summaryrefslogtreecommitdiff
path: root/share
diff options
context:
space:
mode:
Diffstat (limited to 'share')
-rw-r--r--share/gdb/python/gdb/__init__.py18
-rw-r--r--share/gdb/python/gdb/command/__init__.py16
-rw-r--r--share/gdb/python/gdb/command/pretty_printers.py370
-rw-r--r--share/gdb/python/gdb/printing.py208
-rw-r--r--share/gdb/python/gdb/types.py91
-rw-r--r--share/gdb/syscalls/amd64-linux.xml314
-rw-r--r--share/gdb/syscalls/gdb-syscalls.dtd14
-rw-r--r--share/gdb/syscalls/i386-linux.xml340
-rw-r--r--share/gdb/syscalls/mips-n32-linux.xml319
-rw-r--r--share/gdb/syscalls/mips-n64-linux.xml312
-rw-r--r--share/gdb/syscalls/mips-o32-linux.xml347
-rw-r--r--share/gdb/syscalls/ppc-linux.xml310
-rw-r--r--share/gdb/syscalls/ppc64-linux.xml295
-rw-r--r--share/gdb/syscalls/sparc-linux.xml344
-rw-r--r--share/gdb/syscalls/sparc64-linux.xml326
-rw-r--r--share/info/annotate.info1192
-rw-r--r--share/info/as.info22623
-rw-r--r--share/info/bfd.info11673
-rw-r--r--share/info/binutils.info4646
-rw-r--r--share/info/configure.info2773
-rw-r--r--share/info/cpp.info5549
-rw-r--r--share/info/cppinternals.info1036
-rw-r--r--share/info/dir65
-rw-r--r--share/info/gcc.info49096
-rw-r--r--share/info/gccinstall.info4656
-rw-r--r--share/info/gccint.info47869
-rw-r--r--share/info/gdb.info39097
-rw-r--r--share/info/gdbint.info8855
-rw-r--r--share/info/gprof.info2475
-rw-r--r--share/info/ld.info7877
-rw-r--r--share/info/stabs.info4590
-rw-r--r--share/info/standards.info5744
-rw-r--r--share/locale/bg/LC_MESSAGES/binutils.mobin45189 -> 0 bytes
-rw-r--r--share/locale/bg/LC_MESSAGES/gprof.mobin12677 -> 0 bytes
-rw-r--r--share/locale/bg/LC_MESSAGES/ld.mobin71843 -> 0 bytes
-rw-r--r--share/locale/da/LC_MESSAGES/bfd.mobin60556 -> 0 bytes
-rw-r--r--share/locale/da/LC_MESSAGES/binutils.mobin67752 -> 0 bytes
-rw-r--r--share/locale/da/LC_MESSAGES/gprof.mobin9586 -> 0 bytes
-rw-r--r--share/locale/da/LC_MESSAGES/ld.mobin40607 -> 0 bytes
-rw-r--r--share/locale/da/LC_MESSAGES/opcodes.mobin8332 -> 0 bytes
-rw-r--r--share/locale/de/LC_MESSAGES/gprof.mobin10545 -> 0 bytes
-rw-r--r--share/locale/de/LC_MESSAGES/opcodes.mobin16919 -> 0 bytes
-rw-r--r--share/locale/es/LC_MESSAGES/bfd.mobin139774 -> 0 bytes
-rw-r--r--share/locale/es/LC_MESSAGES/binutils.mobin180134 -> 0 bytes
-rw-r--r--share/locale/es/LC_MESSAGES/gas.mobin418871 -> 0 bytes
-rw-r--r--share/locale/es/LC_MESSAGES/gprof.mobin10797 -> 0 bytes
-rw-r--r--share/locale/es/LC_MESSAGES/ld.mobin57540 -> 0 bytes
-rw-r--r--share/locale/es/LC_MESSAGES/opcodes.mobin25770 -> 0 bytes
-rw-r--r--share/locale/fi/LC_MESSAGES/bfd.mobin142032 -> 0 bytes
-rw-r--r--share/locale/fi/LC_MESSAGES/binutils.mobin173759 -> 0 bytes
-rw-r--r--share/locale/fi/LC_MESSAGES/gprof.mobin11021 -> 0 bytes
-rw-r--r--share/locale/fi/LC_MESSAGES/ld.mobin57441 -> 0 bytes
-rw-r--r--share/locale/fi/LC_MESSAGES/opcodes.mobin26403 -> 0 bytes
-rw-r--r--share/locale/fr/LC_MESSAGES/bfd.mobin142671 -> 0 bytes
-rw-r--r--share/locale/fr/LC_MESSAGES/binutils.mobin178907 -> 0 bytes
-rw-r--r--share/locale/fr/LC_MESSAGES/gas.mobin228353 -> 0 bytes
-rw-r--r--share/locale/fr/LC_MESSAGES/gprof.mobin10838 -> 0 bytes
-rw-r--r--share/locale/fr/LC_MESSAGES/ld.mobin51807 -> 0 bytes
-rw-r--r--share/locale/fr/LC_MESSAGES/opcodes.mobin25313 -> 0 bytes
-rw-r--r--share/locale/ga/LC_MESSAGES/gprof.mobin10440 -> 0 bytes
-rw-r--r--share/locale/ga/LC_MESSAGES/ld.mobin48922 -> 0 bytes
-rw-r--r--share/locale/ga/LC_MESSAGES/opcodes.mobin24028 -> 0 bytes
-rw-r--r--share/locale/id/LC_MESSAGES/bfd.mobin105891 -> 0 bytes
-rw-r--r--share/locale/id/LC_MESSAGES/binutils.mobin153153 -> 0 bytes
-rw-r--r--share/locale/id/LC_MESSAGES/gas.mobin389863 -> 0 bytes
-rw-r--r--share/locale/id/LC_MESSAGES/gprof.mobin10448 -> 0 bytes
-rw-r--r--share/locale/id/LC_MESSAGES/ld.mobin53562 -> 0 bytes
-rw-r--r--share/locale/id/LC_MESSAGES/opcodes.mobin25350 -> 0 bytes
-rw-r--r--share/locale/ja/LC_MESSAGES/bfd.mobin52923 -> 0 bytes
-rw-r--r--share/locale/ja/LC_MESSAGES/binutils.mobin180914 -> 0 bytes
-rw-r--r--share/locale/ja/LC_MESSAGES/ld.mobin32271 -> 0 bytes
-rw-r--r--share/locale/ms/LC_MESSAGES/gprof.mobin10360 -> 0 bytes
-rw-r--r--share/locale/nl/LC_MESSAGES/gprof.mobin10712 -> 0 bytes
-rw-r--r--share/locale/nl/LC_MESSAGES/opcodes.mobin25236 -> 0 bytes
-rw-r--r--share/locale/pt_BR/LC_MESSAGES/gprof.mobin9984 -> 0 bytes
-rw-r--r--share/locale/pt_BR/LC_MESSAGES/opcodes.mobin8467 -> 0 bytes
-rw-r--r--share/locale/ro/LC_MESSAGES/bfd.mobin69038 -> 0 bytes
-rw-r--r--share/locale/ro/LC_MESSAGES/binutils.mobin20265 -> 0 bytes
-rw-r--r--share/locale/ro/LC_MESSAGES/gprof.mobin9898 -> 0 bytes
-rw-r--r--share/locale/ro/LC_MESSAGES/opcodes.mobin15986 -> 0 bytes
-rw-r--r--share/locale/ru/LC_MESSAGES/bfd.mobin175235 -> 0 bytes
-rw-r--r--share/locale/ru/LC_MESSAGES/binutils.mobin216900 -> 0 bytes
-rw-r--r--share/locale/ru/LC_MESSAGES/gas.mobin23024 -> 0 bytes
-rw-r--r--share/locale/ru/LC_MESSAGES/gprof.mobin12808 -> 0 bytes
-rw-r--r--share/locale/rw/LC_MESSAGES/bfd.mobin429 -> 0 bytes
-rw-r--r--share/locale/rw/LC_MESSAGES/binutils.mobin615 -> 0 bytes
-rw-r--r--share/locale/rw/LC_MESSAGES/gas.mobin396 -> 0 bytes
-rw-r--r--share/locale/rw/LC_MESSAGES/gprof.mobin486 -> 0 bytes
-rw-r--r--share/locale/sk/LC_MESSAGES/binutils.mobin149635 -> 0 bytes
-rw-r--r--share/locale/sv/LC_MESSAGES/bfd.mobin67266 -> 0 bytes
-rw-r--r--share/locale/sv/LC_MESSAGES/binutils.mobin113208 -> 0 bytes
-rw-r--r--share/locale/sv/LC_MESSAGES/gprof.mobin10367 -> 0 bytes
-rw-r--r--share/locale/sv/LC_MESSAGES/ld.mobin43131 -> 0 bytes
-rw-r--r--share/locale/sv/LC_MESSAGES/opcodes.mobin16004 -> 0 bytes
-rw-r--r--share/locale/tr/LC_MESSAGES/bfd.mobin69529 -> 0 bytes
-rw-r--r--share/locale/tr/LC_MESSAGES/binutils.mobin129842 -> 0 bytes
-rw-r--r--share/locale/tr/LC_MESSAGES/gas.mobin220920 -> 0 bytes
-rw-r--r--share/locale/tr/LC_MESSAGES/gprof.mobin11331 -> 0 bytes
-rw-r--r--share/locale/tr/LC_MESSAGES/ld.mobin41339 -> 0 bytes
-rw-r--r--share/locale/tr/LC_MESSAGES/opcodes.mobin16094 -> 0 bytes
-rw-r--r--share/locale/uk/LC_MESSAGES/binutils.mobin172392 -> 0 bytes
-rw-r--r--share/locale/vi/LC_MESSAGES/bfd.mobin118337 -> 0 bytes
-rw-r--r--share/locale/vi/LC_MESSAGES/binutils.mobin172896 -> 0 bytes
-rw-r--r--share/locale/vi/LC_MESSAGES/gprof.mobin12434 -> 0 bytes
-rw-r--r--share/locale/vi/LC_MESSAGES/ld.mobin59341 -> 0 bytes
-rw-r--r--share/locale/vi/LC_MESSAGES/opcodes.mobin27675 -> 0 bytes
-rw-r--r--share/locale/zh_CN/LC_MESSAGES/bfd.mobin28121 -> 0 bytes
-rw-r--r--share/locale/zh_CN/LC_MESSAGES/binutils.mobin75892 -> 0 bytes
-rw-r--r--share/locale/zh_CN/LC_MESSAGES/ld.mobin24785 -> 0 bytes
-rw-r--r--share/locale/zh_CN/LC_MESSAGES/opcodes.mobin9039 -> 0 bytes
-rw-r--r--share/locale/zh_TW/LC_MESSAGES/binutils.mobin121475 -> 0 bytes
-rw-r--r--share/locale/zh_TW/LC_MESSAGES/ld.mobin44839 -> 0 bytes
-rw-r--r--share/man/man1/arm-eabi-addr2line.1287
-rw-r--r--share/man/man1/arm-eabi-ar.1428
-rw-r--r--share/man/man1/arm-eabi-as.11321
-rw-r--r--share/man/man1/arm-eabi-c++filt.1346
-rw-r--r--share/man/man1/arm-eabi-cpp.1992
-rw-r--r--share/man/man1/arm-eabi-dlltool.1531
-rw-r--r--share/man/man1/arm-eabi-elfedit.1233
-rw-r--r--share/man/man1/arm-eabi-g++.117818
-rw-r--r--share/man/man1/arm-eabi-gcc.117818
-rw-r--r--share/man/man1/arm-eabi-gcov.1681
-rw-r--r--share/man/man1/arm-eabi-gdb.1381
-rw-r--r--share/man/man1/arm-eabi-gdbtui.1381
-rw-r--r--share/man/man1/arm-eabi-gprof.1757
-rw-r--r--share/man/man1/arm-eabi-ld.12413
-rw-r--r--share/man/man1/arm-eabi-nlmconv.1244
-rw-r--r--share/man/man1/arm-eabi-nm.1516
-rw-r--r--share/man/man1/arm-eabi-objcopy.1960
-rw-r--r--share/man/man1/arm-eabi-objdump.1799
-rw-r--r--share/man/man1/arm-eabi-ranlib.1192
-rw-r--r--share/man/man1/arm-eabi-readelf.1426
-rw-r--r--share/man/man1/arm-eabi-run.1475
-rw-r--r--share/man/man1/arm-eabi-size.1268
-rw-r--r--share/man/man1/arm-eabi-strings.1257
-rw-r--r--share/man/man1/arm-eabi-strip.1392
-rw-r--r--share/man/man1/arm-eabi-windmc.1353
-rw-r--r--share/man/man1/arm-eabi-windres.1354
-rw-r--r--share/man/man7/fsf-funding.7184
-rw-r--r--share/man/man7/gfdl.7637
-rw-r--r--share/man/man7/gpl.7841
141 files changed, 0 insertions, 274725 deletions
diff --git a/share/gdb/python/gdb/__init__.py b/share/gdb/python/gdb/__init__.py
deleted file mode 100644
index 43975c2..0000000
--- a/share/gdb/python/gdb/__init__.py
+++ /dev/null
@@ -1,18 +0,0 @@
-# Copyright (C) 2010, 2011 Free Software Foundation, Inc.
-
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 3 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, see <http://www.gnu.org/licenses/>.
-
-import gdb.command.pretty_printers
-
-gdb.command.pretty_printers.register_pretty_printer_commands()
diff --git a/share/gdb/python/gdb/command/__init__.py b/share/gdb/python/gdb/command/__init__.py
deleted file mode 100644
index ee2b61f..0000000
--- a/share/gdb/python/gdb/command/__init__.py
+++ /dev/null
@@ -1,16 +0,0 @@
-# Copyright (C) 2010, 2011 Free Software Foundation, Inc.
-
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 3 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, see <http://www.gnu.org/licenses/>.
-
-
diff --git a/share/gdb/python/gdb/command/pretty_printers.py b/share/gdb/python/gdb/command/pretty_printers.py
deleted file mode 100644
index 86923d7..0000000
--- a/share/gdb/python/gdb/command/pretty_printers.py
+++ /dev/null
@@ -1,370 +0,0 @@
-# Pretty-printer commands.
-# Copyright (C) 2010, 2011 Free Software Foundation, Inc.
-
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 3 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, see <http://www.gnu.org/licenses/>.
-
-"""GDB commands for working with pretty-printers."""
-
-import copy
-import gdb
-import re
-
-
-def parse_printer_regexps(arg):
- """Internal utility to parse a pretty-printer command argv.
-
- Arguments:
- arg: The arguments to the command. The format is:
- [object-regexp [name-regexp]].
- Individual printers in a collection are named as
- printer-name;subprinter-name.
-
- Returns:
- The result is a 3-tuple of compiled regular expressions, except that
- the resulting compiled subprinter regexp is None if not provided.
-
- Raises:
- SyntaxError: an error processing ARG
- """
-
- argv = gdb.string_to_argv(arg);
- argc = len(argv)
- object_regexp = "" # match everything
- name_regexp = "" # match everything
- subname_regexp = None
- if argc > 3:
- raise SyntaxError("too many arguments")
- if argc >= 1:
- object_regexp = argv[0]
- if argc >= 2:
- name_subname = argv[1].split(";", 1)
- name_regexp = name_subname[0]
- if len(name_subname) == 2:
- subname_regexp = name_subname[1]
- # That re.compile raises SyntaxError was determined empirically.
- # We catch it and reraise it to provide a slightly more useful
- # error message for the user.
- try:
- object_re = re.compile(object_regexp)
- except SyntaxError:
- raise SyntaxError("invalid object regexp: %s" % object_regexp)
- try:
- name_re = re.compile (name_regexp)
- except SyntaxError:
- raise SyntaxError("invalid name regexp: %s" % name_regexp)
- if subname_regexp is not None:
- try:
- subname_re = re.compile(subname_regexp)
- except SyntaxError:
- raise SyntaxError("invalid subname regexp: %s" % subname_regexp)
- else:
- subname_re = None
- return(object_re, name_re, subname_re)
-
-
-def printer_enabled_p(printer):
- """Internal utility to see if printer (or subprinter) is enabled."""
- if hasattr(printer, "enabled"):
- return printer.enabled
- else:
- return True
-
-
-class InfoPrettyPrinter(gdb.Command):
- """GDB command to list all registered pretty-printers.
-
- Usage: info pretty-printer [object-regexp [name-regexp]]
-
- OBJECT-REGEXP is a regular expression matching the objects to list.
- Objects are "global", the program space's file, and the objfiles within
- that program space.
-
- NAME-REGEXP matches the name of the pretty-printer.
- Individual printers in a collection are named as
- printer-name;subprinter-name.
- """
-
- def __init__ (self):
- super(InfoPrettyPrinter, self).__init__("info pretty-printer",
- gdb.COMMAND_DATA)
-
- @staticmethod
- def enabled_string(printer):
- """Return "" if PRINTER is enabled, otherwise " [disabled]"."""
- if printer_enabled_p(printer):
- return ""
- else:
- return " [disabled]"
-
- @staticmethod
- def printer_name(printer):
- """Return the printer's name."""
- if hasattr(printer, "name"):
- return printer.name
- if hasattr(printer, "__name__"):
- return printer.__name__
- # This "shouldn't happen", but the public API allows for
- # direct additions to the pretty-printer list, and we shouldn't
- # crash because someone added a bogus printer.
- # Plus we want to give the user a way to list unknown printers.
- return "unknown"
-
- def list_pretty_printers(self, pretty_printers, name_re, subname_re):
- """Print a list of pretty-printers."""
- # A potential enhancement is to provide an option to list printers in
- # "lookup order" (i.e. unsorted).
- sorted_pretty_printers = copy.copy(pretty_printers)
- sorted_pretty_printers.sort(lambda x, y:
- cmp(self.printer_name(x),
- self.printer_name(y)))
- for printer in sorted_pretty_printers:
- name = self.printer_name(printer)
- enabled = self.enabled_string(printer)
- if name_re.match(name):
- print " %s%s" % (name, enabled)
- if (hasattr(printer, "subprinters") and
- printer.subprinters is not None):
- sorted_subprinters = copy.copy(printer.subprinters)
- sorted_subprinters.sort(lambda x, y:
- cmp(self.printer_name(x),
- self.printer_name(y)))
- for subprinter in sorted_subprinters:
- if (not subname_re or
- subname_re.match(subprinter.name)):
- print (" %s%s" %
- (subprinter.name,
- self.enabled_string(subprinter)))
-
- def invoke1(self, title, printer_list,
- obj_name_to_match, object_re, name_re, subname_re):
- """"Subroutine of invoke to simplify it."""
- if printer_list and object_re.match(obj_name_to_match):
- print title
- self.list_pretty_printers(printer_list, name_re, subname_re)
-
- def invoke(self, arg, from_tty):
- """GDB calls this to perform the command."""
- (object_re, name_re, subname_re) = parse_printer_regexps(arg)
- self.invoke1("global pretty-printers:", gdb.pretty_printers,
- "global", object_re, name_re, subname_re)
- cp = gdb.current_progspace()
- self.invoke1("progspace %s pretty-printers:" % cp.filename,
- cp.pretty_printers, "progspace",
- object_re, name_re, subname_re)
- for objfile in gdb.objfiles():
- self.invoke1(" objfile %s pretty-printers:" % objfile.filename,
- objfile.pretty_printers, objfile.filename,
- object_re, name_re, subname_re)
-
-
-def count_enabled_printers(pretty_printers):
- """Return a 2-tuple of number of enabled and total printers."""
- enabled = 0
- total = 0
- for printer in pretty_printers:
- if (hasattr(printer, "subprinters")
- and printer.subprinters is not None):
- if printer_enabled_p(printer):
- for subprinter in printer.subprinters:
- if printer_enabled_p(subprinter):
- enabled += 1
- total += len(printer.subprinters)
- else:
- if printer_enabled_p(printer):
- enabled += 1
- total += 1
- return (enabled, total)
-
-
-def count_all_enabled_printers():
- """Return a 2-tuble of the enabled state and total number of all printers.
- This includes subprinters.
- """
- enabled_count = 0
- total_count = 0
- (t_enabled, t_total) = count_enabled_printers(gdb.pretty_printers)
- enabled_count += t_enabled
- total_count += t_total
- (t_enabled, t_total) = count_enabled_printers(gdb.current_progspace().pretty_printers)
- enabled_count += t_enabled
- total_count += t_total
- for objfile in gdb.objfiles():
- (t_enabled, t_total) = count_enabled_printers(objfile.pretty_printers)
- enabled_count += t_enabled
- total_count += t_total
- return (enabled_count, total_count)
-
-
-def pluralize(text, n, suffix="s"):
- """Return TEXT pluralized if N != 1."""
- if n != 1:
- return "%s%s" % (text, suffix)
- else:
- return text
-
-
-def show_pretty_printer_enabled_summary():
- """Print the number of printers enabled/disabled.
- We count subprinters individually.
- """
- (enabled_count, total_count) = count_all_enabled_printers()
- print "%d of %d printers enabled" % (enabled_count, total_count)
-
-
-def do_enable_pretty_printer_1 (pretty_printers, name_re, subname_re, flag):
- """Worker for enabling/disabling pretty-printers.
-
- Arguments:
- pretty_printers: list of pretty-printers
- name_re: regular-expression object to select printers
- subname_re: regular expression object to select subprinters or None
- if all are affected
- flag: True for Enable, False for Disable
-
- Returns:
- The number of printers affected.
- This is just for informational purposes for the user.
- """
- total = 0
- for printer in pretty_printers:
- if (hasattr(printer, "name") and name_re.match(printer.name) or
- hasattr(printer, "__name__") and name_re.match(printer.__name__)):
- if (hasattr(printer, "subprinters") and
- printer.subprinters is not None):
- if not subname_re:
- # Only record printers that change state.
- if printer_enabled_p(printer) != flag:
- for subprinter in printer.subprinters:
- if printer_enabled_p(subprinter):
- total += 1
- # NOTE: We preserve individual subprinter settings.
- printer.enabled = flag
- else:
- # NOTE: Whether this actually disables the subprinter
- # depends on whether the printer's lookup function supports
- # the "enable" API. We can only assume it does.
- for subprinter in printer.subprinters:
- if subname_re.match(subprinter.name):
- # Only record printers that change state.
- if (printer_enabled_p(printer) and
- printer_enabled_p(subprinter) != flag):
- total += 1
- subprinter.enabled = flag
- else:
- # This printer has no subprinters.
- # If the user does "disable pretty-printer .* .* foo"
- # should we disable printers that don't have subprinters?
- # How do we apply "foo" in this context? Since there is no
- # "foo" subprinter it feels like we should skip this printer.
- # There's still the issue of how to handle
- # "disable pretty-printer .* .* .*", and every other variation
- # that can match everything. For now punt and only support
- # "disable pretty-printer .* .*" (i.e. subname is elided)
- # to disable everything.
- if not subname_re:
- # Only record printers that change state.
- if printer_enabled_p(printer) != flag:
- total += 1
- printer.enabled = flag
- return total
-
-
-def do_enable_pretty_printer (arg, flag):
- """Internal worker for enabling/disabling pretty-printers."""
- (object_re, name_re, subname_re) = parse_printer_regexps(arg)
-
- total = 0
- if object_re.match("global"):
- total += do_enable_pretty_printer_1(gdb.pretty_printers,
- name_re, subname_re, flag)
- cp = gdb.current_progspace()
- if object_re.match("progspace"):
- total += do_enable_pretty_printer_1(cp.pretty_printers,
- name_re, subname_re, flag)
- for objfile in gdb.objfiles():
- if object_re.match(objfile.filename):
- total += do_enable_pretty_printer_1(objfile.pretty_printers,
- name_re, subname_re, flag)
-
- if flag:
- state = "enabled"
- else:
- state = "disabled"
- print "%d %s %s" % (total, pluralize("printer", total), state)
-
- # Print the total list of printers currently enabled/disabled.
- # This is to further assist the user in determining whether the result
- # is expected. Since we use regexps to select it's useful.
- show_pretty_printer_enabled_summary()
-
-
-# Enable/Disable one or more pretty-printers.
-#
-# This is intended for use when a broken pretty-printer is shipped/installed
-# and the user wants to disable that printer without disabling all the other
-# printers.
-#
-# A useful addition would be -v (verbose) to show each printer affected.
-
-class EnablePrettyPrinter (gdb.Command):
- """GDB command to enable the specified pretty-printer.
-
- Usage: enable pretty-printer [object-regexp [name-regexp]]
-
- OBJECT-REGEXP is a regular expression matching the objects to examine.
- Objects are "global", the program space's file, and the objfiles within
- that program space.
-
- NAME-REGEXP matches the name of the pretty-printer.
- Individual printers in a collection are named as
- printer-name;subprinter-name.
- """
-
- def __init__(self):
- super(EnablePrettyPrinter, self).__init__("enable pretty-printer",
- gdb.COMMAND_DATA)
-
- def invoke(self, arg, from_tty):
- """GDB calls this to perform the command."""
- do_enable_pretty_printer(arg, True)
-
-
-class DisablePrettyPrinter (gdb.Command):
- """GDB command to disable the specified pretty-printer.
-
- Usage: disable pretty-printer [object-regexp [name-regexp]]
-
- OBJECT-REGEXP is a regular expression matching the objects to examine.
- Objects are "global", the program space's file, and the objfiles within
- that program space.
-
- NAME-REGEXP matches the name of the pretty-printer.
- Individual printers in a collection are named as
- printer-name;subprinter-name.
- """
-
- def __init__(self):
- super(DisablePrettyPrinter, self).__init__("disable pretty-printer",
- gdb.COMMAND_DATA)
-
- def invoke(self, arg, from_tty):
- """GDB calls this to perform the command."""
- do_enable_pretty_printer(arg, False)
-
-
-def register_pretty_printer_commands():
- """Call from a top level script to install the pretty-printer commands."""
- InfoPrettyPrinter()
- EnablePrettyPrinter()
- DisablePrettyPrinter()
diff --git a/share/gdb/python/gdb/printing.py b/share/gdb/python/gdb/printing.py
deleted file mode 100644
index a030827..0000000
--- a/share/gdb/python/gdb/printing.py
+++ /dev/null
@@ -1,208 +0,0 @@
-# Pretty-printer utilities.
-# Copyright (C) 2010, 2011 Free Software Foundation, Inc.
-
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 3 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, see <http://www.gnu.org/licenses/>.
-
-"""Utilities for working with pretty-printers."""
-
-import gdb
-import gdb.types
-import re
-
-
-class PrettyPrinter(object):
- """A basic pretty-printer.
-
- Attributes:
- name: A unique string among all printers for the context in which
- it is defined (objfile, progspace, or global(gdb)), and should
- meaningfully describe what can be pretty-printed.
- E.g., "StringPiece" or "protobufs".
- subprinters: An iterable object with each element having a `name'
- attribute, and, potentially, "enabled" attribute.
- Or this is None if there are no subprinters.
- enabled: A boolean indicating if the printer is enabled.
-
- Subprinters are for situations where "one" pretty-printer is actually a
- collection of several printers. E.g., The libstdc++ pretty-printer has
- a pretty-printer for each of several different types, based on regexps.
- """
-
- # While one might want to push subprinters into the subclass, it's
- # present here to formalize such support to simplify
- # commands/pretty_printers.py.
-
- def __init__(self, name, subprinters=None):
- self.name = name
- self.subprinters = subprinters
- self.enabled = True
-
- def __call__(self, val):
- # The subclass must define this.
- raise NotImplementedError("PrettyPrinter __call__")
-
-
-class SubPrettyPrinter(object):
- """Baseclass for sub-pretty-printers.
-
- Sub-pretty-printers needn't use this, but it formalizes what's needed.
-
- Attributes:
- name: The name of the subprinter.
- enabled: A boolean indicating if the subprinter is enabled.
- """
-
- def __init__(self, name):
- self.name = name
- self.enabled = True
-
-
-def register_pretty_printer(obj, printer, replace=False):
- """Register pretty-printer PRINTER with OBJ.
-
- The printer is added to the front of the search list, thus one can override
- an existing printer if one needs to. Use a different name when overriding
- an existing printer, otherwise an exception will be raised; multiple
- printers with the same name are disallowed.
-
- Arguments:
- obj: Either an objfile, progspace, or None (in which case the printer
- is registered globally).
- printer: Either a function of one argument (old way) or any object
- which has attributes: name, enabled, __call__.
- replace: If True replace any existing copy of the printer.
- Otherwise if the printer already exists raise an exception.
-
- Returns:
- Nothing.
-
- Raises:
- TypeError: A problem with the type of the printer.
- ValueError: The printer's name contains a semicolon ";".
- RuntimeError: A printer with the same name is already registered.
-
- If the caller wants the printer to be listable and disableable, it must
- follow the PrettyPrinter API. This applies to the old way (functions) too.
- If printer is an object, __call__ is a method of two arguments:
- self, and the value to be pretty-printed. See PrettyPrinter.
- """
-
- # Watch for both __name__ and name.
- # Functions get the former for free, but we don't want to use an
- # attribute named __foo__ for pretty-printers-as-objects.
- # If printer has both, we use `name'.
- if not hasattr(printer, "__name__") and not hasattr(printer, "name"):
- raise TypeError("printer missing attribute: name")
- if hasattr(printer, "name") and not hasattr(printer, "enabled"):
- raise TypeError("printer missing attribute: enabled")
- if not hasattr(printer, "__call__"):
- raise TypeError("printer missing attribute: __call__")
-
- if obj is None:
- if gdb.parameter("verbose"):
- gdb.write("Registering global %s pretty-printer ...\n" % name)
- obj = gdb
- else:
- if gdb.parameter("verbose"):
- gdb.write("Registering %s pretty-printer for %s ...\n" %
- (printer.name, obj.filename))
-
- if hasattr(printer, "name"):
- if not isinstance(printer.name, basestring):
- raise TypeError("printer name is not a string")
- # If printer provides a name, make sure it doesn't contain ";".
- # Semicolon is used by the info/enable/disable pretty-printer commands
- # to delimit subprinters.
- if printer.name.find(";") >= 0:
- raise ValueError("semicolon ';' in printer name")
- # Also make sure the name is unique.
- # Alas, we can't do the same for functions and __name__, they could
- # all have a canonical name like "lookup_function".
- # PERF: gdb records printers in a list, making this inefficient.
- i = 0
- for p in obj.pretty_printers:
- if hasattr(p, "name") and p.name == printer.name:
- if replace:
- del obj.pretty_printers[i]
- break
- else:
- raise RuntimeError("pretty-printer already registered: %s" %
- printer.name)
- i = i + 1
-
- obj.pretty_printers.insert(0, printer)
-
-
-class RegexpCollectionPrettyPrinter(PrettyPrinter):
- """Class for implementing a collection of regular-expression based pretty-printers.
-
- Intended usage:
-
- pretty_printer = RegexpCollectionPrettyPrinter("my_library")
- pretty_printer.add_printer("myclass1", "^myclass1$", MyClass1Printer)
- ...
- pretty_printer.add_printer("myclassN", "^myclassN$", MyClassNPrinter)
- register_pretty_printer(obj, pretty_printer)
- """
-
- class RegexpSubprinter(SubPrettyPrinter):
- def __init__(self, name, regexp, gen_printer):
- super(RegexpCollectionPrettyPrinter.RegexpSubprinter, self).__init__(name)
- self.regexp = regexp
- self.gen_printer = gen_printer
- self.compiled_re = re.compile(regexp)
-
- def __init__(self, name):
- super(RegexpCollectionPrettyPrinter, self).__init__(name, [])
-
- def add_printer(self, name, regexp, gen_printer):
- """Add a printer to the list.
-
- The printer is added to the end of the list.
-
- Arguments:
- name: The name of the subprinter.
- regexp: The regular expression, as a string.
- gen_printer: A function/method that given a value returns an
- object to pretty-print it.
-
- Returns:
- Nothing.
- """
-
- # NOTE: A previous version made the name of each printer the regexp.
- # That makes it awkward to pass to the enable/disable commands (it's
- # cumbersome to make a regexp of a regexp). So now the name is a
- # separate parameter.
-
- self.subprinters.append(self.RegexpSubprinter(name, regexp,
- gen_printer))
-
- def __call__(self, val):
- """Lookup the pretty-printer for the provided value."""
-
- # Get the type name.
- typename = gdb.types.get_basic_type(val.type).tag
- if not typename:
- return None
-
- # Iterate over table of type regexps to determine
- # if a printer is registered for that type.
- # Return an instantiation of the printer if found.
- for printer in self.subprinters:
- if printer.enabled and printer.compiled_re.search(typename):
- return printer.gen_printer(val)
-
- # Cannot find a pretty printer. Return None.
- return None
diff --git a/share/gdb/python/gdb/types.py b/share/gdb/python/gdb/types.py
deleted file mode 100644
index 54fbe3c..0000000
--- a/share/gdb/python/gdb/types.py
+++ /dev/null
@@ -1,91 +0,0 @@
-# Type utilities.
-# Copyright (C) 2010, 2011 Free Software Foundation, Inc.
-
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 3 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, see <http://www.gnu.org/licenses/>.
-
-"""Utilities for working with gdb.Types."""
-
-import gdb
-
-
-def get_basic_type(type_):
- """Return the "basic" type of a type.
-
- Arguments:
- type_: The type to reduce to its basic type.
-
- Returns:
- type_ with const/volatile is stripped away,
- and typedefs/references converted to the underlying type.
- """
-
- while (type_.code == gdb.TYPE_CODE_REF or
- type_.code == gdb.TYPE_CODE_TYPEDEF):
- if type_.code == gdb.TYPE_CODE_REF:
- type_ = type_.target()
- else:
- type_ = type_.strip_typedefs()
- return type_.unqualified()
-
-
-def has_field(type_, field):
- """Return True if a type has the specified field.
-
- Arguments:
- type_: The type to examine.
- It must be one of gdb.TYPE_CODE_STRUCT, gdb.TYPE_CODE_UNION.
- field: The name of the field to look up.
-
- Returns:
- True if the field is present either in type_ or any baseclass.
-
- Raises:
- TypeError: The type is not a struct or union.
- """
-
- type_ = get_basic_type(type_)
- if (type_.code != gdb.TYPE_CODE_STRUCT and
- type_.code != gdb.TYPE_CODE_UNION):
- raise TypeError("not a struct or union")
- for f in type_.fields():
- if f.is_base_class:
- if has_field(f.type, field):
- return True
- else:
- # NOTE: f.name could be None
- if f.name == field:
- return True
- return False
-
-
-def make_enum_dict(enum_type):
- """Return a dictionary from a program's enum type.
-
- Arguments:
- enum_type: The enum to compute the dictionary for.
-
- Returns:
- The dictionary of the enum.
-
- Raises:
- TypeError: The type is not an enum.
- """
-
- if enum_type.code != gdb.TYPE_CODE_ENUM:
- raise TypeError("not an enum type")
- enum_dict = {}
- for field in enum_type.fields():
- # The enum's value is stored in "bitpos".
- enum_dict[field.name] = field.bitpos
- return enum_dict
diff --git a/share/gdb/syscalls/amd64-linux.xml b/share/gdb/syscalls/amd64-linux.xml
deleted file mode 100644
index ee0ea6d..0000000
--- a/share/gdb/syscalls/amd64-linux.xml
+++ /dev/null
@@ -1,314 +0,0 @@
-<?xml version="1.0"?>
-<!-- Copyright (C) 2009, 2011 Free Software Foundation, Inc.
-
- Copying and distribution of this file, with or without modification,
- are permitted in any medium without royalty provided the copyright
- notice and this notice are preserved. -->
-
-<!DOCTYPE feature SYSTEM "gdb-syscalls.dtd">
-
-<!-- This file was generated using the following file:
-
- /usr/src/linux/arch/x86/include/asm/unistd_64.h
-
- The file mentioned above belongs to the Linux Kernel. -->
-
-<syscalls_info>
- <syscall name="read" number="0"/>
- <syscall name="write" number="1"/>
- <syscall name="open" number="2"/>
- <syscall name="close" number="3"/>
- <syscall name="stat" number="4"/>
- <syscall name="fstat" number="5"/>
- <syscall name="lstat" number="6"/>
- <syscall name="poll" number="7"/>
- <syscall name="lseek" number="8"/>
- <syscall name="mmap" number="9"/>
- <syscall name="mprotect" number="10"/>
- <syscall name="munmap" number="11"/>
- <syscall name="brk" number="12"/>
- <syscall name="rt_sigaction" number="13"/>
- <syscall name="rt_sigprocmask" number="14"/>
- <syscall name="rt_sigreturn" number="15"/>
- <syscall name="ioctl" number="16"/>
- <syscall name="pread64" number="17"/>
- <syscall name="pwrite64" number="18"/>
- <syscall name="readv" number="19"/>
- <syscall name="writev" number="20"/>
- <syscall name="access" number="21"/>
- <syscall name="pipe" number="22"/>
- <syscall name="select" number="23"/>
- <syscall name="sched_yield" number="24"/>
- <syscall name="mremap" number="25"/>
- <syscall name="msync" number="26"/>
- <syscall name="mincore" number="27"/>
- <syscall name="madvise" number="28"/>
- <syscall name="shmget" number="29"/>
- <syscall name="shmat" number="30"/>
- <syscall name="shmctl" number="31"/>
- <syscall name="dup" number="32"/>
- <syscall name="dup2" number="33"/>
- <syscall name="pause" number="34"/>
- <syscall name="nanosleep" number="35"/>
- <syscall name="getitimer" number="36"/>
- <syscall name="alarm" number="37"/>
- <syscall name="setitimer" number="38"/>
- <syscall name="getpid" number="39"/>
- <syscall name="sendfile" number="40"/>
- <syscall name="socket" number="41"/>
- <syscall name="connect" number="42"/>
- <syscall name="accept" number="43"/>
- <syscall name="sendto" number="44"/>
- <syscall name="recvfrom" number="45"/>
- <syscall name="sendmsg" number="46"/>
- <syscall name="recvmsg" number="47"/>
- <syscall name="shutdown" number="48"/>
- <syscall name="bind" number="49"/>
- <syscall name="listen" number="50"/>
- <syscall name="getsockname" number="51"/>
- <syscall name="getpeername" number="52"/>
- <syscall name="socketpair" number="53"/>
- <syscall name="setsockopt" number="54"/>
- <syscall name="getsockopt" number="55"/>
- <syscall name="clone" number="56"/>
- <syscall name="fork" number="57"/>
- <syscall name="vfork" number="58"/>
- <syscall name="execve" number="59"/>
- <syscall name="exit" number="60"/>
- <syscall name="wait4" number="61"/>
- <syscall name="kill" number="62"/>
- <syscall name="uname" number="63"/>
- <syscall name="semget" number="64"/>
- <syscall name="semop" number="65"/>
- <syscall name="semctl" number="66"/>
- <syscall name="shmdt" number="67"/>
- <syscall name="msgget" number="68"/>
- <syscall name="msgsnd" number="69"/>
- <syscall name="msgrcv" number="70"/>
- <syscall name="msgctl" number="71"/>
- <syscall name="fcntl" number="72"/>
- <syscall name="flock" number="73"/>
- <syscall name="fsync" number="74"/>
- <syscall name="fdatasync" number="75"/>
- <syscall name="truncate" number="76"/>
- <syscall name="ftruncate" number="77"/>
- <syscall name="getdents" number="78"/>
- <syscall name="getcwd" number="79"/>
- <syscall name="chdir" number="80"/>
- <syscall name="fchdir" number="81"/>
- <syscall name="rename" number="82"/>
- <syscall name="mkdir" number="83"/>
- <syscall name="rmdir" number="84"/>
- <syscall name="creat" number="85"/>
- <syscall name="link" number="86"/>
- <syscall name="unlink" number="87"/>
- <syscall name="symlink" number="88"/>
- <syscall name="readlink" number="89"/>
- <syscall name="chmod" number="90"/>
- <syscall name="fchmod" number="91"/>
- <syscall name="chown" number="92"/>
- <syscall name="fchown" number="93"/>
- <syscall name="lchown" number="94"/>
- <syscall name="umask" number="95"/>
- <syscall name="gettimeofday" number="96"/>
- <syscall name="getrlimit" number="97"/>
- <syscall name="getrusage" number="98"/>
- <syscall name="sysinfo" number="99"/>
- <syscall name="times" number="100"/>
- <syscall name="ptrace" number="101"/>
- <syscall name="getuid" number="102"/>
- <syscall name="syslog" number="103"/>
- <syscall name="getgid" number="104"/>
- <syscall name="setuid" number="105"/>
- <syscall name="setgid" number="106"/>
- <syscall name="geteuid" number="107"/>
- <syscall name="getegid" number="108"/>
- <syscall name="setpgid" number="109"/>
- <syscall name="getppid" number="110"/>
- <syscall name="getpgrp" number="111"/>
- <syscall name="setsid" number="112"/>
- <syscall name="setreuid" number="113"/>
- <syscall name="setregid" number="114"/>
- <syscall name="getgroups" number="115"/>
- <syscall name="setgroups" number="116"/>
- <syscall name="setresuid" number="117"/>
- <syscall name="getresuid" number="118"/>
- <syscall name="setresgid" number="119"/>
- <syscall name="getresgid" number="120"/>
- <syscall name="getpgid" number="121"/>
- <syscall name="setfsuid" number="122"/>
- <syscall name="setfsgid" number="123"/>
- <syscall name="getsid" number="124"/>
- <syscall name="capget" number="125"/>
- <syscall name="capset" number="126"/>
- <syscall name="rt_sigpending" number="127"/>
- <syscall name="rt_sigtimedwait" number="128"/>
- <syscall name="rt_sigqueueinfo" number="129"/>
- <syscall name="rt_sigsuspend" number="130"/>
- <syscall name="sigaltstack" number="131"/>
- <syscall name="utime" number="132"/>
- <syscall name="mknod" number="133"/>
- <syscall name="uselib" number="134"/>
- <syscall name="personality" number="135"/>
- <syscall name="ustat" number="136"/>
- <syscall name="statfs" number="137"/>
- <syscall name="fstatfs" number="138"/>
- <syscall name="sysfs" number="139"/>
- <syscall name="getpriority" number="140"/>
- <syscall name="setpriority" number="141"/>
- <syscall name="sched_setparam" number="142"/>
- <syscall name="sched_getparam" number="143"/>
- <syscall name="sched_setscheduler" number="144"/>
- <syscall name="sched_getscheduler" number="145"/>
- <syscall name="sched_get_priority_max" number="146"/>
- <syscall name="sched_get_priority_min" number="147"/>
- <syscall name="sched_rr_get_interval" number="148"/>
- <syscall name="mlock" number="149"/>
- <syscall name="munlock" number="150"/>
- <syscall name="mlockall" number="151"/>
- <syscall name="munlockall" number="152"/>
- <syscall name="vhangup" number="153"/>
- <syscall name="modify_ldt" number="154"/>
- <syscall name="pivot_root" number="155"/>
- <syscall name="_sysctl" number="156"/>
- <syscall name="prctl" number="157"/>
- <syscall name="arch_prctl" number="158"/>
- <syscall name="adjtimex" number="159"/>
- <syscall name="setrlimit" number="160"/>
- <syscall name="chroot" number="161"/>
- <syscall name="sync" number="162"/>
- <syscall name="acct" number="163"/>
- <syscall name="settimeofday" number="164"/>
- <syscall name="mount" number="165"/>
- <syscall name="umount2" number="166"/>
- <syscall name="swapon" number="167"/>
- <syscall name="swapoff" number="168"/>
- <syscall name="reboot" number="169"/>
- <syscall name="sethostname" number="170"/>
- <syscall name="setdomainname" number="171"/>
- <syscall name="iopl" number="172"/>
- <syscall name="ioperm" number="173"/>
- <syscall name="create_module" number="174"/>
- <syscall name="init_module" number="175"/>
- <syscall name="delete_module" number="176"/>
- <syscall name="get_kernel_syms" number="177"/>
- <syscall name="query_module" number="178"/>
- <syscall name="quotactl" number="179"/>
- <syscall name="nfsservctl" number="180"/>
- <syscall name="getpmsg" number="181"/>
- <syscall name="putpmsg" number="182"/>
- <syscall name="afs_syscall" number="183"/>
- <syscall name="tuxcall" number="184"/>
- <syscall name="security" number="185"/>
- <syscall name="gettid" number="186"/>
- <syscall name="readahead" number="187"/>
- <syscall name="setxattr" number="188"/>
- <syscall name="lsetxattr" number="189"/>
- <syscall name="fsetxattr" number="190"/>
- <syscall name="getxattr" number="191"/>
- <syscall name="lgetxattr" number="192"/>
- <syscall name="fgetxattr" number="193"/>
- <syscall name="listxattr" number="194"/>
- <syscall name="llistxattr" number="195"/>
- <syscall name="flistxattr" number="196"/>
- <syscall name="removexattr" number="197"/>
- <syscall name="lremovexattr" number="198"/>
- <syscall name="fremovexattr" number="199"/>
- <syscall name="tkill" number="200"/>
- <syscall name="time" number="201"/>
- <syscall name="futex" number="202"/>
- <syscall name="sched_setaffinity" number="203"/>
- <syscall name="sched_getaffinity" number="204"/>
- <syscall name="set_thread_area" number="205"/>
- <syscall name="io_setup" number="206"/>
- <syscall name="io_destroy" number="207"/>
- <syscall name="io_getevents" number="208"/>
- <syscall name="io_submit" number="209"/>
- <syscall name="io_cancel" number="210"/>
- <syscall name="get_thread_area" number="211"/>
- <syscall name="lookup_dcookie" number="212"/>
- <syscall name="epoll_create" number="213"/>
- <syscall name="epoll_ctl_old" number="214"/>
- <syscall name="epoll_wait_old" number="215"/>
- <syscall name="remap_file_pages" number="216"/>
- <syscall name="getdents64" number="217"/>
- <syscall name="set_tid_address" number="218"/>
- <syscall name="restart_syscall" number="219"/>
- <syscall name="semtimedop" number="220"/>
- <syscall name="fadvise64" number="221"/>
- <syscall name="timer_create" number="222"/>
- <syscall name="timer_settime" number="223"/>
- <syscall name="timer_gettime" number="224"/>
- <syscall name="timer_getoverrun" number="225"/>
- <syscall name="timer_delete" number="226"/>
- <syscall name="clock_settime" number="227"/>
- <syscall name="clock_gettime" number="228"/>
- <syscall name="clock_getres" number="229"/>
- <syscall name="clock_nanosleep" number="230"/>
- <syscall name="exit_group" number="231"/>
- <syscall name="epoll_wait" number="232"/>
- <syscall name="epoll_ctl" number="233"/>
- <syscall name="tgkill" number="234"/>
- <syscall name="utimes" number="235"/>
- <syscall name="vserver" number="236"/>
- <syscall name="mbind" number="237"/>
- <syscall name="set_mempolicy" number="238"/>
- <syscall name="get_mempolicy" number="239"/>
- <syscall name="mq_open" number="240"/>
- <syscall name="mq_unlink" number="241"/>
- <syscall name="mq_timedsend" number="242"/>
- <syscall name="mq_timedreceive" number="243"/>
- <syscall name="mq_notify" number="244"/>
- <syscall name="mq_getsetattr" number="245"/>
- <syscall name="kexec_load" number="246"/>
- <syscall name="waitid" number="247"/>
- <syscall name="add_key" number="248"/>
- <syscall name="request_key" number="249"/>
- <syscall name="keyctl" number="250"/>
- <syscall name="ioprio_set" number="251"/>
- <syscall name="ioprio_get" number="252"/>
- <syscall name="inotify_init" number="253"/>
- <syscall name="inotify_add_watch" number="254"/>
- <syscall name="inotify_rm_watch" number="255"/>
- <syscall name="migrate_pages" number="256"/>
- <syscall name="openat" number="257"/>
- <syscall name="mkdirat" number="258"/>
- <syscall name="mknodat" number="259"/>
- <syscall name="fchownat" number="260"/>
- <syscall name="futimesat" number="261"/>
- <syscall name="newfstatat" number="262"/>
- <syscall name="unlinkat" number="263"/>
- <syscall name="renameat" number="264"/>
- <syscall name="linkat" number="265"/>
- <syscall name="symlinkat" number="266"/>
- <syscall name="readlinkat" number="267"/>
- <syscall name="fchmodat" number="268"/>
- <syscall name="faccessat" number="269"/>
- <syscall name="pselect6" number="270"/>
- <syscall name="ppoll" number="271"/>
- <syscall name="unshare" number="272"/>
- <syscall name="set_robust_list" number="273"/>
- <syscall name="get_robust_list" number="274"/>
- <syscall name="splice" number="275"/>
- <syscall name="tee" number="276"/>
- <syscall name="sync_file_range" number="277"/>
- <syscall name="vmsplice" number="278"/>
- <syscall name="move_pages" number="279"/>
- <syscall name="utimensat" number="280"/>
- <syscall name="epoll_pwait" number="281"/>
- <syscall name="signalfd" number="282"/>
- <syscall name="timerfd_create" number="283"/>
- <syscall name="eventfd" number="284"/>
- <syscall name="fallocate" number="285"/>
- <syscall name="timerfd_settime" number="286"/>
- <syscall name="timerfd_gettime" number="287"/>
- <syscall name="accept4" number="288"/>
- <syscall name="signalfd4" number="289"/>
- <syscall name="eventfd2" number="290"/>
- <syscall name="epoll_create1" number="291"/>
- <syscall name="dup3" number="292"/>
- <syscall name="pipe2" number="293"/>
- <syscall name="inotify_init1" number="294"/>
- <syscall name="preadv" number="295"/>
- <syscall name="pwritev" number="296"/>
-</syscalls_info>
diff --git a/share/gdb/syscalls/gdb-syscalls.dtd b/share/gdb/syscalls/gdb-syscalls.dtd
deleted file mode 100644
index 0735ecd..0000000
--- a/share/gdb/syscalls/gdb-syscalls.dtd
+++ /dev/null
@@ -1,14 +0,0 @@
-<!-- Copyright (C) 2009, 2011 Free Software Foundation, Inc.
-
- Copying and distribution of this file, with or without modification,
- are permitted in any medium without royalty provided the copyright
- notice and this notice are preserved. -->
-
-<!-- The root element of a syscall info is <syscalls-info>. -->
-
-<!ELEMENT syscalls-info (syscall*)>
-
-<!ELEMENT syscall EMPTY>
-<!ATTLIST syscall
- name CDATA #REQUIRED
- number CDATA #REQUIRED>
diff --git a/share/gdb/syscalls/i386-linux.xml b/share/gdb/syscalls/i386-linux.xml
deleted file mode 100644
index 3cb1251..0000000
--- a/share/gdb/syscalls/i386-linux.xml
+++ /dev/null
@@ -1,340 +0,0 @@
-<?xml version="1.0"?>
-<!-- Copyright (C) 2009, 2011 Free Software Foundation, Inc.
-
- Copying and distribution of this file, with or without modification,
- are permitted in any medium without royalty provided the copyright
- notice and this notice are preserved. -->
-
-<!DOCTYPE feature SYSTEM "gdb-syscalls.dtd">
-
-<!-- This file was generated using the following file:
-
- /usr/src/linux/arch/x86/include/asm/unistd_32.h
-
- The file mentioned above belongs to the Linux Kernel. -->
-
-<syscalls_info>
- <syscall name="restart_syscall" number="0"/>
- <syscall name="exit" number="1"/>
- <syscall name="fork" number="2"/>
- <syscall name="read" number="3"/>
- <syscall name="write" number="4"/>
- <syscall name="open" number="5"/>
- <syscall name="close" number="6"/>
- <syscall name="waitpid" number="7"/>
- <syscall name="creat" number="8"/>
- <syscall name="link" number="9"/>
- <syscall name="unlink" number="10"/>
- <syscall name="execve" number="11"/>
- <syscall name="chdir" number="12"/>
- <syscall name="time" number="13"/>
- <syscall name="mknod" number="14"/>
- <syscall name="chmod" number="15"/>
- <syscall name="lchown" number="16"/>
- <syscall name="break" number="17"/>
- <syscall name="oldstat" number="18"/>
- <syscall name="lseek" number="19"/>
- <syscall name="getpid" number="20"/>
- <syscall name="mount" number="21"/>
- <syscall name="umount" number="22"/>
- <syscall name="setuid" number="23"/>
- <syscall name="getuid" number="24"/>
- <syscall name="stime" number="25"/>
- <syscall name="ptrace" number="26"/>
- <syscall name="alarm" number="27"/>
- <syscall name="oldfstat" number="28"/>
- <syscall name="pause" number="29"/>
- <syscall name="utime" number="30"/>
- <syscall name="stty" number="31"/>
- <syscall name="gtty" number="32"/>
- <syscall name="access" number="33"/>
- <syscall name="nice" number="34"/>
- <syscall name="ftime" number="35"/>
- <syscall name="sync" number="36"/>
- <syscall name="kill" number="37"/>
- <syscall name="rename" number="38"/>
- <syscall name="mkdir" number="39"/>
- <syscall name="rmdir" number="40"/>
- <syscall name="dup" number="41"/>
- <syscall name="pipe" number="42"/>
- <syscall name="times" number="43"/>
- <syscall name="prof" number="44"/>
- <syscall name="brk" number="45"/>
- <syscall name="setgid" number="46"/>
- <syscall name="getgid" number="47"/>
- <syscall name="signal" number="48"/>
- <syscall name="geteuid" number="49"/>
- <syscall name="getegid" number="50"/>
- <syscall name="acct" number="51"/>
- <syscall name="umount2" number="52"/>
- <syscall name="lock" number="53"/>
- <syscall name="ioctl" number="54"/>
- <syscall name="fcntl" number="55"/>
- <syscall name="mpx" number="56"/>
- <syscall name="setpgid" number="57"/>
- <syscall name="ulimit" number="58"/>
- <syscall name="oldolduname" number="59"/>
- <syscall name="umask" number="60"/>
- <syscall name="chroot" number="61"/>
- <syscall name="ustat" number="62"/>
- <syscall name="dup2" number="63"/>
- <syscall name="getppid" number="64"/>
- <syscall name="getpgrp" number="65"/>
- <syscall name="setsid" number="66"/>
- <syscall name="sigaction" number="67"/>
- <syscall name="sgetmask" number="68"/>
- <syscall name="ssetmask" number="69"/>
- <syscall name="setreuid" number="70"/>
- <syscall name="setregid" number="71"/>
- <syscall name="sigsuspend" number="72"/>
- <syscall name="sigpending" number="73"/>
- <syscall name="sethostname" number="74"/>
- <syscall name="setrlimit" number="75"/>
- <syscall name="getrlimit" number="76"/>
- <syscall name="getrusage" number="77"/>
- <syscall name="gettimeofday" number="78"/>
- <syscall name="settimeofday" number="79"/>
- <syscall name="getgroups" number="80"/>
- <syscall name="setgroups" number="81"/>
- <syscall name="select" number="82"/>
- <syscall name="symlink" number="83"/>
- <syscall name="oldlstat" number="84"/>
- <syscall name="readlink" number="85"/>
- <syscall name="uselib" number="86"/>
- <syscall name="swapon" number="87"/>
- <syscall name="reboot" number="88"/>
- <syscall name="readdir" number="89"/>
- <syscall name="mmap" number="90"/>
- <syscall name="munmap" number="91"/>
- <syscall name="truncate" number="92"/>
- <syscall name="ftruncate" number="93"/>
- <syscall name="fchmod" number="94"/>
- <syscall name="fchown" number="95"/>
- <syscall name="getpriority" number="96"/>
- <syscall name="setpriority" number="97"/>
- <syscall name="profil" number="98"/>
- <syscall name="statfs" number="99"/>
- <syscall name="fstatfs" number="100"/>
- <syscall name="ioperm" number="101"/>
- <syscall name="socketcall" number="102"/>
- <syscall name="syslog" number="103"/>
- <syscall name="setitimer" number="104"/>
- <syscall name="getitimer" number="105"/>
- <syscall name="stat" number="106"/>
- <syscall name="lstat" number="107"/>
- <syscall name="fstat" number="108"/>
- <syscall name="olduname" number="109"/>
- <syscall name="iopl" number="110"/>
- <syscall name="vhangup" number="111"/>
- <syscall name="idle" number="112"/>
- <syscall name="vm86old" number="113"/>
- <syscall name="wait4" number="114"/>
- <syscall name="swapoff" number="115"/>
- <syscall name="sysinfo" number="116"/>
- <syscall name="ipc" number="117"/>
- <syscall name="fsync" number="118"/>
- <syscall name="sigreturn" number="119"/>
- <syscall name="clone" number="120"/>
- <syscall name="setdomainname" number="121"/>
- <syscall name="uname" number="122"/>
- <syscall name="modify_ldt" number="123"/>
- <syscall name="adjtimex" number="124"/>
- <syscall name="mprotect" number="125"/>
- <syscall name="sigprocmask" number="126"/>
- <syscall name="create_module" number="127"/>
- <syscall name="init_module" number="128"/>
- <syscall name="delete_module" number="129"/>
- <syscall name="get_kernel_syms" number="130"/>
- <syscall name="quotactl" number="131"/>
- <syscall name="getpgid" number="132"/>
- <syscall name="fchdir" number="133"/>
- <syscall name="bdflush" number="134"/>
- <syscall name="sysfs" number="135"/>
- <syscall name="personality" number="136"/>
- <syscall name="afs_syscall" number="137"/>
- <syscall name="setfsuid" number="138"/>
- <syscall name="setfsgid" number="139"/>
- <syscall name="_llseek" number="140"/>
- <syscall name="getdents" number="141"/>
- <syscall name="_newselect" number="142"/>
- <syscall name="flock" number="143"/>
- <syscall name="msync" number="144"/>
- <syscall name="readv" number="145"/>
- <syscall name="writev" number="146"/>
- <syscall name="getsid" number="147"/>
- <syscall name="fdatasync" number="148"/>
- <syscall name="_sysctl" number="149"/>
- <syscall name="mlock" number="150"/>
- <syscall name="munlock" number="151"/>
- <syscall name="mlockall" number="152"/>
- <syscall name="munlockall" number="153"/>
- <syscall name="sched_setparam" number="154"/>
- <syscall name="sched_getparam" number="155"/>
- <syscall name="sched_setscheduler" number="156"/>
- <syscall name="sched_getscheduler" number="157"/>
- <syscall name="sched_yield" number="158"/>
- <syscall name="sched_get_priority_max" number="159"/>
- <syscall name="sched_get_priority_min" number="160"/>
- <syscall name="sched_rr_get_interval" number="161"/>
- <syscall name="nanosleep" number="162"/>
- <syscall name="mremap" number="163"/>
- <syscall name="setresuid" number="164"/>
- <syscall name="getresuid" number="165"/>
- <syscall name="vm86" number="166"/>
- <syscall name="query_module" number="167"/>
- <syscall name="poll" number="168"/>
- <syscall name="nfsservctl" number="169"/>
- <syscall name="setresgid" number="170"/>
- <syscall name="getresgid" number="171"/>
- <syscall name="prctl" number="172"/>
- <syscall name="rt_sigreturn" number="173"/>
- <syscall name="rt_sigaction" number="174"/>
- <syscall name="rt_sigprocmask" number="175"/>
- <syscall name="rt_sigpending" number="176"/>
- <syscall name="rt_sigtimedwait" number="177"/>
- <syscall name="rt_sigqueueinfo" number="178"/>
- <syscall name="rt_sigsuspend" number="179"/>
- <syscall name="pread64" number="180"/>
- <syscall name="pwrite64" number="181"/>
- <syscall name="chown" number="182"/>
- <syscall name="getcwd" number="183"/>
- <syscall name="capget" number="184"/>
- <syscall name="capset" number="185"/>
- <syscall name="sigaltstack" number="186"/>
- <syscall name="sendfile" number="187"/>
- <syscall name="getpmsg" number="188"/>
- <syscall name="putpmsg" number="189"/>
- <syscall name="vfork" number="190"/>
- <syscall name="ugetrlimit" number="191"/>
- <syscall name="mmap2" number="192"/>
- <syscall name="truncate64" number="193"/>
- <syscall name="ftruncate64" number="194"/>
- <syscall name="stat64" number="195"/>
- <syscall name="lstat64" number="196"/>
- <syscall name="fstat64" number="197"/>
- <syscall name="lchown32" number="198"/>
- <syscall name="getuid32" number="199"/>
- <syscall name="getgid32" number="200"/>
- <syscall name="geteuid32" number="201"/>
- <syscall name="getegid32" number="202"/>
- <syscall name="setreuid32" number="203"/>
- <syscall name="setregid32" number="204"/>
- <syscall name="getgroups32" number="205"/>
- <syscall name="setgroups32" number="206"/>
- <syscall name="fchown32" number="207"/>
- <syscall name="setresuid32" number="208"/>
- <syscall name="getresuid32" number="209"/>
- <syscall name="setresgid32" number="210"/>
- <syscall name="getresgid32" number="211"/>
- <syscall name="chown32" number="212"/>
- <syscall name="setuid32" number="213"/>
- <syscall name="setgid32" number="214"/>
- <syscall name="setfsuid32" number="215"/>
- <syscall name="setfsgid32" number="216"/>
- <syscall name="pivot_root" number="217"/>
- <syscall name="mincore" number="218"/>
- <syscall name="madvise" number="219"/>
- <syscall name="madvise1" number="220"/>
- <syscall name="getdents64" number="221"/>
- <syscall name="fcntl64" number="222"/>
- <syscall name="gettid" number="224"/>
- <syscall name="readahead" number="225"/>
- <syscall name="setxattr" number="226"/>
- <syscall name="lsetxattr" number="227"/>
- <syscall name="fsetxattr" number="228"/>
- <syscall name="getxattr" number="229"/>
- <syscall name="lgetxattr" number="230"/>
- <syscall name="fgetxattr" number="231"/>
- <syscall name="listxattr" number="232"/>
- <syscall name="llistxattr" number="233"/>
- <syscall name="flistxattr" number="234"/>
- <syscall name="removexattr" number="235"/>
- <syscall name="lremovexattr" number="236"/>
- <syscall name="fremovexattr" number="237"/>
- <syscall name="tkill" number="238"/>
- <syscall name="sendfile64" number="239"/>
- <syscall name="futex" number="240"/>
- <syscall name="sched_setaffinity" number="241"/>
- <syscall name="sched_getaffinity" number="242"/>
- <syscall name="set_thread_area" number="243"/>
- <syscall name="get_thread_area" number="244"/>
- <syscall name="io_setup" number="245"/>
- <syscall name="io_destroy" number="246"/>
- <syscall name="io_getevents" number="247"/>
- <syscall name="io_submit" number="248"/>
- <syscall name="io_cancel" number="249"/>
- <syscall name="fadvise64" number="250"/>
- <syscall name="exit_group" number="252"/>
- <syscall name="lookup_dcookie" number="253"/>
- <syscall name="epoll_create" number="254"/>
- <syscall name="epoll_ctl" number="255"/>
- <syscall name="epoll_wait" number="256"/>
- <syscall name="remap_file_pages" number="257"/>
- <syscall name="set_tid_address" number="258"/>
- <syscall name="timer_create" number="259"/>
- <syscall name="timer_settime" number="260"/>
- <syscall name="timer_gettime" number="261"/>
- <syscall name="timer_getoverrun" number="262"/>
- <syscall name="timer_delete" number="263"/>
- <syscall name="clock_settime" number="264"/>
- <syscall name="clock_gettime" number="265"/>
- <syscall name="clock_getres" number="266"/>
- <syscall name="clock_nanosleep" number="267"/>
- <syscall name="statfs64" number="268"/>
- <syscall name="fstatfs64" number="269"/>
- <syscall name="tgkill" number="270"/>
- <syscall name="utimes" number="271"/>
- <syscall name="fadvise64_64" number="272"/>
- <syscall name="vserver" number="273"/>
- <syscall name="mbind" number="274"/>
- <syscall name="get_mempolicy" number="275"/>
- <syscall name="set_mempolicy" number="276"/>
- <syscall name="mq_open" number="277"/>
- <syscall name="mq_unlink" number="278"/>
- <syscall name="mq_timedsend" number="279"/>
- <syscall name="mq_timedreceive" number="280"/>
- <syscall name="mq_notify" number="281"/>
- <syscall name="mq_getsetattr" number="282"/>
- <syscall name="kexec_load" number="283"/>
- <syscall name="waitid" number="284"/>
- <syscall name="add_key" number="286"/>
- <syscall name="request_key" number="287"/>
- <syscall name="keyctl" number="288"/>
- <syscall name="ioprio_set" number="289"/>
- <syscall name="ioprio_get" number="290"/>
- <syscall name="inotify_init" number="291"/>
- <syscall name="inotify_add_watch" number="292"/>
- <syscall name="inotify_rm_watch" number="293"/>
- <syscall name="migrate_pages" number="294"/>
- <syscall name="openat" number="295"/>
- <syscall name="mkdirat" number="296"/>
- <syscall name="mknodat" number="297"/>
- <syscall name="fchownat" number="298"/>
- <syscall name="futimesat" number="299"/>
- <syscall name="fstatat64" number="300"/>
- <syscall name="unlinkat" number="301"/>
- <syscall name="renameat" number="302"/>
- <syscall name="linkat" number="303"/>
- <syscall name="symlinkat" number="304"/>
- <syscall name="readlinkat" number="305"/>
- <syscall name="fchmodat" number="306"/>
- <syscall name="faccessat" number="307"/>
- <syscall name="pselect6" number="308"/>
- <syscall name="ppoll" number="309"/>
- <syscall name="unshare" number="310"/>
- <syscall name="set_robust_list" number="311"/>
- <syscall name="get_robust_list" number="312"/>
- <syscall name="splice" number="313"/>
- <syscall name="sync_file_range" number="314"/>
- <syscall name="tee" number="315"/>
- <syscall name="vmsplice" number="316"/>
- <syscall name="move_pages" number="317"/>
- <syscall name="getcpu" number="318"/>
- <syscall name="epoll_pwait" number="319"/>
- <syscall name="utimensat" number="320"/>
- <syscall name="signalfd" number="321"/>
- <syscall name="timerfd_create" number="322"/>
- <syscall name="eventfd" number="323"/>
- <syscall name="fallocate" number="324"/>
- <syscall name="timerfd_settime" number="325"/>
-</syscalls_info>
diff --git a/share/gdb/syscalls/mips-n32-linux.xml b/share/gdb/syscalls/mips-n32-linux.xml
deleted file mode 100644
index da4aba2..0000000
--- a/share/gdb/syscalls/mips-n32-linux.xml
+++ /dev/null
@@ -1,319 +0,0 @@
-<?xml version="1.0"?>
-<!-- Copyright (C) 2011 Free Software Foundation, Inc.
-
- Copying and distribution of this file, with or without modification,
- are permitted in any medium without royalty provided the copyright
- notice and this notice are preserved. -->
-
-<!DOCTYPE feature SYSTEM "gdb-syscalls.dtd">
-
-<!-- This file was generated using the following file:
-
- /usr/src/linux/arch/mips/include/asm/unistd.h
-
- The file mentioned above belongs to the Linux Kernel. -->
-
-<syscalls_info>
- <syscall name="read" number="6000"/>
- <syscall name="write" number="6001"/>
- <syscall name="open" number="6002"/>
- <syscall name="close" number="6003"/>
- <syscall name="stat" number="6004"/>
- <syscall name="fstat" number="6005"/>
- <syscall name="lstat" number="6006"/>
- <syscall name="poll" number="6007"/>
- <syscall name="lseek" number="6008"/>
- <syscall name="mmap" number="6009"/>
- <syscall name="mprotect" number="6010"/>
- <syscall name="munmap" number="6011"/>
- <syscall name="brk" number="6012"/>
- <syscall name="rt_sigaction" number="6013"/>
- <syscall name="rt_sigprocmask" number="6014"/>
- <syscall name="ioctl" number="6015"/>
- <syscall name="pread64" number="6016"/>
- <syscall name="pwrite64" number="6017"/>
- <syscall name="readv" number="6018"/>
- <syscall name="writev" number="6019"/>
- <syscall name="access" number="6020"/>
- <syscall name="pipe" number="6021"/>
- <syscall name="_newselect" number="6022"/>
- <syscall name="sched_yield" number="6023"/>
- <syscall name="mremap" number="6024"/>
- <syscall name="msync" number="6025"/>
- <syscall name="mincore" number="6026"/>
- <syscall name="madvise" number="6027"/>
- <syscall name="shmget" number="6028"/>
- <syscall name="shmat" number="6029"/>
- <syscall name="shmctl" number="6030"/>
- <syscall name="dup" number="6031"/>
- <syscall name="dup2" number="6032"/>
- <syscall name="pause" number="6033"/>
- <syscall name="nanosleep" number="6034"/>
- <syscall name="getitimer" number="6035"/>
- <syscall name="setitimer" number="6036"/>
- <syscall name="alarm" number="6037"/>
- <syscall name="getpid" number="6038"/>
- <syscall name="sendfile" number="6039"/>
- <syscall name="socket" number="6040"/>
- <syscall name="connect" number="6041"/>
- <syscall name="accept" number="6042"/>
- <syscall name="sendto" number="6043"/>
- <syscall name="recvfrom" number="6044"/>
- <syscall name="sendmsg" number="6045"/>
- <syscall name="recvmsg" number="6046"/>
- <syscall name="shutdown" number="6047"/>
- <syscall name="bind" number="6048"/>
- <syscall name="listen" number="6049"/>
- <syscall name="getsockname" number="6050"/>
- <syscall name="getpeername" number="6051"/>
- <syscall name="socketpair" number="6052"/>
- <syscall name="setsockopt" number="6053"/>
- <syscall name="getsockopt" number="6054"/>
- <syscall name="clone" number="6055"/>
- <syscall name="fork" number="6056"/>
- <syscall name="execve" number="6057"/>
- <syscall name="exit" number="6058"/>
- <syscall name="wait4" number="6059"/>
- <syscall name="kill" number="6060"/>
- <syscall name="uname" number="6061"/>
- <syscall name="semget" number="6062"/>
- <syscall name="semop" number="6063"/>
- <syscall name="semctl" number="6064"/>
- <syscall name="shmdt" number="6065"/>
- <syscall name="msgget" number="6066"/>
- <syscall name="msgsnd" number="6067"/>
- <syscall name="msgrcv" number="6068"/>
- <syscall name="msgctl" number="6069"/>
- <syscall name="fcntl" number="6070"/>
- <syscall name="flock" number="6071"/>
- <syscall name="fsync" number="6072"/>
- <syscall name="fdatasync" number="6073"/>
- <syscall name="truncate" number="6074"/>
- <syscall name="ftruncate" number="6075"/>
- <syscall name="getdents" number="6076"/>
- <syscall name="getcwd" number="6077"/>
- <syscall name="chdir" number="6078"/>
- <syscall name="fchdir" number="6079"/>
- <syscall name="rename" number="6080"/>
- <syscall name="mkdir" number="6081"/>
- <syscall name="rmdir" number="6082"/>
- <syscall name="creat" number="6083"/>
- <syscall name="link" number="6084"/>
- <syscall name="unlink" number="6085"/>
- <syscall name="symlink" number="6086"/>
- <syscall name="readlink" number="6087"/>
- <syscall name="chmod" number="6088"/>
- <syscall name="fchmod" number="6089"/>
- <syscall name="chown" number="6090"/>
- <syscall name="fchown" number="6091"/>
- <syscall name="lchown" number="6092"/>
- <syscall name="umask" number="6093"/>
- <syscall name="gettimeofday" number="6094"/>
- <syscall name="getrlimit" number="6095"/>
- <syscall name="getrusage" number="6096"/>
- <syscall name="sysinfo" number="6097"/>
- <syscall name="times" number="6098"/>
- <syscall name="ptrace" number="6099"/>
- <syscall name="getuid" number="6100"/>
- <syscall name="syslog" number="6101"/>
- <syscall name="getgid" number="6102"/>
- <syscall name="setuid" number="6103"/>
- <syscall name="setgid" number="6104"/>
- <syscall name="geteuid" number="6105"/>
- <syscall name="getegid" number="6106"/>
- <syscall name="setpgid" number="6107"/>
- <syscall name="getppid" number="6108"/>
- <syscall name="getpgrp" number="6109"/>
- <syscall name="setsid" number="6110"/>
- <syscall name="setreuid" number="6111"/>
- <syscall name="setregid" number="6112"/>
- <syscall name="getgroups" number="6113"/>
- <syscall name="setgroups" number="6114"/>
- <syscall name="setresuid" number="6115"/>
- <syscall name="getresuid" number="6116"/>
- <syscall name="setresgid" number="6117"/>
- <syscall name="getresgid" number="6118"/>
- <syscall name="getpgid" number="6119"/>
- <syscall name="setfsuid" number="6120"/>
- <syscall name="setfsgid" number="6121"/>
- <syscall name="getsid" number="6122"/>
- <syscall name="capget" number="6123"/>
- <syscall name="capset" number="6124"/>
- <syscall name="rt_sigpending" number="6125"/>
- <syscall name="rt_sigtimedwait" number="6126"/>
- <syscall name="rt_sigqueueinfo" number="6127"/>
- <syscall name="rt_sigsuspend" number="6128"/>
- <syscall name="sigaltstack" number="6129"/>
- <syscall name="utime" number="6130"/>
- <syscall name="mknod" number="6131"/>
- <syscall name="personality" number="6132"/>
- <syscall name="ustat" number="6133"/>
- <syscall name="statfs" number="6134"/>
- <syscall name="fstatfs" number="6135"/>
- <syscall name="sysfs" number="6136"/>
- <syscall name="getpriority" number="6137"/>
- <syscall name="setpriority" number="6138"/>
- <syscall name="sched_setparam" number="6139"/>
- <syscall name="sched_getparam" number="6140"/>
- <syscall name="sched_setscheduler" number="6141"/>
- <syscall name="sched_getscheduler" number="6142"/>
- <syscall name="sched_get_priority_max" number="6143"/>
- <syscall name="sched_get_priority_min" number="6144"/>
- <syscall name="sched_rr_get_interval" number="6145"/>
- <syscall name="mlock" number="6146"/>
- <syscall name="munlock" number="6147"/>
- <syscall name="mlockall" number="6148"/>
- <syscall name="munlockall" number="6149"/>
- <syscall name="vhangup" number="6150"/>
- <syscall name="pivot_root" number="6151"/>
- <syscall name="_sysctl" number="6152"/>
- <syscall name="prctl" number="6153"/>
- <syscall name="adjtimex" number="6154"/>
- <syscall name="setrlimit" number="6155"/>
- <syscall name="chroot" number="6156"/>
- <syscall name="sync" number="6157"/>
- <syscall name="acct" number="6158"/>
- <syscall name="settimeofday" number="6159"/>
- <syscall name="mount" number="6160"/>
- <syscall name="umount2" number="6161"/>
- <syscall name="swapon" number="6162"/>
- <syscall name="swapoff" number="6163"/>
- <syscall name="reboot" number="6164"/>
- <syscall name="sethostname" number="6165"/>
- <syscall name="setdomainname" number="6166"/>
- <syscall name="create_module" number="6167"/>
- <syscall name="init_module" number="6168"/>
- <syscall name="delete_module" number="6169"/>
- <syscall name="get_kernel_syms" number="6170"/>
- <syscall name="query_module" number="6171"/>
- <syscall name="quotactl" number="6172"/>
- <syscall name="nfsservctl" number="6173"/>
- <syscall name="getpmsg" number="6174"/>
- <syscall name="putpmsg" number="6175"/>
- <syscall name="afs_syscall" number="6176"/>
- <syscall name="reserved177" number="6177"/>
- <syscall name="gettid" number="6178"/>
- <syscall name="readahead" number="6179"/>
- <syscall name="setxattr" number="6180"/>
- <syscall name="lsetxattr" number="6181"/>
- <syscall name="fsetxattr" number="6182"/>
- <syscall name="getxattr" number="6183"/>
- <syscall name="lgetxattr" number="6184"/>
- <syscall name="fgetxattr" number="6185"/>
- <syscall name="listxattr" number="6186"/>
- <syscall name="llistxattr" number="6187"/>
- <syscall name="flistxattr" number="6188"/>
- <syscall name="removexattr" number="6189"/>
- <syscall name="lremovexattr" number="6190"/>
- <syscall name="fremovexattr" number="6191"/>
- <syscall name="tkill" number="6192"/>
- <syscall name="reserved193" number="6193"/>
- <syscall name="futex" number="6194"/>
- <syscall name="sched_setaffinity" number="6195"/>
- <syscall name="sched_getaffinity" number="6196"/>
- <syscall name="cacheflush" number="6197"/>
- <syscall name="cachectl" number="6198"/>
- <syscall name="sysmips" number="6199"/>
- <syscall name="io_setup" number="6200"/>
- <syscall name="io_destroy" number="6201"/>
- <syscall name="io_getevents" number="6202"/>
- <syscall name="io_submit" number="6203"/>
- <syscall name="io_cancel" number="6204"/>
- <syscall name="exit_group" number="6205"/>
- <syscall name="lookup_dcookie" number="6206"/>
- <syscall name="epoll_create" number="6207"/>
- <syscall name="epoll_ctl" number="6208"/>
- <syscall name="epoll_wait" number="6209"/>
- <syscall name="remap_file_pages" number="6210"/>
- <syscall name="rt_sigreturn" number="6211"/>
- <syscall name="fcntl64" number="6212"/>
- <syscall name="set_tid_address" number="6213"/>
- <syscall name="restart_syscall" number="6214"/>
- <syscall name="semtimedop" number="6215"/>
- <syscall name="fadvise64" number="6216"/>
- <syscall name="statfs64" number="6217"/>
- <syscall name="fstatfs64" number="6218"/>
- <syscall name="sendfile64" number="6219"/>
- <syscall name="timer_create" number="6220"/>
- <syscall name="timer_settime" number="6221"/>
- <syscall name="timer_gettime" number="6222"/>
- <syscall name="timer_getoverrun" number="6223"/>
- <syscall name="timer_delete" number="6224"/>
- <syscall name="clock_settime" number="6225"/>
- <syscall name="clock_gettime" number="6226"/>
- <syscall name="clock_getres" number="6227"/>
- <syscall name="clock_nanosleep" number="6228"/>
- <syscall name="tgkill" number="6229"/>
- <syscall name="utimes" number="6230"/>
- <syscall name="mbind" number="6231"/>
- <syscall name="get_mempolicy" number="6232"/>
- <syscall name="set_mempolicy" number="6233"/>
- <syscall name="mq_open" number="6234"/>
- <syscall name="mq_unlink" number="6235"/>
- <syscall name="mq_timedsend" number="6236"/>
- <syscall name="mq_timedreceive" number="6237"/>
- <syscall name="mq_notify" number="6238"/>
- <syscall name="mq_getsetattr" number="6239"/>
- <syscall name="vserver" number="6240"/>
- <syscall name="waitid" number="6241"/>
- <syscall name="add_key" number="6243"/>
- <syscall name="request_key" number="6244"/>
- <syscall name="keyctl" number="6245"/>
- <syscall name="set_thread_area" number="6246"/>
- <syscall name="inotify_init" number="6247"/>
- <syscall name="inotify_add_watch" number="6248"/>
- <syscall name="inotify_rm_watch" number="6249"/>
- <syscall name="migrate_pages" number="6250"/>
- <syscall name="openat" number="6251"/>
- <syscall name="mkdirat" number="6252"/>
- <syscall name="mknodat" number="6253"/>
- <syscall name="fchownat" number="6254"/>
- <syscall name="futimesat" number="6255"/>
- <syscall name="newfstatat" number="6256"/>
- <syscall name="unlinkat" number="6257"/>
- <syscall name="renameat" number="6258"/>
- <syscall name="linkat" number="6259"/>
- <syscall name="symlinkat" number="6260"/>
- <syscall name="readlinkat" number="6261"/>
- <syscall name="fchmodat" number="6262"/>
- <syscall name="faccessat" number="6263"/>
- <syscall name="pselect6" number="6264"/>
- <syscall name="ppoll" number="6265"/>
- <syscall name="unshare" number="6266"/>
- <syscall name="splice" number="6267"/>
- <syscall name="sync_file_range" number="6268"/>
- <syscall name="tee" number="6269"/>
- <syscall name="vmsplice" number="6270"/>
- <syscall name="move_pages" number="6271"/>
- <syscall name="set_robust_list" number="6272"/>
- <syscall name="get_robust_list" number="6273"/>
- <syscall name="kexec_load" number="6274"/>
- <syscall name="getcpu" number="6275"/>
- <syscall name="epoll_pwait" number="6276"/>
- <syscall name="ioprio_set" number="6277"/>
- <syscall name="ioprio_get" number="6278"/>
- <syscall name="utimensat" number="6279"/>
- <syscall name="signalfd" number="6280"/>
- <syscall name="timerfd" number="6281"/>
- <syscall name="eventfd" number="6282"/>
- <syscall name="fallocate" number="6283"/>
- <syscall name="timerfd_create" number="6284"/>
- <syscall name="timerfd_gettime" number="6285"/>
- <syscall name="timerfd_settime" number="6286"/>
- <syscall name="signalfd4" number="6287"/>
- <syscall name="eventfd2" number="6288"/>
- <syscall name="epoll_create1" number="6289"/>
- <syscall name="dup3" number="6290"/>
- <syscall name="pipe2" number="6291"/>
- <syscall name="inotify_init1" number="6292"/>
- <syscall name="preadv" number="6293"/>
- <syscall name="pwritev" number="6294"/>
- <syscall name="rt_tgsigqueueinfo" number="6295"/>
- <syscall name="perf_event_open" number="6296"/>
- <syscall name="accept4" number="6297"/>
- <syscall name="recvmmsg" number="6298"/>
- <syscall name="getdents64" number="6299"/>
- <syscall name="fanotify_init" number="6300"/>
- <syscall name="fanotify_mark" number="6301"/>
- <syscall name="prlimit64" number="6302"/>
-</syscalls_info>
diff --git a/share/gdb/syscalls/mips-n64-linux.xml b/share/gdb/syscalls/mips-n64-linux.xml
deleted file mode 100644
index fc951c8..0000000
--- a/share/gdb/syscalls/mips-n64-linux.xml
+++ /dev/null
@@ -1,312 +0,0 @@
-<?xml version="1.0"?>
-<!-- Copyright (C) 2011 Free Software Foundation, Inc.
-
- Copying and distribution of this file, with or without modification,
- are permitted in any medium without royalty provided the copyright
- notice and this notice are preserved. -->
-
-<!DOCTYPE feature SYSTEM "gdb-syscalls.dtd">
-
-<!-- This file was generated using the following file:
-
- /usr/src/linux/arch/mips/include/asm/unistd.h
-
- The file mentioned above belongs to the Linux Kernel. -->
-
-<syscalls_info>
- <syscall name="read" number="5000"/>
- <syscall name="write" number="5001"/>
- <syscall name="open" number="5002"/>
- <syscall name="close" number="5003"/>
- <syscall name="stat" number="5004"/>
- <syscall name="fstat" number="5005"/>
- <syscall name="lstat" number="5006"/>
- <syscall name="poll" number="5007"/>
- <syscall name="lseek" number="5008"/>
- <syscall name="mmap" number="5009"/>
- <syscall name="mprotect" number="5010"/>
- <syscall name="munmap" number="5011"/>
- <syscall name="brk" number="5012"/>
- <syscall name="rt_sigaction" number="5013"/>
- <syscall name="rt_sigprocmask" number="5014"/>
- <syscall name="ioctl" number="5015"/>
- <syscall name="pread64" number="5016"/>
- <syscall name="pwrite64" number="5017"/>
- <syscall name="readv" number="5018"/>
- <syscall name="writev" number="5019"/>
- <syscall name="access" number="5020"/>
- <syscall name="pipe" number="5021"/>
- <syscall name="_newselect" number="5022"/>
- <syscall name="sched_yield" number="5023"/>
- <syscall name="mremap" number="5024"/>
- <syscall name="msync" number="5025"/>
- <syscall name="mincore" number="5026"/>
- <syscall name="madvise" number="5027"/>
- <syscall name="shmget" number="5028"/>
- <syscall name="shmat" number="5029"/>
- <syscall name="shmctl" number="5030"/>
- <syscall name="dup" number="5031"/>
- <syscall name="dup2" number="5032"/>
- <syscall name="pause" number="5033"/>
- <syscall name="nanosleep" number="5034"/>
- <syscall name="getitimer" number="5035"/>
- <syscall name="setitimer" number="5036"/>
- <syscall name="alarm" number="5037"/>
- <syscall name="getpid" number="5038"/>
- <syscall name="sendfile" number="5039"/>
- <syscall name="socket" number="5040"/>
- <syscall name="connect" number="5041"/>
- <syscall name="accept" number="5042"/>
- <syscall name="sendto" number="5043"/>
- <syscall name="recvfrom" number="5044"/>
- <syscall name="sendmsg" number="5045"/>
- <syscall name="recvmsg" number="5046"/>
- <syscall name="shutdown" number="5047"/>
- <syscall name="bind" number="5048"/>
- <syscall name="listen" number="5049"/>
- <syscall name="getsockname" number="5050"/>
- <syscall name="getpeername" number="5051"/>
- <syscall name="socketpair" number="5052"/>
- <syscall name="setsockopt" number="5053"/>
- <syscall name="getsockopt" number="5054"/>
- <syscall name="clone" number="5055"/>
- <syscall name="fork" number="5056"/>
- <syscall name="execve" number="5057"/>
- <syscall name="exit" number="5058"/>
- <syscall name="wait4" number="5059"/>
- <syscall name="kill" number="5060"/>
- <syscall name="uname" number="5061"/>
- <syscall name="semget" number="5062"/>
- <syscall name="semop" number="5063"/>
- <syscall name="semctl" number="5064"/>
- <syscall name="shmdt" number="5065"/>
- <syscall name="msgget" number="5066"/>
- <syscall name="msgsnd" number="5067"/>
- <syscall name="msgrcv" number="5068"/>
- <syscall name="msgctl" number="5069"/>
- <syscall name="fcntl" number="5070"/>
- <syscall name="flock" number="5071"/>
- <syscall name="fsync" number="5072"/>
- <syscall name="fdatasync" number="5073"/>
- <syscall name="truncate" number="5074"/>
- <syscall name="ftruncate" number="5075"/>
- <syscall name="getdents" number="5076"/>
- <syscall name="getcwd" number="5077"/>
- <syscall name="chdir" number="5078"/>
- <syscall name="fchdir" number="5079"/>
- <syscall name="rename" number="5080"/>
- <syscall name="mkdir" number="5081"/>
- <syscall name="rmdir" number="5082"/>
- <syscall name="creat" number="5083"/>
- <syscall name="link" number="5084"/>
- <syscall name="unlink" number="5085"/>
- <syscall name="symlink" number="5086"/>
- <syscall name="readlink" number="5087"/>
- <syscall name="chmod" number="5088"/>
- <syscall name="fchmod" number="5089"/>
- <syscall name="chown" number="5090"/>
- <syscall name="fchown" number="5091"/>
- <syscall name="lchown" number="5092"/>
- <syscall name="umask" number="5093"/>
- <syscall name="gettimeofday" number="5094"/>
- <syscall name="getrlimit" number="5095"/>
- <syscall name="getrusage" number="5096"/>
- <syscall name="sysinfo" number="5097"/>
- <syscall name="times" number="5098"/>
- <syscall name="ptrace" number="5099"/>
- <syscall name="getuid" number="5100"/>
- <syscall name="syslog" number="5101"/>
- <syscall name="getgid" number="5102"/>
- <syscall name="setuid" number="5103"/>
- <syscall name="setgid" number="5104"/>
- <syscall name="geteuid" number="5105"/>
- <syscall name="getegid" number="5106"/>
- <syscall name="setpgid" number="5107"/>
- <syscall name="getppid" number="5108"/>
- <syscall name="getpgrp" number="5109"/>
- <syscall name="setsid" number="5110"/>
- <syscall name="setreuid" number="5111"/>
- <syscall name="setregid" number="5112"/>
- <syscall name="getgroups" number="5113"/>
- <syscall name="setgroups" number="5114"/>
- <syscall name="setresuid" number="5115"/>
- <syscall name="getresuid" number="5116"/>
- <syscall name="setresgid" number="5117"/>
- <syscall name="getresgid" number="5118"/>
- <syscall name="getpgid" number="5119"/>
- <syscall name="setfsuid" number="5120"/>
- <syscall name="setfsgid" number="5121"/>
- <syscall name="getsid" number="5122"/>
- <syscall name="capget" number="5123"/>
- <syscall name="capset" number="5124"/>
- <syscall name="rt_sigpending" number="5125"/>
- <syscall name="rt_sigtimedwait" number="5126"/>
- <syscall name="rt_sigqueueinfo" number="5127"/>
- <syscall name="rt_sigsuspend" number="5128"/>
- <syscall name="sigaltstack" number="5129"/>
- <syscall name="utime" number="5130"/>
- <syscall name="mknod" number="5131"/>
- <syscall name="personality" number="5132"/>
- <syscall name="ustat" number="5133"/>
- <syscall name="statfs" number="5134"/>
- <syscall name="fstatfs" number="5135"/>
- <syscall name="sysfs" number="5136"/>
- <syscall name="getpriority" number="5137"/>
- <syscall name="setpriority" number="5138"/>
- <syscall name="sched_setparam" number="5139"/>
- <syscall name="sched_getparam" number="5140"/>
- <syscall name="sched_setscheduler" number="5141"/>
- <syscall name="sched_getscheduler" number="5142"/>
- <syscall name="sched_get_priority_max" number="5143"/>
- <syscall name="sched_get_priority_min" number="5144"/>
- <syscall name="sched_rr_get_interval" number="5145"/>
- <syscall name="mlock" number="5146"/>
- <syscall name="munlock" number="5147"/>
- <syscall name="mlockall" number="5148"/>
- <syscall name="munlockall" number="5149"/>
- <syscall name="vhangup" number="5150"/>
- <syscall name="pivot_root" number="5151"/>
- <syscall name="_sysctl" number="5152"/>
- <syscall name="prctl" number="5153"/>
- <syscall name="adjtimex" number="5154"/>
- <syscall name="setrlimit" number="5155"/>
- <syscall name="chroot" number="5156"/>
- <syscall name="sync" number="5157"/>
- <syscall name="acct" number="5158"/>
- <syscall name="settimeofday" number="5159"/>
- <syscall name="mount" number="5160"/>
- <syscall name="umount2" number="5161"/>
- <syscall name="swapon" number="5162"/>
- <syscall name="swapoff" number="5163"/>
- <syscall name="reboot" number="5164"/>
- <syscall name="sethostname" number="5165"/>
- <syscall name="setdomainname" number="5166"/>
- <syscall name="create_module" number="5167"/>
- <syscall name="init_module" number="5168"/>
- <syscall name="delete_module" number="5169"/>
- <syscall name="get_kernel_syms" number="5170"/>
- <syscall name="query_module" number="5171"/>
- <syscall name="quotactl" number="5172"/>
- <syscall name="nfsservctl" number="5173"/>
- <syscall name="getpmsg" number="5174"/>
- <syscall name="putpmsg" number="5175"/>
- <syscall name="afs_syscall" number="5176"/>
- <syscall name="gettid" number="5178"/>
- <syscall name="readahead" number="5179"/>
- <syscall name="setxattr" number="5180"/>
- <syscall name="lsetxattr" number="5181"/>
- <syscall name="fsetxattr" number="5182"/>
- <syscall name="getxattr" number="5183"/>
- <syscall name="lgetxattr" number="5184"/>
- <syscall name="fgetxattr" number="5185"/>
- <syscall name="listxattr" number="5186"/>
- <syscall name="llistxattr" number="5187"/>
- <syscall name="flistxattr" number="5188"/>
- <syscall name="removexattr" number="5189"/>
- <syscall name="lremovexattr" number="5190"/>
- <syscall name="fremovexattr" number="5191"/>
- <syscall name="tkill" number="5192"/>
- <syscall name="futex" number="5194"/>
- <syscall name="sched_setaffinity" number="5195"/>
- <syscall name="sched_getaffinity" number="5196"/>
- <syscall name="cacheflush" number="5197"/>
- <syscall name="cachectl" number="5198"/>
- <syscall name="sysmips" number="5199"/>
- <syscall name="io_setup" number="5200"/>
- <syscall name="io_destroy" number="5201"/>
- <syscall name="io_getevents" number="5202"/>
- <syscall name="io_submit" number="5203"/>
- <syscall name="io_cancel" number="5204"/>
- <syscall name="exit_group" number="5205"/>
- <syscall name="lookup_dcookie" number="5206"/>
- <syscall name="epoll_create" number="5207"/>
- <syscall name="epoll_ctl" number="5208"/>
- <syscall name="epoll_wait" number="5209"/>
- <syscall name="remap_file_pages" number="5210"/>
- <syscall name="rt_sigreturn" number="5211"/>
- <syscall name="set_tid_address" number="5212"/>
- <syscall name="restart_syscall" number="5213"/>
- <syscall name="semtimedop" number="5214"/>
- <syscall name="fadvise64" number="5215"/>
- <syscall name="timer_create" number="5216"/>
- <syscall name="timer_settime" number="5217"/>
- <syscall name="timer_gettime" number="5218"/>
- <syscall name="timer_getoverrun" number="5219"/>
- <syscall name="timer_delete" number="5220"/>
- <syscall name="clock_settime" number="5221"/>
- <syscall name="clock_gettime" number="5222"/>
- <syscall name="clock_getres" number="5223"/>
- <syscall name="clock_nanosleep" number="5224"/>
- <syscall name="tgkill" number="5225"/>
- <syscall name="utimes" number="5226"/>
- <syscall name="mbind" number="5227"/>
- <syscall name="get_mempolicy" number="5228"/>
- <syscall name="set_mempolicy" number="5229"/>
- <syscall name="mq_open" number="5230"/>
- <syscall name="mq_unlink" number="5231"/>
- <syscall name="mq_timedsend" number="5232"/>
- <syscall name="mq_timedreceive" number="5233"/>
- <syscall name="mq_notify" number="5234"/>
- <syscall name="mq_getsetattr" number="5235"/>
- <syscall name="vserver" number="5236"/>
- <syscall name="waitid" number="5237"/>
- <syscall name="add_key" number="5239"/>
- <syscall name="request_key" number="5240"/>
- <syscall name="keyctl" number="5241"/>
- <syscall name="set_thread_area" number="5242"/>
- <syscall name="inotify_init" number="5243"/>
- <syscall name="inotify_add_watch" number="5244"/>
- <syscall name="inotify_rm_watch" number="5245"/>
- <syscall name="migrate_pages" number="5246"/>
- <syscall name="openat" number="5247"/>
- <syscall name="mkdirat" number="5248"/>
- <syscall name="mknodat" number="5249"/>
- <syscall name="fchownat" number="5250"/>
- <syscall name="futimesat" number="5251"/>
- <syscall name="newfstatat" number="5252"/>
- <syscall name="unlinkat" number="5253"/>
- <syscall name="renameat" number="5254"/>
- <syscall name="linkat" number="5255"/>
- <syscall name="symlinkat" number="5256"/>
- <syscall name="readlinkat" number="5257"/>
- <syscall name="fchmodat" number="5258"/>
- <syscall name="faccessat" number="5259"/>
- <syscall name="pselect6" number="5260"/>
- <syscall name="ppoll" number="5261"/>
- <syscall name="unshare" number="5262"/>
- <syscall name="splice" number="5263"/>
- <syscall name="sync_file_range" number="5264"/>
- <syscall name="tee" number="5265"/>
- <syscall name="vmsplice" number="5266"/>
- <syscall name="move_pages" number="5267"/>
- <syscall name="set_robust_list" number="5268"/>
- <syscall name="get_robust_list" number="5269"/>
- <syscall name="kexec_load" number="5270"/>
- <syscall name="getcpu" number="5271"/>
- <syscall name="epoll_pwait" number="5272"/>
- <syscall name="ioprio_set" number="5273"/>
- <syscall name="ioprio_get" number="5274"/>
- <syscall name="utimensat" number="5275"/>
- <syscall name="signalfd" number="5276"/>
- <syscall name="timerfd" number="5277"/>
- <syscall name="eventfd" number="5278"/>
- <syscall name="fallocate" number="5279"/>
- <syscall name="timerfd_create" number="5280"/>
- <syscall name="timerfd_gettime" number="5281"/>
- <syscall name="timerfd_settime" number="5282"/>
- <syscall name="signalfd4" number="5283"/>
- <syscall name="eventfd2" number="5284"/>
- <syscall name="epoll_create1" number="5285"/>
- <syscall name="dup3" number="5286"/>
- <syscall name="pipe2" number="5287"/>
- <syscall name="inotify_init1" number="5288"/>
- <syscall name="preadv" number="5289"/>
- <syscall name="pwritev" number="5290"/>
- <syscall name="rt_tgsigqueueinfo" number="5291"/>
- <syscall name="perf_event_open" number="5292"/>
- <syscall name="accept4" number="5293"/>
- <syscall name="recvmmsg" number="5294"/>
- <syscall name="fanotify_init" number="5295"/>
- <syscall name="fanotify_mark" number="5296"/>
- <syscall name="prlimit64" number="5297"/>
-</syscalls_info>
diff --git a/share/gdb/syscalls/mips-o32-linux.xml b/share/gdb/syscalls/mips-o32-linux.xml
deleted file mode 100644
index 939ed4e..0000000
--- a/share/gdb/syscalls/mips-o32-linux.xml
+++ /dev/null
@@ -1,347 +0,0 @@
-<?xml version="1.0"?>
-<!-- Copyright (C) 2011 Free Software Foundation, Inc.
-
- Copying and distribution of this file, with or without modification,
- are permitted in any medium without royalty provided the copyright
- notice and this notice are preserved. -->
-
-<!DOCTYPE feature SYSTEM "gdb-syscalls.dtd">
-
-<!-- This file was generated using the following file:
-
- /usr/src/linux/arch/mips/include/asm/unistd.h
-
- The file mentioned above belongs to the Linux Kernel. -->
-
-<syscalls_info>
- <syscall name="syscall" number="4000"/>
- <syscall name="exit" number="4001"/>
- <syscall name="fork" number="4002"/>
- <syscall name="read" number="4003"/>
- <syscall name="write" number="4004"/>
- <syscall name="open" number="4005"/>
- <syscall name="close" number="4006"/>
- <syscall name="waitpid" number="4007"/>
- <syscall name="creat" number="4008"/>
- <syscall name="link" number="4009"/>
- <syscall name="unlink" number="4010"/>
- <syscall name="execve" number="4011"/>
- <syscall name="chdir" number="4012"/>
- <syscall name="time" number="4013"/>
- <syscall name="mknod" number="4014"/>
- <syscall name="chmod" number="4015"/>
- <syscall name="lchown" number="4016"/>
- <syscall name="break" number="4017"/>
- <syscall name="lseek" number="4019"/>
- <syscall name="getpid" number="4020"/>
- <syscall name="mount" number="4021"/>
- <syscall name="umount" number="4022"/>
- <syscall name="setuid" number="4023"/>
- <syscall name="getuid" number="4024"/>
- <syscall name="stime" number="4025"/>
- <syscall name="ptrace" number="4026"/>
- <syscall name="alarm" number="4027"/>
- <syscall name="pause" number="4029"/>
- <syscall name="utime" number="4030"/>
- <syscall name="stty" number="4031"/>
- <syscall name="gtty" number="4032"/>
- <syscall name="access" number="4033"/>
- <syscall name="nice" number="4034"/>
- <syscall name="ftime" number="4035"/>
- <syscall name="sync" number="4036"/>
- <syscall name="kill" number="4037"/>
- <syscall name="rename" number="4038"/>
- <syscall name="mkdir" number="4039"/>
- <syscall name="rmdir" number="4040"/>
- <syscall name="dup" number="4041"/>
- <syscall name="pipe" number="4042"/>
- <syscall name="times" number="4043"/>
- <syscall name="prof" number="4044"/>
- <syscall name="brk" number="4045"/>
- <syscall name="setgid" number="4046"/>
- <syscall name="getgid" number="4047"/>
- <syscall name="signal" number="4048"/>
- <syscall name="geteuid" number="4049"/>
- <syscall name="getegid" number="4050"/>
- <syscall name="acct" number="4051"/>
- <syscall name="umount2" number="4052"/>
- <syscall name="lock" number="4053"/>
- <syscall name="ioctl" number="4054"/>
- <syscall name="fcntl" number="4055"/>
- <syscall name="mpx" number="4056"/>
- <syscall name="setpgid" number="4057"/>
- <syscall name="ulimit" number="4058"/>
- <syscall name="umask" number="4060"/>
- <syscall name="chroot" number="4061"/>
- <syscall name="ustat" number="4062"/>
- <syscall name="dup2" number="4063"/>
- <syscall name="getppid" number="4064"/>
- <syscall name="getpgrp" number="4065"/>
- <syscall name="setsid" number="4066"/>
- <syscall name="sigaction" number="4067"/>
- <syscall name="sgetmask" number="4068"/>
- <syscall name="ssetmask" number="4069"/>
- <syscall name="setreuid" number="4070"/>
- <syscall name="setregid" number="4071"/>
- <syscall name="sigsuspend" number="4072"/>
- <syscall name="sigpending" number="4073"/>
- <syscall name="sethostname" number="4074"/>
- <syscall name="setrlimit" number="4075"/>
- <syscall name="getrlimit" number="4076"/>
- <syscall name="getrusage" number="4077"/>
- <syscall name="gettimeofday" number="4078"/>
- <syscall name="settimeofday" number="4079"/>
- <syscall name="getgroups" number="4080"/>
- <syscall name="setgroups" number="4081"/>
- <syscall name="symlink" number="4083"/>
- <syscall name="readlink" number="4085"/>
- <syscall name="uselib" number="4086"/>
- <syscall name="swapon" number="4087"/>
- <syscall name="reboot" number="4088"/>
- <syscall name="readdir" number="4089"/>
- <syscall name="mmap" number="4090"/>
- <syscall name="munmap" number="4091"/>
- <syscall name="truncate" number="4092"/>
- <syscall name="ftruncate" number="4093"/>
- <syscall name="fchmod" number="4094"/>
- <syscall name="fchown" number="4095"/>
- <syscall name="getpriority" number="4096"/>
- <syscall name="setpriority" number="4097"/>
- <syscall name="profil" number="4098"/>
- <syscall name="statfs" number="4099"/>
- <syscall name="fstatfs" number="4100"/>
- <syscall name="ioperm" number="4101"/>
- <syscall name="socketcall" number="4102"/>
- <syscall name="syslog" number="4103"/>
- <syscall name="setitimer" number="4104"/>
- <syscall name="getitimer" number="4105"/>
- <syscall name="stat" number="4106"/>
- <syscall name="lstat" number="4107"/>
- <syscall name="fstat" number="4108"/>
- <syscall name="iopl" number="4110"/>
- <syscall name="vhangup" number="4111"/>
- <syscall name="idle" number="4112"/>
- <syscall name="vm86" number="4113"/>
- <syscall name="wait4" number="4114"/>
- <syscall name="swapoff" number="4115"/>
- <syscall name="sysinfo" number="4116"/>
- <syscall name="ipc" number="4117"/>
- <syscall name="fsync" number="4118"/>
- <syscall name="sigreturn" number="4119"/>
- <syscall name="clone" number="4120"/>
- <syscall name="setdomainname" number="4121"/>
- <syscall name="uname" number="4122"/>
- <syscall name="modify_ldt" number="4123"/>
- <syscall name="adjtimex" number="4124"/>
- <syscall name="mprotect" number="4125"/>
- <syscall name="sigprocmask" number="4126"/>
- <syscall name="create_module" number="4127"/>
- <syscall name="init_module" number="4128"/>
- <syscall name="delete_module" number="4129"/>
- <syscall name="get_kernel_syms" number="4130"/>
- <syscall name="quotactl" number="4131"/>
- <syscall name="getpgid" number="4132"/>
- <syscall name="fchdir" number="4133"/>
- <syscall name="bdflush" number="4134"/>
- <syscall name="sysfs" number="4135"/>
- <syscall name="personality" number="4136"/>
- <syscall name="afs_syscall" number="4137"/>
- <syscall name="setfsuid" number="4138"/>
- <syscall name="setfsgid" number="4139"/>
- <syscall name="_llseek" number="4140"/>
- <syscall name="getdents" number="4141"/>
- <syscall name="_newselect" number="4142"/>
- <syscall name="flock" number="4143"/>
- <syscall name="msync" number="4144"/>
- <syscall name="readv" number="4145"/>
- <syscall name="writev" number="4146"/>
- <syscall name="cacheflush" number="4147"/>
- <syscall name="cachectl" number="4148"/>
- <syscall name="sysmips" number="4149"/>
- <syscall name="getsid" number="4151"/>
- <syscall name="fdatasync" number="4152"/>
- <syscall name="_sysctl" number="4153"/>
- <syscall name="mlock" number="4154"/>
- <syscall name="munlock" number="4155"/>
- <syscall name="mlockall" number="4156"/>
- <syscall name="munlockall" number="4157"/>
- <syscall name="sched_setparam" number="4158"/>
- <syscall name="sched_getparam" number="4159"/>
- <syscall name="sched_setscheduler" number="4160"/>
- <syscall name="sched_getscheduler" number="4161"/>
- <syscall name="sched_yield" number="4162"/>
- <syscall name="sched_get_priority_max" number="4163"/>
- <syscall name="sched_get_priority_min" number="4164"/>
- <syscall name="sched_rr_get_interval" number="4165"/>
- <syscall name="nanosleep" number="4166"/>
- <syscall name="mremap" number="4167"/>
- <syscall name="accept" number="4168"/>
- <syscall name="bind" number="4169"/>
- <syscall name="connect" number="4170"/>
- <syscall name="getpeername" number="4171"/>
- <syscall name="getsockname" number="4172"/>
- <syscall name="getsockopt" number="4173"/>
- <syscall name="listen" number="4174"/>
- <syscall name="recv" number="4175"/>
- <syscall name="recvfrom" number="4176"/>
- <syscall name="recvmsg" number="4177"/>
- <syscall name="send" number="4178"/>
- <syscall name="sendmsg" number="4179"/>
- <syscall name="sendto" number="4180"/>
- <syscall name="setsockopt" number="4181"/>
- <syscall name="shutdown" number="4182"/>
- <syscall name="socket" number="4183"/>
- <syscall name="socketpair" number="4184"/>
- <syscall name="setresuid" number="4185"/>
- <syscall name="getresuid" number="4186"/>
- <syscall name="query_module" number="4187"/>
- <syscall name="poll" number="4188"/>
- <syscall name="nfsservctl" number="4189"/>
- <syscall name="setresgid" number="4190"/>
- <syscall name="getresgid" number="4191"/>
- <syscall name="prctl" number="4192"/>
- <syscall name="rt_sigreturn" number="4193"/>
- <syscall name="rt_sigaction" number="4194"/>
- <syscall name="rt_sigprocmask" number="4195"/>
- <syscall name="rt_sigpending" number="4196"/>
- <syscall name="rt_sigtimedwait" number="4197"/>
- <syscall name="rt_sigqueueinfo" number="4198"/>
- <syscall name="rt_sigsuspend" number="4199"/>
- <syscall name="pread64" number="4200"/>
- <syscall name="pwrite64" number="4201"/>
- <syscall name="chown" number="4202"/>
- <syscall name="getcwd" number="4203"/>
- <syscall name="capget" number="4204"/>
- <syscall name="capset" number="4205"/>
- <syscall name="sigaltstack" number="4206"/>
- <syscall name="sendfile" number="4207"/>
- <syscall name="getpmsg" number="4208"/>
- <syscall name="putpmsg" number="4209"/>
- <syscall name="mmap2" number="4210"/>
- <syscall name="truncate64" number="4211"/>
- <syscall name="ftruncate64" number="4212"/>
- <syscall name="stat64" number="4213"/>
- <syscall name="lstat64" number="4214"/>
- <syscall name="fstat64" number="4215"/>
- <syscall name="pivot_root" number="4216"/>
- <syscall name="mincore" number="4217"/>
- <syscall name="madvise" number="4218"/>
- <syscall name="getdents64" number="4219"/>
- <syscall name="fcntl64" number="4220"/>
- <syscall name="gettid" number="4222"/>
- <syscall name="readahead" number="4223"/>
- <syscall name="setxattr" number="4224"/>
- <syscall name="lsetxattr" number="4225"/>
- <syscall name="fsetxattr" number="4226"/>
- <syscall name="getxattr" number="4227"/>
- <syscall name="lgetxattr" number="4228"/>
- <syscall name="fgetxattr" number="4229"/>
- <syscall name="listxattr" number="4230"/>
- <syscall name="llistxattr" number="4231"/>
- <syscall name="flistxattr" number="4232"/>
- <syscall name="removexattr" number="4233"/>
- <syscall name="lremovexattr" number="4234"/>
- <syscall name="fremovexattr" number="4235"/>
- <syscall name="tkill" number="4236"/>
- <syscall name="sendfile64" number="4237"/>
- <syscall name="futex" number="4238"/>
- <syscall name="sched_setaffinity" number="4239"/>
- <syscall name="sched_getaffinity" number="4240"/>
- <syscall name="io_setup" number="4241"/>
- <syscall name="io_destroy" number="4242"/>
- <syscall name="io_getevents" number="4243"/>
- <syscall name="io_submit" number="4244"/>
- <syscall name="io_cancel" number="4245"/>
- <syscall name="exit_group" number="4246"/>
- <syscall name="lookup_dcookie" number="4247"/>
- <syscall name="epoll_create" number="4248"/>
- <syscall name="epoll_ctl" number="4249"/>
- <syscall name="epoll_wait" number="4250"/>
- <syscall name="remap_file_pages" number="4251"/>
- <syscall name="set_tid_address" number="4252"/>
- <syscall name="restart_syscall" number="4253"/>
- <syscall name="fadvise64" number="4254"/>
- <syscall name="statfs64" number="4255"/>
- <syscall name="fstatfs64" number="4256"/>
- <syscall name="timer_create" number="4257"/>
- <syscall name="timer_settime" number="4258"/>
- <syscall name="timer_gettime" number="4259"/>
- <syscall name="timer_getoverrun" number="4260"/>
- <syscall name="timer_delete" number="4261"/>
- <syscall name="clock_settime" number="4262"/>
- <syscall name="clock_gettime" number="4263"/>
- <syscall name="clock_getres" number="4264"/>
- <syscall name="clock_nanosleep" number="4265"/>
- <syscall name="tgkill" number="4266"/>
- <syscall name="utimes" number="4267"/>
- <syscall name="mbind" number="4268"/>
- <syscall name="get_mempolicy" number="4269"/>
- <syscall name="set_mempolicy" number="4270"/>
- <syscall name="mq_open" number="4271"/>
- <syscall name="mq_unlink" number="4272"/>
- <syscall name="mq_timedsend" number="4273"/>
- <syscall name="mq_timedreceive" number="4274"/>
- <syscall name="mq_notify" number="4275"/>
- <syscall name="mq_getsetattr" number="4276"/>
- <syscall name="vserver" number="4277"/>
- <syscall name="waitid" number="4278"/>
- <syscall name="add_key" number="4280"/>
- <syscall name="request_key" number="4281"/>
- <syscall name="keyctl" number="4282"/>
- <syscall name="set_thread_area" number="4283"/>
- <syscall name="inotify_init" number="4284"/>
- <syscall name="inotify_add_watch" number="4285"/>
- <syscall name="inotify_rm_watch" number="4286"/>
- <syscall name="migrate_pages" number="4287"/>
- <syscall name="openat" number="4288"/>
- <syscall name="mkdirat" number="4289"/>
- <syscall name="mknodat" number="4290"/>
- <syscall name="fchownat" number="4291"/>
- <syscall name="futimesat" number="4292"/>
- <syscall name="fstatat64" number="4293"/>
- <syscall name="unlinkat" number="4294"/>
- <syscall name="renameat" number="4295"/>
- <syscall name="linkat" number="4296"/>
- <syscall name="symlinkat" number="4297"/>
- <syscall name="readlinkat" number="4298"/>
- <syscall name="fchmodat" number="4299"/>
- <syscall name="faccessat" number="4300"/>
- <syscall name="pselect6" number="4301"/>
- <syscall name="ppoll" number="4302"/>
- <syscall name="unshare" number="4303"/>
- <syscall name="splice" number="4304"/>
- <syscall name="sync_file_range" number="4305"/>
- <syscall name="tee" number="4306"/>
- <syscall name="vmsplice" number="4307"/>
- <syscall name="move_pages" number="4308"/>
- <syscall name="set_robust_list" number="4309"/>
- <syscall name="get_robust_list" number="4310"/>
- <syscall name="kexec_load" number="4311"/>
- <syscall name="getcpu" number="4312"/>
- <syscall name="epoll_pwait" number="4313"/>
- <syscall name="ioprio_set" number="4314"/>
- <syscall name="ioprio_get" number="4315"/>
- <syscall name="utimensat" number="4316"/>
- <syscall name="signalfd" number="4317"/>
- <syscall name="timerfd" number="4318"/>
- <syscall name="eventfd" number="4319"/>
- <syscall name="fallocate" number="4320"/>
- <syscall name="timerfd_create" number="4321"/>
- <syscall name="timerfd_gettime" number="4322"/>
- <syscall name="timerfd_settime" number="4323"/>
- <syscall name="signalfd4" number="4324"/>
- <syscall name="eventfd2" number="4325"/>
- <syscall name="epoll_create1" number="4326"/>
- <syscall name="dup3" number="4327"/>
- <syscall name="pipe2" number="4328"/>
- <syscall name="inotify_init1" number="4329"/>
- <syscall name="preadv" number="4330"/>
- <syscall name="pwritev" number="4331"/>
- <syscall name="rt_tgsigqueueinfo" number="4332"/>
- <syscall name="perf_event_open" number="4333"/>
- <syscall name="accept4" number="4334"/>
- <syscall name="recvmmsg" number="4335"/>
- <syscall name="fanotify_init" number="4336"/>
- <syscall name="fanotify_mark" number="4337"/>
- <syscall name="prlimit64" number="4338"/>
-</syscalls_info>
diff --git a/share/gdb/syscalls/ppc-linux.xml b/share/gdb/syscalls/ppc-linux.xml
deleted file mode 100644
index 54728e3..0000000
--- a/share/gdb/syscalls/ppc-linux.xml
+++ /dev/null
@@ -1,310 +0,0 @@
-<?xml version="1.0"?>
-<!-- Copyright (C) 2009, 2011 Free Software Foundation, Inc.
-
- Copying and distribution of this file, with or without modification,
- are permitted in any medium without royalty provided the copyright
- notice and this notice are preserved. -->
-
-<!DOCTYPE feature SYSTEM "gdb-syscalls.dtd">
-
-<!-- This file was generated using the following file:
-
- /usr/src/linux/arch/powerpc/include/asm/unistd.h
-
- The file mentioned above belongs to the Linux Kernel. -->
-
-<syscalls_info>
- <syscall name="restart_syscall" number="0"/>
- <syscall name="exit" number="1"/>
- <syscall name="fork" number="2"/>
- <syscall name="read" number="3"/>
- <syscall name="write" number="4"/>
- <syscall name="open" number="5"/>
- <syscall name="close" number="6"/>
- <syscall name="waitpid" number="7"/>
- <syscall name="creat" number="8"/>
- <syscall name="link" number="9"/>
- <syscall name="unlink" number="10"/>
- <syscall name="execve" number="11"/>
- <syscall name="chdir" number="12"/>
- <syscall name="time" number="13"/>
- <syscall name="mknod" number="14"/>
- <syscall name="chmod" number="15"/>
- <syscall name="lchown" number="16"/>
- <syscall name="break" number="17"/>
- <syscall name="oldstat" number="18"/>
- <syscall name="lseek" number="19"/>
- <syscall name="getpid" number="20"/>
- <syscall name="mount" number="21"/>
- <syscall name="umount" number="22"/>
- <syscall name="setuid" number="23"/>
- <syscall name="getuid" number="24"/>
- <syscall name="stime" number="25"/>
- <syscall name="ptrace" number="26"/>
- <syscall name="alarm" number="27"/>
- <syscall name="oldfstat" number="28"/>
- <syscall name="pause" number="29"/>
- <syscall name="utime" number="30"/>
- <syscall name="stty" number="31"/>
- <syscall name="gtty" number="32"/>
- <syscall name="access" number="33"/>
- <syscall name="nice" number="34"/>
- <syscall name="ftime" number="35"/>
- <syscall name="sync" number="36"/>
- <syscall name="kill" number="37"/>
- <syscall name="rename" number="38"/>
- <syscall name="mkdir" number="39"/>
- <syscall name="rmdir" number="40"/>
- <syscall name="dup" number="41"/>
- <syscall name="pipe" number="42"/>
- <syscall name="times" number="43"/>
- <syscall name="prof" number="44"/>
- <syscall name="brk" number="45"/>
- <syscall name="setgid" number="46"/>
- <syscall name="getgid" number="47"/>
- <syscall name="signal" number="48"/>
- <syscall name="geteuid" number="49"/>
- <syscall name="getegid" number="50"/>
- <syscall name="acct" number="51"/>
- <syscall name="umount2" number="52"/>
- <syscall name="lock" number="53"/>
- <syscall name="ioctl" number="54"/>
- <syscall name="fcntl" number="55"/>
- <syscall name="mpx" number="56"/>
- <syscall name="setpgid" number="57"/>
- <syscall name="ulimit" number="58"/>
- <syscall name="oldolduname" number="59"/>
- <syscall name="umask" number="60"/>
- <syscall name="chroot" number="61"/>
- <syscall name="ustat" number="62"/>
- <syscall name="dup2" number="63"/>
- <syscall name="getppid" number="64"/>
- <syscall name="getpgrp" number="65"/>
- <syscall name="setsid" number="66"/>
- <syscall name="sigaction" number="67"/>
- <syscall name="sgetmask" number="68"/>
- <syscall name="ssetmask" number="69"/>
- <syscall name="setreuid" number="70"/>
- <syscall name="setregid" number="71"/>
- <syscall name="sigsuspend" number="72"/>
- <syscall name="sigpending" number="73"/>
- <syscall name="sethostname" number="74"/>
- <syscall name="setrlimit" number="75"/>
- <syscall name="getrlimit" number="76"/>
- <syscall name="getrusage" number="77"/>
- <syscall name="gettimeofday" number="78"/>
- <syscall name="settimeofday" number="79"/>
- <syscall name="getgroups" number="80"/>
- <syscall name="setgroups" number="81"/>
- <syscall name="select" number="82"/>
- <syscall name="symlink" number="83"/>
- <syscall name="oldlstat" number="84"/>
- <syscall name="readlink" number="85"/>
- <syscall name="uselib" number="86"/>
- <syscall name="swapon" number="87"/>
- <syscall name="reboot" number="88"/>
- <syscall name="readdir" number="89"/>
- <syscall name="mmap" number="90"/>
- <syscall name="munmap" number="91"/>
- <syscall name="truncate" number="92"/>
- <syscall name="ftruncate" number="93"/>
- <syscall name="fchmod" number="94"/>
- <syscall name="fchown" number="95"/>
- <syscall name="getpriority" number="96"/>
- <syscall name="setpriority" number="97"/>
- <syscall name="profil" number="98"/>
- <syscall name="statfs" number="99"/>
- <syscall name="fstatfs" number="100"/>
- <syscall name="ioperm" number="101"/>
- <syscall name="socketcall" number="102"/>
- <syscall name="syslog" number="103"/>
- <syscall name="setitimer" number="104"/>
- <syscall name="getitimer" number="105"/>
- <syscall name="stat" number="106"/>
- <syscall name="lstat" number="107"/>
- <syscall name="fstat" number="108"/>
- <syscall name="olduname" number="109"/>
- <syscall name="iopl" number="110"/>
- <syscall name="vhangup" number="111"/>
- <syscall name="idle" number="112"/>
- <syscall name="vm86" number="113"/>
- <syscall name="wait4" number="114"/>
- <syscall name="swapoff" number="115"/>
- <syscall name="sysinfo" number="116"/>
- <syscall name="ipc" number="117"/>
- <syscall name="fsync" number="118"/>
- <syscall name="sigreturn" number="119"/>
- <syscall name="clone" number="120"/>
- <syscall name="setdomainname" number="121"/>
- <syscall name="uname" number="122"/>
- <syscall name="modify_ldt" number="123"/>
- <syscall name="adjtimex" number="124"/>
- <syscall name="mprotect" number="125"/>
- <syscall name="sigprocmask" number="126"/>
- <syscall name="create_module" number="127"/>
- <syscall name="init_module" number="128"/>
- <syscall name="delete_module" number="129"/>
- <syscall name="get_kernel_syms" number="130"/>
- <syscall name="quotactl" number="131"/>
- <syscall name="getpgid" number="132"/>
- <syscall name="fchdir" number="133"/>
- <syscall name="bdflush" number="134"/>
- <syscall name="sysfs" number="135"/>
- <syscall name="personality" number="136"/>
- <syscall name="afs_syscall" number="137"/>
- <syscall name="setfsuid" number="138"/>
- <syscall name="setfsgid" number="139"/>
- <syscall name="_llseek" number="140"/>
- <syscall name="getdents" number="141"/>
- <syscall name="_newselect" number="142"/>
- <syscall name="flock" number="143"/>
- <syscall name="msync" number="144"/>
- <syscall name="readv" number="145"/>
- <syscall name="writev" number="146"/>
- <syscall name="getsid" number="147"/>
- <syscall name="fdatasync" number="148"/>
- <syscall name="_sysctl" number="149"/>
- <syscall name="mlock" number="150"/>
- <syscall name="munlock" number="151"/>
- <syscall name="mlockall" number="152"/>
- <syscall name="munlockall" number="153"/>
- <syscall name="sched_setparam" number="154"/>
- <syscall name="sched_getparam" number="155"/>
- <syscall name="sched_setscheduler" number="156"/>
- <syscall name="sched_getscheduler" number="157"/>
- <syscall name="sched_yield" number="158"/>
- <syscall name="sched_get_priority_max" number="159"/>
- <syscall name="sched_get_priority_min" number="160"/>
- <syscall name="sched_rr_get_interval" number="161"/>
- <syscall name="nanosleep" number="162"/>
- <syscall name="mremap" number="163"/>
- <syscall name="setresuid" number="164"/>
- <syscall name="getresuid" number="165"/>
- <syscall name="query_module" number="166"/>
- <syscall name="poll" number="167"/>
- <syscall name="nfsservctl" number="168"/>
- <syscall name="setresgid" number="169"/>
- <syscall name="getresgid" number="170"/>
- <syscall name="prctl" number="171"/>
- <syscall name="rt_sigreturn" number="172"/>
- <syscall name="rt_sigaction" number="173"/>
- <syscall name="rt_sigprocmask" number="174"/>
- <syscall name="rt_sigpending" number="175"/>
- <syscall name="rt_sigtimedwait" number="176"/>
- <syscall name="rt_sigqueueinfo" number="177"/>
- <syscall name="rt_sigsuspend" number="178"/>
- <syscall name="pread64" number="179"/>
- <syscall name="pwrite64" number="180"/>
- <syscall name="chown" number="181"/>
- <syscall name="getcwd" number="182"/>
- <syscall name="capget" number="183"/>
- <syscall name="capset" number="184"/>
- <syscall name="sigaltstack" number="185"/>
- <syscall name="sendfile" number="186"/>
- <syscall name="getpmsg" number="187"/>
- <syscall name="putpmsg" number="188"/>
- <syscall name="vfork" number="189"/>
- <syscall name="ugetrlimit" number="190"/>
- <syscall name="readahead" number="191"/>
- <syscall name="mmap2" number="192"/>
- <syscall name="truncate64" number="193"/>
- <syscall name="ftruncate64" number="194"/>
- <syscall name="stat64" number="195"/>
- <syscall name="lstat64" number="196"/>
- <syscall name="fstat64" number="197"/>
- <syscall name="pciconfig_read" number="198"/>
- <syscall name="pciconfig_write" number="199"/>
- <syscall name="pciconfig_iobase" number="200"/>
- <syscall name="multiplexer" number="201"/>
- <syscall name="getdents64" number="202"/>
- <syscall name="pivot_root" number="203"/>
- <syscall name="fcntl64" number="204"/>
- <syscall name="madvise" number="205"/>
- <syscall name="mincore" number="206"/>
- <syscall name="gettid" number="207"/>
- <syscall name="tkill" number="208"/>
- <syscall name="setxattr" number="209"/>
- <syscall name="lsetxattr" number="210"/>
- <syscall name="fsetxattr" number="211"/>
- <syscall name="getxattr" number="212"/>
- <syscall name="lgetxattr" number="213"/>
- <syscall name="fgetxattr" number="214"/>
- <syscall name="listxattr" number="215"/>
- <syscall name="llistxattr" number="216"/>
- <syscall name="flistxattr" number="217"/>
- <syscall name="removexattr" number="218"/>
- <syscall name="lremovexattr" number="219"/>
- <syscall name="fremovexattr" number="220"/>
- <syscall name="futex" number="221"/>
- <syscall name="sched_setaffinity" number="222"/>
- <syscall name="sched_getaffinity" number="223"/>
- <syscall name="tuxcall" number="225"/>
- <syscall name="sendfile64" number="226"/>
- <syscall name="io_setup" number="227"/>
- <syscall name="io_destroy" number="228"/>
- <syscall name="io_getevents" number="229"/>
- <syscall name="io_submit" number="230"/>
- <syscall name="io_cancel" number="231"/>
- <syscall name="set_tid_address" number="232"/>
- <syscall name="fadvise64" number="233"/>
- <syscall name="exit_group" number="234"/>
- <syscall name="lookup_dcookie" number="235"/>
- <syscall name="epoll_create" number="236"/>
- <syscall name="epoll_ctl" number="237"/>
- <syscall name="epoll_wait" number="238"/>
- <syscall name="remap_file_pages" number="239"/>
- <syscall name="timer_create" number="240"/>
- <syscall name="timer_settime" number="241"/>
- <syscall name="timer_gettime" number="242"/>
- <syscall name="timer_getoverrun" number="243"/>
- <syscall name="timer_delete" number="244"/>
- <syscall name="clock_settime" number="245"/>
- <syscall name="clock_gettime" number="246"/>
- <syscall name="clock_getres" number="247"/>
- <syscall name="clock_nanosleep" number="248"/>
- <syscall name="swapcontext" number="249"/>
- <syscall name="tgkill" number="250"/>
- <syscall name="utimes" number="251"/>
- <syscall name="statfs64" number="252"/>
- <syscall name="fstatfs64" number="253"/>
- <syscall name="fadvise64_64" number="254"/>
- <syscall name="rtas" number="255"/>
- <syscall name="sys_debug_setcontext" number="256"/>
- <syscall name="mbind" number="259"/>
- <syscall name="get_mempolicy" number="260"/>
- <syscall name="set_mempolicy" number="261"/>
- <syscall name="mq_open" number="262"/>
- <syscall name="mq_unlink" number="263"/>
- <syscall name="mq_timedsend" number="264"/>
- <syscall name="mq_timedreceive" number="265"/>
- <syscall name="mq_notify" number="266"/>
- <syscall name="mq_getsetattr" number="267"/>
- <syscall name="kexec_load" number="268"/>
- <syscall name="add_key" number="269"/>
- <syscall name="request_key" number="270"/>
- <syscall name="keyctl" number="271"/>
- <syscall name="waitid" number="272"/>
- <syscall name="ioprio_set" number="273"/>
- <syscall name="ioprio_get" number="274"/>
- <syscall name="inotify_init" number="275"/>
- <syscall name="inotify_add_watch" number="276"/>
- <syscall name="inotify_rm_watch" number="277"/>
- <syscall name="spu_run" number="278"/>
- <syscall name="spu_create" number="279"/>
- <syscall name="pselect6" number="280"/>
- <syscall name="ppoll" number="281"/>
- <syscall name="unshare" number="282"/>
- <syscall name="openat" number="286"/>
- <syscall name="mkdirat" number="287"/>
- <syscall name="mknodat" number="288"/>
- <syscall name="fchownat" number="289"/>
- <syscall name="futimesat" number="290"/>
- <syscall name="fstatat64" number="291"/>
- <syscall name="unlinkat" number="292"/>
- <syscall name="renameat" number="293"/>
- <syscall name="linkat" number="294"/>
- <syscall name="symlinkat" number="295"/>
- <syscall name="readlinkat" number="296"/>
- <syscall name="fchmodat" number="297"/>
- <syscall name="faccessat" number="298"/>
-</syscalls_info>
diff --git a/share/gdb/syscalls/ppc64-linux.xml b/share/gdb/syscalls/ppc64-linux.xml
deleted file mode 100644
index 0b0b2ea..0000000
--- a/share/gdb/syscalls/ppc64-linux.xml
+++ /dev/null
@@ -1,295 +0,0 @@
-<?xml version="1.0"?>
-<!-- Copyright (C) 2009, 2011 Free Software Foundation, Inc.
-
- Copying and distribution of this file, with or without modification,
- are permitted in any medium without royalty provided the copyright
- notice and this notice are preserved. -->
-
-<!DOCTYPE feature SYSTEM "gdb-syscalls.dtd">
-
-<!-- This file was generated using the following file:
-
- /usr/src/linux/arch/powerpc/include/asm/unistd.h
-
- The file mentioned above belongs to the Linux Kernel. -->
-
-<syscalls_info>
- <syscall name="restart_syscall" number="0"/>
- <syscall name="exit" number="1"/>
- <syscall name="fork" number="2"/>
- <syscall name="read" number="3"/>
- <syscall name="write" number="4"/>
- <syscall name="open" number="5"/>
- <syscall name="close" number="6"/>
- <syscall name="waitpid" number="7"/>
- <syscall name="creat" number="8"/>
- <syscall name="link" number="9"/>
- <syscall name="unlink" number="10"/>
- <syscall name="execve" number="11"/>
- <syscall name="chdir" number="12"/>
- <syscall name="time" number="13"/>
- <syscall name="mknod" number="14"/>
- <syscall name="chmod" number="15"/>
- <syscall name="lchown" number="16"/>
- <syscall name="break" number="17"/>
- <syscall name="oldstat" number="18"/>
- <syscall name="lseek" number="19"/>
- <syscall name="getpid" number="20"/>
- <syscall name="mount" number="21"/>
- <syscall name="umount" number="22"/>
- <syscall name="setuid" number="23"/>
- <syscall name="getuid" number="24"/>
- <syscall name="stime" number="25"/>
- <syscall name="ptrace" number="26"/>
- <syscall name="alarm" number="27"/>
- <syscall name="oldfstat" number="28"/>
- <syscall name="pause" number="29"/>
- <syscall name="utime" number="30"/>
- <syscall name="stty" number="31"/>
- <syscall name="gtty" number="32"/>
- <syscall name="access" number="33"/>
- <syscall name="nice" number="34"/>
- <syscall name="ftime" number="35"/>
- <syscall name="sync" number="36"/>
- <syscall name="kill" number="37"/>
- <syscall name="rename" number="38"/>
- <syscall name="mkdir" number="39"/>
- <syscall name="rmdir" number="40"/>
- <syscall name="dup" number="41"/>
- <syscall name="pipe" number="42"/>
- <syscall name="times" number="43"/>
- <syscall name="prof" number="44"/>
- <syscall name="brk" number="45"/>
- <syscall name="setgid" number="46"/>
- <syscall name="getgid" number="47"/>
- <syscall name="signal" number="48"/>
- <syscall name="geteuid" number="49"/>
- <syscall name="getegid" number="50"/>
- <syscall name="acct" number="51"/>
- <syscall name="umount2" number="52"/>
- <syscall name="lock" number="53"/>
- <syscall name="ioctl" number="54"/>
- <syscall name="fcntl" number="55"/>
- <syscall name="mpx" number="56"/>
- <syscall name="setpgid" number="57"/>
- <syscall name="ulimit" number="58"/>
- <syscall name="oldolduname" number="59"/>
- <syscall name="umask" number="60"/>
- <syscall name="chroot" number="61"/>
- <syscall name="ustat" number="62"/>
- <syscall name="dup2" number="63"/>
- <syscall name="getppid" number="64"/>
- <syscall name="getpgrp" number="65"/>
- <syscall name="setsid" number="66"/>
- <syscall name="sigaction" number="67"/>
- <syscall name="sgetmask" number="68"/>
- <syscall name="ssetmask" number="69"/>
- <syscall name="setreuid" number="70"/>
- <syscall name="setregid" number="71"/>
- <syscall name="sigsuspend" number="72"/>
- <syscall name="sigpending" number="73"/>
- <syscall name="sethostname" number="74"/>
- <syscall name="setrlimit" number="75"/>
- <syscall name="getrlimit" number="76"/>
- <syscall name="getrusage" number="77"/>
- <syscall name="gettimeofday" number="78"/>
- <syscall name="settimeofday" number="79"/>
- <syscall name="getgroups" number="80"/>
- <syscall name="setgroups" number="81"/>
- <syscall name="select" number="82"/>
- <syscall name="symlink" number="83"/>
- <syscall name="oldlstat" number="84"/>
- <syscall name="readlink" number="85"/>
- <syscall name="uselib" number="86"/>
- <syscall name="swapon" number="87"/>
- <syscall name="reboot" number="88"/>
- <syscall name="readdir" number="89"/>
- <syscall name="mmap" number="90"/>
- <syscall name="munmap" number="91"/>
- <syscall name="truncate" number="92"/>
- <syscall name="ftruncate" number="93"/>
- <syscall name="fchmod" number="94"/>
- <syscall name="fchown" number="95"/>
- <syscall name="getpriority" number="96"/>
- <syscall name="setpriority" number="97"/>
- <syscall name="profil" number="98"/>
- <syscall name="statfs" number="99"/>
- <syscall name="fstatfs" number="100"/>
- <syscall name="ioperm" number="101"/>
- <syscall name="socketcall" number="102"/>
- <syscall name="syslog" number="103"/>
- <syscall name="setitimer" number="104"/>
- <syscall name="getitimer" number="105"/>
- <syscall name="stat" number="106"/>
- <syscall name="lstat" number="107"/>
- <syscall name="fstat" number="108"/>
- <syscall name="olduname" number="109"/>
- <syscall name="iopl" number="110"/>
- <syscall name="vhangup" number="111"/>
- <syscall name="idle" number="112"/>
- <syscall name="vm86" number="113"/>
- <syscall name="wait4" number="114"/>
- <syscall name="swapoff" number="115"/>
- <syscall name="sysinfo" number="116"/>
- <syscall name="ipc" number="117"/>
- <syscall name="fsync" number="118"/>
- <syscall name="sigreturn" number="119"/>
- <syscall name="clone" number="120"/>
- <syscall name="setdomainname" number="121"/>
- <syscall name="uname" number="122"/>
- <syscall name="modify_ldt" number="123"/>
- <syscall name="adjtimex" number="124"/>
- <syscall name="mprotect" number="125"/>
- <syscall name="sigprocmask" number="126"/>
- <syscall name="create_module" number="127"/>
- <syscall name="init_module" number="128"/>
- <syscall name="delete_module" number="129"/>
- <syscall name="get_kernel_syms" number="130"/>
- <syscall name="quotactl" number="131"/>
- <syscall name="getpgid" number="132"/>
- <syscall name="fchdir" number="133"/>
- <syscall name="bdflush" number="134"/>
- <syscall name="sysfs" number="135"/>
- <syscall name="personality" number="136"/>
- <syscall name="afs_syscall" number="137"/>
- <syscall name="setfsuid" number="138"/>
- <syscall name="setfsgid" number="139"/>
- <syscall name="_llseek" number="140"/>
- <syscall name="getdents" number="141"/>
- <syscall name="_newselect" number="142"/>
- <syscall name="flock" number="143"/>
- <syscall name="msync" number="144"/>
- <syscall name="readv" number="145"/>
- <syscall name="writev" number="146"/>
- <syscall name="getsid" number="147"/>
- <syscall name="fdatasync" number="148"/>
- <syscall name="_sysctl" number="149"/>
- <syscall name="mlock" number="150"/>
- <syscall name="munlock" number="151"/>
- <syscall name="mlockall" number="152"/>
- <syscall name="munlockall" number="153"/>
- <syscall name="sched_setparam" number="154"/>
- <syscall name="sched_getparam" number="155"/>
- <syscall name="sched_setscheduler" number="156"/>
- <syscall name="sched_getscheduler" number="157"/>
- <syscall name="sched_yield" number="158"/>
- <syscall name="sched_get_priority_max" number="159"/>
- <syscall name="sched_get_priority_min" number="160"/>
- <syscall name="sched_rr_get_interval" number="161"/>
- <syscall name="nanosleep" number="162"/>
- <syscall name="mremap" number="163"/>
- <syscall name="setresuid" number="164"/>
- <syscall name="getresuid" number="165"/>
- <syscall name="query_module" number="166"/>
- <syscall name="poll" number="167"/>
- <syscall name="nfsservctl" number="168"/>
- <syscall name="setresgid" number="169"/>
- <syscall name="getresgid" number="170"/>
- <syscall name="prctl" number="171"/>
- <syscall name="rt_sigreturn" number="172"/>
- <syscall name="rt_sigaction" number="173"/>
- <syscall name="rt_sigprocmask" number="174"/>
- <syscall name="rt_sigpending" number="175"/>
- <syscall name="rt_sigtimedwait" number="176"/>
- <syscall name="rt_sigqueueinfo" number="177"/>
- <syscall name="rt_sigsuspend" number="178"/>
- <syscall name="pread64" number="179"/>
- <syscall name="pwrite64" number="180"/>
- <syscall name="chown" number="181"/>
- <syscall name="getcwd" number="182"/>
- <syscall name="capget" number="183"/>
- <syscall name="capset" number="184"/>
- <syscall name="sigaltstack" number="185"/>
- <syscall name="sendfile" number="186"/>
- <syscall name="getpmsg" number="187"/>
- <syscall name="putpmsg" number="188"/>
- <syscall name="vfork" number="189"/>
- <syscall name="ugetrlimit" number="190"/>
- <syscall name="readahead" number="191"/>
- <syscall name="pciconfig_read" number="198"/>
- <syscall name="pciconfig_write" number="199"/>
- <syscall name="pciconfig_iobase" number="200"/>
- <syscall name="multiplexer" number="201"/>
- <syscall name="getdents64" number="202"/>
- <syscall name="pivot_root" number="203"/>
- <syscall name="madvise" number="205"/>
- <syscall name="mincore" number="206"/>
- <syscall name="gettid" number="207"/>
- <syscall name="tkill" number="208"/>
- <syscall name="setxattr" number="209"/>
- <syscall name="lsetxattr" number="210"/>
- <syscall name="fsetxattr" number="211"/>
- <syscall name="getxattr" number="212"/>
- <syscall name="lgetxattr" number="213"/>
- <syscall name="fgetxattr" number="214"/>
- <syscall name="listxattr" number="215"/>
- <syscall name="llistxattr" number="216"/>
- <syscall name="flistxattr" number="217"/>
- <syscall name="removexattr" number="218"/>
- <syscall name="lremovexattr" number="219"/>
- <syscall name="fremovexattr" number="220"/>
- <syscall name="futex" number="221"/>
- <syscall name="sched_setaffinity" number="222"/>
- <syscall name="sched_getaffinity" number="223"/>
- <syscall name="tuxcall" number="225"/>
- <syscall name="io_setup" number="227"/>
- <syscall name="io_destroy" number="228"/>
- <syscall name="io_getevents" number="229"/>
- <syscall name="io_submit" number="230"/>
- <syscall name="io_cancel" number="231"/>
- <syscall name="set_tid_address" number="232"/>
- <syscall name="fadvise64" number="233"/>
- <syscall name="exit_group" number="234"/>
- <syscall name="lookup_dcookie" number="235"/>
- <syscall name="epoll_create" number="236"/>
- <syscall name="epoll_ctl" number="237"/>
- <syscall name="epoll_wait" number="238"/>
- <syscall name="remap_file_pages" number="239"/>
- <syscall name="timer_create" number="240"/>
- <syscall name="timer_settime" number="241"/>
- <syscall name="timer_gettime" number="242"/>
- <syscall name="timer_getoverrun" number="243"/>
- <syscall name="timer_delete" number="244"/>
- <syscall name="clock_settime" number="245"/>
- <syscall name="clock_gettime" number="246"/>
- <syscall name="clock_getres" number="247"/>
- <syscall name="clock_nanosleep" number="248"/>
- <syscall name="swapcontext" number="249"/>
- <syscall name="tgkill" number="250"/>
- <syscall name="utimes" number="251"/>
- <syscall name="statfs64" number="252"/>
- <syscall name="fstatfs64" number="253"/>
- <syscall name="rtas" number="255"/>
- <syscall name="sys_debug_setcontext" number="256"/>
- <syscall name="mbind" number="259"/>
- <syscall name="get_mempolicy" number="260"/>
- <syscall name="set_mempolicy" number="261"/>
- <syscall name="mq_open" number="262"/>
- <syscall name="mq_unlink" number="263"/>
- <syscall name="mq_timedsend" number="264"/>
- <syscall name="mq_timedreceive" number="265"/>
- <syscall name="mq_notify" number="266"/>
- <syscall name="mq_getsetattr" number="267"/>
- <syscall name="kexec_load" number="268"/>
- <syscall name="add_key" number="269"/>
- <syscall name="request_key" number="270"/>
- <syscall name="keyctl" number="271"/>
- <syscall name="waitid" number="272"/>
- <syscall name="ioprio_set" number="273"/>
- <syscall name="ioprio_get" number="274"/>
- <syscall name="inotify_init" number="275"/>
- <syscall name="inotify_add_watch" number="276"/>
- <syscall name="inotify_rm_watch" number="277"/>
- <syscall name="spu_run" number="278"/>
- <syscall name="spu_create" number="279"/>
- <syscall name="pselect6" number="280"/>
- <syscall name="ppoll" number="281"/>
- <syscall name="unshare" number="282"/>
- <syscall name="unlinkat" number="286"/>
- <syscall name="renameat" number="287"/>
- <syscall name="linkat" number="288"/>
- <syscall name="symlinkat" number="289"/>
- <syscall name="readlinkat" number="290"/>
- <syscall name="fchmodat" number="291"/>
- <syscall name="faccessat" number="292"/>
-</syscalls_info>
diff --git a/share/gdb/syscalls/sparc-linux.xml b/share/gdb/syscalls/sparc-linux.xml
deleted file mode 100644
index 3820809..0000000
--- a/share/gdb/syscalls/sparc-linux.xml
+++ /dev/null
@@ -1,344 +0,0 @@
-<?xml version="1.0"?>
-<!-- Copyright (C) 2010, 2011 Free Software Foundation, Inc.
-
- Copying and distribution of this file, with or without modification,
- are permitted in any medium without royalty provided the copyright
- notice and this notice are preserved. -->
-
-<!DOCTYPE feature SYSTEM "gdb-syscalls.dtd">
-
-<!-- This file was generated using the following file:
-
- /usr/src/linux/arch/sparc/include/asm/unistd.h
-
- The file mentioned above belongs to the Linux Kernel. -->
-
-<syscalls_info>
- <syscall name="restart_syscall" number="0"/>
- <syscall name="exit" number="1"/>
- <syscall name="fork" number="2"/>
- <syscall name="read" number="3"/>
- <syscall name="write" number="4"/>
- <syscall name="open" number="5"/>
- <syscall name="close" number="6"/>
- <syscall name="wait4" number="7"/>
- <syscall name="creat" number="8"/>
- <syscall name="link" number="9"/>
- <syscall name="unlink" number="10"/>
- <syscall name="execv" number="11"/>
- <syscall name="chdir" number="12"/>
- <syscall name="chown" number="13"/>
- <syscall name="mknod" number="14"/>
- <syscall name="chmod" number="15"/>
- <syscall name="lchown" number="16"/>
- <syscall name="brk" number="17"/>
- <syscall name="perfctr" number="18"/>
- <syscall name="lseek" number="19"/>
- <syscall name="getpid" number="20"/>
- <syscall name="capget" number="21"/>
- <syscall name="capset" number="22"/>
- <syscall name="setuid" number="23"/>
- <syscall name="getuid" number="24"/>
- <syscall name="vmsplice" number="25"/>
- <syscall name="ptrace" number="26"/>
- <syscall name="alarm" number="27"/>
- <syscall name="sigaltstack" number="28"/>
- <syscall name="pause" number="29"/>
- <syscall name="utime" number="30"/>
- <syscall name="lchown32" number="31"/>
- <syscall name="fchown32" number="32"/>
- <syscall name="access" number="33"/>
- <syscall name="nice" number="34"/>
- <syscall name="chown32" number="35"/>
- <syscall name="sync" number="36"/>
- <syscall name="kill" number="37"/>
- <syscall name="stat" number="38"/>
- <syscall name="sendfile" number="39"/>
- <syscall name="lstat" number="40"/>
- <syscall name="dup" number="41"/>
- <syscall name="pipe" number="42"/>
- <syscall name="times" number="43"/>
- <syscall name="getuid32" number="44"/>
- <syscall name="umount2" number="45"/>
- <syscall name="setgid" number="46"/>
- <syscall name="getgid" number="47"/>
- <syscall name="signal" number="48"/>
- <syscall name="geteuid" number="49"/>
- <syscall name="getegid" number="50"/>
- <syscall name="acct" number="51"/>
- <syscall name="getgid32" number="53"/>
- <syscall name="ioctl" number="54"/>
- <syscall name="reboot" number="55"/>
- <syscall name="mmap2" number="56"/>
- <syscall name="symlink" number="57"/>
- <syscall name="readlink" number="58"/>
- <syscall name="execve" number="59"/>
- <syscall name="umask" number="60"/>
- <syscall name="chroot" number="61"/>
- <syscall name="fstat" number="62"/>
- <syscall name="fstat64" number="63"/>
- <syscall name="getpagesize" number="64"/>
- <syscall name="msync" number="65"/>
- <syscall name="vfork" number="66"/>
- <syscall name="pread64" number="67"/>
- <syscall name="pwrite64" number="68"/>
- <syscall name="geteuid32" number="69"/>
- <syscall name="getegid32" number="70"/>
- <syscall name="mmap" number="71"/>
- <syscall name="setreuid32" number="72"/>
- <syscall name="munmap" number="73"/>
- <syscall name="mprotect" number="74"/>
- <syscall name="madvise" number="75"/>
- <syscall name="vhangup" number="76"/>
- <syscall name="truncate64" number="77"/>
- <syscall name="mincore" number="78"/>
- <syscall name="getgroups" number="79"/>
- <syscall name="setgroups" number="80"/>
- <syscall name="getpgrp" number="81"/>
- <syscall name="setgroups32" number="82"/>
- <syscall name="setitimer" number="83"/>
- <syscall name="ftruncate64" number="84"/>
- <syscall name="swapon" number="85"/>
- <syscall name="getitimer" number="86"/>
- <syscall name="setuid32" number="87"/>
- <syscall name="sethostname" number="88"/>
- <syscall name="setgid32" number="89"/>
- <syscall name="dup2" number="90"/>
- <syscall name="setfsuid32" number="91"/>
- <syscall name="fcntl" number="92"/>
- <syscall name="select" number="93"/>
- <syscall name="setfsgid32" number="94"/>
- <syscall name="fsync" number="95"/>
- <syscall name="setpriority" number="96"/>
- <syscall name="socket" number="97"/>
- <syscall name="connect" number="98"/>
- <syscall name="accept" number="99"/>
- <syscall name="getpriority" number="100"/>
- <syscall name="rt_sigreturn" number="101"/>
- <syscall name="rt_sigaction" number="102"/>
- <syscall name="rt_sigprocmask" number="103"/>
- <syscall name="rt_sigpending" number="104"/>
- <syscall name="rt_sigtimedwait" number="105"/>
- <syscall name="rt_sigqueueinfo" number="106"/>
- <syscall name="rt_sigsuspend" number="107"/>
- <syscall name="setresuid32" number="108"/>
- <syscall name="getresuid32" number="109"/>
- <syscall name="setresgid32" number="110"/>
- <syscall name="getresgid32" number="111"/>
- <syscall name="setregid32" number="112"/>
- <syscall name="recvmsg" number="113"/>
- <syscall name="sendmsg" number="114"/>
- <syscall name="getgroups32" number="115"/>
- <syscall name="gettimeofday" number="116"/>
- <syscall name="getrusage" number="117"/>
- <syscall name="getsockopt" number="118"/>
- <syscall name="getcwd" number="119"/>
- <syscall name="readv" number="120"/>
- <syscall name="writev" number="121"/>
- <syscall name="settimeofday" number="122"/>
- <syscall name="fchown" number="123"/>
- <syscall name="fchmod" number="124"/>
- <syscall name="recvfrom" number="125"/>
- <syscall name="setreuid" number="126"/>
- <syscall name="setregid" number="127"/>
- <syscall name="rename" number="128"/>
- <syscall name="truncate" number="129"/>
- <syscall name="ftruncate" number="130"/>
- <syscall name="flock" number="131"/>
- <syscall name="lstat64" number="132"/>
- <syscall name="sendto" number="133"/>
- <syscall name="shutdown" number="134"/>
- <syscall name="socketpair" number="135"/>
- <syscall name="mkdir" number="136"/>
- <syscall name="rmdir" number="137"/>
- <syscall name="utimes" number="138"/>
- <syscall name="stat64" number="139"/>
- <syscall name="sendfile64" number="140"/>
- <syscall name="getpeername" number="141"/>
- <syscall name="futex" number="142"/>
- <syscall name="gettid" number="143"/>
- <syscall name="getrlimit" number="144"/>
- <syscall name="setrlimit" number="145"/>
- <syscall name="pivot_root" number="146"/>
- <syscall name="prctl" number="147"/>
- <syscall name="pciconfig_read" number="148"/>
- <syscall name="pciconfig_write" number="149"/>
- <syscall name="getsockname" number="150"/>
- <syscall name="inotify_init" number="151"/>
- <syscall name="inotify_add_watch" number="152"/>
- <syscall name="poll" number="153"/>
- <syscall name="getdents64" number="154"/>
- <syscall name="fcntl64" number="155"/>
- <syscall name="inotify_rm_watch" number="156"/>
- <syscall name="statfs" number="157"/>
- <syscall name="fstatfs" number="158"/>
- <syscall name="umount" number="159"/>
- <syscall name="sched_set_affinity" number="160"/>
- <syscall name="sched_get_affinity" number="161"/>
- <syscall name="getdomainname" number="162"/>
- <syscall name="setdomainname" number="163"/>
- <syscall name="quotactl" number="165"/>
- <syscall name="set_tid_address" number="166"/>
- <syscall name="mount" number="167"/>
- <syscall name="ustat" number="168"/>
- <syscall name="setxattr" number="169"/>
- <syscall name="lsetxattr" number="170"/>
- <syscall name="fsetxattr" number="171"/>
- <syscall name="getxattr" number="172"/>
- <syscall name="lgetxattr" number="173"/>
- <syscall name="getdents" number="174"/>
- <syscall name="setsid" number="175"/>
- <syscall name="fchdir" number="176"/>
- <syscall name="fgetxattr" number="177"/>
- <syscall name="listxattr" number="178"/>
- <syscall name="llistxattr" number="179"/>
- <syscall name="flistxattr" number="180"/>
- <syscall name="removexattr" number="181"/>
- <syscall name="lremovexattr" number="182"/>
- <syscall name="sigpending" number="183"/>
- <syscall name="query_module" number="184"/>
- <syscall name="setpgid" number="185"/>
- <syscall name="fremovexattr" number="186"/>
- <syscall name="tkill" number="187"/>
- <syscall name="exit_group" number="188"/>
- <syscall name="uname" number="189"/>
- <syscall name="init_module" number="190"/>
- <syscall name="personality" number="191"/>
- <syscall name="remap_file_pages" number="192"/>
- <syscall name="epoll_create" number="193"/>
- <syscall name="epoll_ctl" number="194"/>
- <syscall name="epoll_wait" number="195"/>
- <syscall name="ioprio_set" number="196"/>
- <syscall name="getppid" number="197"/>
- <syscall name="sigaction" number="198"/>
- <syscall name="sgetmask" number="199"/>
- <syscall name="ssetmask" number="200"/>
- <syscall name="sigsuspend" number="201"/>
- <syscall name="oldlstat" number="202"/>
- <syscall name="uselib" number="203"/>
- <syscall name="readdir" number="204"/>
- <syscall name="readahead" number="205"/>
- <syscall name="socketcall" number="206"/>
- <syscall name="syslog" number="207"/>
- <syscall name="lookup_dcookie" number="208"/>
- <syscall name="fadvise64" number="209"/>
- <syscall name="fadvise64_64" number="210"/>
- <syscall name="tgkill" number="211"/>
- <syscall name="waitpid" number="212"/>
- <syscall name="swapoff" number="213"/>
- <syscall name="sysinfo" number="214"/>
- <syscall name="ipc" number="215"/>
- <syscall name="sigreturn" number="216"/>
- <syscall name="clone" number="217"/>
- <syscall name="ioprio_get" number="218"/>
- <syscall name="adjtimex" number="219"/>
- <syscall name="sigprocmask" number="220"/>
- <syscall name="create_module" number="221"/>
- <syscall name="delete_module" number="222"/>
- <syscall name="get_kernel_syms" number="223"/>
- <syscall name="getpgid" number="224"/>
- <syscall name="bdflush" number="225"/>
- <syscall name="sysfs" number="226"/>
- <syscall name="afs_syscall" number="227"/>
- <syscall name="setfsuid" number="228"/>
- <syscall name="setfsgid" number="229"/>
- <syscall name="_newselect" number="230"/>
- <syscall name="time" number="231"/>
- <syscall name="splice" number="232"/>
- <syscall name="stime" number="233"/>
- <syscall name="statfs64" number="234"/>
- <syscall name="fstatfs64" number="235"/>
- <syscall name="_llseek" number="236"/>
- <syscall name="mlock" number="237"/>
- <syscall name="munlock" number="238"/>
- <syscall name="mlockall" number="239"/>
- <syscall name="munlockall" number="240"/>
- <syscall name="sched_setparam" number="241"/>
- <syscall name="sched_getparam" number="242"/>
- <syscall name="sched_setscheduler" number="243"/>
- <syscall name="sched_getscheduler" number="244"/>
- <syscall name="sched_yield" number="245"/>
- <syscall name="sched_get_priority_max" number="246"/>
- <syscall name="sched_get_priority_min" number="247"/>
- <syscall name="sched_rr_get_interval" number="248"/>
- <syscall name="nanosleep" number="249"/>
- <syscall name="mremap" number="250"/>
- <syscall name="_sysctl" number="251"/>
- <syscall name="getsid" number="252"/>
- <syscall name="fdatasync" number="253"/>
- <syscall name="nfsservctl" number="254"/>
- <syscall name="sync_file_range" number="255"/>
- <syscall name="clock_settime" number="256"/>
- <syscall name="clock_gettime" number="257"/>
- <syscall name="clock_getres" number="258"/>
- <syscall name="clock_nanosleep" number="259"/>
- <syscall name="sched_getaffinity" number="260"/>
- <syscall name="sched_setaffinity" number="261"/>
- <syscall name="timer_settime" number="262"/>
- <syscall name="timer_gettime" number="263"/>
- <syscall name="timer_getoverrun" number="264"/>
- <syscall name="timer_delete" number="265"/>
- <syscall name="timer_create" number="266"/>
- <syscall name="vserver" number="267"/>
- <syscall name="io_setup" number="268"/>
- <syscall name="io_destroy" number="269"/>
- <syscall name="io_submit" number="270"/>
- <syscall name="io_cancel" number="271"/>
- <syscall name="io_getevents" number="272"/>
- <syscall name="mq_open" number="273"/>
- <syscall name="mq_unlink" number="274"/>
- <syscall name="mq_timedsend" number="275"/>
- <syscall name="mq_timedreceive" number="276"/>
- <syscall name="mq_notify" number="277"/>
- <syscall name="mq_getsetattr" number="278"/>
- <syscall name="waitid" number="279"/>
- <syscall name="tee" number="280"/>
- <syscall name="add_key" number="281"/>
- <syscall name="request_key" number="282"/>
- <syscall name="keyctl" number="283"/>
- <syscall name="openat" number="284"/>
- <syscall name="mkdirat" number="285"/>
- <syscall name="mknodat" number="286"/>
- <syscall name="fchownat" number="287"/>
- <syscall name="futimesat" number="288"/>
- <syscall name="fstatat64" number="289"/>
- <syscall name="unlinkat" number="290"/>
- <syscall name="renameat" number="291"/>
- <syscall name="linkat" number="292"/>
- <syscall name="symlinkat" number="293"/>
- <syscall name="readlinkat" number="294"/>
- <syscall name="fchmodat" number="295"/>
- <syscall name="faccessat" number="296"/>
- <syscall name="pselect6" number="297"/>
- <syscall name="ppoll" number="298"/>
- <syscall name="unshare" number="299"/>
- <syscall name="set_robust_list" number="300"/>
- <syscall name="get_robust_list" number="301"/>
- <syscall name="migrate_pages" number="302"/>
- <syscall name="mbind" number="303"/>
- <syscall name="get_mempolicy" number="304"/>
- <syscall name="set_mempolicy" number="305"/>
- <syscall name="kexec_load" number="306"/>
- <syscall name="move_pages" number="307"/>
- <syscall name="getcpu" number="308"/>
- <syscall name="epoll_pwait" number="309"/>
- <syscall name="utimensat" number="310"/>
- <syscall name="signalfd" number="311"/>
- <syscall name="timerfd_create" number="312"/>
- <syscall name="eventfd" number="313"/>
- <syscall name="fallocate" number="314"/>
- <syscall name="timerfd_settime" number="315"/>
- <syscall name="timerfd_gettime" number="316"/>
- <syscall name="signalfd4" number="317"/>
- <syscall name="eventfd2" number="318"/>
- <syscall name="epoll_create1" number="319"/>
- <syscall name="dup3" number="320"/>
- <syscall name="pipe2" number="321"/>
- <syscall name="inotify_init1" number="322"/>
- <syscall name="accept4" number="323"/>
- <syscall name="preadv" number="324"/>
- <syscall name="pwritev" number="325"/>
- <syscall name="rt_tgsigqueueinfo" number="326"/>
- <syscall name="perf_event_open" number="327"/>
- <syscall name="recvmmsg" number="328"/>
-</syscalls_info>
diff --git a/share/gdb/syscalls/sparc64-linux.xml b/share/gdb/syscalls/sparc64-linux.xml
deleted file mode 100644
index df8118b..0000000
--- a/share/gdb/syscalls/sparc64-linux.xml
+++ /dev/null
@@ -1,326 +0,0 @@
-<?xml version="1.0"?>
-<!-- Copyright (C) 2010, 2011 Free Software Foundation, Inc.
-
- Copying and distribution of this file, with or without modification,
- are permitted in any medium without royalty provided the copyright
- notice and this notice are preserved. -->
-
-<!DOCTYPE feature SYSTEM "gdb-syscalls.dtd">
-
-<!-- This file was generated using the following file:
-
- /usr/src/linux/arch/sparc/include/asm/unistd.h
-
- The file mentioned above belongs to the Linux Kernel. -->
-
-<syscalls_info>
- <syscall name="restart_syscall" number="0"/>
- <syscall name="exit" number="1"/>
- <syscall name="fork" number="2"/>
- <syscall name="read" number="3"/>
- <syscall name="write" number="4"/>
- <syscall name="open" number="5"/>
- <syscall name="close" number="6"/>
- <syscall name="wait4" number="7"/>
- <syscall name="creat" number="8"/>
- <syscall name="link" number="9"/>
- <syscall name="unlink" number="10"/>
- <syscall name="execv" number="11"/>
- <syscall name="chdir" number="12"/>
- <syscall name="chown" number="13"/>
- <syscall name="mknod" number="14"/>
- <syscall name="chmod" number="15"/>
- <syscall name="lchown" number="16"/>
- <syscall name="brk" number="17"/>
- <syscall name="perfctr" number="18"/>
- <syscall name="lseek" number="19"/>
- <syscall name="getpid" number="20"/>
- <syscall name="capget" number="21"/>
- <syscall name="capset" number="22"/>
- <syscall name="setuid" number="23"/>
- <syscall name="getuid" number="24"/>
- <syscall name="vmsplice" number="25"/>
- <syscall name="ptrace" number="26"/>
- <syscall name="alarm" number="27"/>
- <syscall name="sigaltstack" number="28"/>
- <syscall name="pause" number="29"/>
- <syscall name="utime" number="30"/>
- <syscall name="access" number="33"/>
- <syscall name="nice" number="34"/>
- <syscall name="sync" number="36"/>
- <syscall name="kill" number="37"/>
- <syscall name="stat" number="38"/>
- <syscall name="sendfile" number="39"/>
- <syscall name="lstat" number="40"/>
- <syscall name="dup" number="41"/>
- <syscall name="pipe" number="42"/>
- <syscall name="times" number="43"/>
- <syscall name="umount2" number="45"/>
- <syscall name="setgid" number="46"/>
- <syscall name="getgid" number="47"/>
- <syscall name="signal" number="48"/>
- <syscall name="geteuid" number="49"/>
- <syscall name="getegid" number="50"/>
- <syscall name="acct" number="51"/>
- <syscall name="memory_ordering" number="52"/>
- <syscall name="ioctl" number="54"/>
- <syscall name="reboot" number="55"/>
- <syscall name="symlink" number="57"/>
- <syscall name="readlink" number="58"/>
- <syscall name="execve" number="59"/>
- <syscall name="umask" number="60"/>
- <syscall name="chroot" number="61"/>
- <syscall name="fstat" number="62"/>
- <syscall name="fstat64" number="63"/>
- <syscall name="getpagesize" number="64"/>
- <syscall name="msync" number="65"/>
- <syscall name="vfork" number="66"/>
- <syscall name="pread64" number="67"/>
- <syscall name="pwrite64" number="68"/>
- <syscall name="mmap" number="71"/>
- <syscall name="munmap" number="73"/>
- <syscall name="mprotect" number="74"/>
- <syscall name="madvise" number="75"/>
- <syscall name="vhangup" number="76"/>
- <syscall name="mincore" number="78"/>
- <syscall name="getgroups" number="79"/>
- <syscall name="setgroups" number="80"/>
- <syscall name="getpgrp" number="81"/>
- <syscall name="setitimer" number="83"/>
- <syscall name="swapon" number="85"/>
- <syscall name="getitimer" number="86"/>
- <syscall name="sethostname" number="88"/>
- <syscall name="dup2" number="90"/>
- <syscall name="fcntl" number="92"/>
- <syscall name="select" number="93"/>
- <syscall name="fsync" number="95"/>
- <syscall name="setpriority" number="96"/>
- <syscall name="socket" number="97"/>
- <syscall name="connect" number="98"/>
- <syscall name="accept" number="99"/>
- <syscall name="getpriority" number="100"/>
- <syscall name="rt_sigreturn" number="101"/>
- <syscall name="rt_sigaction" number="102"/>
- <syscall name="rt_sigprocmask" number="103"/>
- <syscall name="rt_sigpending" number="104"/>
- <syscall name="rt_sigtimedwait" number="105"/>
- <syscall name="rt_sigqueueinfo" number="106"/>
- <syscall name="rt_sigsuspend" number="107"/>
- <syscall name="setresuid" number="108"/>
- <syscall name="getresuid" number="109"/>
- <syscall name="setresgid" number="110"/>
- <syscall name="getresgid" number="111"/>
- <syscall name="recvmsg" number="113"/>
- <syscall name="sendmsg" number="114"/>
- <syscall name="gettimeofday" number="116"/>
- <syscall name="getrusage" number="117"/>
- <syscall name="getsockopt" number="118"/>
- <syscall name="getcwd" number="119"/>
- <syscall name="readv" number="120"/>
- <syscall name="writev" number="121"/>
- <syscall name="settimeofday" number="122"/>
- <syscall name="fchown" number="123"/>
- <syscall name="fchmod" number="124"/>
- <syscall name="recvfrom" number="125"/>
- <syscall name="setreuid" number="126"/>
- <syscall name="setregid" number="127"/>
- <syscall name="rename" number="128"/>
- <syscall name="truncate" number="129"/>
- <syscall name="ftruncate" number="130"/>
- <syscall name="flock" number="131"/>
- <syscall name="lstat64" number="132"/>
- <syscall name="sendto" number="133"/>
- <syscall name="shutdown" number="134"/>
- <syscall name="socketpair" number="135"/>
- <syscall name="mkdir" number="136"/>
- <syscall name="rmdir" number="137"/>
- <syscall name="utimes" number="138"/>
- <syscall name="stat64" number="139"/>
- <syscall name="sendfile64" number="140"/>
- <syscall name="getpeername" number="141"/>
- <syscall name="futex" number="142"/>
- <syscall name="gettid" number="143"/>
- <syscall name="getrlimit" number="144"/>
- <syscall name="setrlimit" number="145"/>
- <syscall name="pivot_root" number="146"/>
- <syscall name="prctl" number="147"/>
- <syscall name="pciconfig_read" number="148"/>
- <syscall name="pciconfig_write" number="149"/>
- <syscall name="getsockname" number="150"/>
- <syscall name="inotify_init" number="151"/>
- <syscall name="inotify_add_watch" number="152"/>
- <syscall name="poll" number="153"/>
- <syscall name="getdents64" number="154"/>
- <syscall name="inotify_rm_watch" number="156"/>
- <syscall name="statfs" number="157"/>
- <syscall name="fstatfs" number="158"/>
- <syscall name="umount" number="159"/>
- <syscall name="sched_set_affinity" number="160"/>
- <syscall name="sched_get_affinity" number="161"/>
- <syscall name="getdomainname" number="162"/>
- <syscall name="setdomainname" number="163"/>
- <syscall name="utrap_install" number="164"/>
- <syscall name="quotactl" number="165"/>
- <syscall name="set_tid_address" number="166"/>
- <syscall name="mount" number="167"/>
- <syscall name="ustat" number="168"/>
- <syscall name="setxattr" number="169"/>
- <syscall name="lsetxattr" number="170"/>
- <syscall name="fsetxattr" number="171"/>
- <syscall name="getxattr" number="172"/>
- <syscall name="lgetxattr" number="173"/>
- <syscall name="getdents" number="174"/>
- <syscall name="setsid" number="175"/>
- <syscall name="fchdir" number="176"/>
- <syscall name="fgetxattr" number="177"/>
- <syscall name="listxattr" number="178"/>
- <syscall name="llistxattr" number="179"/>
- <syscall name="flistxattr" number="180"/>
- <syscall name="removexattr" number="181"/>
- <syscall name="lremovexattr" number="182"/>
- <syscall name="sigpending" number="183"/>
- <syscall name="query_module" number="184"/>
- <syscall name="setpgid" number="185"/>
- <syscall name="fremovexattr" number="186"/>
- <syscall name="tkill" number="187"/>
- <syscall name="exit_group" number="188"/>
- <syscall name="uname" number="189"/>
- <syscall name="init_module" number="190"/>
- <syscall name="personality" number="191"/>
- <syscall name="remap_file_pages" number="192"/>
- <syscall name="epoll_create" number="193"/>
- <syscall name="epoll_ctl" number="194"/>
- <syscall name="epoll_wait" number="195"/>
- <syscall name="ioprio_set" number="196"/>
- <syscall name="getppid" number="197"/>
- <syscall name="sigaction" number="198"/>
- <syscall name="sgetmask" number="199"/>
- <syscall name="ssetmask" number="200"/>
- <syscall name="sigsuspend" number="201"/>
- <syscall name="oldlstat" number="202"/>
- <syscall name="uselib" number="203"/>
- <syscall name="readdir" number="204"/>
- <syscall name="readahead" number="205"/>
- <syscall name="socketcall" number="206"/>
- <syscall name="syslog" number="207"/>
- <syscall name="lookup_dcookie" number="208"/>
- <syscall name="fadvise64" number="209"/>
- <syscall name="fadvise64_64" number="210"/>
- <syscall name="tgkill" number="211"/>
- <syscall name="waitpid" number="212"/>
- <syscall name="swapoff" number="213"/>
- <syscall name="sysinfo" number="214"/>
- <syscall name="ipc" number="215"/>
- <syscall name="sigreturn" number="216"/>
- <syscall name="clone" number="217"/>
- <syscall name="ioprio_get" number="218"/>
- <syscall name="adjtimex" number="219"/>
- <syscall name="sigprocmask" number="220"/>
- <syscall name="create_module" number="221"/>
- <syscall name="delete_module" number="222"/>
- <syscall name="get_kernel_syms" number="223"/>
- <syscall name="getpgid" number="224"/>
- <syscall name="bdflush" number="225"/>
- <syscall name="sysfs" number="226"/>
- <syscall name="afs_syscall" number="227"/>
- <syscall name="setfsuid" number="228"/>
- <syscall name="setfsgid" number="229"/>
- <syscall name="_newselect" number="230"/>
- <syscall name="splice" number="232"/>
- <syscall name="stime" number="233"/>
- <syscall name="statfs64" number="234"/>
- <syscall name="fstatfs64" number="235"/>
- <syscall name="_llseek" number="236"/>
- <syscall name="mlock" number="237"/>
- <syscall name="munlock" number="238"/>
- <syscall name="mlockall" number="239"/>
- <syscall name="munlockall" number="240"/>
- <syscall name="sched_setparam" number="241"/>
- <syscall name="sched_getparam" number="242"/>
- <syscall name="sched_setscheduler" number="243"/>
- <syscall name="sched_getscheduler" number="244"/>
- <syscall name="sched_yield" number="245"/>
- <syscall name="sched_get_priority_max" number="246"/>
- <syscall name="sched_get_priority_min" number="247"/>
- <syscall name="sched_rr_get_interval" number="248"/>
- <syscall name="nanosleep" number="249"/>
- <syscall name="mremap" number="250"/>
- <syscall name="_sysctl" number="251"/>
- <syscall name="getsid" number="252"/>
- <syscall name="fdatasync" number="253"/>
- <syscall name="nfsservctl" number="254"/>
- <syscall name="sync_file_range" number="255"/>
- <syscall name="clock_settime" number="256"/>
- <syscall name="clock_gettime" number="257"/>
- <syscall name="clock_getres" number="258"/>
- <syscall name="clock_nanosleep" number="259"/>
- <syscall name="sched_getaffinity" number="260"/>
- <syscall name="sched_setaffinity" number="261"/>
- <syscall name="timer_settime" number="262"/>
- <syscall name="timer_gettime" number="263"/>
- <syscall name="timer_getoverrun" number="264"/>
- <syscall name="timer_delete" number="265"/>
- <syscall name="timer_create" number="266"/>
- <syscall name="vserver" number="267"/>
- <syscall name="io_setup" number="268"/>
- <syscall name="io_destroy" number="269"/>
- <syscall name="io_submit" number="270"/>
- <syscall name="io_cancel" number="271"/>
- <syscall name="io_getevents" number="272"/>
- <syscall name="mq_open" number="273"/>
- <syscall name="mq_unlink" number="274"/>
- <syscall name="mq_timedsend" number="275"/>
- <syscall name="mq_timedreceive" number="276"/>
- <syscall name="mq_notify" number="277"/>
- <syscall name="mq_getsetattr" number="278"/>
- <syscall name="waitid" number="279"/>
- <syscall name="tee" number="280"/>
- <syscall name="add_key" number="281"/>
- <syscall name="request_key" number="282"/>
- <syscall name="keyctl" number="283"/>
- <syscall name="openat" number="284"/>
- <syscall name="mkdirat" number="285"/>
- <syscall name="mknodat" number="286"/>
- <syscall name="fchownat" number="287"/>
- <syscall name="futimesat" number="288"/>
- <syscall name="fstatat64" number="289"/>
- <syscall name="unlinkat" number="290"/>
- <syscall name="renameat" number="291"/>
- <syscall name="linkat" number="292"/>
- <syscall name="symlinkat" number="293"/>
- <syscall name="readlinkat" number="294"/>
- <syscall name="fchmodat" number="295"/>
- <syscall name="faccessat" number="296"/>
- <syscall name="pselect6" number="297"/>
- <syscall name="ppoll" number="298"/>
- <syscall name="unshare" number="299"/>
- <syscall name="set_robust_list" number="300"/>
- <syscall name="get_robust_list" number="301"/>
- <syscall name="migrate_pages" number="302"/>
- <syscall name="mbind" number="303"/>
- <syscall name="get_mempolicy" number="304"/>
- <syscall name="set_mempolicy" number="305"/>
- <syscall name="kexec_load" number="306"/>
- <syscall name="move_pages" number="307"/>
- <syscall name="getcpu" number="308"/>
- <syscall name="epoll_pwait" number="309"/>
- <syscall name="utimensat" number="310"/>
- <syscall name="signalfd" number="311"/>
- <syscall name="timerfd_create" number="312"/>
- <syscall name="eventfd" number="313"/>
- <syscall name="fallocate" number="314"/>
- <syscall name="timerfd_settime" number="315"/>
- <syscall name="timerfd_gettime" number="316"/>
- <syscall name="signalfd4" number="317"/>
- <syscall name="eventfd2" number="318"/>
- <syscall name="epoll_create1" number="319"/>
- <syscall name="dup3" number="320"/>
- <syscall name="pipe2" number="321"/>
- <syscall name="inotify_init1" number="322"/>
- <syscall name="accept4" number="323"/>
- <syscall name="preadv" number="324"/>
- <syscall name="pwritev" number="325"/>
- <syscall name="rt_tgsigqueueinfo" number="326"/>
- <syscall name="perf_event_open" number="327"/>
- <syscall name="recvmmsg" number="328"/>
-</syscalls_info>
diff --git a/share/info/annotate.info b/share/info/annotate.info
deleted file mode 100644
index a1a0963..0000000
--- a/share/info/annotate.info
+++ /dev/null
@@ -1,1192 +0,0 @@
-This is annotate.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gdb/gdb-7.3.x/gdb/doc/annotate.texinfo.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* Annotate: (annotate). The obsolete annotation interface.
-END-INFO-DIR-ENTRY
-
- Copyright (C) 1994, 1995, 2000, 2001, 2003, 2004, 2005, 2007, 2008,
-2009, 2010, 2011 Free Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
- This file documents GDB's obsolete annotations.
-
- Copyright (C) 1994, 1995, 2000, 2001, 2003, 2004, 2005, 2007, 2008,
-2009, 2010, 2011 Free Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
-
-File: annotate.info, Node: Top, Next: Annotations Overview, Up: (dir)
-
-GDB Annotations
-***************
-
-This document describes the obsolete level two annotation interface
-implemented in older GDB versions.
-
-* Menu:
-
-* Annotations Overview:: What annotations are; the general syntax.
-* Limitations:: Limitations of the annotation interface.
-* Migrating to GDB/MI:: Migrating to GDB/MI
-* Server Prefix:: Issuing a command without affecting user state.
-* Value Annotations:: Values are marked as such.
-* Frame Annotations:: Stack frames are annotated.
-* Displays:: GDB can be told to display something periodically.
-* Prompting:: Annotations marking GDB's need for input.
-* Errors:: Annotations for error messages.
-* Breakpoint Info:: Information on breakpoints.
-* Invalidation:: Some annotations describe things now invalid.
-* Annotations for Running::
- Whether the program is running, how it stopped, etc.
-* Source Annotations:: Annotations describing source code.
-* Multi-threaded Apps:: An annotation that reports multi-threadedness.
-
-* GNU Free Documentation License::
-
-
-File: annotate.info, Node: Annotations Overview, Next: Limitations, Prev: Top, Up: Top
-
-1 What is an Annotation?
-************************
-
-To produce obsolete level two annotations, start GDB with the
-`--annotate=2' option.
-
- Annotations start with a newline character, two `control-z'
-characters, and the name of the annotation. If there is no additional
-information associated with this annotation, the name of the annotation
-is followed immediately by a newline. If there is additional
-information, the name of the annotation is followed by a space, the
-additional information, and a newline. The additional information
-cannot contain newline characters.
-
- Any output not beginning with a newline and two `control-z'
-characters denotes literal output from GDB. Currently there is no need
-for GDB to output a newline followed by two `control-z' characters, but
-if there was such a need, the annotations could be extended with an
-`escape' annotation which means those three characters as output.
-
- A simple example of starting up GDB with annotations is:
-
- $ gdb --annotate=2
- GNU GDB 5.0
- Copyright 2000 Free Software Foundation, Inc.
- GDB is free software, covered by the GNU General Public License,
- and you are welcome to change it and/or distribute copies of it
- under certain conditions.
- Type "show copying" to see the conditions.
- There is absolutely no warranty for GDB. Type "show warranty"
- for details.
- This GDB was configured as "sparc-sun-sunos4.1.3"
-
- ^Z^Zpre-prompt
- (gdb)
- ^Z^Zprompt
- quit
-
- ^Z^Zpost-prompt
- $
-
- Here `quit' is input to GDB; the rest is output from GDB. The three
-lines beginning `^Z^Z' (where `^Z' denotes a `control-z' character) are
-annotations; the rest is output from GDB.
-
-
-File: annotate.info, Node: Limitations, Next: Migrating to GDB/MI, Prev: Annotations Overview, Up: Top
-
-2 Limitations of the Annotation Interface
-*****************************************
-
-The level two annotations mechanism is known to have a number of
-technical and architectural limitations. As a consequence, in 2001,
-with the release of GDB 5.1 and the addition of GDB/MI, the annotation
-interface was marked as deprecated.
-
- This chapter discusses the known problems.
-
-2.1 Dependant on CLI output
-===========================
-
-The annotation interface works by interspersing markups with GDB normal
-command-line interpreter output. Unfortunately, this makes the
-annotation client dependant on not just the annotations, but also the
-CLI output. This is because the client is forced to assume that
-specific GDB commands provide specific information. Any change to
-GDB's CLI output modifies or removes that information and,
-consequently, likely breaks the client.
-
- Since the GDB/MI output is independent of the CLI, it does not have
-this problem.
-
-2.2 Scalability
-===============
-
-The annotation interface relies on value annotations (*note Value
-Annotations::) and the display mechanism as a way of obtaining
-up-to-date value information. These mechanisms are not scalable.
-
- In a graphical environment, where many values can be displayed
-simultaneously, a serious performance problem occurs when the client
-tries to first extract from GDB, and then re-display, all those values.
-The client should instead only request and update the values that
-changed.
-
- The GDB/MI Variable Objects provide just that mechanism.
-
-2.3 Correctness
-===============
-
-The annotation interface assumes that a variable's value can only be
-changed when the target is running. This assumption is not correct. A
-single assignment to a single variable can result in the entire target,
-and all displayed values, needing an update.
-
- The GDB/MI Variable Objects include a mechanism for efficiently
-reporting such changes.
-
-2.4 Reliability
-===============
-
-The GDB/MI interface includes a dedicated test directory
-(`gdb/gdb.mi'), and any addition or fix to GDB/MI must include
-testsuite changes.
-
-2.5 Maintainability
-===================
-
-The annotation mechanism was implemented by interspersing CLI print
-statements with various annotations. As a consequence, any CLI output
-change can alter the annotation output.
-
- Since the GDB/MI output is independent of the CLI, and the GDB/MI is
-increasingly implemented independent of the CLI code, its long term
-maintenance is much easier.
-
-
-File: annotate.info, Node: Migrating to GDB/MI, Next: Server Prefix, Prev: Limitations, Up: Top
-
-3 Migrating to GDB/MI
-*********************
-
-By using the `interp mi' command, it is possible for annotation clients
-to invoke GDB/MI commands, and hence access the GDB/MI. By doing this,
-existing annotation clients have a migration path from this obsolete
-interface to GDB/MI.
-
-
-File: annotate.info, Node: Server Prefix, Next: Value Annotations, Prev: Migrating to GDB/MI, Up: Top
-
-4 The Server Prefix
-*******************
-
-To issue a command to GDB without affecting certain aspects of the
-state which is seen by users, prefix it with `server '. This means
-that this command will not affect the command history, nor will it
-affect GDB's notion of which command to repeat if <RET> is pressed on a
-line by itself.
-
- The server prefix does not affect the recording of values into the
-value history; to print a value without recording it into the value
-history, use the `output' command instead of the `print' command.
-
-
-File: annotate.info, Node: Value Annotations, Next: Frame Annotations, Prev: Server Prefix, Up: Top
-
-5 Values
-********
-
-_Value Annotations have been removed. GDB/MI instead provides Variable
-Objects._
-
- When a value is printed in various contexts, GDB uses annotations to
-delimit the value from the surrounding text.
-
- If a value is printed using `print' and added to the value history,
-the annotation looks like
-
- ^Z^Zvalue-history-begin HISTORY-NUMBER VALUE-FLAGS
- HISTORY-STRING
- ^Z^Zvalue-history-value
- THE-VALUE
- ^Z^Zvalue-history-end
-
-where HISTORY-NUMBER is the number it is getting in the value history,
-HISTORY-STRING is a string, such as `$5 = ', which introduces the value
-to the user, THE-VALUE is the output corresponding to the value itself,
-and VALUE-FLAGS is `*' for a value which can be dereferenced and `-'
-for a value which cannot.
-
- If the value is not added to the value history (it is an invalid
-float or it is printed with the `output' command), the annotation is
-similar:
-
- ^Z^Zvalue-begin VALUE-FLAGS
- THE-VALUE
- ^Z^Zvalue-end
-
- When GDB prints an argument to a function (for example, in the output
-from the `backtrace' command), it annotates it as follows:
-
- ^Z^Zarg-begin
- ARGUMENT-NAME
- ^Z^Zarg-name-end
- SEPARATOR-STRING
- ^Z^Zarg-value VALUE-FLAGS
- THE-VALUE
- ^Z^Zarg-end
-
-where ARGUMENT-NAME is the name of the argument, SEPARATOR-STRING is
-text which separates the name from the value for the user's benefit
-(such as `='), and VALUE-FLAGS and THE-VALUE have the same meanings as
-in a `value-history-begin' annotation.
-
- When printing a structure, GDB annotates it as follows:
-
- ^Z^Zfield-begin VALUE-FLAGS
- FIELD-NAME
- ^Z^Zfield-name-end
- SEPARATOR-STRING
- ^Z^Zfield-value
- THE-VALUE
- ^Z^Zfield-end
-
-where FIELD-NAME is the name of the field, SEPARATOR-STRING is text
-which separates the name from the value for the user's benefit (such as
-`='), and VALUE-FLAGS and THE-VALUE have the same meanings as in a
-`value-history-begin' annotation.
-
- When printing an array, GDB annotates it as follows:
-
- ^Z^Zarray-section-begin ARRAY-INDEX VALUE-FLAGS
-
-where ARRAY-INDEX is the index of the first element being annotated and
-VALUE-FLAGS has the same meaning as in a `value-history-begin'
-annotation. This is followed by any number of elements, where is
-element can be either a single element:
-
- `,' WHITESPACE ; omitted for the first element
- THE-VALUE
- ^Z^Zelt
-
- or a repeated element
-
- `,' WHITESPACE ; omitted for the first element
- THE-VALUE
- ^Z^Zelt-rep NUMBER-OF-REPETITIONS
- REPETITION-STRING
- ^Z^Zelt-rep-end
-
- In both cases, THE-VALUE is the output for the value of the element
-and WHITESPACE can contain spaces, tabs, and newlines. In the repeated
-case, NUMBER-OF-REPETITIONS is the number of consecutive array elements
-which contain that value, and REPETITION-STRING is a string which is
-designed to convey to the user that repetition is being depicted.
-
- Once all the array elements have been output, the array annotation is
-ended with
-
- ^Z^Zarray-section-end
-
-
-File: annotate.info, Node: Frame Annotations, Next: Displays, Prev: Value Annotations, Up: Top
-
-6 Frames
-********
-
-_Value Annotations have been removed. GDB/MI instead provides a number
-of frame commands._
-
- _Frame annotations are no longer available. The GDB/MI provides
-`-stack-list-arguments', `-stack-list-locals', and `-stack-list-frames'
-commands._
-
- Whenever GDB prints a frame, it annotates it. For example, this
-applies to frames printed when GDB stops, output from commands such as
-`backtrace' or `up', etc.
-
- The frame annotation begins with
-
- ^Z^Zframe-begin LEVEL ADDRESS
- LEVEL-STRING
-
-where LEVEL is the number of the frame (0 is the innermost frame, and
-other frames have positive numbers), ADDRESS is the address of the code
-executing in that frame, and LEVEL-STRING is a string designed to
-convey the level to the user. ADDRESS is in the form `0x' followed by
-one or more lowercase hex digits (note that this does not depend on the
-language). The frame ends with
-
- ^Z^Zframe-end
-
- Between these annotations is the main body of the frame, which can
-consist of
-
- * ^Z^Zfunction-call
- FUNCTION-CALL-STRING
-
- where FUNCTION-CALL-STRING is text designed to convey to the user
- that this frame is associated with a function call made by GDB to a
- function in the program being debugged.
-
- * ^Z^Zsignal-handler-caller
- SIGNAL-HANDLER-CALLER-STRING
-
- where SIGNAL-HANDLER-CALLER-STRING is text designed to convey to
- the user that this frame is associated with whatever mechanism is
- used by this operating system to call a signal handler (it is the
- frame which calls the signal handler, not the frame for the signal
- handler itself).
-
- * A normal frame.
-
- This can optionally (depending on whether this is thought of as
- interesting information for the user to see) begin with
-
- ^Z^Zframe-address
- ADDRESS
- ^Z^Zframe-address-end
- SEPARATOR-STRING
-
- where ADDRESS is the address executing in the frame (the same
- address as in the `frame-begin' annotation, but printed in a form
- which is intended for user consumption--in particular, the syntax
- varies depending on the language), and SEPARATOR-STRING is a string
- intended to separate this address from what follows for the user's
- benefit.
-
- Then comes
-
- ^Z^Zframe-function-name
- FUNCTION-NAME
- ^Z^Zframe-args
- ARGUMENTS
-
- where FUNCTION-NAME is the name of the function executing in the
- frame, or `??' if not known, and ARGUMENTS are the arguments to
- the frame, with parentheses around them (each argument is annotated
- individually as well, *note Value Annotations::).
-
- If source information is available, a reference to it is then
- printed:
-
- ^Z^Zframe-source-begin
- SOURCE-INTRO-STRING
- ^Z^Zframe-source-file
- FILENAME
- ^Z^Zframe-source-file-end
- :
- ^Z^Zframe-source-line
- LINE-NUMBER
- ^Z^Zframe-source-end
-
- where SOURCE-INTRO-STRING separates for the user's benefit the
- reference from the text which precedes it, FILENAME is the name of
- the source file, and LINE-NUMBER is the line number within that
- file (the first line is line 1).
-
- If GDB prints some information about where the frame is from (which
- library, which load segment, etc.; currently only done on the
- RS/6000), it is annotated with
-
- ^Z^Zframe-where
- INFORMATION
-
- Then, if source is to actually be displayed for this frame (for
- example, this is not true for output from the `backtrace'
- command), then a `source' annotation (*note Source Annotations::)
- is displayed. Unlike most annotations, this is output instead of
- the normal text which would be output, not in addition.
-
-
-File: annotate.info, Node: Displays, Next: Prompting, Prev: Frame Annotations, Up: Top
-
-7 Displays
-**********
-
-_Display Annotations have been removed. GDB/MI instead provides
-Variable Objects._
-
- When GDB is told to display something using the `display' command,
-the results of the display are annotated:
-
- ^Z^Zdisplay-begin
- NUMBER
- ^Z^Zdisplay-number-end
- NUMBER-SEPARATOR
- ^Z^Zdisplay-format
- FORMAT
- ^Z^Zdisplay-expression
- EXPRESSION
- ^Z^Zdisplay-expression-end
- EXPRESSION-SEPARATOR
- ^Z^Zdisplay-value
- VALUE
- ^Z^Zdisplay-end
-
-where NUMBER is the number of the display, NUMBER-SEPARATOR is intended
-to separate the number from what follows for the user, FORMAT includes
-information such as the size, format, or other information about how
-the value is being displayed, EXPRESSION is the expression being
-displayed, EXPRESSION-SEPARATOR is intended to separate the expression
-from the text that follows for the user, and VALUE is the actual value
-being displayed.
-
-
-File: annotate.info, Node: Prompting, Next: Errors, Prev: Displays, Up: Top
-
-8 Annotation for GDB Input
-**************************
-
-When GDB prompts for input, it annotates this fact so it is possible to
-know when to send output, when the output from a given command is over,
-etc.
-
- Different kinds of input each have a different "input type". Each
-input type has three annotations: a `pre-' annotation, which denotes
-the beginning of any prompt which is being output, a plain annotation,
-which denotes the end of the prompt, and then a `post-' annotation
-which denotes the end of any echo which may (or may not) be associated
-with the input. For example, the `prompt' input type features the
-following annotations:
-
- ^Z^Zpre-prompt
- ^Z^Zprompt
- ^Z^Zpost-prompt
-
- The input types are
-
-`prompt'
- When GDB is prompting for a command (the main GDB prompt).
-
-`commands'
- When GDB prompts for a set of commands, like in the `commands'
- command. The annotations are repeated for each command which is
- input.
-
-`overload-choice'
- When GDB wants the user to select between various overloaded
- functions.
-
-`query'
- When GDB wants the user to confirm a potentially dangerous
- operation.
-
-`prompt-for-continue'
- When GDB is asking the user to press return to continue. Note:
- Don't expect this to work well; instead use `set height 0' to
- disable prompting. This is because the counting of lines is buggy
- in the presence of annotations.
-
-
-File: annotate.info, Node: Errors, Next: Breakpoint Info, Prev: Prompting, Up: Top
-
-9 Errors
-********
-
- ^Z^Zquit
-
- This annotation occurs right before GDB responds to an interrupt.
-
- ^Z^Zerror
-
- This annotation occurs right before GDB responds to an error.
-
- Quit and error annotations indicate that any annotations which GDB
-was in the middle of may end abruptly. For example, if a
-`value-history-begin' annotation is followed by a `error', one cannot
-expect to receive the matching `value-history-end'. One cannot expect
-not to receive it either, however; an error annotation does not
-necessarily mean that GDB is immediately returning all the way to the
-top level.
-
- A quit or error annotation may be preceded by
-
- ^Z^Zerror-begin
-
- Any output between that and the quit or error annotation is the error
-message.
-
- Warning messages are not yet annotated.
-
-
-File: annotate.info, Node: Breakpoint Info, Next: Invalidation, Prev: Errors, Up: Top
-
-10 Information on Breakpoints
-*****************************
-
-_Breakpoint Annotations have been removed. GDB/MI instead provides
-breakpoint commands._
-
- The output from the `info breakpoints' command is annotated as
-follows:
-
- ^Z^Zbreakpoints-headers
- HEADER-ENTRY
- ^Z^Zbreakpoints-table
-
-where HEADER-ENTRY has the same syntax as an entry (see below) but
-instead of containing data, it contains strings which are intended to
-convey the meaning of each field to the user. This is followed by any
-number of entries. If a field does not apply for this entry, it is
-omitted. Fields may contain trailing whitespace. Each entry consists
-of:
-
- ^Z^Zrecord
- ^Z^Zfield 0
- NUMBER
- ^Z^Zfield 1
- TYPE
- ^Z^Zfield 2
- DISPOSITION
- ^Z^Zfield 3
- ENABLE
- ^Z^Zfield 4
- ADDRESS
- ^Z^Zfield 5
- WHAT
- ^Z^Zfield 6
- FRAME
- ^Z^Zfield 7
- CONDITION
- ^Z^Zfield 8
- IGNORE-COUNT
- ^Z^Zfield 9
- COMMANDS
-
- Note that ADDRESS is intended for user consumption--the syntax
-varies depending on the language.
-
- The output ends with
-
- ^Z^Zbreakpoints-table-end
-
-
-File: annotate.info, Node: Invalidation, Next: Annotations for Running, Prev: Breakpoint Info, Up: Top
-
-11 Invalidation Notices
-***********************
-
-The following annotations say that certain pieces of state may have
-changed.
-
-`^Z^Zframes-invalid'
- The frames (for example, output from the `backtrace' command) may
- have changed.
-
-`^Z^Zbreakpoints-invalid'
- The breakpoints may have changed. For example, the user just
- added or deleted a breakpoint.
-
-
-File: annotate.info, Node: Annotations for Running, Next: Source Annotations, Prev: Invalidation, Up: Top
-
-12 Running the Program
-**********************
-
-When the program starts executing due to a GDB command such as `step'
-or `continue',
-
- ^Z^Zstarting
-
- is output. When the program stops,
-
- ^Z^Zstopped
-
- is output. Before the `stopped' annotation, a variety of
-annotations describe how the program stopped.
-
-`^Z^Zexited EXIT-STATUS'
- The program exited, and EXIT-STATUS is the exit status (zero for
- successful exit, otherwise nonzero).
-
-`^Z^Zsignalled'
- The program exited with a signal. After the `^Z^Zsignalled', the
- annotation continues:
-
- INTRO-TEXT
- ^Z^Zsignal-name
- NAME
- ^Z^Zsignal-name-end
- MIDDLE-TEXT
- ^Z^Zsignal-string
- STRING
- ^Z^Zsignal-string-end
- END-TEXT
-
- where NAME is the name of the signal, such as `SIGILL' or
- `SIGSEGV', and STRING is the explanation of the signal, such as
- `Illegal Instruction' or `Segmentation fault'. INTRO-TEXT,
- MIDDLE-TEXT, and END-TEXT are for the user's benefit and have no
- particular format.
-
-`^Z^Zsignal'
- The syntax of this annotation is just like `signalled', but GDB is
- just saying that the program received the signal, not that it was
- terminated with it.
-
-`^Z^Zbreakpoint NUMBER'
- The program hit breakpoint number NUMBER.
-
-`^Z^Zwatchpoint NUMBER'
- The program hit watchpoint number NUMBER.
-
-
-File: annotate.info, Node: Source Annotations, Next: Multi-threaded Apps, Prev: Annotations for Running, Up: Top
-
-13 Displaying Source
-********************
-
-The following annotation is used instead of displaying source code:
-
- ^Z^Zsource FILENAME:LINE:CHARACTER:MIDDLE:ADDR
-
- where FILENAME is an absolute file name indicating which source
-file, LINE is the line number within that file (where 1 is the first
-line in the file), CHARACTER is the character position within the file
-(where 0 is the first character in the file) (for most debug formats
-this will necessarily point to the beginning of a line), MIDDLE is
-`middle' if ADDR is in the middle of the line, or `beg' if ADDR is at
-the beginning of the line, and ADDR is the address in the target
-program associated with the source which is being displayed. ADDR is
-in the form `0x' followed by one or more lowercase hex digits (note
-that this does not depend on the language).
-
-
-File: annotate.info, Node: Multi-threaded Apps, Next: GNU Free Documentation License, Prev: Source Annotations, Up: Top
-
-14 Multi-threaded Applications
-******************************
-
-The following annotations report thread related changes of state.
-
-`^Z^Znew-thread'
- This annotation is issued once for each thread that is created
- apart from the main thread, which is not reported.
-
-`^Z^Zthread-changed'
- The selected thread has changed. This may occur at the request of
- the user with the `thread' command, or as a result of execution,
- e.g., another thread hits a breakpoint.
-
-
-
-File: annotate.info, Node: GNU Free Documentation License, Prev: Multi-threaded Apps, Up: Top
-
-Appendix A GNU Free Documentation License
-*****************************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-
-Tag Table:
-Node: Top1366
-Node: Annotations Overview2536
-Node: Limitations4335
-Node: Migrating to GDB/MI6920
-Node: Server Prefix7303
-Node: Value Annotations7949
-Node: Frame Annotations11119
-Node: Displays15018
-Node: Prompting16049
-Node: Errors17552
-Node: Breakpoint Info18442
-Node: Invalidation19667
-Node: Annotations for Running20146
-Node: Source Annotations21659
-Node: Multi-threaded Apps22605
-Node: GNU Free Documentation License23214
-
-End Tag Table
diff --git a/share/info/as.info b/share/info/as.info
deleted file mode 100644
index ecdb875..0000000
--- a/share/info/as.info
+++ /dev/null
@@ -1,22623 +0,0 @@
-This is as.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../binutils/binutils-2.21/gas/doc/as.texinfo.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* As: (as). The GNU assembler.
-* Gas: (as). The GNU assembler.
-END-INFO-DIR-ENTRY
-
- This file documents the GNU Assembler "as".
-
- Copyright (C) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2006, 2007, 2008, 2009, 2010 Free Software
-Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
-
-File: as.info, Node: Top, Next: Overview, Up: (dir)
-
-Using as
-********
-
-This file is a user guide to the GNU assembler `as' (GNU Binutils)
-version 2.21.
-
- This document is distributed under the terms of the GNU Free
-Documentation License. A copy of the license is included in the
-section entitled "GNU Free Documentation License".
-
-* Menu:
-
-* Overview:: Overview
-* Invoking:: Command-Line Options
-* Syntax:: Syntax
-* Sections:: Sections and Relocation
-* Symbols:: Symbols
-* Expressions:: Expressions
-* Pseudo Ops:: Assembler Directives
-
-* Object Attributes:: Object Attributes
-* Machine Dependencies:: Machine Dependent Features
-* Reporting Bugs:: Reporting Bugs
-* Acknowledgements:: Who Did What
-* GNU Free Documentation License:: GNU Free Documentation License
-* AS Index:: AS Index
-
-
-File: as.info, Node: Overview, Next: Invoking, Prev: Top, Up: Top
-
-1 Overview
-**********
-
-Here is a brief summary of how to invoke `as'. For details, see *note
-Command-Line Options: Invoking.
-
- as [-a[cdghlns][=FILE]] [-alternate] [-D]
- [-compress-debug-sections] [-nocompress-debug-sections]
- [-debug-prefix-map OLD=NEW]
- [-defsym SYM=VAL] [-f] [-g] [-gstabs]
- [-gstabs+] [-gdwarf-2] [-help] [-I DIR] [-J]
- [-K] [-L] [-listing-lhs-width=NUM]
- [-listing-lhs-width2=NUM] [-listing-rhs-width=NUM]
- [-listing-cont-lines=NUM] [-keep-locals] [-o
- OBJFILE] [-R] [-reduce-memory-overheads] [-statistics]
- [-v] [-version] [-version] [-W] [-warn]
- [-fatal-warnings] [-w] [-x] [-Z] [@FILE]
- [-target-help] [TARGET-OPTIONS]
- [-|FILES ...]
-
- _Target Alpha options:_
- [-mCPU]
- [-mdebug | -no-mdebug]
- [-replace | -noreplace]
- [-relax] [-g] [-GSIZE]
- [-F] [-32addr]
-
- _Target ARC options:_
- [-marc[5|6|7|8]]
- [-EB|-EL]
-
- _Target ARM options:_
- [-mcpu=PROCESSOR[+EXTENSION...]]
- [-march=ARCHITECTURE[+EXTENSION...]]
- [-mfpu=FLOATING-POINT-FORMAT]
- [-mfloat-abi=ABI]
- [-meabi=VER]
- [-mthumb]
- [-EB|-EL]
- [-mapcs-32|-mapcs-26|-mapcs-float|
- -mapcs-reentrant]
- [-mthumb-interwork] [-k]
-
- _Target Blackfin options:_
- [-mcpu=PROCESSOR[-SIREVISION]]
- [-mfdpic]
- [-mno-fdpic]
- [-mnopic]
-
- _Target CRIS options:_
- [-underscore | -no-underscore]
- [-pic] [-N]
- [-emulation=criself | -emulation=crisaout]
- [-march=v0_v10 | -march=v10 | -march=v32 | -march=common_v10_v32]
-
- _Target D10V options:_
- [-O]
-
- _Target D30V options:_
- [-O|-n|-N]
-
- _Target H8/300 options:_
- [-h-tick-hex]
-
- _Target i386 options:_
- [-32|-64] [-n]
- [-march=CPU[+EXTENSION...]] [-mtune=CPU]
-
- _Target i960 options:_
- [-ACA|-ACA_A|-ACB|-ACC|-AKA|-AKB|
- -AKC|-AMC]
- [-b] [-no-relax]
-
- _Target IA-64 options:_
- [-mconstant-gp|-mauto-pic]
- [-milp32|-milp64|-mlp64|-mp64]
- [-mle|mbe]
- [-mtune=itanium1|-mtune=itanium2]
- [-munwind-check=warning|-munwind-check=error]
- [-mhint.b=ok|-mhint.b=warning|-mhint.b=error]
- [-x|-xexplicit] [-xauto] [-xdebug]
-
- _Target IP2K options:_
- [-mip2022|-mip2022ext]
-
- _Target M32C options:_
- [-m32c|-m16c] [-relax] [-h-tick-hex]
-
- _Target M32R options:_
- [-m32rx|-[no-]warn-explicit-parallel-conflicts|
- -W[n]p]
-
- _Target M680X0 options:_
- [-l] [-m68000|-m68010|-m68020|...]
-
- _Target M68HC11 options:_
- [-m68hc11|-m68hc12|-m68hcs12]
- [-mshort|-mlong]
- [-mshort-double|-mlong-double]
- [-force-long-branches] [-short-branches]
- [-strict-direct-mode] [-print-insn-syntax]
- [-print-opcodes] [-generate-example]
-
- _Target MCORE options:_
- [-jsri2bsr] [-sifilter] [-relax]
- [-mcpu=[210|340]]
- _Target MICROBLAZE options:_
-
- _Target MIPS options:_
- [-nocpp] [-EL] [-EB] [-O[OPTIMIZATION LEVEL]]
- [-g[DEBUG LEVEL]] [-G NUM] [-KPIC] [-call_shared]
- [-non_shared] [-xgot [-mvxworks-pic]
- [-mabi=ABI] [-32] [-n32] [-64] [-mfp32] [-mgp32]
- [-march=CPU] [-mtune=CPU] [-mips1] [-mips2]
- [-mips3] [-mips4] [-mips5] [-mips32] [-mips32r2]
- [-mips64] [-mips64r2]
- [-construct-floats] [-no-construct-floats]
- [-trap] [-no-break] [-break] [-no-trap]
- [-mips16] [-no-mips16]
- [-msmartmips] [-mno-smartmips]
- [-mips3d] [-no-mips3d]
- [-mdmx] [-no-mdmx]
- [-mdsp] [-mno-dsp]
- [-mdspr2] [-mno-dspr2]
- [-mmt] [-mno-mt]
- [-mfix7000] [-mno-fix7000]
- [-mfix-vr4120] [-mno-fix-vr4120]
- [-mfix-vr4130] [-mno-fix-vr4130]
- [-mdebug] [-no-mdebug]
- [-mpdr] [-mno-pdr]
-
- _Target MMIX options:_
- [-fixed-special-register-names] [-globalize-symbols]
- [-gnu-syntax] [-relax] [-no-predefined-symbols]
- [-no-expand] [-no-merge-gregs] [-x]
- [-linker-allocated-gregs]
-
- _Target PDP11 options:_
- [-mpic|-mno-pic] [-mall] [-mno-extensions]
- [-mEXTENSION|-mno-EXTENSION]
- [-mCPU] [-mMACHINE]
-
- _Target picoJava options:_
- [-mb|-me]
-
- _Target PowerPC options:_
- [-mpwrx|-mpwr2|-mpwr|-m601|-mppc|-mppc32|-m603|-m604|
- -m403|-m405|-mppc64|-m620|-mppc64bridge|-mbooke]
- [-mcom|-many|-maltivec|-mvsx] [-memb]
- [-mregnames|-mno-regnames]
- [-mrelocatable|-mrelocatable-lib]
- [-mlittle|-mlittle-endian|-mbig|-mbig-endian]
- [-msolaris|-mno-solaris]
-
- _Target RX options:_
- [-mlittle-endian|-mbig-endian]
- [-m32bit-ints|-m16bit-ints]
- [-m32bit-doubles|-m64bit-doubles]
-
- _Target s390 options:_
- [-m31|-m64] [-mesa|-mzarch] [-march=CPU]
- [-mregnames|-mno-regnames]
- [-mwarn-areg-zero]
-
- _Target SCORE options:_
- [-EB][-EL][-FIXDD][-NWARN]
- [-SCORE5][-SCORE5U][-SCORE7][-SCORE3]
- [-march=score7][-march=score3]
- [-USE_R1][-KPIC][-O0][-G NUM][-V]
-
- _Target SPARC options:_
- [-Av6|-Av7|-Av8|-Asparclet|-Asparclite
- -Av8plus|-Av8plusa|-Av9|-Av9a]
- [-xarch=v8plus|-xarch=v8plusa] [-bump]
- [-32|-64]
-
- _Target TIC54X options:_
- [-mcpu=54[123589]|-mcpu=54[56]lp] [-mfar-mode|-mf]
- [-merrors-to-file <FILENAME>|-me <FILENAME>]
-
-
- _Target TIC6X options:_
- [-march=ARCH] [-matomic|-mno-atomic]
- [-mbig-endian|-mlittle-endian] [-mdsbt|-mno-dsbt]
- [-mpid=no|-mpid=near|-mpid=far] [-mpic|-mno-pic]
-
-
- _Target Z80 options:_
- [-z80] [-r800]
- [ -ignore-undocumented-instructions] [-Wnud]
- [ -ignore-unportable-instructions] [-Wnup]
- [ -warn-undocumented-instructions] [-Wud]
- [ -warn-unportable-instructions] [-Wup]
- [ -forbid-undocumented-instructions] [-Fud]
- [ -forbid-unportable-instructions] [-Fup]
-
-
- _Target Xtensa options:_
- [-[no-]text-section-literals] [-[no-]absolute-literals]
- [-[no-]target-align] [-[no-]longcalls]
- [-[no-]transform]
- [-rename-section OLDNAME=NEWNAME]
-
-`@FILE'
- Read command-line options from FILE. The options read are
- inserted in place of the original @FILE option. If FILE does not
- exist, or cannot be read, then the option will be treated
- literally, and not removed.
-
- Options in FILE are separated by whitespace. A whitespace
- character may be included in an option by surrounding the entire
- option in either single or double quotes. Any character
- (including a backslash) may be included by prefixing the character
- to be included with a backslash. The FILE may itself contain
- additional @FILE options; any such options will be processed
- recursively.
-
-`-a[cdghlmns]'
- Turn on listings, in any of a variety of ways:
-
- `-ac'
- omit false conditionals
-
- `-ad'
- omit debugging directives
-
- `-ag'
- include general information, like as version and options
- passed
-
- `-ah'
- include high-level source
-
- `-al'
- include assembly
-
- `-am'
- include macro expansions
-
- `-an'
- omit forms processing
-
- `-as'
- include symbols
-
- `=file'
- set the name of the listing file
-
- You may combine these options; for example, use `-aln' for assembly
- listing without forms processing. The `=file' option, if used,
- must be the last one. By itself, `-a' defaults to `-ahls'.
-
-`--alternate'
- Begin in alternate macro mode. *Note `.altmacro': Altmacro.
-
-`--compress-debug-sections'
- Compress DWARF debug sections using zlib. The debug sections are
- renamed to begin with `.zdebug', and the resulting object file may
- not be compatible with older linkers and object file utilities.
-
-`--nocompress-debug-sections'
- Do not compress DWARF debug sections. This is the default.
-
-`-D'
- Ignored. This option is accepted for script compatibility with
- calls to other assemblers.
-
-`--debug-prefix-map OLD=NEW'
- When assembling files in directory `OLD', record debugging
- information describing them as in `NEW' instead.
-
-`--defsym SYM=VALUE'
- Define the symbol SYM to be VALUE before assembling the input file.
- VALUE must be an integer constant. As in C, a leading `0x'
- indicates a hexadecimal value, and a leading `0' indicates an octal
- value. The value of the symbol can be overridden inside a source
- file via the use of a `.set' pseudo-op.
-
-`-f'
- "fast"--skip whitespace and comment preprocessing (assume source is
- compiler output).
-
-`-g'
-`--gen-debug'
- Generate debugging information for each assembler source line
- using whichever debug format is preferred by the target. This
- currently means either STABS, ECOFF or DWARF2.
-
-`--gstabs'
- Generate stabs debugging information for each assembler line. This
- may help debugging assembler code, if the debugger can handle it.
-
-`--gstabs+'
- Generate stabs debugging information for each assembler line, with
- GNU extensions that probably only gdb can handle, and that could
- make other debuggers crash or refuse to read your program. This
- may help debugging assembler code. Currently the only GNU
- extension is the location of the current working directory at
- assembling time.
-
-`--gdwarf-2'
- Generate DWARF2 debugging information for each assembler line.
- This may help debugging assembler code, if the debugger can handle
- it. Note--this option is only supported by some targets, not all
- of them.
-
-`--help'
- Print a summary of the command line options and exit.
-
-`--target-help'
- Print a summary of all target specific options and exit.
-
-`-I DIR'
- Add directory DIR to the search list for `.include' directives.
-
-`-J'
- Don't warn about signed overflow.
-
-`-K'
- Issue warnings when difference tables altered for long
- displacements.
-
-`-L'
-`--keep-locals'
- Keep (in the symbol table) local symbols. These symbols start with
- system-specific local label prefixes, typically `.L' for ELF
- systems or `L' for traditional a.out systems. *Note Symbol
- Names::.
-
-`--listing-lhs-width=NUMBER'
- Set the maximum width, in words, of the output data column for an
- assembler listing to NUMBER.
-
-`--listing-lhs-width2=NUMBER'
- Set the maximum width, in words, of the output data column for
- continuation lines in an assembler listing to NUMBER.
-
-`--listing-rhs-width=NUMBER'
- Set the maximum width of an input source line, as displayed in a
- listing, to NUMBER bytes.
-
-`--listing-cont-lines=NUMBER'
- Set the maximum number of lines printed in a listing for a single
- line of input to NUMBER + 1.
-
-`-o OBJFILE'
- Name the object-file output from `as' OBJFILE.
-
-`-R'
- Fold the data section into the text section.
-
- Set the default size of GAS's hash tables to a prime number close
- to NUMBER. Increasing this value can reduce the length of time it
- takes the assembler to perform its tasks, at the expense of
- increasing the assembler's memory requirements. Similarly
- reducing this value can reduce the memory requirements at the
- expense of speed.
-
-`--reduce-memory-overheads'
- This option reduces GAS's memory requirements, at the expense of
- making the assembly processes slower. Currently this switch is a
- synonym for `--hash-size=4051', but in the future it may have
- other effects as well.
-
-`--statistics'
- Print the maximum space (in bytes) and total time (in seconds)
- used by assembly.
-
-`--strip-local-absolute'
- Remove local absolute symbols from the outgoing symbol table.
-
-`-v'
-`-version'
- Print the `as' version.
-
-`--version'
- Print the `as' version and exit.
-
-`-W'
-`--no-warn'
- Suppress warning messages.
-
-`--fatal-warnings'
- Treat warnings as errors.
-
-`--warn'
- Don't suppress warning messages or treat them as errors.
-
-`-w'
- Ignored.
-
-`-x'
- Ignored.
-
-`-Z'
- Generate an object file even after errors.
-
-`-- | FILES ...'
- Standard input, or source files to assemble.
-
-
- The following options are available when as is configured for an ARC
-processor.
-
-`-marc[5|6|7|8]'
- This option selects the core processor variant.
-
-`-EB | -EL'
- Select either big-endian (-EB) or little-endian (-EL) output.
-
- The following options are available when as is configured for the ARM
-processor family.
-
-`-mcpu=PROCESSOR[+EXTENSION...]'
- Specify which ARM processor variant is the target.
-
-`-march=ARCHITECTURE[+EXTENSION...]'
- Specify which ARM architecture variant is used by the target.
-
-`-mfpu=FLOATING-POINT-FORMAT'
- Select which Floating Point architecture is the target.
-
-`-mfloat-abi=ABI'
- Select which floating point ABI is in use.
-
-`-mthumb'
- Enable Thumb only instruction decoding.
-
-`-mapcs-32 | -mapcs-26 | -mapcs-float | -mapcs-reentrant'
- Select which procedure calling convention is in use.
-
-`-EB | -EL'
- Select either big-endian (-EB) or little-endian (-EL) output.
-
-`-mthumb-interwork'
- Specify that the code has been generated with interworking between
- Thumb and ARM code in mind.
-
-`-k'
- Specify that PIC code has been generated.
-
- The following options are available when as is configured for the
-Blackfin processor family.
-
-`-mcpu=PROCESSOR[-SIREVISION]'
- This option specifies the target processor. The optional
- SIREVISION is not used in assembler.
-
-`-mfdpic'
- Assemble for the FDPIC ABI.
-
-`-mno-fdpic'
-`-mnopic'
- Disable -mfdpic.
-
- See the info pages for documentation of the CRIS-specific options.
-
- The following options are available when as is configured for a D10V
-processor.
-`-O'
- Optimize output by parallelizing instructions.
-
- The following options are available when as is configured for a D30V
-processor.
-`-O'
- Optimize output by parallelizing instructions.
-
-`-n'
- Warn when nops are generated.
-
-`-N'
- Warn when a nop after a 32-bit multiply instruction is generated.
-
- The following options are available when as is configured for the
-Intel 80960 processor.
-
-`-ACA | -ACA_A | -ACB | -ACC | -AKA | -AKB | -AKC | -AMC'
- Specify which variant of the 960 architecture is the target.
-
-`-b'
- Add code to collect statistics about branches taken.
-
-`-no-relax'
- Do not alter compare-and-branch instructions for long
- displacements; error if necessary.
-
-
- The following options are available when as is configured for the
-Ubicom IP2K series.
-
-`-mip2022ext'
- Specifies that the extended IP2022 instructions are allowed.
-
-`-mip2022'
- Restores the default behaviour, which restricts the permitted
- instructions to just the basic IP2022 ones.
-
-
- The following options are available when as is configured for the
-Renesas M32C and M16C processors.
-
-`-m32c'
- Assemble M32C instructions.
-
-`-m16c'
- Assemble M16C instructions (the default).
-
-`-relax'
- Enable support for link-time relaxations.
-
-`-h-tick-hex'
- Support H'00 style hex constants in addition to 0x00 style.
-
-
- The following options are available when as is configured for the
-Renesas M32R (formerly Mitsubishi M32R) series.
-
-`--m32rx'
- Specify which processor in the M32R family is the target. The
- default is normally the M32R, but this option changes it to the
- M32RX.
-
-`--warn-explicit-parallel-conflicts or --Wp'
- Produce warning messages when questionable parallel constructs are
- encountered.
-
-`--no-warn-explicit-parallel-conflicts or --Wnp'
- Do not produce warning messages when questionable parallel
- constructs are encountered.
-
-
- The following options are available when as is configured for the
-Motorola 68000 series.
-
-`-l'
- Shorten references to undefined symbols, to one word instead of
- two.
-
-`-m68000 | -m68008 | -m68010 | -m68020 | -m68030'
-`| -m68040 | -m68060 | -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.
-
-`-m68881 | -m68882 | -mno-68881 | -mno-68882'
- The target machine does (or does not) have a floating-point
- coprocessor. The default is to assume a coprocessor for 68020,
- 68030, and cpu32. Although the basic 68000 is not compatible with
- the 68881, a combination of the two can be specified, since it's
- possible to do emulation of the coprocessor instructions with the
- main processor.
-
-`-m68851 | -mno-68851'
- The target machine does (or does not) have a memory-management
- unit coprocessor. The default is to assume an MMU for 68020 and
- up.
-
-
- For details about the PDP-11 machine dependent features options, see
-*note PDP-11-Options::.
-
-`-mpic | -mno-pic'
- Generate position-independent (or position-dependent) code. The
- default is `-mpic'.
-
-`-mall'
-`-mall-extensions'
- Enable all instruction set extensions. This is the default.
-
-`-mno-extensions'
- Disable all instruction set extensions.
-
-`-mEXTENSION | -mno-EXTENSION'
- Enable (or disable) a particular instruction set extension.
-
-`-mCPU'
- Enable the instruction set extensions supported by a particular
- CPU, and disable all other extensions.
-
-`-mMACHINE'
- Enable the instruction set extensions supported by a particular
- machine model, and disable all other extensions.
-
- The following options are available when as is configured for a
-picoJava processor.
-
-`-mb'
- Generate "big endian" format output.
-
-`-ml'
- Generate "little endian" format output.
-
-
- The following options are available when as is configured for the
-Motorola 68HC11 or 68HC12 series.
-
-`-m68hc11 | -m68hc12 | -m68hcs12'
- Specify what processor is the target. The default is defined by
- the configuration option when building the assembler.
-
-`-mshort'
- Specify to use the 16-bit integer ABI.
-
-`-mlong'
- Specify to use the 32-bit integer ABI.
-
-`-mshort-double'
- Specify to use the 32-bit double ABI.
-
-`-mlong-double'
- Specify to use the 64-bit double ABI.
-
-`--force-long-branches'
- Relative branches are turned into absolute ones. This concerns
- conditional branches, unconditional branches and branches to a sub
- routine.
-
-`-S | --short-branches'
- Do not turn relative branches into absolute ones when the offset
- is out of range.
-
-`--strict-direct-mode'
- Do not turn the direct addressing mode into extended addressing
- mode when the instruction does not support direct addressing mode.
-
-`--print-insn-syntax'
- Print the syntax of instruction in case of error.
-
-`--print-opcodes'
- print the list of instructions with syntax and then exit.
-
-`--generate-example'
- print an example of instruction for each possible instruction and
- then exit. This option is only useful for testing `as'.
-
-
- The following options are available when `as' is configured for the
-SPARC architecture:
-
-`-Av6 | -Av7 | -Av8 | -Asparclet | -Asparclite'
-`-Av8plus | -Av8plusa | -Av9 | -Av9a'
- Explicitly select a variant of the SPARC architecture.
-
- `-Av8plus' and `-Av8plusa' select a 32 bit environment. `-Av9'
- and `-Av9a' select a 64 bit environment.
-
- `-Av8plusa' and `-Av9a' enable the SPARC V9 instruction set with
- UltraSPARC extensions.
-
-`-xarch=v8plus | -xarch=v8plusa'
- For compatibility with the Solaris v9 assembler. These options are
- equivalent to -Av8plus and -Av8plusa, respectively.
-
-`-bump'
- Warn when the assembler switches to another architecture.
-
- The following options are available when as is configured for the
-'c54x architecture.
-
-`-mfar-mode'
- Enable extended addressing mode. All addresses and relocations
- will assume extended addressing (usually 23 bits).
-
-`-mcpu=CPU_VERSION'
- Sets the CPU version being compiled for.
-
-`-merrors-to-file FILENAME'
- Redirect error output to a file, for broken systems which don't
- support such behaviour in the shell.
-
- The following options are available when as is configured for a MIPS
-processor.
-
-`-G NUM'
- This option sets the largest size of an object that can be
- referenced implicitly with the `gp' register. It is only accepted
- for targets that use ECOFF format, such as a DECstation running
- Ultrix. The default value is 8.
-
-`-EB'
- Generate "big endian" format output.
-
-`-EL'
- Generate "little endian" format output.
-
-`-mips1'
-`-mips2'
-`-mips3'
-`-mips4'
-`-mips5'
-`-mips32'
-`-mips32r2'
-`-mips64'
-`-mips64r2'
- Generate code for a particular MIPS Instruction Set Architecture
- level. `-mips1' is an alias for `-march=r3000', `-mips2' is an
- alias for `-march=r6000', `-mips3' is an alias for `-march=r4000'
- and `-mips4' is an alias for `-march=r8000'. `-mips5', `-mips32',
- `-mips32r2', `-mips64', and `-mips64r2' correspond to generic
- `MIPS V', `MIPS32', `MIPS32 Release 2', `MIPS64', and `MIPS64
- Release 2' ISA processors, respectively.
-
-`-march=CPU'
- Generate code for a particular MIPS cpu.
-
-`-mtune=CPU'
- Schedule and tune for a particular MIPS cpu.
-
-`-mfix7000'
-`-mno-fix7000'
- Cause nops to be inserted if the read of the destination register
- of an mfhi or mflo instruction occurs in the following two
- instructions.
-
-`-mdebug'
-`-no-mdebug'
- Cause stabs-style debugging output to go into an ECOFF-style
- .mdebug section instead of the standard ELF .stabs sections.
-
-`-mpdr'
-`-mno-pdr'
- Control generation of `.pdr' sections.
-
-`-mgp32'
-`-mfp32'
- The register sizes are normally inferred from the ISA and ABI, but
- these flags force a certain group of registers to be treated as 32
- bits wide at all times. `-mgp32' controls the size of
- general-purpose registers and `-mfp32' controls the size of
- floating-point registers.
-
-`-mips16'
-`-no-mips16'
- Generate code for the MIPS 16 processor. This is equivalent to
- putting `.set mips16' at the start of the assembly file.
- `-no-mips16' turns off this option.
-
-`-msmartmips'
-`-mno-smartmips'
- Enables the SmartMIPS extension to the MIPS32 instruction set.
- This is equivalent to putting `.set smartmips' at the start of the
- assembly file. `-mno-smartmips' turns off this option.
-
-`-mips3d'
-`-no-mips3d'
- Generate code for the MIPS-3D Application Specific Extension.
- This tells the assembler to accept MIPS-3D instructions.
- `-no-mips3d' turns off this option.
-
-`-mdmx'
-`-no-mdmx'
- Generate code for the MDMX Application Specific Extension. This
- tells the assembler to accept MDMX instructions. `-no-mdmx' turns
- off this option.
-
-`-mdsp'
-`-mno-dsp'
- Generate code for the DSP Release 1 Application Specific Extension.
- This tells the assembler to accept DSP Release 1 instructions.
- `-mno-dsp' turns off this option.
-
-`-mdspr2'
-`-mno-dspr2'
- Generate code for the DSP Release 2 Application Specific Extension.
- This option implies -mdsp. This tells the assembler to accept DSP
- Release 2 instructions. `-mno-dspr2' turns off this option.
-
-`-mmt'
-`-mno-mt'
- Generate code for the MT Application Specific Extension. This
- tells the assembler to accept MT instructions. `-mno-mt' turns
- off this option.
-
-`--construct-floats'
-`--no-construct-floats'
- The `--no-construct-floats' option disables the construction of
- double width floating point constants by loading the two halves of
- the value into the two single width floating point registers that
- make up the double width register. By default
- `--construct-floats' is selected, allowing construction of these
- floating point constants.
-
-`--emulation=NAME'
- This option causes `as' to emulate `as' configured for some other
- target, in all respects, including output format (choosing between
- ELF and ECOFF only), handling of pseudo-opcodes which may generate
- debugging information or store symbol table information, and
- default endianness. The available configuration names are:
- `mipsecoff', `mipself', `mipslecoff', `mipsbecoff', `mipslelf',
- `mipsbelf'. The first two do not alter the default endianness
- from that of the primary target for which the assembler was
- configured; the others change the default to little- or big-endian
- as indicated by the `b' or `l' in the name. Using `-EB' or `-EL'
- will override the endianness selection in any case.
-
- This option is currently supported only when the primary target
- `as' is configured for is a MIPS ELF or ECOFF target.
- Furthermore, the primary target or others specified with
- `--enable-targets=...' at configuration time must include support
- for the other format, if both are to be available. For example,
- the Irix 5 configuration includes support for both.
-
- Eventually, this option will support more configurations, with more
- fine-grained control over the assembler's behavior, and will be
- supported for more processors.
-
-`-nocpp'
- `as' ignores this option. It is accepted for compatibility with
- the native tools.
-
-`--trap'
-`--no-trap'
-`--break'
-`--no-break'
- Control how to deal with multiplication overflow and division by
- zero. `--trap' or `--no-break' (which are synonyms) take a trap
- exception (and only work for Instruction Set Architecture level 2
- and higher); `--break' or `--no-trap' (also synonyms, and the
- default) take a break exception.
-
-`-n'
- When this option is used, `as' will issue a warning every time it
- generates a nop instruction from a macro.
-
- The following options are available when as is configured for an
-MCore processor.
-
-`-jsri2bsr'
-`-nojsri2bsr'
- Enable or disable the JSRI to BSR transformation. By default this
- is enabled. The command line option `-nojsri2bsr' can be used to
- disable it.
-
-`-sifilter'
-`-nosifilter'
- Enable or disable the silicon filter behaviour. By default this
- is disabled. The default can be overridden by the `-sifilter'
- command line option.
-
-`-relax'
- Alter jump instructions for long displacements.
-
-`-mcpu=[210|340]'
- Select the cpu type on the target hardware. This controls which
- instructions can be assembled.
-
-`-EB'
- Assemble for a big endian target.
-
-`-EL'
- Assemble for a little endian target.
-
-
- See the info pages for documentation of the MMIX-specific options.
-
- See the info pages for documentation of the RX-specific options.
-
- The following options are available when as is configured for the
-s390 processor family.
-
-`-m31'
-`-m64'
- Select the word size, either 31/32 bits or 64 bits.
-
-`-mesa'
-
-`-mzarch'
- Select the architecture mode, either the Enterprise System
- Architecture (esa) or the z/Architecture mode (zarch).
-
-`-march=PROCESSOR'
- Specify which s390 processor variant is the target, `g6', `g6',
- `z900', `z990', `z9-109', `z9-ec', or `z10'.
-
-`-mregnames'
-`-mno-regnames'
- Allow or disallow symbolic names for registers.
-
-`-mwarn-areg-zero'
- Warn whenever the operand for a base or index register has been
- specified but evaluates to zero.
-
- The following options are available when as is configured for a
-TMS320C6000 processor.
-
-`-march=ARCH'
- Enable (only) instructions from architecture ARCH. By default,
- all instructions are permitted.
-
- The following values of ARCH are accepted: `c62x', `c64x',
- `c64x+', `c67x', `c67x+', `c674x'.
-
-`-matomic'
-`-mno-atomic'
- Enable or disable the optional C64x+ atomic operation instructions.
- By default, they are enabled if no `-march' option is given, or if
- an architecture is specified with `-march' that implies these
- instructions are present (currently, there are no such
- architectures); they are disabled if an architecture is specified
- with `-march' on which the instructions are optional or not
- present. This option overrides such a default from the
- architecture, independent of the order in which the `-march' or
- `-matomic' or `-mno-atomic' options are passed.
-
-`-mdsbt'
-`-mno-dsbt'
- The `-mdsbt' option causes the assembler to generate the
- `Tag_ABI_DSBT' attribute with a value of 1, indicating that the
- code is using DSBT addressing. The `-mno-dsbt' option, the
- default, causes the tag to have a value of 0, indicating that the
- code does not use DSBT addressing. The linker will emit a warning
- if objects of different type (DSBT and non-DSBT) are linked
- together.
-
-`-mpid=no'
-`-mpid=near'
-`-mpid=far'
- The `-mpid=' option causes the assembler to generate the
- `Tag_ABI_PID' attribute with a value indicating the form of data
- addressing used by the code. `-mpid=no', the default, indicates
- position-dependent data addressing, `-mpid=near' indicates
- position-independent addressing with GOT accesses using near DP
- addressing, and `-mpid=far' indicates position-independent
- addressing with GOT accesses using far DP addressing. The linker
- will emit a warning if objects built with different settings of
- this option are linked together.
-
-`-mpic'
-`-mno-pic'
- The `-mpic' option causes the assembler to generate the
- `Tag_ABI_PIC' attribute with a value of 1, indicating that the
- code is using position-independent code addressing, The
- `-mno-pic' option, the default, causes the tag to have a value of
- 0, indicating position-dependent code addressing. The linker will
- emit a warning if objects of different type (position-dependent and
- position-independent) are linked together.
-
-`-mbig-endian'
-`-mlittle-endian'
- Generate code for the specified endianness. The default is
- little-endian.
-
- The following options are available when as is configured for an
-Xtensa processor.
-
-`--text-section-literals | --no-text-section-literals'
- With `--text-section-literals', literal pools are interspersed in
- the text section. The default is `--no-text-section-literals',
- which places literals in a separate section in the output file.
- These options only affect literals referenced via PC-relative
- `L32R' instructions; literals for absolute mode `L32R'
- instructions are handled separately.
-
-`--absolute-literals | --no-absolute-literals'
- Indicate to the assembler whether `L32R' instructions use absolute
- or PC-relative addressing. The default is to assume absolute
- addressing if the Xtensa processor includes the absolute `L32R'
- addressing option. Otherwise, only the PC-relative `L32R' mode
- can be used.
-
-`--target-align | --no-target-align'
- Enable or disable automatic alignment to reduce branch penalties
- at the expense of some code density. The default is
- `--target-align'.
-
-`--longcalls | --no-longcalls'
- Enable or disable transformation of call instructions to allow
- calls across a greater range of addresses. The default is
- `--no-longcalls'.
-
-`--transform | --no-transform'
- Enable or disable all assembler transformations of Xtensa
- instructions. The default is `--transform'; `--no-transform'
- should be used only in the rare cases when the instructions must
- be exactly as specified in the assembly source.
-
-`--rename-section OLDNAME=NEWNAME'
- When generating output sections, rename the OLDNAME section to
- NEWNAME.
-
- The following options are available when as is configured for a Z80
-family processor.
-`-z80'
- Assemble for Z80 processor.
-
-`-r800'
- Assemble for R800 processor.
-
-`-ignore-undocumented-instructions'
-`-Wnud'
- Assemble undocumented Z80 instructions that also work on R800
- without warning.
-
-`-ignore-unportable-instructions'
-`-Wnup'
- Assemble all undocumented Z80 instructions without warning.
-
-`-warn-undocumented-instructions'
-`-Wud'
- Issue a warning for undocumented Z80 instructions that also work
- on R800.
-
-`-warn-unportable-instructions'
-`-Wup'
- Issue a warning for undocumented Z80 instructions that do not work
- on R800.
-
-`-forbid-undocumented-instructions'
-`-Fud'
- Treat all undocumented instructions as errors.
-
-`-forbid-unportable-instructions'
-`-Fup'
- Treat undocumented Z80 instructions that do not work on R800 as
- errors.
-
-* Menu:
-
-* Manual:: Structure of this Manual
-* GNU Assembler:: The GNU Assembler
-* Object Formats:: Object File Formats
-* Command Line:: Command Line
-* Input Files:: Input Files
-* Object:: Output (Object) File
-* Errors:: Error and Warning Messages
-
-
-File: as.info, Node: Manual, Next: GNU Assembler, Up: Overview
-
-1.1 Structure of this Manual
-============================
-
-This manual is intended to describe what you need to know to use GNU
-`as'. We cover the syntax expected in source files, including notation
-for symbols, constants, and expressions; the directives that `as'
-understands; and of course how to invoke `as'.
-
- This manual also describes some of the machine-dependent features of
-various flavors of the assembler.
-
- On the other hand, this manual is _not_ intended as an introduction
-to programming in assembly language--let alone programming in general!
-In a similar vein, we make no attempt to introduce the machine
-architecture; we do _not_ describe the instruction set, standard
-mnemonics, registers or addressing modes that are standard to a
-particular architecture. You may want to consult the manufacturer's
-machine architecture manual for this information.
-
-
-File: as.info, Node: GNU Assembler, Next: Object Formats, Prev: Manual, Up: Overview
-
-1.2 The GNU Assembler
-=====================
-
-GNU `as' is really a family of assemblers. If you use (or have used)
-the GNU assembler on one architecture, you should find a fairly similar
-environment when you use it on another architecture. Each version has
-much in common with the others, including object file formats, most
-assembler directives (often called "pseudo-ops") and assembler syntax.
-
- `as' is primarily intended to assemble the output of the GNU C
-compiler `gcc' for use by the linker `ld'. Nevertheless, we've tried
-to make `as' assemble correctly everything that other assemblers for
-the same machine would assemble. Any exceptions are documented
-explicitly (*note Machine Dependencies::). This doesn't mean `as'
-always uses the same syntax as another assembler for the same
-architecture; for example, we know of several incompatible versions of
-680x0 assembly language syntax.
-
- Unlike older assemblers, `as' is designed to assemble a source
-program in one pass of the source file. This has a subtle impact on the
-`.org' directive (*note `.org': Org.).
-
-
-File: as.info, Node: Object Formats, Next: Command Line, Prev: GNU Assembler, Up: Overview
-
-1.3 Object File Formats
-=======================
-
-The GNU assembler can be configured to produce several alternative
-object file formats. For the most part, this does not affect how you
-write assembly language programs; but directives for debugging symbols
-are typically different in different file formats. *Note Symbol
-Attributes: Symbol Attributes.
-
-
-File: as.info, Node: Command Line, Next: Input Files, Prev: Object Formats, Up: Overview
-
-1.4 Command Line
-================
-
-After the program name `as', the command line may contain options and
-file names. Options may appear in any order, and may be before, after,
-or between file names. The order of file names is significant.
-
- `--' (two hyphens) by itself names the standard input file
-explicitly, as one of the files for `as' to assemble.
-
- Except for `--' any command line argument that begins with a hyphen
-(`-') is an option. Each option changes the behavior of `as'. No
-option changes the way another option works. An option is a `-'
-followed by one or more letters; the case of the letter is important.
-All options are optional.
-
- Some options expect exactly one file name to follow them. The file
-name may either immediately follow the option's letter (compatible with
-older assemblers) or it may be the next command argument (GNU
-standard). These two command lines are equivalent:
-
- as -o my-object-file.o mumble.s
- as -omy-object-file.o mumble.s
-
-
-File: as.info, Node: Input Files, Next: Object, Prev: Command Line, Up: Overview
-
-1.5 Input Files
-===============
-
-We use the phrase "source program", abbreviated "source", to describe
-the program input to one run of `as'. The program may be in one or
-more files; how the source is partitioned into files doesn't change the
-meaning of the source.
-
- The source program is a concatenation of the text in all the files,
-in the order specified.
-
- Each time you run `as' it assembles exactly one source program. The
-source program is made up of one or more files. (The standard input is
-also a file.)
-
- You give `as' a command line that has zero or more input file names.
-The input files are read (from left file name to right). A command
-line argument (in any position) that has no special meaning is taken to
-be an input file name.
-
- If you give `as' no file names it attempts to read one input file
-from the `as' standard input, which is normally your terminal. You may
-have to type <ctl-D> to tell `as' there is no more program to assemble.
-
- Use `--' if you need to explicitly name the standard input file in
-your command line.
-
- If the source is empty, `as' produces a small, empty object file.
-
-Filenames and Line-numbers
---------------------------
-
-There are two ways of locating a line in the input file (or files) and
-either may be used in reporting error messages. One way refers to a
-line number in a physical file; the other refers to a line number in a
-"logical" file. *Note Error and Warning Messages: Errors.
-
- "Physical files" are those files named in the command line given to
-`as'.
-
- "Logical files" are simply names declared explicitly by assembler
-directives; they bear no relation to physical files. Logical file
-names help error messages reflect the original source file, when `as'
-source is itself synthesized from other files. `as' understands the
-`#' directives emitted by the `gcc' preprocessor. See also *note
-`.file': File.
-
-
-File: as.info, Node: Object, Next: Errors, Prev: Input Files, Up: Overview
-
-1.6 Output (Object) File
-========================
-
-Every time you run `as' it produces an output file, which is your
-assembly language program translated into numbers. This file is the
-object file. Its default name is `a.out'. You can give it another
-name by using the `-o' option. Conventionally, object file names end
-with `.o'. The default name is used for historical reasons: older
-assemblers were capable of assembling self-contained programs directly
-into a runnable program. (For some formats, this isn't currently
-possible, but it can be done for the `a.out' format.)
-
- The object file is meant for input to the linker `ld'. It contains
-assembled program code, information to help `ld' integrate the
-assembled program into a runnable file, and (optionally) symbolic
-information for the debugger.
-
-
-File: as.info, Node: Errors, Prev: Object, Up: Overview
-
-1.7 Error and Warning Messages
-==============================
-
-`as' may write warnings and error messages to the standard error file
-(usually your terminal). This should not happen when a compiler runs
-`as' automatically. Warnings report an assumption made so that `as'
-could keep assembling a flawed program; errors report a grave problem
-that stops the assembly.
-
- Warning messages have the format
-
- file_name:NNN:Warning Message Text
-
-(where NNN is a line number). If a logical file name has been given
-(*note `.file': File.) it is used for the filename, otherwise the name
-of the current input file is used. If a logical line number was given
-(*note `.line': Line.) then it is used to calculate the number printed,
-otherwise the actual line in the current source file is printed. The
-message text is intended to be self explanatory (in the grand Unix
-tradition).
-
- Error messages have the format
- file_name:NNN:FATAL:Error Message Text
- The file name and line number are derived as for warning messages.
-The actual message text may be rather less explanatory because many of
-them aren't supposed to happen.
-
-
-File: as.info, Node: Invoking, Next: Syntax, Prev: Overview, Up: Top
-
-2 Command-Line Options
-**********************
-
-This chapter describes command-line options available in _all_ versions
-of the GNU assembler; see *note Machine Dependencies::, for options
-specific to particular machine architectures.
-
- If you are invoking `as' via the GNU C compiler, you can use the
-`-Wa' option to pass arguments through to the assembler. The assembler
-arguments must be separated from each other (and the `-Wa') by commas.
-For example:
-
- gcc -c -g -O -Wa,-alh,-L file.c
-
-This passes two options to the assembler: `-alh' (emit a listing to
-standard output with high-level and assembly source) and `-L' (retain
-local symbols in the symbol table).
-
- Usually you do not need to use this `-Wa' mechanism, since many
-compiler command-line options are automatically passed to the assembler
-by the compiler. (You can call the GNU compiler driver with the `-v'
-option to see precisely what options it passes to each compilation
-pass, including the assembler.)
-
-* Menu:
-
-* a:: -a[cdghlns] enable listings
-* alternate:: --alternate enable alternate macro syntax
-* D:: -D for compatibility
-* f:: -f to work faster
-* I:: -I for .include search path
-
-* K:: -K for difference tables
-
-* L:: -L to retain local symbols
-* listing:: --listing-XXX to configure listing output
-* M:: -M or --mri to assemble in MRI compatibility mode
-* MD:: --MD for dependency tracking
-* o:: -o to name the object file
-* R:: -R to join data and text sections
-* statistics:: --statistics to see statistics about assembly
-* traditional-format:: --traditional-format for compatible output
-* v:: -v to announce version
-* W:: -W, --no-warn, --warn, --fatal-warnings to control warnings
-* Z:: -Z to make object file even after errors
-
-
-File: as.info, Node: a, Next: alternate, Up: Invoking
-
-2.1 Enable Listings: `-a[cdghlns]'
-==================================
-
-These options enable listing output from the assembler. By itself,
-`-a' requests high-level, assembly, and symbols listing. You can use
-other letters to select specific options for the list: `-ah' requests a
-high-level language listing, `-al' requests an output-program assembly
-listing, and `-as' requests a symbol table listing. High-level
-listings require that a compiler debugging option like `-g' be used,
-and that assembly listings (`-al') be requested also.
-
- Use the `-ag' option to print a first section with general assembly
-information, like as version, switches passed, or time stamp.
-
- Use the `-ac' option to omit false conditionals from a listing. Any
-lines which are not assembled because of a false `.if' (or `.ifdef', or
-any other conditional), or a true `.if' followed by an `.else', will be
-omitted from the listing.
-
- Use the `-ad' option to omit debugging directives from the listing.
-
- Once you have specified one of these options, you can further control
-listing output and its appearance using the directives `.list',
-`.nolist', `.psize', `.eject', `.title', and `.sbttl'. The `-an'
-option turns off all forms processing. If you do not request listing
-output with one of the `-a' options, the listing-control directives
-have no effect.
-
- The letters after `-a' may be combined into one option, _e.g._,
-`-aln'.
-
- Note if the assembler source is coming from the standard input (e.g.,
-because it is being created by `gcc' and the `-pipe' command line switch
-is being used) then the listing will not contain any comments or
-preprocessor directives. This is because the listing code buffers
-input source lines from stdin only after they have been preprocessed by
-the assembler. This reduces memory usage and makes the code more
-efficient.
-
-
-File: as.info, Node: alternate, Next: D, Prev: a, Up: Invoking
-
-2.2 `--alternate'
-=================
-
-Begin in alternate macro mode, see *note `.altmacro': Altmacro.
-
-
-File: as.info, Node: D, Next: f, Prev: alternate, Up: Invoking
-
-2.3 `-D'
-========
-
-This option has no effect whatsoever, but it is accepted to make it more
-likely that scripts written for other assemblers also work with `as'.
-
-
-File: as.info, Node: f, Next: I, Prev: D, Up: Invoking
-
-2.4 Work Faster: `-f'
-=====================
-
-`-f' should only be used when assembling programs written by a
-(trusted) compiler. `-f' stops the assembler from doing whitespace and
-comment preprocessing on the input file(s) before assembling them.
-*Note Preprocessing: Preprocessing.
-
- _Warning:_ if you use `-f' when the files actually need to be
- preprocessed (if they contain comments, for example), `as' does
- not work correctly.
-
-
-File: as.info, Node: I, Next: K, Prev: f, Up: Invoking
-
-2.5 `.include' Search Path: `-I' PATH
-=====================================
-
-Use this option to add a PATH to the list of directories `as' searches
-for files specified in `.include' directives (*note `.include':
-Include.). You may use `-I' as many times as necessary to include a
-variety of paths. The current working directory is always searched
-first; after that, `as' searches any `-I' directories in the same order
-as they were specified (left to right) on the command line.
-
-
-File: as.info, Node: K, Next: L, Prev: I, Up: Invoking
-
-2.6 Difference Tables: `-K'
-===========================
-
-`as' sometimes alters the code emitted for directives of the form
-`.word SYM1-SYM2'. *Note `.word': Word. You can use the `-K' option
-if you want a warning issued when this is done.
-
-
-File: as.info, Node: L, Next: listing, Prev: K, Up: Invoking
-
-2.7 Include Local Symbols: `-L'
-===============================
-
-Symbols beginning with system-specific local label prefixes, typically
-`.L' for ELF systems or `L' for traditional a.out systems, are called
-"local symbols". *Note Symbol Names::. Normally you do not see such
-symbols when debugging, because they are intended for the use of
-programs (like compilers) that compose assembler programs, not for your
-notice. Normally both `as' and `ld' discard such symbols, so you do
-not normally debug with them.
-
- This option tells `as' to retain those local symbols in the object
-file. Usually if you do this you also tell the linker `ld' to preserve
-those symbols.
-
-
-File: as.info, Node: listing, Next: M, Prev: L, Up: Invoking
-
-2.8 Configuring listing output: `--listing'
-===========================================
-
-The listing feature of the assembler can be enabled via the command
-line switch `-a' (*note a::). This feature combines the input source
-file(s) with a hex dump of the corresponding locations in the output
-object file, and displays them as a listing file. The format of this
-listing can be controlled by directives inside the assembler source
-(i.e., `.list' (*note List::), `.title' (*note Title::), `.sbttl'
-(*note Sbttl::), `.psize' (*note Psize::), and `.eject' (*note Eject::)
-and also by the following switches:
-
-`--listing-lhs-width=`number''
- Sets the maximum width, in words, of the first line of the hex
- byte dump. This dump appears on the left hand side of the listing
- output.
-
-`--listing-lhs-width2=`number''
- Sets the maximum width, in words, of any further lines of the hex
- byte dump for a given input source line. If this value is not
- specified, it defaults to being the same as the value specified
- for `--listing-lhs-width'. If neither switch is used the default
- is to one.
-
-`--listing-rhs-width=`number''
- Sets the maximum width, in characters, of the source line that is
- displayed alongside the hex dump. The default value for this
- parameter is 100. The source line is displayed on the right hand
- side of the listing output.
-
-`--listing-cont-lines=`number''
- Sets the maximum number of continuation lines of hex dump that
- will be displayed for a given single line of source input. The
- default value is 4.
-
-
-File: as.info, Node: M, Next: MD, Prev: listing, Up: Invoking
-
-2.9 Assemble in MRI Compatibility Mode: `-M'
-============================================
-
-The `-M' or `--mri' option selects MRI compatibility mode. This
-changes the syntax and pseudo-op handling of `as' to make it compatible
-with the `ASM68K' or the `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. 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 `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 file formats. Supporting these would
-require enhancing each object file format individually. These are:
-
- * global symbols in common section
-
- The m68k MRI assembler supports common sections which are merged
- by the linker. Other object file formats do not support this.
- `as' handles common sections by treating them as a single common
- symbol. It permits local symbols to be defined within a common
- section, but it can not support global symbols, since it has no
- way to describe them.
-
- * complex relocations
-
- The MRI assemblers support relocations against a negated section
- address, and relocations which combine the start addresses of two
- or more sections. These are not support by other object file
- formats.
-
- * `END' pseudo-op specifying start address
-
- The MRI `END' pseudo-op permits the specification of a start
- address. This is not supported by other object file formats. The
- start address may instead be specified using the `-e' option to
- the linker, or in a linker script.
-
- * `IDNT', `.ident' and `NAME' pseudo-ops
-
- The MRI `IDNT', `.ident' and `NAME' pseudo-ops assign a module
- name to the output file. This is not supported by other object
- file formats.
-
- * `ORG' pseudo-op
-
- The m68k MRI `ORG' pseudo-op begins an absolute section at a given
- address. This differs from the usual `as' `.org' pseudo-op, which
- changes the location within the current section. Absolute
- sections are not supported by other object file formats. The
- address of a section may be assigned within a linker script.
-
- There are some other features of the MRI assembler which are not
-supported by `as', typically either because they are difficult or
-because they seem of little consequence. Some of these may be
-supported in future releases.
-
- * EBCDIC strings
-
- EBCDIC strings are not supported.
-
- * packed binary coded decimal
-
- Packed binary coded decimal is not supported. This means that the
- `DC.P' and `DCB.P' pseudo-ops are not supported.
-
- * `FEQU' pseudo-op
-
- The m68k `FEQU' pseudo-op is not supported.
-
- * `NOOBJ' pseudo-op
-
- The m68k `NOOBJ' pseudo-op is not supported.
-
- * `OPT' branch control options
-
- The m68k `OPT' branch control options--`B', `BRS', `BRB', `BRL',
- and `BRW'--are ignored. `as' automatically relaxes all branches,
- whether forward or backward, to an appropriate size, so these
- options serve no purpose.
-
- * `OPT' list control options
-
- The following m68k `OPT' list control options are ignored: `C',
- `CEX', `CL', `CRE', `E', `G', `I', `M', `MEX', `MC', `MD', `X'.
-
- * other `OPT' options
-
- The following m68k `OPT' options are ignored: `NEST', `O', `OLD',
- `OP', `P', `PCO', `PCR', `PCS', `R'.
-
- * `OPT' `D' option is default
-
- The m68k `OPT' `D' option is the default, unlike the MRI assembler.
- `OPT NOD' may be used to turn it off.
-
- * `XREF' pseudo-op.
-
- The m68k `XREF' pseudo-op is ignored.
-
- * `.debug' pseudo-op
-
- The i960 `.debug' pseudo-op is not supported.
-
- * `.extended' pseudo-op
-
- The i960 `.extended' pseudo-op is not supported.
-
- * `.list' pseudo-op.
-
- The various options of the i960 `.list' pseudo-op are not
- supported.
-
- * `.optimize' pseudo-op
-
- The i960 `.optimize' pseudo-op is not supported.
-
- * `.output' pseudo-op
-
- The i960 `.output' pseudo-op is not supported.
-
- * `.setreal' pseudo-op
-
- The i960 `.setreal' pseudo-op is not supported.
-
-
-
-File: as.info, Node: MD, Next: o, Prev: M, Up: Invoking
-
-2.10 Dependency Tracking: `--MD'
-================================
-
-`as' can generate a dependency file for the file it creates. This file
-consists of a single rule suitable for `make' describing the
-dependencies of the main source file.
-
- The rule is written to the file named in its argument.
-
- This feature is used in the automatic updating of makefiles.
-
-
-File: as.info, Node: o, Next: R, Prev: MD, Up: Invoking
-
-2.11 Name the Object File: `-o'
-===============================
-
-There is always one object file output when you run `as'. By default
-it has the name `a.out' (or `b.out', for Intel 960 targets only). You
-use this option (which takes exactly one filename) to give the object
-file a different name.
-
- Whatever the object file is called, `as' overwrites any existing
-file of the same name.
-
-
-File: as.info, Node: R, Next: statistics, Prev: o, Up: Invoking
-
-2.12 Join Data and Text Sections: `-R'
-======================================
-
-`-R' tells `as' to write the object file as if all data-section data
-lives in the text section. This is only done at the very last moment:
-your binary data are the same, but data section parts are relocated
-differently. The data section part of your object file is zero bytes
-long because all its bytes are appended to the text section. (*Note
-Sections and Relocation: Sections.)
-
- When you specify `-R' it would be possible to generate shorter
-address displacements (because we do not have to cross between text and
-data section). We refrain from doing this simply for compatibility with
-older versions of `as'. In future, `-R' may work this way.
-
- When `as' is configured for COFF or ELF output, this option is only
-useful if you use sections named `.text' and `.data'.
-
- `-R' is not supported for any of the HPPA targets. Using `-R'
-generates a warning from `as'.
-
-
-File: as.info, Node: statistics, Next: traditional-format, Prev: R, Up: Invoking
-
-2.13 Display Assembly Statistics: `--statistics'
-================================================
-
-Use `--statistics' to display two statistics about the resources used by
-`as': the maximum amount of space allocated during the assembly (in
-bytes), and the total execution time taken for the assembly (in CPU
-seconds).
-
-
-File: as.info, Node: traditional-format, Next: v, Prev: statistics, Up: Invoking
-
-2.14 Compatible Output: `--traditional-format'
-==============================================
-
-For some targets, the output of `as' is different in some ways from the
-output of some existing assembler. This switch requests `as' to use
-the traditional format instead.
-
- For example, it disables the exception frame optimizations which
-`as' normally does by default on `gcc' output.
-
-
-File: as.info, Node: v, Next: W, Prev: traditional-format, Up: Invoking
-
-2.15 Announce Version: `-v'
-===========================
-
-You can find out what version of as is running by including the option
-`-v' (which you can also spell as `-version') on the command line.
-
-
-File: as.info, Node: W, Next: Z, Prev: v, Up: Invoking
-
-2.16 Control Warnings: `-W', `--warn', `--no-warn', `--fatal-warnings'
-======================================================================
-
-`as' should never give a warning or error message when assembling
-compiler output. But programs written by people often cause `as' to
-give a warning that a particular assumption was made. All such
-warnings are directed to the standard error file.
-
- If you use the `-W' and `--no-warn' options, no warnings are issued.
-This only affects the warning messages: it does not change any
-particular of how `as' assembles your file. Errors, which stop the
-assembly, are still reported.
-
- If you use the `--fatal-warnings' option, `as' considers files that
-generate warnings to be in error.
-
- You can switch these options off again by specifying `--warn', which
-causes warnings to be output as usual.
-
-
-File: as.info, Node: Z, Prev: W, Up: Invoking
-
-2.17 Generate Object File in Spite of Errors: `-Z'
-==================================================
-
-After an error message, `as' normally produces no output. If for some
-reason you are interested in object file output even after `as' gives
-an error message on your program, use the `-Z' option. If there are
-any errors, `as' continues anyways, and writes an object file after a
-final warning message of the form `N errors, M warnings, generating bad
-object file.'
-
-
-File: as.info, Node: Syntax, Next: Sections, Prev: Invoking, Up: Top
-
-3 Syntax
-********
-
-This chapter describes the machine-independent syntax allowed in a
-source file. `as' syntax is similar to what many other assemblers use;
-it is inspired by the BSD 4.2 assembler, except that `as' does not
-assemble Vax bit-fields.
-
-* Menu:
-
-* Preprocessing:: Preprocessing
-* Whitespace:: Whitespace
-* Comments:: Comments
-* Symbol Intro:: Symbols
-* Statements:: Statements
-* Constants:: Constants
-
-
-File: as.info, Node: Preprocessing, Next: Whitespace, Up: Syntax
-
-3.1 Preprocessing
-=================
-
-The `as' internal preprocessor:
- * adjusts and removes extra whitespace. It leaves one space or tab
- before the keywords on a line, and turns any other whitespace on
- the line into a single space.
-
- * removes all comments, replacing them with a single space, or an
- appropriate number of newlines.
-
- * converts character constants into the appropriate numeric values.
-
- It does not do macro processing, include file handling, or anything
-else you may get from your C compiler's preprocessor. You can do
-include file processing with the `.include' directive (*note
-`.include': Include.). You can use the GNU C compiler driver to get
-other "CPP" style preprocessing by giving the input file a `.S' suffix.
-*Note Options Controlling the Kind of Output: (gcc.info)Overall Options.
-
- Excess whitespace, comments, and character constants cannot be used
-in the portions of the input text that are not preprocessed.
-
- If the first line of an input file is `#NO_APP' or if you use the
-`-f' option, whitespace and comments are not removed from the input
-file. Within an input file, you can ask for whitespace and comment
-removal in specific portions of the by putting a line that says `#APP'
-before the text that may contain whitespace or comments, and putting a
-line that says `#NO_APP' after this text. This feature is mainly
-intend to support `asm' statements in compilers whose output is
-otherwise free of comments and whitespace.
-
-
-File: as.info, Node: Whitespace, Next: Comments, Prev: Preprocessing, Up: Syntax
-
-3.2 Whitespace
-==============
-
-"Whitespace" is one or more blanks or tabs, in any order. Whitespace
-is used to separate symbols, and to make programs neater for people to
-read. Unless within character constants (*note Character Constants:
-Characters.), any whitespace means the same as exactly one space.
-
-
-File: as.info, Node: Comments, Next: Symbol Intro, Prev: Whitespace, Up: Syntax
-
-3.3 Comments
-============
-
-There are two ways of rendering comments to `as'. In both cases the
-comment is equivalent to one space.
-
- Anything from `/*' through the next `*/' is a comment. This means
-you may not nest these comments.
-
- /*
- The only way to include a newline ('\n') in a comment
- is to use this sort of comment.
- */
-
- /* This sort of comment does not nest. */
-
- Anything from the "line comment" character to the next newline is
-considered a comment and is ignored. The line comment character is `;'
-on the ARC; `@' on the ARM; `;' for the H8/300 family; `;' for the HPPA;
-`#' on the i386 and x86-64; `#' on the i960; `;' for the PDP-11; `;'
-for picoJava; `#' for Motorola PowerPC; `#' for IBM S/390; `#' for the
-Sunplus SCORE; `!' for the Renesas / SuperH SH; `!' on the SPARC; `#'
-on the ip2k; `#' on the m32c; `#' on the m32r; `|' on the 680x0; `#' on
-the 68HC11 and 68HC12; `#' on the RX; `;' on the TMS320C6X; `#' on the
-Vax; `;' for the Z80; `!' for the Z8000; `#' on the V850; `#' for
-Xtensa systems; see *note Machine Dependencies::.
-
- On some machines there are two different line comment characters.
-One character only begins a comment if it is the first non-whitespace
-character on a line, while the other always begins a comment.
-
- The V850 assembler also supports a double dash as starting a comment
-that extends to the end of the line.
-
- `--';
-
- To be compatible with past assemblers, lines that begin with `#'
-have a special interpretation. Following the `#' should be an absolute
-expression (*note Expressions::): the logical line number of the _next_
-line. Then a string (*note Strings: Strings.) is allowed: if present
-it is a new logical file name. The rest of the line, if any, should be
-whitespace.
-
- If the first non-whitespace characters on the line are not numeric,
-the line is ignored. (Just like a comment.)
-
- # This is an ordinary comment.
- # 42-6 "new_file_name" # New logical file name
- # This is logical line # 36.
- This feature is deprecated, and may disappear from future versions
-of `as'.
-
-
-File: as.info, Node: Symbol Intro, Next: Statements, Prev: Comments, Up: Syntax
-
-3.4 Symbols
-===========
-
-A "symbol" is one or more characters chosen from the set of all letters
-(both upper and lower case), digits and the three characters `_.$'. On
-most machines, you can also use `$' in symbol names; exceptions are
-noted in *note Machine Dependencies::. No symbol may begin with a
-digit. Case is significant. There is no length limit: all characters
-are significant. Symbols are delimited by characters not in that set,
-or by the beginning of a file (since the source program must end with a
-newline, the end of a file is not a possible symbol delimiter). *Note
-Symbols::.
-
-
-File: as.info, Node: Statements, Next: Constants, Prev: Symbol Intro, Up: Syntax
-
-3.5 Statements
-==============
-
-A "statement" ends at a newline character (`\n') or line separator
-character. (The line separator is usually `;', unless this conflicts
-with the comment character; see *note Machine Dependencies::.) The
-newline or separator character is considered part of the preceding
-statement. Newlines and separators within character constants are an
-exception: they do not end statements.
-
-It is an error to end any statement with end-of-file: the last
-character of any input file should be a newline.
-
- An empty statement is allowed, and may include whitespace. It is
-ignored.
-
- A statement begins with zero or more labels, optionally followed by a
-key symbol which determines what kind of statement it is. The key
-symbol determines the syntax of the rest of the statement. If the
-symbol begins with a dot `.' then the statement is an assembler
-directive: typically valid for any computer. If the symbol begins with
-a letter the statement is an assembly language "instruction": it
-assembles into a machine language instruction. Different versions of
-`as' for different computers recognize different instructions. In
-fact, the same symbol may represent a different instruction in a
-different computer's assembly language.
-
- A label is a symbol immediately followed by a colon (`:').
-Whitespace before a label or after a colon is permitted, but you may not
-have whitespace between a label's symbol and its colon. *Note Labels::.
-
- For HPPA targets, labels need not be immediately followed by a
-colon, but the definition of a label must begin in column zero. This
-also implies that only one label may be defined on each line.
-
- label: .directive followed by something
- another_label: # This is an empty statement.
- instruction operand_1, operand_2, ...
-
-
-File: as.info, Node: Constants, Prev: Statements, Up: Syntax
-
-3.6 Constants
-=============
-
-A constant is a number, written so that its value is known by
-inspection, without knowing any context. Like this:
- .byte 74, 0112, 092, 0x4A, 0X4a, 'J, '\J # All the same value.
- .ascii "Ring the bell\7" # A string constant.
- .octa 0x123456789abcdef0123456789ABCDEF0 # A bignum.
- .float 0f-314159265358979323846264338327\
- 95028841971.693993751E-40 # - pi, a flonum.
-
-* Menu:
-
-* Characters:: Character Constants
-* Numbers:: Number Constants
-
-
-File: as.info, Node: Characters, Next: Numbers, Up: Constants
-
-3.6.1 Character Constants
--------------------------
-
-There are two kinds of character constants. A "character" stands for
-one character in one byte and its value may be used in numeric
-expressions. String constants (properly called string _literals_) are
-potentially many bytes and their values may not be used in arithmetic
-expressions.
-
-* Menu:
-
-* Strings:: Strings
-* Chars:: Characters
-
-
-File: as.info, Node: Strings, Next: Chars, Up: Characters
-
-3.6.1.1 Strings
-...............
-
-A "string" is written between double-quotes. It may contain
-double-quotes or null characters. The way to get special characters
-into a string is to "escape" these characters: precede them with a
-backslash `\' character. For example `\\' represents one backslash:
-the first `\' is an escape which tells `as' to interpret the second
-character literally as a backslash (which prevents `as' from
-recognizing the second `\' as an escape character). The complete list
-of escapes follows.
-
-`\b'
- Mnemonic for backspace; for ASCII this is octal code 010.
-
-`\f'
- Mnemonic for FormFeed; for ASCII this is octal code 014.
-
-`\n'
- Mnemonic for newline; for ASCII this is octal code 012.
-
-`\r'
- Mnemonic for carriage-Return; for ASCII this is octal code 015.
-
-`\t'
- Mnemonic for horizontal Tab; for ASCII this is octal code 011.
-
-`\ DIGIT DIGIT DIGIT'
- An octal character code. The numeric code is 3 octal digits. For
- compatibility with other Unix systems, 8 and 9 are accepted as
- digits: for example, `\008' has the value 010, and `\009' the
- value 011.
-
-`\`x' HEX-DIGITS...'
- A hex character code. All trailing hex digits are combined.
- Either upper or lower case `x' works.
-
-`\\'
- Represents one `\' character.
-
-`\"'
- Represents one `"' character. Needed in strings to represent this
- character, because an unescaped `"' would end the string.
-
-`\ ANYTHING-ELSE'
- Any other character when escaped by `\' gives a warning, but
- assembles as if the `\' was not present. The idea is that if you
- used an escape sequence you clearly didn't want the literal
- interpretation of the following character. However `as' has no
- other interpretation, so `as' knows it is giving you the wrong
- code and warns you of the fact.
-
- Which characters are escapable, and what those escapes represent,
-varies widely among assemblers. The current set is what we think the
-BSD 4.2 assembler recognizes, and is a subset of what most C compilers
-recognize. If you are in doubt, do not use an escape sequence.
-
-
-File: as.info, Node: Chars, Prev: Strings, Up: Characters
-
-3.6.1.2 Characters
-..................
-
-A single character may be written as a single quote immediately
-followed by that character. The same escapes apply to characters as to
-strings. So if you want to write the character backslash, you must
-write `'\\' where the first `\' escapes the second `\'. As you can
-see, the quote is an acute accent, not a grave accent. A newline
-immediately following an acute accent is taken as a literal character
-and does not count as the end of a statement. The value of a character
-constant in a numeric expression is the machine's byte-wide code for
-that character. `as' assumes your character code is ASCII: `'A' means
-65, `'B' means 66, and so on.
-
-
-File: as.info, Node: Numbers, Prev: Characters, Up: Constants
-
-3.6.2 Number Constants
-----------------------
-
-`as' distinguishes three kinds of numbers according to how they are
-stored in the target machine. _Integers_ are numbers that would fit
-into an `int' in the C language. _Bignums_ are integers, but they are
-stored in more than 32 bits. _Flonums_ are floating point numbers,
-described below.
-
-* Menu:
-
-* Integers:: Integers
-* Bignums:: Bignums
-* Flonums:: Flonums
-
-
-File: as.info, Node: Integers, Next: Bignums, Up: Numbers
-
-3.6.2.1 Integers
-................
-
-A binary integer is `0b' or `0B' followed by zero or more of the binary
-digits `01'.
-
- An octal integer is `0' followed by zero or more of the octal digits
-(`01234567').
-
- A decimal integer starts with a non-zero digit followed by zero or
-more digits (`0123456789').
-
- A hexadecimal integer is `0x' or `0X' followed by one or more
-hexadecimal digits chosen from `0123456789abcdefABCDEF'.
-
- Integers have the usual values. To denote a negative integer, use
-the prefix operator `-' discussed under expressions (*note Prefix
-Operators: Prefix Ops.).
-
-
-File: as.info, Node: Bignums, Next: Flonums, Prev: Integers, Up: Numbers
-
-3.6.2.2 Bignums
-...............
-
-A "bignum" has the same syntax and semantics as an integer except that
-the number (or its negative) takes more than 32 bits to represent in
-binary. The distinction is made because in some places integers are
-permitted while bignums are not.
-
-
-File: as.info, Node: Flonums, Prev: Bignums, Up: Numbers
-
-3.6.2.3 Flonums
-...............
-
-A "flonum" represents a floating point number. The translation is
-indirect: a decimal floating point number from the text is converted by
-`as' to a generic binary floating point number of more than sufficient
-precision. This generic floating point number is converted to a
-particular computer's floating point format (or formats) by a portion
-of `as' specialized to that computer.
-
- A flonum is written by writing (in order)
- * The digit `0'. (`0' is optional on the HPPA.)
-
- * A letter, to tell `as' the rest of the number is a flonum. `e' is
- recommended. Case is not important.
-
- On the H8/300, Renesas / SuperH SH, and AMD 29K architectures, the
- letter must be one of the letters `DFPRSX' (in upper or lower
- case).
-
- On the ARC, the letter must be one of the letters `DFRS' (in upper
- or lower case).
-
- On the Intel 960 architecture, the letter must be one of the
- letters `DFT' (in upper or lower case).
-
- On the HPPA architecture, the letter must be `E' (upper case only).
-
- * An optional sign: either `+' or `-'.
-
- * An optional "integer part": zero or more decimal digits.
-
- * An optional "fractional part": `.' followed by zero or more
- decimal digits.
-
- * An optional exponent, consisting of:
-
- * An `E' or `e'.
-
- * Optional sign: either `+' or `-'.
-
- * One or more decimal digits.
-
-
- At least one of the integer part or the fractional part must be
-present. The floating point number has the usual base-10 value.
-
- `as' does all processing using integers. Flonums are computed
-independently of any floating point hardware in the computer running
-`as'.
-
-
-File: as.info, Node: Sections, Next: Symbols, Prev: Syntax, Up: Top
-
-4 Sections and Relocation
-*************************
-
-* Menu:
-
-* Secs Background:: Background
-* Ld Sections:: Linker Sections
-* As Sections:: Assembler Internal Sections
-* Sub-Sections:: Sub-Sections
-* bss:: bss Section
-
-
-File: as.info, Node: Secs Background, Next: Ld Sections, Up: Sections
-
-4.1 Background
-==============
-
-Roughly, a section is a range of addresses, with no gaps; all data "in"
-those addresses is treated the same for some particular purpose. For
-example there may be a "read only" section.
-
- The linker `ld' reads many object files (partial programs) and
-combines their contents to form a runnable program. When `as' emits an
-object file, the partial program is assumed to start at address 0.
-`ld' assigns the final addresses for the partial program, so that
-different partial programs do not overlap. This is actually an
-oversimplification, but it suffices to explain how `as' uses sections.
-
- `ld' moves blocks of bytes of your program to their run-time
-addresses. These blocks slide to their run-time addresses as rigid
-units; their length does not change and neither does the order of bytes
-within them. Such a rigid unit is called a _section_. Assigning
-run-time addresses to sections is called "relocation". It includes the
-task of adjusting mentions of object-file addresses so they refer to
-the proper run-time addresses. For the H8/300, and for the Renesas /
-SuperH SH, `as' pads sections if needed to ensure they end on a word
-(sixteen bit) boundary.
-
- An object file written by `as' has at least three sections, any of
-which may be empty. These are named "text", "data" and "bss" sections.
-
- When it generates COFF or ELF output, `as' can also generate
-whatever other named sections you specify using the `.section'
-directive (*note `.section': Section.). If you do not use any
-directives that place output in the `.text' or `.data' sections, these
-sections still exist, but are empty.
-
- When `as' generates SOM or ELF output for the HPPA, `as' can also
-generate whatever other named sections you specify using the `.space'
-and `.subspace' directives. See `HP9000 Series 800 Assembly Language
-Reference Manual' (HP 92432-90001) for details on the `.space' and
-`.subspace' assembler directives.
-
- Additionally, `as' uses different names for the standard text, data,
-and bss sections when generating SOM output. Program text is placed
-into the `$CODE$' section, data into `$DATA$', and BSS into `$BSS$'.
-
- Within the object file, the text section starts at address `0', the
-data section follows, and the bss section follows the data section.
-
- When generating either SOM or ELF output files on the HPPA, the text
-section starts at address `0', the data section at address `0x4000000',
-and the bss section follows the data section.
-
- To let `ld' know which data changes when the sections are relocated,
-and how to change that data, `as' also writes to the object file
-details of the relocation needed. To perform relocation `ld' must
-know, each time an address in the object file is mentioned:
- * Where in the object file is the beginning of this reference to an
- address?
-
- * How long (in bytes) is this reference?
-
- * Which section does the address refer to? What is the numeric
- value of
- (ADDRESS) - (START-ADDRESS OF SECTION)?
-
- * Is the reference to an address "Program-Counter relative"?
-
- In fact, every address `as' ever uses is expressed as
- (SECTION) + (OFFSET INTO SECTION)
- Further, most expressions `as' computes have this section-relative
-nature. (For some object formats, such as SOM for the HPPA, some
-expressions are symbol-relative instead.)
-
- In this manual we use the notation {SECNAME N} to mean "offset N
-into section SECNAME."
-
- Apart from text, data and bss sections you need to know about the
-"absolute" section. When `ld' mixes partial programs, addresses in the
-absolute section remain unchanged. For example, address `{absolute 0}'
-is "relocated" to run-time address 0 by `ld'. Although the linker
-never arranges two partial programs' data sections with overlapping
-addresses after linking, _by definition_ their absolute sections must
-overlap. Address `{absolute 239}' in one part of a program is always
-the same address when the program is running as address `{absolute
-239}' in any other part of the program.
-
- The idea of sections is extended to the "undefined" section. Any
-address whose section is unknown at assembly time is by definition
-rendered {undefined U}--where U is filled in later. Since numbers are
-always defined, the only way to generate an undefined address is to
-mention an undefined symbol. A reference to a named common block would
-be such a symbol: its value is unknown at assembly time so it has
-section _undefined_.
-
- By analogy the word _section_ is used to describe groups of sections
-in the linked program. `ld' puts all partial programs' text sections
-in contiguous addresses in the linked program. It is customary to
-refer to the _text section_ of a program, meaning all the addresses of
-all partial programs' text sections. Likewise for data and bss
-sections.
-
- Some sections are manipulated by `ld'; others are invented for use
-of `as' and have no meaning except during assembly.
-
-
-File: as.info, Node: Ld Sections, Next: As Sections, Prev: Secs Background, Up: Sections
-
-4.2 Linker Sections
-===================
-
-`ld' deals with just four kinds of sections, summarized below.
-
-*named sections*
-*text section*
-*data section*
- These sections hold your program. `as' and `ld' treat them as
- separate but equal sections. Anything you can say of one section
- is true of another. When the program is running, however, it is
- customary for the text section to be unalterable. The text
- section is often shared among processes: it contains instructions,
- constants and the like. The data section of a running program is
- usually alterable: for example, C variables would be stored in the
- data section.
-
-*bss section*
- This section contains zeroed bytes when your program begins
- running. It is used to hold uninitialized variables or common
- storage. The length of each partial program's bss section is
- important, but because it starts out containing zeroed bytes there
- is no need to store explicit zero bytes in the object file. The
- bss section was invented to eliminate those explicit zeros from
- object files.
-
-*absolute section*
- Address 0 of this section is always "relocated" to runtime address
- 0. This is useful if you want to refer to an address that `ld'
- must not change when relocating. In this sense we speak of
- absolute addresses being "unrelocatable": they do not change
- during relocation.
-
-*undefined section*
- This "section" is a catch-all for address references to objects
- not in the preceding sections.
-
- An idealized example of three relocatable sections follows. The
-example uses the traditional section names `.text' and `.data'. Memory
-addresses are on the horizontal axis.
-
- +-----+----+--+
- partial program # 1: |ttttt|dddd|00|
- +-----+----+--+
-
- text data bss
- seg. seg. seg.
-
- +---+---+---+
- partial program # 2: |TTT|DDD|000|
- +---+---+---+
-
- +--+---+-----+--+----+---+-----+~~
- linked program: | |TTT|ttttt| |dddd|DDD|00000|
- +--+---+-----+--+----+---+-----+~~
-
- addresses: 0 ...
-
-
-File: as.info, Node: As Sections, Next: Sub-Sections, Prev: Ld Sections, Up: Sections
-
-4.3 Assembler Internal Sections
-===============================
-
-These sections are meant only for the internal use of `as'. They have
-no meaning at run-time. You do not really need to know about these
-sections for most purposes; but they can be mentioned in `as' warning
-messages, so it might be helpful to have an idea of their meanings to
-`as'. These sections are used to permit the value of every expression
-in your assembly language program to be a section-relative address.
-
-ASSEMBLER-INTERNAL-LOGIC-ERROR!
- An internal assembler logic error has been found. This means
- there is a bug in the assembler.
-
-expr section
- The assembler stores complex expression internally as combinations
- of symbols. When it needs to represent an expression as a symbol,
- it puts it in the expr section.
-
-
-File: as.info, Node: Sub-Sections, Next: bss, Prev: As Sections, Up: Sections
-
-4.4 Sub-Sections
-================
-
-Assembled bytes conventionally fall into two sections: text and data.
-You may have separate groups of data in named sections that you want to
-end up near to each other in the object file, even though they are not
-contiguous in the assembler source. `as' allows you to use
-"subsections" for this purpose. Within each section, there can be
-numbered subsections with values from 0 to 8192. Objects assembled
-into the same subsection go into the object file together with other
-objects in the same subsection. For example, a compiler might want to
-store constants in the text section, but might not want to have them
-interspersed with the program being assembled. In this case, the
-compiler could issue a `.text 0' before each section of code being
-output, and a `.text 1' before each group of constants being output.
-
-Subsections are optional. If you do not use subsections, everything
-goes in subsection number zero.
-
- Each subsection is zero-padded up to a multiple of four bytes.
-(Subsections may be padded a different amount on different flavors of
-`as'.)
-
- Subsections appear in your object file in numeric order, lowest
-numbered to highest. (All this to be compatible with other people's
-assemblers.) The object file contains no representation of
-subsections; `ld' and other programs that manipulate object files see
-no trace of them. They just see all your text subsections as a text
-section, and all your data subsections as a data section.
-
- To specify which subsection you want subsequent statements assembled
-into, use a numeric argument to specify it, in a `.text EXPRESSION' or
-a `.data EXPRESSION' statement. When generating COFF output, you can
-also use an extra subsection argument with arbitrary named sections:
-`.section NAME, EXPRESSION'. When generating ELF output, you can also
-use the `.subsection' directive (*note SubSection::) to specify a
-subsection: `.subsection EXPRESSION'. EXPRESSION should be an absolute
-expression (*note Expressions::). If you just say `.text' then `.text
-0' is assumed. Likewise `.data' means `.data 0'. Assembly begins in
-`text 0'. For instance:
- .text 0 # The default subsection is text 0 anyway.
- .ascii "This lives in the first text subsection. *"
- .text 1
- .ascii "But this lives in the second text subsection."
- .data 0
- .ascii "This lives in the data section,"
- .ascii "in the first data subsection."
- .text 0
- .ascii "This lives in the first text section,"
- .ascii "immediately following the asterisk (*)."
-
- Each section has a "location counter" incremented by one for every
-byte assembled into that section. Because subsections are merely a
-convenience restricted to `as' there is no concept of a subsection
-location counter. There is no way to directly manipulate a location
-counter--but the `.align' directive changes it, and any label
-definition captures its current value. The location counter of the
-section where statements are being assembled is said to be the "active"
-location counter.
-
-
-File: as.info, Node: bss, Prev: Sub-Sections, Up: Sections
-
-4.5 bss Section
-===============
-
-The bss section is used for local common variable storage. You may
-allocate address space in the bss section, but you may not dictate data
-to load into it before your program executes. When your program starts
-running, all the contents of the bss section are zeroed bytes.
-
- The `.lcomm' pseudo-op defines a symbol in the bss section; see
-*note `.lcomm': Lcomm.
-
- The `.comm' pseudo-op may be used to declare a common symbol, which
-is another form of uninitialized symbol; see *note `.comm': Comm.
-
- When assembling for a target which supports multiple sections, such
-as ELF or COFF, you may switch into the `.bss' section and define
-symbols as usual; see *note `.section': Section. You may only assemble
-zero values into the section. Typically the section will only contain
-symbol definitions and `.skip' directives (*note `.skip': Skip.).
-
-
-File: as.info, Node: Symbols, Next: Expressions, Prev: Sections, Up: Top
-
-5 Symbols
-*********
-
-Symbols are a central concept: the programmer uses symbols to name
-things, the linker uses symbols to link, and the debugger uses symbols
-to debug.
-
- _Warning:_ `as' does not place symbols in the object file in the
- same order they were declared. This may break some debuggers.
-
-* Menu:
-
-* Labels:: Labels
-* Setting Symbols:: Giving Symbols Other Values
-* Symbol Names:: Symbol Names
-* Dot:: The Special Dot Symbol
-* Symbol Attributes:: Symbol Attributes
-
-
-File: as.info, Node: Labels, Next: Setting Symbols, Up: Symbols
-
-5.1 Labels
-==========
-
-A "label" is written as a symbol immediately followed by a colon `:'.
-The symbol then represents the current value of the active location
-counter, and is, for example, a suitable instruction operand. You are
-warned if you use the same symbol to represent two different locations:
-the first definition overrides any other definitions.
-
- On the HPPA, the usual form for a label need not be immediately
-followed by a colon, but instead must start in column zero. Only one
-label may be defined on a single line. To work around this, the HPPA
-version of `as' also provides a special directive `.label' for defining
-labels more flexibly.
-
-
-File: as.info, Node: Setting Symbols, Next: Symbol Names, Prev: Labels, Up: Symbols
-
-5.2 Giving Symbols Other Values
-===============================
-
-A symbol can be given an arbitrary value by writing a symbol, followed
-by an equals sign `=', followed by an expression (*note Expressions::).
-This is equivalent to using the `.set' directive. *Note `.set': Set.
-In the same way, using a double equals sign `='`=' here represents an
-equivalent of the `.eqv' directive. *Note `.eqv': Eqv.
-
- Blackfin does not support symbol assignment with `='.
-
-
-File: as.info, Node: Symbol Names, Next: Dot, Prev: Setting Symbols, Up: Symbols
-
-5.3 Symbol Names
-================
-
-Symbol names begin with a letter or with one of `._'. On most
-machines, you can also use `$' in symbol names; exceptions are noted in
-*note Machine Dependencies::. That character may be followed by any
-string of digits, letters, dollar signs (unless otherwise noted for a
-particular target machine), and underscores.
-
-Case of letters is significant: `foo' is a different symbol name than
-`Foo'.
-
- Each symbol has exactly one name. Each name in an assembly language
-program refers to exactly one symbol. You may use that symbol name any
-number of times in a program.
-
-Local Symbol Names
-------------------
-
-A local symbol is any symbol beginning with certain local label
-prefixes. By default, the local label prefix is `.L' for ELF systems or
-`L' for traditional a.out systems, but each target may have its own set
-of local label prefixes. On the HPPA local symbols begin with `L$'.
-
- Local symbols are defined and used within the assembler, but they are
-normally not saved in object files. Thus, they are not visible when
-debugging. You may use the `-L' option (*note Include Local Symbols:
-`-L': L.) to retain the local symbols in the object files.
-
-Local Labels
-------------
-
-Local labels help compilers and programmers use names temporarily.
-They create symbols which are guaranteed to be unique over the entire
-scope of the input source code and which can be referred to by a simple
-notation. To define a local label, write a label of the form `N:'
-(where N represents any positive integer). To refer to the most recent
-previous definition of that label write `Nb', using the same number as
-when you defined the label. To refer to the next definition of a local
-label, write `Nf'--the `b' stands for "backwards" and the `f' stands
-for "forwards".
-
- There is no restriction on how you can use these labels, and you can
-reuse them too. So that it is possible to repeatedly define the same
-local label (using the same number `N'), although you can only refer to
-the most recently defined local label of that number (for a backwards
-reference) or the next definition of a specific local label for a
-forward reference. It is also worth noting that the first 10 local
-labels (`0:'...`9:') are implemented in a slightly more efficient
-manner than the others.
-
- Here is an example:
-
- 1: branch 1f
- 2: branch 1b
- 1: branch 2f
- 2: branch 1b
-
- Which is the equivalent of:
-
- label_1: branch label_3
- label_2: branch label_1
- label_3: branch label_4
- label_4: branch label_3
-
- Local label names are only a notational device. They are immediately
-transformed into more conventional symbol names before the assembler
-uses them. The symbol names are stored in the symbol table, appear in
-error messages, and are optionally emitted to the object file. The
-names are constructed using these parts:
-
-`_local label prefix_'
- All local symbols begin with the system-specific local label
- prefix. Normally both `as' and `ld' forget symbols that start
- with the local label prefix. These labels are used for symbols
- you are never intended to see. If you use the `-L' option then
- `as' retains these symbols in the object file. If you also
- instruct `ld' to retain these symbols, you may use them in
- debugging.
-
-`NUMBER'
- This is the number that was used in the local label definition.
- So if the label is written `55:' then the number is `55'.
-
-`C-B'
- This unusual character is included so you do not accidentally
- invent a symbol of the same name. The character has ASCII value
- of `\002' (control-B).
-
-`_ordinal number_'
- This is a serial number to keep the labels distinct. The first
- definition of `0:' gets the number `1'. The 15th definition of
- `0:' gets the number `15', and so on. Likewise the first
- definition of `1:' gets the number `1' and its 15th definition
- gets `15' as well.
-
- So for example, the first `1:' may be named `.L1C-B1', and the 44th
-`3:' may be named `.L3C-B44'.
-
-Dollar Local Labels
--------------------
-
-`as' also supports an even more local form of local labels called
-dollar labels. These labels go out of scope (i.e., they become
-undefined) as soon as a non-local label is defined. Thus they remain
-valid for only a small region of the input source code. Normal local
-labels, by contrast, remain in scope for the entire file, or until they
-are redefined by another occurrence of the same local label.
-
- Dollar labels are defined in exactly the same way as ordinary local
-labels, except that they have a dollar sign suffix to their numeric
-value, e.g., `55$:'.
-
- They can also be distinguished from ordinary local labels by their
-transformed names which use ASCII character `\001' (control-A) as the
-magic character to distinguish them from ordinary labels. For example,
-the fifth definition of `6$' may be named `.L6C-A5'.
-
-
-File: as.info, Node: Dot, Next: Symbol Attributes, Prev: Symbol Names, Up: Symbols
-
-5.4 The Special Dot Symbol
-==========================
-
-The special symbol `.' refers to the current address that `as' is
-assembling into. Thus, the expression `melvin: .long .' defines
-`melvin' to contain its own address. Assigning a value to `.' is
-treated the same as a `.org' directive. Thus, the expression `.=.+4'
-is the same as saying `.space 4'.
-
-
-File: as.info, Node: Symbol Attributes, Prev: Dot, Up: Symbols
-
-5.5 Symbol Attributes
-=====================
-
-Every symbol has, as well as its name, the attributes "Value" and
-"Type". Depending on output format, symbols can also have auxiliary
-attributes.
-
- If you use a symbol without defining it, `as' assumes zero for all
-these attributes, and probably won't warn you. This makes the symbol
-an externally defined symbol, which is generally what you would want.
-
-* Menu:
-
-* Symbol Value:: Value
-* Symbol Type:: Type
-
-
-* a.out Symbols:: Symbol Attributes: `a.out'
-
-* COFF Symbols:: Symbol Attributes for COFF
-
-* SOM Symbols:: Symbol Attributes for SOM
-
-
-File: as.info, Node: Symbol Value, Next: Symbol Type, Up: Symbol Attributes
-
-5.5.1 Value
------------
-
-The value of a symbol is (usually) 32 bits. For a symbol which labels a
-location in the text, data, bss or absolute sections the value is the
-number of addresses from the start of that section to the label.
-Naturally for text, data and bss sections the value of a symbol changes
-as `ld' changes section base addresses during linking. Absolute
-symbols' values do not change during linking: that is why they are
-called absolute.
-
- The value of an undefined symbol is treated in a special way. If it
-is 0 then the symbol is not defined in this assembler source file, and
-`ld' tries to determine its value from other files linked into the same
-program. You make this kind of symbol simply by mentioning a symbol
-name without defining it. A non-zero value represents a `.comm' common
-declaration. The value is how much common storage to reserve, in bytes
-(addresses). The symbol refers to the first address of the allocated
-storage.
-
-
-File: as.info, Node: Symbol Type, Next: a.out Symbols, Prev: Symbol Value, Up: Symbol Attributes
-
-5.5.2 Type
-----------
-
-The type attribute of a symbol contains relocation (section)
-information, any flag settings indicating that a symbol is external, and
-(optionally), other information for linkers and debuggers. The exact
-format depends on the object-code output format in use.
-
-
-File: as.info, Node: a.out Symbols, Next: COFF Symbols, Prev: Symbol Type, Up: Symbol Attributes
-
-5.5.3 Symbol Attributes: `a.out'
---------------------------------
-
-* Menu:
-
-* Symbol Desc:: Descriptor
-* Symbol Other:: Other
-
-
-File: as.info, Node: Symbol Desc, Next: Symbol Other, Up: a.out Symbols
-
-5.5.3.1 Descriptor
-..................
-
-This is an arbitrary 16-bit value. You may establish a symbol's
-descriptor value by using a `.desc' statement (*note `.desc': Desc.).
-A descriptor value means nothing to `as'.
-
-
-File: as.info, Node: Symbol Other, Prev: Symbol Desc, Up: a.out Symbols
-
-5.5.3.2 Other
-.............
-
-This is an arbitrary 8-bit value. It means nothing to `as'.
-
-
-File: as.info, Node: COFF Symbols, Next: SOM Symbols, Prev: a.out Symbols, Up: Symbol Attributes
-
-5.5.4 Symbol Attributes for COFF
---------------------------------
-
-The COFF format supports a multitude of auxiliary symbol attributes;
-like the primary symbol attributes, they are set between `.def' and
-`.endef' directives.
-
-5.5.4.1 Primary Attributes
-..........................
-
-The symbol name is set with `.def'; the value and type, respectively,
-with `.val' and `.type'.
-
-5.5.4.2 Auxiliary Attributes
-............................
-
-The `as' directives `.dim', `.line', `.scl', `.size', `.tag', and
-`.weak' can generate auxiliary symbol table information for COFF.
-
-
-File: as.info, Node: SOM Symbols, Prev: COFF Symbols, Up: Symbol Attributes
-
-5.5.5 Symbol Attributes for SOM
--------------------------------
-
-The SOM format for the HPPA supports a multitude of symbol attributes
-set with the `.EXPORT' and `.IMPORT' directives.
-
- The attributes are described in `HP9000 Series 800 Assembly Language
-Reference Manual' (HP 92432-90001) under the `IMPORT' and `EXPORT'
-assembler directive documentation.
-
-
-File: as.info, Node: Expressions, Next: Pseudo Ops, Prev: Symbols, Up: Top
-
-6 Expressions
-*************
-
-An "expression" specifies an address or numeric value. Whitespace may
-precede and/or follow an expression.
-
- The result of an expression must be an absolute number, or else an
-offset into a particular section. If an expression is not absolute,
-and there is not enough information when `as' sees the expression to
-know its section, a second pass over the source program might be
-necessary to interpret the expression--but the second pass is currently
-not implemented. `as' aborts with an error message in this situation.
-
-* Menu:
-
-* Empty Exprs:: Empty Expressions
-* Integer Exprs:: Integer Expressions
-
-
-File: as.info, Node: Empty Exprs, Next: Integer Exprs, Up: Expressions
-
-6.1 Empty Expressions
-=====================
-
-An empty expression has no value: it is just whitespace or null.
-Wherever an absolute expression is required, you may omit the
-expression, and `as' assumes a value of (absolute) 0. This is
-compatible with other assemblers.
-
-
-File: as.info, Node: Integer Exprs, Prev: Empty Exprs, Up: Expressions
-
-6.2 Integer Expressions
-=======================
-
-An "integer expression" is one or more _arguments_ delimited by
-_operators_.
-
-* Menu:
-
-* Arguments:: Arguments
-* Operators:: Operators
-* Prefix Ops:: Prefix Operators
-* Infix Ops:: Infix Operators
-
-
-File: as.info, Node: Arguments, Next: Operators, Up: Integer Exprs
-
-6.2.1 Arguments
----------------
-
-"Arguments" are symbols, numbers or subexpressions. In other contexts
-arguments are sometimes called "arithmetic operands". In this manual,
-to avoid confusing them with the "instruction operands" of the machine
-language, we use the term "argument" to refer to parts of expressions
-only, reserving the word "operand" to refer only to machine instruction
-operands.
-
- Symbols are evaluated to yield {SECTION NNN} where SECTION is one of
-text, data, bss, absolute, or undefined. NNN is a signed, 2's
-complement 32 bit integer.
-
- Numbers are usually integers.
-
- A number can be a flonum or bignum. In this case, you are warned
-that only the low order 32 bits are used, and `as' pretends these 32
-bits are an integer. You may write integer-manipulating instructions
-that act on exotic constants, compatible with other assemblers.
-
- Subexpressions are a left parenthesis `(' followed by an integer
-expression, followed by a right parenthesis `)'; or a prefix operator
-followed by an argument.
-
-
-File: as.info, Node: Operators, Next: Prefix Ops, Prev: Arguments, Up: Integer Exprs
-
-6.2.2 Operators
----------------
-
-"Operators" are arithmetic functions, like `+' or `%'. Prefix
-operators are followed by an argument. Infix operators appear between
-their arguments. Operators may be preceded and/or followed by
-whitespace.
-
-
-File: as.info, Node: Prefix Ops, Next: Infix Ops, Prev: Operators, Up: Integer Exprs
-
-6.2.3 Prefix Operator
----------------------
-
-`as' has the following "prefix operators". They each take one
-argument, which must be absolute.
-
-`-'
- "Negation". Two's complement negation.
-
-`~'
- "Complementation". Bitwise not.
-
-
-File: as.info, Node: Infix Ops, Prev: Prefix Ops, Up: Integer Exprs
-
-6.2.4 Infix Operators
----------------------
-
-"Infix operators" take two arguments, one on either side. Operators
-have precedence, but operations with equal precedence are performed left
-to right. Apart from `+' or `-', both arguments must be absolute, and
-the result is absolute.
-
- 1. Highest Precedence
-
- `*'
- "Multiplication".
-
- `/'
- "Division". Truncation is the same as the C operator `/'
-
- `%'
- "Remainder".
-
- `<<'
- "Shift Left". Same as the C operator `<<'.
-
- `>>'
- "Shift Right". Same as the C operator `>>'.
-
- 2. Intermediate precedence
-
- `|'
- "Bitwise Inclusive Or".
-
- `&'
- "Bitwise And".
-
- `^'
- "Bitwise Exclusive Or".
-
- `!'
- "Bitwise Or Not".
-
- 3. Low Precedence
-
- `+'
- "Addition". If either argument is absolute, the result has
- the section of the other argument. You may not add together
- arguments from different sections.
-
- `-'
- "Subtraction". If the right argument is absolute, the result
- has the section of the left argument. If both arguments are
- in the same section, the result is absolute. You may not
- subtract arguments from different sections.
-
- `=='
- "Is Equal To"
-
- `<>'
- `!='
- "Is Not Equal To"
-
- `<'
- "Is Less Than"
-
- `>'
- "Is Greater Than"
-
- `>='
- "Is Greater Than Or Equal To"
-
- `<='
- "Is Less Than Or Equal To"
-
- The comparison operators can be used as infix operators. A
- true results has a value of -1 whereas a false result has a
- value of 0. Note, these operators perform signed
- comparisons.
-
- 4. Lowest Precedence
-
- `&&'
- "Logical And".
-
- `||'
- "Logical Or".
-
- These two logical operations can be used to combine the
- results of sub expressions. Note, unlike the comparison
- operators a true result returns a value of 1 but a false
- results does still return 0. Also note that the logical or
- operator has a slightly lower precedence than logical and.
-
-
- In short, it's only meaningful to add or subtract the _offsets_ in an
-address; you can only have a defined section in one of the two
-arguments.
-
-
-File: as.info, Node: Pseudo Ops, Next: Object Attributes, Prev: Expressions, Up: Top
-
-7 Assembler Directives
-**********************
-
-All assembler directives have names that begin with a period (`.').
-The rest of the name is letters, usually in lower case.
-
- This chapter discusses directives that are available regardless of
-the target machine configuration for the GNU assembler. Some machine
-configurations provide additional directives. *Note Machine
-Dependencies::.
-
-* Menu:
-
-* Abort:: `.abort'
-
-* ABORT (COFF):: `.ABORT'
-
-* Align:: `.align ABS-EXPR , ABS-EXPR'
-* Altmacro:: `.altmacro'
-* Ascii:: `.ascii "STRING"'...
-* Asciz:: `.asciz "STRING"'...
-* Balign:: `.balign ABS-EXPR , ABS-EXPR'
-* Byte:: `.byte EXPRESSIONS'
-* CFI directives:: `.cfi_startproc [simple]', `.cfi_endproc', etc.
-* Comm:: `.comm SYMBOL , LENGTH '
-* Data:: `.data SUBSECTION'
-
-* Def:: `.def NAME'
-
-* Desc:: `.desc SYMBOL, ABS-EXPRESSION'
-
-* Dim:: `.dim'
-
-* Double:: `.double FLONUMS'
-* Eject:: `.eject'
-* Else:: `.else'
-* Elseif:: `.elseif'
-* End:: `.end'
-
-* Endef:: `.endef'
-
-* Endfunc:: `.endfunc'
-* Endif:: `.endif'
-* Equ:: `.equ SYMBOL, EXPRESSION'
-* Equiv:: `.equiv SYMBOL, EXPRESSION'
-* Eqv:: `.eqv SYMBOL, EXPRESSION'
-* Err:: `.err'
-* Error:: `.error STRING'
-* Exitm:: `.exitm'
-* Extern:: `.extern'
-* Fail:: `.fail'
-* File:: `.file'
-* Fill:: `.fill REPEAT , SIZE , VALUE'
-* Float:: `.float FLONUMS'
-* Func:: `.func'
-* Global:: `.global SYMBOL', `.globl SYMBOL'
-
-* Gnu_attribute:: `.gnu_attribute TAG,VALUE'
-* Hidden:: `.hidden NAMES'
-
-* hword:: `.hword EXPRESSIONS'
-* Ident:: `.ident'
-* If:: `.if ABSOLUTE EXPRESSION'
-* Incbin:: `.incbin "FILE"[,SKIP[,COUNT]]'
-* Include:: `.include "FILE"'
-* Int:: `.int EXPRESSIONS'
-
-* Internal:: `.internal NAMES'
-
-* Irp:: `.irp SYMBOL,VALUES'...
-* Irpc:: `.irpc SYMBOL,VALUES'...
-* Lcomm:: `.lcomm SYMBOL , LENGTH'
-* Lflags:: `.lflags'
-
-* Line:: `.line LINE-NUMBER'
-
-* Linkonce:: `.linkonce [TYPE]'
-* List:: `.list'
-* Ln:: `.ln LINE-NUMBER'
-* Loc:: `.loc FILENO LINENO'
-* Loc_mark_labels:: `.loc_mark_labels ENABLE'
-
-* Local:: `.local NAMES'
-
-* Long:: `.long EXPRESSIONS'
-
-* Macro:: `.macro NAME ARGS'...
-* MRI:: `.mri VAL'
-* Noaltmacro:: `.noaltmacro'
-* Nolist:: `.nolist'
-* Octa:: `.octa BIGNUMS'
-* Org:: `.org NEW-LC, FILL'
-* P2align:: `.p2align ABS-EXPR, ABS-EXPR, ABS-EXPR'
-
-* PopSection:: `.popsection'
-* Previous:: `.previous'
-
-* Print:: `.print STRING'
-
-* Protected:: `.protected NAMES'
-
-* Psize:: `.psize LINES, COLUMNS'
-* Purgem:: `.purgem NAME'
-
-* PushSection:: `.pushsection NAME'
-
-* Quad:: `.quad BIGNUMS'
-* Reloc:: `.reloc OFFSET, RELOC_NAME[, EXPRESSION]'
-* Rept:: `.rept COUNT'
-* Sbttl:: `.sbttl "SUBHEADING"'
-
-* Scl:: `.scl CLASS'
-
-* Section:: `.section NAME[, FLAGS]'
-
-* Set:: `.set SYMBOL, EXPRESSION'
-* Short:: `.short EXPRESSIONS'
-* Single:: `.single FLONUMS'
-
-* Size:: `.size [NAME , EXPRESSION]'
-
-* Skip:: `.skip SIZE , FILL'
-
-* Sleb128:: `.sleb128 EXPRESSIONS'
-
-* Space:: `.space SIZE , FILL'
-
-* Stab:: `.stabd, .stabn, .stabs'
-
-* String:: `.string "STR"', `.string8 "STR"', `.string16 "STR"', `.string32 "STR"', `.string64 "STR"'
-* Struct:: `.struct EXPRESSION'
-
-* SubSection:: `.subsection'
-* Symver:: `.symver NAME,NAME2@NODENAME'
-
-
-* Tag:: `.tag STRUCTNAME'
-
-* Text:: `.text SUBSECTION'
-* Title:: `.title "HEADING"'
-
-* Type:: `.type <INT | NAME , TYPE DESCRIPTION>'
-
-* Uleb128:: `.uleb128 EXPRESSIONS'
-
-* Val:: `.val ADDR'
-
-
-* Version:: `.version "STRING"'
-* VTableEntry:: `.vtable_entry TABLE, OFFSET'
-* VTableInherit:: `.vtable_inherit CHILD, PARENT'
-
-* Warning:: `.warning STRING'
-* Weak:: `.weak NAMES'
-* Weakref:: `.weakref ALIAS, SYMBOL'
-* Word:: `.word EXPRESSIONS'
-* Deprecated:: Deprecated Directives
-
-
-File: as.info, Node: Abort, Next: ABORT (COFF), Up: Pseudo Ops
-
-7.1 `.abort'
-============
-
-This directive stops the assembly immediately. It is for compatibility
-with other assemblers. The original idea was that the assembly
-language source would be piped into the assembler. If the sender of
-the source quit, it could use this directive tells `as' to quit also.
-One day `.abort' will not be supported.
-
-
-File: as.info, Node: ABORT (COFF), Next: Align, Prev: Abort, Up: Pseudo Ops
-
-7.2 `.ABORT' (COFF)
-===================
-
-When producing COFF output, `as' accepts this directive as a synonym
-for `.abort'.
-
-
-File: as.info, Node: Align, Next: Altmacro, Prev: ABORT (COFF), Up: Pseudo Ops
-
-7.3 `.align ABS-EXPR, ABS-EXPR, ABS-EXPR'
-=========================================
-
-Pad the location counter (in the current subsection) to a particular
-storage boundary. The first expression (which must be absolute) is the
-alignment required, as described below.
-
- The second expression (also absolute) gives the fill value to be
-stored in the padding bytes. It (and the comma) may be omitted. If it
-is omitted, the padding bytes are normally zero. However, on some
-systems, if the section is marked as containing code and the fill value
-is omitted, the space is filled with no-op instructions.
-
- The third expression is also absolute, and is also optional. If it
-is present, it is the maximum number of bytes that should be skipped by
-this alignment directive. If doing the alignment would require
-skipping more bytes than the specified maximum, then the alignment is
-not done at all. You can omit the fill value (the second argument)
-entirely by simply using two commas after the required alignment; this
-can be useful if you want the alignment to be filled with no-op
-instructions when appropriate.
-
- The way the required alignment is specified varies from system to
-system. For the arc, hppa, i386 using ELF, i860, iq2000, m68k, or32,
-s390, sparc, tic4x, tic80 and xtensa, the first expression is the
-alignment request in bytes. For example `.align 8' advances the
-location counter until it is a multiple of 8. If the location counter
-is already a multiple of 8, no change is needed. For the tic54x, the
-first expression is the alignment request in words.
-
- For other systems, including ppc, i386 using a.out format, arm and
-strongarm, it is the number of low-order zero bits the location counter
-must have after advancement. For example `.align 3' advances the
-location counter until it a multiple of 8. If the location counter is
-already a multiple of 8, no change is needed.
-
- This inconsistency is due to the different behaviors of the various
-native assemblers for these systems which GAS must emulate. GAS also
-provides `.balign' and `.p2align' directives, described later, which
-have a consistent behavior across all architectures (but are specific
-to GAS).
-
-
-File: as.info, Node: Altmacro, Next: Ascii, Prev: Align, Up: Pseudo Ops
-
-7.4 `.altmacro'
-===============
-
-Enable alternate macro mode, enabling:
-
-`LOCAL NAME [ , ... ]'
- One additional directive, `LOCAL', is available. It is used to
- generate a string replacement for each of the NAME arguments, and
- replace any instances of NAME in each macro expansion. The
- replacement string is unique in the assembly, and different for
- each separate macro expansion. `LOCAL' allows you to write macros
- that define symbols, without fear of conflict between separate
- macro expansions.
-
-`String delimiters'
- You can write strings delimited in these other ways besides
- `"STRING"':
-
- `'STRING''
- You can delimit strings with single-quote characters.
-
- `<STRING>'
- You can delimit strings with matching angle brackets.
-
-`single-character string escape'
- To include any single character literally in a string (even if the
- character would otherwise have some special meaning), you can
- prefix the character with `!' (an exclamation mark). For example,
- you can write `<4.3 !> 5.4!!>' to get the literal text `4.3 >
- 5.4!'.
-
-`Expression results as strings'
- You can write `%EXPR' to evaluate the expression EXPR and use the
- result as a string.
-
-
-File: as.info, Node: Ascii, Next: Asciz, Prev: Altmacro, Up: Pseudo Ops
-
-7.5 `.ascii "STRING"'...
-========================
-
-`.ascii' expects zero or more string literals (*note Strings::)
-separated by commas. It assembles each string (with no automatic
-trailing zero byte) into consecutive addresses.
-
-
-File: as.info, Node: Asciz, Next: Balign, Prev: Ascii, Up: Pseudo Ops
-
-7.6 `.asciz "STRING"'...
-========================
-
-`.asciz' is just like `.ascii', but each string is followed by a zero
-byte. The "z" in `.asciz' stands for "zero".
-
-
-File: as.info, Node: Balign, Next: Byte, Prev: Asciz, Up: Pseudo Ops
-
-7.7 `.balign[wl] ABS-EXPR, ABS-EXPR, ABS-EXPR'
-==============================================
-
-Pad the location counter (in the current subsection) to a particular
-storage boundary. The first expression (which must be absolute) is the
-alignment request in bytes. For example `.balign 8' advances the
-location counter until it is a multiple of 8. If the location counter
-is already a multiple of 8, no change is needed.
-
- The second expression (also absolute) gives the fill value to be
-stored in the padding bytes. It (and the comma) may be omitted. If it
-is omitted, the padding bytes are normally zero. However, on some
-systems, if the section is marked as containing code and the fill value
-is omitted, the space is filled with no-op instructions.
-
- The third expression is also absolute, and is also optional. If it
-is present, it is the maximum number of bytes that should be skipped by
-this alignment directive. If doing the alignment would require
-skipping more bytes than the specified maximum, then the alignment is
-not done at all. You can omit the fill value (the second argument)
-entirely by simply using two commas after the required alignment; this
-can be useful if you want the alignment to be filled with no-op
-instructions when appropriate.
-
- The `.balignw' and `.balignl' directives are variants of the
-`.balign' directive. The `.balignw' directive treats the fill pattern
-as a two byte word value. The `.balignl' directives treats the fill
-pattern as a four byte longword value. For example, `.balignw
-4,0x368d' will align to a multiple of 4. If it skips two bytes, they
-will be filled in with the value 0x368d (the exact placement of the
-bytes depends upon the endianness of the processor). If it skips 1 or
-3 bytes, the fill value is undefined.
-
-
-File: as.info, Node: Byte, Next: CFI directives, Prev: Balign, Up: Pseudo Ops
-
-7.8 `.byte EXPRESSIONS'
-=======================
-
-`.byte' expects zero or more expressions, separated by commas. Each
-expression is assembled into the next byte.
-
-
-File: as.info, Node: CFI directives, Next: Comm, Prev: Byte, Up: Pseudo Ops
-
-7.9 `.cfi_sections SECTION_LIST'
-================================
-
-`.cfi_sections' may be used to specify whether CFI directives should
-emit `.eh_frame' section and/or `.debug_frame' section. If
-SECTION_LIST is `.eh_frame', `.eh_frame' is emitted, if SECTION_LIST is
-`.debug_frame', `.debug_frame' is emitted. To emit both use
-`.eh_frame, .debug_frame'. The default if this directive is not used
-is `.cfi_sections .eh_frame'.
-
-7.10 `.cfi_startproc [simple]'
-==============================
-
-`.cfi_startproc' is used at the beginning of each function that should
-have an entry in `.eh_frame'. It initializes some internal data
-structures. Don't forget to close the function by `.cfi_endproc'.
-
- Unless `.cfi_startproc' is used along with parameter `simple' it
-also emits some architecture dependent initial CFI instructions.
-
-7.11 `.cfi_endproc'
-===================
-
-`.cfi_endproc' is used at the end of a function where it closes its
-unwind entry previously opened by `.cfi_startproc', and emits it to
-`.eh_frame'.
-
-7.12 `.cfi_personality ENCODING [, EXP]'
-========================================
-
-`.cfi_personality' defines personality routine and its encoding.
-ENCODING must be a constant determining how the personality should be
-encoded. If it is 255 (`DW_EH_PE_omit'), second argument is not
-present, otherwise second argument should be a constant or a symbol
-name. When using indirect encodings, the symbol provided should be the
-location where personality can be loaded from, not the personality
-routine itself. The default after `.cfi_startproc' is
-`.cfi_personality 0xff', no personality routine.
-
-7.13 `.cfi_lsda ENCODING [, EXP]'
-=================================
-
-`.cfi_lsda' defines LSDA and its encoding. ENCODING must be a constant
-determining how the LSDA should be encoded. If it is 255
-(`DW_EH_PE_omit'), second argument is not present, otherwise second
-argument should be a constant or a symbol name. The default after
-`.cfi_startproc' is `.cfi_lsda 0xff', no LSDA.
-
-7.14 `.cfi_def_cfa REGISTER, OFFSET'
-====================================
-
-`.cfi_def_cfa' defines a rule for computing CFA as: take address from
-REGISTER and add OFFSET to it.
-
-7.15 `.cfi_def_cfa_register REGISTER'
-=====================================
-
-`.cfi_def_cfa_register' modifies a rule for computing CFA. From now on
-REGISTER will be used instead of the old one. Offset remains the same.
-
-7.16 `.cfi_def_cfa_offset OFFSET'
-=================================
-
-`.cfi_def_cfa_offset' modifies a rule for computing CFA. Register
-remains the same, but OFFSET is new. Note that it is the absolute
-offset that will be added to a defined register to compute CFA address.
-
-7.17 `.cfi_adjust_cfa_offset OFFSET'
-====================================
-
-Same as `.cfi_def_cfa_offset' but OFFSET is a relative value that is
-added/substracted from the previous offset.
-
-7.18 `.cfi_offset REGISTER, OFFSET'
-===================================
-
-Previous value of REGISTER is saved at offset OFFSET from CFA.
-
-7.19 `.cfi_rel_offset REGISTER, OFFSET'
-=======================================
-
-Previous value of REGISTER is saved at offset OFFSET from the current
-CFA register. This is transformed to `.cfi_offset' using the known
-displacement of the CFA register from the CFA. This is often easier to
-use, because the number will match the code it's annotating.
-
-7.20 `.cfi_register REGISTER1, REGISTER2'
-=========================================
-
-Previous value of REGISTER1 is saved in register REGISTER2.
-
-7.21 `.cfi_restore REGISTER'
-============================
-
-`.cfi_restore' says that the rule for REGISTER is now the same as it
-was at the beginning of the function, after all initial instruction
-added by `.cfi_startproc' were executed.
-
-7.22 `.cfi_undefined REGISTER'
-==============================
-
-From now on the previous value of REGISTER can't be restored anymore.
-
-7.23 `.cfi_same_value REGISTER'
-===============================
-
-Current value of REGISTER is the same like in the previous frame, i.e.
-no restoration needed.
-
-7.24 `.cfi_remember_state',
-===========================
-
-First save all current rules for all registers by `.cfi_remember_state',
-then totally screw them up by subsequent `.cfi_*' directives and when
-everything is hopelessly bad, use `.cfi_restore_state' to restore the
-previous saved state.
-
-7.25 `.cfi_return_column REGISTER'
-==================================
-
-Change return column REGISTER, i.e. the return address is either
-directly in REGISTER or can be accessed by rules for REGISTER.
-
-7.26 `.cfi_signal_frame'
-========================
-
-Mark current function as signal trampoline.
-
-7.27 `.cfi_window_save'
-=======================
-
-SPARC register window has been saved.
-
-7.28 `.cfi_escape' EXPRESSION[, ...]
-====================================
-
-Allows the user to add arbitrary bytes to the unwind info. One might
-use this to add OS-specific CFI opcodes, or generic CFI opcodes that
-GAS does not yet support.
-
-7.29 `.cfi_val_encoded_addr REGISTER, ENCODING, LABEL'
-======================================================
-
-The current value of REGISTER is LABEL. The value of LABEL will be
-encoded in the output file according to ENCODING; see the description
-of `.cfi_personality' for details on this encoding.
-
- The usefulness of equating a register to a fixed label is probably
-limited to the return address register. Here, it can be useful to mark
-a code segment that has only one return address which is reached by a
-direct branch and no copy of the return address exists in memory or
-another register.
-
-
-File: as.info, Node: Comm, Next: Data, Prev: CFI directives, Up: Pseudo Ops
-
-7.30 `.comm SYMBOL , LENGTH '
-=============================
-
-`.comm' declares a common symbol named SYMBOL. When linking, a common
-symbol in one object file may be merged with a defined or common symbol
-of the same name in another object file. If `ld' does not see a
-definition for the symbol-just one or more common symbols-then it will
-allocate LENGTH bytes of uninitialized memory. LENGTH must be an
-absolute expression. If `ld' sees multiple common symbols with the
-same name, and they do not all have the same size, it will allocate
-space using the largest size.
-
- When using ELF or (as a GNU extension) PE, the `.comm' directive
-takes an optional third argument. This is the desired alignment of the
-symbol, specified for ELF as a byte boundary (for example, an alignment
-of 16 means that the least significant 4 bits of the address should be
-zero), and for PE as a power of two (for example, an alignment of 5
-means aligned to a 32-byte boundary). The alignment must be an
-absolute expression, and it must be a power of two. If `ld' allocates
-uninitialized memory for the common symbol, it will use the alignment
-when placing the symbol. If no alignment is specified, `as' will set
-the alignment to the largest power of two less than or equal to the
-size of the symbol, up to a maximum of 16 on ELF, or the default
-section alignment of 4 on PE(1).
-
- The syntax for `.comm' differs slightly on the HPPA. The syntax is
-`SYMBOL .comm, LENGTH'; SYMBOL is optional.
-
- ---------- Footnotes ----------
-
- (1) This is not the same as the executable image file alignment
-controlled by `ld''s `--section-alignment' option; image file sections
-in PE are aligned to multiples of 4096, which is far too large an
-alignment for ordinary variables. It is rather the default alignment
-for (non-debug) sections within object (`*.o') files, which are less
-strictly aligned.
-
-
-File: as.info, Node: Data, Next: Def, Prev: Comm, Up: Pseudo Ops
-
-7.31 `.data SUBSECTION'
-=======================
-
-`.data' tells `as' to assemble the following statements onto the end of
-the data subsection numbered SUBSECTION (which is an absolute
-expression). If SUBSECTION is omitted, it defaults to zero.
-
-
-File: as.info, Node: Def, Next: Desc, Prev: Data, Up: Pseudo Ops
-
-7.32 `.def NAME'
-================
-
-Begin defining debugging information for a symbol NAME; the definition
-extends until the `.endef' directive is encountered.
-
-
-File: as.info, Node: Desc, Next: Dim, Prev: Def, Up: Pseudo Ops
-
-7.33 `.desc SYMBOL, ABS-EXPRESSION'
-===================================
-
-This directive sets the descriptor of the symbol (*note Symbol
-Attributes::) to the low 16 bits of an absolute expression.
-
- The `.desc' directive is not available when `as' is configured for
-COFF output; it is only for `a.out' or `b.out' object format. For the
-sake of compatibility, `as' accepts it, but produces no output, when
-configured for COFF.
-
-
-File: as.info, Node: Dim, Next: Double, Prev: Desc, Up: Pseudo Ops
-
-7.34 `.dim'
-===========
-
-This directive is generated by compilers to include auxiliary debugging
-information in the symbol table. It is only permitted inside
-`.def'/`.endef' pairs.
-
-
-File: as.info, Node: Double, Next: Eject, Prev: Dim, Up: Pseudo Ops
-
-7.35 `.double FLONUMS'
-======================
-
-`.double' expects zero or more flonums, separated by commas. It
-assembles floating point numbers. The exact kind of floating point
-numbers emitted depends on how `as' is configured. *Note Machine
-Dependencies::.
-
-
-File: as.info, Node: Eject, Next: Else, Prev: Double, Up: Pseudo Ops
-
-7.36 `.eject'
-=============
-
-Force a page break at this point, when generating assembly listings.
-
-
-File: as.info, Node: Else, Next: Elseif, Prev: Eject, Up: Pseudo Ops
-
-7.37 `.else'
-============
-
-`.else' is part of the `as' support for conditional assembly; see *note
-`.if': If. It marks the beginning of a section of code to be assembled
-if the condition for the preceding `.if' was false.
-
-
-File: as.info, Node: Elseif, Next: End, Prev: Else, Up: Pseudo Ops
-
-7.38 `.elseif'
-==============
-
-`.elseif' is part of the `as' support for conditional assembly; see
-*note `.if': If. It is shorthand for beginning a new `.if' block that
-would otherwise fill the entire `.else' section.
-
-
-File: as.info, Node: End, Next: Endef, Prev: Elseif, Up: Pseudo Ops
-
-7.39 `.end'
-===========
-
-`.end' marks the end of the assembly file. `as' does not process
-anything in the file past the `.end' directive.
-
-
-File: as.info, Node: Endef, Next: Endfunc, Prev: End, Up: Pseudo Ops
-
-7.40 `.endef'
-=============
-
-This directive flags the end of a symbol definition begun with `.def'.
-
-
-File: as.info, Node: Endfunc, Next: Endif, Prev: Endef, Up: Pseudo Ops
-
-7.41 `.endfunc'
-===============
-
-`.endfunc' marks the end of a function specified with `.func'.
-
-
-File: as.info, Node: Endif, Next: Equ, Prev: Endfunc, Up: Pseudo Ops
-
-7.42 `.endif'
-=============
-
-`.endif' is part of the `as' support for conditional assembly; it marks
-the end of a block of code that is only assembled conditionally. *Note
-`.if': If.
-
-
-File: as.info, Node: Equ, Next: Equiv, Prev: Endif, Up: Pseudo Ops
-
-7.43 `.equ SYMBOL, EXPRESSION'
-==============================
-
-This directive sets the value of SYMBOL to EXPRESSION. It is
-synonymous with `.set'; see *note `.set': Set.
-
- The syntax for `equ' on the HPPA is `SYMBOL .equ EXPRESSION'.
-
- The syntax for `equ' on the Z80 is `SYMBOL equ EXPRESSION'. On the
-Z80 it is an eror if SYMBOL is already defined, but the symbol is not
-protected from later redefinition. Compare *note Equiv::.
-
-
-File: as.info, Node: Equiv, Next: Eqv, Prev: Equ, Up: Pseudo Ops
-
-7.44 `.equiv SYMBOL, EXPRESSION'
-================================
-
-The `.equiv' directive is like `.equ' and `.set', except that the
-assembler will signal an error if SYMBOL is already defined. Note a
-symbol which has been referenced but not actually defined is considered
-to be undefined.
-
- Except for the contents of the error message, this is roughly
-equivalent to
- .ifdef SYM
- .err
- .endif
- .equ SYM,VAL
- plus it protects the symbol from later redefinition.
-
-
-File: as.info, Node: Eqv, Next: Err, Prev: Equiv, Up: Pseudo Ops
-
-7.45 `.eqv SYMBOL, EXPRESSION'
-==============================
-
-The `.eqv' directive is like `.equiv', but no attempt is made to
-evaluate the expression or any part of it immediately. Instead each
-time the resulting symbol is used in an expression, a snapshot of its
-current value is taken.
-
-
-File: as.info, Node: Err, Next: Error, Prev: Eqv, Up: Pseudo Ops
-
-7.46 `.err'
-===========
-
-If `as' assembles a `.err' directive, it will print an error message
-and, unless the `-Z' option was used, it will not generate an object
-file. This can be used to signal an error in conditionally compiled
-code.
-
-
-File: as.info, Node: Error, Next: Exitm, Prev: Err, Up: Pseudo Ops
-
-7.47 `.error "STRING"'
-======================
-
-Similarly to `.err', this directive emits an error, but you can specify
-a string that will be emitted as the error message. If you don't
-specify the message, it defaults to `".error directive invoked in
-source file"'. *Note Error and Warning Messages: Errors.
-
- .error "This code has not been assembled and tested."
-
-
-File: as.info, Node: Exitm, Next: Extern, Prev: Error, Up: Pseudo Ops
-
-7.48 `.exitm'
-=============
-
-Exit early from the current macro definition. *Note Macro::.
-
-
-File: as.info, Node: Extern, Next: Fail, Prev: Exitm, Up: Pseudo Ops
-
-7.49 `.extern'
-==============
-
-`.extern' is accepted in the source program--for compatibility with
-other assemblers--but it is ignored. `as' treats all undefined symbols
-as external.
-
-
-File: as.info, Node: Fail, Next: File, Prev: Extern, Up: Pseudo Ops
-
-7.50 `.fail EXPRESSION'
-=======================
-
-Generates an error or a warning. If the value of the EXPRESSION is 500
-or more, `as' will print a warning message. If the value is less than
-500, `as' will print an error message. The message will include the
-value of EXPRESSION. This can occasionally be useful inside complex
-nested macros or conditional assembly.
-
-
-File: as.info, Node: File, Next: Fill, Prev: Fail, Up: Pseudo Ops
-
-7.51 `.file'
-============
-
-There are two different versions of the `.file' directive. Targets
-that support DWARF2 line number information use the DWARF2 version of
-`.file'. Other targets use the default version.
-
-Default Version
----------------
-
-This version of the `.file' directive tells `as' that we are about to
-start a new logical file. The syntax is:
-
- .file STRING
-
- STRING is the new file name. In general, the filename is recognized
-whether or not it is surrounded by quotes `"'; but if you wish to
-specify an empty file name, you must give the quotes-`""'. This
-statement may go away in future: it is only recognized to be compatible
-with old `as' programs.
-
-DWARF2 Version
---------------
-
-When emitting DWARF2 line number information, `.file' assigns filenames
-to the `.debug_line' file name table. The syntax is:
-
- .file FILENO FILENAME
-
- The FILENO operand should be a unique positive integer to use as the
-index of the entry in the table. The FILENAME operand is a C string
-literal.
-
- The detail of filename indices is exposed to the user because the
-filename table is shared with the `.debug_info' section of the DWARF2
-debugging information, and thus the user must know the exact indices
-that table entries will have.
-
-
-File: as.info, Node: Fill, Next: Float, Prev: File, Up: Pseudo Ops
-
-7.52 `.fill REPEAT , SIZE , VALUE'
-==================================
-
-REPEAT, SIZE and VALUE are absolute expressions. This emits REPEAT
-copies of SIZE bytes. REPEAT may be zero or more. SIZE may be zero or
-more, but if it is more than 8, then it is deemed to have the value 8,
-compatible with other people's assemblers. The contents of each REPEAT
-bytes is taken from an 8-byte number. The highest order 4 bytes are
-zero. The lowest order 4 bytes are VALUE rendered in the byte-order of
-an integer on the computer `as' is assembling for. Each SIZE bytes in
-a repetition is taken from the lowest order SIZE bytes of this number.
-Again, this bizarre behavior is compatible with other people's
-assemblers.
-
- SIZE and VALUE are optional. If the second comma and VALUE are
-absent, VALUE is assumed zero. If the first comma and following tokens
-are absent, SIZE is assumed to be 1.
-
-
-File: as.info, Node: Float, Next: Func, Prev: Fill, Up: Pseudo Ops
-
-7.53 `.float FLONUMS'
-=====================
-
-This directive assembles zero or more flonums, separated by commas. It
-has the same effect as `.single'. The exact kind of floating point
-numbers emitted depends on how `as' is configured. *Note Machine
-Dependencies::.
-
-
-File: as.info, Node: Func, Next: Global, Prev: Float, Up: Pseudo Ops
-
-7.54 `.func NAME[,LABEL]'
-=========================
-
-`.func' emits debugging information to denote function NAME, and is
-ignored unless the file is assembled with debugging enabled. Only
-`--gstabs[+]' is currently supported. LABEL is the entry point of the
-function and if omitted NAME prepended with the `leading char' is used.
-`leading char' is usually `_' or nothing, depending on the target. All
-functions are currently defined to have `void' return type. The
-function must be terminated with `.endfunc'.
-
-
-File: as.info, Node: Global, Next: Gnu_attribute, Prev: Func, Up: Pseudo Ops
-
-7.55 `.global SYMBOL', `.globl SYMBOL'
-======================================
-
-`.global' makes the symbol visible to `ld'. If you define SYMBOL in
-your partial program, its value is made available to other partial
-programs that are linked with it. Otherwise, SYMBOL takes its
-attributes from a symbol of the same name from another file linked into
-the same program.
-
- Both spellings (`.globl' and `.global') are accepted, for
-compatibility with other assemblers.
-
- On the HPPA, `.global' is not always enough to make it accessible to
-other partial programs. You may need the HPPA-only `.EXPORT' directive
-as well. *Note HPPA Assembler Directives: HPPA Directives.
-
-
-File: as.info, Node: Gnu_attribute, Next: Hidden, Prev: Global, Up: Pseudo Ops
-
-7.56 `.gnu_attribute TAG,VALUE'
-===============================
-
-Record a GNU object attribute for this file. *Note Object Attributes::.
-
-
-File: as.info, Node: Hidden, Next: hword, Prev: Gnu_attribute, Up: Pseudo Ops
-
-7.57 `.hidden NAMES'
-====================
-
-This is one of the ELF visibility directives. The other two are
-`.internal' (*note `.internal': Internal.) and `.protected' (*note
-`.protected': Protected.).
-
- This directive overrides the named symbols default visibility (which
-is set by their binding: local, global or weak). The directive sets
-the visibility to `hidden' which means that the symbols are not visible
-to other components. Such symbols are always considered to be
-`protected' as well.
-
-
-File: as.info, Node: hword, Next: Ident, Prev: Hidden, Up: Pseudo Ops
-
-7.58 `.hword EXPRESSIONS'
-=========================
-
-This expects zero or more EXPRESSIONS, and emits a 16 bit number for
-each.
-
- This directive is a synonym for `.short'; depending on the target
-architecture, it may also be a synonym for `.word'.
-
-
-File: as.info, Node: Ident, Next: If, Prev: hword, Up: Pseudo Ops
-
-7.59 `.ident'
-=============
-
-This directive is used by some assemblers to place tags in object
-files. The behavior of this directive varies depending on the target.
-When using the a.out object file format, `as' simply accepts the
-directive for source-file compatibility with existing assemblers, but
-does not emit anything for it. When using COFF, comments are emitted
-to the `.comment' or `.rdata' section, depending on the target. When
-using ELF, comments are emitted to the `.comment' section.
-
-
-File: as.info, Node: If, Next: Incbin, Prev: Ident, Up: Pseudo Ops
-
-7.60 `.if ABSOLUTE EXPRESSION'
-==============================
-
-`.if' marks the beginning of a section of code which is only considered
-part of the source program being assembled if the argument (which must
-be an ABSOLUTE EXPRESSION) is non-zero. The end of the conditional
-section of code must be marked by `.endif' (*note `.endif': Endif.);
-optionally, you may include code for the alternative condition, flagged
-by `.else' (*note `.else': Else.). If you have several conditions to
-check, `.elseif' may be used to avoid nesting blocks if/else within
-each subsequent `.else' block.
-
- The following variants of `.if' are also supported:
-`.ifdef SYMBOL'
- Assembles the following section of code if the specified SYMBOL
- has been defined. Note a symbol which has been referenced but not
- yet defined is considered to be undefined.
-
-`.ifb TEXT'
- Assembles the following section of code if the operand is blank
- (empty).
-
-`.ifc STRING1,STRING2'
- Assembles the following section of code if the two strings are the
- same. The strings may be optionally quoted with single quotes.
- If they are not quoted, the first string stops at the first comma,
- and the second string stops at the end of the line. Strings which
- contain whitespace should be quoted. The string comparison is
- case sensitive.
-
-`.ifeq ABSOLUTE EXPRESSION'
- Assembles the following section of code if the argument is zero.
-
-`.ifeqs STRING1,STRING2'
- Another form of `.ifc'. The strings must be quoted using double
- quotes.
-
-`.ifge ABSOLUTE EXPRESSION'
- Assembles the following section of code if the argument is greater
- than or equal to zero.
-
-`.ifgt ABSOLUTE EXPRESSION'
- Assembles the following section of code if the argument is greater
- than zero.
-
-`.ifle ABSOLUTE EXPRESSION'
- Assembles the following section of code if the argument is less
- than or equal to zero.
-
-`.iflt ABSOLUTE EXPRESSION'
- Assembles the following section of code if the argument is less
- than zero.
-
-`.ifnb TEXT'
- Like `.ifb', but the sense of the test is reversed: this assembles
- the following section of code if the operand is non-blank
- (non-empty).
-
-`.ifnc STRING1,STRING2.'
- Like `.ifc', but the sense of the test is reversed: this assembles
- the following section of code if the two strings are not the same.
-
-`.ifndef SYMBOL'
-`.ifnotdef SYMBOL'
- Assembles the following section of code if the specified SYMBOL
- has not been defined. Both spelling variants are equivalent.
- Note a symbol which has been referenced but not yet defined is
- considered to be undefined.
-
-`.ifne ABSOLUTE EXPRESSION'
- Assembles the following section of code if the argument is not
- equal to zero (in other words, this is equivalent to `.if').
-
-`.ifnes STRING1,STRING2'
- Like `.ifeqs', but the sense of the test is reversed: this
- assembles the following section of code if the two strings are not
- the same.
-
-
-File: as.info, Node: Incbin, Next: Include, Prev: If, Up: Pseudo Ops
-
-7.61 `.incbin "FILE"[,SKIP[,COUNT]]'
-====================================
-
-The `incbin' directive can be used with `--allow-incbin'.
-
- The `incbin' directive includes FILE verbatim at the current
-location. You can control the search paths used with the `-I'
-command-line option (*note Command-Line Options: Invoking.). Quotation
-marks are required around FILE.
-
- The SKIP argument skips a number of bytes from the start of the
-FILE. The COUNT argument indicates the maximum number of bytes to
-read. Note that the data is not aligned in any way, so it is the user's
-responsibility to make sure that proper alignment is provided both
-before and after the `incbin' directive.
-
-
-File: as.info, Node: Include, Next: Int, Prev: Incbin, Up: Pseudo Ops
-
-7.62 `.include "FILE"'
-======================
-
-This directive provides a way to include supporting files at specified
-points in your source program. The code from FILE is assembled as if
-it followed the point of the `.include'; when the end of the included
-file is reached, assembly of the original file continues. You can
-control the search paths used with the `-I' command-line option (*note
-Command-Line Options: Invoking.). Quotation marks are required around
-FILE.
-
-
-File: as.info, Node: Int, Next: Internal, Prev: Include, Up: Pseudo Ops
-
-7.63 `.int EXPRESSIONS'
-=======================
-
-Expect zero or more EXPRESSIONS, of any section, separated by commas.
-For each expression, emit a number that, at run time, is the value of
-that expression. The byte order and bit size of the number depends on
-what kind of target the assembly is for.
-
-
-File: as.info, Node: Internal, Next: Irp, Prev: Int, Up: Pseudo Ops
-
-7.64 `.internal NAMES'
-======================
-
-This is one of the ELF visibility directives. The other two are
-`.hidden' (*note `.hidden': Hidden.) and `.protected' (*note
-`.protected': Protected.).
-
- This directive overrides the named symbols default visibility (which
-is set by their binding: local, global or weak). The directive sets
-the visibility to `internal' which means that the symbols are
-considered to be `hidden' (i.e., not visible to other components), and
-that some extra, processor specific processing must also be performed
-upon the symbols as well.
-
-
-File: as.info, Node: Irp, Next: Irpc, Prev: Internal, Up: Pseudo Ops
-
-7.65 `.irp SYMBOL,VALUES'...
-============================
-
-Evaluate a sequence of statements assigning different values to SYMBOL.
-The sequence of statements starts at the `.irp' directive, and is
-terminated by an `.endr' directive. For each VALUE, SYMBOL is set to
-VALUE, and the sequence of statements is assembled. If no VALUE is
-listed, the sequence of statements is assembled once, with SYMBOL set
-to the null string. To refer to SYMBOL within the sequence of
-statements, use \SYMBOL.
-
- For example, assembling
-
- .irp param,1,2,3
- move d\param,sp@-
- .endr
-
- is equivalent to assembling
-
- move d1,sp@-
- move d2,sp@-
- move d3,sp@-
-
- For some caveats with the spelling of SYMBOL, see also *note Macro::.
-
-
-File: as.info, Node: Irpc, Next: Lcomm, Prev: Irp, Up: Pseudo Ops
-
-7.66 `.irpc SYMBOL,VALUES'...
-=============================
-
-Evaluate a sequence of statements assigning different values to SYMBOL.
-The sequence of statements starts at the `.irpc' directive, and is
-terminated by an `.endr' directive. For each character in VALUE,
-SYMBOL is set to the character, and the sequence of statements is
-assembled. If no VALUE is listed, the sequence of statements is
-assembled once, with SYMBOL set to the null string. To refer to SYMBOL
-within the sequence of statements, use \SYMBOL.
-
- For example, assembling
-
- .irpc param,123
- move d\param,sp@-
- .endr
-
- is equivalent to assembling
-
- move d1,sp@-
- move d2,sp@-
- move d3,sp@-
-
- For some caveats with the spelling of SYMBOL, see also the discussion
-at *Note Macro::.
-
-
-File: as.info, Node: Lcomm, Next: Lflags, Prev: Irpc, Up: Pseudo Ops
-
-7.67 `.lcomm SYMBOL , LENGTH'
-=============================
-
-Reserve LENGTH (an absolute expression) bytes for a local common
-denoted by SYMBOL. The section and value of SYMBOL are those of the
-new local common. The addresses are allocated in the bss section, so
-that at run-time the bytes start off zeroed. SYMBOL is not declared
-global (*note `.global': Global.), so is normally not visible to `ld'.
-
- Some targets permit a third argument to be used with `.lcomm'. This
-argument specifies the desired alignment of the symbol in the bss
-section.
-
- The syntax for `.lcomm' differs slightly on the HPPA. The syntax is
-`SYMBOL .lcomm, LENGTH'; SYMBOL is optional.
-
-
-File: as.info, Node: Lflags, Next: Line, Prev: Lcomm, Up: Pseudo Ops
-
-7.68 `.lflags'
-==============
-
-`as' accepts this directive, for compatibility with other assemblers,
-but ignores it.
-
-
-File: as.info, Node: Line, Next: Linkonce, Prev: Lflags, Up: Pseudo Ops
-
-7.69 `.line LINE-NUMBER'
-========================
-
-Change the logical line number. LINE-NUMBER must be an absolute
-expression. The next line has that logical line number. Therefore any
-other statements on the current line (after a statement separator
-character) are reported as on logical line number LINE-NUMBER - 1. One
-day `as' will no longer support this directive: it is recognized only
-for compatibility with existing assembler programs.
-
-Even though this is a directive associated with the `a.out' or `b.out'
-object-code formats, `as' still recognizes it when producing COFF
-output, and treats `.line' as though it were the COFF `.ln' _if_ it is
-found outside a `.def'/`.endef' pair.
-
- Inside a `.def', `.line' is, instead, one of the directives used by
-compilers to generate auxiliary symbol information for debugging.
-
-
-File: as.info, Node: Linkonce, Next: List, Prev: Line, Up: Pseudo Ops
-
-7.70 `.linkonce [TYPE]'
-=======================
-
-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 `.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 TYPE argument is optional. If specified, it must be one of the
-following strings. For example:
- .linkonce same_size
- Not all types may be supported on all object file formats.
-
-`discard'
- Silently discard duplicate sections. This is the default.
-
-`one_only'
- Warn if there are duplicate sections, but still keep only one copy.
-
-`same_size'
- Warn if any of the duplicates have different sizes.
-
-`same_contents'
- Warn if any of the duplicates do not have exactly the same
- contents.
-
-
-File: as.info, Node: List, Next: Ln, Prev: Linkonce, Up: Pseudo Ops
-
-7.71 `.list'
-============
-
-Control (in conjunction with the `.nolist' directive) whether or not
-assembly listings are generated. These two directives maintain an
-internal counter (which is zero initially). `.list' increments the
-counter, and `.nolist' decrements it. Assembly listings are generated
-whenever the counter is greater than zero.
-
- By default, listings are disabled. When you enable them (with the
-`-a' command line option; *note Command-Line Options: Invoking.), the
-initial value of the listing counter is one.
-
-
-File: as.info, Node: Ln, Next: Loc, Prev: List, Up: Pseudo Ops
-
-7.72 `.ln LINE-NUMBER'
-======================
-
-`.ln' is a synonym for `.line'.
-
-
-File: as.info, Node: Loc, Next: Loc_mark_labels, Prev: Ln, Up: Pseudo Ops
-
-7.73 `.loc FILENO LINENO [COLUMN] [OPTIONS]'
-============================================
-
-When emitting DWARF2 line number information, the `.loc' directive will
-add a row to the `.debug_line' line number matrix corresponding to the
-immediately following assembly instruction. The FILENO, LINENO, and
-optional COLUMN arguments will be applied to the `.debug_line' state
-machine before the row is added.
-
- The OPTIONS are a sequence of the following tokens in any order:
-
-`basic_block'
- This option will set the `basic_block' register in the
- `.debug_line' state machine to `true'.
-
-`prologue_end'
- This option will set the `prologue_end' register in the
- `.debug_line' state machine to `true'.
-
-`epilogue_begin'
- This option will set the `epilogue_begin' register in the
- `.debug_line' state machine to `true'.
-
-`is_stmt VALUE'
- This option will set the `is_stmt' register in the `.debug_line'
- state machine to `value', which must be either 0 or 1.
-
-`isa VALUE'
- This directive will set the `isa' register in the `.debug_line'
- state machine to VALUE, which must be an unsigned integer.
-
-`discriminator VALUE'
- This directive will set the `discriminator' register in the
- `.debug_line' state machine to VALUE, which must be an unsigned
- integer.
-
-
-
-File: as.info, Node: Loc_mark_labels, Next: Local, Prev: Loc, Up: Pseudo Ops
-
-7.74 `.loc_mark_labels ENABLE'
-==============================
-
-When emitting DWARF2 line number information, the `.loc_mark_labels'
-directive makes the assembler emit an entry to the `.debug_line' line
-number matrix with the `basic_block' register in the state machine set
-whenever a code label is seen. The ENABLE argument should be either 1
-or 0, to enable or disable this function respectively.
-
-
-File: as.info, Node: Local, Next: Long, Prev: Loc_mark_labels, Up: Pseudo Ops
-
-7.75 `.local NAMES'
-===================
-
-This directive, which is available for ELF targets, marks each symbol in
-the comma-separated list of `names' as a local symbol so that it will
-not be externally visible. If the symbols do not already exist, they
-will be created.
-
- For targets where the `.lcomm' directive (*note Lcomm::) does not
-accept an alignment argument, which is the case for most ELF targets,
-the `.local' directive can be used in combination with `.comm' (*note
-Comm::) to define aligned local common data.
-
-
-File: as.info, Node: Long, Next: Macro, Prev: Local, Up: Pseudo Ops
-
-7.76 `.long EXPRESSIONS'
-========================
-
-`.long' is the same as `.int'. *Note `.int': Int.
-
-
-File: as.info, Node: Macro, Next: MRI, Prev: Long, Up: Pseudo Ops
-
-7.77 `.macro'
-=============
-
-The commands `.macro' and `.endm' allow you to define macros that
-generate assembly output. For example, this definition specifies a
-macro `sum' that puts a sequence of numbers into memory:
-
- .macro sum from=0, to=5
- .long \from
- .if \to-\from
- sum "(\from+1)",\to
- .endif
- .endm
-
-With that definition, `SUM 0,5' is equivalent to this assembly input:
-
- .long 0
- .long 1
- .long 2
- .long 3
- .long 4
- .long 5
-
-`.macro MACNAME'
-`.macro MACNAME MACARGS ...'
- Begin the definition of a macro called MACNAME. If your macro
- definition requires arguments, specify their names after the macro
- name, separated by commas or spaces. You can qualify the macro
- argument to indicate whether all invocations must specify a
- non-blank value (through `:`req''), or whether it takes all of the
- remaining arguments (through `:`vararg''). You can supply a
- default value for any macro argument by following the name with
- `=DEFLT'. You cannot define two macros with the same MACNAME
- unless it has been subject to the `.purgem' directive (*note
- Purgem::) between the two definitions. For example, these are all
- valid `.macro' statements:
-
- `.macro comm'
- Begin the definition of a macro called `comm', which takes no
- arguments.
-
- `.macro plus1 p, p1'
- `.macro plus1 p p1'
- Either statement begins the definition of a macro called
- `plus1', which takes two arguments; within the macro
- definition, write `\p' or `\p1' to evaluate the arguments.
-
- `.macro reserve_str p1=0 p2'
- Begin the definition of a macro called `reserve_str', with two
- arguments. The first argument has a default value, but not
- the second. After the definition is complete, you can call
- the macro either as `reserve_str A,B' (with `\p1' evaluating
- to A and `\p2' evaluating to B), or as `reserve_str ,B' (with
- `\p1' evaluating as the default, in this case `0', and `\p2'
- evaluating to B).
-
- `.macro m p1:req, p2=0, p3:vararg'
- Begin the definition of a macro called `m', with at least
- three arguments. The first argument must always have a value
- specified, but not the second, which instead has a default
- value. The third formal will get assigned all remaining
- arguments specified at invocation time.
-
- When you call a macro, you can specify the argument values
- either by position, or by keyword. For example, `sum 9,17'
- is equivalent to `sum to=17, from=9'.
-
-
- Note that since each of the MACARGS can be an identifier exactly
- as any other one permitted by the target architecture, there may be
- occasional problems if the target hand-crafts special meanings to
- certain characters when they occur in a special position. For
- example, if the colon (`:') is generally permitted to be part of a
- symbol name, but the architecture specific code special-cases it
- when occurring as the final character of a symbol (to denote a
- label), then the macro parameter replacement code will have no way
- of knowing that and consider the whole construct (including the
- colon) an identifier, and check only this identifier for being the
- subject to parameter substitution. So for example this macro
- definition:
-
- .macro label l
- \l:
- .endm
-
- might not work as expected. Invoking `label foo' might not create
- a label called `foo' but instead just insert the text `\l:' into
- the assembler source, probably generating an error about an
- unrecognised identifier.
-
- Similarly problems might occur with the period character (`.')
- which is often allowed inside opcode names (and hence identifier
- names). So for example constructing a macro to build an opcode
- from a base name and a length specifier like this:
-
- .macro opcode base length
- \base.\length
- .endm
-
- and invoking it as `opcode store l' will not create a `store.l'
- instruction but instead generate some kind of error as the
- assembler tries to interpret the text `\base.\length'.
-
- There are several possible ways around this problem:
-
- `Insert white space'
- If it is possible to use white space characters then this is
- the simplest solution. eg:
-
- .macro label l
- \l :
- .endm
-
- `Use `\()''
- The string `\()' can be used to separate the end of a macro
- argument from the following text. eg:
-
- .macro opcode base length
- \base\().\length
- .endm
-
- `Use the alternate macro syntax mode'
- In the alternative macro syntax mode the ampersand character
- (`&') can be used as a separator. eg:
-
- .altmacro
- .macro label l
- l&:
- .endm
-
- Note: this problem of correctly identifying string parameters to
- pseudo ops also applies to the identifiers used in `.irp' (*note
- Irp::) and `.irpc' (*note Irpc::) as well.
-
-`.endm'
- Mark the end of a macro definition.
-
-`.exitm'
- Exit early from the current macro definition.
-
-`\@'
- `as' maintains a counter of how many macros it has executed in
- this pseudo-variable; you can copy that number to your output with
- `\@', but _only within a macro definition_.
-
-`LOCAL NAME [ , ... ]'
- _Warning: `LOCAL' is only available if you select "alternate macro
- syntax" with `--alternate' or `.altmacro'._ *Note `.altmacro':
- Altmacro.
-
-
-File: as.info, Node: MRI, Next: Noaltmacro, Prev: Macro, Up: Pseudo Ops
-
-7.78 `.mri VAL'
-===============
-
-If VAL is non-zero, this tells `as' to enter MRI mode. If VAL is zero,
-this tells `as' to exit MRI mode. This change affects code assembled
-until the next `.mri' directive, or until the end of the file. *Note
-MRI mode: M.
-
-
-File: as.info, Node: Noaltmacro, Next: Nolist, Prev: MRI, Up: Pseudo Ops
-
-7.79 `.noaltmacro'
-==================
-
-Disable alternate macro mode. *Note Altmacro::.
-
-
-File: as.info, Node: Nolist, Next: Octa, Prev: Noaltmacro, Up: Pseudo Ops
-
-7.80 `.nolist'
-==============
-
-Control (in conjunction with the `.list' directive) whether or not
-assembly listings are generated. These two directives maintain an
-internal counter (which is zero initially). `.list' increments the
-counter, and `.nolist' decrements it. Assembly listings are generated
-whenever the counter is greater than zero.
-
-
-File: as.info, Node: Octa, Next: Org, Prev: Nolist, Up: Pseudo Ops
-
-7.81 `.octa BIGNUMS'
-====================
-
-This directive expects zero or more bignums, separated by commas. For
-each bignum, it emits a 16-byte integer.
-
- The term "octa" comes from contexts in which a "word" is two bytes;
-hence _octa_-word for 16 bytes.
-
-
-File: as.info, Node: Org, Next: P2align, Prev: Octa, Up: Pseudo Ops
-
-7.82 `.org NEW-LC , FILL'
-=========================
-
-Advance the location counter of the current section to NEW-LC. NEW-LC
-is either an absolute expression or an expression with the same section
-as the current subsection. That is, you can't use `.org' to cross
-sections: if NEW-LC has the wrong section, the `.org' directive is
-ignored. To be compatible with former assemblers, if the section of
-NEW-LC is absolute, `as' issues a warning, then pretends the section of
-NEW-LC is the same as the current subsection.
-
- `.org' may only increase the location counter, or leave it
-unchanged; you cannot use `.org' to move the location counter backwards.
-
- Because `as' tries to assemble programs in one pass, NEW-LC may not
-be undefined. If you really detest this restriction we eagerly await a
-chance to share your improved assembler.
-
- Beware that the origin is relative to the start of the section, not
-to the start of the subsection. This is compatible with other people's
-assemblers.
-
- When the location counter (of the current subsection) is advanced,
-the intervening bytes are filled with FILL which should be an absolute
-expression. If the comma and FILL are omitted, FILL defaults to zero.
-
-
-File: as.info, Node: P2align, Next: PopSection, Prev: Org, Up: Pseudo Ops
-
-7.83 `.p2align[wl] ABS-EXPR, ABS-EXPR, ABS-EXPR'
-================================================
-
-Pad the location counter (in the current subsection) to a particular
-storage boundary. The first expression (which must be absolute) is the
-number of low-order zero bits the location counter must have after
-advancement. For example `.p2align 3' advances the location counter
-until it a multiple of 8. If the location counter is already a
-multiple of 8, no change is needed.
-
- The second expression (also absolute) gives the fill value to be
-stored in the padding bytes. It (and the comma) may be omitted. If it
-is omitted, the padding bytes are normally zero. However, on some
-systems, if the section is marked as containing code and the fill value
-is omitted, the space is filled with no-op instructions.
-
- The third expression is also absolute, and is also optional. If it
-is present, it is the maximum number of bytes that should be skipped by
-this alignment directive. If doing the alignment would require
-skipping more bytes than the specified maximum, then the alignment is
-not done at all. You can omit the fill value (the second argument)
-entirely by simply using two commas after the required alignment; this
-can be useful if you want the alignment to be filled with no-op
-instructions when appropriate.
-
- The `.p2alignw' and `.p2alignl' directives are variants of the
-`.p2align' directive. The `.p2alignw' directive treats the fill
-pattern as a two byte word value. The `.p2alignl' directives treats the
-fill pattern as a four byte longword value. For example, `.p2alignw
-2,0x368d' will align to a multiple of 4. If it skips two bytes, they
-will be filled in with the value 0x368d (the exact placement of the
-bytes depends upon the endianness of the processor). If it skips 1 or
-3 bytes, the fill value is undefined.
-
-
-File: as.info, Node: PopSection, Next: Previous, Prev: P2align, Up: Pseudo Ops
-
-7.84 `.popsection'
-==================
-
-This is one of the ELF section stack manipulation directives. The
-others are `.section' (*note Section::), `.subsection' (*note
-SubSection::), `.pushsection' (*note PushSection::), and `.previous'
-(*note Previous::).
-
- This directive replaces the current section (and subsection) with
-the top section (and subsection) on the section stack. This section is
-popped off the stack.
-
-
-File: as.info, Node: Previous, Next: Print, Prev: PopSection, Up: Pseudo Ops
-
-7.85 `.previous'
-================
-
-This is one of the ELF section stack manipulation directives. The
-others are `.section' (*note Section::), `.subsection' (*note
-SubSection::), `.pushsection' (*note PushSection::), and `.popsection'
-(*note PopSection::).
-
- This directive swaps the current section (and subsection) with most
-recently referenced section/subsection pair prior to this one. Multiple
-`.previous' directives in a row will flip between two sections (and
-their subsections). For example:
-
- .section A
- .subsection 1
- .word 0x1234
- .subsection 2
- .word 0x5678
- .previous
- .word 0x9abc
-
- Will place 0x1234 and 0x9abc into subsection 1 and 0x5678 into
-subsection 2 of section A. Whilst:
-
- .section A
- .subsection 1
- # Now in section A subsection 1
- .word 0x1234
- .section B
- .subsection 0
- # Now in section B subsection 0
- .word 0x5678
- .subsection 1
- # Now in section B subsection 1
- .word 0x9abc
- .previous
- # Now in section B subsection 0
- .word 0xdef0
-
- Will place 0x1234 into section A, 0x5678 and 0xdef0 into subsection
-0 of section B and 0x9abc into subsection 1 of section B.
-
- In terms of the section stack, this directive swaps the current
-section with the top section on the section stack.
-
-
-File: as.info, Node: Print, Next: Protected, Prev: Previous, Up: Pseudo Ops
-
-7.86 `.print STRING'
-====================
-
-`as' will print STRING on the standard output during assembly. You
-must put STRING in double quotes.
-
-
-File: as.info, Node: Protected, Next: Psize, Prev: Print, Up: Pseudo Ops
-
-7.87 `.protected NAMES'
-=======================
-
-This is one of the ELF visibility directives. The other two are
-`.hidden' (*note Hidden::) and `.internal' (*note Internal::).
-
- This directive overrides the named symbols default visibility (which
-is set by their binding: local, global or weak). The directive sets
-the visibility to `protected' which means that any references to the
-symbols from within the components that defines them must be resolved
-to the definition in that component, even if a definition in another
-component would normally preempt this.
-
-
-File: as.info, Node: Psize, Next: Purgem, Prev: Protected, Up: Pseudo Ops
-
-7.88 `.psize LINES , COLUMNS'
-=============================
-
-Use this directive to declare the number of lines--and, optionally, the
-number of columns--to use for each page, when generating listings.
-
- If you do not use `.psize', listings use a default line-count of 60.
-You may omit the comma and COLUMNS specification; the default width is
-200 columns.
-
- `as' generates formfeeds whenever the specified number of lines is
-exceeded (or whenever you explicitly request one, using `.eject').
-
- If you specify LINES as `0', no formfeeds are generated save those
-explicitly specified with `.eject'.
-
-
-File: as.info, Node: Purgem, Next: PushSection, Prev: Psize, Up: Pseudo Ops
-
-7.89 `.purgem NAME'
-===================
-
-Undefine the macro NAME, so that later uses of the string will not be
-expanded. *Note Macro::.
-
-
-File: as.info, Node: PushSection, Next: Quad, Prev: Purgem, Up: Pseudo Ops
-
-7.90 `.pushsection NAME [, SUBSECTION] [, "FLAGS"[, @TYPE[,ARGUMENTS]]]'
-========================================================================
-
-This is one of the ELF section stack manipulation directives. The
-others are `.section' (*note Section::), `.subsection' (*note
-SubSection::), `.popsection' (*note PopSection::), and `.previous'
-(*note Previous::).
-
- This directive pushes the current section (and subsection) onto the
-top of the section stack, and then replaces the current section and
-subsection with `name' and `subsection'. The optional `flags', `type'
-and `arguments' are treated the same as in the `.section' (*note
-Section::) directive.
-
-
-File: as.info, Node: Quad, Next: Reloc, Prev: PushSection, Up: Pseudo Ops
-
-7.91 `.quad BIGNUMS'
-====================
-
-`.quad' expects zero or more bignums, separated by commas. For each
-bignum, it emits an 8-byte integer. If the bignum won't fit in 8
-bytes, it prints a warning message; and just takes the lowest order 8
-bytes of the bignum.
-
- The term "quad" comes from contexts in which a "word" is two bytes;
-hence _quad_-word for 8 bytes.
-
-
-File: as.info, Node: Reloc, Next: Rept, Prev: Quad, Up: Pseudo Ops
-
-7.92 `.reloc OFFSET, RELOC_NAME[, EXPRESSION]'
-==============================================
-
-Generate a relocation at OFFSET of type RELOC_NAME with value
-EXPRESSION. If OFFSET is a number, the relocation is generated in the
-current section. If OFFSET is an expression that resolves to a symbol
-plus offset, the relocation is generated in the given symbol's section.
-EXPRESSION, if present, must resolve to a symbol plus addend or to an
-absolute value, but note that not all targets support an addend. e.g.
-ELF REL targets such as i386 store an addend in the section contents
-rather than in the relocation. This low level interface does not
-support addends stored in the section.
-
-
-File: as.info, Node: Rept, Next: Sbttl, Prev: Reloc, Up: Pseudo Ops
-
-7.93 `.rept COUNT'
-==================
-
-Repeat the sequence of lines between the `.rept' directive and the next
-`.endr' directive COUNT times.
-
- For example, assembling
-
- .rept 3
- .long 0
- .endr
-
- is equivalent to assembling
-
- .long 0
- .long 0
- .long 0
-
-
-File: as.info, Node: Sbttl, Next: Scl, Prev: Rept, Up: Pseudo Ops
-
-7.94 `.sbttl "SUBHEADING"'
-==========================
-
-Use SUBHEADING as the title (third line, immediately after the title
-line) when generating assembly listings.
-
- This directive affects subsequent pages, as well as the current page
-if it appears within ten lines of the top of a page.
-
-
-File: as.info, Node: Scl, Next: Section, Prev: Sbttl, Up: Pseudo Ops
-
-7.95 `.scl CLASS'
-=================
-
-Set the storage-class value for a symbol. This directive may only be
-used inside a `.def'/`.endef' pair. Storage class may flag whether a
-symbol is static or external, or it may record further symbolic
-debugging information.
-
-
-File: as.info, Node: Section, Next: Set, Prev: Scl, Up: Pseudo Ops
-
-7.96 `.section NAME'
-====================
-
-Use the `.section' directive to assemble the following code into a
-section named NAME.
-
- This directive is only supported for targets that actually support
-arbitrarily named sections; on `a.out' targets, for example, it is not
-accepted, even with a standard `a.out' section name.
-
-COFF Version
-------------
-
- For COFF targets, the `.section' directive is used in one of the
-following ways:
-
- .section NAME[, "FLAGS"]
- .section NAME[, SUBSECTION]
-
- 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:
-`b'
- bss section (uninitialized data)
-
-`n'
- section is not loaded
-
-`w'
- writable section
-
-`d'
- data section
-
-`r'
- read-only section
-
-`x'
- executable section
-
-`s'
- shared section (meaningful for PE targets)
-
-`a'
- ignored. (For compatibility with the ELF version)
-
-`y'
- section is not readable (meaningful for PE targets)
-
-`0-9'
- single-digit power-of-two section alignment (GNU extension)
-
- 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. Note the `n' and `w' flags
-remove attributes from the section, rather than adding them, so if they
-are used on their own it will be as if no flags had been specified at
-all.
-
- If the optional argument to the `.section' directive is not quoted,
-it is taken as a subsection number (*note Sub-Sections::).
-
-ELF Version
------------
-
- This is one of the ELF section stack manipulation directives. The
-others are `.subsection' (*note SubSection::), `.pushsection' (*note
-PushSection::), `.popsection' (*note PopSection::), and `.previous'
-(*note Previous::).
-
- For ELF targets, the `.section' directive is used like this:
-
- .section NAME [, "FLAGS"[, @TYPE[,FLAG_SPECIFIC_ARGUMENTS]]]
-
- The optional FLAGS argument is a quoted string which may contain any
-combination of the following characters:
-`a'
- section is allocatable
-
-`e'
- section is excluded from executable and shared library.
-
-`w'
- section is writable
-
-`x'
- section is executable
-
-`M'
- section is mergeable
-
-`S'
- section contains zero terminated strings
-
-`G'
- section is a member of a section group
-
-`T'
- section is used for thread-local-storage
-
-`?'
- section is a member of the previously-current section's group, if
- any
-
- The optional TYPE argument may contain one of the following
-constants:
-`@progbits'
- section contains data
-
-`@nobits'
- section does not contain data (i.e., section only occupies space)
-
-`@note'
- section contains data which is used by things other than the
- program
-
-`@init_array'
- section contains an array of pointers to init functions
-
-`@fini_array'
- section contains an array of pointers to finish functions
-
-`@preinit_array'
- section contains an array of pointers to pre-init functions
-
- Many targets only support the first three section types.
-
- Note on targets where the `@' character is the start of a comment (eg
-ARM) then another character is used instead. For example the ARM port
-uses the `%' character.
-
- If FLAGS contains the `M' symbol then the TYPE argument must be
-specified as well as an extra argument--ENTSIZE--like this:
-
- .section NAME , "FLAGS"M, @TYPE, ENTSIZE
-
- Sections with the `M' flag but not `S' flag must contain fixed size
-constants, each ENTSIZE octets long. Sections with both `M' and `S'
-must contain zero terminated strings where each character is ENTSIZE
-bytes long. The linker may remove duplicates within sections with the
-same name, same entity size and same flags. ENTSIZE must be an
-absolute expression. For sections with both `M' and `S', a string
-which is a suffix of a larger string is considered a duplicate. Thus
-`"def"' will be merged with `"abcdef"'; A reference to the first
-`"def"' will be changed to a reference to `"abcdef"+3'.
-
- If FLAGS contains the `G' symbol then the TYPE argument must be
-present along with an additional field like this:
-
- .section NAME , "FLAGS"G, @TYPE, GROUPNAME[, LINKAGE]
-
- The GROUPNAME field specifies the name of the section group to which
-this particular section belongs. The optional linkage field can
-contain:
-`comdat'
- indicates that only one copy of this section should be retained
-
-`.gnu.linkonce'
- an alias for comdat
-
- Note: if both the M and G flags are present then the fields for the
-Merge flag should come first, like this:
-
- .section NAME , "FLAGS"MG, @TYPE, ENTSIZE, GROUPNAME[, LINKAGE]
-
- If FLAGS contains the `?' symbol then it may not also contain the
-`G' symbol and the GROUPNAME or LINKAGE fields should not be present.
-Instead, `?' says to consider the section that's current before this
-directive. If that section used `G', then the new section will use `G'
-with those same GROUPNAME and LINKAGE fields implicitly. If not, then
-the `?' symbol has no effect.
-
- 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 `.section'
-directive for compatibility with the Solaris assembler:
-
- .section "NAME"[, FLAGS...]
-
- Note that the section name is quoted. There may be a sequence of
-comma separated flags:
-`#alloc'
- section is allocatable
-
-`#write'
- section is writable
-
-`#execinstr'
- section is executable
-
-`#exclude'
- section is excluded from executable and shared library.
-
-`#tls'
- section is used for thread local storage
-
- This directive replaces the current section and subsection. See the
-contents of the gas testsuite directory `gas/testsuite/gas/elf' for
-some examples of how this directive and the other section stack
-directives work.
-
-
-File: as.info, Node: Set, Next: Short, Prev: Section, Up: Pseudo Ops
-
-7.97 `.set SYMBOL, EXPRESSION'
-==============================
-
-Set the value of SYMBOL to EXPRESSION. This changes SYMBOL's value and
-type to conform to EXPRESSION. If SYMBOL was flagged as external, it
-remains flagged (*note Symbol Attributes::).
-
- You may `.set' a symbol many times in the same assembly.
-
- If you `.set' a global symbol, the value stored in the object file
-is the last value stored into it.
-
- On Z80 `set' is a real instruction, use `SYMBOL defl EXPRESSION'
-instead.
-
-
-File: as.info, Node: Short, Next: Single, Prev: Set, Up: Pseudo Ops
-
-7.98 `.short EXPRESSIONS'
-=========================
-
-`.short' is normally the same as `.word'. *Note `.word': Word.
-
- In some configurations, however, `.short' and `.word' generate
-numbers of different lengths. *Note Machine Dependencies::.
-
-
-File: as.info, Node: Single, Next: Size, Prev: Short, Up: Pseudo Ops
-
-7.99 `.single FLONUMS'
-======================
-
-This directive assembles zero or more flonums, separated by commas. It
-has the same effect as `.float'. The exact kind of floating point
-numbers emitted depends on how `as' is configured. *Note Machine
-Dependencies::.
-
-
-File: as.info, Node: Size, Next: Skip, Prev: Single, Up: Pseudo Ops
-
-7.100 `.size'
-=============
-
-This directive is used to set the size associated with a symbol.
-
-COFF Version
-------------
-
- For COFF targets, the `.size' directive is only permitted inside
-`.def'/`.endef' pairs. It is used like this:
-
- .size EXPRESSION
-
-ELF Version
------------
-
- For ELF targets, the `.size' directive is used like this:
-
- .size NAME , EXPRESSION
-
- This directive sets the size associated with a symbol NAME. The
-size in bytes is computed from EXPRESSION which can make use of label
-arithmetic. This directive is typically used to set the size of
-function symbols.
-
-
-File: as.info, Node: Skip, Next: Sleb128, Prev: Size, Up: Pseudo Ops
-
-7.101 `.skip SIZE , FILL'
-=========================
-
-This directive emits SIZE bytes, each of value FILL. Both SIZE and
-FILL are absolute expressions. If the comma and FILL are omitted, FILL
-is assumed to be zero. This is the same as `.space'.
-
-
-File: as.info, Node: Sleb128, Next: Space, Prev: Skip, Up: Pseudo Ops
-
-7.102 `.sleb128 EXPRESSIONS'
-============================
-
-SLEB128 stands for "signed little endian base 128." This is a compact,
-variable length representation of numbers used by the DWARF symbolic
-debugging format. *Note `.uleb128': Uleb128.
-
-
-File: as.info, Node: Space, Next: Stab, Prev: Sleb128, Up: Pseudo Ops
-
-7.103 `.space SIZE , FILL'
-==========================
-
-This directive emits SIZE bytes, each of value FILL. Both SIZE and
-FILL are absolute expressions. If the comma and FILL are omitted, FILL
-is assumed to be zero. This is the same as `.skip'.
-
- _Warning:_ `.space' has a completely different meaning for HPPA
- targets; use `.block' as a substitute. See `HP9000 Series 800
- Assembly Language Reference Manual' (HP 92432-90001) for the
- meaning of the `.space' directive. *Note HPPA Assembler
- Directives: HPPA Directives, for a summary.
-
-
-File: as.info, Node: Stab, Next: String, Prev: Space, Up: Pseudo Ops
-
-7.104 `.stabd, .stabn, .stabs'
-==============================
-
-There are three directives that begin `.stab'. All emit symbols (*note
-Symbols::), for use by symbolic debuggers. The symbols are not entered
-in the `as' hash table: they cannot be referenced elsewhere in the
-source file. Up to five fields are required:
-
-STRING
- This is the symbol's name. It may contain any character except
- `\000', so is more general than ordinary symbol names. Some
- debuggers used to code arbitrarily complex structures into symbol
- names using this field.
-
-TYPE
- An absolute expression. The symbol's type is set to the low 8
- bits of this expression. Any bit pattern is permitted, but `ld'
- and debuggers choke on silly bit patterns.
-
-OTHER
- An absolute expression. The symbol's "other" attribute is set to
- the low 8 bits of this expression.
-
-DESC
- An absolute expression. The symbol's descriptor is set to the low
- 16 bits of this expression.
-
-VALUE
- An absolute expression which becomes the symbol's value.
-
- If a warning is detected while reading a `.stabd', `.stabn', or
-`.stabs' statement, the symbol has probably already been created; you
-get a half-formed symbol in your object file. This is compatible with
-earlier assemblers!
-
-`.stabd TYPE , OTHER , DESC'
- The "name" of the symbol generated is not even an empty string.
- It is a null pointer, for compatibility. Older assemblers used a
- null pointer so they didn't waste space in object files with empty
- strings.
-
- The symbol's value is set to the location counter, relocatably.
- When your program is linked, the value of this symbol is the
- address of the location counter when the `.stabd' was assembled.
-
-`.stabn TYPE , OTHER , DESC , VALUE'
- The name of the symbol is set to the empty string `""'.
-
-`.stabs STRING , TYPE , OTHER , DESC , VALUE'
- All five fields are specified.
-
-
-File: as.info, Node: String, Next: Struct, Prev: Stab, Up: Pseudo Ops
-
-7.105 `.string' "STR", `.string8' "STR", `.string16'
-====================================================
-
-"STR", `.string32' "STR", `.string64' "STR"
-
- Copy the characters in STR to the object file. You may specify more
-than one string to copy, separated by commas. Unless otherwise
-specified for a particular machine, the assembler marks the end of each
-string with a 0 byte. You can use any of the escape sequences
-described in *note Strings: Strings.
-
- The variants `string16', `string32' and `string64' differ from the
-`string' pseudo opcode in that each 8-bit character from STR is copied
-and expanded to 16, 32 or 64 bits respectively. The expanded characters
-are stored in target endianness byte order.
-
- Example:
- .string32 "BYE"
- expands to:
- .string "B\0\0\0Y\0\0\0E\0\0\0" /* On little endian targets. */
- .string "\0\0\0B\0\0\0Y\0\0\0E" /* On big endian targets. */
-
-
-File: as.info, Node: Struct, Next: SubSection, Prev: String, Up: Pseudo Ops
-
-7.106 `.struct EXPRESSION'
-==========================
-
-Switch to the absolute section, and set the section offset to
-EXPRESSION, which must be an absolute expression. You might use this
-as follows:
- .struct 0
- field1:
- .struct field1 + 4
- field2:
- .struct field2 + 4
- field3:
- This would define the symbol `field1' to have the value 0, the symbol
-`field2' to have the value 4, and the symbol `field3' to have the value
-8. Assembly would be left in the absolute section, and you would need
-to use a `.section' directive of some sort to change to some other
-section before further assembly.
-
-
-File: as.info, Node: SubSection, Next: Symver, Prev: Struct, Up: Pseudo Ops
-
-7.107 `.subsection NAME'
-========================
-
-This is one of the ELF section stack manipulation directives. The
-others are `.section' (*note Section::), `.pushsection' (*note
-PushSection::), `.popsection' (*note PopSection::), and `.previous'
-(*note Previous::).
-
- This directive replaces the current subsection with `name'. The
-current section is not changed. The replaced subsection is put onto
-the section stack in place of the then current top of stack subsection.
-
-
-File: as.info, Node: Symver, Next: Tag, Prev: SubSection, Up: Pseudo Ops
-
-7.108 `.symver'
-===============
-
-Use the `.symver' directive to bind symbols to specific version nodes
-within a source file. This is only supported on ELF platforms, and is
-typically used when assembling files to be linked into a shared library.
-There are cases where it may make sense to use this in objects to be
-bound into an application itself so as to override a versioned symbol
-from a shared library.
-
- For ELF targets, the `.symver' directive can be used like this:
- .symver NAME, NAME2@NODENAME
- If the symbol NAME is defined within the file being assembled, the
-`.symver' directive effectively creates a symbol alias with the name
-NAME2@NODENAME, and in fact the main reason that we just don't try and
-create a regular alias is that the @ character isn't permitted in
-symbol names. The NAME2 part of the name is the actual name of the
-symbol by which it will be externally referenced. The name NAME itself
-is merely a name of convenience that is used so that it is possible to
-have definitions for multiple versions of a function within a single
-source file, and so that the compiler can unambiguously know which
-version of a function is being mentioned. The NODENAME portion of the
-alias should be the name of a node specified in the version script
-supplied to the linker when building a shared library. If you are
-attempting to override a versioned symbol from a shared library, then
-NODENAME should correspond to the nodename of the symbol you are trying
-to override.
-
- If the symbol NAME is not defined within the file being assembled,
-all references to NAME will be changed to NAME2@NODENAME. If no
-reference to NAME is made, NAME2@NODENAME will be removed from the
-symbol table.
-
- Another usage of the `.symver' directive is:
- .symver NAME, NAME2@@NODENAME
- In this case, the symbol NAME must exist and be defined within the
-file being assembled. It is similar to NAME2@NODENAME. The difference
-is NAME2@@NODENAME will also be used to resolve references to NAME2 by
-the linker.
-
- The third usage of the `.symver' directive is:
- .symver NAME, NAME2@@@NODENAME
- When NAME is not defined within the file being assembled, it is
-treated as NAME2@NODENAME. When NAME is defined within the file being
-assembled, the symbol name, NAME, will be changed to NAME2@@NODENAME.
-
-
-File: as.info, Node: Tag, Next: Text, Prev: Symver, Up: Pseudo Ops
-
-7.109 `.tag STRUCTNAME'
-=======================
-
-This directive is generated by compilers to include auxiliary debugging
-information in the symbol table. It is only permitted inside
-`.def'/`.endef' pairs. Tags are used to link structure definitions in
-the symbol table with instances of those structures.
-
-
-File: as.info, Node: Text, Next: Title, Prev: Tag, Up: Pseudo Ops
-
-7.110 `.text SUBSECTION'
-========================
-
-Tells `as' to assemble the following statements onto the end of the
-text subsection numbered SUBSECTION, which is an absolute expression.
-If SUBSECTION is omitted, subsection number zero is used.
-
-
-File: as.info, Node: Title, Next: Type, Prev: Text, Up: Pseudo Ops
-
-7.111 `.title "HEADING"'
-========================
-
-Use HEADING as the title (second line, immediately after the source
-file name and pagenumber) when generating assembly listings.
-
- This directive affects subsequent pages, as well as the current page
-if it appears within ten lines of the top of a page.
-
-
-File: as.info, Node: Type, Next: Uleb128, Prev: Title, Up: Pseudo Ops
-
-7.112 `.type'
-=============
-
-This directive is used to set the type of a symbol.
-
-COFF Version
-------------
-
- For COFF targets, this directive is permitted only within
-`.def'/`.endef' pairs. It is used like this:
-
- .type INT
-
- This records the integer INT as the type attribute of a symbol table
-entry.
-
-ELF Version
------------
-
- For ELF targets, the `.type' directive is used like this:
-
- .type NAME , TYPE DESCRIPTION
-
- This sets the type of symbol NAME to be either a function symbol or
-an object symbol. There are five different syntaxes supported for the
-TYPE DESCRIPTION field, in order to provide compatibility with various
-other assemblers.
-
- Because some of the characters used in these syntaxes (such as `@'
-and `#') are comment characters for some architectures, some of the
-syntaxes below do not work on all architectures. The first variant
-will be accepted by the GNU assembler on all architectures so that
-variant should be used for maximum portability, if you do not need to
-assemble your code with other assemblers.
-
- The syntaxes supported are:
-
- .type <name> STT_<TYPE_IN_UPPER_CASE>
- .type <name>,#<type>
- .type <name>,@<type>
- .type <name>,%<type>
- .type <name>,"<type>"
-
- The types supported are:
-
-`STT_FUNC'
-`function'
- Mark the symbol as being a function name.
-
-`STT_GNU_IFUNC'
-`gnu_indirect_function'
- Mark the symbol as an indirect function when evaluated during reloc
- processing. (This is only supported on Linux targeted assemblers).
-
-`STT_OBJECT'
-`object'
- Mark the symbol as being a data object.
-
-`STT_TLS'
-`tls_object'
- Mark the symbol as being a thead-local data object.
-
-`STT_COMMON'
-`common'
- Mark the symbol as being a common data object.
-
-`STT_NOTYPE'
-`notype'
- Does not mark the symbol in any way. It is supported just for
- completeness.
-
-`gnu_unique_object'
- Marks the symbol as being a globally unique data object. The
- dynamic linker will make sure that in the entire process there is
- just one symbol with this name and type in use. (This is only
- supported on Linux targeted assemblers).
-
-
- Note: Some targets support extra types in addition to those listed
-above.
-
-
-File: as.info, Node: Uleb128, Next: Val, Prev: Type, Up: Pseudo Ops
-
-7.113 `.uleb128 EXPRESSIONS'
-============================
-
-ULEB128 stands for "unsigned little endian base 128." This is a
-compact, variable length representation of numbers used by the DWARF
-symbolic debugging format. *Note `.sleb128': Sleb128.
-
-
-File: as.info, Node: Val, Next: Version, Prev: Uleb128, Up: Pseudo Ops
-
-7.114 `.val ADDR'
-=================
-
-This directive, permitted only within `.def'/`.endef' pairs, records
-the address ADDR as the value attribute of a symbol table entry.
-
-
-File: as.info, Node: Version, Next: VTableEntry, Prev: Val, Up: Pseudo Ops
-
-7.115 `.version "STRING"'
-=========================
-
-This directive creates a `.note' section and places into it an ELF
-formatted note of type NT_VERSION. The note's name is set to `string'.
-
-
-File: as.info, Node: VTableEntry, Next: VTableInherit, Prev: Version, Up: Pseudo Ops
-
-7.116 `.vtable_entry TABLE, OFFSET'
-===================================
-
-This directive finds or creates a symbol `table' and creates a
-`VTABLE_ENTRY' relocation for it with an addend of `offset'.
-
-
-File: as.info, Node: VTableInherit, Next: Warning, Prev: VTableEntry, Up: Pseudo Ops
-
-7.117 `.vtable_inherit CHILD, PARENT'
-=====================================
-
-This directive finds the symbol `child' and finds or creates the symbol
-`parent' and then creates a `VTABLE_INHERIT' relocation for the parent
-whose addend is the value of the child symbol. As a special case the
-parent name of `0' is treated as referring to the `*ABS*' section.
-
-
-File: as.info, Node: Warning, Next: Weak, Prev: VTableInherit, Up: Pseudo Ops
-
-7.118 `.warning "STRING"'
-=========================
-
-Similar to the directive `.error' (*note `.error "STRING"': Error.),
-but just emits a warning.
-
-
-File: as.info, Node: Weak, Next: Weakref, Prev: Warning, Up: Pseudo Ops
-
-7.119 `.weak NAMES'
-===================
-
-This directive sets the weak attribute on the comma separated list of
-symbol `names'. If the symbols do not already exist, they will be
-created.
-
- On COFF targets other than PE, weak symbols are a GNU extension.
-This directive sets the weak attribute on the comma separated list of
-symbol `names'. If the symbols do not already exist, they will be
-created.
-
- On the PE target, weak symbols are supported natively as weak
-aliases. When a weak symbol is created that is not an alias, GAS
-creates an alternate symbol to hold the default value.
-
-
-File: as.info, Node: Weakref, Next: Word, Prev: Weak, Up: Pseudo Ops
-
-7.120 `.weakref ALIAS, TARGET'
-==============================
-
-This directive creates an alias to the target symbol that enables the
-symbol to be referenced with weak-symbol semantics, but without
-actually making it weak. If direct references or definitions of the
-symbol are present, then the symbol will not be weak, but if all
-references to it are through weak references, the symbol will be marked
-as weak in the symbol table.
-
- The effect is equivalent to moving all references to the alias to a
-separate assembly source file, renaming the alias to the symbol in it,
-declaring the symbol as weak there, and running a reloadable link to
-merge the object files resulting from the assembly of the new source
-file and the old source file that had the references to the alias
-removed.
-
- The alias itself never makes to the symbol table, and is entirely
-handled within the assembler.
-
-
-File: as.info, Node: Word, Next: Deprecated, Prev: Weakref, Up: Pseudo Ops
-
-7.121 `.word EXPRESSIONS'
-=========================
-
-This directive expects zero or more EXPRESSIONS, of any section,
-separated by commas.
-
- The size of the number emitted, and its byte order, depend on what
-target computer the assembly is for.
-
- _Warning: Special Treatment to support Compilers_
-
- Machines with a 32-bit address space, but that do less than 32-bit
-addressing, require the following special treatment. If the machine of
-interest to you does 32-bit addressing (or doesn't require it; *note
-Machine Dependencies::), you can ignore this issue.
-
- In order to assemble compiler output into something that works, `as'
-occasionally does strange things to `.word' directives. Directives of
-the form `.word sym1-sym2' are often emitted by compilers as part of
-jump tables. Therefore, when `as' assembles a directive of the form
-`.word sym1-sym2', and the difference between `sym1' and `sym2' does
-not fit in 16 bits, `as' creates a "secondary jump table", immediately
-before the next label. This secondary jump table is preceded by a
-short-jump to the first byte after the secondary table. This
-short-jump prevents the flow of control from accidentally falling into
-the new table. Inside the table is a long-jump to `sym2'. The
-original `.word' contains `sym1' minus the address of the long-jump to
-`sym2'.
-
- If there were several occurrences of `.word sym1-sym2' before the
-secondary jump table, all of them are adjusted. If there was a `.word
-sym3-sym4', that also did not fit in sixteen bits, a long-jump to
-`sym4' is included in the secondary jump table, and the `.word'
-directives are adjusted to contain `sym3' minus the address of the
-long-jump to `sym4'; and so on, for as many entries in the original
-jump table as necessary.
-
-
-File: as.info, Node: Deprecated, Prev: Word, Up: Pseudo Ops
-
-7.122 Deprecated Directives
-===========================
-
-One day these directives won't work. They are included for
-compatibility with older assemblers.
-.abort
-
-.line
-
-
-File: as.info, Node: Object Attributes, Next: Machine Dependencies, Prev: Pseudo Ops, Up: Top
-
-8 Object Attributes
-*******************
-
-`as' assembles source files written for a specific architecture into
-object files for that architecture. But not all object files are alike.
-Many architectures support incompatible variations. For instance,
-floating point arguments might be passed in floating point registers if
-the object file requires hardware floating point support--or floating
-point arguments might be passed in integer registers if the object file
-supports processors with no hardware floating point unit. Or, if two
-objects are built for different generations of the same architecture,
-the combination may require the newer generation at run-time.
-
- This information is useful during and after linking. At link time,
-`ld' can warn about incompatible object files. After link time, tools
-like `gdb' can use it to process the linked file correctly.
-
- Compatibility information is recorded as a series of object
-attributes. Each attribute has a "vendor", "tag", and "value". The
-vendor is a string, and indicates who sets the meaning of the tag. The
-tag is an integer, and indicates what property the attribute describes.
-The value may be a string or an integer, and indicates how the property
-affects this object. Missing attributes are the same as attributes
-with a zero value or empty string value.
-
- Object attributes were developed as part of the ABI for the ARM
-Architecture. The file format is documented in `ELF for the ARM
-Architecture'.
-
-* Menu:
-
-* GNU Object Attributes:: GNU Object Attributes
-* Defining New Object Attributes:: Defining New Object Attributes
-
-
-File: as.info, Node: GNU Object Attributes, Next: Defining New Object Attributes, Up: Object Attributes
-
-8.1 GNU Object Attributes
-=========================
-
-The `.gnu_attribute' directive records an object attribute with vendor
-`gnu'.
-
- Except for `Tag_compatibility', which has both an integer and a
-string for its value, GNU attributes have a string value if the tag
-number is odd and an integer value if the tag number is even. The
-second bit (`TAG & 2' is set for architecture-independent attributes
-and clear for architecture-dependent ones.
-
-8.1.1 Common GNU attributes
----------------------------
-
-These attributes are valid on all architectures.
-
-Tag_compatibility (32)
- The compatibility attribute takes an integer flag value and a
- vendor name. If the flag value is 0, the file is compatible with
- other toolchains. If it is 1, then the file is only compatible
- with the named toolchain. If it is greater than 1, the file can
- only be processed by other toolchains under some private
- arrangement indicated by the flag value and the vendor name.
-
-8.1.2 MIPS Attributes
----------------------
-
-Tag_GNU_MIPS_ABI_FP (4)
- The floating-point ABI used by this object file. The value will
- be:
-
- * 0 for files not affected by the floating-point ABI.
-
- * 1 for files using the hardware floating-point with a standard
- double-precision FPU.
-
- * 2 for files using the hardware floating-point ABI with a
- single-precision FPU.
-
- * 3 for files using the software floating-point ABI.
-
- * 4 for files using the hardware floating-point ABI with 64-bit
- wide double-precision floating-point registers and 32-bit
- wide general purpose registers.
-
-8.1.3 PowerPC Attributes
-------------------------
-
-Tag_GNU_Power_ABI_FP (4)
- The floating-point ABI used by this object file. The value will
- be:
-
- * 0 for files not affected by the floating-point ABI.
-
- * 1 for files using double-precision hardware floating-point
- ABI.
-
- * 2 for files using the software floating-point ABI.
-
- * 3 for files using single-precision hardware floating-point
- ABI.
-
-Tag_GNU_Power_ABI_Vector (8)
- The vector ABI used by this object file. The value will be:
-
- * 0 for files not affected by the vector ABI.
-
- * 1 for files using general purpose registers to pass vectors.
-
- * 2 for files using AltiVec registers to pass vectors.
-
- * 3 for files using SPE registers to pass vectors.
-
-
-File: as.info, Node: Defining New Object Attributes, Prev: GNU Object Attributes, Up: Object Attributes
-
-8.2 Defining New Object Attributes
-==================================
-
-If you want to define a new GNU object attribute, here are the places
-you will need to modify. New attributes should be discussed on the
-`binutils' mailing list.
-
- * This manual, which is the official register of attributes.
-
- * The header for your architecture `include/elf', to define the tag.
-
- * The `bfd' support file for your architecture, to merge the
- attribute and issue any appropriate link warnings.
-
- * Test cases in `ld/testsuite' for merging and link warnings.
-
- * `binutils/readelf.c' to display your attribute.
-
- * GCC, if you want the compiler to mark the attribute automatically.
-
-
-File: as.info, Node: Machine Dependencies, Next: Reporting Bugs, Prev: Object Attributes, Up: Top
-
-9 Machine Dependent Features
-****************************
-
-The machine instruction sets are (almost by definition) different on
-each machine where `as' runs. Floating point representations vary as
-well, and `as' often supports a few additional directives or
-command-line options for compatibility with other assemblers on a
-particular platform. Finally, some versions of `as' support special
-pseudo-instructions for branch optimization.
-
- This chapter discusses most of these differences, though it does not
-include details on any machine's instruction set. For details on that
-subject, see the hardware manufacturer's manual.
-
-* Menu:
-
-
-* Alpha-Dependent:: Alpha Dependent Features
-
-* ARC-Dependent:: ARC Dependent Features
-
-* ARM-Dependent:: ARM Dependent Features
-
-* AVR-Dependent:: AVR Dependent Features
-
-* Blackfin-Dependent:: Blackfin Dependent Features
-
-* CR16-Dependent:: CR16 Dependent Features
-
-* CRIS-Dependent:: CRIS Dependent Features
-
-* D10V-Dependent:: D10V Dependent Features
-
-* D30V-Dependent:: D30V Dependent Features
-
-* H8/300-Dependent:: Renesas H8/300 Dependent Features
-
-* HPPA-Dependent:: HPPA Dependent Features
-
-* ESA/390-Dependent:: IBM ESA/390 Dependent Features
-
-* i386-Dependent:: Intel 80386 and AMD x86-64 Dependent Features
-
-* i860-Dependent:: Intel 80860 Dependent Features
-
-* i960-Dependent:: Intel 80960 Dependent Features
-
-* IA-64-Dependent:: Intel IA-64 Dependent Features
-
-* IP2K-Dependent:: IP2K Dependent Features
-
-* LM32-Dependent:: LM32 Dependent Features
-
-* M32C-Dependent:: M32C Dependent Features
-
-* M32R-Dependent:: M32R Dependent Features
-
-* M68K-Dependent:: M680x0 Dependent Features
-
-* M68HC11-Dependent:: M68HC11 and 68HC12 Dependent Features
-
-* MicroBlaze-Dependent:: MICROBLAZE Dependent Features
-
-* MIPS-Dependent:: MIPS Dependent Features
-
-* MMIX-Dependent:: MMIX Dependent Features
-
-* MSP430-Dependent:: MSP430 Dependent Features
-
-* SH-Dependent:: Renesas / SuperH SH Dependent Features
-* SH64-Dependent:: SuperH SH64 Dependent Features
-
-* PDP-11-Dependent:: PDP-11 Dependent Features
-
-* PJ-Dependent:: picoJava Dependent Features
-
-* PPC-Dependent:: PowerPC Dependent Features
-
-* RX-Dependent:: RX Dependent Features
-
-* S/390-Dependent:: IBM S/390 Dependent Features
-
-* SCORE-Dependent:: SCORE Dependent Features
-
-* Sparc-Dependent:: SPARC Dependent Features
-
-* TIC54X-Dependent:: TI TMS320C54x Dependent Features
-
-* TIC6X-Dependent :: TI TMS320C6x Dependent Features
-
-* V850-Dependent:: V850 Dependent Features
-
-* Xtensa-Dependent:: Xtensa Dependent Features
-
-* Z80-Dependent:: Z80 Dependent Features
-
-* Z8000-Dependent:: Z8000 Dependent Features
-
-* Vax-Dependent:: VAX Dependent Features
-
-
-File: as.info, Node: Alpha-Dependent, Next: ARC-Dependent, Up: Machine Dependencies
-
-9.1 Alpha Dependent Features
-============================
-
-* Menu:
-
-* Alpha Notes:: Notes
-* Alpha Options:: Options
-* Alpha Syntax:: Syntax
-* Alpha Floating Point:: Floating Point
-* Alpha Directives:: Alpha Machine Directives
-* Alpha Opcodes:: Opcodes
-
-
-File: as.info, Node: Alpha Notes, Next: Alpha Options, Up: Alpha-Dependent
-
-9.1.1 Notes
------------
-
-The documentation here is primarily for the ELF object format. `as'
-also supports the ECOFF and EVAX formats, but features specific to
-these formats are not yet documented.
-
-
-File: as.info, Node: Alpha Options, Next: Alpha Syntax, Prev: Alpha Notes, Up: Alpha-Dependent
-
-9.1.2 Options
--------------
-
-`-mCPU'
- This option specifies the target processor. If an attempt is made
- to assemble an instruction which will not execute on the target
- processor, the assembler may either expand the instruction as a
- macro or issue an error message. This option is equivalent to the
- `.arch' directive.
-
- The following processor names are recognized: `21064', `21064a',
- `21066', `21068', `21164', `21164a', `21164pc', `21264', `21264a',
- `21264b', `ev4', `ev5', `lca45', `ev5', `ev56', `pca56', `ev6',
- `ev67', `ev68'. The special name `all' may be used to allow the
- assembler to accept instructions valid for any Alpha processor.
-
- In order to support existing practice in OSF/1 with respect to
- `.arch', and existing practice within `MILO' (the Linux ARC
- bootloader), the numbered processor names (e.g. 21064) enable the
- processor-specific PALcode instructions, while the
- "electro-vlasic" names (e.g. `ev4') do not.
-
-`-mdebug'
-`-no-mdebug'
- Enables or disables the generation of `.mdebug' encapsulation for
- stabs directives and procedure descriptors. The default is to
- automatically enable `.mdebug' when the first stabs directive is
- seen.
-
-`-relax'
- This option forces all relocations to be put into the object file,
- instead of saving space and resolving some relocations at assembly
- time. Note that this option does not propagate all symbol
- arithmetic into the object file, because not all symbol arithmetic
- can be represented. However, the option can still be useful in
- specific applications.
-
-`-replace'
-`-noreplace'
- Enables or disables the optimization of procedure calls, both at
- assemblage and at link time. These options are only available for
- VMS targets and `-replace' is the default. See section 1.4.1 of
- the OpenVMS Linker Utility Manual.
-
-`-g'
- This option is used when the compiler generates debug information.
- When `gcc' is using `mips-tfile' to generate debug information for
- ECOFF, local labels must be passed through to the object file.
- Otherwise this option has no effect.
-
-`-GSIZE'
- A local common symbol larger than SIZE is placed in `.bss', while
- smaller symbols are placed in `.sbss'.
-
-`-F'
-`-32addr'
- These options are ignored for backward compatibility.
-
-
-File: as.info, Node: Alpha Syntax, Next: Alpha Floating Point, Prev: Alpha Options, Up: Alpha-Dependent
-
-9.1.3 Syntax
-------------
-
-The assembler syntax closely follow the Alpha Reference Manual;
-assembler directives and general syntax closely follow the OSF/1 and
-OpenVMS syntax, with a few differences for ELF.
-
-* Menu:
-
-* Alpha-Chars:: Special Characters
-* Alpha-Regs:: Register Names
-* Alpha-Relocs:: Relocations
-
-
-File: as.info, Node: Alpha-Chars, Next: Alpha-Regs, Up: Alpha Syntax
-
-9.1.3.1 Special Characters
-..........................
-
-`#' is the line comment character.
-
- `;' can be used instead of a newline to separate statements.
-
-
-File: as.info, Node: Alpha-Regs, Next: Alpha-Relocs, Prev: Alpha-Chars, Up: Alpha Syntax
-
-9.1.3.2 Register Names
-......................
-
-The 32 integer registers are referred to as `$N' or `$rN'. In
-addition, registers 15, 28, 29, and 30 may be referred to by the
-symbols `$fp', `$at', `$gp', and `$sp' respectively.
-
- The 32 floating-point registers are referred to as `$fN'.
-
-
-File: as.info, Node: Alpha-Relocs, Prev: Alpha-Regs, Up: Alpha Syntax
-
-9.1.3.3 Relocations
-...................
-
-Some of these relocations are available for ECOFF, but mostly only for
-ELF. They are modeled after the relocation format introduced in
-Digital Unix 4.0, but there are additions.
-
- The format is `!TAG' or `!TAG!NUMBER' where TAG is the name of the
-relocation. In some cases NUMBER is used to relate specific
-instructions.
-
- The relocation is placed at the end of the instruction like so:
-
- ldah $0,a($29) !gprelhigh
- lda $0,a($0) !gprellow
- ldq $1,b($29) !literal!100
- ldl $2,0($1) !lituse_base!100
-
-`!literal'
-`!literal!N'
- Used with an `ldq' instruction to load the address of a symbol
- from the GOT.
-
- A sequence number N is optional, and if present is used to pair
- `lituse' relocations with this `literal' relocation. The `lituse'
- relocations are used by the linker to optimize the code based on
- the final location of the symbol.
-
- Note that these optimizations are dependent on the data flow of the
- program. Therefore, if _any_ `lituse' is paired with a `literal'
- relocation, then _all_ uses of the register set by the `literal'
- instruction must also be marked with `lituse' relocations. This
- is because the original `literal' instruction may be deleted or
- transformed into another instruction.
-
- Also note that there may be a one-to-many relationship between
- `literal' and `lituse', but not a many-to-one. That is, if there
- are two code paths that load up the same address and feed the
- value to a single use, then the use may not use a `lituse'
- relocation.
-
-`!lituse_base!N'
- Used with any memory format instruction (e.g. `ldl') to indicate
- that the literal is used for an address load. The offset field of
- the instruction must be zero. During relaxation, the code may be
- altered to use a gp-relative load.
-
-`!lituse_jsr!N'
- Used with a register branch format instruction (e.g. `jsr') to
- indicate that the literal is used for a call. During relaxation,
- the code may be altered to use a direct branch (e.g. `bsr').
-
-`!lituse_jsrdirect!N'
- Similar to `lituse_jsr', but also that this call cannot be vectored
- through a PLT entry. This is useful for functions with special
- calling conventions which do not allow the normal call-clobbered
- registers to be clobbered.
-
-`!lituse_bytoff!N'
- Used with a byte mask instruction (e.g. `extbl') to indicate that
- only the low 3 bits of the address are relevant. During
- relaxation, the code may be altered to use an immediate instead of
- a register shift.
-
-`!lituse_addr!N'
- Used with any other instruction to indicate that the original
- address is in fact used, and the original `ldq' instruction may
- not be altered or deleted. This is useful in conjunction with
- `lituse_jsr' to test whether a weak symbol is defined.
-
- ldq $27,foo($29) !literal!1
- beq $27,is_undef !lituse_addr!1
- jsr $26,($27),foo !lituse_jsr!1
-
-`!lituse_tlsgd!N'
- Used with a register branch format instruction to indicate that the
- literal is the call to `__tls_get_addr' used to compute the
- address of the thread-local storage variable whose descriptor was
- loaded with `!tlsgd!N'.
-
-`!lituse_tlsldm!N'
- Used with a register branch format instruction to indicate that the
- literal is the call to `__tls_get_addr' used to compute the
- address of the base of the thread-local storage block for the
- current module. The descriptor for the module must have been
- loaded with `!tlsldm!N'.
-
-`!gpdisp!N'
- Used with `ldah' and `lda' to load the GP from the current
- address, a-la the `ldgp' macro. The source register for the
- `ldah' instruction must contain the address of the `ldah'
- instruction. There must be exactly one `lda' instruction paired
- with the `ldah' instruction, though it may appear anywhere in the
- instruction stream. The immediate operands must be zero.
-
- bsr $26,foo
- ldah $29,0($26) !gpdisp!1
- lda $29,0($29) !gpdisp!1
-
-`!gprelhigh'
- Used with an `ldah' instruction to add the high 16 bits of a
- 32-bit displacement from the GP.
-
-`!gprellow'
- Used with any memory format instruction to add the low 16 bits of a
- 32-bit displacement from the GP.
-
-`!gprel'
- Used with any memory format instruction to add a 16-bit
- displacement from the GP.
-
-`!samegp'
- Used with any branch format instruction to skip the GP load at the
- target address. The referenced symbol must have the same GP as the
- source object file, and it must be declared to either not use `$27'
- or perform a standard GP load in the first two instructions via the
- `.prologue' directive.
-
-`!tlsgd'
-`!tlsgd!N'
- Used with an `lda' instruction to load the address of a TLS
- descriptor for a symbol in the GOT.
-
- The sequence number N is optional, and if present it used to pair
- the descriptor load with both the `literal' loading the address of
- the `__tls_get_addr' function and the `lituse_tlsgd' marking the
- call to that function.
-
- For proper relaxation, both the `tlsgd', `literal' and `lituse'
- relocations must be in the same extended basic block. That is,
- the relocation with the lowest address must be executed first at
- runtime.
-
-`!tlsldm'
-`!tlsldm!N'
- Used with an `lda' instruction to load the address of a TLS
- descriptor for the current module in the GOT.
-
- Similar in other respects to `tlsgd'.
-
-`!gotdtprel'
- Used with an `ldq' instruction to load the offset of the TLS
- symbol within its module's thread-local storage block. Also known
- as the dynamic thread pointer offset or dtp-relative offset.
-
-`!dtprelhi'
-`!dtprello'
-`!dtprel'
- Like `gprel' relocations except they compute dtp-relative offsets.
-
-`!gottprel'
- Used with an `ldq' instruction to load the offset of the TLS
- symbol from the thread pointer. Also known as the tp-relative
- offset.
-
-`!tprelhi'
-`!tprello'
-`!tprel'
- Like `gprel' relocations except they compute tp-relative offsets.
-
-
-File: as.info, Node: Alpha Floating Point, Next: Alpha Directives, Prev: Alpha Syntax, Up: Alpha-Dependent
-
-9.1.4 Floating Point
---------------------
-
-The Alpha family uses both IEEE and VAX floating-point numbers.
-
-
-File: as.info, Node: Alpha Directives, Next: Alpha Opcodes, Prev: Alpha Floating Point, Up: Alpha-Dependent
-
-9.1.5 Alpha Assembler Directives
---------------------------------
-
-`as' for the Alpha supports many additional directives for
-compatibility with the native assembler. This section describes them
-only briefly.
-
- These are the additional directives in `as' for the Alpha:
-
-`.arch CPU'
- Specifies the target processor. This is equivalent to the `-mCPU'
- command-line option. *Note Options: Alpha Options, for a list of
- values for CPU.
-
-`.ent FUNCTION[, N]'
- Mark the beginning of FUNCTION. An optional number may follow for
- compatibility with the OSF/1 assembler, but is ignored. When
- generating `.mdebug' information, this will create a procedure
- descriptor for the function. In ELF, it will mark the symbol as a
- function a-la the generic `.type' directive.
-
-`.end FUNCTION'
- Mark the end of FUNCTION. In ELF, it will set the size of the
- symbol a-la the generic `.size' directive.
-
-`.mask MASK, OFFSET'
- Indicate which of the integer registers are saved in the current
- function's stack frame. MASK is interpreted a bit mask in which
- bit N set indicates that register N is saved. The registers are
- saved in a block located OFFSET bytes from the "canonical frame
- address" (CFA) which is the value of the stack pointer on entry to
- the function. The registers are saved sequentially, except that
- the return address register (normally `$26') is saved first.
-
- This and the other directives that describe the stack frame are
- currently only used when generating `.mdebug' information. They
- may in the future be used to generate DWARF2 `.debug_frame' unwind
- information for hand written assembly.
-
-`.fmask MASK, OFFSET'
- Indicate which of the floating-point registers are saved in the
- current stack frame. The MASK and OFFSET parameters are
- interpreted as with `.mask'.
-
-`.frame FRAMEREG, FRAMEOFFSET, RETREG[, ARGOFFSET]'
- Describes the shape of the stack frame. The frame pointer in use
- is FRAMEREG; normally this is either `$fp' or `$sp'. The frame
- pointer is FRAMEOFFSET bytes below the CFA. The return address is
- initially located in RETREG until it is saved as indicated in
- `.mask'. For compatibility with OSF/1 an optional ARGOFFSET
- parameter is accepted and ignored. It is believed to indicate the
- offset from the CFA to the saved argument registers.
-
-`.prologue N'
- Indicate that the stack frame is set up and all registers have been
- spilled. The argument N indicates whether and how the function
- uses the incoming "procedure vector" (the address of the called
- function) in `$27'. 0 indicates that `$27' is not used; 1
- indicates that the first two instructions of the function use `$27'
- to perform a load of the GP register; 2 indicates that `$27' is
- used in some non-standard way and so the linker cannot elide the
- load of the procedure vector during relaxation.
-
-`.usepv FUNCTION, WHICH'
- Used to indicate the use of the `$27' register, similar to
- `.prologue', but without the other semantics of needing to be
- inside an open `.ent'/`.end' block.
-
- The WHICH argument should be either `no', indicating that `$27' is
- not used, or `std', indicating that the first two instructions of
- the function perform a GP load.
-
- One might use this directive instead of `.prologue' if you are
- also using dwarf2 CFI directives.
-
-`.gprel32 EXPRESSION'
- Computes the difference between the address in EXPRESSION and the
- GP for the current object file, and stores it in 4 bytes. In
- addition to being smaller than a full 8 byte address, this also
- does not require a dynamic relocation when used in a shared
- library.
-
-`.t_floating EXPRESSION'
- Stores EXPRESSION as an IEEE double precision value.
-
-`.s_floating EXPRESSION'
- Stores EXPRESSION as an IEEE single precision value.
-
-`.f_floating EXPRESSION'
- Stores EXPRESSION as a VAX F format value.
-
-`.g_floating EXPRESSION'
- Stores EXPRESSION as a VAX G format value.
-
-`.d_floating EXPRESSION'
- Stores EXPRESSION as a VAX D format value.
-
-`.set FEATURE'
- Enables or disables various assembler features. Using the positive
- name of the feature enables while using `noFEATURE' disables.
-
- `at'
- Indicates that macro expansions may clobber the "assembler
- temporary" (`$at' or `$28') register. Some macros may not be
- expanded without this and will generate an error message if
- `noat' is in effect. When `at' is in effect, a warning will
- be generated if `$at' is used by the programmer.
-
- `macro'
- Enables the expansion of macro instructions. Note that
- variants of real instructions, such as `br label' vs `br
- $31,label' are considered alternate forms and not macros.
-
- `move'
- `reorder'
- `volatile'
- These control whether and how the assembler may re-order
- instructions. Accepted for compatibility with the OSF/1
- assembler, but `as' does not do instruction scheduling, so
- these features are ignored.
-
- The following directives are recognized for compatibility with the
-OSF/1 assembler but are ignored.
-
- .proc .aproc
- .reguse .livereg
- .option .aent
- .ugen .eflag
- .alias .noalias
-
-
-File: as.info, Node: Alpha Opcodes, Prev: Alpha Directives, Up: Alpha-Dependent
-
-9.1.6 Opcodes
--------------
-
-For detailed information on the Alpha machine instruction set, see the
-Alpha Architecture Handbook
-(ftp://ftp.digital.com/pub/Digital/info/semiconductor/literature/alphaahb.pdf).
-
-
-File: as.info, Node: ARC-Dependent, Next: ARM-Dependent, Prev: Alpha-Dependent, Up: Machine Dependencies
-
-9.2 ARC Dependent Features
-==========================
-
-* Menu:
-
-* ARC Options:: Options
-* ARC Syntax:: Syntax
-* ARC Floating Point:: Floating Point
-* ARC Directives:: ARC Machine Directives
-* ARC Opcodes:: Opcodes
-
-
-File: as.info, Node: ARC Options, Next: ARC Syntax, Up: ARC-Dependent
-
-9.2.1 Options
--------------
-
-`-marc[5|6|7|8]'
- This option selects the core processor variant. Using `-marc' is
- the same as `-marc6', which is also the default.
-
- `arc5'
- Base instruction set.
-
- `arc6'
- Jump-and-link (jl) instruction. No requirement of an
- instruction between setting flags and conditional jump. For
- example:
-
- mov.f r0,r1
- beq foo
-
- `arc7'
- Break (brk) and sleep (sleep) instructions.
-
- `arc8'
- Software interrupt (swi) instruction.
-
-
- Note: the `.option' directive can to be used to select a core
- variant from within assembly code.
-
-`-EB'
- This option specifies that the output generated by the assembler
- should be marked as being encoded for a big-endian processor.
-
-`-EL'
- This option specifies that the output generated by the assembler
- should be marked as being encoded for a little-endian processor -
- this is the default.
-
-
-
-File: as.info, Node: ARC Syntax, Next: ARC Floating Point, Prev: ARC Options, Up: ARC-Dependent
-
-9.2.2 Syntax
-------------
-
-* Menu:
-
-* ARC-Chars:: Special Characters
-* ARC-Regs:: Register Names
-
-
-File: as.info, Node: ARC-Chars, Next: ARC-Regs, Up: ARC Syntax
-
-9.2.2.1 Special Characters
-..........................
-
-*TODO*
-
-
-File: as.info, Node: ARC-Regs, Prev: ARC-Chars, Up: ARC Syntax
-
-9.2.2.2 Register Names
-......................
-
-*TODO*
-
-
-File: as.info, Node: ARC Floating Point, Next: ARC Directives, Prev: ARC Syntax, Up: ARC-Dependent
-
-9.2.3 Floating Point
---------------------
-
-The ARC core does not currently have hardware floating point support.
-Software floating point support is provided by `GCC' and uses IEEE
-floating-point numbers.
-
-
-File: as.info, Node: ARC Directives, Next: ARC Opcodes, Prev: ARC Floating Point, Up: ARC-Dependent
-
-9.2.4 ARC Machine Directives
-----------------------------
-
-The ARC version of `as' supports the following additional machine
-directives:
-
-`.2byte EXPRESSIONS'
- *TODO*
-
-`.3byte EXPRESSIONS'
- *TODO*
-
-`.4byte EXPRESSIONS'
- *TODO*
-
-`.extAuxRegister NAME,ADDRESS,MODE'
- The ARCtangent A4 has extensible auxiliary register space. The
- auxiliary registers can be defined in the assembler source code by
- using this directive. The first parameter is the NAME of the new
- auxiallry register. The second parameter is the ADDRESS of the
- register in the auxiliary register memory map for the variant of
- the ARC. The third parameter specifies the MODE in which the
- register can be operated is and it can be one of:
-
- `r (readonly)'
-
- `w (write only)'
-
- `r|w (read or write)'
-
- For example:
-
- .extAuxRegister mulhi,0x12,w
-
- This specifies an extension auxiliary register called _mulhi_
- which is at address 0x12 in the memory space and which is only
- writable.
-
-`.extCondCode SUFFIX,VALUE'
- The condition codes on the ARCtangent A4 are extensible and can be
- specified by means of this assembler directive. They are specified
- by the suffix and the value for the condition code. They can be
- used to specify extra condition codes with any values. For
- example:
-
- .extCondCode is_busy,0x14
-
- add.is_busy r1,r2,r3
- bis_busy _main
-
-`.extCoreRegister NAME,REGNUM,MODE,SHORTCUT'
- Specifies an extension core register NAME for the application.
- This allows a register NAME with a valid REGNUM between 0 and 60,
- with the following as valid values for MODE
-
- `_r_ (readonly)'
-
- `_w_ (write only)'
-
- `_r|w_ (read or write)'
-
- The other parameter gives a description of the register having a
- SHORTCUT in the pipeline. The valid values are:
-
- `can_shortcut'
-
- `cannot_shortcut'
-
- For example:
-
- .extCoreRegister mlo,57,r,can_shortcut
-
- This defines an extension core register mlo with the value 57 which
- can shortcut the pipeline.
-
-`.extInstruction NAME,OPCODE,SUBOPCODE,SUFFIXCLASS,SYNTAXCLASS'
- The ARCtangent A4 allows the user to specify extension
- instructions. The extension instructions are not macros. The
- assembler creates encodings for use of these instructions
- according to the specification by the user. The parameters are:
-
- *NAME
- Name of the extension instruction
-
- *OPCODE
- Opcode to be used. (Bits 27:31 in the encoding). Valid values
- 0x10-0x1f or 0x03
-
- *SUBOPCODE
- Subopcode to be used. Valid values are from 0x09-0x3f.
- However the correct value also depends on SYNTAXCLASS
-
- *SUFFIXCLASS
- Determines the kinds of suffixes to be allowed. Valid values
- are `SUFFIX_NONE', `SUFFIX_COND', `SUFFIX_FLAG' which
- indicates the absence or presence of conditional suffixes and
- flag setting by the extension instruction. It is also
- possible to specify that an instruction sets the flags and is
- conditional by using `SUFFIX_CODE' | `SUFFIX_FLAG'.
-
- *SYNTAXCLASS
- Determines the syntax class for the instruction. It can have
- the following values:
-
- ``SYNTAX_2OP':'
- 2 Operand Instruction
-
- ``SYNTAX_3OP':'
- 3 Operand Instruction
-
- In addition there could be modifiers for the syntax class as
- described below:
-
- Syntax Class Modifiers are:
-
- - `OP1_MUST_BE_IMM': Modifies syntax class SYNTAX_3OP,
- specifying that the first operand of a three-operand
- instruction must be an immediate (i.e., the result is
- discarded). OP1_MUST_BE_IMM is used by bitwise ORing it
- with SYNTAX_3OP as given in the example below. This
- could usually be used to set the flags using specific
- instructions and not retain results.
-
- - `OP1_IMM_IMPLIED': Modifies syntax class SYNTAX_20P, it
- specifies that there is an implied immediate destination
- operand which does not appear in the syntax. For
- example, if the source code contains an instruction like:
-
- inst r1,r2
-
- it really means that the first argument is an implied
- immediate (that is, the result is discarded). This is
- the same as though the source code were: inst 0,r1,r2.
- You use OP1_IMM_IMPLIED by bitwise ORing it with
- SYNTAX_20P.
-
-
- For example, defining 64-bit multiplier with immediate operands:
-
- .extInstruction mp64,0x14,0x0,SUFFIX_COND | SUFFIX_FLAG ,
- SYNTAX_3OP|OP1_MUST_BE_IMM
-
- The above specifies an extension instruction called mp64 which has
- 3 operands, sets the flags, can be used with a condition code, for
- which the first operand is an immediate. (Equivalent to
- discarding the result of the operation).
-
- .extInstruction mul64,0x14,0x00,SUFFIX_COND, SYNTAX_2OP|OP1_IMM_IMPLIED
-
- This describes a 2 operand instruction with an implicit first
- immediate operand. The result of this operation would be
- discarded.
-
-`.half EXPRESSIONS'
- *TODO*
-
-`.long EXPRESSIONS'
- *TODO*
-
-`.option ARC|ARC5|ARC6|ARC7|ARC8'
- The `.option' directive must be followed by the desired core
- version. Again `arc' is an alias for `arc6'.
-
- Note: the `.option' directive overrides the command line option
- `-marc'; a warning is emitted when the version is not consistent
- between the two - even for the implicit default core version
- (arc6).
-
-`.short EXPRESSIONS'
- *TODO*
-
-`.word EXPRESSIONS'
- *TODO*
-
-
-
-File: as.info, Node: ARC Opcodes, Prev: ARC Directives, Up: ARC-Dependent
-
-9.2.5 Opcodes
--------------
-
-For information on the ARC instruction set, see `ARC Programmers
-Reference Manual', ARC International (www.arc.com)
-
-
-File: as.info, Node: ARM-Dependent, Next: AVR-Dependent, Prev: ARC-Dependent, Up: Machine Dependencies
-
-9.3 ARM Dependent Features
-==========================
-
-* Menu:
-
-* ARM Options:: Options
-* ARM Syntax:: Syntax
-* ARM Floating Point:: Floating Point
-* ARM Directives:: ARM Machine Directives
-* ARM Opcodes:: Opcodes
-* ARM Mapping Symbols:: Mapping Symbols
-* ARM Unwinding Tutorial:: Unwinding
-
-
-File: as.info, Node: ARM Options, Next: ARM Syntax, Up: ARM-Dependent
-
-9.3.1 Options
--------------
-
-`-mcpu=PROCESSOR[+EXTENSION...]'
- This option specifies the target processor. The assembler will
- issue an error message if an attempt is made to assemble an
- instruction which will not execute on the target processor. The
- following processor names are recognized: `arm1', `arm2', `arm250',
- `arm3', `arm6', `arm60', `arm600', `arm610', `arm620', `arm7',
- `arm7m', `arm7d', `arm7dm', `arm7di', `arm7dmi', `arm70', `arm700',
- `arm700i', `arm710', `arm710t', `arm720', `arm720t', `arm740t',
- `arm710c', `arm7100', `arm7500', `arm7500fe', `arm7t', `arm7tdmi',
- `arm7tdmi-s', `arm8', `arm810', `strongarm', `strongarm1',
- `strongarm110', `strongarm1100', `strongarm1110', `arm9', `arm920',
- `arm920t', `arm922t', `arm940t', `arm9tdmi', `fa526' (Faraday
- FA526 processor), `fa626' (Faraday FA626 processor), `arm9e',
- `arm926e', `arm926ej-s', `arm946e-r0', `arm946e', `arm946e-s',
- `arm966e-r0', `arm966e', `arm966e-s', `arm968e-s', `arm10t',
- `arm10tdmi', `arm10e', `arm1020', `arm1020t', `arm1020e',
- `arm1022e', `arm1026ej-s', `fa626te' (Faraday FA626TE processor),
- `fa726te' (Faraday FA726TE processor), `arm1136j-s', `arm1136jf-s',
- `arm1156t2-s', `arm1156t2f-s', `arm1176jz-s', `arm1176jzf-s',
- `mpcore', `mpcorenovfp', `cortex-a5', `cortex-a8', `cortex-a9',
- `cortex-a15', `cortex-r4', `cortex-r4f', `cortex-m4', `cortex-m3',
- `cortex-m1', `cortex-m0', `ep9312' (ARM920 with Cirrus Maverick
- coprocessor), `i80200' (Intel XScale processor) `iwmmxt' (Intel(r)
- XScale processor with Wireless MMX(tm) technology coprocessor) and
- `xscale'. The special name `all' may be used to allow the
- assembler to accept instructions valid for any ARM processor.
-
- In addition to the basic instruction set, the assembler can be
- told to accept various extension mnemonics that extend the
- processor using the co-processor instruction space. For example,
- `-mcpu=arm920+maverick' is equivalent to specifying `-mcpu=ep9312'.
-
- Multiple extensions may be specified, separated by a `+'. The
- extensions should be specified in ascending alphabetical order.
-
- Some extensions may be restricted to particular architectures;
- this is documented in the list of extensions below.
-
- Extension mnemonics may also be removed from those the assembler
- accepts. This is done be prepending `no' to the option that adds
- the extension. Extensions that are removed should be listed after
- all extensions which have been added, again in ascending
- alphabetical order. For example, `-mcpu=ep9312+nomaverick' is
- equivalent to specifying `-mcpu=arm920'.
-
- The following extensions are currently supported: `idiv', (Integer
- Divide Extensions for v7-A architecture), `iwmmxt', `iwmmxt2',
- `maverick', `mp' (Multiprocessing Extensions for v7-A and v7-R
- architectures), `os' (Operating System for v6M architecture),
- `sec' (Security Extensions for v6K and v7-A architectures), `virt'
- (Virtualization Extensions for v7-A architecture, implies `idiv'),
- and `xscale'.
-
-`-march=ARCHITECTURE[+EXTENSION...]'
- This option specifies the target architecture. The assembler will
- issue an error message if an attempt is made to assemble an
- instruction which will not execute on the target architecture.
- The following architecture names are recognized: `armv1', `armv2',
- `armv2a', `armv2s', `armv3', `armv3m', `armv4', `armv4xm',
- `armv4t', `armv4txm', `armv5', `armv5t', `armv5txm', `armv5te',
- `armv5texp', `armv6', `armv6j', `armv6k', `armv6z', `armv6zk',
- `armv6-m', `armv6s-m', `armv7', `armv7-a', `armv7-r', `armv7-m',
- `armv7e-m', `iwmmxt' and `xscale'. If both `-mcpu' and `-march'
- are specified, the assembler will use the setting for `-mcpu'.
-
- The architecture option can be extended with the same instruction
- set extension options as the `-mcpu' option.
-
-`-mfpu=FLOATING-POINT-FORMAT'
- This option specifies the floating point format to assemble for.
- The assembler will issue an error message if an attempt is made to
- assemble an instruction which will not execute on the target
- floating point unit. The following format options are recognized:
- `softfpa', `fpe', `fpe2', `fpe3', `fpa', `fpa10', `fpa11',
- `arm7500fe', `softvfp', `softvfp+vfp', `vfp', `vfp10', `vfp10-r0',
- `vfp9', `vfpxd', `vfpv2', `vfpv3', `vfpv3-fp16', `vfpv3-d16',
- `vfpv3-d16-fp16', `vfpv3xd', `vfpv3xd-d16', `vfpv4', `vfpv4-d16',
- `fpv4-sp-d16', `arm1020t', `arm1020e', `arm1136jf-s', `maverick',
- `neon', and `neon-vfpv4'.
-
- In addition to determining which instructions are assembled, this
- option also affects the way in which the `.double' assembler
- directive behaves when assembling little-endian code.
-
- The default is dependent on the processor selected. For
- Architecture 5 or later, the default is to assembler for VFP
- instructions; for earlier architectures the default is to assemble
- for FPA instructions.
-
-`-mthumb'
- This option specifies that the assembler should start assembling
- Thumb instructions; that is, it should behave as though the file
- starts with a `.code 16' directive.
-
-`-mthumb-interwork'
- This option specifies that the output generated by the assembler
- should be marked as supporting interworking.
-
-`-mimplicit-it=never'
-`-mimplicit-it=always'
-`-mimplicit-it=arm'
-`-mimplicit-it=thumb'
- The `-mimplicit-it' option controls the behavior of the assembler
- when conditional instructions are not enclosed in IT blocks.
- There are four possible behaviors. If `never' is specified, such
- constructs cause a warning in ARM code and an error in Thumb-2
- code. If `always' is specified, such constructs are accepted in
- both ARM and Thumb-2 code, where the IT instruction is added
- implicitly. If `arm' is specified, such constructs are accepted
- in ARM code and cause an error in Thumb-2 code. If `thumb' is
- specified, such constructs cause a warning in ARM code and are
- accepted in Thumb-2 code. If you omit this option, the behavior
- is equivalent to `-mimplicit-it=arm'.
-
-`-mapcs-26'
-`-mapcs-32'
- These options specify that the output generated by the assembler
- should be marked as supporting the indicated version of the Arm
- Procedure. Calling Standard.
-
-`-matpcs'
- This option specifies that the output generated by the assembler
- should be marked as supporting the Arm/Thumb Procedure Calling
- Standard. If enabled this option will cause the assembler to
- create an empty debugging section in the object file called
- .arm.atpcs. Debuggers can use this to determine the ABI being
- used by.
-
-`-mapcs-float'
- This indicates the floating point variant of the APCS should be
- used. In this variant floating point arguments are passed in FP
- registers rather than integer registers.
-
-`-mapcs-reentrant'
- This indicates that the reentrant variant of the APCS should be
- used. This variant supports position independent code.
-
-`-mfloat-abi=ABI'
- This option specifies that the output generated by the assembler
- should be marked as using specified floating point ABI. The
- following values are recognized: `soft', `softfp' and `hard'.
-
-`-meabi=VER'
- This option specifies which EABI version the produced object files
- should conform to. The following values are recognized: `gnu', `4'
- and `5'.
-
-`-EB'
- This option specifies that the output generated by the assembler
- should be marked as being encoded for a big-endian processor.
-
-`-EL'
- This option specifies that the output generated by the assembler
- should be marked as being encoded for a little-endian processor.
-
-`-k'
- This option specifies that the output of the assembler should be
- marked as position-independent code (PIC).
-
-`--fix-v4bx'
- Allow `BX' instructions in ARMv4 code. This is intended for use
- with the linker option of the same name.
-
-`-mwarn-deprecated'
-`-mno-warn-deprecated'
- Enable or disable warnings about using deprecated options or
- features. The default is to warn.
-
-
-
-File: as.info, Node: ARM Syntax, Next: ARM Floating Point, Prev: ARM Options, Up: ARM-Dependent
-
-9.3.2 Syntax
-------------
-
-* Menu:
-
-* ARM-Instruction-Set:: Instruction Set
-* ARM-Chars:: Special Characters
-* ARM-Regs:: Register Names
-* ARM-Relocations:: Relocations
-* ARM-Neon-Alignment:: NEON Alignment Specifiers
-
-
-File: as.info, Node: ARM-Instruction-Set, Next: ARM-Chars, Up: ARM Syntax
-
-9.3.2.1 Instruction Set Syntax
-..............................
-
-Two slightly different syntaxes are support for ARM and THUMB
-instructions. The default, `divided', uses the old style where ARM and
-THUMB instructions had their own, separate syntaxes. The new,
-`unified' syntax, which can be selected via the `.syntax' directive,
-and has the following main features:
-
-*
- Immediate operands do not require a `#' prefix.
-
-*
- The `IT' instruction may appear, and if it does it is validated
- against subsequent conditional affixes. In ARM mode it does not
- generate machine code, in THUMB mode it does.
-
-*
- For ARM instructions the conditional affixes always appear at the
- end of the instruction. For THUMB instructions conditional
- affixes can be used, but only inside the scope of an `IT'
- instruction.
-
-*
- All of the instructions new to the V6T2 architecture (and later)
- are available. (Only a few such instructions can be written in the
- `divided' syntax).
-
-*
- The `.N' and `.W' suffixes are recognized and honored.
-
-*
- All instructions set the flags if and only if they have an `s'
- affix.
-
-
-File: as.info, Node: ARM-Chars, Next: ARM-Regs, Prev: ARM-Instruction-Set, Up: ARM Syntax
-
-9.3.2.2 Special Characters
-..........................
-
-The presence of a `@' on a line indicates the start of a comment that
-extends to the end of the current line. If a `#' appears as the first
-character of a line, the whole line is treated as a comment.
-
- The `;' character can be used instead of a newline to separate
-statements.
-
- Either `#' or `$' can be used to indicate immediate operands.
-
- *TODO* Explain about /data modifier on symbols.
-
-
-File: as.info, Node: ARM-Regs, Next: ARM-Relocations, Prev: ARM-Chars, Up: ARM Syntax
-
-9.3.2.3 Register Names
-......................
-
-*TODO* Explain about ARM register naming, and the predefined names.
-
-
-File: as.info, Node: ARM-Neon-Alignment, Prev: ARM-Relocations, Up: ARM Syntax
-
-9.3.2.4 NEON Alignment Specifiers
-.................................
-
-Some NEON load/store instructions allow an optional address alignment
-qualifier. The ARM documentation specifies that this is indicated by
-`@ ALIGN'. However GAS already interprets the `@' character as a "line
-comment" start, so `: ALIGN' is used instead. For example:
-
- vld1.8 {q0}, [r0, :128]
-
-
-File: as.info, Node: ARM Floating Point, Next: ARM Directives, Prev: ARM Syntax, Up: ARM-Dependent
-
-9.3.3 Floating Point
---------------------
-
-The ARM family uses IEEE floating-point numbers.
-
-
-File: as.info, Node: ARM-Relocations, Next: ARM-Neon-Alignment, Prev: ARM-Regs, Up: ARM Syntax
-
-9.3.3.1 ARM relocation generation
-.................................
-
-Specific data relocations can be generated by putting the relocation
-name in parentheses after the symbol name. For example:
-
- .word foo(TARGET1)
-
- This will generate an `R_ARM_TARGET1' relocation against the symbol
-FOO. The following relocations are supported: `GOT', `GOTOFF',
-`TARGET1', `TARGET2', `SBREL', `TLSGD', `TLSLDM', `TLSLDO', `GOTTPOFF',
-`GOT_PREL' and `TPOFF'.
-
- For compatibility with older toolchains the assembler also accepts
-`(PLT)' after branch targets. This will generate the deprecated
-`R_ARM_PLT32' relocation.
-
- Relocations for `MOVW' and `MOVT' instructions can be generated by
-prefixing the value with `#:lower16:' and `#:upper16' respectively.
-For example to load the 32-bit address of foo into r0:
-
- MOVW r0, #:lower16:foo
- MOVT r0, #:upper16:foo
-
-
-File: as.info, Node: ARM Directives, Next: ARM Opcodes, Prev: ARM Floating Point, Up: ARM-Dependent
-
-9.3.4 ARM Machine Directives
-----------------------------
-
-`.2byte EXPRESSION [, EXPRESSION]*'
-`.4byte EXPRESSION [, EXPRESSION]*'
-`.8byte EXPRESSION [, EXPRESSION]*'
- These directives write 2, 4 or 8 byte values to the output section.
-
-`.align EXPRESSION [, EXPRESSION]'
- This is the generic .ALIGN directive. For the ARM however if the
- first argument is zero (ie no alignment is needed) the assembler
- will behave as if the argument had been 2 (ie pad to the next four
- byte boundary). This is for compatibility with ARM's own
- assembler.
-
-`.arch NAME'
- Select the target architecture. Valid values for NAME are the
- same as for the `-march' commandline option.
-
- Specifying `.arch' clears any previously selected architecture
- extensions.
-
-`.arch_extension NAME'
- Add or remove an architecture extension to the target
- architecture. Valid values for NAME are the same as those
- accepted as architectural extensions by the `-mcpu' commandline
- option.
-
- `.arch_extension' may be used multiple times to add or remove
- extensions incrementally to the architecture being compiled for.
-
-`.arm'
- This performs the same action as .CODE 32.
-
-`.pad #COUNT'
- Generate unwinder annotations for a stack adjustment of COUNT
- bytes. A positive value indicates the function prologue allocated
- stack space by decrementing the stack pointer.
-
-`.bss'
- This directive switches to the `.bss' section.
-
-`.cantunwind'
- Prevents unwinding through the current function. No personality
- routine or exception table data is required or permitted.
-
-`.code `[16|32]''
- This directive selects the instruction set being generated. The
- value 16 selects Thumb, with the value 32 selecting ARM.
-
-`.cpu NAME'
- Select the target processor. Valid values for NAME are the same as
- for the `-mcpu' commandline option.
-
- Specifying `.cpu' clears any previously selected architecture
- extensions.
-
-`NAME .dn REGISTER NAME [.TYPE] [[INDEX]]'
-`NAME .qn REGISTER NAME [.TYPE] [[INDEX]]'
- The `dn' and `qn' directives are used to create typed and/or
- indexed register aliases for use in Advanced SIMD Extension (Neon)
- instructions. The former should be used to create aliases of
- double-precision registers, and the latter to create aliases of
- quad-precision registers.
-
- If these directives are used to create typed aliases, those
- aliases can be used in Neon instructions instead of writing types
- after the mnemonic or after each operand. For example:
-
- x .dn d2.f32
- y .dn d3.f32
- z .dn d4.f32[1]
- vmul x,y,z
-
- This is equivalent to writing the following:
-
- vmul.f32 d2,d3,d4[1]
-
- Aliases created using `dn' or `qn' can be destroyed using `unreq'.
-
-`.eabi_attribute TAG, VALUE'
- Set the EABI object attribute TAG to VALUE.
-
- The TAG is either an attribute number, or one of the following:
- `Tag_CPU_raw_name', `Tag_CPU_name', `Tag_CPU_arch',
- `Tag_CPU_arch_profile', `Tag_ARM_ISA_use', `Tag_THUMB_ISA_use',
- `Tag_FP_arch', `Tag_WMMX_arch', `Tag_Advanced_SIMD_arch',
- `Tag_PCS_config', `Tag_ABI_PCS_R9_use', `Tag_ABI_PCS_RW_data',
- `Tag_ABI_PCS_RO_data', `Tag_ABI_PCS_GOT_use',
- `Tag_ABI_PCS_wchar_t', `Tag_ABI_FP_rounding',
- `Tag_ABI_FP_denormal', `Tag_ABI_FP_exceptions',
- `Tag_ABI_FP_user_exceptions', `Tag_ABI_FP_number_model',
- `Tag_ABI_align_needed', `Tag_ABI_align_preserved',
- `Tag_ABI_enum_size', `Tag_ABI_HardFP_use', `Tag_ABI_VFP_args',
- `Tag_ABI_WMMX_args', `Tag_ABI_optimization_goals',
- `Tag_ABI_FP_optimization_goals', `Tag_compatibility',
- `Tag_CPU_unaligned_access', `Tag_FP_HP_extension',
- `Tag_ABI_FP_16bit_format', `Tag_MPextension_use', `Tag_DIV_use',
- `Tag_nodefaults', `Tag_also_compatible_with', `Tag_conformance',
- `Tag_T2EE_use', `Tag_Virtualization_use'
-
- The VALUE is either a `number', `"string"', or `number, "string"'
- depending on the tag.
-
- Note - the following legacy values are also accepted by TAG:
- `Tag_VFP_arch', `Tag_ABI_align8_needed',
- `Tag_ABI_align8_preserved', `Tag_VFP_HP_extension',
-
-`.even'
- This directive aligns to an even-numbered address.
-
-`.extend EXPRESSION [, EXPRESSION]*'
-`.ldouble EXPRESSION [, EXPRESSION]*'
- These directives write 12byte long double floating-point values to
- the output section. These are not compatible with current ARM
- processors or ABIs.
-
-`.fnend'
- Marks the end of a function with an unwind table entry. The
- unwind index table entry is created when this directive is
- processed.
-
- If no personality routine has been specified then standard
- personality routine 0 or 1 will be used, depending on the number
- of unwind opcodes required.
-
-`.fnstart'
- Marks the start of a function with an unwind table entry.
-
-`.force_thumb'
- This directive forces the selection of Thumb instructions, even if
- the target processor does not support those instructions
-
-`.fpu NAME'
- Select the floating-point unit to assemble for. Valid values for
- NAME are the same as for the `-mfpu' commandline option.
-
-`.handlerdata'
- Marks the end of the current function, and the start of the
- exception table entry for that function. Anything between this
- directive and the `.fnend' directive will be added to the
- exception table entry.
-
- Must be preceded by a `.personality' or `.personalityindex'
- directive.
-
-`.inst OPCODE [ , ... ]'
-`.inst.n OPCODE [ , ... ]'
-`.inst.w OPCODE [ , ... ]'
- Generates the instruction corresponding to the numerical value
- OPCODE. `.inst.n' and `.inst.w' allow the Thumb instruction size
- to be specified explicitly, overriding the normal encoding rules.
-
-`.ldouble EXPRESSION [, EXPRESSION]*'
- See `.extend'.
-
-`.ltorg'
- This directive causes the current contents of the literal pool to
- be dumped into the current section (which is assumed to be the
- .text section) at the current location (aligned to a word
- boundary). `GAS' maintains a separate literal pool for each
- section and each sub-section. The `.ltorg' directive will only
- affect the literal pool of the current section and sub-section.
- At the end of assembly all remaining, un-empty literal pools will
- automatically be dumped.
-
- Note - older versions of `GAS' would dump the current literal pool
- any time a section change occurred. This is no longer done, since
- it prevents accurate control of the placement of literal pools.
-
-`.movsp REG [, #OFFSET]'
- Tell the unwinder that REG contains an offset from the current
- stack pointer. If OFFSET is not specified then it is assumed to be
- zero.
-
-`.object_arch NAME'
- Override the architecture recorded in the EABI object attribute
- section. Valid values for NAME are the same as for the `.arch'
- directive. Typically this is useful when code uses runtime
- detection of CPU features.
-
-`.packed EXPRESSION [, EXPRESSION]*'
- This directive writes 12-byte packed floating-point values to the
- output section. These are not compatible with current ARM
- processors or ABIs.
-
-`.pad #COUNT'
- Generate unwinder annotations for a stack adjustment of COUNT
- bytes. A positive value indicates the function prologue allocated
- stack space by decrementing the stack pointer.
-
-`.personality NAME'
- Sets the personality routine for the current function to NAME.
-
-`.personalityindex INDEX'
- Sets the personality routine for the current function to the EABI
- standard routine number INDEX
-
-`.pool'
- This is a synonym for .ltorg.
-
-`NAME .req REGISTER NAME'
- This creates an alias for REGISTER NAME called NAME. For example:
-
- foo .req r0
-
-`.save REGLIST'
- Generate unwinder annotations to restore the registers in REGLIST.
- The format of REGLIST is the same as the corresponding
- store-multiple instruction.
-
- _core registers_
- .save {r4, r5, r6, lr}
- stmfd sp!, {r4, r5, r6, lr}
- _FPA registers_
- .save f4, 2
- sfmfd f4, 2, [sp]!
- _VFP registers_
- .save {d8, d9, d10}
- fstmdx sp!, {d8, d9, d10}
- _iWMMXt registers_
- .save {wr10, wr11}
- wstrd wr11, [sp, #-8]!
- wstrd wr10, [sp, #-8]!
- or
- .save wr11
- wstrd wr11, [sp, #-8]!
- .save wr10
- wstrd wr10, [sp, #-8]!
-
-`.setfp FPREG, SPREG [, #OFFSET]'
- Make all unwinder annotations relative to a frame pointer.
- Without this the unwinder will use offsets from the stack pointer.
-
- The syntax of this directive is the same as the `add' or `mov'
- instruction used to set the frame pointer. SPREG must be either
- `sp' or mentioned in a previous `.movsp' directive.
-
- .movsp ip
- mov ip, sp
- ...
- .setfp fp, ip, #4
- add fp, ip, #4
-
-`.secrel32 EXPRESSION [, EXPRESSION]*'
- This directive emits relocations that evaluate to the
- section-relative offset of each expression's symbol. This
- directive is only supported for PE targets.
-
-`.syntax [`unified' | `divided']'
- This directive sets the Instruction Set Syntax as described in the
- *note ARM-Instruction-Set:: section.
-
-`.thumb'
- This performs the same action as .CODE 16.
-
-`.thumb_func'
- This directive specifies that the following symbol is the name of a
- Thumb encoded function. This information is necessary in order to
- allow the assembler and linker to generate correct code for
- interworking between Arm and Thumb instructions and should be used
- even if interworking is not going to be performed. The presence
- of this directive also implies `.thumb'
-
- This directive is not neccessary when generating EABI objects. On
- these targets the encoding is implicit when generating Thumb code.
-
-`.thumb_set'
- This performs the equivalent of a `.set' directive in that it
- creates a symbol which is an alias for another symbol (possibly
- not yet defined). This directive also has the added property in
- that it marks the aliased symbol as being a thumb function entry
- point, in the same way that the `.thumb_func' directive does.
-
-`.unreq ALIAS-NAME'
- This undefines a register alias which was previously defined using
- the `req', `dn' or `qn' directives. For example:
-
- foo .req r0
- .unreq foo
-
- An error occurs if the name is undefined. Note - this pseudo op
- can be used to delete builtin in register name aliases (eg 'r0').
- This should only be done if it is really necessary.
-
-`.unwind_raw OFFSET, BYTE1, ...'
- Insert one of more arbitary unwind opcode bytes, which are known
- to adjust the stack pointer by OFFSET bytes.
-
- For example `.unwind_raw 4, 0xb1, 0x01' is equivalent to `.save
- {r0}'
-
-`.vsave VFP-REGLIST'
- Generate unwinder annotations to restore the VFP registers in
- VFP-REGLIST using FLDMD. Also works for VFPv3 registers that are
- to be restored using VLDM. The format of VFP-REGLIST is the same
- as the corresponding store-multiple instruction.
-
- _VFP registers_
- .vsave {d8, d9, d10}
- fstmdd sp!, {d8, d9, d10}
- _VFPv3 registers_
- .vsave {d15, d16, d17}
- vstm sp!, {d15, d16, d17}
-
- Since FLDMX and FSTMX are now deprecated, this directive should be
- used in favour of `.save' for saving VFP registers for ARMv6 and
- above.
-
-
-
-File: as.info, Node: ARM Opcodes, Next: ARM Mapping Symbols, Prev: ARM Directives, Up: ARM-Dependent
-
-9.3.5 Opcodes
--------------
-
-`as' implements all the standard ARM opcodes. It also implements
-several pseudo opcodes, including several synthetic load instructions.
-
-`NOP'
- nop
-
- This pseudo op will always evaluate to a legal ARM instruction
- that does nothing. Currently it will evaluate to MOV r0, r0.
-
-`LDR'
- ldr <register> , = <expression>
-
- If expression evaluates to a numeric constant then a MOV or MVN
- instruction will be used in place of the LDR instruction, if the
- constant can be generated by either of these instructions.
- Otherwise the constant will be placed into the nearest literal
- pool (if it not already there) and a PC relative LDR instruction
- will be generated.
-
-`ADR'
- adr <register> <label>
-
- This instruction will load the address of LABEL into the indicated
- register. The instruction will evaluate to a PC relative ADD or
- SUB instruction depending upon where the label is located. If the
- label is out of range, or if it is not defined in the same file
- (and section) as the ADR instruction, then an error will be
- generated. This instruction will not make use of the literal pool.
-
-`ADRL'
- adrl <register> <label>
-
- This instruction will load the address of LABEL into the indicated
- register. The instruction will evaluate to one or two PC relative
- ADD or SUB instructions depending upon where the label is located.
- If a second instruction is not needed a NOP instruction will be
- generated in its place, so that this instruction is always 8 bytes
- long.
-
- If the label is out of range, or if it is not defined in the same
- file (and section) as the ADRL instruction, then an error will be
- generated. This instruction will not make use of the literal pool.
-
-
- For information on the ARM or Thumb instruction sets, see `ARM
-Software Development Toolkit Reference Manual', Advanced RISC Machines
-Ltd.
-
-
-File: as.info, Node: ARM Mapping Symbols, Next: ARM Unwinding Tutorial, Prev: ARM Opcodes, Up: ARM-Dependent
-
-9.3.6 Mapping Symbols
----------------------
-
-The ARM ELF specification requires that special symbols be inserted
-into object files to mark certain features:
-
-`$a'
- At the start of a region of code containing ARM instructions.
-
-`$t'
- At the start of a region of code containing THUMB instructions.
-
-`$d'
- At the start of a region of data.
-
-
- The assembler will automatically insert these symbols for you - there
-is no need to code them yourself. Support for tagging symbols ($b, $f,
-$p and $m) which is also mentioned in the current ARM ELF specification
-is not implemented. This is because they have been dropped from the
-new EABI and so tools cannot rely upon their presence.
-
-
-File: as.info, Node: ARM Unwinding Tutorial, Prev: ARM Mapping Symbols, Up: ARM-Dependent
-
-9.3.7 Unwinding
----------------
-
-The ABI for the ARM Architecture specifies a standard format for
-exception unwind information. This information is used when an
-exception is thrown to determine where control should be transferred.
-In particular, the unwind information is used to determine which
-function called the function that threw the exception, and which
-function called that one, and so forth. This information is also used
-to restore the values of callee-saved registers in the function
-catching the exception.
-
- If you are writing functions in assembly code, and those functions
-call other functions that throw exceptions, you must use assembly
-pseudo ops to ensure that appropriate exception unwind information is
-generated. Otherwise, if one of the functions called by your assembly
-code throws an exception, the run-time library will be unable to unwind
-the stack through your assembly code and your program will not behave
-correctly.
-
- To illustrate the use of these pseudo ops, we will examine the code
-that G++ generates for the following C++ input:
-
-void callee (int *);
-
-int
-caller ()
-{
- int i;
- callee (&i);
- return i;
-}
-
- This example does not show how to throw or catch an exception from
-assembly code. That is a much more complex operation and should always
-be done in a high-level language, such as C++, that directly supports
-exceptions.
-
- The code generated by one particular version of G++ when compiling
-the example above is:
-
-_Z6callerv:
- .fnstart
-.LFB2:
- @ Function supports interworking.
- @ args = 0, pretend = 0, frame = 8
- @ frame_needed = 1, uses_anonymous_args = 0
- stmfd sp!, {fp, lr}
- .save {fp, lr}
-.LCFI0:
- .setfp fp, sp, #4
- add fp, sp, #4
-.LCFI1:
- .pad #8
- sub sp, sp, #8
-.LCFI2:
- sub r3, fp, #8
- mov r0, r3
- bl _Z6calleePi
- ldr r3, [fp, #-8]
- mov r0, r3
- sub sp, fp, #4
- ldmfd sp!, {fp, lr}
- bx lr
-.LFE2:
- .fnend
-
- Of course, the sequence of instructions varies based on the options
-you pass to GCC and on the version of GCC in use. The exact
-instructions are not important since we are focusing on the pseudo ops
-that are used to generate unwind information.
-
- An important assumption made by the unwinder is that the stack frame
-does not change during the body of the function. In particular, since
-we assume that the assembly code does not itself throw an exception,
-the only point where an exception can be thrown is from a call, such as
-the `bl' instruction above. At each call site, the same saved
-registers (including `lr', which indicates the return address) must be
-located in the same locations relative to the frame pointer.
-
- The `.fnstart' (*note .fnstart pseudo op: arm_fnstart.) pseudo op
-appears immediately before the first instruction of the function while
-the `.fnend' (*note .fnend pseudo op: arm_fnend.) pseudo op appears
-immediately after the last instruction of the function. These pseudo
-ops specify the range of the function.
-
- Only the order of the other pseudos ops (e.g., `.setfp' or `.pad')
-matters; their exact locations are irrelevant. In the example above,
-the compiler emits the pseudo ops with particular instructions. That
-makes it easier to understand the code, but it is not required for
-correctness. It would work just as well to emit all of the pseudo ops
-other than `.fnend' in the same order, but immediately after `.fnstart'.
-
- The `.save' (*note .save pseudo op: arm_save.) pseudo op indicates
-registers that have been saved to the stack so that they can be
-restored before the function returns. The argument to the `.save'
-pseudo op is a list of registers to save. If a register is
-"callee-saved" (as specified by the ABI) and is modified by the
-function you are writing, then your code must save the value before it
-is modified and restore the original value before the function returns.
-If an exception is thrown, the run-time library restores the values of
-these registers from their locations on the stack before returning
-control to the exception handler. (Of course, if an exception is not
-thrown, the function that contains the `.save' pseudo op restores these
-registers in the function epilogue, as is done with the `ldmfd'
-instruction above.)
-
- You do not have to save callee-saved registers at the very beginning
-of the function and you do not need to use the `.save' pseudo op
-immediately following the point at which the registers are saved.
-However, if you modify a callee-saved register, you must save it on the
-stack before modifying it and before calling any functions which might
-throw an exception. And, you must use the `.save' pseudo op to
-indicate that you have done so.
-
- The `.pad' (*note .pad: arm_pad.) pseudo op indicates a modification
-of the stack pointer that does not save any registers. The argument is
-the number of bytes (in decimal) that are subtracted from the stack
-pointer. (On ARM CPUs, the stack grows downwards, so subtracting from
-the stack pointer increases the size of the stack.)
-
- The `.setfp' (*note .setfp pseudo op: arm_setfp.) pseudo op
-indicates the register that contains the frame pointer. The first
-argument is the register that is set, which is typically `fp'. The
-second argument indicates the register from which the frame pointer
-takes its value. The third argument, if present, is the value (in
-decimal) added to the register specified by the second argument to
-compute the value of the frame pointer. You should not modify the
-frame pointer in the body of the function.
-
- If you do not use a frame pointer, then you should not use the
-`.setfp' pseudo op. If you do not use a frame pointer, then you should
-avoid modifying the stack pointer outside of the function prologue.
-Otherwise, the run-time library will be unable to find saved registers
-when it is unwinding the stack.
-
- The pseudo ops described above are sufficient for writing assembly
-code that calls functions which may throw exceptions. If you need to
-know more about the object-file format used to represent unwind
-information, you may consult the `Exception Handling ABI for the ARM
-Architecture' available from `http://infocenter.arm.com'.
-
-
-File: as.info, Node: AVR-Dependent, Next: Blackfin-Dependent, Prev: ARM-Dependent, Up: Machine Dependencies
-
-9.4 AVR Dependent Features
-==========================
-
-* Menu:
-
-* AVR Options:: Options
-* AVR Syntax:: Syntax
-* AVR Opcodes:: Opcodes
-
-
-File: as.info, Node: AVR Options, Next: AVR Syntax, Up: AVR-Dependent
-
-9.4.1 Options
--------------
-
-`-mmcu=MCU'
- Specify ATMEL AVR instruction set or MCU type.
-
- Instruction set avr1 is for the minimal AVR core, not supported by
- the C compiler, only for assembler programs (MCU types: at90s1200,
- attiny11, attiny12, attiny15, attiny28).
-
- Instruction set avr2 (default) is for the classic AVR core with up
- to 8K program memory space (MCU types: at90s2313, at90s2323,
- at90s2333, at90s2343, attiny22, attiny26, at90s4414, at90s4433,
- at90s4434, at90s8515, at90c8534, at90s8535).
-
- Instruction set avr25 is for the classic AVR core with up to 8K
- program memory space plus the MOVW instruction (MCU types:
- attiny13, attiny13a, attiny2313, attiny2313a, attiny24, attiny24a,
- attiny4313, attiny44, attiny44a, attiny84, attiny84a, attiny25,
- attiny45, attiny85, attiny261, attiny261a, attiny461, attiny461a,
- attiny861, attiny861a, attiny87, attiny43u, attiny48, attiny88,
- at86rf401, ata6289).
-
- Instruction set avr3 is for the classic AVR core with up to 128K
- program memory space (MCU types: at43usb355, at76c711).
-
- Instruction set avr31 is for the classic AVR core with exactly
- 128K program memory space (MCU types: atmega103, at43usb320).
-
- Instruction set avr35 is for classic AVR core plus MOVW, CALL, and
- JMP instructions (MCU types: attiny167, at90usb82, at90usb162,
- atmega8u2, atmega16u2, atmega32u2).
-
- Instruction set avr4 is for the enhanced AVR core with up to 8K
- program memory space (MCU types: atmega48, atmega48a, atmega48p,
- atmega8, atmega88, atmega88a, atmega88p, atmega88pa, atmega8515,
- atmega8535, atmega8hva, at90pwm1, at90pwm2, at90pwm2b, at90pwm3,
- at90pwm3b, at90pwm81).
-
- Instruction set avr5 is for the enhanced AVR core with up to 128K
- program memory space (MCU types: atmega16, atmega16a, atmega161,
- atmega162, atmega163, atmega164a, atmega164p, atmega165,
- atmega165a, atmega165p, atmega168, atmega168a, atmega168p,
- atmega169, atmega169a, atmega169p, atmega169pa, atmega32,
- atmega323, atmega324a, atmega324p, atmega325, atmega325a,
- atmega325p, atmega3250, atmega3250a, atmega3250p, atmega328,
- atmega328p, atmega329, atmega329a, atmega329p, atmega329pa,
- atmega3290, atmega3290a, atmega3290p, atmega406, atmega64,
- atmega640, atmega644, atmega644a, atmega644p, atmega644pa,
- atmega645, atmega645a, atmega645p, atmega6450, atmega6450a,
- atmega6450p, atmega649, atmega649a, atmega649p, atmega6490,
- atmega6490a, atmega6490p, atmega16hva, atmega16hva2, atmega16hvb,
- atmega32hvb, atmega64hve, at90can32, at90can64, at90pwm216,
- at90pwm316, atmega32c1, atmega64c1, atmega16m1, atmega32m1,
- atmega64m1, atmega16u4, atmega32u4, atmega32u6, at90usb646,
- at90usb647, at94k, at90scr100).
-
- Instruction set avr51 is for the enhanced AVR core with exactly
- 128K program memory space (MCU types: atmega128, atmega1280,
- atmega1281, atmega1284p, atmega128rfa1, at90can128, at90usb1286,
- at90usb1287, m3000).
-
- Instruction set avr6 is for the enhanced AVR core with a 3-byte PC
- (MCU types: atmega2560, atmega2561).
-
-`-mall-opcodes'
- Accept all AVR opcodes, even if not supported by `-mmcu'.
-
-`-mno-skip-bug'
- This option disable warnings for skipping two-word instructions.
-
-`-mno-wrap'
- This option reject `rjmp/rcall' instructions with 8K wrap-around.
-
-
-
-File: as.info, Node: AVR Syntax, Next: AVR Opcodes, Prev: AVR Options, Up: AVR-Dependent
-
-9.4.2 Syntax
-------------
-
-* Menu:
-
-* AVR-Chars:: Special Characters
-* AVR-Regs:: Register Names
-* AVR-Modifiers:: Relocatable Expression Modifiers
-
-
-File: as.info, Node: AVR-Chars, Next: AVR-Regs, Up: AVR Syntax
-
-9.4.2.1 Special Characters
-..........................
-
-The presence of a `;' on a line indicates the start of a comment that
-extends to the end of the current line. If a `#' appears as the first
-character of a line, the whole line is treated as a comment.
-
- The `$' character can be used instead of a newline to separate
-statements.
-
-
-File: as.info, Node: AVR-Regs, Next: AVR-Modifiers, Prev: AVR-Chars, Up: AVR Syntax
-
-9.4.2.2 Register Names
-......................
-
-The AVR has 32 x 8-bit general purpose working registers `r0', `r1',
-... `r31'. Six of the 32 registers can be used as three 16-bit
-indirect address register pointers for Data Space addressing. One of
-the these address pointers can also be used as an address pointer for
-look up tables in Flash program memory. These added function registers
-are the 16-bit `X', `Y' and `Z' - registers.
-
- X = r26:r27
- Y = r28:r29
- Z = r30:r31
-
-
-File: as.info, Node: AVR-Modifiers, Prev: AVR-Regs, Up: AVR Syntax
-
-9.4.2.3 Relocatable Expression Modifiers
-........................................
-
-The assembler supports several modifiers when using relocatable
-addresses in AVR instruction operands. The general syntax is the
-following:
-
- modifier(relocatable-expression)
-
-`lo8'
- This modifier allows you to use bits 0 through 7 of an address
- expression as 8 bit relocatable expression.
-
-`hi8'
- This modifier allows you to use bits 7 through 15 of an address
- expression as 8 bit relocatable expression. This is useful with,
- for example, the AVR `ldi' instruction and `lo8' modifier.
-
- For example
-
- ldi r26, lo8(sym+10)
- ldi r27, hi8(sym+10)
-
-`hh8'
- This modifier allows you to use bits 16 through 23 of an address
- expression as 8 bit relocatable expression. Also, can be useful
- for loading 32 bit constants.
-
-`hlo8'
- Synonym of `hh8'.
-
-`hhi8'
- This modifier allows you to use bits 24 through 31 of an
- expression as 8 bit expression. This is useful with, for example,
- the AVR `ldi' instruction and `lo8', `hi8', `hlo8', `hhi8',
- modifier.
-
- For example
-
- ldi r26, lo8(285774925)
- ldi r27, hi8(285774925)
- ldi r28, hlo8(285774925)
- ldi r29, hhi8(285774925)
- ; r29,r28,r27,r26 = 285774925
-
-`pm_lo8'
- This modifier allows you to use bits 0 through 7 of an address
- expression as 8 bit relocatable expression. This modifier useful
- for addressing data or code from Flash/Program memory. The using
- of `pm_lo8' similar to `lo8'.
-
-`pm_hi8'
- This modifier allows you to use bits 8 through 15 of an address
- expression as 8 bit relocatable expression. This modifier useful
- for addressing data or code from Flash/Program memory.
-
-`pm_hh8'
- This modifier allows you to use bits 15 through 23 of an address
- expression as 8 bit relocatable expression. This modifier useful
- for addressing data or code from Flash/Program memory.
-
-
-
-File: as.info, Node: AVR Opcodes, Prev: AVR Syntax, Up: AVR-Dependent
-
-9.4.3 Opcodes
--------------
-
-For detailed information on the AVR machine instruction set, see
-`www.atmel.com/products/AVR'.
-
- `as' implements all the standard AVR opcodes. The following table
-summarizes the AVR opcodes, and their arguments.
-
- Legend:
- r any register
- d `ldi' register (r16-r31)
- v `movw' even register (r0, r2, ..., r28, r30)
- a `fmul' register (r16-r23)
- w `adiw' register (r24,r26,r28,r30)
- e pointer registers (X,Y,Z)
- b base pointer register and displacement ([YZ]+disp)
- z Z pointer register (for [e]lpm Rd,Z[+])
- M immediate value from 0 to 255
- n immediate value from 0 to 255 ( n = ~M ). Relocation impossible
- s immediate value from 0 to 7
- P Port address value from 0 to 63. (in, out)
- p Port address value from 0 to 31. (cbi, sbi, sbic, sbis)
- K immediate value from 0 to 63 (used in `adiw', `sbiw')
- i immediate value
- l signed pc relative offset from -64 to 63
- L signed pc relative offset from -2048 to 2047
- h absolute code address (call, jmp)
- S immediate value from 0 to 7 (S = s << 4)
- ? use this opcode entry if no parameters, else use next opcode entry
-
- 1001010010001000 clc
- 1001010011011000 clh
- 1001010011111000 cli
- 1001010010101000 cln
- 1001010011001000 cls
- 1001010011101000 clt
- 1001010010111000 clv
- 1001010010011000 clz
- 1001010000001000 sec
- 1001010001011000 seh
- 1001010001111000 sei
- 1001010000101000 sen
- 1001010001001000 ses
- 1001010001101000 set
- 1001010000111000 sev
- 1001010000011000 sez
- 100101001SSS1000 bclr S
- 100101000SSS1000 bset S
- 1001010100001001 icall
- 1001010000001001 ijmp
- 1001010111001000 lpm ?
- 1001000ddddd010+ lpm r,z
- 1001010111011000 elpm ?
- 1001000ddddd011+ elpm r,z
- 0000000000000000 nop
- 1001010100001000 ret
- 1001010100011000 reti
- 1001010110001000 sleep
- 1001010110011000 break
- 1001010110101000 wdr
- 1001010111101000 spm
- 000111rdddddrrrr adc r,r
- 000011rdddddrrrr add r,r
- 001000rdddddrrrr and r,r
- 000101rdddddrrrr cp r,r
- 000001rdddddrrrr cpc r,r
- 000100rdddddrrrr cpse r,r
- 001001rdddddrrrr eor r,r
- 001011rdddddrrrr mov r,r
- 100111rdddddrrrr mul r,r
- 001010rdddddrrrr or r,r
- 000010rdddddrrrr sbc r,r
- 000110rdddddrrrr sub r,r
- 001001rdddddrrrr clr r
- 000011rdddddrrrr lsl r
- 000111rdddddrrrr rol r
- 001000rdddddrrrr tst r
- 0111KKKKddddKKKK andi d,M
- 0111KKKKddddKKKK cbr d,n
- 1110KKKKddddKKKK ldi d,M
- 11101111dddd1111 ser d
- 0110KKKKddddKKKK ori d,M
- 0110KKKKddddKKKK sbr d,M
- 0011KKKKddddKKKK cpi d,M
- 0100KKKKddddKKKK sbci d,M
- 0101KKKKddddKKKK subi d,M
- 1111110rrrrr0sss sbrc r,s
- 1111111rrrrr0sss sbrs r,s
- 1111100ddddd0sss bld r,s
- 1111101ddddd0sss bst r,s
- 10110PPdddddPPPP in r,P
- 10111PPrrrrrPPPP out P,r
- 10010110KKddKKKK adiw w,K
- 10010111KKddKKKK sbiw w,K
- 10011000pppppsss cbi p,s
- 10011010pppppsss sbi p,s
- 10011001pppppsss sbic p,s
- 10011011pppppsss sbis p,s
- 111101lllllll000 brcc l
- 111100lllllll000 brcs l
- 111100lllllll001 breq l
- 111101lllllll100 brge l
- 111101lllllll101 brhc l
- 111100lllllll101 brhs l
- 111101lllllll111 brid l
- 111100lllllll111 brie l
- 111100lllllll000 brlo l
- 111100lllllll100 brlt l
- 111100lllllll010 brmi l
- 111101lllllll001 brne l
- 111101lllllll010 brpl l
- 111101lllllll000 brsh l
- 111101lllllll110 brtc l
- 111100lllllll110 brts l
- 111101lllllll011 brvc l
- 111100lllllll011 brvs l
- 111101lllllllsss brbc s,l
- 111100lllllllsss brbs s,l
- 1101LLLLLLLLLLLL rcall L
- 1100LLLLLLLLLLLL rjmp L
- 1001010hhhhh111h call h
- 1001010hhhhh110h jmp h
- 1001010rrrrr0101 asr r
- 1001010rrrrr0000 com r
- 1001010rrrrr1010 dec r
- 1001010rrrrr0011 inc r
- 1001010rrrrr0110 lsr r
- 1001010rrrrr0001 neg r
- 1001000rrrrr1111 pop r
- 1001001rrrrr1111 push r
- 1001010rrrrr0111 ror r
- 1001010rrrrr0010 swap r
- 00000001ddddrrrr movw v,v
- 00000010ddddrrrr muls d,d
- 000000110ddd0rrr mulsu a,a
- 000000110ddd1rrr fmul a,a
- 000000111ddd0rrr fmuls a,a
- 000000111ddd1rrr fmulsu a,a
- 1001001ddddd0000 sts i,r
- 1001000ddddd0000 lds r,i
- 10o0oo0dddddbooo ldd r,b
- 100!000dddddee-+ ld r,e
- 10o0oo1rrrrrbooo std b,r
- 100!001rrrrree-+ st e,r
- 1001010100011001 eicall
- 1001010000011001 eijmp
-
-
-File: as.info, Node: Blackfin-Dependent, Next: CR16-Dependent, Prev: AVR-Dependent, Up: Machine Dependencies
-
-9.5 Blackfin Dependent Features
-===============================
-
-* Menu:
-
-* Blackfin Options:: Blackfin Options
-* Blackfin Syntax:: Blackfin Syntax
-* Blackfin Directives:: Blackfin Directives
-
-
-File: as.info, Node: Blackfin Options, Next: Blackfin Syntax, Up: Blackfin-Dependent
-
-9.5.1 Options
--------------
-
-`-mcpu=PROCESSOR[-SIREVISION]'
- This option specifies the target processor. The optional
- SIREVISION is not used in assembler. It's here such that GCC can
- easily pass down its `-mcpu=' option. The assembler will issue an
- error message if an attempt is made to assemble an instruction
- which will not execute on the target processor. The following
- processor names are recognized: `bf504', `bf506', `bf512', `bf514',
- `bf516', `bf518', `bf522', `bf523', `bf524', `bf525', `bf526',
- `bf527', `bf531', `bf532', `bf533', `bf534', `bf535' (not
- implemented yet), `bf536', `bf537', `bf538', `bf539', `bf542',
- `bf542m', `bf544', `bf544m', `bf547', `bf547m', `bf548', `bf548m',
- `bf549', `bf549m', `bf561', and `bf592'.
-
-`-mfdpic'
- Assemble for the FDPIC ABI.
-
-`-mno-fdpic'
-`-mnopic'
- Disable -mfdpic.
-
-
-File: as.info, Node: Blackfin Syntax, Next: Blackfin Directives, Prev: Blackfin Options, Up: Blackfin-Dependent
-
-9.5.2 Syntax
-------------
-
-`Special Characters'
- Assembler input is free format and may appear anywhere on the line.
- One instruction may extend across multiple lines or more than one
- instruction may appear on the same line. White space (space, tab,
- comments or newline) may appear anywhere between tokens. A token
- must not have embedded spaces. Tokens include numbers, register
- names, keywords, user identifiers, and also some multicharacter
- special symbols like "+=", "/*" or "||".
-
-`Instruction Delimiting'
- A semicolon must terminate every instruction. Sometimes a complete
- instruction will consist of more than one operation. There are two
- cases where this occurs. The first is when two general operations
- are combined. Normally a comma separates the different parts, as
- in
-
- a0= r3.h * r2.l, a1 = r3.l * r2.h ;
-
- The second case occurs when a general instruction is combined with
- one or two memory references for joint issue. The latter portions
- are set off by a "||" token.
-
- a0 = r3.h * r2.l || r1 = [p3++] || r4 = [i2++];
-
-`Register Names'
- The assembler treats register names and instruction keywords in a
- case insensitive manner. User identifiers are case sensitive.
- Thus, R3.l, R3.L, r3.l and r3.L are all equivalent input to the
- assembler.
-
- Register names are reserved and may not be used as program
- identifiers.
-
- Some operations (such as "Move Register") require a register pair.
- Register pairs are always data registers and are denoted using a
- colon, eg., R3:2. The larger number must be written firsts. Note
- that the hardware only supports odd-even pairs, eg., R7:6, R5:4,
- R3:2, and R1:0.
-
- Some instructions (such as -SP (Push Multiple)) require a group of
- adjacent registers. Adjacent registers are denoted in the syntax
- by the range enclosed in parentheses and separated by a colon,
- eg., (R7:3). Again, the larger number appears first.
-
- Portions of a particular register may be individually specified.
- This is written with a dot (".") following the register name and
- then a letter denoting the desired portion. For 32-bit registers,
- ".H" denotes the most significant ("High") portion. ".L" denotes
- the least-significant portion. The subdivisions of the 40-bit
- registers are described later.
-
-`Accumulators'
- The set of 40-bit registers A1 and A0 that normally contain data
- that is being manipulated. Each accumulator can be accessed in
- four ways.
-
- `one 40-bit register'
- The register will be referred to as A1 or A0.
-
- `one 32-bit register'
- The registers are designated as A1.W or A0.W.
-
- `two 16-bit registers'
- The registers are designated as A1.H, A1.L, A0.H or A0.L.
-
- `one 8-bit register'
- The registers are designated as A1.X or A0.X for the bits that
- extend beyond bit 31.
-
-`Data Registers'
- The set of 32-bit registers (R0, R1, R2, R3, R4, R5, R6 and R7)
- that normally contain data for manipulation. These are
- abbreviated as D-register or Dreg. Data registers can be accessed
- as 32-bit registers or as two independent 16-bit registers. The
- least significant 16 bits of each register is called the "low"
- half and is designated with ".L" following the register name. The
- most significant 16 bits are called the "high" half and is
- designated with ".H" following the name.
-
- R7.L, r2.h, r4.L, R0.H
-
-`Pointer Registers'
- The set of 32-bit registers (P0, P1, P2, P3, P4, P5, SP and FP)
- that normally contain byte addresses of data structures. These are
- abbreviated as P-register or Preg.
-
- p2, p5, fp, sp
-
-`Stack Pointer SP'
- The stack pointer contains the 32-bit address of the last occupied
- byte location in the stack. The stack grows by decrementing the
- stack pointer.
-
-`Frame Pointer FP'
- The frame pointer contains the 32-bit address of the previous frame
- pointer in the stack. It is located at the top of a frame.
-
-`Loop Top'
- LT0 and LT1. These registers contain the 32-bit address of the
- top of a zero overhead loop.
-
-`Loop Count'
- LC0 and LC1. These registers contain the 32-bit counter of the
- zero overhead loop executions.
-
-`Loop Bottom'
- LB0 and LB1. These registers contain the 32-bit address of the
- bottom of a zero overhead loop.
-
-`Index Registers'
- The set of 32-bit registers (I0, I1, I2, I3) that normally contain
- byte addresses of data structures. Abbreviated I-register or Ireg.
-
-`Modify Registers'
- The set of 32-bit registers (M0, M1, M2, M3) that normally contain
- offset values that are added and subracted to one of the index
- registers. Abbreviated as Mreg.
-
-`Length Registers'
- The set of 32-bit registers (L0, L1, L2, L3) that normally contain
- the length in bytes of the circular buffer. Abbreviated as Lreg.
- Clear the Lreg to disable circular addressing for the
- corresponding Ireg.
-
-`Base Registers'
- The set of 32-bit registers (B0, B1, B2, B3) that normally contain
- the base address in bytes of the circular buffer. Abbreviated as
- Breg.
-
-`Floating Point'
- The Blackfin family has no hardware floating point but the .float
- directive generates ieee floating point numbers for use with
- software floating point libraries.
-
-`Blackfin Opcodes'
- For detailed information on the Blackfin machine instruction set,
- see the Blackfin(r) Processor Instruction Set Reference.
-
-
-
-File: as.info, Node: Blackfin Directives, Prev: Blackfin Syntax, Up: Blackfin-Dependent
-
-9.5.3 Directives
-----------------
-
-The following directives are provided for compatibility with the VDSP
-assembler.
-
-`.byte2'
- Initializes a four byte data object.
-
-`.byte4'
- Initializes a two byte data object.
-
-`.db'
- TBD
-
-`.dd'
- TBD
-
-`.dw'
- TBD
-
-`.var'
- Define and initialize a 32 bit data object.
-
-
-File: as.info, Node: CR16-Dependent, Next: CRIS-Dependent, Prev: Blackfin-Dependent, Up: Machine Dependencies
-
-9.6 CR16 Dependent Features
-===========================
-
-* Menu:
-
-* CR16 Operand Qualifiers:: CR16 Machine Operand Qualifiers
-
-
-File: as.info, Node: CR16 Operand Qualifiers, Up: CR16-Dependent
-
-9.6.1 CR16 Operand Qualifiers
------------------------------
-
-The National Semiconductor CR16 target of `as' has a few machine
-dependent operand qualifiers.
-
- Operand expression type qualifier is an optional field in the
-instruction operand, to determines the type of the expression field of
-an operand. The `@' is required. CR16 architecture uses one of the
-following expression qualifiers:
-
-`s'
- - `Specifies expression operand type as small'
-
-`m'
- - `Specifies expression operand type as medium'
-
-`l'
- - `Specifies expression operand type as large'
-
-`c'
- - `Specifies the CR16 Assembler generates a relocation entry for
- the operand, where pc has implied bit, the expression is adjusted
- accordingly. The linker uses the relocation entry to update the
- operand address at link time.'
-
-`got/GOT'
- - `Specifies the CR16 Assembler generates a relocation entry for
- the operand, offset from Global Offset Table. The linker uses this
- relocation entry to update the operand address at link time'
-
-`cgot/cGOT'
- - `Specifies the CompactRISC Assembler generates a relocation
- entry for the operand, where pc has implied bit, the expression is
- adjusted accordingly. The linker uses the relocation entry to
- update the operand address at link time.'
-
- CR16 target operand qualifiers and its size (in bits):
-
-`Immediate Operand'
- - s --- 4 bits
-
-`'
- - m --- 16 bits, for movb and movw instructions.
-
-`'
- - m --- 20 bits, movd instructions.
-
-`'
- - l --- 32 bits
-
-`Absolute Operand'
- - s --- Illegal specifier for this operand.
-
-`'
- - m --- 20 bits, movd instructions.
-
-`Displacement Operand'
- - s --- 8 bits
-
-`'
- - m --- 16 bits
-
-`'
- - l --- 24 bits
-
- For example:
- 1 `movw $_myfun@c,r1'
-
- This loads the address of _myfun, shifted right by 1, into r1.
-
- 2 `movd $_myfun@c,(r2,r1)'
-
- This loads the address of _myfun, shifted right by 1, into register-pair r2-r1.
-
- 3 `_myfun_ptr:'
- `.long _myfun@c'
- `loadd _myfun_ptr, (r1,r0)'
- `jal (r1,r0)'
-
- This .long directive, the address of _myfunc, shifted right by 1 at link time.
-
- 4 `loadd _data1@GOT(r12), (r1,r0)'
-
- This loads the address of _data1, into global offset table (ie GOT) and its offset value from GOT loads into register-pair r2-r1.
-
- 5 `loadd _myfunc@cGOT(r12), (r1,r0)'
-
- This loads the address of _myfun, shifted right by 1, into global offset table (ie GOT) and its offset value from GOT loads into register-pair r1-r0.
-
-
-File: as.info, Node: CRIS-Dependent, Next: D10V-Dependent, Prev: CR16-Dependent, Up: Machine Dependencies
-
-9.7 CRIS Dependent Features
-===========================
-
-* Menu:
-
-* CRIS-Opts:: Command-line Options
-* CRIS-Expand:: Instruction expansion
-* CRIS-Symbols:: Symbols
-* CRIS-Syntax:: Syntax
-
-
-File: as.info, Node: CRIS-Opts, Next: CRIS-Expand, Up: CRIS-Dependent
-
-9.7.1 Command-line Options
---------------------------
-
-The CRIS version of `as' has these machine-dependent command-line
-options.
-
- The format of the generated object files can be either ELF or a.out,
-specified by the command-line options `--emulation=crisaout' and
-`--emulation=criself'. The default is ELF (criself), unless `as' has
-been configured specifically for a.out by using the configuration name
-`cris-axis-aout'.
-
- There are two different link-incompatible ELF object file variants
-for CRIS, for use in environments where symbols are expected to be
-prefixed by a leading `_' character and for environments without such a
-symbol prefix. The variant used for GNU/Linux port has no symbol
-prefix. Which variant to produce is specified by either of the options
-`--underscore' and `--no-underscore'. The default is `--underscore'.
-Since symbols in CRIS a.out objects are expected to have a `_' prefix,
-specifying `--no-underscore' when generating a.out objects is an error.
-Besides the object format difference, the effect of this option is to
-parse register names differently (*note crisnous::). The
-`--no-underscore' option makes a `$' register prefix mandatory.
-
- The option `--pic' must be passed to `as' in order to recognize the
-symbol syntax used for ELF (SVR4 PIC) position-independent-code (*note
-crispic::). This will also affect expansion of instructions. The
-expansion with `--pic' will use PC-relative rather than (slightly
-faster) absolute addresses in those expansions.
-
- The option `--march=ARCHITECTURE' specifies the recognized
-instruction set and recognized register names. It also controls the
-architecture type of the object file. Valid values for ARCHITECTURE
-are:
-`v0_v10'
- All instructions and register names for any architecture variant
- in the set v0...v10 are recognized. This is the default if the
- target is configured as cris-*.
-
-`v10'
- Only instructions and register names for CRIS v10 (as found in
- ETRAX 100 LX) are recognized. This is the default if the target
- is configured as crisv10-*.
-
-`v32'
- Only instructions and register names for CRIS v32 (code name
- Guinness) are recognized. This is the default if the target is
- configured as crisv32-*. This value implies `--no-mul-bug-abort'.
- (A subsequent `--mul-bug-abort' will turn it back on.)
-
-`common_v10_v32'
- Only instructions with register names and addressing modes with
- opcodes common to the v10 and v32 are recognized.
-
- When `-N' is specified, `as' will emit a warning when a 16-bit
-branch instruction is expanded into a 32-bit multiple-instruction
-construct (*note CRIS-Expand::).
-
- Some versions of the CRIS v10, for example in the Etrax 100 LX,
-contain a bug that causes destabilizing memory accesses when a multiply
-instruction is executed with certain values in the first operand just
-before a cache-miss. When the `--mul-bug-abort' command line option is
-active (the default value), `as' will refuse to assemble a file
-containing a multiply instruction at a dangerous offset, one that could
-be the last on a cache-line, or is in a section with insufficient
-alignment. This placement checking does not catch any case where the
-multiply instruction is dangerously placed because it is located in a
-delay-slot. The `--mul-bug-abort' command line option turns off the
-checking.
-
-
-File: as.info, Node: CRIS-Expand, Next: CRIS-Symbols, Prev: CRIS-Opts, Up: CRIS-Dependent
-
-9.7.2 Instruction expansion
----------------------------
-
-`as' will silently choose an instruction that fits the operand size for
-`[register+constant]' operands. For example, the offset `127' in
-`move.d [r3+127],r4' fits in an instruction using a signed-byte offset.
-Similarly, `move.d [r2+32767],r1' will generate an instruction using a
-16-bit offset. For symbolic expressions and constants that do not fit
-in 16 bits including the sign bit, a 32-bit offset is generated.
-
- For branches, `as' will expand from a 16-bit branch instruction into
-a sequence of instructions that can reach a full 32-bit address. Since
-this does not correspond to a single instruction, such expansions can
-optionally be warned about. *Note CRIS-Opts::.
-
- If the operand is found to fit the range, a `lapc' mnemonic will
-translate to a `lapcq' instruction. Use `lapc.d' to force the 32-bit
-`lapc' instruction.
-
- Similarly, the `addo' mnemonic will translate to the shortest
-fitting instruction of `addoq', `addo.w' and `addo.d', when used with a
-operand that is a constant known at assembly time.
-
-
-File: as.info, Node: CRIS-Symbols, Next: CRIS-Syntax, Prev: CRIS-Expand, Up: CRIS-Dependent
-
-9.7.3 Symbols
--------------
-
-Some symbols are defined by the assembler. They're intended to be used
-in conditional assembly, for example:
- .if ..asm.arch.cris.v32
- CODE FOR CRIS V32
- .elseif ..asm.arch.cris.common_v10_v32
- CODE COMMON TO CRIS V32 AND CRIS V10
- .elseif ..asm.arch.cris.v10 | ..asm.arch.cris.any_v0_v10
- CODE FOR V10
- .else
- .error "Code needs to be added here."
- .endif
-
- These symbols are defined in the assembler, reflecting command-line
-options, either when specified or the default. They are always
-defined, to 0 or 1.
-`..asm.arch.cris.any_v0_v10'
- This symbol is non-zero when `--march=v0_v10' is specified or the
- default.
-
-`..asm.arch.cris.common_v10_v32'
- Set according to the option `--march=common_v10_v32'.
-
-`..asm.arch.cris.v10'
- Reflects the option `--march=v10'.
-
-`..asm.arch.cris.v32'
- Corresponds to `--march=v10'.
-
- Speaking of symbols, when a symbol is used in code, it can have a
-suffix modifying its value for use in position-independent code. *Note
-CRIS-Pic::.
-
-
-File: as.info, Node: CRIS-Syntax, Prev: CRIS-Symbols, Up: CRIS-Dependent
-
-9.7.4 Syntax
-------------
-
-There are different aspects of the CRIS assembly syntax.
-
-* Menu:
-
-* CRIS-Chars:: Special Characters
-* CRIS-Pic:: Position-Independent Code Symbols
-* CRIS-Regs:: Register Names
-* CRIS-Pseudos:: Assembler Directives
-
-
-File: as.info, Node: CRIS-Chars, Next: CRIS-Pic, Up: CRIS-Syntax
-
-9.7.4.1 Special Characters
-..........................
-
-The character `#' is a line comment character. It starts a comment if
-and only if it is placed at the beginning of a line.
-
- A `;' character starts a comment anywhere on the line, causing all
-characters up to the end of the line to be ignored.
-
- A `@' character is handled as a line separator equivalent to a
-logical new-line character (except in a comment), so separate
-instructions can be specified on a single line.
-
-
-File: as.info, Node: CRIS-Pic, Next: CRIS-Regs, Prev: CRIS-Chars, Up: CRIS-Syntax
-
-9.7.4.2 Symbols in position-independent code
-............................................
-
-When generating position-independent code (SVR4 PIC) for use in
-cris-axis-linux-gnu or crisv32-axis-linux-gnu shared libraries, symbol
-suffixes are used to specify what kind of run-time symbol lookup will
-be used, expressed in the object as different _relocation types_.
-Usually, all absolute symbol values must be located in a table, the
-_global offset table_, leaving the code position-independent;
-independent of values of global symbols and independent of the address
-of the code. The suffix modifies the value of the symbol, into for
-example an index into the global offset table where the real symbol
-value is entered, or a PC-relative value, or a value relative to the
-start of the global offset table. All symbol suffixes start with the
-character `:' (omitted in the list below). Every symbol use in code or
-a read-only section must therefore have a PIC suffix to enable a useful
-shared library to be created. Usually, these constructs must not be
-used with an additive constant offset as is usually allowed, i.e. no 4
-as in `symbol + 4' is allowed. This restriction is checked at
-link-time, not at assembly-time.
-
-`GOT'
- Attaching this suffix to a symbol in an instruction causes the
- symbol to be entered into the global offset table. The value is a
- 32-bit index for that symbol into the global offset table. The
- name of the corresponding relocation is `R_CRIS_32_GOT'. Example:
- `move.d [$r0+extsym:GOT],$r9'
-
-`GOT16'
- Same as for `GOT', but the value is a 16-bit index into the global
- offset table. The corresponding relocation is `R_CRIS_16_GOT'.
- Example: `move.d [$r0+asymbol:GOT16],$r10'
-
-`PLT'
- This suffix is used for function symbols. It causes a _procedure
- linkage table_, an array of code stubs, to be created at the time
- the shared object is created or linked against, together with a
- global offset table entry. The value is a pc-relative offset to
- the corresponding stub code in the procedure linkage table. This
- arrangement causes the run-time symbol resolver to be called to
- look up and set the value of the symbol the first time the
- function is called (at latest; depending environment variables).
- It is only safe to leave the symbol unresolved this way if all
- references are function calls. The name of the relocation is
- `R_CRIS_32_PLT_PCREL'. Example: `add.d fnname:PLT,$pc'
-
-`PLTG'
- Like PLT, but the value is relative to the beginning of the global
- offset table. The relocation is `R_CRIS_32_PLT_GOTREL'. Example:
- `move.d fnname:PLTG,$r3'
-
-`GOTPLT'
- Similar to `PLT', but the value of the symbol is a 32-bit index
- into the global offset table. This is somewhat of a mix between
- the effect of the `GOT' and the `PLT' suffix; the difference to
- `GOT' is that there will be a procedure linkage table entry
- created, and that the symbol is assumed to be a function entry and
- will be resolved by the run-time resolver as with `PLT'. The
- relocation is `R_CRIS_32_GOTPLT'. Example: `jsr
- [$r0+fnname:GOTPLT]'
-
-`GOTPLT16'
- A variant of `GOTPLT' giving a 16-bit value. Its relocation name
- is `R_CRIS_16_GOTPLT'. Example: `jsr [$r0+fnname:GOTPLT16]'
-
-`GOTOFF'
- This suffix must only be attached to a local symbol, but may be
- used in an expression adding an offset. The value is the address
- of the symbol relative to the start of the global offset table.
- The relocation name is `R_CRIS_32_GOTREL'. Example: `move.d
- [$r0+localsym:GOTOFF],r3'
-
-
-File: as.info, Node: CRIS-Regs, Next: CRIS-Pseudos, Prev: CRIS-Pic, Up: CRIS-Syntax
-
-9.7.4.3 Register names
-......................
-
-A `$' character may always prefix a general or special register name in
-an instruction operand but is mandatory when the option
-`--no-underscore' is specified or when the `.syntax register_prefix'
-directive is in effect (*note crisnous::). Register names are
-case-insensitive.
-
-
-File: as.info, Node: CRIS-Pseudos, Prev: CRIS-Regs, Up: CRIS-Syntax
-
-9.7.4.4 Assembler Directives
-............................
-
-There are a few CRIS-specific pseudo-directives in addition to the
-generic ones. *Note Pseudo Ops::. Constants emitted by
-pseudo-directives are in little-endian order for CRIS. There is no
-support for floating-point-specific directives for CRIS.
-
-`.dword EXPRESSIONS'
- The `.dword' directive is a synonym for `.int', expecting zero or
- more EXPRESSIONS, separated by commas. For each expression, a
- 32-bit little-endian constant is emitted.
-
-`.syntax ARGUMENT'
- The `.syntax' directive takes as ARGUMENT one of the following
- case-sensitive choices.
-
- `no_register_prefix'
- The `.syntax no_register_prefix' directive makes a `$'
- character prefix on all registers optional. It overrides a
- previous setting, including the corresponding effect of the
- option `--no-underscore'. If this directive is used when
- ordinary symbols do not have a `_' character prefix, care
- must be taken to avoid ambiguities whether an operand is a
- register or a symbol; using symbols with names the same as
- general or special registers then invoke undefined behavior.
-
- `register_prefix'
- This directive makes a `$' character prefix on all registers
- mandatory. It overrides a previous setting, including the
- corresponding effect of the option `--underscore'.
-
- `leading_underscore'
- This is an assertion directive, emitting an error if the
- `--no-underscore' option is in effect.
-
- `no_leading_underscore'
- This is the opposite of the `.syntax leading_underscore'
- directive and emits an error if the option `--underscore' is
- in effect.
-
-`.arch ARGUMENT'
- This is an assertion directive, giving an error if the specified
- ARGUMENT is not the same as the specified or default value for the
- `--march=ARCHITECTURE' option (*note march-option::).
-
-
-
-File: as.info, Node: D10V-Dependent, Next: D30V-Dependent, Prev: CRIS-Dependent, Up: Machine Dependencies
-
-9.8 D10V Dependent Features
-===========================
-
-* Menu:
-
-* D10V-Opts:: D10V Options
-* D10V-Syntax:: Syntax
-* D10V-Float:: Floating Point
-* D10V-Opcodes:: Opcodes
-
-
-File: as.info, Node: D10V-Opts, Next: D10V-Syntax, Up: D10V-Dependent
-
-9.8.1 D10V Options
-------------------
-
-The Mitsubishi D10V version of `as' has a few machine dependent options.
-
-`-O'
- The D10V can often execute two sub-instructions in parallel. When
- this option is used, `as' will attempt to optimize its output by
- detecting when instructions can be executed in parallel.
-
-`--nowarnswap'
- To optimize execution performance, `as' will sometimes swap the
- order of instructions. Normally this generates a warning. When
- this option is used, no warning will be generated when
- instructions are swapped.
-
-`--gstabs-packing'
-`--no-gstabs-packing'
- `as' packs adjacent short instructions into a single packed
- instruction. `--no-gstabs-packing' turns instruction packing off if
- `--gstabs' is specified as well; `--gstabs-packing' (the default)
- turns instruction packing on even when `--gstabs' is specified.
-
-
-File: as.info, Node: D10V-Syntax, Next: D10V-Float, Prev: D10V-Opts, Up: D10V-Dependent
-
-9.8.2 Syntax
-------------
-
-The D10V syntax is based on the syntax in Mitsubishi's D10V
-architecture manual. The differences are detailed below.
-
-* Menu:
-
-* D10V-Size:: Size Modifiers
-* D10V-Subs:: Sub-Instructions
-* D10V-Chars:: Special Characters
-* D10V-Regs:: Register Names
-* D10V-Addressing:: Addressing Modes
-* D10V-Word:: @WORD Modifier
-
-
-File: as.info, Node: D10V-Size, Next: D10V-Subs, Up: D10V-Syntax
-
-9.8.2.1 Size Modifiers
-......................
-
-The D10V version of `as' uses the instruction names in the D10V
-Architecture Manual. However, the names in the manual are sometimes
-ambiguous. There are instruction names that can assemble to a short or
-long form opcode. How does the assembler pick the correct form? `as'
-will always pick the smallest form if it can. When dealing with a
-symbol that is not defined yet when a line is being assembled, it will
-always use the long form. If you need to force the assembler to use
-either the short or long form of the instruction, you can append either
-`.s' (short) or `.l' (long) to it. For example, if you are writing an
-assembly program and you want to do a branch to a symbol that is
-defined later in your program, you can write `bra.s foo'. Objdump
-and GDB will always append `.s' or `.l' to instructions which have both
-short and long forms.
-
-
-File: as.info, Node: D10V-Subs, Next: D10V-Chars, Prev: D10V-Size, Up: D10V-Syntax
-
-9.8.2.2 Sub-Instructions
-........................
-
-The D10V assembler takes as input a series of instructions, either
-one-per-line, or in the special two-per-line format described in the
-next section. Some of these instructions will be short-form or
-sub-instructions. These sub-instructions can be packed into a single
-instruction. The assembler will do this automatically. It will also
-detect when it should not pack instructions. For example, when a label
-is defined, the next instruction will never be packaged with the
-previous one. Whenever a branch and link instruction is called, it
-will not be packaged with the next instruction so the return address
-will be valid. Nops are automatically inserted when necessary.
-
- If you do not want the assembler automatically making these
-decisions, you can control the packaging and execution type (parallel
-or sequential) with the special execution symbols described in the next
-section.
-
-
-File: as.info, Node: D10V-Chars, Next: D10V-Regs, Prev: D10V-Subs, Up: D10V-Syntax
-
-9.8.2.3 Special Characters
-..........................
-
-`;' and `#' are the line comment characters. Sub-instructions may be
-executed in order, in reverse-order, or in parallel. Instructions
-listed in the standard one-per-line format will be executed
-sequentially. To specify the executing order, use the following
-symbols:
-`->'
- Sequential with instruction on the left first.
-
-`<-'
- Sequential with instruction on the right first.
-
-`||'
- Parallel
- The D10V syntax allows either one instruction per line, one
-instruction per line with the execution symbol, or two instructions per
-line. For example
-`abs a1 -> abs r0'
- Execute these sequentially. The instruction on the right is in
- the right container and is executed second.
-
-`abs r0 <- abs a1'
- Execute these reverse-sequentially. The instruction on the right
- is in the right container, and is executed first.
-
-`ld2w r2,@r8+ || mac a0,r0,r7'
- Execute these in parallel.
-
-`ld2w r2,@r8+ ||'
-`mac a0,r0,r7'
- Two-line format. Execute these in parallel.
-
-`ld2w r2,@r8+'
-`mac a0,r0,r7'
- Two-line format. Execute these sequentially. Assembler will put
- them in the proper containers.
-
-`ld2w r2,@r8+ ->'
-`mac a0,r0,r7'
- Two-line format. Execute these sequentially. Same as above but
- second instruction will always go into right container.
- Since `$' has no special meaning, you may use it in symbol names.
-
-
-File: as.info, Node: D10V-Regs, Next: D10V-Addressing, Prev: D10V-Chars, Up: D10V-Syntax
-
-9.8.2.4 Register Names
-......................
-
-You can use the predefined symbols `r0' through `r15' to refer to the
-D10V registers. You can also use `sp' as an alias for `r15'. The
-accumulators are `a0' and `a1'. There are special register-pair names
-that may optionally be used in opcodes that require even-numbered
-registers. Register names are not case sensitive.
-
- Register Pairs
-`r0-r1'
-
-`r2-r3'
-
-`r4-r5'
-
-`r6-r7'
-
-`r8-r9'
-
-`r10-r11'
-
-`r12-r13'
-
-`r14-r15'
-
- The D10V also has predefined symbols for these control registers and
-status bits:
-`psw'
- Processor Status Word
-
-`bpsw'
- Backup Processor Status Word
-
-`pc'
- Program Counter
-
-`bpc'
- Backup Program Counter
-
-`rpt_c'
- Repeat Count
-
-`rpt_s'
- Repeat Start address
-
-`rpt_e'
- Repeat End address
-
-`mod_s'
- Modulo Start address
-
-`mod_e'
- Modulo End address
-
-`iba'
- Instruction Break Address
-
-`f0'
- Flag 0
-
-`f1'
- Flag 1
-
-`c'
- Carry flag
-
-
-File: as.info, Node: D10V-Addressing, Next: D10V-Word, Prev: D10V-Regs, Up: D10V-Syntax
-
-9.8.2.5 Addressing Modes
-........................
-
-`as' understands the following addressing modes for the D10V. `RN' in
-the following refers to any of the numbered registers, but _not_ the
-control registers.
-`RN'
- Register direct
-
-`@RN'
- Register indirect
-
-`@RN+'
- Register indirect with post-increment
-
-`@RN-'
- Register indirect with post-decrement
-
-`@-SP'
- Register indirect with pre-decrement
-
-`@(DISP, RN)'
- Register indirect with displacement
-
-`ADDR'
- PC relative address (for branch or rep).
-
-`#IMM'
- Immediate data (the `#' is optional and ignored)
-
-
-File: as.info, Node: D10V-Word, Prev: D10V-Addressing, Up: D10V-Syntax
-
-9.8.2.6 @WORD Modifier
-......................
-
-Any symbol followed by `@word' will be replaced by the symbol's value
-shifted right by 2. This is used in situations such as loading a
-register with the address of a function (or any other code fragment).
-For example, if you want to load a register with the location of the
-function `main' then jump to that function, you could do it as follows:
- ldi r2, main@word
- jmp r2
-
-
-File: as.info, Node: D10V-Float, Next: D10V-Opcodes, Prev: D10V-Syntax, Up: D10V-Dependent
-
-9.8.3 Floating Point
---------------------
-
-The D10V has no hardware floating point, but the `.float' and `.double'
-directives generates IEEE floating-point numbers for compatibility with
-other development tools.
-
-
-File: as.info, Node: D10V-Opcodes, Prev: D10V-Float, Up: D10V-Dependent
-
-9.8.4 Opcodes
--------------
-
-For detailed information on the D10V machine instruction set, see `D10V
-Architecture: A VLIW Microprocessor for Multimedia Applications'
-(Mitsubishi Electric Corp.). `as' implements all the standard D10V
-opcodes. The only changes are those described in the section on size
-modifiers
-
-
-File: as.info, Node: D30V-Dependent, Next: H8/300-Dependent, Prev: D10V-Dependent, Up: Machine Dependencies
-
-9.9 D30V Dependent Features
-===========================
-
-* Menu:
-
-* D30V-Opts:: D30V Options
-* D30V-Syntax:: Syntax
-* D30V-Float:: Floating Point
-* D30V-Opcodes:: Opcodes
-
-
-File: as.info, Node: D30V-Opts, Next: D30V-Syntax, Up: D30V-Dependent
-
-9.9.1 D30V Options
-------------------
-
-The Mitsubishi D30V version of `as' has a few machine dependent options.
-
-`-O'
- The D30V can often execute two sub-instructions in parallel. When
- this option is used, `as' will attempt to optimize its output by
- detecting when instructions can be executed in parallel.
-
-`-n'
- When this option is used, `as' will issue a warning every time it
- adds a nop instruction.
-
-`-N'
- When this option is used, `as' will issue a warning if it needs to
- insert a nop after a 32-bit multiply before a load or 16-bit
- multiply instruction.
-
-
-File: as.info, Node: D30V-Syntax, Next: D30V-Float, Prev: D30V-Opts, Up: D30V-Dependent
-
-9.9.2 Syntax
-------------
-
-The D30V syntax is based on the syntax in Mitsubishi's D30V
-architecture manual. The differences are detailed below.
-
-* Menu:
-
-* D30V-Size:: Size Modifiers
-* D30V-Subs:: Sub-Instructions
-* D30V-Chars:: Special Characters
-* D30V-Guarded:: Guarded Execution
-* D30V-Regs:: Register Names
-* D30V-Addressing:: Addressing Modes
-
-
-File: as.info, Node: D30V-Size, Next: D30V-Subs, Up: D30V-Syntax
-
-9.9.2.1 Size Modifiers
-......................
-
-The D30V version of `as' uses the instruction names in the D30V
-Architecture Manual. However, the names in the manual are sometimes
-ambiguous. There are instruction names that can assemble to a short or
-long form opcode. How does the assembler pick the correct form? `as'
-will always pick the smallest form if it can. When dealing with a
-symbol that is not defined yet when a line is being assembled, it will
-always use the long form. If you need to force the assembler to use
-either the short or long form of the instruction, you can append either
-`.s' (short) or `.l' (long) to it. For example, if you are writing an
-assembly program and you want to do a branch to a symbol that is
-defined later in your program, you can write `bra.s foo'. Objdump and
-GDB will always append `.s' or `.l' to instructions which have both
-short and long forms.
-
-
-File: as.info, Node: D30V-Subs, Next: D30V-Chars, Prev: D30V-Size, Up: D30V-Syntax
-
-9.9.2.2 Sub-Instructions
-........................
-
-The D30V assembler takes as input a series of instructions, either
-one-per-line, or in the special two-per-line format described in the
-next section. Some of these instructions will be short-form or
-sub-instructions. These sub-instructions can be packed into a single
-instruction. The assembler will do this automatically. It will also
-detect when it should not pack instructions. For example, when a label
-is defined, the next instruction will never be packaged with the
-previous one. Whenever a branch and link instruction is called, it
-will not be packaged with the next instruction so the return address
-will be valid. Nops are automatically inserted when necessary.
-
- If you do not want the assembler automatically making these
-decisions, you can control the packaging and execution type (parallel
-or sequential) with the special execution symbols described in the next
-section.
-
-
-File: as.info, Node: D30V-Chars, Next: D30V-Guarded, Prev: D30V-Subs, Up: D30V-Syntax
-
-9.9.2.3 Special Characters
-..........................
-
-`;' and `#' are the line comment characters. Sub-instructions may be
-executed in order, in reverse-order, or in parallel. Instructions
-listed in the standard one-per-line format will be executed
-sequentially unless you use the `-O' option.
-
- To specify the executing order, use the following symbols:
-`->'
- Sequential with instruction on the left first.
-
-`<-'
- Sequential with instruction on the right first.
-
-`||'
- Parallel
-
- The D30V syntax allows either one instruction per line, one
-instruction per line with the execution symbol, or two instructions per
-line. For example
-`abs r2,r3 -> abs r4,r5'
- Execute these sequentially. The instruction on the right is in
- the right container and is executed second.
-
-`abs r2,r3 <- abs r4,r5'
- Execute these reverse-sequentially. The instruction on the right
- is in the right container, and is executed first.
-
-`abs r2,r3 || abs r4,r5'
- Execute these in parallel.
-
-`ldw r2,@(r3,r4) ||'
-`mulx r6,r8,r9'
- Two-line format. Execute these in parallel.
-
-`mulx a0,r8,r9'
-`stw r2,@(r3,r4)'
- Two-line format. Execute these sequentially unless `-O' option is
- used. If the `-O' option is used, the assembler will determine if
- the instructions could be done in parallel (the above two
- instructions can be done in parallel), and if so, emit them as
- parallel instructions. The assembler will put them in the proper
- containers. In the above example, the assembler will put the
- `stw' instruction in left container and the `mulx' instruction in
- the right container.
-
-`stw r2,@(r3,r4) ->'
-`mulx a0,r8,r9'
- Two-line format. Execute the `stw' instruction followed by the
- `mulx' instruction sequentially. The first instruction goes in the
- left container and the second instruction goes into right
- container. The assembler will give an error if the machine
- ordering constraints are violated.
-
-`stw r2,@(r3,r4) <-'
-`mulx a0,r8,r9'
- Same as previous example, except that the `mulx' instruction is
- executed before the `stw' instruction.
-
- Since `$' has no special meaning, you may use it in symbol names.
-
-
-File: as.info, Node: D30V-Guarded, Next: D30V-Regs, Prev: D30V-Chars, Up: D30V-Syntax
-
-9.9.2.4 Guarded Execution
-.........................
-
-`as' supports the full range of guarded execution directives for each
-instruction. Just append the directive after the instruction proper.
-The directives are:
-
-`/tx'
- Execute the instruction if flag f0 is true.
-
-`/fx'
- Execute the instruction if flag f0 is false.
-
-`/xt'
- Execute the instruction if flag f1 is true.
-
-`/xf'
- Execute the instruction if flag f1 is false.
-
-`/tt'
- Execute the instruction if both flags f0 and f1 are true.
-
-`/tf'
- Execute the instruction if flag f0 is true and flag f1 is false.
-
-
-File: as.info, Node: D30V-Regs, Next: D30V-Addressing, Prev: D30V-Guarded, Up: D30V-Syntax
-
-9.9.2.5 Register Names
-......................
-
-You can use the predefined symbols `r0' through `r63' to refer to the
-D30V registers. You can also use `sp' as an alias for `r63' and `link'
-as an alias for `r62'. The accumulators are `a0' and `a1'.
-
- The D30V also has predefined symbols for these control registers and
-status bits:
-`psw'
- Processor Status Word
-
-`bpsw'
- Backup Processor Status Word
-
-`pc'
- Program Counter
-
-`bpc'
- Backup Program Counter
-
-`rpt_c'
- Repeat Count
-
-`rpt_s'
- Repeat Start address
-
-`rpt_e'
- Repeat End address
-
-`mod_s'
- Modulo Start address
-
-`mod_e'
- Modulo End address
-
-`iba'
- Instruction Break Address
-
-`f0'
- Flag 0
-
-`f1'
- Flag 1
-
-`f2'
- Flag 2
-
-`f3'
- Flag 3
-
-`f4'
- Flag 4
-
-`f5'
- Flag 5
-
-`f6'
- Flag 6
-
-`f7'
- Flag 7
-
-`s'
- Same as flag 4 (saturation flag)
-
-`v'
- Same as flag 5 (overflow flag)
-
-`va'
- Same as flag 6 (sticky overflow flag)
-
-`c'
- Same as flag 7 (carry/borrow flag)
-
-`b'
- Same as flag 7 (carry/borrow flag)
-
-
-File: as.info, Node: D30V-Addressing, Prev: D30V-Regs, Up: D30V-Syntax
-
-9.9.2.6 Addressing Modes
-........................
-
-`as' understands the following addressing modes for the D30V. `RN' in
-the following refers to any of the numbered registers, but _not_ the
-control registers.
-`RN'
- Register direct
-
-`@RN'
- Register indirect
-
-`@RN+'
- Register indirect with post-increment
-
-`@RN-'
- Register indirect with post-decrement
-
-`@-SP'
- Register indirect with pre-decrement
-
-`@(DISP, RN)'
- Register indirect with displacement
-
-`ADDR'
- PC relative address (for branch or rep).
-
-`#IMM'
- Immediate data (the `#' is optional and ignored)
-
-
-File: as.info, Node: D30V-Float, Next: D30V-Opcodes, Prev: D30V-Syntax, Up: D30V-Dependent
-
-9.9.3 Floating Point
---------------------
-
-The D30V has no hardware floating point, but the `.float' and `.double'
-directives generates IEEE floating-point numbers for compatibility with
-other development tools.
-
-
-File: as.info, Node: D30V-Opcodes, Prev: D30V-Float, Up: D30V-Dependent
-
-9.9.4 Opcodes
--------------
-
-For detailed information on the D30V machine instruction set, see `D30V
-Architecture: A VLIW Microprocessor for Multimedia Applications'
-(Mitsubishi Electric Corp.). `as' implements all the standard D30V
-opcodes. The only changes are those described in the section on size
-modifiers
-
-
-File: as.info, Node: H8/300-Dependent, Next: HPPA-Dependent, Prev: D30V-Dependent, Up: Machine Dependencies
-
-9.10 H8/300 Dependent Features
-==============================
-
-* Menu:
-
-* H8/300 Options:: Options
-* H8/300 Syntax:: Syntax
-* H8/300 Floating Point:: Floating Point
-* H8/300 Directives:: H8/300 Machine Directives
-* H8/300 Opcodes:: Opcodes
-
-
-File: as.info, Node: H8/300 Options, Next: H8/300 Syntax, Up: H8/300-Dependent
-
-9.10.1 Options
---------------
-
-The Renesas H8/300 version of `as' has one machine-dependent option:
-
-`-h-tick-hex'
- Support H'00 style hex constants in addition to 0x00 style.
-
-
-
-File: as.info, Node: H8/300 Syntax, Next: H8/300 Floating Point, Prev: H8/300 Options, Up: H8/300-Dependent
-
-9.10.2 Syntax
--------------
-
-* Menu:
-
-* H8/300-Chars:: Special Characters
-* H8/300-Regs:: Register Names
-* H8/300-Addressing:: Addressing Modes
-
-
-File: as.info, Node: H8/300-Chars, Next: H8/300-Regs, Up: H8/300 Syntax
-
-9.10.2.1 Special Characters
-...........................
-
-`;' is the line comment character.
-
- `$' can be used instead of a newline to separate statements.
-Therefore _you may not use `$' in symbol names_ on the H8/300.
-
-
-File: as.info, Node: H8/300-Regs, Next: H8/300-Addressing, Prev: H8/300-Chars, Up: H8/300 Syntax
-
-9.10.2.2 Register Names
-.......................
-
-You can use predefined symbols of the form `rNh' and `rNl' to refer to
-the H8/300 registers as sixteen 8-bit general-purpose registers. N is
-a digit from `0' to `7'); for instance, both `r0h' and `r7l' are valid
-register names.
-
- You can also use the eight predefined symbols `rN' to refer to the
-H8/300 registers as 16-bit registers (you must use this form for
-addressing).
-
- On the H8/300H, you can also use the eight predefined symbols `erN'
-(`er0' ... `er7') to refer to the 32-bit general purpose registers.
-
- The two control registers are called `pc' (program counter; a 16-bit
-register, except on the H8/300H where it is 24 bits) and `ccr'
-(condition code register; an 8-bit register). `r7' is used as the
-stack pointer, and can also be called `sp'.
-
-
-File: as.info, Node: H8/300-Addressing, Prev: H8/300-Regs, Up: H8/300 Syntax
-
-9.10.2.3 Addressing Modes
-.........................
-
-as understands the following addressing modes for the H8/300:
-`rN'
- Register direct
-
-`@rN'
- Register indirect
-
-`@(D, rN)'
-`@(D:16, rN)'
-`@(D:24, rN)'
- Register indirect: 16-bit or 24-bit displacement D from register
- N. (24-bit displacements are only meaningful on the H8/300H.)
-
-`@rN+'
- Register indirect with post-increment
-
-`@-rN'
- Register indirect with pre-decrement
-
-``@'AA'
-``@'AA:8'
-``@'AA:16'
-``@'AA:24'
- Absolute address `aa'. (The address size `:24' only makes sense
- on the H8/300H.)
-
-`#XX'
-`#XX:8'
-`#XX:16'
-`#XX:32'
- Immediate data XX. You may specify the `:8', `:16', or `:32' for
- clarity, if you wish; but `as' neither requires this nor uses
- it--the data size required is taken from context.
-
-``@'`@'AA'
-``@'`@'AA:8'
- Memory indirect. You may specify the `:8' for clarity, if you
- wish; but `as' neither requires this nor uses it.
-
-
-File: as.info, Node: H8/300 Floating Point, Next: H8/300 Directives, Prev: H8/300 Syntax, Up: H8/300-Dependent
-
-9.10.3 Floating Point
----------------------
-
-The H8/300 family has no hardware floating point, but the `.float'
-directive generates IEEE floating-point numbers for compatibility with
-other development tools.
-
-
-File: as.info, Node: H8/300 Directives, Next: H8/300 Opcodes, Prev: H8/300 Floating Point, Up: H8/300-Dependent
-
-9.10.4 H8/300 Machine Directives
---------------------------------
-
-`as' has the following machine-dependent directives for the H8/300:
-
-`.h8300h'
- Recognize and emit additional instructions for the H8/300H
- variant, and also make `.int' emit 32-bit numbers rather than the
- usual (16-bit) for the H8/300 family.
-
-`.h8300s'
- Recognize and emit additional instructions for the H8S variant, and
- also make `.int' emit 32-bit numbers rather than the usual (16-bit)
- for the H8/300 family.
-
-`.h8300hn'
- Recognize and emit additional instructions for the H8/300H variant
- in normal mode, and also make `.int' emit 32-bit numbers rather
- than the usual (16-bit) for the H8/300 family.
-
-`.h8300sn'
- Recognize and emit additional instructions for the H8S variant in
- normal mode, and also make `.int' emit 32-bit numbers rather than
- the usual (16-bit) for the H8/300 family.
-
- On the H8/300 family (including the H8/300H) `.word' directives
-generate 16-bit numbers.
-
-
-File: as.info, Node: H8/300 Opcodes, Prev: H8/300 Directives, Up: H8/300-Dependent
-
-9.10.5 Opcodes
---------------
-
-For detailed information on the H8/300 machine instruction set, see
-`H8/300 Series Programming Manual'. For information specific to the
-H8/300H, see `H8/300H Series Programming Manual' (Renesas).
-
- `as' implements all the standard H8/300 opcodes. No additional
-pseudo-instructions are needed on this family.
-
- The following table summarizes the H8/300 opcodes, and their
-arguments. Entries marked `*' are opcodes used only on the H8/300H.
-
- Legend:
- Rs source register
- Rd destination register
- abs absolute address
- imm immediate data
- disp:N N-bit displacement from a register
- pcrel:N N-bit displacement relative to program counter
-
- add.b #imm,rd * andc #imm,ccr
- add.b rs,rd band #imm,rd
- add.w rs,rd band #imm,@rd
- * add.w #imm,rd band #imm,@abs:8
- * add.l rs,rd bra pcrel:8
- * add.l #imm,rd * bra pcrel:16
- adds #imm,rd bt pcrel:8
- addx #imm,rd * bt pcrel:16
- addx rs,rd brn pcrel:8
- and.b #imm,rd * brn pcrel:16
- and.b rs,rd bf pcrel:8
- * and.w rs,rd * bf pcrel:16
- * and.w #imm,rd bhi pcrel:8
- * and.l #imm,rd * bhi pcrel:16
- * and.l rs,rd bls pcrel:8
-
- * bls pcrel:16 bld #imm,rd
- bcc pcrel:8 bld #imm,@rd
- * bcc pcrel:16 bld #imm,@abs:8
- bhs pcrel:8 bnot #imm,rd
- * bhs pcrel:16 bnot #imm,@rd
- bcs pcrel:8 bnot #imm,@abs:8
- * bcs pcrel:16 bnot rs,rd
- blo pcrel:8 bnot rs,@rd
- * blo pcrel:16 bnot rs,@abs:8
- bne pcrel:8 bor #imm,rd
- * bne pcrel:16 bor #imm,@rd
- beq pcrel:8 bor #imm,@abs:8
- * beq pcrel:16 bset #imm,rd
- bvc pcrel:8 bset #imm,@rd
- * bvc pcrel:16 bset #imm,@abs:8
- bvs pcrel:8 bset rs,rd
- * bvs pcrel:16 bset rs,@rd
- bpl pcrel:8 bset rs,@abs:8
- * bpl pcrel:16 bsr pcrel:8
- bmi pcrel:8 bsr pcrel:16
- * bmi pcrel:16 bst #imm,rd
- bge pcrel:8 bst #imm,@rd
- * bge pcrel:16 bst #imm,@abs:8
- blt pcrel:8 btst #imm,rd
- * blt pcrel:16 btst #imm,@rd
- bgt pcrel:8 btst #imm,@abs:8
- * bgt pcrel:16 btst rs,rd
- ble pcrel:8 btst rs,@rd
- * ble pcrel:16 btst rs,@abs:8
- bclr #imm,rd bxor #imm,rd
- bclr #imm,@rd bxor #imm,@rd
- bclr #imm,@abs:8 bxor #imm,@abs:8
- bclr rs,rd cmp.b #imm,rd
- bclr rs,@rd cmp.b rs,rd
- bclr rs,@abs:8 cmp.w rs,rd
- biand #imm,rd cmp.w rs,rd
- biand #imm,@rd * cmp.w #imm,rd
- biand #imm,@abs:8 * cmp.l #imm,rd
- bild #imm,rd * cmp.l rs,rd
- bild #imm,@rd daa rs
- bild #imm,@abs:8 das rs
- bior #imm,rd dec.b rs
- bior #imm,@rd * dec.w #imm,rd
- bior #imm,@abs:8 * dec.l #imm,rd
- bist #imm,rd divxu.b rs,rd
- bist #imm,@rd * divxu.w rs,rd
- bist #imm,@abs:8 * divxs.b rs,rd
- bixor #imm,rd * divxs.w rs,rd
- bixor #imm,@rd eepmov
- bixor #imm,@abs:8 * eepmovw
-
- * exts.w rd mov.w rs,@abs:16
- * exts.l rd * mov.l #imm,rd
- * extu.w rd * mov.l rs,rd
- * extu.l rd * mov.l @rs,rd
- inc rs * mov.l @(disp:16,rs),rd
- * inc.w #imm,rd * mov.l @(disp:24,rs),rd
- * inc.l #imm,rd * mov.l @rs+,rd
- jmp @rs * mov.l @abs:16,rd
- jmp abs * mov.l @abs:24,rd
- jmp @@abs:8 * mov.l rs,@rd
- jsr @rs * mov.l rs,@(disp:16,rd)
- jsr abs * mov.l rs,@(disp:24,rd)
- jsr @@abs:8 * mov.l rs,@-rd
- ldc #imm,ccr * mov.l rs,@abs:16
- ldc rs,ccr * mov.l rs,@abs:24
- * ldc @abs:16,ccr movfpe @abs:16,rd
- * ldc @abs:24,ccr movtpe rs,@abs:16
- * ldc @(disp:16,rs),ccr mulxu.b rs,rd
- * ldc @(disp:24,rs),ccr * mulxu.w rs,rd
- * ldc @rs+,ccr * mulxs.b rs,rd
- * ldc @rs,ccr * mulxs.w rs,rd
- * mov.b @(disp:24,rs),rd neg.b rs
- * mov.b rs,@(disp:24,rd) * neg.w rs
- mov.b @abs:16,rd * neg.l rs
- mov.b rs,rd nop
- mov.b @abs:8,rd not.b rs
- mov.b rs,@abs:8 * not.w rs
- mov.b rs,rd * not.l rs
- mov.b #imm,rd or.b #imm,rd
- mov.b @rs,rd or.b rs,rd
- mov.b @(disp:16,rs),rd * or.w #imm,rd
- mov.b @rs+,rd * or.w rs,rd
- mov.b @abs:8,rd * or.l #imm,rd
- mov.b rs,@rd * or.l rs,rd
- mov.b rs,@(disp:16,rd) orc #imm,ccr
- mov.b rs,@-rd pop.w rs
- mov.b rs,@abs:8 * pop.l rs
- mov.w rs,@rd push.w rs
- * mov.w @(disp:24,rs),rd * push.l rs
- * mov.w rs,@(disp:24,rd) rotl.b rs
- * mov.w @abs:24,rd * rotl.w rs
- * mov.w rs,@abs:24 * rotl.l rs
- mov.w rs,rd rotr.b rs
- mov.w #imm,rd * rotr.w rs
- mov.w @rs,rd * rotr.l rs
- mov.w @(disp:16,rs),rd rotxl.b rs
- mov.w @rs+,rd * rotxl.w rs
- mov.w @abs:16,rd * rotxl.l rs
- mov.w rs,@(disp:16,rd) rotxr.b rs
- mov.w rs,@-rd * rotxr.w rs
-
- * rotxr.l rs * stc ccr,@(disp:24,rd)
- bpt * stc ccr,@-rd
- rte * stc ccr,@abs:16
- rts * stc ccr,@abs:24
- shal.b rs sub.b rs,rd
- * shal.w rs sub.w rs,rd
- * shal.l rs * sub.w #imm,rd
- shar.b rs * sub.l rs,rd
- * shar.w rs * sub.l #imm,rd
- * shar.l rs subs #imm,rd
- shll.b rs subx #imm,rd
- * shll.w rs subx rs,rd
- * shll.l rs * trapa #imm
- shlr.b rs xor #imm,rd
- * shlr.w rs xor rs,rd
- * shlr.l rs * xor.w #imm,rd
- sleep * xor.w rs,rd
- stc ccr,rd * xor.l #imm,rd
- * stc ccr,@rs * xor.l rs,rd
- * stc ccr,@(disp:16,rd) xorc #imm,ccr
-
- Four H8/300 instructions (`add', `cmp', `mov', `sub') are defined
-with variants using the suffixes `.b', `.w', and `.l' to specify the
-size of a memory operand. `as' supports these suffixes, but does not
-require them; since one of the operands is always a register, `as' can
-deduce the correct size.
-
- For example, since `r0' refers to a 16-bit register,
- mov r0,@foo
-is equivalent to
- mov.w r0,@foo
-
- If you use the size suffixes, `as' issues a warning when the suffix
-and the register size do not match.
-
-
-File: as.info, Node: HPPA-Dependent, Next: ESA/390-Dependent, Prev: H8/300-Dependent, Up: Machine Dependencies
-
-9.11 HPPA Dependent Features
-============================
-
-* Menu:
-
-* HPPA Notes:: Notes
-* HPPA Options:: Options
-* HPPA Syntax:: Syntax
-* HPPA Floating Point:: Floating Point
-* HPPA Directives:: HPPA Machine Directives
-* HPPA Opcodes:: Opcodes
-
-
-File: as.info, Node: HPPA Notes, Next: HPPA Options, Up: HPPA-Dependent
-
-9.11.1 Notes
-------------
-
-As a back end for GNU CC `as' has been throughly tested and should work
-extremely well. We have tested it only minimally on hand written
-assembly code and no one has tested it much on the assembly output from
-the HP compilers.
-
- The format of the debugging sections has changed since the original
-`as' port (version 1.3X) was released; therefore, you must rebuild all
-HPPA objects and libraries with the new assembler so that you can debug
-the final executable.
-
- The HPPA `as' port generates a small subset of the relocations
-available in the SOM and ELF object file formats. Additional relocation
-support will be added as it becomes necessary.
-
-
-File: as.info, Node: HPPA Options, Next: HPPA Syntax, Prev: HPPA Notes, Up: HPPA-Dependent
-
-9.11.2 Options
---------------
-
-`as' has no machine-dependent command-line options for the HPPA.
-
-
-File: as.info, Node: HPPA Syntax, Next: HPPA Floating Point, Prev: HPPA Options, Up: HPPA-Dependent
-
-9.11.3 Syntax
--------------
-
-The assembler syntax closely follows the HPPA instruction set reference
-manual; assembler directives and general syntax closely follow the HPPA
-assembly language reference manual, with a few noteworthy differences.
-
- First, a colon may immediately follow a label definition. This is
-simply for compatibility with how most assembly language programmers
-write code.
-
- Some obscure expression parsing problems may affect hand written
-code which uses the `spop' instructions, or code which makes significant
-use of the `!' line separator.
-
- `as' is much less forgiving about missing arguments and other
-similar oversights than the HP assembler. `as' notifies you of missing
-arguments as syntax errors; this is regarded as a feature, not a bug.
-
- Finally, `as' allows you to use an external symbol without
-explicitly importing the symbol. _Warning:_ in the future this will be
-an error for HPPA targets.
-
- Special characters for HPPA targets include:
-
- `;' is the line comment character.
-
- `!' can be used instead of a newline to separate statements.
-
- Since `$' has no special meaning, you may use it in symbol names.
-
-
-File: as.info, Node: HPPA Floating Point, Next: HPPA Directives, Prev: HPPA Syntax, Up: HPPA-Dependent
-
-9.11.4 Floating Point
----------------------
-
-The HPPA family uses IEEE floating-point numbers.
-
-
-File: as.info, Node: HPPA Directives, Next: HPPA Opcodes, Prev: HPPA Floating Point, Up: HPPA-Dependent
-
-9.11.5 HPPA Assembler Directives
---------------------------------
-
-`as' for the HPPA supports many additional directives for compatibility
-with the native assembler. This section describes them only briefly.
-For detailed information on HPPA-specific assembler directives, see
-`HP9000 Series 800 Assembly Language Reference Manual' (HP 92432-90001).
-
- `as' does _not_ support the following assembler directives described
-in the HP manual:
-
- .endm .liston
- .enter .locct
- .leave .macro
- .listoff
-
- Beyond those implemented for compatibility, `as' supports one
-additional assembler directive for the HPPA: `.param'. It conveys
-register argument locations for static functions. Its syntax closely
-follows the `.export' directive.
-
- These are the additional directives in `as' for the HPPA:
-
-`.block N'
-`.blockz N'
- Reserve N bytes of storage, and initialize them to zero.
-
-`.call'
- Mark the beginning of a procedure call. Only the special case
- with _no arguments_ is allowed.
-
-`.callinfo [ PARAM=VALUE, ... ] [ FLAG, ... ]'
- Specify a number of parameters and flags that define the
- environment for a procedure.
-
- PARAM may be any of `frame' (frame size), `entry_gr' (end of
- general register range), `entry_fr' (end of float register range),
- `entry_sr' (end of space register range).
-
- The values for FLAG are `calls' or `caller' (proc has
- subroutines), `no_calls' (proc does not call subroutines),
- `save_rp' (preserve return pointer), `save_sp' (proc preserves
- stack pointer), `no_unwind' (do not unwind this proc), `hpux_int'
- (proc is interrupt routine).
-
-`.code'
- Assemble into the standard section called `$TEXT$', subsection
- `$CODE$'.
-
-`.copyright "STRING"'
- In the SOM object format, insert STRING into the object code,
- marked as a copyright string.
-
-`.copyright "STRING"'
- In the ELF object format, insert STRING into the object code,
- marked as a version string.
-
-`.enter'
- Not yet supported; the assembler rejects programs containing this
- directive.
-
-`.entry'
- Mark the beginning of a procedure.
-
-`.exit'
- Mark the end of a procedure.
-
-`.export NAME [ ,TYP ] [ ,PARAM=R ]'
- Make a procedure NAME available to callers. TYP, if present, must
- be one of `absolute', `code' (ELF only, not SOM), `data', `entry',
- `data', `entry', `millicode', `plabel', `pri_prog', or `sec_prog'.
-
- PARAM, if present, provides either relocation information for the
- procedure arguments and result, or a privilege level. PARAM may be
- `argwN' (where N ranges from `0' to `3', and indicates one of four
- one-word arguments); `rtnval' (the procedure's result); or
- `priv_lev' (privilege level). For arguments or the result, R
- specifies how to relocate, and must be one of `no' (not
- relocatable), `gr' (argument is in general register), `fr' (in
- floating point register), or `fu' (upper half of float register).
- For `priv_lev', R is an integer.
-
-`.half N'
- Define a two-byte integer constant N; synonym for the portable
- `as' directive `.short'.
-
-`.import NAME [ ,TYP ]'
- Converse of `.export'; make a procedure available to call. The
- arguments use the same conventions as the first two arguments for
- `.export'.
-
-`.label NAME'
- Define NAME as a label for the current assembly location.
-
-`.leave'
- Not yet supported; the assembler rejects programs containing this
- directive.
-
-`.origin LC'
- Advance location counter to LC. Synonym for the `as' portable
- directive `.org'.
-
-`.param NAME [ ,TYP ] [ ,PARAM=R ]'
- Similar to `.export', but used for static procedures.
-
-`.proc'
- Use preceding the first statement of a procedure.
-
-`.procend'
- Use following the last statement of a procedure.
-
-`LABEL .reg EXPR'
- Synonym for `.equ'; define LABEL with the absolute expression EXPR
- as its value.
-
-`.space SECNAME [ ,PARAMS ]'
- Switch to section SECNAME, creating a new section by that name if
- necessary. You may only use PARAMS when creating a new section,
- not when switching to an existing one. SECNAME may identify a
- section by number rather than by name.
-
- If specified, the list PARAMS declares attributes of the section,
- identified by keywords. The keywords recognized are `spnum=EXP'
- (identify this section by the number EXP, an absolute expression),
- `sort=EXP' (order sections according to this sort key when linking;
- EXP is an absolute expression), `unloadable' (section contains no
- loadable data), `notdefined' (this section defined elsewhere), and
- `private' (data in this section not available to other programs).
-
-`.spnum SECNAM'
- Allocate four bytes of storage, and initialize them with the
- section number of the section named SECNAM. (You can define the
- section number with the HPPA `.space' directive.)
-
-`.string "STR"'
- Copy the characters in the string STR to the object file. *Note
- Strings: Strings, for information on escape sequences you can use
- in `as' strings.
-
- _Warning!_ The HPPA version of `.string' differs from the usual
- `as' definition: it does _not_ write a zero byte after copying STR.
-
-`.stringz "STR"'
- Like `.string', but appends a zero byte after copying STR to object
- file.
-
-`.subspa NAME [ ,PARAMS ]'
-`.nsubspa NAME [ ,PARAMS ]'
- Similar to `.space', but selects a subsection NAME within the
- current section. You may only specify PARAMS when you create a
- subsection (in the first instance of `.subspa' for this NAME).
-
- If specified, the list PARAMS declares attributes of the
- subsection, identified by keywords. The keywords recognized are
- `quad=EXPR' ("quadrant" for this subsection), `align=EXPR'
- (alignment for beginning of this subsection; a power of two),
- `access=EXPR' (value for "access rights" field), `sort=EXPR'
- (sorting order for this subspace in link), `code_only' (subsection
- contains only code), `unloadable' (subsection cannot be loaded
- into memory), `comdat' (subsection is comdat), `common'
- (subsection is common block), `dup_comm' (subsection may have
- duplicate names), or `zero' (subsection is all zeros, do not write
- in object file).
-
- `.nsubspa' always creates a new subspace with the given name, even
- if one with the same name already exists.
-
- `comdat', `common' and `dup_comm' can be used to implement various
- flavors of one-only support when using the SOM linker. The SOM
- linker only supports specific combinations of these flags. The
- details are not documented. A brief description is provided here.
-
- `comdat' provides a form of linkonce support. It is useful for
- both code and data subspaces. A `comdat' subspace has a key symbol
- marked by the `is_comdat' flag or `ST_COMDAT'. Only the first
- subspace for any given key is selected. The key symbol becomes
- universal in shared links. This is similar to the behavior of
- `secondary_def' symbols.
-
- `common' provides Fortran named common support. It is only useful
- for data subspaces. Symbols with the flag `is_common' retain this
- flag in shared links. Referencing a `is_common' symbol in a shared
- library from outside the library doesn't work. Thus, `is_common'
- symbols must be output whenever they are needed.
-
- `common' and `dup_comm' together provide Cobol common support.
- The subspaces in this case must all be the same length.
- Otherwise, this support is similar to the Fortran common support.
-
- `dup_comm' by itself provides a type of one-only support for code.
- Only the first `dup_comm' subspace is selected. There is a rather
- complex algorithm to compare subspaces. Code symbols marked with
- the `dup_common' flag are hidden. This support was intended for
- "C++ duplicate inlines".
-
- A simplified technique is used to mark the flags of symbols based
- on the flags of their subspace. A symbol with the scope
- SS_UNIVERSAL and type ST_ENTRY, ST_CODE or ST_DATA is marked with
- the corresponding settings of `comdat', `common' and `dup_comm'
- from the subspace, respectively. This avoids having to introduce
- additional directives to mark these symbols. The HP assembler
- sets `is_common' from `common'. However, it doesn't set the
- `dup_common' from `dup_comm'. It doesn't have `comdat' support.
-
-`.version "STR"'
- Write STR as version identifier in object code.
-
-
-File: as.info, Node: HPPA Opcodes, Prev: HPPA Directives, Up: HPPA-Dependent
-
-9.11.6 Opcodes
---------------
-
-For detailed information on the HPPA machine instruction set, see
-`PA-RISC Architecture and Instruction Set Reference Manual' (HP
-09740-90039).
-
-
-File: as.info, Node: ESA/390-Dependent, Next: i386-Dependent, Prev: HPPA-Dependent, Up: Machine Dependencies
-
-9.12 ESA/390 Dependent Features
-===============================
-
-* Menu:
-
-* ESA/390 Notes:: Notes
-* ESA/390 Options:: Options
-* ESA/390 Syntax:: Syntax
-* ESA/390 Floating Point:: Floating Point
-* ESA/390 Directives:: ESA/390 Machine Directives
-* ESA/390 Opcodes:: Opcodes
-
-
-File: as.info, Node: ESA/390 Notes, Next: ESA/390 Options, Up: ESA/390-Dependent
-
-9.12.1 Notes
-------------
-
-The ESA/390 `as' port is currently intended to be a back-end for the
-GNU CC compiler. It is not HLASM compatible, although it does support
-a subset of some of the HLASM directives. The only supported binary
-file format is ELF; none of the usual MVS/VM/OE/USS object file
-formats, such as ESD or XSD, are supported.
-
- When used with the GNU CC compiler, the ESA/390 `as' will produce
-correct, fully relocated, functional binaries, and has been used to
-compile and execute large projects. However, many aspects should still
-be considered experimental; these include shared library support,
-dynamically loadable objects, and any relocation other than the 31-bit
-relocation.
-
-
-File: as.info, Node: ESA/390 Options, Next: ESA/390 Syntax, Prev: ESA/390 Notes, Up: ESA/390-Dependent
-
-9.12.2 Options
---------------
-
-`as' has no machine-dependent command-line options for the ESA/390.
-
-
-File: as.info, Node: ESA/390 Syntax, Next: ESA/390 Floating Point, Prev: ESA/390 Options, Up: ESA/390-Dependent
-
-9.12.3 Syntax
--------------
-
-The opcode/operand syntax follows the ESA/390 Principles of Operation
-manual; assembler directives and general syntax are loosely based on the
-prevailing AT&T/SVR4/ELF/Solaris style notation. HLASM-style directives
-are _not_ supported for the most part, with the exception of those
-described herein.
-
- A leading dot in front of directives is optional, and the case of
-directives is ignored; thus for example, .using and USING have the same
-effect.
-
- A colon may immediately follow a label definition. This is simply
-for compatibility with how most assembly language programmers write
-code.
-
- `#' is the line comment character.
-
- `;' can be used instead of a newline to separate statements.
-
- Since `$' has no special meaning, you may use it in symbol names.
-
- Registers can be given the symbolic names r0..r15, fp0, fp2, fp4,
-fp6. By using thesse symbolic names, `as' can detect simple syntax
-errors. The name rarg or r.arg is a synonym for r11, rtca or r.tca for
-r12, sp, r.sp, dsa r.dsa for r13, lr or r.lr for r14, rbase or r.base
-for r3 and rpgt or r.pgt for r4.
-
- `*' is the current location counter. Unlike `.' it is always
-relative to the last USING directive. Note that this means that
-expressions cannot use multiplication, as any occurrence of `*' will be
-interpreted as a location counter.
-
- All labels are relative to the last USING. Thus, branches to a label
-always imply the use of base+displacement.
-
- Many of the usual forms of address constants / address literals are
-supported. Thus,
- .using *,r3
- L r15,=A(some_routine)
- LM r6,r7,=V(some_longlong_extern)
- A r1,=F'12'
- AH r0,=H'42'
- ME r6,=E'3.1416'
- MD r6,=D'3.14159265358979'
- O r6,=XL4'cacad0d0'
- .ltorg
- should all behave as expected: that is, an entry in the literal pool
-will be created (or reused if it already exists), and the instruction
-operands will be the displacement into the literal pool using the
-current base register (as last declared with the `.using' directive).
-
-
-File: as.info, Node: ESA/390 Floating Point, Next: ESA/390 Directives, Prev: ESA/390 Syntax, Up: ESA/390-Dependent
-
-9.12.4 Floating Point
----------------------
-
-The assembler generates only IEEE floating-point numbers. The older
-floating point formats are not supported.
-
-
-File: as.info, Node: ESA/390 Directives, Next: ESA/390 Opcodes, Prev: ESA/390 Floating Point, Up: ESA/390-Dependent
-
-9.12.5 ESA/390 Assembler Directives
------------------------------------
-
-`as' for the ESA/390 supports all of the standard ELF/SVR4 assembler
-directives that are documented in the main part of this documentation.
-Several additional directives are supported in order to implement the
-ESA/390 addressing model. The most important of these are `.using' and
-`.ltorg'
-
- These are the additional directives in `as' for the ESA/390:
-
-`.dc'
- A small subset of the usual DC directive is supported.
-
-`.drop REGNO'
- Stop using REGNO as the base register. The REGNO must have been
- previously declared with a `.using' directive in the same section
- as the current section.
-
-`.ebcdic STRING'
- Emit the EBCDIC equivalent of the indicated string. The emitted
- string will be null terminated. Note that the directives
- `.string' etc. emit ascii strings by default.
-
-`EQU'
- The standard HLASM-style EQU directive is not supported; however,
- the standard `as' directive .equ can be used to the same effect.
-
-`.ltorg'
- Dump the literal pool accumulated so far; begin a new literal pool.
- The literal pool will be written in the current section; in order
- to generate correct assembly, a `.using' must have been previously
- specified in the same section.
-
-`.using EXPR,REGNO'
- Use REGNO as the base register for all subsequent RX, RS, and SS
- form instructions. The EXPR will be evaluated to obtain the base
- address; usually, EXPR will merely be `*'.
-
- This assembler allows two `.using' directives to be simultaneously
- outstanding, one in the `.text' section, and one in another section
- (typically, the `.data' section). This feature allows dynamically
- loaded objects to be implemented in a relatively straightforward
- way. A `.using' directive must always be specified in the `.text'
- section; this will specify the base register that will be used for
- branches in the `.text' section. A second `.using' may be
- specified in another section; this will specify the base register
- that is used for non-label address literals. When a second
- `.using' is specified, then the subsequent `.ltorg' must be put in
- the same section; otherwise an error will result.
-
- Thus, for example, the following code uses `r3' to address branch
- targets and `r4' to address the literal pool, which has been
- written to the `.data' section. The is, the constants
- `=A(some_routine)', `=H'42'' and `=E'3.1416'' will all appear in
- the `.data' section.
-
- .data
- .using LITPOOL,r4
- .text
- BASR r3,0
- .using *,r3
- B START
- .long LITPOOL
- START:
- L r4,4(,r3)
- L r15,=A(some_routine)
- LTR r15,r15
- BNE LABEL
- AH r0,=H'42'
- LABEL:
- ME r6,=E'3.1416'
- .data
- LITPOOL:
- .ltorg
-
- Note that this dual-`.using' directive semantics extends and is
- not compatible with HLASM semantics. Note that this assembler
- directive does not support the full range of HLASM semantics.
-
-
-
-File: as.info, Node: ESA/390 Opcodes, Prev: ESA/390 Directives, Up: ESA/390-Dependent
-
-9.12.6 Opcodes
---------------
-
-For detailed information on the ESA/390 machine instruction set, see
-`ESA/390 Principles of Operation' (IBM Publication Number DZ9AR004).
-
-
-File: as.info, Node: i386-Dependent, Next: i860-Dependent, Prev: ESA/390-Dependent, Up: Machine Dependencies
-
-9.13 80386 Dependent Features
-=============================
-
- The i386 version `as' supports both the original Intel 386
-architecture in both 16 and 32-bit mode as well as AMD x86-64
-architecture extending the Intel architecture to 64-bits.
-
-* Menu:
-
-* i386-Options:: Options
-* i386-Directives:: X86 specific directives
-* i386-Syntax:: AT&T Syntax versus Intel Syntax
-* i386-Mnemonics:: Instruction Naming
-* i386-Regs:: Register Naming
-* i386-Prefixes:: Instruction Prefixes
-* i386-Memory:: Memory References
-* i386-Jumps:: Handling of Jump Instructions
-* i386-Float:: Floating Point
-* i386-SIMD:: Intel's MMX and AMD's 3DNow! SIMD Operations
-* i386-LWP:: AMD's Lightweight Profiling Instructions
-* i386-16bit:: Writing 16-bit Code
-* i386-Arch:: Specifying an x86 CPU architecture
-* i386-Bugs:: AT&T Syntax bugs
-* i386-Notes:: Notes
-
-
-File: as.info, Node: i386-Options, Next: i386-Directives, Up: i386-Dependent
-
-9.13.1 Options
---------------
-
-The i386 version of `as' has a few machine dependent options:
-
-`--32 | --64'
- Select the word size, either 32 bits or 64 bits. Selecting 32-bit
- implies Intel i386 architecture, while 64-bit implies AMD x86-64
- architecture.
-
- These options are only available with the ELF object file format,
- and require that the necessary BFD support has been included (on a
- 32-bit platform you have to add -enable-64-bit-bfd to configure
- enable 64-bit usage and use x86-64 as target platform).
-
-`-n'
- By default, x86 GAS replaces multiple nop instructions used for
- alignment within code sections with multi-byte nop instructions
- such as leal 0(%esi,1),%esi. This switch disables the
- optimization.
-
-`--divide'
- On SVR4-derived platforms, the character `/' is treated as a
- comment character, which means that it cannot be used in
- expressions. The `--divide' option turns `/' into a normal
- character. This does not disable `/' at the beginning of a line
- starting a comment, or affect using `#' for starting a comment.
-
-`-march=CPU[+EXTENSION...]'
- This option specifies the target processor. The assembler will
- issue an error message if an attempt is made to assemble an
- instruction which will not execute on the target processor. The
- following processor names are recognized: `i8086', `i186', `i286',
- `i386', `i486', `i586', `i686', `pentium', `pentiumpro',
- `pentiumii', `pentiumiii', `pentium4', `prescott', `nocona',
- `core', `core2', `corei7', `l1om', `k6', `k6_2', `athlon',
- `opteron', `k8', `amdfam10', `bdver1', `generic32' and `generic64'.
-
- In addition to the basic instruction set, the assembler can be
- told to accept various extension mnemonics. For example,
- `-march=i686+sse4+vmx' extends I686 with SSE4 and VMX. The
- following extensions are currently supported: `8087', `287', `387',
- `no87', `mmx', `nommx', `sse', `sse2', `sse3', `ssse3', `sse4.1',
- `sse4.2', `sse4', `nosse', `avx', `noavx', `vmx', `smx', `xsave',
- `xsaveopt', `aes', `pclmul', `fsgsbase', `rdrnd', `f16c', `fma',
- `movbe', `ept', `clflush', `lwp', `fma4', `xop', `syscall',
- `rdtscp', `3dnow', `3dnowa', `sse4a', `sse5', `svme', `abm' and
- `padlock'. Note that rather than extending a basic instruction
- set, the extension mnemonics starting with `no' revoke the
- respective functionality.
-
- When the `.arch' directive is used with `-march', the `.arch'
- directive will take precedent.
-
-`-mtune=CPU'
- This option specifies a processor to optimize for. When used in
- conjunction with the `-march' option, only instructions of the
- processor specified by the `-march' option will be generated.
-
- Valid CPU values are identical to the processor list of
- `-march=CPU'.
-
-`-msse2avx'
- This option specifies that the assembler should encode SSE
- instructions with VEX prefix.
-
-`-msse-check=NONE'
-`-msse-check=WARNING'
-`-msse-check=ERROR'
- These options control if the assembler should check SSE
- intructions. `-msse-check=NONE' will make the assembler not to
- check SSE instructions, which is the default.
- `-msse-check=WARNING' will make the assembler issue a warning for
- any SSE intruction. `-msse-check=ERROR' will make the assembler
- issue an error for any SSE intruction.
-
-`-mavxscalar=128'
-`-mavxscalar=256'
- This options control how the assembler should encode scalar AVX
- instructions. `-mavxscalar=128' will encode scalar AVX
- instructions with 128bit vector length, which is the default.
- `-mavxscalar=256' will encode scalar AVX instructions with 256bit
- vector length.
-
-`-mmnemonic=ATT'
-`-mmnemonic=INTEL'
- This option specifies instruction mnemonic for matching
- instructions. The `.att_mnemonic' and `.intel_mnemonic'
- directives will take precedent.
-
-`-msyntax=ATT'
-`-msyntax=INTEL'
- This option specifies instruction syntax when processing
- instructions. The `.att_syntax' and `.intel_syntax' directives
- will take precedent.
-
-`-mnaked-reg'
- This opetion specifies that registers don't require a `%' prefix.
- The `.att_syntax' and `.intel_syntax' directives will take
- precedent.
-
-
-
-File: as.info, Node: i386-Directives, Next: i386-Syntax, Prev: i386-Options, Up: i386-Dependent
-
-9.13.2 x86 specific Directives
-------------------------------
-
-`.lcomm SYMBOL , LENGTH[, ALIGNMENT]'
- Reserve LENGTH (an absolute expression) bytes for a local common
- denoted by SYMBOL. The section and value of SYMBOL are those of
- the new local common. The addresses are allocated in the bss
- section, so that at run-time the bytes start off zeroed. Since
- SYMBOL is not declared global, it is normally not visible to `ld'.
- The optional third parameter, ALIGNMENT, specifies the desired
- alignment of the symbol in the bss section.
-
- This directive is only available for COFF based x86 targets.
-
-
-
-File: as.info, Node: i386-Syntax, Next: i386-Mnemonics, Prev: i386-Directives, Up: i386-Dependent
-
-9.13.3 AT&T Syntax versus Intel Syntax
---------------------------------------
-
-`as' now supports assembly using Intel assembler syntax.
-`.intel_syntax' selects Intel mode, and `.att_syntax' switches back to
-the usual AT&T mode for compatibility with the output of `gcc'. Either
-of these directives may have an optional argument, `prefix', or
-`noprefix' specifying whether registers require a `%' prefix. AT&T
-System V/386 assembler syntax is quite different from Intel syntax. We
-mention these differences because almost all 80386 documents use Intel
-syntax. Notable differences between the two syntaxes are:
-
- * AT&T immediate operands are preceded by `$'; Intel immediate
- operands are undelimited (Intel `push 4' is AT&T `pushl $4').
- AT&T register operands are preceded by `%'; Intel register operands
- are undelimited. AT&T absolute (as opposed to PC relative)
- jump/call operands are prefixed by `*'; they are undelimited in
- Intel syntax.
-
- * AT&T and Intel syntax use the opposite order for source and
- destination operands. Intel `add eax, 4' is `addl $4, %eax'. The
- `source, dest' convention is maintained for compatibility with
- previous Unix assemblers. Note that `bound', `invlpga', and
- instructions with 2 immediate operands, such as the `enter'
- instruction, do _not_ have reversed order. *note i386-Bugs::.
-
- * In AT&T syntax the size of memory operands is determined from the
- last character of the instruction mnemonic. Mnemonic suffixes of
- `b', `w', `l' and `q' specify byte (8-bit), word (16-bit), long
- (32-bit) and quadruple word (64-bit) memory references. Intel
- syntax accomplishes this by prefixing memory operands (_not_ the
- instruction mnemonics) with `byte ptr', `word ptr', `dword ptr'
- and `qword ptr'. Thus, Intel `mov al, byte ptr FOO' is `movb FOO,
- %al' in AT&T syntax.
-
- In 64-bit code, `movabs' can be used to encode the `mov'
- instruction with the 64-bit displacement or immediate operand.
-
- * Immediate form long jumps and calls are `lcall/ljmp $SECTION,
- $OFFSET' in AT&T syntax; the Intel syntax is `call/jmp far
- SECTION:OFFSET'. Also, the far return instruction is `lret
- $STACK-ADJUST' in AT&T syntax; Intel syntax is `ret far
- STACK-ADJUST'.
-
- * The AT&T assembler does not provide support for multiple section
- programs. Unix style systems expect all programs to be single
- sections.
-
-
-File: as.info, Node: i386-Mnemonics, Next: i386-Regs, Prev: i386-Syntax, Up: i386-Dependent
-
-9.13.4 Instruction Naming
--------------------------
-
-Instruction mnemonics are suffixed with one character modifiers which
-specify the size of operands. The letters `b', `w', `l' and `q'
-specify byte, word, long and quadruple word operands. If no suffix is
-specified by an instruction then `as' tries to fill in the missing
-suffix based on the destination register operand (the last one by
-convention). Thus, `mov %ax, %bx' is equivalent to `movw %ax, %bx';
-also, `mov $1, %bx' is equivalent to `movw $1, bx'. Note that this is
-incompatible with the AT&T Unix assembler which assumes that a missing
-mnemonic suffix implies long operand size. (This incompatibility does
-not affect compiler output since compilers always explicitly specify
-the mnemonic suffix.)
-
- Almost all instructions have the same names in AT&T and Intel format.
-There are a few exceptions. The sign extend and zero extend
-instructions need two sizes to specify them. They need a size to
-sign/zero extend _from_ and a size to zero extend _to_. This is
-accomplished by using two instruction mnemonic suffixes in AT&T syntax.
-Base names for sign extend and zero extend are `movs...' and `movz...'
-in AT&T syntax (`movsx' and `movzx' in Intel syntax). The instruction
-mnemonic suffixes are tacked on to this base name, the _from_ suffix
-before the _to_ suffix. Thus, `movsbl %al, %edx' is AT&T syntax for
-"move sign extend _from_ %al _to_ %edx." Possible suffixes, thus, are
-`bl' (from byte to long), `bw' (from byte to word), `wl' (from word to
-long), `bq' (from byte to quadruple word), `wq' (from word to quadruple
-word), and `lq' (from long to quadruple word).
-
- Different encoding options can be specified via optional mnemonic
-suffix. `.s' suffix swaps 2 register operands in encoding when moving
-from one register to another. `.d32' suffix forces 32bit displacement
-in encoding.
-
- The Intel-syntax conversion instructions
-
- * `cbw' -- sign-extend byte in `%al' to word in `%ax',
-
- * `cwde' -- sign-extend word in `%ax' to long in `%eax',
-
- * `cwd' -- sign-extend word in `%ax' to long in `%dx:%ax',
-
- * `cdq' -- sign-extend dword in `%eax' to quad in `%edx:%eax',
-
- * `cdqe' -- sign-extend dword in `%eax' to quad in `%rax' (x86-64
- only),
-
- * `cqo' -- sign-extend quad in `%rax' to octuple in `%rdx:%rax'
- (x86-64 only),
-
-are called `cbtw', `cwtl', `cwtd', `cltd', `cltq', and `cqto' in AT&T
-naming. `as' accepts either naming for these instructions.
-
- Far call/jump instructions are `lcall' and `ljmp' in AT&T syntax,
-but are `call far' and `jump far' in Intel convention.
-
-9.13.5 AT&T Mnemonic versus Intel Mnemonic
-------------------------------------------
-
-`as' supports assembly using Intel mnemonic. `.intel_mnemonic' selects
-Intel mnemonic with Intel syntax, and `.att_mnemonic' switches back to
-the usual AT&T mnemonic with AT&T syntax for compatibility with the
-output of `gcc'. Several x87 instructions, `fadd', `fdiv', `fdivp',
-`fdivr', `fdivrp', `fmul', `fsub', `fsubp', `fsubr' and `fsubrp', are
-implemented in AT&T System V/386 assembler with different mnemonics
-from those in Intel IA32 specification. `gcc' generates those
-instructions with AT&T mnemonic.
-
-
-File: as.info, Node: i386-Regs, Next: i386-Prefixes, Prev: i386-Mnemonics, Up: i386-Dependent
-
-9.13.6 Register Naming
-----------------------
-
-Register operands are always prefixed with `%'. The 80386 registers
-consist of
-
- * the 8 32-bit registers `%eax' (the accumulator), `%ebx', `%ecx',
- `%edx', `%edi', `%esi', `%ebp' (the frame pointer), and `%esp'
- (the stack pointer).
-
- * the 8 16-bit low-ends of these: `%ax', `%bx', `%cx', `%dx', `%di',
- `%si', `%bp', and `%sp'.
-
- * the 8 8-bit registers: `%ah', `%al', `%bh', `%bl', `%ch', `%cl',
- `%dh', and `%dl' (These are the high-bytes and low-bytes of `%ax',
- `%bx', `%cx', and `%dx')
-
- * the 6 section registers `%cs' (code section), `%ds' (data
- section), `%ss' (stack section), `%es', `%fs', and `%gs'.
-
- * the 3 processor control registers `%cr0', `%cr2', and `%cr3'.
-
- * the 6 debug registers `%db0', `%db1', `%db2', `%db3', `%db6', and
- `%db7'.
-
- * the 2 test registers `%tr6' and `%tr7'.
-
- * the 8 floating point register stack `%st' or equivalently
- `%st(0)', `%st(1)', `%st(2)', `%st(3)', `%st(4)', `%st(5)',
- `%st(6)', and `%st(7)'. These registers are overloaded by 8 MMX
- registers `%mm0', `%mm1', `%mm2', `%mm3', `%mm4', `%mm5', `%mm6'
- and `%mm7'.
-
- * the 8 SSE registers registers `%xmm0', `%xmm1', `%xmm2', `%xmm3',
- `%xmm4', `%xmm5', `%xmm6' and `%xmm7'.
-
- The AMD x86-64 architecture extends the register set by:
-
- * enhancing the 8 32-bit registers to 64-bit: `%rax' (the
- accumulator), `%rbx', `%rcx', `%rdx', `%rdi', `%rsi', `%rbp' (the
- frame pointer), `%rsp' (the stack pointer)
-
- * the 8 extended registers `%r8'-`%r15'.
-
- * the 8 32-bit low ends of the extended registers: `%r8d'-`%r15d'
-
- * the 8 16-bit low ends of the extended registers: `%r8w'-`%r15w'
-
- * the 8 8-bit low ends of the extended registers: `%r8b'-`%r15b'
-
- * the 4 8-bit registers: `%sil', `%dil', `%bpl', `%spl'.
-
- * the 8 debug registers: `%db8'-`%db15'.
-
- * the 8 SSE registers: `%xmm8'-`%xmm15'.
-
-
-File: as.info, Node: i386-Prefixes, Next: i386-Memory, Prev: i386-Regs, Up: i386-Dependent
-
-9.13.7 Instruction Prefixes
----------------------------
-
-Instruction prefixes are used to modify the following instruction. They
-are used to repeat string instructions, to provide section overrides, to
-perform bus lock operations, and to change operand and address sizes.
-(Most instructions that normally operate on 32-bit operands will use
-16-bit operands if the instruction has an "operand size" prefix.)
-Instruction prefixes are best written on the same line as the
-instruction they act upon. For example, the `scas' (scan string)
-instruction is repeated with:
-
- repne scas %es:(%edi),%al
-
- You may also place prefixes on the lines immediately preceding the
-instruction, but this circumvents checks that `as' does with prefixes,
-and will not work with all prefixes.
-
- Here is a list of instruction prefixes:
-
- * Section override prefixes `cs', `ds', `ss', `es', `fs', `gs'.
- These are automatically added by specifying using the
- SECTION:MEMORY-OPERAND form for memory references.
-
- * Operand/Address size prefixes `data16' and `addr16' change 32-bit
- operands/addresses into 16-bit operands/addresses, while `data32'
- and `addr32' change 16-bit ones (in a `.code16' section) into
- 32-bit operands/addresses. These prefixes _must_ appear on the
- same line of code as the instruction they modify. For example, in
- a 16-bit `.code16' section, you might write:
-
- addr32 jmpl *(%ebx)
-
- * The bus lock prefix `lock' inhibits interrupts during execution of
- the instruction it precedes. (This is only valid with certain
- instructions; see a 80386 manual for details).
-
- * The wait for coprocessor prefix `wait' waits for the coprocessor to
- complete the current instruction. This should never be needed for
- the 80386/80387 combination.
-
- * The `rep', `repe', and `repne' prefixes are added to string
- instructions to make them repeat `%ecx' times (`%cx' times if the
- current address size is 16-bits).
-
- * The `rex' family of prefixes is used by x86-64 to encode
- extensions to i386 instruction set. The `rex' prefix has four
- bits -- an operand size overwrite (`64') used to change operand
- size from 32-bit to 64-bit and X, Y and Z extensions bits used to
- extend the register set.
-
- You may write the `rex' prefixes directly. The `rex64xyz'
- instruction emits `rex' prefix with all the bits set. By omitting
- the `64', `x', `y' or `z' you may write other prefixes as well.
- Normally, there is no need to write the prefixes explicitly, since
- gas will automatically generate them based on the instruction
- operands.
-
-
-File: as.info, Node: i386-Memory, Next: i386-Jumps, Prev: i386-Prefixes, Up: i386-Dependent
-
-9.13.8 Memory References
-------------------------
-
-An Intel syntax indirect memory reference of the form
-
- SECTION:[BASE + INDEX*SCALE + DISP]
-
-is translated into the AT&T syntax
-
- SECTION:DISP(BASE, INDEX, SCALE)
-
-where BASE and INDEX are the optional 32-bit base and index registers,
-DISP is the optional displacement, and SCALE, taking the values 1, 2,
-4, and 8, multiplies INDEX to calculate the address of the operand. If
-no SCALE is specified, SCALE is taken to be 1. SECTION specifies the
-optional section register for the memory operand, and may override the
-default section register (see a 80386 manual for section register
-defaults). Note that section overrides in AT&T syntax _must_ be
-preceded by a `%'. If you specify a section override which coincides
-with the default section register, `as' does _not_ output any section
-register override prefixes to assemble the given instruction. Thus,
-section overrides can be specified to emphasize which section register
-is used for a given memory operand.
-
- Here are some examples of Intel and AT&T style memory references:
-
-AT&T: `-4(%ebp)', Intel: `[ebp - 4]'
- BASE is `%ebp'; DISP is `-4'. SECTION is missing, and the default
- section is used (`%ss' for addressing with `%ebp' as the base
- register). INDEX, SCALE are both missing.
-
-AT&T: `foo(,%eax,4)', Intel: `[foo + eax*4]'
- INDEX is `%eax' (scaled by a SCALE 4); DISP is `foo'. All other
- fields are missing. The section register here defaults to `%ds'.
-
-AT&T: `foo(,1)'; Intel `[foo]'
- This uses the value pointed to by `foo' as a memory operand. Note
- that BASE and INDEX are both missing, but there is only _one_ `,'.
- This is a syntactic exception.
-
-AT&T: `%gs:foo'; Intel `gs:foo'
- This selects the contents of the variable `foo' with section
- register SECTION being `%gs'.
-
- Absolute (as opposed to PC relative) call and jump operands must be
-prefixed with `*'. If no `*' is specified, `as' always chooses PC
-relative addressing for jump/call labels.
-
- Any instruction that has a memory operand, but no register operand,
-_must_ specify its size (byte, word, long, or quadruple) with an
-instruction mnemonic suffix (`b', `w', `l' or `q', respectively).
-
- The x86-64 architecture adds an RIP (instruction pointer relative)
-addressing. This addressing mode is specified by using `rip' as a base
-register. Only constant offsets are valid. For example:
-
-AT&T: `1234(%rip)', Intel: `[rip + 1234]'
- Points to the address 1234 bytes past the end of the current
- instruction.
-
-AT&T: `symbol(%rip)', Intel: `[rip + symbol]'
- Points to the `symbol' in RIP relative way, this is shorter than
- the default absolute addressing.
-
- Other addressing modes remain unchanged in x86-64 architecture,
-except registers used are 64-bit instead of 32-bit.
-
-
-File: as.info, Node: i386-Jumps, Next: i386-Float, Prev: i386-Memory, Up: i386-Dependent
-
-9.13.9 Handling of Jump Instructions
-------------------------------------
-
-Jump instructions are always optimized to use the smallest possible
-displacements. This is accomplished by using byte (8-bit) displacement
-jumps whenever the target is sufficiently close. If a byte displacement
-is insufficient a long displacement is used. We do not support word
-(16-bit) displacement jumps in 32-bit mode (i.e. prefixing the jump
-instruction with the `data16' instruction prefix), since the 80386
-insists upon masking `%eip' to 16 bits after the word displacement is
-added. (See also *note i386-Arch::)
-
- Note that the `jcxz', `jecxz', `loop', `loopz', `loope', `loopnz'
-and `loopne' instructions only come in byte displacements, so that if
-you use these instructions (`gcc' does not use them) you may get an
-error message (and incorrect code). The AT&T 80386 assembler tries to
-get around this problem by expanding `jcxz foo' to
-
- jcxz cx_zero
- jmp cx_nonzero
- cx_zero: jmp foo
- cx_nonzero:
-
-
-File: as.info, Node: i386-Float, Next: i386-SIMD, Prev: i386-Jumps, Up: i386-Dependent
-
-9.13.10 Floating Point
-----------------------
-
-All 80387 floating point types except packed BCD are supported. (BCD
-support may be added without much difficulty). These data types are
-16-, 32-, and 64- bit integers, and single (32-bit), double (64-bit),
-and extended (80-bit) precision floating point. Each supported type
-has an instruction mnemonic suffix and a constructor associated with
-it. Instruction mnemonic suffixes specify the operand's data type.
-Constructors build these data types into memory.
-
- * Floating point constructors are `.float' or `.single', `.double',
- and `.tfloat' for 32-, 64-, and 80-bit formats. These correspond
- to instruction mnemonic suffixes `s', `l', and `t'. `t' stands for
- 80-bit (ten byte) real. The 80387 only supports this format via
- the `fldt' (load 80-bit real to stack top) and `fstpt' (store
- 80-bit real and pop stack) instructions.
-
- * Integer constructors are `.word', `.long' or `.int', and `.quad'
- for the 16-, 32-, and 64-bit integer formats. The corresponding
- instruction mnemonic suffixes are `s' (single), `l' (long), and
- `q' (quad). As with the 80-bit real format, the 64-bit `q' format
- is only present in the `fildq' (load quad integer to stack top)
- and `fistpq' (store quad integer and pop stack) instructions.
-
- Register to register operations should not use instruction mnemonic
-suffixes. `fstl %st, %st(1)' will give a warning, and be assembled as
-if you wrote `fst %st, %st(1)', since all register to register
-operations use 80-bit floating point operands. (Contrast this with
-`fstl %st, mem', which converts `%st' from 80-bit to 64-bit floating
-point format, then stores the result in the 4 byte location `mem')
-
-
-File: as.info, Node: i386-SIMD, Next: i386-LWP, Prev: i386-Float, Up: i386-Dependent
-
-9.13.11 Intel's MMX and AMD's 3DNow! SIMD Operations
-----------------------------------------------------
-
-`as' supports Intel's MMX instruction set (SIMD instructions for
-integer data), available on Intel's Pentium MMX processors and Pentium
-II processors, AMD's K6 and K6-2 processors, Cyrix' M2 processor, and
-probably others. It also supports AMD's 3DNow! instruction set (SIMD
-instructions for 32-bit floating point data) available on AMD's K6-2
-processor and possibly others in the future.
-
- Currently, `as' does not support Intel's floating point SIMD, Katmai
-(KNI).
-
- The eight 64-bit MMX operands, also used by 3DNow!, are called
-`%mm0', `%mm1', ... `%mm7'. They contain eight 8-bit integers, four
-16-bit integers, two 32-bit integers, one 64-bit integer, or two 32-bit
-floating point values. The MMX registers cannot be used at the same
-time as the floating point stack.
-
- See Intel and AMD documentation, keeping in mind that the operand
-order in instructions is reversed from the Intel syntax.
-
-
-File: as.info, Node: i386-LWP, Next: i386-16bit, Prev: i386-SIMD, Up: i386-Dependent
-
-9.13.12 AMD's Lightweight Profiling Instructions
-------------------------------------------------
-
-`as' supports AMD's Lightweight Profiling (LWP) instruction set,
-available on AMD's Family 15h (Orochi) processors.
-
- LWP enables applications to collect and manage performance data, and
-react to performance events. The collection of performance data
-requires no context switches. LWP runs in the context of a thread and
-so several counters can be used independently across multiple threads.
-LWP can be used in both 64-bit and legacy 32-bit modes.
-
- For detailed information on the LWP instruction set, see the `AMD
-Lightweight Profiling Specification' available at Lightweight Profiling
-Specification (http://developer.amd.com/cpu/LWP).
-
-
-File: as.info, Node: i386-16bit, Next: i386-Arch, Prev: i386-LWP, Up: i386-Dependent
-
-9.13.13 Writing 16-bit Code
----------------------------
-
-While `as' normally writes only "pure" 32-bit i386 code or 64-bit
-x86-64 code depending on the default configuration, it also supports
-writing code to run in real mode or in 16-bit protected mode code
-segments. To do this, put a `.code16' or `.code16gcc' directive before
-the assembly language instructions to be run in 16-bit mode. You can
-switch `as' to writing 32-bit code with the `.code32' directive or
-64-bit code with the `.code64' directive.
-
- `.code16gcc' provides experimental support for generating 16-bit
-code from gcc, and differs from `.code16' in that `call', `ret',
-`enter', `leave', `push', `pop', `pusha', `popa', `pushf', and `popf'
-instructions default to 32-bit size. This is so that the stack pointer
-is manipulated in the same way over function calls, allowing access to
-function parameters at the same stack offsets as in 32-bit mode.
-`.code16gcc' also automatically adds address size prefixes where
-necessary to use the 32-bit addressing modes that gcc generates.
-
- The code which `as' generates in 16-bit mode will not necessarily
-run on a 16-bit pre-80386 processor. To write code that runs on such a
-processor, you must refrain from using _any_ 32-bit constructs which
-require `as' to output address or operand size prefixes.
-
- Note that writing 16-bit code instructions by explicitly specifying a
-prefix or an instruction mnemonic suffix within a 32-bit code section
-generates different machine instructions than those generated for a
-16-bit code segment. In a 32-bit code section, the following code
-generates the machine opcode bytes `66 6a 04', which pushes the value
-`4' onto the stack, decrementing `%esp' by 2.
-
- pushw $4
-
- The same code in a 16-bit code section would generate the machine
-opcode bytes `6a 04' (i.e., without the operand size prefix), which is
-correct since the processor default operand size is assumed to be 16
-bits in a 16-bit code section.
-
-
-File: as.info, Node: i386-Bugs, Next: i386-Notes, Prev: i386-Arch, Up: i386-Dependent
-
-9.13.14 AT&T Syntax bugs
-------------------------
-
-The UnixWare assembler, and probably other AT&T derived ix86 Unix
-assemblers, generate floating point instructions with reversed source
-and destination registers in certain cases. Unfortunately, gcc and
-possibly many other programs use this reversed syntax, so we're stuck
-with it.
-
- For example
-
- fsub %st,%st(3)
- results in `%st(3)' being updated to `%st - %st(3)' rather than the
-expected `%st(3) - %st'. This happens with all the non-commutative
-arithmetic floating point operations with two register operands where
-the source register is `%st' and the destination register is `%st(i)'.
-
-
-File: as.info, Node: i386-Arch, Next: i386-Bugs, Prev: i386-16bit, Up: i386-Dependent
-
-9.13.15 Specifying CPU Architecture
------------------------------------
-
-`as' may be told to assemble for a particular CPU (sub-)architecture
-with the `.arch CPU_TYPE' directive. This directive enables a warning
-when gas detects an instruction that is not supported on the CPU
-specified. The choices for CPU_TYPE are:
-
-`i8086' `i186' `i286' `i386'
-`i486' `i586' `i686' `pentium'
-`pentiumpro' `pentiumii' `pentiumiii' `pentium4'
-`prescott' `nocona' `core' `core2'
-`corei7' `l1om'
-`k6' `k6_2' `athlon' `k8'
-`amdfam10' `bdver1'
-`generic32' `generic64'
-`.mmx' `.sse' `.sse2' `.sse3'
-`.ssse3' `.sse4.1' `.sse4.2' `.sse4'
-`.avx' `.vmx' `.smx' `.ept'
-`.clflush' `.movbe' `.xsave' `.xsaveopt'
-`.aes' `.pclmul' `.fma' `.fsgsbase'
-`.rdrnd' `.f16c'
-`.3dnow' `.3dnowa' `.sse4a' `.sse5'
-`.syscall' `.rdtscp' `.svme' `.abm'
-`.lwp' `.fma4' `.xop'
-`.padlock'
-
- Apart from the warning, there are only two other effects on `as'
-operation; Firstly, if you specify a CPU other than `i486', then shift
-by one instructions such as `sarl $1, %eax' will automatically use a
-two byte opcode sequence. The larger three byte opcode sequence is
-used on the 486 (and when no architecture is specified) because it
-executes faster on the 486. Note that you can explicitly request the
-two byte opcode by writing `sarl %eax'. Secondly, if you specify
-`i8086', `i186', or `i286', _and_ `.code16' or `.code16gcc' then byte
-offset conditional jumps will be promoted when necessary to a two
-instruction sequence consisting of a conditional jump of the opposite
-sense around an unconditional jump to the target.
-
- Following the CPU architecture (but not a sub-architecture, which
-are those starting with a dot), you may specify `jumps' or `nojumps' to
-control automatic promotion of conditional jumps. `jumps' is the
-default, and enables jump promotion; All external jumps will be of the
-long variety, and file-local jumps will be promoted as necessary.
-(*note i386-Jumps::) `nojumps' leaves external conditional jumps as
-byte offset jumps, and warns about file-local conditional jumps that
-`as' promotes. Unconditional jumps are treated as for `jumps'.
-
- For example
-
- .arch i8086,nojumps
-
-
-File: as.info, Node: i386-Notes, Prev: i386-Bugs, Up: i386-Dependent
-
-9.13.16 Notes
--------------
-
-There is some trickery concerning the `mul' and `imul' instructions
-that deserves mention. The 16-, 32-, 64- and 128-bit expanding
-multiplies (base opcode `0xf6'; extension 4 for `mul' and 5 for `imul')
-can be output only in the one operand form. Thus, `imul %ebx, %eax'
-does _not_ select the expanding multiply; the expanding multiply would
-clobber the `%edx' register, and this would confuse `gcc' output. Use
-`imul %ebx' to get the 64-bit product in `%edx:%eax'.
-
- We have added a two operand form of `imul' when the first operand is
-an immediate mode expression and the second operand is a register.
-This is just a shorthand, so that, multiplying `%eax' by 69, for
-example, can be done with `imul $69, %eax' rather than `imul $69, %eax,
-%eax'.
-
-
-File: as.info, Node: i860-Dependent, Next: i960-Dependent, Prev: i386-Dependent, Up: Machine Dependencies
-
-9.14 Intel i860 Dependent Features
-==================================
-
-* Menu:
-
-* Notes-i860:: i860 Notes
-* Options-i860:: i860 Command-line Options
-* Directives-i860:: i860 Machine Directives
-* Opcodes for i860:: i860 Opcodes
-
-
-File: as.info, Node: Notes-i860, Next: Options-i860, Up: i860-Dependent
-
-9.14.1 i860 Notes
------------------
-
-This is a fairly complete i860 assembler which is compatible with the
-UNIX System V/860 Release 4 assembler. However, it does not currently
-support SVR4 PIC (i.e., `@GOT, @GOTOFF, @PLT').
-
- Like the SVR4/860 assembler, the output object format is ELF32.
-Currently, this is the only supported object format. If there is
-sufficient interest, other formats such as COFF may be implemented.
-
- Both the Intel and AT&T/SVR4 syntaxes are supported, with the latter
-being the default. One difference is that AT&T syntax requires the '%'
-prefix on register names while Intel syntax does not. Another
-difference is in the specification of relocatable expressions. The
-Intel syntax is `ha%expression' whereas the SVR4 syntax is
-`[expression]@ha' (and similarly for the "l" and "h" selectors).
-
-
-File: as.info, Node: Options-i860, Next: Directives-i860, Prev: Notes-i860, Up: i860-Dependent
-
-9.14.2 i860 Command-line Options
---------------------------------
-
-9.14.2.1 SVR4 compatibility options
-...................................
-
-`-V'
- Print assembler version.
-
-`-Qy'
- Ignored.
-
-`-Qn'
- Ignored.
-
-9.14.2.2 Other options
-......................
-
-`-EL'
- Select little endian output (this is the default).
-
-`-EB'
- Select big endian output. Note that the i860 always reads
- instructions as little endian data, so this option only effects
- data and not instructions.
-
-`-mwarn-expand'
- Emit a warning message if any pseudo-instruction expansions
- occurred. For example, a `or' instruction with an immediate
- larger than 16-bits will be expanded into two instructions. This
- is a very undesirable feature to rely on, so this flag can help
- detect any code where it happens. One use of it, for instance, has
- been to find and eliminate any place where `gcc' may emit these
- pseudo-instructions.
-
-`-mxp'
- Enable support for the i860XP instructions and control registers.
- By default, this option is disabled so that only the base
- instruction set (i.e., i860XR) is supported.
-
-`-mintel-syntax'
- The i860 assembler defaults to AT&T/SVR4 syntax. This option
- enables the Intel syntax.
-
-
-File: as.info, Node: Directives-i860, Next: Opcodes for i860, Prev: Options-i860, Up: i860-Dependent
-
-9.14.3 i860 Machine Directives
-------------------------------
-
-`.dual'
- Enter dual instruction mode. While this directive is supported, the
- preferred way to use dual instruction mode is to explicitly code
- the dual bit with the `d.' prefix.
-
-`.enddual'
- Exit dual instruction mode. While this directive is supported, the
- preferred way to use dual instruction mode is to explicitly code
- the dual bit with the `d.' prefix.
-
-`.atmp'
- Change the temporary register used when expanding pseudo
- operations. The default register is `r31'.
-
- The `.dual', `.enddual', and `.atmp' directives are available only
-in the Intel syntax mode.
-
- Both syntaxes allow for the standard `.align' directive. However,
-the Intel syntax additionally allows keywords for the alignment
-parameter: "`.align type'", where `type' is one of `.short', `.long',
-`.quad', `.single', `.double' representing alignments of 2, 4, 16, 4,
-and 8, respectively.
-
-
-File: as.info, Node: Opcodes for i860, Prev: Directives-i860, Up: i860-Dependent
-
-9.14.4 i860 Opcodes
--------------------
-
-All of the Intel i860XR and i860XP machine instructions are supported.
-Please see either _i860 Microprocessor Programmer's Reference Manual_
-or _i860 Microprocessor Architecture_ for more information.
-
-9.14.4.1 Other instruction support (pseudo-instructions)
-........................................................
-
-For compatibility with some other i860 assemblers, a number of
-pseudo-instructions are supported. While these are supported, they are
-a very undesirable feature that should be avoided - in particular, when
-they result in an expansion to multiple actual i860 instructions. Below
-are the pseudo-instructions that result in expansions.
- * Load large immediate into general register:
-
- The pseudo-instruction `mov imm,%rn' (where the immediate does not
- fit within a signed 16-bit field) will be expanded into:
- orh large_imm@h,%r0,%rn
- or large_imm@l,%rn,%rn
-
- * Load/store with relocatable address expression:
-
- For example, the pseudo-instruction `ld.b addr_exp(%rx),%rn' will
- be expanded into:
- orh addr_exp@ha,%rx,%r31
- ld.l addr_exp@l(%r31),%rn
-
- The analogous expansions apply to `ld.x, st.x, fld.x, pfld.x,
- fst.x', and `pst.x' as well.
-
- * Signed large immediate with add/subtract:
-
- If any of the arithmetic operations `adds, addu, subs, subu' are
- used with an immediate larger than 16-bits (signed), then they
- will be expanded. For instance, the pseudo-instruction `adds
- large_imm,%rx,%rn' expands to:
- orh large_imm@h,%r0,%r31
- or large_imm@l,%r31,%r31
- adds %r31,%rx,%rn
-
- * Unsigned large immediate with logical operations:
-
- Logical operations (`or, andnot, or, xor') also result in
- expansions. The pseudo-instruction `or large_imm,%rx,%rn' results
- in:
- orh large_imm@h,%rx,%r31
- or large_imm@l,%r31,%rn
-
- Similarly for the others, except for `and' which expands to:
- andnot (-1 - large_imm)@h,%rx,%r31
- andnot (-1 - large_imm)@l,%r31,%rn
-
-
-File: as.info, Node: i960-Dependent, Next: IA-64-Dependent, Prev: i860-Dependent, Up: Machine Dependencies
-
-9.15 Intel 80960 Dependent Features
-===================================
-
-* Menu:
-
-* Options-i960:: i960 Command-line Options
-* Floating Point-i960:: Floating Point
-* Directives-i960:: i960 Machine Directives
-* Opcodes for i960:: i960 Opcodes
-
-
-File: as.info, Node: Options-i960, Next: Floating Point-i960, Up: i960-Dependent
-
-9.15.1 i960 Command-line Options
---------------------------------
-
-`-ACA | -ACA_A | -ACB | -ACC | -AKA | -AKB | -AKC | -AMC'
- Select the 80960 architecture. Instructions or features not
- supported by the selected architecture cause fatal errors.
-
- `-ACA' is equivalent to `-ACA_A'; `-AKC' is equivalent to `-AMC'.
- Synonyms are provided for compatibility with other tools.
-
- If you do not specify any of these options, `as' generates code
- for any instruction or feature that is supported by _some_ version
- of the 960 (even if this means mixing architectures!). In
- principle, `as' attempts to deduce the minimal sufficient
- processor type if none is specified; depending on the object code
- format, the processor type may be recorded in the object file. If
- it is critical that the `as' output match a specific architecture,
- specify that architecture explicitly.
-
-`-b'
- Add code to collect information about conditional branches taken,
- for later optimization using branch prediction bits. (The
- conditional branch instructions have branch prediction bits in the
- CA, CB, and CC architectures.) If BR represents a conditional
- branch instruction, the following represents the code generated by
- the assembler when `-b' is specified:
-
- call INCREMENT ROUTINE
- .word 0 # pre-counter
- Label: BR
- call INCREMENT ROUTINE
- .word 0 # post-counter
-
- The counter following a branch records the number of times that
- branch was _not_ taken; the difference between the two counters is
- the number of times the branch _was_ taken.
-
- A table of every such `Label' is also generated, so that the
- external postprocessor `gbr960' (supplied by Intel) can locate all
- the counters. This table is always labeled `__BRANCH_TABLE__';
- this is a local symbol to permit collecting statistics for many
- separate object files. The table is word aligned, and begins with
- a two-word header. The first word, initialized to 0, is used in
- maintaining linked lists of branch tables. The second word is a
- count of the number of entries in the table, which follow
- immediately: each is a word, pointing to one of the labels
- illustrated above.
-
- +------------+------------+------------+ ... +------------+
- | | | | | |
- | *NEXT | COUNT: N | *BRLAB 1 | | *BRLAB N |
- | | | | | |
- +------------+------------+------------+ ... +------------+
-
- __BRANCH_TABLE__ layout
-
- The first word of the header is used to locate multiple branch
- tables, since each object file may contain one. Normally the links
- are maintained with a call to an initialization routine, placed at
- the beginning of each function in the file. The GNU C compiler
- generates these calls automatically when you give it a `-b' option.
- For further details, see the documentation of `gbr960'.
-
-`-no-relax'
- Normally, Compare-and-Branch instructions with targets that require
- displacements greater than 13 bits (or that have external targets)
- are replaced with the corresponding compare (or `chkbit') and
- branch instructions. You can use the `-no-relax' option to
- specify that `as' should generate errors instead, if the target
- displacement is larger than 13 bits.
-
- This option does not affect the Compare-and-Jump instructions; the
- code emitted for them is _always_ adjusted when necessary
- (depending on displacement size), regardless of whether you use
- `-no-relax'.
-
-
-File: as.info, Node: Floating Point-i960, Next: Directives-i960, Prev: Options-i960, Up: i960-Dependent
-
-9.15.2 Floating Point
----------------------
-
-`as' generates IEEE floating-point numbers for the directives `.float',
-`.double', `.extended', and `.single'.
-
-
-File: as.info, Node: Directives-i960, Next: Opcodes for i960, Prev: Floating Point-i960, Up: i960-Dependent
-
-9.15.3 i960 Machine Directives
-------------------------------
-
-`.bss SYMBOL, LENGTH, ALIGN'
- Reserve LENGTH bytes in the bss section for a local SYMBOL,
- aligned to the power of two specified by ALIGN. LENGTH and ALIGN
- must be positive absolute expressions. This directive differs
- from `.lcomm' only in that it permits you to specify an alignment.
- *Note `.lcomm': Lcomm.
-
-`.extended FLONUMS'
- `.extended' expects zero or more flonums, separated by commas; for
- each flonum, `.extended' emits an IEEE extended-format (80-bit)
- floating-point number.
-
-`.leafproc CALL-LAB, BAL-LAB'
- You can use the `.leafproc' directive in conjunction with the
- optimized `callj' instruction to enable faster calls of leaf
- procedures. If a procedure is known to call no other procedures,
- you may define an entry point that skips procedure prolog code
- (and that does not depend on system-supplied saved context), and
- declare it as the BAL-LAB using `.leafproc'. If the procedure
- also has an entry point that goes through the normal prolog, you
- can specify that entry point as CALL-LAB.
-
- A `.leafproc' declaration is meant for use in conjunction with the
- optimized call instruction `callj'; the directive records the data
- needed later to choose between converting the `callj' into a `bal'
- or a `call'.
-
- CALL-LAB is optional; if only one argument is present, or if the
- two arguments are identical, the single argument is assumed to be
- the `bal' entry point.
-
-`.sysproc NAME, INDEX'
- The `.sysproc' directive defines a name for a system procedure.
- After you define it using `.sysproc', you can use NAME to refer to
- the system procedure identified by INDEX when calling procedures
- with the optimized call instruction `callj'.
-
- Both arguments are required; INDEX must be between 0 and 31
- (inclusive).
-
-
-File: as.info, Node: Opcodes for i960, Prev: Directives-i960, Up: i960-Dependent
-
-9.15.4 i960 Opcodes
--------------------
-
-All Intel 960 machine instructions are supported; *note i960
-Command-line Options: Options-i960. for a discussion of selecting the
-instruction subset for a particular 960 architecture.
-
- Some opcodes are processed beyond simply emitting a single
-corresponding instruction: `callj', and Compare-and-Branch or
-Compare-and-Jump instructions with target displacements larger than 13
-bits.
-
-* Menu:
-
-* callj-i960:: `callj'
-* Compare-and-branch-i960:: Compare-and-Branch
-
-
-File: as.info, Node: callj-i960, Next: Compare-and-branch-i960, Up: Opcodes for i960
-
-9.15.4.1 `callj'
-................
-
-You can write `callj' to have the assembler or the linker determine the
-most appropriate form of subroutine call: `call', `bal', or `calls'.
-If the assembly source contains enough information--a `.leafproc' or
-`.sysproc' directive defining the operand--then `as' translates the
-`callj'; if not, it simply emits the `callj', leaving it for the linker
-to resolve.
-
-
-File: as.info, Node: Compare-and-branch-i960, Prev: callj-i960, Up: Opcodes for i960
-
-9.15.4.2 Compare-and-Branch
-...........................
-
-The 960 architectures provide combined Compare-and-Branch instructions
-that permit you to store the branch target in the lower 13 bits of the
-instruction word itself. However, if you specify a branch target far
-enough away that its address won't fit in 13 bits, the assembler can
-either issue an error, or convert your Compare-and-Branch instruction
-into separate instructions to do the compare and the branch.
-
- Whether `as' gives an error or expands the instruction depends on
-two choices you can make: whether you use the `-no-relax' option, and
-whether you use a "Compare and Branch" instruction or a "Compare and
-Jump" instruction. The "Jump" instructions are _always_ expanded if
-necessary; the "Branch" instructions are expanded when necessary
-_unless_ you specify `-no-relax'--in which case `as' gives an error
-instead.
-
- These are the Compare-and-Branch instructions, their "Jump" variants,
-and the instruction pairs they may expand into:
-
- Compare and
- Branch Jump Expanded to
- ------ ------ ------------
- bbc chkbit; bno
- bbs chkbit; bo
- cmpibe cmpije cmpi; be
- cmpibg cmpijg cmpi; bg
- cmpibge cmpijge cmpi; bge
- cmpibl cmpijl cmpi; bl
- cmpible cmpijle cmpi; ble
- cmpibno cmpijno cmpi; bno
- cmpibne cmpijne cmpi; bne
- cmpibo cmpijo cmpi; bo
- cmpobe cmpoje cmpo; be
- cmpobg cmpojg cmpo; bg
- cmpobge cmpojge cmpo; bge
- cmpobl cmpojl cmpo; bl
- cmpoble cmpojle cmpo; ble
- cmpobne cmpojne cmpo; bne
-
-
-File: as.info, Node: IA-64-Dependent, Next: IP2K-Dependent, Prev: i960-Dependent, Up: Machine Dependencies
-
-9.16 IA-64 Dependent Features
-=============================
-
-* Menu:
-
-* IA-64 Options:: Options
-* IA-64 Syntax:: Syntax
-* IA-64 Opcodes:: Opcodes
-
-
-File: as.info, Node: IA-64 Options, Next: IA-64 Syntax, Up: IA-64-Dependent
-
-9.16.1 Options
---------------
-
-`-mconstant-gp'
- This option instructs the assembler to mark the resulting object
- file as using the "constant GP" model. With this model, it is
- assumed that the entire program uses a single global pointer (GP)
- value. Note that this option does not in any fashion affect the
- machine code emitted by the assembler. All it does is turn on the
- EF_IA_64_CONS_GP flag in the ELF file header.
-
-`-mauto-pic'
- This option instructs the assembler to mark the resulting object
- file as using the "constant GP without function descriptor" data
- model. This model is like the "constant GP" model, except that it
- additionally does away with function descriptors. What this means
- is that the address of a function refers directly to the
- function's code entry-point. Normally, such an address would
- refer to a function descriptor, which contains both the code
- entry-point and the GP-value needed by the function. Note that
- this option does not in any fashion affect the machine code
- emitted by the assembler. All it does is turn on the
- EF_IA_64_NOFUNCDESC_CONS_GP flag in the ELF file header.
-
-`-milp32'
-`-milp64'
-`-mlp64'
-`-mp64'
- These options select the data model. The assembler defaults to
- `-mlp64' (LP64 data model).
-
-`-mle'
-`-mbe'
- These options select the byte order. The `-mle' option selects
- little-endian byte order (default) and `-mbe' selects big-endian
- byte order. Note that IA-64 machine code always uses
- little-endian byte order.
-
-`-mtune=itanium1'
-`-mtune=itanium2'
- Tune for a particular IA-64 CPU, ITANIUM1 or ITANIUM2. The default
- is ITANIUM2.
-
-`-munwind-check=warning'
-`-munwind-check=error'
- These options control what the assembler will do when performing
- consistency checks on unwind directives. `-munwind-check=warning'
- will make the assembler issue a warning when an unwind directive
- check fails. This is the default. `-munwind-check=error' will
- make the assembler issue an error when an unwind directive check
- fails.
-
-`-mhint.b=ok'
-`-mhint.b=warning'
-`-mhint.b=error'
- These options control what the assembler will do when the `hint.b'
- instruction is used. `-mhint.b=ok' will make the assembler accept
- `hint.b'. `-mint.b=warning' will make the assembler issue a
- warning when `hint.b' is used. `-mhint.b=error' will make the
- assembler treat `hint.b' as an error, which is the default.
-
-`-x'
-`-xexplicit'
- These options turn on dependency violation checking.
-
-`-xauto'
- This option instructs the assembler to automatically insert stop
- bits where necessary to remove dependency violations. This is the
- default mode.
-
-`-xnone'
- This option turns off dependency violation checking.
-
-`-xdebug'
- This turns on debug output intended to help tracking down bugs in
- the dependency violation checker.
-
-`-xdebugn'
- This is a shortcut for -xnone -xdebug.
-
-`-xdebugx'
- This is a shortcut for -xexplicit -xdebug.
-
-
-
-File: as.info, Node: IA-64 Syntax, Next: IA-64 Opcodes, Prev: IA-64 Options, Up: IA-64-Dependent
-
-9.16.2 Syntax
--------------
-
-The assembler syntax closely follows the IA-64 Assembly Language
-Reference Guide.
-
-* Menu:
-
-* IA-64-Chars:: Special Characters
-* IA-64-Regs:: Register Names
-* IA-64-Bits:: Bit Names
-* IA-64-Relocs:: Relocations
-
-
-File: as.info, Node: IA-64-Chars, Next: IA-64-Regs, Up: IA-64 Syntax
-
-9.16.2.1 Special Characters
-...........................
-
-`//' is the line comment token.
-
- `;' can be used instead of a newline to separate statements.
-
-
-File: as.info, Node: IA-64-Regs, Next: IA-64-Bits, Prev: IA-64-Chars, Up: IA-64 Syntax
-
-9.16.2.2 Register Names
-.......................
-
-The 128 integer registers are referred to as `rN'. The 128
-floating-point registers are referred to as `fN'. The 128 application
-registers are referred to as `arN'. The 128 control registers are
-referred to as `crN'. The 64 one-bit predicate registers are referred
-to as `pN'. The 8 branch registers are referred to as `bN'. In
-addition, the assembler defines a number of aliases: `gp' (`r1'), `sp'
-(`r12'), `rp' (`b0'), `ret0' (`r8'), `ret1' (`r9'), `ret2' (`r10'),
-`ret3' (`r9'), `fargN' (`f8+N'), and `fretN' (`f8+N').
-
- For convenience, the assembler also defines aliases for all named
-application and control registers. For example, `ar.bsp' refers to the
-register backing store pointer (`ar17'). Similarly, `cr.eoi' refers to
-the end-of-interrupt register (`cr67').
-
-
-File: as.info, Node: IA-64-Bits, Next: IA-64-Relocs, Prev: IA-64-Regs, Up: IA-64 Syntax
-
-9.16.2.3 IA-64 Processor-Status-Register (PSR) Bit Names
-........................................................
-
-The assembler defines bit masks for each of the bits in the IA-64
-processor status register. For example, `psr.ic' corresponds to a
-value of 0x2000. These masks are primarily intended for use with the
-`ssm'/`sum' and `rsm'/`rum' instructions, but they can be used anywhere
-else where an integer constant is expected.
-
-
-File: as.info, Node: IA-64-Relocs, Prev: IA-64-Bits, Up: IA-64 Syntax
-
-9.16.2.4 Relocations
-....................
-
-In addition to the standard IA-64 relocations, the following
-relocations are implemented by `as':
-
-`@slotcount(V)'
- Convert the address offset V into a slot count. This pseudo
- function is available only on VMS. The expression V must be known
- at assembly time: it can't reference undefined symbols or symbols
- in different sections.
-
-
-File: as.info, Node: IA-64 Opcodes, Prev: IA-64 Syntax, Up: IA-64-Dependent
-
-9.16.3 Opcodes
---------------
-
-For detailed information on the IA-64 machine instruction set, see the
-IA-64 Architecture Handbook
-(http://developer.intel.com/design/itanium/arch_spec.htm).
-
-
-File: as.info, Node: IP2K-Dependent, Next: LM32-Dependent, Prev: IA-64-Dependent, Up: Machine Dependencies
-
-9.17 IP2K Dependent Features
-============================
-
-* Menu:
-
-* IP2K-Opts:: IP2K Options
-
-
-File: as.info, Node: IP2K-Opts, Up: IP2K-Dependent
-
-9.17.1 IP2K Options
--------------------
-
-The Ubicom IP2K version of `as' has a few machine dependent options:
-
-`-mip2022ext'
- `as' can assemble the extended IP2022 instructions, but it will
- only do so if this is specifically allowed via this command line
- option.
-
-`-mip2022'
- This option restores the assembler's default behaviour of not
- permitting the extended IP2022 instructions to be assembled.
-
-
-
-File: as.info, Node: LM32-Dependent, Next: M32C-Dependent, Prev: IP2K-Dependent, Up: Machine Dependencies
-
-9.18 LM32 Dependent Features
-============================
-
-* Menu:
-
-* LM32 Options:: Options
-* LM32 Syntax:: Syntax
-* LM32 Opcodes:: Opcodes
-
-
-File: as.info, Node: LM32 Options, Next: LM32 Syntax, Up: LM32-Dependent
-
-9.18.1 Options
---------------
-
-`-mmultiply-enabled'
- Enable multiply instructions.
-
-`-mdivide-enabled'
- Enable divide instructions.
-
-`-mbarrel-shift-enabled'
- Enable barrel-shift instructions.
-
-`-msign-extend-enabled'
- Enable sign extend instructions.
-
-`-muser-enabled'
- Enable user defined instructions.
-
-`-micache-enabled'
- Enable instruction cache related CSRs.
-
-`-mdcache-enabled'
- Enable data cache related CSRs.
-
-`-mbreak-enabled'
- Enable break instructions.
-
-`-mall-enabled'
- Enable all instructions and CSRs.
-
-
-
-File: as.info, Node: LM32 Syntax, Next: LM32 Opcodes, Prev: LM32 Options, Up: LM32-Dependent
-
-9.18.2 Syntax
--------------
-
-* Menu:
-
-* LM32-Regs:: Register Names
-* LM32-Modifiers:: Relocatable Expression Modifiers
-
-
-File: as.info, Node: LM32-Regs, Next: LM32-Modifiers, Up: LM32 Syntax
-
-9.18.2.1 Register Names
-.......................
-
-LM32 has 32 x 32-bit general purpose registers `r0', `r1', ... `r31'.
-
- The following aliases are defined: `gp' - `r26', `fp' - `r27', `sp'
-- `r28', `ra' - `r29', `ea' - `r30', `ba' - `r31'.
-
- LM32 has the following Control and Status Registers (CSRs).
-
-`IE'
- Interrupt enable.
-
-`IM'
- Interrupt mask.
-
-`IP'
- Interrupt pending.
-
-`ICC'
- Instruction cache control.
-
-`DCC'
- Data cache control.
-
-`CC'
- Cycle counter.
-
-`CFG'
- Configuration.
-
-`EBA'
- Exception base address.
-
-`DC'
- Debug control.
-
-`DEBA'
- Debug exception base address.
-
-`JTX'
- JTAG transmit.
-
-`JRX'
- JTAG receive.
-
-`BP0'
- Breakpoint 0.
-
-`BP1'
- Breakpoint 1.
-
-`BP2'
- Breakpoint 2.
-
-`BP3'
- Breakpoint 3.
-
-`WP0'
- Watchpoint 0.
-
-`WP1'
- Watchpoint 1.
-
-`WP2'
- Watchpoint 2.
-
-`WP3'
- Watchpoint 3.
-
-
-File: as.info, Node: LM32-Modifiers, Prev: LM32-Regs, Up: LM32 Syntax
-
-9.18.2.2 Relocatable Expression Modifiers
-.........................................
-
-The assembler supports several modifiers when using relocatable
-addresses in LM32 instruction operands. The general syntax is the
-following:
-
- modifier(relocatable-expression)
-
-`lo'
- This modifier allows you to use bits 0 through 15 of an address
- expression as 16 bit relocatable expression.
-
-`hi'
- This modifier allows you to use bits 16 through 23 of an address
- expression as 16 bit relocatable expression.
-
- For example
-
- ori r4, r4, lo(sym+10)
- orhi r4, r4, hi(sym+10)
-
-`gp'
- This modified creates a 16-bit relocatable expression that is the
- offset of the symbol from the global pointer.
-
- mva r4, gp(sym)
-
-`got'
- This modifier places a symbol in the GOT and creates a 16-bit
- relocatable expression that is the offset into the GOT of this
- symbol.
-
- lw r4, (gp+got(sym))
-
-`gotofflo16'
- This modifier allows you to use the bits 0 through 15 of an
- address which is an offset from the GOT.
-
-`gotoffhi16'
- This modifier allows you to use the bits 16 through 31 of an
- address which is an offset from the GOT.
-
- orhi r4, r4, gotoffhi16(lsym)
- addi r4, r4, gotofflo16(lsym)
-
-
-
-File: as.info, Node: LM32 Opcodes, Prev: LM32 Syntax, Up: LM32-Dependent
-
-9.18.3 Opcodes
---------------
-
-For detailed information on the LM32 machine instruction set, see
-`http://www.latticesemi.com/products/intellectualproperty/ipcores/mico32/'.
-
- `as' implements all the standard LM32 opcodes.
-
-
-File: as.info, Node: M32C-Dependent, Next: M32R-Dependent, Prev: LM32-Dependent, Up: Machine Dependencies
-
-9.19 M32C Dependent Features
-============================
-
- `as' can assemble code for several different members of the Renesas
-M32C family. Normally the default is to assemble code for the M16C
-microprocessor. The `-m32c' option may be used to change the default
-to the M32C microprocessor.
-
-* Menu:
-
-* M32C-Opts:: M32C Options
-* M32C-Modifiers:: Symbolic Operand Modifiers
-
-
-File: as.info, Node: M32C-Opts, Next: M32C-Modifiers, Up: M32C-Dependent
-
-9.19.1 M32C Options
--------------------
-
-The Renesas M32C version of `as' has these machine-dependent options:
-
-`-m32c'
- Assemble M32C instructions.
-
-`-m16c'
- Assemble M16C instructions (default).
-
-`-relax'
- Enable support for link-time relaxations.
-
-`-h-tick-hex'
- Support H'00 style hex constants in addition to 0x00 style.
-
-
-
-File: as.info, Node: M32C-Modifiers, Prev: M32C-Opts, Up: M32C-Dependent
-
-9.19.2 Symbolic Operand Modifiers
----------------------------------
-
-The assembler supports several modifiers when using symbol addresses in
-M32C instruction operands. The general syntax is the following:
-
- %modifier(symbol)
-
-`%dsp8'
-`%dsp16'
- These modifiers override the assembler's assumptions about how big
- a symbol's address is. Normally, when it sees an operand like
- `sym[a0]' it assumes `sym' may require the widest displacement
- field (16 bits for `-m16c', 24 bits for `-m32c'). These modifiers
- tell it to assume the address will fit in an 8 or 16 bit
- (respectively) unsigned displacement. Note that, of course, if it
- doesn't actually fit you will get linker errors. Example:
-
- mov.w %dsp8(sym)[a0],r1
- mov.b #0,%dsp8(sym)[a0]
-
-`%hi8'
- This modifier allows you to load bits 16 through 23 of a 24 bit
- address into an 8 bit register. This is useful with, for example,
- the M16C `smovf' instruction, which expects a 20 bit address in
- `r1h' and `a0'. Example:
-
- mov.b #%hi8(sym),r1h
- mov.w #%lo16(sym),a0
- smovf.b
-
-`%lo16'
- Likewise, this modifier allows you to load bits 0 through 15 of a
- 24 bit address into a 16 bit register.
-
-`%hi16'
- This modifier allows you to load bits 16 through 31 of a 32 bit
- address into a 16 bit register. While the M32C family only has 24
- bits of address space, it does support addresses in pairs of 16 bit
- registers (like `a1a0' for the `lde' instruction). This modifier
- is for loading the upper half in such cases. Example:
-
- mov.w #%hi16(sym),a1
- mov.w #%lo16(sym),a0
- ...
- lde.w [a1a0],r1
-
-
-
-File: as.info, Node: M32R-Dependent, Next: M68K-Dependent, Prev: M32C-Dependent, Up: Machine Dependencies
-
-9.20 M32R Dependent Features
-============================
-
-* Menu:
-
-* M32R-Opts:: M32R Options
-* M32R-Directives:: M32R Directives
-* M32R-Warnings:: M32R Warnings
-
-
-File: as.info, Node: M32R-Opts, Next: M32R-Directives, Up: M32R-Dependent
-
-9.20.1 M32R Options
--------------------
-
-The Renease M32R version of `as' has a few machine dependent options:
-
-`-m32rx'
- `as' can assemble code for several different members of the
- Renesas M32R family. Normally the default is to assemble code for
- the M32R microprocessor. This option may be used to change the
- default to the M32RX microprocessor, which adds some more
- instructions to the basic M32R instruction set, and some
- additional parameters to some of the original instructions.
-
-`-m32r2'
- This option changes the target processor to the the M32R2
- microprocessor.
-
-`-m32r'
- This option can be used to restore the assembler's default
- behaviour of assembling for the M32R microprocessor. This can be
- useful if the default has been changed by a previous command line
- option.
-
-`-little'
- This option tells the assembler to produce little-endian code and
- data. The default is dependent upon how the toolchain was
- configured.
-
-`-EL'
- This is a synonym for _-little_.
-
-`-big'
- This option tells the assembler to produce big-endian code and
- data.
-
-`-EB'
- This is a synonum for _-big_.
-
-`-KPIC'
- This option specifies that the output of the assembler should be
- marked as position-independent code (PIC).
-
-`-parallel'
- This option tells the assembler to attempts to combine two
- sequential instructions into a single, parallel instruction, where
- it is legal to do so.
-
-`-no-parallel'
- This option disables a previously enabled _-parallel_ option.
-
-`-no-bitinst'
- This option disables the support for the extended bit-field
- instructions provided by the M32R2. If this support needs to be
- re-enabled the _-bitinst_ switch can be used to restore it.
-
-`-O'
- This option tells the assembler to attempt to optimize the
- instructions that it produces. This includes filling delay slots
- and converting sequential instructions into parallel ones. This
- option implies _-parallel_.
-
-`-warn-explicit-parallel-conflicts'
- Instructs `as' to produce warning messages when questionable
- parallel instructions are encountered. This option is enabled by
- default, but `gcc' disables it when it invokes `as' directly.
- Questionable instructions are those whose behaviour would be
- different if they were executed sequentially. For example the
- code fragment `mv r1, r2 || mv r3, r1' produces a different result
- from `mv r1, r2 \n mv r3, r1' since the former moves r1 into r3
- and then r2 into r1, whereas the later moves r2 into r1 and r3.
-
-`-Wp'
- This is a shorter synonym for the
- _-warn-explicit-parallel-conflicts_ option.
-
-`-no-warn-explicit-parallel-conflicts'
- Instructs `as' not to produce warning messages when questionable
- parallel instructions are encountered.
-
-`-Wnp'
- This is a shorter synonym for the
- _-no-warn-explicit-parallel-conflicts_ option.
-
-`-ignore-parallel-conflicts'
- This option tells the assembler's to stop checking parallel
- instructions for constraint violations. This ability is provided
- for hardware vendors testing chip designs and should not be used
- under normal circumstances.
-
-`-no-ignore-parallel-conflicts'
- This option restores the assembler's default behaviour of checking
- parallel instructions to detect constraint violations.
-
-`-Ip'
- This is a shorter synonym for the _-ignore-parallel-conflicts_
- option.
-
-`-nIp'
- This is a shorter synonym for the _-no-ignore-parallel-conflicts_
- option.
-
-`-warn-unmatched-high'
- This option tells the assembler to produce a warning message if a
- `.high' pseudo op is encountered without a matching `.low' pseudo
- op. The presence of such an unmatched pseudo op usually indicates
- a programming error.
-
-`-no-warn-unmatched-high'
- Disables a previously enabled _-warn-unmatched-high_ option.
-
-`-Wuh'
- This is a shorter synonym for the _-warn-unmatched-high_ option.
-
-`-Wnuh'
- This is a shorter synonym for the _-no-warn-unmatched-high_ option.
-
-
-
-File: as.info, Node: M32R-Directives, Next: M32R-Warnings, Prev: M32R-Opts, Up: M32R-Dependent
-
-9.20.2 M32R Directives
-----------------------
-
-The Renease M32R version of `as' has a few architecture specific
-directives:
-
-`low EXPRESSION'
- The `low' directive computes the value of its expression and
- places the lower 16-bits of the result into the immediate-field of
- the instruction. For example:
-
- or3 r0, r0, #low(0x12345678) ; compute r0 = r0 | 0x5678
- add3, r0, r0, #low(fred) ; compute r0 = r0 + low 16-bits of address of fred
-
-`high EXPRESSION'
- The `high' directive computes the value of its expression and
- places the upper 16-bits of the result into the immediate-field of
- the instruction. For example:
-
- seth r0, #high(0x12345678) ; compute r0 = 0x12340000
- seth, r0, #high(fred) ; compute r0 = upper 16-bits of address of fred
-
-`shigh EXPRESSION'
- The `shigh' directive is very similar to the `high' directive. It
- also computes the value of its expression and places the upper
- 16-bits of the result into the immediate-field of the instruction.
- The difference is that `shigh' also checks to see if the lower
- 16-bits could be interpreted as a signed number, and if so it
- assumes that a borrow will occur from the upper-16 bits. To
- compensate for this the `shigh' directive pre-biases the upper 16
- bit value by adding one to it. For example:
-
- For example:
-
- seth r0, #shigh(0x12345678) ; compute r0 = 0x12340000
- seth r0, #shigh(0x00008000) ; compute r0 = 0x00010000
-
- In the second example the lower 16-bits are 0x8000. If these are
- treated as a signed value and sign extended to 32-bits then the
- value becomes 0xffff8000. If this value is then added to
- 0x00010000 then the result is 0x00008000.
-
- This behaviour is to allow for the different semantics of the
- `or3' and `add3' instructions. The `or3' instruction treats its
- 16-bit immediate argument as unsigned whereas the `add3' treats
- its 16-bit immediate as a signed value. So for example:
-
- seth r0, #shigh(0x00008000)
- add3 r0, r0, #low(0x00008000)
-
- Produces the correct result in r0, whereas:
-
- seth r0, #shigh(0x00008000)
- or3 r0, r0, #low(0x00008000)
-
- Stores 0xffff8000 into r0.
-
- Note - the `shigh' directive does not know where in the assembly
- source code the lower 16-bits of the value are going set, so it
- cannot check to make sure that an `or3' instruction is being used
- rather than an `add3' instruction. It is up to the programmer to
- make sure that correct directives are used.
-
-`.m32r'
- The directive performs a similar thing as the _-m32r_ command line
- option. It tells the assembler to only accept M32R instructions
- from now on. An instructions from later M32R architectures are
- refused.
-
-`.m32rx'
- The directive performs a similar thing as the _-m32rx_ command
- line option. It tells the assembler to start accepting the extra
- instructions in the M32RX ISA as well as the ordinary M32R ISA.
-
-`.m32r2'
- The directive performs a similar thing as the _-m32r2_ command
- line option. It tells the assembler to start accepting the extra
- instructions in the M32R2 ISA as well as the ordinary M32R ISA.
-
-`.little'
- The directive performs a similar thing as the _-little_ command
- line option. It tells the assembler to start producing
- little-endian code and data. This option should be used with care
- as producing mixed-endian binary files is fraught with danger.
-
-`.big'
- The directive performs a similar thing as the _-big_ command line
- option. It tells the assembler to start producing big-endian code
- and data. This option should be used with care as producing
- mixed-endian binary files is fraught with danger.
-
-
-
-File: as.info, Node: M32R-Warnings, Prev: M32R-Directives, Up: M32R-Dependent
-
-9.20.3 M32R Warnings
---------------------
-
-There are several warning and error messages that can be produced by
-`as' which are specific to the M32R:
-
-`output of 1st instruction is the same as an input to 2nd instruction - is this intentional ?'
- This message is only produced if warnings for explicit parallel
- conflicts have been enabled. It indicates that the assembler has
- encountered a parallel instruction in which the destination
- register of the left hand instruction is used as an input register
- in the right hand instruction. For example in this code fragment
- `mv r1, r2 || neg r3, r1' register r1 is the destination of the
- move instruction and the input to the neg instruction.
-
-`output of 2nd instruction is the same as an input to 1st instruction - is this intentional ?'
- This message is only produced if warnings for explicit parallel
- conflicts have been enabled. It indicates that the assembler has
- encountered a parallel instruction in which the destination
- register of the right hand instruction is used as an input
- register in the left hand instruction. For example in this code
- fragment `mv r1, r2 || neg r2, r3' register r2 is the destination
- of the neg instruction and the input to the move instruction.
-
-`instruction `...' is for the M32RX only'
- This message is produced when the assembler encounters an
- instruction which is only supported by the M32Rx processor, and
- the `-m32rx' command line flag has not been specified to allow
- assembly of such instructions.
-
-`unknown instruction `...''
- This message is produced when the assembler encounters an
- instruction which it does not recognize.
-
-`only the NOP instruction can be issued in parallel on the m32r'
- This message is produced when the assembler encounters a parallel
- instruction which does not involve a NOP instruction and the
- `-m32rx' command line flag has not been specified. Only the M32Rx
- processor is able to execute two instructions in parallel.
-
-`instruction `...' cannot be executed in parallel.'
- This message is produced when the assembler encounters a parallel
- instruction which is made up of one or two instructions which
- cannot be executed in parallel.
-
-`Instructions share the same execution pipeline'
- This message is produced when the assembler encounters a parallel
- instruction whoes components both use the same execution pipeline.
-
-`Instructions write to the same destination register.'
- This message is produced when the assembler encounters a parallel
- instruction where both components attempt to modify the same
- register. For example these code fragments will produce this
- message: `mv r1, r2 || neg r1, r3' `jl r0 || mv r14, r1' `st r2,
- @-r1 || mv r1, r3' `mv r1, r2 || ld r0, @r1+' `cmp r1, r2 || addx
- r3, r4' (Both write to the condition bit)
-
-
-
-File: as.info, Node: M68K-Dependent, Next: M68HC11-Dependent, Prev: M32R-Dependent, Up: Machine Dependencies
-
-9.21 M680x0 Dependent Features
-==============================
-
-* Menu:
-
-* M68K-Opts:: M680x0 Options
-* M68K-Syntax:: Syntax
-* M68K-Moto-Syntax:: Motorola Syntax
-* M68K-Float:: Floating Point
-* M68K-Directives:: 680x0 Machine Directives
-* M68K-opcodes:: Opcodes
-
-
-File: as.info, Node: M68K-Opts, Next: M68K-Syntax, Up: M68K-Dependent
-
-9.21.1 M680x0 Options
----------------------
-
-The Motorola 680x0 version of `as' has a few machine dependent options:
-
-`-march=ARCHITECTURE'
- This option specifies a target architecture. The following
- architectures are recognized: `68000', `68010', `68020', `68030',
- `68040', `68060', `cpu32', `isaa', `isaaplus', `isab', `isac' and
- `cfv4e'.
-
-`-mcpu=CPU'
- This option specifies a target cpu. When used in conjunction with
- the `-march' option, the cpu must be within the specified
- architecture. Also, the generic features of the architecture are
- used for instruction generation, rather than those of the specific
- chip.
-
-`-m[no-]68851'
-`-m[no-]68881'
-`-m[no-]div'
-`-m[no-]usp'
-`-m[no-]float'
-`-m[no-]mac'
-`-m[no-]emac'
- Enable or disable various architecture specific features. If a
- chip or architecture by default supports an option (for instance
- `-march=isaaplus' includes the `-mdiv' option), explicitly
- disabling the option will override the default.
-
-`-l'
- You can use the `-l' option to shorten the size of references to
- undefined symbols. If you do not use the `-l' option, references
- to undefined symbols are wide enough for a full `long' (32 bits).
- (Since `as' cannot know where these symbols end up, `as' can only
- allocate space for the linker to fill in later. Since `as' does
- not know how far away these symbols are, it allocates as much
- space as it can.) If you use this option, the references are only
- one word wide (16 bits). This may be useful if you want the
- object file to be as small as possible, and you know that the
- relevant symbols are always less than 17 bits away.
-
-`--register-prefix-optional'
- For some configurations, especially those where the compiler
- normally does not prepend an underscore to the names of user
- variables, the assembler requires a `%' before any use of a
- register name. This is intended to let the assembler distinguish
- between C variables and functions named `a0' through `a7', and so
- on. The `%' is always accepted, but is not required for certain
- configurations, notably `sun3'. The `--register-prefix-optional'
- option may be used to permit omitting the `%' even for
- configurations for which it is normally required. If this is
- done, it will generally be impossible to refer to C variables and
- functions with the same names as register names.
-
-`--bitwise-or'
- Normally the character `|' is treated as a comment character, which
- means that it can not be used in expressions. The `--bitwise-or'
- option turns `|' into a normal character. In this mode, you must
- either use C style comments, or start comments with a `#' character
- at the beginning of a line.
-
-`--base-size-default-16 --base-size-default-32'
- If you use an addressing mode with a base register without
- specifying the size, `as' will normally use the full 32 bit value.
- For example, the addressing mode `%a0@(%d0)' is equivalent to
- `%a0@(%d0:l)'. You may use the `--base-size-default-16' option to
- tell `as' to default to using the 16 bit value. In this case,
- `%a0@(%d0)' is equivalent to `%a0@(%d0:w)'. You may use the
- `--base-size-default-32' option to restore the default behaviour.
-
-`--disp-size-default-16 --disp-size-default-32'
- If you use an addressing mode with a displacement, and the value
- of the displacement is not known, `as' will normally assume that
- the value is 32 bits. For example, if the symbol `disp' has not
- been defined, `as' will assemble the addressing mode
- `%a0@(disp,%d0)' as though `disp' is a 32 bit value. You may use
- the `--disp-size-default-16' option to tell `as' to instead assume
- that the displacement is 16 bits. In this case, `as' will
- assemble `%a0@(disp,%d0)' as though `disp' is a 16 bit value. You
- may use the `--disp-size-default-32' option to restore the default
- behaviour.
-
-`--pcrel'
- Always keep branches PC-relative. In the M680x0 architecture all
- branches are defined as PC-relative. However, on some processors
- they are limited to word displacements maximum. When `as' needs a
- long branch that is not available, it normally emits an absolute
- jump instead. This option disables this substitution. When this
- option is given and no long branches are available, only word
- branches will be emitted. An error message will be generated if a
- word branch cannot reach its target. This option has no effect on
- 68020 and other processors that have long branches. *note Branch
- Improvement: M68K-Branch.
-
-`-m68000'
- `as' can assemble code for several different members of the
- Motorola 680x0 family. The default depends upon how `as' was
- configured when it was built; normally, the default is to assemble
- code for the 68020 microprocessor. The following options may be
- used to change the default. These options control which
- instructions and addressing modes are permitted. The members of
- the 680x0 family are very similar. For detailed information about
- the differences, see the Motorola manuals.
-
- `-m68000'
- `-m68ec000'
- `-m68hc000'
- `-m68hc001'
- `-m68008'
- `-m68302'
- `-m68306'
- `-m68307'
- `-m68322'
- `-m68356'
- Assemble for the 68000. `-m68008', `-m68302', and so on are
- synonyms for `-m68000', since the chips are the same from the
- point of view of the assembler.
-
- `-m68010'
- Assemble for the 68010.
-
- `-m68020'
- `-m68ec020'
- Assemble for the 68020. This is normally the default.
-
- `-m68030'
- `-m68ec030'
- Assemble for the 68030.
-
- `-m68040'
- `-m68ec040'
- Assemble for the 68040.
-
- `-m68060'
- `-m68ec060'
- Assemble for the 68060.
-
- `-mcpu32'
- `-m68330'
- `-m68331'
- `-m68332'
- `-m68333'
- `-m68334'
- `-m68336'
- `-m68340'
- `-m68341'
- `-m68349'
- `-m68360'
- Assemble for the CPU32 family of chips.
-
- `-m5200'
- `-m5202'
- `-m5204'
- `-m5206'
- `-m5206e'
- `-m521x'
- `-m5249'
- `-m528x'
- `-m5307'
- `-m5407'
- `-m547x'
- `-m548x'
- `-mcfv4'
- `-mcfv4e'
- Assemble for the ColdFire family of chips.
-
- `-m68881'
- `-m68882'
- Assemble 68881 floating point instructions. This is the
- default for the 68020, 68030, and the CPU32. The 68040 and
- 68060 always support floating point instructions.
-
- `-mno-68881'
- Do not assemble 68881 floating point instructions. This is
- the default for 68000 and the 68010. The 68040 and 68060
- always support floating point instructions, even if this
- option is used.
-
- `-m68851'
- Assemble 68851 MMU instructions. This is the default for the
- 68020, 68030, and 68060. The 68040 accepts a somewhat
- different set of MMU instructions; `-m68851' and `-m68040'
- should not be used together.
-
- `-mno-68851'
- Do not assemble 68851 MMU instructions. This is the default
- for the 68000, 68010, and the CPU32. The 68040 accepts a
- somewhat different set of MMU instructions.
-
-
-File: as.info, Node: M68K-Syntax, Next: M68K-Moto-Syntax, Prev: M68K-Opts, Up: M68K-Dependent
-
-9.21.2 Syntax
--------------
-
-This syntax for the Motorola 680x0 was developed at MIT.
-
- The 680x0 version of `as' uses instructions names and syntax
-compatible with the Sun assembler. Intervening periods are ignored;
-for example, `movl' is equivalent to `mov.l'.
-
- In the following table APC stands for any of the address registers
-(`%a0' through `%a7'), the program counter (`%pc'), the zero-address
-relative to the program counter (`%zpc'), a suppressed address register
-(`%za0' through `%za7'), or it may be omitted entirely. The use of
-SIZE means one of `w' or `l', and it may be omitted, along with the
-leading colon, unless a scale is also specified. The use of SCALE
-means one of `1', `2', `4', or `8', and it may always be omitted along
-with the leading colon.
-
- The following addressing modes are understood:
-"Immediate"
- `#NUMBER'
-
-"Data Register"
- `%d0' through `%d7'
-
-"Address Register"
- `%a0' through `%a7'
- `%a7' is also known as `%sp', i.e., the Stack Pointer. `%a6' is
- also known as `%fp', the Frame Pointer.
-
-"Address Register Indirect"
- `%a0@' through `%a7@'
-
-"Address Register Postincrement"
- `%a0@+' through `%a7@+'
-
-"Address Register Predecrement"
- `%a0@-' through `%a7@-'
-
-"Indirect Plus Offset"
- `APC@(NUMBER)'
-
-"Index"
- `APC@(NUMBER,REGISTER:SIZE:SCALE)'
-
- The NUMBER may be omitted.
-
-"Postindex"
- `APC@(NUMBER)@(ONUMBER,REGISTER:SIZE:SCALE)'
-
- The ONUMBER or the REGISTER, but not both, may be omitted.
-
-"Preindex"
- `APC@(NUMBER,REGISTER:SIZE:SCALE)@(ONUMBER)'
-
- The NUMBER may be omitted. Omitting the REGISTER produces the
- Postindex addressing mode.
-
-"Absolute"
- `SYMBOL', or `DIGITS', optionally followed by `:b', `:w', or `:l'.
-
-
-File: as.info, Node: M68K-Moto-Syntax, Next: M68K-Float, Prev: M68K-Syntax, Up: M68K-Dependent
-
-9.21.3 Motorola Syntax
-----------------------
-
-The standard Motorola syntax for this chip differs from the syntax
-already discussed (*note Syntax: M68K-Syntax.). `as' can accept
-Motorola syntax for operands, even if MIT syntax is used for other
-operands in the same instruction. The two kinds of syntax are fully
-compatible.
-
- In the following table APC stands for any of the address registers
-(`%a0' through `%a7'), the program counter (`%pc'), the zero-address
-relative to the program counter (`%zpc'), or a suppressed address
-register (`%za0' through `%za7'). The use of SIZE means one of `w' or
-`l', and it may always be omitted along with the leading dot. The use
-of SCALE means one of `1', `2', `4', or `8', and it may always be
-omitted along with the leading asterisk.
-
- The following additional addressing modes are understood:
-
-"Address Register Indirect"
- `(%a0)' through `(%a7)'
- `%a7' is also known as `%sp', i.e., the Stack Pointer. `%a6' is
- also known as `%fp', the Frame Pointer.
-
-"Address Register Postincrement"
- `(%a0)+' through `(%a7)+'
-
-"Address Register Predecrement"
- `-(%a0)' through `-(%a7)'
-
-"Indirect Plus Offset"
- `NUMBER(%A0)' through `NUMBER(%A7)', or `NUMBER(%PC)'.
-
- The NUMBER may also appear within the parentheses, as in
- `(NUMBER,%A0)'. When used with the PC, the NUMBER may be omitted
- (with an address register, omitting the NUMBER produces Address
- Register Indirect mode).
-
-"Index"
- `NUMBER(APC,REGISTER.SIZE*SCALE)'
-
- The NUMBER may be omitted, or it may appear within the
- parentheses. The APC may be omitted. The REGISTER and the APC
- may appear in either order. If both APC and REGISTER are address
- registers, and the SIZE and SCALE are omitted, then the first
- register is taken as the base register, and the second as the
- index register.
-
-"Postindex"
- `([NUMBER,APC],REGISTER.SIZE*SCALE,ONUMBER)'
-
- The ONUMBER, or the REGISTER, or both, may be omitted. Either the
- NUMBER or the APC may be omitted, but not both.
-
-"Preindex"
- `([NUMBER,APC,REGISTER.SIZE*SCALE],ONUMBER)'
-
- The NUMBER, or the APC, or the REGISTER, or any two of them, may
- be omitted. The ONUMBER may be omitted. The REGISTER and the APC
- may appear in either order. If both APC and REGISTER are address
- registers, and the SIZE and SCALE are omitted, then the first
- register is taken as the base register, and the second as the
- index register.
-
-
-File: as.info, Node: M68K-Float, Next: M68K-Directives, Prev: M68K-Moto-Syntax, Up: M68K-Dependent
-
-9.21.4 Floating Point
----------------------
-
-Packed decimal (P) format floating literals are not supported. Feel
-free to add the code!
-
- The floating point formats generated by directives are these.
-
-`.float'
- `Single' precision floating point constants.
-
-`.double'
- `Double' precision floating point constants.
-
-`.extend'
-`.ldouble'
- `Extended' precision (`long double') floating point constants.
-
-
-File: as.info, Node: M68K-Directives, Next: M68K-opcodes, Prev: M68K-Float, Up: M68K-Dependent
-
-9.21.5 680x0 Machine Directives
--------------------------------
-
-In order to be compatible with the Sun assembler the 680x0 assembler
-understands the following directives.
-
-`.data1'
- This directive is identical to a `.data 1' directive.
-
-`.data2'
- This directive is identical to a `.data 2' directive.
-
-`.even'
- This directive is a special case of the `.align' directive; it
- aligns the output to an even byte boundary.
-
-`.skip'
- This directive is identical to a `.space' directive.
-
-`.arch NAME'
- Select the target architecture and extension features. Valid
- values for NAME are the same as for the `-march' command line
- option. This directive cannot be specified after any instructions
- have been assembled. If it is given multiple times, or in
- conjunction with the `-march' option, all uses must be for the
- same architecture and extension set.
-
-`.cpu NAME'
- Select the target cpu. Valid valuse for NAME are the same as for
- the `-mcpu' command line option. This directive cannot be
- specified after any instructions have been assembled. If it is
- given multiple times, or in conjunction with the `-mopt' option,
- all uses must be for the same cpu.
-
-
-
-File: as.info, Node: M68K-opcodes, Prev: M68K-Directives, Up: M68K-Dependent
-
-9.21.6 Opcodes
---------------
-
-* Menu:
-
-* M68K-Branch:: Branch Improvement
-* M68K-Chars:: Special Characters
-
-
-File: as.info, Node: M68K-Branch, Next: M68K-Chars, Up: M68K-opcodes
-
-9.21.6.1 Branch Improvement
-...........................
-
-Certain pseudo opcodes are permitted for branch instructions. They
-expand to the shortest branch instruction that reach the target.
-Generally these mnemonics are made by substituting `j' for `b' at the
-start of a Motorola mnemonic.
-
- The following table summarizes the pseudo-operations. A `*' flags
-cases that are more fully described after the table:
-
- Displacement
- +------------------------------------------------------------
- | 68020 68000/10, not PC-relative OK
- Pseudo-Op |BYTE WORD LONG ABSOLUTE LONG JUMP **
- +------------------------------------------------------------
- jbsr |bsrs bsrw bsrl jsr
- jra |bras braw bral jmp
- * jXX |bXXs bXXw bXXl bNXs;jmp
- * dbXX | N/A dbXXw dbXX;bras;bral dbXX;bras;jmp
- fjXX | N/A fbXXw fbXXl N/A
-
- XX: condition
- NX: negative of condition XX
- `*'--see full description below
- `**'--this expansion mode is disallowed by `--pcrel'
-
-`jbsr'
-`jra'
- These are the simplest jump pseudo-operations; they always map to
- one particular machine instruction, depending on the displacement
- to the branch target. This instruction will be a byte or word
- branch is that is sufficient. Otherwise, a long branch will be
- emitted if available. If no long branches are available and the
- `--pcrel' option is not given, an absolute long jump will be
- emitted instead. If no long branches are available, the `--pcrel'
- option is given, and a word branch cannot reach the target, an
- error message is generated.
-
- In addition to standard branch operands, `as' allows these
- pseudo-operations to have all operands that are allowed for jsr
- and jmp, substituting these instructions if the operand given is
- not valid for a branch instruction.
-
-`jXX'
- Here, `jXX' stands for an entire family of pseudo-operations,
- where XX is a conditional branch or condition-code test. The full
- list of pseudo-ops in this family is:
- jhi jls jcc jcs jne jeq jvc
- jvs jpl jmi jge jlt jgt jle
-
- Usually, each of these pseudo-operations expands to a single branch
- instruction. However, if a word branch is not sufficient, no long
- branches are available, and the `--pcrel' option is not given, `as'
- issues a longer code fragment in terms of NX, the opposite
- condition to XX. For example, under these conditions:
- jXX foo
- gives
- bNXs oof
- jmp foo
- oof:
-
-`dbXX'
- The full family of pseudo-operations covered here is
- dbhi dbls dbcc dbcs dbne dbeq dbvc
- dbvs dbpl dbmi dbge dblt dbgt dble
- dbf dbra dbt
-
- Motorola `dbXX' instructions allow word displacements only. When
- a word displacement is sufficient, each of these pseudo-operations
- expands to the corresponding Motorola instruction. When a word
- displacement is not sufficient and long branches are available,
- when the source reads `dbXX foo', `as' emits
- dbXX oo1
- bras oo2
- oo1:bral foo
- oo2:
-
- If, however, long branches are not available and the `--pcrel'
- option is not given, `as' emits
- dbXX oo1
- bras oo2
- oo1:jmp foo
- oo2:
-
-`fjXX'
- This family includes
- fjne fjeq fjge fjlt fjgt fjle fjf
- fjt fjgl fjgle fjnge fjngl fjngle fjngt
- fjnle fjnlt fjoge fjogl fjogt fjole fjolt
- fjor fjseq fjsf fjsne fjst fjueq fjuge
- fjugt fjule fjult fjun
-
- Each of these pseudo-operations always expands to a single Motorola
- coprocessor branch instruction, word or long. All Motorola
- coprocessor branch instructions allow both word and long
- displacements.
-
-
-
-File: as.info, Node: M68K-Chars, Prev: M68K-Branch, Up: M68K-opcodes
-
-9.21.6.2 Special Characters
-...........................
-
-The immediate character is `#' for Sun compatibility. The line-comment
-character is `|' (unless the `--bitwise-or' option is used). If a `#'
-appears at the beginning of a line, it is treated as a comment unless
-it looks like `# line file', in which case it is treated normally.
-
-
-File: as.info, Node: M68HC11-Dependent, Next: MicroBlaze-Dependent, Prev: M68K-Dependent, Up: Machine Dependencies
-
-9.22 M68HC11 and M68HC12 Dependent Features
-===========================================
-
-* Menu:
-
-* M68HC11-Opts:: M68HC11 and M68HC12 Options
-* M68HC11-Syntax:: Syntax
-* M68HC11-Modifiers:: Symbolic Operand Modifiers
-* M68HC11-Directives:: Assembler Directives
-* M68HC11-Float:: Floating Point
-* M68HC11-opcodes:: Opcodes
-
-
-File: as.info, Node: M68HC11-Opts, Next: M68HC11-Syntax, Up: M68HC11-Dependent
-
-9.22.1 M68HC11 and M68HC12 Options
-----------------------------------
-
-The Motorola 68HC11 and 68HC12 version of `as' have a few machine
-dependent options.
-
-`-m68hc11'
- This option switches the assembler in the M68HC11 mode. In this
- mode, the assembler only accepts 68HC11 operands and mnemonics. It
- produces code for the 68HC11.
-
-`-m68hc12'
- This option switches the assembler in the M68HC12 mode. In this
- mode, the assembler also accepts 68HC12 operands and mnemonics. It
- produces code for the 68HC12. A few 68HC11 instructions are
- replaced by some 68HC12 instructions as recommended by Motorola
- specifications.
-
-`-m68hcs12'
- This option switches the assembler in the M68HCS12 mode. This
- mode is similar to `-m68hc12' but specifies to assemble for the
- 68HCS12 series. The only difference is on the assembling of the
- `movb' and `movw' instruction when a PC-relative operand is used.
-
-`-mshort'
- This option controls the ABI and indicates to use a 16-bit integer
- ABI. It has no effect on the assembled instructions. This is the
- default.
-
-`-mlong'
- This option controls the ABI and indicates to use a 32-bit integer
- ABI.
-
-`-mshort-double'
- This option controls the ABI and indicates to use a 32-bit float
- ABI. This is the default.
-
-`-mlong-double'
- This option controls the ABI and indicates to use a 64-bit float
- ABI.
-
-`--strict-direct-mode'
- You can use the `--strict-direct-mode' option to disable the
- automatic translation of direct page mode addressing into extended
- mode when the instruction does not support direct mode. For
- example, the `clr' instruction does not support direct page mode
- addressing. When it is used with the direct page mode, `as' will
- ignore it and generate an absolute addressing. This option
- prevents `as' from doing this, and the wrong usage of the direct
- page mode will raise an error.
-
-`--short-branches'
- The `--short-branches' option turns off the translation of
- relative branches into absolute branches when the branch offset is
- out of range. By default `as' transforms the relative branch
- (`bsr', `bgt', `bge', `beq', `bne', `ble', `blt', `bhi', `bcc',
- `bls', `bcs', `bmi', `bvs', `bvs', `bra') into an absolute branch
- when the offset is out of the -128 .. 127 range. In that case,
- the `bsr' instruction is translated into a `jsr', the `bra'
- instruction is translated into a `jmp' and the conditional
- branches instructions are inverted and followed by a `jmp'. This
- option disables these translations and `as' will generate an error
- if a relative branch is out of range. This option does not affect
- the optimization associated to the `jbra', `jbsr' and `jbXX'
- pseudo opcodes.
-
-`--force-long-branches'
- The `--force-long-branches' option forces the translation of
- relative branches into absolute branches. This option does not
- affect the optimization associated to the `jbra', `jbsr' and
- `jbXX' pseudo opcodes.
-
-`--print-insn-syntax'
- You can use the `--print-insn-syntax' option to obtain the syntax
- description of the instruction when an error is detected.
-
-`--print-opcodes'
- The `--print-opcodes' option prints the list of all the
- instructions with their syntax. The first item of each line
- represents the instruction name and the rest of the line indicates
- the possible operands for that instruction. The list is printed in
- alphabetical order. Once the list is printed `as' exits.
-
-`--generate-example'
- The `--generate-example' option is similar to `--print-opcodes'
- but it generates an example for each instruction instead.
-
-
-File: as.info, Node: M68HC11-Syntax, Next: M68HC11-Modifiers, Prev: M68HC11-Opts, Up: M68HC11-Dependent
-
-9.22.2 Syntax
--------------
-
-In the M68HC11 syntax, the instruction name comes first and it may be
-followed by one or several operands (up to three). Operands are
-separated by comma (`,'). In the normal mode, `as' will complain if too
-many operands are specified for a given instruction. In the MRI mode
-(turned on with `-M' option), it will treat them as comments. Example:
-
- inx
- lda #23
- bset 2,x #4
- brclr *bot #8 foo
-
- The following addressing modes are understood for 68HC11 and 68HC12:
-"Immediate"
- `#NUMBER'
-
-"Address Register"
- `NUMBER,X', `NUMBER,Y'
-
- The NUMBER may be omitted in which case 0 is assumed.
-
-"Direct Addressing mode"
- `*SYMBOL', or `*DIGITS'
-
-"Absolute"
- `SYMBOL', or `DIGITS'
-
- The M68HC12 has other more complex addressing modes. All of them are
-supported and they are represented below:
-
-"Constant Offset Indexed Addressing Mode"
- `NUMBER,REG'
-
- The NUMBER may be omitted in which case 0 is assumed. The
- register can be either `X', `Y', `SP' or `PC'. The assembler will
- use the smaller post-byte definition according to the constant
- value (5-bit constant offset, 9-bit constant offset or 16-bit
- constant offset). If the constant is not known by the assembler
- it will use the 16-bit constant offset post-byte and the value
- will be resolved at link time.
-
-"Offset Indexed Indirect"
- `[NUMBER,REG]'
-
- The register can be either `X', `Y', `SP' or `PC'.
-
-"Auto Pre-Increment/Pre-Decrement/Post-Increment/Post-Decrement"
- `NUMBER,-REG' `NUMBER,+REG' `NUMBER,REG-' `NUMBER,REG+'
-
- The number must be in the range `-8'..`+8' and must not be 0. The
- register can be either `X', `Y', `SP' or `PC'.
-
-"Accumulator Offset"
- `ACC,REG'
-
- The accumulator register can be either `A', `B' or `D'. The
- register can be either `X', `Y', `SP' or `PC'.
-
-"Accumulator D offset indexed-indirect"
- `[D,REG]'
-
- The register can be either `X', `Y', `SP' or `PC'.
-
-
- For example:
-
- ldab 1024,sp
- ldd [10,x]
- orab 3,+x
- stab -2,y-
- ldx a,pc
- sty [d,sp]
-
-
-File: as.info, Node: M68HC11-Modifiers, Next: M68HC11-Directives, Prev: M68HC11-Syntax, Up: M68HC11-Dependent
-
-9.22.3 Symbolic Operand Modifiers
----------------------------------
-
-The assembler supports several modifiers when using symbol addresses in
-68HC11 and 68HC12 instruction operands. The general syntax is the
-following:
-
- %modifier(symbol)
-
-`%addr'
- This modifier indicates to the assembler and linker to use the
- 16-bit physical address corresponding to the symbol. This is
- intended to be used on memory window systems to map a symbol in
- the memory bank window. If the symbol is in a memory expansion
- part, the physical address corresponds to the symbol address
- within the memory bank window. If the symbol is not in a memory
- expansion part, this is the symbol address (using or not using the
- %addr modifier has no effect in that case).
-
-`%page'
- This modifier indicates to use the memory page number corresponding
- to the symbol. If the symbol is in a memory expansion part, its
- page number is computed by the linker as a number used to map the
- page containing the symbol in the memory bank window. If the
- symbol is not in a memory expansion part, the page number is 0.
-
-`%hi'
- This modifier indicates to use the 8-bit high part of the physical
- address of the symbol.
-
-`%lo'
- This modifier indicates to use the 8-bit low part of the physical
- address of the symbol.
-
-
- For example a 68HC12 call to a function `foo_example' stored in
-memory expansion part could be written as follows:
-
- call %addr(foo_example),%page(foo_example)
-
- and this is equivalent to
-
- call foo_example
-
- And for 68HC11 it could be written as follows:
-
- ldab #%page(foo_example)
- stab _page_switch
- jsr %addr(foo_example)
-
-
-File: as.info, Node: M68HC11-Directives, Next: M68HC11-Float, Prev: M68HC11-Modifiers, Up: M68HC11-Dependent
-
-9.22.4 Assembler Directives
----------------------------
-
-The 68HC11 and 68HC12 version of `as' have the following specific
-assembler directives:
-
-`.relax'
- The relax directive is used by the `GNU Compiler' to emit a
- specific relocation to mark a group of instructions for linker
- relaxation. The sequence of instructions within the group must be
- known to the linker so that relaxation can be performed.
-
-`.mode [mshort|mlong|mshort-double|mlong-double]'
- This directive specifies the ABI. It overrides the `-mshort',
- `-mlong', `-mshort-double' and `-mlong-double' options.
-
-`.far SYMBOL'
- This directive marks the symbol as a `far' symbol meaning that it
- uses a `call/rtc' calling convention as opposed to `jsr/rts'.
- During a final link, the linker will identify references to the
- `far' symbol and will verify the proper calling convention.
-
-`.interrupt SYMBOL'
- This directive marks the symbol as an interrupt entry point. This
- information is then used by the debugger to correctly unwind the
- frame across interrupts.
-
-`.xrefb SYMBOL'
- This directive is defined for compatibility with the
- `Specification for Motorola 8 and 16-Bit Assembly Language Input
- Standard' and is ignored.
-
-
-
-File: as.info, Node: M68HC11-Float, Next: M68HC11-opcodes, Prev: M68HC11-Directives, Up: M68HC11-Dependent
-
-9.22.5 Floating Point
----------------------
-
-Packed decimal (P) format floating literals are not supported. Feel
-free to add the code!
-
- The floating point formats generated by directives are these.
-
-`.float'
- `Single' precision floating point constants.
-
-`.double'
- `Double' precision floating point constants.
-
-`.extend'
-`.ldouble'
- `Extended' precision (`long double') floating point constants.
-
-
-File: as.info, Node: M68HC11-opcodes, Prev: M68HC11-Float, Up: M68HC11-Dependent
-
-9.22.6 Opcodes
---------------
-
-* Menu:
-
-* M68HC11-Branch:: Branch Improvement
-
-
-File: as.info, Node: M68HC11-Branch, Up: M68HC11-opcodes
-
-9.22.6.1 Branch Improvement
-...........................
-
-Certain pseudo opcodes are permitted for branch instructions. They
-expand to the shortest branch instruction that reach the target.
-Generally these mnemonics are made by prepending `j' to the start of
-Motorola mnemonic. These pseudo opcodes are not affected by the
-`--short-branches' or `--force-long-branches' options.
-
- The following table summarizes the pseudo-operations.
-
- Displacement Width
- +-------------------------------------------------------------+
- | Options |
- | --short-branches --force-long-branches |
- +--------------------------+----------------------------------+
- Op |BYTE WORD | BYTE WORD |
- +--------------------------+----------------------------------+
- bsr | bsr <pc-rel> <error> | jsr <abs> |
- bra | bra <pc-rel> <error> | jmp <abs> |
- jbsr | bsr <pc-rel> jsr <abs> | bsr <pc-rel> jsr <abs> |
- jbra | bra <pc-rel> jmp <abs> | bra <pc-rel> jmp <abs> |
- bXX | bXX <pc-rel> <error> | bNX +3; jmp <abs> |
- jbXX | bXX <pc-rel> bNX +3; | bXX <pc-rel> bNX +3; jmp <abs> |
- | jmp <abs> | |
- +--------------------------+----------------------------------+
- XX: condition
- NX: negative of condition XX
-
-`jbsr'
-`jbra'
- These are the simplest jump pseudo-operations; they always map to
- one particular machine instruction, depending on the displacement
- to the branch target.
-
-`jbXX'
- Here, `jbXX' stands for an entire family of pseudo-operations,
- where XX is a conditional branch or condition-code test. The full
- list of pseudo-ops in this family is:
- jbcc jbeq jbge jbgt jbhi jbvs jbpl jblo
- jbcs jbne jblt jble jbls jbvc jbmi
-
- For the cases of non-PC relative displacements and long
- displacements, `as' issues a longer code fragment in terms of NX,
- the opposite condition to XX. For example, for the non-PC
- relative case:
- jbXX foo
- gives
- bNXs oof
- jmp foo
- oof:
-
-
-
-File: as.info, Node: MicroBlaze-Dependent, Next: MIPS-Dependent, Prev: M68HC11-Dependent, Up: Machine Dependencies
-
-9.23 MicroBlaze Dependent Features
-==================================
-
- The Xilinx MicroBlaze processor family includes several variants,
-all using the same core instruction set. This chapter covers features
-of the GNU assembler that are specific to the MicroBlaze architecture.
-For details about the MicroBlaze instruction set, please see the
-`MicroBlaze Processor Reference Guide (UG081)' available at
-www.xilinx.com.
-
-* Menu:
-
-* MicroBlaze Directives:: Directives for MicroBlaze Processors.
-
-
-File: as.info, Node: MicroBlaze Directives, Up: MicroBlaze-Dependent
-
-9.23.1 Directives
------------------
-
-A number of assembler directives are available for MicroBlaze.
-
-`.data8 EXPRESSION,...'
- This directive is an alias for `.byte'. Each expression is
- assembled into an eight-bit value.
-
-`.data16 EXPRESSION,...'
- This directive is an alias for `.hword'. Each expression is
- assembled into an 16-bit value.
-
-`.data32 EXPRESSION,...'
- This directive is an alias for `.word'. Each expression is
- assembled into an 32-bit value.
-
-`.ent NAME[,LABEL]'
- This directive is an alias for `.func' denoting the start of
- function NAME at (optional) LABEL.
-
-`.end NAME[,LABEL]'
- This directive is an alias for `.endfunc' denoting the end of
- function NAME.
-
-`.gpword LABEL,...'
- This directive is an alias for `.rva'. The resolved address of
- LABEL is stored in the data section.
-
-`.weakext LABEL'
- Declare that LABEL is a weak external symbol.
-
-`.rodata'
- Switch to .rodata section. Equivalent to `.section .rodata'
-
-`.sdata2'
- Switch to .sdata2 section. Equivalent to `.section .sdata2'
-
-`.sdata'
- Switch to .sdata section. Equivalent to `.section .sdata'
-
-`.bss'
- Switch to .bss section. Equivalent to `.section .bss'
-
-`.sbss'
- Switch to .sbss section. Equivalent to `.section .sbss'
-
-
-File: as.info, Node: MIPS-Dependent, Next: MMIX-Dependent, Prev: MicroBlaze-Dependent, Up: Machine Dependencies
-
-9.24 MIPS Dependent Features
-============================
-
- GNU `as' for MIPS architectures supports several different MIPS
-processors, and MIPS ISA levels I through V, MIPS32, and MIPS64. For
-information about the MIPS instruction set, see `MIPS RISC
-Architecture', by Kane and Heindrich (Prentice-Hall). For an overview
-of MIPS assembly conventions, see "Appendix D: Assembly Language
-Programming" in the same work.
-
-* Menu:
-
-* MIPS Opts:: Assembler options
-* MIPS Object:: ECOFF object code
-* MIPS Stabs:: Directives for debugging information
-* MIPS ISA:: Directives to override the ISA level
-* MIPS symbol sizes:: Directives to override the size of symbols
-* MIPS autoextend:: Directives for extending MIPS 16 bit instructions
-* MIPS insn:: Directive to mark data as an instruction
-* MIPS option stack:: Directives to save and restore options
-* MIPS ASE instruction generation overrides:: Directives to control
- generation of MIPS ASE instructions
-* MIPS floating-point:: Directives to override floating-point options
-
-
-File: as.info, Node: MIPS Opts, Next: MIPS Object, Up: MIPS-Dependent
-
-9.24.1 Assembler options
-------------------------
-
-The MIPS configurations of GNU `as' support these special options:
-
-`-G NUM'
- This option sets the largest size of an object that can be
- referenced implicitly with the `gp' register. It is only accepted
- for targets that use ECOFF format. The default value is 8.
-
-`-EB'
-`-EL'
- Any MIPS configuration of `as' can select big-endian or
- little-endian output at run time (unlike the other GNU development
- tools, which must be configured for one or the other). Use `-EB'
- to select big-endian output, and `-EL' for little-endian.
-
-`-KPIC'
- Generate SVR4-style PIC. This option tells the assembler to
- generate SVR4-style position-independent macro expansions. It
- also tells the assembler to mark the output file as PIC.
-
-`-mvxworks-pic'
- Generate VxWorks PIC. This option tells the assembler to generate
- VxWorks-style position-independent macro expansions.
-
-`-mips1'
-`-mips2'
-`-mips3'
-`-mips4'
-`-mips5xo'
-`-mips32'
-`-mips32r2'
-`-mips64'
-`-mips64r2'
- Generate code for a particular MIPS Instruction Set Architecture
- level. `-mips1' corresponds to the R2000 and R3000 processors,
- `-mips2' to the R6000 processor, `-mips3' to the R4000 processor,
- and `-mips4' to the R8000 and R10000 processors. `-mips5',
- `-mips32', `-mips32r2', `-mips64', and `-mips64r2' correspond to
- generic MIPS V, MIPS32, MIPS32 RELEASE 2, MIPS64, and MIPS64
- RELEASE 2 ISA processors, respectively. You can also switch
- instruction sets during the assembly; see *note Directives to
- override the ISA level: MIPS ISA.
-
-`-mgp32'
-`-mfp32'
- Some macros have different expansions for 32-bit and 64-bit
- registers. The register sizes are normally inferred from the ISA
- and ABI, but these flags force a certain group of registers to be
- treated as 32 bits wide at all times. `-mgp32' controls the size
- of general-purpose registers and `-mfp32' controls the size of
- floating-point registers.
-
- The `.set gp=32' and `.set fp=32' directives allow the size of
- registers to be changed for parts of an object. The default value
- is restored by `.set gp=default' and `.set fp=default'.
-
- On some MIPS variants there is a 32-bit mode flag; when this flag
- is set, 64-bit instructions generate a trap. Also, some 32-bit
- OSes only save the 32-bit registers on a context switch, so it is
- essential never to use the 64-bit registers.
-
-`-mgp64'
-`-mfp64'
- Assume that 64-bit registers are available. This is provided in
- the interests of symmetry with `-mgp32' and `-mfp32'.
-
- The `.set gp=64' and `.set fp=64' directives allow the size of
- registers to be changed for parts of an object. The default value
- is restored by `.set gp=default' and `.set fp=default'.
-
-`-mips16'
-`-no-mips16'
- Generate code for the MIPS 16 processor. This is equivalent to
- putting `.set mips16' at the start of the assembly file.
- `-no-mips16' turns off this option.
-
-`-msmartmips'
-`-mno-smartmips'
- Enables the SmartMIPS extensions to the MIPS32 instruction set,
- which provides a number of new instructions which target smartcard
- and cryptographic applications. This is equivalent to putting
- `.set smartmips' at the start of the assembly file.
- `-mno-smartmips' turns off this option.
-
-`-mips3d'
-`-no-mips3d'
- Generate code for the MIPS-3D Application Specific Extension.
- This tells the assembler to accept MIPS-3D instructions.
- `-no-mips3d' turns off this option.
-
-`-mdmx'
-`-no-mdmx'
- Generate code for the MDMX Application Specific Extension. This
- tells the assembler to accept MDMX instructions. `-no-mdmx' turns
- off this option.
-
-`-mdsp'
-`-mno-dsp'
- Generate code for the DSP Release 1 Application Specific Extension.
- This tells the assembler to accept DSP Release 1 instructions.
- `-mno-dsp' turns off this option.
-
-`-mdspr2'
-`-mno-dspr2'
- Generate code for the DSP Release 2 Application Specific Extension.
- This option implies -mdsp. This tells the assembler to accept DSP
- Release 2 instructions. `-mno-dspr2' turns off this option.
-
-`-mmt'
-`-mno-mt'
- Generate code for the MT Application Specific Extension. This
- tells the assembler to accept MT instructions. `-mno-mt' turns
- off this option.
-
-`-mfix7000'
-`-mno-fix7000'
- Cause nops to be inserted if the read of the destination register
- of an mfhi or mflo instruction occurs in the following two
- instructions.
-
-`-mfix-loongson2f-jump'
-`-mno-fix-loongson2f-jump'
- Eliminate instruction fetch from outside 256M region to work
- around the Loongson2F `jump' instructions. Without it, under
- extreme cases, the kernel may crash. The issue has been solved in
- latest processor batches, but this fix has no side effect to them.
-
-`-mfix-loongson2f-nop'
-`-mno-fix-loongson2f-nop'
- Replace nops by `or at,at,zero' to work around the Loongson2F
- `nop' errata. Without it, under extreme cases, cpu might
- deadlock. The issue has been solved in latest loongson2f batches,
- but this fix has no side effect to them.
-
-`-mfix-vr4120'
-`-mno-fix-vr4120'
- Insert nops to work around certain VR4120 errata. This option is
- intended to be used on GCC-generated code: it is not designed to
- catch all problems in hand-written assembler code.
-
-`-mfix-vr4130'
-`-mno-fix-vr4130'
- Insert nops to work around the VR4130 `mflo'/`mfhi' errata.
-
-`-mfix-24k'
-`-no-mfix-24k'
- Insert nops to work around the 24K `eret'/`deret' errata.
-
-`-mfix-cn63xxp1'
-`-mno-fix-cn63xxp1'
- Replace `pref' hints 0 - 4 and 6 - 24 with hint 28 to work around
- certain CN63XXP1 errata.
-
-`-m4010'
-`-no-m4010'
- Generate code for the LSI R4010 chip. This tells the assembler to
- accept the R4010 specific instructions (`addciu', `ffc', etc.),
- and to not schedule `nop' instructions around accesses to the `HI'
- and `LO' registers. `-no-m4010' turns off this option.
-
-`-m4650'
-`-no-m4650'
- Generate code for the MIPS R4650 chip. This tells the assembler
- to accept the `mad' and `madu' instruction, and to not schedule
- `nop' instructions around accesses to the `HI' and `LO' registers.
- `-no-m4650' turns off this option.
-
-`-m3900'
-`-no-m3900'
-`-m4100'
-`-no-m4100'
- For each option `-mNNNN', generate code for the MIPS RNNNN chip.
- This tells the assembler to accept instructions specific to that
- chip, and to schedule for that chip's hazards.
-
-`-march=CPU'
- Generate code for a particular MIPS cpu. It is exactly equivalent
- to `-mCPU', except that there are more value of CPU understood.
- Valid CPU value are:
-
- 2000, 3000, 3900, 4000, 4010, 4100, 4111, vr4120, vr4130,
- vr4181, 4300, 4400, 4600, 4650, 5000, rm5200, rm5230, rm5231,
- rm5261, rm5721, vr5400, vr5500, 6000, rm7000, 8000, rm9000,
- 10000, 12000, 14000, 16000, 4kc, 4km, 4kp, 4ksc, 4kec, 4kem,
- 4kep, 4ksd, m4k, m4kp, 24kc, 24kf2_1, 24kf, 24kf1_1, 24kec,
- 24kef2_1, 24kef, 24kef1_1, 34kc, 34kf2_1, 34kf, 34kf1_1, 74kc,
- 74kf2_1, 74kf, 74kf1_1, 74kf3_2, 1004kc, 1004kf2_1, 1004kf,
- 1004kf1_1, 5kc, 5kf, 20kc, 25kf, sb1, sb1a, loongson2e,
- loongson2f, octeon, xlr
-
- For compatibility reasons, `Nx' and `Bfx' are accepted as synonyms
- for `Nf1_1'. These values are deprecated.
-
-`-mtune=CPU'
- Schedule and tune for a particular MIPS cpu. Valid CPU values are
- identical to `-march=CPU'.
-
-`-mabi=ABI'
- Record which ABI the source code uses. The recognized arguments
- are: `32', `n32', `o64', `64' and `eabi'.
-
-`-msym32'
-`-mno-sym32'
- Equivalent to adding `.set sym32' or `.set nosym32' to the
- beginning of the assembler input. *Note MIPS symbol sizes::.
-
-`-nocpp'
- This option is ignored. It is accepted for command-line
- compatibility with other assemblers, which use it to turn off C
- style preprocessing. With GNU `as', there is no need for
- `-nocpp', because the GNU assembler itself never runs the C
- preprocessor.
-
-`-msoft-float'
-`-mhard-float'
- Disable or enable floating-point instructions. Note that by
- default floating-point instructions are always allowed even with
- CPU targets that don't have support for these instructions.
-
-`-msingle-float'
-`-mdouble-float'
- Disable or enable double-precision floating-point operations. Note
- that by default double-precision floating-point operations are
- always allowed even with CPU targets that don't have support for
- these operations.
-
-`--construct-floats'
-`--no-construct-floats'
- The `--no-construct-floats' option disables the construction of
- double width floating point constants by loading the two halves of
- the value into the two single width floating point registers that
- make up the double width register. This feature is useful if the
- processor support the FR bit in its status register, and this bit
- is known (by the programmer) to be set. This bit prevents the
- aliasing of the double width register by the single width
- registers.
-
- By default `--construct-floats' is selected, allowing construction
- of these floating point constants.
-
-`--trap'
-`--no-break'
- `as' automatically macro expands certain division and
- multiplication instructions to check for overflow and division by
- zero. This option causes `as' to generate code to take a trap
- exception rather than a break exception when an error is detected.
- The trap instructions are only supported at Instruction Set
- Architecture level 2 and higher.
-
-`--break'
-`--no-trap'
- Generate code to take a break exception rather than a trap
- exception when an error is detected. This is the default.
-
-`-mpdr'
-`-mno-pdr'
- Control generation of `.pdr' sections. Off by default on IRIX, on
- elsewhere.
-
-`-mshared'
-`-mno-shared'
- When generating code using the Unix calling conventions (selected
- by `-KPIC' or `-mcall_shared'), gas will normally generate code
- which can go into a shared library. The `-mno-shared' option
- tells gas to generate code which uses the calling convention, but
- can not go into a shared library. The resulting code is slightly
- more efficient. This option only affects the handling of the
- `.cpload' and `.cpsetup' pseudo-ops.
-
-
-File: as.info, Node: MIPS Object, Next: MIPS Stabs, Prev: MIPS Opts, Up: MIPS-Dependent
-
-9.24.2 MIPS ECOFF object code
------------------------------
-
-Assembling for a MIPS ECOFF target supports some additional sections
-besides the usual `.text', `.data' and `.bss'. The additional sections
-are `.rdata', used for read-only data, `.sdata', used for small data,
-and `.sbss', used for small common objects.
-
- When assembling for ECOFF, the assembler uses the `$gp' (`$28')
-register to form the address of a "small object". Any object in the
-`.sdata' or `.sbss' sections is considered "small" in this sense. For
-external objects, or for objects in the `.bss' section, you can use the
-`gcc' `-G' option to control the size of objects addressed via `$gp';
-the default value is 8, meaning that a reference to any object eight
-bytes or smaller uses `$gp'. Passing `-G 0' to `as' prevents it from
-using the `$gp' register on the basis of object size (but the assembler
-uses `$gp' for objects in `.sdata' or `sbss' in any case). The size of
-an object in the `.bss' section is set by the `.comm' or `.lcomm'
-directive that defines it. The size of an external object may be set
-with the `.extern' directive. For example, `.extern sym,4' declares
-that the object at `sym' is 4 bytes in length, whie leaving `sym'
-otherwise undefined.
-
- Using small ECOFF objects requires linker support, and assumes that
-the `$gp' register is correctly initialized (normally done
-automatically by the startup code). MIPS ECOFF assembly code must not
-modify the `$gp' register.
-
-
-File: as.info, Node: MIPS Stabs, Next: MIPS ISA, Prev: MIPS Object, Up: MIPS-Dependent
-
-9.24.3 Directives for debugging information
--------------------------------------------
-
-MIPS ECOFF `as' supports several directives used for generating
-debugging information which are not support by traditional MIPS
-assemblers. These are `.def', `.endef', `.dim', `.file', `.scl',
-`.size', `.tag', `.type', `.val', `.stabd', `.stabn', and `.stabs'.
-The debugging information generated by the three `.stab' directives can
-only be read by GDB, not by traditional MIPS debuggers (this
-enhancement is required to fully support C++ debugging). These
-directives are primarily used by compilers, not assembly language
-programmers!
-
-
-File: as.info, Node: MIPS symbol sizes, Next: MIPS autoextend, Prev: MIPS ISA, Up: MIPS-Dependent
-
-9.24.4 Directives to override the size of symbols
--------------------------------------------------
-
-The n64 ABI allows symbols to have any 64-bit value. Although this
-provides a great deal of flexibility, it means that some macros have
-much longer expansions than their 32-bit counterparts. For example,
-the non-PIC expansion of `dla $4,sym' is usually:
-
- lui $4,%highest(sym)
- lui $1,%hi(sym)
- daddiu $4,$4,%higher(sym)
- daddiu $1,$1,%lo(sym)
- dsll32 $4,$4,0
- daddu $4,$4,$1
-
- whereas the 32-bit expansion is simply:
-
- lui $4,%hi(sym)
- daddiu $4,$4,%lo(sym)
-
- n64 code is sometimes constructed in such a way that all symbolic
-constants are known to have 32-bit values, and in such cases, it's
-preferable to use the 32-bit expansion instead of the 64-bit expansion.
-
- You can use the `.set sym32' directive to tell the assembler that,
-from this point on, all expressions of the form `SYMBOL' or `SYMBOL +
-OFFSET' have 32-bit values. For example:
-
- .set sym32
- dla $4,sym
- lw $4,sym+16
- sw $4,sym+0x8000($4)
-
- will cause the assembler to treat `sym', `sym+16' and `sym+0x8000'
-as 32-bit values. The handling of non-symbolic addresses is not
-affected.
-
- The directive `.set nosym32' ends a `.set sym32' block and reverts
-to the normal behavior. It is also possible to change the symbol size
-using the command-line options `-msym32' and `-mno-sym32'.
-
- These options and directives are always accepted, but at present,
-they have no effect for anything other than n64.
-
-
-File: as.info, Node: MIPS ISA, Next: MIPS symbol sizes, Prev: MIPS Stabs, Up: MIPS-Dependent
-
-9.24.5 Directives to override the ISA level
--------------------------------------------
-
-GNU `as' supports an additional directive to change the MIPS
-Instruction Set Architecture level on the fly: `.set mipsN'. N should
-be a number from 0 to 5, or 32, 32r2, 64 or 64r2. The values other
-than 0 make the assembler accept instructions for the corresponding ISA
-level, from that point on in the assembly. `.set mipsN' affects not
-only which instructions are permitted, but also how certain macros are
-expanded. `.set mips0' restores the ISA level to its original level:
-either the level you selected with command line options, or the default
-for your configuration. You can use this feature to permit specific
-MIPS3 instructions while assembling in 32 bit mode. Use this directive
-with care!
-
- The `.set arch=CPU' directive provides even finer control. It
-changes the effective CPU target and allows the assembler to use
-instructions specific to a particular CPU. All CPUs supported by the
-`-march' command line option are also selectable by this directive.
-The original value is restored by `.set arch=default'.
-
- The directive `.set mips16' puts the assembler into MIPS 16 mode, in
-which it will assemble instructions for the MIPS 16 processor. Use
-`.set nomips16' to return to normal 32 bit mode.
-
- Traditional MIPS assemblers do not support this directive.
-
-
-File: as.info, Node: MIPS autoextend, Next: MIPS insn, Prev: MIPS symbol sizes, Up: MIPS-Dependent
-
-9.24.6 Directives for extending MIPS 16 bit instructions
---------------------------------------------------------
-
-By default, MIPS 16 instructions are automatically extended to 32 bits
-when necessary. The directive `.set noautoextend' will turn this off.
-When `.set noautoextend' is in effect, any 32 bit instruction must be
-explicitly extended with the `.e' modifier (e.g., `li.e $4,1000'). The
-directive `.set autoextend' may be used to once again automatically
-extend instructions when necessary.
-
- This directive is only meaningful when in MIPS 16 mode. Traditional
-MIPS assemblers do not support this directive.
-
-
-File: as.info, Node: MIPS insn, Next: MIPS option stack, Prev: MIPS autoextend, Up: MIPS-Dependent
-
-9.24.7 Directive to mark data as an instruction
------------------------------------------------
-
-The `.insn' directive tells `as' that the following data is actually
-instructions. This makes a difference in MIPS 16 mode: when loading
-the address of a label which precedes instructions, `as' automatically
-adds 1 to the value, so that jumping to the loaded address will do the
-right thing.
-
- The `.global' and `.globl' directives supported by `as' will by
-default mark the symbol as pointing to a region of data not code. This
-means that, for example, any instructions following such a symbol will
-not be disassembled by `objdump' as it will regard them as data. To
-change this behaviour an optional section name can be placed after the
-symbol name in the `.global' directive. If this section exists and is
-known to be a code section, then the symbol will be marked as poiting at
-code not data. Ie the syntax for the directive is:
-
- `.global SYMBOL[ SECTION][, SYMBOL[ SECTION]] ...',
-
- Here is a short example:
-
- .global foo .text, bar, baz .data
- foo:
- nop
- bar:
- .word 0x0
- baz:
- .word 0x1
-
-
-File: as.info, Node: MIPS option stack, Next: MIPS ASE instruction generation overrides, Prev: MIPS insn, Up: MIPS-Dependent
-
-9.24.8 Directives to save and restore options
----------------------------------------------
-
-The directives `.set push' and `.set pop' may be used to save and
-restore the current settings for all the options which are controlled
-by `.set'. The `.set push' directive saves the current settings on a
-stack. The `.set pop' directive pops the stack and restores the
-settings.
-
- These directives can be useful inside an macro which must change an
-option such as the ISA level or instruction reordering but does not want
-to change the state of the code which invoked the macro.
-
- Traditional MIPS assemblers do not support these directives.
-
-
-File: as.info, Node: MIPS ASE instruction generation overrides, Next: MIPS floating-point, Prev: MIPS option stack, Up: MIPS-Dependent
-
-9.24.9 Directives to control generation of MIPS ASE instructions
-----------------------------------------------------------------
-
-The directive `.set mips3d' makes the assembler accept instructions
-from the MIPS-3D Application Specific Extension from that point on in
-the assembly. The `.set nomips3d' directive prevents MIPS-3D
-instructions from being accepted.
-
- The directive `.set smartmips' makes the assembler accept
-instructions from the SmartMIPS Application Specific Extension to the
-MIPS32 ISA from that point on in the assembly. The `.set nosmartmips'
-directive prevents SmartMIPS instructions from being accepted.
-
- The directive `.set mdmx' makes the assembler accept instructions
-from the MDMX Application Specific Extension from that point on in the
-assembly. The `.set nomdmx' directive prevents MDMX instructions from
-being accepted.
-
- The directive `.set dsp' makes the assembler accept instructions
-from the DSP Release 1 Application Specific Extension from that point
-on in the assembly. The `.set nodsp' directive prevents DSP Release 1
-instructions from being accepted.
-
- The directive `.set dspr2' makes the assembler accept instructions
-from the DSP Release 2 Application Specific Extension from that point
-on in the assembly. This dirctive implies `.set dsp'. The `.set
-nodspr2' directive prevents DSP Release 2 instructions from being
-accepted.
-
- The directive `.set mt' makes the assembler accept instructions from
-the MT Application Specific Extension from that point on in the
-assembly. The `.set nomt' directive prevents MT instructions from
-being accepted.
-
- Traditional MIPS assemblers do not support these directives.
-
-
-File: as.info, Node: MIPS floating-point, Prev: MIPS ASE instruction generation overrides, Up: MIPS-Dependent
-
-9.24.10 Directives to override floating-point options
------------------------------------------------------
-
-The directives `.set softfloat' and `.set hardfloat' provide finer
-control of disabling and enabling float-point instructions. These
-directives always override the default (that hard-float instructions
-are accepted) or the command-line options (`-msoft-float' and
-`-mhard-float').
-
- The directives `.set singlefloat' and `.set doublefloat' provide
-finer control of disabling and enabling double-precision float-point
-operations. These directives always override the default (that
-double-precision operations are accepted) or the command-line options
-(`-msingle-float' and `-mdouble-float').
-
- Traditional MIPS assemblers do not support these directives.
-
-
-File: as.info, Node: MMIX-Dependent, Next: MSP430-Dependent, Prev: MIPS-Dependent, Up: Machine Dependencies
-
-9.25 MMIX Dependent Features
-============================
-
-* Menu:
-
-* MMIX-Opts:: Command-line Options
-* MMIX-Expand:: Instruction expansion
-* MMIX-Syntax:: Syntax
-* MMIX-mmixal:: Differences to `mmixal' syntax and semantics
-
-
-File: as.info, Node: MMIX-Opts, Next: MMIX-Expand, Up: MMIX-Dependent
-
-9.25.1 Command-line Options
----------------------------
-
-The MMIX version of `as' has some machine-dependent options.
-
- When `--fixed-special-register-names' is specified, only the register
-names specified in *note MMIX-Regs:: are recognized in the instructions
-`PUT' and `GET'.
-
- You can use the `--globalize-symbols' to make all symbols global.
-This option is useful when splitting up a `mmixal' program into several
-files.
-
- The `--gnu-syntax' turns off most syntax compatibility with
-`mmixal'. Its usability is currently doubtful.
-
- The `--relax' option is not fully supported, but will eventually make
-the object file prepared for linker relaxation.
-
- If you want to avoid inadvertently calling a predefined symbol and
-would rather get an error, for example when using `as' with a compiler
-or other machine-generated code, specify `--no-predefined-syms'. This
-turns off built-in predefined definitions of all such symbols,
-including rounding-mode symbols, segment symbols, `BIT' symbols, and
-`TRAP' symbols used in `mmix' "system calls". It also turns off
-predefined special-register names, except when used in `PUT' and `GET'
-instructions.
-
- By default, some instructions are expanded to fit the size of the
-operand or an external symbol (*note MMIX-Expand::). By passing
-`--no-expand', no such expansion will be done, instead causing errors
-at link time if the operand does not fit.
-
- The `mmixal' documentation (*note mmixsite::) specifies that global
-registers allocated with the `GREG' directive (*note MMIX-greg::) and
-initialized to the same non-zero value, will refer to the same global
-register. This isn't strictly enforceable in `as' since the final
-addresses aren't known until link-time, but it will do an effort unless
-the `--no-merge-gregs' option is specified. (Register merging isn't
-yet implemented in `ld'.)
-
- `as' will warn every time it expands an instruction to fit an
-operand unless the option `-x' is specified. It is believed that this
-behaviour is more useful than just mimicking `mmixal''s behaviour, in
-which instructions are only expanded if the `-x' option is specified,
-and assembly fails otherwise, when an instruction needs to be expanded.
-It needs to be kept in mind that `mmixal' is both an assembler and
-linker, while `as' will expand instructions that at link stage can be
-contracted. (Though linker relaxation isn't yet implemented in `ld'.)
-The option `-x' also imples `--linker-allocated-gregs'.
-
- If instruction expansion is enabled, `as' can expand a `PUSHJ'
-instruction into a series of instructions. The shortest expansion is
-to not expand it, but just mark the call as redirectable to a stub,
-which `ld' creates at link-time, but only if the original `PUSHJ'
-instruction is found not to reach the target. The stub consists of the
-necessary instructions to form a jump to the target. This happens if
-`as' can assert that the `PUSHJ' instruction can reach such a stub.
-The option `--no-pushj-stubs' disables this shorter expansion, and the
-longer series of instructions is then created at assembly-time. The
-option `--no-stubs' is a synonym, intended for compatibility with
-future releases, where generation of stubs for other instructions may
-be implemented.
-
- Usually a two-operand-expression (*note GREG-base::) without a
-matching `GREG' directive is treated as an error by `as'. When the
-option `--linker-allocated-gregs' is in effect, they are instead passed
-through to the linker, which will allocate as many global registers as
-is needed.
-
-
-File: as.info, Node: MMIX-Expand, Next: MMIX-Syntax, Prev: MMIX-Opts, Up: MMIX-Dependent
-
-9.25.2 Instruction expansion
-----------------------------
-
-When `as' encounters an instruction with an operand that is either not
-known or does not fit the operand size of the instruction, `as' (and
-`ld') will expand the instruction into a sequence of instructions
-semantically equivalent to the operand fitting the instruction.
-Expansion will take place for the following instructions:
-
-`GETA'
- Expands to a sequence of four instructions: `SETL', `INCML',
- `INCMH' and `INCH'. The operand must be a multiple of four.
-
-Conditional branches
- A branch instruction is turned into a branch with the complemented
- condition and prediction bit over five instructions; four
- instructions setting `$255' to the operand value, which like with
- `GETA' must be a multiple of four, and a final `GO $255,$255,0'.
-
-`PUSHJ'
- Similar to expansion for conditional branches; four instructions
- set `$255' to the operand value, followed by a `PUSHGO
- $255,$255,0'.
-
-`JMP'
- Similar to conditional branches and `PUSHJ'. The final instruction
- is `GO $255,$255,0'.
-
- The linker `ld' is expected to shrink these expansions for code
-assembled with `--relax' (though not currently implemented).
-
-
-File: as.info, Node: MMIX-Syntax, Next: MMIX-mmixal, Prev: MMIX-Expand, Up: MMIX-Dependent
-
-9.25.3 Syntax
--------------
-
-The assembly syntax is supposed to be upward compatible with that
-described in Sections 1.3 and 1.4 of `The Art of Computer Programming,
-Volume 1'. Draft versions of those chapters as well as other MMIX
-information is located at
-`http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html'. Most code
-examples from the mmixal package located there should work unmodified
-when assembled and linked as single files, with a few noteworthy
-exceptions (*note MMIX-mmixal::).
-
- Before an instruction is emitted, the current location is aligned to
-the next four-byte boundary. If a label is defined at the beginning of
-the line, its value will be the aligned value.
-
- In addition to the traditional hex-prefix `0x', a hexadecimal number
-can also be specified by the prefix character `#'.
-
- After all operands to an MMIX instruction or directive have been
-specified, the rest of the line is ignored, treated as a comment.
-
-* Menu:
-
-* MMIX-Chars:: Special Characters
-* MMIX-Symbols:: Symbols
-* MMIX-Regs:: Register Names
-* MMIX-Pseudos:: Assembler Directives
-
-
-File: as.info, Node: MMIX-Chars, Next: MMIX-Symbols, Up: MMIX-Syntax
-
-9.25.3.1 Special Characters
-...........................
-
-The characters `*' and `#' are line comment characters; each start a
-comment at the beginning of a line, but only at the beginning of a
-line. A `#' prefixes a hexadecimal number if found elsewhere on a line.
-
- Two other characters, `%' and `!', each start a comment anywhere on
-the line. Thus you can't use the `modulus' and `not' operators in
-expressions normally associated with these two characters.
-
- A `;' is a line separator, treated as a new-line, so separate
-instructions can be specified on a single line.
-
-
-File: as.info, Node: MMIX-Symbols, Next: MMIX-Regs, Prev: MMIX-Chars, Up: MMIX-Syntax
-
-9.25.3.2 Symbols
-................
-
-The character `:' is permitted in identifiers. There are two
-exceptions to it being treated as any other symbol character: if a
-symbol begins with `:', it means that the symbol is in the global
-namespace and that the current prefix should not be prepended to that
-symbol (*note MMIX-prefix::). The `:' is then not considered part of
-the symbol. For a symbol in the label position (first on a line), a `:'
-at the end of a symbol is silently stripped off. A label is permitted,
-but not required, to be followed by a `:', as with many other assembly
-formats.
-
- The character `@' in an expression, is a synonym for `.', the
-current location.
-
- In addition to the common forward and backward local symbol formats
-(*note Symbol Names::), they can be specified with upper-case `B' and
-`F', as in `8B' and `9F'. A local label defined for the current
-position is written with a `H' appended to the number:
- 3H LDB $0,$1,2
- This and traditional local-label formats cannot be mixed: a label
-must be defined and referred to using the same format.
-
- There's a minor caveat: just as for the ordinary local symbols, the
-local symbols are translated into ordinary symbols using control
-characters are to hide the ordinal number of the symbol.
-Unfortunately, these symbols are not translated back in error messages.
-Thus you may see confusing error messages when local symbols are used.
-Control characters `\003' (control-C) and `\004' (control-D) are used
-for the MMIX-specific local-symbol syntax.
-
- The symbol `Main' is handled specially; it is always global.
-
- By defining the symbols `__.MMIX.start..text' and
-`__.MMIX.start..data', the address of respectively the `.text' and
-`.data' segments of the final program can be defined, though when
-linking more than one object file, the code or data in the object file
-containing the symbol is not guaranteed to be start at that position;
-just the final executable. *Note MMIX-loc::.
-
-
-File: as.info, Node: MMIX-Regs, Next: MMIX-Pseudos, Prev: MMIX-Symbols, Up: MMIX-Syntax
-
-9.25.3.3 Register names
-.......................
-
-Local and global registers are specified as `$0' to `$255'. The
-recognized special register names are `rJ', `rA', `rB', `rC', `rD',
-`rE', `rF', `rG', `rH', `rI', `rK', `rL', `rM', `rN', `rO', `rP', `rQ',
-`rR', `rS', `rT', `rU', `rV', `rW', `rX', `rY', `rZ', `rBB', `rTT',
-`rWW', `rXX', `rYY' and `rZZ'. A leading `:' is optional for special
-register names.
-
- Local and global symbols can be equated to register names and used in
-place of ordinary registers.
-
- Similarly for special registers, local and global symbols can be
-used. Also, symbols equated from numbers and constant expressions are
-allowed in place of a special register, except when either of the
-options `--no-predefined-syms' and `--fixed-special-register-names' are
-specified. Then only the special register names above are allowed for
-the instructions having a special register operand; `GET' and `PUT'.
-
-
-File: as.info, Node: MMIX-Pseudos, Prev: MMIX-Regs, Up: MMIX-Syntax
-
-9.25.3.4 Assembler Directives
-.............................
-
-`LOC'
- The `LOC' directive sets the current location to the value of the
- operand field, which may include changing sections. If the
- operand is a constant, the section is set to either `.data' if the
- value is `0x2000000000000000' or larger, else it is set to `.text'.
- Within a section, the current location may only be changed to
- monotonically higher addresses. A LOC expression must be a
- previously defined symbol or a "pure" constant.
-
- An example, which sets the label PREV to the current location, and
- updates the current location to eight bytes forward:
- prev LOC @+8
-
- When a LOC has a constant as its operand, a symbol
- `__.MMIX.start..text' or `__.MMIX.start..data' is defined
- depending on the address as mentioned above. Each such symbol is
- interpreted as special by the linker, locating the section at that
- address. Note that if multiple files are linked, the first object
- file with that section will be mapped to that address (not
- necessarily the file with the LOC definition).
-
-`LOCAL'
- Example:
- LOCAL external_symbol
- LOCAL 42
- .local asymbol
-
- This directive-operation generates a link-time assertion that the
- operand does not correspond to a global register. The operand is
- an expression that at link-time resolves to a register symbol or a
- number. A number is treated as the register having that number.
- There is one restriction on the use of this directive: the
- pseudo-directive must be placed in a section with contents, code
- or data.
-
-`IS'
- The `IS' directive:
- asymbol IS an_expression
- sets the symbol `asymbol' to `an_expression'. A symbol may not be
- set more than once using this directive. Local labels may be set
- using this directive, for example:
- 5H IS @+4
-
-`GREG'
- This directive reserves a global register, gives it an initial
- value and optionally gives it a symbolic name. Some examples:
-
- areg GREG
- breg GREG data_value
- GREG data_buffer
- .greg creg, another_data_value
-
- The symbolic register name can be used in place of a (non-special)
- register. If a value isn't provided, it defaults to zero. Unless
- the option `--no-merge-gregs' is specified, non-zero registers
- allocated with this directive may be eliminated by `as'; another
- register with the same value used in its place. Any of the
- instructions `CSWAP', `GO', `LDA', `LDBU', `LDB', `LDHT', `LDOU',
- `LDO', `LDSF', `LDTU', `LDT', `LDUNC', `LDVTS', `LDWU', `LDW',
- `PREGO', `PRELD', `PREST', `PUSHGO', `STBU', `STB', `STCO', `STHT',
- `STOU', `STSF', `STTU', `STT', `STUNC', `SYNCD', `SYNCID', can
- have a value nearby an initial value in place of its second and
- third operands. Here, "nearby" is defined as within the range
- 0...255 from the initial value of such an allocated register.
-
- buffer1 BYTE 0,0,0,0,0
- buffer2 BYTE 0,0,0,0,0
- ...
- GREG buffer1
- LDOU $42,buffer2
- In the example above, the `Y' field of the `LDOUI' instruction
- (LDOU with a constant Z) will be replaced with the global register
- allocated for `buffer1', and the `Z' field will have the value 5,
- the offset from `buffer1' to `buffer2'. The result is equivalent
- to this code:
- buffer1 BYTE 0,0,0,0,0
- buffer2 BYTE 0,0,0,0,0
- ...
- tmpreg GREG buffer1
- LDOU $42,tmpreg,(buffer2-buffer1)
-
- Global registers allocated with this directive are allocated in
- order higher-to-lower within a file. Other than that, the exact
- order of register allocation and elimination is undefined. For
- example, the order is undefined when more than one file with such
- directives are linked together. With the options `-x' and
- `--linker-allocated-gregs', `GREG' directives for two-operand
- cases like the one mentioned above can be omitted. Sufficient
- global registers will then be allocated by the linker.
-
-`BYTE'
- The `BYTE' directive takes a series of operands separated by a
- comma. If an operand is a string (*note Strings::), each
- character of that string is emitted as a byte. Other operands
- must be constant expressions without forward references, in the
- range 0...255. If you need operands having expressions with
- forward references, use `.byte' (*note Byte::). An operand can be
- omitted, defaulting to a zero value.
-
-`WYDE'
-`TETRA'
-`OCTA'
- The directives `WYDE', `TETRA' and `OCTA' emit constants of two,
- four and eight bytes size respectively. Before anything else
- happens for the directive, the current location is aligned to the
- respective constant-size boundary. If a label is defined at the
- beginning of the line, its value will be that after the alignment.
- A single operand can be omitted, defaulting to a zero value
- emitted for the directive. Operands can be expressed as strings
- (*note Strings::), in which case each character in the string is
- emitted as a separate constant of the size indicated by the
- directive.
-
-`PREFIX'
- The `PREFIX' directive sets a symbol name prefix to be prepended to
- all symbols (except local symbols, *note MMIX-Symbols::), that are
- not prefixed with `:', until the next `PREFIX' directive. Such
- prefixes accumulate. For example,
- PREFIX a
- PREFIX b
- c IS 0
- defines a symbol `abc' with the value 0.
-
-`BSPEC'
-`ESPEC'
- A pair of `BSPEC' and `ESPEC' directives delimit a section of
- special contents (without specified semantics). Example:
- BSPEC 42
- TETRA 1,2,3
- ESPEC
- The single operand to `BSPEC' must be number in the range 0...255.
- The `BSPEC' number 80 is used by the GNU binutils implementation.
-
-
-File: as.info, Node: MMIX-mmixal, Prev: MMIX-Syntax, Up: MMIX-Dependent
-
-9.25.4 Differences to `mmixal'
-------------------------------
-
-The binutils `as' and `ld' combination has a few differences in
-function compared to `mmixal' (*note mmixsite::).
-
- The replacement of a symbol with a GREG-allocated register (*note
-GREG-base::) is not handled the exactly same way in `as' as in
-`mmixal'. This is apparent in the `mmixal' example file `inout.mms',
-where different registers with different offsets, eventually yielding
-the same address, are used in the first instruction. This type of
-difference should however not affect the function of any program unless
-it has specific assumptions about the allocated register number.
-
- Line numbers (in the `mmo' object format) are currently not
-supported.
-
- Expression operator precedence is not that of mmixal: operator
-precedence is that of the C programming language. It's recommended to
-use parentheses to explicitly specify wanted operator precedence
-whenever more than one type of operators are used.
-
- The serialize unary operator `&', the fractional division operator
-`//', the logical not operator `!' and the modulus operator `%' are not
-available.
-
- Symbols are not global by default, unless the option
-`--globalize-symbols' is passed. Use the `.global' directive to
-globalize symbols (*note Global::).
-
- Operand syntax is a bit stricter with `as' than `mmixal'. For
-example, you can't say `addu 1,2,3', instead you must write `addu
-$1,$2,3'.
-
- You can't LOC to a lower address than those already visited (i.e.,
-"backwards").
-
- A LOC directive must come before any emitted code.
-
- Predefined symbols are visible as file-local symbols after use. (In
-the ELF file, that is--the linked mmo file has no notion of a file-local
-symbol.)
-
- Some mapping of constant expressions to sections in LOC expressions
-is attempted, but that functionality is easily confused and should be
-avoided unless compatibility with `mmixal' is required. A LOC
-expression to `0x2000000000000000' or higher, maps to the `.data'
-section and lower addresses map to the `.text' section (*note
-MMIX-loc::).
-
- The code and data areas are each contiguous. Sparse programs with
-far-away LOC directives will take up the same amount of space as a
-contiguous program with zeros filled in the gaps between the LOC
-directives. If you need sparse programs, you might try and get the
-wanted effect with a linker script and splitting up the code parts into
-sections (*note Section::). Assembly code for this, to be compatible
-with `mmixal', would look something like:
- .if 0
- LOC away_expression
- .else
- .section away,"ax"
- .fi
- `as' will not execute the LOC directive and `mmixal' ignores the
-lines with `.'. This construct can be used generally to help
-compatibility.
-
- Symbols can't be defined twice-not even to the same value.
-
- Instruction mnemonics are recognized case-insensitive, though the
-`IS' and `GREG' pseudo-operations must be specified in upper-case
-characters.
-
- There's no unicode support.
-
- The following is a list of programs in `mmix.tar.gz', available at
-`http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html', last
-checked with the version dated 2001-08-25 (md5sum
-c393470cfc86fac040487d22d2bf0172) that assemble with `mmixal' but do
-not assemble with `as':
-
-`silly.mms'
- LOC to a previous address.
-
-`sim.mms'
- Redefines symbol `Done'.
-
-`test.mms'
- Uses the serial operator `&'.
-
-
-File: as.info, Node: MSP430-Dependent, Next: SH-Dependent, Prev: MMIX-Dependent, Up: Machine Dependencies
-
-9.26 MSP 430 Dependent Features
-===============================
-
-* Menu:
-
-* MSP430 Options:: Options
-* MSP430 Syntax:: Syntax
-* MSP430 Floating Point:: Floating Point
-* MSP430 Directives:: MSP 430 Machine Directives
-* MSP430 Opcodes:: Opcodes
-* MSP430 Profiling Capability:: Profiling Capability
-
-
-File: as.info, Node: MSP430 Options, Next: MSP430 Syntax, Up: MSP430-Dependent
-
-9.26.1 Options
---------------
-
-`-m'
- select the mpu arch. Currently has no effect.
-
-`-mP'
- enables polymorph instructions handler.
-
-`-mQ'
- enables relaxation at assembly time. DANGEROUS!
-
-
-
-File: as.info, Node: MSP430 Syntax, Next: MSP430 Floating Point, Prev: MSP430 Options, Up: MSP430-Dependent
-
-9.26.2 Syntax
--------------
-
-* Menu:
-
-* MSP430-Macros:: Macros
-* MSP430-Chars:: Special Characters
-* MSP430-Regs:: Register Names
-* MSP430-Ext:: Assembler Extensions
-
-
-File: as.info, Node: MSP430-Macros, Next: MSP430-Chars, Up: MSP430 Syntax
-
-9.26.2.1 Macros
-...............
-
-The macro syntax used on the MSP 430 is like that described in the MSP
-430 Family Assembler Specification. Normal `as' macros should still
-work.
-
- Additional built-in macros are:
-
-`llo(exp)'
- Extracts least significant word from 32-bit expression 'exp'.
-
-`lhi(exp)'
- Extracts most significant word from 32-bit expression 'exp'.
-
-`hlo(exp)'
- Extracts 3rd word from 64-bit expression 'exp'.
-
-`hhi(exp)'
- Extracts 4rd word from 64-bit expression 'exp'.
-
-
- They normally being used as an immediate source operand.
- mov #llo(1), r10 ; == mov #1, r10
- mov #lhi(1), r10 ; == mov #0, r10
-
-
-File: as.info, Node: MSP430-Chars, Next: MSP430-Regs, Prev: MSP430-Macros, Up: MSP430 Syntax
-
-9.26.2.2 Special Characters
-...........................
-
-`;' is the line comment character.
-
- The character `$' in jump instructions indicates current location and
-implemented only for TI syntax compatibility.
-
-
-File: as.info, Node: MSP430-Regs, Next: MSP430-Ext, Prev: MSP430-Chars, Up: MSP430 Syntax
-
-9.26.2.3 Register Names
-.......................
-
-General-purpose registers are represented by predefined symbols of the
-form `rN' (for global registers), where N represents a number between
-`0' and `15'. The leading letters may be in either upper or lower
-case; for example, `r13' and `R7' are both valid register names.
-
- Register names `PC', `SP' and `SR' cannot be used as register names
-and will be treated as variables. Use `r0', `r1', and `r2' instead.
-
-
-File: as.info, Node: MSP430-Ext, Prev: MSP430-Regs, Up: MSP430 Syntax
-
-9.26.2.4 Assembler Extensions
-.............................
-
-`@rN'
- As destination operand being treated as `0(rn)'
-
-`0(rN)'
- As source operand being treated as `@rn'
-
-`jCOND +N'
- Skips next N bytes followed by jump instruction and equivalent to
- `jCOND $+N+2'
-
-
- Also, there are some instructions, which cannot be found in other
-assemblers. These are branch instructions, which has different opcodes
-upon jump distance. They all got PC relative addressing mode.
-
-`beq label'
- A polymorph instruction which is `jeq label' in case if jump
- distance within allowed range for cpu's jump instruction. If not,
- this unrolls into a sequence of
- jne $+6
- br label
-
-`bne label'
- A polymorph instruction which is `jne label' or `jeq +4; br label'
-
-`blt label'
- A polymorph instruction which is `jl label' or `jge +4; br label'
-
-`bltn label'
- A polymorph instruction which is `jn label' or `jn +2; jmp +4; br
- label'
-
-`bltu label'
- A polymorph instruction which is `jlo label' or `jhs +2; br label'
-
-`bge label'
- A polymorph instruction which is `jge label' or `jl +4; br label'
-
-`bgeu label'
- A polymorph instruction which is `jhs label' or `jlo +4; br label'
-
-`bgt label'
- A polymorph instruction which is `jeq +2; jge label' or `jeq +6;
- jl +4; br label'
-
-`bgtu label'
- A polymorph instruction which is `jeq +2; jhs label' or `jeq +6;
- jlo +4; br label'
-
-`bleu label'
- A polymorph instruction which is `jeq label; jlo label' or `jeq
- +2; jhs +4; br label'
-
-`ble label'
- A polymorph instruction which is `jeq label; jl label' or `jeq
- +2; jge +4; br label'
-
-`jump label'
- A polymorph instruction which is `jmp label' or `br label'
-
-
-File: as.info, Node: MSP430 Floating Point, Next: MSP430 Directives, Prev: MSP430 Syntax, Up: MSP430-Dependent
-
-9.26.3 Floating Point
----------------------
-
-The MSP 430 family uses IEEE 32-bit floating-point numbers.
-
-
-File: as.info, Node: MSP430 Directives, Next: MSP430 Opcodes, Prev: MSP430 Floating Point, Up: MSP430-Dependent
-
-9.26.4 MSP 430 Machine Directives
----------------------------------
-
-`.file'
- This directive is ignored; it is accepted for compatibility with
- other MSP 430 assemblers.
-
- _Warning:_ in other versions of the GNU assembler, `.file' is
- used for the directive called `.app-file' in the MSP 430
- support.
-
-`.line'
- This directive is ignored; it is accepted for compatibility with
- other MSP 430 assemblers.
-
-`.arch'
- Currently this directive is ignored; it is accepted for
- compatibility with other MSP 430 assemblers.
-
-`.profiler'
- This directive instructs assembler to add new profile entry to the
- object file.
-
-
-
-File: as.info, Node: MSP430 Opcodes, Next: MSP430 Profiling Capability, Prev: MSP430 Directives, Up: MSP430-Dependent
-
-9.26.5 Opcodes
---------------
-
-`as' implements all the standard MSP 430 opcodes. No additional
-pseudo-instructions are needed on this family.
-
- For information on the 430 machine instruction set, see `MSP430
-User's Manual, document slau049d', Texas Instrument, Inc.
-
-
-File: as.info, Node: MSP430 Profiling Capability, Prev: MSP430 Opcodes, Up: MSP430-Dependent
-
-9.26.6 Profiling Capability
----------------------------
-
-It is a performance hit to use gcc's profiling approach for this tiny
-target. Even more - jtag hardware facility does not perform any
-profiling functions. However we've got gdb's built-in simulator where
-we can do anything.
-
- We define new section `.profiler' which holds all profiling
-information. We define new pseudo operation `.profiler' which will
-instruct assembler to add new profile entry to the object file. Profile
-should take place at the present address.
-
- Pseudo operation format:
-
- `.profiler flags,function_to_profile [, cycle_corrector, extra]'
-
- where:
-
- `flags' is a combination of the following characters:
-
- `s'
- function entry
-
- `x'
- function exit
-
- `i'
- function is in init section
-
- `f'
- function is in fini section
-
- `l'
- library call
-
- `c'
- libc standard call
-
- `d'
- stack value demand
-
- `I'
- interrupt service routine
-
- `P'
- prologue start
-
- `p'
- prologue end
-
- `E'
- epilogue start
-
- `e'
- epilogue end
-
- `j'
- long jump / sjlj unwind
-
- `a'
- an arbitrary code fragment
-
- `t'
- extra parameter saved (a constant value like frame size)
-
-`function_to_profile'
- a function address
-
-`cycle_corrector'
- a value which should be added to the cycle counter, zero if
- omitted.
-
-`extra'
- any extra parameter, zero if omitted.
-
-
- For example:
- .global fxx
- .type fxx,@function
- fxx:
- .LFrameOffset_fxx=0x08
- .profiler "scdP", fxx ; function entry.
- ; we also demand stack value to be saved
- push r11
- push r10
- push r9
- push r8
- .profiler "cdpt",fxx,0, .LFrameOffset_fxx ; check stack value at this point
- ; (this is a prologue end)
- ; note, that spare var filled with
- ; the farme size
- mov r15,r8
- ...
- .profiler cdE,fxx ; check stack
- pop r8
- pop r9
- pop r10
- pop r11
- .profiler xcde,fxx,3 ; exit adds 3 to the cycle counter
- ret ; cause 'ret' insn takes 3 cycles
-
-
-File: as.info, Node: PDP-11-Dependent, Next: PJ-Dependent, Prev: SH64-Dependent, Up: Machine Dependencies
-
-9.27 PDP-11 Dependent Features
-==============================
-
-* Menu:
-
-* PDP-11-Options:: Options
-* PDP-11-Pseudos:: Assembler Directives
-* PDP-11-Syntax:: DEC Syntax versus BSD Syntax
-* PDP-11-Mnemonics:: Instruction Naming
-* PDP-11-Synthetic:: Synthetic Instructions
-
-
-File: as.info, Node: PDP-11-Options, Next: PDP-11-Pseudos, Up: PDP-11-Dependent
-
-9.27.1 Options
---------------
-
-The PDP-11 version of `as' has a rich set of machine dependent options.
-
-9.27.1.1 Code Generation Options
-................................
-
-`-mpic | -mno-pic'
- Generate position-independent (or position-dependent) code.
-
- The default is to generate position-independent code.
-
-9.27.1.2 Instruction Set Extension Options
-..........................................
-
-These options enables or disables the use of extensions over the base
-line instruction set as introduced by the first PDP-11 CPU: the KA11.
-Most options come in two variants: a `-m'EXTENSION that enables
-EXTENSION, and a `-mno-'EXTENSION that disables EXTENSION.
-
- The default is to enable all extensions.
-
-`-mall | -mall-extensions'
- Enable all instruction set extensions.
-
-`-mno-extensions'
- Disable all instruction set extensions.
-
-`-mcis | -mno-cis'
- Enable (or disable) the use of the commercial instruction set,
- which consists of these instructions: `ADDNI', `ADDN', `ADDPI',
- `ADDP', `ASHNI', `ASHN', `ASHPI', `ASHP', `CMPCI', `CMPC',
- `CMPNI', `CMPN', `CMPPI', `CMPP', `CVTLNI', `CVTLN', `CVTLPI',
- `CVTLP', `CVTNLI', `CVTNL', `CVTNPI', `CVTNP', `CVTPLI', `CVTPL',
- `CVTPNI', `CVTPN', `DIVPI', `DIVP', `L2DR', `L3DR', `LOCCI',
- `LOCC', `MATCI', `MATC', `MOVCI', `MOVC', `MOVRCI', `MOVRC',
- `MOVTCI', `MOVTC', `MULPI', `MULP', `SCANCI', `SCANC', `SKPCI',
- `SKPC', `SPANCI', `SPANC', `SUBNI', `SUBN', `SUBPI', and `SUBP'.
-
-`-mcsm | -mno-csm'
- Enable (or disable) the use of the `CSM' instruction.
-
-`-meis | -mno-eis'
- Enable (or disable) the use of the extended instruction set, which
- consists of these instructions: `ASHC', `ASH', `DIV', `MARK',
- `MUL', `RTT', `SOB' `SXT', and `XOR'.
-
-`-mfis | -mkev11'
-`-mno-fis | -mno-kev11'
- Enable (or disable) the use of the KEV11 floating-point
- instructions: `FADD', `FDIV', `FMUL', and `FSUB'.
-
-`-mfpp | -mfpu | -mfp-11'
-`-mno-fpp | -mno-fpu | -mno-fp-11'
- Enable (or disable) the use of FP-11 floating-point instructions:
- `ABSF', `ADDF', `CFCC', `CLRF', `CMPF', `DIVF', `LDCFF', `LDCIF',
- `LDEXP', `LDF', `LDFPS', `MODF', `MULF', `NEGF', `SETD', `SETF',
- `SETI', `SETL', `STCFF', `STCFI', `STEXP', `STF', `STFPS', `STST',
- `SUBF', and `TSTF'.
-
-`-mlimited-eis | -mno-limited-eis'
- Enable (or disable) the use of the limited extended instruction
- set: `MARK', `RTT', `SOB', `SXT', and `XOR'.
-
- The -mno-limited-eis options also implies -mno-eis.
-
-`-mmfpt | -mno-mfpt'
- Enable (or disable) the use of the `MFPT' instruction.
-
-`-mmultiproc | -mno-multiproc'
- Enable (or disable) the use of multiprocessor instructions:
- `TSTSET' and `WRTLCK'.
-
-`-mmxps | -mno-mxps'
- Enable (or disable) the use of the `MFPS' and `MTPS' instructions.
-
-`-mspl | -mno-spl'
- Enable (or disable) the use of the `SPL' instruction.
-
- Enable (or disable) the use of the microcode instructions: `LDUB',
- `MED', and `XFC'.
-
-9.27.1.3 CPU Model Options
-..........................
-
-These options enable the instruction set extensions supported by a
-particular CPU, and disables all other extensions.
-
-`-mka11'
- KA11 CPU. Base line instruction set only.
-
-`-mkb11'
- KB11 CPU. Enable extended instruction set and `SPL'.
-
-`-mkd11a'
- KD11-A CPU. Enable limited extended instruction set.
-
-`-mkd11b'
- KD11-B CPU. Base line instruction set only.
-
-`-mkd11d'
- KD11-D CPU. Base line instruction set only.
-
-`-mkd11e'
- KD11-E CPU. Enable extended instruction set, `MFPS', and `MTPS'.
-
-`-mkd11f | -mkd11h | -mkd11q'
- KD11-F, KD11-H, or KD11-Q CPU. Enable limited extended
- instruction set, `MFPS', and `MTPS'.
-
-`-mkd11k'
- KD11-K CPU. Enable extended instruction set, `LDUB', `MED',
- `MFPS', `MFPT', `MTPS', and `XFC'.
-
-`-mkd11z'
- KD11-Z CPU. Enable extended instruction set, `CSM', `MFPS',
- `MFPT', `MTPS', and `SPL'.
-
-`-mf11'
- F11 CPU. Enable extended instruction set, `MFPS', `MFPT', and
- `MTPS'.
-
-`-mj11'
- J11 CPU. Enable extended instruction set, `CSM', `MFPS', `MFPT',
- `MTPS', `SPL', `TSTSET', and `WRTLCK'.
-
-`-mt11'
- T11 CPU. Enable limited extended instruction set, `MFPS', and
- `MTPS'.
-
-9.27.1.4 Machine Model Options
-..............................
-
-These options enable the instruction set extensions supported by a
-particular machine model, and disables all other extensions.
-
-`-m11/03'
- Same as `-mkd11f'.
-
-`-m11/04'
- Same as `-mkd11d'.
-
-`-m11/05 | -m11/10'
- Same as `-mkd11b'.
-
-`-m11/15 | -m11/20'
- Same as `-mka11'.
-
-`-m11/21'
- Same as `-mt11'.
-
-`-m11/23 | -m11/24'
- Same as `-mf11'.
-
-`-m11/34'
- Same as `-mkd11e'.
-
-`-m11/34a'
- Ame as `-mkd11e' `-mfpp'.
-
-`-m11/35 | -m11/40'
- Same as `-mkd11a'.
-
-`-m11/44'
- Same as `-mkd11z'.
-
-`-m11/45 | -m11/50 | -m11/55 | -m11/70'
- Same as `-mkb11'.
-
-`-m11/53 | -m11/73 | -m11/83 | -m11/84 | -m11/93 | -m11/94'
- Same as `-mj11'.
-
-`-m11/60'
- Same as `-mkd11k'.
-
-
-File: as.info, Node: PDP-11-Pseudos, Next: PDP-11-Syntax, Prev: PDP-11-Options, Up: PDP-11-Dependent
-
-9.27.2 Assembler Directives
----------------------------
-
-The PDP-11 version of `as' has a few machine dependent assembler
-directives.
-
-`.bss'
- Switch to the `bss' section.
-
-`.even'
- Align the location counter to an even number.
-
-
-File: as.info, Node: PDP-11-Syntax, Next: PDP-11-Mnemonics, Prev: PDP-11-Pseudos, Up: PDP-11-Dependent
-
-9.27.3 PDP-11 Assembly Language Syntax
---------------------------------------
-
-`as' supports both DEC syntax and BSD syntax. The only difference is
-that in DEC syntax, a `#' character is used to denote an immediate
-constants, while in BSD syntax the character for this purpose is `$'.
-
- general-purpose registers are named `r0' through `r7'. Mnemonic
-alternatives for `r6' and `r7' are `sp' and `pc', respectively.
-
- Floating-point registers are named `ac0' through `ac3', or
-alternatively `fr0' through `fr3'.
-
- Comments are started with a `#' or a `/' character, and extend to
-the end of the line. (FIXME: clash with immediates?)
-
-
-File: as.info, Node: PDP-11-Mnemonics, Next: PDP-11-Synthetic, Prev: PDP-11-Syntax, Up: PDP-11-Dependent
-
-9.27.4 Instruction Naming
--------------------------
-
-Some instructions have alternative names.
-
-`BCC'
- `BHIS'
-
-`BCS'
- `BLO'
-
-`L2DR'
- `L2D'
-
-`L3DR'
- `L3D'
-
-`SYS'
- `TRAP'
-
-
-File: as.info, Node: PDP-11-Synthetic, Prev: PDP-11-Mnemonics, Up: PDP-11-Dependent
-
-9.27.5 Synthetic Instructions
------------------------------
-
-The `JBR' and `J'CC synthetic instructions are not supported yet.
-
-
-File: as.info, Node: PJ-Dependent, Next: PPC-Dependent, Prev: PDP-11-Dependent, Up: Machine Dependencies
-
-9.28 picoJava Dependent Features
-================================
-
-* Menu:
-
-* PJ Options:: Options
-
-
-File: as.info, Node: PJ Options, Up: PJ-Dependent
-
-9.28.1 Options
---------------
-
-`as' has two additional command-line options for the picoJava
-architecture.
-`-ml'
- This option selects little endian data output.
-
-`-mb'
- This option selects big endian data output.
-
-
-File: as.info, Node: PPC-Dependent, Next: RX-Dependent, Prev: PJ-Dependent, Up: Machine Dependencies
-
-9.29 PowerPC Dependent Features
-===============================
-
-* Menu:
-
-* PowerPC-Opts:: Options
-* PowerPC-Pseudo:: PowerPC Assembler Directives
-
-
-File: as.info, Node: PowerPC-Opts, Next: PowerPC-Pseudo, Up: PPC-Dependent
-
-9.29.1 Options
---------------
-
-The PowerPC chip family includes several successive levels, using the
-same core instruction set, but including a few additional instructions
-at each level. There are exceptions to this however. For details on
-what instructions each variant supports, please see the chip's
-architecture reference manual.
-
- The following table lists all available PowerPC options.
-
-`-mpwrx | -mpwr2'
- Generate code for POWER/2 (RIOS2).
-
-`-mpwr'
- Generate code for POWER (RIOS1)
-
-`-m601'
- Generate code for PowerPC 601.
-
-`-mppc, -mppc32, -m603, -m604'
- Generate code for PowerPC 603/604.
-
-`-m403, -m405'
- Generate code for PowerPC 403/405.
-
-`-m440'
- Generate code for PowerPC 440. BookE and some 405 instructions.
-
-`-m476'
- Generate code for PowerPC 476.
-
-`-m7400, -m7410, -m7450, -m7455'
- Generate code for PowerPC 7400/7410/7450/7455.
-
-`-m750cl'
- Generate code for PowerPC 750CL.
-
-`-mppc64, -m620'
- Generate code for PowerPC 620/625/630.
-
-`-me500, -me500x2'
- Generate code for Motorola e500 core complex.
-
-`-mspe'
- Generate code for Motorola SPE instructions.
-
-`-mtitan'
- Generate code for AppliedMicro Titan core complex.
-
-`-mppc64bridge'
- Generate code for PowerPC 64, including bridge insns.
-
-`-mbooke'
- Generate code for 32-bit BookE.
-
-`-ma2'
- Generate code for A2 architecture.
-
-`-me300'
- Generate code for PowerPC e300 family.
-
-`-maltivec'
- Generate code for processors with AltiVec instructions.
-
-`-mvsx'
- Generate code for processors with Vector-Scalar (VSX) instructions.
-
-`-mpower4'
- Generate code for Power4 architecture.
-
-`-mpower5'
- Generate code for Power5 architecture.
-
-`-mpower6'
- Generate code for Power6 architecture.
-
-`-mpower7'
- Generate code for Power7 architecture.
-
-`-mcell'
- Generate code for Cell Broadband Engine architecture.
-
-`-mcom'
- Generate code Power/PowerPC common instructions.
-
-`-many'
- Generate code for any architecture (PWR/PWRX/PPC).
-
-`-mregnames'
- Allow symbolic names for registers.
-
-`-mno-regnames'
- Do not allow symbolic names for registers.
-
-`-mrelocatable'
- Support for GCC's -mrelocatable option.
-
-`-mrelocatable-lib'
- Support for GCC's -mrelocatable-lib option.
-
-`-memb'
- Set PPC_EMB bit in ELF flags.
-
-`-mlittle, -mlittle-endian'
- Generate code for a little endian machine.
-
-`-mbig, -mbig-endian'
- Generate code for a big endian machine.
-
-`-msolaris'
- Generate code for Solaris.
-
-`-mno-solaris'
- Do not generate code for Solaris.
-
-
-File: as.info, Node: PowerPC-Pseudo, Prev: PowerPC-Opts, Up: PPC-Dependent
-
-9.29.2 PowerPC Assembler Directives
------------------------------------
-
-A number of assembler directives are available for PowerPC. The
-following table is far from complete.
-
-`.machine "string"'
- This directive allows you to change the machine for which code is
- generated. `"string"' may be any of the -m cpu selection options
- (without the -m) enclosed in double quotes, `"push"', or `"pop"'.
- `.machine "push"' saves the currently selected cpu, which may be
- restored with `.machine "pop"'.
-
-
-File: as.info, Node: RX-Dependent, Next: S/390-Dependent, Prev: PPC-Dependent, Up: Machine Dependencies
-
-9.30 RX Dependent Features
-==========================
-
-* Menu:
-
-* RX-Opts:: RX Assembler Command Line Options
-* RX-Modifiers:: Symbolic Operand Modifiers
-* RX-Directives:: Assembler Directives
-* RX-Float:: Floating Point
-
-
-File: as.info, Node: RX-Opts, Next: RX-Modifiers, Up: RX-Dependent
-
-9.30.1 RX Options
------------------
-
-The Renesas RX port of `as' has a few target specfic command line
-options:
-
-`-m32bit-doubles'
- This option controls the ABI and indicates to use a 32-bit float
- ABI. It has no effect on the assembled instructions, but it does
- influence the behaviour of the `.double' pseudo-op. This is the
- default.
-
-`-m64bit-doubles'
- This option controls the ABI and indicates to use a 64-bit float
- ABI. It has no effect on the assembled instructions, but it does
- influence the behaviour of the `.double' pseudo-op.
-
-`-mbig-endian'
- This option controls the ABI and indicates to use a big-endian data
- ABI. It has no effect on the assembled instructions, but it does
- influence the behaviour of the `.short', `.hword', `.int',
- `.word', `.long', `.quad' and `.octa' pseudo-ops.
-
-`-mlittle-endian'
- This option controls the ABI and indicates to use a little-endian
- data ABI. It has no effect on the assembled instructions, but it
- does influence the behaviour of the `.short', `.hword', `.int',
- `.word', `.long', `.quad' and `.octa' pseudo-ops. This is the
- default.
-
-`-muse-conventional-section-names'
- This option controls the default names given to the code (.text),
- initialised data (.data) and uninitialised data sections (.bss).
-
-`-muse-renesas-section-names'
- This option controls the default names given to the code (.P),
- initialised data (.D_1) and uninitialised data sections (.B_1).
- This is the default.
-
-`-msmall-data-limit'
- This option tells the assembler that the small data limit feature
- of the RX port of GCC is being used. This results in the assembler
- generating an undefined reference to a symbol called __gp for use
- by the relocations that are needed to support the small data limit
- feature. This option is not enabled by default as it would
- otherwise pollute the symbol table.
-
-
-
-File: as.info, Node: RX-Modifiers, Next: RX-Directives, Prev: RX-Opts, Up: RX-Dependent
-
-9.30.2 Symbolic Operand Modifiers
----------------------------------
-
-The assembler supports several modifiers when using symbol addresses in
-RX instruction operands. The general syntax is the following:
-
- %modifier(symbol)
-
-`%gp'
-
-
-File: as.info, Node: RX-Directives, Next: RX-Float, Prev: RX-Modifiers, Up: RX-Dependent
-
-9.30.3 Assembler Directives
----------------------------
-
-The RX version of `as' has the following specific assembler directives:
-
-`.3byte'
- Inserts a 3-byte value into the output file at the current
- location.
-
-
-
-File: as.info, Node: RX-Float, Prev: RX-Directives, Up: RX-Dependent
-
-9.30.4 Floating Point
----------------------
-
-The floating point formats generated by directives are these.
-
-`.float'
- `Single' precision (32-bit) floating point constants.
-
-`.double'
- If the `-m64bit-doubles' command line option has been specified
- then then `double' directive generates `double' precision (64-bit)
- floating point constants, otherwise it generates `single'
- precision (32-bit) floating point constants. To force the
- generation of 64-bit floating point constants used the `dc.d'
- directive instead.
-
-
-
-File: as.info, Node: S/390-Dependent, Next: SCORE-Dependent, Prev: RX-Dependent, Up: Machine Dependencies
-
-9.31 IBM S/390 Dependent Features
-=================================
-
- The s390 version of `as' supports two architectures modes and seven
-chip levels. The architecture modes are the Enterprise System
-Architecture (ESA) and the newer z/Architecture mode. The chip levels
-are g5, g6, z900, z990, z9-109, z9-ec, z10 and z196.
-
-* Menu:
-
-* s390 Options:: Command-line Options.
-* s390 Characters:: Special Characters.
-* s390 Syntax:: Assembler Instruction syntax.
-* s390 Directives:: Assembler Directives.
-* s390 Floating Point:: Floating Point.
-
-
-File: as.info, Node: s390 Options, Next: s390 Characters, Up: S/390-Dependent
-
-9.31.1 Options
---------------
-
-The following table lists all available s390 specific options:
-
-`-m31 | -m64'
- Select 31- or 64-bit ABI implying a word size of 32- or 64-bit.
-
- These options are only available with the ELF object file format,
- and require that the necessary BFD support has been included (on a
- 31-bit platform you must add -enable-64-bit-bfd on the call to the
- configure script to enable 64-bit usage and use s390x as target
- platform).
-
-`-mesa | -mzarch'
- Select the architecture mode, either the Enterprise System
- Architecture (esa) mode or the z/Architecture mode (zarch).
-
- The 64-bit instructions are only available with the z/Architecture
- mode. The combination of `-m64' and `-mesa' results in a warning
- message.
-
-`-march=CPU'
- This option specifies the target processor. The following
- processor names are recognized: `g5', `g6', `z900', `z990',
- `z9-109', `z9-ec', `z10' and `z196'. Assembling an instruction
- that is not supported on the target processor results in an error
- message. Do not specify `g5' or `g6' with `-mzarch'.
-
-`-mregnames'
- Allow symbolic names for registers.
-
-`-mno-regnames'
- Do not allow symbolic names for registers.
-
-`-mwarn-areg-zero'
- Warn whenever the operand for a base or index register has been
- specified but evaluates to zero. This can indicate the misuse of
- general purpose register 0 as an address register.
-
-
-
-File: as.info, Node: s390 Characters, Next: s390 Syntax, Prev: s390 Options, Up: S/390-Dependent
-
-9.31.2 Special Characters
--------------------------
-
-`#' is the line comment character.
-
-
-File: as.info, Node: s390 Syntax, Next: s390 Directives, Prev: s390 Characters, Up: S/390-Dependent
-
-9.31.3 Instruction syntax
--------------------------
-
-The assembler syntax closely follows the syntax outlined in Enterprise
-Systems Architecture/390 Principles of Operation (SA22-7201) and the
-z/Architecture Principles of Operation (SA22-7832).
-
- Each instruction has two major parts, the instruction mnemonic and
-the instruction operands. The instruction format varies.
-
-* Menu:
-
-* s390 Register:: Register Naming
-* s390 Mnemonics:: Instruction Mnemonics
-* s390 Operands:: Instruction Operands
-* s390 Formats:: Instruction Formats
-* s390 Aliases:: Instruction Aliases
-* s390 Operand Modifier:: Instruction Operand Modifier
-* s390 Instruction Marker:: Instruction Marker
-* s390 Literal Pool Entries:: Literal Pool Entries
-
-
-File: as.info, Node: s390 Register, Next: s390 Mnemonics, Up: s390 Syntax
-
-9.31.3.1 Register naming
-........................
-
-The `as' recognizes a number of predefined symbols for the various
-processor registers. A register specification in one of the instruction
-formats is an unsigned integer between 0 and 15. The specific
-instruction and the position of the register in the instruction format
-denotes the type of the register. The register symbols are prefixed with
-`%':
-
- %rN the 16 general purpose registers, 0 <= N <= 15
- %fN the 16 floating point registers, 0 <= N <= 15
- %aN the 16 access registers, 0 <= N <= 15
- %cN the 16 control registers, 0 <= N <= 15
- %lit an alias for the general purpose register %r13
- %sp an alias for the general purpose register %r15
-
-
-File: as.info, Node: s390 Mnemonics, Next: s390 Operands, Prev: s390 Register, Up: s390 Syntax
-
-9.31.3.2 Instruction Mnemonics
-..............................
-
-All instructions documented in the Principles of Operation are supported
-with the mnemonic and order of operands as described. The instruction
-mnemonic identifies the instruction format (*note s390 Formats::) and
-the specific operation code for the instruction. For example, the `lr'
-mnemonic denotes the instruction format `RR' with the operation code
-`0x18'.
-
- The definition of the various mnemonics follows a scheme, where the
-first character usually hint at the type of the instruction:
-
- a add instruction, for example `al' for add logical 32-bit
- b branch instruction, for example `bc' for branch on condition
- c compare or convert instruction, for example `cr' for compare
- register 32-bit
- d divide instruction, for example `dlr' devide logical register
- 64-bit to 32-bit
- i insert instruction, for example `ic' insert character
- l load instruction, for example `ltr' load and test register
- mv move instruction, for example `mvc' move character
- m multiply instruction, for example `mh' multiply halfword
- n and instruction, for example `ni' and immediate
- o or instruction, for example `oc' or character
- sla, sll shift left single instruction
- sra, srl shift right single instruction
- st store instruction, for example `stm' store multiple
- s subtract instruction, for example `slr' subtract
- logical 32-bit
- t test or translate instruction, of example `tm' test under mask
- x exclusive or instruction, for example `xc' exclusive or
- character
-
- Certain characters at the end of the mnemonic may describe a property
-of the instruction:
-
- c the instruction uses a 8-bit character operand
- f the instruction extends a 32-bit operand to 64 bit
- g the operands are treated as 64-bit values
- h the operand uses a 16-bit halfword operand
- i the instruction uses an immediate operand
- l the instruction uses unsigned, logical operands
- m the instruction uses a mask or operates on multiple values
- r if r is the last character, the instruction operates on registers
- y the instruction uses 20-bit displacements
-
- There are many exceptions to the scheme outlined in the above lists,
-in particular for the priviledged instructions. For non-priviledged
-instruction it works quite well, for example the instruction `clgfr' c:
-compare instruction, l: unsigned operands, g: 64-bit operands, f: 32-
-to 64-bit extension, r: register operands. The instruction compares an
-64-bit value in a register with the zero extended 32-bit value from a
-second register. For a complete list of all mnemonics see appendix B
-in the Principles of Operation.
-
-
-File: as.info, Node: s390 Operands, Next: s390 Formats, Prev: s390 Mnemonics, Up: s390 Syntax
-
-9.31.3.3 Instruction Operands
-.............................
-
-Instruction operands can be grouped into three classes, operands located
-in registers, immediate operands, and operands in storage.
-
- A register operand can be located in general, floating-point, access,
-or control register. The register is identified by a four-bit field.
-The field containing the register operand is called the R field.
-
- Immediate operands are contained within the instruction and can have
-8, 16 or 32 bits. The field containing the immediate operand is called
-the I field. Dependent on the instruction the I field is either signed
-or unsigned.
-
- A storage operand consists of an address and a length. The address
-of a storage operands can be specified in any of these ways:
-
- * The content of a single general R
-
- * The sum of the content of a general register called the base
- register B plus the content of a displacement field D
-
- * The sum of the contents of two general registers called the index
- register X and the base register B plus the content of a
- displacement field
-
- * The sum of the current instruction address and a 32-bit signed
- immediate field multiplied by two.
-
- The length of a storage operand can be:
-
- * Implied by the instruction
-
- * Specified by a bitmask
-
- * Specified by a four-bit or eight-bit length field L
-
- * Specified by the content of a general register
-
- The notation for storage operand addresses formed from multiple
-fields is as follows:
-
-`Dn(Bn)'
- the address for operand number n is formed from the content of
- general register Bn called the base register and the displacement
- field Dn.
-
-`Dn(Xn,Bn)'
- the address for operand number n is formed from the content of
- general register Xn called the index register, general register Bn
- called the base register and the displacement field Dn.
-
-`Dn(Ln,Bn)'
- the address for operand number n is formed from the content of
- general regiser Bn called the base register and the displacement
- field Dn. The length of the operand n is specified by the field
- Ln.
-
- The base registers Bn and the index registers Xn of a storage
-operand can be skipped. If Bn and Xn are skipped, a zero will be stored
-to the operand field. The notation changes as follows:
-
- full notation short notation
- ------------------------------------------
- Dn(0,Bn) Dn(Bn)
- Dn(0,0) Dn
- Dn(0) Dn
- Dn(Ln,0) Dn(Ln)
-
-
-File: as.info, Node: s390 Formats, Next: s390 Aliases, Prev: s390 Operands, Up: s390 Syntax
-
-9.31.3.4 Instruction Formats
-............................
-
-The Principles of Operation manuals lists 26 instruction formats where
-some of the formats have multiple variants. For the `.insn' pseudo
-directive the assembler recognizes some of the formats. Typically, the
-most general variant of the instruction format is used by the `.insn'
-directive.
-
- The following table lists the abbreviations used in the table of
-instruction formats:
-
- OpCode / OpCd Part of the op code.
- Bx Base register number for operand x.
- Dx Displacement for operand x.
- DLx Displacement lower 12 bits for operand x.
- DHx Displacement higher 8-bits for operand x.
- Rx Register number for operand x.
- Xx Index register number for operand x.
- Ix Signed immediate for operand x.
- Ux Unsigned immediate for operand x.
-
- An instruction is two, four, or six bytes in length and must be
-aligned on a 2 byte boundary. The first two bits of the instruction
-specify the length of the instruction, 00 indicates a two byte
-instruction, 01 and 10 indicates a four byte instruction, and 11
-indicates a six byte instruction.
-
- The following table lists the s390 instruction formats that are
-available with the `.insn' pseudo directive:
-
-`E format'
- +-------------+
- | OpCode |
- +-------------+
- 0 15
-
-`RI format: <insn> R1,I2'
- +--------+----+----+------------------+
- | OpCode | R1 |OpCd| I2 |
- +--------+----+----+------------------+
- 0 8 12 16 31
-
-`RIE format: <insn> R1,R3,I2'
- +--------+----+----+------------------+--------+--------+
- | OpCode | R1 | R3 | I2 |////////| OpCode |
- +--------+----+----+------------------+--------+--------+
- 0 8 12 16 32 40 47
-
-`RIL format: <insn> R1,I2'
- +--------+----+----+------------------------------------+
- | OpCode | R1 |OpCd| I2 |
- +--------+----+----+------------------------------------+
- 0 8 12 16 47
-
-`RILU format: <insn> R1,U2'
- +--------+----+----+------------------------------------+
- | OpCode | R1 |OpCd| U2 |
- +--------+----+----+------------------------------------+
- 0 8 12 16 47
-
-`RIS format: <insn> R1,I2,M3,D4(B4)'
- +--------+----+----+----+-------------+--------+--------+
- | OpCode | R1 | M3 | B4 | D4 | I2 | Opcode |
- +--------+----+----+----+-------------+--------+--------+
- 0 8 12 16 20 32 36 47
-
-`RR format: <insn> R1,R2'
- +--------+----+----+
- | OpCode | R1 | R2 |
- +--------+----+----+
- 0 8 12 15
-
-`RRE format: <insn> R1,R2'
- +------------------+--------+----+----+
- | OpCode |////////| R1 | R2 |
- +------------------+--------+----+----+
- 0 16 24 28 31
-
-`RRF format: <insn> R1,R2,R3,M4'
- +------------------+----+----+----+----+
- | OpCode | R3 | M4 | R1 | R2 |
- +------------------+----+----+----+----+
- 0 16 20 24 28 31
-
-`RRS format: <insn> R1,R2,M3,D4(B4)'
- +--------+----+----+----+-------------+----+----+--------+
- | OpCode | R1 | R3 | B4 | D4 | M3 |////| OpCode |
- +--------+----+----+----+-------------+----+----+--------+
- 0 8 12 16 20 32 36 40 47
-
-`RS format: <insn> R1,R3,D2(B2)'
- +--------+----+----+----+-------------+
- | OpCode | R1 | R3 | B2 | D2 |
- +--------+----+----+----+-------------+
- 0 8 12 16 20 31
-
-`RSE format: <insn> R1,R3,D2(B2)'
- +--------+----+----+----+-------------+--------+--------+
- | OpCode | R1 | R3 | B2 | D2 |////////| OpCode |
- +--------+----+----+----+-------------+--------+--------+
- 0 8 12 16 20 32 40 47
-
-`RSI format: <insn> R1,R3,I2'
- +--------+----+----+------------------------------------+
- | OpCode | R1 | R3 | I2 |
- +--------+----+----+------------------------------------+
- 0 8 12 16 47
-
-`RSY format: <insn> R1,R3,D2(B2)'
- +--------+----+----+----+-------------+--------+--------+
- | OpCode | R1 | R3 | B2 | DL2 | DH2 | OpCode |
- +--------+----+----+----+-------------+--------+--------+
- 0 8 12 16 20 32 40 47
-
-`RX format: <insn> R1,D2(X2,B2)'
- +--------+----+----+----+-------------+
- | OpCode | R1 | X2 | B2 | D2 |
- +--------+----+----+----+-------------+
- 0 8 12 16 20 31
-
-`RXE format: <insn> R1,D2(X2,B2)'
- +--------+----+----+----+-------------+--------+--------+
- | OpCode | R1 | X2 | B2 | D2 |////////| OpCode |
- +--------+----+----+----+-------------+--------+--------+
- 0 8 12 16 20 32 40 47
-
-`RXF format: <insn> R1,R3,D2(X2,B2)'
- +--------+----+----+----+-------------+----+---+--------+
- | OpCode | R3 | X2 | B2 | D2 | R1 |///| OpCode |
- +--------+----+----+----+-------------+----+---+--------+
- 0 8 12 16 20 32 36 40 47
-
-`RXY format: <insn> R1,D2(X2,B2)'
- +--------+----+----+----+-------------+--------+--------+
- | OpCode | R1 | X2 | B2 | DL2 | DH2 | OpCode |
- +--------+----+----+----+-------------+--------+--------+
- 0 8 12 16 20 32 36 40 47
-
-`S format: <insn> D2(B2)'
- +------------------+----+-------------+
- | OpCode | B2 | D2 |
- +------------------+----+-------------+
- 0 16 20 31
-
-`SI format: <insn> D1(B1),I2'
- +--------+---------+----+-------------+
- | OpCode | I2 | B1 | D1 |
- +--------+---------+----+-------------+
- 0 8 16 20 31
-
-`SIY format: <insn> D1(B1),U2'
- +--------+---------+----+-------------+--------+--------+
- | OpCode | I2 | B1 | DL1 | DH1 | OpCode |
- +--------+---------+----+-------------+--------+--------+
- 0 8 16 20 32 36 40 47
-
-`SIL format: <insn> D1(B1),I2'
- +------------------+----+-------------+-----------------+
- | OpCode | B1 | D1 | I2 |
- +------------------+----+-------------+-----------------+
- 0 16 20 32 47
-
-`SS format: <insn> D1(R1,B1),D2(B3),R3'
- +--------+----+----+----+-------------+----+------------+
- | OpCode | R1 | R3 | B1 | D1 | B2 | D2 |
- +--------+----+----+----+-------------+----+------------+
- 0 8 12 16 20 32 36 47
-
-`SSE format: <insn> D1(B1),D2(B2)'
- +------------------+----+-------------+----+------------+
- | OpCode | B1 | D1 | B2 | D2 |
- +------------------+----+-------------+----+------------+
- 0 8 12 16 20 32 36 47
-
-`SSF format: <insn> D1(B1),D2(B2),R3'
- +--------+----+----+----+-------------+----+------------+
- | OpCode | R3 |OpCd| B1 | D1 | B2 | D2 |
- +--------+----+----+----+-------------+----+------------+
- 0 8 12 16 20 32 36 47
-
-
- For the complete list of all instruction format variants see the
-Principles of Operation manuals.
-
-
-File: as.info, Node: s390 Aliases, Next: s390 Operand Modifier, Prev: s390 Formats, Up: s390 Syntax
-
-9.31.3.5 Instruction Aliases
-............................
-
-A specific bit pattern can have multiple mnemonics, for example the bit
-pattern `0xa7000000' has the mnemonics `tmh' and `tmlh'. In addition,
-there are a number of mnemonics recognized by `as' that are not present
-in the Principles of Operation. These are the short forms of the
-branch instructions, where the condition code mask operand is encoded
-in the mnemonic. This is relevant for the branch instructions, the
-compare and branch instructions, and the compare and trap instructions.
-
- For the branch instructions there are 20 condition code strings that
-can be used as part of the mnemonic in place of a mask operand in the
-instruction format:
-
- instruction short form
- ------------------------------------------
- bcr M1,R2 b<m>r R2
- bc M1,D2(X2,B2) b<m> D2(X2,B2)
- brc M1,I2 j<m> I2
- brcl M1,I2 jg<m> I2
-
- In the mnemonic for a branch instruction the condition code string
-<m> can be any of the following:
-
- o jump on overflow / if ones
- h jump on A high
- p jump on plus
- nle jump on not low or equal
- l jump on A low
- m jump on minus
- nhe jump on not high or equal
- lh jump on low or high
- ne jump on A not equal B
- nz jump on not zero / if not zeros
- e jump on A equal B
- z jump on zero / if zeroes
- nlh jump on not low or high
- he jump on high or equal
- nl jump on A not low
- nm jump on not minus / if not mixed
- le jump on low or equal
- nh jump on A not high
- np jump on not plus
- no jump on not overflow / if not ones
-
- For the compare and branch, and compare and trap instructions there
-are 12 condition code strings that can be used as part of the mnemonic
-in place of a mask operand in the instruction format:
-
- instruction short form
- --------------------------------------------------------
- crb R1,R2,M3,D4(B4) crb<m> R1,R2,D4(B4)
- cgrb R1,R2,M3,D4(B4) cgrb<m> R1,R2,D4(B4)
- crj R1,R2,M3,I4 crj<m> R1,R2,I4
- cgrj R1,R2,M3,I4 cgrj<m> R1,R2,I4
- cib R1,I2,M3,D4(B4) cib<m> R1,I2,D4(B4)
- cgib R1,I2,M3,D4(B4) cgib<m> R1,I2,D4(B4)
- cij R1,I2,M3,I4 cij<m> R1,I2,I4
- cgij R1,I2,M3,I4 cgij<m> R1,I2,I4
- crt R1,R2,M3 crt<m> R1,R2
- cgrt R1,R2,M3 cgrt<m> R1,R2
- cit R1,I2,M3 cit<m> R1,I2
- cgit R1,I2,M3 cgit<m> R1,I2
- clrb R1,R2,M3,D4(B4) clrb<m> R1,R2,D4(B4)
- clgrb R1,R2,M3,D4(B4) clgrb<m> R1,R2,D4(B4)
- clrj R1,R2,M3,I4 clrj<m> R1,R2,I4
- clgrj R1,R2,M3,I4 clgrj<m> R1,R2,I4
- clib R1,I2,M3,D4(B4) clib<m> R1,I2,D4(B4)
- clgib R1,I2,M3,D4(B4) clgib<m> R1,I2,D4(B4)
- clij R1,I2,M3,I4 clij<m> R1,I2,I4
- clgij R1,I2,M3,I4 clgij<m> R1,I2,I4
- clrt R1,R2,M3 clrt<m> R1,R2
- clgrt R1,R2,M3 clgrt<m> R1,R2
- clfit R1,I2,M3 clfit<m> R1,I2
- clgit R1,I2,M3 clgit<m> R1,I2
-
- In the mnemonic for a compare and branch and compare and trap
-instruction the condition code string <m> can be any of the following:
-
- h jump on A high
- nle jump on not low or equal
- l jump on A low
- nhe jump on not high or equal
- ne jump on A not equal B
- lh jump on low or high
- e jump on A equal B
- nlh jump on not low or high
- nl jump on A not low
- he jump on high or equal
- nh jump on A not high
- le jump on low or equal
-
-
-File: as.info, Node: s390 Operand Modifier, Next: s390 Instruction Marker, Prev: s390 Aliases, Up: s390 Syntax
-
-9.31.3.6 Instruction Operand Modifier
-.....................................
-
-If a symbol modifier is attached to a symbol in an expression for an
-instruction operand field, the symbol term is replaced with a reference
-to an object in the global offset table (GOT) or the procedure linkage
-table (PLT). The following expressions are allowed: `symbol@modifier +
-constant', `symbol@modifier + label + constant', and `symbol@modifier -
-label + constant'. The term `symbol' is the symbol that will be
-entered into the GOT or PLT, `label' is a local label, and `constant'
-is an arbitrary expression that the assembler can evaluate to a
-constant value.
-
- The term `(symbol + constant1)@modifier +/- label + constant2' is
-also accepted but a warning message is printed and the term is
-converted to `symbol@modifier +/- label + constant1 + constant2'.
-
-`@got'
-`@got12'
- The @got modifier can be used for displacement fields, 16-bit
- immediate fields and 32-bit pc-relative immediate fields. The
- @got12 modifier is synonym to @got. The symbol is added to the
- GOT. For displacement fields and 16-bit immediate fields the
- symbol term is replaced with the offset from the start of the GOT
- to the GOT slot for the symbol. For a 32-bit pc-relative field
- the pc-relative offset to the GOT slot from the current
- instruction address is used.
-
-`@gotent'
- The @gotent modifier can be used for 32-bit pc-relative immediate
- fields. The symbol is added to the GOT and the symbol term is
- replaced with the pc-relative offset from the current instruction
- to the GOT slot for the symbol.
-
-`@gotoff'
- The @gotoff modifier can be used for 16-bit immediate fields. The
- symbol term is replaced with the offset from the start of the GOT
- to the address of the symbol.
-
-`@gotplt'
- The @gotplt modifier can be used for displacement fields, 16-bit
- immediate fields, and 32-bit pc-relative immediate fields. A
- procedure linkage table entry is generated for the symbol and a
- jump slot for the symbol is added to the GOT. For displacement
- fields and 16-bit immediate fields the symbol term is replaced
- with the offset from the start of the GOT to the jump slot for the
- symbol. For a 32-bit pc-relative field the pc-relative offset to
- the jump slot from the current instruction address is used.
-
-`@plt'
- The @plt modifier can be used for 16-bit and 32-bit pc-relative
- immediate fields. A procedure linkage table entry is generated for
- the symbol. The symbol term is replaced with the relative offset
- from the current instruction to the PLT entry for the symbol.
-
-`@pltoff'
- The @pltoff modifier can be used for 16-bit immediate fields. The
- symbol term is replaced with the offset from the start of the PLT
- to the address of the symbol.
-
-`@gotntpoff'
- The @gotntpoff modifier can be used for displacement fields. The
- symbol is added to the static TLS block and the negated offset to
- the symbol in the static TLS block is added to the GOT. The symbol
- term is replaced with the offset to the GOT slot from the start of
- the GOT.
-
-`@indntpoff'
- The @indntpoff modifier can be used for 32-bit pc-relative
- immediate fields. The symbol is added to the static TLS block and
- the negated offset to the symbol in the static TLS block is added
- to the GOT. The symbol term is replaced with the pc-relative
- offset to the GOT slot from the current instruction address.
-
- For more information about the thread local storage modifiers
-`gotntpoff' and `indntpoff' see the ELF extension documentation `ELF
-Handling For Thread-Local Storage'.
-
-
-File: as.info, Node: s390 Instruction Marker, Next: s390 Literal Pool Entries, Prev: s390 Operand Modifier, Up: s390 Syntax
-
-9.31.3.7 Instruction Marker
-...........................
-
-The thread local storage instruction markers are used by the linker to
-perform code optimization.
-
-`:tls_load'
- The :tls_load marker is used to flag the load instruction in the
- initial exec TLS model that retrieves the offset from the thread
- pointer to a thread local storage variable from the GOT.
-
-`:tls_gdcall'
- The :tls_gdcall marker is used to flag the branch-and-save
- instruction to the __tls_get_offset function in the global dynamic
- TLS model.
-
-`:tls_ldcall'
- The :tls_ldcall marker is used to flag the branch-and-save
- instruction to the __tls_get_offset function in the local dynamic
- TLS model.
-
- For more information about the thread local storage instruction
-marker and the linker optimizations see the ELF extension documentation
-`ELF Handling For Thread-Local Storage'.
-
-
-File: as.info, Node: s390 Literal Pool Entries, Prev: s390 Instruction Marker, Up: s390 Syntax
-
-9.31.3.8 Literal Pool Entries
-.............................
-
-A literal pool is a collection of values. To access the values a pointer
-to the literal pool is loaded to a register, the literal pool register.
-Usually, register %r13 is used as the literal pool register (*note s390
-Register::). Literal pool entries are created by adding the suffix
-:lit1, :lit2, :lit4, or :lit8 to the end of an expression for an
-instruction operand. The expression is added to the literal pool and the
-operand is replaced with the offset to the literal in the literal pool.
-
-`:lit1'
- The literal pool entry is created as an 8-bit value. An operand
- modifier must not be used for the original expression.
-
-`:lit2'
- The literal pool entry is created as a 16 bit value. The operand
- modifier @got may be used in the original expression. The term
- `x@got:lit2' will put the got offset for the global symbol x to
- the literal pool as 16 bit value.
-
-`:lit4'
- The literal pool entry is created as a 32-bit value. The operand
- modifier @got and @plt may be used in the original expression. The
- term `x@got:lit4' will put the got offset for the global symbol x
- to the literal pool as a 32-bit value. The term `x@plt:lit4' will
- put the plt offset for the global symbol x to the literal pool as
- a 32-bit value.
-
-`:lit8'
- The literal pool entry is created as a 64-bit value. The operand
- modifier @got and @plt may be used in the original expression. The
- term `x@got:lit8' will put the got offset for the global symbol x
- to the literal pool as a 64-bit value. The term `x@plt:lit8' will
- put the plt offset for the global symbol x to the literal pool as
- a 64-bit value.
-
- The assembler directive `.ltorg' is used to emit all literal pool
-entries to the current position.
-
-
-File: as.info, Node: s390 Directives, Next: s390 Floating Point, Prev: s390 Syntax, Up: S/390-Dependent
-
-9.31.4 Assembler Directives
----------------------------
-
-`as' for s390 supports all of the standard ELF assembler directives as
-outlined in the main part of this document. Some directives have been
-extended and there are some additional directives, which are only
-available for the s390 `as'.
-
-`.insn'
- This directive permits the numeric representation of an
- instructions and makes the assembler insert the operands according
- to one of the instructions formats for `.insn' (*note s390
- Formats::). For example, the instruction `l %r1,24(%r15)' could
- be written as `.insn rx,0x58000000,%r1,24(%r15)'.
-
-`.short'
-`.long'
-`.quad'
- This directive places one or more 16-bit (.short), 32-bit (.long),
- or 64-bit (.quad) values into the current section. If an ELF or
- TLS modifier is used only the following expressions are allowed:
- `symbol@modifier + constant', `symbol@modifier + label +
- constant', and `symbol@modifier - label + constant'. The
- following modifiers are available:
- `@got'
- `@got12'
- The @got modifier can be used for .short, .long and .quad.
- The @got12 modifier is synonym to @got. The symbol is added
- to the GOT. The symbol term is replaced with offset from the
- start of the GOT to the GOT slot for the symbol.
-
- `@gotoff'
- The @gotoff modifier can be used for .short, .long and .quad.
- The symbol term is replaced with the offset from the start of
- the GOT to the address of the symbol.
-
- `@gotplt'
- The @gotplt modifier can be used for .long and .quad. A
- procedure linkage table entry is generated for the symbol and
- a jump slot for the symbol is added to the GOT. The symbol
- term is replaced with the offset from the start of the GOT to
- the jump slot for the symbol.
-
- `@plt'
- The @plt modifier can be used for .long and .quad. A
- procedure linkage table entry us generated for the symbol.
- The symbol term is replaced with the address of the PLT entry
- for the symbol.
-
- `@pltoff'
- The @pltoff modifier can be used for .short, .long and .quad.
- The symbol term is replaced with the offset from the start of
- the PLT to the address of the symbol.
-
- `@tlsgd'
- `@tlsldm'
- The @tlsgd and @tlsldm modifier can be used for .long and
- .quad. A tls_index structure for the symbol is added to the
- GOT. The symbol term is replaced with the offset from the
- start of the GOT to the tls_index structure.
-
- `@gotntpoff'
- `@indntpoff'
- The @gotntpoff and @indntpoff modifier can be used for .long
- and .quad. The symbol is added to the static TLS block and
- the negated offset to the symbol in the static TLS block is
- added to the GOT. For @gotntpoff the symbol term is replaced
- with the offset from the start of the GOT to the GOT slot,
- for @indntpoff the symbol term is replaced with the address
- of the GOT slot.
-
- `@dtpoff'
- The @dtpoff modifier can be used for .long and .quad. The
- symbol term is replaced with the offset of the symbol
- relative to the start of the TLS block it is contained in.
-
- `@ntpoff'
- The @ntpoff modifier can be used for .long and .quad. The
- symbol term is replaced with the offset of the symbol
- relative to the TCB pointer.
-
- For more information about the thread local storage modifiers see
- the ELF extension documentation `ELF Handling For Thread-Local
- Storage'.
-
-`.ltorg'
- This directive causes the current contents of the literal pool to
- be dumped to the current location (*note s390 Literal Pool
- Entries::).
-
-
-File: as.info, Node: s390 Floating Point, Prev: s390 Directives, Up: S/390-Dependent
-
-9.31.5 Floating Point
----------------------
-
-The assembler recognizes both the IEEE floating-point instruction and
-the hexadecimal floating-point instructions. The floating-point
-constructors `.float', `.single', and `.double' always emit the IEEE
-format. To assemble hexadecimal floating-point constants the `.long'
-and `.quad' directives must be used.
-
-
-File: as.info, Node: SCORE-Dependent, Next: Sparc-Dependent, Prev: S/390-Dependent, Up: Machine Dependencies
-
-9.32 SCORE Dependent Features
-=============================
-
-* Menu:
-
-* SCORE-Opts:: Assembler options
-* SCORE-Pseudo:: SCORE Assembler Directives
-
-
-File: as.info, Node: SCORE-Opts, Next: SCORE-Pseudo, Up: SCORE-Dependent
-
-9.32.1 Options
---------------
-
-The following table lists all available SCORE options.
-
-`-G NUM'
- This option sets the largest size of an object that can be
- referenced implicitly with the `gp' register. The default value is
- 8.
-
-`-EB'
- Assemble code for a big-endian cpu
-
-`-EL'
- Assemble code for a little-endian cpu
-
-`-FIXDD'
- Assemble code for fix data dependency
-
-`-NWARN'
- Assemble code for no warning message for fix data dependency
-
-`-SCORE5'
- Assemble code for target is SCORE5
-
-`-SCORE5U'
- Assemble code for target is SCORE5U
-
-`-SCORE7'
- Assemble code for target is SCORE7, this is default setting
-
-`-SCORE3'
- Assemble code for target is SCORE3
-
-`-march=score7'
- Assemble code for target is SCORE7, this is default setting
-
-`-march=score3'
- Assemble code for target is SCORE3
-
-`-USE_R1'
- Assemble code for no warning message when using temp register r1
-
-`-KPIC'
- Generate code for PIC. This option tells the assembler to generate
- score position-independent macro expansions. It also tells the
- assembler to mark the output file as PIC.
-
-`-O0'
- Assembler will not perform any optimizations
-
-`-V'
- Sunplus release version
-
-
-
-File: as.info, Node: SCORE-Pseudo, Prev: SCORE-Opts, Up: SCORE-Dependent
-
-9.32.2 SCORE Assembler Directives
----------------------------------
-
-A number of assembler directives are available for SCORE. The
-following table is far from complete.
-
-`.set nwarn'
- Let the assembler not to generate warnings if the source machine
- language instructions happen data dependency.
-
-`.set fixdd'
- Let the assembler to insert bubbles (32 bit nop instruction / 16
- bit nop! Instruction) if the source machine language instructions
- happen data dependency.
-
-`.set nofixdd'
- Let the assembler to generate warnings if the source machine
- language instructions happen data dependency. (Default)
-
-`.set r1'
- Let the assembler not to generate warnings if the source program
- uses r1. allow user to use r1
-
-`set nor1'
- Let the assembler to generate warnings if the source program uses
- r1. (Default)
-
-`.sdata'
- Tell the assembler to add subsequent data into the sdata section
-
-`.rdata'
- Tell the assembler to add subsequent data into the rdata section
-
-`.frame "frame-register", "offset", "return-pc-register"'
- Describe a stack frame. "frame-register" is the frame register,
- "offset" is the distance from the frame register to the virtual
- frame pointer, "return-pc-register" is the return program register.
- You must use ".ent" before ".frame" and only one ".frame" can be
- used per ".ent".
-
-`.mask "bitmask", "frameoffset"'
- Indicate which of the integer registers are saved in the current
- function's stack frame, this is for the debugger to explain the
- frame chain.
-
-`.ent "proc-name"'
- Set the beginning of the procedure "proc_name". Use this directive
- when you want to generate information for the debugger.
-
-`.end proc-name'
- Set the end of a procedure. Use this directive to generate
- information for the debugger.
-
-`.bss'
- Switch the destination of following statements into the bss
- section, which is used for data that is uninitialized anywhere.
-
-
-
-File: as.info, Node: SH-Dependent, Next: SH64-Dependent, Prev: MSP430-Dependent, Up: Machine Dependencies
-
-9.33 Renesas / SuperH SH Dependent Features
-===========================================
-
-* Menu:
-
-* SH Options:: Options
-* SH Syntax:: Syntax
-* SH Floating Point:: Floating Point
-* SH Directives:: SH Machine Directives
-* SH Opcodes:: Opcodes
-
-
-File: as.info, Node: SH Options, Next: SH Syntax, Up: SH-Dependent
-
-9.33.1 Options
---------------
-
-`as' has following command-line options for the Renesas (formerly
-Hitachi) / SuperH SH family.
-
-`--little'
- Generate little endian code.
-
-`--big'
- Generate big endian code.
-
-`--relax'
- Alter jump instructions for long displacements.
-
-`--small'
- Align sections to 4 byte boundaries, not 16.
-
-`--dsp'
- Enable sh-dsp insns, and disable sh3e / sh4 insns.
-
-`--renesas'
- Disable optimization with section symbol for compatibility with
- Renesas assembler.
-
-`--allow-reg-prefix'
- Allow '$' as a register name prefix.
-
-`--fdpic'
- Generate an FDPIC object file.
-
-`--isa=sh4 | sh4a'
- Specify the sh4 or sh4a instruction set.
-
-`--isa=dsp'
- Enable sh-dsp insns, and disable sh3e / sh4 insns.
-
-`--isa=fp'
- Enable sh2e, sh3e, sh4, and sh4a insn sets.
-
-`--isa=all'
- Enable sh1, sh2, sh2e, sh3, sh3e, sh4, sh4a, and sh-dsp insn sets.
-
-`-h-tick-hex'
- Support H'00 style hex constants in addition to 0x00 style.
-
-
-
-File: as.info, Node: SH Syntax, Next: SH Floating Point, Prev: SH Options, Up: SH-Dependent
-
-9.33.2 Syntax
--------------
-
-* Menu:
-
-* SH-Chars:: Special Characters
-* SH-Regs:: Register Names
-* SH-Addressing:: Addressing Modes
-
-
-File: as.info, Node: SH-Chars, Next: SH-Regs, Up: SH Syntax
-
-9.33.2.1 Special Characters
-...........................
-
-`!' is the line comment character.
-
- You can use `;' instead of a newline to separate statements.
-
- Since `$' has no special meaning, you may use it in symbol names.
-
-
-File: as.info, Node: SH-Regs, Next: SH-Addressing, Prev: SH-Chars, Up: SH Syntax
-
-9.33.2.2 Register Names
-.......................
-
-You can use the predefined symbols `r0', `r1', `r2', `r3', `r4', `r5',
-`r6', `r7', `r8', `r9', `r10', `r11', `r12', `r13', `r14', and `r15' to
-refer to the SH registers.
-
- The SH also has these control registers:
-
-`pr'
- procedure register (holds return address)
-
-`pc'
- program counter
-
-`mach'
-`macl'
- high and low multiply accumulator registers
-
-`sr'
- status register
-
-`gbr'
- global base register
-
-`vbr'
- vector base register (for interrupt vectors)
-
-
-File: as.info, Node: SH-Addressing, Prev: SH-Regs, Up: SH Syntax
-
-9.33.2.3 Addressing Modes
-.........................
-
-`as' understands the following addressing modes for the SH. `RN' in
-the following refers to any of the numbered registers, but _not_ the
-control registers.
-
-`RN'
- Register direct
-
-`@RN'
- Register indirect
-
-`@-RN'
- Register indirect with pre-decrement
-
-`@RN+'
- Register indirect with post-increment
-
-`@(DISP, RN)'
- Register indirect with displacement
-
-`@(R0, RN)'
- Register indexed
-
-`@(DISP, GBR)'
- `GBR' offset
-
-`@(R0, GBR)'
- GBR indexed
-
-`ADDR'
-`@(DISP, PC)'
- PC relative address (for branch or for addressing memory). The
- `as' implementation allows you to use the simpler form ADDR
- anywhere a PC relative address is called for; the alternate form
- is supported for compatibility with other assemblers.
-
-`#IMM'
- Immediate data
-
-
-File: as.info, Node: SH Floating Point, Next: SH Directives, Prev: SH Syntax, Up: SH-Dependent
-
-9.33.3 Floating Point
----------------------
-
-SH2E, SH3E and SH4 groups have on-chip floating-point unit (FPU). Other
-SH groups can use `.float' directive to generate IEEE floating-point
-numbers.
-
- SH2E and SH3E support single-precision floating point calculations as
-well as entirely PCAPI compatible emulation of double-precision
-floating point calculations. SH2E and SH3E instructions are a subset of
-the floating point calculations conforming to the IEEE754 standard.
-
- In addition to single-precision and double-precision floating-point
-operation capability, the on-chip FPU of SH4 has a 128-bit graphic
-engine that enables 32-bit floating-point data to be processed 128 bits
-at a time. It also supports 4 * 4 array operations and inner product
-operations. Also, a superscalar architecture is employed that enables
-simultaneous execution of two instructions (including FPU
-instructions), providing performance of up to twice that of
-conventional architectures at the same frequency.
-
-
-File: as.info, Node: SH Directives, Next: SH Opcodes, Prev: SH Floating Point, Up: SH-Dependent
-
-9.33.4 SH Machine Directives
-----------------------------
-
-`uaword'
-`ualong'
- `as' will issue a warning when a misaligned `.word' or `.long'
- directive is used. You may use `.uaword' or `.ualong' to indicate
- that the value is intentionally misaligned.
-
-
-File: as.info, Node: SH Opcodes, Prev: SH Directives, Up: SH-Dependent
-
-9.33.5 Opcodes
---------------
-
-For detailed information on the SH machine instruction set, see
-`SH-Microcomputer User's Manual' (Renesas) or `SH-4 32-bit CPU Core
-Architecture' (SuperH) and `SuperH (SH) 64-Bit RISC Series' (SuperH).
-
- `as' implements all the standard SH opcodes. No additional
-pseudo-instructions are needed on this family. Note, however, that
-because `as' supports a simpler form of PC-relative addressing, you may
-simply write (for example)
-
- mov.l bar,r0
-
-where other assemblers might require an explicit displacement to `bar'
-from the program counter:
-
- mov.l @(DISP, PC)
-
- Here is a summary of SH opcodes:
-
- Legend:
- Rn a numbered register
- Rm another numbered register
- #imm immediate data
- disp displacement
- disp8 8-bit displacement
- disp12 12-bit displacement
-
- add #imm,Rn lds.l @Rn+,PR
- add Rm,Rn mac.w @Rm+,@Rn+
- addc Rm,Rn mov #imm,Rn
- addv Rm,Rn mov Rm,Rn
- and #imm,R0 mov.b Rm,@(R0,Rn)
- and Rm,Rn mov.b Rm,@-Rn
- and.b #imm,@(R0,GBR) mov.b Rm,@Rn
- bf disp8 mov.b @(disp,Rm),R0
- bra disp12 mov.b @(disp,GBR),R0
- bsr disp12 mov.b @(R0,Rm),Rn
- bt disp8 mov.b @Rm+,Rn
- clrmac mov.b @Rm,Rn
- clrt mov.b R0,@(disp,Rm)
- cmp/eq #imm,R0 mov.b R0,@(disp,GBR)
- cmp/eq Rm,Rn mov.l Rm,@(disp,Rn)
- cmp/ge Rm,Rn mov.l Rm,@(R0,Rn)
- cmp/gt Rm,Rn mov.l Rm,@-Rn
- cmp/hi Rm,Rn mov.l Rm,@Rn
- cmp/hs Rm,Rn mov.l @(disp,Rn),Rm
- cmp/pl Rn mov.l @(disp,GBR),R0
- cmp/pz Rn mov.l @(disp,PC),Rn
- cmp/str Rm,Rn mov.l @(R0,Rm),Rn
- div0s Rm,Rn mov.l @Rm+,Rn
- div0u mov.l @Rm,Rn
- div1 Rm,Rn mov.l R0,@(disp,GBR)
- exts.b Rm,Rn mov.w Rm,@(R0,Rn)
- exts.w Rm,Rn mov.w Rm,@-Rn
- extu.b Rm,Rn mov.w Rm,@Rn
- extu.w Rm,Rn mov.w @(disp,Rm),R0
- jmp @Rn mov.w @(disp,GBR),R0
- jsr @Rn mov.w @(disp,PC),Rn
- ldc Rn,GBR mov.w @(R0,Rm),Rn
- ldc Rn,SR mov.w @Rm+,Rn
- ldc Rn,VBR mov.w @Rm,Rn
- ldc.l @Rn+,GBR mov.w R0,@(disp,Rm)
- ldc.l @Rn+,SR mov.w R0,@(disp,GBR)
- ldc.l @Rn+,VBR mova @(disp,PC),R0
- lds Rn,MACH movt Rn
- lds Rn,MACL muls Rm,Rn
- lds Rn,PR mulu Rm,Rn
- lds.l @Rn+,MACH neg Rm,Rn
- lds.l @Rn+,MACL negc Rm,Rn
-
- nop stc VBR,Rn
- not Rm,Rn stc.l GBR,@-Rn
- or #imm,R0 stc.l SR,@-Rn
- or Rm,Rn stc.l VBR,@-Rn
- or.b #imm,@(R0,GBR) sts MACH,Rn
- rotcl Rn sts MACL,Rn
- rotcr Rn sts PR,Rn
- rotl Rn sts.l MACH,@-Rn
- rotr Rn sts.l MACL,@-Rn
- rte sts.l PR,@-Rn
- rts sub Rm,Rn
- sett subc Rm,Rn
- shal Rn subv Rm,Rn
- shar Rn swap.b Rm,Rn
- shll Rn swap.w Rm,Rn
- shll16 Rn tas.b @Rn
- shll2 Rn trapa #imm
- shll8 Rn tst #imm,R0
- shlr Rn tst Rm,Rn
- shlr16 Rn tst.b #imm,@(R0,GBR)
- shlr2 Rn xor #imm,R0
- shlr8 Rn xor Rm,Rn
- sleep xor.b #imm,@(R0,GBR)
- stc GBR,Rn xtrct Rm,Rn
- stc SR,Rn
-
-
-File: as.info, Node: SH64-Dependent, Next: PDP-11-Dependent, Prev: SH-Dependent, Up: Machine Dependencies
-
-9.34 SuperH SH64 Dependent Features
-===================================
-
-* Menu:
-
-* SH64 Options:: Options
-* SH64 Syntax:: Syntax
-* SH64 Directives:: SH64 Machine Directives
-* SH64 Opcodes:: Opcodes
-
-
-File: as.info, Node: SH64 Options, Next: SH64 Syntax, Up: SH64-Dependent
-
-9.34.1 Options
---------------
-
-`-isa=sh4 | sh4a'
- Specify the sh4 or sh4a instruction set.
-
-`-isa=dsp'
- Enable sh-dsp insns, and disable sh3e / sh4 insns.
-
-`-isa=fp'
- Enable sh2e, sh3e, sh4, and sh4a insn sets.
-
-`-isa=all'
- Enable sh1, sh2, sh2e, sh3, sh3e, sh4, sh4a, and sh-dsp insn sets.
-
-`-isa=shmedia | -isa=shcompact'
- Specify the default instruction set. `SHmedia' specifies the
- 32-bit opcodes, and `SHcompact' specifies the 16-bit opcodes
- compatible with previous SH families. The default depends on the
- ABI selected; the default for the 64-bit ABI is SHmedia, and the
- default for the 32-bit ABI is SHcompact. If neither the ABI nor
- the ISA is specified, the default is 32-bit SHcompact.
-
- Note that the `.mode' pseudo-op is not permitted if the ISA is not
- specified on the command line.
-
-`-abi=32 | -abi=64'
- Specify the default ABI. If the ISA is specified and the ABI is
- not, the default ABI depends on the ISA, with SHmedia defaulting
- to 64-bit and SHcompact defaulting to 32-bit.
-
- Note that the `.abi' pseudo-op is not permitted if the ABI is not
- specified on the command line. When the ABI is specified on the
- command line, any `.abi' pseudo-ops in the source must match it.
-
-`-shcompact-const-crange'
- Emit code-range descriptors for constants in SHcompact code
- sections.
-
-`-no-mix'
- Disallow SHmedia code in the same section as constants and
- SHcompact code.
-
-`-no-expand'
- Do not expand MOVI, PT, PTA or PTB instructions.
-
-`-expand-pt32'
- With -abi=64, expand PT, PTA and PTB instructions to 32 bits only.
-
-`-h-tick-hex'
- Support H'00 style hex constants in addition to 0x00 style.
-
-
-
-File: as.info, Node: SH64 Syntax, Next: SH64 Directives, Prev: SH64 Options, Up: SH64-Dependent
-
-9.34.2 Syntax
--------------
-
-* Menu:
-
-* SH64-Chars:: Special Characters
-* SH64-Regs:: Register Names
-* SH64-Addressing:: Addressing Modes
-
-
-File: as.info, Node: SH64-Chars, Next: SH64-Regs, Up: SH64 Syntax
-
-9.34.2.1 Special Characters
-...........................
-
-`!' is the line comment character.
-
- You can use `;' instead of a newline to separate statements.
-
- Since `$' has no special meaning, you may use it in symbol names.
-
-
-File: as.info, Node: SH64-Regs, Next: SH64-Addressing, Prev: SH64-Chars, Up: SH64 Syntax
-
-9.34.2.2 Register Names
-.......................
-
-You can use the predefined symbols `r0' through `r63' to refer to the
-SH64 general registers, `cr0' through `cr63' for control registers,
-`tr0' through `tr7' for target address registers, `fr0' through `fr63'
-for single-precision floating point registers, `dr0' through `dr62'
-(even numbered registers only) for double-precision floating point
-registers, `fv0' through `fv60' (multiples of four only) for
-single-precision floating point vectors, `fp0' through `fp62' (even
-numbered registers only) for single-precision floating point pairs,
-`mtrx0' through `mtrx48' (multiples of 16 only) for 4x4 matrices of
-single-precision floating point registers, `pc' for the program
-counter, and `fpscr' for the floating point status and control register.
-
- You can also refer to the control registers by the mnemonics `sr',
-`ssr', `pssr', `intevt', `expevt', `pexpevt', `tra', `spc', `pspc',
-`resvec', `vbr', `tea', `dcr', `kcr0', `kcr1', `ctc', and `usr'.
-
-
-File: as.info, Node: SH64-Addressing, Prev: SH64-Regs, Up: SH64 Syntax
-
-9.34.2.3 Addressing Modes
-.........................
-
-SH64 operands consist of either a register or immediate value. The
-immediate value can be a constant or label reference (or portion of a
-label reference), as in this example:
-
- movi 4,r2
- pt function, tr4
- movi (function >> 16) & 65535,r0
- shori function & 65535, r0
- ld.l r0,4,r0
-
- Instruction label references can reference labels in either SHmedia
-or SHcompact. To differentiate between the two, labels in SHmedia
-sections will always have the least significant bit set (i.e. they will
-be odd), which SHcompact labels will have the least significant bit
-reset (i.e. they will be even). If you need to reference the actual
-address of a label, you can use the `datalabel' modifier, as in this
-example:
-
- .long function
- .long datalabel function
-
- In that example, the first longword may or may not have the least
-significant bit set depending on whether the label is an SHmedia label
-or an SHcompact label. The second longword will be the actual address
-of the label, regardless of what type of label it is.
-
-
-File: as.info, Node: SH64 Directives, Next: SH64 Opcodes, Prev: SH64 Syntax, Up: SH64-Dependent
-
-9.34.3 SH64 Machine Directives
-------------------------------
-
-In addition to the SH directives, the SH64 provides the following
-directives:
-
-`.mode [shmedia|shcompact]'
-`.isa [shmedia|shcompact]'
- Specify the ISA for the following instructions (the two directives
- are equivalent). Note that programs such as `objdump' rely on
- symbolic labels to determine when such mode switches occur (by
- checking the least significant bit of the label's address), so
- such mode/isa changes should always be followed by a label (in
- practice, this is true anyway). Note that you cannot use these
- directives if you didn't specify an ISA on the command line.
-
-`.abi [32|64]'
- Specify the ABI for the following instructions. Note that you
- cannot use this directive unless you specified an ABI on the
- command line, and the ABIs specified must match.
-
-`.uaquad'
- Like .uaword and .ualong, this allows you to specify an
- intentionally unaligned quadword (64 bit word).
-
-
-
-File: as.info, Node: SH64 Opcodes, Prev: SH64 Directives, Up: SH64-Dependent
-
-9.34.4 Opcodes
---------------
-
-For detailed information on the SH64 machine instruction set, see
-`SuperH 64 bit RISC Series Architecture Manual' (SuperH, Inc.).
-
- `as' implements all the standard SH64 opcodes. In addition, the
-following pseudo-opcodes may be expanded into one or more alternate
-opcodes:
-
-`movi'
- If the value doesn't fit into a standard `movi' opcode, `as' will
- replace the `movi' with a sequence of `movi' and `shori' opcodes.
-
-`pt'
- This expands to a sequence of `movi' and `shori' opcode, followed
- by a `ptrel' opcode, or to a `pta' or `ptb' opcode, depending on
- the label referenced.
-
-
-
-File: as.info, Node: Sparc-Dependent, Next: TIC54X-Dependent, Prev: SCORE-Dependent, Up: Machine Dependencies
-
-9.35 SPARC Dependent Features
-=============================
-
-* Menu:
-
-* Sparc-Opts:: Options
-* Sparc-Aligned-Data:: Option to enforce aligned data
-* Sparc-Syntax:: Syntax
-* Sparc-Float:: Floating Point
-* Sparc-Directives:: Sparc Machine Directives
-
-
-File: as.info, Node: Sparc-Opts, Next: Sparc-Aligned-Data, Up: Sparc-Dependent
-
-9.35.1 Options
---------------
-
-The SPARC chip family includes several successive versions, using the
-same core instruction set, but including a few additional instructions
-at each version. There are exceptions to this however. For details on
-what instructions each variant supports, please see the chip's
-architecture reference manual.
-
- By default, `as' assumes the core instruction set (SPARC v6), but
-"bumps" the architecture level as needed: it switches to successively
-higher architectures as it encounters instructions that only exist in
-the higher levels.
-
- If not configured for SPARC v9 (`sparc64-*-*') GAS will not bump
-past sparclite by default, an option must be passed to enable the v9
-instructions.
-
- GAS treats sparclite as being compatible with v8, unless an
-architecture is explicitly requested. SPARC v9 is always incompatible
-with sparclite.
-
-`-Av6 | -Av7 | -Av8 | -Asparclet | -Asparclite'
-`-Av8plus | -Av8plusa | -Av9 | -Av9a'
- Use one of the `-A' options to select one of the SPARC
- architectures explicitly. If you select an architecture
- explicitly, `as' reports a fatal error if it encounters an
- instruction or feature requiring an incompatible or higher level.
-
- `-Av8plus' and `-Av8plusa' select a 32 bit environment.
-
- `-Av9' and `-Av9a' select a 64 bit environment and are not
- available unless GAS is explicitly configured with 64 bit
- environment support.
-
- `-Av8plusa' and `-Av9a' enable the SPARC V9 instruction set with
- UltraSPARC extensions.
-
-`-xarch=v8plus | -xarch=v8plusa'
- For compatibility with the SunOS v9 assembler. These options are
- equivalent to -Av8plus and -Av8plusa, respectively.
-
-`-bump'
- Warn whenever it is necessary to switch to another level. If an
- architecture level is explicitly requested, GAS will not issue
- warnings until that level is reached, and will then bump the level
- as required (except between incompatible levels).
-
-`-32 | -64'
- Select the word size, either 32 bits or 64 bits. These options
- are only available with the ELF object file format, and require
- that the necessary BFD support has been included.
-
-
-File: as.info, Node: Sparc-Aligned-Data, Next: Sparc-Syntax, Prev: Sparc-Opts, Up: Sparc-Dependent
-
-9.35.2 Enforcing aligned data
------------------------------
-
-SPARC GAS normally permits data to be misaligned. For example, it
-permits the `.long' pseudo-op to be used on a byte boundary. However,
-the native SunOS assemblers issue an error when they see misaligned
-data.
-
- You can use the `--enforce-aligned-data' option to make SPARC GAS
-also issue an error about misaligned data, just as the SunOS assemblers
-do.
-
- The `--enforce-aligned-data' option is not the default because gcc
-issues misaligned data pseudo-ops when it initializes certain packed
-data structures (structures defined using the `packed' attribute). You
-may have to assemble with GAS in order to initialize packed data
-structures in your own code.
-
-
-File: as.info, Node: Sparc-Syntax, Next: Sparc-Float, Prev: Sparc-Aligned-Data, Up: Sparc-Dependent
-
-9.35.3 Sparc Syntax
--------------------
-
-The assembler syntax closely follows The Sparc Architecture Manual,
-versions 8 and 9, as well as most extensions defined by Sun for their
-UltraSPARC and Niagara line of processors.
-
-* Menu:
-
-* Sparc-Chars:: Special Characters
-* Sparc-Regs:: Register Names
-* Sparc-Constants:: Constant Names
-* Sparc-Relocs:: Relocations
-* Sparc-Size-Translations:: Size Translations
-
-
-File: as.info, Node: Sparc-Chars, Next: Sparc-Regs, Up: Sparc-Syntax
-
-9.35.3.1 Special Characters
-...........................
-
-`#' is the line comment character.
-
- `;' can be used instead of a newline to separate statements.
-
-
-File: as.info, Node: Sparc-Regs, Next: Sparc-Constants, Prev: Sparc-Chars, Up: Sparc-Syntax
-
-9.35.3.2 Register Names
-.......................
-
-The Sparc integer register file is broken down into global, outgoing,
-local, and incoming.
-
- * The 8 global registers are referred to as `%gN'.
-
- * The 8 outgoing registers are referred to as `%oN'.
-
- * The 8 local registers are referred to as `%lN'.
-
- * The 8 incoming registers are referred to as `%iN'.
-
- * The frame pointer register `%i6' can be referenced using the alias
- `%fp'.
-
- * The stack pointer register `%o6' can be referenced using the alias
- `%sp'.
-
- Floating point registers are simply referred to as `%fN'. When
-assembling for pre-V9, only 32 floating point registers are available.
-For V9 and later there are 64, but there are restrictions when
-referencing the upper 32 registers. They can only be accessed as
-double or quad, and thus only even or quad numbered accesses are
-allowed. For example, `%f34' is a legal floating point register, but
-`%f35' is not.
-
- Certain V9 instructions allow access to ancillary state registers.
-Most simply they can be referred to as `%asrN' where N can be from 16
-to 31. However, there are some aliases defined to reference ASR
-registers defined for various UltraSPARC processors:
-
- * The tick compare register is referred to as `%tick_cmpr'.
-
- * The system tick register is referred to as `%stick'. An alias,
- `%sys_tick', exists but is deprecated and should not be used by
- new software.
-
- * The system tick compare register is referred to as `%stick_cmpr'.
- An alias, `%sys_tick_cmpr', exists but is deprecated and should
- not be used by new software.
-
- * The software interrupt register is referred to as `%softint'.
-
- * The set software interrupt register is referred to as
- `%set_softint'. The mnemonic `%softint_set' is provided as an
- alias.
-
- * The clear software interrupt register is referred to as
- `%clear_softint'. The mnemonic `%softint_clear' is provided as an
- alias.
-
- * The performance instrumentation counters register is referred to as
- `%pic'.
-
- * The performance control register is referred to as `%pcr'.
-
- * The graphics status register is referred to as `%gsr'.
-
- * The V9 dispatch control register is referred to as `%dcr'.
-
- Various V9 branch and conditional move instructions allow
-specification of which set of integer condition codes to test. These
-are referred to as `%xcc' and `%icc'.
-
- In V9, there are 4 sets of floating point condition codes which are
-referred to as `%fccN'.
-
- Several special privileged and non-privileged registers exist:
-
- * The V9 address space identifier register is referred to as `%asi'.
-
- * The V9 restorable windows register is referred to as `%canrestore'.
-
- * The V9 savable windows register is referred to as `%cansave'.
-
- * The V9 clean windows register is referred to as `%cleanwin'.
-
- * The V9 current window pointer register is referred to as `%cwp'.
-
- * The floating-point queue register is referred to as `%fq'.
-
- * The V8 co-processor queue register is referred to as `%cq'.
-
- * The floating point status register is referred to as `%fsr'.
-
- * The other windows register is referred to as `%otherwin'.
-
- * The V9 program counter register is referred to as `%pc'.
-
- * The V9 next program counter register is referred to as `%npc'.
-
- * The V9 processor interrupt level register is referred to as `%pil'.
-
- * The V9 processor state register is referred to as `%pstate'.
-
- * The trap base address register is referred to as `%tba'.
-
- * The V9 tick register is referred to as `%tick'.
-
- * The V9 trap level is referred to as `%tl'.
-
- * The V9 trap program counter is referred to as `%tpc'.
-
- * The V9 trap next program counter is referred to as `%tnpc'.
-
- * The V9 trap state is referred to as `%tstate'.
-
- * The V9 trap type is referred to as `%tt'.
-
- * The V9 condition codes is referred to as `%ccr'.
-
- * The V9 floating-point registers state is referred to as `%fprs'.
-
- * The V9 version register is referred to as `%ver'.
-
- * The V9 window state register is referred to as `%wstate'.
-
- * The Y register is referred to as `%y'.
-
- * The V8 window invalid mask register is referred to as `%wim'.
-
- * The V8 processor state register is referred to as `%psr'.
-
- * The V9 global register level register is referred to as `%gl'.
-
- Several special register names exist for hypervisor mode code:
-
- * The hyperprivileged processor state register is referred to as
- `%hpstate'.
-
- * The hyperprivileged trap state register is referred to as
- `%htstate'.
-
- * The hyperprivileged interrupt pending register is referred to as
- `%hintp'.
-
- * The hyperprivileged trap base address register is referred to as
- `%htba'.
-
- * The hyperprivileged implementation version register is referred to
- as `%hver'.
-
- * The hyperprivileged system tick compare register is referred to as
- `%hstick_cmpr'. Note that there is no `%hstick' register, the
- normal `%stick' is used.
-
-
-File: as.info, Node: Sparc-Constants, Next: Sparc-Relocs, Prev: Sparc-Regs, Up: Sparc-Syntax
-
-9.35.3.3 Constants
-..................
-
-Several Sparc instructions take an immediate operand field for which
-mnemonic names exist. Two such examples are `membar' and `prefetch'.
-Another example are the set of V9 memory access instruction that allow
-specification of an address space identifier.
-
- The `membar' instruction specifies a memory barrier that is the
-defined by the operand which is a bitmask. The supported mask
-mnemonics are:
-
- * `#Sync' requests that all operations (including nonmemory
- reference operations) appearing prior to the `membar' must have
- been performed and the effects of any exceptions become visible
- before any instructions after the `membar' may be initiated. This
- corresponds to `membar' cmask field bit 2.
-
- * `#MemIssue' requests that all memory reference operations
- appearing prior to the `membar' must have been performed before
- any memory operation after the `membar' may be initiated. This
- corresponds to `membar' cmask field bit 1.
-
- * `#Lookaside' requests that a store appearing prior to the `membar'
- must complete before any load following the `membar' referencing
- the same address can be initiated. This corresponds to `membar'
- cmask field bit 0.
-
- * `#StoreStore' defines that the effects of all stores appearing
- prior to the `membar' instruction must be visible to all
- processors before the effect of any stores following the `membar'.
- Equivalent to the deprecated `stbar' instruction. This
- corresponds to `membar' mmask field bit 3.
-
- * `#LoadStore' defines all loads appearing prior to the `membar'
- instruction must have been performed before the effect of any
- stores following the `membar' is visible to any other processor.
- This corresponds to `membar' mmask field bit 2.
-
- * `#StoreLoad' defines that the effects of all stores appearing
- prior to the `membar' instruction must be visible to all
- processors before loads following the `membar' may be performed.
- This corresponds to `membar' mmask field bit 1.
-
- * `#LoadLoad' defines that all loads appearing prior to the `membar'
- instruction must have been performed before any loads following
- the `membar' may be performed. This corresponds to `membar' mmask
- field bit 0.
-
-
- These values can be ored together, for example:
-
- membar #Sync
- membar #StoreLoad | #LoadLoad
- membar #StoreLoad | #StoreStore
-
- The `prefetch' and `prefetcha' instructions take a prefetch function
-code. The following prefetch function code constant mnemonics are
-available:
-
- * `#n_reads' requests a prefetch for several reads, and corresponds
- to a prefetch function code of 0.
-
- `#one_read' requests a prefetch for one read, and corresponds to a
- prefetch function code of 1.
-
- `#n_writes' requests a prefetch for several writes (and possibly
- reads), and corresponds to a prefetch function code of 2.
-
- `#one_write' requests a prefetch for one write, and corresponds to
- a prefetch function code of 3.
-
- `#page' requests a prefetch page, and corresponds to a prefetch
- function code of 4.
-
- `#invalidate' requests a prefetch invalidate, and corresponds to a
- prefetch function code of 16.
-
- `#unified' requests a prefetch to the nearest unified cache, and
- corresponds to a prefetch function code of 17.
-
- `#n_reads_strong' requests a strong prefetch for several reads,
- and corresponds to a prefetch function code of 20.
-
- `#one_read_strong' requests a strong prefetch for one read, and
- corresponds to a prefetch function code of 21.
-
- `#n_writes_strong' requests a strong prefetch for several writes,
- and corresponds to a prefetch function code of 22.
-
- `#one_write_strong' requests a strong prefetch for one write, and
- corresponds to a prefetch function code of 23.
-
- Onle one prefetch code may be specified. Here are some examples:
-
- prefetch [%l0 + %l2], #one_read
- prefetch [%g2 + 8], #n_writes
- prefetcha [%g1] 0x8, #unified
- prefetcha [%o0 + 0x10] %asi, #n_reads
-
- The actual behavior of a given prefetch function code is processor
- specific. If a processor does not implement a given prefetch
- function code, it will treat the prefetch instruction as a nop.
-
- For instructions that accept an immediate address space identifier,
- `as' provides many mnemonics corresponding to V9 defined as well
- as UltraSPARC and Niagara extended values. For example, `#ASI_P'
- and `#ASI_BLK_INIT_QUAD_LDD_AIUS'. See the V9 and processor
- specific manuals for details.
-
-
-
-File: as.info, Node: Sparc-Relocs, Next: Sparc-Size-Translations, Prev: Sparc-Constants, Up: Sparc-Syntax
-
-9.35.3.4 Relocations
-....................
-
-ELF relocations are available as defined in the 32-bit and 64-bit Sparc
-ELF specifications.
-
- `R_SPARC_HI22' is obtained using `%hi' and `R_SPARC_LO10' is
-obtained using `%lo'. Likewise `R_SPARC_HIX22' is obtained from `%hix'
-and `R_SPARC_LOX10' is obtained using `%lox'. For example:
-
- sethi %hi(symbol), %g1
- or %g1, %lo(symbol), %g1
-
- sethi %hix(symbol), %g1
- xor %g1, %lox(symbol), %g1
-
- These "high" mnemonics extract bits 31:10 of their operand, and the
-"low" mnemonics extract bits 9:0 of their operand.
-
- V9 code model relocations can be requested as follows:
-
- * `R_SPARC_HH22' is requested using `%hh'. It can also be generated
- using `%uhi'.
-
- * `R_SPARC_HM10' is requested using `%hm'. It can also be generated
- using `%ulo'.
-
- * `R_SPARC_LM22' is requested using `%lm'.
-
- * `R_SPARC_H44' is requested using `%h44'.
-
- * `R_SPARC_M44' is requested using `%m44'.
-
- * `R_SPARC_L44' is requested using `%l44'.
-
- The PC relative relocation `R_SPARC_PC22' can be obtained by
-enclosing an operand inside of `%pc22'. Likewise, the `R_SPARC_PC10'
-relocation can be obtained using `%pc10'. These are mostly used when
-assembling PIC code. For example, the standard PIC sequence on Sparc
-to get the base of the global offset table, PC relative, into a
-register, can be performed as:
-
- sethi %pc22(_GLOBAL_OFFSET_TABLE_-4), %l7
- add %l7, %pc10(_GLOBAL_OFFSET_TABLE_+4), %l7
-
- Several relocations exist to allow the link editor to potentially
-optimize GOT data references. The `R_SPARC_GOTDATA_OP_HIX22'
-relocation can obtained by enclosing an operand inside of
-`%gdop_hix22'. The `R_SPARC_GOTDATA_OP_LOX10' relocation can obtained
-by enclosing an operand inside of `%gdop_lox10'. Likewise,
-`R_SPARC_GOTDATA_OP' can be obtained by enclosing an operand inside of
-`%gdop'. For example, assuming the GOT base is in register `%l7':
-
- sethi %gdop_hix22(symbol), %l1
- xor %l1, %gdop_lox10(symbol), %l1
- ld [%l7 + %l1], %l2, %gdop(symbol)
-
- There are many relocations that can be requested for access to
-thread local storage variables. All of the Sparc TLS mnemonics are
-supported:
-
- * `R_SPARC_TLS_GD_HI22' is requested using `%tgd_hi22'.
-
- * `R_SPARC_TLS_GD_LO10' is requested using `%tgd_lo10'.
-
- * `R_SPARC_TLS_GD_ADD' is requested using `%tgd_add'.
-
- * `R_SPARC_TLS_GD_CALL' is requested using `%tgd_call'.
-
- * `R_SPARC_TLS_LDM_HI22' is requested using `%tldm_hi22'.
-
- * `R_SPARC_TLS_LDM_LO10' is requested using `%tldm_lo10'.
-
- * `R_SPARC_TLS_LDM_ADD' is requested using `%tldm_add'.
-
- * `R_SPARC_TLS_LDM_CALL' is requested using `%tldm_call'.
-
- * `R_SPARC_TLS_LDO_HIX22' is requested using `%tldo_hix22'.
-
- * `R_SPARC_TLS_LDO_LOX10' is requested using `%tldo_lox10'.
-
- * `R_SPARC_TLS_LDO_ADD' is requested using `%tldo_add'.
-
- * `R_SPARC_TLS_IE_HI22' is requested using `%tie_hi22'.
-
- * `R_SPARC_TLS_IE_LO10' is requested using `%tie_lo10'.
-
- * `R_SPARC_TLS_IE_LD' is requested using `%tie_ld'.
-
- * `R_SPARC_TLS_IE_LDX' is requested using `%tie_ldx'.
-
- * `R_SPARC_TLS_IE_ADD' is requested using `%tie_add'.
-
- * `R_SPARC_TLS_LE_HIX22' is requested using `%tle_hix22'.
-
- * `R_SPARC_TLS_LE_LOX10' is requested using `%tle_lox10'.
-
- Here are some example TLS model sequences.
-
- First, General Dynamic:
-
- sethi %tgd_hi22(symbol), %l1
- add %l1, %tgd_lo10(symbol), %l1
- add %l7, %l1, %o0, %tgd_add(symbol)
- call __tls_get_addr, %tgd_call(symbol)
- nop
-
- Local Dynamic:
-
- sethi %tldm_hi22(symbol), %l1
- add %l1, %tldm_lo10(symbol), %l1
- add %l7, %l1, %o0, %tldm_add(symbol)
- call __tls_get_addr, %tldm_call(symbol)
- nop
-
- sethi %tldo_hix22(symbol), %l1
- xor %l1, %tldo_lox10(symbol), %l1
- add %o0, %l1, %l1, %tldo_add(symbol)
-
- Initial Exec:
-
- sethi %tie_hi22(symbol), %l1
- add %l1, %tie_lo10(symbol), %l1
- ld [%l7 + %l1], %o0, %tie_ld(symbol)
- add %g7, %o0, %o0, %tie_add(symbol)
-
- sethi %tie_hi22(symbol), %l1
- add %l1, %tie_lo10(symbol), %l1
- ldx [%l7 + %l1], %o0, %tie_ldx(symbol)
- add %g7, %o0, %o0, %tie_add(symbol)
-
- And finally, Local Exec:
-
- sethi %tle_hix22(symbol), %l1
- add %l1, %tle_lox10(symbol), %l1
- add %g7, %l1, %l1
-
- When assembling for 64-bit, and a secondary constant addend is
-specified in an address expression that would normally generate an
-`R_SPARC_LO10' relocation, the assembler will emit an `R_SPARC_OLO10'
-instead.
-
-
-File: as.info, Node: Sparc-Size-Translations, Prev: Sparc-Relocs, Up: Sparc-Syntax
-
-9.35.3.5 Size Translations
-..........................
-
-Often it is desirable to write code in an operand size agnostic manner.
-`as' provides support for this via operand size opcode translations.
-Translations are supported for loads, stores, shifts, compare-and-swap
-atomics, and the `clr' synthetic instruction.
-
- If generating 32-bit code, `as' will generate the 32-bit opcode.
-Whereas if 64-bit code is being generated, the 64-bit opcode will be
-emitted. For example `ldn' will be transformed into `ld' for 32-bit
-code and `ldx' for 64-bit code.
-
- Here is an example meant to demonstrate all the supported opcode
-translations:
-
- ldn [%o0], %o1
- ldna [%o0] %asi, %o2
- stn %o1, [%o0]
- stna %o2, [%o0] %asi
- slln %o3, 3, %o3
- srln %o4, 8, %o4
- sran %o5, 12, %o5
- casn [%o0], %o1, %o2
- casna [%o0] %asi, %o1, %o2
- clrn %g1
-
- In 32-bit mode `as' will emit:
-
- ld [%o0], %o1
- lda [%o0] %asi, %o2
- st %o1, [%o0]
- sta %o2, [%o0] %asi
- sll %o3, 3, %o3
- srl %o4, 8, %o4
- sra %o5, 12, %o5
- cas [%o0], %o1, %o2
- casa [%o0] %asi, %o1, %o2
- clr %g1
-
- And in 64-bit mode `as' will emit:
-
- ldx [%o0], %o1
- ldxa [%o0] %asi, %o2
- stx %o1, [%o0]
- stxa %o2, [%o0] %asi
- sllx %o3, 3, %o3
- srlx %o4, 8, %o4
- srax %o5, 12, %o5
- casx [%o0], %o1, %o2
- casxa [%o0] %asi, %o1, %o2
- clrx %g1
-
- Finally, the `.nword' translating directive is supported as well.
-It is documented in the section on Sparc machine directives.
-
-
-File: as.info, Node: Sparc-Float, Next: Sparc-Directives, Prev: Sparc-Syntax, Up: Sparc-Dependent
-
-9.35.4 Floating Point
----------------------
-
-The Sparc uses IEEE floating-point numbers.
-
-
-File: as.info, Node: Sparc-Directives, Prev: Sparc-Float, Up: Sparc-Dependent
-
-9.35.5 Sparc Machine Directives
--------------------------------
-
-The Sparc version of `as' supports the following additional machine
-directives:
-
-`.align'
- This must be followed by the desired alignment in bytes.
-
-`.common'
- This must be followed by a symbol name, a positive number, and
- `"bss"'. This behaves somewhat like `.comm', but the syntax is
- different.
-
-`.half'
- This is functionally identical to `.short'.
-
-`.nword'
- On the Sparc, the `.nword' directive produces native word sized
- value, ie. if assembling with -32 it is equivalent to `.word', if
- assembling with -64 it is equivalent to `.xword'.
-
-`.proc'
- This directive is ignored. Any text following it on the same line
- is also ignored.
-
-`.register'
- This directive declares use of a global application or system
- register. It must be followed by a register name %g2, %g3, %g6 or
- %g7, comma and the symbol name for that register. If symbol name
- is `#scratch', it is a scratch register, if it is `#ignore', it
- just suppresses any errors about using undeclared global register,
- but does not emit any information about it into the object file.
- This can be useful e.g. if you save the register before use and
- restore it after.
-
-`.reserve'
- This must be followed by a symbol name, a positive number, and
- `"bss"'. This behaves somewhat like `.lcomm', but the syntax is
- different.
-
-`.seg'
- This must be followed by `"text"', `"data"', or `"data1"'. It
- behaves like `.text', `.data', or `.data 1'.
-
-`.skip'
- This is functionally identical to the `.space' directive.
-
-`.word'
- On the Sparc, the `.word' directive produces 32 bit values,
- instead of the 16 bit values it produces on many other machines.
-
-`.xword'
- On the Sparc V9 processor, the `.xword' directive produces 64 bit
- values.
-
-
-File: as.info, Node: TIC54X-Dependent, Next: TIC6X-Dependent, Prev: Sparc-Dependent, Up: Machine Dependencies
-
-9.36 TIC54X Dependent Features
-==============================
-
-* Menu:
-
-* TIC54X-Opts:: Command-line Options
-* TIC54X-Block:: Blocking
-* TIC54X-Env:: Environment Settings
-* TIC54X-Constants:: Constants Syntax
-* TIC54X-Subsyms:: String Substitution
-* TIC54X-Locals:: Local Label Syntax
-* TIC54X-Builtins:: Builtin Assembler Math Functions
-* TIC54X-Ext:: Extended Addressing Support
-* TIC54X-Directives:: Directives
-* TIC54X-Macros:: Macro Features
-* TIC54X-MMRegs:: Memory-mapped Registers
-
-
-File: as.info, Node: TIC54X-Opts, Next: TIC54X-Block, Up: TIC54X-Dependent
-
-9.36.1 Options
---------------
-
-The TMS320C54X version of `as' has a few machine-dependent options.
-
- You can use the `-mfar-mode' option to enable extended addressing
-mode. All addresses will be assumed to be > 16 bits, and the
-appropriate relocation types will be used. This option is equivalent
-to using the `.far_mode' directive in the assembly code. If you do not
-use the `-mfar-mode' option, all references will be assumed to be 16
-bits. This option may be abbreviated to `-mf'.
-
- You can use the `-mcpu' option to specify a particular CPU. This
-option is equivalent to using the `.version' directive in the assembly
-code. For recognized CPU codes, see *Note `.version':
-TIC54X-Directives. The default CPU version is `542'.
-
- You can use the `-merrors-to-file' option to redirect error output
-to a file (this provided for those deficient environments which don't
-provide adequate output redirection). This option may be abbreviated to
-`-me'.
-
-
-File: as.info, Node: TIC54X-Block, Next: TIC54X-Env, Prev: TIC54X-Opts, Up: TIC54X-Dependent
-
-9.36.2 Blocking
----------------
-
-A blocked section or memory block is guaranteed not to cross the
-blocking boundary (usually a page, or 128 words) if it is smaller than
-the blocking size, or to start on a page boundary if it is larger than
-the blocking size.
-
-
-File: as.info, Node: TIC54X-Env, Next: TIC54X-Constants, Prev: TIC54X-Block, Up: TIC54X-Dependent
-
-9.36.3 Environment Settings
----------------------------
-
-`C54XDSP_DIR' and `A_DIR' are semicolon-separated paths which are added
-to the list of directories normally searched for source and include
-files. `C54XDSP_DIR' will override `A_DIR'.
-
-
-File: as.info, Node: TIC54X-Constants, Next: TIC54X-Subsyms, Prev: TIC54X-Env, Up: TIC54X-Dependent
-
-9.36.4 Constants Syntax
------------------------
-
-The TIC54X version of `as' allows the following additional constant
-formats, using a suffix to indicate the radix:
-
- Binary `000000B, 011000b'
- Octal `10Q, 224q'
- Hexadecimal `45h, 0FH'
-
-
-File: as.info, Node: TIC54X-Subsyms, Next: TIC54X-Locals, Prev: TIC54X-Constants, Up: TIC54X-Dependent
-
-9.36.5 String Substitution
---------------------------
-
-A subset of allowable symbols (which we'll call subsyms) may be assigned
-arbitrary string values. This is roughly equivalent to C preprocessor
-#define macros. When `as' encounters one of these symbols, the symbol
-is replaced in the input stream by its string value. Subsym names
-*must* begin with a letter.
-
- Subsyms may be defined using the `.asg' and `.eval' directives
-(*Note `.asg': TIC54X-Directives, *Note `.eval': TIC54X-Directives.
-
- Expansion is recursive until a previously encountered symbol is
-seen, at which point substitution stops.
-
- In this example, x is replaced with SYM2; SYM2 is replaced with
-SYM1, and SYM1 is replaced with x. At this point, x has already been
-encountered and the substitution stops.
-
- .asg "x",SYM1
- .asg "SYM1",SYM2
- .asg "SYM2",x
- add x,a ; final code assembled is "add x, a"
-
- Macro parameters are converted to subsyms; a side effect of this is
-the normal `as' '\ARG' dereferencing syntax is unnecessary. Subsyms
-defined within a macro will have global scope, unless the `.var'
-directive is used to identify the subsym as a local macro variable
-*note `.var': TIC54X-Directives.
-
- Substitution may be forced in situations where replacement might be
-ambiguous by placing colons on either side of the subsym. The following
-code:
-
- .eval "10",x
- LAB:X: add #x, a
-
- When assembled becomes:
-
- LAB10 add #10, a
-
- Smaller parts of the string assigned to a subsym may be accessed with
-the following syntax:
-
-``:SYMBOL(CHAR_INDEX):''
- Evaluates to a single-character string, the character at
- CHAR_INDEX.
-
-``:SYMBOL(START,LENGTH):''
- Evaluates to a substring of SYMBOL beginning at START with length
- LENGTH.
-
-
-File: as.info, Node: TIC54X-Locals, Next: TIC54X-Builtins, Prev: TIC54X-Subsyms, Up: TIC54X-Dependent
-
-9.36.6 Local Labels
--------------------
-
-Local labels may be defined in two ways:
-
- * $N, where N is a decimal number between 0 and 9
-
- * LABEL?, where LABEL is any legal symbol name.
-
- Local labels thus defined may be redefined or automatically
-generated. The scope of a local label is based on when it may be
-undefined or reset. This happens when one of the following situations
-is encountered:
-
- * .newblock directive *note `.newblock': TIC54X-Directives.
-
- * The current section is changed (.sect, .text, or .data)
-
- * Entering or leaving an included file
-
- * The macro scope where the label was defined is exited
-
-
-File: as.info, Node: TIC54X-Builtins, Next: TIC54X-Ext, Prev: TIC54X-Locals, Up: TIC54X-Dependent
-
-9.36.7 Math Builtins
---------------------
-
-The following built-in functions may be used to generate a
-floating-point value. All return a floating-point value except `$cvi',
-`$int', and `$sgn', which return an integer value.
-
-``$acos(EXPR)''
- Returns the floating point arccosine of EXPR.
-
-``$asin(EXPR)''
- Returns the floating point arcsine of EXPR.
-
-``$atan(EXPR)''
- Returns the floating point arctangent of EXPR.
-
-``$atan2(EXPR1,EXPR2)''
- Returns the floating point arctangent of EXPR1 / EXPR2.
-
-``$ceil(EXPR)''
- Returns the smallest integer not less than EXPR as floating point.
-
-``$cosh(EXPR)''
- Returns the floating point hyperbolic cosine of EXPR.
-
-``$cos(EXPR)''
- Returns the floating point cosine of EXPR.
-
-``$cvf(EXPR)''
- Returns the integer value EXPR converted to floating-point.
-
-``$cvi(EXPR)''
- Returns the floating point value EXPR converted to integer.
-
-``$exp(EXPR)''
- Returns the floating point value e ^ EXPR.
-
-``$fabs(EXPR)''
- Returns the floating point absolute value of EXPR.
-
-``$floor(EXPR)''
- Returns the largest integer that is not greater than EXPR as
- floating point.
-
-``$fmod(EXPR1,EXPR2)''
- Returns the floating point remainder of EXPR1 / EXPR2.
-
-``$int(EXPR)''
- Returns 1 if EXPR evaluates to an integer, zero otherwise.
-
-``$ldexp(EXPR1,EXPR2)''
- Returns the floating point value EXPR1 * 2 ^ EXPR2.
-
-``$log10(EXPR)''
- Returns the base 10 logarithm of EXPR.
-
-``$log(EXPR)''
- Returns the natural logarithm of EXPR.
-
-``$max(EXPR1,EXPR2)''
- Returns the floating point maximum of EXPR1 and EXPR2.
-
-``$min(EXPR1,EXPR2)''
- Returns the floating point minimum of EXPR1 and EXPR2.
-
-``$pow(EXPR1,EXPR2)''
- Returns the floating point value EXPR1 ^ EXPR2.
-
-``$round(EXPR)''
- Returns the nearest integer to EXPR as a floating point number.
-
-``$sgn(EXPR)''
- Returns -1, 0, or 1 based on the sign of EXPR.
-
-``$sin(EXPR)''
- Returns the floating point sine of EXPR.
-
-``$sinh(EXPR)''
- Returns the floating point hyperbolic sine of EXPR.
-
-``$sqrt(EXPR)''
- Returns the floating point square root of EXPR.
-
-``$tan(EXPR)''
- Returns the floating point tangent of EXPR.
-
-``$tanh(EXPR)''
- Returns the floating point hyperbolic tangent of EXPR.
-
-``$trunc(EXPR)''
- Returns the integer value of EXPR truncated towards zero as
- floating point.
-
-
-
-File: as.info, Node: TIC54X-Ext, Next: TIC54X-Directives, Prev: TIC54X-Builtins, Up: TIC54X-Dependent
-
-9.36.8 Extended Addressing
---------------------------
-
-The `LDX' pseudo-op is provided for loading the extended addressing bits
-of a label or address. For example, if an address `_label' resides in
-extended program memory, the value of `_label' may be loaded as follows:
- ldx #_label,16,a ; loads extended bits of _label
- or #_label,a ; loads lower 16 bits of _label
- bacc a ; full address is in accumulator A
-
-
-File: as.info, Node: TIC54X-Directives, Next: TIC54X-Macros, Prev: TIC54X-Ext, Up: TIC54X-Dependent
-
-9.36.9 Directives
------------------
-
-`.align [SIZE]'
-`.even'
- Align the section program counter on the next boundary, based on
- SIZE. SIZE may be any power of 2. `.even' is equivalent to
- `.align' with a SIZE of 2.
- `1'
- Align SPC to word boundary
-
- `2'
- Align SPC to longword boundary (same as .even)
-
- `128'
- Align SPC to page boundary
-
-`.asg STRING, NAME'
- Assign NAME the string STRING. String replacement is performed on
- STRING before assignment.
-
-`.eval STRING, NAME'
- Evaluate the contents of string STRING and assign the result as a
- string to the subsym NAME. String replacement is performed on
- STRING before assignment.
-
-`.bss SYMBOL, SIZE [, [BLOCKING_FLAG] [,ALIGNMENT_FLAG]]'
- Reserve space for SYMBOL in the .bss section. SIZE is in words.
- If present, BLOCKING_FLAG indicates the allocated space should be
- aligned on a page boundary if it would otherwise cross a page
- boundary. If present, ALIGNMENT_FLAG causes the assembler to
- allocate SIZE on a long word boundary.
-
-`.byte VALUE [,...,VALUE_N]'
-`.ubyte VALUE [,...,VALUE_N]'
-`.char VALUE [,...,VALUE_N]'
-`.uchar VALUE [,...,VALUE_N]'
- Place one or more bytes into consecutive words of the current
- section. The upper 8 bits of each word is zero-filled. If a
- label is used, it points to the word allocated for the first byte
- encountered.
-
-`.clink ["SECTION_NAME"]'
- Set STYP_CLINK flag for this section, which indicates to the
- linker that if no symbols from this section are referenced, the
- section should not be included in the link. If SECTION_NAME is
- omitted, the current section is used.
-
-`.c_mode'
- TBD.
-
-`.copy "FILENAME" | FILENAME'
-`.include "FILENAME" | FILENAME'
- Read source statements from FILENAME. The normal include search
- path is used. Normally .copy will cause statements from the
- included file to be printed in the assembly listing and .include
- will not, but this distinction is not currently implemented.
-
-`.data'
- Begin assembling code into the .data section.
-
-`.double VALUE [,...,VALUE_N]'
-`.ldouble VALUE [,...,VALUE_N]'
-`.float VALUE [,...,VALUE_N]'
-`.xfloat VALUE [,...,VALUE_N]'
- Place an IEEE single-precision floating-point representation of
- one or more floating-point values into the current section. All
- but `.xfloat' align the result on a longword boundary. Values are
- stored most-significant word first.
-
-`.drlist'
-`.drnolist'
- Control printing of directives to the listing file. Ignored.
-
-`.emsg STRING'
-`.mmsg STRING'
-`.wmsg STRING'
- Emit a user-defined error, message, or warning, respectively.
-
-`.far_mode'
- Use extended addressing when assembling statements. This should
- appear only once per file, and is equivalent to the -mfar-mode
- option *note `-mfar-mode': TIC54X-Opts.
-
-`.fclist'
-`.fcnolist'
- Control printing of false conditional blocks to the listing file.
-
-`.field VALUE [,SIZE]'
- Initialize a bitfield of SIZE bits in the current section. If
- VALUE is relocatable, then SIZE must be 16. SIZE defaults to 16
- bits. If VALUE does not fit into SIZE bits, the value will be
- truncated. Successive `.field' directives will pack starting at
- the current word, filling the most significant bits first, and
- aligning to the start of the next word if the field size does not
- fit into the space remaining in the current word. A `.align'
- directive with an operand of 1 will force the next `.field'
- directive to begin packing into a new word. If a label is used, it
- points to the word that contains the specified field.
-
-`.global SYMBOL [,...,SYMBOL_N]'
-`.def SYMBOL [,...,SYMBOL_N]'
-`.ref SYMBOL [,...,SYMBOL_N]'
- `.def' nominally identifies a symbol defined in the current file
- and available to other files. `.ref' identifies a symbol used in
- the current file but defined elsewhere. Both map to the standard
- `.global' directive.
-
-`.half VALUE [,...,VALUE_N]'
-`.uhalf VALUE [,...,VALUE_N]'
-`.short VALUE [,...,VALUE_N]'
-`.ushort VALUE [,...,VALUE_N]'
-`.int VALUE [,...,VALUE_N]'
-`.uint VALUE [,...,VALUE_N]'
-`.word VALUE [,...,VALUE_N]'
-`.uword VALUE [,...,VALUE_N]'
- Place one or more values into consecutive words of the current
- section. If a label is used, it points to the word allocated for
- the first value encountered.
-
-`.label SYMBOL'
- Define a special SYMBOL to refer to the load time address of the
- current section program counter.
-
-`.length'
-`.width'
- Set the page length and width of the output listing file. Ignored.
-
-`.list'
-`.nolist'
- Control whether the source listing is printed. Ignored.
-
-`.long VALUE [,...,VALUE_N]'
-`.ulong VALUE [,...,VALUE_N]'
-`.xlong VALUE [,...,VALUE_N]'
- Place one or more 32-bit values into consecutive words in the
- current section. The most significant word is stored first.
- `.long' and `.ulong' align the result on a longword boundary;
- `xlong' does not.
-
-`.loop [COUNT]'
-`.break [CONDITION]'
-`.endloop'
- Repeatedly assemble a block of code. `.loop' begins the block, and
- `.endloop' marks its termination. COUNT defaults to 1024, and
- indicates the number of times the block should be repeated.
- `.break' terminates the loop so that assembly begins after the
- `.endloop' directive. The optional CONDITION will cause the loop
- to terminate only if it evaluates to zero.
-
-`MACRO_NAME .macro [PARAM1][,...PARAM_N]'
-`[.mexit]'
-`.endm'
- See the section on macros for more explanation (*Note
- TIC54X-Macros::.
-
-`.mlib "FILENAME" | FILENAME'
- Load the macro library FILENAME. FILENAME must be an archived
- library (BFD ar-compatible) of text files, expected to contain
- only macro definitions. The standard include search path is used.
-
-`.mlist'
-`.mnolist'
- Control whether to include macro and loop block expansions in the
- listing output. Ignored.
-
-`.mmregs'
- Define global symbolic names for the 'c54x registers. Supposedly
- equivalent to executing `.set' directives for each register with
- its memory-mapped value, but in reality is provided only for
- compatibility and does nothing.
-
-`.newblock'
- This directive resets any TIC54X local labels currently defined.
- Normal `as' local labels are unaffected.
-
-`.option OPTION_LIST'
- Set listing options. Ignored.
-
-`.sblock "SECTION_NAME" | SECTION_NAME [,"NAME_N" | NAME_N]'
- Designate SECTION_NAME for blocking. Blocking guarantees that a
- section will start on a page boundary (128 words) if it would
- otherwise cross a page boundary. Only initialized sections may be
- designated with this directive. See also *Note TIC54X-Block::.
-
-`.sect "SECTION_NAME"'
- Define a named initialized section and make it the current section.
-
-`SYMBOL .set "VALUE"'
-`SYMBOL .equ "VALUE"'
- Equate a constant VALUE to a SYMBOL, which is placed in the symbol
- table. SYMBOL may not be previously defined.
-
-`.space SIZE_IN_BITS'
-`.bes SIZE_IN_BITS'
- Reserve the given number of bits in the current section and
- zero-fill them. If a label is used with `.space', it points to the
- *first* word reserved. With `.bes', the label points to the
- *last* word reserved.
-
-`.sslist'
-`.ssnolist'
- Controls the inclusion of subsym replacement in the listing
- output. Ignored.
-
-`.string "STRING" [,...,"STRING_N"]'
-`.pstring "STRING" [,...,"STRING_N"]'
- Place 8-bit characters from STRING into the current section.
- `.string' zero-fills the upper 8 bits of each word, while
- `.pstring' puts two characters into each word, filling the
- most-significant bits first. Unused space is zero-filled. If a
- label is used, it points to the first word initialized.
-
-`[STAG] .struct [OFFSET]'
-`[NAME_1] element [COUNT_1]'
-`[NAME_2] element [COUNT_2]'
-`[TNAME] .tag STAGX [TCOUNT]'
-`...'
-`[NAME_N] element [COUNT_N]'
-`[SSIZE] .endstruct'
-`LABEL .tag [STAG]'
- Assign symbolic offsets to the elements of a structure. STAG
- defines a symbol to use to reference the structure. OFFSET
- indicates a starting value to use for the first element
- encountered; otherwise it defaults to zero. Each element can have
- a named offset, NAME, which is a symbol assigned the value of the
- element's offset into the structure. If STAG is missing, these
- become global symbols. COUNT adjusts the offset that many times,
- as if `element' were an array. `element' may be one of `.byte',
- `.word', `.long', `.float', or any equivalent of those, and the
- structure offset is adjusted accordingly. `.field' and `.string'
- are also allowed; the size of `.field' is one bit, and `.string'
- is considered to be one word in size. Only element descriptors,
- structure/union tags, `.align' and conditional assembly directives
- are allowed within `.struct'/`.endstruct'. `.align' aligns member
- offsets to word boundaries only. SSIZE, if provided, will always
- be assigned the size of the structure.
-
- The `.tag' directive, in addition to being used to define a
- structure/union element within a structure, may be used to apply a
- structure to a symbol. Once applied to LABEL, the individual
- structure elements may be applied to LABEL to produce the desired
- offsets using LABEL as the structure base.
-
-`.tab'
- Set the tab size in the output listing. Ignored.
-
-`[UTAG] .union'
-`[NAME_1] element [COUNT_1]'
-`[NAME_2] element [COUNT_2]'
-`[TNAME] .tag UTAGX[,TCOUNT]'
-`...'
-`[NAME_N] element [COUNT_N]'
-`[USIZE] .endstruct'
-`LABEL .tag [UTAG]'
- Similar to `.struct', but the offset after each element is reset to
- zero, and the USIZE is set to the maximum of all defined elements.
- Starting offset for the union is always zero.
-
-`[SYMBOL] .usect "SECTION_NAME", SIZE, [,[BLOCKING_FLAG] [,ALIGNMENT_FLAG]]'
- Reserve space for variables in a named, uninitialized section
- (similar to .bss). `.usect' allows definitions sections
- independent of .bss. SYMBOL points to the first location reserved
- by this allocation. The symbol may be used as a variable name.
- SIZE is the allocated size in words. BLOCKING_FLAG indicates
- whether to block this section on a page boundary (128 words)
- (*note TIC54X-Block::). ALIGNMENT FLAG indicates whether the
- section should be longword-aligned.
-
-`.var SYM[,..., SYM_N]'
- Define a subsym to be a local variable within a macro. See *Note
- TIC54X-Macros::.
-
-`.version VERSION'
- Set which processor to build instructions for. Though the
- following values are accepted, the op is ignored.
- `541'
- `542'
- `543'
- `545'
- `545LP'
- `546LP'
- `548'
- `549'
-
-
-File: as.info, Node: TIC54X-Macros, Next: TIC54X-MMRegs, Prev: TIC54X-Directives, Up: TIC54X-Dependent
-
-9.36.10 Macros
---------------
-
-Macros do not require explicit dereferencing of arguments (i.e., \ARG).
-
- During macro expansion, the macro parameters are converted to
-subsyms. If the number of arguments passed the macro invocation
-exceeds the number of parameters defined, the last parameter is
-assigned the string equivalent of all remaining arguments. If fewer
-arguments are given than parameters, the missing parameters are
-assigned empty strings. To include a comma in an argument, you must
-enclose the argument in quotes.
-
- The following built-in subsym functions allow examination of the
-string value of subsyms (or ordinary strings). The arguments are
-strings unless otherwise indicated (subsyms passed as args will be
-replaced by the strings they represent).
-``$symlen(STR)''
- Returns the length of STR.
-
-``$symcmp(STR1,STR2)''
- Returns 0 if STR1 == STR2, non-zero otherwise.
-
-``$firstch(STR,CH)''
- Returns index of the first occurrence of character constant CH in
- STR.
-
-``$lastch(STR,CH)''
- Returns index of the last occurrence of character constant CH in
- STR.
-
-``$isdefed(SYMBOL)''
- Returns zero if the symbol SYMBOL is not in the symbol table,
- non-zero otherwise.
-
-``$ismember(SYMBOL,LIST)''
- Assign the first member of comma-separated string LIST to SYMBOL;
- LIST is reassigned the remainder of the list. Returns zero if
- LIST is a null string. Both arguments must be subsyms.
-
-``$iscons(EXPR)''
- Returns 1 if string EXPR is binary, 2 if octal, 3 if hexadecimal,
- 4 if a character, 5 if decimal, and zero if not an integer.
-
-``$isname(NAME)''
- Returns 1 if NAME is a valid symbol name, zero otherwise.
-
-``$isreg(REG)''
- Returns 1 if REG is a valid predefined register name (AR0-AR7
- only).
-
-``$structsz(STAG)''
- Returns the size of the structure or union represented by STAG.
-
-``$structacc(STAG)''
- Returns the reference point of the structure or union represented
- by STAG. Always returns zero.
-
-
-
-File: as.info, Node: TIC54X-MMRegs, Prev: TIC54X-Macros, Up: TIC54X-Dependent
-
-9.36.11 Memory-mapped Registers
--------------------------------
-
-The following symbols are recognized as memory-mapped registers:
-
-
-
-File: as.info, Node: TIC6X-Dependent, Next: V850-Dependent, Prev: TIC54X-Dependent, Up: Machine Dependencies
-
-9.37 TIC6X Dependent Features
-=============================
-
-* Menu:
-
-* TIC6X Options:: Options
-* TIC6X Syntax:: Syntax
-* TIC6X Directives:: Directives
-
-
-File: as.info, Node: TIC6X Options, Next: TIC6X Syntax, Up: TIC6X-Dependent
-
-9.37.1 TIC6X Options
---------------------
-
-`-march=ARCH'
- Enable (only) instructions from architecture ARCH. By default,
- all instructions are permitted.
-
- The following values of ARCH are accepted: `c62x', `c64x',
- `c64x+', `c67x', `c67x+', `c674x'.
-
-`-matomic'
-`-mno-atomic'
- Enable or disable the optional C64x+ atomic operation instructions.
- By default, they are enabled if no `-march' option is given, or if
- an architecture is specified with `-march' that implies these
- instructions are present (currently, there are no such
- architectures); they are disabled if an architecture is specified
- with `-march' on which the instructions are optional or not
- present. This option overrides such a default from the
- architecture, independent of the order in which the `-march' or
- `-matomic' or `-mno-atomic' options are passed.
-
-`-mdsbt'
-`-mno-dsbt'
- The `-mdsbt' option causes the assembler to generate the
- `Tag_ABI_DSBT' attribute with a value of 1, indicating that the
- code is using DSBT addressing. The `-mno-dsbt' option, the
- default, causes the tag to have a value of 0, indicating that the
- code does not use DSBT addressing. The linker will emit a warning
- if objects of different type (DSBT and non-DSBT) are linked
- together.
-
-`-mpid=no'
-`-mpid=near'
-`-mpid=far'
- The `-mpid=' option causes the assembler to generate the
- `Tag_ABI_PID' attribute with a value indicating the form of data
- addressing used by the code. `-mpid=no', the default, indicates
- position-dependent data addressing, `-mpid=near' indicates
- position-independent addressing with GOT accesses using near DP
- addressing, and `-mpid=far' indicates position-independent
- addressing with GOT accesses using far DP addressing. The linker
- will emit a warning if objects built with different settings of
- this option are linked together.
-
-`-mpic'
-`-mno-pic'
- The `-mpic' option causes the assembler to generate the
- `Tag_ABI_PIC' attribute with a value of 1, indicating that the
- code is using position-independent code addressing, The
- `-mno-pic' option, the default, causes the tag to have a value of
- 0, indicating position-dependent code addressing. The linker will
- emit a warning if objects of different type (position-dependent and
- position-independent) are linked together.
-
-`-mbig-endian'
-`-mlittle-endian'
- Generate code for the specified endianness. The default is
- little-endian.
-
-
-
-File: as.info, Node: TIC6X Syntax, Next: TIC6X Directives, Prev: TIC6X Options, Up: TIC6X-Dependent
-
-9.37.2 TIC6X Syntax
--------------------
-
-The presence of a `;' on a line indicates the start of a comment that
-extends to the end of the current line. If a `#' or `*' appears as the
-first character of a line, the whole line is treated as a comment.
-
- The `@' character can be used instead of a newline to separate
-statements.
-
- Instruction, register and functional unit names are case-insensitive.
-`as' requires fully-specified functional unit names, such as `.S1',
-`.L1X' or `.D1T2', on all instructions using a functional unit.
-
- For some instructions, there may be syntactic ambiguity between
-register or functional unit names and the names of labels or other
-symbols. To avoid this, enclose the ambiguous symbol name in
-parentheses; register and functional unit names may not be enclosed in
-parentheses.
-
-
-File: as.info, Node: TIC6X Directives, Prev: TIC6X Syntax, Up: TIC6X-Dependent
-
-9.37.3 TIC6X Directives
------------------------
-
-Directives controlling the set of instructions accepted by the
-assembler have effect for instructions between the directive and any
-subsequent directive overriding it.
-
-`.arch ARCH'
- This has the same effect as `-march=ARCH'.
-
-`.atomic'
-`.noatomic'
- These have the same effects as `-matomic' and `-mno-atomic'.
-
-`.c6xabi_attribute TAG, VALUE'
- Set the C6000 EABI build attribute TAG to VALUE.
-
- The TAG is either an attribute number or one of `Tag_ISA',
- `Tag_ABI_wchar_t', `Tag_ABI_stack_align_needed',
- `Tag_ABI_stack_align_preserved', `Tag_ABI_DSBT', `Tag_ABI_PID',
- `Tag_ABI_PIC', `TAG_ABI_array_object_alignment',
- `TAG_ABI_array_object_align_expected', `Tag_ABI_compatibility' and
- `Tag_ABI_conformance'. The VALUE is either a `number',
- `"string"', or `number, "string"' depending on the tag.
-
-`.nocmp'
- Disallow use of C64x+ compact instructions in the current text
- section.
-
-
-
-File: as.info, Node: Z80-Dependent, Next: Z8000-Dependent, Prev: Xtensa-Dependent, Up: Machine Dependencies
-
-9.38 Z80 Dependent Features
-===========================
-
-* Menu:
-
-* Z80 Options:: Options
-* Z80 Syntax:: Syntax
-* Z80 Floating Point:: Floating Point
-* Z80 Directives:: Z80 Machine Directives
-* Z80 Opcodes:: Opcodes
-
-
-File: as.info, Node: Z80 Options, Next: Z80 Syntax, Up: Z80-Dependent
-
-9.38.1 Options
---------------
-
-The Zilog Z80 and Ascii R800 version of `as' have a few machine
-dependent options.
-`-z80'
- Produce code for the Z80 processor. There are additional options to
- request warnings and error messages for undocumented instructions.
-
-`-ignore-undocumented-instructions'
-`-Wnud'
- Silently assemble undocumented Z80-instructions that have been
- adopted as documented R800-instructions.
-
-`-ignore-unportable-instructions'
-`-Wnup'
- Silently assemble all undocumented Z80-instructions.
-
-`-warn-undocumented-instructions'
-`-Wud'
- Issue warnings for undocumented Z80-instructions that work on
- R800, do not assemble other undocumented instructions without
- warning.
-
-`-warn-unportable-instructions'
-`-Wup'
- Issue warnings for other undocumented Z80-instructions, do not
- treat any undocumented instructions as errors.
-
-`-forbid-undocumented-instructions'
-`-Fud'
- Treat all undocumented z80-instructions as errors.
-
-`-forbid-unportable-instructions'
-`-Fup'
- Treat undocumented z80-instructions that do not work on R800 as
- errors.
-
-`-r800'
- Produce code for the R800 processor. The assembler does not support
- undocumented instructions for the R800. In line with common
- practice, `as' uses Z80 instruction names for the R800 processor,
- as far as they exist.
-
-
-File: as.info, Node: Z80 Syntax, Next: Z80 Floating Point, Prev: Z80 Options, Up: Z80-Dependent
-
-9.38.2 Syntax
--------------
-
-The assembler syntax closely follows the 'Z80 family CPU User Manual' by
-Zilog. In expressions a single `=' may be used as "is equal to"
-comparison operator.
-
- Suffices can be used to indicate the radix of integer constants; `H'
-or `h' for hexadecimal, `D' or `d' for decimal, `Q', `O', `q' or `o'
-for octal, and `B' for binary.
-
- The suffix `b' denotes a backreference to local label.
-
-* Menu:
-
-* Z80-Chars:: Special Characters
-* Z80-Regs:: Register Names
-* Z80-Case:: Case Sensitivity
-
-
-File: as.info, Node: Z80-Chars, Next: Z80-Regs, Up: Z80 Syntax
-
-9.38.2.1 Special Characters
-...........................
-
-The semicolon `;' is the line comment character;
-
- The dollar sign `$' can be used as a prefix for hexadecimal numbers
-and as a symbol denoting the current location counter.
-
- A backslash `\' is an ordinary character for the Z80 assembler.
-
- The single quote `'' must be followed by a closing quote. If there
-is one character in between, it is a character constant, otherwise it is
-a string constant.
-
-
-File: as.info, Node: Z80-Regs, Next: Z80-Case, Prev: Z80-Chars, Up: Z80 Syntax
-
-9.38.2.2 Register Names
-.......................
-
-The registers are referred to with the letters assigned to them by
-Zilog. In addition `as' recognizes `ixl' and `ixh' as the least and
-most significant octet in `ix', and similarly `iyl' and `iyh' as parts
-of `iy'.
-
-
-File: as.info, Node: Z80-Case, Prev: Z80-Regs, Up: Z80 Syntax
-
-9.38.2.3 Case Sensitivity
-.........................
-
-Upper and lower case are equivalent in register names, opcodes,
-condition codes and assembler directives. The case of letters is
-significant in labels and symbol names. The case is also important to
-distinguish the suffix `b' for a backward reference to a local label
-from the suffix `B' for a number in binary notation.
-
-
-File: as.info, Node: Z80 Floating Point, Next: Z80 Directives, Prev: Z80 Syntax, Up: Z80-Dependent
-
-9.38.3 Floating Point
----------------------
-
-Floating-point numbers are not supported.
-
-
-File: as.info, Node: Z80 Directives, Next: Z80 Opcodes, Prev: Z80 Floating Point, Up: Z80-Dependent
-
-9.38.4 Z80 Assembler Directives
--------------------------------
-
-`as' for the Z80 supports some additional directives for compatibility
-with other assemblers.
-
- These are the additional directives in `as' for the Z80:
-
-`db EXPRESSION|STRING[,EXPRESSION|STRING...]'
-`defb EXPRESSION|STRING[,EXPRESSION|STRING...]'
- For each STRING the characters are copied to the object file, for
- each other EXPRESSION the value is stored in one byte. A warning
- is issued in case of an overflow.
-
-`dw EXPRESSION[,EXPRESSION...]'
-`defw EXPRESSION[,EXPRESSION...]'
- For each EXPRESSION the value is stored in two bytes, ignoring
- overflow.
-
-`d24 EXPRESSION[,EXPRESSION...]'
-`def24 EXPRESSION[,EXPRESSION...]'
- For each EXPRESSION the value is stored in three bytes, ignoring
- overflow.
-
-`d32 EXPRESSION[,EXPRESSION...]'
-`def32 EXPRESSION[,EXPRESSION...]'
- For each EXPRESSION the value is stored in four bytes, ignoring
- overflow.
-
-`ds COUNT[, VALUE]'
-`defs COUNT[, VALUE]'
- Fill COUNT bytes in the object file with VALUE, if VALUE is
- omitted it defaults to zero.
-
-`SYMBOL equ EXPRESSION'
-`SYMBOL defl EXPRESSION'
- These directives set the value of SYMBOL to EXPRESSION. If `equ'
- is used, it is an error if SYMBOL is already defined. Symbols
- defined with `equ' are not protected from redefinition.
-
-`set'
- This is a normal instruction on Z80, and not an assembler
- directive.
-
-`psect NAME'
- A synonym for *Note Section::, no second argument should be given.
-
-
-
-File: as.info, Node: Z80 Opcodes, Prev: Z80 Directives, Up: Z80-Dependent
-
-9.38.5 Opcodes
---------------
-
-In line with common practice, Z80 mnemonics are used for both the Z80
-and the R800.
-
- In many instructions it is possible to use one of the half index
-registers (`ixl',`ixh',`iyl',`iyh') in stead of an 8-bit general
-purpose register. This yields instructions that are documented on the
-R800 and undocumented on the Z80. Similarly `in f,(c)' is documented
-on the R800 and undocumented on the Z80.
-
- The assembler also supports the following undocumented
-Z80-instructions, that have not been adopted in the R800 instruction
-set:
-`out (c),0'
- Sends zero to the port pointed to by register c.
-
-`sli M'
- Equivalent to `M = (M<<1)+1', the operand M can be any operand
- that is valid for `sla'. One can use `sll' as a synonym for `sli'.
-
-`OP (ix+D), R'
- This is equivalent to
-
- ld R, (ix+D)
- OPC R
- ld (ix+D), R
-
- The operation `OPC' may be any of `res B,', `set B,', `rl', `rlc',
- `rr', `rrc', `sla', `sli', `sra' and `srl', and the register `R'
- may be any of `a', `b', `c', `d', `e', `h' and `l'.
-
-`OPC (iy+D), R'
- As above, but with `iy' instead of `ix'.
-
- The web site at `http://www.z80.info' is a good starting place to
-find more information on programming the Z80.
-
-
-File: as.info, Node: Z8000-Dependent, Next: Vax-Dependent, Prev: Z80-Dependent, Up: Machine Dependencies
-
-9.39 Z8000 Dependent Features
-=============================
-
- The Z8000 as supports both members of the Z8000 family: the
-unsegmented Z8002, with 16 bit addresses, and the segmented Z8001 with
-24 bit addresses.
-
- When the assembler is in unsegmented mode (specified with the
-`unsegm' directive), an address takes up one word (16 bit) sized
-register. When the assembler is in segmented mode (specified with the
-`segm' directive), a 24-bit address takes up a long (32 bit) register.
-*Note Assembler Directives for the Z8000: Z8000 Directives, for a list
-of other Z8000 specific assembler directives.
-
-* Menu:
-
-* Z8000 Options:: Command-line options for the Z8000
-* Z8000 Syntax:: Assembler syntax for the Z8000
-* Z8000 Directives:: Special directives for the Z8000
-* Z8000 Opcodes:: Opcodes
-
-
-File: as.info, Node: Z8000 Options, Next: Z8000 Syntax, Up: Z8000-Dependent
-
-9.39.1 Options
---------------
-
-`-z8001'
- Generate segmented code by default.
-
-`-z8002'
- Generate unsegmented code by default.
-
-
-File: as.info, Node: Z8000 Syntax, Next: Z8000 Directives, Prev: Z8000 Options, Up: Z8000-Dependent
-
-9.39.2 Syntax
--------------
-
-* Menu:
-
-* Z8000-Chars:: Special Characters
-* Z8000-Regs:: Register Names
-* Z8000-Addressing:: Addressing Modes
-
-
-File: as.info, Node: Z8000-Chars, Next: Z8000-Regs, Up: Z8000 Syntax
-
-9.39.2.1 Special Characters
-...........................
-
-`!' is the line comment character.
-
- You can use `;' instead of a newline to separate statements.
-
-
-File: as.info, Node: Z8000-Regs, Next: Z8000-Addressing, Prev: Z8000-Chars, Up: Z8000 Syntax
-
-9.39.2.2 Register Names
-.......................
-
-The Z8000 has sixteen 16 bit registers, numbered 0 to 15. You can refer
-to different sized groups of registers by register number, with the
-prefix `r' for 16 bit registers, `rr' for 32 bit registers and `rq' for
-64 bit registers. You can also refer to the contents of the first
-eight (of the sixteen 16 bit registers) by bytes. They are named `rlN'
-and `rhN'.
-
-_byte registers_
- rl0 rh0 rl1 rh1 rl2 rh2 rl3 rh3
- rl4 rh4 rl5 rh5 rl6 rh6 rl7 rh7
-
-_word registers_
- r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15
-
-_long word registers_
- rr0 rr2 rr4 rr6 rr8 rr10 rr12 rr14
-
-_quad word registers_
- rq0 rq4 rq8 rq12
-
-
-File: as.info, Node: Z8000-Addressing, Prev: Z8000-Regs, Up: Z8000 Syntax
-
-9.39.2.3 Addressing Modes
-.........................
-
-as understands the following addressing modes for the Z8000:
-
-`rlN'
-`rhN'
-`rN'
-`rrN'
-`rqN'
- Register direct: 8bit, 16bit, 32bit, and 64bit registers.
-
-`@rN'
-`@rrN'
- Indirect register: @rrN in segmented mode, @rN in unsegmented
- mode.
-
-`ADDR'
- Direct: the 16 bit or 24 bit address (depending on whether the
- assembler is in segmented or unsegmented mode) of the operand is
- in the instruction.
-
-`address(rN)'
- Indexed: the 16 or 24 bit address is added to the 16 bit register
- to produce the final address in memory of the operand.
-
-`rN(#IMM)'
-`rrN(#IMM)'
- Base Address: the 16 or 24 bit register is added to the 16 bit sign
- extended immediate displacement to produce the final address in
- memory of the operand.
-
-`rN(rM)'
-`rrN(rM)'
- Base Index: the 16 or 24 bit register rN or rrN is added to the
- sign extended 16 bit index register rM to produce the final
- address in memory of the operand.
-
-`#XX'
- Immediate data XX.
-
-
-File: as.info, Node: Z8000 Directives, Next: Z8000 Opcodes, Prev: Z8000 Syntax, Up: Z8000-Dependent
-
-9.39.3 Assembler Directives for the Z8000
------------------------------------------
-
-The Z8000 port of as includes additional assembler directives, for
-compatibility with other Z8000 assemblers. These do not begin with `.'
-(unlike the ordinary as directives).
-
-`segm'
-`.z8001'
- Generate code for the segmented Z8001.
-
-`unsegm'
-`.z8002'
- Generate code for the unsegmented Z8002.
-
-`name'
- Synonym for `.file'
-
-`global'
- Synonym for `.global'
-
-`wval'
- Synonym for `.word'
-
-`lval'
- Synonym for `.long'
-
-`bval'
- Synonym for `.byte'
-
-`sval'
- Assemble a string. `sval' expects one string literal, delimited by
- single quotes. It assembles each byte of the string into
- consecutive addresses. You can use the escape sequence `%XX'
- (where XX represents a two-digit hexadecimal number) to represent
- the character whose ASCII value is XX. Use this feature to
- describe single quote and other characters that may not appear in
- string literals as themselves. For example, the C statement
- `char *a = "he said \"it's 50% off\"";' is represented in Z8000
- assembly language (shown with the assembler output in hex at the
- left) as
-
- 68652073 sval 'he said %22it%27s 50%25 off%22%00'
- 61696420
- 22697427
- 73203530
- 25206F66
- 662200
-
-`rsect'
- synonym for `.section'
-
-`block'
- synonym for `.space'
-
-`even'
- special case of `.align'; aligns output to even byte boundary.
-
-
-File: as.info, Node: Z8000 Opcodes, Prev: Z8000 Directives, Up: Z8000-Dependent
-
-9.39.4 Opcodes
---------------
-
-For detailed information on the Z8000 machine instruction set, see
-`Z8000 Technical Manual'.
-
- The following table summarizes the opcodes and their arguments:
-
- rs 16 bit source register
- rd 16 bit destination register
- rbs 8 bit source register
- rbd 8 bit destination register
- rrs 32 bit source register
- rrd 32 bit destination register
- rqs 64 bit source register
- rqd 64 bit destination register
- addr 16/24 bit address
- imm immediate data
-
- adc rd,rs clrb addr cpsir @rd,@rs,rr,cc
- adcb rbd,rbs clrb addr(rd) cpsirb @rd,@rs,rr,cc
- add rd,@rs clrb rbd dab rbd
- add rd,addr com @rd dbjnz rbd,disp7
- add rd,addr(rs) com addr dec @rd,imm4m1
- add rd,imm16 com addr(rd) dec addr(rd),imm4m1
- add rd,rs com rd dec addr,imm4m1
- addb rbd,@rs comb @rd dec rd,imm4m1
- addb rbd,addr comb addr decb @rd,imm4m1
- addb rbd,addr(rs) comb addr(rd) decb addr(rd),imm4m1
- addb rbd,imm8 comb rbd decb addr,imm4m1
- addb rbd,rbs comflg flags decb rbd,imm4m1
- addl rrd,@rs cp @rd,imm16 di i2
- addl rrd,addr cp addr(rd),imm16 div rrd,@rs
- addl rrd,addr(rs) cp addr,imm16 div rrd,addr
- addl rrd,imm32 cp rd,@rs div rrd,addr(rs)
- addl rrd,rrs cp rd,addr div rrd,imm16
- and rd,@rs cp rd,addr(rs) div rrd,rs
- and rd,addr cp rd,imm16 divl rqd,@rs
- and rd,addr(rs) cp rd,rs divl rqd,addr
- and rd,imm16 cpb @rd,imm8 divl rqd,addr(rs)
- and rd,rs cpb addr(rd),imm8 divl rqd,imm32
- andb rbd,@rs cpb addr,imm8 divl rqd,rrs
- andb rbd,addr cpb rbd,@rs djnz rd,disp7
- andb rbd,addr(rs) cpb rbd,addr ei i2
- andb rbd,imm8 cpb rbd,addr(rs) ex rd,@rs
- andb rbd,rbs cpb rbd,imm8 ex rd,addr
- bit @rd,imm4 cpb rbd,rbs ex rd,addr(rs)
- bit addr(rd),imm4 cpd rd,@rs,rr,cc ex rd,rs
- bit addr,imm4 cpdb rbd,@rs,rr,cc exb rbd,@rs
- bit rd,imm4 cpdr rd,@rs,rr,cc exb rbd,addr
- bit rd,rs cpdrb rbd,@rs,rr,cc exb rbd,addr(rs)
- bitb @rd,imm4 cpi rd,@rs,rr,cc exb rbd,rbs
- bitb addr(rd),imm4 cpib rbd,@rs,rr,cc ext0e imm8
- bitb addr,imm4 cpir rd,@rs,rr,cc ext0f imm8
- bitb rbd,imm4 cpirb rbd,@rs,rr,cc ext8e imm8
- bitb rbd,rs cpl rrd,@rs ext8f imm8
- bpt cpl rrd,addr exts rrd
- call @rd cpl rrd,addr(rs) extsb rd
- call addr cpl rrd,imm32 extsl rqd
- call addr(rd) cpl rrd,rrs halt
- calr disp12 cpsd @rd,@rs,rr,cc in rd,@rs
- clr @rd cpsdb @rd,@rs,rr,cc in rd,imm16
- clr addr cpsdr @rd,@rs,rr,cc inb rbd,@rs
- clr addr(rd) cpsdrb @rd,@rs,rr,cc inb rbd,imm16
- clr rd cpsi @rd,@rs,rr,cc inc @rd,imm4m1
- clrb @rd cpsib @rd,@rs,rr,cc inc addr(rd),imm4m1
- inc addr,imm4m1 ldb rbd,rs(rx) mult rrd,addr(rs)
- inc rd,imm4m1 ldb rd(imm16),rbs mult rrd,imm16
- incb @rd,imm4m1 ldb rd(rx),rbs mult rrd,rs
- incb addr(rd),imm4m1 ldctl ctrl,rs multl rqd,@rs
- incb addr,imm4m1 ldctl rd,ctrl multl rqd,addr
- incb rbd,imm4m1 ldd @rs,@rd,rr multl rqd,addr(rs)
- ind @rd,@rs,ra lddb @rs,@rd,rr multl rqd,imm32
- indb @rd,@rs,rba lddr @rs,@rd,rr multl rqd,rrs
- inib @rd,@rs,ra lddrb @rs,@rd,rr neg @rd
- inibr @rd,@rs,ra ldi @rd,@rs,rr neg addr
- iret ldib @rd,@rs,rr neg addr(rd)
- jp cc,@rd ldir @rd,@rs,rr neg rd
- jp cc,addr ldirb @rd,@rs,rr negb @rd
- jp cc,addr(rd) ldk rd,imm4 negb addr
- jr cc,disp8 ldl @rd,rrs negb addr(rd)
- ld @rd,imm16 ldl addr(rd),rrs negb rbd
- ld @rd,rs ldl addr,rrs nop
- ld addr(rd),imm16 ldl rd(imm16),rrs or rd,@rs
- ld addr(rd),rs ldl rd(rx),rrs or rd,addr
- ld addr,imm16 ldl rrd,@rs or rd,addr(rs)
- ld addr,rs ldl rrd,addr or rd,imm16
- ld rd(imm16),rs ldl rrd,addr(rs) or rd,rs
- ld rd(rx),rs ldl rrd,imm32 orb rbd,@rs
- ld rd,@rs ldl rrd,rrs orb rbd,addr
- ld rd,addr ldl rrd,rs(imm16) orb rbd,addr(rs)
- ld rd,addr(rs) ldl rrd,rs(rx) orb rbd,imm8
- ld rd,imm16 ldm @rd,rs,n orb rbd,rbs
- ld rd,rs ldm addr(rd),rs,n out @rd,rs
- ld rd,rs(imm16) ldm addr,rs,n out imm16,rs
- ld rd,rs(rx) ldm rd,@rs,n outb @rd,rbs
- lda rd,addr ldm rd,addr(rs),n outb imm16,rbs
- lda rd,addr(rs) ldm rd,addr,n outd @rd,@rs,ra
- lda rd,rs(imm16) ldps @rs outdb @rd,@rs,rba
- lda rd,rs(rx) ldps addr outib @rd,@rs,ra
- ldar rd,disp16 ldps addr(rs) outibr @rd,@rs,ra
- ldb @rd,imm8 ldr disp16,rs pop @rd,@rs
- ldb @rd,rbs ldr rd,disp16 pop addr(rd),@rs
- ldb addr(rd),imm8 ldrb disp16,rbs pop addr,@rs
- ldb addr(rd),rbs ldrb rbd,disp16 pop rd,@rs
- ldb addr,imm8 ldrl disp16,rrs popl @rd,@rs
- ldb addr,rbs ldrl rrd,disp16 popl addr(rd),@rs
- ldb rbd,@rs mbit popl addr,@rs
- ldb rbd,addr mreq rd popl rrd,@rs
- ldb rbd,addr(rs) mres push @rd,@rs
- ldb rbd,imm8 mset push @rd,addr
- ldb rbd,rbs mult rrd,@rs push @rd,addr(rs)
- ldb rbd,rs(imm16) mult rrd,addr push @rd,imm16
- push @rd,rs set addr,imm4 subl rrd,imm32
- pushl @rd,@rs set rd,imm4 subl rrd,rrs
- pushl @rd,addr set rd,rs tcc cc,rd
- pushl @rd,addr(rs) setb @rd,imm4 tccb cc,rbd
- pushl @rd,rrs setb addr(rd),imm4 test @rd
- res @rd,imm4 setb addr,imm4 test addr
- res addr(rd),imm4 setb rbd,imm4 test addr(rd)
- res addr,imm4 setb rbd,rs test rd
- res rd,imm4 setflg imm4 testb @rd
- res rd,rs sinb rbd,imm16 testb addr
- resb @rd,imm4 sinb rd,imm16 testb addr(rd)
- resb addr(rd),imm4 sind @rd,@rs,ra testb rbd
- resb addr,imm4 sindb @rd,@rs,rba testl @rd
- resb rbd,imm4 sinib @rd,@rs,ra testl addr
- resb rbd,rs sinibr @rd,@rs,ra testl addr(rd)
- resflg imm4 sla rd,imm8 testl rrd
- ret cc slab rbd,imm8 trdb @rd,@rs,rba
- rl rd,imm1or2 slal rrd,imm8 trdrb @rd,@rs,rba
- rlb rbd,imm1or2 sll rd,imm8 trib @rd,@rs,rbr
- rlc rd,imm1or2 sllb rbd,imm8 trirb @rd,@rs,rbr
- rlcb rbd,imm1or2 slll rrd,imm8 trtdrb @ra,@rb,rbr
- rldb rbb,rba sout imm16,rs trtib @ra,@rb,rr
- rr rd,imm1or2 soutb imm16,rbs trtirb @ra,@rb,rbr
- rrb rbd,imm1or2 soutd @rd,@rs,ra trtrb @ra,@rb,rbr
- rrc rd,imm1or2 soutdb @rd,@rs,rba tset @rd
- rrcb rbd,imm1or2 soutib @rd,@rs,ra tset addr
- rrdb rbb,rba soutibr @rd,@rs,ra tset addr(rd)
- rsvd36 sra rd,imm8 tset rd
- rsvd38 srab rbd,imm8 tsetb @rd
- rsvd78 sral rrd,imm8 tsetb addr
- rsvd7e srl rd,imm8 tsetb addr(rd)
- rsvd9d srlb rbd,imm8 tsetb rbd
- rsvd9f srll rrd,imm8 xor rd,@rs
- rsvdb9 sub rd,@rs xor rd,addr
- rsvdbf sub rd,addr xor rd,addr(rs)
- sbc rd,rs sub rd,addr(rs) xor rd,imm16
- sbcb rbd,rbs sub rd,imm16 xor rd,rs
- sc imm8 sub rd,rs xorb rbd,@rs
- sda rd,rs subb rbd,@rs xorb rbd,addr
- sdab rbd,rs subb rbd,addr xorb rbd,addr(rs)
- sdal rrd,rs subb rbd,addr(rs) xorb rbd,imm8
- sdl rd,rs subb rbd,imm8 xorb rbd,rbs
- sdlb rbd,rs subb rbd,rbs xorb rbd,rbs
- sdll rrd,rs subl rrd,@rs
- set @rd,imm4 subl rrd,addr
- set addr(rd),imm4 subl rrd,addr(rs)
-
-
-File: as.info, Node: Vax-Dependent, Prev: Z8000-Dependent, Up: Machine Dependencies
-
-9.40 VAX Dependent Features
-===========================
-
-* Menu:
-
-* VAX-Opts:: VAX Command-Line Options
-* VAX-float:: VAX Floating Point
-* VAX-directives:: Vax Machine Directives
-* VAX-opcodes:: VAX Opcodes
-* VAX-branch:: VAX Branch Improvement
-* VAX-operands:: VAX Operands
-* VAX-no:: Not Supported on VAX
-
-
-File: as.info, Node: VAX-Opts, Next: VAX-float, Up: Vax-Dependent
-
-9.40.1 VAX Command-Line Options
--------------------------------
-
-The Vax version of `as' accepts any of the following options, gives a
-warning message that the option was ignored and proceeds. These
-options are for compatibility with scripts designed for other people's
-assemblers.
-
-``-D' (Debug)'
-``-S' (Symbol Table)'
-``-T' (Token Trace)'
- These are obsolete options used to debug old assemblers.
-
-``-d' (Displacement size for JUMPs)'
- This option expects a number following the `-d'. Like options
- that expect filenames, the number may immediately follow the `-d'
- (old standard) or constitute the whole of the command line
- argument that follows `-d' (GNU standard).
-
-``-V' (Virtualize Interpass Temporary File)'
- Some other assemblers use a temporary file. This option commanded
- them to keep the information in active memory rather than in a
- disk file. `as' always does this, so this option is redundant.
-
-``-J' (JUMPify Longer Branches)'
- Many 32-bit computers permit a variety of branch instructions to
- do the same job. Some of these instructions are short (and fast)
- but have a limited range; others are long (and slow) but can
- branch anywhere in virtual memory. Often there are 3 flavors of
- branch: short, medium and long. Some other assemblers would emit
- short and medium branches, unless told by this option to emit
- short and long branches.
-
-``-t' (Temporary File Directory)'
- Some other assemblers may use a temporary file, and this option
- takes a filename being the directory to site the temporary file.
- Since `as' does not use a temporary disk file, this option makes
- no difference. `-t' needs exactly one filename.
-
- The Vax version of the assembler accepts additional options when
-compiled for VMS:
-
-`-h N'
- External symbol or section (used for global variables) names are
- not case sensitive on VAX/VMS and always mapped to upper case.
- This is contrary to the C language definition which explicitly
- distinguishes upper and lower case. To implement a standard
- conforming C compiler, names must be changed (mapped) to preserve
- the case information. The default mapping is to convert all lower
- case characters to uppercase and adding an underscore followed by
- a 6 digit hex value, representing a 24 digit binary value. The
- one digits in the binary value represent which characters are
- uppercase in the original symbol name.
-
- The `-h N' option determines how we map names. This takes several
- values. No `-h' switch at all allows case hacking as described
- above. A value of zero (`-h0') implies names should be upper
- case, and inhibits the case hack. A value of 2 (`-h2') implies
- names should be all lower case, with no case hack. A value of 3
- (`-h3') implies that case should be preserved. The value 1 is
- unused. The `-H' option directs `as' to display every mapped
- symbol during assembly.
-
- Symbols whose names include a dollar sign `$' are exceptions to the
- general name mapping. These symbols are normally only used to
- reference VMS library names. Such symbols are always mapped to
- upper case.
-
-`-+'
- The `-+' option causes `as' to truncate any symbol name larger
- than 31 characters. The `-+' option also prevents some code
- following the `_main' symbol normally added to make the object
- file compatible with Vax-11 "C".
-
-`-1'
- This option is ignored for backward compatibility with `as'
- version 1.x.
-
-`-H'
- The `-H' option causes `as' to print every symbol which was
- changed by case mapping.
-
-
-File: as.info, Node: VAX-float, Next: VAX-directives, Prev: VAX-Opts, Up: Vax-Dependent
-
-9.40.2 VAX Floating Point
--------------------------
-
-Conversion of flonums to floating point is correct, and compatible with
-previous assemblers. Rounding is towards zero if the remainder is
-exactly half the least significant bit.
-
- `D', `F', `G' and `H' floating point formats are understood.
-
- Immediate floating literals (_e.g._ `S`$6.9') are rendered
-correctly. Again, rounding is towards zero in the boundary case.
-
- The `.float' directive produces `f' format numbers. The `.double'
-directive produces `d' format numbers.
-
-
-File: as.info, Node: VAX-directives, Next: VAX-opcodes, Prev: VAX-float, Up: Vax-Dependent
-
-9.40.3 Vax Machine Directives
------------------------------
-
-The Vax version of the assembler supports four directives for
-generating Vax floating point constants. They are described in the
-table below.
-
-`.dfloat'
- This expects zero or more flonums, separated by commas, and
- assembles Vax `d' format 64-bit floating point constants.
-
-`.ffloat'
- This expects zero or more flonums, separated by commas, and
- assembles Vax `f' format 32-bit floating point constants.
-
-`.gfloat'
- This expects zero or more flonums, separated by commas, and
- assembles Vax `g' format 64-bit floating point constants.
-
-`.hfloat'
- This expects zero or more flonums, separated by commas, and
- assembles Vax `h' format 128-bit floating point constants.
-
-
-
-File: as.info, Node: VAX-opcodes, Next: VAX-branch, Prev: VAX-directives, Up: Vax-Dependent
-
-9.40.4 VAX Opcodes
-------------------
-
-All DEC mnemonics are supported. Beware that `case...' instructions
-have exactly 3 operands. The dispatch table that follows the `case...'
-instruction should be made with `.word' statements. This is compatible
-with all unix assemblers we know of.
-
-
-File: as.info, Node: VAX-branch, Next: VAX-operands, Prev: VAX-opcodes, Up: Vax-Dependent
-
-9.40.5 VAX Branch Improvement
------------------------------
-
-Certain pseudo opcodes are permitted. They are for branch
-instructions. They expand to the shortest branch instruction that
-reaches the target. Generally these mnemonics are made by substituting
-`j' for `b' at the start of a DEC mnemonic. This feature is included
-both for compatibility and to help compilers. If you do not need this
-feature, avoid these opcodes. Here are the mnemonics, and the code
-they can expand into.
-
-`jbsb'
- `Jsb' is already an instruction mnemonic, so we chose `jbsb'.
- (byte displacement)
- `bsbb ...'
-
- (word displacement)
- `bsbw ...'
-
- (long displacement)
- `jsb ...'
-
-`jbr'
-`jr'
- Unconditional branch.
- (byte displacement)
- `brb ...'
-
- (word displacement)
- `brw ...'
-
- (long displacement)
- `jmp ...'
-
-`jCOND'
- COND may be any one of the conditional branches `neq', `nequ',
- `eql', `eqlu', `gtr', `geq', `lss', `gtru', `lequ', `vc', `vs',
- `gequ', `cc', `lssu', `cs'. COND may also be one of the bit tests
- `bs', `bc', `bss', `bcs', `bsc', `bcc', `bssi', `bcci', `lbs',
- `lbc'. NOTCOND is the opposite condition to COND.
- (byte displacement)
- `bCOND ...'
-
- (word displacement)
- `bNOTCOND foo ; brw ... ; foo:'
-
- (long displacement)
- `bNOTCOND foo ; jmp ... ; foo:'
-
-`jacbX'
- X may be one of `b d f g h l w'.
- (word displacement)
- `OPCODE ...'
-
- (long displacement)
- OPCODE ..., foo ;
- brb bar ;
- foo: jmp ... ;
- bar:
-
-`jaobYYY'
- YYY may be one of `lss leq'.
-
-`jsobZZZ'
- ZZZ may be one of `geq gtr'.
- (byte displacement)
- `OPCODE ...'
-
- (word displacement)
- OPCODE ..., foo ;
- brb bar ;
- foo: brw DESTINATION ;
- bar:
-
- (long displacement)
- OPCODE ..., foo ;
- brb bar ;
- foo: jmp DESTINATION ;
- bar:
-
-`aobleq'
-`aoblss'
-`sobgeq'
-`sobgtr'
-
- (byte displacement)
- `OPCODE ...'
-
- (word displacement)
- OPCODE ..., foo ;
- brb bar ;
- foo: brw DESTINATION ;
- bar:
-
- (long displacement)
- OPCODE ..., foo ;
- brb bar ;
- foo: jmp DESTINATION ;
- bar:
-
-
-File: as.info, Node: VAX-operands, Next: VAX-no, Prev: VAX-branch, Up: Vax-Dependent
-
-9.40.6 VAX Operands
--------------------
-
-The immediate character is `$' for Unix compatibility, not `#' as DEC
-writes it.
-
- The indirect character is `*' for Unix compatibility, not `@' as DEC
-writes it.
-
- The displacement sizing character is ``' (an accent grave) for Unix
-compatibility, not `^' as DEC writes it. The letter preceding ``' may
-have either case. `G' is not understood, but all other letters (`b i l
-s w') are understood.
-
- Register names understood are `r0 r1 r2 ... r15 ap fp sp pc'. Upper
-and lower case letters are equivalent.
-
- For instance
- tstb *w`$4(r5)
-
- Any expression is permitted in an operand. Operands are comma
-separated.
-
-
-File: as.info, Node: VAX-no, Prev: VAX-operands, Up: Vax-Dependent
-
-9.40.7 Not Supported on VAX
----------------------------
-
-Vax bit fields can not be assembled with `as'. Someone can add the
-required code if they really need it.
-
-
-File: as.info, Node: V850-Dependent, Next: Xtensa-Dependent, Prev: TIC6X-Dependent, Up: Machine Dependencies
-
-9.41 v850 Dependent Features
-============================
-
-* Menu:
-
-* V850 Options:: Options
-* V850 Syntax:: Syntax
-* V850 Floating Point:: Floating Point
-* V850 Directives:: V850 Machine Directives
-* V850 Opcodes:: Opcodes
-
-
-File: as.info, Node: V850 Options, Next: V850 Syntax, Up: V850-Dependent
-
-9.41.1 Options
---------------
-
-`as' supports the following additional command-line options for the
-V850 processor family:
-
-`-wsigned_overflow'
- Causes warnings to be produced when signed immediate values
- overflow the space available for then within their opcodes. By
- default this option is disabled as it is possible to receive
- spurious warnings due to using exact bit patterns as immediate
- constants.
-
-`-wunsigned_overflow'
- Causes warnings to be produced when unsigned immediate values
- overflow the space available for then within their opcodes. By
- default this option is disabled as it is possible to receive
- spurious warnings due to using exact bit patterns as immediate
- constants.
-
-`-mv850'
- Specifies that the assembled code should be marked as being
- targeted at the V850 processor. This allows the linker to detect
- attempts to link such code with code assembled for other
- processors.
-
-`-mv850e'
- Specifies that the assembled code should be marked as being
- targeted at the V850E processor. This allows the linker to detect
- attempts to link such code with code assembled for other
- processors.
-
-`-mv850e1'
- Specifies that the assembled code should be marked as being
- targeted at the V850E1 processor. This allows the linker to
- detect attempts to link such code with code assembled for other
- processors.
-
-`-mv850any'
- Specifies that the assembled code should be marked as being
- targeted at the V850 processor but support instructions that are
- specific to the extended variants of the process. This allows the
- production of binaries that contain target specific code, but
- which are also intended to be used in a generic fashion. For
- example libgcc.a contains generic routines used by the code
- produced by GCC for all versions of the v850 architecture,
- together with support routines only used by the V850E architecture.
-
-`-mv850e2'
- Specifies that the assembled code should be marked as being
- targeted at the V850E2 processor. This allows the linker to
- detect attempts to link such code with code assembled for other
- processors.
-
-`-mv850e2v3'
- Specifies that the assembled code should be marked as being
- targeted at the V850E2V3 processor. This allows the linker to
- detect attempts to link such code with code assembled for other
- processors.
-
-`-mrelax'
- Enables relaxation. This allows the .longcall and .longjump pseudo
- ops to be used in the assembler source code. These ops label
- sections of code which are either a long function call or a long
- branch. The assembler will then flag these sections of code and
- the linker will attempt to relax them.
-
-
-
-File: as.info, Node: V850 Syntax, Next: V850 Floating Point, Prev: V850 Options, Up: V850-Dependent
-
-9.41.2 Syntax
--------------
-
-* Menu:
-
-* V850-Chars:: Special Characters
-* V850-Regs:: Register Names
-
-
-File: as.info, Node: V850-Chars, Next: V850-Regs, Up: V850 Syntax
-
-9.41.2.1 Special Characters
-...........................
-
-`#' is the line comment character.
-
-
-File: as.info, Node: V850-Regs, Prev: V850-Chars, Up: V850 Syntax
-
-9.41.2.2 Register Names
-.......................
-
-`as' supports the following names for registers:
-`general register 0'
- r0, zero
-
-`general register 1'
- r1
-
-`general register 2'
- r2, hp
-
-`general register 3'
- r3, sp
-
-`general register 4'
- r4, gp
-
-`general register 5'
- r5, tp
-
-`general register 6'
- r6
-
-`general register 7'
- r7
-
-`general register 8'
- r8
-
-`general register 9'
- r9
-
-`general register 10'
- r10
-
-`general register 11'
- r11
-
-`general register 12'
- r12
-
-`general register 13'
- r13
-
-`general register 14'
- r14
-
-`general register 15'
- r15
-
-`general register 16'
- r16
-
-`general register 17'
- r17
-
-`general register 18'
- r18
-
-`general register 19'
- r19
-
-`general register 20'
- r20
-
-`general register 21'
- r21
-
-`general register 22'
- r22
-
-`general register 23'
- r23
-
-`general register 24'
- r24
-
-`general register 25'
- r25
-
-`general register 26'
- r26
-
-`general register 27'
- r27
-
-`general register 28'
- r28
-
-`general register 29'
- r29
-
-`general register 30'
- r30, ep
-
-`general register 31'
- r31, lp
-
-`system register 0'
- eipc
-
-`system register 1'
- eipsw
-
-`system register 2'
- fepc
-
-`system register 3'
- fepsw
-
-`system register 4'
- ecr
-
-`system register 5'
- psw
-
-`system register 16'
- ctpc
-
-`system register 17'
- ctpsw
-
-`system register 18'
- dbpc
-
-`system register 19'
- dbpsw
-
-`system register 20'
- ctbp
-
-
-File: as.info, Node: V850 Floating Point, Next: V850 Directives, Prev: V850 Syntax, Up: V850-Dependent
-
-9.41.3 Floating Point
----------------------
-
-The V850 family uses IEEE floating-point numbers.
-
-
-File: as.info, Node: V850 Directives, Next: V850 Opcodes, Prev: V850 Floating Point, Up: V850-Dependent
-
-9.41.4 V850 Machine Directives
-------------------------------
-
-`.offset <EXPRESSION>'
- Moves the offset into the current section to the specified amount.
-
-`.section "name", <type>'
- This is an extension to the standard .section directive. It sets
- the current section to be <type> and creates an alias for this
- section called "name".
-
-`.v850'
- Specifies that the assembled code should be marked as being
- targeted at the V850 processor. This allows the linker to detect
- attempts to link such code with code assembled for other
- processors.
-
-`.v850e'
- Specifies that the assembled code should be marked as being
- targeted at the V850E processor. This allows the linker to detect
- attempts to link such code with code assembled for other
- processors.
-
-`.v850e1'
- Specifies that the assembled code should be marked as being
- targeted at the V850E1 processor. This allows the linker to
- detect attempts to link such code with code assembled for other
- processors.
-
-`.v850e2'
- Specifies that the assembled code should be marked as being
- targeted at the V850E2 processor. This allows the linker to
- detect attempts to link such code with code assembled for other
- processors.
-
-`.v850e2v3'
- Specifies that the assembled code should be marked as being
- targeted at the V850E2V3 processor. This allows the linker to
- detect attempts to link such code with code assembled for other
- processors.
-
-
-
-File: as.info, Node: V850 Opcodes, Prev: V850 Directives, Up: V850-Dependent
-
-9.41.5 Opcodes
---------------
-
-`as' implements all the standard V850 opcodes.
-
- `as' also implements the following pseudo ops:
-
-`hi0()'
- Computes the higher 16 bits of the given expression and stores it
- into the immediate operand field of the given instruction. For
- example:
-
- `mulhi hi0(here - there), r5, r6'
-
- computes the difference between the address of labels 'here' and
- 'there', takes the upper 16 bits of this difference, shifts it
- down 16 bits and then multiplies it by the lower 16 bits in
- register 5, putting the result into register 6.
-
-`lo()'
- Computes the lower 16 bits of the given expression and stores it
- into the immediate operand field of the given instruction. For
- example:
-
- `addi lo(here - there), r5, r6'
-
- computes the difference between the address of labels 'here' and
- 'there', takes the lower 16 bits of this difference and adds it to
- register 5, putting the result into register 6.
-
-`hi()'
- Computes the higher 16 bits of the given expression and then adds
- the value of the most significant bit of the lower 16 bits of the
- expression and stores the result into the immediate operand field
- of the given instruction. For example the following code can be
- used to compute the address of the label 'here' and store it into
- register 6:
-
- `movhi hi(here), r0, r6' `movea lo(here), r6, r6'
-
- The reason for this special behaviour is that movea performs a sign
- extension on its immediate operand. So for example if the address
- of 'here' was 0xFFFFFFFF then without the special behaviour of the
- hi() pseudo-op the movhi instruction would put 0xFFFF0000 into r6,
- then the movea instruction would takes its immediate operand,
- 0xFFFF, sign extend it to 32 bits, 0xFFFFFFFF, and then add it
- into r6 giving 0xFFFEFFFF which is wrong (the fifth nibble is E).
- With the hi() pseudo op adding in the top bit of the lo() pseudo
- op, the movhi instruction actually stores 0 into r6 (0xFFFF + 1 =
- 0x0000), so that the movea instruction stores 0xFFFFFFFF into r6 -
- the right value.
-
-`hilo()'
- Computes the 32 bit value of the given expression and stores it
- into the immediate operand field of the given instruction (which
- must be a mov instruction). For example:
-
- `mov hilo(here), r6'
-
- computes the absolute address of label 'here' and puts the result
- into register 6.
-
-`sdaoff()'
- Computes the offset of the named variable from the start of the
- Small Data Area (whoes address is held in register 4, the GP
- register) and stores the result as a 16 bit signed value in the
- immediate operand field of the given instruction. For example:
-
- `ld.w sdaoff(_a_variable)[gp],r6'
-
- loads the contents of the location pointed to by the label
- '_a_variable' into register 6, provided that the label is located
- somewhere within +/- 32K of the address held in the GP register.
- [Note the linker assumes that the GP register contains a fixed
- address set to the address of the label called '__gp'. This can
- either be set up automatically by the linker, or specifically set
- by using the `--defsym __gp=<value>' command line option].
-
-`tdaoff()'
- Computes the offset of the named variable from the start of the
- Tiny Data Area (whoes address is held in register 30, the EP
- register) and stores the result as a 4,5, 7 or 8 bit unsigned
- value in the immediate operand field of the given instruction.
- For example:
-
- `sld.w tdaoff(_a_variable)[ep],r6'
-
- loads the contents of the location pointed to by the label
- '_a_variable' into register 6, provided that the label is located
- somewhere within +256 bytes of the address held in the EP
- register. [Note the linker assumes that the EP register contains
- a fixed address set to the address of the label called '__ep'.
- This can either be set up automatically by the linker, or
- specifically set by using the `--defsym __ep=<value>' command line
- option].
-
-`zdaoff()'
- Computes the offset of the named variable from address 0 and
- stores the result as a 16 bit signed value in the immediate
- operand field of the given instruction. For example:
-
- `movea zdaoff(_a_variable),zero,r6'
-
- puts the address of the label '_a_variable' into register 6,
- assuming that the label is somewhere within the first 32K of
- memory. (Strictly speaking it also possible to access the last
- 32K of memory as well, as the offsets are signed).
-
-`ctoff()'
- Computes the offset of the named variable from the start of the
- Call Table Area (whoes address is helg in system register 20, the
- CTBP register) and stores the result a 6 or 16 bit unsigned value
- in the immediate field of then given instruction or piece of data.
- For example:
-
- `callt ctoff(table_func1)'
-
- will put the call the function whoes address is held in the call
- table at the location labeled 'table_func1'.
-
-`.longcall `name''
- Indicates that the following sequence of instructions is a long
- call to function `name'. The linker will attempt to shorten this
- call sequence if `name' is within a 22bit offset of the call. Only
- valid if the `-mrelax' command line switch has been enabled.
-
-`.longjump `name''
- Indicates that the following sequence of instructions is a long
- jump to label `name'. The linker will attempt to shorten this code
- sequence if `name' is within a 22bit offset of the jump. Only
- valid if the `-mrelax' command line switch has been enabled.
-
-
- For information on the V850 instruction set, see `V850 Family
-32-/16-Bit single-Chip Microcontroller Architecture Manual' from NEC.
-Ltd.
-
-
-File: as.info, Node: Xtensa-Dependent, Next: Z80-Dependent, Prev: V850-Dependent, Up: Machine Dependencies
-
-9.42 Xtensa Dependent Features
-==============================
-
- This chapter covers features of the GNU assembler that are specific
-to the Xtensa architecture. For details about the Xtensa instruction
-set, please consult the `Xtensa Instruction Set Architecture (ISA)
-Reference Manual'.
-
-* Menu:
-
-* Xtensa Options:: Command-line Options.
-* Xtensa Syntax:: Assembler Syntax for Xtensa Processors.
-* Xtensa Optimizations:: Assembler Optimizations.
-* Xtensa Relaxation:: Other Automatic Transformations.
-* Xtensa Directives:: Directives for Xtensa Processors.
-
-
-File: as.info, Node: Xtensa Options, Next: Xtensa Syntax, Up: Xtensa-Dependent
-
-9.42.1 Command Line Options
----------------------------
-
-The Xtensa version of the GNU assembler supports these special options:
-
-`--text-section-literals | --no-text-section-literals'
- Control the treatment of literal pools. The default is
- `--no-text-section-literals', which places literals in separate
- sections in the output file. This allows the literal pool to be
- placed in a data RAM/ROM. With `--text-section-literals', the
- literals are interspersed in the text section in order to keep
- them as close as possible to their references. This may be
- necessary for large assembly files, where the literals would
- otherwise be out of range of the `L32R' instructions in the text
- section. These options only affect literals referenced via
- PC-relative `L32R' instructions; literals for absolute mode `L32R'
- instructions are handled separately. *Note literal: Literal
- Directive.
-
-`--absolute-literals | --no-absolute-literals'
- Indicate to the assembler whether `L32R' instructions use absolute
- or PC-relative addressing. If the processor includes the absolute
- addressing option, the default is to use absolute `L32R'
- relocations. Otherwise, only the PC-relative `L32R' relocations
- can be used.
-
-`--target-align | --no-target-align'
- Enable or disable automatic alignment to reduce branch penalties
- at some expense in code size. *Note Automatic Instruction
- Alignment: Xtensa Automatic Alignment. This optimization is
- enabled by default. Note that the assembler will always align
- instructions like `LOOP' that have fixed alignment requirements.
-
-`--longcalls | --no-longcalls'
- Enable or disable transformation of call instructions to allow
- calls across a greater range of addresses. *Note Function Call
- Relaxation: Xtensa Call Relaxation. This option should be used
- when call targets can potentially be out of range. It may degrade
- both code size and performance, but the linker can generally
- optimize away the unnecessary overhead when a call ends up within
- range. The default is `--no-longcalls'.
-
-`--transform | --no-transform'
- Enable or disable all assembler transformations of Xtensa
- instructions, including both relaxation and optimization. The
- default is `--transform'; `--no-transform' should only be used in
- the rare cases when the instructions must be exactly as specified
- in the assembly source. Using `--no-transform' causes out of range
- instruction operands to be errors.
-
-`--rename-section OLDNAME=NEWNAME'
- Rename the OLDNAME section to NEWNAME. This option can be used
- multiple times to rename multiple sections.
-
-
-File: as.info, Node: Xtensa Syntax, Next: Xtensa Optimizations, Prev: Xtensa Options, Up: Xtensa-Dependent
-
-9.42.2 Assembler Syntax
------------------------
-
-Block comments are delimited by `/*' and `*/'. End of line comments
-may be introduced with either `#' or `//'.
-
- Instructions consist of a leading opcode or macro name followed by
-whitespace and an optional comma-separated list of operands:
-
- OPCODE [OPERAND, ...]
-
- Instructions must be separated by a newline or semicolon.
-
- FLIX instructions, which bundle multiple opcodes together in a single
-instruction, are specified by enclosing the bundled opcodes inside
-braces:
-
- {
- [FORMAT]
- OPCODE0 [OPERANDS]
- OPCODE1 [OPERANDS]
- OPCODE2 [OPERANDS]
- ...
- }
-
- The opcodes in a FLIX instruction are listed in the same order as the
-corresponding instruction slots in the TIE format declaration.
-Directives and labels are not allowed inside the braces of a FLIX
-instruction. A particular TIE format name can optionally be specified
-immediately after the opening brace, but this is usually unnecessary.
-The assembler will automatically search for a format that can encode the
-specified opcodes, so the format name need only be specified in rare
-cases where there is more than one applicable format and where it
-matters which of those formats is used. A FLIX instruction can also be
-specified on a single line by separating the opcodes with semicolons:
-
- { [FORMAT;] OPCODE0 [OPERANDS]; OPCODE1 [OPERANDS]; OPCODE2 [OPERANDS]; ... }
-
- If an opcode can only be encoded in a FLIX instruction but is not
-specified as part of a FLIX bundle, the assembler will choose the
-smallest format where the opcode can be encoded and will fill unused
-instruction slots with no-ops.
-
-* Menu:
-
-* Xtensa Opcodes:: Opcode Naming Conventions.
-* Xtensa Registers:: Register Naming.
-
-
-File: as.info, Node: Xtensa Opcodes, Next: Xtensa Registers, Up: Xtensa Syntax
-
-9.42.2.1 Opcode Names
-.....................
-
-See the `Xtensa Instruction Set Architecture (ISA) Reference Manual'
-for a complete list of opcodes and descriptions of their semantics.
-
- If an opcode name is prefixed with an underscore character (`_'),
-`as' will not transform that instruction in any way. The underscore
-prefix disables both optimization (*note Xtensa Optimizations: Xtensa
-Optimizations.) and relaxation (*note Xtensa Relaxation: Xtensa
-Relaxation.) for that particular instruction. Only use the underscore
-prefix when it is essential to select the exact opcode produced by the
-assembler. Using this feature unnecessarily makes the code less
-efficient by disabling assembler optimization and less flexible by
-disabling relaxation.
-
- Note that this special handling of underscore prefixes only applies
-to Xtensa opcodes, not to either built-in macros or user-defined macros.
-When an underscore prefix is used with a macro (e.g., `_MOV'), it
-refers to a different macro. The assembler generally provides built-in
-macros both with and without the underscore prefix, where the underscore
-versions behave as if the underscore carries through to the instructions
-in the macros. For example, `_MOV' may expand to `_MOV.N'.
-
- The underscore prefix only applies to individual instructions, not to
-series of instructions. For example, if a series of instructions have
-underscore prefixes, the assembler will not transform the individual
-instructions, but it may insert other instructions between them (e.g.,
-to align a `LOOP' instruction). To prevent the assembler from
-modifying a series of instructions as a whole, use the `no-transform'
-directive. *Note transform: Transform Directive.
-
-
-File: as.info, Node: Xtensa Registers, Prev: Xtensa Opcodes, Up: Xtensa Syntax
-
-9.42.2.2 Register Names
-.......................
-
-The assembly syntax for a register file entry is the "short" name for a
-TIE register file followed by the index into that register file. For
-example, the general-purpose `AR' register file has a short name of
-`a', so these registers are named `a0'...`a15'. As a special feature,
-`sp' is also supported as a synonym for `a1'. Additional registers may
-be added by processor configuration options and by designer-defined TIE
-extensions. An initial `$' character is optional in all register names.
-
-
-File: as.info, Node: Xtensa Optimizations, Next: Xtensa Relaxation, Prev: Xtensa Syntax, Up: Xtensa-Dependent
-
-9.42.3 Xtensa Optimizations
----------------------------
-
-The optimizations currently supported by `as' are generation of density
-instructions where appropriate and automatic branch target alignment.
-
-* Menu:
-
-* Density Instructions:: Using Density Instructions.
-* Xtensa Automatic Alignment:: Automatic Instruction Alignment.
-
-
-File: as.info, Node: Density Instructions, Next: Xtensa Automatic Alignment, Up: Xtensa Optimizations
-
-9.42.3.1 Using Density Instructions
-...................................
-
-The Xtensa instruction set has a code density option that provides
-16-bit versions of some of the most commonly used opcodes. Use of these
-opcodes can significantly reduce code size. When possible, the
-assembler automatically translates instructions from the core Xtensa
-instruction set into equivalent instructions from the Xtensa code
-density option. This translation can be disabled by using underscore
-prefixes (*note Opcode Names: Xtensa Opcodes.), by using the
-`--no-transform' command-line option (*note Command Line Options:
-Xtensa Options.), or by using the `no-transform' directive (*note
-transform: Transform Directive.).
-
- It is a good idea _not_ to use the density instructions directly.
-The assembler will automatically select dense instructions where
-possible. If you later need to use an Xtensa processor without the code
-density option, the same assembly code will then work without
-modification.
-
-
-File: as.info, Node: Xtensa Automatic Alignment, Prev: Density Instructions, Up: Xtensa Optimizations
-
-9.42.3.2 Automatic Instruction Alignment
-........................................
-
-The Xtensa assembler will automatically align certain instructions, both
-to optimize performance and to satisfy architectural requirements.
-
- As an optimization to improve performance, the assembler attempts to
-align branch targets so they do not cross instruction fetch boundaries.
-(Xtensa processors can be configured with either 32-bit or 64-bit
-instruction fetch widths.) An instruction immediately following a call
-is treated as a branch target in this context, because it will be the
-target of a return from the call. This alignment has the potential to
-reduce branch penalties at some expense in code size. This
-optimization is enabled by default. You can disable it with the
-`--no-target-align' command-line option (*note Command Line Options:
-Xtensa Options.).
-
- The target alignment optimization is done without adding instructions
-that could increase the execution time of the program. If there are
-density instructions in the code preceding a target, the assembler can
-change the target alignment by widening some of those instructions to
-the equivalent 24-bit instructions. Extra bytes of padding can be
-inserted immediately following unconditional jump and return
-instructions. This approach is usually successful in aligning many,
-but not all, branch targets.
-
- The `LOOP' family of instructions must be aligned such that the
-first instruction in the loop body does not cross an instruction fetch
-boundary (e.g., with a 32-bit fetch width, a `LOOP' instruction must be
-on either a 1 or 2 mod 4 byte boundary). The assembler knows about
-this restriction and inserts the minimal number of 2 or 3 byte no-op
-instructions to satisfy it. When no-op instructions are added, any
-label immediately preceding the original loop will be moved in order to
-refer to the loop instruction, not the newly generated no-op
-instruction. To preserve binary compatibility across processors with
-different fetch widths, the assembler conservatively assumes a 32-bit
-fetch width when aligning `LOOP' instructions (except if the first
-instruction in the loop is a 64-bit instruction).
-
- Previous versions of the assembler automatically aligned `ENTRY'
-instructions to 4-byte boundaries, but that alignment is now the
-programmer's responsibility.
-
-
-File: as.info, Node: Xtensa Relaxation, Next: Xtensa Directives, Prev: Xtensa Optimizations, Up: Xtensa-Dependent
-
-9.42.4 Xtensa Relaxation
-------------------------
-
-When an instruction operand is outside the range allowed for that
-particular instruction field, `as' can transform the code to use a
-functionally-equivalent instruction or sequence of instructions. This
-process is known as "relaxation". This is typically done for branch
-instructions because the distance of the branch targets is not known
-until assembly-time. The Xtensa assembler offers branch relaxation and
-also extends this concept to function calls, `MOVI' instructions and
-other instructions with immediate fields.
-
-* Menu:
-
-* Xtensa Branch Relaxation:: Relaxation of Branches.
-* Xtensa Call Relaxation:: Relaxation of Function Calls.
-* Xtensa Immediate Relaxation:: Relaxation of other Immediate Fields.
-
-
-File: as.info, Node: Xtensa Branch Relaxation, Next: Xtensa Call Relaxation, Up: Xtensa Relaxation
-
-9.42.4.1 Conditional Branch Relaxation
-......................................
-
-When the target of a branch is too far away from the branch itself,
-i.e., when the offset from the branch to the target is too large to fit
-in the immediate field of the branch instruction, it may be necessary to
-replace the branch with a branch around a jump. For example,
-
- beqz a2, L
-
- may result in:
-
- bnez.n a2, M
- j L
- M:
-
- (The `BNEZ.N' instruction would be used in this example only if the
-density option is available. Otherwise, `BNEZ' would be used.)
-
- This relaxation works well because the unconditional jump instruction
-has a much larger offset range than the various conditional branches.
-However, an error will occur if a branch target is beyond the range of a
-jump instruction. `as' cannot relax unconditional jumps. Similarly,
-an error will occur if the original input contains an unconditional
-jump to a target that is out of range.
-
- Branch relaxation is enabled by default. It can be disabled by using
-underscore prefixes (*note Opcode Names: Xtensa Opcodes.), the
-`--no-transform' command-line option (*note Command Line Options:
-Xtensa Options.), or the `no-transform' directive (*note transform:
-Transform Directive.).
-
-
-File: as.info, Node: Xtensa Call Relaxation, Next: Xtensa Immediate Relaxation, Prev: Xtensa Branch Relaxation, Up: Xtensa Relaxation
-
-9.42.4.2 Function Call Relaxation
-.................................
-
-Function calls may require relaxation because the Xtensa immediate call
-instructions (`CALL0', `CALL4', `CALL8' and `CALL12') provide a
-PC-relative offset of only 512 Kbytes in either direction. For larger
-programs, it may be necessary to use indirect calls (`CALLX0',
-`CALLX4', `CALLX8' and `CALLX12') where the target address is specified
-in a register. The Xtensa assembler can automatically relax immediate
-call instructions into indirect call instructions. This relaxation is
-done by loading the address of the called function into the callee's
-return address register and then using a `CALLX' instruction. So, for
-example:
-
- call8 func
-
- might be relaxed to:
-
- .literal .L1, func
- l32r a8, .L1
- callx8 a8
-
- Because the addresses of targets of function calls are not generally
-known until link-time, the assembler must assume the worst and relax all
-the calls to functions in other source files, not just those that really
-will be out of range. The linker can recognize calls that were
-unnecessarily relaxed, and it will remove the overhead introduced by the
-assembler for those cases where direct calls are sufficient.
-
- Call relaxation is disabled by default because it can have a negative
-effect on both code size and performance, although the linker can
-usually eliminate the unnecessary overhead. If a program is too large
-and some of the calls are out of range, function call relaxation can be
-enabled using the `--longcalls' command-line option or the `longcalls'
-directive (*note longcalls: Longcalls Directive.).
-
-
-File: as.info, Node: Xtensa Immediate Relaxation, Prev: Xtensa Call Relaxation, Up: Xtensa Relaxation
-
-9.42.4.3 Other Immediate Field Relaxation
-.........................................
-
-The assembler normally performs the following other relaxations. They
-can be disabled by using underscore prefixes (*note Opcode Names:
-Xtensa Opcodes.), the `--no-transform' command-line option (*note
-Command Line Options: Xtensa Options.), or the `no-transform' directive
-(*note transform: Transform Directive.).
-
- The `MOVI' machine instruction can only materialize values in the
-range from -2048 to 2047. Values outside this range are best
-materialized with `L32R' instructions. Thus:
-
- movi a0, 100000
-
- is assembled into the following machine code:
-
- .literal .L1, 100000
- l32r a0, .L1
-
- The `L8UI' machine instruction can only be used with immediate
-offsets in the range from 0 to 255. The `L16SI' and `L16UI' machine
-instructions can only be used with offsets from 0 to 510. The `L32I'
-machine instruction can only be used with offsets from 0 to 1020. A
-load offset outside these ranges can be materialized with an `L32R'
-instruction if the destination register of the load is different than
-the source address register. For example:
-
- l32i a1, a0, 2040
-
- is translated to:
-
- .literal .L1, 2040
- l32r a1, .L1
- add a1, a0, a1
- l32i a1, a1, 0
-
-If the load destination and source address register are the same, an
-out-of-range offset causes an error.
-
- The Xtensa `ADDI' instruction only allows immediate operands in the
-range from -128 to 127. There are a number of alternate instruction
-sequences for the `ADDI' operation. First, if the immediate is 0, the
-`ADDI' will be turned into a `MOV.N' instruction (or the equivalent
-`OR' instruction if the code density option is not available). If the
-`ADDI' immediate is outside of the range -128 to 127, but inside the
-range -32896 to 32639, an `ADDMI' instruction or `ADDMI'/`ADDI'
-sequence will be used. Finally, if the immediate is outside of this
-range and a free register is available, an `L32R'/`ADD' sequence will
-be used with a literal allocated from the literal pool.
-
- For example:
-
- addi a5, a6, 0
- addi a5, a6, 512
- addi a5, a6, 513
- addi a5, a6, 50000
-
- is assembled into the following:
-
- .literal .L1, 50000
- mov.n a5, a6
- addmi a5, a6, 0x200
- addmi a5, a6, 0x200
- addi a5, a5, 1
- l32r a5, .L1
- add a5, a6, a5
-
-
-File: as.info, Node: Xtensa Directives, Prev: Xtensa Relaxation, Up: Xtensa-Dependent
-
-9.42.5 Directives
------------------
-
-The Xtensa assembler supports a region-based directive syntax:
-
- .begin DIRECTIVE [OPTIONS]
- ...
- .end DIRECTIVE
-
- All the Xtensa-specific directives that apply to a region of code use
-this syntax.
-
- The directive applies to code between the `.begin' and the `.end'.
-The state of the option after the `.end' reverts to what it was before
-the `.begin'. A nested `.begin'/`.end' region can further change the
-state of the directive without having to be aware of its outer state.
-For example, consider:
-
- .begin no-transform
- L: add a0, a1, a2
- .begin transform
- M: add a0, a1, a2
- .end transform
- N: add a0, a1, a2
- .end no-transform
-
- The `ADD' opcodes at `L' and `N' in the outer `no-transform' region
-both result in `ADD' machine instructions, but the assembler selects an
-`ADD.N' instruction for the `ADD' at `M' in the inner `transform'
-region.
-
- The advantage of this style is that it works well inside macros
-which can preserve the context of their callers.
-
- The following directives are available:
-
-* Menu:
-
-* Schedule Directive:: Enable instruction scheduling.
-* Longcalls Directive:: Use Indirect Calls for Greater Range.
-* Transform Directive:: Disable All Assembler Transformations.
-* Literal Directive:: Intermix Literals with Instructions.
-* Literal Position Directive:: Specify Inline Literal Pool Locations.
-* Literal Prefix Directive:: Specify Literal Section Name Prefix.
-* Absolute Literals Directive:: Control PC-Relative vs. Absolute Literals.
-
-
-File: as.info, Node: Schedule Directive, Next: Longcalls Directive, Up: Xtensa Directives
-
-9.42.5.1 schedule
-.................
-
-The `schedule' directive is recognized only for compatibility with
-Tensilica's assembler.
-
- .begin [no-]schedule
- .end [no-]schedule
-
- This directive is ignored and has no effect on `as'.
-
-
-File: as.info, Node: Longcalls Directive, Next: Transform Directive, Prev: Schedule Directive, Up: Xtensa Directives
-
-9.42.5.2 longcalls
-..................
-
-The `longcalls' directive enables or disables function call relaxation.
-*Note Function Call Relaxation: Xtensa Call Relaxation.
-
- .begin [no-]longcalls
- .end [no-]longcalls
-
- Call relaxation is disabled by default unless the `--longcalls'
-command-line option is specified. The `longcalls' directive overrides
-the default determined by the command-line options.
-
-
-File: as.info, Node: Transform Directive, Next: Literal Directive, Prev: Longcalls Directive, Up: Xtensa Directives
-
-9.42.5.3 transform
-..................
-
-This directive enables or disables all assembler transformation,
-including relaxation (*note Xtensa Relaxation: Xtensa Relaxation.) and
-optimization (*note Xtensa Optimizations: Xtensa Optimizations.).
-
- .begin [no-]transform
- .end [no-]transform
-
- Transformations are enabled by default unless the `--no-transform'
-option is used. The `transform' directive overrides the default
-determined by the command-line options. An underscore opcode prefix,
-disabling transformation of that opcode, always takes precedence over
-both directives and command-line flags.
-
-
-File: as.info, Node: Literal Directive, Next: Literal Position Directive, Prev: Transform Directive, Up: Xtensa Directives
-
-9.42.5.4 literal
-................
-
-The `.literal' directive is used to define literal pool data, i.e.,
-read-only 32-bit data accessed via `L32R' instructions.
-
- .literal LABEL, VALUE[, VALUE...]
-
- This directive is similar to the standard `.word' directive, except
-that the actual location of the literal data is determined by the
-assembler and linker, not by the position of the `.literal' directive.
-Using this directive gives the assembler freedom to locate the literal
-data in the most appropriate place and possibly to combine identical
-literals. For example, the code:
-
- entry sp, 40
- .literal .L1, sym
- l32r a4, .L1
-
- can be used to load a pointer to the symbol `sym' into register
-`a4'. The value of `sym' will not be placed between the `ENTRY' and
-`L32R' instructions; instead, the assembler puts the data in a literal
-pool.
-
- Literal pools are placed by default in separate literal sections;
-however, when using the `--text-section-literals' option (*note Command
-Line Options: Xtensa Options.), the literal pools for PC-relative mode
-`L32R' instructions are placed in the current section.(1) These text
-section literal pools are created automatically before `ENTRY'
-instructions and manually after `.literal_position' directives (*note
-literal_position: Literal Position Directive.). If there are no
-preceding `ENTRY' instructions, explicit `.literal_position' directives
-must be used to place the text section literal pools; otherwise, `as'
-will report an error.
-
- When literals are placed in separate sections, the literal section
-names are derived from the names of the sections where the literals are
-defined. The base literal section names are `.literal' for PC-relative
-mode `L32R' instructions and `.lit4' for absolute mode `L32R'
-instructions (*note absolute-literals: Absolute Literals Directive.).
-These base names are used for literals defined in the default `.text'
-section. For literals defined in other sections or within the scope of
-a `literal_prefix' directive (*note literal_prefix: Literal Prefix
-Directive.), the following rules determine the literal section name:
-
- 1. If the current section is a member of a section group, the literal
- section name includes the group name as a suffix to the base
- `.literal' or `.lit4' name, with a period to separate the base
- name and group name. The literal section is also made a member of
- the group.
-
- 2. If the current section name (or `literal_prefix' value) begins with
- "`.gnu.linkonce.KIND.'", the literal section name is formed by
- replacing "`.KIND'" with the base `.literal' or `.lit4' name. For
- example, for literals defined in a section named
- `.gnu.linkonce.t.func', the literal section will be
- `.gnu.linkonce.literal.func' or `.gnu.linkonce.lit4.func'.
-
- 3. If the current section name (or `literal_prefix' value) ends with
- `.text', the literal section name is formed by replacing that
- suffix with the base `.literal' or `.lit4' name. For example, for
- literals defined in a section named `.iram0.text', the literal
- section will be `.iram0.literal' or `.iram0.lit4'.
-
- 4. If none of the preceding conditions apply, the literal section
- name is formed by adding the base `.literal' or `.lit4' name as a
- suffix to the current section name (or `literal_prefix' value).
-
- ---------- Footnotes ----------
-
- (1) Literals for the `.init' and `.fini' sections are always placed
-in separate sections, even when `--text-section-literals' is enabled.
-
-
-File: as.info, Node: Literal Position Directive, Next: Literal Prefix Directive, Prev: Literal Directive, Up: Xtensa Directives
-
-9.42.5.5 literal_position
-.........................
-
-When using `--text-section-literals' to place literals inline in the
-section being assembled, the `.literal_position' directive can be used
-to mark a potential location for a literal pool.
-
- .literal_position
-
- The `.literal_position' directive is ignored when the
-`--text-section-literals' option is not used or when `L32R'
-instructions use the absolute addressing mode.
-
- The assembler will automatically place text section literal pools
-before `ENTRY' instructions, so the `.literal_position' directive is
-only needed to specify some other location for a literal pool. You may
-need to add an explicit jump instruction to skip over an inline literal
-pool.
-
- For example, an interrupt vector does not begin with an `ENTRY'
-instruction so the assembler will be unable to automatically find a good
-place to put a literal pool. Moreover, the code for the interrupt
-vector must be at a specific starting address, so the literal pool
-cannot come before the start of the code. The literal pool for the
-vector must be explicitly positioned in the middle of the vector (before
-any uses of the literals, due to the negative offsets used by
-PC-relative `L32R' instructions). The `.literal_position' directive
-can be used to do this. In the following code, the literal for `M'
-will automatically be aligned correctly and is placed after the
-unconditional jump.
-
- .global M
- code_start:
- j continue
- .literal_position
- .align 4
- continue:
- movi a4, M
-
-
-File: as.info, Node: Literal Prefix Directive, Next: Absolute Literals Directive, Prev: Literal Position Directive, Up: Xtensa Directives
-
-9.42.5.6 literal_prefix
-.......................
-
-The `literal_prefix' directive allows you to override the default
-literal section names, which are derived from the names of the sections
-where the literals are defined.
-
- .begin literal_prefix [NAME]
- .end literal_prefix
-
- For literals defined within the delimited region, the literal section
-names are derived from the NAME argument instead of the name of the
-current section. The rules used to derive the literal section names do
-not change. *Note literal: Literal Directive. If the NAME argument is
-omitted, the literal sections revert to the defaults. This directive
-has no effect when using the `--text-section-literals' option (*note
-Command Line Options: Xtensa Options.).
-
-
-File: as.info, Node: Absolute Literals Directive, Prev: Literal Prefix Directive, Up: Xtensa Directives
-
-9.42.5.7 absolute-literals
-..........................
-
-The `absolute-literals' and `no-absolute-literals' directives control
-the absolute vs. PC-relative mode for `L32R' instructions. These are
-relevant only for Xtensa configurations that include the absolute
-addressing option for `L32R' instructions.
-
- .begin [no-]absolute-literals
- .end [no-]absolute-literals
-
- These directives do not change the `L32R' mode--they only cause the
-assembler to emit the appropriate kind of relocation for `L32R'
-instructions and to place the literal values in the appropriate section.
-To change the `L32R' mode, the program must write the `LITBASE' special
-register. It is the programmer's responsibility to keep track of the
-mode and indicate to the assembler which mode is used in each region of
-code.
-
- If the Xtensa configuration includes the absolute `L32R' addressing
-option, the default is to assume absolute `L32R' addressing unless the
-`--no-absolute-literals' command-line option is specified. Otherwise,
-the default is to assume PC-relative `L32R' addressing. The
-`absolute-literals' directive can then be used to override the default
-determined by the command-line options.
-
-
-File: as.info, Node: Reporting Bugs, Next: Acknowledgements, Prev: Machine Dependencies, Up: Top
-
-10 Reporting Bugs
-*****************
-
-Your bug reports play an essential role in making `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 `as' work
-better. Bug reports are your contribution to the maintenance of `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
-
-
-File: as.info, Node: Bug Criteria, Next: Bug Reporting, Up: Reporting Bugs
-
-10.1 Have You Found a Bug?
-==========================
-
-If you are not sure whether you have found a bug, here are some
-guidelines:
-
- * If the assembler gets a fatal signal, for any input whatever, that
- is a `as' bug. Reliable assemblers never crash.
-
- * If `as' produces an error message for valid input, that is a bug.
-
- * If `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".
-
- * If you are an experienced user of assemblers, your suggestions for
- improvement of `as' are welcome in any case.
-
-
-File: as.info, Node: Bug Reporting, Prev: Bug Criteria, Up: Reporting Bugs
-
-10.2 How to Report Bugs
-=======================
-
-A number of companies and individuals offer support for GNU products.
-If you obtained `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 `etc/SERVICE' in the GNU Emacs distribution.
-
- In any event, we also recommend that you send bug reports for `as'
-to `http://www.sourceware.org/bugzilla/'.
-
- The fundamental principle of reporting bugs usefully is this:
-*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?" This cannot help us fix a bug, so it is basically useless. We
-respond by asking for enough details to enable us to investigate. You
-might as well expedite matters by sending them to begin with.
-
- To enable us to fix the bug, you should include all these things:
-
- * The version of `as'. `as' announces it if you start it with the
- `--version' argument.
-
- Without this, we will not know whether there is any point in
- looking for the bug in the current version of `as'.
-
- * Any patches you may have applied to the `as' source.
-
- * The type of machine you are using, and the operating system name
- and version number.
-
- * What compiler (and its version) was used to compile `as'--e.g.
- "`gcc-2.7'".
-
- * 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.
-
- * 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 `-S'
- option. If you are using `gcc', use the options `-v
- --save-temps'; this will save the assembler source in a file with
- an extension of `.s', and also show you exactly how `as' is being
- run.
-
- * 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 `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 `as' is out of sync, 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.
-
- * If you wish to suggest changes to the `as' source, send us context
- diffs, as generated by `diff' with the `-u', `-c', or `-p' option.
- Always send diffs from the old file to the new file. If you even
- discuss something in the `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.
-
- Here are some things that are not necessary:
-
- * 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 _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.
-
- * 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 `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.
-
- * 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.
-
-
-File: as.info, Node: Acknowledgements, Next: GNU Free Documentation License, Prev: Reporting Bugs, Up: Top
-
-11 Acknowledgements
-*******************
-
-If you have contributed to GAS and your name isn't listed here, it is
-not meant as a slight. We just don't know about it. Send mail to the
-maintainer, and we'll correct the situation. Currently the maintainer
-is Ken Raeburn (email address `raeburn@cygnus.com').
-
- Dean Elsner wrote the original GNU assembler for the VAX.(1)
-
- Jay Fenlason maintained GAS for a while, adding support for
-GDB-specific debug information and the 68k series machines, most of the
-preprocessing pass, and extensive changes in `messages.c',
-`input-file.c', `write.c'.
-
- K. Richard Pixley maintained GAS for a while, adding various
-enhancements and many bug fixes, including merging support for several
-processors, breaking GAS up to handle multiple object file format back
-ends (including heavy rewrite, testing, an integration of the coff and
-b.out back ends), adding configuration including heavy testing and
-verification of cross assemblers and file splits and renaming,
-converted GAS to strictly ANSI C including full prototypes, added
-support for m680[34]0 and cpu32, did considerable work on i960
-including a COFF port (including considerable amounts of reverse
-engineering), a SPARC opcode file rewrite, DECstation, rs6000, and
-hp300hpux host ports, updated "know" assertions and made them work,
-much other reorganization, cleanup, and lint.
-
- Ken Raeburn wrote the high-level BFD interface code to replace most
-of the code in format-specific I/O modules.
-
- The original VMS support was contributed by David L. Kashtan. Eric
-Youngdale has done much work with it since.
-
- The Intel 80386 machine description was written by Eliot Dresselhaus.
-
- Minh Tran-Le at IntelliCorp contributed some AIX 386 support.
-
- The Motorola 88k machine description was contributed by Devon Bowen
-of Buffalo University and Torbjorn Granlund of the Swedish Institute of
-Computer Science.
-
- Keith Knowles at the Open Software Foundation wrote the original
-MIPS back end (`tc-mips.c', `tc-mips.h'), and contributed Rose format
-support (which hasn't been merged in yet). Ralph Campbell worked with
-the MIPS code to support a.out format.
-
- Support for the Zilog Z8k and Renesas H8/300 processors (tc-z8k,
-tc-h8300), and IEEE 695 object file format (obj-ieee), was written by
-Steve Chamberlain of Cygnus Support. Steve also modified the COFF back
-end to use BFD for some low-level operations, for use with the H8/300
-and AMD 29k targets.
-
- John Gilmore built the AMD 29000 support, added `.include' support,
-and simplified the configuration of which versions accept which
-directives. He updated the 68k machine description so that Motorola's
-opcodes always produced fixed-size instructions (e.g., `jsr'), while
-synthetic instructions remained shrinkable (`jbsr'). John fixed many
-bugs, including true tested cross-compilation support, and one bug in
-relaxation that took a week and required the proverbial one-bit fix.
-
- 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,
-wrote the initial RS/6000 and PowerPC assembler, and made a few other
-minor patches.
-
- Steve Chamberlain made GAS able to generate listings.
-
- Hewlett-Packard contributed support for the HP9000/300.
-
- Jeff Law wrote GAS and BFD support for the native HPPA object format
-(SOM) along with a fairly extensive HPPA testsuite (for both SOM and
-ELF object formats). This work was supported by both the Center for
-Software Science at the University of Utah and Cygnus Support.
-
- Support for ELF format files has been worked on by Mark Eichin of
-Cygnus Support (original, incomplete implementation for SPARC), Pete
-Hoogenboom and Jeff Law at the University of Utah (HPPA mainly),
-Michael Meissner of the Open Software Foundation (i386 mainly), and Ken
-Raeburn of Cygnus Support (sparc, and some initial 64-bit support).
-
- Linas Vepstas added GAS support for the ESA/390 "IBM 370"
-architecture.
-
- Richard Henderson rewrote the Alpha assembler. Klaus Kaempf wrote
-GAS and BFD support for openVMS/Alpha.
-
- Timothy Wall, Michael Hayes, and Greg Smart contributed to the
-various tic* flavors.
-
- David Heine, Sterling Augustine, Bob Wilson and John Ruttenberg from
-Tensilica, Inc. added support for Xtensa processors.
-
- Several engineers at Cygnus Support have also provided many small
-bug fixes and configuration enhancements.
-
- Jon Beniston added support for the Lattice Mico32 architecture.
-
- Many others have contributed large or small bugfixes and
-enhancements. If you have contributed significant work and are not
-mentioned on this list, and want to be, let us know. Some of the
-history has been lost; we are not intentionally leaving anyone out.
-
- ---------- Footnotes ----------
-
- (1) Any more details?
-
-
-File: as.info, Node: GNU Free Documentation License, Next: AS Index, Prev: Acknowledgements, Up: Top
-
-Appendix A GNU Free Documentation License
-*****************************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: as.info, Node: AS Index, Prev: GNU Free Documentation License, Up: Top
-
-AS Index
-********
-
-
-* Menu:
-
-* #: Comments. (line 39)
-* #APP: Preprocessing. (line 26)
-* #NO_APP: Preprocessing. (line 26)
-* $ in symbol names <1>: D10V-Chars. (line 46)
-* $ in symbol names <2>: SH64-Chars. (line 10)
-* $ in symbol names <3>: D30V-Chars. (line 63)
-* $ in symbol names: SH-Chars. (line 10)
-* $a: ARM Mapping Symbols. (line 9)
-* $acos math builtin, TIC54X: TIC54X-Builtins. (line 10)
-* $asin math builtin, TIC54X: TIC54X-Builtins. (line 13)
-* $atan math builtin, TIC54X: TIC54X-Builtins. (line 16)
-* $atan2 math builtin, TIC54X: TIC54X-Builtins. (line 19)
-* $ceil math builtin, TIC54X: TIC54X-Builtins. (line 22)
-* $cos math builtin, TIC54X: TIC54X-Builtins. (line 28)
-* $cosh math builtin, TIC54X: TIC54X-Builtins. (line 25)
-* $cvf math builtin, TIC54X: TIC54X-Builtins. (line 31)
-* $cvi math builtin, TIC54X: TIC54X-Builtins. (line 34)
-* $d: ARM Mapping Symbols. (line 15)
-* $exp math builtin, TIC54X: TIC54X-Builtins. (line 37)
-* $fabs math builtin, TIC54X: TIC54X-Builtins. (line 40)
-* $firstch subsym builtin, TIC54X: TIC54X-Macros. (line 26)
-* $floor math builtin, TIC54X: TIC54X-Builtins. (line 43)
-* $fmod math builtin, TIC54X: TIC54X-Builtins. (line 47)
-* $int math builtin, TIC54X: TIC54X-Builtins. (line 50)
-* $iscons subsym builtin, TIC54X: TIC54X-Macros. (line 43)
-* $isdefed subsym builtin, TIC54X: TIC54X-Macros. (line 34)
-* $ismember subsym builtin, TIC54X: TIC54X-Macros. (line 38)
-* $isname subsym builtin, TIC54X: TIC54X-Macros. (line 47)
-* $isreg subsym builtin, TIC54X: TIC54X-Macros. (line 50)
-* $lastch subsym builtin, TIC54X: TIC54X-Macros. (line 30)
-* $ldexp math builtin, TIC54X: TIC54X-Builtins. (line 53)
-* $log math builtin, TIC54X: TIC54X-Builtins. (line 59)
-* $log10 math builtin, TIC54X: TIC54X-Builtins. (line 56)
-* $max math builtin, TIC54X: TIC54X-Builtins. (line 62)
-* $min math builtin, TIC54X: TIC54X-Builtins. (line 65)
-* $pow math builtin, TIC54X: TIC54X-Builtins. (line 68)
-* $round math builtin, TIC54X: TIC54X-Builtins. (line 71)
-* $sgn math builtin, TIC54X: TIC54X-Builtins. (line 74)
-* $sin math builtin, TIC54X: TIC54X-Builtins. (line 77)
-* $sinh math builtin, TIC54X: TIC54X-Builtins. (line 80)
-* $sqrt math builtin, TIC54X: TIC54X-Builtins. (line 83)
-* $structacc subsym builtin, TIC54X: TIC54X-Macros. (line 57)
-* $structsz subsym builtin, TIC54X: TIC54X-Macros. (line 54)
-* $symcmp subsym builtin, TIC54X: TIC54X-Macros. (line 23)
-* $symlen subsym builtin, TIC54X: TIC54X-Macros. (line 20)
-* $t: ARM Mapping Symbols. (line 12)
-* $tan math builtin, TIC54X: TIC54X-Builtins. (line 86)
-* $tanh math builtin, TIC54X: TIC54X-Builtins. (line 89)
-* $trunc math builtin, TIC54X: TIC54X-Builtins. (line 92)
-* -+ option, VAX/VMS: VAX-Opts. (line 71)
-* --: Command Line. (line 10)
-* --32 option, i386: i386-Options. (line 8)
-* --32 option, x86-64: i386-Options. (line 8)
-* --64 option, i386: i386-Options. (line 8)
-* --64 option, x86-64: i386-Options. (line 8)
-* --absolute-literals: Xtensa Options. (line 23)
-* --allow-reg-prefix: SH Options. (line 9)
-* --alternate: alternate. (line 6)
-* --base-size-default-16: M68K-Opts. (line 65)
-* --base-size-default-32: M68K-Opts. (line 65)
-* --big: SH Options. (line 9)
-* --bitwise-or option, M680x0: M68K-Opts. (line 58)
-* --disp-size-default-16: M68K-Opts. (line 74)
-* --disp-size-default-32: M68K-Opts. (line 74)
-* --divide option, i386: i386-Options. (line 24)
-* --dsp: SH Options. (line 9)
-* --emulation=crisaout command line option, CRIS: CRIS-Opts. (line 9)
-* --emulation=criself command line option, CRIS: CRIS-Opts. (line 9)
-* --enforce-aligned-data: Sparc-Aligned-Data. (line 11)
-* --fatal-warnings: W. (line 16)
-* --fdpic: SH Options. (line 31)
-* --fix-v4bx command line option, ARM: ARM Options. (line 165)
-* --fixed-special-register-names command line option, MMIX: MMIX-Opts.
- (line 8)
-* --force-long-branches: M68HC11-Opts. (line 69)
-* --generate-example: M68HC11-Opts. (line 86)
-* --globalize-symbols command line option, MMIX: MMIX-Opts. (line 12)
-* --gnu-syntax command line option, MMIX: MMIX-Opts. (line 16)
-* --hash-size=NUMBER: Overview. (line 354)
-* --linker-allocated-gregs command line option, MMIX: MMIX-Opts.
- (line 67)
-* --listing-cont-lines: listing. (line 34)
-* --listing-lhs-width: listing. (line 16)
-* --listing-lhs-width2: listing. (line 21)
-* --listing-rhs-width: listing. (line 28)
-* --little: SH Options. (line 9)
-* --longcalls: Xtensa Options. (line 37)
-* --march=ARCHITECTURE command line option, CRIS: CRIS-Opts. (line 33)
-* --MD: MD. (line 6)
-* --mul-bug-abort command line option, CRIS: CRIS-Opts. (line 61)
-* --no-absolute-literals: Xtensa Options. (line 23)
-* --no-expand command line option, MMIX: MMIX-Opts. (line 31)
-* --no-longcalls: Xtensa Options. (line 37)
-* --no-merge-gregs command line option, MMIX: MMIX-Opts. (line 36)
-* --no-mul-bug-abort command line option, CRIS: CRIS-Opts. (line 61)
-* --no-predefined-syms command line option, MMIX: MMIX-Opts. (line 22)
-* --no-pushj-stubs command line option, MMIX: MMIX-Opts. (line 54)
-* --no-stubs command line option, MMIX: MMIX-Opts. (line 54)
-* --no-target-align: Xtensa Options. (line 30)
-* --no-text-section-literals: Xtensa Options. (line 9)
-* --no-transform: Xtensa Options. (line 46)
-* --no-underscore command line option, CRIS: CRIS-Opts. (line 15)
-* --no-warn: W. (line 11)
-* --pcrel: M68K-Opts. (line 86)
-* --pic command line option, CRIS: CRIS-Opts. (line 27)
-* --print-insn-syntax: M68HC11-Opts. (line 75)
-* --print-opcodes: M68HC11-Opts. (line 79)
-* --register-prefix-optional option, M680x0: M68K-Opts. (line 45)
-* --relax: SH Options. (line 9)
-* --relax command line option, MMIX: MMIX-Opts. (line 19)
-* --rename-section: Xtensa Options. (line 54)
-* --renesas: SH Options. (line 9)
-* --short-branches: M68HC11-Opts. (line 54)
-* --small: SH Options. (line 9)
-* --statistics: statistics. (line 6)
-* --strict-direct-mode: M68HC11-Opts. (line 44)
-* --target-align: Xtensa Options. (line 30)
-* --text-section-literals: Xtensa Options. (line 9)
-* --traditional-format: traditional-format. (line 6)
-* --transform: Xtensa Options. (line 46)
-* --underscore command line option, CRIS: CRIS-Opts. (line 15)
-* --warn: W. (line 19)
-* -1 option, VAX/VMS: VAX-Opts. (line 77)
-* -32addr command line option, Alpha: Alpha Options. (line 57)
-* -a: a. (line 6)
-* -A options, i960: Options-i960. (line 6)
-* -ac: a. (line 6)
-* -ad: a. (line 6)
-* -ag: a. (line 6)
-* -ah: a. (line 6)
-* -al: a. (line 6)
-* -an: a. (line 6)
-* -as: a. (line 6)
-* -Asparclet: Sparc-Opts. (line 25)
-* -Asparclite: Sparc-Opts. (line 25)
-* -Av6: Sparc-Opts. (line 25)
-* -Av8: Sparc-Opts. (line 25)
-* -Av9: Sparc-Opts. (line 25)
-* -Av9a: Sparc-Opts. (line 25)
-* -b option, i960: Options-i960. (line 22)
-* -big option, M32R: M32R-Opts. (line 35)
-* -D: D. (line 6)
-* -D, ignored on VAX: VAX-Opts. (line 11)
-* -d, VAX option: VAX-Opts. (line 16)
-* -eabi= command line option, ARM: ARM Options. (line 148)
-* -EB command line option, ARC: ARC Options. (line 31)
-* -EB command line option, ARM: ARM Options. (line 153)
-* -EB option (MIPS): MIPS Opts. (line 13)
-* -EB option, M32R: M32R-Opts. (line 39)
-* -EL command line option, ARC: ARC Options. (line 35)
-* -EL command line option, ARM: ARM Options. (line 157)
-* -EL option (MIPS): MIPS Opts. (line 13)
-* -EL option, M32R: M32R-Opts. (line 32)
-* -f: f. (line 6)
-* -F command line option, Alpha: Alpha Options. (line 57)
-* -g command line option, Alpha: Alpha Options. (line 47)
-* -G command line option, Alpha: Alpha Options. (line 53)
-* -G option (MIPS): MIPS Opts. (line 8)
-* -h option, VAX/VMS: VAX-Opts. (line 45)
-* -H option, VAX/VMS: VAX-Opts. (line 81)
-* -I PATH: I. (line 6)
-* -ignore-parallel-conflicts option, M32RX: M32R-Opts. (line 87)
-* -Ip option, M32RX: M32R-Opts. (line 97)
-* -J, ignored on VAX: VAX-Opts. (line 27)
-* -K: K. (line 6)
-* -k command line option, ARM: ARM Options. (line 161)
-* -KPIC option, M32R: M32R-Opts. (line 42)
-* -KPIC option, MIPS: MIPS Opts. (line 21)
-* -L: L. (line 6)
-* -l option, M680x0: M68K-Opts. (line 33)
-* -little option, M32R: M32R-Opts. (line 27)
-* -M: M. (line 6)
-* -m11/03: PDP-11-Options. (line 140)
-* -m11/04: PDP-11-Options. (line 143)
-* -m11/05: PDP-11-Options. (line 146)
-* -m11/10: PDP-11-Options. (line 146)
-* -m11/15: PDP-11-Options. (line 149)
-* -m11/20: PDP-11-Options. (line 149)
-* -m11/21: PDP-11-Options. (line 152)
-* -m11/23: PDP-11-Options. (line 155)
-* -m11/24: PDP-11-Options. (line 155)
-* -m11/34: PDP-11-Options. (line 158)
-* -m11/34a: PDP-11-Options. (line 161)
-* -m11/35: PDP-11-Options. (line 164)
-* -m11/40: PDP-11-Options. (line 164)
-* -m11/44: PDP-11-Options. (line 167)
-* -m11/45: PDP-11-Options. (line 170)
-* -m11/50: PDP-11-Options. (line 170)
-* -m11/53: PDP-11-Options. (line 173)
-* -m11/55: PDP-11-Options. (line 170)
-* -m11/60: PDP-11-Options. (line 176)
-* -m11/70: PDP-11-Options. (line 170)
-* -m11/73: PDP-11-Options. (line 173)
-* -m11/83: PDP-11-Options. (line 173)
-* -m11/84: PDP-11-Options. (line 173)
-* -m11/93: PDP-11-Options. (line 173)
-* -m11/94: PDP-11-Options. (line 173)
-* -m16c option, M16C: M32C-Opts. (line 12)
-* -m31 option, s390: s390 Options. (line 8)
-* -m32bit-doubles: RX-Opts. (line 9)
-* -m32c option, M32C: M32C-Opts. (line 9)
-* -m32r option, M32R: M32R-Opts. (line 21)
-* -m32rx option, M32R2: M32R-Opts. (line 17)
-* -m32rx option, M32RX: M32R-Opts. (line 9)
-* -m64 option, s390: s390 Options. (line 8)
-* -m64bit-doubles: RX-Opts. (line 15)
-* -m68000 and related options: M68K-Opts. (line 98)
-* -m68hc11: M68HC11-Opts. (line 9)
-* -m68hc12: M68HC11-Opts. (line 14)
-* -m68hcs12: M68HC11-Opts. (line 21)
-* -m[no-]68851 command line option, M680x0: M68K-Opts. (line 21)
-* -m[no-]68881 command line option, M680x0: M68K-Opts. (line 21)
-* -m[no-]div command line option, M680x0: M68K-Opts. (line 21)
-* -m[no-]emac command line option, M680x0: M68K-Opts. (line 21)
-* -m[no-]float command line option, M680x0: M68K-Opts. (line 21)
-* -m[no-]mac command line option, M680x0: M68K-Opts. (line 21)
-* -m[no-]usp command line option, M680x0: M68K-Opts. (line 21)
-* -mall: PDP-11-Options. (line 26)
-* -mall-enabled command line option, LM32: LM32 Options. (line 30)
-* -mall-extensions: PDP-11-Options. (line 26)
-* -mall-opcodes command line option, AVR: AVR Options. (line 68)
-* -mapcs-26 command line option, ARM: ARM Options. (line 120)
-* -mapcs-32 command line option, ARM: ARM Options. (line 120)
-* -mapcs-float command line option, ARM: ARM Options. (line 134)
-* -mapcs-reentrant command line option, ARM: ARM Options. (line 139)
-* -marc[5|6|7|8] command line option, ARC: ARC Options. (line 6)
-* -march= command line option, ARM: ARM Options. (line 59)
-* -march= command line option, M680x0: M68K-Opts. (line 8)
-* -march= command line option, TIC6X: TIC6X Options. (line 6)
-* -march= option, i386: i386-Options. (line 31)
-* -march= option, s390: s390 Options. (line 25)
-* -march= option, x86-64: i386-Options. (line 31)
-* -matomic command line option, TIC6X: TIC6X Options. (line 13)
-* -matpcs command line option, ARM: ARM Options. (line 126)
-* -mavxscalar= option, i386: i386-Options. (line 79)
-* -mavxscalar= option, x86-64: i386-Options. (line 79)
-* -mbarrel-shift-enabled command line option, LM32: LM32 Options.
- (line 12)
-* -mbig-endian: RX-Opts. (line 20)
-* -mbreak-enabled command line option, LM32: LM32 Options. (line 27)
-* -mcis: PDP-11-Options. (line 32)
-* -mconstant-gp command line option, IA-64: IA-64 Options. (line 6)
-* -mCPU command line option, Alpha: Alpha Options. (line 6)
-* -mcpu option, cpu: TIC54X-Opts. (line 15)
-* -mcpu= command line option, ARM: ARM Options. (line 6)
-* -mcpu= command line option, Blackfin: Blackfin Options. (line 6)
-* -mcpu= command line option, M680x0: M68K-Opts. (line 14)
-* -mcsm: PDP-11-Options. (line 43)
-* -mdcache-enabled command line option, LM32: LM32 Options. (line 24)
-* -mdebug command line option, Alpha: Alpha Options. (line 25)
-* -mdivide-enabled command line option, LM32: LM32 Options. (line 9)
-* -mdsbt command line option, TIC6X: TIC6X Options. (line 25)
-* -me option, stderr redirect: TIC54X-Opts. (line 20)
-* -meis: PDP-11-Options. (line 46)
-* -merrors-to-file option, stderr redirect: TIC54X-Opts. (line 20)
-* -mesa option, s390: s390 Options. (line 17)
-* -mf option, far-mode: TIC54X-Opts. (line 8)
-* -mf11: PDP-11-Options. (line 122)
-* -mfar-mode option, far-mode: TIC54X-Opts. (line 8)
-* -mfdpic command line option, Blackfin: Blackfin Options. (line 19)
-* -mfis: PDP-11-Options. (line 51)
-* -mfloat-abi= command line option, ARM: ARM Options. (line 143)
-* -mfp-11: PDP-11-Options. (line 56)
-* -mfpp: PDP-11-Options. (line 56)
-* -mfpu: PDP-11-Options. (line 56)
-* -mfpu= command line option, ARM: ARM Options. (line 74)
-* -micache-enabled command line option, LM32: LM32 Options. (line 21)
-* -mimplicit-it command line option, ARM: ARM Options. (line 104)
-* -mip2022 option, IP2K: IP2K-Opts. (line 14)
-* -mip2022ext option, IP2022: IP2K-Opts. (line 9)
-* -mj11: PDP-11-Options. (line 126)
-* -mka11: PDP-11-Options. (line 92)
-* -mkb11: PDP-11-Options. (line 95)
-* -mkd11a: PDP-11-Options. (line 98)
-* -mkd11b: PDP-11-Options. (line 101)
-* -mkd11d: PDP-11-Options. (line 104)
-* -mkd11e: PDP-11-Options. (line 107)
-* -mkd11f: PDP-11-Options. (line 110)
-* -mkd11h: PDP-11-Options. (line 110)
-* -mkd11k: PDP-11-Options. (line 114)
-* -mkd11q: PDP-11-Options. (line 110)
-* -mkd11z: PDP-11-Options. (line 118)
-* -mkev11: PDP-11-Options. (line 51)
-* -mlimited-eis: PDP-11-Options. (line 64)
-* -mlittle-endian: RX-Opts. (line 26)
-* -mlong: M68HC11-Opts. (line 32)
-* -mlong-double: M68HC11-Opts. (line 40)
-* -mmcu= command line option, AVR: AVR Options. (line 6)
-* -mmfpt: PDP-11-Options. (line 70)
-* -mmicrocode: PDP-11-Options. (line 83)
-* -mmnemonic= option, i386: i386-Options. (line 87)
-* -mmnemonic= option, x86-64: i386-Options. (line 87)
-* -mmultiply-enabled command line option, LM32: LM32 Options. (line 6)
-* -mmutiproc: PDP-11-Options. (line 73)
-* -mmxps: PDP-11-Options. (line 77)
-* -mnaked-reg option, i386: i386-Options. (line 99)
-* -mnaked-reg option, x86-64: i386-Options. (line 99)
-* -mno-atomic command line option, TIC6X: TIC6X Options. (line 13)
-* -mno-cis: PDP-11-Options. (line 32)
-* -mno-csm: PDP-11-Options. (line 43)
-* -mno-dsbt command line option, TIC6X: TIC6X Options. (line 25)
-* -mno-eis: PDP-11-Options. (line 46)
-* -mno-extensions: PDP-11-Options. (line 29)
-* -mno-fdpic command line option, Blackfin: Blackfin Options. (line 22)
-* -mno-fis: PDP-11-Options. (line 51)
-* -mno-fp-11: PDP-11-Options. (line 56)
-* -mno-fpp: PDP-11-Options. (line 56)
-* -mno-fpu: PDP-11-Options. (line 56)
-* -mno-kev11: PDP-11-Options. (line 51)
-* -mno-limited-eis: PDP-11-Options. (line 64)
-* -mno-mfpt: PDP-11-Options. (line 70)
-* -mno-microcode: PDP-11-Options. (line 83)
-* -mno-mutiproc: PDP-11-Options. (line 73)
-* -mno-mxps: PDP-11-Options. (line 77)
-* -mno-pic: PDP-11-Options. (line 11)
-* -mno-pic command line option, TIC6X: TIC6X Options. (line 48)
-* -mno-regnames option, s390: s390 Options. (line 35)
-* -mno-skip-bug command line option, AVR: AVR Options. (line 71)
-* -mno-spl: PDP-11-Options. (line 80)
-* -mno-sym32: MIPS Opts. (line 208)
-* -mno-wrap command line option, AVR: AVR Options. (line 74)
-* -mnopic command line option, Blackfin: Blackfin Options. (line 22)
-* -mpic: PDP-11-Options. (line 11)
-* -mpic command line option, TIC6X: TIC6X Options. (line 48)
-* -mpid= command line option, TIC6X: TIC6X Options. (line 35)
-* -mregnames option, s390: s390 Options. (line 32)
-* -mrelax command line option, V850: V850 Options. (line 63)
-* -mshort: M68HC11-Opts. (line 27)
-* -mshort-double: M68HC11-Opts. (line 36)
-* -msign-extend-enabled command line option, LM32: LM32 Options.
- (line 15)
-* -msmall-data-limit: RX-Opts. (line 42)
-* -mspl: PDP-11-Options. (line 80)
-* -msse-check= option, i386: i386-Options. (line 69)
-* -msse-check= option, x86-64: i386-Options. (line 69)
-* -msse2avx option, i386: i386-Options. (line 65)
-* -msse2avx option, x86-64: i386-Options. (line 65)
-* -msym32: MIPS Opts. (line 208)
-* -msyntax= option, i386: i386-Options. (line 93)
-* -msyntax= option, x86-64: i386-Options. (line 93)
-* -mt11: PDP-11-Options. (line 130)
-* -mthumb command line option, ARM: ARM Options. (line 95)
-* -mthumb-interwork command line option, ARM: ARM Options. (line 100)
-* -mtune= option, i386: i386-Options. (line 57)
-* -mtune= option, x86-64: i386-Options. (line 57)
-* -muse-conventional-section-names: RX-Opts. (line 33)
-* -muse-renesas-section-names: RX-Opts. (line 37)
-* -muser-enabled command line option, LM32: LM32 Options. (line 18)
-* -mv850 command line option, V850: V850 Options. (line 23)
-* -mv850any command line option, V850: V850 Options. (line 41)
-* -mv850e command line option, V850: V850 Options. (line 29)
-* -mv850e1 command line option, V850: V850 Options. (line 35)
-* -mv850e2 command line option, V850: V850 Options. (line 51)
-* -mv850e2v3 command line option, V850: V850 Options. (line 57)
-* -mvxworks-pic option, MIPS: MIPS Opts. (line 26)
-* -mwarn-areg-zero option, s390: s390 Options. (line 38)
-* -mwarn-deprecated command line option, ARM: ARM Options. (line 169)
-* -mzarch option, s390: s390 Options. (line 17)
-* -N command line option, CRIS: CRIS-Opts. (line 57)
-* -nIp option, M32RX: M32R-Opts. (line 101)
-* -no-bitinst, M32R2: M32R-Opts. (line 54)
-* -no-ignore-parallel-conflicts option, M32RX: M32R-Opts. (line 93)
-* -no-mdebug command line option, Alpha: Alpha Options. (line 25)
-* -no-parallel option, M32RX: M32R-Opts. (line 51)
-* -no-relax option, i960: Options-i960. (line 66)
-* -no-warn-explicit-parallel-conflicts option, M32RX: M32R-Opts.
- (line 79)
-* -no-warn-unmatched-high option, M32R: M32R-Opts. (line 111)
-* -nocpp ignored (MIPS): MIPS Opts. (line 211)
-* -noreplace command line option, Alpha: Alpha Options. (line 40)
-* -o: o. (line 6)
-* -O option, M32RX: M32R-Opts. (line 59)
-* -parallel option, M32RX: M32R-Opts. (line 46)
-* -R: R. (line 6)
-* -r800 command line option, Z80: Z80 Options. (line 41)
-* -relax command line option, Alpha: Alpha Options. (line 32)
-* -replace command line option, Alpha: Alpha Options. (line 40)
-* -S, ignored on VAX: VAX-Opts. (line 11)
-* -T, ignored on VAX: VAX-Opts. (line 11)
-* -t, ignored on VAX: VAX-Opts. (line 36)
-* -v: v. (line 6)
-* -V, redundant on VAX: VAX-Opts. (line 22)
-* -version: v. (line 6)
-* -W: W. (line 11)
-* -warn-explicit-parallel-conflicts option, M32RX: M32R-Opts. (line 65)
-* -warn-unmatched-high option, M32R: M32R-Opts. (line 105)
-* -Wnp option, M32RX: M32R-Opts. (line 83)
-* -Wnuh option, M32RX: M32R-Opts. (line 117)
-* -Wp option, M32RX: M32R-Opts. (line 75)
-* -wsigned_overflow command line option, V850: V850 Options. (line 9)
-* -Wuh option, M32RX: M32R-Opts. (line 114)
-* -wunsigned_overflow command line option, V850: V850 Options.
- (line 16)
-* -x command line option, MMIX: MMIX-Opts. (line 44)
-* -z80 command line option, Z80: Z80 Options. (line 8)
-* -z8001 command line option, Z8000: Z8000 Options. (line 6)
-* -z8002 command line option, Z8000: Z8000 Options. (line 9)
-* . (symbol): Dot. (line 6)
-* .2byte directive, ARM: ARM Directives. (line 6)
-* .4byte directive, ARM: ARM Directives. (line 6)
-* .8byte directive, ARM: ARM Directives. (line 6)
-* .align directive, ARM: ARM Directives. (line 11)
-* .arch directive, ARM: ARM Directives. (line 18)
-* .arch directive, TIC6X: TIC6X Directives. (line 10)
-* .arch_extension directive, ARM: ARM Directives. (line 25)
-* .arm directive, ARM: ARM Directives. (line 34)
-* .atomic directive, TIC6X: TIC6X Directives. (line 13)
-* .big directive, M32RX: M32R-Directives. (line 88)
-* .bss directive, ARM: ARM Directives. (line 42)
-* .c6xabi_attribute directive, TIC6X: TIC6X Directives. (line 17)
-* .cantunwind directive, ARM: ARM Directives. (line 45)
-* .code directive, ARM: ARM Directives. (line 49)
-* .cpu directive, ARM: ARM Directives. (line 53)
-* .dn and .qn directives, ARM: ARM Directives. (line 60)
-* .eabi_attribute directive, ARM: ARM Directives. (line 83)
-* .even directive, ARM: ARM Directives. (line 111)
-* .extend directive, ARM: ARM Directives. (line 114)
-* .fnend directive, ARM: ARM Directives. (line 120)
-* .fnstart directive, ARM: ARM Directives. (line 129)
-* .force_thumb directive, ARM: ARM Directives. (line 132)
-* .fpu directive, ARM: ARM Directives. (line 136)
-* .global: MIPS insn. (line 12)
-* .handlerdata directive, ARM: ARM Directives. (line 140)
-* .insn: MIPS insn. (line 6)
-* .insn directive, s390: s390 Directives. (line 11)
-* .inst directive, ARM: ARM Directives. (line 149)
-* .ldouble directive, ARM: ARM Directives. (line 114)
-* .little directive, M32RX: M32R-Directives. (line 82)
-* .long directive, s390: s390 Directives. (line 16)
-* .ltorg directive, ARM: ARM Directives. (line 159)
-* .ltorg directive, s390: s390 Directives. (line 88)
-* .m32r directive, M32R: M32R-Directives. (line 66)
-* .m32r2 directive, M32R2: M32R-Directives. (line 77)
-* .m32rx directive, M32RX: M32R-Directives. (line 72)
-* .movsp directive, ARM: ARM Directives. (line 173)
-* .noatomic directive, TIC6X: TIC6X Directives. (line 13)
-* .nocmp directive, TIC6X: TIC6X Directives. (line 28)
-* .o: Object. (line 6)
-* .object_arch directive, ARM: ARM Directives. (line 178)
-* .packed directive, ARM: ARM Directives. (line 184)
-* .pad directive, ARM: ARM Directives. (line 189)
-* .param on HPPA: HPPA Directives. (line 19)
-* .personality directive, ARM: ARM Directives. (line 194)
-* .personalityindex directive, ARM: ARM Directives. (line 197)
-* .pool directive, ARM: ARM Directives. (line 201)
-* .quad directive, s390: s390 Directives. (line 16)
-* .req directive, ARM: ARM Directives. (line 204)
-* .save directive, ARM: ARM Directives. (line 209)
-* .secrel32 directive, ARM: ARM Directives. (line 247)
-* .set arch=CPU: MIPS ISA. (line 18)
-* .set autoextend: MIPS autoextend. (line 6)
-* .set doublefloat: MIPS floating-point. (line 12)
-* .set dsp: MIPS ASE instruction generation overrides.
- (line 21)
-* .set dspr2: MIPS ASE instruction generation overrides.
- (line 26)
-* .set hardfloat: MIPS floating-point. (line 6)
-* .set mdmx: MIPS ASE instruction generation overrides.
- (line 16)
-* .set mips3d: MIPS ASE instruction generation overrides.
- (line 6)
-* .set mipsN: MIPS ISA. (line 6)
-* .set mt: MIPS ASE instruction generation overrides.
- (line 32)
-* .set noautoextend: MIPS autoextend. (line 6)
-* .set nodsp: MIPS ASE instruction generation overrides.
- (line 21)
-* .set nodspr2: MIPS ASE instruction generation overrides.
- (line 26)
-* .set nomdmx: MIPS ASE instruction generation overrides.
- (line 16)
-* .set nomips3d: MIPS ASE instruction generation overrides.
- (line 6)
-* .set nomt: MIPS ASE instruction generation overrides.
- (line 32)
-* .set nosmartmips: MIPS ASE instruction generation overrides.
- (line 11)
-* .set nosym32: MIPS symbol sizes. (line 6)
-* .set pop: MIPS option stack. (line 6)
-* .set push: MIPS option stack. (line 6)
-* .set singlefloat: MIPS floating-point. (line 12)
-* .set smartmips: MIPS ASE instruction generation overrides.
- (line 11)
-* .set softfloat: MIPS floating-point. (line 6)
-* .set sym32: MIPS symbol sizes. (line 6)
-* .setfp directive, ARM: ARM Directives. (line 233)
-* .short directive, s390: s390 Directives. (line 16)
-* .syntax directive, ARM: ARM Directives. (line 252)
-* .thumb directive, ARM: ARM Directives. (line 256)
-* .thumb_func directive, ARM: ARM Directives. (line 259)
-* .thumb_set directive, ARM: ARM Directives. (line 270)
-* .unreq directive, ARM: ARM Directives. (line 277)
-* .unwind_raw directive, ARM: ARM Directives. (line 288)
-* .v850 directive, V850: V850 Directives. (line 14)
-* .v850e directive, V850: V850 Directives. (line 20)
-* .v850e1 directive, V850: V850 Directives. (line 26)
-* .v850e2 directive, V850: V850 Directives. (line 32)
-* .v850e2v3 directive, V850: V850 Directives. (line 38)
-* .vsave directive, ARM: ARM Directives. (line 295)
-* .z8001: Z8000 Directives. (line 11)
-* .z8002: Z8000 Directives. (line 15)
-* 16-bit code, i386: i386-16bit. (line 6)
-* 2byte directive, ARC: ARC Directives. (line 9)
-* 3byte directive, ARC: ARC Directives. (line 12)
-* 3DNow!, i386: i386-SIMD. (line 6)
-* 3DNow!, x86-64: i386-SIMD. (line 6)
-* 430 support: MSP430-Dependent. (line 6)
-* 4byte directive, ARC: ARC Directives. (line 15)
-* : (label): Statements. (line 30)
-* @word modifier, D10V: D10V-Word. (line 6)
-* \" (doublequote character): Strings. (line 43)
-* \\ (\ character): Strings. (line 40)
-* \b (backspace character): Strings. (line 15)
-* \DDD (octal character code): Strings. (line 30)
-* \f (formfeed character): Strings. (line 18)
-* \n (newline character): Strings. (line 21)
-* \r (carriage return character): Strings. (line 24)
-* \t (tab): Strings. (line 27)
-* \XD... (hex character code): Strings. (line 36)
-* _ opcode prefix: Xtensa Opcodes. (line 9)
-* a.out: Object. (line 6)
-* a.out symbol attributes: a.out Symbols. (line 6)
-* A_DIR environment variable, TIC54X: TIC54X-Env. (line 6)
-* ABI options, SH64: SH64 Options. (line 29)
-* abort directive: Abort. (line 6)
-* ABORT directive: ABORT (COFF). (line 6)
-* absolute section: Ld Sections. (line 29)
-* absolute-literals directive: Absolute Literals Directive.
- (line 6)
-* ADDI instructions, relaxation: Xtensa Immediate Relaxation.
- (line 43)
-* addition, permitted arguments: Infix Ops. (line 44)
-* addresses: Expressions. (line 6)
-* addresses, format of: Secs Background. (line 68)
-* addressing modes, D10V: D10V-Addressing. (line 6)
-* addressing modes, D30V: D30V-Addressing. (line 6)
-* addressing modes, H8/300: H8/300-Addressing. (line 6)
-* addressing modes, M680x0: M68K-Syntax. (line 21)
-* addressing modes, M68HC11: M68HC11-Syntax. (line 17)
-* addressing modes, SH: SH-Addressing. (line 6)
-* addressing modes, SH64: SH64-Addressing. (line 6)
-* addressing modes, Z8000: Z8000-Addressing. (line 6)
-* ADR reg,<label> pseudo op, ARM: ARM Opcodes. (line 25)
-* ADRL reg,<label> pseudo op, ARM: ARM Opcodes. (line 35)
-* advancing location counter: Org. (line 6)
-* align directive: Align. (line 6)
-* align directive, SPARC: Sparc-Directives. (line 9)
-* align directive, TIC54X: TIC54X-Directives. (line 6)
-* alignment for NEON instructions: ARM-Neon-Alignment. (line 6)
-* alignment of branch targets: Xtensa Automatic Alignment.
- (line 6)
-* alignment of LOOP instructions: Xtensa Automatic Alignment.
- (line 6)
-* Alpha floating point (IEEE): Alpha Floating Point.
- (line 6)
-* Alpha line comment character: Alpha-Chars. (line 6)
-* Alpha line separator: Alpha-Chars. (line 8)
-* Alpha notes: Alpha Notes. (line 6)
-* Alpha options: Alpha Options. (line 6)
-* Alpha registers: Alpha-Regs. (line 6)
-* Alpha relocations: Alpha-Relocs. (line 6)
-* Alpha support: Alpha-Dependent. (line 6)
-* Alpha Syntax: Alpha Options. (line 61)
-* Alpha-only directives: Alpha Directives. (line 10)
-* altered difference tables: Word. (line 12)
-* alternate syntax for the 680x0: M68K-Moto-Syntax. (line 6)
-* ARC floating point (IEEE): ARC Floating Point. (line 6)
-* ARC machine directives: ARC Directives. (line 6)
-* ARC opcodes: ARC Opcodes. (line 6)
-* ARC options (none): ARC Options. (line 6)
-* ARC register names: ARC-Regs. (line 6)
-* ARC special characters: ARC-Chars. (line 6)
-* ARC support: ARC-Dependent. (line 6)
-* arc5 arc5, ARC: ARC Options. (line 10)
-* arc6 arc6, ARC: ARC Options. (line 13)
-* arc7 arc7, ARC: ARC Options. (line 21)
-* arc8 arc8, ARC: ARC Options. (line 24)
-* arch directive, i386: i386-Arch. (line 6)
-* arch directive, M680x0: M68K-Directives. (line 22)
-* arch directive, x86-64: i386-Arch. (line 6)
-* architecture options, i960: Options-i960. (line 6)
-* architecture options, IP2022: IP2K-Opts. (line 9)
-* architecture options, IP2K: IP2K-Opts. (line 14)
-* architecture options, M16C: M32C-Opts. (line 12)
-* architecture options, M32C: M32C-Opts. (line 9)
-* architecture options, M32R: M32R-Opts. (line 21)
-* architecture options, M32R2: M32R-Opts. (line 17)
-* architecture options, M32RX: M32R-Opts. (line 9)
-* architecture options, M680x0: M68K-Opts. (line 98)
-* Architecture variant option, CRIS: CRIS-Opts. (line 33)
-* architectures, PowerPC: PowerPC-Opts. (line 6)
-* architectures, SCORE: SCORE-Opts. (line 6)
-* architectures, SPARC: Sparc-Opts. (line 6)
-* arguments for addition: Infix Ops. (line 44)
-* arguments for subtraction: Infix Ops. (line 49)
-* arguments in expressions: Arguments. (line 6)
-* arithmetic functions: Operators. (line 6)
-* arithmetic operands: Arguments. (line 6)
-* ARM data relocations: ARM-Relocations. (line 6)
-* ARM floating point (IEEE): ARM Floating Point. (line 6)
-* ARM identifiers: ARM-Chars. (line 15)
-* ARM immediate character: ARM-Chars. (line 13)
-* ARM line comment character: ARM-Chars. (line 6)
-* ARM line separator: ARM-Chars. (line 10)
-* ARM machine directives: ARM Directives. (line 6)
-* ARM opcodes: ARM Opcodes. (line 6)
-* ARM options (none): ARM Options. (line 6)
-* ARM register names: ARM-Regs. (line 6)
-* ARM support: ARM-Dependent. (line 6)
-* ascii directive: Ascii. (line 6)
-* asciz directive: Asciz. (line 6)
-* asg directive, TIC54X: TIC54X-Directives. (line 20)
-* assembler bugs, reporting: Bug Reporting. (line 6)
-* assembler crash: Bug Criteria. (line 9)
-* assembler directive .3byte, RX: RX-Directives. (line 9)
-* assembler directive .arch, CRIS: CRIS-Pseudos. (line 45)
-* assembler directive .dword, CRIS: CRIS-Pseudos. (line 12)
-* assembler directive .far, M68HC11: M68HC11-Directives. (line 20)
-* assembler directive .interrupt, M68HC11: M68HC11-Directives.
- (line 26)
-* assembler directive .mode, M68HC11: M68HC11-Directives. (line 16)
-* assembler directive .relax, M68HC11: M68HC11-Directives. (line 10)
-* assembler directive .syntax, CRIS: CRIS-Pseudos. (line 17)
-* assembler directive .xrefb, M68HC11: M68HC11-Directives. (line 31)
-* assembler directive BSPEC, MMIX: MMIX-Pseudos. (line 131)
-* assembler directive BYTE, MMIX: MMIX-Pseudos. (line 97)
-* assembler directive ESPEC, MMIX: MMIX-Pseudos. (line 131)
-* assembler directive GREG, MMIX: MMIX-Pseudos. (line 50)
-* assembler directive IS, MMIX: MMIX-Pseudos. (line 42)
-* assembler directive LOC, MMIX: MMIX-Pseudos. (line 7)
-* assembler directive LOCAL, MMIX: MMIX-Pseudos. (line 28)
-* assembler directive OCTA, MMIX: MMIX-Pseudos. (line 108)
-* assembler directive PREFIX, MMIX: MMIX-Pseudos. (line 120)
-* assembler directive TETRA, MMIX: MMIX-Pseudos. (line 108)
-* assembler directive WYDE, MMIX: MMIX-Pseudos. (line 108)
-* assembler directives, CRIS: CRIS-Pseudos. (line 6)
-* assembler directives, M68HC11: M68HC11-Directives. (line 6)
-* assembler directives, M68HC12: M68HC11-Directives. (line 6)
-* assembler directives, MMIX: MMIX-Pseudos. (line 6)
-* assembler directives, RX: RX-Directives. (line 6)
-* assembler internal logic error: As Sections. (line 13)
-* assembler version: v. (line 6)
-* assembler, and linker: Secs Background. (line 10)
-* assembly listings, enabling: a. (line 6)
-* assigning values to symbols <1>: Equ. (line 6)
-* assigning values to symbols: Setting Symbols. (line 6)
-* atmp directive, i860: Directives-i860. (line 16)
-* att_syntax pseudo op, i386: i386-Syntax. (line 6)
-* att_syntax pseudo op, x86-64: i386-Syntax. (line 6)
-* attributes, symbol: Symbol Attributes. (line 6)
-* auxiliary attributes, COFF symbols: COFF Symbols. (line 19)
-* auxiliary symbol information, COFF: Dim. (line 6)
-* Av7: Sparc-Opts. (line 25)
-* AVR line comment character: AVR-Chars. (line 6)
-* AVR line separator: AVR-Chars. (line 10)
-* AVR modifiers: AVR-Modifiers. (line 6)
-* AVR opcode summary: AVR Opcodes. (line 6)
-* AVR options (none): AVR Options. (line 6)
-* AVR register names: AVR-Regs. (line 6)
-* AVR support: AVR-Dependent. (line 6)
-* backslash (\\): Strings. (line 40)
-* backspace (\b): Strings. (line 15)
-* balign directive: Balign. (line 6)
-* balignl directive: Balign. (line 27)
-* balignw directive: Balign. (line 27)
-* bes directive, TIC54X: TIC54X-Directives. (line 196)
-* big endian output, MIPS: Overview. (line 683)
-* big endian output, PJ: Overview. (line 590)
-* big-endian output, MIPS: MIPS Opts. (line 13)
-* big-endian output, TIC6X: TIC6X Options. (line 58)
-* bignums: Bignums. (line 6)
-* binary constants, TIC54X: TIC54X-Constants. (line 8)
-* binary files, including: Incbin. (line 6)
-* binary integers: Integers. (line 6)
-* bit names, IA-64: IA-64-Bits. (line 6)
-* bitfields, not supported on VAX: VAX-no. (line 6)
-* Blackfin directives: Blackfin Directives. (line 6)
-* Blackfin options (none): Blackfin Options. (line 6)
-* Blackfin support: Blackfin-Dependent. (line 6)
-* Blackfin syntax: Blackfin Syntax. (line 6)
-* block: Z8000 Directives. (line 55)
-* branch improvement, M680x0: M68K-Branch. (line 6)
-* branch improvement, M68HC11: M68HC11-Branch. (line 6)
-* branch improvement, VAX: VAX-branch. (line 6)
-* branch instructions, relaxation: Xtensa Branch Relaxation.
- (line 6)
-* branch recording, i960: Options-i960. (line 22)
-* branch statistics table, i960: Options-i960. (line 40)
-* branch target alignment: Xtensa Automatic Alignment.
- (line 6)
-* break directive, TIC54X: TIC54X-Directives. (line 143)
-* BSD syntax: PDP-11-Syntax. (line 6)
-* bss directive, i960: Directives-i960. (line 6)
-* bss directive, TIC54X: TIC54X-Directives. (line 29)
-* bss section <1>: Ld Sections. (line 20)
-* bss section: bss. (line 6)
-* bug criteria: Bug Criteria. (line 6)
-* bug reports: Bug Reporting. (line 6)
-* bugs in assembler: Reporting Bugs. (line 6)
-* Built-in symbols, CRIS: CRIS-Symbols. (line 6)
-* builtin math functions, TIC54X: TIC54X-Builtins. (line 6)
-* builtin subsym functions, TIC54X: TIC54X-Macros. (line 16)
-* bus lock prefixes, i386: i386-Prefixes. (line 36)
-* bval: Z8000 Directives. (line 30)
-* byte directive: Byte. (line 6)
-* byte directive, TIC54X: TIC54X-Directives. (line 36)
-* C54XDSP_DIR environment variable, TIC54X: TIC54X-Env. (line 6)
-* c_mode directive, TIC54X: TIC54X-Directives. (line 51)
-* call instructions, i386: i386-Mnemonics. (line 56)
-* call instructions, relaxation: Xtensa Call Relaxation.
- (line 6)
-* call instructions, x86-64: i386-Mnemonics. (line 56)
-* callj, i960 pseudo-opcode: callj-i960. (line 6)
-* carriage return (\r): Strings. (line 24)
-* case sensitivity, Z80: Z80-Case. (line 6)
-* cfi_endproc directive: CFI directives. (line 26)
-* cfi_sections directive: CFI directives. (line 6)
-* cfi_startproc directive: CFI directives. (line 16)
-* char directive, TIC54X: TIC54X-Directives. (line 36)
-* character constant, Z80: Z80-Chars. (line 13)
-* character constants: Characters. (line 6)
-* character escape codes: Strings. (line 15)
-* character escapes, Z80: Z80-Chars. (line 11)
-* character, single: Chars. (line 6)
-* characters used in symbols: Symbol Intro. (line 6)
-* clink directive, TIC54X: TIC54X-Directives. (line 45)
-* code16 directive, i386: i386-16bit. (line 6)
-* code16gcc directive, i386: i386-16bit. (line 6)
-* code32 directive, i386: i386-16bit. (line 6)
-* code64 directive, i386: i386-16bit. (line 6)
-* code64 directive, x86-64: i386-16bit. (line 6)
-* COFF auxiliary symbol information: Dim. (line 6)
-* COFF structure debugging: Tag. (line 6)
-* COFF symbol attributes: COFF Symbols. (line 6)
-* COFF symbol descriptor: Desc. (line 6)
-* COFF symbol storage class: Scl. (line 6)
-* COFF symbol type: Type. (line 11)
-* COFF symbols, debugging: Def. (line 6)
-* COFF value attribute: Val. (line 6)
-* COMDAT: Linkonce. (line 6)
-* comm directive: Comm. (line 6)
-* command line conventions: Command Line. (line 6)
-* command line options, V850: V850 Options. (line 9)
-* command-line options ignored, VAX: VAX-Opts. (line 6)
-* comments: Comments. (line 6)
-* comments, M680x0: M68K-Chars. (line 6)
-* comments, removed by preprocessor: Preprocessing. (line 11)
-* common directive, SPARC: Sparc-Directives. (line 12)
-* common sections: Linkonce. (line 6)
-* common variable storage: bss. (line 6)
-* compare and jump expansions, i960: Compare-and-branch-i960.
- (line 13)
-* compare/branch instructions, i960: Compare-and-branch-i960.
- (line 6)
-* comparison expressions: Infix Ops. (line 55)
-* conditional assembly: If. (line 6)
-* constant, single character: Chars. (line 6)
-* constants: Constants. (line 6)
-* constants, bignum: Bignums. (line 6)
-* constants, character: Characters. (line 6)
-* constants, converted by preprocessor: Preprocessing. (line 14)
-* constants, floating point: Flonums. (line 6)
-* constants, integer: Integers. (line 6)
-* constants, number: Numbers. (line 6)
-* constants, Sparc: Sparc-Constants. (line 6)
-* constants, string: Strings. (line 6)
-* constants, TIC54X: TIC54X-Constants. (line 6)
-* conversion instructions, i386: i386-Mnemonics. (line 37)
-* conversion instructions, x86-64: i386-Mnemonics. (line 37)
-* coprocessor wait, i386: i386-Prefixes. (line 40)
-* copy directive, TIC54X: TIC54X-Directives. (line 54)
-* cpu directive, M680x0: M68K-Directives. (line 30)
-* CR16 Operand Qualifiers: CR16 Operand Qualifiers.
- (line 6)
-* CR16 support: CR16-Dependent. (line 6)
-* crash of assembler: Bug Criteria. (line 9)
-* CRIS --emulation=crisaout command line option: CRIS-Opts. (line 9)
-* CRIS --emulation=criself command line option: CRIS-Opts. (line 9)
-* CRIS --march=ARCHITECTURE command line option: CRIS-Opts. (line 33)
-* CRIS --mul-bug-abort command line option: CRIS-Opts. (line 61)
-* CRIS --no-mul-bug-abort command line option: CRIS-Opts. (line 61)
-* CRIS --no-underscore command line option: CRIS-Opts. (line 15)
-* CRIS --pic command line option: CRIS-Opts. (line 27)
-* CRIS --underscore command line option: CRIS-Opts. (line 15)
-* CRIS -N command line option: CRIS-Opts. (line 57)
-* CRIS architecture variant option: CRIS-Opts. (line 33)
-* CRIS assembler directive .arch: CRIS-Pseudos. (line 45)
-* CRIS assembler directive .dword: CRIS-Pseudos. (line 12)
-* CRIS assembler directive .syntax: CRIS-Pseudos. (line 17)
-* CRIS assembler directives: CRIS-Pseudos. (line 6)
-* CRIS built-in symbols: CRIS-Symbols. (line 6)
-* CRIS instruction expansion: CRIS-Expand. (line 6)
-* CRIS line comment characters: CRIS-Chars. (line 6)
-* CRIS options: CRIS-Opts. (line 6)
-* CRIS position-independent code: CRIS-Opts. (line 27)
-* CRIS pseudo-op .arch: CRIS-Pseudos. (line 45)
-* CRIS pseudo-op .dword: CRIS-Pseudos. (line 12)
-* CRIS pseudo-op .syntax: CRIS-Pseudos. (line 17)
-* CRIS pseudo-ops: CRIS-Pseudos. (line 6)
-* CRIS register names: CRIS-Regs. (line 6)
-* CRIS support: CRIS-Dependent. (line 6)
-* CRIS symbols in position-independent code: CRIS-Pic. (line 6)
-* ctbp register, V850: V850-Regs. (line 131)
-* ctoff pseudo-op, V850: V850 Opcodes. (line 111)
-* ctpc register, V850: V850-Regs. (line 119)
-* ctpsw register, V850: V850-Regs. (line 122)
-* current address: Dot. (line 6)
-* current address, advancing: Org. (line 6)
-* D10V @word modifier: D10V-Word. (line 6)
-* D10V addressing modes: D10V-Addressing. (line 6)
-* D10V floating point: D10V-Float. (line 6)
-* D10V line comment character: D10V-Chars. (line 6)
-* D10V opcode summary: D10V-Opcodes. (line 6)
-* D10V optimization: Overview. (line 462)
-* D10V options: D10V-Opts. (line 6)
-* D10V registers: D10V-Regs. (line 6)
-* D10V size modifiers: D10V-Size. (line 6)
-* D10V sub-instruction ordering: D10V-Chars. (line 6)
-* D10V sub-instructions: D10V-Subs. (line 6)
-* D10V support: D10V-Dependent. (line 6)
-* D10V syntax: D10V-Syntax. (line 6)
-* D30V addressing modes: D30V-Addressing. (line 6)
-* D30V floating point: D30V-Float. (line 6)
-* D30V Guarded Execution: D30V-Guarded. (line 6)
-* D30V line comment character: D30V-Chars. (line 6)
-* D30V nops: Overview. (line 470)
-* D30V nops after 32-bit multiply: Overview. (line 473)
-* D30V opcode summary: D30V-Opcodes. (line 6)
-* D30V optimization: Overview. (line 467)
-* D30V options: D30V-Opts. (line 6)
-* D30V registers: D30V-Regs. (line 6)
-* D30V size modifiers: D30V-Size. (line 6)
-* D30V sub-instruction ordering: D30V-Chars. (line 6)
-* D30V sub-instructions: D30V-Subs. (line 6)
-* D30V support: D30V-Dependent. (line 6)
-* D30V syntax: D30V-Syntax. (line 6)
-* data alignment on SPARC: Sparc-Aligned-Data. (line 6)
-* data and text sections, joining: R. (line 6)
-* data directive: Data. (line 6)
-* data directive, TIC54X: TIC54X-Directives. (line 61)
-* data relocations, ARM: ARM-Relocations. (line 6)
-* data section: Ld Sections. (line 9)
-* data1 directive, M680x0: M68K-Directives. (line 9)
-* data2 directive, M680x0: M68K-Directives. (line 12)
-* datalabel, SH64: SH64-Addressing. (line 16)
-* dbpc register, V850: V850-Regs. (line 125)
-* dbpsw register, V850: V850-Regs. (line 128)
-* debuggers, and symbol order: Symbols. (line 10)
-* debugging COFF symbols: Def. (line 6)
-* DEC syntax: PDP-11-Syntax. (line 6)
-* decimal integers: Integers. (line 12)
-* def directive: Def. (line 6)
-* def directive, TIC54X: TIC54X-Directives. (line 103)
-* density instructions: Density Instructions.
- (line 6)
-* dependency tracking: MD. (line 6)
-* deprecated directives: Deprecated. (line 6)
-* desc directive: Desc. (line 6)
-* descriptor, of a.out symbol: Symbol Desc. (line 6)
-* dfloat directive, VAX: VAX-directives. (line 10)
-* difference tables altered: Word. (line 12)
-* difference tables, warning: K. (line 6)
-* differences, mmixal: MMIX-mmixal. (line 6)
-* dim directive: Dim. (line 6)
-* directives and instructions: Statements. (line 19)
-* directives for PowerPC: PowerPC-Pseudo. (line 6)
-* directives for SCORE: SCORE-Pseudo. (line 6)
-* directives, Blackfin: Blackfin Directives. (line 6)
-* directives, M32R: M32R-Directives. (line 6)
-* directives, M680x0: M68K-Directives. (line 6)
-* directives, machine independent: Pseudo Ops. (line 6)
-* directives, Xtensa: Xtensa Directives. (line 6)
-* directives, Z8000: Z8000 Directives. (line 6)
-* Disable floating-point instructions: MIPS floating-point. (line 6)
-* Disable single-precision floating-point operations: MIPS floating-point.
- (line 12)
-* displacement sizing character, VAX: VAX-operands. (line 12)
-* dollar local symbols: Symbol Names. (line 105)
-* dot (symbol): Dot. (line 6)
-* double directive: Double. (line 6)
-* double directive, i386: i386-Float. (line 14)
-* double directive, M680x0: M68K-Float. (line 14)
-* double directive, M68HC11: M68HC11-Float. (line 14)
-* double directive, RX: RX-Float. (line 11)
-* double directive, TIC54X: TIC54X-Directives. (line 64)
-* double directive, VAX: VAX-float. (line 15)
-* double directive, x86-64: i386-Float. (line 14)
-* doublequote (\"): Strings. (line 43)
-* drlist directive, TIC54X: TIC54X-Directives. (line 73)
-* drnolist directive, TIC54X: TIC54X-Directives. (line 73)
-* dual directive, i860: Directives-i860. (line 6)
-* ECOFF sections: MIPS Object. (line 6)
-* ecr register, V850: V850-Regs. (line 113)
-* eight-byte integer: Quad. (line 9)
-* eipc register, V850: V850-Regs. (line 101)
-* eipsw register, V850: V850-Regs. (line 104)
-* eject directive: Eject. (line 6)
-* ELF symbol type: Type. (line 22)
-* else directive: Else. (line 6)
-* elseif directive: Elseif. (line 6)
-* empty expressions: Empty Exprs. (line 6)
-* emsg directive, TIC54X: TIC54X-Directives. (line 77)
-* emulation: Overview. (line 786)
-* encoding options, i386: i386-Mnemonics. (line 32)
-* encoding options, x86-64: i386-Mnemonics. (line 32)
-* end directive: End. (line 6)
-* enddual directive, i860: Directives-i860. (line 11)
-* endef directive: Endef. (line 6)
-* endfunc directive: Endfunc. (line 6)
-* endianness, MIPS: Overview. (line 683)
-* endianness, PJ: Overview. (line 590)
-* endif directive: Endif. (line 6)
-* endloop directive, TIC54X: TIC54X-Directives. (line 143)
-* endm directive: Macro. (line 138)
-* endm directive, TIC54X: TIC54X-Directives. (line 153)
-* endstruct directive, TIC54X: TIC54X-Directives. (line 216)
-* endunion directive, TIC54X: TIC54X-Directives. (line 250)
-* environment settings, TIC54X: TIC54X-Env. (line 6)
-* EOF, newline must precede: Statements. (line 13)
-* ep register, V850: V850-Regs. (line 95)
-* equ directive: Equ. (line 6)
-* equ directive, TIC54X: TIC54X-Directives. (line 191)
-* equiv directive: Equiv. (line 6)
-* eqv directive: Eqv. (line 6)
-* err directive: Err. (line 6)
-* error directive: Error. (line 6)
-* error messages: Errors. (line 6)
-* error on valid input: Bug Criteria. (line 12)
-* errors, caused by warnings: W. (line 16)
-* errors, continuing after: Z. (line 6)
-* ESA/390 floating point (IEEE): ESA/390 Floating Point.
- (line 6)
-* ESA/390 support: ESA/390-Dependent. (line 6)
-* ESA/390 Syntax: ESA/390 Options. (line 8)
-* ESA/390-only directives: ESA/390 Directives. (line 12)
-* escape codes, character: Strings. (line 15)
-* eval directive, TIC54X: TIC54X-Directives. (line 24)
-* even: Z8000 Directives. (line 58)
-* even directive, M680x0: M68K-Directives. (line 15)
-* even directive, TIC54X: TIC54X-Directives. (line 6)
-* exitm directive: Macro. (line 141)
-* expr (internal section): As Sections. (line 17)
-* expression arguments: Arguments. (line 6)
-* expressions: Expressions. (line 6)
-* expressions, comparison: Infix Ops. (line 55)
-* expressions, empty: Empty Exprs. (line 6)
-* expressions, integer: Integer Exprs. (line 6)
-* extAuxRegister directive, ARC: ARC Directives. (line 18)
-* extCondCode directive, ARC: ARC Directives. (line 41)
-* extCoreRegister directive, ARC: ARC Directives. (line 53)
-* extend directive M680x0: M68K-Float. (line 17)
-* extend directive M68HC11: M68HC11-Float. (line 17)
-* extended directive, i960: Directives-i960. (line 13)
-* extern directive: Extern. (line 6)
-* extInstruction directive, ARC: ARC Directives. (line 78)
-* fail directive: Fail. (line 6)
-* far_mode directive, TIC54X: TIC54X-Directives. (line 82)
-* faster processing (-f): f. (line 6)
-* fatal signal: Bug Criteria. (line 9)
-* fclist directive, TIC54X: TIC54X-Directives. (line 87)
-* fcnolist directive, TIC54X: TIC54X-Directives. (line 87)
-* fepc register, V850: V850-Regs. (line 107)
-* fepsw register, V850: V850-Regs. (line 110)
-* ffloat directive, VAX: VAX-directives. (line 14)
-* field directive, TIC54X: TIC54X-Directives. (line 91)
-* file directive: File. (line 6)
-* file directive, MSP 430: MSP430 Directives. (line 6)
-* file name, logical: File. (line 13)
-* files, including: Include. (line 6)
-* files, input: Input Files. (line 6)
-* fill directive: Fill. (line 6)
-* filling memory <1>: Skip. (line 6)
-* filling memory: Space. (line 6)
-* FLIX syntax: Xtensa Syntax. (line 6)
-* float directive: Float. (line 6)
-* float directive, i386: i386-Float. (line 14)
-* float directive, M680x0: M68K-Float. (line 11)
-* float directive, M68HC11: M68HC11-Float. (line 11)
-* float directive, RX: RX-Float. (line 8)
-* float directive, TIC54X: TIC54X-Directives. (line 64)
-* float directive, VAX: VAX-float. (line 15)
-* float directive, x86-64: i386-Float. (line 14)
-* floating point numbers: Flonums. (line 6)
-* floating point numbers (double): Double. (line 6)
-* floating point numbers (single) <1>: Float. (line 6)
-* floating point numbers (single): Single. (line 6)
-* floating point, Alpha (IEEE): Alpha Floating Point.
- (line 6)
-* floating point, ARC (IEEE): ARC Floating Point. (line 6)
-* floating point, ARM (IEEE): ARM Floating Point. (line 6)
-* floating point, D10V: D10V-Float. (line 6)
-* floating point, D30V: D30V-Float. (line 6)
-* floating point, ESA/390 (IEEE): ESA/390 Floating Point.
- (line 6)
-* floating point, H8/300 (IEEE): H8/300 Floating Point.
- (line 6)
-* floating point, HPPA (IEEE): HPPA Floating Point. (line 6)
-* floating point, i386: i386-Float. (line 6)
-* floating point, i960 (IEEE): Floating Point-i960. (line 6)
-* floating point, M680x0: M68K-Float. (line 6)
-* floating point, M68HC11: M68HC11-Float. (line 6)
-* floating point, MSP 430 (IEEE): MSP430 Floating Point.
- (line 6)
-* floating point, RX: RX-Float. (line 6)
-* floating point, s390: s390 Floating Point. (line 6)
-* floating point, SH (IEEE): SH Floating Point. (line 6)
-* floating point, SPARC (IEEE): Sparc-Float. (line 6)
-* floating point, V850 (IEEE): V850 Floating Point. (line 6)
-* floating point, VAX: VAX-float. (line 6)
-* floating point, x86-64: i386-Float. (line 6)
-* floating point, Z80: Z80 Floating Point. (line 6)
-* flonums: Flonums. (line 6)
-* format of error messages: Errors. (line 24)
-* format of warning messages: Errors. (line 12)
-* formfeed (\f): Strings. (line 18)
-* func directive: Func. (line 6)
-* functions, in expressions: Operators. (line 6)
-* gbr960, i960 postprocessor: Options-i960. (line 40)
-* gfloat directive, VAX: VAX-directives. (line 18)
-* global: Z8000 Directives. (line 21)
-* global directive: Global. (line 6)
-* global directive, TIC54X: TIC54X-Directives. (line 103)
-* gp register, MIPS: MIPS Object. (line 11)
-* gp register, V850: V850-Regs. (line 17)
-* grouping data: Sub-Sections. (line 6)
-* H8/300 addressing modes: H8/300-Addressing. (line 6)
-* H8/300 floating point (IEEE): H8/300 Floating Point.
- (line 6)
-* H8/300 line comment character: H8/300-Chars. (line 6)
-* H8/300 line separator: H8/300-Chars. (line 8)
-* H8/300 machine directives (none): H8/300 Directives. (line 6)
-* H8/300 opcode summary: H8/300 Opcodes. (line 6)
-* H8/300 options: H8/300 Options. (line 6)
-* H8/300 registers: H8/300-Regs. (line 6)
-* H8/300 size suffixes: H8/300 Opcodes. (line 163)
-* H8/300 support: H8/300-Dependent. (line 6)
-* H8/300H, assembling for: H8/300 Directives. (line 8)
-* half directive, ARC: ARC Directives. (line 156)
-* half directive, SPARC: Sparc-Directives. (line 17)
-* half directive, TIC54X: TIC54X-Directives. (line 111)
-* hex character code (\XD...): Strings. (line 36)
-* hexadecimal integers: Integers. (line 15)
-* hexadecimal prefix, Z80: Z80-Chars. (line 8)
-* hfloat directive, VAX: VAX-directives. (line 22)
-* hi pseudo-op, V850: V850 Opcodes. (line 33)
-* hi0 pseudo-op, V850: V850 Opcodes. (line 10)
-* hidden directive: Hidden. (line 6)
-* high directive, M32R: M32R-Directives. (line 18)
-* hilo pseudo-op, V850: V850 Opcodes. (line 55)
-* HPPA directives not supported: HPPA Directives. (line 11)
-* HPPA floating point (IEEE): HPPA Floating Point. (line 6)
-* HPPA Syntax: HPPA Options. (line 8)
-* HPPA-only directives: HPPA Directives. (line 24)
-* hword directive: hword. (line 6)
-* i370 support: ESA/390-Dependent. (line 6)
-* i386 16-bit code: i386-16bit. (line 6)
-* i386 arch directive: i386-Arch. (line 6)
-* i386 att_syntax pseudo op: i386-Syntax. (line 6)
-* i386 conversion instructions: i386-Mnemonics. (line 37)
-* i386 floating point: i386-Float. (line 6)
-* i386 immediate operands: i386-Syntax. (line 15)
-* i386 instruction naming: i386-Mnemonics. (line 6)
-* i386 instruction prefixes: i386-Prefixes. (line 6)
-* i386 intel_syntax pseudo op: i386-Syntax. (line 6)
-* i386 jump optimization: i386-Jumps. (line 6)
-* i386 jump, call, return: i386-Syntax. (line 41)
-* i386 jump/call operands: i386-Syntax. (line 15)
-* i386 memory references: i386-Memory. (line 6)
-* i386 mnemonic compatibility: i386-Mnemonics. (line 62)
-* i386 mul, imul instructions: i386-Notes. (line 6)
-* i386 options: i386-Options. (line 6)
-* i386 register operands: i386-Syntax. (line 15)
-* i386 registers: i386-Regs. (line 6)
-* i386 sections: i386-Syntax. (line 47)
-* i386 size suffixes: i386-Syntax. (line 29)
-* i386 source, destination operands: i386-Syntax. (line 22)
-* i386 support: i386-Dependent. (line 6)
-* i386 syntax compatibility: i386-Syntax. (line 6)
-* i80386 support: i386-Dependent. (line 6)
-* i860 machine directives: Directives-i860. (line 6)
-* i860 opcodes: Opcodes for i860. (line 6)
-* i860 support: i860-Dependent. (line 6)
-* i960 architecture options: Options-i960. (line 6)
-* i960 branch recording: Options-i960. (line 22)
-* i960 callj pseudo-opcode: callj-i960. (line 6)
-* i960 compare and jump expansions: Compare-and-branch-i960.
- (line 13)
-* i960 compare/branch instructions: Compare-and-branch-i960.
- (line 6)
-* i960 floating point (IEEE): Floating Point-i960. (line 6)
-* i960 machine directives: Directives-i960. (line 6)
-* i960 opcodes: Opcodes for i960. (line 6)
-* i960 options: Options-i960. (line 6)
-* i960 support: i960-Dependent. (line 6)
-* IA-64 line comment character: IA-64-Chars. (line 6)
-* IA-64 line separator: IA-64-Chars. (line 8)
-* IA-64 options: IA-64 Options. (line 6)
-* IA-64 Processor-status-Register bit names: IA-64-Bits. (line 6)
-* IA-64 registers: IA-64-Regs. (line 6)
-* IA-64 relocations: IA-64-Relocs. (line 6)
-* IA-64 support: IA-64-Dependent. (line 6)
-* IA-64 Syntax: IA-64 Options. (line 87)
-* ident directive: Ident. (line 6)
-* identifiers, ARM: ARM-Chars. (line 15)
-* identifiers, MSP 430: MSP430-Chars. (line 8)
-* if directive: If. (line 6)
-* ifb directive: If. (line 21)
-* ifc directive: If. (line 25)
-* ifdef directive: If. (line 16)
-* ifeq directive: If. (line 33)
-* ifeqs directive: If. (line 36)
-* ifge directive: If. (line 40)
-* ifgt directive: If. (line 44)
-* ifle directive: If. (line 48)
-* iflt directive: If. (line 52)
-* ifnb directive: If. (line 56)
-* ifnc directive: If. (line 61)
-* ifndef directive: If. (line 65)
-* ifne directive: If. (line 72)
-* ifnes directive: If. (line 76)
-* ifnotdef directive: If. (line 65)
-* immediate character, ARM: ARM-Chars. (line 13)
-* immediate character, M680x0: M68K-Chars. (line 6)
-* immediate character, VAX: VAX-operands. (line 6)
-* immediate fields, relaxation: Xtensa Immediate Relaxation.
- (line 6)
-* immediate operands, i386: i386-Syntax. (line 15)
-* immediate operands, x86-64: i386-Syntax. (line 15)
-* imul instruction, i386: i386-Notes. (line 6)
-* imul instruction, x86-64: i386-Notes. (line 6)
-* incbin directive: Incbin. (line 6)
-* include directive: Include. (line 6)
-* include directive search path: I. (line 6)
-* indirect character, VAX: VAX-operands. (line 9)
-* infix operators: Infix Ops. (line 6)
-* inhibiting interrupts, i386: i386-Prefixes. (line 36)
-* input: Input Files. (line 6)
-* input file linenumbers: Input Files. (line 35)
-* instruction aliases, s390: s390 Aliases. (line 6)
-* instruction expansion, CRIS: CRIS-Expand. (line 6)
-* instruction expansion, MMIX: MMIX-Expand. (line 6)
-* instruction formats, s390: s390 Formats. (line 6)
-* instruction marker, s390: s390 Instruction Marker.
- (line 6)
-* instruction mnemonics, s390: s390 Mnemonics. (line 6)
-* instruction naming, i386: i386-Mnemonics. (line 6)
-* instruction naming, x86-64: i386-Mnemonics. (line 6)
-* instruction operand modifier, s390: s390 Operand Modifier.
- (line 6)
-* instruction operands, s390: s390 Operands. (line 6)
-* instruction prefixes, i386: i386-Prefixes. (line 6)
-* instruction set, M680x0: M68K-opcodes. (line 6)
-* instruction set, M68HC11: M68HC11-opcodes. (line 6)
-* instruction summary, AVR: AVR Opcodes. (line 6)
-* instruction summary, D10V: D10V-Opcodes. (line 6)
-* instruction summary, D30V: D30V-Opcodes. (line 6)
-* instruction summary, H8/300: H8/300 Opcodes. (line 6)
-* instruction summary, LM32: LM32 Opcodes. (line 6)
-* instruction summary, SH: SH Opcodes. (line 6)
-* instruction summary, SH64: SH64 Opcodes. (line 6)
-* instruction summary, Z8000: Z8000 Opcodes. (line 6)
-* instruction syntax, s390: s390 Syntax. (line 6)
-* instructions and directives: Statements. (line 19)
-* int directive: Int. (line 6)
-* int directive, H8/300: H8/300 Directives. (line 6)
-* int directive, i386: i386-Float. (line 21)
-* int directive, TIC54X: TIC54X-Directives. (line 111)
-* int directive, x86-64: i386-Float. (line 21)
-* integer expressions: Integer Exprs. (line 6)
-* integer, 16-byte: Octa. (line 6)
-* integer, 8-byte: Quad. (line 9)
-* integers: Integers. (line 6)
-* integers, 16-bit: hword. (line 6)
-* integers, 32-bit: Int. (line 6)
-* integers, binary: Integers. (line 6)
-* integers, decimal: Integers. (line 12)
-* integers, hexadecimal: Integers. (line 15)
-* integers, octal: Integers. (line 9)
-* integers, one byte: Byte. (line 6)
-* intel_syntax pseudo op, i386: i386-Syntax. (line 6)
-* intel_syntax pseudo op, x86-64: i386-Syntax. (line 6)
-* internal assembler sections: As Sections. (line 6)
-* internal directive: Internal. (line 6)
-* invalid input: Bug Criteria. (line 14)
-* invocation summary: Overview. (line 6)
-* IP2K architecture options: IP2K-Opts. (line 14)
-* IP2K options: IP2K-Opts. (line 6)
-* IP2K support: IP2K-Dependent. (line 6)
-* irp directive: Irp. (line 6)
-* irpc directive: Irpc. (line 6)
-* ISA options, SH64: SH64 Options. (line 6)
-* joining text and data sections: R. (line 6)
-* jump instructions, i386: i386-Mnemonics. (line 56)
-* jump instructions, x86-64: i386-Mnemonics. (line 56)
-* jump optimization, i386: i386-Jumps. (line 6)
-* jump optimization, x86-64: i386-Jumps. (line 6)
-* jump/call operands, i386: i386-Syntax. (line 15)
-* jump/call operands, x86-64: i386-Syntax. (line 15)
-* L16SI instructions, relaxation: Xtensa Immediate Relaxation.
- (line 23)
-* L16UI instructions, relaxation: Xtensa Immediate Relaxation.
- (line 23)
-* L32I instructions, relaxation: Xtensa Immediate Relaxation.
- (line 23)
-* L8UI instructions, relaxation: Xtensa Immediate Relaxation.
- (line 23)
-* label (:): Statements. (line 30)
-* label directive, TIC54X: TIC54X-Directives. (line 123)
-* labels: Labels. (line 6)
-* lcomm directive: Lcomm. (line 6)
-* lcomm directive, COFF: i386-Directives. (line 6)
-* ld: Object. (line 15)
-* ldouble directive M680x0: M68K-Float. (line 17)
-* ldouble directive M68HC11: M68HC11-Float. (line 17)
-* ldouble directive, TIC54X: TIC54X-Directives. (line 64)
-* LDR reg,=<label> pseudo op, ARM: ARM Opcodes. (line 15)
-* leafproc directive, i960: Directives-i960. (line 18)
-* length directive, TIC54X: TIC54X-Directives. (line 127)
-* length of symbols: Symbol Intro. (line 14)
-* lflags directive (ignored): Lflags. (line 6)
-* line comment character: Comments. (line 19)
-* line comment character, Alpha: Alpha-Chars. (line 6)
-* line comment character, ARM: ARM-Chars. (line 6)
-* line comment character, AVR: AVR-Chars. (line 6)
-* line comment character, D10V: D10V-Chars. (line 6)
-* line comment character, D30V: D30V-Chars. (line 6)
-* line comment character, H8/300: H8/300-Chars. (line 6)
-* line comment character, IA-64: IA-64-Chars. (line 6)
-* line comment character, M680x0: M68K-Chars. (line 6)
-* line comment character, MSP 430: MSP430-Chars. (line 6)
-* line comment character, s390: s390 Characters. (line 6)
-* line comment character, SH: SH-Chars. (line 6)
-* line comment character, SH64: SH64-Chars. (line 6)
-* line comment character, Sparc: Sparc-Chars. (line 6)
-* line comment character, TIC6X: TIC6X Syntax. (line 6)
-* line comment character, V850: V850-Chars. (line 6)
-* line comment character, Z80: Z80-Chars. (line 6)
-* line comment character, Z8000: Z8000-Chars. (line 6)
-* line comment characters, CRIS: CRIS-Chars. (line 6)
-* line comment characters, MMIX: MMIX-Chars. (line 6)
-* line directive: Line. (line 6)
-* line directive, MSP 430: MSP430 Directives. (line 14)
-* line numbers, in input files: Input Files. (line 35)
-* line numbers, in warnings/errors: Errors. (line 16)
-* line separator character: Statements. (line 6)
-* line separator, Alpha: Alpha-Chars. (line 8)
-* line separator, ARM: ARM-Chars. (line 10)
-* line separator, AVR: AVR-Chars. (line 10)
-* line separator, H8/300: H8/300-Chars. (line 8)
-* line separator, IA-64: IA-64-Chars. (line 8)
-* line separator, SH: SH-Chars. (line 8)
-* line separator, SH64: SH64-Chars. (line 8)
-* line separator, Sparc: Sparc-Chars. (line 8)
-* line separator, TIC6X: TIC6X Syntax. (line 10)
-* line separator, Z8000: Z8000-Chars. (line 8)
-* lines starting with #: Comments. (line 39)
-* linker: Object. (line 15)
-* linker, and assembler: Secs Background. (line 10)
-* linkonce directive: Linkonce. (line 6)
-* list directive: List. (line 6)
-* list directive, TIC54X: TIC54X-Directives. (line 131)
-* listing control, turning off: Nolist. (line 6)
-* listing control, turning on: List. (line 6)
-* listing control: new page: Eject. (line 6)
-* listing control: paper size: Psize. (line 6)
-* listing control: subtitle: Sbttl. (line 6)
-* listing control: title line: Title. (line 6)
-* listings, enabling: a. (line 6)
-* literal directive: Literal Directive. (line 6)
-* literal pool entries, s390: s390 Literal Pool Entries.
- (line 6)
-* literal_position directive: Literal Position Directive.
- (line 6)
-* literal_prefix directive: Literal Prefix Directive.
- (line 6)
-* little endian output, MIPS: Overview. (line 686)
-* little endian output, PJ: Overview. (line 593)
-* little-endian output, MIPS: MIPS Opts. (line 13)
-* little-endian output, TIC6X: TIC6X Options. (line 58)
-* LM32 modifiers: LM32-Modifiers. (line 6)
-* LM32 opcode summary: LM32 Opcodes. (line 6)
-* LM32 options (none): LM32 Options. (line 6)
-* LM32 register names: LM32-Regs. (line 6)
-* LM32 support: LM32-Dependent. (line 6)
-* ln directive: Ln. (line 6)
-* lo pseudo-op, V850: V850 Opcodes. (line 22)
-* loc directive: Loc. (line 6)
-* loc_mark_labels directive: Loc_mark_labels. (line 6)
-* local common symbols: Lcomm. (line 6)
-* local directive: Local. (line 6)
-* local labels: Symbol Names. (line 35)
-* local symbol names: Symbol Names. (line 22)
-* local symbols, retaining in output: L. (line 6)
-* location counter: Dot. (line 6)
-* location counter, advancing: Org. (line 6)
-* location counter, Z80: Z80-Chars. (line 8)
-* logical file name: File. (line 13)
-* logical line number: Line. (line 6)
-* logical line numbers: Comments. (line 39)
-* long directive: Long. (line 6)
-* long directive, ARC: ARC Directives. (line 159)
-* long directive, i386: i386-Float. (line 21)
-* long directive, TIC54X: TIC54X-Directives. (line 135)
-* long directive, x86-64: i386-Float. (line 21)
-* longcall pseudo-op, V850: V850 Opcodes. (line 123)
-* longcalls directive: Longcalls Directive. (line 6)
-* longjump pseudo-op, V850: V850 Opcodes. (line 129)
-* loop directive, TIC54X: TIC54X-Directives. (line 143)
-* LOOP instructions, alignment: Xtensa Automatic Alignment.
- (line 6)
-* low directive, M32R: M32R-Directives. (line 9)
-* lp register, V850: V850-Regs. (line 98)
-* lval: Z8000 Directives. (line 27)
-* LWP, i386: i386-LWP. (line 6)
-* LWP, x86-64: i386-LWP. (line 6)
-* M16C architecture option: M32C-Opts. (line 12)
-* M32C architecture option: M32C-Opts. (line 9)
-* M32C modifiers: M32C-Modifiers. (line 6)
-* M32C options: M32C-Opts. (line 6)
-* M32C support: M32C-Dependent. (line 6)
-* M32R architecture options: M32R-Opts. (line 17)
-* M32R directives: M32R-Directives. (line 6)
-* M32R options: M32R-Opts. (line 6)
-* M32R support: M32R-Dependent. (line 6)
-* M32R warnings: M32R-Warnings. (line 6)
-* M680x0 addressing modes: M68K-Syntax. (line 21)
-* M680x0 architecture options: M68K-Opts. (line 98)
-* M680x0 branch improvement: M68K-Branch. (line 6)
-* M680x0 directives: M68K-Directives. (line 6)
-* M680x0 floating point: M68K-Float. (line 6)
-* M680x0 immediate character: M68K-Chars. (line 6)
-* M680x0 line comment character: M68K-Chars. (line 6)
-* M680x0 opcodes: M68K-opcodes. (line 6)
-* M680x0 options: M68K-Opts. (line 6)
-* M680x0 pseudo-opcodes: M68K-Branch. (line 6)
-* M680x0 size modifiers: M68K-Syntax. (line 8)
-* M680x0 support: M68K-Dependent. (line 6)
-* M680x0 syntax: M68K-Syntax. (line 8)
-* M68HC11 addressing modes: M68HC11-Syntax. (line 17)
-* M68HC11 and M68HC12 support: M68HC11-Dependent. (line 6)
-* M68HC11 assembler directive .far: M68HC11-Directives. (line 20)
-* M68HC11 assembler directive .interrupt: M68HC11-Directives. (line 26)
-* M68HC11 assembler directive .mode: M68HC11-Directives. (line 16)
-* M68HC11 assembler directive .relax: M68HC11-Directives. (line 10)
-* M68HC11 assembler directive .xrefb: M68HC11-Directives. (line 31)
-* M68HC11 assembler directives: M68HC11-Directives. (line 6)
-* M68HC11 branch improvement: M68HC11-Branch. (line 6)
-* M68HC11 floating point: M68HC11-Float. (line 6)
-* M68HC11 modifiers: M68HC11-Modifiers. (line 6)
-* M68HC11 opcodes: M68HC11-opcodes. (line 6)
-* M68HC11 options: M68HC11-Opts. (line 6)
-* M68HC11 pseudo-opcodes: M68HC11-Branch. (line 6)
-* M68HC11 syntax: M68HC11-Syntax. (line 6)
-* M68HC12 assembler directives: M68HC11-Directives. (line 6)
-* machine dependencies: Machine Dependencies.
- (line 6)
-* machine directives, ARC: ARC Directives. (line 6)
-* machine directives, ARM: ARM Directives. (line 6)
-* machine directives, H8/300 (none): H8/300 Directives. (line 6)
-* machine directives, i860: Directives-i860. (line 6)
-* machine directives, i960: Directives-i960. (line 6)
-* machine directives, MSP 430: MSP430 Directives. (line 6)
-* machine directives, SH: SH Directives. (line 6)
-* machine directives, SH64: SH64 Directives. (line 9)
-* machine directives, SPARC: Sparc-Directives. (line 6)
-* machine directives, TIC54X: TIC54X-Directives. (line 6)
-* machine directives, TIC6X: TIC6X Directives. (line 6)
-* machine directives, V850: V850 Directives. (line 6)
-* machine directives, VAX: VAX-directives. (line 6)
-* machine directives, x86: i386-Directives. (line 6)
-* machine independent directives: Pseudo Ops. (line 6)
-* machine instructions (not covered): Manual. (line 14)
-* machine-independent syntax: Syntax. (line 6)
-* macro directive: Macro. (line 28)
-* macro directive, TIC54X: TIC54X-Directives. (line 153)
-* macros: Macro. (line 6)
-* macros, count executed: Macro. (line 143)
-* Macros, MSP 430: MSP430-Macros. (line 6)
-* macros, TIC54X: TIC54X-Macros. (line 6)
-* make rules: MD. (line 6)
-* manual, structure and purpose: Manual. (line 6)
-* math builtins, TIC54X: TIC54X-Builtins. (line 6)
-* Maximum number of continuation lines: listing. (line 34)
-* memory references, i386: i386-Memory. (line 6)
-* memory references, x86-64: i386-Memory. (line 6)
-* memory-mapped registers, TIC54X: TIC54X-MMRegs. (line 6)
-* merging text and data sections: R. (line 6)
-* messages from assembler: Errors. (line 6)
-* MicroBlaze architectures: MicroBlaze-Dependent.
- (line 6)
-* MicroBlaze directives: MicroBlaze Directives.
- (line 6)
-* MicroBlaze support: MicroBlaze-Dependent.
- (line 13)
-* minus, permitted arguments: Infix Ops. (line 49)
-* MIPS architecture options: MIPS Opts. (line 29)
-* MIPS big-endian output: MIPS Opts. (line 13)
-* MIPS CPU override: MIPS ISA. (line 18)
-* MIPS debugging directives: MIPS Stabs. (line 6)
-* MIPS DSP Release 1 instruction generation override: MIPS ASE instruction generation overrides.
- (line 21)
-* MIPS DSP Release 2 instruction generation override: MIPS ASE instruction generation overrides.
- (line 26)
-* MIPS ECOFF sections: MIPS Object. (line 6)
-* MIPS endianness: Overview. (line 683)
-* MIPS ISA: Overview. (line 689)
-* MIPS ISA override: MIPS ISA. (line 6)
-* MIPS little-endian output: MIPS Opts. (line 13)
-* MIPS MDMX instruction generation override: MIPS ASE instruction generation overrides.
- (line 16)
-* MIPS MIPS-3D instruction generation override: MIPS ASE instruction generation overrides.
- (line 6)
-* MIPS MT instruction generation override: MIPS ASE instruction generation overrides.
- (line 32)
-* MIPS option stack: MIPS option stack. (line 6)
-* MIPS processor: MIPS-Dependent. (line 6)
-* MIT: M68K-Syntax. (line 6)
-* mlib directive, TIC54X: TIC54X-Directives. (line 159)
-* mlist directive, TIC54X: TIC54X-Directives. (line 164)
-* MMIX assembler directive BSPEC: MMIX-Pseudos. (line 131)
-* MMIX assembler directive BYTE: MMIX-Pseudos. (line 97)
-* MMIX assembler directive ESPEC: MMIX-Pseudos. (line 131)
-* MMIX assembler directive GREG: MMIX-Pseudos. (line 50)
-* MMIX assembler directive IS: MMIX-Pseudos. (line 42)
-* MMIX assembler directive LOC: MMIX-Pseudos. (line 7)
-* MMIX assembler directive LOCAL: MMIX-Pseudos. (line 28)
-* MMIX assembler directive OCTA: MMIX-Pseudos. (line 108)
-* MMIX assembler directive PREFIX: MMIX-Pseudos. (line 120)
-* MMIX assembler directive TETRA: MMIX-Pseudos. (line 108)
-* MMIX assembler directive WYDE: MMIX-Pseudos. (line 108)
-* MMIX assembler directives: MMIX-Pseudos. (line 6)
-* MMIX line comment characters: MMIX-Chars. (line 6)
-* MMIX options: MMIX-Opts. (line 6)
-* MMIX pseudo-op BSPEC: MMIX-Pseudos. (line 131)
-* MMIX pseudo-op BYTE: MMIX-Pseudos. (line 97)
-* MMIX pseudo-op ESPEC: MMIX-Pseudos. (line 131)
-* MMIX pseudo-op GREG: MMIX-Pseudos. (line 50)
-* MMIX pseudo-op IS: MMIX-Pseudos. (line 42)
-* MMIX pseudo-op LOC: MMIX-Pseudos. (line 7)
-* MMIX pseudo-op LOCAL: MMIX-Pseudos. (line 28)
-* MMIX pseudo-op OCTA: MMIX-Pseudos. (line 108)
-* MMIX pseudo-op PREFIX: MMIX-Pseudos. (line 120)
-* MMIX pseudo-op TETRA: MMIX-Pseudos. (line 108)
-* MMIX pseudo-op WYDE: MMIX-Pseudos. (line 108)
-* MMIX pseudo-ops: MMIX-Pseudos. (line 6)
-* MMIX register names: MMIX-Regs. (line 6)
-* MMIX support: MMIX-Dependent. (line 6)
-* mmixal differences: MMIX-mmixal. (line 6)
-* mmregs directive, TIC54X: TIC54X-Directives. (line 169)
-* mmsg directive, TIC54X: TIC54X-Directives. (line 77)
-* MMX, i386: i386-SIMD. (line 6)
-* MMX, x86-64: i386-SIMD. (line 6)
-* mnemonic compatibility, i386: i386-Mnemonics. (line 62)
-* mnemonic suffixes, i386: i386-Syntax. (line 29)
-* mnemonic suffixes, x86-64: i386-Syntax. (line 29)
-* mnemonics for opcodes, VAX: VAX-opcodes. (line 6)
-* mnemonics, AVR: AVR Opcodes. (line 6)
-* mnemonics, D10V: D10V-Opcodes. (line 6)
-* mnemonics, D30V: D30V-Opcodes. (line 6)
-* mnemonics, H8/300: H8/300 Opcodes. (line 6)
-* mnemonics, LM32: LM32 Opcodes. (line 6)
-* mnemonics, SH: SH Opcodes. (line 6)
-* mnemonics, SH64: SH64 Opcodes. (line 6)
-* mnemonics, Z8000: Z8000 Opcodes. (line 6)
-* mnolist directive, TIC54X: TIC54X-Directives. (line 164)
-* Motorola syntax for the 680x0: M68K-Moto-Syntax. (line 6)
-* MOVI instructions, relaxation: Xtensa Immediate Relaxation.
- (line 12)
-* MOVW and MOVT relocations, ARM: ARM-Relocations. (line 20)
-* MRI compatibility mode: M. (line 6)
-* mri directive: MRI. (line 6)
-* MRI mode, temporarily: MRI. (line 6)
-* MSP 430 floating point (IEEE): MSP430 Floating Point.
- (line 6)
-* MSP 430 identifiers: MSP430-Chars. (line 8)
-* MSP 430 line comment character: MSP430-Chars. (line 6)
-* MSP 430 machine directives: MSP430 Directives. (line 6)
-* MSP 430 macros: MSP430-Macros. (line 6)
-* MSP 430 opcodes: MSP430 Opcodes. (line 6)
-* MSP 430 options (none): MSP430 Options. (line 6)
-* MSP 430 profiling capability: MSP430 Profiling Capability.
- (line 6)
-* MSP 430 register names: MSP430-Regs. (line 6)
-* MSP 430 support: MSP430-Dependent. (line 6)
-* MSP430 Assembler Extensions: MSP430-Ext. (line 6)
-* mul instruction, i386: i386-Notes. (line 6)
-* mul instruction, x86-64: i386-Notes. (line 6)
-* name: Z8000 Directives. (line 18)
-* named section: Section. (line 6)
-* named sections: Ld Sections. (line 8)
-* names, symbol: Symbol Names. (line 6)
-* naming object file: o. (line 6)
-* new page, in listings: Eject. (line 6)
-* newblock directive, TIC54X: TIC54X-Directives. (line 175)
-* newline (\n): Strings. (line 21)
-* newline, required at file end: Statements. (line 13)
-* no-absolute-literals directive: Absolute Literals Directive.
- (line 6)
-* no-longcalls directive: Longcalls Directive. (line 6)
-* no-schedule directive: Schedule Directive. (line 6)
-* no-transform directive: Transform Directive. (line 6)
-* nolist directive: Nolist. (line 6)
-* nolist directive, TIC54X: TIC54X-Directives. (line 131)
-* NOP pseudo op, ARM: ARM Opcodes. (line 9)
-* notes for Alpha: Alpha Notes. (line 6)
-* null-terminated strings: Asciz. (line 6)
-* number constants: Numbers. (line 6)
-* number of macros executed: Macro. (line 143)
-* numbered subsections: Sub-Sections. (line 6)
-* numbers, 16-bit: hword. (line 6)
-* numeric values: Expressions. (line 6)
-* nword directive, SPARC: Sparc-Directives. (line 20)
-* object attributes: Object Attributes. (line 6)
-* object file: Object. (line 6)
-* object file format: Object Formats. (line 6)
-* object file name: o. (line 6)
-* object file, after errors: Z. (line 6)
-* obsolescent directives: Deprecated. (line 6)
-* octa directive: Octa. (line 6)
-* octal character code (\DDD): Strings. (line 30)
-* octal integers: Integers. (line 9)
-* offset directive, V850: V850 Directives. (line 6)
-* opcode mnemonics, VAX: VAX-opcodes. (line 6)
-* opcode names, Xtensa: Xtensa Opcodes. (line 6)
-* opcode summary, AVR: AVR Opcodes. (line 6)
-* opcode summary, D10V: D10V-Opcodes. (line 6)
-* opcode summary, D30V: D30V-Opcodes. (line 6)
-* opcode summary, H8/300: H8/300 Opcodes. (line 6)
-* opcode summary, LM32: LM32 Opcodes. (line 6)
-* opcode summary, SH: SH Opcodes. (line 6)
-* opcode summary, SH64: SH64 Opcodes. (line 6)
-* opcode summary, Z8000: Z8000 Opcodes. (line 6)
-* opcodes for ARC: ARC Opcodes. (line 6)
-* opcodes for ARM: ARM Opcodes. (line 6)
-* opcodes for MSP 430: MSP430 Opcodes. (line 6)
-* opcodes for V850: V850 Opcodes. (line 6)
-* opcodes, i860: Opcodes for i860. (line 6)
-* opcodes, i960: Opcodes for i960. (line 6)
-* opcodes, M680x0: M68K-opcodes. (line 6)
-* opcodes, M68HC11: M68HC11-opcodes. (line 6)
-* operand delimiters, i386: i386-Syntax. (line 15)
-* operand delimiters, x86-64: i386-Syntax. (line 15)
-* operand notation, VAX: VAX-operands. (line 6)
-* operands in expressions: Arguments. (line 6)
-* operator precedence: Infix Ops. (line 11)
-* operators, in expressions: Operators. (line 6)
-* operators, permitted arguments: Infix Ops. (line 6)
-* optimization, D10V: Overview. (line 462)
-* optimization, D30V: Overview. (line 467)
-* optimizations: Xtensa Optimizations.
- (line 6)
-* option directive, ARC: ARC Directives. (line 162)
-* option directive, TIC54X: TIC54X-Directives. (line 179)
-* option summary: Overview. (line 6)
-* options for Alpha: Alpha Options. (line 6)
-* options for ARC (none): ARC Options. (line 6)
-* options for ARM (none): ARM Options. (line 6)
-* options for AVR (none): AVR Options. (line 6)
-* options for Blackfin (none): Blackfin Options. (line 6)
-* options for i386: i386-Options. (line 6)
-* options for IA-64: IA-64 Options. (line 6)
-* options for LM32 (none): LM32 Options. (line 6)
-* options for MSP430 (none): MSP430 Options. (line 6)
-* options for PDP-11: PDP-11-Options. (line 6)
-* options for PowerPC: PowerPC-Opts. (line 6)
-* options for s390: s390 Options. (line 6)
-* options for SCORE: SCORE-Opts. (line 6)
-* options for SPARC: Sparc-Opts. (line 6)
-* options for TIC6X: TIC6X Options. (line 6)
-* options for V850 (none): V850 Options. (line 6)
-* options for VAX/VMS: VAX-Opts. (line 42)
-* options for x86-64: i386-Options. (line 6)
-* options for Z80: Z80 Options. (line 6)
-* options, all versions of assembler: Invoking. (line 6)
-* options, command line: Command Line. (line 13)
-* options, CRIS: CRIS-Opts. (line 6)
-* options, D10V: D10V-Opts. (line 6)
-* options, D30V: D30V-Opts. (line 6)
-* options, H8/300: H8/300 Options. (line 6)
-* options, i960: Options-i960. (line 6)
-* options, IP2K: IP2K-Opts. (line 6)
-* options, M32C: M32C-Opts. (line 6)
-* options, M32R: M32R-Opts. (line 6)
-* options, M680x0: M68K-Opts. (line 6)
-* options, M68HC11: M68HC11-Opts. (line 6)
-* options, MMIX: MMIX-Opts. (line 6)
-* options, PJ: PJ Options. (line 6)
-* options, RX: RX-Opts. (line 6)
-* options, SH: SH Options. (line 6)
-* options, SH64: SH64 Options. (line 6)
-* options, TIC54X: TIC54X-Opts. (line 6)
-* options, Z8000: Z8000 Options. (line 6)
-* org directive: Org. (line 6)
-* other attribute, of a.out symbol: Symbol Other. (line 6)
-* output file: Object. (line 6)
-* p2align directive: P2align. (line 6)
-* p2alignl directive: P2align. (line 28)
-* p2alignw directive: P2align. (line 28)
-* padding the location counter: Align. (line 6)
-* padding the location counter given a power of two: P2align. (line 6)
-* padding the location counter given number of bytes: Balign. (line 6)
-* page, in listings: Eject. (line 6)
-* paper size, for listings: Psize. (line 6)
-* paths for .include: I. (line 6)
-* patterns, writing in memory: Fill. (line 6)
-* PDP-11 comments: PDP-11-Syntax. (line 16)
-* PDP-11 floating-point register syntax: PDP-11-Syntax. (line 13)
-* PDP-11 general-purpose register syntax: PDP-11-Syntax. (line 10)
-* PDP-11 instruction naming: PDP-11-Mnemonics. (line 6)
-* PDP-11 support: PDP-11-Dependent. (line 6)
-* PDP-11 syntax: PDP-11-Syntax. (line 6)
-* PIC code generation for ARM: ARM Options. (line 161)
-* PIC code generation for M32R: M32R-Opts. (line 42)
-* PIC selection, MIPS: MIPS Opts. (line 21)
-* PJ endianness: Overview. (line 590)
-* PJ options: PJ Options. (line 6)
-* PJ support: PJ-Dependent. (line 6)
-* plus, permitted arguments: Infix Ops. (line 44)
-* popsection directive: PopSection. (line 6)
-* Position-independent code, CRIS: CRIS-Opts. (line 27)
-* Position-independent code, symbols in, CRIS: CRIS-Pic. (line 6)
-* PowerPC architectures: PowerPC-Opts. (line 6)
-* PowerPC directives: PowerPC-Pseudo. (line 6)
-* PowerPC options: PowerPC-Opts. (line 6)
-* PowerPC support: PPC-Dependent. (line 6)
-* precedence of operators: Infix Ops. (line 11)
-* precision, floating point: Flonums. (line 6)
-* prefix operators: Prefix Ops. (line 6)
-* prefixes, i386: i386-Prefixes. (line 6)
-* preprocessing: Preprocessing. (line 6)
-* preprocessing, turning on and off: Preprocessing. (line 26)
-* previous directive: Previous. (line 6)
-* primary attributes, COFF symbols: COFF Symbols. (line 13)
-* print directive: Print. (line 6)
-* proc directive, SPARC: Sparc-Directives. (line 25)
-* profiler directive, MSP 430: MSP430 Directives. (line 22)
-* profiling capability for MSP 430: MSP430 Profiling Capability.
- (line 6)
-* protected directive: Protected. (line 6)
-* pseudo-op .arch, CRIS: CRIS-Pseudos. (line 45)
-* pseudo-op .dword, CRIS: CRIS-Pseudos. (line 12)
-* pseudo-op .syntax, CRIS: CRIS-Pseudos. (line 17)
-* pseudo-op BSPEC, MMIX: MMIX-Pseudos. (line 131)
-* pseudo-op BYTE, MMIX: MMIX-Pseudos. (line 97)
-* pseudo-op ESPEC, MMIX: MMIX-Pseudos. (line 131)
-* pseudo-op GREG, MMIX: MMIX-Pseudos. (line 50)
-* pseudo-op IS, MMIX: MMIX-Pseudos. (line 42)
-* pseudo-op LOC, MMIX: MMIX-Pseudos. (line 7)
-* pseudo-op LOCAL, MMIX: MMIX-Pseudos. (line 28)
-* pseudo-op OCTA, MMIX: MMIX-Pseudos. (line 108)
-* pseudo-op PREFIX, MMIX: MMIX-Pseudos. (line 120)
-* pseudo-op TETRA, MMIX: MMIX-Pseudos. (line 108)
-* pseudo-op WYDE, MMIX: MMIX-Pseudos. (line 108)
-* pseudo-opcodes, M680x0: M68K-Branch. (line 6)
-* pseudo-opcodes, M68HC11: M68HC11-Branch. (line 6)
-* pseudo-ops for branch, VAX: VAX-branch. (line 6)
-* pseudo-ops, CRIS: CRIS-Pseudos. (line 6)
-* pseudo-ops, machine independent: Pseudo Ops. (line 6)
-* pseudo-ops, MMIX: MMIX-Pseudos. (line 6)
-* psize directive: Psize. (line 6)
-* PSR bits: IA-64-Bits. (line 6)
-* pstring directive, TIC54X: TIC54X-Directives. (line 208)
-* psw register, V850: V850-Regs. (line 116)
-* purgem directive: Purgem. (line 6)
-* purpose of GNU assembler: GNU Assembler. (line 12)
-* pushsection directive: PushSection. (line 6)
-* quad directive: Quad. (line 6)
-* quad directive, i386: i386-Float. (line 21)
-* quad directive, x86-64: i386-Float. (line 21)
-* real-mode code, i386: i386-16bit. (line 6)
-* ref directive, TIC54X: TIC54X-Directives. (line 103)
-* register directive, SPARC: Sparc-Directives. (line 29)
-* register names, Alpha: Alpha-Regs. (line 6)
-* register names, ARC: ARC-Regs. (line 6)
-* register names, ARM: ARM-Regs. (line 6)
-* register names, AVR: AVR-Regs. (line 6)
-* register names, CRIS: CRIS-Regs. (line 6)
-* register names, H8/300: H8/300-Regs. (line 6)
-* register names, IA-64: IA-64-Regs. (line 6)
-* register names, LM32: LM32-Regs. (line 6)
-* register names, MMIX: MMIX-Regs. (line 6)
-* register names, MSP 430: MSP430-Regs. (line 6)
-* register names, Sparc: Sparc-Regs. (line 6)
-* register names, V850: V850-Regs. (line 6)
-* register names, VAX: VAX-operands. (line 17)
-* register names, Xtensa: Xtensa Registers. (line 6)
-* register names, Z80: Z80-Regs. (line 6)
-* register naming, s390: s390 Register. (line 6)
-* register operands, i386: i386-Syntax. (line 15)
-* register operands, x86-64: i386-Syntax. (line 15)
-* registers, D10V: D10V-Regs. (line 6)
-* registers, D30V: D30V-Regs. (line 6)
-* registers, i386: i386-Regs. (line 6)
-* registers, SH: SH-Regs. (line 6)
-* registers, SH64: SH64-Regs. (line 6)
-* registers, TIC54X memory-mapped: TIC54X-MMRegs. (line 6)
-* registers, x86-64: i386-Regs. (line 6)
-* registers, Z8000: Z8000-Regs. (line 6)
-* relaxation: Xtensa Relaxation. (line 6)
-* relaxation of ADDI instructions: Xtensa Immediate Relaxation.
- (line 43)
-* relaxation of branch instructions: Xtensa Branch Relaxation.
- (line 6)
-* relaxation of call instructions: Xtensa Call Relaxation.
- (line 6)
-* relaxation of immediate fields: Xtensa Immediate Relaxation.
- (line 6)
-* relaxation of L16SI instructions: Xtensa Immediate Relaxation.
- (line 23)
-* relaxation of L16UI instructions: Xtensa Immediate Relaxation.
- (line 23)
-* relaxation of L32I instructions: Xtensa Immediate Relaxation.
- (line 23)
-* relaxation of L8UI instructions: Xtensa Immediate Relaxation.
- (line 23)
-* relaxation of MOVI instructions: Xtensa Immediate Relaxation.
- (line 12)
-* reloc directive: Reloc. (line 6)
-* relocation: Sections. (line 6)
-* relocation example: Ld Sections. (line 40)
-* relocations, Alpha: Alpha-Relocs. (line 6)
-* relocations, Sparc: Sparc-Relocs. (line 6)
-* repeat prefixes, i386: i386-Prefixes. (line 44)
-* reporting bugs in assembler: Reporting Bugs. (line 6)
-* rept directive: Rept. (line 6)
-* reserve directive, SPARC: Sparc-Directives. (line 39)
-* return instructions, i386: i386-Syntax. (line 41)
-* return instructions, x86-64: i386-Syntax. (line 41)
-* REX prefixes, i386: i386-Prefixes. (line 46)
-* rsect: Z8000 Directives. (line 52)
-* RX assembler directive .3byte: RX-Directives. (line 9)
-* RX assembler directives: RX-Directives. (line 6)
-* RX floating point: RX-Float. (line 6)
-* RX modifiers: RX-Modifiers. (line 6)
-* RX options: RX-Opts. (line 6)
-* RX support: RX-Dependent. (line 6)
-* s390 floating point: s390 Floating Point. (line 6)
-* s390 instruction aliases: s390 Aliases. (line 6)
-* s390 instruction formats: s390 Formats. (line 6)
-* s390 instruction marker: s390 Instruction Marker.
- (line 6)
-* s390 instruction mnemonics: s390 Mnemonics. (line 6)
-* s390 instruction operand modifier: s390 Operand Modifier.
- (line 6)
-* s390 instruction operands: s390 Operands. (line 6)
-* s390 instruction syntax: s390 Syntax. (line 6)
-* s390 line comment character: s390 Characters. (line 6)
-* s390 literal pool entries: s390 Literal Pool Entries.
- (line 6)
-* s390 options: s390 Options. (line 6)
-* s390 register naming: s390 Register. (line 6)
-* s390 support: S/390-Dependent. (line 6)
-* sblock directive, TIC54X: TIC54X-Directives. (line 182)
-* sbttl directive: Sbttl. (line 6)
-* schedule directive: Schedule Directive. (line 6)
-* scl directive: Scl. (line 6)
-* SCORE architectures: SCORE-Opts. (line 6)
-* SCORE directives: SCORE-Pseudo. (line 6)
-* SCORE options: SCORE-Opts. (line 6)
-* SCORE processor: SCORE-Dependent. (line 6)
-* sdaoff pseudo-op, V850: V850 Opcodes. (line 65)
-* search path for .include: I. (line 6)
-* sect directive, MSP 430: MSP430 Directives. (line 18)
-* sect directive, TIC54X: TIC54X-Directives. (line 188)
-* section directive (COFF version): Section. (line 16)
-* section directive (ELF version): Section. (line 73)
-* section directive, V850: V850 Directives. (line 9)
-* section override prefixes, i386: i386-Prefixes. (line 23)
-* Section Stack <1>: SubSection. (line 6)
-* Section Stack <2>: PopSection. (line 6)
-* Section Stack <3>: Section. (line 68)
-* Section Stack <4>: Previous. (line 6)
-* Section Stack: PushSection. (line 6)
-* section-relative addressing: Secs Background. (line 68)
-* sections: Sections. (line 6)
-* sections in messages, internal: As Sections. (line 6)
-* sections, i386: i386-Syntax. (line 47)
-* sections, named: Ld Sections. (line 8)
-* sections, x86-64: i386-Syntax. (line 47)
-* seg directive, SPARC: Sparc-Directives. (line 44)
-* segm: Z8000 Directives. (line 10)
-* set directive: Set. (line 6)
-* set directive, TIC54X: TIC54X-Directives. (line 191)
-* SH addressing modes: SH-Addressing. (line 6)
-* SH floating point (IEEE): SH Floating Point. (line 6)
-* SH line comment character: SH-Chars. (line 6)
-* SH line separator: SH-Chars. (line 8)
-* SH machine directives: SH Directives. (line 6)
-* SH opcode summary: SH Opcodes. (line 6)
-* SH options: SH Options. (line 6)
-* SH registers: SH-Regs. (line 6)
-* SH support: SH-Dependent. (line 6)
-* SH64 ABI options: SH64 Options. (line 29)
-* SH64 addressing modes: SH64-Addressing. (line 6)
-* SH64 ISA options: SH64 Options. (line 6)
-* SH64 line comment character: SH64-Chars. (line 6)
-* SH64 line separator: SH64-Chars. (line 8)
-* SH64 machine directives: SH64 Directives. (line 9)
-* SH64 opcode summary: SH64 Opcodes. (line 6)
-* SH64 options: SH64 Options. (line 6)
-* SH64 registers: SH64-Regs. (line 6)
-* SH64 support: SH64-Dependent. (line 6)
-* shigh directive, M32R: M32R-Directives. (line 26)
-* short directive: Short. (line 6)
-* short directive, ARC: ARC Directives. (line 171)
-* short directive, TIC54X: TIC54X-Directives. (line 111)
-* SIMD, i386: i386-SIMD. (line 6)
-* SIMD, x86-64: i386-SIMD. (line 6)
-* single character constant: Chars. (line 6)
-* single directive: Single. (line 6)
-* single directive, i386: i386-Float. (line 14)
-* single directive, x86-64: i386-Float. (line 14)
-* single quote, Z80: Z80-Chars. (line 13)
-* sixteen bit integers: hword. (line 6)
-* sixteen byte integer: Octa. (line 6)
-* size directive (COFF version): Size. (line 11)
-* size directive (ELF version): Size. (line 19)
-* size modifiers, D10V: D10V-Size. (line 6)
-* size modifiers, D30V: D30V-Size. (line 6)
-* size modifiers, M680x0: M68K-Syntax. (line 8)
-* size prefixes, i386: i386-Prefixes. (line 27)
-* size suffixes, H8/300: H8/300 Opcodes. (line 163)
-* size, translations, Sparc: Sparc-Size-Translations.
- (line 6)
-* sizes operands, i386: i386-Syntax. (line 29)
-* sizes operands, x86-64: i386-Syntax. (line 29)
-* skip directive: Skip. (line 6)
-* skip directive, M680x0: M68K-Directives. (line 19)
-* skip directive, SPARC: Sparc-Directives. (line 48)
-* sleb128 directive: Sleb128. (line 6)
-* small objects, MIPS ECOFF: MIPS Object. (line 11)
-* SmartMIPS instruction generation override: MIPS ASE instruction generation overrides.
- (line 11)
-* SOM symbol attributes: SOM Symbols. (line 6)
-* source program: Input Files. (line 6)
-* source, destination operands; i386: i386-Syntax. (line 22)
-* source, destination operands; x86-64: i386-Syntax. (line 22)
-* sp register: Xtensa Registers. (line 6)
-* sp register, V850: V850-Regs. (line 14)
-* space directive: Space. (line 6)
-* space directive, TIC54X: TIC54X-Directives. (line 196)
-* space used, maximum for assembly: statistics. (line 6)
-* SPARC architectures: Sparc-Opts. (line 6)
-* Sparc constants: Sparc-Constants. (line 6)
-* SPARC data alignment: Sparc-Aligned-Data. (line 6)
-* SPARC floating point (IEEE): Sparc-Float. (line 6)
-* Sparc line comment character: Sparc-Chars. (line 6)
-* Sparc line separator: Sparc-Chars. (line 8)
-* SPARC machine directives: Sparc-Directives. (line 6)
-* SPARC options: Sparc-Opts. (line 6)
-* Sparc registers: Sparc-Regs. (line 6)
-* Sparc relocations: Sparc-Relocs. (line 6)
-* Sparc size translations: Sparc-Size-Translations.
- (line 6)
-* SPARC support: Sparc-Dependent. (line 6)
-* SPARC syntax: Sparc-Aligned-Data. (line 21)
-* special characters, ARC: ARC-Chars. (line 6)
-* special characters, M680x0: M68K-Chars. (line 6)
-* special purpose registers, MSP 430: MSP430-Regs. (line 11)
-* sslist directive, TIC54X: TIC54X-Directives. (line 203)
-* ssnolist directive, TIC54X: TIC54X-Directives. (line 203)
-* stabd directive: Stab. (line 38)
-* stabn directive: Stab. (line 48)
-* stabs directive: Stab. (line 51)
-* stabX directives: Stab. (line 6)
-* standard assembler sections: Secs Background. (line 27)
-* standard input, as input file: Command Line. (line 10)
-* statement separator character: Statements. (line 6)
-* statement separator, Alpha: Alpha-Chars. (line 8)
-* statement separator, ARM: ARM-Chars. (line 10)
-* statement separator, AVR: AVR-Chars. (line 10)
-* statement separator, H8/300: H8/300-Chars. (line 8)
-* statement separator, IA-64: IA-64-Chars. (line 8)
-* statement separator, SH: SH-Chars. (line 8)
-* statement separator, SH64: SH64-Chars. (line 8)
-* statement separator, Sparc: Sparc-Chars. (line 8)
-* statement separator, TIC6X: TIC6X Syntax. (line 10)
-* statement separator, Z8000: Z8000-Chars. (line 8)
-* statements, structure of: Statements. (line 6)
-* statistics, about assembly: statistics. (line 6)
-* stopping the assembly: Abort. (line 6)
-* string constants: Strings. (line 6)
-* string directive: String. (line 8)
-* string directive on HPPA: HPPA Directives. (line 137)
-* string directive, TIC54X: TIC54X-Directives. (line 208)
-* string literals: Ascii. (line 6)
-* string, copying to object file: String. (line 8)
-* string16 directive: String. (line 8)
-* string16, copying to object file: String. (line 8)
-* string32 directive: String. (line 8)
-* string32, copying to object file: String. (line 8)
-* string64 directive: String. (line 8)
-* string64, copying to object file: String. (line 8)
-* string8 directive: String. (line 8)
-* string8, copying to object file: String. (line 8)
-* struct directive: Struct. (line 6)
-* struct directive, TIC54X: TIC54X-Directives. (line 216)
-* structure debugging, COFF: Tag. (line 6)
-* sub-instruction ordering, D10V: D10V-Chars. (line 6)
-* sub-instruction ordering, D30V: D30V-Chars. (line 6)
-* sub-instructions, D10V: D10V-Subs. (line 6)
-* sub-instructions, D30V: D30V-Subs. (line 6)
-* subexpressions: Arguments. (line 24)
-* subsection directive: SubSection. (line 6)
-* subsym builtins, TIC54X: TIC54X-Macros. (line 16)
-* subtitles for listings: Sbttl. (line 6)
-* subtraction, permitted arguments: Infix Ops. (line 49)
-* summary of options: Overview. (line 6)
-* support: HPPA-Dependent. (line 6)
-* supporting files, including: Include. (line 6)
-* suppressing warnings: W. (line 11)
-* sval: Z8000 Directives. (line 33)
-* symbol attributes: Symbol Attributes. (line 6)
-* symbol attributes, a.out: a.out Symbols. (line 6)
-* symbol attributes, COFF: COFF Symbols. (line 6)
-* symbol attributes, SOM: SOM Symbols. (line 6)
-* symbol descriptor, COFF: Desc. (line 6)
-* symbol modifiers <1>: AVR-Modifiers. (line 12)
-* symbol modifiers <2>: M68HC11-Modifiers. (line 12)
-* symbol modifiers <3>: M32C-Modifiers. (line 11)
-* symbol modifiers <4>: LM32-Modifiers. (line 12)
-* symbol modifiers: RX-Modifiers. (line 11)
-* symbol names: Symbol Names. (line 6)
-* symbol names, $ in <1>: D30V-Chars. (line 63)
-* symbol names, $ in <2>: SH64-Chars. (line 10)
-* symbol names, $ in <3>: SH-Chars. (line 10)
-* symbol names, $ in: D10V-Chars. (line 46)
-* symbol names, local: Symbol Names. (line 22)
-* symbol names, temporary: Symbol Names. (line 35)
-* symbol storage class (COFF): Scl. (line 6)
-* symbol type: Symbol Type. (line 6)
-* symbol type, COFF: Type. (line 11)
-* symbol type, ELF: Type. (line 22)
-* symbol value: Symbol Value. (line 6)
-* symbol value, setting: Set. (line 6)
-* symbol values, assigning: Setting Symbols. (line 6)
-* symbol versioning: Symver. (line 6)
-* symbol, common: Comm. (line 6)
-* symbol, making visible to linker: Global. (line 6)
-* symbolic debuggers, information for: Stab. (line 6)
-* symbols: Symbols. (line 6)
-* Symbols in position-independent code, CRIS: CRIS-Pic. (line 6)
-* symbols with uppercase, VAX/VMS: VAX-Opts. (line 42)
-* symbols, assigning values to: Equ. (line 6)
-* Symbols, built-in, CRIS: CRIS-Symbols. (line 6)
-* Symbols, CRIS, built-in: CRIS-Symbols. (line 6)
-* symbols, local common: Lcomm. (line 6)
-* symver directive: Symver. (line 6)
-* syntax compatibility, i386: i386-Syntax. (line 6)
-* syntax compatibility, x86-64: i386-Syntax. (line 6)
-* syntax, AVR: AVR-Modifiers. (line 6)
-* syntax, Blackfin: Blackfin Syntax. (line 6)
-* syntax, D10V: D10V-Syntax. (line 6)
-* syntax, D30V: D30V-Syntax. (line 6)
-* syntax, LM32: LM32-Modifiers. (line 6)
-* syntax, M32C: M32C-Modifiers. (line 6)
-* syntax, M680x0: M68K-Syntax. (line 8)
-* syntax, M68HC11 <1>: M68HC11-Syntax. (line 6)
-* syntax, M68HC11: M68HC11-Modifiers. (line 6)
-* syntax, machine-independent: Syntax. (line 6)
-* syntax, RX: RX-Modifiers. (line 6)
-* syntax, SPARC: Sparc-Aligned-Data. (line 21)
-* syntax, Xtensa assembler: Xtensa Syntax. (line 6)
-* sysproc directive, i960: Directives-i960. (line 37)
-* tab (\t): Strings. (line 27)
-* tab directive, TIC54X: TIC54X-Directives. (line 247)
-* tag directive: Tag. (line 6)
-* tag directive, TIC54X: TIC54X-Directives. (line 216)
-* tdaoff pseudo-op, V850: V850 Opcodes. (line 81)
-* temporary symbol names: Symbol Names. (line 35)
-* text and data sections, joining: R. (line 6)
-* text directive: Text. (line 6)
-* text section: Ld Sections. (line 9)
-* tfloat directive, i386: i386-Float. (line 14)
-* tfloat directive, x86-64: i386-Float. (line 14)
-* Thumb support: ARM-Dependent. (line 6)
-* TIC54X builtin math functions: TIC54X-Builtins. (line 6)
-* TIC54X machine directives: TIC54X-Directives. (line 6)
-* TIC54X memory-mapped registers: TIC54X-MMRegs. (line 6)
-* TIC54X options: TIC54X-Opts. (line 6)
-* TIC54X subsym builtins: TIC54X-Macros. (line 16)
-* TIC54X support: TIC54X-Dependent. (line 6)
-* TIC54X-specific macros: TIC54X-Macros. (line 6)
-* TIC6X big-endian output: TIC6X Options. (line 58)
-* TIC6X line comment character: TIC6X Syntax. (line 6)
-* TIC6X line separator: TIC6X Syntax. (line 10)
-* TIC6X little-endian output: TIC6X Options. (line 58)
-* TIC6X machine directives: TIC6X Directives. (line 6)
-* TIC6X options: TIC6X Options. (line 6)
-* TIC6X support: TIC6X-Dependent. (line 6)
-* time, total for assembly: statistics. (line 6)
-* title directive: Title. (line 6)
-* TMS320C6X support: TIC6X-Dependent. (line 6)
-* tp register, V850: V850-Regs. (line 20)
-* transform directive: Transform Directive. (line 6)
-* trusted compiler: f. (line 6)
-* turning preprocessing on and off: Preprocessing. (line 26)
-* type directive (COFF version): Type. (line 11)
-* type directive (ELF version): Type. (line 22)
-* type of a symbol: Symbol Type. (line 6)
-* ualong directive, SH: SH Directives. (line 6)
-* uaword directive, SH: SH Directives. (line 6)
-* ubyte directive, TIC54X: TIC54X-Directives. (line 36)
-* uchar directive, TIC54X: TIC54X-Directives. (line 36)
-* uhalf directive, TIC54X: TIC54X-Directives. (line 111)
-* uint directive, TIC54X: TIC54X-Directives. (line 111)
-* uleb128 directive: Uleb128. (line 6)
-* ulong directive, TIC54X: TIC54X-Directives. (line 135)
-* undefined section: Ld Sections. (line 36)
-* union directive, TIC54X: TIC54X-Directives. (line 250)
-* unsegm: Z8000 Directives. (line 14)
-* usect directive, TIC54X: TIC54X-Directives. (line 262)
-* ushort directive, TIC54X: TIC54X-Directives. (line 111)
-* uword directive, TIC54X: TIC54X-Directives. (line 111)
-* V850 command line options: V850 Options. (line 9)
-* V850 floating point (IEEE): V850 Floating Point. (line 6)
-* V850 line comment character: V850-Chars. (line 6)
-* V850 machine directives: V850 Directives. (line 6)
-* V850 opcodes: V850 Opcodes. (line 6)
-* V850 options (none): V850 Options. (line 6)
-* V850 register names: V850-Regs. (line 6)
-* V850 support: V850-Dependent. (line 6)
-* val directive: Val. (line 6)
-* value attribute, COFF: Val. (line 6)
-* value of a symbol: Symbol Value. (line 6)
-* var directive, TIC54X: TIC54X-Directives. (line 272)
-* VAX bitfields not supported: VAX-no. (line 6)
-* VAX branch improvement: VAX-branch. (line 6)
-* VAX command-line options ignored: VAX-Opts. (line 6)
-* VAX displacement sizing character: VAX-operands. (line 12)
-* VAX floating point: VAX-float. (line 6)
-* VAX immediate character: VAX-operands. (line 6)
-* VAX indirect character: VAX-operands. (line 9)
-* VAX machine directives: VAX-directives. (line 6)
-* VAX opcode mnemonics: VAX-opcodes. (line 6)
-* VAX operand notation: VAX-operands. (line 6)
-* VAX register names: VAX-operands. (line 17)
-* VAX support: Vax-Dependent. (line 6)
-* Vax-11 C compatibility: VAX-Opts. (line 42)
-* VAX/VMS options: VAX-Opts. (line 42)
-* version directive: Version. (line 6)
-* version directive, TIC54X: TIC54X-Directives. (line 276)
-* version of assembler: v. (line 6)
-* versions of symbols: Symver. (line 6)
-* visibility <1>: Internal. (line 6)
-* visibility <2>: Hidden. (line 6)
-* visibility: Protected. (line 6)
-* VMS (VAX) options: VAX-Opts. (line 42)
-* vtable_entry directive: VTableEntry. (line 6)
-* vtable_inherit directive: VTableInherit. (line 6)
-* warning directive: Warning. (line 6)
-* warning for altered difference tables: K. (line 6)
-* warning messages: Errors. (line 6)
-* warnings, causing error: W. (line 16)
-* warnings, M32R: M32R-Warnings. (line 6)
-* warnings, suppressing: W. (line 11)
-* warnings, switching on: W. (line 19)
-* weak directive: Weak. (line 6)
-* weakref directive: Weakref. (line 6)
-* whitespace: Whitespace. (line 6)
-* whitespace, removed by preprocessor: Preprocessing. (line 7)
-* wide floating point directives, VAX: VAX-directives. (line 10)
-* width directive, TIC54X: TIC54X-Directives. (line 127)
-* Width of continuation lines of disassembly output: listing. (line 21)
-* Width of first line disassembly output: listing. (line 16)
-* Width of source line output: listing. (line 28)
-* wmsg directive, TIC54X: TIC54X-Directives. (line 77)
-* word directive: Word. (line 6)
-* word directive, ARC: ARC Directives. (line 174)
-* word directive, H8/300: H8/300 Directives. (line 6)
-* word directive, i386: i386-Float. (line 21)
-* word directive, SPARC: Sparc-Directives. (line 51)
-* word directive, TIC54X: TIC54X-Directives. (line 111)
-* word directive, x86-64: i386-Float. (line 21)
-* writing patterns in memory: Fill. (line 6)
-* wval: Z8000 Directives. (line 24)
-* x86 machine directives: i386-Directives. (line 6)
-* x86-64 arch directive: i386-Arch. (line 6)
-* x86-64 att_syntax pseudo op: i386-Syntax. (line 6)
-* x86-64 conversion instructions: i386-Mnemonics. (line 37)
-* x86-64 floating point: i386-Float. (line 6)
-* x86-64 immediate operands: i386-Syntax. (line 15)
-* x86-64 instruction naming: i386-Mnemonics. (line 6)
-* x86-64 intel_syntax pseudo op: i386-Syntax. (line 6)
-* x86-64 jump optimization: i386-Jumps. (line 6)
-* x86-64 jump, call, return: i386-Syntax. (line 41)
-* x86-64 jump/call operands: i386-Syntax. (line 15)
-* x86-64 memory references: i386-Memory. (line 6)
-* x86-64 options: i386-Options. (line 6)
-* x86-64 register operands: i386-Syntax. (line 15)
-* x86-64 registers: i386-Regs. (line 6)
-* x86-64 sections: i386-Syntax. (line 47)
-* x86-64 size suffixes: i386-Syntax. (line 29)
-* x86-64 source, destination operands: i386-Syntax. (line 22)
-* x86-64 support: i386-Dependent. (line 6)
-* x86-64 syntax compatibility: i386-Syntax. (line 6)
-* xfloat directive, TIC54X: TIC54X-Directives. (line 64)
-* xlong directive, TIC54X: TIC54X-Directives. (line 135)
-* Xtensa architecture: Xtensa-Dependent. (line 6)
-* Xtensa assembler syntax: Xtensa Syntax. (line 6)
-* Xtensa directives: Xtensa Directives. (line 6)
-* Xtensa opcode names: Xtensa Opcodes. (line 6)
-* Xtensa register names: Xtensa Registers. (line 6)
-* xword directive, SPARC: Sparc-Directives. (line 55)
-* Z80 $: Z80-Chars. (line 8)
-* Z80 ': Z80-Chars. (line 13)
-* Z80 floating point: Z80 Floating Point. (line 6)
-* Z80 line comment character: Z80-Chars. (line 6)
-* Z80 options: Z80 Options. (line 6)
-* Z80 registers: Z80-Regs. (line 6)
-* Z80 support: Z80-Dependent. (line 6)
-* Z80 Syntax: Z80 Options. (line 47)
-* Z80, \: Z80-Chars. (line 11)
-* Z80, case sensitivity: Z80-Case. (line 6)
-* Z80-only directives: Z80 Directives. (line 9)
-* Z800 addressing modes: Z8000-Addressing. (line 6)
-* Z8000 directives: Z8000 Directives. (line 6)
-* Z8000 line comment character: Z8000-Chars. (line 6)
-* Z8000 line separator: Z8000-Chars. (line 8)
-* Z8000 opcode summary: Z8000 Opcodes. (line 6)
-* Z8000 options: Z8000 Options. (line 6)
-* Z8000 registers: Z8000-Regs. (line 6)
-* Z8000 support: Z8000-Dependent. (line 6)
-* zdaoff pseudo-op, V850: V850 Opcodes. (line 99)
-* zero register, V850: V850-Regs. (line 7)
-* zero-terminated strings: Asciz. (line 6)
-
-
-
-Tag Table:
-Node: Top913
-Node: Overview1899
-Node: Manual34738
-Node: GNU Assembler35682
-Node: Object Formats36853
-Node: Command Line37305
-Node: Input Files38392
-Node: Object40373
-Node: Errors41269
-Node: Invoking42464
-Node: a44419
-Node: alternate46330
-Node: D46502
-Node: f46735
-Node: I47243
-Node: K47787
-Node: L48091
-Node: listing48830
-Node: M50489
-Node: MD54890
-Node: o55316
-Node: R55771
-Node: statistics56801
-Node: traditional-format57208
-Node: v57681
-Node: W57956
-Node: Z58863
-Node: Syntax59385
-Node: Preprocessing59976
-Node: Whitespace61539
-Node: Comments61935
-Node: Symbol Intro64171
-Node: Statements64861
-Node: Constants66782
-Node: Characters67413
-Node: Strings67915
-Node: Chars70081
-Node: Numbers70835
-Node: Integers71375
-Node: Bignums72031
-Node: Flonums72387
-Node: Sections74134
-Node: Secs Background74512
-Node: Ld Sections79551
-Node: As Sections81935
-Node: Sub-Sections82845
-Node: bss85990
-Node: Symbols86940
-Node: Labels87588
-Node: Setting Symbols88319
-Node: Symbol Names88873
-Node: Dot93914
-Node: Symbol Attributes94361
-Node: Symbol Value95098
-Node: Symbol Type96143
-Node: a.out Symbols96531
-Node: Symbol Desc96793
-Node: Symbol Other97088
-Node: COFF Symbols97257
-Node: SOM Symbols97930
-Node: Expressions98372
-Node: Empty Exprs99121
-Node: Integer Exprs99468
-Node: Arguments99863
-Node: Operators100969
-Node: Prefix Ops101304
-Node: Infix Ops101632
-Node: Pseudo Ops104022
-Node: Abort109523
-Node: ABORT (COFF)109935
-Node: Align110143
-Node: Altmacro112425
-Node: Ascii113754
-Node: Asciz114063
-Node: Balign114308
-Node: Byte116171
-Node: CFI directives116419
-Node: Comm122046
-Ref: Comm-Footnote-1123647
-Node: Data124009
-Node: Def124326
-Node: Desc124558
-Node: Dim125058
-Node: Double125315
-Node: Eject125653
-Node: Else125828
-Node: Elseif126128
-Node: End126422
-Node: Endef126637
-Node: Endfunc126814
-Node: Endif126989
-Node: Equ127250
-Node: Equiv127764
-Node: Eqv128320
-Node: Err128684
-Node: Error128995
-Node: Exitm129440
-Node: Extern129609
-Node: Fail129870
-Node: File130315
-Node: Fill131644
-Node: Float132608
-Node: Func132950
-Node: Global133540
-Node: Gnu_attribute134297
-Node: Hidden134522
-Node: hword135108
-Node: Ident135436
-Node: If136010
-Node: Incbin139069
-Node: Include139826
-Node: Int140377
-Node: Internal140758
-Node: Irp141406
-Node: Irpc142285
-Node: Lcomm143202
-Node: Lflags143950
-Node: Line144144
-Node: Linkonce145057
-Node: List146286
-Node: Ln146894
-Node: Loc147044
-Node: Loc_mark_labels148430
-Node: Local148914
-Node: Long149526
-Node: Macro149704
-Node: MRI155626
-Node: Noaltmacro155964
-Node: Nolist156133
-Node: Octa156563
-Node: Org156897
-Node: P2align158180
-Node: PopSection160108
-Node: Previous160616
-Node: Print162029
-Node: Protected162258
-Node: Psize162905
-Node: Purgem163589
-Node: PushSection163810
-Node: Quad164553
-Node: Reloc165009
-Node: Rept165770
-Node: Sbttl166184
-Node: Scl166549
-Node: Section166890
-Node: Set173005
-Node: Short173576
-Node: Single173897
-Node: Size174242
-Node: Skip174916
-Node: Sleb128175240
-Node: Space175564
-Node: Stab176205
-Node: String178209
-Node: Struct179203
-Node: SubSection179928
-Node: Symver180491
-Node: Tag182884
-Node: Text183266
-Node: Title183587
-Node: Type183968
-Node: Uleb128186262
-Node: Val186586
-Node: Version186836
-Node: VTableEntry187111
-Node: VTableInherit187401
-Node: Warning187851
-Node: Weak188085
-Node: Weakref188754
-Node: Word189719
-Node: Deprecated191565
-Node: Object Attributes191800
-Node: GNU Object Attributes193520
-Node: Defining New Object Attributes196073
-Node: Machine Dependencies196870
-Node: Alpha-Dependent200115
-Node: Alpha Notes200529
-Node: Alpha Options200810
-Node: Alpha Syntax203285
-Node: Alpha-Chars203754
-Node: Alpha-Regs203985
-Node: Alpha-Relocs204372
-Node: Alpha Floating Point210630
-Node: Alpha Directives210852
-Node: Alpha Opcodes216375
-Node: ARC-Dependent216670
-Node: ARC Options217053
-Node: ARC Syntax218122
-Node: ARC-Chars218354
-Node: ARC-Regs218486
-Node: ARC Floating Point218610
-Node: ARC Directives218921
-Node: ARC Opcodes224893
-Node: ARM-Dependent225119
-Node: ARM Options225584
-Node: ARM Syntax233930
-Node: ARM-Instruction-Set234298
-Node: ARM-Chars235530
-Node: ARM-Regs236082
-Node: ARM-Neon-Alignment236291
-Node: ARM Floating Point236755
-Node: ARM-Relocations236954
-Node: ARM Directives237946
-Ref: arm_pad239263
-Ref: arm_fnend242600
-Ref: arm_fnstart242924
-Ref: arm_save245934
-Ref: arm_setfp246635
-Node: ARM Opcodes249716
-Node: ARM Mapping Symbols251804
-Node: ARM Unwinding Tutorial252614
-Node: AVR-Dependent258814
-Node: AVR Options259104
-Node: AVR Syntax262607
-Node: AVR-Chars262894
-Node: AVR-Regs263300
-Node: AVR-Modifiers263879
-Node: AVR Opcodes265939
-Node: Blackfin-Dependent271185
-Node: Blackfin Options271497
-Node: Blackfin Syntax272471
-Node: Blackfin Directives278204
-Node: CR16-Dependent278623
-Node: CR16 Operand Qualifiers278871
-Node: CRIS-Dependent281512
-Node: CRIS-Opts281858
-Ref: march-option283476
-Node: CRIS-Expand285293
-Node: CRIS-Symbols286476
-Node: CRIS-Syntax287645
-Node: CRIS-Chars287981
-Node: CRIS-Pic288532
-Ref: crispic288728
-Node: CRIS-Regs292268
-Node: CRIS-Pseudos292685
-Ref: crisnous293461
-Node: D10V-Dependent294743
-Node: D10V-Opts295094
-Node: D10V-Syntax296056
-Node: D10V-Size296585
-Node: D10V-Subs297558
-Node: D10V-Chars298593
-Node: D10V-Regs300197
-Node: D10V-Addressing301242
-Node: D10V-Word301928
-Node: D10V-Float302443
-Node: D10V-Opcodes302754
-Node: D30V-Dependent303147
-Node: D30V-Opts303500
-Node: D30V-Syntax304175
-Node: D30V-Size304707
-Node: D30V-Subs305678
-Node: D30V-Chars306713
-Node: D30V-Guarded309011
-Node: D30V-Regs309691
-Node: D30V-Addressing310830
-Node: D30V-Float311498
-Node: D30V-Opcodes311809
-Node: H8/300-Dependent312202
-Node: H8/300 Options312614
-Node: H8/300 Syntax312881
-Node: H8/300-Chars313182
-Node: H8/300-Regs313481
-Node: H8/300-Addressing314400
-Node: H8/300 Floating Point315441
-Node: H8/300 Directives315768
-Node: H8/300 Opcodes316896
-Node: HPPA-Dependent325218
-Node: HPPA Notes325653
-Node: HPPA Options326411
-Node: HPPA Syntax326606
-Node: HPPA Floating Point327876
-Node: HPPA Directives328082
-Node: HPPA Opcodes336768
-Node: ESA/390-Dependent337027
-Node: ESA/390 Notes337487
-Node: ESA/390 Options338278
-Node: ESA/390 Syntax338488
-Node: ESA/390 Floating Point340661
-Node: ESA/390 Directives340940
-Node: ESA/390 Opcodes344229
-Node: i386-Dependent344491
-Node: i386-Options345688
-Node: i386-Directives350054
-Node: i386-Syntax350792
-Node: i386-Mnemonics353356
-Node: i386-Regs356649
-Node: i386-Prefixes358694
-Node: i386-Memory361454
-Node: i386-Jumps364391
-Node: i386-Float365512
-Node: i386-SIMD367343
-Node: i386-LWP368452
-Node: i386-16bit369288
-Node: i386-Bugs371359
-Node: i386-Arch372113
-Node: i386-Notes374774
-Node: i860-Dependent375632
-Node: Notes-i860376028
-Node: Options-i860376933
-Node: Directives-i860378296
-Node: Opcodes for i860379365
-Node: i960-Dependent381532
-Node: Options-i960381935
-Node: Floating Point-i960385820
-Node: Directives-i960386088
-Node: Opcodes for i960388122
-Node: callj-i960388739
-Node: Compare-and-branch-i960389228
-Node: IA-64-Dependent391132
-Node: IA-64 Options391433
-Node: IA-64 Syntax394584
-Node: IA-64-Chars394990
-Node: IA-64-Regs395220
-Node: IA-64-Bits396146
-Node: IA-64-Relocs396676
-Node: IA-64 Opcodes397148
-Node: IP2K-Dependent397420
-Node: IP2K-Opts397648
-Node: LM32-Dependent398128
-Node: LM32 Options398423
-Node: LM32 Syntax399057
-Node: LM32-Regs399304
-Node: LM32-Modifiers400263
-Node: LM32 Opcodes401619
-Node: M32C-Dependent401923
-Node: M32C-Opts402447
-Node: M32C-Modifiers402870
-Node: M32R-Dependent404657
-Node: M32R-Opts404978
-Node: M32R-Directives409145
-Node: M32R-Warnings413120
-Node: M68K-Dependent416126
-Node: M68K-Opts416593
-Node: M68K-Syntax423966
-Node: M68K-Moto-Syntax425806
-Node: M68K-Float428396
-Node: M68K-Directives428916
-Node: M68K-opcodes430244
-Node: M68K-Branch430470
-Node: M68K-Chars434668
-Node: M68HC11-Dependent435081
-Node: M68HC11-Opts435618
-Node: M68HC11-Syntax439439
-Node: M68HC11-Modifiers441653
-Node: M68HC11-Directives443481
-Node: M68HC11-Float444857
-Node: M68HC11-opcodes445385
-Node: M68HC11-Branch445567
-Node: MicroBlaze-Dependent448016
-Node: MicroBlaze Directives448646
-Node: MIPS-Dependent450003
-Node: MIPS Opts451166
-Node: MIPS Object461678
-Node: MIPS Stabs463244
-Node: MIPS symbol sizes463966
-Node: MIPS ISA465635
-Node: MIPS autoextend467109
-Node: MIPS insn467839
-Node: MIPS option stack469109
-Node: MIPS ASE instruction generation overrides469883
-Node: MIPS floating-point471697
-Node: MMIX-Dependent472583
-Node: MMIX-Opts472963
-Node: MMIX-Expand476567
-Node: MMIX-Syntax477882
-Ref: mmixsite478239
-Node: MMIX-Chars479080
-Node: MMIX-Symbols479734
-Node: MMIX-Regs481802
-Node: MMIX-Pseudos482827
-Ref: MMIX-loc482968
-Ref: MMIX-local484048
-Ref: MMIX-is484580
-Ref: MMIX-greg484851
-Ref: GREG-base485770
-Ref: MMIX-byte487087
-Ref: MMIX-constants487558
-Ref: MMIX-prefix488204
-Ref: MMIX-spec488578
-Node: MMIX-mmixal488912
-Node: MSP430-Dependent492410
-Node: MSP430 Options492876
-Node: MSP430 Syntax493162
-Node: MSP430-Macros493478
-Node: MSP430-Chars494209
-Node: MSP430-Regs494522
-Node: MSP430-Ext495082
-Node: MSP430 Floating Point496903
-Node: MSP430 Directives497127
-Node: MSP430 Opcodes497918
-Node: MSP430 Profiling Capability498313
-Node: PDP-11-Dependent500642
-Node: PDP-11-Options501031
-Node: PDP-11-Pseudos506102
-Node: PDP-11-Syntax506447
-Node: PDP-11-Mnemonics507199
-Node: PDP-11-Synthetic507501
-Node: PJ-Dependent507719
-Node: PJ Options507944
-Node: PPC-Dependent508221
-Node: PowerPC-Opts508505
-Node: PowerPC-Pseudo511124
-Node: RX-Dependent511723
-Node: RX-Opts512116
-Node: RX-Modifiers514142
-Node: RX-Directives514473
-Node: RX-Float514789
-Node: S/390-Dependent515412
-Node: s390 Options516120
-Node: s390 Characters517666
-Node: s390 Syntax517859
-Node: s390 Register518760
-Node: s390 Mnemonics519573
-Node: s390 Operands522593
-Node: s390 Formats525212
-Node: s390 Aliases533058
-Node: s390 Operand Modifier536955
-Node: s390 Instruction Marker540756
-Node: s390 Literal Pool Entries541772
-Node: s390 Directives543695
-Node: s390 Floating Point547610
-Node: SCORE-Dependent548056
-Node: SCORE-Opts548330
-Node: SCORE-Pseudo549618
-Node: SH-Dependent551674
-Node: SH Options552086
-Node: SH Syntax553141
-Node: SH-Chars553414
-Node: SH-Regs553708
-Node: SH-Addressing554322
-Node: SH Floating Point555231
-Node: SH Directives556325
-Node: SH Opcodes556695
-Node: SH64-Dependent561017
-Node: SH64 Options561380
-Node: SH64 Syntax563177
-Node: SH64-Chars563460
-Node: SH64-Regs563760
-Node: SH64-Addressing564856
-Node: SH64 Directives566039
-Node: SH64 Opcodes567149
-Node: Sparc-Dependent567865
-Node: Sparc-Opts568277
-Node: Sparc-Aligned-Data570534
-Node: Sparc-Syntax571366
-Node: Sparc-Chars571940
-Node: Sparc-Regs572173
-Node: Sparc-Constants577284
-Node: Sparc-Relocs582044
-Node: Sparc-Size-Translations586724
-Node: Sparc-Float588373
-Node: Sparc-Directives588568
-Node: TIC54X-Dependent590528
-Node: TIC54X-Opts591255
-Node: TIC54X-Block592298
-Node: TIC54X-Env592658
-Node: TIC54X-Constants593006
-Node: TIC54X-Subsyms593408
-Node: TIC54X-Locals595317
-Node: TIC54X-Builtins596061
-Node: TIC54X-Ext598532
-Node: TIC54X-Directives599103
-Node: TIC54X-Macros610004
-Node: TIC54X-MMRegs612115
-Node: TIC6X-Dependent612331
-Node: TIC6X Options612631
-Node: TIC6X Syntax615249
-Node: TIC6X Directives616173
-Node: Z80-Dependent617242
-Node: Z80 Options617630
-Node: Z80 Syntax619053
-Node: Z80-Chars619725
-Node: Z80-Regs620259
-Node: Z80-Case620611
-Node: Z80 Floating Point621056
-Node: Z80 Directives621250
-Node: Z80 Opcodes622875
-Node: Z8000-Dependent624219
-Node: Z8000 Options625180
-Node: Z8000 Syntax625397
-Node: Z8000-Chars625687
-Node: Z8000-Regs625920
-Node: Z8000-Addressing626710
-Node: Z8000 Directives627827
-Node: Z8000 Opcodes629436
-Node: Vax-Dependent639378
-Node: VAX-Opts639895
-Node: VAX-float643630
-Node: VAX-directives644262
-Node: VAX-opcodes645123
-Node: VAX-branch645512
-Node: VAX-operands648019
-Node: VAX-no648782
-Node: V850-Dependent649019
-Node: V850 Options649416
-Node: V850 Syntax652267
-Node: V850-Chars652507
-Node: V850-Regs652672
-Node: V850 Floating Point654240
-Node: V850 Directives654446
-Node: V850 Opcodes656049
-Node: Xtensa-Dependent661941
-Node: Xtensa Options662670
-Node: Xtensa Syntax665480
-Node: Xtensa Opcodes667369
-Node: Xtensa Registers669163
-Node: Xtensa Optimizations669796
-Node: Density Instructions670248
-Node: Xtensa Automatic Alignment671350
-Node: Xtensa Relaxation673797
-Node: Xtensa Branch Relaxation674705
-Node: Xtensa Call Relaxation676077
-Node: Xtensa Immediate Relaxation677863
-Node: Xtensa Directives680437
-Node: Schedule Directive682146
-Node: Longcalls Directive682486
-Node: Transform Directive683030
-Node: Literal Directive683772
-Ref: Literal Directive-Footnote-1687311
-Node: Literal Position Directive687453
-Node: Literal Prefix Directive689152
-Node: Absolute Literals Directive690050
-Node: Reporting Bugs691357
-Node: Bug Criteria692083
-Node: Bug Reporting692850
-Node: Acknowledgements699499
-Ref: Acknowledgements-Footnote-1704465
-Node: GNU Free Documentation License704491
-Node: AS Index729660
-
-End Tag Table
diff --git a/share/info/bfd.info b/share/info/bfd.info
deleted file mode 100644
index 48be649..0000000
--- a/share/info/bfd.info
+++ /dev/null
@@ -1,11673 +0,0 @@
-This is bfd.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gdb/gdb-7.3.x/bfd/doc/bfd.texinfo.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* Bfd: (bfd). The Binary File Descriptor library.
-END-INFO-DIR-ENTRY
-
- This file documents the BFD library.
-
- Copyright (C) 1991, 2000, 2001, 2003, 2006, 2007, 2008 Free Software
-Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with the
-Invariant Sections being "GNU General Public License" and "Funding Free
-Software", the Front-Cover texts being (a) (see below), and with the
-Back-Cover Texts being (b) (see below). A copy of the license is
-included in the section entitled "GNU Free Documentation License".
-
- (a) The FSF's Front-Cover Text is:
-
- A GNU Manual
-
- (b) The FSF's Back-Cover Text is:
-
- You have freedom to copy and modify this GNU Manual, like GNU
-software. Copies published by the Free Software Foundation raise
-funds for GNU development.
-
-
-File: bfd.info, Node: Top, Next: Overview, Prev: (dir), Up: (dir)
-
- This file documents the binary file descriptor library libbfd.
-
-* Menu:
-
-* Overview:: Overview of BFD
-* BFD front end:: BFD front end
-* BFD back ends:: BFD back ends
-* GNU Free Documentation License:: GNU Free Documentation License
-* BFD Index:: BFD Index
-
-
-File: bfd.info, Node: Overview, Next: BFD front end, Prev: Top, Up: Top
-
-1 Introduction
-**************
-
-BFD is a package which allows applications to use the same routines to
-operate on object files whatever the object file format. A new object
-file format can be supported simply by creating a new BFD back end and
-adding it to the library.
-
- BFD is split into two parts: the front end, and the back ends (one
-for each object file format).
- * The front end of BFD provides the interface to the user. It manages
- memory and various canonical data structures. The front end also
- decides which back end to use and when to call back end routines.
-
- * The back ends provide BFD its view of the real world. Each back
- end provides a set of calls which the BFD front end can use to
- maintain its canonical form. The back ends also may keep around
- information for their own use, for greater efficiency.
-
-* Menu:
-
-* History:: History
-* How It Works:: How It Works
-* What BFD Version 2 Can Do:: What BFD Version 2 Can Do
-
-
-File: bfd.info, Node: History, Next: How It Works, Prev: Overview, Up: Overview
-
-1.1 History
-===========
-
-One spur behind BFD was the desire, on the part of the GNU 960 team at
-Intel Oregon, for interoperability of applications on their COFF and
-b.out file formats. Cygnus was providing GNU support for the team, and
-was contracted to provide the required functionality.
-
- The name came from a conversation David Wallace was having with
-Richard Stallman about the library: RMS said that it would be quite
-hard--David said "BFD". Stallman was right, but the name stuck.
-
- At the same time, Ready Systems wanted much the same thing, but for
-different object file formats: IEEE-695, Oasys, Srecords, a.out and 68k
-coff.
-
- BFD was first implemented by members of Cygnus Support; Steve
-Chamberlain (`sac@cygnus.com'), John Gilmore (`gnu@cygnus.com'), K.
-Richard Pixley (`rich@cygnus.com') and David Henkel-Wallace
-(`gumby@cygnus.com').
-
-
-File: bfd.info, Node: How It Works, Next: What BFD Version 2 Can Do, Prev: History, Up: Overview
-
-1.2 How To Use BFD
-==================
-
-To use the library, include `bfd.h' and link with `libbfd.a'.
-
- BFD provides a common interface to the parts of an object file for a
-calling application.
-
- When an application successfully opens a target file (object,
-archive, or whatever), a pointer to an internal structure is returned.
-This pointer points to a structure called `bfd', described in `bfd.h'.
-Our convention is to call this pointer a BFD, and instances of it
-within code `abfd'. All operations on the target object file are
-applied as methods to the BFD. The mapping is defined within `bfd.h'
-in a set of macros, all beginning with `bfd_' to reduce namespace
-pollution.
-
- For example, this sequence does what you would probably expect:
-return the number of sections in an object file attached to a BFD
-`abfd'.
-
- #include "bfd.h"
-
- unsigned int number_of_sections (abfd)
- bfd *abfd;
- {
- return bfd_count_sections (abfd);
- }
-
- The abstraction used within BFD is that an object file has:
-
- * a header,
-
- * a number of sections containing raw data (*note Sections::),
-
- * a set of relocations (*note Relocations::), and
-
- * some symbol information (*note Symbols::).
- Also, BFDs opened for archives have the additional attribute of an
-index and contain subordinate BFDs. This approach is fine for a.out and
-coff, but loses efficiency when applied to formats such as S-records and
-IEEE-695.
-
-
-File: bfd.info, Node: What BFD Version 2 Can Do, Prev: How It Works, Up: Overview
-
-1.3 What BFD Version 2 Can Do
-=============================
-
-When an object file is opened, BFD subroutines automatically determine
-the format of the input object file. They then build a descriptor in
-memory with pointers to routines that will be used to access elements of
-the object file's data structures.
-
- As different information from the object files is required, BFD
-reads from different sections of the file and processes them. For
-example, a very common operation for the linker is processing symbol
-tables. Each BFD back end provides a routine for converting between
-the object file's representation of symbols and an internal canonical
-format. When the linker asks for the symbol table of an object file, it
-calls through a memory pointer to the routine from the relevant BFD
-back end which reads and converts the table into a canonical form. The
-linker then operates upon the canonical form. When the link is finished
-and the linker writes the output file's symbol table, another BFD back
-end routine is called to take the newly created symbol table and
-convert it into the chosen output format.
-
-* Menu:
-
-* BFD information loss:: Information Loss
-* Canonical format:: The BFD canonical object-file format
-
-
-File: bfd.info, Node: BFD information loss, Next: Canonical format, Up: What BFD Version 2 Can Do
-
-1.3.1 Information Loss
-----------------------
-
-_Information can be lost during output._ The output formats supported
-by BFD do not provide identical facilities, and information which can
-be described in one form has nowhere to go in another format. One
-example of this is alignment information in `b.out'. There is nowhere
-in an `a.out' format file to store alignment information on the
-contained data, so when a file is linked from `b.out' and an `a.out'
-image is produced, alignment information will not propagate to the
-output file. (The linker will still use the alignment information
-internally, so the link is performed correctly).
-
- Another example is COFF section names. COFF files may contain an
-unlimited number of sections, each one with a textual section name. If
-the target of the link is a format which does not have many sections
-(e.g., `a.out') or has sections without names (e.g., the Oasys format),
-the link cannot be done simply. You can circumvent this problem by
-describing the desired input-to-output section mapping with the linker
-command language.
-
- _Information can be lost during canonicalization._ The BFD internal
-canonical form of the external formats is not exhaustive; there are
-structures in input formats for which there is no direct representation
-internally. This means that the BFD back ends cannot maintain all
-possible data richness through the transformation between external to
-internal and back to external formats.
-
- This limitation is only a problem when an application reads one
-format and writes another. Each BFD back end is responsible for
-maintaining as much data as possible, and the internal BFD canonical
-form has structures which are opaque to the BFD core, and exported only
-to the back ends. When a file is read in one format, the canonical form
-is generated for BFD and the application. At the same time, the back
-end saves away any information which may otherwise be lost. If the data
-is then written back in the same format, the back end routine will be
-able to use the canonical form provided by the BFD core as well as the
-information it prepared earlier. Since there is a great deal of
-commonality between back ends, there is no information lost when
-linking or copying big endian COFF to little endian COFF, or `a.out' to
-`b.out'. When a mixture of formats is linked, the information is only
-lost from the files whose format differs from the destination.
-
-
-File: bfd.info, Node: Canonical format, Prev: BFD information loss, Up: What BFD Version 2 Can Do
-
-1.3.2 The BFD canonical object-file format
-------------------------------------------
-
-The greatest potential for loss of information occurs when there is the
-least overlap between the information provided by the source format,
-that stored by the canonical format, and that needed by the destination
-format. A brief description of the canonical form may help you
-understand which kinds of data you can count on preserving across
-conversions.
-
-_files_
- Information stored on a per-file basis includes target machine
- architecture, particular implementation format type, a demand
- pageable bit, and a write protected bit. Information like Unix
- magic numbers is not stored here--only the magic numbers' meaning,
- so a `ZMAGIC' file would have both the demand pageable bit and the
- write protected text bit set. The byte order of the target is
- stored on a per-file basis, so that big- and little-endian object
- files may be used with one another.
-
-_sections_
- Each section in the input file contains the name of the section,
- the section's original address in the object file, size and
- alignment information, various flags, and pointers into other BFD
- data structures.
-
-_symbols_
- Each symbol contains a pointer to the information for the object
- file which originally defined it, its name, its value, and various
- flag bits. When a BFD back end reads in a symbol table, it
- relocates all symbols to make them relative to the base of the
- section where they were defined. Doing this ensures that each
- symbol points to its containing section. Each symbol also has a
- varying amount of hidden private data for the BFD back end. Since
- the symbol points to the original file, the private data format
- for that symbol is accessible. `ld' can operate on a collection
- of symbols of wildly different formats without problems.
-
- Normal global and simple local symbols are maintained on output,
- so an output file (no matter its format) will retain symbols
- pointing to functions and to global, static, and common variables.
- Some symbol information is not worth retaining; in `a.out', type
- information is stored in the symbol table as long symbol names.
- This information would be useless to most COFF debuggers; the
- linker has command line switches to allow users to throw it away.
-
- There is one word of type information within the symbol, so if the
- format supports symbol type information within symbols (for
- example, COFF, IEEE, Oasys) and the type is simple enough to fit
- within one word (nearly everything but aggregates), the
- information will be preserved.
-
-_relocation level_
- Each canonical BFD relocation record contains a pointer to the
- symbol to relocate to, the offset of the data to relocate, the
- section the data is in, and a pointer to a relocation type
- descriptor. Relocation is performed by passing messages through
- the relocation type descriptor and the symbol pointer. Therefore,
- relocations can be performed on output data using a relocation
- method that is only available in one of the input formats. For
- instance, Oasys provides a byte relocation format. A relocation
- record requesting this relocation type would point indirectly to a
- routine to perform this, so the relocation may be performed on a
- byte being written to a 68k COFF file, even though 68k COFF has no
- such relocation type.
-
-_line numbers_
- Object formats can contain, for debugging purposes, some form of
- mapping between symbols, source line numbers, and addresses in the
- output file. These addresses have to be relocated along with the
- symbol information. Each symbol with an associated list of line
- number records points to the first record of the list. The head
- of a line number list consists of a pointer to the symbol, which
- allows finding out the address of the function whose line number
- is being described. The rest of the list is made up of pairs:
- offsets into the section and line numbers. Any format which can
- simply derive this information can pass it successfully between
- formats (COFF, IEEE and Oasys).
-
-
-File: bfd.info, Node: BFD front end, Next: BFD back ends, Prev: Overview, Up: Top
-
-2 BFD Front End
-***************
-
-2.1 `typedef bfd'
-=================
-
-A BFD has type `bfd'; objects of this type are the cornerstone of any
-application using BFD. Using BFD consists of making references though
-the BFD and to data in the BFD.
-
- Here is the structure that defines the type `bfd'. It contains the
-major data about the file and pointers to the rest of the data.
-
-
- enum bfd_direction
- {
- no_direction = 0,
- read_direction = 1,
- write_direction = 2,
- both_direction = 3
- };
-
- struct bfd
- {
- /* A unique identifier of the BFD */
- unsigned int id;
-
- /* The filename the application opened the BFD with. */
- const char *filename;
-
- /* A pointer to the target jump table. */
- const struct bfd_target *xvec;
-
- /* The IOSTREAM, and corresponding IO vector that provide access
- to the file backing the BFD. */
- void *iostream;
- const struct bfd_iovec *iovec;
-
- /* The caching routines use these to maintain a
- least-recently-used list of BFDs. */
- struct bfd *lru_prev, *lru_next;
-
- /* When a file is closed by the caching routines, BFD retains
- state information on the file here... */
- ufile_ptr where;
-
- /* File modified time, if mtime_set is TRUE. */
- long mtime;
-
- /* Reserved for an unimplemented file locking extension. */
- int ifd;
-
- /* The format which belongs to the BFD. (object, core, etc.) */
- bfd_format format;
-
- /* The direction with which the BFD was opened. */
- enum bfd_direction direction;
-
- /* Format_specific flags. */
- flagword flags;
-
- /* Values that may appear in the flags field of a BFD. These also
- appear in the object_flags field of the bfd_target structure, where
- they indicate the set of flags used by that backend (not all flags
- are meaningful for all object file formats) (FIXME: at the moment,
- the object_flags values have mostly just been copied from backend
- to another, and are not necessarily correct). */
-
- #define BFD_NO_FLAGS 0x00
-
- /* BFD contains relocation entries. */
- #define HAS_RELOC 0x01
-
- /* BFD is directly executable. */
- #define EXEC_P 0x02
-
- /* BFD has line number information (basically used for F_LNNO in a
- COFF header). */
- #define HAS_LINENO 0x04
-
- /* BFD has debugging information. */
- #define HAS_DEBUG 0x08
-
- /* BFD has symbols. */
- #define HAS_SYMS 0x10
-
- /* BFD has local symbols (basically used for F_LSYMS in a COFF
- header). */
- #define HAS_LOCALS 0x20
-
- /* BFD is a dynamic object. */
- #define DYNAMIC 0x40
-
- /* Text section is write protected (if D_PAGED is not set, this is
- like an a.out NMAGIC file) (the linker sets this by default, but
- clears it for -r or -N). */
- #define WP_TEXT 0x80
-
- /* BFD is dynamically paged (this is like an a.out ZMAGIC file) (the
- linker sets this by default, but clears it for -r or -n or -N). */
- #define D_PAGED 0x100
-
- /* BFD is relaxable (this means that bfd_relax_section may be able to
- do something) (sometimes bfd_relax_section can do something even if
- this is not set). */
- #define BFD_IS_RELAXABLE 0x200
-
- /* This may be set before writing out a BFD to request using a
- traditional format. For example, this is used to request that when
- writing out an a.out object the symbols not be hashed to eliminate
- duplicates. */
- #define BFD_TRADITIONAL_FORMAT 0x400
-
- /* This flag indicates that the BFD contents are actually cached
- in memory. If this is set, iostream points to a bfd_in_memory
- struct. */
- #define BFD_IN_MEMORY 0x800
-
- /* The sections in this BFD specify a memory page. */
- #define HAS_LOAD_PAGE 0x1000
-
- /* This BFD has been created by the linker and doesn't correspond
- to any input file. */
- #define BFD_LINKER_CREATED 0x2000
-
- /* This may be set before writing out a BFD to request that it
- be written using values for UIDs, GIDs, timestamps, etc. that
- will be consistent from run to run. */
- #define BFD_DETERMINISTIC_OUTPUT 0x4000
-
- /* Compress sections in this BFD. */
- #define BFD_COMPRESS 0x8000
-
- /* Decompress sections in this BFD. */
- #define BFD_DECOMPRESS 0x10000
-
- /* Flags bits to be saved in bfd_preserve_save. */
- #define BFD_FLAGS_SAVED \
- (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS)
-
- /* Flags bits which are for BFD use only. */
- #define BFD_FLAGS_FOR_BFD_USE_MASK \
- (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS | BFD_LINKER_CREATED \
- | BFD_TRADITIONAL_FORMAT | BFD_DETERMINISTIC_OUTPUT)
-
- /* Currently my_archive is tested before adding origin to
- anything. I believe that this can become always an add of
- origin, with origin set to 0 for non archive files. */
- ufile_ptr origin;
-
- /* The origin in the archive of the proxy entry. This will
- normally be the same as origin, except for thin archives,
- when it will contain the current offset of the proxy in the
- thin archive rather than the offset of the bfd in its actual
- container. */
- ufile_ptr proxy_origin;
-
- /* A hash table for section names. */
- struct bfd_hash_table section_htab;
-
- /* Pointer to linked list of sections. */
- struct bfd_section *sections;
-
- /* The last section on the section list. */
- struct bfd_section *section_last;
-
- /* The number of sections. */
- unsigned int section_count;
-
- /* Stuff only useful for object files:
- The start address. */
- bfd_vma start_address;
-
- /* Used for input and output. */
- unsigned int symcount;
-
- /* Symbol table for output BFD (with symcount entries).
- Also used by the linker to cache input BFD symbols. */
- struct bfd_symbol **outsymbols;
-
- /* Used for slurped dynamic symbol tables. */
- unsigned int dynsymcount;
-
- /* Pointer to structure which contains architecture information. */
- const struct bfd_arch_info *arch_info;
-
- /* Stuff only useful for archives. */
- void *arelt_data;
- struct bfd *my_archive; /* The containing archive BFD. */
- struct bfd *archive_next; /* The next BFD in the archive. */
- struct bfd *archive_head; /* The first BFD in the archive. */
- struct bfd *nested_archives; /* List of nested archive in a flattened
- thin archive. */
-
- /* A chain of BFD structures involved in a link. */
- struct bfd *link_next;
-
- /* A field used by _bfd_generic_link_add_archive_symbols. This will
- be used only for archive elements. */
- int archive_pass;
-
- /* Used by the back end to hold private data. */
- union
- {
- struct aout_data_struct *aout_data;
- struct artdata *aout_ar_data;
- struct _oasys_data *oasys_obj_data;
- struct _oasys_ar_data *oasys_ar_data;
- struct coff_tdata *coff_obj_data;
- struct pe_tdata *pe_obj_data;
- struct xcoff_tdata *xcoff_obj_data;
- struct ecoff_tdata *ecoff_obj_data;
- struct ieee_data_struct *ieee_data;
- struct ieee_ar_data_struct *ieee_ar_data;
- struct srec_data_struct *srec_data;
- struct verilog_data_struct *verilog_data;
- struct ihex_data_struct *ihex_data;
- struct tekhex_data_struct *tekhex_data;
- struct elf_obj_tdata *elf_obj_data;
- struct nlm_obj_tdata *nlm_obj_data;
- struct bout_data_struct *bout_data;
- struct mmo_data_struct *mmo_data;
- struct sun_core_struct *sun_core_data;
- struct sco5_core_struct *sco5_core_data;
- struct trad_core_struct *trad_core_data;
- struct som_data_struct *som_data;
- struct hpux_core_struct *hpux_core_data;
- struct hppabsd_core_struct *hppabsd_core_data;
- struct sgi_core_struct *sgi_core_data;
- struct lynx_core_struct *lynx_core_data;
- struct osf_core_struct *osf_core_data;
- struct cisco_core_struct *cisco_core_data;
- struct versados_data_struct *versados_data;
- struct netbsd_core_struct *netbsd_core_data;
- struct mach_o_data_struct *mach_o_data;
- struct mach_o_fat_data_struct *mach_o_fat_data;
- struct plugin_data_struct *plugin_data;
- struct bfd_pef_data_struct *pef_data;
- struct bfd_pef_xlib_data_struct *pef_xlib_data;
- struct bfd_sym_data_struct *sym_data;
- void *any;
- }
- tdata;
-
- /* Used by the application to hold private data. */
- void *usrdata;
-
- /* Where all the allocated stuff under this BFD goes. This is a
- struct objalloc *, but we use void * to avoid requiring the inclusion
- of objalloc.h. */
- void *memory;
-
- /* Is the file descriptor being cached? That is, can it be closed as
- needed, and re-opened when accessed later? */
- unsigned int cacheable : 1;
-
- /* Marks whether there was a default target specified when the
- BFD was opened. This is used to select which matching algorithm
- to use to choose the back end. */
- unsigned int target_defaulted : 1;
-
- /* ... and here: (``once'' means at least once). */
- unsigned int opened_once : 1;
-
- /* Set if we have a locally maintained mtime value, rather than
- getting it from the file each time. */
- unsigned int mtime_set : 1;
-
- /* Flag set if symbols from this BFD should not be exported. */
- unsigned int no_export : 1;
-
- /* Remember when output has begun, to stop strange things
- from happening. */
- unsigned int output_has_begun : 1;
-
- /* Have archive map. */
- unsigned int has_armap : 1;
-
- /* Set if this is a thin archive. */
- unsigned int is_thin_archive : 1;
-
- /* Set if only required symbols should be added in the link hash table for
- this object. Used by VMS linkers. */
- unsigned int selective_search : 1;
- };
-
-2.2 Error reporting
-===================
-
-Most BFD functions return nonzero on success (check their individual
-documentation for precise semantics). On an error, they call
-`bfd_set_error' to set an error condition that callers can check by
-calling `bfd_get_error'. If that returns `bfd_error_system_call', then
-check `errno'.
-
- The easiest way to report a BFD error to the user is to use
-`bfd_perror'.
-
-2.2.1 Type `bfd_error_type'
----------------------------
-
-The values returned by `bfd_get_error' are defined by the enumerated
-type `bfd_error_type'.
-
-
- typedef enum bfd_error
- {
- bfd_error_no_error = 0,
- bfd_error_system_call,
- bfd_error_invalid_target,
- bfd_error_wrong_format,
- bfd_error_wrong_object_format,
- bfd_error_invalid_operation,
- bfd_error_no_memory,
- bfd_error_no_symbols,
- bfd_error_no_armap,
- bfd_error_no_more_archived_files,
- bfd_error_malformed_archive,
- bfd_error_file_not_recognized,
- bfd_error_file_ambiguously_recognized,
- bfd_error_no_contents,
- bfd_error_nonrepresentable_section,
- bfd_error_no_debug_section,
- bfd_error_bad_value,
- bfd_error_file_truncated,
- bfd_error_file_too_big,
- bfd_error_on_input,
- bfd_error_invalid_error_code
- }
- bfd_error_type;
-
-2.2.1.1 `bfd_get_error'
-.......................
-
-*Synopsis*
- bfd_error_type bfd_get_error (void);
- *Description*
-Return the current BFD error condition.
-
-2.2.1.2 `bfd_set_error'
-.......................
-
-*Synopsis*
- void bfd_set_error (bfd_error_type error_tag, ...);
- *Description*
-Set the BFD error condition to be ERROR_TAG. If ERROR_TAG is
-bfd_error_on_input, then this function takes two more parameters, the
-input bfd where the error occurred, and the bfd_error_type error.
-
-2.2.1.3 `bfd_errmsg'
-....................
-
-*Synopsis*
- const char *bfd_errmsg (bfd_error_type error_tag);
- *Description*
-Return a string describing the error ERROR_TAG, or the system error if
-ERROR_TAG is `bfd_error_system_call'.
-
-2.2.1.4 `bfd_perror'
-....................
-
-*Synopsis*
- void bfd_perror (const char *message);
- *Description*
-Print to the standard error stream a string describing the last BFD
-error that occurred, or the last system error if the last BFD error was
-a system call failure. If MESSAGE is non-NULL and non-empty, the error
-string printed is preceded by MESSAGE, a colon, and a space. It is
-followed by a newline.
-
-2.2.2 BFD error handler
------------------------
-
-Some BFD functions want to print messages describing the problem. They
-call a BFD error handler function. This function may be overridden by
-the program.
-
- The BFD error handler acts like printf.
-
-
- typedef void (*bfd_error_handler_type) (const char *, ...);
-
-2.2.2.1 `bfd_set_error_handler'
-...............................
-
-*Synopsis*
- bfd_error_handler_type bfd_set_error_handler (bfd_error_handler_type);
- *Description*
-Set the BFD error handler function. Returns the previous function.
-
-2.2.2.2 `bfd_set_error_program_name'
-....................................
-
-*Synopsis*
- void bfd_set_error_program_name (const char *);
- *Description*
-Set the program name to use when printing a BFD error. This is printed
-before the error message followed by a colon and space. The string
-must not be changed after it is passed to this function.
-
-2.2.2.3 `bfd_get_error_handler'
-...............................
-
-*Synopsis*
- bfd_error_handler_type bfd_get_error_handler (void);
- *Description*
-Return the BFD error handler function.
-
-2.3 Miscellaneous
-=================
-
-2.3.1 Miscellaneous functions
------------------------------
-
-2.3.1.1 `bfd_get_reloc_upper_bound'
-...................................
-
-*Synopsis*
- long bfd_get_reloc_upper_bound (bfd *abfd, asection *sect);
- *Description*
-Return the number of bytes required to store the relocation information
-associated with section SECT attached to bfd ABFD. If an error occurs,
-return -1.
-
-2.3.1.2 `bfd_canonicalize_reloc'
-................................
-
-*Synopsis*
- long bfd_canonicalize_reloc
- (bfd *abfd, asection *sec, arelent **loc, asymbol **syms);
- *Description*
-Call the back end associated with the open BFD ABFD and translate the
-external form of the relocation information attached to SEC into the
-internal canonical form. Place the table into memory at LOC, which has
-been preallocated, usually by a call to `bfd_get_reloc_upper_bound'.
-Returns the number of relocs, or -1 on error.
-
- The SYMS table is also needed for horrible internal magic reasons.
-
-2.3.1.3 `bfd_set_reloc'
-.......................
-
-*Synopsis*
- void bfd_set_reloc
- (bfd *abfd, asection *sec, arelent **rel, unsigned int count);
- *Description*
-Set the relocation pointer and count within section SEC to the values
-REL and COUNT. The argument ABFD is ignored.
-
-2.3.1.4 `bfd_set_file_flags'
-............................
-
-*Synopsis*
- bfd_boolean bfd_set_file_flags (bfd *abfd, flagword flags);
- *Description*
-Set the flag word in the BFD ABFD to the value FLAGS.
-
- Possible errors are:
- * `bfd_error_wrong_format' - The target bfd was not of object format.
-
- * `bfd_error_invalid_operation' - The target bfd was open for
- reading.
-
- * `bfd_error_invalid_operation' - The flag word contained a bit
- which was not applicable to the type of file. E.g., an attempt
- was made to set the `D_PAGED' bit on a BFD format which does not
- support demand paging.
-
-2.3.1.5 `bfd_get_arch_size'
-...........................
-
-*Synopsis*
- int bfd_get_arch_size (bfd *abfd);
- *Description*
-Returns the architecture address size, in bits, as determined by the
-object file's format. For ELF, this information is included in the
-header.
-
- *Returns*
-Returns the arch size in bits if known, `-1' otherwise.
-
-2.3.1.6 `bfd_get_sign_extend_vma'
-.................................
-
-*Synopsis*
- int bfd_get_sign_extend_vma (bfd *abfd);
- *Description*
-Indicates if the target architecture "naturally" sign extends an
-address. Some architectures implicitly sign extend address values when
-they are converted to types larger than the size of an address. For
-instance, bfd_get_start_address() will return an address sign extended
-to fill a bfd_vma when this is the case.
-
- *Returns*
-Returns `1' if the target architecture is known to sign extend
-addresses, `0' if the target architecture is known to not sign extend
-addresses, and `-1' otherwise.
-
-2.3.1.7 `bfd_set_start_address'
-...............................
-
-*Synopsis*
- bfd_boolean bfd_set_start_address (bfd *abfd, bfd_vma vma);
- *Description*
-Make VMA the entry point of output BFD ABFD.
-
- *Returns*
-Returns `TRUE' on success, `FALSE' otherwise.
-
-2.3.1.8 `bfd_get_gp_size'
-.........................
-
-*Synopsis*
- unsigned int bfd_get_gp_size (bfd *abfd);
- *Description*
-Return the maximum size of objects to be optimized using the GP
-register under MIPS ECOFF. This is typically set by the `-G' argument
-to the compiler, assembler or linker.
-
-2.3.1.9 `bfd_set_gp_size'
-.........................
-
-*Synopsis*
- void bfd_set_gp_size (bfd *abfd, unsigned int i);
- *Description*
-Set the maximum size of objects to be optimized using the GP register
-under ECOFF or MIPS ELF. This is typically set by the `-G' argument to
-the compiler, assembler or linker.
-
-2.3.1.10 `bfd_scan_vma'
-.......................
-
-*Synopsis*
- bfd_vma bfd_scan_vma (const char *string, const char **end, int base);
- *Description*
-Convert, like `strtoul', a numerical expression STRING into a `bfd_vma'
-integer, and return that integer. (Though without as many bells and
-whistles as `strtoul'.) The expression is assumed to be unsigned
-(i.e., positive). If given a BASE, it is used as the base for
-conversion. A base of 0 causes the function to interpret the string in
-hex if a leading "0x" or "0X" is found, otherwise in octal if a leading
-zero is found, otherwise in decimal.
-
- If the value would overflow, the maximum `bfd_vma' value is returned.
-
-2.3.1.11 `bfd_copy_private_header_data'
-.......................................
-
-*Synopsis*
- bfd_boolean bfd_copy_private_header_data (bfd *ibfd, bfd *obfd);
- *Description*
-Copy private BFD header information from the BFD IBFD to the the BFD
-OBFD. This copies information that may require sections to exist, but
-does not require symbol tables. Return `true' on success, `false' on
-error. Possible error returns are:
-
- * `bfd_error_no_memory' - Not enough memory exists to create private
- data for OBFD.
-
- #define bfd_copy_private_header_data(ibfd, obfd) \
- BFD_SEND (obfd, _bfd_copy_private_header_data, \
- (ibfd, obfd))
-
-2.3.1.12 `bfd_copy_private_bfd_data'
-....................................
-
-*Synopsis*
- bfd_boolean bfd_copy_private_bfd_data (bfd *ibfd, bfd *obfd);
- *Description*
-Copy private BFD information from the BFD IBFD to the the BFD OBFD.
-Return `TRUE' on success, `FALSE' on error. Possible error returns are:
-
- * `bfd_error_no_memory' - Not enough memory exists to create private
- data for OBFD.
-
- #define bfd_copy_private_bfd_data(ibfd, obfd) \
- BFD_SEND (obfd, _bfd_copy_private_bfd_data, \
- (ibfd, obfd))
-
-2.3.1.13 `bfd_merge_private_bfd_data'
-.....................................
-
-*Synopsis*
- bfd_boolean bfd_merge_private_bfd_data (bfd *ibfd, bfd *obfd);
- *Description*
-Merge private BFD information from the BFD IBFD to the the output file
-BFD OBFD when linking. Return `TRUE' on success, `FALSE' on error.
-Possible error returns are:
-
- * `bfd_error_no_memory' - Not enough memory exists to create private
- data for OBFD.
-
- #define bfd_merge_private_bfd_data(ibfd, obfd) \
- BFD_SEND (obfd, _bfd_merge_private_bfd_data, \
- (ibfd, obfd))
-
-2.3.1.14 `bfd_set_private_flags'
-................................
-
-*Synopsis*
- bfd_boolean bfd_set_private_flags (bfd *abfd, flagword flags);
- *Description*
-Set private BFD flag information in the BFD ABFD. Return `TRUE' on
-success, `FALSE' on error. Possible error returns are:
-
- * `bfd_error_no_memory' - Not enough memory exists to create private
- data for OBFD.
-
- #define bfd_set_private_flags(abfd, flags) \
- BFD_SEND (abfd, _bfd_set_private_flags, (abfd, flags))
-
-2.3.1.15 `Other functions'
-..........................
-
-*Description*
-The following functions exist but have not yet been documented.
- #define bfd_sizeof_headers(abfd, info) \
- BFD_SEND (abfd, _bfd_sizeof_headers, (abfd, info))
-
- #define bfd_find_nearest_line(abfd, sec, syms, off, file, func, line) \
- BFD_SEND (abfd, _bfd_find_nearest_line, \
- (abfd, sec, syms, off, file, func, line))
-
- #define bfd_find_line(abfd, syms, sym, file, line) \
- BFD_SEND (abfd, _bfd_find_line, \
- (abfd, syms, sym, file, line))
-
- #define bfd_find_inliner_info(abfd, file, func, line) \
- BFD_SEND (abfd, _bfd_find_inliner_info, \
- (abfd, file, func, line))
-
- #define bfd_debug_info_start(abfd) \
- BFD_SEND (abfd, _bfd_debug_info_start, (abfd))
-
- #define bfd_debug_info_end(abfd) \
- BFD_SEND (abfd, _bfd_debug_info_end, (abfd))
-
- #define bfd_debug_info_accumulate(abfd, section) \
- BFD_SEND (abfd, _bfd_debug_info_accumulate, (abfd, section))
-
- #define bfd_stat_arch_elt(abfd, stat) \
- BFD_SEND (abfd, _bfd_stat_arch_elt,(abfd, stat))
-
- #define bfd_update_armap_timestamp(abfd) \
- BFD_SEND (abfd, _bfd_update_armap_timestamp, (abfd))
-
- #define bfd_set_arch_mach(abfd, arch, mach)\
- BFD_SEND ( abfd, _bfd_set_arch_mach, (abfd, arch, mach))
-
- #define bfd_relax_section(abfd, section, link_info, again) \
- BFD_SEND (abfd, _bfd_relax_section, (abfd, section, link_info, again))
-
- #define bfd_gc_sections(abfd, link_info) \
- BFD_SEND (abfd, _bfd_gc_sections, (abfd, link_info))
-
- #define bfd_merge_sections(abfd, link_info) \
- BFD_SEND (abfd, _bfd_merge_sections, (abfd, link_info))
-
- #define bfd_is_group_section(abfd, sec) \
- BFD_SEND (abfd, _bfd_is_group_section, (abfd, sec))
-
- #define bfd_discard_group(abfd, sec) \
- BFD_SEND (abfd, _bfd_discard_group, (abfd, sec))
-
- #define bfd_link_hash_table_create(abfd) \
- BFD_SEND (abfd, _bfd_link_hash_table_create, (abfd))
-
- #define bfd_link_hash_table_free(abfd, hash) \
- BFD_SEND (abfd, _bfd_link_hash_table_free, (hash))
-
- #define bfd_link_add_symbols(abfd, info) \
- BFD_SEND (abfd, _bfd_link_add_symbols, (abfd, info))
-
- #define bfd_link_just_syms(abfd, sec, info) \
- BFD_SEND (abfd, _bfd_link_just_syms, (sec, info))
-
- #define bfd_final_link(abfd, info) \
- BFD_SEND (abfd, _bfd_final_link, (abfd, info))
-
- #define bfd_free_cached_info(abfd) \
- BFD_SEND (abfd, _bfd_free_cached_info, (abfd))
-
- #define bfd_get_dynamic_symtab_upper_bound(abfd) \
- BFD_SEND (abfd, _bfd_get_dynamic_symtab_upper_bound, (abfd))
-
- #define bfd_print_private_bfd_data(abfd, file)\
- BFD_SEND (abfd, _bfd_print_private_bfd_data, (abfd, file))
-
- #define bfd_canonicalize_dynamic_symtab(abfd, asymbols) \
- BFD_SEND (abfd, _bfd_canonicalize_dynamic_symtab, (abfd, asymbols))
-
- #define bfd_get_synthetic_symtab(abfd, count, syms, dyncount, dynsyms, ret) \
- BFD_SEND (abfd, _bfd_get_synthetic_symtab, (abfd, count, syms, \
- dyncount, dynsyms, ret))
-
- #define bfd_get_dynamic_reloc_upper_bound(abfd) \
- BFD_SEND (abfd, _bfd_get_dynamic_reloc_upper_bound, (abfd))
-
- #define bfd_canonicalize_dynamic_reloc(abfd, arels, asyms) \
- BFD_SEND (abfd, _bfd_canonicalize_dynamic_reloc, (abfd, arels, asyms))
-
- extern bfd_byte *bfd_get_relocated_section_contents
- (bfd *, struct bfd_link_info *, struct bfd_link_order *, bfd_byte *,
- bfd_boolean, asymbol **);
-
-2.3.1.16 `bfd_alt_mach_code'
-............................
-
-*Synopsis*
- bfd_boolean bfd_alt_mach_code (bfd *abfd, int alternative);
- *Description*
-When more than one machine code number is available for the same
-machine type, this function can be used to switch between the preferred
-one (alternative == 0) and any others. Currently, only ELF supports
-this feature, with up to two alternate machine codes.
-
- struct bfd_preserve
- {
- void *marker;
- void *tdata;
- flagword flags;
- const struct bfd_arch_info *arch_info;
- struct bfd_section *sections;
- struct bfd_section *section_last;
- unsigned int section_count;
- struct bfd_hash_table section_htab;
- };
-
-2.3.1.17 `bfd_preserve_save'
-............................
-
-*Synopsis*
- bfd_boolean bfd_preserve_save (bfd *, struct bfd_preserve *);
- *Description*
-When testing an object for compatibility with a particular target
-back-end, the back-end object_p function needs to set up certain fields
-in the bfd on successfully recognizing the object. This typically
-happens in a piecemeal fashion, with failures possible at many points.
-On failure, the bfd is supposed to be restored to its initial state,
-which is virtually impossible. However, restoring a subset of the bfd
-state works in practice. This function stores the subset and
-reinitializes the bfd.
-
-2.3.1.18 `bfd_preserve_restore'
-...............................
-
-*Synopsis*
- void bfd_preserve_restore (bfd *, struct bfd_preserve *);
- *Description*
-This function restores bfd state saved by bfd_preserve_save. If MARKER
-is non-NULL in struct bfd_preserve then that block and all subsequently
-bfd_alloc'd memory is freed.
-
-2.3.1.19 `bfd_preserve_finish'
-..............................
-
-*Synopsis*
- void bfd_preserve_finish (bfd *, struct bfd_preserve *);
- *Description*
-This function should be called when the bfd state saved by
-bfd_preserve_save is no longer needed. ie. when the back-end object_p
-function returns with success.
-
-2.3.1.20 `bfd_emul_get_maxpagesize'
-...................................
-
-*Synopsis*
- bfd_vma bfd_emul_get_maxpagesize (const char *);
- *Description*
-Returns the maximum page size, in bytes, as determined by emulation.
-
- *Returns*
-Returns the maximum page size in bytes for ELF, 0 otherwise.
-
-2.3.1.21 `bfd_emul_set_maxpagesize'
-...................................
-
-*Synopsis*
- void bfd_emul_set_maxpagesize (const char *, bfd_vma);
- *Description*
-For ELF, set the maximum page size for the emulation. It is a no-op
-for other formats.
-
-2.3.1.22 `bfd_emul_get_commonpagesize'
-......................................
-
-*Synopsis*
- bfd_vma bfd_emul_get_commonpagesize (const char *);
- *Description*
-Returns the common page size, in bytes, as determined by emulation.
-
- *Returns*
-Returns the common page size in bytes for ELF, 0 otherwise.
-
-2.3.1.23 `bfd_emul_set_commonpagesize'
-......................................
-
-*Synopsis*
- void bfd_emul_set_commonpagesize (const char *, bfd_vma);
- *Description*
-For ELF, set the common page size for the emulation. It is a no-op for
-other formats.
-
-2.3.1.24 `bfd_demangle'
-.......................
-
-*Synopsis*
- char *bfd_demangle (bfd *, const char *, int);
- *Description*
-Wrapper around cplus_demangle. Strips leading underscores and other
-such chars that would otherwise confuse the demangler. If passed a g++
-v3 ABI mangled name, returns a buffer allocated with malloc holding the
-demangled name. Returns NULL otherwise and on memory alloc failure.
-
-2.3.1.25 `struct bfd_iovec'
-...........................
-
-*Description*
-The `struct bfd_iovec' contains the internal file I/O class. Each
-`BFD' has an instance of this class and all file I/O is routed through
-it (it is assumed that the instance implements all methods listed
-below).
- struct bfd_iovec
- {
- /* To avoid problems with macros, a "b" rather than "f"
- prefix is prepended to each method name. */
- /* Attempt to read/write NBYTES on ABFD's IOSTREAM storing/fetching
- bytes starting at PTR. Return the number of bytes actually
- transfered (a read past end-of-file returns less than NBYTES),
- or -1 (setting `bfd_error') if an error occurs. */
- file_ptr (*bread) (struct bfd *abfd, void *ptr, file_ptr nbytes);
- file_ptr (*bwrite) (struct bfd *abfd, const void *ptr,
- file_ptr nbytes);
- /* Return the current IOSTREAM file offset, or -1 (setting `bfd_error'
- if an error occurs. */
- file_ptr (*btell) (struct bfd *abfd);
- /* For the following, on successful completion a value of 0 is returned.
- Otherwise, a value of -1 is returned (and `bfd_error' is set). */
- int (*bseek) (struct bfd *abfd, file_ptr offset, int whence);
- int (*bclose) (struct bfd *abfd);
- int (*bflush) (struct bfd *abfd);
- int (*bstat) (struct bfd *abfd, struct stat *sb);
- /* Just like mmap: (void*)-1 on failure, mmapped address on success. */
- void *(*bmmap) (struct bfd *abfd, void *addr, bfd_size_type len,
- int prot, int flags, file_ptr offset);
- };
- extern const struct bfd_iovec _bfd_memory_iovec;
-
-2.3.1.26 `bfd_get_mtime'
-........................
-
-*Synopsis*
- long bfd_get_mtime (bfd *abfd);
- *Description*
-Return the file modification time (as read from the file system, or
-from the archive header for archive members).
-
-2.3.1.27 `bfd_get_size'
-.......................
-
-*Synopsis*
- file_ptr bfd_get_size (bfd *abfd);
- *Description*
-Return the file size (as read from file system) for the file associated
-with BFD ABFD.
-
- The initial motivation for, and use of, this routine is not so we
-can get the exact size of the object the BFD applies to, since that
-might not be generally possible (archive members for example). It
-would be ideal if someone could eventually modify it so that such
-results were guaranteed.
-
- Instead, we want to ask questions like "is this NNN byte sized
-object I'm about to try read from file offset YYY reasonable?" As as
-example of where we might do this, some object formats use string
-tables for which the first `sizeof (long)' bytes of the table contain
-the size of the table itself, including the size bytes. If an
-application tries to read what it thinks is one of these string tables,
-without some way to validate the size, and for some reason the size is
-wrong (byte swapping error, wrong location for the string table, etc.),
-the only clue is likely to be a read error when it tries to read the
-table, or a "virtual memory exhausted" error when it tries to allocate
-15 bazillon bytes of space for the 15 bazillon byte table it is about
-to read. This function at least allows us to answer the question, "is
-the size reasonable?".
-
-2.3.1.28 `bfd_mmap'
-...................
-
-*Synopsis*
- void *bfd_mmap (bfd *abfd, void *addr, bfd_size_type len,
- int prot, int flags, file_ptr offset);
- *Description*
-Return mmap()ed region of the file, if possible and implemented.
-
-* Menu:
-
-* Memory Usage::
-* Initialization::
-* Sections::
-* Symbols::
-* Archives::
-* Formats::
-* Relocations::
-* Core Files::
-* Targets::
-* Architectures::
-* Opening and Closing::
-* Internal::
-* File Caching::
-* Linker Functions::
-* Hash Tables::
-
-
-File: bfd.info, Node: Memory Usage, Next: Initialization, Prev: BFD front end, Up: BFD front end
-
-2.4 Memory Usage
-================
-
-BFD keeps all of its internal structures in obstacks. There is one
-obstack per open BFD file, into which the current state is stored. When
-a BFD is closed, the obstack is deleted, and so everything which has
-been allocated by BFD for the closing file is thrown away.
-
- BFD does not free anything created by an application, but pointers
-into `bfd' structures become invalid on a `bfd_close'; for example,
-after a `bfd_close' the vector passed to `bfd_canonicalize_symtab' is
-still around, since it has been allocated by the application, but the
-data that it pointed to are lost.
-
- The general rule is to not close a BFD until all operations dependent
-upon data from the BFD have been completed, or all the data from within
-the file has been copied. To help with the management of memory, there
-is a function (`bfd_alloc_size') which returns the number of bytes in
-obstacks associated with the supplied BFD. This could be used to select
-the greediest open BFD, close it to reclaim the memory, perform some
-operation and reopen the BFD again, to get a fresh copy of the data
-structures.
-
-
-File: bfd.info, Node: Initialization, Next: Sections, Prev: Memory Usage, Up: BFD front end
-
-2.5 Initialization
-==================
-
-2.5.1 Initialization functions
-------------------------------
-
-These are the functions that handle initializing a BFD.
-
-2.5.1.1 `bfd_init'
-..................
-
-*Synopsis*
- void bfd_init (void);
- *Description*
-This routine must be called before any other BFD function to initialize
-magical internal data structures.
-
-
-File: bfd.info, Node: Sections, Next: Symbols, Prev: Initialization, Up: BFD front end
-
-2.6 Sections
-============
-
-The raw data contained within a BFD is maintained through the section
-abstraction. A single BFD may have any number of sections. It keeps
-hold of them by pointing to the first; each one points to the next in
-the list.
-
- Sections are supported in BFD in `section.c'.
-
-* Menu:
-
-* Section Input::
-* Section Output::
-* typedef asection::
-* section prototypes::
-
-
-File: bfd.info, Node: Section Input, Next: Section Output, Prev: Sections, Up: Sections
-
-2.6.1 Section input
--------------------
-
-When a BFD is opened for reading, the section structures are created
-and attached to the BFD.
-
- Each section has a name which describes the section in the outside
-world--for example, `a.out' would contain at least three sections,
-called `.text', `.data' and `.bss'.
-
- Names need not be unique; for example a COFF file may have several
-sections named `.data'.
-
- Sometimes a BFD will contain more than the "natural" number of
-sections. A back end may attach other sections containing constructor
-data, or an application may add a section (using `bfd_make_section') to
-the sections attached to an already open BFD. For example, the linker
-creates an extra section `COMMON' for each input file's BFD to hold
-information about common storage.
-
- The raw data is not necessarily read in when the section descriptor
-is created. Some targets may leave the data in place until a
-`bfd_get_section_contents' call is made. Other back ends may read in
-all the data at once. For example, an S-record file has to be read
-once to determine the size of the data. An IEEE-695 file doesn't
-contain raw data in sections, but data and relocation expressions
-intermixed, so the data area has to be parsed to get out the data and
-relocations.
-
-
-File: bfd.info, Node: Section Output, Next: typedef asection, Prev: Section Input, Up: Sections
-
-2.6.2 Section output
---------------------
-
-To write a new object style BFD, the various sections to be written
-have to be created. They are attached to the BFD in the same way as
-input sections; data is written to the sections using
-`bfd_set_section_contents'.
-
- Any program that creates or combines sections (e.g., the assembler
-and linker) must use the `asection' fields `output_section' and
-`output_offset' to indicate the file sections to which each section
-must be written. (If the section is being created from scratch,
-`output_section' should probably point to the section itself and
-`output_offset' should probably be zero.)
-
- The data to be written comes from input sections attached (via
-`output_section' pointers) to the output sections. The output section
-structure can be considered a filter for the input section: the output
-section determines the vma of the output data and the name, but the
-input section determines the offset into the output section of the data
-to be written.
-
- E.g., to create a section "O", starting at 0x100, 0x123 long,
-containing two subsections, "A" at offset 0x0 (i.e., at vma 0x100) and
-"B" at offset 0x20 (i.e., at vma 0x120) the `asection' structures would
-look like:
-
- section name "A"
- output_offset 0x00
- size 0x20
- output_section -----------> section name "O"
- | vma 0x100
- section name "B" | size 0x123
- output_offset 0x20 |
- size 0x103 |
- output_section --------|
-
-2.6.3 Link orders
------------------
-
-The data within a section is stored in a "link_order". These are much
-like the fixups in `gas'. The link_order abstraction allows a section
-to grow and shrink within itself.
-
- A link_order knows how big it is, and which is the next link_order
-and where the raw data for it is; it also points to a list of
-relocations which apply to it.
-
- The link_order is used by the linker to perform relaxing on final
-code. The compiler creates code which is as big as necessary to make
-it work without relaxing, and the user can select whether to relax.
-Sometimes relaxing takes a lot of time. The linker runs around the
-relocations to see if any are attached to data which can be shrunk, if
-so it does it on a link_order by link_order basis.
-
-
-File: bfd.info, Node: typedef asection, Next: section prototypes, Prev: Section Output, Up: Sections
-
-2.6.4 typedef asection
-----------------------
-
-Here is the section structure:
-
-
- typedef struct bfd_section
- {
- /* The name of the section; the name isn't a copy, the pointer is
- the same as that passed to bfd_make_section. */
- const char *name;
-
- /* A unique sequence number. */
- int id;
-
- /* Which section in the bfd; 0..n-1 as sections are created in a bfd. */
- int index;
-
- /* The next section in the list belonging to the BFD, or NULL. */
- struct bfd_section *next;
-
- /* The previous section in the list belonging to the BFD, or NULL. */
- struct bfd_section *prev;
-
- /* The field flags contains attributes of the section. Some
- flags are read in from the object file, and some are
- synthesized from other information. */
- flagword flags;
-
- #define SEC_NO_FLAGS 0x000
-
- /* Tells the OS to allocate space for this section when loading.
- This is clear for a section containing debug information only. */
- #define SEC_ALLOC 0x001
-
- /* Tells the OS to load the section from the file when loading.
- This is clear for a .bss section. */
- #define SEC_LOAD 0x002
-
- /* The section contains data still to be relocated, so there is
- some relocation information too. */
- #define SEC_RELOC 0x004
-
- /* A signal to the OS that the section contains read only data. */
- #define SEC_READONLY 0x008
-
- /* The section contains code only. */
- #define SEC_CODE 0x010
-
- /* The section contains data only. */
- #define SEC_DATA 0x020
-
- /* The section will reside in ROM. */
- #define SEC_ROM 0x040
-
- /* The section contains constructor information. This section
- type is used by the linker to create lists of constructors and
- destructors used by `g++'. When a back end sees a symbol
- which should be used in a constructor list, it creates a new
- section for the type of name (e.g., `__CTOR_LIST__'), attaches
- the symbol to it, and builds a relocation. To build the lists
- of constructors, all the linker has to do is catenate all the
- sections called `__CTOR_LIST__' and relocate the data
- contained within - exactly the operations it would peform on
- standard data. */
- #define SEC_CONSTRUCTOR 0x080
-
- /* The section has contents - a data section could be
- `SEC_ALLOC' | `SEC_HAS_CONTENTS'; a debug section could be
- `SEC_HAS_CONTENTS' */
- #define SEC_HAS_CONTENTS 0x100
-
- /* An instruction to the linker to not output the section
- even if it has information which would normally be written. */
- #define SEC_NEVER_LOAD 0x200
-
- /* The section contains thread local data. */
- #define SEC_THREAD_LOCAL 0x400
-
- /* The section has GOT references. This flag is only for the
- linker, and is currently only used by the elf32-hppa back end.
- It will be set if global offset table references were detected
- in this section, which indicate to the linker that the section
- contains PIC code, and must be handled specially when doing a
- static link. */
- #define SEC_HAS_GOT_REF 0x800
-
- /* The section contains common symbols (symbols may be defined
- multiple times, the value of a symbol is the amount of
- space it requires, and the largest symbol value is the one
- used). Most targets have exactly one of these (which we
- translate to bfd_com_section_ptr), but ECOFF has two. */
- #define SEC_IS_COMMON 0x1000
-
- /* The section contains only debugging information. For
- example, this is set for ELF .debug and .stab sections.
- strip tests this flag to see if a section can be
- discarded. */
- #define SEC_DEBUGGING 0x2000
-
- /* The contents of this section are held in memory pointed to
- by the contents field. This is checked by bfd_get_section_contents,
- and the data is retrieved from memory if appropriate. */
- #define SEC_IN_MEMORY 0x4000
-
- /* The contents of this section are to be excluded by the
- linker for executable and shared objects unless those
- objects are to be further relocated. */
- #define SEC_EXCLUDE 0x8000
-
- /* The contents of this section are to be sorted based on the sum of
- the symbol and addend values specified by the associated relocation
- entries. Entries without associated relocation entries will be
- appended to the end of the section in an unspecified order. */
- #define SEC_SORT_ENTRIES 0x10000
-
- /* When linking, duplicate sections of the same name should be
- discarded, rather than being combined into a single section as
- is usually done. This is similar to how common symbols are
- handled. See SEC_LINK_DUPLICATES below. */
- #define SEC_LINK_ONCE 0x20000
-
- /* If SEC_LINK_ONCE is set, this bitfield describes how the linker
- should handle duplicate sections. */
- #define SEC_LINK_DUPLICATES 0xc0000
-
- /* This value for SEC_LINK_DUPLICATES means that duplicate
- sections with the same name should simply be discarded. */
- #define SEC_LINK_DUPLICATES_DISCARD 0x0
-
- /* This value for SEC_LINK_DUPLICATES means that the linker
- should warn if there are any duplicate sections, although
- it should still only link one copy. */
- #define SEC_LINK_DUPLICATES_ONE_ONLY 0x40000
-
- /* This value for SEC_LINK_DUPLICATES means that the linker
- should warn if any duplicate sections are a different size. */
- #define SEC_LINK_DUPLICATES_SAME_SIZE 0x80000
-
- /* This value for SEC_LINK_DUPLICATES means that the linker
- should warn if any duplicate sections contain different
- contents. */
- #define SEC_LINK_DUPLICATES_SAME_CONTENTS \
- (SEC_LINK_DUPLICATES_ONE_ONLY | SEC_LINK_DUPLICATES_SAME_SIZE)
-
- /* This section was created by the linker as part of dynamic
- relocation or other arcane processing. It is skipped when
- going through the first-pass output, trusting that someone
- else up the line will take care of it later. */
- #define SEC_LINKER_CREATED 0x100000
-
- /* This section should not be subject to garbage collection.
- Also set to inform the linker that this section should not be
- listed in the link map as discarded. */
- #define SEC_KEEP 0x200000
-
- /* This section contains "short" data, and should be placed
- "near" the GP. */
- #define SEC_SMALL_DATA 0x400000
-
- /* Attempt to merge identical entities in the section.
- Entity size is given in the entsize field. */
- #define SEC_MERGE 0x800000
-
- /* If given with SEC_MERGE, entities to merge are zero terminated
- strings where entsize specifies character size instead of fixed
- size entries. */
- #define SEC_STRINGS 0x1000000
-
- /* This section contains data about section groups. */
- #define SEC_GROUP 0x2000000
-
- /* The section is a COFF shared library section. This flag is
- only for the linker. If this type of section appears in
- the input file, the linker must copy it to the output file
- without changing the vma or size. FIXME: Although this
- was originally intended to be general, it really is COFF
- specific (and the flag was renamed to indicate this). It
- might be cleaner to have some more general mechanism to
- allow the back end to control what the linker does with
- sections. */
- #define SEC_COFF_SHARED_LIBRARY 0x4000000
-
- /* This section contains data which may be shared with other
- executables or shared objects. This is for COFF only. */
- #define SEC_COFF_SHARED 0x8000000
-
- /* When a section with this flag is being linked, then if the size of
- the input section is less than a page, it should not cross a page
- boundary. If the size of the input section is one page or more,
- it should be aligned on a page boundary. This is for TI
- TMS320C54X only. */
- #define SEC_TIC54X_BLOCK 0x10000000
-
- /* Conditionally link this section; do not link if there are no
- references found to any symbol in the section. This is for TI
- TMS320C54X only. */
- #define SEC_TIC54X_CLINK 0x20000000
-
- /* Indicate that section has the no read flag set. This happens
- when memory read flag isn't set. */
- #define SEC_COFF_NOREAD 0x40000000
-
- /* End of section flags. */
-
- /* Some internal packed boolean fields. */
-
- /* See the vma field. */
- unsigned int user_set_vma : 1;
-
- /* A mark flag used by some of the linker backends. */
- unsigned int linker_mark : 1;
-
- /* Another mark flag used by some of the linker backends. Set for
- output sections that have an input section. */
- unsigned int linker_has_input : 1;
-
- /* Mark flag used by some linker backends for garbage collection. */
- unsigned int gc_mark : 1;
-
- /* Section compression status. */
- unsigned int compress_status : 2;
- #define COMPRESS_SECTION_NONE 0
- #define COMPRESS_SECTION_DONE 1
- #define DECOMPRESS_SECTION_SIZED 2
-
- /* The following flags are used by the ELF linker. */
-
- /* Mark sections which have been allocated to segments. */
- unsigned int segment_mark : 1;
-
- /* Type of sec_info information. */
- unsigned int sec_info_type:3;
- #define ELF_INFO_TYPE_NONE 0
- #define ELF_INFO_TYPE_STABS 1
- #define ELF_INFO_TYPE_MERGE 2
- #define ELF_INFO_TYPE_EH_FRAME 3
- #define ELF_INFO_TYPE_JUST_SYMS 4
-
- /* Nonzero if this section uses RELA relocations, rather than REL. */
- unsigned int use_rela_p:1;
-
- /* Bits used by various backends. The generic code doesn't touch
- these fields. */
-
- unsigned int sec_flg0:1;
- unsigned int sec_flg1:1;
- unsigned int sec_flg2:1;
- unsigned int sec_flg3:1;
- unsigned int sec_flg4:1;
- unsigned int sec_flg5:1;
-
- /* End of internal packed boolean fields. */
-
- /* The virtual memory address of the section - where it will be
- at run time. The symbols are relocated against this. The
- user_set_vma flag is maintained by bfd; if it's not set, the
- backend can assign addresses (for example, in `a.out', where
- the default address for `.data' is dependent on the specific
- target and various flags). */
- bfd_vma vma;
-
- /* The load address of the section - where it would be in a
- rom image; really only used for writing section header
- information. */
- bfd_vma lma;
-
- /* The size of the section in octets, as it will be output.
- Contains a value even if the section has no contents (e.g., the
- size of `.bss'). */
- bfd_size_type size;
-
- /* For input sections, the original size on disk of the section, in
- octets. This field should be set for any section whose size is
- changed by linker relaxation. It is required for sections where
- the linker relaxation scheme doesn't cache altered section and
- reloc contents (stabs, eh_frame, SEC_MERGE, some coff relaxing
- targets), and thus the original size needs to be kept to read the
- section multiple times. For output sections, rawsize holds the
- section size calculated on a previous linker relaxation pass. */
- bfd_size_type rawsize;
-
- /* The compressed size of the section in octets. */
- bfd_size_type compressed_size;
-
- /* Relaxation table. */
- struct relax_table *relax;
-
- /* Count of used relaxation table entries. */
- int relax_count;
-
-
- /* If this section is going to be output, then this value is the
- offset in *bytes* into the output section of the first byte in the
- input section (byte ==> smallest addressable unit on the
- target). In most cases, if this was going to start at the
- 100th octet (8-bit quantity) in the output section, this value
- would be 100. However, if the target byte size is 16 bits
- (bfd_octets_per_byte is "2"), this value would be 50. */
- bfd_vma output_offset;
-
- /* The output section through which to map on output. */
- struct bfd_section *output_section;
-
- /* The alignment requirement of the section, as an exponent of 2 -
- e.g., 3 aligns to 2^3 (or 8). */
- unsigned int alignment_power;
-
- /* If an input section, a pointer to a vector of relocation
- records for the data in this section. */
- struct reloc_cache_entry *relocation;
-
- /* If an output section, a pointer to a vector of pointers to
- relocation records for the data in this section. */
- struct reloc_cache_entry **orelocation;
-
- /* The number of relocation records in one of the above. */
- unsigned reloc_count;
-
- /* Information below is back end specific - and not always used
- or updated. */
-
- /* File position of section data. */
- file_ptr filepos;
-
- /* File position of relocation info. */
- file_ptr rel_filepos;
-
- /* File position of line data. */
- file_ptr line_filepos;
-
- /* Pointer to data for applications. */
- void *userdata;
-
- /* If the SEC_IN_MEMORY flag is set, this points to the actual
- contents. */
- unsigned char *contents;
-
- /* Attached line number information. */
- alent *lineno;
-
- /* Number of line number records. */
- unsigned int lineno_count;
-
- /* Entity size for merging purposes. */
- unsigned int entsize;
-
- /* Points to the kept section if this section is a link-once section,
- and is discarded. */
- struct bfd_section *kept_section;
-
- /* When a section is being output, this value changes as more
- linenumbers are written out. */
- file_ptr moving_line_filepos;
-
- /* What the section number is in the target world. */
- int target_index;
-
- void *used_by_bfd;
-
- /* If this is a constructor section then here is a list of the
- relocations created to relocate items within it. */
- struct relent_chain *constructor_chain;
-
- /* The BFD which owns the section. */
- bfd *owner;
-
- /* A symbol which points at this section only. */
- struct bfd_symbol *symbol;
- struct bfd_symbol **symbol_ptr_ptr;
-
- /* Early in the link process, map_head and map_tail are used to build
- a list of input sections attached to an output section. Later,
- output sections use these fields for a list of bfd_link_order
- structs. */
- union {
- struct bfd_link_order *link_order;
- struct bfd_section *s;
- } map_head, map_tail;
- } asection;
-
- /* Relax table contains information about instructions which can
- be removed by relaxation -- replacing a long address with a
- short address. */
- struct relax_table {
- /* Address where bytes may be deleted. */
- bfd_vma addr;
-
- /* Number of bytes to be deleted. */
- int size;
- };
-
- /* These sections are global, and are managed by BFD. The application
- and target back end are not permitted to change the values in
- these sections. New code should use the section_ptr macros rather
- than referring directly to the const sections. The const sections
- may eventually vanish. */
- #define BFD_ABS_SECTION_NAME "*ABS*"
- #define BFD_UND_SECTION_NAME "*UND*"
- #define BFD_COM_SECTION_NAME "*COM*"
- #define BFD_IND_SECTION_NAME "*IND*"
-
- /* The absolute section. */
- extern asection bfd_abs_section;
- #define bfd_abs_section_ptr ((asection *) &bfd_abs_section)
- #define bfd_is_abs_section(sec) ((sec) == bfd_abs_section_ptr)
- /* Pointer to the undefined section. */
- extern asection bfd_und_section;
- #define bfd_und_section_ptr ((asection *) &bfd_und_section)
- #define bfd_is_und_section(sec) ((sec) == bfd_und_section_ptr)
- /* Pointer to the common section. */
- extern asection bfd_com_section;
- #define bfd_com_section_ptr ((asection *) &bfd_com_section)
- /* Pointer to the indirect section. */
- extern asection bfd_ind_section;
- #define bfd_ind_section_ptr ((asection *) &bfd_ind_section)
- #define bfd_is_ind_section(sec) ((sec) == bfd_ind_section_ptr)
-
- #define bfd_is_const_section(SEC) \
- ( ((SEC) == bfd_abs_section_ptr) \
- || ((SEC) == bfd_und_section_ptr) \
- || ((SEC) == bfd_com_section_ptr) \
- || ((SEC) == bfd_ind_section_ptr))
-
- /* Macros to handle insertion and deletion of a bfd's sections. These
- only handle the list pointers, ie. do not adjust section_count,
- target_index etc. */
- #define bfd_section_list_remove(ABFD, S) \
- do \
- { \
- asection *_s = S; \
- asection *_next = _s->next; \
- asection *_prev = _s->prev; \
- if (_prev) \
- _prev->next = _next; \
- else \
- (ABFD)->sections = _next; \
- if (_next) \
- _next->prev = _prev; \
- else \
- (ABFD)->section_last = _prev; \
- } \
- while (0)
- #define bfd_section_list_append(ABFD, S) \
- do \
- { \
- asection *_s = S; \
- bfd *_abfd = ABFD; \
- _s->next = NULL; \
- if (_abfd->section_last) \
- { \
- _s->prev = _abfd->section_last; \
- _abfd->section_last->next = _s; \
- } \
- else \
- { \
- _s->prev = NULL; \
- _abfd->sections = _s; \
- } \
- _abfd->section_last = _s; \
- } \
- while (0)
- #define bfd_section_list_prepend(ABFD, S) \
- do \
- { \
- asection *_s = S; \
- bfd *_abfd = ABFD; \
- _s->prev = NULL; \
- if (_abfd->sections) \
- { \
- _s->next = _abfd->sections; \
- _abfd->sections->prev = _s; \
- } \
- else \
- { \
- _s->next = NULL; \
- _abfd->section_last = _s; \
- } \
- _abfd->sections = _s; \
- } \
- while (0)
- #define bfd_section_list_insert_after(ABFD, A, S) \
- do \
- { \
- asection *_a = A; \
- asection *_s = S; \
- asection *_next = _a->next; \
- _s->next = _next; \
- _s->prev = _a; \
- _a->next = _s; \
- if (_next) \
- _next->prev = _s; \
- else \
- (ABFD)->section_last = _s; \
- } \
- while (0)
- #define bfd_section_list_insert_before(ABFD, B, S) \
- do \
- { \
- asection *_b = B; \
- asection *_s = S; \
- asection *_prev = _b->prev; \
- _s->prev = _prev; \
- _s->next = _b; \
- _b->prev = _s; \
- if (_prev) \
- _prev->next = _s; \
- else \
- (ABFD)->sections = _s; \
- } \
- while (0)
- #define bfd_section_removed_from_list(ABFD, S) \
- ((S)->next == NULL ? (ABFD)->section_last != (S) : (S)->next->prev != (S))
-
- #define BFD_FAKE_SECTION(SEC, FLAGS, SYM, NAME, IDX) \
- /* name, id, index, next, prev, flags, user_set_vma, */ \
- { NAME, IDX, 0, NULL, NULL, FLAGS, 0, \
- \
- /* linker_mark, linker_has_input, gc_mark, decompress_status, */ \
- 0, 0, 1, 0, \
- \
- /* segment_mark, sec_info_type, use_rela_p, */ \
- 0, 0, 0, \
- \
- /* sec_flg0, sec_flg1, sec_flg2, sec_flg3, sec_flg4, sec_flg5, */ \
- 0, 0, 0, 0, 0, 0, \
- \
- /* vma, lma, size, rawsize, compressed_size, relax, relax_count, */ \
- 0, 0, 0, 0, 0, 0, 0, \
- \
- /* output_offset, output_section, alignment_power, */ \
- 0, (struct bfd_section *) &SEC, 0, \
- \
- /* relocation, orelocation, reloc_count, filepos, rel_filepos, */ \
- NULL, NULL, 0, 0, 0, \
- \
- /* line_filepos, userdata, contents, lineno, lineno_count, */ \
- 0, NULL, NULL, NULL, 0, \
- \
- /* entsize, kept_section, moving_line_filepos, */ \
- 0, NULL, 0, \
- \
- /* target_index, used_by_bfd, constructor_chain, owner, */ \
- 0, NULL, NULL, NULL, \
- \
- /* symbol, symbol_ptr_ptr, */ \
- (struct bfd_symbol *) SYM, &SEC.symbol, \
- \
- /* map_head, map_tail */ \
- { NULL }, { NULL } \
- }
-
-
-File: bfd.info, Node: section prototypes, Prev: typedef asection, Up: Sections
-
-2.6.5 Section prototypes
-------------------------
-
-These are the functions exported by the section handling part of BFD.
-
-2.6.5.1 `bfd_section_list_clear'
-................................
-
-*Synopsis*
- void bfd_section_list_clear (bfd *);
- *Description*
-Clears the section list, and also resets the section count and hash
-table entries.
-
-2.6.5.2 `bfd_get_section_by_name'
-.................................
-
-*Synopsis*
- asection *bfd_get_section_by_name (bfd *abfd, const char *name);
- *Description*
-Run through ABFD and return the one of the `asection's whose name
-matches NAME, otherwise `NULL'. *Note Sections::, for more information.
-
- This should only be used in special cases; the normal way to process
-all sections of a given name is to use `bfd_map_over_sections' and
-`strcmp' on the name (or better yet, base it on the section flags or
-something else) for each section.
-
-2.6.5.3 `bfd_get_section_by_name_if'
-....................................
-
-*Synopsis*
- asection *bfd_get_section_by_name_if
- (bfd *abfd,
- const char *name,
- bfd_boolean (*func) (bfd *abfd, asection *sect, void *obj),
- void *obj);
- *Description*
-Call the provided function FUNC for each section attached to the BFD
-ABFD whose name matches NAME, passing OBJ as an argument. The function
-will be called as if by
-
- func (abfd, the_section, obj);
-
- It returns the first section for which FUNC returns true, otherwise
-`NULL'.
-
-2.6.5.4 `bfd_get_unique_section_name'
-.....................................
-
-*Synopsis*
- char *bfd_get_unique_section_name
- (bfd *abfd, const char *templat, int *count);
- *Description*
-Invent a section name that is unique in ABFD by tacking a dot and a
-digit suffix onto the original TEMPLAT. If COUNT is non-NULL, then it
-specifies the first number tried as a suffix to generate a unique name.
-The value pointed to by COUNT will be incremented in this case.
-
-2.6.5.5 `bfd_make_section_old_way'
-..................................
-
-*Synopsis*
- asection *bfd_make_section_old_way (bfd *abfd, const char *name);
- *Description*
-Create a new empty section called NAME and attach it to the end of the
-chain of sections for the BFD ABFD. An attempt to create a section with
-a name which is already in use returns its pointer without changing the
-section chain.
-
- It has the funny name since this is the way it used to be before it
-was rewritten....
-
- Possible errors are:
- * `bfd_error_invalid_operation' - If output has already started for
- this BFD.
-
- * `bfd_error_no_memory' - If memory allocation fails.
-
-2.6.5.6 `bfd_make_section_anyway_with_flags'
-............................................
-
-*Synopsis*
- asection *bfd_make_section_anyway_with_flags
- (bfd *abfd, const char *name, flagword flags);
- *Description*
-Create a new empty section called NAME and attach it to the end of the
-chain of sections for ABFD. Create a new section even if there is
-already a section with that name. Also set the attributes of the new
-section to the value FLAGS.
-
- Return `NULL' and set `bfd_error' on error; possible errors are:
- * `bfd_error_invalid_operation' - If output has already started for
- ABFD.
-
- * `bfd_error_no_memory' - If memory allocation fails.
-
-2.6.5.7 `bfd_make_section_anyway'
-.................................
-
-*Synopsis*
- asection *bfd_make_section_anyway (bfd *abfd, const char *name);
- *Description*
-Create a new empty section called NAME and attach it to the end of the
-chain of sections for ABFD. Create a new section even if there is
-already a section with that name.
-
- Return `NULL' and set `bfd_error' on error; possible errors are:
- * `bfd_error_invalid_operation' - If output has already started for
- ABFD.
-
- * `bfd_error_no_memory' - If memory allocation fails.
-
-2.6.5.8 `bfd_make_section_with_flags'
-.....................................
-
-*Synopsis*
- asection *bfd_make_section_with_flags
- (bfd *, const char *name, flagword flags);
- *Description*
-Like `bfd_make_section_anyway', but return `NULL' (without calling
-bfd_set_error ()) without changing the section chain if there is
-already a section named NAME. Also set the attributes of the new
-section to the value FLAGS. If there is an error, return `NULL' and set
-`bfd_error'.
-
-2.6.5.9 `bfd_make_section'
-..........................
-
-*Synopsis*
- asection *bfd_make_section (bfd *, const char *name);
- *Description*
-Like `bfd_make_section_anyway', but return `NULL' (without calling
-bfd_set_error ()) without changing the section chain if there is
-already a section named NAME. If there is an error, return `NULL' and
-set `bfd_error'.
-
-2.6.5.10 `bfd_set_section_flags'
-................................
-
-*Synopsis*
- bfd_boolean bfd_set_section_flags
- (bfd *abfd, asection *sec, flagword flags);
- *Description*
-Set the attributes of the section SEC in the BFD ABFD to the value
-FLAGS. Return `TRUE' on success, `FALSE' on error. Possible error
-returns are:
-
- * `bfd_error_invalid_operation' - The section cannot have one or
- more of the attributes requested. For example, a .bss section in
- `a.out' may not have the `SEC_HAS_CONTENTS' field set.
-
-2.6.5.11 `bfd_rename_section'
-.............................
-
-*Synopsis*
- void bfd_rename_section
- (bfd *abfd, asection *sec, const char *newname);
- *Description*
-Rename section SEC in ABFD to NEWNAME.
-
-2.6.5.12 `bfd_map_over_sections'
-................................
-
-*Synopsis*
- void bfd_map_over_sections
- (bfd *abfd,
- void (*func) (bfd *abfd, asection *sect, void *obj),
- void *obj);
- *Description*
-Call the provided function FUNC for each section attached to the BFD
-ABFD, passing OBJ as an argument. The function will be called as if by
-
- func (abfd, the_section, obj);
-
- This is the preferred method for iterating over sections; an
-alternative would be to use a loop:
-
- section *p;
- for (p = abfd->sections; p != NULL; p = p->next)
- func (abfd, p, ...)
-
-2.6.5.13 `bfd_sections_find_if'
-...............................
-
-*Synopsis*
- asection *bfd_sections_find_if
- (bfd *abfd,
- bfd_boolean (*operation) (bfd *abfd, asection *sect, void *obj),
- void *obj);
- *Description*
-Call the provided function OPERATION for each section attached to the
-BFD ABFD, passing OBJ as an argument. The function will be called as if
-by
-
- operation (abfd, the_section, obj);
-
- It returns the first section for which OPERATION returns true.
-
-2.6.5.14 `bfd_set_section_size'
-...............................
-
-*Synopsis*
- bfd_boolean bfd_set_section_size
- (bfd *abfd, asection *sec, bfd_size_type val);
- *Description*
-Set SEC to the size VAL. If the operation is ok, then `TRUE' is
-returned, else `FALSE'.
-
- Possible error returns:
- * `bfd_error_invalid_operation' - Writing has started to the BFD, so
- setting the size is invalid.
-
-2.6.5.15 `bfd_set_section_contents'
-...................................
-
-*Synopsis*
- bfd_boolean bfd_set_section_contents
- (bfd *abfd, asection *section, const void *data,
- file_ptr offset, bfd_size_type count);
- *Description*
-Sets the contents of the section SECTION in BFD ABFD to the data
-starting in memory at DATA. The data is written to the output section
-starting at offset OFFSET for COUNT octets.
-
- Normally `TRUE' is returned, else `FALSE'. Possible error returns
-are:
- * `bfd_error_no_contents' - The output section does not have the
- `SEC_HAS_CONTENTS' attribute, so nothing can be written to it.
-
- * and some more too
- This routine is front end to the back end function
-`_bfd_set_section_contents'.
-
-2.6.5.16 `bfd_get_section_contents'
-...................................
-
-*Synopsis*
- bfd_boolean bfd_get_section_contents
- (bfd *abfd, asection *section, void *location, file_ptr offset,
- bfd_size_type count);
- *Description*
-Read data from SECTION in BFD ABFD into memory starting at LOCATION.
-The data is read at an offset of OFFSET from the start of the input
-section, and is read for COUNT bytes.
-
- If the contents of a constructor with the `SEC_CONSTRUCTOR' flag set
-are requested or if the section does not have the `SEC_HAS_CONTENTS'
-flag set, then the LOCATION is filled with zeroes. If no errors occur,
-`TRUE' is returned, else `FALSE'.
-
-2.6.5.17 `bfd_malloc_and_get_section'
-.....................................
-
-*Synopsis*
- bfd_boolean bfd_malloc_and_get_section
- (bfd *abfd, asection *section, bfd_byte **buf);
- *Description*
-Read all data from SECTION in BFD ABFD into a buffer, *BUF, malloc'd by
-this function.
-
-2.6.5.18 `bfd_copy_private_section_data'
-........................................
-
-*Synopsis*
- bfd_boolean bfd_copy_private_section_data
- (bfd *ibfd, asection *isec, bfd *obfd, asection *osec);
- *Description*
-Copy private section information from ISEC in the BFD IBFD to the
-section OSEC in the BFD OBFD. Return `TRUE' on success, `FALSE' on
-error. Possible error returns are:
-
- * `bfd_error_no_memory' - Not enough memory exists to create private
- data for OSEC.
-
- #define bfd_copy_private_section_data(ibfd, isection, obfd, osection) \
- BFD_SEND (obfd, _bfd_copy_private_section_data, \
- (ibfd, isection, obfd, osection))
-
-2.6.5.19 `bfd_generic_is_group_section'
-.......................................
-
-*Synopsis*
- bfd_boolean bfd_generic_is_group_section (bfd *, const asection *sec);
- *Description*
-Returns TRUE if SEC is a member of a group.
-
-2.6.5.20 `bfd_generic_discard_group'
-....................................
-
-*Synopsis*
- bfd_boolean bfd_generic_discard_group (bfd *abfd, asection *group);
- *Description*
-Remove all members of GROUP from the output.
-
-
-File: bfd.info, Node: Symbols, Next: Archives, Prev: Sections, Up: BFD front end
-
-2.7 Symbols
-===========
-
-BFD tries to maintain as much symbol information as it can when it
-moves information from file to file. BFD passes information to
-applications though the `asymbol' structure. When the application
-requests the symbol table, BFD reads the table in the native form and
-translates parts of it into the internal format. To maintain more than
-the information passed to applications, some targets keep some
-information "behind the scenes" in a structure only the particular back
-end knows about. For example, the coff back end keeps the original
-symbol table structure as well as the canonical structure when a BFD is
-read in. On output, the coff back end can reconstruct the output symbol
-table so that no information is lost, even information unique to coff
-which BFD doesn't know or understand. If a coff symbol table were read,
-but were written through an a.out back end, all the coff specific
-information would be lost. The symbol table of a BFD is not necessarily
-read in until a canonicalize request is made. Then the BFD back end
-fills in a table provided by the application with pointers to the
-canonical information. To output symbols, the application provides BFD
-with a table of pointers to pointers to `asymbol's. This allows
-applications like the linker to output a symbol as it was read, since
-the "behind the scenes" information will be still available.
-
-* Menu:
-
-* Reading Symbols::
-* Writing Symbols::
-* Mini Symbols::
-* typedef asymbol::
-* symbol handling functions::
-
-
-File: bfd.info, Node: Reading Symbols, Next: Writing Symbols, Prev: Symbols, Up: Symbols
-
-2.7.1 Reading symbols
----------------------
-
-There are two stages to reading a symbol table from a BFD: allocating
-storage, and the actual reading process. This is an excerpt from an
-application which reads the symbol table:
-
- long storage_needed;
- asymbol **symbol_table;
- long number_of_symbols;
- long i;
-
- storage_needed = bfd_get_symtab_upper_bound (abfd);
-
- if (storage_needed < 0)
- FAIL
-
- if (storage_needed == 0)
- return;
-
- symbol_table = xmalloc (storage_needed);
- ...
- number_of_symbols =
- bfd_canonicalize_symtab (abfd, symbol_table);
-
- if (number_of_symbols < 0)
- FAIL
-
- for (i = 0; i < number_of_symbols; i++)
- process_symbol (symbol_table[i]);
-
- All storage for the symbols themselves is in an objalloc connected
-to the BFD; it is freed when the BFD is closed.
-
-
-File: bfd.info, Node: Writing Symbols, Next: Mini Symbols, Prev: Reading Symbols, Up: Symbols
-
-2.7.2 Writing symbols
----------------------
-
-Writing of a symbol table is automatic when a BFD open for writing is
-closed. The application attaches a vector of pointers to pointers to
-symbols to the BFD being written, and fills in the symbol count. The
-close and cleanup code reads through the table provided and performs
-all the necessary operations. The BFD output code must always be
-provided with an "owned" symbol: one which has come from another BFD,
-or one which has been created using `bfd_make_empty_symbol'. Here is an
-example showing the creation of a symbol table with only one element:
-
- #include "bfd.h"
- int main (void)
- {
- bfd *abfd;
- asymbol *ptrs[2];
- asymbol *new;
-
- abfd = bfd_openw ("foo","a.out-sunos-big");
- bfd_set_format (abfd, bfd_object);
- new = bfd_make_empty_symbol (abfd);
- new->name = "dummy_symbol";
- new->section = bfd_make_section_old_way (abfd, ".text");
- new->flags = BSF_GLOBAL;
- new->value = 0x12345;
-
- ptrs[0] = new;
- ptrs[1] = 0;
-
- bfd_set_symtab (abfd, ptrs, 1);
- bfd_close (abfd);
- return 0;
- }
-
- ./makesym
- nm foo
- 00012345 A dummy_symbol
-
- Many formats cannot represent arbitrary symbol information; for
-instance, the `a.out' object format does not allow an arbitrary number
-of sections. A symbol pointing to a section which is not one of
-`.text', `.data' or `.bss' cannot be described.
-
-
-File: bfd.info, Node: Mini Symbols, Next: typedef asymbol, Prev: Writing Symbols, Up: Symbols
-
-2.7.3 Mini Symbols
-------------------
-
-Mini symbols provide read-only access to the symbol table. They use
-less memory space, but require more time to access. They can be useful
-for tools like nm or objdump, which may have to handle symbol tables of
-extremely large executables.
-
- The `bfd_read_minisymbols' function will read the symbols into
-memory in an internal form. It will return a `void *' pointer to a
-block of memory, a symbol count, and the size of each symbol. The
-pointer is allocated using `malloc', and should be freed by the caller
-when it is no longer needed.
-
- The function `bfd_minisymbol_to_symbol' will take a pointer to a
-minisymbol, and a pointer to a structure returned by
-`bfd_make_empty_symbol', and return a `asymbol' structure. The return
-value may or may not be the same as the value from
-`bfd_make_empty_symbol' which was passed in.
-
-
-File: bfd.info, Node: typedef asymbol, Next: symbol handling functions, Prev: Mini Symbols, Up: Symbols
-
-2.7.4 typedef asymbol
----------------------
-
-An `asymbol' has the form:
-
-
- typedef struct bfd_symbol
- {
- /* A pointer to the BFD which owns the symbol. This information
- is necessary so that a back end can work out what additional
- information (invisible to the application writer) is carried
- with the symbol.
-
- This field is *almost* redundant, since you can use section->owner
- instead, except that some symbols point to the global sections
- bfd_{abs,com,und}_section. This could be fixed by making
- these globals be per-bfd (or per-target-flavor). FIXME. */
- struct bfd *the_bfd; /* Use bfd_asymbol_bfd(sym) to access this field. */
-
- /* The text of the symbol. The name is left alone, and not copied; the
- application may not alter it. */
- const char *name;
-
- /* The value of the symbol. This really should be a union of a
- numeric value with a pointer, since some flags indicate that
- a pointer to another symbol is stored here. */
- symvalue value;
-
- /* Attributes of a symbol. */
- #define BSF_NO_FLAGS 0x00
-
- /* The symbol has local scope; `static' in `C'. The value
- is the offset into the section of the data. */
- #define BSF_LOCAL (1 << 0)
-
- /* The symbol has global scope; initialized data in `C'. The
- value is the offset into the section of the data. */
- #define BSF_GLOBAL (1 << 1)
-
- /* The symbol has global scope and is exported. The value is
- the offset into the section of the data. */
- #define BSF_EXPORT BSF_GLOBAL /* No real difference. */
-
- /* A normal C symbol would be one of:
- `BSF_LOCAL', `BSF_COMMON', `BSF_UNDEFINED' or
- `BSF_GLOBAL'. */
-
- /* The symbol is a debugging record. The value has an arbitrary
- meaning, unless BSF_DEBUGGING_RELOC is also set. */
- #define BSF_DEBUGGING (1 << 2)
-
- /* The symbol denotes a function entry point. Used in ELF,
- perhaps others someday. */
- #define BSF_FUNCTION (1 << 3)
-
- /* Used by the linker. */
- #define BSF_KEEP (1 << 5)
- #define BSF_KEEP_G (1 << 6)
-
- /* A weak global symbol, overridable without warnings by
- a regular global symbol of the same name. */
- #define BSF_WEAK (1 << 7)
-
- /* This symbol was created to point to a section, e.g. ELF's
- STT_SECTION symbols. */
- #define BSF_SECTION_SYM (1 << 8)
-
- /* The symbol used to be a common symbol, but now it is
- allocated. */
- #define BSF_OLD_COMMON (1 << 9)
-
- /* In some files the type of a symbol sometimes alters its
- location in an output file - ie in coff a `ISFCN' symbol
- which is also `C_EXT' symbol appears where it was
- declared and not at the end of a section. This bit is set
- by the target BFD part to convey this information. */
- #define BSF_NOT_AT_END (1 << 10)
-
- /* Signal that the symbol is the label of constructor section. */
- #define BSF_CONSTRUCTOR (1 << 11)
-
- /* Signal that the symbol is a warning symbol. The name is a
- warning. The name of the next symbol is the one to warn about;
- if a reference is made to a symbol with the same name as the next
- symbol, a warning is issued by the linker. */
- #define BSF_WARNING (1 << 12)
-
- /* Signal that the symbol is indirect. This symbol is an indirect
- pointer to the symbol with the same name as the next symbol. */
- #define BSF_INDIRECT (1 << 13)
-
- /* BSF_FILE marks symbols that contain a file name. This is used
- for ELF STT_FILE symbols. */
- #define BSF_FILE (1 << 14)
-
- /* Symbol is from dynamic linking information. */
- #define BSF_DYNAMIC (1 << 15)
-
- /* The symbol denotes a data object. Used in ELF, and perhaps
- others someday. */
- #define BSF_OBJECT (1 << 16)
-
- /* This symbol is a debugging symbol. The value is the offset
- into the section of the data. BSF_DEBUGGING should be set
- as well. */
- #define BSF_DEBUGGING_RELOC (1 << 17)
-
- /* This symbol is thread local. Used in ELF. */
- #define BSF_THREAD_LOCAL (1 << 18)
-
- /* This symbol represents a complex relocation expression,
- with the expression tree serialized in the symbol name. */
- #define BSF_RELC (1 << 19)
-
- /* This symbol represents a signed complex relocation expression,
- with the expression tree serialized in the symbol name. */
- #define BSF_SRELC (1 << 20)
-
- /* This symbol was created by bfd_get_synthetic_symtab. */
- #define BSF_SYNTHETIC (1 << 21)
-
- /* This symbol is an indirect code object. Unrelated to BSF_INDIRECT.
- The dynamic linker will compute the value of this symbol by
- calling the function that it points to. BSF_FUNCTION must
- also be also set. */
- #define BSF_GNU_INDIRECT_FUNCTION (1 << 22)
- /* This symbol is a globally unique data object. The dynamic linker
- will make sure that in the entire process there is just one symbol
- with this name and type in use. BSF_OBJECT must also be set. */
- #define BSF_GNU_UNIQUE (1 << 23)
-
- flagword flags;
-
- /* A pointer to the section to which this symbol is
- relative. This will always be non NULL, there are special
- sections for undefined and absolute symbols. */
- struct bfd_section *section;
-
- /* Back end special data. */
- union
- {
- void *p;
- bfd_vma i;
- }
- udata;
- }
- asymbol;
-
-
-File: bfd.info, Node: symbol handling functions, Prev: typedef asymbol, Up: Symbols
-
-2.7.5 Symbol handling functions
--------------------------------
-
-2.7.5.1 `bfd_get_symtab_upper_bound'
-....................................
-
-*Description*
-Return the number of bytes required to store a vector of pointers to
-`asymbols' for all the symbols in the BFD ABFD, including a terminal
-NULL pointer. If there are no symbols in the BFD, then return 0. If an
-error occurs, return -1.
- #define bfd_get_symtab_upper_bound(abfd) \
- BFD_SEND (abfd, _bfd_get_symtab_upper_bound, (abfd))
-
-2.7.5.2 `bfd_is_local_label'
-............................
-
-*Synopsis*
- bfd_boolean bfd_is_local_label (bfd *abfd, asymbol *sym);
- *Description*
-Return TRUE if the given symbol SYM in the BFD ABFD is a compiler
-generated local label, else return FALSE.
-
-2.7.5.3 `bfd_is_local_label_name'
-.................................
-
-*Synopsis*
- bfd_boolean bfd_is_local_label_name (bfd *abfd, const char *name);
- *Description*
-Return TRUE if a symbol with the name NAME in the BFD ABFD is a
-compiler generated local label, else return FALSE. This just checks
-whether the name has the form of a local label.
- #define bfd_is_local_label_name(abfd, name) \
- BFD_SEND (abfd, _bfd_is_local_label_name, (abfd, name))
-
-2.7.5.4 `bfd_is_target_special_symbol'
-......................................
-
-*Synopsis*
- bfd_boolean bfd_is_target_special_symbol (bfd *abfd, asymbol *sym);
- *Description*
-Return TRUE iff a symbol SYM in the BFD ABFD is something special to
-the particular target represented by the BFD. Such symbols should
-normally not be mentioned to the user.
- #define bfd_is_target_special_symbol(abfd, sym) \
- BFD_SEND (abfd, _bfd_is_target_special_symbol, (abfd, sym))
-
-2.7.5.5 `bfd_canonicalize_symtab'
-.................................
-
-*Description*
-Read the symbols from the BFD ABFD, and fills in the vector LOCATION
-with pointers to the symbols and a trailing NULL. Return the actual
-number of symbol pointers, not including the NULL.
- #define bfd_canonicalize_symtab(abfd, location) \
- BFD_SEND (abfd, _bfd_canonicalize_symtab, (abfd, location))
-
-2.7.5.6 `bfd_set_symtab'
-........................
-
-*Synopsis*
- bfd_boolean bfd_set_symtab
- (bfd *abfd, asymbol **location, unsigned int count);
- *Description*
-Arrange that when the output BFD ABFD is closed, the table LOCATION of
-COUNT pointers to symbols will be written.
-
-2.7.5.7 `bfd_print_symbol_vandf'
-................................
-
-*Synopsis*
- void bfd_print_symbol_vandf (bfd *abfd, void *file, asymbol *symbol);
- *Description*
-Print the value and flags of the SYMBOL supplied to the stream FILE.
-
-2.7.5.8 `bfd_make_empty_symbol'
-...............................
-
-*Description*
-Create a new `asymbol' structure for the BFD ABFD and return a pointer
-to it.
-
- This routine is necessary because each back end has private
-information surrounding the `asymbol'. Building your own `asymbol' and
-pointing to it will not create the private information, and will cause
-problems later on.
- #define bfd_make_empty_symbol(abfd) \
- BFD_SEND (abfd, _bfd_make_empty_symbol, (abfd))
-
-2.7.5.9 `_bfd_generic_make_empty_symbol'
-........................................
-
-*Synopsis*
- asymbol *_bfd_generic_make_empty_symbol (bfd *);
- *Description*
-Create a new `asymbol' structure for the BFD ABFD and return a pointer
-to it. Used by core file routines, binary back-end and anywhere else
-where no private info is needed.
-
-2.7.5.10 `bfd_make_debug_symbol'
-................................
-
-*Description*
-Create a new `asymbol' structure for the BFD ABFD, to be used as a
-debugging symbol. Further details of its use have yet to be worked out.
- #define bfd_make_debug_symbol(abfd,ptr,size) \
- BFD_SEND (abfd, _bfd_make_debug_symbol, (abfd, ptr, size))
-
-2.7.5.11 `bfd_decode_symclass'
-..............................
-
-*Description*
-Return a character corresponding to the symbol class of SYMBOL, or '?'
-for an unknown class.
-
- *Synopsis*
- int bfd_decode_symclass (asymbol *symbol);
-
-2.7.5.12 `bfd_is_undefined_symclass'
-....................................
-
-*Description*
-Returns non-zero if the class symbol returned by bfd_decode_symclass
-represents an undefined symbol. Returns zero otherwise.
-
- *Synopsis*
- bfd_boolean bfd_is_undefined_symclass (int symclass);
-
-2.7.5.13 `bfd_symbol_info'
-..........................
-
-*Description*
-Fill in the basic info about symbol that nm needs. Additional info may
-be added by the back-ends after calling this function.
-
- *Synopsis*
- void bfd_symbol_info (asymbol *symbol, symbol_info *ret);
-
-2.7.5.14 `bfd_copy_private_symbol_data'
-.......................................
-
-*Synopsis*
- bfd_boolean bfd_copy_private_symbol_data
- (bfd *ibfd, asymbol *isym, bfd *obfd, asymbol *osym);
- *Description*
-Copy private symbol information from ISYM in the BFD IBFD to the symbol
-OSYM in the BFD OBFD. Return `TRUE' on success, `FALSE' on error.
-Possible error returns are:
-
- * `bfd_error_no_memory' - Not enough memory exists to create private
- data for OSEC.
-
- #define bfd_copy_private_symbol_data(ibfd, isymbol, obfd, osymbol) \
- BFD_SEND (obfd, _bfd_copy_private_symbol_data, \
- (ibfd, isymbol, obfd, osymbol))
-
-
-File: bfd.info, Node: Archives, Next: Formats, Prev: Symbols, Up: BFD front end
-
-2.8 Archives
-============
-
-*Description*
-An archive (or library) is just another BFD. It has a symbol table,
-although there's not much a user program will do with it.
-
- The big difference between an archive BFD and an ordinary BFD is
-that the archive doesn't have sections. Instead it has a chain of BFDs
-that are considered its contents. These BFDs can be manipulated like
-any other. The BFDs contained in an archive opened for reading will
-all be opened for reading. You may put either input or output BFDs
-into an archive opened for output; they will be handled correctly when
-the archive is closed.
-
- Use `bfd_openr_next_archived_file' to step through the contents of
-an archive opened for input. You don't have to read the entire archive
-if you don't want to! Read it until you find what you want.
-
- Archive contents of output BFDs are chained through the `next'
-pointer in a BFD. The first one is findable through the `archive_head'
-slot of the archive. Set it with `bfd_set_archive_head' (q.v.). A
-given BFD may be in only one open output archive at a time.
-
- As expected, the BFD archive code is more general than the archive
-code of any given environment. BFD archives may contain files of
-different formats (e.g., a.out and coff) and even different
-architectures. You may even place archives recursively into archives!
-
- This can cause unexpected confusion, since some archive formats are
-more expressive than others. For instance, Intel COFF archives can
-preserve long filenames; SunOS a.out archives cannot. If you move a
-file from the first to the second format and back again, the filename
-may be truncated. Likewise, different a.out environments have different
-conventions as to how they truncate filenames, whether they preserve
-directory names in filenames, etc. When interoperating with native
-tools, be sure your files are homogeneous.
-
- Beware: most of these formats do not react well to the presence of
-spaces in filenames. We do the best we can, but can't always handle
-this case due to restrictions in the format of archives. Many Unix
-utilities are braindead in regards to spaces and such in filenames
-anyway, so this shouldn't be much of a restriction.
-
- Archives are supported in BFD in `archive.c'.
-
-2.8.1 Archive functions
------------------------
-
-2.8.1.1 `bfd_get_next_mapent'
-.............................
-
-*Synopsis*
- symindex bfd_get_next_mapent
- (bfd *abfd, symindex previous, carsym **sym);
- *Description*
-Step through archive ABFD's symbol table (if it has one). Successively
-update SYM with the next symbol's information, returning that symbol's
-(internal) index into the symbol table.
-
- Supply `BFD_NO_MORE_SYMBOLS' as the PREVIOUS entry to get the first
-one; returns `BFD_NO_MORE_SYMBOLS' when you've already got the last one.
-
- A `carsym' is a canonical archive symbol. The only user-visible
-element is its name, a null-terminated string.
-
-2.8.1.2 `bfd_set_archive_head'
-..............................
-
-*Synopsis*
- bfd_boolean bfd_set_archive_head (bfd *output, bfd *new_head);
- *Description*
-Set the head of the chain of BFDs contained in the archive OUTPUT to
-NEW_HEAD.
-
-2.8.1.3 `bfd_openr_next_archived_file'
-......................................
-
-*Synopsis*
- bfd *bfd_openr_next_archived_file (bfd *archive, bfd *previous);
- *Description*
-Provided a BFD, ARCHIVE, containing an archive and NULL, open an input
-BFD on the first contained element and returns that. Subsequent calls
-should pass the archive and the previous return value to return a
-created BFD to the next contained element. NULL is returned when there
-are no more.
-
-
-File: bfd.info, Node: Formats, Next: Relocations, Prev: Archives, Up: BFD front end
-
-2.9 File formats
-================
-
-A format is a BFD concept of high level file contents type. The formats
-supported by BFD are:
-
- * `bfd_object'
- The BFD may contain data, symbols, relocations and debug info.
-
- * `bfd_archive'
- The BFD contains other BFDs and an optional index.
-
- * `bfd_core'
- The BFD contains the result of an executable core dump.
-
-2.9.1 File format functions
----------------------------
-
-2.9.1.1 `bfd_check_format'
-..........................
-
-*Synopsis*
- bfd_boolean bfd_check_format (bfd *abfd, bfd_format format);
- *Description*
-Verify if the file attached to the BFD ABFD is compatible with the
-format FORMAT (i.e., one of `bfd_object', `bfd_archive' or `bfd_core').
-
- If the BFD has been set to a specific target before the call, only
-the named target and format combination is checked. If the target has
-not been set, or has been set to `default', then all the known target
-backends is interrogated to determine a match. If the default target
-matches, it is used. If not, exactly one target must recognize the
-file, or an error results.
-
- The function returns `TRUE' on success, otherwise `FALSE' with one
-of the following error codes:
-
- * `bfd_error_invalid_operation' - if `format' is not one of
- `bfd_object', `bfd_archive' or `bfd_core'.
-
- * `bfd_error_system_call' - if an error occured during a read - even
- some file mismatches can cause bfd_error_system_calls.
-
- * `file_not_recognised' - none of the backends recognised the file
- format.
-
- * `bfd_error_file_ambiguously_recognized' - more than one backend
- recognised the file format.
-
-2.9.1.2 `bfd_check_format_matches'
-..................................
-
-*Synopsis*
- bfd_boolean bfd_check_format_matches
- (bfd *abfd, bfd_format format, char ***matching);
- *Description*
-Like `bfd_check_format', except when it returns FALSE with `bfd_errno'
-set to `bfd_error_file_ambiguously_recognized'. In that case, if
-MATCHING is not NULL, it will be filled in with a NULL-terminated list
-of the names of the formats that matched, allocated with `malloc'.
-Then the user may choose a format and try again.
-
- When done with the list that MATCHING points to, the caller should
-free it.
-
-2.9.1.3 `bfd_set_format'
-........................
-
-*Synopsis*
- bfd_boolean bfd_set_format (bfd *abfd, bfd_format format);
- *Description*
-This function sets the file format of the BFD ABFD to the format
-FORMAT. If the target set in the BFD does not support the format
-requested, the format is invalid, or the BFD is not open for writing,
-then an error occurs.
-
-2.9.1.4 `bfd_format_string'
-...........................
-
-*Synopsis*
- const char *bfd_format_string (bfd_format format);
- *Description*
-Return a pointer to a const string `invalid', `object', `archive',
-`core', or `unknown', depending upon the value of FORMAT.
-
-
-File: bfd.info, Node: Relocations, Next: Core Files, Prev: Formats, Up: BFD front end
-
-2.10 Relocations
-================
-
-BFD maintains relocations in much the same way it maintains symbols:
-they are left alone until required, then read in en-masse and
-translated into an internal form. A common routine
-`bfd_perform_relocation' acts upon the canonical form to do the fixup.
-
- Relocations are maintained on a per section basis, while symbols are
-maintained on a per BFD basis.
-
- All that a back end has to do to fit the BFD interface is to create
-a `struct reloc_cache_entry' for each relocation in a particular
-section, and fill in the right bits of the structures.
-
-* Menu:
-
-* typedef arelent::
-* howto manager::
-
-
-File: bfd.info, Node: typedef arelent, Next: howto manager, Prev: Relocations, Up: Relocations
-
-2.10.1 typedef arelent
-----------------------
-
-This is the structure of a relocation entry:
-
-
- typedef enum bfd_reloc_status
- {
- /* No errors detected. */
- bfd_reloc_ok,
-
- /* The relocation was performed, but there was an overflow. */
- bfd_reloc_overflow,
-
- /* The address to relocate was not within the section supplied. */
- bfd_reloc_outofrange,
-
- /* Used by special functions. */
- bfd_reloc_continue,
-
- /* Unsupported relocation size requested. */
- bfd_reloc_notsupported,
-
- /* Unused. */
- bfd_reloc_other,
-
- /* The symbol to relocate against was undefined. */
- bfd_reloc_undefined,
-
- /* The relocation was performed, but may not be ok - presently
- generated only when linking i960 coff files with i960 b.out
- symbols. If this type is returned, the error_message argument
- to bfd_perform_relocation will be set. */
- bfd_reloc_dangerous
- }
- bfd_reloc_status_type;
-
-
- typedef struct reloc_cache_entry
- {
- /* A pointer into the canonical table of pointers. */
- struct bfd_symbol **sym_ptr_ptr;
-
- /* offset in section. */
- bfd_size_type address;
-
- /* addend for relocation value. */
- bfd_vma addend;
-
- /* Pointer to how to perform the required relocation. */
- reloc_howto_type *howto;
-
- }
- arelent;
- *Description*
-Here is a description of each of the fields within an `arelent':
-
- * `sym_ptr_ptr'
- The symbol table pointer points to a pointer to the symbol
-associated with the relocation request. It is the pointer into the
-table returned by the back end's `canonicalize_symtab' action. *Note
-Symbols::. The symbol is referenced through a pointer to a pointer so
-that tools like the linker can fix up all the symbols of the same name
-by modifying only one pointer. The relocation routine looks in the
-symbol and uses the base of the section the symbol is attached to and
-the value of the symbol as the initial relocation offset. If the symbol
-pointer is zero, then the section provided is looked up.
-
- * `address'
- The `address' field gives the offset in bytes from the base of the
-section data which owns the relocation record to the first byte of
-relocatable information. The actual data relocated will be relative to
-this point; for example, a relocation type which modifies the bottom
-two bytes of a four byte word would not touch the first byte pointed to
-in a big endian world.
-
- * `addend'
- The `addend' is a value provided by the back end to be added (!) to
-the relocation offset. Its interpretation is dependent upon the howto.
-For example, on the 68k the code:
-
- char foo[];
- main()
- {
- return foo[0x12345678];
- }
-
- Could be compiled into:
-
- linkw fp,#-4
- moveb @#12345678,d0
- extbl d0
- unlk fp
- rts
-
- This could create a reloc pointing to `foo', but leave the offset in
-the data, something like:
-
- RELOCATION RECORDS FOR [.text]:
- offset type value
- 00000006 32 _foo
-
- 00000000 4e56 fffc ; linkw fp,#-4
- 00000004 1039 1234 5678 ; moveb @#12345678,d0
- 0000000a 49c0 ; extbl d0
- 0000000c 4e5e ; unlk fp
- 0000000e 4e75 ; rts
-
- Using coff and an 88k, some instructions don't have enough space in
-them to represent the full address range, and pointers have to be
-loaded in two parts. So you'd get something like:
-
- or.u r13,r0,hi16(_foo+0x12345678)
- ld.b r2,r13,lo16(_foo+0x12345678)
- jmp r1
-
- This should create two relocs, both pointing to `_foo', and with
-0x12340000 in their addend field. The data would consist of:
-
- RELOCATION RECORDS FOR [.text]:
- offset type value
- 00000002 HVRT16 _foo+0x12340000
- 00000006 LVRT16 _foo+0x12340000
-
- 00000000 5da05678 ; or.u r13,r0,0x5678
- 00000004 1c4d5678 ; ld.b r2,r13,0x5678
- 00000008 f400c001 ; jmp r1
-
- The relocation routine digs out the value from the data, adds it to
-the addend to get the original offset, and then adds the value of
-`_foo'. Note that all 32 bits have to be kept around somewhere, to cope
-with carry from bit 15 to bit 16.
-
- One further example is the sparc and the a.out format. The sparc has
-a similar problem to the 88k, in that some instructions don't have room
-for an entire offset, but on the sparc the parts are created in odd
-sized lumps. The designers of the a.out format chose to not use the
-data within the section for storing part of the offset; all the offset
-is kept within the reloc. Anything in the data should be ignored.
-
- save %sp,-112,%sp
- sethi %hi(_foo+0x12345678),%g2
- ldsb [%g2+%lo(_foo+0x12345678)],%i0
- ret
- restore
-
- Both relocs contain a pointer to `foo', and the offsets contain junk.
-
- RELOCATION RECORDS FOR [.text]:
- offset type value
- 00000004 HI22 _foo+0x12345678
- 00000008 LO10 _foo+0x12345678
-
- 00000000 9de3bf90 ; save %sp,-112,%sp
- 00000004 05000000 ; sethi %hi(_foo+0),%g2
- 00000008 f048a000 ; ldsb [%g2+%lo(_foo+0)],%i0
- 0000000c 81c7e008 ; ret
- 00000010 81e80000 ; restore
-
- * `howto'
- The `howto' field can be imagined as a relocation instruction. It is
-a pointer to a structure which contains information on what to do with
-all of the other information in the reloc record and data section. A
-back end would normally have a relocation instruction set and turn
-relocations into pointers to the correct structure on input - but it
-would be possible to create each howto field on demand.
-
-2.10.1.1 `enum complain_overflow'
-.................................
-
-Indicates what sort of overflow checking should be done when performing
-a relocation.
-
-
- enum complain_overflow
- {
- /* Do not complain on overflow. */
- complain_overflow_dont,
-
- /* Complain if the value overflows when considered as a signed
- number one bit larger than the field. ie. A bitfield of N bits
- is allowed to represent -2**n to 2**n-1. */
- complain_overflow_bitfield,
-
- /* Complain if the value overflows when considered as a signed
- number. */
- complain_overflow_signed,
-
- /* Complain if the value overflows when considered as an
- unsigned number. */
- complain_overflow_unsigned
- };
-
-2.10.1.2 `reloc_howto_type'
-...........................
-
-The `reloc_howto_type' is a structure which contains all the
-information that libbfd needs to know to tie up a back end's data.
-
- struct bfd_symbol; /* Forward declaration. */
-
- struct reloc_howto_struct
- {
- /* The type field has mainly a documentary use - the back end can
- do what it wants with it, though normally the back end's
- external idea of what a reloc number is stored
- in this field. For example, a PC relative word relocation
- in a coff environment has the type 023 - because that's
- what the outside world calls a R_PCRWORD reloc. */
- unsigned int type;
-
- /* The value the final relocation is shifted right by. This drops
- unwanted data from the relocation. */
- unsigned int rightshift;
-
- /* The size of the item to be relocated. This is *not* a
- power-of-two measure. To get the number of bytes operated
- on by a type of relocation, use bfd_get_reloc_size. */
- int size;
-
- /* The number of bits in the item to be relocated. This is used
- when doing overflow checking. */
- unsigned int bitsize;
-
- /* The relocation is relative to the field being relocated. */
- bfd_boolean pc_relative;
-
- /* The bit position of the reloc value in the destination.
- The relocated value is left shifted by this amount. */
- unsigned int bitpos;
-
- /* What type of overflow error should be checked for when
- relocating. */
- enum complain_overflow complain_on_overflow;
-
- /* If this field is non null, then the supplied function is
- called rather than the normal function. This allows really
- strange relocation methods to be accommodated (e.g., i960 callj
- instructions). */
- bfd_reloc_status_type (*special_function)
- (bfd *, arelent *, struct bfd_symbol *, void *, asection *,
- bfd *, char **);
-
- /* The textual name of the relocation type. */
- char *name;
-
- /* Some formats record a relocation addend in the section contents
- rather than with the relocation. For ELF formats this is the
- distinction between USE_REL and USE_RELA (though the code checks
- for USE_REL == 1/0). The value of this field is TRUE if the
- addend is recorded with the section contents; when performing a
- partial link (ld -r) the section contents (the data) will be
- modified. The value of this field is FALSE if addends are
- recorded with the relocation (in arelent.addend); when performing
- a partial link the relocation will be modified.
- All relocations for all ELF USE_RELA targets should set this field
- to FALSE (values of TRUE should be looked on with suspicion).
- However, the converse is not true: not all relocations of all ELF
- USE_REL targets set this field to TRUE. Why this is so is peculiar
- to each particular target. For relocs that aren't used in partial
- links (e.g. GOT stuff) it doesn't matter what this is set to. */
- bfd_boolean partial_inplace;
-
- /* src_mask selects the part of the instruction (or data) to be used
- in the relocation sum. If the target relocations don't have an
- addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
- dst_mask to extract the addend from the section contents. If
- relocations do have an addend in the reloc, eg. ELF USE_RELA, this
- field should be zero. Non-zero values for ELF USE_RELA targets are
- bogus as in those cases the value in the dst_mask part of the
- section contents should be treated as garbage. */
- bfd_vma src_mask;
-
- /* dst_mask selects which parts of the instruction (or data) are
- replaced with a relocated value. */
- bfd_vma dst_mask;
-
- /* When some formats create PC relative instructions, they leave
- the value of the pc of the place being relocated in the offset
- slot of the instruction, so that a PC relative relocation can
- be made just by adding in an ordinary offset (e.g., sun3 a.out).
- Some formats leave the displacement part of an instruction
- empty (e.g., m88k bcs); this flag signals the fact. */
- bfd_boolean pcrel_offset;
- };
-
-2.10.1.3 `The HOWTO Macro'
-..........................
-
-*Description*
-The HOWTO define is horrible and will go away.
- #define HOWTO(C, R, S, B, P, BI, O, SF, NAME, INPLACE, MASKSRC, MASKDST, PC) \
- { (unsigned) C, R, S, B, P, BI, O, SF, NAME, INPLACE, MASKSRC, MASKDST, PC }
-
- *Description*
-And will be replaced with the totally magic way. But for the moment, we
-are compatible, so do it this way.
- #define NEWHOWTO(FUNCTION, NAME, SIZE, REL, IN) \
- HOWTO (0, 0, SIZE, 0, REL, 0, complain_overflow_dont, FUNCTION, \
- NAME, FALSE, 0, 0, IN)
-
- *Description*
-This is used to fill in an empty howto entry in an array.
- #define EMPTY_HOWTO(C) \
- HOWTO ((C), 0, 0, 0, FALSE, 0, complain_overflow_dont, NULL, \
- NULL, FALSE, 0, 0, FALSE)
-
- *Description*
-Helper routine to turn a symbol into a relocation value.
- #define HOWTO_PREPARE(relocation, symbol) \
- { \
- if (symbol != NULL) \
- { \
- if (bfd_is_com_section (symbol->section)) \
- { \
- relocation = 0; \
- } \
- else \
- { \
- relocation = symbol->value; \
- } \
- } \
- }
-
-2.10.1.4 `bfd_get_reloc_size'
-.............................
-
-*Synopsis*
- unsigned int bfd_get_reloc_size (reloc_howto_type *);
- *Description*
-For a reloc_howto_type that operates on a fixed number of bytes, this
-returns the number of bytes operated on.
-
-2.10.1.5 `arelent_chain'
-........................
-
-*Description*
-How relocs are tied together in an `asection':
- typedef struct relent_chain
- {
- arelent relent;
- struct relent_chain *next;
- }
- arelent_chain;
-
-2.10.1.6 `bfd_check_overflow'
-.............................
-
-*Synopsis*
- bfd_reloc_status_type bfd_check_overflow
- (enum complain_overflow how,
- unsigned int bitsize,
- unsigned int rightshift,
- unsigned int addrsize,
- bfd_vma relocation);
- *Description*
-Perform overflow checking on RELOCATION which has BITSIZE significant
-bits and will be shifted right by RIGHTSHIFT bits, on a machine with
-addresses containing ADDRSIZE significant bits. The result is either of
-`bfd_reloc_ok' or `bfd_reloc_overflow'.
-
-2.10.1.7 `bfd_perform_relocation'
-.................................
-
-*Synopsis*
- bfd_reloc_status_type bfd_perform_relocation
- (bfd *abfd,
- arelent *reloc_entry,
- void *data,
- asection *input_section,
- bfd *output_bfd,
- char **error_message);
- *Description*
-If OUTPUT_BFD is supplied to this function, the generated image will be
-relocatable; the relocations are copied to the output file after they
-have been changed to reflect the new state of the world. There are two
-ways of reflecting the results of partial linkage in an output file: by
-modifying the output data in place, and by modifying the relocation
-record. Some native formats (e.g., basic a.out and basic coff) have no
-way of specifying an addend in the relocation type, so the addend has
-to go in the output data. This is no big deal since in these formats
-the output data slot will always be big enough for the addend. Complex
-reloc types with addends were invented to solve just this problem. The
-ERROR_MESSAGE argument is set to an error message if this return
-`bfd_reloc_dangerous'.
-
-2.10.1.8 `bfd_install_relocation'
-.................................
-
-*Synopsis*
- bfd_reloc_status_type bfd_install_relocation
- (bfd *abfd,
- arelent *reloc_entry,
- void *data, bfd_vma data_start,
- asection *input_section,
- char **error_message);
- *Description*
-This looks remarkably like `bfd_perform_relocation', except it does not
-expect that the section contents have been filled in. I.e., it's
-suitable for use when creating, rather than applying a relocation.
-
- For now, this function should be considered reserved for the
-assembler.
-
-
-File: bfd.info, Node: howto manager, Prev: typedef arelent, Up: Relocations
-
-2.10.2 The howto manager
-------------------------
-
-When an application wants to create a relocation, but doesn't know what
-the target machine might call it, it can find out by using this bit of
-code.
-
-2.10.2.1 `bfd_reloc_code_type'
-..............................
-
-*Description*
-The insides of a reloc code. The idea is that, eventually, there will
-be one enumerator for every type of relocation we ever do. Pass one of
-these values to `bfd_reloc_type_lookup', and it'll return a howto
-pointer.
-
- This does mean that the application must determine the correct
-enumerator value; you can't get a howto pointer from a random set of
-attributes.
-
- Here are the possible values for `enum bfd_reloc_code_real':
-
- -- : BFD_RELOC_64
- -- : BFD_RELOC_32
- -- : BFD_RELOC_26
- -- : BFD_RELOC_24
- -- : BFD_RELOC_16
- -- : BFD_RELOC_14
- -- : BFD_RELOC_8
- Basic absolute relocations of N bits.
-
- -- : BFD_RELOC_64_PCREL
- -- : BFD_RELOC_32_PCREL
- -- : BFD_RELOC_24_PCREL
- -- : BFD_RELOC_16_PCREL
- -- : BFD_RELOC_12_PCREL
- -- : BFD_RELOC_8_PCREL
- PC-relative relocations. Sometimes these are relative to the
- address of the relocation itself; sometimes they are relative to
- the start of the section containing the relocation. It depends on
- the specific target.
-
- The 24-bit relocation is used in some Intel 960 configurations.
-
- -- : BFD_RELOC_32_SECREL
- Section relative relocations. Some targets need this for DWARF2.
-
- -- : BFD_RELOC_32_GOT_PCREL
- -- : BFD_RELOC_16_GOT_PCREL
- -- : BFD_RELOC_8_GOT_PCREL
- -- : BFD_RELOC_32_GOTOFF
- -- : BFD_RELOC_16_GOTOFF
- -- : BFD_RELOC_LO16_GOTOFF
- -- : BFD_RELOC_HI16_GOTOFF
- -- : BFD_RELOC_HI16_S_GOTOFF
- -- : BFD_RELOC_8_GOTOFF
- -- : BFD_RELOC_64_PLT_PCREL
- -- : BFD_RELOC_32_PLT_PCREL
- -- : BFD_RELOC_24_PLT_PCREL
- -- : BFD_RELOC_16_PLT_PCREL
- -- : BFD_RELOC_8_PLT_PCREL
- -- : BFD_RELOC_64_PLTOFF
- -- : BFD_RELOC_32_PLTOFF
- -- : BFD_RELOC_16_PLTOFF
- -- : BFD_RELOC_LO16_PLTOFF
- -- : BFD_RELOC_HI16_PLTOFF
- -- : BFD_RELOC_HI16_S_PLTOFF
- -- : BFD_RELOC_8_PLTOFF
- For ELF.
-
- -- : BFD_RELOC_68K_GLOB_DAT
- -- : BFD_RELOC_68K_JMP_SLOT
- -- : BFD_RELOC_68K_RELATIVE
- -- : BFD_RELOC_68K_TLS_GD32
- -- : BFD_RELOC_68K_TLS_GD16
- -- : BFD_RELOC_68K_TLS_GD8
- -- : BFD_RELOC_68K_TLS_LDM32
- -- : BFD_RELOC_68K_TLS_LDM16
- -- : BFD_RELOC_68K_TLS_LDM8
- -- : BFD_RELOC_68K_TLS_LDO32
- -- : BFD_RELOC_68K_TLS_LDO16
- -- : BFD_RELOC_68K_TLS_LDO8
- -- : BFD_RELOC_68K_TLS_IE32
- -- : BFD_RELOC_68K_TLS_IE16
- -- : BFD_RELOC_68K_TLS_IE8
- -- : BFD_RELOC_68K_TLS_LE32
- -- : BFD_RELOC_68K_TLS_LE16
- -- : BFD_RELOC_68K_TLS_LE8
- Relocations used by 68K ELF.
-
- -- : BFD_RELOC_32_BASEREL
- -- : BFD_RELOC_16_BASEREL
- -- : BFD_RELOC_LO16_BASEREL
- -- : BFD_RELOC_HI16_BASEREL
- -- : BFD_RELOC_HI16_S_BASEREL
- -- : BFD_RELOC_8_BASEREL
- -- : BFD_RELOC_RVA
- Linkage-table relative.
-
- -- : BFD_RELOC_8_FFnn
- Absolute 8-bit relocation, but used to form an address like 0xFFnn.
-
- -- : BFD_RELOC_32_PCREL_S2
- -- : BFD_RELOC_16_PCREL_S2
- -- : BFD_RELOC_23_PCREL_S2
- These PC-relative relocations are stored as word displacements -
- i.e., byte displacements shifted right two bits. The 30-bit word
- displacement (<<32_PCREL_S2>> - 32 bits, shifted 2) is used on the
- SPARC. (SPARC tools generally refer to this as <<WDISP30>>.) The
- signed 16-bit displacement is used on the MIPS, and the 23-bit
- displacement is used on the Alpha.
-
- -- : BFD_RELOC_HI22
- -- : BFD_RELOC_LO10
- High 22 bits and low 10 bits of 32-bit value, placed into lower
- bits of the target word. These are used on the SPARC.
-
- -- : BFD_RELOC_GPREL16
- -- : BFD_RELOC_GPREL32
- For systems that allocate a Global Pointer register, these are
- displacements off that register. These relocation types are
- handled specially, because the value the register will have is
- decided relatively late.
-
- -- : BFD_RELOC_I960_CALLJ
- Reloc types used for i960/b.out.
-
- -- : BFD_RELOC_NONE
- -- : BFD_RELOC_SPARC_WDISP22
- -- : BFD_RELOC_SPARC22
- -- : BFD_RELOC_SPARC13
- -- : BFD_RELOC_SPARC_GOT10
- -- : BFD_RELOC_SPARC_GOT13
- -- : BFD_RELOC_SPARC_GOT22
- -- : BFD_RELOC_SPARC_PC10
- -- : BFD_RELOC_SPARC_PC22
- -- : BFD_RELOC_SPARC_WPLT30
- -- : BFD_RELOC_SPARC_COPY
- -- : BFD_RELOC_SPARC_GLOB_DAT
- -- : BFD_RELOC_SPARC_JMP_SLOT
- -- : BFD_RELOC_SPARC_RELATIVE
- -- : BFD_RELOC_SPARC_UA16
- -- : BFD_RELOC_SPARC_UA32
- -- : BFD_RELOC_SPARC_UA64
- -- : BFD_RELOC_SPARC_GOTDATA_HIX22
- -- : BFD_RELOC_SPARC_GOTDATA_LOX10
- -- : BFD_RELOC_SPARC_GOTDATA_OP_HIX22
- -- : BFD_RELOC_SPARC_GOTDATA_OP_LOX10
- -- : BFD_RELOC_SPARC_GOTDATA_OP
- -- : BFD_RELOC_SPARC_JMP_IREL
- -- : BFD_RELOC_SPARC_IRELATIVE
- SPARC ELF relocations. There is probably some overlap with other
- relocation types already defined.
-
- -- : BFD_RELOC_SPARC_BASE13
- -- : BFD_RELOC_SPARC_BASE22
- I think these are specific to SPARC a.out (e.g., Sun 4).
-
- -- : BFD_RELOC_SPARC_64
- -- : BFD_RELOC_SPARC_10
- -- : BFD_RELOC_SPARC_11
- -- : BFD_RELOC_SPARC_OLO10
- -- : BFD_RELOC_SPARC_HH22
- -- : BFD_RELOC_SPARC_HM10
- -- : BFD_RELOC_SPARC_LM22
- -- : BFD_RELOC_SPARC_PC_HH22
- -- : BFD_RELOC_SPARC_PC_HM10
- -- : BFD_RELOC_SPARC_PC_LM22
- -- : BFD_RELOC_SPARC_WDISP16
- -- : BFD_RELOC_SPARC_WDISP19
- -- : BFD_RELOC_SPARC_7
- -- : BFD_RELOC_SPARC_6
- -- : BFD_RELOC_SPARC_5
- -- : BFD_RELOC_SPARC_DISP64
- -- : BFD_RELOC_SPARC_PLT32
- -- : BFD_RELOC_SPARC_PLT64
- -- : BFD_RELOC_SPARC_HIX22
- -- : BFD_RELOC_SPARC_LOX10
- -- : BFD_RELOC_SPARC_H44
- -- : BFD_RELOC_SPARC_M44
- -- : BFD_RELOC_SPARC_L44
- -- : BFD_RELOC_SPARC_REGISTER
- SPARC64 relocations
-
- -- : BFD_RELOC_SPARC_REV32
- SPARC little endian relocation
-
- -- : BFD_RELOC_SPARC_TLS_GD_HI22
- -- : BFD_RELOC_SPARC_TLS_GD_LO10
- -- : BFD_RELOC_SPARC_TLS_GD_ADD
- -- : BFD_RELOC_SPARC_TLS_GD_CALL
- -- : BFD_RELOC_SPARC_TLS_LDM_HI22
- -- : BFD_RELOC_SPARC_TLS_LDM_LO10
- -- : BFD_RELOC_SPARC_TLS_LDM_ADD
- -- : BFD_RELOC_SPARC_TLS_LDM_CALL
- -- : BFD_RELOC_SPARC_TLS_LDO_HIX22
- -- : BFD_RELOC_SPARC_TLS_LDO_LOX10
- -- : BFD_RELOC_SPARC_TLS_LDO_ADD
- -- : BFD_RELOC_SPARC_TLS_IE_HI22
- -- : BFD_RELOC_SPARC_TLS_IE_LO10
- -- : BFD_RELOC_SPARC_TLS_IE_LD
- -- : BFD_RELOC_SPARC_TLS_IE_LDX
- -- : BFD_RELOC_SPARC_TLS_IE_ADD
- -- : BFD_RELOC_SPARC_TLS_LE_HIX22
- -- : BFD_RELOC_SPARC_TLS_LE_LOX10
- -- : BFD_RELOC_SPARC_TLS_DTPMOD32
- -- : BFD_RELOC_SPARC_TLS_DTPMOD64
- -- : BFD_RELOC_SPARC_TLS_DTPOFF32
- -- : BFD_RELOC_SPARC_TLS_DTPOFF64
- -- : BFD_RELOC_SPARC_TLS_TPOFF32
- -- : BFD_RELOC_SPARC_TLS_TPOFF64
- SPARC TLS relocations
-
- -- : BFD_RELOC_SPU_IMM7
- -- : BFD_RELOC_SPU_IMM8
- -- : BFD_RELOC_SPU_IMM10
- -- : BFD_RELOC_SPU_IMM10W
- -- : BFD_RELOC_SPU_IMM16
- -- : BFD_RELOC_SPU_IMM16W
- -- : BFD_RELOC_SPU_IMM18
- -- : BFD_RELOC_SPU_PCREL9a
- -- : BFD_RELOC_SPU_PCREL9b
- -- : BFD_RELOC_SPU_PCREL16
- -- : BFD_RELOC_SPU_LO16
- -- : BFD_RELOC_SPU_HI16
- -- : BFD_RELOC_SPU_PPU32
- -- : BFD_RELOC_SPU_PPU64
- -- : BFD_RELOC_SPU_ADD_PIC
- SPU Relocations.
-
- -- : BFD_RELOC_ALPHA_GPDISP_HI16
- Alpha ECOFF and ELF relocations. Some of these treat the symbol or
- "addend" in some special way. For GPDISP_HI16 ("gpdisp")
- relocations, the symbol is ignored when writing; when reading, it
- will be the absolute section symbol. The addend is the
- displacement in bytes of the "lda" instruction from the "ldah"
- instruction (which is at the address of this reloc).
-
- -- : BFD_RELOC_ALPHA_GPDISP_LO16
- For GPDISP_LO16 ("ignore") relocations, the symbol is handled as
- with GPDISP_HI16 relocs. The addend is ignored when writing the
- relocations out, and is filled in with the file's GP value on
- reading, for convenience.
-
- -- : BFD_RELOC_ALPHA_GPDISP
- The ELF GPDISP relocation is exactly the same as the GPDISP_HI16
- relocation except that there is no accompanying GPDISP_LO16
- relocation.
-
- -- : BFD_RELOC_ALPHA_LITERAL
- -- : BFD_RELOC_ALPHA_ELF_LITERAL
- -- : BFD_RELOC_ALPHA_LITUSE
- The Alpha LITERAL/LITUSE relocs are produced by a symbol reference;
- the assembler turns it into a LDQ instruction to load the address
- of the symbol, and then fills in a register in the real
- instruction.
-
- The LITERAL reloc, at the LDQ instruction, refers to the .lita
- section symbol. The addend is ignored when writing, but is filled
- in with the file's GP value on reading, for convenience, as with
- the GPDISP_LO16 reloc.
-
- The ELF_LITERAL reloc is somewhere between 16_GOTOFF and
- GPDISP_LO16. It should refer to the symbol to be referenced, as
- with 16_GOTOFF, but it generates output not based on the position
- within the .got section, but relative to the GP value chosen for
- the file during the final link stage.
-
- The LITUSE reloc, on the instruction using the loaded address,
- gives information to the linker that it might be able to use to
- optimize away some literal section references. The symbol is
- ignored (read as the absolute section symbol), and the "addend"
- indicates the type of instruction using the register: 1 - "memory"
- fmt insn 2 - byte-manipulation (byte offset reg) 3 - jsr (target
- of branch)
-
- -- : BFD_RELOC_ALPHA_HINT
- The HINT relocation indicates a value that should be filled into
- the "hint" field of a jmp/jsr/ret instruction, for possible branch-
- prediction logic which may be provided on some processors.
-
- -- : BFD_RELOC_ALPHA_LINKAGE
- The LINKAGE relocation outputs a linkage pair in the object file,
- which is filled by the linker.
-
- -- : BFD_RELOC_ALPHA_CODEADDR
- The CODEADDR relocation outputs a STO_CA in the object file, which
- is filled by the linker.
-
- -- : BFD_RELOC_ALPHA_GPREL_HI16
- -- : BFD_RELOC_ALPHA_GPREL_LO16
- The GPREL_HI/LO relocations together form a 32-bit offset from the
- GP register.
-
- -- : BFD_RELOC_ALPHA_BRSGP
- Like BFD_RELOC_23_PCREL_S2, except that the source and target must
- share a common GP, and the target address is adjusted for
- STO_ALPHA_STD_GPLOAD.
-
- -- : BFD_RELOC_ALPHA_NOP
- The NOP relocation outputs a NOP if the longword displacement
- between two procedure entry points is < 2^21.
-
- -- : BFD_RELOC_ALPHA_BSR
- The BSR relocation outputs a BSR if the longword displacement
- between two procedure entry points is < 2^21.
-
- -- : BFD_RELOC_ALPHA_LDA
- The LDA relocation outputs a LDA if the longword displacement
- between two procedure entry points is < 2^16.
-
- -- : BFD_RELOC_ALPHA_BOH
- The BOH relocation outputs a BSR if the longword displacement
- between two procedure entry points is < 2^21, or else a hint.
-
- -- : BFD_RELOC_ALPHA_TLSGD
- -- : BFD_RELOC_ALPHA_TLSLDM
- -- : BFD_RELOC_ALPHA_DTPMOD64
- -- : BFD_RELOC_ALPHA_GOTDTPREL16
- -- : BFD_RELOC_ALPHA_DTPREL64
- -- : BFD_RELOC_ALPHA_DTPREL_HI16
- -- : BFD_RELOC_ALPHA_DTPREL_LO16
- -- : BFD_RELOC_ALPHA_DTPREL16
- -- : BFD_RELOC_ALPHA_GOTTPREL16
- -- : BFD_RELOC_ALPHA_TPREL64
- -- : BFD_RELOC_ALPHA_TPREL_HI16
- -- : BFD_RELOC_ALPHA_TPREL_LO16
- -- : BFD_RELOC_ALPHA_TPREL16
- Alpha thread-local storage relocations.
-
- -- : BFD_RELOC_MIPS_JMP
- Bits 27..2 of the relocation address shifted right 2 bits; simple
- reloc otherwise.
-
- -- : BFD_RELOC_MIPS16_JMP
- The MIPS16 jump instruction.
-
- -- : BFD_RELOC_MIPS16_GPREL
- MIPS16 GP relative reloc.
-
- -- : BFD_RELOC_HI16
- High 16 bits of 32-bit value; simple reloc.
-
- -- : BFD_RELOC_HI16_S
- High 16 bits of 32-bit value but the low 16 bits will be sign
- extended and added to form the final result. If the low 16 bits
- form a negative number, we need to add one to the high value to
- compensate for the borrow when the low bits are added.
-
- -- : BFD_RELOC_LO16
- Low 16 bits.
-
- -- : BFD_RELOC_HI16_PCREL
- High 16 bits of 32-bit pc-relative value
-
- -- : BFD_RELOC_HI16_S_PCREL
- High 16 bits of 32-bit pc-relative value, adjusted
-
- -- : BFD_RELOC_LO16_PCREL
- Low 16 bits of pc-relative value
-
- -- : BFD_RELOC_MIPS16_GOT16
- -- : BFD_RELOC_MIPS16_CALL16
- Equivalent of BFD_RELOC_MIPS_*, but with the MIPS16 layout of
- 16-bit immediate fields
-
- -- : BFD_RELOC_MIPS16_HI16
- MIPS16 high 16 bits of 32-bit value.
-
- -- : BFD_RELOC_MIPS16_HI16_S
- MIPS16 high 16 bits of 32-bit value but the low 16 bits will be
- sign extended and added to form the final result. If the low 16
- bits form a negative number, we need to add one to the high value
- to compensate for the borrow when the low bits are added.
-
- -- : BFD_RELOC_MIPS16_LO16
- MIPS16 low 16 bits.
-
- -- : BFD_RELOC_MIPS_LITERAL
- Relocation against a MIPS literal section.
-
- -- : BFD_RELOC_MIPS_GOT16
- -- : BFD_RELOC_MIPS_CALL16
- -- : BFD_RELOC_MIPS_GOT_HI16
- -- : BFD_RELOC_MIPS_GOT_LO16
- -- : BFD_RELOC_MIPS_CALL_HI16
- -- : BFD_RELOC_MIPS_CALL_LO16
- -- : BFD_RELOC_MIPS_SUB
- -- : BFD_RELOC_MIPS_GOT_PAGE
- -- : BFD_RELOC_MIPS_GOT_OFST
- -- : BFD_RELOC_MIPS_GOT_DISP
- -- : BFD_RELOC_MIPS_SHIFT5
- -- : BFD_RELOC_MIPS_SHIFT6
- -- : BFD_RELOC_MIPS_INSERT_A
- -- : BFD_RELOC_MIPS_INSERT_B
- -- : BFD_RELOC_MIPS_DELETE
- -- : BFD_RELOC_MIPS_HIGHEST
- -- : BFD_RELOC_MIPS_HIGHER
- -- : BFD_RELOC_MIPS_SCN_DISP
- -- : BFD_RELOC_MIPS_REL16
- -- : BFD_RELOC_MIPS_RELGOT
- -- : BFD_RELOC_MIPS_JALR
- -- : BFD_RELOC_MIPS_TLS_DTPMOD32
- -- : BFD_RELOC_MIPS_TLS_DTPREL32
- -- : BFD_RELOC_MIPS_TLS_DTPMOD64
- -- : BFD_RELOC_MIPS_TLS_DTPREL64
- -- : BFD_RELOC_MIPS_TLS_GD
- -- : BFD_RELOC_MIPS_TLS_LDM
- -- : BFD_RELOC_MIPS_TLS_DTPREL_HI16
- -- : BFD_RELOC_MIPS_TLS_DTPREL_LO16
- -- : BFD_RELOC_MIPS_TLS_GOTTPREL
- -- : BFD_RELOC_MIPS_TLS_TPREL32
- -- : BFD_RELOC_MIPS_TLS_TPREL64
- -- : BFD_RELOC_MIPS_TLS_TPREL_HI16
- -- : BFD_RELOC_MIPS_TLS_TPREL_LO16
- MIPS ELF relocations.
-
- -- : BFD_RELOC_MIPS_COPY
- -- : BFD_RELOC_MIPS_JUMP_SLOT
- MIPS ELF relocations (VxWorks and PLT extensions).
-
- -- : BFD_RELOC_MOXIE_10_PCREL
- Moxie ELF relocations.
-
- -- : BFD_RELOC_FRV_LABEL16
- -- : BFD_RELOC_FRV_LABEL24
- -- : BFD_RELOC_FRV_LO16
- -- : BFD_RELOC_FRV_HI16
- -- : BFD_RELOC_FRV_GPREL12
- -- : BFD_RELOC_FRV_GPRELU12
- -- : BFD_RELOC_FRV_GPREL32
- -- : BFD_RELOC_FRV_GPRELHI
- -- : BFD_RELOC_FRV_GPRELLO
- -- : BFD_RELOC_FRV_GOT12
- -- : BFD_RELOC_FRV_GOTHI
- -- : BFD_RELOC_FRV_GOTLO
- -- : BFD_RELOC_FRV_FUNCDESC
- -- : BFD_RELOC_FRV_FUNCDESC_GOT12
- -- : BFD_RELOC_FRV_FUNCDESC_GOTHI
- -- : BFD_RELOC_FRV_FUNCDESC_GOTLO
- -- : BFD_RELOC_FRV_FUNCDESC_VALUE
- -- : BFD_RELOC_FRV_FUNCDESC_GOTOFF12
- -- : BFD_RELOC_FRV_FUNCDESC_GOTOFFHI
- -- : BFD_RELOC_FRV_FUNCDESC_GOTOFFLO
- -- : BFD_RELOC_FRV_GOTOFF12
- -- : BFD_RELOC_FRV_GOTOFFHI
- -- : BFD_RELOC_FRV_GOTOFFLO
- -- : BFD_RELOC_FRV_GETTLSOFF
- -- : BFD_RELOC_FRV_TLSDESC_VALUE
- -- : BFD_RELOC_FRV_GOTTLSDESC12
- -- : BFD_RELOC_FRV_GOTTLSDESCHI
- -- : BFD_RELOC_FRV_GOTTLSDESCLO
- -- : BFD_RELOC_FRV_TLSMOFF12
- -- : BFD_RELOC_FRV_TLSMOFFHI
- -- : BFD_RELOC_FRV_TLSMOFFLO
- -- : BFD_RELOC_FRV_GOTTLSOFF12
- -- : BFD_RELOC_FRV_GOTTLSOFFHI
- -- : BFD_RELOC_FRV_GOTTLSOFFLO
- -- : BFD_RELOC_FRV_TLSOFF
- -- : BFD_RELOC_FRV_TLSDESC_RELAX
- -- : BFD_RELOC_FRV_GETTLSOFF_RELAX
- -- : BFD_RELOC_FRV_TLSOFF_RELAX
- -- : BFD_RELOC_FRV_TLSMOFF
- Fujitsu Frv Relocations.
-
- -- : BFD_RELOC_MN10300_GOTOFF24
- This is a 24bit GOT-relative reloc for the mn10300.
-
- -- : BFD_RELOC_MN10300_GOT32
- This is a 32bit GOT-relative reloc for the mn10300, offset by two
- bytes in the instruction.
-
- -- : BFD_RELOC_MN10300_GOT24
- This is a 24bit GOT-relative reloc for the mn10300, offset by two
- bytes in the instruction.
-
- -- : BFD_RELOC_MN10300_GOT16
- This is a 16bit GOT-relative reloc for the mn10300, offset by two
- bytes in the instruction.
-
- -- : BFD_RELOC_MN10300_COPY
- Copy symbol at runtime.
-
- -- : BFD_RELOC_MN10300_GLOB_DAT
- Create GOT entry.
-
- -- : BFD_RELOC_MN10300_JMP_SLOT
- Create PLT entry.
-
- -- : BFD_RELOC_MN10300_RELATIVE
- Adjust by program base.
-
- -- : BFD_RELOC_MN10300_SYM_DIFF
- Together with another reloc targeted at the same location, allows
- for a value that is the difference of two symbols in the same
- section.
-
- -- : BFD_RELOC_MN10300_ALIGN
- The addend of this reloc is an alignment power that must be
- honoured at the offset's location, regardless of linker relaxation.
-
- -- : BFD_RELOC_386_GOT32
- -- : BFD_RELOC_386_PLT32
- -- : BFD_RELOC_386_COPY
- -- : BFD_RELOC_386_GLOB_DAT
- -- : BFD_RELOC_386_JUMP_SLOT
- -- : BFD_RELOC_386_RELATIVE
- -- : BFD_RELOC_386_GOTOFF
- -- : BFD_RELOC_386_GOTPC
- -- : BFD_RELOC_386_TLS_TPOFF
- -- : BFD_RELOC_386_TLS_IE
- -- : BFD_RELOC_386_TLS_GOTIE
- -- : BFD_RELOC_386_TLS_LE
- -- : BFD_RELOC_386_TLS_GD
- -- : BFD_RELOC_386_TLS_LDM
- -- : BFD_RELOC_386_TLS_LDO_32
- -- : BFD_RELOC_386_TLS_IE_32
- -- : BFD_RELOC_386_TLS_LE_32
- -- : BFD_RELOC_386_TLS_DTPMOD32
- -- : BFD_RELOC_386_TLS_DTPOFF32
- -- : BFD_RELOC_386_TLS_TPOFF32
- -- : BFD_RELOC_386_TLS_GOTDESC
- -- : BFD_RELOC_386_TLS_DESC_CALL
- -- : BFD_RELOC_386_TLS_DESC
- -- : BFD_RELOC_386_IRELATIVE
- i386/elf relocations
-
- -- : BFD_RELOC_X86_64_GOT32
- -- : BFD_RELOC_X86_64_PLT32
- -- : BFD_RELOC_X86_64_COPY
- -- : BFD_RELOC_X86_64_GLOB_DAT
- -- : BFD_RELOC_X86_64_JUMP_SLOT
- -- : BFD_RELOC_X86_64_RELATIVE
- -- : BFD_RELOC_X86_64_GOTPCREL
- -- : BFD_RELOC_X86_64_32S
- -- : BFD_RELOC_X86_64_DTPMOD64
- -- : BFD_RELOC_X86_64_DTPOFF64
- -- : BFD_RELOC_X86_64_TPOFF64
- -- : BFD_RELOC_X86_64_TLSGD
- -- : BFD_RELOC_X86_64_TLSLD
- -- : BFD_RELOC_X86_64_DTPOFF32
- -- : BFD_RELOC_X86_64_GOTTPOFF
- -- : BFD_RELOC_X86_64_TPOFF32
- -- : BFD_RELOC_X86_64_GOTOFF64
- -- : BFD_RELOC_X86_64_GOTPC32
- -- : BFD_RELOC_X86_64_GOT64
- -- : BFD_RELOC_X86_64_GOTPCREL64
- -- : BFD_RELOC_X86_64_GOTPC64
- -- : BFD_RELOC_X86_64_GOTPLT64
- -- : BFD_RELOC_X86_64_PLTOFF64
- -- : BFD_RELOC_X86_64_GOTPC32_TLSDESC
- -- : BFD_RELOC_X86_64_TLSDESC_CALL
- -- : BFD_RELOC_X86_64_TLSDESC
- -- : BFD_RELOC_X86_64_IRELATIVE
- x86-64/elf relocations
-
- -- : BFD_RELOC_NS32K_IMM_8
- -- : BFD_RELOC_NS32K_IMM_16
- -- : BFD_RELOC_NS32K_IMM_32
- -- : BFD_RELOC_NS32K_IMM_8_PCREL
- -- : BFD_RELOC_NS32K_IMM_16_PCREL
- -- : BFD_RELOC_NS32K_IMM_32_PCREL
- -- : BFD_RELOC_NS32K_DISP_8
- -- : BFD_RELOC_NS32K_DISP_16
- -- : BFD_RELOC_NS32K_DISP_32
- -- : BFD_RELOC_NS32K_DISP_8_PCREL
- -- : BFD_RELOC_NS32K_DISP_16_PCREL
- -- : BFD_RELOC_NS32K_DISP_32_PCREL
- ns32k relocations
-
- -- : BFD_RELOC_PDP11_DISP_8_PCREL
- -- : BFD_RELOC_PDP11_DISP_6_PCREL
- PDP11 relocations
-
- -- : BFD_RELOC_PJ_CODE_HI16
- -- : BFD_RELOC_PJ_CODE_LO16
- -- : BFD_RELOC_PJ_CODE_DIR16
- -- : BFD_RELOC_PJ_CODE_DIR32
- -- : BFD_RELOC_PJ_CODE_REL16
- -- : BFD_RELOC_PJ_CODE_REL32
- Picojava relocs. Not all of these appear in object files.
-
- -- : BFD_RELOC_PPC_B26
- -- : BFD_RELOC_PPC_BA26
- -- : BFD_RELOC_PPC_TOC16
- -- : BFD_RELOC_PPC_B16
- -- : BFD_RELOC_PPC_B16_BRTAKEN
- -- : BFD_RELOC_PPC_B16_BRNTAKEN
- -- : BFD_RELOC_PPC_BA16
- -- : BFD_RELOC_PPC_BA16_BRTAKEN
- -- : BFD_RELOC_PPC_BA16_BRNTAKEN
- -- : BFD_RELOC_PPC_COPY
- -- : BFD_RELOC_PPC_GLOB_DAT
- -- : BFD_RELOC_PPC_JMP_SLOT
- -- : BFD_RELOC_PPC_RELATIVE
- -- : BFD_RELOC_PPC_LOCAL24PC
- -- : BFD_RELOC_PPC_EMB_NADDR32
- -- : BFD_RELOC_PPC_EMB_NADDR16
- -- : BFD_RELOC_PPC_EMB_NADDR16_LO
- -- : BFD_RELOC_PPC_EMB_NADDR16_HI
- -- : BFD_RELOC_PPC_EMB_NADDR16_HA
- -- : BFD_RELOC_PPC_EMB_SDAI16
- -- : BFD_RELOC_PPC_EMB_SDA2I16
- -- : BFD_RELOC_PPC_EMB_SDA2REL
- -- : BFD_RELOC_PPC_EMB_SDA21
- -- : BFD_RELOC_PPC_EMB_MRKREF
- -- : BFD_RELOC_PPC_EMB_RELSEC16
- -- : BFD_RELOC_PPC_EMB_RELST_LO
- -- : BFD_RELOC_PPC_EMB_RELST_HI
- -- : BFD_RELOC_PPC_EMB_RELST_HA
- -- : BFD_RELOC_PPC_EMB_BIT_FLD
- -- : BFD_RELOC_PPC_EMB_RELSDA
- -- : BFD_RELOC_PPC64_HIGHER
- -- : BFD_RELOC_PPC64_HIGHER_S
- -- : BFD_RELOC_PPC64_HIGHEST
- -- : BFD_RELOC_PPC64_HIGHEST_S
- -- : BFD_RELOC_PPC64_TOC16_LO
- -- : BFD_RELOC_PPC64_TOC16_HI
- -- : BFD_RELOC_PPC64_TOC16_HA
- -- : BFD_RELOC_PPC64_TOC
- -- : BFD_RELOC_PPC64_PLTGOT16
- -- : BFD_RELOC_PPC64_PLTGOT16_LO
- -- : BFD_RELOC_PPC64_PLTGOT16_HI
- -- : BFD_RELOC_PPC64_PLTGOT16_HA
- -- : BFD_RELOC_PPC64_ADDR16_DS
- -- : BFD_RELOC_PPC64_ADDR16_LO_DS
- -- : BFD_RELOC_PPC64_GOT16_DS
- -- : BFD_RELOC_PPC64_GOT16_LO_DS
- -- : BFD_RELOC_PPC64_PLT16_LO_DS
- -- : BFD_RELOC_PPC64_SECTOFF_DS
- -- : BFD_RELOC_PPC64_SECTOFF_LO_DS
- -- : BFD_RELOC_PPC64_TOC16_DS
- -- : BFD_RELOC_PPC64_TOC16_LO_DS
- -- : BFD_RELOC_PPC64_PLTGOT16_DS
- -- : BFD_RELOC_PPC64_PLTGOT16_LO_DS
- Power(rs6000) and PowerPC relocations.
-
- -- : BFD_RELOC_PPC_TLS
- -- : BFD_RELOC_PPC_TLSGD
- -- : BFD_RELOC_PPC_TLSLD
- -- : BFD_RELOC_PPC_DTPMOD
- -- : BFD_RELOC_PPC_TPREL16
- -- : BFD_RELOC_PPC_TPREL16_LO
- -- : BFD_RELOC_PPC_TPREL16_HI
- -- : BFD_RELOC_PPC_TPREL16_HA
- -- : BFD_RELOC_PPC_TPREL
- -- : BFD_RELOC_PPC_DTPREL16
- -- : BFD_RELOC_PPC_DTPREL16_LO
- -- : BFD_RELOC_PPC_DTPREL16_HI
- -- : BFD_RELOC_PPC_DTPREL16_HA
- -- : BFD_RELOC_PPC_DTPREL
- -- : BFD_RELOC_PPC_GOT_TLSGD16
- -- : BFD_RELOC_PPC_GOT_TLSGD16_LO
- -- : BFD_RELOC_PPC_GOT_TLSGD16_HI
- -- : BFD_RELOC_PPC_GOT_TLSGD16_HA
- -- : BFD_RELOC_PPC_GOT_TLSLD16
- -- : BFD_RELOC_PPC_GOT_TLSLD16_LO
- -- : BFD_RELOC_PPC_GOT_TLSLD16_HI
- -- : BFD_RELOC_PPC_GOT_TLSLD16_HA
- -- : BFD_RELOC_PPC_GOT_TPREL16
- -- : BFD_RELOC_PPC_GOT_TPREL16_LO
- -- : BFD_RELOC_PPC_GOT_TPREL16_HI
- -- : BFD_RELOC_PPC_GOT_TPREL16_HA
- -- : BFD_RELOC_PPC_GOT_DTPREL16
- -- : BFD_RELOC_PPC_GOT_DTPREL16_LO
- -- : BFD_RELOC_PPC_GOT_DTPREL16_HI
- -- : BFD_RELOC_PPC_GOT_DTPREL16_HA
- -- : BFD_RELOC_PPC64_TPREL16_DS
- -- : BFD_RELOC_PPC64_TPREL16_LO_DS
- -- : BFD_RELOC_PPC64_TPREL16_HIGHER
- -- : BFD_RELOC_PPC64_TPREL16_HIGHERA
- -- : BFD_RELOC_PPC64_TPREL16_HIGHEST
- -- : BFD_RELOC_PPC64_TPREL16_HIGHESTA
- -- : BFD_RELOC_PPC64_DTPREL16_DS
- -- : BFD_RELOC_PPC64_DTPREL16_LO_DS
- -- : BFD_RELOC_PPC64_DTPREL16_HIGHER
- -- : BFD_RELOC_PPC64_DTPREL16_HIGHERA
- -- : BFD_RELOC_PPC64_DTPREL16_HIGHEST
- -- : BFD_RELOC_PPC64_DTPREL16_HIGHESTA
- PowerPC and PowerPC64 thread-local storage relocations.
-
- -- : BFD_RELOC_I370_D12
- IBM 370/390 relocations
-
- -- : BFD_RELOC_CTOR
- The type of reloc used to build a constructor table - at the moment
- probably a 32 bit wide absolute relocation, but the target can
- choose. It generally does map to one of the other relocation
- types.
-
- -- : BFD_RELOC_ARM_PCREL_BRANCH
- ARM 26 bit pc-relative branch. The lowest two bits must be zero
- and are not stored in the instruction.
-
- -- : BFD_RELOC_ARM_PCREL_BLX
- ARM 26 bit pc-relative branch. The lowest bit must be zero and is
- not stored in the instruction. The 2nd lowest bit comes from a 1
- bit field in the instruction.
-
- -- : BFD_RELOC_THUMB_PCREL_BLX
- Thumb 22 bit pc-relative branch. The lowest bit must be zero and
- is not stored in the instruction. The 2nd lowest bit comes from a
- 1 bit field in the instruction.
-
- -- : BFD_RELOC_ARM_PCREL_CALL
- ARM 26-bit pc-relative branch for an unconditional BL or BLX
- instruction.
-
- -- : BFD_RELOC_ARM_PCREL_JUMP
- ARM 26-bit pc-relative branch for B or conditional BL instruction.
-
- -- : BFD_RELOC_THUMB_PCREL_BRANCH7
- -- : BFD_RELOC_THUMB_PCREL_BRANCH9
- -- : BFD_RELOC_THUMB_PCREL_BRANCH12
- -- : BFD_RELOC_THUMB_PCREL_BRANCH20
- -- : BFD_RELOC_THUMB_PCREL_BRANCH23
- -- : BFD_RELOC_THUMB_PCREL_BRANCH25
- Thumb 7-, 9-, 12-, 20-, 23-, and 25-bit pc-relative branches. The
- lowest bit must be zero and is not stored in the instruction.
- Note that the corresponding ELF R_ARM_THM_JUMPnn constant has an
- "nn" one smaller in all cases. Note further that BRANCH23
- corresponds to R_ARM_THM_CALL.
-
- -- : BFD_RELOC_ARM_OFFSET_IMM
- 12-bit immediate offset, used in ARM-format ldr and str
- instructions.
-
- -- : BFD_RELOC_ARM_THUMB_OFFSET
- 5-bit immediate offset, used in Thumb-format ldr and str
- instructions.
-
- -- : BFD_RELOC_ARM_TARGET1
- Pc-relative or absolute relocation depending on target. Used for
- entries in .init_array sections.
-
- -- : BFD_RELOC_ARM_ROSEGREL32
- Read-only segment base relative address.
-
- -- : BFD_RELOC_ARM_SBREL32
- Data segment base relative address.
-
- -- : BFD_RELOC_ARM_TARGET2
- This reloc is used for references to RTTI data from exception
- handling tables. The actual definition depends on the target. It
- may be a pc-relative or some form of GOT-indirect relocation.
-
- -- : BFD_RELOC_ARM_PREL31
- 31-bit PC relative address.
-
- -- : BFD_RELOC_ARM_MOVW
- -- : BFD_RELOC_ARM_MOVT
- -- : BFD_RELOC_ARM_MOVW_PCREL
- -- : BFD_RELOC_ARM_MOVT_PCREL
- -- : BFD_RELOC_ARM_THUMB_MOVW
- -- : BFD_RELOC_ARM_THUMB_MOVT
- -- : BFD_RELOC_ARM_THUMB_MOVW_PCREL
- -- : BFD_RELOC_ARM_THUMB_MOVT_PCREL
- Low and High halfword relocations for MOVW and MOVT instructions.
-
- -- : BFD_RELOC_ARM_JUMP_SLOT
- -- : BFD_RELOC_ARM_GLOB_DAT
- -- : BFD_RELOC_ARM_GOT32
- -- : BFD_RELOC_ARM_PLT32
- -- : BFD_RELOC_ARM_RELATIVE
- -- : BFD_RELOC_ARM_GOTOFF
- -- : BFD_RELOC_ARM_GOTPC
- -- : BFD_RELOC_ARM_GOT_PREL
- Relocations for setting up GOTs and PLTs for shared libraries.
-
- -- : BFD_RELOC_ARM_TLS_GD32
- -- : BFD_RELOC_ARM_TLS_LDO32
- -- : BFD_RELOC_ARM_TLS_LDM32
- -- : BFD_RELOC_ARM_TLS_DTPOFF32
- -- : BFD_RELOC_ARM_TLS_DTPMOD32
- -- : BFD_RELOC_ARM_TLS_TPOFF32
- -- : BFD_RELOC_ARM_TLS_IE32
- -- : BFD_RELOC_ARM_TLS_LE32
- -- : BFD_RELOC_ARM_TLS_GOTDESC
- -- : BFD_RELOC_ARM_TLS_CALL
- -- : BFD_RELOC_ARM_THM_TLS_CALL
- -- : BFD_RELOC_ARM_TLS_DESCSEQ
- -- : BFD_RELOC_ARM_THM_TLS_DESCSEQ
- -- : BFD_RELOC_ARM_TLS_DESC
- ARM thread-local storage relocations.
-
- -- : BFD_RELOC_ARM_ALU_PC_G0_NC
- -- : BFD_RELOC_ARM_ALU_PC_G0
- -- : BFD_RELOC_ARM_ALU_PC_G1_NC
- -- : BFD_RELOC_ARM_ALU_PC_G1
- -- : BFD_RELOC_ARM_ALU_PC_G2
- -- : BFD_RELOC_ARM_LDR_PC_G0
- -- : BFD_RELOC_ARM_LDR_PC_G1
- -- : BFD_RELOC_ARM_LDR_PC_G2
- -- : BFD_RELOC_ARM_LDRS_PC_G0
- -- : BFD_RELOC_ARM_LDRS_PC_G1
- -- : BFD_RELOC_ARM_LDRS_PC_G2
- -- : BFD_RELOC_ARM_LDC_PC_G0
- -- : BFD_RELOC_ARM_LDC_PC_G1
- -- : BFD_RELOC_ARM_LDC_PC_G2
- -- : BFD_RELOC_ARM_ALU_SB_G0_NC
- -- : BFD_RELOC_ARM_ALU_SB_G0
- -- : BFD_RELOC_ARM_ALU_SB_G1_NC
- -- : BFD_RELOC_ARM_ALU_SB_G1
- -- : BFD_RELOC_ARM_ALU_SB_G2
- -- : BFD_RELOC_ARM_LDR_SB_G0
- -- : BFD_RELOC_ARM_LDR_SB_G1
- -- : BFD_RELOC_ARM_LDR_SB_G2
- -- : BFD_RELOC_ARM_LDRS_SB_G0
- -- : BFD_RELOC_ARM_LDRS_SB_G1
- -- : BFD_RELOC_ARM_LDRS_SB_G2
- -- : BFD_RELOC_ARM_LDC_SB_G0
- -- : BFD_RELOC_ARM_LDC_SB_G1
- -- : BFD_RELOC_ARM_LDC_SB_G2
- ARM group relocations.
-
- -- : BFD_RELOC_ARM_V4BX
- Annotation of BX instructions.
-
- -- : BFD_RELOC_ARM_IRELATIVE
- ARM support for STT_GNU_IFUNC.
-
- -- : BFD_RELOC_ARM_IMMEDIATE
- -- : BFD_RELOC_ARM_ADRL_IMMEDIATE
- -- : BFD_RELOC_ARM_T32_IMMEDIATE
- -- : BFD_RELOC_ARM_T32_ADD_IMM
- -- : BFD_RELOC_ARM_T32_IMM12
- -- : BFD_RELOC_ARM_T32_ADD_PC12
- -- : BFD_RELOC_ARM_SHIFT_IMM
- -- : BFD_RELOC_ARM_SMC
- -- : BFD_RELOC_ARM_HVC
- -- : BFD_RELOC_ARM_SWI
- -- : BFD_RELOC_ARM_MULTI
- -- : BFD_RELOC_ARM_CP_OFF_IMM
- -- : BFD_RELOC_ARM_CP_OFF_IMM_S2
- -- : BFD_RELOC_ARM_T32_CP_OFF_IMM
- -- : BFD_RELOC_ARM_T32_CP_OFF_IMM_S2
- -- : BFD_RELOC_ARM_ADR_IMM
- -- : BFD_RELOC_ARM_LDR_IMM
- -- : BFD_RELOC_ARM_LITERAL
- -- : BFD_RELOC_ARM_IN_POOL
- -- : BFD_RELOC_ARM_OFFSET_IMM8
- -- : BFD_RELOC_ARM_T32_OFFSET_U8
- -- : BFD_RELOC_ARM_T32_OFFSET_IMM
- -- : BFD_RELOC_ARM_HWLITERAL
- -- : BFD_RELOC_ARM_THUMB_ADD
- -- : BFD_RELOC_ARM_THUMB_IMM
- -- : BFD_RELOC_ARM_THUMB_SHIFT
- These relocs are only used within the ARM assembler. They are not
- (at present) written to any object files.
-
- -- : BFD_RELOC_SH_PCDISP8BY2
- -- : BFD_RELOC_SH_PCDISP12BY2
- -- : BFD_RELOC_SH_IMM3
- -- : BFD_RELOC_SH_IMM3U
- -- : BFD_RELOC_SH_DISP12
- -- : BFD_RELOC_SH_DISP12BY2
- -- : BFD_RELOC_SH_DISP12BY4
- -- : BFD_RELOC_SH_DISP12BY8
- -- : BFD_RELOC_SH_DISP20
- -- : BFD_RELOC_SH_DISP20BY8
- -- : BFD_RELOC_SH_IMM4
- -- : BFD_RELOC_SH_IMM4BY2
- -- : BFD_RELOC_SH_IMM4BY4
- -- : BFD_RELOC_SH_IMM8
- -- : BFD_RELOC_SH_IMM8BY2
- -- : BFD_RELOC_SH_IMM8BY4
- -- : BFD_RELOC_SH_PCRELIMM8BY2
- -- : BFD_RELOC_SH_PCRELIMM8BY4
- -- : BFD_RELOC_SH_SWITCH16
- -- : BFD_RELOC_SH_SWITCH32
- -- : BFD_RELOC_SH_USES
- -- : BFD_RELOC_SH_COUNT
- -- : BFD_RELOC_SH_ALIGN
- -- : BFD_RELOC_SH_CODE
- -- : BFD_RELOC_SH_DATA
- -- : BFD_RELOC_SH_LABEL
- -- : BFD_RELOC_SH_LOOP_START
- -- : BFD_RELOC_SH_LOOP_END
- -- : BFD_RELOC_SH_COPY
- -- : BFD_RELOC_SH_GLOB_DAT
- -- : BFD_RELOC_SH_JMP_SLOT
- -- : BFD_RELOC_SH_RELATIVE
- -- : BFD_RELOC_SH_GOTPC
- -- : BFD_RELOC_SH_GOT_LOW16
- -- : BFD_RELOC_SH_GOT_MEDLOW16
- -- : BFD_RELOC_SH_GOT_MEDHI16
- -- : BFD_RELOC_SH_GOT_HI16
- -- : BFD_RELOC_SH_GOTPLT_LOW16
- -- : BFD_RELOC_SH_GOTPLT_MEDLOW16
- -- : BFD_RELOC_SH_GOTPLT_MEDHI16
- -- : BFD_RELOC_SH_GOTPLT_HI16
- -- : BFD_RELOC_SH_PLT_LOW16
- -- : BFD_RELOC_SH_PLT_MEDLOW16
- -- : BFD_RELOC_SH_PLT_MEDHI16
- -- : BFD_RELOC_SH_PLT_HI16
- -- : BFD_RELOC_SH_GOTOFF_LOW16
- -- : BFD_RELOC_SH_GOTOFF_MEDLOW16
- -- : BFD_RELOC_SH_GOTOFF_MEDHI16
- -- : BFD_RELOC_SH_GOTOFF_HI16
- -- : BFD_RELOC_SH_GOTPC_LOW16
- -- : BFD_RELOC_SH_GOTPC_MEDLOW16
- -- : BFD_RELOC_SH_GOTPC_MEDHI16
- -- : BFD_RELOC_SH_GOTPC_HI16
- -- : BFD_RELOC_SH_COPY64
- -- : BFD_RELOC_SH_GLOB_DAT64
- -- : BFD_RELOC_SH_JMP_SLOT64
- -- : BFD_RELOC_SH_RELATIVE64
- -- : BFD_RELOC_SH_GOT10BY4
- -- : BFD_RELOC_SH_GOT10BY8
- -- : BFD_RELOC_SH_GOTPLT10BY4
- -- : BFD_RELOC_SH_GOTPLT10BY8
- -- : BFD_RELOC_SH_GOTPLT32
- -- : BFD_RELOC_SH_SHMEDIA_CODE
- -- : BFD_RELOC_SH_IMMU5
- -- : BFD_RELOC_SH_IMMS6
- -- : BFD_RELOC_SH_IMMS6BY32
- -- : BFD_RELOC_SH_IMMU6
- -- : BFD_RELOC_SH_IMMS10
- -- : BFD_RELOC_SH_IMMS10BY2
- -- : BFD_RELOC_SH_IMMS10BY4
- -- : BFD_RELOC_SH_IMMS10BY8
- -- : BFD_RELOC_SH_IMMS16
- -- : BFD_RELOC_SH_IMMU16
- -- : BFD_RELOC_SH_IMM_LOW16
- -- : BFD_RELOC_SH_IMM_LOW16_PCREL
- -- : BFD_RELOC_SH_IMM_MEDLOW16
- -- : BFD_RELOC_SH_IMM_MEDLOW16_PCREL
- -- : BFD_RELOC_SH_IMM_MEDHI16
- -- : BFD_RELOC_SH_IMM_MEDHI16_PCREL
- -- : BFD_RELOC_SH_IMM_HI16
- -- : BFD_RELOC_SH_IMM_HI16_PCREL
- -- : BFD_RELOC_SH_PT_16
- -- : BFD_RELOC_SH_TLS_GD_32
- -- : BFD_RELOC_SH_TLS_LD_32
- -- : BFD_RELOC_SH_TLS_LDO_32
- -- : BFD_RELOC_SH_TLS_IE_32
- -- : BFD_RELOC_SH_TLS_LE_32
- -- : BFD_RELOC_SH_TLS_DTPMOD32
- -- : BFD_RELOC_SH_TLS_DTPOFF32
- -- : BFD_RELOC_SH_TLS_TPOFF32
- -- : BFD_RELOC_SH_GOT20
- -- : BFD_RELOC_SH_GOTOFF20
- -- : BFD_RELOC_SH_GOTFUNCDESC
- -- : BFD_RELOC_SH_GOTFUNCDESC20
- -- : BFD_RELOC_SH_GOTOFFFUNCDESC
- -- : BFD_RELOC_SH_GOTOFFFUNCDESC20
- -- : BFD_RELOC_SH_FUNCDESC
- Renesas / SuperH SH relocs. Not all of these appear in object
- files.
-
- -- : BFD_RELOC_ARC_B22_PCREL
- ARC Cores relocs. ARC 22 bit pc-relative branch. The lowest two
- bits must be zero and are not stored in the instruction. The high
- 20 bits are installed in bits 26 through 7 of the instruction.
-
- -- : BFD_RELOC_ARC_B26
- ARC 26 bit absolute branch. The lowest two bits must be zero and
- are not stored in the instruction. The high 24 bits are installed
- in bits 23 through 0.
-
- -- : BFD_RELOC_BFIN_16_IMM
- ADI Blackfin 16 bit immediate absolute reloc.
-
- -- : BFD_RELOC_BFIN_16_HIGH
- ADI Blackfin 16 bit immediate absolute reloc higher 16 bits.
-
- -- : BFD_RELOC_BFIN_4_PCREL
- ADI Blackfin 'a' part of LSETUP.
-
- -- : BFD_RELOC_BFIN_5_PCREL
- ADI Blackfin.
-
- -- : BFD_RELOC_BFIN_16_LOW
- ADI Blackfin 16 bit immediate absolute reloc lower 16 bits.
-
- -- : BFD_RELOC_BFIN_10_PCREL
- ADI Blackfin.
-
- -- : BFD_RELOC_BFIN_11_PCREL
- ADI Blackfin 'b' part of LSETUP.
-
- -- : BFD_RELOC_BFIN_12_PCREL_JUMP
- ADI Blackfin.
-
- -- : BFD_RELOC_BFIN_12_PCREL_JUMP_S
- ADI Blackfin Short jump, pcrel.
-
- -- : BFD_RELOC_BFIN_24_PCREL_CALL_X
- ADI Blackfin Call.x not implemented.
-
- -- : BFD_RELOC_BFIN_24_PCREL_JUMP_L
- ADI Blackfin Long Jump pcrel.
-
- -- : BFD_RELOC_BFIN_GOT17M4
- -- : BFD_RELOC_BFIN_GOTHI
- -- : BFD_RELOC_BFIN_GOTLO
- -- : BFD_RELOC_BFIN_FUNCDESC
- -- : BFD_RELOC_BFIN_FUNCDESC_GOT17M4
- -- : BFD_RELOC_BFIN_FUNCDESC_GOTHI
- -- : BFD_RELOC_BFIN_FUNCDESC_GOTLO
- -- : BFD_RELOC_BFIN_FUNCDESC_VALUE
- -- : BFD_RELOC_BFIN_FUNCDESC_GOTOFF17M4
- -- : BFD_RELOC_BFIN_FUNCDESC_GOTOFFHI
- -- : BFD_RELOC_BFIN_FUNCDESC_GOTOFFLO
- -- : BFD_RELOC_BFIN_GOTOFF17M4
- -- : BFD_RELOC_BFIN_GOTOFFHI
- -- : BFD_RELOC_BFIN_GOTOFFLO
- ADI Blackfin FD-PIC relocations.
-
- -- : BFD_RELOC_BFIN_GOT
- ADI Blackfin GOT relocation.
-
- -- : BFD_RELOC_BFIN_PLTPC
- ADI Blackfin PLTPC relocation.
-
- -- : BFD_ARELOC_BFIN_PUSH
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_CONST
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_ADD
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_SUB
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_MULT
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_DIV
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_MOD
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_LSHIFT
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_RSHIFT
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_AND
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_OR
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_XOR
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_LAND
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_LOR
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_LEN
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_NEG
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_COMP
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_PAGE
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_HWPAGE
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_ARELOC_BFIN_ADDR
- ADI Blackfin arithmetic relocation.
-
- -- : BFD_RELOC_D10V_10_PCREL_R
- Mitsubishi D10V relocs. This is a 10-bit reloc with the right 2
- bits assumed to be 0.
-
- -- : BFD_RELOC_D10V_10_PCREL_L
- Mitsubishi D10V relocs. This is a 10-bit reloc with the right 2
- bits assumed to be 0. This is the same as the previous reloc
- except it is in the left container, i.e., shifted left 15 bits.
-
- -- : BFD_RELOC_D10V_18
- This is an 18-bit reloc with the right 2 bits assumed to be 0.
-
- -- : BFD_RELOC_D10V_18_PCREL
- This is an 18-bit reloc with the right 2 bits assumed to be 0.
-
- -- : BFD_RELOC_D30V_6
- Mitsubishi D30V relocs. This is a 6-bit absolute reloc.
-
- -- : BFD_RELOC_D30V_9_PCREL
- This is a 6-bit pc-relative reloc with the right 3 bits assumed to
- be 0.
-
- -- : BFD_RELOC_D30V_9_PCREL_R
- This is a 6-bit pc-relative reloc with the right 3 bits assumed to
- be 0. Same as the previous reloc but on the right side of the
- container.
-
- -- : BFD_RELOC_D30V_15
- This is a 12-bit absolute reloc with the right 3 bitsassumed to be
- 0.
-
- -- : BFD_RELOC_D30V_15_PCREL
- This is a 12-bit pc-relative reloc with the right 3 bits assumed
- to be 0.
-
- -- : BFD_RELOC_D30V_15_PCREL_R
- This is a 12-bit pc-relative reloc with the right 3 bits assumed
- to be 0. Same as the previous reloc but on the right side of the
- container.
-
- -- : BFD_RELOC_D30V_21
- This is an 18-bit absolute reloc with the right 3 bits assumed to
- be 0.
-
- -- : BFD_RELOC_D30V_21_PCREL
- This is an 18-bit pc-relative reloc with the right 3 bits assumed
- to be 0.
-
- -- : BFD_RELOC_D30V_21_PCREL_R
- This is an 18-bit pc-relative reloc with the right 3 bits assumed
- to be 0. Same as the previous reloc but on the right side of the
- container.
-
- -- : BFD_RELOC_D30V_32
- This is a 32-bit absolute reloc.
-
- -- : BFD_RELOC_D30V_32_PCREL
- This is a 32-bit pc-relative reloc.
-
- -- : BFD_RELOC_DLX_HI16_S
- DLX relocs
-
- -- : BFD_RELOC_DLX_LO16
- DLX relocs
-
- -- : BFD_RELOC_DLX_JMP26
- DLX relocs
-
- -- : BFD_RELOC_M32C_HI8
- -- : BFD_RELOC_M32C_RL_JUMP
- -- : BFD_RELOC_M32C_RL_1ADDR
- -- : BFD_RELOC_M32C_RL_2ADDR
- Renesas M16C/M32C Relocations.
-
- -- : BFD_RELOC_M32R_24
- Renesas M32R (formerly Mitsubishi M32R) relocs. This is a 24 bit
- absolute address.
-
- -- : BFD_RELOC_M32R_10_PCREL
- This is a 10-bit pc-relative reloc with the right 2 bits assumed
- to be 0.
-
- -- : BFD_RELOC_M32R_18_PCREL
- This is an 18-bit reloc with the right 2 bits assumed to be 0.
-
- -- : BFD_RELOC_M32R_26_PCREL
- This is a 26-bit reloc with the right 2 bits assumed to be 0.
-
- -- : BFD_RELOC_M32R_HI16_ULO
- This is a 16-bit reloc containing the high 16 bits of an address
- used when the lower 16 bits are treated as unsigned.
-
- -- : BFD_RELOC_M32R_HI16_SLO
- This is a 16-bit reloc containing the high 16 bits of an address
- used when the lower 16 bits are treated as signed.
-
- -- : BFD_RELOC_M32R_LO16
- This is a 16-bit reloc containing the lower 16 bits of an address.
-
- -- : BFD_RELOC_M32R_SDA16
- This is a 16-bit reloc containing the small data area offset for
- use in add3, load, and store instructions.
-
- -- : BFD_RELOC_M32R_GOT24
- -- : BFD_RELOC_M32R_26_PLTREL
- -- : BFD_RELOC_M32R_COPY
- -- : BFD_RELOC_M32R_GLOB_DAT
- -- : BFD_RELOC_M32R_JMP_SLOT
- -- : BFD_RELOC_M32R_RELATIVE
- -- : BFD_RELOC_M32R_GOTOFF
- -- : BFD_RELOC_M32R_GOTOFF_HI_ULO
- -- : BFD_RELOC_M32R_GOTOFF_HI_SLO
- -- : BFD_RELOC_M32R_GOTOFF_LO
- -- : BFD_RELOC_M32R_GOTPC24
- -- : BFD_RELOC_M32R_GOT16_HI_ULO
- -- : BFD_RELOC_M32R_GOT16_HI_SLO
- -- : BFD_RELOC_M32R_GOT16_LO
- -- : BFD_RELOC_M32R_GOTPC_HI_ULO
- -- : BFD_RELOC_M32R_GOTPC_HI_SLO
- -- : BFD_RELOC_M32R_GOTPC_LO
- For PIC.
-
- -- : BFD_RELOC_V850_9_PCREL
- This is a 9-bit reloc
-
- -- : BFD_RELOC_V850_22_PCREL
- This is a 22-bit reloc
-
- -- : BFD_RELOC_V850_SDA_16_16_OFFSET
- This is a 16 bit offset from the short data area pointer.
-
- -- : BFD_RELOC_V850_SDA_15_16_OFFSET
- This is a 16 bit offset (of which only 15 bits are used) from the
- short data area pointer.
-
- -- : BFD_RELOC_V850_ZDA_16_16_OFFSET
- This is a 16 bit offset from the zero data area pointer.
-
- -- : BFD_RELOC_V850_ZDA_15_16_OFFSET
- This is a 16 bit offset (of which only 15 bits are used) from the
- zero data area pointer.
-
- -- : BFD_RELOC_V850_TDA_6_8_OFFSET
- This is an 8 bit offset (of which only 6 bits are used) from the
- tiny data area pointer.
-
- -- : BFD_RELOC_V850_TDA_7_8_OFFSET
- This is an 8bit offset (of which only 7 bits are used) from the
- tiny data area pointer.
-
- -- : BFD_RELOC_V850_TDA_7_7_OFFSET
- This is a 7 bit offset from the tiny data area pointer.
-
- -- : BFD_RELOC_V850_TDA_16_16_OFFSET
- This is a 16 bit offset from the tiny data area pointer.
-
- -- : BFD_RELOC_V850_TDA_4_5_OFFSET
- This is a 5 bit offset (of which only 4 bits are used) from the
- tiny data area pointer.
-
- -- : BFD_RELOC_V850_TDA_4_4_OFFSET
- This is a 4 bit offset from the tiny data area pointer.
-
- -- : BFD_RELOC_V850_SDA_16_16_SPLIT_OFFSET
- This is a 16 bit offset from the short data area pointer, with the
- bits placed non-contiguously in the instruction.
-
- -- : BFD_RELOC_V850_ZDA_16_16_SPLIT_OFFSET
- This is a 16 bit offset from the zero data area pointer, with the
- bits placed non-contiguously in the instruction.
-
- -- : BFD_RELOC_V850_CALLT_6_7_OFFSET
- This is a 6 bit offset from the call table base pointer.
-
- -- : BFD_RELOC_V850_CALLT_16_16_OFFSET
- This is a 16 bit offset from the call table base pointer.
-
- -- : BFD_RELOC_V850_LONGCALL
- Used for relaxing indirect function calls.
-
- -- : BFD_RELOC_V850_LONGJUMP
- Used for relaxing indirect jumps.
-
- -- : BFD_RELOC_V850_ALIGN
- Used to maintain alignment whilst relaxing.
-
- -- : BFD_RELOC_V850_LO16_SPLIT_OFFSET
- This is a variation of BFD_RELOC_LO16 that can be used in v850e
- ld.bu instructions.
-
- -- : BFD_RELOC_V850_16_PCREL
- This is a 16-bit reloc.
-
- -- : BFD_RELOC_V850_17_PCREL
- This is a 17-bit reloc.
-
- -- : BFD_RELOC_V850_23
- This is a 23-bit reloc.
-
- -- : BFD_RELOC_V850_32_PCREL
- This is a 32-bit reloc.
-
- -- : BFD_RELOC_V850_32_ABS
- This is a 32-bit reloc.
-
- -- : BFD_RELOC_V850_16_SPLIT_OFFSET
- This is a 16-bit reloc.
-
- -- : BFD_RELOC_V850_16_S1
- This is a 16-bit reloc.
-
- -- : BFD_RELOC_V850_LO16_S1
- Low 16 bits. 16 bit shifted by 1.
-
- -- : BFD_RELOC_V850_CALLT_15_16_OFFSET
- This is a 16 bit offset from the call table base pointer.
-
- -- : BFD_RELOC_V850_32_GOTPCREL
- DSO relocations.
-
- -- : BFD_RELOC_V850_16_GOT
- DSO relocations.
-
- -- : BFD_RELOC_V850_32_GOT
- DSO relocations.
-
- -- : BFD_RELOC_V850_22_PLT_PCREL
- DSO relocations.
-
- -- : BFD_RELOC_V850_32_PLT_PCREL
- DSO relocations.
-
- -- : BFD_RELOC_V850_COPY
- DSO relocations.
-
- -- : BFD_RELOC_V850_GLOB_DAT
- DSO relocations.
-
- -- : BFD_RELOC_V850_JMP_SLOT
- DSO relocations.
-
- -- : BFD_RELOC_V850_RELATIVE
- DSO relocations.
-
- -- : BFD_RELOC_V850_16_GOTOFF
- DSO relocations.
-
- -- : BFD_RELOC_V850_32_GOTOFF
- DSO relocations.
-
- -- : BFD_RELOC_V850_CODE
- start code.
-
- -- : BFD_RELOC_V850_DATA
- start data in text.
-
- -- : BFD_RELOC_MN10300_32_PCREL
- This is a 32bit pcrel reloc for the mn10300, offset by two bytes
- in the instruction.
-
- -- : BFD_RELOC_MN10300_16_PCREL
- This is a 16bit pcrel reloc for the mn10300, offset by two bytes
- in the instruction.
-
- -- : BFD_RELOC_TIC30_LDP
- This is a 8bit DP reloc for the tms320c30, where the most
- significant 8 bits of a 24 bit word are placed into the least
- significant 8 bits of the opcode.
-
- -- : BFD_RELOC_TIC54X_PARTLS7
- This is a 7bit reloc for the tms320c54x, where the least
- significant 7 bits of a 16 bit word are placed into the least
- significant 7 bits of the opcode.
-
- -- : BFD_RELOC_TIC54X_PARTMS9
- This is a 9bit DP reloc for the tms320c54x, where the most
- significant 9 bits of a 16 bit word are placed into the least
- significant 9 bits of the opcode.
-
- -- : BFD_RELOC_TIC54X_23
- This is an extended address 23-bit reloc for the tms320c54x.
-
- -- : BFD_RELOC_TIC54X_16_OF_23
- This is a 16-bit reloc for the tms320c54x, where the least
- significant 16 bits of a 23-bit extended address are placed into
- the opcode.
-
- -- : BFD_RELOC_TIC54X_MS7_OF_23
- This is a reloc for the tms320c54x, where the most significant 7
- bits of a 23-bit extended address are placed into the opcode.
-
- -- : BFD_RELOC_C6000_PCR_S21
- -- : BFD_RELOC_C6000_PCR_S12
- -- : BFD_RELOC_C6000_PCR_S10
- -- : BFD_RELOC_C6000_PCR_S7
- -- : BFD_RELOC_C6000_ABS_S16
- -- : BFD_RELOC_C6000_ABS_L16
- -- : BFD_RELOC_C6000_ABS_H16
- -- : BFD_RELOC_C6000_SBR_U15_B
- -- : BFD_RELOC_C6000_SBR_U15_H
- -- : BFD_RELOC_C6000_SBR_U15_W
- -- : BFD_RELOC_C6000_SBR_S16
- -- : BFD_RELOC_C6000_SBR_L16_B
- -- : BFD_RELOC_C6000_SBR_L16_H
- -- : BFD_RELOC_C6000_SBR_L16_W
- -- : BFD_RELOC_C6000_SBR_H16_B
- -- : BFD_RELOC_C6000_SBR_H16_H
- -- : BFD_RELOC_C6000_SBR_H16_W
- -- : BFD_RELOC_C6000_SBR_GOT_U15_W
- -- : BFD_RELOC_C6000_SBR_GOT_L16_W
- -- : BFD_RELOC_C6000_SBR_GOT_H16_W
- -- : BFD_RELOC_C6000_DSBT_INDEX
- -- : BFD_RELOC_C6000_PREL31
- -- : BFD_RELOC_C6000_COPY
- -- : BFD_RELOC_C6000_JUMP_SLOT
- -- : BFD_RELOC_C6000_EHTYPE
- -- : BFD_RELOC_C6000_PCR_H16
- -- : BFD_RELOC_C6000_PCR_L16
- -- : BFD_RELOC_C6000_ALIGN
- -- : BFD_RELOC_C6000_FPHEAD
- -- : BFD_RELOC_C6000_NOCMP
- TMS320C6000 relocations.
-
- -- : BFD_RELOC_FR30_48
- This is a 48 bit reloc for the FR30 that stores 32 bits.
-
- -- : BFD_RELOC_FR30_20
- This is a 32 bit reloc for the FR30 that stores 20 bits split up
- into two sections.
-
- -- : BFD_RELOC_FR30_6_IN_4
- This is a 16 bit reloc for the FR30 that stores a 6 bit word
- offset in 4 bits.
-
- -- : BFD_RELOC_FR30_8_IN_8
- This is a 16 bit reloc for the FR30 that stores an 8 bit byte
- offset into 8 bits.
-
- -- : BFD_RELOC_FR30_9_IN_8
- This is a 16 bit reloc for the FR30 that stores a 9 bit short
- offset into 8 bits.
-
- -- : BFD_RELOC_FR30_10_IN_8
- This is a 16 bit reloc for the FR30 that stores a 10 bit word
- offset into 8 bits.
-
- -- : BFD_RELOC_FR30_9_PCREL
- This is a 16 bit reloc for the FR30 that stores a 9 bit pc relative
- short offset into 8 bits.
-
- -- : BFD_RELOC_FR30_12_PCREL
- This is a 16 bit reloc for the FR30 that stores a 12 bit pc
- relative short offset into 11 bits.
-
- -- : BFD_RELOC_MCORE_PCREL_IMM8BY4
- -- : BFD_RELOC_MCORE_PCREL_IMM11BY2
- -- : BFD_RELOC_MCORE_PCREL_IMM4BY2
- -- : BFD_RELOC_MCORE_PCREL_32
- -- : BFD_RELOC_MCORE_PCREL_JSR_IMM11BY2
- -- : BFD_RELOC_MCORE_RVA
- Motorola Mcore relocations.
-
- -- : BFD_RELOC_MEP_8
- -- : BFD_RELOC_MEP_16
- -- : BFD_RELOC_MEP_32
- -- : BFD_RELOC_MEP_PCREL8A2
- -- : BFD_RELOC_MEP_PCREL12A2
- -- : BFD_RELOC_MEP_PCREL17A2
- -- : BFD_RELOC_MEP_PCREL24A2
- -- : BFD_RELOC_MEP_PCABS24A2
- -- : BFD_RELOC_MEP_LOW16
- -- : BFD_RELOC_MEP_HI16U
- -- : BFD_RELOC_MEP_HI16S
- -- : BFD_RELOC_MEP_GPREL
- -- : BFD_RELOC_MEP_TPREL
- -- : BFD_RELOC_MEP_TPREL7
- -- : BFD_RELOC_MEP_TPREL7A2
- -- : BFD_RELOC_MEP_TPREL7A4
- -- : BFD_RELOC_MEP_UIMM24
- -- : BFD_RELOC_MEP_ADDR24A4
- -- : BFD_RELOC_MEP_GNU_VTINHERIT
- -- : BFD_RELOC_MEP_GNU_VTENTRY
- Toshiba Media Processor Relocations.
-
- -- : BFD_RELOC_MMIX_GETA
- -- : BFD_RELOC_MMIX_GETA_1
- -- : BFD_RELOC_MMIX_GETA_2
- -- : BFD_RELOC_MMIX_GETA_3
- These are relocations for the GETA instruction.
-
- -- : BFD_RELOC_MMIX_CBRANCH
- -- : BFD_RELOC_MMIX_CBRANCH_J
- -- : BFD_RELOC_MMIX_CBRANCH_1
- -- : BFD_RELOC_MMIX_CBRANCH_2
- -- : BFD_RELOC_MMIX_CBRANCH_3
- These are relocations for a conditional branch instruction.
-
- -- : BFD_RELOC_MMIX_PUSHJ
- -- : BFD_RELOC_MMIX_PUSHJ_1
- -- : BFD_RELOC_MMIX_PUSHJ_2
- -- : BFD_RELOC_MMIX_PUSHJ_3
- -- : BFD_RELOC_MMIX_PUSHJ_STUBBABLE
- These are relocations for the PUSHJ instruction.
-
- -- : BFD_RELOC_MMIX_JMP
- -- : BFD_RELOC_MMIX_JMP_1
- -- : BFD_RELOC_MMIX_JMP_2
- -- : BFD_RELOC_MMIX_JMP_3
- These are relocations for the JMP instruction.
-
- -- : BFD_RELOC_MMIX_ADDR19
- This is a relocation for a relative address as in a GETA
- instruction or a branch.
-
- -- : BFD_RELOC_MMIX_ADDR27
- This is a relocation for a relative address as in a JMP
- instruction.
-
- -- : BFD_RELOC_MMIX_REG_OR_BYTE
- This is a relocation for an instruction field that may be a general
- register or a value 0..255.
-
- -- : BFD_RELOC_MMIX_REG
- This is a relocation for an instruction field that may be a general
- register.
-
- -- : BFD_RELOC_MMIX_BASE_PLUS_OFFSET
- This is a relocation for two instruction fields holding a register
- and an offset, the equivalent of the relocation.
-
- -- : BFD_RELOC_MMIX_LOCAL
- This relocation is an assertion that the expression is not
- allocated as a global register. It does not modify contents.
-
- -- : BFD_RELOC_AVR_7_PCREL
- This is a 16 bit reloc for the AVR that stores 8 bit pc relative
- short offset into 7 bits.
-
- -- : BFD_RELOC_AVR_13_PCREL
- This is a 16 bit reloc for the AVR that stores 13 bit pc relative
- short offset into 12 bits.
-
- -- : BFD_RELOC_AVR_16_PM
- This is a 16 bit reloc for the AVR that stores 17 bit value
- (usually program memory address) into 16 bits.
-
- -- : BFD_RELOC_AVR_LO8_LDI
- This is a 16 bit reloc for the AVR that stores 8 bit value (usually
- data memory address) into 8 bit immediate value of LDI insn.
-
- -- : BFD_RELOC_AVR_HI8_LDI
- This is a 16 bit reloc for the AVR that stores 8 bit value (high 8
- bit of data memory address) into 8 bit immediate value of LDI insn.
-
- -- : BFD_RELOC_AVR_HH8_LDI
- This is a 16 bit reloc for the AVR that stores 8 bit value (most
- high 8 bit of program memory address) into 8 bit immediate value
- of LDI insn.
-
- -- : BFD_RELOC_AVR_MS8_LDI
- This is a 16 bit reloc for the AVR that stores 8 bit value (most
- high 8 bit of 32 bit value) into 8 bit immediate value of LDI insn.
-
- -- : BFD_RELOC_AVR_LO8_LDI_NEG
- This is a 16 bit reloc for the AVR that stores negated 8 bit value
- (usually data memory address) into 8 bit immediate value of SUBI
- insn.
-
- -- : BFD_RELOC_AVR_HI8_LDI_NEG
- This is a 16 bit reloc for the AVR that stores negated 8 bit value
- (high 8 bit of data memory address) into 8 bit immediate value of
- SUBI insn.
-
- -- : BFD_RELOC_AVR_HH8_LDI_NEG
- This is a 16 bit reloc for the AVR that stores negated 8 bit value
- (most high 8 bit of program memory address) into 8 bit immediate
- value of LDI or SUBI insn.
-
- -- : BFD_RELOC_AVR_MS8_LDI_NEG
- This is a 16 bit reloc for the AVR that stores negated 8 bit value
- (msb of 32 bit value) into 8 bit immediate value of LDI insn.
-
- -- : BFD_RELOC_AVR_LO8_LDI_PM
- This is a 16 bit reloc for the AVR that stores 8 bit value (usually
- command address) into 8 bit immediate value of LDI insn.
-
- -- : BFD_RELOC_AVR_LO8_LDI_GS
- This is a 16 bit reloc for the AVR that stores 8 bit value
- (command address) into 8 bit immediate value of LDI insn. If the
- address is beyond the 128k boundary, the linker inserts a jump
- stub for this reloc in the lower 128k.
-
- -- : BFD_RELOC_AVR_HI8_LDI_PM
- This is a 16 bit reloc for the AVR that stores 8 bit value (high 8
- bit of command address) into 8 bit immediate value of LDI insn.
-
- -- : BFD_RELOC_AVR_HI8_LDI_GS
- This is a 16 bit reloc for the AVR that stores 8 bit value (high 8
- bit of command address) into 8 bit immediate value of LDI insn.
- If the address is beyond the 128k boundary, the linker inserts a
- jump stub for this reloc below 128k.
-
- -- : BFD_RELOC_AVR_HH8_LDI_PM
- This is a 16 bit reloc for the AVR that stores 8 bit value (most
- high 8 bit of command address) into 8 bit immediate value of LDI
- insn.
-
- -- : BFD_RELOC_AVR_LO8_LDI_PM_NEG
- This is a 16 bit reloc for the AVR that stores negated 8 bit value
- (usually command address) into 8 bit immediate value of SUBI insn.
-
- -- : BFD_RELOC_AVR_HI8_LDI_PM_NEG
- This is a 16 bit reloc for the AVR that stores negated 8 bit value
- (high 8 bit of 16 bit command address) into 8 bit immediate value
- of SUBI insn.
-
- -- : BFD_RELOC_AVR_HH8_LDI_PM_NEG
- This is a 16 bit reloc for the AVR that stores negated 8 bit value
- (high 6 bit of 22 bit command address) into 8 bit immediate value
- of SUBI insn.
-
- -- : BFD_RELOC_AVR_CALL
- This is a 32 bit reloc for the AVR that stores 23 bit value into
- 22 bits.
-
- -- : BFD_RELOC_AVR_LDI
- This is a 16 bit reloc for the AVR that stores all needed bits for
- absolute addressing with ldi with overflow check to linktime
-
- -- : BFD_RELOC_AVR_6
- This is a 6 bit reloc for the AVR that stores offset for ldd/std
- instructions
-
- -- : BFD_RELOC_AVR_6_ADIW
- This is a 6 bit reloc for the AVR that stores offset for adiw/sbiw
- instructions
-
- -- : BFD_RELOC_RX_NEG8
- -- : BFD_RELOC_RX_NEG16
- -- : BFD_RELOC_RX_NEG24
- -- : BFD_RELOC_RX_NEG32
- -- : BFD_RELOC_RX_16_OP
- -- : BFD_RELOC_RX_24_OP
- -- : BFD_RELOC_RX_32_OP
- -- : BFD_RELOC_RX_8U
- -- : BFD_RELOC_RX_16U
- -- : BFD_RELOC_RX_24U
- -- : BFD_RELOC_RX_DIR3U_PCREL
- -- : BFD_RELOC_RX_DIFF
- -- : BFD_RELOC_RX_GPRELB
- -- : BFD_RELOC_RX_GPRELW
- -- : BFD_RELOC_RX_GPRELL
- -- : BFD_RELOC_RX_SYM
- -- : BFD_RELOC_RX_OP_SUBTRACT
- -- : BFD_RELOC_RX_OP_NEG
- -- : BFD_RELOC_RX_ABS8
- -- : BFD_RELOC_RX_ABS16
- -- : BFD_RELOC_RX_ABS16_REV
- -- : BFD_RELOC_RX_ABS32
- -- : BFD_RELOC_RX_ABS32_REV
- -- : BFD_RELOC_RX_ABS16U
- -- : BFD_RELOC_RX_ABS16UW
- -- : BFD_RELOC_RX_ABS16UL
- -- : BFD_RELOC_RX_RELAX
- Renesas RX Relocations.
-
- -- : BFD_RELOC_390_12
- Direct 12 bit.
-
- -- : BFD_RELOC_390_GOT12
- 12 bit GOT offset.
-
- -- : BFD_RELOC_390_PLT32
- 32 bit PC relative PLT address.
-
- -- : BFD_RELOC_390_COPY
- Copy symbol at runtime.
-
- -- : BFD_RELOC_390_GLOB_DAT
- Create GOT entry.
-
- -- : BFD_RELOC_390_JMP_SLOT
- Create PLT entry.
-
- -- : BFD_RELOC_390_RELATIVE
- Adjust by program base.
-
- -- : BFD_RELOC_390_GOTPC
- 32 bit PC relative offset to GOT.
-
- -- : BFD_RELOC_390_GOT16
- 16 bit GOT offset.
-
- -- : BFD_RELOC_390_PC16DBL
- PC relative 16 bit shifted by 1.
-
- -- : BFD_RELOC_390_PLT16DBL
- 16 bit PC rel. PLT shifted by 1.
-
- -- : BFD_RELOC_390_PC32DBL
- PC relative 32 bit shifted by 1.
-
- -- : BFD_RELOC_390_PLT32DBL
- 32 bit PC rel. PLT shifted by 1.
-
- -- : BFD_RELOC_390_GOTPCDBL
- 32 bit PC rel. GOT shifted by 1.
-
- -- : BFD_RELOC_390_GOT64
- 64 bit GOT offset.
-
- -- : BFD_RELOC_390_PLT64
- 64 bit PC relative PLT address.
-
- -- : BFD_RELOC_390_GOTENT
- 32 bit rel. offset to GOT entry.
-
- -- : BFD_RELOC_390_GOTOFF64
- 64 bit offset to GOT.
-
- -- : BFD_RELOC_390_GOTPLT12
- 12-bit offset to symbol-entry within GOT, with PLT handling.
-
- -- : BFD_RELOC_390_GOTPLT16
- 16-bit offset to symbol-entry within GOT, with PLT handling.
-
- -- : BFD_RELOC_390_GOTPLT32
- 32-bit offset to symbol-entry within GOT, with PLT handling.
-
- -- : BFD_RELOC_390_GOTPLT64
- 64-bit offset to symbol-entry within GOT, with PLT handling.
-
- -- : BFD_RELOC_390_GOTPLTENT
- 32-bit rel. offset to symbol-entry within GOT, with PLT handling.
-
- -- : BFD_RELOC_390_PLTOFF16
- 16-bit rel. offset from the GOT to a PLT entry.
-
- -- : BFD_RELOC_390_PLTOFF32
- 32-bit rel. offset from the GOT to a PLT entry.
-
- -- : BFD_RELOC_390_PLTOFF64
- 64-bit rel. offset from the GOT to a PLT entry.
-
- -- : BFD_RELOC_390_TLS_LOAD
- -- : BFD_RELOC_390_TLS_GDCALL
- -- : BFD_RELOC_390_TLS_LDCALL
- -- : BFD_RELOC_390_TLS_GD32
- -- : BFD_RELOC_390_TLS_GD64
- -- : BFD_RELOC_390_TLS_GOTIE12
- -- : BFD_RELOC_390_TLS_GOTIE32
- -- : BFD_RELOC_390_TLS_GOTIE64
- -- : BFD_RELOC_390_TLS_LDM32
- -- : BFD_RELOC_390_TLS_LDM64
- -- : BFD_RELOC_390_TLS_IE32
- -- : BFD_RELOC_390_TLS_IE64
- -- : BFD_RELOC_390_TLS_IEENT
- -- : BFD_RELOC_390_TLS_LE32
- -- : BFD_RELOC_390_TLS_LE64
- -- : BFD_RELOC_390_TLS_LDO32
- -- : BFD_RELOC_390_TLS_LDO64
- -- : BFD_RELOC_390_TLS_DTPMOD
- -- : BFD_RELOC_390_TLS_DTPOFF
- -- : BFD_RELOC_390_TLS_TPOFF
- s390 tls relocations.
-
- -- : BFD_RELOC_390_20
- -- : BFD_RELOC_390_GOT20
- -- : BFD_RELOC_390_GOTPLT20
- -- : BFD_RELOC_390_TLS_GOTIE20
- Long displacement extension.
-
- -- : BFD_RELOC_SCORE_GPREL15
- Score relocations Low 16 bit for load/store
-
- -- : BFD_RELOC_SCORE_DUMMY2
- -- : BFD_RELOC_SCORE_JMP
- This is a 24-bit reloc with the right 1 bit assumed to be 0
-
- -- : BFD_RELOC_SCORE_BRANCH
- This is a 19-bit reloc with the right 1 bit assumed to be 0
-
- -- : BFD_RELOC_SCORE_IMM30
- This is a 32-bit reloc for 48-bit instructions.
-
- -- : BFD_RELOC_SCORE_IMM32
- This is a 32-bit reloc for 48-bit instructions.
-
- -- : BFD_RELOC_SCORE16_JMP
- This is a 11-bit reloc with the right 1 bit assumed to be 0
-
- -- : BFD_RELOC_SCORE16_BRANCH
- This is a 8-bit reloc with the right 1 bit assumed to be 0
-
- -- : BFD_RELOC_SCORE_BCMP
- This is a 9-bit reloc with the right 1 bit assumed to be 0
-
- -- : BFD_RELOC_SCORE_GOT15
- -- : BFD_RELOC_SCORE_GOT_LO16
- -- : BFD_RELOC_SCORE_CALL15
- -- : BFD_RELOC_SCORE_DUMMY_HI16
- Undocumented Score relocs
-
- -- : BFD_RELOC_IP2K_FR9
- Scenix IP2K - 9-bit register number / data address
-
- -- : BFD_RELOC_IP2K_BANK
- Scenix IP2K - 4-bit register/data bank number
-
- -- : BFD_RELOC_IP2K_ADDR16CJP
- Scenix IP2K - low 13 bits of instruction word address
-
- -- : BFD_RELOC_IP2K_PAGE3
- Scenix IP2K - high 3 bits of instruction word address
-
- -- : BFD_RELOC_IP2K_LO8DATA
- -- : BFD_RELOC_IP2K_HI8DATA
- -- : BFD_RELOC_IP2K_EX8DATA
- Scenix IP2K - ext/low/high 8 bits of data address
-
- -- : BFD_RELOC_IP2K_LO8INSN
- -- : BFD_RELOC_IP2K_HI8INSN
- Scenix IP2K - low/high 8 bits of instruction word address
-
- -- : BFD_RELOC_IP2K_PC_SKIP
- Scenix IP2K - even/odd PC modifier to modify snb pcl.0
-
- -- : BFD_RELOC_IP2K_TEXT
- Scenix IP2K - 16 bit word address in text section.
-
- -- : BFD_RELOC_IP2K_FR_OFFSET
- Scenix IP2K - 7-bit sp or dp offset
-
- -- : BFD_RELOC_VPE4KMATH_DATA
- -- : BFD_RELOC_VPE4KMATH_INSN
- Scenix VPE4K coprocessor - data/insn-space addressing
-
- -- : BFD_RELOC_VTABLE_INHERIT
- -- : BFD_RELOC_VTABLE_ENTRY
- These two relocations are used by the linker to determine which of
- the entries in a C++ virtual function table are actually used.
- When the -gc-sections option is given, the linker will zero out
- the entries that are not used, so that the code for those
- functions need not be included in the output.
-
- VTABLE_INHERIT is a zero-space relocation used to describe to the
- linker the inheritance tree of a C++ virtual function table. The
- relocation's symbol should be the parent class' vtable, and the
- relocation should be located at the child vtable.
-
- VTABLE_ENTRY is a zero-space relocation that describes the use of a
- virtual function table entry. The reloc's symbol should refer to
- the table of the class mentioned in the code. Off of that base,
- an offset describes the entry that is being used. For Rela hosts,
- this offset is stored in the reloc's addend. For Rel hosts, we
- are forced to put this offset in the reloc's section offset.
-
- -- : BFD_RELOC_IA64_IMM14
- -- : BFD_RELOC_IA64_IMM22
- -- : BFD_RELOC_IA64_IMM64
- -- : BFD_RELOC_IA64_DIR32MSB
- -- : BFD_RELOC_IA64_DIR32LSB
- -- : BFD_RELOC_IA64_DIR64MSB
- -- : BFD_RELOC_IA64_DIR64LSB
- -- : BFD_RELOC_IA64_GPREL22
- -- : BFD_RELOC_IA64_GPREL64I
- -- : BFD_RELOC_IA64_GPREL32MSB
- -- : BFD_RELOC_IA64_GPREL32LSB
- -- : BFD_RELOC_IA64_GPREL64MSB
- -- : BFD_RELOC_IA64_GPREL64LSB
- -- : BFD_RELOC_IA64_LTOFF22
- -- : BFD_RELOC_IA64_LTOFF64I
- -- : BFD_RELOC_IA64_PLTOFF22
- -- : BFD_RELOC_IA64_PLTOFF64I
- -- : BFD_RELOC_IA64_PLTOFF64MSB
- -- : BFD_RELOC_IA64_PLTOFF64LSB
- -- : BFD_RELOC_IA64_FPTR64I
- -- : BFD_RELOC_IA64_FPTR32MSB
- -- : BFD_RELOC_IA64_FPTR32LSB
- -- : BFD_RELOC_IA64_FPTR64MSB
- -- : BFD_RELOC_IA64_FPTR64LSB
- -- : BFD_RELOC_IA64_PCREL21B
- -- : BFD_RELOC_IA64_PCREL21BI
- -- : BFD_RELOC_IA64_PCREL21M
- -- : BFD_RELOC_IA64_PCREL21F
- -- : BFD_RELOC_IA64_PCREL22
- -- : BFD_RELOC_IA64_PCREL60B
- -- : BFD_RELOC_IA64_PCREL64I
- -- : BFD_RELOC_IA64_PCREL32MSB
- -- : BFD_RELOC_IA64_PCREL32LSB
- -- : BFD_RELOC_IA64_PCREL64MSB
- -- : BFD_RELOC_IA64_PCREL64LSB
- -- : BFD_RELOC_IA64_LTOFF_FPTR22
- -- : BFD_RELOC_IA64_LTOFF_FPTR64I
- -- : BFD_RELOC_IA64_LTOFF_FPTR32MSB
- -- : BFD_RELOC_IA64_LTOFF_FPTR32LSB
- -- : BFD_RELOC_IA64_LTOFF_FPTR64MSB
- -- : BFD_RELOC_IA64_LTOFF_FPTR64LSB
- -- : BFD_RELOC_IA64_SEGREL32MSB
- -- : BFD_RELOC_IA64_SEGREL32LSB
- -- : BFD_RELOC_IA64_SEGREL64MSB
- -- : BFD_RELOC_IA64_SEGREL64LSB
- -- : BFD_RELOC_IA64_SECREL32MSB
- -- : BFD_RELOC_IA64_SECREL32LSB
- -- : BFD_RELOC_IA64_SECREL64MSB
- -- : BFD_RELOC_IA64_SECREL64LSB
- -- : BFD_RELOC_IA64_REL32MSB
- -- : BFD_RELOC_IA64_REL32LSB
- -- : BFD_RELOC_IA64_REL64MSB
- -- : BFD_RELOC_IA64_REL64LSB
- -- : BFD_RELOC_IA64_LTV32MSB
- -- : BFD_RELOC_IA64_LTV32LSB
- -- : BFD_RELOC_IA64_LTV64MSB
- -- : BFD_RELOC_IA64_LTV64LSB
- -- : BFD_RELOC_IA64_IPLTMSB
- -- : BFD_RELOC_IA64_IPLTLSB
- -- : BFD_RELOC_IA64_COPY
- -- : BFD_RELOC_IA64_LTOFF22X
- -- : BFD_RELOC_IA64_LDXMOV
- -- : BFD_RELOC_IA64_TPREL14
- -- : BFD_RELOC_IA64_TPREL22
- -- : BFD_RELOC_IA64_TPREL64I
- -- : BFD_RELOC_IA64_TPREL64MSB
- -- : BFD_RELOC_IA64_TPREL64LSB
- -- : BFD_RELOC_IA64_LTOFF_TPREL22
- -- : BFD_RELOC_IA64_DTPMOD64MSB
- -- : BFD_RELOC_IA64_DTPMOD64LSB
- -- : BFD_RELOC_IA64_LTOFF_DTPMOD22
- -- : BFD_RELOC_IA64_DTPREL14
- -- : BFD_RELOC_IA64_DTPREL22
- -- : BFD_RELOC_IA64_DTPREL64I
- -- : BFD_RELOC_IA64_DTPREL32MSB
- -- : BFD_RELOC_IA64_DTPREL32LSB
- -- : BFD_RELOC_IA64_DTPREL64MSB
- -- : BFD_RELOC_IA64_DTPREL64LSB
- -- : BFD_RELOC_IA64_LTOFF_DTPREL22
- Intel IA64 Relocations.
-
- -- : BFD_RELOC_M68HC11_HI8
- Motorola 68HC11 reloc. This is the 8 bit high part of an absolute
- address.
-
- -- : BFD_RELOC_M68HC11_LO8
- Motorola 68HC11 reloc. This is the 8 bit low part of an absolute
- address.
-
- -- : BFD_RELOC_M68HC11_3B
- Motorola 68HC11 reloc. This is the 3 bit of a value.
-
- -- : BFD_RELOC_M68HC11_RL_JUMP
- Motorola 68HC11 reloc. This reloc marks the beginning of a
- jump/call instruction. It is used for linker relaxation to
- correctly identify beginning of instruction and change some
- branches to use PC-relative addressing mode.
-
- -- : BFD_RELOC_M68HC11_RL_GROUP
- Motorola 68HC11 reloc. This reloc marks a group of several
- instructions that gcc generates and for which the linker
- relaxation pass can modify and/or remove some of them.
-
- -- : BFD_RELOC_M68HC11_LO16
- Motorola 68HC11 reloc. This is the 16-bit lower part of an
- address. It is used for 'call' instruction to specify the symbol
- address without any special transformation (due to memory bank
- window).
-
- -- : BFD_RELOC_M68HC11_PAGE
- Motorola 68HC11 reloc. This is a 8-bit reloc that specifies the
- page number of an address. It is used by 'call' instruction to
- specify the page number of the symbol.
-
- -- : BFD_RELOC_M68HC11_24
- Motorola 68HC11 reloc. This is a 24-bit reloc that represents the
- address with a 16-bit value and a 8-bit page number. The symbol
- address is transformed to follow the 16K memory bank of 68HC12
- (seen as mapped in the window).
-
- -- : BFD_RELOC_M68HC12_5B
- Motorola 68HC12 reloc. This is the 5 bits of a value.
-
- -- : BFD_RELOC_16C_NUM08
- -- : BFD_RELOC_16C_NUM08_C
- -- : BFD_RELOC_16C_NUM16
- -- : BFD_RELOC_16C_NUM16_C
- -- : BFD_RELOC_16C_NUM32
- -- : BFD_RELOC_16C_NUM32_C
- -- : BFD_RELOC_16C_DISP04
- -- : BFD_RELOC_16C_DISP04_C
- -- : BFD_RELOC_16C_DISP08
- -- : BFD_RELOC_16C_DISP08_C
- -- : BFD_RELOC_16C_DISP16
- -- : BFD_RELOC_16C_DISP16_C
- -- : BFD_RELOC_16C_DISP24
- -- : BFD_RELOC_16C_DISP24_C
- -- : BFD_RELOC_16C_DISP24a
- -- : BFD_RELOC_16C_DISP24a_C
- -- : BFD_RELOC_16C_REG04
- -- : BFD_RELOC_16C_REG04_C
- -- : BFD_RELOC_16C_REG04a
- -- : BFD_RELOC_16C_REG04a_C
- -- : BFD_RELOC_16C_REG14
- -- : BFD_RELOC_16C_REG14_C
- -- : BFD_RELOC_16C_REG16
- -- : BFD_RELOC_16C_REG16_C
- -- : BFD_RELOC_16C_REG20
- -- : BFD_RELOC_16C_REG20_C
- -- : BFD_RELOC_16C_ABS20
- -- : BFD_RELOC_16C_ABS20_C
- -- : BFD_RELOC_16C_ABS24
- -- : BFD_RELOC_16C_ABS24_C
- -- : BFD_RELOC_16C_IMM04
- -- : BFD_RELOC_16C_IMM04_C
- -- : BFD_RELOC_16C_IMM16
- -- : BFD_RELOC_16C_IMM16_C
- -- : BFD_RELOC_16C_IMM20
- -- : BFD_RELOC_16C_IMM20_C
- -- : BFD_RELOC_16C_IMM24
- -- : BFD_RELOC_16C_IMM24_C
- -- : BFD_RELOC_16C_IMM32
- -- : BFD_RELOC_16C_IMM32_C
- NS CR16C Relocations.
-
- -- : BFD_RELOC_CR16_NUM8
- -- : BFD_RELOC_CR16_NUM16
- -- : BFD_RELOC_CR16_NUM32
- -- : BFD_RELOC_CR16_NUM32a
- -- : BFD_RELOC_CR16_REGREL0
- -- : BFD_RELOC_CR16_REGREL4
- -- : BFD_RELOC_CR16_REGREL4a
- -- : BFD_RELOC_CR16_REGREL14
- -- : BFD_RELOC_CR16_REGREL14a
- -- : BFD_RELOC_CR16_REGREL16
- -- : BFD_RELOC_CR16_REGREL20
- -- : BFD_RELOC_CR16_REGREL20a
- -- : BFD_RELOC_CR16_ABS20
- -- : BFD_RELOC_CR16_ABS24
- -- : BFD_RELOC_CR16_IMM4
- -- : BFD_RELOC_CR16_IMM8
- -- : BFD_RELOC_CR16_IMM16
- -- : BFD_RELOC_CR16_IMM20
- -- : BFD_RELOC_CR16_IMM24
- -- : BFD_RELOC_CR16_IMM32
- -- : BFD_RELOC_CR16_IMM32a
- -- : BFD_RELOC_CR16_DISP4
- -- : BFD_RELOC_CR16_DISP8
- -- : BFD_RELOC_CR16_DISP16
- -- : BFD_RELOC_CR16_DISP20
- -- : BFD_RELOC_CR16_DISP24
- -- : BFD_RELOC_CR16_DISP24a
- -- : BFD_RELOC_CR16_SWITCH8
- -- : BFD_RELOC_CR16_SWITCH16
- -- : BFD_RELOC_CR16_SWITCH32
- -- : BFD_RELOC_CR16_GOT_REGREL20
- -- : BFD_RELOC_CR16_GOTC_REGREL20
- -- : BFD_RELOC_CR16_GLOB_DAT
- NS CR16 Relocations.
-
- -- : BFD_RELOC_CRX_REL4
- -- : BFD_RELOC_CRX_REL8
- -- : BFD_RELOC_CRX_REL8_CMP
- -- : BFD_RELOC_CRX_REL16
- -- : BFD_RELOC_CRX_REL24
- -- : BFD_RELOC_CRX_REL32
- -- : BFD_RELOC_CRX_REGREL12
- -- : BFD_RELOC_CRX_REGREL22
- -- : BFD_RELOC_CRX_REGREL28
- -- : BFD_RELOC_CRX_REGREL32
- -- : BFD_RELOC_CRX_ABS16
- -- : BFD_RELOC_CRX_ABS32
- -- : BFD_RELOC_CRX_NUM8
- -- : BFD_RELOC_CRX_NUM16
- -- : BFD_RELOC_CRX_NUM32
- -- : BFD_RELOC_CRX_IMM16
- -- : BFD_RELOC_CRX_IMM32
- -- : BFD_RELOC_CRX_SWITCH8
- -- : BFD_RELOC_CRX_SWITCH16
- -- : BFD_RELOC_CRX_SWITCH32
- NS CRX Relocations.
-
- -- : BFD_RELOC_CRIS_BDISP8
- -- : BFD_RELOC_CRIS_UNSIGNED_5
- -- : BFD_RELOC_CRIS_SIGNED_6
- -- : BFD_RELOC_CRIS_UNSIGNED_6
- -- : BFD_RELOC_CRIS_SIGNED_8
- -- : BFD_RELOC_CRIS_UNSIGNED_8
- -- : BFD_RELOC_CRIS_SIGNED_16
- -- : BFD_RELOC_CRIS_UNSIGNED_16
- -- : BFD_RELOC_CRIS_LAPCQ_OFFSET
- -- : BFD_RELOC_CRIS_UNSIGNED_4
- These relocs are only used within the CRIS assembler. They are not
- (at present) written to any object files.
-
- -- : BFD_RELOC_CRIS_COPY
- -- : BFD_RELOC_CRIS_GLOB_DAT
- -- : BFD_RELOC_CRIS_JUMP_SLOT
- -- : BFD_RELOC_CRIS_RELATIVE
- Relocs used in ELF shared libraries for CRIS.
-
- -- : BFD_RELOC_CRIS_32_GOT
- 32-bit offset to symbol-entry within GOT.
-
- -- : BFD_RELOC_CRIS_16_GOT
- 16-bit offset to symbol-entry within GOT.
-
- -- : BFD_RELOC_CRIS_32_GOTPLT
- 32-bit offset to symbol-entry within GOT, with PLT handling.
-
- -- : BFD_RELOC_CRIS_16_GOTPLT
- 16-bit offset to symbol-entry within GOT, with PLT handling.
-
- -- : BFD_RELOC_CRIS_32_GOTREL
- 32-bit offset to symbol, relative to GOT.
-
- -- : BFD_RELOC_CRIS_32_PLT_GOTREL
- 32-bit offset to symbol with PLT entry, relative to GOT.
-
- -- : BFD_RELOC_CRIS_32_PLT_PCREL
- 32-bit offset to symbol with PLT entry, relative to this
- relocation.
-
- -- : BFD_RELOC_CRIS_32_GOT_GD
- -- : BFD_RELOC_CRIS_16_GOT_GD
- -- : BFD_RELOC_CRIS_32_GD
- -- : BFD_RELOC_CRIS_DTP
- -- : BFD_RELOC_CRIS_32_DTPREL
- -- : BFD_RELOC_CRIS_16_DTPREL
- -- : BFD_RELOC_CRIS_32_GOT_TPREL
- -- : BFD_RELOC_CRIS_16_GOT_TPREL
- -- : BFD_RELOC_CRIS_32_TPREL
- -- : BFD_RELOC_CRIS_16_TPREL
- -- : BFD_RELOC_CRIS_DTPMOD
- -- : BFD_RELOC_CRIS_32_IE
- Relocs used in TLS code for CRIS.
-
- -- : BFD_RELOC_860_COPY
- -- : BFD_RELOC_860_GLOB_DAT
- -- : BFD_RELOC_860_JUMP_SLOT
- -- : BFD_RELOC_860_RELATIVE
- -- : BFD_RELOC_860_PC26
- -- : BFD_RELOC_860_PLT26
- -- : BFD_RELOC_860_PC16
- -- : BFD_RELOC_860_LOW0
- -- : BFD_RELOC_860_SPLIT0
- -- : BFD_RELOC_860_LOW1
- -- : BFD_RELOC_860_SPLIT1
- -- : BFD_RELOC_860_LOW2
- -- : BFD_RELOC_860_SPLIT2
- -- : BFD_RELOC_860_LOW3
- -- : BFD_RELOC_860_LOGOT0
- -- : BFD_RELOC_860_SPGOT0
- -- : BFD_RELOC_860_LOGOT1
- -- : BFD_RELOC_860_SPGOT1
- -- : BFD_RELOC_860_LOGOTOFF0
- -- : BFD_RELOC_860_SPGOTOFF0
- -- : BFD_RELOC_860_LOGOTOFF1
- -- : BFD_RELOC_860_SPGOTOFF1
- -- : BFD_RELOC_860_LOGOTOFF2
- -- : BFD_RELOC_860_LOGOTOFF3
- -- : BFD_RELOC_860_LOPC
- -- : BFD_RELOC_860_HIGHADJ
- -- : BFD_RELOC_860_HAGOT
- -- : BFD_RELOC_860_HAGOTOFF
- -- : BFD_RELOC_860_HAPC
- -- : BFD_RELOC_860_HIGH
- -- : BFD_RELOC_860_HIGOT
- -- : BFD_RELOC_860_HIGOTOFF
- Intel i860 Relocations.
-
- -- : BFD_RELOC_OPENRISC_ABS_26
- -- : BFD_RELOC_OPENRISC_REL_26
- OpenRISC Relocations.
-
- -- : BFD_RELOC_H8_DIR16A8
- -- : BFD_RELOC_H8_DIR16R8
- -- : BFD_RELOC_H8_DIR24A8
- -- : BFD_RELOC_H8_DIR24R8
- -- : BFD_RELOC_H8_DIR32A16
- H8 elf Relocations.
-
- -- : BFD_RELOC_XSTORMY16_REL_12
- -- : BFD_RELOC_XSTORMY16_12
- -- : BFD_RELOC_XSTORMY16_24
- -- : BFD_RELOC_XSTORMY16_FPTR16
- Sony Xstormy16 Relocations.
-
- -- : BFD_RELOC_RELC
- Self-describing complex relocations.
-
- -- : BFD_RELOC_XC16X_PAG
- -- : BFD_RELOC_XC16X_POF
- -- : BFD_RELOC_XC16X_SEG
- -- : BFD_RELOC_XC16X_SOF
- Infineon Relocations.
-
- -- : BFD_RELOC_VAX_GLOB_DAT
- -- : BFD_RELOC_VAX_JMP_SLOT
- -- : BFD_RELOC_VAX_RELATIVE
- Relocations used by VAX ELF.
-
- -- : BFD_RELOC_MT_PC16
- Morpho MT - 16 bit immediate relocation.
-
- -- : BFD_RELOC_MT_HI16
- Morpho MT - Hi 16 bits of an address.
-
- -- : BFD_RELOC_MT_LO16
- Morpho MT - Low 16 bits of an address.
-
- -- : BFD_RELOC_MT_GNU_VTINHERIT
- Morpho MT - Used to tell the linker which vtable entries are used.
-
- -- : BFD_RELOC_MT_GNU_VTENTRY
- Morpho MT - Used to tell the linker which vtable entries are used.
-
- -- : BFD_RELOC_MT_PCINSN8
- Morpho MT - 8 bit immediate relocation.
-
- -- : BFD_RELOC_MSP430_10_PCREL
- -- : BFD_RELOC_MSP430_16_PCREL
- -- : BFD_RELOC_MSP430_16
- -- : BFD_RELOC_MSP430_16_PCREL_BYTE
- -- : BFD_RELOC_MSP430_16_BYTE
- -- : BFD_RELOC_MSP430_2X_PCREL
- -- : BFD_RELOC_MSP430_RL_PCREL
- msp430 specific relocation codes
-
- -- : BFD_RELOC_IQ2000_OFFSET_16
- -- : BFD_RELOC_IQ2000_OFFSET_21
- -- : BFD_RELOC_IQ2000_UHI16
- IQ2000 Relocations.
-
- -- : BFD_RELOC_XTENSA_RTLD
- Special Xtensa relocation used only by PLT entries in ELF shared
- objects to indicate that the runtime linker should set the value
- to one of its own internal functions or data structures.
-
- -- : BFD_RELOC_XTENSA_GLOB_DAT
- -- : BFD_RELOC_XTENSA_JMP_SLOT
- -- : BFD_RELOC_XTENSA_RELATIVE
- Xtensa relocations for ELF shared objects.
-
- -- : BFD_RELOC_XTENSA_PLT
- Xtensa relocation used in ELF object files for symbols that may
- require PLT entries. Otherwise, this is just a generic 32-bit
- relocation.
-
- -- : BFD_RELOC_XTENSA_DIFF8
- -- : BFD_RELOC_XTENSA_DIFF16
- -- : BFD_RELOC_XTENSA_DIFF32
- Xtensa relocations to mark the difference of two local symbols.
- These are only needed to support linker relaxation and can be
- ignored when not relaxing. The field is set to the value of the
- difference assuming no relaxation. The relocation encodes the
- position of the first symbol so the linker can determine whether
- to adjust the field value.
-
- -- : BFD_RELOC_XTENSA_SLOT0_OP
- -- : BFD_RELOC_XTENSA_SLOT1_OP
- -- : BFD_RELOC_XTENSA_SLOT2_OP
- -- : BFD_RELOC_XTENSA_SLOT3_OP
- -- : BFD_RELOC_XTENSA_SLOT4_OP
- -- : BFD_RELOC_XTENSA_SLOT5_OP
- -- : BFD_RELOC_XTENSA_SLOT6_OP
- -- : BFD_RELOC_XTENSA_SLOT7_OP
- -- : BFD_RELOC_XTENSA_SLOT8_OP
- -- : BFD_RELOC_XTENSA_SLOT9_OP
- -- : BFD_RELOC_XTENSA_SLOT10_OP
- -- : BFD_RELOC_XTENSA_SLOT11_OP
- -- : BFD_RELOC_XTENSA_SLOT12_OP
- -- : BFD_RELOC_XTENSA_SLOT13_OP
- -- : BFD_RELOC_XTENSA_SLOT14_OP
- Generic Xtensa relocations for instruction operands. Only the slot
- number is encoded in the relocation. The relocation applies to the
- last PC-relative immediate operand, or if there are no PC-relative
- immediates, to the last immediate operand.
-
- -- : BFD_RELOC_XTENSA_SLOT0_ALT
- -- : BFD_RELOC_XTENSA_SLOT1_ALT
- -- : BFD_RELOC_XTENSA_SLOT2_ALT
- -- : BFD_RELOC_XTENSA_SLOT3_ALT
- -- : BFD_RELOC_XTENSA_SLOT4_ALT
- -- : BFD_RELOC_XTENSA_SLOT5_ALT
- -- : BFD_RELOC_XTENSA_SLOT6_ALT
- -- : BFD_RELOC_XTENSA_SLOT7_ALT
- -- : BFD_RELOC_XTENSA_SLOT8_ALT
- -- : BFD_RELOC_XTENSA_SLOT9_ALT
- -- : BFD_RELOC_XTENSA_SLOT10_ALT
- -- : BFD_RELOC_XTENSA_SLOT11_ALT
- -- : BFD_RELOC_XTENSA_SLOT12_ALT
- -- : BFD_RELOC_XTENSA_SLOT13_ALT
- -- : BFD_RELOC_XTENSA_SLOT14_ALT
- Alternate Xtensa relocations. Only the slot is encoded in the
- relocation. The meaning of these relocations is opcode-specific.
-
- -- : BFD_RELOC_XTENSA_OP0
- -- : BFD_RELOC_XTENSA_OP1
- -- : BFD_RELOC_XTENSA_OP2
- Xtensa relocations for backward compatibility. These have all been
- replaced by BFD_RELOC_XTENSA_SLOT0_OP.
-
- -- : BFD_RELOC_XTENSA_ASM_EXPAND
- Xtensa relocation to mark that the assembler expanded the
- instructions from an original target. The expansion size is
- encoded in the reloc size.
-
- -- : BFD_RELOC_XTENSA_ASM_SIMPLIFY
- Xtensa relocation to mark that the linker should simplify
- assembler-expanded instructions. This is commonly used internally
- by the linker after analysis of a BFD_RELOC_XTENSA_ASM_EXPAND.
-
- -- : BFD_RELOC_XTENSA_TLSDESC_FN
- -- : BFD_RELOC_XTENSA_TLSDESC_ARG
- -- : BFD_RELOC_XTENSA_TLS_DTPOFF
- -- : BFD_RELOC_XTENSA_TLS_TPOFF
- -- : BFD_RELOC_XTENSA_TLS_FUNC
- -- : BFD_RELOC_XTENSA_TLS_ARG
- -- : BFD_RELOC_XTENSA_TLS_CALL
- Xtensa TLS relocations.
-
- -- : BFD_RELOC_Z80_DISP8
- 8 bit signed offset in (ix+d) or (iy+d).
-
- -- : BFD_RELOC_Z8K_DISP7
- DJNZ offset.
-
- -- : BFD_RELOC_Z8K_CALLR
- CALR offset.
-
- -- : BFD_RELOC_Z8K_IMM4L
- 4 bit value.
-
- -- : BFD_RELOC_LM32_CALL
- -- : BFD_RELOC_LM32_BRANCH
- -- : BFD_RELOC_LM32_16_GOT
- -- : BFD_RELOC_LM32_GOTOFF_HI16
- -- : BFD_RELOC_LM32_GOTOFF_LO16
- -- : BFD_RELOC_LM32_COPY
- -- : BFD_RELOC_LM32_GLOB_DAT
- -- : BFD_RELOC_LM32_JMP_SLOT
- -- : BFD_RELOC_LM32_RELATIVE
- Lattice Mico32 relocations.
-
- -- : BFD_RELOC_MACH_O_SECTDIFF
- Difference between two section addreses. Must be followed by a
- BFD_RELOC_MACH_O_PAIR.
-
- -- : BFD_RELOC_MACH_O_PAIR
- Pair of relocation. Contains the first symbol.
-
- -- : BFD_RELOC_MACH_O_X86_64_BRANCH32
- -- : BFD_RELOC_MACH_O_X86_64_BRANCH8
- PCREL relocations. They are marked as branch to create PLT entry
- if required.
-
- -- : BFD_RELOC_MACH_O_X86_64_GOT
- Used when referencing a GOT entry.
-
- -- : BFD_RELOC_MACH_O_X86_64_GOT_LOAD
- Used when loading a GOT entry with movq. It is specially marked
- so that the linker could optimize the movq to a leaq if possible.
-
- -- : BFD_RELOC_MACH_O_X86_64_SUBTRACTOR32
- Symbol will be substracted. Must be followed by a BFD_RELOC_64.
-
- -- : BFD_RELOC_MACH_O_X86_64_SUBTRACTOR64
- Symbol will be substracted. Must be followed by a BFD_RELOC_64.
-
- -- : BFD_RELOC_MACH_O_X86_64_PCREL32_1
- Same as BFD_RELOC_32_PCREL but with an implicit -1 addend.
-
- -- : BFD_RELOC_MACH_O_X86_64_PCREL32_2
- Same as BFD_RELOC_32_PCREL but with an implicit -2 addend.
-
- -- : BFD_RELOC_MACH_O_X86_64_PCREL32_4
- Same as BFD_RELOC_32_PCREL but with an implicit -4 addend.
-
- -- : BFD_RELOC_MICROBLAZE_32_LO
- This is a 32 bit reloc for the microblaze that stores the low 16
- bits of a value
-
- -- : BFD_RELOC_MICROBLAZE_32_LO_PCREL
- This is a 32 bit pc-relative reloc for the microblaze that stores
- the low 16 bits of a value
-
- -- : BFD_RELOC_MICROBLAZE_32_ROSDA
- This is a 32 bit reloc for the microblaze that stores a value
- relative to the read-only small data area anchor
-
- -- : BFD_RELOC_MICROBLAZE_32_RWSDA
- This is a 32 bit reloc for the microblaze that stores a value
- relative to the read-write small data area anchor
-
- -- : BFD_RELOC_MICROBLAZE_32_SYM_OP_SYM
- This is a 32 bit reloc for the microblaze to handle expressions of
- the form "Symbol Op Symbol"
-
- -- : BFD_RELOC_MICROBLAZE_64_NONE
- This is a 64 bit reloc that stores the 32 bit pc relative value in
- two words (with an imm instruction). No relocation is done here -
- only used for relaxing
-
- -- : BFD_RELOC_MICROBLAZE_64_GOTPC
- This is a 64 bit reloc that stores the 32 bit pc relative value in
- two words (with an imm instruction). The relocation is
- PC-relative GOT offset
-
- -- : BFD_RELOC_MICROBLAZE_64_GOT
- This is a 64 bit reloc that stores the 32 bit pc relative value in
- two words (with an imm instruction). The relocation is GOT offset
-
- -- : BFD_RELOC_MICROBLAZE_64_PLT
- This is a 64 bit reloc that stores the 32 bit pc relative value in
- two words (with an imm instruction). The relocation is
- PC-relative offset into PLT
-
- -- : BFD_RELOC_MICROBLAZE_64_GOTOFF
- This is a 64 bit reloc that stores the 32 bit GOT relative value
- in two words (with an imm instruction). The relocation is
- relative offset from _GLOBAL_OFFSET_TABLE_
-
- -- : BFD_RELOC_MICROBLAZE_32_GOTOFF
- This is a 32 bit reloc that stores the 32 bit GOT relative value
- in a word. The relocation is relative offset from
-
- -- : BFD_RELOC_MICROBLAZE_COPY
- This is used to tell the dynamic linker to copy the value out of
- the dynamic object into the runtime process image.
-
-
- typedef enum bfd_reloc_code_real bfd_reloc_code_real_type;
-
-2.10.2.2 `bfd_reloc_type_lookup'
-................................
-
-*Synopsis*
- reloc_howto_type *bfd_reloc_type_lookup
- (bfd *abfd, bfd_reloc_code_real_type code);
- reloc_howto_type *bfd_reloc_name_lookup
- (bfd *abfd, const char *reloc_name);
- *Description*
-Return a pointer to a howto structure which, when invoked, will perform
-the relocation CODE on data from the architecture noted.
-
-2.10.2.3 `bfd_default_reloc_type_lookup'
-........................................
-
-*Synopsis*
- reloc_howto_type *bfd_default_reloc_type_lookup
- (bfd *abfd, bfd_reloc_code_real_type code);
- *Description*
-Provides a default relocation lookup routine for any architecture.
-
-2.10.2.4 `bfd_get_reloc_code_name'
-..................................
-
-*Synopsis*
- const char *bfd_get_reloc_code_name (bfd_reloc_code_real_type code);
- *Description*
-Provides a printable name for the supplied relocation code. Useful
-mainly for printing error messages.
-
-2.10.2.5 `bfd_generic_relax_section'
-....................................
-
-*Synopsis*
- bfd_boolean bfd_generic_relax_section
- (bfd *abfd,
- asection *section,
- struct bfd_link_info *,
- bfd_boolean *);
- *Description*
-Provides default handling for relaxing for back ends which don't do
-relaxing.
-
-2.10.2.6 `bfd_generic_gc_sections'
-..................................
-
-*Synopsis*
- bfd_boolean bfd_generic_gc_sections
- (bfd *, struct bfd_link_info *);
- *Description*
-Provides default handling for relaxing for back ends which don't do
-section gc - i.e., does nothing.
-
-2.10.2.7 `bfd_generic_merge_sections'
-.....................................
-
-*Synopsis*
- bfd_boolean bfd_generic_merge_sections
- (bfd *, struct bfd_link_info *);
- *Description*
-Provides default handling for SEC_MERGE section merging for back ends
-which don't have SEC_MERGE support - i.e., does nothing.
-
-2.10.2.8 `bfd_generic_get_relocated_section_contents'
-.....................................................
-
-*Synopsis*
- bfd_byte *bfd_generic_get_relocated_section_contents
- (bfd *abfd,
- struct bfd_link_info *link_info,
- struct bfd_link_order *link_order,
- bfd_byte *data,
- bfd_boolean relocatable,
- asymbol **symbols);
- *Description*
-Provides default handling of relocation effort for back ends which
-can't be bothered to do it efficiently.
-
-
-File: bfd.info, Node: Core Files, Next: Targets, Prev: Relocations, Up: BFD front end
-
-2.11 Core files
-===============
-
-2.11.1 Core file functions
---------------------------
-
-*Description*
-These are functions pertaining to core files.
-
-2.11.1.1 `bfd_core_file_failing_command'
-........................................
-
-*Synopsis*
- const char *bfd_core_file_failing_command (bfd *abfd);
- *Description*
-Return a read-only string explaining which program was running when it
-failed and produced the core file ABFD.
-
-2.11.1.2 `bfd_core_file_failing_signal'
-.......................................
-
-*Synopsis*
- int bfd_core_file_failing_signal (bfd *abfd);
- *Description*
-Returns the signal number which caused the core dump which generated
-the file the BFD ABFD is attached to.
-
-2.11.1.3 `bfd_core_file_pid'
-............................
-
-*Synopsis*
- int bfd_core_file_pid (bfd *abfd);
- *Description*
-Returns the PID of the process the core dump the BFD ABFD is attached
-to was generated from.
-
-2.11.1.4 `core_file_matches_executable_p'
-.........................................
-
-*Synopsis*
- bfd_boolean core_file_matches_executable_p
- (bfd *core_bfd, bfd *exec_bfd);
- *Description*
-Return `TRUE' if the core file attached to CORE_BFD was generated by a
-run of the executable file attached to EXEC_BFD, `FALSE' otherwise.
-
-2.11.1.5 `generic_core_file_matches_executable_p'
-.................................................
-
-*Synopsis*
- bfd_boolean generic_core_file_matches_executable_p
- (bfd *core_bfd, bfd *exec_bfd);
- *Description*
-Return TRUE if the core file attached to CORE_BFD was generated by a
-run of the executable file attached to EXEC_BFD. The match is based on
-executable basenames only.
-
- Note: When not able to determine the core file failing command or
-the executable name, we still return TRUE even though we're not sure
-that core file and executable match. This is to avoid generating a
-false warning in situations where we really don't know whether they
-match or not.
-
-
-File: bfd.info, Node: Targets, Next: Architectures, Prev: Core Files, Up: BFD front end
-
-2.12 Targets
-============
-
-*Description*
-Each port of BFD to a different machine requires the creation of a
-target back end. All the back end provides to the root part of BFD is a
-structure containing pointers to functions which perform certain low
-level operations on files. BFD translates the applications's requests
-through a pointer into calls to the back end routines.
-
- When a file is opened with `bfd_openr', its format and target are
-unknown. BFD uses various mechanisms to determine how to interpret the
-file. The operations performed are:
-
- * Create a BFD by calling the internal routine `_bfd_new_bfd', then
- call `bfd_find_target' with the target string supplied to
- `bfd_openr' and the new BFD pointer.
-
- * If a null target string was provided to `bfd_find_target', look up
- the environment variable `GNUTARGET' and use that as the target
- string.
-
- * If the target string is still `NULL', or the target string is
- `default', then use the first item in the target vector as the
- target type, and set `target_defaulted' in the BFD to cause
- `bfd_check_format' to loop through all the targets. *Note
- bfd_target::. *Note Formats::.
-
- * Otherwise, inspect the elements in the target vector one by one,
- until a match on target name is found. When found, use it.
-
- * Otherwise return the error `bfd_error_invalid_target' to
- `bfd_openr'.
-
- * `bfd_openr' attempts to open the file using `bfd_open_file', and
- returns the BFD.
- Once the BFD has been opened and the target selected, the file
-format may be determined. This is done by calling `bfd_check_format' on
-the BFD with a suggested format. If `target_defaulted' has been set,
-each possible target type is tried to see if it recognizes the
-specified format. `bfd_check_format' returns `TRUE' when the caller
-guesses right.
-
-* Menu:
-
-* bfd_target::
-
-
-File: bfd.info, Node: bfd_target, Prev: Targets, Up: Targets
-
-2.12.1 bfd_target
------------------
-
-*Description*
-This structure contains everything that BFD knows about a target. It
-includes things like its byte order, name, and which routines to call
-to do various operations.
-
- Every BFD points to a target structure with its `xvec' member.
-
- The macros below are used to dispatch to functions through the
-`bfd_target' vector. They are used in a number of macros further down
-in `bfd.h', and are also used when calling various routines by hand
-inside the BFD implementation. The ARGLIST argument must be
-parenthesized; it contains all the arguments to the called function.
-
- They make the documentation (more) unpleasant to read, so if someone
-wants to fix this and not break the above, please do.
- #define BFD_SEND(bfd, message, arglist) \
- ((*((bfd)->xvec->message)) arglist)
-
- #ifdef DEBUG_BFD_SEND
- #undef BFD_SEND
- #define BFD_SEND(bfd, message, arglist) \
- (((bfd) && (bfd)->xvec && (bfd)->xvec->message) ? \
- ((*((bfd)->xvec->message)) arglist) : \
- (bfd_assert (__FILE__,__LINE__), NULL))
- #endif
- For operations which index on the BFD format:
- #define BFD_SEND_FMT(bfd, message, arglist) \
- (((bfd)->xvec->message[(int) ((bfd)->format)]) arglist)
-
- #ifdef DEBUG_BFD_SEND
- #undef BFD_SEND_FMT
- #define BFD_SEND_FMT(bfd, message, arglist) \
- (((bfd) && (bfd)->xvec && (bfd)->xvec->message) ? \
- (((bfd)->xvec->message[(int) ((bfd)->format)]) arglist) : \
- (bfd_assert (__FILE__,__LINE__), NULL))
- #endif
- This is the structure which defines the type of BFD this is. The
-`xvec' member of the struct `bfd' itself points here. Each module that
-implements access to a different target under BFD, defines one of these.
-
- FIXME, these names should be rationalised with the names of the
-entry points which call them. Too bad we can't have one macro to define
-them both!
- enum bfd_flavour
- {
- bfd_target_unknown_flavour,
- bfd_target_aout_flavour,
- bfd_target_coff_flavour,
- bfd_target_ecoff_flavour,
- bfd_target_xcoff_flavour,
- bfd_target_elf_flavour,
- bfd_target_ieee_flavour,
- bfd_target_nlm_flavour,
- bfd_target_oasys_flavour,
- bfd_target_tekhex_flavour,
- bfd_target_srec_flavour,
- bfd_target_verilog_flavour,
- bfd_target_ihex_flavour,
- bfd_target_som_flavour,
- bfd_target_os9k_flavour,
- bfd_target_versados_flavour,
- bfd_target_msdos_flavour,
- bfd_target_ovax_flavour,
- bfd_target_evax_flavour,
- bfd_target_mmo_flavour,
- bfd_target_mach_o_flavour,
- bfd_target_pef_flavour,
- bfd_target_pef_xlib_flavour,
- bfd_target_sym_flavour
- };
-
- enum bfd_endian { BFD_ENDIAN_BIG, BFD_ENDIAN_LITTLE, BFD_ENDIAN_UNKNOWN };
-
- /* Forward declaration. */
- typedef struct bfd_link_info _bfd_link_info;
-
- typedef struct bfd_target
- {
- /* Identifies the kind of target, e.g., SunOS4, Ultrix, etc. */
- char *name;
-
- /* The "flavour" of a back end is a general indication about
- the contents of a file. */
- enum bfd_flavour flavour;
-
- /* The order of bytes within the data area of a file. */
- enum bfd_endian byteorder;
-
- /* The order of bytes within the header parts of a file. */
- enum bfd_endian header_byteorder;
-
- /* A mask of all the flags which an executable may have set -
- from the set `BFD_NO_FLAGS', `HAS_RELOC', ...`D_PAGED'. */
- flagword object_flags;
-
- /* A mask of all the flags which a section may have set - from
- the set `SEC_NO_FLAGS', `SEC_ALLOC', ...`SET_NEVER_LOAD'. */
- flagword section_flags;
-
- /* The character normally found at the front of a symbol.
- (if any), perhaps `_'. */
- char symbol_leading_char;
-
- /* The pad character for file names within an archive header. */
- char ar_pad_char;
-
- /* The maximum number of characters in an archive header. */
- unsigned short ar_max_namelen;
-
- /* Entries for byte swapping for data. These are different from the
- other entry points, since they don't take a BFD as the first argument.
- Certain other handlers could do the same. */
- bfd_uint64_t (*bfd_getx64) (const void *);
- bfd_int64_t (*bfd_getx_signed_64) (const void *);
- void (*bfd_putx64) (bfd_uint64_t, void *);
- bfd_vma (*bfd_getx32) (const void *);
- bfd_signed_vma (*bfd_getx_signed_32) (const void *);
- void (*bfd_putx32) (bfd_vma, void *);
- bfd_vma (*bfd_getx16) (const void *);
- bfd_signed_vma (*bfd_getx_signed_16) (const void *);
- void (*bfd_putx16) (bfd_vma, void *);
-
- /* Byte swapping for the headers. */
- bfd_uint64_t (*bfd_h_getx64) (const void *);
- bfd_int64_t (*bfd_h_getx_signed_64) (const void *);
- void (*bfd_h_putx64) (bfd_uint64_t, void *);
- bfd_vma (*bfd_h_getx32) (const void *);
- bfd_signed_vma (*bfd_h_getx_signed_32) (const void *);
- void (*bfd_h_putx32) (bfd_vma, void *);
- bfd_vma (*bfd_h_getx16) (const void *);
- bfd_signed_vma (*bfd_h_getx_signed_16) (const void *);
- void (*bfd_h_putx16) (bfd_vma, void *);
-
- /* Format dependent routines: these are vectors of entry points
- within the target vector structure, one for each format to check. */
-
- /* Check the format of a file being read. Return a `bfd_target *' or zero. */
- const struct bfd_target *(*_bfd_check_format[bfd_type_end]) (bfd *);
-
- /* Set the format of a file being written. */
- bfd_boolean (*_bfd_set_format[bfd_type_end]) (bfd *);
-
- /* Write cached information into a file being written, at `bfd_close'. */
- bfd_boolean (*_bfd_write_contents[bfd_type_end]) (bfd *);
- The general target vector. These vectors are initialized using the
-BFD_JUMP_TABLE macros.
-
- /* Generic entry points. */
- #define BFD_JUMP_TABLE_GENERIC(NAME) \
- NAME##_close_and_cleanup, \
- NAME##_bfd_free_cached_info, \
- NAME##_new_section_hook, \
- NAME##_get_section_contents, \
- NAME##_get_section_contents_in_window
-
- /* Called when the BFD is being closed to do any necessary cleanup. */
- bfd_boolean (*_close_and_cleanup) (bfd *);
- /* Ask the BFD to free all cached information. */
- bfd_boolean (*_bfd_free_cached_info) (bfd *);
- /* Called when a new section is created. */
- bfd_boolean (*_new_section_hook) (bfd *, sec_ptr);
- /* Read the contents of a section. */
- bfd_boolean (*_bfd_get_section_contents)
- (bfd *, sec_ptr, void *, file_ptr, bfd_size_type);
- bfd_boolean (*_bfd_get_section_contents_in_window)
- (bfd *, sec_ptr, bfd_window *, file_ptr, bfd_size_type);
-
- /* Entry points to copy private data. */
- #define BFD_JUMP_TABLE_COPY(NAME) \
- NAME##_bfd_copy_private_bfd_data, \
- NAME##_bfd_merge_private_bfd_data, \
- _bfd_generic_init_private_section_data, \
- NAME##_bfd_copy_private_section_data, \
- NAME##_bfd_copy_private_symbol_data, \
- NAME##_bfd_copy_private_header_data, \
- NAME##_bfd_set_private_flags, \
- NAME##_bfd_print_private_bfd_data
-
- /* Called to copy BFD general private data from one object file
- to another. */
- bfd_boolean (*_bfd_copy_private_bfd_data) (bfd *, bfd *);
- /* Called to merge BFD general private data from one object file
- to a common output file when linking. */
- bfd_boolean (*_bfd_merge_private_bfd_data) (bfd *, bfd *);
- /* Called to initialize BFD private section data from one object file
- to another. */
- #define bfd_init_private_section_data(ibfd, isec, obfd, osec, link_info) \
- BFD_SEND (obfd, _bfd_init_private_section_data, (ibfd, isec, obfd, osec, link_info))
- bfd_boolean (*_bfd_init_private_section_data)
- (bfd *, sec_ptr, bfd *, sec_ptr, struct bfd_link_info *);
- /* Called to copy BFD private section data from one object file
- to another. */
- bfd_boolean (*_bfd_copy_private_section_data)
- (bfd *, sec_ptr, bfd *, sec_ptr);
- /* Called to copy BFD private symbol data from one symbol
- to another. */
- bfd_boolean (*_bfd_copy_private_symbol_data)
- (bfd *, asymbol *, bfd *, asymbol *);
- /* Called to copy BFD private header data from one object file
- to another. */
- bfd_boolean (*_bfd_copy_private_header_data)
- (bfd *, bfd *);
- /* Called to set private backend flags. */
- bfd_boolean (*_bfd_set_private_flags) (bfd *, flagword);
-
- /* Called to print private BFD data. */
- bfd_boolean (*_bfd_print_private_bfd_data) (bfd *, void *);
-
- /* Core file entry points. */
- #define BFD_JUMP_TABLE_CORE(NAME) \
- NAME##_core_file_failing_command, \
- NAME##_core_file_failing_signal, \
- NAME##_core_file_matches_executable_p, \
- NAME##_core_file_pid
-
- char * (*_core_file_failing_command) (bfd *);
- int (*_core_file_failing_signal) (bfd *);
- bfd_boolean (*_core_file_matches_executable_p) (bfd *, bfd *);
- int (*_core_file_pid) (bfd *);
-
- /* Archive entry points. */
- #define BFD_JUMP_TABLE_ARCHIVE(NAME) \
- NAME##_slurp_armap, \
- NAME##_slurp_extended_name_table, \
- NAME##_construct_extended_name_table, \
- NAME##_truncate_arname, \
- NAME##_write_armap, \
- NAME##_read_ar_hdr, \
- NAME##_write_ar_hdr, \
- NAME##_openr_next_archived_file, \
- NAME##_get_elt_at_index, \
- NAME##_generic_stat_arch_elt, \
- NAME##_update_armap_timestamp
-
- bfd_boolean (*_bfd_slurp_armap) (bfd *);
- bfd_boolean (*_bfd_slurp_extended_name_table) (bfd *);
- bfd_boolean (*_bfd_construct_extended_name_table)
- (bfd *, char **, bfd_size_type *, const char **);
- void (*_bfd_truncate_arname) (bfd *, const char *, char *);
- bfd_boolean (*write_armap)
- (bfd *, unsigned int, struct orl *, unsigned int, int);
- void * (*_bfd_read_ar_hdr_fn) (bfd *);
- bfd_boolean (*_bfd_write_ar_hdr_fn) (bfd *, bfd *);
- bfd * (*openr_next_archived_file) (bfd *, bfd *);
- #define bfd_get_elt_at_index(b,i) BFD_SEND (b, _bfd_get_elt_at_index, (b,i))
- bfd * (*_bfd_get_elt_at_index) (bfd *, symindex);
- int (*_bfd_stat_arch_elt) (bfd *, struct stat *);
- bfd_boolean (*_bfd_update_armap_timestamp) (bfd *);
-
- /* Entry points used for symbols. */
- #define BFD_JUMP_TABLE_SYMBOLS(NAME) \
- NAME##_get_symtab_upper_bound, \
- NAME##_canonicalize_symtab, \
- NAME##_make_empty_symbol, \
- NAME##_print_symbol, \
- NAME##_get_symbol_info, \
- NAME##_bfd_is_local_label_name, \
- NAME##_bfd_is_target_special_symbol, \
- NAME##_get_lineno, \
- NAME##_find_nearest_line, \
- _bfd_generic_find_line, \
- NAME##_find_inliner_info, \
- NAME##_bfd_make_debug_symbol, \
- NAME##_read_minisymbols, \
- NAME##_minisymbol_to_symbol
-
- long (*_bfd_get_symtab_upper_bound) (bfd *);
- long (*_bfd_canonicalize_symtab)
- (bfd *, struct bfd_symbol **);
- struct bfd_symbol *
- (*_bfd_make_empty_symbol) (bfd *);
- void (*_bfd_print_symbol)
- (bfd *, void *, struct bfd_symbol *, bfd_print_symbol_type);
- #define bfd_print_symbol(b,p,s,e) BFD_SEND (b, _bfd_print_symbol, (b,p,s,e))
- void (*_bfd_get_symbol_info)
- (bfd *, struct bfd_symbol *, symbol_info *);
- #define bfd_get_symbol_info(b,p,e) BFD_SEND (b, _bfd_get_symbol_info, (b,p,e))
- bfd_boolean (*_bfd_is_local_label_name) (bfd *, const char *);
- bfd_boolean (*_bfd_is_target_special_symbol) (bfd *, asymbol *);
- alent * (*_get_lineno) (bfd *, struct bfd_symbol *);
- bfd_boolean (*_bfd_find_nearest_line)
- (bfd *, struct bfd_section *, struct bfd_symbol **, bfd_vma,
- const char **, const char **, unsigned int *);
- bfd_boolean (*_bfd_find_line)
- (bfd *, struct bfd_symbol **, struct bfd_symbol *,
- const char **, unsigned int *);
- bfd_boolean (*_bfd_find_inliner_info)
- (bfd *, const char **, const char **, unsigned int *);
- /* Back-door to allow format-aware applications to create debug symbols
- while using BFD for everything else. Currently used by the assembler
- when creating COFF files. */
- asymbol * (*_bfd_make_debug_symbol)
- (bfd *, void *, unsigned long size);
- #define bfd_read_minisymbols(b, d, m, s) \
- BFD_SEND (b, _read_minisymbols, (b, d, m, s))
- long (*_read_minisymbols)
- (bfd *, bfd_boolean, void **, unsigned int *);
- #define bfd_minisymbol_to_symbol(b, d, m, f) \
- BFD_SEND (b, _minisymbol_to_symbol, (b, d, m, f))
- asymbol * (*_minisymbol_to_symbol)
- (bfd *, bfd_boolean, const void *, asymbol *);
-
- /* Routines for relocs. */
- #define BFD_JUMP_TABLE_RELOCS(NAME) \
- NAME##_get_reloc_upper_bound, \
- NAME##_canonicalize_reloc, \
- NAME##_bfd_reloc_type_lookup, \
- NAME##_bfd_reloc_name_lookup
-
- long (*_get_reloc_upper_bound) (bfd *, sec_ptr);
- long (*_bfd_canonicalize_reloc)
- (bfd *, sec_ptr, arelent **, struct bfd_symbol **);
- /* See documentation on reloc types. */
- reloc_howto_type *
- (*reloc_type_lookup) (bfd *, bfd_reloc_code_real_type);
- reloc_howto_type *
- (*reloc_name_lookup) (bfd *, const char *);
-
-
- /* Routines used when writing an object file. */
- #define BFD_JUMP_TABLE_WRITE(NAME) \
- NAME##_set_arch_mach, \
- NAME##_set_section_contents
-
- bfd_boolean (*_bfd_set_arch_mach)
- (bfd *, enum bfd_architecture, unsigned long);
- bfd_boolean (*_bfd_set_section_contents)
- (bfd *, sec_ptr, const void *, file_ptr, bfd_size_type);
-
- /* Routines used by the linker. */
- #define BFD_JUMP_TABLE_LINK(NAME) \
- NAME##_sizeof_headers, \
- NAME##_bfd_get_relocated_section_contents, \
- NAME##_bfd_relax_section, \
- NAME##_bfd_link_hash_table_create, \
- NAME##_bfd_link_hash_table_free, \
- NAME##_bfd_link_add_symbols, \
- NAME##_bfd_link_just_syms, \
- NAME##_bfd_copy_link_hash_symbol_type, \
- NAME##_bfd_final_link, \
- NAME##_bfd_link_split_section, \
- NAME##_bfd_gc_sections, \
- NAME##_bfd_merge_sections, \
- NAME##_bfd_is_group_section, \
- NAME##_bfd_discard_group, \
- NAME##_section_already_linked, \
- NAME##_bfd_define_common_symbol
-
- int (*_bfd_sizeof_headers) (bfd *, struct bfd_link_info *);
- bfd_byte * (*_bfd_get_relocated_section_contents)
- (bfd *, struct bfd_link_info *, struct bfd_link_order *,
- bfd_byte *, bfd_boolean, struct bfd_symbol **);
-
- bfd_boolean (*_bfd_relax_section)
- (bfd *, struct bfd_section *, struct bfd_link_info *, bfd_boolean *);
-
- /* Create a hash table for the linker. Different backends store
- different information in this table. */
- struct bfd_link_hash_table *
- (*_bfd_link_hash_table_create) (bfd *);
-
- /* Release the memory associated with the linker hash table. */
- void (*_bfd_link_hash_table_free) (struct bfd_link_hash_table *);
-
- /* Add symbols from this object file into the hash table. */
- bfd_boolean (*_bfd_link_add_symbols) (bfd *, struct bfd_link_info *);
-
- /* Indicate that we are only retrieving symbol values from this section. */
- void (*_bfd_link_just_syms) (asection *, struct bfd_link_info *);
-
- /* Copy the symbol type of a linker hash table entry. */
- #define bfd_copy_link_hash_symbol_type(b, t, f) \
- BFD_SEND (b, _bfd_copy_link_hash_symbol_type, (b, t, f))
- void (*_bfd_copy_link_hash_symbol_type)
- (bfd *, struct bfd_link_hash_entry *, struct bfd_link_hash_entry *);
-
- /* Do a link based on the link_order structures attached to each
- section of the BFD. */
- bfd_boolean (*_bfd_final_link) (bfd *, struct bfd_link_info *);
-
- /* Should this section be split up into smaller pieces during linking. */
- bfd_boolean (*_bfd_link_split_section) (bfd *, struct bfd_section *);
-
- /* Remove sections that are not referenced from the output. */
- bfd_boolean (*_bfd_gc_sections) (bfd *, struct bfd_link_info *);
-
- /* Attempt to merge SEC_MERGE sections. */
- bfd_boolean (*_bfd_merge_sections) (bfd *, struct bfd_link_info *);
-
- /* Is this section a member of a group? */
- bfd_boolean (*_bfd_is_group_section) (bfd *, const struct bfd_section *);
-
- /* Discard members of a group. */
- bfd_boolean (*_bfd_discard_group) (bfd *, struct bfd_section *);
-
- /* Check if SEC has been already linked during a reloceatable or
- final link. */
- void (*_section_already_linked) (bfd *, struct bfd_section *,
- struct bfd_link_info *);
-
- /* Define a common symbol. */
- bfd_boolean (*_bfd_define_common_symbol) (bfd *, struct bfd_link_info *,
- struct bfd_link_hash_entry *);
-
- /* Routines to handle dynamic symbols and relocs. */
- #define BFD_JUMP_TABLE_DYNAMIC(NAME) \
- NAME##_get_dynamic_symtab_upper_bound, \
- NAME##_canonicalize_dynamic_symtab, \
- NAME##_get_synthetic_symtab, \
- NAME##_get_dynamic_reloc_upper_bound, \
- NAME##_canonicalize_dynamic_reloc
-
- /* Get the amount of memory required to hold the dynamic symbols. */
- long (*_bfd_get_dynamic_symtab_upper_bound) (bfd *);
- /* Read in the dynamic symbols. */
- long (*_bfd_canonicalize_dynamic_symtab)
- (bfd *, struct bfd_symbol **);
- /* Create synthetized symbols. */
- long (*_bfd_get_synthetic_symtab)
- (bfd *, long, struct bfd_symbol **, long, struct bfd_symbol **,
- struct bfd_symbol **);
- /* Get the amount of memory required to hold the dynamic relocs. */
- long (*_bfd_get_dynamic_reloc_upper_bound) (bfd *);
- /* Read in the dynamic relocs. */
- long (*_bfd_canonicalize_dynamic_reloc)
- (bfd *, arelent **, struct bfd_symbol **);
- A pointer to an alternative bfd_target in case the current one is not
-satisfactory. This can happen when the target cpu supports both big
-and little endian code, and target chosen by the linker has the wrong
-endianness. The function open_output() in ld/ldlang.c uses this field
-to find an alternative output format that is suitable.
- /* Opposite endian version of this target. */
- const struct bfd_target * alternative_target;
-
- /* Data for use by back-end routines, which isn't
- generic enough to belong in this structure. */
- const void *backend_data;
-
- } bfd_target;
-
-2.12.1.1 `bfd_set_default_target'
-.................................
-
-*Synopsis*
- bfd_boolean bfd_set_default_target (const char *name);
- *Description*
-Set the default target vector to use when recognizing a BFD. This
-takes the name of the target, which may be a BFD target name or a
-configuration triplet.
-
-2.12.1.2 `bfd_find_target'
-..........................
-
-*Synopsis*
- const bfd_target *bfd_find_target (const char *target_name, bfd *abfd);
- *Description*
-Return a pointer to the transfer vector for the object target named
-TARGET_NAME. If TARGET_NAME is `NULL', choose the one in the
-environment variable `GNUTARGET'; if that is null or not defined, then
-choose the first entry in the target list. Passing in the string
-"default" or setting the environment variable to "default" will cause
-the first entry in the target list to be returned, and
-"target_defaulted" will be set in the BFD if ABFD isn't `NULL'. This
-causes `bfd_check_format' to loop over all the targets to find the one
-that matches the file being read.
-
-2.12.1.3 `bfd_get_target_info'
-..............................
-
-*Synopsis*
- const bfd_target *bfd_get_target_info (const char *target_name,
- bfd *abfd,
- bfd_boolean *is_bigendian,
- int *underscoring,
- const char **def_target_arch);
- *Description*
-Return a pointer to the transfer vector for the object target named
-TARGET_NAME. If TARGET_NAME is `NULL', choose the one in the
-environment variable `GNUTARGET'; if that is null or not defined, then
-choose the first entry in the target list. Passing in the string
-"default" or setting the environment variable to "default" will cause
-the first entry in the target list to be returned, and
-"target_defaulted" will be set in the BFD if ABFD isn't `NULL'. This
-causes `bfd_check_format' to loop over all the targets to find the one
-that matches the file being read. If IS_BIGENDIAN is not `NULL', then
-set this value to target's endian mode. True for big-endian, FALSE for
-little-endian or for invalid target. If UNDERSCORING is not `NULL',
-then set this value to target's underscoring mode. Zero for
-none-underscoring, -1 for invalid target, else the value of target
-vector's symbol underscoring. If DEF_TARGET_ARCH is not `NULL', then
-set it to the architecture string specified by the target_name.
-
-2.12.1.4 `bfd_target_list'
-..........................
-
-*Synopsis*
- const char ** bfd_target_list (void);
- *Description*
-Return a freshly malloced NULL-terminated vector of the names of all
-the valid BFD targets. Do not modify the names.
-
-2.12.1.5 `bfd_seach_for_target'
-...............................
-
-*Synopsis*
- const bfd_target *bfd_search_for_target
- (int (*search_func) (const bfd_target *, void *),
- void *);
- *Description*
-Return a pointer to the first transfer vector in the list of transfer
-vectors maintained by BFD that produces a non-zero result when passed
-to the function SEARCH_FUNC. The parameter DATA is passed, unexamined,
-to the search function.
-
-
-File: bfd.info, Node: Architectures, Next: Opening and Closing, Prev: Targets, Up: BFD front end
-
-2.13 Architectures
-==================
-
-BFD keeps one atom in a BFD describing the architecture of the data
-attached to the BFD: a pointer to a `bfd_arch_info_type'.
-
- Pointers to structures can be requested independently of a BFD so
-that an architecture's information can be interrogated without access
-to an open BFD.
-
- The architecture information is provided by each architecture
-package. The set of default architectures is selected by the macro
-`SELECT_ARCHITECTURES'. This is normally set up in the
-`config/TARGET.mt' file of your choice. If the name is not defined,
-then all the architectures supported are included.
-
- When BFD starts up, all the architectures are called with an
-initialize method. It is up to the architecture back end to insert as
-many items into the list of architectures as it wants to; generally
-this would be one for each machine and one for the default case (an
-item with a machine field of 0).
-
- BFD's idea of an architecture is implemented in `archures.c'.
-
-2.13.1 bfd_architecture
------------------------
-
-*Description*
-This enum gives the object file's CPU architecture, in a global
-sense--i.e., what processor family does it belong to? Another field
-indicates which processor within the family is in use. The machine
-gives a number which distinguishes different versions of the
-architecture, containing, for example, 2 and 3 for Intel i960 KA and
-i960 KB, and 68020 and 68030 for Motorola 68020 and 68030.
- enum bfd_architecture
- {
- bfd_arch_unknown, /* File arch not known. */
- bfd_arch_obscure, /* Arch known, not one of these. */
- bfd_arch_m68k, /* Motorola 68xxx */
- #define bfd_mach_m68000 1
- #define bfd_mach_m68008 2
- #define bfd_mach_m68010 3
- #define bfd_mach_m68020 4
- #define bfd_mach_m68030 5
- #define bfd_mach_m68040 6
- #define bfd_mach_m68060 7
- #define bfd_mach_cpu32 8
- #define bfd_mach_fido 9
- #define bfd_mach_mcf_isa_a_nodiv 10
- #define bfd_mach_mcf_isa_a 11
- #define bfd_mach_mcf_isa_a_mac 12
- #define bfd_mach_mcf_isa_a_emac 13
- #define bfd_mach_mcf_isa_aplus 14
- #define bfd_mach_mcf_isa_aplus_mac 15
- #define bfd_mach_mcf_isa_aplus_emac 16
- #define bfd_mach_mcf_isa_b_nousp 17
- #define bfd_mach_mcf_isa_b_nousp_mac 18
- #define bfd_mach_mcf_isa_b_nousp_emac 19
- #define bfd_mach_mcf_isa_b 20
- #define bfd_mach_mcf_isa_b_mac 21
- #define bfd_mach_mcf_isa_b_emac 22
- #define bfd_mach_mcf_isa_b_float 23
- #define bfd_mach_mcf_isa_b_float_mac 24
- #define bfd_mach_mcf_isa_b_float_emac 25
- #define bfd_mach_mcf_isa_c 26
- #define bfd_mach_mcf_isa_c_mac 27
- #define bfd_mach_mcf_isa_c_emac 28
- #define bfd_mach_mcf_isa_c_nodiv 29
- #define bfd_mach_mcf_isa_c_nodiv_mac 30
- #define bfd_mach_mcf_isa_c_nodiv_emac 31
- bfd_arch_vax, /* DEC Vax */
- bfd_arch_i960, /* Intel 960 */
- /* The order of the following is important.
- lower number indicates a machine type that
- only accepts a subset of the instructions
- available to machines with higher numbers.
- The exception is the "ca", which is
- incompatible with all other machines except
- "core". */
-
- #define bfd_mach_i960_core 1
- #define bfd_mach_i960_ka_sa 2
- #define bfd_mach_i960_kb_sb 3
- #define bfd_mach_i960_mc 4
- #define bfd_mach_i960_xa 5
- #define bfd_mach_i960_ca 6
- #define bfd_mach_i960_jx 7
- #define bfd_mach_i960_hx 8
-
- bfd_arch_or32, /* OpenRISC 32 */
-
- bfd_arch_sparc, /* SPARC */
- #define bfd_mach_sparc 1
- /* The difference between v8plus and v9 is that v9 is a true 64 bit env. */
- #define bfd_mach_sparc_sparclet 2
- #define bfd_mach_sparc_sparclite 3
- #define bfd_mach_sparc_v8plus 4
- #define bfd_mach_sparc_v8plusa 5 /* with ultrasparc add'ns. */
- #define bfd_mach_sparc_sparclite_le 6
- #define bfd_mach_sparc_v9 7
- #define bfd_mach_sparc_v9a 8 /* with ultrasparc add'ns. */
- #define bfd_mach_sparc_v8plusb 9 /* with cheetah add'ns. */
- #define bfd_mach_sparc_v9b 10 /* with cheetah add'ns. */
- /* Nonzero if MACH has the v9 instruction set. */
- #define bfd_mach_sparc_v9_p(mach) \
- ((mach) >= bfd_mach_sparc_v8plus && (mach) <= bfd_mach_sparc_v9b \
- && (mach) != bfd_mach_sparc_sparclite_le)
- /* Nonzero if MACH is a 64 bit sparc architecture. */
- #define bfd_mach_sparc_64bit_p(mach) \
- ((mach) >= bfd_mach_sparc_v9 && (mach) != bfd_mach_sparc_v8plusb)
- bfd_arch_spu, /* PowerPC SPU */
- #define bfd_mach_spu 256
- bfd_arch_mips, /* MIPS Rxxxx */
- #define bfd_mach_mips3000 3000
- #define bfd_mach_mips3900 3900
- #define bfd_mach_mips4000 4000
- #define bfd_mach_mips4010 4010
- #define bfd_mach_mips4100 4100
- #define bfd_mach_mips4111 4111
- #define bfd_mach_mips4120 4120
- #define bfd_mach_mips4300 4300
- #define bfd_mach_mips4400 4400
- #define bfd_mach_mips4600 4600
- #define bfd_mach_mips4650 4650
- #define bfd_mach_mips5000 5000
- #define bfd_mach_mips5400 5400
- #define bfd_mach_mips5500 5500
- #define bfd_mach_mips6000 6000
- #define bfd_mach_mips7000 7000
- #define bfd_mach_mips8000 8000
- #define bfd_mach_mips9000 9000
- #define bfd_mach_mips10000 10000
- #define bfd_mach_mips12000 12000
- #define bfd_mach_mips14000 14000
- #define bfd_mach_mips16000 16000
- #define bfd_mach_mips16 16
- #define bfd_mach_mips5 5
- #define bfd_mach_mips_loongson_2e 3001
- #define bfd_mach_mips_loongson_2f 3002
- #define bfd_mach_mips_loongson_3a 3003
- #define bfd_mach_mips_sb1 12310201 /* octal 'SB', 01 */
- #define bfd_mach_mips_octeon 6501
- #define bfd_mach_mips_xlr 887682 /* decimal 'XLR' */
- #define bfd_mach_mipsisa32 32
- #define bfd_mach_mipsisa32r2 33
- #define bfd_mach_mipsisa64 64
- #define bfd_mach_mipsisa64r2 65
- bfd_arch_i386, /* Intel 386 */
- #define bfd_mach_i386_i386 1
- #define bfd_mach_i386_i8086 2
- #define bfd_mach_i386_i386_intel_syntax 3
- #define bfd_mach_x64_32 32
- #define bfd_mach_x64_32_intel_syntax 33
- #define bfd_mach_x86_64 64
- #define bfd_mach_x86_64_intel_syntax 65
- bfd_arch_l1om, /* Intel L1OM */
- #define bfd_mach_l1om 66
- #define bfd_mach_l1om_intel_syntax 67
- bfd_arch_we32k, /* AT&T WE32xxx */
- bfd_arch_tahoe, /* CCI/Harris Tahoe */
- bfd_arch_i860, /* Intel 860 */
- bfd_arch_i370, /* IBM 360/370 Mainframes */
- bfd_arch_romp, /* IBM ROMP PC/RT */
- bfd_arch_convex, /* Convex */
- bfd_arch_m88k, /* Motorola 88xxx */
- bfd_arch_m98k, /* Motorola 98xxx */
- bfd_arch_pyramid, /* Pyramid Technology */
- bfd_arch_h8300, /* Renesas H8/300 (formerly Hitachi H8/300) */
- #define bfd_mach_h8300 1
- #define bfd_mach_h8300h 2
- #define bfd_mach_h8300s 3
- #define bfd_mach_h8300hn 4
- #define bfd_mach_h8300sn 5
- #define bfd_mach_h8300sx 6
- #define bfd_mach_h8300sxn 7
- bfd_arch_pdp11, /* DEC PDP-11 */
- bfd_arch_plugin,
- bfd_arch_powerpc, /* PowerPC */
- #define bfd_mach_ppc 32
- #define bfd_mach_ppc64 64
- #define bfd_mach_ppc_403 403
- #define bfd_mach_ppc_403gc 4030
- #define bfd_mach_ppc_405 405
- #define bfd_mach_ppc_505 505
- #define bfd_mach_ppc_601 601
- #define bfd_mach_ppc_602 602
- #define bfd_mach_ppc_603 603
- #define bfd_mach_ppc_ec603e 6031
- #define bfd_mach_ppc_604 604
- #define bfd_mach_ppc_620 620
- #define bfd_mach_ppc_630 630
- #define bfd_mach_ppc_750 750
- #define bfd_mach_ppc_860 860
- #define bfd_mach_ppc_a35 35
- #define bfd_mach_ppc_rs64ii 642
- #define bfd_mach_ppc_rs64iii 643
- #define bfd_mach_ppc_7400 7400
- #define bfd_mach_ppc_e500 500
- #define bfd_mach_ppc_e500mc 5001
- #define bfd_mach_ppc_e500mc64 5005
- #define bfd_mach_ppc_titan 83
- bfd_arch_rs6000, /* IBM RS/6000 */
- #define bfd_mach_rs6k 6000
- #define bfd_mach_rs6k_rs1 6001
- #define bfd_mach_rs6k_rsc 6003
- #define bfd_mach_rs6k_rs2 6002
- bfd_arch_hppa, /* HP PA RISC */
- #define bfd_mach_hppa10 10
- #define bfd_mach_hppa11 11
- #define bfd_mach_hppa20 20
- #define bfd_mach_hppa20w 25
- bfd_arch_d10v, /* Mitsubishi D10V */
- #define bfd_mach_d10v 1
- #define bfd_mach_d10v_ts2 2
- #define bfd_mach_d10v_ts3 3
- bfd_arch_d30v, /* Mitsubishi D30V */
- bfd_arch_dlx, /* DLX */
- bfd_arch_m68hc11, /* Motorola 68HC11 */
- bfd_arch_m68hc12, /* Motorola 68HC12 */
- #define bfd_mach_m6812_default 0
- #define bfd_mach_m6812 1
- #define bfd_mach_m6812s 2
- bfd_arch_z8k, /* Zilog Z8000 */
- #define bfd_mach_z8001 1
- #define bfd_mach_z8002 2
- bfd_arch_h8500, /* Renesas H8/500 (formerly Hitachi H8/500) */
- bfd_arch_sh, /* Renesas / SuperH SH (formerly Hitachi SH) */
- #define bfd_mach_sh 1
- #define bfd_mach_sh2 0x20
- #define bfd_mach_sh_dsp 0x2d
- #define bfd_mach_sh2a 0x2a
- #define bfd_mach_sh2a_nofpu 0x2b
- #define bfd_mach_sh2a_nofpu_or_sh4_nommu_nofpu 0x2a1
- #define bfd_mach_sh2a_nofpu_or_sh3_nommu 0x2a2
- #define bfd_mach_sh2a_or_sh4 0x2a3
- #define bfd_mach_sh2a_or_sh3e 0x2a4
- #define bfd_mach_sh2e 0x2e
- #define bfd_mach_sh3 0x30
- #define bfd_mach_sh3_nommu 0x31
- #define bfd_mach_sh3_dsp 0x3d
- #define bfd_mach_sh3e 0x3e
- #define bfd_mach_sh4 0x40
- #define bfd_mach_sh4_nofpu 0x41
- #define bfd_mach_sh4_nommu_nofpu 0x42
- #define bfd_mach_sh4a 0x4a
- #define bfd_mach_sh4a_nofpu 0x4b
- #define bfd_mach_sh4al_dsp 0x4d
- #define bfd_mach_sh5 0x50
- bfd_arch_alpha, /* Dec Alpha */
- #define bfd_mach_alpha_ev4 0x10
- #define bfd_mach_alpha_ev5 0x20
- #define bfd_mach_alpha_ev6 0x30
- bfd_arch_arm, /* Advanced Risc Machines ARM. */
- #define bfd_mach_arm_unknown 0
- #define bfd_mach_arm_2 1
- #define bfd_mach_arm_2a 2
- #define bfd_mach_arm_3 3
- #define bfd_mach_arm_3M 4
- #define bfd_mach_arm_4 5
- #define bfd_mach_arm_4T 6
- #define bfd_mach_arm_5 7
- #define bfd_mach_arm_5T 8
- #define bfd_mach_arm_5TE 9
- #define bfd_mach_arm_XScale 10
- #define bfd_mach_arm_ep9312 11
- #define bfd_mach_arm_iWMMXt 12
- #define bfd_mach_arm_iWMMXt2 13
- bfd_arch_ns32k, /* National Semiconductors ns32000 */
- bfd_arch_w65, /* WDC 65816 */
- bfd_arch_tic30, /* Texas Instruments TMS320C30 */
- bfd_arch_tic4x, /* Texas Instruments TMS320C3X/4X */
- #define bfd_mach_tic3x 30
- #define bfd_mach_tic4x 40
- bfd_arch_tic54x, /* Texas Instruments TMS320C54X */
- bfd_arch_tic6x, /* Texas Instruments TMS320C6X */
- bfd_arch_tic80, /* TI TMS320c80 (MVP) */
- bfd_arch_v850, /* NEC V850 */
- #define bfd_mach_v850 1
- #define bfd_mach_v850e 'E'
- #define bfd_mach_v850e1 '1'
- #define bfd_mach_v850e2 0x4532
- #define bfd_mach_v850e2v3 0x45325633
- bfd_arch_arc, /* ARC Cores */
- #define bfd_mach_arc_5 5
- #define bfd_mach_arc_6 6
- #define bfd_mach_arc_7 7
- #define bfd_mach_arc_8 8
- bfd_arch_m32c, /* Renesas M16C/M32C. */
- #define bfd_mach_m16c 0x75
- #define bfd_mach_m32c 0x78
- bfd_arch_m32r, /* Renesas M32R (formerly Mitsubishi M32R/D) */
- #define bfd_mach_m32r 1 /* For backwards compatibility. */
- #define bfd_mach_m32rx 'x'
- #define bfd_mach_m32r2 '2'
- bfd_arch_mn10200, /* Matsushita MN10200 */
- bfd_arch_mn10300, /* Matsushita MN10300 */
- #define bfd_mach_mn10300 300
- #define bfd_mach_am33 330
- #define bfd_mach_am33_2 332
- bfd_arch_fr30,
- #define bfd_mach_fr30 0x46523330
- bfd_arch_frv,
- #define bfd_mach_frv 1
- #define bfd_mach_frvsimple 2
- #define bfd_mach_fr300 300
- #define bfd_mach_fr400 400
- #define bfd_mach_fr450 450
- #define bfd_mach_frvtomcat 499 /* fr500 prototype */
- #define bfd_mach_fr500 500
- #define bfd_mach_fr550 550
- bfd_arch_moxie, /* The moxie processor */
- #define bfd_mach_moxie 1
- bfd_arch_mcore,
- bfd_arch_mep,
- #define bfd_mach_mep 1
- #define bfd_mach_mep_h1 0x6831
- #define bfd_mach_mep_c5 0x6335
- bfd_arch_ia64, /* HP/Intel ia64 */
- #define bfd_mach_ia64_elf64 64
- #define bfd_mach_ia64_elf32 32
- bfd_arch_ip2k, /* Ubicom IP2K microcontrollers. */
- #define bfd_mach_ip2022 1
- #define bfd_mach_ip2022ext 2
- bfd_arch_iq2000, /* Vitesse IQ2000. */
- #define bfd_mach_iq2000 1
- #define bfd_mach_iq10 2
- bfd_arch_mt,
- #define bfd_mach_ms1 1
- #define bfd_mach_mrisc2 2
- #define bfd_mach_ms2 3
- bfd_arch_pj,
- bfd_arch_avr, /* Atmel AVR microcontrollers. */
- #define bfd_mach_avr1 1
- #define bfd_mach_avr2 2
- #define bfd_mach_avr25 25
- #define bfd_mach_avr3 3
- #define bfd_mach_avr31 31
- #define bfd_mach_avr35 35
- #define bfd_mach_avr4 4
- #define bfd_mach_avr5 5
- #define bfd_mach_avr51 51
- #define bfd_mach_avr6 6
- #define bfd_mach_avrxmega1 101
- #define bfd_mach_avrxmega2 102
- #define bfd_mach_avrxmega3 103
- #define bfd_mach_avrxmega4 104
- #define bfd_mach_avrxmega5 105
- #define bfd_mach_avrxmega6 106
- #define bfd_mach_avrxmega7 107
- bfd_arch_bfin, /* ADI Blackfin */
- #define bfd_mach_bfin 1
- bfd_arch_cr16, /* National Semiconductor CompactRISC (ie CR16). */
- #define bfd_mach_cr16 1
- bfd_arch_cr16c, /* National Semiconductor CompactRISC. */
- #define bfd_mach_cr16c 1
- bfd_arch_crx, /* National Semiconductor CRX. */
- #define bfd_mach_crx 1
- bfd_arch_cris, /* Axis CRIS */
- #define bfd_mach_cris_v0_v10 255
- #define bfd_mach_cris_v32 32
- #define bfd_mach_cris_v10_v32 1032
- bfd_arch_rx, /* Renesas RX. */
- #define bfd_mach_rx 0x75
- bfd_arch_s390, /* IBM s390 */
- #define bfd_mach_s390_31 31
- #define bfd_mach_s390_64 64
- bfd_arch_score, /* Sunplus score */
- #define bfd_mach_score3 3
- #define bfd_mach_score7 7
- bfd_arch_openrisc, /* OpenRISC */
- bfd_arch_mmix, /* Donald Knuth's educational processor. */
- bfd_arch_xstormy16,
- #define bfd_mach_xstormy16 1
- bfd_arch_msp430, /* Texas Instruments MSP430 architecture. */
- #define bfd_mach_msp11 11
- #define bfd_mach_msp110 110
- #define bfd_mach_msp12 12
- #define bfd_mach_msp13 13
- #define bfd_mach_msp14 14
- #define bfd_mach_msp15 15
- #define bfd_mach_msp16 16
- #define bfd_mach_msp21 21
- #define bfd_mach_msp31 31
- #define bfd_mach_msp32 32
- #define bfd_mach_msp33 33
- #define bfd_mach_msp41 41
- #define bfd_mach_msp42 42
- #define bfd_mach_msp43 43
- #define bfd_mach_msp44 44
- bfd_arch_xc16x, /* Infineon's XC16X Series. */
- #define bfd_mach_xc16x 1
- #define bfd_mach_xc16xl 2
- #define bfd_mach_xc16xs 3
- bfd_arch_xtensa, /* Tensilica's Xtensa cores. */
- #define bfd_mach_xtensa 1
- bfd_arch_z80,
- #define bfd_mach_z80strict 1 /* No undocumented opcodes. */
- #define bfd_mach_z80 3 /* With ixl, ixh, iyl, and iyh. */
- #define bfd_mach_z80full 7 /* All undocumented instructions. */
- #define bfd_mach_r800 11 /* R800: successor with multiplication. */
- bfd_arch_lm32, /* Lattice Mico32 */
- #define bfd_mach_lm32 1
- bfd_arch_microblaze,/* Xilinx MicroBlaze. */
- bfd_arch_last
- };
-
-2.13.2 bfd_arch_info
---------------------
-
-*Description*
-This structure contains information on architectures for use within BFD.
-
- typedef struct bfd_arch_info
- {
- int bits_per_word;
- int bits_per_address;
- int bits_per_byte;
- enum bfd_architecture arch;
- unsigned long mach;
- const char *arch_name;
- const char *printable_name;
- unsigned int section_align_power;
- /* TRUE if this is the default machine for the architecture.
- The default arch should be the first entry for an arch so that
- all the entries for that arch can be accessed via `next'. */
- bfd_boolean the_default;
- const struct bfd_arch_info * (*compatible)
- (const struct bfd_arch_info *a, const struct bfd_arch_info *b);
-
- bfd_boolean (*scan) (const struct bfd_arch_info *, const char *);
-
- const struct bfd_arch_info *next;
- }
- bfd_arch_info_type;
-
-2.13.2.1 `bfd_printable_name'
-.............................
-
-*Synopsis*
- const char *bfd_printable_name (bfd *abfd);
- *Description*
-Return a printable string representing the architecture and machine
-from the pointer to the architecture info structure.
-
-2.13.2.2 `bfd_scan_arch'
-........................
-
-*Synopsis*
- const bfd_arch_info_type *bfd_scan_arch (const char *string);
- *Description*
-Figure out if BFD supports any cpu which could be described with the
-name STRING. Return a pointer to an `arch_info' structure if a machine
-is found, otherwise NULL.
-
-2.13.2.3 `bfd_arch_list'
-........................
-
-*Synopsis*
- const char **bfd_arch_list (void);
- *Description*
-Return a freshly malloced NULL-terminated vector of the names of all
-the valid BFD architectures. Do not modify the names.
-
-2.13.2.4 `bfd_arch_get_compatible'
-..................................
-
-*Synopsis*
- const bfd_arch_info_type *bfd_arch_get_compatible
- (const bfd *abfd, const bfd *bbfd, bfd_boolean accept_unknowns);
- *Description*
-Determine whether two BFDs' architectures and machine types are
-compatible. Calculates the lowest common denominator between the two
-architectures and machine types implied by the BFDs and returns a
-pointer to an `arch_info' structure describing the compatible machine.
-
-2.13.2.5 `bfd_default_arch_struct'
-..................................
-
-*Description*
-The `bfd_default_arch_struct' is an item of `bfd_arch_info_type' which
-has been initialized to a fairly generic state. A BFD starts life by
-pointing to this structure, until the correct back end has determined
-the real architecture of the file.
- extern const bfd_arch_info_type bfd_default_arch_struct;
-
-2.13.2.6 `bfd_set_arch_info'
-............................
-
-*Synopsis*
- void bfd_set_arch_info (bfd *abfd, const bfd_arch_info_type *arg);
- *Description*
-Set the architecture info of ABFD to ARG.
-
-2.13.2.7 `bfd_default_set_arch_mach'
-....................................
-
-*Synopsis*
- bfd_boolean bfd_default_set_arch_mach
- (bfd *abfd, enum bfd_architecture arch, unsigned long mach);
- *Description*
-Set the architecture and machine type in BFD ABFD to ARCH and MACH.
-Find the correct pointer to a structure and insert it into the
-`arch_info' pointer.
-
-2.13.2.8 `bfd_get_arch'
-.......................
-
-*Synopsis*
- enum bfd_architecture bfd_get_arch (bfd *abfd);
- *Description*
-Return the enumerated type which describes the BFD ABFD's architecture.
-
-2.13.2.9 `bfd_get_mach'
-.......................
-
-*Synopsis*
- unsigned long bfd_get_mach (bfd *abfd);
- *Description*
-Return the long type which describes the BFD ABFD's machine.
-
-2.13.2.10 `bfd_arch_bits_per_byte'
-..................................
-
-*Synopsis*
- unsigned int bfd_arch_bits_per_byte (bfd *abfd);
- *Description*
-Return the number of bits in one of the BFD ABFD's architecture's bytes.
-
-2.13.2.11 `bfd_arch_bits_per_address'
-.....................................
-
-*Synopsis*
- unsigned int bfd_arch_bits_per_address (bfd *abfd);
- *Description*
-Return the number of bits in one of the BFD ABFD's architecture's
-addresses.
-
-2.13.2.12 `bfd_default_compatible'
-..................................
-
-*Synopsis*
- const bfd_arch_info_type *bfd_default_compatible
- (const bfd_arch_info_type *a, const bfd_arch_info_type *b);
- *Description*
-The default function for testing for compatibility.
-
-2.13.2.13 `bfd_default_scan'
-............................
-
-*Synopsis*
- bfd_boolean bfd_default_scan
- (const struct bfd_arch_info *info, const char *string);
- *Description*
-The default function for working out whether this is an architecture
-hit and a machine hit.
-
-2.13.2.14 `bfd_get_arch_info'
-.............................
-
-*Synopsis*
- const bfd_arch_info_type *bfd_get_arch_info (bfd *abfd);
- *Description*
-Return the architecture info struct in ABFD.
-
-2.13.2.15 `bfd_lookup_arch'
-...........................
-
-*Synopsis*
- const bfd_arch_info_type *bfd_lookup_arch
- (enum bfd_architecture arch, unsigned long machine);
- *Description*
-Look for the architecture info structure which matches the arguments
-ARCH and MACHINE. A machine of 0 matches the machine/architecture
-structure which marks itself as the default.
-
-2.13.2.16 `bfd_printable_arch_mach'
-...................................
-
-*Synopsis*
- const char *bfd_printable_arch_mach
- (enum bfd_architecture arch, unsigned long machine);
- *Description*
-Return a printable string representing the architecture and machine
-type.
-
- This routine is depreciated.
-
-2.13.2.17 `bfd_octets_per_byte'
-...............................
-
-*Synopsis*
- unsigned int bfd_octets_per_byte (bfd *abfd);
- *Description*
-Return the number of octets (8-bit quantities) per target byte (minimum
-addressable unit). In most cases, this will be one, but some DSP
-targets have 16, 32, or even 48 bits per byte.
-
-2.13.2.18 `bfd_arch_mach_octets_per_byte'
-.........................................
-
-*Synopsis*
- unsigned int bfd_arch_mach_octets_per_byte
- (enum bfd_architecture arch, unsigned long machine);
- *Description*
-See bfd_octets_per_byte.
-
- This routine is provided for those cases where a bfd * is not
-available
-
-
-File: bfd.info, Node: Opening and Closing, Next: Internal, Prev: Architectures, Up: BFD front end
-
- /* Set to N to open the next N BFDs using an alternate id space. */
- extern unsigned int bfd_use_reserved_id;
-
-2.14 Opening and closing BFDs
-=============================
-
-2.14.1 Functions for opening and closing
-----------------------------------------
-
-2.14.1.1 `bfd_fopen'
-....................
-
-*Synopsis*
- bfd *bfd_fopen (const char *filename, const char *target,
- const char *mode, int fd);
- *Description*
-Open the file FILENAME with the target TARGET. Return a pointer to the
-created BFD. If FD is not -1, then `fdopen' is used to open the file;
-otherwise, `fopen' is used. MODE is passed directly to `fopen' or
-`fdopen'.
-
- Calls `bfd_find_target', so TARGET is interpreted as by that
-function.
-
- The new BFD is marked as cacheable iff FD is -1.
-
- If `NULL' is returned then an error has occured. Possible errors
-are `bfd_error_no_memory', `bfd_error_invalid_target' or `system_call'
-error.
-
-2.14.1.2 `bfd_openr'
-....................
-
-*Synopsis*
- bfd *bfd_openr (const char *filename, const char *target);
- *Description*
-Open the file FILENAME (using `fopen') with the target TARGET. Return
-a pointer to the created BFD.
-
- Calls `bfd_find_target', so TARGET is interpreted as by that
-function.
-
- If `NULL' is returned then an error has occured. Possible errors
-are `bfd_error_no_memory', `bfd_error_invalid_target' or `system_call'
-error.
-
-2.14.1.3 `bfd_fdopenr'
-......................
-
-*Synopsis*
- bfd *bfd_fdopenr (const char *filename, const char *target, int fd);
- *Description*
-`bfd_fdopenr' is to `bfd_fopenr' much like `fdopen' is to `fopen'. It
-opens a BFD on a file already described by the FD supplied.
-
- When the file is later `bfd_close'd, the file descriptor will be
-closed. If the caller desires that this file descriptor be cached by
-BFD (opened as needed, closed as needed to free descriptors for other
-opens), with the supplied FD used as an initial file descriptor (but
-subject to closure at any time), call bfd_set_cacheable(bfd, 1) on the
-returned BFD. The default is to assume no caching; the file descriptor
-will remain open until `bfd_close', and will not be affected by BFD
-operations on other files.
-
- Possible errors are `bfd_error_no_memory',
-`bfd_error_invalid_target' and `bfd_error_system_call'.
-
-2.14.1.4 `bfd_openstreamr'
-..........................
-
-*Synopsis*
- bfd *bfd_openstreamr (const char *, const char *, void *);
- *Description*
-Open a BFD for read access on an existing stdio stream. When the BFD
-is passed to `bfd_close', the stream will be closed.
-
-2.14.1.5 `bfd_openr_iovec'
-..........................
-
-*Synopsis*
- bfd *bfd_openr_iovec (const char *filename, const char *target,
- void *(*open_func) (struct bfd *nbfd,
- void *open_closure),
- void *open_closure,
- file_ptr (*pread_func) (struct bfd *nbfd,
- void *stream,
- void *buf,
- file_ptr nbytes,
- file_ptr offset),
- int (*close_func) (struct bfd *nbfd,
- void *stream),
- int (*stat_func) (struct bfd *abfd,
- void *stream,
- struct stat *sb));
- *Description*
-Create and return a BFD backed by a read-only STREAM. The STREAM is
-created using OPEN_FUNC, accessed using PREAD_FUNC and destroyed using
-CLOSE_FUNC.
-
- Calls `bfd_find_target', so TARGET is interpreted as by that
-function.
-
- Calls OPEN_FUNC (which can call `bfd_zalloc' and `bfd_get_filename')
-to obtain the read-only stream backing the BFD. OPEN_FUNC either
-succeeds returning the non-`NULL' STREAM, or fails returning `NULL'
-(setting `bfd_error').
-
- Calls PREAD_FUNC to request NBYTES of data from STREAM starting at
-OFFSET (e.g., via a call to `bfd_read'). PREAD_FUNC either succeeds
-returning the number of bytes read (which can be less than NBYTES when
-end-of-file), or fails returning -1 (setting `bfd_error').
-
- Calls CLOSE_FUNC when the BFD is later closed using `bfd_close'.
-CLOSE_FUNC either succeeds returning 0, or fails returning -1 (setting
-`bfd_error').
-
- Calls STAT_FUNC to fill in a stat structure for bfd_stat,
-bfd_get_size, and bfd_get_mtime calls. STAT_FUNC returns 0 on success,
-or returns -1 on failure (setting `bfd_error').
-
- If `bfd_openr_iovec' returns `NULL' then an error has occurred.
-Possible errors are `bfd_error_no_memory', `bfd_error_invalid_target'
-and `bfd_error_system_call'.
-
-2.14.1.6 `bfd_openw'
-....................
-
-*Synopsis*
- bfd *bfd_openw (const char *filename, const char *target);
- *Description*
-Create a BFD, associated with file FILENAME, using the file format
-TARGET, and return a pointer to it.
-
- Possible errors are `bfd_error_system_call', `bfd_error_no_memory',
-`bfd_error_invalid_target'.
-
-2.14.1.7 `bfd_close'
-....................
-
-*Synopsis*
- bfd_boolean bfd_close (bfd *abfd);
- *Description*
-Close a BFD. If the BFD was open for writing, then pending operations
-are completed and the file written out and closed. If the created file
-is executable, then `chmod' is called to mark it as such.
-
- All memory attached to the BFD is released.
-
- The file descriptor associated with the BFD is closed (even if it
-was passed in to BFD by `bfd_fdopenr').
-
- *Returns*
-`TRUE' is returned if all is ok, otherwise `FALSE'.
-
-2.14.1.8 `bfd_close_all_done'
-.............................
-
-*Synopsis*
- bfd_boolean bfd_close_all_done (bfd *);
- *Description*
-Close a BFD. Differs from `bfd_close' since it does not complete any
-pending operations. This routine would be used if the application had
-just used BFD for swapping and didn't want to use any of the writing
-code.
-
- If the created file is executable, then `chmod' is called to mark it
-as such.
-
- All memory attached to the BFD is released.
-
- *Returns*
-`TRUE' is returned if all is ok, otherwise `FALSE'.
-
-2.14.1.9 `bfd_create'
-.....................
-
-*Synopsis*
- bfd *bfd_create (const char *filename, bfd *templ);
- *Description*
-Create a new BFD in the manner of `bfd_openw', but without opening a
-file. The new BFD takes the target from the target used by TEMPL. The
-format is always set to `bfd_object'.
-
-2.14.1.10 `bfd_make_writable'
-.............................
-
-*Synopsis*
- bfd_boolean bfd_make_writable (bfd *abfd);
- *Description*
-Takes a BFD as created by `bfd_create' and converts it into one like as
-returned by `bfd_openw'. It does this by converting the BFD to
-BFD_IN_MEMORY. It's assumed that you will call `bfd_make_readable' on
-this bfd later.
-
- *Returns*
-`TRUE' is returned if all is ok, otherwise `FALSE'.
-
-2.14.1.11 `bfd_make_readable'
-.............................
-
-*Synopsis*
- bfd_boolean bfd_make_readable (bfd *abfd);
- *Description*
-Takes a BFD as created by `bfd_create' and `bfd_make_writable' and
-converts it into one like as returned by `bfd_openr'. It does this by
-writing the contents out to the memory buffer, then reversing the
-direction.
-
- *Returns*
-`TRUE' is returned if all is ok, otherwise `FALSE'.
-
-2.14.1.12 `bfd_alloc'
-.....................
-
-*Synopsis*
- void *bfd_alloc (bfd *abfd, bfd_size_type wanted);
- *Description*
-Allocate a block of WANTED bytes of memory attached to `abfd' and
-return a pointer to it.
-
-2.14.1.13 `bfd_alloc2'
-......................
-
-*Synopsis*
- void *bfd_alloc2 (bfd *abfd, bfd_size_type nmemb, bfd_size_type size);
- *Description*
-Allocate a block of NMEMB elements of SIZE bytes each of memory
-attached to `abfd' and return a pointer to it.
-
-2.14.1.14 `bfd_zalloc'
-......................
-
-*Synopsis*
- void *bfd_zalloc (bfd *abfd, bfd_size_type wanted);
- *Description*
-Allocate a block of WANTED bytes of zeroed memory attached to `abfd'
-and return a pointer to it.
-
-2.14.1.15 `bfd_zalloc2'
-.......................
-
-*Synopsis*
- void *bfd_zalloc2 (bfd *abfd, bfd_size_type nmemb, bfd_size_type size);
- *Description*
-Allocate a block of NMEMB elements of SIZE bytes each of zeroed memory
-attached to `abfd' and return a pointer to it.
-
-2.14.1.16 `bfd_calc_gnu_debuglink_crc32'
-........................................
-
-*Synopsis*
- unsigned long bfd_calc_gnu_debuglink_crc32
- (unsigned long crc, const unsigned char *buf, bfd_size_type len);
- *Description*
-Computes a CRC value as used in the .gnu_debuglink section. Advances
-the previously computed CRC value by computing and adding in the crc32
-for LEN bytes of BUF.
-
- *Returns*
-Return the updated CRC32 value.
-
-2.14.1.17 `get_debug_link_info'
-...............................
-
-*Synopsis*
- char *get_debug_link_info (bfd *abfd, unsigned long *crc32_out);
- *Description*
-fetch the filename and CRC32 value for any separate debuginfo
-associated with ABFD. Return NULL if no such info found, otherwise
-return filename and update CRC32_OUT.
-
-2.14.1.18 `separate_debug_file_exists'
-......................................
-
-*Synopsis*
- bfd_boolean separate_debug_file_exists
- (char *name, unsigned long crc32);
- *Description*
-Checks to see if NAME is a file and if its contents match CRC32.
-
-2.14.1.19 `find_separate_debug_file'
-....................................
-
-*Synopsis*
- char *find_separate_debug_file (bfd *abfd);
- *Description*
-Searches ABFD for a reference to separate debugging information, scans
-various locations in the filesystem, including the file tree rooted at
-DEBUG_FILE_DIRECTORY, and returns a filename of such debugging
-information if the file is found and has matching CRC32. Returns NULL
-if no reference to debugging file exists, or file cannot be found.
-
-2.14.1.20 `bfd_follow_gnu_debuglink'
-....................................
-
-*Synopsis*
- char *bfd_follow_gnu_debuglink (bfd *abfd, const char *dir);
- *Description*
-Takes a BFD and searches it for a .gnu_debuglink section. If this
-section is found, it examines the section for the name and checksum of
-a '.debug' file containing auxiliary debugging information. It then
-searches the filesystem for this .debug file in some standard
-locations, including the directory tree rooted at DIR, and if found
-returns the full filename.
-
- If DIR is NULL, it will search a default path configured into libbfd
-at build time. [XXX this feature is not currently implemented].
-
- *Returns*
-`NULL' on any errors or failure to locate the .debug file, otherwise a
-pointer to a heap-allocated string containing the filename. The caller
-is responsible for freeing this string.
-
-2.14.1.21 `bfd_create_gnu_debuglink_section'
-............................................
-
-*Synopsis*
- struct bfd_section *bfd_create_gnu_debuglink_section
- (bfd *abfd, const char *filename);
- *Description*
-Takes a BFD and adds a .gnu_debuglink section to it. The section is
-sized to be big enough to contain a link to the specified FILENAME.
-
- *Returns*
-A pointer to the new section is returned if all is ok. Otherwise
-`NULL' is returned and bfd_error is set.
-
-2.14.1.22 `bfd_fill_in_gnu_debuglink_section'
-.............................................
-
-*Synopsis*
- bfd_boolean bfd_fill_in_gnu_debuglink_section
- (bfd *abfd, struct bfd_section *sect, const char *filename);
- *Description*
-Takes a BFD and containing a .gnu_debuglink section SECT and fills in
-the contents of the section to contain a link to the specified
-FILENAME. The filename should be relative to the current directory.
-
- *Returns*
-`TRUE' is returned if all is ok. Otherwise `FALSE' is returned and
-bfd_error is set.
-
-
-File: bfd.info, Node: Internal, Next: File Caching, Prev: Opening and Closing, Up: BFD front end
-
-2.15 Implementation details
-===========================
-
-2.15.1 Internal functions
--------------------------
-
-*Description*
-These routines are used within BFD. They are not intended for export,
-but are documented here for completeness.
-
-2.15.1.1 `bfd_write_bigendian_4byte_int'
-........................................
-
-*Synopsis*
- bfd_boolean bfd_write_bigendian_4byte_int (bfd *, unsigned int);
- *Description*
-Write a 4 byte integer I to the output BFD ABFD, in big endian order
-regardless of what else is going on. This is useful in archives.
-
-2.15.1.2 `bfd_put_size'
-.......................
-
-2.15.1.3 `bfd_get_size'
-.......................
-
-*Description*
-These macros as used for reading and writing raw data in sections; each
-access (except for bytes) is vectored through the target format of the
-BFD and mangled accordingly. The mangling performs any necessary endian
-translations and removes alignment restrictions. Note that types
-accepted and returned by these macros are identical so they can be
-swapped around in macros--for example, `libaout.h' defines `GET_WORD'
-to either `bfd_get_32' or `bfd_get_64'.
-
- In the put routines, VAL must be a `bfd_vma'. If we are on a system
-without prototypes, the caller is responsible for making sure that is
-true, with a cast if necessary. We don't cast them in the macro
-definitions because that would prevent `lint' or `gcc -Wall' from
-detecting sins such as passing a pointer. To detect calling these with
-less than a `bfd_vma', use `gcc -Wconversion' on a host with 64 bit
-`bfd_vma''s.
-
- /* Byte swapping macros for user section data. */
-
- #define bfd_put_8(abfd, val, ptr) \
- ((void) (*((unsigned char *) (ptr)) = (val) & 0xff))
- #define bfd_put_signed_8 \
- bfd_put_8
- #define bfd_get_8(abfd, ptr) \
- (*(unsigned char *) (ptr) & 0xff)
- #define bfd_get_signed_8(abfd, ptr) \
- (((*(unsigned char *) (ptr) & 0xff) ^ 0x80) - 0x80)
-
- #define bfd_put_16(abfd, val, ptr) \
- BFD_SEND (abfd, bfd_putx16, ((val),(ptr)))
- #define bfd_put_signed_16 \
- bfd_put_16
- #define bfd_get_16(abfd, ptr) \
- BFD_SEND (abfd, bfd_getx16, (ptr))
- #define bfd_get_signed_16(abfd, ptr) \
- BFD_SEND (abfd, bfd_getx_signed_16, (ptr))
-
- #define bfd_put_32(abfd, val, ptr) \
- BFD_SEND (abfd, bfd_putx32, ((val),(ptr)))
- #define bfd_put_signed_32 \
- bfd_put_32
- #define bfd_get_32(abfd, ptr) \
- BFD_SEND (abfd, bfd_getx32, (ptr))
- #define bfd_get_signed_32(abfd, ptr) \
- BFD_SEND (abfd, bfd_getx_signed_32, (ptr))
-
- #define bfd_put_64(abfd, val, ptr) \
- BFD_SEND (abfd, bfd_putx64, ((val), (ptr)))
- #define bfd_put_signed_64 \
- bfd_put_64
- #define bfd_get_64(abfd, ptr) \
- BFD_SEND (abfd, bfd_getx64, (ptr))
- #define bfd_get_signed_64(abfd, ptr) \
- BFD_SEND (abfd, bfd_getx_signed_64, (ptr))
-
- #define bfd_get(bits, abfd, ptr) \
- ((bits) == 8 ? (bfd_vma) bfd_get_8 (abfd, ptr) \
- : (bits) == 16 ? bfd_get_16 (abfd, ptr) \
- : (bits) == 32 ? bfd_get_32 (abfd, ptr) \
- : (bits) == 64 ? bfd_get_64 (abfd, ptr) \
- : (abort (), (bfd_vma) - 1))
-
- #define bfd_put(bits, abfd, val, ptr) \
- ((bits) == 8 ? bfd_put_8 (abfd, val, ptr) \
- : (bits) == 16 ? bfd_put_16 (abfd, val, ptr) \
- : (bits) == 32 ? bfd_put_32 (abfd, val, ptr) \
- : (bits) == 64 ? bfd_put_64 (abfd, val, ptr) \
- : (abort (), (void) 0))
-
-2.15.1.4 `bfd_h_put_size'
-.........................
-
-*Description*
-These macros have the same function as their `bfd_get_x' brethren,
-except that they are used for removing information for the header
-records of object files. Believe it or not, some object files keep
-their header records in big endian order and their data in little
-endian order.
-
- /* Byte swapping macros for file header data. */
-
- #define bfd_h_put_8(abfd, val, ptr) \
- bfd_put_8 (abfd, val, ptr)
- #define bfd_h_put_signed_8(abfd, val, ptr) \
- bfd_put_8 (abfd, val, ptr)
- #define bfd_h_get_8(abfd, ptr) \
- bfd_get_8 (abfd, ptr)
- #define bfd_h_get_signed_8(abfd, ptr) \
- bfd_get_signed_8 (abfd, ptr)
-
- #define bfd_h_put_16(abfd, val, ptr) \
- BFD_SEND (abfd, bfd_h_putx16, (val, ptr))
- #define bfd_h_put_signed_16 \
- bfd_h_put_16
- #define bfd_h_get_16(abfd, ptr) \
- BFD_SEND (abfd, bfd_h_getx16, (ptr))
- #define bfd_h_get_signed_16(abfd, ptr) \
- BFD_SEND (abfd, bfd_h_getx_signed_16, (ptr))
-
- #define bfd_h_put_32(abfd, val, ptr) \
- BFD_SEND (abfd, bfd_h_putx32, (val, ptr))
- #define bfd_h_put_signed_32 \
- bfd_h_put_32
- #define bfd_h_get_32(abfd, ptr) \
- BFD_SEND (abfd, bfd_h_getx32, (ptr))
- #define bfd_h_get_signed_32(abfd, ptr) \
- BFD_SEND (abfd, bfd_h_getx_signed_32, (ptr))
-
- #define bfd_h_put_64(abfd, val, ptr) \
- BFD_SEND (abfd, bfd_h_putx64, (val, ptr))
- #define bfd_h_put_signed_64 \
- bfd_h_put_64
- #define bfd_h_get_64(abfd, ptr) \
- BFD_SEND (abfd, bfd_h_getx64, (ptr))
- #define bfd_h_get_signed_64(abfd, ptr) \
- BFD_SEND (abfd, bfd_h_getx_signed_64, (ptr))
-
- /* Aliases for the above, which should eventually go away. */
-
- #define H_PUT_64 bfd_h_put_64
- #define H_PUT_32 bfd_h_put_32
- #define H_PUT_16 bfd_h_put_16
- #define H_PUT_8 bfd_h_put_8
- #define H_PUT_S64 bfd_h_put_signed_64
- #define H_PUT_S32 bfd_h_put_signed_32
- #define H_PUT_S16 bfd_h_put_signed_16
- #define H_PUT_S8 bfd_h_put_signed_8
- #define H_GET_64 bfd_h_get_64
- #define H_GET_32 bfd_h_get_32
- #define H_GET_16 bfd_h_get_16
- #define H_GET_8 bfd_h_get_8
- #define H_GET_S64 bfd_h_get_signed_64
- #define H_GET_S32 bfd_h_get_signed_32
- #define H_GET_S16 bfd_h_get_signed_16
- #define H_GET_S8 bfd_h_get_signed_8
-
-2.15.1.5 `bfd_log2'
-...................
-
-*Synopsis*
- unsigned int bfd_log2 (bfd_vma x);
- *Description*
-Return the log base 2 of the value supplied, rounded up. E.g., an X of
-1025 returns 11. A X of 0 returns 0.
-
-
-File: bfd.info, Node: File Caching, Next: Linker Functions, Prev: Internal, Up: BFD front end
-
-2.16 File caching
-=================
-
-The file caching mechanism is embedded within BFD and allows the
-application to open as many BFDs as it wants without regard to the
-underlying operating system's file descriptor limit (often as low as 20
-open files). The module in `cache.c' maintains a least recently used
-list of `BFD_CACHE_MAX_OPEN' files, and exports the name
-`bfd_cache_lookup', which runs around and makes sure that the required
-BFD is open. If not, then it chooses a file to close, closes it and
-opens the one wanted, returning its file handle.
-
-2.16.1 Caching functions
-------------------------
-
-2.16.1.1 `bfd_cache_init'
-.........................
-
-*Synopsis*
- bfd_boolean bfd_cache_init (bfd *abfd);
- *Description*
-Add a newly opened BFD to the cache.
-
-2.16.1.2 `bfd_cache_close'
-..........................
-
-*Synopsis*
- bfd_boolean bfd_cache_close (bfd *abfd);
- *Description*
-Remove the BFD ABFD from the cache. If the attached file is open, then
-close it too.
-
- *Returns*
-`FALSE' is returned if closing the file fails, `TRUE' is returned if
-all is well.
-
-2.16.1.3 `bfd_cache_close_all'
-..............................
-
-*Synopsis*
- bfd_boolean bfd_cache_close_all (void);
- *Description*
-Remove all BFDs from the cache. If the attached file is open, then
-close it too.
-
- *Returns*
-`FALSE' is returned if closing one of the file fails, `TRUE' is
-returned if all is well.
-
-2.16.1.4 `bfd_open_file'
-........................
-
-*Synopsis*
- FILE* bfd_open_file (bfd *abfd);
- *Description*
-Call the OS to open a file for ABFD. Return the `FILE *' (possibly
-`NULL') that results from this operation. Set up the BFD so that
-future accesses know the file is open. If the `FILE *' returned is
-`NULL', then it won't have been put in the cache, so it won't have to
-be removed from it.
-
-
-File: bfd.info, Node: Linker Functions, Next: Hash Tables, Prev: File Caching, Up: BFD front end
-
-2.17 Linker Functions
-=====================
-
-The linker uses three special entry points in the BFD target vector.
-It is not necessary to write special routines for these entry points
-when creating a new BFD back end, since generic versions are provided.
-However, writing them can speed up linking and make it use
-significantly less runtime memory.
-
- The first routine creates a hash table used by the other routines.
-The second routine adds the symbols from an object file to the hash
-table. The third routine takes all the object files and links them
-together to create the output file. These routines are designed so
-that the linker proper does not need to know anything about the symbols
-in the object files that it is linking. The linker merely arranges the
-sections as directed by the linker script and lets BFD handle the
-details of symbols and relocs.
-
- The second routine and third routines are passed a pointer to a
-`struct bfd_link_info' structure (defined in `bfdlink.h') which holds
-information relevant to the link, including the linker hash table
-(which was created by the first routine) and a set of callback
-functions to the linker proper.
-
- The generic linker routines are in `linker.c', and use the header
-file `genlink.h'. As of this writing, the only back ends which have
-implemented versions of these routines are a.out (in `aoutx.h') and
-ECOFF (in `ecoff.c'). The a.out routines are used as examples
-throughout this section.
-
-* Menu:
-
-* Creating a Linker Hash Table::
-* Adding Symbols to the Hash Table::
-* Performing the Final Link::
-
-
-File: bfd.info, Node: Creating a Linker Hash Table, Next: Adding Symbols to the Hash Table, Prev: Linker Functions, Up: Linker Functions
-
-2.17.1 Creating a linker hash table
------------------------------------
-
-The linker routines must create a hash table, which must be derived
-from `struct bfd_link_hash_table' described in `bfdlink.c'. *Note Hash
-Tables::, for information on how to create a derived hash table. This
-entry point is called using the target vector of the linker output file.
-
- The `_bfd_link_hash_table_create' entry point must allocate and
-initialize an instance of the desired hash table. If the back end does
-not require any additional information to be stored with the entries in
-the hash table, the entry point may simply create a `struct
-bfd_link_hash_table'. Most likely, however, some additional
-information will be needed.
-
- For example, with each entry in the hash table the a.out linker
-keeps the index the symbol has in the final output file (this index
-number is used so that when doing a relocatable link the symbol index
-used in the output file can be quickly filled in when copying over a
-reloc). The a.out linker code defines the required structures and
-functions for a hash table derived from `struct bfd_link_hash_table'.
-The a.out linker hash table is created by the function
-`NAME(aout,link_hash_table_create)'; it simply allocates space for the
-hash table, initializes it, and returns a pointer to it.
-
- When writing the linker routines for a new back end, you will
-generally not know exactly which fields will be required until you have
-finished. You should simply create a new hash table which defines no
-additional fields, and then simply add fields as they become necessary.
-
-
-File: bfd.info, Node: Adding Symbols to the Hash Table, Next: Performing the Final Link, Prev: Creating a Linker Hash Table, Up: Linker Functions
-
-2.17.2 Adding symbols to the hash table
----------------------------------------
-
-The linker proper will call the `_bfd_link_add_symbols' entry point for
-each object file or archive which is to be linked (typically these are
-the files named on the command line, but some may also come from the
-linker script). The entry point is responsible for examining the file.
-For an object file, BFD must add any relevant symbol information to the
-hash table. For an archive, BFD must determine which elements of the
-archive should be used and adding them to the link.
-
- The a.out version of this entry point is
-`NAME(aout,link_add_symbols)'.
-
-* Menu:
-
-* Differing file formats::
-* Adding symbols from an object file::
-* Adding symbols from an archive::
-
-
-File: bfd.info, Node: Differing file formats, Next: Adding symbols from an object file, Prev: Adding Symbols to the Hash Table, Up: Adding Symbols to the Hash Table
-
-2.17.2.1 Differing file formats
-...............................
-
-Normally all the files involved in a link will be of the same format,
-but it is also possible to link together different format object files,
-and the back end must support that. The `_bfd_link_add_symbols' entry
-point is called via the target vector of the file to be added. This
-has an important consequence: the function may not assume that the hash
-table is the type created by the corresponding
-`_bfd_link_hash_table_create' vector. All the `_bfd_link_add_symbols'
-function can assume about the hash table is that it is derived from
-`struct bfd_link_hash_table'.
-
- Sometimes the `_bfd_link_add_symbols' function must store some
-information in the hash table entry to be used by the `_bfd_final_link'
-function. In such a case the output bfd xvec must be checked to make
-sure that the hash table was created by an object file of the same
-format.
-
- The `_bfd_final_link' routine must be prepared to handle a hash
-entry without any extra information added by the
-`_bfd_link_add_symbols' function. A hash entry without extra
-information will also occur when the linker script directs the linker
-to create a symbol. Note that, regardless of how a hash table entry is
-added, all the fields will be initialized to some sort of null value by
-the hash table entry initialization function.
-
- See `ecoff_link_add_externals' for an example of how to check the
-output bfd before saving information (in this case, the ECOFF external
-symbol debugging information) in a hash table entry.
-
-
-File: bfd.info, Node: Adding symbols from an object file, Next: Adding symbols from an archive, Prev: Differing file formats, Up: Adding Symbols to the Hash Table
-
-2.17.2.2 Adding symbols from an object file
-...........................................
-
-When the `_bfd_link_add_symbols' routine is passed an object file, it
-must add all externally visible symbols in that object file to the hash
-table. The actual work of adding the symbol to the hash table is
-normally handled by the function `_bfd_generic_link_add_one_symbol'.
-The `_bfd_link_add_symbols' routine is responsible for reading all the
-symbols from the object file and passing the correct information to
-`_bfd_generic_link_add_one_symbol'.
-
- The `_bfd_link_add_symbols' routine should not use
-`bfd_canonicalize_symtab' to read the symbols. The point of providing
-this routine is to avoid the overhead of converting the symbols into
-generic `asymbol' structures.
-
- `_bfd_generic_link_add_one_symbol' handles the details of combining
-common symbols, warning about multiple definitions, and so forth. It
-takes arguments which describe the symbol to add, notably symbol flags,
-a section, and an offset. The symbol flags include such things as
-`BSF_WEAK' or `BSF_INDIRECT'. The section is a section in the object
-file, or something like `bfd_und_section_ptr' for an undefined symbol
-or `bfd_com_section_ptr' for a common symbol.
-
- If the `_bfd_final_link' routine is also going to need to read the
-symbol information, the `_bfd_link_add_symbols' routine should save it
-somewhere attached to the object file BFD. However, the information
-should only be saved if the `keep_memory' field of the `info' argument
-is TRUE, so that the `-no-keep-memory' linker switch is effective.
-
- The a.out function which adds symbols from an object file is
-`aout_link_add_object_symbols', and most of the interesting work is in
-`aout_link_add_symbols'. The latter saves pointers to the hash tables
-entries created by `_bfd_generic_link_add_one_symbol' indexed by symbol
-number, so that the `_bfd_final_link' routine does not have to call the
-hash table lookup routine to locate the entry.
-
-
-File: bfd.info, Node: Adding symbols from an archive, Prev: Adding symbols from an object file, Up: Adding Symbols to the Hash Table
-
-2.17.2.3 Adding symbols from an archive
-.......................................
-
-When the `_bfd_link_add_symbols' routine is passed an archive, it must
-look through the symbols defined by the archive and decide which
-elements of the archive should be included in the link. For each such
-element it must call the `add_archive_element' linker callback, and it
-must add the symbols from the object file to the linker hash table.
-(The callback may in fact indicate that a replacement BFD should be
-used, in which case the symbols from that BFD should be added to the
-linker hash table instead.)
-
- In most cases the work of looking through the symbols in the archive
-should be done by the `_bfd_generic_link_add_archive_symbols' function.
-This function builds a hash table from the archive symbol table and
-looks through the list of undefined symbols to see which elements
-should be included. `_bfd_generic_link_add_archive_symbols' is passed
-a function to call to make the final decision about adding an archive
-element to the link and to do the actual work of adding the symbols to
-the linker hash table.
-
- The function passed to `_bfd_generic_link_add_archive_symbols' must
-read the symbols of the archive element and decide whether the archive
-element should be included in the link. If the element is to be
-included, the `add_archive_element' linker callback routine must be
-called with the element as an argument, and the element's symbols must
-be added to the linker hash table just as though the element had itself
-been passed to the `_bfd_link_add_symbols' function. The
-`add_archive_element' callback has the option to indicate that it would
-like to replace the element archive with a substitute BFD, in which
-case it is the symbols of that substitute BFD that must be added to the
-linker hash table instead.
-
- When the a.out `_bfd_link_add_symbols' function receives an archive,
-it calls `_bfd_generic_link_add_archive_symbols' passing
-`aout_link_check_archive_element' as the function argument.
-`aout_link_check_archive_element' calls `aout_link_check_ar_symbols'.
-If the latter decides to add the element (an element is only added if
-it provides a real, non-common, definition for a previously undefined
-or common symbol) it calls the `add_archive_element' callback and then
-`aout_link_check_archive_element' calls `aout_link_add_symbols' to
-actually add the symbols to the linker hash table - possibly those of a
-substitute BFD, if the `add_archive_element' callback avails itself of
-that option.
-
- The ECOFF back end is unusual in that it does not normally call
-`_bfd_generic_link_add_archive_symbols', because ECOFF archives already
-contain a hash table of symbols. The ECOFF back end searches the
-archive itself to avoid the overhead of creating a new hash table.
-
-
-File: bfd.info, Node: Performing the Final Link, Prev: Adding Symbols to the Hash Table, Up: Linker Functions
-
-2.17.3 Performing the final link
---------------------------------
-
-When all the input files have been processed, the linker calls the
-`_bfd_final_link' entry point of the output BFD. This routine is
-responsible for producing the final output file, which has several
-aspects. It must relocate the contents of the input sections and copy
-the data into the output sections. It must build an output symbol
-table including any local symbols from the input files and the global
-symbols from the hash table. When producing relocatable output, it must
-modify the input relocs and write them into the output file. There may
-also be object format dependent work to be done.
-
- The linker will also call the `write_object_contents' entry point
-when the BFD is closed. The two entry points must work together in
-order to produce the correct output file.
-
- The details of how this works are inevitably dependent upon the
-specific object file format. The a.out `_bfd_final_link' routine is
-`NAME(aout,final_link)'.
-
-* Menu:
-
-* Information provided by the linker::
-* Relocating the section contents::
-* Writing the symbol table::
-
-
-File: bfd.info, Node: Information provided by the linker, Next: Relocating the section contents, Prev: Performing the Final Link, Up: Performing the Final Link
-
-2.17.3.1 Information provided by the linker
-...........................................
-
-Before the linker calls the `_bfd_final_link' entry point, it sets up
-some data structures for the function to use.
-
- The `input_bfds' field of the `bfd_link_info' structure will point
-to a list of all the input files included in the link. These files are
-linked through the `link_next' field of the `bfd' structure.
-
- Each section in the output file will have a list of `link_order'
-structures attached to the `map_head.link_order' field (the
-`link_order' structure is defined in `bfdlink.h'). These structures
-describe how to create the contents of the output section in terms of
-the contents of various input sections, fill constants, and,
-eventually, other types of information. They also describe relocs that
-must be created by the BFD backend, but do not correspond to any input
-file; this is used to support -Ur, which builds constructors while
-generating a relocatable object file.
-
-
-File: bfd.info, Node: Relocating the section contents, Next: Writing the symbol table, Prev: Information provided by the linker, Up: Performing the Final Link
-
-2.17.3.2 Relocating the section contents
-........................................
-
-The `_bfd_final_link' function should look through the `link_order'
-structures attached to each section of the output file. Each
-`link_order' structure should either be handled specially, or it should
-be passed to the function `_bfd_default_link_order' which will do the
-right thing (`_bfd_default_link_order' is defined in `linker.c').
-
- For efficiency, a `link_order' of type `bfd_indirect_link_order'
-whose associated section belongs to a BFD of the same format as the
-output BFD must be handled specially. This type of `link_order'
-describes part of an output section in terms of a section belonging to
-one of the input files. The `_bfd_final_link' function should read the
-contents of the section and any associated relocs, apply the relocs to
-the section contents, and write out the modified section contents. If
-performing a relocatable link, the relocs themselves must also be
-modified and written out.
-
- The functions `_bfd_relocate_contents' and
-`_bfd_final_link_relocate' provide some general support for performing
-the actual relocations, notably overflow checking. Their arguments
-include information about the symbol the relocation is against and a
-`reloc_howto_type' argument which describes the relocation to perform.
-These functions are defined in `reloc.c'.
-
- The a.out function which handles reading, relocating, and writing
-section contents is `aout_link_input_section'. The actual relocation
-is done in `aout_link_input_section_std' and
-`aout_link_input_section_ext'.
-
-
-File: bfd.info, Node: Writing the symbol table, Prev: Relocating the section contents, Up: Performing the Final Link
-
-2.17.3.3 Writing the symbol table
-.................................
-
-The `_bfd_final_link' function must gather all the symbols in the input
-files and write them out. It must also write out all the symbols in
-the global hash table. This must be controlled by the `strip' and
-`discard' fields of the `bfd_link_info' structure.
-
- The local symbols of the input files will not have been entered into
-the linker hash table. The `_bfd_final_link' routine must consider
-each input file and include the symbols in the output file. It may be
-convenient to do this when looking through the `link_order' structures,
-or it may be done by stepping through the `input_bfds' list.
-
- The `_bfd_final_link' routine must also traverse the global hash
-table to gather all the externally visible symbols. It is possible
-that most of the externally visible symbols may be written out when
-considering the symbols of each input file, but it is still necessary
-to traverse the hash table since the linker script may have defined
-some symbols that are not in any of the input files.
-
- The `strip' field of the `bfd_link_info' structure controls which
-symbols are written out. The possible values are listed in
-`bfdlink.h'. If the value is `strip_some', then the `keep_hash' field
-of the `bfd_link_info' structure is a hash table of symbols to keep;
-each symbol should be looked up in this hash table, and only symbols
-which are present should be included in the output file.
-
- If the `strip' field of the `bfd_link_info' structure permits local
-symbols to be written out, the `discard' field is used to further
-controls which local symbols are included in the output file. If the
-value is `discard_l', then all local symbols which begin with a certain
-prefix are discarded; this is controlled by the
-`bfd_is_local_label_name' entry point.
-
- The a.out backend handles symbols by calling
-`aout_link_write_symbols' on each input BFD and then traversing the
-global hash table with the function `aout_link_write_other_symbol'. It
-builds a string table while writing out the symbols, which is written
-to the output file at the end of `NAME(aout,final_link)'.
-
-2.17.3.4 `bfd_link_split_section'
-.................................
-
-*Synopsis*
- bfd_boolean bfd_link_split_section (bfd *abfd, asection *sec);
- *Description*
-Return nonzero if SEC should be split during a reloceatable or final
-link.
- #define bfd_link_split_section(abfd, sec) \
- BFD_SEND (abfd, _bfd_link_split_section, (abfd, sec))
-
-2.17.3.5 `bfd_section_already_linked'
-.....................................
-
-*Synopsis*
- void bfd_section_already_linked (bfd *abfd, asection *sec,
- struct bfd_link_info *info);
- *Description*
-Check if SEC has been already linked during a reloceatable or final
-link.
- #define bfd_section_already_linked(abfd, sec, info) \
- BFD_SEND (abfd, _section_already_linked, (abfd, sec, info))
-
-2.17.3.6 `bfd_generic_define_common_symbol'
-...........................................
-
-*Synopsis*
- bfd_boolean bfd_generic_define_common_symbol
- (bfd *output_bfd, struct bfd_link_info *info,
- struct bfd_link_hash_entry *h);
- *Description*
-Convert common symbol H into a defined symbol. Return TRUE on success
-and FALSE on failure.
- #define bfd_define_common_symbol(output_bfd, info, h) \
- BFD_SEND (output_bfd, _bfd_define_common_symbol, (output_bfd, info, h))
-
-2.17.3.7 `bfd_find_version_for_sym '
-....................................
-
-*Synopsis*
- struct bfd_elf_version_tree * bfd_find_version_for_sym
- (struct bfd_elf_version_tree *verdefs,
- const char *sym_name, bfd_boolean *hide);
- *Description*
-Search an elf version script tree for symbol versioning info and export
-/ don't-export status for a given symbol. Return non-NULL on success
-and NULL on failure; also sets the output `hide' boolean parameter.
-
-
-File: bfd.info, Node: Hash Tables, Prev: Linker Functions, Up: BFD front end
-
-2.18 Hash Tables
-================
-
-BFD provides a simple set of hash table functions. Routines are
-provided to initialize a hash table, to free a hash table, to look up a
-string in a hash table and optionally create an entry for it, and to
-traverse a hash table. There is currently no routine to delete an
-string from a hash table.
-
- The basic hash table does not permit any data to be stored with a
-string. However, a hash table is designed to present a base class from
-which other types of hash tables may be derived. These derived types
-may store additional information with the string. Hash tables were
-implemented in this way, rather than simply providing a data pointer in
-a hash table entry, because they were designed for use by the linker
-back ends. The linker may create thousands of hash table entries, and
-the overhead of allocating private data and storing and following
-pointers becomes noticeable.
-
- The basic hash table code is in `hash.c'.
-
-* Menu:
-
-* Creating and Freeing a Hash Table::
-* Looking Up or Entering a String::
-* Traversing a Hash Table::
-* Deriving a New Hash Table Type::
-
-
-File: bfd.info, Node: Creating and Freeing a Hash Table, Next: Looking Up or Entering a String, Prev: Hash Tables, Up: Hash Tables
-
-2.18.1 Creating and freeing a hash table
-----------------------------------------
-
-To create a hash table, create an instance of a `struct bfd_hash_table'
-(defined in `bfd.h') and call `bfd_hash_table_init' (if you know
-approximately how many entries you will need, the function
-`bfd_hash_table_init_n', which takes a SIZE argument, may be used).
-`bfd_hash_table_init' returns `FALSE' if some sort of error occurs.
-
- The function `bfd_hash_table_init' take as an argument a function to
-use to create new entries. For a basic hash table, use the function
-`bfd_hash_newfunc'. *Note Deriving a New Hash Table Type::, for why
-you would want to use a different value for this argument.
-
- `bfd_hash_table_init' will create an objalloc which will be used to
-allocate new entries. You may allocate memory on this objalloc using
-`bfd_hash_allocate'.
-
- Use `bfd_hash_table_free' to free up all the memory that has been
-allocated for a hash table. This will not free up the `struct
-bfd_hash_table' itself, which you must provide.
-
- Use `bfd_hash_set_default_size' to set the default size of hash
-table to use.
-
-
-File: bfd.info, Node: Looking Up or Entering a String, Next: Traversing a Hash Table, Prev: Creating and Freeing a Hash Table, Up: Hash Tables
-
-2.18.2 Looking up or entering a string
---------------------------------------
-
-The function `bfd_hash_lookup' is used both to look up a string in the
-hash table and to create a new entry.
-
- If the CREATE argument is `FALSE', `bfd_hash_lookup' will look up a
-string. If the string is found, it will returns a pointer to a `struct
-bfd_hash_entry'. If the string is not found in the table
-`bfd_hash_lookup' will return `NULL'. You should not modify any of the
-fields in the returns `struct bfd_hash_entry'.
-
- If the CREATE argument is `TRUE', the string will be entered into
-the hash table if it is not already there. Either way a pointer to a
-`struct bfd_hash_entry' will be returned, either to the existing
-structure or to a newly created one. In this case, a `NULL' return
-means that an error occurred.
-
- If the CREATE argument is `TRUE', and a new entry is created, the
-COPY argument is used to decide whether to copy the string onto the
-hash table objalloc or not. If COPY is passed as `FALSE', you must be
-careful not to deallocate or modify the string as long as the hash table
-exists.
-
-
-File: bfd.info, Node: Traversing a Hash Table, Next: Deriving a New Hash Table Type, Prev: Looking Up or Entering a String, Up: Hash Tables
-
-2.18.3 Traversing a hash table
-------------------------------
-
-The function `bfd_hash_traverse' may be used to traverse a hash table,
-calling a function on each element. The traversal is done in a random
-order.
-
- `bfd_hash_traverse' takes as arguments a function and a generic
-`void *' pointer. The function is called with a hash table entry (a
-`struct bfd_hash_entry *') and the generic pointer passed to
-`bfd_hash_traverse'. The function must return a `boolean' value, which
-indicates whether to continue traversing the hash table. If the
-function returns `FALSE', `bfd_hash_traverse' will stop the traversal
-and return immediately.
-
-
-File: bfd.info, Node: Deriving a New Hash Table Type, Prev: Traversing a Hash Table, Up: Hash Tables
-
-2.18.4 Deriving a new hash table type
--------------------------------------
-
-Many uses of hash tables want to store additional information which
-each entry in the hash table. Some also find it convenient to store
-additional information with the hash table itself. This may be done
-using a derived hash table.
-
- Since C is not an object oriented language, creating a derived hash
-table requires sticking together some boilerplate routines with a few
-differences specific to the type of hash table you want to create.
-
- An example of a derived hash table is the linker hash table. The
-structures for this are defined in `bfdlink.h'. The functions are in
-`linker.c'.
-
- You may also derive a hash table from an already derived hash table.
-For example, the a.out linker backend code uses a hash table derived
-from the linker hash table.
-
-* Menu:
-
-* Define the Derived Structures::
-* Write the Derived Creation Routine::
-* Write Other Derived Routines::
-
-
-File: bfd.info, Node: Define the Derived Structures, Next: Write the Derived Creation Routine, Prev: Deriving a New Hash Table Type, Up: Deriving a New Hash Table Type
-
-2.18.4.1 Define the derived structures
-......................................
-
-You must define a structure for an entry in the hash table, and a
-structure for the hash table itself.
-
- The first field in the structure for an entry in the hash table must
-be of the type used for an entry in the hash table you are deriving
-from. If you are deriving from a basic hash table this is `struct
-bfd_hash_entry', which is defined in `bfd.h'. The first field in the
-structure for the hash table itself must be of the type of the hash
-table you are deriving from itself. If you are deriving from a basic
-hash table, this is `struct bfd_hash_table'.
-
- For example, the linker hash table defines `struct
-bfd_link_hash_entry' (in `bfdlink.h'). The first field, `root', is of
-type `struct bfd_hash_entry'. Similarly, the first field in `struct
-bfd_link_hash_table', `table', is of type `struct bfd_hash_table'.
-
-
-File: bfd.info, Node: Write the Derived Creation Routine, Next: Write Other Derived Routines, Prev: Define the Derived Structures, Up: Deriving a New Hash Table Type
-
-2.18.4.2 Write the derived creation routine
-...........................................
-
-You must write a routine which will create and initialize an entry in
-the hash table. This routine is passed as the function argument to
-`bfd_hash_table_init'.
-
- In order to permit other hash tables to be derived from the hash
-table you are creating, this routine must be written in a standard way.
-
- The first argument to the creation routine is a pointer to a hash
-table entry. This may be `NULL', in which case the routine should
-allocate the right amount of space. Otherwise the space has already
-been allocated by a hash table type derived from this one.
-
- After allocating space, the creation routine must call the creation
-routine of the hash table type it is derived from, passing in a pointer
-to the space it just allocated. This will initialize any fields used
-by the base hash table.
-
- Finally the creation routine must initialize any local fields for
-the new hash table type.
-
- Here is a boilerplate example of a creation routine. FUNCTION_NAME
-is the name of the routine. ENTRY_TYPE is the type of an entry in the
-hash table you are creating. BASE_NEWFUNC is the name of the creation
-routine of the hash table type your hash table is derived from.
-
- struct bfd_hash_entry *
- FUNCTION_NAME (struct bfd_hash_entry *entry,
- struct bfd_hash_table *table,
- const char *string)
- {
- struct ENTRY_TYPE *ret = (ENTRY_TYPE *) entry;
-
- /* Allocate the structure if it has not already been allocated by a
- derived class. */
- if (ret == NULL)
- {
- ret = bfd_hash_allocate (table, sizeof (* ret));
- if (ret == NULL)
- return NULL;
- }
-
- /* Call the allocation method of the base class. */
- ret = ((ENTRY_TYPE *)
- BASE_NEWFUNC ((struct bfd_hash_entry *) ret, table, string));
-
- /* Initialize the local fields here. */
-
- return (struct bfd_hash_entry *) ret;
- }
- *Description*
-The creation routine for the linker hash table, which is in `linker.c',
-looks just like this example. FUNCTION_NAME is
-`_bfd_link_hash_newfunc'. ENTRY_TYPE is `struct bfd_link_hash_entry'.
-BASE_NEWFUNC is `bfd_hash_newfunc', the creation routine for a basic
-hash table.
-
- `_bfd_link_hash_newfunc' also initializes the local fields in a
-linker hash table entry: `type', `written' and `next'.
-
-
-File: bfd.info, Node: Write Other Derived Routines, Prev: Write the Derived Creation Routine, Up: Deriving a New Hash Table Type
-
-2.18.4.3 Write other derived routines
-.....................................
-
-You will want to write other routines for your new hash table, as well.
-
- You will want an initialization routine which calls the
-initialization routine of the hash table you are deriving from and
-initializes any other local fields. For the linker hash table, this is
-`_bfd_link_hash_table_init' in `linker.c'.
-
- You will want a lookup routine which calls the lookup routine of the
-hash table you are deriving from and casts the result. The linker hash
-table uses `bfd_link_hash_lookup' in `linker.c' (this actually takes an
-additional argument which it uses to decide how to return the looked up
-value).
-
- You may want a traversal routine. This should just call the
-traversal routine of the hash table you are deriving from with
-appropriate casts. The linker hash table uses `bfd_link_hash_traverse'
-in `linker.c'.
-
- These routines may simply be defined as macros. For example, the
-a.out backend linker hash table, which is derived from the linker hash
-table, uses macros for the lookup and traversal routines. These are
-`aout_link_hash_lookup' and `aout_link_hash_traverse' in aoutx.h.
-
-
-File: bfd.info, Node: BFD back ends, Next: GNU Free Documentation License, Prev: BFD front end, Up: Top
-
-3 BFD back ends
-***************
-
-* Menu:
-
-* What to Put Where::
-* aout :: a.out backends
-* coff :: coff backends
-* elf :: elf backends
-* mmo :: mmo backend
-
-
-File: bfd.info, Node: What to Put Where, Next: aout, Prev: BFD back ends, Up: BFD back ends
-
-3.1 What to Put Where
-=====================
-
-All of BFD lives in one directory.
-
-
-File: bfd.info, Node: aout, Next: coff, Prev: What to Put Where, Up: BFD back ends
-
-3.2 a.out backends
-==================
-
-*Description*
-BFD supports a number of different flavours of a.out format, though the
-major differences are only the sizes of the structures on disk, and the
-shape of the relocation information.
-
- The support is split into a basic support file `aoutx.h' and other
-files which derive functions from the base. One derivation file is
-`aoutf1.h' (for a.out flavour 1), and adds to the basic a.out functions
-support for sun3, sun4, 386 and 29k a.out files, to create a target
-jump vector for a specific target.
-
- This information is further split out into more specific files for
-each machine, including `sunos.c' for sun3 and sun4, `newsos3.c' for
-the Sony NEWS, and `demo64.c' for a demonstration of a 64 bit a.out
-format.
-
- The base file `aoutx.h' defines general mechanisms for reading and
-writing records to and from disk and various other methods which BFD
-requires. It is included by `aout32.c' and `aout64.c' to form the names
-`aout_32_swap_exec_header_in', `aout_64_swap_exec_header_in', etc.
-
- As an example, this is what goes on to make the back end for a sun4,
-from `aout32.c':
-
- #define ARCH_SIZE 32
- #include "aoutx.h"
-
- Which exports names:
-
- ...
- aout_32_canonicalize_reloc
- aout_32_find_nearest_line
- aout_32_get_lineno
- aout_32_get_reloc_upper_bound
- ...
-
- from `sunos.c':
-
- #define TARGET_NAME "a.out-sunos-big"
- #define VECNAME sunos_big_vec
- #include "aoutf1.h"
-
- requires all the names from `aout32.c', and produces the jump vector
-
- sunos_big_vec
-
- The file `host-aout.c' is a special case. It is for a large set of
-hosts that use "more or less standard" a.out files, and for which
-cross-debugging is not interesting. It uses the standard 32-bit a.out
-support routines, but determines the file offsets and addresses of the
-text, data, and BSS sections, the machine architecture and machine
-type, and the entry point address, in a host-dependent manner. Once
-these values have been determined, generic code is used to handle the
-object file.
-
- When porting it to run on a new system, you must supply:
-
- HOST_PAGE_SIZE
- HOST_SEGMENT_SIZE
- HOST_MACHINE_ARCH (optional)
- HOST_MACHINE_MACHINE (optional)
- HOST_TEXT_START_ADDR
- HOST_STACK_END_ADDR
-
- in the file `../include/sys/h-XXX.h' (for your host). These values,
-plus the structures and macros defined in `a.out.h' on your host
-system, will produce a BFD target that will access ordinary a.out files
-on your host. To configure a new machine to use `host-aout.c', specify:
-
- TDEFAULTS = -DDEFAULT_VECTOR=host_aout_big_vec
- TDEPFILES= host-aout.o trad-core.o
-
- in the `config/XXX.mt' file, and modify `configure.in' to use the
-`XXX.mt' file (by setting "`bfd_target=XXX'") when your configuration
-is selected.
-
-3.2.1 Relocations
------------------
-
-*Description*
-The file `aoutx.h' provides for both the _standard_ and _extended_
-forms of a.out relocation records.
-
- The standard records contain only an address, a symbol index, and a
-type field. The extended records (used on 29ks and sparcs) also have a
-full integer for an addend.
-
-3.2.2 Internal entry points
----------------------------
-
-*Description*
-`aoutx.h' exports several routines for accessing the contents of an
-a.out file, which are gathered and exported in turn by various format
-specific files (eg sunos.c).
-
-3.2.2.1 `aout_SIZE_swap_exec_header_in'
-.......................................
-
-*Synopsis*
- void aout_SIZE_swap_exec_header_in,
- (bfd *abfd,
- struct external_exec *bytes,
- struct internal_exec *execp);
- *Description*
-Swap the information in an executable header RAW_BYTES taken from a raw
-byte stream memory image into the internal exec header structure EXECP.
-
-3.2.2.2 `aout_SIZE_swap_exec_header_out'
-........................................
-
-*Synopsis*
- void aout_SIZE_swap_exec_header_out
- (bfd *abfd,
- struct internal_exec *execp,
- struct external_exec *raw_bytes);
- *Description*
-Swap the information in an internal exec header structure EXECP into
-the buffer RAW_BYTES ready for writing to disk.
-
-3.2.2.3 `aout_SIZE_some_aout_object_p'
-......................................
-
-*Synopsis*
- const bfd_target *aout_SIZE_some_aout_object_p
- (bfd *abfd,
- struct internal_exec *execp,
- const bfd_target *(*callback_to_real_object_p) (bfd *));
- *Description*
-Some a.out variant thinks that the file open in ABFD checking is an
-a.out file. Do some more checking, and set up for access if it really
-is. Call back to the calling environment's "finish up" function just
-before returning, to handle any last-minute setup.
-
-3.2.2.4 `aout_SIZE_mkobject'
-............................
-
-*Synopsis*
- bfd_boolean aout_SIZE_mkobject, (bfd *abfd);
- *Description*
-Initialize BFD ABFD for use with a.out files.
-
-3.2.2.5 `aout_SIZE_machine_type'
-................................
-
-*Synopsis*
- enum machine_type aout_SIZE_machine_type
- (enum bfd_architecture arch,
- unsigned long machine,
- bfd_boolean *unknown);
- *Description*
-Keep track of machine architecture and machine type for a.out's. Return
-the `machine_type' for a particular architecture and machine, or
-`M_UNKNOWN' if that exact architecture and machine can't be represented
-in a.out format.
-
- If the architecture is understood, machine type 0 (default) is
-always understood.
-
-3.2.2.6 `aout_SIZE_set_arch_mach'
-.................................
-
-*Synopsis*
- bfd_boolean aout_SIZE_set_arch_mach,
- (bfd *,
- enum bfd_architecture arch,
- unsigned long machine);
- *Description*
-Set the architecture and the machine of the BFD ABFD to the values ARCH
-and MACHINE. Verify that ABFD's format can support the architecture
-required.
-
-3.2.2.7 `aout_SIZE_new_section_hook'
-....................................
-
-*Synopsis*
- bfd_boolean aout_SIZE_new_section_hook,
- (bfd *abfd,
- asection *newsect);
- *Description*
-Called by the BFD in response to a `bfd_make_section' request.
-
-
-File: bfd.info, Node: coff, Next: elf, Prev: aout, Up: BFD back ends
-
-3.3 coff backends
-=================
-
-BFD supports a number of different flavours of coff format. The major
-differences between formats are the sizes and alignments of fields in
-structures on disk, and the occasional extra field.
-
- Coff in all its varieties is implemented with a few common files and
-a number of implementation specific files. For example, The 88k bcs
-coff format is implemented in the file `coff-m88k.c'. This file
-`#include's `coff/m88k.h' which defines the external structure of the
-coff format for the 88k, and `coff/internal.h' which defines the
-internal structure. `coff-m88k.c' also defines the relocations used by
-the 88k format *Note Relocations::.
-
- The Intel i960 processor version of coff is implemented in
-`coff-i960.c'. This file has the same structure as `coff-m88k.c',
-except that it includes `coff/i960.h' rather than `coff-m88k.h'.
-
-3.3.1 Porting to a new version of coff
---------------------------------------
-
-The recommended method is to select from the existing implementations
-the version of coff which is most like the one you want to use. For
-example, we'll say that i386 coff is the one you select, and that your
-coff flavour is called foo. Copy `i386coff.c' to `foocoff.c', copy
-`../include/coff/i386.h' to `../include/coff/foo.h', and add the lines
-to `targets.c' and `Makefile.in' so that your new back end is used.
-Alter the shapes of the structures in `../include/coff/foo.h' so that
-they match what you need. You will probably also have to add `#ifdef's
-to the code in `coff/internal.h' and `coffcode.h' if your version of
-coff is too wild.
-
- You can verify that your new BFD backend works quite simply by
-building `objdump' from the `binutils' directory, and making sure that
-its version of what's going on and your host system's idea (assuming it
-has the pretty standard coff dump utility, usually called `att-dump' or
-just `dump') are the same. Then clean up your code, and send what
-you've done to Cygnus. Then your stuff will be in the next release, and
-you won't have to keep integrating it.
-
-3.3.2 How the coff backend works
---------------------------------
-
-3.3.2.1 File layout
-...................
-
-The Coff backend is split into generic routines that are applicable to
-any Coff target and routines that are specific to a particular target.
-The target-specific routines are further split into ones which are
-basically the same for all Coff targets except that they use the
-external symbol format or use different values for certain constants.
-
- The generic routines are in `coffgen.c'. These routines work for
-any Coff target. They use some hooks into the target specific code;
-the hooks are in a `bfd_coff_backend_data' structure, one of which
-exists for each target.
-
- The essentially similar target-specific routines are in
-`coffcode.h'. This header file includes executable C code. The
-various Coff targets first include the appropriate Coff header file,
-make any special defines that are needed, and then include `coffcode.h'.
-
- Some of the Coff targets then also have additional routines in the
-target source file itself.
-
- For example, `coff-i960.c' includes `coff/internal.h' and
-`coff/i960.h'. It then defines a few constants, such as `I960', and
-includes `coffcode.h'. Since the i960 has complex relocation types,
-`coff-i960.c' also includes some code to manipulate the i960 relocs.
-This code is not in `coffcode.h' because it would not be used by any
-other target.
-
-3.3.2.2 Coff long section names
-...............................
-
-In the standard Coff object format, section names are limited to the
-eight bytes available in the `s_name' field of the `SCNHDR' section
-header structure. The format requires the field to be NUL-padded, but
-not necessarily NUL-terminated, so the longest section names permitted
-are a full eight characters.
-
- The Microsoft PE variants of the Coff object file format add an
-extension to support the use of long section names. This extension is
-defined in section 4 of the Microsoft PE/COFF specification (rev 8.1).
-If a section name is too long to fit into the section header's `s_name'
-field, it is instead placed into the string table, and the `s_name'
-field is filled with a slash ("/") followed by the ASCII decimal
-representation of the offset of the full name relative to the string
-table base.
-
- Note that this implies that the extension can only be used in object
-files, as executables do not contain a string table. The standard
-specifies that long section names from objects emitted into executable
-images are to be truncated.
-
- However, as a GNU extension, BFD can generate executable images that
-contain a string table and long section names. This would appear to be
-technically valid, as the standard only says that Coff debugging
-information is deprecated, not forbidden, and in practice it works,
-although some tools that parse PE files expecting the MS standard
-format may become confused; `PEview' is one known example.
-
- The functionality is supported in BFD by code implemented under the
-control of the macro `COFF_LONG_SECTION_NAMES'. If not defined, the
-format does not support long section names in any way. If defined, it
-is used to initialise a flag, `_bfd_coff_long_section_names', and a
-hook function pointer, `_bfd_coff_set_long_section_names', in the Coff
-backend data structure. The flag controls the generation of long
-section names in output BFDs at runtime; if it is false, as it will be
-by default when generating an executable image, long section names are
-truncated; if true, the long section names extension is employed. The
-hook points to a function that allows the value of the flag to be
-altered at runtime, on formats that support long section names at all;
-on other formats it points to a stub that returns an error indication.
-With input BFDs, the flag is set according to whether any long section
-names are detected while reading the section headers. For a completely
-new BFD, the flag is set to the default for the target format. This
-information can be used by a client of the BFD library when deciding
-what output format to generate, and means that a BFD that is opened for
-read and subsequently converted to a writeable BFD and modified
-in-place will retain whatever format it had on input.
-
- If `COFF_LONG_SECTION_NAMES' is simply defined (blank), or is
-defined to the value "1", then long section names are enabled by
-default; if it is defined to the value zero, they are disabled by
-default (but still accepted in input BFDs). The header `coffcode.h'
-defines a macro, `COFF_DEFAULT_LONG_SECTION_NAMES', which is used in
-the backends to initialise the backend data structure fields
-appropriately; see the comments for further detail.
-
-3.3.2.3 Bit twiddling
-.....................
-
-Each flavour of coff supported in BFD has its own header file
-describing the external layout of the structures. There is also an
-internal description of the coff layout, in `coff/internal.h'. A major
-function of the coff backend is swapping the bytes and twiddling the
-bits to translate the external form of the structures into the normal
-internal form. This is all performed in the `bfd_swap'_thing_direction
-routines. Some elements are different sizes between different versions
-of coff; it is the duty of the coff version specific include file to
-override the definitions of various packing routines in `coffcode.h'.
-E.g., the size of line number entry in coff is sometimes 16 bits, and
-sometimes 32 bits. `#define'ing `PUT_LNSZ_LNNO' and `GET_LNSZ_LNNO'
-will select the correct one. No doubt, some day someone will find a
-version of coff which has a varying field size not catered to at the
-moment. To port BFD, that person will have to add more `#defines'.
-Three of the bit twiddling routines are exported to `gdb';
-`coff_swap_aux_in', `coff_swap_sym_in' and `coff_swap_lineno_in'. `GDB'
-reads the symbol table on its own, but uses BFD to fix things up. More
-of the bit twiddlers are exported for `gas'; `coff_swap_aux_out',
-`coff_swap_sym_out', `coff_swap_lineno_out', `coff_swap_reloc_out',
-`coff_swap_filehdr_out', `coff_swap_aouthdr_out',
-`coff_swap_scnhdr_out'. `Gas' currently keeps track of all the symbol
-table and reloc drudgery itself, thereby saving the internal BFD
-overhead, but uses BFD to swap things on the way out, making cross
-ports much safer. Doing so also allows BFD (and thus the linker) to
-use the same header files as `gas', which makes one avenue to disaster
-disappear.
-
-3.3.2.4 Symbol reading
-......................
-
-The simple canonical form for symbols used by BFD is not rich enough to
-keep all the information available in a coff symbol table. The back end
-gets around this problem by keeping the original symbol table around,
-"behind the scenes".
-
- When a symbol table is requested (through a call to
-`bfd_canonicalize_symtab'), a request gets through to
-`coff_get_normalized_symtab'. This reads the symbol table from the coff
-file and swaps all the structures inside into the internal form. It
-also fixes up all the pointers in the table (represented in the file by
-offsets from the first symbol in the table) into physical pointers to
-elements in the new internal table. This involves some work since the
-meanings of fields change depending upon context: a field that is a
-pointer to another structure in the symbol table at one moment may be
-the size in bytes of a structure at the next. Another pass is made
-over the table. All symbols which mark file names (`C_FILE' symbols)
-are modified so that the internal string points to the value in the
-auxent (the real filename) rather than the normal text associated with
-the symbol (`".file"').
-
- At this time the symbol names are moved around. Coff stores all
-symbols less than nine characters long physically within the symbol
-table; longer strings are kept at the end of the file in the string
-table. This pass moves all strings into memory and replaces them with
-pointers to the strings.
-
- The symbol table is massaged once again, this time to create the
-canonical table used by the BFD application. Each symbol is inspected
-in turn, and a decision made (using the `sclass' field) about the
-various flags to set in the `asymbol'. *Note Symbols::. The generated
-canonical table shares strings with the hidden internal symbol table.
-
- Any linenumbers are read from the coff file too, and attached to the
-symbols which own the functions the linenumbers belong to.
-
-3.3.2.5 Symbol writing
-......................
-
-Writing a symbol to a coff file which didn't come from a coff file will
-lose any debugging information. The `asymbol' structure remembers the
-BFD from which the symbol was taken, and on output the back end makes
-sure that the same destination target as source target is present.
-
- When the symbols have come from a coff file then all the debugging
-information is preserved.
-
- Symbol tables are provided for writing to the back end in a vector
-of pointers to pointers. This allows applications like the linker to
-accumulate and output large symbol tables without having to do too much
-byte copying.
-
- This function runs through the provided symbol table and patches
-each symbol marked as a file place holder (`C_FILE') to point to the
-next file place holder in the list. It also marks each `offset' field
-in the list with the offset from the first symbol of the current symbol.
-
- Another function of this procedure is to turn the canonical value
-form of BFD into the form used by coff. Internally, BFD expects symbol
-values to be offsets from a section base; so a symbol physically at
-0x120, but in a section starting at 0x100, would have the value 0x20.
-Coff expects symbols to contain their final value, so symbols have
-their values changed at this point to reflect their sum with their
-owning section. This transformation uses the `output_section' field of
-the `asymbol''s `asection' *Note Sections::.
-
- * `coff_mangle_symbols'
- This routine runs though the provided symbol table and uses the
-offsets generated by the previous pass and the pointers generated when
-the symbol table was read in to create the structured hierarchy
-required by coff. It changes each pointer to a symbol into the index
-into the symbol table of the asymbol.
-
- * `coff_write_symbols'
- This routine runs through the symbol table and patches up the
-symbols from their internal form into the coff way, calls the bit
-twiddlers, and writes out the table to the file.
-
-3.3.2.6 `coff_symbol_type'
-..........................
-
-*Description*
-The hidden information for an `asymbol' is described in a
-`combined_entry_type':
-
-
- typedef struct coff_ptr_struct
- {
- /* Remembers the offset from the first symbol in the file for
- this symbol. Generated by coff_renumber_symbols. */
- unsigned int offset;
-
- /* Should the value of this symbol be renumbered. Used for
- XCOFF C_BSTAT symbols. Set by coff_slurp_symbol_table. */
- unsigned int fix_value : 1;
-
- /* Should the tag field of this symbol be renumbered.
- Created by coff_pointerize_aux. */
- unsigned int fix_tag : 1;
-
- /* Should the endidx field of this symbol be renumbered.
- Created by coff_pointerize_aux. */
- unsigned int fix_end : 1;
-
- /* Should the x_csect.x_scnlen field be renumbered.
- Created by coff_pointerize_aux. */
- unsigned int fix_scnlen : 1;
-
- /* Fix up an XCOFF C_BINCL/C_EINCL symbol. The value is the
- index into the line number entries. Set by coff_slurp_symbol_table. */
- unsigned int fix_line : 1;
-
- /* The container for the symbol structure as read and translated
- from the file. */
- union
- {
- union internal_auxent auxent;
- struct internal_syment syment;
- } u;
- } combined_entry_type;
-
-
- /* Each canonical asymbol really looks like this: */
-
- typedef struct coff_symbol_struct
- {
- /* The actual symbol which the rest of BFD works with */
- asymbol symbol;
-
- /* A pointer to the hidden information for this symbol */
- combined_entry_type *native;
-
- /* A pointer to the linenumber information for this symbol */
- struct lineno_cache_entry *lineno;
-
- /* Have the line numbers been relocated yet ? */
- bfd_boolean done_lineno;
- } coff_symbol_type;
-
-3.3.2.7 `bfd_coff_backend_data'
-...............................
-
- /* COFF symbol classifications. */
-
- enum coff_symbol_classification
- {
- /* Global symbol. */
- COFF_SYMBOL_GLOBAL,
- /* Common symbol. */
- COFF_SYMBOL_COMMON,
- /* Undefined symbol. */
- COFF_SYMBOL_UNDEFINED,
- /* Local symbol. */
- COFF_SYMBOL_LOCAL,
- /* PE section symbol. */
- COFF_SYMBOL_PE_SECTION
- };
-Special entry points for gdb to swap in coff symbol table parts:
- typedef struct
- {
- void (*_bfd_coff_swap_aux_in)
- (bfd *, void *, int, int, int, int, void *);
-
- void (*_bfd_coff_swap_sym_in)
- (bfd *, void *, void *);
-
- void (*_bfd_coff_swap_lineno_in)
- (bfd *, void *, void *);
-
- unsigned int (*_bfd_coff_swap_aux_out)
- (bfd *, void *, int, int, int, int, void *);
-
- unsigned int (*_bfd_coff_swap_sym_out)
- (bfd *, void *, void *);
-
- unsigned int (*_bfd_coff_swap_lineno_out)
- (bfd *, void *, void *);
-
- unsigned int (*_bfd_coff_swap_reloc_out)
- (bfd *, void *, void *);
-
- unsigned int (*_bfd_coff_swap_filehdr_out)
- (bfd *, void *, void *);
-
- unsigned int (*_bfd_coff_swap_aouthdr_out)
- (bfd *, void *, void *);
-
- unsigned int (*_bfd_coff_swap_scnhdr_out)
- (bfd *, void *, void *);
-
- unsigned int _bfd_filhsz;
- unsigned int _bfd_aoutsz;
- unsigned int _bfd_scnhsz;
- unsigned int _bfd_symesz;
- unsigned int _bfd_auxesz;
- unsigned int _bfd_relsz;
- unsigned int _bfd_linesz;
- unsigned int _bfd_filnmlen;
- bfd_boolean _bfd_coff_long_filenames;
-
- bfd_boolean _bfd_coff_long_section_names;
- bfd_boolean (*_bfd_coff_set_long_section_names)
- (bfd *, int);
-
- unsigned int _bfd_coff_default_section_alignment_power;
- bfd_boolean _bfd_coff_force_symnames_in_strings;
- unsigned int _bfd_coff_debug_string_prefix_length;
-
- void (*_bfd_coff_swap_filehdr_in)
- (bfd *, void *, void *);
-
- void (*_bfd_coff_swap_aouthdr_in)
- (bfd *, void *, void *);
-
- void (*_bfd_coff_swap_scnhdr_in)
- (bfd *, void *, void *);
-
- void (*_bfd_coff_swap_reloc_in)
- (bfd *abfd, void *, void *);
-
- bfd_boolean (*_bfd_coff_bad_format_hook)
- (bfd *, void *);
-
- bfd_boolean (*_bfd_coff_set_arch_mach_hook)
- (bfd *, void *);
-
- void * (*_bfd_coff_mkobject_hook)
- (bfd *, void *, void *);
-
- bfd_boolean (*_bfd_styp_to_sec_flags_hook)
- (bfd *, void *, const char *, asection *, flagword *);
-
- void (*_bfd_set_alignment_hook)
- (bfd *, asection *, void *);
-
- bfd_boolean (*_bfd_coff_slurp_symbol_table)
- (bfd *);
-
- bfd_boolean (*_bfd_coff_symname_in_debug)
- (bfd *, struct internal_syment *);
-
- bfd_boolean (*_bfd_coff_pointerize_aux_hook)
- (bfd *, combined_entry_type *, combined_entry_type *,
- unsigned int, combined_entry_type *);
-
- bfd_boolean (*_bfd_coff_print_aux)
- (bfd *, FILE *, combined_entry_type *, combined_entry_type *,
- combined_entry_type *, unsigned int);
-
- void (*_bfd_coff_reloc16_extra_cases)
- (bfd *, struct bfd_link_info *, struct bfd_link_order *, arelent *,
- bfd_byte *, unsigned int *, unsigned int *);
-
- int (*_bfd_coff_reloc16_estimate)
- (bfd *, asection *, arelent *, unsigned int,
- struct bfd_link_info *);
-
- enum coff_symbol_classification (*_bfd_coff_classify_symbol)
- (bfd *, struct internal_syment *);
-
- bfd_boolean (*_bfd_coff_compute_section_file_positions)
- (bfd *);
-
- bfd_boolean (*_bfd_coff_start_final_link)
- (bfd *, struct bfd_link_info *);
-
- bfd_boolean (*_bfd_coff_relocate_section)
- (bfd *, struct bfd_link_info *, bfd *, asection *, bfd_byte *,
- struct internal_reloc *, struct internal_syment *, asection **);
-
- reloc_howto_type *(*_bfd_coff_rtype_to_howto)
- (bfd *, asection *, struct internal_reloc *,
- struct coff_link_hash_entry *, struct internal_syment *,
- bfd_vma *);
-
- bfd_boolean (*_bfd_coff_adjust_symndx)
- (bfd *, struct bfd_link_info *, bfd *, asection *,
- struct internal_reloc *, bfd_boolean *);
-
- bfd_boolean (*_bfd_coff_link_add_one_symbol)
- (struct bfd_link_info *, bfd *, const char *, flagword,
- asection *, bfd_vma, const char *, bfd_boolean, bfd_boolean,
- struct bfd_link_hash_entry **);
-
- bfd_boolean (*_bfd_coff_link_output_has_begun)
- (bfd *, struct coff_final_link_info *);
-
- bfd_boolean (*_bfd_coff_final_link_postscript)
- (bfd *, struct coff_final_link_info *);
-
- bfd_boolean (*_bfd_coff_print_pdata)
- (bfd *, void *);
-
- } bfd_coff_backend_data;
-
- #define coff_backend_info(abfd) \
- ((bfd_coff_backend_data *) (abfd)->xvec->backend_data)
-
- #define bfd_coff_swap_aux_in(a,e,t,c,ind,num,i) \
- ((coff_backend_info (a)->_bfd_coff_swap_aux_in) (a,e,t,c,ind,num,i))
-
- #define bfd_coff_swap_sym_in(a,e,i) \
- ((coff_backend_info (a)->_bfd_coff_swap_sym_in) (a,e,i))
-
- #define bfd_coff_swap_lineno_in(a,e,i) \
- ((coff_backend_info ( a)->_bfd_coff_swap_lineno_in) (a,e,i))
-
- #define bfd_coff_swap_reloc_out(abfd, i, o) \
- ((coff_backend_info (abfd)->_bfd_coff_swap_reloc_out) (abfd, i, o))
-
- #define bfd_coff_swap_lineno_out(abfd, i, o) \
- ((coff_backend_info (abfd)->_bfd_coff_swap_lineno_out) (abfd, i, o))
-
- #define bfd_coff_swap_aux_out(a,i,t,c,ind,num,o) \
- ((coff_backend_info (a)->_bfd_coff_swap_aux_out) (a,i,t,c,ind,num,o))
-
- #define bfd_coff_swap_sym_out(abfd, i,o) \
- ((coff_backend_info (abfd)->_bfd_coff_swap_sym_out) (abfd, i, o))
-
- #define bfd_coff_swap_scnhdr_out(abfd, i,o) \
- ((coff_backend_info (abfd)->_bfd_coff_swap_scnhdr_out) (abfd, i, o))
-
- #define bfd_coff_swap_filehdr_out(abfd, i,o) \
- ((coff_backend_info (abfd)->_bfd_coff_swap_filehdr_out) (abfd, i, o))
-
- #define bfd_coff_swap_aouthdr_out(abfd, i,o) \
- ((coff_backend_info (abfd)->_bfd_coff_swap_aouthdr_out) (abfd, i, o))
-
- #define bfd_coff_filhsz(abfd) (coff_backend_info (abfd)->_bfd_filhsz)
- #define bfd_coff_aoutsz(abfd) (coff_backend_info (abfd)->_bfd_aoutsz)
- #define bfd_coff_scnhsz(abfd) (coff_backend_info (abfd)->_bfd_scnhsz)
- #define bfd_coff_symesz(abfd) (coff_backend_info (abfd)->_bfd_symesz)
- #define bfd_coff_auxesz(abfd) (coff_backend_info (abfd)->_bfd_auxesz)
- #define bfd_coff_relsz(abfd) (coff_backend_info (abfd)->_bfd_relsz)
- #define bfd_coff_linesz(abfd) (coff_backend_info (abfd)->_bfd_linesz)
- #define bfd_coff_filnmlen(abfd) (coff_backend_info (abfd)->_bfd_filnmlen)
- #define bfd_coff_long_filenames(abfd) \
- (coff_backend_info (abfd)->_bfd_coff_long_filenames)
- #define bfd_coff_long_section_names(abfd) \
- (coff_backend_info (abfd)->_bfd_coff_long_section_names)
- #define bfd_coff_set_long_section_names(abfd, enable) \
- ((coff_backend_info (abfd)->_bfd_coff_set_long_section_names) (abfd, enable))
- #define bfd_coff_default_section_alignment_power(abfd) \
- (coff_backend_info (abfd)->_bfd_coff_default_section_alignment_power)
- #define bfd_coff_swap_filehdr_in(abfd, i,o) \
- ((coff_backend_info (abfd)->_bfd_coff_swap_filehdr_in) (abfd, i, o))
-
- #define bfd_coff_swap_aouthdr_in(abfd, i,o) \
- ((coff_backend_info (abfd)->_bfd_coff_swap_aouthdr_in) (abfd, i, o))
-
- #define bfd_coff_swap_scnhdr_in(abfd, i,o) \
- ((coff_backend_info (abfd)->_bfd_coff_swap_scnhdr_in) (abfd, i, o))
-
- #define bfd_coff_swap_reloc_in(abfd, i, o) \
- ((coff_backend_info (abfd)->_bfd_coff_swap_reloc_in) (abfd, i, o))
-
- #define bfd_coff_bad_format_hook(abfd, filehdr) \
- ((coff_backend_info (abfd)->_bfd_coff_bad_format_hook) (abfd, filehdr))
-
- #define bfd_coff_set_arch_mach_hook(abfd, filehdr)\
- ((coff_backend_info (abfd)->_bfd_coff_set_arch_mach_hook) (abfd, filehdr))
- #define bfd_coff_mkobject_hook(abfd, filehdr, aouthdr)\
- ((coff_backend_info (abfd)->_bfd_coff_mkobject_hook)\
- (abfd, filehdr, aouthdr))
-
- #define bfd_coff_styp_to_sec_flags_hook(abfd, scnhdr, name, section, flags_ptr)\
- ((coff_backend_info (abfd)->_bfd_styp_to_sec_flags_hook)\
- (abfd, scnhdr, name, section, flags_ptr))
-
- #define bfd_coff_set_alignment_hook(abfd, sec, scnhdr)\
- ((coff_backend_info (abfd)->_bfd_set_alignment_hook) (abfd, sec, scnhdr))
-
- #define bfd_coff_slurp_symbol_table(abfd)\
- ((coff_backend_info (abfd)->_bfd_coff_slurp_symbol_table) (abfd))
-
- #define bfd_coff_symname_in_debug(abfd, sym)\
- ((coff_backend_info (abfd)->_bfd_coff_symname_in_debug) (abfd, sym))
-
- #define bfd_coff_force_symnames_in_strings(abfd)\
- (coff_backend_info (abfd)->_bfd_coff_force_symnames_in_strings)
-
- #define bfd_coff_debug_string_prefix_length(abfd)\
- (coff_backend_info (abfd)->_bfd_coff_debug_string_prefix_length)
-
- #define bfd_coff_print_aux(abfd, file, base, symbol, aux, indaux)\
- ((coff_backend_info (abfd)->_bfd_coff_print_aux)\
- (abfd, file, base, symbol, aux, indaux))
-
- #define bfd_coff_reloc16_extra_cases(abfd, link_info, link_order,\
- reloc, data, src_ptr, dst_ptr)\
- ((coff_backend_info (abfd)->_bfd_coff_reloc16_extra_cases)\
- (abfd, link_info, link_order, reloc, data, src_ptr, dst_ptr))
-
- #define bfd_coff_reloc16_estimate(abfd, section, reloc, shrink, link_info)\
- ((coff_backend_info (abfd)->_bfd_coff_reloc16_estimate)\
- (abfd, section, reloc, shrink, link_info))
-
- #define bfd_coff_classify_symbol(abfd, sym)\
- ((coff_backend_info (abfd)->_bfd_coff_classify_symbol)\
- (abfd, sym))
-
- #define bfd_coff_compute_section_file_positions(abfd)\
- ((coff_backend_info (abfd)->_bfd_coff_compute_section_file_positions)\
- (abfd))
-
- #define bfd_coff_start_final_link(obfd, info)\
- ((coff_backend_info (obfd)->_bfd_coff_start_final_link)\
- (obfd, info))
- #define bfd_coff_relocate_section(obfd,info,ibfd,o,con,rel,isyms,secs)\
- ((coff_backend_info (ibfd)->_bfd_coff_relocate_section)\
- (obfd, info, ibfd, o, con, rel, isyms, secs))
- #define bfd_coff_rtype_to_howto(abfd, sec, rel, h, sym, addendp)\
- ((coff_backend_info (abfd)->_bfd_coff_rtype_to_howto)\
- (abfd, sec, rel, h, sym, addendp))
- #define bfd_coff_adjust_symndx(obfd, info, ibfd, sec, rel, adjustedp)\
- ((coff_backend_info (abfd)->_bfd_coff_adjust_symndx)\
- (obfd, info, ibfd, sec, rel, adjustedp))
- #define bfd_coff_link_add_one_symbol(info, abfd, name, flags, section,\
- value, string, cp, coll, hashp)\
- ((coff_backend_info (abfd)->_bfd_coff_link_add_one_symbol)\
- (info, abfd, name, flags, section, value, string, cp, coll, hashp))
-
- #define bfd_coff_link_output_has_begun(a,p) \
- ((coff_backend_info (a)->_bfd_coff_link_output_has_begun) (a, p))
- #define bfd_coff_final_link_postscript(a,p) \
- ((coff_backend_info (a)->_bfd_coff_final_link_postscript) (a, p))
-
- #define bfd_coff_have_print_pdata(a) \
- (coff_backend_info (a)->_bfd_coff_print_pdata)
- #define bfd_coff_print_pdata(a,p) \
- ((coff_backend_info (a)->_bfd_coff_print_pdata) (a, p))
-
- /* Macro: Returns true if the bfd is a PE executable as opposed to a
- PE object file. */
- #define bfd_pei_p(abfd) \
- (CONST_STRNEQ ((abfd)->xvec->name, "pei-"))
-
-3.3.2.8 Writing relocations
-...........................
-
-To write relocations, the back end steps though the canonical
-relocation table and create an `internal_reloc'. The symbol index to
-use is removed from the `offset' field in the symbol table supplied.
-The address comes directly from the sum of the section base address and
-the relocation offset; the type is dug directly from the howto field.
-Then the `internal_reloc' is swapped into the shape of an
-`external_reloc' and written out to disk.
-
-3.3.2.9 Reading linenumbers
-...........................
-
-Creating the linenumber table is done by reading in the entire coff
-linenumber table, and creating another table for internal use.
-
- A coff linenumber table is structured so that each function is
-marked as having a line number of 0. Each line within the function is
-an offset from the first line in the function. The base of the line
-number information for the table is stored in the symbol associated
-with the function.
-
- Note: The PE format uses line number 0 for a flag indicating a new
-source file.
-
- The information is copied from the external to the internal table,
-and each symbol which marks a function is marked by pointing its...
-
- How does this work ?
-
-3.3.2.10 Reading relocations
-............................
-
-Coff relocations are easily transformed into the internal BFD form
-(`arelent').
-
- Reading a coff relocation table is done in the following stages:
-
- * Read the entire coff relocation table into memory.
-
- * Process each relocation in turn; first swap it from the external
- to the internal form.
-
- * Turn the symbol referenced in the relocation's symbol index into a
- pointer into the canonical symbol table. This table is the same
- as the one returned by a call to `bfd_canonicalize_symtab'. The
- back end will call that routine and save the result if a
- canonicalization hasn't been done.
-
- * The reloc index is turned into a pointer to a howto structure, in
- a back end specific way. For instance, the 386 and 960 use the
- `r_type' to directly produce an index into a howto table vector;
- the 88k subtracts a number from the `r_type' field and creates an
- addend field.
-
-
-File: bfd.info, Node: elf, Next: mmo, Prev: coff, Up: BFD back ends
-
-3.4 ELF backends
-================
-
-BFD support for ELF formats is being worked on. Currently, the best
-supported back ends are for sparc and i386 (running svr4 or Solaris 2).
-
- Documentation of the internals of the support code still needs to be
-written. The code is changing quickly enough that we haven't bothered
-yet.
-
-
-File: bfd.info, Node: mmo, Prev: elf, Up: BFD back ends
-
-3.5 mmo backend
-===============
-
-The mmo object format is used exclusively together with Professor
-Donald E. Knuth's educational 64-bit processor MMIX. The simulator
-`mmix' which is available at
-`http://www-cs-faculty.stanford.edu/~knuth/programs/mmix.tar.gz'
-understands this format. That package also includes a combined
-assembler and linker called `mmixal'. The mmo format has no advantages
-feature-wise compared to e.g. ELF. It is a simple non-relocatable
-object format with no support for archives or debugging information,
-except for symbol value information and line numbers (which is not yet
-implemented in BFD). See
-`http://www-cs-faculty.stanford.edu/~knuth/mmix.html' for more
-information about MMIX. The ELF format is used for intermediate object
-files in the BFD implementation.
-
-* Menu:
-
-* File layout::
-* Symbol-table::
-* mmo section mapping::
-
-
-File: bfd.info, Node: File layout, Next: Symbol-table, Prev: mmo, Up: mmo
-
-3.5.1 File layout
------------------
-
-The mmo file contents is not partitioned into named sections as with
-e.g. ELF. Memory areas is formed by specifying the location of the
-data that follows. Only the memory area `0x0000...00' to `0x01ff...ff'
-is executable, so it is used for code (and constants) and the area
-`0x2000...00' to `0x20ff...ff' is used for writable data. *Note mmo
-section mapping::.
-
- There is provision for specifying "special data" of 65536 different
-types. We use type 80 (decimal), arbitrarily chosen the same as the
-ELF `e_machine' number for MMIX, filling it with section information
-normally found in ELF objects. *Note mmo section mapping::.
-
- Contents is entered as 32-bit words, xor:ed over previous contents,
-always zero-initialized. A word that starts with the byte `0x98' forms
-a command called a `lopcode', where the next byte distinguished between
-the thirteen lopcodes. The two remaining bytes, called the `Y' and `Z'
-fields, or the `YZ' field (a 16-bit big-endian number), are used for
-various purposes different for each lopcode. As documented in
-`http://www-cs-faculty.stanford.edu/~knuth/mmixal-intro.ps.gz', the
-lopcodes are:
-
-`lop_quote'
- 0x98000001. The next word is contents, regardless of whether it
- starts with 0x98 or not.
-
-`lop_loc'
- 0x9801YYZZ, where `Z' is 1 or 2. This is a location directive,
- setting the location for the next data to the next 32-bit word
- (for Z = 1) or 64-bit word (for Z = 2), plus Y * 2^56. Normally
- `Y' is 0 for the text segment and 2 for the data segment.
-
-`lop_skip'
- 0x9802YYZZ. Increase the current location by `YZ' bytes.
-
-`lop_fixo'
- 0x9803YYZZ, where `Z' is 1 or 2. Store the current location as 64
- bits into the location pointed to by the next 32-bit (Z = 1) or
- 64-bit (Z = 2) word, plus Y * 2^56.
-
-`lop_fixr'
- 0x9804YYZZ. `YZ' is stored into the current location plus 2 - 4 *
- YZ.
-
-`lop_fixrx'
- 0x980500ZZ. `Z' is 16 or 24. A value `L' derived from the
- following 32-bit word are used in a manner similar to `YZ' in
- lop_fixr: it is xor:ed into the current location minus 4 * L. The
- first byte of the word is 0 or 1. If it is 1, then L = (LOWEST 24
- BITS OF WORD) - 2^Z, if 0, then L = (LOWEST 24 BITS OF WORD).
-
-`lop_file'
- 0x9806YYZZ. `Y' is the file number, `Z' is count of 32-bit words.
- Set the file number to `Y' and the line counter to 0. The next Z
- * 4 bytes contain the file name, padded with zeros if the count is
- not a multiple of four. The same `Y' may occur multiple times,
- but `Z' must be 0 for all but the first occurrence.
-
-`lop_line'
- 0x9807YYZZ. `YZ' is the line number. Together with lop_file, it
- forms the source location for the next 32-bit word. Note that for
- each non-lopcode 32-bit word, line numbers are assumed incremented
- by one.
-
-`lop_spec'
- 0x9808YYZZ. `YZ' is the type number. Data until the next lopcode
- other than lop_quote forms special data of type `YZ'. *Note mmo
- section mapping::.
-
- Other types than 80, (or type 80 with a content that does not
- parse) is stored in sections named `.MMIX.spec_data.N' where N is
- the `YZ'-type. The flags for such a sections say not to allocate
- or load the data. The vma is 0. Contents of multiple occurrences
- of special data N is concatenated to the data of the previous
- lop_spec Ns. The location in data or code at which the lop_spec
- occurred is lost.
-
-`lop_pre'
- 0x980901ZZ. The first lopcode in a file. The `Z' field forms the
- length of header information in 32-bit words, where the first word
- tells the time in seconds since `00:00:00 GMT Jan 1 1970'.
-
-`lop_post'
- 0x980a00ZZ. Z > 32. This lopcode follows after all
- content-generating lopcodes in a program. The `Z' field denotes
- the value of `rG' at the beginning of the program. The following
- 256 - Z big-endian 64-bit words are loaded into global registers
- `$G' ... `$255'.
-
-`lop_stab'
- 0x980b0000. The next-to-last lopcode in a program. Must follow
- immediately after the lop_post lopcode and its data. After this
- lopcode follows all symbols in a compressed format (*note
- Symbol-table::).
-
-`lop_end'
- 0x980cYYZZ. The last lopcode in a program. It must follow the
- lop_stab lopcode and its data. The `YZ' field contains the number
- of 32-bit words of symbol table information after the preceding
- lop_stab lopcode.
-
- Note that the lopcode "fixups"; `lop_fixr', `lop_fixrx' and
-`lop_fixo' are not generated by BFD, but are handled. They are
-generated by `mmixal'.
-
- This trivial one-label, one-instruction file:
-
- :Main TRAP 1,2,3
-
- can be represented this way in mmo:
-
- 0x98090101 - lop_pre, one 32-bit word with timestamp.
- <timestamp>
- 0x98010002 - lop_loc, text segment, using a 64-bit address.
- Note that mmixal does not emit this for the file above.
- 0x00000000 - Address, high 32 bits.
- 0x00000000 - Address, low 32 bits.
- 0x98060002 - lop_file, 2 32-bit words for file-name.
- 0x74657374 - "test"
- 0x2e730000 - ".s\0\0"
- 0x98070001 - lop_line, line 1.
- 0x00010203 - TRAP 1,2,3
- 0x980a00ff - lop_post, setting $255 to 0.
- 0x00000000
- 0x00000000
- 0x980b0000 - lop_stab for ":Main" = 0, serial 1.
- 0x203a4040 *Note Symbol-table::.
- 0x10404020
- 0x4d206120
- 0x69016e00
- 0x81000000
- 0x980c0005 - lop_end; symbol table contained five 32-bit words.
-
-
-File: bfd.info, Node: Symbol-table, Next: mmo section mapping, Prev: File layout, Up: mmo
-
-3.5.2 Symbol table format
--------------------------
-
-From mmixal.w (or really, the generated mmixal.tex) in
-`http://www-cs-faculty.stanford.edu/~knuth/programs/mmix.tar.gz'):
-"Symbols are stored and retrieved by means of a `ternary search trie',
-following ideas of Bentley and Sedgewick. (See ACM-SIAM Symp. on
-Discrete Algorithms `8' (1997), 360-369; R.Sedgewick, `Algorithms in C'
-(Reading, Mass. Addison-Wesley, 1998), `15.4'.) Each trie node stores
-a character, and there are branches to subtries for the cases where a
-given character is less than, equal to, or greater than the character
-in the trie. There also is a pointer to a symbol table entry if a
-symbol ends at the current node."
-
- So it's a tree encoded as a stream of bytes. The stream of bytes
-acts on a single virtual global symbol, adding and removing characters
-and signalling complete symbol points. Here, we read the stream and
-create symbols at the completion points.
-
- First, there's a control byte `m'. If any of the listed bits in `m'
-is nonzero, we execute what stands at the right, in the listed order:
-
- (MMO3_LEFT)
- 0x40 - Traverse left trie.
- (Read a new command byte and recurse.)
-
- (MMO3_SYMBITS)
- 0x2f - Read the next byte as a character and store it in the
- current character position; increment character position.
- Test the bits of `m':
-
- (MMO3_WCHAR)
- 0x80 - The character is 16-bit (so read another byte,
- merge into current character.
-
- (MMO3_TYPEBITS)
- 0xf - We have a complete symbol; parse the type, value
- and serial number and do what should be done
- with a symbol. The type and length information
- is in j = (m & 0xf).
-
- (MMO3_REGQUAL_BITS)
- j == 0xf: A register variable. The following
- byte tells which register.
- j <= 8: An absolute symbol. Read j bytes as the
- big-endian number the symbol equals.
- A j = 2 with two zero bytes denotes an
- unknown symbol.
- j > 8: As with j <= 8, but add (0x20 << 56)
- to the value in the following j - 8
- bytes.
-
- Then comes the serial number, as a variant of
- uleb128, but better named ubeb128:
- Read bytes and shift the previous value left 7
- (multiply by 128). Add in the new byte, repeat
- until a byte has bit 7 set. The serial number
- is the computed value minus 128.
-
- (MMO3_MIDDLE)
- 0x20 - Traverse middle trie. (Read a new command byte
- and recurse.) Decrement character position.
-
- (MMO3_RIGHT)
- 0x10 - Traverse right trie. (Read a new command byte and
- recurse.)
-
- Let's look again at the `lop_stab' for the trivial file (*note File
-layout::).
-
- 0x980b0000 - lop_stab for ":Main" = 0, serial 1.
- 0x203a4040
- 0x10404020
- 0x4d206120
- 0x69016e00
- 0x81000000
-
- This forms the trivial trie (note that the path between ":" and "M"
-is redundant):
-
- 203a ":"
- 40 /
- 40 /
- 10 \
- 40 /
- 40 /
- 204d "M"
- 2061 "a"
- 2069 "i"
- 016e "n" is the last character in a full symbol, and
- with a value represented in one byte.
- 00 The value is 0.
- 81 The serial number is 1.
-
-
-File: bfd.info, Node: mmo section mapping, Prev: Symbol-table, Up: mmo
-
-3.5.3 mmo section mapping
--------------------------
-
-The implementation in BFD uses special data type 80 (decimal) to
-encapsulate and describe named sections, containing e.g. debug
-information. If needed, any datum in the encapsulation will be quoted
-using lop_quote. First comes a 32-bit word holding the number of
-32-bit words containing the zero-terminated zero-padded segment name.
-After the name there's a 32-bit word holding flags describing the
-section type. Then comes a 64-bit big-endian word with the section
-length (in bytes), then another with the section start address.
-Depending on the type of section, the contents might follow,
-zero-padded to 32-bit boundary. For a loadable section (such as data
-or code), the contents might follow at some later point, not
-necessarily immediately, as a lop_loc with the same start address as in
-the section description, followed by the contents. This in effect
-forms a descriptor that must be emitted before the actual contents.
-Sections described this way must not overlap.
-
- For areas that don't have such descriptors, synthetic sections are
-formed by BFD. Consecutive contents in the two memory areas
-`0x0000...00' to `0x01ff...ff' and `0x2000...00' to `0x20ff...ff' are
-entered in sections named `.text' and `.data' respectively. If an area
-is not otherwise described, but would together with a neighboring lower
-area be less than `0x40000000' bytes long, it is joined with the lower
-area and the gap is zero-filled. For other cases, a new section is
-formed, named `.MMIX.sec.N'. Here, N is a number, a running count
-through the mmo file, starting at 0.
-
- A loadable section specified as:
-
- .section secname,"ax"
- TETRA 1,2,3,4,-1,-2009
- BYTE 80
-
- and linked to address `0x4', is represented by the sequence:
-
- 0x98080050 - lop_spec 80
- 0x00000002 - two 32-bit words for the section name
- 0x7365636e - "secn"
- 0x616d6500 - "ame\0"
- 0x00000033 - flags CODE, READONLY, LOAD, ALLOC
- 0x00000000 - high 32 bits of section length
- 0x0000001c - section length is 28 bytes; 6 * 4 + 1 + alignment to 32 bits
- 0x00000000 - high 32 bits of section address
- 0x00000004 - section address is 4
- 0x98010002 - 64 bits with address of following data
- 0x00000000 - high 32 bits of address
- 0x00000004 - low 32 bits: data starts at address 4
- 0x00000001 - 1
- 0x00000002 - 2
- 0x00000003 - 3
- 0x00000004 - 4
- 0xffffffff - -1
- 0xfffff827 - -2009
- 0x50000000 - 80 as a byte, padded with zeros.
-
- Note that the lop_spec wrapping does not include the section
-contents. Compare this to a non-loaded section specified as:
-
- .section thirdsec
- TETRA 200001,100002
- BYTE 38,40
-
- This, when linked to address `0x200000000000001c', is represented by:
-
- 0x98080050 - lop_spec 80
- 0x00000002 - two 32-bit words for the section name
- 0x7365636e - "thir"
- 0x616d6500 - "dsec"
- 0x00000010 - flag READONLY
- 0x00000000 - high 32 bits of section length
- 0x0000000c - section length is 12 bytes; 2 * 4 + 2 + alignment to 32 bits
- 0x20000000 - high 32 bits of address
- 0x0000001c - low 32 bits of address 0x200000000000001c
- 0x00030d41 - 200001
- 0x000186a2 - 100002
- 0x26280000 - 38, 40 as bytes, padded with zeros
-
- For the latter example, the section contents must not be loaded in
-memory, and is therefore specified as part of the special data. The
-address is usually unimportant but might provide information for e.g.
-the DWARF 2 debugging format.
-
-
-File: bfd.info, Node: GNU Free Documentation License, Next: BFD Index, Prev: BFD back ends, Up: Top
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: bfd.info, Node: BFD Index, Prev: GNU Free Documentation License, Up: Top
-
-BFD Index
-*********
-
-
-* Menu:
-
-* _bfd_final_link_relocate: Relocating the section contents.
- (line 22)
-* _bfd_generic_link_add_archive_symbols: Adding symbols from an archive.
- (line 15)
-* _bfd_generic_link_add_one_symbol: Adding symbols from an object file.
- (line 19)
-* _bfd_generic_make_empty_symbol: symbol handling functions.
- (line 92)
-* _bfd_link_add_symbols in target vector: Adding Symbols to the Hash Table.
- (line 6)
-* _bfd_link_final_link in target vector: Performing the Final Link.
- (line 6)
-* _bfd_link_hash_table_create in target vector: Creating a Linker Hash Table.
- (line 6)
-* _bfd_relocate_contents: Relocating the section contents.
- (line 22)
-* aout_SIZE_machine_type: aout. (line 147)
-* aout_SIZE_mkobject: aout. (line 139)
-* aout_SIZE_new_section_hook: aout. (line 177)
-* aout_SIZE_set_arch_mach: aout. (line 164)
-* aout_SIZE_some_aout_object_p: aout. (line 125)
-* aout_SIZE_swap_exec_header_in: aout. (line 101)
-* aout_SIZE_swap_exec_header_out: aout. (line 113)
-* arelent_chain: typedef arelent. (line 336)
-* BFD: Overview. (line 6)
-* BFD canonical format: Canonical format. (line 11)
-* bfd_alloc: Opening and Closing.
- (line 214)
-* bfd_alloc2: Opening and Closing.
- (line 223)
-* bfd_alt_mach_code: BFD front end. (line 708)
-* bfd_arch_bits_per_address: Architectures. (line 531)
-* bfd_arch_bits_per_byte: Architectures. (line 523)
-* bfd_arch_get_compatible: Architectures. (line 466)
-* bfd_arch_list: Architectures. (line 457)
-* bfd_arch_mach_octets_per_byte: Architectures. (line 600)
-* BFD_ARELOC_BFIN_ADD: howto manager. (line 1025)
-* BFD_ARELOC_BFIN_ADDR: howto manager. (line 1076)
-* BFD_ARELOC_BFIN_AND: howto manager. (line 1046)
-* BFD_ARELOC_BFIN_COMP: howto manager. (line 1067)
-* BFD_ARELOC_BFIN_CONST: howto manager. (line 1022)
-* BFD_ARELOC_BFIN_DIV: howto manager. (line 1034)
-* BFD_ARELOC_BFIN_HWPAGE: howto manager. (line 1073)
-* BFD_ARELOC_BFIN_LAND: howto manager. (line 1055)
-* BFD_ARELOC_BFIN_LEN: howto manager. (line 1061)
-* BFD_ARELOC_BFIN_LOR: howto manager. (line 1058)
-* BFD_ARELOC_BFIN_LSHIFT: howto manager. (line 1040)
-* BFD_ARELOC_BFIN_MOD: howto manager. (line 1037)
-* BFD_ARELOC_BFIN_MULT: howto manager. (line 1031)
-* BFD_ARELOC_BFIN_NEG: howto manager. (line 1064)
-* BFD_ARELOC_BFIN_OR: howto manager. (line 1049)
-* BFD_ARELOC_BFIN_PAGE: howto manager. (line 1070)
-* BFD_ARELOC_BFIN_PUSH: howto manager. (line 1019)
-* BFD_ARELOC_BFIN_RSHIFT: howto manager. (line 1043)
-* BFD_ARELOC_BFIN_SUB: howto manager. (line 1028)
-* BFD_ARELOC_BFIN_XOR: howto manager. (line 1052)
-* bfd_cache_close: File Caching. (line 26)
-* bfd_cache_close_all: File Caching. (line 39)
-* bfd_cache_init: File Caching. (line 18)
-* bfd_calc_gnu_debuglink_crc32: Opening and Closing.
- (line 250)
-* bfd_canonicalize_reloc: BFD front end. (line 427)
-* bfd_canonicalize_symtab: symbol handling functions.
- (line 50)
-* bfd_check_format: Formats. (line 21)
-* bfd_check_format_matches: Formats. (line 52)
-* bfd_check_overflow: typedef arelent. (line 348)
-* bfd_close: Opening and Closing.
- (line 139)
-* bfd_close_all_done: Opening and Closing.
- (line 157)
-* bfd_coff_backend_data: coff. (line 304)
-* bfd_copy_private_bfd_data: BFD front end. (line 566)
-* bfd_copy_private_header_data: BFD front end. (line 548)
-* bfd_copy_private_section_data: section prototypes. (line 264)
-* bfd_copy_private_symbol_data: symbol handling functions.
- (line 140)
-* bfd_core_file_failing_command: Core Files. (line 12)
-* bfd_core_file_failing_signal: Core Files. (line 21)
-* bfd_core_file_pid: Core Files. (line 30)
-* bfd_create: Opening and Closing.
- (line 176)
-* bfd_create_gnu_debuglink_section: Opening and Closing.
- (line 316)
-* bfd_decode_symclass: symbol handling functions.
- (line 111)
-* bfd_default_arch_struct: Architectures. (line 478)
-* bfd_default_compatible: Architectures. (line 540)
-* bfd_default_reloc_type_lookup: howto manager. (line 2421)
-* bfd_default_scan: Architectures. (line 549)
-* bfd_default_set_arch_mach: Architectures. (line 496)
-* bfd_demangle: BFD front end. (line 806)
-* bfd_emul_get_commonpagesize: BFD front end. (line 786)
-* bfd_emul_get_maxpagesize: BFD front end. (line 766)
-* bfd_emul_set_commonpagesize: BFD front end. (line 797)
-* bfd_emul_set_maxpagesize: BFD front end. (line 777)
-* bfd_errmsg: BFD front end. (line 352)
-* bfd_fdopenr: Opening and Closing.
- (line 49)
-* bfd_fill_in_gnu_debuglink_section: Opening and Closing.
- (line 330)
-* bfd_find_target: bfd_target. (line 456)
-* bfd_find_version_for_sym: Writing the symbol table.
- (line 80)
-* bfd_follow_gnu_debuglink: Opening and Closing.
- (line 295)
-* bfd_fopen: Opening and Closing.
- (line 12)
-* bfd_format_string: Formats. (line 79)
-* bfd_generic_define_common_symbol: Writing the symbol table.
- (line 67)
-* bfd_generic_discard_group: section prototypes. (line 290)
-* bfd_generic_gc_sections: howto manager. (line 2452)
-* bfd_generic_get_relocated_section_contents: howto manager. (line 2472)
-* bfd_generic_is_group_section: section prototypes. (line 282)
-* bfd_generic_merge_sections: howto manager. (line 2462)
-* bfd_generic_relax_section: howto manager. (line 2439)
-* bfd_get_arch: Architectures. (line 507)
-* bfd_get_arch_info: Architectures. (line 559)
-* bfd_get_arch_size: BFD front end. (line 471)
-* bfd_get_error: BFD front end. (line 333)
-* bfd_get_error_handler: BFD front end. (line 403)
-* bfd_get_gp_size: BFD front end. (line 512)
-* bfd_get_mach: Architectures. (line 515)
-* bfd_get_mtime: BFD front end. (line 851)
-* bfd_get_next_mapent: Archives. (line 52)
-* bfd_get_reloc_code_name: howto manager. (line 2430)
-* bfd_get_reloc_size: typedef arelent. (line 327)
-* bfd_get_reloc_upper_bound: BFD front end. (line 417)
-* bfd_get_section_by_name: section prototypes. (line 17)
-* bfd_get_section_by_name_if: section prototypes. (line 31)
-* bfd_get_section_contents: section prototypes. (line 237)
-* bfd_get_sign_extend_vma: BFD front end. (line 484)
-* bfd_get_size <1>: BFD front end. (line 860)
-* bfd_get_size: Internal. (line 25)
-* bfd_get_symtab_upper_bound: symbol handling functions.
- (line 6)
-* bfd_get_target_info: bfd_target. (line 472)
-* bfd_get_unique_section_name: section prototypes. (line 50)
-* bfd_h_put_size: Internal. (line 97)
-* bfd_hash_allocate: Creating and Freeing a Hash Table.
- (line 17)
-* bfd_hash_lookup: Looking Up or Entering a String.
- (line 6)
-* bfd_hash_newfunc: Creating and Freeing a Hash Table.
- (line 12)
-* bfd_hash_set_default_size: Creating and Freeing a Hash Table.
- (line 25)
-* bfd_hash_table_free: Creating and Freeing a Hash Table.
- (line 21)
-* bfd_hash_table_init: Creating and Freeing a Hash Table.
- (line 6)
-* bfd_hash_table_init_n: Creating and Freeing a Hash Table.
- (line 6)
-* bfd_hash_traverse: Traversing a Hash Table.
- (line 6)
-* bfd_init: Initialization. (line 11)
-* bfd_install_relocation: typedef arelent. (line 389)
-* bfd_is_local_label: symbol handling functions.
- (line 17)
-* bfd_is_local_label_name: symbol handling functions.
- (line 26)
-* bfd_is_target_special_symbol: symbol handling functions.
- (line 38)
-* bfd_is_undefined_symclass: symbol handling functions.
- (line 120)
-* bfd_link_split_section: Writing the symbol table.
- (line 44)
-* bfd_log2: Internal. (line 164)
-* bfd_lookup_arch: Architectures. (line 567)
-* bfd_make_debug_symbol: symbol handling functions.
- (line 102)
-* bfd_make_empty_symbol: symbol handling functions.
- (line 78)
-* bfd_make_readable: Opening and Closing.
- (line 200)
-* bfd_make_section: section prototypes. (line 129)
-* bfd_make_section_anyway: section prototypes. (line 100)
-* bfd_make_section_anyway_with_flags: section prototypes. (line 82)
-* bfd_make_section_old_way: section prototypes. (line 62)
-* bfd_make_section_with_flags: section prototypes. (line 116)
-* bfd_make_writable: Opening and Closing.
- (line 186)
-* bfd_malloc_and_get_section: section prototypes. (line 254)
-* bfd_map_over_sections: section prototypes. (line 164)
-* bfd_merge_private_bfd_data: BFD front end. (line 582)
-* bfd_mmap: BFD front end. (line 889)
-* bfd_octets_per_byte: Architectures. (line 590)
-* bfd_open_file: File Caching. (line 52)
-* bfd_openr: Opening and Closing.
- (line 33)
-* bfd_openr_iovec: Opening and Closing.
- (line 79)
-* bfd_openr_next_archived_file: Archives. (line 78)
-* bfd_openstreamr: Opening and Closing.
- (line 70)
-* bfd_openw: Opening and Closing.
- (line 127)
-* bfd_perform_relocation: typedef arelent. (line 364)
-* bfd_perror: BFD front end. (line 361)
-* bfd_preserve_finish: BFD front end. (line 756)
-* bfd_preserve_restore: BFD front end. (line 746)
-* bfd_preserve_save: BFD front end. (line 730)
-* bfd_print_symbol_vandf: symbol handling functions.
- (line 70)
-* bfd_printable_arch_mach: Architectures. (line 578)
-* bfd_printable_name: Architectures. (line 438)
-* bfd_put_size: Internal. (line 22)
-* BFD_RELOC_12_PCREL: howto manager. (line 39)
-* BFD_RELOC_14: howto manager. (line 31)
-* BFD_RELOC_16: howto manager. (line 30)
-* BFD_RELOC_16_BASEREL: howto manager. (line 95)
-* BFD_RELOC_16_GOT_PCREL: howto manager. (line 52)
-* BFD_RELOC_16_GOTOFF: howto manager. (line 55)
-* BFD_RELOC_16_PCREL: howto manager. (line 38)
-* BFD_RELOC_16_PCREL_S2: howto manager. (line 107)
-* BFD_RELOC_16_PLT_PCREL: howto manager. (line 63)
-* BFD_RELOC_16_PLTOFF: howto manager. (line 67)
-* BFD_RELOC_16C_ABS20: howto manager. (line 1985)
-* BFD_RELOC_16C_ABS20_C: howto manager. (line 1986)
-* BFD_RELOC_16C_ABS24: howto manager. (line 1987)
-* BFD_RELOC_16C_ABS24_C: howto manager. (line 1988)
-* BFD_RELOC_16C_DISP04: howto manager. (line 1965)
-* BFD_RELOC_16C_DISP04_C: howto manager. (line 1966)
-* BFD_RELOC_16C_DISP08: howto manager. (line 1967)
-* BFD_RELOC_16C_DISP08_C: howto manager. (line 1968)
-* BFD_RELOC_16C_DISP16: howto manager. (line 1969)
-* BFD_RELOC_16C_DISP16_C: howto manager. (line 1970)
-* BFD_RELOC_16C_DISP24: howto manager. (line 1971)
-* BFD_RELOC_16C_DISP24_C: howto manager. (line 1972)
-* BFD_RELOC_16C_DISP24a: howto manager. (line 1973)
-* BFD_RELOC_16C_DISP24a_C: howto manager. (line 1974)
-* BFD_RELOC_16C_IMM04: howto manager. (line 1989)
-* BFD_RELOC_16C_IMM04_C: howto manager. (line 1990)
-* BFD_RELOC_16C_IMM16: howto manager. (line 1991)
-* BFD_RELOC_16C_IMM16_C: howto manager. (line 1992)
-* BFD_RELOC_16C_IMM20: howto manager. (line 1993)
-* BFD_RELOC_16C_IMM20_C: howto manager. (line 1994)
-* BFD_RELOC_16C_IMM24: howto manager. (line 1995)
-* BFD_RELOC_16C_IMM24_C: howto manager. (line 1996)
-* BFD_RELOC_16C_IMM32: howto manager. (line 1997)
-* BFD_RELOC_16C_IMM32_C: howto manager. (line 1998)
-* BFD_RELOC_16C_NUM08: howto manager. (line 1959)
-* BFD_RELOC_16C_NUM08_C: howto manager. (line 1960)
-* BFD_RELOC_16C_NUM16: howto manager. (line 1961)
-* BFD_RELOC_16C_NUM16_C: howto manager. (line 1962)
-* BFD_RELOC_16C_NUM32: howto manager. (line 1963)
-* BFD_RELOC_16C_NUM32_C: howto manager. (line 1964)
-* BFD_RELOC_16C_REG04: howto manager. (line 1975)
-* BFD_RELOC_16C_REG04_C: howto manager. (line 1976)
-* BFD_RELOC_16C_REG04a: howto manager. (line 1977)
-* BFD_RELOC_16C_REG04a_C: howto manager. (line 1978)
-* BFD_RELOC_16C_REG14: howto manager. (line 1979)
-* BFD_RELOC_16C_REG14_C: howto manager. (line 1980)
-* BFD_RELOC_16C_REG16: howto manager. (line 1981)
-* BFD_RELOC_16C_REG16_C: howto manager. (line 1982)
-* BFD_RELOC_16C_REG20: howto manager. (line 1983)
-* BFD_RELOC_16C_REG20_C: howto manager. (line 1984)
-* BFD_RELOC_23_PCREL_S2: howto manager. (line 108)
-* BFD_RELOC_24: howto manager. (line 29)
-* BFD_RELOC_24_PCREL: howto manager. (line 37)
-* BFD_RELOC_24_PLT_PCREL: howto manager. (line 62)
-* BFD_RELOC_26: howto manager. (line 28)
-* BFD_RELOC_32: howto manager. (line 27)
-* BFD_RELOC_32_BASEREL: howto manager. (line 94)
-* BFD_RELOC_32_GOT_PCREL: howto manager. (line 51)
-* BFD_RELOC_32_GOTOFF: howto manager. (line 54)
-* BFD_RELOC_32_PCREL: howto manager. (line 36)
-* BFD_RELOC_32_PCREL_S2: howto manager. (line 106)
-* BFD_RELOC_32_PLT_PCREL: howto manager. (line 61)
-* BFD_RELOC_32_PLTOFF: howto manager. (line 66)
-* BFD_RELOC_32_SECREL: howto manager. (line 48)
-* BFD_RELOC_386_COPY: howto manager. (line 507)
-* BFD_RELOC_386_GLOB_DAT: howto manager. (line 508)
-* BFD_RELOC_386_GOT32: howto manager. (line 505)
-* BFD_RELOC_386_GOTOFF: howto manager. (line 511)
-* BFD_RELOC_386_GOTPC: howto manager. (line 512)
-* BFD_RELOC_386_IRELATIVE: howto manager. (line 528)
-* BFD_RELOC_386_JUMP_SLOT: howto manager. (line 509)
-* BFD_RELOC_386_PLT32: howto manager. (line 506)
-* BFD_RELOC_386_RELATIVE: howto manager. (line 510)
-* BFD_RELOC_386_TLS_DESC: howto manager. (line 527)
-* BFD_RELOC_386_TLS_DESC_CALL: howto manager. (line 526)
-* BFD_RELOC_386_TLS_DTPMOD32: howto manager. (line 522)
-* BFD_RELOC_386_TLS_DTPOFF32: howto manager. (line 523)
-* BFD_RELOC_386_TLS_GD: howto manager. (line 517)
-* BFD_RELOC_386_TLS_GOTDESC: howto manager. (line 525)
-* BFD_RELOC_386_TLS_GOTIE: howto manager. (line 515)
-* BFD_RELOC_386_TLS_IE: howto manager. (line 514)
-* BFD_RELOC_386_TLS_IE_32: howto manager. (line 520)
-* BFD_RELOC_386_TLS_LDM: howto manager. (line 518)
-* BFD_RELOC_386_TLS_LDO_32: howto manager. (line 519)
-* BFD_RELOC_386_TLS_LE: howto manager. (line 516)
-* BFD_RELOC_386_TLS_LE_32: howto manager. (line 521)
-* BFD_RELOC_386_TLS_TPOFF: howto manager. (line 513)
-* BFD_RELOC_386_TLS_TPOFF32: howto manager. (line 524)
-* BFD_RELOC_390_12: howto manager. (line 1645)
-* BFD_RELOC_390_20: howto manager. (line 1745)
-* BFD_RELOC_390_COPY: howto manager. (line 1654)
-* BFD_RELOC_390_GLOB_DAT: howto manager. (line 1657)
-* BFD_RELOC_390_GOT12: howto manager. (line 1648)
-* BFD_RELOC_390_GOT16: howto manager. (line 1669)
-* BFD_RELOC_390_GOT20: howto manager. (line 1746)
-* BFD_RELOC_390_GOT64: howto manager. (line 1687)
-* BFD_RELOC_390_GOTENT: howto manager. (line 1693)
-* BFD_RELOC_390_GOTOFF64: howto manager. (line 1696)
-* BFD_RELOC_390_GOTPC: howto manager. (line 1666)
-* BFD_RELOC_390_GOTPCDBL: howto manager. (line 1684)
-* BFD_RELOC_390_GOTPLT12: howto manager. (line 1699)
-* BFD_RELOC_390_GOTPLT16: howto manager. (line 1702)
-* BFD_RELOC_390_GOTPLT20: howto manager. (line 1747)
-* BFD_RELOC_390_GOTPLT32: howto manager. (line 1705)
-* BFD_RELOC_390_GOTPLT64: howto manager. (line 1708)
-* BFD_RELOC_390_GOTPLTENT: howto manager. (line 1711)
-* BFD_RELOC_390_JMP_SLOT: howto manager. (line 1660)
-* BFD_RELOC_390_PC16DBL: howto manager. (line 1672)
-* BFD_RELOC_390_PC32DBL: howto manager. (line 1678)
-* BFD_RELOC_390_PLT16DBL: howto manager. (line 1675)
-* BFD_RELOC_390_PLT32: howto manager. (line 1651)
-* BFD_RELOC_390_PLT32DBL: howto manager. (line 1681)
-* BFD_RELOC_390_PLT64: howto manager. (line 1690)
-* BFD_RELOC_390_PLTOFF16: howto manager. (line 1714)
-* BFD_RELOC_390_PLTOFF32: howto manager. (line 1717)
-* BFD_RELOC_390_PLTOFF64: howto manager. (line 1720)
-* BFD_RELOC_390_RELATIVE: howto manager. (line 1663)
-* BFD_RELOC_390_TLS_DTPMOD: howto manager. (line 1740)
-* BFD_RELOC_390_TLS_DTPOFF: howto manager. (line 1741)
-* BFD_RELOC_390_TLS_GD32: howto manager. (line 1726)
-* BFD_RELOC_390_TLS_GD64: howto manager. (line 1727)
-* BFD_RELOC_390_TLS_GDCALL: howto manager. (line 1724)
-* BFD_RELOC_390_TLS_GOTIE12: howto manager. (line 1728)
-* BFD_RELOC_390_TLS_GOTIE20: howto manager. (line 1748)
-* BFD_RELOC_390_TLS_GOTIE32: howto manager. (line 1729)
-* BFD_RELOC_390_TLS_GOTIE64: howto manager. (line 1730)
-* BFD_RELOC_390_TLS_IE32: howto manager. (line 1733)
-* BFD_RELOC_390_TLS_IE64: howto manager. (line 1734)
-* BFD_RELOC_390_TLS_IEENT: howto manager. (line 1735)
-* BFD_RELOC_390_TLS_LDCALL: howto manager. (line 1725)
-* BFD_RELOC_390_TLS_LDM32: howto manager. (line 1731)
-* BFD_RELOC_390_TLS_LDM64: howto manager. (line 1732)
-* BFD_RELOC_390_TLS_LDO32: howto manager. (line 1738)
-* BFD_RELOC_390_TLS_LDO64: howto manager. (line 1739)
-* BFD_RELOC_390_TLS_LE32: howto manager. (line 1736)
-* BFD_RELOC_390_TLS_LE64: howto manager. (line 1737)
-* BFD_RELOC_390_TLS_LOAD: howto manager. (line 1723)
-* BFD_RELOC_390_TLS_TPOFF: howto manager. (line 1742)
-* BFD_RELOC_64: howto manager. (line 26)
-* BFD_RELOC_64_PCREL: howto manager. (line 35)
-* BFD_RELOC_64_PLT_PCREL: howto manager. (line 60)
-* BFD_RELOC_64_PLTOFF: howto manager. (line 65)
-* BFD_RELOC_68K_GLOB_DAT: howto manager. (line 74)
-* BFD_RELOC_68K_JMP_SLOT: howto manager. (line 75)
-* BFD_RELOC_68K_RELATIVE: howto manager. (line 76)
-* BFD_RELOC_68K_TLS_GD16: howto manager. (line 78)
-* BFD_RELOC_68K_TLS_GD32: howto manager. (line 77)
-* BFD_RELOC_68K_TLS_GD8: howto manager. (line 79)
-* BFD_RELOC_68K_TLS_IE16: howto manager. (line 87)
-* BFD_RELOC_68K_TLS_IE32: howto manager. (line 86)
-* BFD_RELOC_68K_TLS_IE8: howto manager. (line 88)
-* BFD_RELOC_68K_TLS_LDM16: howto manager. (line 81)
-* BFD_RELOC_68K_TLS_LDM32: howto manager. (line 80)
-* BFD_RELOC_68K_TLS_LDM8: howto manager. (line 82)
-* BFD_RELOC_68K_TLS_LDO16: howto manager. (line 84)
-* BFD_RELOC_68K_TLS_LDO32: howto manager. (line 83)
-* BFD_RELOC_68K_TLS_LDO8: howto manager. (line 85)
-* BFD_RELOC_68K_TLS_LE16: howto manager. (line 90)
-* BFD_RELOC_68K_TLS_LE32: howto manager. (line 89)
-* BFD_RELOC_68K_TLS_LE8: howto manager. (line 91)
-* BFD_RELOC_8: howto manager. (line 32)
-* BFD_RELOC_860_COPY: howto manager. (line 2113)
-* BFD_RELOC_860_GLOB_DAT: howto manager. (line 2114)
-* BFD_RELOC_860_HAGOT: howto manager. (line 2139)
-* BFD_RELOC_860_HAGOTOFF: howto manager. (line 2140)
-* BFD_RELOC_860_HAPC: howto manager. (line 2141)
-* BFD_RELOC_860_HIGH: howto manager. (line 2142)
-* BFD_RELOC_860_HIGHADJ: howto manager. (line 2138)
-* BFD_RELOC_860_HIGOT: howto manager. (line 2143)
-* BFD_RELOC_860_HIGOTOFF: howto manager. (line 2144)
-* BFD_RELOC_860_JUMP_SLOT: howto manager. (line 2115)
-* BFD_RELOC_860_LOGOT0: howto manager. (line 2127)
-* BFD_RELOC_860_LOGOT1: howto manager. (line 2129)
-* BFD_RELOC_860_LOGOTOFF0: howto manager. (line 2131)
-* BFD_RELOC_860_LOGOTOFF1: howto manager. (line 2133)
-* BFD_RELOC_860_LOGOTOFF2: howto manager. (line 2135)
-* BFD_RELOC_860_LOGOTOFF3: howto manager. (line 2136)
-* BFD_RELOC_860_LOPC: howto manager. (line 2137)
-* BFD_RELOC_860_LOW0: howto manager. (line 2120)
-* BFD_RELOC_860_LOW1: howto manager. (line 2122)
-* BFD_RELOC_860_LOW2: howto manager. (line 2124)
-* BFD_RELOC_860_LOW3: howto manager. (line 2126)
-* BFD_RELOC_860_PC16: howto manager. (line 2119)
-* BFD_RELOC_860_PC26: howto manager. (line 2117)
-* BFD_RELOC_860_PLT26: howto manager. (line 2118)
-* BFD_RELOC_860_RELATIVE: howto manager. (line 2116)
-* BFD_RELOC_860_SPGOT0: howto manager. (line 2128)
-* BFD_RELOC_860_SPGOT1: howto manager. (line 2130)
-* BFD_RELOC_860_SPGOTOFF0: howto manager. (line 2132)
-* BFD_RELOC_860_SPGOTOFF1: howto manager. (line 2134)
-* BFD_RELOC_860_SPLIT0: howto manager. (line 2121)
-* BFD_RELOC_860_SPLIT1: howto manager. (line 2123)
-* BFD_RELOC_860_SPLIT2: howto manager. (line 2125)
-* BFD_RELOC_8_BASEREL: howto manager. (line 99)
-* BFD_RELOC_8_FFnn: howto manager. (line 103)
-* BFD_RELOC_8_GOT_PCREL: howto manager. (line 53)
-* BFD_RELOC_8_GOTOFF: howto manager. (line 59)
-* BFD_RELOC_8_PCREL: howto manager. (line 40)
-* BFD_RELOC_8_PLT_PCREL: howto manager. (line 64)
-* BFD_RELOC_8_PLTOFF: howto manager. (line 71)
-* BFD_RELOC_ALPHA_BOH: howto manager. (line 315)
-* BFD_RELOC_ALPHA_BRSGP: howto manager. (line 298)
-* BFD_RELOC_ALPHA_BSR: howto manager. (line 307)
-* BFD_RELOC_ALPHA_CODEADDR: howto manager. (line 289)
-* BFD_RELOC_ALPHA_DTPMOD64: howto manager. (line 321)
-* BFD_RELOC_ALPHA_DTPREL16: howto manager. (line 326)
-* BFD_RELOC_ALPHA_DTPREL64: howto manager. (line 323)
-* BFD_RELOC_ALPHA_DTPREL_HI16: howto manager. (line 324)
-* BFD_RELOC_ALPHA_DTPREL_LO16: howto manager. (line 325)
-* BFD_RELOC_ALPHA_ELF_LITERAL: howto manager. (line 254)
-* BFD_RELOC_ALPHA_GOTDTPREL16: howto manager. (line 322)
-* BFD_RELOC_ALPHA_GOTTPREL16: howto manager. (line 327)
-* BFD_RELOC_ALPHA_GPDISP: howto manager. (line 248)
-* BFD_RELOC_ALPHA_GPDISP_HI16: howto manager. (line 234)
-* BFD_RELOC_ALPHA_GPDISP_LO16: howto manager. (line 242)
-* BFD_RELOC_ALPHA_GPREL_HI16: howto manager. (line 293)
-* BFD_RELOC_ALPHA_GPREL_LO16: howto manager. (line 294)
-* BFD_RELOC_ALPHA_HINT: howto manager. (line 280)
-* BFD_RELOC_ALPHA_LDA: howto manager. (line 311)
-* BFD_RELOC_ALPHA_LINKAGE: howto manager. (line 285)
-* BFD_RELOC_ALPHA_LITERAL: howto manager. (line 253)
-* BFD_RELOC_ALPHA_LITUSE: howto manager. (line 255)
-* BFD_RELOC_ALPHA_NOP: howto manager. (line 303)
-* BFD_RELOC_ALPHA_TLSGD: howto manager. (line 319)
-* BFD_RELOC_ALPHA_TLSLDM: howto manager. (line 320)
-* BFD_RELOC_ALPHA_TPREL16: howto manager. (line 331)
-* BFD_RELOC_ALPHA_TPREL64: howto manager. (line 328)
-* BFD_RELOC_ALPHA_TPREL_HI16: howto manager. (line 329)
-* BFD_RELOC_ALPHA_TPREL_LO16: howto manager. (line 330)
-* BFD_RELOC_ARC_B22_PCREL: howto manager. (line 954)
-* BFD_RELOC_ARC_B26: howto manager. (line 959)
-* BFD_RELOC_ARM_ADR_IMM: howto manager. (line 840)
-* BFD_RELOC_ARM_ADRL_IMMEDIATE: howto manager. (line 826)
-* BFD_RELOC_ARM_ALU_PC_G0: howto manager. (line 790)
-* BFD_RELOC_ARM_ALU_PC_G0_NC: howto manager. (line 789)
-* BFD_RELOC_ARM_ALU_PC_G1: howto manager. (line 792)
-* BFD_RELOC_ARM_ALU_PC_G1_NC: howto manager. (line 791)
-* BFD_RELOC_ARM_ALU_PC_G2: howto manager. (line 793)
-* BFD_RELOC_ARM_ALU_SB_G0: howto manager. (line 804)
-* BFD_RELOC_ARM_ALU_SB_G0_NC: howto manager. (line 803)
-* BFD_RELOC_ARM_ALU_SB_G1: howto manager. (line 806)
-* BFD_RELOC_ARM_ALU_SB_G1_NC: howto manager. (line 805)
-* BFD_RELOC_ARM_ALU_SB_G2: howto manager. (line 807)
-* BFD_RELOC_ARM_CP_OFF_IMM: howto manager. (line 836)
-* BFD_RELOC_ARM_CP_OFF_IMM_S2: howto manager. (line 837)
-* BFD_RELOC_ARM_GLOB_DAT: howto manager. (line 764)
-* BFD_RELOC_ARM_GOT32: howto manager. (line 765)
-* BFD_RELOC_ARM_GOT_PREL: howto manager. (line 770)
-* BFD_RELOC_ARM_GOTOFF: howto manager. (line 768)
-* BFD_RELOC_ARM_GOTPC: howto manager. (line 769)
-* BFD_RELOC_ARM_HVC: howto manager. (line 833)
-* BFD_RELOC_ARM_HWLITERAL: howto manager. (line 847)
-* BFD_RELOC_ARM_IMMEDIATE: howto manager. (line 825)
-* BFD_RELOC_ARM_IN_POOL: howto manager. (line 843)
-* BFD_RELOC_ARM_IRELATIVE: howto manager. (line 822)
-* BFD_RELOC_ARM_JUMP_SLOT: howto manager. (line 763)
-* BFD_RELOC_ARM_LDC_PC_G0: howto manager. (line 800)
-* BFD_RELOC_ARM_LDC_PC_G1: howto manager. (line 801)
-* BFD_RELOC_ARM_LDC_PC_G2: howto manager. (line 802)
-* BFD_RELOC_ARM_LDC_SB_G0: howto manager. (line 814)
-* BFD_RELOC_ARM_LDC_SB_G1: howto manager. (line 815)
-* BFD_RELOC_ARM_LDC_SB_G2: howto manager. (line 816)
-* BFD_RELOC_ARM_LDR_IMM: howto manager. (line 841)
-* BFD_RELOC_ARM_LDR_PC_G0: howto manager. (line 794)
-* BFD_RELOC_ARM_LDR_PC_G1: howto manager. (line 795)
-* BFD_RELOC_ARM_LDR_PC_G2: howto manager. (line 796)
-* BFD_RELOC_ARM_LDR_SB_G0: howto manager. (line 808)
-* BFD_RELOC_ARM_LDR_SB_G1: howto manager. (line 809)
-* BFD_RELOC_ARM_LDR_SB_G2: howto manager. (line 810)
-* BFD_RELOC_ARM_LDRS_PC_G0: howto manager. (line 797)
-* BFD_RELOC_ARM_LDRS_PC_G1: howto manager. (line 798)
-* BFD_RELOC_ARM_LDRS_PC_G2: howto manager. (line 799)
-* BFD_RELOC_ARM_LDRS_SB_G0: howto manager. (line 811)
-* BFD_RELOC_ARM_LDRS_SB_G1: howto manager. (line 812)
-* BFD_RELOC_ARM_LDRS_SB_G2: howto manager. (line 813)
-* BFD_RELOC_ARM_LITERAL: howto manager. (line 842)
-* BFD_RELOC_ARM_MOVT: howto manager. (line 754)
-* BFD_RELOC_ARM_MOVT_PCREL: howto manager. (line 756)
-* BFD_RELOC_ARM_MOVW: howto manager. (line 753)
-* BFD_RELOC_ARM_MOVW_PCREL: howto manager. (line 755)
-* BFD_RELOC_ARM_MULTI: howto manager. (line 835)
-* BFD_RELOC_ARM_OFFSET_IMM: howto manager. (line 727)
-* BFD_RELOC_ARM_OFFSET_IMM8: howto manager. (line 844)
-* BFD_RELOC_ARM_PCREL_BLX: howto manager. (line 698)
-* BFD_RELOC_ARM_PCREL_BRANCH: howto manager. (line 694)
-* BFD_RELOC_ARM_PCREL_CALL: howto manager. (line 708)
-* BFD_RELOC_ARM_PCREL_JUMP: howto manager. (line 712)
-* BFD_RELOC_ARM_PLT32: howto manager. (line 766)
-* BFD_RELOC_ARM_PREL31: howto manager. (line 750)
-* BFD_RELOC_ARM_RELATIVE: howto manager. (line 767)
-* BFD_RELOC_ARM_ROSEGREL32: howto manager. (line 739)
-* BFD_RELOC_ARM_SBREL32: howto manager. (line 742)
-* BFD_RELOC_ARM_SHIFT_IMM: howto manager. (line 831)
-* BFD_RELOC_ARM_SMC: howto manager. (line 832)
-* BFD_RELOC_ARM_SWI: howto manager. (line 834)
-* BFD_RELOC_ARM_T32_ADD_IMM: howto manager. (line 828)
-* BFD_RELOC_ARM_T32_ADD_PC12: howto manager. (line 830)
-* BFD_RELOC_ARM_T32_CP_OFF_IMM: howto manager. (line 838)
-* BFD_RELOC_ARM_T32_CP_OFF_IMM_S2: howto manager. (line 839)
-* BFD_RELOC_ARM_T32_IMM12: howto manager. (line 829)
-* BFD_RELOC_ARM_T32_IMMEDIATE: howto manager. (line 827)
-* BFD_RELOC_ARM_T32_OFFSET_IMM: howto manager. (line 846)
-* BFD_RELOC_ARM_T32_OFFSET_U8: howto manager. (line 845)
-* BFD_RELOC_ARM_TARGET1: howto manager. (line 735)
-* BFD_RELOC_ARM_TARGET2: howto manager. (line 745)
-* BFD_RELOC_ARM_THM_TLS_CALL: howto manager. (line 783)
-* BFD_RELOC_ARM_THM_TLS_DESCSEQ: howto manager. (line 785)
-* BFD_RELOC_ARM_THUMB_ADD: howto manager. (line 848)
-* BFD_RELOC_ARM_THUMB_IMM: howto manager. (line 849)
-* BFD_RELOC_ARM_THUMB_MOVT: howto manager. (line 758)
-* BFD_RELOC_ARM_THUMB_MOVT_PCREL: howto manager. (line 760)
-* BFD_RELOC_ARM_THUMB_MOVW: howto manager. (line 757)
-* BFD_RELOC_ARM_THUMB_MOVW_PCREL: howto manager. (line 759)
-* BFD_RELOC_ARM_THUMB_OFFSET: howto manager. (line 731)
-* BFD_RELOC_ARM_THUMB_SHIFT: howto manager. (line 850)
-* BFD_RELOC_ARM_TLS_CALL: howto manager. (line 782)
-* BFD_RELOC_ARM_TLS_DESC: howto manager. (line 786)
-* BFD_RELOC_ARM_TLS_DESCSEQ: howto manager. (line 784)
-* BFD_RELOC_ARM_TLS_DTPMOD32: howto manager. (line 777)
-* BFD_RELOC_ARM_TLS_DTPOFF32: howto manager. (line 776)
-* BFD_RELOC_ARM_TLS_GD32: howto manager. (line 773)
-* BFD_RELOC_ARM_TLS_GOTDESC: howto manager. (line 781)
-* BFD_RELOC_ARM_TLS_IE32: howto manager. (line 779)
-* BFD_RELOC_ARM_TLS_LDM32: howto manager. (line 775)
-* BFD_RELOC_ARM_TLS_LDO32: howto manager. (line 774)
-* BFD_RELOC_ARM_TLS_LE32: howto manager. (line 780)
-* BFD_RELOC_ARM_TLS_TPOFF32: howto manager. (line 778)
-* BFD_RELOC_ARM_V4BX: howto manager. (line 819)
-* BFD_RELOC_AVR_13_PCREL: howto manager. (line 1517)
-* BFD_RELOC_AVR_16_PM: howto manager. (line 1521)
-* BFD_RELOC_AVR_6: howto manager. (line 1608)
-* BFD_RELOC_AVR_6_ADIW: howto manager. (line 1612)
-* BFD_RELOC_AVR_7_PCREL: howto manager. (line 1513)
-* BFD_RELOC_AVR_CALL: howto manager. (line 1600)
-* BFD_RELOC_AVR_HH8_LDI: howto manager. (line 1533)
-* BFD_RELOC_AVR_HH8_LDI_NEG: howto manager. (line 1552)
-* BFD_RELOC_AVR_HH8_LDI_PM: howto manager. (line 1581)
-* BFD_RELOC_AVR_HH8_LDI_PM_NEG: howto manager. (line 1595)
-* BFD_RELOC_AVR_HI8_LDI: howto manager. (line 1529)
-* BFD_RELOC_AVR_HI8_LDI_GS: howto manager. (line 1575)
-* BFD_RELOC_AVR_HI8_LDI_NEG: howto manager. (line 1547)
-* BFD_RELOC_AVR_HI8_LDI_PM: howto manager. (line 1571)
-* BFD_RELOC_AVR_HI8_LDI_PM_NEG: howto manager. (line 1590)
-* BFD_RELOC_AVR_LDI: howto manager. (line 1604)
-* BFD_RELOC_AVR_LO8_LDI: howto manager. (line 1525)
-* BFD_RELOC_AVR_LO8_LDI_GS: howto manager. (line 1565)
-* BFD_RELOC_AVR_LO8_LDI_NEG: howto manager. (line 1542)
-* BFD_RELOC_AVR_LO8_LDI_PM: howto manager. (line 1561)
-* BFD_RELOC_AVR_LO8_LDI_PM_NEG: howto manager. (line 1586)
-* BFD_RELOC_AVR_MS8_LDI: howto manager. (line 1538)
-* BFD_RELOC_AVR_MS8_LDI_NEG: howto manager. (line 1557)
-* BFD_RELOC_BFIN_10_PCREL: howto manager. (line 979)
-* BFD_RELOC_BFIN_11_PCREL: howto manager. (line 982)
-* BFD_RELOC_BFIN_12_PCREL_JUMP: howto manager. (line 985)
-* BFD_RELOC_BFIN_12_PCREL_JUMP_S: howto manager. (line 988)
-* BFD_RELOC_BFIN_16_HIGH: howto manager. (line 967)
-* BFD_RELOC_BFIN_16_IMM: howto manager. (line 964)
-* BFD_RELOC_BFIN_16_LOW: howto manager. (line 976)
-* BFD_RELOC_BFIN_24_PCREL_CALL_X: howto manager. (line 991)
-* BFD_RELOC_BFIN_24_PCREL_JUMP_L: howto manager. (line 994)
-* BFD_RELOC_BFIN_4_PCREL: howto manager. (line 970)
-* BFD_RELOC_BFIN_5_PCREL: howto manager. (line 973)
-* BFD_RELOC_BFIN_FUNCDESC: howto manager. (line 1000)
-* BFD_RELOC_BFIN_FUNCDESC_GOT17M4: howto manager. (line 1001)
-* BFD_RELOC_BFIN_FUNCDESC_GOTHI: howto manager. (line 1002)
-* BFD_RELOC_BFIN_FUNCDESC_GOTLO: howto manager. (line 1003)
-* BFD_RELOC_BFIN_FUNCDESC_GOTOFF17M4: howto manager. (line 1005)
-* BFD_RELOC_BFIN_FUNCDESC_GOTOFFHI: howto manager. (line 1006)
-* BFD_RELOC_BFIN_FUNCDESC_GOTOFFLO: howto manager. (line 1007)
-* BFD_RELOC_BFIN_FUNCDESC_VALUE: howto manager. (line 1004)
-* BFD_RELOC_BFIN_GOT: howto manager. (line 1013)
-* BFD_RELOC_BFIN_GOT17M4: howto manager. (line 997)
-* BFD_RELOC_BFIN_GOTHI: howto manager. (line 998)
-* BFD_RELOC_BFIN_GOTLO: howto manager. (line 999)
-* BFD_RELOC_BFIN_GOTOFF17M4: howto manager. (line 1008)
-* BFD_RELOC_BFIN_GOTOFFHI: howto manager. (line 1009)
-* BFD_RELOC_BFIN_GOTOFFLO: howto manager. (line 1010)
-* BFD_RELOC_BFIN_PLTPC: howto manager. (line 1016)
-* BFD_RELOC_C6000_ABS_H16: howto manager. (line 1376)
-* BFD_RELOC_C6000_ABS_L16: howto manager. (line 1375)
-* BFD_RELOC_C6000_ABS_S16: howto manager. (line 1374)
-* BFD_RELOC_C6000_ALIGN: howto manager. (line 1397)
-* BFD_RELOC_C6000_COPY: howto manager. (line 1392)
-* BFD_RELOC_C6000_DSBT_INDEX: howto manager. (line 1390)
-* BFD_RELOC_C6000_EHTYPE: howto manager. (line 1394)
-* BFD_RELOC_C6000_FPHEAD: howto manager. (line 1398)
-* BFD_RELOC_C6000_JUMP_SLOT: howto manager. (line 1393)
-* BFD_RELOC_C6000_NOCMP: howto manager. (line 1399)
-* BFD_RELOC_C6000_PCR_H16: howto manager. (line 1395)
-* BFD_RELOC_C6000_PCR_L16: howto manager. (line 1396)
-* BFD_RELOC_C6000_PCR_S10: howto manager. (line 1372)
-* BFD_RELOC_C6000_PCR_S12: howto manager. (line 1371)
-* BFD_RELOC_C6000_PCR_S21: howto manager. (line 1370)
-* BFD_RELOC_C6000_PCR_S7: howto manager. (line 1373)
-* BFD_RELOC_C6000_PREL31: howto manager. (line 1391)
-* BFD_RELOC_C6000_SBR_GOT_H16_W: howto manager. (line 1389)
-* BFD_RELOC_C6000_SBR_GOT_L16_W: howto manager. (line 1388)
-* BFD_RELOC_C6000_SBR_GOT_U15_W: howto manager. (line 1387)
-* BFD_RELOC_C6000_SBR_H16_B: howto manager. (line 1384)
-* BFD_RELOC_C6000_SBR_H16_H: howto manager. (line 1385)
-* BFD_RELOC_C6000_SBR_H16_W: howto manager. (line 1386)
-* BFD_RELOC_C6000_SBR_L16_B: howto manager. (line 1381)
-* BFD_RELOC_C6000_SBR_L16_H: howto manager. (line 1382)
-* BFD_RELOC_C6000_SBR_L16_W: howto manager. (line 1383)
-* BFD_RELOC_C6000_SBR_S16: howto manager. (line 1380)
-* BFD_RELOC_C6000_SBR_U15_B: howto manager. (line 1377)
-* BFD_RELOC_C6000_SBR_U15_H: howto manager. (line 1378)
-* BFD_RELOC_C6000_SBR_U15_W: howto manager. (line 1379)
-* bfd_reloc_code_type: howto manager. (line 10)
-* BFD_RELOC_CR16_ABS20: howto manager. (line 2013)
-* BFD_RELOC_CR16_ABS24: howto manager. (line 2014)
-* BFD_RELOC_CR16_DISP16: howto manager. (line 2024)
-* BFD_RELOC_CR16_DISP20: howto manager. (line 2025)
-* BFD_RELOC_CR16_DISP24: howto manager. (line 2026)
-* BFD_RELOC_CR16_DISP24a: howto manager. (line 2027)
-* BFD_RELOC_CR16_DISP4: howto manager. (line 2022)
-* BFD_RELOC_CR16_DISP8: howto manager. (line 2023)
-* BFD_RELOC_CR16_GLOB_DAT: howto manager. (line 2033)
-* BFD_RELOC_CR16_GOT_REGREL20: howto manager. (line 2031)
-* BFD_RELOC_CR16_GOTC_REGREL20: howto manager. (line 2032)
-* BFD_RELOC_CR16_IMM16: howto manager. (line 2017)
-* BFD_RELOC_CR16_IMM20: howto manager. (line 2018)
-* BFD_RELOC_CR16_IMM24: howto manager. (line 2019)
-* BFD_RELOC_CR16_IMM32: howto manager. (line 2020)
-* BFD_RELOC_CR16_IMM32a: howto manager. (line 2021)
-* BFD_RELOC_CR16_IMM4: howto manager. (line 2015)
-* BFD_RELOC_CR16_IMM8: howto manager. (line 2016)
-* BFD_RELOC_CR16_NUM16: howto manager. (line 2002)
-* BFD_RELOC_CR16_NUM32: howto manager. (line 2003)
-* BFD_RELOC_CR16_NUM32a: howto manager. (line 2004)
-* BFD_RELOC_CR16_NUM8: howto manager. (line 2001)
-* BFD_RELOC_CR16_REGREL0: howto manager. (line 2005)
-* BFD_RELOC_CR16_REGREL14: howto manager. (line 2008)
-* BFD_RELOC_CR16_REGREL14a: howto manager. (line 2009)
-* BFD_RELOC_CR16_REGREL16: howto manager. (line 2010)
-* BFD_RELOC_CR16_REGREL20: howto manager. (line 2011)
-* BFD_RELOC_CR16_REGREL20a: howto manager. (line 2012)
-* BFD_RELOC_CR16_REGREL4: howto manager. (line 2006)
-* BFD_RELOC_CR16_REGREL4a: howto manager. (line 2007)
-* BFD_RELOC_CR16_SWITCH16: howto manager. (line 2029)
-* BFD_RELOC_CR16_SWITCH32: howto manager. (line 2030)
-* BFD_RELOC_CR16_SWITCH8: howto manager. (line 2028)
-* BFD_RELOC_CRIS_16_DTPREL: howto manager. (line 2104)
-* BFD_RELOC_CRIS_16_GOT: howto manager. (line 2080)
-* BFD_RELOC_CRIS_16_GOT_GD: howto manager. (line 2100)
-* BFD_RELOC_CRIS_16_GOT_TPREL: howto manager. (line 2106)
-* BFD_RELOC_CRIS_16_GOTPLT: howto manager. (line 2086)
-* BFD_RELOC_CRIS_16_TPREL: howto manager. (line 2108)
-* BFD_RELOC_CRIS_32_DTPREL: howto manager. (line 2103)
-* BFD_RELOC_CRIS_32_GD: howto manager. (line 2101)
-* BFD_RELOC_CRIS_32_GOT: howto manager. (line 2077)
-* BFD_RELOC_CRIS_32_GOT_GD: howto manager. (line 2099)
-* BFD_RELOC_CRIS_32_GOT_TPREL: howto manager. (line 2105)
-* BFD_RELOC_CRIS_32_GOTPLT: howto manager. (line 2083)
-* BFD_RELOC_CRIS_32_GOTREL: howto manager. (line 2089)
-* BFD_RELOC_CRIS_32_IE: howto manager. (line 2110)
-* BFD_RELOC_CRIS_32_PLT_GOTREL: howto manager. (line 2092)
-* BFD_RELOC_CRIS_32_PLT_PCREL: howto manager. (line 2095)
-* BFD_RELOC_CRIS_32_TPREL: howto manager. (line 2107)
-* BFD_RELOC_CRIS_BDISP8: howto manager. (line 2058)
-* BFD_RELOC_CRIS_COPY: howto manager. (line 2071)
-* BFD_RELOC_CRIS_DTP: howto manager. (line 2102)
-* BFD_RELOC_CRIS_DTPMOD: howto manager. (line 2109)
-* BFD_RELOC_CRIS_GLOB_DAT: howto manager. (line 2072)
-* BFD_RELOC_CRIS_JUMP_SLOT: howto manager. (line 2073)
-* BFD_RELOC_CRIS_LAPCQ_OFFSET: howto manager. (line 2066)
-* BFD_RELOC_CRIS_RELATIVE: howto manager. (line 2074)
-* BFD_RELOC_CRIS_SIGNED_16: howto manager. (line 2064)
-* BFD_RELOC_CRIS_SIGNED_6: howto manager. (line 2060)
-* BFD_RELOC_CRIS_SIGNED_8: howto manager. (line 2062)
-* BFD_RELOC_CRIS_UNSIGNED_16: howto manager. (line 2065)
-* BFD_RELOC_CRIS_UNSIGNED_4: howto manager. (line 2067)
-* BFD_RELOC_CRIS_UNSIGNED_5: howto manager. (line 2059)
-* BFD_RELOC_CRIS_UNSIGNED_6: howto manager. (line 2061)
-* BFD_RELOC_CRIS_UNSIGNED_8: howto manager. (line 2063)
-* BFD_RELOC_CRX_ABS16: howto manager. (line 2046)
-* BFD_RELOC_CRX_ABS32: howto manager. (line 2047)
-* BFD_RELOC_CRX_IMM16: howto manager. (line 2051)
-* BFD_RELOC_CRX_IMM32: howto manager. (line 2052)
-* BFD_RELOC_CRX_NUM16: howto manager. (line 2049)
-* BFD_RELOC_CRX_NUM32: howto manager. (line 2050)
-* BFD_RELOC_CRX_NUM8: howto manager. (line 2048)
-* BFD_RELOC_CRX_REGREL12: howto manager. (line 2042)
-* BFD_RELOC_CRX_REGREL22: howto manager. (line 2043)
-* BFD_RELOC_CRX_REGREL28: howto manager. (line 2044)
-* BFD_RELOC_CRX_REGREL32: howto manager. (line 2045)
-* BFD_RELOC_CRX_REL16: howto manager. (line 2039)
-* BFD_RELOC_CRX_REL24: howto manager. (line 2040)
-* BFD_RELOC_CRX_REL32: howto manager. (line 2041)
-* BFD_RELOC_CRX_REL4: howto manager. (line 2036)
-* BFD_RELOC_CRX_REL8: howto manager. (line 2037)
-* BFD_RELOC_CRX_REL8_CMP: howto manager. (line 2038)
-* BFD_RELOC_CRX_SWITCH16: howto manager. (line 2054)
-* BFD_RELOC_CRX_SWITCH32: howto manager. (line 2055)
-* BFD_RELOC_CRX_SWITCH8: howto manager. (line 2053)
-* BFD_RELOC_CTOR: howto manager. (line 688)
-* BFD_RELOC_D10V_10_PCREL_L: howto manager. (line 1083)
-* BFD_RELOC_D10V_10_PCREL_R: howto manager. (line 1079)
-* BFD_RELOC_D10V_18: howto manager. (line 1088)
-* BFD_RELOC_D10V_18_PCREL: howto manager. (line 1091)
-* BFD_RELOC_D30V_15: howto manager. (line 1106)
-* BFD_RELOC_D30V_15_PCREL: howto manager. (line 1110)
-* BFD_RELOC_D30V_15_PCREL_R: howto manager. (line 1114)
-* BFD_RELOC_D30V_21: howto manager. (line 1119)
-* BFD_RELOC_D30V_21_PCREL: howto manager. (line 1123)
-* BFD_RELOC_D30V_21_PCREL_R: howto manager. (line 1127)
-* BFD_RELOC_D30V_32: howto manager. (line 1132)
-* BFD_RELOC_D30V_32_PCREL: howto manager. (line 1135)
-* BFD_RELOC_D30V_6: howto manager. (line 1094)
-* BFD_RELOC_D30V_9_PCREL: howto manager. (line 1097)
-* BFD_RELOC_D30V_9_PCREL_R: howto manager. (line 1101)
-* BFD_RELOC_DLX_HI16_S: howto manager. (line 1138)
-* BFD_RELOC_DLX_JMP26: howto manager. (line 1144)
-* BFD_RELOC_DLX_LO16: howto manager. (line 1141)
-* BFD_RELOC_FR30_10_IN_8: howto manager. (line 1421)
-* BFD_RELOC_FR30_12_PCREL: howto manager. (line 1429)
-* BFD_RELOC_FR30_20: howto manager. (line 1405)
-* BFD_RELOC_FR30_48: howto manager. (line 1402)
-* BFD_RELOC_FR30_6_IN_4: howto manager. (line 1409)
-* BFD_RELOC_FR30_8_IN_8: howto manager. (line 1413)
-* BFD_RELOC_FR30_9_IN_8: howto manager. (line 1417)
-* BFD_RELOC_FR30_9_PCREL: howto manager. (line 1425)
-* BFD_RELOC_FRV_FUNCDESC: howto manager. (line 440)
-* BFD_RELOC_FRV_FUNCDESC_GOT12: howto manager. (line 441)
-* BFD_RELOC_FRV_FUNCDESC_GOTHI: howto manager. (line 442)
-* BFD_RELOC_FRV_FUNCDESC_GOTLO: howto manager. (line 443)
-* BFD_RELOC_FRV_FUNCDESC_GOTOFF12: howto manager. (line 445)
-* BFD_RELOC_FRV_FUNCDESC_GOTOFFHI: howto manager. (line 446)
-* BFD_RELOC_FRV_FUNCDESC_GOTOFFLO: howto manager. (line 447)
-* BFD_RELOC_FRV_FUNCDESC_VALUE: howto manager. (line 444)
-* BFD_RELOC_FRV_GETTLSOFF: howto manager. (line 451)
-* BFD_RELOC_FRV_GETTLSOFF_RELAX: howto manager. (line 464)
-* BFD_RELOC_FRV_GOT12: howto manager. (line 437)
-* BFD_RELOC_FRV_GOTHI: howto manager. (line 438)
-* BFD_RELOC_FRV_GOTLO: howto manager. (line 439)
-* BFD_RELOC_FRV_GOTOFF12: howto manager. (line 448)
-* BFD_RELOC_FRV_GOTOFFHI: howto manager. (line 449)
-* BFD_RELOC_FRV_GOTOFFLO: howto manager. (line 450)
-* BFD_RELOC_FRV_GOTTLSDESC12: howto manager. (line 453)
-* BFD_RELOC_FRV_GOTTLSDESCHI: howto manager. (line 454)
-* BFD_RELOC_FRV_GOTTLSDESCLO: howto manager. (line 455)
-* BFD_RELOC_FRV_GOTTLSOFF12: howto manager. (line 459)
-* BFD_RELOC_FRV_GOTTLSOFFHI: howto manager. (line 460)
-* BFD_RELOC_FRV_GOTTLSOFFLO: howto manager. (line 461)
-* BFD_RELOC_FRV_GPREL12: howto manager. (line 432)
-* BFD_RELOC_FRV_GPREL32: howto manager. (line 434)
-* BFD_RELOC_FRV_GPRELHI: howto manager. (line 435)
-* BFD_RELOC_FRV_GPRELLO: howto manager. (line 436)
-* BFD_RELOC_FRV_GPRELU12: howto manager. (line 433)
-* BFD_RELOC_FRV_HI16: howto manager. (line 431)
-* BFD_RELOC_FRV_LABEL16: howto manager. (line 428)
-* BFD_RELOC_FRV_LABEL24: howto manager. (line 429)
-* BFD_RELOC_FRV_LO16: howto manager. (line 430)
-* BFD_RELOC_FRV_TLSDESC_RELAX: howto manager. (line 463)
-* BFD_RELOC_FRV_TLSDESC_VALUE: howto manager. (line 452)
-* BFD_RELOC_FRV_TLSMOFF: howto manager. (line 466)
-* BFD_RELOC_FRV_TLSMOFF12: howto manager. (line 456)
-* BFD_RELOC_FRV_TLSMOFFHI: howto manager. (line 457)
-* BFD_RELOC_FRV_TLSMOFFLO: howto manager. (line 458)
-* BFD_RELOC_FRV_TLSOFF: howto manager. (line 462)
-* BFD_RELOC_FRV_TLSOFF_RELAX: howto manager. (line 465)
-* BFD_RELOC_GPREL16: howto manager. (line 121)
-* BFD_RELOC_GPREL32: howto manager. (line 122)
-* BFD_RELOC_H8_DIR16A8: howto manager. (line 2151)
-* BFD_RELOC_H8_DIR16R8: howto manager. (line 2152)
-* BFD_RELOC_H8_DIR24A8: howto manager. (line 2153)
-* BFD_RELOC_H8_DIR24R8: howto manager. (line 2154)
-* BFD_RELOC_H8_DIR32A16: howto manager. (line 2155)
-* BFD_RELOC_HI16: howto manager. (line 344)
-* BFD_RELOC_HI16_BASEREL: howto manager. (line 97)
-* BFD_RELOC_HI16_GOTOFF: howto manager. (line 57)
-* BFD_RELOC_HI16_PCREL: howto manager. (line 356)
-* BFD_RELOC_HI16_PLTOFF: howto manager. (line 69)
-* BFD_RELOC_HI16_S: howto manager. (line 347)
-* BFD_RELOC_HI16_S_BASEREL: howto manager. (line 98)
-* BFD_RELOC_HI16_S_GOTOFF: howto manager. (line 58)
-* BFD_RELOC_HI16_S_PCREL: howto manager. (line 359)
-* BFD_RELOC_HI16_S_PLTOFF: howto manager. (line 70)
-* BFD_RELOC_HI22: howto manager. (line 116)
-* BFD_RELOC_I370_D12: howto manager. (line 685)
-* BFD_RELOC_I960_CALLJ: howto manager. (line 128)
-* BFD_RELOC_IA64_COPY: howto manager. (line 1895)
-* BFD_RELOC_IA64_DIR32LSB: howto manager. (line 1840)
-* BFD_RELOC_IA64_DIR32MSB: howto manager. (line 1839)
-* BFD_RELOC_IA64_DIR64LSB: howto manager. (line 1842)
-* BFD_RELOC_IA64_DIR64MSB: howto manager. (line 1841)
-* BFD_RELOC_IA64_DTPMOD64LSB: howto manager. (line 1905)
-* BFD_RELOC_IA64_DTPMOD64MSB: howto manager. (line 1904)
-* BFD_RELOC_IA64_DTPREL14: howto manager. (line 1907)
-* BFD_RELOC_IA64_DTPREL22: howto manager. (line 1908)
-* BFD_RELOC_IA64_DTPREL32LSB: howto manager. (line 1911)
-* BFD_RELOC_IA64_DTPREL32MSB: howto manager. (line 1910)
-* BFD_RELOC_IA64_DTPREL64I: howto manager. (line 1909)
-* BFD_RELOC_IA64_DTPREL64LSB: howto manager. (line 1913)
-* BFD_RELOC_IA64_DTPREL64MSB: howto manager. (line 1912)
-* BFD_RELOC_IA64_FPTR32LSB: howto manager. (line 1857)
-* BFD_RELOC_IA64_FPTR32MSB: howto manager. (line 1856)
-* BFD_RELOC_IA64_FPTR64I: howto manager. (line 1855)
-* BFD_RELOC_IA64_FPTR64LSB: howto manager. (line 1859)
-* BFD_RELOC_IA64_FPTR64MSB: howto manager. (line 1858)
-* BFD_RELOC_IA64_GPREL22: howto manager. (line 1843)
-* BFD_RELOC_IA64_GPREL32LSB: howto manager. (line 1846)
-* BFD_RELOC_IA64_GPREL32MSB: howto manager. (line 1845)
-* BFD_RELOC_IA64_GPREL64I: howto manager. (line 1844)
-* BFD_RELOC_IA64_GPREL64LSB: howto manager. (line 1848)
-* BFD_RELOC_IA64_GPREL64MSB: howto manager. (line 1847)
-* BFD_RELOC_IA64_IMM14: howto manager. (line 1836)
-* BFD_RELOC_IA64_IMM22: howto manager. (line 1837)
-* BFD_RELOC_IA64_IMM64: howto manager. (line 1838)
-* BFD_RELOC_IA64_IPLTLSB: howto manager. (line 1894)
-* BFD_RELOC_IA64_IPLTMSB: howto manager. (line 1893)
-* BFD_RELOC_IA64_LDXMOV: howto manager. (line 1897)
-* BFD_RELOC_IA64_LTOFF22: howto manager. (line 1849)
-* BFD_RELOC_IA64_LTOFF22X: howto manager. (line 1896)
-* BFD_RELOC_IA64_LTOFF64I: howto manager. (line 1850)
-* BFD_RELOC_IA64_LTOFF_DTPMOD22: howto manager. (line 1906)
-* BFD_RELOC_IA64_LTOFF_DTPREL22: howto manager. (line 1914)
-* BFD_RELOC_IA64_LTOFF_FPTR22: howto manager. (line 1871)
-* BFD_RELOC_IA64_LTOFF_FPTR32LSB: howto manager. (line 1874)
-* BFD_RELOC_IA64_LTOFF_FPTR32MSB: howto manager. (line 1873)
-* BFD_RELOC_IA64_LTOFF_FPTR64I: howto manager. (line 1872)
-* BFD_RELOC_IA64_LTOFF_FPTR64LSB: howto manager. (line 1876)
-* BFD_RELOC_IA64_LTOFF_FPTR64MSB: howto manager. (line 1875)
-* BFD_RELOC_IA64_LTOFF_TPREL22: howto manager. (line 1903)
-* BFD_RELOC_IA64_LTV32LSB: howto manager. (line 1890)
-* BFD_RELOC_IA64_LTV32MSB: howto manager. (line 1889)
-* BFD_RELOC_IA64_LTV64LSB: howto manager. (line 1892)
-* BFD_RELOC_IA64_LTV64MSB: howto manager. (line 1891)
-* BFD_RELOC_IA64_PCREL21B: howto manager. (line 1860)
-* BFD_RELOC_IA64_PCREL21BI: howto manager. (line 1861)
-* BFD_RELOC_IA64_PCREL21F: howto manager. (line 1863)
-* BFD_RELOC_IA64_PCREL21M: howto manager. (line 1862)
-* BFD_RELOC_IA64_PCREL22: howto manager. (line 1864)
-* BFD_RELOC_IA64_PCREL32LSB: howto manager. (line 1868)
-* BFD_RELOC_IA64_PCREL32MSB: howto manager. (line 1867)
-* BFD_RELOC_IA64_PCREL60B: howto manager. (line 1865)
-* BFD_RELOC_IA64_PCREL64I: howto manager. (line 1866)
-* BFD_RELOC_IA64_PCREL64LSB: howto manager. (line 1870)
-* BFD_RELOC_IA64_PCREL64MSB: howto manager. (line 1869)
-* BFD_RELOC_IA64_PLTOFF22: howto manager. (line 1851)
-* BFD_RELOC_IA64_PLTOFF64I: howto manager. (line 1852)
-* BFD_RELOC_IA64_PLTOFF64LSB: howto manager. (line 1854)
-* BFD_RELOC_IA64_PLTOFF64MSB: howto manager. (line 1853)
-* BFD_RELOC_IA64_REL32LSB: howto manager. (line 1886)
-* BFD_RELOC_IA64_REL32MSB: howto manager. (line 1885)
-* BFD_RELOC_IA64_REL64LSB: howto manager. (line 1888)
-* BFD_RELOC_IA64_REL64MSB: howto manager. (line 1887)
-* BFD_RELOC_IA64_SECREL32LSB: howto manager. (line 1882)
-* BFD_RELOC_IA64_SECREL32MSB: howto manager. (line 1881)
-* BFD_RELOC_IA64_SECREL64LSB: howto manager. (line 1884)
-* BFD_RELOC_IA64_SECREL64MSB: howto manager. (line 1883)
-* BFD_RELOC_IA64_SEGREL32LSB: howto manager. (line 1878)
-* BFD_RELOC_IA64_SEGREL32MSB: howto manager. (line 1877)
-* BFD_RELOC_IA64_SEGREL64LSB: howto manager. (line 1880)
-* BFD_RELOC_IA64_SEGREL64MSB: howto manager. (line 1879)
-* BFD_RELOC_IA64_TPREL14: howto manager. (line 1898)
-* BFD_RELOC_IA64_TPREL22: howto manager. (line 1899)
-* BFD_RELOC_IA64_TPREL64I: howto manager. (line 1900)
-* BFD_RELOC_IA64_TPREL64LSB: howto manager. (line 1902)
-* BFD_RELOC_IA64_TPREL64MSB: howto manager. (line 1901)
-* BFD_RELOC_IP2K_ADDR16CJP: howto manager. (line 1788)
-* BFD_RELOC_IP2K_BANK: howto manager. (line 1785)
-* BFD_RELOC_IP2K_EX8DATA: howto manager. (line 1796)
-* BFD_RELOC_IP2K_FR9: howto manager. (line 1782)
-* BFD_RELOC_IP2K_FR_OFFSET: howto manager. (line 1809)
-* BFD_RELOC_IP2K_HI8DATA: howto manager. (line 1795)
-* BFD_RELOC_IP2K_HI8INSN: howto manager. (line 1800)
-* BFD_RELOC_IP2K_LO8DATA: howto manager. (line 1794)
-* BFD_RELOC_IP2K_LO8INSN: howto manager. (line 1799)
-* BFD_RELOC_IP2K_PAGE3: howto manager. (line 1791)
-* BFD_RELOC_IP2K_PC_SKIP: howto manager. (line 1803)
-* BFD_RELOC_IP2K_TEXT: howto manager. (line 1806)
-* BFD_RELOC_IQ2000_OFFSET_16: howto manager. (line 2205)
-* BFD_RELOC_IQ2000_OFFSET_21: howto manager. (line 2206)
-* BFD_RELOC_IQ2000_UHI16: howto manager. (line 2207)
-* BFD_RELOC_LM32_16_GOT: howto manager. (line 2312)
-* BFD_RELOC_LM32_BRANCH: howto manager. (line 2311)
-* BFD_RELOC_LM32_CALL: howto manager. (line 2310)
-* BFD_RELOC_LM32_COPY: howto manager. (line 2315)
-* BFD_RELOC_LM32_GLOB_DAT: howto manager. (line 2316)
-* BFD_RELOC_LM32_GOTOFF_HI16: howto manager. (line 2313)
-* BFD_RELOC_LM32_GOTOFF_LO16: howto manager. (line 2314)
-* BFD_RELOC_LM32_JMP_SLOT: howto manager. (line 2317)
-* BFD_RELOC_LM32_RELATIVE: howto manager. (line 2318)
-* BFD_RELOC_LO10: howto manager. (line 117)
-* BFD_RELOC_LO16: howto manager. (line 353)
-* BFD_RELOC_LO16_BASEREL: howto manager. (line 96)
-* BFD_RELOC_LO16_GOTOFF: howto manager. (line 56)
-* BFD_RELOC_LO16_PCREL: howto manager. (line 362)
-* BFD_RELOC_LO16_PLTOFF: howto manager. (line 68)
-* BFD_RELOC_M32C_HI8: howto manager. (line 1147)
-* BFD_RELOC_M32C_RL_1ADDR: howto manager. (line 1149)
-* BFD_RELOC_M32C_RL_2ADDR: howto manager. (line 1150)
-* BFD_RELOC_M32C_RL_JUMP: howto manager. (line 1148)
-* BFD_RELOC_M32R_10_PCREL: howto manager. (line 1157)
-* BFD_RELOC_M32R_18_PCREL: howto manager. (line 1161)
-* BFD_RELOC_M32R_24: howto manager. (line 1153)
-* BFD_RELOC_M32R_26_PCREL: howto manager. (line 1164)
-* BFD_RELOC_M32R_26_PLTREL: howto manager. (line 1183)
-* BFD_RELOC_M32R_COPY: howto manager. (line 1184)
-* BFD_RELOC_M32R_GLOB_DAT: howto manager. (line 1185)
-* BFD_RELOC_M32R_GOT16_HI_SLO: howto manager. (line 1194)
-* BFD_RELOC_M32R_GOT16_HI_ULO: howto manager. (line 1193)
-* BFD_RELOC_M32R_GOT16_LO: howto manager. (line 1195)
-* BFD_RELOC_M32R_GOT24: howto manager. (line 1182)
-* BFD_RELOC_M32R_GOTOFF: howto manager. (line 1188)
-* BFD_RELOC_M32R_GOTOFF_HI_SLO: howto manager. (line 1190)
-* BFD_RELOC_M32R_GOTOFF_HI_ULO: howto manager. (line 1189)
-* BFD_RELOC_M32R_GOTOFF_LO: howto manager. (line 1191)
-* BFD_RELOC_M32R_GOTPC24: howto manager. (line 1192)
-* BFD_RELOC_M32R_GOTPC_HI_SLO: howto manager. (line 1197)
-* BFD_RELOC_M32R_GOTPC_HI_ULO: howto manager. (line 1196)
-* BFD_RELOC_M32R_GOTPC_LO: howto manager. (line 1198)
-* BFD_RELOC_M32R_HI16_SLO: howto manager. (line 1171)
-* BFD_RELOC_M32R_HI16_ULO: howto manager. (line 1167)
-* BFD_RELOC_M32R_JMP_SLOT: howto manager. (line 1186)
-* BFD_RELOC_M32R_LO16: howto manager. (line 1175)
-* BFD_RELOC_M32R_RELATIVE: howto manager. (line 1187)
-* BFD_RELOC_M32R_SDA16: howto manager. (line 1178)
-* BFD_RELOC_M68HC11_24: howto manager. (line 1950)
-* BFD_RELOC_M68HC11_3B: howto manager. (line 1925)
-* BFD_RELOC_M68HC11_HI8: howto manager. (line 1917)
-* BFD_RELOC_M68HC11_LO16: howto manager. (line 1939)
-* BFD_RELOC_M68HC11_LO8: howto manager. (line 1921)
-* BFD_RELOC_M68HC11_PAGE: howto manager. (line 1945)
-* BFD_RELOC_M68HC11_RL_GROUP: howto manager. (line 1934)
-* BFD_RELOC_M68HC11_RL_JUMP: howto manager. (line 1928)
-* BFD_RELOC_M68HC12_5B: howto manager. (line 1956)
-* BFD_RELOC_MACH_O_PAIR: howto manager. (line 2325)
-* BFD_RELOC_MACH_O_SECTDIFF: howto manager. (line 2321)
-* BFD_RELOC_MACH_O_X86_64_BRANCH32: howto manager. (line 2328)
-* BFD_RELOC_MACH_O_X86_64_BRANCH8: howto manager. (line 2329)
-* BFD_RELOC_MACH_O_X86_64_GOT: howto manager. (line 2333)
-* BFD_RELOC_MACH_O_X86_64_GOT_LOAD: howto manager. (line 2336)
-* BFD_RELOC_MACH_O_X86_64_PCREL32_1: howto manager. (line 2346)
-* BFD_RELOC_MACH_O_X86_64_PCREL32_2: howto manager. (line 2349)
-* BFD_RELOC_MACH_O_X86_64_PCREL32_4: howto manager. (line 2352)
-* BFD_RELOC_MACH_O_X86_64_SUBTRACTOR32: howto manager. (line 2340)
-* BFD_RELOC_MACH_O_X86_64_SUBTRACTOR64: howto manager. (line 2343)
-* BFD_RELOC_MCORE_PCREL_32: howto manager. (line 1436)
-* BFD_RELOC_MCORE_PCREL_IMM11BY2: howto manager. (line 1434)
-* BFD_RELOC_MCORE_PCREL_IMM4BY2: howto manager. (line 1435)
-* BFD_RELOC_MCORE_PCREL_IMM8BY4: howto manager. (line 1433)
-* BFD_RELOC_MCORE_PCREL_JSR_IMM11BY2: howto manager. (line 1437)
-* BFD_RELOC_MCORE_RVA: howto manager. (line 1438)
-* BFD_RELOC_MEP_16: howto manager. (line 1442)
-* BFD_RELOC_MEP_32: howto manager. (line 1443)
-* BFD_RELOC_MEP_8: howto manager. (line 1441)
-* BFD_RELOC_MEP_ADDR24A4: howto manager. (line 1458)
-* BFD_RELOC_MEP_GNU_VTENTRY: howto manager. (line 1460)
-* BFD_RELOC_MEP_GNU_VTINHERIT: howto manager. (line 1459)
-* BFD_RELOC_MEP_GPREL: howto manager. (line 1452)
-* BFD_RELOC_MEP_HI16S: howto manager. (line 1451)
-* BFD_RELOC_MEP_HI16U: howto manager. (line 1450)
-* BFD_RELOC_MEP_LOW16: howto manager. (line 1449)
-* BFD_RELOC_MEP_PCABS24A2: howto manager. (line 1448)
-* BFD_RELOC_MEP_PCREL12A2: howto manager. (line 1445)
-* BFD_RELOC_MEP_PCREL17A2: howto manager. (line 1446)
-* BFD_RELOC_MEP_PCREL24A2: howto manager. (line 1447)
-* BFD_RELOC_MEP_PCREL8A2: howto manager. (line 1444)
-* BFD_RELOC_MEP_TPREL: howto manager. (line 1453)
-* BFD_RELOC_MEP_TPREL7: howto manager. (line 1454)
-* BFD_RELOC_MEP_TPREL7A2: howto manager. (line 1455)
-* BFD_RELOC_MEP_TPREL7A4: howto manager. (line 1456)
-* BFD_RELOC_MEP_UIMM24: howto manager. (line 1457)
-* BFD_RELOC_MICROBLAZE_32_GOTOFF: howto manager. (line 2399)
-* BFD_RELOC_MICROBLAZE_32_LO: howto manager. (line 2355)
-* BFD_RELOC_MICROBLAZE_32_LO_PCREL: howto manager. (line 2359)
-* BFD_RELOC_MICROBLAZE_32_ROSDA: howto manager. (line 2363)
-* BFD_RELOC_MICROBLAZE_32_RWSDA: howto manager. (line 2367)
-* BFD_RELOC_MICROBLAZE_32_SYM_OP_SYM: howto manager. (line 2371)
-* BFD_RELOC_MICROBLAZE_64_GOT: howto manager. (line 2385)
-* BFD_RELOC_MICROBLAZE_64_GOTOFF: howto manager. (line 2394)
-* BFD_RELOC_MICROBLAZE_64_GOTPC: howto manager. (line 2380)
-* BFD_RELOC_MICROBLAZE_64_NONE: howto manager. (line 2375)
-* BFD_RELOC_MICROBLAZE_64_PLT: howto manager. (line 2389)
-* BFD_RELOC_MICROBLAZE_COPY: howto manager. (line 2403)
-* BFD_RELOC_MIPS16_CALL16: howto manager. (line 366)
-* BFD_RELOC_MIPS16_GOT16: howto manager. (line 365)
-* BFD_RELOC_MIPS16_GPREL: howto manager. (line 341)
-* BFD_RELOC_MIPS16_HI16: howto manager. (line 370)
-* BFD_RELOC_MIPS16_HI16_S: howto manager. (line 373)
-* BFD_RELOC_MIPS16_JMP: howto manager. (line 338)
-* BFD_RELOC_MIPS16_LO16: howto manager. (line 379)
-* BFD_RELOC_MIPS_CALL16: howto manager. (line 386)
-* BFD_RELOC_MIPS_CALL_HI16: howto manager. (line 389)
-* BFD_RELOC_MIPS_CALL_LO16: howto manager. (line 390)
-* BFD_RELOC_MIPS_COPY: howto manager. (line 421)
-* BFD_RELOC_MIPS_DELETE: howto manager. (line 399)
-* BFD_RELOC_MIPS_GOT16: howto manager. (line 385)
-* BFD_RELOC_MIPS_GOT_DISP: howto manager. (line 394)
-* BFD_RELOC_MIPS_GOT_HI16: howto manager. (line 387)
-* BFD_RELOC_MIPS_GOT_LO16: howto manager. (line 388)
-* BFD_RELOC_MIPS_GOT_OFST: howto manager. (line 393)
-* BFD_RELOC_MIPS_GOT_PAGE: howto manager. (line 392)
-* BFD_RELOC_MIPS_HIGHER: howto manager. (line 401)
-* BFD_RELOC_MIPS_HIGHEST: howto manager. (line 400)
-* BFD_RELOC_MIPS_INSERT_A: howto manager. (line 397)
-* BFD_RELOC_MIPS_INSERT_B: howto manager. (line 398)
-* BFD_RELOC_MIPS_JALR: howto manager. (line 405)
-* BFD_RELOC_MIPS_JMP: howto manager. (line 334)
-* BFD_RELOC_MIPS_JUMP_SLOT: howto manager. (line 422)
-* BFD_RELOC_MIPS_LITERAL: howto manager. (line 382)
-* BFD_RELOC_MIPS_REL16: howto manager. (line 403)
-* BFD_RELOC_MIPS_RELGOT: howto manager. (line 404)
-* BFD_RELOC_MIPS_SCN_DISP: howto manager. (line 402)
-* BFD_RELOC_MIPS_SHIFT5: howto manager. (line 395)
-* BFD_RELOC_MIPS_SHIFT6: howto manager. (line 396)
-* BFD_RELOC_MIPS_SUB: howto manager. (line 391)
-* BFD_RELOC_MIPS_TLS_DTPMOD32: howto manager. (line 406)
-* BFD_RELOC_MIPS_TLS_DTPMOD64: howto manager. (line 408)
-* BFD_RELOC_MIPS_TLS_DTPREL32: howto manager. (line 407)
-* BFD_RELOC_MIPS_TLS_DTPREL64: howto manager. (line 409)
-* BFD_RELOC_MIPS_TLS_DTPREL_HI16: howto manager. (line 412)
-* BFD_RELOC_MIPS_TLS_DTPREL_LO16: howto manager. (line 413)
-* BFD_RELOC_MIPS_TLS_GD: howto manager. (line 410)
-* BFD_RELOC_MIPS_TLS_GOTTPREL: howto manager. (line 414)
-* BFD_RELOC_MIPS_TLS_LDM: howto manager. (line 411)
-* BFD_RELOC_MIPS_TLS_TPREL32: howto manager. (line 415)
-* BFD_RELOC_MIPS_TLS_TPREL64: howto manager. (line 416)
-* BFD_RELOC_MIPS_TLS_TPREL_HI16: howto manager. (line 417)
-* BFD_RELOC_MIPS_TLS_TPREL_LO16: howto manager. (line 418)
-* BFD_RELOC_MMIX_ADDR19: howto manager. (line 1489)
-* BFD_RELOC_MMIX_ADDR27: howto manager. (line 1493)
-* BFD_RELOC_MMIX_BASE_PLUS_OFFSET: howto manager. (line 1505)
-* BFD_RELOC_MMIX_CBRANCH: howto manager. (line 1469)
-* BFD_RELOC_MMIX_CBRANCH_1: howto manager. (line 1471)
-* BFD_RELOC_MMIX_CBRANCH_2: howto manager. (line 1472)
-* BFD_RELOC_MMIX_CBRANCH_3: howto manager. (line 1473)
-* BFD_RELOC_MMIX_CBRANCH_J: howto manager. (line 1470)
-* BFD_RELOC_MMIX_GETA: howto manager. (line 1463)
-* BFD_RELOC_MMIX_GETA_1: howto manager. (line 1464)
-* BFD_RELOC_MMIX_GETA_2: howto manager. (line 1465)
-* BFD_RELOC_MMIX_GETA_3: howto manager. (line 1466)
-* BFD_RELOC_MMIX_JMP: howto manager. (line 1483)
-* BFD_RELOC_MMIX_JMP_1: howto manager. (line 1484)
-* BFD_RELOC_MMIX_JMP_2: howto manager. (line 1485)
-* BFD_RELOC_MMIX_JMP_3: howto manager. (line 1486)
-* BFD_RELOC_MMIX_LOCAL: howto manager. (line 1509)
-* BFD_RELOC_MMIX_PUSHJ: howto manager. (line 1476)
-* BFD_RELOC_MMIX_PUSHJ_1: howto manager. (line 1477)
-* BFD_RELOC_MMIX_PUSHJ_2: howto manager. (line 1478)
-* BFD_RELOC_MMIX_PUSHJ_3: howto manager. (line 1479)
-* BFD_RELOC_MMIX_PUSHJ_STUBBABLE: howto manager. (line 1480)
-* BFD_RELOC_MMIX_REG: howto manager. (line 1501)
-* BFD_RELOC_MMIX_REG_OR_BYTE: howto manager. (line 1497)
-* BFD_RELOC_MN10300_16_PCREL: howto manager. (line 1339)
-* BFD_RELOC_MN10300_32_PCREL: howto manager. (line 1335)
-* BFD_RELOC_MN10300_ALIGN: howto manager. (line 501)
-* BFD_RELOC_MN10300_COPY: howto manager. (line 484)
-* BFD_RELOC_MN10300_GLOB_DAT: howto manager. (line 487)
-* BFD_RELOC_MN10300_GOT16: howto manager. (line 480)
-* BFD_RELOC_MN10300_GOT24: howto manager. (line 476)
-* BFD_RELOC_MN10300_GOT32: howto manager. (line 472)
-* BFD_RELOC_MN10300_GOTOFF24: howto manager. (line 469)
-* BFD_RELOC_MN10300_JMP_SLOT: howto manager. (line 490)
-* BFD_RELOC_MN10300_RELATIVE: howto manager. (line 493)
-* BFD_RELOC_MN10300_SYM_DIFF: howto manager. (line 496)
-* BFD_RELOC_MOXIE_10_PCREL: howto manager. (line 425)
-* BFD_RELOC_MSP430_10_PCREL: howto manager. (line 2196)
-* BFD_RELOC_MSP430_16: howto manager. (line 2198)
-* BFD_RELOC_MSP430_16_BYTE: howto manager. (line 2200)
-* BFD_RELOC_MSP430_16_PCREL: howto manager. (line 2197)
-* BFD_RELOC_MSP430_16_PCREL_BYTE: howto manager. (line 2199)
-* BFD_RELOC_MSP430_2X_PCREL: howto manager. (line 2201)
-* BFD_RELOC_MSP430_RL_PCREL: howto manager. (line 2202)
-* BFD_RELOC_MT_GNU_VTENTRY: howto manager. (line 2190)
-* BFD_RELOC_MT_GNU_VTINHERIT: howto manager. (line 2187)
-* BFD_RELOC_MT_HI16: howto manager. (line 2181)
-* BFD_RELOC_MT_LO16: howto manager. (line 2184)
-* BFD_RELOC_MT_PC16: howto manager. (line 2178)
-* BFD_RELOC_MT_PCINSN8: howto manager. (line 2193)
-* BFD_RELOC_NONE: howto manager. (line 131)
-* BFD_RELOC_NS32K_DISP_16: howto manager. (line 567)
-* BFD_RELOC_NS32K_DISP_16_PCREL: howto manager. (line 570)
-* BFD_RELOC_NS32K_DISP_32: howto manager. (line 568)
-* BFD_RELOC_NS32K_DISP_32_PCREL: howto manager. (line 571)
-* BFD_RELOC_NS32K_DISP_8: howto manager. (line 566)
-* BFD_RELOC_NS32K_DISP_8_PCREL: howto manager. (line 569)
-* BFD_RELOC_NS32K_IMM_16: howto manager. (line 561)
-* BFD_RELOC_NS32K_IMM_16_PCREL: howto manager. (line 564)
-* BFD_RELOC_NS32K_IMM_32: howto manager. (line 562)
-* BFD_RELOC_NS32K_IMM_32_PCREL: howto manager. (line 565)
-* BFD_RELOC_NS32K_IMM_8: howto manager. (line 560)
-* BFD_RELOC_NS32K_IMM_8_PCREL: howto manager. (line 563)
-* BFD_RELOC_OPENRISC_ABS_26: howto manager. (line 2147)
-* BFD_RELOC_OPENRISC_REL_26: howto manager. (line 2148)
-* BFD_RELOC_PDP11_DISP_6_PCREL: howto manager. (line 575)
-* BFD_RELOC_PDP11_DISP_8_PCREL: howto manager. (line 574)
-* BFD_RELOC_PJ_CODE_DIR16: howto manager. (line 580)
-* BFD_RELOC_PJ_CODE_DIR32: howto manager. (line 581)
-* BFD_RELOC_PJ_CODE_HI16: howto manager. (line 578)
-* BFD_RELOC_PJ_CODE_LO16: howto manager. (line 579)
-* BFD_RELOC_PJ_CODE_REL16: howto manager. (line 582)
-* BFD_RELOC_PJ_CODE_REL32: howto manager. (line 583)
-* BFD_RELOC_PPC64_ADDR16_DS: howto manager. (line 628)
-* BFD_RELOC_PPC64_ADDR16_LO_DS: howto manager. (line 629)
-* BFD_RELOC_PPC64_DTPREL16_DS: howto manager. (line 677)
-* BFD_RELOC_PPC64_DTPREL16_HIGHER: howto manager. (line 679)
-* BFD_RELOC_PPC64_DTPREL16_HIGHERA: howto manager. (line 680)
-* BFD_RELOC_PPC64_DTPREL16_HIGHEST: howto manager. (line 681)
-* BFD_RELOC_PPC64_DTPREL16_HIGHESTA: howto manager. (line 682)
-* BFD_RELOC_PPC64_DTPREL16_LO_DS: howto manager. (line 678)
-* BFD_RELOC_PPC64_GOT16_DS: howto manager. (line 630)
-* BFD_RELOC_PPC64_GOT16_LO_DS: howto manager. (line 631)
-* BFD_RELOC_PPC64_HIGHER: howto manager. (line 616)
-* BFD_RELOC_PPC64_HIGHER_S: howto manager. (line 617)
-* BFD_RELOC_PPC64_HIGHEST: howto manager. (line 618)
-* BFD_RELOC_PPC64_HIGHEST_S: howto manager. (line 619)
-* BFD_RELOC_PPC64_PLT16_LO_DS: howto manager. (line 632)
-* BFD_RELOC_PPC64_PLTGOT16: howto manager. (line 624)
-* BFD_RELOC_PPC64_PLTGOT16_DS: howto manager. (line 637)
-* BFD_RELOC_PPC64_PLTGOT16_HA: howto manager. (line 627)
-* BFD_RELOC_PPC64_PLTGOT16_HI: howto manager. (line 626)
-* BFD_RELOC_PPC64_PLTGOT16_LO: howto manager. (line 625)
-* BFD_RELOC_PPC64_PLTGOT16_LO_DS: howto manager. (line 638)
-* BFD_RELOC_PPC64_SECTOFF_DS: howto manager. (line 633)
-* BFD_RELOC_PPC64_SECTOFF_LO_DS: howto manager. (line 634)
-* BFD_RELOC_PPC64_TOC: howto manager. (line 623)
-* BFD_RELOC_PPC64_TOC16_DS: howto manager. (line 635)
-* BFD_RELOC_PPC64_TOC16_HA: howto manager. (line 622)
-* BFD_RELOC_PPC64_TOC16_HI: howto manager. (line 621)
-* BFD_RELOC_PPC64_TOC16_LO: howto manager. (line 620)
-* BFD_RELOC_PPC64_TOC16_LO_DS: howto manager. (line 636)
-* BFD_RELOC_PPC64_TPREL16_DS: howto manager. (line 671)
-* BFD_RELOC_PPC64_TPREL16_HIGHER: howto manager. (line 673)
-* BFD_RELOC_PPC64_TPREL16_HIGHERA: howto manager. (line 674)
-* BFD_RELOC_PPC64_TPREL16_HIGHEST: howto manager. (line 675)
-* BFD_RELOC_PPC64_TPREL16_HIGHESTA: howto manager. (line 676)
-* BFD_RELOC_PPC64_TPREL16_LO_DS: howto manager. (line 672)
-* BFD_RELOC_PPC_B16: howto manager. (line 589)
-* BFD_RELOC_PPC_B16_BRNTAKEN: howto manager. (line 591)
-* BFD_RELOC_PPC_B16_BRTAKEN: howto manager. (line 590)
-* BFD_RELOC_PPC_B26: howto manager. (line 586)
-* BFD_RELOC_PPC_BA16: howto manager. (line 592)
-* BFD_RELOC_PPC_BA16_BRNTAKEN: howto manager. (line 594)
-* BFD_RELOC_PPC_BA16_BRTAKEN: howto manager. (line 593)
-* BFD_RELOC_PPC_BA26: howto manager. (line 587)
-* BFD_RELOC_PPC_COPY: howto manager. (line 595)
-* BFD_RELOC_PPC_DTPMOD: howto manager. (line 644)
-* BFD_RELOC_PPC_DTPREL: howto manager. (line 654)
-* BFD_RELOC_PPC_DTPREL16: howto manager. (line 650)
-* BFD_RELOC_PPC_DTPREL16_HA: howto manager. (line 653)
-* BFD_RELOC_PPC_DTPREL16_HI: howto manager. (line 652)
-* BFD_RELOC_PPC_DTPREL16_LO: howto manager. (line 651)
-* BFD_RELOC_PPC_EMB_BIT_FLD: howto manager. (line 614)
-* BFD_RELOC_PPC_EMB_MRKREF: howto manager. (line 609)
-* BFD_RELOC_PPC_EMB_NADDR16: howto manager. (line 601)
-* BFD_RELOC_PPC_EMB_NADDR16_HA: howto manager. (line 604)
-* BFD_RELOC_PPC_EMB_NADDR16_HI: howto manager. (line 603)
-* BFD_RELOC_PPC_EMB_NADDR16_LO: howto manager. (line 602)
-* BFD_RELOC_PPC_EMB_NADDR32: howto manager. (line 600)
-* BFD_RELOC_PPC_EMB_RELSDA: howto manager. (line 615)
-* BFD_RELOC_PPC_EMB_RELSEC16: howto manager. (line 610)
-* BFD_RELOC_PPC_EMB_RELST_HA: howto manager. (line 613)
-* BFD_RELOC_PPC_EMB_RELST_HI: howto manager. (line 612)
-* BFD_RELOC_PPC_EMB_RELST_LO: howto manager. (line 611)
-* BFD_RELOC_PPC_EMB_SDA21: howto manager. (line 608)
-* BFD_RELOC_PPC_EMB_SDA2I16: howto manager. (line 606)
-* BFD_RELOC_PPC_EMB_SDA2REL: howto manager. (line 607)
-* BFD_RELOC_PPC_EMB_SDAI16: howto manager. (line 605)
-* BFD_RELOC_PPC_GLOB_DAT: howto manager. (line 596)
-* BFD_RELOC_PPC_GOT_DTPREL16: howto manager. (line 667)
-* BFD_RELOC_PPC_GOT_DTPREL16_HA: howto manager. (line 670)
-* BFD_RELOC_PPC_GOT_DTPREL16_HI: howto manager. (line 669)
-* BFD_RELOC_PPC_GOT_DTPREL16_LO: howto manager. (line 668)
-* BFD_RELOC_PPC_GOT_TLSGD16: howto manager. (line 655)
-* BFD_RELOC_PPC_GOT_TLSGD16_HA: howto manager. (line 658)
-* BFD_RELOC_PPC_GOT_TLSGD16_HI: howto manager. (line 657)
-* BFD_RELOC_PPC_GOT_TLSGD16_LO: howto manager. (line 656)
-* BFD_RELOC_PPC_GOT_TLSLD16: howto manager. (line 659)
-* BFD_RELOC_PPC_GOT_TLSLD16_HA: howto manager. (line 662)
-* BFD_RELOC_PPC_GOT_TLSLD16_HI: howto manager. (line 661)
-* BFD_RELOC_PPC_GOT_TLSLD16_LO: howto manager. (line 660)
-* BFD_RELOC_PPC_GOT_TPREL16: howto manager. (line 663)
-* BFD_RELOC_PPC_GOT_TPREL16_HA: howto manager. (line 666)
-* BFD_RELOC_PPC_GOT_TPREL16_HI: howto manager. (line 665)
-* BFD_RELOC_PPC_GOT_TPREL16_LO: howto manager. (line 664)
-* BFD_RELOC_PPC_JMP_SLOT: howto manager. (line 597)
-* BFD_RELOC_PPC_LOCAL24PC: howto manager. (line 599)
-* BFD_RELOC_PPC_RELATIVE: howto manager. (line 598)
-* BFD_RELOC_PPC_TLS: howto manager. (line 641)
-* BFD_RELOC_PPC_TLSGD: howto manager. (line 642)
-* BFD_RELOC_PPC_TLSLD: howto manager. (line 643)
-* BFD_RELOC_PPC_TOC16: howto manager. (line 588)
-* BFD_RELOC_PPC_TPREL: howto manager. (line 649)
-* BFD_RELOC_PPC_TPREL16: howto manager. (line 645)
-* BFD_RELOC_PPC_TPREL16_HA: howto manager. (line 648)
-* BFD_RELOC_PPC_TPREL16_HI: howto manager. (line 647)
-* BFD_RELOC_PPC_TPREL16_LO: howto manager. (line 646)
-* BFD_RELOC_RELC: howto manager. (line 2164)
-* BFD_RELOC_RVA: howto manager. (line 100)
-* BFD_RELOC_RX_16_OP: howto manager. (line 1620)
-* BFD_RELOC_RX_16U: howto manager. (line 1624)
-* BFD_RELOC_RX_24_OP: howto manager. (line 1621)
-* BFD_RELOC_RX_24U: howto manager. (line 1625)
-* BFD_RELOC_RX_32_OP: howto manager. (line 1622)
-* BFD_RELOC_RX_8U: howto manager. (line 1623)
-* BFD_RELOC_RX_ABS16: howto manager. (line 1635)
-* BFD_RELOC_RX_ABS16_REV: howto manager. (line 1636)
-* BFD_RELOC_RX_ABS16U: howto manager. (line 1639)
-* BFD_RELOC_RX_ABS16UL: howto manager. (line 1641)
-* BFD_RELOC_RX_ABS16UW: howto manager. (line 1640)
-* BFD_RELOC_RX_ABS32: howto manager. (line 1637)
-* BFD_RELOC_RX_ABS32_REV: howto manager. (line 1638)
-* BFD_RELOC_RX_ABS8: howto manager. (line 1634)
-* BFD_RELOC_RX_DIFF: howto manager. (line 1627)
-* BFD_RELOC_RX_DIR3U_PCREL: howto manager. (line 1626)
-* BFD_RELOC_RX_GPRELB: howto manager. (line 1628)
-* BFD_RELOC_RX_GPRELL: howto manager. (line 1630)
-* BFD_RELOC_RX_GPRELW: howto manager. (line 1629)
-* BFD_RELOC_RX_NEG16: howto manager. (line 1617)
-* BFD_RELOC_RX_NEG24: howto manager. (line 1618)
-* BFD_RELOC_RX_NEG32: howto manager. (line 1619)
-* BFD_RELOC_RX_NEG8: howto manager. (line 1616)
-* BFD_RELOC_RX_OP_NEG: howto manager. (line 1633)
-* BFD_RELOC_RX_OP_SUBTRACT: howto manager. (line 1632)
-* BFD_RELOC_RX_RELAX: howto manager. (line 1642)
-* BFD_RELOC_RX_SYM: howto manager. (line 1631)
-* BFD_RELOC_SCORE16_BRANCH: howto manager. (line 1770)
-* BFD_RELOC_SCORE16_JMP: howto manager. (line 1767)
-* BFD_RELOC_SCORE_BCMP: howto manager. (line 1773)
-* BFD_RELOC_SCORE_BRANCH: howto manager. (line 1758)
-* BFD_RELOC_SCORE_CALL15: howto manager. (line 1778)
-* BFD_RELOC_SCORE_DUMMY2: howto manager. (line 1754)
-* BFD_RELOC_SCORE_DUMMY_HI16: howto manager. (line 1779)
-* BFD_RELOC_SCORE_GOT15: howto manager. (line 1776)
-* BFD_RELOC_SCORE_GOT_LO16: howto manager. (line 1777)
-* BFD_RELOC_SCORE_GPREL15: howto manager. (line 1751)
-* BFD_RELOC_SCORE_IMM30: howto manager. (line 1761)
-* BFD_RELOC_SCORE_IMM32: howto manager. (line 1764)
-* BFD_RELOC_SCORE_JMP: howto manager. (line 1755)
-* BFD_RELOC_SH_ALIGN: howto manager. (line 876)
-* BFD_RELOC_SH_CODE: howto manager. (line 877)
-* BFD_RELOC_SH_COPY: howto manager. (line 882)
-* BFD_RELOC_SH_COPY64: howto manager. (line 907)
-* BFD_RELOC_SH_COUNT: howto manager. (line 875)
-* BFD_RELOC_SH_DATA: howto manager. (line 878)
-* BFD_RELOC_SH_DISP12: howto manager. (line 858)
-* BFD_RELOC_SH_DISP12BY2: howto manager. (line 859)
-* BFD_RELOC_SH_DISP12BY4: howto manager. (line 860)
-* BFD_RELOC_SH_DISP12BY8: howto manager. (line 861)
-* BFD_RELOC_SH_DISP20: howto manager. (line 862)
-* BFD_RELOC_SH_DISP20BY8: howto manager. (line 863)
-* BFD_RELOC_SH_FUNCDESC: howto manager. (line 950)
-* BFD_RELOC_SH_GLOB_DAT: howto manager. (line 883)
-* BFD_RELOC_SH_GLOB_DAT64: howto manager. (line 908)
-* BFD_RELOC_SH_GOT10BY4: howto manager. (line 911)
-* BFD_RELOC_SH_GOT10BY8: howto manager. (line 912)
-* BFD_RELOC_SH_GOT20: howto manager. (line 944)
-* BFD_RELOC_SH_GOT_HI16: howto manager. (line 890)
-* BFD_RELOC_SH_GOT_LOW16: howto manager. (line 887)
-* BFD_RELOC_SH_GOT_MEDHI16: howto manager. (line 889)
-* BFD_RELOC_SH_GOT_MEDLOW16: howto manager. (line 888)
-* BFD_RELOC_SH_GOTFUNCDESC: howto manager. (line 946)
-* BFD_RELOC_SH_GOTFUNCDESC20: howto manager. (line 947)
-* BFD_RELOC_SH_GOTOFF20: howto manager. (line 945)
-* BFD_RELOC_SH_GOTOFF_HI16: howto manager. (line 902)
-* BFD_RELOC_SH_GOTOFF_LOW16: howto manager. (line 899)
-* BFD_RELOC_SH_GOTOFF_MEDHI16: howto manager. (line 901)
-* BFD_RELOC_SH_GOTOFF_MEDLOW16: howto manager. (line 900)
-* BFD_RELOC_SH_GOTOFFFUNCDESC: howto manager. (line 948)
-* BFD_RELOC_SH_GOTOFFFUNCDESC20: howto manager. (line 949)
-* BFD_RELOC_SH_GOTPC: howto manager. (line 886)
-* BFD_RELOC_SH_GOTPC_HI16: howto manager. (line 906)
-* BFD_RELOC_SH_GOTPC_LOW16: howto manager. (line 903)
-* BFD_RELOC_SH_GOTPC_MEDHI16: howto manager. (line 905)
-* BFD_RELOC_SH_GOTPC_MEDLOW16: howto manager. (line 904)
-* BFD_RELOC_SH_GOTPLT10BY4: howto manager. (line 913)
-* BFD_RELOC_SH_GOTPLT10BY8: howto manager. (line 914)
-* BFD_RELOC_SH_GOTPLT32: howto manager. (line 915)
-* BFD_RELOC_SH_GOTPLT_HI16: howto manager. (line 894)
-* BFD_RELOC_SH_GOTPLT_LOW16: howto manager. (line 891)
-* BFD_RELOC_SH_GOTPLT_MEDHI16: howto manager. (line 893)
-* BFD_RELOC_SH_GOTPLT_MEDLOW16: howto manager. (line 892)
-* BFD_RELOC_SH_IMM3: howto manager. (line 856)
-* BFD_RELOC_SH_IMM3U: howto manager. (line 857)
-* BFD_RELOC_SH_IMM4: howto manager. (line 864)
-* BFD_RELOC_SH_IMM4BY2: howto manager. (line 865)
-* BFD_RELOC_SH_IMM4BY4: howto manager. (line 866)
-* BFD_RELOC_SH_IMM8: howto manager. (line 867)
-* BFD_RELOC_SH_IMM8BY2: howto manager. (line 868)
-* BFD_RELOC_SH_IMM8BY4: howto manager. (line 869)
-* BFD_RELOC_SH_IMM_HI16: howto manager. (line 933)
-* BFD_RELOC_SH_IMM_HI16_PCREL: howto manager. (line 934)
-* BFD_RELOC_SH_IMM_LOW16: howto manager. (line 927)
-* BFD_RELOC_SH_IMM_LOW16_PCREL: howto manager. (line 928)
-* BFD_RELOC_SH_IMM_MEDHI16: howto manager. (line 931)
-* BFD_RELOC_SH_IMM_MEDHI16_PCREL: howto manager. (line 932)
-* BFD_RELOC_SH_IMM_MEDLOW16: howto manager. (line 929)
-* BFD_RELOC_SH_IMM_MEDLOW16_PCREL: howto manager. (line 930)
-* BFD_RELOC_SH_IMMS10: howto manager. (line 921)
-* BFD_RELOC_SH_IMMS10BY2: howto manager. (line 922)
-* BFD_RELOC_SH_IMMS10BY4: howto manager. (line 923)
-* BFD_RELOC_SH_IMMS10BY8: howto manager. (line 924)
-* BFD_RELOC_SH_IMMS16: howto manager. (line 925)
-* BFD_RELOC_SH_IMMS6: howto manager. (line 918)
-* BFD_RELOC_SH_IMMS6BY32: howto manager. (line 919)
-* BFD_RELOC_SH_IMMU16: howto manager. (line 926)
-* BFD_RELOC_SH_IMMU5: howto manager. (line 917)
-* BFD_RELOC_SH_IMMU6: howto manager. (line 920)
-* BFD_RELOC_SH_JMP_SLOT: howto manager. (line 884)
-* BFD_RELOC_SH_JMP_SLOT64: howto manager. (line 909)
-* BFD_RELOC_SH_LABEL: howto manager. (line 879)
-* BFD_RELOC_SH_LOOP_END: howto manager. (line 881)
-* BFD_RELOC_SH_LOOP_START: howto manager. (line 880)
-* BFD_RELOC_SH_PCDISP12BY2: howto manager. (line 855)
-* BFD_RELOC_SH_PCDISP8BY2: howto manager. (line 854)
-* BFD_RELOC_SH_PCRELIMM8BY2: howto manager. (line 870)
-* BFD_RELOC_SH_PCRELIMM8BY4: howto manager. (line 871)
-* BFD_RELOC_SH_PLT_HI16: howto manager. (line 898)
-* BFD_RELOC_SH_PLT_LOW16: howto manager. (line 895)
-* BFD_RELOC_SH_PLT_MEDHI16: howto manager. (line 897)
-* BFD_RELOC_SH_PLT_MEDLOW16: howto manager. (line 896)
-* BFD_RELOC_SH_PT_16: howto manager. (line 935)
-* BFD_RELOC_SH_RELATIVE: howto manager. (line 885)
-* BFD_RELOC_SH_RELATIVE64: howto manager. (line 910)
-* BFD_RELOC_SH_SHMEDIA_CODE: howto manager. (line 916)
-* BFD_RELOC_SH_SWITCH16: howto manager. (line 872)
-* BFD_RELOC_SH_SWITCH32: howto manager. (line 873)
-* BFD_RELOC_SH_TLS_DTPMOD32: howto manager. (line 941)
-* BFD_RELOC_SH_TLS_DTPOFF32: howto manager. (line 942)
-* BFD_RELOC_SH_TLS_GD_32: howto manager. (line 936)
-* BFD_RELOC_SH_TLS_IE_32: howto manager. (line 939)
-* BFD_RELOC_SH_TLS_LD_32: howto manager. (line 937)
-* BFD_RELOC_SH_TLS_LDO_32: howto manager. (line 938)
-* BFD_RELOC_SH_TLS_LE_32: howto manager. (line 940)
-* BFD_RELOC_SH_TLS_TPOFF32: howto manager. (line 943)
-* BFD_RELOC_SH_USES: howto manager. (line 874)
-* BFD_RELOC_SPARC13: howto manager. (line 134)
-* BFD_RELOC_SPARC22: howto manager. (line 133)
-* BFD_RELOC_SPARC_10: howto manager. (line 163)
-* BFD_RELOC_SPARC_11: howto manager. (line 164)
-* BFD_RELOC_SPARC_5: howto manager. (line 176)
-* BFD_RELOC_SPARC_6: howto manager. (line 175)
-* BFD_RELOC_SPARC_64: howto manager. (line 162)
-* BFD_RELOC_SPARC_7: howto manager. (line 174)
-* BFD_RELOC_SPARC_BASE13: howto manager. (line 158)
-* BFD_RELOC_SPARC_BASE22: howto manager. (line 159)
-* BFD_RELOC_SPARC_COPY: howto manager. (line 141)
-* BFD_RELOC_SPARC_DISP64: howto manager. (line 177)
-* BFD_RELOC_SPARC_GLOB_DAT: howto manager. (line 142)
-* BFD_RELOC_SPARC_GOT10: howto manager. (line 135)
-* BFD_RELOC_SPARC_GOT13: howto manager. (line 136)
-* BFD_RELOC_SPARC_GOT22: howto manager. (line 137)
-* BFD_RELOC_SPARC_GOTDATA_HIX22: howto manager. (line 148)
-* BFD_RELOC_SPARC_GOTDATA_LOX10: howto manager. (line 149)
-* BFD_RELOC_SPARC_GOTDATA_OP: howto manager. (line 152)
-* BFD_RELOC_SPARC_GOTDATA_OP_HIX22: howto manager. (line 150)
-* BFD_RELOC_SPARC_GOTDATA_OP_LOX10: howto manager. (line 151)
-* BFD_RELOC_SPARC_H44: howto manager. (line 182)
-* BFD_RELOC_SPARC_HH22: howto manager. (line 166)
-* BFD_RELOC_SPARC_HIX22: howto manager. (line 180)
-* BFD_RELOC_SPARC_HM10: howto manager. (line 167)
-* BFD_RELOC_SPARC_IRELATIVE: howto manager. (line 154)
-* BFD_RELOC_SPARC_JMP_IREL: howto manager. (line 153)
-* BFD_RELOC_SPARC_JMP_SLOT: howto manager. (line 143)
-* BFD_RELOC_SPARC_L44: howto manager. (line 184)
-* BFD_RELOC_SPARC_LM22: howto manager. (line 168)
-* BFD_RELOC_SPARC_LOX10: howto manager. (line 181)
-* BFD_RELOC_SPARC_M44: howto manager. (line 183)
-* BFD_RELOC_SPARC_OLO10: howto manager. (line 165)
-* BFD_RELOC_SPARC_PC10: howto manager. (line 138)
-* BFD_RELOC_SPARC_PC22: howto manager. (line 139)
-* BFD_RELOC_SPARC_PC_HH22: howto manager. (line 169)
-* BFD_RELOC_SPARC_PC_HM10: howto manager. (line 170)
-* BFD_RELOC_SPARC_PC_LM22: howto manager. (line 171)
-* BFD_RELOC_SPARC_PLT32: howto manager. (line 178)
-* BFD_RELOC_SPARC_PLT64: howto manager. (line 179)
-* BFD_RELOC_SPARC_REGISTER: howto manager. (line 185)
-* BFD_RELOC_SPARC_RELATIVE: howto manager. (line 144)
-* BFD_RELOC_SPARC_REV32: howto manager. (line 188)
-* BFD_RELOC_SPARC_TLS_DTPMOD32: howto manager. (line 209)
-* BFD_RELOC_SPARC_TLS_DTPMOD64: howto manager. (line 210)
-* BFD_RELOC_SPARC_TLS_DTPOFF32: howto manager. (line 211)
-* BFD_RELOC_SPARC_TLS_DTPOFF64: howto manager. (line 212)
-* BFD_RELOC_SPARC_TLS_GD_ADD: howto manager. (line 193)
-* BFD_RELOC_SPARC_TLS_GD_CALL: howto manager. (line 194)
-* BFD_RELOC_SPARC_TLS_GD_HI22: howto manager. (line 191)
-* BFD_RELOC_SPARC_TLS_GD_LO10: howto manager. (line 192)
-* BFD_RELOC_SPARC_TLS_IE_ADD: howto manager. (line 206)
-* BFD_RELOC_SPARC_TLS_IE_HI22: howto manager. (line 202)
-* BFD_RELOC_SPARC_TLS_IE_LD: howto manager. (line 204)
-* BFD_RELOC_SPARC_TLS_IE_LDX: howto manager. (line 205)
-* BFD_RELOC_SPARC_TLS_IE_LO10: howto manager. (line 203)
-* BFD_RELOC_SPARC_TLS_LDM_ADD: howto manager. (line 197)
-* BFD_RELOC_SPARC_TLS_LDM_CALL: howto manager. (line 198)
-* BFD_RELOC_SPARC_TLS_LDM_HI22: howto manager. (line 195)
-* BFD_RELOC_SPARC_TLS_LDM_LO10: howto manager. (line 196)
-* BFD_RELOC_SPARC_TLS_LDO_ADD: howto manager. (line 201)
-* BFD_RELOC_SPARC_TLS_LDO_HIX22: howto manager. (line 199)
-* BFD_RELOC_SPARC_TLS_LDO_LOX10: howto manager. (line 200)
-* BFD_RELOC_SPARC_TLS_LE_HIX22: howto manager. (line 207)
-* BFD_RELOC_SPARC_TLS_LE_LOX10: howto manager. (line 208)
-* BFD_RELOC_SPARC_TLS_TPOFF32: howto manager. (line 213)
-* BFD_RELOC_SPARC_TLS_TPOFF64: howto manager. (line 214)
-* BFD_RELOC_SPARC_UA16: howto manager. (line 145)
-* BFD_RELOC_SPARC_UA32: howto manager. (line 146)
-* BFD_RELOC_SPARC_UA64: howto manager. (line 147)
-* BFD_RELOC_SPARC_WDISP16: howto manager. (line 172)
-* BFD_RELOC_SPARC_WDISP19: howto manager. (line 173)
-* BFD_RELOC_SPARC_WDISP22: howto manager. (line 132)
-* BFD_RELOC_SPARC_WPLT30: howto manager. (line 140)
-* BFD_RELOC_SPU_ADD_PIC: howto manager. (line 231)
-* BFD_RELOC_SPU_HI16: howto manager. (line 228)
-* BFD_RELOC_SPU_IMM10: howto manager. (line 219)
-* BFD_RELOC_SPU_IMM10W: howto manager. (line 220)
-* BFD_RELOC_SPU_IMM16: howto manager. (line 221)
-* BFD_RELOC_SPU_IMM16W: howto manager. (line 222)
-* BFD_RELOC_SPU_IMM18: howto manager. (line 223)
-* BFD_RELOC_SPU_IMM7: howto manager. (line 217)
-* BFD_RELOC_SPU_IMM8: howto manager. (line 218)
-* BFD_RELOC_SPU_LO16: howto manager. (line 227)
-* BFD_RELOC_SPU_PCREL16: howto manager. (line 226)
-* BFD_RELOC_SPU_PCREL9a: howto manager. (line 224)
-* BFD_RELOC_SPU_PCREL9b: howto manager. (line 225)
-* BFD_RELOC_SPU_PPU32: howto manager. (line 229)
-* BFD_RELOC_SPU_PPU64: howto manager. (line 230)
-* BFD_RELOC_THUMB_PCREL_BLX: howto manager. (line 703)
-* BFD_RELOC_THUMB_PCREL_BRANCH12: howto manager. (line 717)
-* BFD_RELOC_THUMB_PCREL_BRANCH20: howto manager. (line 718)
-* BFD_RELOC_THUMB_PCREL_BRANCH23: howto manager. (line 719)
-* BFD_RELOC_THUMB_PCREL_BRANCH25: howto manager. (line 720)
-* BFD_RELOC_THUMB_PCREL_BRANCH7: howto manager. (line 715)
-* BFD_RELOC_THUMB_PCREL_BRANCH9: howto manager. (line 716)
-* BFD_RELOC_TIC30_LDP: howto manager. (line 1343)
-* BFD_RELOC_TIC54X_16_OF_23: howto manager. (line 1361)
-* BFD_RELOC_TIC54X_23: howto manager. (line 1358)
-* BFD_RELOC_TIC54X_MS7_OF_23: howto manager. (line 1366)
-* BFD_RELOC_TIC54X_PARTLS7: howto manager. (line 1348)
-* BFD_RELOC_TIC54X_PARTMS9: howto manager. (line 1353)
-* bfd_reloc_type_lookup: howto manager. (line 2408)
-* BFD_RELOC_V850_16_GOT: howto manager. (line 1299)
-* BFD_RELOC_V850_16_GOTOFF: howto manager. (line 1323)
-* BFD_RELOC_V850_16_PCREL: howto manager. (line 1269)
-* BFD_RELOC_V850_16_S1: howto manager. (line 1287)
-* BFD_RELOC_V850_16_SPLIT_OFFSET: howto manager. (line 1284)
-* BFD_RELOC_V850_17_PCREL: howto manager. (line 1272)
-* BFD_RELOC_V850_22_PCREL: howto manager. (line 1204)
-* BFD_RELOC_V850_22_PLT_PCREL: howto manager. (line 1305)
-* BFD_RELOC_V850_23: howto manager. (line 1275)
-* BFD_RELOC_V850_32_ABS: howto manager. (line 1281)
-* BFD_RELOC_V850_32_GOT: howto manager. (line 1302)
-* BFD_RELOC_V850_32_GOTOFF: howto manager. (line 1326)
-* BFD_RELOC_V850_32_GOTPCREL: howto manager. (line 1296)
-* BFD_RELOC_V850_32_PCREL: howto manager. (line 1278)
-* BFD_RELOC_V850_32_PLT_PCREL: howto manager. (line 1308)
-* BFD_RELOC_V850_9_PCREL: howto manager. (line 1201)
-* BFD_RELOC_V850_ALIGN: howto manager. (line 1262)
-* BFD_RELOC_V850_CALLT_15_16_OFFSET: howto manager. (line 1293)
-* BFD_RELOC_V850_CALLT_16_16_OFFSET: howto manager. (line 1253)
-* BFD_RELOC_V850_CALLT_6_7_OFFSET: howto manager. (line 1250)
-* BFD_RELOC_V850_CODE: howto manager. (line 1329)
-* BFD_RELOC_V850_COPY: howto manager. (line 1311)
-* BFD_RELOC_V850_DATA: howto manager. (line 1332)
-* BFD_RELOC_V850_GLOB_DAT: howto manager. (line 1314)
-* BFD_RELOC_V850_JMP_SLOT: howto manager. (line 1317)
-* BFD_RELOC_V850_LO16_S1: howto manager. (line 1290)
-* BFD_RELOC_V850_LO16_SPLIT_OFFSET: howto manager. (line 1265)
-* BFD_RELOC_V850_LONGCALL: howto manager. (line 1256)
-* BFD_RELOC_V850_LONGJUMP: howto manager. (line 1259)
-* BFD_RELOC_V850_RELATIVE: howto manager. (line 1320)
-* BFD_RELOC_V850_SDA_15_16_OFFSET: howto manager. (line 1210)
-* BFD_RELOC_V850_SDA_16_16_OFFSET: howto manager. (line 1207)
-* BFD_RELOC_V850_SDA_16_16_SPLIT_OFFSET: howto manager. (line 1242)
-* BFD_RELOC_V850_TDA_16_16_OFFSET: howto manager. (line 1232)
-* BFD_RELOC_V850_TDA_4_4_OFFSET: howto manager. (line 1239)
-* BFD_RELOC_V850_TDA_4_5_OFFSET: howto manager. (line 1235)
-* BFD_RELOC_V850_TDA_6_8_OFFSET: howto manager. (line 1221)
-* BFD_RELOC_V850_TDA_7_7_OFFSET: howto manager. (line 1229)
-* BFD_RELOC_V850_TDA_7_8_OFFSET: howto manager. (line 1225)
-* BFD_RELOC_V850_ZDA_15_16_OFFSET: howto manager. (line 1217)
-* BFD_RELOC_V850_ZDA_16_16_OFFSET: howto manager. (line 1214)
-* BFD_RELOC_V850_ZDA_16_16_SPLIT_OFFSET: howto manager. (line 1246)
-* BFD_RELOC_VAX_GLOB_DAT: howto manager. (line 2173)
-* BFD_RELOC_VAX_JMP_SLOT: howto manager. (line 2174)
-* BFD_RELOC_VAX_RELATIVE: howto manager. (line 2175)
-* BFD_RELOC_VPE4KMATH_DATA: howto manager. (line 1812)
-* BFD_RELOC_VPE4KMATH_INSN: howto manager. (line 1813)
-* BFD_RELOC_VTABLE_ENTRY: howto manager. (line 1817)
-* BFD_RELOC_VTABLE_INHERIT: howto manager. (line 1816)
-* BFD_RELOC_X86_64_32S: howto manager. (line 538)
-* BFD_RELOC_X86_64_COPY: howto manager. (line 533)
-* BFD_RELOC_X86_64_DTPMOD64: howto manager. (line 539)
-* BFD_RELOC_X86_64_DTPOFF32: howto manager. (line 544)
-* BFD_RELOC_X86_64_DTPOFF64: howto manager. (line 540)
-* BFD_RELOC_X86_64_GLOB_DAT: howto manager. (line 534)
-* BFD_RELOC_X86_64_GOT32: howto manager. (line 531)
-* BFD_RELOC_X86_64_GOT64: howto manager. (line 549)
-* BFD_RELOC_X86_64_GOTOFF64: howto manager. (line 547)
-* BFD_RELOC_X86_64_GOTPC32: howto manager. (line 548)
-* BFD_RELOC_X86_64_GOTPC32_TLSDESC: howto manager. (line 554)
-* BFD_RELOC_X86_64_GOTPC64: howto manager. (line 551)
-* BFD_RELOC_X86_64_GOTPCREL: howto manager. (line 537)
-* BFD_RELOC_X86_64_GOTPCREL64: howto manager. (line 550)
-* BFD_RELOC_X86_64_GOTPLT64: howto manager. (line 552)
-* BFD_RELOC_X86_64_GOTTPOFF: howto manager. (line 545)
-* BFD_RELOC_X86_64_IRELATIVE: howto manager. (line 557)
-* BFD_RELOC_X86_64_JUMP_SLOT: howto manager. (line 535)
-* BFD_RELOC_X86_64_PLT32: howto manager. (line 532)
-* BFD_RELOC_X86_64_PLTOFF64: howto manager. (line 553)
-* BFD_RELOC_X86_64_RELATIVE: howto manager. (line 536)
-* BFD_RELOC_X86_64_TLSDESC: howto manager. (line 556)
-* BFD_RELOC_X86_64_TLSDESC_CALL: howto manager. (line 555)
-* BFD_RELOC_X86_64_TLSGD: howto manager. (line 542)
-* BFD_RELOC_X86_64_TLSLD: howto manager. (line 543)
-* BFD_RELOC_X86_64_TPOFF32: howto manager. (line 546)
-* BFD_RELOC_X86_64_TPOFF64: howto manager. (line 541)
-* BFD_RELOC_XC16X_PAG: howto manager. (line 2167)
-* BFD_RELOC_XC16X_POF: howto manager. (line 2168)
-* BFD_RELOC_XC16X_SEG: howto manager. (line 2169)
-* BFD_RELOC_XC16X_SOF: howto manager. (line 2170)
-* BFD_RELOC_XSTORMY16_12: howto manager. (line 2159)
-* BFD_RELOC_XSTORMY16_24: howto manager. (line 2160)
-* BFD_RELOC_XSTORMY16_FPTR16: howto manager. (line 2161)
-* BFD_RELOC_XSTORMY16_REL_12: howto manager. (line 2158)
-* BFD_RELOC_XTENSA_ASM_EXPAND: howto manager. (line 2279)
-* BFD_RELOC_XTENSA_ASM_SIMPLIFY: howto manager. (line 2284)
-* BFD_RELOC_XTENSA_DIFF16: howto manager. (line 2226)
-* BFD_RELOC_XTENSA_DIFF32: howto manager. (line 2227)
-* BFD_RELOC_XTENSA_DIFF8: howto manager. (line 2225)
-* BFD_RELOC_XTENSA_GLOB_DAT: howto manager. (line 2215)
-* BFD_RELOC_XTENSA_JMP_SLOT: howto manager. (line 2216)
-* BFD_RELOC_XTENSA_OP0: howto manager. (line 2273)
-* BFD_RELOC_XTENSA_OP1: howto manager. (line 2274)
-* BFD_RELOC_XTENSA_OP2: howto manager. (line 2275)
-* BFD_RELOC_XTENSA_PLT: howto manager. (line 2220)
-* BFD_RELOC_XTENSA_RELATIVE: howto manager. (line 2217)
-* BFD_RELOC_XTENSA_RTLD: howto manager. (line 2210)
-* BFD_RELOC_XTENSA_SLOT0_ALT: howto manager. (line 2255)
-* BFD_RELOC_XTENSA_SLOT0_OP: howto manager. (line 2235)
-* BFD_RELOC_XTENSA_SLOT10_ALT: howto manager. (line 2265)
-* BFD_RELOC_XTENSA_SLOT10_OP: howto manager. (line 2245)
-* BFD_RELOC_XTENSA_SLOT11_ALT: howto manager. (line 2266)
-* BFD_RELOC_XTENSA_SLOT11_OP: howto manager. (line 2246)
-* BFD_RELOC_XTENSA_SLOT12_ALT: howto manager. (line 2267)
-* BFD_RELOC_XTENSA_SLOT12_OP: howto manager. (line 2247)
-* BFD_RELOC_XTENSA_SLOT13_ALT: howto manager. (line 2268)
-* BFD_RELOC_XTENSA_SLOT13_OP: howto manager. (line 2248)
-* BFD_RELOC_XTENSA_SLOT14_ALT: howto manager. (line 2269)
-* BFD_RELOC_XTENSA_SLOT14_OP: howto manager. (line 2249)
-* BFD_RELOC_XTENSA_SLOT1_ALT: howto manager. (line 2256)
-* BFD_RELOC_XTENSA_SLOT1_OP: howto manager. (line 2236)
-* BFD_RELOC_XTENSA_SLOT2_ALT: howto manager. (line 2257)
-* BFD_RELOC_XTENSA_SLOT2_OP: howto manager. (line 2237)
-* BFD_RELOC_XTENSA_SLOT3_ALT: howto manager. (line 2258)
-* BFD_RELOC_XTENSA_SLOT3_OP: howto manager. (line 2238)
-* BFD_RELOC_XTENSA_SLOT4_ALT: howto manager. (line 2259)
-* BFD_RELOC_XTENSA_SLOT4_OP: howto manager. (line 2239)
-* BFD_RELOC_XTENSA_SLOT5_ALT: howto manager. (line 2260)
-* BFD_RELOC_XTENSA_SLOT5_OP: howto manager. (line 2240)
-* BFD_RELOC_XTENSA_SLOT6_ALT: howto manager. (line 2261)
-* BFD_RELOC_XTENSA_SLOT6_OP: howto manager. (line 2241)
-* BFD_RELOC_XTENSA_SLOT7_ALT: howto manager. (line 2262)
-* BFD_RELOC_XTENSA_SLOT7_OP: howto manager. (line 2242)
-* BFD_RELOC_XTENSA_SLOT8_ALT: howto manager. (line 2263)
-* BFD_RELOC_XTENSA_SLOT8_OP: howto manager. (line 2243)
-* BFD_RELOC_XTENSA_SLOT9_ALT: howto manager. (line 2264)
-* BFD_RELOC_XTENSA_SLOT9_OP: howto manager. (line 2244)
-* BFD_RELOC_XTENSA_TLS_ARG: howto manager. (line 2294)
-* BFD_RELOC_XTENSA_TLS_CALL: howto manager. (line 2295)
-* BFD_RELOC_XTENSA_TLS_DTPOFF: howto manager. (line 2291)
-* BFD_RELOC_XTENSA_TLS_FUNC: howto manager. (line 2293)
-* BFD_RELOC_XTENSA_TLS_TPOFF: howto manager. (line 2292)
-* BFD_RELOC_XTENSA_TLSDESC_ARG: howto manager. (line 2290)
-* BFD_RELOC_XTENSA_TLSDESC_FN: howto manager. (line 2289)
-* BFD_RELOC_Z80_DISP8: howto manager. (line 2298)
-* BFD_RELOC_Z8K_CALLR: howto manager. (line 2304)
-* BFD_RELOC_Z8K_DISP7: howto manager. (line 2301)
-* BFD_RELOC_Z8K_IMM4L: howto manager. (line 2307)
-* bfd_rename_section: section prototypes. (line 155)
-* bfd_scan_arch: Architectures. (line 447)
-* bfd_scan_vma: BFD front end. (line 532)
-* bfd_seach_for_target: bfd_target. (line 507)
-* bfd_section_already_linked: Writing the symbol table.
- (line 55)
-* bfd_section_list_clear: section prototypes. (line 8)
-* bfd_sections_find_if: section prototypes. (line 185)
-* bfd_set_arch_info: Architectures. (line 488)
-* bfd_set_archive_head: Archives. (line 69)
-* bfd_set_default_target: bfd_target. (line 446)
-* bfd_set_error: BFD front end. (line 342)
-* bfd_set_error_handler: BFD front end. (line 384)
-* bfd_set_error_program_name: BFD front end. (line 393)
-* bfd_set_file_flags: BFD front end. (line 452)
-* bfd_set_format: Formats. (line 68)
-* bfd_set_gp_size: BFD front end. (line 522)
-* bfd_set_private_flags: BFD front end. (line 599)
-* bfd_set_reloc: BFD front end. (line 442)
-* bfd_set_section_contents: section prototypes. (line 216)
-* bfd_set_section_flags: section prototypes. (line 140)
-* bfd_set_section_size: section prototypes. (line 202)
-* bfd_set_start_address: BFD front end. (line 501)
-* bfd_set_symtab: symbol handling functions.
- (line 60)
-* bfd_symbol_info: symbol handling functions.
- (line 130)
-* bfd_target_list: bfd_target. (line 498)
-* bfd_write_bigendian_4byte_int: Internal. (line 13)
-* bfd_zalloc: Opening and Closing.
- (line 232)
-* bfd_zalloc2: Opening and Closing.
- (line 241)
-* coff_symbol_type: coff. (line 244)
-* core_file_matches_executable_p: Core Files. (line 39)
-* find_separate_debug_file: Opening and Closing.
- (line 283)
-* generic_core_file_matches_executable_p: Core Files. (line 49)
-* get_debug_link_info: Opening and Closing.
- (line 264)
-* Hash tables: Hash Tables. (line 6)
-* internal object-file format: Canonical format. (line 11)
-* Linker: Linker Functions. (line 6)
-* Other functions: BFD front end. (line 614)
-* separate_debug_file_exists: Opening and Closing.
- (line 274)
-* struct bfd_iovec: BFD front end. (line 817)
-* target vector (_bfd_final_link): Performing the Final Link.
- (line 6)
-* target vector (_bfd_link_add_symbols): Adding Symbols to the Hash Table.
- (line 6)
-* target vector (_bfd_link_hash_table_create): Creating a Linker Hash Table.
- (line 6)
-* The HOWTO Macro: typedef arelent. (line 288)
-* what is it?: Overview. (line 6)
-
-
-
-Tag Table:
-Node: Top1163
-Node: Overview1502
-Node: History2553
-Node: How It Works3499
-Node: What BFD Version 2 Can Do5042
-Node: BFD information loss6357
-Node: Canonical format8889
-Node: BFD front end13261
-Node: Memory Usage45340
-Node: Initialization46568
-Node: Sections47027
-Node: Section Input47510
-Node: Section Output48875
-Node: typedef asection51361
-Node: section prototypes76673
-Node: Symbols86568
-Node: Reading Symbols88163
-Node: Writing Symbols89270
-Node: Mini Symbols90979
-Node: typedef asymbol91953
-Node: symbol handling functions98012
-Node: Archives103354
-Node: Formats107080
-Node: Relocations110028
-Node: typedef arelent110755
-Node: howto manager126391
-Node: Core Files203223
-Node: Targets205261
-Node: bfd_target207231
-Node: Architectures229624
-Node: Opening and Closing253382
-Node: Internal264838
-Node: File Caching271171
-Node: Linker Functions273085
-Node: Creating a Linker Hash Table274758
-Node: Adding Symbols to the Hash Table276496
-Node: Differing file formats277396
-Node: Adding symbols from an object file279121
-Node: Adding symbols from an archive281272
-Node: Performing the Final Link284201
-Node: Information provided by the linker285443
-Node: Relocating the section contents286597
-Node: Writing the symbol table288348
-Node: Hash Tables292363
-Node: Creating and Freeing a Hash Table293561
-Node: Looking Up or Entering a String294811
-Node: Traversing a Hash Table296064
-Node: Deriving a New Hash Table Type296853
-Node: Define the Derived Structures297919
-Node: Write the Derived Creation Routine299000
-Node: Write Other Derived Routines301624
-Node: BFD back ends302939
-Node: What to Put Where303209
-Node: aout303389
-Node: coff309707
-Node: elf338140
-Node: mmo338541
-Node: File layout339469
-Node: Symbol-table345116
-Node: mmo section mapping348885
-Node: GNU Free Documentation License352537
-Node: BFD Index377620
-
-End Tag Table
diff --git a/share/info/binutils.info b/share/info/binutils.info
deleted file mode 100644
index 7a273d4..0000000
--- a/share/info/binutils.info
+++ /dev/null
@@ -1,4646 +0,0 @@
-This is binutils.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../binutils/binutils-2.21/binutils/doc/binutils.texi.
-
-Copyright (C) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free
-Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* Binutils: (binutils). The GNU binary utilities.
-END-INFO-DIR-ENTRY
-
-INFO-DIR-SECTION Individual utilities
-START-INFO-DIR-ENTRY
-* addr2line: (binutils)addr2line. Convert addresses to file and line.
-* ar: (binutils)ar. Create, modify, and extract from archives.
-* c++filt: (binutils)c++filt. Filter to demangle encoded C++ symbols.
-* cxxfilt: (binutils)c++filt. MS-DOS name for c++filt.
-* dlltool: (binutils)dlltool. Create files needed to build and use DLLs.
-* nlmconv: (binutils)nlmconv. Converts object code into an NLM.
-* nm: (binutils)nm. List symbols from object files.
-* objcopy: (binutils)objcopy. Copy and translate object files.
-* objdump: (binutils)objdump. Display information from object files.
-* ranlib: (binutils)ranlib. Generate index to archive contents.
-* readelf: (binutils)readelf. Display the contents of ELF format files.
-* size: (binutils)size. List section sizes and total size.
-* strings: (binutils)strings. List printable strings from files.
-* strip: (binutils)strip. Discard symbols.
-* elfedit: (binutils)elfedit. Update the ELF header of ELF files.
-* windmc: (binutils)windmc. Generator for Windows message resources.
-* windres: (binutils)windres. Manipulate Windows resources.
-END-INFO-DIR-ENTRY
-
-
-File: binutils.info, Node: Top, Next: ar, Up: (dir)
-
-Introduction
-************
-
-This brief manual contains documentation for the GNU binary utilities
-(GNU Binutils) version 2.21:
-
- This document is distributed under the terms of the GNU Free
-Documentation License version 1.3. A copy of the license is included
-in the section entitled "GNU Free Documentation License".
-
-* Menu:
-
-* ar:: Create, modify, and extract from archives
-* nm:: List symbols from object files
-* objcopy:: Copy and translate object files
-* objdump:: Display information from object files
-* ranlib:: Generate index to archive contents
-* readelf:: Display the contents of ELF format files
-* size:: List section sizes and total size
-* strings:: List printable strings from files
-* strip:: Discard symbols
-* elfedit:: Update the ELF header of ELF files
-* c++filt:: Filter to demangle encoded C++ symbols
-* cxxfilt: c++filt. MS-DOS name for c++filt
-* addr2line:: Convert addresses to file and line
-* nlmconv:: Converts object code into an NLM
-* windres:: Manipulate Windows resources
-* windmc:: Generator for Windows message resources
-* dlltool:: Create files needed to build and use DLLs
-* Common Options:: Command-line options for all utilities
-* Selecting the Target System:: How these utilities determine the target
-* Reporting Bugs:: Reporting Bugs
-* GNU Free Documentation License:: GNU Free Documentation License
-* Binutils Index:: Binutils Index
-
-
-File: binutils.info, Node: ar, Next: nm, Prev: Top, Up: Top
-
-1 ar
-****
-
- ar [`--plugin' NAME] [-]P[MOD [RELPOS] [COUNT]] ARCHIVE [MEMBER...]
- ar -M [ <mri-script ]
-
- The GNU `ar' program creates, modifies, and extracts from archives.
-An "archive" is a single file holding a collection of other files in a
-structure that makes it possible to retrieve the original individual
-files (called "members" of the archive).
-
- The original files' contents, mode (permissions), timestamp, owner,
-and group are preserved in the archive, and can be restored on
-extraction.
-
- GNU `ar' can maintain archives whose members have names of any
-length; however, depending on how `ar' is configured on your system, a
-limit on member-name length may be imposed for compatibility with
-archive formats maintained with other tools. If it exists, the limit
-is often 15 characters (typical of formats related to a.out) or 16
-characters (typical of formats related to coff).
-
- `ar' is considered a binary utility because archives of this sort
-are most often used as "libraries" holding commonly needed subroutines.
-
- `ar' creates an index to the symbols defined in relocatable object
-modules in the archive when you specify the modifier `s'. Once
-created, this index is updated in the archive whenever `ar' makes a
-change to its contents (save for the `q' update operation). An archive
-with such an index speeds up linking to the library, and allows
-routines in the library to call each other without regard to their
-placement in the archive.
-
- You may use `nm -s' or `nm --print-armap' to list this index table.
-If an archive lacks the table, another form of `ar' called `ranlib' can
-be used to add just the table.
-
- GNU `ar' can optionally create a _thin_ archive, which contains a
-symbol index and references to the original copies of the member files
-of the archives. Such an archive is useful for building libraries for
-use within a local build, where the relocatable objects are expected to
-remain available, and copying the contents of each object would only
-waste time and space. Thin archives are also _flattened_, so that
-adding one or more archives to a thin archive will add the elements of
-the nested archive individually. The paths to the elements of the
-archive are stored relative to the archive itself.
-
- GNU `ar' is designed to be compatible with two different facilities.
-You can control its activity using command-line options, like the
-different varieties of `ar' on Unix systems; or, if you specify the
-single command-line option `-M', you can control it with a script
-supplied via standard input, like the MRI "librarian" program.
-
-* Menu:
-
-* ar cmdline:: Controlling `ar' on the command line
-* ar scripts:: Controlling `ar' with a script
-
-
-File: binutils.info, Node: ar cmdline, Next: ar scripts, Up: ar
-
-1.1 Controlling `ar' on the Command Line
-========================================
-
- ar [`--plugin' NAME] [`-X32_64'] [`-']P[MOD [RELPOS] [COUNT]] ARCHIVE [MEMBER...]
-
- When you use `ar' in the Unix style, `ar' insists on at least two
-arguments to execute: one keyletter specifying the _operation_
-(optionally accompanied by other keyletters specifying _modifiers_),
-and the archive name to act on.
-
- Most operations can also accept further MEMBER arguments, specifying
-particular files to operate on.
-
- GNU `ar' allows you to mix the operation code P and modifier flags
-MOD in any order, within the first command-line argument.
-
- If you wish, you may begin the first command-line argument with a
-dash.
-
- The P keyletter specifies what operation to execute; it may be any
-of the following, but you must specify only one of them:
-
-`d'
- _Delete_ modules from the archive. Specify the names of modules to
- be deleted as MEMBER...; the archive is untouched if you specify
- no files to delete.
-
- If you specify the `v' modifier, `ar' lists each module as it is
- deleted.
-
-`m'
- Use this operation to _move_ members in an archive.
-
- The ordering of members in an archive can make a difference in how
- programs are linked using the library, if a symbol is defined in
- more than one member.
-
- If no modifiers are used with `m', any members you name in the
- MEMBER arguments are moved to the _end_ of the archive; you can
- use the `a', `b', or `i' modifiers to move them to a specified
- place instead.
-
-`p'
- _Print_ the specified members of the archive, to the standard
- output file. If the `v' modifier is specified, show the member
- name before copying its contents to standard output.
-
- If you specify no MEMBER arguments, all the files in the archive
- are printed.
-
-`q'
- _Quick append_; Historically, add the files MEMBER... to the end of
- ARCHIVE, without checking for replacement.
-
- The modifiers `a', `b', and `i' do _not_ affect this operation;
- new members are always placed at the end of the archive.
-
- The modifier `v' makes `ar' list each file as it is appended.
-
- Since the point of this operation is speed, the archive's symbol
- table index is not updated, even if it already existed; you can
- use `ar s' or `ranlib' explicitly to update the symbol table index.
-
- However, too many different systems assume quick append rebuilds
- the index, so GNU `ar' implements `q' as a synonym for `r'.
-
-`r'
- Insert the files MEMBER... into ARCHIVE (with _replacement_). This
- operation differs from `q' in that any previously existing members
- are deleted if their names match those being added.
-
- If one of the files named in MEMBER... does not exist, `ar'
- displays an error message, and leaves undisturbed any existing
- members of the archive matching that name.
-
- By default, new members are added at the end of the file; but you
- may use one of the modifiers `a', `b', or `i' to request placement
- relative to some existing member.
-
- The modifier `v' used with this operation elicits a line of output
- for each file inserted, along with one of the letters `a' or `r'
- to indicate whether the file was appended (no old member deleted)
- or replaced.
-
-`s'
- Add an index to the archive, or update it if it already exists.
- Note this command is an exception to the rule that there can only
- be one command letter, as it is possible to use it as either a
- command or a modifier. In either case it does the same thing.
-
-`t'
- Display a _table_ listing the contents of ARCHIVE, or those of the
- files listed in MEMBER... that are present in the archive.
- Normally only the member name is shown; if you also want to see
- the modes (permissions), timestamp, owner, group, and size, you can
- request that by also specifying the `v' modifier.
-
- If you do not specify a MEMBER, all files in the archive are
- listed.
-
- If there is more than one file with the same name (say, `fie') in
- an archive (say `b.a'), `ar t b.a fie' lists only the first
- instance; to see them all, you must ask for a complete listing--in
- our example, `ar t b.a'.
-
-`x'
- _Extract_ members (named MEMBER) from the archive. You can use
- the `v' modifier with this operation, to request that `ar' list
- each name as it extracts it.
-
- If you do not specify a MEMBER, all files in the archive are
- extracted.
-
- Files cannot be extracted from a thin archive.
-
-
- A number of modifiers (MOD) may immediately follow the P keyletter,
-to specify variations on an operation's behavior:
-
-`a'
- Add new files _after_ an existing member of the archive. If you
- use the modifier `a', the name of an existing archive member must
- be present as the RELPOS argument, before the ARCHIVE
- specification.
-
-`b'
- Add new files _before_ an existing member of the archive. If you
- use the modifier `b', the name of an existing archive member must
- be present as the RELPOS argument, before the ARCHIVE
- specification. (same as `i').
-
-`c'
- _Create_ the archive. The specified ARCHIVE is always created if
- it did not exist, when you request an update. But a warning is
- issued unless you specify in advance that you expect to create it,
- by using this modifier.
-
-`D'
- Operate in _deterministic_ mode. When adding files and the archive
- index use zero for UIDs, GIDs, timestamps, and use consistent file
- modes for all files. When this option is used, if `ar' is used
- with identical options and identical input files, multiple runs
- will create identical output files regardless of the input files'
- owners, groups, file modes, or modification times.
-
-`f'
- Truncate names in the archive. GNU `ar' will normally permit file
- names of any length. This will cause it to create archives which
- are not compatible with the native `ar' program on some systems.
- If this is a concern, the `f' modifier may be used to truncate file
- names when putting them in the archive.
-
-`i'
- Insert new files _before_ an existing member of the archive. If
- you use the modifier `i', the name of an existing archive member
- must be present as the RELPOS argument, before the ARCHIVE
- specification. (same as `b').
-
-`l'
- This modifier is accepted but not used.
-
-`N'
- Uses the COUNT parameter. This is used if there are multiple
- entries in the archive with the same name. Extract or delete
- instance COUNT of the given name from the archive.
-
-`o'
- Preserve the _original_ dates of members when extracting them. If
- you do not specify this modifier, files extracted from the archive
- are stamped with the time of extraction.
-
-`P'
- Use the full path name when matching names in the archive. GNU
- `ar' can not create an archive with a full path name (such archives
- are not POSIX complaint), but other archive creators can. This
- option will cause GNU `ar' to match file names using a complete
- path name, which can be convenient when extracting a single file
- from an archive created by another tool.
-
-`s'
- Write an object-file index into the archive, or update an existing
- one, even if no other change is made to the archive. You may use
- this modifier flag either with any operation, or alone. Running
- `ar s' on an archive is equivalent to running `ranlib' on it.
-
-`S'
- Do not generate an archive symbol table. This can speed up
- building a large library in several steps. The resulting archive
- can not be used with the linker. In order to build a symbol
- table, you must omit the `S' modifier on the last execution of
- `ar', or you must run `ranlib' on the archive.
-
-`T'
- Make the specified ARCHIVE a _thin_ archive. If it already exists
- and is a regular archive, the existing members must be present in
- the same directory as ARCHIVE.
-
-`u'
- Normally, `ar r'... inserts all files listed into the archive. If
- you would like to insert _only_ those of the files you list that
- are newer than existing members of the same names, use this
- modifier. The `u' modifier is allowed only for the operation `r'
- (replace). In particular, the combination `qu' is not allowed,
- since checking the timestamps would lose any speed advantage from
- the operation `q'.
-
-`v'
- This modifier requests the _verbose_ version of an operation. Many
- operations display additional information, such as filenames
- processed, when the modifier `v' is appended.
-
-`V'
- This modifier shows the version number of `ar'.
-
- `ar' ignores an initial option spelt `-X32_64', for compatibility
-with AIX. The behaviour produced by this option is the default for GNU
-`ar'. `ar' does not support any of the other `-X' options; in
-particular, it does not support `-X32' which is the default for AIX
-`ar'.
-
- The optional command line switch `--plugin' NAME causes `ar' to load
-the plugin called NAME which adds support for more file formats. This
-option is only available if the toolchain has been built with plugin
-support enabled.
-
-
-File: binutils.info, Node: ar scripts, Prev: ar cmdline, Up: ar
-
-1.2 Controlling `ar' with a Script
-==================================
-
- ar -M [ <SCRIPT ]
-
- If you use the single command-line option `-M' with `ar', you can
-control its operation with a rudimentary command language. This form
-of `ar' operates interactively if standard input is coming directly
-from a terminal. During interactive use, `ar' prompts for input (the
-prompt is `AR >'), and continues executing even after errors. If you
-redirect standard input to a script file, no prompts are issued, and
-`ar' abandons execution (with a nonzero exit code) on any error.
-
- The `ar' command language is _not_ designed to be equivalent to the
-command-line options; in fact, it provides somewhat less control over
-archives. The only purpose of the command language is to ease the
-transition to GNU `ar' for developers who already have scripts written
-for the MRI "librarian" program.
-
- The syntax for the `ar' command language is straightforward:
- * commands are recognized in upper or lower case; for example, `LIST'
- is the same as `list'. In the following descriptions, commands are
- shown in upper case for clarity.
-
- * a single command may appear on each line; it is the first word on
- the line.
-
- * empty lines are allowed, and have no effect.
-
- * comments are allowed; text after either of the characters `*' or
- `;' is ignored.
-
- * Whenever you use a list of names as part of the argument to an `ar'
- command, you can separate the individual names with either commas
- or blanks. Commas are shown in the explanations below, for
- clarity.
-
- * `+' is used as a line continuation character; if `+' appears at
- the end of a line, the text on the following line is considered
- part of the current command.
-
- Here are the commands you can use in `ar' scripts, or when using
-`ar' interactively. Three of them have special significance:
-
- `OPEN' or `CREATE' specify a "current archive", which is a temporary
-file required for most of the other commands.
-
- `SAVE' commits the changes so far specified by the script. Prior to
-`SAVE', commands affect only the temporary copy of the current archive.
-
-`ADDLIB ARCHIVE'
-`ADDLIB ARCHIVE (MODULE, MODULE, ... MODULE)'
- Add all the contents of ARCHIVE (or, if specified, each named
- MODULE from ARCHIVE) to the current archive.
-
- Requires prior use of `OPEN' or `CREATE'.
-
-`ADDMOD MEMBER, MEMBER, ... MEMBER'
- Add each named MEMBER as a module in the current archive.
-
- Requires prior use of `OPEN' or `CREATE'.
-
-`CLEAR'
- Discard the contents of the current archive, canceling the effect
- of any operations since the last `SAVE'. May be executed (with no
- effect) even if no current archive is specified.
-
-`CREATE ARCHIVE'
- Creates an archive, and makes it the current archive (required for
- many other commands). The new archive is created with a temporary
- name; it is not actually saved as ARCHIVE until you use `SAVE'.
- You can overwrite existing archives; similarly, the contents of any
- existing file named ARCHIVE will not be destroyed until `SAVE'.
-
-`DELETE MODULE, MODULE, ... MODULE'
- Delete each listed MODULE from the current archive; equivalent to
- `ar -d ARCHIVE MODULE ... MODULE'.
-
- Requires prior use of `OPEN' or `CREATE'.
-
-`DIRECTORY ARCHIVE (MODULE, ... MODULE)'
-`DIRECTORY ARCHIVE (MODULE, ... MODULE) OUTPUTFILE'
- List each named MODULE present in ARCHIVE. The separate command
- `VERBOSE' specifies the form of the output: when verbose output is
- off, output is like that of `ar -t ARCHIVE MODULE...'. When
- verbose output is on, the listing is like `ar -tv ARCHIVE
- MODULE...'.
-
- Output normally goes to the standard output stream; however, if you
- specify OUTPUTFILE as a final argument, `ar' directs the output to
- that file.
-
-`END'
- Exit from `ar', with a `0' exit code to indicate successful
- completion. This command does not save the output file; if you
- have changed the current archive since the last `SAVE' command,
- those changes are lost.
-
-`EXTRACT MODULE, MODULE, ... MODULE'
- Extract each named MODULE from the current archive, writing them
- into the current directory as separate files. Equivalent to `ar -x
- ARCHIVE MODULE...'.
-
- Requires prior use of `OPEN' or `CREATE'.
-
-`LIST'
- Display full contents of the current archive, in "verbose" style
- regardless of the state of `VERBOSE'. The effect is like `ar tv
- ARCHIVE'. (This single command is a GNU `ar' enhancement, rather
- than present for MRI compatibility.)
-
- Requires prior use of `OPEN' or `CREATE'.
-
-`OPEN ARCHIVE'
- Opens an existing archive for use as the current archive (required
- for many other commands). Any changes as the result of subsequent
- commands will not actually affect ARCHIVE until you next use
- `SAVE'.
-
-`REPLACE MODULE, MODULE, ... MODULE'
- In the current archive, replace each existing MODULE (named in the
- `REPLACE' arguments) from files in the current working directory.
- To execute this command without errors, both the file, and the
- module in the current archive, must exist.
-
- Requires prior use of `OPEN' or `CREATE'.
-
-`VERBOSE'
- Toggle an internal flag governing the output from `DIRECTORY'.
- When the flag is on, `DIRECTORY' output matches output from `ar
- -tv '....
-
-`SAVE'
- Commit your changes to the current archive, and actually save it
- as a file with the name specified in the last `CREATE' or `OPEN'
- command.
-
- Requires prior use of `OPEN' or `CREATE'.
-
-
-
-File: binutils.info, Node: nm, Next: objcopy, Prev: ar, Up: Top
-
-2 nm
-****
-
- nm [`-a'|`--debug-syms']
- [`-g'|`--extern-only'][`--plugin' NAME]
- [`-B'] [`-C'|`--demangle'[=STYLE]] [`-D'|`--dynamic']
- [`-S'|`--print-size'] [`-s'|`--print-armap']
- [`-A'|`-o'|`--print-file-name'][`--special-syms']
- [`-n'|`-v'|`--numeric-sort'] [`-p'|`--no-sort']
- [`-r'|`--reverse-sort'] [`--size-sort'] [`-u'|`--undefined-only']
- [`-t' RADIX|`--radix='RADIX] [`-P'|`--portability']
- [`--target='BFDNAME] [`-f'FORMAT|`--format='FORMAT]
- [`--defined-only'] [`-l'|`--line-numbers'] [`--no-demangle']
- [`-V'|`--version'] [`-X 32_64'] [`--help'] [OBJFILE...]
-
- GNU `nm' lists the symbols from object files OBJFILE.... If no
-object files are listed as arguments, `nm' assumes the file `a.out'.
-
- For each symbol, `nm' shows:
-
- * The symbol value, in the radix selected by options (see below), or
- hexadecimal by default.
-
- * The symbol type. At least the following types are used; others
- are, as well, depending on the object file format. If lowercase,
- the symbol is local; if uppercase, the symbol is global (external).
-
- `A'
- The symbol's value is absolute, and will not be changed by
- further linking.
-
- `B'
- `b'
- The symbol is in the uninitialized data section (known as
- BSS).
-
- `C'
- The symbol is common. Common symbols are uninitialized data.
- When linking, multiple common symbols may appear with the
- same name. If the symbol is defined anywhere, the common
- symbols are treated as undefined references. For more
- details on common symbols, see the discussion of -warn-common
- in *note Linker options: (ld.info)Options.
-
- `D'
- `d'
- The symbol is in the initialized data section.
-
- `G'
- `g'
- The symbol is in an initialized data section for small
- objects. Some object file formats permit more efficient
- access to small data objects, such as a global int variable
- as opposed to a large global array.
-
- `i'
- For PE format files this indicates that the symbol is in a
- section specific to the implementation of DLLs. For ELF
- format files this indicates that the symbol is an indirect
- function. This is a GNU extension to the standard set of ELF
- symbol types. It indicates a symbol which if referenced by a
- relocation does not evaluate to its address, but instead must
- be invoked at runtime. The runtime execution will then
- return the value to be used in the relocation.
-
- `N'
- The symbol is a debugging symbol.
-
- `p'
- The symbols is in a stack unwind section.
-
- `R'
- `r'
- The symbol is in a read only data section.
-
- `S'
- `s'
- The symbol is in an uninitialized data section for small
- objects.
-
- `T'
- `t'
- The symbol is in the text (code) section.
-
- `U'
- The symbol is undefined.
-
- `u'
- The symbol is a unique global symbol. This is a GNU
- extension to the standard set of ELF symbol bindings. For
- such a symbol the dynamic linker will make sure that in the
- entire process there is just one symbol with this name and
- type in use.
-
- `V'
- `v'
- The symbol is a weak object. When a weak defined symbol is
- linked with a normal defined symbol, the normal defined
- symbol is used with no error. When a weak undefined symbol
- is linked and the symbol is not defined, the value of the
- weak symbol becomes zero with no error. On some systems,
- uppercase indicates that a default value has been specified.
-
- `W'
- `w'
- The symbol is a weak symbol that has not been specifically
- tagged as a weak object symbol. When a weak defined symbol
- is linked with a normal defined symbol, the normal defined
- symbol is used with no error. When a weak undefined symbol
- is linked and the symbol is not defined, the value of the
- symbol is determined in a system-specific manner without
- error. On some systems, uppercase indicates that a default
- value has been specified.
-
- `-'
- The symbol is a stabs symbol in an a.out object file. In
- this case, the next values printed are the stabs other field,
- the stabs desc field, and the stab type. Stabs symbols are
- used to hold debugging information. For more information,
- see *note Stabs: (stabs.info)Top.
-
- `?'
- The symbol type is unknown, or object file format specific.
-
- * The symbol name.
-
- The long and short forms of options, shown here as alternatives, are
-equivalent.
-
-`-A'
-`-o'
-`--print-file-name'
- Precede each symbol by the name of the input file (or archive
- member) in which it was found, rather than identifying the input
- file once only, before all of its symbols.
-
-`-a'
-`--debug-syms'
- Display all symbols, even debugger-only symbols; normally these
- are not listed.
-
-`-B'
- The same as `--format=bsd' (for compatibility with the MIPS `nm').
-
-`-C'
-`--demangle[=STYLE]'
- Decode ("demangle") low-level symbol names into user-level names.
- Besides removing any initial underscore prepended by the system,
- this makes C++ function names readable. Different compilers have
- different mangling styles. The optional demangling style argument
- can be used to choose an appropriate demangling style for your
- compiler. *Note c++filt::, for more information on demangling.
-
-`--no-demangle'
- Do not demangle low-level symbol names. This is the default.
-
-`-D'
-`--dynamic'
- Display the dynamic symbols rather than the normal symbols. This
- is only meaningful for dynamic objects, such as certain types of
- shared libraries.
-
-`-f FORMAT'
-`--format=FORMAT'
- Use the output format FORMAT, which can be `bsd', `sysv', or
- `posix'. The default is `bsd'. Only the first character of
- FORMAT is significant; it can be either upper or lower case.
-
-`-g'
-`--extern-only'
- Display only external symbols.
-
-`--plugin NAME'
- Load the plugin called NAME to add support for extra target types.
- This option is only available if the toolchain has been built with
- plugin support enabled.
-
-`-l'
-`--line-numbers'
- For each symbol, use debugging information to try to find a
- filename and line number. For a defined symbol, look for the line
- number of the address of the symbol. For an undefined symbol,
- look for the line number of a relocation entry which refers to the
- symbol. If line number information can be found, print it after
- the other symbol information.
-
-`-n'
-`-v'
-`--numeric-sort'
- Sort symbols numerically by their addresses, rather than
- alphabetically by their names.
-
-`-p'
-`--no-sort'
- Do not bother to sort the symbols in any order; print them in the
- order encountered.
-
-`-P'
-`--portability'
- Use the POSIX.2 standard output format instead of the default
- format. Equivalent to `-f posix'.
-
-`-S'
-`--print-size'
- Print both value and size of defined symbols for the `bsd' output
- style. This option has no effect for object formats that do not
- record symbol sizes, unless `--size-sort' is also used in which
- case a calculated size is displayed.
-
-`-s'
-`--print-armap'
- When listing symbols from archive members, include the index: a
- mapping (stored in the archive by `ar' or `ranlib') of which
- modules contain definitions for which names.
-
-`-r'
-`--reverse-sort'
- Reverse the order of the sort (whether numeric or alphabetic); let
- the last come first.
-
-`--size-sort'
- Sort symbols by size. The size is computed as the difference
- between the value of the symbol and the value of the symbol with
- the next higher value. If the `bsd' output format is used the
- size of the symbol is printed, rather than the value, and `-S'
- must be used in order both size and value to be printed.
-
-`--special-syms'
- Display symbols which have a target-specific special meaning.
- These symbols are usually used by the target for some special
- processing and are not normally helpful when included included in
- the normal symbol lists. For example for ARM targets this option
- would skip the mapping symbols used to mark transitions between
- ARM code, THUMB code and data.
-
-`-t RADIX'
-`--radix=RADIX'
- Use RADIX as the radix for printing the symbol values. It must be
- `d' for decimal, `o' for octal, or `x' for hexadecimal.
-
-`--target=BFDNAME'
- Specify an object code format other than your system's default
- format. *Note Target Selection::, for more information.
-
-`-u'
-`--undefined-only'
- Display only undefined symbols (those external to each object
- file).
-
-`--defined-only'
- Display only defined symbols for each object file.
-
-`-V'
-`--version'
- Show the version number of `nm' and exit.
-
-`-X'
- This option is ignored for compatibility with the AIX version of
- `nm'. It takes one parameter which must be the string `32_64'.
- The default mode of AIX `nm' corresponds to `-X 32', which is not
- supported by GNU `nm'.
-
-`--help'
- Show a summary of the options to `nm' and exit.
-
-
-File: binutils.info, Node: objcopy, Next: objdump, Prev: nm, Up: Top
-
-3 objcopy
-*********
-
- objcopy [`-F' BFDNAME|`--target='BFDNAME]
- [`-I' BFDNAME|`--input-target='BFDNAME]
- [`-O' BFDNAME|`--output-target='BFDNAME]
- [`-B' BFDARCH|`--binary-architecture='BFDARCH]
- [`-S'|`--strip-all']
- [`-g'|`--strip-debug']
- [`-K' SYMBOLNAME|`--keep-symbol='SYMBOLNAME]
- [`-N' SYMBOLNAME|`--strip-symbol='SYMBOLNAME]
- [`--strip-unneeded-symbol='SYMBOLNAME]
- [`-G' SYMBOLNAME|`--keep-global-symbol='SYMBOLNAME]
- [`--localize-hidden']
- [`-L' SYMBOLNAME|`--localize-symbol='SYMBOLNAME]
- [`--globalize-symbol='SYMBOLNAME]
- [`-W' SYMBOLNAME|`--weaken-symbol='SYMBOLNAME]
- [`-w'|`--wildcard']
- [`-x'|`--discard-all']
- [`-X'|`--discard-locals']
- [`-b' BYTE|`--byte='BYTE]
- [`-i' [BREADTH]|`--interleave'[=BREADTH]]
- [`--interleave-width='WIDTH]
- [`-j' SECTIONNAME|`--only-section='SECTIONNAME]
- [`-R' SECTIONNAME|`--remove-section='SECTIONNAME]
- [`-p'|`--preserve-dates']
- [`--debugging']
- [`--gap-fill='VAL]
- [`--pad-to='ADDRESS]
- [`--set-start='VAL]
- [`--adjust-start='INCR]
- [`--change-addresses='INCR]
- [`--change-section-address' SECTION{=,+,-}VAL]
- [`--change-section-lma' SECTION{=,+,-}VAL]
- [`--change-section-vma' SECTION{=,+,-}VAL]
- [`--change-warnings'] [`--no-change-warnings']
- [`--set-section-flags' SECTION=FLAGS]
- [`--add-section' SECTIONNAME=FILENAME]
- [`--rename-section' OLDNAME=NEWNAME[,FLAGS]]
- [`--long-section-names' {enable,disable,keep}]
- [`--change-leading-char'] [`--remove-leading-char']
- [`--reverse-bytes='NUM]
- [`--srec-len='IVAL] [`--srec-forceS3']
- [`--redefine-sym' OLD=NEW]
- [`--redefine-syms='FILENAME]
- [`--weaken']
- [`--keep-symbols='FILENAME]
- [`--strip-symbols='FILENAME]
- [`--strip-unneeded-symbols='FILENAME]
- [`--keep-global-symbols='FILENAME]
- [`--localize-symbols='FILENAME]
- [`--globalize-symbols='FILENAME]
- [`--weaken-symbols='FILENAME]
- [`--alt-machine-code='INDEX]
- [`--prefix-symbols='STRING]
- [`--prefix-sections='STRING]
- [`--prefix-alloc-sections='STRING]
- [`--add-gnu-debuglink='PATH-TO-FILE]
- [`--keep-file-symbols']
- [`--only-keep-debug']
- [`--extract-symbol']
- [`--writable-text']
- [`--readonly-text']
- [`--pure']
- [`--impure']
- [`--file-alignment='NUM]
- [`--heap='SIZE]
- [`--image-base='ADDRESS]
- [`--section-alignment='NUM]
- [`--stack='SIZE]
- [`--subsystem='WHICH:MAJOR.MINOR]
- [`--compress-debug-sections']
- [`--decompress-debug-sections']
- [`-v'|`--verbose']
- [`-V'|`--version']
- [`--help'] [`--info']
- INFILE [OUTFILE]
-
- The GNU `objcopy' utility copies the contents of an object file to
-another. `objcopy' uses the GNU BFD Library to read and write the
-object files. It can write the destination object file in a format
-different from that of the source object file. The exact behavior of
-`objcopy' is controlled by command-line options. Note that `objcopy'
-should be able to copy a fully linked file between any two formats.
-However, copying a relocatable object file between any two formats may
-not work as expected.
-
- `objcopy' creates temporary files to do its translations and deletes
-them afterward. `objcopy' uses BFD to do all its translation work; it
-has access to all the formats described in BFD and thus is able to
-recognize most formats without being told explicitly. *Note BFD:
-(ld.info)BFD.
-
- `objcopy' can be used to generate S-records by using an output
-target of `srec' (e.g., use `-O srec').
-
- `objcopy' can be used to generate a raw binary file by using an
-output target of `binary' (e.g., use `-O binary'). When `objcopy'
-generates a raw binary file, it will essentially produce a memory dump
-of the contents of the input object file. All symbols and relocation
-information will be discarded. The memory dump will start at the load
-address of the lowest section copied into the output file.
-
- When generating an S-record or a raw binary file, it may be helpful
-to use `-S' to remove sections containing debugging information. In
-some cases `-R' will be useful to remove sections which contain
-information that is not needed by the binary file.
-
- Note--`objcopy' is not able to change the endianness of its input
-files. If the input format has an endianness (some formats do not),
-`objcopy' can only copy the inputs into file formats that have the same
-endianness or which have no endianness (e.g., `srec'). (However, see
-the `--reverse-bytes' option.)
-
-`INFILE'
-`OUTFILE'
- The input and output files, respectively. If you do not specify
- OUTFILE, `objcopy' creates a temporary file and destructively
- renames the result with the name of INFILE.
-
-`-I BFDNAME'
-`--input-target=BFDNAME'
- Consider the source file's object format to be BFDNAME, rather than
- attempting to deduce it. *Note Target Selection::, for more
- information.
-
-`-O BFDNAME'
-`--output-target=BFDNAME'
- Write the output file using the object format BFDNAME. *Note
- Target Selection::, for more information.
-
-`-F BFDNAME'
-`--target=BFDNAME'
- Use BFDNAME as the object format for both the input and the output
- file; i.e., simply transfer data from source to destination with no
- translation. *Note Target Selection::, for more information.
-
-`-B BFDARCH'
-`--binary-architecture=BFDARCH'
- Useful when transforming a architecture-less input file into an
- object file. In this case the output architecture can be set to
- BFDARCH. This option will be ignored if the input file has a
- known BFDARCH. You can access this binary data inside a program
- by referencing the special symbols that are created by the
- conversion process. These symbols are called
- _binary_OBJFILE_start, _binary_OBJFILE_end and
- _binary_OBJFILE_size. e.g. you can transform a picture file into
- an object file and then access it in your code using these symbols.
-
-`-j SECTIONNAME'
-`--only-section=SECTIONNAME'
- Copy only the named section from the input file to the output file.
- This option may be given more than once. Note that using this
- option inappropriately may make the output file unusable.
-
-`-R SECTIONNAME'
-`--remove-section=SECTIONNAME'
- Remove any section named SECTIONNAME from the output file. This
- option may be given more than once. Note that using this option
- inappropriately may make the output file unusable.
-
-`-S'
-`--strip-all'
- Do not copy relocation and symbol information from the source file.
-
-`-g'
-`--strip-debug'
- Do not copy debugging symbols or sections from the source file.
-
-`--strip-unneeded'
- Strip all symbols that are not needed for relocation processing.
-
-`-K SYMBOLNAME'
-`--keep-symbol=SYMBOLNAME'
- When stripping symbols, keep symbol SYMBOLNAME even if it would
- normally be stripped. This option may be given more than once.
-
-`-N SYMBOLNAME'
-`--strip-symbol=SYMBOLNAME'
- Do not copy symbol SYMBOLNAME from the source file. This option
- may be given more than once.
-
-`--strip-unneeded-symbol=SYMBOLNAME'
- Do not copy symbol SYMBOLNAME from the source file unless it is
- needed by a relocation. This option may be given more than once.
-
-`-G SYMBOLNAME'
-`--keep-global-symbol=SYMBOLNAME'
- Keep only symbol SYMBOLNAME global. Make all other symbols local
- to the file, so that they are not visible externally. This option
- may be given more than once.
-
-`--localize-hidden'
- In an ELF object, mark all symbols that have hidden or internal
- visibility as local. This option applies on top of
- symbol-specific localization options such as `-L'.
-
-`-L SYMBOLNAME'
-`--localize-symbol=SYMBOLNAME'
- Make symbol SYMBOLNAME local to the file, so that it is not
- visible externally. This option may be given more than once.
-
-`-W SYMBOLNAME'
-`--weaken-symbol=SYMBOLNAME'
- Make symbol SYMBOLNAME weak. This option may be given more than
- once.
-
-`--globalize-symbol=SYMBOLNAME'
- Give symbol SYMBOLNAME global scoping so that it is visible
- outside of the file in which it is defined. This option may be
- given more than once.
-
-`-w'
-`--wildcard'
- Permit regular expressions in SYMBOLNAMEs used in other command
- line options. The question mark (?), asterisk (*), backslash (\)
- and square brackets ([]) operators can be used anywhere in the
- symbol name. If the first character of the symbol name is the
- exclamation point (!) then the sense of the switch is reversed for
- that symbol. For example:
-
- -w -W !foo -W fo*
-
- would cause objcopy to weaken all symbols that start with "fo"
- except for the symbol "foo".
-
-`-x'
-`--discard-all'
- Do not copy non-global symbols from the source file.
-
-`-X'
-`--discard-locals'
- Do not copy compiler-generated local symbols. (These usually
- start with `L' or `.'.)
-
-`-b BYTE'
-`--byte=BYTE'
- If interleaving has been enabled via the `--interleave' option
- then start the range of bytes to keep at the BYTEth byte. BYTE
- can be in the range from 0 to BREADTH-1, where BREADTH is the
- value given by the `--interleave' option.
-
-`-i [BREADTH]'
-`--interleave[=BREADTH]'
- Only copy a range out of every BREADTH bytes. (Header data is not
- affected). Select which byte in the range begins the copy with
- the `--byte' option. Select the width of the range with the
- `--interleave-width' option.
-
- This option is useful for creating files to program ROM. It is
- typically used with an `srec' output target. Note that `objcopy'
- will complain if you do not specify the `--byte' option as well.
-
- The default interleave breadth is 4, so with `--byte' set to 0,
- `objcopy' would copy the first byte out of every four bytes from
- the input to the output.
-
-`--interleave-width=WIDTH'
- When used with the `--interleave' option, copy WIDTH bytes at a
- time. The start of the range of bytes to be copied is set by the
- `--byte' option, and the extent of the range is set with the
- `--interleave' option.
-
- The default value for this option is 1. The value of WIDTH plus
- the BYTE value set by the `--byte' option must not exceed the
- interleave breadth set by the `--interleave' option.
-
- This option can be used to create images for two 16-bit flashes
- interleaved in a 32-bit bus by passing `-b 0 -i 4
- --interleave-width=2' and `-b 2 -i 4 --interleave-width=2' to two
- `objcopy' commands. If the input was '12345678' then the outputs
- would be '1256' and '3478' respectively.
-
-`-p'
-`--preserve-dates'
- Set the access and modification dates of the output file to be the
- same as those of the input file.
-
-`--debugging'
- Convert debugging information, if possible. This is not the
- default because only certain debugging formats are supported, and
- the conversion process can be time consuming.
-
-`--gap-fill VAL'
- Fill gaps between sections with VAL. This operation applies to
- the _load address_ (LMA) of the sections. It is done by increasing
- the size of the section with the lower address, and filling in the
- extra space created with VAL.
-
-`--pad-to ADDRESS'
- Pad the output file up to the load address ADDRESS. This is done
- by increasing the size of the last section. The extra space is
- filled in with the value specified by `--gap-fill' (default zero).
-
-`--set-start VAL'
- Set the start address of the new file to VAL. Not all object file
- formats support setting the start address.
-
-`--change-start INCR'
-`--adjust-start INCR'
- Change the start address by adding INCR. Not all object file
- formats support setting the start address.
-
-`--change-addresses INCR'
-`--adjust-vma INCR'
- Change the VMA and LMA addresses of all sections, as well as the
- start address, by adding INCR. Some object file formats do not
- permit section addresses to be changed arbitrarily. Note that
- this does not relocate the sections; if the program expects
- sections to be loaded at a certain address, and this option is
- used to change the sections such that they are loaded at a
- different address, the program may fail.
-
-`--change-section-address SECTION{=,+,-}VAL'
-`--adjust-section-vma SECTION{=,+,-}VAL'
- Set or change both the VMA address and the LMA address of the named
- SECTION. If `=' is used, the section address is set to VAL.
- Otherwise, VAL is added to or subtracted from the section address.
- See the comments under `--change-addresses', above. If SECTION
- does not exist in the input file, a warning will be issued, unless
- `--no-change-warnings' is used.
-
-`--change-section-lma SECTION{=,+,-}VAL'
- Set or change the LMA address of the named SECTION. The LMA
- address is the address where the section will be loaded into
- memory at program load time. Normally this is the same as the VMA
- address, which is the address of the section at program run time,
- but on some systems, especially those where a program is held in
- ROM, the two can be different. If `=' is used, the section
- address is set to VAL. Otherwise, VAL is added to or subtracted
- from the section address. See the comments under
- `--change-addresses', above. If SECTION does not exist in the
- input file, a warning will be issued, unless
- `--no-change-warnings' is used.
-
-`--change-section-vma SECTION{=,+,-}VAL'
- Set or change the VMA address of the named SECTION. The VMA
- address is the address where the section will be located once the
- program has started executing. Normally this is the same as the
- LMA address, which is the address where the section will be loaded
- into memory, but on some systems, especially those where a program
- is held in ROM, the two can be different. If `=' is used, the
- section address is set to VAL. Otherwise, VAL is added to or
- subtracted from the section address. See the comments under
- `--change-addresses', above. If SECTION does not exist in the
- input file, a warning will be issued, unless
- `--no-change-warnings' is used.
-
-`--change-warnings'
-`--adjust-warnings'
- If `--change-section-address' or `--change-section-lma' or
- `--change-section-vma' is used, and the named section does not
- exist, issue a warning. This is the default.
-
-`--no-change-warnings'
-`--no-adjust-warnings'
- Do not issue a warning if `--change-section-address' or
- `--adjust-section-lma' or `--adjust-section-vma' is used, even if
- the named section does not exist.
-
-`--set-section-flags SECTION=FLAGS'
- Set the flags for the named section. The FLAGS argument is a
- comma separated string of flag names. The recognized names are
- `alloc', `contents', `load', `noload', `readonly', `code', `data',
- `rom', `share', and `debug'. You can set the `contents' flag for
- a section which does not have contents, but it is not meaningful
- to clear the `contents' flag of a section which does have
- contents-just remove the section instead. Not all flags are
- meaningful for all object file formats.
-
-`--add-section SECTIONNAME=FILENAME'
- Add a new section named SECTIONNAME while copying the file. The
- contents of the new section are taken from the file FILENAME. The
- size of the section will be the size of the file. This option only
- works on file formats which can support sections with arbitrary
- names.
-
-`--rename-section OLDNAME=NEWNAME[,FLAGS]'
- Rename a section from OLDNAME to NEWNAME, optionally changing the
- section's flags to FLAGS in the process. This has the advantage
- over usng a linker script to perform the rename in that the output
- stays as an object file and does not become a linked executable.
-
- This option is particularly helpful when the input format is
- binary, since this will always create a section called .data. If
- for example, you wanted instead to create a section called .rodata
- containing binary data you could use the following command line to
- achieve it:
-
- objcopy -I binary -O <output_format> -B <architecture> \
- --rename-section .data=.rodata,alloc,load,readonly,data,contents \
- <input_binary_file> <output_object_file>
-
-`--long-section-names {enable,disable,keep}'
- Controls the handling of long section names when processing `COFF'
- and `PE-COFF' object formats. The default behaviour, `keep', is
- to preserve long section names if any are present in the input
- file. The `enable' and `disable' options forcibly enable or
- disable the use of long section names in the output object; when
- `disable' is in effect, any long section names in the input object
- will be truncated. The `enable' option will only emit long
- section names if any are present in the inputs; this is mostly the
- same as `keep', but it is left undefined whether the `enable'
- option might force the creation of an empty string table in the
- output file.
-
-`--change-leading-char'
- Some object file formats use special characters at the start of
- symbols. The most common such character is underscore, which
- compilers often add before every symbol. This option tells
- `objcopy' to change the leading character of every symbol when it
- converts between object file formats. If the object file formats
- use the same leading character, this option has no effect.
- Otherwise, it will add a character, or remove a character, or
- change a character, as appropriate.
-
-`--remove-leading-char'
- If the first character of a global symbol is a special symbol
- leading character used by the object file format, remove the
- character. The most common symbol leading character is
- underscore. This option will remove a leading underscore from all
- global symbols. This can be useful if you want to link together
- objects of different file formats with different conventions for
- symbol names. This is different from `--change-leading-char'
- because it always changes the symbol name when appropriate,
- regardless of the object file format of the output file.
-
-`--reverse-bytes=NUM'
- Reverse the bytes in a section with output contents. A section
- length must be evenly divisible by the value given in order for
- the swap to be able to take place. Reversing takes place before
- the interleaving is performed.
-
- This option is used typically in generating ROM images for
- problematic target systems. For example, on some target boards,
- the 32-bit words fetched from 8-bit ROMs are re-assembled in
- little-endian byte order regardless of the CPU byte order.
- Depending on the programming model, the endianness of the ROM may
- need to be modified.
-
- Consider a simple file with a section containing the following
- eight bytes: `12345678'.
-
- Using `--reverse-bytes=2' for the above example, the bytes in the
- output file would be ordered `21436587'.
-
- Using `--reverse-bytes=4' for the above example, the bytes in the
- output file would be ordered `43218765'.
-
- By using `--reverse-bytes=2' for the above example, followed by
- `--reverse-bytes=4' on the output file, the bytes in the second
- output file would be ordered `34127856'.
-
-`--srec-len=IVAL'
- Meaningful only for srec output. Set the maximum length of the
- Srecords being produced to IVAL. This length covers both address,
- data and crc fields.
-
-`--srec-forceS3'
- Meaningful only for srec output. Avoid generation of S1/S2
- records, creating S3-only record format.
-
-`--redefine-sym OLD=NEW'
- Change the name of a symbol OLD, to NEW. This can be useful when
- one is trying link two things together for which you have no
- source, and there are name collisions.
-
-`--redefine-syms=FILENAME'
- Apply `--redefine-sym' to each symbol pair "OLD NEW" listed in the
- file FILENAME. FILENAME is simply a flat file, with one symbol
- pair per line. Line comments may be introduced by the hash
- character. This option may be given more than once.
-
-`--weaken'
- Change all global symbols in the file to be weak. This can be
- useful when building an object which will be linked against other
- objects using the `-R' option to the linker. This option is only
- effective when using an object file format which supports weak
- symbols.
-
-`--keep-symbols=FILENAME'
- Apply `--keep-symbol' option to each symbol listed in the file
- FILENAME. FILENAME is simply a flat file, with one symbol name
- per line. Line comments may be introduced by the hash character.
- This option may be given more than once.
-
-`--strip-symbols=FILENAME'
- Apply `--strip-symbol' option to each symbol listed in the file
- FILENAME. FILENAME is simply a flat file, with one symbol name
- per line. Line comments may be introduced by the hash character.
- This option may be given more than once.
-
-`--strip-unneeded-symbols=FILENAME'
- Apply `--strip-unneeded-symbol' option to each symbol listed in
- the file FILENAME. FILENAME is simply a flat file, with one
- symbol name per line. Line comments may be introduced by the hash
- character. This option may be given more than once.
-
-`--keep-global-symbols=FILENAME'
- Apply `--keep-global-symbol' option to each symbol listed in the
- file FILENAME. FILENAME is simply a flat file, with one symbol
- name per line. Line comments may be introduced by the hash
- character. This option may be given more than once.
-
-`--localize-symbols=FILENAME'
- Apply `--localize-symbol' option to each symbol listed in the file
- FILENAME. FILENAME is simply a flat file, with one symbol name
- per line. Line comments may be introduced by the hash character.
- This option may be given more than once.
-
-`--globalize-symbols=FILENAME'
- Apply `--globalize-symbol' option to each symbol listed in the file
- FILENAME. FILENAME is simply a flat file, with one symbol name
- per line. Line comments may be introduced by the hash character.
- This option may be given more than once.
-
-`--weaken-symbols=FILENAME'
- Apply `--weaken-symbol' option to each symbol listed in the file
- FILENAME. FILENAME is simply a flat file, with one symbol name
- per line. Line comments may be introduced by the hash character.
- This option may be given more than once.
-
-`--alt-machine-code=INDEX'
- If the output architecture has alternate machine codes, use the
- INDEXth code instead of the default one. This is useful in case a
- machine is assigned an official code and the tool-chain adopts the
- new code, but other applications still depend on the original code
- being used. For ELF based architectures if the INDEX alternative
- does not exist then the value is treated as an absolute number to
- be stored in the e_machine field of the ELF header.
-
-`--writable-text'
- Mark the output text as writable. This option isn't meaningful
- for all object file formats.
-
-`--readonly-text'
- Make the output text write protected. This option isn't
- meaningful for all object file formats.
-
-`--pure'
- Mark the output file as demand paged. This option isn't
- meaningful for all object file formats.
-
-`--impure'
- Mark the output file as impure. This option isn't meaningful for
- all object file formats.
-
-`--prefix-symbols=STRING'
- Prefix all symbols in the output file with STRING.
-
-`--prefix-sections=STRING'
- Prefix all section names in the output file with STRING.
-
-`--prefix-alloc-sections=STRING'
- Prefix all the names of all allocated sections in the output file
- with STRING.
-
-`--add-gnu-debuglink=PATH-TO-FILE'
- Creates a .gnu_debuglink section which contains a reference to
- PATH-TO-FILE and adds it to the output file.
-
-`--keep-file-symbols'
- When stripping a file, perhaps with `--strip-debug' or
- `--strip-unneeded', retain any symbols specifying source file
- names, which would otherwise get stripped.
-
-`--only-keep-debug'
- Strip a file, removing contents of any sections that would not be
- stripped by `--strip-debug' and leaving the debugging sections
- intact. In ELF files, this preserves all note sections in the
- output.
-
- The intention is that this option will be used in conjunction with
- `--add-gnu-debuglink' to create a two part executable. One a
- stripped binary which will occupy less space in RAM and in a
- distribution and the second a debugging information file which is
- only needed if debugging abilities are required. The suggested
- procedure to create these files is as follows:
-
- 1. Link the executable as normal. Assuming that is is called
- `foo' then...
-
- 2. Run `objcopy --only-keep-debug foo foo.dbg' to create a file
- containing the debugging info.
-
- 3. Run `objcopy --strip-debug foo' to create a stripped
- executable.
-
- 4. Run `objcopy --add-gnu-debuglink=foo.dbg foo' to add a link
- to the debugging info into the stripped executable.
-
- Note--the choice of `.dbg' as an extension for the debug info file
- is arbitrary. Also the `--only-keep-debug' step is optional. You
- could instead do this:
-
- 1. Link the executable as normal.
-
- 2. Copy `foo' to `foo.full'
-
- 3. Run `objcopy --strip-debug foo'
-
- 4. Run `objcopy --add-gnu-debuglink=foo.full foo'
-
- i.e., the file pointed to by the `--add-gnu-debuglink' can be the
- full executable. It does not have to be a file created by the
- `--only-keep-debug' switch.
-
- Note--this switch is only intended for use on fully linked files.
- It does not make sense to use it on object files where the
- debugging information may be incomplete. Besides the
- gnu_debuglink feature currently only supports the presence of one
- filename containing debugging information, not multiple filenames
- on a one-per-object-file basis.
-
-`--file-alignment NUM'
- Specify the file alignment. Sections in the file will always
- begin at file offsets which are multiples of this number. This
- defaults to 512. [This option is specific to PE targets.]
-
-`--heap RESERVE'
-`--heap RESERVE,COMMIT'
- Specify the number of bytes of memory to reserve (and optionally
- commit) to be used as heap for this program. [This option is
- specific to PE targets.]
-
-`--image-base VALUE'
- Use VALUE as the base address of your program or dll. This is the
- lowest memory location that will be used when your program or dll
- is loaded. To reduce the need to relocate and improve performance
- of your dlls, each should have a unique base address and not
- overlap any other dlls. The default is 0x400000 for executables,
- and 0x10000000 for dlls. [This option is specific to PE targets.]
-
-`--section-alignment NUM'
- Sets the section alignment. Sections in memory will always begin
- at addresses which are a multiple of this number. Defaults to
- 0x1000. [This option is specific to PE targets.]
-
-`--stack RESERVE'
-`--stack RESERVE,COMMIT'
- Specify the number of bytes of memory to reserve (and optionally
- commit) to be used as stack for this program. [This option is
- specific to PE targets.]
-
-`--subsystem WHICH'
-`--subsystem WHICH:MAJOR'
-`--subsystem WHICH:MAJOR.MINOR'
- Specifies the subsystem under which your program will execute. The
- legal values for WHICH are `native', `windows', `console',
- `posix', `efi-app', `efi-bsd', `efi-rtd', `sal-rtd', and `xbox'.
- You may optionally set the subsystem version also. Numeric values
- are also accepted for WHICH. [This option is specific to PE
- targets.]
-
-`--extract-symbol'
- Keep the file's section flags and symbols but remove all section
- data. Specifically, the option:
-
- * removes the contents of all sections;
-
- * sets the size of every section to zero; and
-
- * sets the file's start address to zero.
-
- This option is used to build a `.sym' file for a VxWorks kernel.
- It can also be a useful way of reducing the size of a
- `--just-symbols' linker input file.
-
-`--compress-debug-sections'
- Compress DWARF debug sections using zlib.
-
-`--decompress-debug-sections'
- Decompress DWARF debug sections using zlib.
-
-`-V'
-`--version'
- Show the version number of `objcopy'.
-
-`-v'
-`--verbose'
- Verbose output: list all object files modified. In the case of
- archives, `objcopy -V' lists all members of the archive.
-
-`--help'
- Show a summary of the options to `objcopy'.
-
-`--info'
- Display a list showing all architectures and object formats
- available.
-
-
-File: binutils.info, Node: objdump, Next: ranlib, Prev: objcopy, Up: Top
-
-4 objdump
-*********
-
- objdump [`-a'|`--archive-headers']
- [`-b' BFDNAME|`--target=BFDNAME']
- [`-C'|`--demangle'[=STYLE] ]
- [`-d'|`--disassemble']
- [`-D'|`--disassemble-all']
- [`-z'|`--disassemble-zeroes']
- [`-EB'|`-EL'|`--endian='{big | little }]
- [`-f'|`--file-headers']
- [`-F'|`--file-offsets']
- [`--file-start-context']
- [`-g'|`--debugging']
- [`-e'|`--debugging-tags']
- [`-h'|`--section-headers'|`--headers']
- [`-i'|`--info']
- [`-j' SECTION|`--section='SECTION]
- [`-l'|`--line-numbers']
- [`-S'|`--source']
- [`-m' MACHINE|`--architecture='MACHINE]
- [`-M' OPTIONS|`--disassembler-options='OPTIONS]
- [`-p'|`--private-headers']
- [`-r'|`--reloc']
- [`-R'|`--dynamic-reloc']
- [`-s'|`--full-contents']
- [`-W[lLiaprmfFsoRt]'|
- `--dwarf'[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges]]
- [`-G'|`--stabs']
- [`-t'|`--syms']
- [`-T'|`--dynamic-syms']
- [`-x'|`--all-headers']
- [`-w'|`--wide']
- [`--start-address='ADDRESS]
- [`--stop-address='ADDRESS]
- [`--prefix-addresses']
- [`--[no-]show-raw-insn']
- [`--adjust-vma='OFFSET]
- [`--special-syms']
- [`--prefix='PREFIX]
- [`--prefix-strip='LEVEL]
- [`--insn-width='WIDTH]
- [`-V'|`--version']
- [`-H'|`--help']
- OBJFILE...
-
- `objdump' displays information about one or more object files. The
-options control what particular information to display. This
-information is mostly useful to programmers who are working on the
-compilation tools, as opposed to programmers who just want their
-program to compile and work.
-
- OBJFILE... are the object files to be examined. When you specify
-archives, `objdump' shows information on each of the member object
-files.
-
- The long and short forms of options, shown here as alternatives, are
-equivalent. At least one option from the list
-`-a,-d,-D,-e,-f,-g,-G,-h,-H,-p,-r,-R,-s,-S,-t,-T,-V,-x' must be given.
-
-`-a'
-`--archive-header'
- If any of the OBJFILE files are archives, display the archive
- header information (in a format similar to `ls -l'). Besides the
- information you could list with `ar tv', `objdump -a' shows the
- object file format of each archive member.
-
-`--adjust-vma=OFFSET'
- When dumping information, first add OFFSET to all the section
- addresses. This is useful if the section addresses do not
- correspond to the symbol table, which can happen when putting
- sections at particular addresses when using a format which can not
- represent section addresses, such as a.out.
-
-`-b BFDNAME'
-`--target=BFDNAME'
- Specify that the object-code format for the object files is
- BFDNAME. This option may not be necessary; OBJDUMP can
- automatically recognize many formats.
-
- For example,
- objdump -b oasys -m vax -h fu.o
- displays summary information from the section headers (`-h') of
- `fu.o', which is explicitly identified (`-m') as a VAX object file
- in the format produced by Oasys compilers. You can list the
- formats available with the `-i' option. *Note Target Selection::,
- for more information.
-
-`-C'
-`--demangle[=STYLE]'
- Decode ("demangle") low-level symbol names into user-level names.
- Besides removing any initial underscore prepended by the system,
- this makes C++ function names readable. Different compilers have
- different mangling styles. The optional demangling style argument
- can be used to choose an appropriate demangling style for your
- compiler. *Note c++filt::, for more information on demangling.
-
-`-g'
-`--debugging'
- Display debugging information. This attempts to parse STABS and
- IEEE debugging format information stored in the file and print it
- out using a C like syntax. If neither of these formats are found
- this option falls back on the `-W' option to print any DWARF
- information in the file.
-
-`-e'
-`--debugging-tags'
- Like `-g', but the information is generated in a format compatible
- with ctags tool.
-
-`-d'
-`--disassemble'
- Display the assembler mnemonics for the machine instructions from
- OBJFILE. This option only disassembles those sections which are
- expected to contain instructions.
-
-`-D'
-`--disassemble-all'
- Like `-d', but disassemble the contents of all sections, not just
- those expected to contain instructions.
-
- If the target is an ARM architecture this switch also has the
- effect of forcing the disassembler to decode pieces of data found
- in code sections as if they were instructions.
-
-`--prefix-addresses'
- When disassembling, print the complete address on each line. This
- is the older disassembly format.
-
-`-EB'
-`-EL'
-`--endian={big|little}'
- Specify the endianness of the object files. This only affects
- disassembly. This can be useful when disassembling a file format
- which does not describe endianness information, such as S-records.
-
-`-f'
-`--file-headers'
- Display summary information from the overall header of each of the
- OBJFILE files.
-
-`-F'
-`--file-offsets'
- When disassembling sections, whenever a symbol is displayed, also
- display the file offset of the region of data that is about to be
- dumped. If zeroes are being skipped, then when disassembly
- resumes, tell the user how many zeroes were skipped and the file
- offset of the location from where the disassembly resumes. When
- dumping sections, display the file offset of the location from
- where the dump starts.
-
-`--file-start-context'
- Specify that when displaying interlisted source code/disassembly
- (assumes `-S') from a file that has not yet been displayed, extend
- the context to the start of the file.
-
-`-h'
-`--section-headers'
-`--headers'
- Display summary information from the section headers of the object
- file.
-
- File segments may be relocated to nonstandard addresses, for
- example by using the `-Ttext', `-Tdata', or `-Tbss' options to
- `ld'. However, some object file formats, such as a.out, do not
- store the starting address of the file segments. In those
- situations, although `ld' relocates the sections correctly, using
- `objdump -h' to list the file section headers cannot show the
- correct addresses. Instead, it shows the usual addresses, which
- are implicit for the target.
-
-`-H'
-`--help'
- Print a summary of the options to `objdump' and exit.
-
-`-i'
-`--info'
- Display a list showing all architectures and object formats
- available for specification with `-b' or `-m'.
-
-`-j NAME'
-`--section=NAME'
- Display information only for section NAME.
-
-`-l'
-`--line-numbers'
- Label the display (using debugging information) with the filename
- and source line numbers corresponding to the object code or relocs
- shown. Only useful with `-d', `-D', or `-r'.
-
-`-m MACHINE'
-`--architecture=MACHINE'
- Specify the architecture to use when disassembling object files.
- This can be useful when disassembling object files which do not
- describe architecture information, such as S-records. You can
- list the available architectures with the `-i' option.
-
- If the target is an ARM architecture then this switch has an
- additional effect. It restricts the disassembly to only those
- instructions supported by the architecture specified by MACHINE.
- If it is necessary to use this switch because the input file does
- not contain any architecture information, but it is also desired to
- disassemble all the instructions use `-marm'.
-
-`-M OPTIONS'
-`--disassembler-options=OPTIONS'
- Pass target specific information to the disassembler. Only
- supported on some targets. If it is necessary to specify more
- than one disassembler option then multiple `-M' options can be
- used or can be placed together into a comma separated list.
-
- If the target is an ARM architecture then this switch can be used
- to select which register name set is used during disassembler.
- Specifying `-M reg-names-std' (the default) will select the
- register names as used in ARM's instruction set documentation, but
- with register 13 called 'sp', register 14 called 'lr' and register
- 15 called 'pc'. Specifying `-M reg-names-apcs' will select the
- name set used by the ARM Procedure Call Standard, whilst
- specifying `-M reg-names-raw' will just use `r' followed by the
- register number.
-
- There are also two variants on the APCS register naming scheme
- enabled by `-M reg-names-atpcs' and `-M reg-names-special-atpcs'
- which use the ARM/Thumb Procedure Call Standard naming
- conventions. (Either with the normal register names or the
- special register names).
-
- This option can also be used for ARM architectures to force the
- disassembler to interpret all instructions as Thumb instructions by
- using the switch `--disassembler-options=force-thumb'. This can be
- useful when attempting to disassemble thumb code produced by other
- compilers.
-
- For the x86, some of the options duplicate functions of the `-m'
- switch, but allow finer grained control. Multiple selections from
- the following may be specified as a comma separated string.
- `x86-64', `i386' and `i8086' select disassembly for the given
- architecture. `intel' and `att' select between intel syntax mode
- and AT&T syntax mode. `intel-mnemonic' and `att-mnemonic' select
- between intel mnemonic mode and AT&T mnemonic mode.
- `intel-mnemonic' implies `intel' and `att-mnemonic' implies `att'.
- `addr64', `addr32', `addr16', `data32' and `data16' specify the
- default address size and operand size. These four options will be
- overridden if `x86-64', `i386' or `i8086' appear later in the
- option string. Lastly, `suffix', when in AT&T mode, instructs the
- disassembler to print a mnemonic suffix even when the suffix could
- be inferred by the operands.
-
- For PowerPC, `booke' controls the disassembly of BookE
- instructions. `32' and `64' select PowerPC and PowerPC64
- disassembly, respectively. `e300' selects disassembly for the
- e300 family. `440' selects disassembly for the PowerPC 440.
- `ppcps' selects disassembly for the paired single instructions of
- the PPC750CL.
-
- For MIPS, this option controls the printing of instruction mnemonic
- names and register names in disassembled instructions. Multiple
- selections from the following may be specified as a comma separated
- string, and invalid options are ignored:
-
- `no-aliases'
- Print the 'raw' instruction mnemonic instead of some pseudo
- instruction mnemonic. I.e., print 'daddu' or 'or' instead of
- 'move', 'sll' instead of 'nop', etc.
-
- `gpr-names=ABI'
- Print GPR (general-purpose register) names as appropriate for
- the specified ABI. By default, GPR names are selected
- according to the ABI of the binary being disassembled.
-
- `fpr-names=ABI'
- Print FPR (floating-point register) names as appropriate for
- the specified ABI. By default, FPR numbers are printed
- rather than names.
-
- `cp0-names=ARCH'
- Print CP0 (system control coprocessor; coprocessor 0)
- register names as appropriate for the CPU or architecture
- specified by ARCH. By default, CP0 register names are
- selected according to the architecture and CPU of the binary
- being disassembled.
-
- `hwr-names=ARCH'
- Print HWR (hardware register, used by the `rdhwr'
- instruction) names as appropriate for the CPU or architecture
- specified by ARCH. By default, HWR names are selected
- according to the architecture and CPU of the binary being
- disassembled.
-
- `reg-names=ABI'
- Print GPR and FPR names as appropriate for the selected ABI.
-
- `reg-names=ARCH'
- Print CPU-specific register names (CP0 register and HWR names)
- as appropriate for the selected CPU or architecture.
-
- For any of the options listed above, ABI or ARCH may be specified
- as `numeric' to have numbers printed rather than names, for the
- selected types of registers. You can list the available values of
- ABI and ARCH using the `--help' option.
-
- For VAX, you can specify function entry addresses with `-M
- entry:0xf00ba'. You can use this multiple times to properly
- disassemble VAX binary files that don't contain symbol tables (like
- ROM dumps). In these cases, the function entry mask would
- otherwise be decoded as VAX instructions, which would probably
- lead the rest of the function being wrongly disassembled.
-
-`-p'
-`--private-headers'
- Print information that is specific to the object file format. The
- exact information printed depends upon the object file format.
- For some object file formats, no additional information is printed.
-
-`-r'
-`--reloc'
- Print the relocation entries of the file. If used with `-d' or
- `-D', the relocations are printed interspersed with the
- disassembly.
-
-`-R'
-`--dynamic-reloc'
- Print the dynamic relocation entries of the file. This is only
- meaningful for dynamic objects, such as certain types of shared
- libraries. As for `-r', if used with `-d' or `-D', the
- relocations are printed interspersed with the disassembly.
-
-`-s'
-`--full-contents'
- Display the full contents of any sections requested. By default
- all non-empty sections are displayed.
-
-`-S'
-`--source'
- Display source code intermixed with disassembly, if possible.
- Implies `-d'.
-
-`--prefix=PREFIX'
- Specify PREFIX to add to the absolute paths when used with `-S'.
-
-`--prefix-strip=LEVEL'
- Indicate how many initial directory names to strip off the
- hardwired absolute paths. It has no effect without
- `--prefix='PREFIX.
-
-`--show-raw-insn'
- When disassembling instructions, print the instruction in hex as
- well as in symbolic form. This is the default except when
- `--prefix-addresses' is used.
-
-`--no-show-raw-insn'
- When disassembling instructions, do not print the instruction
- bytes. This is the default when `--prefix-addresses' is used.
-
-`--insn-width=WIDTH'
- Display WIDTH bytes on a single line when disassembling
- instructions.
-
-`-W[lLiaprmfFsoRt]'
-`--dwarf[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges]'
- Displays the contents of the debug sections in the file, if any are
- present. If one of the optional letters or words follows the
- switch then only data found in those specific sections will be
- dumped.
-
- Note that there is no single letter option to display the content
- of trace sections.
-
-`-G'
-`--stabs'
- Display the full contents of any sections requested. Display the
- contents of the .stab and .stab.index and .stab.excl sections from
- an ELF file. This is only useful on systems (such as Solaris 2.0)
- in which `.stab' debugging symbol-table entries are carried in an
- ELF section. In most other file formats, debugging symbol-table
- entries are interleaved with linkage symbols, and are visible in
- the `--syms' output. For more information on stabs symbols, see
- *note Stabs: (stabs.info)Top.
-
-`--start-address=ADDRESS'
- Start displaying data at the specified address. This affects the
- output of the `-d', `-r' and `-s' options.
-
-`--stop-address=ADDRESS'
- Stop displaying data at the specified address. This affects the
- output of the `-d', `-r' and `-s' options.
-
-`-t'
-`--syms'
- Print the symbol table entries of the file. This is similar to
- the information provided by the `nm' program, although the display
- format is different. The format of the output depends upon the
- format of the file being dumped, but there are two main types.
- One looks like this:
-
- [ 4](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .bss
- [ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 fred
-
- where the number inside the square brackets is the number of the
- entry in the symbol table, the SEC number is the section number,
- the FL value are the symbol's flag bits, the TY number is the
- symbol's type, the SCL number is the symbol's storage class and
- the NX value is the number of auxilary entries associated with the
- symbol. The last two fields are the symbol's value and its name.
-
- The other common output format, usually seen with ELF based files,
- looks like this:
-
- 00000000 l d .bss 00000000 .bss
- 00000000 g .text 00000000 fred
-
- Here the first number is the symbol's value (sometimes refered to
- as its address). The next field is actually a set of characters
- and spaces indicating the flag bits that are set on the symbol.
- These characters are described below. Next is the section with
- which the symbol is associated or _*ABS*_ if the section is
- absolute (ie not connected with any section), or _*UND*_ if the
- section is referenced in the file being dumped, but not defined
- there.
-
- After the section name comes another field, a number, which for
- common symbols is the alignment and for other symbol is the size.
- Finally the symbol's name is displayed.
-
- The flag characters are divided into 7 groups as follows:
- `l'
- `g'
- `u'
- `!'
- The symbol is a local (l), global (g), unique global (u),
- neither global nor local (a space) or both global and local
- (!). A symbol can be neither local or global for a variety
- of reasons, e.g., because it is used for debugging, but it is
- probably an indication of a bug if it is ever both local and
- global. Unique global symbols are a GNU extension to the
- standard set of ELF symbol bindings. For such a symbol the
- dynamic linker will make sure that in the entire process
- there is just one symbol with this name and type in use.
-
- `w'
- The symbol is weak (w) or strong (a space).
-
- `C'
- The symbol denotes a constructor (C) or an ordinary symbol (a
- space).
-
- `W'
- The symbol is a warning (W) or a normal symbol (a space). A
- warning symbol's name is a message to be displayed if the
- symbol following the warning symbol is ever referenced.
-
- `I'
-
- `i'
- The symbol is an indirect reference to another symbol (I), a
- function to be evaluated during reloc processing (i) or a
- normal symbol (a space).
-
- `d'
- `D'
- The symbol is a debugging symbol (d) or a dynamic symbol (D)
- or a normal symbol (a space).
-
- `F'
-
- `f'
-
- `O'
- The symbol is the name of a function (F) or a file (f) or an
- object (O) or just a normal symbol (a space).
-
-`-T'
-`--dynamic-syms'
- Print the dynamic symbol table entries of the file. This is only
- meaningful for dynamic objects, such as certain types of shared
- libraries. This is similar to the information provided by the `nm'
- program when given the `-D' (`--dynamic') option.
-
-`--special-syms'
- When displaying symbols include those which the target considers
- to be special in some way and which would not normally be of
- interest to the user.
-
-`-V'
-`--version'
- Print the version number of `objdump' and exit.
-
-`-x'
-`--all-headers'
- Display all available header information, including the symbol
- table and relocation entries. Using `-x' is equivalent to
- specifying all of `-a -f -h -p -r -t'.
-
-`-w'
-`--wide'
- Format some lines for output devices that have more than 80
- columns. Also do not truncate symbol names when they are
- displayed.
-
-`-z'
-`--disassemble-zeroes'
- Normally the disassembly output will skip blocks of zeroes. This
- option directs the disassembler to disassemble those blocks, just
- like any other data.
-
-
-File: binutils.info, Node: ranlib, Next: readelf, Prev: objdump, Up: Top
-
-5 ranlib
-********
-
- ranlib [`-vVt'] ARCHIVE
-
- `ranlib' generates an index to the contents of an archive and stores
-it in the archive. The index lists each symbol defined by a member of
-an archive that is a relocatable object file.
-
- You may use `nm -s' or `nm --print-armap' to list this index.
-
- An archive with such an index speeds up linking to the library and
-allows routines in the library to call each other without regard to
-their placement in the archive.
-
- The GNU `ranlib' program is another form of GNU `ar'; running
-`ranlib' is completely equivalent to executing `ar -s'. *Note ar::.
-
-`-v'
-`-V'
-`--version'
- Show the version number of `ranlib'.
-
-`-t'
- Update the timestamp of the symbol map of an archive.
-
-
-File: binutils.info, Node: size, Next: strings, Prev: readelf, Up: Top
-
-6 size
-******
-
- size [`-A'|`-B'|`--format='COMPATIBILITY]
- [`--help']
- [`-d'|`-o'|`-x'|`--radix='NUMBER]
- [`--common']
- [`-t'|`--totals']
- [`--target='BFDNAME] [`-V'|`--version']
- [OBJFILE...]
-
- The GNU `size' utility lists the section sizes--and the total
-size--for each of the object or archive files OBJFILE in its argument
-list. By default, one line of output is generated for each object file
-or each module in an archive.
-
- OBJFILE... are the object files to be examined. If none are
-specified, the file `a.out' will be used.
-
- The command line options have the following meanings:
-
-`-A'
-`-B'
-`--format=COMPATIBILITY'
- Using one of these options, you can choose whether the output from
- GNU `size' resembles output from System V `size' (using `-A', or
- `--format=sysv'), or Berkeley `size' (using `-B', or
- `--format=berkeley'). The default is the one-line format similar
- to Berkeley's.
-
- Here is an example of the Berkeley (default) format of output from
- `size':
- $ size --format=Berkeley ranlib size
- text data bss dec hex filename
- 294880 81920 11592 388392 5ed28 ranlib
- 294880 81920 11888 388688 5ee50 size
-
- This is the same data, but displayed closer to System V
- conventions:
-
- $ size --format=SysV ranlib size
- ranlib :
- section size addr
- .text 294880 8192
- .data 81920 303104
- .bss 11592 385024
- Total 388392
-
-
- size :
- section size addr
- .text 294880 8192
- .data 81920 303104
- .bss 11888 385024
- Total 388688
-
-`--help'
- Show a summary of acceptable arguments and options.
-
-`-d'
-`-o'
-`-x'
-`--radix=NUMBER'
- Using one of these options, you can control whether the size of
- each section is given in decimal (`-d', or `--radix=10'); octal
- (`-o', or `--radix=8'); or hexadecimal (`-x', or `--radix=16').
- In `--radix=NUMBER', only the three values (8, 10, 16) are
- supported. The total size is always given in two radices; decimal
- and hexadecimal for `-d' or `-x' output, or octal and hexadecimal
- if you're using `-o'.
-
-`--common'
- Print total size of common symbols in each file. When using
- Berkeley format these are included in the bss size.
-
-`-t'
-`--totals'
- Show totals of all objects listed (Berkeley format listing mode
- only).
-
-`--target=BFDNAME'
- Specify that the object-code format for OBJFILE is BFDNAME. This
- option may not be necessary; `size' can automatically recognize
- many formats. *Note Target Selection::, for more information.
-
-`-V'
-`--version'
- Display the version number of `size'.
-
-
-File: binutils.info, Node: strings, Next: strip, Prev: size, Up: Top
-
-7 strings
-*********
-
- strings [`-afovV'] [`-'MIN-LEN]
- [`-n' MIN-LEN] [`--bytes='MIN-LEN]
- [`-t' RADIX] [`--radix='RADIX]
- [`-e' ENCODING] [`--encoding='ENCODING]
- [`-'] [`--all'] [`--print-file-name']
- [`-T' BFDNAME] [`--target='BFDNAME]
- [`--help'] [`--version'] FILE...
-
- For each FILE given, GNU `strings' prints the printable character
-sequences that are at least 4 characters long (or the number given with
-the options below) and are followed by an unprintable character. By
-default, it only prints the strings from the initialized and loaded
-sections of object files; for other types of files, it prints the
-strings from the whole file.
-
- `strings' is mainly useful for determining the contents of non-text
-files.
-
-`-a'
-`--all'
-`-'
- Do not scan only the initialized and loaded sections of object
- files; scan the whole files.
-
-`-f'
-`--print-file-name'
- Print the name of the file before each string.
-
-`--help'
- Print a summary of the program usage on the standard output and
- exit.
-
-`-MIN-LEN'
-`-n MIN-LEN'
-`--bytes=MIN-LEN'
- Print sequences of characters that are at least MIN-LEN characters
- long, instead of the default 4.
-
-`-o'
- Like `-t o'. Some other versions of `strings' have `-o' act like
- `-t d' instead. Since we can not be compatible with both ways, we
- simply chose one.
-
-`-t RADIX'
-`--radix=RADIX'
- Print the offset within the file before each string. The single
- character argument specifies the radix of the offset--`o' for
- octal, `x' for hexadecimal, or `d' for decimal.
-
-`-e ENCODING'
-`--encoding=ENCODING'
- Select the character encoding of the strings that are to be found.
- Possible values for ENCODING are: `s' = single-7-bit-byte
- characters (ASCII, ISO 8859, etc., default), `S' =
- single-8-bit-byte characters, `b' = 16-bit bigendian, `l' = 16-bit
- littleendian, `B' = 32-bit bigendian, `L' = 32-bit littleendian.
- Useful for finding wide character strings. (`l' and `b' apply to,
- for example, Unicode UTF-16/UCS-2 encodings).
-
-`-T BFDNAME'
-`--target=BFDNAME'
- Specify an object code format other than your system's default
- format. *Note Target Selection::, for more information.
-
-`-v'
-`-V'
-`--version'
- Print the program version number on the standard output and exit.
-
-
-File: binutils.info, Node: strip, Next: elfedit, Prev: strings, Up: Top
-
-8 strip
-*******
-
- strip [`-F' BFDNAME |`--target='BFDNAME]
- [`-I' BFDNAME |`--input-target='BFDNAME]
- [`-O' BFDNAME |`--output-target='BFDNAME]
- [`-s'|`--strip-all']
- [`-S'|`-g'|`-d'|`--strip-debug']
- [`-K' SYMBOLNAME |`--keep-symbol='SYMBOLNAME]
- [`-N' SYMBOLNAME |`--strip-symbol='SYMBOLNAME]
- [`-w'|`--wildcard']
- [`-x'|`--discard-all'] [`-X' |`--discard-locals']
- [`-R' SECTIONNAME |`--remove-section='SECTIONNAME]
- [`-o' FILE] [`-p'|`--preserve-dates']
- [`--keep-file-symbols']
- [`--only-keep-debug']
- [`-v' |`--verbose'] [`-V'|`--version']
- [`--help'] [`--info']
- OBJFILE...
-
- GNU `strip' discards all symbols from object files OBJFILE. The
-list of object files may include archives. At least one object file
-must be given.
-
- `strip' modifies the files named in its argument, rather than
-writing modified copies under different names.
-
-`-F BFDNAME'
-`--target=BFDNAME'
- Treat the original OBJFILE as a file with the object code format
- BFDNAME, and rewrite it in the same format. *Note Target
- Selection::, for more information.
-
-`--help'
- Show a summary of the options to `strip' and exit.
-
-`--info'
- Display a list showing all architectures and object formats
- available.
-
-`-I BFDNAME'
-`--input-target=BFDNAME'
- Treat the original OBJFILE as a file with the object code format
- BFDNAME. *Note Target Selection::, for more information.
-
-`-O BFDNAME'
-`--output-target=BFDNAME'
- Replace OBJFILE with a file in the output format BFDNAME. *Note
- Target Selection::, for more information.
-
-`-R SECTIONNAME'
-`--remove-section=SECTIONNAME'
- Remove any section named SECTIONNAME from the output file. This
- option may be given more than once. Note that using this option
- inappropriately may make the output file unusable.
-
-`-s'
-`--strip-all'
- Remove all symbols.
-
-`-g'
-`-S'
-`-d'
-`--strip-debug'
- Remove debugging symbols only.
-
-`--strip-unneeded'
- Remove all symbols that are not needed for relocation processing.
-
-`-K SYMBOLNAME'
-`--keep-symbol=SYMBOLNAME'
- When stripping symbols, keep symbol SYMBOLNAME even if it would
- normally be stripped. This option may be given more than once.
-
-`-N SYMBOLNAME'
-`--strip-symbol=SYMBOLNAME'
- Remove symbol SYMBOLNAME from the source file. This option may be
- given more than once, and may be combined with strip options other
- than `-K'.
-
-`-o FILE'
- Put the stripped output in FILE, rather than replacing the
- existing file. When this argument is used, only one OBJFILE
- argument may be specified.
-
-`-p'
-`--preserve-dates'
- Preserve the access and modification dates of the file.
-
-`-w'
-`--wildcard'
- Permit regular expressions in SYMBOLNAMEs used in other command
- line options. The question mark (?), asterisk (*), backslash (\)
- and square brackets ([]) operators can be used anywhere in the
- symbol name. If the first character of the symbol name is the
- exclamation point (!) then the sense of the switch is reversed for
- that symbol. For example:
-
- -w -K !foo -K fo*
-
- would cause strip to only keep symbols that start with the letters
- "fo", but to discard the symbol "foo".
-
-`-x'
-`--discard-all'
- Remove non-global symbols.
-
-`-X'
-`--discard-locals'
- Remove compiler-generated local symbols. (These usually start
- with `L' or `.'.)
-
-`--keep-file-symbols'
- When stripping a file, perhaps with `--strip-debug' or
- `--strip-unneeded', retain any symbols specifying source file
- names, which would otherwise get stripped.
-
-`--only-keep-debug'
- Strip a file, removing contents of any sections that would not be
- stripped by `--strip-debug' and leaving the debugging sections
- intact. In ELF files, this preserves all note sections in the
- output.
-
- The intention is that this option will be used in conjunction with
- `--add-gnu-debuglink' to create a two part executable. One a
- stripped binary which will occupy less space in RAM and in a
- distribution and the second a debugging information file which is
- only needed if debugging abilities are required. The suggested
- procedure to create these files is as follows:
-
- 1. Link the executable as normal. Assuming that is is called
- `foo' then...
-
- 2. Run `objcopy --only-keep-debug foo foo.dbg' to create a file
- containing the debugging info.
-
- 3. Run `objcopy --strip-debug foo' to create a stripped
- executable.
-
- 4. Run `objcopy --add-gnu-debuglink=foo.dbg foo' to add a link
- to the debugging info into the stripped executable.
-
- Note--the choice of `.dbg' as an extension for the debug info file
- is arbitrary. Also the `--only-keep-debug' step is optional. You
- could instead do this:
-
- 1. Link the executable as normal.
-
- 2. Copy `foo' to `foo.full'
-
- 3. Run `strip --strip-debug foo'
-
- 4. Run `objcopy --add-gnu-debuglink=foo.full foo'
-
- i.e., the file pointed to by the `--add-gnu-debuglink' can be the
- full executable. It does not have to be a file created by the
- `--only-keep-debug' switch.
-
- Note--this switch is only intended for use on fully linked files.
- It does not make sense to use it on object files where the
- debugging information may be incomplete. Besides the
- gnu_debuglink feature currently only supports the presence of one
- filename containing debugging information, not multiple filenames
- on a one-per-object-file basis.
-
-`-V'
-`--version'
- Show the version number for `strip'.
-
-`-v'
-`--verbose'
- Verbose output: list all object files modified. In the case of
- archives, `strip -v' lists all members of the archive.
-
-
-File: binutils.info, Node: c++filt, Next: addr2line, Prev: elfedit, Up: Top
-
-9 c++filt
-*********
-
- c++filt [`-_'|`--strip-underscores']
- [`-n'|`--no-strip-underscores']
- [`-p'|`--no-params']
- [`-t'|`--types']
- [`-i'|`--no-verbose']
- [`-s' FORMAT|`--format='FORMAT]
- [`--help'] [`--version'] [SYMBOL...]
-
- The C++ and Java languages provide function overloading, which means
-that you can write many functions with the same name, providing that
-each function takes parameters of different types. In order to be able
-to distinguish these similarly named functions C++ and Java encode them
-into a low-level assembler name which uniquely identifies each
-different version. This process is known as "mangling". The `c++filt'
-(1) program does the inverse mapping: it decodes ("demangles") low-level
-names into user-level names so that they can be read.
-
- Every alphanumeric word (consisting of letters, digits, underscores,
-dollars, or periods) seen in the input is a potential mangled name. If
-the name decodes into a C++ name, the C++ name replaces the low-level
-name in the output, otherwise the original word is output. In this way
-you can pass an entire assembler source file, containing mangled names,
-through `c++filt' and see the same source file containing demangled
-names.
-
- You can also use `c++filt' to decipher individual symbols by passing
-them on the command line:
-
- c++filt SYMBOL
-
- If no SYMBOL arguments are given, `c++filt' reads symbol names from
-the standard input instead. All the results are printed on the
-standard output. The difference between reading names from the command
-line versus reading names from the standard input is that command line
-arguments are expected to be just mangled names and no checking is
-performed to separate them from surrounding text. Thus for example:
-
- c++filt -n _Z1fv
-
- will work and demangle the name to "f()" whereas:
-
- c++filt -n _Z1fv,
-
- will not work. (Note the extra comma at the end of the mangled name
-which makes it invalid). This command however will work:
-
- echo _Z1fv, | c++filt -n
-
- and will display "f(),", i.e., the demangled name followed by a
-trailing comma. This behaviour is because when the names are read from
-the standard input it is expected that they might be part of an
-assembler source file where there might be extra, extraneous characters
-trailing after a mangled name. For example:
-
- .type _Z1fv, @function
-
-`-_'
-`--strip-underscores'
- On some systems, both the C and C++ compilers put an underscore in
- front of every name. For example, the C name `foo' gets the
- low-level name `_foo'. This option removes the initial
- underscore. Whether `c++filt' removes the underscore by default
- is target dependent.
-
-`-n'
-`--no-strip-underscores'
- Do not remove the initial underscore.
-
-`-p'
-`--no-params'
- When demangling the name of a function, do not display the types of
- the function's parameters.
-
-`-t'
-`--types'
- Attempt to demangle types as well as function names. This is
- disabled by default since mangled types are normally only used
- internally in the compiler, and they can be confused with
- non-mangled names. For example, a function called "a" treated as
- a mangled type name would be demangled to "signed char".
-
-`-i'
-`--no-verbose'
- Do not include implementation details (if any) in the demangled
- output.
-
-`-s FORMAT'
-`--format=FORMAT'
- `c++filt' can decode various methods of mangling, used by
- different compilers. The argument to this option selects which
- method it uses:
-
- `auto'
- Automatic selection based on executable (the default method)
-
- `gnu'
- the one used by the GNU C++ compiler (g++)
-
- `lucid'
- the one used by the Lucid compiler (lcc)
-
- `arm'
- the one specified by the C++ Annotated Reference Manual
-
- `hp'
- the one used by the HP compiler (aCC)
-
- `edg'
- the one used by the EDG compiler
-
- `gnu-v3'
- the one used by the GNU C++ compiler (g++) with the V3 ABI.
-
- `java'
- the one used by the GNU Java compiler (gcj)
-
- `gnat'
- the one used by the GNU Ada compiler (GNAT).
-
-`--help'
- Print a summary of the options to `c++filt' and exit.
-
-`--version'
- Print the version number of `c++filt' and exit.
-
- _Warning:_ `c++filt' is a new utility, and the details of its user
- interface are subject to change in future releases. In particular,
- a command-line option may be required in the future to decode a
- name passed as an argument on the command line; in other words,
-
- c++filt SYMBOL
-
- may in a future release become
-
- c++filt OPTION SYMBOL
-
- ---------- Footnotes ----------
-
- (1) MS-DOS does not allow `+' characters in file names, so on MS-DOS
-this program is named `CXXFILT'.
-
-
-File: binutils.info, Node: addr2line, Next: nlmconv, Prev: c++filt, Up: Top
-
-10 addr2line
-************
-
- addr2line [`-a'|`--addresses']
- [`-b' BFDNAME|`--target='BFDNAME]
- [`-C'|`--demangle'[=STYLE]]
- [`-e' FILENAME|`--exe='FILENAME]
- [`-f'|`--functions'] [`-s'|`--basename']
- [`-i'|`--inlines']
- [`-p'|`--pretty-print']
- [`-j'|`--section='NAME]
- [`-H'|`--help'] [`-V'|`--version']
- [addr addr ...]
-
- `addr2line' translates addresses into file names and line numbers.
-Given an address in an executable or an offset in a section of a
-relocatable object, it uses the debugging information to figure out
-which file name and line number are associated with it.
-
- The executable or relocatable object to use is specified with the
-`-e' option. The default is the file `a.out'. The section in the
-relocatable object to use is specified with the `-j' option.
-
- `addr2line' has two modes of operation.
-
- In the first, hexadecimal addresses are specified on the command
-line, and `addr2line' displays the file name and line number for each
-address.
-
- In the second, `addr2line' reads hexadecimal addresses from standard
-input, and prints the file name and line number for each address on
-standard output. In this mode, `addr2line' may be used in a pipe to
-convert dynamically chosen addresses.
-
- The format of the output is `FILENAME:LINENO'. The file name and
-line number for each address is printed on a separate line. If the
-`-f' option is used, then each `FILENAME:LINENO' line is preceded by a
-`FUNCTIONNAME' line which is the name of the function containing the
-address. If the `-a' option is used, then the address read is first
-printed.
-
- If the file name or function name can not be determined, `addr2line'
-will print two question marks in their place. If the line number can
-not be determined, `addr2line' will print 0.
-
- The long and short forms of options, shown here as alternatives, are
-equivalent.
-
-`-a'
-`--addresses'
- Display address before function names or file and line number
- information. The address is printed with a `0x' prefix to easily
- identify it.
-
-`-b BFDNAME'
-`--target=BFDNAME'
- Specify that the object-code format for the object files is
- BFDNAME.
-
-`-C'
-`--demangle[=STYLE]'
- Decode ("demangle") low-level symbol names into user-level names.
- Besides removing any initial underscore prepended by the system,
- this makes C++ function names readable. Different compilers have
- different mangling styles. The optional demangling style argument
- can be used to choose an appropriate demangling style for your
- compiler. *Note c++filt::, for more information on demangling.
-
-`-e FILENAME'
-`--exe=FILENAME'
- Specify the name of the executable for which addresses should be
- translated. The default file is `a.out'.
-
-`-f'
-`--functions'
- Display function names as well as file and line number information.
-
-`-s'
-`--basenames'
- Display only the base of each file name.
-
-`-i'
-`--inlines'
- If the address belongs to a function that was inlined, the source
- information for all enclosing scopes back to the first non-inlined
- function will also be printed. For example, if `main' inlines
- `callee1' which inlines `callee2', and address is from `callee2',
- the source information for `callee1' and `main' will also be
- printed.
-
-`-j'
-`--section'
- Read offsets relative to the specified section instead of absolute
- addresses.
-
-`-p'
-`--pretty-print'
- Make the output more human friendly: each location are printed on
- one line. If option `-i' is specified, lines for all enclosing
- scopes are prefixed with `(inlined by)'.
-
-
-File: binutils.info, Node: nlmconv, Next: windres, Prev: addr2line, Up: Top
-
-11 nlmconv
-**********
-
-`nlmconv' converts a relocatable object file into a NetWare Loadable
-Module.
-
- _Warning:_ `nlmconv' is not always built as part of the binary
- utilities, since it is only useful for NLM targets.
-
- nlmconv [`-I' BFDNAME|`--input-target='BFDNAME]
- [`-O' BFDNAME|`--output-target='BFDNAME]
- [`-T' HEADERFILE|`--header-file='HEADERFILE]
- [`-d'|`--debug'] [`-l' LINKER|`--linker='LINKER]
- [`-h'|`--help'] [`-V'|`--version']
- INFILE OUTFILE
-
- `nlmconv' converts the relocatable `i386' object file INFILE into
-the NetWare Loadable Module OUTFILE, optionally reading HEADERFILE for
-NLM header information. For instructions on writing the NLM command
-file language used in header files, see the `linkers' section,
-`NLMLINK' in particular, of the `NLM Development and Tools Overview',
-which is part of the NLM Software Developer's Kit ("NLM SDK"),
-available from Novell, Inc. `nlmconv' uses the GNU Binary File
-Descriptor library to read INFILE; see *note BFD: (ld.info)BFD, for
-more information.
-
- `nlmconv' can perform a link step. In other words, you can list
-more than one object file for input if you list them in the definitions
-file (rather than simply specifying one input file on the command line).
-In this case, `nlmconv' calls the linker for you.
-
-`-I BFDNAME'
-`--input-target=BFDNAME'
- Object format of the input file. `nlmconv' can usually determine
- the format of a given file (so no default is necessary). *Note
- Target Selection::, for more information.
-
-`-O BFDNAME'
-`--output-target=BFDNAME'
- Object format of the output file. `nlmconv' infers the output
- format based on the input format, e.g. for a `i386' input file the
- output format is `nlm32-i386'. *Note Target Selection::, for more
- information.
-
-`-T HEADERFILE'
-`--header-file=HEADERFILE'
- Reads HEADERFILE for NLM header information. For instructions on
- writing the NLM command file language used in header files, see
- see the `linkers' section, of the `NLM Development and Tools
- Overview', which is part of the NLM Software Developer's Kit,
- available from Novell, Inc.
-
-`-d'
-`--debug'
- Displays (on standard error) the linker command line used by
- `nlmconv'.
-
-`-l LINKER'
-`--linker=LINKER'
- Use LINKER for any linking. LINKER can be an absolute or a
- relative pathname.
-
-`-h'
-`--help'
- Prints a usage summary.
-
-`-V'
-`--version'
- Prints the version number for `nlmconv'.
-
-
-File: binutils.info, Node: windmc, Next: dlltool, Prev: windres, Up: Top
-
-12 windmc
-*********
-
-`windmc' may be used to generator Windows message resources.
-
- _Warning:_ `windmc' is not always built as part of the binary
- utilities, since it is only useful for Windows targets.
-
- windmc [options] input-file
-
- `windmc' reads message definitions from an input file (.mc) and
-translate them into a set of output files. The output files may be of
-four kinds:
-
-`h'
- A C header file containing the message definitions.
-
-`rc'
- A resource file compilable by the `windres' tool.
-
-`bin'
- One or more binary files containing the resource data for a
- specific message language.
-
-`dbg'
- A C include file that maps message id's to their symbolic name.
-
- The exact description of these different formats is available in
-documentation from Microsoft.
-
- When `windmc' converts from the `mc' format to the `bin' format,
-`rc', `h', and optional `dbg' it is acting like the Windows Message
-Compiler.
-
-`-a'
-`--ascii_in'
- Specifies that the input file specified is ASCII. This is the
- default behaviour.
-
-`-A'
-`--ascii_out'
- Specifies that messages in the output `bin' files should be in
- ASCII format.
-
-`-b'
-`--binprefix'
- Specifies that `bin' filenames should have to be prefixed by the
- basename of the source file.
-
-`-c'
-`--customflag'
- Sets the customer bit in all message id's.
-
-`-C CODEPAGE'
-`--codepage_in CODEPAGE'
- Sets the default codepage to be used to convert input file to
- UTF16. The default is ocdepage 1252.
-
-`-d'
-`--decimal_values'
- Outputs the constants in the header file in decimal. Default is
- using hexadecimal output.
-
-`-e EXT'
-`--extension EXT'
- The extension for the header file. The default is .h extension.
-
-`-F TARGET'
-`--target TARGET'
- Specify the BFD format to use for a bin file as output. This is a
- BFD target name; you can use the `--help' option to see a list of
- supported targets. Normally `windmc' will use the default format,
- which is the first one listed by the `--help' option. *note
- Target Selection::.
-
-`-h PATH'
-`--headerdir PATH'
- The target directory of the generated header file. The default is
- the current directory.
-
-`-H'
-`--help'
- Displays a list of command line options and then exits.
-
-`-m CHARACTERS'
-`--maxlength CHARACTERS'
- Instructs `windmc' to generate a warning if the length of any
- message exceeds the number specified.
-
-`-n'
-`--nullterminate'
- Terminate message text in `bin' files by zero. By default they are
- terminated by CR/LF.
-
-`-o'
-`--hresult_use'
- Not yet implemented. Instructs `windmc' to generate an OLE2 header
- file, using HRESULT definitions. Status codes are used if the flag
- is not specified.
-
-`-O CODEPAGE'
-`--codepage_out CODEPAGE'
- Sets the default codepage to be used to output text files. The
- default is ocdepage 1252.
-
-`-r PATH'
-`--rcdir PATH'
- The target directory for the generated `rc' script and the
- generated `bin' files that the resource compiler script includes.
- The default is the current directory.
-
-`-u'
-`--unicode_in'
- Specifies that the input file is UTF16.
-
-`-U'
-`--unicode_out'
- Specifies that messages in the output `bin' file should be in UTF16
- format. This is the default behaviour.
-
-`-v'
-
-`--verbose'
- Enable verbose mode.
-
-`-V'
-
-`--version'
- Prints the version number for `windmc'.
-
-`-x PATH'
-`--xdgb PATH'
- The path of the `dbg' C include file that maps message id's to the
- symbolic name. No such file is generated without specifying the
- switch.
-
-
-File: binutils.info, Node: windres, Next: windmc, Prev: nlmconv, Up: Top
-
-13 windres
-**********
-
-`windres' may be used to manipulate Windows resources.
-
- _Warning:_ `windres' is not always built as part of the binary
- utilities, since it is only useful for Windows targets.
-
- windres [options] [input-file] [output-file]
-
- `windres' reads resources from an input file and copies them into an
-output file. Either file may be in one of three formats:
-
-`rc'
- A text format read by the Resource Compiler.
-
-`res'
- A binary format generated by the Resource Compiler.
-
-`coff'
- A COFF object or executable.
-
- The exact description of these different formats is available in
-documentation from Microsoft.
-
- When `windres' converts from the `rc' format to the `res' format, it
-is acting like the Windows Resource Compiler. When `windres' converts
-from the `res' format to the `coff' format, it is acting like the
-Windows `CVTRES' program.
-
- When `windres' generates an `rc' file, the output is similar but not
-identical to the format expected for the input. When an input `rc'
-file refers to an external filename, an output `rc' file will instead
-include the file contents.
-
- If the input or output format is not specified, `windres' will guess
-based on the file name, or, for the input file, the file contents. A
-file with an extension of `.rc' will be treated as an `rc' file, a file
-with an extension of `.res' will be treated as a `res' file, and a file
-with an extension of `.o' or `.exe' will be treated as a `coff' file.
-
- If no output file is specified, `windres' will print the resources
-in `rc' format to standard output.
-
- The normal use is for you to write an `rc' file, use `windres' to
-convert it to a COFF object file, and then link the COFF file into your
-application. This will make the resources described in the `rc' file
-available to Windows.
-
-`-i FILENAME'
-`--input FILENAME'
- The name of the input file. If this option is not used, then
- `windres' will use the first non-option argument as the input file
- name. If there are no non-option arguments, then `windres' will
- read from standard input. `windres' can not read a COFF file from
- standard input.
-
-`-o FILENAME'
-`--output FILENAME'
- The name of the output file. If this option is not used, then
- `windres' will use the first non-option argument, after any used
- for the input file name, as the output file name. If there is no
- non-option argument, then `windres' will write to standard output.
- `windres' can not write a COFF file to standard output. Note, for
- compatibility with `rc' the option `-fo' is also accepted, but its
- use is not recommended.
-
-`-J FORMAT'
-`--input-format FORMAT'
- The input format to read. FORMAT may be `res', `rc', or `coff'.
- If no input format is specified, `windres' will guess, as
- described above.
-
-`-O FORMAT'
-`--output-format FORMAT'
- The output format to generate. FORMAT may be `res', `rc', or
- `coff'. If no output format is specified, `windres' will guess,
- as described above.
-
-`-F TARGET'
-`--target TARGET'
- Specify the BFD format to use for a COFF file as input or output.
- This is a BFD target name; you can use the `--help' option to see
- a list of supported targets. Normally `windres' will use the
- default format, which is the first one listed by the `--help'
- option. *note Target Selection::.
-
-`--preprocessor PROGRAM'
- When `windres' reads an `rc' file, it runs it through the C
- preprocessor first. This option may be used to specify the
- preprocessor to use, including any leading arguments. The default
- preprocessor argument is `gcc -E -xc-header -DRC_INVOKED'.
-
-`-I DIRECTORY'
-`--include-dir DIRECTORY'
- Specify an include directory to use when reading an `rc' file.
- `windres' will pass this to the preprocessor as an `-I' option.
- `windres' will also search this directory when looking for files
- named in the `rc' file. If the argument passed to this command
- matches any of the supported FORMATS (as described in the `-J'
- option), it will issue a deprecation warning, and behave just like
- the `-J' option. New programs should not use this behaviour. If a
- directory happens to match a FORMAT, simple prefix it with `./' to
- disable the backward compatibility.
-
-`-D TARGET'
-`--define SYM[=VAL]'
- Specify a `-D' option to pass to the preprocessor when reading an
- `rc' file.
-
-`-U TARGET'
-`--undefine SYM'
- Specify a `-U' option to pass to the preprocessor when reading an
- `rc' file.
-
-`-r'
- Ignored for compatibility with rc.
-
-`-v'
- Enable verbose mode. This tells you what the preprocessor is if
- you didn't specify one.
-
-`-c VAL'
-
-`--codepage VAL'
- Specify the default codepage to use when reading an `rc' file.
- VAL should be a hexadecimal prefixed by `0x' or decimal codepage
- code. The valid range is from zero up to 0xffff, but the validity
- of the codepage is host and configuration dependent.
-
-`-l VAL'
-
-`--language VAL'
- Specify the default language to use when reading an `rc' file.
- VAL should be a hexadecimal language code. The low eight bits are
- the language, and the high eight bits are the sublanguage.
-
-`--use-temp-file'
- Use a temporary file to instead of using popen to read the output
- of the preprocessor. Use this option if the popen implementation
- is buggy on the host (eg., certain non-English language versions
- of Windows 95 and Windows 98 are known to have buggy popen where
- the output will instead go the console).
-
-`--no-use-temp-file'
- Use popen, not a temporary file, to read the output of the
- preprocessor. This is the default behaviour.
-
-`-h'
-
-`--help'
- Prints a usage summary.
-
-`-V'
-
-`--version'
- Prints the version number for `windres'.
-
-`--yydebug'
- If `windres' is compiled with `YYDEBUG' defined as `1', this will
- turn on parser debugging.
-
-
-File: binutils.info, Node: dlltool, Next: Common Options, Prev: windmc, Up: Top
-
-14 dlltool
-**********
-
-`dlltool' is used to create the files needed to create dynamic link
-libraries (DLLs) on systems which understand PE format image files such
-as Windows. A DLL contains an export table which contains information
-that the runtime loader needs to resolve references from a referencing
-program.
-
- The export table is generated by this program by reading in a `.def'
-file or scanning the `.a' and `.o' files which will be in the DLL. A
-`.o' file can contain information in special `.drectve' sections with
-export information.
-
- _Note:_ `dlltool' is not always built as part of the binary
- utilities, since it is only useful for those targets which support
- DLLs.
-
- dlltool [`-d'|`--input-def' DEF-FILE-NAME]
- [`-b'|`--base-file' BASE-FILE-NAME]
- [`-e'|`--output-exp' EXPORTS-FILE-NAME]
- [`-z'|`--output-def' DEF-FILE-NAME]
- [`-l'|`--output-lib' LIBRARY-FILE-NAME]
- [`-y'|`--output-delaylib' LIBRARY-FILE-NAME]
- [`--export-all-symbols'] [`--no-export-all-symbols']
- [`--exclude-symbols' LIST]
- [`--no-default-excludes']
- [`-S'|`--as' PATH-TO-ASSEMBLER] [`-f'|`--as-flags' OPTIONS]
- [`-D'|`--dllname' NAME] [`-m'|`--machine' MACHINE]
- [`-a'|`--add-indirect']
- [`-U'|`--add-underscore'] [`--add-stdcall-underscore']
- [`-k'|`--kill-at'] [`-A'|`--add-stdcall-alias']
- [`-p'|`--ext-prefix-alias' PREFIX]
- [`-x'|`--no-idata4'] [`-c'|`--no-idata5']
- [`--use-nul-prefixed-import-tables']
- [`-I'|`--identify' LIBRARY-FILE-NAME] [`--identify-strict']
- [`-i'|`--interwork']
- [`-n'|`--nodelete'] [`-t'|`--temp-prefix' PREFIX]
- [`-v'|`--verbose']
- [`-h'|`--help'] [`-V'|`--version']
- [`--no-leading-underscore'] [`--leading-underscore']
- [object-file ...]
-
- `dlltool' reads its inputs, which can come from the `-d' and `-b'
-options as well as object files specified on the command line. It then
-processes these inputs and if the `-e' option has been specified it
-creates a exports file. If the `-l' option has been specified it
-creates a library file and if the `-z' option has been specified it
-creates a def file. Any or all of the `-e', `-l' and `-z' options can
-be present in one invocation of dlltool.
-
- When creating a DLL, along with the source for the DLL, it is
-necessary to have three other files. `dlltool' can help with the
-creation of these files.
-
- The first file is a `.def' file which specifies which functions are
-exported from the DLL, which functions the DLL imports, and so on. This
-is a text file and can be created by hand, or `dlltool' can be used to
-create it using the `-z' option. In this case `dlltool' will scan the
-object files specified on its command line looking for those functions
-which have been specially marked as being exported and put entries for
-them in the `.def' file it creates.
-
- In order to mark a function as being exported from a DLL, it needs to
-have an `-export:<name_of_function>' entry in the `.drectve' section of
-the object file. This can be done in C by using the asm() operator:
-
- asm (".section .drectve");
- asm (".ascii \"-export:my_func\"");
-
- int my_func (void) { ... }
-
- The second file needed for DLL creation is an exports file. This
-file is linked with the object files that make up the body of the DLL
-and it handles the interface between the DLL and the outside world.
-This is a binary file and it can be created by giving the `-e' option to
-`dlltool' when it is creating or reading in a `.def' file.
-
- The third file needed for DLL creation is the library file that
-programs will link with in order to access the functions in the DLL (an
-`import library'). This file can be created by giving the `-l' option
-to dlltool when it is creating or reading in a `.def' file.
-
- If the `-y' option is specified, dlltool generates a delay-import
-library that can be used instead of the normal import library to allow
-a program to link to the dll only as soon as an imported function is
-called for the first time. The resulting executable will need to be
-linked to the static delayimp library containing __delayLoadHelper2(),
-which in turn will import LoadLibraryA and GetProcAddress from kernel32.
-
- `dlltool' builds the library file by hand, but it builds the exports
-file by creating temporary files containing assembler statements and
-then assembling these. The `-S' command line option can be used to
-specify the path to the assembler that dlltool will use, and the `-f'
-option can be used to pass specific flags to that assembler. The `-n'
-can be used to prevent dlltool from deleting these temporary assembler
-files when it is done, and if `-n' is specified twice then this will
-prevent dlltool from deleting the temporary object files it used to
-build the library.
-
- Here is an example of creating a DLL from a source file `dll.c' and
-also creating a program (from an object file called `program.o') that
-uses that DLL:
-
- gcc -c dll.c
- dlltool -e exports.o -l dll.lib dll.o
- gcc dll.o exports.o -o dll.dll
- gcc program.o dll.lib -o program
-
- `dlltool' may also be used to query an existing import library to
-determine the name of the DLL to which it is associated. See the
-description of the `-I' or `--identify' option.
-
- The command line options have the following meanings:
-
-`-d FILENAME'
-`--input-def FILENAME'
- Specifies the name of a `.def' file to be read in and processed.
-
-`-b FILENAME'
-`--base-file FILENAME'
- Specifies the name of a base file to be read in and processed. The
- contents of this file will be added to the relocation section in
- the exports file generated by dlltool.
-
-`-e FILENAME'
-`--output-exp FILENAME'
- Specifies the name of the export file to be created by dlltool.
-
-`-z FILENAME'
-`--output-def FILENAME'
- Specifies the name of the `.def' file to be created by dlltool.
-
-`-l FILENAME'
-`--output-lib FILENAME'
- Specifies the name of the library file to be created by dlltool.
-
-`-y FILENAME'
-`--output-delaylib FILENAME'
- Specifies the name of the delay-import library file to be created
- by dlltool.
-
-`--export-all-symbols'
- Treat all global and weak defined symbols found in the input object
- files as symbols to be exported. There is a small list of symbols
- which are not exported by default; see the `--no-default-excludes'
- option. You may add to the list of symbols to not export by using
- the `--exclude-symbols' option.
-
-`--no-export-all-symbols'
- Only export symbols explicitly listed in an input `.def' file or in
- `.drectve' sections in the input object files. This is the default
- behaviour. The `.drectve' sections are created by `dllexport'
- attributes in the source code.
-
-`--exclude-symbols LIST'
- Do not export the symbols in LIST. This is a list of symbol names
- separated by comma or colon characters. The symbol names should
- not contain a leading underscore. This is only meaningful when
- `--export-all-symbols' is used.
-
-`--no-default-excludes'
- When `--export-all-symbols' is used, it will by default avoid
- exporting certain special symbols. The current list of symbols to
- avoid exporting is `DllMain@12', `DllEntryPoint@0', `impure_ptr'.
- You may use the `--no-default-excludes' option to go ahead and
- export these special symbols. This is only meaningful when
- `--export-all-symbols' is used.
-
-`-S PATH'
-`--as PATH'
- Specifies the path, including the filename, of the assembler to be
- used to create the exports file.
-
-`-f OPTIONS'
-`--as-flags OPTIONS'
- Specifies any specific command line options to be passed to the
- assembler when building the exports file. This option will work
- even if the `-S' option is not used. This option only takes one
- argument, and if it occurs more than once on the command line,
- then later occurrences will override earlier occurrences. So if
- it is necessary to pass multiple options to the assembler they
- should be enclosed in double quotes.
-
-`-D NAME'
-`--dll-name NAME'
- Specifies the name to be stored in the `.def' file as the name of
- the DLL when the `-e' option is used. If this option is not
- present, then the filename given to the `-e' option will be used
- as the name of the DLL.
-
-`-m MACHINE'
-`-machine MACHINE'
- Specifies the type of machine for which the library file should be
- built. `dlltool' has a built in default type, depending upon how
- it was created, but this option can be used to override that.
- This is normally only useful when creating DLLs for an ARM
- processor, when the contents of the DLL are actually encode using
- Thumb instructions.
-
-`-a'
-`--add-indirect'
- Specifies that when `dlltool' is creating the exports file it
- should add a section which allows the exported functions to be
- referenced without using the import library. Whatever the hell
- that means!
-
-`-U'
-`--add-underscore'
- Specifies that when `dlltool' is creating the exports file it
- should prepend an underscore to the names of _all_ exported
- symbols.
-
-`--no-leading-underscore'
-
-`--leading-underscore'
- Specifies whether standard symbol should be forced to be prefixed,
- or not.
-
-`--add-stdcall-underscore'
- Specifies that when `dlltool' is creating the exports file it
- should prepend an underscore to the names of exported _stdcall_
- functions. Variable names and non-stdcall function names are not
- modified. This option is useful when creating GNU-compatible
- import libs for third party DLLs that were built with MS-Windows
- tools.
-
-`-k'
-`--kill-at'
- Specifies that when `dlltool' is creating the exports file it
- should not append the string `@ <number>'. These numbers are
- called ordinal numbers and they represent another way of accessing
- the function in a DLL, other than by name.
-
-`-A'
-`--add-stdcall-alias'
- Specifies that when `dlltool' is creating the exports file it
- should add aliases for stdcall symbols without `@ <number>' in
- addition to the symbols with `@ <number>'.
-
-`-p'
-`--ext-prefix-alias PREFIX'
- Causes `dlltool' to create external aliases for all DLL imports
- with the specified prefix. The aliases are created for both
- external and import symbols with no leading underscore.
-
-`-x'
-`--no-idata4'
- Specifies that when `dlltool' is creating the exports and library
- files it should omit the `.idata4' section. This is for
- compatibility with certain operating systems.
-
-`--use-nul-prefixed-import-tables'
- Specifies that when `dlltool' is creating the exports and library
- files it should prefix the `.idata4' and `.idata5' by zero an
- element. This emulates old gnu import library generation of
- `dlltool'. By default this option is turned off.
-
-`-c'
-`--no-idata5'
- Specifies that when `dlltool' is creating the exports and library
- files it should omit the `.idata5' section. This is for
- compatibility with certain operating systems.
-
-`-I FILENAME'
-`--identify FILENAME'
- Specifies that `dlltool' should inspect the import library
- indicated by FILENAME and report, on `stdout', the name(s) of the
- associated DLL(s). This can be performed in addition to any other
- operations indicated by the other options and arguments.
- `dlltool' fails if the import library does not exist or is not
- actually an import library. See also `--identify-strict'.
-
-`--identify-strict'
- Modifies the behavior of the `--identify' option, such that an
- error is reported if FILENAME is associated with more than one DLL.
-
-`-i'
-`--interwork'
- Specifies that `dlltool' should mark the objects in the library
- file and exports file that it produces as supporting interworking
- between ARM and Thumb code.
-
-`-n'
-`--nodelete'
- Makes `dlltool' preserve the temporary assembler files it used to
- create the exports file. If this option is repeated then dlltool
- will also preserve the temporary object files it uses to create
- the library file.
-
-`-t PREFIX'
-`--temp-prefix PREFIX'
- Makes `dlltool' use PREFIX when constructing the names of
- temporary assembler and object files. By default, the temp file
- prefix is generated from the pid.
-
-`-v'
-`--verbose'
- Make dlltool describe what it is doing.
-
-`-h'
-`--help'
- Displays a list of command line options and then exits.
-
-`-V'
-`--version'
- Displays dlltool's version number and then exits.
-
-
-* Menu:
-
-* def file format:: The format of the dlltool `.def' file
-
-
-File: binutils.info, Node: def file format, Up: dlltool
-
-14.1 The format of the `dlltool' `.def' file
-============================================
-
-A `.def' file contains any number of the following commands:
-
-`NAME' NAME `[ ,' BASE `]'
- The result is going to be named NAME`.exe'.
-
-`LIBRARY' NAME `[ ,' BASE `]'
- The result is going to be named NAME`.dll'.
-
-`EXPORTS ( ( (' NAME1 `[ = ' NAME2 `] ) | ( ' NAME1 `=' MODULE-NAME `.' EXTERNAL-NAME `) ) [ == ' ITS_NAME `]'
-
-`[' INTEGER `] [ NONAME ] [ CONSTANT ] [ DATA ] [ PRIVATE ] ) *'
- Declares NAME1 as an exported symbol from the DLL, with optional
- ordinal number INTEGER, or declares NAME1 as an alias (forward) of
- the function EXTERNAL-NAME in the DLL. If ITS_NAME is specified,
- this name is used as string in export table. MODULE-NAME.
-
-`IMPORTS ( (' INTERNAL-NAME `=' MODULE-NAME `.' INTEGER `) | [' INTERNAL-NAME `= ]' MODULE-NAME `.' EXTERNAL-NAME `) [ == ) ITS_NAME `]' *'
- Declares that EXTERNAL-NAME or the exported function whose ordinal
- number is INTEGER is to be imported from the file MODULE-NAME. If
- INTERNAL-NAME is specified then this is the name that the imported
- function will be referred to in the body of the DLL. If ITS_NAME
- is specified, this name is used as string in import table.
-
-`DESCRIPTION' STRING
- Puts STRING into the output `.exp' file in the `.rdata' section.
-
-`STACKSIZE' NUMBER-RESERVE `[, ' NUMBER-COMMIT `]'
-
-`HEAPSIZE' NUMBER-RESERVE `[, ' NUMBER-COMMIT `]'
- Generates `--stack' or `--heap' NUMBER-RESERVE,NUMBER-COMMIT in
- the output `.drectve' section. The linker will see this and act
- upon it.
-
-`CODE' ATTR `+'
-
-`DATA' ATTR `+'
-
-`SECTIONS (' SECTION-NAME ATTR` + ) *'
- Generates `--attr' SECTION-NAME ATTR in the output `.drectve'
- section, where ATTR is one of `READ', `WRITE', `EXECUTE' or
- `SHARED'. The linker will see this and act upon it.
-
-
-
-File: binutils.info, Node: readelf, Next: size, Prev: ranlib, Up: Top
-
-15 readelf
-**********
-
- readelf [`-a'|`--all']
- [`-h'|`--file-header']
- [`-l'|`--program-headers'|`--segments']
- [`-S'|`--section-headers'|`--sections']
- [`-g'|`--section-groups']
- [`-t'|`--section-details']
- [`-e'|`--headers']
- [`-s'|`--syms'|`--symbols']
- [`--dyn-syms']
- [`-n'|`--notes']
- [`-r'|`--relocs']
- [`-u'|`--unwind']
- [`-d'|`--dynamic']
- [`-V'|`--version-info']
- [`-A'|`--arch-specific']
- [`-D'|`--use-dynamic']
- [`-x' <number or name>|`--hex-dump='<number or name>]
- [`-p' <number or name>|`--string-dump='<number or name>]
- [`-R' <number or name>|`--relocated-dump='<number or name>]
- [`-c'|`--archive-index']
- [`-w[lLiaprmfFsoRt]'|
- `--debug-dump'[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges]]
- [`-I'|`--histogram']
- [`-v'|`--version']
- [`-W'|`--wide']
- [`-H'|`--help']
- ELFFILE...
-
- `readelf' displays information about one or more ELF format object
-files. The options control what particular information to display.
-
- ELFFILE... are the object files to be examined. 32-bit and 64-bit
-ELF files are supported, as are archives containing ELF files.
-
- This program performs a similar function to `objdump' but it goes
-into more detail and it exists independently of the BFD library, so if
-there is a bug in BFD then readelf will not be affected.
-
- The long and short forms of options, shown here as alternatives, are
-equivalent. At least one option besides `-v' or `-H' must be given.
-
-`-a'
-`--all'
- Equivalent to specifying `--file-header', `--program-headers',
- `--sections', `--symbols', `--relocs', `--dynamic', `--notes' and
- `--version-info'.
-
-`-h'
-`--file-header'
- Displays the information contained in the ELF header at the start
- of the file.
-
-`-l'
-`--program-headers'
-`--segments'
- Displays the information contained in the file's segment headers,
- if it has any.
-
-`-S'
-`--sections'
-`--section-headers'
- Displays the information contained in the file's section headers,
- if it has any.
-
-`-g'
-`--section-groups'
- Displays the information contained in the file's section groups,
- if it has any.
-
-`-t'
-`--section-details'
- Displays the detailed section information. Implies `-S'.
-
-`-s'
-`--symbols'
-`--syms'
- Displays the entries in symbol table section of the file, if it
- has one.
-
-`--dyn-syms'
- Displays the entries in dynamic symbol table section of the file,
- if it has one.
-
-`-e'
-`--headers'
- Display all the headers in the file. Equivalent to `-h -l -S'.
-
-`-n'
-`--notes'
- Displays the contents of the NOTE segments and/or sections, if any.
-
-`-r'
-`--relocs'
- Displays the contents of the file's relocation section, if it has
- one.
-
-`-u'
-`--unwind'
- Displays the contents of the file's unwind section, if it has one.
- Only the unwind sections for IA64 ELF files, as well as ARM unwind
- tables (`.ARM.exidx' / `.ARM.extab') are currently supported.
-
-`-d'
-`--dynamic'
- Displays the contents of the file's dynamic section, if it has one.
-
-`-V'
-`--version-info'
- Displays the contents of the version sections in the file, it they
- exist.
-
-`-A'
-`--arch-specific'
- Displays architecture-specific information in the file, if there
- is any.
-
-`-D'
-`--use-dynamic'
- When displaying symbols, this option makes `readelf' use the
- symbol hash tables in the file's dynamic section, rather than the
- symbol table sections.
-
-`-x <number or name>'
-`--hex-dump=<number or name>'
- Displays the contents of the indicated section as a hexadecimal
- bytes. A number identifies a particular section by index in the
- section table; any other string identifies all sections with that
- name in the object file.
-
-`-R <number or name>'
-`--relocated-dump=<number or name>'
- Displays the contents of the indicated section as a hexadecimal
- bytes. A number identifies a particular section by index in the
- section table; any other string identifies all sections with that
- name in the object file. The contents of the section will be
- relocated before they are displayed.
-
-`-p <number or name>'
-`--string-dump=<number or name>'
- Displays the contents of the indicated section as printable
- strings. A number identifies a particular section by index in the
- section table; any other string identifies all sections with that
- name in the object file.
-
-`-c'
-`--archive-index'
- Displays the file symbol index infomation contained in the header
- part of binary archives. Performs the same function as the `t'
- command to `ar', but without using the BFD library. *Note ar::.
-
-`-w[lLiaprmfFsoRt]'
-`--debug-dump[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges]'
- Displays the contents of the debug sections in the file, if any are
- present. If one of the optional letters or words follows the
- switch then only data found in those specific sections will be
- dumped.
-
- Note that there is no single letter option to display the content
- of trace sections.
-
- Note: the `=decodedline' option will display the interpreted
- contents of a .debug_line section whereas the `=rawline' option
- dumps the contents in a raw format.
-
- Note: the `=frames-interp' option will display the interpreted
- contents of a .debug_frame section whereas the `=frames' option
- dumps the contents in a raw format.
-
-`-I'
-`--histogram'
- Display a histogram of bucket list lengths when displaying the
- contents of the symbol tables.
-
-`-v'
-`--version'
- Display the version number of readelf.
-
-`-W'
-`--wide'
- Don't break output lines to fit into 80 columns. By default
- `readelf' breaks section header and segment listing lines for
- 64-bit ELF files, so that they fit into 80 columns. This option
- causes `readelf' to print each section header resp. each segment
- one a single line, which is far more readable on terminals wider
- than 80 columns.
-
-`-H'
-`--help'
- Display the command line options understood by `readelf'.
-
-
-
-File: binutils.info, Node: elfedit, Next: c++filt, Prev: strip, Up: Top
-
-16 elfedit
-**********
-
- elfedit [`--input-mach='MACHINE]
- [`--input-type='TYPE]
- [`--input-osabi='OSBI]
- `--output-mach='MACHINE
- `--output-type='TYPE
- `--output-osabi='OSBI
- [`-v'|`--version']
- [`-h'|`--help']
- ELFFILE...
-
- `elfedit' updates the ELF header of ELF files which have the
-matching ELF machine and file types. The options control how and which
-fields in the ELF header should be updated.
-
- ELFFILE... are the ELF files to be updated. 32-bit and 64-bit ELF
-files are supported, as are archives containing ELF files.
-
- The long and short forms of options, shown here as alternatives, are
-equivalent. At least one of the `--output-mach', `--output-type' and
-`--output-osabi' options must be given.
-
-`--input-mach=MACHINE'
- Set the matching input ELF machine type to MACHINE. If
- `--input-mach' isn't specified, it will match any ELF machine
- types.
-
- The supported ELF machine types are, L1OM and X86-64.
-
-`--output-mach=MACHINE'
- Change the ELF machine type in the ELF header to MACHINE. The
- supported ELF machine types are the same as `--input-mach'.
-
-`--input-type=TYPE'
- Set the matching input ELF file type to TYPE. If `--input-type'
- isn't specified, it will match any ELF file types.
-
- The supported ELF file types are, REL, EXEC and DYN.
-
-`--output-type=TYPE'
- Change the ELF file type in the ELF header to TYPE. The supported
- ELF types are the same as `--input-type'.
-
-`--input-osabi=OSABI'
- Set the matching input ELF file OSABI to OSBI. If `--input-osabi'
- isn't specified, it will match any ELF OSABIs.
-
- The supported ELF OSABIs are, NONE, HPUX, NETBSD, LINUX, HURD,
- SOLARIS, AIX, IRIX, FREEBSD, TRU64, MODESTO, OPENBSD, OPENVMS,
- NSK, AROS and FENIXOS.
-
-`--output-osabi=OSABI'
- Change the ELF OSABI in the ELF header to TYPE. The supported ELF
- OSABI are the same as `--input-osabi'.
-
-`-v'
-`--version'
- Display the version number of `elfedit'.
-
-`-h'
-`--help'
- Display the command line options understood by `elfedit'.
-
-
-
-File: binutils.info, Node: Common Options, Next: Selecting the Target System, Prev: dlltool, Up: Top
-
-17 Common Options
-*****************
-
-The following command-line options are supported by all of the programs
-described in this manual.
-
-`@FILE'
- Read command-line options from FILE. The options read are
- inserted in place of the original @FILE option. If FILE does not
- exist, or cannot be read, then the option will be treated
- literally, and not removed.
-
- Options in FILE are separated by whitespace. A whitespace
- character may be included in an option by surrounding the entire
- option in either single or double quotes. Any character
- (including a backslash) may be included by prefixing the character
- to be included with a backslash. The FILE may itself contain
- additional @FILE options; any such options will be processed
- recursively.
-
-`--help'
- Display the command-line options supported by the program.
-
-`--version'
- Display the version number of the program.
-
-
-
-File: binutils.info, Node: Selecting the Target System, Next: Reporting Bugs, Prev: Common Options, Up: Top
-
-18 Selecting the Target System
-******************************
-
-You can specify two aspects of the target system to the GNU binary file
-utilities, each in several ways:
-
- * the target
-
- * the architecture
-
- In the following summaries, the lists of ways to specify values are
-in order of decreasing precedence. The ways listed first override those
-listed later.
-
- The commands to list valid values only list the values for which the
-programs you are running were configured. If they were configured with
-`--enable-targets=all', the commands list most of the available values,
-but a few are left out; not all targets can be configured in at once
-because some of them can only be configured "native" (on hosts with the
-same type as the target system).
-
-* Menu:
-
-* Target Selection::
-* Architecture Selection::
-
-
-File: binutils.info, Node: Target Selection, Next: Architecture Selection, Up: Selecting the Target System
-
-18.1 Target Selection
-=====================
-
-A "target" is an object file format. A given target may be supported
-for multiple architectures (*note Architecture Selection::). A target
-selection may also have variations for different operating systems or
-architectures.
-
- The command to list valid target values is `objdump -i' (the first
-column of output contains the relevant information).
-
- Some sample values are: `a.out-hp300bsd', `ecoff-littlemips',
-`a.out-sunos-big'.
-
- You can also specify a target using a configuration triplet. This is
-the same sort of name that is passed to `configure' to specify a
-target. When you use a configuration triplet as an argument, it must be
-fully canonicalized. You can see the canonical version of a triplet by
-running the shell script `config.sub' which is included with the
-sources.
-
- Some sample configuration triplets are: `m68k-hp-bsd',
-`mips-dec-ultrix', `sparc-sun-sunos'.
-
-`objdump' Target
-----------------
-
-Ways to specify:
-
- 1. command line option: `-b' or `--target'
-
- 2. environment variable `GNUTARGET'
-
- 3. deduced from the input file
-
-`objcopy' and `strip' Input Target
-----------------------------------
-
-Ways to specify:
-
- 1. command line options: `-I' or `--input-target', or `-F' or
- `--target'
-
- 2. environment variable `GNUTARGET'
-
- 3. deduced from the input file
-
-`objcopy' and `strip' Output Target
------------------------------------
-
-Ways to specify:
-
- 1. command line options: `-O' or `--output-target', or `-F' or
- `--target'
-
- 2. the input target (see "`objcopy' and `strip' Input Target" above)
-
- 3. environment variable `GNUTARGET'
-
- 4. deduced from the input file
-
-`nm', `size', and `strings' Target
-----------------------------------
-
-Ways to specify:
-
- 1. command line option: `--target'
-
- 2. environment variable `GNUTARGET'
-
- 3. deduced from the input file
-
-
-File: binutils.info, Node: Architecture Selection, Prev: Target Selection, Up: Selecting the Target System
-
-18.2 Architecture Selection
-===========================
-
-An "architecture" is a type of CPU on which an object file is to run.
-Its name may contain a colon, separating the name of the processor
-family from the name of the particular CPU.
-
- The command to list valid architecture values is `objdump -i' (the
-second column contains the relevant information).
-
- Sample values: `m68k:68020', `mips:3000', `sparc'.
-
-`objdump' Architecture
-----------------------
-
-Ways to specify:
-
- 1. command line option: `-m' or `--architecture'
-
- 2. deduced from the input file
-
-`objcopy', `nm', `size', `strings' Architecture
------------------------------------------------
-
-Ways to specify:
-
- 1. deduced from the input file
-
-
-File: binutils.info, Node: Reporting Bugs, Next: GNU Free Documentation License, Prev: Selecting the Target System, Up: Top
-
-19 Reporting Bugs
-*****************
-
-Your bug reports play an essential role in making the binary utilities
-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 the binary
-utilities work better. Bug reports are your contribution to their
-maintenance.
-
- 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
-
-
-File: binutils.info, Node: Bug Criteria, Next: Bug Reporting, Up: Reporting Bugs
-
-19.1 Have You Found a Bug?
-==========================
-
-If you are not sure whether you have found a bug, here are some
-guidelines:
-
- * If a binary utility gets a fatal signal, for any input whatever,
- that is a bug. Reliable utilities never crash.
-
- * If a binary utility produces an error message for valid input,
- that is a bug.
-
- * If you are an experienced user of binary utilities, your
- suggestions for improvement are welcome in any case.
-
-
-File: binutils.info, Node: Bug Reporting, Prev: Bug Criteria, Up: Reporting Bugs
-
-19.2 How to Report Bugs
-=======================
-
-A number of companies and individuals offer support for GNU products.
-If you obtained the binary utilities 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 `etc/SERVICE' in the GNU Emacs distribution.
-
- In any event, we also recommend that you send bug reports for the
-binary utilities to `http://www.sourceware.org/bugzilla/'.
-
- The fundamental principle of reporting bugs usefully is this:
-*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 file 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 pathname is stored in memory; perhaps, if the pathname were
-different, the contents of that location would fool the utility 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?" This cannot help us fix a bug, so it is basically useless. We
-respond by asking for enough details to enable us to investigate. You
-might as well expedite matters by sending them to begin with.
-
- To enable us to fix the bug, you should include all these things:
-
- * The version of the utility. Each utility announces it if you
- start it with the `--version' argument.
-
- Without this, we will not know whether there is any point in
- looking for the bug in the current version of the binary utilities.
-
- * Any patches you may have applied to the source, including any
- patches made to the `BFD' library.
-
- * The type of machine you are using, and the operating system name
- and version number.
-
- * What compiler (and its version) was used to compile the
- utilities--e.g. "`gcc-2.7'".
-
- * The command arguments you gave the utility to 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.
-
- * A complete input file, or set of input files, that will reproduce
- the bug. If the utility is reading an object file or files, then
- it is generally most helpful to send the actual object files.
-
- If the source files were produced exclusively using GNU programs
- (e.g., `gcc', `gas', and/or the GNU `ld'), then it may be OK to
- send the source files rather than the object files. In this case,
- be sure to say exactly what version of `gcc', or whatever, was
- used to produce the object files. Also say how `gcc', or
- whatever, was configured.
-
- * 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 the utility 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 the utility is out of sync, 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.
-
- * If you wish to suggest changes to the source, send us context
- diffs, as generated by `diff' with the `-u', `-c', or `-p' option.
- Always send diffs from the old file to the new file. If you wish
- to discuss something in the `ld' 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.
-
- Here are some things that are not necessary:
-
- * 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 _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.
-
- * 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 programs as complicated as the binary utilities 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.
-
- * 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.
-
-
-File: binutils.info, Node: GNU Free Documentation License, Next: Binutils Index, Prev: Reporting Bugs, Up: Top
-
-Appendix A GNU Free Documentation License
-*****************************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: binutils.info, Node: Binutils Index, Prev: GNU Free Documentation License, Up: Top
-
-Binutils Index
-**************
-
-
-* Menu:
-
-* .stab: objdump. (line 373)
-* Add prefix to absolute paths: objdump. (line 341)
-* addr2line: addr2line. (line 6)
-* address to file name and line number: addr2line. (line 6)
-* all header information, object file: objdump. (line 492)
-* ar: ar. (line 6)
-* ar compatibility: ar. (line 50)
-* architecture: objdump. (line 195)
-* architectures available: objdump. (line 180)
-* archive contents: ranlib. (line 6)
-* Archive file symbol index information: readelf. (line 152)
-* archive headers: objdump. (line 65)
-* archives: ar. (line 6)
-* base files: dlltool. (line 124)
-* bug criteria: Bug Criteria. (line 6)
-* bug reports: Bug Reporting. (line 6)
-* bugs: Reporting Bugs. (line 6)
-* bugs, reporting: Bug Reporting. (line 6)
-* c++filt: c++filt. (line 6)
-* changing object addresses: objcopy. (line 308)
-* changing section address: objcopy. (line 318)
-* changing section LMA: objcopy. (line 326)
-* changing section VMA: objcopy. (line 339)
-* changing start address: objcopy. (line 303)
-* collections of files: ar. (line 6)
-* compatibility, ar: ar. (line 50)
-* contents of archive: ar cmdline. (line 94)
-* crash: Bug Criteria. (line 9)
-* creating archives: ar cmdline. (line 135)
-* creating thin archive: ar cmdline. (line 196)
-* cxxfilt: c++filt. (line 14)
-* dates in archive: ar cmdline. (line 170)
-* debug symbols: objdump. (line 373)
-* debugging symbols: nm. (line 141)
-* deleting from archive: ar cmdline. (line 26)
-* demangling C++ symbols: c++filt. (line 6)
-* demangling in nm: nm. (line 149)
-* demangling in objdump <1>: objdump. (line 93)
-* demangling in objdump: addr2line. (line 64)
-* deterministic archives: ar cmdline. (line 141)
-* disassembling object code: objdump. (line 115)
-* disassembly architecture: objdump. (line 195)
-* disassembly endianness: objdump. (line 135)
-* disassembly, with source: objdump. (line 337)
-* discarding symbols: strip. (line 6)
-* DLL: dlltool. (line 6)
-* dlltool: dlltool. (line 6)
-* DWARF: objdump. (line 363)
-* dynamic relocation entries, in object file: objdump. (line 325)
-* dynamic symbol table entries, printing: objdump. (line 476)
-* dynamic symbols: nm. (line 161)
-* ELF dynamic section information: readelf. (line 110)
-* ELF dynamic symbol table information: readelf. (line 86)
-* ELF file header information: readelf. (line 55)
-* ELF file information: readelf. (line 6)
-* ELF notes: readelf. (line 95)
-* ELF object file format: objdump. (line 373)
-* ELF program header information: readelf. (line 61)
-* ELF reloc information: readelf. (line 99)
-* ELF section group information: readelf. (line 72)
-* ELF section information: readelf. (line 67)
-* ELF segment information: readelf. (line 61)
-* ELF symbol table information: readelf. (line 82)
-* ELF version sections informations: readelf. (line 114)
-* elfedit: elfedit. (line 6)
-* endianness: objdump. (line 135)
-* error on valid input: Bug Criteria. (line 12)
-* external symbols: nm. (line 173)
-* extract from archive: ar cmdline. (line 109)
-* fatal signal: Bug Criteria. (line 9)
-* file name: nm. (line 135)
-* header information, all: objdump. (line 492)
-* input .def file: dlltool. (line 120)
-* input file name: nm. (line 135)
-* Instruction width: objdump. (line 358)
-* libraries: ar. (line 25)
-* listings strings: strings. (line 6)
-* load plugin: nm. (line 176)
-* machine instructions: objdump. (line 115)
-* moving in archive: ar cmdline. (line 34)
-* MRI compatibility, ar: ar scripts. (line 8)
-* name duplication in archive: ar cmdline. (line 103)
-* name length: ar. (line 18)
-* nm: nm. (line 6)
-* nm compatibility: nm. (line 167)
-* nm format: nm. (line 167)
-* not writing archive index: ar cmdline. (line 189)
-* objdump: objdump. (line 6)
-* object code format <1>: strings. (line 67)
-* object code format <2>: nm. (line 244)
-* object code format <3>: objdump. (line 79)
-* object code format <4>: addr2line. (line 59)
-* object code format: size. (line 84)
-* object file header: objdump. (line 141)
-* object file information: objdump. (line 6)
-* object file offsets: objdump. (line 146)
-* object file sections: objdump. (line 332)
-* object formats available: objdump. (line 180)
-* operations on archive: ar cmdline. (line 22)
-* printing from archive: ar cmdline. (line 46)
-* printing strings: strings. (line 6)
-* quick append to archive: ar cmdline. (line 54)
-* radix for section sizes: size. (line 66)
-* ranlib <1>: ranlib. (line 6)
-* ranlib: ar cmdline. (line 88)
-* readelf: readelf. (line 6)
-* relative placement in archive: ar cmdline. (line 123)
-* relocation entries, in object file: objdump. (line 319)
-* removing symbols: strip. (line 6)
-* repeated names in archive: ar cmdline. (line 103)
-* replacement in archive: ar cmdline. (line 70)
-* reporting bugs: Reporting Bugs. (line 6)
-* scripts, ar: ar scripts. (line 8)
-* section addresses in objdump: objdump. (line 71)
-* section headers: objdump. (line 162)
-* section information: objdump. (line 185)
-* section sizes: size. (line 6)
-* sections, full contents: objdump. (line 332)
-* size: size. (line 6)
-* size display format: size. (line 27)
-* size number format: size. (line 66)
-* sorting symbols: nm. (line 197)
-* source code context: objdump. (line 155)
-* source disassembly: objdump. (line 337)
-* source file name: nm. (line 135)
-* source filenames for object files: objdump. (line 189)
-* stab: objdump. (line 373)
-* start-address: objdump. (line 383)
-* stop-address: objdump. (line 387)
-* strings: strings. (line 6)
-* strings, printing: strings. (line 6)
-* strip: strip. (line 6)
-* Strip absolute paths: objdump. (line 344)
-* symbol index <1>: ar. (line 28)
-* symbol index: ranlib. (line 6)
-* symbol index, listing: nm. (line 214)
-* symbol line numbers: nm. (line 182)
-* symbol table entries, printing: objdump. (line 392)
-* symbols: nm. (line 6)
-* symbols, discarding: strip. (line 6)
-* thin archives: ar. (line 40)
-* undefined symbols: nm. (line 249)
-* Unix compatibility, ar: ar cmdline. (line 8)
-* unwind information: readelf. (line 104)
-* Update ELF header: elfedit. (line 6)
-* updating an archive: ar cmdline. (line 201)
-* version: Top. (line 6)
-* VMA in objdump: objdump. (line 71)
-* wide output, printing: objdump. (line 498)
-* writing archive index: ar cmdline. (line 183)
-
-
-
-Tag Table:
-Node: Top2090
-Node: ar3800
-Node: ar cmdline6605
-Node: ar scripts15929
-Node: nm21617
-Node: objcopy31091
-Node: objdump60699
-Node: ranlib81371
-Node: size82192
-Node: strings85197
-Node: strip87655
-Node: c++filt93606
-Ref: c++filt-Footnote-198453
-Node: addr2line98559
-Node: nlmconv102359
-Node: windmc104965
-Node: windres108614
-Node: dlltool114641
-Node: def file format127527
-Node: readelf129458
-Node: elfedit136038
-Node: Common Options138258
-Node: Selecting the Target System139298
-Node: Target Selection140230
-Node: Architecture Selection142212
-Node: Reporting Bugs143040
-Node: Bug Criteria143819
-Node: Bug Reporting144372
-Node: GNU Free Documentation License151242
-Node: Binutils Index176421
-
-End Tag Table
diff --git a/share/info/configure.info b/share/info/configure.info
deleted file mode 100644
index b2d8883..0000000
--- a/share/info/configure.info
+++ /dev/null
@@ -1,2773 +0,0 @@
-This is configure.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gdb/gdb-7.3.x/etc/configure.texi.
-
-INFO-DIR-SECTION GNU admin
-START-INFO-DIR-ENTRY
-* configure: (configure). The GNU configure and build system
-END-INFO-DIR-ENTRY
-
- This file documents the GNU configure and build system.
-
- Copyright (C) 1998 Cygnus Solutions.
-
- Permission is granted to make and distribute verbatim copies of this
-manual provided the copyright notice and this permission notice are
-preserved on all copies.
-
- Permission is granted to copy and distribute modified versions of
-this manual under the conditions for verbatim copying, provided that
-the entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
-
- Permission is granted to copy and distribute translations of this
-manual into another language, under the above conditions for modified
-versions, except that this permission notice may be stated in a
-translation approved by the Foundation.
-
-
-File: configure.info, Node: Top, Next: Introduction, Up: (dir)
-
-GNU configure and build system
-******************************
-
-The GNU configure and build system.
-
-* Menu:
-
-* Introduction:: Introduction.
-* Getting Started:: Getting Started.
-* Files:: Files.
-* Configuration Names:: Configuration Names.
-* Cross Compilation Tools:: Cross Compilation Tools.
-* Canadian Cross:: Canadian Cross.
-* Cygnus Configure:: Cygnus Configure.
-* Multilibs:: Multilibs.
-* FAQ:: Frequently Asked Questions.
-* Index:: Index.
-
-
-File: configure.info, Node: Introduction, Next: Getting Started, Prev: Top, Up: Top
-
-1 Introduction
-**************
-
-This document describes the GNU configure and build systems. It
-describes how autoconf, automake, libtool, and make fit together. It
-also includes a discussion of the older Cygnus configure system.
-
- This document does not describe in detail how to use each of the
-tools; see the respective manuals for that. Instead, it describes
-which files the developer must write, which files are machine generated
-and how they are generated, and where certain common problems should be
-addressed.
-
- This document draws on several sources, including the autoconf
-manual by David MacKenzie (*note autoconf overview: (autoconf)Top.),
-the automake manual by David MacKenzie and Tom Tromey (*note automake
-overview: (automake)Top.), the libtool manual by Gordon Matzigkeit
-(*note libtool overview: (libtool)Top.), and the Cygnus configure
-manual by K. Richard Pixley.
-
-* Menu:
-
-* Goals:: Goals.
-* Tools:: The tools.
-* History:: History.
-* Building:: Building.
-
-
-File: configure.info, Node: Goals, Next: Tools, Up: Introduction
-
-1.1 Goals
-=========
-
-The GNU configure and build system has two main goals.
-
- The first is to simplify the development of portable programs. The
-system permits the developer to concentrate on writing the program,
-simplifying many details of portability across Unix and even Windows
-systems, and permitting the developer to describe how to build the
-program using simple rules rather than complex Makefiles.
-
- The second is to simplify the building of programs distributed as
-source code. All programs are built using a simple, standardized, two
-step process. The program builder need not install any special tools in
-order to build the program.
-
-
-File: configure.info, Node: Tools, Next: History, Prev: Goals, Up: Introduction
-
-1.2 Tools
-=========
-
-The GNU configure and build system is comprised of several different
-tools. Program developers must build and install all of these tools.
-
- People who just want to build programs from distributed sources
-normally do not need any special tools beyond a Unix shell, a make
-program, and a C compiler.
-
-autoconf
- provides a general portability framework, based on testing the
- features of the host system at build time.
-
-automake
- a system for describing how to build a program, permitting the
- developer to write a simplified `Makefile'.
-
-libtool
- a standardized approach to building shared libraries.
-
-gettext
- provides a framework for translation of text messages into other
- languages; not really discussed in this document.
-
-m4
- autoconf requires the GNU version of m4; the standard Unix m4 does
- not suffice.
-
-perl
- automake requires perl.
-
-
-File: configure.info, Node: History, Next: Building, Prev: Tools, Up: Introduction
-
-1.3 History
-===========
-
-This is a very brief and probably inaccurate history.
-
- As the number of Unix variants increased during the 1980s, it became
-harder to write programs which could run on all variants. While it was
-often possible to use `#ifdef' to identify particular systems,
-developers frequently did not have access to every system, and the
-characteristics of some systems changed from version to version.
-
- By 1992, at least three different approaches had been developed:
- * The Metaconfig program, by Larry Wall, Harlan Stenn, and Raphael
- Manfredi.
-
- * The Cygnus configure script, by K. Richard Pixley, and the gcc
- configure script, by Richard Stallman. These use essentially the
- same approach, and the developers communicated regularly.
-
- * The autoconf program, by David MacKenzie.
-
- The Metaconfig program is still used for Perl and a few other
-programs. It is part of the Dist package. I do not know if it is
-being developed.
-
- In 1994, David MacKenzie and others modified autoconf to incorporate
-all the features of Cygnus configure. Since then, there has been a
-slow but steady conversion of GNU programs from Cygnus configure to
-autoconf. gcc has been converted, eliminating the gcc configure script.
-
- GNU autoconf was regularly maintained until late 1996. As of this
-writing in June, 1998, it has no public maintainer.
-
- Most programs are built using the make program, which requires the
-developer to write Makefiles describing how to build the programs.
-Since most programs are built in pretty much the same way, this led to a
-lot of duplication.
-
- The X Window system is built using the imake tool, which uses a
-database of rules to eliminate the duplication. However, building a
-tool which was developed using imake requires that the builder have
-imake installed, violating one of the goals of the GNU system.
-
- The new BSD make provides a standard library of Makefile fragments,
-which permits developers to write very simple Makefiles. However, this
-requires that the builder install the new BSD make program.
-
- In 1994, David MacKenzie wrote the first version of automake, which
-permitted writing a simple build description which was converted into a
-Makefile which could be used by the standard make program. In 1995, Tom
-Tromey completely rewrote automake in Perl, and he continues to enhance
-it.
-
- Various free packages built libraries, and by around 1995 several
-included support to build shared libraries on various platforms.
-However, there was no consistent approach. In early 1996, Gordon
-Matzigkeit began working on libtool, which provided a standardized
-approach to building shared libraries. This was integrated into
-automake from the start.
-
- The development of automake and libtool was driven by the GNITS
-project, a group of GNU maintainers who designed standardized tools to
-help meet the GNU coding standards.
-
-
-File: configure.info, Node: Building, Prev: History, Up: Introduction
-
-1.4 Building
-============
-
-Most readers of this document should already know how to build a tool by
-running `configure' and `make'. This section may serve as a quick
-introduction or reminder.
-
- Building a tool is normally as simple as running `configure'
-followed by `make'. You should normally run `configure' from an empty
-directory, using some path to refer to the `configure' script in the
-source directory. The directory in which you run `configure' is called
-the "object directory".
-
- In order to use a object directory which is different from the source
-directory, you must be using the GNU version of `make', which has the
-required `VPATH' support. Despite this restriction, using a different
-object directory is highly recommended:
- * It keeps the files generated during the build from cluttering up
- your sources.
-
- * It permits you to remove the built files by simply removing the
- entire build directory.
-
- * It permits you to build from the same sources with several sets of
- configure options simultaneously.
-
- If you don't have GNU `make', you will have to run `configure' in
-the source directory. All GNU packages should support this; in
-particular, GNU packages should not assume the presence of GNU `make'.
-
- After running `configure', you can build the tools by running `make'.
-
- To install the tools, run `make install'. Installing the tools will
-copy the programs and any required support files to the "installation
-directory". The location of the installation directory is controlled
-by `configure' options, as described below.
-
- In the Cygnus tree at present, the info files are built and
-installed as a separate step. To build them, run `make info'. To
-install them, run `make install-info'. The equivalent html files are
-also built and installed in a separate step. To build the html files,
-run `make html'. To install the html files run `make install-html'.
-
- All `configure' scripts support a wide variety of options. The most
-interesting ones are `--with' and `--enable' options which are
-generally specific to particular tools. You can usually use the
-`--help' option to get a list of interesting options for a particular
-configure script.
-
- The only generic options you are likely to use are the `--prefix'
-and `--exec-prefix' options. These options are used to specify the
-installation directory.
-
- The directory named by the `--prefix' option will hold machine
-independent files such as info files.
-
- The directory named by the `--exec-prefix' option, which is normally
-a subdirectory of the `--prefix' directory, will hold machine dependent
-files such as executables.
-
- The default for `--prefix' is `/usr/local'. The default for
-`--exec-prefix' is the value used for `--prefix'.
-
- The convention used in Cygnus releases is to use a `--prefix' option
-of `/usr/cygnus/RELEASE', where RELEASE is the name of the release, and
-to use a `--exec-prefix' option of `/usr/cygnus/RELEASE/H-HOST', where
-HOST is the configuration name of the host system (*note Configuration
-Names::).
-
- Do not use either the source or the object directory as the
-installation directory. That will just lead to confusion.
-
-
-File: configure.info, Node: Getting Started, Next: Files, Prev: Introduction, Up: Top
-
-2 Getting Started
-*****************
-
-To start using the GNU configure and build system with your software
-package, you must write three files, and you must run some tools to
-manually generate additional files.
-
-* Menu:
-
-* Write configure.in:: Write configure.in.
-* Write Makefile.am:: Write Makefile.am.
-* Write acconfig.h:: Write acconfig.h.
-* Generate files:: Generate files.
-* Getting Started Example:: Example.
-
-
-File: configure.info, Node: Write configure.in, Next: Write Makefile.am, Up: Getting Started
-
-2.1 Write configure.in
-======================
-
-You must first write the file `configure.in'. This is an autoconf
-input file, and the autoconf manual describes in detail what this file
-should look like.
-
- You will write tests in your `configure.in' file to check for
-conditions that may change from one system to another, such as the
-presence of particular header files or functions.
-
- For example, not all systems support the `gettimeofday' function.
-If you want to use the `gettimeofday' function when it is available,
-and to use some other function when it is not, you would check for this
-by putting `AC_CHECK_FUNCS(gettimeofday)' in `configure.in'.
-
- When the configure script is run at build time, this will arrange to
-define the preprocessor macro `HAVE_GETTIMEOFDAY' to the value 1 if the
-`gettimeofday' function is available, and to not define the macro at
-all if the function is not available. Your code can then use `#ifdef'
-to test whether it is safe to call `gettimeofday'.
-
- If you have an existing body of code, the `autoscan' program may
-help identify potential portability problems, and hence configure tests
-that you will want to use. *Note Invoking autoscan: (autoconf)Invoking
-autoscan.
-
- Another handy tool for an existing body of code is `ifnames'. This
-will show you all the preprocessor conditionals that the code already
-uses. *Note Invoking ifnames: (autoconf)Invoking ifnames.
-
- Besides the portability tests which are specific to your particular
-package, every `configure.in' file should contain the following macros.
-
-`AC_INIT'
- This macro takes a single argument, which is the name of a file in
- your package. For example, `AC_INIT(foo.c)'.
-
-`AC_PREREQ(VERSION)'
- This macro is optional. It may be used to indicate the version of
- `autoconf' that you are using. This will prevent users from
- running an earlier version of `autoconf' and perhaps getting an
- invalid `configure' script. For example, `AC_PREREQ(2.12)'.
-
-`AM_INIT_AUTOMAKE'
- This macro takes two arguments: the name of the package, and a
- version number. For example, `AM_INIT_AUTOMAKE(foo, 1.0)'. (This
- macro is not needed if you are not using automake).
-
-`AM_CONFIG_HEADER'
- This macro names the header file which will hold the preprocessor
- macro definitions at run time. Normally this should be
- `config.h'. Your sources would then use `#include "config.h"' to
- include it.
-
- This macro may optionally name the input file for that header
- file; by default, this is `config.h.in', but that file name works
- poorly on DOS filesystems. Therefore, it is often better to name
- it explicitly as `config.in'.
-
- This is what you should normally put in `configure.in':
- AM_CONFIG_HEADER(config.h:config.in)
-
- (If you are not using automake, use `AC_CONFIG_HEADER' rather than
- `AM_CONFIG_HEADER').
-
-`AM_MAINTAINER_MODE'
- This macro always appears in Cygnus configure scripts. Other
- programs may or may not use it.
-
- If this macro is used, the `--enable-maintainer-mode' option is
- required to enable automatic rebuilding of generated files used by
- the configure system. This of course requires that developers be
- aware of, and use, that option.
-
- If this macro is not used, then the generated files will always be
- rebuilt automatically. This will cause problems if the wrong
- versions of autoconf, automake, or others are in the builder's
- `PATH'.
-
- (If you are not using automake, you do not need to use this macro).
-
-`AC_EXEEXT'
- Either this macro or `AM_EXEEXT' always appears in Cygnus configure
- files. Other programs may or may not use one of them.
-
- This macro looks for the executable suffix used on the host
- system. On Unix systems, this is the empty string. On Windows
- systems, this is `.exe'. This macro directs automake to use the
- executable suffix as appropriate when creating programs. This
- macro does not take any arguments.
-
- The `AC_EXEEXT' form is new, and is part of a Cygnus patch to
- autoconf to support compiling with Visual C++. Older programs use
- `AM_EXEEXT' instead.
-
- (Programs which do not use automake use neither `AC_EXEEXT' nor
- `AM_EXEEXT').
-
-`AC_PROG_CC'
- If you are writing C code, you will normally want to use this
- macro. It locates the C compiler to use. It does not take any
- arguments.
-
- However, if this `configure.in' file is for a library which is to
- be compiled by a cross compiler which may not fully work, then you
- will not want to use `AC_PROG_CC'. Instead, you will want to use a
- variant which does not call the macro `AC_PROG_CC_WORKS'. Examples
- can be found in various `configure.in' files for libraries that are
- compiled with cross compilers, such as libiberty or libgloss.
- This is essentially a bug in autoconf, and there will probably be
- a better workaround at some point.
-
-`AC_PROG_CXX'
- If you are writing C++ code, you will want to use this macro. It
- locates the C++ compiler to use. It does not take any arguments.
- The same cross compiler comments apply as for `AC_PROG_CC'.
-
-`AM_PROG_LIBTOOL'
- If you want to build libraries, and you want to permit them to be
- shared, or you want to link against libraries which were built
- using libtool, then you will need this macro. This macro is
- required in order to use libtool.
-
- By default, this will cause all libraries to be built as shared
- libraries. To prevent this-to change the default-use
- `AM_DISABLE_SHARED' before `AM_PROG_LIBTOOL'. The configure
- options `--enable-shared' and `--disable-shared' may be used to
- override the default at build time.
-
-`AC_DEFINE(_GNU_SOURCE)'
- GNU packages should normally include this line before any other
- feature tests. This defines the macro `_GNU_SOURCE' when
- compiling, which directs the libc header files to provide the
- standard GNU system interfaces including all GNU extensions. If
- this macro is not defined, certain GNU extensions may not be
- available.
-
-`AC_OUTPUT'
- This macro takes a list of file names which the configure process
- should produce. This is normally a list of one or more `Makefile'
- files in different directories. If your package lives entirely in
- a single directory, you would use simply `AC_OUTPUT(Makefile)'.
- If you also have, for example, a `lib' subdirectory, you would use
- `AC_OUTPUT(Makefile lib/Makefile)'.
-
- If you want to use locally defined macros in your `configure.in'
-file, then you will need to write a `acinclude.m4' file which defines
-them (if not using automake, this file is called `aclocal.m4').
-Alternatively, you can put separate macros in an `m4' subdirectory, and
-put `ACLOCAL_AMFLAGS = -I m4' in your `Makefile.am' file so that the
-`aclocal' program will be able to find them.
-
- The different macro prefixes indicate which tool defines the macro.
-Macros which start with `AC_' are part of autoconf. Macros which start
-with `AM_' are provided by automake or libtool.
-
-
-File: configure.info, Node: Write Makefile.am, Next: Write acconfig.h, Prev: Write configure.in, Up: Getting Started
-
-2.2 Write Makefile.am
-=====================
-
-You must write the file `Makefile.am'. This is an automake input file,
-and the automake manual describes in detail what this file should look
-like.
-
- The automake commands in `Makefile.am' mostly look like variable
-assignments in a `Makefile'. automake recognizes special variable
-names, and automatically add make rules to the output as needed.
-
- There will be one `Makefile.am' file for each directory in your
-package. For each directory with subdirectories, the `Makefile.am'
-file should contain the line
- SUBDIRS = DIR DIR ...
- where each DIR is the name of a subdirectory.
-
- For each `Makefile.am', there should be a corresponding `Makefile'
-in the `AC_OUTPUT' macro in `configure.in'.
-
- Every `Makefile.am' written at Cygnus should contain the line
- AUTOMAKE_OPTIONS = cygnus
- This puts automake into Cygnus mode. See the automake manual for
-details.
-
- You may to include the version number of `automake' that you are
-using on the `AUTOMAKE_OPTIONS' line. For example,
- AUTOMAKE_OPTIONS = cygnus 1.3
- This will prevent users from running an earlier version of
-`automake' and perhaps getting an invalid `Makefile.in'.
-
- If your package builds a program, then in the directory where that
-program is built you will normally want a line like
- bin_PROGRAMS = PROGRAM
- where PROGRAM is the name of the program. You will then want a line
-like
- PROGRAM_SOURCES = FILE FILE ...
- where each FILE is the name of a source file to link into the
-program (e.g., `foo.c').
-
- If your package builds a library, and you do not want the library to
-ever be built as a shared library, then in the directory where that
-library is built you will normally want a line like
- lib_LIBRARIES = libNAME.a
- where `libNAME.a' is the name of the library. You will then want a
-line like
- libNAME_a_SOURCES = FILE FILE ...
- where each FILE is the name of a source file to add to the library.
-
- If your package builds a library, and you want to permit building the
-library as a shared library, then in the directory where that library is
-built you will normally want a line like
- lib_LTLIBRARIES = libNAME.la
- The use of `LTLIBRARIES', and the `.la' extension, indicate a
-library to be built using libtool. As usual, you will then want a line
-like
- libNAME_la_SOURCES = FILE FILE ...
-
- The strings `bin' and `lib' that appear above in `bin_PROGRAMS' and
-`lib_LIBRARIES' are not arbitrary. They refer to particular
-directories, which may be set by the `--bindir' and `--libdir' options
-to `configure'. If those options are not used, the default values are
-based on the `--prefix' or `--exec-prefix' options to `configure'. It
-is possible to use other names if the program or library should be
-installed in some other directory.
-
- The `Makefile.am' file may also contain almost anything that may
-appear in a normal `Makefile'. automake also supports many other
-special variables, as well as conditionals.
-
- See the automake manual for more information.
-
-
-File: configure.info, Node: Write acconfig.h, Next: Generate files, Prev: Write Makefile.am, Up: Getting Started
-
-2.3 Write acconfig.h
-====================
-
-If you are generating a portability header file, (i.e., you are using
-`AM_CONFIG_HEADER' in `configure.in'), then you will have to write a
-`acconfig.h' file. It will have to contain the following lines.
-
- /* Name of package. */
- #undef PACKAGE
-
- /* Version of package. */
- #undef VERSION
-
- This requirement is really a bug in the system, and the requirement
-may be eliminated at some later date.
-
- The `acconfig.h' file will also similar comment and `#undef' lines
-for any unusual macros in the `configure.in' file, including any macro
-which appears in a `AC_DEFINE' macro.
-
- In particular, if you are writing a GNU package and therefore include
-`AC_DEFINE(_GNU_SOURCE)' in `configure.in' as suggested above, you will
-need lines like this in `acconfig.h':
- /* Enable GNU extensions. */
- #undef _GNU_SOURCE
-
- Normally the `autoheader' program will inform you of any such
-requirements by printing an error message when it is run. However, if
-you do anything particular odd in your `configure.in' file, you will
-have to make sure that the right entries appear in `acconfig.h', since
-otherwise the results of the tests may not be available in the
-`config.h' file which your code will use.
-
- (Thee `PACKAGE' and `VERSION' lines are not required if you are not
-using automake, and in that case you may not need a `acconfig.h' file
-at all).
-
-
-File: configure.info, Node: Generate files, Next: Getting Started Example, Prev: Write acconfig.h, Up: Getting Started
-
-2.4 Generate files
-==================
-
-Once you have written `configure.in', `Makefile.am', `acconfig.h', and
-possibly `acinclude.m4', you must use autoconf and automake programs to
-produce the first versions of the generated files. This is done by
-executing the following sequence of commands.
-
- aclocal
- autoconf
- autoheader
- automake
-
- The `aclocal' and `automake' commands are part of the automake
-package, and the `autoconf' and `autoheader' commands are part of the
-autoconf package.
-
- If you are using a `m4' subdirectory for your macros, you will need
-to use the `-I m4' option when you run `aclocal'.
-
- If you are not using the Cygnus tree, use the `-a' option when
-running `automake' command in order to copy the required support files
-into your source directory.
-
- If you are using libtool, you must build and install the libtool
-package with the same `--prefix' and `--exec-prefix' options as you
-used with the autoconf and automake packages. You must do this before
-running any of the above commands. If you are not using the Cygnus
-tree, you will need to run the `libtoolize' program to copy the libtool
-support files into your directory.
-
- Once you have managed to run these commands without getting any
-errors, you should create a new empty directory, and run the `configure'
-script which will have been created by `autoconf' with the
-`--enable-maintainer-mode' option. This will give you a set of
-Makefiles which will include rules to automatically rebuild all the
-generated files.
-
- After doing that, whenever you have changed some of the input files
-and want to regenerated the other files, go to your object directory
-and run `make'. Doing this is more reliable than trying to rebuild the
-files manually, because there are complex order dependencies and it is
-easy to forget something.
-
-
-File: configure.info, Node: Getting Started Example, Prev: Generate files, Up: Getting Started
-
-2.5 Example
-===========
-
-Let's consider a trivial example.
-
- Suppose we want to write a simple version of `touch'. Our program,
-which we will call `poke', will take a single file name argument, and
-use the `utime' system call to set the modification and access times of
-the file to the current time. We want this program to be highly
-portable.
-
- We'll first see what this looks like without using autoconf and
-automake, and then see what it looks like with them.
-
-* Menu:
-
-* Getting Started Example 1:: First Try.
-* Getting Started Example 2:: Second Try.
-* Getting Started Example 3:: Third Try.
-* Generate Files in Example:: Generate Files.
-
-
-File: configure.info, Node: Getting Started Example 1, Next: Getting Started Example 2, Up: Getting Started Example
-
-2.5.1 First Try
----------------
-
-Here is our first try at `poke.c'. Note that we've written it without
-ANSI/ISO C prototypes, since we want it to be highly portable.
-
- #include <stdio.h>
- #include <stdlib.h>
- #include <sys/types.h>
- #include <utime.h>
-
- int
- main (argc, argv)
- int argc;
- char **argv;
- {
- if (argc != 2)
- {
- fprintf (stderr, "Usage: poke file\n");
- exit (1);
- }
-
- if (utime (argv[1], NULL) < 0)
- {
- perror ("utime");
- exit (1);
- }
-
- exit (0);
- }
-
- We also write a simple `Makefile'.
-
- CC = gcc
- CFLAGS = -g -O2
-
- all: poke
-
- poke: poke.o
- $(CC) -o poke $(CFLAGS) $(LDFLAGS) poke.o
-
- So far, so good.
-
- Unfortunately, there are a few problems.
-
- On older Unix systems derived from BSD 4.3, the `utime' system call
-does not accept a second argument of `NULL'. On those systems, we need
-to pass a pointer to `struct utimbuf' structure. Unfortunately, even
-older systems don't define that structure; on those systems, we need to
-pass an array of two `long' values.
-
- The header file `stdlib.h' was invented by ANSI C, and older systems
-don't have a copy. We included it above to get a declaration of `exit'.
-
- We can find some of these portability problems by running
-`autoscan', which will create a `configure.scan' file which we can use
-as a prototype for our `configure.in' file. I won't show the output,
-but it will notice the potential problems with `utime' and `stdlib.h'.
-
- In our `Makefile', we don't provide any way to install the program.
-This doesn't matter much for such a simple example, but a real program
-will need an `install' target. For that matter, we will also want a
-`clean' target.
-
-
-File: configure.info, Node: Getting Started Example 2, Next: Getting Started Example 3, Prev: Getting Started Example 1, Up: Getting Started Example
-
-2.5.2 Second Try
-----------------
-
-Here is our second try at this program.
-
- We modify `poke.c' to use preprocessor macros to control what
-features are available. (I've cheated a bit by using the same macro
-names which autoconf will use).
-
- #include <stdio.h>
-
- #ifdef STDC_HEADERS
- #include <stdlib.h>
- #endif
-
- #include <sys/types.h>
-
- #ifdef HAVE_UTIME_H
- #include <utime.h>
- #endif
-
- #ifndef HAVE_UTIME_NULL
-
- #include <time.h>
-
- #ifndef HAVE_STRUCT_UTIMBUF
-
- struct utimbuf
- {
- long actime;
- long modtime;
- };
-
- #endif
-
- static int
- utime_now (file)
- char *file;
- {
- struct utimbuf now;
-
- now.actime = now.modtime = time (NULL);
- return utime (file, &now);
- }
-
- #define utime(f, p) utime_now (f)
-
- #endif /* HAVE_UTIME_NULL */
-
- int
- main (argc, argv)
- int argc;
- char **argv;
- {
- if (argc != 2)
- {
- fprintf (stderr, "Usage: poke file\n");
- exit (1);
- }
-
- if (utime (argv[1], NULL) < 0)
- {
- perror ("utime");
- exit (1);
- }
-
- exit (0);
- }
-
- Here is the associated `Makefile'. We've added support for the
-preprocessor flags we use. We've also added `install' and `clean'
-targets.
-
- # Set this to your installation directory.
- bindir = /usr/local/bin
-
- # Uncomment this if you have the standard ANSI/ISO C header files.
- # STDC_HDRS = -DSTDC_HEADERS
-
- # Uncomment this if you have utime.h.
- # UTIME_H = -DHAVE_UTIME_H
-
- # Uncomment this if utime (FILE, NULL) works on your system.
- # UTIME_NULL = -DHAVE_UTIME_NULL
-
- # Uncomment this if struct utimbuf is defined in utime.h.
- # UTIMBUF = -DHAVE_STRUCT_UTIMBUF
-
- CC = gcc
- CFLAGS = -g -O2
-
- ALL_CFLAGS = $(STDC_HDRS) $(UTIME_H) $(UTIME_NULL) $(UTIMBUF) $(CFLAGS)
-
- all: poke
-
- poke: poke.o
- $(CC) -o poke $(ALL_CFLAGS) $(LDFLAGS) poke.o
-
- .c.o:
- $(CC) -c $(ALL_CFLAGS) poke.c
-
- install: poke
- cp poke $(bindir)/poke
-
- clean:
- rm poke poke.o
-
- Some problems with this approach should be clear.
-
- Users who want to compile poke will have to know how `utime' works
-on their systems, so that they can uncomment the `Makefile' correctly.
-
- The installation is done using `cp', but many systems have an
-`install' program which may be used, and which supports optional
-features such as stripping debugging information out of the installed
-binary.
-
- The use of `Makefile' variables like `CC', `CFLAGS' and `LDFLAGS'
-follows the requirements of the GNU standards. This is convenient for
-all packages, since it reduces surprises for users. However, it is
-easy to get the details wrong, and wind up with a slightly nonstandard
-distribution.
-
-
-File: configure.info, Node: Getting Started Example 3, Next: Generate Files in Example, Prev: Getting Started Example 2, Up: Getting Started Example
-
-2.5.3 Third Try
----------------
-
-For our third try at this program, we will write a `configure.in'
-script to discover the configuration features on the host system, rather
-than requiring the user to edit the `Makefile'. We will also write a
-`Makefile.am' rather than a `Makefile'.
-
- The only change to `poke.c' is to add a line at the start of the
-file:
- #include "config.h"
-
- The new `configure.in' file is as follows.
-
- AC_INIT(poke.c)
- AM_INIT_AUTOMAKE(poke, 1.0)
- AM_CONFIG_HEADER(config.h:config.in)
- AC_PROG_CC
- AC_HEADER_STDC
- AC_CHECK_HEADERS(utime.h)
- AC_EGREP_HEADER(utimbuf, utime.h, AC_DEFINE(HAVE_STRUCT_UTIMBUF))
- AC_FUNC_UTIME_NULL
- AC_OUTPUT(Makefile)
-
- The first four macros in this file, and the last one, were described
-above; see *note Write configure.in::. If we omit these macros, then
-when we run `automake' we will get a reminder that we need them.
-
- The other macros are standard autoconf macros.
-
-`AC_HEADER_STDC'
- Check for standard C headers.
-
-`AC_CHECK_HEADERS'
- Check whether a particular header file exists.
-
-`AC_EGREP_HEADER'
- Check for a particular string in a particular header file, in this
- case checking for `utimbuf' in `utime.h'.
-
-`AC_FUNC_UTIME_NULL'
- Check whether `utime' accepts a NULL second argument to set the
- file change time to the current time.
-
- See the autoconf manual for a more complete description.
-
- The new `Makefile.am' file is as follows. Note how simple this is
-compared to our earlier `Makefile'.
-
- bin_PROGRAMS = poke
-
- poke_SOURCES = poke.c
-
- This means that we should build a single program name `poke'. It
-should be installed in the binary directory, which we called `bindir'
-earlier. The program `poke' is built from the source file `poke.c'.
-
- We must also write a `acconfig.h' file. Besides `PACKAGE' and
-`VERSION', which must be mentioned for all packages which use automake,
-we must include `HAVE_STRUCT_UTIMBUF', since we mentioned it in an
-`AC_DEFINE'.
-
- /* Name of package. */
- #undef PACKAGE
-
- /* Version of package. */
- #undef VERSION
-
- /* Whether utime.h defines struct utimbuf. */
- #undef HAVE_STRUCT_UTIMBUF
-
-
-File: configure.info, Node: Generate Files in Example, Prev: Getting Started Example 3, Up: Getting Started Example
-
-2.5.4 Generate Files
---------------------
-
-We must now generate the other files, using the following commands.
-
- aclocal
- autoconf
- autoheader
- automake
-
- When we run `autoheader', it will remind us of any macros we forgot
-to add to `acconfig.h'.
-
- When we run `automake', it will want to add some files to our
-distribution. It will add them automatically if we use the
-`--add-missing' option.
-
- By default, `automake' will run in GNU mode, which means that it
-will want us to create certain additional files; as of this writing, it
-will want `NEWS', `README', `AUTHORS', and `ChangeLog', all of which
-are files which should appear in a standard GNU distribution. We can
-either add those files, or run `automake' with the `--foreign' option.
-
- Running these tools will generate the following files, all of which
-are described in the next chapter.
-
- * `aclocal.m4'
-
- * `configure'
-
- * `config.in'
-
- * `Makefile.in'
-
- * `stamp-h.in'
-
-
-File: configure.info, Node: Files, Next: Configuration Names, Prev: Getting Started, Up: Top
-
-3 Files
-*******
-
-As was seen in the previous chapter, the GNU configure and build system
-uses a number of different files. The developer must write a few files.
-The others are generated by various tools.
-
- The system is rather flexible, and can be used in many different
-ways. In describing the files that it uses, I will describe the common
-case, and mention some other cases that may arise.
-
-* Menu:
-
-* Developer Files:: Developer Files.
-* Build Files:: Build Files.
-* Support Files:: Support Files.
-
-
-File: configure.info, Node: Developer Files, Next: Build Files, Up: Files
-
-3.1 Developer Files
-===================
-
-This section describes the files written or generated by the developer
-of a package.
-
-* Menu:
-
-* Developer Files Picture:: Developer Files Picture.
-* Written Developer Files:: Written Developer Files.
-* Generated Developer Files:: Generated Developer Files.
-
-
-File: configure.info, Node: Developer Files Picture, Next: Written Developer Files, Up: Developer Files
-
-3.1.1 Developer Files Picture
------------------------------
-
-Here is a picture of the files which are written by the developer, the
-generated files which would be included with a complete source
-distribution, and the tools which create those files. The file names
-are plain text and the tool names are enclosed by `*' characters (e.g.,
-`autoheader' is the name of a tool, not the name of a file).
-
- acconfig.h configure.in Makefile.am
- | | |
- | --------------+---------------------- |
- | | | | |
- v v | acinclude.m4 | |
- *autoheader* | | v v
- | | v --->*automake*
- v |--->*aclocal* | |
- config.in | | | v
- | v | Makefile.in
- | aclocal.m4---
- | |
- v v
- *autoconf*
- |
- v
- configure
-
-
-File: configure.info, Node: Written Developer Files, Next: Generated Developer Files, Prev: Developer Files Picture, Up: Developer Files
-
-3.1.2 Written Developer Files
------------------------------
-
-The following files would be written by the developer.
-
-`configure.in'
- This is the configuration script. This script contains
- invocations of autoconf macros. It may also contain ordinary
- shell script code. This file will contain feature tests for
- portability issues. The last thing in the file will normally be
- an `AC_OUTPUT' macro listing which files to create when the
- builder runs the configure script. This file is always required
- when using the GNU configure system. *Note Write configure.in::.
-
-`Makefile.am'
- This is the automake input file. It describes how the code should
- be built. It consists of definitions of automake variables. It
- may also contain ordinary Makefile targets. This file is only
- needed when using automake (newer tools normally use automake, but
- there are still older tools which have not been converted, in
- which the developer writes `Makefile.in' directly). *Note Write
- Makefile.am::.
-
-`acconfig.h'
- When the configure script creates a portability header file, by
- using `AM_CONFIG_HEADER' (or, if not using automake,
- `AC_CONFIG_HEADER'), this file is used to describe macros which are
- not recognized by the `autoheader' command. This is normally a
- fairly uninteresting file, consisting of a collection of `#undef'
- lines with comments. Normally any call to `AC_DEFINE' in
- `configure.in' will require a line in this file. *Note Write
- acconfig.h::.
-
-`acinclude.m4'
- This file is not always required. It defines local autoconf
- macros. These macros may then be used in `configure.in'. If you
- don't need any local autoconf macros, then you don't need this
- file at all. In fact, in general, you never need local autoconf
- macros, since you can put everything in `configure.in', but
- sometimes a local macro is convenient.
-
- Newer tools may omit `acinclude.m4', and instead use a
- subdirectory, typically named `m4', and define `ACLOCAL_AMFLAGS =
- -I m4' in `Makefile.am' to force `aclocal' to look there for macro
- definitions. The macro definitions are then placed in separate
- files in that directory.
-
- The `acinclude.m4' file is only used when using automake; in older
- tools, the developer writes `aclocal.m4' directly, if it is needed.
-
-
-File: configure.info, Node: Generated Developer Files, Prev: Written Developer Files, Up: Developer Files
-
-3.1.3 Generated Developer Files
--------------------------------
-
-The following files would be generated by the developer.
-
- When using automake, these files are normally not generated manually
-after the first time. Instead, the generated `Makefile' contains rules
-to automatically rebuild the files as required. When
-`AM_MAINTAINER_MODE' is used in `configure.in' (the normal case in
-Cygnus code), the automatic rebuilding rules will only be defined if
-you configure using the `--enable-maintainer-mode' option.
-
- When using automatic rebuilding, it is important to ensure that all
-the various tools have been built and installed on your `PATH'. Using
-automatic rebuilding is highly recommended, so much so that I'm not
-going to explain what you have to do if you don't use it.
-
-`configure'
- This is the configure script which will be run when building the
- package. This is generated by `autoconf' from `configure.in' and
- `aclocal.m4'. This is a shell script.
-
-`Makefile.in'
- This is the file which the configure script will turn into the
- `Makefile' at build time. This file is generated by `automake'
- from `Makefile.am'. If you aren't using automake, you must write
- this file yourself. This file is pretty much a normal `Makefile',
- with some configure substitutions for certain variables.
-
-`aclocal.m4'
- This file is created by the `aclocal' program, based on the
- contents of `configure.in' and `acinclude.m4' (or, as noted in the
- description of `acinclude.m4' above, on the contents of an `m4'
- subdirectory). This file contains definitions of autoconf macros
- which `autoconf' will use when generating the file `configure'.
- These autoconf macros may be defined by you in `acinclude.m4' or
- they may be defined by other packages such as automake, libtool or
- gettext. If you aren't using automake, you will normally write
- this file yourself; in that case, if `configure.in' uses only
- standard autoconf macros, this file will not be needed at all.
-
-`config.in'
- This file is created by `autoheader' based on `acconfig.h' and
- `configure.in'. At build time, the configure script will define
- some of the macros in it to create `config.h', which may then be
- included by your program. This permits your C code to use
- preprocessor conditionals to change its behaviour based on the
- characteristics of the host system. This file may also be called
- `config.h.in'.
-
-`stamp.h-in'
- This rather uninteresting file, which I omitted from the picture,
- is generated by `automake'. It always contains the string
- `timestamp'. It is used as a timestamp file indicating whether
- `config.in' is up to date. Using a timestamp file means that
- `config.in' can be marked as up to date without actually changing
- its modification time. This is useful since `config.in' depends
- upon `configure.in', but it is easy to change `configure.in' in a
- way which does not affect `config.in'.
-
-
-File: configure.info, Node: Build Files, Next: Support Files, Prev: Developer Files, Up: Files
-
-3.2 Build Files
-===============
-
-This section describes the files which are created at configure and
-build time. These are the files which somebody who builds the package
-will see.
-
- Of course, the developer will also build the package. The
-distinction between developer files and build files is not that the
-developer does not see the build files, but that somebody who only
-builds the package does not have to worry about the developer files.
-
-* Menu:
-
-* Build Files Picture:: Build Files Picture.
-* Build Files Description:: Build Files Description.
-
-
-File: configure.info, Node: Build Files Picture, Next: Build Files Description, Up: Build Files
-
-3.2.1 Build Files Picture
--------------------------
-
-Here is a picture of the files which will be created at build time.
-`config.status' is both a created file and a shell script which is run
-to create other files, and the picture attempts to show that.
-
- config.in *configure* Makefile.in
- | | |
- | v |
- | config.status |
- | | |
- *config.status*<======+==========>*config.status*
- | |
- v v
- config.h Makefile
-
-
-File: configure.info, Node: Build Files Description, Prev: Build Files Picture, Up: Build Files
-
-3.2.2 Build Files Description
------------------------------
-
-This is a description of the files which are created at build time.
-
-`config.status'
- The first step in building a package is to run the `configure'
- script. The `configure' script will create the file
- `config.status', which is itself a shell script. When you first
- run `configure', it will automatically run `config.status'. An
- `Makefile' derived from an automake generated `Makefile.in' will
- contain rules to automatically run `config.status' again when
- necessary to recreate certain files if their inputs change.
-
-`Makefile'
- This is the file which make will read to build the program. The
- `config.status' script will transform `Makefile.in' into
- `Makefile'.
-
-`config.h'
- This file defines C preprocessor macros which C code can use to
- adjust its behaviour on different systems. The `config.status'
- script will transform `config.in' into `config.h'.
-
-`config.cache'
- This file did not fit neatly into the picture, and I omitted it.
- It is used by the `configure' script to cache results between
- runs. This can be an important speedup. If you modify
- `configure.in' in such a way that the results of old tests should
- change (perhaps you have added a new library to `LDFLAGS'), then
- you will have to remove `config.cache' to force the tests to be
- rerun.
-
- The autoconf manual explains how to set up a site specific cache
- file. This can speed up running `configure' scripts on your
- system.
-
-`stamp.h'
- This file, which I omitted from the picture, is similar to
- `stamp-h.in'. It is used as a timestamp file indicating whether
- `config.h' is up to date. This is useful since `config.h' depends
- upon `config.status', but it is easy for `config.status' to change
- in a way which does not affect `config.h'.
-
-
-File: configure.info, Node: Support Files, Prev: Build Files, Up: Files
-
-3.3 Support Files
-=================
-
-The GNU configure and build system requires several support files to be
-included with your distribution. You do not normally need to concern
-yourself with these. If you are using the Cygnus tree, most are already
-present. Otherwise, they will be installed with your source by
-`automake' (with the `--add-missing' option) and `libtoolize'.
-
- You don't have to put the support files in the top level directory.
-You can put them in a subdirectory, and use the `AC_CONFIG_AUX_DIR'
-macro in `configure.in' to tell `automake' and the `configure' script
-where they are.
-
- In this section, I describe the support files, so that you can know
-what they are and why they are there.
-
-`ABOUT-NLS'
- Added by automake if you are using gettext. This is a
- documentation file about the gettext project.
-
-`ansi2knr.c'
- Used by an automake generated `Makefile' if you put `ansi2knr' in
- `AUTOMAKE_OPTIONS' in `Makefile.am'. This permits compiling ANSI
- C code with a K&R C compiler.
-
-`ansi2knr.1'
- The man page which goes with `ansi2knr.c'.
-
-`config.guess'
- A shell script which determines the configuration name for the
- system on which it is run.
-
-`config.sub'
- A shell script which canonicalizes a configuration name entered by
- a user.
-
-`elisp-comp'
- Used to compile Emacs LISP files.
-
-`install-sh'
- A shell script which installs a program. This is used if the
- configure script can not find an install binary.
-
-`ltconfig'
- Used by libtool. This is a shell script which configures libtool
- for the particular system on which it is used.
-
-`ltmain.sh'
- Used by libtool. This is the actual libtool script which is used,
- after it is configured by `ltconfig' to build a library.
-
-`mdate-sh'
- A shell script used by an automake generated `Makefile' to pretty
- print the modification time of a file. This is used to maintain
- version numbers for texinfo files.
-
-`missing'
- A shell script used if some tool is missing entirely. This is
- used by an automake generated `Makefile' to avoid certain sorts of
- timestamp problems.
-
-`mkinstalldirs'
- A shell script which creates a directory, including all parent
- directories. This is used by an automake generated `Makefile'
- during installation.
-
-`texinfo.tex'
- Required if you have any texinfo files. This is used when
- converting Texinfo files into DVI using `texi2dvi' and TeX.
-
-`ylwrap'
- A shell script used by an automake generated `Makefile' to run
- programs like `bison', `yacc', `flex', and `lex'. These programs
- default to producing output files with a fixed name, and the
- `ylwrap' script runs them in a subdirectory to avoid file name
- conflicts when using a parallel make program.
-
-
-File: configure.info, Node: Configuration Names, Next: Cross Compilation Tools, Prev: Files, Up: Top
-
-4 Configuration Names
-*********************
-
-The GNU configure system names all systems using a "configuration
-name". All such names used to be triplets (they may now contain four
-parts in certain cases), and the term "configuration triplet" is still
-seen.
-
-* Menu:
-
-* Configuration Name Definition:: Configuration Name Definition.
-* Using Configuration Names:: Using Configuration Names.
-
-
-File: configure.info, Node: Configuration Name Definition, Next: Using Configuration Names, Up: Configuration Names
-
-4.1 Configuration Name Definition
-=================================
-
-This is a string of the form CPU-MANUFACTURER-OPERATING_SYSTEM. In
-some cases, this is extended to a four part form:
-CPU-MANUFACTURER-KERNEL-OPERATING_SYSTEM.
-
- When using a configuration name in a configure option, it is normally
-not necessary to specify an entire name. In particular, the
-MANUFACTURER field is often omitted, leading to strings such as
-`i386-linux' or `sparc-sunos'. The shell script `config.sub' will
-translate these shortened strings into the canonical form. autoconf
-will arrange for `config.sub' to be run automatically when it is needed.
-
- The fields of a configuration name are as follows:
-
-CPU
- The type of processor. This is typically something like `i386' or
- `sparc'. More specific variants are used as well, such as
- `mipsel' to indicate a little endian MIPS processor.
-
-MANUFACTURER
- A somewhat freeform field which indicates the manufacturer of the
- system. This is often simply `unknown'. Other common strings are
- `pc' for an IBM PC compatible system, or the name of a workstation
- vendor, such as `sun'.
-
-OPERATING_SYSTEM
- The name of the operating system which is run on the system. This
- will be something like `solaris2.5' or `irix6.3'. There is no
- particular restriction on the version number, and strings like
- `aix4.1.4.0' are seen. For an embedded system, which has no
- operating system, this field normally indicates the type of object
- file format, such as `elf' or `coff'.
-
-KERNEL
- This is used mainly for GNU/Linux. A typical GNU/Linux
- configuration name is `i586-pc-linux-gnulibc1'. In this case the
- kernel, `linux', is separated from the operating system,
- `gnulibc1'.
-
- The shell script `config.guess' will normally print the correct
-configuration name for the system on which it is run. It does by
-running `uname' and by examining other characteristics of the system.
-
- Because `config.guess' can normally determine the configuration name
-for a machine, it is normally only necessary to specify a configuration
-name when building a cross-compiler or when building using a
-cross-compiler.
-
-
-File: configure.info, Node: Using Configuration Names, Prev: Configuration Name Definition, Up: Configuration Names
-
-4.2 Using Configuration Names
-=============================
-
-A configure script will sometimes have to make a decision based on a
-configuration name. You will need to do this if you have to compile
-code differently based on something which can not be tested using a
-standard autoconf feature test.
-
- It is normally better to test for particular features, rather than to
-test for a particular system. This is because as Unix evolves,
-different systems copy features from one another. Even if you need to
-determine whether the feature is supported based on a configuration
-name, you should define a macro which describes the feature, rather than
-defining a macro which describes the particular system you are on.
-
- Testing for a particular system is normally done using a case
-statement in `configure.in'. The case statement might look something
-like the following, assuming that `host' is a shell variable holding a
-canonical configuration name (which will be the case if `configure.in'
-uses the `AC_CANONICAL_HOST' or `AC_CANONICAL_SYSTEM' macro).
-
- case "${host}" in
- i[3-7]86-*-linux-gnu*) do something ;;
- sparc*-sun-solaris2.[56789]*) do something ;;
- sparc*-sun-solaris*) do something ;;
- mips*-*-elf*) do something ;;
- esac
-
- It is particularly important to use `*' after the operating system
-field, in order to match the version number which will be generated by
-`config.guess'.
-
- In most cases you must be careful to match a range of processor
-types. For most processor families, a trailing `*' suffices, as in
-`mips*' above. For the i386 family, something along the lines of
-`i[3-7]86' suffices at present. For the m68k family, you will need
-something like `m68*'. Of course, if you do not need to match on the
-processor, it is simpler to just replace the entire field by a `*', as
-in `*-*-irix*'.
-
-
-File: configure.info, Node: Cross Compilation Tools, Next: Canadian Cross, Prev: Configuration Names, Up: Top
-
-5 Cross Compilation Tools
-*************************
-
-The GNU configure and build system can be used to build "cross
-compilation" tools. A cross compilation tool is a tool which runs on
-one system and produces code which runs on another system.
-
-* Menu:
-
-* Cross Compilation Concepts:: Cross Compilation Concepts.
-* Host and Target:: Host and Target.
-* Using the Host Type:: Using the Host Type.
-* Specifying the Target:: Specifying the Target.
-* Using the Target Type:: Using the Target Type.
-* Cross Tools in the Cygnus Tree:: Cross Tools in the Cygnus Tree
-
-
-File: configure.info, Node: Cross Compilation Concepts, Next: Host and Target, Up: Cross Compilation Tools
-
-5.1 Cross Compilation Concepts
-==============================
-
-A compiler which produces programs which run on a different system is a
-cross compilation compiler, or simply a "cross compiler". Similarly,
-we speak of cross assemblers, cross linkers, etc.
-
- In the normal case, a compiler produces code which runs on the same
-system as the one on which the compiler runs. When it is necessary to
-distinguish this case from the cross compilation case, such a compiler
-is called a "native compiler". Similarly, we speak of native
-assemblers, etc.
-
- Although the debugger is not strictly speaking a compilation tool,
-it is nevertheless meaningful to speak of a cross debugger: a debugger
-which is used to debug code which runs on another system. Everything
-that is said below about configuring cross compilation tools applies to
-the debugger as well.
-
-
-File: configure.info, Node: Host and Target, Next: Using the Host Type, Prev: Cross Compilation Concepts, Up: Cross Compilation Tools
-
-5.2 Host and Target
-===================
-
-When building cross compilation tools, there are two different systems
-involved: the system on which the tools will run, and the system for
-which the tools generate code.
-
- The system on which the tools will run is called the "host" system.
-
- The system for which the tools generate code is called the "target"
-system.
-
- For example, suppose you have a compiler which runs on a GNU/Linux
-system and generates ELF programs for a MIPS embedded system. In this
-case the GNU/Linux system is the host, and the MIPS ELF system is the
-target. Such a compiler could be called a GNU/Linux cross MIPS ELF
-compiler, or, equivalently, a `i386-linux-gnu' cross `mips-elf'
-compiler.
-
- Naturally, most programs are not cross compilation tools. For those
-programs, it does not make sense to speak of a target. It only makes
-sense to speak of a target for tools like `gcc' or the `binutils' which
-actually produce running code. For example, it does not make sense to
-speak of the target of a tool like `bison' or `make'.
-
- Most cross compilation tools can also serve as native tools. For a
-native compilation tool, it is still meaningful to speak of a target.
-For a native tool, the target is the same as the host. For example, for
-a GNU/Linux native compiler, the host is GNU/Linux, and the target is
-also GNU/Linux.
-
-
-File: configure.info, Node: Using the Host Type, Next: Specifying the Target, Prev: Host and Target, Up: Cross Compilation Tools
-
-5.3 Using the Host Type
-=======================
-
-In almost all cases the host system is the system on which you run the
-`configure' script, and on which you build the tools (for the case when
-they differ, *note Canadian Cross::).
-
- If your configure script needs to know the configuration name of the
-host system, and the package is not a cross compilation tool and
-therefore does not have a target, put `AC_CANONICAL_HOST' in
-`configure.in'. This macro will arrange to define a few shell
-variables when the `configure' script is run.
-
-`host'
- The canonical configuration name of the host. This will normally
- be determined by running the `config.guess' shell script, although
- the user is permitted to override this by using an explicit
- `--host' option.
-
-`host_alias'
- In the unusual case that the user used an explicit `--host' option,
- this will be the argument to `--host'. In the normal case, this
- will be the same as the `host' variable.
-
-`host_cpu'
-`host_vendor'
-`host_os'
- The first three parts of the canonical configuration name.
-
- The shell variables may be used by putting shell code in
-`configure.in'. For an example, see *note Using Configuration Names::.
-
-
-File: configure.info, Node: Specifying the Target, Next: Using the Target Type, Prev: Using the Host Type, Up: Cross Compilation Tools
-
-5.4 Specifying the Target
-=========================
-
-By default, the `configure' script will assume that the target is the
-same as the host. This is the more common case; for example, it leads
-to a native compiler rather than a cross compiler.
-
- If you want to build a cross compilation tool, you must specify the
-target explicitly by using the `--target' option when you run
-`configure'. The argument to `--target' is the configuration name of
-the system for which you wish to generate code. *Note Configuration
-Names::.
-
- For example, to build tools which generate code for a MIPS ELF
-embedded system, you would use `--target mips-elf'.
-
-
-File: configure.info, Node: Using the Target Type, Next: Cross Tools in the Cygnus Tree, Prev: Specifying the Target, Up: Cross Compilation Tools
-
-5.5 Using the Target Type
-=========================
-
-When writing `configure.in' for a cross compilation tool, you will need
-to use information about the target. To do this, put
-`AC_CANONICAL_SYSTEM' in `configure.in'.
-
- `AC_CANONICAL_SYSTEM' will look for a `--target' option and
-canonicalize it using the `config.sub' shell script. It will also run
-`AC_CANONICAL_HOST' (*note Using the Host Type::).
-
- The target type will be recorded in the following shell variables.
-Note that the host versions of these variables will also be defined by
-`AC_CANONICAL_HOST'.
-
-`target'
- The canonical configuration name of the target.
-
-`target_alias'
- The argument to the `--target' option. If the user did not specify
- a `--target' option, this will be the same as `host_alias'.
-
-`target_cpu'
-`target_vendor'
-`target_os'
- The first three parts of the canonical target configuration name.
-
- Note that if `host' and `target' are the same string, you can assume
-a native configuration. If they are different, you can assume a cross
-configuration.
-
- It is arguably possible for `host' and `target' to represent the
-same system, but for the strings to not be identical. For example, if
-`config.guess' returns `sparc-sun-sunos4.1.4', and somebody configures
-with `--target sparc-sun-sunos4.1', then the slight differences between
-the two versions of SunOS may be unimportant for your tool. However,
-in the general case it can be quite difficult to determine whether the
-differences between two configuration names are significant or not.
-Therefore, by convention, if the user specifies a `--target' option
-without specifying a `--host' option, it is assumed that the user wants
-to configure a cross compilation tool.
-
- The variables `target' and `target_alias' should be handled
-differently.
-
- In general, whenever the user may actually see a string,
-`target_alias' should be used. This includes anything which may appear
-in the file system, such as a directory name or part of a tool name.
-It also includes any tool output, unless it is clearly labelled as the
-canonical target configuration name. This permits the user to use the
-`--target' option to specify how the tool will appear to the outside
-world.
-
- On the other hand, when checking for characteristics of the target
-system, `target' should be used. This is because a wide variety of
-`--target' options may map into the same canonical configuration name.
-You should not attempt to duplicate the canonicalization done by
-`config.sub' in your own code.
-
- By convention, cross tools are installed with a prefix of the
-argument used with the `--target' option, also known as `target_alias'
-(*note Using the Target Type::). If the user does not use the
-`--target' option, and thus is building a native tool, no prefix is
-used.
-
- For example, if gcc is configured with `--target mips-elf', then the
-installed binary will be named `mips-elf-gcc'. If gcc is configured
-without a `--target' option, then the installed binary will be named
-`gcc'.
-
- The autoconf macro `AC_ARG_PROGRAM' will handle this for you. If
-you are using automake, no more need be done; the programs will
-automatically be installed with the correct prefixes. Otherwise, see
-the autoconf documentation for `AC_ARG_PROGRAM'.
-
-
-File: configure.info, Node: Cross Tools in the Cygnus Tree, Prev: Using the Target Type, Up: Cross Compilation Tools
-
-5.6 Cross Tools in the Cygnus Tree
-==================================
-
-The Cygnus tree is used for various packages including gdb, the GNU
-binutils, and egcs. It is also, of course, used for Cygnus releases.
-
- In the Cygnus tree, the top level `configure' script uses the old
-Cygnus configure system, not autoconf. The top level `Makefile.in' is
-written to build packages based on what is in the source tree, and
-supports building a large number of tools in a single
-`configure'/`make' step.
-
- The Cygnus tree may be configured with a `--target' option. The
-`--target' option applies recursively to every subdirectory, and
-permits building an entire set of cross tools at once.
-
-* Menu:
-
-* Host and Target Libraries:: Host and Target Libraries.
-* Target Library Configure Scripts:: Target Library Configure Scripts.
-* Make Targets in Cygnus Tree:: Make Targets in Cygnus Tree.
-* Target libiberty:: Target libiberty
-
-
-File: configure.info, Node: Host and Target Libraries, Next: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree
-
-5.6.1 Host and Target Libraries
--------------------------------
-
-The Cygnus tree distinguishes host libraries from target libraries.
-
- Host libraries are built with the compiler used to build the programs
-which run on the host, which is called the host compiler. This includes
-libraries such as `bfd' and `tcl'. These libraries are built with the
-host compiler, and are linked into programs like the binutils or gcc
-which run on the host.
-
- Target libraries are built with the target compiler. If gcc is
-present in the source tree, then the target compiler is the gcc that is
-built using the host compiler. Target libraries are libraries such as
-`newlib' and `libstdc++'. These libraries are not linked into the host
-programs, but are instead made available for use with programs built
-with the target compiler.
-
- For the rest of this section, assume that gcc is present in the
-source tree, so that it will be used to build the target libraries.
-
- There is a complication here. The configure process needs to know
-which compiler you are going to use to build a tool; otherwise, the
-feature tests will not work correctly. The Cygnus tree handles this by
-not configuring the target libraries until the target compiler is
-built. In order to permit everything to build using a single
-`configure'/`make', the configuration of the target libraries is
-actually triggered during the make step.
-
- When the target libraries are configured, the `--target' option is
-not used. Instead, the `--host' option is used with the argument of
-the `--target' option for the overall configuration. If no `--target'
-option was used for the overall configuration, the `--host' option will
-be passed with the output of the `config.guess' shell script. Any
-`--build' option is passed down unchanged.
-
- This translation of configuration options is done because since the
-target libraries are compiled with the target compiler, they are being
-built in order to run on the target of the overall configuration. By
-the definition of host, this means that their host system is the same as
-the target system of the overall configuration.
-
- The same process is used for both a native configuration and a cross
-configuration. Even when using a native configuration, the target
-libraries will be configured and built using the newly built compiler.
-This is particularly important for the C++ libraries, since there is no
-reason to assume that the C++ compiler used to build the host tools (if
-there even is one) uses the same ABI as the g++ compiler which will be
-used to build the target libraries.
-
- There is one difference between a native configuration and a cross
-configuration. In a native configuration, the target libraries are
-normally configured and built as siblings of the host tools. In a cross
-configuration, the target libraries are normally built in a subdirectory
-whose name is the argument to `--target'. This is mainly for
-historical reasons.
-
- To summarize, running `configure' in the Cygnus tree configures all
-the host libraries and tools, but does not configure any of the target
-libraries. Running `make' then does the following steps:
-
- * Build the host libraries.
-
- * Build the host programs, including gcc. Note that we call gcc
- both a host program (since it runs on the host) and a target
- compiler (since it generates code for the target).
-
- * Using the newly built target compiler, configure the target
- libraries.
-
- * Build the target libraries.
-
- The steps need not be done in precisely this order, since they are
-actually controlled by `Makefile' targets.
-
-
-File: configure.info, Node: Target Library Configure Scripts, Next: Make Targets in Cygnus Tree, Prev: Host and Target Libraries, Up: Cross Tools in the Cygnus Tree
-
-5.6.2 Target Library Configure Scripts
---------------------------------------
-
-There are a few things you must know in order to write a configure
-script for a target library. This is just a quick sketch, and beginners
-shouldn't worry if they don't follow everything here.
-
- The target libraries are configured and built using a newly built
-target compiler. There may not be any startup files or libraries for
-this target compiler. In fact, those files will probably be built as
-part of some target library, which naturally means that they will not
-exist when your target library is configured.
-
- This means that the configure script for a target library may not use
-any test which requires doing a link. This unfortunately includes many
-useful autoconf macros, such as `AC_CHECK_FUNCS'. autoconf macros
-which do a compile but not a link, such as `AC_CHECK_HEADERS', may be
-used.
-
- This is a severe restriction, but normally not a fatal one, as target
-libraries can often assume the presence of other target libraries, and
-thus know which functions will be available.
-
- As of this writing, the autoconf macro `AC_PROG_CC' does a link to
-make sure that the compiler works. This may fail in a target library,
-so target libraries must use a different set of macros to locate the
-compiler. See the `configure.in' file in a directory like `libiberty'
-or `libgloss' for an example.
-
- As noted in the previous section, target libraries are sometimes
-built in directories which are siblings to the host tools, and are
-sometimes built in a subdirectory. The `--with-target-subdir' configure
-option will be passed when the library is configured. Its value will be
-an empty string if the target library is a sibling. Its value will be
-the name of the subdirectory if the target library is in a subdirectory.
-
- If the overall build is not a native build (i.e., the overall
-configure used the `--target' option), then the library will be
-configured with the `--with-cross-host' option. The value of this
-option will be the host system of the overall build. Recall that the
-host system of the library will be the target of the overall build. If
-the overall build is a native build, the `--with-cross-host' option
-will not be used.
-
- A library which can be built both standalone and as a target library
-may want to install itself into different directories depending upon the
-case. When built standalone, or when built native, the library should
-be installed in `$(libdir)'. When built as a target library which is
-not native, the library should be installed in `$(tooldir)/lib'. The
-`--with-cross-host' option may be used to distinguish these cases.
-
- This same test of `--with-cross-host' may be used to see whether it
-is OK to use link tests in the configure script. If the
-`--with-cross-host' option is not used, then the library is being built
-either standalone or native, and a link should work.
-
-
-File: configure.info, Node: Make Targets in Cygnus Tree, Next: Target libiberty, Prev: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree
-
-5.6.3 Make Targets in Cygnus Tree
----------------------------------
-
-The top level `Makefile' in the Cygnus tree defines targets for every
-known subdirectory.
-
- For every subdirectory DIR which holds a host library or program,
-the `Makefile' target `all-DIR' will build that library or program.
-
- There are dependencies among host tools. For example, building gcc
-requires first building gas, because the gcc build process invokes the
-target assembler. These dependencies are reflected in the top level
-`Makefile'.
-
- For every subdirectory DIR which holds a target library, the
-`Makefile' target `configure-target-DIR' will configure that library.
-The `Makefile' target `all-target-DIR' will build that library.
-
- Every `configure-target-DIR' target depends upon `all-gcc', since
-gcc, the target compiler, is required to configure the tool. Every
-`all-target-DIR' target depends upon the corresponding
-`configure-target-DIR' target.
-
- There are several other targets which may be of interest for each
-directory: `install-DIR', `clean-DIR', and `check-DIR'. There are also
-corresponding `target' versions of these for the target libraries ,
-such as `install-target-DIR'.
-
-
-File: configure.info, Node: Target libiberty, Prev: Make Targets in Cygnus Tree, Up: Cross Tools in the Cygnus Tree
-
-5.6.4 Target libiberty
-----------------------
-
-The `libiberty' subdirectory is currently a special case, in that it is
-the only directory which is built both using the host compiler and
-using the target compiler.
-
- This is because the files in `libiberty' are used when building the
-host tools, and they are also incorporated into the `libstdc++' target
-library as support code.
-
- This duality does not pose any particular difficulties. It means
-that there are targets for both `all-libiberty' and
-`all-target-libiberty'.
-
- In a native configuration, when target libraries are not built in a
-subdirectory, the same objects are normally used as both the host build
-and the target build. This is normally OK, since libiberty contains
-only C code, and in a native configuration the results of the host
-compiler and the target compiler are normally interoperable.
-
- Irix 6 is again an exception here, since the SGI native compiler
-defaults to using the `O32' ABI, and gcc defaults to using the `N32'
-ABI. On Irix 6, the target libraries are built in a subdirectory even
-for a native configuration, avoiding this problem.
-
- There are currently no other libraries built for both the host and
-the target, but there is no conceptual problem with adding more.
-
-
-File: configure.info, Node: Canadian Cross, Next: Cygnus Configure, Prev: Cross Compilation Tools, Up: Top
-
-6 Canadian Cross
-****************
-
-It is possible to use the GNU configure and build system to build a
-program which will run on a system which is different from the system on
-which the tools are built. In other words, it is possible to build
-programs using a cross compiler.
-
- This is referred to as a "Canadian Cross".
-
-* Menu:
-
-* Canadian Cross Example:: Canadian Cross Example.
-* Canadian Cross Concepts:: Canadian Cross Concepts.
-* Build Cross Host Tools:: Build Cross Host Tools.
-* Build and Host Options:: Build and Host Options.
-* CCross not in Cygnus Tree:: Canadian Cross not in Cygnus Tree.
-* CCross in Cygnus Tree:: Canadian Cross in Cygnus Tree.
-* Supporting Canadian Cross:: Supporting Canadian Cross.
-
-
-File: configure.info, Node: Canadian Cross Example, Next: Canadian Cross Concepts, Up: Canadian Cross
-
-6.1 Canadian Cross Example
-==========================
-
-Here is an example of a Canadian Cross.
-
- While running on a GNU/Linux, you can build a program which will run
-on a Solaris system. You would use a GNU/Linux cross Solaris compiler
-to build the program.
-
- Of course, you could not run the resulting program on your GNU/Linux
-system. You would have to copy it over to a Solaris system before you
-would run it.
-
- Of course, you could also simply build the programs on the Solaris
-system in the first place. However, perhaps the Solaris system is not
-available for some reason; perhaps you actually don't have one, but you
-want to build the tools for somebody else to use. Or perhaps your
-GNU/Linux system is much faster than your Solaris system.
-
- A Canadian Cross build is most frequently used when building
-programs to run on a non-Unix system, such as DOS or Windows. It may
-be simpler to configure and build on a Unix system than to support the
-configuration machinery on a non-Unix system.
-
-
-File: configure.info, Node: Canadian Cross Concepts, Next: Build Cross Host Tools, Prev: Canadian Cross Example, Up: Canadian Cross
-
-6.2 Canadian Cross Concepts
-===========================
-
-When building a Canadian Cross, there are at least two different systems
-involved: the system on which the tools are being built, and the system
-on which the tools will run.
-
- The system on which the tools are being built is called the "build"
-system.
-
- The system on which the tools will run is called the host system.
-
- For example, if you are building a Solaris program on a GNU/Linux
-system, as in the previous section, the build system would be GNU/Linux,
-and the host system would be Solaris.
-
- It is, of course, possible to build a cross compiler using a Canadian
-Cross (i.e., build a cross compiler using a cross compiler). In this
-case, the system for which the resulting cross compiler generates code
-is called the target system. (For a more complete discussion of host
-and target systems, *note Host and Target::).
-
- An example of building a cross compiler using a Canadian Cross would
-be building a Windows cross MIPS ELF compiler on a GNU/Linux system. In
-this case the build system would be GNU/Linux, the host system would be
-Windows, and the target system would be MIPS ELF.
-
- The name Canadian Cross comes from the case when the build, host, and
-target systems are all different. At the time that these issues were
-all being hashed out, Canada had three national political parties.
-
-
-File: configure.info, Node: Build Cross Host Tools, Next: Build and Host Options, Prev: Canadian Cross Concepts, Up: Canadian Cross
-
-6.3 Build Cross Host Tools
-==========================
-
-In order to configure a program for a Canadian Cross build, you must
-first build and install the set of cross tools you will use to build the
-program.
-
- These tools will be build cross host tools. That is, they will run
-on the build system, and will produce code that runs on the host system.
-
- It is easy to confuse the meaning of build and host here. Always
-remember that the build system is where you are doing the build, and the
-host system is where the resulting program will run. Therefore, you
-need a build cross host compiler.
-
- In general, you must have a complete cross environment in order to do
-the build. This normally means a cross compiler, cross assembler, and
-so forth, as well as libraries and include files for the host system.
-
-
-File: configure.info, Node: Build and Host Options, Next: CCross not in Cygnus Tree, Prev: Build Cross Host Tools, Up: Canadian Cross
-
-6.4 Build and Host Options
-==========================
-
-When you run `configure', you must use both the `--build' and `--host'
-options.
-
- The `--build' option is used to specify the configuration name of
-the build system. This can normally be the result of running the
-`config.guess' shell script, and it is reasonable to use
-`--build=`config.guess`'.
-
- The `--host' option is used to specify the configuration name of the
-host system.
-
- As we explained earlier, `config.guess' is used to set the default
-value for the `--host' option (*note Using the Host Type::). We can
-now see that since `config.guess' returns the type of system on which
-it is run, it really identifies the build system. Since the host
-system is normally the same as the build system (i.e., people do not
-normally build using a cross compiler), it is reasonable to use the
-result of `config.guess' as the default for the host system when the
-`--host' option is not used.
-
- It might seem that if the `--host' option were used without the
-`--build' option that the configure script could run `config.guess' to
-determine the build system, and presume a Canadian Cross if the result
-of `config.guess' differed from the `--host' option. However, for
-historical reasons, some configure scripts are routinely run using an
-explicit `--host' option, rather than using the default from
-`config.guess'. As noted earlier, it is difficult or impossible to
-reliably compare configuration names (*note Using the Target Type::).
-Therefore, by convention, if the `--host' option is used, but the
-`--build' option is not used, then the build system defaults to the
-host system.
-
-
-File: configure.info, Node: CCross not in Cygnus Tree, Next: CCross in Cygnus Tree, Prev: Build and Host Options, Up: Canadian Cross
-
-6.5 Canadian Cross not in Cygnus Tree.
-======================================
-
-If you are not using the Cygnus tree, you must explicitly specify the
-cross tools which you want to use to build the program. This is done by
-setting environment variables before running the `configure' script.
-
- You must normally set at least the environment variables `CC', `AR',
-and `RANLIB' to the cross tools which you want to use to build.
-
- For some programs, you must set additional cross tools as well, such
-as `AS', `LD', or `NM'.
-
- You would set these environment variables to the build cross tools
-which you are going to use.
-
- For example, if you are building a Solaris program on a GNU/Linux
-system, and your GNU/Linux cross Solaris compiler were named
-`solaris-gcc', then you would set the environment variable `CC' to
-`solaris-gcc'.
-
-
-File: configure.info, Node: CCross in Cygnus Tree, Next: Supporting Canadian Cross, Prev: CCross not in Cygnus Tree, Up: Canadian Cross
-
-6.6 Canadian Cross in Cygnus Tree
-=================================
-
-This section describes configuring and building a Canadian Cross when
-using the Cygnus tree.
-
-* Menu:
-
-* Standard Cygnus CCross:: Building a Normal Program.
-* Cross Cygnus CCross:: Building a Cross Program.
-
-
-File: configure.info, Node: Standard Cygnus CCross, Next: Cross Cygnus CCross, Up: CCross in Cygnus Tree
-
-6.6.1 Building a Normal Program
--------------------------------
-
-When configuring a Canadian Cross in the Cygnus tree, all the
-appropriate environment variables are automatically set to `HOST-TOOL',
-where HOST is the value used for the `--host' option, and TOOL is the
-name of the tool (e.g., `gcc', `as', etc.). These tools must be on
-your `PATH'.
-
- Adding a prefix of HOST will give the usual name for the build cross
-host tools. To see this, consider that when these cross tools were
-built, they were configured to run on the build system and to produce
-code for the host system. That is, they were configured with a
-`--target' option that is the same as the system which we are now
-calling the host. Recall that the default name for installed cross
-tools uses the target system as a prefix (*note Using the Target
-Type::). Since that is the system which we are now calling the host,
-HOST is the right prefix to use.
-
- For example, if you configure with `--build=i386-linux-gnu' and
-`--host=solaris', then the Cygnus tree will automatically default to
-using the compiler `solaris-gcc'. You must have previously built and
-installed this compiler, probably by doing a build with no `--host'
-option and with a `--target' option of `solaris'.
-
-
-File: configure.info, Node: Cross Cygnus CCross, Prev: Standard Cygnus CCross, Up: CCross in Cygnus Tree
-
-6.6.2 Building a Cross Program
-------------------------------
-
-There are additional considerations if you want to build a cross
-compiler, rather than a native compiler, in the Cygnus tree using a
-Canadian Cross.
-
- When you build a cross compiler using the Cygnus tree, then the
-target libraries will normally be built with the newly built target
-compiler (*note Host and Target Libraries::). However, this will not
-work when building with a Canadian Cross. This is because the newly
-built target compiler will be a program which runs on the host system,
-and therefore will not be able to run on the build system.
-
- Therefore, when building a cross compiler with the Cygnus tree, you
-must first install a set of build cross target tools. These tools will
-be used when building the target libraries.
-
- Note that this is not a requirement of a Canadian Cross in general.
-For example, it would be possible to build just the host cross target
-tools on the build system, to copy the tools to the host system, and to
-build the target libraries on the host system. The requirement for
-build cross target tools is imposed by the Cygnus tree, which expects
-to be able to build both host programs and target libraries in a single
-`configure'/`make' step. Because it builds these in a single step, it
-expects to be able to build the target libraries on the build system,
-which means that it must use a build cross target toolchain.
-
- For example, suppose you want to build a Windows cross MIPS ELF
-compiler on a GNU/Linux system. You must have previously installed
-both a GNU/Linux cross Windows compiler and a GNU/Linux cross MIPS ELF
-compiler.
-
- In order to build the Windows (configuration name `i386-cygwin32')
-cross MIPS ELF (configure name `mips-elf') compiler, you might execute
-the following commands (long command lines are broken across lines with
-a trailing backslash as a continuation character).
-
- mkdir linux-x-cygwin32
- cd linux-x-cygwin32
- SRCDIR/configure --target i386-cygwin32 --prefix=INSTALLDIR \
- --exec-prefix=INSTALLDIR/H-i386-linux
- make
- make install
- cd ..
- mkdir linux-x-mips-elf
- cd linux-x-mips-elf
- SRCDIR/configure --target mips-elf --prefix=INSTALLDIR \
- --exec-prefix=INSTALLDIR/H-i386-linux
- make
- make install
- cd ..
- mkdir cygwin32-x-mips-elf
- cd cygwin32-x-mips-elf
- SRCDIR/configure --build=i386-linux-gnu --host=i386-cygwin32 \
- --target=mips-elf --prefix=WININSTALLDIR \
- --exec-prefix=WININSTALLDIR/H-i386-cygwin32
- make
- make install
-
- You would then copy the contents of WININSTALLDIR over to the
-Windows machine, and run the resulting programs.
-
-
-File: configure.info, Node: Supporting Canadian Cross, Prev: CCross in Cygnus Tree, Up: Canadian Cross
-
-6.7 Supporting Canadian Cross
-=============================
-
-If you want to make it possible to build a program you are developing
-using a Canadian Cross, you must take some care when writing your
-configure and make rules. Simple cases will normally work correctly.
-However, it is not hard to write configure and make tests which will
-fail in a Canadian Cross.
-
-* Menu:
-
-* CCross in Configure:: Supporting Canadian Cross in Configure Scripts.
-* CCross in Make:: Supporting Canadian Cross in Makefiles.
-
-
-File: configure.info, Node: CCross in Configure, Next: CCross in Make, Up: Supporting Canadian Cross
-
-6.7.1 Supporting Canadian Cross in Configure Scripts
-----------------------------------------------------
-
-In a `configure.in' file, after calling `AC_PROG_CC', you can find out
-whether this is a Canadian Cross configure by examining the shell
-variable `cross_compiling'. In a Canadian Cross, which means that the
-compiler is a cross compiler, `cross_compiling' will be `yes'. In a
-normal configuration, `cross_compiling' will be `no'.
-
- You ordinarily do not need to know the type of the build system in a
-configure script. However, if you do need that information, you can get
-it by using the macro `AC_CANONICAL_SYSTEM', the same macro that is
-used to determine the target system. This macro will set the variables
-`build', `build_alias', `build_cpu', `build_vendor', and `build_os',
-which correspond to the similar `target' and `host' variables, except
-that they describe the build system.
-
- When writing tests in `configure.in', you must remember that you
-want to test the host environment, not the build environment.
-
- Macros like `AC_CHECK_FUNCS' which use the compiler will test the
-host environment. That is because the tests will be done by running the
-compiler, which is actually a build cross host compiler. If the
-compiler can find the function, that means that the function is present
-in the host environment.
-
- Tests like `test -f /dev/ptyp0', on the other hand, will test the
-build environment. Remember that the configure script is running on the
-build system, not the host system. If your configure scripts examines
-files, those files will be on the build system. Whatever you determine
-based on those files may or may not be the case on the host system.
-
- Most autoconf macros will work correctly for a Canadian Cross. The
-main exception is `AC_TRY_RUN'. This macro tries to compile and run a
-test program. This will fail in a Canadian Cross, because the program
-will be compiled for the host system, which means that it will not run
-on the build system.
-
- The `AC_TRY_RUN' macro provides an optional argument to tell the
-configure script what to do in a Canadian Cross. If that argument is
-not present, you will get a warning when you run `autoconf':
- warning: AC_TRY_RUN called without default to allow cross compiling
- This tells you that the resulting `configure' script will not work
-with a Canadian Cross.
-
- In some cases while it may better to perform a test at configure
-time, it is also possible to perform the test at run time. In such a
-case you can use the cross compiling argument to `AC_TRY_RUN' to tell
-your program that the test could not be performed at configure time.
-
- There are a few other autoconf macros which will not work correctly
-with a Canadian Cross: a partial list is `AC_FUNC_GETPGRP',
-`AC_FUNC_SETPGRP', `AC_FUNC_SETVBUF_REVERSED', and
-`AC_SYS_RESTARTABLE_SYSCALLS'. The `AC_CHECK_SIZEOF' macro is
-generally not very useful with a Canadian Cross; it permits an optional
-argument indicating the default size, but there is no way to know what
-the correct default should be.
-
-
-File: configure.info, Node: CCross in Make, Prev: CCross in Configure, Up: Supporting Canadian Cross
-
-6.7.2 Supporting Canadian Cross in Makefiles.
----------------------------------------------
-
-The main Canadian Cross issue in a `Makefile' arises when you want to
-use a subsidiary program to generate code or data which you will then
-include in your real program.
-
- If you compile this subsidiary program using `$(CC)' in the usual
-way, you will not be able to run it. This is because `$(CC)' will
-build a program for the host system, but the program is being built on
-the build system.
-
- You must instead use a compiler for the build system, rather than the
-host system. In the Cygnus tree, this make variable `$(CC_FOR_BUILD)'
-will hold a compiler for the build system.
-
- Note that you should not include `config.h' in a file you are
-compiling with `$(CC_FOR_BUILD)'. The `configure' script will build
-`config.h' with information for the host system. However, you are
-compiling the file using a compiler for the build system (a native
-compiler). Subsidiary programs are normally simple filters which do no
-user interaction, and it is normally possible to write them in a highly
-portable fashion so that the absence of `config.h' is not crucial.
-
- The gcc `Makefile.in' shows a complex situation in which certain
-files, such as `rtl.c', must be compiled into both subsidiary programs
-run on the build system and into the final program. This approach may
-be of interest for advanced build system hackers. Note that the build
-system compiler is rather confusingly called `HOST_CC'.
-
-
-File: configure.info, Node: Cygnus Configure, Next: Multilibs, Prev: Canadian Cross, Up: Top
-
-7 Cygnus Configure
-******************
-
-The Cygnus configure script predates autoconf. All of its interesting
-features have been incorporated into autoconf. No new programs should
-be written to use the Cygnus configure script.
-
- However, the Cygnus configure script is still used in a few places:
-at the top of the Cygnus tree and in a few target libraries in the
-Cygnus tree. Until those uses have been replaced with autoconf, some
-brief notes are appropriate here. This is not complete documentation,
-but it should be possible to use this as a guide while examining the
-scripts themselves.
-
-* Menu:
-
-* Cygnus Configure Basics:: Cygnus Configure Basics.
-* Cygnus Configure in C++ Libraries:: Cygnus Configure in C++ Libraries.
-
-
-File: configure.info, Node: Cygnus Configure Basics, Next: Cygnus Configure in C++ Libraries, Up: Cygnus Configure
-
-7.1 Cygnus Configure Basics
-===========================
-
-Cygnus configure does not use any generated files; there is no program
-corresponding to `autoconf'. Instead, there is a single shell script
-named `configure' which may be found at the top of the Cygnus tree.
-This shell script was written by hand; it was not generated by
-autoconf, and it is incorrect, and indeed harmful, to run `autoconf' in
-the top level of a Cygnus tree.
-
- Cygnus configure works in a particular directory by examining the
-file `configure.in' in that directory. That file is broken into four
-separate shell scripts.
-
- The first is the contents of `configure.in' up to a line that starts
-with `# per-host:'. This is the common part.
-
- The second is the rest of `configure.in' up to a line that starts
-with `# per-target:'. This is the per host part.
-
- The third is the rest of `configure.in' up to a line that starts
-with `# post-target:'. This is the per target part.
-
- The fourth is the remainder of `configure.in'. This is the post
-target part.
-
- If any of these comment lines are missing, the corresponding shell
-script is empty.
-
- Cygnus configure will first execute the common part. This must set
-the shell variable `srctrigger' to the name of a source file, to
-confirm that Cygnus configure is looking at the right directory. This
-may set the shell variables `package_makefile_frag' and
-`package_makefile_rules_frag'.
-
- Cygnus configure will next set the `build' and `host' shell
-variables, and execute the per host part. This may set the shell
-variable `host_makefile_frag'.
-
- Cygnus configure will next set the `target' variable, and execute
-the per target part. This may set the shell variable
-`target_makefile_frag'.
-
- Any of these scripts may set the `subdirs' shell variable. This
-variable is a list of subdirectories where a `Makefile.in' file may be
-found. Cygnus configure will automatically look for a `Makefile.in'
-file in the current directory. The `subdirs' shell variable is not
-normally used, and I believe that the only directory which uses it at
-present is `newlib'.
-
- For each `Makefile.in', Cygnus configure will automatically create a
-`Makefile' by adding definitions for `make' variables such as `host'
-and `target', and automatically editing the values of `make' variables
-such as `prefix' if they are present.
-
- Also, if any of the `makefile_frag' shell variables are set, Cygnus
-configure will interpret them as file names relative to either the
-working directory or the source directory, and will read the contents of
-the file into the generated `Makefile'. The file contents will be read
-in after the first line in `Makefile.in' which starts with `####'.
-
- These `Makefile' fragments are used to customize behaviour for a
-particular host or target. They serve to select particular files to
-compile, and to define particular preprocessor macros by providing
-values for `make' variables which are then used during compilation.
-Cygnus configure, unlike autoconf, normally does not do feature tests,
-and normally requires support to be added manually for each new host.
-
- The `Makefile' fragment support is similar to the autoconf
-`AC_SUBST_FILE' macro.
-
- After creating each `Makefile', the post target script will be run
-(i.e., it may be run several times). This script may further customize
-the `Makefile'. When it is run, the shell variable `Makefile' will
-hold the name of the `Makefile', including the appropriate directory
-component.
-
- Like an autoconf generated `configure' script, Cygnus configure will
-create a file named `config.status' which, when run, will automatically
-recreate the configuration. The `config.status' file will simply
-execute the Cygnus configure script again with the appropriate
-arguments.
-
- Any of the parts of `configure.in' may set the shell variables
-`files' and `links'. Cygnus configure will set up symlinks from the
-names in `links' to the files named in `files'. This is similar to the
-autoconf `AC_LINK_FILES' macro.
-
- Finally, any of the parts of `configure.in' may set the shell
-variable `configdirs' to a set of subdirectories. If it is set, Cygnus
-configure will recursively run the configure process in each
-subdirectory. If the subdirectory uses Cygnus configure, it will
-contain a `configure.in' file but no `configure' file, in which case
-Cygnus configure will invoke itself recursively. If the subdirectory
-has a `configure' file, Cygnus configure assumes that it is an autoconf
-generated `configure' script, and simply invokes it directly.
-
-
-File: configure.info, Node: Cygnus Configure in C++ Libraries, Prev: Cygnus Configure Basics, Up: Cygnus Configure
-
-7.2 Cygnus Configure in C++ Libraries
-=====================================
-
-The C++ library configure system, written by Per Bothner, deserves
-special mention. It uses Cygnus configure, but it does feature testing
-like that done by autoconf generated `configure' scripts. This
-approach is used in the libraries `libio', `libstdc++', and `libg++'.
-
- Most of the `Makefile' information is written out by the shell
-script `libio/config.shared'. Each `configure.in' file sets certain
-shell variables, and then invokes `config.shared' to create two package
-`Makefile' fragments. These fragments are then incorporated into the
-resulting `Makefile' by the Cygnus configure script.
-
- The file `_G_config.h' is created in the `libio' object directory by
-running the shell script `libio/gen-params'. This shell script uses
-feature tests to define macros and typedefs in `_G_config.h'.
-
-
-File: configure.info, Node: Multilibs, Next: FAQ, Prev: Cygnus Configure, Up: Top
-
-8 Multilibs
-***********
-
-For some targets gcc may have different processor requirements depending
-upon command line options. An obvious example is the `-msoft-float'
-option supported on several processors. This option means that the
-floating point registers are not available, which means that floating
-point operations must be done by calling an emulation subroutine rather
-than by using machine instructions.
-
- For such options, gcc is often configured to compile target libraries
-twice: once with `-msoft-float' and once without. When gcc compiles
-target libraries more than once, the resulting libraries are called
-"multilibs".
-
- Multilibs are not really part of the GNU configure and build system,
-but we discuss them here since they require support in the `configure'
-scripts and `Makefile's used for target libraries.
-
-* Menu:
-
-* Multilibs in gcc:: Multilibs in gcc.
-* Multilibs in Target Libraries:: Multilibs in Target Libraries.
-
-
-File: configure.info, Node: Multilibs in gcc, Next: Multilibs in Target Libraries, Up: Multilibs
-
-8.1 Multilibs in gcc
-====================
-
-In gcc, multilibs are defined by setting the variable
-`MULTILIB_OPTIONS' in the target `Makefile' fragment. Several other
-`MULTILIB' variables may also be defined there. *Note The Target
-Makefile Fragment: (gcc)Target Fragment.
-
- If you have built gcc, you can see what multilibs it uses by running
-it with the `-print-multi-lib' option. The output `.;' means that no
-multilibs are used. In general, the output is a sequence of lines, one
-per multilib. The first part of each line, up to the `;', is the name
-of the multilib directory. The second part is a list of compiler
-options separated by `@' characters.
-
- Multilibs are built in a tree of directories. The top of the tree,
-represented by `.' in the list of multilib directories, is the default
-library to use when no special compiler options are used. The
-subdirectories of the tree hold versions of the library to use when
-particular compiler options are used.
-
-
-File: configure.info, Node: Multilibs in Target Libraries, Prev: Multilibs in gcc, Up: Multilibs
-
-8.2 Multilibs in Target Libraries
-=================================
-
-The target libraries in the Cygnus tree are automatically built with
-multilibs. That means that each library is built multiple times.
-
- This default is set in the top level `configure.in' file, by adding
-`--enable-multilib' to the list of arguments passed to configure when
-it is run for the target libraries (*note Host and Target Libraries::).
-
- Each target library uses the shell script `config-ml.in', written by
-Doug Evans, to prepare to build target libraries. This shell script is
-invoked after the `Makefile' has been created by the `configure'
-script. If multilibs are not enabled, it does nothing, otherwise it
-modifies the `Makefile' to support multilibs.
-
- The `config-ml.in' script makes one copy of the `Makefile' for each
-multilib in the appropriate subdirectory. When configuring in the
-source directory (which is not recommended), it will build a symlink
-tree of the sources in each subdirectory.
-
- The `config-ml.in' script sets several variables in the various
-`Makefile's. The `Makefile.in' must have definitions for these
-variables already; `config-ml.in' simply changes the existing values.
-The `Makefile' should use default values for these variables which will
-do the right thing in the subdirectories.
-
-`MULTISRCTOP'
- `config-ml.in' will set this to a sequence of `../' strings, where
- the number of strings is the number of multilib levels in the
- source tree. The default value should be the empty string.
-
-`MULTIBUILDTOP'
- `config-ml.in' will set this to a sequence of `../' strings, where
- the number of strings is number of multilib levels in the object
- directory. The default value should be the empty string. This
- will differ from `MULTISRCTOP' when configuring in the source tree
- (which is not recommended).
-
-`MULTIDIRS'
- In the top level `Makefile' only, `config-ml.in' will set this to
- the list of multilib subdirectories. The default value should be
- the empty string.
-
-`MULTISUBDIR'
- `config-ml.in' will set this to the installed subdirectory name to
- use for this subdirectory, with a leading `/'. The default value
- shold be the empty string.
-
-`MULTIDO'
-`MULTICLEAN'
- In the top level `Makefile' only, `config-ml.in' will set these
- variables to commands to use when doing a recursive make. These
- variables should both default to the string `true', so that by
- default nothing happens.
-
- All references to the parent of the source directory should use the
-variable `MULTISRCTOP'. Instead of writing `$(srcdir)/..', you must
-write `$(srcdir)/$(MULTISRCTOP)..'.
-
- Similarly, references to the parent of the object directory should
-use the variable `MULTIBUILDTOP'.
-
- In the installation target, the libraries should be installed in the
-subdirectory `MULTISUBDIR'. Instead of installing
-`$(libdir)/libfoo.a', install `$(libdir)$(MULTISUBDIR)/libfoo.a'.
-
- The `config-ml.in' script also modifies the top level `Makefile' to
-add `multi-do' and `multi-clean' targets which are used when building
-multilibs.
-
- The default target of the `Makefile' should include the following
-command:
- @$(MULTIDO) $(FLAGS_TO_PASS) DO=all multi-do
- This assumes that `$(FLAGS_TO_PASS)' is defined as a set of
-variables to pass to a recursive invocation of `make'. This will build
-all the multilibs. Note that the default value of `MULTIDO' is `true',
-so by default this command will do nothing. It will only do something
-in the top level `Makefile' if multilibs were enabled.
-
- The `install' target of the `Makefile' should include the following
-command:
- @$(MULTIDO) $(FLAGS_TO_PASS) DO=install multi-do
-
- In general, any operation, other than clean, which should be
-performed on all the multilibs should use a `$(MULTIDO)' line, setting
-the variable `DO' to the target of each recursive call to `make'.
-
- The `clean' targets (`clean', `mostlyclean', etc.) should use
-`$(MULTICLEAN)'. For example, the `clean' target should do this:
- @$(MULTICLEAN) DO=clean multi-clean
-
-
-File: configure.info, Node: FAQ, Next: Index, Prev: Multilibs, Up: Top
-
-9 Frequently Asked Questions
-****************************
-
-Which do I run first, `autoconf' or `automake'?
- Except when you first add autoconf or automake support to a
- package, you shouldn't run either by hand. Instead, configure
- with the `--enable-maintainer-mode' option, and let `make' take
- care of it.
-
-`autoconf' says something about undefined macros.
- This means that you have macros in your `configure.in' which are
- not defined by `autoconf'. You may be using an old version of
- `autoconf'; try building and installing a newer one. Make sure the
- newly installled `autoconf' is first on your `PATH'. Also, see
- the next question.
-
-My `configure' script has stuff like `CY_GNU_GETTEXT' in it.
- This means that you have macros in your `configure.in' which should
- be defined in your `aclocal.m4' file, but aren't. This usually
- means that `aclocal' was not able to appropriate definitions of the
- macros. Make sure that you have installed all the packages you
- need. In particular, make sure that you have installed libtool
- (this is where `AM_PROG_LIBTOOL' is defined) and gettext (this is
- where `CY_GNU_GETTEXT' is defined, at least in the Cygnus version
- of gettext).
-
-My `Makefile' has `@' characters in it.
- This may mean that you tried to use an autoconf substitution in
- your `Makefile.in' without adding the appropriate `AC_SUBST' call
- to your `configure' script. Or it may just mean that you need to
- rebuild `Makefile' in your build directory. To rebuild `Makefile'
- from `Makefile.in', run the shell script `config.status' with no
- arguments. If you need to force `configure' to run again, first
- run `config.status --recheck'. These runs are normally done
- automatically by `Makefile' targets, but if your `Makefile' has
- gotten messed up you'll need to help them along.
-
-Why do I have to run both `config.status --recheck' and `config.status'?
- Normally, you don't; they will be run automatically by `Makefile'
- targets. If you do need to run them, use `config.status --recheck'
- to run the `configure' script again with the same arguments as the
- first time you ran it. Use `config.status' (with no arguments) to
- regenerate all files (`Makefile', `config.h', etc.) based on the
- results of the configure script. The two cases are separate
- because it isn't always necessary to regenerate all the files
- after running `config.status --recheck'. The `Makefile' targets
- generated by automake will use the environment variables
- `CONFIG_FILES' and `CONFIG_HEADERS' to only regenerate files as
- they are needed.
-
-What is the Cygnus tree?
- The Cygnus tree is used for various packages including gdb, the GNU
- binutils, and egcs. It is also, of course, used for Cygnus
- releases. It is the build system which was developed at Cygnus,
- using the Cygnus configure script. It permits building many
- different packages with a single configure and make. The
- configure scripts in the tree are being converted to autoconf, but
- the general build structure remains intact.
-
-Why do I have to keep rebuilding and reinstalling the tools?
- I know, it's a pain. Unfortunately, there are bugs in the tools
- themselves which need to be fixed, and each time that happens
- everybody who uses the tools need to reinstall new versions of
- them. I don't know if there is going to be a clever fix until the
- tools stabilize.
-
-Why not just have a Cygnus tree `make' target to update the tools?
- The tools unfortunately need to be installed before they can be
- used. That means that they must be built using an appropriate
- prefix, and it seems unwise to assume that every configuration
- uses an appropriate prefix. It might be possible to make them
- work in place, or it might be possible to install them in some
- subdirectory; so far these approaches have not been implemented.
-
-
-File: configure.info, Node: Index, Prev: FAQ, Up: Top
-
-Index
-*****
-
-
-* Menu:
-
-* --build option: Build and Host Options.
- (line 9)
-* --host option: Build and Host Options.
- (line 14)
-* --target option: Specifying the Target.
- (line 10)
-* _GNU_SOURCE: Write configure.in. (line 134)
-* AC_CANONICAL_HOST: Using the Host Type. (line 10)
-* AC_CANONICAL_SYSTEM: Using the Target Type.
- (line 6)
-* AC_CONFIG_HEADER: Write configure.in. (line 66)
-* AC_EXEEXT: Write configure.in. (line 86)
-* AC_INIT: Write configure.in. (line 38)
-* AC_OUTPUT: Write configure.in. (line 142)
-* AC_PREREQ: Write configure.in. (line 42)
-* AC_PROG_CC: Write configure.in. (line 103)
-* AC_PROG_CXX: Write configure.in. (line 117)
-* acconfig.h: Written Developer Files.
- (line 27)
-* acconfig.h, writing: Write acconfig.h. (line 6)
-* acinclude.m4: Written Developer Files.
- (line 37)
-* aclocal.m4: Generated Developer Files.
- (line 33)
-* AM_CONFIG_HEADER: Write configure.in. (line 53)
-* AM_DISABLE_SHARED: Write configure.in. (line 127)
-* AM_EXEEXT: Write configure.in. (line 86)
-* AM_INIT_AUTOMAKE: Write configure.in. (line 48)
-* AM_MAINTAINER_MODE: Write configure.in. (line 70)
-* AM_PROG_LIBTOOL: Write configure.in. (line 122)
-* AM_PROG_LIBTOOL in configure: FAQ. (line 19)
-* build option: Build and Host Options.
- (line 9)
-* building with a cross compiler: Canadian Cross. (line 6)
-* canadian cross: Canadian Cross. (line 6)
-* canadian cross in configure: CCross in Configure. (line 6)
-* canadian cross in cygnus tree: CCross in Cygnus Tree.
- (line 6)
-* canadian cross in makefile: CCross in Make. (line 6)
-* canadian cross, configuring: Build and Host Options.
- (line 6)
-* canonical system names: Configuration Names. (line 6)
-* config.cache: Build Files Description.
- (line 28)
-* config.h: Build Files Description.
- (line 23)
-* config.h.in: Generated Developer Files.
- (line 45)
-* config.in: Generated Developer Files.
- (line 45)
-* config.status: Build Files Description.
- (line 9)
-* config.status --recheck: FAQ. (line 40)
-* configuration names: Configuration Names. (line 6)
-* configuration triplets: Configuration Names. (line 6)
-* configure: Generated Developer Files.
- (line 21)
-* configure build system: Build and Host Options.
- (line 9)
-* configure host: Build and Host Options.
- (line 14)
-* configure target: Specifying the Target.
- (line 10)
-* configure.in: Written Developer Files.
- (line 9)
-* configure.in, writing: Write configure.in. (line 6)
-* configuring a canadian cross: Build and Host Options.
- (line 6)
-* cross compiler: Cross Compilation Concepts.
- (line 6)
-* cross compiler, building with: Canadian Cross. (line 6)
-* cross tools: Cross Compilation Tools.
- (line 6)
-* CY_GNU_GETTEXT in configure: FAQ. (line 19)
-* cygnus configure: Cygnus Configure. (line 6)
-* goals: Goals. (line 6)
-* history: History. (line 6)
-* host names: Configuration Names. (line 6)
-* host option: Build and Host Options.
- (line 14)
-* host system: Host and Target. (line 6)
-* host triplets: Configuration Names. (line 6)
-* HOST_CC: CCross in Make. (line 27)
-* libg++ configure: Cygnus Configure in C++ Libraries.
- (line 6)
-* libio configure: Cygnus Configure in C++ Libraries.
- (line 6)
-* libstdc++ configure: Cygnus Configure in C++ Libraries.
- (line 6)
-* Makefile: Build Files Description.
- (line 18)
-* Makefile, garbage characters: FAQ. (line 29)
-* Makefile.am: Written Developer Files.
- (line 18)
-* Makefile.am, writing: Write Makefile.am. (line 6)
-* Makefile.in: Generated Developer Files.
- (line 26)
-* multilibs: Multilibs. (line 6)
-* stamp-h: Build Files Description.
- (line 41)
-* stamp-h.in: Generated Developer Files.
- (line 54)
-* system names: Configuration Names. (line 6)
-* system types: Configuration Names. (line 6)
-* target option: Specifying the Target.
- (line 10)
-* target system: Host and Target. (line 6)
-* triplets: Configuration Names. (line 6)
-* undefined macros: FAQ. (line 12)
-
-
-
-Tag Table:
-Node: Top1039
-Node: Introduction1567
-Node: Goals2649
-Node: Tools3373
-Node: History4367
-Node: Building7365
-Node: Getting Started10628
-Node: Write configure.in11141
-Node: Write Makefile.am18392
-Node: Write acconfig.h21569
-Node: Generate files23106
-Node: Getting Started Example25072
-Node: Getting Started Example 125827
-Node: Getting Started Example 227748
-Node: Getting Started Example 330743
-Node: Generate Files in Example33107
-Node: Files34197
-Node: Developer Files34808
-Node: Developer Files Picture35188
-Node: Written Developer Files36476
-Node: Generated Developer Files39028
-Node: Build Files42172
-Node: Build Files Picture42833
-Node: Build Files Description43597
-Node: Support Files45603
-Node: Configuration Names48485
-Node: Configuration Name Definition48985
-Node: Using Configuration Names51308
-Node: Cross Compilation Tools53278
-Node: Cross Compilation Concepts53969
-Node: Host and Target54937
-Node: Using the Host Type56438
-Node: Specifying the Target57787
-Node: Using the Target Type58576
-Node: Cross Tools in the Cygnus Tree62007
-Node: Host and Target Libraries63064
-Node: Target Library Configure Scripts66813
-Node: Make Targets in Cygnus Tree69905
-Node: Target libiberty71253
-Node: Canadian Cross72640
-Node: Canadian Cross Example73481
-Node: Canadian Cross Concepts74600
-Node: Build Cross Host Tools76112
-Node: Build and Host Options77064
-Node: CCross not in Cygnus Tree78850
-Node: CCross in Cygnus Tree79828
-Node: Standard Cygnus CCross80249
-Node: Cross Cygnus CCross81613
-Node: Supporting Canadian Cross84413
-Node: CCross in Configure85028
-Node: CCross in Make88196
-Node: Cygnus Configure89799
-Node: Cygnus Configure Basics90634
-Node: Cygnus Configure in C++ Libraries95312
-Node: Multilibs96319
-Node: Multilibs in gcc97364
-Node: Multilibs in Target Libraries98442
-Node: FAQ102633
-Node: Index106733
-
-End Tag Table
diff --git a/share/info/cpp.info b/share/info/cpp.info
deleted file mode 100644
index de964c4..0000000
--- a/share/info/cpp.info
+++ /dev/null
@@ -1,5549 +0,0 @@
-This is doc/cpp.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gcc/gcc-4.6/gcc/doc/cpp.texi.
-
-Copyright (C) 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1996, 1997,
-1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
-2010, 2011 Free Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation. A copy of
-the license is included in the section entitled "GNU Free Documentation
-License".
-
- This manual contains no Invariant Sections. The Front-Cover Texts
-are (a) (see below), and the Back-Cover Texts are (b) (see below).
-
- (a) The FSF's Front-Cover Text is:
-
- A GNU Manual
-
- (b) The FSF's Back-Cover Text is:
-
- You have freedom to copy and modify this GNU Manual, like GNU
-software. Copies published by the Free Software Foundation raise
-funds for GNU development.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* Cpp: (cpp). The GNU C preprocessor.
-END-INFO-DIR-ENTRY
-
-
-File: cpp.info, Node: Top, Next: Overview, Up: (dir)
-
-The C Preprocessor
-******************
-
-The C preprocessor implements the macro language used to transform C,
-C++, and Objective-C programs before they are compiled. It can also be
-useful on its own.
-
-* Menu:
-
-* Overview::
-* Header Files::
-* Macros::
-* Conditionals::
-* Diagnostics::
-* Line Control::
-* Pragmas::
-* Other Directives::
-* Preprocessor Output::
-* Traditional Mode::
-* Implementation Details::
-* Invocation::
-* Environment Variables::
-* GNU Free Documentation License::
-* Index of Directives::
-* Option Index::
-* Concept Index::
-
- --- The Detailed Node Listing ---
-
-Overview
-
-* Character sets::
-* Initial processing::
-* Tokenization::
-* The preprocessing language::
-
-Header Files
-
-* Include Syntax::
-* Include Operation::
-* Search Path::
-* Once-Only Headers::
-* Alternatives to Wrapper #ifndef::
-* Computed Includes::
-* Wrapper Headers::
-* System Headers::
-
-Macros
-
-* Object-like Macros::
-* Function-like Macros::
-* Macro Arguments::
-* Stringification::
-* Concatenation::
-* Variadic Macros::
-* Predefined Macros::
-* Undefining and Redefining Macros::
-* Directives Within Macro Arguments::
-* Macro Pitfalls::
-
-Predefined Macros
-
-* Standard Predefined Macros::
-* Common Predefined Macros::
-* System-specific Predefined Macros::
-* C++ Named Operators::
-
-Macro Pitfalls
-
-* Misnesting::
-* Operator Precedence Problems::
-* Swallowing the Semicolon::
-* Duplication of Side Effects::
-* Self-Referential Macros::
-* Argument Prescan::
-* Newlines in Arguments::
-
-Conditionals
-
-* Conditional Uses::
-* Conditional Syntax::
-* Deleted Code::
-
-Conditional Syntax
-
-* Ifdef::
-* If::
-* Defined::
-* Else::
-* Elif::
-
-Implementation Details
-
-* Implementation-defined behavior::
-* Implementation limits::
-* Obsolete Features::
-* Differences from previous versions::
-
-Obsolete Features
-
-* Obsolete Features::
-
- Copyright (C) 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1996, 1997,
-1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
-2010, 2011 Free Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation. A copy of
-the license is included in the section entitled "GNU Free Documentation
-License".
-
- This manual contains no Invariant Sections. The Front-Cover Texts
-are (a) (see below), and the Back-Cover Texts are (b) (see below).
-
- (a) The FSF's Front-Cover Text is:
-
- A GNU Manual
-
- (b) The FSF's Back-Cover Text is:
-
- You have freedom to copy and modify this GNU Manual, like GNU
-software. Copies published by the Free Software Foundation raise
-funds for GNU development.
-
-
-File: cpp.info, Node: Overview, Next: Header Files, Prev: Top, Up: Top
-
-1 Overview
-**********
-
-The C preprocessor, often known as "cpp", is a "macro processor" that
-is used automatically by the C compiler to transform your program
-before compilation. It is called a macro processor because it allows
-you to define "macros", which are brief abbreviations for longer
-constructs.
-
- The C preprocessor is intended to be used only with C, C++, and
-Objective-C source code. In the past, it has been abused as a general
-text processor. It will choke on input which does not obey C's lexical
-rules. For example, apostrophes will be interpreted as the beginning of
-character constants, and cause errors. Also, you cannot rely on it
-preserving characteristics of the input which are not significant to
-C-family languages. If a Makefile is preprocessed, all the hard tabs
-will be removed, and the Makefile will not work.
-
- Having said that, you can often get away with using cpp on things
-which are not C. Other Algol-ish programming languages are often safe
-(Pascal, Ada, etc.) So is assembly, with caution. `-traditional-cpp'
-mode preserves more white space, and is otherwise more permissive. Many
-of the problems can be avoided by writing C or C++ style comments
-instead of native language comments, and keeping macros simple.
-
- Wherever possible, you should use a preprocessor geared to the
-language you are writing in. Modern versions of the GNU assembler have
-macro facilities. Most high level programming languages have their own
-conditional compilation and inclusion mechanism. If all else fails,
-try a true general text processor, such as GNU M4.
-
- C preprocessors vary in some details. This manual discusses the GNU
-C preprocessor, which provides a small superset of the features of ISO
-Standard C. In its default mode, the GNU C preprocessor does not do a
-few things required by the standard. These are features which are
-rarely, if ever, used, and may cause surprising changes to the meaning
-of a program which does not expect them. To get strict ISO Standard C,
-you should use the `-std=c90', `-std=c99' or `-std=c1x' options,
-depending on which version of the standard you want. To get all the
-mandatory diagnostics, you must also use `-pedantic'. *Note
-Invocation::.
-
- This manual describes the behavior of the ISO preprocessor. To
-minimize gratuitous differences, where the ISO preprocessor's behavior
-does not conflict with traditional semantics, the traditional
-preprocessor should behave the same way. The various differences that
-do exist are detailed in the section *note Traditional Mode::.
-
- For clarity, unless noted otherwise, references to `CPP' in this
-manual refer to GNU CPP.
-
-* Menu:
-
-* Character sets::
-* Initial processing::
-* Tokenization::
-* The preprocessing language::
-
-
-File: cpp.info, Node: Character sets, Next: Initial processing, Up: Overview
-
-1.1 Character sets
-==================
-
-Source code character set processing in C and related languages is
-rather complicated. The C standard discusses two character sets, but
-there are really at least four.
-
- The files input to CPP might be in any character set at all. CPP's
-very first action, before it even looks for line boundaries, is to
-convert the file into the character set it uses for internal
-processing. That set is what the C standard calls the "source"
-character set. It must be isomorphic with ISO 10646, also known as
-Unicode. CPP uses the UTF-8 encoding of Unicode.
-
- The character sets of the input files are specified using the
-`-finput-charset=' option.
-
- All preprocessing work (the subject of the rest of this manual) is
-carried out in the source character set. If you request textual output
-from the preprocessor with the `-E' option, it will be in UTF-8.
-
- After preprocessing is complete, string and character constants are
-converted again, into the "execution" character set. This character
-set is under control of the user; the default is UTF-8, matching the
-source character set. Wide string and character constants have their
-own character set, which is not called out specifically in the
-standard. Again, it is under control of the user. The default is
-UTF-16 or UTF-32, whichever fits in the target's `wchar_t' type, in the
-target machine's byte order.(1) Octal and hexadecimal escape sequences
-do not undergo conversion; '\x12' has the value 0x12 regardless of the
-currently selected execution character set. All other escapes are
-replaced by the character in the source character set that they
-represent, then converted to the execution character set, just like
-unescaped characters.
-
- Unless the experimental `-fextended-identifiers' option is used, GCC
-does not permit the use of characters outside the ASCII range, nor `\u'
-and `\U' escapes, in identifiers. Even with that option, characters
-outside the ASCII range can only be specified with the `\u' and `\U'
-escapes, not used directly in identifiers.
-
- ---------- Footnotes ----------
-
- (1) UTF-16 does not meet the requirements of the C standard for a
-wide character set, but the choice of 16-bit `wchar_t' is enshrined in
-some system ABIs so we cannot fix this.
-
-
-File: cpp.info, Node: Initial processing, Next: Tokenization, Prev: Character sets, Up: Overview
-
-1.2 Initial processing
-======================
-
-The preprocessor performs a series of textual transformations on its
-input. These happen before all other processing. Conceptually, they
-happen in a rigid order, and the entire file is run through each
-transformation before the next one begins. CPP actually does them all
-at once, for performance reasons. These transformations correspond
-roughly to the first three "phases of translation" described in the C
-standard.
-
- 1. The input file is read into memory and broken into lines.
-
- Different systems use different conventions to indicate the end of
- a line. GCC accepts the ASCII control sequences `LF', `CR LF' and
- `CR' as end-of-line markers. These are the canonical sequences
- used by Unix, DOS and VMS, and the classic Mac OS (before OSX)
- respectively. You may therefore safely copy source code written
- on any of those systems to a different one and use it without
- conversion. (GCC may lose track of the current line number if a
- file doesn't consistently use one convention, as sometimes happens
- when it is edited on computers with different conventions that
- share a network file system.)
-
- If the last line of any input file lacks an end-of-line marker,
- the end of the file is considered to implicitly supply one. The C
- standard says that this condition provokes undefined behavior, so
- GCC will emit a warning message.
-
- 2. If trigraphs are enabled, they are replaced by their corresponding
- single characters. By default GCC ignores trigraphs, but if you
- request a strictly conforming mode with the `-std' option, or you
- specify the `-trigraphs' option, then it converts them.
-
- These are nine three-character sequences, all starting with `??',
- that are defined by ISO C to stand for single characters. They
- permit obsolete systems that lack some of C's punctuation to use
- C. For example, `??/' stands for `\', so '??/n' is a character
- constant for a newline.
-
- Trigraphs are not popular and many compilers implement them
- incorrectly. Portable code should not rely on trigraphs being
- either converted or ignored. With `-Wtrigraphs' GCC will warn you
- when a trigraph may change the meaning of your program if it were
- converted. *Note Wtrigraphs::.
-
- In a string constant, you can prevent a sequence of question marks
- from being confused with a trigraph by inserting a backslash
- between the question marks, or by separating the string literal at
- the trigraph and making use of string literal concatenation.
- "(??\?)" is the string `(???)', not `(?]'. Traditional C
- compilers do not recognize these idioms.
-
- The nine trigraphs and their replacements are
-
- Trigraph: ??( ??) ??< ??> ??= ??/ ??' ??! ??-
- Replacement: [ ] { } # \ ^ | ~
-
- 3. Continued lines are merged into one long line.
-
- A continued line is a line which ends with a backslash, `\'. The
- backslash is removed and the following line is joined with the
- current one. No space is inserted, so you may split a line
- anywhere, even in the middle of a word. (It is generally more
- readable to split lines only at white space.)
-
- The trailing backslash on a continued line is commonly referred to
- as a "backslash-newline".
-
- If there is white space between a backslash and the end of a line,
- that is still a continued line. However, as this is usually the
- result of an editing mistake, and many compilers will not accept
- it as a continued line, GCC will warn you about it.
-
- 4. All comments are replaced with single spaces.
-
- There are two kinds of comments. "Block comments" begin with `/*'
- and continue until the next `*/'. Block comments do not nest:
-
- /* this is /* one comment */ text outside comment
-
- "Line comments" begin with `//' and continue to the end of the
- current line. Line comments do not nest either, but it does not
- matter, because they would end in the same place anyway.
-
- // this is // one comment
- text outside comment
-
- It is safe to put line comments inside block comments, or vice versa.
-
- /* block comment
- // contains line comment
- yet more comment
- */ outside comment
-
- // line comment /* contains block comment */
-
- But beware of commenting out one end of a block comment with a line
-comment.
-
- // l.c. /* block comment begins
- oops! this isn't a comment anymore */
-
- Comments are not recognized within string literals. "/* blah */" is
-the string constant `/* blah */', not an empty string.
-
- Line comments are not in the 1989 edition of the C standard, but they
-are recognized by GCC as an extension. In C++ and in the 1999 edition
-of the C standard, they are an official part of the language.
-
- Since these transformations happen before all other processing, you
-can split a line mechanically with backslash-newline anywhere. You can
-comment out the end of a line. You can continue a line comment onto the
-next line with backslash-newline. You can even split `/*', `*/', and
-`//' onto multiple lines with backslash-newline. For example:
-
- /\
- *
- */ # /*
- */ defi\
- ne FO\
- O 10\
- 20
-
-is equivalent to `#define FOO 1020'. All these tricks are extremely
-confusing and should not be used in code intended to be readable.
-
- There is no way to prevent a backslash at the end of a line from
-being interpreted as a backslash-newline. This cannot affect any
-correct program, however.
-
-
-File: cpp.info, Node: Tokenization, Next: The preprocessing language, Prev: Initial processing, Up: Overview
-
-1.3 Tokenization
-================
-
-After the textual transformations are finished, the input file is
-converted into a sequence of "preprocessing tokens". These mostly
-correspond to the syntactic tokens used by the C compiler, but there are
-a few differences. White space separates tokens; it is not itself a
-token of any kind. Tokens do not have to be separated by white space,
-but it is often necessary to avoid ambiguities.
-
- When faced with a sequence of characters that has more than one
-possible tokenization, the preprocessor is greedy. It always makes
-each token, starting from the left, as big as possible before moving on
-to the next token. For instance, `a+++++b' is interpreted as
-`a ++ ++ + b', not as `a ++ + ++ b', even though the latter
-tokenization could be part of a valid C program and the former could
-not.
-
- Once the input file is broken into tokens, the token boundaries never
-change, except when the `##' preprocessing operator is used to paste
-tokens together. *Note Concatenation::. For example,
-
- #define foo() bar
- foo()baz
- ==> bar baz
- _not_
- ==> barbaz
-
- The compiler does not re-tokenize the preprocessor's output. Each
-preprocessing token becomes one compiler token.
-
- Preprocessing tokens fall into five broad classes: identifiers,
-preprocessing numbers, string literals, punctuators, and other. An
-"identifier" is the same as an identifier in C: any sequence of
-letters, digits, or underscores, which begins with a letter or
-underscore. Keywords of C have no significance to the preprocessor;
-they are ordinary identifiers. You can define a macro whose name is a
-keyword, for instance. The only identifier which can be considered a
-preprocessing keyword is `defined'. *Note Defined::.
-
- This is mostly true of other languages which use the C preprocessor.
-However, a few of the keywords of C++ are significant even in the
-preprocessor. *Note C++ Named Operators::.
-
- In the 1999 C standard, identifiers may contain letters which are not
-part of the "basic source character set", at the implementation's
-discretion (such as accented Latin letters, Greek letters, or Chinese
-ideograms). This may be done with an extended character set, or the
-`\u' and `\U' escape sequences. The implementation of this feature in
-GCC is experimental; such characters are only accepted in the `\u' and
-`\U' forms and only if `-fextended-identifiers' is used.
-
- As an extension, GCC treats `$' as a letter. This is for
-compatibility with some systems, such as VMS, where `$' is commonly
-used in system-defined function and object names. `$' is not a letter
-in strictly conforming mode, or if you specify the `-$' option. *Note
-Invocation::.
-
- A "preprocessing number" has a rather bizarre definition. The
-category includes all the normal integer and floating point constants
-one expects of C, but also a number of other things one might not
-initially recognize as a number. Formally, preprocessing numbers begin
-with an optional period, a required decimal digit, and then continue
-with any sequence of letters, digits, underscores, periods, and
-exponents. Exponents are the two-character sequences `e+', `e-', `E+',
-`E-', `p+', `p-', `P+', and `P-'. (The exponents that begin with `p'
-or `P' are new to C99. They are used for hexadecimal floating-point
-constants.)
-
- The purpose of this unusual definition is to isolate the preprocessor
-from the full complexity of numeric constants. It does not have to
-distinguish between lexically valid and invalid floating-point numbers,
-which is complicated. The definition also permits you to split an
-identifier at any position and get exactly two tokens, which can then be
-pasted back together with the `##' operator.
-
- It's possible for preprocessing numbers to cause programs to be
-misinterpreted. For example, `0xE+12' is a preprocessing number which
-does not translate to any valid numeric constant, therefore a syntax
-error. It does not mean `0xE + 12', which is what you might have
-intended.
-
- "String literals" are string constants, character constants, and
-header file names (the argument of `#include').(1) String constants
-and character constants are straightforward: "..." or '...'. In either
-case embedded quotes should be escaped with a backslash: '\'' is the
-character constant for `''. There is no limit on the length of a
-character constant, but the value of a character constant that contains
-more than one character is implementation-defined. *Note
-Implementation Details::.
-
- Header file names either look like string constants, "...", or are
-written with angle brackets instead, <...>. In either case, backslash
-is an ordinary character. There is no way to escape the closing quote
-or angle bracket. The preprocessor looks for the header file in
-different places depending on which form you use. *Note Include
-Operation::.
-
- No string literal may extend past the end of a line. Older versions
-of GCC accepted multi-line string constants. You may use continued
-lines instead, or string constant concatenation. *Note Differences
-from previous versions::.
-
- "Punctuators" are all the usual bits of punctuation which are
-meaningful to C and C++. All but three of the punctuation characters in
-ASCII are C punctuators. The exceptions are `@', `$', and ``'. In
-addition, all the two- and three-character operators are punctuators.
-There are also six "digraphs", which the C++ standard calls
-"alternative tokens", which are merely alternate ways to spell other
-punctuators. This is a second attempt to work around missing
-punctuation in obsolete systems. It has no negative side effects,
-unlike trigraphs, but does not cover as much ground. The digraphs and
-their corresponding normal punctuators are:
-
- Digraph: <% %> <: :> %: %:%:
- Punctuator: { } [ ] # ##
-
- Any other single character is considered "other". It is passed on to
-the preprocessor's output unmolested. The C compiler will almost
-certainly reject source code containing "other" tokens. In ASCII, the
-only other characters are `@', `$', ``', and control characters other
-than NUL (all bits zero). (Note that `$' is normally considered a
-letter.) All characters with the high bit set (numeric range
-0x7F-0xFF) are also "other" in the present implementation. This will
-change when proper support for international character sets is added to
-GCC.
-
- NUL is a special case because of the high probability that its
-appearance is accidental, and because it may be invisible to the user
-(many terminals do not display NUL at all). Within comments, NULs are
-silently ignored, just as any other character would be. In running
-text, NUL is considered white space. For example, these two directives
-have the same meaning.
-
- #define X^@1
- #define X 1
-
-(where `^@' is ASCII NUL). Within string or character constants, NULs
-are preserved. In the latter two cases the preprocessor emits a
-warning message.
-
- ---------- Footnotes ----------
-
- (1) The C standard uses the term "string literal" to refer only to
-what we are calling "string constants".
-
-
-File: cpp.info, Node: The preprocessing language, Prev: Tokenization, Up: Overview
-
-1.4 The preprocessing language
-==============================
-
-After tokenization, the stream of tokens may simply be passed straight
-to the compiler's parser. However, if it contains any operations in the
-"preprocessing language", it will be transformed first. This stage
-corresponds roughly to the standard's "translation phase 4" and is what
-most people think of as the preprocessor's job.
-
- The preprocessing language consists of "directives" to be executed
-and "macros" to be expanded. Its primary capabilities are:
-
- * Inclusion of header files. These are files of declarations that
- can be substituted into your program.
-
- * Macro expansion. You can define "macros", which are abbreviations
- for arbitrary fragments of C code. The preprocessor will replace
- the macros with their definitions throughout the program. Some
- macros are automatically defined for you.
-
- * Conditional compilation. You can include or exclude parts of the
- program according to various conditions.
-
- * Line control. If you use a program to combine or rearrange source
- files into an intermediate file which is then compiled, you can
- use line control to inform the compiler where each source line
- originally came from.
-
- * Diagnostics. You can detect problems at compile time and issue
- errors or warnings.
-
- There are a few more, less useful, features.
-
- Except for expansion of predefined macros, all these operations are
-triggered with "preprocessing directives". Preprocessing directives
-are lines in your program that start with `#'. Whitespace is allowed
-before and after the `#'. The `#' is followed by an identifier, the
-"directive name". It specifies the operation to perform. Directives
-are commonly referred to as `#NAME' where NAME is the directive name.
-For example, `#define' is the directive that defines a macro.
-
- The `#' which begins a directive cannot come from a macro expansion.
-Also, the directive name is not macro expanded. Thus, if `foo' is
-defined as a macro expanding to `define', that does not make `#foo' a
-valid preprocessing directive.
-
- The set of valid directive names is fixed. Programs cannot define
-new preprocessing directives.
-
- Some directives require arguments; these make up the rest of the
-directive line and must be separated from the directive name by
-whitespace. For example, `#define' must be followed by a macro name
-and the intended expansion of the macro.
-
- A preprocessing directive cannot cover more than one line. The line
-may, however, be continued with backslash-newline, or by a block comment
-which extends past the end of the line. In either case, when the
-directive is processed, the continuations have already been merged with
-the first line to make one long line.
-
-
-File: cpp.info, Node: Header Files, Next: Macros, Prev: Overview, Up: Top
-
-2 Header Files
-**************
-
-A header file is a file containing C declarations and macro definitions
-(*note Macros::) to be shared between several source files. You request
-the use of a header file in your program by "including" it, with the C
-preprocessing directive `#include'.
-
- Header files serve two purposes.
-
- * System header files declare the interfaces to parts of the
- operating system. You include them in your program to supply the
- definitions and declarations you need to invoke system calls and
- libraries.
-
- * Your own header files contain declarations for interfaces between
- the source files of your program. Each time you have a group of
- related declarations and macro definitions all or most of which
- are needed in several different source files, it is a good idea to
- create a header file for them.
-
- Including a header file produces the same results as copying the
-header file into each source file that needs it. Such copying would be
-time-consuming and error-prone. With a header file, the related
-declarations appear in only one place. If they need to be changed, they
-can be changed in one place, and programs that include the header file
-will automatically use the new version when next recompiled. The header
-file eliminates the labor of finding and changing all the copies as well
-as the risk that a failure to find one copy will result in
-inconsistencies within a program.
-
- In C, the usual convention is to give header files names that end
-with `.h'. It is most portable to use only letters, digits, dashes, and
-underscores in header file names, and at most one dot.
-
-* Menu:
-
-* Include Syntax::
-* Include Operation::
-* Search Path::
-* Once-Only Headers::
-* Alternatives to Wrapper #ifndef::
-* Computed Includes::
-* Wrapper Headers::
-* System Headers::
-
-
-File: cpp.info, Node: Include Syntax, Next: Include Operation, Up: Header Files
-
-2.1 Include Syntax
-==================
-
-Both user and system header files are included using the preprocessing
-directive `#include'. It has two variants:
-
-`#include <FILE>'
- This variant is used for system header files. It searches for a
- file named FILE in a standard list of system directories. You can
- prepend directories to this list with the `-I' option (*note
- Invocation::).
-
-`#include "FILE"'
- This variant is used for header files of your own program. It
- searches for a file named FILE first in the directory containing
- the current file, then in the quote directories and then the same
- directories used for `<FILE>'. You can prepend directories to the
- list of quote directories with the `-iquote' option.
-
- The argument of `#include', whether delimited with quote marks or
-angle brackets, behaves like a string constant in that comments are not
-recognized, and macro names are not expanded. Thus, `#include <x/*y>'
-specifies inclusion of a system header file named `x/*y'.
-
- However, if backslashes occur within FILE, they are considered
-ordinary text characters, not escape characters. None of the character
-escape sequences appropriate to string constants in C are processed.
-Thus, `#include "x\n\\y"' specifies a filename containing three
-backslashes. (Some systems interpret `\' as a pathname separator. All
-of these also interpret `/' the same way. It is most portable to use
-only `/'.)
-
- It is an error if there is anything (other than comments) on the line
-after the file name.
-
-
-File: cpp.info, Node: Include Operation, Next: Search Path, Prev: Include Syntax, Up: Header Files
-
-2.2 Include Operation
-=====================
-
-The `#include' directive works by directing the C preprocessor to scan
-the specified file as input before continuing with the rest of the
-current file. The output from the preprocessor contains the output
-already generated, followed by the output resulting from the included
-file, followed by the output that comes from the text after the
-`#include' directive. For example, if you have a header file
-`header.h' as follows,
-
- char *test (void);
-
-and a main program called `program.c' that uses the header file, like
-this,
-
- int x;
- #include "header.h"
-
- int
- main (void)
- {
- puts (test ());
- }
-
-the compiler will see the same token stream as it would if `program.c'
-read
-
- int x;
- char *test (void);
-
- int
- main (void)
- {
- puts (test ());
- }
-
- Included files are not limited to declarations and macro definitions;
-those are merely the typical uses. Any fragment of a C program can be
-included from another file. The include file could even contain the
-beginning of a statement that is concluded in the containing file, or
-the end of a statement that was started in the including file. However,
-an included file must consist of complete tokens. Comments and string
-literals which have not been closed by the end of an included file are
-invalid. For error recovery, they are considered to end at the end of
-the file.
-
- To avoid confusion, it is best if header files contain only complete
-syntactic units--function declarations or definitions, type
-declarations, etc.
-
- The line following the `#include' directive is always treated as a
-separate line by the C preprocessor, even if the included file lacks a
-final newline.
-
-
-File: cpp.info, Node: Search Path, Next: Once-Only Headers, Prev: Include Operation, Up: Header Files
-
-2.3 Search Path
-===============
-
-GCC looks in several different places for headers. On a normal Unix
-system, if you do not instruct it otherwise, it will look for headers
-requested with `#include <FILE>' in:
-
- /usr/local/include
- LIBDIR/gcc/TARGET/VERSION/include
- /usr/TARGET/include
- /usr/include
-
- For C++ programs, it will also look in `/usr/include/g++-v3', first.
-In the above, TARGET is the canonical name of the system GCC was
-configured to compile code for; often but not always the same as the
-canonical name of the system it runs on. VERSION is the version of GCC
-in use.
-
- You can add to this list with the `-IDIR' command line option. All
-the directories named by `-I' are searched, in left-to-right order,
-_before_ the default directories. The only exception is when `dir' is
-already searched by default. In this case, the option is ignored and
-the search order for system directories remains unchanged.
-
- Duplicate directories are removed from the quote and bracket search
-chains before the two chains are merged to make the final search chain.
-Thus, it is possible for a directory to occur twice in the final search
-chain if it was specified in both the quote and bracket chains.
-
- You can prevent GCC from searching any of the default directories
-with the `-nostdinc' option. This is useful when you are compiling an
-operating system kernel or some other program that does not use the
-standard C library facilities, or the standard C library itself. `-I'
-options are not ignored as described above when `-nostdinc' is in
-effect.
-
- GCC looks for headers requested with `#include "FILE"' first in the
-directory containing the current file, then in the directories as
-specified by `-iquote' options, then in the same places it would have
-looked for a header requested with angle brackets. For example, if
-`/usr/include/sys/stat.h' contains `#include "types.h"', GCC looks for
-`types.h' first in `/usr/include/sys', then in its usual search path.
-
- `#line' (*note Line Control::) does not change GCC's idea of the
-directory containing the current file.
-
- You may put `-I-' at any point in your list of `-I' options. This
-has two effects. First, directories appearing before the `-I-' in the
-list are searched only for headers requested with quote marks.
-Directories after `-I-' are searched for all headers. Second, the
-directory containing the current file is not searched for anything,
-unless it happens to be one of the directories named by an `-I' switch.
-`-I-' is deprecated, `-iquote' should be used instead.
-
- `-I. -I-' is not the same as no `-I' options at all, and does not
-cause the same behavior for `<>' includes that `""' includes get with
-no special options. `-I.' searches the compiler's current working
-directory for header files. That may or may not be the same as the
-directory containing the current file.
-
- If you need to look for headers in a directory named `-', write
-`-I./-'.
-
- There are several more ways to adjust the header search path. They
-are generally less useful. *Note Invocation::.
-
-
-File: cpp.info, Node: Once-Only Headers, Next: Alternatives to Wrapper #ifndef, Prev: Search Path, Up: Header Files
-
-2.4 Once-Only Headers
-=====================
-
-If a header file happens to be included twice, the compiler will process
-its contents twice. This is very likely to cause an error, e.g. when
-the compiler sees the same structure definition twice. Even if it does
-not, it will certainly waste time.
-
- The standard way to prevent this is to enclose the entire real
-contents of the file in a conditional, like this:
-
- /* File foo. */
- #ifndef FILE_FOO_SEEN
- #define FILE_FOO_SEEN
-
- THE ENTIRE FILE
-
- #endif /* !FILE_FOO_SEEN */
-
- This construct is commonly known as a "wrapper #ifndef". When the
-header is included again, the conditional will be false, because
-`FILE_FOO_SEEN' is defined. The preprocessor will skip over the entire
-contents of the file, and the compiler will not see it twice.
-
- CPP optimizes even further. It remembers when a header file has a
-wrapper `#ifndef'. If a subsequent `#include' specifies that header,
-and the macro in the `#ifndef' is still defined, it does not bother to
-rescan the file at all.
-
- You can put comments outside the wrapper. They will not interfere
-with this optimization.
-
- The macro `FILE_FOO_SEEN' is called the "controlling macro" or
-"guard macro". In a user header file, the macro name should not begin
-with `_'. In a system header file, it should begin with `__' to avoid
-conflicts with user programs. In any kind of header file, the macro
-name should contain the name of the file and some additional text, to
-avoid conflicts with other header files.
-
-
-File: cpp.info, Node: Alternatives to Wrapper #ifndef, Next: Computed Includes, Prev: Once-Only Headers, Up: Header Files
-
-2.5 Alternatives to Wrapper #ifndef
-===================================
-
-CPP supports two more ways of indicating that a header file should be
-read only once. Neither one is as portable as a wrapper `#ifndef' and
-we recommend you do not use them in new programs, with the caveat that
-`#import' is standard practice in Objective-C.
-
- CPP supports a variant of `#include' called `#import' which includes
-a file, but does so at most once. If you use `#import' instead of
-`#include', then you don't need the conditionals inside the header file
-to prevent multiple inclusion of the contents. `#import' is standard
-in Objective-C, but is considered a deprecated extension in C and C++.
-
- `#import' is not a well designed feature. It requires the users of
-a header file to know that it should only be included once. It is much
-better for the header file's implementor to write the file so that users
-don't need to know this. Using a wrapper `#ifndef' accomplishes this
-goal.
-
- In the present implementation, a single use of `#import' will
-prevent the file from ever being read again, by either `#import' or
-`#include'. You should not rely on this; do not use both `#import' and
-`#include' to refer to the same header file.
-
- Another way to prevent a header file from being included more than
-once is with the `#pragma once' directive. If `#pragma once' is seen
-when scanning a header file, that file will never be read again, no
-matter what.
-
- `#pragma once' does not have the problems that `#import' does, but
-it is not recognized by all preprocessors, so you cannot rely on it in
-a portable program.
-
-
-File: cpp.info, Node: Computed Includes, Next: Wrapper Headers, Prev: Alternatives to Wrapper #ifndef, Up: Header Files
-
-2.6 Computed Includes
-=====================
-
-Sometimes it is necessary to select one of several different header
-files to be included into your program. They might specify
-configuration parameters to be used on different sorts of operating
-systems, for instance. You could do this with a series of conditionals,
-
- #if SYSTEM_1
- # include "system_1.h"
- #elif SYSTEM_2
- # include "system_2.h"
- #elif SYSTEM_3
- ...
- #endif
-
- That rapidly becomes tedious. Instead, the preprocessor offers the
-ability to use a macro for the header name. This is called a "computed
-include". Instead of writing a header name as the direct argument of
-`#include', you simply put a macro name there instead:
-
- #define SYSTEM_H "system_1.h"
- ...
- #include SYSTEM_H
-
-`SYSTEM_H' will be expanded, and the preprocessor will look for
-`system_1.h' as if the `#include' had been written that way originally.
-`SYSTEM_H' could be defined by your Makefile with a `-D' option.
-
- You must be careful when you define the macro. `#define' saves
-tokens, not text. The preprocessor has no way of knowing that the macro
-will be used as the argument of `#include', so it generates ordinary
-tokens, not a header name. This is unlikely to cause problems if you
-use double-quote includes, which are close enough to string constants.
-If you use angle brackets, however, you may have trouble.
-
- The syntax of a computed include is actually a bit more general than
-the above. If the first non-whitespace character after `#include' is
-not `"' or `<', then the entire line is macro-expanded like running
-text would be.
-
- If the line expands to a single string constant, the contents of that
-string constant are the file to be included. CPP does not re-examine
-the string for embedded quotes, but neither does it process backslash
-escapes in the string. Therefore
-
- #define HEADER "a\"b"
- #include HEADER
-
-looks for a file named `a\"b'. CPP searches for the file according to
-the rules for double-quoted includes.
-
- If the line expands to a token stream beginning with a `<' token and
-including a `>' token, then the tokens between the `<' and the first
-`>' are combined to form the filename to be included. Any whitespace
-between tokens is reduced to a single space; then any space after the
-initial `<' is retained, but a trailing space before the closing `>' is
-ignored. CPP searches for the file according to the rules for
-angle-bracket includes.
-
- In either case, if there are any tokens on the line after the file
-name, an error occurs and the directive is not processed. It is also
-an error if the result of expansion does not match either of the two
-expected forms.
-
- These rules are implementation-defined behavior according to the C
-standard. To minimize the risk of different compilers interpreting your
-computed includes differently, we recommend you use only a single
-object-like macro which expands to a string constant. This will also
-minimize confusion for people reading your program.
-
-
-File: cpp.info, Node: Wrapper Headers, Next: System Headers, Prev: Computed Includes, Up: Header Files
-
-2.7 Wrapper Headers
-===================
-
-Sometimes it is necessary to adjust the contents of a system-provided
-header file without editing it directly. GCC's `fixincludes' operation
-does this, for example. One way to do that would be to create a new
-header file with the same name and insert it in the search path before
-the original header. That works fine as long as you're willing to
-replace the old header entirely. But what if you want to refer to the
-old header from the new one?
-
- You cannot simply include the old header with `#include'. That will
-start from the beginning, and find your new header again. If your
-header is not protected from multiple inclusion (*note Once-Only
-Headers::), it will recurse infinitely and cause a fatal error.
-
- You could include the old header with an absolute pathname:
- #include "/usr/include/old-header.h"
- This works, but is not clean; should the system headers ever move,
-you would have to edit the new headers to match.
-
- There is no way to solve this problem within the C standard, but you
-can use the GNU extension `#include_next'. It means, "Include the
-_next_ file with this name". This directive works like `#include'
-except in searching for the specified file: it starts searching the
-list of header file directories _after_ the directory in which the
-current file was found.
-
- Suppose you specify `-I /usr/local/include', and the list of
-directories to search also includes `/usr/include'; and suppose both
-directories contain `signal.h'. Ordinary `#include <signal.h>' finds
-the file under `/usr/local/include'. If that file contains
-`#include_next <signal.h>', it starts searching after that directory,
-and finds the file in `/usr/include'.
-
- `#include_next' does not distinguish between `<FILE>' and `"FILE"'
-inclusion, nor does it check that the file you specify has the same
-name as the current file. It simply looks for the file named, starting
-with the directory in the search path after the one where the current
-file was found.
-
- The use of `#include_next' can lead to great confusion. We
-recommend it be used only when there is no other alternative. In
-particular, it should not be used in the headers belonging to a specific
-program; it should be used only to make global corrections along the
-lines of `fixincludes'.
-
-
-File: cpp.info, Node: System Headers, Prev: Wrapper Headers, Up: Header Files
-
-2.8 System Headers
-==================
-
-The header files declaring interfaces to the operating system and
-runtime libraries often cannot be written in strictly conforming C.
-Therefore, GCC gives code found in "system headers" special treatment.
-All warnings, other than those generated by `#warning' (*note
-Diagnostics::), are suppressed while GCC is processing a system header.
-Macros defined in a system header are immune to a few warnings wherever
-they are expanded. This immunity is granted on an ad-hoc basis, when
-we find that a warning generates lots of false positives because of
-code in macros defined in system headers.
-
- Normally, only the headers found in specific directories are
-considered system headers. These directories are determined when GCC
-is compiled. There are, however, two ways to make normal headers into
-system headers.
-
- The `-isystem' command line option adds its argument to the list of
-directories to search for headers, just like `-I'. Any headers found
-in that directory will be considered system headers.
-
- All directories named by `-isystem' are searched _after_ all
-directories named by `-I', no matter what their order was on the
-command line. If the same directory is named by both `-I' and
-`-isystem', the `-I' option is ignored. GCC provides an informative
-message when this occurs if `-v' is used.
-
- There is also a directive, `#pragma GCC system_header', which tells
-GCC to consider the rest of the current include file a system header,
-no matter where it was found. Code that comes before the `#pragma' in
-the file will not be affected. `#pragma GCC system_header' has no
-effect in the primary source file.
-
- On very old systems, some of the pre-defined system header
-directories get even more special treatment. GNU C++ considers code in
-headers found in those directories to be surrounded by an `extern "C"'
-block. There is no way to request this behavior with a `#pragma', or
-from the command line.
-
-
-File: cpp.info, Node: Macros, Next: Conditionals, Prev: Header Files, Up: Top
-
-3 Macros
-********
-
-A "macro" is a fragment of code which has been given a name. Whenever
-the name is used, it is replaced by the contents of the macro. There
-are two kinds of macros. They differ mostly in what they look like
-when they are used. "Object-like" macros resemble data objects when
-used, "function-like" macros resemble function calls.
-
- You may define any valid identifier as a macro, even if it is a C
-keyword. The preprocessor does not know anything about keywords. This
-can be useful if you wish to hide a keyword such as `const' from an
-older compiler that does not understand it. However, the preprocessor
-operator `defined' (*note Defined::) can never be defined as a macro,
-and C++'s named operators (*note C++ Named Operators::) cannot be
-macros when you are compiling C++.
-
-* Menu:
-
-* Object-like Macros::
-* Function-like Macros::
-* Macro Arguments::
-* Stringification::
-* Concatenation::
-* Variadic Macros::
-* Predefined Macros::
-* Undefining and Redefining Macros::
-* Directives Within Macro Arguments::
-* Macro Pitfalls::
-
-
-File: cpp.info, Node: Object-like Macros, Next: Function-like Macros, Up: Macros
-
-3.1 Object-like Macros
-======================
-
-An "object-like macro" is a simple identifier which will be replaced by
-a code fragment. It is called object-like because it looks like a data
-object in code that uses it. They are most commonly used to give
-symbolic names to numeric constants.
-
- You create macros with the `#define' directive. `#define' is
-followed by the name of the macro and then the token sequence it should
-be an abbreviation for, which is variously referred to as the macro's
-"body", "expansion" or "replacement list". For example,
-
- #define BUFFER_SIZE 1024
-
-defines a macro named `BUFFER_SIZE' as an abbreviation for the token
-`1024'. If somewhere after this `#define' directive there comes a C
-statement of the form
-
- foo = (char *) malloc (BUFFER_SIZE);
-
-then the C preprocessor will recognize and "expand" the macro
-`BUFFER_SIZE'. The C compiler will see the same tokens as it would if
-you had written
-
- foo = (char *) malloc (1024);
-
- By convention, macro names are written in uppercase. Programs are
-easier to read when it is possible to tell at a glance which names are
-macros.
-
- The macro's body ends at the end of the `#define' line. You may
-continue the definition onto multiple lines, if necessary, using
-backslash-newline. When the macro is expanded, however, it will all
-come out on one line. For example,
-
- #define NUMBERS 1, \
- 2, \
- 3
- int x[] = { NUMBERS };
- ==> int x[] = { 1, 2, 3 };
-
-The most common visible consequence of this is surprising line numbers
-in error messages.
-
- There is no restriction on what can go in a macro body provided it
-decomposes into valid preprocessing tokens. Parentheses need not
-balance, and the body need not resemble valid C code. (If it does not,
-you may get error messages from the C compiler when you use the macro.)
-
- The C preprocessor scans your program sequentially. Macro
-definitions take effect at the place you write them. Therefore, the
-following input to the C preprocessor
-
- foo = X;
- #define X 4
- bar = X;
-
-produces
-
- foo = X;
- bar = 4;
-
- When the preprocessor expands a macro name, the macro's expansion
-replaces the macro invocation, then the expansion is examined for more
-macros to expand. For example,
-
- #define TABLESIZE BUFSIZE
- #define BUFSIZE 1024
- TABLESIZE
- ==> BUFSIZE
- ==> 1024
-
-`TABLESIZE' is expanded first to produce `BUFSIZE', then that macro is
-expanded to produce the final result, `1024'.
-
- Notice that `BUFSIZE' was not defined when `TABLESIZE' was defined.
-The `#define' for `TABLESIZE' uses exactly the expansion you
-specify--in this case, `BUFSIZE'--and does not check to see whether it
-too contains macro names. Only when you _use_ `TABLESIZE' is the
-result of its expansion scanned for more macro names.
-
- This makes a difference if you change the definition of `BUFSIZE' at
-some point in the source file. `TABLESIZE', defined as shown, will
-always expand using the definition of `BUFSIZE' that is currently in
-effect:
-
- #define BUFSIZE 1020
- #define TABLESIZE BUFSIZE
- #undef BUFSIZE
- #define BUFSIZE 37
-
-Now `TABLESIZE' expands (in two stages) to `37'.
-
- If the expansion of a macro contains its own name, either directly or
-via intermediate macros, it is not expanded again when the expansion is
-examined for more macros. This prevents infinite recursion. *Note
-Self-Referential Macros::, for the precise details.
-
-
-File: cpp.info, Node: Function-like Macros, Next: Macro Arguments, Prev: Object-like Macros, Up: Macros
-
-3.2 Function-like Macros
-========================
-
-You can also define macros whose use looks like a function call. These
-are called "function-like macros". To define a function-like macro,
-you use the same `#define' directive, but you put a pair of parentheses
-immediately after the macro name. For example,
-
- #define lang_init() c_init()
- lang_init()
- ==> c_init()
-
- A function-like macro is only expanded if its name appears with a
-pair of parentheses after it. If you write just the name, it is left
-alone. This can be useful when you have a function and a macro of the
-same name, and you wish to use the function sometimes.
-
- extern void foo(void);
- #define foo() /* optimized inline version */
- ...
- foo();
- funcptr = foo;
-
- Here the call to `foo()' will use the macro, but the function
-pointer will get the address of the real function. If the macro were to
-be expanded, it would cause a syntax error.
-
- If you put spaces between the macro name and the parentheses in the
-macro definition, that does not define a function-like macro, it defines
-an object-like macro whose expansion happens to begin with a pair of
-parentheses.
-
- #define lang_init () c_init()
- lang_init()
- ==> () c_init()()
-
- The first two pairs of parentheses in this expansion come from the
-macro. The third is the pair that was originally after the macro
-invocation. Since `lang_init' is an object-like macro, it does not
-consume those parentheses.
-
-
-File: cpp.info, Node: Macro Arguments, Next: Stringification, Prev: Function-like Macros, Up: Macros
-
-3.3 Macro Arguments
-===================
-
-Function-like macros can take "arguments", just like true functions.
-To define a macro that uses arguments, you insert "parameters" between
-the pair of parentheses in the macro definition that make the macro
-function-like. The parameters must be valid C identifiers, separated
-by commas and optionally whitespace.
-
- To invoke a macro that takes arguments, you write the name of the
-macro followed by a list of "actual arguments" in parentheses, separated
-by commas. The invocation of the macro need not be restricted to a
-single logical line--it can cross as many lines in the source file as
-you wish. The number of arguments you give must match the number of
-parameters in the macro definition. When the macro is expanded, each
-use of a parameter in its body is replaced by the tokens of the
-corresponding argument. (You need not use all of the parameters in the
-macro body.)
-
- As an example, here is a macro that computes the minimum of two
-numeric values, as it is defined in many C programs, and some uses.
-
- #define min(X, Y) ((X) < (Y) ? (X) : (Y))
- x = min(a, b); ==> x = ((a) < (b) ? (a) : (b));
- y = min(1, 2); ==> y = ((1) < (2) ? (1) : (2));
- z = min(a + 28, *p); ==> z = ((a + 28) < (*p) ? (a + 28) : (*p));
-
-(In this small example you can already see several of the dangers of
-macro arguments. *Note Macro Pitfalls::, for detailed explanations.)
-
- Leading and trailing whitespace in each argument is dropped, and all
-whitespace between the tokens of an argument is reduced to a single
-space. Parentheses within each argument must balance; a comma within
-such parentheses does not end the argument. However, there is no
-requirement for square brackets or braces to balance, and they do not
-prevent a comma from separating arguments. Thus,
-
- macro (array[x = y, x + 1])
-
-passes two arguments to `macro': `array[x = y' and `x + 1]'. If you
-want to supply `array[x = y, x + 1]' as an argument, you can write it
-as `array[(x = y, x + 1)]', which is equivalent C code.
-
- All arguments to a macro are completely macro-expanded before they
-are substituted into the macro body. After substitution, the complete
-text is scanned again for macros to expand, including the arguments.
-This rule may seem strange, but it is carefully designed so you need
-not worry about whether any function call is actually a macro
-invocation. You can run into trouble if you try to be too clever,
-though. *Note Argument Prescan::, for detailed discussion.
-
- For example, `min (min (a, b), c)' is first expanded to
-
- min (((a) < (b) ? (a) : (b)), (c))
-
-and then to
-
- ((((a) < (b) ? (a) : (b))) < (c)
- ? (((a) < (b) ? (a) : (b)))
- : (c))
-
-(Line breaks shown here for clarity would not actually be generated.)
-
- You can leave macro arguments empty; this is not an error to the
-preprocessor (but many macros will then expand to invalid code). You
-cannot leave out arguments entirely; if a macro takes two arguments,
-there must be exactly one comma at the top level of its argument list.
-Here are some silly examples using `min':
-
- min(, b) ==> (( ) < (b) ? ( ) : (b))
- min(a, ) ==> ((a ) < ( ) ? (a ) : ( ))
- min(,) ==> (( ) < ( ) ? ( ) : ( ))
- min((,),) ==> (((,)) < ( ) ? ((,)) : ( ))
-
- min() error--> macro "min" requires 2 arguments, but only 1 given
- min(,,) error--> macro "min" passed 3 arguments, but takes just 2
-
- Whitespace is not a preprocessing token, so if a macro `foo' takes
-one argument, `foo ()' and `foo ( )' both supply it an empty argument.
-Previous GNU preprocessor implementations and documentation were
-incorrect on this point, insisting that a function-like macro that
-takes a single argument be passed a space if an empty argument was
-required.
-
- Macro parameters appearing inside string literals are not replaced by
-their corresponding actual arguments.
-
- #define foo(x) x, "x"
- foo(bar) ==> bar, "x"
-
-
-File: cpp.info, Node: Stringification, Next: Concatenation, Prev: Macro Arguments, Up: Macros
-
-3.4 Stringification
-===================
-
-Sometimes you may want to convert a macro argument into a string
-constant. Parameters are not replaced inside string constants, but you
-can use the `#' preprocessing operator instead. When a macro parameter
-is used with a leading `#', the preprocessor replaces it with the
-literal text of the actual argument, converted to a string constant.
-Unlike normal parameter replacement, the argument is not macro-expanded
-first. This is called "stringification".
-
- There is no way to combine an argument with surrounding text and
-stringify it all together. Instead, you can write a series of adjacent
-string constants and stringified arguments. The preprocessor will
-replace the stringified arguments with string constants. The C
-compiler will then combine all the adjacent string constants into one
-long string.
-
- Here is an example of a macro definition that uses stringification:
-
- #define WARN_IF(EXP) \
- do { if (EXP) \
- fprintf (stderr, "Warning: " #EXP "\n"); } \
- while (0)
- WARN_IF (x == 0);
- ==> do { if (x == 0)
- fprintf (stderr, "Warning: " "x == 0" "\n"); } while (0);
-
-The argument for `EXP' is substituted once, as-is, into the `if'
-statement, and once, stringified, into the argument to `fprintf'. If
-`x' were a macro, it would be expanded in the `if' statement, but not
-in the string.
-
- The `do' and `while (0)' are a kludge to make it possible to write
-`WARN_IF (ARG);', which the resemblance of `WARN_IF' to a function
-would make C programmers want to do; see *note Swallowing the
-Semicolon::.
-
- Stringification in C involves more than putting double-quote
-characters around the fragment. The preprocessor backslash-escapes the
-quotes surrounding embedded string constants, and all backslashes
-within string and character constants, in order to get a valid C string
-constant with the proper contents. Thus, stringifying `p = "foo\n";'
-results in "p = \"foo\\n\";". However, backslashes that are not inside
-string or character constants are not duplicated: `\n' by itself
-stringifies to "\n".
-
- All leading and trailing whitespace in text being stringified is
-ignored. Any sequence of whitespace in the middle of the text is
-converted to a single space in the stringified result. Comments are
-replaced by whitespace long before stringification happens, so they
-never appear in stringified text.
-
- There is no way to convert a macro argument into a character
-constant.
-
- If you want to stringify the result of expansion of a macro argument,
-you have to use two levels of macros.
-
- #define xstr(s) str(s)
- #define str(s) #s
- #define foo 4
- str (foo)
- ==> "foo"
- xstr (foo)
- ==> xstr (4)
- ==> str (4)
- ==> "4"
-
- `s' is stringified when it is used in `str', so it is not
-macro-expanded first. But `s' is an ordinary argument to `xstr', so it
-is completely macro-expanded before `xstr' itself is expanded (*note
-Argument Prescan::). Therefore, by the time `str' gets to its
-argument, it has already been macro-expanded.
-
-
-File: cpp.info, Node: Concatenation, Next: Variadic Macros, Prev: Stringification, Up: Macros
-
-3.5 Concatenation
-=================
-
-It is often useful to merge two tokens into one while expanding macros.
-This is called "token pasting" or "token concatenation". The `##'
-preprocessing operator performs token pasting. When a macro is
-expanded, the two tokens on either side of each `##' operator are
-combined into a single token, which then replaces the `##' and the two
-original tokens in the macro expansion. Usually both will be
-identifiers, or one will be an identifier and the other a preprocessing
-number. When pasted, they make a longer identifier. This isn't the
-only valid case. It is also possible to concatenate two numbers (or a
-number and a name, such as `1.5' and `e3') into a number. Also,
-multi-character operators such as `+=' can be formed by token pasting.
-
- However, two tokens that don't together form a valid token cannot be
-pasted together. For example, you cannot concatenate `x' with `+' in
-either order. If you try, the preprocessor issues a warning and emits
-the two tokens. Whether it puts white space between the tokens is
-undefined. It is common to find unnecessary uses of `##' in complex
-macros. If you get this warning, it is likely that you can simply
-remove the `##'.
-
- Both the tokens combined by `##' could come from the macro body, but
-you could just as well write them as one token in the first place.
-Token pasting is most useful when one or both of the tokens comes from a
-macro argument. If either of the tokens next to an `##' is a parameter
-name, it is replaced by its actual argument before `##' executes. As
-with stringification, the actual argument is not macro-expanded first.
-If the argument is empty, that `##' has no effect.
-
- Keep in mind that the C preprocessor converts comments to whitespace
-before macros are even considered. Therefore, you cannot create a
-comment by concatenating `/' and `*'. You can put as much whitespace
-between `##' and its operands as you like, including comments, and you
-can put comments in arguments that will be concatenated. However, it
-is an error if `##' appears at either end of a macro body.
-
- Consider a C program that interprets named commands. There probably
-needs to be a table of commands, perhaps an array of structures declared
-as follows:
-
- struct command
- {
- char *name;
- void (*function) (void);
- };
-
- struct command commands[] =
- {
- { "quit", quit_command },
- { "help", help_command },
- ...
- };
-
- It would be cleaner not to have to give each command name twice,
-once in the string constant and once in the function name. A macro
-which takes the name of a command as an argument can make this
-unnecessary. The string constant can be created with stringification,
-and the function name by concatenating the argument with `_command'.
-Here is how it is done:
-
- #define COMMAND(NAME) { #NAME, NAME ## _command }
-
- struct command commands[] =
- {
- COMMAND (quit),
- COMMAND (help),
- ...
- };
-
-
-File: cpp.info, Node: Variadic Macros, Next: Predefined Macros, Prev: Concatenation, Up: Macros
-
-3.6 Variadic Macros
-===================
-
-A macro can be declared to accept a variable number of arguments much as
-a function can. The syntax for defining the macro is similar to that of
-a function. Here is an example:
-
- #define eprintf(...) fprintf (stderr, __VA_ARGS__)
-
- This kind of macro is called "variadic". When the macro is invoked,
-all the tokens in its argument list after the last named argument (this
-macro has none), including any commas, become the "variable argument".
-This sequence of tokens replaces the identifier `__VA_ARGS__' in the
-macro body wherever it appears. Thus, we have this expansion:
-
- eprintf ("%s:%d: ", input_file, lineno)
- ==> fprintf (stderr, "%s:%d: ", input_file, lineno)
-
- The variable argument is completely macro-expanded before it is
-inserted into the macro expansion, just like an ordinary argument. You
-may use the `#' and `##' operators to stringify the variable argument
-or to paste its leading or trailing token with another token. (But see
-below for an important special case for `##'.)
-
- If your macro is complicated, you may want a more descriptive name
-for the variable argument than `__VA_ARGS__'. CPP permits this, as an
-extension. You may write an argument name immediately before the
-`...'; that name is used for the variable argument. The `eprintf'
-macro above could be written
-
- #define eprintf(args...) fprintf (stderr, args)
-
-using this extension. You cannot use `__VA_ARGS__' and this extension
-in the same macro.
-
- You can have named arguments as well as variable arguments in a
-variadic macro. We could define `eprintf' like this, instead:
-
- #define eprintf(format, ...) fprintf (stderr, format, __VA_ARGS__)
-
-This formulation looks more descriptive, but unfortunately it is less
-flexible: you must now supply at least one argument after the format
-string. In standard C, you cannot omit the comma separating the named
-argument from the variable arguments. Furthermore, if you leave the
-variable argument empty, you will get a syntax error, because there
-will be an extra comma after the format string.
-
- eprintf("success!\n", );
- ==> fprintf(stderr, "success!\n", );
-
- GNU CPP has a pair of extensions which deal with this problem.
-First, you are allowed to leave the variable argument out entirely:
-
- eprintf ("success!\n")
- ==> fprintf(stderr, "success!\n", );
-
-Second, the `##' token paste operator has a special meaning when placed
-between a comma and a variable argument. If you write
-
- #define eprintf(format, ...) fprintf (stderr, format, ##__VA_ARGS__)
-
-and the variable argument is left out when the `eprintf' macro is used,
-then the comma before the `##' will be deleted. This does _not_ happen
-if you pass an empty argument, nor does it happen if the token
-preceding `##' is anything other than a comma.
-
- eprintf ("success!\n")
- ==> fprintf(stderr, "success!\n");
-
-The above explanation is ambiguous about the case where the only macro
-parameter is a variable arguments parameter, as it is meaningless to
-try to distinguish whether no argument at all is an empty argument or a
-missing argument. In this case the C99 standard is clear that the
-comma must remain, however the existing GCC extension used to swallow
-the comma. So CPP retains the comma when conforming to a specific C
-standard, and drops it otherwise.
-
- C99 mandates that the only place the identifier `__VA_ARGS__' can
-appear is in the replacement list of a variadic macro. It may not be
-used as a macro name, macro argument name, or within a different type
-of macro. It may also be forbidden in open text; the standard is
-ambiguous. We recommend you avoid using it except for its defined
-purpose.
-
- Variadic macros are a new feature in C99. GNU CPP has supported them
-for a long time, but only with a named variable argument (`args...',
-not `...' and `__VA_ARGS__'). If you are concerned with portability to
-previous versions of GCC, you should use only named variable arguments.
-On the other hand, if you are concerned with portability to other
-conforming implementations of C99, you should use only `__VA_ARGS__'.
-
- Previous versions of CPP implemented the comma-deletion extension
-much more generally. We have restricted it in this release to minimize
-the differences from C99. To get the same effect with both this and
-previous versions of GCC, the token preceding the special `##' must be
-a comma, and there must be white space between that comma and whatever
-comes immediately before it:
-
- #define eprintf(format, args...) fprintf (stderr, format , ##args)
-
-*Note Differences from previous versions::, for the gory details.
-
-
-File: cpp.info, Node: Predefined Macros, Next: Undefining and Redefining Macros, Prev: Variadic Macros, Up: Macros
-
-3.7 Predefined Macros
-=====================
-
-Several object-like macros are predefined; you use them without
-supplying their definitions. They fall into three classes: standard,
-common, and system-specific.
-
- In C++, there is a fourth category, the named operators. They act
-like predefined macros, but you cannot undefine them.
-
-* Menu:
-
-* Standard Predefined Macros::
-* Common Predefined Macros::
-* System-specific Predefined Macros::
-* C++ Named Operators::
-
-
-File: cpp.info, Node: Standard Predefined Macros, Next: Common Predefined Macros, Up: Predefined Macros
-
-3.7.1 Standard Predefined Macros
---------------------------------
-
-The standard predefined macros are specified by the relevant language
-standards, so they are available with all compilers that implement
-those standards. Older compilers may not provide all of them. Their
-names all start with double underscores.
-
-`__FILE__'
- This macro expands to the name of the current input file, in the
- form of a C string constant. This is the path by which the
- preprocessor opened the file, not the short name specified in
- `#include' or as the input file name argument. For example,
- `"/usr/local/include/myheader.h"' is a possible expansion of this
- macro.
-
-`__LINE__'
- This macro expands to the current input line number, in the form
- of a decimal integer constant. While we call it a predefined
- macro, it's a pretty strange macro, since its "definition" changes
- with each new line of source code.
-
- `__FILE__' and `__LINE__' are useful in generating an error message
-to report an inconsistency detected by the program; the message can
-state the source line at which the inconsistency was detected. For
-example,
-
- fprintf (stderr, "Internal error: "
- "negative string length "
- "%d at %s, line %d.",
- length, __FILE__, __LINE__);
-
- An `#include' directive changes the expansions of `__FILE__' and
-`__LINE__' to correspond to the included file. At the end of that
-file, when processing resumes on the input file that contained the
-`#include' directive, the expansions of `__FILE__' and `__LINE__'
-revert to the values they had before the `#include' (but `__LINE__' is
-then incremented by one as processing moves to the line after the
-`#include').
-
- A `#line' directive changes `__LINE__', and may change `__FILE__' as
-well. *Note Line Control::.
-
- C99 introduces `__func__', and GCC has provided `__FUNCTION__' for a
-long time. Both of these are strings containing the name of the
-current function (there are slight semantic differences; see the GCC
-manual). Neither of them is a macro; the preprocessor does not know the
-name of the current function. They tend to be useful in conjunction
-with `__FILE__' and `__LINE__', though.
-
-`__DATE__'
- This macro expands to a string constant that describes the date on
- which the preprocessor is being run. The string constant contains
- eleven characters and looks like `"Feb 12 1996"'. If the day of
- the month is less than 10, it is padded with a space on the left.
-
- If GCC cannot determine the current date, it will emit a warning
- message (once per compilation) and `__DATE__' will expand to
- `"??? ?? ????"'.
-
-`__TIME__'
- This macro expands to a string constant that describes the time at
- which the preprocessor is being run. The string constant contains
- eight characters and looks like `"23:59:01"'.
-
- If GCC cannot determine the current time, it will emit a warning
- message (once per compilation) and `__TIME__' will expand to
- `"??:??:??"'.
-
-`__STDC__'
- In normal operation, this macro expands to the constant 1, to
- signify that this compiler conforms to ISO Standard C. If GNU CPP
- is used with a compiler other than GCC, this is not necessarily
- true; however, the preprocessor always conforms to the standard
- unless the `-traditional-cpp' option is used.
-
- This macro is not defined if the `-traditional-cpp' option is used.
-
- On some hosts, the system compiler uses a different convention,
- where `__STDC__' is normally 0, but is 1 if the user specifies
- strict conformance to the C Standard. CPP follows the host
- convention when processing system header files, but when
- processing user files `__STDC__' is always 1. This has been
- reported to cause problems; for instance, some versions of Solaris
- provide X Windows headers that expect `__STDC__' to be either
- undefined or 1. *Note Invocation::.
-
-`__STDC_VERSION__'
- This macro expands to the C Standard's version number, a long
- integer constant of the form `YYYYMML' where YYYY and MM are the
- year and month of the Standard version. This signifies which
- version of the C Standard the compiler conforms to. Like
- `__STDC__', this is not necessarily accurate for the entire
- implementation, unless GNU CPP is being used with GCC.
-
- The value `199409L' signifies the 1989 C standard as amended in
- 1994, which is the current default; the value `199901L' signifies
- the 1999 revision of the C standard. Support for the 1999
- revision is not yet complete.
-
- This macro is not defined if the `-traditional-cpp' option is
- used, nor when compiling C++ or Objective-C.
-
-`__STDC_HOSTED__'
- This macro is defined, with value 1, if the compiler's target is a
- "hosted environment". A hosted environment has the complete
- facilities of the standard C library available.
-
-`__cplusplus'
- This macro is defined when the C++ compiler is in use. You can use
- `__cplusplus' to test whether a header is compiled by a C compiler
- or a C++ compiler. This macro is similar to `__STDC_VERSION__', in
- that it expands to a version number. A fully conforming
- implementation of the 1998 C++ standard will define this macro to
- `199711L'. The GNU C++ compiler is not yet fully conforming, so
- it uses `1' instead. It is hoped to complete the implementation
- of standard C++ in the near future.
-
-`__OBJC__'
- This macro is defined, with value 1, when the Objective-C compiler
- is in use. You can use `__OBJC__' to test whether a header is
- compiled by a C compiler or an Objective-C compiler.
-
-`__ASSEMBLER__'
- This macro is defined with value 1 when preprocessing assembly
- language.
-
-
-
-File: cpp.info, Node: Common Predefined Macros, Next: System-specific Predefined Macros, Prev: Standard Predefined Macros, Up: Predefined Macros
-
-3.7.2 Common Predefined Macros
-------------------------------
-
-The common predefined macros are GNU C extensions. They are available
-with the same meanings regardless of the machine or operating system on
-which you are using GNU C or GNU Fortran. Their names all start with
-double underscores.
-
-`__COUNTER__'
- This macro expands to sequential integral values starting from 0.
- In conjunction with the `##' operator, this provides a convenient
- means to generate unique identifiers. Care must be taken to
- ensure that `__COUNTER__' is not expanded prior to inclusion of
- precompiled headers which use it. Otherwise, the precompiled
- headers will not be used.
-
-`__GFORTRAN__'
- The GNU Fortran compiler defines this.
-
-`__GNUC__'
-`__GNUC_MINOR__'
-`__GNUC_PATCHLEVEL__'
- These macros are defined by all GNU compilers that use the C
- preprocessor: C, C++, Objective-C and Fortran. Their values are
- the major version, minor version, and patch level of the compiler,
- as integer constants. For example, GCC 3.2.1 will define
- `__GNUC__' to 3, `__GNUC_MINOR__' to 2, and `__GNUC_PATCHLEVEL__'
- to 1. These macros are also defined if you invoke the
- preprocessor directly.
-
- `__GNUC_PATCHLEVEL__' is new to GCC 3.0; it is also present in the
- widely-used development snapshots leading up to 3.0 (which identify
- themselves as GCC 2.96 or 2.97, depending on which snapshot you
- have).
-
- If all you need to know is whether or not your program is being
- compiled by GCC, or a non-GCC compiler that claims to accept the
- GNU C dialects, you can simply test `__GNUC__'. If you need to
- write code which depends on a specific version, you must be more
- careful. Each time the minor version is increased, the patch
- level is reset to zero; each time the major version is increased
- (which happens rarely), the minor version and patch level are
- reset. If you wish to use the predefined macros directly in the
- conditional, you will need to write it like this:
-
- /* Test for GCC > 3.2.0 */
- #if __GNUC__ > 3 || \
- (__GNUC__ == 3 && (__GNUC_MINOR__ > 2 || \
- (__GNUC_MINOR__ == 2 && \
- __GNUC_PATCHLEVEL__ > 0))
-
- Another approach is to use the predefined macros to calculate a
- single number, then compare that against a threshold:
-
- #define GCC_VERSION (__GNUC__ * 10000 \
- + __GNUC_MINOR__ * 100 \
- + __GNUC_PATCHLEVEL__)
- ...
- /* Test for GCC > 3.2.0 */
- #if GCC_VERSION > 30200
-
- Many people find this form easier to understand.
-
-`__GNUG__'
- The GNU C++ compiler defines this. Testing it is equivalent to
- testing `(__GNUC__ && __cplusplus)'.
-
-`__STRICT_ANSI__'
- GCC defines this macro if and only if the `-ansi' switch, or a
- `-std' switch specifying strict conformance to some version of ISO
- C, was specified when GCC was invoked. It is defined to `1'.
- This macro exists primarily to direct GNU libc's header files to
- restrict their definitions to the minimal set found in the 1989 C
- standard.
-
-`__BASE_FILE__'
- This macro expands to the name of the main input file, in the form
- of a C string constant. This is the source file that was specified
- on the command line of the preprocessor or C compiler.
-
-`__INCLUDE_LEVEL__'
- This macro expands to a decimal integer constant that represents
- the depth of nesting in include files. The value of this macro is
- incremented on every `#include' directive and decremented at the
- end of every included file. It starts out at 0, its value within
- the base file specified on the command line.
-
-`__ELF__'
- This macro is defined if the target uses the ELF object format.
-
-`__VERSION__'
- This macro expands to a string constant which describes the
- version of the compiler in use. You should not rely on its
- contents having any particular form, but it can be counted on to
- contain at least the release number.
-
-`__OPTIMIZE__'
-`__OPTIMIZE_SIZE__'
-`__NO_INLINE__'
- These macros describe the compilation mode. `__OPTIMIZE__' is
- defined in all optimizing compilations. `__OPTIMIZE_SIZE__' is
- defined if the compiler is optimizing for size, not speed.
- `__NO_INLINE__' is defined if no functions will be inlined into
- their callers (when not optimizing, or when inlining has been
- specifically disabled by `-fno-inline').
-
- These macros cause certain GNU header files to provide optimized
- definitions, using macros or inline functions, of system library
- functions. You should not use these macros in any way unless you
- make sure that programs will execute with the same effect whether
- or not they are defined. If they are defined, their value is 1.
-
-`__GNUC_GNU_INLINE__'
- GCC defines this macro if functions declared `inline' will be
- handled in GCC's traditional gnu90 mode. Object files will contain
- externally visible definitions of all functions declared `inline'
- without `extern' or `static'. They will not contain any
- definitions of any functions declared `extern inline'.
-
-`__GNUC_STDC_INLINE__'
- GCC defines this macro if functions declared `inline' will be
- handled according to the ISO C99 standard. Object files will
- contain externally visible definitions of all functions declared
- `extern inline'. They will not contain definitions of any
- functions declared `inline' without `extern'.
-
- If this macro is defined, GCC supports the `gnu_inline' function
- attribute as a way to always get the gnu90 behavior. Support for
- this and `__GNUC_GNU_INLINE__' was added in GCC 4.1.3. If neither
- macro is defined, an older version of GCC is being used: `inline'
- functions will be compiled in gnu90 mode, and the `gnu_inline'
- function attribute will not be recognized.
-
-`__CHAR_UNSIGNED__'
- GCC defines this macro if and only if the data type `char' is
- unsigned on the target machine. It exists to cause the standard
- header file `limits.h' to work correctly. You should not use this
- macro yourself; instead, refer to the standard macros defined in
- `limits.h'.
-
-`__WCHAR_UNSIGNED__'
- Like `__CHAR_UNSIGNED__', this macro is defined if and only if the
- data type `wchar_t' is unsigned and the front-end is in C++ mode.
-
-`__REGISTER_PREFIX__'
- This macro expands to a single token (not a string constant) which
- is the prefix applied to CPU register names in assembly language
- for this target. You can use it to write assembly that is usable
- in multiple environments. For example, in the `m68k-aout'
- environment it expands to nothing, but in the `m68k-coff'
- environment it expands to a single `%'.
-
-`__USER_LABEL_PREFIX__'
- This macro expands to a single token which is the prefix applied to
- user labels (symbols visible to C code) in assembly. For example,
- in the `m68k-aout' environment it expands to an `_', but in the
- `m68k-coff' environment it expands to nothing.
-
- This macro will have the correct definition even if
- `-f(no-)underscores' is in use, but it will not be correct if
- target-specific options that adjust this prefix are used (e.g. the
- OSF/rose `-mno-underscores' option).
-
-`__SIZE_TYPE__'
-`__PTRDIFF_TYPE__'
-`__WCHAR_TYPE__'
-`__WINT_TYPE__'
-`__INTMAX_TYPE__'
-`__UINTMAX_TYPE__'
-`__SIG_ATOMIC_TYPE__'
-`__INT8_TYPE__'
-`__INT16_TYPE__'
-`__INT32_TYPE__'
-`__INT64_TYPE__'
-`__UINT8_TYPE__'
-`__UINT16_TYPE__'
-`__UINT32_TYPE__'
-`__UINT64_TYPE__'
-`__INT_LEAST8_TYPE__'
-`__INT_LEAST16_TYPE__'
-`__INT_LEAST32_TYPE__'
-`__INT_LEAST64_TYPE__'
-`__UINT_LEAST8_TYPE__'
-`__UINT_LEAST16_TYPE__'
-`__UINT_LEAST32_TYPE__'
-`__UINT_LEAST64_TYPE__'
-`__INT_FAST8_TYPE__'
-`__INT_FAST16_TYPE__'
-`__INT_FAST32_TYPE__'
-`__INT_FAST64_TYPE__'
-`__UINT_FAST8_TYPE__'
-`__UINT_FAST16_TYPE__'
-`__UINT_FAST32_TYPE__'
-`__UINT_FAST64_TYPE__'
-`__INTPTR_TYPE__'
-`__UINTPTR_TYPE__'
- These macros are defined to the correct underlying types for the
- `size_t', `ptrdiff_t', `wchar_t', `wint_t', `intmax_t',
- `uintmax_t', `sig_atomic_t', `int8_t', `int16_t', `int32_t',
- `int64_t', `uint8_t', `uint16_t', `uint32_t', `uint64_t',
- `int_least8_t', `int_least16_t', `int_least32_t', `int_least64_t',
- `uint_least8_t', `uint_least16_t', `uint_least32_t',
- `uint_least64_t', `int_fast8_t', `int_fast16_t', `int_fast32_t',
- `int_fast64_t', `uint_fast8_t', `uint_fast16_t', `uint_fast32_t',
- `uint_fast64_t', `intptr_t', and `uintptr_t' typedefs,
- respectively. They exist to make the standard header files
- `stddef.h', `stdint.h', and `wchar.h' work correctly. You should
- not use these macros directly; instead, include the appropriate
- headers and use the typedefs. Some of these macros may not be
- defined on particular systems if GCC does not provide a `stdint.h'
- header on those systems.
-
-`__CHAR_BIT__'
- Defined to the number of bits used in the representation of the
- `char' data type. It exists to make the standard header given
- numerical limits work correctly. You should not use this macro
- directly; instead, include the appropriate headers.
-
-`__SCHAR_MAX__'
-`__WCHAR_MAX__'
-`__SHRT_MAX__'
-`__INT_MAX__'
-`__LONG_MAX__'
-`__LONG_LONG_MAX__'
-`__WINT_MAX__'
-`__SIZE_MAX__'
-`__PTRDIFF_MAX__'
-`__INTMAX_MAX__'
-`__UINTMAX_MAX__'
-`__SIG_ATOMIC_MAX__'
-`__INT8_MAX__'
-`__INT16_MAX__'
-`__INT32_MAX__'
-`__INT64_MAX__'
-`__UINT8_MAX__'
-`__UINT16_MAX__'
-`__UINT32_MAX__'
-`__UINT64_MAX__'
-`__INT_LEAST8_MAX__'
-`__INT_LEAST16_MAX__'
-`__INT_LEAST32_MAX__'
-`__INT_LEAST64_MAX__'
-`__UINT_LEAST8_MAX__'
-`__UINT_LEAST16_MAX__'
-`__UINT_LEAST32_MAX__'
-`__UINT_LEAST64_MAX__'
-`__INT_FAST8_MAX__'
-`__INT_FAST16_MAX__'
-`__INT_FAST32_MAX__'
-`__INT_FAST64_MAX__'
-`__UINT_FAST8_MAX__'
-`__UINT_FAST16_MAX__'
-`__UINT_FAST32_MAX__'
-`__UINT_FAST64_MAX__'
-`__INTPTR_MAX__'
-`__UINTPTR_MAX__'
-`__WCHAR_MIN__'
-`__WINT_MIN__'
-`__SIG_ATOMIC_MIN__'
- Defined to the maximum value of the `signed char', `wchar_t',
- `signed short', `signed int', `signed long', `signed long long',
- `wint_t', `size_t', `ptrdiff_t', `intmax_t', `uintmax_t',
- `sig_atomic_t', `int8_t', `int16_t', `int32_t', `int64_t',
- `uint8_t', `uint16_t', `uint32_t', `uint64_t', `int_least8_t',
- `int_least16_t', `int_least32_t', `int_least64_t',
- `uint_least8_t', `uint_least16_t', `uint_least32_t',
- `uint_least64_t', `int_fast8_t', `int_fast16_t', `int_fast32_t',
- `int_fast64_t', `uint_fast8_t', `uint_fast16_t', `uint_fast32_t',
- `uint_fast64_t', `intptr_t', and `uintptr_t' types and to the
- minimum value of the `wchar_t', `wint_t', and `sig_atomic_t' types
- respectively. They exist to make the standard header given
- numerical limits work correctly. You should not use these macros
- directly; instead, include the appropriate headers. Some of these
- macros may not be defined on particular systems if GCC does not
- provide a `stdint.h' header on those systems.
-
-`__INT8_C'
-`__INT16_C'
-`__INT32_C'
-`__INT64_C'
-`__UINT8_C'
-`__UINT16_C'
-`__UINT32_C'
-`__UINT64_C'
-`__INTMAX_C'
-`__UINTMAX_C'
- Defined to implementations of the standard `stdint.h' macros with
- the same names without the leading `__'. They exist the make the
- implementation of that header work correctly. You should not use
- these macros directly; instead, include the appropriate headers.
- Some of these macros may not be defined on particular systems if
- GCC does not provide a `stdint.h' header on those systems.
-
-`__SIZEOF_INT__'
-`__SIZEOF_LONG__'
-`__SIZEOF_LONG_LONG__'
-`__SIZEOF_SHORT__'
-`__SIZEOF_POINTER__'
-`__SIZEOF_FLOAT__'
-`__SIZEOF_DOUBLE__'
-`__SIZEOF_LONG_DOUBLE__'
-`__SIZEOF_SIZE_T__'
-`__SIZEOF_WCHAR_T__'
-`__SIZEOF_WINT_T__'
-`__SIZEOF_PTRDIFF_T__'
- Defined to the number of bytes of the C standard data types: `int',
- `long', `long long', `short', `void *', `float', `double', `long
- double', `size_t', `wchar_t', `wint_t' and `ptrdiff_t'.
-
-`__BYTE_ORDER__'
-`__ORDER_LITTLE_ENDIAN__'
-`__ORDER_BIG_ENDIAN__'
-`__ORDER_PDP_ENDIAN__'
- `__BYTE_ORDER__' is defined to one of the values
- `__ORDER_LITTLE_ENDIAN__', `__ORDER_BIG_ENDIAN__', or
- `__ORDER_PDP_ENDIAN__' to reflect the layout of multi-byte and
- multi-word quantities in memory. If `__BYTE_ORDER__' is equal to
- `__ORDER_LITTLE_ENDIAN__' or `__ORDER_BIG_ENDIAN__', then
- multi-byte and multi-word quantities are laid out identically: the
- byte (word) at the lowest address is the least significant or most
- significant byte (word) of the quantity, respectively. If
- `__BYTE_ORDER__' is equal to `__ORDER_PDP_ENDIAN__', then bytes in
- 16-bit words are laid out in a little-endian fashion, whereas the
- 16-bit subwords of a 32-bit quantity are laid out in big-endian
- fashion.
-
- You should use these macros for testing like this:
-
- /* Test for a little-endian machine */
- #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
-
-`__FLOAT_WORD_ORDER__'
- `__FLOAT_WORD_ORDER__' is defined to one of the values
- `__ORDER_LITTLE_ENDIAN__' or `__ORDER_BIG_ENDIAN__' to reflect the
- layout of the words of multi-word floating-point quantities.
-
-`__DEPRECATED'
- This macro is defined, with value 1, when compiling a C++ source
- file with warnings about deprecated constructs enabled. These
- warnings are enabled by default, but can be disabled with
- `-Wno-deprecated'.
-
-`__EXCEPTIONS'
- This macro is defined, with value 1, when compiling a C++ source
- file with exceptions enabled. If `-fno-exceptions' is used when
- compiling the file, then this macro is not defined.
-
-`__GXX_RTTI'
- This macro is defined, with value 1, when compiling a C++ source
- file with runtime type identification enabled. If `-fno-rtti' is
- used when compiling the file, then this macro is not defined.
-
-`__USING_SJLJ_EXCEPTIONS__'
- This macro is defined, with value 1, if the compiler uses the old
- mechanism based on `setjmp' and `longjmp' for exception handling.
-
-`__GXX_EXPERIMENTAL_CXX0X__'
- This macro is defined when compiling a C++ source file with the
- option `-std=c++0x' or `-std=gnu++0x'. It indicates that some
- features likely to be included in C++0x are available. Note that
- these features are experimental, and may change or be removed in
- future versions of GCC.
-
-`__GXX_WEAK__'
- This macro is defined when compiling a C++ source file. It has the
- value 1 if the compiler will use weak symbols, COMDAT sections, or
- other similar techniques to collapse symbols with "vague linkage"
- that are defined in multiple translation units. If the compiler
- will not collapse such symbols, this macro is defined with value
- 0. In general, user code should not need to make use of this
- macro; the purpose of this macro is to ease implementation of the
- C++ runtime library provided with G++.
-
-`__NEXT_RUNTIME__'
- This macro is defined, with value 1, if (and only if) the NeXT
- runtime (as in `-fnext-runtime') is in use for Objective-C. If
- the GNU runtime is used, this macro is not defined, so that you
- can use this macro to determine which runtime (NeXT or GNU) is
- being used.
-
-`__LP64__'
-`_LP64'
- These macros are defined, with value 1, if (and only if) the
- compilation is for a target where `long int' and pointer both use
- 64-bits and `int' uses 32-bit.
-
-`__SSP__'
- This macro is defined, with value 1, when `-fstack-protector' is in
- use.
-
-`__SSP_ALL__'
- This macro is defined, with value 2, when `-fstack-protector-all'
- is in use.
-
-`__TIMESTAMP__'
- This macro expands to a string constant that describes the date
- and time of the last modification of the current source file. The
- string constant contains abbreviated day of the week, month, day
- of the month, time in hh:mm:ss form, year and looks like
- `"Sun Sep 16 01:03:52 1973"'. If the day of the month is less
- than 10, it is padded with a space on the left.
-
- If GCC cannot determine the current date, it will emit a warning
- message (once per compilation) and `__TIMESTAMP__' will expand to
- `"??? ??? ?? ??:??:?? ????"'.
-
-`__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1'
-`__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2'
-`__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4'
-`__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8'
-`__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16'
- These macros are defined when the target processor supports atomic
- compare and swap operations on operands 1, 2, 4, 8 or 16 bytes in
- length, respectively.
-
-`__GCC_HAVE_DWARF2_CFI_ASM'
- This macro is defined when the compiler is emitting Dwarf2 CFI
- directives to the assembler. When this is defined, it is possible
- to emit those same directives in inline assembly.
-
-`__FP_FAST_FMA'
-`__FP_FAST_FMAF'
-`__FP_FAST_FMAL'
- These macros are defined with value 1 if the backend supports the
- `fma', `fmaf', and `fmal' builtin functions, so that the include
- file `math.h' can define the macros `FP_FAST_FMA', `FP_FAST_FMAF',
- and `FP_FAST_FMAL' for compatibility with the 1999 C standard.
-
-
-File: cpp.info, Node: System-specific Predefined Macros, Next: C++ Named Operators, Prev: Common Predefined Macros, Up: Predefined Macros
-
-3.7.3 System-specific Predefined Macros
----------------------------------------
-
-The C preprocessor normally predefines several macros that indicate what
-type of system and machine is in use. They are obviously different on
-each target supported by GCC. This manual, being for all systems and
-machines, cannot tell you what their names are, but you can use `cpp
--dM' to see them all. *Note Invocation::. All system-specific
-predefined macros expand to the constant 1, so you can test them with
-either `#ifdef' or `#if'.
-
- The C standard requires that all system-specific macros be part of
-the "reserved namespace". All names which begin with two underscores,
-or an underscore and a capital letter, are reserved for the compiler and
-library to use as they wish. However, historically system-specific
-macros have had names with no special prefix; for instance, it is common
-to find `unix' defined on Unix systems. For all such macros, GCC
-provides a parallel macro with two underscores added at the beginning
-and the end. If `unix' is defined, `__unix__' will be defined too.
-There will never be more than two underscores; the parallel of `_mips'
-is `__mips__'.
-
- When the `-ansi' option, or any `-std' option that requests strict
-conformance, is given to the compiler, all the system-specific
-predefined macros outside the reserved namespace are suppressed. The
-parallel macros, inside the reserved namespace, remain defined.
-
- We are slowly phasing out all predefined macros which are outside the
-reserved namespace. You should never use them in new programs, and we
-encourage you to correct older code to use the parallel macros whenever
-you find it. We don't recommend you use the system-specific macros that
-are in the reserved namespace, either. It is better in the long run to
-check specifically for features you need, using a tool such as
-`autoconf'.
-
-
-File: cpp.info, Node: C++ Named Operators, Prev: System-specific Predefined Macros, Up: Predefined Macros
-
-3.7.4 C++ Named Operators
--------------------------
-
-In C++, there are eleven keywords which are simply alternate spellings
-of operators normally written with punctuation. These keywords are
-treated as such even in the preprocessor. They function as operators in
-`#if', and they cannot be defined as macros or poisoned. In C, you can
-request that those keywords take their C++ meaning by including
-`iso646.h'. That header defines each one as a normal object-like macro
-expanding to the appropriate punctuator.
-
- These are the named operators and their corresponding punctuators:
-
-Named Operator Punctuator
-`and' `&&'
-`and_eq' `&='
-`bitand' `&'
-`bitor' `|'
-`compl' `~'
-`not' `!'
-`not_eq' `!='
-`or' `||'
-`or_eq' `|='
-`xor' `^'
-`xor_eq' `^='
-
-
-File: cpp.info, Node: Undefining and Redefining Macros, Next: Directives Within Macro Arguments, Prev: Predefined Macros, Up: Macros
-
-3.8 Undefining and Redefining Macros
-====================================
-
-If a macro ceases to be useful, it may be "undefined" with the `#undef'
-directive. `#undef' takes a single argument, the name of the macro to
-undefine. You use the bare macro name, even if the macro is
-function-like. It is an error if anything appears on the line after
-the macro name. `#undef' has no effect if the name is not a macro.
-
- #define FOO 4
- x = FOO; ==> x = 4;
- #undef FOO
- x = FOO; ==> x = FOO;
-
- Once a macro has been undefined, that identifier may be "redefined"
-as a macro by a subsequent `#define' directive. The new definition
-need not have any resemblance to the old definition.
-
- However, if an identifier which is currently a macro is redefined,
-then the new definition must be "effectively the same" as the old one.
-Two macro definitions are effectively the same if:
- * Both are the same type of macro (object- or function-like).
-
- * All the tokens of the replacement list are the same.
-
- * If there are any parameters, they are the same.
-
- * Whitespace appears in the same places in both. It need not be
- exactly the same amount of whitespace, though. Remember that
- comments count as whitespace.
-
-These definitions are effectively the same:
- #define FOUR (2 + 2)
- #define FOUR (2 + 2)
- #define FOUR (2 /* two */ + 2)
- but these are not:
- #define FOUR (2 + 2)
- #define FOUR ( 2+2 )
- #define FOUR (2 * 2)
- #define FOUR(score,and,seven,years,ago) (2 + 2)
-
- If a macro is redefined with a definition that is not effectively the
-same as the old one, the preprocessor issues a warning and changes the
-macro to use the new definition. If the new definition is effectively
-the same, the redefinition is silently ignored. This allows, for
-instance, two different headers to define a common macro. The
-preprocessor will only complain if the definitions do not match.
-
-
-File: cpp.info, Node: Directives Within Macro Arguments, Next: Macro Pitfalls, Prev: Undefining and Redefining Macros, Up: Macros
-
-3.9 Directives Within Macro Arguments
-=====================================
-
-Occasionally it is convenient to use preprocessor directives within the
-arguments of a macro. The C and C++ standards declare that behavior in
-these cases is undefined.
-
- Versions of CPP prior to 3.2 would reject such constructs with an
-error message. This was the only syntactic difference between normal
-functions and function-like macros, so it seemed attractive to remove
-this limitation, and people would often be surprised that they could
-not use macros in this way. Moreover, sometimes people would use
-conditional compilation in the argument list to a normal library
-function like `printf', only to find that after a library upgrade
-`printf' had changed to be a function-like macro, and their code would
-no longer compile. So from version 3.2 we changed CPP to successfully
-process arbitrary directives within macro arguments in exactly the same
-way as it would have processed the directive were the function-like
-macro invocation not present.
-
- If, within a macro invocation, that macro is redefined, then the new
-definition takes effect in time for argument pre-expansion, but the
-original definition is still used for argument replacement. Here is a
-pathological example:
-
- #define f(x) x x
- f (1
- #undef f
- #define f 2
- f)
-
-which expands to
-
- 1 2 1 2
-
-with the semantics described above.
-
-
-File: cpp.info, Node: Macro Pitfalls, Prev: Directives Within Macro Arguments, Up: Macros
-
-3.10 Macro Pitfalls
-===================
-
-In this section we describe some special rules that apply to macros and
-macro expansion, and point out certain cases in which the rules have
-counter-intuitive consequences that you must watch out for.
-
-* Menu:
-
-* Misnesting::
-* Operator Precedence Problems::
-* Swallowing the Semicolon::
-* Duplication of Side Effects::
-* Self-Referential Macros::
-* Argument Prescan::
-* Newlines in Arguments::
-
-
-File: cpp.info, Node: Misnesting, Next: Operator Precedence Problems, Up: Macro Pitfalls
-
-3.10.1 Misnesting
------------------
-
-When a macro is called with arguments, the arguments are substituted
-into the macro body and the result is checked, together with the rest of
-the input file, for more macro calls. It is possible to piece together
-a macro call coming partially from the macro body and partially from the
-arguments. For example,
-
- #define twice(x) (2*(x))
- #define call_with_1(x) x(1)
- call_with_1 (twice)
- ==> twice(1)
- ==> (2*(1))
-
- Macro definitions do not have to have balanced parentheses. By
-writing an unbalanced open parenthesis in a macro body, it is possible
-to create a macro call that begins inside the macro body but ends
-outside of it. For example,
-
- #define strange(file) fprintf (file, "%s %d",
- ...
- strange(stderr) p, 35)
- ==> fprintf (stderr, "%s %d", p, 35)
-
- The ability to piece together a macro call can be useful, but the
-use of unbalanced open parentheses in a macro body is just confusing,
-and should be avoided.
-
-
-File: cpp.info, Node: Operator Precedence Problems, Next: Swallowing the Semicolon, Prev: Misnesting, Up: Macro Pitfalls
-
-3.10.2 Operator Precedence Problems
------------------------------------
-
-You may have noticed that in most of the macro definition examples shown
-above, each occurrence of a macro argument name had parentheses around
-it. In addition, another pair of parentheses usually surround the
-entire macro definition. Here is why it is best to write macros that
-way.
-
- Suppose you define a macro as follows,
-
- #define ceil_div(x, y) (x + y - 1) / y
-
-whose purpose is to divide, rounding up. (One use for this operation is
-to compute how many `int' objects are needed to hold a certain number
-of `char' objects.) Then suppose it is used as follows:
-
- a = ceil_div (b & c, sizeof (int));
- ==> a = (b & c + sizeof (int) - 1) / sizeof (int);
-
-This does not do what is intended. The operator-precedence rules of C
-make it equivalent to this:
-
- a = (b & (c + sizeof (int) - 1)) / sizeof (int);
-
-What we want is this:
-
- a = ((b & c) + sizeof (int) - 1)) / sizeof (int);
-
-Defining the macro as
-
- #define ceil_div(x, y) ((x) + (y) - 1) / (y)
-
-provides the desired result.
-
- Unintended grouping can result in another way. Consider `sizeof
-ceil_div(1, 2)'. That has the appearance of a C expression that would
-compute the size of the type of `ceil_div (1, 2)', but in fact it means
-something very different. Here is what it expands to:
-
- sizeof ((1) + (2) - 1) / (2)
-
-This would take the size of an integer and divide it by two. The
-precedence rules have put the division outside the `sizeof' when it was
-intended to be inside.
-
- Parentheses around the entire macro definition prevent such problems.
-Here, then, is the recommended way to define `ceil_div':
-
- #define ceil_div(x, y) (((x) + (y) - 1) / (y))
-
-
-File: cpp.info, Node: Swallowing the Semicolon, Next: Duplication of Side Effects, Prev: Operator Precedence Problems, Up: Macro Pitfalls
-
-3.10.3 Swallowing the Semicolon
--------------------------------
-
-Often it is desirable to define a macro that expands into a compound
-statement. Consider, for example, the following macro, that advances a
-pointer (the argument `p' says where to find it) across whitespace
-characters:
-
- #define SKIP_SPACES(p, limit) \
- { char *lim = (limit); \
- while (p < lim) { \
- if (*p++ != ' ') { \
- p--; break; }}}
-
-Here backslash-newline is used to split the macro definition, which must
-be a single logical line, so that it resembles the way such code would
-be laid out if not part of a macro definition.
-
- A call to this macro might be `SKIP_SPACES (p, lim)'. Strictly
-speaking, the call expands to a compound statement, which is a complete
-statement with no need for a semicolon to end it. However, since it
-looks like a function call, it minimizes confusion if you can use it
-like a function call, writing a semicolon afterward, as in `SKIP_SPACES
-(p, lim);'
-
- This can cause trouble before `else' statements, because the
-semicolon is actually a null statement. Suppose you write
-
- if (*p != 0)
- SKIP_SPACES (p, lim);
- else ...
-
-The presence of two statements--the compound statement and a null
-statement--in between the `if' condition and the `else' makes invalid C
-code.
-
- The definition of the macro `SKIP_SPACES' can be altered to solve
-this problem, using a `do ... while' statement. Here is how:
-
- #define SKIP_SPACES(p, limit) \
- do { char *lim = (limit); \
- while (p < lim) { \
- if (*p++ != ' ') { \
- p--; break; }}} \
- while (0)
-
- Now `SKIP_SPACES (p, lim);' expands into
-
- do {...} while (0);
-
-which is one statement. The loop executes exactly once; most compilers
-generate no extra code for it.
-
-
-File: cpp.info, Node: Duplication of Side Effects, Next: Self-Referential Macros, Prev: Swallowing the Semicolon, Up: Macro Pitfalls
-
-3.10.4 Duplication of Side Effects
-----------------------------------
-
-Many C programs define a macro `min', for "minimum", like this:
-
- #define min(X, Y) ((X) < (Y) ? (X) : (Y))
-
- When you use this macro with an argument containing a side effect,
-as shown here,
-
- next = min (x + y, foo (z));
-
-it expands as follows:
-
- next = ((x + y) < (foo (z)) ? (x + y) : (foo (z)));
-
-where `x + y' has been substituted for `X' and `foo (z)' for `Y'.
-
- The function `foo' is used only once in the statement as it appears
-in the program, but the expression `foo (z)' has been substituted twice
-into the macro expansion. As a result, `foo' might be called two times
-when the statement is executed. If it has side effects or if it takes
-a long time to compute, the results might not be what you intended. We
-say that `min' is an "unsafe" macro.
-
- The best solution to this problem is to define `min' in a way that
-computes the value of `foo (z)' only once. The C language offers no
-standard way to do this, but it can be done with GNU extensions as
-follows:
-
- #define min(X, Y) \
- ({ typeof (X) x_ = (X); \
- typeof (Y) y_ = (Y); \
- (x_ < y_) ? x_ : y_; })
-
- The `({ ... })' notation produces a compound statement that acts as
-an expression. Its value is the value of its last statement. This
-permits us to define local variables and assign each argument to one.
-The local variables have underscores after their names to reduce the
-risk of conflict with an identifier of wider scope (it is impossible to
-avoid this entirely). Now each argument is evaluated exactly once.
-
- If you do not wish to use GNU C extensions, the only solution is to
-be careful when _using_ the macro `min'. For example, you can
-calculate the value of `foo (z)', save it in a variable, and use that
-variable in `min':
-
- #define min(X, Y) ((X) < (Y) ? (X) : (Y))
- ...
- {
- int tem = foo (z);
- next = min (x + y, tem);
- }
-
-(where we assume that `foo' returns type `int').
-
-
-File: cpp.info, Node: Self-Referential Macros, Next: Argument Prescan, Prev: Duplication of Side Effects, Up: Macro Pitfalls
-
-3.10.5 Self-Referential Macros
-------------------------------
-
-A "self-referential" macro is one whose name appears in its definition.
-Recall that all macro definitions are rescanned for more macros to
-replace. If the self-reference were considered a use of the macro, it
-would produce an infinitely large expansion. To prevent this, the
-self-reference is not considered a macro call. It is passed into the
-preprocessor output unchanged. Consider an example:
-
- #define foo (4 + foo)
-
-where `foo' is also a variable in your program.
-
- Following the ordinary rules, each reference to `foo' will expand
-into `(4 + foo)'; then this will be rescanned and will expand into `(4
-+ (4 + foo))'; and so on until the computer runs out of memory.
-
- The self-reference rule cuts this process short after one step, at
-`(4 + foo)'. Therefore, this macro definition has the possibly useful
-effect of causing the program to add 4 to the value of `foo' wherever
-`foo' is referred to.
-
- In most cases, it is a bad idea to take advantage of this feature. A
-person reading the program who sees that `foo' is a variable will not
-expect that it is a macro as well. The reader will come across the
-identifier `foo' in the program and think its value should be that of
-the variable `foo', whereas in fact the value is four greater.
-
- One common, useful use of self-reference is to create a macro which
-expands to itself. If you write
-
- #define EPERM EPERM
-
-then the macro `EPERM' expands to `EPERM'. Effectively, it is left
-alone by the preprocessor whenever it's used in running text. You can
-tell that it's a macro with `#ifdef'. You might do this if you want to
-define numeric constants with an `enum', but have `#ifdef' be true for
-each constant.
-
- If a macro `x' expands to use a macro `y', and the expansion of `y'
-refers to the macro `x', that is an "indirect self-reference" of `x'.
-`x' is not expanded in this case either. Thus, if we have
-
- #define x (4 + y)
- #define y (2 * x)
-
-then `x' and `y' expand as follows:
-
- x ==> (4 + y)
- ==> (4 + (2 * x))
-
- y ==> (2 * x)
- ==> (2 * (4 + y))
-
-Each macro is expanded when it appears in the definition of the other
-macro, but not when it indirectly appears in its own definition.
-
-
-File: cpp.info, Node: Argument Prescan, Next: Newlines in Arguments, Prev: Self-Referential Macros, Up: Macro Pitfalls
-
-3.10.6 Argument Prescan
------------------------
-
-Macro arguments are completely macro-expanded before they are
-substituted into a macro body, unless they are stringified or pasted
-with other tokens. After substitution, the entire macro body, including
-the substituted arguments, is scanned again for macros to be expanded.
-The result is that the arguments are scanned _twice_ to expand macro
-calls in them.
-
- Most of the time, this has no effect. If the argument contained any
-macro calls, they are expanded during the first scan. The result
-therefore contains no macro calls, so the second scan does not change
-it. If the argument were substituted as given, with no prescan, the
-single remaining scan would find the same macro calls and produce the
-same results.
-
- You might expect the double scan to change the results when a
-self-referential macro is used in an argument of another macro (*note
-Self-Referential Macros::): the self-referential macro would be
-expanded once in the first scan, and a second time in the second scan.
-However, this is not what happens. The self-references that do not
-expand in the first scan are marked so that they will not expand in the
-second scan either.
-
- You might wonder, "Why mention the prescan, if it makes no
-difference? And why not skip it and make the preprocessor faster?"
-The answer is that the prescan does make a difference in three special
-cases:
-
- * Nested calls to a macro.
-
- We say that "nested" calls to a macro occur when a macro's argument
- contains a call to that very macro. For example, if `f' is a macro
- that expects one argument, `f (f (1))' is a nested pair of calls to
- `f'. The desired expansion is made by expanding `f (1)' and
- substituting that into the definition of `f'. The prescan causes
- the expected result to happen. Without the prescan, `f (1)' itself
- would be substituted as an argument, and the inner use of `f' would
- appear during the main scan as an indirect self-reference and
- would not be expanded.
-
- * Macros that call other macros that stringify or concatenate.
-
- If an argument is stringified or concatenated, the prescan does not
- occur. If you _want_ to expand a macro, then stringify or
- concatenate its expansion, you can do that by causing one macro to
- call another macro that does the stringification or concatenation.
- For instance, if you have
-
- #define AFTERX(x) X_ ## x
- #define XAFTERX(x) AFTERX(x)
- #define TABLESIZE 1024
- #define BUFSIZE TABLESIZE
-
- then `AFTERX(BUFSIZE)' expands to `X_BUFSIZE', and
- `XAFTERX(BUFSIZE)' expands to `X_1024'. (Not to `X_TABLESIZE'.
- Prescan always does a complete expansion.)
-
- * Macros used in arguments, whose expansions contain unshielded
- commas.
-
- This can cause a macro expanded on the second scan to be called
- with the wrong number of arguments. Here is an example:
-
- #define foo a,b
- #define bar(x) lose(x)
- #define lose(x) (1 + (x))
-
- We would like `bar(foo)' to turn into `(1 + (foo))', which would
- then turn into `(1 + (a,b))'. Instead, `bar(foo)' expands into
- `lose(a,b)', and you get an error because `lose' requires a single
- argument. In this case, the problem is easily solved by the same
- parentheses that ought to be used to prevent misnesting of
- arithmetic operations:
-
- #define foo (a,b)
- or
- #define bar(x) lose((x))
-
- The extra pair of parentheses prevents the comma in `foo''s
- definition from being interpreted as an argument separator.
-
-
-
-File: cpp.info, Node: Newlines in Arguments, Prev: Argument Prescan, Up: Macro Pitfalls
-
-3.10.7 Newlines in Arguments
-----------------------------
-
-The invocation of a function-like macro can extend over many logical
-lines. However, in the present implementation, the entire expansion
-comes out on one line. Thus line numbers emitted by the compiler or
-debugger refer to the line the invocation started on, which might be
-different to the line containing the argument causing the problem.
-
- Here is an example illustrating this:
-
- #define ignore_second_arg(a,b,c) a; c
-
- ignore_second_arg (foo (),
- ignored (),
- syntax error);
-
-The syntax error triggered by the tokens `syntax error' results in an
-error message citing line three--the line of ignore_second_arg-- even
-though the problematic code comes from line five.
-
- We consider this a bug, and intend to fix it in the near future.
-
-
-File: cpp.info, Node: Conditionals, Next: Diagnostics, Prev: Macros, Up: Top
-
-4 Conditionals
-**************
-
-A "conditional" is a directive that instructs the preprocessor to
-select whether or not to include a chunk of code in the final token
-stream passed to the compiler. Preprocessor conditionals can test
-arithmetic expressions, or whether a name is defined as a macro, or both
-simultaneously using the special `defined' operator.
-
- A conditional in the C preprocessor resembles in some ways an `if'
-statement in C, but it is important to understand the difference between
-them. The condition in an `if' statement is tested during the
-execution of your program. Its purpose is to allow your program to
-behave differently from run to run, depending on the data it is
-operating on. The condition in a preprocessing conditional directive is
-tested when your program is compiled. Its purpose is to allow different
-code to be included in the program depending on the situation at the
-time of compilation.
-
- However, the distinction is becoming less clear. Modern compilers
-often do test `if' statements when a program is compiled, if their
-conditions are known not to vary at run time, and eliminate code which
-can never be executed. If you can count on your compiler to do this,
-you may find that your program is more readable if you use `if'
-statements with constant conditions (perhaps determined by macros). Of
-course, you can only use this to exclude code, not type definitions or
-other preprocessing directives, and you can only do it if the code
-remains syntactically valid when it is not to be used.
-
- GCC version 3 eliminates this kind of never-executed code even when
-not optimizing. Older versions did it only when optimizing.
-
-* Menu:
-
-* Conditional Uses::
-* Conditional Syntax::
-* Deleted Code::
-
-
-File: cpp.info, Node: Conditional Uses, Next: Conditional Syntax, Up: Conditionals
-
-4.1 Conditional Uses
-====================
-
-There are three general reasons to use a conditional.
-
- * A program may need to use different code depending on the machine
- or operating system it is to run on. In some cases the code for
- one operating system may be erroneous on another operating system;
- for example, it might refer to data types or constants that do not
- exist on the other system. When this happens, it is not enough to
- avoid executing the invalid code. Its mere presence will cause
- the compiler to reject the program. With a preprocessing
- conditional, the offending code can be effectively excised from
- the program when it is not valid.
-
- * You may want to be able to compile the same source file into two
- different programs. One version might make frequent time-consuming
- consistency checks on its intermediate data, or print the values of
- those data for debugging, and the other not.
-
- * A conditional whose condition is always false is one way to
- exclude code from the program but keep it as a sort of comment for
- future reference.
-
- Simple programs that do not need system-specific logic or complex
-debugging hooks generally will not need to use preprocessing
-conditionals.
-
-
-File: cpp.info, Node: Conditional Syntax, Next: Deleted Code, Prev: Conditional Uses, Up: Conditionals
-
-4.2 Conditional Syntax
-======================
-
-A conditional in the C preprocessor begins with a "conditional
-directive": `#if', `#ifdef' or `#ifndef'.
-
-* Menu:
-
-* Ifdef::
-* If::
-* Defined::
-* Else::
-* Elif::
-
-
-File: cpp.info, Node: Ifdef, Next: If, Up: Conditional Syntax
-
-4.2.1 Ifdef
------------
-
-The simplest sort of conditional is
-
- #ifdef MACRO
-
- CONTROLLED TEXT
-
- #endif /* MACRO */
-
- This block is called a "conditional group". CONTROLLED TEXT will be
-included in the output of the preprocessor if and only if MACRO is
-defined. We say that the conditional "succeeds" if MACRO is defined,
-"fails" if it is not.
-
- The CONTROLLED TEXT inside of a conditional can include
-preprocessing directives. They are executed only if the conditional
-succeeds. You can nest conditional groups inside other conditional
-groups, but they must be completely nested. In other words, `#endif'
-always matches the nearest `#ifdef' (or `#ifndef', or `#if'). Also,
-you cannot start a conditional group in one file and end it in another.
-
- Even if a conditional fails, the CONTROLLED TEXT inside it is still
-run through initial transformations and tokenization. Therefore, it
-must all be lexically valid C. Normally the only way this matters is
-that all comments and string literals inside a failing conditional group
-must still be properly ended.
-
- The comment following the `#endif' is not required, but it is a good
-practice if there is a lot of CONTROLLED TEXT, because it helps people
-match the `#endif' to the corresponding `#ifdef'. Older programs
-sometimes put MACRO directly after the `#endif' without enclosing it in
-a comment. This is invalid code according to the C standard. CPP
-accepts it with a warning. It never affects which `#ifndef' the
-`#endif' matches.
-
- Sometimes you wish to use some code if a macro is _not_ defined.
-You can do this by writing `#ifndef' instead of `#ifdef'. One common
-use of `#ifndef' is to include code only the first time a header file
-is included. *Note Once-Only Headers::.
-
- Macro definitions can vary between compilations for several reasons.
-Here are some samples.
-
- * Some macros are predefined on each kind of machine (*note
- System-specific Predefined Macros::). This allows you to provide
- code specially tuned for a particular machine.
-
- * System header files define more macros, associated with the
- features they implement. You can test these macros with
- conditionals to avoid using a system feature on a machine where it
- is not implemented.
-
- * Macros can be defined or undefined with the `-D' and `-U' command
- line options when you compile the program. You can arrange to
- compile the same source file into two different programs by
- choosing a macro name to specify which program you want, writing
- conditionals to test whether or how this macro is defined, and
- then controlling the state of the macro with command line options,
- perhaps set in the Makefile. *Note Invocation::.
-
- * Your program might have a special header file (often called
- `config.h') that is adjusted when the program is compiled. It can
- define or not define macros depending on the features of the
- system and the desired capabilities of the program. The
- adjustment can be automated by a tool such as `autoconf', or done
- by hand.
-
-
-File: cpp.info, Node: If, Next: Defined, Prev: Ifdef, Up: Conditional Syntax
-
-4.2.2 If
---------
-
-The `#if' directive allows you to test the value of an arithmetic
-expression, rather than the mere existence of one macro. Its syntax is
-
- #if EXPRESSION
-
- CONTROLLED TEXT
-
- #endif /* EXPRESSION */
-
- EXPRESSION is a C expression of integer type, subject to stringent
-restrictions. It may contain
-
- * Integer constants.
-
- * Character constants, which are interpreted as they would be in
- normal code.
-
- * Arithmetic operators for addition, subtraction, multiplication,
- division, bitwise operations, shifts, comparisons, and logical
- operations (`&&' and `||'). The latter two obey the usual
- short-circuiting rules of standard C.
-
- * Macros. All macros in the expression are expanded before actual
- computation of the expression's value begins.
-
- * Uses of the `defined' operator, which lets you check whether macros
- are defined in the middle of an `#if'.
-
- * Identifiers that are not macros, which are all considered to be the
- number zero. This allows you to write `#if MACRO' instead of
- `#ifdef MACRO', if you know that MACRO, when defined, will always
- have a nonzero value. Function-like macros used without their
- function call parentheses are also treated as zero.
-
- In some contexts this shortcut is undesirable. The `-Wundef'
- option causes GCC to warn whenever it encounters an identifier
- which is not a macro in an `#if'.
-
- The preprocessor does not know anything about types in the language.
-Therefore, `sizeof' operators are not recognized in `#if', and neither
-are `enum' constants. They will be taken as identifiers which are not
-macros, and replaced by zero. In the case of `sizeof', this is likely
-to cause the expression to be invalid.
-
- The preprocessor calculates the value of EXPRESSION. It carries out
-all calculations in the widest integer type known to the compiler; on
-most machines supported by GCC this is 64 bits. This is not the same
-rule as the compiler uses to calculate the value of a constant
-expression, and may give different results in some cases. If the value
-comes out to be nonzero, the `#if' succeeds and the CONTROLLED TEXT is
-included; otherwise it is skipped.
-
-
-File: cpp.info, Node: Defined, Next: Else, Prev: If, Up: Conditional Syntax
-
-4.2.3 Defined
--------------
-
-The special operator `defined' is used in `#if' and `#elif' expressions
-to test whether a certain name is defined as a macro. `defined NAME'
-and `defined (NAME)' are both expressions whose value is 1 if NAME is
-defined as a macro at the current point in the program, and 0
-otherwise. Thus, `#if defined MACRO' is precisely equivalent to
-`#ifdef MACRO'.
-
- `defined' is useful when you wish to test more than one macro for
-existence at once. For example,
-
- #if defined (__vax__) || defined (__ns16000__)
-
-would succeed if either of the names `__vax__' or `__ns16000__' is
-defined as a macro.
-
- Conditionals written like this:
-
- #if defined BUFSIZE && BUFSIZE >= 1024
-
-can generally be simplified to just `#if BUFSIZE >= 1024', since if
-`BUFSIZE' is not defined, it will be interpreted as having the value
-zero.
-
- If the `defined' operator appears as a result of a macro expansion,
-the C standard says the behavior is undefined. GNU cpp treats it as a
-genuine `defined' operator and evaluates it normally. It will warn
-wherever your code uses this feature if you use the command-line option
-`-pedantic', since other compilers may handle it differently.
-
-
-File: cpp.info, Node: Else, Next: Elif, Prev: Defined, Up: Conditional Syntax
-
-4.2.4 Else
-----------
-
-The `#else' directive can be added to a conditional to provide
-alternative text to be used if the condition fails. This is what it
-looks like:
-
- #if EXPRESSION
- TEXT-IF-TRUE
- #else /* Not EXPRESSION */
- TEXT-IF-FALSE
- #endif /* Not EXPRESSION */
-
-If EXPRESSION is nonzero, the TEXT-IF-TRUE is included and the
-TEXT-IF-FALSE is skipped. If EXPRESSION is zero, the opposite happens.
-
- You can use `#else' with `#ifdef' and `#ifndef', too.
-
-
-File: cpp.info, Node: Elif, Prev: Else, Up: Conditional Syntax
-
-4.2.5 Elif
-----------
-
-One common case of nested conditionals is used to check for more than
-two possible alternatives. For example, you might have
-
- #if X == 1
- ...
- #else /* X != 1 */
- #if X == 2
- ...
- #else /* X != 2 */
- ...
- #endif /* X != 2 */
- #endif /* X != 1 */
-
- Another conditional directive, `#elif', allows this to be
-abbreviated as follows:
-
- #if X == 1
- ...
- #elif X == 2
- ...
- #else /* X != 2 and X != 1*/
- ...
- #endif /* X != 2 and X != 1*/
-
- `#elif' stands for "else if". Like `#else', it goes in the middle
-of a conditional group and subdivides it; it does not require a
-matching `#endif' of its own. Like `#if', the `#elif' directive
-includes an expression to be tested. The text following the `#elif' is
-processed only if the original `#if'-condition failed and the `#elif'
-condition succeeds.
-
- More than one `#elif' can go in the same conditional group. Then
-the text after each `#elif' is processed only if the `#elif' condition
-succeeds after the original `#if' and all previous `#elif' directives
-within it have failed.
-
- `#else' is allowed after any number of `#elif' directives, but
-`#elif' may not follow `#else'.
-
-
-File: cpp.info, Node: Deleted Code, Prev: Conditional Syntax, Up: Conditionals
-
-4.3 Deleted Code
-================
-
-If you replace or delete a part of the program but want to keep the old
-code around for future reference, you often cannot simply comment it
-out. Block comments do not nest, so the first comment inside the old
-code will end the commenting-out. The probable result is a flood of
-syntax errors.
-
- One way to avoid this problem is to use an always-false conditional
-instead. For instance, put `#if 0' before the deleted code and
-`#endif' after it. This works even if the code being turned off
-contains conditionals, but they must be entire conditionals (balanced
-`#if' and `#endif').
-
- Some people use `#ifdef notdef' instead. This is risky, because
-`notdef' might be accidentally defined as a macro, and then the
-conditional would succeed. `#if 0' can be counted on to fail.
-
- Do not use `#if 0' for comments which are not C code. Use a real
-comment, instead. The interior of `#if 0' must consist of complete
-tokens; in particular, single-quote characters must balance. Comments
-often contain unbalanced single-quote characters (known in English as
-apostrophes). These confuse `#if 0'. They don't confuse `/*'.
-
-
-File: cpp.info, Node: Diagnostics, Next: Line Control, Prev: Conditionals, Up: Top
-
-5 Diagnostics
-*************
-
-The directive `#error' causes the preprocessor to report a fatal error.
-The tokens forming the rest of the line following `#error' are used as
-the error message.
-
- You would use `#error' inside of a conditional that detects a
-combination of parameters which you know the program does not properly
-support. For example, if you know that the program will not run
-properly on a VAX, you might write
-
- #ifdef __vax__
- #error "Won't work on VAXen. See comments at get_last_object."
- #endif
-
- If you have several configuration parameters that must be set up by
-the installation in a consistent way, you can use conditionals to detect
-an inconsistency and report it with `#error'. For example,
-
- #if !defined(UNALIGNED_INT_ASM_OP) && defined(DWARF2_DEBUGGING_INFO)
- #error "DWARF2_DEBUGGING_INFO requires UNALIGNED_INT_ASM_OP."
- #endif
-
- The directive `#warning' is like `#error', but causes the
-preprocessor to issue a warning and continue preprocessing. The tokens
-following `#warning' are used as the warning message.
-
- You might use `#warning' in obsolete header files, with a message
-directing the user to the header file which should be used instead.
-
- Neither `#error' nor `#warning' macro-expands its argument.
-Internal whitespace sequences are each replaced with a single space.
-The line must consist of complete tokens. It is wisest to make the
-argument of these directives be a single string constant; this avoids
-problems with apostrophes and the like.
-
-
-File: cpp.info, Node: Line Control, Next: Pragmas, Prev: Diagnostics, Up: Top
-
-6 Line Control
-**************
-
-The C preprocessor informs the C compiler of the location in your source
-code where each token came from. Presently, this is just the file name
-and line number. All the tokens resulting from macro expansion are
-reported as having appeared on the line of the source file where the
-outermost macro was used. We intend to be more accurate in the future.
-
- If you write a program which generates source code, such as the
-`bison' parser generator, you may want to adjust the preprocessor's
-notion of the current file name and line number by hand. Parts of the
-output from `bison' are generated from scratch, other parts come from a
-standard parser file. The rest are copied verbatim from `bison''s
-input. You would like compiler error messages and symbolic debuggers
-to be able to refer to `bison''s input file.
-
- `bison' or any such program can arrange this by writing `#line'
-directives into the output file. `#line' is a directive that specifies
-the original line number and source file name for subsequent input in
-the current preprocessor input file. `#line' has three variants:
-
-`#line LINENUM'
- LINENUM is a non-negative decimal integer constant. It specifies
- the line number which should be reported for the following line of
- input. Subsequent lines are counted from LINENUM.
-
-`#line LINENUM FILENAME'
- LINENUM is the same as for the first form, and has the same
- effect. In addition, FILENAME is a string constant. The
- following line and all subsequent lines are reported to come from
- the file it specifies, until something else happens to change that.
- FILENAME is interpreted according to the normal rules for a string
- constant: backslash escapes are interpreted. This is different
- from `#include'.
-
- Previous versions of CPP did not interpret escapes in `#line'; we
- have changed it because the standard requires they be interpreted,
- and most other compilers do.
-
-`#line ANYTHING ELSE'
- ANYTHING ELSE is checked for macro calls, which are expanded. The
- result should match one of the above two forms.
-
- `#line' directives alter the results of the `__FILE__' and
-`__LINE__' predefined macros from that point on. *Note Standard
-Predefined Macros::. They do not have any effect on `#include''s idea
-of the directory containing the current file. This is a change from
-GCC 2.95. Previously, a file reading
-
- #line 1 "../src/gram.y"
- #include "gram.h"
-
- would search for `gram.h' in `../src', then the `-I' chain; the
-directory containing the physical source file would not be searched.
-In GCC 3.0 and later, the `#include' is not affected by the presence of
-a `#line' referring to a different directory.
-
- We made this change because the old behavior caused problems when
-generated source files were transported between machines. For instance,
-it is common practice to ship generated parsers with a source release,
-so that people building the distribution do not need to have yacc or
-Bison installed. These files frequently have `#line' directives
-referring to the directory tree of the system where the distribution was
-created. If GCC tries to search for headers in those directories, the
-build is likely to fail.
-
- The new behavior can cause failures too, if the generated file is not
-in the same directory as its source and it attempts to include a header
-which would be visible searching from the directory containing the
-source file. However, this problem is easily solved with an additional
-`-I' switch on the command line. The failures caused by the old
-semantics could sometimes be corrected only by editing the generated
-files, which is difficult and error-prone.
-
-
-File: cpp.info, Node: Pragmas, Next: Other Directives, Prev: Line Control, Up: Top
-
-7 Pragmas
-*********
-
-The `#pragma' directive is the method specified by the C standard for
-providing additional information to the compiler, beyond what is
-conveyed in the language itself. Three forms of this directive
-(commonly known as "pragmas") are specified by the 1999 C standard. A
-C compiler is free to attach any meaning it likes to other pragmas.
-
- GCC has historically preferred to use extensions to the syntax of the
-language, such as `__attribute__', for this purpose. However, GCC does
-define a few pragmas of its own. These mostly have effects on the
-entire translation unit or source file.
-
- In GCC version 3, all GNU-defined, supported pragmas have been given
-a `GCC' prefix. This is in line with the `STDC' prefix on all pragmas
-defined by C99. For backward compatibility, pragmas which were
-recognized by previous versions are still recognized without the `GCC'
-prefix, but that usage is deprecated. Some older pragmas are
-deprecated in their entirety. They are not recognized with the `GCC'
-prefix. *Note Obsolete Features::.
-
- C99 introduces the `_Pragma' operator. This feature addresses a
-major problem with `#pragma': being a directive, it cannot be produced
-as the result of macro expansion. `_Pragma' is an operator, much like
-`sizeof' or `defined', and can be embedded in a macro.
-
- Its syntax is `_Pragma (STRING-LITERAL)', where STRING-LITERAL can
-be either a normal or wide-character string literal. It is
-destringized, by replacing all `\\' with a single `\' and all `\"' with
-a `"'. The result is then processed as if it had appeared as the right
-hand side of a `#pragma' directive. For example,
-
- _Pragma ("GCC dependency \"parse.y\"")
-
-has the same effect as `#pragma GCC dependency "parse.y"'. The same
-effect could be achieved using macros, for example
-
- #define DO_PRAGMA(x) _Pragma (#x)
- DO_PRAGMA (GCC dependency "parse.y")
-
- The standard is unclear on where a `_Pragma' operator can appear.
-The preprocessor does not accept it within a preprocessing conditional
-directive like `#if'. To be safe, you are probably best keeping it out
-of directives other than `#define', and putting it on a line of its own.
-
- This manual documents the pragmas which are meaningful to the
-preprocessor itself. Other pragmas are meaningful to the C or C++
-compilers. They are documented in the GCC manual.
-
- GCC plugins may provide their own pragmas.
-
-`#pragma GCC dependency'
- `#pragma GCC dependency' allows you to check the relative dates of
- the current file and another file. If the other file is more
- recent than the current file, a warning is issued. This is useful
- if the current file is derived from the other file, and should be
- regenerated. The other file is searched for using the normal
- include search path. Optional trailing text can be used to give
- more information in the warning message.
-
- #pragma GCC dependency "parse.y"
- #pragma GCC dependency "/usr/include/time.h" rerun fixincludes
-
-`#pragma GCC poison'
- Sometimes, there is an identifier that you want to remove
- completely from your program, and make sure that it never creeps
- back in. To enforce this, you can "poison" the identifier with
- this pragma. `#pragma GCC poison' is followed by a list of
- identifiers to poison. If any of those identifiers appears
- anywhere in the source after the directive, it is a hard error.
- For example,
-
- #pragma GCC poison printf sprintf fprintf
- sprintf(some_string, "hello");
-
- will produce an error.
-
- If a poisoned identifier appears as part of the expansion of a
- macro which was defined before the identifier was poisoned, it
- will _not_ cause an error. This lets you poison an identifier
- without worrying about system headers defining macros that use it.
-
- For example,
-
- #define strrchr rindex
- #pragma GCC poison rindex
- strrchr(some_string, 'h');
-
- will not produce an error.
-
-`#pragma GCC system_header'
- This pragma takes no arguments. It causes the rest of the code in
- the current file to be treated as if it came from a system header.
- *Note System Headers::.
-
-
-
-File: cpp.info, Node: Other Directives, Next: Preprocessor Output, Prev: Pragmas, Up: Top
-
-8 Other Directives
-******************
-
-The `#ident' directive takes one argument, a string constant. On some
-systems, that string constant is copied into a special segment of the
-object file. On other systems, the directive is ignored. The `#sccs'
-directive is a synonym for `#ident'.
-
- These directives are not part of the C standard, but they are not
-official GNU extensions either. What historical information we have
-been able to find, suggests they originated with System V.
-
- The "null directive" consists of a `#' followed by a newline, with
-only whitespace (including comments) in between. A null directive is
-understood as a preprocessing directive but has no effect on the
-preprocessor output. The primary significance of the existence of the
-null directive is that an input line consisting of just a `#' will
-produce no output, rather than a line of output containing just a `#'.
-Supposedly some old C programs contain such lines.
-
-
-File: cpp.info, Node: Preprocessor Output, Next: Traditional Mode, Prev: Other Directives, Up: Top
-
-9 Preprocessor Output
-*********************
-
-When the C preprocessor is used with the C, C++, or Objective-C
-compilers, it is integrated into the compiler and communicates a stream
-of binary tokens directly to the compiler's parser. However, it can
-also be used in the more conventional standalone mode, where it produces
-textual output.
-
- The output from the C preprocessor looks much like the input, except
-that all preprocessing directive lines have been replaced with blank
-lines and all comments with spaces. Long runs of blank lines are
-discarded.
-
- The ISO standard specifies that it is implementation defined whether
-a preprocessor preserves whitespace between tokens, or replaces it with
-e.g. a single space. In GNU CPP, whitespace between tokens is collapsed
-to become a single space, with the exception that the first token on a
-non-directive line is preceded with sufficient spaces that it appears in
-the same column in the preprocessed output that it appeared in the
-original source file. This is so the output is easy to read. *Note
-Differences from previous versions::. CPP does not insert any
-whitespace where there was none in the original source, except where
-necessary to prevent an accidental token paste.
-
- Source file name and line number information is conveyed by lines of
-the form
-
- # LINENUM FILENAME FLAGS
-
-These are called "linemarkers". They are inserted as needed into the
-output (but never within a string or character constant). They mean
-that the following line originated in file FILENAME at line LINENUM.
-FILENAME will never contain any non-printing characters; they are
-replaced with octal escape sequences.
-
- After the file name comes zero or more flags, which are `1', `2',
-`3', or `4'. If there are multiple flags, spaces separate them. Here
-is what the flags mean:
-
-`1'
- This indicates the start of a new file.
-
-`2'
- This indicates returning to a file (after having included another
- file).
-
-`3'
- This indicates that the following text comes from a system header
- file, so certain warnings should be suppressed.
-
-`4'
- This indicates that the following text should be treated as being
- wrapped in an implicit `extern "C"' block.
-
- As an extension, the preprocessor accepts linemarkers in
-non-assembler input files. They are treated like the corresponding
-`#line' directive, (*note Line Control::), except that trailing flags
-are permitted, and are interpreted with the meanings described above.
-If multiple flags are given, they must be in ascending order.
-
- Some directives may be duplicated in the output of the preprocessor.
-These are `#ident' (always), `#pragma' (only if the preprocessor does
-not handle the pragma itself), and `#define' and `#undef' (with certain
-debugging options). If this happens, the `#' of the directive will
-always be in the first column, and there will be no space between the
-`#' and the directive name. If macro expansion happens to generate
-tokens which might be mistaken for a duplicated directive, a space will
-be inserted between the `#' and the directive name.
-
-
-File: cpp.info, Node: Traditional Mode, Next: Implementation Details, Prev: Preprocessor Output, Up: Top
-
-10 Traditional Mode
-*******************
-
-Traditional (pre-standard) C preprocessing is rather different from the
-preprocessing specified by the standard. When GCC is given the
-`-traditional-cpp' option, it attempts to emulate a traditional
-preprocessor.
-
- GCC versions 3.2 and later only support traditional mode semantics in
-the preprocessor, and not in the compiler front ends. This chapter
-outlines the traditional preprocessor semantics we implemented.
-
- The implementation does not correspond precisely to the behavior of
-earlier versions of GCC, nor to any true traditional preprocessor.
-After all, inconsistencies among traditional implementations were a
-major motivation for C standardization. However, we intend that it
-should be compatible with true traditional preprocessors in all ways
-that actually matter.
-
-* Menu:
-
-* Traditional lexical analysis::
-* Traditional macros::
-* Traditional miscellany::
-* Traditional warnings::
-
-
-File: cpp.info, Node: Traditional lexical analysis, Next: Traditional macros, Up: Traditional Mode
-
-10.1 Traditional lexical analysis
-=================================
-
-The traditional preprocessor does not decompose its input into tokens
-the same way a standards-conforming preprocessor does. The input is
-simply treated as a stream of text with minimal internal form.
-
- This implementation does not treat trigraphs (*note trigraphs::)
-specially since they were an invention of the standards committee. It
-handles arbitrarily-positioned escaped newlines properly and splices
-the lines as you would expect; many traditional preprocessors did not
-do this.
-
- The form of horizontal whitespace in the input file is preserved in
-the output. In particular, hard tabs remain hard tabs. This can be
-useful if, for example, you are preprocessing a Makefile.
-
- Traditional CPP only recognizes C-style block comments, and treats
-the `/*' sequence as introducing a comment only if it lies outside
-quoted text. Quoted text is introduced by the usual single and double
-quotes, and also by an initial `<' in a `#include' directive.
-
- Traditionally, comments are completely removed and are not replaced
-with a space. Since a traditional compiler does its own tokenization
-of the output of the preprocessor, this means that comments can
-effectively be used as token paste operators. However, comments behave
-like separators for text handled by the preprocessor itself, since it
-doesn't re-lex its input. For example, in
-
- #if foo/**/bar
-
-`foo' and `bar' are distinct identifiers and expanded separately if
-they happen to be macros. In other words, this directive is equivalent
-to
-
- #if foo bar
-
-rather than
-
- #if foobar
-
- Generally speaking, in traditional mode an opening quote need not
-have a matching closing quote. In particular, a macro may be defined
-with replacement text that contains an unmatched quote. Of course, if
-you attempt to compile preprocessed output containing an unmatched quote
-you will get a syntax error.
-
- However, all preprocessing directives other than `#define' require
-matching quotes. For example:
-
- #define m This macro's fine and has an unmatched quote
- "/* This is not a comment. */
- /* This is a comment. The following #include directive
- is ill-formed. */
- #include <stdio.h
-
- Just as for the ISO preprocessor, what would be a closing quote can
-be escaped with a backslash to prevent the quoted text from closing.
-
-
-File: cpp.info, Node: Traditional macros, Next: Traditional miscellany, Prev: Traditional lexical analysis, Up: Traditional Mode
-
-10.2 Traditional macros
-=======================
-
-The major difference between traditional and ISO macros is that the
-former expand to text rather than to a token sequence. CPP removes all
-leading and trailing horizontal whitespace from a macro's replacement
-text before storing it, but preserves the form of internal whitespace.
-
- One consequence is that it is legitimate for the replacement text to
-contain an unmatched quote (*note Traditional lexical analysis::). An
-unclosed string or character constant continues into the text following
-the macro call. Similarly, the text at the end of a macro's expansion
-can run together with the text after the macro invocation to produce a
-single token.
-
- Normally comments are removed from the replacement text after the
-macro is expanded, but if the `-CC' option is passed on the command
-line comments are preserved. (In fact, the current implementation
-removes comments even before saving the macro replacement text, but it
-careful to do it in such a way that the observed effect is identical
-even in the function-like macro case.)
-
- The ISO stringification operator `#' and token paste operator `##'
-have no special meaning. As explained later, an effect similar to
-these operators can be obtained in a different way. Macro names that
-are embedded in quotes, either from the main file or after macro
-replacement, do not expand.
-
- CPP replaces an unquoted object-like macro name with its replacement
-text, and then rescans it for further macros to replace. Unlike
-standard macro expansion, traditional macro expansion has no provision
-to prevent recursion. If an object-like macro appears unquoted in its
-replacement text, it will be replaced again during the rescan pass, and
-so on _ad infinitum_. GCC detects when it is expanding recursive
-macros, emits an error message, and continues after the offending macro
-invocation.
-
- #define PLUS +
- #define INC(x) PLUS+x
- INC(foo);
- ==> ++foo;
-
- Function-like macros are similar in form but quite different in
-behavior to their ISO counterparts. Their arguments are contained
-within parentheses, are comma-separated, and can cross physical lines.
-Commas within nested parentheses are not treated as argument
-separators. Similarly, a quote in an argument cannot be left unclosed;
-a following comma or parenthesis that comes before the closing quote is
-treated like any other character. There is no facility for handling
-variadic macros.
-
- This implementation removes all comments from macro arguments, unless
-the `-C' option is given. The form of all other horizontal whitespace
-in arguments is preserved, including leading and trailing whitespace.
-In particular
-
- f( )
-
-is treated as an invocation of the macro `f' with a single argument
-consisting of a single space. If you want to invoke a function-like
-macro that takes no arguments, you must not leave any whitespace
-between the parentheses.
-
- If a macro argument crosses a new line, the new line is replaced with
-a space when forming the argument. If the previous line contained an
-unterminated quote, the following line inherits the quoted state.
-
- Traditional preprocessors replace parameters in the replacement text
-with their arguments regardless of whether the parameters are within
-quotes or not. This provides a way to stringize arguments. For example
-
- #define str(x) "x"
- str(/* A comment */some text )
- ==> "some text "
-
-Note that the comment is removed, but that the trailing space is
-preserved. Here is an example of using a comment to effect token
-pasting.
-
- #define suffix(x) foo_/**/x
- suffix(bar)
- ==> foo_bar
-
-
-File: cpp.info, Node: Traditional miscellany, Next: Traditional warnings, Prev: Traditional macros, Up: Traditional Mode
-
-10.3 Traditional miscellany
-===========================
-
-Here are some things to be aware of when using the traditional
-preprocessor.
-
- * Preprocessing directives are recognized only when their leading
- `#' appears in the first column. There can be no whitespace
- between the beginning of the line and the `#', but whitespace can
- follow the `#'.
-
- * A true traditional C preprocessor does not recognize `#error' or
- `#pragma', and may not recognize `#elif'. CPP supports all the
- directives in traditional mode that it supports in ISO mode,
- including extensions, with the exception that the effects of
- `#pragma GCC poison' are undefined.
-
- * __STDC__ is not defined.
-
- * If you use digraphs the behavior is undefined.
-
- * If a line that looks like a directive appears within macro
- arguments, the behavior is undefined.
-
-
-
-File: cpp.info, Node: Traditional warnings, Prev: Traditional miscellany, Up: Traditional Mode
-
-10.4 Traditional warnings
-=========================
-
-You can request warnings about features that did not exist, or worked
-differently, in traditional C with the `-Wtraditional' option. GCC
-does not warn about features of ISO C which you must use when you are
-using a conforming compiler, such as the `#' and `##' operators.
-
- Presently `-Wtraditional' warns about:
-
- * Macro parameters that appear within string literals in the macro
- body. In traditional C macro replacement takes place within
- string literals, but does not in ISO C.
-
- * In traditional C, some preprocessor directives did not exist.
- Traditional preprocessors would only consider a line to be a
- directive if the `#' appeared in column 1 on the line. Therefore
- `-Wtraditional' warns about directives that traditional C
- understands but would ignore because the `#' does not appear as the
- first character on the line. It also suggests you hide directives
- like `#pragma' not understood by traditional C by indenting them.
- Some traditional implementations would not recognize `#elif', so it
- suggests avoiding it altogether.
-
- * A function-like macro that appears without an argument list. In
- some traditional preprocessors this was an error. In ISO C it
- merely means that the macro is not expanded.
-
- * The unary plus operator. This did not exist in traditional C.
-
- * The `U' and `LL' integer constant suffixes, which were not
- available in traditional C. (Traditional C does support the `L'
- suffix for simple long integer constants.) You are not warned
- about uses of these suffixes in macros defined in system headers.
- For instance, `UINT_MAX' may well be defined as `4294967295U', but
- you will not be warned if you use `UINT_MAX'.
-
- You can usually avoid the warning, and the related warning about
- constants which are so large that they are unsigned, by writing the
- integer constant in question in hexadecimal, with no U suffix.
- Take care, though, because this gives the wrong result in exotic
- cases.
-
-
-File: cpp.info, Node: Implementation Details, Next: Invocation, Prev: Traditional Mode, Up: Top
-
-11 Implementation Details
-*************************
-
-Here we document details of how the preprocessor's implementation
-affects its user-visible behavior. You should try to avoid undue
-reliance on behavior described here, as it is possible that it will
-change subtly in future implementations.
-
- Also documented here are obsolete features and changes from previous
-versions of CPP.
-
-* Menu:
-
-* Implementation-defined behavior::
-* Implementation limits::
-* Obsolete Features::
-* Differences from previous versions::
-
-
-File: cpp.info, Node: Implementation-defined behavior, Next: Implementation limits, Up: Implementation Details
-
-11.1 Implementation-defined behavior
-====================================
-
-This is how CPP behaves in all the cases which the C standard describes
-as "implementation-defined". This term means that the implementation
-is free to do what it likes, but must document its choice and stick to
-it.
-
- * The mapping of physical source file multi-byte characters to the
- execution character set.
-
- The input character set can be specified using the
- `-finput-charset' option, while the execution character set may be
- controlled using the `-fexec-charset' and `-fwide-exec-charset'
- options.
-
- * Identifier characters. The C and C++ standards allow identifiers
- to be composed of `_' and the alphanumeric characters. C++ and
- C99 also allow universal character names, and C99 further permits
- implementation-defined characters. GCC currently only permits
- universal character names if `-fextended-identifiers' is used,
- because the implementation of universal character names in
- identifiers is experimental.
-
- GCC allows the `$' character in identifiers as an extension for
- most targets. This is true regardless of the `std=' switch, since
- this extension cannot conflict with standards-conforming programs.
- When preprocessing assembler, however, dollars are not identifier
- characters by default.
-
- Currently the targets that by default do not permit `$' are AVR,
- IP2K, MMIX, MIPS Irix 3, ARM aout, and PowerPC targets for the AIX
- operating system.
-
- You can override the default with `-fdollars-in-identifiers' or
- `fno-dollars-in-identifiers'. *Note fdollars-in-identifiers::.
-
- * Non-empty sequences of whitespace characters.
-
- In textual output, each whitespace sequence is collapsed to a
- single space. For aesthetic reasons, the first token on each
- non-directive line of output is preceded with sufficient spaces
- that it appears in the same column as it did in the original
- source file.
-
- * The numeric value of character constants in preprocessor
- expressions.
-
- The preprocessor and compiler interpret character constants in the
- same way; i.e. escape sequences such as `\a' are given the values
- they would have on the target machine.
-
- The compiler evaluates a multi-character character constant a
- character at a time, shifting the previous value left by the
- number of bits per target character, and then or-ing in the
- bit-pattern of the new character truncated to the width of a
- target character. The final bit-pattern is given type `int', and
- is therefore signed, regardless of whether single characters are
- signed or not (a slight change from versions 3.1 and earlier of
- GCC). If there are more characters in the constant than would fit
- in the target `int' the compiler issues a warning, and the excess
- leading characters are ignored.
-
- For example, `'ab'' for a target with an 8-bit `char' would be
- interpreted as
- `(int) ((unsigned char) 'a' * 256 + (unsigned char) 'b')', and
- `'\234a'' as
- `(int) ((unsigned char) '\234' * 256 + (unsigned char) 'a')'.
-
- * Source file inclusion.
-
- For a discussion on how the preprocessor locates header files,
- *note Include Operation::.
-
- * Interpretation of the filename resulting from a macro-expanded
- `#include' directive.
-
- *Note Computed Includes::.
-
- * Treatment of a `#pragma' directive that after macro-expansion
- results in a standard pragma.
-
- No macro expansion occurs on any `#pragma' directive line, so the
- question does not arise.
-
- Note that GCC does not yet implement any of the standard pragmas.
-
-
-
-File: cpp.info, Node: Implementation limits, Next: Obsolete Features, Prev: Implementation-defined behavior, Up: Implementation Details
-
-11.2 Implementation limits
-==========================
-
-CPP has a small number of internal limits. This section lists the
-limits which the C standard requires to be no lower than some minimum,
-and all the others known. It is intended that there should be as few
-limits as possible. If you encounter an undocumented or inconvenient
-limit, please report that as a bug. *Note Reporting Bugs: (gcc)Bugs.
-
- Where we say something is limited "only by available memory", that
-means that internal data structures impose no intrinsic limit, and space
-is allocated with `malloc' or equivalent. The actual limit will
-therefore depend on many things, such as the size of other things
-allocated by the compiler at the same time, the amount of memory
-consumed by other processes on the same computer, etc.
-
- * Nesting levels of `#include' files.
-
- We impose an arbitrary limit of 200 levels, to avoid runaway
- recursion. The standard requires at least 15 levels.
-
- * Nesting levels of conditional inclusion.
-
- The C standard mandates this be at least 63. CPP is limited only
- by available memory.
-
- * Levels of parenthesized expressions within a full expression.
-
- The C standard requires this to be at least 63. In preprocessor
- conditional expressions, it is limited only by available memory.
-
- * Significant initial characters in an identifier or macro name.
-
- The preprocessor treats all characters as significant. The C
- standard requires only that the first 63 be significant.
-
- * Number of macros simultaneously defined in a single translation
- unit.
-
- The standard requires at least 4095 be possible. CPP is limited
- only by available memory.
-
- * Number of parameters in a macro definition and arguments in a
- macro call.
-
- We allow `USHRT_MAX', which is no smaller than 65,535. The minimum
- required by the standard is 127.
-
- * Number of characters on a logical source line.
-
- The C standard requires a minimum of 4096 be permitted. CPP places
- no limits on this, but you may get incorrect column numbers
- reported in diagnostics for lines longer than 65,535 characters.
-
- * Maximum size of a source file.
-
- The standard does not specify any lower limit on the maximum size
- of a source file. GNU cpp maps files into memory, so it is
- limited by the available address space. This is generally at
- least two gigabytes. Depending on the operating system, the size
- of physical memory may or may not be a limitation.
-
-
-
-File: cpp.info, Node: Obsolete Features, Next: Differences from previous versions, Prev: Implementation limits, Up: Implementation Details
-
-11.3 Obsolete Features
-======================
-
-CPP has some features which are present mainly for compatibility with
-older programs. We discourage their use in new code. In some cases,
-we plan to remove the feature in a future version of GCC.
-
-11.3.1 Assertions
------------------
-
-"Assertions" are a deprecated alternative to macros in writing
-conditionals to test what sort of computer or system the compiled
-program will run on. Assertions are usually predefined, but you can
-define them with preprocessing directives or command-line options.
-
- Assertions were intended to provide a more systematic way to describe
-the compiler's target system and we added them for compatibility with
-existing compilers. In practice they are just as unpredictable as the
-system-specific predefined macros. In addition, they are not part of
-any standard, and only a few compilers support them. Therefore, the
-use of assertions is *less* portable than the use of system-specific
-predefined macros. We recommend you do not use them at all.
-
- An assertion looks like this:
-
- #PREDICATE (ANSWER)
-
-PREDICATE must be a single identifier. ANSWER can be any sequence of
-tokens; all characters are significant except for leading and trailing
-whitespace, and differences in internal whitespace sequences are
-ignored. (This is similar to the rules governing macro redefinition.)
-Thus, `(x + y)' is different from `(x+y)' but equivalent to
-`( x + y )'. Parentheses do not nest inside an answer.
-
- To test an assertion, you write it in an `#if'. For example, this
-conditional succeeds if either `vax' or `ns16000' has been asserted as
-an answer for `machine'.
-
- #if #machine (vax) || #machine (ns16000)
-
-You can test whether _any_ answer is asserted for a predicate by
-omitting the answer in the conditional:
-
- #if #machine
-
- Assertions are made with the `#assert' directive. Its sole argument
-is the assertion to make, without the leading `#' that identifies
-assertions in conditionals.
-
- #assert PREDICATE (ANSWER)
-
-You may make several assertions with the same predicate and different
-answers. Subsequent assertions do not override previous ones for the
-same predicate. All the answers for any given predicate are
-simultaneously true.
-
- Assertions can be canceled with the `#unassert' directive. It has
-the same syntax as `#assert'. In that form it cancels only the answer
-which was specified on the `#unassert' line; other answers for that
-predicate remain true. You can cancel an entire predicate by leaving
-out the answer:
-
- #unassert PREDICATE
-
-In either form, if no such assertion has been made, `#unassert' has no
-effect.
-
- You can also make or cancel assertions using command line options.
-*Note Invocation::.
-
-
-File: cpp.info, Node: Differences from previous versions, Prev: Obsolete Features, Up: Implementation Details
-
-11.4 Differences from previous versions
-=======================================
-
-This section details behavior which has changed from previous versions
-of CPP. We do not plan to change it again in the near future, but we
-do not promise not to, either.
-
- The "previous versions" discussed here are 2.95 and before. The
-behavior of GCC 3.0 is mostly the same as the behavior of the widely
-used 2.96 and 2.97 development snapshots. Where there are differences,
-they generally represent bugs in the snapshots.
-
- * -I- deprecated
-
- This option has been deprecated in 4.0. `-iquote' is meant to
- replace the need for this option.
-
- * Order of evaluation of `#' and `##' operators
-
- The standard does not specify the order of evaluation of a chain of
- `##' operators, nor whether `#' is evaluated before, after, or at
- the same time as `##'. You should therefore not write any code
- which depends on any specific ordering. It is possible to
- guarantee an ordering, if you need one, by suitable use of nested
- macros.
-
- An example of where this might matter is pasting the arguments `1',
- `e' and `-2'. This would be fine for left-to-right pasting, but
- right-to-left pasting would produce an invalid token `e-2'.
-
- GCC 3.0 evaluates `#' and `##' at the same time and strictly left
- to right. Older versions evaluated all `#' operators first, then
- all `##' operators, in an unreliable order.
-
- * The form of whitespace between tokens in preprocessor output
-
- *Note Preprocessor Output::, for the current textual format. This
- is also the format used by stringification. Normally, the
- preprocessor communicates tokens directly to the compiler's
- parser, and whitespace does not come up at all.
-
- Older versions of GCC preserved all whitespace provided by the
- user and inserted lots more whitespace of their own, because they
- could not accurately predict when extra spaces were needed to
- prevent accidental token pasting.
-
- * Optional argument when invoking rest argument macros
-
- As an extension, GCC permits you to omit the variable arguments
- entirely when you use a variable argument macro. This is
- forbidden by the 1999 C standard, and will provoke a pedantic
- warning with GCC 3.0. Previous versions accepted it silently.
-
- * `##' swallowing preceding text in rest argument macros
-
- Formerly, in a macro expansion, if `##' appeared before a variable
- arguments parameter, and the set of tokens specified for that
- argument in the macro invocation was empty, previous versions of
- CPP would back up and remove the preceding sequence of
- non-whitespace characters (*not* the preceding token). This
- extension is in direct conflict with the 1999 C standard and has
- been drastically pared back.
-
- In the current version of the preprocessor, if `##' appears between
- a comma and a variable arguments parameter, and the variable
- argument is omitted entirely, the comma will be removed from the
- expansion. If the variable argument is empty, or the token before
- `##' is not a comma, then `##' behaves as a normal token paste.
-
- * `#line' and `#include'
-
- The `#line' directive used to change GCC's notion of the
- "directory containing the current file", used by `#include' with a
- double-quoted header file name. In 3.0 and later, it does not.
- *Note Line Control::, for further explanation.
-
- * Syntax of `#line'
-
- In GCC 2.95 and previous, the string constant argument to `#line'
- was treated the same way as the argument to `#include': backslash
- escapes were not honored, and the string ended at the second `"'.
- This is not compliant with the C standard. In GCC 3.0, an attempt
- was made to correct the behavior, so that the string was treated
- as a real string constant, but it turned out to be buggy. In 3.1,
- the bugs have been fixed. (We are not fixing the bugs in 3.0
- because they affect relatively few people and the fix is quite
- invasive.)
-
-
-
-File: cpp.info, Node: Invocation, Next: Environment Variables, Prev: Implementation Details, Up: Top
-
-12 Invocation
-*************
-
-Most often when you use the C preprocessor you will not have to invoke
-it explicitly: the C compiler will do so automatically. However, the
-preprocessor is sometimes useful on its own. All the options listed
-here are also acceptable to the C compiler and have the same meaning,
-except that the C compiler has different rules for specifying the output
-file.
-
- _Note:_ Whether you use the preprocessor by way of `gcc' or `cpp',
-the "compiler driver" is run first. This program's purpose is to
-translate your command into invocations of the programs that do the
-actual work. Their command line interfaces are similar but not
-identical to the documented interface, and may change without notice.
-
- The C preprocessor expects two file names as arguments, INFILE and
-OUTFILE. The preprocessor reads INFILE together with any other files
-it specifies with `#include'. All the output generated by the combined
-input files is written in OUTFILE.
-
- Either INFILE or OUTFILE may be `-', which as INFILE means to read
-from standard input and as OUTFILE means to write to standard output.
-Also, if either file is omitted, it means the same as if `-' had been
-specified for that file.
-
- Unless otherwise noted, or the option ends in `=', all options which
-take an argument may have that argument appear either immediately after
-the option, or with a space between option and argument: `-Ifoo' and
-`-I foo' have the same effect.
-
- Many options have multi-letter names; therefore multiple
-single-letter options may _not_ be grouped: `-dM' is very different from
-`-d -M'.
-
-`-D NAME'
- Predefine NAME as a macro, with definition `1'.
-
-`-D NAME=DEFINITION'
- The contents of DEFINITION are tokenized and processed as if they
- appeared during translation phase three in a `#define' directive.
- In particular, the definition will be truncated by embedded
- newline characters.
-
- If you are invoking the preprocessor from a shell or shell-like
- program you may need to use the shell's quoting syntax to protect
- characters such as spaces that have a meaning in the shell syntax.
-
- If you wish to define a function-like macro on the command line,
- write its argument list with surrounding parentheses before the
- equals sign (if any). Parentheses are meaningful to most shells,
- so you will need to quote the option. With `sh' and `csh',
- `-D'NAME(ARGS...)=DEFINITION'' works.
-
- `-D' and `-U' options are processed in the order they are given on
- the command line. All `-imacros FILE' and `-include FILE' options
- are processed after all `-D' and `-U' options.
-
-`-U NAME'
- Cancel any previous definition of NAME, either built in or
- provided with a `-D' option.
-
-`-undef'
- Do not predefine any system-specific or GCC-specific macros. The
- standard predefined macros remain defined. *Note Standard
- Predefined Macros::.
-
-`-I DIR'
- Add the directory DIR to the list of directories to be searched
- for header files. *Note Search Path::. Directories named by `-I'
- are searched before the standard system include directories. If
- the directory DIR is a standard system include directory, the
- option is ignored to ensure that the default search order for
- system directories and the special treatment of system headers are
- not defeated (*note System Headers::) . If DIR begins with `=',
- then the `=' will be replaced by the sysroot prefix; see
- `--sysroot' and `-isysroot'.
-
-`-o FILE'
- Write output to FILE. This is the same as specifying FILE as the
- second non-option argument to `cpp'. `gcc' has a different
- interpretation of a second non-option argument, so you must use
- `-o' to specify the output file.
-
-`-Wall'
- Turns on all optional warnings which are desirable for normal code.
- At present this is `-Wcomment', `-Wtrigraphs', `-Wmultichar' and a
- warning about integer promotion causing a change of sign in `#if'
- expressions. Note that many of the preprocessor's warnings are on
- by default and have no options to control them.
-
-`-Wcomment'
-`-Wcomments'
- Warn whenever a comment-start sequence `/*' appears in a `/*'
- comment, or whenever a backslash-newline appears in a `//' comment.
- (Both forms have the same effect.)
-
-`-Wtrigraphs'
- Most trigraphs in comments cannot affect the meaning of the
- program. However, a trigraph that would form an escaped newline
- (`??/' at the end of a line) can, by changing where the comment
- begins or ends. Therefore, only trigraphs that would form escaped
- newlines produce warnings inside a comment.
-
- This option is implied by `-Wall'. If `-Wall' is not given, this
- option is still enabled unless trigraphs are enabled. To get
- trigraph conversion without warnings, but get the other `-Wall'
- warnings, use `-trigraphs -Wall -Wno-trigraphs'.
-
-`-Wtraditional'
- Warn about certain constructs that behave differently in
- traditional and ISO C. Also warn about ISO C constructs that have
- no traditional C equivalent, and problematic constructs which
- should be avoided. *Note Traditional Mode::.
-
-`-Wundef'
- Warn whenever an identifier which is not a macro is encountered in
- an `#if' directive, outside of `defined'. Such identifiers are
- replaced with zero.
-
-`-Wunused-macros'
- Warn about macros defined in the main file that are unused. A
- macro is "used" if it is expanded or tested for existence at least
- once. The preprocessor will also warn if the macro has not been
- used at the time it is redefined or undefined.
-
- Built-in macros, macros defined on the command line, and macros
- defined in include files are not warned about.
-
- _Note:_ If a macro is actually used, but only used in skipped
- conditional blocks, then CPP will report it as unused. To avoid
- the warning in such a case, you might improve the scope of the
- macro's definition by, for example, moving it into the first
- skipped block. Alternatively, you could provide a dummy use with
- something like:
-
- #if defined the_macro_causing_the_warning
- #endif
-
-`-Wendif-labels'
- Warn whenever an `#else' or an `#endif' are followed by text.
- This usually happens in code of the form
-
- #if FOO
- ...
- #else FOO
- ...
- #endif FOO
-
- The second and third `FOO' should be in comments, but often are not
- in older programs. This warning is on by default.
-
-`-Werror'
- Make all warnings into hard errors. Source code which triggers
- warnings will be rejected.
-
-`-Wsystem-headers'
- Issue warnings for code in system headers. These are normally
- unhelpful in finding bugs in your own code, therefore suppressed.
- If you are responsible for the system library, you may want to see
- them.
-
-`-w'
- Suppress all warnings, including those which GNU CPP issues by
- default.
-
-`-pedantic'
- Issue all the mandatory diagnostics listed in the C standard.
- Some of them are left out by default, since they trigger
- frequently on harmless code.
-
-`-pedantic-errors'
- Issue all the mandatory diagnostics, and make all mandatory
- diagnostics into errors. This includes mandatory diagnostics that
- GCC issues without `-pedantic' but treats as warnings.
-
-`-M'
- Instead of outputting the result of preprocessing, output a rule
- suitable for `make' describing the dependencies of the main source
- file. The preprocessor outputs one `make' rule containing the
- object file name for that source file, a colon, and the names of
- all the included files, including those coming from `-include' or
- `-imacros' command line options.
-
- Unless specified explicitly (with `-MT' or `-MQ'), the object file
- name consists of the name of the source file with any suffix
- replaced with object file suffix and with any leading directory
- parts removed. If there are many included files then the rule is
- split into several lines using `\'-newline. The rule has no
- commands.
-
- This option does not suppress the preprocessor's debug output,
- such as `-dM'. To avoid mixing such debug output with the
- dependency rules you should explicitly specify the dependency
- output file with `-MF', or use an environment variable like
- `DEPENDENCIES_OUTPUT' (*note Environment Variables::). Debug
- output will still be sent to the regular output stream as normal.
-
- Passing `-M' to the driver implies `-E', and suppresses warnings
- with an implicit `-w'.
-
-`-MM'
- Like `-M' but do not mention header files that are found in system
- header directories, nor header files that are included, directly
- or indirectly, from such a header.
-
- This implies that the choice of angle brackets or double quotes in
- an `#include' directive does not in itself determine whether that
- header will appear in `-MM' dependency output. This is a slight
- change in semantics from GCC versions 3.0 and earlier.
-
-`-MF FILE'
- When used with `-M' or `-MM', specifies a file to write the
- dependencies to. If no `-MF' switch is given the preprocessor
- sends the rules to the same place it would have sent preprocessed
- output.
-
- When used with the driver options `-MD' or `-MMD', `-MF' overrides
- the default dependency output file.
-
-`-MG'
- In conjunction with an option such as `-M' requesting dependency
- generation, `-MG' assumes missing header files are generated files
- and adds them to the dependency list without raising an error.
- The dependency filename is taken directly from the `#include'
- directive without prepending any path. `-MG' also suppresses
- preprocessed output, as a missing header file renders this useless.
-
- This feature is used in automatic updating of makefiles.
-
-`-MP'
- This option instructs CPP to add a phony target for each dependency
- other than the main file, causing each to depend on nothing. These
- dummy rules work around errors `make' gives if you remove header
- files without updating the `Makefile' to match.
-
- This is typical output:
-
- test.o: test.c test.h
-
- test.h:
-
-`-MT TARGET'
- Change the target of the rule emitted by dependency generation. By
- default CPP takes the name of the main input file, deletes any
- directory components and any file suffix such as `.c', and appends
- the platform's usual object suffix. The result is the target.
-
- An `-MT' option will set the target to be exactly the string you
- specify. If you want multiple targets, you can specify them as a
- single argument to `-MT', or use multiple `-MT' options.
-
- For example, `-MT '$(objpfx)foo.o'' might give
-
- $(objpfx)foo.o: foo.c
-
-`-MQ TARGET'
- Same as `-MT', but it quotes any characters which are special to
- Make. `-MQ '$(objpfx)foo.o'' gives
-
- $$(objpfx)foo.o: foo.c
-
- The default target is automatically quoted, as if it were given
- with `-MQ'.
-
-`-MD'
- `-MD' is equivalent to `-M -MF FILE', except that `-E' is not
- implied. The driver determines FILE based on whether an `-o'
- option is given. If it is, the driver uses its argument but with
- a suffix of `.d', otherwise it takes the name of the input file,
- removes any directory components and suffix, and applies a `.d'
- suffix.
-
- If `-MD' is used in conjunction with `-E', any `-o' switch is
- understood to specify the dependency output file (*note -MF:
- dashMF.), but if used without `-E', each `-o' is understood to
- specify a target object file.
-
- Since `-E' is not implied, `-MD' can be used to generate a
- dependency output file as a side-effect of the compilation process.
-
-`-MMD'
- Like `-MD' except mention only user header files, not system
- header files.
-
-`-x c'
-`-x c++'
-`-x objective-c'
-`-x assembler-with-cpp'
- Specify the source language: C, C++, Objective-C, or assembly.
- This has nothing to do with standards conformance or extensions;
- it merely selects which base syntax to expect. If you give none
- of these options, cpp will deduce the language from the extension
- of the source file: `.c', `.cc', `.m', or `.S'. Some other common
- extensions for C++ and assembly are also recognized. If cpp does
- not recognize the extension, it will treat the file as C; this is
- the most generic mode.
-
- _Note:_ Previous versions of cpp accepted a `-lang' option which
- selected both the language and the standards conformance level.
- This option has been removed, because it conflicts with the `-l'
- option.
-
-`-std=STANDARD'
-`-ansi'
- Specify the standard to which the code should conform. Currently
- CPP knows about C and C++ standards; others may be added in the
- future.
-
- STANDARD may be one of:
- `c90'
- `c89'
- `iso9899:1990'
- The ISO C standard from 1990. `c90' is the customary
- shorthand for this version of the standard.
-
- The `-ansi' option is equivalent to `-std=c90'.
-
- `iso9899:199409'
- The 1990 C standard, as amended in 1994.
-
- `iso9899:1999'
- `c99'
- `iso9899:199x'
- `c9x'
- The revised ISO C standard, published in December 1999.
- Before publication, this was known as C9X.
-
- `c1x'
- The next version of the ISO C standard, still under
- development.
-
- `gnu90'
- `gnu89'
- The 1990 C standard plus GNU extensions. This is the default.
-
- `gnu99'
- `gnu9x'
- The 1999 C standard plus GNU extensions.
-
- `gnu1x'
- The next version of the ISO C standard, still under
- development, plus GNU extensions.
-
- `c++98'
- The 1998 ISO C++ standard plus amendments.
-
- `gnu++98'
- The same as `-std=c++98' plus GNU extensions. This is the
- default for C++ code.
-
-`-I-'
- Split the include path. Any directories specified with `-I'
- options before `-I-' are searched only for headers requested with
- `#include "FILE"'; they are not searched for `#include <FILE>'.
- If additional directories are specified with `-I' options after
- the `-I-', those directories are searched for all `#include'
- directives.
-
- In addition, `-I-' inhibits the use of the directory of the current
- file directory as the first search directory for `#include "FILE"'.
- *Note Search Path::. This option has been deprecated.
-
-`-nostdinc'
- Do not search the standard system directories for header files.
- Only the directories you have specified with `-I' options (and the
- directory of the current file, if appropriate) are searched.
-
-`-nostdinc++'
- Do not search for header files in the C++-specific standard
- directories, but do still search the other standard directories.
- (This option is used when building the C++ library.)
-
-`-include FILE'
- Process FILE as if `#include "file"' appeared as the first line of
- the primary source file. However, the first directory searched
- for FILE is the preprocessor's working directory _instead of_ the
- directory containing the main source file. If not found there, it
- is searched for in the remainder of the `#include "..."' search
- chain as normal.
-
- If multiple `-include' options are given, the files are included
- in the order they appear on the command line.
-
-`-imacros FILE'
- Exactly like `-include', except that any output produced by
- scanning FILE is thrown away. Macros it defines remain defined.
- This allows you to acquire all the macros from a header without
- also processing its declarations.
-
- All files specified by `-imacros' are processed before all files
- specified by `-include'.
-
-`-idirafter DIR'
- Search DIR for header files, but do it _after_ all directories
- specified with `-I' and the standard system directories have been
- exhausted. DIR is treated as a system include directory. If DIR
- begins with `=', then the `=' will be replaced by the sysroot
- prefix; see `--sysroot' and `-isysroot'.
-
-`-iprefix PREFIX'
- Specify PREFIX as the prefix for subsequent `-iwithprefix'
- options. If the prefix represents a directory, you should include
- the final `/'.
-
-`-iwithprefix DIR'
-`-iwithprefixbefore DIR'
- Append DIR to the prefix specified previously with `-iprefix', and
- add the resulting directory to the include search path.
- `-iwithprefixbefore' puts it in the same place `-I' would;
- `-iwithprefix' puts it where `-idirafter' would.
-
-`-isysroot DIR'
- This option is like the `--sysroot' option, but applies only to
- header files (except for Darwin targets, where it applies to both
- header files and libraries). See the `--sysroot' option for more
- information.
-
-`-imultilib DIR'
- Use DIR as a subdirectory of the directory containing
- target-specific C++ headers.
-
-`-isystem DIR'
- Search DIR for header files, after all directories specified by
- `-I' but before the standard system directories. Mark it as a
- system directory, so that it gets the same special treatment as is
- applied to the standard system directories. *Note System
- Headers::. If DIR begins with `=', then the `=' will be replaced
- by the sysroot prefix; see `--sysroot' and `-isysroot'.
-
-`-iquote DIR'
- Search DIR only for header files requested with `#include "FILE"';
- they are not searched for `#include <FILE>', before all
- directories specified by `-I' and before the standard system
- directories. *Note Search Path::. If DIR begins with `=', then
- the `=' will be replaced by the sysroot prefix; see `--sysroot'
- and `-isysroot'.
-
-`-fdirectives-only'
- When preprocessing, handle directives, but do not expand macros.
-
- The option's behavior depends on the `-E' and `-fpreprocessed'
- options.
-
- With `-E', preprocessing is limited to the handling of directives
- such as `#define', `#ifdef', and `#error'. Other preprocessor
- operations, such as macro expansion and trigraph conversion are
- not performed. In addition, the `-dD' option is implicitly
- enabled.
-
- With `-fpreprocessed', predefinition of command line and most
- builtin macros is disabled. Macros such as `__LINE__', which are
- contextually dependent, are handled normally. This enables
- compilation of files previously preprocessed with `-E
- -fdirectives-only'.
-
- With both `-E' and `-fpreprocessed', the rules for
- `-fpreprocessed' take precedence. This enables full preprocessing
- of files previously preprocessed with `-E -fdirectives-only'.
-
-`-fdollars-in-identifiers'
- Accept `$' in identifiers. *Note Identifier characters::.
-
-`-fextended-identifiers'
- Accept universal character names in identifiers. This option is
- experimental; in a future version of GCC, it will be enabled by
- default for C99 and C++.
-
-`-fpreprocessed'
- Indicate to the preprocessor that the input file has already been
- preprocessed. This suppresses things like macro expansion,
- trigraph conversion, escaped newline splicing, and processing of
- most directives. The preprocessor still recognizes and removes
- comments, so that you can pass a file preprocessed with `-C' to
- the compiler without problems. In this mode the integrated
- preprocessor is little more than a tokenizer for the front ends.
-
- `-fpreprocessed' is implicit if the input file has one of the
- extensions `.i', `.ii' or `.mi'. These are the extensions that
- GCC uses for preprocessed files created by `-save-temps'.
-
-`-ftabstop=WIDTH'
- Set the distance between tab stops. This helps the preprocessor
- report correct column numbers in warnings or errors, even if tabs
- appear on the line. If the value is less than 1 or greater than
- 100, the option is ignored. The default is 8.
-
-`-fexec-charset=CHARSET'
- Set the execution character set, used for string and character
- constants. The default is UTF-8. CHARSET can be any encoding
- supported by the system's `iconv' library routine.
-
-`-fwide-exec-charset=CHARSET'
- Set the wide execution character set, used for wide string and
- character constants. The default is UTF-32 or UTF-16, whichever
- corresponds to the width of `wchar_t'. As with `-fexec-charset',
- CHARSET can be any encoding supported by the system's `iconv'
- library routine; however, you will have problems with encodings
- that do not fit exactly in `wchar_t'.
-
-`-finput-charset=CHARSET'
- Set the input character set, used for translation from the
- character set of the input file to the source character set used
- by GCC. If the locale does not specify, or GCC cannot get this
- information from the locale, the default is UTF-8. This can be
- overridden by either the locale or this command line option.
- Currently the command line option takes precedence if there's a
- conflict. CHARSET can be any encoding supported by the system's
- `iconv' library routine.
-
-`-fworking-directory'
- Enable generation of linemarkers in the preprocessor output that
- will let the compiler know the current working directory at the
- time of preprocessing. When this option is enabled, the
- preprocessor will emit, after the initial linemarker, a second
- linemarker with the current working directory followed by two
- slashes. GCC will use this directory, when it's present in the
- preprocessed input, as the directory emitted as the current
- working directory in some debugging information formats. This
- option is implicitly enabled if debugging information is enabled,
- but this can be inhibited with the negated form
- `-fno-working-directory'. If the `-P' flag is present in the
- command line, this option has no effect, since no `#line'
- directives are emitted whatsoever.
-
-`-fno-show-column'
- Do not print column numbers in diagnostics. This may be necessary
- if diagnostics are being scanned by a program that does not
- understand the column numbers, such as `dejagnu'.
-
-`-A PREDICATE=ANSWER'
- Make an assertion with the predicate PREDICATE and answer ANSWER.
- This form is preferred to the older form `-A PREDICATE(ANSWER)',
- which is still supported, because it does not use shell special
- characters. *Note Obsolete Features::.
-
-`-A -PREDICATE=ANSWER'
- Cancel an assertion with the predicate PREDICATE and answer ANSWER.
-
-`-dCHARS'
- CHARS is a sequence of one or more of the following characters,
- and must not be preceded by a space. Other characters are
- interpreted by the compiler proper, or reserved for future
- versions of GCC, and so are silently ignored. If you specify
- characters whose behavior conflicts, the result is undefined.
-
- `M'
- Instead of the normal output, generate a list of `#define'
- directives for all the macros defined during the execution of
- the preprocessor, including predefined macros. This gives
- you a way of finding out what is predefined in your version
- of the preprocessor. Assuming you have no file `foo.h', the
- command
-
- touch foo.h; cpp -dM foo.h
-
- will show all the predefined macros.
-
- If you use `-dM' without the `-E' option, `-dM' is
- interpreted as a synonym for `-fdump-rtl-mach'. *Note
- Debugging Options: (gcc)Debugging Options.
-
- `D'
- Like `M' except in two respects: it does _not_ include the
- predefined macros, and it outputs _both_ the `#define'
- directives and the result of preprocessing. Both kinds of
- output go to the standard output file.
-
- `N'
- Like `D', but emit only the macro names, not their expansions.
-
- `I'
- Output `#include' directives in addition to the result of
- preprocessing.
-
- `U'
- Like `D' except that only macros that are expanded, or whose
- definedness is tested in preprocessor directives, are output;
- the output is delayed until the use or test of the macro; and
- `#undef' directives are also output for macros tested but
- undefined at the time.
-
-`-P'
- Inhibit generation of linemarkers in the output from the
- preprocessor. This might be useful when running the preprocessor
- on something that is not C code, and will be sent to a program
- which might be confused by the linemarkers. *Note Preprocessor
- Output::.
-
-`-C'
- Do not discard comments. All comments are passed through to the
- output file, except for comments in processed directives, which
- are deleted along with the directive.
-
- You should be prepared for side effects when using `-C'; it causes
- the preprocessor to treat comments as tokens in their own right.
- For example, comments appearing at the start of what would be a
- directive line have the effect of turning that line into an
- ordinary source line, since the first token on the line is no
- longer a `#'.
-
-`-CC'
- Do not discard comments, including during macro expansion. This is
- like `-C', except that comments contained within macros are also
- passed through to the output file where the macro is expanded.
-
- In addition to the side-effects of the `-C' option, the `-CC'
- option causes all C++-style comments inside a macro to be
- converted to C-style comments. This is to prevent later use of
- that macro from inadvertently commenting out the remainder of the
- source line.
-
- The `-CC' option is generally used to support lint comments.
-
-`-traditional-cpp'
- Try to imitate the behavior of old-fashioned C preprocessors, as
- opposed to ISO C preprocessors. *Note Traditional Mode::.
-
-`-trigraphs'
- Process trigraph sequences. *Note Initial processing::.
-
-`-remap'
- Enable special code to work around file systems which only permit
- very short file names, such as MS-DOS.
-
-`--help'
-`--target-help'
- Print text describing all the command line options instead of
- preprocessing anything.
-
-`-v'
- Verbose mode. Print out GNU CPP's version number at the beginning
- of execution, and report the final form of the include path.
-
-`-H'
- Print the name of each header file used, in addition to other
- normal activities. Each name is indented to show how deep in the
- `#include' stack it is. Precompiled header files are also
- printed, even if they are found to be invalid; an invalid
- precompiled header file is printed with `...x' and a valid one
- with `...!' .
-
-`-version'
-`--version'
- Print out GNU CPP's version number. With one dash, proceed to
- preprocess as normal. With two dashes, exit immediately.
-
-
-File: cpp.info, Node: Environment Variables, Next: GNU Free Documentation License, Prev: Invocation, Up: Top
-
-13 Environment Variables
-************************
-
-This section describes the environment variables that affect how CPP
-operates. You can use them to specify directories or prefixes to use
-when searching for include files, or to control dependency output.
-
- Note that you can also specify places to search using options such as
-`-I', and control dependency output with options like `-M' (*note
-Invocation::). These take precedence over environment variables, which
-in turn take precedence over the configuration of GCC.
-
-`CPATH'
-`C_INCLUDE_PATH'
-`CPLUS_INCLUDE_PATH'
-`OBJC_INCLUDE_PATH'
- Each variable's value is a list of directories separated by a
- special character, much like `PATH', in which to look for header
- files. The special character, `PATH_SEPARATOR', is
- target-dependent and determined at GCC build time. For Microsoft
- Windows-based targets it is a semicolon, and for almost all other
- targets it is a colon.
-
- `CPATH' specifies a list of directories to be searched as if
- specified with `-I', but after any paths given with `-I' options
- on the command line. This environment variable is used regardless
- of which language is being preprocessed.
-
- The remaining environment variables apply only when preprocessing
- the particular language indicated. Each specifies a list of
- directories to be searched as if specified with `-isystem', but
- after any paths given with `-isystem' options on the command line.
-
- In all these variables, an empty element instructs the compiler to
- search its current working directory. Empty elements can appear
- at the beginning or end of a path. For instance, if the value of
- `CPATH' is `:/special/include', that has the same effect as
- `-I. -I/special/include'.
-
- See also *note Search Path::.
-
-`DEPENDENCIES_OUTPUT'
- If this variable is set, its value specifies how to output
- dependencies for Make based on the non-system header files
- processed by the compiler. System header files are ignored in the
- dependency output.
-
- The value of `DEPENDENCIES_OUTPUT' can be just a file name, in
- which case the Make rules are written to that file, guessing the
- target name from the source file name. Or the value can have the
- form `FILE TARGET', in which case the rules are written to file
- FILE using TARGET as the target name.
-
- In other words, this environment variable is equivalent to
- combining the options `-MM' and `-MF' (*note Invocation::), with
- an optional `-MT' switch too.
-
-`SUNPRO_DEPENDENCIES'
- This variable is the same as `DEPENDENCIES_OUTPUT' (see above),
- except that system header files are not ignored, so it implies
- `-M' rather than `-MM'. However, the dependence on the main input
- file is omitted. *Note Invocation::.
-
-
-File: cpp.info, Node: GNU Free Documentation License, Next: Index of Directives, Prev: Environment Variables, Up: Top
-
-GNU Free Documentation License
-******************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: cpp.info, Node: Index of Directives, Next: Option Index, Prev: GNU Free Documentation License, Up: Top
-
-Index of Directives
-*******************
-
-
-* Menu:
-
-* #assert: Obsolete Features. (line 48)
-* #define: Object-like Macros. (line 11)
-* #elif: Elif. (line 6)
-* #else: Else. (line 6)
-* #endif: Ifdef. (line 6)
-* #error: Diagnostics. (line 6)
-* #ident: Other Directives. (line 6)
-* #if: Conditional Syntax. (line 6)
-* #ifdef: Ifdef. (line 6)
-* #ifndef: Ifdef. (line 40)
-* #import: Alternatives to Wrapper #ifndef.
- (line 11)
-* #include: Include Syntax. (line 6)
-* #include_next: Wrapper Headers. (line 6)
-* #line: Line Control. (line 20)
-* #pragma GCC dependency: Pragmas. (line 55)
-* #pragma GCC poison: Pragmas. (line 67)
-* #pragma GCC system_header <1>: Pragmas. (line 94)
-* #pragma GCC system_header: System Headers. (line 31)
-* #sccs: Other Directives. (line 6)
-* #unassert: Obsolete Features. (line 59)
-* #undef: Undefining and Redefining Macros.
- (line 6)
-* #warning: Diagnostics. (line 27)
-
-
-File: cpp.info, Node: Option Index, Next: Concept Index, Prev: Index of Directives, Up: Top
-
-Option Index
-************
-
-CPP's command line options and environment variables are indexed here
-without any initial `-' or `--'.
-
-
-* Menu:
-
-* A: Invocation. (line 534)
-* ansi: Invocation. (line 308)
-* C: Invocation. (line 593)
-* C_INCLUDE_PATH: Environment Variables.
- (line 16)
-* CPATH: Environment Variables.
- (line 15)
-* CPLUS_INCLUDE_PATH: Environment Variables.
- (line 17)
-* D: Invocation. (line 39)
-* dD: Invocation. (line 566)
-* DEPENDENCIES_OUTPUT: Environment Variables.
- (line 44)
-* dI: Invocation. (line 575)
-* dM: Invocation. (line 550)
-* dN: Invocation. (line 572)
-* dU: Invocation. (line 579)
-* fdirectives-only: Invocation. (line 442)
-* fdollars-in-identifiers: Invocation. (line 464)
-* fexec-charset: Invocation. (line 491)
-* fextended-identifiers: Invocation. (line 467)
-* finput-charset: Invocation. (line 504)
-* fno-show-column: Invocation. (line 529)
-* fno-working-directory: Invocation. (line 514)
-* fpreprocessed: Invocation. (line 472)
-* ftabstop: Invocation. (line 485)
-* fwide-exec-charset: Invocation. (line 496)
-* fworking-directory: Invocation. (line 514)
-* H: Invocation. (line 638)
-* help: Invocation. (line 630)
-* I: Invocation. (line 71)
-* I-: Invocation. (line 355)
-* idirafter: Invocation. (line 397)
-* imacros: Invocation. (line 388)
-* imultilib: Invocation. (line 422)
-* include: Invocation. (line 377)
-* iprefix: Invocation. (line 404)
-* iquote: Invocation. (line 434)
-* isysroot: Invocation. (line 416)
-* isystem: Invocation. (line 426)
-* iwithprefix: Invocation. (line 410)
-* iwithprefixbefore: Invocation. (line 410)
-* M: Invocation. (line 180)
-* MD: Invocation. (line 269)
-* MF: Invocation. (line 215)
-* MG: Invocation. (line 224)
-* MM: Invocation. (line 205)
-* MMD: Invocation. (line 285)
-* MP: Invocation. (line 234)
-* MQ: Invocation. (line 260)
-* MT: Invocation. (line 246)
-* nostdinc: Invocation. (line 367)
-* nostdinc++: Invocation. (line 372)
-* o: Invocation. (line 82)
-* OBJC_INCLUDE_PATH: Environment Variables.
- (line 18)
-* P: Invocation. (line 586)
-* pedantic: Invocation. (line 170)
-* pedantic-errors: Invocation. (line 175)
-* remap: Invocation. (line 625)
-* std=: Invocation. (line 308)
-* SUNPRO_DEPENDENCIES: Environment Variables.
- (line 60)
-* target-help: Invocation. (line 630)
-* traditional-cpp: Invocation. (line 618)
-* trigraphs: Invocation. (line 622)
-* U: Invocation. (line 62)
-* undef: Invocation. (line 66)
-* v: Invocation. (line 634)
-* version: Invocation. (line 647)
-* w: Invocation. (line 166)
-* Wall: Invocation. (line 88)
-* Wcomment: Invocation. (line 96)
-* Wcomments: Invocation. (line 96)
-* Wendif-labels: Invocation. (line 143)
-* Werror: Invocation. (line 156)
-* Wsystem-headers: Invocation. (line 160)
-* Wtraditional: Invocation. (line 113)
-* Wtrigraphs: Invocation. (line 101)
-* Wundef: Invocation. (line 119)
-* Wunused-macros: Invocation. (line 124)
-* x: Invocation. (line 292)
-
-
-File: cpp.info, Node: Concept Index, Prev: Option Index, Up: Top
-
-Concept Index
-*************
-
-
-* Menu:
-
-* # operator: Stringification. (line 6)
-* ## operator: Concatenation. (line 6)
-* _Pragma: Pragmas. (line 25)
-* alternative tokens: Tokenization. (line 106)
-* arguments: Macro Arguments. (line 6)
-* arguments in macro definitions: Macro Arguments. (line 6)
-* assertions: Obsolete Features. (line 13)
-* assertions, canceling: Obsolete Features. (line 59)
-* backslash-newline: Initial processing. (line 61)
-* block comments: Initial processing. (line 77)
-* C++ named operators: C++ Named Operators. (line 6)
-* character constants: Tokenization. (line 85)
-* character set, execution: Invocation. (line 491)
-* character set, input: Invocation. (line 504)
-* character set, wide execution: Invocation. (line 496)
-* command line: Invocation. (line 6)
-* commenting out code: Deleted Code. (line 6)
-* comments: Initial processing. (line 77)
-* common predefined macros: Common Predefined Macros.
- (line 6)
-* computed includes: Computed Includes. (line 6)
-* concatenation: Concatenation. (line 6)
-* conditional group: Ifdef. (line 14)
-* conditionals: Conditionals. (line 6)
-* continued lines: Initial processing. (line 61)
-* controlling macro: Once-Only Headers. (line 35)
-* defined: Defined. (line 6)
-* dependencies for make as output: Environment Variables.
- (line 45)
-* dependencies, make: Invocation. (line 180)
-* diagnostic: Diagnostics. (line 6)
-* differences from previous versions: Differences from previous versions.
- (line 6)
-* digraphs: Tokenization. (line 106)
-* directive line: The preprocessing language.
- (line 6)
-* directive name: The preprocessing language.
- (line 6)
-* directives: The preprocessing language.
- (line 6)
-* empty macro arguments: Macro Arguments. (line 66)
-* environment variables: Environment Variables.
- (line 6)
-* expansion of arguments: Argument Prescan. (line 6)
-* FDL, GNU Free Documentation License: GNU Free Documentation License.
- (line 6)
-* function-like macros: Function-like Macros.
- (line 6)
-* grouping options: Invocation. (line 34)
-* guard macro: Once-Only Headers. (line 35)
-* header file: Header Files. (line 6)
-* header file names: Tokenization. (line 85)
-* identifiers: Tokenization. (line 34)
-* implementation limits: Implementation limits.
- (line 6)
-* implementation-defined behavior: Implementation-defined behavior.
- (line 6)
-* including just once: Once-Only Headers. (line 6)
-* invocation: Invocation. (line 6)
-* iso646.h: C++ Named Operators. (line 6)
-* line comments: Initial processing. (line 77)
-* line control: Line Control. (line 6)
-* line endings: Initial processing. (line 14)
-* linemarkers: Preprocessor Output. (line 28)
-* macro argument expansion: Argument Prescan. (line 6)
-* macro arguments and directives: Directives Within Macro Arguments.
- (line 6)
-* macros in include: Computed Includes. (line 6)
-* macros with arguments: Macro Arguments. (line 6)
-* macros with variable arguments: Variadic Macros. (line 6)
-* make: Invocation. (line 180)
-* manifest constants: Object-like Macros. (line 6)
-* named operators: C++ Named Operators. (line 6)
-* newlines in macro arguments: Newlines in Arguments.
- (line 6)
-* null directive: Other Directives. (line 15)
-* numbers: Tokenization. (line 61)
-* object-like macro: Object-like Macros. (line 6)
-* options: Invocation. (line 38)
-* options, grouping: Invocation. (line 34)
-* other tokens: Tokenization. (line 120)
-* output format: Preprocessor Output. (line 12)
-* overriding a header file: Wrapper Headers. (line 6)
-* parentheses in macro bodies: Operator Precedence Problems.
- (line 6)
-* pitfalls of macros: Macro Pitfalls. (line 6)
-* predefined macros: Predefined Macros. (line 6)
-* predefined macros, system-specific: System-specific Predefined Macros.
- (line 6)
-* predicates: Obsolete Features. (line 26)
-* preprocessing directives: The preprocessing language.
- (line 6)
-* preprocessing numbers: Tokenization. (line 61)
-* preprocessing tokens: Tokenization. (line 6)
-* prescan of macro arguments: Argument Prescan. (line 6)
-* problems with macros: Macro Pitfalls. (line 6)
-* punctuators: Tokenization. (line 106)
-* redefining macros: Undefining and Redefining Macros.
- (line 6)
-* repeated inclusion: Once-Only Headers. (line 6)
-* reporting errors: Diagnostics. (line 6)
-* reporting warnings: Diagnostics. (line 6)
-* reserved namespace: System-specific Predefined Macros.
- (line 6)
-* self-reference: Self-Referential Macros.
- (line 6)
-* semicolons (after macro calls): Swallowing the Semicolon.
- (line 6)
-* side effects (in macro arguments): Duplication of Side Effects.
- (line 6)
-* standard predefined macros.: Standard Predefined Macros.
- (line 6)
-* string constants: Tokenization. (line 85)
-* string literals: Tokenization. (line 85)
-* stringification: Stringification. (line 6)
-* symbolic constants: Object-like Macros. (line 6)
-* system header files <1>: System Headers. (line 6)
-* system header files: Header Files. (line 13)
-* system-specific predefined macros: System-specific Predefined Macros.
- (line 6)
-* testing predicates: Obsolete Features. (line 37)
-* token concatenation: Concatenation. (line 6)
-* token pasting: Concatenation. (line 6)
-* tokens: Tokenization. (line 6)
-* trigraphs: Initial processing. (line 32)
-* undefining macros: Undefining and Redefining Macros.
- (line 6)
-* unsafe macros: Duplication of Side Effects.
- (line 6)
-* variable number of arguments: Variadic Macros. (line 6)
-* variadic macros: Variadic Macros. (line 6)
-* wrapper #ifndef: Once-Only Headers. (line 6)
-* wrapper headers: Wrapper Headers. (line 6)
-
-
-
-Tag Table:
-Node: Top1149
-Node: Overview3881
-Node: Character sets6714
-Ref: Character sets-Footnote-18897
-Node: Initial processing9078
-Ref: trigraphs10637
-Node: Tokenization14839
-Ref: Tokenization-Footnote-121975
-Node: The preprocessing language22086
-Node: Header Files24964
-Node: Include Syntax26880
-Node: Include Operation28517
-Node: Search Path30365
-Node: Once-Only Headers33555
-Node: Alternatives to Wrapper #ifndef35214
-Node: Computed Includes36957
-Node: Wrapper Headers40115
-Node: System Headers42541
-Node: Macros44591
-Node: Object-like Macros45732
-Node: Function-like Macros49322
-Node: Macro Arguments50938
-Node: Stringification55083
-Node: Concatenation58289
-Node: Variadic Macros61397
-Node: Predefined Macros66184
-Node: Standard Predefined Macros66772
-Node: Common Predefined Macros72709
-Node: System-specific Predefined Macros90212
-Node: C++ Named Operators92233
-Node: Undefining and Redefining Macros93197
-Node: Directives Within Macro Arguments95301
-Node: Macro Pitfalls96849
-Node: Misnesting97382
-Node: Operator Precedence Problems98494
-Node: Swallowing the Semicolon100360
-Node: Duplication of Side Effects102383
-Node: Self-Referential Macros104566
-Node: Argument Prescan106975
-Node: Newlines in Arguments110729
-Node: Conditionals111680
-Node: Conditional Uses113510
-Node: Conditional Syntax114868
-Node: Ifdef115188
-Node: If118349
-Node: Defined120653
-Node: Else121936
-Node: Elif122506
-Node: Deleted Code123795
-Node: Diagnostics125042
-Node: Line Control126659
-Node: Pragmas130463
-Node: Other Directives134780
-Node: Preprocessor Output135830
-Node: Traditional Mode139031
-Node: Traditional lexical analysis140089
-Node: Traditional macros142592
-Node: Traditional miscellany146394
-Node: Traditional warnings147391
-Node: Implementation Details149588
-Node: Implementation-defined behavior150209
-Ref: Identifier characters150961
-Node: Implementation limits154039
-Node: Obsolete Features156713
-Node: Differences from previous versions159601
-Node: Invocation163809
-Ref: Wtrigraphs168261
-Ref: dashMF173036
-Ref: fdollars-in-identifiers182747
-Node: Environment Variables190910
-Node: GNU Free Documentation License193876
-Node: Index of Directives219040
-Node: Option Index220974
-Node: Concept Index227158
-
-End Tag Table
diff --git a/share/info/cppinternals.info b/share/info/cppinternals.info
deleted file mode 100644
index d7a6ba7..0000000
--- a/share/info/cppinternals.info
+++ /dev/null
@@ -1,1036 +0,0 @@
-This is doc/cppinternals.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gcc/gcc-4.6/gcc/doc/cppinternals.texi.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* Cpplib: (cppinternals). Cpplib internals.
-END-INFO-DIR-ENTRY
-
- This file documents the internals of the GNU C Preprocessor.
-
- Copyright 2000, 2001, 2002, 2004, 2005, 2006, 2007 Free Software
-Foundation, Inc.
-
- Permission is granted to make and distribute verbatim copies of this
-manual provided the copyright notice and this permission notice are
-preserved on all copies.
-
- Permission is granted to copy and distribute modified versions of
-this manual under the conditions for verbatim copying, provided also
-that the entire resulting derived work is distributed under the terms
-of a permission notice identical to this one.
-
- Permission is granted to copy and distribute translations of this
-manual into another language, under the above conditions for modified
-versions.
-
-
-File: cppinternals.info, Node: Top, Next: Conventions, Up: (dir)
-
-The GNU C Preprocessor Internals
-********************************
-
-1 Cpplib--the GNU C Preprocessor
-********************************
-
-The GNU C preprocessor is implemented as a library, "cpplib", so it can
-be easily shared between a stand-alone preprocessor, and a preprocessor
-integrated with the C, C++ and Objective-C front ends. It is also
-available for use by other programs, though this is not recommended as
-its exposed interface has not yet reached a point of reasonable
-stability.
-
- The library has been written to be re-entrant, so that it can be used
-to preprocess many files simultaneously if necessary. It has also been
-written with the preprocessing token as the fundamental unit; the
-preprocessor in previous versions of GCC would operate on text strings
-as the fundamental unit.
-
- This brief manual documents the internals of cpplib, and explains
-some of the tricky issues. It is intended that, along with the
-comments in the source code, a reasonably competent C programmer should
-be able to figure out what the code is doing, and why things have been
-implemented the way they have.
-
-* Menu:
-
-* Conventions:: Conventions used in the code.
-* Lexer:: The combined C, C++ and Objective-C Lexer.
-* Hash Nodes:: All identifiers are entered into a hash table.
-* Macro Expansion:: Macro expansion algorithm.
-* Token Spacing:: Spacing and paste avoidance issues.
-* Line Numbering:: Tracking location within files.
-* Guard Macros:: Optimizing header files with guard macros.
-* Files:: File handling.
-* Concept Index:: Index.
-
-
-File: cppinternals.info, Node: Conventions, Next: Lexer, Prev: Top, Up: Top
-
-Conventions
-***********
-
-cpplib has two interfaces--one is exposed internally only, and the
-other is for both internal and external use.
-
- The convention is that functions and types that are exposed to
-multiple files internally are prefixed with `_cpp_', and are to be
-found in the file `internal.h'. Functions and types exposed to external
-clients are in `cpplib.h', and prefixed with `cpp_'. For historical
-reasons this is no longer quite true, but we should strive to stick to
-it.
-
- We are striving to reduce the information exposed in `cpplib.h' to
-the bare minimum necessary, and then to keep it there. This makes clear
-exactly what external clients are entitled to assume, and allows us to
-change internals in the future without worrying whether library clients
-are perhaps relying on some kind of undocumented implementation-specific
-behavior.
-
-
-File: cppinternals.info, Node: Lexer, Next: Hash Nodes, Prev: Conventions, Up: Top
-
-The Lexer
-*********
-
-Overview
-========
-
-The lexer is contained in the file `lex.c'. It is a hand-coded lexer,
-and not implemented as a state machine. It can understand C, C++ and
-Objective-C source code, and has been extended to allow reasonably
-successful preprocessing of assembly language. The lexer does not make
-an initial pass to strip out trigraphs and escaped newlines, but handles
-them as they are encountered in a single pass of the input file. It
-returns preprocessing tokens individually, not a line at a time.
-
- It is mostly transparent to users of the library, since the library's
-interface for obtaining the next token, `cpp_get_token', takes care of
-lexing new tokens, handling directives, and expanding macros as
-necessary. However, the lexer does expose some functionality so that
-clients of the library can easily spell a given token, such as
-`cpp_spell_token' and `cpp_token_len'. These functions are useful when
-generating diagnostics, and for emitting the preprocessed output.
-
-Lexing a token
-==============
-
-Lexing of an individual token is handled by `_cpp_lex_direct' and its
-subroutines. In its current form the code is quite complicated, with
-read ahead characters and such-like, since it strives to not step back
-in the character stream in preparation for handling non-ASCII file
-encodings. The current plan is to convert any such files to UTF-8
-before processing them. This complexity is therefore unnecessary and
-will be removed, so I'll not discuss it further here.
-
- The job of `_cpp_lex_direct' is simply to lex a token. It is not
-responsible for issues like directive handling, returning lookahead
-tokens directly, multiple-include optimization, or conditional block
-skipping. It necessarily has a minor ro^le to play in memory
-management of lexed lines. I discuss these issues in a separate section
-(*note Lexing a line::).
-
- The lexer places the token it lexes into storage pointed to by the
-variable `cur_token', and then increments it. This variable is
-important for correct diagnostic positioning. Unless a specific line
-and column are passed to the diagnostic routines, they will examine the
-`line' and `col' values of the token just before the location that
-`cur_token' points to, and use that location to report the diagnostic.
-
- The lexer does not consider whitespace to be a token in its own
-right. If whitespace (other than a new line) precedes a token, it sets
-the `PREV_WHITE' bit in the token's flags. Each token has its `line'
-and `col' variables set to the line and column of the first character
-of the token. This line number is the line number in the translation
-unit, and can be converted to a source (file, line) pair using the line
-map code.
-
- The first token on a logical, i.e. unescaped, line has the flag
-`BOL' set for beginning-of-line. This flag is intended for internal
-use, both to distinguish a `#' that begins a directive from one that
-doesn't, and to generate a call-back to clients that want to be
-notified about the start of every non-directive line with tokens on it.
-Clients cannot reliably determine this for themselves: the first token
-might be a macro, and the tokens of a macro expansion do not have the
-`BOL' flag set. The macro expansion may even be empty, and the next
-token on the line certainly won't have the `BOL' flag set.
-
- New lines are treated specially; exactly how the lexer handles them
-is context-dependent. The C standard mandates that directives are
-terminated by the first unescaped newline character, even if it appears
-in the middle of a macro expansion. Therefore, if the state variable
-`in_directive' is set, the lexer returns a `CPP_EOF' token, which is
-normally used to indicate end-of-file, to indicate end-of-directive.
-In a directive a `CPP_EOF' token never means end-of-file.
-Conveniently, if the caller was `collect_args', it already handles
-`CPP_EOF' as if it were end-of-file, and reports an error about an
-unterminated macro argument list.
-
- The C standard also specifies that a new line in the middle of the
-arguments to a macro is treated as whitespace. This white space is
-important in case the macro argument is stringified. The state variable
-`parsing_args' is nonzero when the preprocessor is collecting the
-arguments to a macro call. It is set to 1 when looking for the opening
-parenthesis to a function-like macro, and 2 when collecting the actual
-arguments up to the closing parenthesis, since these two cases need to
-be distinguished sometimes. One such time is here: the lexer sets the
-`PREV_WHITE' flag of a token if it meets a new line when `parsing_args'
-is set to 2. It doesn't set it if it meets a new line when
-`parsing_args' is 1, since then code like
-
- #define foo() bar
- foo
- baz
-
-would be output with an erroneous space before `baz':
-
- foo
- baz
-
- This is a good example of the subtlety of getting token spacing
-correct in the preprocessor; there are plenty of tests in the testsuite
-for corner cases like this.
-
- The lexer is written to treat each of `\r', `\n', `\r\n' and `\n\r'
-as a single new line indicator. This allows it to transparently
-preprocess MS-DOS, Macintosh and Unix files without their needing to
-pass through a special filter beforehand.
-
- We also decided to treat a backslash, either `\' or the trigraph
-`??/', separated from one of the above newline indicators by
-non-comment whitespace only, as intending to escape the newline. It
-tends to be a typing mistake, and cannot reasonably be mistaken for
-anything else in any of the C-family grammars. Since handling it this
-way is not strictly conforming to the ISO standard, the library issues a
-warning wherever it encounters it.
-
- Handling newlines like this is made simpler by doing it in one place
-only. The function `handle_newline' takes care of all newline
-characters, and `skip_escaped_newlines' takes care of arbitrarily long
-sequences of escaped newlines, deferring to `handle_newline' to handle
-the newlines themselves.
-
- The most painful aspect of lexing ISO-standard C and C++ is handling
-trigraphs and backlash-escaped newlines. Trigraphs are processed before
-any interpretation of the meaning of a character is made, and
-unfortunately there is a trigraph representation for a backslash, so it
-is possible for the trigraph `??/' to introduce an escaped newline.
-
- Escaped newlines are tedious because theoretically they can occur
-anywhere--between the `+' and `=' of the `+=' token, within the
-characters of an identifier, and even between the `*' and `/' that
-terminates a comment. Moreover, you cannot be sure there is just
-one--there might be an arbitrarily long sequence of them.
-
- So, for example, the routine that lexes a number, `parse_number',
-cannot assume that it can scan forwards until the first non-number
-character and be done with it, because this could be the `\'
-introducing an escaped newline, or the `?' introducing the trigraph
-sequence that represents the `\' of an escaped newline. If it
-encounters a `?' or `\', it calls `skip_escaped_newlines' to skip over
-any potential escaped newlines before checking whether the number has
-been finished.
-
- Similarly code in the main body of `_cpp_lex_direct' cannot simply
-check for a `=' after a `+' character to determine whether it has a
-`+=' token; it needs to be prepared for an escaped newline of some
-sort. Such cases use the function `get_effective_char', which returns
-the first character after any intervening escaped newlines.
-
- The lexer needs to keep track of the correct column position,
-including counting tabs as specified by the `-ftabstop=' option. This
-should be done even within C-style comments; they can appear in the
-middle of a line, and we want to report diagnostics in the correct
-position for text appearing after the end of the comment.
-
- Some identifiers, such as `__VA_ARGS__' and poisoned identifiers,
-may be invalid and require a diagnostic. However, if they appear in a
-macro expansion we don't want to complain with each use of the macro.
-It is therefore best to catch them during the lexing stage, in
-`parse_identifier'. In both cases, whether a diagnostic is needed or
-not is dependent upon the lexer's state. For example, we don't want to
-issue a diagnostic for re-poisoning a poisoned identifier, or for using
-`__VA_ARGS__' in the expansion of a variable-argument macro. Therefore
-`parse_identifier' makes use of state flags to determine whether a
-diagnostic is appropriate. Since we change state on a per-token basis,
-and don't lex whole lines at a time, this is not a problem.
-
- Another place where state flags are used to change behavior is whilst
-lexing header names. Normally, a `<' would be lexed as a single token.
-After a `#include' directive, though, it should be lexed as a single
-token as far as the nearest `>' character. Note that we don't allow
-the terminators of header names to be escaped; the first `"' or `>'
-terminates the header name.
-
- Interpretation of some character sequences depends upon whether we
-are lexing C, C++ or Objective-C, and on the revision of the standard in
-force. For example, `::' is a single token in C++, but in C it is two
-separate `:' tokens and almost certainly a syntax error. Such cases
-are handled by `_cpp_lex_direct' based upon command-line flags stored
-in the `cpp_options' structure.
-
- Once a token has been lexed, it leads an independent existence. The
-spelling of numbers, identifiers and strings is copied to permanent
-storage from the original input buffer, so a token remains valid and
-correct even if its source buffer is freed with `_cpp_pop_buffer'. The
-storage holding the spellings of such tokens remains until the client
-program calls cpp_destroy, probably at the end of the translation unit.
-
-Lexing a line
-=============
-
-When the preprocessor was changed to return pointers to tokens, one
-feature I wanted was some sort of guarantee regarding how long a
-returned pointer remains valid. This is important to the stand-alone
-preprocessor, the future direction of the C family front ends, and even
-to cpplib itself internally.
-
- Occasionally the preprocessor wants to be able to peek ahead in the
-token stream. For example, after the name of a function-like macro, it
-wants to check the next token to see if it is an opening parenthesis.
-Another example is that, after reading the first few tokens of a
-`#pragma' directive and not recognizing it as a registered pragma, it
-wants to backtrack and allow the user-defined handler for unknown
-pragmas to access the full `#pragma' token stream. The stand-alone
-preprocessor wants to be able to test the current token with the
-previous one to see if a space needs to be inserted to preserve their
-separate tokenization upon re-lexing (paste avoidance), so it needs to
-be sure the pointer to the previous token is still valid. The
-recursive-descent C++ parser wants to be able to perform tentative
-parsing arbitrarily far ahead in the token stream, and then to be able
-to jump back to a prior position in that stream if necessary.
-
- The rule I chose, which is fairly natural, is to arrange that the
-preprocessor lex all tokens on a line consecutively into a token buffer,
-which I call a "token run", and when meeting an unescaped new line
-(newlines within comments do not count either), to start lexing back at
-the beginning of the run. Note that we do _not_ lex a line of tokens
-at once; if we did that `parse_identifier' would not have state flags
-available to warn about invalid identifiers (*note Invalid
-identifiers::).
-
- In other words, accessing tokens that appeared earlier in the current
-line is valid, but since each logical line overwrites the tokens of the
-previous line, tokens from prior lines are unavailable. In particular,
-since a directive only occupies a single logical line, this means that
-the directive handlers like the `#pragma' handler can jump around in
-the directive's tokens if necessary.
-
- Two issues remain: what about tokens that arise from macro
-expansions, and what happens when we have a long line that overflows
-the token run?
-
- Since we promise clients that we preserve the validity of pointers
-that we have already returned for tokens that appeared earlier in the
-line, we cannot reallocate the run. Instead, on overflow it is
-expanded by chaining a new token run on to the end of the existing one.
-
- The tokens forming a macro's replacement list are collected by the
-`#define' handler, and placed in storage that is only freed by
-`cpp_destroy'. So if a macro is expanded in the line of tokens, the
-pointers to the tokens of its expansion that are returned will always
-remain valid. However, macros are a little trickier than that, since
-they give rise to three sources of fresh tokens. They are the built-in
-macros like `__LINE__', and the `#' and `##' operators for
-stringification and token pasting. I handled this by allocating space
-for these tokens from the lexer's token run chain. This means they
-automatically receive the same lifetime guarantees as lexed tokens, and
-we don't need to concern ourselves with freeing them.
-
- Lexing into a line of tokens solves some of the token memory
-management issues, but not all. The opening parenthesis after a
-function-like macro name might lie on a different line, and the front
-ends definitely want the ability to look ahead past the end of the
-current line. So cpplib only moves back to the start of the token run
-at the end of a line if the variable `keep_tokens' is zero.
-Line-buffering is quite natural for the preprocessor, and as a result
-the only time cpplib needs to increment this variable is whilst looking
-for the opening parenthesis to, and reading the arguments of, a
-function-like macro. In the near future cpplib will export an
-interface to increment and decrement this variable, so that clients can
-share full control over the lifetime of token pointers too.
-
- The routine `_cpp_lex_token' handles moving to new token runs,
-calling `_cpp_lex_direct' to lex new tokens, or returning
-previously-lexed tokens if we stepped back in the token stream. It also
-checks each token for the `BOL' flag, which might indicate a directive
-that needs to be handled, or require a start-of-line call-back to be
-made. `_cpp_lex_token' also handles skipping over tokens in failed
-conditional blocks, and invalidates the control macro of the
-multiple-include optimization if a token was successfully lexed outside
-a directive. In other words, its callers do not need to concern
-themselves with such issues.
-
-
-File: cppinternals.info, Node: Hash Nodes, Next: Macro Expansion, Prev: Lexer, Up: Top
-
-Hash Nodes
-**********
-
-When cpplib encounters an "identifier", it generates a hash code for it
-and stores it in the hash table. By "identifier" we mean tokens with
-type `CPP_NAME'; this includes identifiers in the usual C sense, as
-well as keywords, directive names, macro names and so on. For example,
-all of `pragma', `int', `foo' and `__GNUC__' are identifiers and hashed
-when lexed.
-
- Each node in the hash table contain various information about the
-identifier it represents. For example, its length and type. At any one
-time, each identifier falls into exactly one of three categories:
-
- * Macros
-
- These have been declared to be macros, either on the command line
- or with `#define'. A few, such as `__TIME__' are built-ins
- entered in the hash table during initialization. The hash node
- for a normal macro points to a structure with more information
- about the macro, such as whether it is function-like, how many
- arguments it takes, and its expansion. Built-in macros are
- flagged as special, and instead contain an enum indicating which
- of the various built-in macros it is.
-
- * Assertions
-
- Assertions are in a separate namespace to macros. To enforce
- this, cpp actually prepends a `#' character before hashing and
- entering it in the hash table. An assertion's node points to a
- chain of answers to that assertion.
-
- * Void
-
- Everything else falls into this category--an identifier that is not
- currently a macro, or a macro that has since been undefined with
- `#undef'.
-
- When preprocessing C++, this category also includes the named
- operators, such as `xor'. In expressions these behave like the
- operators they represent, but in contexts where the spelling of a
- token matters they are spelt differently. This spelling
- distinction is relevant when they are operands of the stringizing
- and pasting macro operators `#' and `##'. Named operator hash
- nodes are flagged, both to catch the spelling distinction and to
- prevent them from being defined as macros.
-
- The same identifiers share the same hash node. Since each identifier
-token, after lexing, contains a pointer to its hash node, this is used
-to provide rapid lookup of various information. For example, when
-parsing a `#define' statement, CPP flags each argument's identifier
-hash node with the index of that argument. This makes duplicated
-argument checking an O(1) operation for each argument. Similarly, for
-each identifier in the macro's expansion, lookup to see if it is an
-argument, and which argument it is, is also an O(1) operation. Further,
-each directive name, such as `endif', has an associated directive enum
-stored in its hash node, so that directive lookup is also O(1).
-
-
-File: cppinternals.info, Node: Macro Expansion, Next: Token Spacing, Prev: Hash Nodes, Up: Top
-
-Macro Expansion Algorithm
-*************************
-
-Macro expansion is a tricky operation, fraught with nasty corner cases
-and situations that render what you thought was a nifty way to optimize
-the preprocessor's expansion algorithm wrong in quite subtle ways.
-
- I strongly recommend you have a good grasp of how the C and C++
-standards require macros to be expanded before diving into this
-section, let alone the code!. If you don't have a clear mental picture
-of how things like nested macro expansion, stringification and token
-pasting are supposed to work, damage to your sanity can quickly result.
-
-Internal representation of macros
-=================================
-
-The preprocessor stores macro expansions in tokenized form. This saves
-repeated lexing passes during expansion, at the cost of a small
-increase in memory consumption on average. The tokens are stored
-contiguously in memory, so a pointer to the first one and a token count
-is all you need to get the replacement list of a macro.
-
- If the macro is a function-like macro the preprocessor also stores
-its parameters, in the form of an ordered list of pointers to the hash
-table entry of each parameter's identifier. Further, in the macro's
-stored expansion each occurrence of a parameter is replaced with a
-special token of type `CPP_MACRO_ARG'. Each such token holds the index
-of the parameter it represents in the parameter list, which allows
-rapid replacement of parameters with their arguments during expansion.
-Despite this optimization it is still necessary to store the original
-parameters to the macro, both for dumping with e.g., `-dD', and to warn
-about non-trivial macro redefinitions when the parameter names have
-changed.
-
-Macro expansion overview
-========================
-
-The preprocessor maintains a "context stack", implemented as a linked
-list of `cpp_context' structures, which together represent the macro
-expansion state at any one time. The `struct cpp_reader' member
-variable `context' points to the current top of this stack. The top
-normally holds the unexpanded replacement list of the innermost macro
-under expansion, except when cpplib is about to pre-expand an argument,
-in which case it holds that argument's unexpanded tokens.
-
- When there are no macros under expansion, cpplib is in "base
-context". All contexts other than the base context contain a
-contiguous list of tokens delimited by a starting and ending token.
-When not in base context, cpplib obtains the next token from the list
-of the top context. If there are no tokens left in the list, it pops
-that context off the stack, and subsequent ones if necessary, until an
-unexhausted context is found or it returns to base context. In base
-context, cpplib reads tokens directly from the lexer.
-
- If it encounters an identifier that is both a macro and enabled for
-expansion, cpplib prepares to push a new context for that macro on the
-stack by calling the routine `enter_macro_context'. When this routine
-returns, the new context will contain the unexpanded tokens of the
-replacement list of that macro. In the case of function-like macros,
-`enter_macro_context' also replaces any parameters in the replacement
-list, stored as `CPP_MACRO_ARG' tokens, with the appropriate macro
-argument. If the standard requires that the parameter be replaced with
-its expanded argument, the argument will have been fully macro expanded
-first.
-
- `enter_macro_context' also handles special macros like `__LINE__'.
-Although these macros expand to a single token which cannot contain any
-further macros, for reasons of token spacing (*note Token Spacing::)
-and simplicity of implementation, cpplib handles these special macros
-by pushing a context containing just that one token.
-
- The final thing that `enter_macro_context' does before returning is
-to mark the macro disabled for expansion (except for special macros
-like `__TIME__'). The macro is re-enabled when its context is later
-popped from the context stack, as described above. This strict
-ordering ensures that a macro is disabled whilst its expansion is being
-scanned, but that it is _not_ disabled whilst any arguments to it are
-being expanded.
-
-Scanning the replacement list for macros to expand
-==================================================
-
-The C standard states that, after any parameters have been replaced
-with their possibly-expanded arguments, the replacement list is scanned
-for nested macros. Further, any identifiers in the replacement list
-that are not expanded during this scan are never again eligible for
-expansion in the future, if the reason they were not expanded is that
-the macro in question was disabled.
-
- Clearly this latter condition can only apply to tokens resulting from
-argument pre-expansion. Other tokens never have an opportunity to be
-re-tested for expansion. It is possible for identifiers that are
-function-like macros to not expand initially but to expand during a
-later scan. This occurs when the identifier is the last token of an
-argument (and therefore originally followed by a comma or a closing
-parenthesis in its macro's argument list), and when it replaces its
-parameter in the macro's replacement list, the subsequent token happens
-to be an opening parenthesis (itself possibly the first token of an
-argument).
-
- It is important to note that when cpplib reads the last token of a
-given context, that context still remains on the stack. Only when
-looking for the _next_ token do we pop it off the stack and drop to a
-lower context. This makes backing up by one token easy, but more
-importantly ensures that the macro corresponding to the current context
-is still disabled when we are considering the last token of its
-replacement list for expansion (or indeed expanding it). As an
-example, which illustrates many of the points above, consider
-
- #define foo(x) bar x
- foo(foo) (2)
-
-which fully expands to `bar foo (2)'. During pre-expansion of the
-argument, `foo' does not expand even though the macro is enabled, since
-it has no following parenthesis [pre-expansion of an argument only uses
-tokens from that argument; it cannot take tokens from whatever follows
-the macro invocation]. This still leaves the argument token `foo'
-eligible for future expansion. Then, when re-scanning after argument
-replacement, the token `foo' is rejected for expansion, and marked
-ineligible for future expansion, since the macro is now disabled. It
-is disabled because the replacement list `bar foo' of the macro is
-still on the context stack.
-
- If instead the algorithm looked for an opening parenthesis first and
-then tested whether the macro were disabled it would be subtly wrong.
-In the example above, the replacement list of `foo' would be popped in
-the process of finding the parenthesis, re-enabling `foo' and expanding
-it a second time.
-
-Looking for a function-like macro's opening parenthesis
-=======================================================
-
-Function-like macros only expand when immediately followed by a
-parenthesis. To do this cpplib needs to temporarily disable macros and
-read the next token. Unfortunately, because of spacing issues (*note
-Token Spacing::), there can be fake padding tokens in-between, and if
-the next real token is not a parenthesis cpplib needs to be able to
-back up that one token as well as retain the information in any
-intervening padding tokens.
-
- Backing up more than one token when macros are involved is not
-permitted by cpplib, because in general it might involve issues like
-restoring popped contexts onto the context stack, which are too hard.
-Instead, searching for the parenthesis is handled by a special
-function, `funlike_invocation_p', which remembers padding information
-as it reads tokens. If the next real token is not an opening
-parenthesis, it backs up that one token, and then pushes an extra
-context just containing the padding information if necessary.
-
-Marking tokens ineligible for future expansion
-==============================================
-
-As discussed above, cpplib needs a way of marking tokens as
-unexpandable. Since the tokens cpplib handles are read-only once they
-have been lexed, it instead makes a copy of the token and adds the flag
-`NO_EXPAND' to the copy.
-
- For efficiency and to simplify memory management by avoiding having
-to remember to free these tokens, they are allocated as temporary tokens
-from the lexer's current token run (*note Lexing a line::) using the
-function `_cpp_temp_token'. The tokens are then re-used once the
-current line of tokens has been read in.
-
- This might sound unsafe. However, tokens runs are not re-used at the
-end of a line if it happens to be in the middle of a macro argument
-list, and cpplib only wants to back-up more than one lexer token in
-situations where no macro expansion is involved, so the optimization is
-safe.
-
-
-File: cppinternals.info, Node: Token Spacing, Next: Line Numbering, Prev: Macro Expansion, Up: Top
-
-Token Spacing
-*************
-
-First, consider an issue that only concerns the stand-alone
-preprocessor: there needs to be a guarantee that re-reading its
-preprocessed output results in an identical token stream. Without
-taking special measures, this might not be the case because of macro
-substitution. For example:
-
- #define PLUS +
- #define EMPTY
- #define f(x) =x=
- +PLUS -EMPTY- PLUS+ f(=)
- ==> + + - - + + = = =
- _not_
- ==> ++ -- ++ ===
-
- One solution would be to simply insert a space between all adjacent
-tokens. However, we would like to keep space insertion to a minimum,
-both for aesthetic reasons and because it causes problems for people who
-still try to abuse the preprocessor for things like Fortran source and
-Makefiles.
-
- For now, just notice that when tokens are added (or removed, as
-shown by the `EMPTY' example) from the original lexed token stream, we
-need to check for accidental token pasting. We call this "paste
-avoidance". Token addition and removal can only occur because of macro
-expansion, but accidental pasting can occur in many places: both before
-and after each macro replacement, each argument replacement, and
-additionally each token created by the `#' and `##' operators.
-
- Look at how the preprocessor gets whitespace output correct
-normally. The `cpp_token' structure contains a flags byte, and one of
-those flags is `PREV_WHITE'. This is flagged by the lexer, and
-indicates that the token was preceded by whitespace of some form other
-than a new line. The stand-alone preprocessor can use this flag to
-decide whether to insert a space between tokens in the output.
-
- Now consider the result of the following macro expansion:
-
- #define add(x, y, z) x + y +z;
- sum = add (1,2, 3);
- ==> sum = 1 + 2 +3;
-
- The interesting thing here is that the tokens `1' and `2' are output
-with a preceding space, and `3' is output without a preceding space,
-but when lexed none of these tokens had that property. Careful
-consideration reveals that `1' gets its preceding whitespace from the
-space preceding `add' in the macro invocation, _not_ replacement list.
-`2' gets its whitespace from the space preceding the parameter `y' in
-the macro replacement list, and `3' has no preceding space because
-parameter `z' has none in the replacement list.
-
- Once lexed, tokens are effectively fixed and cannot be altered, since
-pointers to them might be held in many places, in particular by
-in-progress macro expansions. So instead of modifying the two tokens
-above, the preprocessor inserts a special token, which I call a
-"padding token", into the token stream to indicate that spacing of the
-subsequent token is special. The preprocessor inserts padding tokens
-in front of every macro expansion and expanded macro argument. These
-point to a "source token" from which the subsequent real token should
-inherit its spacing. In the above example, the source tokens are `add'
-in the macro invocation, and `y' and `z' in the macro replacement list,
-respectively.
-
- It is quite easy to get multiple padding tokens in a row, for
-example if a macro's first replacement token expands straight into
-another macro.
-
- #define foo bar
- #define bar baz
- [foo]
- ==> [baz]
-
- Here, two padding tokens are generated with sources the `foo' token
-between the brackets, and the `bar' token from foo's replacement list,
-respectively. Clearly the first padding token is the one to use, so
-the output code should contain a rule that the first padding token in a
-sequence is the one that matters.
-
- But what if a macro expansion is left? Adjusting the above example
-slightly:
-
- #define foo bar
- #define bar EMPTY baz
- #define EMPTY
- [foo] EMPTY;
- ==> [ baz] ;
-
- As shown, now there should be a space before `baz' and the semicolon
-in the output.
-
- The rules we decided above fail for `baz': we generate three padding
-tokens, one per macro invocation, before the token `baz'. We would
-then have it take its spacing from the first of these, which carries
-source token `foo' with no leading space.
-
- It is vital that cpplib get spacing correct in these examples since
-any of these macro expansions could be stringified, where spacing
-matters.
-
- So, this demonstrates that not just entering macro and argument
-expansions, but leaving them requires special handling too. I made
-cpplib insert a padding token with a `NULL' source token when leaving
-macro expansions, as well as after each replaced argument in a macro's
-replacement list. It also inserts appropriate padding tokens on either
-side of tokens created by the `#' and `##' operators. I expanded the
-rule so that, if we see a padding token with a `NULL' source token,
-_and_ that source token has no leading space, then we behave as if we
-have seen no padding tokens at all. A quick check shows this rule will
-then get the above example correct as well.
-
- Now a relationship with paste avoidance is apparent: we have to be
-careful about paste avoidance in exactly the same locations we have
-padding tokens in order to get white space correct. This makes
-implementation of paste avoidance easy: wherever the stand-alone
-preprocessor is fixing up spacing because of padding tokens, and it
-turns out that no space is needed, it has to take the extra step to
-check that a space is not needed after all to avoid an accidental paste.
-The function `cpp_avoid_paste' advises whether a space is required
-between two consecutive tokens. To avoid excessive spacing, it tries
-hard to only require a space if one is likely to be necessary, but for
-reasons of efficiency it is slightly conservative and might recommend a
-space where one is not strictly needed.
-
-
-File: cppinternals.info, Node: Line Numbering, Next: Guard Macros, Prev: Token Spacing, Up: Top
-
-Line numbering
-**************
-
-Just which line number anyway?
-==============================
-
-There are three reasonable requirements a cpplib client might have for
-the line number of a token passed to it:
-
- * The source line it was lexed on.
-
- * The line it is output on. This can be different to the line it was
- lexed on if, for example, there are intervening escaped newlines or
- C-style comments. For example:
-
- foo /* A long
- comment */ bar \
- baz
- =>
- foo bar baz
-
- * If the token results from a macro expansion, the line of the macro
- name, or possibly the line of the closing parenthesis in the case
- of function-like macro expansion.
-
- The `cpp_token' structure contains `line' and `col' members. The
-lexer fills these in with the line and column of the first character of
-the token. Consequently, but maybe unexpectedly, a token from the
-replacement list of a macro expansion carries the location of the token
-within the `#define' directive, because cpplib expands a macro by
-returning pointers to the tokens in its replacement list. The current
-implementation of cpplib assigns tokens created from built-in macros
-and the `#' and `##' operators the location of the most recently lexed
-token. This is a because they are allocated from the lexer's token
-runs, and because of the way the diagnostic routines infer the
-appropriate location to report.
-
- The diagnostic routines in cpplib display the location of the most
-recently _lexed_ token, unless they are passed a specific line and
-column to report. For diagnostics regarding tokens that arise from
-macro expansions, it might also be helpful for the user to see the
-original location in the macro definition that the token came from.
-Since that is exactly the information each token carries, such an
-enhancement could be made relatively easily in future.
-
- The stand-alone preprocessor faces a similar problem when determining
-the correct line to output the token on: the position attached to a
-token is fairly useless if the token came from a macro expansion. All
-tokens on a logical line should be output on its first physical line, so
-the token's reported location is also wrong if it is part of a physical
-line other than the first.
-
- To solve these issues, cpplib provides a callback that is generated
-whenever it lexes a preprocessing token that starts a new logical line
-other than a directive. It passes this token (which may be a `CPP_EOF'
-token indicating the end of the translation unit) to the callback
-routine, which can then use the line and column of this token to
-produce correct output.
-
-Representation of line numbers
-==============================
-
-As mentioned above, cpplib stores with each token the line number that
-it was lexed on. In fact, this number is not the number of the line in
-the source file, but instead bears more resemblance to the number of the
-line in the translation unit.
-
- The preprocessor maintains a monotonic increasing line count, which
-is incremented at every new line character (and also at the end of any
-buffer that does not end in a new line). Since a line number of zero is
-useful to indicate certain special states and conditions, this variable
-starts counting from one.
-
- This variable therefore uniquely enumerates each line in the
-translation unit. With some simple infrastructure, it is straight
-forward to map from this to the original source file and line number
-pair, saving space whenever line number information needs to be saved.
-The code the implements this mapping lies in the files `line-map.c' and
-`line-map.h'.
-
- Command-line macros and assertions are implemented by pushing a
-buffer containing the right hand side of an equivalent `#define' or
-`#assert' directive. Some built-in macros are handled similarly.
-Since these are all processed before the first line of the main input
-file, it will typically have an assigned line closer to twenty than to
-one.
-
-
-File: cppinternals.info, Node: Guard Macros, Next: Files, Prev: Line Numbering, Up: Top
-
-The Multiple-Include Optimization
-*********************************
-
-Header files are often of the form
-
- #ifndef FOO
- #define FOO
- ...
- #endif
-
-to prevent the compiler from processing them more than once. The
-preprocessor notices such header files, so that if the header file
-appears in a subsequent `#include' directive and `FOO' is defined, then
-it is ignored and it doesn't preprocess or even re-open the file a
-second time. This is referred to as the "multiple include
-optimization".
-
- Under what circumstances is such an optimization valid? If the file
-were included a second time, it can only be optimized away if that
-inclusion would result in no tokens to return, and no relevant
-directives to process. Therefore the current implementation imposes
-requirements and makes some allowances as follows:
-
- 1. There must be no tokens outside the controlling `#if'-`#endif'
- pair, but whitespace and comments are permitted.
-
- 2. There must be no directives outside the controlling directive
- pair, but the "null directive" (a line containing nothing other
- than a single `#' and possibly whitespace) is permitted.
-
- 3. The opening directive must be of the form
-
- #ifndef FOO
-
- or
-
- #if !defined FOO [equivalently, #if !defined(FOO)]
-
- 4. In the second form above, the tokens forming the `#if' expression
- must have come directly from the source file--no macro expansion
- must have been involved. This is because macro definitions can
- change, and tracking whether or not a relevant change has been
- made is not worth the implementation cost.
-
- 5. There can be no `#else' or `#elif' directives at the outer
- conditional block level, because they would probably contain
- something of interest to a subsequent pass.
-
- First, when pushing a new file on the buffer stack,
-`_stack_include_file' sets the controlling macro `mi_cmacro' to `NULL',
-and sets `mi_valid' to `true'. This indicates that the preprocessor
-has not yet encountered anything that would invalidate the
-multiple-include optimization. As described in the next few
-paragraphs, these two variables having these values effectively
-indicates top-of-file.
-
- When about to return a token that is not part of a directive,
-`_cpp_lex_token' sets `mi_valid' to `false'. This enforces the
-constraint that tokens outside the controlling conditional block
-invalidate the optimization.
-
- The `do_if', when appropriate, and `do_ifndef' directive handlers
-pass the controlling macro to the function `push_conditional'. cpplib
-maintains a stack of nested conditional blocks, and after processing
-every opening conditional this function pushes an `if_stack' structure
-onto the stack. In this structure it records the controlling macro for
-the block, provided there is one and we're at top-of-file (as described
-above). If an `#elif' or `#else' directive is encountered, the
-controlling macro for that block is cleared to `NULL'. Otherwise, it
-survives until the `#endif' closing the block, upon which `do_endif'
-sets `mi_valid' to true and stores the controlling macro in `mi_cmacro'.
-
- `_cpp_handle_directive' clears `mi_valid' when processing any
-directive other than an opening conditional and the null directive.
-With this, and requiring top-of-file to record a controlling macro, and
-no `#else' or `#elif' for it to survive and be copied to `mi_cmacro' by
-`do_endif', we have enforced the absence of directives outside the main
-conditional block for the optimization to be on.
-
- Note that whilst we are inside the conditional block, `mi_valid' is
-likely to be reset to `false', but this does not matter since the
-closing `#endif' restores it to `true' if appropriate.
-
- Finally, since `_cpp_lex_direct' pops the file off the buffer stack
-at `EOF' without returning a token, if the `#endif' directive was not
-followed by any tokens, `mi_valid' is `true' and `_cpp_pop_file_buffer'
-remembers the controlling macro associated with the file. Subsequent
-calls to `stack_include_file' result in no buffer being pushed if the
-controlling macro is defined, effecting the optimization.
-
- A quick word on how we handle the
-
- #if !defined FOO
-
-case. `_cpp_parse_expr' and `parse_defined' take steps to see whether
-the three stages `!', `defined-expression' and `end-of-directive' occur
-in order in a `#if' expression. If so, they return the guard macro to
-`do_if' in the variable `mi_ind_cmacro', and otherwise set it to `NULL'.
-`enter_macro_context' sets `mi_valid' to false, so if a macro was
-expanded whilst parsing any part of the expression, then the
-top-of-file test in `push_conditional' fails and the optimization is
-turned off.
-
-
-File: cppinternals.info, Node: Files, Next: Concept Index, Prev: Guard Macros, Up: Top
-
-File Handling
-*************
-
-Fairly obviously, the file handling code of cpplib resides in the file
-`files.c'. It takes care of the details of file searching, opening,
-reading and caching, for both the main source file and all the headers
-it recursively includes.
-
- The basic strategy is to minimize the number of system calls. On
-many systems, the basic `open ()' and `fstat ()' system calls can be
-quite expensive. For every `#include'-d file, we need to try all the
-directories in the search path until we find a match. Some projects,
-such as glibc, pass twenty or thirty include paths on the command line,
-so this can rapidly become time consuming.
-
- For a header file we have not encountered before we have little
-choice but to do this. However, it is often the case that the same
-headers are repeatedly included, and in these cases we try to avoid
-repeating the filesystem queries whilst searching for the correct file.
-
- For each file we try to open, we store the constructed path in a
-splay tree. This path first undergoes simplification by the function
-`_cpp_simplify_pathname'. For example, `/usr/include/bits/../foo.h' is
-simplified to `/usr/include/foo.h' before we enter it in the splay tree
-and try to `open ()' the file. CPP will then find subsequent uses of
-`foo.h', even as `/usr/include/foo.h', in the splay tree and save
-system calls.
-
- Further, it is likely the file contents have also been cached,
-saving a `read ()' system call. We don't bother caching the contents of
-header files that are re-inclusion protected, and whose re-inclusion
-macro is defined when we leave the header file for the first time. If
-the host supports it, we try to map suitably large files into memory,
-rather than reading them in directly.
-
- The include paths are internally stored on a null-terminated
-singly-linked list, starting with the `"header.h"' directory search
-chain, which then links into the `<header.h>' directory chain.
-
- Files included with the `<foo.h>' syntax start the lookup directly
-in the second half of this chain. However, files included with the
-`"foo.h"' syntax start at the beginning of the chain, but with one
-extra directory prepended. This is the directory of the current file;
-the one containing the `#include' directive. Prepending this directory
-on a per-file basis is handled by the function `search_from'.
-
- Note that a header included with a directory component, such as
-`#include "mydir/foo.h"' and opened as
-`/usr/local/include/mydir/foo.h', will have the complete path minus the
-basename `foo.h' as the current directory.
-
- Enough information is stored in the splay tree that CPP can
-immediately tell whether it can skip the header file because of the
-multiple include optimization, whether the file didn't exist or
-couldn't be opened for some reason, or whether the header was flagged
-not to be re-used, as it is with the obsolete `#import' directive.
-
- For the benefit of MS-DOS filesystems with an 8.3 filename
-limitation, CPP offers the ability to treat various include file names
-as aliases for the real header files with shorter names. The map from
-one to the other is found in a special file called `header.gcc', stored
-in the command line (or system) include directories to which the mapping
-applies. This may be higher up the directory tree than the full path to
-the file minus the base name.
-
-
-File: cppinternals.info, Node: Concept Index, Prev: Files, Up: Top
-
-Concept Index
-*************
-
-
-* Menu:
-
-* assertions: Hash Nodes. (line 6)
-* controlling macros: Guard Macros. (line 6)
-* escaped newlines: Lexer. (line 6)
-* files: Files. (line 6)
-* guard macros: Guard Macros. (line 6)
-* hash table: Hash Nodes. (line 6)
-* header files: Conventions. (line 6)
-* identifiers: Hash Nodes. (line 6)
-* interface: Conventions. (line 6)
-* lexer: Lexer. (line 6)
-* line numbers: Line Numbering. (line 6)
-* macro expansion: Macro Expansion. (line 6)
-* macro representation (internal): Macro Expansion. (line 19)
-* macros: Hash Nodes. (line 6)
-* multiple-include optimization: Guard Macros. (line 6)
-* named operators: Hash Nodes. (line 6)
-* newlines: Lexer. (line 6)
-* paste avoidance: Token Spacing. (line 6)
-* spacing: Token Spacing. (line 6)
-* token run: Lexer. (line 192)
-* token spacing: Token Spacing. (line 6)
-
-
-
-Tag Table:
-Node: Top1011
-Node: Conventions2696
-Node: Lexer3638
-Ref: Invalid identifiers11551
-Ref: Lexing a line13500
-Node: Hash Nodes18273
-Node: Macro Expansion21152
-Node: Token Spacing30099
-Node: Line Numbering35959
-Node: Guard Macros40044
-Node: Files44835
-Node: Concept Index48301
-
-End Tag Table
diff --git a/share/info/dir b/share/info/dir
deleted file mode 100644
index b452d27..0000000
--- a/share/info/dir
+++ /dev/null
@@ -1,65 +0,0 @@
-This is the file .../info/dir, which contains the
-topmost node of the Info hierarchy, called (dir)Top.
-The first time you invoke Info you start off looking at this node.
-
-File: dir, Node: Top This is the top of the INFO tree
-
- This (the Directory node) gives a menu of major topics.
- Typing "q" exits, "?" lists all Info commands, "d" returns here,
- "h" gives a primer for first-timers,
- "mEmacs<Return>" visits the Emacs manual, etc.
-
- In Emacs, you can click mouse button 2 on a menu item or cross reference
- to select it.
-
-* Menu:
-
-Individual utilities
-* addr2line: (binutils)addr2line. Convert addresses to file and
- line.
-* ar: (binutils)ar. Create, modify, and extract
- from archives.
-* c++filt: (binutils)c++filt. Filter to demangle encoded C++
- symbols.
-* cxxfilt: (binutils)c++filt. MS-DOS name for c++filt.
-* dlltool: (binutils)dlltool. Create files needed to build
- and use DLLs.
-* elfedit: (binutils)elfedit. Update the ELF header of ELF
- files.
-* nlmconv: (binutils)nlmconv. Converts object code into an
- NLM.
-* nm: (binutils)nm. List symbols from object files.
-* objcopy: (binutils)objcopy. Copy and translate object
- files.
-* objdump: (binutils)objdump. Display information from
- object files.
-* ranlib: (binutils)ranlib. Generate index to archive
- contents.
-* readelf: (binutils)readelf. Display the contents of ELF
- format files.
-* size: (binutils)size. List section sizes and total
- size.
-* strings: (binutils)strings. List printable strings from
- files.
-* strip: (binutils)strip. Discard symbols.
-* windmc: (binutils)windmc. Generator for Windows message
- resources.
-* windres: (binutils)windres. Manipulate Windows resources.
-
-Software development
-* Annotate: (annotate). The obsolete annotation interface.
-* As: (as). The GNU assembler.
-* Bfd: (bfd). The Binary File Descriptor library.
-* Binutils: (binutils). The GNU binary utilities.
-* Cpp: (cpp). The GNU C preprocessor.
-* Cpplib: (cppinternals). Cpplib internals.
-* Gas: (as). The GNU assembler.
-* Gdb: (gdb). The GNU debugger.
-* Gdb-Internals: (gdbint). The GNU debugger's internals.
-* Ld: (ld). The GNU linker.
-* Stabs: (stabs). The "stabs" debugging information format.
-* g++: (gcc). The GNU C++ compiler.
-* gcc: (gcc). The GNU Compiler Collection.
-* gccinstall: (gccinstall). Installing the GNU Compiler Collection.
-* gccint: (gccint). Internals of the GNU Compiler Collection.
-* gprof: (gprof). Profiling your program's execution
diff --git a/share/info/gcc.info b/share/info/gcc.info
deleted file mode 100644
index 62b4a73..0000000
--- a/share/info/gcc.info
+++ /dev/null
@@ -1,49096 +0,0 @@
-This is doc/gcc.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gcc/gcc-4.6/gcc/doc/gcc.texi.
-
-Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with the
-Invariant Sections being "Funding Free Software", the Front-Cover Texts
-being (a) (see below), and with the Back-Cover Texts being (b) (see
-below). A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
- (a) The FSF's Front-Cover Text is:
-
- A GNU Manual
-
- (b) The FSF's Back-Cover Text is:
-
- You have freedom to copy and modify this GNU Manual, like GNU
-software. Copies published by the Free Software Foundation raise
-funds for GNU development.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* gcc: (gcc). The GNU Compiler Collection.
-* g++: (gcc). The GNU C++ compiler.
-END-INFO-DIR-ENTRY
- This file documents the use of the GNU compilers.
-
- Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with the
-Invariant Sections being "Funding Free Software", the Front-Cover Texts
-being (a) (see below), and with the Back-Cover Texts being (b) (see
-below). A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
- (a) The FSF's Front-Cover Text is:
-
- A GNU Manual
-
- (b) The FSF's Back-Cover Text is:
-
- You have freedom to copy and modify this GNU Manual, like GNU
-software. Copies published by the Free Software Foundation raise
-funds for GNU development.
-
-
-
-File: gcc.info, Node: Top, Next: G++ and GCC, Up: (DIR)
-
-Introduction
-************
-
-This manual documents how to use the GNU compilers, as well as their
-features and incompatibilities, and how to report bugs. It corresponds
-to the compilers (GCC) version 4.6.x-google. The internals of the GNU
-compilers, including how to port them to new targets and some
-information about how to write front ends for new languages, are
-documented in a separate manual. *Note Introduction: (gccint)Top.
-
-* Menu:
-
-* G++ and GCC:: You can compile C or C++ programs.
-* Standards:: Language standards supported by GCC.
-* Invoking GCC:: Command options supported by `gcc'.
-* C Implementation:: How GCC implements the ISO C specification.
-* C Extensions:: GNU extensions to the C language family.
-* C++ Implementation:: How GCC implements the ISO C++ specification.
-* C++ Extensions:: GNU extensions to the C++ language.
-* Objective-C:: GNU Objective-C runtime features.
-* Compatibility:: Binary Compatibility
-* Gcov:: `gcov'---a test coverage program.
-* Trouble:: If you have trouble using GCC.
-* Bugs:: How, why and where to report bugs.
-* Service:: How to find suppliers of support for GCC.
-* Contributing:: How to contribute to testing and developing GCC.
-
-* Funding:: How to help assure funding for free software.
-* GNU Project:: The GNU Project and GNU/Linux.
-
-* Copying:: GNU General Public License says
- how you can copy and share GCC.
-* GNU Free Documentation License:: How you can copy and share this manual.
-* Contributors:: People who have contributed to GCC.
-
-* Option Index:: Index to command line options.
-* Keyword Index:: Index of concepts and symbol names.
-
-
-File: gcc.info, Node: G++ and GCC, Next: Standards, Prev: Top, Up: Top
-
-1 Programming Languages Supported by GCC
-****************************************
-
-GCC stands for "GNU Compiler Collection". GCC is an integrated
-distribution of compilers for several major programming languages.
-These languages currently include C, C++, Objective-C, Objective-C++,
-Java, Fortran, Ada, and Go.
-
- The abbreviation "GCC" has multiple meanings in common use. The
-current official meaning is "GNU Compiler Collection", which refers
-generically to the complete suite of tools. The name historically stood
-for "GNU C Compiler", and this usage is still common when the emphasis
-is on compiling C programs. Finally, the name is also used when
-speaking of the "language-independent" component of GCC: code shared
-among the compilers for all supported languages.
-
- The language-independent component of GCC includes the majority of the
-optimizers, as well as the "back ends" that generate machine code for
-various processors.
-
- The part of a compiler that is specific to a particular language is
-called the "front end". In addition to the front ends that are
-integrated components of GCC, there are several other front ends that
-are maintained separately. These support languages such as Pascal,
-Mercury, and COBOL. To use these, they must be built together with GCC
-proper.
-
- Most of the compilers for languages other than C have their own names.
-The C++ compiler is G++, the Ada compiler is GNAT, and so on. When we
-talk about compiling one of those languages, we might refer to that
-compiler by its own name, or as GCC. Either is correct.
-
- Historically, compilers for many languages, including C++ and Fortran,
-have been implemented as "preprocessors" which emit another high level
-language such as C. None of the compilers included in GCC are
-implemented this way; they all generate machine code directly. This
-sort of preprocessor should not be confused with the "C preprocessor",
-which is an integral feature of the C, C++, Objective-C and
-Objective-C++ languages.
-
-
-File: gcc.info, Node: Standards, Next: Invoking GCC, Prev: G++ and GCC, Up: Top
-
-2 Language Standards Supported by GCC
-*************************************
-
-For each language compiled by GCC for which there is a standard, GCC
-attempts to follow one or more versions of that standard, possibly with
-some exceptions, and possibly with some extensions.
-
-2.1 C language
-==============
-
-GCC supports three versions of the C standard, although support for the
-most recent version is not yet complete.
-
- The original ANSI C standard (X3.159-1989) was ratified in 1989 and
-published in 1990. This standard was ratified as an ISO standard
-(ISO/IEC 9899:1990) later in 1990. There were no technical differences
-between these publications, although the sections of the ANSI standard
-were renumbered and became clauses in the ISO standard. This standard,
-in both its forms, is commonly known as "C89", or occasionally as
-"C90", from the dates of ratification. The ANSI standard, but not the
-ISO standard, also came with a Rationale document. To select this
-standard in GCC, use one of the options `-ansi', `-std=c90' or
-`-std=iso9899:1990'; to obtain all the diagnostics required by the
-standard, you should also specify `-pedantic' (or `-pedantic-errors' if
-you want them to be errors rather than warnings). *Note Options
-Controlling C Dialect: C Dialect Options.
-
- Errors in the 1990 ISO C standard were corrected in two Technical
-Corrigenda published in 1994 and 1996. GCC does not support the
-uncorrected version.
-
- An amendment to the 1990 standard was published in 1995. This
-amendment added digraphs and `__STDC_VERSION__' to the language, but
-otherwise concerned the library. This amendment is commonly known as
-"AMD1"; the amended standard is sometimes known as "C94" or "C95". To
-select this standard in GCC, use the option `-std=iso9899:199409'
-(with, as for other standard versions, `-pedantic' to receive all
-required diagnostics).
-
- A new edition of the ISO C standard was published in 1999 as ISO/IEC
-9899:1999, and is commonly known as "C99". GCC has incomplete support
-for this standard version; see
-`http://gcc.gnu.org/gcc-4.6/c99status.html' for details. To select this
-standard, use `-std=c99' or `-std=iso9899:1999'. (While in
-development, drafts of this standard version were referred to as "C9X".)
-
- Errors in the 1999 ISO C standard were corrected in three Technical
-Corrigenda published in 2001, 2004 and 2007. GCC does not support the
-uncorrected version.
-
- A fourth version of the C standard, known as "C1X", is under
-development; GCC has limited preliminary support for parts of this
-standard, enabled with `-std=c1x'.
-
- By default, GCC provides some extensions to the C language that on
-rare occasions conflict with the C standard. *Note Extensions to the C
-Language Family: C Extensions. Use of the `-std' options listed above
-will disable these extensions where they conflict with the C standard
-version selected. You may also select an extended version of the C
-language explicitly with `-std=gnu90' (for C90 with GNU extensions),
-`-std=gnu99' (for C99 with GNU extensions) or `-std=gnu1x' (for C1X
-with GNU extensions). The default, if no C language dialect options
-are given, is `-std=gnu90'; this will change to `-std=gnu99' in some
-future release when the C99 support is complete. Some features that
-are part of the C99 standard are accepted as extensions in C90 mode.
-
- The ISO C standard defines (in clause 4) two classes of conforming
-implementation. A "conforming hosted implementation" supports the
-whole standard including all the library facilities; a "conforming
-freestanding implementation" is only required to provide certain
-library facilities: those in `<float.h>', `<limits.h>', `<stdarg.h>',
-and `<stddef.h>'; since AMD1, also those in `<iso646.h>'; and in C99,
-also those in `<stdbool.h>' and `<stdint.h>'. In addition, complex
-types, added in C99, are not required for freestanding implementations.
-The standard also defines two environments for programs, a
-"freestanding environment", required of all implementations and which
-may not have library facilities beyond those required of freestanding
-implementations, where the handling of program startup and termination
-are implementation-defined, and a "hosted environment", which is not
-required, in which all the library facilities are provided and startup
-is through a function `int main (void)' or `int main (int, char *[])'.
-An OS kernel would be a freestanding environment; a program using the
-facilities of an operating system would normally be in a hosted
-implementation.
-
- GCC aims towards being usable as a conforming freestanding
-implementation, or as the compiler for a conforming hosted
-implementation. By default, it will act as the compiler for a hosted
-implementation, defining `__STDC_HOSTED__' as `1' and presuming that
-when the names of ISO C functions are used, they have the semantics
-defined in the standard. To make it act as a conforming freestanding
-implementation for a freestanding environment, use the option
-`-ffreestanding'; it will then define `__STDC_HOSTED__' to `0' and not
-make assumptions about the meanings of function names from the standard
-library, with exceptions noted below. To build an OS kernel, you may
-well still need to make your own arrangements for linking and startup.
-*Note Options Controlling C Dialect: C Dialect Options.
-
- GCC does not provide the library facilities required only of hosted
-implementations, nor yet all the facilities required by C99 of
-freestanding implementations; to use the facilities of a hosted
-environment, you will need to find them elsewhere (for example, in the
-GNU C library). *Note Standard Libraries: Standard Libraries.
-
- Most of the compiler support routines used by GCC are present in
-`libgcc', but there are a few exceptions. GCC requires the
-freestanding environment provide `memcpy', `memmove', `memset' and
-`memcmp'. Finally, if `__builtin_trap' is used, and the target does
-not implement the `trap' pattern, then GCC will emit a call to `abort'.
-
- For references to Technical Corrigenda, Rationale documents and
-information concerning the history of C that is available online, see
-`http://gcc.gnu.org/readings.html'
-
-2.2 C++ language
-================
-
-GCC supports the ISO C++ standard (1998) and contains experimental
-support for the upcoming ISO C++ standard (200x).
-
- The original ISO C++ standard was published as the ISO standard
-(ISO/IEC 14882:1998) and amended by a Technical Corrigenda published in
-2003 (ISO/IEC 14882:2003). These standards are referred to as C++98 and
-C++03, respectively. GCC implements the majority of C++98 (`export' is
-a notable exception) and most of the changes in C++03. To select this
-standard in GCC, use one of the options `-ansi' or `-std=c++98'; to
-obtain all the diagnostics required by the standard, you should also
-specify `-pedantic' (or `-pedantic-errors' if you want them to be
-errors rather than warnings).
-
- The ISO C++ committee is working on a new ISO C++ standard, dubbed
-C++0x, that is intended to be published by 2009. C++0x contains several
-changes to the C++ language, some of which have been implemented in an
-experimental C++0x mode in GCC. The C++0x mode in GCC tracks the draft
-working paper for the C++0x standard; the latest working paper is
-available on the ISO C++ committee's web site at
-`http://www.open-std.org/jtc1/sc22/wg21/'. For information regarding
-the C++0x features available in the experimental C++0x mode, see
-`http://gcc.gnu.org/projects/cxx0x.html'. To select this standard in
-GCC, use the option `-std=c++0x'; to obtain all the diagnostics
-required by the standard, you should also specify `-pedantic' (or
-`-pedantic-errors' if you want them to be errors rather than warnings).
-
- By default, GCC provides some extensions to the C++ language; *Note
-Options Controlling C++ Dialect: C++ Dialect Options. Use of the
-`-std' option listed above will disable these extensions. You may also
-select an extended version of the C++ language explicitly with
-`-std=gnu++98' (for C++98 with GNU extensions) or `-std=gnu++0x' (for
-C++0x with GNU extensions). The default, if no C++ language dialect
-options are given, is `-std=gnu++98'.
-
-2.3 Objective-C and Objective-C++ languages
-===========================================
-
-GCC supports "traditional" Objective-C (also known as "Objective-C
-1.0") and contains support for the Objective-C exception and
-synchronization syntax. It has also support for a number of
-"Objective-C 2.0" language extensions, including properties, fast
-enumeration (only for Objective-C), method attributes and the @optional
-and @required keywords in protocols. GCC supports Objective-C++ and
-features available in Objective-C are also available in Objective-C++.
-
- GCC by default uses the GNU Objective-C runtime library, which is part
-of GCC and is not the same as the Apple/NeXT Objective-C runtime
-library used on Apple systems. There are a number of differences
-documented in this manual. The options `-fgnu-runtime' and
-`-fnext-runtime' allow you to switch between producing output that
-works with the GNU Objective-C runtime library and output that works
-with the Apple/NeXT Objective-C runtime library.
-
- There is no formal written standard for Objective-C or Objective-C++.
-The authoritative manual on traditional Objective-C (1.0) is
-"Object-Oriented Programming and the Objective-C Language", available
-at a number of web sites:
- * `http://www.gnustep.org/resources/documentation/ObjectivCBook.pdf'
- is the original NeXTstep document;
-
- * `http://objc.toodarkpark.net' is the same document in another
- format;
-
- *
- `http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/'
- has an updated version but make sure you search for "Object
- Oriented Programming and the Objective-C Programming Language 1.0",
- not documentation on the newer "Objective-C 2.0" language
-
- The Objective-C exception and synchronization syntax (that is, the
-keywords @try, @throw, @catch, @finally and @synchronized) is supported
-by GCC and is enabled with the option `-fobjc-exceptions'. The syntax
-is briefly documented in this manual and in the Objective-C 2.0 manuals
-from Apple.
-
- The Objective-C 2.0 language extensions and features are automatically
-enabled; they include properties (via the @property, @synthesize and
-@dynamic keywords), fast enumeration (not available in Objective-C++),
-attributes for methods (such as deprecated, noreturn, sentinel,
-format), the unused attribute for method arguments, the @package
-keyword for instance variables and the @optional and @required keywords
-in protocols. You can disable all these Objective-C 2.0 language
-extensions with the option `-fobjc-std=objc1', which causes the
-compiler to recognize the same Objective-C language syntax recognized
-by GCC 4.0, and to produce an error if one of the new features is used.
-
- GCC has currently no support for non-fragile instance variables.
-
- The authoritative manual on Objective-C 2.0 is available from Apple:
- *
- `http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/'
-
- For more information concerning the history of Objective-C that is
-available online, see `http://gcc.gnu.org/readings.html'
-
-2.4 Go language
-===============
-
-The Go language continues to evolve as of this writing; see the current
-language specifications (http://golang.org/doc/go_spec.html). At
-present there are no specific versions of Go, and there is no way to
-describe the language supported by GCC in terms of a specific version.
-In general GCC tracks the evolving specification closely, and any given
-release will support the language as of the date that the release was
-frozen.
-
-2.5 References for other languages
-==================================
-
-*Note GNAT Reference Manual: (gnat_rm)Top, for information on standard
-conformance and compatibility of the Ada compiler.
-
- *Note Standards: (gfortran)Standards, for details of standards
-supported by GNU Fortran.
-
- *Note Compatibility with the Java Platform: (gcj)Compatibility, for
-details of compatibility between `gcj' and the Java Platform.
-
-
-File: gcc.info, Node: Invoking GCC, Next: C Implementation, Prev: Standards, Up: Top
-
-3 GCC Command Options
-*********************
-
-When you invoke GCC, it normally does preprocessing, compilation,
-assembly and linking. The "overall options" allow you to stop this
-process at an intermediate stage. For example, the `-c' option says
-not to run the linker. Then the output consists of object files output
-by the assembler.
-
- Other options are passed on to one stage of processing. Some options
-control the preprocessor and others the compiler itself. Yet other
-options control the assembler and linker; most of these are not
-documented here, since you rarely need to use any of them.
-
- Most of the command line options that you can use with GCC are useful
-for C programs; when an option is only useful with another language
-(usually C++), the explanation says so explicitly. If the description
-for a particular option does not mention a source language, you can use
-that option with all supported languages.
-
- *Note Compiling C++ Programs: Invoking G++, for a summary of special
-options for compiling C++ programs.
-
- The `gcc' program accepts options and file names as operands. Many
-options have multi-letter names; therefore multiple single-letter
-options may _not_ be grouped: `-dv' is very different from `-d -v'.
-
- You can mix options and other arguments. For the most part, the order
-you use doesn't matter. Order does matter when you use several options
-of the same kind; for example, if you specify `-L' more than once, the
-directories are searched in the order specified. Also, the placement
-of the `-l' option is significant.
-
- Many options have long names starting with `-f' or with `-W'--for
-example, `-fmove-loop-invariants', `-Wformat' and so on. Most of these
-have both positive and negative forms; the negative form of `-ffoo'
-would be `-fno-foo'. This manual documents only one of these two
-forms, whichever one is not the default.
-
- *Note Option Index::, for an index to GCC's options.
-
-* Menu:
-
-* Option Summary:: Brief list of all options, without explanations.
-* Overall Options:: Controlling the kind of output:
- an executable, object files, assembler files,
- or preprocessed source.
-* Invoking G++:: Compiling C++ programs.
-* C Dialect Options:: Controlling the variant of C language compiled.
-* C++ Dialect Options:: Variations on C++.
-* Objective-C and Objective-C++ Dialect Options:: Variations on Objective-C
- and Objective-C++.
-* Language Independent Options:: Controlling how diagnostics should be
- formatted.
-* Warning Options:: How picky should the compiler be?
-* Debugging Options:: Symbol tables, measurements, and debugging dumps.
-* Optimize Options:: How much optimization?
-* Preprocessor Options:: Controlling header files and macro definitions.
- Also, getting dependency information for Make.
-* Assembler Options:: Passing options to the assembler.
-* Link Options:: Specifying libraries and so on.
-* Directory Options:: Where to find header files and libraries.
- Where to find the compiler executable files.
-* Spec Files:: How to pass switches to sub-processes.
-* Target Options:: Running a cross-compiler, or an old version of GCC.
-* Submodel Options:: Specifying minor hardware or convention variations,
- such as 68010 vs 68020.
-* Code Gen Options:: Specifying conventions for function calls, data layout
- and register usage.
-* Environment Variables:: Env vars that affect GCC.
-* Precompiled Headers:: Compiling a header once, and using it many times.
-
-
-File: gcc.info, Node: Option Summary, Next: Overall Options, Up: Invoking GCC
-
-3.1 Option Summary
-==================
-
-Here is a summary of all the options, grouped by type. Explanations are
-in the following sections.
-
-_Overall Options_
- *Note Options Controlling the Kind of Output: Overall Options.
- -c -S -E -o FILE -no-canonical-prefixes
- -pipe -pass-exit-codes
- -x LANGUAGE -v -### --help[=CLASS[,...]] --target-help
- --version -wrapper @FILE -fplugin=FILE -fplugin-arg-NAME=ARG
- -fdump-ada-spec[-slim]
- -fdump-go-spec=FILE
-
-_C Language Options_
- *Note Options Controlling C Dialect: C Dialect Options.
- -ansi -std=STANDARD -fgnu89-inline
- -aux-info FILENAME
- -fno-asm -fno-builtin -fno-builtin-FUNCTION
- -fhosted -ffreestanding -fopenmp -fms-extensions -fplan9-extensions
- -trigraphs -no-integrated-cpp -traditional -traditional-cpp
- -fallow-single-precision -fcond-mismatch -flax-vector-conversions
- -fsigned-bitfields -fsigned-char
- -funsigned-bitfields -funsigned-char
-
-_C++ Language Options_
- *Note Options Controlling C++ Dialect: C++ Dialect Options.
- -fabi-version=N -fno-access-control -fcheck-new
- -fconserve-space -fconstexpr-depth=N -ffriend-injection
- -fno-elide-constructors
- -fno-enforce-eh-specs
- -ffor-scope -fno-for-scope -fno-gnu-keywords
- -fno-implicit-templates
- -fno-implicit-inline-templates
- -fno-implement-inlines -fms-extensions
- -fno-nonansi-builtins -fnothrow-opt -fno-operator-names
- -fno-optional-diags -fpermissive
- -fno-pretty-templates
- -frepo -fno-rtti -fstats -ftemplate-depth=N
- -fno-threadsafe-statics -fuse-cxa-atexit -fno-weak -nostdinc++
- -fno-default-inline -fvisibility-inlines-hidden
- -fvisibility-ms-compat
- -Wabi -Wconversion-null -Wctor-dtor-privacy
- -Wnoexcept -Wnon-virtual-dtor -Wreorder
- -Weffc++ -Wstrict-null-sentinel
- -Wno-non-template-friend -Wold-style-cast
- -Woverloaded-virtual -Wno-pmf-conversions
- -Wsign-promo
-
-_Objective-C and Objective-C++ Language Options_
- *Note Options Controlling Objective-C and Objective-C++ Dialects:
- Objective-C and Objective-C++ Dialect Options.
- -fconstant-string-class=CLASS-NAME
- -fgnu-runtime -fnext-runtime
- -fno-nil-receivers
- -fobjc-abi-version=N
- -fobjc-call-cxx-cdtors
- -fobjc-direct-dispatch
- -fobjc-exceptions
- -fobjc-gc
- -fobjc-nilcheck
- -fobjc-std=objc1
- -freplace-objc-classes
- -fzero-link
- -gen-decls
- -Wassign-intercept
- -Wno-protocol -Wselector
- -Wstrict-selector-match
- -Wundeclared-selector
-
-_Language Independent Options_
- *Note Options to Control Diagnostic Messages Formatting: Language
- Independent Options.
- -fmessage-length=N
- -fdiagnostics-show-location=[once|every-line]
- -fno-diagnostics-show-option
-
-_Warning Options_
- *Note Options to Request or Suppress Warnings: Warning Options.
- -fsyntax-only -fmax-errors=N -pedantic
- -pedantic-errors
- -w -Wextra -Wall -Waddress -Waggregate-return -Warray-bounds
- -Wno-attributes -Wno-builtin-macro-redefined
- -Wc++-compat -Wc++0x-compat -Wcast-align -Wcast-qual
- -Wchar-subscripts -Wclobbered -Wcomment
- -Wconversion -Wcoverage-mismatch -Wno-cpp -Wno-deprecated
- -Wno-deprecated-declarations -Wdisabled-optimization
- -Wno-div-by-zero -Wdouble-promotion -Wempty-body -Wenum-compare
- -Wno-endif-labels -Werror -Werror=*
- -Wfatal-errors -Wfloat-equal -Wformat -Wformat=2
- -Wno-format-contains-nul -Wno-format-extra-args -Wformat-nonliteral
- -Wformat-security -Wformat-y2k
- -Wframe-larger-than=LEN -Wjump-misses-init -Wignored-qualifiers
- -Wimplicit -Wimplicit-function-declaration -Wimplicit-int
- -Winit-self -Winline -Wmaybe-uninitialized
- -Wno-int-to-pointer-cast -Wno-invalid-offsetof
- -Winvalid-pch -Wlarger-than=LEN -Wunsafe-loop-optimizations
- -Wlogical-op -Wlong-long
- -Wmain -Wmaybe-uninitialized -Wmissing-braces -Wmissing-field-initializers
- -Wmissing-format-attribute -Wmissing-include-dirs
- -Wno-mudflap
- -Wno-multichar -Wnonnull -Wno-overflow
- -Woverlength-strings -Wpacked -Wpacked-bitfield-compat -Wpadded
- -Wparentheses -Wpedantic-ms-format -Wno-pedantic-ms-format
- -Wpointer-arith -Wno-pointer-to-int-cast
- -Wreal-conversion -Wredundant-decls -Wreturn-type -Wripa-opt-mismatch
- -Wself-assign -Wself-assign-non-pod -Wsequence-point -Wshadow
- -Wshadow-compatible-local -Wshadow-local
- -Wsign-compare -Wsign-conversion -Wstack-protector
- -Wstrict-aliasing -Wstrict-aliasing=n
- -Wstrict-overflow -Wstrict-overflow=N
- -Wsuggest-attribute=[pure|const|noreturn]
- -Wswitch -Wswitch-default -Wswitch-enum -Wsync-nand
- -Wsystem-headers -Wthread-safety -Wthread-unguarded-var
- -Wthread-unguarded-func -Wthread-mismatched-lock-order
- -Wthread-mismatched-lock-acq-rel -Wthread-reentrant-lock
- -Wthread-unsupported-lock-name -Wthread-attr-bind-param
- -Wtrampolines -Wtrigraphs -Wtype-limits -Wundef
- -Wuninitialized -Wunknown-pragmas -Wno-pragmas
- -Wunsuffixed-float-constants -Wunused -Wunused-function
- -Wunused-label -Wunused-parameter -Wno-unused-result -Wunused-value
- -Wunused-variable -Wunused-but-set-parameter -Wunused-but-set-variable
- -Wvariadic-macros -Wvla -Wvolatile-register-var -Wwrite-strings
-
-_C and Objective-C-only Warning Options_
- -Wbad-function-cast -Wmissing-declarations
- -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs
- -Wold-style-declaration -Wold-style-definition
- -Wstrict-prototypes -Wtraditional -Wtraditional-conversion
- -Wdeclaration-after-statement -Wpointer-sign
-
-_Debugging Options_
- *Note Options for Debugging Your Program or GCC: Debugging Options.
- -dLETTERS -dumpspecs -dumpmachine -dumpversion
- -fdbg-cnt-list -fdbg-cnt=COUNTER-VALUE-LIST
- -fdisable-ipa-PASS_NAME
- -fdisable-rtl-PASS_NAME
- -fdisable-rtl-PASS-NAME=RANGE-LIST
- -fdisable-tree-PASS_NAME
- -fdisable-tree-PASS-NAME=RANGE-LIST
- -fdump-noaddr -fdump-unnumbered -fdump-unnumbered-links
- -fdump-translation-unit[-N]
- -fdump-class-hierarchy[-N]
- -fdump-ipa-all -fdump-ipa-cgraph -fdump-ipa-inline
- -fdump-passes
- -fdump-statistics
- -fdump-tree-all
- -fdump-tree-original[-N]
- -fdump-tree-optimized[-N]
- -fdump-tree-cfg -fdump-tree-vcg -fdump-tree-alias
- -fdump-tree-ch
- -fdump-tree-ssa[-N] -fdump-tree-pre[-N]
- -fdump-tree-ccp[-N] -fdump-tree-dce[-N]
- -fdump-tree-gimple[-raw] -fdump-tree-mudflap[-N]
- -fdump-tree-dom[-N]
- -fdump-tree-dse[-N]
- -fdump-tree-phiprop[-N]
- -fdump-tree-phiopt[-N]
- -fdump-tree-forwprop[-N]
- -fdump-tree-copyrename[-N]
- -fdump-tree-nrv -fdump-tree-vect
- -fdump-tree-sink
- -fdump-tree-sra[-N]
- -fdump-tree-forwprop[-N]
- -fdump-tree-fre[-N]
- -fdump-tree-vrp[-N]
- -ftree-vectorizer-verbose=N
- -fdump-tree-storeccp[-N]
- -fdump-final-insns=FILE
- -fcompare-debug[=OPTS] -fcompare-debug-second
- -feliminate-dwarf2-dups -feliminate-unused-debug-types
- -feliminate-unused-debug-symbols -femit-class-debug-always
- -fenable-icf-debug
- -fenable-KIND-PASS
- -fenable-KIND-PASS=RANGE-LIST
- -fdebug-types-section
- -fmem-report -fpre-ipa-mem-report -fpost-ipa-mem-report -fprofile-arcs
- -frandom-seed=STRING -fsched-verbose=N
- -fsel-sched-verbose -fsel-sched-dump-cfg -fsel-sched-pipelining-verbose
- -fstack-usage -ftest-coverage -ftime-report -fvar-tracking
- -fvar-tracking-assignments -fvar-tracking-assignments-toggle
- -g -gLEVEL -gtoggle -gcoff -gdwarf-VERSION
- -ggdb -gmlt -gstabs -gstabs+ -gstrict-dwarf -gno-strict-dwarf
- -gvms -gxcoff -gxcoff+
- -fno-merge-debug-strings -fno-dwarf2-cfi-asm
- -fdebug-prefix-map=OLD=NEW
- -femit-struct-debug-baseonly -femit-struct-debug-reduced
- -femit-struct-debug-detailed[=SPEC-LIST]
- -p -pg -print-file-name=LIBRARY -print-libgcc-file-name
- -print-multi-directory -print-multi-lib -print-multi-os-directory
- -print-prog-name=PROGRAM -print-search-dirs -Q
- -print-sysroot -print-sysroot-headers-suffix
- -save-temps -save-temps=cwd -save-temps=obj -time[=FILE]
-
-_Optimization Options_
- *Note Options that Control Optimization: Optimize Options.
- -falign-functions[=N] -falign-jumps[=N]
- -falign-labels[=N] -falign-loops[=N] -fassociative-math
- -fauto-inc-dec -fbranch-probabilities -fbranch-target-load-optimize
- -fbranch-target-load-optimize2 -fbtr-bb-exclusive -fcaller-saves
- -fcallgraph-profiles-sections -fcheck-data-deps -fclone-hot-version-paths
- -fcombine-stack-adjustments -fconserve-stack
- -fcompare-elim -fcprop-registers -fcrossjumping
- -fcse-follow-jumps -fcse-skip-blocks -fcx-fortran-rules
- -fcx-limited-range
- -fdata-sections -fdce -fdce -fdelayed-branch
- -fdelete-null-pointer-checks -fdse -fdevirtualize -fdse
- -fearly-inlining -fipa-sra -fexpensive-optimizations -ffast-math
- -ffinite-math-only -ffloat-store -fexcess-precision=STYLE
- -fforward-propagate -ffp-contract=STYLE -ffunction-sections
- -fgcse -fgcse-after-reload -fgcse-las -fgcse-lm -fgraphite-identity
- -fgcse-sm -fif-conversion -fif-conversion2 -findirect-inlining
- -finline-functions -finline-functions-called-once -finline-limit=N
- -finline-small-functions -fipa-cp -fipa-cp-clone -fipa-matrix-reorg
- -fipa-pta -fipa-profile -fipa-pure-const -fipa-reference
- -fipa-struct-reorg -fira-algorithm=ALGORITHM
- -fira-region=REGION
- -fira-loop-pressure -fno-ira-share-save-slots
- -fno-ira-share-spill-slots -fira-verbose=N
- -fivopts -fkeep-inline-functions -fkeep-static-consts
- -floop-block -floop-flatten -floop-interchange -floop-strip-mine
- -floop-parallelize-all -flto -flto-compression-level
- -flto-partition=ALG -flto-report -fmerge-all-constants
- -fmerge-constants -fmodulo-sched -fmodulo-sched-allow-regmoves
- -fmove-loop-invariants fmudflap -fmudflapir -fmudflapth -fno-branch-count-reg
- -fno-default-inline
- -fno-defer-pop -fno-function-cse -fno-guess-branch-probability
- -fno-inline -fno-math-errno -fno-peephole -fno-peephole2
- -fno-sched-interblock -fno-sched-spec -fno-signed-zeros
- -fno-toplevel-reorder -fno-trapping-math -fno-zero-initialized-in-bss
- -fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls
- -fpartial-inlining -fpeel-loops -fpredictive-commoning
- -fprefetch-loop-arrays
- -fprofile-correction -fprofile-dir=PATH -fprofile-generate
- -fprofile-generate=PATH -fprofile-generate-sampling
- -fprofile-use -fprofile-use=PATH -fprofile-values
- -fpmu-profile-generate=PMUOPTION
- -fpmu-profile-use=PMUOPTION
- -freciprocal-math -fregmove -frename-registers -freorder-blocks
- -frecord-gcc-switches-in-elf
- -freorder-blocks-and-partition -freorder-functions
- -frerun-cse-after-loop -freschedule-modulo-scheduled-loops
- -fripa -fripa-disallow-asm-modules -fripa-disallow-opt-mismatch
- -fripa-no-promote-always-inline-func -fripa-verbose
- -fripa-peel-size-limit -fripa-unroll-size-limit -frounding-math
- -fsched2-use-superblocks -fsched-pressure
- -fsched-spec-load -fsched-spec-load-dangerous
- -fsched-stalled-insns-dep[=N] -fsched-stalled-insns[=N]
- -fsched-group-heuristic -fsched-critical-path-heuristic
- -fsched-spec-insn-heuristic -fsched-rank-heuristic
- -fsched-last-insn-heuristic -fsched-dep-count-heuristic
- -fschedule-insns -fschedule-insns2 -fsection-anchors
- -fselective-scheduling -fselective-scheduling2
- -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
- -fsignaling-nans -fsingle-precision-constant -fsplit-ivs-in-unroller
- -fsplit-wide-types -fstack-protector -fstack-protector-all
- -fstack-protector-strong -fstrict-aliasing -fstrict-overflow
- -fthread-jumps -ftracer -ftree-bit-ccp
- -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copy-prop
- -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse
- -ftree-forwprop -ftree-fre -ftree-loop-if-convert
- -ftree-loop-if-convert-stores -ftree-loop-im
- -ftree-phiprop -ftree-loop-distribution -ftree-loop-distribute-patterns
- -ftree-loop-ivcanon -ftree-loop-linear -ftree-loop-optimize
- -ftree-parallelize-loops=N -ftree-pre -ftree-pta -ftree-reassoc
- -ftree-sink -ftree-sra -ftree-switch-conversion
- -ftree-ter -ftree-vect-loop-version -ftree-vectorize -ftree-vrp
- -funit-at-a-time -funroll-all-loops -funroll-loops
- -funsafe-loop-optimizations -funsafe-math-optimizations -funswitch-loops
- -fvariable-expansion-in-unroller -fvect-cost-model -fvpt -fweb
- -fwhole-program -fwpa -fuse-ld -fuse-linker-plugin
- --param NAME=VALUE
- -O -O0 -O1 -O2 -O3 -Os -Ofast
-
-_Preprocessor Options_
- *Note Options Controlling the Preprocessor: Preprocessor Options.
- -AQUESTION=ANSWER
- -A-QUESTION[=ANSWER]
- -C -dD -dI -dM -dN
- -DMACRO[=DEFN] -E -H
- -idirafter DIR
- -include FILE -imacros FILE
- -iprefix FILE -iwithprefix DIR
- -iwithprefixbefore DIR -isystem DIR
- -imultilib DIR -isysroot DIR
- -M -MM -MF -MG -MP -MQ -MT -nostdinc
- -P -fworking-directory -remap
- -trigraphs -undef -UMACRO -Wp,OPTION
- -Xpreprocessor OPTION
-
-_Assembler Option_
- *Note Passing Options to the Assembler: Assembler Options.
- -Wa,OPTION -Xassembler OPTION
-
-_Linker Options_
- *Note Options for Linking: Link Options.
- OBJECT-FILE-NAME -lLIBRARY
- -nostartfiles -nodefaultlibs -nostdlib -pie -rdynamic
- -s -static -static-libgcc -static-libstdc++ -shared
- -shared-libgcc -symbolic
- -T SCRIPT -Wl,OPTION -Xlinker OPTION
- -u SYMBOL
-
-_Directory Options_
- *Note Options for Directory Search: Directory Options.
- -BPREFIX -IDIR -iplugindir=DIR
-
- -iquoteDIR -LDIR -specs=FILE -I- -sysroot=DIR
-
-_Machine Dependent Options_
- *Note Hardware Models and Configurations: Submodel Options.
-
- _ARC Options_
- -EB -EL
- -mmangle-cpu -mcpu=CPU -mtext=TEXT-SECTION
- -mdata=DATA-SECTION -mrodata=READONLY-DATA-SECTION
-
- _ARM Options_
- -mapcs-frame -mno-apcs-frame
- -mabi=NAME
- -mapcs-stack-check -mno-apcs-stack-check
- -mapcs-float -mno-apcs-float
- -mapcs-reentrant -mno-apcs-reentrant
- -msched-prolog -mno-sched-prolog
- -mlittle-endian -mbig-endian -mwords-little-endian
- -mfloat-abi=NAME -msoft-float -mhard-float -mfpe
- -mfp16-format=NAME
- -mthumb-interwork -mno-thumb-interwork
- -mcpu=NAME -march=NAME -mfpu=NAME
- -mstructure-size-boundary=N
- -mabort-on-noreturn
- -mlong-calls -mno-long-calls
- -msingle-pic-base -mno-single-pic-base
- -mpic-register=REG
- -mnop-fun-dllimport
- -mcirrus-fix-invalid-insns -mno-cirrus-fix-invalid-insns
- -mpoke-function-name
- -mthumb -marm
- -mtpcs-frame -mtpcs-leaf-frame
- -mcaller-super-interworking -mcallee-super-interworking
- -mtp=NAME
- -mword-relocations
- -mfix-cortex-m3-ldrd
-
- _AVR Options_
- -mmcu=MCU -mno-interrupts
- -mcall-prologues -mtiny-stack -mint8
-
- _Blackfin Options_
- -mcpu=CPU[-SIREVISION]
- -msim -momit-leaf-frame-pointer -mno-omit-leaf-frame-pointer
- -mspecld-anomaly -mno-specld-anomaly -mcsync-anomaly -mno-csync-anomaly
- -mlow-64k -mno-low64k -mstack-check-l1 -mid-shared-library
- -mno-id-shared-library -mshared-library-id=N
- -mleaf-id-shared-library -mno-leaf-id-shared-library
- -msep-data -mno-sep-data -mlong-calls -mno-long-calls
- -mfast-fp -minline-plt -mmulticore -mcorea -mcoreb -msdram
- -micplb
-
- _CRIS Options_
- -mcpu=CPU -march=CPU -mtune=CPU
- -mmax-stack-frame=N -melinux-stacksize=N
- -metrax4 -metrax100 -mpdebug -mcc-init -mno-side-effects
- -mstack-align -mdata-align -mconst-align
- -m32-bit -m16-bit -m8-bit -mno-prologue-epilogue -mno-gotplt
- -melf -maout -melinux -mlinux -sim -sim2
- -mmul-bug-workaround -mno-mul-bug-workaround
-
- _CRX Options_
- -mmac -mpush-args
-
- _Darwin Options_
- -all_load -allowable_client -arch -arch_errors_fatal
- -arch_only -bind_at_load -bundle -bundle_loader
- -client_name -compatibility_version -current_version
- -dead_strip
- -dependency-file -dylib_file -dylinker_install_name
- -dynamic -dynamiclib -exported_symbols_list
- -filelist -flat_namespace -force_cpusubtype_ALL
- -force_flat_namespace -headerpad_max_install_names
- -iframework
- -image_base -init -install_name -keep_private_externs
- -multi_module -multiply_defined -multiply_defined_unused
- -noall_load -no_dead_strip_inits_and_terms
- -nofixprebinding -nomultidefs -noprebind -noseglinkedit
- -pagezero_size -prebind -prebind_all_twolevel_modules
- -private_bundle -read_only_relocs -sectalign
- -sectobjectsymbols -whyload -seg1addr
- -sectcreate -sectobjectsymbols -sectorder
- -segaddr -segs_read_only_addr -segs_read_write_addr
- -seg_addr_table -seg_addr_table_filename -seglinkedit
- -segprot -segs_read_only_addr -segs_read_write_addr
- -single_module -static -sub_library -sub_umbrella
- -twolevel_namespace -umbrella -undefined
- -unexported_symbols_list -weak_reference_mismatches
- -whatsloaded -F -gused -gfull -mmacosx-version-min=VERSION
- -mkernel -mone-byte-bool
-
- _DEC Alpha Options_
- -mno-fp-regs -msoft-float -malpha-as -mgas
- -mieee -mieee-with-inexact -mieee-conformant
- -mfp-trap-mode=MODE -mfp-rounding-mode=MODE
- -mtrap-precision=MODE -mbuild-constants
- -mcpu=CPU-TYPE -mtune=CPU-TYPE
- -mbwx -mmax -mfix -mcix
- -mfloat-vax -mfloat-ieee
- -mexplicit-relocs -msmall-data -mlarge-data
- -msmall-text -mlarge-text
- -mmemory-latency=TIME
-
- _DEC Alpha/VMS Options_
- -mvms-return-codes -mdebug-main=PREFIX -mmalloc64
-
- _FR30 Options_
- -msmall-model -mno-lsim
-
- _FRV Options_
- -mgpr-32 -mgpr-64 -mfpr-32 -mfpr-64
- -mhard-float -msoft-float
- -malloc-cc -mfixed-cc -mdword -mno-dword
- -mdouble -mno-double
- -mmedia -mno-media -mmuladd -mno-muladd
- -mfdpic -minline-plt -mgprel-ro -multilib-library-pic
- -mlinked-fp -mlong-calls -malign-labels
- -mlibrary-pic -macc-4 -macc-8
- -mpack -mno-pack -mno-eflags -mcond-move -mno-cond-move
- -moptimize-membar -mno-optimize-membar
- -mscc -mno-scc -mcond-exec -mno-cond-exec
- -mvliw-branch -mno-vliw-branch
- -mmulti-cond-exec -mno-multi-cond-exec -mnested-cond-exec
- -mno-nested-cond-exec -mtomcat-stats
- -mTLS -mtls
- -mcpu=CPU
-
- _GNU/Linux Options_
- -mglibc -muclibc -mbionic -mandroid
- -tno-android-cc -tno-android-ld
-
- _H8/300 Options_
- -mrelax -mh -ms -mn -mint32 -malign-300
-
- _HPPA Options_
- -march=ARCHITECTURE-TYPE
- -mbig-switch -mdisable-fpregs -mdisable-indexing
- -mfast-indirect-calls -mgas -mgnu-ld -mhp-ld
- -mfixed-range=REGISTER-RANGE
- -mjump-in-delay -mlinker-opt -mlong-calls
- -mlong-load-store -mno-big-switch -mno-disable-fpregs
- -mno-disable-indexing -mno-fast-indirect-calls -mno-gas
- -mno-jump-in-delay -mno-long-load-store
- -mno-portable-runtime -mno-soft-float
- -mno-space-regs -msoft-float -mpa-risc-1-0
- -mpa-risc-1-1 -mpa-risc-2-0 -mportable-runtime
- -mschedule=CPU-TYPE -mspace-regs -msio -mwsio
- -munix=UNIX-STD -nolibdld -static -threads
-
- _i386 and x86-64 Options_
- -mtune=CPU-TYPE -march=CPU-TYPE
- -mfpmath=UNIT
- -masm=DIALECT -mno-fancy-math-387
- -mno-fp-ret-in-387 -msoft-float
- -mno-wide-multiply -mrtd -malign-double
- -mpreferred-stack-boundary=NUM
- -mincoming-stack-boundary=NUM
- -mcld -mcx16 -msahf -mmovbe -mcrc32 -mrecip -mvzeroupper
- -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx
- -maes -mpclmul -mfsgsbase -mrdrnd -mf16c -mfused-madd
- -msse4a -m3dnow -mpopcnt -mabm -mbmi -mtbm -mfma4 -mxop -mlwp
- -mthreads -mno-align-stringops -minline-all-stringops
- -minline-stringops-dynamically -mstringop-strategy=ALG
- -mpush-args -maccumulate-outgoing-args -m128bit-long-double
- -m96bit-long-double -mregparm=NUM -msseregparm
- -mveclibabi=TYPE -mvect8-ret-in-mem
- -mpc32 -mpc64 -mpc80 -mstackrealign
- -momit-leaf-frame-pointer -mno-red-zone -mno-tls-direct-seg-refs
- -mcmodel=CODE-MODEL -mabi=NAME
- -m32 -m64 -mlarge-data-threshold=NUM
- -msse2avx -mfentry -m8bit-idiv
- -mavx256-split-unaligned-load -mavx256-split-unaligned-store
-
- _i386 and x86-64 Windows Options_
- -mconsole -mcygwin -mno-cygwin -mdll
- -mnop-fun-dllimport -mthread
- -municode -mwin32 -mwindows -fno-set-stack-executable
-
- _IA-64 Options_
- -mbig-endian -mlittle-endian -mgnu-as -mgnu-ld -mno-pic
- -mvolatile-asm-stop -mregister-names -msdata -mno-sdata
- -mconstant-gp -mauto-pic -mfused-madd
- -minline-float-divide-min-latency
- -minline-float-divide-max-throughput
- -mno-inline-float-divide
- -minline-int-divide-min-latency
- -minline-int-divide-max-throughput
- -mno-inline-int-divide
- -minline-sqrt-min-latency -minline-sqrt-max-throughput
- -mno-inline-sqrt
- -mdwarf2-asm -mearly-stop-bits
- -mfixed-range=REGISTER-RANGE -mtls-size=TLS-SIZE
- -mtune=CPU-TYPE -milp32 -mlp64
- -msched-br-data-spec -msched-ar-data-spec -msched-control-spec
- -msched-br-in-data-spec -msched-ar-in-data-spec -msched-in-control-spec
- -msched-spec-ldc -msched-spec-control-ldc
- -msched-prefer-non-data-spec-insns -msched-prefer-non-control-spec-insns
- -msched-stop-bits-after-every-cycle -msched-count-spec-in-critical-path
- -msel-sched-dont-check-control-spec -msched-fp-mem-deps-zero-cost
- -msched-max-memory-insns-hard-limit -msched-max-memory-insns=MAX-INSNS
-
- _IA-64/VMS Options_
- -mvms-return-codes -mdebug-main=PREFIX -mmalloc64
-
- _LM32 Options_
- -mbarrel-shift-enabled -mdivide-enabled -mmultiply-enabled
- -msign-extend-enabled -muser-enabled
-
- _M32R/D Options_
- -m32r2 -m32rx -m32r
- -mdebug
- -malign-loops -mno-align-loops
- -missue-rate=NUMBER
- -mbranch-cost=NUMBER
- -mmodel=CODE-SIZE-MODEL-TYPE
- -msdata=SDATA-TYPE
- -mno-flush-func -mflush-func=NAME
- -mno-flush-trap -mflush-trap=NUMBER
- -G NUM
-
- _M32C Options_
- -mcpu=CPU -msim -memregs=NUMBER
-
- _M680x0 Options_
- -march=ARCH -mcpu=CPU -mtune=TUNE
- -m68000 -m68020 -m68020-40 -m68020-60 -m68030 -m68040
- -m68060 -mcpu32 -m5200 -m5206e -m528x -m5307 -m5407
- -mcfv4e -mbitfield -mno-bitfield -mc68000 -mc68020
- -mnobitfield -mrtd -mno-rtd -mdiv -mno-div -mshort
- -mno-short -mhard-float -m68881 -msoft-float -mpcrel
- -malign-int -mstrict-align -msep-data -mno-sep-data
- -mshared-library-id=n -mid-shared-library -mno-id-shared-library
- -mxgot -mno-xgot
-
- _M68hc1x Options_
- -m6811 -m6812 -m68hc11 -m68hc12 -m68hcs12
- -mauto-incdec -minmax -mlong-calls -mshort
- -msoft-reg-count=COUNT
-
- _MCore Options_
- -mhardlit -mno-hardlit -mdiv -mno-div -mrelax-immediates
- -mno-relax-immediates -mwide-bitfields -mno-wide-bitfields
- -m4byte-functions -mno-4byte-functions -mcallgraph-data
- -mno-callgraph-data -mslow-bytes -mno-slow-bytes -mno-lsim
- -mlittle-endian -mbig-endian -m210 -m340 -mstack-increment
-
- _MeP Options_
- -mabsdiff -mall-opts -maverage -mbased=N -mbitops
- -mc=N -mclip -mconfig=NAME -mcop -mcop32 -mcop64 -mivc2
- -mdc -mdiv -meb -mel -mio-volatile -ml -mleadz -mm -mminmax
- -mmult -mno-opts -mrepeat -ms -msatur -msdram -msim -msimnovec -mtf
- -mtiny=N
-
- _MicroBlaze Options_
- -msoft-float -mhard-float -msmall-divides -mcpu=CPU
- -mmemcpy -mxl-soft-mul -mxl-soft-div -mxl-barrel-shift
- -mxl-pattern-compare -mxl-stack-check -mxl-gp-opt -mno-clearbss
- -mxl-multiply-high -mxl-float-convert -mxl-float-sqrt
- -mxl-mode-APP-MODEL
-
- _MIPS Options_
- -EL -EB -march=ARCH -mtune=ARCH
- -mips1 -mips2 -mips3 -mips4 -mips32 -mips32r2
- -mips64 -mips64r2
- -mips16 -mno-mips16 -mflip-mips16
- -minterlink-mips16 -mno-interlink-mips16
- -mabi=ABI -mabicalls -mno-abicalls
- -mshared -mno-shared -mplt -mno-plt -mxgot -mno-xgot
- -mgp32 -mgp64 -mfp32 -mfp64 -mhard-float -msoft-float
- -msingle-float -mdouble-float -mdsp -mno-dsp -mdspr2 -mno-dspr2
- -mfpu=FPU-TYPE
- -msmartmips -mno-smartmips
- -mpaired-single -mno-paired-single -mdmx -mno-mdmx
- -mips3d -mno-mips3d -mmt -mno-mt -mllsc -mno-llsc
- -mlong64 -mlong32 -msym32 -mno-sym32
- -GNUM -mlocal-sdata -mno-local-sdata
- -mextern-sdata -mno-extern-sdata -mgpopt -mno-gopt
- -membedded-data -mno-embedded-data
- -muninit-const-in-rodata -mno-uninit-const-in-rodata
- -mcode-readable=SETTING
- -msplit-addresses -mno-split-addresses
- -mexplicit-relocs -mno-explicit-relocs
- -mcheck-zero-division -mno-check-zero-division
- -mdivide-traps -mdivide-breaks
- -mmemcpy -mno-memcpy -mlong-calls -mno-long-calls
- -mmad -mno-mad -mfused-madd -mno-fused-madd -nocpp
- -mfix-r4000 -mno-fix-r4000 -mfix-r4400 -mno-fix-r4400
- -mfix-r10000 -mno-fix-r10000 -mfix-vr4120 -mno-fix-vr4120
- -mfix-vr4130 -mno-fix-vr4130 -mfix-sb1 -mno-fix-sb1
- -mflush-func=FUNC -mno-flush-func
- -mbranch-cost=NUM -mbranch-likely -mno-branch-likely
- -mfp-exceptions -mno-fp-exceptions
- -mvr4130-align -mno-vr4130-align -msynci -mno-synci
- -mrelax-pic-calls -mno-relax-pic-calls -mmcount-ra-address
-
- _MMIX Options_
- -mlibfuncs -mno-libfuncs -mepsilon -mno-epsilon -mabi=gnu
- -mabi=mmixware -mzero-extend -mknuthdiv -mtoplevel-symbols
- -melf -mbranch-predict -mno-branch-predict -mbase-addresses
- -mno-base-addresses -msingle-exit -mno-single-exit
-
- _MN10300 Options_
- -mmult-bug -mno-mult-bug
- -mno-am33 -mam33 -mam33-2 -mam34
- -mtune=CPU-TYPE
- -mreturn-pointer-on-d0
- -mno-crt0 -mrelax -mliw
-
- _PDP-11 Options_
- -mfpu -msoft-float -mac0 -mno-ac0 -m40 -m45 -m10
- -mbcopy -mbcopy-builtin -mint32 -mno-int16
- -mint16 -mno-int32 -mfloat32 -mno-float64
- -mfloat64 -mno-float32 -mabshi -mno-abshi
- -mbranch-expensive -mbranch-cheap
- -munix-asm -mdec-asm
-
- _picoChip Options_
- -mae=AE_TYPE -mvliw-lookahead=N
- -msymbol-as-address -mno-inefficient-warnings
-
- _PowerPC Options_ See RS/6000 and PowerPC Options.
-
- _RS/6000 and PowerPC Options_
- -mcpu=CPU-TYPE
- -mtune=CPU-TYPE
- -mcmodel=CODE-MODEL
- -mpower -mno-power -mpower2 -mno-power2
- -mpowerpc -mpowerpc64 -mno-powerpc
- -maltivec -mno-altivec
- -mpowerpc-gpopt -mno-powerpc-gpopt
- -mpowerpc-gfxopt -mno-powerpc-gfxopt
- -mmfcrf -mno-mfcrf -mpopcntb -mno-popcntb -mpopcntd -mno-popcntd
- -mfprnd -mno-fprnd
- -mcmpb -mno-cmpb -mmfpgpr -mno-mfpgpr -mhard-dfp -mno-hard-dfp
- -mnew-mnemonics -mold-mnemonics
- -mfull-toc -mminimal-toc -mno-fp-in-toc -mno-sum-in-toc
- -m64 -m32 -mxl-compat -mno-xl-compat -mpe
- -malign-power -malign-natural
- -msoft-float -mhard-float -mmultiple -mno-multiple
- -msingle-float -mdouble-float -msimple-fpu
- -mstring -mno-string -mupdate -mno-update
- -mavoid-indexed-addresses -mno-avoid-indexed-addresses
- -mfused-madd -mno-fused-madd -mbit-align -mno-bit-align
- -mstrict-align -mno-strict-align -mrelocatable
- -mno-relocatable -mrelocatable-lib -mno-relocatable-lib
- -mtoc -mno-toc -mlittle -mlittle-endian -mbig -mbig-endian
- -mdynamic-no-pic -maltivec -mswdiv -msingle-pic-base
- -mprioritize-restricted-insns=PRIORITY
- -msched-costly-dep=DEPENDENCE_TYPE
- -minsert-sched-nops=SCHEME
- -mcall-sysv -mcall-netbsd
- -maix-struct-return -msvr4-struct-return
- -mabi=ABI-TYPE -msecure-plt -mbss-plt
- -mblock-move-inline-limit=NUM
- -misel -mno-isel
- -misel=yes -misel=no
- -mspe -mno-spe
- -mspe=yes -mspe=no
- -mpaired
- -mgen-cell-microcode -mwarn-cell-microcode
- -mvrsave -mno-vrsave
- -mmulhw -mno-mulhw
- -mdlmzb -mno-dlmzb
- -mfloat-gprs=yes -mfloat-gprs=no -mfloat-gprs=single -mfloat-gprs=double
- -mprototype -mno-prototype
- -msim -mmvme -mads -myellowknife -memb -msdata
- -msdata=OPT -mvxworks -G NUM -pthread
- -mrecip -mrecip=OPT -mno-recip -mrecip-precision
- -mno-recip-precision
- -mveclibabi=TYPE -mfriz -mno-friz
-
- _RX Options_
- -m64bit-doubles -m32bit-doubles -fpu -nofpu
- -mcpu=
- -mbig-endian-data -mlittle-endian-data
- -msmall-data
- -msim -mno-sim
- -mas100-syntax -mno-as100-syntax
- -mrelax
- -mmax-constant-size=
- -mint-register=
- -msave-acc-in-interrupts
-
- _S/390 and zSeries Options_
- -mtune=CPU-TYPE -march=CPU-TYPE
- -mhard-float -msoft-float -mhard-dfp -mno-hard-dfp
- -mlong-double-64 -mlong-double-128
- -mbackchain -mno-backchain -mpacked-stack -mno-packed-stack
- -msmall-exec -mno-small-exec -mmvcle -mno-mvcle
- -m64 -m31 -mdebug -mno-debug -mesa -mzarch
- -mtpf-trace -mno-tpf-trace -mfused-madd -mno-fused-madd
- -mwarn-framesize -mwarn-dynamicstack -mstack-size -mstack-guard
-
- _Score Options_
- -meb -mel
- -mnhwloop
- -muls
- -mmac
- -mscore5 -mscore5u -mscore7 -mscore7d
-
- _SH Options_
- -m1 -m2 -m2e
- -m2a-nofpu -m2a-single-only -m2a-single -m2a
- -m3 -m3e
- -m4-nofpu -m4-single-only -m4-single -m4
- -m4a-nofpu -m4a-single-only -m4a-single -m4a -m4al
- -m5-64media -m5-64media-nofpu
- -m5-32media -m5-32media-nofpu
- -m5-compact -m5-compact-nofpu
- -mb -ml -mdalign -mrelax
- -mbigtable -mfmovd -mhitachi -mrenesas -mno-renesas -mnomacsave
- -mieee -mbitops -misize -minline-ic_invalidate -mpadstruct -mspace
- -mprefergot -musermode -multcost=NUMBER -mdiv=STRATEGY
- -mdivsi3_libfunc=NAME -mfixed-range=REGISTER-RANGE
- -madjust-unroll -mindexed-addressing -mgettrcost=NUMBER -mpt-fixed
- -maccumulate-outgoing-args -minvalid-symbols
-
- _Solaris 2 Options_
- -mimpure-text -mno-impure-text
- -threads -pthreads -pthread
-
- _SPARC Options_
- -mcpu=CPU-TYPE
- -mtune=CPU-TYPE
- -mcmodel=CODE-MODEL
- -m32 -m64 -mapp-regs -mno-app-regs
- -mfaster-structs -mno-faster-structs
- -mfpu -mno-fpu -mhard-float -msoft-float
- -mhard-quad-float -msoft-quad-float
- -mlittle-endian
- -mstack-bias -mno-stack-bias
- -munaligned-doubles -mno-unaligned-doubles
- -mv8plus -mno-v8plus -mvis -mno-vis
- -mfix-at697f
-
- _SPU Options_
- -mwarn-reloc -merror-reloc
- -msafe-dma -munsafe-dma
- -mbranch-hints
- -msmall-mem -mlarge-mem -mstdmain
- -mfixed-range=REGISTER-RANGE
- -mea32 -mea64
- -maddress-space-conversion -mno-address-space-conversion
- -mcache-size=CACHE-SIZE
- -matomic-updates -mno-atomic-updates
-
- _System V Options_
- -Qy -Qn -YP,PATHS -Ym,DIR
-
- _V850 Options_
- -mlong-calls -mno-long-calls -mep -mno-ep
- -mprolog-function -mno-prolog-function -mspace
- -mtda=N -msda=N -mzda=N
- -mapp-regs -mno-app-regs
- -mdisable-callt -mno-disable-callt
- -mv850e2v3
- -mv850e2
- -mv850e1 -mv850es
- -mv850e
- -mv850 -mbig-switch
-
- _VAX Options_
- -mg -mgnu -munix
-
- _VxWorks Options_
- -mrtp -non-static -Bstatic -Bdynamic
- -Xbind-lazy -Xbind-now
-
- _x86-64 Options_ See i386 and x86-64 Options.
-
- _Xstormy16 Options_
- -msim
-
- _Xtensa Options_
- -mconst16 -mno-const16
- -mfused-madd -mno-fused-madd
- -mforce-no-pic
- -mserialize-volatile -mno-serialize-volatile
- -mtext-section-literals -mno-text-section-literals
- -mtarget-align -mno-target-align
- -mlongcalls -mno-longcalls
-
- _zSeries Options_ See S/390 and zSeries Options.
-
-_Code Generation Options_
- *Note Options for Code Generation Conventions: Code Gen Options.
- -fcall-saved-REG -fcall-used-REG
- -ffixed-REG -fexceptions
- -fnon-call-exceptions -funwind-tables
- -fasynchronous-unwind-tables
- -finhibit-size-directive -finstrument-functions
- -finstrument-functions-exclude-function-list=SYM,SYM,...
- -finstrument-functions-exclude-file-list=FILE,FILE,...
- -fno-common -fno-ident
- -fpcc-struct-return -fpic -fPIC -fpie -fPIE
- -fno-jump-tables
- -frecord-gcc-switches
- -freg-struct-return -fshort-enums
- -fshort-double -fshort-wchar
- -fverbose-asm -fpack-struct[=N] -fstack-check
- -fstack-limit-register=REG -fstack-limit-symbol=SYM
- -fno-stack-limit -fsplit-stack
- -fleading-underscore -ftls-model=MODEL
- -ftrapv -fwrapv -fbounds-check
- -fvisibility -fstrict-volatile-bitfields
-
-
-* Menu:
-
-* Overall Options:: Controlling the kind of output:
- an executable, object files, assembler files,
- or preprocessed source.
-* C Dialect Options:: Controlling the variant of C language compiled.
-* C++ Dialect Options:: Variations on C++.
-* Objective-C and Objective-C++ Dialect Options:: Variations on Objective-C
- and Objective-C++.
-* Language Independent Options:: Controlling how diagnostics should be
- formatted.
-* Warning Options:: How picky should the compiler be?
-* Debugging Options:: Symbol tables, measurements, and debugging dumps.
-* Optimize Options:: How much optimization?
-* Preprocessor Options:: Controlling header files and macro definitions.
- Also, getting dependency information for Make.
-* Assembler Options:: Passing options to the assembler.
-* Link Options:: Specifying libraries and so on.
-* Directory Options:: Where to find header files and libraries.
- Where to find the compiler executable files.
-* Spec Files:: How to pass switches to sub-processes.
-* Target Options:: Running a cross-compiler, or an old version of GCC.
-
-
-File: gcc.info, Node: Overall Options, Next: Invoking G++, Prev: Option Summary, Up: Invoking GCC
-
-3.2 Options Controlling the Kind of Output
-==========================================
-
-Compilation can involve up to four stages: preprocessing, compilation
-proper, assembly and linking, always in that order. GCC is capable of
-preprocessing and compiling several files either into several assembler
-input files, or into one assembler input file; then each assembler
-input file produces an object file, and linking combines all the object
-files (those newly compiled, and those specified as input) into an
-executable file.
-
- For any given input file, the file name suffix determines what kind of
-compilation is done:
-
-`FILE.c'
- C source code which must be preprocessed.
-
-`FILE.i'
- C source code which should not be preprocessed.
-
-`FILE.ii'
- C++ source code which should not be preprocessed.
-
-`FILE.m'
- Objective-C source code. Note that you must link with the
- `libobjc' library to make an Objective-C program work.
-
-`FILE.mi'
- Objective-C source code which should not be preprocessed.
-
-`FILE.mm'
-`FILE.M'
- Objective-C++ source code. Note that you must link with the
- `libobjc' library to make an Objective-C++ program work. Note
- that `.M' refers to a literal capital M.
-
-`FILE.mii'
- Objective-C++ source code which should not be preprocessed.
-
-`FILE.h'
- C, C++, Objective-C or Objective-C++ header file to be turned into
- a precompiled header (default), or C, C++ header file to be turned
- into an Ada spec (via the `-fdump-ada-spec' switch).
-
-`FILE.cc'
-`FILE.cp'
-`FILE.cxx'
-`FILE.cpp'
-`FILE.CPP'
-`FILE.c++'
-`FILE.C'
- C++ source code which must be preprocessed. Note that in `.cxx',
- the last two letters must both be literally `x'. Likewise, `.C'
- refers to a literal capital C.
-
-`FILE.mm'
-`FILE.M'
- Objective-C++ source code which must be preprocessed.
-
-`FILE.mii'
- Objective-C++ source code which should not be preprocessed.
-
-`FILE.hh'
-`FILE.H'
-`FILE.hp'
-`FILE.hxx'
-`FILE.hpp'
-`FILE.HPP'
-`FILE.h++'
-`FILE.tcc'
- C++ header file to be turned into a precompiled header or Ada spec.
-
-`FILE.f'
-`FILE.for'
-`FILE.ftn'
- Fixed form Fortran source code which should not be preprocessed.
-
-`FILE.F'
-`FILE.FOR'
-`FILE.fpp'
-`FILE.FPP'
-`FILE.FTN'
- Fixed form Fortran source code which must be preprocessed (with
- the traditional preprocessor).
-
-`FILE.f90'
-`FILE.f95'
-`FILE.f03'
-`FILE.f08'
- Free form Fortran source code which should not be preprocessed.
-
-`FILE.F90'
-`FILE.F95'
-`FILE.F03'
-`FILE.F08'
- Free form Fortran source code which must be preprocessed (with the
- traditional preprocessor).
-
-`FILE.go'
- Go source code.
-
-`FILE.ads'
- Ada source code file which contains a library unit declaration (a
- declaration of a package, subprogram, or generic, or a generic
- instantiation), or a library unit renaming declaration (a package,
- generic, or subprogram renaming declaration). Such files are also
- called "specs".
-
-`FILE.adb'
- Ada source code file containing a library unit body (a subprogram
- or package body). Such files are also called "bodies".
-
-`FILE.s'
- Assembler code.
-
-`FILE.S'
-`FILE.sx'
- Assembler code which must be preprocessed.
-
-`OTHER'
- An object file to be fed straight into linking. Any file name
- with no recognized suffix is treated this way.
-
- You can specify the input language explicitly with the `-x' option:
-
-`-x LANGUAGE'
- Specify explicitly the LANGUAGE for the following input files
- (rather than letting the compiler choose a default based on the
- file name suffix). This option applies to all following input
- files until the next `-x' option. Possible values for LANGUAGE
- are:
- c c-header cpp-output
- c++ c++-header c++-cpp-output
- objective-c objective-c-header objective-c-cpp-output
- objective-c++ objective-c++-header objective-c++-cpp-output
- assembler assembler-with-cpp
- ada
- f77 f77-cpp-input f95 f95-cpp-input
- go
- java
-
-`-x none'
- Turn off any specification of a language, so that subsequent files
- are handled according to their file name suffixes (as they are if
- `-x' has not been used at all).
-
-`-pass-exit-codes'
- Normally the `gcc' program will exit with the code of 1 if any
- phase of the compiler returns a non-success return code. If you
- specify `-pass-exit-codes', the `gcc' program will instead return
- with numerically highest error produced by any phase that returned
- an error indication. The C, C++, and Fortran frontends return 4,
- if an internal compiler error is encountered.
-
- If you only want some of the stages of compilation, you can use `-x'
-(or filename suffixes) to tell `gcc' where to start, and one of the
-options `-c', `-S', or `-E' to say where `gcc' is to stop. Note that
-some combinations (for example, `-x cpp-output -E') instruct `gcc' to
-do nothing at all.
-
-`-c'
- Compile or assemble the source files, but do not link. The linking
- stage simply is not done. The ultimate output is in the form of an
- object file for each source file.
-
- By default, the object file name for a source file is made by
- replacing the suffix `.c', `.i', `.s', etc., with `.o'.
-
- Unrecognized input files, not requiring compilation or assembly,
- are ignored.
-
-`-S'
- Stop after the stage of compilation proper; do not assemble. The
- output is in the form of an assembler code file for each
- non-assembler input file specified.
-
- By default, the assembler file name for a source file is made by
- replacing the suffix `.c', `.i', etc., with `.s'.
-
- Input files that don't require compilation are ignored.
-
-`-E'
- Stop after the preprocessing stage; do not run the compiler
- proper. The output is in the form of preprocessed source code,
- which is sent to the standard output.
-
- Input files which don't require preprocessing are ignored.
-
-`-o FILE'
- Place output in file FILE. This applies regardless to whatever
- sort of output is being produced, whether it be an executable file,
- an object file, an assembler file or preprocessed C code.
-
- If `-o' is not specified, the default is to put an executable file
- in `a.out', the object file for `SOURCE.SUFFIX' in `SOURCE.o', its
- assembler file in `SOURCE.s', a precompiled header file in
- `SOURCE.SUFFIX.gch', and all preprocessed C source on standard
- output.
-
-`-v'
- Print (on standard error output) the commands executed to run the
- stages of compilation. Also print the version number of the
- compiler driver program and of the preprocessor and the compiler
- proper.
-
-`-###'
- Like `-v' except the commands are not executed and arguments are
- quoted unless they contain only alphanumeric characters or `./-_'.
- This is useful for shell scripts to capture the driver-generated
- command lines.
-
-`-pipe'
- Use pipes rather than temporary files for communication between the
- various stages of compilation. This fails to work on some systems
- where the assembler is unable to read from a pipe; but the GNU
- assembler has no trouble.
-
-`--help'
- Print (on the standard output) a description of the command line
- options understood by `gcc'. If the `-v' option is also specified
- then `--help' will also be passed on to the various processes
- invoked by `gcc', so that they can display the command line options
- they accept. If the `-Wextra' option has also been specified
- (prior to the `--help' option), then command line options which
- have no documentation associated with them will also be displayed.
-
-`--target-help'
- Print (on the standard output) a description of target-specific
- command line options for each tool. For some targets extra
- target-specific information may also be printed.
-
-`--help={CLASS|[^]QUALIFIER}[,...]'
- Print (on the standard output) a description of the command line
- options understood by the compiler that fit into all specified
- classes and qualifiers. These are the supported classes:
-
- `optimizers'
- This will display all of the optimization options supported
- by the compiler.
-
- `warnings'
- This will display all of the options controlling warning
- messages produced by the compiler.
-
- `target'
- This will display target-specific options. Unlike the
- `--target-help' option however, target-specific options of the
- linker and assembler will not be displayed. This is because
- those tools do not currently support the extended `--help='
- syntax.
-
- `params'
- This will display the values recognized by the `--param'
- option.
-
- LANGUAGE
- This will display the options supported for LANGUAGE, where
- LANGUAGE is the name of one of the languages supported in this
- version of GCC.
-
- `common'
- This will display the options that are common to all
- languages.
-
- These are the supported qualifiers:
-
- `undocumented'
- Display only those options which are undocumented.
-
- `joined'
- Display options which take an argument that appears after an
- equal sign in the same continuous piece of text, such as:
- `--help=target'.
-
- `separate'
- Display options which take an argument that appears as a
- separate word following the original option, such as: `-o
- output-file'.
-
- Thus for example to display all the undocumented target-specific
- switches supported by the compiler the following can be used:
-
- --help=target,undocumented
-
- The sense of a qualifier can be inverted by prefixing it with the
- `^' character, so for example to display all binary warning
- options (i.e., ones that are either on or off and that do not take
- an argument), which have a description the following can be used:
-
- --help=warnings,^joined,^undocumented
-
- The argument to `--help=' should not consist solely of inverted
- qualifiers.
-
- Combining several classes is possible, although this usually
- restricts the output by so much that there is nothing to display.
- One case where it does work however is when one of the classes is
- TARGET. So for example to display all the target-specific
- optimization options the following can be used:
-
- --help=target,optimizers
-
- The `--help=' option can be repeated on the command line. Each
- successive use will display its requested class of options,
- skipping those that have already been displayed.
-
- If the `-Q' option appears on the command line before the
- `--help=' option, then the descriptive text displayed by `--help='
- is changed. Instead of describing the displayed options, an
- indication is given as to whether the option is enabled, disabled
- or set to a specific value (assuming that the compiler knows this
- at the point where the `--help=' option is used).
-
- Here is a truncated example from the ARM port of `gcc':
-
- % gcc -Q -mabi=2 --help=target -c
- The following options are target specific:
- -mabi= 2
- -mabort-on-noreturn [disabled]
- -mapcs [disabled]
-
- The output is sensitive to the effects of previous command line
- options, so for example it is possible to find out which
- optimizations are enabled at `-O2' by using:
-
- -Q -O2 --help=optimizers
-
- Alternatively you can discover which binary optimizations are
- enabled by `-O3' by using:
-
- gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
- gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
- diff /tmp/O2-opts /tmp/O3-opts | grep enabled
-
-`-canonical-prefixes'
- Always expand any symbolic links, resolve references to `/../' or
- `/./', and make the path absolute when generating a relative
- prefix.
-
-`-no-canonical-prefixes'
- Never expand any symbolic links, resolve references to `/../' or
- `/./', or make the path absolute when generating a relative
- prefix. If neither `-canonical-prefixes' nor
- `-nocanonical-prefixes' is given, GCC tries to set an appropriate
- default by looking for a target-specific subdirectory alongside the
- directory containing the compiler driver.
-
-`--version'
- Display the version number and copyrights of the invoked GCC.
-
-`-wrapper'
- Invoke all subcommands under a wrapper program. The name of the
- wrapper program and its parameters are passed as a comma separated
- list.
-
- gcc -c t.c -wrapper gdb,--args
-
- This will invoke all subprograms of `gcc' under `gdb --args', thus
- the invocation of `cc1' will be `gdb --args cc1 ...'.
-
-`-fplugin=NAME.so'
- Load the plugin code in file NAME.so, assumed to be a shared
- object to be dlopen'd by the compiler. The base name of the
- shared object file is used to identify the plugin for the purposes
- of argument parsing (See `-fplugin-arg-NAME-KEY=VALUE' below).
- Each plugin should define the callback functions specified in the
- Plugins API.
-
-`-fplugin-arg-NAME-KEY=VALUE'
- Define an argument called KEY with a value of VALUE for the plugin
- called NAME.
-
-`-fdump-ada-spec[-slim]'
- For C and C++ source and include files, generate corresponding Ada
- specs. *Note Generating Ada Bindings for C and C++ headers:
- (gnat_ugn)Generating Ada Bindings for C and C++ headers, which
- provides detailed documentation on this feature.
-
-`-fdump-go-spec=FILE'
- For input files in any language, generate corresponding Go
- declarations in FILE. This generates Go `const', `type', `var',
- and `func' declarations which may be a useful way to start writing
- a Go interface to code written in some other language.
-
-`@FILE'
- Read command-line options from FILE. The options read are
- inserted in place of the original @FILE option. If FILE does not
- exist, or cannot be read, then the option will be treated
- literally, and not removed.
-
- Options in FILE are separated by whitespace. A whitespace
- character may be included in an option by surrounding the entire
- option in either single or double quotes. Any character
- (including a backslash) may be included by prefixing the character
- to be included with a backslash. The FILE may itself contain
- additional @FILE options; any such options will be processed
- recursively.
-
-
-File: gcc.info, Node: Invoking G++, Next: C Dialect Options, Prev: Overall Options, Up: Invoking GCC
-
-3.3 Compiling C++ Programs
-==========================
-
-C++ source files conventionally use one of the suffixes `.C', `.cc',
-`.cpp', `.CPP', `.c++', `.cp', or `.cxx'; C++ header files often use
-`.hh', `.hpp', `.H', or (for shared template code) `.tcc'; and
-preprocessed C++ files use the suffix `.ii'. GCC recognizes files with
-these names and compiles them as C++ programs even if you call the
-compiler the same way as for compiling C programs (usually with the
-name `gcc').
-
- However, the use of `gcc' does not add the C++ library. `g++' is a
-program that calls GCC and treats `.c', `.h' and `.i' files as C++
-source files instead of C source files unless `-x' is used, and
-automatically specifies linking against the C++ library. This program
-is also useful when precompiling a C header file with a `.h' extension
-for use in C++ compilations. On many systems, `g++' is also installed
-with the name `c++'.
-
- When you compile C++ programs, you may specify many of the same
-command-line options that you use for compiling programs in any
-language; or command-line options meaningful for C and related
-languages; or options that are meaningful only for C++ programs. *Note
-Options Controlling C Dialect: C Dialect Options, for explanations of
-options for languages related to C. *Note Options Controlling C++
-Dialect: C++ Dialect Options, for explanations of options that are
-meaningful only for C++ programs.
-
-
-File: gcc.info, Node: C Dialect Options, Next: C++ Dialect Options, Prev: Invoking G++, Up: Invoking GCC
-
-3.4 Options Controlling C Dialect
-=================================
-
-The following options control the dialect of C (or languages derived
-from C, such as C++, Objective-C and Objective-C++) that the compiler
-accepts:
-
-`-ansi'
- In C mode, this is equivalent to `-std=c90'. In C++ mode, it is
- equivalent to `-std=c++98'.
-
- This turns off certain features of GCC that are incompatible with
- ISO C90 (when compiling C code), or of standard C++ (when
- compiling C++ code), such as the `asm' and `typeof' keywords, and
- predefined macros such as `unix' and `vax' that identify the type
- of system you are using. It also enables the undesirable and
- rarely used ISO trigraph feature. For the C compiler, it disables
- recognition of C++ style `//' comments as well as the `inline'
- keyword.
-
- The alternate keywords `__asm__', `__extension__', `__inline__'
- and `__typeof__' continue to work despite `-ansi'. You would not
- want to use them in an ISO C program, of course, but it is useful
- to put them in header files that might be included in compilations
- done with `-ansi'. Alternate predefined macros such as `__unix__'
- and `__vax__' are also available, with or without `-ansi'.
-
- The `-ansi' option does not cause non-ISO programs to be rejected
- gratuitously. For that, `-pedantic' is required in addition to
- `-ansi'. *Note Warning Options::.
-
- The macro `__STRICT_ANSI__' is predefined when the `-ansi' option
- is used. Some header files may notice this macro and refrain from
- declaring certain functions or defining certain macros that the
- ISO standard doesn't call for; this is to avoid interfering with
- any programs that might use these names for other things.
-
- Functions that would normally be built in but do not have semantics
- defined by ISO C (such as `alloca' and `ffs') are not built-in
- functions when `-ansi' is used. *Note Other built-in functions
- provided by GCC: Other Builtins, for details of the functions
- affected.
-
-`-std='
- Determine the language standard. *Note Language Standards
- Supported by GCC: Standards, for details of these standard
- versions. This option is currently only supported when compiling
- C or C++.
-
- The compiler can accept several base standards, such as `c90' or
- `c++98', and GNU dialects of those standards, such as `gnu90' or
- `gnu++98'. By specifying a base standard, the compiler will
- accept all programs following that standard and those using GNU
- extensions that do not contradict it. For example, `-std=c90'
- turns off certain features of GCC that are incompatible with ISO
- C90, such as the `asm' and `typeof' keywords, but not other GNU
- extensions that do not have a meaning in ISO C90, such as omitting
- the middle term of a `?:' expression. On the other hand, by
- specifying a GNU dialect of a standard, all features the compiler
- support are enabled, even when those features change the meaning
- of the base standard and some strict-conforming programs may be
- rejected. The particular standard is used by `-pedantic' to
- identify which features are GNU extensions given that version of
- the standard. For example `-std=gnu90 -pedantic' would warn about
- C++ style `//' comments, while `-std=gnu99 -pedantic' would not.
-
- A value for this option must be provided; possible values are
-
- `c90'
- `c89'
- `iso9899:1990'
- Support all ISO C90 programs (certain GNU extensions that
- conflict with ISO C90 are disabled). Same as `-ansi' for C
- code.
-
- `iso9899:199409'
- ISO C90 as modified in amendment 1.
-
- `c99'
- `c9x'
- `iso9899:1999'
- `iso9899:199x'
- ISO C99. Note that this standard is not yet fully supported;
- see `http://gcc.gnu.org/gcc-4.6/c99status.html' for more
- information. The names `c9x' and `iso9899:199x' are
- deprecated.
-
- `c1x'
- ISO C1X, the draft of the next revision of the ISO C standard.
- Support is limited and experimental and features enabled by
- this option may be changed or removed if changed in or
- removed from the standard draft.
-
- `gnu90'
- `gnu89'
- GNU dialect of ISO C90 (including some C99 features). This is
- the default for C code.
-
- `gnu99'
- `gnu9x'
- GNU dialect of ISO C99. When ISO C99 is fully implemented in
- GCC, this will become the default. The name `gnu9x' is
- deprecated.
-
- `gnu1x'
- GNU dialect of ISO C1X. Support is limited and experimental
- and features enabled by this option may be changed or removed
- if changed in or removed from the standard draft.
-
- `c++98'
- The 1998 ISO C++ standard plus amendments. Same as `-ansi' for
- C++ code.
-
- `gnu++98'
- GNU dialect of `-std=c++98'. This is the default for C++
- code.
-
- `c++0x'
- The working draft of the upcoming ISO C++0x standard. This
- option enables experimental features that are likely to be
- included in C++0x. The working draft is constantly changing,
- and any feature that is enabled by this flag may be removed
- from future versions of GCC if it is not part of the C++0x
- standard.
-
- `gnu++0x'
- GNU dialect of `-std=c++0x'. This option enables experimental
- features that may be removed in future versions of GCC.
-
-`-fgnu89-inline'
- The option `-fgnu89-inline' tells GCC to use the traditional GNU
- semantics for `inline' functions when in C99 mode. *Note An
- Inline Function is As Fast As a Macro: Inline. This option is
- accepted and ignored by GCC versions 4.1.3 up to but not including
- 4.3. In GCC versions 4.3 and later it changes the behavior of GCC
- in C99 mode. Using this option is roughly equivalent to adding the
- `gnu_inline' function attribute to all inline functions (*note
- Function Attributes::).
-
- The option `-fno-gnu89-inline' explicitly tells GCC to use the C99
- semantics for `inline' when in C99 or gnu99 mode (i.e., it
- specifies the default behavior). This option was first supported
- in GCC 4.3. This option is not supported in `-std=c90' or
- `-std=gnu90' mode.
-
- The preprocessor macros `__GNUC_GNU_INLINE__' and
- `__GNUC_STDC_INLINE__' may be used to check which semantics are in
- effect for `inline' functions. *Note Common Predefined Macros:
- (cpp)Common Predefined Macros.
-
-`-aux-info FILENAME'
- Output to the given filename prototyped declarations for all
- functions declared and/or defined in a translation unit, including
- those in header files. This option is silently ignored in any
- language other than C.
-
- Besides declarations, the file indicates, in comments, the origin
- of each declaration (source file and line), whether the
- declaration was implicit, prototyped or unprototyped (`I', `N' for
- new or `O' for old, respectively, in the first character after the
- line number and the colon), and whether it came from a declaration
- or a definition (`C' or `F', respectively, in the following
- character). In the case of function definitions, a K&R-style list
- of arguments followed by their declarations is also provided,
- inside comments, after the declaration.
-
-`-fno-asm'
- Do not recognize `asm', `inline' or `typeof' as a keyword, so that
- code can use these words as identifiers. You can use the keywords
- `__asm__', `__inline__' and `__typeof__' instead. `-ansi' implies
- `-fno-asm'.
-
- In C++, this switch only affects the `typeof' keyword, since `asm'
- and `inline' are standard keywords. You may want to use the
- `-fno-gnu-keywords' flag instead, which has the same effect. In
- C99 mode (`-std=c99' or `-std=gnu99'), this switch only affects
- the `asm' and `typeof' keywords, since `inline' is a standard
- keyword in ISO C99.
-
-`-fno-builtin'
-`-fno-builtin-FUNCTION'
- Don't recognize built-in functions that do not begin with
- `__builtin_' as prefix. *Note Other built-in functions provided
- by GCC: Other Builtins, for details of the functions affected,
- including those which are not built-in functions when `-ansi' or
- `-std' options for strict ISO C conformance are used because they
- do not have an ISO standard meaning.
-
- GCC normally generates special code to handle certain built-in
- functions more efficiently; for instance, calls to `alloca' may
- become single instructions that adjust the stack directly, and
- calls to `memcpy' may become inline copy loops. The resulting
- code is often both smaller and faster, but since the function
- calls no longer appear as such, you cannot set a breakpoint on
- those calls, nor can you change the behavior of the functions by
- linking with a different library. In addition, when a function is
- recognized as a built-in function, GCC may use information about
- that function to warn about problems with calls to that function,
- or to generate more efficient code, even if the resulting code
- still contains calls to that function. For example, warnings are
- given with `-Wformat' for bad calls to `printf', when `printf' is
- built in, and `strlen' is known not to modify global memory.
-
- With the `-fno-builtin-FUNCTION' option only the built-in function
- FUNCTION is disabled. FUNCTION must not begin with `__builtin_'.
- If a function is named that is not built-in in this version of
- GCC, this option is ignored. There is no corresponding
- `-fbuiltin-FUNCTION' option; if you wish to enable built-in
- functions selectively when using `-fno-builtin' or
- `-ffreestanding', you may define macros such as:
-
- #define abs(n) __builtin_abs ((n))
- #define strcpy(d, s) __builtin_strcpy ((d), (s))
-
-`-fhosted'
- Assert that compilation takes place in a hosted environment. This
- implies `-fbuiltin'. A hosted environment is one in which the
- entire standard library is available, and in which `main' has a
- return type of `int'. Examples are nearly everything except a
- kernel. This is equivalent to `-fno-freestanding'.
-
-`-ffreestanding'
- Assert that compilation takes place in a freestanding environment.
- This implies `-fno-builtin'. A freestanding environment is one in
- which the standard library may not exist, and program startup may
- not necessarily be at `main'. The most obvious example is an OS
- kernel. This is equivalent to `-fno-hosted'.
-
- *Note Language Standards Supported by GCC: Standards, for details
- of freestanding and hosted environments.
-
-`-fopenmp'
- Enable handling of OpenMP directives `#pragma omp' in C/C++ and
- `!$omp' in Fortran. When `-fopenmp' is specified, the compiler
- generates parallel code according to the OpenMP Application
- Program Interface v3.0 `http://www.openmp.org/'. This option
- implies `-pthread', and thus is only supported on targets that
- have support for `-pthread'.
-
-`-fms-extensions'
- Accept some non-standard constructs used in Microsoft header files.
-
- In C++ code, this allows member names in structures to be similar
- to previous types declarations.
-
- typedef int UOW;
- struct ABC {
- UOW UOW;
- };
-
- Some cases of unnamed fields in structures and unions are only
- accepted with this option. *Note Unnamed struct/union fields
- within structs/unions: Unnamed Fields, for details.
-
-`-fplan9-extensions'
- Accept some non-standard constructs used in Plan 9 code.
-
- This enables `-fms-extensions', permits passing pointers to
- structures with anonymous fields to functions which expect
- pointers to elements of the type of the field, and permits
- referring to anonymous fields declared using a typedef. *Note
- Unnamed struct/union fields within structs/unions: Unnamed Fields,
- for details. This is only supported for C, not C++.
-
-`-trigraphs'
- Support ISO C trigraphs. The `-ansi' option (and `-std' options
- for strict ISO C conformance) implies `-trigraphs'.
-
-`-no-integrated-cpp'
- Performs a compilation in two passes: preprocessing and compiling.
- This option allows a user supplied "cc1", "cc1plus", or "cc1obj"
- via the `-B' option. The user supplied compilation step can then
- add in an additional preprocessing step after normal preprocessing
- but before compiling. The default is to use the integrated cpp
- (internal cpp)
-
- The semantics of this option will change if "cc1", "cc1plus", and
- "cc1obj" are merged.
-
-`-traditional'
-`-traditional-cpp'
- Formerly, these options caused GCC to attempt to emulate a
- pre-standard C compiler. They are now only supported with the
- `-E' switch. The preprocessor continues to support a pre-standard
- mode. See the GNU CPP manual for details.
-
-`-fcond-mismatch'
- Allow conditional expressions with mismatched types in the second
- and third arguments. The value of such an expression is void.
- This option is not supported for C++.
-
-`-flax-vector-conversions'
- Allow implicit conversions between vectors with differing numbers
- of elements and/or incompatible element types. This option should
- not be used for new code.
-
-`-funsigned-char'
- Let the type `char' be unsigned, like `unsigned char'.
-
- Each kind of machine has a default for what `char' should be. It
- is either like `unsigned char' by default or like `signed char' by
- default.
-
- Ideally, a portable program should always use `signed char' or
- `unsigned char' when it depends on the signedness of an object.
- But many programs have been written to use plain `char' and expect
- it to be signed, or expect it to be unsigned, depending on the
- machines they were written for. This option, and its inverse, let
- you make such a program work with the opposite default.
-
- The type `char' is always a distinct type from each of `signed
- char' or `unsigned char', even though its behavior is always just
- like one of those two.
-
-`-fsigned-char'
- Let the type `char' be signed, like `signed char'.
-
- Note that this is equivalent to `-fno-unsigned-char', which is the
- negative form of `-funsigned-char'. Likewise, the option
- `-fno-signed-char' is equivalent to `-funsigned-char'.
-
-`-fsigned-bitfields'
-`-funsigned-bitfields'
-`-fno-signed-bitfields'
-`-fno-unsigned-bitfields'
- These options control whether a bit-field is signed or unsigned,
- when the declaration does not use either `signed' or `unsigned'.
- By default, such a bit-field is signed, because this is
- consistent: the basic integer types such as `int' are signed types.
-
-
-File: gcc.info, Node: C++ Dialect Options, Next: Objective-C and Objective-C++ Dialect Options, Prev: C Dialect Options, Up: Invoking GCC
-
-3.5 Options Controlling C++ Dialect
-===================================
-
-This section describes the command-line options that are only meaningful
-for C++ programs; but you can also use most of the GNU compiler options
-regardless of what language your program is in. For example, you might
-compile a file `firstClass.C' like this:
-
- g++ -g -frepo -O -c firstClass.C
-
-In this example, only `-frepo' is an option meant only for C++
-programs; you can use the other options with any language supported by
-GCC.
-
- Here is a list of options that are _only_ for compiling C++ programs:
-
-`-fabi-version=N'
- Use version N of the C++ ABI. Version 2 is the version of the C++
- ABI that first appeared in G++ 3.4. Version 1 is the version of
- the C++ ABI that first appeared in G++ 3.2. Version 0 will always
- be the version that conforms most closely to the C++ ABI
- specification. Therefore, the ABI obtained using version 0 will
- change as ABI bugs are fixed.
-
- The default is version 2.
-
- Version 3 corrects an error in mangling a constant address as a
- template argument.
-
- Version 4 implements a standard mangling for vector types.
-
- Version 5 corrects the mangling of attribute const/volatile on
- function pointer types, decltype of a plain decl, and use of a
- function parameter in the declaration of another parameter.
-
- See also `-Wabi'.
-
-`-fno-access-control'
- Turn off all access checking. This switch is mainly useful for
- working around bugs in the access control code.
-
-`-fcheck-new'
- Check that the pointer returned by `operator new' is non-null
- before attempting to modify the storage allocated. This check is
- normally unnecessary because the C++ standard specifies that
- `operator new' will only return `0' if it is declared `throw()',
- in which case the compiler will always check the return value even
- without this option. In all other cases, when `operator new' has
- a non-empty exception specification, memory exhaustion is
- signalled by throwing `std::bad_alloc'. See also `new (nothrow)'.
-
-`-fconserve-space'
- Put uninitialized or runtime-initialized global variables into the
- common segment, as C does. This saves space in the executable at
- the cost of not diagnosing duplicate definitions. If you compile
- with this flag and your program mysteriously crashes after
- `main()' has completed, you may have an object that is being
- destroyed twice because two definitions were merged.
-
- This option is no longer useful on most targets, now that support
- has been added for putting variables into BSS without making them
- common.
-
-`-fconstexpr-depth=N'
- Set the maximum nested evaluation depth for C++0x constexpr
- functions to N. A limit is needed to detect endless recursion
- during constant expression evaluation. The minimum specified by
- the standard is 512.
-
-`-fno-deduce-init-list'
- Disable deduction of a template type parameter as
- std::initializer_list from a brace-enclosed initializer list, i.e.
-
- template <class T> auto forward(T t) -> decltype (realfn (t))
- {
- return realfn (t);
- }
-
- void f()
- {
- forward({1,2}); // call forward<std::initializer_list<int>>
- }
-
- This option is present because this deduction is an extension to
- the current specification in the C++0x working draft, and there was
- some concern about potential overload resolution problems.
-
-`-ffriend-injection'
- Inject friend functions into the enclosing namespace, so that they
- are visible outside the scope of the class in which they are
- declared. Friend functions were documented to work this way in
- the old Annotated C++ Reference Manual, and versions of G++ before
- 4.1 always worked that way. However, in ISO C++ a friend function
- which is not declared in an enclosing scope can only be found
- using argument dependent lookup. This option causes friends to be
- injected as they were in earlier releases.
-
- This option is for compatibility, and may be removed in a future
- release of G++.
-
-`-fno-elide-constructors'
- The C++ standard allows an implementation to omit creating a
- temporary which is only used to initialize another object of the
- same type. Specifying this option disables that optimization, and
- forces G++ to call the copy constructor in all cases.
-
-`-fno-enforce-eh-specs'
- Don't generate code to check for violation of exception
- specifications at runtime. This option violates the C++ standard,
- but may be useful for reducing code size in production builds,
- much like defining `NDEBUG'. This does not give user code
- permission to throw exceptions in violation of the exception
- specifications; the compiler will still optimize based on the
- specifications, so throwing an unexpected exception will result in
- undefined behavior.
-
-`-ffor-scope'
-`-fno-for-scope'
- If `-ffor-scope' is specified, the scope of variables declared in
- a for-init-statement is limited to the `for' loop itself, as
- specified by the C++ standard. If `-fno-for-scope' is specified,
- the scope of variables declared in a for-init-statement extends to
- the end of the enclosing scope, as was the case in old versions of
- G++, and other (traditional) implementations of C++.
-
- The default if neither flag is given to follow the standard, but
- to allow and give a warning for old-style code that would
- otherwise be invalid, or have different behavior.
-
-`-fno-gnu-keywords'
- Do not recognize `typeof' as a keyword, so that code can use this
- word as an identifier. You can use the keyword `__typeof__'
- instead. `-ansi' implies `-fno-gnu-keywords'.
-
-`-fno-implicit-templates'
- Never emit code for non-inline templates which are instantiated
- implicitly (i.e. by use); only emit code for explicit
- instantiations. *Note Template Instantiation::, for more
- information.
-
-`-fno-implicit-inline-templates'
- Don't emit code for implicit instantiations of inline templates,
- either. The default is to handle inlines differently so that
- compiles with and without optimization will need the same set of
- explicit instantiations.
-
-`-fno-implement-inlines'
- To save space, do not emit out-of-line copies of inline functions
- controlled by `#pragma implementation'. This will cause linker
- errors if these functions are not inlined everywhere they are
- called.
-
-`-fms-extensions'
- Disable pedantic warnings about constructs used in MFC, such as
- implicit int and getting a pointer to member function via
- non-standard syntax.
-
-`-fno-nonansi-builtins'
- Disable built-in declarations of functions that are not mandated by
- ANSI/ISO C. These include `ffs', `alloca', `_exit', `index',
- `bzero', `conjf', and other related functions.
-
-`-fnothrow-opt'
- Treat a `throw()' exception specification as though it were a
- `noexcept' specification to reduce or eliminate the text size
- overhead relative to a function with no exception specification.
- If the function has local variables of types with non-trivial
- destructors, the exception specification will actually make the
- function smaller because the EH cleanups for those variables can be
- optimized away. The semantic effect is that an exception thrown
- out of a function with such an exception specification will result
- in a call to `terminate' rather than `unexpected'.
-
-`-fno-operator-names'
- Do not treat the operator name keywords `and', `bitand', `bitor',
- `compl', `not', `or' and `xor' as synonyms as keywords.
-
-`-fno-optional-diags'
- Disable diagnostics that the standard says a compiler does not
- need to issue. Currently, the only such diagnostic issued by G++
- is the one for a name having multiple meanings within a class.
-
-`-fpermissive'
- Downgrade some diagnostics about nonconformant code from errors to
- warnings. Thus, using `-fpermissive' will allow some
- nonconforming code to compile.
-
-`-fno-pretty-templates'
- When an error message refers to a specialization of a function
- template, the compiler will normally print the signature of the
- template followed by the template arguments and any typedefs or
- typenames in the signature (e.g. `void f(T) [with T = int]' rather
- than `void f(int)') so that it's clear which template is involved.
- When an error message refers to a specialization of a class
- template, the compiler will omit any template arguments which match
- the default template arguments for that template. If either of
- these behaviors make it harder to understand the error message
- rather than easier, using `-fno-pretty-templates' will disable
- them.
-
-`-frepo'
- Enable automatic template instantiation at link time. This option
- also implies `-fno-implicit-templates'. *Note Template
- Instantiation::, for more information.
-
-`-fno-rtti'
- Disable generation of information about every class with virtual
- functions for use by the C++ runtime type identification features
- (`dynamic_cast' and `typeid'). If you don't use those parts of
- the language, you can save some space by using this flag. Note
- that exception handling uses the same information, but it will
- generate it as needed. The `dynamic_cast' operator can still be
- used for casts that do not require runtime type information, i.e.
- casts to `void *' or to unambiguous base classes.
-
-`-fstats'
- Emit statistics about front-end processing at the end of the
- compilation. This information is generally only useful to the G++
- development team.
-
-`-fstrict-enums'
- Allow the compiler to optimize using the assumption that a value of
- enumeration type can only be one of the values of the enumeration
- (as defined in the C++ standard; basically, a value which can be
- represented in the minimum number of bits needed to represent all
- the enumerators). This assumption may not be valid if the program
- uses a cast to convert an arbitrary integer value to the
- enumeration type.
-
-`-ftemplate-depth=N'
- Set the maximum instantiation depth for template classes to N. A
- limit on the template instantiation depth is needed to detect
- endless recursions during template class instantiation. ANSI/ISO
- C++ conforming programs must not rely on a maximum depth greater
- than 17 (changed to 1024 in C++0x).
-
-`-fno-threadsafe-statics'
- Do not emit the extra code to use the routines specified in the C++
- ABI for thread-safe initialization of local statics. You can use
- this option to reduce code size slightly in code that doesn't need
- to be thread-safe.
-
-`-fuse-cxa-atexit'
- Register destructors for objects with static storage duration with
- the `__cxa_atexit' function rather than the `atexit' function.
- This option is required for fully standards-compliant handling of
- static destructors, but will only work if your C library supports
- `__cxa_atexit'.
-
-`-fno-use-cxa-get-exception-ptr'
- Don't use the `__cxa_get_exception_ptr' runtime routine. This
- will cause `std::uncaught_exception' to be incorrect, but is
- necessary if the runtime routine is not available.
-
-`-fvisibility-inlines-hidden'
- This switch declares that the user does not attempt to compare
- pointers to inline methods where the addresses of the two functions
- were taken in different shared objects.
-
- The effect of this is that GCC may, effectively, mark inline
- methods with `__attribute__ ((visibility ("hidden")))' so that
- they do not appear in the export table of a DSO and do not require
- a PLT indirection when used within the DSO. Enabling this option
- can have a dramatic effect on load and link times of a DSO as it
- massively reduces the size of the dynamic export table when the
- library makes heavy use of templates.
-
- The behavior of this switch is not quite the same as marking the
- methods as hidden directly, because it does not affect static
- variables local to the function or cause the compiler to deduce
- that the function is defined in only one shared object.
-
- You may mark a method as having a visibility explicitly to negate
- the effect of the switch for that method. For example, if you do
- want to compare pointers to a particular inline method, you might
- mark it as having default visibility. Marking the enclosing class
- with explicit visibility will have no effect.
-
- Explicitly instantiated inline methods are unaffected by this
- option as their linkage might otherwise cross a shared library
- boundary. *Note Template Instantiation::.
-
-`-fvisibility-ms-compat'
- This flag attempts to use visibility settings to make GCC's C++
- linkage model compatible with that of Microsoft Visual Studio.
-
- The flag makes these changes to GCC's linkage model:
-
- 1. It sets the default visibility to `hidden', like
- `-fvisibility=hidden'.
-
- 2. Types, but not their members, are not hidden by default.
-
- 3. The One Definition Rule is relaxed for types without explicit
- visibility specifications which are defined in more than one
- different shared object: those declarations are permitted if
- they would have been permitted when this option was not used.
-
- In new code it is better to use `-fvisibility=hidden' and export
- those classes which are intended to be externally visible.
- Unfortunately it is possible for code to rely, perhaps
- accidentally, on the Visual Studio behavior.
-
- Among the consequences of these changes are that static data
- members of the same type with the same name but defined in
- different shared objects will be different, so changing one will
- not change the other; and that pointers to function members
- defined in different shared objects may not compare equal. When
- this flag is given, it is a violation of the ODR to define types
- with the same name differently.
-
-`-fno-weak'
- Do not use weak symbol support, even if it is provided by the
- linker. By default, G++ will use weak symbols if they are
- available. This option exists only for testing, and should not be
- used by end-users; it will result in inferior code and has no
- benefits. This option may be removed in a future release of G++.
-
-`-nostdinc++'
- Do not search for header files in the standard directories
- specific to C++, but do still search the other standard
- directories. (This option is used when building the C++ library.)
-
- In addition, these optimization, warning, and code generation options
-have meanings only for C++ programs:
-
-`-fno-default-inline'
- Do not assume `inline' for functions defined inside a class scope.
- *Note Options That Control Optimization: Optimize Options. Note
- that these functions will have linkage like inline functions; they
- just won't be inlined by default.
-
-`-Wabi (C, Objective-C, C++ and Objective-C++ only)'
- Warn when G++ generates code that is probably not compatible with
- the vendor-neutral C++ ABI. Although an effort has been made to
- warn about all such cases, there are probably some cases that are
- not warned about, even though G++ is generating incompatible code.
- There may also be cases where warnings are emitted even though the
- code that is generated will be compatible.
-
- You should rewrite your code to avoid these warnings if you are
- concerned about the fact that code generated by G++ may not be
- binary compatible with code generated by other compilers.
-
- The known incompatibilities in `-fabi-version=2' (the default)
- include:
-
- * A template with a non-type template parameter of reference
- type is mangled incorrectly:
- extern int N;
- template <int &> struct S {};
- void n (S<N>) {2}
-
- This is fixed in `-fabi-version=3'.
-
- * SIMD vector types declared using `__attribute
- ((vector_size))' are mangled in a non-standard way that does
- not allow for overloading of functions taking vectors of
- different sizes.
-
- The mangling is changed in `-fabi-version=4'.
-
- The known incompatibilities in `-fabi-version=1' include:
-
- * Incorrect handling of tail-padding for bit-fields. G++ may
- attempt to pack data into the same byte as a base class. For
- example:
-
- struct A { virtual void f(); int f1 : 1; };
- struct B : public A { int f2 : 1; };
-
- In this case, G++ will place `B::f2' into the same byte
- as`A::f1'; other compilers will not. You can avoid this
- problem by explicitly padding `A' so that its size is a
- multiple of the byte size on your platform; that will cause
- G++ and other compilers to layout `B' identically.
-
- * Incorrect handling of tail-padding for virtual bases. G++
- does not use tail padding when laying out virtual bases. For
- example:
-
- struct A { virtual void f(); char c1; };
- struct B { B(); char c2; };
- struct C : public A, public virtual B {};
-
- In this case, G++ will not place `B' into the tail-padding for
- `A'; other compilers will. You can avoid this problem by
- explicitly padding `A' so that its size is a multiple of its
- alignment (ignoring virtual base classes); that will cause
- G++ and other compilers to layout `C' identically.
-
- * Incorrect handling of bit-fields with declared widths greater
- than that of their underlying types, when the bit-fields
- appear in a union. For example:
-
- union U { int i : 4096; };
-
- Assuming that an `int' does not have 4096 bits, G++ will make
- the union too small by the number of bits in an `int'.
-
- * Empty classes can be placed at incorrect offsets. For
- example:
-
- struct A {};
-
- struct B {
- A a;
- virtual void f ();
- };
-
- struct C : public B, public A {};
-
- G++ will place the `A' base class of `C' at a nonzero offset;
- it should be placed at offset zero. G++ mistakenly believes
- that the `A' data member of `B' is already at offset zero.
-
- * Names of template functions whose types involve `typename' or
- template template parameters can be mangled incorrectly.
-
- template <typename Q>
- void f(typename Q::X) {}
-
- template <template <typename> class Q>
- void f(typename Q<int>::X) {}
-
- Instantiations of these templates may be mangled incorrectly.
-
-
- It also warns psABI related changes. The known psABI changes at
- this point include:
-
- * For SYSV/x86-64, when passing union with long double, it is
- changed to pass in memory as specified in psABI. For example:
-
- union U {
- long double ld;
- int i;
- };
-
- `union U' will always be passed in memory.
-
-
-`-Wctor-dtor-privacy (C++ and Objective-C++ only)'
- Warn when a class seems unusable because all the constructors or
- destructors in that class are private, and it has neither friends
- nor public static member functions.
-
-`-Wnoexcept (C++ and Objective-C++ only)'
- Warn when a noexcept-expression evaluates to false because of a
- call to a function that does not have a non-throwing exception
- specification (i.e. `throw()' or `noexcept') but is known by the
- compiler to never throw an exception.
-
-`-Wnon-virtual-dtor (C++ and Objective-C++ only)'
- Warn when a class has virtual functions and accessible non-virtual
- destructor, in which case it would be possible but unsafe to delete
- an instance of a derived class through a pointer to the base class.
- This warning is also enabled if -Weffc++ is specified.
-
-`-Wreorder (C++ and Objective-C++ only)'
- Warn when the order of member initializers given in the code does
- not match the order in which they must be executed. For instance:
-
- struct A {
- int i;
- int j;
- A(): j (0), i (1) { }
- };
-
- The compiler will rearrange the member initializers for `i' and
- `j' to match the declaration order of the members, emitting a
- warning to that effect. This warning is enabled by `-Wall'.
-
- The following `-W...' options are not affected by `-Wall'.
-
-`-Weffc++ (C++ and Objective-C++ only)'
- Warn about violations of the following style guidelines from Scott
- Meyers' `Effective C++' book:
-
- * Item 11: Define a copy constructor and an assignment
- operator for classes with dynamically allocated memory.
-
- * Item 12: Prefer initialization to assignment in constructors.
-
- * Item 14: Make destructors virtual in base classes.
-
- * Item 15: Have `operator=' return a reference to `*this'.
-
- * Item 23: Don't try to return a reference when you must
- return an object.
-
-
- Also warn about violations of the following style guidelines from
- Scott Meyers' `More Effective C++' book:
-
- * Item 6: Distinguish between prefix and postfix forms of
- increment and decrement operators.
-
- * Item 7: Never overload `&&', `||', or `,'.
-
-
- When selecting this option, be aware that the standard library
- headers do not obey all of these guidelines; use `grep -v' to
- filter out those warnings.
-
-`-Wstrict-null-sentinel (C++ and Objective-C++ only)'
- Warn also about the use of an uncasted `NULL' as sentinel. When
- compiling only with GCC this is a valid sentinel, as `NULL' is
- defined to `__null'. Although it is a null pointer constant not a
- null pointer, it is guaranteed to be of the same size as a
- pointer. But this use is not portable across different compilers.
-
-`-Wno-non-template-friend (C++ and Objective-C++ only)'
- Disable warnings when non-templatized friend functions are declared
- within a template. Since the advent of explicit template
- specification support in G++, if the name of the friend is an
- unqualified-id (i.e., `friend foo(int)'), the C++ language
- specification demands that the friend declare or define an
- ordinary, nontemplate function. (Section 14.5.3). Before G++
- implemented explicit specification, unqualified-ids could be
- interpreted as a particular specialization of a templatized
- function. Because this non-conforming behavior is no longer the
- default behavior for G++, `-Wnon-template-friend' allows the
- compiler to check existing code for potential trouble spots and is
- on by default. This new compiler behavior can be turned off with
- `-Wno-non-template-friend' which keeps the conformant compiler code
- but disables the helpful warning.
-
-`-Wold-style-cast (C++ and Objective-C++ only)'
- Warn if an old-style (C-style) cast to a non-void type is used
- within a C++ program. The new-style casts (`dynamic_cast',
- `static_cast', `reinterpret_cast', and `const_cast') are less
- vulnerable to unintended effects and much easier to search for.
-
-`-Woverloaded-virtual (C++ and Objective-C++ only)'
- Warn when a function declaration hides virtual functions from a
- base class. For example, in:
-
- struct A {
- virtual void f();
- };
-
- struct B: public A {
- void f(int);
- };
-
- the `A' class version of `f' is hidden in `B', and code like:
-
- B* b;
- b->f();
-
- will fail to compile.
-
-`-Wno-pmf-conversions (C++ and Objective-C++ only)'
- Disable the diagnostic for converting a bound pointer to member
- function to a plain pointer.
-
-`-Wsign-promo (C++ and Objective-C++ only)'
- Warn when overload resolution chooses a promotion from unsigned or
- enumerated type to a signed type, over a conversion to an unsigned
- type of the same size. Previous versions of G++ would try to
- preserve unsignedness, but the standard mandates the current
- behavior.
-
- struct A {
- operator int ();
- A& operator = (int);
- };
-
- main ()
- {
- A a,b;
- a = b;
- }
-
- In this example, G++ will synthesize a default `A& operator =
- (const A&);', while cfront will use the user-defined `operator ='.
-
-
-File: gcc.info, Node: Objective-C and Objective-C++ Dialect Options, Next: Language Independent Options, Prev: C++ Dialect Options, Up: Invoking GCC
-
-3.6 Options Controlling Objective-C and Objective-C++ Dialects
-==============================================================
-
-(NOTE: This manual does not describe the Objective-C and Objective-C++
-languages themselves. *Note Language Standards Supported by GCC:
-Standards, for references.)
-
- This section describes the command-line options that are only
-meaningful for Objective-C and Objective-C++ programs, but you can also
-use most of the language-independent GNU compiler options. For
-example, you might compile a file `some_class.m' like this:
-
- gcc -g -fgnu-runtime -O -c some_class.m
-
-In this example, `-fgnu-runtime' is an option meant only for
-Objective-C and Objective-C++ programs; you can use the other options
-with any language supported by GCC.
-
- Note that since Objective-C is an extension of the C language,
-Objective-C compilations may also use options specific to the C
-front-end (e.g., `-Wtraditional'). Similarly, Objective-C++
-compilations may use C++-specific options (e.g., `-Wabi').
-
- Here is a list of options that are _only_ for compiling Objective-C
-and Objective-C++ programs:
-
-`-fconstant-string-class=CLASS-NAME'
- Use CLASS-NAME as the name of the class to instantiate for each
- literal string specified with the syntax `@"..."'. The default
- class name is `NXConstantString' if the GNU runtime is being used,
- and `NSConstantString' if the NeXT runtime is being used (see
- below). The `-fconstant-cfstrings' option, if also present, will
- override the `-fconstant-string-class' setting and cause `@"..."'
- literals to be laid out as constant CoreFoundation strings.
-
-`-fgnu-runtime'
- Generate object code compatible with the standard GNU Objective-C
- runtime. This is the default for most types of systems.
-
-`-fnext-runtime'
- Generate output compatible with the NeXT runtime. This is the
- default for NeXT-based systems, including Darwin and Mac OS X.
- The macro `__NEXT_RUNTIME__' is predefined if (and only if) this
- option is used.
-
-`-fno-nil-receivers'
- Assume that all Objective-C message dispatches (`[receiver
- message:arg]') in this translation unit ensure that the receiver is
- not `nil'. This allows for more efficient entry points in the
- runtime to be used. This option is only available in conjunction
- with the NeXT runtime and ABI version 0 or 1.
-
-`-fobjc-abi-version=N'
- Use version N of the Objective-C ABI for the selected runtime.
- This option is currently supported only for the NeXT runtime. In
- that case, Version 0 is the traditional (32-bit) ABI without
- support for properties and other Objective-C 2.0 additions.
- Version 1 is the traditional (32-bit) ABI with support for
- properties and other Objective-C 2.0 additions. Version 2 is the
- modern (64-bit) ABI. If nothing is specified, the default is
- Version 0 on 32-bit target machines, and Version 2 on 64-bit
- target machines.
-
-`-fobjc-call-cxx-cdtors'
- For each Objective-C class, check if any of its instance variables
- is a C++ object with a non-trivial default constructor. If so,
- synthesize a special `- (id) .cxx_construct' instance method that
- will run non-trivial default constructors on any such instance
- variables, in order, and then return `self'. Similarly, check if
- any instance variable is a C++ object with a non-trivial
- destructor, and if so, synthesize a special `- (void)
- .cxx_destruct' method that will run all such default destructors,
- in reverse order.
-
- The `- (id) .cxx_construct' and `- (void) .cxx_destruct' methods
- thusly generated will only operate on instance variables declared
- in the current Objective-C class, and not those inherited from
- superclasses. It is the responsibility of the Objective-C runtime
- to invoke all such methods in an object's inheritance hierarchy.
- The `- (id) .cxx_construct' methods will be invoked by the runtime
- immediately after a new object instance is allocated; the `-
- (void) .cxx_destruct' methods will be invoked immediately before
- the runtime deallocates an object instance.
-
- As of this writing, only the NeXT runtime on Mac OS X 10.4 and
- later has support for invoking the `- (id) .cxx_construct' and `-
- (void) .cxx_destruct' methods.
-
-`-fobjc-direct-dispatch'
- Allow fast jumps to the message dispatcher. On Darwin this is
- accomplished via the comm page.
-
-`-fobjc-exceptions'
- Enable syntactic support for structured exception handling in
- Objective-C, similar to what is offered by C++ and Java. This
- option is required to use the Objective-C keywords `@try',
- `@throw', `@catch', `@finally' and `@synchronized'. This option
- is available with both the GNU runtime and the NeXT runtime (but
- not available in conjunction with the NeXT runtime on Mac OS X
- 10.2 and earlier).
-
-`-fobjc-gc'
- Enable garbage collection (GC) in Objective-C and Objective-C++
- programs. This option is only available with the NeXT runtime; the
- GNU runtime has a different garbage collection implementation that
- does not require special compiler flags.
-
-`-fobjc-nilcheck'
- For the NeXT runtime with version 2 of the ABI, check for a nil
- receiver in method invocations before doing the actual method call.
- This is the default and can be disabled using
- `-fno-objc-nilcheck'. Class methods and super calls are never
- checked for nil in this way no matter what this flag is set to.
- Currently this flag does nothing when the GNU runtime, or an older
- version of the NeXT runtime ABI, is used.
-
-`-fobjc-std=objc1'
- Conform to the language syntax of Objective-C 1.0, the language
- recognized by GCC 4.0. This only affects the Objective-C
- additions to the C/C++ language; it does not affect conformance to
- C/C++ standards, which is controlled by the separate C/C++ dialect
- option flags. When this option is used with the Objective-C or
- Objective-C++ compiler, any Objective-C syntax that is not
- recognized by GCC 4.0 is rejected. This is useful if you need to
- make sure that your Objective-C code can be compiled with older
- versions of GCC.
-
-`-freplace-objc-classes'
- Emit a special marker instructing `ld(1)' not to statically link in
- the resulting object file, and allow `dyld(1)' to load it in at
- run time instead. This is used in conjunction with the
- Fix-and-Continue debugging mode, where the object file in question
- may be recompiled and dynamically reloaded in the course of
- program execution, without the need to restart the program itself.
- Currently, Fix-and-Continue functionality is only available in
- conjunction with the NeXT runtime on Mac OS X 10.3 and later.
-
-`-fzero-link'
- When compiling for the NeXT runtime, the compiler ordinarily
- replaces calls to `objc_getClass("...")' (when the name of the
- class is known at compile time) with static class references that
- get initialized at load time, which improves run-time performance.
- Specifying the `-fzero-link' flag suppresses this behavior and
- causes calls to `objc_getClass("...")' to be retained. This is
- useful in Zero-Link debugging mode, since it allows for individual
- class implementations to be modified during program execution.
- The GNU runtime currently always retains calls to
- `objc_get_class("...")' regardless of command line options.
-
-`-gen-decls'
- Dump interface declarations for all classes seen in the source
- file to a file named `SOURCENAME.decl'.
-
-`-Wassign-intercept (Objective-C and Objective-C++ only)'
- Warn whenever an Objective-C assignment is being intercepted by the
- garbage collector.
-
-`-Wno-protocol (Objective-C and Objective-C++ only)'
- If a class is declared to implement a protocol, a warning is
- issued for every method in the protocol that is not implemented by
- the class. The default behavior is to issue a warning for every
- method not explicitly implemented in the class, even if a method
- implementation is inherited from the superclass. If you use the
- `-Wno-protocol' option, then methods inherited from the superclass
- are considered to be implemented, and no warning is issued for
- them.
-
-`-Wselector (Objective-C and Objective-C++ only)'
- Warn if multiple methods of different types for the same selector
- are found during compilation. The check is performed on the list
- of methods in the final stage of compilation. Additionally, a
- check is performed for each selector appearing in a
- `@selector(...)' expression, and a corresponding method for that
- selector has been found during compilation. Because these checks
- scan the method table only at the end of compilation, these
- warnings are not produced if the final stage of compilation is not
- reached, for example because an error is found during compilation,
- or because the `-fsyntax-only' option is being used.
-
-`-Wstrict-selector-match (Objective-C and Objective-C++ only)'
- Warn if multiple methods with differing argument and/or return
- types are found for a given selector when attempting to send a
- message using this selector to a receiver of type `id' or `Class'.
- When this flag is off (which is the default behavior), the
- compiler will omit such warnings if any differences found are
- confined to types which share the same size and alignment.
-
-`-Wundeclared-selector (Objective-C and Objective-C++ only)'
- Warn if a `@selector(...)' expression referring to an undeclared
- selector is found. A selector is considered undeclared if no
- method with that name has been declared before the
- `@selector(...)' expression, either explicitly in an `@interface'
- or `@protocol' declaration, or implicitly in an `@implementation'
- section. This option always performs its checks as soon as a
- `@selector(...)' expression is found, while `-Wselector' only
- performs its checks in the final stage of compilation. This also
- enforces the coding style convention that methods and selectors
- must be declared before being used.
-
-`-print-objc-runtime-info'
- Generate C header describing the largest structure that is passed
- by value, if any.
-
-
-
-File: gcc.info, Node: Language Independent Options, Next: Warning Options, Prev: Objective-C and Objective-C++ Dialect Options, Up: Invoking GCC
-
-3.7 Options to Control Diagnostic Messages Formatting
-=====================================================
-
-Traditionally, diagnostic messages have been formatted irrespective of
-the output device's aspect (e.g. its width, ...). The options described
-below can be used to control the diagnostic messages formatting
-algorithm, e.g. how many characters per line, how often source location
-information should be reported. Right now, only the C++ front end can
-honor these options. However it is expected, in the near future, that
-the remaining front ends would be able to digest them correctly.
-
-`-fmessage-length=N'
- Try to format error messages so that they fit on lines of about N
- characters. The default is 72 characters for `g++' and 0 for the
- rest of the front ends supported by GCC. If N is zero, then no
- line-wrapping will be done; each error message will appear on a
- single line.
-
-`-fdiagnostics-show-location=once'
- Only meaningful in line-wrapping mode. Instructs the diagnostic
- messages reporter to emit _once_ source location information; that
- is, in case the message is too long to fit on a single physical
- line and has to be wrapped, the source location won't be emitted
- (as prefix) again, over and over, in subsequent continuation
- lines. This is the default behavior.
-
-`-fdiagnostics-show-location=every-line'
- Only meaningful in line-wrapping mode. Instructs the diagnostic
- messages reporter to emit the same source location information (as
- prefix) for physical lines that result from the process of breaking
- a message which is too long to fit on a single line.
-
-`-fno-diagnostics-show-option'
- By default, each diagnostic emitted includes text which indicates
- the command line option that directly controls the diagnostic (if
- such an option is known to the diagnostic machinery). Specifying
- the `-fno-diagnostics-show-option' flag suppresses that behavior.
-
-`-Wcoverage-mismatch'
- Warn if feedback profiles do not match when using the
- `-fprofile-use' option. If a source file was changed between
- `-fprofile-gen' and `-fprofile-use', the files with the profile
- feedback can fail to match the source file and GCC can not use the
- profile feedback information. By default, this warning is enabled
- and is treated as an error. `-Wno-coverage-mismatch' can be used
- to disable the warning or `-Wno-error=coverage-mismatch' can be
- used to disable the error. Disable the error for this warning can
- result in poorly optimized code, so disabling the error is useful
- only in the case of very minor changes such as bug fixes to an
- existing code-base. Completely disabling the warning is not
- recommended.
-
-
-
-File: gcc.info, Node: Warning Options, Next: Debugging Options, Prev: Language Independent Options, Up: Invoking GCC
-
-3.8 Options to Request or Suppress Warnings
-===========================================
-
-Warnings are diagnostic messages that report constructions which are
-not inherently erroneous but which are risky or suggest there may have
-been an error.
-
- The following language-independent options do not enable specific
-warnings but control the kinds of diagnostics produced by GCC.
-
-`-fsyntax-only'
- Check the code for syntax errors, but don't do anything beyond
- that.
-
-`-fmax-errors=N'
- Limits the maximum number of error messages to N, at which point
- GCC bails out rather than attempting to continue processing the
- source code. If N is 0 (the default), there is no limit on the
- number of error messages produced. If `-Wfatal-errors' is also
- specified, then `-Wfatal-errors' takes precedence over this option.
-
-`-w'
- Inhibit all warning messages.
-
-`-Werror'
- Make all warnings into errors.
-
-`-Werror='
- Make the specified warning into an error. The specifier for a
- warning is appended, for example `-Werror=switch' turns the
- warnings controlled by `-Wswitch' into errors. This switch takes a
- negative form, to be used to negate `-Werror' for specific
- warnings, for example `-Wno-error=switch' makes `-Wswitch'
- warnings not be errors, even when `-Werror' is in effect.
-
- The warning message for each controllable warning includes the
- option which controls the warning. That option can then be used
- with `-Werror=' and `-Wno-error=' as described above. (Printing
- of the option in the warning message can be disabled using the
- `-fno-diagnostics-show-option' flag.)
-
- Note that specifying `-Werror='FOO automatically implies `-W'FOO.
- However, `-Wno-error='FOO does not imply anything.
-
-`-Wfatal-errors'
- This option causes the compiler to abort compilation on the first
- error occurred rather than trying to keep going and printing
- further error messages.
-
-
- You can request many specific warnings with options beginning `-W',
-for example `-Wimplicit' to request warnings on implicit declarations.
-Each of these specific warning options also has a negative form
-beginning `-Wno-' to turn off warnings; for example, `-Wno-implicit'.
-This manual lists only one of the two forms, whichever is not the
-default. For further, language-specific options also refer to *note
-C++ Dialect Options:: and *note Objective-C and Objective-C++ Dialect
-Options::.
-
- When an unrecognized warning option is requested (e.g.,
-`-Wunknown-warning'), GCC will emit a diagnostic stating that the
-option is not recognized. However, if the `-Wno-' form is used, the
-behavior is slightly different: No diagnostic will be produced for
-`-Wno-unknown-warning' unless other diagnostics are being produced.
-This allows the use of new `-Wno-' options with old compilers, but if
-something goes wrong, the compiler will warn that an unrecognized
-option was used.
-
-`-pedantic'
- Issue all the warnings demanded by strict ISO C and ISO C++;
- reject all programs that use forbidden extensions, and some other
- programs that do not follow ISO C and ISO C++. For ISO C, follows
- the version of the ISO C standard specified by any `-std' option
- used.
-
- Valid ISO C and ISO C++ programs should compile properly with or
- without this option (though a rare few will require `-ansi' or a
- `-std' option specifying the required version of ISO C). However,
- without this option, certain GNU extensions and traditional C and
- C++ features are supported as well. With this option, they are
- rejected.
-
- `-pedantic' does not cause warning messages for use of the
- alternate keywords whose names begin and end with `__'. Pedantic
- warnings are also disabled in the expression that follows
- `__extension__'. However, only system header files should use
- these escape routes; application programs should avoid them.
- *Note Alternate Keywords::.
-
- Some users try to use `-pedantic' to check programs for strict ISO
- C conformance. They soon find that it does not do quite what they
- want: it finds some non-ISO practices, but not all--only those for
- which ISO C _requires_ a diagnostic, and some others for which
- diagnostics have been added.
-
- A feature to report any failure to conform to ISO C might be
- useful in some instances, but would require considerable
- additional work and would be quite different from `-pedantic'. We
- don't have plans to support such a feature in the near future.
-
- Where the standard specified with `-std' represents a GNU extended
- dialect of C, such as `gnu90' or `gnu99', there is a corresponding
- "base standard", the version of ISO C on which the GNU extended
- dialect is based. Warnings from `-pedantic' are given where they
- are required by the base standard. (It would not make sense for
- such warnings to be given only for features not in the specified
- GNU C dialect, since by definition the GNU dialects of C include
- all features the compiler supports with the given option, and
- there would be nothing to warn about.)
-
-`-pedantic-errors'
- Like `-pedantic', except that errors are produced rather than
- warnings.
-
-`-Wall'
- This enables all the warnings about constructions that some users
- consider questionable, and that are easy to avoid (or modify to
- prevent the warning), even in conjunction with macros. This also
- enables some language-specific warnings described in *note C++
- Dialect Options:: and *note Objective-C and Objective-C++ Dialect
- Options::.
-
- `-Wall' turns on the following warning flags:
-
- -Waddress
- -Warray-bounds (only with `-O2')
- -Wc++0x-compat
- -Wchar-subscripts
- -Wenum-compare (in C/Objc; this is on by default in C++)
- -Wimplicit-int (C and Objective-C only)
- -Wimplicit-function-declaration (C and Objective-C only)
- -Wcomment
- -Wformat
- -Wmain (only for C/ObjC and unless `-ffreestanding')
- -Wmaybe-uninitialized
- -Wmissing-braces
- -Wnonnull
- -Wparentheses
- -Wpointer-sign
- -Wreorder
- -Wreturn-type
- -Wripa-opt-mismatch
- -Wsequence-point
- -Wsign-compare (only in C++)
- -Wstrict-aliasing
- -Wstrict-overflow=1
- -Wswitch
- -Wtrigraphs
- -Wuninitialized
- -Wunknown-pragmas
- -Wunused-function
- -Wunused-label
- -Wunused-value
- -Wunused-variable
- -Wvolatile-register-var
-
- Note that some warning flags are not implied by `-Wall'. Some of
- them warn about constructions that users generally do not consider
- questionable, but which occasionally you might wish to check for;
- others warn about constructions that are necessary or hard to
- avoid in some cases, and there is no simple way to modify the code
- to suppress the warning. Some of them are enabled by `-Wextra' but
- many of them must be enabled individually.
-
-`-Wextra'
- This enables some extra warning flags that are not enabled by
- `-Wall'. (This option used to be called `-W'. The older name is
- still supported, but the newer name is more descriptive.)
-
- -Wclobbered
- -Wempty-body
- -Wignored-qualifiers
- -Wmissing-field-initializers
- -Wmissing-parameter-type (C only)
- -Wold-style-declaration (C only)
- -Woverride-init
- -Wsign-compare
- -Wtype-limits
- -Wuninitialized
- -Wunused-parameter (only with `-Wunused' or `-Wall')
- -Wunused-but-set-parameter (only with `-Wunused' or `-Wall')
-
- The option `-Wextra' also prints warning messages for the
- following cases:
-
- * A pointer is compared against integer zero with `<', `<=',
- `>', or `>='.
-
- * (C++ only) An enumerator and a non-enumerator both appear in a
- conditional expression.
-
- * (C++ only) Ambiguous virtual bases.
-
- * (C++ only) Subscripting an array which has been declared
- `register'.
-
- * (C++ only) Taking the address of a variable which has been
- declared `register'.
-
- * (C++ only) A base class is not initialized in a derived
- class' copy constructor.
-
-
-`-Wchar-subscripts'
- Warn if an array subscript has type `char'. This is a common cause
- of error, as programmers often forget that this type is signed on
- some machines. This warning is enabled by `-Wall'.
-
-`-Wcomment'
- Warn whenever a comment-start sequence `/*' appears in a `/*'
- comment, or whenever a Backslash-Newline appears in a `//' comment.
- This warning is enabled by `-Wall'.
-
-`-Wno-cpp'
- (C, Objective-C, C++, Objective-C++ and Fortran only)
-
- Suppress warning messages emitted by `#warning' directives.
-
-`-Wdouble-promotion (C, C++, Objective-C and Objective-C++ only)'
- Give a warning when a value of type `float' is implicitly promoted
- to `double'. CPUs with a 32-bit "single-precision" floating-point
- unit implement `float' in hardware, but emulate `double' in
- software. On such a machine, doing computations using `double'
- values is much more expensive because of the overhead required for
- software emulation.
-
- It is easy to accidentally do computations with `double' because
- floating-point literals are implicitly of type `double'. For
- example, in:
- float area(float radius)
- {
- return 3.14159 * radius * radius;
- }
- the compiler will perform the entire computation with `double'
- because the floating-point literal is a `double'.
-
-`-Wformat'
- Check calls to `printf' and `scanf', etc., to make sure that the
- arguments supplied have types appropriate to the format string
- specified, and that the conversions specified in the format string
- make sense. This includes standard functions, and others
- specified by format attributes (*note Function Attributes::), in
- the `printf', `scanf', `strftime' and `strfmon' (an X/Open
- extension, not in the C standard) families (or other
- target-specific families). Which functions are checked without
- format attributes having been specified depends on the standard
- version selected, and such checks of functions without the
- attribute specified are disabled by `-ffreestanding' or
- `-fno-builtin'.
-
- The formats are checked against the format features supported by
- GNU libc version 2.2. These include all ISO C90 and C99 features,
- as well as features from the Single Unix Specification and some
- BSD and GNU extensions. Other library implementations may not
- support all these features; GCC does not support warning about
- features that go beyond a particular library's limitations.
- However, if `-pedantic' is used with `-Wformat', warnings will be
- given about format features not in the selected standard version
- (but not for `strfmon' formats, since those are not in any version
- of the C standard). *Note Options Controlling C Dialect: C
- Dialect Options.
-
- Since `-Wformat' also checks for null format arguments for several
- functions, `-Wformat' also implies `-Wnonnull'.
-
- `-Wformat' is included in `-Wall'. For more control over some
- aspects of format checking, the options `-Wformat-y2k',
- `-Wno-format-extra-args', `-Wno-format-zero-length',
- `-Wformat-nonliteral', `-Wformat-security', and `-Wformat=2' are
- available, but are not included in `-Wall'.
-
-`-Wformat-y2k'
- If `-Wformat' is specified, also warn about `strftime' formats
- which may yield only a two-digit year.
-
-`-Wno-format-contains-nul'
- If `-Wformat' is specified, do not warn about format strings that
- contain NUL bytes.
-
-`-Wno-format-extra-args'
- If `-Wformat' is specified, do not warn about excess arguments to a
- `printf' or `scanf' format function. The C standard specifies
- that such arguments are ignored.
-
- Where the unused arguments lie between used arguments that are
- specified with `$' operand number specifications, normally
- warnings are still given, since the implementation could not know
- what type to pass to `va_arg' to skip the unused arguments.
- However, in the case of `scanf' formats, this option will suppress
- the warning if the unused arguments are all pointers, since the
- Single Unix Specification says that such unused arguments are
- allowed.
-
-`-Wno-format-zero-length (C and Objective-C only)'
- If `-Wformat' is specified, do not warn about zero-length formats.
- The C standard specifies that zero-length formats are allowed.
-
-`-Wformat-nonliteral'
- If `-Wformat' is specified, also warn if the format string is not a
- string literal and so cannot be checked, unless the format function
- takes its format arguments as a `va_list'.
-
-`-Wformat-security'
- If `-Wformat' is specified, also warn about uses of format
- functions that represent possible security problems. At present,
- this warns about calls to `printf' and `scanf' functions where the
- format string is not a string literal and there are no format
- arguments, as in `printf (foo);'. This may be a security hole if
- the format string came from untrusted input and contains `%n'.
- (This is currently a subset of what `-Wformat-nonliteral' warns
- about, but in future warnings may be added to `-Wformat-security'
- that are not included in `-Wformat-nonliteral'.)
-
-`-Wformat=2'
- Enable `-Wformat' plus format checks not included in `-Wformat'.
- Currently equivalent to `-Wformat -Wformat-nonliteral
- -Wformat-security -Wformat-y2k'.
-
-`-Wnonnull (C, C++, Objective-C, and Objective-C++ only)'
- Warn about passing a null pointer for arguments marked as
- requiring a non-null value by the `nonnull' function attribute.
-
- `-Wnonnull' is included in `-Wall' and `-Wformat'. It can be
- disabled with the `-Wno-nonnull' option.
-
-`-Winit-self (C, C++, Objective-C and Objective-C++ only)'
- Warn about uninitialized variables which are initialized with
- themselves. Note this option can only be used with the
- `-Wuninitialized' option.
-
- For example, GCC will warn about `i' being uninitialized in the
- following snippet only when `-Winit-self' has been specified:
- int f()
- {
- int i = i;
- return i;
- }
-
-`-Wimplicit-int (C and Objective-C only)'
- Warn when a declaration does not specify a type. This warning is
- enabled by `-Wall'.
-
-`-Wimplicit-function-declaration (C and Objective-C only)'
- Give a warning whenever a function is used before being declared.
- In C99 mode (`-std=c99' or `-std=gnu99'), this warning is enabled
- by default and it is made into an error by `-pedantic-errors'.
- This warning is also enabled by `-Wall'.
-
-`-Wimplicit (C and Objective-C only)'
- Same as `-Wimplicit-int' and `-Wimplicit-function-declaration'.
- This warning is enabled by `-Wall'.
-
-`-Wignored-qualifiers (C and C++ only)'
- Warn if the return type of a function has a type qualifier such as
- `const'. For ISO C such a type qualifier has no effect, since the
- value returned by a function is not an lvalue. For C++, the
- warning is only emitted for scalar types or `void'. ISO C
- prohibits qualified `void' return types on function definitions,
- so such return types always receive a warning even without this
- option.
-
- This warning is also enabled by `-Wextra'.
-
-`-Wmain'
- Warn if the type of `main' is suspicious. `main' should be a
- function with external linkage, returning int, taking either zero
- arguments, two, or three arguments of appropriate types. This
- warning is enabled by default in C++ and is enabled by either
- `-Wall' or `-pedantic'.
-
-`-Wmissing-braces'
- Warn if an aggregate or union initializer is not fully bracketed.
- In the following example, the initializer for `a' is not fully
- bracketed, but that for `b' is fully bracketed.
-
- int a[2][2] = { 0, 1, 2, 3 };
- int b[2][2] = { { 0, 1 }, { 2, 3 } };
-
- This warning is enabled by `-Wall'.
-
-`-Wmissing-include-dirs (C, C++, Objective-C and Objective-C++ only)'
- Warn if a user-supplied include directory does not exist.
-
-`-Wparentheses'
- Warn if parentheses are omitted in certain contexts, such as when
- there is an assignment in a context where a truth value is
- expected, or when operators are nested whose precedence people
- often get confused about.
-
- Also warn if a comparison like `x<=y<=z' appears; this is
- equivalent to `(x<=y ? 1 : 0) <= z', which is a different
- interpretation from that of ordinary mathematical notation.
-
- Also warn about constructions where there may be confusion to which
- `if' statement an `else' branch belongs. Here is an example of
- such a case:
-
- {
- if (a)
- if (b)
- foo ();
- else
- bar ();
- }
-
- In C/C++, every `else' branch belongs to the innermost possible
- `if' statement, which in this example is `if (b)'. This is often
- not what the programmer expected, as illustrated in the above
- example by indentation the programmer chose. When there is the
- potential for this confusion, GCC will issue a warning when this
- flag is specified. To eliminate the warning, add explicit braces
- around the innermost `if' statement so there is no way the `else'
- could belong to the enclosing `if'. The resulting code would look
- like this:
-
- {
- if (a)
- {
- if (b)
- foo ();
- else
- bar ();
- }
- }
-
- Also warn for dangerous uses of the ?: with omitted middle operand
- GNU extension. When the condition in the ?: operator is a boolean
- expression the omitted value will be always 1. Often the user
- expects it to be a value computed inside the conditional
- expression instead.
-
- This warning is enabled by `-Wall'.
-
-`-Wsequence-point'
- Warn about code that may have undefined semantics because of
- violations of sequence point rules in the C and C++ standards.
-
- The C and C++ standards defines the order in which expressions in
- a C/C++ program are evaluated in terms of "sequence points", which
- represent a partial ordering between the execution of parts of the
- program: those executed before the sequence point, and those
- executed after it. These occur after the evaluation of a full
- expression (one which is not part of a larger expression), after
- the evaluation of the first operand of a `&&', `||', `? :' or `,'
- (comma) operator, before a function is called (but after the
- evaluation of its arguments and the expression denoting the called
- function), and in certain other places. Other than as expressed
- by the sequence point rules, the order of evaluation of
- subexpressions of an expression is not specified. All these rules
- describe only a partial order rather than a total order, since,
- for example, if two functions are called within one expression
- with no sequence point between them, the order in which the
- functions are called is not specified. However, the standards
- committee have ruled that function calls do not overlap.
-
- It is not specified when between sequence points modifications to
- the values of objects take effect. Programs whose behavior
- depends on this have undefined behavior; the C and C++ standards
- specify that "Between the previous and next sequence point an
- object shall have its stored value modified at most once by the
- evaluation of an expression. Furthermore, the prior value shall
- be read only to determine the value to be stored.". If a program
- breaks these rules, the results on any particular implementation
- are entirely unpredictable.
-
- Examples of code with undefined behavior are `a = a++;', `a[n] =
- b[n++]' and `a[i++] = i;'. Some more complicated cases are not
- diagnosed by this option, and it may give an occasional false
- positive result, but in general it has been found fairly effective
- at detecting this sort of problem in programs.
-
- The standard is worded confusingly, therefore there is some debate
- over the precise meaning of the sequence point rules in subtle
- cases. Links to discussions of the problem, including proposed
- formal definitions, may be found on the GCC readings page, at
- `http://gcc.gnu.org/readings.html'.
-
- This warning is enabled by `-Wall' for C and C++.
-
-`-Wself-assign'
- Warn about self-assignment and self-initialization. This warning
- is intended for detecting accidental self-assignment due to typos,
- and therefore does not warn on a statement that is semantically a
- self-assignment after constant folding. Here is an example of what
- will trigger a self-assign warning and what will not:
-
- void func()
- {
- int i = 2;
- int x = x; /* warn */
- float f = 5.0;
- double a[3];
-
- i = i + 0; /* not warn */
- f = f / 1; /* not warn */
- a[1] = a[1]; /* warn */
- i += 0; /* not warn */
- }
-
- In C++ it will not warn on self-assignment of non-POD variables
- unless `-Wself-assign-non-pod' is also enabled.
-
-`-Wself-assign-non-pod'
- Warn about self-assignment of non-POD variables. This is a
- C++-specific warning and only effective when `-Wself-assign' is
- enabled.
-
- There are cases where self-assignment might be intentional. For
- example, a C++ programmer might write code to test whether an
- overloaded `operator=' works when the same object is assigned to
- itself. One way to work around the self-assign warning in such
- cases when this flag is enabled is using the functional form
- `object.operator=(object)' instead of the assignment form `object
- = object', as shown in the following example.
-
- void test_func()
- {
- MyType t;
-
- t.operator=(t); // not warn
- t = t; // warn
- }
-
-`-Wreturn-type'
- Warn whenever a function is defined with a return-type that
- defaults to `int'. Also warn about any `return' statement with no
- return-value in a function whose return-type is not `void'
- (falling off the end of the function body is considered returning
- without a value), and about a `return' statement with an
- expression in a function whose return-type is `void'.
-
- For C++, a function without return type always produces a
- diagnostic message, even when `-Wno-return-type' is specified.
- The only exceptions are `main' and functions defined in system
- headers.
-
- This warning is enabled by `-Wall'.
-
-`-Wripa-opt-mismatch'
- When doing an FDO build with `-fprofile-use' and `-fripa', warn if
- importing an axuiliary module that was built with a different GCC
- command line during the profile-generate phase than the primary
- module.
-
- This warning is enabled by `-Wall'.
-
-`-Wswitch'
- Warn whenever a `switch' statement has an index of enumerated type
- and lacks a `case' for one or more of the named codes of that
- enumeration. (The presence of a `default' label prevents this
- warning.) `case' labels outside the enumeration range also
- provoke warnings when this option is used (even if there is a
- `default' label). This warning is enabled by `-Wall'.
-
-`-Wswitch-default'
- Warn whenever a `switch' statement does not have a `default' case.
-
-`-Wswitch-enum'
- Warn whenever a `switch' statement has an index of enumerated type
- and lacks a `case' for one or more of the named codes of that
- enumeration. `case' labels outside the enumeration range also
- provoke warnings when this option is used. The only difference
- between `-Wswitch' and this option is that this option gives a
- warning about an omitted enumeration code even if there is a
- `default' label.
-
-`-Wsync-nand (C and C++ only)'
- Warn when `__sync_fetch_and_nand' and `__sync_nand_and_fetch'
- built-in functions are used. These functions changed semantics in
- GCC 4.4.
-
-`-Wthread-safety'
- Warn about potential thread safety issues when the code is
- annotated with thread safety attributes.
-
-`Wthread-unguarded-var'
- Warn about shared variables not properly protected by locks
- specified in the attributes. This flag is effective only with
- `-Wthread-safety' and enabled by default.
-
-`Wthread-unguarded-func'
- Warn about function calls not properly protected by locks
- specified in the attributes. This flag is effective only with
- `-Wthread-safety' and enabled by default.
-
-`Wthread-mismatched-lock-order'
- Warn about lock acquisition order inconsistent with what specified
- in the attributes. This flag is effective only with
- `-Wthread-safety' and enabled by default.
-
-`Wthread-mismatched-lock-acq-rel'
- Warn about mismatched lock acquisition and release. This flag is
- effective only with `-Wthread-safety' and enabled by default.
-
-`Wthread-reentrant-lock'
- Warn about a lock being acquired recursively. This flag is
- effective only with `-Wthread-safety' and enabled by default.
-
-`Wthread-unsupported-lock-name'
- Warn about uses of unsupported lock names in attributes. This flag
- is effective only with `-Wthread-safety' and disabled by default.
-
-`Wthread-attr-bind-param'
- Make the thread safety analysis try to bind the function
- parameters used in the attributes. This flag is effective only
- with `-Wthread-safety' and enabled by default.
-
-`-Wtrigraphs'
- Warn if any trigraphs are encountered that might change the
- meaning of the program (trigraphs within comments are not warned
- about). This warning is enabled by `-Wall'.
-
-`-Wunused-but-set-parameter'
- Warn whenever a function parameter is assigned to, but otherwise
- unused (aside from its declaration).
-
- To suppress this warning use the `unused' attribute (*note
- Variable Attributes::).
-
- This warning is also enabled by `-Wunused' together with `-Wextra'.
-
-`-Wunused-but-set-variable'
- Warn whenever a local variable is assigned to, but otherwise unused
- (aside from its declaration). This warning is enabled by `-Wall'.
-
- To suppress this warning use the `unused' attribute (*note
- Variable Attributes::).
-
- This warning is also enabled by `-Wunused', which is enabled by
- `-Wall'.
-
-`-Wunused-function'
- Warn whenever a static function is declared but not defined or a
- non-inline static function is unused. This warning is enabled by
- `-Wall'.
-
-`-Wunused-label'
- Warn whenever a label is declared but not used. This warning is
- enabled by `-Wall'.
-
- To suppress this warning use the `unused' attribute (*note
- Variable Attributes::).
-
-`-Wunused-parameter'
- Warn whenever a function parameter is unused aside from its
- declaration.
-
- To suppress this warning use the `unused' attribute (*note
- Variable Attributes::).
-
-`-Wno-unused-result'
- Do not warn if a caller of a function marked with attribute
- `warn_unused_result' (*note Variable Attributes::) does not use
- its return value. The default is `-Wunused-result'.
-
-`-Wunused-variable'
- Warn whenever a local variable or non-constant static variable is
- unused aside from its declaration. This warning is enabled by
- `-Wall'.
-
- To suppress this warning use the `unused' attribute (*note
- Variable Attributes::).
-
- Note that a classic way to avoid `-Wunused-variable' warning is
- using `x = x', but that does not work with `-Wself-assign'. Use
- `(void) x' or `static_cast<void>(x)' instead.
-
-`-Wunused-value'
- Warn whenever a statement computes a result that is explicitly not
- used. To suppress this warning cast the unused expression to
- `void'. This includes an expression-statement or the left-hand
- side of a comma expression that contains no side effects. For
- example, an expression such as `x[i,j]' will cause a warning, while
- `x[(void)i,j]' will not.
-
- This warning is enabled by `-Wall'.
-
-`-Wunused'
- All the above `-Wunused' options combined.
-
- In order to get a warning about an unused function parameter, you
- must either specify `-Wextra -Wunused' (note that `-Wall' implies
- `-Wunused'), or separately specify `-Wunused-parameter'.
-
-`-Wuninitialized'
- Warn if an automatic variable is used without first being
- initialized or if a variable may be clobbered by a `setjmp' call.
- In C++, warn if a non-static reference or non-static `const' member
- appears in a class without constructors.
-
- If you want to warn about code which uses the uninitialized value
- of the variable in its own initializer, use the `-Winit-self'
- option.
-
- These warnings occur for individual uninitialized or clobbered
- elements of structure, union or array variables as well as for
- variables which are uninitialized or clobbered as a whole. They do
- not occur for variables or elements declared `volatile'. Because
- these warnings depend on optimization, the exact variables or
- elements for which there are warnings will depend on the precise
- optimization options and version of GCC used.
-
- Note that there may be no warning about a variable that is used
- only to compute a value that itself is never used, because such
- computations may be deleted by data flow analysis before the
- warnings are printed.
-
-`-Wmaybe-uninitialized'
- For an automatic variable, if there exists a path from the function
- entry to a use of the variable that is initialized, but there exist
- some other paths the variable is not initialized, the compiler will
- emit a warning if it can not prove the uninitialized paths do not
- happen at runtime. These warnings are made optional because GCC is
- not smart enough to see all the reasons why the code might be
- correct despite appearing to have an error. Here is one example
- of how this can happen:
-
- {
- int x;
- switch (y)
- {
- case 1: x = 1;
- break;
- case 2: x = 4;
- break;
- case 3: x = 5;
- }
- foo (x);
- }
-
- If the value of `y' is always 1, 2 or 3, then `x' is always
- initialized, but GCC doesn't know this. To suppress the warning,
- the user needs to provide a default case with assert(0) or similar
- code.
-
- This option also warns when a non-volatile automatic variable
- might be changed by a call to `longjmp'. These warnings as well
- are possible only in optimizing compilation.
-
- The compiler sees only the calls to `setjmp'. It cannot know
- where `longjmp' will be called; in fact, a signal handler could
- call it at any point in the code. As a result, you may get a
- warning even when there is in fact no problem because `longjmp'
- cannot in fact be called at the place which would cause a problem.
-
- Some spurious warnings can be avoided if you declare all the
- functions you use that never return as `noreturn'. *Note Function
- Attributes::.
-
- This warning is enabled by `-Wall' or `-Wextra'.
-
-`-Wunknown-pragmas'
- Warn when a #pragma directive is encountered which is not
- understood by GCC. If this command line option is used, warnings
- will even be issued for unknown pragmas in system header files.
- This is not the case if the warnings were only enabled by the
- `-Wall' command line option.
-
-`-Wno-pragmas'
- Do not warn about misuses of pragmas, such as incorrect parameters,
- invalid syntax, or conflicts between pragmas. See also
- `-Wunknown-pragmas'.
-
-`-Wstrict-aliasing'
- This option is only active when `-fstrict-aliasing' is active. It
- warns about code which might break the strict aliasing rules that
- the compiler is using for optimization. The warning does not
- catch all cases, but does attempt to catch the more common
- pitfalls. It is included in `-Wall'. It is equivalent to
- `-Wstrict-aliasing=3'
-
-`-Wstrict-aliasing=n'
- This option is only active when `-fstrict-aliasing' is active. It
- warns about code which might break the strict aliasing rules that
- the compiler is using for optimization. Higher levels correspond
- to higher accuracy (fewer false positives). Higher levels also
- correspond to more effort, similar to the way -O works.
- `-Wstrict-aliasing' is equivalent to `-Wstrict-aliasing=n', with
- n=3.
-
- Level 1: Most aggressive, quick, least accurate. Possibly useful
- when higher levels do not warn but -fstrict-aliasing still breaks
- the code, as it has very few false negatives. However, it has
- many false positives. Warns for all pointer conversions between
- possibly incompatible types, even if never dereferenced. Runs in
- the frontend only.
-
- Level 2: Aggressive, quick, not too precise. May still have many
- false positives (not as many as level 1 though), and few false
- negatives (but possibly more than level 1). Unlike level 1, it
- only warns when an address is taken. Warns about incomplete
- types. Runs in the frontend only.
-
- Level 3 (default for `-Wstrict-aliasing'): Should have very few
- false positives and few false negatives. Slightly slower than
- levels 1 or 2 when optimization is enabled. Takes care of the
- common pun+dereference pattern in the frontend:
- `*(int*)&some_float'. If optimization is enabled, it also runs in
- the backend, where it deals with multiple statement cases using
- flow-sensitive points-to information. Only warns when the
- converted pointer is dereferenced. Does not warn about incomplete
- types.
-
-`-Wstrict-overflow'
-`-Wstrict-overflow=N'
- This option is only active when `-fstrict-overflow' is active. It
- warns about cases where the compiler optimizes based on the
- assumption that signed overflow does not occur. Note that it does
- not warn about all cases where the code might overflow: it only
- warns about cases where the compiler implements some optimization.
- Thus this warning depends on the optimization level.
-
- An optimization which assumes that signed overflow does not occur
- is perfectly safe if the values of the variables involved are such
- that overflow never does, in fact, occur. Therefore this warning
- can easily give a false positive: a warning about code which is not
- actually a problem. To help focus on important issues, several
- warning levels are defined. No warnings are issued for the use of
- undefined signed overflow when estimating how many iterations a
- loop will require, in particular when determining whether a loop
- will be executed at all.
-
- `-Wstrict-overflow=1'
- Warn about cases which are both questionable and easy to
- avoid. For example: `x + 1 > x'; with `-fstrict-overflow',
- the compiler will simplify this to `1'. This level of
- `-Wstrict-overflow' is enabled by `-Wall'; higher levels are
- not, and must be explicitly requested.
-
- `-Wstrict-overflow=2'
- Also warn about other cases where a comparison is simplified
- to a constant. For example: `abs (x) >= 0'. This can only be
- simplified when `-fstrict-overflow' is in effect, because
- `abs (INT_MIN)' overflows to `INT_MIN', which is less than
- zero. `-Wstrict-overflow' (with no level) is the same as
- `-Wstrict-overflow=2'.
-
- `-Wstrict-overflow=3'
- Also warn about other cases where a comparison is simplified.
- For example: `x + 1 > 1' will be simplified to `x > 0'.
-
- `-Wstrict-overflow=4'
- Also warn about other simplifications not covered by the
- above cases. For example: `(x * 10) / 5' will be simplified
- to `x * 2'.
-
- `-Wstrict-overflow=5'
- Also warn about cases where the compiler reduces the
- magnitude of a constant involved in a comparison. For
- example: `x + 2 > y' will be simplified to `x + 1 >= y'.
- This is reported only at the highest warning level because
- this simplification applies to many comparisons, so this
- warning level will give a very large number of false
- positives.
-
-`-Wsuggest-attribute=[pure|const|noreturn]'
- Warn for cases where adding an attribute may be beneficial. The
- attributes currently supported are listed below.
-
- `-Wsuggest-attribute=pure'
- `-Wsuggest-attribute=const'
- `-Wsuggest-attribute=noreturn'
- Warn about functions which might be candidates for attributes
- `pure', `const' or `noreturn'. The compiler only warns for
- functions visible in other compilation units or (in the case
- of `pure' and `const') if it cannot prove that the function
- returns normally. A function returns normally if it doesn't
- contain an infinite loop nor returns abnormally by throwing,
- calling `abort()' or trapping. This analysis requires option
- `-fipa-pure-const', which is enabled by default at `-O' and
- higher. Higher optimization levels improve the accuracy of
- the analysis.
-
-`-Warray-bounds'
- This option is only active when `-ftree-vrp' is active (default
- for `-O2' and above). It warns about subscripts to arrays that are
- always out of bounds. This warning is enabled by `-Wall'.
-
-`-Wno-div-by-zero'
- Do not warn about compile-time integer division by zero. Floating
- point division by zero is not warned about, as it can be a
- legitimate way of obtaining infinities and NaNs.
-
-`-Wsystem-headers'
- Print warning messages for constructs found in system header files.
- Warnings from system headers are normally suppressed, on the
- assumption that they usually do not indicate real problems and
- would only make the compiler output harder to read. Using this
- command line option tells GCC to emit warnings from system headers
- as if they occurred in user code. However, note that using
- `-Wall' in conjunction with this option will _not_ warn about
- unknown pragmas in system headers--for that, `-Wunknown-pragmas'
- must also be used.
-
-`-Wtrampolines'
- Warn about trampolines generated for pointers to nested functions.
-
- A trampoline is a small piece of data or code that is created at
- run time on the stack when the address of a nested function is
- taken, and is used to call the nested function indirectly. For
- some targets, it is made up of data only and thus requires no
- special treatment. But, for most targets, it is made up of code
- and thus requires the stack to be made executable in order for
- the program to work properly.
-
-`-Wfloat-equal'
- Warn if floating point values are used in equality comparisons.
-
- The idea behind this is that sometimes it is convenient (for the
- programmer) to consider floating-point values as approximations to
- infinitely precise real numbers. If you are doing this, then you
- need to compute (by analyzing the code, or in some other way) the
- maximum or likely maximum error that the computation introduces,
- and allow for it when performing comparisons (and when producing
- output, but that's a different problem). In particular, instead
- of testing for equality, you would check to see whether the two
- values have ranges that overlap; and this is done with the
- relational operators, so equality comparisons are probably
- mistaken.
-
-`-Wtraditional (C and Objective-C only)'
- Warn about certain constructs that behave differently in
- traditional and ISO C. Also warn about ISO C constructs that have
- no traditional C equivalent, and/or problematic constructs which
- should be avoided.
-
- * Macro parameters that appear within string literals in the
- macro body. In traditional C macro replacement takes place
- within string literals, but does not in ISO C.
-
- * In traditional C, some preprocessor directives did not exist.
- Traditional preprocessors would only consider a line to be a
- directive if the `#' appeared in column 1 on the line.
- Therefore `-Wtraditional' warns about directives that
- traditional C understands but would ignore because the `#'
- does not appear as the first character on the line. It also
- suggests you hide directives like `#pragma' not understood by
- traditional C by indenting them. Some traditional
- implementations would not recognize `#elif', so it suggests
- avoiding it altogether.
-
- * A function-like macro that appears without arguments.
-
- * The unary plus operator.
-
- * The `U' integer constant suffix, or the `F' or `L' floating
- point constant suffixes. (Traditional C does support the `L'
- suffix on integer constants.) Note, these suffixes appear in
- macros defined in the system headers of most modern systems,
- e.g. the `_MIN'/`_MAX' macros in `<limits.h>'. Use of these
- macros in user code might normally lead to spurious warnings,
- however GCC's integrated preprocessor has enough context to
- avoid warning in these cases.
-
- * A function declared external in one block and then used after
- the end of the block.
-
- * A `switch' statement has an operand of type `long'.
-
- * A non-`static' function declaration follows a `static' one.
- This construct is not accepted by some traditional C
- compilers.
-
- * The ISO type of an integer constant has a different width or
- signedness from its traditional type. This warning is only
- issued if the base of the constant is ten. I.e. hexadecimal
- or octal values, which typically represent bit patterns, are
- not warned about.
-
- * Usage of ISO string concatenation is detected.
-
- * Initialization of automatic aggregates.
-
- * Identifier conflicts with labels. Traditional C lacks a
- separate namespace for labels.
-
- * Initialization of unions. If the initializer is zero, the
- warning is omitted. This is done under the assumption that
- the zero initializer in user code appears conditioned on e.g.
- `__STDC__' to avoid missing initializer warnings and relies
- on default initialization to zero in the traditional C case.
-
- * Conversions by prototypes between fixed/floating point values
- and vice versa. The absence of these prototypes when
- compiling with traditional C would cause serious problems.
- This is a subset of the possible conversion warnings, for the
- full set use `-Wtraditional-conversion'.
-
- * Use of ISO C style function definitions. This warning
- intentionally is _not_ issued for prototype declarations or
- variadic functions because these ISO C features will appear
- in your code when using libiberty's traditional C
- compatibility macros, `PARAMS' and `VPARAMS'. This warning
- is also bypassed for nested functions because that feature is
- already a GCC extension and thus not relevant to traditional
- C compatibility.
-
-`-Wtraditional-conversion (C and Objective-C only)'
- Warn if a prototype causes a type conversion that is different
- from what would happen to the same argument in the absence of a
- prototype. This includes conversions of fixed point to floating
- and vice versa, and conversions changing the width or signedness
- of a fixed point argument except when the same as the default
- promotion.
-
-`-Wdeclaration-after-statement (C and Objective-C only)'
- Warn when a declaration is found after a statement in a block.
- This construct, known from C++, was introduced with ISO C99 and is
- by default allowed in GCC. It is not supported by ISO C90 and was
- not supported by GCC versions before GCC 3.0. *Note Mixed
- Declarations::.
-
-`-Wundef'
- Warn if an undefined identifier is evaluated in an `#if' directive.
-
-`-Wno-endif-labels'
- Do not warn whenever an `#else' or an `#endif' are followed by
- text.
-
-`-Wshadow'
- Warn whenever a local variable or type declaration shadows another
- variable, parameter, type, or class member (in C++), or whenever a
- built-in function is shadowed. Note that in C++, the compiler will
- not warn if a local variable shadows a struct/class/enum, but will
- warn if it shadows an explicit typedef.
-
-`-Wshadow-local'
- Warn when a local variable shadows another local variable or
- parameter.
-
-`-Wshadow-compatible-local'
- Warn when a local variable shadows another local variable or
- parameter whose type is compatible with that of the shadowing
- variable. In C++, type compatibility here means the type of the
- shadowing variable can be converted to that of the shadowed
- variable. The creation of this flag (in addition to
- `-Wshadow-local') is based on the idea that when a local variable
- shadows another one of incompatible type, it is most likely
- intentional, not a bug or typo, as shown in the following example:
-
- for (SomeIterator i = SomeObj.begin(); i != SomeObj.end(); ++i)
- {
- for (int i = 0; i < N; ++i)
- {
- ...
- }
- ...
- }
-
- Since the two variable `i' in the example above have incompatible
- types, enabling only `-Wshadow-compatible-local' will not emit a
- warning. Because their types are incompatible, if a programmer
- accidentally uses one in place of the other, type checking will
- catch that and emit an error or warning. So not warning (about
- shadowing) in this case will not lead to undetected bugs. Use of
- this flag instead of `-Wshadow-local' can possibly reduce the
- number of warnings triggered by intentional shadowing.
-
-`-Wlarger-than=LEN'
- Warn whenever an object of larger than LEN bytes is defined.
-
-`-Wframe-larger-than=LEN'
- Warn if the size of a function frame is larger than LEN bytes.
- The computation done to determine the stack frame size is
- approximate and not conservative. The actual requirements may be
- somewhat greater than LEN even if you do not get a warning. In
- addition, any space allocated via `alloca', variable-length
- arrays, or related constructs is not included by the compiler when
- determining whether or not to issue a warning.
-
-`-Wunsafe-loop-optimizations'
- Warn if the loop cannot be optimized because the compiler could not
- assume anything on the bounds of the loop indices. With
- `-funsafe-loop-optimizations' warn if the compiler made such
- assumptions.
-
-`-Wno-pedantic-ms-format (MinGW targets only)'
- Disables the warnings about non-ISO `printf' / `scanf' format
- width specifiers `I32', `I64', and `I' used on Windows targets
- depending on the MS runtime, when you are using the options
- `-Wformat' and `-pedantic' without gnu-extensions.
-
-`-Wpointer-arith'
- Warn about anything that depends on the "size of" a function type
- or of `void'. GNU C assigns these types a size of 1, for
- convenience in calculations with `void *' pointers and pointers to
- functions. In C++, warn also when an arithmetic operation involves
- `NULL'. This warning is also enabled by `-pedantic'.
-
-`-Wtype-limits'
- Warn if a comparison is always true or always false due to the
- limited range of the data type, but do not warn for constant
- expressions. For example, warn if an unsigned variable is
- compared against zero with `<' or `>='. This warning is also
- enabled by `-Wextra'.
-
-`-Wbad-function-cast (C and Objective-C only)'
- Warn whenever a function call is cast to a non-matching type. For
- example, warn if `int malloc()' is cast to `anything *'.
-
-`-Wc++-compat (C and Objective-C only)'
- Warn about ISO C constructs that are outside of the common subset
- of ISO C and ISO C++, e.g. request for implicit conversion from
- `void *' to a pointer to non-`void' type.
-
-`-Wc++0x-compat (C++ and Objective-C++ only)'
- Warn about C++ constructs whose meaning differs between ISO C++
- 1998 and ISO C++ 200x, e.g., identifiers in ISO C++ 1998 that will
- become keywords in ISO C++ 200x. This warning is enabled by
- `-Wall'.
-
-`-Wcast-qual'
- Warn whenever a pointer is cast so as to remove a type qualifier
- from the target type. For example, warn if a `const char *' is
- cast to an ordinary `char *'.
-
- Also warn when making a cast which introduces a type qualifier in
- an unsafe way. For example, casting `char **' to `const char **'
- is unsafe, as in this example:
-
- /* p is char ** value. */
- const char **q = (const char **) p;
- /* Assignment of readonly string to const char * is OK. */
- *q = "string";
- /* Now char** pointer points to read-only memory. */
- **p = 'b';
-
-`-Wcast-align'
- Warn whenever a pointer is cast such that the required alignment
- of the target is increased. For example, warn if a `char *' is
- cast to an `int *' on machines where integers can only be accessed
- at two- or four-byte boundaries.
-
-`-Wwrite-strings'
- When compiling C, give string constants the type `const
- char[LENGTH]' so that copying the address of one into a
- non-`const' `char *' pointer will get a warning. These warnings
- will help you find at compile time code that can try to write into
- a string constant, but only if you have been very careful about
- using `const' in declarations and prototypes. Otherwise, it will
- just be a nuisance. This is why we did not make `-Wall' request
- these warnings.
-
- When compiling C++, warn about the deprecated conversion from
- string literals to `char *'. This warning is enabled by default
- for C++ programs.
-
-`-Wclobbered'
- Warn for variables that might be changed by `longjmp' or `vfork'.
- This warning is also enabled by `-Wextra'.
-
-`-Wconversion'
- Warn for implicit conversions that may alter a value. This includes
- conversions between real and integer, like `abs (x)' when `x' is
- `double'; conversions between signed and unsigned, like `unsigned
- ui = -1'; and conversions to smaller types, like `sqrtf (M_PI)'.
- Do not warn for explicit casts like `abs ((int) x)' and `ui =
- (unsigned) -1', or if the value is not changed by the conversion
- like in `abs (2.0)'. Warnings about conversions between signed
- and unsigned integers can be disabled by using
- `-Wno-sign-conversion'.
-
- For C++, also warn for confusing overload resolution for
- user-defined conversions; and conversions that will never use a
- type conversion operator: conversions to `void', the same type, a
- base class or a reference to them. Warnings about conversions
- between signed and unsigned integers are disabled by default in
- C++ unless `-Wsign-conversion' is explicitly enabled.
-
-`-Wno-conversion-null (C++ and Objective-C++ only)'
- Do not warn for conversions between `NULL' and non-pointer types.
- `-Wconversion-null' is enabled by default.
-
-`-Wreal-conversion'
- Warn for implicit type conversions from real (`double' or `float')
- to integral values.
-
-`-Wempty-body'
- Warn if an empty body occurs in an `if', `else' or `do while'
- statement. This warning is also enabled by `-Wextra'.
-
-`-Wenum-compare'
- Warn about a comparison between values of different enum types. In
- C++ this warning is enabled by default. In C this warning is
- enabled by `-Wall'.
-
-`-Wjump-misses-init (C, Objective-C only)'
- Warn if a `goto' statement or a `switch' statement jumps forward
- across the initialization of a variable, or jumps backward to a
- label after the variable has been initialized. This only warns
- about variables which are initialized when they are declared.
- This warning is only supported for C and Objective C; in C++ this
- sort of branch is an error in any case.
-
- `-Wjump-misses-init' is included in `-Wc++-compat'. It can be
- disabled with the `-Wno-jump-misses-init' option.
-
-`-Wsign-compare'
- Warn when a comparison between signed and unsigned values could
- produce an incorrect result when the signed value is converted to
- unsigned. This warning is also enabled by `-Wextra'; to get the
- other warnings of `-Wextra' without this warning, use `-Wextra
- -Wno-sign-compare'.
-
-`-Wsign-conversion'
- Warn for implicit conversions that may change the sign of an
- integer value, like assigning a signed integer expression to an
- unsigned integer variable. An explicit cast silences the warning.
- In C, this option is enabled also by `-Wconversion'.
-
-`-Waddress'
- Warn about suspicious uses of memory addresses. These include using
- the address of a function in a conditional expression, such as
- `void func(void); if (func)', and comparisons against the memory
- address of a string literal, such as `if (x == "abc")'. Such uses
- typically indicate a programmer error: the address of a function
- always evaluates to true, so their use in a conditional usually
- indicate that the programmer forgot the parentheses in a function
- call; and comparisons against string literals result in unspecified
- behavior and are not portable in C, so they usually indicate that
- the programmer intended to use `strcmp'. This warning is enabled
- by `-Wall'.
-
-`-Wlogical-op'
- Warn about suspicious uses of logical operators in expressions.
- This includes using logical operators in contexts where a bit-wise
- operator is likely to be expected.
-
-`-Waggregate-return'
- Warn if any functions that return structures or unions are defined
- or called. (In languages where you can return an array, this also
- elicits a warning.)
-
-`-Wno-attributes'
- Do not warn if an unexpected `__attribute__' is used, such as
- unrecognized attributes, function attributes applied to variables,
- etc. This will not stop errors for incorrect use of supported
- attributes.
-
-`-Wno-builtin-macro-redefined'
- Do not warn if certain built-in macros are redefined. This
- suppresses warnings for redefinition of `__TIMESTAMP__',
- `__TIME__', `__DATE__', `__FILE__', and `__BASE_FILE__'.
-
-`-Wstrict-prototypes (C and Objective-C only)'
- Warn if a function is declared or defined without specifying the
- argument types. (An old-style function definition is permitted
- without a warning if preceded by a declaration which specifies the
- argument types.)
-
-`-Wold-style-declaration (C and Objective-C only)'
- Warn for obsolescent usages, according to the C Standard, in a
- declaration. For example, warn if storage-class specifiers like
- `static' are not the first things in a declaration. This warning
- is also enabled by `-Wextra'.
-
-`-Wold-style-definition (C and Objective-C only)'
- Warn if an old-style function definition is used. A warning is
- given even if there is a previous prototype.
-
-`-Wmissing-parameter-type (C and Objective-C only)'
- A function parameter is declared without a type specifier in
- K&R-style functions:
-
- void foo(bar) { }
-
- This warning is also enabled by `-Wextra'.
-
-`-Wmissing-prototypes (C and Objective-C only)'
- Warn if a global function is defined without a previous prototype
- declaration. This warning is issued even if the definition itself
- provides a prototype. The aim is to detect global functions that
- fail to be declared in header files.
-
-`-Wmissing-declarations'
- Warn if a global function is defined without a previous
- declaration. Do so even if the definition itself provides a
- prototype. Use this option to detect global functions that are
- not declared in header files. In C++, no warnings are issued for
- function templates, or for inline functions, or for functions in
- anonymous namespaces.
-
-`-Wmissing-field-initializers'
- Warn if a structure's initializer has some fields missing. For
- example, the following code would cause such a warning, because
- `x.h' is implicitly zero:
-
- struct s { int f, g, h; };
- struct s x = { 3, 4 };
-
- This option does not warn about designated initializers, so the
- following modification would not trigger a warning:
-
- struct s { int f, g, h; };
- struct s x = { .f = 3, .g = 4 };
-
- This warning is included in `-Wextra'. To get other `-Wextra'
- warnings without this one, use `-Wextra
- -Wno-missing-field-initializers'.
-
-`-Wmissing-format-attribute'
- Warn about function pointers which might be candidates for `format'
- attributes. Note these are only possible candidates, not absolute
- ones. GCC will guess that function pointers with `format'
- attributes that are used in assignment, initialization, parameter
- passing or return statements should have a corresponding `format'
- attribute in the resulting type. I.e. the left-hand side of the
- assignment or initialization, the type of the parameter variable,
- or the return type of the containing function respectively should
- also have a `format' attribute to avoid the warning.
-
- GCC will also warn about function definitions which might be
- candidates for `format' attributes. Again, these are only
- possible candidates. GCC will guess that `format' attributes
- might be appropriate for any function that calls a function like
- `vprintf' or `vscanf', but this might not always be the case, and
- some functions for which `format' attributes are appropriate may
- not be detected.
-
-`-Wno-multichar'
- Do not warn if a multicharacter constant (`'FOOF'') is used.
- Usually they indicate a typo in the user's code, as they have
- implementation-defined values, and should not be used in portable
- code.
-
-`-Wnormalized=<none|id|nfc|nfkc>'
- In ISO C and ISO C++, two identifiers are different if they are
- different sequences of characters. However, sometimes when
- characters outside the basic ASCII character set are used, you can
- have two different character sequences that look the same. To
- avoid confusion, the ISO 10646 standard sets out some
- "normalization rules" which when applied ensure that two sequences
- that look the same are turned into the same sequence. GCC can
- warn you if you are using identifiers which have not been
- normalized; this option controls that warning.
-
- There are four levels of warning that GCC supports. The default is
- `-Wnormalized=nfc', which warns about any identifier which is not
- in the ISO 10646 "C" normalized form, "NFC". NFC is the
- recommended form for most uses.
-
- Unfortunately, there are some characters which ISO C and ISO C++
- allow in identifiers that when turned into NFC aren't allowable as
- identifiers. That is, there's no way to use these symbols in
- portable ISO C or C++ and have all your identifiers in NFC.
- `-Wnormalized=id' suppresses the warning for these characters. It
- is hoped that future versions of the standards involved will
- correct this, which is why this option is not the default.
-
- You can switch the warning off for all characters by writing
- `-Wnormalized=none'. You would only want to do this if you were
- using some other normalization scheme (like "D"), because
- otherwise you can easily create bugs that are literally impossible
- to see.
-
- Some characters in ISO 10646 have distinct meanings but look
- identical in some fonts or display methodologies, especially once
- formatting has been applied. For instance `\u207F', "SUPERSCRIPT
- LATIN SMALL LETTER N", will display just like a regular `n' which
- has been placed in a superscript. ISO 10646 defines the "NFKC"
- normalization scheme to convert all these into a standard form as
- well, and GCC will warn if your code is not in NFKC if you use
- `-Wnormalized=nfkc'. This warning is comparable to warning about
- every identifier that contains the letter O because it might be
- confused with the digit 0, and so is not the default, but may be
- useful as a local coding convention if the programming environment
- is unable to be fixed to display these characters distinctly.
-
-`-Wno-deprecated'
- Do not warn about usage of deprecated features. *Note Deprecated
- Features::.
-
-`-Wno-deprecated-declarations'
- Do not warn about uses of functions (*note Function Attributes::),
- variables (*note Variable Attributes::), and types (*note Type
- Attributes::) marked as deprecated by using the `deprecated'
- attribute.
-
-`-Wno-overflow'
- Do not warn about compile-time overflow in constant expressions.
-
-`-Woverride-init (C and Objective-C only)'
- Warn if an initialized field without side effects is overridden
- when using designated initializers (*note Designated Initializers:
- Designated Inits.).
-
- This warning is included in `-Wextra'. To get other `-Wextra'
- warnings without this one, use `-Wextra -Wno-override-init'.
-
-`-Wpacked'
- Warn if a structure is given the packed attribute, but the packed
- attribute has no effect on the layout or size of the structure.
- Such structures may be mis-aligned for little benefit. For
- instance, in this code, the variable `f.x' in `struct bar' will be
- misaligned even though `struct bar' does not itself have the
- packed attribute:
-
- struct foo {
- int x;
- char a, b, c, d;
- } __attribute__((packed));
- struct bar {
- char z;
- struct foo f;
- };
-
-`-Wpacked-bitfield-compat'
- The 4.1, 4.2 and 4.3 series of GCC ignore the `packed' attribute
- on bit-fields of type `char'. This has been fixed in GCC 4.4 but
- the change can lead to differences in the structure layout. GCC
- informs you when the offset of such a field has changed in GCC 4.4.
- For example there is no longer a 4-bit padding between field `a'
- and `b' in this structure:
-
- struct foo
- {
- char a:4;
- char b:8;
- } __attribute__ ((packed));
-
- This warning is enabled by default. Use
- `-Wno-packed-bitfield-compat' to disable this warning.
-
-`-Wpadded'
- Warn if padding is included in a structure, either to align an
- element of the structure or to align the whole structure.
- Sometimes when this happens it is possible to rearrange the fields
- of the structure to reduce the padding and so make the structure
- smaller.
-
-`-Wredundant-decls'
- Warn if anything is declared more than once in the same scope,
- even in cases where multiple declaration is valid and changes
- nothing.
-
-`-Wnested-externs (C and Objective-C only)'
- Warn if an `extern' declaration is encountered within a function.
-
-`-Winline'
- Warn if a function can not be inlined and it was declared as
- inline. Even with this option, the compiler will not warn about
- failures to inline functions declared in system headers.
-
- The compiler uses a variety of heuristics to determine whether or
- not to inline a function. For example, the compiler takes into
- account the size of the function being inlined and the amount of
- inlining that has already been done in the current function.
- Therefore, seemingly insignificant changes in the source program
- can cause the warnings produced by `-Winline' to appear or
- disappear.
-
-`-Wno-invalid-offsetof (C++ and Objective-C++ only)'
- Suppress warnings from applying the `offsetof' macro to a non-POD
- type. According to the 1998 ISO C++ standard, applying `offsetof'
- to a non-POD type is undefined. In existing C++ implementations,
- however, `offsetof' typically gives meaningful results even when
- applied to certain kinds of non-POD types. (Such as a simple
- `struct' that fails to be a POD type only by virtue of having a
- constructor.) This flag is for users who are aware that they are
- writing nonportable code and who have deliberately chosen to
- ignore the warning about it.
-
- The restrictions on `offsetof' may be relaxed in a future version
- of the C++ standard.
-
-`-Wno-int-to-pointer-cast'
- Suppress warnings from casts to pointer type of an integer of a
- different size. In C++, casting to a pointer type of smaller size
- is an error. `Wint-to-pointer-cast' is enabled by default.
-
-`max-lipo-mem'
- When importing auxiliary modules during profile-use, check current
- memory consumption after parsing each auxiliary module. If it
- exceeds this limit (specified in kb), don't import any more
- auxiliary modules. Specifying a value of 0 means don't enforce
- this limit. This parameter is only useful when using
- `-fprofile-use' and `-fripa'.
-
-`-Wno-pointer-to-int-cast (C and Objective-C only)'
- Suppress warnings from casts from a pointer to an integer type of a
- different size.
-
-`-Winvalid-pch'
- Warn if a precompiled header (*note Precompiled Headers::) is
- found in the search path but can't be used.
-
-`-Wlong-long'
- Warn if `long long' type is used. This is enabled by either
- `-pedantic' or `-Wtraditional' in ISO C90 and C++98 modes. To
- inhibit the warning messages, use `-Wno-long-long'.
-
-`-Wvariadic-macros'
- Warn if variadic macros are used in pedantic ISO C90 mode, or the
- GNU alternate syntax when in pedantic ISO C99 mode. This is
- default. To inhibit the warning messages, use
- `-Wno-variadic-macros'.
-
-`-Wvla'
- Warn if variable length array is used in the code. `-Wno-vla'
- will prevent the `-pedantic' warning of the variable length array.
-
-`-Wvolatile-register-var'
- Warn if a register variable is declared volatile. The volatile
- modifier does not inhibit all optimizations that may eliminate
- reads and/or writes to register variables. This warning is
- enabled by `-Wall'.
-
-`-Wdisabled-optimization'
- Warn if a requested optimization pass is disabled. This warning
- does not generally indicate that there is anything wrong with your
- code; it merely indicates that GCC's optimizers were unable to
- handle the code effectively. Often, the problem is that your code
- is too big or too complex; GCC will refuse to optimize programs
- when the optimization itself is likely to take inordinate amounts
- of time.
-
-`-Wpointer-sign (C and Objective-C only)'
- Warn for pointer argument passing or assignment with different
- signedness. This option is only supported for C and Objective-C.
- It is implied by `-Wall' and by `-pedantic', which can be disabled
- with `-Wno-pointer-sign'.
-
-`-Wstack-protector'
- This option is only active when `-fstack-protector' is active. It
- warns about functions that will not be protected against stack
- smashing.
-
-`-Wno-mudflap'
- Suppress warnings about constructs that cannot be instrumented by
- `-fmudflap'.
-
-`-Woverlength-strings'
- Warn about string constants which are longer than the "minimum
- maximum" length specified in the C standard. Modern compilers
- generally allow string constants which are much longer than the
- standard's minimum limit, but very portable programs should avoid
- using longer strings.
-
- The limit applies _after_ string constant concatenation, and does
- not count the trailing NUL. In C90, the limit was 509 characters;
- in C99, it was raised to 4095. C++98 does not specify a normative
- minimum maximum, so we do not diagnose overlength strings in C++.
-
- This option is implied by `-pedantic', and can be disabled with
- `-Wno-overlength-strings'.
-
-`-Wunsuffixed-float-constants (C and Objective-C only)'
- GCC will issue a warning for any floating constant that does not
- have a suffix. When used together with `-Wsystem-headers' it will
- warn about such constants in system header files. This can be
- useful when preparing code to use with the `FLOAT_CONST_DECIMAL64'
- pragma from the decimal floating-point extension to C99.
-
-
-File: gcc.info, Node: Debugging Options, Next: Optimize Options, Prev: Warning Options, Up: Invoking GCC
-
-3.9 Options for Debugging Your Program or GCC
-=============================================
-
-GCC has various special options that are used for debugging either your
-program or GCC:
-
-`-g'
- Produce debugging information in the operating system's native
- format (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this
- debugging information.
-
- On most systems that use stabs format, `-g' enables use of extra
- debugging information that only GDB can use; this extra information
- makes debugging work better in GDB but will probably make other
- debuggers crash or refuse to read the program. If you want to
- control for certain whether to generate the extra information, use
- `-gstabs+', `-gstabs', `-gxcoff+', `-gxcoff', or `-gvms' (see
- below).
-
- GCC allows you to use `-g' with `-O'. The shortcuts taken by
- optimized code may occasionally produce surprising results: some
- variables you declared may not exist at all; flow of control may
- briefly move where you did not expect it; some statements may not
- be executed because they compute constant results or their values
- were already at hand; some statements may execute in different
- places because they were moved out of loops.
-
- Nevertheless it proves possible to debug optimized output. This
- makes it reasonable to use the optimizer for programs that might
- have bugs.
-
- The following options are useful when GCC is generated with the
- capability for more than one debugging format.
-
-`-ggdb'
- Produce debugging information for use by GDB. This means to use
- the most expressive format available (DWARF 2, stabs, or the
- native format if neither of those are supported), including GDB
- extensions if at all possible.
-
-`-gstabs'
- Produce debugging information in stabs format (if that is
- supported), without GDB extensions. This is the format used by
- DBX on most BSD systems. On MIPS, Alpha and System V Release 4
- systems this option produces stabs debugging output which is not
- understood by DBX or SDB. On System V Release 4 systems this
- option requires the GNU assembler.
-
-`-feliminate-unused-debug-symbols'
- Produce debugging information in stabs format (if that is
- supported), for only symbols that are actually used.
-
-`-femit-class-debug-always'
- Instead of emitting debugging information for a C++ class in only
- one object file, emit it in all object files using the class.
- This option should be used only with debuggers that are unable to
- handle the way GCC normally emits debugging information for
- classes because using this option will increase the size of
- debugging information by as much as a factor of two.
-
-`-gstabs+'
- Produce debugging information in stabs format (if that is
- supported), using GNU extensions understood only by the GNU
- debugger (GDB). The use of these extensions is likely to make
- other debuggers crash or refuse to read the program.
-
-`-gcoff'
- Produce debugging information in COFF format (if that is
- supported). This is the format used by SDB on most System V
- systems prior to System V Release 4.
-
-`-gxcoff'
- Produce debugging information in XCOFF format (if that is
- supported). This is the format used by the DBX debugger on IBM
- RS/6000 systems.
-
-`-gxcoff+'
- Produce debugging information in XCOFF format (if that is
- supported), using GNU extensions understood only by the GNU
- debugger (GDB). The use of these extensions is likely to make
- other debuggers crash or refuse to read the program, and may cause
- assemblers other than the GNU assembler (GAS) to fail with an
- error.
-
-`-gdwarf-VERSION'
- Produce debugging information in DWARF format (if that is
- supported). This is the format used by DBX on IRIX 6. The value
- of VERSION may be either 2, 3 or 4; the default version is 2.
-
- Note that with DWARF version 2 some ports require, and will always
- use, some non-conflicting DWARF 3 extensions in the unwind tables.
-
- Version 4 may require GDB 7.0 and `-fvar-tracking-assignments' for
- maximum benefit.
-
-`-gstrict-dwarf'
- Disallow using extensions of later DWARF standard version than
- selected with `-gdwarf-VERSION'. On most targets using
- non-conflicting DWARF extensions from later standard versions is
- allowed.
-
-`-gno-strict-dwarf'
- Allow using extensions of later DWARF standard version than
- selected with `-gdwarf-VERSION'.
-
-`-gvms'
- Produce debugging information in VMS debug format (if that is
- supported). This is the format used by DEBUG on VMS systems.
-
-`-gLEVEL'
-`-ggdbLEVEL'
-`-gstabsLEVEL'
-`-gcoffLEVEL'
-`-gxcoffLEVEL'
-`-gvmsLEVEL'
- Request debugging information and also use LEVEL to specify how
- much information. The default level is 2.
-
- Level 0 produces no debug information at all. Thus, `-g0' negates
- `-g'.
-
- Level 1 produces minimal information, enough for making backtraces
- in parts of the program that you don't plan to debug. This
- includes descriptions of functions and external variables, but no
- information about local variables and no line numbers.
-
- Level 3 includes extra information, such as all the macro
- definitions present in the program. Some debuggers support macro
- expansion when you use `-g3'.
-
- `-gdwarf-2' does not accept a concatenated debug level, because
- GCC used to support an option `-gdwarf' that meant to generate
- debug information in version 1 of the DWARF format (which is very
- different from version 2), and it would have been too confusing.
- That debug format is long obsolete, but the option cannot be
- changed now. Instead use an additional `-gLEVEL' option to change
- the debug level for DWARF.
-
-`-gmlt'
- Produce a minimal line table, with level 1 debugging information
- plus information about inlined functions and line numbers.
-
-`-gtoggle'
- Turn off generation of debug info, if leaving out this option
- would have generated it, or turn it on at level 2 otherwise. The
- position of this argument in the command line does not matter, it
- takes effect after all other options are processed, and it does so
- only once, no matter how many times it is given. This is mainly
- intended to be used with `-fcompare-debug'.
-
-`-fdump-final-insns[=FILE]'
- Dump the final internal representation (RTL) to FILE. If the
- optional argument is omitted (or if FILE is `.'), the name of the
- dump file will be determined by appending `.gkd' to the
- compilation output file name.
-
-`-fcompare-debug[=OPTS]'
- If no error occurs during compilation, run the compiler a second
- time, adding OPTS and `-fcompare-debug-second' to the arguments
- passed to the second compilation. Dump the final internal
- representation in both compilations, and print an error if they
- differ.
-
- If the equal sign is omitted, the default `-gtoggle' is used.
-
- The environment variable `GCC_COMPARE_DEBUG', if defined, non-empty
- and nonzero, implicitly enables `-fcompare-debug'. If
- `GCC_COMPARE_DEBUG' is defined to a string starting with a dash,
- then it is used for OPTS, otherwise the default `-gtoggle' is used.
-
- `-fcompare-debug=', with the equal sign but without OPTS, is
- equivalent to `-fno-compare-debug', which disables the dumping of
- the final representation and the second compilation, preventing
- even `GCC_COMPARE_DEBUG' from taking effect.
-
- To verify full coverage during `-fcompare-debug' testing, set
- `GCC_COMPARE_DEBUG' to say `-fcompare-debug-not-overridden', which
- GCC will reject as an invalid option in any actual compilation
- (rather than preprocessing, assembly or linking). To get just a
- warning, setting `GCC_COMPARE_DEBUG' to `-w%n-fcompare-debug not
- overridden' will do.
-
-`-fcompare-debug-second'
- This option is implicitly passed to the compiler for the second
- compilation requested by `-fcompare-debug', along with options to
- silence warnings, and omitting other options that would cause
- side-effect compiler outputs to files or to the standard output.
- Dump files and preserved temporary files are renamed so as to
- contain the `.gk' additional extension during the second
- compilation, to avoid overwriting those generated by the first.
-
- When this option is passed to the compiler driver, it causes the
- _first_ compilation to be skipped, which makes it useful for little
- other than debugging the compiler proper.
-
-`-feliminate-dwarf2-dups'
- Compress DWARF2 debugging information by eliminating duplicated
- information about each symbol. This option only makes sense when
- generating DWARF2 debugging information with `-gdwarf-2'.
-
-`-femit-struct-debug-baseonly'
- Emit debug information for struct-like types only when the base
- name of the compilation source file matches the base name of file
- in which the struct was defined.
-
- This option substantially reduces the size of debugging
- information, but at significant potential loss in type information
- to the debugger. See `-femit-struct-debug-reduced' for a less
- aggressive option. See `-femit-struct-debug-detailed' for more
- detailed control.
-
- This option works only with DWARF 2.
-
-`-femit-struct-debug-reduced'
- Emit debug information for struct-like types only when the base
- name of the compilation source file matches the base name of file
- in which the type was defined, unless the struct is a template or
- defined in a system header.
-
- This option significantly reduces the size of debugging
- information, with some potential loss in type information to the
- debugger. See `-femit-struct-debug-baseonly' for a more
- aggressive option. See `-femit-struct-debug-detailed' for more
- detailed control.
-
- This option works only with DWARF 2.
-
-`-femit-struct-debug-detailed[=SPEC-LIST]'
- Specify the struct-like types for which the compiler will generate
- debug information. The intent is to reduce duplicate struct debug
- information between different object files within the same program.
-
- This option is a detailed version of `-femit-struct-debug-reduced'
- and `-femit-struct-debug-baseonly', which will serve for most
- needs.
-
- A specification has the syntax
- [`dir:'|`ind:'][`ord:'|`gen:'](`any'|`sys'|`base'|`none')
-
- The optional first word limits the specification to structs that
- are used directly (`dir:') or used indirectly (`ind:'). A struct
- type is used directly when it is the type of a variable, member.
- Indirect uses arise through pointers to structs. That is, when
- use of an incomplete struct would be legal, the use is indirect.
- An example is `struct one direct; struct two * indirect;'.
-
- The optional second word limits the specification to ordinary
- structs (`ord:') or generic structs (`gen:'). Generic structs are
- a bit complicated to explain. For C++, these are non-explicit
- specializations of template classes, or non-template classes
- within the above. Other programming languages have generics, but
- `-femit-struct-debug-detailed' does not yet implement them.
-
- The third word specifies the source files for those structs for
- which the compiler will emit debug information. The values `none'
- and `any' have the normal meaning. The value `base' means that
- the base of name of the file in which the type declaration appears
- must match the base of the name of the main compilation file. In
- practice, this means that types declared in `foo.c' and `foo.h'
- will have debug information, but types declared in other header
- will not. The value `sys' means those types satisfying `base' or
- declared in system or compiler headers.
-
- You may need to experiment to determine the best settings for your
- application.
-
- The default is `-femit-struct-debug-detailed=all'.
-
- This option works only with DWARF 2.
-
-`-fenable-icf-debug'
- Generate additional debug information to support identical code
- folding (ICF). This option only works with DWARF version 2 or
- higher.
-
-`-fno-merge-debug-strings'
- Direct the linker to not merge together strings in the debugging
- information which are identical in different object files.
- Merging is not supported by all assemblers or linkers. Merging
- decreases the size of the debug information in the output file at
- the cost of increasing link processing time. Merging is enabled
- by default.
-
-`-fdebug-prefix-map=OLD=NEW'
- When compiling files in directory `OLD', record debugging
- information describing them as in `NEW' instead.
-
-`-fno-dwarf2-cfi-asm'
- Emit DWARF 2 unwind info as compiler generated `.eh_frame' section
- instead of using GAS `.cfi_*' directives.
-
-`-p'
- Generate extra code to write profile information suitable for the
- analysis program `prof'. You must use this option when compiling
- the source files you want data about, and you must also use it when
- linking.
-
-`-pg'
- Generate extra code to write profile information suitable for the
- analysis program `gprof'. You must use this option when compiling
- the source files you want data about, and you must also use it when
- linking.
-
-`-Q'
- Makes the compiler print out each function name as it is compiled,
- and print some statistics about each pass when it finishes.
-
-`-ftime-report'
- Makes the compiler print some statistics about the time consumed
- by each pass when it finishes.
-
-`-fmem-report'
- Makes the compiler print some statistics about permanent memory
- allocation when it finishes.
-
-`-fpre-ipa-mem-report'
-
-`-fpost-ipa-mem-report'
- Makes the compiler print some statistics about permanent memory
- allocation before or after interprocedural optimization.
-
-`-fstack-usage'
- Makes the compiler output stack usage information for the program,
- on a per-function basis. The filename for the dump is made by
- appending `.su' to the AUXNAME. AUXNAME is generated from the
- name of the output file, if explicitly specified and it is not an
- executable, otherwise it is the basename of the source file. An
- entry is made up of three fields:
-
- * The name of the function.
-
- * A number of bytes.
-
- * One or more qualifiers: `static', `dynamic', `bounded'.
-
- The qualifier `static' means that the function manipulates the
- stack statically: a fixed number of bytes are allocated for the
- frame on function entry and released on function exit; no stack
- adjustments are otherwise made in the function. The second field
- is this fixed number of bytes.
-
- The qualifier `dynamic' means that the function manipulates the
- stack dynamically: in addition to the static allocation described
- above, stack adjustments are made in the body of the function, for
- example to push/pop arguments around function calls. If the
- qualifier `bounded' is also present, the amount of these
- adjustments is bounded at compile-time and the second field is an
- upper bound of the total amount of stack used by the function. If
- it is not present, the amount of these adjustments is not bounded
- at compile-time and the second field only represents the bounded
- part.
-
-`-fprofile-arcs'
- Add code so that program flow "arcs" are instrumented. During
- execution the program records how many times each branch and call
- is executed and how many times it is taken or returns. When the
- compiled program exits it saves this data to a file called
- `AUXNAME.gcda' for each source file. The data may be used for
- profile-directed optimizations (`-fbranch-probabilities'), or for
- test coverage analysis (`-ftest-coverage'). Each object file's
- AUXNAME is generated from the name of the output file, if
- explicitly specified and it is not the final executable, otherwise
- it is the basename of the source file. In both cases any suffix
- is removed (e.g. `foo.gcda' for input file `dir/foo.c', or
- `dir/foo.gcda' for output file specified as `-o dir/foo.o').
- *Note Cross-profiling::.
-
-`--coverage'
- This option is used to compile and link code instrumented for
- coverage analysis. The option is a synonym for `-fprofile-arcs'
- `-ftest-coverage' (when compiling) and `-lgcov' (when linking).
- See the documentation for those options for more details.
-
- * Compile the source files with `-fprofile-arcs' plus
- optimization and code generation options. For test coverage
- analysis, use the additional `-ftest-coverage' option. You
- do not need to profile every source file in a program.
-
- * Link your object files with `-lgcov' or `-fprofile-arcs' (the
- latter implies the former).
-
- * Run the program on a representative workload to generate the
- arc profile information. This may be repeated any number of
- times. You can run concurrent instances of your program, and
- provided that the file system supports locking, the data
- files will be correctly updated. Also `fork' calls are
- detected and correctly handled (double counting will not
- happen).
-
- * For profile-directed optimizations, compile the source files
- again with the same optimization and code generation options
- plus `-fbranch-probabilities' (*note Options that Control
- Optimization: Optimize Options.).
-
- * For test coverage analysis, use `gcov' to produce human
- readable information from the `.gcno' and `.gcda' files.
- Refer to the `gcov' documentation for further information.
-
-
- With `-fprofile-arcs', for each function of your program GCC
- creates a program flow graph, then finds a spanning tree for the
- graph. Only arcs that are not on the spanning tree have to be
- instrumented: the compiler adds code to count the number of times
- that these arcs are executed. When an arc is the only exit or
- only entrance to a block, the instrumentation code can be added to
- the block; otherwise, a new basic block must be created to hold
- the instrumentation code.
-
-`-ftest-coverage'
- Produce a notes file that the `gcov' code-coverage utility (*note
- `gcov'--a Test Coverage Program: Gcov.) can use to show program
- coverage. Each source file's note file is called `AUXNAME.gcno'.
- Refer to the `-fprofile-arcs' option above for a description of
- AUXNAME and instructions on how to generate test coverage data.
- Coverage data will match the source files more closely, if you do
- not optimize.
-
-`-fdbg-cnt-list'
- Print the name and the counter upper bound for all debug counters.
-
-`-fdbg-cnt=COUNTER-VALUE-LIST'
- Set the internal debug counter upper bound. COUNTER-VALUE-LIST is
- a comma-separated list of NAME:VALUE pairs which sets the upper
- bound of each debug counter NAME to VALUE. All debug counters
- have the initial upper bound of UINT_MAX, thus dbg_cnt() returns
- true always unless the upper bound is set by this option. e.g.
- With -fdbg-cnt=dce:10,tail_call:0 dbg_cnt(dce) will return true
- only for first 10 invocations
-
-`-fenable-KIND-PASS'
-`-fdisable-KIND-PASS=RANGE-LIST'
- This is a set of debugging options that are used to explicitly
- disable/enable optimization passes. For compiler users, regular
- options for enabling/disabling passes should be used instead.
-
- * -fdisable-ipa-PASS Disable ipa pass PASS. PASS is the pass
- name. If the same pass is statically invoked in the compiler
- multiple times, the pass name should be appended with a
- sequential number starting from 1.
-
- * -fdisable-rtl-PASS
-
- * -fdisable-rtl-PASS=RANGE-LIST Disable rtl pass PASS. PASS is
- the pass name. If the same pass is statically invoked in the
- compiler multiple times, the pass name should be appended
- with a sequential number starting from 1. RANGE-LIST is a
- comma seperated list of function ranges or assembler names.
- Each range is a number pair seperated by a colon. The range
- is inclusive in both ends. If the range is trivial, the
- number pair can be simplified as a single number. If the
- function's cgraph node's UID is falling within one of the
- specified ranges, the PASS is disabled for that function.
- The UID is shown in the function header of a dump file, and
- the pass names can be dumped by using option `-fdump-passes'.
-
- * -fdisable-tree-PASS
-
- * -fdisable-tree-PASS=RANGE-LIST Disable tree pass PASS. See
- `-fdisable-rtl' for the description of option arguments.
-
- * -fenable-ipa-PASS Enable ipa pass PASS. PASS is the pass
- name. If the same pass is statically invoked in the compiler
- multiple times, the pass name should be appended with a
- sequential number starting from 1.
-
- * -fenable-rtl-PASS
-
- * -fenable-rtl-PASS=RANGE-LIST Enable rtl pass PASS. See
- `-fdisable-rtl' for option argument description and examples.
-
- * -fenable-tree-PASS
-
- * -fenable-tree-PASS=RANGE-LIST Enable tree pass PASS. See
- `-fdisable-rtl' for the description of option arguments.
-
-
- # disable ccp1 for all functions
- -fdisable-tree-ccp1
- # disable complete unroll for function whose cgraph node uid is 1
- -fenable-tree-cunroll=1
- # disable gcse2 for functions at the following ranges [1,1],
- # [300,400], and [400,1000]
- # disable gcse2 for functions foo and foo2
- -fdisable-rtl-gcse2=foo,foo2
- # disable early inlining
- -fdisable-tree-einline
- # disable ipa inlining
- -fdisable-ipa-inline
- # enable tree full unroll
- -fenable-tree-unroll
-
-
-`-dLETTERS'
-`-fdump-rtl-PASS'
- Says to make debugging dumps during compilation at times specified
- by LETTERS. This is used for debugging the RTL-based passes of the
- compiler. The file names for most of the dumps are made by
- appending a pass number and a word to the DUMPNAME, and the files
- are created in the directory of the output file. Note that the
- pass number is computed statically as passes get registered into
- the pass manager. Thus the numbering is not related to the
- dynamic order of execution of passes. In particular, a pass
- installed by a plugin could have a number over 200 even if it
- executed quite early. DUMPNAME is generated from the name of the
- output file, if explicitly specified and it is not an executable,
- otherwise it is the basename of the source file. These switches
- may have different effects when `-E' is used for preprocessing.
-
- Debug dumps can be enabled with a `-fdump-rtl' switch or some `-d'
- option LETTERS. Here are the possible letters for use in PASS and
- LETTERS, and their meanings:
-
- `-fdump-rtl-alignments'
- Dump after branch alignments have been computed.
-
- `-fdump-rtl-asmcons'
- Dump after fixing rtl statements that have unsatisfied in/out
- constraints.
-
- `-fdump-rtl-auto_inc_dec'
- Dump after auto-inc-dec discovery. This pass is only run on
- architectures that have auto inc or auto dec instructions.
-
- `-fdump-rtl-barriers'
- Dump after cleaning up the barrier instructions.
-
- `-fdump-rtl-bbpart'
- Dump after partitioning hot and cold basic blocks.
-
- `-fdump-rtl-bbro'
- Dump after block reordering.
-
- `-fdump-rtl-btl1'
- `-fdump-rtl-btl2'
- `-fdump-rtl-btl1' and `-fdump-rtl-btl2' enable dumping after
- the two branch target load optimization passes.
-
- `-fdump-rtl-bypass'
- Dump after jump bypassing and control flow optimizations.
-
- `-fdump-rtl-combine'
- Dump after the RTL instruction combination pass.
-
- `-fdump-rtl-compgotos'
- Dump after duplicating the computed gotos.
-
- `-fdump-rtl-ce1'
- `-fdump-rtl-ce2'
- `-fdump-rtl-ce3'
- `-fdump-rtl-ce1', `-fdump-rtl-ce2', and `-fdump-rtl-ce3'
- enable dumping after the three if conversion passes.
-
- `-fdump-rtl-cprop_hardreg'
- Dump after hard register copy propagation.
-
- `-fdump-rtl-csa'
- Dump after combining stack adjustments.
-
- `-fdump-rtl-cse1'
- `-fdump-rtl-cse2'
- `-fdump-rtl-cse1' and `-fdump-rtl-cse2' enable dumping after
- the two common sub-expression elimination passes.
-
- `-fdump-rtl-dce'
- Dump after the standalone dead code elimination passes.
-
- `-fdump-rtl-dbr'
- Dump after delayed branch scheduling.
-
- `-fdump-rtl-dce1'
- `-fdump-rtl-dce2'
- `-fdump-rtl-dce1' and `-fdump-rtl-dce2' enable dumping after
- the two dead store elimination passes.
-
- `-fdump-rtl-eh'
- Dump after finalization of EH handling code.
-
- `-fdump-rtl-eh_ranges'
- Dump after conversion of EH handling range regions.
-
- `-fdump-rtl-expand'
- Dump after RTL generation.
-
- `-fdump-rtl-fwprop1'
- `-fdump-rtl-fwprop2'
- `-fdump-rtl-fwprop1' and `-fdump-rtl-fwprop2' enable dumping
- after the two forward propagation passes.
-
- `-fdump-rtl-gcse1'
- `-fdump-rtl-gcse2'
- `-fdump-rtl-gcse1' and `-fdump-rtl-gcse2' enable dumping
- after global common subexpression elimination.
-
- `-fdump-rtl-init-regs'
- Dump after the initialization of the registers.
-
- `-fdump-rtl-initvals'
- Dump after the computation of the initial value sets.
-
- `-fdump-rtl-into_cfglayout'
- Dump after converting to cfglayout mode.
-
- `-fdump-rtl-ira'
- Dump after iterated register allocation.
-
- `-fdump-rtl-jump'
- Dump after the second jump optimization.
-
- `-fdump-rtl-loop2'
- `-fdump-rtl-loop2' enables dumping after the rtl loop
- optimization passes.
-
- `-fdump-rtl-mach'
- Dump after performing the machine dependent reorganization
- pass, if that pass exists.
-
- `-fdump-rtl-mode_sw'
- Dump after removing redundant mode switches.
-
- `-fdump-rtl-rnreg'
- Dump after register renumbering.
-
- `-fdump-rtl-outof_cfglayout'
- Dump after converting from cfglayout mode.
-
- `-fdump-rtl-peephole2'
- Dump after the peephole pass.
-
- `-fdump-rtl-postreload'
- Dump after post-reload optimizations.
-
- `-fdump-rtl-pro_and_epilogue'
- Dump after generating the function pro and epilogues.
-
- `-fdump-rtl-regmove'
- Dump after the register move pass.
-
- `-fdump-rtl-sched1'
- `-fdump-rtl-sched2'
- `-fdump-rtl-sched1' and `-fdump-rtl-sched2' enable dumping
- after the basic block scheduling passes.
-
- `-fdump-rtl-see'
- Dump after sign extension elimination.
-
- `-fdump-rtl-seqabstr'
- Dump after common sequence discovery.
-
- `-fdump-rtl-shorten'
- Dump after shortening branches.
-
- `-fdump-rtl-sibling'
- Dump after sibling call optimizations.
-
- `-fdump-rtl-split1'
- `-fdump-rtl-split2'
- `-fdump-rtl-split3'
- `-fdump-rtl-split4'
- `-fdump-rtl-split5'
- `-fdump-rtl-split1', `-fdump-rtl-split2',
- `-fdump-rtl-split3', `-fdump-rtl-split4' and
- `-fdump-rtl-split5' enable dumping after five rounds of
- instruction splitting.
-
- `-fdump-rtl-sms'
- Dump after modulo scheduling. This pass is only run on some
- architectures.
-
- `-fdump-rtl-stack'
- Dump after conversion from GCC's "flat register file"
- registers to the x87's stack-like registers. This pass is
- only run on x86 variants.
-
- `-fdump-rtl-subreg1'
- `-fdump-rtl-subreg2'
- `-fdump-rtl-subreg1' and `-fdump-rtl-subreg2' enable dumping
- after the two subreg expansion passes.
-
- `-fdump-rtl-unshare'
- Dump after all rtl has been unshared.
-
- `-fdump-rtl-vartrack'
- Dump after variable tracking.
-
- `-fdump-rtl-vregs'
- Dump after converting virtual registers to hard registers.
-
- `-fdump-rtl-web'
- Dump after live range splitting.
-
- `-fdump-rtl-regclass'
- `-fdump-rtl-subregs_of_mode_init'
- `-fdump-rtl-subregs_of_mode_finish'
- `-fdump-rtl-dfinit'
- `-fdump-rtl-dfinish'
- These dumps are defined but always produce empty files.
-
- `-fdump-rtl-all'
- Produce all the dumps listed above.
-
- `-dA'
- Annotate the assembler output with miscellaneous debugging
- information.
-
- `-dD'
- Dump all macro definitions, at the end of preprocessing, in
- addition to normal output.
-
- `-dH'
- Produce a core dump whenever an error occurs.
-
- `-dm'
- Print statistics on memory usage, at the end of the run, to
- standard error.
-
- `-dp'
- Annotate the assembler output with a comment indicating which
- pattern and alternative was used. The length of each
- instruction is also printed.
-
- `-dP'
- Dump the RTL in the assembler output as a comment before each
- instruction. Also turns on `-dp' annotation.
-
- `-dv'
- For each of the other indicated dump files
- (`-fdump-rtl-PASS'), dump a representation of the control
- flow graph suitable for viewing with VCG to `FILE.PASS.vcg'.
-
- `-dx'
- Just generate RTL for a function instead of compiling it.
- Usually used with `-fdump-rtl-expand'.
-
-`-fdump-noaddr'
- When doing debugging dumps, suppress address output. This makes
- it more feasible to use diff on debugging dumps for compiler
- invocations with different compiler binaries and/or different text
- / bss / data / heap / stack / dso start locations.
-
-`-fdump-unnumbered'
- When doing debugging dumps, suppress instruction numbers and
- address output. This makes it more feasible to use diff on
- debugging dumps for compiler invocations with different options,
- in particular with and without `-g'.
-
-`-fdump-unnumbered-links'
- When doing debugging dumps (see `-d' option above), suppress
- instruction numbers for the links to the previous and next
- instructions in a sequence.
-
-`-fdump-translation-unit (C++ only)'
-`-fdump-translation-unit-OPTIONS (C++ only)'
- Dump a representation of the tree structure for the entire
- translation unit to a file. The file name is made by appending
- `.tu' to the source file name, and the file is created in the same
- directory as the output file. If the `-OPTIONS' form is used,
- OPTIONS controls the details of the dump as described for the
- `-fdump-tree' options.
-
-`-fdump-class-hierarchy (C++ only)'
-`-fdump-class-hierarchy-OPTIONS (C++ only)'
- Dump a representation of each class's hierarchy and virtual
- function table layout to a file. The file name is made by
- appending `.class' to the source file name, and the file is
- created in the same directory as the output file. If the
- `-OPTIONS' form is used, OPTIONS controls the details of the dump
- as described for the `-fdump-tree' options.
-
-`-fdump-ipa-SWITCH'
- Control the dumping at various stages of inter-procedural analysis
- language tree to a file. The file name is generated by appending a
- switch specific suffix to the source file name, and the file is
- created in the same directory as the output file. The following
- dumps are possible:
-
- `all'
- Enables all inter-procedural analysis dumps.
-
- `cgraph'
- Dumps information about call-graph optimization, unused
- function removal, and inlining decisions.
-
- `inline'
- Dump after function inlining.
-
-
-`-fdump-passes'
- Dump the list of optimization passes that are turned on and off by
- the current command line options.
-
-`-fdump-statistics-OPTION'
- Enable and control dumping of pass statistics in a separate file.
- The file name is generated by appending a suffix ending in
- `.statistics' to the source file name, and the file is created in
- the same directory as the output file. If the `-OPTION' form is
- used, `-stats' will cause counters to be summed over the whole
- compilation unit while `-details' will dump every event as the
- passes generate them. The default with no option is to sum
- counters for each function compiled.
-
-`-fdump-tree-SWITCH'
-`-fdump-tree-SWITCH-OPTIONS'
- Control the dumping at various stages of processing the
- intermediate language tree to a file. The file name is generated
- by appending a switch specific suffix to the source file name, and
- the file is created in the same directory as the output file. If
- the `-OPTIONS' form is used, OPTIONS is a list of `-' separated
- options that control the details of the dump. Not all options are
- applicable to all dumps, those which are not meaningful will be
- ignored. The following options are available
-
- `address'
- Print the address of each node. Usually this is not
- meaningful as it changes according to the environment and
- source file. Its primary use is for tying up a dump file
- with a debug environment.
-
- `asmname'
- If `DECL_ASSEMBLER_NAME' has been set for a given decl, use
- that in the dump instead of `DECL_NAME'. Its primary use is
- ease of use working backward from mangled names in the
- assembly file.
-
- `slim'
- Inhibit dumping of members of a scope or body of a function
- merely because that scope has been reached. Only dump such
- items when they are directly reachable by some other path.
- When dumping pretty-printed trees, this option inhibits
- dumping the bodies of control structures.
-
- `raw'
- Print a raw representation of the tree. By default, trees are
- pretty-printed into a C-like representation.
-
- `details'
- Enable more detailed dumps (not honored by every dump option).
-
- `stats'
- Enable dumping various statistics about the pass (not honored
- by every dump option).
-
- `blocks'
- Enable showing basic block boundaries (disabled in raw dumps).
-
- `vops'
- Enable showing virtual operands for every statement.
-
- `lineno'
- Enable showing line numbers for statements.
-
- `uid'
- Enable showing the unique ID (`DECL_UID') for each variable.
-
- `verbose'
- Enable showing the tree dump for each statement.
-
- `eh'
- Enable showing the EH region number holding each statement.
-
- `all'
- Turn on all options, except `raw', `slim', `verbose' and
- `lineno'.
-
- The following tree dumps are possible:
- `original'
- Dump before any tree based optimization, to `FILE.original'.
-
- `optimized'
- Dump after all tree based optimization, to `FILE.optimized'.
-
- `gimple'
- Dump each function before and after the gimplification pass
- to a file. The file name is made by appending `.gimple' to
- the source file name.
-
- `cfg'
- Dump the control flow graph of each function to a file. The
- file name is made by appending `.cfg' to the source file name.
-
- `vcg'
- Dump the control flow graph of each function to a file in VCG
- format. The file name is made by appending `.vcg' to the
- source file name. Note that if the file contains more than
- one function, the generated file cannot be used directly by
- VCG. You will need to cut and paste each function's graph
- into its own separate file first.
-
- `ch'
- Dump each function after copying loop headers. The file name
- is made by appending `.ch' to the source file name.
-
- `ssa'
- Dump SSA related information to a file. The file name is
- made by appending `.ssa' to the source file name.
-
- `alias'
- Dump aliasing information for each function. The file name
- is made by appending `.alias' to the source file name.
-
- `ccp'
- Dump each function after CCP. The file name is made by
- appending `.ccp' to the source file name.
-
- `storeccp'
- Dump each function after STORE-CCP. The file name is made by
- appending `.storeccp' to the source file name.
-
- `pre'
- Dump trees after partial redundancy elimination. The file
- name is made by appending `.pre' to the source file name.
-
- `fre'
- Dump trees after full redundancy elimination. The file name
- is made by appending `.fre' to the source file name.
-
- `copyprop'
- Dump trees after copy propagation. The file name is made by
- appending `.copyprop' to the source file name.
-
- `store_copyprop'
- Dump trees after store copy-propagation. The file name is
- made by appending `.store_copyprop' to the source file name.
-
- `dce'
- Dump each function after dead code elimination. The file
- name is made by appending `.dce' to the source file name.
-
- `mudflap'
- Dump each function after adding mudflap instrumentation. The
- file name is made by appending `.mudflap' to the source file
- name.
-
- `sra'
- Dump each function after performing scalar replacement of
- aggregates. The file name is made by appending `.sra' to the
- source file name.
-
- `sink'
- Dump each function after performing code sinking. The file
- name is made by appending `.sink' to the source file name.
-
- `dom'
- Dump each function after applying dominator tree
- optimizations. The file name is made by appending `.dom' to
- the source file name.
-
- `dse'
- Dump each function after applying dead store elimination.
- The file name is made by appending `.dse' to the source file
- name.
-
- `phiopt'
- Dump each function after optimizing PHI nodes into
- straightline code. The file name is made by appending
- `.phiopt' to the source file name.
-
- `forwprop'
- Dump each function after forward propagating single use
- variables. The file name is made by appending `.forwprop' to
- the source file name.
-
- `copyrename'
- Dump each function after applying the copy rename
- optimization. The file name is made by appending
- `.copyrename' to the source file name.
-
- `nrv'
- Dump each function after applying the named return value
- optimization on generic trees. The file name is made by
- appending `.nrv' to the source file name.
-
- `vect'
- Dump each function after applying vectorization of loops.
- The file name is made by appending `.vect' to the source file
- name.
-
- `slp'
- Dump each function after applying vectorization of basic
- blocks. The file name is made by appending `.slp' to the
- source file name.
-
- `vrp'
- Dump each function after Value Range Propagation (VRP). The
- file name is made by appending `.vrp' to the source file name.
-
- `all'
- Enable all the available tree dumps with the flags provided
- in this option.
-
-`-ftree-vectorizer-verbose=N'
- This option controls the amount of debugging output the vectorizer
- prints. This information is written to standard error, unless
- `-fdump-tree-all' or `-fdump-tree-vect' is specified, in which
- case it is output to the usual dump listing file, `.vect'. For
- N=0 no diagnostic information is reported. If N=1 the vectorizer
- reports each loop that got vectorized, and the total number of
- loops that got vectorized. If N=2 the vectorizer also reports
- non-vectorized loops that passed the first analysis phase
- (vect_analyze_loop_form) - i.e. countable, inner-most, single-bb,
- single-entry/exit loops. This is the same verbosity level that
- `-fdump-tree-vect-stats' uses. Higher verbosity levels mean
- either more information dumped for each reported loop, or same
- amount of information reported for more loops: if N=3, vectorizer
- cost model information is reported. If N=4, alignment related
- information is added to the reports. If N=5, data-references
- related information (e.g. memory dependences, memory
- access-patterns) is added to the reports. If N=6, the vectorizer
- reports also non-vectorized inner-most loops that did not pass the
- first analysis phase (i.e., may not be countable, or may have
- complicated control-flow). If N=7, the vectorizer reports also
- non-vectorized nested loops. If N=8, SLP related information is
- added to the reports. For N=9, all the information the vectorizer
- generates during its analysis and transformation is reported.
- This is the same verbosity level that `-fdump-tree-vect-details'
- uses.
-
-`-frandom-seed=STRING'
- This option provides a seed that GCC uses when it would otherwise
- use random numbers. It is used to generate certain symbol names
- that have to be different in every compiled file. It is also used
- to place unique stamps in coverage data files and the object files
- that produce them. You can use the `-frandom-seed' option to
- produce reproducibly identical object files.
-
- The STRING should be different for every file you compile.
-
-`-fsched-verbose=N'
- On targets that use instruction scheduling, this option controls
- the amount of debugging output the scheduler prints. This
- information is written to standard error, unless
- `-fdump-rtl-sched1' or `-fdump-rtl-sched2' is specified, in which
- case it is output to the usual dump listing file, `.sched1' or
- `.sched2' respectively. However for N greater than nine, the
- output is always printed to standard error.
-
- For N greater than zero, `-fsched-verbose' outputs the same
- information as `-fdump-rtl-sched1' and `-fdump-rtl-sched2'. For N
- greater than one, it also output basic block probabilities,
- detailed ready list information and unit/insn info. For N greater
- than two, it includes RTL at abort point, control-flow and regions
- info. And for N over four, `-fsched-verbose' also includes
- dependence info.
-
-`-save-temps'
-`-save-temps=cwd'
- Store the usual "temporary" intermediate files permanently; place
- them in the current directory and name them based on the source
- file. Thus, compiling `foo.c' with `-c -save-temps' would produce
- files `foo.i' and `foo.s', as well as `foo.o'. This creates a
- preprocessed `foo.i' output file even though the compiler now
- normally uses an integrated preprocessor.
-
- When used in combination with the `-x' command line option,
- `-save-temps' is sensible enough to avoid over writing an input
- source file with the same extension as an intermediate file. The
- corresponding intermediate file may be obtained by renaming the
- source file before using `-save-temps'.
-
- If you invoke GCC in parallel, compiling several different source
- files that share a common base name in different subdirectories or
- the same source file compiled for multiple output destinations, it
- is likely that the different parallel compilers will interfere
- with each other, and overwrite the temporary files. For instance:
-
- gcc -save-temps -o outdir1/foo.o indir1/foo.c&
- gcc -save-temps -o outdir2/foo.o indir2/foo.c&
-
- may result in `foo.i' and `foo.o' being written to simultaneously
- by both compilers.
-
-`-save-temps=obj'
- Store the usual "temporary" intermediate files permanently. If the
- `-o' option is used, the temporary files are based on the object
- file. If the `-o' option is not used, the `-save-temps=obj'
- switch behaves like `-save-temps'.
-
- For example:
-
- gcc -save-temps=obj -c foo.c
- gcc -save-temps=obj -c bar.c -o dir/xbar.o
- gcc -save-temps=obj foobar.c -o dir2/yfoobar
-
- would create `foo.i', `foo.s', `dir/xbar.i', `dir/xbar.s',
- `dir2/yfoobar.i', `dir2/yfoobar.s', and `dir2/yfoobar.o'.
-
-`-time[=FILE]'
- Report the CPU time taken by each subprocess in the compilation
- sequence. For C source files, this is the compiler proper and
- assembler (plus the linker if linking is done).
-
- Without the specification of an output file, the output looks like
- this:
-
- # cc1 0.12 0.01
- # as 0.00 0.01
-
- The first number on each line is the "user time", that is time
- spent executing the program itself. The second number is "system
- time", time spent executing operating system routines on behalf of
- the program. Both numbers are in seconds.
-
- With the specification of an output file, the output is appended
- to the named file, and it looks like this:
-
- 0.12 0.01 cc1 OPTIONS
- 0.00 0.01 as OPTIONS
-
- The "user time" and the "system time" are moved before the program
- name, and the options passed to the program are displayed, so that
- one can later tell what file was being compiled, and with which
- options.
-
-`-fvar-tracking'
- Run variable tracking pass. It computes where variables are
- stored at each position in code. Better debugging information is
- then generated (if the debugging information format supports this
- information).
-
- It is enabled by default when compiling with optimization (`-Os',
- `-O', `-O2', ...), debugging information (`-g') and the debug info
- format supports it.
-
-`-fvar-tracking-assignments'
- Annotate assignments to user variables early in the compilation and
- attempt to carry the annotations over throughout the compilation
- all the way to the end, in an attempt to improve debug information
- while optimizing. Use of `-gdwarf-4' is recommended along with it.
-
- It can be enabled even if var-tracking is disabled, in which case
- annotations will be created and maintained, but discarded at the
- end.
-
-`-fvar-tracking-assignments-toggle'
- Toggle `-fvar-tracking-assignments', in the same way that
- `-gtoggle' toggles `-g'.
-
-`-print-file-name=LIBRARY'
- Print the full absolute name of the library file LIBRARY that
- would be used when linking--and don't do anything else. With this
- option, GCC does not compile or link anything; it just prints the
- file name.
-
-`-print-multi-directory'
- Print the directory name corresponding to the multilib selected by
- any other switches present in the command line. This directory is
- supposed to exist in `GCC_EXEC_PREFIX'.
-
-`-print-multi-lib'
- Print the mapping from multilib directory names to compiler
- switches that enable them. The directory name is separated from
- the switches by `;', and each switch starts with an `@' instead of
- the `-', without spaces between multiple switches. This is
- supposed to ease shell-processing.
-
-`-print-multi-os-directory'
- Print the path to OS libraries for the selected multilib, relative
- to some `lib' subdirectory. If OS libraries are present in the
- `lib' subdirectory and no multilibs are used, this is usually just
- `.', if OS libraries are present in `libSUFFIX' sibling
- directories this prints e.g. `../lib64', `../lib' or `../lib32',
- or if OS libraries are present in `lib/SUBDIR' subdirectories it
- prints e.g. `amd64', `sparcv9' or `ev6'.
-
-`-print-prog-name=PROGRAM'
- Like `-print-file-name', but searches for a program such as `cpp'.
-
-`-print-libgcc-file-name'
- Same as `-print-file-name=libgcc.a'.
-
- This is useful when you use `-nostdlib' or `-nodefaultlibs' but
- you do want to link with `libgcc.a'. You can do
-
- gcc -nostdlib FILES... `gcc -print-libgcc-file-name`
-
-`-print-search-dirs'
- Print the name of the configured installation directory and a list
- of program and library directories `gcc' will search--and don't do
- anything else.
-
- This is useful when `gcc' prints the error message `installation
- problem, cannot exec cpp0: No such file or directory'. To resolve
- this you either need to put `cpp0' and the other compiler
- components where `gcc' expects to find them, or you can set the
- environment variable `GCC_EXEC_PREFIX' to the directory where you
- installed them. Don't forget the trailing `/'. *Note Environment
- Variables::.
-
-`-print-sysroot'
- Print the target sysroot directory that will be used during
- compilation. This is the target sysroot specified either at
- configure time or using the `--sysroot' option, possibly with an
- extra suffix that depends on compilation options. If no target
- sysroot is specified, the option prints nothing.
-
-`-print-sysroot-headers-suffix'
- Print the suffix added to the target sysroot when searching for
- headers, or give an error if the compiler is not configured with
- such a suffix--and don't do anything else.
-
-`-dumpmachine'
- Print the compiler's target machine (for example,
- `i686-pc-linux-gnu')--and don't do anything else.
-
-`-dumpversion'
- Print the compiler version (for example, `3.0')--and don't do
- anything else.
-
-`-dumpspecs'
- Print the compiler's built-in specs--and don't do anything else.
- (This is used when GCC itself is being built.) *Note Spec Files::.
-
-`-feliminate-unused-debug-types'
- Normally, when producing DWARF2 output, GCC will emit debugging
- information for all types declared in a compilation unit,
- regardless of whether or not they are actually used in that
- compilation unit. Sometimes this is useful, such as if, in the
- debugger, you want to cast a value to a type that is not actually
- used in your program (but is declared). More often, however, this
- results in a significant amount of wasted space. With this
- option, GCC will avoid producing debug symbol output for types
- that are nowhere used in the source file being compiled.
-
-
-File: gcc.info, Node: Optimize Options, Next: Preprocessor Options, Prev: Debugging Options, Up: Invoking GCC
-
-3.10 Options That Control Optimization
-======================================
-
-These options control various sorts of optimizations.
-
- Without any optimization option, the compiler's goal is to reduce the
-cost of compilation and to make debugging produce the expected results.
-Statements are independent: if you stop the program with a breakpoint
-between statements, you can then assign a new value to any variable or
-change the program counter to any other statement in the function and
-get exactly the results you would expect from the source code.
-
- Turning on optimization flags makes the compiler attempt to improve
-the performance and/or code size at the expense of compilation time and
-possibly the ability to debug the program.
-
- The compiler performs optimization based on the knowledge it has of the
-program. Compiling multiple files at once to a single output file mode
-allows the compiler to use information gained from all of the files
-when compiling each of them.
-
- Not all optimizations are controlled directly by a flag. Only
-optimizations that have a flag are listed in this section.
-
- Most optimizations are only enabled if an `-O' level is set on the
-command line. Otherwise they are disabled, even if individual
-optimization flags are specified.
-
- Depending on the target and how GCC was configured, a slightly
-different set of optimizations may be enabled at each `-O' level than
-those listed here. You can invoke GCC with `-Q --help=optimizers' to
-find out the exact set of optimizations that are enabled at each level.
-*Note Overall Options::, for examples.
-
-`-O'
-`-O1'
- Optimize. Optimizing compilation takes somewhat more time, and a
- lot more memory for a large function.
-
- With `-O', the compiler tries to reduce code size and execution
- time, without performing any optimizations that take a great deal
- of compilation time.
-
- `-O' turns on the following optimization flags:
- -fauto-inc-dec
- -fcompare-elim
- -fcprop-registers
- -fdce
- -fdefer-pop
- -fdelayed-branch
- -fdse
- -fguess-branch-probability
- -fif-conversion2
- -fif-conversion
- -fipa-pure-const
- -fipa-profile
- -fipa-reference
- -fmerge-constants
- -fsplit-wide-types
- -ftree-bit-ccp
- -ftree-builtin-call-dce
- -ftree-ccp
- -ftree-ch
- -ftree-copyrename
- -ftree-dce
- -ftree-dominator-opts
- -ftree-dse
- -ftree-forwprop
- -ftree-fre
- -ftree-phiprop
- -ftree-sra
- -ftree-pta
- -ftree-ter
- -funit-at-a-time
-
- `-O' also turns on `-fomit-frame-pointer' on machines where doing
- so does not interfere with debugging.
-
-`-O2'
- Optimize even more. GCC performs nearly all supported
- optimizations that do not involve a space-speed tradeoff. As
- compared to `-O', this option increases both compilation time and
- the performance of the generated code.
-
- `-O2' turns on all optimization flags specified by `-O'. It also
- turns on the following optimization flags:
- -fthread-jumps
- -falign-functions -falign-jumps
- -falign-loops -falign-labels
- -fcaller-saves
- -fcrossjumping
- -fcse-follow-jumps -fcse-skip-blocks
- -fdelete-null-pointer-checks
- -fdevirtualize
- -fexpensive-optimizations
- -fgcse -fgcse-lm
- -finline-small-functions
- -findirect-inlining
- -fipa-sra
- -foptimize-sibling-calls
- -fpartial-inlining
- -fpeephole2
- -fregmove
- -freorder-blocks -freorder-functions
- -frerun-cse-after-loop
- -fsched-interblock -fsched-spec
- -fschedule-insns -fschedule-insns2
- -fstrict-aliasing -fstrict-overflow
- -ftree-switch-conversion
- -ftree-pre
- -ftree-vrp
-
- Please note the warning under `-fgcse' about invoking `-O2' on
- programs that use computed gotos.
-
-`-O3'
- Optimize yet more. `-O3' turns on all optimizations specified by
- `-O2' and also turns on the `-finline-functions',
- `-funswitch-loops', `-fpredictive-commoning',
- `-fgcse-after-reload', `-ftree-vectorize' and `-fipa-cp-clone'
- options.
-
-`-O0'
- Reduce compilation time and make debugging produce the expected
- results. This is the default.
-
-`-Os'
- Optimize for size. `-Os' enables all `-O2' optimizations that do
- not typically increase code size. It also performs further
- optimizations designed to reduce code size.
-
- `-Os' disables the following optimization flags:
- -falign-functions -falign-jumps -falign-loops
- -falign-labels -freorder-blocks -freorder-blocks-and-partition
- -fprefetch-loop-arrays -ftree-vect-loop-version
-
-`-Ofast'
- Disregard strict standards compliance. `-Ofast' enables all `-O3'
- optimizations. It also enables optimizations that are not valid
- for all standard compliant programs. It turns on `-ffast-math'.
-
- If you use multiple `-O' options, with or without level numbers,
- the last such option is the one that is effective.
-
- Options of the form `-fFLAG' specify machine-independent flags. Most
-flags have both positive and negative forms; the negative form of
-`-ffoo' would be `-fno-foo'. In the table below, only one of the forms
-is listed--the one you typically will use. You can figure out the
-other form by either removing `no-' or adding it.
-
- The following options control specific optimizations. They are either
-activated by `-O' options or are related to ones that are. You can use
-the following flags in the rare cases when "fine-tuning" of
-optimizations to be performed is desired.
-
-`-fno-default-inline'
- Do not make member functions inline by default merely because they
- are defined inside the class scope (C++ only). Otherwise, when
- you specify `-O', member functions defined inside class scope are
- compiled inline by default; i.e., you don't need to add `inline'
- in front of the member function name.
-
-`-fno-defer-pop'
- Always pop the arguments to each function call as soon as that
- function returns. For machines which must pop arguments after a
- function call, the compiler normally lets arguments accumulate on
- the stack for several function calls and pops them all at once.
-
- Disabled at levels `-O', `-O2', `-O3', `-Os'.
-
-`-fforward-propagate'
- Perform a forward propagation pass on RTL. The pass tries to
- combine two instructions and checks if the result can be
- simplified. If loop unrolling is active, two passes are performed
- and the second is scheduled after loop unrolling.
-
- This option is enabled by default at optimization levels `-O',
- `-O2', `-O3', `-Os'.
-
-`-ffp-contract=STYLE'
- `-ffp-contract=off' disables floating-point expression contraction.
- `-ffp-contract=fast' enables floating-point expression contraction
- such as forming of fused multiply-add operations if the target has
- native support for them. `-ffp-contract=on' enables
- floating-point expression contraction if allowed by the language
- standard. This is currently not implemented and treated equal to
- `-ffp-contract=off'.
-
- The default is `-ffp-contract=fast'.
-
-`-fomit-frame-pointer'
- Don't keep the frame pointer in a register for functions that
- don't need one. This avoids the instructions to save, set up and
- restore frame pointers; it also makes an extra register available
- in many functions. *It also makes debugging impossible on some
- machines.*
-
- On some machines, such as the VAX, this flag has no effect, because
- the standard calling sequence automatically handles the frame
- pointer and nothing is saved by pretending it doesn't exist. The
- machine-description macro `FRAME_POINTER_REQUIRED' controls
- whether a target machine supports this flag. *Note Register
- Usage: (gccint)Registers.
-
- Starting with GCC version 4.6, the default setting (when not
- optimizing for size) for 32-bit Linux x86 and 32-bit Darwin x86
- targets has been changed to `-fomit-frame-pointer'. The default
- can be reverted to `-fno-omit-frame-pointer' by configuring GCC
- with the `--enable-frame-pointer' configure option.
-
- Enabled at levels `-O', `-O2', `-O3', `-Os'.
-
-`-foptimize-sibling-calls'
- Optimize sibling and tail recursive calls.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fno-inline'
- Don't pay attention to the `inline' keyword. Normally this option
- is used to keep the compiler from expanding any functions inline.
- Note that if you are not optimizing, no functions can be expanded
- inline.
-
-`-finline-small-functions'
- Integrate functions into their callers when their body is smaller
- than expected function call code (so overall size of program gets
- smaller). The compiler heuristically decides which functions are
- simple enough to be worth integrating in this way.
-
- Enabled at level `-O2'.
-
-`-findirect-inlining'
- Inline also indirect calls that are discovered to be known at
- compile time thanks to previous inlining. This option has any
- effect only when inlining itself is turned on by the
- `-finline-functions' or `-finline-small-functions' options.
-
- Enabled at level `-O2'.
-
-`-finline-functions'
- Integrate all simple functions into their callers. The compiler
- heuristically decides which functions are simple enough to be worth
- integrating in this way.
-
- If all calls to a given function are integrated, and the function
- is declared `static', then the function is normally not output as
- assembler code in its own right.
-
- Enabled at level `-O3'.
-
-`-finline-functions-called-once'
- Consider all `static' functions called once for inlining into their
- caller even if they are not marked `inline'. If a call to a given
- function is integrated, then the function is not output as
- assembler code in its own right.
-
- Enabled at levels `-O1', `-O2', `-O3' and `-Os'.
-
-`-fearly-inlining'
- Inline functions marked by `always_inline' and functions whose
- body seems smaller than the function call overhead early before
- doing `-fprofile-generate' instrumentation and real inlining pass.
- Doing so makes profiling significantly cheaper and usually
- inlining faster on programs having large chains of nested wrapper
- functions.
-
- Enabled by default.
-
-`-fipa-sra'
- Perform interprocedural scalar replacement of aggregates, removal
- of unused parameters and replacement of parameters passed by
- reference by parameters passed by value.
-
- Enabled at levels `-O2', `-O3' and `-Os'.
-
-`-finline-limit=N'
- By default, GCC limits the size of functions that can be inlined.
- This flag allows coarse control of this limit. N is the size of
- functions that can be inlined in number of pseudo instructions.
-
- Inlining is actually controlled by a number of parameters, which
- may be specified individually by using `--param NAME=VALUE'. The
- `-finline-limit=N' option sets some of these parameters as follows:
-
- `max-inline-insns-single'
- is set to N/2.
-
- `max-inline-insns-auto'
- is set to N/2.
-
- See below for a documentation of the individual parameters
- controlling inlining and for the defaults of these parameters.
-
- _Note:_ there may be no value to `-finline-limit' that results in
- default behavior.
-
- _Note:_ pseudo instruction represents, in this particular context,
- an abstract measurement of function's size. In no way does it
- represent a count of assembly instructions and as such its exact
- meaning might change from one release to an another.
-
-`-fno-keep-inline-dllexport'
- This is a more fine-grained version of `-fkeep-inline-functions',
- which applies only to functions that are declared using the
- `dllexport' attribute or declspec (*Note Declaring Attributes of
- Functions: Function Attributes.)
-
-`-fkeep-inline-functions'
- In C, emit `static' functions that are declared `inline' into the
- object file, even if the function has been inlined into all of its
- callers. This switch does not affect functions using the `extern
- inline' extension in GNU C90. In C++, emit any and all inline
- functions into the object file.
-
-`-fkeep-static-consts'
- Emit variables declared `static const' when optimization isn't
- turned on, even if the variables aren't referenced.
-
- GCC enables this option by default. If you want to force the
- compiler to check if the variable was referenced, regardless of
- whether or not optimization is turned on, use the
- `-fno-keep-static-consts' option.
-
-`-fmerge-constants'
- Attempt to merge identical constants (string constants and
- floating point constants) across compilation units.
-
- This option is the default for optimized compilation if the
- assembler and linker support it. Use `-fno-merge-constants' to
- inhibit this behavior.
-
- Enabled at levels `-O', `-O2', `-O3', `-Os'.
-
-`-fmerge-all-constants'
- Attempt to merge identical constants and identical variables.
-
- This option implies `-fmerge-constants'. In addition to
- `-fmerge-constants' this considers e.g. even constant initialized
- arrays or initialized constant variables with integral or floating
- point types. Languages like C or C++ require each variable,
- including multiple instances of the same variable in recursive
- calls, to have distinct locations, so using this option will
- result in non-conforming behavior.
-
-`-fmodulo-sched'
- Perform swing modulo scheduling immediately before the first
- scheduling pass. This pass looks at innermost loops and reorders
- their instructions by overlapping different iterations.
-
-`-fmodulo-sched-allow-regmoves'
- Perform more aggressive SMS based modulo scheduling with register
- moves allowed. By setting this flag certain anti-dependences
- edges will be deleted which will trigger the generation of
- reg-moves based on the life-range analysis. This option is
- effective only with `-fmodulo-sched' enabled.
-
-`-fno-branch-count-reg'
- Do not use "decrement and branch" instructions on a count register,
- but instead generate a sequence of instructions that decrement a
- register, compare it against zero, then branch based upon the
- result. This option is only meaningful on architectures that
- support such instructions, which include x86, PowerPC, IA-64 and
- S/390.
-
- The default is `-fbranch-count-reg'.
-
-`-fno-function-cse'
- Do not put function addresses in registers; make each instruction
- that calls a constant function contain the function's address
- explicitly.
-
- This option results in less efficient code, but some strange hacks
- that alter the assembler output may be confused by the
- optimizations performed when this option is not used.
-
- The default is `-ffunction-cse'
-
-`-fno-zero-initialized-in-bss'
- If the target supports a BSS section, GCC by default puts
- variables that are initialized to zero into BSS. This can save
- space in the resulting code.
-
- This option turns off this behavior because some programs
- explicitly rely on variables going to the data section. E.g., so
- that the resulting executable can find the beginning of that
- section and/or make assumptions based on that.
-
- The default is `-fzero-initialized-in-bss'.
-
-`-fmudflap -fmudflapth -fmudflapir'
- For front-ends that support it (C and C++), instrument all risky
- pointer/array dereferencing operations, some standard library
- string/heap functions, and some other associated constructs with
- range/validity tests. Modules so instrumented should be immune to
- buffer overflows, invalid heap use, and some other classes of C/C++
- programming errors. The instrumentation relies on a separate
- runtime library (`libmudflap'), which will be linked into a
- program if `-fmudflap' is given at link time. Run-time behavior
- of the instrumented program is controlled by the `MUDFLAP_OPTIONS'
- environment variable. See `env MUDFLAP_OPTIONS=-help a.out' for
- its options.
-
- Use `-fmudflapth' instead of `-fmudflap' to compile and to link if
- your program is multi-threaded. Use `-fmudflapir', in addition to
- `-fmudflap' or `-fmudflapth', if instrumentation should ignore
- pointer reads. This produces less instrumentation (and therefore
- faster execution) and still provides some protection against
- outright memory corrupting writes, but allows erroneously read
- data to propagate within a program.
-
-`-fthread-jumps'
- Perform optimizations where we check to see if a jump branches to a
- location where another comparison subsumed by the first is found.
- If so, the first branch is redirected to either the destination of
- the second branch or a point immediately following it, depending
- on whether the condition is known to be true or false.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fsplit-wide-types'
- When using a type that occupies multiple registers, such as `long
- long' on a 32-bit system, split the registers apart and allocate
- them independently. This normally generates better code for those
- types, but may make debugging more difficult.
-
- Enabled at levels `-O', `-O2', `-O3', `-Os'.
-
-`-fcse-follow-jumps'
- In common subexpression elimination (CSE), scan through jump
- instructions when the target of the jump is not reached by any
- other path. For example, when CSE encounters an `if' statement
- with an `else' clause, CSE will follow the jump when the condition
- tested is false.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fcse-skip-blocks'
- This is similar to `-fcse-follow-jumps', but causes CSE to follow
- jumps which conditionally skip over blocks. When CSE encounters a
- simple `if' statement with no else clause, `-fcse-skip-blocks'
- causes CSE to follow the jump around the body of the `if'.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-frerun-cse-after-loop'
- Re-run common subexpression elimination after loop optimizations
- has been performed.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fgcse'
- Perform a global common subexpression elimination pass. This pass
- also performs global constant and copy propagation.
-
- _Note:_ When compiling a program using computed gotos, a GCC
- extension, you may get better runtime performance if you disable
- the global common subexpression elimination pass by adding
- `-fno-gcse' to the command line.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fgcse-lm'
- When `-fgcse-lm' is enabled, global common subexpression
- elimination will attempt to move loads which are only killed by
- stores into themselves. This allows a loop containing a
- load/store sequence to be changed to a load outside the loop, and
- a copy/store within the loop.
-
- Enabled by default when gcse is enabled.
-
-`-fgcse-sm'
- When `-fgcse-sm' is enabled, a store motion pass is run after
- global common subexpression elimination. This pass will attempt
- to move stores out of loops. When used in conjunction with
- `-fgcse-lm', loops containing a load/store sequence can be changed
- to a load before the loop and a store after the loop.
-
- Not enabled at any optimization level.
-
-`-fgcse-las'
- When `-fgcse-las' is enabled, the global common subexpression
- elimination pass eliminates redundant loads that come after stores
- to the same memory location (both partial and full redundancies).
-
- Not enabled at any optimization level.
-
-`-fgcse-after-reload'
- When `-fgcse-after-reload' is enabled, a redundant load elimination
- pass is performed after reload. The purpose of this pass is to
- cleanup redundant spilling.
-
-`-funsafe-loop-optimizations'
- If given, the loop optimizer will assume that loop indices do not
- overflow, and that the loops with nontrivial exit condition are not
- infinite. This enables a wider range of loop optimizations even if
- the loop optimizer itself cannot prove that these assumptions are
- valid. Using `-Wunsafe-loop-optimizations', the compiler will
- warn you if it finds this kind of loop.
-
-`-fcrossjumping'
- Perform cross-jumping transformation. This transformation unifies
- equivalent code and save code size. The resulting code may or may
- not perform better than without cross-jumping.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fauto-inc-dec'
- Combine increments or decrements of addresses with memory accesses.
- This pass is always skipped on architectures that do not have
- instructions to support this. Enabled by default at `-O' and
- higher on architectures that support this.
-
-`-fdce'
- Perform dead code elimination (DCE) on RTL. Enabled by default at
- `-O' and higher.
-
-`-fdse'
- Perform dead store elimination (DSE) on RTL. Enabled by default
- at `-O' and higher.
-
-`-fif-conversion'
- Attempt to transform conditional jumps into branch-less
- equivalents. This include use of conditional moves, min, max, set
- flags and abs instructions, and some tricks doable by standard
- arithmetics. The use of conditional execution on chips where it
- is available is controlled by `if-conversion2'.
-
- Enabled at levels `-O', `-O2', `-O3', `-Os'.
-
-`-fif-conversion2'
- Use conditional execution (where available) to transform
- conditional jumps into branch-less equivalents.
-
- Enabled at levels `-O', `-O2', `-O3', `-Os'.
-
-`-fdelete-null-pointer-checks'
- Assume that programs cannot safely dereference null pointers, and
- that no code or data element resides there. This enables simple
- constant folding optimizations at all optimization levels. In
- addition, other optimization passes in GCC use this flag to
- control global dataflow analyses that eliminate useless checks for
- null pointers; these assume that if a pointer is checked after it
- has already been dereferenced, it cannot be null.
-
- Note however that in some environments this assumption is not true.
- Use `-fno-delete-null-pointer-checks' to disable this optimization
- for programs which depend on that behavior.
-
- Some targets, especially embedded ones, disable this option at all
- levels. Otherwise it is enabled at all levels: `-O0', `-O1',
- `-O2', `-O3', `-Os'. Passes that use the information are enabled
- independently at different optimization levels.
-
-`-fdevirtualize'
- Attempt to convert calls to virtual functions to direct calls.
- This is done both within a procedure and interprocedurally as part
- of indirect inlining (`-findirect-inlining') and interprocedural
- constant propagation (`-fipa-cp'). Enabled at levels `-O2',
- `-O3', `-Os'.
-
-`-fexpensive-optimizations'
- Perform a number of minor optimizations that are relatively
- expensive.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-foptimize-register-move'
-`-fregmove'
- Attempt to reassign register numbers in move instructions and as
- operands of other simple instructions in order to maximize the
- amount of register tying. This is especially helpful on machines
- with two-operand instructions.
-
- Note `-fregmove' and `-foptimize-register-move' are the same
- optimization.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fira-algorithm=ALGORITHM'
- Use specified coloring algorithm for the integrated register
- allocator. The ALGORITHM argument should be `priority' or `CB'.
- The first algorithm specifies Chow's priority coloring, the second
- one specifies Chaitin-Briggs coloring. The second algorithm can
- be unimplemented for some architectures. If it is implemented, it
- is the default because Chaitin-Briggs coloring as a rule generates
- a better code.
-
-`-fira-region=REGION'
- Use specified regions for the integrated register allocator. The
- REGION argument should be one of `all', `mixed', or `one'. The
- first value means using all loops as register allocation regions,
- the second value which is the default means using all loops except
- for loops with small register pressure as the regions, and third
- one means using all function as a single region. The first value
- can give best result for machines with small size and irregular
- register set, the third one results in faster and generates decent
- code and the smallest size code, and the default value usually
- give the best results in most cases and for most architectures.
-
-`-fira-loop-pressure'
- Use IRA to evaluate register pressure in loops for decision to move
- loop invariants. Usage of this option usually results in
- generation of faster and smaller code on machines with big
- register files (>= 32 registers) but it can slow compiler down.
-
- This option is enabled at level `-O3' for some targets.
-
-`-fno-ira-share-save-slots'
- Switch off sharing stack slots used for saving call used hard
- registers living through a call. Each hard register will get a
- separate stack slot and as a result function stack frame will be
- bigger.
-
-`-fno-ira-share-spill-slots'
- Switch off sharing stack slots allocated for pseudo-registers.
- Each pseudo-register which did not get a hard register will get a
- separate stack slot and as a result function stack frame will be
- bigger.
-
-`-fira-verbose=N'
- Set up how verbose dump file for the integrated register allocator
- will be. Default value is 5. If the value is greater or equal to
- 10, the dump file will be stderr as if the value were N minus 10.
-
-`-fdelayed-branch'
- If supported for the target machine, attempt to reorder
- instructions to exploit instruction slots available after delayed
- branch instructions.
-
- Enabled at levels `-O', `-O2', `-O3', `-Os'.
-
-`-fschedule-insns'
- If supported for the target machine, attempt to reorder
- instructions to eliminate execution stalls due to required data
- being unavailable. This helps machines that have slow floating
- point or memory load instructions by allowing other instructions
- to be issued until the result of the load or floating point
- instruction is required.
-
- Enabled at levels `-O2', `-O3'.
-
-`-fschedule-insns2'
- Similar to `-fschedule-insns', but requests an additional pass of
- instruction scheduling after register allocation has been done.
- This is especially useful on machines with a relatively small
- number of registers and where memory load instructions take more
- than one cycle.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fno-sched-interblock'
- Don't schedule instructions across basic blocks. This is normally
- enabled by default when scheduling before register allocation, i.e.
- with `-fschedule-insns' or at `-O2' or higher.
-
-`-fno-sched-spec'
- Don't allow speculative motion of non-load instructions. This is
- normally enabled by default when scheduling before register
- allocation, i.e. with `-fschedule-insns' or at `-O2' or higher.
-
-`-fsched-pressure'
- Enable register pressure sensitive insn scheduling before the
- register allocation. This only makes sense when scheduling before
- register allocation is enabled, i.e. with `-fschedule-insns' or at
- `-O2' or higher. Usage of this option can improve the generated
- code and decrease its size by preventing register pressure
- increase above the number of available hard registers and as a
- consequence register spills in the register allocation.
-
-`-fsched-spec-load'
- Allow speculative motion of some load instructions. This only
- makes sense when scheduling before register allocation, i.e. with
- `-fschedule-insns' or at `-O2' or higher.
-
-`-fsched-spec-load-dangerous'
- Allow speculative motion of more load instructions. This only
- makes sense when scheduling before register allocation, i.e. with
- `-fschedule-insns' or at `-O2' or higher.
-
-`-fsched-stalled-insns'
-`-fsched-stalled-insns=N'
- Define how many insns (if any) can be moved prematurely from the
- queue of stalled insns into the ready list, during the second
- scheduling pass. `-fno-sched-stalled-insns' means that no insns
- will be moved prematurely, `-fsched-stalled-insns=0' means there
- is no limit on how many queued insns can be moved prematurely.
- `-fsched-stalled-insns' without a value is equivalent to
- `-fsched-stalled-insns=1'.
-
-`-fsched-stalled-insns-dep'
-`-fsched-stalled-insns-dep=N'
- Define how many insn groups (cycles) will be examined for a
- dependency on a stalled insn that is candidate for premature
- removal from the queue of stalled insns. This has an effect only
- during the second scheduling pass, and only if
- `-fsched-stalled-insns' is used. `-fno-sched-stalled-insns-dep'
- is equivalent to `-fsched-stalled-insns-dep=0'.
- `-fsched-stalled-insns-dep' without a value is equivalent to
- `-fsched-stalled-insns-dep=1'.
-
-`-fsched2-use-superblocks'
- When scheduling after register allocation, do use superblock
- scheduling algorithm. Superblock scheduling allows motion across
- basic block boundaries resulting on faster schedules. This option
- is experimental, as not all machine descriptions used by GCC model
- the CPU closely enough to avoid unreliable results from the
- algorithm.
-
- This only makes sense when scheduling after register allocation,
- i.e. with `-fschedule-insns2' or at `-O2' or higher.
-
-`-fsched-group-heuristic'
- Enable the group heuristic in the scheduler. This heuristic favors
- the instruction that belongs to a schedule group. This is enabled
- by default when scheduling is enabled, i.e. with `-fschedule-insns'
- or `-fschedule-insns2' or at `-O2' or higher.
-
-`-fsched-critical-path-heuristic'
- Enable the critical-path heuristic in the scheduler. This
- heuristic favors instructions on the critical path. This is
- enabled by default when scheduling is enabled, i.e. with
- `-fschedule-insns' or `-fschedule-insns2' or at `-O2' or higher.
-
-`-fsched-spec-insn-heuristic'
- Enable the speculative instruction heuristic in the scheduler.
- This heuristic favors speculative instructions with greater
- dependency weakness. This is enabled by default when scheduling
- is enabled, i.e. with `-fschedule-insns' or `-fschedule-insns2'
- or at `-O2' or higher.
-
-`-fsched-rank-heuristic'
- Enable the rank heuristic in the scheduler. This heuristic favors
- the instruction belonging to a basic block with greater size or
- frequency. This is enabled by default when scheduling is enabled,
- i.e. with `-fschedule-insns' or `-fschedule-insns2' or at `-O2'
- or higher.
-
-`-fsched-last-insn-heuristic'
- Enable the last-instruction heuristic in the scheduler. This
- heuristic favors the instruction that is less dependent on the
- last instruction scheduled. This is enabled by default when
- scheduling is enabled, i.e. with `-fschedule-insns' or
- `-fschedule-insns2' or at `-O2' or higher.
-
-`-fsched-dep-count-heuristic'
- Enable the dependent-count heuristic in the scheduler. This
- heuristic favors the instruction that has more instructions
- depending on it. This is enabled by default when scheduling is
- enabled, i.e. with `-fschedule-insns' or `-fschedule-insns2' or
- at `-O2' or higher.
-
-`-freschedule-modulo-scheduled-loops'
- The modulo scheduling comes before the traditional scheduling, if
- a loop was modulo scheduled we may want to prevent the later
- scheduling passes from changing its schedule, we use this option
- to control that.
-
-`-fselective-scheduling'
- Schedule instructions using selective scheduling algorithm.
- Selective scheduling runs instead of the first scheduler pass.
-
-`-fselective-scheduling2'
- Schedule instructions using selective scheduling algorithm.
- Selective scheduling runs instead of the second scheduler pass.
-
-`-fsel-sched-pipelining'
- Enable software pipelining of innermost loops during selective
- scheduling. This option has no effect until one of
- `-fselective-scheduling' or `-fselective-scheduling2' is turned on.
-
-`-fsel-sched-pipelining-outer-loops'
- When pipelining loops during selective scheduling, also pipeline
- outer loops. This option has no effect until
- `-fsel-sched-pipelining' is turned on.
-
-`-fcaller-saves'
- Enable values to be allocated in registers that will be clobbered
- by function calls, by emitting extra instructions to save and
- restore the registers around such calls. Such allocation is done
- only when it seems to result in better code than would otherwise
- be produced.
-
- This option is always enabled by default on certain machines,
- usually those which have no call-preserved registers to use
- instead.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fcombine-stack-adjustments'
- Tracks stack adjustments (pushes and pops) and stack memory
- references and then tries to find ways to combine them.
-
- Enabled by default at `-O1' and higher.
-
-`-fconserve-stack'
- Attempt to minimize stack usage. The compiler will attempt to use
- less stack space, even if that makes the program slower. This
- option implies setting the `large-stack-frame' parameter to 100
- and the `large-stack-frame-growth' parameter to 400.
-
-`-ftree-reassoc'
- Perform reassociation on trees. This flag is enabled by default
- at `-O' and higher.
-
-`-ftree-pre'
- Perform partial redundancy elimination (PRE) on trees. This flag
- is enabled by default at `-O2' and `-O3'.
-
-`-ftree-forwprop'
- Perform forward propagation on trees. This flag is enabled by
- default at `-O' and higher.
-
-`-ftree-fre'
- Perform full redundancy elimination (FRE) on trees. The difference
- between FRE and PRE is that FRE only considers expressions that
- are computed on all paths leading to the redundant computation.
- This analysis is faster than PRE, though it exposes fewer
- redundancies. This flag is enabled by default at `-O' and higher.
-
-`-ftree-phiprop'
- Perform hoisting of loads from conditional pointers on trees. This
- pass is enabled by default at `-O' and higher.
-
-`-ftree-copy-prop'
- Perform copy propagation on trees. This pass eliminates
- unnecessary copy operations. This flag is enabled by default at
- `-O' and higher.
-
-`-fipa-pure-const'
- Discover which functions are pure or constant. Enabled by default
- at `-O' and higher.
-
-`-fipa-reference'
- Discover which static variables do not escape cannot escape the
- compilation unit. Enabled by default at `-O' and higher.
-
-`-fipa-struct-reorg'
- Perform structure reorganization optimization, that change C-like
- structures layout in order to better utilize spatial locality.
- This transformation is affective for programs containing arrays of
- structures. Available in two compilation modes: profile-based
- (enabled with `-fprofile-generate') or static (which uses built-in
- heuristics). It works only in whole program mode, so it requires
- `-fwhole-program' to be enabled. Structures considered `cold' by
- this transformation are not affected (see `--param
- struct-reorg-cold-struct-ratio=VALUE').
-
- With this flag, the program debug info reflects a new structure
- layout.
-
-`-fipa-pta'
- Perform interprocedural pointer analysis and interprocedural
- modification and reference analysis. This option can cause
- excessive memory and compile-time usage on large compilation
- units. It is not enabled by default at any optimization level.
-
-`-fipa-profile'
- Perform interprocedural profile propagation. The functions called
- only from cold functions are marked as cold. Also functions
- executed once (such as `cold', `noreturn', static constructors or
- destructors) are identified. Cold functions and loop less parts of
- functions executed once are then optimized for size. Enabled by
- default at `-O' and higher.
-
-`-fipa-cp'
- Perform interprocedural constant propagation. This optimization
- analyzes the program to determine when values passed to functions
- are constants and then optimizes accordingly. This optimization
- can substantially increase performance if the application has
- constants passed to functions. This flag is enabled by default at
- `-O2', `-Os' and `-O3'.
-
-`-fipa-cp-clone'
- Perform function cloning to make interprocedural constant
- propagation stronger. When enabled, interprocedural constant
- propagation will perform function cloning when externally visible
- function can be called with constant arguments. Because this
- optimization can create multiple copies of functions, it may
- significantly increase code size (see `--param
- ipcp-unit-growth=VALUE'). This flag is enabled by default at
- `-O3'.
-
-`-fipa-matrix-reorg'
- Perform matrix flattening and transposing. Matrix flattening
- tries to replace an m-dimensional matrix with its equivalent
- n-dimensional matrix, where n < m. This reduces the level of
- indirection needed for accessing the elements of the matrix. The
- second optimization is matrix transposing that attempts to change
- the order of the matrix's dimensions in order to improve cache
- locality. Both optimizations need the `-fwhole-program' flag.
- Transposing is enabled only if profiling information is available.
-
-`-ftree-sink'
- Perform forward store motion on trees. This flag is enabled by
- default at `-O' and higher.
-
-`-ftree-bit-ccp'
- Perform sparse conditional bit constant propagation on trees and
- propagate pointer alignment information. This pass only operates
- on local scalar variables and is enabled by default at `-O' and
- higher. It requires that `-ftree-ccp' is enabled.
-
-`-ftree-ccp'
- Perform sparse conditional constant propagation (CCP) on trees.
- This pass only operates on local scalar variables and is enabled
- by default at `-O' and higher.
-
-`-ftree-switch-conversion'
- Perform conversion of simple initializations in a switch to
- initializations from a scalar array. This flag is enabled by
- default at `-O2' and higher.
-
-`-ftree-dce'
- Perform dead code elimination (DCE) on trees. This flag is
- enabled by default at `-O' and higher.
-
-`-ftree-builtin-call-dce'
- Perform conditional dead code elimination (DCE) for calls to
- builtin functions that may set `errno' but are otherwise
- side-effect free. This flag is enabled by default at `-O2' and
- higher if `-Os' is not also specified.
-
-`-ftree-dominator-opts'
- Perform a variety of simple scalar cleanups (constant/copy
- propagation, redundancy elimination, range propagation and
- expression simplification) based on a dominator tree traversal.
- This also performs jump threading (to reduce jumps to jumps). This
- flag is enabled by default at `-O' and higher.
-
-`-ftree-dse'
- Perform dead store elimination (DSE) on trees. A dead store is a
- store into a memory location which will later be overwritten by
- another store without any intervening loads. In this case the
- earlier store can be deleted. This flag is enabled by default at
- `-O' and higher.
-
-`-ftree-ch'
- Perform loop header copying on trees. This is beneficial since it
- increases effectiveness of code motion optimizations. It also
- saves one jump. This flag is enabled by default at `-O' and
- higher. It is not enabled for `-Os', since it usually increases
- code size.
-
-`-ftree-loop-optimize'
- Perform loop optimizations on trees. This flag is enabled by
- default at `-O' and higher.
-
-`-ftree-loop-linear'
- Perform loop interchange transformations on tree. Same as
- `-floop-interchange'. To use this code transformation, GCC has to
- be configured with `--with-ppl' and `--with-cloog' to enable the
- Graphite loop transformation infrastructure.
-
-`-floop-interchange'
- Perform loop interchange transformations on loops. Interchanging
- two nested loops switches the inner and outer loops. For example,
- given a loop like:
- DO J = 1, M
- DO I = 1, N
- A(J, I) = A(J, I) * C
- ENDDO
- ENDDO
- loop interchange will transform the loop as if the user had
- written:
- DO I = 1, N
- DO J = 1, M
- A(J, I) = A(J, I) * C
- ENDDO
- ENDDO
- which can be beneficial when `N' is larger than the caches,
- because in Fortran, the elements of an array are stored in memory
- contiguously by column, and the original loop iterates over rows,
- potentially creating at each access a cache miss. This
- optimization applies to all the languages supported by GCC and is
- not limited to Fortran. To use this code transformation, GCC has
- to be configured with `--with-ppl' and `--with-cloog' to enable the
- Graphite loop transformation infrastructure.
-
-`-floop-strip-mine'
- Perform loop strip mining transformations on loops. Strip mining
- splits a loop into two nested loops. The outer loop has strides
- equal to the strip size and the inner loop has strides of the
- original loop within a strip. The strip length can be changed
- using the `loop-block-tile-size' parameter. For example, given a
- loop like:
- DO I = 1, N
- A(I) = A(I) + C
- ENDDO
- loop strip mining will transform the loop as if the user had
- written:
- DO II = 1, N, 51
- DO I = II, min (II + 50, N)
- A(I) = A(I) + C
- ENDDO
- ENDDO
- This optimization applies to all the languages supported by GCC
- and is not limited to Fortran. To use this code transformation,
- GCC has to be configured with `--with-ppl' and `--with-cloog' to
- enable the Graphite loop transformation infrastructure.
-
-`-floop-block'
- Perform loop blocking transformations on loops. Blocking strip
- mines each loop in the loop nest such that the memory accesses of
- the element loops fit inside caches. The strip length can be
- changed using the `loop-block-tile-size' parameter. For example,
- given a loop like:
- DO I = 1, N
- DO J = 1, M
- A(J, I) = B(I) + C(J)
- ENDDO
- ENDDO
- loop blocking will transform the loop as if the user had written:
- DO II = 1, N, 51
- DO JJ = 1, M, 51
- DO I = II, min (II + 50, N)
- DO J = JJ, min (JJ + 50, M)
- A(J, I) = B(I) + C(J)
- ENDDO
- ENDDO
- ENDDO
- ENDDO
- which can be beneficial when `M' is larger than the caches,
- because the innermost loop will iterate over a smaller amount of
- data that can be kept in the caches. This optimization applies to
- all the languages supported by GCC and is not limited to Fortran.
- To use this code transformation, GCC has to be configured with
- `--with-ppl' and `--with-cloog' to enable the Graphite loop
- transformation infrastructure.
-
-`-fgraphite-identity'
- Enable the identity transformation for graphite. For every SCoP
- we generate the polyhedral representation and transform it back to
- gimple. Using `-fgraphite-identity' we can check the costs or
- benefits of the GIMPLE -> GRAPHITE -> GIMPLE transformation. Some
- minimal optimizations are also performed by the code generator
- CLooG, like index splitting and dead code elimination in loops.
-
-`-floop-flatten'
- Removes the loop nesting structure: transforms the loop nest into a
- single loop. This transformation can be useful to vectorize all
- the levels of the loop nest.
-
-`-floop-parallelize-all'
- Use the Graphite data dependence analysis to identify loops that
- can be parallelized. Parallelize all the loops that can be
- analyzed to not contain loop carried dependences without checking
- that it is profitable to parallelize the loops.
-
-`-fcheck-data-deps'
- Compare the results of several data dependence analyzers. This
- option is used for debugging the data dependence analyzers.
-
-`-ftree-loop-if-convert'
- Attempt to transform conditional jumps in the innermost loops to
- branch-less equivalents. The intent is to remove control-flow from
- the innermost loops in order to improve the ability of the
- vectorization pass to handle these loops. This is enabled by
- default if vectorization is enabled.
-
-`-ftree-loop-if-convert-stores'
- Attempt to also if-convert conditional jumps containing memory
- writes. This transformation can be unsafe for multi-threaded
- programs as it transforms conditional memory writes into
- unconditional memory writes. For example,
- for (i = 0; i < N; i++)
- if (cond)
- A[i] = expr;
- would be transformed to
- for (i = 0; i < N; i++)
- A[i] = cond ? expr : A[i];
- potentially producing data races.
-
-`-ftree-loop-distribution'
- Perform loop distribution. This flag can improve cache
- performance on big loop bodies and allow further loop
- optimizations, like parallelization or vectorization, to take
- place. For example, the loop
- DO I = 1, N
- A(I) = B(I) + C
- D(I) = E(I) * F
- ENDDO
- is transformed to
- DO I = 1, N
- A(I) = B(I) + C
- ENDDO
- DO I = 1, N
- D(I) = E(I) * F
- ENDDO
-
-`-ftree-loop-distribute-patterns'
- Perform loop distribution of patterns that can be code generated
- with calls to a library. This flag is enabled by default at `-O3'.
-
- This pass distributes the initialization loops and generates a
- call to memset zero. For example, the loop
- DO I = 1, N
- A(I) = 0
- B(I) = A(I) + I
- ENDDO
- is transformed to
- DO I = 1, N
- A(I) = 0
- ENDDO
- DO I = 1, N
- B(I) = A(I) + I
- ENDDO
- and the initialization loop is transformed into a call to memset
- zero.
-
-`-ftree-loop-im'
- Perform loop invariant motion on trees. This pass moves only
- invariants that would be hard to handle at RTL level (function
- calls, operations that expand to nontrivial sequences of insns).
- With `-funswitch-loops' it also moves operands of conditions that
- are invariant out of the loop, so that we can use just trivial
- invariantness analysis in loop unswitching. The pass also includes
- store motion.
-
-`-ftree-loop-ivcanon'
- Create a canonical counter for number of iterations in the loop
- for that determining number of iterations requires complicated
- analysis. Later optimizations then may determine the number
- easily. Useful especially in connection with unrolling.
-
-`-fivopts'
- Perform induction variable optimizations (strength reduction,
- induction variable merging and induction variable elimination) on
- trees.
-
-`-ftree-parallelize-loops=n'
- Parallelize loops, i.e., split their iteration space to run in n
- threads. This is only possible for loops whose iterations are
- independent and can be arbitrarily reordered. The optimization is
- only profitable on multiprocessor machines, for loops that are
- CPU-intensive, rather than constrained e.g. by memory bandwidth.
- This option implies `-pthread', and thus is only supported on
- targets that have support for `-pthread'.
-
-`-ftree-pta'
- Perform function-local points-to analysis on trees. This flag is
- enabled by default at `-O' and higher.
-
-`-ftree-sra'
- Perform scalar replacement of aggregates. This pass replaces
- structure references with scalars to prevent committing structures
- to memory too early. This flag is enabled by default at `-O' and
- higher.
-
-`-ftree-copyrename'
- Perform copy renaming on trees. This pass attempts to rename
- compiler temporaries to other variables at copy locations, usually
- resulting in variable names which more closely resemble the
- original variables. This flag is enabled by default at `-O' and
- higher.
-
-`-ftree-ter'
- Perform temporary expression replacement during the SSA->normal
- phase. Single use/single def temporaries are replaced at their
- use location with their defining expression. This results in
- non-GIMPLE code, but gives the expanders much more complex trees
- to work on resulting in better RTL generation. This is enabled by
- default at `-O' and higher.
-
-`-ftree-vectorize'
- Perform loop vectorization on trees. This flag is enabled by
- default at `-O3'.
-
-`-ftree-slp-vectorize'
- Perform basic block vectorization on trees. This flag is enabled
- by default at `-O3' and when `-ftree-vectorize' is enabled.
-
-`-ftree-vect-loop-version'
- Perform loop versioning when doing loop vectorization on trees.
- When a loop appears to be vectorizable except that data alignment
- or data dependence cannot be determined at compile time then
- vectorized and non-vectorized versions of the loop are generated
- along with runtime checks for alignment or dependence to control
- which version is executed. This option is enabled by default
- except at level `-Os' where it is disabled.
-
-`-fvect-cost-model'
- Enable cost model for vectorization.
-
-`-ftree-vrp'
- Perform Value Range Propagation on trees. This is similar to the
- constant propagation pass, but instead of values, ranges of values
- are propagated. This allows the optimizers to remove unnecessary
- range checks like array bound checks and null pointer checks.
- This is enabled by default at `-O2' and higher. Null pointer check
- elimination is only done if `-fdelete-null-pointer-checks' is
- enabled.
-
-`-ftracer'
- Perform tail duplication to enlarge superblock size. This
- transformation simplifies the control flow of the function
- allowing other optimizations to do better job.
-
-`-funroll-loops'
- Unroll loops whose number of iterations can be determined at
- compile time or upon entry to the loop. `-funroll-loops' implies
- `-frerun-cse-after-loop'. This option makes code larger, and may
- or may not make it run faster.
-
-`-funroll-all-loops'
- Unroll all loops, even if their number of iterations is uncertain
- when the loop is entered. This usually makes programs run more
- slowly. `-funroll-all-loops' implies the same options as
- `-funroll-loops',
-
-`-fsplit-ivs-in-unroller'
- Enables expressing of values of induction variables in later
- iterations of the unrolled loop using the value in the first
- iteration. This breaks long dependency chains, thus improving
- efficiency of the scheduling passes.
-
- Combination of `-fweb' and CSE is often sufficient to obtain the
- same effect. However in cases the loop body is more complicated
- than a single basic block, this is not reliable. It also does not
- work at all on some of the architectures due to restrictions in
- the CSE pass.
-
- This optimization is enabled by default.
-
-`-fvariable-expansion-in-unroller'
- With this option, the compiler will create multiple copies of some
- local variables when unrolling a loop which can result in superior
- code.
-
-`-fpartial-inlining'
- Inline parts of functions. This option has any effect only when
- inlining itself is turned on by the `-finline-functions' or
- `-finline-small-functions' options.
-
- Enabled at level `-O2'.
-
-`-fpredictive-commoning'
- Perform predictive commoning optimization, i.e., reusing
- computations (especially memory loads and stores) performed in
- previous iterations of loops.
-
- This option is enabled at level `-O3'.
-
-`-fprefetch-loop-arrays'
- If supported by the target machine, generate instructions to
- prefetch memory to improve the performance of loops that access
- large arrays.
-
- This option may generate better or worse code; results are highly
- dependent on the structure of loops within the source code.
-
- Disabled at level `-Os'.
-
-`-fno-peephole'
-`-fno-peephole2'
- Disable any machine-specific peephole optimizations. The
- difference between `-fno-peephole' and `-fno-peephole2' is in how
- they are implemented in the compiler; some targets use one, some
- use the other, a few use both.
-
- `-fpeephole' is enabled by default. `-fpeephole2' enabled at
- levels `-O2', `-O3', `-Os'.
-
-`-fno-guess-branch-probability'
- Do not guess branch probabilities using heuristics.
-
- GCC will use heuristics to guess branch probabilities if they are
- not provided by profiling feedback (`-fprofile-arcs'). These
- heuristics are based on the control flow graph. If some branch
- probabilities are specified by `__builtin_expect', then the
- heuristics will be used to guess branch probabilities for the rest
- of the control flow graph, taking the `__builtin_expect' info into
- account. The interactions between the heuristics and
- `__builtin_expect' can be complex, and in some cases, it may be
- useful to disable the heuristics so that the effects of
- `__builtin_expect' are easier to understand.
-
- The default is `-fguess-branch-probability' at levels `-O', `-O2',
- `-O3', `-Os'.
-
-`-freorder-blocks'
- Reorder basic blocks in the compiled function in order to reduce
- number of taken branches and improve code locality.
-
- Enabled at levels `-O2', `-O3'.
-
-`-freorder-blocks-and-partition'
- In addition to reordering basic blocks in the compiled function,
- in order to reduce number of taken branches, partitions hot and
- cold basic blocks into separate sections of the assembly and .o
- files, to improve paging and cache locality performance.
-
- This optimization is automatically turned off in the presence of
- exception handling, for linkonce sections, for functions with a
- user-defined section attribute and on any architecture that does
- not support named sections.
-
-`-freorder-functions'
- Reorder functions in the object file in order to improve code
- locality. This is implemented by using special subsections
- `.text.hot' for most frequently executed functions and
- `.text.unlikely' for unlikely executed functions. Reordering is
- done by the linker so object file format must support named
- sections and linker must place them in a reasonable way.
-
- Also profile feedback must be available in to make this option
- effective. See `-fprofile-arcs' for details.
-
- Enabled at levels `-O2', `-O3', `-Os'.
-
-`-fstrict-aliasing'
- Allow the compiler to assume the strictest aliasing rules
- applicable to the language being compiled. For C (and C++), this
- activates optimizations based on the type of expressions. In
- particular, an object of one type is assumed never to reside at
- the same address as an object of a different type, unless the
- types are almost the same. For example, an `unsigned int' can
- alias an `int', but not a `void*' or a `double'. A character type
- may alias any other type.
-
- Pay special attention to code like this:
- union a_union {
- int i;
- double d;
- };
-
- int f() {
- union a_union t;
- t.d = 3.0;
- return t.i;
- }
- The practice of reading from a different union member than the one
- most recently written to (called "type-punning") is common. Even
- with `-fstrict-aliasing', type-punning is allowed, provided the
- memory is accessed through the union type. So, the code above
- will work as expected. *Note Structures unions enumerations and
- bit-fields implementation::. However, this code might not:
- int f() {
- union a_union t;
- int* ip;
- t.d = 3.0;
- ip = &t.i;
- return *ip;
- }
-
- Similarly, access by taking the address, casting the resulting
- pointer and dereferencing the result has undefined behavior, even
- if the cast uses a union type, e.g.:
- int f() {
- double d = 3.0;
- return ((union a_union *) &d)->i;
- }
-
- The `-fstrict-aliasing' option is enabled at levels `-O2', `-O3',
- `-Os'.
-
-`-fstrict-overflow'
- Allow the compiler to assume strict signed overflow rules,
- depending on the language being compiled. For C (and C++) this
- means that overflow when doing arithmetic with signed numbers is
- undefined, which means that the compiler may assume that it will
- not happen. This permits various optimizations. For example, the
- compiler will assume that an expression like `i + 10 > i' will
- always be true for signed `i'. This assumption is only valid if
- signed overflow is undefined, as the expression is false if `i +
- 10' overflows when using twos complement arithmetic. When this
- option is in effect any attempt to determine whether an operation
- on signed numbers will overflow must be written carefully to not
- actually involve overflow.
-
- This option also allows the compiler to assume strict pointer
- semantics: given a pointer to an object, if adding an offset to
- that pointer does not produce a pointer to the same object, the
- addition is undefined. This permits the compiler to conclude that
- `p + u > p' is always true for a pointer `p' and unsigned integer
- `u'. This assumption is only valid because pointer wraparound is
- undefined, as the expression is false if `p + u' overflows using
- twos complement arithmetic.
-
- See also the `-fwrapv' option. Using `-fwrapv' means that integer
- signed overflow is fully defined: it wraps. When `-fwrapv' is
- used, there is no difference between `-fstrict-overflow' and
- `-fno-strict-overflow' for integers. With `-fwrapv' certain types
- of overflow are permitted. For example, if the compiler gets an
- overflow when doing arithmetic on constants, the overflowed value
- can still be used with `-fwrapv', but not otherwise.
-
- The `-fstrict-overflow' option is enabled at levels `-O2', `-O3',
- `-Os'.
-
-`-falign-functions'
-`-falign-functions=N'
- Align the start of functions to the next power-of-two greater than
- N, skipping up to N bytes. For instance, `-falign-functions=32'
- aligns functions to the next 32-byte boundary, but
- `-falign-functions=24' would align to the next 32-byte boundary
- only if this can be done by skipping 23 bytes or less.
-
- `-fno-align-functions' and `-falign-functions=1' are equivalent
- and mean that functions will not be aligned.
-
- Some assemblers only support this flag when N is a power of two;
- in that case, it is rounded up.
-
- If N is not specified or is zero, use a machine-dependent default.
-
- Enabled at levels `-O2', `-O3'.
-
-`-falign-labels'
-`-falign-labels=N'
- Align all branch targets to a power-of-two boundary, skipping up to
- N bytes like `-falign-functions'. This option can easily make
- code slower, because it must insert dummy operations for when the
- branch target is reached in the usual flow of the code.
-
- `-fno-align-labels' and `-falign-labels=1' are equivalent and mean
- that labels will not be aligned.
-
- If `-falign-loops' or `-falign-jumps' are applicable and are
- greater than this value, then their values are used instead.
-
- If N is not specified or is zero, use a machine-dependent default
- which is very likely to be `1', meaning no alignment.
-
- Enabled at levels `-O2', `-O3'.
-
-`-falign-loops'
-`-falign-loops=N'
- Align loops to a power-of-two boundary, skipping up to N bytes
- like `-falign-functions'. The hope is that the loop will be
- executed many times, which will make up for any execution of the
- dummy operations.
-
- `-fno-align-loops' and `-falign-loops=1' are equivalent and mean
- that loops will not be aligned.
-
- If N is not specified or is zero, use a machine-dependent default.
-
- Enabled at levels `-O2', `-O3'.
-
-`-falign-jumps'
-`-falign-jumps=N'
- Align branch targets to a power-of-two boundary, for branch targets
- where the targets can only be reached by jumping, skipping up to N
- bytes like `-falign-functions'. In this case, no dummy operations
- need be executed.
-
- `-fno-align-jumps' and `-falign-jumps=1' are equivalent and mean
- that loops will not be aligned.
-
- If N is not specified or is zero, use a machine-dependent default.
-
- Enabled at levels `-O2', `-O3'.
-
-`-funit-at-a-time'
- This option is left for compatibility reasons. `-funit-at-a-time'
- has no effect, while `-fno-unit-at-a-time' implies
- `-fno-toplevel-reorder' and `-fno-section-anchors'.
-
- Enabled by default.
-
-`-fno-toplevel-reorder'
- Do not reorder top-level functions, variables, and `asm'
- statements. Output them in the same order that they appear in the
- input file. When this option is used, unreferenced static
- variables will not be removed. This option is intended to support
- existing code which relies on a particular ordering. For new
- code, it is better to use attributes.
-
- Enabled at level `-O0'. When disabled explicitly, it also imply
- `-fno-section-anchors' that is otherwise enabled at `-O0' on some
- targets.
-
-`-fweb'
- Constructs webs as commonly used for register allocation purposes
- and assign each web individual pseudo register. This allows the
- register allocation pass to operate on pseudos directly, but also
- strengthens several other optimization passes, such as CSE, loop
- optimizer and trivial dead code remover. It can, however, make
- debugging impossible, since variables will no longer stay in a
- "home register".
-
- Enabled by default with `-funroll-loops'.
-
-`-fwhole-program'
- Assume that the current compilation unit represents the whole
- program being compiled. All public functions and variables with
- the exception of `main' and those merged by attribute
- `externally_visible' become static functions and in effect are
- optimized more aggressively by interprocedural optimizers. If
- `gold' is used as the linker plugin, `externally_visible'
- attributes are automatically added to functions (not variable yet
- due to a current `gold' issue) that are accessed outside of LTO
- objects according to resolution file produced by `gold'. For
- other linkers that cannot generate resolution file, explicit
- `externally_visible' attributes are still necessary. While this
- option is equivalent to proper use of the `static' keyword for
- programs consisting of a single file, in combination with option
- `-flto' this flag can be used to compile many smaller scale
- programs since the functions and variables become local for the
- whole combined compilation unit, not for the single source file
- itself.
-
- This option implies `-fwhole-file' for Fortran programs.
-
-`-flto[=N]'
- This option runs the standard link-time optimizer. When invoked
- with source code, it generates GIMPLE (one of GCC's internal
- representations) and writes it to special ELF sections in the
- object file. When the object files are linked together, all the
- function bodies are read from these ELF sections and instantiated
- as if they had been part of the same translation unit.
-
- To use the link-time optimizer, `-flto' needs to be specified at
- compile time and during the final link. For example:
-
- gcc -c -O2 -flto foo.c
- gcc -c -O2 -flto bar.c
- gcc -o myprog -flto -O2 foo.o bar.o
-
- The first two invocations to GCC save a bytecode representation of
- GIMPLE into special ELF sections inside `foo.o' and `bar.o'. The
- final invocation reads the GIMPLE bytecode from `foo.o' and
- `bar.o', merges the two files into a single internal image, and
- compiles the result as usual. Since both `foo.o' and `bar.o' are
- merged into a single image, this causes all the interprocedural
- analyses and optimizations in GCC to work across the two files as
- if they were a single one. This means, for example, that the
- inliner is able to inline functions in `bar.o' into functions in
- `foo.o' and vice-versa.
-
- Another (simpler) way to enable link-time optimization is:
-
- gcc -o myprog -flto -O2 foo.c bar.c
-
- The above generates bytecode for `foo.c' and `bar.c', merges them
- together into a single GIMPLE representation and optimizes them as
- usual to produce `myprog'.
-
- The only important thing to keep in mind is that to enable
- link-time optimizations the `-flto' flag needs to be passed to
- both the compile and the link commands.
-
- To make whole program optimization effective, it is necessary to
- make certain whole program assumptions. The compiler needs to know
- what functions and variables can be accessed by libraries and
- runtime outside of the link-time optimized unit. When supported
- by the linker, the linker plugin (see `-fuse-linker-plugin')
- passes information to the compiler about used and externally
- visible symbols. When the linker plugin is not available,
- `-fwhole-program' should be used to allow the compiler to make
- these assumptions, which leads to more aggressive optimization
- decisions.
-
- Note that when a file is compiled with `-flto', the generated
- object file is larger than a regular object file because it
- contains GIMPLE bytecodes and the usual final code. This means
- that object files with LTO information can be linked as normal
- object files; if `-flto' is not passed to the linker, no
- interprocedural optimizations are applied.
-
- Additionally, the optimization flags used to compile individual
- files are not necessarily related to those used at link time. For
- instance,
-
- gcc -c -O0 -flto foo.c
- gcc -c -O0 -flto bar.c
- gcc -o myprog -flto -O3 foo.o bar.o
-
- This produces individual object files with unoptimized assembler
- code, but the resulting binary `myprog' is optimized at `-O3'.
- If, instead, the final binary is generated without `-flto', then
- `myprog' is not optimized.
-
- When producing the final binary with `-flto', GCC only applies
- link-time optimizations to those files that contain bytecode.
- Therefore, you can mix and match object files and libraries with
- GIMPLE bytecodes and final object code. GCC automatically selects
- which files to optimize in LTO mode and which files to link without
- further processing.
-
- There are some code generation flags that GCC preserves when
- generating bytecodes, as they need to be used during the final link
- stage. Currently, the following options are saved into the GIMPLE
- bytecode files: `-fPIC', `-fcommon' and all the `-m' target flags.
-
- At link time, these options are read in and reapplied. Note that
- the current implementation makes no attempt to recognize
- conflicting values for these options. If different files have
- conflicting option values (e.g., one file is compiled with `-fPIC'
- and another isn't), the compiler simply uses the last value read
- from the bytecode files. It is recommended, then, that you
- compile all the files participating in the same link with the same
- options.
-
- If LTO encounters objects with C linkage declared with incompatible
- types in separate translation units to be linked together
- (undefined behavior according to ISO C99 6.2.7), a non-fatal
- diagnostic may be issued. The behavior is still undefined at
- runtime.
-
- Another feature of LTO is that it is possible to apply
- interprocedural optimizations on files written in different
- languages. This requires support in the language front end.
- Currently, the C, C++ and Fortran front ends are capable of
- emitting GIMPLE bytecodes, so something like this should work:
-
- gcc -c -flto foo.c
- g++ -c -flto bar.cc
- gfortran -c -flto baz.f90
- g++ -o myprog -flto -O3 foo.o bar.o baz.o -lgfortran
-
- Notice that the final link is done with `g++' to get the C++
- runtime libraries and `-lgfortran' is added to get the Fortran
- runtime libraries. In general, when mixing languages in LTO mode,
- you should use the same link command options as when mixing
- languages in a regular (non-LTO) compilation; all you need to add
- is `-flto' to all the compile and link commands.
-
- If object files containing GIMPLE bytecode are stored in a library
- archive, say `libfoo.a', it is possible to extract and use them in
- an LTO link if you are using a linker with plugin support. To
- enable this feature, use the flag `-fuse-linker-plugin' at link
- time:
-
- gcc -o myprog -O2 -flto -fuse-linker-plugin a.o b.o -lfoo
-
- With the linker plugin enabled, the linker extracts the needed
- GIMPLE files from `libfoo.a' and passes them on to the running GCC
- to make them part of the aggregated GIMPLE image to be optimized.
-
- If you are not using a linker with plugin support and/or do not
- enable the linker plugin, then the objects inside `libfoo.a' are
- extracted and linked as usual, but they do not participate in the
- LTO optimization process.
-
- Link-time optimizations do not require the presence of the whole
- program to operate. If the program does not require any symbols
- to be exported, it is possible to combine `-flto' and
- `-fwhole-program' to allow the interprocedural optimizers to use
- more aggressive assumptions which may lead to improved
- optimization opportunities. Use of `-fwhole-program' is not
- needed when linker plugin is active (see `-fuse-linker-plugin').
-
- The current implementation of LTO makes no attempt to generate
- bytecode that is portable between different types of hosts. The
- bytecode files are versioned and there is a strict version check,
- so bytecode files generated in one version of GCC will not work
- with an older/newer version of GCC.
-
- Link-time optimization does not work well with generation of
- debugging information. Combining `-flto' with `-g' is currently
- experimental and expected to produce wrong results.
-
- If you specify the optional N, the optimization and code
- generation done at link time is executed in parallel using N
- parallel jobs by utilizing an installed `make' program. The
- environment variable `MAKE' may be used to override the program
- used. The default value for N is 1.
-
- You can also specify `-flto=jobserver' to use GNU make's job
- server mode to determine the number of parallel jobs. This is
- useful when the Makefile calling GCC is already executing in
- parallel. You must prepend a `+' to the command recipe in the
- parent Makefile for this to work. This option likely only works
- if `MAKE' is GNU make.
-
- This option is disabled by default.
-
-`-flto-partition=ALG'
- Specify the partitioning algorithm used by the link-time optimizer.
- The value is either `1to1' to specify a partitioning mirroring the
- original source files or `balanced' to specify partitioning into
- equally sized chunks (whenever possible). Specifying `none' as an
- algorithm disables partitioning and streaming completely. The
- default value is `balanced'.
-
-`-flto-compression-level=N'
- This option specifies the level of compression used for
- intermediate language written to LTO object files, and is only
- meaningful in conjunction with LTO mode (`-flto'). Valid values
- are 0 (no compression) to 9 (maximum compression). Values outside
- this range are clamped to either 0 or 9. If the option is not
- given, a default balanced compression setting is used.
-
-`-flto-report'
- Prints a report with internal details on the workings of the
- link-time optimizer. The contents of this report vary from
- version to version. It is meant to be useful to GCC developers
- when processing object files in LTO mode (via `-flto').
-
- Disabled by default.
-
-`-fuse-linker-plugin'
- Enables the use of a linker plugin during link-time optimization.
- This option relies on the linker plugin support in linker that is
- available in gold or in GNU ld 2.21 or newer.
-
- This option enables the extraction of object files with GIMPLE
- bytecode out of library archives. This improves the quality of
- optimization by exposing more code to the link-time optimizer.
- This information specifies what symbols can be accessed externally
- (by non-LTO object or during dynamic linking). Resulting code
- quality improvements on binaries (and shared libraries that use
- hidden visibility) are similar to `-fwhole-program'. See `-flto'
- for a description of the effect of this flag and how to use it.
-
- This option is enabled by default when LTO support in GCC is
- enabled and GCC was configured for use with a linker supporting
- plugins (GNU ld 2.21 or newer or gold).
-
-`-fcompare-elim'
- After register allocation and post-register allocation instruction
- splitting, identify arithmetic instructions that compute processor
- flags similar to a comparison operation based on that arithmetic.
- If possible, eliminate the explicit comparison operation.
-
- This pass only applies to certain targets that cannot explicitly
- represent the comparison operation before register allocation is
- complete.
-
- Enabled at levels `-O', `-O2', `-O3', `-Os'.
-
-`-fuse-ld=gold'
- Use the `gold' linker instead of the default linker. This option
- is only necessary if GCC has been configured with `--enable-gold'
- and `--enable-ld=default'.
-
-`-fuse-ld=bfd'
- Use the `ld.bfd' linker instead of the default linker. This
- option is only necessary if GCC has been configured with
- `--enable-gold' and `--enable-ld'.
-
-`-fcprop-registers'
- After register allocation and post-register allocation instruction
- splitting, we perform a copy-propagation pass to try to reduce
- scheduling dependencies and occasionally eliminate the copy.
-
- Enabled at levels `-O', `-O2', `-O3', `-Os'.
-
-`-fprofile-correction'
- Profiles collected using an instrumented binary for multi-threaded
- programs may be inconsistent due to missed counter updates. When
- this option is specified, GCC will use heuristics to correct or
- smooth out such inconsistencies. By default, GCC will emit an
- error message when an inconsistent profile is detected.
-
-`-fprofile-dir=PATH'
- Set the directory to search for the profile data files in to PATH.
- This option affects only the profile data generated by
- `-fprofile-generate', `-ftest-coverage', `-fprofile-arcs' and used
- by `-fprofile-use' and `-fbranch-probabilities' and its related
- options. Both absolute and relative paths can be used. By
- default, GCC will use the current directory as PATH, thus the
- profile data file will appear in the same directory as the object
- file.
-
-`-fprofile-generate'
-`-fprofile-generate=PATH'
- Enable options usually used for instrumenting application to
- produce profile useful for later recompilation with profile
- feedback based optimization. You must use `-fprofile-generate'
- both when compiling and when linking your program.
-
- The following options are enabled: `-fprofile-arcs',
- `-fprofile-values', `-fvpt'.
-
- If PATH is specified, GCC will look at the PATH to find the
- profile feedback data files. See `-fprofile-dir'.
-
-`-fprofile-generate-sampling'
- Enable sampling for instrumented binaries. Instead of recording
- every event, record only every N-th event, where N (the sampling
- rate) can be set either at compile time using `--param
- profile-generate-sampling-rate=VALUE', or at execution start time
- through environment variable `GCOV_SAMPLING_RATE'.
-
- At this time sampling applies only to branch counters. A sampling
- rate of 100 decreases instrumentated binary slowdown from up to
- 20x for heavily threaded applications down to around 2x.
- `-fprofile-correction' is always needed with sampling.
-
-`-fprofile-use'
-`-fprofile-use=PATH'
- Enable profile feedback directed optimizations, and optimizations
- generally profitable only with profile feedback available.
-
- The following options are enabled: `-fbranch-probabilities',
- `-fvpt', `-funroll-loops', `-fpeel-loops'.
-
- By default, GCC emits an error message if the feedback profiles do
- not match the source code. This error can be turned into a
- warning by using `-Wcoverage-mismatch'. Note this may result in
- poorly optimized code.
-
- If PATH is specified, GCC will look at the PATH to find the
- profile feedback data files. See `-fprofile-dir'.
-
-`-fpmu-profile-generate=PMUOPTION'
- Enable performance monitoring unit (PMU) profiling. This collects
- hardware counter data corresponding to PMUOPTION. Currently only
- LOAD-LATENCY and BRANCH-MISPREDICT are supported using pfmon tool.
- You must use `-fpmu-profile-generate' both when compiling and when
- linking your program. This PMU profile data may later be used by
- the compiler during optimizations as well can be displayed using
- coverage tool gcov. The params variable "pmu_profile_n_addresses"
- can be used to restrict PMU data collection to only this many
- addresses.
-
-`-fpmu-profile-use=PMUOPTION'
- Enable performance monitoring unit (PMU) profiling based
- optimizations. Currently only LOAD-LATENCY and BRANCH-MISPREDICT
- are supported.
-
-`-fripa'
- Perform dynamic inter-procedural analysis. This is used in
- conjunction with the `-fprofile-generate' and `-fprofile-use'
- options. During the `-fprofile-generate' phase, this flag turns
- on some additional instrumentation code that enables dynamic
- call-graph analysis. During the `-fprofile-use' phase, this flag
- enables cross-module optimizations such as inlining.
-
-`-fripa-disallow-asm-modules'
- During profile-gen, if this flag is enabled, and the module has
- asm statements, arrange so that a bit recording this information
- will be set in the profile feedback data file. During
- profile-use, if this flag is enabled, and the same bit in auxiliary
- module's profile feedback data is set, don't import this auxiliary
- module. If this is the primary module, don't export it.
-
-`-fripa-disallow-opt-mismatch'
- Don't import an auxiliary module, if the GCC command line options
- used for this auxiliary module during the profile-generate stage
- were different from those used for the primary module. Note that
- any mismatches in warning-related options are ignored for this
- comparison.
-
-`-fripa-no-promote-always-inline-func'
- Do not promote static functions with always inline attribute in
- LIPO compilation.
-
-`-fripa-verbose'
- Enable printing of verbose information about dynamic
- inter-procedural optimizations. This is used in conjunction with
- the `-fripa'.
-
-`-fripa-peel-size-limit'
- Limit loop peeling of non-const non-FP loops in a LIPO compilation
- under estimates of a large code footprint. Enabled by default
- under `-fripa'. Code size estimation and thresholds are controlled
- by the `codesize-hotness-threshold' and
- `unrollpeel-codesize-threshold' parameters.
-
-`-fripa-unroll-size-limit'
- Limit loop unrolling of non-const non-FP loops in a LIPO
- compilation under estimates of a large code footprint. Enabled by
- default under `-fripa'. Code size estimation and thresholds are
- controlled by the `codesize-hotness-threshold' and
- `unrollpeel-codesize-threshold' parameters.
-
-`-fcallgraph-profiles-sections'
- Emit call graph edge profile counts in .note.callgraph.text
- sections. This is used in conjunction with `-fprofile-use'. A new
- .note.callgraph.text section is created for each function. This
- section lists every callee and the number of times it is called.
- The params variable "note-cgraph-section-edge-threshold" can be
- used to only list edges above a certain threshold.
-
-`-frecord-gcc-switches-in-elf'
- Record the command line options in the .gnu.switches.text elf
- section for sample based LIPO to do module grouping.
-
- The following options control compiler behavior regarding floating
-point arithmetic. These options trade off between speed and
-correctness. All must be specifically enabled.
-
-`-ffloat-store'
- Do not store floating point variables in registers, and inhibit
- other options that might change whether a floating point value is
- taken from a register or memory.
-
- This option prevents undesirable excess precision on machines such
- as the 68000 where the floating registers (of the 68881) keep more
- precision than a `double' is supposed to have. Similarly for the
- x86 architecture. For most programs, the excess precision does
- only good, but a few programs rely on the precise definition of
- IEEE floating point. Use `-ffloat-store' for such programs, after
- modifying them to store all pertinent intermediate computations
- into variables.
-
-`-fexcess-precision=STYLE'
- This option allows further control over excess precision on
- machines where floating-point registers have more precision than
- the IEEE `float' and `double' types and the processor does not
- support operations rounding to those types. By default,
- `-fexcess-precision=fast' is in effect; this means that operations
- are carried out in the precision of the registers and that it is
- unpredictable when rounding to the types specified in the source
- code takes place. When compiling C, if
- `-fexcess-precision=standard' is specified then excess precision
- will follow the rules specified in ISO C99; in particular, both
- casts and assignments cause values to be rounded to their semantic
- types (whereas `-ffloat-store' only affects assignments). This
- option is enabled by default for C if a strict conformance option
- such as `-std=c99' is used.
-
- `-fexcess-precision=standard' is not implemented for languages
- other than C, and has no effect if `-funsafe-math-optimizations'
- or `-ffast-math' is specified. On the x86, it also has no effect
- if `-mfpmath=sse' or `-mfpmath=sse+387' is specified; in the
- former case, IEEE semantics apply without excess precision, and in
- the latter, rounding is unpredictable.
-
-`-ffast-math'
- Sets `-fno-math-errno', `-funsafe-math-optimizations',
- `-ffinite-math-only', `-fno-rounding-math', `-fno-signaling-nans'
- and `-fcx-limited-range'.
-
- This option causes the preprocessor macro `__FAST_MATH__' to be
- defined.
-
- This option is not turned on by any `-O' option besides `-Ofast'
- since it can result in incorrect output for programs which depend
- on an exact implementation of IEEE or ISO rules/specifications for
- math functions. It may, however, yield faster code for programs
- that do not require the guarantees of these specifications.
-
-`-fno-math-errno'
- Do not set ERRNO after calling math functions that are executed
- with a single instruction, e.g., sqrt. A program that relies on
- IEEE exceptions for math error handling may want to use this flag
- for speed while maintaining IEEE arithmetic compatibility.
-
- This option is not turned on by any `-O' option since it can
- result in incorrect output for programs which depend on an exact
- implementation of IEEE or ISO rules/specifications for math
- functions. It may, however, yield faster code for programs that do
- not require the guarantees of these specifications.
-
- The default is `-fmath-errno'.
-
- On Darwin systems, the math library never sets `errno'. There is
- therefore no reason for the compiler to consider the possibility
- that it might, and `-fno-math-errno' is the default.
-
-`-funsafe-math-optimizations'
- Allow optimizations for floating-point arithmetic that (a) assume
- that arguments and results are valid and (b) may violate IEEE or
- ANSI standards. When used at link-time, it may include libraries
- or startup files that change the default FPU control word or other
- similar optimizations.
-
- This option is not turned on by any `-O' option since it can
- result in incorrect output for programs which depend on an exact
- implementation of IEEE or ISO rules/specifications for math
- functions. It may, however, yield faster code for programs that do
- not require the guarantees of these specifications. Enables
- `-fno-signed-zeros', `-fno-trapping-math', `-fassociative-math'
- and `-freciprocal-math'.
-
- The default is `-fno-unsafe-math-optimizations'.
-
-`-fassociative-math'
- Allow re-association of operands in series of floating-point
- operations. This violates the ISO C and C++ language standard by
- possibly changing computation result. NOTE: re-ordering may
- change the sign of zero as well as ignore NaNs and inhibit or
- create underflow or overflow (and thus cannot be used on a code
- which relies on rounding behavior like `(x + 2**52) - 2**52)'.
- May also reorder floating-point comparisons and thus may not be
- used when ordered comparisons are required. This option requires
- that both `-fno-signed-zeros' and `-fno-trapping-math' be in
- effect. Moreover, it doesn't make much sense with
- `-frounding-math'. For Fortran the option is automatically enabled
- when both `-fno-signed-zeros' and `-fno-trapping-math' are in
- effect.
-
- The default is `-fno-associative-math'.
-
-`-freciprocal-math'
- Allow the reciprocal of a value to be used instead of dividing by
- the value if this enables optimizations. For example `x / y' can
- be replaced with `x * (1/y)' which is useful if `(1/y)' is subject
- to common subexpression elimination. Note that this loses
- precision and increases the number of flops operating on the value.
-
- The default is `-fno-reciprocal-math'.
-
-`-ffinite-math-only'
- Allow optimizations for floating-point arithmetic that assume that
- arguments and results are not NaNs or +-Infs.
-
- This option is not turned on by any `-O' option since it can
- result in incorrect output for programs which depend on an exact
- implementation of IEEE or ISO rules/specifications for math
- functions. It may, however, yield faster code for programs that do
- not require the guarantees of these specifications.
-
- The default is `-fno-finite-math-only'.
-
-`-fno-signed-zeros'
- Allow optimizations for floating point arithmetic that ignore the
- signedness of zero. IEEE arithmetic specifies the behavior of
- distinct +0.0 and -0.0 values, which then prohibits simplification
- of expressions such as x+0.0 or 0.0*x (even with
- `-ffinite-math-only'). This option implies that the sign of a
- zero result isn't significant.
-
- The default is `-fsigned-zeros'.
-
-`-fno-trapping-math'
- Compile code assuming that floating-point operations cannot
- generate user-visible traps. These traps include division by
- zero, overflow, underflow, inexact result and invalid operation.
- This option requires that `-fno-signaling-nans' be in effect.
- Setting this option may allow faster code if one relies on
- "non-stop" IEEE arithmetic, for example.
-
- This option should never be turned on by any `-O' option since it
- can result in incorrect output for programs which depend on an
- exact implementation of IEEE or ISO rules/specifications for math
- functions.
-
- The default is `-ftrapping-math'.
-
-`-frounding-math'
- Disable transformations and optimizations that assume default
- floating point rounding behavior. This is round-to-zero for all
- floating point to integer conversions, and round-to-nearest for
- all other arithmetic truncations. This option should be specified
- for programs that change the FP rounding mode dynamically, or that
- may be executed with a non-default rounding mode. This option
- disables constant folding of floating point expressions at
- compile-time (which may be affected by rounding mode) and
- arithmetic transformations that are unsafe in the presence of
- sign-dependent rounding modes.
-
- The default is `-fno-rounding-math'.
-
- This option is experimental and does not currently guarantee to
- disable all GCC optimizations that are affected by rounding mode.
- Future versions of GCC may provide finer control of this setting
- using C99's `FENV_ACCESS' pragma. This command line option will
- be used to specify the default state for `FENV_ACCESS'.
-
-`-fsignaling-nans'
- Compile code assuming that IEEE signaling NaNs may generate
- user-visible traps during floating-point operations. Setting this
- option disables optimizations that may change the number of
- exceptions visible with signaling NaNs. This option implies
- `-ftrapping-math'.
-
- This option causes the preprocessor macro `__SUPPORT_SNAN__' to be
- defined.
-
- The default is `-fno-signaling-nans'.
-
- This option is experimental and does not currently guarantee to
- disable all GCC optimizations that affect signaling NaN behavior.
-
-`-fsingle-precision-constant'
- Treat floating point constant as single precision constant instead
- of implicitly converting it to double precision constant.
-
-`-fcx-limited-range'
- When enabled, this option states that a range reduction step is not
- needed when performing complex division. Also, there is no
- checking whether the result of a complex multiplication or
- division is `NaN + I*NaN', with an attempt to rescue the situation
- in that case. The default is `-fno-cx-limited-range', but is
- enabled by `-ffast-math'.
-
- This option controls the default setting of the ISO C99
- `CX_LIMITED_RANGE' pragma. Nevertheless, the option applies to
- all languages.
-
-`-fcx-fortran-rules'
- Complex multiplication and division follow Fortran rules. Range
- reduction is done as part of complex division, but there is no
- checking whether the result of a complex multiplication or
- division is `NaN + I*NaN', with an attempt to rescue the situation
- in that case.
-
- The default is `-fno-cx-fortran-rules'.
-
-`min-mcf-cancel-iters'
- The minimum number of iterations of negative cycle cancellation
- during MCF profile correction before early termination. This
- parameter is only useful when using `-fprofile-correction'.
-
-
- The following options control optimizations that may improve
-performance, but are not enabled by any `-O' options. This section
-includes experimental options that may produce broken code.
-
-`-fbranch-probabilities'
- After running a program compiled with `-fprofile-arcs' (*note
- Options for Debugging Your Program or `gcc': Debugging Options.),
- you can compile it a second time using `-fbranch-probabilities',
- to improve optimizations based on the number of times each branch
- was taken. When the program compiled with `-fprofile-arcs' exits
- it saves arc execution counts to a file called `SOURCENAME.gcda'
- for each source file. The information in this data file is very
- dependent on the structure of the generated code, so you must use
- the same source code and the same optimization options for both
- compilations.
-
- With `-fbranch-probabilities', GCC puts a `REG_BR_PROB' note on
- each `JUMP_INSN' and `CALL_INSN'. These can be used to improve
- optimization. Currently, they are only used in one place: in
- `reorg.c', instead of guessing which path a branch is most likely
- to take, the `REG_BR_PROB' values are used to exactly determine
- which path is taken more often.
-
-`-fclone-hot-version-paths'
- When multi-version calls are made using `__builtin_dispatch', this
- flag enables cloning and hoisting of hot multiversioned paths.
-
-`-fprofile-values'
- If combined with `-fprofile-arcs', it adds code so that some data
- about values of expressions in the program is gathered.
-
- With `-fbranch-probabilities', it reads back the data gathered
- from profiling values of expressions for usage in optimizations.
-
- Enabled with `-fprofile-generate' and `-fprofile-use'.
-
-`-fvpt'
- If combined with `-fprofile-arcs', it instructs the compiler to add
- a code to gather information about values of expressions.
-
- With `-fbranch-probabilities', it reads back the data gathered and
- actually performs the optimizations based on them. Currently the
- optimizations include specialization of division operation using
- the knowledge about the value of the denominator.
-
-`-frename-registers'
- Attempt to avoid false dependencies in scheduled code by making use
- of registers left over after register allocation. This
- optimization will most benefit processors with lots of registers.
- Depending on the debug information format adopted by the target,
- however, it can make debugging impossible, since variables will no
- longer stay in a "home register".
-
- Enabled by default with `-funroll-loops' and `-fpeel-loops'.
-
-`-ftracer'
- Perform tail duplication to enlarge superblock size. This
- transformation simplifies the control flow of the function
- allowing other optimizations to do better job.
-
- Enabled with `-fprofile-use'.
-
-`-funroll-loops'
- Unroll loops whose number of iterations can be determined at
- compile time or upon entry to the loop. `-funroll-loops' implies
- `-frerun-cse-after-loop', `-fweb' and `-frename-registers'. It
- also turns on complete loop peeling (i.e. complete removal of
- loops with small constant number of iterations). This option
- makes code larger, and may or may not make it run faster.
-
- Enabled with `-fprofile-use'.
-
-`-funroll-all-loops'
- Unroll all loops, even if their number of iterations is uncertain
- when the loop is entered. This usually makes programs run more
- slowly. `-funroll-all-loops' implies the same options as
- `-funroll-loops'.
-
-`-fpeel-loops'
- Peels the loops for that there is enough information that they do
- not roll much (from profile feedback). It also turns on complete
- loop peeling (i.e. complete removal of loops with small constant
- number of iterations).
-
- Enabled with `-fprofile-use'.
-
-`-fmove-loop-invariants'
- Enables the loop invariant motion pass in the RTL loop optimizer.
- Enabled at level `-O1'
-
-`-funswitch-loops'
- Move branches with loop invariant conditions out of the loop, with
- duplicates of the loop on both branches (modified according to
- result of the condition).
-
-`-ffunction-sections'
-`-fdata-sections'
- Place each function or data item into its own section in the output
- file if the target supports arbitrary sections. The name of the
- function or the name of the data item determines the section's name
- in the output file.
-
- Use these options on systems where the linker can perform
- optimizations to improve locality of reference in the instruction
- space. Most systems using the ELF object format and SPARC
- processors running Solaris 2 have linkers with such optimizations.
- AIX may have these optimizations in the future.
-
- Only use these options when there are significant benefits from
- doing so. When you specify these options, the assembler and
- linker will create larger object and executable files and will
- also be slower. You will not be able to use `gprof' on all
- systems if you specify this option and you may have problems with
- debugging if you specify both this option and `-g'.
-
-`-fbranch-target-load-optimize'
- Perform branch target register load optimization before prologue /
- epilogue threading. The use of target registers can typically be
- exposed only during reload, thus hoisting loads out of loops and
- doing inter-block scheduling needs a separate optimization pass.
-
-`-fbranch-target-load-optimize2'
- Perform branch target register load optimization after prologue /
- epilogue threading.
-
-`-fbtr-bb-exclusive'
- When performing branch target register load optimization, don't
- reuse branch target registers in within any basic block.
-
-`-fstack-protector'
- Emit extra code to check for buffer overflows, such as stack
- smashing attacks. This is done by adding a guard variable to
- functions with vulnerable objects. This includes functions that
- call alloca, and functions with buffers larger than 8 bytes. The
- guards are initialized when a function is entered and then checked
- when the function exits. If a guard check fails, an error message
- is printed and the program exits.
-
-`-fstack-protector-all'
- Like `-fstack-protector' except that all functions are protected.
-
-`-fstack-protector-strong'
- Like `-fstack-protector' but includes additional functions to be
- protected - those that have local array definitions, or have
- references to local frame addresses.
-
-`-fsection-anchors'
- Try to reduce the number of symbolic address calculations by using
- shared "anchor" symbols to address nearby objects. This
- transformation can help to reduce the number of GOT entries and
- GOT accesses on some targets.
-
- For example, the implementation of the following function `foo':
-
- static int a, b, c;
- int foo (void) { return a + b + c; }
-
- would usually calculate the addresses of all three variables, but
- if you compile it with `-fsection-anchors', it will access the
- variables from a common anchor point instead. The effect is
- similar to the following pseudocode (which isn't valid C):
-
- int foo (void)
- {
- register int *xr = &x;
- return xr[&a - &x] + xr[&b - &x] + xr[&c - &x];
- }
-
- Not all targets support this option.
-
-`--param NAME=VALUE'
- In some places, GCC uses various constants to control the amount of
- optimization that is done. For example, GCC will not inline
- functions that contain more that a certain number of instructions.
- You can control some of these constants on the command-line using
- the `--param' option.
-
- The names of specific parameters, and the meaning of the values,
- are tied to the internals of the compiler, and are subject to
- change without notice in future releases.
-
- In each case, the VALUE is an integer. The allowable choices for
- NAME are given in the following table:
-
- `struct-reorg-cold-struct-ratio'
- The threshold ratio (as a percentage) between a structure
- frequency and the frequency of the hottest structure in the
- program. This parameter is used by struct-reorg optimization
- enabled by `-fipa-struct-reorg'. We say that if the ratio of
- a structure frequency, calculated by profiling, to the
- hottest structure frequency in the program is less than this
- parameter, then structure reorganization is not applied to
- this structure. The default is 10.
-
- `predictable-branch-outcome'
- When branch is predicted to be taken with probability lower
- than this threshold (in percent), then it is considered well
- predictable. The default is 10.
-
- `max-crossjump-edges'
- The maximum number of incoming edges to consider for
- crossjumping. The algorithm used by `-fcrossjumping' is
- O(N^2) in the number of edges incoming to each block.
- Increasing values mean more aggressive optimization, making
- the compile time increase with probably small improvement in
- executable size.
-
- `min-crossjump-insns'
- The minimum number of instructions which must be matched at
- the end of two blocks before crossjumping will be performed
- on them. This value is ignored in the case where all
- instructions in the block being crossjumped from are matched.
- The default value is 5.
-
- `max-grow-copy-bb-insns'
- The maximum code size expansion factor when copying basic
- blocks instead of jumping. The expansion is relative to a
- jump instruction. The default value is 8.
-
- `max-goto-duplication-insns'
- The maximum number of instructions to duplicate to a block
- that jumps to a computed goto. To avoid O(N^2) behavior in a
- number of passes, GCC factors computed gotos early in the
- compilation process, and unfactors them as late as possible.
- Only computed jumps at the end of a basic blocks with no more
- than max-goto-duplication-insns are unfactored. The default
- value is 8.
-
- `max-delay-slot-insn-search'
- The maximum number of instructions to consider when looking
- for an instruction to fill a delay slot. If more than this
- arbitrary number of instructions is searched, the time
- savings from filling the delay slot will be minimal so stop
- searching. Increasing values mean more aggressive
- optimization, making the compile time increase with probably
- small improvement in executable run time.
-
- `max-delay-slot-live-search'
- When trying to fill delay slots, the maximum number of
- instructions to consider when searching for a block with
- valid live register information. Increasing this arbitrarily
- chosen value means more aggressive optimization, increasing
- the compile time. This parameter should be removed when the
- delay slot code is rewritten to maintain the control-flow
- graph.
-
- `max-gcse-memory'
- The approximate maximum amount of memory that will be
- allocated in order to perform the global common subexpression
- elimination optimization. If more memory than specified is
- required, the optimization will not be done.
-
- `max-gcse-insertion-ratio'
- If the ratio of expression insertions to deletions is larger
- than this value for any expression, then RTL PRE will insert
- or remove the expression and thus leave partially redundant
- computations in the instruction stream. The default value is
- 20.
-
- `max-pending-list-length'
- The maximum number of pending dependencies scheduling will
- allow before flushing the current state and starting over.
- Large functions with few branches or calls can create
- excessively large lists which needlessly consume memory and
- resources.
-
- `max-inline-insns-single'
- Several parameters control the tree inliner used in gcc.
- This number sets the maximum number of instructions (counted
- in GCC's internal representation) in a single function that
- the tree inliner will consider for inlining. This only
- affects functions declared inline and methods implemented in
- a class declaration (C++). The default value is 400.
-
- `max-inline-insns-auto'
- When you use `-finline-functions' (included in `-O3'), a lot
- of functions that would otherwise not be considered for
- inlining by the compiler will be investigated. To those
- functions, a different (more restrictive) limit compared to
- functions declared inline can be applied. The default value
- is 40.
-
- `mversn-clone-depth'
- When using `-fclone-hot-version-paths', hot function paths
- are multi- versioned via cloning. This parameter specifies
- the maximum length of the call graph path that can be cloned.
- The default value is 2.
-
- `num-mversn-clones'
- When using `-fclone-hot-version-paths', hot function paths
- are multi- versioned via cloning. This parameter specifies
- the maximum number of functions that can be cloned. The
- default value is 10.
-
- `large-function-insns'
- The limit specifying really large functions. For functions
- larger than this limit after inlining, inlining is
- constrained by `--param large-function-growth'. This
- parameter is useful primarily to avoid extreme compilation
- time caused by non-linear algorithms used by the backend.
- The default value is 2700.
-
- `large-function-growth'
- Specifies maximal growth of large function caused by inlining
- in percents. The default value is 100 which limits large
- function growth to 2.0 times the original size.
-
- `large-unit-insns'
- The limit specifying large translation unit. Growth caused
- by inlining of units larger than this limit is limited by
- `--param inline-unit-growth'. For small units this might be
- too tight (consider unit consisting of function A that is
- inline and B that just calls A three time. If B is small
- relative to A, the growth of unit is 300\% and yet such
- inlining is very sane. For very large units consisting of
- small inlineable functions however the overall unit growth
- limit is needed to avoid exponential explosion of code size.
- Thus for smaller units, the size is increased to `--param
- large-unit-insns' before applying `--param
- inline-unit-growth'. The default is 10000
-
- `inline-unit-growth'
- Specifies maximal overall growth of the compilation unit
- caused by inlining. The default value is 30 which limits
- unit growth to 1.3 times the original size.
-
- `ipcp-unit-growth'
- Specifies maximal overall growth of the compilation unit
- caused by interprocedural constant propagation. The default
- value is 10 which limits unit growth to 1.1 times the
- original size.
-
- `large-stack-frame'
- The limit specifying large stack frames. While inlining the
- algorithm is trying to not grow past this limit too much.
- Default value is 256 bytes.
-
- `large-stack-frame-growth'
- Specifies maximal growth of large stack frames caused by
- inlining in percents. The default value is 1000 which limits
- large stack frame growth to 11 times the original size.
-
- `max-inline-insns-recursive'
- `max-inline-insns-recursive-auto'
- Specifies maximum number of instructions out-of-line copy of
- self recursive inline function can grow into by performing
- recursive inlining.
-
- For functions declared inline `--param
- max-inline-insns-recursive' is taken into account. For
- function not declared inline, recursive inlining happens only
- when `-finline-functions' (included in `-O3') is enabled and
- `--param max-inline-insns-recursive-auto' is used. The
- default value is 450.
-
- `max-inline-recursive-depth'
- `max-inline-recursive-depth-auto'
- Specifies maximum recursion depth used by the recursive
- inlining.
-
- For functions declared inline `--param
- max-inline-recursive-depth' is taken into account. For
- function not declared inline, recursive inlining happens only
- when `-finline-functions' (included in `-O3') is enabled and
- `--param max-inline-recursive-depth-auto' is used. The
- default value is 8.
-
- `min-inline-recursive-probability'
- Recursive inlining is profitable only for function having
- deep recursion in average and can hurt for function having
- little recursion depth by increasing the prologue size or
- complexity of function body to other optimizers.
-
- When profile feedback is available (see `-fprofile-generate')
- the actual recursion depth can be guessed from probability
- that function will recurse via given call expression. This
- parameter limits inlining only to call expression whose
- probability exceeds given threshold (in percents). The
- default value is 10.
-
- `early-inlining-insns'
- Specify growth that early inliner can make. In effect it
- increases amount of inlining for code having large
- abstraction penalty. The default value is 10.
-
- `max-early-inliner-iterations'
- `max-early-inliner-iterations'
- Limit of iterations of early inliner. This basically bounds
- number of nested indirect calls early inliner can resolve.
- Deeper chains are still handled by late inlining.
-
- `comdat-sharing-probability'
- `comdat-sharing-probability'
- Probability (in percent) that C++ inline function with comdat
- visibility will be shared across multiple compilation units.
- The default value is 20.
-
- `min-vect-loop-bound'
- The minimum number of iterations under which a loop will not
- get vectorized when `-ftree-vectorize' is used. The number
- of iterations after vectorization needs to be greater than
- the value specified by this option to allow vectorization.
- The default value is 0.
-
- `gcse-cost-distance-ratio'
- Scaling factor in calculation of maximum distance an
- expression can be moved by GCSE optimizations. This is
- currently supported only in the code hoisting pass. The
- bigger the ratio, the more aggressive code hoisting will be
- with simple expressions, i.e., the expressions which have cost
- less than `gcse-unrestricted-cost'. Specifying 0 will disable
- hoisting of simple expressions. The default value is 10.
-
- `gcse-unrestricted-cost'
- Cost, roughly measured as the cost of a single typical machine
- instruction, at which GCSE optimizations will not constrain
- the distance an expression can travel. This is currently
- supported only in the code hoisting pass. The lesser the
- cost, the more aggressive code hoisting will be. Specifying
- 0 will allow all expressions to travel unrestricted distances.
- The default value is 3.
-
- `max-hoist-depth'
- The depth of search in the dominator tree for expressions to
- hoist. This is used to avoid quadratic behavior in hoisting
- algorithm. The value of 0 will avoid limiting the search,
- but may slow down compilation of huge functions. The default
- value is 30.
-
- `max-unrolled-insns'
- The maximum number of instructions that a loop should have if
- that loop is unrolled, and if the loop is unrolled, it
- determines how many times the loop code is unrolled.
-
- `max-average-unrolled-insns'
- The maximum number of instructions biased by probabilities of
- their execution that a loop should have if that loop is
- unrolled, and if the loop is unrolled, it determines how many
- times the loop code is unrolled.
-
- `max-unroll-times'
- The maximum number of unrollings of a single loop.
-
- `max-peeled-insns'
- The maximum number of instructions that a loop should have if
- that loop is peeled, and if the loop is peeled, it determines
- how many times the loop code is peeled.
-
- `max-peel-times'
- The maximum number of peelings of a single loop.
-
- `max-completely-peeled-insns'
- The maximum number of insns of a completely peeled loop.
-
- `max-completely-peeled-insns-feedback'
- The maximum number of insns of a completely peeled loop when
- profile feedback is available and the loop is hot. Because of
- the real profiles, this value may set to be larger for hot
- loops. Its default value is 600.
-
- `max-once-peeled-insns'
- The maximum number of insns of a peeled loop that rolls only
- once.
-
- `max-once-peeled-insns-feedback'
- The maximum number of insns of a peeled loop when profile
- feedback is available and the loop is hot. Because of the
- real profiles, this value may set to be larger for hot loops.
- The default value is 600.
-
- `max-completely-peel-times'
- The maximum number of iterations of a loop to be suitable for
- complete peeling.
-
- `max-completely-peel-times-feedback'
- The maximum number of iterations of a loop to be suitable for
- complete peeling when profile feedback is available and the
- loop is hot. Because of the real profiles, this value may set
- to be larger for hot loops. Its default value is 16.
-
- `max-completely-peel-loop-nest-depth'
- The maximum depth of a loop nest suitable for complete
- peeling.
-
- `codesize-hotness-threshold'
- The minimum profile count of basic blocks to look at when
- estimating the code size footprint of the call graph in a
- LIPO compile.
-
- `unrollpeel-codesize-threshold'
- Maximum LIPO code size footprint estimate for loop unrolling
- and peeling.
-
- `max-unswitch-insns'
- The maximum number of insns of an unswitched loop.
-
- `max-unswitch-level'
- The maximum number of branches unswitched in a single loop.
-
- `lim-expensive'
- The minimum cost of an expensive expression in the loop
- invariant motion.
-
- `iv-consider-all-candidates-bound'
- Bound on number of candidates for induction variables below
- that all candidates are considered for each use in induction
- variable optimizations. Only the most relevant candidates
- are considered if there are more candidates, to avoid
- quadratic time complexity.
-
- `iv-max-considered-uses'
- The induction variable optimizations give up on loops that
- contain more induction variable uses.
-
- `iv-always-prune-cand-set-bound'
- If number of candidates in the set is smaller than this value,
- we always try to remove unnecessary ivs from the set during
- its optimization when a new iv is added to the set.
-
- `scev-max-expr-size'
- Bound on size of expressions used in the scalar evolutions
- analyzer. Large expressions slow the analyzer.
-
- `scev-max-expr-complexity'
- Bound on the complexity of the expressions in the scalar
- evolutions analyzer. Complex expressions slow the analyzer.
-
- `omega-max-vars'
- The maximum number of variables in an Omega constraint system.
- The default value is 128.
-
- `omega-max-geqs'
- The maximum number of inequalities in an Omega constraint
- system. The default value is 256.
-
- `omega-max-eqs'
- The maximum number of equalities in an Omega constraint
- system. The default value is 128.
-
- `omega-max-wild-cards'
- The maximum number of wildcard variables that the Omega
- solver will be able to insert. The default value is 18.
-
- `omega-hash-table-size'
- The size of the hash table in the Omega solver. The default
- value is 550.
-
- `omega-max-keys'
- The maximal number of keys used by the Omega solver. The
- default value is 500.
-
- `omega-eliminate-redundant-constraints'
- When set to 1, use expensive methods to eliminate all
- redundant constraints. The default value is 0.
-
- `vect-max-version-for-alignment-checks'
- The maximum number of runtime checks that can be performed
- when doing loop versioning for alignment in the vectorizer.
- See option ftree-vect-loop-version for more information.
-
- `vect-max-version-for-alias-checks'
- The maximum number of runtime checks that can be performed
- when doing loop versioning for alias in the vectorizer. See
- option ftree-vect-loop-version for more information.
-
- `max-iterations-to-track'
- The maximum number of iterations of a loop the brute force
- algorithm for analysis of # of iterations of the loop tries
- to evaluate.
-
- `hot-bb-count-fraction'
- Select fraction of the maximal count of repetitions of basic
- block in program given basic block needs to have to be
- considered hot.
-
- `hot-bb-frequency-fraction'
- Select fraction of the entry block frequency of executions of
- basic block in function given basic block needs to have to be
- considered hot
-
- `max-predicted-iterations'
- The maximum number of loop iterations we predict statically.
- This is useful in cases where function contain single loop
- with known bound and other loop with unknown. We predict the
- known number of iterations correctly, while the unknown
- number of iterations average to roughly 10. This means that
- the loop without bounds would appear artificially cold
- relative to the other one.
-
- `align-threshold'
- Select fraction of the maximal frequency of executions of
- basic block in function given basic block will get aligned.
-
- `align-loop-iterations'
- A loop expected to iterate at lest the selected number of
- iterations will get aligned.
-
- `tracer-dynamic-coverage'
- `tracer-dynamic-coverage-feedback'
- This value is used to limit superblock formation once the
- given percentage of executed instructions is covered. This
- limits unnecessary code size expansion.
-
- The `tracer-dynamic-coverage-feedback' is used only when
- profile feedback is available. The real profiles (as opposed
- to statically estimated ones) are much less balanced allowing
- the threshold to be larger value.
-
- `tracer-max-code-growth'
- Stop tail duplication once code growth has reached given
- percentage. This is rather hokey argument, as most of the
- duplicates will be eliminated later in cross jumping, so it
- may be set to much higher values than is the desired code
- growth.
-
- `tracer-min-branch-ratio'
- Stop reverse growth when the reverse probability of best edge
- is less than this threshold (in percent).
-
- `tracer-min-branch-ratio'
- `tracer-min-branch-ratio-feedback'
- Stop forward growth if the best edge do have probability
- lower than this threshold.
-
- Similarly to `tracer-dynamic-coverage' two values are
- present, one for compilation for profile feedback and one for
- compilation without. The value for compilation with profile
- feedback needs to be more conservative (higher) in order to
- make tracer effective.
-
- `max-cse-path-length'
- Maximum number of basic blocks on path that cse considers.
- The default is 10.
-
- `max-cse-insns'
- The maximum instructions CSE process before flushing. The
- default is 1000.
-
- `ggc-min-expand'
- GCC uses a garbage collector to manage its own memory
- allocation. This parameter specifies the minimum percentage
- by which the garbage collector's heap should be allowed to
- expand between collections. Tuning this may improve
- compilation speed; it has no effect on code generation.
-
- The default is 30% + 70% * (RAM/1GB) with an upper bound of
- 100% when RAM >= 1GB. If `getrlimit' is available, the
- notion of "RAM" is the smallest of actual RAM and
- `RLIMIT_DATA' or `RLIMIT_AS'. If GCC is not able to
- calculate RAM on a particular platform, the lower bound of
- 30% is used. Setting this parameter and `ggc-min-heapsize'
- to zero causes a full collection to occur at every
- opportunity. This is extremely slow, but can be useful for
- debugging.
-
- `ggc-min-heapsize'
- Minimum size of the garbage collector's heap before it begins
- bothering to collect garbage. The first collection occurs
- after the heap expands by `ggc-min-expand'% beyond
- `ggc-min-heapsize'. Again, tuning this may improve
- compilation speed, and has no effect on code generation.
-
- The default is the smaller of RAM/8, RLIMIT_RSS, or a limit
- which tries to ensure that RLIMIT_DATA or RLIMIT_AS are not
- exceeded, but with a lower bound of 4096 (four megabytes) and
- an upper bound of 131072 (128 megabytes). If GCC is not able
- to calculate RAM on a particular platform, the lower bound is
- used. Setting this parameter very large effectively disables
- garbage collection. Setting this parameter and
- `ggc-min-expand' to zero causes a full collection to occur at
- every opportunity.
-
- `max-reload-search-insns'
- The maximum number of instruction reload should look backward
- for equivalent register. Increasing values mean more
- aggressive optimization, making the compile time increase
- with probably slightly better performance. The default value
- is 100.
-
- `max-cselib-memory-locations'
- The maximum number of memory locations cselib should take
- into account. Increasing values mean more aggressive
- optimization, making the compile time increase with probably
- slightly better performance. The default value is 500.
-
- `reorder-blocks-duplicate'
- `reorder-blocks-duplicate-feedback'
- Used by basic block reordering pass to decide whether to use
- unconditional branch or duplicate the code on its
- destination. Code is duplicated when its estimated size is
- smaller than this value multiplied by the estimated size of
- unconditional jump in the hot spots of the program.
-
- The `reorder-block-duplicate-feedback' is used only when
- profile feedback is available and may be set to higher values
- than `reorder-block-duplicate' since information about the
- hot spots is more accurate.
-
- `max-sched-ready-insns'
- The maximum number of instructions ready to be issued the
- scheduler should consider at any given time during the first
- scheduling pass. Increasing values mean more thorough
- searches, making the compilation time increase with probably
- little benefit. The default value is 100.
-
- `max-sched-region-blocks'
- The maximum number of blocks in a region to be considered for
- interblock scheduling. The default value is 10.
-
- `max-pipeline-region-blocks'
- The maximum number of blocks in a region to be considered for
- pipelining in the selective scheduler. The default value is
- 15.
-
- `max-sched-region-insns'
- The maximum number of insns in a region to be considered for
- interblock scheduling. The default value is 100.
-
- `max-pipeline-region-insns'
- The maximum number of insns in a region to be considered for
- pipelining in the selective scheduler. The default value is
- 200.
-
- `min-spec-prob'
- The minimum probability (in percents) of reaching a source
- block for interblock speculative scheduling. The default
- value is 40.
-
- `max-sched-extend-regions-iters'
- The maximum number of iterations through CFG to extend
- regions. 0 - disable region extension, N - do at most N
- iterations. The default value is 0.
-
- `max-sched-insn-conflict-delay'
- The maximum conflict delay for an insn to be considered for
- speculative motion. The default value is 3.
-
- `sched-spec-prob-cutoff'
- The minimal probability of speculation success (in percents),
- so that speculative insn will be scheduled. The default
- value is 40.
-
- `sched-mem-true-dep-cost'
- Minimal distance (in CPU cycles) between store and load
- targeting same memory locations. The default value is 1.
-
- `selsched-max-lookahead'
- The maximum size of the lookahead window of selective
- scheduling. It is a depth of search for available
- instructions. The default value is 50.
-
- `selsched-max-sched-times'
- The maximum number of times that an instruction will be
- scheduled during selective scheduling. This is the limit on
- the number of iterations through which the instruction may be
- pipelined. The default value is 2.
-
- `selsched-max-insns-to-rename'
- The maximum number of best instructions in the ready list
- that are considered for renaming in the selective scheduler.
- The default value is 2.
-
- `max-last-value-rtl'
- The maximum size measured as number of RTLs that can be
- recorded in an expression in combiner for a pseudo register
- as last known value of that register. The default is 10000.
-
- `integer-share-limit'
- Small integer constants can use a shared data structure,
- reducing the compiler's memory usage and increasing its
- speed. This sets the maximum value of a shared integer
- constant. The default value is 256.
-
- `min-virtual-mappings'
- Specifies the minimum number of virtual mappings in the
- incremental SSA updater that should be registered to trigger
- the virtual mappings heuristic defined by
- virtual-mappings-ratio. The default value is 100.
-
- `virtual-mappings-ratio'
- If the number of virtual mappings is virtual-mappings-ratio
- bigger than the number of virtual symbols to be updated, then
- the incremental SSA updater switches to a full update for
- those symbols. The default ratio is 3.
-
- `ssp-buffer-size'
- The minimum size of buffers (i.e. arrays) that will receive
- stack smashing protection when `-fstack-protection' is used.
-
- `max-jump-thread-duplication-stmts'
- Maximum number of statements allowed in a block that needs to
- be duplicated when threading jumps.
-
- `max-fields-for-field-sensitive'
- Maximum number of fields in a structure we will treat in a
- field sensitive manner during pointer analysis. The default
- is zero for -O0, and -O1 and 100 for -Os, -O2, and -O3.
-
- `prefetch-latency'
- Estimate on average number of instructions that are executed
- before prefetch finishes. The distance we prefetch ahead is
- proportional to this constant. Increasing this number may
- also lead to less streams being prefetched (see
- `simultaneous-prefetches').
-
- `simultaneous-prefetches'
- Maximum number of prefetches that can run at the same time.
-
- `l1-cache-line-size'
- The size of cache line in L1 cache, in bytes.
-
- `l1-cache-size'
- The size of L1 cache, in kilobytes.
-
- `l2-cache-size'
- The size of L2 cache, in kilobytes.
-
- `min-insn-to-prefetch-ratio'
- The minimum ratio between the number of instructions and the
- number of prefetches to enable prefetching in a loop.
-
- `prefetch-min-insn-to-mem-ratio'
- The minimum ratio between the number of instructions and the
- number of memory references to enable prefetching in a loop.
-
- `use-canonical-types'
- Whether the compiler should use the "canonical" type system.
- By default, this should always be 1, which uses a more
- efficient internal mechanism for comparing types in C++ and
- Objective-C++. However, if bugs in the canonical type system
- are causing compilation failures, set this value to 0 to
- disable canonical types.
-
- `switch-conversion-max-branch-ratio'
- Switch initialization conversion will refuse to create arrays
- that are bigger than `switch-conversion-max-branch-ratio'
- times the number of branches in the switch.
-
- `max-partial-antic-length'
- Maximum length of the partial antic set computed during the
- tree partial redundancy elimination optimization
- (`-ftree-pre') when optimizing at `-O3' and above. For some
- sorts of source code the enhanced partial redundancy
- elimination optimization can run away, consuming all of the
- memory available on the host machine. This parameter sets a
- limit on the length of the sets that are computed, which
- prevents the runaway behavior. Setting a value of 0 for this
- parameter will allow an unlimited set length.
-
- `sccvn-max-scc-size'
- Maximum size of a strongly connected component (SCC) during
- SCCVN processing. If this limit is hit, SCCVN processing for
- the whole function will not be done and optimizations
- depending on it will be disabled. The default maximum SCC
- size is 10000.
-
- `ira-max-loops-num'
- IRA uses a regional register allocation by default. If a
- function contains loops more than number given by the
- parameter, only at most given number of the most frequently
- executed loops will form regions for the regional register
- allocation. The default value of the parameter is 100.
-
- `ira-max-conflict-table-size'
- Although IRA uses a sophisticated algorithm of compression
- conflict table, the table can be still big for huge
- functions. If the conflict table for a function could be
- more than size in MB given by the parameter, the conflict
- table is not built and faster, simpler, and lower quality
- register allocation algorithm will be used. The algorithm do
- not use pseudo-register conflicts. The default value of the
- parameter is 2000.
-
- `ira-loop-reserved-regs'
- IRA can be used to evaluate more accurate register pressure
- in loops for decision to move loop invariants (see `-O3').
- The number of available registers reserved for some other
- purposes is described by this parameter. The default value
- of the parameter is 2 which is minimal number of registers
- needed for execution of typical instruction. This value is
- the best found from numerous experiments.
-
- `loop-invariant-max-bbs-in-loop'
- Loop invariant motion can be very expensive, both in compile
- time and in amount of needed compile time memory, with very
- large loops. Loops with more basic blocks than this
- parameter won't have loop invariant motion optimization
- performed on them. The default value of the parameter is
- 1000 for -O1 and 10000 for -O2 and above.
-
- `max-vartrack-size'
- Sets a maximum number of hash table slots to use during
- variable tracking dataflow analysis of any function. If this
- limit is exceeded with variable tracking at assignments
- enabled, analysis for that function is retried without it,
- after removing all debug insns from the function. If the
- limit is exceeded even without debug insns, var tracking
- analysis is completely disabled for the function. Setting
- the parameter to zero makes it unlimited.
-
- `min-nondebug-insn-uid'
- Use uids starting at this parameter for nondebug insns. The
- range below the parameter is reserved exclusively for debug
- insns created by `-fvar-tracking-assignments', but debug
- insns may get (non-overlapping) uids above it if the reserved
- range is exhausted.
-
- `ipa-sra-ptr-growth-factor'
- IPA-SRA will replace a pointer to an aggregate with one or
- more new parameters only when their cumulative size is less
- or equal to `ipa-sra-ptr-growth-factor' times the size of the
- original pointer parameter.
-
- `graphite-max-nb-scop-params'
- To avoid exponential effects in the Graphite loop transforms,
- the number of parameters in a Static Control Part (SCoP) is
- bounded. The default value is 10 parameters. A variable
- whose value is unknown at compile time and defined outside a
- SCoP is a parameter of the SCoP.
-
- `graphite-max-bbs-per-function'
- To avoid exponential effects in the detection of SCoPs, the
- size of the functions analyzed by Graphite is bounded. The
- default value is 100 basic blocks.
-
- `loop-block-tile-size'
- Loop blocking or strip mining transforms, enabled with
- `-floop-block' or `-floop-strip-mine', strip mine each loop
- in the loop nest by a given number of iterations. The strip
- length can be changed using the `loop-block-tile-size'
- parameter. The default value is 51 iterations.
-
- `devirt-type-list-size'
- IPA-CP attempts to track all possible types passed to a
- function's parameter in order to perform devirtualization.
- `devirt-type-list-size' is the maximum number of types it
- stores per a single formal parameter of a function.
-
- `lto-partitions'
- Specify desired number of partitions produced during WHOPR
- compilation. The number of partitions should exceed the
- number of CPUs used for compilation. The default value is 32.
-
- `lto-minpartition'
- Size of minimal partition for WHOPR (in estimated
- instructions). This prevents expenses of splitting very
- small programs into too many partitions.
-
- `cxx-max-namespaces-for-diagnostic-help'
- The maximum number of namespaces to consult for suggestions
- when C++ name lookup fails for an identifier. The default is
- 1000.
-
-
-
-File: gcc.info, Node: Preprocessor Options, Next: Assembler Options, Prev: Optimize Options, Up: Invoking GCC
-
-3.11 Options Controlling the Preprocessor
-=========================================
-
-These options control the C preprocessor, which is run on each C source
-file before actual compilation.
-
- If you use the `-E' option, nothing is done except preprocessing.
-Some of these options make sense only together with `-E' because they
-cause the preprocessor output to be unsuitable for actual compilation.
-
-`-Wp,OPTION'
- You can use `-Wp,OPTION' to bypass the compiler driver and pass
- OPTION directly through to the preprocessor. If OPTION contains
- commas, it is split into multiple options at the commas. However,
- many options are modified, translated or interpreted by the
- compiler driver before being passed to the preprocessor, and `-Wp'
- forcibly bypasses this phase. The preprocessor's direct interface
- is undocumented and subject to change, so whenever possible you
- should avoid using `-Wp' and let the driver handle the options
- instead.
-
-`-Xpreprocessor OPTION'
- Pass OPTION as an option to the preprocessor. You can use this to
- supply system-specific preprocessor options which GCC does not
- know how to recognize.
-
- If you want to pass an option that takes an argument, you must use
- `-Xpreprocessor' twice, once for the option and once for the
- argument.
-
-`-D NAME'
- Predefine NAME as a macro, with definition `1'.
-
-`-D NAME=DEFINITION'
- The contents of DEFINITION are tokenized and processed as if they
- appeared during translation phase three in a `#define' directive.
- In particular, the definition will be truncated by embedded
- newline characters.
-
- If you are invoking the preprocessor from a shell or shell-like
- program you may need to use the shell's quoting syntax to protect
- characters such as spaces that have a meaning in the shell syntax.
-
- If you wish to define a function-like macro on the command line,
- write its argument list with surrounding parentheses before the
- equals sign (if any). Parentheses are meaningful to most shells,
- so you will need to quote the option. With `sh' and `csh',
- `-D'NAME(ARGS...)=DEFINITION'' works.
-
- `-D' and `-U' options are processed in the order they are given on
- the command line. All `-imacros FILE' and `-include FILE' options
- are processed after all `-D' and `-U' options.
-
-`-U NAME'
- Cancel any previous definition of NAME, either built in or
- provided with a `-D' option.
-
-`-undef'
- Do not predefine any system-specific or GCC-specific macros. The
- standard predefined macros remain defined.
-
-`-I DIR'
- Add the directory DIR to the list of directories to be searched
- for header files. Directories named by `-I' are searched before
- the standard system include directories. If the directory DIR is
- a standard system include directory, the option is ignored to
- ensure that the default search order for system directories and
- the special treatment of system headers are not defeated . If DIR
- begins with `=', then the `=' will be replaced by the sysroot
- prefix; see `--sysroot' and `-isysroot'.
-
-`-o FILE'
- Write output to FILE. This is the same as specifying FILE as the
- second non-option argument to `cpp'. `gcc' has a different
- interpretation of a second non-option argument, so you must use
- `-o' to specify the output file.
-
-`-Wall'
- Turns on all optional warnings which are desirable for normal code.
- At present this is `-Wcomment', `-Wtrigraphs', `-Wmultichar' and a
- warning about integer promotion causing a change of sign in `#if'
- expressions. Note that many of the preprocessor's warnings are on
- by default and have no options to control them.
-
-`-Wcomment'
-`-Wcomments'
- Warn whenever a comment-start sequence `/*' appears in a `/*'
- comment, or whenever a backslash-newline appears in a `//' comment.
- (Both forms have the same effect.)
-
-`-Wtrigraphs'
- Most trigraphs in comments cannot affect the meaning of the
- program. However, a trigraph that would form an escaped newline
- (`??/' at the end of a line) can, by changing where the comment
- begins or ends. Therefore, only trigraphs that would form escaped
- newlines produce warnings inside a comment.
-
- This option is implied by `-Wall'. If `-Wall' is not given, this
- option is still enabled unless trigraphs are enabled. To get
- trigraph conversion without warnings, but get the other `-Wall'
- warnings, use `-trigraphs -Wall -Wno-trigraphs'.
-
-`-Wtraditional'
- Warn about certain constructs that behave differently in
- traditional and ISO C. Also warn about ISO C constructs that have
- no traditional C equivalent, and problematic constructs which
- should be avoided.
-
-`-Wundef'
- Warn whenever an identifier which is not a macro is encountered in
- an `#if' directive, outside of `defined'. Such identifiers are
- replaced with zero.
-
-`-Wunused-macros'
- Warn about macros defined in the main file that are unused. A
- macro is "used" if it is expanded or tested for existence at least
- once. The preprocessor will also warn if the macro has not been
- used at the time it is redefined or undefined.
-
- Built-in macros, macros defined on the command line, and macros
- defined in include files are not warned about.
-
- _Note:_ If a macro is actually used, but only used in skipped
- conditional blocks, then CPP will report it as unused. To avoid
- the warning in such a case, you might improve the scope of the
- macro's definition by, for example, moving it into the first
- skipped block. Alternatively, you could provide a dummy use with
- something like:
-
- #if defined the_macro_causing_the_warning
- #endif
-
-`-Wendif-labels'
- Warn whenever an `#else' or an `#endif' are followed by text.
- This usually happens in code of the form
-
- #if FOO
- ...
- #else FOO
- ...
- #endif FOO
-
- The second and third `FOO' should be in comments, but often are not
- in older programs. This warning is on by default.
-
-`-Werror'
- Make all warnings into hard errors. Source code which triggers
- warnings will be rejected.
-
-`-Wsystem-headers'
- Issue warnings for code in system headers. These are normally
- unhelpful in finding bugs in your own code, therefore suppressed.
- If you are responsible for the system library, you may want to see
- them.
-
-`-w'
- Suppress all warnings, including those which GNU CPP issues by
- default.
-
-`-pedantic'
- Issue all the mandatory diagnostics listed in the C standard.
- Some of them are left out by default, since they trigger
- frequently on harmless code.
-
-`-pedantic-errors'
- Issue all the mandatory diagnostics, and make all mandatory
- diagnostics into errors. This includes mandatory diagnostics that
- GCC issues without `-pedantic' but treats as warnings.
-
-`-M'
- Instead of outputting the result of preprocessing, output a rule
- suitable for `make' describing the dependencies of the main source
- file. The preprocessor outputs one `make' rule containing the
- object file name for that source file, a colon, and the names of
- all the included files, including those coming from `-include' or
- `-imacros' command line options.
-
- Unless specified explicitly (with `-MT' or `-MQ'), the object file
- name consists of the name of the source file with any suffix
- replaced with object file suffix and with any leading directory
- parts removed. If there are many included files then the rule is
- split into several lines using `\'-newline. The rule has no
- commands.
-
- This option does not suppress the preprocessor's debug output,
- such as `-dM'. To avoid mixing such debug output with the
- dependency rules you should explicitly specify the dependency
- output file with `-MF', or use an environment variable like
- `DEPENDENCIES_OUTPUT' (*note Environment Variables::). Debug
- output will still be sent to the regular output stream as normal.
-
- Passing `-M' to the driver implies `-E', and suppresses warnings
- with an implicit `-w'.
-
-`-MM'
- Like `-M' but do not mention header files that are found in system
- header directories, nor header files that are included, directly
- or indirectly, from such a header.
-
- This implies that the choice of angle brackets or double quotes in
- an `#include' directive does not in itself determine whether that
- header will appear in `-MM' dependency output. This is a slight
- change in semantics from GCC versions 3.0 and earlier.
-
-`-MF FILE'
- When used with `-M' or `-MM', specifies a file to write the
- dependencies to. If no `-MF' switch is given the preprocessor
- sends the rules to the same place it would have sent preprocessed
- output.
-
- When used with the driver options `-MD' or `-MMD', `-MF' overrides
- the default dependency output file.
-
-`-MG'
- In conjunction with an option such as `-M' requesting dependency
- generation, `-MG' assumes missing header files are generated files
- and adds them to the dependency list without raising an error.
- The dependency filename is taken directly from the `#include'
- directive without prepending any path. `-MG' also suppresses
- preprocessed output, as a missing header file renders this useless.
-
- This feature is used in automatic updating of makefiles.
-
-`-MP'
- This option instructs CPP to add a phony target for each dependency
- other than the main file, causing each to depend on nothing. These
- dummy rules work around errors `make' gives if you remove header
- files without updating the `Makefile' to match.
-
- This is typical output:
-
- test.o: test.c test.h
-
- test.h:
-
-`-MT TARGET'
- Change the target of the rule emitted by dependency generation. By
- default CPP takes the name of the main input file, deletes any
- directory components and any file suffix such as `.c', and appends
- the platform's usual object suffix. The result is the target.
-
- An `-MT' option will set the target to be exactly the string you
- specify. If you want multiple targets, you can specify them as a
- single argument to `-MT', or use multiple `-MT' options.
-
- For example, `-MT '$(objpfx)foo.o'' might give
-
- $(objpfx)foo.o: foo.c
-
-`-MQ TARGET'
- Same as `-MT', but it quotes any characters which are special to
- Make. `-MQ '$(objpfx)foo.o'' gives
-
- $$(objpfx)foo.o: foo.c
-
- The default target is automatically quoted, as if it were given
- with `-MQ'.
-
-`-MD'
- `-MD' is equivalent to `-M -MF FILE', except that `-E' is not
- implied. The driver determines FILE based on whether an `-o'
- option is given. If it is, the driver uses its argument but with
- a suffix of `.d', otherwise it takes the name of the input file,
- removes any directory components and suffix, and applies a `.d'
- suffix.
-
- If `-MD' is used in conjunction with `-E', any `-o' switch is
- understood to specify the dependency output file (*note -MF:
- dashMF.), but if used without `-E', each `-o' is understood to
- specify a target object file.
-
- Since `-E' is not implied, `-MD' can be used to generate a
- dependency output file as a side-effect of the compilation process.
-
-`-MMD'
- Like `-MD' except mention only user header files, not system
- header files.
-
-`-fpch-deps'
- When using precompiled headers (*note Precompiled Headers::), this
- flag will cause the dependency-output flags to also list the files
- from the precompiled header's dependencies. If not specified only
- the precompiled header would be listed and not the files that were
- used to create it because those files are not consulted when a
- precompiled header is used.
-
-`-fpch-preprocess'
- This option allows use of a precompiled header (*note Precompiled
- Headers::) together with `-E'. It inserts a special `#pragma',
- `#pragma GCC pch_preprocess "FILENAME"' in the output to mark the
- place where the precompiled header was found, and its FILENAME.
- When `-fpreprocessed' is in use, GCC recognizes this `#pragma' and
- loads the PCH.
-
- This option is off by default, because the resulting preprocessed
- output is only really suitable as input to GCC. It is switched on
- by `-save-temps'.
-
- You should not write this `#pragma' in your own code, but it is
- safe to edit the filename if the PCH file is available in a
- different location. The filename may be absolute or it may be
- relative to GCC's current directory.
-
-`-x c'
-`-x c++'
-`-x objective-c'
-`-x assembler-with-cpp'
- Specify the source language: C, C++, Objective-C, or assembly.
- This has nothing to do with standards conformance or extensions;
- it merely selects which base syntax to expect. If you give none
- of these options, cpp will deduce the language from the extension
- of the source file: `.c', `.cc', `.m', or `.S'. Some other common
- extensions for C++ and assembly are also recognized. If cpp does
- not recognize the extension, it will treat the file as C; this is
- the most generic mode.
-
- _Note:_ Previous versions of cpp accepted a `-lang' option which
- selected both the language and the standards conformance level.
- This option has been removed, because it conflicts with the `-l'
- option.
-
-`-std=STANDARD'
-`-ansi'
- Specify the standard to which the code should conform. Currently
- CPP knows about C and C++ standards; others may be added in the
- future.
-
- STANDARD may be one of:
- `c90'
- `c89'
- `iso9899:1990'
- The ISO C standard from 1990. `c90' is the customary
- shorthand for this version of the standard.
-
- The `-ansi' option is equivalent to `-std=c90'.
-
- `iso9899:199409'
- The 1990 C standard, as amended in 1994.
-
- `iso9899:1999'
- `c99'
- `iso9899:199x'
- `c9x'
- The revised ISO C standard, published in December 1999.
- Before publication, this was known as C9X.
-
- `c1x'
- The next version of the ISO C standard, still under
- development.
-
- `gnu90'
- `gnu89'
- The 1990 C standard plus GNU extensions. This is the default.
-
- `gnu99'
- `gnu9x'
- The 1999 C standard plus GNU extensions.
-
- `gnu1x'
- The next version of the ISO C standard, still under
- development, plus GNU extensions.
-
- `c++98'
- The 1998 ISO C++ standard plus amendments.
-
- `gnu++98'
- The same as `-std=c++98' plus GNU extensions. This is the
- default for C++ code.
-
-`-I-'
- Split the include path. Any directories specified with `-I'
- options before `-I-' are searched only for headers requested with
- `#include "FILE"'; they are not searched for `#include <FILE>'.
- If additional directories are specified with `-I' options after
- the `-I-', those directories are searched for all `#include'
- directives.
-
- In addition, `-I-' inhibits the use of the directory of the current
- file directory as the first search directory for `#include "FILE"'.
- This option has been deprecated.
-
-`-nostdinc'
- Do not search the standard system directories for header files.
- Only the directories you have specified with `-I' options (and the
- directory of the current file, if appropriate) are searched.
-
-`-nostdinc++'
- Do not search for header files in the C++-specific standard
- directories, but do still search the other standard directories.
- (This option is used when building the C++ library.)
-
-`-include FILE'
- Process FILE as if `#include "file"' appeared as the first line of
- the primary source file. However, the first directory searched
- for FILE is the preprocessor's working directory _instead of_ the
- directory containing the main source file. If not found there, it
- is searched for in the remainder of the `#include "..."' search
- chain as normal.
-
- If multiple `-include' options are given, the files are included
- in the order they appear on the command line.
-
-`-imacros FILE'
- Exactly like `-include', except that any output produced by
- scanning FILE is thrown away. Macros it defines remain defined.
- This allows you to acquire all the macros from a header without
- also processing its declarations.
-
- All files specified by `-imacros' are processed before all files
- specified by `-include'.
-
-`-idirafter DIR'
- Search DIR for header files, but do it _after_ all directories
- specified with `-I' and the standard system directories have been
- exhausted. DIR is treated as a system include directory. If DIR
- begins with `=', then the `=' will be replaced by the sysroot
- prefix; see `--sysroot' and `-isysroot'.
-
-`-iprefix PREFIX'
- Specify PREFIX as the prefix for subsequent `-iwithprefix'
- options. If the prefix represents a directory, you should include
- the final `/'.
-
-`-iwithprefix DIR'
-`-iwithprefixbefore DIR'
- Append DIR to the prefix specified previously with `-iprefix', and
- add the resulting directory to the include search path.
- `-iwithprefixbefore' puts it in the same place `-I' would;
- `-iwithprefix' puts it where `-idirafter' would.
-
-`-isysroot DIR'
- This option is like the `--sysroot' option, but applies only to
- header files (except for Darwin targets, where it applies to both
- header files and libraries). See the `--sysroot' option for more
- information.
-
-`-imultilib DIR'
- Use DIR as a subdirectory of the directory containing
- target-specific C++ headers.
-
-`-isystem DIR'
- Search DIR for header files, after all directories specified by
- `-I' but before the standard system directories. Mark it as a
- system directory, so that it gets the same special treatment as is
- applied to the standard system directories. If DIR begins with
- `=', then the `=' will be replaced by the sysroot prefix; see
- `--sysroot' and `-isysroot'.
-
-`-iquote DIR'
- Search DIR only for header files requested with `#include "FILE"';
- they are not searched for `#include <FILE>', before all
- directories specified by `-I' and before the standard system
- directories. If DIR begins with `=', then the `=' will be replaced
- by the sysroot prefix; see `--sysroot' and `-isysroot'.
-
-`-fdirectives-only'
- When preprocessing, handle directives, but do not expand macros.
-
- The option's behavior depends on the `-E' and `-fpreprocessed'
- options.
-
- With `-E', preprocessing is limited to the handling of directives
- such as `#define', `#ifdef', and `#error'. Other preprocessor
- operations, such as macro expansion and trigraph conversion are
- not performed. In addition, the `-dD' option is implicitly
- enabled.
-
- With `-fpreprocessed', predefinition of command line and most
- builtin macros is disabled. Macros such as `__LINE__', which are
- contextually dependent, are handled normally. This enables
- compilation of files previously preprocessed with `-E
- -fdirectives-only'.
-
- With both `-E' and `-fpreprocessed', the rules for
- `-fpreprocessed' take precedence. This enables full preprocessing
- of files previously preprocessed with `-E -fdirectives-only'.
-
-`-fdollars-in-identifiers'
- Accept `$' in identifiers.
-
-`-fextended-identifiers'
- Accept universal character names in identifiers. This option is
- experimental; in a future version of GCC, it will be enabled by
- default for C99 and C++.
-
-`-fpreprocessed'
- Indicate to the preprocessor that the input file has already been
- preprocessed. This suppresses things like macro expansion,
- trigraph conversion, escaped newline splicing, and processing of
- most directives. The preprocessor still recognizes and removes
- comments, so that you can pass a file preprocessed with `-C' to
- the compiler without problems. In this mode the integrated
- preprocessor is little more than a tokenizer for the front ends.
-
- `-fpreprocessed' is implicit if the input file has one of the
- extensions `.i', `.ii' or `.mi'. These are the extensions that
- GCC uses for preprocessed files created by `-save-temps'.
-
-`-ftabstop=WIDTH'
- Set the distance between tab stops. This helps the preprocessor
- report correct column numbers in warnings or errors, even if tabs
- appear on the line. If the value is less than 1 or greater than
- 100, the option is ignored. The default is 8.
-
-`-fexec-charset=CHARSET'
- Set the execution character set, used for string and character
- constants. The default is UTF-8. CHARSET can be any encoding
- supported by the system's `iconv' library routine.
-
-`-fwide-exec-charset=CHARSET'
- Set the wide execution character set, used for wide string and
- character constants. The default is UTF-32 or UTF-16, whichever
- corresponds to the width of `wchar_t'. As with `-fexec-charset',
- CHARSET can be any encoding supported by the system's `iconv'
- library routine; however, you will have problems with encodings
- that do not fit exactly in `wchar_t'.
-
-`-finput-charset=CHARSET'
- Set the input character set, used for translation from the
- character set of the input file to the source character set used
- by GCC. If the locale does not specify, or GCC cannot get this
- information from the locale, the default is UTF-8. This can be
- overridden by either the locale or this command line option.
- Currently the command line option takes precedence if there's a
- conflict. CHARSET can be any encoding supported by the system's
- `iconv' library routine.
-
-`-fworking-directory'
- Enable generation of linemarkers in the preprocessor output that
- will let the compiler know the current working directory at the
- time of preprocessing. When this option is enabled, the
- preprocessor will emit, after the initial linemarker, a second
- linemarker with the current working directory followed by two
- slashes. GCC will use this directory, when it's present in the
- preprocessed input, as the directory emitted as the current
- working directory in some debugging information formats. This
- option is implicitly enabled if debugging information is enabled,
- but this can be inhibited with the negated form
- `-fno-working-directory'. If the `-P' flag is present in the
- command line, this option has no effect, since no `#line'
- directives are emitted whatsoever.
-
-`-fno-show-column'
- Do not print column numbers in diagnostics. This may be necessary
- if diagnostics are being scanned by a program that does not
- understand the column numbers, such as `dejagnu'.
-
-`-A PREDICATE=ANSWER'
- Make an assertion with the predicate PREDICATE and answer ANSWER.
- This form is preferred to the older form `-A PREDICATE(ANSWER)',
- which is still supported, because it does not use shell special
- characters.
-
-`-A -PREDICATE=ANSWER'
- Cancel an assertion with the predicate PREDICATE and answer ANSWER.
-
-`-dCHARS'
- CHARS is a sequence of one or more of the following characters,
- and must not be preceded by a space. Other characters are
- interpreted by the compiler proper, or reserved for future
- versions of GCC, and so are silently ignored. If you specify
- characters whose behavior conflicts, the result is undefined.
-
- `M'
- Instead of the normal output, generate a list of `#define'
- directives for all the macros defined during the execution of
- the preprocessor, including predefined macros. This gives
- you a way of finding out what is predefined in your version
- of the preprocessor. Assuming you have no file `foo.h', the
- command
-
- touch foo.h; cpp -dM foo.h
-
- will show all the predefined macros.
-
- If you use `-dM' without the `-E' option, `-dM' is
- interpreted as a synonym for `-fdump-rtl-mach'. *Note
- Debugging Options: (gcc)Debugging Options.
-
- `D'
- Like `M' except in two respects: it does _not_ include the
- predefined macros, and it outputs _both_ the `#define'
- directives and the result of preprocessing. Both kinds of
- output go to the standard output file.
-
- `N'
- Like `D', but emit only the macro names, not their expansions.
-
- `I'
- Output `#include' directives in addition to the result of
- preprocessing.
-
- `U'
- Like `D' except that only macros that are expanded, or whose
- definedness is tested in preprocessor directives, are output;
- the output is delayed until the use or test of the macro; and
- `#undef' directives are also output for macros tested but
- undefined at the time.
-
-`-P'
- Inhibit generation of linemarkers in the output from the
- preprocessor. This might be useful when running the preprocessor
- on something that is not C code, and will be sent to a program
- which might be confused by the linemarkers.
-
-`-C'
- Do not discard comments. All comments are passed through to the
- output file, except for comments in processed directives, which
- are deleted along with the directive.
-
- You should be prepared for side effects when using `-C'; it causes
- the preprocessor to treat comments as tokens in their own right.
- For example, comments appearing at the start of what would be a
- directive line have the effect of turning that line into an
- ordinary source line, since the first token on the line is no
- longer a `#'.
-
-`-CC'
- Do not discard comments, including during macro expansion. This is
- like `-C', except that comments contained within macros are also
- passed through to the output file where the macro is expanded.
-
- In addition to the side-effects of the `-C' option, the `-CC'
- option causes all C++-style comments inside a macro to be
- converted to C-style comments. This is to prevent later use of
- that macro from inadvertently commenting out the remainder of the
- source line.
-
- The `-CC' option is generally used to support lint comments.
-
-`-traditional-cpp'
- Try to imitate the behavior of old-fashioned C preprocessors, as
- opposed to ISO C preprocessors.
-
-`-trigraphs'
- Process trigraph sequences. These are three-character sequences,
- all starting with `??', that are defined by ISO C to stand for
- single characters. For example, `??/' stands for `\', so `'??/n''
- is a character constant for a newline. By default, GCC ignores
- trigraphs, but in standard-conforming modes it converts them. See
- the `-std' and `-ansi' options.
-
- The nine trigraphs and their replacements are
-
- Trigraph: ??( ??) ??< ??> ??= ??/ ??' ??! ??-
- Replacement: [ ] { } # \ ^ | ~
-
-`-remap'
- Enable special code to work around file systems which only permit
- very short file names, such as MS-DOS.
-
-`--help'
-`--target-help'
- Print text describing all the command line options instead of
- preprocessing anything.
-
-`-v'
- Verbose mode. Print out GNU CPP's version number at the beginning
- of execution, and report the final form of the include path.
-
-`-H'
- Print the name of each header file used, in addition to other
- normal activities. Each name is indented to show how deep in the
- `#include' stack it is. Precompiled header files are also
- printed, even if they are found to be invalid; an invalid
- precompiled header file is printed with `...x' and a valid one
- with `...!' .
-
-`-version'
-`--version'
- Print out GNU CPP's version number. With one dash, proceed to
- preprocess as normal. With two dashes, exit immediately.
-
-
-File: gcc.info, Node: Assembler Options, Next: Link Options, Prev: Preprocessor Options, Up: Invoking GCC
-
-3.12 Passing Options to the Assembler
-=====================================
-
-You can pass options to the assembler.
-
-`-Wa,OPTION'
- Pass OPTION as an option to the assembler. If OPTION contains
- commas, it is split into multiple options at the commas.
-
-`-Xassembler OPTION'
- Pass OPTION as an option to the assembler. You can use this to
- supply system-specific assembler options which GCC does not know
- how to recognize.
-
- If you want to pass an option that takes an argument, you must use
- `-Xassembler' twice, once for the option and once for the argument.
-
-`profile-generate-sampling-rate'
- Set the sampling rate with `-fprofile-generate-sampling'.
-
-
-
-File: gcc.info, Node: Link Options, Next: Directory Options, Prev: Assembler Options, Up: Invoking GCC
-
-3.13 Options for Linking
-========================
-
-These options come into play when the compiler links object files into
-an executable output file. They are meaningless if the compiler is not
-doing a link step.
-
-`OBJECT-FILE-NAME'
- A file name that does not end in a special recognized suffix is
- considered to name an object file or library. (Object files are
- distinguished from libraries by the linker according to the file
- contents.) If linking is done, these object files are used as
- input to the linker.
-
-`-c'
-`-S'
-`-E'
- If any of these options is used, then the linker is not run, and
- object file names should not be used as arguments. *Note Overall
- Options::.
-
-`-lLIBRARY'
-`-l LIBRARY'
- Search the library named LIBRARY when linking. (The second
- alternative with the library as a separate argument is only for
- POSIX compliance and is not recommended.)
-
- It makes a difference where in the command you write this option;
- the linker searches and processes libraries and object files in
- the order they are specified. Thus, `foo.o -lz bar.o' searches
- library `z' after file `foo.o' but before `bar.o'. If `bar.o'
- refers to functions in `z', those functions may not be loaded.
-
- The linker searches a standard list of directories for the library,
- which is actually a file named `libLIBRARY.a'. The linker then
- uses this file as if it had been specified precisely by name.
-
- The directories searched include several standard system
- directories plus any that you specify with `-L'.
-
- Normally the files found this way are library files--archive files
- whose members are object files. The linker handles an archive
- file by scanning through it for members which define symbols that
- have so far been referenced but not defined. But if the file that
- is found is an ordinary object file, it is linked in the usual
- fashion. The only difference between using an `-l' option and
- specifying a file name is that `-l' surrounds LIBRARY with `lib'
- and `.a' and searches several directories.
-
-`-lobjc'
- You need this special case of the `-l' option in order to link an
- Objective-C or Objective-C++ program.
-
-`-nostartfiles'
- Do not use the standard system startup files when linking. The
- standard system libraries are used normally, unless `-nostdlib' or
- `-nodefaultlibs' is used.
-
-`-nodefaultlibs'
- Do not use the standard system libraries when linking. Only the
- libraries you specify will be passed to the linker, options
- specifying linkage of the system libraries, such as
- `-static-libgcc' or `-shared-libgcc', will be ignored. The
- standard startup files are used normally, unless `-nostartfiles'
- is used. The compiler may generate calls to `memcmp', `memset',
- `memcpy' and `memmove'. These entries are usually resolved by
- entries in libc. These entry points should be supplied through
- some other mechanism when this option is specified.
-
-`-nostdlib'
- Do not use the standard system startup files or libraries when
- linking. No startup files and only the libraries you specify will
- be passed to the linker, options specifying linkage of the system
- libraries, such as `-static-libgcc' or `-shared-libgcc', will be
- ignored. The compiler may generate calls to `memcmp', `memset',
- `memcpy' and `memmove'. These entries are usually resolved by
- entries in libc. These entry points should be supplied through
- some other mechanism when this option is specified.
-
- One of the standard libraries bypassed by `-nostdlib' and
- `-nodefaultlibs' is `libgcc.a', a library of internal subroutines
- that GCC uses to overcome shortcomings of particular machines, or
- special needs for some languages. (*Note Interfacing to GCC
- Output: (gccint)Interface, for more discussion of `libgcc.a'.) In
- most cases, you need `libgcc.a' even when you want to avoid other
- standard libraries. In other words, when you specify `-nostdlib'
- or `-nodefaultlibs' you should usually specify `-lgcc' as well.
- This ensures that you have no unresolved references to internal GCC
- library subroutines. (For example, `__main', used to ensure C++
- constructors will be called; *note `collect2': (gccint)Collect2.)
-
-`-pie'
- Produce a position independent executable on targets which support
- it. For predictable results, you must also specify the same set
- of options that were used to generate code (`-fpie', `-fPIE', or
- model suboptions) when you specify this option.
-
-`-rdynamic'
- Pass the flag `-export-dynamic' to the ELF linker, on targets that
- support it. This instructs the linker to add all symbols, not only
- used ones, to the dynamic symbol table. This option is needed for
- some uses of `dlopen' or to allow obtaining backtraces from within
- a program.
-
-`-s'
- Remove all symbol table and relocation information from the
- executable.
-
-`-static'
- On systems that support dynamic linking, this prevents linking
- with the shared libraries. On other systems, this option has no
- effect.
-
-`-shared'
- Produce a shared object which can then be linked with other
- objects to form an executable. Not all systems support this
- option. For predictable results, you must also specify the same
- set of options that were used to generate code (`-fpic', `-fPIC',
- or model suboptions) when you specify this option.(1)
-
-`-shared-libgcc'
-`-static-libgcc'
- On systems that provide `libgcc' as a shared library, these options
- force the use of either the shared or static version respectively.
- If no shared version of `libgcc' was built when the compiler was
- configured, these options have no effect.
-
- There are several situations in which an application should use the
- shared `libgcc' instead of the static version. The most common of
- these is when the application wishes to throw and catch exceptions
- across different shared libraries. In that case, each of the
- libraries as well as the application itself should use the shared
- `libgcc'.
-
- Therefore, the G++ and GCJ drivers automatically add
- `-shared-libgcc' whenever you build a shared library or a main
- executable, because C++ and Java programs typically use
- exceptions, so this is the right thing to do.
-
- If, instead, you use the GCC driver to create shared libraries,
- you may find that they will not always be linked with the shared
- `libgcc'. If GCC finds, at its configuration time, that you have
- a non-GNU linker or a GNU linker that does not support option
- `--eh-frame-hdr', it will link the shared version of `libgcc' into
- shared libraries by default. Otherwise, it will take advantage of
- the linker and optimize away the linking with the shared version
- of `libgcc', linking with the static version of libgcc by default.
- This allows exceptions to propagate through such shared libraries,
- without incurring relocation costs at library load time.
-
- However, if a library or main executable is supposed to throw or
- catch exceptions, you must link it using the G++ or GCJ driver, as
- appropriate for the languages used in the program, or using the
- option `-shared-libgcc', such that it is linked with the shared
- `libgcc'.
-
-`-static-libstdc++'
- When the `g++' program is used to link a C++ program, it will
- normally automatically link against `libstdc++'. If `libstdc++'
- is available as a shared library, and the `-static' option is not
- used, then this will link against the shared version of
- `libstdc++'. That is normally fine. However, it is sometimes
- useful to freeze the version of `libstdc++' used by the program
- without going all the way to a fully static link. The
- `-static-libstdc++' option directs the `g++' driver to link
- `libstdc++' statically, without necessarily linking other
- libraries statically.
-
-`-symbolic'
- Bind references to global symbols when building a shared object.
- Warn about any unresolved references (unless overridden by the
- link editor option `-Xlinker -z -Xlinker defs'). Only a few
- systems support this option.
-
-`-T SCRIPT'
- Use SCRIPT as the linker script. This option is supported by most
- systems using the GNU linker. On some targets, such as bare-board
- targets without an operating system, the `-T' option may be
- required when linking to avoid references to undefined symbols.
-
-`-Xlinker OPTION'
- Pass OPTION as an option to the linker. You can use this to
- supply system-specific linker options which GCC does not know how
- to recognize.
-
- If you want to pass an option that takes a separate argument, you
- must use `-Xlinker' twice, once for the option and once for the
- argument. For example, to pass `-assert definitions', you must
- write `-Xlinker -assert -Xlinker definitions'. It does not work
- to write `-Xlinker "-assert definitions"', because this passes the
- entire string as a single argument, which is not what the linker
- expects.
-
- When using the GNU linker, it is usually more convenient to pass
- arguments to linker options using the `OPTION=VALUE' syntax than
- as separate arguments. For example, you can specify `-Xlinker
- -Map=output.map' rather than `-Xlinker -Map -Xlinker output.map'.
- Other linkers may not support this syntax for command-line options.
-
-`-Wl,OPTION'
- Pass OPTION as an option to the linker. If OPTION contains
- commas, it is split into multiple options at the commas. You can
- use this syntax to pass an argument to the option. For example,
- `-Wl,-Map,output.map' passes `-Map output.map' to the linker.
- When using the GNU linker, you can also get the same effect with
- `-Wl,-Map=output.map'.
-
-`-u SYMBOL'
- Pretend the symbol SYMBOL is undefined, to force linking of
- library modules to define it. You can use `-u' multiple times with
- different symbols to force loading of additional library modules.
-
- ---------- Footnotes ----------
-
- (1) On some systems, `gcc -shared' needs to build supplementary stub
-code for constructors to work. On multi-libbed systems, `gcc -shared'
-must select the correct support libraries to link against. Failing to
-supply the correct flags may lead to subtle defects. Supplying them in
-cases where they are not necessary is innocuous.
-
-
-File: gcc.info, Node: Directory Options, Next: Spec Files, Prev: Link Options, Up: Invoking GCC
-
-3.14 Options for Directory Search
-=================================
-
-These options specify directories to search for header files, for
-libraries and for parts of the compiler:
-
-`-IDIR'
- Add the directory DIR to the head of the list of directories to be
- searched for header files. This can be used to override a system
- header file, substituting your own version, since these
- directories are searched before the system header file
- directories. However, you should not use this option to add
- directories that contain vendor-supplied system header files (use
- `-isystem' for that). If you use more than one `-I' option, the
- directories are scanned in left-to-right order; the standard
- system directories come after.
-
- If a standard system include directory, or a directory specified
- with `-isystem', is also specified with `-I', the `-I' option will
- be ignored. The directory will still be searched but as a system
- directory at its normal position in the system include chain.
- This is to ensure that GCC's procedure to fix buggy system headers
- and the ordering for the include_next directive are not
- inadvertently changed. If you really need to change the search
- order for system directories, use the `-nostdinc' and/or
- `-isystem' options.
-
-`-iplugindir=DIR'
- Set the directory to search for plugins which are passed by
- `-fplugin=NAME' instead of `-fplugin=PATH/NAME.so'. This option
- is not meant to be used by the user, but only passed by the driver.
-
-`-iquoteDIR'
- Add the directory DIR to the head of the list of directories to be
- searched for header files only for the case of `#include "FILE"';
- they are not searched for `#include <FILE>', otherwise just like
- `-I'.
-
-`-LDIR'
- Add directory DIR to the list of directories to be searched for
- `-l'.
-
-`-BPREFIX'
- This option specifies where to find the executables, libraries,
- include files, and data files of the compiler itself.
-
- The compiler driver program runs one or more of the subprograms
- `cpp', `cc1', `as' and `ld'. It tries PREFIX as a prefix for each
- program it tries to run, both with and without `MACHINE/VERSION/'
- (*note Target Options::).
-
- For each subprogram to be run, the compiler driver first tries the
- `-B' prefix, if any. If that name is not found, or if `-B' was
- not specified, the driver tries two standard prefixes, which are
- `/usr/lib/gcc/' and `/usr/local/lib/gcc/'. If neither of those
- results in a file name that is found, the unmodified program name
- is searched for using the directories specified in your `PATH'
- environment variable.
-
- The compiler will check to see if the path provided by the `-B'
- refers to a directory, and if necessary it will add a directory
- separator character at the end of the path.
-
- `-B' prefixes that effectively specify directory names also apply
- to libraries in the linker, because the compiler translates these
- options into `-L' options for the linker. They also apply to
- includes files in the preprocessor, because the compiler
- translates these options into `-isystem' options for the
- preprocessor. In this case, the compiler appends `include' to the
- prefix.
-
- The run-time support file `libgcc.a' can also be searched for using
- the `-B' prefix, if needed. If it is not found there, the two
- standard prefixes above are tried, and that is all. The file is
- left out of the link if it is not found by those means.
-
- Another way to specify a prefix much like the `-B' prefix is to use
- the environment variable `GCC_EXEC_PREFIX'. *Note Environment
- Variables::.
-
- As a special kludge, if the path provided by `-B' is
- `[dir/]stageN/', where N is a number in the range 0 to 9, then it
- will be replaced by `[dir/]include'. This is to help with
- boot-strapping the compiler.
-
-`-specs=FILE'
- Process FILE after the compiler reads in the standard `specs'
- file, in order to override the defaults that the `gcc' driver
- program uses when determining what switches to pass to `cc1',
- `cc1plus', `as', `ld', etc. More than one `-specs=FILE' can be
- specified on the command line, and they are processed in order,
- from left to right.
-
-`--sysroot=DIR'
- Use DIR as the logical root directory for headers and libraries.
- For example, if the compiler would normally search for headers in
- `/usr/include' and libraries in `/usr/lib', it will instead search
- `DIR/usr/include' and `DIR/usr/lib'.
-
- If you use both this option and the `-isysroot' option, then the
- `--sysroot' option will apply to libraries, but the `-isysroot'
- option will apply to header files.
-
- The GNU linker (beginning with version 2.16) has the necessary
- support for this option. If your linker does not support this
- option, the header file aspect of `--sysroot' will still work, but
- the library aspect will not.
-
-`-I-'
- This option has been deprecated. Please use `-iquote' instead for
- `-I' directories before the `-I-' and remove the `-I-'. Any
- directories you specify with `-I' options before the `-I-' option
- are searched only for the case of `#include "FILE"'; they are not
- searched for `#include <FILE>'.
-
- If additional directories are specified with `-I' options after
- the `-I-', these directories are searched for all `#include'
- directives. (Ordinarily _all_ `-I' directories are used this way.)
-
- In addition, the `-I-' option inhibits the use of the current
- directory (where the current input file came from) as the first
- search directory for `#include "FILE"'. There is no way to
- override this effect of `-I-'. With `-I.' you can specify
- searching the directory which was current when the compiler was
- invoked. That is not exactly the same as what the preprocessor
- does by default, but it is often satisfactory.
-
- `-I-' does not inhibit the use of the standard system directories
- for header files. Thus, `-I-' and `-nostdinc' are independent.
-
-
-File: gcc.info, Node: Spec Files, Next: Target Options, Prev: Directory Options, Up: Invoking GCC
-
-3.15 Specifying subprocesses and the switches to pass to them
-=============================================================
-
-`gcc' is a driver program. It performs its job by invoking a sequence
-of other programs to do the work of compiling, assembling and linking.
-GCC interprets its command-line parameters and uses these to deduce
-which programs it should invoke, and which command-line options it
-ought to place on their command lines. This behavior is controlled by
-"spec strings". In most cases there is one spec string for each
-program that GCC can invoke, but a few programs have multiple spec
-strings to control their behavior. The spec strings built into GCC can
-be overridden by using the `-specs=' command-line switch to specify a
-spec file.
-
- "Spec files" are plaintext files that are used to construct spec
-strings. They consist of a sequence of directives separated by blank
-lines. The type of directive is determined by the first non-whitespace
-character on the line and it can be one of the following:
-
-`%COMMAND'
- Issues a COMMAND to the spec file processor. The commands that can
- appear here are:
-
- `%include <FILE>'
- Search for FILE and insert its text at the current point in
- the specs file.
-
- `%include_noerr <FILE>'
- Just like `%include', but do not generate an error message if
- the include file cannot be found.
-
- `%rename OLD_NAME NEW_NAME'
- Rename the spec string OLD_NAME to NEW_NAME.
-
-
-`*[SPEC_NAME]:'
- This tells the compiler to create, override or delete the named
- spec string. All lines after this directive up to the next
- directive or blank line are considered to be the text for the spec
- string. If this results in an empty string then the spec will be
- deleted. (Or, if the spec did not exist, then nothing will
- happened.) Otherwise, if the spec does not currently exist a new
- spec will be created. If the spec does exist then its contents
- will be overridden by the text of this directive, unless the first
- character of that text is the `+' character, in which case the
- text will be appended to the spec.
-
-`[SUFFIX]:'
- Creates a new `[SUFFIX] spec' pair. All lines after this directive
- and up to the next directive or blank line are considered to make
- up the spec string for the indicated suffix. When the compiler
- encounters an input file with the named suffix, it will processes
- the spec string in order to work out how to compile that file.
- For example:
-
- .ZZ:
- z-compile -input %i
-
- This says that any input file whose name ends in `.ZZ' should be
- passed to the program `z-compile', which should be invoked with the
- command-line switch `-input' and with the result of performing the
- `%i' substitution. (See below.)
-
- As an alternative to providing a spec string, the text that
- follows a suffix directive can be one of the following:
-
- `@LANGUAGE'
- This says that the suffix is an alias for a known LANGUAGE.
- This is similar to using the `-x' command-line switch to GCC
- to specify a language explicitly. For example:
-
- .ZZ:
- @c++
-
- Says that .ZZ files are, in fact, C++ source files.
-
- `#NAME'
- This causes an error messages saying:
-
- NAME compiler not installed on this system.
-
- GCC already has an extensive list of suffixes built into it. This
- directive will add an entry to the end of the list of suffixes, but
- since the list is searched from the end backwards, it is
- effectively possible to override earlier entries using this
- technique.
-
-
- GCC has the following spec strings built into it. Spec files can
-override these strings or create their own. Note that individual
-targets can also add their own spec strings to this list.
-
- asm Options to pass to the assembler
- asm_final Options to pass to the assembler post-processor
- cpp Options to pass to the C preprocessor
- cc1 Options to pass to the C compiler
- cc1plus Options to pass to the C++ compiler
- endfile Object files to include at the end of the link
- link Options to pass to the linker
- lib Libraries to include on the command line to the linker
- libgcc Decides which GCC support library to pass to the linker
- linker Sets the name of the linker
- predefines Defines to be passed to the C preprocessor
- signed_char Defines to pass to CPP to say whether `char' is signed
- by default
- startfile Object files to include at the start of the link
-
- Here is a small example of a spec file:
-
- %rename lib old_lib
-
- *lib:
- --start-group -lgcc -lc -leval1 --end-group %(old_lib)
-
- This example renames the spec called `lib' to `old_lib' and then
-overrides the previous definition of `lib' with a new one. The new
-definition adds in some extra command-line options before including the
-text of the old definition.
-
- "Spec strings" are a list of command-line options to be passed to their
-corresponding program. In addition, the spec strings can contain
-`%'-prefixed sequences to substitute variable text or to conditionally
-insert text into the command line. Using these constructs it is
-possible to generate quite complex command lines.
-
- Here is a table of all defined `%'-sequences for spec strings. Note
-that spaces are not generated automatically around the results of
-expanding these sequences. Therefore you can concatenate them together
-or combine them with constant text in a single argument.
-
-`%%'
- Substitute one `%' into the program name or argument.
-
-`%i'
- Substitute the name of the input file being processed.
-
-`%b'
- Substitute the basename of the input file being processed. This
- is the substring up to (and not including) the last period and not
- including the directory.
-
-`%B'
- This is the same as `%b', but include the file suffix (text after
- the last period).
-
-`%d'
- Marks the argument containing or following the `%d' as a temporary
- file name, so that that file will be deleted if GCC exits
- successfully. Unlike `%g', this contributes no text to the
- argument.
-
-`%gSUFFIX'
- Substitute a file name that has suffix SUFFIX and is chosen once
- per compilation, and mark the argument in the same way as `%d'.
- To reduce exposure to denial-of-service attacks, the file name is
- now chosen in a way that is hard to predict even when previously
- chosen file names are known. For example, `%g.s ... %g.o ... %g.s'
- might turn into `ccUVUUAU.s ccXYAXZ12.o ccUVUUAU.s'. SUFFIX
- matches the regexp `[.A-Za-z]*' or the special string `%O', which
- is treated exactly as if `%O' had been preprocessed. Previously,
- `%g' was simply substituted with a file name chosen once per
- compilation, without regard to any appended suffix (which was
- therefore treated just like ordinary text), making such attacks
- more likely to succeed.
-
-`%uSUFFIX'
- Like `%g', but generates a new temporary file name even if
- `%uSUFFIX' was already seen.
-
-`%USUFFIX'
- Substitutes the last file name generated with `%uSUFFIX',
- generating a new one if there is no such last file name. In the
- absence of any `%uSUFFIX', this is just like `%gSUFFIX', except
- they don't share the same suffix _space_, so `%g.s ... %U.s ...
- %g.s ... %U.s' would involve the generation of two distinct file
- names, one for each `%g.s' and another for each `%U.s'.
- Previously, `%U' was simply substituted with a file name chosen
- for the previous `%u', without regard to any appended suffix.
-
-`%jSUFFIX'
- Substitutes the name of the `HOST_BIT_BUCKET', if any, and if it is
- writable, and if save-temps is off; otherwise, substitute the name
- of a temporary file, just like `%u'. This temporary file is not
- meant for communication between processes, but rather as a junk
- disposal mechanism.
-
-`%|SUFFIX'
-`%mSUFFIX'
- Like `%g', except if `-pipe' is in effect. In that case `%|'
- substitutes a single dash and `%m' substitutes nothing at all.
- These are the two most common ways to instruct a program that it
- should read from standard input or write to standard output. If
- you need something more elaborate you can use an `%{pipe:`X'}'
- construct: see for example `f/lang-specs.h'.
-
-`%.SUFFIX'
- Substitutes .SUFFIX for the suffixes of a matched switch's args
- when it is subsequently output with `%*'. SUFFIX is terminated by
- the next space or %.
-
-`%w'
- Marks the argument containing or following the `%w' as the
- designated output file of this compilation. This puts the argument
- into the sequence of arguments that `%o' will substitute later.
-
-`%o'
- Substitutes the names of all the output files, with spaces
- automatically placed around them. You should write spaces around
- the `%o' as well or the results are undefined. `%o' is for use in
- the specs for running the linker. Input files whose names have no
- recognized suffix are not compiled at all, but they are included
- among the output files, so they will be linked.
-
-`%O'
- Substitutes the suffix for object files. Note that this is
- handled specially when it immediately follows `%g, %u, or %U',
- because of the need for those to form complete file names. The
- handling is such that `%O' is treated exactly as if it had already
- been substituted, except that `%g, %u, and %U' do not currently
- support additional SUFFIX characters following `%O' as they would
- following, for example, `.o'.
-
-`%p'
- Substitutes the standard macro predefinitions for the current
- target machine. Use this when running `cpp'.
-
-`%P'
- Like `%p', but puts `__' before and after the name of each
- predefined macro, except for macros that start with `__' or with
- `_L', where L is an uppercase letter. This is for ISO C.
-
-`%I'
- Substitute any of `-iprefix' (made from `GCC_EXEC_PREFIX'),
- `-isysroot' (made from `TARGET_SYSTEM_ROOT'), `-isystem' (made
- from `COMPILER_PATH' and `-B' options) and `-imultilib' as
- necessary.
-
-`%s'
- Current argument is the name of a library or startup file of some
- sort. Search for that file in a standard list of directories and
- substitute the full name found. The current working directory is
- included in the list of directories scanned.
-
-`%T'
- Current argument is the name of a linker script. Search for that
- file in the current list of directories to scan for libraries. If
- the file is located insert a `--script' option into the command
- line followed by the full path name found. If the file is not
- found then generate an error message. Note: the current working
- directory is not searched.
-
-`%eSTR'
- Print STR as an error message. STR is terminated by a newline.
- Use this when inconsistent options are detected.
-
-`%(NAME)'
- Substitute the contents of spec string NAME at this point.
-
-`%[NAME]'
- Like `%(...)' but put `__' around `-D' arguments.
-
-`%x{OPTION}'
- Accumulate an option for `%X'.
-
-`%X'
- Output the accumulated linker options specified by `-Wl' or a `%x'
- spec string.
-
-`%Y'
- Output the accumulated assembler options specified by `-Wa'.
-
-`%Z'
- Output the accumulated preprocessor options specified by `-Wp'.
-
-`%a'
- Process the `asm' spec. This is used to compute the switches to
- be passed to the assembler.
-
-`%A'
- Process the `asm_final' spec. This is a spec string for passing
- switches to an assembler post-processor, if such a program is
- needed.
-
-`%l'
- Process the `link' spec. This is the spec for computing the
- command line passed to the linker. Typically it will make use of
- the `%L %G %S %D and %E' sequences.
-
-`%D'
- Dump out a `-L' option for each directory that GCC believes might
- contain startup files. If the target supports multilibs then the
- current multilib directory will be prepended to each of these
- paths.
-
-`%L'
- Process the `lib' spec. This is a spec string for deciding which
- libraries should be included on the command line to the linker.
-
-`%G'
- Process the `libgcc' spec. This is a spec string for deciding
- which GCC support library should be included on the command line
- to the linker.
-
-`%S'
- Process the `startfile' spec. This is a spec for deciding which
- object files should be the first ones passed to the linker.
- Typically this might be a file named `crt0.o'.
-
-`%E'
- Process the `endfile' spec. This is a spec string that specifies
- the last object files that will be passed to the linker.
-
-`%C'
- Process the `cpp' spec. This is used to construct the arguments
- to be passed to the C preprocessor.
-
-`%1'
- Process the `cc1' spec. This is used to construct the options to
- be passed to the actual C compiler (`cc1').
-
-`%2'
- Process the `cc1plus' spec. This is used to construct the options
- to be passed to the actual C++ compiler (`cc1plus').
-
-`%*'
- Substitute the variable part of a matched option. See below.
- Note that each comma in the substituted string is replaced by a
- single space.
-
-`%<`S''
- Remove all occurrences of `-S' from the command line. Note--this
- command is position dependent. `%' commands in the spec string
- before this one will see `-S', `%' commands in the spec string
- after this one will not.
-
-`%:FUNCTION(ARGS)'
- Call the named function FUNCTION, passing it ARGS. ARGS is first
- processed as a nested spec string, then split into an argument
- vector in the usual fashion. The function returns a string which
- is processed as if it had appeared literally as part of the
- current spec.
-
- The following built-in spec functions are provided:
-
- ``getenv''
- The `getenv' spec function takes two arguments: an environment
- variable name and a string. If the environment variable is
- not defined, a fatal error is issued. Otherwise, the return
- value is the value of the environment variable concatenated
- with the string. For example, if `TOPDIR' is defined as
- `/path/to/top', then:
-
- %:getenv(TOPDIR /include)
-
- expands to `/path/to/top/include'.
-
- ``if-exists''
- The `if-exists' spec function takes one argument, an absolute
- pathname to a file. If the file exists, `if-exists' returns
- the pathname. Here is a small example of its usage:
-
- *startfile:
- crt0%O%s %:if-exists(crti%O%s) crtbegin%O%s
-
- ``if-exists-else''
- The `if-exists-else' spec function is similar to the
- `if-exists' spec function, except that it takes two
- arguments. The first argument is an absolute pathname to a
- file. If the file exists, `if-exists-else' returns the
- pathname. If it does not exist, it returns the second
- argument. This way, `if-exists-else' can be used to select
- one file or another, based on the existence of the first.
- Here is a small example of its usage:
-
- *startfile:
- crt0%O%s %:if-exists(crti%O%s) \
- %:if-exists-else(crtbeginT%O%s crtbegin%O%s)
-
- ``replace-outfile''
- The `replace-outfile' spec function takes two arguments. It
- looks for the first argument in the outfiles array and
- replaces it with the second argument. Here is a small
- example of its usage:
-
- %{fgnu-runtime:%:replace-outfile(-lobjc -lobjc-gnu)}
-
- ``remove-outfile''
- The `remove-outfile' spec function takes one argument. It
- looks for the first argument in the outfiles array and
- removes it. Here is a small example its usage:
-
- %:remove-outfile(-lm)
-
- ``pass-through-libs''
- The `pass-through-libs' spec function takes any number of
- arguments. It finds any `-l' options and any non-options
- ending in ".a" (which it assumes are the names of linker
- input library archive files) and returns a result containing
- all the found arguments each prepended by
- `-plugin-opt=-pass-through=' and joined by spaces. This list
- is intended to be passed to the LTO linker plugin.
-
- %:pass-through-libs(%G %L %G)
-
- ``print-asm-header''
- The `print-asm-header' function takes no arguments and simply
- prints a banner like:
-
- Assembler options
- =================
-
- Use "-Wa,OPTION" to pass "OPTION" to the assembler.
-
- It is used to separate compiler options from assembler options
- in the `--target-help' output.
-
-`%{`S'}'
- Substitutes the `-S' switch, if that switch was given to GCC. If
- that switch was not specified, this substitutes nothing. Note that
- the leading dash is omitted when specifying this option, and it is
- automatically inserted if the substitution is performed. Thus the
- spec string `%{foo}' would match the command-line option `-foo'
- and would output the command line option `-foo'.
-
-`%W{`S'}'
- Like %{`S'} but mark last argument supplied within as a file to be
- deleted on failure.
-
-`%{`S'*}'
- Substitutes all the switches specified to GCC whose names start
- with `-S', but which also take an argument. This is used for
- switches like `-o', `-D', `-I', etc. GCC considers `-o foo' as
- being one switch whose names starts with `o'. %{o*} would
- substitute this text, including the space. Thus two arguments
- would be generated.
-
-`%{`S'*&`T'*}'
- Like %{`S'*}, but preserve order of `S' and `T' options (the order
- of `S' and `T' in the spec is not significant). There can be any
- number of ampersand-separated variables; for each the wild card is
- optional. Useful for CPP as `%{D*&U*&A*}'.
-
-`%{`S':`X'}'
- Substitutes `X', if the `-S' switch was given to GCC.
-
-`%{!`S':`X'}'
- Substitutes `X', if the `-S' switch was _not_ given to GCC.
-
-`%{`S'*:`X'}'
- Substitutes `X' if one or more switches whose names start with
- `-S' are specified to GCC. Normally `X' is substituted only once,
- no matter how many such switches appeared. However, if `%*'
- appears somewhere in `X', then `X' will be substituted once for
- each matching switch, with the `%*' replaced by the part of that
- switch that matched the `*'.
-
-`%{.`S':`X'}'
- Substitutes `X', if processing a file with suffix `S'.
-
-`%{!.`S':`X'}'
- Substitutes `X', if _not_ processing a file with suffix `S'.
-
-`%{,`S':`X'}'
- Substitutes `X', if processing a file for language `S'.
-
-`%{!,`S':`X'}'
- Substitutes `X', if not processing a file for language `S'.
-
-`%{`S'|`P':`X'}'
- Substitutes `X' if either `-S' or `-P' was given to GCC. This may
- be combined with `!', `.', `,', and `*' sequences as well,
- although they have a stronger binding than the `|'. If `%*'
- appears in `X', all of the alternatives must be starred, and only
- the first matching alternative is substituted.
-
- For example, a spec string like this:
-
- %{.c:-foo} %{!.c:-bar} %{.c|d:-baz} %{!.c|d:-boggle}
-
- will output the following command-line options from the following
- input command-line options:
-
- fred.c -foo -baz
- jim.d -bar -boggle
- -d fred.c -foo -baz -boggle
- -d jim.d -bar -baz -boggle
-
-`%{S:X; T:Y; :D}'
- If `S' was given to GCC, substitutes `X'; else if `T' was given to
- GCC, substitutes `Y'; else substitutes `D'. There can be as many
- clauses as you need. This may be combined with `.', `,', `!',
- `|', and `*' as needed.
-
-`max-lipo-mem'
- When importing auxiliary modules during profile-use, check current
- memory consumption after parsing each auxiliary module. If it
- exceeds this limit (specified in kb), don't import any more
- auxiliary modules. Specifying a value of 0 means don't enforce
- this limit. This parameter is only useful when using
- `-fprofile-use' and `-fripa'.
-
-
- The conditional text `X' in a %{`S':`X'} or similar construct may
-contain other nested `%' constructs or spaces, or even newlines. They
-are processed as usual, as described above. Trailing white space in
-`X' is ignored. White space may also appear anywhere on the left side
-of the colon in these constructs, except between `.' or `*' and the
-corresponding word.
-
- The `-O', `-f', `-m', and `-W' switches are handled specifically in
-these constructs. If another value of `-O' or the negated form of a
-`-f', `-m', or `-W' switch is found later in the command line, the
-earlier switch value is ignored, except with {`S'*} where `S' is just
-one letter, which passes all matching options.
-
- The character `|' at the beginning of the predicate text is used to
-indicate that a command should be piped to the following command, but
-only if `-pipe' is specified.
-
- It is built into GCC which switches take arguments and which do not.
-(You might think it would be useful to generalize this to allow each
-compiler's spec to say which switches take arguments. But this cannot
-be done in a consistent fashion. GCC cannot even decide which input
-files have been specified without knowing which switches take arguments,
-and it must know which input files to compile in order to tell which
-compilers to run).
-
- GCC also knows implicitly that arguments starting in `-l' are to be
-treated as compiler output files, and passed to the linker in their
-proper position among the other output files.
-
-
-File: gcc.info, Node: Target Options, Next: Submodel Options, Prev: Spec Files, Up: Invoking GCC
-
-3.16 Specifying Target Machine and Compiler Version
-===================================================
-
-The usual way to run GCC is to run the executable called `gcc', or
-`MACHINE-gcc' when cross-compiling, or `MACHINE-gcc-VERSION' to run a
-version other than the one that was installed last.
-
-
-File: gcc.info, Node: Submodel Options, Next: Code Gen Options, Prev: Target Options, Up: Invoking GCC
-
-3.17 Hardware Models and Configurations
-=======================================
-
-Each target machine types can have its own special options, starting
-with `-m', to choose among various hardware models or
-configurations--for example, 68010 vs 68020, floating coprocessor or
-none. A single installed version of the compiler can compile for any
-model or configuration, according to the options specified.
-
- Some configurations of the compiler also support additional special
-options, usually for compatibility with other compilers on the same
-platform.
-
-* Menu:
-
-* ARC Options::
-* ARM Options::
-* AVR Options::
-* Blackfin Options::
-* CRIS Options::
-* CRX Options::
-* Darwin Options::
-* DEC Alpha Options::
-* DEC Alpha/VMS Options::
-* FR30 Options::
-* FRV Options::
-* GNU/Linux Options::
-* H8/300 Options::
-* HPPA Options::
-* i386 and x86-64 Options::
-* i386 and x86-64 Windows Options::
-* IA-64 Options::
-* IA-64/VMS Options::
-* LM32 Options::
-* M32C Options::
-* M32R/D Options::
-* M680x0 Options::
-* M68hc1x Options::
-* MCore Options::
-* MeP Options::
-* MicroBlaze Options::
-* MIPS Options::
-* MMIX Options::
-* MN10300 Options::
-* PDP-11 Options::
-* picoChip Options::
-* PowerPC Options::
-* RS/6000 and PowerPC Options::
-* RX Options::
-* S/390 and zSeries Options::
-* Score Options::
-* SH Options::
-* Solaris 2 Options::
-* SPARC Options::
-* SPU Options::
-* System V Options::
-* V850 Options::
-* VAX Options::
-* VxWorks Options::
-* x86-64 Options::
-* Xstormy16 Options::
-* Xtensa Options::
-* zSeries Options::
-
-
-File: gcc.info, Node: ARC Options, Next: ARM Options, Up: Submodel Options
-
-3.17.1 ARC Options
-------------------
-
-These options are defined for ARC implementations:
-
-`-EL'
- Compile code for little endian mode. This is the default.
-
-`-EB'
- Compile code for big endian mode.
-
-`-mmangle-cpu'
- Prepend the name of the CPU to all public symbol names. In
- multiple-processor systems, there are many ARC variants with
- different instruction and register set characteristics. This flag
- prevents code compiled for one CPU to be linked with code compiled
- for another. No facility exists for handling variants that are
- "almost identical". This is an all or nothing option.
-
-`-mcpu=CPU'
- Compile code for ARC variant CPU. Which variants are supported
- depend on the configuration. All variants support `-mcpu=base',
- this is the default.
-
-`-mtext=TEXT-SECTION'
-`-mdata=DATA-SECTION'
-`-mrodata=READONLY-DATA-SECTION'
- Put functions, data, and readonly data in TEXT-SECTION,
- DATA-SECTION, and READONLY-DATA-SECTION respectively by default.
- This can be overridden with the `section' attribute. *Note
- Variable Attributes::.
-
-
-
-File: gcc.info, Node: ARM Options, Next: AVR Options, Prev: ARC Options, Up: Submodel Options
-
-3.17.2 ARM Options
-------------------
-
-These `-m' options are defined for Advanced RISC Machines (ARM)
-architectures:
-
-`-mabi=NAME'
- Generate code for the specified ABI. Permissible values are:
- `apcs-gnu', `atpcs', `aapcs', `aapcs-linux' and `iwmmxt'.
-
-`-mapcs-frame'
- Generate a stack frame that is compliant with the ARM Procedure
- Call Standard for all functions, even if this is not strictly
- necessary for correct execution of the code. Specifying
- `-fomit-frame-pointer' with this option will cause the stack
- frames not to be generated for leaf functions. The default is
- `-mno-apcs-frame'.
-
-`-mapcs'
- This is a synonym for `-mapcs-frame'.
-
-`-mthumb-interwork'
- Generate code which supports calling between the ARM and Thumb
- instruction sets. Without this option the two instruction sets
- cannot be reliably used inside one program. The default is
- `-mno-thumb-interwork', since slightly larger code is generated
- when `-mthumb-interwork' is specified.
-
-`-mno-sched-prolog'
- Prevent the reordering of instructions in the function prolog, or
- the merging of those instruction with the instructions in the
- function's body. This means that all functions will start with a
- recognizable set of instructions (or in fact one of a choice from
- a small set of different function prologues), and this information
- can be used to locate the start if functions inside an executable
- piece of code. The default is `-msched-prolog'.
-
-`-mfloat-abi=NAME'
- Specifies which floating-point ABI to use. Permissible values
- are: `soft', `softfp' and `hard'.
-
- Specifying `soft' causes GCC to generate output containing library
- calls for floating-point operations. `softfp' allows the
- generation of code using hardware floating-point instructions, but
- still uses the soft-float calling conventions. `hard' allows
- generation of floating-point instructions and uses FPU-specific
- calling conventions.
-
- The default depends on the specific target configuration. Note
- that the hard-float and soft-float ABIs are not link-compatible;
- you must compile your entire program with the same ABI, and link
- with a compatible set of libraries.
-
-`-mhard-float'
- Equivalent to `-mfloat-abi=hard'.
-
-`-msoft-float'
- Equivalent to `-mfloat-abi=soft'.
-
-`-mlittle-endian'
- Generate code for a processor running in little-endian mode. This
- is the default for all standard configurations.
-
-`-mbig-endian'
- Generate code for a processor running in big-endian mode; the
- default is to compile code for a little-endian processor.
-
-`-mwords-little-endian'
- This option only applies when generating code for big-endian
- processors. Generate code for a little-endian word order but a
- big-endian byte order. That is, a byte order of the form
- `32107654'. Note: this option should only be used if you require
- compatibility with code for big-endian ARM processors generated by
- versions of the compiler prior to 2.8.
-
-`-mcpu=NAME'
- This specifies the name of the target ARM processor. GCC uses
- this name to determine what kind of instructions it can emit when
- generating assembly code. Permissible names are: `arm2', `arm250',
- `arm3', `arm6', `arm60', `arm600', `arm610', `arm620', `arm7',
- `arm7m', `arm7d', `arm7dm', `arm7di', `arm7dmi', `arm70', `arm700',
- `arm700i', `arm710', `arm710c', `arm7100', `arm720', `arm7500',
- `arm7500fe', `arm7tdmi', `arm7tdmi-s', `arm710t', `arm720t',
- `arm740t', `strongarm', `strongarm110', `strongarm1100',
- `strongarm1110', `arm8', `arm810', `arm9', `arm9e', `arm920',
- `arm920t', `arm922t', `arm946e-s', `arm966e-s', `arm968e-s',
- `arm926ej-s', `arm940t', `arm9tdmi', `arm10tdmi', `arm1020t',
- `arm1026ej-s', `arm10e', `arm1020e', `arm1022e', `arm1136j-s',
- `arm1136jf-s', `mpcore', `mpcorenovfp', `arm1156t2-s',
- `arm1156t2f-s', `arm1176jz-s', `arm1176jzf-s', `cortex-a5',
- `cortex-a8', `cortex-a9', `cortex-a15', `cortex-r4', `cortex-r4f',
- `cortex-m4', `cortex-m3', `cortex-m1', `cortex-m0', `xscale',
- `iwmmxt', `iwmmxt2', `ep9312'.
-
-`-mtune=NAME'
- This option is very similar to the `-mcpu=' option, except that
- instead of specifying the actual target processor type, and hence
- restricting which instructions can be used, it specifies that GCC
- should tune the performance of the code as if the target were of
- the type specified in this option, but still choosing the
- instructions that it will generate based on the CPU specified by a
- `-mcpu=' option. For some ARM implementations better performance
- can be obtained by using this option.
-
-`-march=NAME'
- This specifies the name of the target ARM architecture. GCC uses
- this name to determine what kind of instructions it can emit when
- generating assembly code. This option can be used in conjunction
- with or instead of the `-mcpu=' option. Permissible names are:
- `armv2', `armv2a', `armv3', `armv3m', `armv4', `armv4t', `armv5',
- `armv5t', `armv5e', `armv5te', `armv6', `armv6j', `armv6t2',
- `armv6z', `armv6zk', `armv6-m', `armv7', `armv7-a', `armv7-r',
- `armv7-m', `iwmmxt', `iwmmxt2', `ep9312'.
-
-`-mfpu=NAME'
-`-mfpe=NUMBER'
-`-mfp=NUMBER'
- This specifies what floating point hardware (or hardware
- emulation) is available on the target. Permissible names are:
- `fpa', `fpe2', `fpe3', `maverick', `vfp', `vfpv3', `vfpv3-fp16',
- `vfpv3-d16', `vfpv3-d16-fp16', `vfpv3xd', `vfpv3xd-fp16', `neon',
- `neon-fp16', `vfpv4', `vfpv4-d16', `fpv4-sp-d16' and `neon-vfpv4'.
- `-mfp' and `-mfpe' are synonyms for `-mfpu'=`fpe'NUMBER, for
- compatibility with older versions of GCC.
-
- If `-msoft-float' is specified this specifies the format of
- floating point values.
-
- If the selected floating-point hardware includes the NEON extension
- (e.g. `-mfpu'=`neon'), note that floating-point operations will
- not be used by GCC's auto-vectorization pass unless
- `-funsafe-math-optimizations' is also specified. This is because
- NEON hardware does not fully implement the IEEE 754 standard for
- floating-point arithmetic (in particular denormal values are
- treated as zero), so the use of NEON instructions may lead to a
- loss of precision.
-
-`-mfp16-format=NAME'
- Specify the format of the `__fp16' half-precision floating-point
- type. Permissible names are `none', `ieee', and `alternative';
- the default is `none', in which case the `__fp16' type is not
- defined. *Note Half-Precision::, for more information.
-
-`-mstructure-size-boundary=N'
- The size of all structures and unions will be rounded up to a
- multiple of the number of bits set by this option. Permissible
- values are 8, 32 and 64. The default value varies for different
- toolchains. For the COFF targeted toolchain the default value is
- 8. A value of 64 is only allowed if the underlying ABI supports
- it.
-
- Specifying the larger number can produce faster, more efficient
- code, but can also increase the size of the program. Different
- values are potentially incompatible. Code compiled with one value
- cannot necessarily expect to work with code or libraries compiled
- with another value, if they exchange information using structures
- or unions.
-
-`-mabort-on-noreturn'
- Generate a call to the function `abort' at the end of a `noreturn'
- function. It will be executed if the function tries to return.
-
-`-mlong-calls'
-`-mno-long-calls'
- Tells the compiler to perform function calls by first loading the
- address of the function into a register and then performing a
- subroutine call on this register. This switch is needed if the
- target function will lie outside of the 64 megabyte addressing
- range of the offset based version of subroutine call instruction.
-
- Even if this switch is enabled, not all function calls will be
- turned into long calls. The heuristic is that static functions,
- functions which have the `short-call' attribute, functions that
- are inside the scope of a `#pragma no_long_calls' directive and
- functions whose definitions have already been compiled within the
- current compilation unit, will not be turned into long calls. The
- exception to this rule is that weak function definitions,
- functions with the `long-call' attribute or the `section'
- attribute, and functions that are within the scope of a `#pragma
- long_calls' directive, will always be turned into long calls.
-
- This feature is not enabled by default. Specifying
- `-mno-long-calls' will restore the default behavior, as will
- placing the function calls within the scope of a `#pragma
- long_calls_off' directive. Note these switches have no effect on
- how the compiler generates code to handle function calls via
- function pointers.
-
-`-msingle-pic-base'
- Treat the register used for PIC addressing as read-only, rather
- than loading it in the prologue for each function. The run-time
- system is responsible for initializing this register with an
- appropriate value before execution begins.
-
-`-mpic-register=REG'
- Specify the register to be used for PIC addressing. The default
- is R10 unless stack-checking is enabled, when R9 is used.
-
-`-mcirrus-fix-invalid-insns'
- Insert NOPs into the instruction stream to in order to work around
- problems with invalid Maverick instruction combinations. This
- option is only valid if the `-mcpu=ep9312' option has been used to
- enable generation of instructions for the Cirrus Maverick floating
- point co-processor. This option is not enabled by default, since
- the problem is only present in older Maverick implementations.
- The default can be re-enabled by use of the
- `-mno-cirrus-fix-invalid-insns' switch.
-
-`-mpoke-function-name'
- Write the name of each function into the text section, directly
- preceding the function prologue. The generated code is similar to
- this:
-
- t0
- .ascii "arm_poke_function_name", 0
- .align
- t1
- .word 0xff000000 + (t1 - t0)
- arm_poke_function_name
- mov ip, sp
- stmfd sp!, {fp, ip, lr, pc}
- sub fp, ip, #4
-
- When performing a stack backtrace, code can inspect the value of
- `pc' stored at `fp + 0'. If the trace function then looks at
- location `pc - 12' and the top 8 bits are set, then we know that
- there is a function name embedded immediately preceding this
- location and has length `((pc[-3]) & 0xff000000)'.
-
-`-mthumb'
- Generate code for the Thumb instruction set. The default is to
- use the 32-bit ARM instruction set. This option automatically
- enables either 16-bit Thumb-1 or mixed 16/32-bit Thumb-2
- instructions based on the `-mcpu=NAME' and `-march=NAME' options.
- This option is not passed to the assembler. If you want to force
- assembler files to be interpreted as Thumb code, either add a
- `.thumb' directive to the source or pass the `-mthumb' option
- directly to the assembler by prefixing it with `-Wa'.
-
-`-mtpcs-frame'
- Generate a stack frame that is compliant with the Thumb Procedure
- Call Standard for all non-leaf functions. (A leaf function is one
- that does not call any other functions.) The default is
- `-mno-tpcs-frame'.
-
-`-mtpcs-leaf-frame'
- Generate a stack frame that is compliant with the Thumb Procedure
- Call Standard for all leaf functions. (A leaf function is one
- that does not call any other functions.) The default is
- `-mno-apcs-leaf-frame'.
-
-`-mcallee-super-interworking'
- Gives all externally visible functions in the file being compiled
- an ARM instruction set header which switches to Thumb mode before
- executing the rest of the function. This allows these functions
- to be called from non-interworking code. This option is not valid
- in AAPCS configurations because interworking is enabled by default.
-
-`-mcaller-super-interworking'
- Allows calls via function pointers (including virtual functions) to
- execute correctly regardless of whether the target code has been
- compiled for interworking or not. There is a small overhead in
- the cost of executing a function pointer if this option is
- enabled. This option is not valid in AAPCS configurations because
- interworking is enabled by default.
-
-`-mtp=NAME'
- Specify the access model for the thread local storage pointer.
- The valid models are `soft', which generates calls to
- `__aeabi_read_tp', `cp15', which fetches the thread pointer from
- `cp15' directly (supported in the arm6k architecture), and `auto',
- which uses the best available method for the selected processor.
- The default setting is `auto'.
-
-`-mword-relocations'
- Only generate absolute relocations on word sized values (i.e.
- R_ARM_ABS32). This is enabled by default on targets (uClinux,
- SymbianOS) where the runtime loader imposes this restriction, and
- when `-fpic' or `-fPIC' is specified.
-
-`-mfix-cortex-m3-ldrd'
- Some Cortex-M3 cores can cause data corruption when `ldrd'
- instructions with overlapping destination and base registers are
- used. This option avoids generating these instructions. This
- option is enabled by default when `-mcpu=cortex-m3' is specified.
-
-
-
-File: gcc.info, Node: AVR Options, Next: Blackfin Options, Prev: ARM Options, Up: Submodel Options
-
-3.17.3 AVR Options
-------------------
-
-These options are defined for AVR implementations:
-
-`-mmcu=MCU'
- Specify ATMEL AVR instruction set or MCU type.
-
- Instruction set avr1 is for the minimal AVR core, not supported by
- the C compiler, only for assembler programs (MCU types: at90s1200,
- attiny10, attiny11, attiny12, attiny15, attiny28).
-
- Instruction set avr2 (default) is for the classic AVR core with up
- to 8K program memory space (MCU types: at90s2313, at90s2323,
- attiny22, at90s2333, at90s2343, at90s4414, at90s4433, at90s4434,
- at90s8515, at90c8534, at90s8535).
-
- Instruction set avr3 is for the classic AVR core with up to 128K
- program memory space (MCU types: atmega103, atmega603, at43usb320,
- at76c711).
-
- Instruction set avr4 is for the enhanced AVR core with up to 8K
- program memory space (MCU types: atmega8, atmega83, atmega85).
-
- Instruction set avr5 is for the enhanced AVR core with up to 128K
- program memory space (MCU types: atmega16, atmega161, atmega163,
- atmega32, atmega323, atmega64, atmega128, at43usb355, at94k).
-
-`-mno-interrupts'
- Generated code is not compatible with hardware interrupts. Code
- size will be smaller.
-
-`-mcall-prologues'
- Functions prologues/epilogues expanded as call to appropriate
- subroutines. Code size will be smaller.
-
-`-mtiny-stack'
- Change only the low 8 bits of the stack pointer.
-
-`-mint8'
- Assume int to be 8 bit integer. This affects the sizes of all
- types: A char will be 1 byte, an int will be 1 byte, a long will
- be 2 bytes and long long will be 4 bytes. Please note that this
- option does not comply to the C standards, but it will provide you
- with smaller code size.
-
-3.17.3.1 `EIND' and Devices with more than 128k Bytes of Flash
-..............................................................
-
-Pointers in the implementation are 16 bits wide. The address of a
-function or label is represented as word address so that indirect jumps
-and calls can address any code address in the range of 64k words.
-
- In order to faciliate indirect jump on devices with more than 128k
-bytes of program memory space, there is a special function register
-called `EIND' that serves as most significant part of the target address
-when `EICALL' or `EIJMP' instructions are used.
-
- Indirect jumps and calls on these devices are handled as follows and
-are subject to some limitations:
-
- * The compiler never sets `EIND'.
-
- * The startup code from libgcc never sets `EIND'. Notice that
- startup code is a blend of code from libgcc and avr-libc. For the
- impact of avr-libc on `EIND', see the
- avr-libc user manual (http://nongnu.org/avr-libc/user-manual).
-
- * The compiler uses `EIND' implicitely in `EICALL'/`EIJMP'
- instructions or might read `EIND' directly.
-
- * The compiler assumes that `EIND' never changes during the startup
- code or run of the application. In particular, `EIND' is not
- saved/restored in function or interrupt service routine
- prologue/epilogue.
-
- * It is legitimate for user-specific startup code to set up `EIND'
- early, for example by means of initialization code located in
- section `.init3', and thus prior to general startup code that
- initializes RAM and calls constructors.
-
- * For indirect calls to functions and computed goto, the linker will
- generate _stubs_. Stubs are jump pads sometimes also called
- _trampolines_. Thus, the indirect call/jump will jump to such a
- stub. The stub contains a direct jump to the desired address.
-
- * Stubs will be generated automatically by the linker if the
- following two conditions are met:
- - The address of a label is taken by means of the `gs' modifier
- (short for _generate stubs_) like so:
- LDI r24, lo8(gs(FUNC))
- LDI r25, hi8(gs(FUNC))
-
- - The final location of that label is in a code segment
- _outside_ the segment where the stubs are located.
-
- * The compiler will emit such `gs' modifiers for code labels in the
- following situations:
- - Taking address of a function or code label.
-
- - Computed goto.
-
- - If prologue-save function is used, see `-mcall-prologues'
- command line option.
-
- - Switch/case dispatch tables. If you do not want such dispatch
- tables you can specify the `-fno-jump-tables' command line
- option.
-
- - C and C++ constructors/destructors called during
- startup/shutdown.
-
- - If the tools hit a `gs()' modifier explained above.
-
- * The default linker script is arranged for code with `EIND = 0'.
- If code is supposed to work for a setup with `EIND != 0', a custom
- linker script has to be used in order to place the sections whose
- name start with `.trampolines' into the segment where `EIND'
- points to.
-
- * Jumping to non-symbolic addresses like so is _not_ supported:
-
- int main (void)
- {
- /* Call function at word address 0x2 */
- return ((int(*)(void)) 0x2)();
- }
-
- Instead, a stub has to be set up:
-
- int main (void)
- {
- extern int func_4 (void);
-
- /* Call function at byte address 0x4 */
- return func_4();
- }
-
- and the application be linked with `-Wl,--defsym,func_4=0x4'.
- Alternatively, `func_4' can be defined in the linker script.
-
-
-File: gcc.info, Node: Blackfin Options, Next: CRIS Options, Prev: AVR Options, Up: Submodel Options
-
-3.17.4 Blackfin Options
------------------------
-
-`-mcpu=CPU[-SIREVISION]'
- Specifies the name of the target Blackfin processor. Currently,
- CPU can be one of `bf512', `bf514', `bf516', `bf518', `bf522',
- `bf523', `bf524', `bf525', `bf526', `bf527', `bf531', `bf532',
- `bf533', `bf534', `bf536', `bf537', `bf538', `bf539', `bf542',
- `bf544', `bf547', `bf548', `bf549', `bf542m', `bf544m', `bf547m',
- `bf548m', `bf549m', `bf561'. The optional SIREVISION specifies
- the silicon revision of the target Blackfin processor. Any
- workarounds available for the targeted silicon revision will be
- enabled. If SIREVISION is `none', no workarounds are enabled. If
- SIREVISION is `any', all workarounds for the targeted processor
- will be enabled. The `__SILICON_REVISION__' macro is defined to
- two hexadecimal digits representing the major and minor numbers in
- the silicon revision. If SIREVISION is `none', the
- `__SILICON_REVISION__' is not defined. If SIREVISION is `any', the
- `__SILICON_REVISION__' is defined to be `0xffff'. If this
- optional SIREVISION is not used, GCC assumes the latest known
- silicon revision of the targeted Blackfin processor.
-
- Support for `bf561' is incomplete. For `bf561', Only the
- processor macro is defined. Without this option, `bf532' is used
- as the processor by default. The corresponding predefined
- processor macros for CPU is to be defined. And for `bfin-elf'
- toolchain, this causes the hardware BSP provided by libgloss to be
- linked in if `-msim' is not given.
-
-`-msim'
- Specifies that the program will be run on the simulator. This
- causes the simulator BSP provided by libgloss to be linked in.
- This option has effect only for `bfin-elf' toolchain. Certain
- other options, such as `-mid-shared-library' and `-mfdpic', imply
- `-msim'.
-
-`-momit-leaf-frame-pointer'
- Don't keep the frame pointer in a register for leaf functions.
- This avoids the instructions to save, set up and restore frame
- pointers and makes an extra register available in leaf functions.
- The option `-fomit-frame-pointer' removes the frame pointer for
- all functions which might make debugging harder.
-
-`-mspecld-anomaly'
- When enabled, the compiler will ensure that the generated code
- does not contain speculative loads after jump instructions. If
- this option is used, `__WORKAROUND_SPECULATIVE_LOADS' is defined.
-
-`-mno-specld-anomaly'
- Don't generate extra code to prevent speculative loads from
- occurring.
-
-`-mcsync-anomaly'
- When enabled, the compiler will ensure that the generated code
- does not contain CSYNC or SSYNC instructions too soon after
- conditional branches. If this option is used,
- `__WORKAROUND_SPECULATIVE_SYNCS' is defined.
-
-`-mno-csync-anomaly'
- Don't generate extra code to prevent CSYNC or SSYNC instructions
- from occurring too soon after a conditional branch.
-
-`-mlow-64k'
- When enabled, the compiler is free to take advantage of the
- knowledge that the entire program fits into the low 64k of memory.
-
-`-mno-low-64k'
- Assume that the program is arbitrarily large. This is the default.
-
-`-mstack-check-l1'
- Do stack checking using information placed into L1 scratchpad
- memory by the uClinux kernel.
-
-`-mid-shared-library'
- Generate code that supports shared libraries via the library ID
- method. This allows for execute in place and shared libraries in
- an environment without virtual memory management. This option
- implies `-fPIC'. With a `bfin-elf' target, this option implies
- `-msim'.
-
-`-mno-id-shared-library'
- Generate code that doesn't assume ID based shared libraries are
- being used. This is the default.
-
-`-mleaf-id-shared-library'
- Generate code that supports shared libraries via the library ID
- method, but assumes that this library or executable won't link
- against any other ID shared libraries. That allows the compiler
- to use faster code for jumps and calls.
-
-`-mno-leaf-id-shared-library'
- Do not assume that the code being compiled won't link against any
- ID shared libraries. Slower code will be generated for jump and
- call insns.
-
-`-mshared-library-id=n'
- Specified the identification number of the ID based shared library
- being compiled. Specifying a value of 0 will generate more
- compact code, specifying other values will force the allocation of
- that number to the current library but is no more space or time
- efficient than omitting this option.
-
-`-msep-data'
- Generate code that allows the data segment to be located in a
- different area of memory from the text segment. This allows for
- execute in place in an environment without virtual memory
- management by eliminating relocations against the text section.
-
-`-mno-sep-data'
- Generate code that assumes that the data segment follows the text
- segment. This is the default.
-
-`-mlong-calls'
-`-mno-long-calls'
- Tells the compiler to perform function calls by first loading the
- address of the function into a register and then performing a
- subroutine call on this register. This switch is needed if the
- target function will lie outside of the 24 bit addressing range of
- the offset based version of subroutine call instruction.
-
- This feature is not enabled by default. Specifying
- `-mno-long-calls' will restore the default behavior. Note these
- switches have no effect on how the compiler generates code to
- handle function calls via function pointers.
-
-`-mfast-fp'
- Link with the fast floating-point library. This library relaxes
- some of the IEEE floating-point standard's rules for checking
- inputs against Not-a-Number (NAN), in the interest of performance.
-
-`-minline-plt'
- Enable inlining of PLT entries in function calls to functions that
- are not known to bind locally. It has no effect without `-mfdpic'.
-
-`-mmulticore'
- Build standalone application for multicore Blackfin processor.
- Proper start files and link scripts will be used to support
- multicore. This option defines `__BFIN_MULTICORE'. It can only be
- used with `-mcpu=bf561[-SIREVISION]'. It can be used with
- `-mcorea' or `-mcoreb'. If it's used without `-mcorea' or
- `-mcoreb', single application/dual core programming model is used.
- In this model, the main function of Core B should be named as
- coreb_main. If it's used with `-mcorea' or `-mcoreb', one
- application per core programming model is used. If this option is
- not used, single core application programming model is used.
-
-`-mcorea'
- Build standalone application for Core A of BF561 when using one
- application per core programming model. Proper start files and
- link scripts will be used to support Core A. This option defines
- `__BFIN_COREA'. It must be used with `-mmulticore'.
-
-`-mcoreb'
- Build standalone application for Core B of BF561 when using one
- application per core programming model. Proper start files and
- link scripts will be used to support Core B. This option defines
- `__BFIN_COREB'. When this option is used, coreb_main should be
- used instead of main. It must be used with `-mmulticore'.
-
-`-msdram'
- Build standalone application for SDRAM. Proper start files and
- link scripts will be used to put the application into SDRAM.
- Loader should initialize SDRAM before loading the application into
- SDRAM. This option defines `__BFIN_SDRAM'.
-
-`-micplb'
- Assume that ICPLBs are enabled at runtime. This has an effect on
- certain anomaly workarounds. For Linux targets, the default is to
- assume ICPLBs are enabled; for standalone applications the default
- is off.
-
-
-File: gcc.info, Node: CRIS Options, Next: CRX Options, Prev: Blackfin Options, Up: Submodel Options
-
-3.17.5 CRIS Options
--------------------
-
-These options are defined specifically for the CRIS ports.
-
-`-march=ARCHITECTURE-TYPE'
-`-mcpu=ARCHITECTURE-TYPE'
- Generate code for the specified architecture. The choices for
- ARCHITECTURE-TYPE are `v3', `v8' and `v10' for respectively
- ETRAX 4, ETRAX 100, and ETRAX 100 LX. Default is `v0' except for
- cris-axis-linux-gnu, where the default is `v10'.
-
-`-mtune=ARCHITECTURE-TYPE'
- Tune to ARCHITECTURE-TYPE everything applicable about the generated
- code, except for the ABI and the set of available instructions.
- The choices for ARCHITECTURE-TYPE are the same as for
- `-march=ARCHITECTURE-TYPE'.
-
-`-mmax-stack-frame=N'
- Warn when the stack frame of a function exceeds N bytes.
-
-`-metrax4'
-`-metrax100'
- The options `-metrax4' and `-metrax100' are synonyms for
- `-march=v3' and `-march=v8' respectively.
-
-`-mmul-bug-workaround'
-`-mno-mul-bug-workaround'
- Work around a bug in the `muls' and `mulu' instructions for CPU
- models where it applies. This option is active by default.
-
-`-mpdebug'
- Enable CRIS-specific verbose debug-related information in the
- assembly code. This option also has the effect to turn off the
- `#NO_APP' formatted-code indicator to the assembler at the
- beginning of the assembly file.
-
-`-mcc-init'
- Do not use condition-code results from previous instruction;
- always emit compare and test instructions before use of condition
- codes.
-
-`-mno-side-effects'
- Do not emit instructions with side-effects in addressing modes
- other than post-increment.
-
-`-mstack-align'
-`-mno-stack-align'
-`-mdata-align'
-`-mno-data-align'
-`-mconst-align'
-`-mno-const-align'
- These options (no-options) arranges (eliminate arrangements) for
- the stack-frame, individual data and constants to be aligned for
- the maximum single data access size for the chosen CPU model. The
- default is to arrange for 32-bit alignment. ABI details such as
- structure layout are not affected by these options.
-
-`-m32-bit'
-`-m16-bit'
-`-m8-bit'
- Similar to the stack- data- and const-align options above, these
- options arrange for stack-frame, writable data and constants to
- all be 32-bit, 16-bit or 8-bit aligned. The default is 32-bit
- alignment.
-
-`-mno-prologue-epilogue'
-`-mprologue-epilogue'
- With `-mno-prologue-epilogue', the normal function prologue and
- epilogue that sets up the stack-frame are omitted and no return
- instructions or return sequences are generated in the code. Use
- this option only together with visual inspection of the compiled
- code: no warnings or errors are generated when call-saved
- registers must be saved, or storage for local variable needs to be
- allocated.
-
-`-mno-gotplt'
-`-mgotplt'
- With `-fpic' and `-fPIC', don't generate (do generate) instruction
- sequences that load addresses for functions from the PLT part of
- the GOT rather than (traditional on other architectures) calls to
- the PLT. The default is `-mgotplt'.
-
-`-melf'
- Legacy no-op option only recognized with the cris-axis-elf and
- cris-axis-linux-gnu targets.
-
-`-mlinux'
- Legacy no-op option only recognized with the cris-axis-linux-gnu
- target.
-
-`-sim'
- This option, recognized for the cris-axis-elf arranges to link
- with input-output functions from a simulator library. Code,
- initialized data and zero-initialized data are allocated
- consecutively.
-
-`-sim2'
- Like `-sim', but pass linker options to locate initialized data at
- 0x40000000 and zero-initialized data at 0x80000000.
-
-
-File: gcc.info, Node: CRX Options, Next: Darwin Options, Prev: CRIS Options, Up: Submodel Options
-
-3.17.6 CRX Options
-------------------
-
-These options are defined specifically for the CRX ports.
-
-`-mmac'
- Enable the use of multiply-accumulate instructions. Disabled by
- default.
-
-`-mpush-args'
- Push instructions will be used to pass outgoing arguments when
- functions are called. Enabled by default.
-
-
-File: gcc.info, Node: Darwin Options, Next: DEC Alpha Options, Prev: CRX Options, Up: Submodel Options
-
-3.17.7 Darwin Options
----------------------
-
-These options are defined for all architectures running the Darwin
-operating system.
-
- FSF GCC on Darwin does not create "fat" object files; it will create
-an object file for the single architecture that it was built to target.
-Apple's GCC on Darwin does create "fat" files if multiple `-arch'
-options are used; it does so by running the compiler or linker multiple
-times and joining the results together with `lipo'.
-
- The subtype of the file created (like `ppc7400' or `ppc970' or `i686')
-is determined by the flags that specify the ISA that GCC is targetting,
-like `-mcpu' or `-march'. The `-force_cpusubtype_ALL' option can be
-used to override this.
-
- The Darwin tools vary in their behavior when presented with an ISA
-mismatch. The assembler, `as', will only permit instructions to be
-used that are valid for the subtype of the file it is generating, so
-you cannot put 64-bit instructions in a `ppc750' object file. The
-linker for shared libraries, `/usr/bin/libtool', will fail and print an
-error if asked to create a shared library with a less restrictive
-subtype than its input files (for instance, trying to put a `ppc970'
-object file in a `ppc7400' library). The linker for executables, `ld',
-will quietly give the executable the most restrictive subtype of any of
-its input files.
-
-`-FDIR'
- Add the framework directory DIR to the head of the list of
- directories to be searched for header files. These directories are
- interleaved with those specified by `-I' options and are scanned
- in a left-to-right order.
-
- A framework directory is a directory with frameworks in it. A
- framework is a directory with a `"Headers"' and/or
- `"PrivateHeaders"' directory contained directly in it that ends in
- `".framework"'. The name of a framework is the name of this
- directory excluding the `".framework"'. Headers associated with
- the framework are found in one of those two directories, with
- `"Headers"' being searched first. A subframework is a framework
- directory that is in a framework's `"Frameworks"' directory.
- Includes of subframework headers can only appear in a header of a
- framework that contains the subframework, or in a sibling
- subframework header. Two subframeworks are siblings if they occur
- in the same framework. A subframework should not have the same
- name as a framework, a warning will be issued if this is violated.
- Currently a subframework cannot have subframeworks, in the future,
- the mechanism may be extended to support this. The standard
- frameworks can be found in `"/System/Library/Frameworks"' and
- `"/Library/Frameworks"'. An example include looks like `#include
- <Framework/header.h>', where `Framework' denotes the name of the
- framework and header.h is found in the `"PrivateHeaders"' or
- `"Headers"' directory.
-
-`-iframeworkDIR'
- Like `-F' except the directory is a treated as a system directory.
- The main difference between this `-iframework' and `-F' is that
- with `-iframework' the compiler does not warn about constructs
- contained within header files found via DIR. This option is valid
- only for the C family of languages.
-
-`-gused'
- Emit debugging information for symbols that are used. For STABS
- debugging format, this enables `-feliminate-unused-debug-symbols'.
- This is by default ON.
-
-`-gfull'
- Emit debugging information for all symbols and types.
-
-`-mmacosx-version-min=VERSION'
- The earliest version of MacOS X that this executable will run on
- is VERSION. Typical values of VERSION include `10.1', `10.2', and
- `10.3.9'.
-
- If the compiler was built to use the system's headers by default,
- then the default for this option is the system version on which the
- compiler is running, otherwise the default is to make choices which
- are compatible with as many systems and code bases as possible.
-
-`-mkernel'
- Enable kernel development mode. The `-mkernel' option sets
- `-static', `-fno-common', `-fno-cxa-atexit', `-fno-exceptions',
- `-fno-non-call-exceptions', `-fapple-kext', `-fno-weak' and
- `-fno-rtti' where applicable. This mode also sets `-mno-altivec',
- `-msoft-float', `-fno-builtin' and `-mlong-branch' for PowerPC
- targets.
-
-`-mone-byte-bool'
- Override the defaults for `bool' so that `sizeof(bool)==1'. By
- default `sizeof(bool)' is `4' when compiling for Darwin/PowerPC
- and `1' when compiling for Darwin/x86, so this option has no
- effect on x86.
-
- *Warning:* The `-mone-byte-bool' switch causes GCC to generate
- code that is not binary compatible with code generated without
- that switch. Using this switch may require recompiling all other
- modules in a program, including system libraries. Use this switch
- to conform to a non-default data model.
-
-`-mfix-and-continue'
-`-ffix-and-continue'
-`-findirect-data'
- Generate code suitable for fast turn around development. Needed to
- enable gdb to dynamically load `.o' files into already running
- programs. `-findirect-data' and `-ffix-and-continue' are provided
- for backwards compatibility.
-
-`-all_load'
- Loads all members of static archive libraries. See man ld(1) for
- more information.
-
-`-arch_errors_fatal'
- Cause the errors having to do with files that have the wrong
- architecture to be fatal.
-
-`-bind_at_load'
- Causes the output file to be marked such that the dynamic linker
- will bind all undefined references when the file is loaded or
- launched.
-
-`-bundle'
- Produce a Mach-o bundle format file. See man ld(1) for more
- information.
-
-`-bundle_loader EXECUTABLE'
- This option specifies the EXECUTABLE that will be loading the build
- output file being linked. See man ld(1) for more information.
-
-`-dynamiclib'
- When passed this option, GCC will produce a dynamic library
- instead of an executable when linking, using the Darwin `libtool'
- command.
-
-`-force_cpusubtype_ALL'
- This causes GCC's output file to have the ALL subtype, instead of
- one controlled by the `-mcpu' or `-march' option.
-
-`-allowable_client CLIENT_NAME'
-`-client_name'
-`-compatibility_version'
-`-current_version'
-`-dead_strip'
-`-dependency-file'
-`-dylib_file'
-`-dylinker_install_name'
-`-dynamic'
-`-exported_symbols_list'
-`-filelist'
-`-flat_namespace'
-`-force_flat_namespace'
-`-headerpad_max_install_names'
-`-image_base'
-`-init'
-`-install_name'
-`-keep_private_externs'
-`-multi_module'
-`-multiply_defined'
-`-multiply_defined_unused'
-`-noall_load'
-`-no_dead_strip_inits_and_terms'
-`-nofixprebinding'
-`-nomultidefs'
-`-noprebind'
-`-noseglinkedit'
-`-pagezero_size'
-`-prebind'
-`-prebind_all_twolevel_modules'
-`-private_bundle'
-`-read_only_relocs'
-`-sectalign'
-`-sectobjectsymbols'
-`-whyload'
-`-seg1addr'
-`-sectcreate'
-`-sectobjectsymbols'
-`-sectorder'
-`-segaddr'
-`-segs_read_only_addr'
-`-segs_read_write_addr'
-`-seg_addr_table'
-`-seg_addr_table_filename'
-`-seglinkedit'
-`-segprot'
-`-segs_read_only_addr'
-`-segs_read_write_addr'
-`-single_module'
-`-static'
-`-sub_library'
-`-sub_umbrella'
-`-twolevel_namespace'
-`-umbrella'
-`-undefined'
-`-unexported_symbols_list'
-`-weak_reference_mismatches'
-`-whatsloaded'
- These options are passed to the Darwin linker. The Darwin linker
- man page describes them in detail.
-
-
-File: gcc.info, Node: DEC Alpha Options, Next: DEC Alpha/VMS Options, Prev: Darwin Options, Up: Submodel Options
-
-3.17.8 DEC Alpha Options
-------------------------
-
-These `-m' options are defined for the DEC Alpha implementations:
-
-`-mno-soft-float'
-`-msoft-float'
- Use (do not use) the hardware floating-point instructions for
- floating-point operations. When `-msoft-float' is specified,
- functions in `libgcc.a' will be used to perform floating-point
- operations. Unless they are replaced by routines that emulate the
- floating-point operations, or compiled in such a way as to call
- such emulations routines, these routines will issue floating-point
- operations. If you are compiling for an Alpha without
- floating-point operations, you must ensure that the library is
- built so as not to call them.
-
- Note that Alpha implementations without floating-point operations
- are required to have floating-point registers.
-
-`-mfp-reg'
-`-mno-fp-regs'
- Generate code that uses (does not use) the floating-point register
- set. `-mno-fp-regs' implies `-msoft-float'. If the floating-point
- register set is not used, floating point operands are passed in
- integer registers as if they were integers and floating-point
- results are passed in `$0' instead of `$f0'. This is a
- non-standard calling sequence, so any function with a
- floating-point argument or return value called by code compiled
- with `-mno-fp-regs' must also be compiled with that option.
-
- A typical use of this option is building a kernel that does not
- use, and hence need not save and restore, any floating-point
- registers.
-
-`-mieee'
- The Alpha architecture implements floating-point hardware
- optimized for maximum performance. It is mostly compliant with
- the IEEE floating point standard. However, for full compliance,
- software assistance is required. This option generates code fully
- IEEE compliant code _except_ that the INEXACT-FLAG is not
- maintained (see below). If this option is turned on, the
- preprocessor macro `_IEEE_FP' is defined during compilation. The
- resulting code is less efficient but is able to correctly support
- denormalized numbers and exceptional IEEE values such as
- not-a-number and plus/minus infinity. Other Alpha compilers call
- this option `-ieee_with_no_inexact'.
-
-`-mieee-with-inexact'
- This is like `-mieee' except the generated code also maintains the
- IEEE INEXACT-FLAG. Turning on this option causes the generated
- code to implement fully-compliant IEEE math. In addition to
- `_IEEE_FP', `_IEEE_FP_EXACT' is defined as a preprocessor macro.
- On some Alpha implementations the resulting code may execute
- significantly slower than the code generated by default. Since
- there is very little code that depends on the INEXACT-FLAG, you
- should normally not specify this option. Other Alpha compilers
- call this option `-ieee_with_inexact'.
-
-`-mfp-trap-mode=TRAP-MODE'
- This option controls what floating-point related traps are enabled.
- Other Alpha compilers call this option `-fptm TRAP-MODE'. The
- trap mode can be set to one of four values:
-
- `n'
- This is the default (normal) setting. The only traps that
- are enabled are the ones that cannot be disabled in software
- (e.g., division by zero trap).
-
- `u'
- In addition to the traps enabled by `n', underflow traps are
- enabled as well.
-
- `su'
- Like `u', but the instructions are marked to be safe for
- software completion (see Alpha architecture manual for
- details).
-
- `sui'
- Like `su', but inexact traps are enabled as well.
-
-`-mfp-rounding-mode=ROUNDING-MODE'
- Selects the IEEE rounding mode. Other Alpha compilers call this
- option `-fprm ROUNDING-MODE'. The ROUNDING-MODE can be one of:
-
- `n'
- Normal IEEE rounding mode. Floating point numbers are
- rounded towards the nearest machine number or towards the
- even machine number in case of a tie.
-
- `m'
- Round towards minus infinity.
-
- `c'
- Chopped rounding mode. Floating point numbers are rounded
- towards zero.
-
- `d'
- Dynamic rounding mode. A field in the floating point control
- register (FPCR, see Alpha architecture reference manual)
- controls the rounding mode in effect. The C library
- initializes this register for rounding towards plus infinity.
- Thus, unless your program modifies the FPCR, `d' corresponds
- to round towards plus infinity.
-
-`-mtrap-precision=TRAP-PRECISION'
- In the Alpha architecture, floating point traps are imprecise.
- This means without software assistance it is impossible to recover
- from a floating trap and program execution normally needs to be
- terminated. GCC can generate code that can assist operating
- system trap handlers in determining the exact location that caused
- a floating point trap. Depending on the requirements of an
- application, different levels of precisions can be selected:
-
- `p'
- Program precision. This option is the default and means a
- trap handler can only identify which program caused a
- floating point exception.
-
- `f'
- Function precision. The trap handler can determine the
- function that caused a floating point exception.
-
- `i'
- Instruction precision. The trap handler can determine the
- exact instruction that caused a floating point exception.
-
- Other Alpha compilers provide the equivalent options called
- `-scope_safe' and `-resumption_safe'.
-
-`-mieee-conformant'
- This option marks the generated code as IEEE conformant. You must
- not use this option unless you also specify `-mtrap-precision=i'
- and either `-mfp-trap-mode=su' or `-mfp-trap-mode=sui'. Its only
- effect is to emit the line `.eflag 48' in the function prologue of
- the generated assembly file. Under DEC Unix, this has the effect
- that IEEE-conformant math library routines will be linked in.
-
-`-mbuild-constants'
- Normally GCC examines a 32- or 64-bit integer constant to see if
- it can construct it from smaller constants in two or three
- instructions. If it cannot, it will output the constant as a
- literal and generate code to load it from the data segment at
- runtime.
-
- Use this option to require GCC to construct _all_ integer constants
- using code, even if it takes more instructions (the maximum is
- six).
-
- You would typically use this option to build a shared library
- dynamic loader. Itself a shared library, it must relocate itself
- in memory before it can find the variables and constants in its
- own data segment.
-
-`-malpha-as'
-`-mgas'
- Select whether to generate code to be assembled by the
- vendor-supplied assembler (`-malpha-as') or by the GNU assembler
- `-mgas'.
-
-`-mbwx'
-`-mno-bwx'
-`-mcix'
-`-mno-cix'
-`-mfix'
-`-mno-fix'
-`-mmax'
-`-mno-max'
- Indicate whether GCC should generate code to use the optional BWX,
- CIX, FIX and MAX instruction sets. The default is to use the
- instruction sets supported by the CPU type specified via `-mcpu='
- option or that of the CPU on which GCC was built if none was
- specified.
-
-`-mfloat-vax'
-`-mfloat-ieee'
- Generate code that uses (does not use) VAX F and G floating point
- arithmetic instead of IEEE single and double precision.
-
-`-mexplicit-relocs'
-`-mno-explicit-relocs'
- Older Alpha assemblers provided no way to generate symbol
- relocations except via assembler macros. Use of these macros does
- not allow optimal instruction scheduling. GNU binutils as of
- version 2.12 supports a new syntax that allows the compiler to
- explicitly mark which relocations should apply to which
- instructions. This option is mostly useful for debugging, as GCC
- detects the capabilities of the assembler when it is built and
- sets the default accordingly.
-
-`-msmall-data'
-`-mlarge-data'
- When `-mexplicit-relocs' is in effect, static data is accessed via
- "gp-relative" relocations. When `-msmall-data' is used, objects 8
- bytes long or smaller are placed in a "small data area" (the
- `.sdata' and `.sbss' sections) and are accessed via 16-bit
- relocations off of the `$gp' register. This limits the size of
- the small data area to 64KB, but allows the variables to be
- directly accessed via a single instruction.
-
- The default is `-mlarge-data'. With this option the data area is
- limited to just below 2GB. Programs that require more than 2GB of
- data must use `malloc' or `mmap' to allocate the data in the heap
- instead of in the program's data segment.
-
- When generating code for shared libraries, `-fpic' implies
- `-msmall-data' and `-fPIC' implies `-mlarge-data'.
-
-`-msmall-text'
-`-mlarge-text'
- When `-msmall-text' is used, the compiler assumes that the code of
- the entire program (or shared library) fits in 4MB, and is thus
- reachable with a branch instruction. When `-msmall-data' is used,
- the compiler can assume that all local symbols share the same
- `$gp' value, and thus reduce the number of instructions required
- for a function call from 4 to 1.
-
- The default is `-mlarge-text'.
-
-`-mcpu=CPU_TYPE'
- Set the instruction set and instruction scheduling parameters for
- machine type CPU_TYPE. You can specify either the `EV' style name
- or the corresponding chip number. GCC supports scheduling
- parameters for the EV4, EV5 and EV6 family of processors and will
- choose the default values for the instruction set from the
- processor you specify. If you do not specify a processor type,
- GCC will default to the processor on which the compiler was built.
-
- Supported values for CPU_TYPE are
-
- `ev4'
- `ev45'
- `21064'
- Schedules as an EV4 and has no instruction set extensions.
-
- `ev5'
- `21164'
- Schedules as an EV5 and has no instruction set extensions.
-
- `ev56'
- `21164a'
- Schedules as an EV5 and supports the BWX extension.
-
- `pca56'
- `21164pc'
- `21164PC'
- Schedules as an EV5 and supports the BWX and MAX extensions.
-
- `ev6'
- `21264'
- Schedules as an EV6 and supports the BWX, FIX, and MAX
- extensions.
-
- `ev67'
- `21264a'
- Schedules as an EV6 and supports the BWX, CIX, FIX, and MAX
- extensions.
-
- Native Linux/GNU toolchains also support the value `native', which
- selects the best architecture option for the host processor.
- `-mcpu=native' has no effect if GCC does not recognize the
- processor.
-
-`-mtune=CPU_TYPE'
- Set only the instruction scheduling parameters for machine type
- CPU_TYPE. The instruction set is not changed.
-
- Native Linux/GNU toolchains also support the value `native', which
- selects the best architecture option for the host processor.
- `-mtune=native' has no effect if GCC does not recognize the
- processor.
-
-`-mmemory-latency=TIME'
- Sets the latency the scheduler should assume for typical memory
- references as seen by the application. This number is highly
- dependent on the memory access patterns used by the application
- and the size of the external cache on the machine.
-
- Valid options for TIME are
-
- `NUMBER'
- A decimal number representing clock cycles.
-
- `L1'
- `L2'
- `L3'
- `main'
- The compiler contains estimates of the number of clock cycles
- for "typical" EV4 & EV5 hardware for the Level 1, 2 & 3 caches
- (also called Dcache, Scache, and Bcache), as well as to main
- memory. Note that L3 is only valid for EV5.
-
-
-
-File: gcc.info, Node: DEC Alpha/VMS Options, Next: FR30 Options, Prev: DEC Alpha Options, Up: Submodel Options
-
-3.17.9 DEC Alpha/VMS Options
-----------------------------
-
-These `-m' options are defined for the DEC Alpha/VMS implementations:
-
-`-mvms-return-codes'
- Return VMS condition codes from main. The default is to return
- POSIX style condition (e.g. error) codes.
-
-`-mdebug-main=PREFIX'
- Flag the first routine whose name starts with PREFIX as the main
- routine for the debugger.
-
-`-mmalloc64'
- Default to 64bit memory allocation routines.
-
-
-File: gcc.info, Node: FR30 Options, Next: FRV Options, Prev: DEC Alpha/VMS Options, Up: Submodel Options
-
-3.17.10 FR30 Options
---------------------
-
-These options are defined specifically for the FR30 port.
-
-`-msmall-model'
- Use the small address space model. This can produce smaller code,
- but it does assume that all symbolic values and addresses will fit
- into a 20-bit range.
-
-`-mno-lsim'
- Assume that run-time support has been provided and so there is no
- need to include the simulator library (`libsim.a') on the linker
- command line.
-
-
-
-File: gcc.info, Node: FRV Options, Next: GNU/Linux Options, Prev: FR30 Options, Up: Submodel Options
-
-3.17.11 FRV Options
--------------------
-
-`-mgpr-32'
- Only use the first 32 general purpose registers.
-
-`-mgpr-64'
- Use all 64 general purpose registers.
-
-`-mfpr-32'
- Use only the first 32 floating point registers.
-
-`-mfpr-64'
- Use all 64 floating point registers
-
-`-mhard-float'
- Use hardware instructions for floating point operations.
-
-`-msoft-float'
- Use library routines for floating point operations.
-
-`-malloc-cc'
- Dynamically allocate condition code registers.
-
-`-mfixed-cc'
- Do not try to dynamically allocate condition code registers, only
- use `icc0' and `fcc0'.
-
-`-mdword'
- Change ABI to use double word insns.
-
-`-mno-dword'
- Do not use double word instructions.
-
-`-mdouble'
- Use floating point double instructions.
-
-`-mno-double'
- Do not use floating point double instructions.
-
-`-mmedia'
- Use media instructions.
-
-`-mno-media'
- Do not use media instructions.
-
-`-mmuladd'
- Use multiply and add/subtract instructions.
-
-`-mno-muladd'
- Do not use multiply and add/subtract instructions.
-
-`-mfdpic'
- Select the FDPIC ABI, that uses function descriptors to represent
- pointers to functions. Without any PIC/PIE-related options, it
- implies `-fPIE'. With `-fpic' or `-fpie', it assumes GOT entries
- and small data are within a 12-bit range from the GOT base
- address; with `-fPIC' or `-fPIE', GOT offsets are computed with 32
- bits. With a `bfin-elf' target, this option implies `-msim'.
-
-`-minline-plt'
- Enable inlining of PLT entries in function calls to functions that
- are not known to bind locally. It has no effect without `-mfdpic'.
- It's enabled by default if optimizing for speed and compiling for
- shared libraries (i.e., `-fPIC' or `-fpic'), or when an
- optimization option such as `-O3' or above is present in the
- command line.
-
-`-mTLS'
- Assume a large TLS segment when generating thread-local code.
-
-`-mtls'
- Do not assume a large TLS segment when generating thread-local
- code.
-
-`-mgprel-ro'
- Enable the use of `GPREL' relocations in the FDPIC ABI for data
- that is known to be in read-only sections. It's enabled by
- default, except for `-fpic' or `-fpie': even though it may help
- make the global offset table smaller, it trades 1 instruction for
- 4. With `-fPIC' or `-fPIE', it trades 3 instructions for 4, one
- of which may be shared by multiple symbols, and it avoids the need
- for a GOT entry for the referenced symbol, so it's more likely to
- be a win. If it is not, `-mno-gprel-ro' can be used to disable it.
-
-`-multilib-library-pic'
- Link with the (library, not FD) pic libraries. It's implied by
- `-mlibrary-pic', as well as by `-fPIC' and `-fpic' without
- `-mfdpic'. You should never have to use it explicitly.
-
-`-mlinked-fp'
- Follow the EABI requirement of always creating a frame pointer
- whenever a stack frame is allocated. This option is enabled by
- default and can be disabled with `-mno-linked-fp'.
-
-`-mlong-calls'
- Use indirect addressing to call functions outside the current
- compilation unit. This allows the functions to be placed anywhere
- within the 32-bit address space.
-
-`-malign-labels'
- Try to align labels to an 8-byte boundary by inserting nops into
- the previous packet. This option only has an effect when VLIW
- packing is enabled. It doesn't create new packets; it merely adds
- nops to existing ones.
-
-`-mlibrary-pic'
- Generate position-independent EABI code.
-
-`-macc-4'
- Use only the first four media accumulator registers.
-
-`-macc-8'
- Use all eight media accumulator registers.
-
-`-mpack'
- Pack VLIW instructions.
-
-`-mno-pack'
- Do not pack VLIW instructions.
-
-`-mno-eflags'
- Do not mark ABI switches in e_flags.
-
-`-mcond-move'
- Enable the use of conditional-move instructions (default).
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-mno-cond-move'
- Disable the use of conditional-move instructions.
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-mscc'
- Enable the use of conditional set instructions (default).
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-mno-scc'
- Disable the use of conditional set instructions.
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-mcond-exec'
- Enable the use of conditional execution (default).
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-mno-cond-exec'
- Disable the use of conditional execution.
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-mvliw-branch'
- Run a pass to pack branches into VLIW instructions (default).
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-mno-vliw-branch'
- Do not run a pass to pack branches into VLIW instructions.
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-mmulti-cond-exec'
- Enable optimization of `&&' and `||' in conditional execution
- (default).
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-mno-multi-cond-exec'
- Disable optimization of `&&' and `||' in conditional execution.
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-mnested-cond-exec'
- Enable nested conditional execution optimizations (default).
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-mno-nested-cond-exec'
- Disable nested conditional execution optimizations.
-
- This switch is mainly for debugging the compiler and will likely
- be removed in a future version.
-
-`-moptimize-membar'
- This switch removes redundant `membar' instructions from the
- compiler generated code. It is enabled by default.
-
-`-mno-optimize-membar'
- This switch disables the automatic removal of redundant `membar'
- instructions from the generated code.
-
-`-mtomcat-stats'
- Cause gas to print out tomcat statistics.
-
-`-mcpu=CPU'
- Select the processor type for which to generate code. Possible
- values are `frv', `fr550', `tomcat', `fr500', `fr450', `fr405',
- `fr400', `fr300' and `simple'.
-
-
-
-File: gcc.info, Node: GNU/Linux Options, Next: H8/300 Options, Prev: FRV Options, Up: Submodel Options
-
-3.17.12 GNU/Linux Options
--------------------------
-
-These `-m' options are defined for GNU/Linux targets:
-
-`-mglibc'
- Use the GNU C library. This is the default except on
- `*-*-linux-*uclibc*' and `*-*-linux-*android*' targets.
-
-`-muclibc'
- Use uClibc C library. This is the default on `*-*-linux-*uclibc*'
- targets.
-
-`-mbionic'
- Use Bionic C library. This is the default on
- `*-*-linux-*android*' targets.
-
-`-mandroid'
- Compile code compatible with Android platform. This is the
- default on `*-*-linux-*android*' targets.
-
- When compiling, this option enables `-mbionic', `-fPIC',
- `-fno-exceptions' and `-fno-rtti' by default. When linking, this
- option makes the GCC driver pass Android-specific options to the
- linker. Finally, this option causes the preprocessor macro
- `__ANDROID__' to be defined.
-
-`-tno-android-cc'
- Disable compilation effects of `-mandroid', i.e., do not enable
- `-mbionic', `-fPIC', `-fno-exceptions' and `-fno-rtti' by default.
-
-`-tno-android-ld'
- Disable linking effects of `-mandroid', i.e., pass standard Linux
- linking options to the linker.
-
-
-
-File: gcc.info, Node: H8/300 Options, Next: HPPA Options, Prev: GNU/Linux Options, Up: Submodel Options
-
-3.17.13 H8/300 Options
-----------------------
-
-These `-m' options are defined for the H8/300 implementations:
-
-`-mrelax'
- Shorten some address references at link time, when possible; uses
- the linker option `-relax'. *Note `ld' and the H8/300:
- (ld)H8/300, for a fuller description.
-
-`-mh'
- Generate code for the H8/300H.
-
-`-ms'
- Generate code for the H8S.
-
-`-mn'
- Generate code for the H8S and H8/300H in the normal mode. This
- switch must be used either with `-mh' or `-ms'.
-
-`-ms2600'
- Generate code for the H8S/2600. This switch must be used with
- `-ms'.
-
-`-mint32'
- Make `int' data 32 bits by default.
-
-`-malign-300'
- On the H8/300H and H8S, use the same alignment rules as for the
- H8/300. The default for the H8/300H and H8S is to align longs and
- floats on 4 byte boundaries. `-malign-300' causes them to be
- aligned on 2 byte boundaries. This option has no effect on the
- H8/300.
-
-
-File: gcc.info, Node: HPPA Options, Next: i386 and x86-64 Options, Prev: H8/300 Options, Up: Submodel Options
-
-3.17.14 HPPA Options
---------------------
-
-These `-m' options are defined for the HPPA family of computers:
-
-`-march=ARCHITECTURE-TYPE'
- Generate code for the specified architecture. The choices for
- ARCHITECTURE-TYPE are `1.0' for PA 1.0, `1.1' for PA 1.1, and
- `2.0' for PA 2.0 processors. Refer to `/usr/lib/sched.models' on
- an HP-UX system to determine the proper architecture option for
- your machine. Code compiled for lower numbered architectures will
- run on higher numbered architectures, but not the other way around.
-
-`-mpa-risc-1-0'
-`-mpa-risc-1-1'
-`-mpa-risc-2-0'
- Synonyms for `-march=1.0', `-march=1.1', and `-march=2.0'
- respectively.
-
-`-mbig-switch'
- Generate code suitable for big switch tables. Use this option
- only if the assembler/linker complain about out of range branches
- within a switch table.
-
-`-mjump-in-delay'
- Fill delay slots of function calls with unconditional jump
- instructions by modifying the return pointer for the function call
- to be the target of the conditional jump.
-
-`-mdisable-fpregs'
- Prevent floating point registers from being used in any manner.
- This is necessary for compiling kernels which perform lazy context
- switching of floating point registers. If you use this option and
- attempt to perform floating point operations, the compiler will
- abort.
-
-`-mdisable-indexing'
- Prevent the compiler from using indexing address modes. This
- avoids some rather obscure problems when compiling MIG generated
- code under MACH.
-
-`-mno-space-regs'
- Generate code that assumes the target has no space registers.
- This allows GCC to generate faster indirect calls and use unscaled
- index address modes.
-
- Such code is suitable for level 0 PA systems and kernels.
-
-`-mfast-indirect-calls'
- Generate code that assumes calls never cross space boundaries.
- This allows GCC to emit code which performs faster indirect calls.
-
- This option will not work in the presence of shared libraries or
- nested functions.
-
-`-mfixed-range=REGISTER-RANGE'
- Generate code treating the given register range as fixed registers.
- A fixed register is one that the register allocator can not use.
- This is useful when compiling kernel code. A register range is
- specified as two registers separated by a dash. Multiple register
- ranges can be specified separated by a comma.
-
-`-mlong-load-store'
- Generate 3-instruction load and store sequences as sometimes
- required by the HP-UX 10 linker. This is equivalent to the `+k'
- option to the HP compilers.
-
-`-mportable-runtime'
- Use the portable calling conventions proposed by HP for ELF
- systems.
-
-`-mgas'
- Enable the use of assembler directives only GAS understands.
-
-`-mschedule=CPU-TYPE'
- Schedule code according to the constraints for the machine type
- CPU-TYPE. The choices for CPU-TYPE are `700' `7100', `7100LC',
- `7200', `7300' and `8000'. Refer to `/usr/lib/sched.models' on an
- HP-UX system to determine the proper scheduling option for your
- machine. The default scheduling is `8000'.
-
-`-mlinker-opt'
- Enable the optimization pass in the HP-UX linker. Note this makes
- symbolic debugging impossible. It also triggers a bug in the
- HP-UX 8 and HP-UX 9 linkers in which they give bogus error
- messages when linking some programs.
-
-`-msoft-float'
- Generate output containing library calls for floating point.
- *Warning:* the requisite libraries are not available for all HPPA
- targets. Normally the facilities of the machine's usual C
- compiler are used, but this cannot be done directly in
- cross-compilation. You must make your own arrangements to provide
- suitable library functions for cross-compilation.
-
- `-msoft-float' changes the calling convention in the output file;
- therefore, it is only useful if you compile _all_ of a program with
- this option. In particular, you need to compile `libgcc.a', the
- library that comes with GCC, with `-msoft-float' in order for this
- to work.
-
-`-msio'
- Generate the predefine, `_SIO', for server IO. The default is
- `-mwsio'. This generates the predefines, `__hp9000s700',
- `__hp9000s700__' and `_WSIO', for workstation IO. These options
- are available under HP-UX and HI-UX.
-
-`-mgnu-ld'
- Use GNU ld specific options. This passes `-shared' to ld when
- building a shared library. It is the default when GCC is
- configured, explicitly or implicitly, with the GNU linker. This
- option does not have any affect on which ld is called, it only
- changes what parameters are passed to that ld. The ld that is
- called is determined by the `--with-ld' configure option, GCC's
- program search path, and finally by the user's `PATH'. The linker
- used by GCC can be printed using `which `gcc
- -print-prog-name=ld`'. This option is only available on the 64
- bit HP-UX GCC, i.e. configured with `hppa*64*-*-hpux*'.
-
-`-mhp-ld'
- Use HP ld specific options. This passes `-b' to ld when building
- a shared library and passes `+Accept TypeMismatch' to ld on all
- links. It is the default when GCC is configured, explicitly or
- implicitly, with the HP linker. This option does not have any
- affect on which ld is called, it only changes what parameters are
- passed to that ld. The ld that is called is determined by the
- `--with-ld' configure option, GCC's program search path, and
- finally by the user's `PATH'. The linker used by GCC can be
- printed using `which `gcc -print-prog-name=ld`'. This option is
- only available on the 64 bit HP-UX GCC, i.e. configured with
- `hppa*64*-*-hpux*'.
-
-`-mlong-calls'
- Generate code that uses long call sequences. This ensures that a
- call is always able to reach linker generated stubs. The default
- is to generate long calls only when the distance from the call
- site to the beginning of the function or translation unit, as the
- case may be, exceeds a predefined limit set by the branch type
- being used. The limits for normal calls are 7,600,000 and 240,000
- bytes, respectively for the PA 2.0 and PA 1.X architectures.
- Sibcalls are always limited at 240,000 bytes.
-
- Distances are measured from the beginning of functions when using
- the `-ffunction-sections' option, or when using the `-mgas' and
- `-mno-portable-runtime' options together under HP-UX with the SOM
- linker.
-
- It is normally not desirable to use this option as it will degrade
- performance. However, it may be useful in large applications,
- particularly when partial linking is used to build the application.
-
- The types of long calls used depends on the capabilities of the
- assembler and linker, and the type of code being generated. The
- impact on systems that support long absolute calls, and long pic
- symbol-difference or pc-relative calls should be relatively small.
- However, an indirect call is used on 32-bit ELF systems in pic code
- and it is quite long.
-
-`-munix=UNIX-STD'
- Generate compiler predefines and select a startfile for the
- specified UNIX standard. The choices for UNIX-STD are `93', `95'
- and `98'. `93' is supported on all HP-UX versions. `95' is
- available on HP-UX 10.10 and later. `98' is available on HP-UX
- 11.11 and later. The default values are `93' for HP-UX 10.00,
- `95' for HP-UX 10.10 though to 11.00, and `98' for HP-UX 11.11 and
- later.
-
- `-munix=93' provides the same predefines as GCC 3.3 and 3.4.
- `-munix=95' provides additional predefines for `XOPEN_UNIX' and
- `_XOPEN_SOURCE_EXTENDED', and the startfile `unix95.o'.
- `-munix=98' provides additional predefines for `_XOPEN_UNIX',
- `_XOPEN_SOURCE_EXTENDED', `_INCLUDE__STDC_A1_SOURCE' and
- `_INCLUDE_XOPEN_SOURCE_500', and the startfile `unix98.o'.
-
- It is _important_ to note that this option changes the interfaces
- for various library routines. It also affects the operational
- behavior of the C library. Thus, _extreme_ care is needed in
- using this option.
-
- Library code that is intended to operate with more than one UNIX
- standard must test, set and restore the variable
- __XPG4_EXTENDED_MASK as appropriate. Most GNU software doesn't
- provide this capability.
-
-`-nolibdld'
- Suppress the generation of link options to search libdld.sl when
- the `-static' option is specified on HP-UX 10 and later.
-
-`-static'
- The HP-UX implementation of setlocale in libc has a dependency on
- libdld.sl. There isn't an archive version of libdld.sl. Thus,
- when the `-static' option is specified, special link options are
- needed to resolve this dependency.
-
- On HP-UX 10 and later, the GCC driver adds the necessary options to
- link with libdld.sl when the `-static' option is specified. This
- causes the resulting binary to be dynamic. On the 64-bit port,
- the linkers generate dynamic binaries by default in any case. The
- `-nolibdld' option can be used to prevent the GCC driver from
- adding these link options.
-
-`-threads'
- Add support for multithreading with the "dce thread" library under
- HP-UX. This option sets flags for both the preprocessor and
- linker.
-
-
-File: gcc.info, Node: i386 and x86-64 Options, Next: i386 and x86-64 Windows Options, Prev: HPPA Options, Up: Submodel Options
-
-3.17.15 Intel 386 and AMD x86-64 Options
-----------------------------------------
-
-These `-m' options are defined for the i386 and x86-64 family of
-computers:
-
-`-mtune=CPU-TYPE'
- Tune to CPU-TYPE everything applicable about the generated code,
- except for the ABI and the set of available instructions. The
- choices for CPU-TYPE are:
- _generic_
- Produce code optimized for the most common IA32/AMD64/EM64T
- processors. If you know the CPU on which your code will run,
- then you should use the corresponding `-mtune' option instead
- of `-mtune=generic'. But, if you do not know exactly what
- CPU users of your application will have, then you should use
- this option.
-
- As new processors are deployed in the marketplace, the
- behavior of this option will change. Therefore, if you
- upgrade to a newer version of GCC, the code generated option
- will change to reflect the processors that were most common
- when that version of GCC was released.
-
- There is no `-march=generic' option because `-march'
- indicates the instruction set the compiler can use, and there
- is no generic instruction set applicable to all processors.
- In contrast, `-mtune' indicates the processor (or, in this
- case, collection of processors) for which the code is
- optimized.
-
- _native_
- This selects the CPU to tune for at compilation time by
- determining the processor type of the compiling machine.
- Using `-mtune=native' will produce code optimized for the
- local machine under the constraints of the selected
- instruction set. Using `-march=native' will enable all
- instruction subsets supported by the local machine (hence the
- result might not run on different machines).
-
- _i386_
- Original Intel's i386 CPU.
-
- _i486_
- Intel's i486 CPU. (No scheduling is implemented for this
- chip.)
-
- _i586, pentium_
- Intel Pentium CPU with no MMX support.
-
- _pentium-mmx_
- Intel PentiumMMX CPU based on Pentium core with MMX
- instruction set support.
-
- _pentiumpro_
- Intel PentiumPro CPU.
-
- _i686_
- Same as `generic', but when used as `march' option, PentiumPro
- instruction set will be used, so the code will run on all
- i686 family chips.
-
- _pentium2_
- Intel Pentium2 CPU based on PentiumPro core with MMX
- instruction set support.
-
- _pentium3, pentium3m_
- Intel Pentium3 CPU based on PentiumPro core with MMX and SSE
- instruction set support.
-
- _pentium-m_
- Low power version of Intel Pentium3 CPU with MMX, SSE and
- SSE2 instruction set support. Used by Centrino notebooks.
-
- _pentium4, pentium4m_
- Intel Pentium4 CPU with MMX, SSE and SSE2 instruction set
- support.
-
- _prescott_
- Improved version of Intel Pentium4 CPU with MMX, SSE, SSE2
- and SSE3 instruction set support.
-
- _nocona_
- Improved version of Intel Pentium4 CPU with 64-bit
- extensions, MMX, SSE, SSE2 and SSE3 instruction set support.
-
- _core2_
- Intel Core2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3
- and SSSE3 instruction set support.
-
- _corei7_
- Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2,
- SSE3, SSSE3, SSE4.1 and SSE4.2 instruction set support.
-
- _corei7-avx_
- Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2,
- SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AES and PCLMUL instruction
- set support.
-
- _core-avx-i_
- Intel Core CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
- SSSE3, SSE4.1, SSE4.2, AVX, AES, PCLMUL, FSGSBASE, RDRND and
- F16C instruction set support.
-
- _atom_
- Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3
- and SSSE3 instruction set support.
-
- _k6_
- AMD K6 CPU with MMX instruction set support.
-
- _k6-2, k6-3_
- Improved versions of AMD K6 CPU with MMX and 3DNow!
- instruction set support.
-
- _athlon, athlon-tbird_
- AMD Athlon CPU with MMX, 3dNOW!, enhanced 3DNow! and SSE
- prefetch instructions support.
-
- _athlon-4, athlon-xp, athlon-mp_
- Improved AMD Athlon CPU with MMX, 3DNow!, enhanced 3DNow! and
- full SSE instruction set support.
-
- _k8, opteron, athlon64, athlon-fx_
- AMD K8 core based CPUs with x86-64 instruction set support.
- (This supersets MMX, SSE, SSE2, 3DNow!, enhanced 3DNow! and
- 64-bit instruction set extensions.)
-
- _k8-sse3, opteron-sse3, athlon64-sse3_
- Improved versions of k8, opteron and athlon64 with SSE3
- instruction set support.
-
- _amdfam10, barcelona_
- AMD Family 10h core based CPUs with x86-64 instruction set
- support. (This supersets MMX, SSE, SSE2, SSE3, SSE4A,
- 3DNow!, enhanced 3DNow!, ABM and 64-bit instruction set
- extensions.)
-
- _winchip-c6_
- IDT Winchip C6 CPU, dealt in same way as i486 with additional
- MMX instruction set support.
-
- _winchip2_
- IDT Winchip2 CPU, dealt in same way as i486 with additional
- MMX and 3DNow! instruction set support.
-
- _c3_
- Via C3 CPU with MMX and 3DNow! instruction set support. (No
- scheduling is implemented for this chip.)
-
- _c3-2_
- Via C3-2 CPU with MMX and SSE instruction set support. (No
- scheduling is implemented for this chip.)
-
- _geode_
- Embedded AMD CPU with MMX and 3DNow! instruction set support.
-
- While picking a specific CPU-TYPE will schedule things
- appropriately for that particular chip, the compiler will not
- generate any code that does not run on the i386 without the
- `-march=CPU-TYPE' option being used.
-
-`-march=CPU-TYPE'
- Generate instructions for the machine type CPU-TYPE. The choices
- for CPU-TYPE are the same as for `-mtune'. Moreover, specifying
- `-march=CPU-TYPE' implies `-mtune=CPU-TYPE'.
-
-`-mcpu=CPU-TYPE'
- A deprecated synonym for `-mtune'.
-
-`-mfpmath=UNIT'
- Generate floating point arithmetics for selected unit UNIT. The
- choices for UNIT are:
-
- `387'
- Use the standard 387 floating point coprocessor present
- majority of chips and emulated otherwise. Code compiled with
- this option will run almost everywhere. The temporary
- results are computed in 80bit precision instead of precision
- specified by the type resulting in slightly different results
- compared to most of other chips. See `-ffloat-store' for
- more detailed description.
-
- This is the default choice for i386 compiler.
-
- `sse'
- Use scalar floating point instructions present in the SSE
- instruction set. This instruction set is supported by
- Pentium3 and newer chips, in the AMD line by Athlon-4,
- Athlon-xp and Athlon-mp chips. The earlier version of SSE
- instruction set supports only single precision arithmetics,
- thus the double and extended precision arithmetics is still
- done using 387. Later version, present only in Pentium4 and
- the future AMD x86-64 chips supports double precision
- arithmetics too.
-
- For the i386 compiler, you need to use `-march=CPU-TYPE',
- `-msse' or `-msse2' switches to enable SSE extensions and
- make this option effective. For the x86-64 compiler, these
- extensions are enabled by default.
-
- The resulting code should be considerably faster in the
- majority of cases and avoid the numerical instability
- problems of 387 code, but may break some existing code that
- expects temporaries to be 80bit.
-
- This is the default choice for the x86-64 compiler.
-
- `sse,387'
- `sse+387'
- `both'
- Attempt to utilize both instruction sets at once. This
- effectively double the amount of available registers and on
- chips with separate execution units for 387 and SSE the
- execution resources too. Use this option with care, as it is
- still experimental, because the GCC register allocator does
- not model separate functional units well resulting in
- instable performance.
-
-`-masm=DIALECT'
- Output asm instructions using selected DIALECT. Supported choices
- are `intel' or `att' (the default one). Darwin does not support
- `intel'.
-
-`-mieee-fp'
-`-mno-ieee-fp'
- Control whether or not the compiler uses IEEE floating point
- comparisons. These handle correctly the case where the result of a
- comparison is unordered.
-
-`-msoft-float'
- Generate output containing library calls for floating point.
- *Warning:* the requisite libraries are not part of GCC. Normally
- the facilities of the machine's usual C compiler are used, but
- this can't be done directly in cross-compilation. You must make
- your own arrangements to provide suitable library functions for
- cross-compilation.
-
- On machines where a function returns floating point results in the
- 80387 register stack, some floating point opcodes may be emitted
- even if `-msoft-float' is used.
-
-`-mno-fp-ret-in-387'
- Do not use the FPU registers for return values of functions.
-
- The usual calling convention has functions return values of types
- `float' and `double' in an FPU register, even if there is no FPU.
- The idea is that the operating system should emulate an FPU.
-
- The option `-mno-fp-ret-in-387' causes such values to be returned
- in ordinary CPU registers instead.
-
-`-mno-fancy-math-387'
- Some 387 emulators do not support the `sin', `cos' and `sqrt'
- instructions for the 387. Specify this option to avoid generating
- those instructions. This option is the default on FreeBSD,
- OpenBSD and NetBSD. This option is overridden when `-march'
- indicates that the target CPU will always have an FPU and so the
- instruction will not need emulation. As of revision 2.6.1, these
- instructions are not generated unless you also use the
- `-funsafe-math-optimizations' switch.
-
-`-malign-double'
-`-mno-align-double'
- Control whether GCC aligns `double', `long double', and `long
- long' variables on a two word boundary or a one word boundary.
- Aligning `double' variables on a two word boundary will produce
- code that runs somewhat faster on a `Pentium' at the expense of
- more memory.
-
- On x86-64, `-malign-double' is enabled by default.
-
- *Warning:* if you use the `-malign-double' switch, structures
- containing the above types will be aligned differently than the
- published application binary interface specifications for the 386
- and will not be binary compatible with structures in code compiled
- without that switch.
-
-`-m96bit-long-double'
-`-m128bit-long-double'
- These switches control the size of `long double' type. The i386
- application binary interface specifies the size to be 96 bits, so
- `-m96bit-long-double' is the default in 32 bit mode.
-
- Modern architectures (Pentium and newer) would prefer `long double'
- to be aligned to an 8 or 16 byte boundary. In arrays or structures
- conforming to the ABI, this would not be possible. So specifying a
- `-m128bit-long-double' will align `long double' to a 16 byte
- boundary by padding the `long double' with an additional 32 bit
- zero.
-
- In the x86-64 compiler, `-m128bit-long-double' is the default
- choice as its ABI specifies that `long double' is to be aligned on
- 16 byte boundary.
-
- Notice that neither of these options enable any extra precision
- over the x87 standard of 80 bits for a `long double'.
-
- *Warning:* if you override the default value for your target ABI,
- the structures and arrays containing `long double' variables will
- change their size as well as function calling convention for
- function taking `long double' will be modified. Hence they will
- not be binary compatible with arrays or structures in code
- compiled without that switch.
-
-`-mlarge-data-threshold=NUMBER'
- When `-mcmodel=medium' is specified, the data greater than
- THRESHOLD are placed in large data section. This value must be the
- same across all object linked into the binary and defaults to
- 65535.
-
-`-mrtd'
- Use a different function-calling convention, in which functions
- that take a fixed number of arguments return with the `ret' NUM
- instruction, which pops their arguments while returning. This
- saves one instruction in the caller since there is no need to pop
- the arguments there.
-
- You can specify that an individual function is called with this
- calling sequence with the function attribute `stdcall'. You can
- also override the `-mrtd' option by using the function attribute
- `cdecl'. *Note Function Attributes::.
-
- *Warning:* this calling convention is incompatible with the one
- normally used on Unix, so you cannot use it if you need to call
- libraries compiled with the Unix compiler.
-
- Also, you must provide function prototypes for all functions that
- take variable numbers of arguments (including `printf'); otherwise
- incorrect code will be generated for calls to those functions.
-
- In addition, seriously incorrect code will result if you call a
- function with too many arguments. (Normally, extra arguments are
- harmlessly ignored.)
-
-`-mregparm=NUM'
- Control how many registers are used to pass integer arguments. By
- default, no registers are used to pass arguments, and at most 3
- registers can be used. You can control this behavior for a
- specific function by using the function attribute `regparm'.
- *Note Function Attributes::.
-
- *Warning:* if you use this switch, and NUM is nonzero, then you
- must build all modules with the same value, including any
- libraries. This includes the system libraries and startup modules.
-
-`-msseregparm'
- Use SSE register passing conventions for float and double arguments
- and return values. You can control this behavior for a specific
- function by using the function attribute `sseregparm'. *Note
- Function Attributes::.
-
- *Warning:* if you use this switch then you must build all modules
- with the same value, including any libraries. This includes the
- system libraries and startup modules.
-
-`-mvect8-ret-in-mem'
- Return 8-byte vectors in memory instead of MMX registers. This is
- the default on Solaris 8 and 9 and VxWorks to match the ABI of the
- Sun Studio compilers until version 12. Later compiler versions
- (starting with Studio 12 Update 1) follow the ABI used by other
- x86 targets, which is the default on Solaris 10 and later. _Only_
- use this option if you need to remain compatible with existing
- code produced by those previous compiler versions or older
- versions of GCC.
-
-`-mpc32'
-`-mpc64'
-`-mpc80'
- Set 80387 floating-point precision to 32, 64 or 80 bits. When
- `-mpc32' is specified, the significands of results of
- floating-point operations are rounded to 24 bits (single
- precision); `-mpc64' rounds the significands of results of
- floating-point operations to 53 bits (double precision) and
- `-mpc80' rounds the significands of results of floating-point
- operations to 64 bits (extended double precision), which is the
- default. When this option is used, floating-point operations in
- higher precisions are not available to the programmer without
- setting the FPU control word explicitly.
-
- Setting the rounding of floating-point operations to less than the
- default 80 bits can speed some programs by 2% or more. Note that
- some mathematical libraries assume that extended precision (80
- bit) floating-point operations are enabled by default; routines in
- such libraries could suffer significant loss of accuracy,
- typically through so-called "catastrophic cancellation", when this
- option is used to set the precision to less than extended
- precision.
-
-`-mstackrealign'
- Realign the stack at entry. On the Intel x86, the `-mstackrealign'
- option will generate an alternate prologue and epilogue that
- realigns the runtime stack if necessary. This supports mixing
- legacy codes that keep a 4-byte aligned stack with modern codes
- that keep a 16-byte stack for SSE compatibility. See also the
- attribute `force_align_arg_pointer', applicable to individual
- functions.
-
-`-mpreferred-stack-boundary=NUM'
- Attempt to keep the stack boundary aligned to a 2 raised to NUM
- byte boundary. If `-mpreferred-stack-boundary' is not specified,
- the default is 4 (16 bytes or 128 bits).
-
-`-mincoming-stack-boundary=NUM'
- Assume the incoming stack is aligned to a 2 raised to NUM byte
- boundary. If `-mincoming-stack-boundary' is not specified, the
- one specified by `-mpreferred-stack-boundary' will be used.
-
- On Pentium and PentiumPro, `double' and `long double' values
- should be aligned to an 8 byte boundary (see `-malign-double') or
- suffer significant run time performance penalties. On Pentium
- III, the Streaming SIMD Extension (SSE) data type `__m128' may not
- work properly if it is not 16 byte aligned.
-
- To ensure proper alignment of this values on the stack, the stack
- boundary must be as aligned as that required by any value stored
- on the stack. Further, every function must be generated such that
- it keeps the stack aligned. Thus calling a function compiled with
- a higher preferred stack boundary from a function compiled with a
- lower preferred stack boundary will most likely misalign the
- stack. It is recommended that libraries that use callbacks always
- use the default setting.
-
- This extra alignment does consume extra stack space, and generally
- increases code size. Code that is sensitive to stack space usage,
- such as embedded systems and operating system kernels, may want to
- reduce the preferred alignment to `-mpreferred-stack-boundary=2'.
-
-`-mmmx'
-`-mno-mmx'
-`-msse'
-`-mno-sse'
-`-msse2'
-`-mno-sse2'
-`-msse3'
-`-mno-sse3'
-`-mssse3'
-`-mno-ssse3'
-`-msse4.1'
-`-mno-sse4.1'
-`-msse4.2'
-`-mno-sse4.2'
-`-msse4'
-`-mno-sse4'
-`-mavx'
-`-mno-avx'
-`-maes'
-`-mno-aes'
-`-mpclmul'
-`-mno-pclmul'
-`-mfsgsbase'
-`-mno-fsgsbase'
-`-mrdrnd'
-`-mno-rdrnd'
-`-mf16c'
-`-mno-f16c'
-`-msse4a'
-`-mno-sse4a'
-`-mfma4'
-`-mno-fma4'
-`-mxop'
-`-mno-xop'
-`-mlwp'
-`-mno-lwp'
-`-m3dnow'
-`-mno-3dnow'
-`-mpopcnt'
-`-mno-popcnt'
-`-mabm'
-`-mno-abm'
-`-mbmi'
-`-mno-bmi'
-`-mtbm'
-`-mno-tbm'
- These switches enable or disable the use of instructions in the
- MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, AVX, AES, PCLMUL, FSGSBASE,
- RDRND, F16C, SSE4A, FMA4, XOP, LWP, ABM, BMI, or 3DNow! extended
- instruction sets. These extensions are also available as built-in
- functions: see *note X86 Built-in Functions::, for details of the
- functions enabled and disabled by these switches.
-
- To have SSE/SSE2 instructions generated automatically from
- floating-point code (as opposed to 387 instructions), see
- `-mfpmath=sse'.
-
- GCC depresses SSEx instructions when `-mavx' is used. Instead, it
- generates new AVX instructions or AVX equivalence for all SSEx
- instructions when needed.
-
- These options will enable GCC to use these extended instructions in
- generated code, even without `-mfpmath=sse'. Applications which
- perform runtime CPU detection must compile separate files for each
- supported architecture, using the appropriate flags. In
- particular, the file containing the CPU detection code should be
- compiled without these options.
-
-`-mfused-madd'
-`-mno-fused-madd'
- Do (don't) generate code that uses the fused multiply/add or
- multiply/subtract instructions. The default is to use these
- instructions.
-
-`-mcld'
- This option instructs GCC to emit a `cld' instruction in the
- prologue of functions that use string instructions. String
- instructions depend on the DF flag to select between autoincrement
- or autodecrement mode. While the ABI specifies the DF flag to be
- cleared on function entry, some operating systems violate this
- specification by not clearing the DF flag in their exception
- dispatchers. The exception handler can be invoked with the DF flag
- set which leads to wrong direction mode, when string instructions
- are used. This option can be enabled by default on 32-bit x86
- targets by configuring GCC with the `--enable-cld' configure
- option. Generation of `cld' instructions can be suppressed with
- the `-mno-cld' compiler option in this case.
-
-`-mvzeroupper'
- This option instructs GCC to emit a `vzeroupper' instruction
- before a transfer of control flow out of the function to minimize
- AVX to SSE transition penalty as well as remove unnecessary
- zeroupper intrinsics.
-
-`-mcx16'
- This option will enable GCC to use CMPXCHG16B instruction in
- generated code. CMPXCHG16B allows for atomic operations on
- 128-bit double quadword (or oword) data types. This is useful for
- high resolution counters that could be updated by multiple
- processors (or cores). This instruction is generated as part of
- atomic built-in functions: see *note Atomic Builtins:: for details.
-
-`-msahf'
- This option will enable GCC to use SAHF instruction in generated
- 64-bit code. Early Intel CPUs with Intel 64 lacked LAHF and SAHF
- instructions supported by AMD64 until introduction of Pentium 4 G1
- step in December 2005. LAHF and SAHF are load and store
- instructions, respectively, for certain status flags. In 64-bit
- mode, SAHF instruction is used to optimize `fmod', `drem' or
- `remainder' built-in functions: see *note Other Builtins:: for
- details.
-
-`-mmovbe'
- This option will enable GCC to use movbe instruction to implement
- `__builtin_bswap32' and `__builtin_bswap64'.
-
-`-mcrc32'
- This option will enable built-in functions,
- `__builtin_ia32_crc32qi', `__builtin_ia32_crc32hi'.
- `__builtin_ia32_crc32si' and `__builtin_ia32_crc32di' to generate
- the crc32 machine instruction.
-
-`-mrecip'
- This option will enable GCC to use RCPSS and RSQRTSS instructions
- (and their vectorized variants RCPPS and RSQRTPS) with an
- additional Newton-Raphson step to increase precision instead of
- DIVSS and SQRTSS (and their vectorized variants) for single
- precision floating point arguments. These instructions are
- generated only when `-funsafe-math-optimizations' is enabled
- together with `-finite-math-only' and `-fno-trapping-math'. Note
- that while the throughput of the sequence is higher than the
- throughput of the non-reciprocal instruction, the precision of the
- sequence can be decreased by up to 2 ulp (i.e. the inverse of 1.0
- equals 0.99999994).
-
- Note that GCC implements 1.0f/sqrtf(x) in terms of RSQRTSS (or
- RSQRTPS) already with `-ffast-math' (or the above option
- combination), and doesn't need `-mrecip'.
-
-`-mveclibabi=TYPE'
- Specifies the ABI type to use for vectorizing intrinsics using an
- external library. Supported types are `svml' for the Intel short
- vector math library and `acml' for the AMD math core library style
- of interfacing. GCC will currently emit calls to `vmldExp2',
- `vmldLn2', `vmldLog102', `vmldLog102', `vmldPow2', `vmldTanh2',
- `vmldTan2', `vmldAtan2', `vmldAtanh2', `vmldCbrt2', `vmldSinh2',
- `vmldSin2', `vmldAsinh2', `vmldAsin2', `vmldCosh2', `vmldCos2',
- `vmldAcosh2', `vmldAcos2', `vmlsExp4', `vmlsLn4', `vmlsLog104',
- `vmlsLog104', `vmlsPow4', `vmlsTanh4', `vmlsTan4', `vmlsAtan4',
- `vmlsAtanh4', `vmlsCbrt4', `vmlsSinh4', `vmlsSin4', `vmlsAsinh4',
- `vmlsAsin4', `vmlsCosh4', `vmlsCos4', `vmlsAcosh4' and `vmlsAcos4'
- for corresponding function type when `-mveclibabi=svml' is used
- and `__vrd2_sin', `__vrd2_cos', `__vrd2_exp', `__vrd2_log',
- `__vrd2_log2', `__vrd2_log10', `__vrs4_sinf', `__vrs4_cosf',
- `__vrs4_expf', `__vrs4_logf', `__vrs4_log2f', `__vrs4_log10f' and
- `__vrs4_powf' for corresponding function type when
- `-mveclibabi=acml' is used. Both `-ftree-vectorize' and
- `-funsafe-math-optimizations' have to be enabled. A SVML or ACML
- ABI compatible library will have to be specified at link time.
-
-`-mabi=NAME'
- Generate code for the specified calling convention. Permissible
- values are: `sysv' for the ABI used on GNU/Linux and other systems
- and `ms' for the Microsoft ABI. The default is to use the
- Microsoft ABI when targeting Windows. On all other systems, the
- default is the SYSV ABI. You can control this behavior for a
- specific function by using the function attribute
- `ms_abi'/`sysv_abi'. *Note Function Attributes::.
-
-`-mpush-args'
-`-mno-push-args'
- Use PUSH operations to store outgoing parameters. This method is
- shorter and usually equally fast as method using SUB/MOV
- operations and is enabled by default. In some cases disabling it
- may improve performance because of improved scheduling and reduced
- dependencies.
-
-`-maccumulate-outgoing-args'
- If enabled, the maximum amount of space required for outgoing
- arguments will be computed in the function prologue. This is
- faster on most modern CPUs because of reduced dependencies,
- improved scheduling and reduced stack usage when preferred stack
- boundary is not equal to 2. The drawback is a notable increase in
- code size. This switch implies `-mno-push-args'.
-
-`-mthreads'
- Support thread-safe exception handling on `Mingw32'. Code that
- relies on thread-safe exception handling must compile and link all
- code with the `-mthreads' option. When compiling, `-mthreads'
- defines `-D_MT'; when linking, it links in a special thread helper
- library `-lmingwthrd' which cleans up per thread exception
- handling data.
-
-`-mno-align-stringops'
- Do not align destination of inlined string operations. This
- switch reduces code size and improves performance in case the
- destination is already aligned, but GCC doesn't know about it.
-
-`-minline-all-stringops'
- By default GCC inlines string operations only when destination is
- known to be aligned at least to 4 byte boundary. This enables
- more inlining, increase code size, but may improve performance of
- code that depends on fast memcpy, strlen and memset for short
- lengths.
-
-`-minline-stringops-dynamically'
- For string operation of unknown size, inline runtime checks so for
- small blocks inline code is used, while for large blocks library
- call is used.
-
-`-mstringop-strategy=ALG'
- Overwrite internal decision heuristic about particular algorithm
- to inline string operation with. The allowed values are
- `rep_byte', `rep_4byte', `rep_8byte' for expanding using i386
- `rep' prefix of specified size, `byte_loop', `loop',
- `unrolled_loop' for expanding inline loop, `libcall' for always
- expanding library call.
-
-`-momit-leaf-frame-pointer'
- Don't keep the frame pointer in a register for leaf functions.
- This avoids the instructions to save, set up and restore frame
- pointers and makes an extra register available in leaf functions.
- The option `-fomit-frame-pointer' removes the frame pointer for
- all functions which might make debugging harder.
-
-`-mtls-direct-seg-refs'
-`-mno-tls-direct-seg-refs'
- Controls whether TLS variables may be accessed with offsets from
- the TLS segment register (`%gs' for 32-bit, `%fs' for 64-bit), or
- whether the thread base pointer must be added. Whether or not this
- is legal depends on the operating system, and whether it maps the
- segment to cover the entire TLS area.
-
- For systems that use GNU libc, the default is on.
-
-`-msse2avx'
-`-mno-sse2avx'
- Specify that the assembler should encode SSE instructions with VEX
- prefix. The option `-mavx' turns this on by default.
-
-`-mfentry'
-`-mno-fentry'
- If profiling is active `-pg' put the profiling counter call before
- prologue. Note: On x86 architectures the attribute
- `ms_hook_prologue' isn't possible at the moment for `-mfentry' and
- `-pg'.
-
-`-m8bit-idiv'
-`-mno-8bit-idiv'
- On some processors, like Intel Atom, 8bit unsigned integer divide
- is much faster than 32bit/64bit integer divide. This option will
- generate a runt-time check. If both dividend and divisor are
- within range of 0 to 255, 8bit unsigned integer divide will be
- used instead of 32bit/64bit integer divide.
-
-`-mavx256-split-unaligned-load'
-
-`-mavx256-split-unaligned-store'
- Split 32-byte AVX unaligned load and store.
-
-
- These `-m' switches are supported in addition to the above on AMD
-x86-64 processors in 64-bit environments.
-
-`-m32'
-`-m64'
- Generate code for a 32-bit or 64-bit environment. The 32-bit
- environment sets int, long and pointer to 32 bits and generates
- code that runs on any i386 system. The 64-bit environment sets
- int to 32 bits and long and pointer to 64 bits and generates code
- for AMD's x86-64 architecture. For darwin only the -m64 option
- turns off the `-fno-pic' and `-mdynamic-no-pic' options.
-
-`-mno-red-zone'
- Do not use a so called red zone for x86-64 code. The red zone is
- mandated by the x86-64 ABI, it is a 128-byte area beyond the
- location of the stack pointer that will not be modified by signal
- or interrupt handlers and therefore can be used for temporary data
- without adjusting the stack pointer. The flag `-mno-red-zone'
- disables this red zone.
-
-`-mcmodel=small'
- Generate code for the small code model: the program and its
- symbols must be linked in the lower 2 GB of the address space.
- Pointers are 64 bits. Programs can be statically or dynamically
- linked. This is the default code model.
-
-`-mcmodel=kernel'
- Generate code for the kernel code model. The kernel runs in the
- negative 2 GB of the address space. This model has to be used for
- Linux kernel code.
-
-`-mcmodel=medium'
- Generate code for the medium model: The program is linked in the
- lower 2 GB of the address space. Small symbols are also placed
- there. Symbols with sizes larger than `-mlarge-data-threshold'
- are put into large data or bss sections and can be located above
- 2GB. Programs can be statically or dynamically linked.
-
-`-mcmodel=large'
- Generate code for the large model: This model makes no assumptions
- about addresses and sizes of sections.
-
-
-File: gcc.info, Node: i386 and x86-64 Windows Options, Next: IA-64 Options, Prev: i386 and x86-64 Options, Up: Submodel Options
-
-3.17.16 i386 and x86-64 Windows Options
----------------------------------------
-
-These additional options are available for Windows targets:
-
-`-mconsole'
- This option is available for Cygwin and MinGW targets. It
- specifies that a console application is to be generated, by
- instructing the linker to set the PE header subsystem type
- required for console applications. This is the default behavior
- for Cygwin and MinGW targets.
-
-`-mdll'
- This option is available for Cygwin and MinGW targets. It
- specifies that a DLL - a dynamic link library - is to be
- generated, enabling the selection of the required runtime startup
- object and entry point.
-
-`-mnop-fun-dllimport'
- This option is available for Cygwin and MinGW targets. It
- specifies that the dllimport attribute should be ignored.
-
-`-mthread'
- This option is available for MinGW targets. It specifies that
- MinGW-specific thread support is to be used.
-
-`-municode'
- This option is available for mingw-w64 targets. It specifies that
- the UNICODE macro is getting pre-defined and that the unicode
- capable runtime startup code is chosen.
-
-`-mwin32'
- This option is available for Cygwin and MinGW targets. It
- specifies that the typical Windows pre-defined macros are to be
- set in the pre-processor, but does not influence the choice of
- runtime library/startup code.
-
-`-mwindows'
- This option is available for Cygwin and MinGW targets. It
- specifies that a GUI application is to be generated by instructing
- the linker to set the PE header subsystem type appropriately.
-
-`-fno-set-stack-executable'
- This option is available for MinGW targets. It specifies that the
- executable flag for stack used by nested functions isn't set. This
- is necessary for binaries running in kernel mode of Windows, as
- there the user32 API, which is used to set executable privileges,
- isn't available.
-
-`-mpe-aligned-commons'
- This option is available for Cygwin and MinGW targets. It
- specifies that the GNU extension to the PE file format that
- permits the correct alignment of COMMON variables should be used
- when generating code. It will be enabled by default if GCC
- detects that the target assembler found during configuration
- supports the feature.
-
- See also under *note i386 and x86-64 Options:: for standard options.
-
-
-File: gcc.info, Node: IA-64 Options, Next: IA-64/VMS Options, Prev: i386 and x86-64 Windows Options, Up: Submodel Options
-
-3.17.17 IA-64 Options
----------------------
-
-These are the `-m' options defined for the Intel IA-64 architecture.
-
-`-mbig-endian'
- Generate code for a big endian target. This is the default for
- HP-UX.
-
-`-mlittle-endian'
- Generate code for a little endian target. This is the default for
- AIX5 and GNU/Linux.
-
-`-mgnu-as'
-`-mno-gnu-as'
- Generate (or don't) code for the GNU assembler. This is the
- default.
-
-`-mgnu-ld'
-`-mno-gnu-ld'
- Generate (or don't) code for the GNU linker. This is the default.
-
-`-mno-pic'
- Generate code that does not use a global pointer register. The
- result is not position independent code, and violates the IA-64
- ABI.
-
-`-mvolatile-asm-stop'
-`-mno-volatile-asm-stop'
- Generate (or don't) a stop bit immediately before and after
- volatile asm statements.
-
-`-mregister-names'
-`-mno-register-names'
- Generate (or don't) `in', `loc', and `out' register names for the
- stacked registers. This may make assembler output more readable.
-
-`-mno-sdata'
-`-msdata'
- Disable (or enable) optimizations that use the small data section.
- This may be useful for working around optimizer bugs.
-
-`-mconstant-gp'
- Generate code that uses a single constant global pointer value.
- This is useful when compiling kernel code.
-
-`-mauto-pic'
- Generate code that is self-relocatable. This implies
- `-mconstant-gp'. This is useful when compiling firmware code.
-
-`-minline-float-divide-min-latency'
- Generate code for inline divides of floating point values using
- the minimum latency algorithm.
-
-`-minline-float-divide-max-throughput'
- Generate code for inline divides of floating point values using
- the maximum throughput algorithm.
-
-`-mno-inline-float-divide'
- Do not generate inline code for divides of floating point values.
-
-`-minline-int-divide-min-latency'
- Generate code for inline divides of integer values using the
- minimum latency algorithm.
-
-`-minline-int-divide-max-throughput'
- Generate code for inline divides of integer values using the
- maximum throughput algorithm.
-
-`-mno-inline-int-divide'
- Do not generate inline code for divides of integer values.
-
-`-minline-sqrt-min-latency'
- Generate code for inline square roots using the minimum latency
- algorithm.
-
-`-minline-sqrt-max-throughput'
- Generate code for inline square roots using the maximum throughput
- algorithm.
-
-`-mno-inline-sqrt'
- Do not generate inline code for sqrt.
-
-`-mfused-madd'
-`-mno-fused-madd'
- Do (don't) generate code that uses the fused multiply/add or
- multiply/subtract instructions. The default is to use these
- instructions.
-
-`-mno-dwarf2-asm'
-`-mdwarf2-asm'
- Don't (or do) generate assembler code for the DWARF2 line number
- debugging info. This may be useful when not using the GNU
- assembler.
-
-`-mearly-stop-bits'
-`-mno-early-stop-bits'
- Allow stop bits to be placed earlier than immediately preceding the
- instruction that triggered the stop bit. This can improve
- instruction scheduling, but does not always do so.
-
-`-mfixed-range=REGISTER-RANGE'
- Generate code treating the given register range as fixed registers.
- A fixed register is one that the register allocator can not use.
- This is useful when compiling kernel code. A register range is
- specified as two registers separated by a dash. Multiple register
- ranges can be specified separated by a comma.
-
-`-mtls-size=TLS-SIZE'
- Specify bit size of immediate TLS offsets. Valid values are 14,
- 22, and 64.
-
-`-mtune=CPU-TYPE'
- Tune the instruction scheduling for a particular CPU, Valid values
- are itanium, itanium1, merced, itanium2, and mckinley.
-
-`-milp32'
-`-mlp64'
- Generate code for a 32-bit or 64-bit environment. The 32-bit
- environment sets int, long and pointer to 32 bits. The 64-bit
- environment sets int to 32 bits and long and pointer to 64 bits.
- These are HP-UX specific flags.
-
-`-mno-sched-br-data-spec'
-`-msched-br-data-spec'
- (Dis/En)able data speculative scheduling before reload. This will
- result in generation of the ld.a instructions and the
- corresponding check instructions (ld.c / chk.a). The default is
- 'disable'.
-
-`-msched-ar-data-spec'
-`-mno-sched-ar-data-spec'
- (En/Dis)able data speculative scheduling after reload. This will
- result in generation of the ld.a instructions and the
- corresponding check instructions (ld.c / chk.a). The default is
- 'enable'.
-
-`-mno-sched-control-spec'
-`-msched-control-spec'
- (Dis/En)able control speculative scheduling. This feature is
- available only during region scheduling (i.e. before reload).
- This will result in generation of the ld.s instructions and the
- corresponding check instructions chk.s . The default is 'disable'.
-
-`-msched-br-in-data-spec'
-`-mno-sched-br-in-data-spec'
- (En/Dis)able speculative scheduling of the instructions that are
- dependent on the data speculative loads before reload. This is
- effective only with `-msched-br-data-spec' enabled. The default
- is 'enable'.
-
-`-msched-ar-in-data-spec'
-`-mno-sched-ar-in-data-spec'
- (En/Dis)able speculative scheduling of the instructions that are
- dependent on the data speculative loads after reload. This is
- effective only with `-msched-ar-data-spec' enabled. The default
- is 'enable'.
-
-`-msched-in-control-spec'
-`-mno-sched-in-control-spec'
- (En/Dis)able speculative scheduling of the instructions that are
- dependent on the control speculative loads. This is effective
- only with `-msched-control-spec' enabled. The default is 'enable'.
-
-`-mno-sched-prefer-non-data-spec-insns'
-`-msched-prefer-non-data-spec-insns'
- If enabled, data speculative instructions will be chosen for
- schedule only if there are no other choices at the moment. This
- will make the use of the data speculation much more conservative.
- The default is 'disable'.
-
-`-mno-sched-prefer-non-control-spec-insns'
-`-msched-prefer-non-control-spec-insns'
- If enabled, control speculative instructions will be chosen for
- schedule only if there are no other choices at the moment. This
- will make the use of the control speculation much more
- conservative. The default is 'disable'.
-
-`-mno-sched-count-spec-in-critical-path'
-`-msched-count-spec-in-critical-path'
- If enabled, speculative dependencies will be considered during
- computation of the instructions priorities. This will make the
- use of the speculation a bit more conservative. The default is
- 'disable'.
-
-`-msched-spec-ldc'
- Use a simple data speculation check. This option is on by default.
-
-`-msched-control-spec-ldc'
- Use a simple check for control speculation. This option is on by
- default.
-
-`-msched-stop-bits-after-every-cycle'
- Place a stop bit after every cycle when scheduling. This option
- is on by default.
-
-`-msched-fp-mem-deps-zero-cost'
- Assume that floating-point stores and loads are not likely to
- cause a conflict when placed into the same instruction group.
- This option is disabled by default.
-
-`-msel-sched-dont-check-control-spec'
- Generate checks for control speculation in selective scheduling.
- This flag is disabled by default.
-
-`-msched-max-memory-insns=MAX-INSNS'
- Limit on the number of memory insns per instruction group, giving
- lower priority to subsequent memory insns attempting to schedule
- in the same instruction group. Frequently useful to prevent cache
- bank conflicts. The default value is 1.
-
-`-msched-max-memory-insns-hard-limit'
- Disallow more than `msched-max-memory-insns' in instruction group.
- Otherwise, limit is `soft' meaning that we would prefer non-memory
- operations when limit is reached but may still schedule memory
- operations.
-
-
-
-File: gcc.info, Node: IA-64/VMS Options, Next: LM32 Options, Prev: IA-64 Options, Up: Submodel Options
-
-3.17.18 IA-64/VMS Options
--------------------------
-
-These `-m' options are defined for the IA-64/VMS implementations:
-
-`-mvms-return-codes'
- Return VMS condition codes from main. The default is to return
- POSIX style condition (e.g. error) codes.
-
-`-mdebug-main=PREFIX'
- Flag the first routine whose name starts with PREFIX as the main
- routine for the debugger.
-
-`-mmalloc64'
- Default to 64bit memory allocation routines.
-
-
-File: gcc.info, Node: LM32 Options, Next: M32C Options, Prev: IA-64/VMS Options, Up: Submodel Options
-
-3.17.19 LM32 Options
---------------------
-
-These `-m' options are defined for the Lattice Mico32 architecture:
-
-`-mbarrel-shift-enabled'
- Enable barrel-shift instructions.
-
-`-mdivide-enabled'
- Enable divide and modulus instructions.
-
-`-mmultiply-enabled'
- Enable multiply instructions.
-
-`-msign-extend-enabled'
- Enable sign extend instructions.
-
-`-muser-enabled'
- Enable user-defined instructions.
-
-
-
-File: gcc.info, Node: M32C Options, Next: M32R/D Options, Prev: LM32 Options, Up: Submodel Options
-
-3.17.20 M32C Options
---------------------
-
-`-mcpu=NAME'
- Select the CPU for which code is generated. NAME may be one of
- `r8c' for the R8C/Tiny series, `m16c' for the M16C (up to /60)
- series, `m32cm' for the M16C/80 series, or `m32c' for the M32C/80
- series.
-
-`-msim'
- Specifies that the program will be run on the simulator. This
- causes an alternate runtime library to be linked in which
- supports, for example, file I/O. You must not use this option
- when generating programs that will run on real hardware; you must
- provide your own runtime library for whatever I/O functions are
- needed.
-
-`-memregs=NUMBER'
- Specifies the number of memory-based pseudo-registers GCC will use
- during code generation. These pseudo-registers will be used like
- real registers, so there is a tradeoff between GCC's ability to
- fit the code into available registers, and the performance penalty
- of using memory instead of registers. Note that all modules in a
- program must be compiled with the same value for this option.
- Because of that, you must not use this option with the default
- runtime libraries gcc builds.
-
-
-
-File: gcc.info, Node: M32R/D Options, Next: M680x0 Options, Prev: M32C Options, Up: Submodel Options
-
-3.17.21 M32R/D Options
-----------------------
-
-These `-m' options are defined for Renesas M32R/D architectures:
-
-`-m32r2'
- Generate code for the M32R/2.
-
-`-m32rx'
- Generate code for the M32R/X.
-
-`-m32r'
- Generate code for the M32R. This is the default.
-
-`-mmodel=small'
- Assume all objects live in the lower 16MB of memory (so that their
- addresses can be loaded with the `ld24' instruction), and assume
- all subroutines are reachable with the `bl' instruction. This is
- the default.
-
- The addressability of a particular object can be set with the
- `model' attribute.
-
-`-mmodel=medium'
- Assume objects may be anywhere in the 32-bit address space (the
- compiler will generate `seth/add3' instructions to load their
- addresses), and assume all subroutines are reachable with the `bl'
- instruction.
-
-`-mmodel=large'
- Assume objects may be anywhere in the 32-bit address space (the
- compiler will generate `seth/add3' instructions to load their
- addresses), and assume subroutines may not be reachable with the
- `bl' instruction (the compiler will generate the much slower
- `seth/add3/jl' instruction sequence).
-
-`-msdata=none'
- Disable use of the small data area. Variables will be put into
- one of `.data', `bss', or `.rodata' (unless the `section'
- attribute has been specified). This is the default.
-
- The small data area consists of sections `.sdata' and `.sbss'.
- Objects may be explicitly put in the small data area with the
- `section' attribute using one of these sections.
-
-`-msdata=sdata'
- Put small global and static data in the small data area, but do not
- generate special code to reference them.
-
-`-msdata=use'
- Put small global and static data in the small data area, and
- generate special instructions to reference them.
-
-`-G NUM'
- Put global and static objects less than or equal to NUM bytes into
- the small data or bss sections instead of the normal data or bss
- sections. The default value of NUM is 8. The `-msdata' option
- must be set to one of `sdata' or `use' for this option to have any
- effect.
-
- All modules should be compiled with the same `-G NUM' value.
- Compiling with different values of NUM may or may not work; if it
- doesn't the linker will give an error message--incorrect code will
- not be generated.
-
-`-mdebug'
- Makes the M32R specific code in the compiler display some
- statistics that might help in debugging programs.
-
-`-malign-loops'
- Align all loops to a 32-byte boundary.
-
-`-mno-align-loops'
- Do not enforce a 32-byte alignment for loops. This is the default.
-
-`-missue-rate=NUMBER'
- Issue NUMBER instructions per cycle. NUMBER can only be 1 or 2.
-
-`-mbranch-cost=NUMBER'
- NUMBER can only be 1 or 2. If it is 1 then branches will be
- preferred over conditional code, if it is 2, then the opposite will
- apply.
-
-`-mflush-trap=NUMBER'
- Specifies the trap number to use to flush the cache. The default
- is 12. Valid numbers are between 0 and 15 inclusive.
-
-`-mno-flush-trap'
- Specifies that the cache cannot be flushed by using a trap.
-
-`-mflush-func=NAME'
- Specifies the name of the operating system function to call to
- flush the cache. The default is __flush_cache_, but a function
- call will only be used if a trap is not available.
-
-`-mno-flush-func'
- Indicates that there is no OS function for flushing the cache.
-
-
-
-File: gcc.info, Node: M680x0 Options, Next: M68hc1x Options, Prev: M32R/D Options, Up: Submodel Options
-
-3.17.22 M680x0 Options
-----------------------
-
-These are the `-m' options defined for M680x0 and ColdFire processors.
-The default settings depend on which architecture was selected when the
-compiler was configured; the defaults for the most common choices are
-given below.
-
-`-march=ARCH'
- Generate code for a specific M680x0 or ColdFire instruction set
- architecture. Permissible values of ARCH for M680x0 architectures
- are: `68000', `68010', `68020', `68030', `68040', `68060' and
- `cpu32'. ColdFire architectures are selected according to
- Freescale's ISA classification and the permissible values are:
- `isaa', `isaaplus', `isab' and `isac'.
-
- gcc defines a macro `__mcfARCH__' whenever it is generating code
- for a ColdFire target. The ARCH in this macro is one of the
- `-march' arguments given above.
-
- When used together, `-march' and `-mtune' select code that runs on
- a family of similar processors but that is optimized for a
- particular microarchitecture.
-
-`-mcpu=CPU'
- Generate code for a specific M680x0 or ColdFire processor. The
- M680x0 CPUs are: `68000', `68010', `68020', `68030', `68040',
- `68060', `68302', `68332' and `cpu32'. The ColdFire CPUs are
- given by the table below, which also classifies the CPUs into
- families:
-
- *Family* *`-mcpu' arguments*
- `51' `51' `51ac' `51cn' `51em' `51qe'
- `5206' `5202' `5204' `5206'
- `5206e' `5206e'
- `5208' `5207' `5208'
- `5211a' `5210a' `5211a'
- `5213' `5211' `5212' `5213'
- `5216' `5214' `5216'
- `52235' `52230' `52231' `52232' `52233' `52234' `52235'
- `5225' `5224' `5225'
- `52259' `52252' `52254' `52255' `52256' `52258' `52259'
- `5235' `5232' `5233' `5234' `5235' `523x'
- `5249' `5249'
- `5250' `5250'
- `5271' `5270' `5271'
- `5272' `5272'
- `5275' `5274' `5275'
- `5282' `5280' `5281' `5282' `528x'
- `53017' `53011' `53012' `53013' `53014' `53015' `53016'
- `53017'
- `5307' `5307'
- `5329' `5327' `5328' `5329' `532x'
- `5373' `5372' `5373' `537x'
- `5407' `5407'
- `5475' `5470' `5471' `5472' `5473' `5474' `5475' `547x'
- `5480' `5481' `5482' `5483' `5484' `5485'
-
- `-mcpu=CPU' overrides `-march=ARCH' if ARCH is compatible with
- CPU. Other combinations of `-mcpu' and `-march' are rejected.
-
- gcc defines the macro `__mcf_cpu_CPU' when ColdFire target CPU is
- selected. It also defines `__mcf_family_FAMILY', where the value
- of FAMILY is given by the table above.
-
-`-mtune=TUNE'
- Tune the code for a particular microarchitecture, within the
- constraints set by `-march' and `-mcpu'. The M680x0
- microarchitectures are: `68000', `68010', `68020', `68030',
- `68040', `68060' and `cpu32'. The ColdFire microarchitectures
- are: `cfv1', `cfv2', `cfv3', `cfv4' and `cfv4e'.
-
- You can also use `-mtune=68020-40' for code that needs to run
- relatively well on 68020, 68030 and 68040 targets.
- `-mtune=68020-60' is similar but includes 68060 targets as well.
- These two options select the same tuning decisions as `-m68020-40'
- and `-m68020-60' respectively.
-
- gcc defines the macros `__mcARCH' and `__mcARCH__' when tuning for
- 680x0 architecture ARCH. It also defines `mcARCH' unless either
- `-ansi' or a non-GNU `-std' option is used. If gcc is tuning for
- a range of architectures, as selected by `-mtune=68020-40' or
- `-mtune=68020-60', it defines the macros for every architecture in
- the range.
-
- gcc also defines the macro `__mUARCH__' when tuning for ColdFire
- microarchitecture UARCH, where UARCH is one of the arguments given
- above.
-
-`-m68000'
-`-mc68000'
- Generate output for a 68000. This is the default when the
- compiler is configured for 68000-based systems. It is equivalent
- to `-march=68000'.
-
- Use this option for microcontrollers with a 68000 or EC000 core,
- including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
-
-`-m68010'
- Generate output for a 68010. This is the default when the
- compiler is configured for 68010-based systems. It is equivalent
- to `-march=68010'.
-
-`-m68020'
-`-mc68020'
- Generate output for a 68020. This is the default when the
- compiler is configured for 68020-based systems. It is equivalent
- to `-march=68020'.
-
-`-m68030'
- Generate output for a 68030. This is the default when the
- compiler is configured for 68030-based systems. It is equivalent
- to `-march=68030'.
-
-`-m68040'
- Generate output for a 68040. This is the default when the
- compiler is configured for 68040-based systems. It is equivalent
- to `-march=68040'.
-
- This option inhibits the use of 68881/68882 instructions that have
- to be emulated by software on the 68040. Use this option if your
- 68040 does not have code to emulate those instructions.
-
-`-m68060'
- Generate output for a 68060. This is the default when the
- compiler is configured for 68060-based systems. It is equivalent
- to `-march=68060'.
-
- This option inhibits the use of 68020 and 68881/68882 instructions
- that have to be emulated by software on the 68060. Use this
- option if your 68060 does not have code to emulate those
- instructions.
-
-`-mcpu32'
- Generate output for a CPU32. This is the default when the
- compiler is configured for CPU32-based systems. It is equivalent
- to `-march=cpu32'.
-
- Use this option for microcontrollers with a CPU32 or CPU32+ core,
- including the 68330, 68331, 68332, 68333, 68334, 68336, 68340,
- 68341, 68349 and 68360.
-
-`-m5200'
- Generate output for a 520X ColdFire CPU. This is the default when
- the compiler is configured for 520X-based systems. It is
- equivalent to `-mcpu=5206', and is now deprecated in favor of that
- option.
-
- Use this option for microcontroller with a 5200 core, including
- the MCF5202, MCF5203, MCF5204 and MCF5206.
-
-`-m5206e'
- Generate output for a 5206e ColdFire CPU. The option is now
- deprecated in favor of the equivalent `-mcpu=5206e'.
-
-`-m528x'
- Generate output for a member of the ColdFire 528X family. The
- option is now deprecated in favor of the equivalent `-mcpu=528x'.
-
-`-m5307'
- Generate output for a ColdFire 5307 CPU. The option is now
- deprecated in favor of the equivalent `-mcpu=5307'.
-
-`-m5407'
- Generate output for a ColdFire 5407 CPU. The option is now
- deprecated in favor of the equivalent `-mcpu=5407'.
-
-`-mcfv4e'
- Generate output for a ColdFire V4e family CPU (e.g. 547x/548x).
- This includes use of hardware floating point instructions. The
- option is equivalent to `-mcpu=547x', and is now deprecated in
- favor of that option.
-
-`-m68020-40'
- Generate output for a 68040, without using any of the new
- instructions. This results in code which can run relatively
- efficiently on either a 68020/68881 or a 68030 or a 68040. The
- generated code does use the 68881 instructions that are emulated
- on the 68040.
-
- The option is equivalent to `-march=68020' `-mtune=68020-40'.
-
-`-m68020-60'
- Generate output for a 68060, without using any of the new
- instructions. This results in code which can run relatively
- efficiently on either a 68020/68881 or a 68030 or a 68040. The
- generated code does use the 68881 instructions that are emulated
- on the 68060.
-
- The option is equivalent to `-march=68020' `-mtune=68020-60'.
-
-`-mhard-float'
-`-m68881'
- Generate floating-point instructions. This is the default for
- 68020 and above, and for ColdFire devices that have an FPU. It
- defines the macro `__HAVE_68881__' on M680x0 targets and
- `__mcffpu__' on ColdFire targets.
-
-`-msoft-float'
- Do not generate floating-point instructions; use library calls
- instead. This is the default for 68000, 68010, and 68832 targets.
- It is also the default for ColdFire devices that have no FPU.
-
-`-mdiv'
-`-mno-div'
- Generate (do not generate) ColdFire hardware divide and remainder
- instructions. If `-march' is used without `-mcpu', the default is
- "on" for ColdFire architectures and "off" for M680x0
- architectures. Otherwise, the default is taken from the target CPU
- (either the default CPU, or the one specified by `-mcpu'). For
- example, the default is "off" for `-mcpu=5206' and "on" for
- `-mcpu=5206e'.
-
- gcc defines the macro `__mcfhwdiv__' when this option is enabled.
-
-`-mshort'
- Consider type `int' to be 16 bits wide, like `short int'.
- Additionally, parameters passed on the stack are also aligned to a
- 16-bit boundary even on targets whose API mandates promotion to
- 32-bit.
-
-`-mno-short'
- Do not consider type `int' to be 16 bits wide. This is the
- default.
-
-`-mnobitfield'
-`-mno-bitfield'
- Do not use the bit-field instructions. The `-m68000', `-mcpu32'
- and `-m5200' options imply `-mnobitfield'.
-
-`-mbitfield'
- Do use the bit-field instructions. The `-m68020' option implies
- `-mbitfield'. This is the default if you use a configuration
- designed for a 68020.
-
-`-mrtd'
- Use a different function-calling convention, in which functions
- that take a fixed number of arguments return with the `rtd'
- instruction, which pops their arguments while returning. This
- saves one instruction in the caller since there is no need to pop
- the arguments there.
-
- This calling convention is incompatible with the one normally used
- on Unix, so you cannot use it if you need to call libraries
- compiled with the Unix compiler.
-
- Also, you must provide function prototypes for all functions that
- take variable numbers of arguments (including `printf'); otherwise
- incorrect code will be generated for calls to those functions.
-
- In addition, seriously incorrect code will result if you call a
- function with too many arguments. (Normally, extra arguments are
- harmlessly ignored.)
-
- The `rtd' instruction is supported by the 68010, 68020, 68030,
- 68040, 68060 and CPU32 processors, but not by the 68000 or 5200.
-
-`-mno-rtd'
- Do not use the calling conventions selected by `-mrtd'. This is
- the default.
-
-`-malign-int'
-`-mno-align-int'
- Control whether GCC aligns `int', `long', `long long', `float',
- `double', and `long double' variables on a 32-bit boundary
- (`-malign-int') or a 16-bit boundary (`-mno-align-int'). Aligning
- variables on 32-bit boundaries produces code that runs somewhat
- faster on processors with 32-bit busses at the expense of more
- memory.
-
- *Warning:* if you use the `-malign-int' switch, GCC will align
- structures containing the above types differently than most
- published application binary interface specifications for the m68k.
-
-`-mpcrel'
- Use the pc-relative addressing mode of the 68000 directly, instead
- of using a global offset table. At present, this option implies
- `-fpic', allowing at most a 16-bit offset for pc-relative
- addressing. `-fPIC' is not presently supported with `-mpcrel',
- though this could be supported for 68020 and higher processors.
-
-`-mno-strict-align'
-`-mstrict-align'
- Do not (do) assume that unaligned memory references will be
- handled by the system.
-
-`-msep-data'
- Generate code that allows the data segment to be located in a
- different area of memory from the text segment. This allows for
- execute in place in an environment without virtual memory
- management. This option implies `-fPIC'.
-
-`-mno-sep-data'
- Generate code that assumes that the data segment follows the text
- segment. This is the default.
-
-`-mid-shared-library'
- Generate code that supports shared libraries via the library ID
- method. This allows for execute in place and shared libraries in
- an environment without virtual memory management. This option
- implies `-fPIC'.
-
-`-mno-id-shared-library'
- Generate code that doesn't assume ID based shared libraries are
- being used. This is the default.
-
-`-mshared-library-id=n'
- Specified the identification number of the ID based shared library
- being compiled. Specifying a value of 0 will generate more
- compact code, specifying other values will force the allocation of
- that number to the current library but is no more space or time
- efficient than omitting this option.
-
-`-mxgot'
-`-mno-xgot'
- When generating position-independent code for ColdFire, generate
- code that works if the GOT has more than 8192 entries. This code
- is larger and slower than code generated without this option. On
- M680x0 processors, this option is not needed; `-fPIC' suffices.
-
- GCC normally uses a single instruction to load values from the GOT.
- While this is relatively efficient, it only works if the GOT is
- smaller than about 64k. Anything larger causes the linker to
- report an error such as:
-
- relocation truncated to fit: R_68K_GOT16O foobar
-
- If this happens, you should recompile your code with `-mxgot'. It
- should then work with very large GOTs. However, code generated
- with `-mxgot' is less efficient, since it takes 4 instructions to
- fetch the value of a global symbol.
-
- Note that some linkers, including newer versions of the GNU linker,
- can create multiple GOTs and sort GOT entries. If you have such a
- linker, you should only need to use `-mxgot' when compiling a
- single object file that accesses more than 8192 GOT entries. Very
- few do.
-
- These options have no effect unless GCC is generating
- position-independent code.
-
-
-
-File: gcc.info, Node: M68hc1x Options, Next: MCore Options, Prev: M680x0 Options, Up: Submodel Options
-
-3.17.23 M68hc1x Options
------------------------
-
-These are the `-m' options defined for the 68hc11 and 68hc12
-microcontrollers. The default values for these options depends on
-which style of microcontroller was selected when the compiler was
-configured; the defaults for the most common choices are given below.
-
-`-m6811'
-`-m68hc11'
- Generate output for a 68HC11. This is the default when the
- compiler is configured for 68HC11-based systems.
-
-`-m6812'
-`-m68hc12'
- Generate output for a 68HC12. This is the default when the
- compiler is configured for 68HC12-based systems.
-
-`-m68S12'
-`-m68hcs12'
- Generate output for a 68HCS12.
-
-`-mauto-incdec'
- Enable the use of 68HC12 pre and post auto-increment and
- auto-decrement addressing modes.
-
-`-minmax'
-`-mnominmax'
- Enable the use of 68HC12 min and max instructions.
-
-`-mlong-calls'
-`-mno-long-calls'
- Treat all calls as being far away (near). If calls are assumed to
- be far away, the compiler will use the `call' instruction to call
- a function and the `rtc' instruction for returning.
-
-`-mshort'
- Consider type `int' to be 16 bits wide, like `short int'.
-
-`-msoft-reg-count=COUNT'
- Specify the number of pseudo-soft registers which are used for the
- code generation. The maximum number is 32. Using more pseudo-soft
- register may or may not result in better code depending on the
- program. The default is 4 for 68HC11 and 2 for 68HC12.
-
-
-
-File: gcc.info, Node: MCore Options, Next: MeP Options, Prev: M68hc1x Options, Up: Submodel Options
-
-3.17.24 MCore Options
----------------------
-
-These are the `-m' options defined for the Motorola M*Core processors.
-
-`-mhardlit'
-`-mno-hardlit'
- Inline constants into the code stream if it can be done in two
- instructions or less.
-
-`-mdiv'
-`-mno-div'
- Use the divide instruction. (Enabled by default).
-
-`-mrelax-immediate'
-`-mno-relax-immediate'
- Allow arbitrary sized immediates in bit operations.
-
-`-mwide-bitfields'
-`-mno-wide-bitfields'
- Always treat bit-fields as int-sized.
-
-`-m4byte-functions'
-`-mno-4byte-functions'
- Force all functions to be aligned to a four byte boundary.
-
-`-mcallgraph-data'
-`-mno-callgraph-data'
- Emit callgraph information.
-
-`-mslow-bytes'
-`-mno-slow-bytes'
- Prefer word access when reading byte quantities.
-
-`-mlittle-endian'
-`-mbig-endian'
- Generate code for a little endian target.
-
-`-m210'
-`-m340'
- Generate code for the 210 processor.
-
-`-mno-lsim'
- Assume that run-time support has been provided and so omit the
- simulator library (`libsim.a)' from the linker command line.
-
-`-mstack-increment=SIZE'
- Set the maximum amount for a single stack increment operation.
- Large values can increase the speed of programs which contain
- functions that need a large amount of stack space, but they can
- also trigger a segmentation fault if the stack is extended too
- much. The default value is 0x1000.
-
-
-
-File: gcc.info, Node: MeP Options, Next: MicroBlaze Options, Prev: MCore Options, Up: Submodel Options
-
-3.17.25 MeP Options
--------------------
-
-`-mabsdiff'
- Enables the `abs' instruction, which is the absolute difference
- between two registers.
-
-`-mall-opts'
- Enables all the optional instructions - average, multiply, divide,
- bit operations, leading zero, absolute difference, min/max, clip,
- and saturation.
-
-`-maverage'
- Enables the `ave' instruction, which computes the average of two
- registers.
-
-`-mbased=N'
- Variables of size N bytes or smaller will be placed in the
- `.based' section by default. Based variables use the `$tp'
- register as a base register, and there is a 128 byte limit to the
- `.based' section.
-
-`-mbitops'
- Enables the bit operation instructions - bit test (`btstm'), set
- (`bsetm'), clear (`bclrm'), invert (`bnotm'), and test-and-set
- (`tas').
-
-`-mc=NAME'
- Selects which section constant data will be placed in. NAME may
- be `tiny', `near', or `far'.
-
-`-mclip'
- Enables the `clip' instruction. Note that `-mclip' is not useful
- unless you also provide `-mminmax'.
-
-`-mconfig=NAME'
- Selects one of the build-in core configurations. Each MeP chip has
- one or more modules in it; each module has a core CPU and a
- variety of coprocessors, optional instructions, and peripherals.
- The `MeP-Integrator' tool, not part of GCC, provides these
- configurations through this option; using this option is the same
- as using all the corresponding command line options. The default
- configuration is `default'.
-
-`-mcop'
- Enables the coprocessor instructions. By default, this is a 32-bit
- coprocessor. Note that the coprocessor is normally enabled via the
- `-mconfig=' option.
-
-`-mcop32'
- Enables the 32-bit coprocessor's instructions.
-
-`-mcop64'
- Enables the 64-bit coprocessor's instructions.
-
-`-mivc2'
- Enables IVC2 scheduling. IVC2 is a 64-bit VLIW coprocessor.
-
-`-mdc'
- Causes constant variables to be placed in the `.near' section.
-
-`-mdiv'
- Enables the `div' and `divu' instructions.
-
-`-meb'
- Generate big-endian code.
-
-`-mel'
- Generate little-endian code.
-
-`-mio-volatile'
- Tells the compiler that any variable marked with the `io'
- attribute is to be considered volatile.
-
-`-ml'
- Causes variables to be assigned to the `.far' section by default.
-
-`-mleadz'
- Enables the `leadz' (leading zero) instruction.
-
-`-mm'
- Causes variables to be assigned to the `.near' section by default.
-
-`-mminmax'
- Enables the `min' and `max' instructions.
-
-`-mmult'
- Enables the multiplication and multiply-accumulate instructions.
-
-`-mno-opts'
- Disables all the optional instructions enabled by `-mall-opts'.
-
-`-mrepeat'
- Enables the `repeat' and `erepeat' instructions, used for
- low-overhead looping.
-
-`-ms'
- Causes all variables to default to the `.tiny' section. Note that
- there is a 65536 byte limit to this section. Accesses to these
- variables use the `%gp' base register.
-
-`-msatur'
- Enables the saturation instructions. Note that the compiler does
- not currently generate these itself, but this option is included
- for compatibility with other tools, like `as'.
-
-`-msdram'
- Link the SDRAM-based runtime instead of the default ROM-based
- runtime.
-
-`-msim'
- Link the simulator runtime libraries.
-
-`-msimnovec'
- Link the simulator runtime libraries, excluding built-in support
- for reset and exception vectors and tables.
-
-`-mtf'
- Causes all functions to default to the `.far' section. Without
- this option, functions default to the `.near' section.
-
-`-mtiny=N'
- Variables that are N bytes or smaller will be allocated to the
- `.tiny' section. These variables use the `$gp' base register.
- The default for this option is 4, but note that there's a 65536
- byte limit to the `.tiny' section.
-
-
-
-File: gcc.info, Node: MicroBlaze Options, Next: MIPS Options, Prev: MeP Options, Up: Submodel Options
-
-3.17.26 MicroBlaze Options
---------------------------
-
-`-msoft-float'
- Use software emulation for floating point (default).
-
-`-mhard-float'
- Use hardware floating point instructions.
-
-`-mmemcpy'
- Do not optimize block moves, use `memcpy'.
-
-`-mno-clearbss'
- This option is deprecated. Use `-fno-zero-initialized-in-bss'
- instead.
-
-`-mcpu=CPU-TYPE'
- Use features of and schedule code for given CPU. Supported values
- are in the format `vX.YY.Z', where X is a major version, YY is the
- minor version, and Z is compatibility code. Example values are
- `v3.00.a', `v4.00.b', `v5.00.a', `v5.00.b', `v5.00.b', `v6.00.a'.
-
-`-mxl-soft-mul'
- Use software multiply emulation (default).
-
-`-mxl-soft-div'
- Use software emulation for divides (default).
-
-`-mxl-barrel-shift'
- Use the hardware barrel shifter.
-
-`-mxl-pattern-compare'
- Use pattern compare instructions.
-
-`-msmall-divides'
- Use table lookup optimization for small signed integer divisions.
-
-`-mxl-stack-check'
- This option is deprecated. Use -fstack-check instead.
-
-`-mxl-gp-opt'
- Use GP relative sdata/sbss sections.
-
-`-mxl-multiply-high'
- Use multiply high instructions for high part of 32x32 multiply.
-
-`-mxl-float-convert'
- Use hardware floating point conversion instructions.
-
-`-mxl-float-sqrt'
- Use hardware floating point square root instruction.
-
-`-mxl-mode-APP-MODEL'
- Select application model APP-MODEL. Valid models are
- `executable'
- normal executable (default), uses startup code `crt0.o'.
-
- `xmdstub'
- for use with Xilinx Microprocessor Debugger (XMD) based
- software intrusive debug agent called xmdstub. This uses
- startup file `crt1.o' and sets the start address of the
- program to be 0x800.
-
- `bootstrap'
- for applications that are loaded using a bootloader. This
- model uses startup file `crt2.o' which does not contain a
- processor reset vector handler. This is suitable for
- transferring control on a processor reset to the bootloader
- rather than the application.
-
- `novectors'
- for applications that do not require any of the MicroBlaze
- vectors. This option may be useful for applications running
- within a monitoring application. This model uses `crt3.o' as
- a startup file.
-
- Option `-xl-mode-APP-MODEL' is a deprecated alias for
- `-mxl-mode-APP-MODEL'.
-
-
-
-File: gcc.info, Node: MIPS Options, Next: MMIX Options, Prev: MicroBlaze Options, Up: Submodel Options
-
-3.17.27 MIPS Options
---------------------
-
-`-EB'
- Generate big-endian code.
-
-`-EL'
- Generate little-endian code. This is the default for `mips*el-*-*'
- configurations.
-
-`-march=ARCH'
- Generate code that will run on ARCH, which can be the name of a
- generic MIPS ISA, or the name of a particular processor. The ISA
- names are: `mips1', `mips2', `mips3', `mips4', `mips32',
- `mips32r2', `mips64' and `mips64r2'. The processor names are:
- `4kc', `4km', `4kp', `4ksc', `4kec', `4kem', `4kep', `4ksd',
- `5kc', `5kf', `20kc', `24kc', `24kf2_1', `24kf1_1', `24kec',
- `24kef2_1', `24kef1_1', `34kc', `34kf2_1', `34kf1_1', `74kc',
- `74kf2_1', `74kf1_1', `74kf3_2', `1004kc', `1004kf2_1',
- `1004kf1_1', `loongson2e', `loongson2f', `loongson3a', `m4k',
- `octeon', `orion', `r2000', `r3000', `r3900', `r4000', `r4400',
- `r4600', `r4650', `r6000', `r8000', `rm7000', `rm9000', `r10000',
- `r12000', `r14000', `r16000', `sb1', `sr71000', `vr4100',
- `vr4111', `vr4120', `vr4130', `vr4300', `vr5000', `vr5400',
- `vr5500' and `xlr'. The special value `from-abi' selects the most
- compatible architecture for the selected ABI (that is, `mips1' for
- 32-bit ABIs and `mips3' for 64-bit ABIs).
-
- Native Linux/GNU toolchains also support the value `native', which
- selects the best architecture option for the host processor.
- `-march=native' has no effect if GCC does not recognize the
- processor.
-
- In processor names, a final `000' can be abbreviated as `k' (for
- example, `-march=r2k'). Prefixes are optional, and `vr' may be
- written `r'.
-
- Names of the form `Nf2_1' refer to processors with FPUs clocked at
- half the rate of the core, names of the form `Nf1_1' refer to
- processors with FPUs clocked at the same rate as the core, and
- names of the form `Nf3_2' refer to processors with FPUs clocked a
- ratio of 3:2 with respect to the core. For compatibility reasons,
- `Nf' is accepted as a synonym for `Nf2_1' while `Nx' and `Bfx' are
- accepted as synonyms for `Nf1_1'.
-
- GCC defines two macros based on the value of this option. The
- first is `_MIPS_ARCH', which gives the name of target
- architecture, as a string. The second has the form
- `_MIPS_ARCH_FOO', where FOO is the capitalized value of
- `_MIPS_ARCH'. For example, `-march=r2000' will set `_MIPS_ARCH'
- to `"r2000"' and define the macro `_MIPS_ARCH_R2000'.
-
- Note that the `_MIPS_ARCH' macro uses the processor names given
- above. In other words, it will have the full prefix and will not
- abbreviate `000' as `k'. In the case of `from-abi', the macro
- names the resolved architecture (either `"mips1"' or `"mips3"').
- It names the default architecture when no `-march' option is given.
-
-`-mtune=ARCH'
- Optimize for ARCH. Among other things, this option controls the
- way instructions are scheduled, and the perceived cost of
- arithmetic operations. The list of ARCH values is the same as for
- `-march'.
-
- When this option is not used, GCC will optimize for the processor
- specified by `-march'. By using `-march' and `-mtune' together,
- it is possible to generate code that will run on a family of
- processors, but optimize the code for one particular member of
- that family.
-
- `-mtune' defines the macros `_MIPS_TUNE' and `_MIPS_TUNE_FOO',
- which work in the same way as the `-march' ones described above.
-
-`-mips1'
- Equivalent to `-march=mips1'.
-
-`-mips2'
- Equivalent to `-march=mips2'.
-
-`-mips3'
- Equivalent to `-march=mips3'.
-
-`-mips4'
- Equivalent to `-march=mips4'.
-
-`-mips32'
- Equivalent to `-march=mips32'.
-
-`-mips32r2'
- Equivalent to `-march=mips32r2'.
-
-`-mips64'
- Equivalent to `-march=mips64'.
-
-`-mips64r2'
- Equivalent to `-march=mips64r2'.
-
-`-mips16'
-`-mno-mips16'
- Generate (do not generate) MIPS16 code. If GCC is targetting a
- MIPS32 or MIPS64 architecture, it will make use of the MIPS16e ASE.
-
- MIPS16 code generation can also be controlled on a per-function
- basis by means of `mips16' and `nomips16' attributes. *Note
- Function Attributes::, for more information.
-
-`-mflip-mips16'
- Generate MIPS16 code on alternating functions. This option is
- provided for regression testing of mixed MIPS16/non-MIPS16 code
- generation, and is not intended for ordinary use in compiling user
- code.
-
-`-minterlink-mips16'
-`-mno-interlink-mips16'
- Require (do not require) that non-MIPS16 code be link-compatible
- with MIPS16 code.
-
- For example, non-MIPS16 code cannot jump directly to MIPS16 code;
- it must either use a call or an indirect jump.
- `-minterlink-mips16' therefore disables direct jumps unless GCC
- knows that the target of the jump is not MIPS16.
-
-`-mabi=32'
-`-mabi=o64'
-`-mabi=n32'
-`-mabi=64'
-`-mabi=eabi'
- Generate code for the given ABI.
-
- Note that the EABI has a 32-bit and a 64-bit variant. GCC normally
- generates 64-bit code when you select a 64-bit architecture, but
- you can use `-mgp32' to get 32-bit code instead.
-
- For information about the O64 ABI, see
- `http://gcc.gnu.org/projects/mipso64-abi.html'.
-
- GCC supports a variant of the o32 ABI in which floating-point
- registers are 64 rather than 32 bits wide. You can select this
- combination with `-mabi=32' `-mfp64'. This ABI relies on the
- `mthc1' and `mfhc1' instructions and is therefore only supported
- for MIPS32R2 processors.
-
- The register assignments for arguments and return values remain the
- same, but each scalar value is passed in a single 64-bit register
- rather than a pair of 32-bit registers. For example, scalar
- floating-point values are returned in `$f0' only, not a
- `$f0'/`$f1' pair. The set of call-saved registers also remains
- the same, but all 64 bits are saved.
-
-`-mabicalls'
-`-mno-abicalls'
- Generate (do not generate) code that is suitable for SVR4-style
- dynamic objects. `-mabicalls' is the default for SVR4-based
- systems.
-
-`-mshared'
-`-mno-shared'
- Generate (do not generate) code that is fully position-independent,
- and that can therefore be linked into shared libraries. This
- option only affects `-mabicalls'.
-
- All `-mabicalls' code has traditionally been position-independent,
- regardless of options like `-fPIC' and `-fpic'. However, as an
- extension, the GNU toolchain allows executables to use absolute
- accesses for locally-binding symbols. It can also use shorter GP
- initialization sequences and generate direct calls to
- locally-defined functions. This mode is selected by `-mno-shared'.
-
- `-mno-shared' depends on binutils 2.16 or higher and generates
- objects that can only be linked by the GNU linker. However, the
- option does not affect the ABI of the final executable; it only
- affects the ABI of relocatable objects. Using `-mno-shared' will
- generally make executables both smaller and quicker.
-
- `-mshared' is the default.
-
-`-mplt'
-`-mno-plt'
- Assume (do not assume) that the static and dynamic linkers support
- PLTs and copy relocations. This option only affects `-mno-shared
- -mabicalls'. For the n64 ABI, this option has no effect without
- `-msym32'.
-
- You can make `-mplt' the default by configuring GCC with
- `--with-mips-plt'. The default is `-mno-plt' otherwise.
-
-`-mxgot'
-`-mno-xgot'
- Lift (do not lift) the usual restrictions on the size of the global
- offset table.
-
- GCC normally uses a single instruction to load values from the GOT.
- While this is relatively efficient, it will only work if the GOT
- is smaller than about 64k. Anything larger will cause the linker
- to report an error such as:
-
- relocation truncated to fit: R_MIPS_GOT16 foobar
-
- If this happens, you should recompile your code with `-mxgot'. It
- should then work with very large GOTs, although it will also be
- less efficient, since it will take three instructions to fetch the
- value of a global symbol.
-
- Note that some linkers can create multiple GOTs. If you have such
- a linker, you should only need to use `-mxgot' when a single object
- file accesses more than 64k's worth of GOT entries. Very few do.
-
- These options have no effect unless GCC is generating position
- independent code.
-
-`-mgp32'
- Assume that general-purpose registers are 32 bits wide.
-
-`-mgp64'
- Assume that general-purpose registers are 64 bits wide.
-
-`-mfp32'
- Assume that floating-point registers are 32 bits wide.
-
-`-mfp64'
- Assume that floating-point registers are 64 bits wide.
-
-`-mhard-float'
- Use floating-point coprocessor instructions.
-
-`-msoft-float'
- Do not use floating-point coprocessor instructions. Implement
- floating-point calculations using library calls instead.
-
-`-msingle-float'
- Assume that the floating-point coprocessor only supports
- single-precision operations.
-
-`-mdouble-float'
- Assume that the floating-point coprocessor supports
- double-precision operations. This is the default.
-
-`-mllsc'
-`-mno-llsc'
- Use (do not use) `ll', `sc', and `sync' instructions to implement
- atomic memory built-in functions. When neither option is
- specified, GCC will use the instructions if the target architecture
- supports them.
-
- `-mllsc' is useful if the runtime environment can emulate the
- instructions and `-mno-llsc' can be useful when compiling for
- nonstandard ISAs. You can make either option the default by
- configuring GCC with `--with-llsc' and `--without-llsc'
- respectively. `--with-llsc' is the default for some
- configurations; see the installation documentation for details.
-
-`-mdsp'
-`-mno-dsp'
- Use (do not use) revision 1 of the MIPS DSP ASE. *Note MIPS DSP
- Built-in Functions::. This option defines the preprocessor macro
- `__mips_dsp'. It also defines `__mips_dsp_rev' to 1.
-
-`-mdspr2'
-`-mno-dspr2'
- Use (do not use) revision 2 of the MIPS DSP ASE. *Note MIPS DSP
- Built-in Functions::. This option defines the preprocessor macros
- `__mips_dsp' and `__mips_dspr2'. It also defines `__mips_dsp_rev'
- to 2.
-
-`-msmartmips'
-`-mno-smartmips'
- Use (do not use) the MIPS SmartMIPS ASE.
-
-`-mpaired-single'
-`-mno-paired-single'
- Use (do not use) paired-single floating-point instructions. *Note
- MIPS Paired-Single Support::. This option requires hardware
- floating-point support to be enabled.
-
-`-mdmx'
-`-mno-mdmx'
- Use (do not use) MIPS Digital Media Extension instructions. This
- option can only be used when generating 64-bit code and requires
- hardware floating-point support to be enabled.
-
-`-mips3d'
-`-mno-mips3d'
- Use (do not use) the MIPS-3D ASE. *Note MIPS-3D Built-in
- Functions::. The option `-mips3d' implies `-mpaired-single'.
-
-`-mmt'
-`-mno-mt'
- Use (do not use) MT Multithreading instructions.
-
-`-mlong64'
- Force `long' types to be 64 bits wide. See `-mlong32' for an
- explanation of the default and the way that the pointer size is
- determined.
-
-`-mlong32'
- Force `long', `int', and pointer types to be 32 bits wide.
-
- The default size of `int's, `long's and pointers depends on the
- ABI. All the supported ABIs use 32-bit `int's. The n64 ABI uses
- 64-bit `long's, as does the 64-bit EABI; the others use 32-bit
- `long's. Pointers are the same size as `long's, or the same size
- as integer registers, whichever is smaller.
-
-`-msym32'
-`-mno-sym32'
- Assume (do not assume) that all symbols have 32-bit values,
- regardless of the selected ABI. This option is useful in
- combination with `-mabi=64' and `-mno-abicalls' because it allows
- GCC to generate shorter and faster references to symbolic
- addresses.
-
-`-G NUM'
- Put definitions of externally-visible data in a small data section
- if that data is no bigger than NUM bytes. GCC can then access the
- data more efficiently; see `-mgpopt' for details.
-
- The default `-G' option depends on the configuration.
-
-`-mlocal-sdata'
-`-mno-local-sdata'
- Extend (do not extend) the `-G' behavior to local data too, such
- as to static variables in C. `-mlocal-sdata' is the default for
- all configurations.
-
- If the linker complains that an application is using too much
- small data, you might want to try rebuilding the less
- performance-critical parts with `-mno-local-sdata'. You might
- also want to build large libraries with `-mno-local-sdata', so
- that the libraries leave more room for the main program.
-
-`-mextern-sdata'
-`-mno-extern-sdata'
- Assume (do not assume) that externally-defined data will be in a
- small data section if that data is within the `-G' limit.
- `-mextern-sdata' is the default for all configurations.
-
- If you compile a module MOD with `-mextern-sdata' `-G NUM'
- `-mgpopt', and MOD references a variable VAR that is no bigger
- than NUM bytes, you must make sure that VAR is placed in a small
- data section. If VAR is defined by another module, you must
- either compile that module with a high-enough `-G' setting or
- attach a `section' attribute to VAR's definition. If VAR is
- common, you must link the application with a high-enough `-G'
- setting.
-
- The easiest way of satisfying these restrictions is to compile and
- link every module with the same `-G' option. However, you may
- wish to build a library that supports several different small data
- limits. You can do this by compiling the library with the highest
- supported `-G' setting and additionally using `-mno-extern-sdata'
- to stop the library from making assumptions about
- externally-defined data.
-
-`-mgpopt'
-`-mno-gpopt'
- Use (do not use) GP-relative accesses for symbols that are known
- to be in a small data section; see `-G', `-mlocal-sdata' and
- `-mextern-sdata'. `-mgpopt' is the default for all configurations.
-
- `-mno-gpopt' is useful for cases where the `$gp' register might
- not hold the value of `_gp'. For example, if the code is part of
- a library that might be used in a boot monitor, programs that call
- boot monitor routines will pass an unknown value in `$gp'. (In
- such situations, the boot monitor itself would usually be compiled
- with `-G0'.)
-
- `-mno-gpopt' implies `-mno-local-sdata' and `-mno-extern-sdata'.
-
-`-membedded-data'
-`-mno-embedded-data'
- Allocate variables to the read-only data section first if
- possible, then next in the small data section if possible,
- otherwise in data. This gives slightly slower code than the
- default, but reduces the amount of RAM required when executing,
- and thus may be preferred for some embedded systems.
-
-`-muninit-const-in-rodata'
-`-mno-uninit-const-in-rodata'
- Put uninitialized `const' variables in the read-only data section.
- This option is only meaningful in conjunction with
- `-membedded-data'.
-
-`-mcode-readable=SETTING'
- Specify whether GCC may generate code that reads from executable
- sections. There are three possible settings:
-
- `-mcode-readable=yes'
- Instructions may freely access executable sections. This is
- the default setting.
-
- `-mcode-readable=pcrel'
- MIPS16 PC-relative load instructions can access executable
- sections, but other instructions must not do so. This option
- is useful on 4KSc and 4KSd processors when the code TLBs have
- the Read Inhibit bit set. It is also useful on processors
- that can be configured to have a dual instruction/data SRAM
- interface and that, like the M4K, automatically redirect
- PC-relative loads to the instruction RAM.
-
- `-mcode-readable=no'
- Instructions must not access executable sections. This
- option can be useful on targets that are configured to have a
- dual instruction/data SRAM interface but that (unlike the
- M4K) do not automatically redirect PC-relative loads to the
- instruction RAM.
-
-`-msplit-addresses'
-`-mno-split-addresses'
- Enable (disable) use of the `%hi()' and `%lo()' assembler
- relocation operators. This option has been superseded by
- `-mexplicit-relocs' but is retained for backwards compatibility.
-
-`-mexplicit-relocs'
-`-mno-explicit-relocs'
- Use (do not use) assembler relocation operators when dealing with
- symbolic addresses. The alternative, selected by
- `-mno-explicit-relocs', is to use assembler macros instead.
-
- `-mexplicit-relocs' is the default if GCC was configured to use an
- assembler that supports relocation operators.
-
-`-mcheck-zero-division'
-`-mno-check-zero-division'
- Trap (do not trap) on integer division by zero.
-
- The default is `-mcheck-zero-division'.
-
-`-mdivide-traps'
-`-mdivide-breaks'
- MIPS systems check for division by zero by generating either a
- conditional trap or a break instruction. Using traps results in
- smaller code, but is only supported on MIPS II and later. Also,
- some versions of the Linux kernel have a bug that prevents trap
- from generating the proper signal (`SIGFPE'). Use
- `-mdivide-traps' to allow conditional traps on architectures that
- support them and `-mdivide-breaks' to force the use of breaks.
-
- The default is usually `-mdivide-traps', but this can be
- overridden at configure time using `--with-divide=breaks'.
- Divide-by-zero checks can be completely disabled using
- `-mno-check-zero-division'.
-
-`-mmemcpy'
-`-mno-memcpy'
- Force (do not force) the use of `memcpy()' for non-trivial block
- moves. The default is `-mno-memcpy', which allows GCC to inline
- most constant-sized copies.
-
-`-mlong-calls'
-`-mno-long-calls'
- Disable (do not disable) use of the `jal' instruction. Calling
- functions using `jal' is more efficient but requires the caller
- and callee to be in the same 256 megabyte segment.
-
- This option has no effect on abicalls code. The default is
- `-mno-long-calls'.
-
-`-mmad'
-`-mno-mad'
- Enable (disable) use of the `mad', `madu' and `mul' instructions,
- as provided by the R4650 ISA.
-
-`-mfused-madd'
-`-mno-fused-madd'
- Enable (disable) use of the floating point multiply-accumulate
- instructions, when they are available. The default is
- `-mfused-madd'.
-
- When multiply-accumulate instructions are used, the intermediate
- product is calculated to infinite precision and is not subject to
- the FCSR Flush to Zero bit. This may be undesirable in some
- circumstances.
-
-`-nocpp'
- Tell the MIPS assembler to not run its preprocessor over user
- assembler files (with a `.s' suffix) when assembling them.
-
-`-mfix-r4000'
-`-mno-fix-r4000'
- Work around certain R4000 CPU errata:
- - A double-word or a variable shift may give an incorrect
- result if executed immediately after starting an integer
- division.
-
- - A double-word or a variable shift may give an incorrect
- result if executed while an integer multiplication is in
- progress.
-
- - An integer division may give an incorrect result if started
- in a delay slot of a taken branch or a jump.
-
-`-mfix-r4400'
-`-mno-fix-r4400'
- Work around certain R4400 CPU errata:
- - A double-word or a variable shift may give an incorrect
- result if executed immediately after starting an integer
- division.
-
-`-mfix-r10000'
-`-mno-fix-r10000'
- Work around certain R10000 errata:
- - `ll'/`sc' sequences may not behave atomically on revisions
- prior to 3.0. They may deadlock on revisions 2.6 and earlier.
-
- This option can only be used if the target architecture supports
- branch-likely instructions. `-mfix-r10000' is the default when
- `-march=r10000' is used; `-mno-fix-r10000' is the default
- otherwise.
-
-`-mfix-vr4120'
-`-mno-fix-vr4120'
- Work around certain VR4120 errata:
- - `dmultu' does not always produce the correct result.
-
- - `div' and `ddiv' do not always produce the correct result if
- one of the operands is negative.
- The workarounds for the division errata rely on special functions
- in `libgcc.a'. At present, these functions are only provided by
- the `mips64vr*-elf' configurations.
-
- Other VR4120 errata require a nop to be inserted between certain
- pairs of instructions. These errata are handled by the assembler,
- not by GCC itself.
-
-`-mfix-vr4130'
- Work around the VR4130 `mflo'/`mfhi' errata. The workarounds are
- implemented by the assembler rather than by GCC, although GCC will
- avoid using `mflo' and `mfhi' if the VR4130 `macc', `macchi',
- `dmacc' and `dmacchi' instructions are available instead.
-
-`-mfix-sb1'
-`-mno-fix-sb1'
- Work around certain SB-1 CPU core errata. (This flag currently
- works around the SB-1 revision 2 "F1" and "F2" floating point
- errata.)
-
-`-mr10k-cache-barrier=SETTING'
- Specify whether GCC should insert cache barriers to avoid the
- side-effects of speculation on R10K processors.
-
- In common with many processors, the R10K tries to predict the
- outcome of a conditional branch and speculatively executes
- instructions from the "taken" branch. It later aborts these
- instructions if the predicted outcome was wrong. However, on the
- R10K, even aborted instructions can have side effects.
-
- This problem only affects kernel stores and, depending on the
- system, kernel loads. As an example, a speculatively-executed
- store may load the target memory into cache and mark the cache
- line as dirty, even if the store itself is later aborted. If a
- DMA operation writes to the same area of memory before the "dirty"
- line is flushed, the cached data will overwrite the DMA-ed data.
- See the R10K processor manual for a full description, including
- other potential problems.
-
- One workaround is to insert cache barrier instructions before
- every memory access that might be speculatively executed and that
- might have side effects even if aborted.
- `-mr10k-cache-barrier=SETTING' controls GCC's implementation of
- this workaround. It assumes that aborted accesses to any byte in
- the following regions will not have side effects:
-
- 1. the memory occupied by the current function's stack frame;
-
- 2. the memory occupied by an incoming stack argument;
-
- 3. the memory occupied by an object with a link-time-constant
- address.
-
- It is the kernel's responsibility to ensure that speculative
- accesses to these regions are indeed safe.
-
- If the input program contains a function declaration such as:
-
- void foo (void);
-
- then the implementation of `foo' must allow `j foo' and `jal foo'
- to be executed speculatively. GCC honors this restriction for
- functions it compiles itself. It expects non-GCC functions (such
- as hand-written assembly code) to do the same.
-
- The option has three forms:
-
- `-mr10k-cache-barrier=load-store'
- Insert a cache barrier before a load or store that might be
- speculatively executed and that might have side effects even
- if aborted.
-
- `-mr10k-cache-barrier=store'
- Insert a cache barrier before a store that might be
- speculatively executed and that might have side effects even
- if aborted.
-
- `-mr10k-cache-barrier=none'
- Disable the insertion of cache barriers. This is the default
- setting.
-
-`-mflush-func=FUNC'
-`-mno-flush-func'
- Specifies the function to call to flush the I and D caches, or to
- not call any such function. If called, the function must take the
- same arguments as the common `_flush_func()', that is, the address
- of the memory range for which the cache is being flushed, the size
- of the memory range, and the number 3 (to flush both caches). The
- default depends on the target GCC was configured for, but commonly
- is either `_flush_func' or `__cpu_flush'.
-
-`mbranch-cost=NUM'
- Set the cost of branches to roughly NUM "simple" instructions.
- This cost is only a heuristic and is not guaranteed to produce
- consistent results across releases. A zero cost redundantly
- selects the default, which is based on the `-mtune' setting.
-
-`-mbranch-likely'
-`-mno-branch-likely'
- Enable or disable use of Branch Likely instructions, regardless of
- the default for the selected architecture. By default, Branch
- Likely instructions may be generated if they are supported by the
- selected architecture. An exception is for the MIPS32 and MIPS64
- architectures and processors which implement those architectures;
- for those, Branch Likely instructions will not be generated by
- default because the MIPS32 and MIPS64 architectures specifically
- deprecate their use.
-
-`-mfp-exceptions'
-`-mno-fp-exceptions'
- Specifies whether FP exceptions are enabled. This affects how we
- schedule FP instructions for some processors. The default is that
- FP exceptions are enabled.
-
- For instance, on the SB-1, if FP exceptions are disabled, and we
- are emitting 64-bit code, then we can use both FP pipes.
- Otherwise, we can only use one FP pipe.
-
-`-mvr4130-align'
-`-mno-vr4130-align'
- The VR4130 pipeline is two-way superscalar, but can only issue two
- instructions together if the first one is 8-byte aligned. When
- this option is enabled, GCC will align pairs of instructions that
- it thinks should execute in parallel.
-
- This option only has an effect when optimizing for the VR4130. It
- normally makes code faster, but at the expense of making it bigger.
- It is enabled by default at optimization level `-O3'.
-
-`-msynci'
-`-mno-synci'
- Enable (disable) generation of `synci' instructions on
- architectures that support it. The `synci' instructions (if
- enabled) will be generated when `__builtin___clear_cache()' is
- compiled.
-
- This option defaults to `-mno-synci', but the default can be
- overridden by configuring with `--with-synci'.
-
- When compiling code for single processor systems, it is generally
- safe to use `synci'. However, on many multi-core (SMP) systems, it
- will not invalidate the instruction caches on all cores and may
- lead to undefined behavior.
-
-`-mrelax-pic-calls'
-`-mno-relax-pic-calls'
- Try to turn PIC calls that are normally dispatched via register
- `$25' into direct calls. This is only possible if the linker can
- resolve the destination at link-time and if the destination is
- within range for a direct call.
-
- `-mrelax-pic-calls' is the default if GCC was configured to use an
- assembler and a linker that supports the `.reloc' assembly
- directive and `-mexplicit-relocs' is in effect. With
- `-mno-explicit-relocs', this optimization can be performed by the
- assembler and the linker alone without help from the compiler.
-
-`-mmcount-ra-address'
-`-mno-mcount-ra-address'
- Emit (do not emit) code that allows `_mcount' to modify the
- calling function's return address. When enabled, this option
- extends the usual `_mcount' interface with a new RA-ADDRESS
- parameter, which has type `intptr_t *' and is passed in register
- `$12'. `_mcount' can then modify the return address by doing both
- of the following:
- * Returning the new address in register `$31'.
-
- * Storing the new address in `*RA-ADDRESS', if RA-ADDRESS is
- nonnull.
-
- The default is `-mno-mcount-ra-address'.
-
-
-
-File: gcc.info, Node: MMIX Options, Next: MN10300 Options, Prev: MIPS Options, Up: Submodel Options
-
-3.17.28 MMIX Options
---------------------
-
-These options are defined for the MMIX:
-
-`-mlibfuncs'
-`-mno-libfuncs'
- Specify that intrinsic library functions are being compiled,
- passing all values in registers, no matter the size.
-
-`-mepsilon'
-`-mno-epsilon'
- Generate floating-point comparison instructions that compare with
- respect to the `rE' epsilon register.
-
-`-mabi=mmixware'
-`-mabi=gnu'
- Generate code that passes function parameters and return values
- that (in the called function) are seen as registers `$0' and up,
- as opposed to the GNU ABI which uses global registers `$231' and
- up.
-
-`-mzero-extend'
-`-mno-zero-extend'
- When reading data from memory in sizes shorter than 64 bits, use
- (do not use) zero-extending load instructions by default, rather
- than sign-extending ones.
-
-`-mknuthdiv'
-`-mno-knuthdiv'
- Make the result of a division yielding a remainder have the same
- sign as the divisor. With the default, `-mno-knuthdiv', the sign
- of the remainder follows the sign of the dividend. Both methods
- are arithmetically valid, the latter being almost exclusively used.
-
-`-mtoplevel-symbols'
-`-mno-toplevel-symbols'
- Prepend (do not prepend) a `:' to all global symbols, so the
- assembly code can be used with the `PREFIX' assembly directive.
-
-`-melf'
- Generate an executable in the ELF format, rather than the default
- `mmo' format used by the `mmix' simulator.
-
-`-mbranch-predict'
-`-mno-branch-predict'
- Use (do not use) the probable-branch instructions, when static
- branch prediction indicates a probable branch.
-
-`-mbase-addresses'
-`-mno-base-addresses'
- Generate (do not generate) code that uses _base addresses_. Using
- a base address automatically generates a request (handled by the
- assembler and the linker) for a constant to be set up in a global
- register. The register is used for one or more base address
- requests within the range 0 to 255 from the value held in the
- register. The generally leads to short and fast code, but the
- number of different data items that can be addressed is limited.
- This means that a program that uses lots of static data may
- require `-mno-base-addresses'.
-
-`-msingle-exit'
-`-mno-single-exit'
- Force (do not force) generated code to have a single exit point in
- each function.
-
-
-File: gcc.info, Node: MN10300 Options, Next: PDP-11 Options, Prev: MMIX Options, Up: Submodel Options
-
-3.17.29 MN10300 Options
------------------------
-
-These `-m' options are defined for Matsushita MN10300 architectures:
-
-`-mmult-bug'
- Generate code to avoid bugs in the multiply instructions for the
- MN10300 processors. This is the default.
-
-`-mno-mult-bug'
- Do not generate code to avoid bugs in the multiply instructions
- for the MN10300 processors.
-
-`-mam33'
- Generate code which uses features specific to the AM33 processor.
-
-`-mno-am33'
- Do not generate code which uses features specific to the AM33
- processor. This is the default.
-
-`-mam33-2'
- Generate code which uses features specific to the AM33/2.0
- processor.
-
-`-mam34'
- Generate code which uses features specific to the AM34 processor.
-
-`-mtune=CPU-TYPE'
- Use the timing characteristics of the indicated CPU type when
- scheduling instructions. This does not change the targeted
- processor type. The CPU type must be one of `mn10300', `am33',
- `am33-2' or `am34'.
-
-`-mreturn-pointer-on-d0'
- When generating a function which returns a pointer, return the
- pointer in both `a0' and `d0'. Otherwise, the pointer is returned
- only in a0, and attempts to call such functions without a prototype
- would result in errors. Note that this option is on by default;
- use `-mno-return-pointer-on-d0' to disable it.
-
-`-mno-crt0'
- Do not link in the C run-time initialization object file.
-
-`-mrelax'
- Indicate to the linker that it should perform a relaxation
- optimization pass to shorten branches, calls and absolute memory
- addresses. This option only has an effect when used on the
- command line for the final link step.
-
- This option makes symbolic debugging impossible.
-
-`-mliw'
- Allow the compiler to generate _Long Instruction Word_
- instructions if the target is the `AM33' or later. This is the
- default. This option defines the preprocessor macro `__LIW__'.
-
-`-mnoliw'
- Do not allow the compiler to generate _Long Instruction Word_
- instructions. This option defines the preprocessor macro
- `__NO_LIW__'.
-
-
-
-File: gcc.info, Node: PDP-11 Options, Next: picoChip Options, Prev: MN10300 Options, Up: Submodel Options
-
-3.17.30 PDP-11 Options
-----------------------
-
-These options are defined for the PDP-11:
-
-`-mfpu'
- Use hardware FPP floating point. This is the default. (FIS
- floating point on the PDP-11/40 is not supported.)
-
-`-msoft-float'
- Do not use hardware floating point.
-
-`-mac0'
- Return floating-point results in ac0 (fr0 in Unix assembler
- syntax).
-
-`-mno-ac0'
- Return floating-point results in memory. This is the default.
-
-`-m40'
- Generate code for a PDP-11/40.
-
-`-m45'
- Generate code for a PDP-11/45. This is the default.
-
-`-m10'
- Generate code for a PDP-11/10.
-
-`-mbcopy-builtin'
- Use inline `movmemhi' patterns for copying memory. This is the
- default.
-
-`-mbcopy'
- Do not use inline `movmemhi' patterns for copying memory.
-
-`-mint16'
-`-mno-int32'
- Use 16-bit `int'. This is the default.
-
-`-mint32'
-`-mno-int16'
- Use 32-bit `int'.
-
-`-mfloat64'
-`-mno-float32'
- Use 64-bit `float'. This is the default.
-
-`-mfloat32'
-`-mno-float64'
- Use 32-bit `float'.
-
-`-mabshi'
- Use `abshi2' pattern. This is the default.
-
-`-mno-abshi'
- Do not use `abshi2' pattern.
-
-`-mbranch-expensive'
- Pretend that branches are expensive. This is for experimenting
- with code generation only.
-
-`-mbranch-cheap'
- Do not pretend that branches are expensive. This is the default.
-
-`-munix-asm'
- Use Unix assembler syntax. This is the default when configured for
- `pdp11-*-bsd'.
-
-`-mdec-asm'
- Use DEC assembler syntax. This is the default when configured for
- any PDP-11 target other than `pdp11-*-bsd'.
-
-
-File: gcc.info, Node: picoChip Options, Next: PowerPC Options, Prev: PDP-11 Options, Up: Submodel Options
-
-3.17.31 picoChip Options
-------------------------
-
-These `-m' options are defined for picoChip implementations:
-
-`-mae=AE_TYPE'
- Set the instruction set, register set, and instruction scheduling
- parameters for array element type AE_TYPE. Supported values for
- AE_TYPE are `ANY', `MUL', and `MAC'.
-
- `-mae=ANY' selects a completely generic AE type. Code generated
- with this option will run on any of the other AE types. The code
- will not be as efficient as it would be if compiled for a specific
- AE type, and some types of operation (e.g., multiplication) will
- not work properly on all types of AE.
-
- `-mae=MUL' selects a MUL AE type. This is the most useful AE type
- for compiled code, and is the default.
-
- `-mae=MAC' selects a DSP-style MAC AE. Code compiled with this
- option may suffer from poor performance of byte (char)
- manipulation, since the DSP AE does not provide hardware support
- for byte load/stores.
-
-`-msymbol-as-address'
- Enable the compiler to directly use a symbol name as an address in
- a load/store instruction, without first loading it into a
- register. Typically, the use of this option will generate larger
- programs, which run faster than when the option isn't used.
- However, the results vary from program to program, so it is left
- as a user option, rather than being permanently enabled.
-
-`-mno-inefficient-warnings'
- Disables warnings about the generation of inefficient code. These
- warnings can be generated, for example, when compiling code which
- performs byte-level memory operations on the MAC AE type. The MAC
- AE has no hardware support for byte-level memory operations, so
- all byte load/stores must be synthesized from word load/store
- operations. This is inefficient and a warning will be generated
- indicating to the programmer that they should rewrite the code to
- avoid byte operations, or to target an AE type which has the
- necessary hardware support. This option enables the warning to be
- turned off.
-
-
-
-File: gcc.info, Node: PowerPC Options, Next: RS/6000 and PowerPC Options, Prev: picoChip Options, Up: Submodel Options
-
-3.17.32 PowerPC Options
------------------------
-
-These are listed under *Note RS/6000 and PowerPC Options::.
-
-
-File: gcc.info, Node: RS/6000 and PowerPC Options, Next: RX Options, Prev: PowerPC Options, Up: Submodel Options
-
-3.17.33 IBM RS/6000 and PowerPC Options
----------------------------------------
-
-These `-m' options are defined for the IBM RS/6000 and PowerPC:
-`-mpower'
-`-mno-power'
-`-mpower2'
-`-mno-power2'
-`-mpowerpc'
-`-mno-powerpc'
-`-mpowerpc-gpopt'
-`-mno-powerpc-gpopt'
-`-mpowerpc-gfxopt'
-`-mno-powerpc-gfxopt'
-`-mpowerpc64'
-`-mno-powerpc64'
-`-mmfcrf'
-`-mno-mfcrf'
-`-mpopcntb'
-`-mno-popcntb'
-`-mpopcntd'
-`-mno-popcntd'
-`-mfprnd'
-`-mno-fprnd'
-`-mcmpb'
-`-mno-cmpb'
-`-mmfpgpr'
-`-mno-mfpgpr'
-`-mhard-dfp'
-`-mno-hard-dfp'
- GCC supports two related instruction set architectures for the
- RS/6000 and PowerPC. The "POWER" instruction set are those
- instructions supported by the `rios' chip set used in the original
- RS/6000 systems and the "PowerPC" instruction set is the
- architecture of the Freescale MPC5xx, MPC6xx, MPC8xx
- microprocessors, and the IBM 4xx, 6xx, and follow-on
- microprocessors.
-
- Neither architecture is a subset of the other. However there is a
- large common subset of instructions supported by both. An MQ
- register is included in processors supporting the POWER
- architecture.
-
- You use these options to specify which instructions are available
- on the processor you are using. The default value of these
- options is determined when configuring GCC. Specifying the
- `-mcpu=CPU_TYPE' overrides the specification of these options. We
- recommend you use the `-mcpu=CPU_TYPE' option rather than the
- options listed above.
-
- The `-mpower' option allows GCC to generate instructions that are
- found only in the POWER architecture and to use the MQ register.
- Specifying `-mpower2' implies `-power' and also allows GCC to
- generate instructions that are present in the POWER2 architecture
- but not the original POWER architecture.
-
- The `-mpowerpc' option allows GCC to generate instructions that
- are found only in the 32-bit subset of the PowerPC architecture.
- Specifying `-mpowerpc-gpopt' implies `-mpowerpc' and also allows
- GCC to use the optional PowerPC architecture instructions in the
- General Purpose group, including floating-point square root.
- Specifying `-mpowerpc-gfxopt' implies `-mpowerpc' and also allows
- GCC to use the optional PowerPC architecture instructions in the
- Graphics group, including floating-point select.
-
- The `-mmfcrf' option allows GCC to generate the move from
- condition register field instruction implemented on the POWER4
- processor and other processors that support the PowerPC V2.01
- architecture. The `-mpopcntb' option allows GCC to generate the
- popcount and double precision FP reciprocal estimate instruction
- implemented on the POWER5 processor and other processors that
- support the PowerPC V2.02 architecture. The `-mpopcntd' option
- allows GCC to generate the popcount instruction implemented on the
- POWER7 processor and other processors that support the PowerPC
- V2.06 architecture. The `-mfprnd' option allows GCC to generate
- the FP round to integer instructions implemented on the POWER5+
- processor and other processors that support the PowerPC V2.03
- architecture. The `-mcmpb' option allows GCC to generate the
- compare bytes instruction implemented on the POWER6 processor and
- other processors that support the PowerPC V2.05 architecture. The
- `-mmfpgpr' option allows GCC to generate the FP move to/from
- general purpose register instructions implemented on the POWER6X
- processor and other processors that support the extended PowerPC
- V2.05 architecture. The `-mhard-dfp' option allows GCC to
- generate the decimal floating point instructions implemented on
- some POWER processors.
-
- The `-mpowerpc64' option allows GCC to generate the additional
- 64-bit instructions that are found in the full PowerPC64
- architecture and to treat GPRs as 64-bit, doubleword quantities.
- GCC defaults to `-mno-powerpc64'.
-
- If you specify both `-mno-power' and `-mno-powerpc', GCC will use
- only the instructions in the common subset of both architectures
- plus some special AIX common-mode calls, and will not use the MQ
- register. Specifying both `-mpower' and `-mpowerpc' permits GCC
- to use any instruction from either architecture and to allow use
- of the MQ register; specify this for the Motorola MPC601.
-
-`-mnew-mnemonics'
-`-mold-mnemonics'
- Select which mnemonics to use in the generated assembler code.
- With `-mnew-mnemonics', GCC uses the assembler mnemonics defined
- for the PowerPC architecture. With `-mold-mnemonics' it uses the
- assembler mnemonics defined for the POWER architecture.
- Instructions defined in only one architecture have only one
- mnemonic; GCC uses that mnemonic irrespective of which of these
- options is specified.
-
- GCC defaults to the mnemonics appropriate for the architecture in
- use. Specifying `-mcpu=CPU_TYPE' sometimes overrides the value of
- these option. Unless you are building a cross-compiler, you
- should normally not specify either `-mnew-mnemonics' or
- `-mold-mnemonics', but should instead accept the default.
-
-`-mcpu=CPU_TYPE'
- Set architecture type, register usage, choice of mnemonics, and
- instruction scheduling parameters for machine type CPU_TYPE.
- Supported values for CPU_TYPE are `401', `403', `405', `405fp',
- `440', `440fp', `464', `464fp', `476', `476fp', `505', `601',
- `602', `603', `603e', `604', `604e', `620', `630', `740', `7400',
- `7450', `750', `801', `821', `823', `860', `970', `8540', `a2',
- `e300c2', `e300c3', `e500mc', `e500mc64', `ec603e', `G3', `G4',
- `G5', `titan', `power', `power2', `power3', `power4', `power5',
- `power5+', `power6', `power6x', `power7', `common', `powerpc',
- `powerpc64', `rios', `rios1', `rios2', `rsc', and `rs64'.
-
- `-mcpu=common' selects a completely generic processor. Code
- generated under this option will run on any POWER or PowerPC
- processor. GCC will use only the instructions in the common
- subset of both architectures, and will not use the MQ register.
- GCC assumes a generic processor model for scheduling purposes.
-
- `-mcpu=power', `-mcpu=power2', `-mcpu=powerpc', and
- `-mcpu=powerpc64' specify generic POWER, POWER2, pure 32-bit
- PowerPC (i.e., not MPC601), and 64-bit PowerPC architecture machine
- types, with an appropriate, generic processor model assumed for
- scheduling purposes.
-
- The other options specify a specific processor. Code generated
- under those options will run best on that processor, and may not
- run at all on others.
-
- The `-mcpu' options automatically enable or disable the following
- options:
-
- -maltivec -mfprnd -mhard-float -mmfcrf -mmultiple
- -mnew-mnemonics -mpopcntb -mpopcntd -mpower -mpower2 -mpowerpc64
- -mpowerpc-gpopt -mpowerpc-gfxopt -msingle-float -mdouble-float
- -msimple-fpu -mstring -mmulhw -mdlmzb -mmfpgpr -mvsx
-
- The particular options set for any particular CPU will vary between
- compiler versions, depending on what setting seems to produce
- optimal code for that CPU; it doesn't necessarily reflect the
- actual hardware's capabilities. If you wish to set an individual
- option to a particular value, you may specify it after the `-mcpu'
- option, like `-mcpu=970 -mno-altivec'.
-
- On AIX, the `-maltivec' and `-mpowerpc64' options are not enabled
- or disabled by the `-mcpu' option at present because AIX does not
- have full support for these options. You may still enable or
- disable them individually if you're sure it'll work in your
- environment.
-
-`-mtune=CPU_TYPE'
- Set the instruction scheduling parameters for machine type
- CPU_TYPE, but do not set the architecture type, register usage, or
- choice of mnemonics, as `-mcpu=CPU_TYPE' would. The same values
- for CPU_TYPE are used for `-mtune' as for `-mcpu'. If both are
- specified, the code generated will use the architecture,
- registers, and mnemonics set by `-mcpu', but the scheduling
- parameters set by `-mtune'.
-
-`-mcmodel=small'
- Generate PowerPC64 code for the small model: The TOC is limited to
- 64k.
-
-`-mcmodel=medium'
- Generate PowerPC64 code for the medium model: The TOC and other
- static data may be up to a total of 4G in size.
-
-`-mcmodel=large'
- Generate PowerPC64 code for the large model: The TOC may be up to
- 4G in size. Other data and code is only limited by the 64-bit
- address space.
-
-`-maltivec'
-`-mno-altivec'
- Generate code that uses (does not use) AltiVec instructions, and
- also enable the use of built-in functions that allow more direct
- access to the AltiVec instruction set. You may also need to set
- `-mabi=altivec' to adjust the current ABI with AltiVec ABI
- enhancements.
-
-`-mvrsave'
-`-mno-vrsave'
- Generate VRSAVE instructions when generating AltiVec code.
-
-`-mgen-cell-microcode'
- Generate Cell microcode instructions
-
-`-mwarn-cell-microcode'
- Warning when a Cell microcode instruction is going to emitted. An
- example of a Cell microcode instruction is a variable shift.
-
-`-msecure-plt'
- Generate code that allows ld and ld.so to build executables and
- shared libraries with non-exec .plt and .got sections. This is a
- PowerPC 32-bit SYSV ABI option.
-
-`-mbss-plt'
- Generate code that uses a BSS .plt section that ld.so fills in, and
- requires .plt and .got sections that are both writable and
- executable. This is a PowerPC 32-bit SYSV ABI option.
-
-`-misel'
-`-mno-isel'
- This switch enables or disables the generation of ISEL
- instructions.
-
-`-misel=YES/NO'
- This switch has been deprecated. Use `-misel' and `-mno-isel'
- instead.
-
-`-mspe'
-`-mno-spe'
- This switch enables or disables the generation of SPE simd
- instructions.
-
-`-mpaired'
-`-mno-paired'
- This switch enables or disables the generation of PAIRED simd
- instructions.
-
-`-mspe=YES/NO'
- This option has been deprecated. Use `-mspe' and `-mno-spe'
- instead.
-
-`-mvsx'
-`-mno-vsx'
- Generate code that uses (does not use) vector/scalar (VSX)
- instructions, and also enable the use of built-in functions that
- allow more direct access to the VSX instruction set.
-
-`-mfloat-gprs=YES/SINGLE/DOUBLE/NO'
-`-mfloat-gprs'
- This switch enables or disables the generation of floating point
- operations on the general purpose registers for architectures that
- support it.
-
- The argument YES or SINGLE enables the use of single-precision
- floating point operations.
-
- The argument DOUBLE enables the use of single and double-precision
- floating point operations.
-
- The argument NO disables floating point operations on the general
- purpose registers.
-
- This option is currently only available on the MPC854x.
-
-`-m32'
-`-m64'
- Generate code for 32-bit or 64-bit environments of Darwin and SVR4
- targets (including GNU/Linux). The 32-bit environment sets int,
- long and pointer to 32 bits and generates code that runs on any
- PowerPC variant. The 64-bit environment sets int to 32 bits and
- long and pointer to 64 bits, and generates code for PowerPC64, as
- for `-mpowerpc64'.
-
-`-mfull-toc'
-`-mno-fp-in-toc'
-`-mno-sum-in-toc'
-`-mminimal-toc'
- Modify generation of the TOC (Table Of Contents), which is created
- for every executable file. The `-mfull-toc' option is selected by
- default. In that case, GCC will allocate at least one TOC entry
- for each unique non-automatic variable reference in your program.
- GCC will also place floating-point constants in the TOC. However,
- only 16,384 entries are available in the TOC.
-
- If you receive a linker error message that saying you have
- overflowed the available TOC space, you can reduce the amount of
- TOC space used with the `-mno-fp-in-toc' and `-mno-sum-in-toc'
- options. `-mno-fp-in-toc' prevents GCC from putting floating-point
- constants in the TOC and `-mno-sum-in-toc' forces GCC to generate
- code to calculate the sum of an address and a constant at run-time
- instead of putting that sum into the TOC. You may specify one or
- both of these options. Each causes GCC to produce very slightly
- slower and larger code at the expense of conserving TOC space.
-
- If you still run out of space in the TOC even when you specify
- both of these options, specify `-mminimal-toc' instead. This
- option causes GCC to make only one TOC entry for every file. When
- you specify this option, GCC will produce code that is slower and
- larger but which uses extremely little TOC space. You may wish to
- use this option only on files that contain less frequently
- executed code.
-
-`-maix64'
-`-maix32'
- Enable 64-bit AIX ABI and calling convention: 64-bit pointers,
- 64-bit `long' type, and the infrastructure needed to support them.
- Specifying `-maix64' implies `-mpowerpc64' and `-mpowerpc', while
- `-maix32' disables the 64-bit ABI and implies `-mno-powerpc64'.
- GCC defaults to `-maix32'.
-
-`-mxl-compat'
-`-mno-xl-compat'
- Produce code that conforms more closely to IBM XL compiler
- semantics when using AIX-compatible ABI. Pass floating-point
- arguments to prototyped functions beyond the register save area
- (RSA) on the stack in addition to argument FPRs. Do not assume
- that most significant double in 128-bit long double value is
- properly rounded when comparing values and converting to double.
- Use XL symbol names for long double support routines.
-
- The AIX calling convention was extended but not initially
- documented to handle an obscure K&R C case of calling a function
- that takes the address of its arguments with fewer arguments than
- declared. IBM XL compilers access floating point arguments which
- do not fit in the RSA from the stack when a subroutine is compiled
- without optimization. Because always storing floating-point
- arguments on the stack is inefficient and rarely needed, this
- option is not enabled by default and only is necessary when
- calling subroutines compiled by IBM XL compilers without
- optimization.
-
-`-mpe'
- Support "IBM RS/6000 SP" "Parallel Environment" (PE). Link an
- application written to use message passing with special startup
- code to enable the application to run. The system must have PE
- installed in the standard location (`/usr/lpp/ppe.poe/'), or the
- `specs' file must be overridden with the `-specs=' option to
- specify the appropriate directory location. The Parallel
- Environment does not support threads, so the `-mpe' option and the
- `-pthread' option are incompatible.
-
-`-malign-natural'
-`-malign-power'
- On AIX, 32-bit Darwin, and 64-bit PowerPC GNU/Linux, the option
- `-malign-natural' overrides the ABI-defined alignment of larger
- types, such as floating-point doubles, on their natural size-based
- boundary. The option `-malign-power' instructs GCC to follow the
- ABI-specified alignment rules. GCC defaults to the standard
- alignment defined in the ABI.
-
- On 64-bit Darwin, natural alignment is the default, and
- `-malign-power' is not supported.
-
-`-msoft-float'
-`-mhard-float'
- Generate code that does not use (uses) the floating-point register
- set. Software floating point emulation is provided if you use the
- `-msoft-float' option, and pass the option to GCC when linking.
-
-`-msingle-float'
-`-mdouble-float'
- Generate code for single or double-precision floating point
- operations. `-mdouble-float' implies `-msingle-float'.
-
-`-msimple-fpu'
- Do not generate sqrt and div instructions for hardware floating
- point unit.
-
-`-mfpu'
- Specify type of floating point unit. Valid values are SP_LITE
- (equivalent to -msingle-float -msimple-fpu), DP_LITE (equivalent
- to -mdouble-float -msimple-fpu), SP_FULL (equivalent to
- -msingle-float), and DP_FULL (equivalent to -mdouble-float).
-
-`-mxilinx-fpu'
- Perform optimizations for floating point unit on Xilinx PPC
- 405/440.
-
-`-mmultiple'
-`-mno-multiple'
- Generate code that uses (does not use) the load multiple word
- instructions and the store multiple word instructions. These
- instructions are generated by default on POWER systems, and not
- generated on PowerPC systems. Do not use `-mmultiple' on little
- endian PowerPC systems, since those instructions do not work when
- the processor is in little endian mode. The exceptions are PPC740
- and PPC750 which permit the instructions usage in little endian
- mode.
-
-`-mstring'
-`-mno-string'
- Generate code that uses (does not use) the load string instructions
- and the store string word instructions to save multiple registers
- and do small block moves. These instructions are generated by
- default on POWER systems, and not generated on PowerPC systems.
- Do not use `-mstring' on little endian PowerPC systems, since those
- instructions do not work when the processor is in little endian
- mode. The exceptions are PPC740 and PPC750 which permit the
- instructions usage in little endian mode.
-
-`-mupdate'
-`-mno-update'
- Generate code that uses (does not use) the load or store
- instructions that update the base register to the address of the
- calculated memory location. These instructions are generated by
- default. If you use `-mno-update', there is a small window
- between the time that the stack pointer is updated and the address
- of the previous frame is stored, which means code that walks the
- stack frame across interrupts or signals may get corrupted data.
-
-`-mavoid-indexed-addresses'
-`-mno-avoid-indexed-addresses'
- Generate code that tries to avoid (not avoid) the use of indexed
- load or store instructions. These instructions can incur a
- performance penalty on Power6 processors in certain situations,
- such as when stepping through large arrays that cross a 16M
- boundary. This option is enabled by default when targetting
- Power6 and disabled otherwise.
-
-`-mfused-madd'
-`-mno-fused-madd'
- Generate code that uses (does not use) the floating point multiply
- and accumulate instructions. These instructions are generated by
- default if hardware floating point is used. The machine dependent
- `-mfused-madd' option is now mapped to the machine independent
- `-ffp-contract=fast' option, and `-mno-fused-madd' is mapped to
- `-ffp-contract=off'.
-
-`-mmulhw'
-`-mno-mulhw'
- Generate code that uses (does not use) the half-word multiply and
- multiply-accumulate instructions on the IBM 405, 440, 464 and 476
- processors. These instructions are generated by default when
- targetting those processors.
-
-`-mdlmzb'
-`-mno-dlmzb'
- Generate code that uses (does not use) the string-search `dlmzb'
- instruction on the IBM 405, 440, 464 and 476 processors. This
- instruction is generated by default when targetting those
- processors.
-
-`-mno-bit-align'
-`-mbit-align'
- On System V.4 and embedded PowerPC systems do not (do) force
- structures and unions that contain bit-fields to be aligned to the
- base type of the bit-field.
-
- For example, by default a structure containing nothing but 8
- `unsigned' bit-fields of length 1 would be aligned to a 4 byte
- boundary and have a size of 4 bytes. By using `-mno-bit-align',
- the structure would be aligned to a 1 byte boundary and be one
- byte in size.
-
-`-mno-strict-align'
-`-mstrict-align'
- On System V.4 and embedded PowerPC systems do not (do) assume that
- unaligned memory references will be handled by the system.
-
-`-mrelocatable'
-`-mno-relocatable'
- Generate code that allows (does not allow) a static executable to
- be relocated to a different address at runtime. A simple embedded
- PowerPC system loader should relocate the entire contents of
- `.got2' and 4-byte locations listed in the `.fixup' section, a
- table of 32-bit addresses generated by this option. For this to
- work, all objects linked together must be compiled with
- `-mrelocatable' or `-mrelocatable-lib'. `-mrelocatable' code
- aligns the stack to an 8 byte boundary.
-
-`-mrelocatable-lib'
-`-mno-relocatable-lib'
- Like `-mrelocatable', `-mrelocatable-lib' generates a `.fixup'
- section to allow static executables to be relocated at runtime,
- but `-mrelocatable-lib' does not use the smaller stack alignment
- of `-mrelocatable'. Objects compiled with `-mrelocatable-lib' may
- be linked with objects compiled with any combination of the
- `-mrelocatable' options.
-
-`-mno-toc'
-`-mtoc'
- On System V.4 and embedded PowerPC systems do not (do) assume that
- register 2 contains a pointer to a global area pointing to the
- addresses used in the program.
-
-`-mlittle'
-`-mlittle-endian'
- On System V.4 and embedded PowerPC systems compile code for the
- processor in little endian mode. The `-mlittle-endian' option is
- the same as `-mlittle'.
-
-`-mbig'
-`-mbig-endian'
- On System V.4 and embedded PowerPC systems compile code for the
- processor in big endian mode. The `-mbig-endian' option is the
- same as `-mbig'.
-
-`-mdynamic-no-pic'
- On Darwin and Mac OS X systems, compile code so that it is not
- relocatable, but that its external references are relocatable. The
- resulting code is suitable for applications, but not shared
- libraries.
-
-`-msingle-pic-base'
- Treat the register used for PIC addressing as read-only, rather
- than loading it in the prologue for each function. The run-time
- system is responsible for initializing this register with an
- appropriate value before execution begins.
-
-`-mprioritize-restricted-insns=PRIORITY'
- This option controls the priority that is assigned to
- dispatch-slot restricted instructions during the second scheduling
- pass. The argument PRIORITY takes the value 0/1/2 to assign
- NO/HIGHEST/SECOND-HIGHEST priority to dispatch slot restricted
- instructions.
-
-`-msched-costly-dep=DEPENDENCE_TYPE'
- This option controls which dependences are considered costly by
- the target during instruction scheduling. The argument
- DEPENDENCE_TYPE takes one of the following values: NO: no
- dependence is costly, ALL: all dependences are costly,
- TRUE_STORE_TO_LOAD: a true dependence from store to load is costly,
- STORE_TO_LOAD: any dependence from store to load is costly,
- NUMBER: any dependence which latency >= NUMBER is costly.
-
-`-minsert-sched-nops=SCHEME'
- This option controls which nop insertion scheme will be used during
- the second scheduling pass. The argument SCHEME takes one of the
- following values: NO: Don't insert nops. PAD: Pad with nops any
- dispatch group which has vacant issue slots, according to the
- scheduler's grouping. REGROUP_EXACT: Insert nops to force costly
- dependent insns into separate groups. Insert exactly as many nops
- as needed to force an insn to a new group, according to the
- estimated processor grouping. NUMBER: Insert nops to force costly
- dependent insns into separate groups. Insert NUMBER nops to force
- an insn to a new group.
-
-`-mcall-sysv'
- On System V.4 and embedded PowerPC systems compile code using
- calling conventions that adheres to the March 1995 draft of the
- System V Application Binary Interface, PowerPC processor
- supplement. This is the default unless you configured GCC using
- `powerpc-*-eabiaix'.
-
-`-mcall-sysv-eabi'
-`-mcall-eabi'
- Specify both `-mcall-sysv' and `-meabi' options.
-
-`-mcall-sysv-noeabi'
- Specify both `-mcall-sysv' and `-mno-eabi' options.
-
-`-mcall-aixdesc'
- On System V.4 and embedded PowerPC systems compile code for the AIX
- operating system.
-
-`-mcall-linux'
- On System V.4 and embedded PowerPC systems compile code for the
- Linux-based GNU system.
-
-`-mcall-gnu'
- On System V.4 and embedded PowerPC systems compile code for the
- Hurd-based GNU system.
-
-`-mcall-freebsd'
- On System V.4 and embedded PowerPC systems compile code for the
- FreeBSD operating system.
-
-`-mcall-netbsd'
- On System V.4 and embedded PowerPC systems compile code for the
- NetBSD operating system.
-
-`-mcall-openbsd'
- On System V.4 and embedded PowerPC systems compile code for the
- OpenBSD operating system.
-
-`-maix-struct-return'
- Return all structures in memory (as specified by the AIX ABI).
-
-`-msvr4-struct-return'
- Return structures smaller than 8 bytes in registers (as specified
- by the SVR4 ABI).
-
-`-mabi=ABI-TYPE'
- Extend the current ABI with a particular extension, or remove such
- extension. Valid values are ALTIVEC, NO-ALTIVEC, SPE, NO-SPE,
- IBMLONGDOUBLE, IEEELONGDOUBLE.
-
-`-mabi=spe'
- Extend the current ABI with SPE ABI extensions. This does not
- change the default ABI, instead it adds the SPE ABI extensions to
- the current ABI.
-
-`-mabi=no-spe'
- Disable Booke SPE ABI extensions for the current ABI.
-
-`-mabi=ibmlongdouble'
- Change the current ABI to use IBM extended precision long double.
- This is a PowerPC 32-bit SYSV ABI option.
-
-`-mabi=ieeelongdouble'
- Change the current ABI to use IEEE extended precision long double.
- This is a PowerPC 32-bit Linux ABI option.
-
-`-mprototype'
-`-mno-prototype'
- On System V.4 and embedded PowerPC systems assume that all calls to
- variable argument functions are properly prototyped. Otherwise,
- the compiler must insert an instruction before every non
- prototyped call to set or clear bit 6 of the condition code
- register (CR) to indicate whether floating point values were
- passed in the floating point registers in case the function takes
- a variable arguments. With `-mprototype', only calls to
- prototyped variable argument functions will set or clear the bit.
-
-`-msim'
- On embedded PowerPC systems, assume that the startup module is
- called `sim-crt0.o' and that the standard C libraries are
- `libsim.a' and `libc.a'. This is the default for
- `powerpc-*-eabisim' configurations.
-
-`-mmvme'
- On embedded PowerPC systems, assume that the startup module is
- called `crt0.o' and the standard C libraries are `libmvme.a' and
- `libc.a'.
-
-`-mads'
- On embedded PowerPC systems, assume that the startup module is
- called `crt0.o' and the standard C libraries are `libads.a' and
- `libc.a'.
-
-`-myellowknife'
- On embedded PowerPC systems, assume that the startup module is
- called `crt0.o' and the standard C libraries are `libyk.a' and
- `libc.a'.
-
-`-mvxworks'
- On System V.4 and embedded PowerPC systems, specify that you are
- compiling for a VxWorks system.
-
-`-memb'
- On embedded PowerPC systems, set the PPC_EMB bit in the ELF flags
- header to indicate that `eabi' extended relocations are used.
-
-`-meabi'
-`-mno-eabi'
- On System V.4 and embedded PowerPC systems do (do not) adhere to
- the Embedded Applications Binary Interface (eabi) which is a set of
- modifications to the System V.4 specifications. Selecting `-meabi'
- means that the stack is aligned to an 8 byte boundary, a function
- `__eabi' is called to from `main' to set up the eabi environment,
- and the `-msdata' option can use both `r2' and `r13' to point to
- two separate small data areas. Selecting `-mno-eabi' means that
- the stack is aligned to a 16 byte boundary, do not call an
- initialization function from `main', and the `-msdata' option will
- only use `r13' to point to a single small data area. The `-meabi'
- option is on by default if you configured GCC using one of the
- `powerpc*-*-eabi*' options.
-
-`-msdata=eabi'
- On System V.4 and embedded PowerPC systems, put small initialized
- `const' global and static data in the `.sdata2' section, which is
- pointed to by register `r2'. Put small initialized non-`const'
- global and static data in the `.sdata' section, which is pointed
- to by register `r13'. Put small uninitialized global and static
- data in the `.sbss' section, which is adjacent to the `.sdata'
- section. The `-msdata=eabi' option is incompatible with the
- `-mrelocatable' option. The `-msdata=eabi' option also sets the
- `-memb' option.
-
-`-msdata=sysv'
- On System V.4 and embedded PowerPC systems, put small global and
- static data in the `.sdata' section, which is pointed to by
- register `r13'. Put small uninitialized global and static data in
- the `.sbss' section, which is adjacent to the `.sdata' section.
- The `-msdata=sysv' option is incompatible with the `-mrelocatable'
- option.
-
-`-msdata=default'
-`-msdata'
- On System V.4 and embedded PowerPC systems, if `-meabi' is used,
- compile code the same as `-msdata=eabi', otherwise compile code the
- same as `-msdata=sysv'.
-
-`-msdata=data'
- On System V.4 and embedded PowerPC systems, put small global data
- in the `.sdata' section. Put small uninitialized global data in
- the `.sbss' section. Do not use register `r13' to address small
- data however. This is the default behavior unless other `-msdata'
- options are used.
-
-`-msdata=none'
-`-mno-sdata'
- On embedded PowerPC systems, put all initialized global and static
- data in the `.data' section, and all uninitialized data in the
- `.bss' section.
-
-`-mblock-move-inline-limit=NUM'
- Inline all block moves (such as calls to `memcpy' or structure
- copies) less than or equal to NUM bytes. The minimum value for
- NUM is 32 bytes on 32-bit targets and 64 bytes on 64-bit targets.
- The default value is target-specific.
-
-`-G NUM'
- On embedded PowerPC systems, put global and static items less than
- or equal to NUM bytes into the small data or bss sections instead
- of the normal data or bss section. By default, NUM is 8. The `-G
- NUM' switch is also passed to the linker. All modules should be
- compiled with the same `-G NUM' value.
-
-`-mregnames'
-`-mno-regnames'
- On System V.4 and embedded PowerPC systems do (do not) emit
- register names in the assembly language output using symbolic
- forms.
-
-`-mlongcall'
-`-mno-longcall'
- By default assume that all calls are far away so that a longer more
- expensive calling sequence is required. This is required for calls
- further than 32 megabytes (33,554,432 bytes) from the current
- location. A short call will be generated if the compiler knows
- the call cannot be that far away. This setting can be overridden
- by the `shortcall' function attribute, or by `#pragma longcall(0)'.
-
- Some linkers are capable of detecting out-of-range calls and
- generating glue code on the fly. On these systems, long calls are
- unnecessary and generate slower code. As of this writing, the AIX
- linker can do this, as can the GNU linker for PowerPC/64. It is
- planned to add this feature to the GNU linker for 32-bit PowerPC
- systems as well.
-
- On Darwin/PPC systems, `#pragma longcall' will generate "jbsr
- callee, L42", plus a "branch island" (glue code). The two target
- addresses represent the callee and the "branch island". The
- Darwin/PPC linker will prefer the first address and generate a "bl
- callee" if the PPC "bl" instruction will reach the callee directly;
- otherwise, the linker will generate "bl L42" to call the "branch
- island". The "branch island" is appended to the body of the
- calling function; it computes the full 32-bit address of the callee
- and jumps to it.
-
- On Mach-O (Darwin) systems, this option directs the compiler emit
- to the glue for every direct call, and the Darwin linker decides
- whether to use or discard it.
-
- In the future, we may cause GCC to ignore all longcall
- specifications when the linker is known to generate glue.
-
-`-mtls-markers'
-`-mno-tls-markers'
- Mark (do not mark) calls to `__tls_get_addr' with a relocation
- specifying the function argument. The relocation allows ld to
- reliably associate function call with argument setup instructions
- for TLS optimization, which in turn allows gcc to better schedule
- the sequence.
-
-`-pthread'
- Adds support for multithreading with the "pthreads" library. This
- option sets flags for both the preprocessor and linker.
-
-`-mrecip'
-`-mno-recip'
- This option will enable GCC to use the reciprocal estimate and
- reciprocal square root estimate instructions with additional
- Newton-Raphson steps to increase precision instead of doing a
- divide or square root and divide for floating point arguments.
- You should use the `-ffast-math' option when using `-mrecip' (or at
- least `-funsafe-math-optimizations', `-finite-math-only',
- `-freciprocal-math' and `-fno-trapping-math'). Note that while
- the throughput of the sequence is generally higher than the
- throughput of the non-reciprocal instruction, the precision of the
- sequence can be decreased by up to 2 ulp (i.e. the inverse of 1.0
- equals 0.99999994) for reciprocal square roots.
-
-`-mrecip=OPT'
- This option allows to control which reciprocal estimate
- instructions may be used. OPT is a comma separated list of
- options, that may be preceded by a `!' to invert the option:
- `all': enable all estimate instructions, `default': enable the
- default instructions, equivalent to `-mrecip', `none': disable all
- estimate instructions, equivalent to `-mno-recip'; `div': enable
- the reciprocal approximation instructions for both single and
- double precision; `divf': enable the single precision reciprocal
- approximation instructions; `divd': enable the double precision
- reciprocal approximation instructions; `rsqrt': enable the
- reciprocal square root approximation instructions for both single
- and double precision; `rsqrtf': enable the single precision
- reciprocal square root approximation instructions; `rsqrtd':
- enable the double precision reciprocal square root approximation
- instructions;
-
- So for example, `-mrecip=all,!rsqrtd' would enable the all of the
- reciprocal estimate instructions, except for the `FRSQRTE',
- `XSRSQRTEDP', and `XVRSQRTEDP' instructions which handle the
- double precision reciprocal square root calculations.
-
-`-mrecip-precision'
-`-mno-recip-precision'
- Assume (do not assume) that the reciprocal estimate instructions
- provide higher precision estimates than is mandated by the powerpc
- ABI. Selecting `-mcpu=power6' or `-mcpu=power7' automatically
- selects `-mrecip-precision'. The double precision square root
- estimate instructions are not generated by default on low
- precision machines, since they do not provide an estimate that
- converges after three steps.
-
-`-mveclibabi=TYPE'
- Specifies the ABI type to use for vectorizing intrinsics using an
- external library. The only type supported at present is `mass',
- which specifies to use IBM's Mathematical Acceleration Subsystem
- (MASS) libraries for vectorizing intrinsics using external
- libraries. GCC will currently emit calls to `acosd2', `acosf4',
- `acoshd2', `acoshf4', `asind2', `asinf4', `asinhd2', `asinhf4',
- `atan2d2', `atan2f4', `atand2', `atanf4', `atanhd2', `atanhf4',
- `cbrtd2', `cbrtf4', `cosd2', `cosf4', `coshd2', `coshf4',
- `erfcd2', `erfcf4', `erfd2', `erff4', `exp2d2', `exp2f4', `expd2',
- `expf4', `expm1d2', `expm1f4', `hypotd2', `hypotf4', `lgammad2',
- `lgammaf4', `log10d2', `log10f4', `log1pd2', `log1pf4', `log2d2',
- `log2f4', `logd2', `logf4', `powd2', `powf4', `sind2', `sinf4',
- `sinhd2', `sinhf4', `sqrtd2', `sqrtf4', `tand2', `tanf4',
- `tanhd2', and `tanhf4' when generating code for power7. Both
- `-ftree-vectorize' and `-funsafe-math-optimizations' have to be
- enabled. The MASS libraries will have to be specified at link
- time.
-
-`-mfriz'
-`-mno-friz'
- Generate (do not generate) the `friz' instruction when the
- `-funsafe-math-optimizations' option is used to optimize rounding
- a floating point value to 64-bit integer and back to floating
- point. The `friz' instruction does not return the same value if
- the floating point number is too large to fit in an integer.
-
-
-File: gcc.info, Node: RX Options, Next: S/390 and zSeries Options, Prev: RS/6000 and PowerPC Options, Up: Submodel Options
-
-3.17.34 RX Options
-------------------
-
-These command line options are defined for RX targets:
-
-`-m64bit-doubles'
-`-m32bit-doubles'
- Make the `double' data type be 64-bits (`-m64bit-doubles') or
- 32-bits (`-m32bit-doubles') in size. The default is
- `-m32bit-doubles'. _Note_ RX floating point hardware only works
- on 32-bit values, which is why the default is `-m32bit-doubles'.
-
-`-fpu'
-`-nofpu'
- Enables (`-fpu') or disables (`-nofpu') the use of RX floating
- point hardware. The default is enabled for the RX600 series and
- disabled for the RX200 series.
-
- Floating point instructions will only be generated for 32-bit
- floating point values however, so if the `-m64bit-doubles' option
- is in use then the FPU hardware will not be used for doubles.
-
- _Note_ If the `-fpu' option is enabled then
- `-funsafe-math-optimizations' is also enabled automatically. This
- is because the RX FPU instructions are themselves unsafe.
-
-`-mcpu=NAME'
- Selects the type of RX CPU to be targeted. Currently three types
- are supported, the generic RX600 and RX200 series hardware and the
- specific RX610 CPU. The default is RX600.
-
- The only difference between RX600 and RX610 is that the RX610 does
- not support the `MVTIPL' instruction.
-
- The RX200 series does not have a hardware floating point unit and
- so `-nofpu' is enabled by default when this type is selected.
-
-`-mbig-endian-data'
-`-mlittle-endian-data'
- Store data (but not code) in the big-endian format. The default is
- `-mlittle-endian-data', i.e. to store data in the little endian
- format.
-
-`-msmall-data-limit=N'
- Specifies the maximum size in bytes of global and static variables
- which can be placed into the small data area. Using the small data
- area can lead to smaller and faster code, but the size of area is
- limited and it is up to the programmer to ensure that the area does
- not overflow. Also when the small data area is used one of the
- RX's registers (`r13') is reserved for use pointing to this area,
- so it is no longer available for use by the compiler. This could
- result in slower and/or larger code if variables which once could
- have been held in `r13' are now pushed onto the stack.
-
- Note, common variables (variables which have not been initialised)
- and constants are not placed into the small data area as they are
- assigned to other sections in the output executable.
-
- The default value is zero, which disables this feature. Note, this
- feature is not enabled by default with higher optimization levels
- (`-O2' etc) because of the potentially detrimental effects of
- reserving register `r13'. It is up to the programmer to
- experiment and discover whether this feature is of benefit to their
- program.
-
-`-msim'
-`-mno-sim'
- Use the simulator runtime. The default is to use the libgloss
- board specific runtime.
-
-`-mas100-syntax'
-`-mno-as100-syntax'
- When generating assembler output use a syntax that is compatible
- with Renesas's AS100 assembler. This syntax can also be handled
- by the GAS assembler but it has some restrictions so generating it
- is not the default option.
-
-`-mmax-constant-size=N'
- Specifies the maximum size, in bytes, of a constant that can be
- used as an operand in a RX instruction. Although the RX
- instruction set does allow constants of up to 4 bytes in length to
- be used in instructions, a longer value equates to a longer
- instruction. Thus in some circumstances it can be beneficial to
- restrict the size of constants that are used in instructions.
- Constants that are too big are instead placed into a constant pool
- and referenced via register indirection.
-
- The value N can be between 0 and 4. A value of 0 (the default) or
- 4 means that constants of any size are allowed.
-
-`-mrelax'
- Enable linker relaxation. Linker relaxation is a process whereby
- the linker will attempt to reduce the size of a program by finding
- shorter versions of various instructions. Disabled by default.
-
-`-mint-register=N'
- Specify the number of registers to reserve for fast interrupt
- handler functions. The value N can be between 0 and 4. A value
- of 1 means that register `r13' will be reserved for the exclusive
- use of fast interrupt handlers. A value of 2 reserves `r13' and
- `r12'. A value of 3 reserves `r13', `r12' and `r11', and a value
- of 4 reserves `r13' through `r10'. A value of 0, the default,
- does not reserve any registers.
-
-`-msave-acc-in-interrupts'
- Specifies that interrupt handler functions should preserve the
- accumulator register. This is only necessary if normal code might
- use the accumulator register, for example because it performs
- 64-bit multiplications. The default is to ignore the accumulator
- as this makes the interrupt handlers faster.
-
-
- _Note:_ The generic GCC command line `-ffixed-REG' has special
-significance to the RX port when used with the `interrupt' function
-attribute. This attribute indicates a function intended to process
-fast interrupts. GCC will will ensure that it only uses the registers
-`r10', `r11', `r12' and/or `r13' and only provided that the normal use
-of the corresponding registers have been restricted via the
-`-ffixed-REG' or `-mint-register' command line options.
-
-
-File: gcc.info, Node: S/390 and zSeries Options, Next: Score Options, Prev: RX Options, Up: Submodel Options
-
-3.17.35 S/390 and zSeries Options
----------------------------------
-
-These are the `-m' options defined for the S/390 and zSeries
-architecture.
-
-`-mhard-float'
-`-msoft-float'
- Use (do not use) the hardware floating-point instructions and
- registers for floating-point operations. When `-msoft-float' is
- specified, functions in `libgcc.a' will be used to perform
- floating-point operations. When `-mhard-float' is specified, the
- compiler generates IEEE floating-point instructions. This is the
- default.
-
-`-mhard-dfp'
-`-mno-hard-dfp'
- Use (do not use) the hardware decimal-floating-point instructions
- for decimal-floating-point operations. When `-mno-hard-dfp' is
- specified, functions in `libgcc.a' will be used to perform
- decimal-floating-point operations. When `-mhard-dfp' is
- specified, the compiler generates decimal-floating-point hardware
- instructions. This is the default for `-march=z9-ec' or higher.
-
-`-mlong-double-64'
-`-mlong-double-128'
- These switches control the size of `long double' type. A size of
- 64bit makes the `long double' type equivalent to the `double'
- type. This is the default.
-
-`-mbackchain'
-`-mno-backchain'
- Store (do not store) the address of the caller's frame as
- backchain pointer into the callee's stack frame. A backchain may
- be needed to allow debugging using tools that do not understand
- DWARF-2 call frame information. When `-mno-packed-stack' is in
- effect, the backchain pointer is stored at the bottom of the stack
- frame; when `-mpacked-stack' is in effect, the backchain is placed
- into the topmost word of the 96/160 byte register save area.
-
- In general, code compiled with `-mbackchain' is call-compatible
- with code compiled with `-mmo-backchain'; however, use of the
- backchain for debugging purposes usually requires that the whole
- binary is built with `-mbackchain'. Note that the combination of
- `-mbackchain', `-mpacked-stack' and `-mhard-float' is not
- supported. In order to build a linux kernel use `-msoft-float'.
-
- The default is to not maintain the backchain.
-
-`-mpacked-stack'
-`-mno-packed-stack'
- Use (do not use) the packed stack layout. When
- `-mno-packed-stack' is specified, the compiler uses the all fields
- of the 96/160 byte register save area only for their default
- purpose; unused fields still take up stack space. When
- `-mpacked-stack' is specified, register save slots are densely
- packed at the top of the register save area; unused space is
- reused for other purposes, allowing for more efficient use of the
- available stack space. However, when `-mbackchain' is also in
- effect, the topmost word of the save area is always used to store
- the backchain, and the return address register is always saved two
- words below the backchain.
-
- As long as the stack frame backchain is not used, code generated
- with `-mpacked-stack' is call-compatible with code generated with
- `-mno-packed-stack'. Note that some non-FSF releases of GCC 2.95
- for S/390 or zSeries generated code that uses the stack frame
- backchain at run time, not just for debugging purposes. Such code
- is not call-compatible with code compiled with `-mpacked-stack'.
- Also, note that the combination of `-mbackchain', `-mpacked-stack'
- and `-mhard-float' is not supported. In order to build a linux
- kernel use `-msoft-float'.
-
- The default is to not use the packed stack layout.
-
-`-msmall-exec'
-`-mno-small-exec'
- Generate (or do not generate) code using the `bras' instruction to
- do subroutine calls. This only works reliably if the total
- executable size does not exceed 64k. The default is to use the
- `basr' instruction instead, which does not have this limitation.
-
-`-m64'
-`-m31'
- When `-m31' is specified, generate code compliant to the GNU/Linux
- for S/390 ABI. When `-m64' is specified, generate code compliant
- to the GNU/Linux for zSeries ABI. This allows GCC in particular
- to generate 64-bit instructions. For the `s390' targets, the
- default is `-m31', while the `s390x' targets default to `-m64'.
-
-`-mzarch'
-`-mesa'
- When `-mzarch' is specified, generate code using the instructions
- available on z/Architecture. When `-mesa' is specified, generate
- code using the instructions available on ESA/390. Note that
- `-mesa' is not possible with `-m64'. When generating code
- compliant to the GNU/Linux for S/390 ABI, the default is `-mesa'.
- When generating code compliant to the GNU/Linux for zSeries ABI,
- the default is `-mzarch'.
-
-`-mmvcle'
-`-mno-mvcle'
- Generate (or do not generate) code using the `mvcle' instruction
- to perform block moves. When `-mno-mvcle' is specified, use a
- `mvc' loop instead. This is the default unless optimizing for
- size.
-
-`-mdebug'
-`-mno-debug'
- Print (or do not print) additional debug information when
- compiling. The default is to not print debug information.
-
-`-march=CPU-TYPE'
- Generate code that will run on CPU-TYPE, which is the name of a
- system representing a certain processor type. Possible values for
- CPU-TYPE are `g5', `g6', `z900', `z990', `z9-109', `z9-ec' and
- `z10'. When generating code using the instructions available on
- z/Architecture, the default is `-march=z900'. Otherwise, the
- default is `-march=g5'.
-
-`-mtune=CPU-TYPE'
- Tune to CPU-TYPE everything applicable about the generated code,
- except for the ABI and the set of available instructions. The
- list of CPU-TYPE values is the same as for `-march'. The default
- is the value used for `-march'.
-
-`-mtpf-trace'
-`-mno-tpf-trace'
- Generate code that adds (does not add) in TPF OS specific branches
- to trace routines in the operating system. This option is off by
- default, even when compiling for the TPF OS.
-
-`-mfused-madd'
-`-mno-fused-madd'
- Generate code that uses (does not use) the floating point multiply
- and accumulate instructions. These instructions are generated by
- default if hardware floating point is used.
-
-`-mwarn-framesize=FRAMESIZE'
- Emit a warning if the current function exceeds the given frame
- size. Because this is a compile time check it doesn't need to be
- a real problem when the program runs. It is intended to identify
- functions which most probably cause a stack overflow. It is
- useful to be used in an environment with limited stack size e.g.
- the linux kernel.
-
-`-mwarn-dynamicstack'
- Emit a warning if the function calls alloca or uses dynamically
- sized arrays. This is generally a bad idea with a limited stack
- size.
-
-`-mstack-guard=STACK-GUARD'
-`-mstack-size=STACK-SIZE'
- If these options are provided the s390 back end emits additional
- instructions in the function prologue which trigger a trap if the
- stack size is STACK-GUARD bytes above the STACK-SIZE (remember
- that the stack on s390 grows downward). If the STACK-GUARD option
- is omitted the smallest power of 2 larger than the frame size of
- the compiled function is chosen. These options are intended to be
- used to help debugging stack overflow problems. The additionally
- emitted code causes only little overhead and hence can also be
- used in production like systems without greater performance
- degradation. The given values have to be exact powers of 2 and
- STACK-SIZE has to be greater than STACK-GUARD without exceeding
- 64k. In order to be efficient the extra code makes the assumption
- that the stack starts at an address aligned to the value given by
- STACK-SIZE. The STACK-GUARD option can only be used in
- conjunction with STACK-SIZE.
-
-
-File: gcc.info, Node: Score Options, Next: SH Options, Prev: S/390 and zSeries Options, Up: Submodel Options
-
-3.17.36 Score Options
----------------------
-
-These options are defined for Score implementations:
-
-`-meb'
- Compile code for big endian mode. This is the default.
-
-`-mel'
- Compile code for little endian mode.
-
-`-mnhwloop'
- Disable generate bcnz instruction.
-
-`-muls'
- Enable generate unaligned load and store instruction.
-
-`-mmac'
- Enable the use of multiply-accumulate instructions. Disabled by
- default.
-
-`-mscore5'
- Specify the SCORE5 as the target architecture.
-
-`-mscore5u'
- Specify the SCORE5U of the target architecture.
-
-`-mscore7'
- Specify the SCORE7 as the target architecture. This is the default.
-
-`-mscore7d'
- Specify the SCORE7D as the target architecture.
-
-
-File: gcc.info, Node: SH Options, Next: Solaris 2 Options, Prev: Score Options, Up: Submodel Options
-
-3.17.37 SH Options
-------------------
-
-These `-m' options are defined for the SH implementations:
-
-`-m1'
- Generate code for the SH1.
-
-`-m2'
- Generate code for the SH2.
-
-`-m2e'
- Generate code for the SH2e.
-
-`-m2a-nofpu'
- Generate code for the SH2a without FPU, or for a SH2a-FPU in such
- a way that the floating-point unit is not used.
-
-`-m2a-single-only'
- Generate code for the SH2a-FPU, in such a way that no
- double-precision floating point operations are used.
-
-`-m2a-single'
- Generate code for the SH2a-FPU assuming the floating-point unit is
- in single-precision mode by default.
-
-`-m2a'
- Generate code for the SH2a-FPU assuming the floating-point unit is
- in double-precision mode by default.
-
-`-m3'
- Generate code for the SH3.
-
-`-m3e'
- Generate code for the SH3e.
-
-`-m4-nofpu'
- Generate code for the SH4 without a floating-point unit.
-
-`-m4-single-only'
- Generate code for the SH4 with a floating-point unit that only
- supports single-precision arithmetic.
-
-`-m4-single'
- Generate code for the SH4 assuming the floating-point unit is in
- single-precision mode by default.
-
-`-m4'
- Generate code for the SH4.
-
-`-m4a-nofpu'
- Generate code for the SH4al-dsp, or for a SH4a in such a way that
- the floating-point unit is not used.
-
-`-m4a-single-only'
- Generate code for the SH4a, in such a way that no double-precision
- floating point operations are used.
-
-`-m4a-single'
- Generate code for the SH4a assuming the floating-point unit is in
- single-precision mode by default.
-
-`-m4a'
- Generate code for the SH4a.
-
-`-m4al'
- Same as `-m4a-nofpu', except that it implicitly passes `-dsp' to
- the assembler. GCC doesn't generate any DSP instructions at the
- moment.
-
-`-mb'
- Compile code for the processor in big endian mode.
-
-`-ml'
- Compile code for the processor in little endian mode.
-
-`-mdalign'
- Align doubles at 64-bit boundaries. Note that this changes the
- calling conventions, and thus some functions from the standard C
- library will not work unless you recompile it first with
- `-mdalign'.
-
-`-mrelax'
- Shorten some address references at link time, when possible; uses
- the linker option `-relax'.
-
-`-mbigtable'
- Use 32-bit offsets in `switch' tables. The default is to use
- 16-bit offsets.
-
-`-mbitops'
- Enable the use of bit manipulation instructions on SH2A.
-
-`-mfmovd'
- Enable the use of the instruction `fmovd'. Check `-mdalign' for
- alignment constraints.
-
-`-mhitachi'
- Comply with the calling conventions defined by Renesas.
-
-`-mrenesas'
- Comply with the calling conventions defined by Renesas.
-
-`-mno-renesas'
- Comply with the calling conventions defined for GCC before the
- Renesas conventions were available. This option is the default
- for all targets of the SH toolchain except for `sh-symbianelf'.
-
-`-mnomacsave'
- Mark the `MAC' register as call-clobbered, even if `-mhitachi' is
- given.
-
-`-mieee'
- Increase IEEE-compliance of floating-point code. At the moment,
- this is equivalent to `-fno-finite-math-only'. When generating 16
- bit SH opcodes, getting IEEE-conforming results for comparisons of
- NANs / infinities incurs extra overhead in every floating point
- comparison, therefore the default is set to `-ffinite-math-only'.
-
-`-minline-ic_invalidate'
- Inline code to invalidate instruction cache entries after setting
- up nested function trampolines. This option has no effect if
- -musermode is in effect and the selected code generation option
- (e.g. -m4) does not allow the use of the icbi instruction. If the
- selected code generation option does not allow the use of the icbi
- instruction, and -musermode is not in effect, the inlined code will
- manipulate the instruction cache address array directly with an
- associative write. This not only requires privileged mode, but it
- will also fail if the cache line had been mapped via the TLB and
- has become unmapped.
-
-`-misize'
- Dump instruction size and location in the assembly code.
-
-`-mpadstruct'
- This option is deprecated. It pads structures to multiple of 4
- bytes, which is incompatible with the SH ABI.
-
-`-mspace'
- Optimize for space instead of speed. Implied by `-Os'.
-
-`-mprefergot'
- When generating position-independent code, emit function calls
- using the Global Offset Table instead of the Procedure Linkage
- Table.
-
-`-musermode'
- Don't generate privileged mode only code; implies
- -mno-inline-ic_invalidate if the inlined code would not work in
- user mode. This is the default when the target is `sh-*-linux*'.
-
-`-multcost=NUMBER'
- Set the cost to assume for a multiply insn.
-
-`-mdiv=STRATEGY'
- Set the division strategy to use for SHmedia code. STRATEGY must
- be one of: call, call2, fp, inv, inv:minlat, inv20u, inv20l,
- inv:call, inv:call2, inv:fp . "fp" performs the operation in
- floating point. This has a very high latency, but needs only a
- few instructions, so it might be a good choice if your code has
- enough easily exploitable ILP to allow the compiler to schedule
- the floating point instructions together with other instructions.
- Division by zero causes a floating point exception. "inv" uses
- integer operations to calculate the inverse of the divisor, and
- then multiplies the dividend with the inverse. This strategy
- allows cse and hoisting of the inverse calculation. Division by
- zero calculates an unspecified result, but does not trap.
- "inv:minlat" is a variant of "inv" where if no cse / hoisting
- opportunities have been found, or if the entire operation has been
- hoisted to the same place, the last stages of the inverse
- calculation are intertwined with the final multiply to reduce the
- overall latency, at the expense of using a few more instructions,
- and thus offering fewer scheduling opportunities with other code.
- "call" calls a library function that usually implements the
- inv:minlat strategy. This gives high code density for
- m5-*media-nofpu compilations. "call2" uses a different entry
- point of the same library function, where it assumes that a
- pointer to a lookup table has already been set up, which exposes
- the pointer load to cse / code hoisting optimizations.
- "inv:call", "inv:call2" and "inv:fp" all use the "inv" algorithm
- for initial code generation, but if the code stays unoptimized,
- revert to the "call", "call2", or "fp" strategies, respectively.
- Note that the potentially-trapping side effect of division by zero
- is carried by a separate instruction, so it is possible that all
- the integer instructions are hoisted out, but the marker for the
- side effect stays where it is. A recombination to fp operations
- or a call is not possible in that case. "inv20u" and "inv20l" are
- variants of the "inv:minlat" strategy. In the case that the
- inverse calculation was nor separated from the multiply, they speed
- up division where the dividend fits into 20 bits (plus sign where
- applicable), by inserting a test to skip a number of operations in
- this case; this test slows down the case of larger dividends.
- inv20u assumes the case of a such a small dividend to be unlikely,
- and inv20l assumes it to be likely.
-
-`-maccumulate-outgoing-args'
- Reserve space once for outgoing arguments in the function prologue
- rather than around each call. Generally beneficial for
- performance and size. Also needed for unwinding to avoid changing
- the stack frame around conditional code.
-
-`-mdivsi3_libfunc=NAME'
- Set the name of the library function used for 32 bit signed
- division to NAME. This only affect the name used in the call and
- inv:call division strategies, and the compiler will still expect
- the same sets of input/output/clobbered registers as if this
- option was not present.
-
-`-mfixed-range=REGISTER-RANGE'
- Generate code treating the given register range as fixed registers.
- A fixed register is one that the register allocator can not use.
- This is useful when compiling kernel code. A register range is
- specified as two registers separated by a dash. Multiple register
- ranges can be specified separated by a comma.
-
-`-madjust-unroll'
- Throttle unrolling to avoid thrashing target registers. This
- option only has an effect if the gcc code base supports the
- TARGET_ADJUST_UNROLL_MAX target hook.
-
-`-mindexed-addressing'
- Enable the use of the indexed addressing mode for
- SHmedia32/SHcompact. This is only safe if the hardware and/or OS
- implement 32 bit wrap-around semantics for the indexed addressing
- mode. The architecture allows the implementation of processors
- with 64 bit MMU, which the OS could use to get 32 bit addressing,
- but since no current hardware implementation supports this or any
- other way to make the indexed addressing mode safe to use in the
- 32 bit ABI, the default is -mno-indexed-addressing.
-
-`-mgettrcost=NUMBER'
- Set the cost assumed for the gettr instruction to NUMBER. The
- default is 2 if `-mpt-fixed' is in effect, 100 otherwise.
-
-`-mpt-fixed'
- Assume pt* instructions won't trap. This will generally generate
- better scheduled code, but is unsafe on current hardware. The
- current architecture definition says that ptabs and ptrel trap
- when the target anded with 3 is 3. This has the unintentional
- effect of making it unsafe to schedule ptabs / ptrel before a
- branch, or hoist it out of a loop. For example,
- __do_global_ctors, a part of libgcc that runs constructors at
- program startup, calls functions in a list which is delimited by
- -1. With the -mpt-fixed option, the ptabs will be done before
- testing against -1. That means that all the constructors will be
- run a bit quicker, but when the loop comes to the end of the list,
- the program crashes because ptabs loads -1 into a target register.
- Since this option is unsafe for any hardware implementing the
- current architecture specification, the default is -mno-pt-fixed.
- Unless the user specifies a specific cost with `-mgettrcost',
- -mno-pt-fixed also implies `-mgettrcost=100'; this deters register
- allocation using target registers for storing ordinary integers.
-
-`-minvalid-symbols'
- Assume symbols might be invalid. Ordinary function symbols
- generated by the compiler will always be valid to load with
- movi/shori/ptabs or movi/shori/ptrel, but with assembler and/or
- linker tricks it is possible to generate symbols that will cause
- ptabs / ptrel to trap. This option is only meaningful when
- `-mno-pt-fixed' is in effect. It will then prevent
- cross-basic-block cse, hoisting and most scheduling of symbol
- loads. The default is `-mno-invalid-symbols'.
-
-
-File: gcc.info, Node: Solaris 2 Options, Next: SPARC Options, Prev: SH Options, Up: Submodel Options
-
-3.17.38 Solaris 2 Options
--------------------------
-
-These `-m' options are supported on Solaris 2:
-
-`-mimpure-text'
- `-mimpure-text', used in addition to `-shared', tells the compiler
- to not pass `-z text' to the linker when linking a shared object.
- Using this option, you can link position-dependent code into a
- shared object.
-
- `-mimpure-text' suppresses the "relocations remain against
- allocatable but non-writable sections" linker error message.
- However, the necessary relocations will trigger copy-on-write, and
- the shared object is not actually shared across processes.
- Instead of using `-mimpure-text', you should compile all source
- code with `-fpic' or `-fPIC'.
-
-
- These switches are supported in addition to the above on Solaris 2:
-
-`-threads'
- Add support for multithreading using the Solaris threads library.
- This option sets flags for both the preprocessor and linker. This
- option does not affect the thread safety of object code produced
- by the compiler or that of libraries supplied with it.
-
-`-pthreads'
- Add support for multithreading using the POSIX threads library.
- This option sets flags for both the preprocessor and linker. This
- option does not affect the thread safety of object code produced
- by the compiler or that of libraries supplied with it.
-
-`-pthread'
- This is a synonym for `-pthreads'.
-
-
-File: gcc.info, Node: SPARC Options, Next: SPU Options, Prev: Solaris 2 Options, Up: Submodel Options
-
-3.17.39 SPARC Options
----------------------
-
-These `-m' options are supported on the SPARC:
-
-`-mno-app-regs'
-`-mapp-regs'
- Specify `-mapp-regs' to generate output using the global registers
- 2 through 4, which the SPARC SVR4 ABI reserves for applications.
- This is the default.
-
- To be fully SVR4 ABI compliant at the cost of some performance
- loss, specify `-mno-app-regs'. You should compile libraries and
- system software with this option.
-
-`-mfpu'
-`-mhard-float'
- Generate output containing floating point instructions. This is
- the default.
-
-`-mno-fpu'
-`-msoft-float'
- Generate output containing library calls for floating point.
- *Warning:* the requisite libraries are not available for all SPARC
- targets. Normally the facilities of the machine's usual C
- compiler are used, but this cannot be done directly in
- cross-compilation. You must make your own arrangements to provide
- suitable library functions for cross-compilation. The embedded
- targets `sparc-*-aout' and `sparclite-*-*' do provide software
- floating point support.
-
- `-msoft-float' changes the calling convention in the output file;
- therefore, it is only useful if you compile _all_ of a program with
- this option. In particular, you need to compile `libgcc.a', the
- library that comes with GCC, with `-msoft-float' in order for this
- to work.
-
-`-mhard-quad-float'
- Generate output containing quad-word (long double) floating point
- instructions.
-
-`-msoft-quad-float'
- Generate output containing library calls for quad-word (long
- double) floating point instructions. The functions called are
- those specified in the SPARC ABI. This is the default.
-
- As of this writing, there are no SPARC implementations that have
- hardware support for the quad-word floating point instructions.
- They all invoke a trap handler for one of these instructions, and
- then the trap handler emulates the effect of the instruction.
- Because of the trap handler overhead, this is much slower than
- calling the ABI library routines. Thus the `-msoft-quad-float'
- option is the default.
-
-`-mno-unaligned-doubles'
-`-munaligned-doubles'
- Assume that doubles have 8 byte alignment. This is the default.
-
- With `-munaligned-doubles', GCC assumes that doubles have 8 byte
- alignment only if they are contained in another type, or if they
- have an absolute address. Otherwise, it assumes they have 4 byte
- alignment. Specifying this option avoids some rare compatibility
- problems with code generated by other compilers. It is not the
- default because it results in a performance loss, especially for
- floating point code.
-
-`-mno-faster-structs'
-`-mfaster-structs'
- With `-mfaster-structs', the compiler assumes that structures
- should have 8 byte alignment. This enables the use of pairs of
- `ldd' and `std' instructions for copies in structure assignment,
- in place of twice as many `ld' and `st' pairs. However, the use
- of this changed alignment directly violates the SPARC ABI. Thus,
- it's intended only for use on targets where the developer
- acknowledges that their resulting code will not be directly in
- line with the rules of the ABI.
-
-`-mcpu=CPU_TYPE'
- Set the instruction set, register set, and instruction scheduling
- parameters for machine type CPU_TYPE. Supported values for
- CPU_TYPE are `v7', `cypress', `v8', `supersparc', `hypersparc',
- `leon', `sparclite', `f930', `f934', `sparclite86x', `sparclet',
- `tsc701', `v9', `ultrasparc', `ultrasparc3', `niagara' and
- `niagara2'.
-
- Default instruction scheduling parameters are used for values that
- select an architecture and not an implementation. These are `v7',
- `v8', `sparclite', `sparclet', `v9'.
-
- Here is a list of each supported architecture and their supported
- implementations.
-
- v7: cypress
- v8: supersparc, hypersparc, leon
- sparclite: f930, f934, sparclite86x
- sparclet: tsc701
- v9: ultrasparc, ultrasparc3, niagara, niagara2
-
- By default (unless configured otherwise), GCC generates code for
- the V7 variant of the SPARC architecture. With `-mcpu=cypress',
- the compiler additionally optimizes it for the Cypress CY7C602
- chip, as used in the SPARCStation/SPARCServer 3xx series. This is
- also appropriate for the older SPARCStation 1, 2, IPX etc.
-
- With `-mcpu=v8', GCC generates code for the V8 variant of the SPARC
- architecture. The only difference from V7 code is that the
- compiler emits the integer multiply and integer divide
- instructions which exist in SPARC-V8 but not in SPARC-V7. With
- `-mcpu=supersparc', the compiler additionally optimizes it for the
- SuperSPARC chip, as used in the SPARCStation 10, 1000 and 2000
- series.
-
- With `-mcpu=sparclite', GCC generates code for the SPARClite
- variant of the SPARC architecture. This adds the integer
- multiply, integer divide step and scan (`ffs') instructions which
- exist in SPARClite but not in SPARC-V7. With `-mcpu=f930', the
- compiler additionally optimizes it for the Fujitsu MB86930 chip,
- which is the original SPARClite, with no FPU. With `-mcpu=f934',
- the compiler additionally optimizes it for the Fujitsu MB86934
- chip, which is the more recent SPARClite with FPU.
-
- With `-mcpu=sparclet', GCC generates code for the SPARClet variant
- of the SPARC architecture. This adds the integer multiply,
- multiply/accumulate, integer divide step and scan (`ffs')
- instructions which exist in SPARClet but not in SPARC-V7. With
- `-mcpu=tsc701', the compiler additionally optimizes it for the
- TEMIC SPARClet chip.
-
- With `-mcpu=v9', GCC generates code for the V9 variant of the SPARC
- architecture. This adds 64-bit integer and floating-point move
- instructions, 3 additional floating-point condition code registers
- and conditional move instructions. With `-mcpu=ultrasparc', the
- compiler additionally optimizes it for the Sun UltraSPARC I/II/IIi
- chips. With `-mcpu=ultrasparc3', the compiler additionally
- optimizes it for the Sun UltraSPARC III/III+/IIIi/IIIi+/IV/IV+
- chips. With `-mcpu=niagara', the compiler additionally optimizes
- it for Sun UltraSPARC T1 chips. With `-mcpu=niagara2', the
- compiler additionally optimizes it for Sun UltraSPARC T2 chips.
-
-`-mtune=CPU_TYPE'
- Set the instruction scheduling parameters for machine type
- CPU_TYPE, but do not set the instruction set or register set that
- the option `-mcpu=CPU_TYPE' would.
-
- The same values for `-mcpu=CPU_TYPE' can be used for
- `-mtune=CPU_TYPE', but the only useful values are those that
- select a particular CPU implementation. Those are `cypress',
- `supersparc', `hypersparc', `leon', `f930', `f934',
- `sparclite86x', `tsc701', `ultrasparc', `ultrasparc3', `niagara',
- and `niagara2'.
-
-`-mv8plus'
-`-mno-v8plus'
- With `-mv8plus', GCC generates code for the SPARC-V8+ ABI. The
- difference from the V8 ABI is that the global and out registers are
- considered 64-bit wide. This is enabled by default on Solaris in
- 32-bit mode for all SPARC-V9 processors.
-
-`-mvis'
-`-mno-vis'
- With `-mvis', GCC generates code that takes advantage of the
- UltraSPARC Visual Instruction Set extensions. The default is
- `-mno-vis'.
-
-`-mfix-at697f'
- Enable the documented workaround for the single erratum of the
- Atmel AT697F processor (which corresponds to erratum #13 of the
- AT697E processor).
-
- These `-m' options are supported in addition to the above on SPARC-V9
-processors in 64-bit environments:
-
-`-mlittle-endian'
- Generate code for a processor running in little-endian mode. It
- is only available for a few configurations and most notably not on
- Solaris and Linux.
-
-`-m32'
-`-m64'
- Generate code for a 32-bit or 64-bit environment. The 32-bit
- environment sets int, long and pointer to 32 bits. The 64-bit
- environment sets int to 32 bits and long and pointer to 64 bits.
-
-`-mcmodel=medlow'
- Generate code for the Medium/Low code model: 64-bit addresses,
- programs must be linked in the low 32 bits of memory. Programs
- can be statically or dynamically linked.
-
-`-mcmodel=medmid'
- Generate code for the Medium/Middle code model: 64-bit addresses,
- programs must be linked in the low 44 bits of memory, the text and
- data segments must be less than 2GB in size and the data segment
- must be located within 2GB of the text segment.
-
-`-mcmodel=medany'
- Generate code for the Medium/Anywhere code model: 64-bit
- addresses, programs may be linked anywhere in memory, the text and
- data segments must be less than 2GB in size and the data segment
- must be located within 2GB of the text segment.
-
-`-mcmodel=embmedany'
- Generate code for the Medium/Anywhere code model for embedded
- systems: 64-bit addresses, the text and data segments must be less
- than 2GB in size, both starting anywhere in memory (determined at
- link time). The global register %g4 points to the base of the
- data segment. Programs are statically linked and PIC is not
- supported.
-
-`-mstack-bias'
-`-mno-stack-bias'
- With `-mstack-bias', GCC assumes that the stack pointer, and frame
- pointer if present, are offset by -2047 which must be added back
- when making stack frame references. This is the default in 64-bit
- mode. Otherwise, assume no such offset is present.
-
-
-File: gcc.info, Node: SPU Options, Next: System V Options, Prev: SPARC Options, Up: Submodel Options
-
-3.17.40 SPU Options
--------------------
-
-These `-m' options are supported on the SPU:
-
-`-mwarn-reloc'
-`-merror-reloc'
- The loader for SPU does not handle dynamic relocations. By
- default, GCC will give an error when it generates code that
- requires a dynamic relocation. `-mno-error-reloc' disables the
- error, `-mwarn-reloc' will generate a warning instead.
-
-`-msafe-dma'
-`-munsafe-dma'
- Instructions which initiate or test completion of DMA must not be
- reordered with respect to loads and stores of the memory which is
- being accessed. Users typically address this problem using the
- volatile keyword, but that can lead to inefficient code in places
- where the memory is known to not change. Rather than mark the
- memory as volatile we treat the DMA instructions as potentially
- effecting all memory. With `-munsafe-dma' users must use the
- volatile keyword to protect memory accesses.
-
-`-mbranch-hints'
- By default, GCC will generate a branch hint instruction to avoid
- pipeline stalls for always taken or probably taken branches. A
- hint will not be generated closer than 8 instructions away from
- its branch. There is little reason to disable them, except for
- debugging purposes, or to make an object a little bit smaller.
-
-`-msmall-mem'
-`-mlarge-mem'
- By default, GCC generates code assuming that addresses are never
- larger than 18 bits. With `-mlarge-mem' code is generated that
- assumes a full 32 bit address.
-
-`-mstdmain'
- By default, GCC links against startup code that assumes the
- SPU-style main function interface (which has an unconventional
- parameter list). With `-mstdmain', GCC will link your program
- against startup code that assumes a C99-style interface to `main',
- including a local copy of `argv' strings.
-
-`-mfixed-range=REGISTER-RANGE'
- Generate code treating the given register range as fixed registers.
- A fixed register is one that the register allocator can not use.
- This is useful when compiling kernel code. A register range is
- specified as two registers separated by a dash. Multiple register
- ranges can be specified separated by a comma.
-
-`-mea32'
-`-mea64'
- Compile code assuming that pointers to the PPU address space
- accessed via the `__ea' named address space qualifier are either
- 32 or 64 bits wide. The default is 32 bits. As this is an ABI
- changing option, all object code in an executable must be compiled
- with the same setting.
-
-`-maddress-space-conversion'
-`-mno-address-space-conversion'
- Allow/disallow treating the `__ea' address space as superset of
- the generic address space. This enables explicit type casts
- between `__ea' and generic pointer as well as implicit conversions
- of generic pointers to `__ea' pointers. The default is to allow
- address space pointer conversions.
-
-`-mcache-size=CACHE-SIZE'
- This option controls the version of libgcc that the compiler links
- to an executable and selects a software-managed cache for
- accessing variables in the `__ea' address space with a particular
- cache size. Possible options for CACHE-SIZE are `8', `16', `32',
- `64' and `128'. The default cache size is 64KB.
-
-`-matomic-updates'
-`-mno-atomic-updates'
- This option controls the version of libgcc that the compiler links
- to an executable and selects whether atomic updates to the
- software-managed cache of PPU-side variables are used. If you use
- atomic updates, changes to a PPU variable from SPU code using the
- `__ea' named address space qualifier will not interfere with
- changes to other PPU variables residing in the same cache line
- from PPU code. If you do not use atomic updates, such
- interference may occur; however, writing back cache lines will be
- more efficient. The default behavior is to use atomic updates.
-
-`-mdual-nops'
-`-mdual-nops=N'
- By default, GCC will insert nops to increase dual issue when it
- expects it to increase performance. N can be a value from 0 to
- 10. A smaller N will insert fewer nops. 10 is the default, 0 is
- the same as `-mno-dual-nops'. Disabled with `-Os'.
-
-`-mhint-max-nops=N'
- Maximum number of nops to insert for a branch hint. A branch hint
- must be at least 8 instructions away from the branch it is
- effecting. GCC will insert up to N nops to enforce this,
- otherwise it will not generate the branch hint.
-
-`-mhint-max-distance=N'
- The encoding of the branch hint instruction limits the hint to be
- within 256 instructions of the branch it is effecting. By
- default, GCC makes sure it is within 125.
-
-`-msafe-hints'
- Work around a hardware bug which causes the SPU to stall
- indefinitely. By default, GCC will insert the `hbrp' instruction
- to make sure this stall won't happen.
-
-
-
-File: gcc.info, Node: System V Options, Next: V850 Options, Prev: SPU Options, Up: Submodel Options
-
-3.17.41 Options for System V
-----------------------------
-
-These additional options are available on System V Release 4 for
-compatibility with other compilers on those systems:
-
-`-G'
- Create a shared object. It is recommended that `-symbolic' or
- `-shared' be used instead.
-
-`-Qy'
- Identify the versions of each tool used by the compiler, in a
- `.ident' assembler directive in the output.
-
-`-Qn'
- Refrain from adding `.ident' directives to the output file (this is
- the default).
-
-`-YP,DIRS'
- Search the directories DIRS, and no others, for libraries
- specified with `-l'.
-
-`-Ym,DIR'
- Look in the directory DIR to find the M4 preprocessor. The
- assembler uses this option.
-
-
-File: gcc.info, Node: V850 Options, Next: VAX Options, Prev: System V Options, Up: Submodel Options
-
-3.17.42 V850 Options
---------------------
-
-These `-m' options are defined for V850 implementations:
-
-`-mlong-calls'
-`-mno-long-calls'
- Treat all calls as being far away (near). If calls are assumed to
- be far away, the compiler will always load the functions address
- up into a register, and call indirect through the pointer.
-
-`-mno-ep'
-`-mep'
- Do not optimize (do optimize) basic blocks that use the same index
- pointer 4 or more times to copy pointer into the `ep' register, and
- use the shorter `sld' and `sst' instructions. The `-mep' option
- is on by default if you optimize.
-
-`-mno-prolog-function'
-`-mprolog-function'
- Do not use (do use) external functions to save and restore
- registers at the prologue and epilogue of a function. The
- external functions are slower, but use less code space if more
- than one function saves the same number of registers. The
- `-mprolog-function' option is on by default if you optimize.
-
-`-mspace'
- Try to make the code as small as possible. At present, this just
- turns on the `-mep' and `-mprolog-function' options.
-
-`-mtda=N'
- Put static or global variables whose size is N bytes or less into
- the tiny data area that register `ep' points to. The tiny data
- area can hold up to 256 bytes in total (128 bytes for byte
- references).
-
-`-msda=N'
- Put static or global variables whose size is N bytes or less into
- the small data area that register `gp' points to. The small data
- area can hold up to 64 kilobytes.
-
-`-mzda=N'
- Put static or global variables whose size is N bytes or less into
- the first 32 kilobytes of memory.
-
-`-mv850'
- Specify that the target processor is the V850.
-
-`-mbig-switch'
- Generate code suitable for big switch tables. Use this option
- only if the assembler/linker complain about out of range branches
- within a switch table.
-
-`-mapp-regs'
- This option will cause r2 and r5 to be used in the code generated
- by the compiler. This setting is the default.
-
-`-mno-app-regs'
- This option will cause r2 and r5 to be treated as fixed registers.
-
-`-mv850e2v3'
- Specify that the target processor is the V850E2V3. The
- preprocessor constants `__v850e2v3__' will be defined if this
- option is used.
-
-`-mv850e2'
- Specify that the target processor is the V850E2. The preprocessor
- constants `__v850e2__' will be defined if
-
-`-mv850e1'
- Specify that the target processor is the V850E1. The preprocessor
- constants `__v850e1__' and `__v850e__' will be defined if
-
-`-mv850es'
- Specify that the target processor is the V850ES. This is an alias
- for the `-mv850e1' option.
-
-`-mv850e'
- Specify that the target processor is the V850E. The preprocessor
- constant `__v850e__' will be defined if this option is used.
-
- If neither `-mv850' nor `-mv850e' nor `-mv850e1' nor `-mv850e2'
- nor `-mv850e2v3' are defined then a default target processor will
- be chosen and the relevant `__v850*__' preprocessor constant will
- be defined.
-
- The preprocessor constants `__v850' and `__v851__' are always
- defined, regardless of which processor variant is the target.
-
-`-mdisable-callt'
- This option will suppress generation of the CALLT instruction for
- the v850e, v850e1, v850e2 and v850e2v3 flavors of the v850
- architecture. The default is `-mno-disable-callt' which allows
- the CALLT instruction to be used.
-
-
-
-File: gcc.info, Node: VAX Options, Next: VxWorks Options, Prev: V850 Options, Up: Submodel Options
-
-3.17.43 VAX Options
--------------------
-
-These `-m' options are defined for the VAX:
-
-`-munix'
- Do not output certain jump instructions (`aobleq' and so on) that
- the Unix assembler for the VAX cannot handle across long ranges.
-
-`-mgnu'
- Do output those jump instructions, on the assumption that you will
- assemble with the GNU assembler.
-
-`-mg'
- Output code for g-format floating point numbers instead of
- d-format.
-
-
-File: gcc.info, Node: VxWorks Options, Next: x86-64 Options, Prev: VAX Options, Up: Submodel Options
-
-3.17.44 VxWorks Options
------------------------
-
-The options in this section are defined for all VxWorks targets.
-Options specific to the target hardware are listed with the other
-options for that target.
-
-`-mrtp'
- GCC can generate code for both VxWorks kernels and real time
- processes (RTPs). This option switches from the former to the
- latter. It also defines the preprocessor macro `__RTP__'.
-
-`-non-static'
- Link an RTP executable against shared libraries rather than static
- libraries. The options `-static' and `-shared' can also be used
- for RTPs (*note Link Options::); `-static' is the default.
-
-`-Bstatic'
-`-Bdynamic'
- These options are passed down to the linker. They are defined for
- compatibility with Diab.
-
-`-Xbind-lazy'
- Enable lazy binding of function calls. This option is equivalent
- to `-Wl,-z,now' and is defined for compatibility with Diab.
-
-`-Xbind-now'
- Disable lazy binding of function calls. This option is the
- default and is defined for compatibility with Diab.
-
-
-File: gcc.info, Node: x86-64 Options, Next: Xstormy16 Options, Prev: VxWorks Options, Up: Submodel Options
-
-3.17.45 x86-64 Options
-----------------------
-
-These are listed under *Note i386 and x86-64 Options::.
-
-
-File: gcc.info, Node: Xstormy16 Options, Next: Xtensa Options, Prev: x86-64 Options, Up: Submodel Options
-
-3.17.46 Xstormy16 Options
--------------------------
-
-These options are defined for Xstormy16:
-
-`-msim'
- Choose startup files and linker script suitable for the simulator.
-
-
-File: gcc.info, Node: Xtensa Options, Next: zSeries Options, Prev: Xstormy16 Options, Up: Submodel Options
-
-3.17.47 Xtensa Options
-----------------------
-
-These options are supported for Xtensa targets:
-
-`-mconst16'
-`-mno-const16'
- Enable or disable use of `CONST16' instructions for loading
- constant values. The `CONST16' instruction is currently not a
- standard option from Tensilica. When enabled, `CONST16'
- instructions are always used in place of the standard `L32R'
- instructions. The use of `CONST16' is enabled by default only if
- the `L32R' instruction is not available.
-
-`-mfused-madd'
-`-mno-fused-madd'
- Enable or disable use of fused multiply/add and multiply/subtract
- instructions in the floating-point option. This has no effect if
- the floating-point option is not also enabled. Disabling fused
- multiply/add and multiply/subtract instructions forces the
- compiler to use separate instructions for the multiply and
- add/subtract operations. This may be desirable in some cases
- where strict IEEE 754-compliant results are required: the fused
- multiply add/subtract instructions do not round the intermediate
- result, thereby producing results with _more_ bits of precision
- than specified by the IEEE standard. Disabling fused multiply
- add/subtract instructions also ensures that the program output is
- not sensitive to the compiler's ability to combine multiply and
- add/subtract operations.
-
-`-mserialize-volatile'
-`-mno-serialize-volatile'
- When this option is enabled, GCC inserts `MEMW' instructions before
- `volatile' memory references to guarantee sequential consistency.
- The default is `-mserialize-volatile'. Use
- `-mno-serialize-volatile' to omit the `MEMW' instructions.
-
-`-mforce-no-pic'
- For targets, like GNU/Linux, where all user-mode Xtensa code must
- be position-independent code (PIC), this option disables PIC for
- compiling kernel code.
-
-`-mtext-section-literals'
-`-mno-text-section-literals'
- Control the treatment of literal pools. The default is
- `-mno-text-section-literals', which places literals in a separate
- section in the output file. This allows the literal pool to be
- placed in a data RAM/ROM, and it also allows the linker to combine
- literal pools from separate object files to remove redundant
- literals and improve code size. With `-mtext-section-literals',
- the literals are interspersed in the text section in order to keep
- them as close as possible to their references. This may be
- necessary for large assembly files.
-
-`-mtarget-align'
-`-mno-target-align'
- When this option is enabled, GCC instructs the assembler to
- automatically align instructions to reduce branch penalties at the
- expense of some code density. The assembler attempts to widen
- density instructions to align branch targets and the instructions
- following call instructions. If there are not enough preceding
- safe density instructions to align a target, no widening will be
- performed. The default is `-mtarget-align'. These options do not
- affect the treatment of auto-aligned instructions like `LOOP',
- which the assembler will always align, either by widening density
- instructions or by inserting no-op instructions.
-
-`-mlongcalls'
-`-mno-longcalls'
- When this option is enabled, GCC instructs the assembler to
- translate direct calls to indirect calls unless it can determine
- that the target of a direct call is in the range allowed by the
- call instruction. This translation typically occurs for calls to
- functions in other source files. Specifically, the assembler
- translates a direct `CALL' instruction into an `L32R' followed by
- a `CALLX' instruction. The default is `-mno-longcalls'. This
- option should be used in programs where the call target can
- potentially be out of range. This option is implemented in the
- assembler, not the compiler, so the assembly code generated by GCC
- will still show direct call instructions--look at the disassembled
- object code to see the actual instructions. Note that the
- assembler will use an indirect call for every cross-file call, not
- just those that really will be out of range.
-
-
-File: gcc.info, Node: zSeries Options, Prev: Xtensa Options, Up: Submodel Options
-
-3.17.48 zSeries Options
------------------------
-
-These are listed under *Note S/390 and zSeries Options::.
-
-
-File: gcc.info, Node: Code Gen Options, Next: Environment Variables, Prev: Submodel Options, Up: Invoking GCC
-
-3.18 Options for Code Generation Conventions
-============================================
-
-These machine-independent options control the interface conventions
-used in code generation.
-
- Most of them have both positive and negative forms; the negative form
-of `-ffoo' would be `-fno-foo'. In the table below, only one of the
-forms is listed--the one which is not the default. You can figure out
-the other form by either removing `no-' or adding it.
-
-`-fbounds-check'
- For front-ends that support it, generate additional code to check
- that indices used to access arrays are within the declared range.
- This is currently only supported by the Java and Fortran
- front-ends, where this option defaults to true and false
- respectively.
-
-`-ftrapv'
- This option generates traps for signed overflow on addition,
- subtraction, multiplication operations.
-
-`-fwrapv'
- This option instructs the compiler to assume that signed arithmetic
- overflow of addition, subtraction and multiplication wraps around
- using twos-complement representation. This flag enables some
- optimizations and disables others. This option is enabled by
- default for the Java front-end, as required by the Java language
- specification.
-
-`-fexceptions'
- Enable exception handling. Generates extra code needed to
- propagate exceptions. For some targets, this implies GCC will
- generate frame unwind information for all functions, which can
- produce significant data size overhead, although it does not
- affect execution. If you do not specify this option, GCC will
- enable it by default for languages like C++ which normally require
- exception handling, and disable it for languages like C that do
- not normally require it. However, you may need to enable this
- option when compiling C code that needs to interoperate properly
- with exception handlers written in C++. You may also wish to
- disable this option if you are compiling older C++ programs that
- don't use exception handling.
-
-`-fnon-call-exceptions'
- Generate code that allows trapping instructions to throw
- exceptions. Note that this requires platform-specific runtime
- support that does not exist everywhere. Moreover, it only allows
- _trapping_ instructions to throw exceptions, i.e. memory
- references or floating point instructions. It does not allow
- exceptions to be thrown from arbitrary signal handlers such as
- `SIGALRM'.
-
-`-funwind-tables'
- Similar to `-fexceptions', except that it will just generate any
- needed static data, but will not affect the generated code in any
- other way. You will normally not enable this option; instead, a
- language processor that needs this handling would enable it on
- your behalf.
-
-`-fasynchronous-unwind-tables'
- Generate unwind table in dwarf2 format, if supported by target
- machine. The table is exact at each instruction boundary, so it
- can be used for stack unwinding from asynchronous events (such as
- debugger or garbage collector).
-
-`-fpcc-struct-return'
- Return "short" `struct' and `union' values in memory like longer
- ones, rather than in registers. This convention is less
- efficient, but it has the advantage of allowing intercallability
- between GCC-compiled files and files compiled with other
- compilers, particularly the Portable C Compiler (pcc).
-
- The precise convention for returning structures in memory depends
- on the target configuration macros.
-
- Short structures and unions are those whose size and alignment
- match that of some integer type.
-
- *Warning:* code compiled with the `-fpcc-struct-return' switch is
- not binary compatible with code compiled with the
- `-freg-struct-return' switch. Use it to conform to a non-default
- application binary interface.
-
-`-freg-struct-return'
- Return `struct' and `union' values in registers when possible.
- This is more efficient for small structures than
- `-fpcc-struct-return'.
-
- If you specify neither `-fpcc-struct-return' nor
- `-freg-struct-return', GCC defaults to whichever convention is
- standard for the target. If there is no standard convention, GCC
- defaults to `-fpcc-struct-return', except on targets where GCC is
- the principal compiler. In those cases, we can choose the
- standard, and we chose the more efficient register return
- alternative.
-
- *Warning:* code compiled with the `-freg-struct-return' switch is
- not binary compatible with code compiled with the
- `-fpcc-struct-return' switch. Use it to conform to a non-default
- application binary interface.
-
-`-fshort-enums'
- Allocate to an `enum' type only as many bytes as it needs for the
- declared range of possible values. Specifically, the `enum' type
- will be equivalent to the smallest integer type which has enough
- room.
-
- *Warning:* the `-fshort-enums' switch causes GCC to generate code
- that is not binary compatible with code generated without that
- switch. Use it to conform to a non-default application binary
- interface.
-
-`-fshort-double'
- Use the same size for `double' as for `float'.
-
- *Warning:* the `-fshort-double' switch causes GCC to generate code
- that is not binary compatible with code generated without that
- switch. Use it to conform to a non-default application binary
- interface.
-
-`-fshort-wchar'
- Override the underlying type for `wchar_t' to be `short unsigned
- int' instead of the default for the target. This option is useful
- for building programs to run under WINE.
-
- *Warning:* the `-fshort-wchar' switch causes GCC to generate code
- that is not binary compatible with code generated without that
- switch. Use it to conform to a non-default application binary
- interface.
-
-`-fno-common'
- In C code, controls the placement of uninitialized global
- variables. Unix C compilers have traditionally permitted multiple
- definitions of such variables in different compilation units by
- placing the variables in a common block. This is the behavior
- specified by `-fcommon', and is the default for GCC on most
- targets. On the other hand, this behavior is not required by ISO
- C, and on some targets may carry a speed or code size penalty on
- variable references. The `-fno-common' option specifies that the
- compiler should place uninitialized global variables in the data
- section of the object file, rather than generating them as common
- blocks. This has the effect that if the same variable is declared
- (without `extern') in two different compilations, you will get a
- multiple-definition error when you link them. In this case, you
- must compile with `-fcommon' instead. Compiling with
- `-fno-common' is useful on targets for which it provides better
- performance, or if you wish to verify that the program will work
- on other systems which always treat uninitialized variable
- declarations this way.
-
-`-fno-ident'
- Ignore the `#ident' directive.
-
-`-finhibit-size-directive'
- Don't output a `.size' assembler directive, or anything else that
- would cause trouble if the function is split in the middle, and the
- two halves are placed at locations far apart in memory. This
- option is used when compiling `crtstuff.c'; you should not need to
- use it for anything else.
-
-`-fverbose-asm'
- Put extra commentary information in the generated assembly code to
- make it more readable. This option is generally only of use to
- those who actually need to read the generated assembly code
- (perhaps while debugging the compiler itself).
-
- `-fno-verbose-asm', the default, causes the extra information to
- be omitted and is useful when comparing two assembler files.
-
-`-frecord-gcc-switches'
- This switch causes the command line that was used to invoke the
- compiler to be recorded into the object file that is being created.
- This switch is only implemented on some targets and the exact
- format of the recording is target and binary file format
- dependent, but it usually takes the form of a section containing
- ASCII text. This switch is related to the `-fverbose-asm' switch,
- but that switch only records information in the assembler output
- file as comments, so it never reaches the object file.
-
-`-fpic'
- Generate position-independent code (PIC) suitable for use in a
- shared library, if supported for the target machine. Such code
- accesses all constant addresses through a global offset table
- (GOT). The dynamic loader resolves the GOT entries when the
- program starts (the dynamic loader is not part of GCC; it is part
- of the operating system). If the GOT size for the linked
- executable exceeds a machine-specific maximum size, you get an
- error message from the linker indicating that `-fpic' does not
- work; in that case, recompile with `-fPIC' instead. (These
- maximums are 8k on the SPARC and 32k on the m68k and RS/6000. The
- 386 has no such limit.)
-
- Position-independent code requires special support, and therefore
- works only on certain machines. For the 386, GCC supports PIC for
- System V but not for the Sun 386i. Code generated for the IBM
- RS/6000 is always position-independent.
-
- When this flag is set, the macros `__pic__' and `__PIC__' are
- defined to 1.
-
-`-fPIC'
- If supported for the target machine, emit position-independent
- code, suitable for dynamic linking and avoiding any limit on the
- size of the global offset table. This option makes a difference
- on the m68k, PowerPC and SPARC.
-
- Position-independent code requires special support, and therefore
- works only on certain machines.
-
- When this flag is set, the macros `__pic__' and `__PIC__' are
- defined to 2.
-
-`-fpie'
-`-fPIE'
- These options are similar to `-fpic' and `-fPIC', but generated
- position independent code can be only linked into executables.
- Usually these options are used when `-pie' GCC option will be used
- during linking.
-
- `-fpie' and `-fPIE' both define the macros `__pie__' and
- `__PIE__'. The macros have the value 1 for `-fpie' and 2 for
- `-fPIE'.
-
-`-fno-jump-tables'
- Do not use jump tables for switch statements even where it would be
- more efficient than other code generation strategies. This option
- is of use in conjunction with `-fpic' or `-fPIC' for building code
- which forms part of a dynamic linker and cannot reference the
- address of a jump table. On some targets, jump tables do not
- require a GOT and this option is not needed.
-
-`-ffixed-REG'
- Treat the register named REG as a fixed register; generated code
- should never refer to it (except perhaps as a stack pointer, frame
- pointer or in some other fixed role).
-
- REG must be the name of a register. The register names accepted
- are machine-specific and are defined in the `REGISTER_NAMES' macro
- in the machine description macro file.
-
- This flag does not have a negative form, because it specifies a
- three-way choice.
-
-`-fcall-used-REG'
- Treat the register named REG as an allocable register that is
- clobbered by function calls. It may be allocated for temporaries
- or variables that do not live across a call. Functions compiled
- this way will not save and restore the register REG.
-
- It is an error to used this flag with the frame pointer or stack
- pointer. Use of this flag for other registers that have fixed
- pervasive roles in the machine's execution model will produce
- disastrous results.
-
- This flag does not have a negative form, because it specifies a
- three-way choice.
-
-`-fcall-saved-REG'
- Treat the register named REG as an allocable register saved by
- functions. It may be allocated even for temporaries or variables
- that live across a call. Functions compiled this way will save
- and restore the register REG if they use it.
-
- It is an error to used this flag with the frame pointer or stack
- pointer. Use of this flag for other registers that have fixed
- pervasive roles in the machine's execution model will produce
- disastrous results.
-
- A different sort of disaster will result from the use of this flag
- for a register in which function values may be returned.
-
- This flag does not have a negative form, because it specifies a
- three-way choice.
-
-`-fpack-struct[=N]'
- Without a value specified, pack all structure members together
- without holes. When a value is specified (which must be a small
- power of two), pack structure members according to this value,
- representing the maximum alignment (that is, objects with default
- alignment requirements larger than this will be output potentially
- unaligned at the next fitting location.
-
- *Warning:* the `-fpack-struct' switch causes GCC to generate code
- that is not binary compatible with code generated without that
- switch. Additionally, it makes the code suboptimal. Use it to
- conform to a non-default application binary interface.
-
-`-finstrument-functions'
- Generate instrumentation calls for entry and exit to functions.
- Just after function entry and just before function exit, the
- following profiling functions will be called with the address of
- the current function and its call site. (On some platforms,
- `__builtin_return_address' does not work beyond the current
- function, so the call site information may not be available to the
- profiling functions otherwise.)
-
- void __cyg_profile_func_enter (void *this_fn,
- void *call_site);
- void __cyg_profile_func_exit (void *this_fn,
- void *call_site);
-
- The first argument is the address of the start of the current
- function, which may be looked up exactly in the symbol table.
-
- This instrumentation is also done for functions expanded inline in
- other functions. The profiling calls will indicate where,
- conceptually, the inline function is entered and exited. This
- means that addressable versions of such functions must be
- available. If all your uses of a function are expanded inline,
- this may mean an additional expansion of code size. If you use
- `extern inline' in your C code, an addressable version of such
- functions must be provided. (This is normally the case anyways,
- but if you get lucky and the optimizer always expands the
- functions inline, you might have gotten away without providing
- static copies.)
-
- A function may be given the attribute `no_instrument_function', in
- which case this instrumentation will not be done. This can be
- used, for example, for the profiling functions listed above,
- high-priority interrupt routines, and any functions from which the
- profiling functions cannot safely be called (perhaps signal
- handlers, if the profiling routines generate output or allocate
- memory).
-
-`-finstrument-functions-exclude-file-list=FILE,FILE,...'
- Set the list of functions that are excluded from instrumentation
- (see the description of `-finstrument-functions'). If the file
- that contains a function definition matches with one of FILE, then
- that function is not instrumented. The match is done on
- substrings: if the FILE parameter is a substring of the file name,
- it is considered to be a match.
-
- For example:
-
- -finstrument-functions-exclude-file-list=/bits/stl,include/sys
-
- will exclude any inline function defined in files whose pathnames
- contain `/bits/stl' or `include/sys'.
-
- If, for some reason, you want to include letter `','' in one of
- SYM, write `'\,''. For example,
- `-finstrument-functions-exclude-file-list='\,\,tmp'' (note the
- single quote surrounding the option).
-
-`-finstrument-functions-exclude-function-list=SYM,SYM,...'
- This is similar to `-finstrument-functions-exclude-file-list', but
- this option sets the list of function names to be excluded from
- instrumentation. The function name to be matched is its
- user-visible name, such as `vector<int> blah(const vector<int>
- &)', not the internal mangled name (e.g.,
- `_Z4blahRSt6vectorIiSaIiEE'). The match is done on substrings: if
- the SYM parameter is a substring of the function name, it is
- considered to be a match. For C99 and C++ extended identifiers,
- the function name must be given in UTF-8, not using universal
- character names.
-
-`-fstack-check'
- Generate code to verify that you do not go beyond the boundary of
- the stack. You should specify this flag if you are running in an
- environment with multiple threads, but only rarely need to specify
- it in a single-threaded environment since stack overflow is
- automatically detected on nearly all systems if there is only one
- stack.
-
- Note that this switch does not actually cause checking to be done;
- the operating system or the language runtime must do that. The
- switch causes generation of code to ensure that they see the stack
- being extended.
-
- You can additionally specify a string parameter: `no' means no
- checking, `generic' means force the use of old-style checking,
- `specific' means use the best checking method and is equivalent to
- bare `-fstack-check'.
-
- Old-style checking is a generic mechanism that requires no specific
- target support in the compiler but comes with the following
- drawbacks:
-
- 1. Modified allocation strategy for large objects: they will
- always be allocated dynamically if their size exceeds a fixed
- threshold.
-
- 2. Fixed limit on the size of the static frame of functions:
- when it is topped by a particular function, stack checking is
- not reliable and a warning is issued by the compiler.
-
- 3. Inefficiency: because of both the modified allocation
- strategy and the generic implementation, the performances of
- the code are hampered.
-
- Note that old-style stack checking is also the fallback method for
- `specific' if no target support has been added in the compiler.
-
-`-fstack-limit-register=REG'
-`-fstack-limit-symbol=SYM'
-`-fno-stack-limit'
- Generate code to ensure that the stack does not grow beyond a
- certain value, either the value of a register or the address of a
- symbol. If the stack would grow beyond the value, a signal is
- raised. For most targets, the signal is raised before the stack
- overruns the boundary, so it is possible to catch the signal
- without taking special precautions.
-
- For instance, if the stack starts at absolute address `0x80000000'
- and grows downwards, you can use the flags
- `-fstack-limit-symbol=__stack_limit' and
- `-Wl,--defsym,__stack_limit=0x7ffe0000' to enforce a stack limit
- of 128KB. Note that this may only work with the GNU linker.
-
-`-fsplit-stack'
- Generate code to automatically split the stack before it overflows.
- The resulting program has a discontiguous stack which can only
- overflow if the program is unable to allocate any more memory.
- This is most useful when running threaded programs, as it is no
- longer necessary to calculate a good stack size to use for each
- thread. This is currently only implemented for the i386 and
- x86_64 backends running GNU/Linux.
-
- When code compiled with `-fsplit-stack' calls code compiled
- without `-fsplit-stack', there may not be much stack space
- available for the latter code to run. If compiling all code,
- including library code, with `-fsplit-stack' is not an option,
- then the linker can fix up these calls so that the code compiled
- without `-fsplit-stack' always has a large stack. Support for
- this is implemented in the gold linker in GNU binutils release 2.21
- and later.
-
-`-fleading-underscore'
- This option and its counterpart, `-fno-leading-underscore',
- forcibly change the way C symbols are represented in the object
- file. One use is to help link with legacy assembly code.
-
- *Warning:* the `-fleading-underscore' switch causes GCC to
- generate code that is not binary compatible with code generated
- without that switch. Use it to conform to a non-default
- application binary interface. Not all targets provide complete
- support for this switch.
-
-`-ftls-model=MODEL'
- Alter the thread-local storage model to be used (*note
- Thread-Local::). The MODEL argument should be one of
- `global-dynamic', `local-dynamic', `initial-exec' or `local-exec'.
-
- The default without `-fpic' is `initial-exec'; with `-fpic' the
- default is `global-dynamic'.
-
-`-fvisibility=DEFAULT|INTERNAL|HIDDEN|PROTECTED'
- Set the default ELF image symbol visibility to the specified
- option--all symbols will be marked with this unless overridden
- within the code. Using this feature can very substantially
- improve linking and load times of shared object libraries, produce
- more optimized code, provide near-perfect API export and prevent
- symbol clashes. It is *strongly* recommended that you use this in
- any shared objects you distribute.
-
- Despite the nomenclature, `default' always means public; i.e.,
- available to be linked against from outside the shared object.
- `protected' and `internal' are pretty useless in real-world usage
- so the only other commonly used option will be `hidden'. The
- default if `-fvisibility' isn't specified is `default', i.e., make
- every symbol public--this causes the same behavior as previous
- versions of GCC.
-
- A good explanation of the benefits offered by ensuring ELF symbols
- have the correct visibility is given by "How To Write Shared
- Libraries" by Ulrich Drepper (which can be found at
- `http://people.redhat.com/~drepper/')--however a superior solution
- made possible by this option to marking things hidden when the
- default is public is to make the default hidden and mark things
- public. This is the norm with DLL's on Windows and with
- `-fvisibility=hidden' and `__attribute__
- ((visibility("default")))' instead of `__declspec(dllexport)' you
- get almost identical semantics with identical syntax. This is a
- great boon to those working with cross-platform projects.
-
- For those adding visibility support to existing code, you may find
- `#pragma GCC visibility' of use. This works by you enclosing the
- declarations you wish to set visibility for with (for example)
- `#pragma GCC visibility push(hidden)' and `#pragma GCC visibility
- pop'. Bear in mind that symbol visibility should be viewed *as
- part of the API interface contract* and thus all new code should
- always specify visibility when it is not the default; i.e.,
- declarations only for use within the local DSO should *always* be
- marked explicitly as hidden as so to avoid PLT indirection
- overheads--making this abundantly clear also aids readability and
- self-documentation of the code. Note that due to ISO C++
- specification requirements, operator new and operator delete must
- always be of default visibility.
-
- Be aware that headers from outside your project, in particular
- system headers and headers from any other library you use, may not
- be expecting to be compiled with visibility other than the
- default. You may need to explicitly say `#pragma GCC visibility
- push(default)' before including any such headers.
-
- `extern' declarations are not affected by `-fvisibility', so a lot
- of code can be recompiled with `-fvisibility=hidden' with no
- modifications. However, this means that calls to `extern'
- functions with no explicit visibility will use the PLT, so it is
- more effective to use `__attribute ((visibility))' and/or `#pragma
- GCC visibility' to tell the compiler which `extern' declarations
- should be treated as hidden.
-
- Note that `-fvisibility' does affect C++ vague linkage entities.
- This means that, for instance, an exception class that will be
- thrown between DSOs must be explicitly marked with default
- visibility so that the `type_info' nodes will be unified between
- the DSOs.
-
- An overview of these techniques, their benefits and how to use them
- is at `http://gcc.gnu.org/wiki/Visibility'.
-
-`-fstrict-volatile-bitfields'
- This option should be used if accesses to volatile bitfields (or
- other structure fields, although the compiler usually honors those
- types anyway) should use a single access of the width of the
- field's type, aligned to a natural alignment if possible. For
- example, targets with memory-mapped peripheral registers might
- require all such accesses to be 16 bits wide; with this flag the
- user could declare all peripheral bitfields as "unsigned short"
- (assuming short is 16 bits on these targets) to force GCC to use
- 16 bit accesses instead of, perhaps, a more efficient 32 bit
- access.
-
- If this option is disabled, the compiler will use the most
- efficient instruction. In the previous example, that might be a
- 32-bit load instruction, even though that will access bytes that
- do not contain any portion of the bitfield, or memory-mapped
- registers unrelated to the one being updated.
-
- If the target requires strict alignment, and honoring the field
- type would require violating this alignment, a warning is issued.
- If the field has `packed' attribute, the access is done without
- honoring the field type. If the field doesn't have `packed'
- attribute, the access is done honoring the field type. In both
- cases, GCC assumes that the user knows something about the target
- hardware that it is unaware of.
-
- The default value of this option is determined by the application
- binary interface for the target processor.
-
-
-
-File: gcc.info, Node: Environment Variables, Next: Precompiled Headers, Prev: Code Gen Options, Up: Invoking GCC
-
-3.19 Environment Variables Affecting GCC
-========================================
-
-This section describes several environment variables that affect how GCC
-operates. Some of them work by specifying directories or prefixes to
-use when searching for various kinds of files. Some are used to
-specify other aspects of the compilation environment.
-
- Note that you can also specify places to search using options such as
-`-B', `-I' and `-L' (*note Directory Options::). These take precedence
-over places specified using environment variables, which in turn take
-precedence over those specified by the configuration of GCC. *Note
-Controlling the Compilation Driver `gcc': (gccint)Driver.
-
-`LANG'
-`LC_CTYPE'
-`LC_MESSAGES'
-`LC_ALL'
- These environment variables control the way that GCC uses
- localization information that allow GCC to work with different
- national conventions. GCC inspects the locale categories
- `LC_CTYPE' and `LC_MESSAGES' if it has been configured to do so.
- These locale categories can be set to any value supported by your
- installation. A typical value is `en_GB.UTF-8' for English in the
- United Kingdom encoded in UTF-8.
-
- The `LC_CTYPE' environment variable specifies character
- classification. GCC uses it to determine the character boundaries
- in a string; this is needed for some multibyte encodings that
- contain quote and escape characters that would otherwise be
- interpreted as a string end or escape.
-
- The `LC_MESSAGES' environment variable specifies the language to
- use in diagnostic messages.
-
- If the `LC_ALL' environment variable is set, it overrides the value
- of `LC_CTYPE' and `LC_MESSAGES'; otherwise, `LC_CTYPE' and
- `LC_MESSAGES' default to the value of the `LANG' environment
- variable. If none of these variables are set, GCC defaults to
- traditional C English behavior.
-
-`TMPDIR'
- If `TMPDIR' is set, it specifies the directory to use for temporary
- files. GCC uses temporary files to hold the output of one stage of
- compilation which is to be used as input to the next stage: for
- example, the output of the preprocessor, which is the input to the
- compiler proper.
-
-`GCC_EXEC_PREFIX'
- If `GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the
- names of the subprograms executed by the compiler. No slash is
- added when this prefix is combined with the name of a subprogram,
- but you can specify a prefix that ends with a slash if you wish.
-
- If `GCC_EXEC_PREFIX' is not set, GCC will attempt to figure out an
- appropriate prefix to use based on the pathname it was invoked
- with.
-
- If GCC cannot find the subprogram using the specified prefix, it
- tries looking in the usual places for the subprogram.
-
- The default value of `GCC_EXEC_PREFIX' is `PREFIX/lib/gcc/' where
- PREFIX is the prefix to the installed compiler. In many cases
- PREFIX is the value of `prefix' when you ran the `configure'
- script.
-
- Other prefixes specified with `-B' take precedence over this
- prefix.
-
- This prefix is also used for finding files such as `crt0.o' that
- are used for linking.
-
- In addition, the prefix is used in an unusual way in finding the
- directories to search for header files. For each of the standard
- directories whose name normally begins with `/usr/local/lib/gcc'
- (more precisely, with the value of `GCC_INCLUDE_DIR'), GCC tries
- replacing that beginning with the specified prefix to produce an
- alternate directory name. Thus, with `-Bfoo/', GCC will search
- `foo/bar' where it would normally search `/usr/local/lib/bar'.
- These alternate directories are searched first; the standard
- directories come next. If a standard directory begins with the
- configured PREFIX then the value of PREFIX is replaced by
- `GCC_EXEC_PREFIX' when looking for header files.
-
-`COMPILER_PATH'
- The value of `COMPILER_PATH' is a colon-separated list of
- directories, much like `PATH'. GCC tries the directories thus
- specified when searching for subprograms, if it can't find the
- subprograms using `GCC_EXEC_PREFIX'.
-
-`LIBRARY_PATH'
- The value of `LIBRARY_PATH' is a colon-separated list of
- directories, much like `PATH'. When configured as a native
- compiler, GCC tries the directories thus specified when searching
- for special linker files, if it can't find them using
- `GCC_EXEC_PREFIX'. Linking using GCC also uses these directories
- when searching for ordinary libraries for the `-l' option (but
- directories specified with `-L' come first).
-
-`LANG'
- This variable is used to pass locale information to the compiler.
- One way in which this information is used is to determine the
- character set to be used when character literals, string literals
- and comments are parsed in C and C++. When the compiler is
- configured to allow multibyte characters, the following values for
- `LANG' are recognized:
-
- `C-JIS'
- Recognize JIS characters.
-
- `C-SJIS'
- Recognize SJIS characters.
-
- `C-EUCJP'
- Recognize EUCJP characters.
-
- If `LANG' is not defined, or if it has some other value, then the
- compiler will use mblen and mbtowc as defined by the default
- locale to recognize and translate multibyte characters.
-
-Some additional environments variables affect the behavior of the
-preprocessor.
-
-`CPATH'
-`C_INCLUDE_PATH'
-`CPLUS_INCLUDE_PATH'
-`OBJC_INCLUDE_PATH'
- Each variable's value is a list of directories separated by a
- special character, much like `PATH', in which to look for header
- files. The special character, `PATH_SEPARATOR', is
- target-dependent and determined at GCC build time. For Microsoft
- Windows-based targets it is a semicolon, and for almost all other
- targets it is a colon.
-
- `CPATH' specifies a list of directories to be searched as if
- specified with `-I', but after any paths given with `-I' options
- on the command line. This environment variable is used regardless
- of which language is being preprocessed.
-
- The remaining environment variables apply only when preprocessing
- the particular language indicated. Each specifies a list of
- directories to be searched as if specified with `-isystem', but
- after any paths given with `-isystem' options on the command line.
-
- In all these variables, an empty element instructs the compiler to
- search its current working directory. Empty elements can appear
- at the beginning or end of a path. For instance, if the value of
- `CPATH' is `:/special/include', that has the same effect as
- `-I. -I/special/include'.
-
-`DEPENDENCIES_OUTPUT'
- If this variable is set, its value specifies how to output
- dependencies for Make based on the non-system header files
- processed by the compiler. System header files are ignored in the
- dependency output.
-
- The value of `DEPENDENCIES_OUTPUT' can be just a file name, in
- which case the Make rules are written to that file, guessing the
- target name from the source file name. Or the value can have the
- form `FILE TARGET', in which case the rules are written to file
- FILE using TARGET as the target name.
-
- In other words, this environment variable is equivalent to
- combining the options `-MM' and `-MF' (*note Preprocessor
- Options::), with an optional `-MT' switch too.
-
-`SUNPRO_DEPENDENCIES'
- This variable is the same as `DEPENDENCIES_OUTPUT' (see above),
- except that system header files are not ignored, so it implies
- `-M' rather than `-MM'. However, the dependence on the main input
- file is omitted. *Note Preprocessor Options::.
-
-
-File: gcc.info, Node: Precompiled Headers, Prev: Environment Variables, Up: Invoking GCC
-
-3.20 Using Precompiled Headers
-==============================
-
-Often large projects have many header files that are included in every
-source file. The time the compiler takes to process these header files
-over and over again can account for nearly all of the time required to
-build the project. To make builds faster, GCC allows users to
-`precompile' a header file; then, if builds can use the precompiled
-header file they will be much faster.
-
- To create a precompiled header file, simply compile it as you would any
-other file, if necessary using the `-x' option to make the driver treat
-it as a C or C++ header file. You will probably want to use a tool
-like `make' to keep the precompiled header up-to-date when the headers
-it contains change.
-
- A precompiled header file will be searched for when `#include' is seen
-in the compilation. As it searches for the included file (*note Search
-Path: (cpp)Search Path.) the compiler looks for a precompiled header in
-each directory just before it looks for the include file in that
-directory. The name searched for is the name specified in the
-`#include' with `.gch' appended. If the precompiled header file can't
-be used, it is ignored.
-
- For instance, if you have `#include "all.h"', and you have `all.h.gch'
-in the same directory as `all.h', then the precompiled header file will
-be used if possible, and the original header will be used otherwise.
-
- Alternatively, you might decide to put the precompiled header file in a
-directory and use `-I' to ensure that directory is searched before (or
-instead of) the directory containing the original header. Then, if you
-want to check that the precompiled header file is always used, you can
-put a file of the same name as the original header in this directory
-containing an `#error' command.
-
- This also works with `-include'. So yet another way to use
-precompiled headers, good for projects not designed with precompiled
-header files in mind, is to simply take most of the header files used by
-a project, include them from another header file, precompile that header
-file, and `-include' the precompiled header. If the header files have
-guards against multiple inclusion, they will be skipped because they've
-already been included (in the precompiled header).
-
- If you need to precompile the same header file for different
-languages, targets, or compiler options, you can instead make a
-_directory_ named like `all.h.gch', and put each precompiled header in
-the directory, perhaps using `-o'. It doesn't matter what you call the
-files in the directory, every precompiled header in the directory will
-be considered. The first precompiled header encountered in the
-directory that is valid for this compilation will be used; they're
-searched in no particular order.
-
- There are many other possibilities, limited only by your imagination,
-good sense, and the constraints of your build system.
-
- A precompiled header file can be used only when these conditions apply:
-
- * Only one precompiled header can be used in a particular
- compilation.
-
- * A precompiled header can't be used once the first C token is seen.
- You can have preprocessor directives before a precompiled header;
- you can even include a precompiled header from inside another
- header, so long as there are no C tokens before the `#include'.
-
- * The precompiled header file must be produced for the same language
- as the current compilation. You can't use a C precompiled header
- for a C++ compilation.
-
- * The precompiled header file must have been produced by the same
- compiler binary as the current compilation is using.
-
- * Any macros defined before the precompiled header is included must
- either be defined in the same way as when the precompiled header
- was generated, or must not affect the precompiled header, which
- usually means that they don't appear in the precompiled header at
- all.
-
- The `-D' option is one way to define a macro before a precompiled
- header is included; using a `#define' can also do it. There are
- also some options that define macros implicitly, like `-O' and
- `-Wdeprecated'; the same rule applies to macros defined this way.
-
- * If debugging information is output when using the precompiled
- header, using `-g' or similar, the same kind of debugging
- information must have been output when building the precompiled
- header. However, a precompiled header built using `-g' can be
- used in a compilation when no debugging information is being
- output.
-
- * The same `-m' options must generally be used when building and
- using the precompiled header. *Note Submodel Options::, for any
- cases where this rule is relaxed.
-
- * Each of the following options must be the same when building and
- using the precompiled header:
-
- -fexceptions
-
- * Some other command-line options starting with `-f', `-p', or `-O'
- must be defined in the same way as when the precompiled header was
- generated. At present, it's not clear which options are safe to
- change and which are not; the safest choice is to use exactly the
- same options when generating and using the precompiled header.
- The following are known to be safe:
-
- -fmessage-length= -fpreprocessed -fsched-interblock
- -fsched-spec -fsched-spec-load -fsched-spec-load-dangerous
- -fsched-verbose=NUMBER -fschedule-insns -fvisibility=
- -pedantic-errors
-
-
- For all of these except the last, the compiler will automatically
-ignore the precompiled header if the conditions aren't met. If you
-find an option combination that doesn't work and doesn't cause the
-precompiled header to be ignored, please consider filing a bug report,
-see *note Bugs::.
-
- If you do use differing options when generating and using the
-precompiled header, the actual behavior will be a mixture of the
-behavior for the options. For instance, if you use `-g' to generate
-the precompiled header but not when using it, you may or may not get
-debugging information for routines in the precompiled header.
-
-
-File: gcc.info, Node: C Implementation, Next: C Extensions, Prev: Invoking GCC, Up: Top
-
-4 C Implementation-defined behavior
-***********************************
-
-A conforming implementation of ISO C is required to document its choice
-of behavior in each of the areas that are designated "implementation
-defined". The following lists all such areas, along with the section
-numbers from the ISO/IEC 9899:1990 and ISO/IEC 9899:1999 standards.
-Some areas are only implementation-defined in one version of the
-standard.
-
- Some choices depend on the externally determined ABI for the platform
-(including standard character encodings) which GCC follows; these are
-listed as "determined by ABI" below. *Note Binary Compatibility:
-Compatibility, and `http://gcc.gnu.org/readings.html'. Some choices
-are documented in the preprocessor manual. *Note
-Implementation-defined behavior: (cpp)Implementation-defined behavior.
-Some choices are made by the library and operating system (or other
-environment when compiling for a freestanding environment); refer to
-their documentation for details.
-
-* Menu:
-
-* Translation implementation::
-* Environment implementation::
-* Identifiers implementation::
-* Characters implementation::
-* Integers implementation::
-* Floating point implementation::
-* Arrays and pointers implementation::
-* Hints implementation::
-* Structures unions enumerations and bit-fields implementation::
-* Qualifiers implementation::
-* Declarators implementation::
-* Statements implementation::
-* Preprocessing directives implementation::
-* Library functions implementation::
-* Architecture implementation::
-* Locale-specific behavior implementation::
-
-
-File: gcc.info, Node: Translation implementation, Next: Environment implementation, Up: C Implementation
-
-4.1 Translation
-===============
-
- * `How a diagnostic is identified (C90 3.7, C99 3.10, C90 and C99
- 5.1.1.3).'
-
- Diagnostics consist of all the output sent to stderr by GCC.
-
- * `Whether each nonempty sequence of white-space characters other
- than new-line is retained or replaced by one space character in
- translation phase 3 (C90 and C99 5.1.1.2).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
-
-
-File: gcc.info, Node: Environment implementation, Next: Identifiers implementation, Prev: Translation implementation, Up: C Implementation
-
-4.2 Environment
-===============
-
-The behavior of most of these points are dependent on the implementation
-of the C library, and are not defined by GCC itself.
-
- * `The mapping between physical source file multibyte characters and
- the source character set in translation phase 1 (C90 and C99
- 5.1.1.2).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
-
-
-File: gcc.info, Node: Identifiers implementation, Next: Characters implementation, Prev: Environment implementation, Up: C Implementation
-
-4.3 Identifiers
-===============
-
- * `Which additional multibyte characters may appear in identifiers
- and their correspondence to universal character names (C99 6.4.2).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
- * `The number of significant initial characters in an identifier
- (C90 6.1.2, C90 and C99 5.2.4.1, C99 6.4.2).'
-
- For internal names, all characters are significant. For external
- names, the number of significant characters are defined by the
- linker; for almost all targets, all characters are significant.
-
- * `Whether case distinctions are significant in an identifier with
- external linkage (C90 6.1.2).'
-
- This is a property of the linker. C99 requires that case
- distinctions are always significant in identifiers with external
- linkage and systems without this property are not supported by GCC.
-
-
-
-File: gcc.info, Node: Characters implementation, Next: Integers implementation, Prev: Identifiers implementation, Up: C Implementation
-
-4.4 Characters
-==============
-
- * `The number of bits in a byte (C90 3.4, C99 3.6).'
-
- Determined by ABI.
-
- * `The values of the members of the execution character set (C90 and
- C99 5.2.1).'
-
- Determined by ABI.
-
- * `The unique value of the member of the execution character set
- produced for each of the standard alphabetic escape sequences (C90
- and C99 5.2.2).'
-
- Determined by ABI.
-
- * `The value of a `char' object into which has been stored any
- character other than a member of the basic execution character set
- (C90 6.1.2.5, C99 6.2.5).'
-
- Determined by ABI.
-
- * `Which of `signed char' or `unsigned char' has the same range,
- representation, and behavior as "plain" `char' (C90 6.1.2.5, C90
- 6.2.1.1, C99 6.2.5, C99 6.3.1.1).'
-
- Determined by ABI. The options `-funsigned-char' and
- `-fsigned-char' change the default. *Note Options Controlling C
- Dialect: C Dialect Options.
-
- * `The mapping of members of the source character set (in character
- constants and string literals) to members of the execution
- character set (C90 6.1.3.4, C99 6.4.4.4, C90 and C99 5.1.1.2).'
-
- Determined by ABI.
-
- * `The value of an integer character constant containing more than
- one character or containing a character or escape sequence that
- does not map to a single-byte execution character (C90 6.1.3.4,
- C99 6.4.4.4).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
- * `The value of a wide character constant containing more than one
- multibyte character, or containing a multibyte character or escape
- sequence not represented in the extended execution character set
- (C90 6.1.3.4, C99 6.4.4.4).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
- * `The current locale used to convert a wide character constant
- consisting of a single multibyte character that maps to a member
- of the extended execution character set into a corresponding wide
- character code (C90 6.1.3.4, C99 6.4.4.4).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
- * `The current locale used to convert a wide string literal into
- corresponding wide character codes (C90 6.1.4, C99 6.4.5).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
- * `The value of a string literal containing a multibyte character or
- escape sequence not represented in the execution character set
- (C90 6.1.4, C99 6.4.5).'
-
- *Note Implementation-defined behavior: (cpp)Implementation-defined
- behavior.
-
-
-File: gcc.info, Node: Integers implementation, Next: Floating point implementation, Prev: Characters implementation, Up: C Implementation
-
-4.5 Integers
-============
-
- * `Any extended integer types that exist in the implementation (C99
- 6.2.5).'
-
- GCC does not support any extended integer types.
-
- * `Whether signed integer types are represented using sign and
- magnitude, two's complement, or one's complement, and whether the
- extraordinary value is a trap representation or an ordinary value
- (C99 6.2.6.2).'
-
- GCC supports only two's complement integer types, and all bit
- patterns are ordinary values.
-
- * `The rank of any extended integer type relative to another extended
- integer type with the same precision (C99 6.3.1.1).'
-
- GCC does not support any extended integer types.
-
- * `The result of, or the signal raised by, converting an integer to a
- signed integer type when the value cannot be represented in an
- object of that type (C90 6.2.1.2, C99 6.3.1.3).'
-
- For conversion to a type of width N, the value is reduced modulo
- 2^N to be within range of the type; no signal is raised.
-
- * `The results of some bitwise operations on signed integers (C90
- 6.3, C99 6.5).'
-
- Bitwise operators act on the representation of the value including
- both the sign and value bits, where the sign bit is considered
- immediately above the highest-value value bit. Signed `>>' acts
- on negative numbers by sign extension.
-
- GCC does not use the latitude given in C99 only to treat certain
- aspects of signed `<<' as undefined, but this is subject to change.
-
- * `The sign of the remainder on integer division (C90 6.3.5).'
-
- GCC always follows the C99 requirement that the result of division
- is truncated towards zero.
-
-
-
-File: gcc.info, Node: Floating point implementation, Next: Arrays and pointers implementation, Prev: Integers implementation, Up: C Implementation
-
-4.6 Floating point
-==================
-
- * `The accuracy of the floating-point operations and of the library
- functions in `<math.h>' and `<complex.h>' that return
- floating-point results (C90 and C99 5.2.4.2.2).'
-
- The accuracy is unknown.
-
- * `The rounding behaviors characterized by non-standard values of
- `FLT_ROUNDS' (C90 and C99 5.2.4.2.2).'
-
- GCC does not use such values.
-
- * `The evaluation methods characterized by non-standard negative
- values of `FLT_EVAL_METHOD' (C99 5.2.4.2.2).'
-
- GCC does not use such values.
-
- * `The direction of rounding when an integer is converted to a
- floating-point number that cannot exactly represent the original
- value (C90 6.2.1.3, C99 6.3.1.4).'
-
- C99 Annex F is followed.
-
- * `The direction of rounding when a floating-point number is
- converted to a narrower floating-point number (C90 6.2.1.4, C99
- 6.3.1.5).'
-
- C99 Annex F is followed.
-
- * `How the nearest representable value or the larger or smaller
- representable value immediately adjacent to the nearest
- representable value is chosen for certain floating constants (C90
- 6.1.3.1, C99 6.4.4.2).'
-
- C99 Annex F is followed.
-
- * `Whether and how floating expressions are contracted when not
- disallowed by the `FP_CONTRACT' pragma (C99 6.5).'
-
- Expressions are currently only contracted if
- `-funsafe-math-optimizations' or `-ffast-math' are used. This is
- subject to change.
-
- * `The default state for the `FENV_ACCESS' pragma (C99 7.6.1).'
-
- This pragma is not implemented, but the default is to "off" unless
- `-frounding-math' is used in which case it is "on".
-
- * `Additional floating-point exceptions, rounding modes,
- environments, and classifications, and their macro names (C99 7.6,
- C99 7.12).'
-
- This is dependent on the implementation of the C library, and is
- not defined by GCC itself.
-
- * `The default state for the `FP_CONTRACT' pragma (C99 7.12.2).'
-
- This pragma is not implemented. Expressions are currently only
- contracted if `-funsafe-math-optimizations' or `-ffast-math' are
- used. This is subject to change.
-
- * `Whether the "inexact" floating-point exception can be raised when
- the rounded result actually does equal the mathematical result in
- an IEC 60559 conformant implementation (C99 F.9).'
-
- This is dependent on the implementation of the C library, and is
- not defined by GCC itself.
-
- * `Whether the "underflow" (and "inexact") floating-point exception
- can be raised when a result is tiny but not inexact in an IEC
- 60559 conformant implementation (C99 F.9).'
-
- This is dependent on the implementation of the C library, and is
- not defined by GCC itself.
-
-
-
-File: gcc.info, Node: Arrays and pointers implementation, Next: Hints implementation, Prev: Floating point implementation, Up: C Implementation
-
-4.7 Arrays and pointers
-=======================
-
- * `The result of converting a pointer to an integer or vice versa
- (C90 6.3.4, C99 6.3.2.3).'
-
- A cast from pointer to integer discards most-significant bits if
- the pointer representation is larger than the integer type,
- sign-extends(1) if the pointer representation is smaller than the
- integer type, otherwise the bits are unchanged.
-
- A cast from integer to pointer discards most-significant bits if
- the pointer representation is smaller than the integer type,
- extends according to the signedness of the integer type if the
- pointer representation is larger than the integer type, otherwise
- the bits are unchanged.
-
- When casting from pointer to integer and back again, the resulting
- pointer must reference the same object as the original pointer,
- otherwise the behavior is undefined. That is, one may not use
- integer arithmetic to avoid the undefined behavior of pointer
- arithmetic as proscribed in C99 6.5.6/8.
-
- * `The size of the result of subtracting two pointers to elements of
- the same array (C90 6.3.6, C99 6.5.6).'
-
- The value is as specified in the standard and the type is
- determined by the ABI.
-
-
- ---------- Footnotes ----------
-
- (1) Future versions of GCC may zero-extend, or use a target-defined
-`ptr_extend' pattern. Do not rely on sign extension.
-
-
-File: gcc.info, Node: Hints implementation, Next: Structures unions enumerations and bit-fields implementation, Prev: Arrays and pointers implementation, Up: C Implementation
-
-4.8 Hints
-=========
-
- * `The extent to which suggestions made by using the `register'
- storage-class specifier are effective (C90 6.5.1, C99 6.7.1).'
-
- The `register' specifier affects code generation only in these
- ways:
-
- * When used as part of the register variable extension, see
- *note Explicit Reg Vars::.
-
- * When `-O0' is in use, the compiler allocates distinct stack
- memory for all variables that do not have the `register'
- storage-class specifier; if `register' is specified, the
- variable may have a shorter lifespan than the code would
- indicate and may never be placed in memory.
-
- * On some rare x86 targets, `setjmp' doesn't save the registers
- in all circumstances. In those cases, GCC doesn't allocate
- any variables in registers unless they are marked `register'.
-
-
- * `The extent to which suggestions made by using the inline function
- specifier are effective (C99 6.7.4).'
-
- GCC will not inline any functions if the `-fno-inline' option is
- used or if `-O0' is used. Otherwise, GCC may still be unable to
- inline a function for many reasons; the `-Winline' option may be
- used to determine if a function has not been inlined and why not.
-
-
-
-File: gcc.info, Node: Structures unions enumerations and bit-fields implementation, Next: Qualifiers implementation, Prev: Hints implementation, Up: C Implementation
-
-4.9 Structures, unions, enumerations, and bit-fields
-====================================================
-
- * `A member of a union object is accessed using a member of a
- different type (C90 6.3.2.3).'
-
- The relevant bytes of the representation of the object are treated
- as an object of the type used for the access. *Note
- Type-punning::. This may be a trap representation.
-
- * `Whether a "plain" `int' bit-field is treated as a `signed int'
- bit-field or as an `unsigned int' bit-field (C90 6.5.2, C90
- 6.5.2.1, C99 6.7.2, C99 6.7.2.1).'
-
- By default it is treated as `signed int' but this may be changed
- by the `-funsigned-bitfields' option.
-
- * `Allowable bit-field types other than `_Bool', `signed int', and
- `unsigned int' (C99 6.7.2.1).'
-
- No other types are permitted in strictly conforming mode.
-
- * `Whether a bit-field can straddle a storage-unit boundary (C90
- 6.5.2.1, C99 6.7.2.1).'
-
- Determined by ABI.
-
- * `The order of allocation of bit-fields within a unit (C90 6.5.2.1,
- C99 6.7.2.1).'
-
- Determined by ABI.
-
- * `The alignment of non-bit-field members of structures (C90
- 6.5.2.1, C99 6.7.2.1).'
-
- Determined by ABI.
-
- * `The integer type compatible with each enumerated type (C90
- 6.5.2.2, C99 6.7.2.2).'
-
- Normally, the type is `unsigned int' if there are no negative
- values in the enumeration, otherwise `int'. If `-fshort-enums' is
- specified, then if there are negative values it is the first of
- `signed char', `short' and `int' that can represent all the
- values, otherwise it is the first of `unsigned char', `unsigned
- short' and `unsigned int' that can represent all the values.
-
- On some targets, `-fshort-enums' is the default; this is
- determined by the ABI.
-
-
-
-File: gcc.info, Node: Qualifiers implementation, Next: Declarators implementation, Prev: Structures unions enumerations and bit-fields implementation, Up: C Implementation
-
-4.10 Qualifiers
-===============
-
- * `What constitutes an access to an object that has
- volatile-qualified type (C90 6.5.3, C99 6.7.3).'
-
- Such an object is normally accessed by pointers and used for
- accessing hardware. In most expressions, it is intuitively
- obvious what is a read and what is a write. For example
-
- volatile int *dst = SOMEVALUE;
- volatile int *src = SOMEOTHERVALUE;
- *dst = *src;
-
- will cause a read of the volatile object pointed to by SRC and
- store the value into the volatile object pointed to by DST. There
- is no guarantee that these reads and writes are atomic, especially
- for objects larger than `int'.
-
- However, if the volatile storage is not being modified, and the
- value of the volatile storage is not used, then the situation is
- less obvious. For example
-
- volatile int *src = SOMEVALUE;
- *src;
-
- According to the C standard, such an expression is an rvalue whose
- type is the unqualified version of its original type, i.e. `int'.
- Whether GCC interprets this as a read of the volatile object being
- pointed to or only as a request to evaluate the expression for its
- side-effects depends on this type.
-
- If it is a scalar type, or on most targets an aggregate type whose
- only member object is of a scalar type, or a union type whose
- member objects are of scalar types, the expression is interpreted
- by GCC as a read of the volatile object; in the other cases, the
- expression is only evaluated for its side-effects.
-
-
-
-File: gcc.info, Node: Declarators implementation, Next: Statements implementation, Prev: Qualifiers implementation, Up: C Implementation
-
-4.11 Declarators
-================
-
- * `The maximum number of declarators that may modify an arithmetic,
- structure or union type (C90 6.5.4).'
-
- GCC is only limited by available memory.
-
-
-
-File: gcc.info, Node: Statements implementation, Next: Preprocessing directives implementation, Prev: Declarators implementation, Up: C Implementation
-
-4.12 Statements
-===============
-
- * `The maximum number of `case' values in a `switch' statement (C90
- 6.6.4.2).'
-
- GCC is only limited by available memory.
-
-
-
-File: gcc.info, Node: Preprocessing directives implementation, Next: Library functions implementation, Prev: Statements implementation, Up: C Implementation
-
-4.13 Preprocessing directives
-=============================
-
-*Note Implementation-defined behavior: (cpp)Implementation-defined
-behavior, for details of these aspects of implementation-defined
-behavior.
-
- * `How sequences in both forms of header names are mapped to headers
- or external source file names (C90 6.1.7, C99 6.4.7).'
-
- * `Whether the value of a character constant in a constant expression
- that controls conditional inclusion matches the value of the same
- character constant in the execution character set (C90 6.8.1, C99
- 6.10.1).'
-
- * `Whether the value of a single-character character constant in a
- constant expression that controls conditional inclusion may have a
- negative value (C90 6.8.1, C99 6.10.1).'
-
- * `The places that are searched for an included `<>' delimited
- header, and how the places are specified or the header is
- identified (C90 6.8.2, C99 6.10.2).'
-
- * `How the named source file is searched for in an included `""'
- delimited header (C90 6.8.2, C99 6.10.2).'
-
- * `The method by which preprocessing tokens (possibly resulting from
- macro expansion) in a `#include' directive are combined into a
- header name (C90 6.8.2, C99 6.10.2).'
-
- * `The nesting limit for `#include' processing (C90 6.8.2, C99
- 6.10.2).'
-
- * `Whether the `#' operator inserts a `\' character before the `\'
- character that begins a universal character name in a character
- constant or string literal (C99 6.10.3.2).'
-
- * `The behavior on each recognized non-`STDC #pragma' directive (C90
- 6.8.6, C99 6.10.6).'
-
- *Note Pragmas: (cpp)Pragmas, for details of pragmas accepted by
- GCC on all targets. *Note Pragmas Accepted by GCC: Pragmas, for
- details of target-specific pragmas.
-
- * `The definitions for `__DATE__' and `__TIME__' when respectively,
- the date and time of translation are not available (C90 6.8.8, C99
- 6.10.8).'
-
-
-
-File: gcc.info, Node: Library functions implementation, Next: Architecture implementation, Prev: Preprocessing directives implementation, Up: C Implementation
-
-4.14 Library functions
-======================
-
-The behavior of most of these points are dependent on the implementation
-of the C library, and are not defined by GCC itself.
-
- * `The null pointer constant to which the macro `NULL' expands (C90
- 7.1.6, C99 7.17).'
-
- In `<stddef.h>', `NULL' expands to `((void *)0)'. GCC does not
- provide the other headers which define `NULL' and some library
- implementations may use other definitions in those headers.
-
-
-
-File: gcc.info, Node: Architecture implementation, Next: Locale-specific behavior implementation, Prev: Library functions implementation, Up: C Implementation
-
-4.15 Architecture
-=================
-
- * `The values or expressions assigned to the macros specified in the
- headers `<float.h>', `<limits.h>', and `<stdint.h>' (C90 and C99
- 5.2.4.2, C99 7.18.2, C99 7.18.3).'
-
- Determined by ABI.
-
- * `The number, order, and encoding of bytes in any object (when not
- explicitly specified in this International Standard) (C99
- 6.2.6.1).'
-
- Determined by ABI.
-
- * `The value of the result of the `sizeof' operator (C90 6.3.3.4,
- C99 6.5.3.4).'
-
- Determined by ABI.
-
-
-
-File: gcc.info, Node: Locale-specific behavior implementation, Prev: Architecture implementation, Up: C Implementation
-
-4.16 Locale-specific behavior
-=============================
-
-The behavior of these points are dependent on the implementation of the
-C library, and are not defined by GCC itself.
-
-
-File: gcc.info, Node: C++ Implementation, Next: C++ Extensions, Prev: C Extensions, Up: Top
-
-5 C++ Implementation-defined behavior
-*************************************
-
-A conforming implementation of ISO C++ is required to document its
-choice of behavior in each of the areas that are designated
-"implementation defined". The following lists all such areas, along
-with the section numbers from the ISO/IEC 14822:1998 and ISO/IEC
-14822:2003 standards. Some areas are only implementation-defined in
-one version of the standard.
-
- Some choices depend on the externally determined ABI for the platform
-(including standard character encodings) which GCC follows; these are
-listed as "determined by ABI" below. *Note Binary Compatibility:
-Compatibility, and `http://gcc.gnu.org/readings.html'. Some choices
-are documented in the preprocessor manual. *Note
-Implementation-defined behavior: (cpp)Implementation-defined behavior.
-Some choices are documented in the corresponding document for the C
-language. *Note C Implementation::. Some choices are made by the
-library and operating system (or other environment when compiling for a
-freestanding environment); refer to their documentation for details.
-
-* Menu:
-
-* Conditionally-supported behavior::
-* Exception handling::
-
-
-File: gcc.info, Node: Conditionally-supported behavior, Next: Exception handling, Up: C++ Implementation
-
-5.1 Conditionally-supported behavior
-====================================
-
-`Each implementation shall include documentation that identifies all
-conditionally-supported constructs that it does not support (C++0x
-1.4).'
-
- * `Whether an argument of class type with a non-trivial copy
- constructor or destructor can be passed to ... (C++0x 5.2.2).'
-
- Such argument passing is not supported.
-
-
-
-File: gcc.info, Node: Exception handling, Prev: Conditionally-supported behavior, Up: C++ Implementation
-
-5.2 Exception handling
-======================
-
- * `In the situation where no matching handler is found, it is
- implementation-defined whether or not the stack is unwound before
- std::terminate() is called (C++98 15.5.1).'
-
- The stack is not unwound before std::terminate is called.
-
-
-
-File: gcc.info, Node: C Extensions, Next: C++ Implementation, Prev: C Implementation, Up: Top
-
-6 Extensions to the C Language Family
-*************************************
-
-GNU C provides several language features not found in ISO standard C.
-(The `-pedantic' option directs GCC to print a warning message if any
-of these features is used.) To test for the availability of these
-features in conditional compilation, check for a predefined macro
-`__GNUC__', which is always defined under GCC.
-
- These extensions are available in C and Objective-C. Most of them are
-also available in C++. *Note Extensions to the C++ Language: C++
-Extensions, for extensions that apply _only_ to C++.
-
- Some features that are in ISO C99 but not C90 or C++ are also, as
-extensions, accepted by GCC in C90 mode and in C++.
-
-* Menu:
-
-* Statement Exprs:: Putting statements and declarations inside expressions.
-* Local Labels:: Labels local to a block.
-* Labels as Values:: Getting pointers to labels, and computed gotos.
-* Nested Functions:: As in Algol and Pascal, lexical scoping of functions.
-* Constructing Calls:: Dispatching a call to another function.
-* Typeof:: `typeof': referring to the type of an expression.
-* Conditionals:: Omitting the middle operand of a `?:' expression.
-* Long Long:: Double-word integers---`long long int'.
-* __int128:: 128-bit integers---`__int128'.
-* Complex:: Data types for complex numbers.
-* Floating Types:: Additional Floating Types.
-* Half-Precision:: Half-Precision Floating Point.
-* Decimal Float:: Decimal Floating Types.
-* Hex Floats:: Hexadecimal floating-point constants.
-* Fixed-Point:: Fixed-Point Types.
-* Named Address Spaces::Named address spaces.
-* Zero Length:: Zero-length arrays.
-* Variable Length:: Arrays whose length is computed at run time.
-* Empty Structures:: Structures with no members.
-* Variadic Macros:: Macros with a variable number of arguments.
-* Escaped Newlines:: Slightly looser rules for escaped newlines.
-* Subscripting:: Any array can be subscripted, even if not an lvalue.
-* Pointer Arith:: Arithmetic on `void'-pointers and function pointers.
-* Initializers:: Non-constant initializers.
-* Compound Literals:: Compound literals give structures, unions
- or arrays as values.
-* Designated Inits:: Labeling elements of initializers.
-* Cast to Union:: Casting to union type from any member of the union.
-* Case Ranges:: `case 1 ... 9' and such.
-* Mixed Declarations:: Mixing declarations and code.
-* Function Attributes:: Declaring that functions have no side effects,
- or that they can never return.
-* Attribute Syntax:: Formal syntax for attributes.
-* Function Prototypes:: Prototype declarations and old-style definitions.
-* C++ Comments:: C++ comments are recognized.
-* Dollar Signs:: Dollar sign is allowed in identifiers.
-* Character Escapes:: `\e' stands for the character <ESC>.
-* Variable Attributes:: Specifying attributes of variables.
-* Type Attributes:: Specifying attributes of types.
-* Alignment:: Inquiring about the alignment of a type or variable.
-* Inline:: Defining inline functions (as fast as macros).
-* Volatiles:: What constitutes an access to a volatile object.
-* Extended Asm:: Assembler instructions with C expressions as operands.
- (With them you can define ``built-in'' functions.)
-* Constraints:: Constraints for asm operands
-* Asm Labels:: Specifying the assembler name to use for a C symbol.
-* Explicit Reg Vars:: Defining variables residing in specified registers.
-* Alternate Keywords:: `__const__', `__asm__', etc., for header files.
-* Incomplete Enums:: `enum foo;', with details to follow.
-* Function Names:: Printable strings which are the name of the current
- function.
-* Return Address:: Getting the return or frame address of a function.
-* Vector Extensions:: Using vector instructions through built-in functions.
-* Offsetof:: Special syntax for implementing `offsetof'.
-* Atomic Builtins:: Built-in functions for atomic memory access.
-* Object Size Checking:: Built-in functions for limited buffer overflow
- checking.
-* Other Builtins:: Other built-in functions.
-* Target Builtins:: Built-in functions specific to particular targets.
-* Target Format Checks:: Format checks specific to particular targets.
-* Pragmas:: Pragmas accepted by GCC.
-* Unnamed Fields:: Unnamed struct/union fields within structs/unions.
-* Thread-Local:: Per-thread variables.
-* Binary constants:: Binary constants using the `0b' prefix.
-
-
-File: gcc.info, Node: Statement Exprs, Next: Local Labels, Up: C Extensions
-
-6.1 Statements and Declarations in Expressions
-==============================================
-
-A compound statement enclosed in parentheses may appear as an expression
-in GNU C. This allows you to use loops, switches, and local variables
-within an expression.
-
- Recall that a compound statement is a sequence of statements surrounded
-by braces; in this construct, parentheses go around the braces. For
-example:
-
- ({ int y = foo (); int z;
- if (y > 0) z = y;
- else z = - y;
- z; })
-
-is a valid (though slightly more complex than necessary) expression for
-the absolute value of `foo ()'.
-
- The last thing in the compound statement should be an expression
-followed by a semicolon; the value of this subexpression serves as the
-value of the entire construct. (If you use some other kind of statement
-last within the braces, the construct has type `void', and thus
-effectively no value.)
-
- This feature is especially useful in making macro definitions "safe"
-(so that they evaluate each operand exactly once). For example, the
-"maximum" function is commonly defined as a macro in standard C as
-follows:
-
- #define max(a,b) ((a) > (b) ? (a) : (b))
-
-But this definition computes either A or B twice, with bad results if
-the operand has side effects. In GNU C, if you know the type of the
-operands (here taken as `int'), you can define the macro safely as
-follows:
-
- #define maxint(a,b) \
- ({int _a = (a), _b = (b); _a > _b ? _a : _b; })
-
- Embedded statements are not allowed in constant expressions, such as
-the value of an enumeration constant, the width of a bit-field, or the
-initial value of a static variable.
-
- If you don't know the type of the operand, you can still do this, but
-you must use `typeof' (*note Typeof::).
-
- In G++, the result value of a statement expression undergoes array and
-function pointer decay, and is returned by value to the enclosing
-expression. For instance, if `A' is a class, then
-
- A a;
-
- ({a;}).Foo ()
-
-will construct a temporary `A' object to hold the result of the
-statement expression, and that will be used to invoke `Foo'. Therefore
-the `this' pointer observed by `Foo' will not be the address of `a'.
-
- Any temporaries created within a statement within a statement
-expression will be destroyed at the statement's end. This makes
-statement expressions inside macros slightly different from function
-calls. In the latter case temporaries introduced during argument
-evaluation will be destroyed at the end of the statement that includes
-the function call. In the statement expression case they will be
-destroyed during the statement expression. For instance,
-
- #define macro(a) ({__typeof__(a) b = (a); b + 3; })
- template<typename T> T function(T a) { T b = a; return b + 3; }
-
- void foo ()
- {
- macro (X ());
- function (X ());
- }
-
-will have different places where temporaries are destroyed. For the
-`macro' case, the temporary `X' will be destroyed just after the
-initialization of `b'. In the `function' case that temporary will be
-destroyed when the function returns.
-
- These considerations mean that it is probably a bad idea to use
-statement-expressions of this form in header files that are designed to
-work with C++. (Note that some versions of the GNU C Library contained
-header files using statement-expression that lead to precisely this
-bug.)
-
- Jumping into a statement expression with `goto' or using a `switch'
-statement outside the statement expression with a `case' or `default'
-label inside the statement expression is not permitted. Jumping into a
-statement expression with a computed `goto' (*note Labels as Values::)
-yields undefined behavior. Jumping out of a statement expression is
-permitted, but if the statement expression is part of a larger
-expression then it is unspecified which other subexpressions of that
-expression have been evaluated except where the language definition
-requires certain subexpressions to be evaluated before or after the
-statement expression. In any case, as with a function call the
-evaluation of a statement expression is not interleaved with the
-evaluation of other parts of the containing expression. For example,
-
- foo (), (({ bar1 (); goto a; 0; }) + bar2 ()), baz();
-
-will call `foo' and `bar1' and will not call `baz' but may or may not
-call `bar2'. If `bar2' is called, it will be called after `foo' and
-before `bar1'
-
-
-File: gcc.info, Node: Local Labels, Next: Labels as Values, Prev: Statement Exprs, Up: C Extensions
-
-6.2 Locally Declared Labels
-===========================
-
-GCC allows you to declare "local labels" in any nested block scope. A
-local label is just like an ordinary label, but you can only reference
-it (with a `goto' statement, or by taking its address) within the block
-in which it was declared.
-
- A local label declaration looks like this:
-
- __label__ LABEL;
-
-or
-
- __label__ LABEL1, LABEL2, /* ... */;
-
- Local label declarations must come at the beginning of the block,
-before any ordinary declarations or statements.
-
- The label declaration defines the label _name_, but does not define
-the label itself. You must do this in the usual way, with `LABEL:',
-within the statements of the statement expression.
-
- The local label feature is useful for complex macros. If a macro
-contains nested loops, a `goto' can be useful for breaking out of them.
-However, an ordinary label whose scope is the whole function cannot be
-used: if the macro can be expanded several times in one function, the
-label will be multiply defined in that function. A local label avoids
-this problem. For example:
-
- #define SEARCH(value, array, target) \
- do { \
- __label__ found; \
- typeof (target) _SEARCH_target = (target); \
- typeof (*(array)) *_SEARCH_array = (array); \
- int i, j; \
- int value; \
- for (i = 0; i < max; i++) \
- for (j = 0; j < max; j++) \
- if (_SEARCH_array[i][j] == _SEARCH_target) \
- { (value) = i; goto found; } \
- (value) = -1; \
- found:; \
- } while (0)
-
- This could also be written using a statement-expression:
-
- #define SEARCH(array, target) \
- ({ \
- __label__ found; \
- typeof (target) _SEARCH_target = (target); \
- typeof (*(array)) *_SEARCH_array = (array); \
- int i, j; \
- int value; \
- for (i = 0; i < max; i++) \
- for (j = 0; j < max; j++) \
- if (_SEARCH_array[i][j] == _SEARCH_target) \
- { value = i; goto found; } \
- value = -1; \
- found: \
- value; \
- })
-
- Local label declarations also make the labels they declare visible to
-nested functions, if there are any. *Note Nested Functions::, for
-details.
-
-
-File: gcc.info, Node: Labels as Values, Next: Nested Functions, Prev: Local Labels, Up: C Extensions
-
-6.3 Labels as Values
-====================
-
-You can get the address of a label defined in the current function (or
-a containing function) with the unary operator `&&'. The value has
-type `void *'. This value is a constant and can be used wherever a
-constant of that type is valid. For example:
-
- void *ptr;
- /* ... */
- ptr = &&foo;
-
- To use these values, you need to be able to jump to one. This is done
-with the computed goto statement(1), `goto *EXP;'. For example,
-
- goto *ptr;
-
-Any expression of type `void *' is allowed.
-
- One way of using these constants is in initializing a static array that
-will serve as a jump table:
-
- static void *array[] = { &&foo, &&bar, &&hack };
-
- Then you can select a label with indexing, like this:
-
- goto *array[i];
-
-Note that this does not check whether the subscript is in bounds--array
-indexing in C never does that.
-
- Such an array of label values serves a purpose much like that of the
-`switch' statement. The `switch' statement is cleaner, so use that
-rather than an array unless the problem does not fit a `switch'
-statement very well.
-
- Another use of label values is in an interpreter for threaded code.
-The labels within the interpreter function can be stored in the
-threaded code for super-fast dispatching.
-
- You may not use this mechanism to jump to code in a different function.
-If you do that, totally unpredictable things will happen. The best way
-to avoid this is to store the label address only in automatic variables
-and never pass it as an argument.
-
- An alternate way to write the above example is
-
- static const int array[] = { &&foo - &&foo, &&bar - &&foo,
- &&hack - &&foo };
- goto *(&&foo + array[i]);
-
-This is more friendly to code living in shared libraries, as it reduces
-the number of dynamic relocations that are needed, and by consequence,
-allows the data to be read-only.
-
- The `&&foo' expressions for the same label might have different values
-if the containing function is inlined or cloned. If a program relies
-on them being always the same,
-`__attribute__((__noinline__,__noclone__))' should be used to prevent
-inlining and cloning. If `&&foo' is used in a static variable
-initializer, inlining and cloning is forbidden.
-
- ---------- Footnotes ----------
-
- (1) The analogous feature in Fortran is called an assigned goto, but
-that name seems inappropriate in C, where one can do more than simply
-store label addresses in label variables.
-
-
-File: gcc.info, Node: Nested Functions, Next: Constructing Calls, Prev: Labels as Values, Up: C Extensions
-
-6.4 Nested Functions
-====================
-
-A "nested function" is a function defined inside another function.
-(Nested functions are not supported for GNU C++.) The nested function's
-name is local to the block where it is defined. For example, here we
-define a nested function named `square', and call it twice:
-
- foo (double a, double b)
- {
- double square (double z) { return z * z; }
-
- return square (a) + square (b);
- }
-
- The nested function can access all the variables of the containing
-function that are visible at the point of its definition. This is
-called "lexical scoping". For example, here we show a nested function
-which uses an inherited variable named `offset':
-
- bar (int *array, int offset, int size)
- {
- int access (int *array, int index)
- { return array[index + offset]; }
- int i;
- /* ... */
- for (i = 0; i < size; i++)
- /* ... */ access (array, i) /* ... */
- }
-
- Nested function definitions are permitted within functions in the
-places where variable definitions are allowed; that is, in any block,
-mixed with the other declarations and statements in the block.
-
- It is possible to call the nested function from outside the scope of
-its name by storing its address or passing the address to another
-function:
-
- hack (int *array, int size)
- {
- void store (int index, int value)
- { array[index] = value; }
-
- intermediate (store, size);
- }
-
- Here, the function `intermediate' receives the address of `store' as
-an argument. If `intermediate' calls `store', the arguments given to
-`store' are used to store into `array'. But this technique works only
-so long as the containing function (`hack', in this example) does not
-exit.
-
- If you try to call the nested function through its address after the
-containing function has exited, all hell will break loose. If you try
-to call it after a containing scope level has exited, and if it refers
-to some of the variables that are no longer in scope, you may be lucky,
-but it's not wise to take the risk. If, however, the nested function
-does not refer to anything that has gone out of scope, you should be
-safe.
-
- GCC implements taking the address of a nested function using a
-technique called "trampolines". This technique was described in
-`Lexical Closures for C++' (Thomas M. Breuel, USENIX C++ Conference
-Proceedings, October 17-21, 1988).
-
- A nested function can jump to a label inherited from a containing
-function, provided the label was explicitly declared in the containing
-function (*note Local Labels::). Such a jump returns instantly to the
-containing function, exiting the nested function which did the `goto'
-and any intermediate functions as well. Here is an example:
-
- bar (int *array, int offset, int size)
- {
- __label__ failure;
- int access (int *array, int index)
- {
- if (index > size)
- goto failure;
- return array[index + offset];
- }
- int i;
- /* ... */
- for (i = 0; i < size; i++)
- /* ... */ access (array, i) /* ... */
- /* ... */
- return 0;
-
- /* Control comes here from `access'
- if it detects an error. */
- failure:
- return -1;
- }
-
- A nested function always has no linkage. Declaring one with `extern'
-or `static' is erroneous. If you need to declare the nested function
-before its definition, use `auto' (which is otherwise meaningless for
-function declarations).
-
- bar (int *array, int offset, int size)
- {
- __label__ failure;
- auto int access (int *, int);
- /* ... */
- int access (int *array, int index)
- {
- if (index > size)
- goto failure;
- return array[index + offset];
- }
- /* ... */
- }
-
-
-File: gcc.info, Node: Constructing Calls, Next: Typeof, Prev: Nested Functions, Up: C Extensions
-
-6.5 Constructing Function Calls
-===============================
-
-Using the built-in functions described below, you can record the
-arguments a function received, and call another function with the same
-arguments, without knowing the number or types of the arguments.
-
- You can also record the return value of that function call, and later
-return that value, without knowing what data type the function tried to
-return (as long as your caller expects that data type).
-
- However, these built-in functions may interact badly with some
-sophisticated features or other extensions of the language. It is,
-therefore, not recommended to use them outside very simple functions
-acting as mere forwarders for their arguments.
-
- -- Built-in Function: void * __builtin_apply_args ()
- This built-in function returns a pointer to data describing how to
- perform a call with the same arguments as were passed to the
- current function.
-
- The function saves the arg pointer register, structure value
- address, and all registers that might be used to pass arguments to
- a function into a block of memory allocated on the stack. Then it
- returns the address of that block.
-
- -- Built-in Function: void * __builtin_apply (void (*FUNCTION)(), void
- *ARGUMENTS, size_t SIZE)
- This built-in function invokes FUNCTION with a copy of the
- parameters described by ARGUMENTS and SIZE.
-
- The value of ARGUMENTS should be the value returned by
- `__builtin_apply_args'. The argument SIZE specifies the size of
- the stack argument data, in bytes.
-
- This function returns a pointer to data describing how to return
- whatever value was returned by FUNCTION. The data is saved in a
- block of memory allocated on the stack.
-
- It is not always simple to compute the proper value for SIZE. The
- value is used by `__builtin_apply' to compute the amount of data
- that should be pushed on the stack and copied from the incoming
- argument area.
-
- -- Built-in Function: void __builtin_return (void *RESULT)
- This built-in function returns the value described by RESULT from
- the containing function. You should specify, for RESULT, a value
- returned by `__builtin_apply'.
-
- -- Built-in Function: __builtin_va_arg_pack ()
- This built-in function represents all anonymous arguments of an
- inline function. It can be used only in inline functions which
- will be always inlined, never compiled as a separate function,
- such as those using `__attribute__ ((__always_inline__))' or
- `__attribute__ ((__gnu_inline__))' extern inline functions. It
- must be only passed as last argument to some other function with
- variable arguments. This is useful for writing small wrapper
- inlines for variable argument functions, when using preprocessor
- macros is undesirable. For example:
- extern int myprintf (FILE *f, const char *format, ...);
- extern inline __attribute__ ((__gnu_inline__)) int
- myprintf (FILE *f, const char *format, ...)
- {
- int r = fprintf (f, "myprintf: ");
- if (r < 0)
- return r;
- int s = fprintf (f, format, __builtin_va_arg_pack ());
- if (s < 0)
- return s;
- return r + s;
- }
-
- -- Built-in Function: size_t __builtin_va_arg_pack_len ()
- This built-in function returns the number of anonymous arguments of
- an inline function. It can be used only in inline functions which
- will be always inlined, never compiled as a separate function, such
- as those using `__attribute__ ((__always_inline__))' or
- `__attribute__ ((__gnu_inline__))' extern inline functions. For
- example following will do link or runtime checking of open
- arguments for optimized code:
- #ifdef __OPTIMIZE__
- extern inline __attribute__((__gnu_inline__)) int
- myopen (const char *path, int oflag, ...)
- {
- if (__builtin_va_arg_pack_len () > 1)
- warn_open_too_many_arguments ();
-
- if (__builtin_constant_p (oflag))
- {
- if ((oflag & O_CREAT) != 0 && __builtin_va_arg_pack_len () < 1)
- {
- warn_open_missing_mode ();
- return __open_2 (path, oflag);
- }
- return open (path, oflag, __builtin_va_arg_pack ());
- }
-
- if (__builtin_va_arg_pack_len () < 1)
- return __open_2 (path, oflag);
-
- return open (path, oflag, __builtin_va_arg_pack ());
- }
- #endif
-
-
-File: gcc.info, Node: Typeof, Next: Conditionals, Prev: Constructing Calls, Up: C Extensions
-
-6.6 Referring to a Type with `typeof'
-=====================================
-
-Another way to refer to the type of an expression is with `typeof'.
-The syntax of using of this keyword looks like `sizeof', but the
-construct acts semantically like a type name defined with `typedef'.
-
- There are two ways of writing the argument to `typeof': with an
-expression or with a type. Here is an example with an expression:
-
- typeof (x[0](1))
-
-This assumes that `x' is an array of pointers to functions; the type
-described is that of the values of the functions.
-
- Here is an example with a typename as the argument:
-
- typeof (int *)
-
-Here the type described is that of pointers to `int'.
-
- If you are writing a header file that must work when included in ISO C
-programs, write `__typeof__' instead of `typeof'. *Note Alternate
-Keywords::.
-
- A `typeof'-construct can be used anywhere a typedef name could be
-used. For example, you can use it in a declaration, in a cast, or
-inside of `sizeof' or `typeof'.
-
- The operand of `typeof' is evaluated for its side effects if and only
-if it is an expression of variably modified type or the name of such a
-type.
-
- `typeof' is often useful in conjunction with the
-statements-within-expressions feature. Here is how the two together can
-be used to define a safe "maximum" macro that operates on any
-arithmetic type and evaluates each of its arguments exactly once:
-
- #define max(a,b) \
- ({ typeof (a) _a = (a); \
- typeof (b) _b = (b); \
- _a > _b ? _a : _b; })
-
- The reason for using names that start with underscores for the local
-variables is to avoid conflicts with variable names that occur within
-the expressions that are substituted for `a' and `b'. Eventually we
-hope to design a new form of declaration syntax that allows you to
-declare variables whose scopes start only after their initializers;
-this will be a more reliable way to prevent such conflicts.
-
-Some more examples of the use of `typeof':
-
- * This declares `y' with the type of what `x' points to.
-
- typeof (*x) y;
-
- * This declares `y' as an array of such values.
-
- typeof (*x) y[4];
-
- * This declares `y' as an array of pointers to characters:
-
- typeof (typeof (char *)[4]) y;
-
- It is equivalent to the following traditional C declaration:
-
- char *y[4];
-
- To see the meaning of the declaration using `typeof', and why it
- might be a useful way to write, rewrite it with these macros:
-
- #define pointer(T) typeof(T *)
- #define array(T, N) typeof(T [N])
-
- Now the declaration can be rewritten this way:
-
- array (pointer (char), 4) y;
-
- Thus, `array (pointer (char), 4)' is the type of arrays of 4
- pointers to `char'.
-
- _Compatibility Note:_ In addition to `typeof', GCC 2 supported a more
-limited extension which permitted one to write
-
- typedef T = EXPR;
-
-with the effect of declaring T to have the type of the expression EXPR.
-This extension does not work with GCC 3 (versions between 3.0 and 3.2
-will crash; 3.2.1 and later give an error). Code which relies on it
-should be rewritten to use `typeof':
-
- typedef typeof(EXPR) T;
-
-This will work with all versions of GCC.
-
-
-File: gcc.info, Node: Conditionals, Next: Long Long, Prev: Typeof, Up: C Extensions
-
-6.7 Conditionals with Omitted Operands
-======================================
-
-The middle operand in a conditional expression may be omitted. Then if
-the first operand is nonzero, its value is the value of the conditional
-expression.
-
- Therefore, the expression
-
- x ? : y
-
-has the value of `x' if that is nonzero; otherwise, the value of `y'.
-
- This example is perfectly equivalent to
-
- x ? x : y
-
-In this simple case, the ability to omit the middle operand is not
-especially useful. When it becomes useful is when the first operand
-does, or may (if it is a macro argument), contain a side effect. Then
-repeating the operand in the middle would perform the side effect
-twice. Omitting the middle operand uses the value already computed
-without the undesirable effects of recomputing it.
-
-
-File: gcc.info, Node: __int128, Next: Complex, Prev: Long Long, Up: C Extensions
-
-6.8 128-bits integers
-=====================
-
-As an extension the integer scalar type `__int128' is supported for
-targets having an integer mode wide enough to hold 128-bit. Simply
-write `__int128' for a signed 128-bit integer, or `unsigned __int128'
-for an unsigned 128-bit integer. There is no support in GCC to express
-an integer constant of type `__int128' for targets having `long long'
-integer with less then 128 bit width.
-
-
-File: gcc.info, Node: Long Long, Next: __int128, Prev: Conditionals, Up: C Extensions
-
-6.9 Double-Word Integers
-========================
-
-ISO C99 supports data types for integers that are at least 64 bits wide,
-and as an extension GCC supports them in C90 mode and in C++. Simply
-write `long long int' for a signed integer, or `unsigned long long int'
-for an unsigned integer. To make an integer constant of type `long
-long int', add the suffix `LL' to the integer. To make an integer
-constant of type `unsigned long long int', add the suffix `ULL' to the
-integer.
-
- You can use these types in arithmetic like any other integer types.
-Addition, subtraction, and bitwise boolean operations on these types
-are open-coded on all types of machines. Multiplication is open-coded
-if the machine supports fullword-to-doubleword a widening multiply
-instruction. Division and shifts are open-coded only on machines that
-provide special support. The operations that are not open-coded use
-special library routines that come with GCC.
-
- There may be pitfalls when you use `long long' types for function
-arguments, unless you declare function prototypes. If a function
-expects type `int' for its argument, and you pass a value of type `long
-long int', confusion will result because the caller and the subroutine
-will disagree about the number of bytes for the argument. Likewise, if
-the function expects `long long int' and you pass `int'. The best way
-to avoid such problems is to use prototypes.
-
-
-File: gcc.info, Node: Complex, Next: Floating Types, Prev: __int128, Up: C Extensions
-
-6.10 Complex Numbers
-====================
-
-ISO C99 supports complex floating data types, and as an extension GCC
-supports them in C90 mode and in C++, and supports complex integer data
-types which are not part of ISO C99. You can declare complex types
-using the keyword `_Complex'. As an extension, the older GNU keyword
-`__complex__' is also supported.
-
- For example, `_Complex double x;' declares `x' as a variable whose
-real part and imaginary part are both of type `double'. `_Complex
-short int y;' declares `y' to have real and imaginary parts of type
-`short int'; this is not likely to be useful, but it shows that the set
-of complex types is complete.
-
- To write a constant with a complex data type, use the suffix `i' or
-`j' (either one; they are equivalent). For example, `2.5fi' has type
-`_Complex float' and `3i' has type `_Complex int'. Such a constant
-always has a pure imaginary value, but you can form any complex value
-you like by adding one to a real constant. This is a GNU extension; if
-you have an ISO C99 conforming C library (such as GNU libc), and want
-to construct complex constants of floating type, you should include
-`<complex.h>' and use the macros `I' or `_Complex_I' instead.
-
- To extract the real part of a complex-valued expression EXP, write
-`__real__ EXP'. Likewise, use `__imag__' to extract the imaginary
-part. This is a GNU extension; for values of floating type, you should
-use the ISO C99 functions `crealf', `creal', `creall', `cimagf',
-`cimag' and `cimagl', declared in `<complex.h>' and also provided as
-built-in functions by GCC.
-
- The operator `~' performs complex conjugation when used on a value
-with a complex type. This is a GNU extension; for values of floating
-type, you should use the ISO C99 functions `conjf', `conj' and `conjl',
-declared in `<complex.h>' and also provided as built-in functions by
-GCC.
-
- GCC can allocate complex automatic variables in a noncontiguous
-fashion; it's even possible for the real part to be in a register while
-the imaginary part is on the stack (or vice-versa). Only the DWARF2
-debug info format can represent this, so use of DWARF2 is recommended.
-If you are using the stabs debug info format, GCC describes a
-noncontiguous complex variable as if it were two separate variables of
-noncomplex type. If the variable's actual name is `foo', the two
-fictitious variables are named `foo$real' and `foo$imag'. You can
-examine and set these two fictitious variables with your debugger.
-
-
-File: gcc.info, Node: Floating Types, Next: Half-Precision, Prev: Complex, Up: C Extensions
-
-6.11 Additional Floating Types
-==============================
-
-As an extension, the GNU C compiler supports additional floating types,
-`__float80' and `__float128' to support 80bit (`XFmode') and 128 bit
-(`TFmode') floating types. Support for additional types includes the
-arithmetic operators: add, subtract, multiply, divide; unary arithmetic
-operators; relational operators; equality operators; and conversions to
-and from integer and other floating types. Use a suffix `w' or `W' in
-a literal constant of type `__float80' and `q' or `Q' for `_float128'.
-You can declare complex types using the corresponding internal complex
-type, `XCmode' for `__float80' type and `TCmode' for `__float128' type:
-
- typedef _Complex float __attribute__((mode(TC))) _Complex128;
- typedef _Complex float __attribute__((mode(XC))) _Complex80;
-
- Not all targets support additional floating point types. `__float80'
-and `__float128' types are supported on i386, x86_64 and ia64 targets.
-The `__float128' type is supported on hppa HP-UX targets.
-
-
-File: gcc.info, Node: Half-Precision, Next: Decimal Float, Prev: Floating Types, Up: C Extensions
-
-6.12 Half-Precision Floating Point
-==================================
-
-On ARM targets, GCC supports half-precision (16-bit) floating point via
-the `__fp16' type. You must enable this type explicitly with the
-`-mfp16-format' command-line option in order to use it.
-
- ARM supports two incompatible representations for half-precision
-floating-point values. You must choose one of the representations and
-use it consistently in your program.
-
- Specifying `-mfp16-format=ieee' selects the IEEE 754-2008 format.
-This format can represent normalized values in the range of 2^-14 to
-65504. There are 11 bits of significand precision, approximately 3
-decimal digits.
-
- Specifying `-mfp16-format=alternative' selects the ARM alternative
-format. This representation is similar to the IEEE format, but does
-not support infinities or NaNs. Instead, the range of exponents is
-extended, so that this format can represent normalized values in the
-range of 2^-14 to 131008.
-
- The `__fp16' type is a storage format only. For purposes of
-arithmetic and other operations, `__fp16' values in C or C++
-expressions are automatically promoted to `float'. In addition, you
-cannot declare a function with a return value or parameters of type
-`__fp16'.
-
- Note that conversions from `double' to `__fp16' involve an
-intermediate conversion to `float'. Because of rounding, this can
-sometimes produce a different result than a direct conversion.
-
- ARM provides hardware support for conversions between `__fp16' and
-`float' values as an extension to VFP and NEON (Advanced SIMD). GCC
-generates code using these hardware instructions if you compile with
-options to select an FPU that provides them; for example,
-`-mfpu=neon-fp16 -mfloat-abi=softfp', in addition to the
-`-mfp16-format' option to select a half-precision format.
-
- Language-level support for the `__fp16' data type is independent of
-whether GCC generates code using hardware floating-point instructions.
-In cases where hardware support is not specified, GCC implements
-conversions between `__fp16' and `float' values as library calls.
-
-
-File: gcc.info, Node: Decimal Float, Next: Hex Floats, Prev: Half-Precision, Up: C Extensions
-
-6.13 Decimal Floating Types
-===========================
-
-As an extension, the GNU C compiler supports decimal floating types as
-defined in the N1312 draft of ISO/IEC WDTR24732. Support for decimal
-floating types in GCC will evolve as the draft technical report changes.
-Calling conventions for any target might also change. Not all targets
-support decimal floating types.
-
- The decimal floating types are `_Decimal32', `_Decimal64', and
-`_Decimal128'. They use a radix of ten, unlike the floating types
-`float', `double', and `long double' whose radix is not specified by
-the C standard but is usually two.
-
- Support for decimal floating types includes the arithmetic operators
-add, subtract, multiply, divide; unary arithmetic operators; relational
-operators; equality operators; and conversions to and from integer and
-other floating types. Use a suffix `df' or `DF' in a literal constant
-of type `_Decimal32', `dd' or `DD' for `_Decimal64', and `dl' or `DL'
-for `_Decimal128'.
-
- GCC support of decimal float as specified by the draft technical report
-is incomplete:
-
- * When the value of a decimal floating type cannot be represented in
- the integer type to which it is being converted, the result is
- undefined rather than the result value specified by the draft
- technical report.
-
- * GCC does not provide the C library functionality associated with
- `math.h', `fenv.h', `stdio.h', `stdlib.h', and `wchar.h', which
- must come from a separate C library implementation. Because of
- this the GNU C compiler does not define macro `__STDC_DEC_FP__' to
- indicate that the implementation conforms to the technical report.
-
- Types `_Decimal32', `_Decimal64', and `_Decimal128' are supported by
-the DWARF2 debug information format.
-
-
-File: gcc.info, Node: Hex Floats, Next: Fixed-Point, Prev: Decimal Float, Up: C Extensions
-
-6.14 Hex Floats
-===============
-
-ISO C99 supports floating-point numbers written not only in the usual
-decimal notation, such as `1.55e1', but also numbers such as `0x1.fp3'
-written in hexadecimal format. As a GNU extension, GCC supports this
-in C90 mode (except in some cases when strictly conforming) and in C++.
-In that format the `0x' hex introducer and the `p' or `P' exponent
-field are mandatory. The exponent is a decimal number that indicates
-the power of 2 by which the significant part will be multiplied. Thus
-`0x1.f' is 1 15/16, `p3' multiplies it by 8, and the value of `0x1.fp3'
-is the same as `1.55e1'.
-
- Unlike for floating-point numbers in the decimal notation the exponent
-is always required in the hexadecimal notation. Otherwise the compiler
-would not be able to resolve the ambiguity of, e.g., `0x1.f'. This
-could mean `1.0f' or `1.9375' since `f' is also the extension for
-floating-point constants of type `float'.
-
-
-File: gcc.info, Node: Fixed-Point, Next: Named Address Spaces, Prev: Hex Floats, Up: C Extensions
-
-6.15 Fixed-Point Types
-======================
-
-As an extension, the GNU C compiler supports fixed-point types as
-defined in the N1169 draft of ISO/IEC DTR 18037. Support for
-fixed-point types in GCC will evolve as the draft technical report
-changes. Calling conventions for any target might also change. Not
-all targets support fixed-point types.
-
- The fixed-point types are `short _Fract', `_Fract', `long _Fract',
-`long long _Fract', `unsigned short _Fract', `unsigned _Fract',
-`unsigned long _Fract', `unsigned long long _Fract', `_Sat short
-_Fract', `_Sat _Fract', `_Sat long _Fract', `_Sat long long _Fract',
-`_Sat unsigned short _Fract', `_Sat unsigned _Fract', `_Sat unsigned
-long _Fract', `_Sat unsigned long long _Fract', `short _Accum',
-`_Accum', `long _Accum', `long long _Accum', `unsigned short _Accum',
-`unsigned _Accum', `unsigned long _Accum', `unsigned long long _Accum',
-`_Sat short _Accum', `_Sat _Accum', `_Sat long _Accum', `_Sat long long
-_Accum', `_Sat unsigned short _Accum', `_Sat unsigned _Accum', `_Sat
-unsigned long _Accum', `_Sat unsigned long long _Accum'.
-
- Fixed-point data values contain fractional and optional integral parts.
-The format of fixed-point data varies and depends on the target machine.
-
- Support for fixed-point types includes:
- * prefix and postfix increment and decrement operators (`++', `--')
-
- * unary arithmetic operators (`+', `-', `!')
-
- * binary arithmetic operators (`+', `-', `*', `/')
-
- * binary shift operators (`<<', `>>')
-
- * relational operators (`<', `<=', `>=', `>')
-
- * equality operators (`==', `!=')
-
- * assignment operators (`+=', `-=', `*=', `/=', `<<=', `>>=')
-
- * conversions to and from integer, floating-point, or fixed-point
- types
-
- Use a suffix in a fixed-point literal constant:
- * `hr' or `HR' for `short _Fract' and `_Sat short _Fract'
-
- * `r' or `R' for `_Fract' and `_Sat _Fract'
-
- * `lr' or `LR' for `long _Fract' and `_Sat long _Fract'
-
- * `llr' or `LLR' for `long long _Fract' and `_Sat long long _Fract'
-
- * `uhr' or `UHR' for `unsigned short _Fract' and `_Sat unsigned
- short _Fract'
-
- * `ur' or `UR' for `unsigned _Fract' and `_Sat unsigned _Fract'
-
- * `ulr' or `ULR' for `unsigned long _Fract' and `_Sat unsigned long
- _Fract'
-
- * `ullr' or `ULLR' for `unsigned long long _Fract' and `_Sat
- unsigned long long _Fract'
-
- * `hk' or `HK' for `short _Accum' and `_Sat short _Accum'
-
- * `k' or `K' for `_Accum' and `_Sat _Accum'
-
- * `lk' or `LK' for `long _Accum' and `_Sat long _Accum'
-
- * `llk' or `LLK' for `long long _Accum' and `_Sat long long _Accum'
-
- * `uhk' or `UHK' for `unsigned short _Accum' and `_Sat unsigned
- short _Accum'
-
- * `uk' or `UK' for `unsigned _Accum' and `_Sat unsigned _Accum'
-
- * `ulk' or `ULK' for `unsigned long _Accum' and `_Sat unsigned long
- _Accum'
-
- * `ullk' or `ULLK' for `unsigned long long _Accum' and `_Sat
- unsigned long long _Accum'
-
- GCC support of fixed-point types as specified by the draft technical
-report is incomplete:
-
- * Pragmas to control overflow and rounding behaviors are not
- implemented.
-
- Fixed-point types are supported by the DWARF2 debug information format.
-
-
-File: gcc.info, Node: Named Address Spaces, Next: Zero Length, Prev: Fixed-Point, Up: C Extensions
-
-6.16 Named address spaces
-=========================
-
-As an extension, the GNU C compiler supports named address spaces as
-defined in the N1275 draft of ISO/IEC DTR 18037. Support for named
-address spaces in GCC will evolve as the draft technical report changes.
-Calling conventions for any target might also change. At present, only
-the SPU and M32C targets support other address spaces. On the SPU
-target, for example, variables may be declared as belonging to another
-address space by qualifying the type with the `__ea' address space
-identifier:
-
- extern int __ea i;
-
- When the variable `i' is accessed, the compiler will generate special
-code to access this variable. It may use runtime library support, or
-generate special machine instructions to access that address space.
-
- The `__ea' identifier may be used exactly like any other C type
-qualifier (e.g., `const' or `volatile'). See the N1275 document for
-more details.
-
- On the M32C target, with the R8C and M16C cpu variants, variables
-qualified with `__far' are accessed using 32-bit addresses in order to
-access memory beyond the first 64k bytes. If `__far' is used with the
-M32CM or M32C cpu variants, it has no effect.
-
-
-File: gcc.info, Node: Zero Length, Next: Variable Length, Prev: Named Address Spaces, Up: C Extensions
-
-6.17 Arrays of Length Zero
-==========================
-
-Zero-length arrays are allowed in GNU C. They are very useful as the
-last element of a structure which is really a header for a
-variable-length object:
-
- struct line {
- int length;
- char contents[0];
- };
-
- struct line *thisline = (struct line *)
- malloc (sizeof (struct line) + this_length);
- thisline->length = this_length;
-
- In ISO C90, you would have to give `contents' a length of 1, which
-means either you waste space or complicate the argument to `malloc'.
-
- In ISO C99, you would use a "flexible array member", which is slightly
-different in syntax and semantics:
-
- * Flexible array members are written as `contents[]' without the `0'.
-
- * Flexible array members have incomplete type, and so the `sizeof'
- operator may not be applied. As a quirk of the original
- implementation of zero-length arrays, `sizeof' evaluates to zero.
-
- * Flexible array members may only appear as the last member of a
- `struct' that is otherwise non-empty.
-
- * A structure containing a flexible array member, or a union
- containing such a structure (possibly recursively), may not be a
- member of a structure or an element of an array. (However, these
- uses are permitted by GCC as extensions.)
-
- GCC versions before 3.0 allowed zero-length arrays to be statically
-initialized, as if they were flexible arrays. In addition to those
-cases that were useful, it also allowed initializations in situations
-that would corrupt later data. Non-empty initialization of zero-length
-arrays is now treated like any case where there are more initializer
-elements than the array holds, in that a suitable warning about "excess
-elements in array" is given, and the excess elements (all of them, in
-this case) are ignored.
-
- Instead GCC allows static initialization of flexible array members.
-This is equivalent to defining a new structure containing the original
-structure followed by an array of sufficient size to contain the data.
-I.e. in the following, `f1' is constructed as if it were declared like
-`f2'.
-
- struct f1 {
- int x; int y[];
- } f1 = { 1, { 2, 3, 4 } };
-
- struct f2 {
- struct f1 f1; int data[3];
- } f2 = { { 1 }, { 2, 3, 4 } };
-
-The convenience of this extension is that `f1' has the desired type,
-eliminating the need to consistently refer to `f2.f1'.
-
- This has symmetry with normal static arrays, in that an array of
-unknown size is also written with `[]'.
-
- Of course, this extension only makes sense if the extra data comes at
-the end of a top-level object, as otherwise we would be overwriting
-data at subsequent offsets. To avoid undue complication and confusion
-with initialization of deeply nested arrays, we simply disallow any
-non-empty initialization except when the structure is the top-level
-object. For example:
-
- struct foo { int x; int y[]; };
- struct bar { struct foo z; };
-
- struct foo a = { 1, { 2, 3, 4 } }; // Valid.
- struct bar b = { { 1, { 2, 3, 4 } } }; // Invalid.
- struct bar c = { { 1, { } } }; // Valid.
- struct foo d[1] = { { 1 { 2, 3, 4 } } }; // Invalid.
-
-
-File: gcc.info, Node: Empty Structures, Next: Variadic Macros, Prev: Variable Length, Up: C Extensions
-
-6.18 Structures With No Members
-===============================
-
-GCC permits a C structure to have no members:
-
- struct empty {
- };
-
- The structure will have size zero. In C++, empty structures are part
-of the language. G++ treats empty structures as if they had a single
-member of type `char'.
-
-
-File: gcc.info, Node: Variable Length, Next: Empty Structures, Prev: Zero Length, Up: C Extensions
-
-6.19 Arrays of Variable Length
-==============================
-
-Variable-length automatic arrays are allowed in ISO C99, and as an
-extension GCC accepts them in C90 mode and in C++. These arrays are
-declared like any other automatic arrays, but with a length that is not
-a constant expression. The storage is allocated at the point of
-declaration and deallocated when the brace-level is exited. For
-example:
-
- FILE *
- concat_fopen (char *s1, char *s2, char *mode)
- {
- char str[strlen (s1) + strlen (s2) + 1];
- strcpy (str, s1);
- strcat (str, s2);
- return fopen (str, mode);
- }
-
- Jumping or breaking out of the scope of the array name deallocates the
-storage. Jumping into the scope is not allowed; you get an error
-message for it.
-
- You can use the function `alloca' to get an effect much like
-variable-length arrays. The function `alloca' is available in many
-other C implementations (but not in all). On the other hand,
-variable-length arrays are more elegant.
-
- There are other differences between these two methods. Space allocated
-with `alloca' exists until the containing _function_ returns. The
-space for a variable-length array is deallocated as soon as the array
-name's scope ends. (If you use both variable-length arrays and
-`alloca' in the same function, deallocation of a variable-length array
-will also deallocate anything more recently allocated with `alloca'.)
-
- You can also use variable-length arrays as arguments to functions:
-
- struct entry
- tester (int len, char data[len][len])
- {
- /* ... */
- }
-
- The length of an array is computed once when the storage is allocated
-and is remembered for the scope of the array in case you access it with
-`sizeof'.
-
- If you want to pass the array first and the length afterward, you can
-use a forward declaration in the parameter list--another GNU extension.
-
- struct entry
- tester (int len; char data[len][len], int len)
- {
- /* ... */
- }
-
- The `int len' before the semicolon is a "parameter forward
-declaration", and it serves the purpose of making the name `len' known
-when the declaration of `data' is parsed.
-
- You can write any number of such parameter forward declarations in the
-parameter list. They can be separated by commas or semicolons, but the
-last one must end with a semicolon, which is followed by the "real"
-parameter declarations. Each forward declaration must match a "real"
-declaration in parameter name and data type. ISO C99 does not support
-parameter forward declarations.
-
-
-File: gcc.info, Node: Variadic Macros, Next: Escaped Newlines, Prev: Empty Structures, Up: C Extensions
-
-6.20 Macros with a Variable Number of Arguments.
-================================================
-
-In the ISO C standard of 1999, a macro can be declared to accept a
-variable number of arguments much as a function can. The syntax for
-defining the macro is similar to that of a function. Here is an
-example:
-
- #define debug(format, ...) fprintf (stderr, format, __VA_ARGS__)
-
- Here `...' is a "variable argument". In the invocation of such a
-macro, it represents the zero or more tokens until the closing
-parenthesis that ends the invocation, including any commas. This set of
-tokens replaces the identifier `__VA_ARGS__' in the macro body wherever
-it appears. See the CPP manual for more information.
-
- GCC has long supported variadic macros, and used a different syntax
-that allowed you to give a name to the variable arguments just like any
-other argument. Here is an example:
-
- #define debug(format, args...) fprintf (stderr, format, args)
-
- This is in all ways equivalent to the ISO C example above, but arguably
-more readable and descriptive.
-
- GNU CPP has two further variadic macro extensions, and permits them to
-be used with either of the above forms of macro definition.
-
- In standard C, you are not allowed to leave the variable argument out
-entirely; but you are allowed to pass an empty argument. For example,
-this invocation is invalid in ISO C, because there is no comma after
-the string:
-
- debug ("A message")
-
- GNU CPP permits you to completely omit the variable arguments in this
-way. In the above examples, the compiler would complain, though since
-the expansion of the macro still has the extra comma after the format
-string.
-
- To help solve this problem, CPP behaves specially for variable
-arguments used with the token paste operator, `##'. If instead you
-write
-
- #define debug(format, ...) fprintf (stderr, format, ## __VA_ARGS__)
-
- and if the variable arguments are omitted or empty, the `##' operator
-causes the preprocessor to remove the comma before it. If you do
-provide some variable arguments in your macro invocation, GNU CPP does
-not complain about the paste operation and instead places the variable
-arguments after the comma. Just like any other pasted macro argument,
-these arguments are not macro expanded.
-
-
-File: gcc.info, Node: Escaped Newlines, Next: Subscripting, Prev: Variadic Macros, Up: C Extensions
-
-6.21 Slightly Looser Rules for Escaped Newlines
-===============================================
-
-Recently, the preprocessor has relaxed its treatment of escaped
-newlines. Previously, the newline had to immediately follow a
-backslash. The current implementation allows whitespace in the form of
-spaces, horizontal and vertical tabs, and form feeds between the
-backslash and the subsequent newline. The preprocessor issues a
-warning, but treats it as a valid escaped newline and combines the two
-lines to form a single logical line. This works within comments and
-tokens, as well as between tokens. Comments are _not_ treated as
-whitespace for the purposes of this relaxation, since they have not yet
-been replaced with spaces.
-
-
-File: gcc.info, Node: Subscripting, Next: Pointer Arith, Prev: Escaped Newlines, Up: C Extensions
-
-6.22 Non-Lvalue Arrays May Have Subscripts
-==========================================
-
-In ISO C99, arrays that are not lvalues still decay to pointers, and
-may be subscripted, although they may not be modified or used after the
-next sequence point and the unary `&' operator may not be applied to
-them. As an extension, GCC allows such arrays to be subscripted in C90
-mode, though otherwise they do not decay to pointers outside C99 mode.
-For example, this is valid in GNU C though not valid in C90:
-
- struct foo {int a[4];};
-
- struct foo f();
-
- bar (int index)
- {
- return f().a[index];
- }
-
-
-File: gcc.info, Node: Pointer Arith, Next: Initializers, Prev: Subscripting, Up: C Extensions
-
-6.23 Arithmetic on `void'- and Function-Pointers
-================================================
-
-In GNU C, addition and subtraction operations are supported on pointers
-to `void' and on pointers to functions. This is done by treating the
-size of a `void' or of a function as 1.
-
- A consequence of this is that `sizeof' is also allowed on `void' and
-on function types, and returns 1.
-
- The option `-Wpointer-arith' requests a warning if these extensions
-are used.
-
-
-File: gcc.info, Node: Initializers, Next: Compound Literals, Prev: Pointer Arith, Up: C Extensions
-
-6.24 Non-Constant Initializers
-==============================
-
-As in standard C++ and ISO C99, the elements of an aggregate
-initializer for an automatic variable are not required to be constant
-expressions in GNU C. Here is an example of an initializer with
-run-time varying elements:
-
- foo (float f, float g)
- {
- float beat_freqs[2] = { f-g, f+g };
- /* ... */
- }
-
-
-File: gcc.info, Node: Compound Literals, Next: Designated Inits, Prev: Initializers, Up: C Extensions
-
-6.25 Compound Literals
-======================
-
-ISO C99 supports compound literals. A compound literal looks like a
-cast containing an initializer. Its value is an object of the type
-specified in the cast, containing the elements specified in the
-initializer; it is an lvalue. As an extension, GCC supports compound
-literals in C90 mode and in C++.
-
- Usually, the specified type is a structure. Assume that `struct foo'
-and `structure' are declared as shown:
-
- struct foo {int a; char b[2];} structure;
-
-Here is an example of constructing a `struct foo' with a compound
-literal:
-
- structure = ((struct foo) {x + y, 'a', 0});
-
-This is equivalent to writing the following:
-
- {
- struct foo temp = {x + y, 'a', 0};
- structure = temp;
- }
-
- You can also construct an array. If all the elements of the compound
-literal are (made up of) simple constant expressions, suitable for use
-in initializers of objects of static storage duration, then the compound
-literal can be coerced to a pointer to its first element and used in
-such an initializer, as shown here:
-
- char **foo = (char *[]) { "x", "y", "z" };
-
- Compound literals for scalar types and union types are is also
-allowed, but then the compound literal is equivalent to a cast.
-
- As a GNU extension, GCC allows initialization of objects with static
-storage duration by compound literals (which is not possible in ISO
-C99, because the initializer is not a constant). It is handled as if
-the object was initialized only with the bracket enclosed list if the
-types of the compound literal and the object match. The initializer
-list of the compound literal must be constant. If the object being
-initialized has array type of unknown size, the size is determined by
-compound literal size.
-
- static struct foo x = (struct foo) {1, 'a', 'b'};
- static int y[] = (int []) {1, 2, 3};
- static int z[] = (int [3]) {1};
-
-The above lines are equivalent to the following:
- static struct foo x = {1, 'a', 'b'};
- static int y[] = {1, 2, 3};
- static int z[] = {1, 0, 0};
-
-
-File: gcc.info, Node: Designated Inits, Next: Cast to Union, Prev: Compound Literals, Up: C Extensions
-
-6.26 Designated Initializers
-============================
-
-Standard C90 requires the elements of an initializer to appear in a
-fixed order, the same as the order of the elements in the array or
-structure being initialized.
-
- In ISO C99 you can give the elements in any order, specifying the array
-indices or structure field names they apply to, and GNU C allows this as
-an extension in C90 mode as well. This extension is not implemented in
-GNU C++.
-
- To specify an array index, write `[INDEX] =' before the element value.
-For example,
-
- int a[6] = { [4] = 29, [2] = 15 };
-
-is equivalent to
-
- int a[6] = { 0, 0, 15, 0, 29, 0 };
-
-The index values must be constant expressions, even if the array being
-initialized is automatic.
-
- An alternative syntax for this which has been obsolete since GCC 2.5
-but GCC still accepts is to write `[INDEX]' before the element value,
-with no `='.
-
- To initialize a range of elements to the same value, write `[FIRST ...
-LAST] = VALUE'. This is a GNU extension. For example,
-
- int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
-
-If the value in it has side-effects, the side-effects will happen only
-once, not for each initialized field by the range initializer.
-
-Note that the length of the array is the highest value specified plus
-one.
-
- In a structure initializer, specify the name of a field to initialize
-with `.FIELDNAME =' before the element value. For example, given the
-following structure,
-
- struct point { int x, y; };
-
-the following initialization
-
- struct point p = { .y = yvalue, .x = xvalue };
-
-is equivalent to
-
- struct point p = { xvalue, yvalue };
-
- Another syntax which has the same meaning, obsolete since GCC 2.5, is
-`FIELDNAME:', as shown here:
-
- struct point p = { y: yvalue, x: xvalue };
-
- The `[INDEX]' or `.FIELDNAME' is known as a "designator". You can
-also use a designator (or the obsolete colon syntax) when initializing
-a union, to specify which element of the union should be used. For
-example,
-
- union foo { int i; double d; };
-
- union foo f = { .d = 4 };
-
-will convert 4 to a `double' to store it in the union using the second
-element. By contrast, casting 4 to type `union foo' would store it
-into the union as the integer `i', since it is an integer. (*Note Cast
-to Union::.)
-
- You can combine this technique of naming elements with ordinary C
-initialization of successive elements. Each initializer element that
-does not have a designator applies to the next consecutive element of
-the array or structure. For example,
-
- int a[6] = { [1] = v1, v2, [4] = v4 };
-
-is equivalent to
-
- int a[6] = { 0, v1, v2, 0, v4, 0 };
-
- Labeling the elements of an array initializer is especially useful
-when the indices are characters or belong to an `enum' type. For
-example:
-
- int whitespace[256]
- = { [' '] = 1, ['\t'] = 1, ['\h'] = 1,
- ['\f'] = 1, ['\n'] = 1, ['\r'] = 1 };
-
- You can also write a series of `.FIELDNAME' and `[INDEX]' designators
-before an `=' to specify a nested subobject to initialize; the list is
-taken relative to the subobject corresponding to the closest
-surrounding brace pair. For example, with the `struct point'
-declaration above:
-
- struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
-
-If the same field is initialized multiple times, it will have value from
-the last initialization. If any such overridden initialization has
-side-effect, it is unspecified whether the side-effect happens or not.
-Currently, GCC will discard them and issue a warning.
-
-
-File: gcc.info, Node: Case Ranges, Next: Mixed Declarations, Prev: Cast to Union, Up: C Extensions
-
-6.27 Case Ranges
-================
-
-You can specify a range of consecutive values in a single `case' label,
-like this:
-
- case LOW ... HIGH:
-
-This has the same effect as the proper number of individual `case'
-labels, one for each integer value from LOW to HIGH, inclusive.
-
- This feature is especially useful for ranges of ASCII character codes:
-
- case 'A' ... 'Z':
-
- *Be careful:* Write spaces around the `...', for otherwise it may be
-parsed wrong when you use it with integer values. For example, write
-this:
-
- case 1 ... 5:
-
-rather than this:
-
- case 1...5:
-
-
-File: gcc.info, Node: Cast to Union, Next: Case Ranges, Prev: Designated Inits, Up: C Extensions
-
-6.28 Cast to a Union Type
-=========================
-
-A cast to union type is similar to other casts, except that the type
-specified is a union type. You can specify the type either with `union
-TAG' or with a typedef name. A cast to union is actually a constructor
-though, not a cast, and hence does not yield an lvalue like normal
-casts. (*Note Compound Literals::.)
-
- The types that may be cast to the union type are those of the members
-of the union. Thus, given the following union and variables:
-
- union foo { int i; double d; };
- int x;
- double y;
-
-both `x' and `y' can be cast to type `union foo'.
-
- Using the cast as the right-hand side of an assignment to a variable of
-union type is equivalent to storing in a member of the union:
-
- union foo u;
- /* ... */
- u = (union foo) x == u.i = x
- u = (union foo) y == u.d = y
-
- You can also use the union cast as a function argument:
-
- void hack (union foo);
- /* ... */
- hack ((union foo) x);
-
-
-File: gcc.info, Node: Mixed Declarations, Next: Function Attributes, Prev: Case Ranges, Up: C Extensions
-
-6.29 Mixed Declarations and Code
-================================
-
-ISO C99 and ISO C++ allow declarations and code to be freely mixed
-within compound statements. As an extension, GCC also allows this in
-C90 mode. For example, you could do:
-
- int i;
- /* ... */
- i++;
- int j = i + 2;
-
- Each identifier is visible from where it is declared until the end of
-the enclosing block.
-
-
-File: gcc.info, Node: Function Attributes, Next: Attribute Syntax, Prev: Mixed Declarations, Up: C Extensions
-
-6.30 Declaring Attributes of Functions
-======================================
-
-In GNU C, you declare certain things about functions called in your
-program which help the compiler optimize function calls and check your
-code more carefully.
-
- The keyword `__attribute__' allows you to specify special attributes
-when making a declaration. This keyword is followed by an attribute
-specification inside double parentheses. The following attributes are
-currently defined for functions on all targets: `aligned',
-`alloc_size', `noreturn', `returns_twice', `noinline', `noclone',
-`always_inline', `flatten', `pure', `const', `nothrow', `sentinel',
-`format', `format_arg', `no_instrument_function', `no_split_stack',
-`section', `constructor', `destructor', `used', `unused', `deprecated',
-`weak', `malloc', `alias', `ifunc', `warn_unused_result', `nonnull',
-`gnu_inline', `externally_visible', `hot', `cold', `artificial',
-`error' and `warning'. Several other attributes are defined for
-functions on particular target systems. Other attributes, including
-`section' are supported for variables declarations (*note Variable
-Attributes::) and for types (*note Type Attributes::).
-
- GCC plugins may provide their own attributes.
-
- You may also specify attributes with `__' preceding and following each
-keyword. This allows you to use them in header files without being
-concerned about a possible macro of the same name. For example, you
-may use `__noreturn__' instead of `noreturn'.
-
- *Note Attribute Syntax::, for details of the exact syntax for using
-attributes.
-
-`alias ("TARGET")'
- The `alias' attribute causes the declaration to be emitted as an
- alias for another symbol, which must be specified. For instance,
-
- void __f () { /* Do something. */; }
- void f () __attribute__ ((weak, alias ("__f")));
-
- defines `f' to be a weak alias for `__f'. In C++, the mangled
- name for the target must be used. It is an error if `__f' is not
- defined in the same translation unit.
-
- Not all target machines support this attribute.
-
-`aligned (ALIGNMENT)'
- This attribute specifies a minimum alignment for the function,
- measured in bytes.
-
- You cannot use this attribute to decrease the alignment of a
- function, only to increase it. However, when you explicitly
- specify a function alignment this will override the effect of the
- `-falign-functions' (*note Optimize Options::) option for this
- function.
-
- Note that the effectiveness of `aligned' attributes may be limited
- by inherent limitations in your linker. On many systems, the
- linker is only able to arrange for functions to be aligned up to a
- certain maximum alignment. (For some linkers, the maximum
- supported alignment may be very very small.) See your linker
- documentation for further information.
-
- The `aligned' attribute can also be used for variables and fields
- (*note Variable Attributes::.)
-
-`alloc_size'
- The `alloc_size' attribute is used to tell the compiler that the
- function return value points to memory, where the size is given by
- one or two of the functions parameters. GCC uses this information
- to improve the correctness of `__builtin_object_size'.
-
- The function parameter(s) denoting the allocated size are
- specified by one or two integer arguments supplied to the
- attribute. The allocated size is either the value of the single
- function argument specified or the product of the two function
- arguments specified. Argument numbering starts at one.
-
- For instance,
-
- void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2)))
- void my_realloc(void*, size_t) __attribute__((alloc_size(2)))
-
- declares that my_calloc will return memory of the size given by
- the product of parameter 1 and 2 and that my_realloc will return
- memory of the size given by parameter 2.
-
-`always_inline'
- Generally, functions are not inlined unless optimization is
- specified. For functions declared inline, this attribute inlines
- the function even if no optimization level was specified.
-
-`gnu_inline'
- This attribute should be used with a function which is also
- declared with the `inline' keyword. It directs GCC to treat the
- function as if it were defined in gnu90 mode even when compiling
- in C99 or gnu99 mode.
-
- If the function is declared `extern', then this definition of the
- function is used only for inlining. In no case is the function
- compiled as a standalone function, not even if you take its address
- explicitly. Such an address becomes an external reference, as if
- you had only declared the function, and had not defined it. This
- has almost the effect of a macro. The way to use this is to put a
- function definition in a header file with this attribute, and put
- another copy of the function, without `extern', in a library file.
- The definition in the header file will cause most calls to the
- function to be inlined. If any uses of the function remain, they
- will refer to the single copy in the library. Note that the two
- definitions of the functions need not be precisely the same,
- although if they do not have the same effect your program may
- behave oddly.
-
- In C, if the function is neither `extern' nor `static', then the
- function is compiled as a standalone function, as well as being
- inlined where possible.
-
- This is how GCC traditionally handled functions declared `inline'.
- Since ISO C99 specifies a different semantics for `inline', this
- function attribute is provided as a transition measure and as a
- useful feature in its own right. This attribute is available in
- GCC 4.1.3 and later. It is available if either of the
- preprocessor macros `__GNUC_GNU_INLINE__' or
- `__GNUC_STDC_INLINE__' are defined. *Note An Inline Function is
- As Fast As a Macro: Inline.
-
- In C++, this attribute does not depend on `extern' in any way, but
- it still requires the `inline' keyword to enable its special
- behavior.
-
-`artificial'
- This attribute is useful for small inline wrappers which if
- possible should appear during debugging as a unit, depending on
- the debug info format it will either mean marking the function as
- artificial or using the caller location for all instructions
- within the inlined body.
-
-`bank_switch'
- When added to an interrupt handler with the M32C port, causes the
- prologue and epilogue to use bank switching to preserve the
- registers rather than saving them on the stack.
-
-`flatten'
- Generally, inlining into a function is limited. For a function
- marked with this attribute, every call inside this function will
- be inlined, if possible. Whether the function itself is
- considered for inlining depends on its size and the current
- inlining parameters.
-
-`error ("MESSAGE")'
- If this attribute is used on a function declaration and a call to
- such a function is not eliminated through dead code elimination or
- other optimizations, an error which will include MESSAGE will be
- diagnosed. This is useful for compile time checking, especially
- together with `__builtin_constant_p' and inline functions where
- checking the inline function arguments is not possible through
- `extern char [(condition) ? 1 : -1];' tricks. While it is
- possible to leave the function undefined and thus invoke a link
- failure, when using this attribute the problem will be diagnosed
- earlier and with exact location of the call even in presence of
- inline functions or when not emitting debugging information.
-
-`warning ("MESSAGE")'
- If this attribute is used on a function declaration and a call to
- such a function is not eliminated through dead code elimination or
- other optimizations, a warning which will include MESSAGE will be
- diagnosed. This is useful for compile time checking, especially
- together with `__builtin_constant_p' and inline functions. While
- it is possible to define the function with a message in
- `.gnu.warning*' section, when using this attribute the problem
- will be diagnosed earlier and with exact location of the call even
- in presence of inline functions or when not emitting debugging
- information.
-
-`cdecl'
- On the Intel 386, the `cdecl' attribute causes the compiler to
- assume that the calling function will pop off the stack space used
- to pass arguments. This is useful to override the effects of the
- `-mrtd' switch.
-
-`const'
- Many functions do not examine any values except their arguments,
- and have no effects except the return value. Basically this is
- just slightly more strict class than the `pure' attribute below,
- since function is not allowed to read global memory.
-
- Note that a function that has pointer arguments and examines the
- data pointed to must _not_ be declared `const'. Likewise, a
- function that calls a non-`const' function usually must not be
- `const'. It does not make sense for a `const' function to return
- `void'.
-
- The attribute `const' is not implemented in GCC versions earlier
- than 2.5. An alternative way to declare that a function has no
- side effects, which works in the current version and in some older
- versions, is as follows:
-
- typedef int intfn ();
-
- extern const intfn square;
-
- This approach does not work in GNU C++ from 2.6.0 on, since the
- language specifies that the `const' must be attached to the return
- value.
-
-`constructor'
-`destructor'
-`constructor (PRIORITY)'
-`destructor (PRIORITY)'
- The `constructor' attribute causes the function to be called
- automatically before execution enters `main ()'. Similarly, the
- `destructor' attribute causes the function to be called
- automatically after `main ()' has completed or `exit ()' has been
- called. Functions with these attributes are useful for
- initializing data that will be used implicitly during the
- execution of the program.
-
- You may provide an optional integer priority to control the order
- in which constructor and destructor functions are run. A
- constructor with a smaller priority number runs before a
- constructor with a larger priority number; the opposite
- relationship holds for destructors. So, if you have a constructor
- that allocates a resource and a destructor that deallocates the
- same resource, both functions typically have the same priority.
- The priorities for constructor and destructor functions are the
- same as those specified for namespace-scope C++ objects (*note C++
- Attributes::).
-
- These attributes are not currently implemented for Objective-C.
-
-`deprecated'
-`deprecated (MSG)'
- The `deprecated' attribute results in a warning if the function is
- used anywhere in the source file. This is useful when identifying
- functions that are expected to be removed in a future version of a
- program. The warning also includes the location of the declaration
- of the deprecated function, to enable users to easily find further
- information about why the function is deprecated, or what they
- should do instead. Note that the warnings only occurs for uses:
-
- int old_fn () __attribute__ ((deprecated));
- int old_fn ();
- int (*fn_ptr)() = old_fn;
-
- results in a warning on line 3 but not line 2. The optional msg
- argument, which must be a string, will be printed in the warning if
- present.
-
- The `deprecated' attribute can also be used for variables and
- types (*note Variable Attributes::, *note Type Attributes::.)
-
-`disinterrupt'
- On MeP targets, this attribute causes the compiler to emit
- instructions to disable interrupts for the duration of the given
- function.
-
-`dllexport'
- On Microsoft Windows targets and Symbian OS targets the
- `dllexport' attribute causes the compiler to provide a global
- pointer to a pointer in a DLL, so that it can be referenced with
- the `dllimport' attribute. On Microsoft Windows targets, the
- pointer name is formed by combining `_imp__' and the function or
- variable name.
-
- You can use `__declspec(dllexport)' as a synonym for
- `__attribute__ ((dllexport))' for compatibility with other
- compilers.
-
- On systems that support the `visibility' attribute, this attribute
- also implies "default" visibility. It is an error to explicitly
- specify any other visibility.
-
- In previous versions of GCC, the `dllexport' attribute was ignored
- for inlined functions, unless the `-fkeep-inline-functions' flag
- had been used. The default behaviour now is to emit all
- dllexported inline functions; however, this can cause object
- file-size bloat, in which case the old behaviour can be restored
- by using `-fno-keep-inline-dllexport'.
-
- The attribute is also ignored for undefined symbols.
-
- When applied to C++ classes, the attribute marks defined
- non-inlined member functions and static data members as exports.
- Static consts initialized in-class are not marked unless they are
- also defined out-of-class.
-
- For Microsoft Windows targets there are alternative methods for
- including the symbol in the DLL's export table such as using a
- `.def' file with an `EXPORTS' section or, with GNU ld, using the
- `--export-all' linker flag.
-
-`dllimport'
- On Microsoft Windows and Symbian OS targets, the `dllimport'
- attribute causes the compiler to reference a function or variable
- via a global pointer to a pointer that is set up by the DLL
- exporting the symbol. The attribute implies `extern'. On
- Microsoft Windows targets, the pointer name is formed by combining
- `_imp__' and the function or variable name.
-
- You can use `__declspec(dllimport)' as a synonym for
- `__attribute__ ((dllimport))' for compatibility with other
- compilers.
-
- On systems that support the `visibility' attribute, this attribute
- also implies "default" visibility. It is an error to explicitly
- specify any other visibility.
-
- Currently, the attribute is ignored for inlined functions. If the
- attribute is applied to a symbol _definition_, an error is
- reported. If a symbol previously declared `dllimport' is later
- defined, the attribute is ignored in subsequent references, and a
- warning is emitted. The attribute is also overridden by a
- subsequent declaration as `dllexport'.
-
- When applied to C++ classes, the attribute marks non-inlined
- member functions and static data members as imports. However, the
- attribute is ignored for virtual methods to allow creation of
- vtables using thunks.
-
- On the SH Symbian OS target the `dllimport' attribute also has
- another affect--it can cause the vtable and run-time type
- information for a class to be exported. This happens when the
- class has a dllimport'ed constructor or a non-inline, non-pure
- virtual function and, for either of those two conditions, the
- class also has an inline constructor or destructor and has a key
- function that is defined in the current translation unit.
-
- For Microsoft Windows based targets the use of the `dllimport'
- attribute on functions is not necessary, but provides a small
- performance benefit by eliminating a thunk in the DLL. The use of
- the `dllimport' attribute on imported variables was required on
- older versions of the GNU linker, but can now be avoided by
- passing the `--enable-auto-import' switch to the GNU linker. As
- with functions, using the attribute for a variable eliminates a
- thunk in the DLL.
-
- One drawback to using this attribute is that a pointer to a
- _variable_ marked as `dllimport' cannot be used as a constant
- address. However, a pointer to a _function_ with the `dllimport'
- attribute can be used as a constant initializer; in this case, the
- address of a stub function in the import lib is referenced. On
- Microsoft Windows targets, the attribute can be disabled for
- functions by setting the `-mnop-fun-dllimport' flag.
-
-`eightbit_data'
- Use this attribute on the H8/300, H8/300H, and H8S to indicate
- that the specified variable should be placed into the eight bit
- data section. The compiler will generate more efficient code for
- certain operations on data in the eight bit data area. Note the
- eight bit data area is limited to 256 bytes of data.
-
- You must use GAS and GLD from GNU binutils version 2.7 or later for
- this attribute to work correctly.
-
-`exception_handler'
- Use this attribute on the Blackfin to indicate that the specified
- function is an exception handler. The compiler will generate
- function entry and exit sequences suitable for use in an exception
- handler when this attribute is present.
-
-`externally_visible'
- This attribute, attached to a global variable or function,
- nullifies the effect of the `-fwhole-program' command-line option,
- so the object remains visible outside the current compilation
- unit. If `-fwhole-program' is used together with `-flto' and
- `gold' is used as the linker plugin, `externally_visible'
- attributes are automatically added to functions (not variable yet
- due to a current `gold' issue) that are accessed outside of LTO
- objects according to resolution file produced by `gold'. For
- other linkers that cannot generate resolution file, explicit
- `externally_visible' attributes are still necessary.
-
-`far'
- On 68HC11 and 68HC12 the `far' attribute causes the compiler to
- use a calling convention that takes care of switching memory banks
- when entering and leaving a function. This calling convention is
- also the default when using the `-mlong-calls' option.
-
- On 68HC12 the compiler will use the `call' and `rtc' instructions
- to call and return from a function.
-
- On 68HC11 the compiler will generate a sequence of instructions to
- invoke a board-specific routine to switch the memory bank and call
- the real function. The board-specific routine simulates a `call'.
- At the end of a function, it will jump to a board-specific routine
- instead of using `rts'. The board-specific return routine
- simulates the `rtc'.
-
- On MeP targets this causes the compiler to use a calling convention
- which assumes the called function is too far away for the built-in
- addressing modes.
-
-`fast_interrupt'
- Use this attribute on the M32C and RX ports to indicate that the
- specified function is a fast interrupt handler. This is just like
- the `interrupt' attribute, except that `freit' is used to return
- instead of `reit'.
-
-`fastcall'
- On the Intel 386, the `fastcall' attribute causes the compiler to
- pass the first argument (if of integral type) in the register ECX
- and the second argument (if of integral type) in the register EDX.
- Subsequent and other typed arguments are passed on the stack. The
- called function will pop the arguments off the stack. If the
- number of arguments is variable all arguments are pushed on the
- stack.
-
-`thiscall'
- On the Intel 386, the `thiscall' attribute causes the compiler to
- pass the first argument (if of integral type) in the register ECX.
- Subsequent and other typed arguments are passed on the stack. The
- called function will pop the arguments off the stack. If the
- number of arguments is variable all arguments are pushed on the
- stack. The `thiscall' attribute is intended for C++ non-static
- member functions. As gcc extension this calling convention can be
- used for C-functions and for static member methods.
-
-`format (ARCHETYPE, STRING-INDEX, FIRST-TO-CHECK)'
- The `format' attribute specifies that a function takes `printf',
- `scanf', `strftime' or `strfmon' style arguments which should be
- type-checked against a format string. For example, the
- declaration:
-
- extern int
- my_printf (void *my_object, const char *my_format, ...)
- __attribute__ ((format (printf, 2, 3)));
-
- causes the compiler to check the arguments in calls to `my_printf'
- for consistency with the `printf' style format string argument
- `my_format'.
-
- The parameter ARCHETYPE determines how the format string is
- interpreted, and should be `printf', `scanf', `strftime',
- `gnu_printf', `gnu_scanf', `gnu_strftime' or `strfmon'. (You can
- also use `__printf__', `__scanf__', `__strftime__' or
- `__strfmon__'.) On MinGW targets, `ms_printf', `ms_scanf', and
- `ms_strftime' are also present. ARCHTYPE values such as `printf'
- refer to the formats accepted by the system's C run-time library,
- while `gnu_' values always refer to the formats accepted by the
- GNU C Library. On Microsoft Windows targets, `ms_' values refer
- to the formats accepted by the `msvcrt.dll' library. The
- parameter STRING-INDEX specifies which argument is the format
- string argument (starting from 1), while FIRST-TO-CHECK is the
- number of the first argument to check against the format string.
- For functions where the arguments are not available to be checked
- (such as `vprintf'), specify the third parameter as zero. In this
- case the compiler only checks the format string for consistency.
- For `strftime' formats, the third parameter is required to be zero.
- Since non-static C++ methods have an implicit `this' argument, the
- arguments of such methods should be counted from two, not one, when
- giving values for STRING-INDEX and FIRST-TO-CHECK.
-
- In the example above, the format string (`my_format') is the second
- argument of the function `my_print', and the arguments to check
- start with the third argument, so the correct parameters for the
- format attribute are 2 and 3.
-
- The `format' attribute allows you to identify your own functions
- which take format strings as arguments, so that GCC can check the
- calls to these functions for errors. The compiler always (unless
- `-ffreestanding' or `-fno-builtin' is used) checks formats for the
- standard library functions `printf', `fprintf', `sprintf',
- `scanf', `fscanf', `sscanf', `strftime', `vprintf', `vfprintf' and
- `vsprintf' whenever such warnings are requested (using
- `-Wformat'), so there is no need to modify the header file
- `stdio.h'. In C99 mode, the functions `snprintf', `vsnprintf',
- `vscanf', `vfscanf' and `vsscanf' are also checked. Except in
- strictly conforming C standard modes, the X/Open function
- `strfmon' is also checked as are `printf_unlocked' and
- `fprintf_unlocked'. *Note Options Controlling C Dialect: C
- Dialect Options.
-
- For Objective-C dialects, `NSString' (or `__NSString__') is
- recognized in the same context. Declarations including these
- format attributes will be parsed for correct syntax, however the
- result of checking of such format strings is not yet defined, and
- will not be carried out by this version of the compiler.
-
- The target may also provide additional types of format checks.
- *Note Format Checks Specific to Particular Target Machines: Target
- Format Checks.
-
-`format_arg (STRING-INDEX)'
- The `format_arg' attribute specifies that a function takes a format
- string for a `printf', `scanf', `strftime' or `strfmon' style
- function and modifies it (for example, to translate it into
- another language), so the result can be passed to a `printf',
- `scanf', `strftime' or `strfmon' style function (with the
- remaining arguments to the format function the same as they would
- have been for the unmodified string). For example, the
- declaration:
-
- extern char *
- my_dgettext (char *my_domain, const char *my_format)
- __attribute__ ((format_arg (2)));
-
- causes the compiler to check the arguments in calls to a `printf',
- `scanf', `strftime' or `strfmon' type function, whose format
- string argument is a call to the `my_dgettext' function, for
- consistency with the format string argument `my_format'. If the
- `format_arg' attribute had not been specified, all the compiler
- could tell in such calls to format functions would be that the
- format string argument is not constant; this would generate a
- warning when `-Wformat-nonliteral' is used, but the calls could
- not be checked without the attribute.
-
- The parameter STRING-INDEX specifies which argument is the format
- string argument (starting from one). Since non-static C++ methods
- have an implicit `this' argument, the arguments of such methods
- should be counted from two.
-
- The `format-arg' attribute allows you to identify your own
- functions which modify format strings, so that GCC can check the
- calls to `printf', `scanf', `strftime' or `strfmon' type function
- whose operands are a call to one of your own function. The
- compiler always treats `gettext', `dgettext', and `dcgettext' in
- this manner except when strict ISO C support is requested by
- `-ansi' or an appropriate `-std' option, or `-ffreestanding' or
- `-fno-builtin' is used. *Note Options Controlling C Dialect: C
- Dialect Options.
-
- For Objective-C dialects, the `format-arg' attribute may refer to
- an `NSString' reference for compatibility with the `format'
- attribute above.
-
- The target may also allow additional types in `format-arg'
- attributes. *Note Format Checks Specific to Particular Target
- Machines: Target Format Checks.
-
-`function_vector'
- Use this attribute on the H8/300, H8/300H, and H8S to indicate
- that the specified function should be called through the function
- vector. Calling a function through the function vector will
- reduce code size, however; the function vector has a limited size
- (maximum 128 entries on the H8/300 and 64 entries on the H8/300H
- and H8S) and shares space with the interrupt vector.
-
- In SH2A target, this attribute declares a function to be called
- using the TBR relative addressing mode. The argument to this
- attribute is the entry number of the same function in a vector
- table containing all the TBR relative addressable functions. For
- the successful jump, register TBR should contain the start address
- of this TBR relative vector table. In the startup routine of the
- user application, user needs to care of this TBR register
- initialization. The TBR relative vector table can have at max 256
- function entries. The jumps to these functions will be generated
- using a SH2A specific, non delayed branch instruction JSR/N
- @(disp8,TBR). You must use GAS and GLD from GNU binutils version
- 2.7 or later for this attribute to work correctly.
-
- Please refer the example of M16C target, to see the use of this
- attribute while declaring a function,
-
- In an application, for a function being called once, this
- attribute will save at least 8 bytes of code; and if other
- successive calls are being made to the same function, it will save
- 2 bytes of code per each of these calls.
-
- On M16C/M32C targets, the `function_vector' attribute declares a
- special page subroutine call function. Use of this attribute
- reduces the code size by 2 bytes for each call generated to the
- subroutine. The argument to the attribute is the vector number
- entry from the special page vector table which contains the 16
- low-order bits of the subroutine's entry address. Each vector
- table has special page number (18 to 255) which are used in `jsrs'
- instruction. Jump addresses of the routines are generated by
- adding 0x0F0000 (in case of M16C targets) or 0xFF0000 (in case of
- M32C targets), to the 2 byte addresses set in the vector table.
- Therefore you need to ensure that all the special page vector
- routines should get mapped within the address range 0x0F0000 to
- 0x0FFFFF (for M16C) and 0xFF0000 to 0xFFFFFF (for M32C).
-
- In the following example 2 bytes will be saved for each call to
- function `foo'.
-
- void foo (void) __attribute__((function_vector(0x18)));
- void foo (void)
- {
- }
-
- void bar (void)
- {
- foo();
- }
-
- If functions are defined in one file and are called in another
- file, then be sure to write this declaration in both files.
-
- This attribute is ignored for R8C target.
-
-`interrupt'
- Use this attribute on the ARM, AVR, CRX, M32C, M32R/D, m68k, MeP,
- MIPS, RX and Xstormy16 ports to indicate that the specified
- function is an interrupt handler. The compiler will generate
- function entry and exit sequences suitable for use in an interrupt
- handler when this attribute is present.
-
- Note, interrupt handlers for the Blackfin, H8/300, H8/300H, H8S,
- MicroBlaze, and SH processors can be specified via the
- `interrupt_handler' attribute.
-
- Note, on the AVR, interrupts will be enabled inside the function.
-
- Note, for the ARM, you can specify the kind of interrupt to be
- handled by adding an optional parameter to the interrupt attribute
- like this:
-
- void f () __attribute__ ((interrupt ("IRQ")));
-
- Permissible values for this parameter are: IRQ, FIQ, SWI, ABORT
- and UNDEF.
-
- On ARMv7-M the interrupt type is ignored, and the attribute means
- the function may be called with a word aligned stack pointer.
-
- On MIPS targets, you can use the following attributes to modify
- the behavior of an interrupt handler:
- `use_shadow_register_set'
- Assume that the handler uses a shadow register set, instead of
- the main general-purpose registers.
-
- `keep_interrupts_masked'
- Keep interrupts masked for the whole function. Without this
- attribute, GCC tries to reenable interrupts for as much of
- the function as it can.
-
- `use_debug_exception_return'
- Return using the `deret' instruction. Interrupt handlers
- that don't have this attribute return using `eret' instead.
-
- You can use any combination of these attributes, as shown below:
- void __attribute__ ((interrupt)) v0 ();
- void __attribute__ ((interrupt, use_shadow_register_set)) v1 ();
- void __attribute__ ((interrupt, keep_interrupts_masked)) v2 ();
- void __attribute__ ((interrupt, use_debug_exception_return)) v3 ();
- void __attribute__ ((interrupt, use_shadow_register_set,
- keep_interrupts_masked)) v4 ();
- void __attribute__ ((interrupt, use_shadow_register_set,
- use_debug_exception_return)) v5 ();
- void __attribute__ ((interrupt, keep_interrupts_masked,
- use_debug_exception_return)) v6 ();
- void __attribute__ ((interrupt, use_shadow_register_set,
- keep_interrupts_masked,
- use_debug_exception_return)) v7 ();
-
-`ifunc ("RESOLVER")'
- The `ifunc' attribute is used to mark a function as an indirect
- function using the STT_GNU_IFUNC symbol type extension to the ELF
- standard. This allows the resolution of the symbol value to be
- determined dynamically at load time, and an optimized version of
- the routine can be selected for the particular processor or other
- system characteristics determined then. To use this attribute,
- first define the implementation functions available, and a
- resolver function that returns a pointer to the selected
- implementation function. The implementation functions'
- declarations must match the API of the function being implemented,
- the resolver's declaration is be a function returning pointer to
- void function returning void:
-
- void *my_memcpy (void *dst, const void *src, size_t len)
- {
- ...
- }
-
- static void (*resolve_memcpy (void)) (void)
- {
- return my_memcpy; // we'll just always select this routine
- }
-
- The exported header file declaring the function the user calls
- would contain:
-
- extern void *memcpy (void *, const void *, size_t);
-
- allowing the user to call this as a regular function, unaware of
- the implementation. Finally, the indirect function needs to be
- defined in the same translation unit as the resolver function:
-
- void *memcpy (void *, const void *, size_t)
- __attribute__ ((ifunc ("resolve_memcpy")));
-
- Indirect functions cannot be weak, and require a recent binutils
- (at least version 2.20.1), and GNU C library (at least version
- 2.11.1).
-
-`interrupt_handler'
- Use this attribute on the Blackfin, m68k, H8/300, H8/300H, H8S,
- and SH to indicate that the specified function is an interrupt
- handler. The compiler will generate function entry and exit
- sequences suitable for use in an interrupt handler when this
- attribute is present.
-
-`interrupt_thread'
- Use this attribute on fido, a subarchitecture of the m68k, to
- indicate that the specified function is an interrupt handler that
- is designed to run as a thread. The compiler omits generate
- prologue/epilogue sequences and replaces the return instruction
- with a `sleep' instruction. This attribute is available only on
- fido.
-
-`isr'
- Use this attribute on ARM to write Interrupt Service Routines.
- This is an alias to the `interrupt' attribute above.
-
-`kspisusp'
- When used together with `interrupt_handler', `exception_handler'
- or `nmi_handler', code will be generated to load the stack pointer
- from the USP register in the function prologue.
-
-`l1_text'
- This attribute specifies a function to be placed into L1
- Instruction SRAM. The function will be put into a specific section
- named `.l1.text'. With `-mfdpic', function calls with a such
- function as the callee or caller will use inlined PLT.
-
-`l2'
- On the Blackfin, this attribute specifies a function to be placed
- into L2 SRAM. The function will be put into a specific section
- named `.l1.text'. With `-mfdpic', callers of such functions will
- use an inlined PLT.
-
-`leaf'
- Calls to external functions with this attribute must return to the
- current compilation unit only by return or by exception handling.
- In particular, leaf functions are not allowed to call callback
- function passed to it from the current compilation unit or
- directly call functions exported by the unit or longjmp into the
- unit. Leaf function might still call functions from other
- compilation units and thus they are not necessarily leaf in the
- sense that they contain no function calls at all.
-
- The attribute is intended for library functions to improve
- dataflow analysis. The compiler takes the hint that any data not
- escaping the current compilation unit can not be used or modified
- by the leaf function. For example, the `sin' function is a leaf
- function, but `qsort' is not.
-
- Note that leaf functions might invoke signals and signal handlers
- might be defined in the current compilation unit and use static
- variables. The only compliant way to write such a signal handler
- is to declare such variables `volatile'.
-
- The attribute has no effect on functions defined within the
- current compilation unit. This is to allow easy merging of
- multiple compilation units into one, for example, by using the
- link time optimization. For this reason the attribute is not
- allowed on types to annotate indirect calls.
-
-`long_call/short_call'
- This attribute specifies how a particular function is called on
- ARM. Both attributes override the `-mlong-calls' (*note ARM
- Options::) command-line switch and `#pragma long_calls' settings.
- The `long_call' attribute indicates that the function might be far
- away from the call site and require a different (more expensive)
- calling sequence. The `short_call' attribute always places the
- offset to the function from the call site into the `BL'
- instruction directly.
-
-`longcall/shortcall'
- On the Blackfin, RS/6000 and PowerPC, the `longcall' attribute
- indicates that the function might be far away from the call site
- and require a different (more expensive) calling sequence. The
- `shortcall' attribute indicates that the function is always close
- enough for the shorter calling sequence to be used. These
- attributes override both the `-mlongcall' switch and, on the
- RS/6000 and PowerPC, the `#pragma longcall' setting.
-
- *Note RS/6000 and PowerPC Options::, for more information on
- whether long calls are necessary.
-
-`long_call/near/far'
- These attributes specify how a particular function is called on
- MIPS. The attributes override the `-mlong-calls' (*note MIPS
- Options::) command-line switch. The `long_call' and `far'
- attributes are synonyms, and cause the compiler to always call the
- function by first loading its address into a register, and then
- using the contents of that register. The `near' attribute has the
- opposite effect; it specifies that non-PIC calls should be made
- using the more efficient `jal' instruction.
-
-`malloc'
- The `malloc' attribute is used to tell the compiler that a function
- may be treated as if any non-`NULL' pointer it returns cannot
- alias any other pointer valid when the function returns. This
- will often improve optimization. Standard functions with this
- property include `malloc' and `calloc'. `realloc'-like functions
- have this property as long as the old pointer is never referred to
- (including comparing it to the new pointer) after the function
- returns a non-`NULL' value.
-
-`mips16/nomips16'
- On MIPS targets, you can use the `mips16' and `nomips16' function
- attributes to locally select or turn off MIPS16 code generation.
- A function with the `mips16' attribute is emitted as MIPS16 code,
- while MIPS16 code generation is disabled for functions with the
- `nomips16' attribute. These attributes override the `-mips16' and
- `-mno-mips16' options on the command line (*note MIPS Options::).
-
- When compiling files containing mixed MIPS16 and non-MIPS16 code,
- the preprocessor symbol `__mips16' reflects the setting on the
- command line, not that within individual functions. Mixed MIPS16
- and non-MIPS16 code may interact badly with some GCC extensions
- such as `__builtin_apply' (*note Constructing Calls::).
-
-`model (MODEL-NAME)'
- On the M32R/D, use this attribute to set the addressability of an
- object, and of the code generated for a function. The identifier
- MODEL-NAME is one of `small', `medium', or `large', representing
- each of the code models.
-
- Small model objects live in the lower 16MB of memory (so that their
- addresses can be loaded with the `ld24' instruction), and are
- callable with the `bl' instruction.
-
- Medium model objects may live anywhere in the 32-bit address space
- (the compiler will generate `seth/add3' instructions to load their
- addresses), and are callable with the `bl' instruction.
-
- Large model objects may live anywhere in the 32-bit address space
- (the compiler will generate `seth/add3' instructions to load their
- addresses), and may not be reachable with the `bl' instruction
- (the compiler will generate the much slower `seth/add3/jl'
- instruction sequence).
-
- On IA-64, use this attribute to set the addressability of an
- object. At present, the only supported identifier for MODEL-NAME
- is `small', indicating addressability via "small" (22-bit)
- addresses (so that their addresses can be loaded with the `addl'
- instruction). Caveat: such addressing is by definition not
- position independent and hence this attribute must not be used for
- objects defined by shared libraries.
-
-`ms_abi/sysv_abi'
- On 64-bit x86_64-*-* targets, you can use an ABI attribute to
- indicate which calling convention should be used for a function.
- The `ms_abi' attribute tells the compiler to use the Microsoft
- ABI, while the `sysv_abi' attribute tells the compiler to use the
- ABI used on GNU/Linux and other systems. The default is to use
- the Microsoft ABI when targeting Windows. On all other systems,
- the default is the AMD ABI.
-
- Note, the `ms_abi' attribute for Windows targets currently requires
- the `-maccumulate-outgoing-args' option.
-
-`callee_pop_aggregate_return (NUMBER)'
- On 32-bit i?86-*-* targets, you can control by those attribute for
- aggregate return in memory, if the caller is responsible to pop
- the hidden pointer together with the rest of the arguments -
- NUMBER equal to zero -, or if the callee is responsible to pop
- hidden pointer - NUMBER equal to one.
-
- For i?86-netware, the caller pops the stack for the hidden
- arguments pointing to aggregate return value. This differs from
- the default i386 ABI which assumes that the callee pops the stack
- for hidden pointer.
-
-`ms_hook_prologue'
- On 32 bit i[34567]86-*-* targets and 64 bit x86_64-*-* targets,
- you can use this function attribute to make gcc generate the
- "hot-patching" function prologue used in Win32 API functions in
- Microsoft Windows XP Service Pack 2 and newer.
-
-`naked'
- Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to
- indicate that the specified function does not need
- prologue/epilogue sequences generated by the compiler. It is up
- to the programmer to provide these sequences. The only statements
- that can be safely included in naked functions are `asm'
- statements that do not have operands. All other statements,
- including declarations of local variables, `if' statements, and so
- forth, should be avoided. Naked functions should be used to
- implement the body of an assembly function, while allowing the
- compiler to construct the requisite function declaration for the
- assembler.
-
-`near'
- On 68HC11 and 68HC12 the `near' attribute causes the compiler to
- use the normal calling convention based on `jsr' and `rts'. This
- attribute can be used to cancel the effect of the `-mlong-calls'
- option.
-
- On MeP targets this attribute causes the compiler to assume the
- called function is close enough to use the normal calling
- convention, overriding the `-mtf' command line option.
-
-`nesting'
- Use this attribute together with `interrupt_handler',
- `exception_handler' or `nmi_handler' to indicate that the function
- entry code should enable nested interrupts or exceptions.
-
-`nmi_handler'
- Use this attribute on the Blackfin to indicate that the specified
- function is an NMI handler. The compiler will generate function
- entry and exit sequences suitable for use in an NMI handler when
- this attribute is present.
-
-`no_instrument_function'
- If `-finstrument-functions' is given, profiling function calls will
- be generated at entry and exit of most user-compiled functions.
- Functions with this attribute will not be so instrumented.
-
-`no_split_stack'
- If `-fsplit-stack' is given, functions will have a small prologue
- which decides whether to split the stack. Functions with the
- `no_split_stack' attribute will not have that prologue, and thus
- may run with only a small amount of stack space available.
-
-`noinline'
- This function attribute prevents a function from being considered
- for inlining. If the function does not have side-effects, there
- are optimizations other than inlining that causes function calls
- to be optimized away, although the function call is live. To keep
- such calls from being optimized away, put
- asm ("");
- (*note Extended Asm::) in the called function, to serve as a
- special side-effect.
-
-`noclone'
- This function attribute prevents a function from being considered
- for cloning - a mechanism which produces specialized copies of
- functions and which is (currently) performed by interprocedural
- constant propagation.
-
-`nonnull (ARG-INDEX, ...)'
- The `nonnull' attribute specifies that some function parameters
- should be non-null pointers. For instance, the declaration:
-
- extern void *
- my_memcpy (void *dest, const void *src, size_t len)
- __attribute__((nonnull (1, 2)));
-
- causes the compiler to check that, in calls to `my_memcpy',
- arguments DEST and SRC are non-null. If the compiler determines
- that a null pointer is passed in an argument slot marked as
- non-null, and the `-Wnonnull' option is enabled, a warning is
- issued. The compiler may also choose to make optimizations based
- on the knowledge that certain function arguments will not be null.
-
- Since non-static C++ methods have an implicit `this' argument, the
- arguments of such methods should be counted from two, not one, when
- giving values for ARG-INDEX.
-
- If no argument index list is given to the `nonnull' attribute, all
- pointer arguments are marked as non-null. To illustrate, the
- following declaration is equivalent to the previous example:
-
- extern void *
- my_memcpy (void *dest, const void *src, size_t len)
- __attribute__((nonnull));
-
-`noreturn'
- A few standard library functions, such as `abort' and `exit',
- cannot return. GCC knows this automatically. Some programs define
- their own functions that never return. You can declare them
- `noreturn' to tell the compiler this fact. For example,
-
- void fatal () __attribute__ ((noreturn));
-
- void
- fatal (/* ... */)
- {
- /* ... */ /* Print error message. */ /* ... */
- exit (1);
- }
-
- The `noreturn' keyword tells the compiler to assume that `fatal'
- cannot return. It can then optimize without regard to what would
- happen if `fatal' ever did return. This makes slightly better
- code. More importantly, it helps avoid spurious warnings of
- uninitialized variables.
-
- The `noreturn' keyword does not affect the exceptional path when
- that applies: a `noreturn'-marked function may still return to the
- caller by throwing an exception or calling `longjmp'.
-
- Do not assume that registers saved by the calling function are
- restored before calling the `noreturn' function.
-
- It does not make sense for a `noreturn' function to have a return
- type other than `void'.
-
- The attribute `noreturn' is not implemented in GCC versions
- earlier than 2.5. An alternative way to declare that a function
- does not return, which works in the current version and in some
- older versions, is as follows:
-
- typedef void voidfn ();
-
- volatile voidfn fatal;
-
- This approach does not work in GNU C++.
-
-`nothrow'
- The `nothrow' attribute is used to inform the compiler that a
- function cannot throw an exception. For example, most functions in
- the standard C library can be guaranteed not to throw an exception
- with the notable exceptions of `qsort' and `bsearch' that take
- function pointer arguments. The `nothrow' attribute is not
- implemented in GCC versions earlier than 3.3.
-
-`optimize'
- The `optimize' attribute is used to specify that a function is to
- be compiled with different optimization options than specified on
- the command line. Arguments can either be numbers or strings.
- Numbers are assumed to be an optimization level. Strings that
- begin with `O' are assumed to be an optimization option, while
- other options are assumed to be used with a `-f' prefix. You can
- also use the `#pragma GCC optimize' pragma to set the optimization
- options that affect more than one function. *Note Function
- Specific Option Pragmas::, for details about the `#pragma GCC
- optimize' pragma.
-
- This can be used for instance to have frequently executed functions
- compiled with more aggressive optimization options that produce
- faster and larger code, while other functions can be called with
- less aggressive options.
-
-`OS_main/OS_task'
- On AVR, functions with the `OS_main' or `OS_task' attribute do not
- save/restore any call-saved register in their prologue/epilogue.
-
- The `OS_main' attribute can be used when there _is guarantee_ that
- interrupts are disabled at the time when the function is entered.
- This will save resources when the stack pointer has to be changed
- to set up a frame for local variables.
-
- The `OS_task' attribute can be used when there is _no guarantee_
- that interrupts are disabled at that time when the function is
- entered like for, e.g. task functions in a multi-threading
- operating system. In that case, changing the stack pointer
- register will be guarded by save/clear/restore of the global
- interrupt enable flag.
-
- The differences to the `naked' function attrubute are:
- * `naked' functions do not have a return instruction whereas
- `OS_main' and `OS_task' functions will have a `RET' or `RETI'
- return instruction.
-
- * `naked' functions do not set up a frame for local variables
- or a frame pointer whereas `OS_main' and `OS_task' do this as
- needed.
-
-`pcs'
- The `pcs' attribute can be used to control the calling convention
- used for a function on ARM. The attribute takes an argument that
- specifies the calling convention to use.
-
- When compiling using the AAPCS ABI (or a variant of that) then
- valid values for the argument are `"aapcs"' and `"aapcs-vfp"'. In
- order to use a variant other than `"aapcs"' then the compiler must
- be permitted to use the appropriate co-processor registers (i.e.,
- the VFP registers must be available in order to use `"aapcs-vfp"').
- For example,
-
- /* Argument passed in r0, and result returned in r0+r1. */
- double f2d (float) __attribute__((pcs("aapcs")));
-
- Variadic functions always use the `"aapcs"' calling convention and
- the compiler will reject attempts to specify an alternative.
-
-`pure'
- Many functions have no effects except the return value and their
- return value depends only on the parameters and/or global
- variables. Such a function can be subject to common subexpression
- elimination and loop optimization just as an arithmetic operator
- would be. These functions should be declared with the attribute
- `pure'. For example,
-
- int square (int) __attribute__ ((pure));
-
- says that the hypothetical function `square' is safe to call fewer
- times than the program says.
-
- Some of common examples of pure functions are `strlen' or `memcmp'.
- Interesting non-pure functions are functions with infinite loops
- or those depending on volatile memory or other system resource,
- that may change between two consecutive calls (such as `feof' in a
- multithreading environment).
-
- The attribute `pure' is not implemented in GCC versions earlier
- than 2.96.
-
-`hot'
- The `hot' attribute is used to inform the compiler that a function
- is a hot spot of the compiled program. The function is optimized
- more aggressively and on many target it is placed into special
- subsection of the text section so all hot functions appears close
- together improving locality.
-
- When profile feedback is available, via `-fprofile-use', hot
- functions are automatically detected and this attribute is ignored.
-
- The `hot' attribute is not implemented in GCC versions earlier
- than 4.3.
-
-`cold'
- The `cold' attribute is used to inform the compiler that a
- function is unlikely executed. The function is optimized for size
- rather than speed and on many targets it is placed into special
- subsection of the text section so all cold functions appears close
- together improving code locality of non-cold parts of program.
- The paths leading to call of cold functions within code are marked
- as unlikely by the branch prediction mechanism. It is thus useful
- to mark functions used to handle unlikely conditions, such as
- `perror', as cold to improve optimization of hot functions that do
- call marked functions in rare occasions.
-
- When profile feedback is available, via `-fprofile-use', hot
- functions are automatically detected and this attribute is ignored.
-
- The `cold' attribute is not implemented in GCC versions earlier
- than 4.3.
-
-`regparm (NUMBER)'
- On the Intel 386, the `regparm' attribute causes the compiler to
- pass arguments number one to NUMBER if they are of integral type
- in registers EAX, EDX, and ECX instead of on the stack. Functions
- that take a variable number of arguments will continue to be
- passed all of their arguments on the stack.
-
- Beware that on some ELF systems this attribute is unsuitable for
- global functions in shared libraries with lazy binding (which is
- the default). Lazy binding will send the first call via resolving
- code in the loader, which might assume EAX, EDX and ECX can be
- clobbered, as per the standard calling conventions. Solaris 8 is
- affected by this. GNU systems with GLIBC 2.1 or higher, and
- FreeBSD, are believed to be safe since the loaders there save EAX,
- EDX and ECX. (Lazy binding can be disabled with the linker or the
- loader if desired, to avoid the problem.)
-
-`sseregparm'
- On the Intel 386 with SSE support, the `sseregparm' attribute
- causes the compiler to pass up to 3 floating point arguments in
- SSE registers instead of on the stack. Functions that take a
- variable number of arguments will continue to pass all of their
- floating point arguments on the stack.
-
-`force_align_arg_pointer'
- On the Intel x86, the `force_align_arg_pointer' attribute may be
- applied to individual function definitions, generating an alternate
- prologue and epilogue that realigns the runtime stack if necessary.
- This supports mixing legacy codes that run with a 4-byte aligned
- stack with modern codes that keep a 16-byte stack for SSE
- compatibility.
-
-`resbank'
- On the SH2A target, this attribute enables the high-speed register
- saving and restoration using a register bank for
- `interrupt_handler' routines. Saving to the bank is performed
- automatically after the CPU accepts an interrupt that uses a
- register bank.
-
- The nineteen 32-bit registers comprising general register R0 to
- R14, control register GBR, and system registers MACH, MACL, and PR
- and the vector table address offset are saved into a register
- bank. Register banks are stacked in first-in last-out (FILO)
- sequence. Restoration from the bank is executed by issuing a
- RESBANK instruction.
-
-`returns_twice'
- The `returns_twice' attribute tells the compiler that a function
- may return more than one time. The compiler will ensure that all
- registers are dead before calling such a function and will emit a
- warning about the variables that may be clobbered after the second
- return from the function. Examples of such functions are `setjmp'
- and `vfork'. The `longjmp'-like counterpart of such function, if
- any, might need to be marked with the `noreturn' attribute.
-
-`saveall'
- Use this attribute on the Blackfin, H8/300, H8/300H, and H8S to
- indicate that all registers except the stack pointer should be
- saved in the prologue regardless of whether they are used or not.
-
-`save_volatiles'
- Use this attribute on the MicroBlaze to indicate that the function
- is an interrupt handler. All volatile registers (in addition to
- non-volatile registers) will be saved in the function prologue.
- If the function is a leaf function, only volatiles used by the
- function are saved. A normal function return is generated instead
- of a return from interrupt.
-
-`section ("SECTION-NAME")'
- Normally, the compiler places the code it generates in the `text'
- section. Sometimes, however, you need additional sections, or you
- need certain particular functions to appear in special sections.
- The `section' attribute specifies that a function lives in a
- particular section. For example, the declaration:
-
- extern void foobar (void) __attribute__ ((section ("bar")));
-
- puts the function `foobar' in the `bar' section.
-
- Some file formats do not support arbitrary sections so the
- `section' attribute is not available on all platforms. If you
- need to map the entire contents of a module to a particular
- section, consider using the facilities of the linker instead.
-
-`sentinel'
- This function attribute ensures that a parameter in a function
- call is an explicit `NULL'. The attribute is only valid on
- variadic functions. By default, the sentinel is located at
- position zero, the last parameter of the function call. If an
- optional integer position argument P is supplied to the attribute,
- the sentinel must be located at position P counting backwards from
- the end of the argument list.
-
- __attribute__ ((sentinel))
- is equivalent to
- __attribute__ ((sentinel(0)))
-
- The attribute is automatically set with a position of 0 for the
- built-in functions `execl' and `execlp'. The built-in function
- `execle' has the attribute set with a position of 1.
-
- A valid `NULL' in this context is defined as zero with any pointer
- type. If your system defines the `NULL' macro with an integer type
- then you need to add an explicit cast. GCC replaces `stddef.h'
- with a copy that redefines NULL appropriately.
-
- The warnings for missing or incorrect sentinels are enabled with
- `-Wformat'.
-
-`short_call'
- See long_call/short_call.
-
-`shortcall'
- See longcall/shortcall.
-
-`signal'
- Use this attribute on the AVR to indicate that the specified
- function is a signal handler. The compiler will generate function
- entry and exit sequences suitable for use in a signal handler when
- this attribute is present. Interrupts will be disabled inside the
- function.
-
-`sp_switch'
- Use this attribute on the SH to indicate an `interrupt_handler'
- function should switch to an alternate stack. It expects a string
- argument that names a global variable holding the address of the
- alternate stack.
-
- void *alt_stack;
- void f () __attribute__ ((interrupt_handler,
- sp_switch ("alt_stack")));
-
-`stdcall'
- On the Intel 386, the `stdcall' attribute causes the compiler to
- assume that the called function will pop off the stack space used
- to pass arguments, unless it takes a variable number of arguments.
-
-`syscall_linkage'
- This attribute is used to modify the IA64 calling convention by
- marking all input registers as live at all function exits. This
- makes it possible to restart a system call after an interrupt
- without having to save/restore the input registers. This also
- prevents kernel data from leaking into application code.
-
-`target'
- The `target' attribute is used to specify that a function is to be
- compiled with different target options than specified on the
- command line. This can be used for instance to have functions
- compiled with a different ISA (instruction set architecture) than
- the default. You can also use the `#pragma GCC target' pragma to
- set more than one function to be compiled with specific target
- options. *Note Function Specific Option Pragmas::, for details
- about the `#pragma GCC target' pragma.
-
- For instance on a 386, you could compile one function with
- `target("sse4.1,arch=core2")' and another with
- `target("sse4a,arch=amdfam10")' that would be equivalent to
- compiling the first function with `-msse4.1' and `-march=core2'
- options, and the second function with `-msse4a' and
- `-march=amdfam10' options. It is up to the user to make sure that
- a function is only invoked on a machine that supports the
- particular ISA it was compiled for (for example by using `cpuid'
- on 386 to determine what feature bits and architecture family are
- used).
-
- int core2_func (void) __attribute__ ((__target__ ("arch=core2")));
- int sse3_func (void) __attribute__ ((__target__ ("sse3")));
-
- On the 386, the following options are allowed:
-
- `abm'
- `no-abm'
- Enable/disable the generation of the advanced bit
- instructions.
-
- `aes'
- `no-aes'
- Enable/disable the generation of the AES instructions.
-
- `mmx'
- `no-mmx'
- Enable/disable the generation of the MMX instructions.
-
- `pclmul'
- `no-pclmul'
- Enable/disable the generation of the PCLMUL instructions.
-
- `popcnt'
- `no-popcnt'
- Enable/disable the generation of the POPCNT instruction.
-
- `sse'
- `no-sse'
- Enable/disable the generation of the SSE instructions.
-
- `sse2'
- `no-sse2'
- Enable/disable the generation of the SSE2 instructions.
-
- `sse3'
- `no-sse3'
- Enable/disable the generation of the SSE3 instructions.
-
- `sse4'
- `no-sse4'
- Enable/disable the generation of the SSE4 instructions (both
- SSE4.1 and SSE4.2).
-
- `sse4.1'
- `no-sse4.1'
- Enable/disable the generation of the sse4.1 instructions.
-
- `sse4.2'
- `no-sse4.2'
- Enable/disable the generation of the sse4.2 instructions.
-
- `sse4a'
- `no-sse4a'
- Enable/disable the generation of the SSE4A instructions.
-
- `fma4'
- `no-fma4'
- Enable/disable the generation of the FMA4 instructions.
-
- `xop'
- `no-xop'
- Enable/disable the generation of the XOP instructions.
-
- `lwp'
- `no-lwp'
- Enable/disable the generation of the LWP instructions.
-
- `ssse3'
- `no-ssse3'
- Enable/disable the generation of the SSSE3 instructions.
-
- `cld'
- `no-cld'
- Enable/disable the generation of the CLD before string moves.
-
- `fancy-math-387'
- `no-fancy-math-387'
- Enable/disable the generation of the `sin', `cos', and `sqrt'
- instructions on the 387 floating point unit.
-
- `fused-madd'
- `no-fused-madd'
- Enable/disable the generation of the fused multiply/add
- instructions.
-
- `ieee-fp'
- `no-ieee-fp'
- Enable/disable the generation of floating point that depends
- on IEEE arithmetic.
-
- `inline-all-stringops'
- `no-inline-all-stringops'
- Enable/disable inlining of string operations.
-
- `inline-stringops-dynamically'
- `no-inline-stringops-dynamically'
- Enable/disable the generation of the inline code to do small
- string operations and calling the library routines for large
- operations.
-
- `align-stringops'
- `no-align-stringops'
- Do/do not align destination of inlined string operations.
-
- `recip'
- `no-recip'
- Enable/disable the generation of RCPSS, RCPPS, RSQRTSS and
- RSQRTPS instructions followed an additional Newton-Raphson
- step instead of doing a floating point division.
-
- `arch=ARCH'
- Specify the architecture to generate code for in compiling
- the function.
-
- `tune=TUNE'
- Specify the architecture to tune for in compiling the
- function.
-
- `fpmath=FPMATH'
- Specify which floating point unit to use. The
- `target("fpmath=sse,387")' option must be specified as
- `target("fpmath=sse+387")' because the comma would separate
- different options.
-
- On the PowerPC, the following options are allowed:
-
- `altivec'
- `no-altivec'
- Generate code that uses (does not use) AltiVec instructions.
- In 32-bit code, you cannot enable Altivec instructions unless
- `-mabi=altivec' was used on the command line.
-
- `cmpb'
- `no-cmpb'
- Generate code that uses (does not use) the compare bytes
- instruction implemented on the POWER6 processor and other
- processors that support the PowerPC V2.05 architecture.
-
- `dlmzb'
- `no-dlmzb'
- Generate code that uses (does not use) the string-search
- `dlmzb' instruction on the IBM 405, 440, 464 and 476
- processors. This instruction is generated by default when
- targetting those processors.
-
- `fprnd'
- `no-fprnd'
- Generate code that uses (does not use) the FP round to integer
- instructions implemented on the POWER5+ processor and other
- processors that support the PowerPC V2.03 architecture.
-
- `hard-dfp'
- `no-hard-dfp'
- Generate code that uses (does not use) the decimal floating
- point instructions implemented on some POWER processors.
-
- `isel'
- `no-isel'
- Generate code that uses (does not use) ISEL instruction.
-
- `mfcrf'
- `no-mfcrf'
- Generate code that uses (does not use) the move from condition
- register field instruction implemented on the POWER4
- processor and other processors that support the PowerPC V2.01
- architecture.
-
- `mfpgpr'
- `no-mfpgpr'
- Generate code that uses (does not use) the FP move to/from
- general purpose register instructions implemented on the
- POWER6X processor and other processors that support the
- extended PowerPC V2.05 architecture.
-
- `mulhw'
- `no-mulhw'
- Generate code that uses (does not use) the half-word multiply
- and multiply-accumulate instructions on the IBM 405, 440, 464
- and 476 processors. These instructions are generated by
- default when targetting those processors.
-
- `multiple'
- `no-multiple'
- Generate code that uses (does not use) the load multiple word
- instructions and the store multiple word instructions.
-
- `update'
- `no-update'
- Generate code that uses (does not use) the load or store
- instructions that update the base register to the address of
- the calculated memory location.
-
- `popcntb'
- `no-popcntb'
- Generate code that uses (does not use) the popcount and double
- precision FP reciprocal estimate instruction implemented on
- the POWER5 processor and other processors that support the
- PowerPC V2.02 architecture.
-
- `popcntd'
- `no-popcntd'
- Generate code that uses (does not use) the popcount
- instruction implemented on the POWER7 processor and other
- processors that support the PowerPC V2.06 architecture.
-
- `powerpc-gfxopt'
- `no-powerpc-gfxopt'
- Generate code that uses (does not use) the optional PowerPC
- architecture instructions in the Graphics group, including
- floating-point select.
-
- `powerpc-gpopt'
- `no-powerpc-gpopt'
- Generate code that uses (does not use) the optional PowerPC
- architecture instructions in the General Purpose group,
- including floating-point square root.
-
- `recip-precision'
- `no-recip-precision'
- Assume (do not assume) that the reciprocal estimate
- instructions provide higher precision estimates than is
- mandated by the powerpc ABI.
-
- `string'
- `no-string'
- Generate code that uses (does not use) the load string
- instructions and the store string word instructions to save
- multiple registers and do small block moves.
-
- `vsx'
- `no-vsx'
- Generate code that uses (does not use) vector/scalar (VSX)
- instructions, and also enable the use of built-in functions
- that allow more direct access to the VSX instruction set. In
- 32-bit code, you cannot enable VSX or Altivec instructions
- unless `-mabi=altivec' was used on the command line.
-
- `friz'
- `no-friz'
- Generate (do not generate) the `friz' instruction when the
- `-funsafe-math-optimizations' option is used to optimize
- rounding a floating point value to 64-bit integer and back to
- floating point. The `friz' instruction does not return the
- same value if the floating point number is too large to fit
- in an integer.
-
- `avoid-indexed-addresses'
- `no-avoid-indexed-addresses'
- Generate code that tries to avoid (not avoid) the use of
- indexed load or store instructions.
-
- `paired'
- `no-paired'
- Generate code that uses (does not use) the generation of
- PAIRED simd instructions.
-
- `longcall'
- `no-longcall'
- Generate code that assumes (does not assume) that all calls
- are far away so that a longer more expensive calling sequence
- is required.
-
- `cpu=CPU'
- Specify the architecture to generate code for when compiling
- the function. If you select the `"target("cpu=power7)"'
- attribute when generating 32-bit code, VSX and Altivec
- instructions are not generated unless you use the
- `-mabi=altivec' option on the command line.
-
- `tune=TUNE'
- Specify the architecture to tune for when compiling the
- function. If you do not specify the `target("tune=TUNE")'
- attribute and you do specify the `target("cpu=CPU")'
- attribute, compilation will tune for the CPU architecture,
- and not the default tuning specified on the command line.
-
- On the 386/x86_64 and PowerPC backends, you can use either multiple
- strings to specify multiple options, or you can separate the option
- with a comma (`,').
-
- On the 386/x86_64 and PowerPC backends, the inliner will not
- inline a function that has different target options than the
- caller, unless the callee has a subset of the target options of
- the caller. For example a function declared with `target("sse3")'
- can inline a function with `target("sse2")', since `-msse3'
- implies `-msse2'.
-
- The `target' attribute is not implemented in GCC versions earlier
- than 4.4 for the i386/x86_64 and 4.6 for the PowerPC backends. It
- is not currently implemented for other backends.
-
-`tiny_data'
- Use this attribute on the H8/300H and H8S to indicate that the
- specified variable should be placed into the tiny data section.
- The compiler will generate more efficient code for loads and stores
- on data in the tiny data section. Note the tiny data area is
- limited to slightly under 32kbytes of data.
-
-`trap_exit'
- Use this attribute on the SH for an `interrupt_handler' to return
- using `trapa' instead of `rte'. This attribute expects an integer
- argument specifying the trap number to be used.
-
-`unused'
- This attribute, attached to a function, means that the function is
- meant to be possibly unused. GCC will not produce a warning for
- this function.
-
-`used'
- This attribute, attached to a function, means that code must be
- emitted for the function even if it appears that the function is
- not referenced. This is useful, for example, when the function is
- referenced only in inline assembly.
-
-`version_id'
- This IA64 HP-UX attribute, attached to a global variable or
- function, renames a symbol to contain a version string, thus
- allowing for function level versioning. HP-UX system header files
- may use version level functioning for some system calls.
-
- extern int foo () __attribute__((version_id ("20040821")));
-
- Calls to FOO will be mapped to calls to FOO{20040821}.
-
-`visibility ("VISIBILITY_TYPE")'
- This attribute affects the linkage of the declaration to which it
- is attached. There are four supported VISIBILITY_TYPE values:
- default, hidden, protected or internal visibility.
-
- void __attribute__ ((visibility ("protected")))
- f () { /* Do something. */; }
- int i __attribute__ ((visibility ("hidden")));
-
- The possible values of VISIBILITY_TYPE correspond to the
- visibility settings in the ELF gABI.
-
- "default"
- Default visibility is the normal case for the object file
- format. This value is available for the visibility attribute
- to override other options that may change the assumed
- visibility of entities.
-
- On ELF, default visibility means that the declaration is
- visible to other modules and, in shared libraries, means that
- the declared entity may be overridden.
-
- On Darwin, default visibility means that the declaration is
- visible to other modules.
-
- Default visibility corresponds to "external linkage" in the
- language.
-
- "hidden"
- Hidden visibility indicates that the entity declared will
- have a new form of linkage, which we'll call "hidden
- linkage". Two declarations of an object with hidden linkage
- refer to the same object if they are in the same shared
- object.
-
- "internal"
- Internal visibility is like hidden visibility, but with
- additional processor specific semantics. Unless otherwise
- specified by the psABI, GCC defines internal visibility to
- mean that a function is _never_ called from another module.
- Compare this with hidden functions which, while they cannot
- be referenced directly by other modules, can be referenced
- indirectly via function pointers. By indicating that a
- function cannot be called from outside the module, GCC may
- for instance omit the load of a PIC register since it is known
- that the calling function loaded the correct value.
-
- "protected"
- Protected visibility is like default visibility except that it
- indicates that references within the defining module will
- bind to the definition in that module. That is, the declared
- entity cannot be overridden by another module.
-
-
- All visibilities are supported on many, but not all, ELF targets
- (supported when the assembler supports the `.visibility'
- pseudo-op). Default visibility is supported everywhere. Hidden
- visibility is supported on Darwin targets.
-
- The visibility attribute should be applied only to declarations
- which would otherwise have external linkage. The attribute should
- be applied consistently, so that the same entity should not be
- declared with different settings of the attribute.
-
- In C++, the visibility attribute applies to types as well as
- functions and objects, because in C++ types have linkage. A class
- must not have greater visibility than its non-static data member
- types and bases, and class members default to the visibility of
- their class. Also, a declaration without explicit visibility is
- limited to the visibility of its type.
-
- In C++, you can mark member functions and static member variables
- of a class with the visibility attribute. This is useful if you
- know a particular method or static member variable should only be
- used from one shared object; then you can mark it hidden while the
- rest of the class has default visibility. Care must be taken to
- avoid breaking the One Definition Rule; for example, it is usually
- not useful to mark an inline method as hidden without marking the
- whole class as hidden.
-
- A C++ namespace declaration can also have the visibility attribute.
- This attribute applies only to the particular namespace body, not
- to other definitions of the same namespace; it is equivalent to
- using `#pragma GCC visibility' before and after the namespace
- definition (*note Visibility Pragmas::).
-
- In C++, if a template argument has limited visibility, this
- restriction is implicitly propagated to the template instantiation.
- Otherwise, template instantiations and specializations default to
- the visibility of their template.
-
- If both the template and enclosing class have explicit visibility,
- the visibility from the template is used.
-
-`vliw'
- On MeP, the `vliw' attribute tells the compiler to emit
- instructions in VLIW mode instead of core mode. Note that this
- attribute is not allowed unless a VLIW coprocessor has been
- configured and enabled through command line options.
-
-`warn_unused_result'
- The `warn_unused_result' attribute causes a warning to be emitted
- if a caller of the function with this attribute does not use its
- return value. This is useful for functions where not checking the
- result is either a security problem or always a bug, such as
- `realloc'.
-
- int fn () __attribute__ ((warn_unused_result));
- int foo ()
- {
- if (fn () < 0) return -1;
- fn ();
- return 0;
- }
-
- results in warning on line 5.
-
-`weak'
- The `weak' attribute causes the declaration to be emitted as a weak
- symbol rather than a global. This is primarily useful in defining
- library functions which can be overridden in user code, though it
- can also be used with non-function declarations. Weak symbols are
- supported for ELF targets, and also for a.out targets when using
- the GNU assembler and linker.
-
-`weakref'
-`weakref ("TARGET")'
- The `weakref' attribute marks a declaration as a weak reference.
- Without arguments, it should be accompanied by an `alias' attribute
- naming the target symbol. Optionally, the TARGET may be given as
- an argument to `weakref' itself. In either case, `weakref'
- implicitly marks the declaration as `weak'. Without a TARGET,
- given as an argument to `weakref' or to `alias', `weakref' is
- equivalent to `weak'.
-
- static int x() __attribute__ ((weakref ("y")));
- /* is equivalent to... */
- static int x() __attribute__ ((weak, weakref, alias ("y")));
- /* and to... */
- static int x() __attribute__ ((weakref));
- static int x() __attribute__ ((alias ("y")));
-
- A weak reference is an alias that does not by itself require a
- definition to be given for the target symbol. If the target
- symbol is only referenced through weak references, then it becomes
- a `weak' undefined symbol. If it is directly referenced, however,
- then such strong references prevail, and a definition will be
- required for the symbol, not necessarily in the same translation
- unit.
-
- The effect is equivalent to moving all references to the alias to a
- separate translation unit, renaming the alias to the aliased
- symbol, declaring it as weak, compiling the two separate
- translation units and performing a reloadable link on them.
-
- At present, a declaration to which `weakref' is attached can only
- be `static'.
-
-
- You can specify multiple attributes in a declaration by separating them
-by commas within the double parentheses or by immediately following an
-attribute declaration with another attribute declaration.
-
- Some people object to the `__attribute__' feature, suggesting that ISO
-C's `#pragma' should be used instead. At the time `__attribute__' was
-designed, there were two reasons for not doing this.
-
- 1. It is impossible to generate `#pragma' commands from a macro.
-
- 2. There is no telling what the same `#pragma' might mean in another
- compiler.
-
- These two reasons applied to almost any application that might have
-been proposed for `#pragma'. It was basically a mistake to use
-`#pragma' for _anything_.
-
- The ISO C99 standard includes `_Pragma', which now allows pragmas to
-be generated from macros. In addition, a `#pragma GCC' namespace is
-now in use for GCC-specific pragmas. However, it has been found
-convenient to use `__attribute__' to achieve a natural attachment of
-attributes to their corresponding declarations, whereas `#pragma GCC'
-is of use for constructs that do not naturally form part of the
-grammar. *Note Miscellaneous Preprocessing Directives: (cpp)Other
-Directives.
-
-
-File: gcc.info, Node: Attribute Syntax, Next: Function Prototypes, Prev: Function Attributes, Up: C Extensions
-
-6.31 Attribute Syntax
-=====================
-
-This section describes the syntax with which `__attribute__' may be
-used, and the constructs to which attribute specifiers bind, for the C
-language. Some details may vary for C++ and Objective-C. Because of
-infelicities in the grammar for attributes, some forms described here
-may not be successfully parsed in all cases.
-
- There are some problems with the semantics of attributes in C++. For
-example, there are no manglings for attributes, although they may affect
-code generation, so problems may arise when attributed types are used in
-conjunction with templates or overloading. Similarly, `typeid' does
-not distinguish between types with different attributes. Support for
-attributes in C++ may be restricted in future to attributes on
-declarations only, but not on nested declarators.
-
- *Note Function Attributes::, for details of the semantics of attributes
-applying to functions. *Note Variable Attributes::, for details of the
-semantics of attributes applying to variables. *Note Type Attributes::,
-for details of the semantics of attributes applying to structure, union
-and enumerated types.
-
- An "attribute specifier" is of the form `__attribute__
-((ATTRIBUTE-LIST))'. An "attribute list" is a possibly empty
-comma-separated sequence of "attributes", where each attribute is one
-of the following:
-
- * Empty. Empty attributes are ignored.
-
- * A word (which may be an identifier such as `unused', or a reserved
- word such as `const').
-
- * A word, followed by, in parentheses, parameters for the attribute.
- These parameters take one of the following forms:
-
- * An identifier. For example, `mode' attributes use this form.
-
- * An identifier followed by a comma and a non-empty
- comma-separated list of expressions. For example, `format'
- attributes use this form.
-
- * A possibly empty comma-separated list of expressions. For
- example, `format_arg' attributes use this form with the list
- being a single integer constant expression, and `alias'
- attributes use this form with the list being a single string
- constant.
-
- An "attribute specifier list" is a sequence of one or more attribute
-specifiers, not separated by any other tokens.
-
- In GNU C, an attribute specifier list may appear after the colon
-following a label, other than a `case' or `default' label. The only
-attribute it makes sense to use after a label is `unused'. This
-feature is intended for code generated by programs which contains labels
-that may be unused but which is compiled with `-Wall'. It would not
-normally be appropriate to use in it human-written code, though it
-could be useful in cases where the code that jumps to the label is
-contained within an `#ifdef' conditional. GNU C++ only permits
-attributes on labels if the attribute specifier is immediately followed
-by a semicolon (i.e., the label applies to an empty statement). If the
-semicolon is missing, C++ label attributes are ambiguous, as it is
-permissible for a declaration, which could begin with an attribute
-list, to be labelled in C++. Declarations cannot be labelled in C90 or
-C99, so the ambiguity does not arise there.
-
- An attribute specifier list may appear as part of a `struct', `union'
-or `enum' specifier. It may go either immediately after the `struct',
-`union' or `enum' keyword, or after the closing brace. The former
-syntax is preferred. Where attribute specifiers follow the closing
-brace, they are considered to relate to the structure, union or
-enumerated type defined, not to any enclosing declaration the type
-specifier appears in, and the type defined is not complete until after
-the attribute specifiers.
-
- Otherwise, an attribute specifier appears as part of a declaration,
-counting declarations of unnamed parameters and type names, and relates
-to that declaration (which may be nested in another declaration, for
-example in the case of a parameter declaration), or to a particular
-declarator within a declaration. Where an attribute specifier is
-applied to a parameter declared as a function or an array, it should
-apply to the function or array rather than the pointer to which the
-parameter is implicitly converted, but this is not yet correctly
-implemented.
-
- Any list of specifiers and qualifiers at the start of a declaration may
-contain attribute specifiers, whether or not such a list may in that
-context contain storage class specifiers. (Some attributes, however,
-are essentially in the nature of storage class specifiers, and only make
-sense where storage class specifiers may be used; for example,
-`section'.) There is one necessary limitation to this syntax: the
-first old-style parameter declaration in a function definition cannot
-begin with an attribute specifier, because such an attribute applies to
-the function instead by syntax described below (which, however, is not
-yet implemented in this case). In some other cases, attribute
-specifiers are permitted by this grammar but not yet supported by the
-compiler. All attribute specifiers in this place relate to the
-declaration as a whole. In the obsolescent usage where a type of `int'
-is implied by the absence of type specifiers, such a list of specifiers
-and qualifiers may be an attribute specifier list with no other
-specifiers or qualifiers.
-
- At present, the first parameter in a function prototype must have some
-type specifier which is not an attribute specifier; this resolves an
-ambiguity in the interpretation of `void f(int (__attribute__((foo))
-x))', but is subject to change. At present, if the parentheses of a
-function declarator contain only attributes then those attributes are
-ignored, rather than yielding an error or warning or implying a single
-parameter of type int, but this is subject to change.
-
- An attribute specifier list may appear immediately before a declarator
-(other than the first) in a comma-separated list of declarators in a
-declaration of more than one identifier using a single list of
-specifiers and qualifiers. Such attribute specifiers apply only to the
-identifier before whose declarator they appear. For example, in
-
- __attribute__((noreturn)) void d0 (void),
- __attribute__((format(printf, 1, 2))) d1 (const char *, ...),
- d2 (void)
-
-the `noreturn' attribute applies to all the functions declared; the
-`format' attribute only applies to `d1'.
-
- An attribute specifier list may appear immediately before the comma,
-`=' or semicolon terminating the declaration of an identifier other
-than a function definition. Such attribute specifiers apply to the
-declared object or function. Where an assembler name for an object or
-function is specified (*note Asm Labels::), the attribute must follow
-the `asm' specification.
-
- An attribute specifier list may, in future, be permitted to appear
-after the declarator in a function definition (before any old-style
-parameter declarations or the function body).
-
- Attribute specifiers may be mixed with type qualifiers appearing inside
-the `[]' of a parameter array declarator, in the C99 construct by which
-such qualifiers are applied to the pointer to which the array is
-implicitly converted. Such attribute specifiers apply to the pointer,
-not to the array, but at present this is not implemented and they are
-ignored.
-
- An attribute specifier list may appear at the start of a nested
-declarator. At present, there are some limitations in this usage: the
-attributes correctly apply to the declarator, but for most individual
-attributes the semantics this implies are not implemented. When
-attribute specifiers follow the `*' of a pointer declarator, they may
-be mixed with any type qualifiers present. The following describes the
-formal semantics of this syntax. It will make the most sense if you
-are familiar with the formal specification of declarators in the ISO C
-standard.
-
- Consider (as in C99 subclause 6.7.5 paragraph 4) a declaration `T D1',
-where `T' contains declaration specifiers that specify a type TYPE
-(such as `int') and `D1' is a declarator that contains an identifier
-IDENT. The type specified for IDENT for derived declarators whose type
-does not include an attribute specifier is as in the ISO C standard.
-
- If `D1' has the form `( ATTRIBUTE-SPECIFIER-LIST D )', and the
-declaration `T D' specifies the type "DERIVED-DECLARATOR-TYPE-LIST
-TYPE" for IDENT, then `T D1' specifies the type
-"DERIVED-DECLARATOR-TYPE-LIST ATTRIBUTE-SPECIFIER-LIST TYPE" for IDENT.
-
- If `D1' has the form `* TYPE-QUALIFIER-AND-ATTRIBUTE-SPECIFIER-LIST
-D', and the declaration `T D' specifies the type
-"DERIVED-DECLARATOR-TYPE-LIST TYPE" for IDENT, then `T D1' specifies
-the type "DERIVED-DECLARATOR-TYPE-LIST
-TYPE-QUALIFIER-AND-ATTRIBUTE-SPECIFIER-LIST pointer to TYPE" for IDENT.
-
- For example,
-
- void (__attribute__((noreturn)) ****f) (void);
-
-specifies the type "pointer to pointer to pointer to pointer to
-non-returning function returning `void'". As another example,
-
- char *__attribute__((aligned(8))) *f;
-
-specifies the type "pointer to 8-byte-aligned pointer to `char'". Note
-again that this does not work with most attributes; for example, the
-usage of `aligned' and `noreturn' attributes given above is not yet
-supported.
-
- For compatibility with existing code written for compiler versions that
-did not implement attributes on nested declarators, some laxity is
-allowed in the placing of attributes. If an attribute that only applies
-to types is applied to a declaration, it will be treated as applying to
-the type of that declaration. If an attribute that only applies to
-declarations is applied to the type of a declaration, it will be treated
-as applying to that declaration; and, for compatibility with code
-placing the attributes immediately before the identifier declared, such
-an attribute applied to a function return type will be treated as
-applying to the function type, and such an attribute applied to an array
-element type will be treated as applying to the array type. If an
-attribute that only applies to function types is applied to a
-pointer-to-function type, it will be treated as applying to the pointer
-target type; if such an attribute is applied to a function return type
-that is not a pointer-to-function type, it will be treated as applying
-to the function type.
-
-
-File: gcc.info, Node: Function Prototypes, Next: C++ Comments, Prev: Attribute Syntax, Up: C Extensions
-
-6.32 Prototypes and Old-Style Function Definitions
-==================================================
-
-GNU C extends ISO C to allow a function prototype to override a later
-old-style non-prototype definition. Consider the following example:
-
- /* Use prototypes unless the compiler is old-fashioned. */
- #ifdef __STDC__
- #define P(x) x
- #else
- #define P(x) ()
- #endif
-
- /* Prototype function declaration. */
- int isroot P((uid_t));
-
- /* Old-style function definition. */
- int
- isroot (x) /* ??? lossage here ??? */
- uid_t x;
- {
- return x == 0;
- }
-
- Suppose the type `uid_t' happens to be `short'. ISO C does not allow
-this example, because subword arguments in old-style non-prototype
-definitions are promoted. Therefore in this example the function
-definition's argument is really an `int', which does not match the
-prototype argument type of `short'.
-
- This restriction of ISO C makes it hard to write code that is portable
-to traditional C compilers, because the programmer does not know
-whether the `uid_t' type is `short', `int', or `long'. Therefore, in
-cases like these GNU C allows a prototype to override a later old-style
-definition. More precisely, in GNU C, a function prototype argument
-type overrides the argument type specified by a later old-style
-definition if the former type is the same as the latter type before
-promotion. Thus in GNU C the above example is equivalent to the
-following:
-
- int isroot (uid_t);
-
- int
- isroot (uid_t x)
- {
- return x == 0;
- }
-
-GNU C++ does not support old-style function definitions, so this
-extension is irrelevant.
-
-
-File: gcc.info, Node: C++ Comments, Next: Dollar Signs, Prev: Function Prototypes, Up: C Extensions
-
-6.33 C++ Style Comments
-=======================
-
-In GNU C, you may use C++ style comments, which start with `//' and
-continue until the end of the line. Many other C implementations allow
-such comments, and they are included in the 1999 C standard. However,
-C++ style comments are not recognized if you specify an `-std' option
-specifying a version of ISO C before C99, or `-ansi' (equivalent to
-`-std=c90').
-
-
-File: gcc.info, Node: Dollar Signs, Next: Character Escapes, Prev: C++ Comments, Up: C Extensions
-
-6.34 Dollar Signs in Identifier Names
-=====================================
-
-In GNU C, you may normally use dollar signs in identifier names. This
-is because many traditional C implementations allow such identifiers.
-However, dollar signs in identifiers are not supported on a few target
-machines, typically because the target assembler does not allow them.
-
-
-File: gcc.info, Node: Character Escapes, Next: Variable Attributes, Prev: Dollar Signs, Up: C Extensions
-
-6.35 The Character <ESC> in Constants
-=====================================
-
-You can use the sequence `\e' in a string or character constant to
-stand for the ASCII character <ESC>.
-
-
-File: gcc.info, Node: Variable Attributes, Next: Type Attributes, Prev: Character Escapes, Up: C Extensions
-
-6.36 Specifying Attributes of Variables
-=======================================
-
-The keyword `__attribute__' allows you to specify special attributes of
-variables or structure fields. This keyword is followed by an
-attribute specification inside double parentheses. Some attributes are
-currently defined generically for variables. Other attributes are
-defined for variables on particular target systems. Other attributes
-are available for functions (*note Function Attributes::) and for types
-(*note Type Attributes::). Other front ends might define more
-attributes (*note Extensions to the C++ Language: C++ Extensions.).
-
- You may also specify attributes with `__' preceding and following each
-keyword. This allows you to use them in header files without being
-concerned about a possible macro of the same name. For example, you
-may use `__aligned__' instead of `aligned'.
-
- *Note Attribute Syntax::, for details of the exact syntax for using
-attributes.
-
-`aligned (ALIGNMENT)'
- This attribute specifies a minimum alignment for the variable or
- structure field, measured in bytes. For example, the declaration:
-
- int x __attribute__ ((aligned (16))) = 0;
-
- causes the compiler to allocate the global variable `x' on a
- 16-byte boundary. On a 68040, this could be used in conjunction
- with an `asm' expression to access the `move16' instruction which
- requires 16-byte aligned operands.
-
- You can also specify the alignment of structure fields. For
- example, to create a double-word aligned `int' pair, you could
- write:
-
- struct foo { int x[2] __attribute__ ((aligned (8))); };
-
- This is an alternative to creating a union with a `double' member
- that forces the union to be double-word aligned.
-
- As in the preceding examples, you can explicitly specify the
- alignment (in bytes) that you wish the compiler to use for a given
- variable or structure field. Alternatively, you can leave out the
- alignment factor and just ask the compiler to align a variable or
- field to the default alignment for the target architecture you are
- compiling for. The default alignment is sufficient for all scalar
- types, but may not be enough for all vector types on a target
- which supports vector operations. The default alignment is fixed
- for a particular target ABI.
-
- Gcc also provides a target specific macro `__BIGGEST_ALIGNMENT__',
- which is the largest alignment ever used for any data type on the
- target machine you are compiling for. For example, you could
- write:
-
- short array[3] __attribute__ ((aligned (__BIGGEST_ALIGNMENT__)));
-
- The compiler automatically sets the alignment for the declared
- variable or field to `__BIGGEST_ALIGNMENT__'. Doing this can
- often make copy operations more efficient, because the compiler can
- use whatever instructions copy the biggest chunks of memory when
- performing copies to or from the variables or fields that you have
- aligned this way. Note that the value of `__BIGGEST_ALIGNMENT__'
- may change depending on command line options.
-
- When used on a struct, or struct member, the `aligned' attribute
- can only increase the alignment; in order to decrease it, the
- `packed' attribute must be specified as well. When used as part
- of a typedef, the `aligned' attribute can both increase and
- decrease alignment, and specifying the `packed' attribute will
- generate a warning.
-
- Note that the effectiveness of `aligned' attributes may be limited
- by inherent limitations in your linker. On many systems, the
- linker is only able to arrange for variables to be aligned up to a
- certain maximum alignment. (For some linkers, the maximum
- supported alignment may be very very small.) If your linker is
- only able to align variables up to a maximum of 8 byte alignment,
- then specifying `aligned(16)' in an `__attribute__' will still
- only provide you with 8 byte alignment. See your linker
- documentation for further information.
-
- The `aligned' attribute can also be used for functions (*note
- Function Attributes::.)
-
-`cleanup (CLEANUP_FUNCTION)'
- The `cleanup' attribute runs a function when the variable goes out
- of scope. This attribute can only be applied to auto function
- scope variables; it may not be applied to parameters or variables
- with static storage duration. The function must take one
- parameter, a pointer to a type compatible with the variable. The
- return value of the function (if any) is ignored.
-
- If `-fexceptions' is enabled, then CLEANUP_FUNCTION will be run
- during the stack unwinding that happens during the processing of
- the exception. Note that the `cleanup' attribute does not allow
- the exception to be caught, only to perform an action. It is
- undefined what happens if CLEANUP_FUNCTION does not return
- normally.
-
-`common'
-`nocommon'
- The `common' attribute requests GCC to place a variable in
- "common" storage. The `nocommon' attribute requests the
- opposite--to allocate space for it directly.
-
- These attributes override the default chosen by the `-fno-common'
- and `-fcommon' flags respectively.
-
-`deprecated'
-`deprecated (MSG)'
- The `deprecated' attribute results in a warning if the variable is
- used anywhere in the source file. This is useful when identifying
- variables that are expected to be removed in a future version of a
- program. The warning also includes the location of the declaration
- of the deprecated variable, to enable users to easily find further
- information about why the variable is deprecated, or what they
- should do instead. Note that the warning only occurs for uses:
-
- extern int old_var __attribute__ ((deprecated));
- extern int old_var;
- int new_fn () { return old_var; }
-
- results in a warning on line 3 but not line 2. The optional msg
- argument, which must be a string, will be printed in the warning if
- present.
-
- The `deprecated' attribute can also be used for functions and
- types (*note Function Attributes::, *note Type Attributes::.)
-
-`mode (MODE)'
- This attribute specifies the data type for the
- declaration--whichever type corresponds to the mode MODE. This in
- effect lets you request an integer or floating point type
- according to its width.
-
- You may also specify a mode of `byte' or `__byte__' to indicate
- the mode corresponding to a one-byte integer, `word' or `__word__'
- for the mode of a one-word integer, and `pointer' or `__pointer__'
- for the mode used to represent pointers.
-
-`packed'
- The `packed' attribute specifies that a variable or structure field
- should have the smallest possible alignment--one byte for a
- variable, and one bit for a field, unless you specify a larger
- value with the `aligned' attribute.
-
- Here is a structure in which the field `x' is packed, so that it
- immediately follows `a':
-
- struct foo
- {
- char a;
- int x[2] __attribute__ ((packed));
- };
-
- _Note:_ The 4.1, 4.2 and 4.3 series of GCC ignore the `packed'
- attribute on bit-fields of type `char'. This has been fixed in
- GCC 4.4 but the change can lead to differences in the structure
- layout. See the documentation of `-Wpacked-bitfield-compat' for
- more information.
-
-`section ("SECTION-NAME")'
- Normally, the compiler places the objects it generates in sections
- like `data' and `bss'. Sometimes, however, you need additional
- sections, or you need certain particular variables to appear in
- special sections, for example to map to special hardware. The
- `section' attribute specifies that a variable (or function) lives
- in a particular section. For example, this small program uses
- several specific section names:
-
- struct duart a __attribute__ ((section ("DUART_A"))) = { 0 };
- struct duart b __attribute__ ((section ("DUART_B"))) = { 0 };
- char stack[10000] __attribute__ ((section ("STACK"))) = { 0 };
- int init_data __attribute__ ((section ("INITDATA")));
-
- main()
- {
- /* Initialize stack pointer */
- init_sp (stack + sizeof (stack));
-
- /* Initialize initialized data */
- memcpy (&init_data, &data, &edata - &data);
-
- /* Turn on the serial ports */
- init_duart (&a);
- init_duart (&b);
- }
-
- Use the `section' attribute with _global_ variables and not
- _local_ variables, as shown in the example.
-
- You may use the `section' attribute with initialized or
- uninitialized global variables but the linker requires each object
- be defined once, with the exception that uninitialized variables
- tentatively go in the `common' (or `bss') section and can be
- multiply "defined". Using the `section' attribute will change
- what section the variable goes into and may cause the linker to
- issue an error if an uninitialized variable has multiple
- definitions. You can force a variable to be initialized with the
- `-fno-common' flag or the `nocommon' attribute.
-
- Some file formats do not support arbitrary sections so the
- `section' attribute is not available on all platforms. If you
- need to map the entire contents of a module to a particular
- section, consider using the facilities of the linker instead.
-
-`shared'
- On Microsoft Windows, in addition to putting variable definitions
- in a named section, the section can also be shared among all
- running copies of an executable or DLL. For example, this small
- program defines shared data by putting it in a named section
- `shared' and marking the section shareable:
-
- int foo __attribute__((section ("shared"), shared)) = 0;
-
- int
- main()
- {
- /* Read and write foo. All running
- copies see the same value. */
- return 0;
- }
-
- You may only use the `shared' attribute along with `section'
- attribute with a fully initialized global definition because of
- the way linkers work. See `section' attribute for more
- information.
-
- The `shared' attribute is only available on Microsoft Windows.
-
-`tls_model ("TLS_MODEL")'
- The `tls_model' attribute sets thread-local storage model (*note
- Thread-Local::) of a particular `__thread' variable, overriding
- `-ftls-model=' command-line switch on a per-variable basis. The
- TLS_MODEL argument should be one of `global-dynamic',
- `local-dynamic', `initial-exec' or `local-exec'.
-
- Not all targets support this attribute.
-
-`unused'
- This attribute, attached to a variable, means that the variable is
- meant to be possibly unused. GCC will not produce a warning for
- this variable.
-
-`used'
- This attribute, attached to a variable, means that the variable
- must be emitted even if it appears that the variable is not
- referenced.
-
-`vector_size (BYTES)'
- This attribute specifies the vector size for the variable,
- measured in bytes. For example, the declaration:
-
- int foo __attribute__ ((vector_size (16)));
-
- causes the compiler to set the mode for `foo', to be 16 bytes,
- divided into `int' sized units. Assuming a 32-bit int (a vector of
- 4 units of 4 bytes), the corresponding mode of `foo' will be V4SI.
-
- This attribute is only applicable to integral and float scalars,
- although arrays, pointers, and function return values are allowed
- in conjunction with this construct.
-
- Aggregates with this attribute are invalid, even if they are of
- the same size as a corresponding scalar. For example, the
- declaration:
-
- struct S { int a; };
- struct S __attribute__ ((vector_size (16))) foo;
-
- is invalid even if the size of the structure is the same as the
- size of the `int'.
-
-`selectany'
- The `selectany' attribute causes an initialized global variable to
- have link-once semantics. When multiple definitions of the
- variable are encountered by the linker, the first is selected and
- the remainder are discarded. Following usage by the Microsoft
- compiler, the linker is told _not_ to warn about size or content
- differences of the multiple definitions.
-
- Although the primary usage of this attribute is for POD types, the
- attribute can also be applied to global C++ objects that are
- initialized by a constructor. In this case, the static
- initialization and destruction code for the object is emitted in
- each translation defining the object, but the calls to the
- constructor and destructor are protected by a link-once guard
- variable.
-
- The `selectany' attribute is only available on Microsoft Windows
- targets. You can use `__declspec (selectany)' as a synonym for
- `__attribute__ ((selectany))' for compatibility with other
- compilers.
-
-`weak'
- The `weak' attribute is described in *note Function Attributes::.
-
-`dllimport'
- The `dllimport' attribute is described in *note Function
- Attributes::.
-
-`dllexport'
- The `dllexport' attribute is described in *note Function
- Attributes::.
-
-
-6.36.1 AVR Variable Attributes
-------------------------------
-
-`progmem'
- The `progmem' attribute is used on the AVR to place data in the
- program memory address space (flash). This is accomplished by
- putting respective variables into a section whose name starts with
- `.progmem'.
-
- AVR is a Harvard architecture processor and data and reas only data
- normally resides in the data memory address space (RAM).
-
-6.36.2 Blackfin Variable Attributes
------------------------------------
-
-Three attributes are currently defined for the Blackfin.
-
-`l1_data'
-`l1_data_A'
-`l1_data_B'
- Use these attributes on the Blackfin to place the variable into L1
- Data SRAM. Variables with `l1_data' attribute will be put into
- the specific section named `.l1.data'. Those with `l1_data_A'
- attribute will be put into the specific section named
- `.l1.data.A'. Those with `l1_data_B' attribute will be put into
- the specific section named `.l1.data.B'.
-
-`l2'
- Use this attribute on the Blackfin to place the variable into L2
- SRAM. Variables with `l2' attribute will be put into the specific
- section named `.l2.data'.
-
-6.36.3 M32R/D Variable Attributes
----------------------------------
-
-One attribute is currently defined for the M32R/D.
-
-`model (MODEL-NAME)'
- Use this attribute on the M32R/D to set the addressability of an
- object. The identifier MODEL-NAME is one of `small', `medium', or
- `large', representing each of the code models.
-
- Small model objects live in the lower 16MB of memory (so that their
- addresses can be loaded with the `ld24' instruction).
-
- Medium and large model objects may live anywhere in the 32-bit
- address space (the compiler will generate `seth/add3' instructions
- to load their addresses).
-
-6.36.4 MeP Variable Attributes
-------------------------------
-
-The MeP target has a number of addressing modes and busses. The `near'
-space spans the standard memory space's first 16 megabytes (24 bits).
-The `far' space spans the entire 32-bit memory space. The `based'
-space is a 128 byte region in the memory space which is addressed
-relative to the `$tp' register. The `tiny' space is a 65536 byte
-region relative to the `$gp' register. In addition to these memory
-regions, the MeP target has a separate 16-bit control bus which is
-specified with `cb' attributes.
-
-`based'
- Any variable with the `based' attribute will be assigned to the
- `.based' section, and will be accessed with relative to the `$tp'
- register.
-
-`tiny'
- Likewise, the `tiny' attribute assigned variables to the `.tiny'
- section, relative to the `$gp' register.
-
-`near'
- Variables with the `near' attribute are assumed to have addresses
- that fit in a 24-bit addressing mode. This is the default for
- large variables (`-mtiny=4' is the default) but this attribute can
- override `-mtiny=' for small variables, or override `-ml'.
-
-`far'
- Variables with the `far' attribute are addressed using a full
- 32-bit address. Since this covers the entire memory space, this
- allows modules to make no assumptions about where variables might
- be stored.
-
-`io'
-`io (ADDR)'
- Variables with the `io' attribute are used to address
- memory-mapped peripherals. If an address is specified, the
- variable is assigned that address, else it is not assigned an
- address (it is assumed some other module will assign an address).
- Example:
-
- int timer_count __attribute__((io(0x123)));
-
-`cb'
-`cb (ADDR)'
- Variables with the `cb' attribute are used to access the control
- bus, using special instructions. `addr' indicates the control bus
- address. Example:
-
- int cpu_clock __attribute__((cb(0x123)));
-
-
-6.36.5 i386 Variable Attributes
--------------------------------
-
-Two attributes are currently defined for i386 configurations:
-`ms_struct' and `gcc_struct'
-
-`ms_struct'
-`gcc_struct'
- If `packed' is used on a structure, or if bit-fields are used it
- may be that the Microsoft ABI packs them differently than GCC
- would normally pack them. Particularly when moving packed data
- between functions compiled with GCC and the native Microsoft
- compiler (either via function call or as data in a file), it may
- be necessary to access either format.
-
- Currently `-m[no-]ms-bitfields' is provided for the Microsoft
- Windows X86 compilers to match the native Microsoft compiler.
-
- The Microsoft structure layout algorithm is fairly simple with the
- exception of the bitfield packing:
-
- The padding and alignment of members of structures and whether a
- bit field can straddle a storage-unit boundary
-
- 1. Structure members are stored sequentially in the order in
- which they are declared: the first member has the lowest
- memory address and the last member the highest.
-
- 2. Every data object has an alignment-requirement. The
- alignment-requirement for all data except structures, unions,
- and arrays is either the size of the object or the current
- packing size (specified with either the aligned attribute or
- the pack pragma), whichever is less. For structures, unions,
- and arrays, the alignment-requirement is the largest
- alignment-requirement of its members. Every object is
- allocated an offset so that:
-
- offset % alignment-requirement == 0
-
- 3. Adjacent bit fields are packed into the same 1-, 2-, or
- 4-byte allocation unit if the integral types are the same
- size and if the next bit field fits into the current
- allocation unit without crossing the boundary imposed by the
- common alignment requirements of the bit fields.
-
- Handling of zero-length bitfields:
-
- MSVC interprets zero-length bitfields in the following ways:
-
- 1. If a zero-length bitfield is inserted between two bitfields
- that would normally be coalesced, the bitfields will not be
- coalesced.
-
- For example:
-
- struct
- {
- unsigned long bf_1 : 12;
- unsigned long : 0;
- unsigned long bf_2 : 12;
- } t1;
-
- The size of `t1' would be 8 bytes with the zero-length
- bitfield. If the zero-length bitfield were removed, `t1''s
- size would be 4 bytes.
-
- 2. If a zero-length bitfield is inserted after a bitfield,
- `foo', and the alignment of the zero-length bitfield is
- greater than the member that follows it, `bar', `bar' will be
- aligned as the type of the zero-length bitfield.
-
- For example:
-
- struct
- {
- char foo : 4;
- short : 0;
- char bar;
- } t2;
-
- struct
- {
- char foo : 4;
- short : 0;
- double bar;
- } t3;
-
- For `t2', `bar' will be placed at offset 2, rather than
- offset 1. Accordingly, the size of `t2' will be 4. For
- `t3', the zero-length bitfield will not affect the alignment
- of `bar' or, as a result, the size of the structure.
-
- Taking this into account, it is important to note the
- following:
-
- 1. If a zero-length bitfield follows a normal bitfield, the
- type of the zero-length bitfield may affect the
- alignment of the structure as whole. For example, `t2'
- has a size of 4 bytes, since the zero-length bitfield
- follows a normal bitfield, and is of type short.
-
- 2. Even if a zero-length bitfield is not followed by a
- normal bitfield, it may still affect the alignment of
- the structure:
-
- struct
- {
- char foo : 6;
- long : 0;
- } t4;
-
- Here, `t4' will take up 4 bytes.
-
- 3. Zero-length bitfields following non-bitfield members are
- ignored:
-
- struct
- {
- char foo;
- long : 0;
- char bar;
- } t5;
-
- Here, `t5' will take up 2 bytes.
-
-6.36.6 PowerPC Variable Attributes
-----------------------------------
-
-Three attributes currently are defined for PowerPC configurations:
-`altivec', `ms_struct' and `gcc_struct'.
-
- For full documentation of the struct attributes please see the
-documentation in *note i386 Variable Attributes::.
-
- For documentation of `altivec' attribute please see the documentation
-in *note PowerPC Type Attributes::.
-
-6.36.7 SPU Variable Attributes
-------------------------------
-
-The SPU supports the `spu_vector' attribute for variables. For
-documentation of this attribute please see the documentation in *note
-SPU Type Attributes::.
-
-6.36.8 Xstormy16 Variable Attributes
-------------------------------------
-
-One attribute is currently defined for xstormy16 configurations:
-`below100'.
-
-`below100'
- If a variable has the `below100' attribute (`BELOW100' is allowed
- also), GCC will place the variable in the first 0x100 bytes of
- memory and use special opcodes to access it. Such variables will
- be placed in either the `.bss_below100' section or the
- `.data_below100' section.
-
-
-
-File: gcc.info, Node: Type Attributes, Next: Alignment, Prev: Variable Attributes, Up: C Extensions
-
-6.37 Specifying Attributes of Types
-===================================
-
-The keyword `__attribute__' allows you to specify special attributes of
-`struct' and `union' types when you define such types. This keyword is
-followed by an attribute specification inside double parentheses.
-Seven attributes are currently defined for types: `aligned', `packed',
-`transparent_union', `unused', `deprecated', `visibility', and
-`may_alias'. Other attributes are defined for functions (*note
-Function Attributes::) and for variables (*note Variable Attributes::).
-
- You may also specify any one of these attributes with `__' preceding
-and following its keyword. This allows you to use these attributes in
-header files without being concerned about a possible macro of the same
-name. For example, you may use `__aligned__' instead of `aligned'.
-
- You may specify type attributes in an enum, struct or union type
-declaration or definition, or for other types in a `typedef'
-declaration.
-
- For an enum, struct or union type, you may specify attributes either
-between the enum, struct or union tag and the name of the type, or just
-past the closing curly brace of the _definition_. The former syntax is
-preferred.
-
- *Note Attribute Syntax::, for details of the exact syntax for using
-attributes.
-
-`aligned (ALIGNMENT)'
- This attribute specifies a minimum alignment (in bytes) for
- variables of the specified type. For example, the declarations:
-
- struct S { short f[3]; } __attribute__ ((aligned (8)));
- typedef int more_aligned_int __attribute__ ((aligned (8)));
-
- force the compiler to insure (as far as it can) that each variable
- whose type is `struct S' or `more_aligned_int' will be allocated
- and aligned _at least_ on a 8-byte boundary. On a SPARC, having
- all variables of type `struct S' aligned to 8-byte boundaries
- allows the compiler to use the `ldd' and `std' (doubleword load and
- store) instructions when copying one variable of type `struct S' to
- another, thus improving run-time efficiency.
-
- Note that the alignment of any given `struct' or `union' type is
- required by the ISO C standard to be at least a perfect multiple of
- the lowest common multiple of the alignments of all of the members
- of the `struct' or `union' in question. This means that you _can_
- effectively adjust the alignment of a `struct' or `union' type by
- attaching an `aligned' attribute to any one of the members of such
- a type, but the notation illustrated in the example above is a
- more obvious, intuitive, and readable way to request the compiler
- to adjust the alignment of an entire `struct' or `union' type.
-
- As in the preceding example, you can explicitly specify the
- alignment (in bytes) that you wish the compiler to use for a given
- `struct' or `union' type. Alternatively, you can leave out the
- alignment factor and just ask the compiler to align a type to the
- maximum useful alignment for the target machine you are compiling
- for. For example, you could write:
-
- struct S { short f[3]; } __attribute__ ((aligned));
-
- Whenever you leave out the alignment factor in an `aligned'
- attribute specification, the compiler automatically sets the
- alignment for the type to the largest alignment which is ever used
- for any data type on the target machine you are compiling for.
- Doing this can often make copy operations more efficient, because
- the compiler can use whatever instructions copy the biggest chunks
- of memory when performing copies to or from the variables which
- have types that you have aligned this way.
-
- In the example above, if the size of each `short' is 2 bytes, then
- the size of the entire `struct S' type is 6 bytes. The smallest
- power of two which is greater than or equal to that is 8, so the
- compiler sets the alignment for the entire `struct S' type to 8
- bytes.
-
- Note that although you can ask the compiler to select a
- time-efficient alignment for a given type and then declare only
- individual stand-alone objects of that type, the compiler's
- ability to select a time-efficient alignment is primarily useful
- only when you plan to create arrays of variables having the
- relevant (efficiently aligned) type. If you declare or use arrays
- of variables of an efficiently-aligned type, then it is likely
- that your program will also be doing pointer arithmetic (or
- subscripting, which amounts to the same thing) on pointers to the
- relevant type, and the code that the compiler generates for these
- pointer arithmetic operations will often be more efficient for
- efficiently-aligned types than for other types.
-
- The `aligned' attribute can only increase the alignment; but you
- can decrease it by specifying `packed' as well. See below.
-
- Note that the effectiveness of `aligned' attributes may be limited
- by inherent limitations in your linker. On many systems, the
- linker is only able to arrange for variables to be aligned up to a
- certain maximum alignment. (For some linkers, the maximum
- supported alignment may be very very small.) If your linker is
- only able to align variables up to a maximum of 8 byte alignment,
- then specifying `aligned(16)' in an `__attribute__' will still
- only provide you with 8 byte alignment. See your linker
- documentation for further information.
-
-`packed'
- This attribute, attached to `struct' or `union' type definition,
- specifies that each member (other than zero-width bitfields) of
- the structure or union is placed to minimize the memory required.
- When attached to an `enum' definition, it indicates that the
- smallest integral type should be used.
-
- Specifying this attribute for `struct' and `union' types is
- equivalent to specifying the `packed' attribute on each of the
- structure or union members. Specifying the `-fshort-enums' flag
- on the line is equivalent to specifying the `packed' attribute on
- all `enum' definitions.
-
- In the following example `struct my_packed_struct''s members are
- packed closely together, but the internal layout of its `s' member
- is not packed--to do that, `struct my_unpacked_struct' would need
- to be packed too.
-
- struct my_unpacked_struct
- {
- char c;
- int i;
- };
-
- struct __attribute__ ((__packed__)) my_packed_struct
- {
- char c;
- int i;
- struct my_unpacked_struct s;
- };
-
- You may only specify this attribute on the definition of an `enum',
- `struct' or `union', not on a `typedef' which does not also define
- the enumerated type, structure or union.
-
-`transparent_union'
- This attribute, attached to a `union' type definition, indicates
- that any function parameter having that union type causes calls to
- that function to be treated in a special way.
-
- First, the argument corresponding to a transparent union type can
- be of any type in the union; no cast is required. Also, if the
- union contains a pointer type, the corresponding argument can be a
- null pointer constant or a void pointer expression; and if the
- union contains a void pointer type, the corresponding argument can
- be any pointer expression. If the union member type is a pointer,
- qualifiers like `const' on the referenced type must be respected,
- just as with normal pointer conversions.
-
- Second, the argument is passed to the function using the calling
- conventions of the first member of the transparent union, not the
- calling conventions of the union itself. All members of the union
- must have the same machine representation; this is necessary for
- this argument passing to work properly.
-
- Transparent unions are designed for library functions that have
- multiple interfaces for compatibility reasons. For example,
- suppose the `wait' function must accept either a value of type
- `int *' to comply with Posix, or a value of type `union wait *' to
- comply with the 4.1BSD interface. If `wait''s parameter were
- `void *', `wait' would accept both kinds of arguments, but it
- would also accept any other pointer type and this would make
- argument type checking less useful. Instead, `<sys/wait.h>' might
- define the interface as follows:
-
- typedef union __attribute__ ((__transparent_union__))
- {
- int *__ip;
- union wait *__up;
- } wait_status_ptr_t;
-
- pid_t wait (wait_status_ptr_t);
-
- This interface allows either `int *' or `union wait *' arguments
- to be passed, using the `int *' calling convention. The program
- can call `wait' with arguments of either type:
-
- int w1 () { int w; return wait (&w); }
- int w2 () { union wait w; return wait (&w); }
-
- With this interface, `wait''s implementation might look like this:
-
- pid_t wait (wait_status_ptr_t p)
- {
- return waitpid (-1, p.__ip, 0);
- }
-
-`unused'
- When attached to a type (including a `union' or a `struct'), this
- attribute means that variables of that type are meant to appear
- possibly unused. GCC will not produce a warning for any variables
- of that type, even if the variable appears to do nothing. This is
- often the case with lock or thread classes, which are usually
- defined and then not referenced, but contain constructors and
- destructors that have nontrivial bookkeeping functions.
-
-`deprecated'
-`deprecated (MSG)'
- The `deprecated' attribute results in a warning if the type is
- used anywhere in the source file. This is useful when identifying
- types that are expected to be removed in a future version of a
- program. If possible, the warning also includes the location of
- the declaration of the deprecated type, to enable users to easily
- find further information about why the type is deprecated, or what
- they should do instead. Note that the warnings only occur for
- uses and then only if the type is being applied to an identifier
- that itself is not being declared as deprecated.
-
- typedef int T1 __attribute__ ((deprecated));
- T1 x;
- typedef T1 T2;
- T2 y;
- typedef T1 T3 __attribute__ ((deprecated));
- T3 z __attribute__ ((deprecated));
-
- results in a warning on line 2 and 3 but not lines 4, 5, or 6. No
- warning is issued for line 4 because T2 is not explicitly
- deprecated. Line 5 has no warning because T3 is explicitly
- deprecated. Similarly for line 6. The optional msg argument,
- which must be a string, will be printed in the warning if present.
-
- The `deprecated' attribute can also be used for functions and
- variables (*note Function Attributes::, *note Variable
- Attributes::.)
-
-`may_alias'
- Accesses through pointers to types with this attribute are not
- subject to type-based alias analysis, but are instead assumed to
- be able to alias any other type of objects. In the context of
- 6.5/7 an lvalue expression dereferencing such a pointer is treated
- like having a character type. See `-fstrict-aliasing' for more
- information on aliasing issues. This extension exists to support
- some vector APIs, in which pointers to one vector type are
- permitted to alias pointers to a different vector type.
-
- Note that an object of a type with this attribute does not have any
- special semantics.
-
- Example of use:
-
- typedef short __attribute__((__may_alias__)) short_a;
-
- int
- main (void)
- {
- int a = 0x12345678;
- short_a *b = (short_a *) &a;
-
- b[1] = 0;
-
- if (a == 0x12345678)
- abort();
-
- exit(0);
- }
-
- If you replaced `short_a' with `short' in the variable
- declaration, the above program would abort when compiled with
- `-fstrict-aliasing', which is on by default at `-O2' or above in
- recent GCC versions.
-
-`visibility'
- In C++, attribute visibility (*note Function Attributes::) can
- also be applied to class, struct, union and enum types. Unlike
- other type attributes, the attribute must appear between the
- initial keyword and the name of the type; it cannot appear after
- the body of the type.
-
- Note that the type visibility is applied to vague linkage entities
- associated with the class (vtable, typeinfo node, etc.). In
- particular, if a class is thrown as an exception in one shared
- object and caught in another, the class must have default
- visibility. Otherwise the two shared objects will be unable to
- use the same typeinfo node and exception handling will break.
-
-
-6.37.1 ARM Type Attributes
---------------------------
-
-On those ARM targets that support `dllimport' (such as Symbian OS), you
-can use the `notshared' attribute to indicate that the virtual table
-and other similar data for a class should not be exported from a DLL.
-For example:
-
- class __declspec(notshared) C {
- public:
- __declspec(dllimport) C();
- virtual void f();
- }
-
- __declspec(dllexport)
- C::C() {}
-
- In this code, `C::C' is exported from the current DLL, but the virtual
-table for `C' is not exported. (You can use `__attribute__' instead of
-`__declspec' if you prefer, but most Symbian OS code uses `__declspec'.)
-
-6.37.2 MeP Type Attributes
---------------------------
-
-Many of the MeP variable attributes may be applied to types as well.
-Specifically, the `based', `tiny', `near', and `far' attributes may be
-applied to either. The `io' and `cb' attributes may not be applied to
-types.
-
-6.37.3 i386 Type Attributes
----------------------------
-
-Two attributes are currently defined for i386 configurations:
-`ms_struct' and `gcc_struct'.
-
-`ms_struct'
-`gcc_struct'
- If `packed' is used on a structure, or if bit-fields are used it
- may be that the Microsoft ABI packs them differently than GCC
- would normally pack them. Particularly when moving packed data
- between functions compiled with GCC and the native Microsoft
- compiler (either via function call or as data in a file), it may
- be necessary to access either format.
-
- Currently `-m[no-]ms-bitfields' is provided for the Microsoft
- Windows X86 compilers to match the native Microsoft compiler.
-
- To specify multiple attributes, separate them by commas within the
-double parentheses: for example, `__attribute__ ((aligned (16),
-packed))'.
-
-6.37.4 PowerPC Type Attributes
-------------------------------
-
-Three attributes currently are defined for PowerPC configurations:
-`altivec', `ms_struct' and `gcc_struct'.
-
- For full documentation of the `ms_struct' and `gcc_struct' attributes
-please see the documentation in *note i386 Type Attributes::.
-
- The `altivec' attribute allows one to declare AltiVec vector data
-types supported by the AltiVec Programming Interface Manual. The
-attribute requires an argument to specify one of three vector types:
-`vector__', `pixel__' (always followed by unsigned short), and `bool__'
-(always followed by unsigned).
-
- __attribute__((altivec(vector__)))
- __attribute__((altivec(pixel__))) unsigned short
- __attribute__((altivec(bool__))) unsigned
-
- These attributes mainly are intended to support the `__vector',
-`__pixel', and `__bool' AltiVec keywords.
-
-6.37.5 SPU Type Attributes
---------------------------
-
-The SPU supports the `spu_vector' attribute for types. This attribute
-allows one to declare vector data types supported by the
-Sony/Toshiba/IBM SPU Language Extensions Specification. It is intended
-to support the `__vector' keyword.
-
-
-File: gcc.info, Node: Alignment, Next: Inline, Prev: Type Attributes, Up: C Extensions
-
-6.38 Inquiring on Alignment of Types or Variables
-=================================================
-
-The keyword `__alignof__' allows you to inquire about how an object is
-aligned, or the minimum alignment usually required by a type. Its
-syntax is just like `sizeof'.
-
- For example, if the target machine requires a `double' value to be
-aligned on an 8-byte boundary, then `__alignof__ (double)' is 8. This
-is true on many RISC machines. On more traditional machine designs,
-`__alignof__ (double)' is 4 or even 2.
-
- Some machines never actually require alignment; they allow reference
-to any data type even at an odd address. For these machines,
-`__alignof__' reports the smallest alignment that GCC will give the
-data type, usually as mandated by the target ABI.
-
- If the operand of `__alignof__' is an lvalue rather than a type, its
-value is the required alignment for its type, taking into account any
-minimum alignment specified with GCC's `__attribute__' extension (*note
-Variable Attributes::). For example, after this declaration:
-
- struct foo { int x; char y; } foo1;
-
-the value of `__alignof__ (foo1.y)' is 1, even though its actual
-alignment is probably 2 or 4, the same as `__alignof__ (int)'.
-
- It is an error to ask for the alignment of an incomplete type.
-
-
-File: gcc.info, Node: Inline, Next: Volatiles, Prev: Alignment, Up: C Extensions
-
-6.39 An Inline Function is As Fast As a Macro
-=============================================
-
-By declaring a function inline, you can direct GCC to make calls to
-that function faster. One way GCC can achieve this is to integrate
-that function's code into the code for its callers. This makes
-execution faster by eliminating the function-call overhead; in
-addition, if any of the actual argument values are constant, their
-known values may permit simplifications at compile time so that not all
-of the inline function's code needs to be included. The effect on code
-size is less predictable; object code may be larger or smaller with
-function inlining, depending on the particular case. You can also
-direct GCC to try to integrate all "simple enough" functions into their
-callers with the option `-finline-functions'.
-
- GCC implements three different semantics of declaring a function
-inline. One is available with `-std=gnu89' or `-fgnu89-inline' or when
-`gnu_inline' attribute is present on all inline declarations, another
-when `-std=c99', `-std=c1x', `-std=gnu99' or `-std=gnu1x' (without
-`-fgnu89-inline'), and the third is used when compiling C++.
-
- To declare a function inline, use the `inline' keyword in its
-declaration, like this:
-
- static inline int
- inc (int *a)
- {
- return (*a)++;
- }
-
- If you are writing a header file to be included in ISO C90 programs,
-write `__inline__' instead of `inline'. *Note Alternate Keywords::.
-
- The three types of inlining behave similarly in two important cases:
-when the `inline' keyword is used on a `static' function, like the
-example above, and when a function is first declared without using the
-`inline' keyword and then is defined with `inline', like this:
-
- extern int inc (int *a);
- inline int
- inc (int *a)
- {
- return (*a)++;
- }
-
- In both of these common cases, the program behaves the same as if you
-had not used the `inline' keyword, except for its speed.
-
- When a function is both inline and `static', if all calls to the
-function are integrated into the caller, and the function's address is
-never used, then the function's own assembler code is never referenced.
-In this case, GCC does not actually output assembler code for the
-function, unless you specify the option `-fkeep-inline-functions'.
-Some calls cannot be integrated for various reasons (in particular,
-calls that precede the function's definition cannot be integrated, and
-neither can recursive calls within the definition). If there is a
-nonintegrated call, then the function is compiled to assembler code as
-usual. The function must also be compiled as usual if the program
-refers to its address, because that can't be inlined.
-
- Note that certain usages in a function definition can make it
-unsuitable for inline substitution. Among these usages are: use of
-varargs, use of alloca, use of variable sized data types (*note
-Variable Length::), use of computed goto (*note Labels as Values::),
-use of nonlocal goto, and nested functions (*note Nested Functions::).
-Using `-Winline' will warn when a function marked `inline' could not be
-substituted, and will give the reason for the failure.
-
- As required by ISO C++, GCC considers member functions defined within
-the body of a class to be marked inline even if they are not explicitly
-declared with the `inline' keyword. You can override this with
-`-fno-default-inline'; *note Options Controlling C++ Dialect: C++
-Dialect Options.
-
- GCC does not inline any functions when not optimizing unless you
-specify the `always_inline' attribute for the function, like this:
-
- /* Prototype. */
- inline void foo (const char) __attribute__((always_inline));
-
- The remainder of this section is specific to GNU C90 inlining.
-
- When an inline function is not `static', then the compiler must assume
-that there may be calls from other source files; since a global symbol
-can be defined only once in any program, the function must not be
-defined in the other source files, so the calls therein cannot be
-integrated. Therefore, a non-`static' inline function is always
-compiled on its own in the usual fashion.
-
- If you specify both `inline' and `extern' in the function definition,
-then the definition is used only for inlining. In no case is the
-function compiled on its own, not even if you refer to its address
-explicitly. Such an address becomes an external reference, as if you
-had only declared the function, and had not defined it.
-
- This combination of `inline' and `extern' has almost the effect of a
-macro. The way to use it is to put a function definition in a header
-file with these keywords, and put another copy of the definition
-(lacking `inline' and `extern') in a library file. The definition in
-the header file will cause most calls to the function to be inlined.
-If any uses of the function remain, they will refer to the single copy
-in the library.
-
-
-File: gcc.info, Node: Volatiles, Next: Extended Asm, Prev: Inline, Up: C Extensions
-
-6.40 When is a Volatile Object Accessed?
-========================================
-
-C has the concept of volatile objects. These are normally accessed by
-pointers and used for accessing hardware or inter-thread communication.
-The standard encourages compilers to refrain from optimizations
-concerning accesses to volatile objects, but leaves it implementation
-defined as to what constitutes a volatile access. The minimum
-requirement is that at a sequence point all previous accesses to
-volatile objects have stabilized and no subsequent accesses have
-occurred. Thus an implementation is free to reorder and combine
-volatile accesses which occur between sequence points, but cannot do so
-for accesses across a sequence point. The use of volatile does not
-allow you to violate the restriction on updating objects multiple times
-between two sequence points.
-
- Accesses to non-volatile objects are not ordered with respect to
-volatile accesses. You cannot use a volatile object as a memory
-barrier to order a sequence of writes to non-volatile memory. For
-instance:
-
- int *ptr = SOMETHING;
- volatile int vobj;
- *ptr = SOMETHING;
- vobj = 1;
-
- Unless *PTR and VOBJ can be aliased, it is not guaranteed that the
-write to *PTR will have occurred by the time the update of VOBJ has
-happened. If you need this guarantee, you must use a stronger memory
-barrier such as:
-
- int *ptr = SOMETHING;
- volatile int vobj;
- *ptr = SOMETHING;
- asm volatile ("" : : : "memory");
- vobj = 1;
-
- A scalar volatile object is read when it is accessed in a void context:
-
- volatile int *src = SOMEVALUE;
- *src;
-
- Such expressions are rvalues, and GCC implements this as a read of the
-volatile object being pointed to.
-
- Assignments are also expressions and have an rvalue. However when
-assigning to a scalar volatile, the volatile object is not reread,
-regardless of whether the assignment expression's rvalue is used or
-not. If the assignment's rvalue is used, the value is that assigned to
-the volatile object. For instance, there is no read of VOBJ in all the
-following cases:
-
- int obj;
- volatile int vobj;
- vobj = SOMETHING;
- obj = vobj = SOMETHING;
- obj ? vobj = ONETHING : vobj = ANOTHERTHING;
- obj = (SOMETHING, vobj = ANOTHERTHING);
-
- If you need to read the volatile object after an assignment has
-occurred, you must use a separate expression with an intervening
-sequence point.
-
- As bitfields are not individually addressable, volatile bitfields may
-be implicitly read when written to, or when adjacent bitfields are
-accessed. Bitfield operations may be optimized such that adjacent
-bitfields are only partially accessed, if they straddle a storage unit
-boundary. For these reasons it is unwise to use volatile bitfields to
-access hardware.
-
-
-File: gcc.info, Node: Extended Asm, Next: Constraints, Prev: Volatiles, Up: C Extensions
-
-6.41 Assembler Instructions with C Expression Operands
-======================================================
-
-In an assembler instruction using `asm', you can specify the operands
-of the instruction using C expressions. This means you need not guess
-which registers or memory locations will contain the data you want to
-use.
-
- You must specify an assembler instruction template much like what
-appears in a machine description, plus an operand constraint string for
-each operand.
-
- For example, here is how to use the 68881's `fsinx' instruction:
-
- asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
-
-Here `angle' is the C expression for the input operand while `result'
-is that of the output operand. Each has `"f"' as its operand
-constraint, saying that a floating point register is required. The `='
-in `=f' indicates that the operand is an output; all output operands'
-constraints must use `='. The constraints use the same language used
-in the machine description (*note Constraints::).
-
- Each operand is described by an operand-constraint string followed by
-the C expression in parentheses. A colon separates the assembler
-template from the first output operand and another separates the last
-output operand from the first input, if any. Commas separate the
-operands within each group. The total number of operands is currently
-limited to 30; this limitation may be lifted in some future version of
-GCC.
-
- If there are no output operands but there are input operands, you must
-place two consecutive colons surrounding the place where the output
-operands would go.
-
- As of GCC version 3.1, it is also possible to specify input and output
-operands using symbolic names which can be referenced within the
-assembler code. These names are specified inside square brackets
-preceding the constraint string, and can be referenced inside the
-assembler code using `%[NAME]' instead of a percentage sign followed by
-the operand number. Using named operands the above example could look
-like:
-
- asm ("fsinx %[angle],%[output]"
- : [output] "=f" (result)
- : [angle] "f" (angle));
-
-Note that the symbolic operand names have no relation whatsoever to
-other C identifiers. You may use any name you like, even those of
-existing C symbols, but you must ensure that no two operands within the
-same assembler construct use the same symbolic name.
-
- Output operand expressions must be lvalues; the compiler can check
-this. The input operands need not be lvalues. The compiler cannot
-check whether the operands have data types that are reasonable for the
-instruction being executed. It does not parse the assembler instruction
-template and does not know what it means or even whether it is valid
-assembler input. The extended `asm' feature is most often used for
-machine instructions the compiler itself does not know exist. If the
-output expression cannot be directly addressed (for example, it is a
-bit-field), your constraint must allow a register. In that case, GCC
-will use the register as the output of the `asm', and then store that
-register into the output.
-
- The ordinary output operands must be write-only; GCC will assume that
-the values in these operands before the instruction are dead and need
-not be generated. Extended asm supports input-output or read-write
-operands. Use the constraint character `+' to indicate such an operand
-and list it with the output operands. You should only use read-write
-operands when the constraints for the operand (or the operand in which
-only some of the bits are to be changed) allow a register.
-
- You may, as an alternative, logically split its function into two
-separate operands, one input operand and one write-only output operand.
-The connection between them is expressed by constraints which say they
-need to be in the same location when the instruction executes. You can
-use the same C expression for both operands, or different expressions.
-For example, here we write the (fictitious) `combine' instruction with
-`bar' as its read-only source operand and `foo' as its read-write
-destination:
-
- asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar));
-
-The constraint `"0"' for operand 1 says that it must occupy the same
-location as operand 0. A number in constraint is allowed only in an
-input operand and it must refer to an output operand.
-
- Only a number in the constraint can guarantee that one operand will be
-in the same place as another. The mere fact that `foo' is the value of
-both operands is not enough to guarantee that they will be in the same
-place in the generated assembler code. The following would not work
-reliably:
-
- asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar));
-
- Various optimizations or reloading could cause operands 0 and 1 to be
-in different registers; GCC knows no reason not to do so. For example,
-the compiler might find a copy of the value of `foo' in one register and
-use it for operand 1, but generate the output operand 0 in a different
-register (copying it afterward to `foo''s own address). Of course,
-since the register for operand 1 is not even mentioned in the assembler
-code, the result will not work, but GCC can't tell that.
-
- As of GCC version 3.1, one may write `[NAME]' instead of the operand
-number for a matching constraint. For example:
-
- asm ("cmoveq %1,%2,%[result]"
- : [result] "=r"(result)
- : "r" (test), "r"(new), "[result]"(old));
-
- Sometimes you need to make an `asm' operand be a specific register,
-but there's no matching constraint letter for that register _by
-itself_. To force the operand into that register, use a local variable
-for the operand and specify the register in the variable declaration.
-*Note Explicit Reg Vars::. Then for the `asm' operand, use any
-register constraint letter that matches the register:
-
- register int *p1 asm ("r0") = ...;
- register int *p2 asm ("r1") = ...;
- register int *result asm ("r0");
- asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
-
- In the above example, beware that a register that is call-clobbered by
-the target ABI will be overwritten by any function call in the
-assignment, including library calls for arithmetic operators. Also a
-register may be clobbered when generating some operations, like
-variable shift, memory copy or memory move on x86. Assuming it is a
-call-clobbered register, this may happen to `r0' above by the
-assignment to `p2'. If you have to use such a register, use temporary
-variables for expressions between the register assignment and use:
-
- int t1 = ...;
- register int *p1 asm ("r0") = ...;
- register int *p2 asm ("r1") = t1;
- register int *result asm ("r0");
- asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
-
- Some instructions clobber specific hard registers. To describe this,
-write a third colon after the input operands, followed by the names of
-the clobbered hard registers (given as strings). Here is a realistic
-example for the VAX:
-
- asm volatile ("movc3 %0,%1,%2"
- : /* no outputs */
- : "g" (from), "g" (to), "g" (count)
- : "r0", "r1", "r2", "r3", "r4", "r5");
-
- You may not write a clobber description in a way that overlaps with an
-input or output operand. For example, you may not have an operand
-describing a register class with one member if you mention that register
-in the clobber list. Variables declared to live in specific registers
-(*note Explicit Reg Vars::), and used as asm input or output operands
-must have no part mentioned in the clobber description. There is no
-way for you to specify that an input operand is modified without also
-specifying it as an output operand. Note that if all the output
-operands you specify are for this purpose (and hence unused), you will
-then also need to specify `volatile' for the `asm' construct, as
-described below, to prevent GCC from deleting the `asm' statement as
-unused.
-
- If you refer to a particular hardware register from the assembler code,
-you will probably have to list the register after the third colon to
-tell the compiler the register's value is modified. In some assemblers,
-the register names begin with `%'; to produce one `%' in the assembler
-code, you must write `%%' in the input.
-
- If your assembler instruction can alter the condition code register,
-add `cc' to the list of clobbered registers. GCC on some machines
-represents the condition codes as a specific hardware register; `cc'
-serves to name this register. On other machines, the condition code is
-handled differently, and specifying `cc' has no effect. But it is
-valid no matter what the machine.
-
- If your assembler instructions access memory in an unpredictable
-fashion, add `memory' to the list of clobbered registers. This will
-cause GCC to not keep memory values cached in registers across the
-assembler instruction and not optimize stores or loads to that memory.
-You will also want to add the `volatile' keyword if the memory affected
-is not listed in the inputs or outputs of the `asm', as the `memory'
-clobber does not count as a side-effect of the `asm'. If you know how
-large the accessed memory is, you can add it as input or output but if
-this is not known, you should add `memory'. As an example, if you
-access ten bytes of a string, you can use a memory input like:
-
- {"m"( ({ struct { char x[10]; } *p = (void *)ptr ; *p; }) )}.
-
- Note that in the following example the memory input is necessary,
-otherwise GCC might optimize the store to `x' away:
- int foo ()
- {
- int x = 42;
- int *y = &x;
- int result;
- asm ("magic stuff accessing an 'int' pointed to by '%1'"
- "=&d" (r) : "a" (y), "m" (*y));
- return result;
- }
-
- You can put multiple assembler instructions together in a single `asm'
-template, separated by the characters normally used in assembly code
-for the system. A combination that works in most places is a newline
-to break the line, plus a tab character to move to the instruction field
-(written as `\n\t'). Sometimes semicolons can be used, if the
-assembler allows semicolons as a line-breaking character. Note that
-some assembler dialects use semicolons to start a comment. The input
-operands are guaranteed not to use any of the clobbered registers, and
-neither will the output operands' addresses, so you can read and write
-the clobbered registers as many times as you like. Here is an example
-of multiple instructions in a template; it assumes the subroutine
-`_foo' accepts arguments in registers 9 and 10:
-
- asm ("movl %0,r9\n\tmovl %1,r10\n\tcall _foo"
- : /* no outputs */
- : "g" (from), "g" (to)
- : "r9", "r10");
-
- Unless an output operand has the `&' constraint modifier, GCC may
-allocate it in the same register as an unrelated input operand, on the
-assumption the inputs are consumed before the outputs are produced.
-This assumption may be false if the assembler code actually consists of
-more than one instruction. In such a case, use `&' for each output
-operand that may not overlap an input. *Note Modifiers::.
-
- If you want to test the condition code produced by an assembler
-instruction, you must include a branch and a label in the `asm'
-construct, as follows:
-
- asm ("clr %0\n\tfrob %1\n\tbeq 0f\n\tmov #1,%0\n0:"
- : "g" (result)
- : "g" (input));
-
-This assumes your assembler supports local labels, as the GNU assembler
-and most Unix assemblers do.
-
- Speaking of labels, jumps from one `asm' to another are not supported.
-The compiler's optimizers do not know about these jumps, and therefore
-they cannot take account of them when deciding how to optimize. *Note
-Extended asm with goto::.
-
- Usually the most convenient way to use these `asm' instructions is to
-encapsulate them in macros that look like functions. For example,
-
- #define sin(x) \
- ({ double __value, __arg = (x); \
- asm ("fsinx %1,%0": "=f" (__value): "f" (__arg)); \
- __value; })
-
-Here the variable `__arg' is used to make sure that the instruction
-operates on a proper `double' value, and to accept only those arguments
-`x' which can convert automatically to a `double'.
-
- Another way to make sure the instruction operates on the correct data
-type is to use a cast in the `asm'. This is different from using a
-variable `__arg' in that it converts more different types. For
-example, if the desired type were `int', casting the argument to `int'
-would accept a pointer with no complaint, while assigning the argument
-to an `int' variable named `__arg' would warn about using a pointer
-unless the caller explicitly casts it.
-
- If an `asm' has output operands, GCC assumes for optimization purposes
-the instruction has no side effects except to change the output
-operands. This does not mean instructions with a side effect cannot be
-used, but you must be careful, because the compiler may eliminate them
-if the output operands aren't used, or move them out of loops, or
-replace two with one if they constitute a common subexpression. Also,
-if your instruction does have a side effect on a variable that otherwise
-appears not to change, the old value of the variable may be reused later
-if it happens to be found in a register.
-
- You can prevent an `asm' instruction from being deleted by writing the
-keyword `volatile' after the `asm'. For example:
-
- #define get_and_set_priority(new) \
- ({ int __old; \
- asm volatile ("get_and_set_priority %0, %1" \
- : "=g" (__old) : "g" (new)); \
- __old; })
-
-The `volatile' keyword indicates that the instruction has important
-side-effects. GCC will not delete a volatile `asm' if it is reachable.
-(The instruction can still be deleted if GCC can prove that
-control-flow will never reach the location of the instruction.) Note
-that even a volatile `asm' instruction can be moved relative to other
-code, including across jump instructions. For example, on many targets
-there is a system register which can be set to control the rounding
-mode of floating point operations. You might try setting it with a
-volatile `asm', like this PowerPC example:
-
- asm volatile("mtfsf 255,%0" : : "f" (fpenv));
- sum = x + y;
-
-This will not work reliably, as the compiler may move the addition back
-before the volatile `asm'. To make it work you need to add an
-artificial dependency to the `asm' referencing a variable in the code
-you don't want moved, for example:
-
- asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
- sum = x + y;
-
- Similarly, you can't expect a sequence of volatile `asm' instructions
-to remain perfectly consecutive. If you want consecutive output, use a
-single `asm'. Also, GCC will perform some optimizations across a
-volatile `asm' instruction; GCC does not "forget everything" when it
-encounters a volatile `asm' instruction the way some other compilers do.
-
- An `asm' instruction without any output operands will be treated
-identically to a volatile `asm' instruction.
-
- It is a natural idea to look for a way to give access to the condition
-code left by the assembler instruction. However, when we attempted to
-implement this, we found no way to make it work reliably. The problem
-is that output operands might need reloading, which would result in
-additional following "store" instructions. On most machines, these
-instructions would alter the condition code before there was time to
-test it. This problem doesn't arise for ordinary "test" and "compare"
-instructions because they don't have any output operands.
-
- For reasons similar to those described above, it is not possible to
-give an assembler instruction access to the condition code left by
-previous instructions.
-
- As of GCC version 4.5, `asm goto' may be used to have the assembly
-jump to one or more C labels. In this form, a fifth section after the
-clobber list contains a list of all C labels to which the assembly may
-jump. Each label operand is implicitly self-named. The `asm' is also
-assumed to fall through to the next statement.
-
- This form of `asm' is restricted to not have outputs. This is due to
-a internal restriction in the compiler that control transfer
-instructions cannot have outputs. This restriction on `asm goto' may
-be lifted in some future version of the compiler. In the mean time,
-`asm goto' may include a memory clobber, and so leave outputs in memory.
-
- int frob(int x)
- {
- int y;
- asm goto ("frob %%r5, %1; jc %l[error]; mov (%2), %%r5"
- : : "r"(x), "r"(&y) : "r5", "memory" : error);
- return y;
- error:
- return -1;
- }
-
- In this (inefficient) example, the `frob' instruction sets the carry
-bit to indicate an error. The `jc' instruction detects this and
-branches to the `error' label. Finally, the output of the `frob'
-instruction (`%r5') is stored into the memory for variable `y', which
-is later read by the `return' statement.
-
- void doit(void)
- {
- int i = 0;
- asm goto ("mfsr %%r1, 123; jmp %%r1;"
- ".pushsection doit_table;"
- ".long %l0, %l1, %l2, %l3;"
- ".popsection"
- : : : "r1" : label1, label2, label3, label4);
- __builtin_unreachable ();
-
- label1:
- f1();
- return;
- label2:
- f2();
- return;
- label3:
- i = 1;
- label4:
- f3(i);
- }
-
- In this (also inefficient) example, the `mfsr' instruction reads an
-address from some out-of-band machine register, and the following `jmp'
-instruction branches to that address. The address read by the `mfsr'
-instruction is assumed to have been previously set via some
-application-specific mechanism to be one of the four values stored in
-the `doit_table' section. Finally, the `asm' is followed by a call to
-`__builtin_unreachable' to indicate that the `asm' does not in fact
-fall through.
-
- #define TRACE1(NUM) \
- do { \
- asm goto ("0: nop;" \
- ".pushsection trace_table;" \
- ".long 0b, %l0;" \
- ".popsection" \
- : : : : trace#NUM); \
- if (0) { trace#NUM: trace(); } \
- } while (0)
- #define TRACE TRACE1(__COUNTER__)
-
- In this example (which in fact inspired the `asm goto' feature) we
-want on rare occasions to call the `trace' function; on other occasions
-we'd like to keep the overhead to the absolute minimum. The normal
-code path consists of a single `nop' instruction. However, we record
-the address of this `nop' together with the address of a label that
-calls the `trace' function. This allows the `nop' instruction to be
-patched at runtime to be an unconditional branch to the stored label.
-It is assumed that an optimizing compiler will move the labeled block
-out of line, to optimize the fall through path from the `asm'.
-
- If you are writing a header file that should be includable in ISO C
-programs, write `__asm__' instead of `asm'. *Note Alternate Keywords::.
-
-6.41.1 Size of an `asm'
------------------------
-
-Some targets require that GCC track the size of each instruction used in
-order to generate correct code. Because the final length of an `asm'
-is only known by the assembler, GCC must make an estimate as to how big
-it will be. The estimate is formed by counting the number of
-statements in the pattern of the `asm' and multiplying that by the
-length of the longest instruction on that processor. Statements in the
-`asm' are identified by newline characters and whatever statement
-separator characters are supported by the assembler; on most processors
-this is the ``;'' character.
-
- Normally, GCC's estimate is perfectly adequate to ensure that correct
-code is generated, but it is possible to confuse the compiler if you use
-pseudo instructions or assembler macros that expand into multiple real
-instructions or if you use assembler directives that expand to more
-space in the object file than would be needed for a single instruction.
-If this happens then the assembler will produce a diagnostic saying that
-a label is unreachable.
-
-6.41.2 i386 floating point asm operands
----------------------------------------
-
-There are several rules on the usage of stack-like regs in asm_operands
-insns. These rules apply only to the operands that are stack-like regs:
-
- 1. Given a set of input regs that die in an asm_operands, it is
- necessary to know which are implicitly popped by the asm, and
- which must be explicitly popped by gcc.
-
- An input reg that is implicitly popped by the asm must be
- explicitly clobbered, unless it is constrained to match an output
- operand.
-
- 2. For any input reg that is implicitly popped by an asm, it is
- necessary to know how to adjust the stack to compensate for the
- pop. If any non-popped input is closer to the top of the
- reg-stack than the implicitly popped reg, it would not be possible
- to know what the stack looked like--it's not clear how the rest of
- the stack "slides up".
-
- All implicitly popped input regs must be closer to the top of the
- reg-stack than any input that is not implicitly popped.
-
- It is possible that if an input dies in an insn, reload might use
- the input reg for an output reload. Consider this example:
-
- asm ("foo" : "=t" (a) : "f" (b));
-
- This asm says that input B is not popped by the asm, and that the
- asm pushes a result onto the reg-stack, i.e., the stack is one
- deeper after the asm than it was before. But, it is possible that
- reload will think that it can use the same reg for both the input
- and the output, if input B dies in this insn.
-
- If any input operand uses the `f' constraint, all output reg
- constraints must use the `&' earlyclobber.
-
- The asm above would be written as
-
- asm ("foo" : "=&t" (a) : "f" (b));
-
- 3. Some operands need to be in particular places on the stack. All
- output operands fall in this category--there is no other way to
- know which regs the outputs appear in unless the user indicates
- this in the constraints.
-
- Output operands must specifically indicate which reg an output
- appears in after an asm. `=f' is not allowed: the operand
- constraints must select a class with a single reg.
-
- 4. Output operands may not be "inserted" between existing stack regs.
- Since no 387 opcode uses a read/write operand, all output operands
- are dead before the asm_operands, and are pushed by the
- asm_operands. It makes no sense to push anywhere but the top of
- the reg-stack.
-
- Output operands must start at the top of the reg-stack: output
- operands may not "skip" a reg.
-
- 5. Some asm statements may need extra stack space for internal
- calculations. This can be guaranteed by clobbering stack registers
- unrelated to the inputs and outputs.
-
-
- Here are a couple of reasonable asms to want to write. This asm takes
-one input, which is internally popped, and produces two outputs.
-
- asm ("fsincos" : "=t" (cos), "=u" (sin) : "0" (inp));
-
- This asm takes two inputs, which are popped by the `fyl2xp1' opcode,
-and replaces them with one output. The user must code the `st(1)'
-clobber for reg-stack.c to know that `fyl2xp1' pops both inputs.
-
- asm ("fyl2xp1" : "=t" (result) : "0" (x), "u" (y) : "st(1)");
-
-
-File: gcc.info, Node: Constraints, Next: Asm Labels, Prev: Extended Asm, Up: C Extensions
-
-6.42 Constraints for `asm' Operands
-===================================
-
-Here are specific details on what constraint letters you can use with
-`asm' operands. Constraints can say whether an operand may be in a
-register, and which kinds of register; whether the operand can be a
-memory reference, and which kinds of address; whether the operand may
-be an immediate constant, and which possible values it may have.
-Constraints can also require two operands to match. Side-effects
-aren't allowed in operands of inline `asm', unless `<' or `>'
-constraints are used, because there is no guarantee that the
-side-effects will happen exactly once in an instruction that can update
-the addressing register.
-
-* Menu:
-
-* Simple Constraints:: Basic use of constraints.
-* Multi-Alternative:: When an insn has two alternative constraint-patterns.
-* Modifiers:: More precise control over effects of constraints.
-* Machine Constraints:: Special constraints for some particular machines.
-
-
-File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints
-
-6.42.1 Simple Constraints
--------------------------
-
-The simplest kind of constraint is a string full of letters, each of
-which describes one kind of operand that is permitted. Here are the
-letters that are allowed:
-
-whitespace
- Whitespace characters are ignored and can be inserted at any
- position except the first. This enables each alternative for
- different operands to be visually aligned in the machine
- description even if they have different number of constraints and
- modifiers.
-
-`m'
- A memory operand is allowed, with any kind of address that the
- machine supports in general. Note that the letter used for the
- general memory constraint can be re-defined by a back end using
- the `TARGET_MEM_CONSTRAINT' macro.
-
-`o'
- A memory operand is allowed, but only if the address is
- "offsettable". This means that adding a small integer (actually,
- the width in bytes of the operand, as determined by its machine
- mode) may be added to the address and the result is also a valid
- memory address.
-
- For example, an address which is constant is offsettable; so is an
- address that is the sum of a register and a constant (as long as a
- slightly larger constant is also within the range of
- address-offsets supported by the machine); but an autoincrement or
- autodecrement address is not offsettable. More complicated
- indirect/indexed addresses may or may not be offsettable depending
- on the other addressing modes that the machine supports.
-
- Note that in an output operand which can be matched by another
- operand, the constraint letter `o' is valid only when accompanied
- by both `<' (if the target machine has predecrement addressing)
- and `>' (if the target machine has preincrement addressing).
-
-`V'
- A memory operand that is not offsettable. In other words,
- anything that would fit the `m' constraint but not the `o'
- constraint.
-
-`<'
- A memory operand with autodecrement addressing (either
- predecrement or postdecrement) is allowed. In inline `asm' this
- constraint is only allowed if the operand is used exactly once in
- an instruction that can handle the side-effects. Not using an
- operand with `<' in constraint string in the inline `asm' pattern
- at all or using it in multiple instructions isn't valid, because
- the side-effects wouldn't be performed or would be performed more
- than once. Furthermore, on some targets the operand with `<' in
- constraint string must be accompanied by special instruction
- suffixes like `%U0' instruction suffix on PowerPC or `%P0' on
- IA-64.
-
-`>'
- A memory operand with autoincrement addressing (either
- preincrement or postincrement) is allowed. In inline `asm' the
- same restrictions as for `<' apply.
-
-`r'
- A register operand is allowed provided that it is in a general
- register.
-
-`i'
- An immediate integer operand (one with constant value) is allowed.
- This includes symbolic constants whose values will be known only at
- assembly time or later.
-
-`n'
- An immediate integer operand with a known numeric value is allowed.
- Many systems cannot support assembly-time constants for operands
- less than a word wide. Constraints for these operands should use
- `n' rather than `i'.
-
-`I', `J', `K', ... `P'
- Other letters in the range `I' through `P' may be defined in a
- machine-dependent fashion to permit immediate integer operands with
- explicit integer values in specified ranges. For example, on the
- 68000, `I' is defined to stand for the range of values 1 to 8.
- This is the range permitted as a shift count in the shift
- instructions.
-
-`E'
- An immediate floating operand (expression code `const_double') is
- allowed, but only if the target floating point format is the same
- as that of the host machine (on which the compiler is running).
-
-`F'
- An immediate floating operand (expression code `const_double' or
- `const_vector') is allowed.
-
-`G', `H'
- `G' and `H' may be defined in a machine-dependent fashion to
- permit immediate floating operands in particular ranges of values.
-
-`s'
- An immediate integer operand whose value is not an explicit
- integer is allowed.
-
- This might appear strange; if an insn allows a constant operand
- with a value not known at compile time, it certainly must allow
- any known value. So why use `s' instead of `i'? Sometimes it
- allows better code to be generated.
-
- For example, on the 68000 in a fullword instruction it is possible
- to use an immediate operand; but if the immediate value is between
- -128 and 127, better code results from loading the value into a
- register and using the register. This is because the load into
- the register can be done with a `moveq' instruction. We arrange
- for this to happen by defining the letter `K' to mean "any integer
- outside the range -128 to 127", and then specifying `Ks' in the
- operand constraints.
-
-`g'
- Any register, memory or immediate integer operand is allowed,
- except for registers that are not general registers.
-
-`X'
- Any operand whatsoever is allowed.
-
-`0', `1', `2', ... `9'
- An operand that matches the specified operand number is allowed.
- If a digit is used together with letters within the same
- alternative, the digit should come last.
-
- This number is allowed to be more than a single digit. If multiple
- digits are encountered consecutively, they are interpreted as a
- single decimal integer. There is scant chance for ambiguity,
- since to-date it has never been desirable that `10' be interpreted
- as matching either operand 1 _or_ operand 0. Should this be
- desired, one can use multiple alternatives instead.
-
- This is called a "matching constraint" and what it really means is
- that the assembler has only a single operand that fills two roles
- which `asm' distinguishes. For example, an add instruction uses
- two input operands and an output operand, but on most CISC
- machines an add instruction really has only two operands, one of
- them an input-output operand:
-
- addl #35,r12
-
- Matching constraints are used in these circumstances. More
- precisely, the two operands that match must include one input-only
- operand and one output-only operand. Moreover, the digit must be a
- smaller number than the number of the operand that uses it in the
- constraint.
-
-`p'
- An operand that is a valid memory address is allowed. This is for
- "load address" and "push address" instructions.
-
- `p' in the constraint must be accompanied by `address_operand' as
- the predicate in the `match_operand'. This predicate interprets
- the mode specified in the `match_operand' as the mode of the memory
- reference for which the address would be valid.
-
-OTHER-LETTERS
- Other letters can be defined in machine-dependent fashion to stand
- for particular classes of registers or other arbitrary operand
- types. `d', `a' and `f' are defined on the 68000/68020 to stand
- for data, address and floating point registers.
-
-
-File: gcc.info, Node: Multi-Alternative, Next: Modifiers, Prev: Simple Constraints, Up: Constraints
-
-6.42.2 Multiple Alternative Constraints
----------------------------------------
-
-Sometimes a single instruction has multiple alternative sets of possible
-operands. For example, on the 68000, a logical-or instruction can
-combine register or an immediate value into memory, or it can combine
-any kind of operand into a register; but it cannot combine one memory
-location into another.
-
- These constraints are represented as multiple alternatives. An
-alternative can be described by a series of letters for each operand.
-The overall constraint for an operand is made from the letters for this
-operand from the first alternative, a comma, the letters for this
-operand from the second alternative, a comma, and so on until the last
-alternative.
-
- If all the operands fit any one alternative, the instruction is valid.
-Otherwise, for each alternative, the compiler counts how many
-instructions must be added to copy the operands so that that
-alternative applies. The alternative requiring the least copying is
-chosen. If two alternatives need the same amount of copying, the one
-that comes first is chosen. These choices can be altered with the `?'
-and `!' characters:
-
-`?'
- Disparage slightly the alternative that the `?' appears in, as a
- choice when no alternative applies exactly. The compiler regards
- this alternative as one unit more costly for each `?' that appears
- in it.
-
-`!'
- Disparage severely the alternative that the `!' appears in. This
- alternative can still be used if it fits without reloading, but if
- reloading is needed, some other alternative will be used.
-
-
-File: gcc.info, Node: Modifiers, Next: Machine Constraints, Prev: Multi-Alternative, Up: Constraints
-
-6.42.3 Constraint Modifier Characters
--------------------------------------
-
-Here are constraint modifier characters.
-
-`='
- Means that this operand is write-only for this instruction: the
- previous value is discarded and replaced by output data.
-
-`+'
- Means that this operand is both read and written by the
- instruction.
-
- When the compiler fixes up the operands to satisfy the constraints,
- it needs to know which operands are inputs to the instruction and
- which are outputs from it. `=' identifies an output; `+'
- identifies an operand that is both input and output; all other
- operands are assumed to be input only.
-
- If you specify `=' or `+' in a constraint, you put it in the first
- character of the constraint string.
-
-`&'
- Means (in a particular alternative) that this operand is an
- "earlyclobber" operand, which is modified before the instruction is
- finished using the input operands. Therefore, this operand may
- not lie in a register that is used as an input operand or as part
- of any memory address.
-
- `&' applies only to the alternative in which it is written. In
- constraints with multiple alternatives, sometimes one alternative
- requires `&' while others do not. See, for example, the `movdf'
- insn of the 68000.
-
- An input operand can be tied to an earlyclobber operand if its only
- use as an input occurs before the early result is written. Adding
- alternatives of this form often allows GCC to produce better code
- when only some of the inputs can be affected by the earlyclobber.
- See, for example, the `mulsi3' insn of the ARM.
-
- `&' does not obviate the need to write `='.
-
-`%'
- Declares the instruction to be commutative for this operand and the
- following operand. This means that the compiler may interchange
- the two operands if that is the cheapest way to make all operands
- fit the constraints. GCC can only handle one commutative pair in
- an asm; if you use more, the compiler may fail. Note that you
- need not use the modifier if the two alternatives are strictly
- identical; this would only waste time in the reload pass. The
- modifier is not operational after register allocation, so the
- result of `define_peephole2' and `define_split's performed after
- reload cannot rely on `%' to make the intended insn match.
-
-`#'
- Says that all following characters, up to the next comma, are to be
- ignored as a constraint. They are significant only for choosing
- register preferences.
-
-`*'
- Says that the following character should be ignored when choosing
- register preferences. `*' has no effect on the meaning of the
- constraint as a constraint, and no effect on reloading.
-
-
-
-File: gcc.info, Node: Machine Constraints, Prev: Modifiers, Up: Constraints
-
-6.42.4 Constraints for Particular Machines
-------------------------------------------
-
-Whenever possible, you should use the general-purpose constraint letters
-in `asm' arguments, since they will convey meaning more readily to
-people reading your code. Failing that, use the constraint letters
-that usually have very similar meanings across architectures. The most
-commonly used constraints are `m' and `r' (for memory and
-general-purpose registers respectively; *note Simple Constraints::), and
-`I', usually the letter indicating the most common immediate-constant
-format.
-
- Each architecture defines additional constraints. These constraints
-are used by the compiler itself for instruction generation, as well as
-for `asm' statements; therefore, some of the constraints are not
-particularly useful for `asm'. Here is a summary of some of the
-machine-dependent constraints available on some particular machines; it
-includes both constraints that are useful for `asm' and constraints
-that aren't. The compiler source file mentioned in the table heading
-for each architecture is the definitive reference for the meanings of
-that architecture's constraints.
-
-_ARM family--`config/arm/arm.h'_
-
- `f'
- Floating-point register
-
- `w'
- VFP floating-point register
-
- `F'
- One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0,
- 4.0, 5.0 or 10.0
-
- `G'
- Floating-point constant that would satisfy the constraint `F'
- if it were negated
-
- `I'
- Integer that is valid as an immediate operand in a data
- processing instruction. That is, an integer in the range 0
- to 255 rotated by a multiple of 2
-
- `J'
- Integer in the range -4095 to 4095
-
- `K'
- Integer that satisfies constraint `I' when inverted (ones
- complement)
-
- `L'
- Integer that satisfies constraint `I' when negated (twos
- complement)
-
- `M'
- Integer in the range 0 to 32
-
- `Q'
- A memory reference where the exact address is in a single
- register (``m'' is preferable for `asm' statements)
-
- `R'
- An item in the constant pool
-
- `S'
- A symbol in the text segment of the current file
-
- `Uv'
- A memory reference suitable for VFP load/store insns
- (reg+constant offset)
-
- `Uy'
- A memory reference suitable for iWMMXt load/store
- instructions.
-
- `Uq'
- A memory reference suitable for the ARMv4 ldrsb instruction.
-
-_AVR family--`config/avr/constraints.md'_
-
- `l'
- Registers from r0 to r15
-
- `a'
- Registers from r16 to r23
-
- `d'
- Registers from r16 to r31
-
- `w'
- Registers from r24 to r31. These registers can be used in
- `adiw' command
-
- `e'
- Pointer register (r26-r31)
-
- `b'
- Base pointer register (r28-r31)
-
- `q'
- Stack pointer register (SPH:SPL)
-
- `t'
- Temporary register r0
-
- `x'
- Register pair X (r27:r26)
-
- `y'
- Register pair Y (r29:r28)
-
- `z'
- Register pair Z (r31:r30)
-
- `I'
- Constant greater than -1, less than 64
-
- `J'
- Constant greater than -64, less than 1
-
- `K'
- Constant integer 2
-
- `L'
- Constant integer 0
-
- `M'
- Constant that fits in 8 bits
-
- `N'
- Constant integer -1
-
- `O'
- Constant integer 8, 16, or 24
-
- `P'
- Constant integer 1
-
- `G'
- A floating point constant 0.0
-
- `R'
- Integer constant in the range -6 ... 5.
-
- `Q'
- A memory address based on Y or Z pointer with displacement.
-
-_CRX Architecture--`config/crx/crx.h'_
-
- `b'
- Registers from r0 to r14 (registers without stack pointer)
-
- `l'
- Register r16 (64-bit accumulator lo register)
-
- `h'
- Register r17 (64-bit accumulator hi register)
-
- `k'
- Register pair r16-r17. (64-bit accumulator lo-hi pair)
-
- `I'
- Constant that fits in 3 bits
-
- `J'
- Constant that fits in 4 bits
-
- `K'
- Constant that fits in 5 bits
-
- `L'
- Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
-
- `G'
- Floating point constant that is legal for store immediate
-
-_Hewlett-Packard PA-RISC--`config/pa/pa.h'_
-
- `a'
- General register 1
-
- `f'
- Floating point register
-
- `q'
- Shift amount register
-
- `x'
- Floating point register (deprecated)
-
- `y'
- Upper floating point register (32-bit), floating point
- register (64-bit)
-
- `Z'
- Any register
-
- `I'
- Signed 11-bit integer constant
-
- `J'
- Signed 14-bit integer constant
-
- `K'
- Integer constant that can be deposited with a `zdepi'
- instruction
-
- `L'
- Signed 5-bit integer constant
-
- `M'
- Integer constant 0
-
- `N'
- Integer constant that can be loaded with a `ldil' instruction
-
- `O'
- Integer constant whose value plus one is a power of 2
-
- `P'
- Integer constant that can be used for `and' operations in
- `depi' and `extru' instructions
-
- `S'
- Integer constant 31
-
- `U'
- Integer constant 63
-
- `G'
- Floating-point constant 0.0
-
- `A'
- A `lo_sum' data-linkage-table memory operand
-
- `Q'
- A memory operand that can be used as the destination operand
- of an integer store instruction
-
- `R'
- A scaled or unscaled indexed memory operand
-
- `T'
- A memory operand for floating-point loads and stores
-
- `W'
- A register indirect memory operand
-
-_picoChip family--`picochip.h'_
-
- `k'
- Stack register.
-
- `f'
- Pointer register. A register which can be used to access
- memory without supplying an offset. Any other register can
- be used to access memory, but will need a constant offset.
- In the case of the offset being zero, it is more efficient to
- use a pointer register, since this reduces code size.
-
- `t'
- A twin register. A register which may be paired with an
- adjacent register to create a 32-bit register.
-
- `a'
- Any absolute memory address (e.g., symbolic constant, symbolic
- constant + offset).
-
- `I'
- 4-bit signed integer.
-
- `J'
- 4-bit unsigned integer.
-
- `K'
- 8-bit signed integer.
-
- `M'
- Any constant whose absolute value is no greater than 4-bits.
-
- `N'
- 10-bit signed integer
-
- `O'
- 16-bit signed integer.
-
-
-_PowerPC and IBM RS6000--`config/rs6000/rs6000.h'_
-
- `b'
- Address base register
-
- `d'
- Floating point register (containing 64-bit value)
-
- `f'
- Floating point register (containing 32-bit value)
-
- `v'
- Altivec vector register
-
- `wd'
- VSX vector register to hold vector double data
-
- `wf'
- VSX vector register to hold vector float data
-
- `ws'
- VSX vector register to hold scalar float data
-
- `wa'
- Any VSX register
-
- `h'
- `MQ', `CTR', or `LINK' register
-
- `q'
- `MQ' register
-
- `c'
- `CTR' register
-
- `l'
- `LINK' register
-
- `x'
- `CR' register (condition register) number 0
-
- `y'
- `CR' register (condition register)
-
- `z'
- `XER[CA]' carry bit (part of the XER register)
-
- `I'
- Signed 16-bit constant
-
- `J'
- Unsigned 16-bit constant shifted left 16 bits (use `L'
- instead for `SImode' constants)
-
- `K'
- Unsigned 16-bit constant
-
- `L'
- Signed 16-bit constant shifted left 16 bits
-
- `M'
- Constant larger than 31
-
- `N'
- Exact power of 2
-
- `O'
- Zero
-
- `P'
- Constant whose negation is a signed 16-bit constant
-
- `G'
- Floating point constant that can be loaded into a register
- with one instruction per word
-
- `H'
- Integer/Floating point constant that can be loaded into a
- register using three instructions
-
- `m'
- Memory operand. Normally, `m' does not allow addresses that
- update the base register. If `<' or `>' constraint is also
- used, they are allowed and therefore on PowerPC targets in
- that case it is only safe to use `m<>' in an `asm' statement
- if that `asm' statement accesses the operand exactly once.
- The `asm' statement must also use `%U<OPNO>' as a placeholder
- for the "update" flag in the corresponding load or store
- instruction. For example:
-
- asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val));
-
- is correct but:
-
- asm ("st %1,%0" : "=m<>" (mem) : "r" (val));
-
- is not.
-
- `es'
- A "stable" memory operand; that is, one which does not
- include any automodification of the base register. This used
- to be useful when `m' allowed automodification of the base
- register, but as those are now only allowed when `<' or `>'
- is used, `es' is basically the same as `m' without `<' and
- `>'.
-
- `Q'
- Memory operand that is an offset from a register (it is
- usually better to use `m' or `es' in `asm' statements)
-
- `Z'
- Memory operand that is an indexed or indirect from a register
- (it is usually better to use `m' or `es' in `asm' statements)
-
- `R'
- AIX TOC entry
-
- `a'
- Address operand that is an indexed or indirect from a
- register (`p' is preferable for `asm' statements)
-
- `S'
- Constant suitable as a 64-bit mask operand
-
- `T'
- Constant suitable as a 32-bit mask operand
-
- `U'
- System V Release 4 small data area reference
-
- `t'
- AND masks that can be performed by two rldic{l, r}
- instructions
-
- `W'
- Vector constant that does not require memory
-
- `j'
- Vector constant that is all zeros.
-
-
-_Intel 386--`config/i386/constraints.md'_
-
- `R'
- Legacy register--the eight integer registers available on all
- i386 processors (`a', `b', `c', `d', `si', `di', `bp', `sp').
-
- `q'
- Any register accessible as `Rl'. In 32-bit mode, `a', `b',
- `c', and `d'; in 64-bit mode, any integer register.
-
- `Q'
- Any register accessible as `Rh': `a', `b', `c', and `d'.
-
- `a'
- The `a' register.
-
- `b'
- The `b' register.
-
- `c'
- The `c' register.
-
- `d'
- The `d' register.
-
- `S'
- The `si' register.
-
- `D'
- The `di' register.
-
- `A'
- The `a' and `d' registers. This class is used for
- instructions that return double word results in the `ax:dx'
- register pair. Single word values will be allocated either
- in `ax' or `dx'. For example on i386 the following
- implements `rdtsc':
-
- unsigned long long rdtsc (void)
- {
- unsigned long long tick;
- __asm__ __volatile__("rdtsc":"=A"(tick));
- return tick;
- }
-
- This is not correct on x86_64 as it would allocate tick in
- either `ax' or `dx'. You have to use the following variant
- instead:
-
- unsigned long long rdtsc (void)
- {
- unsigned int tickl, tickh;
- __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh));
- return ((unsigned long long)tickh << 32)|tickl;
- }
-
- `f'
- Any 80387 floating-point (stack) register.
-
- `t'
- Top of 80387 floating-point stack (`%st(0)').
-
- `u'
- Second from top of 80387 floating-point stack (`%st(1)').
-
- `y'
- Any MMX register.
-
- `x'
- Any SSE register.
-
- `Yz'
- First SSE register (`%xmm0').
-
- `I'
- Integer constant in the range 0 ... 31, for 32-bit shifts.
-
- `J'
- Integer constant in the range 0 ... 63, for 64-bit shifts.
-
- `K'
- Signed 8-bit integer constant.
-
- `L'
- `0xFF' or `0xFFFF', for andsi as a zero-extending move.
-
- `M'
- 0, 1, 2, or 3 (shifts for the `lea' instruction).
-
- `N'
- Unsigned 8-bit integer constant (for `in' and `out'
- instructions).
-
- `G'
- Standard 80387 floating point constant.
-
- `C'
- Standard SSE floating point constant.
-
- `e'
- 32-bit signed integer constant, or a symbolic reference known
- to fit that range (for immediate operands in sign-extending
- x86-64 instructions).
-
- `Z'
- 32-bit unsigned integer constant, or a symbolic reference
- known to fit that range (for immediate operands in
- zero-extending x86-64 instructions).
-
-
-_Intel IA-64--`config/ia64/ia64.h'_
-
- `a'
- General register `r0' to `r3' for `addl' instruction
-
- `b'
- Branch register
-
- `c'
- Predicate register (`c' as in "conditional")
-
- `d'
- Application register residing in M-unit
-
- `e'
- Application register residing in I-unit
-
- `f'
- Floating-point register
-
- `m'
- Memory operand. If used together with `<' or `>', the
- operand can have postincrement and postdecrement which
- require printing with `%Pn' on IA-64.
-
- `G'
- Floating-point constant 0.0 or 1.0
-
- `I'
- 14-bit signed integer constant
-
- `J'
- 22-bit signed integer constant
-
- `K'
- 8-bit signed integer constant for logical instructions
-
- `L'
- 8-bit adjusted signed integer constant for compare pseudo-ops
-
- `M'
- 6-bit unsigned integer constant for shift counts
-
- `N'
- 9-bit signed integer constant for load and store
- postincrements
-
- `O'
- The constant zero
-
- `P'
- 0 or -1 for `dep' instruction
-
- `Q'
- Non-volatile memory for floating-point loads and stores
-
- `R'
- Integer constant in the range 1 to 4 for `shladd' instruction
-
- `S'
- Memory operand except postincrement and postdecrement. This
- is now roughly the same as `m' when not used together with `<'
- or `>'.
-
-_FRV--`config/frv/frv.h'_
-
- `a'
- Register in the class `ACC_REGS' (`acc0' to `acc7').
-
- `b'
- Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7').
-
- `c'
- Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0'
- to `icc3').
-
- `d'
- Register in the class `GPR_REGS' (`gr0' to `gr63').
-
- `e'
- Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd
- registers are excluded not in the class but through the use
- of a machine mode larger than 4 bytes.
-
- `f'
- Register in the class `FPR_REGS' (`fr0' to `fr63').
-
- `h'
- Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd
- registers are excluded not in the class but through the use
- of a machine mode larger than 4 bytes.
-
- `l'
- Register in the class `LR_REG' (the `lr' register).
-
- `q'
- Register in the class `QUAD_REGS' (`gr2' to `gr63').
- Register numbers not divisible by 4 are excluded not in the
- class but through the use of a machine mode larger than 8
- bytes.
-
- `t'
- Register in the class `ICC_REGS' (`icc0' to `icc3').
-
- `u'
- Register in the class `FCC_REGS' (`fcc0' to `fcc3').
-
- `v'
- Register in the class `ICR_REGS' (`cc4' to `cc7').
-
- `w'
- Register in the class `FCR_REGS' (`cc0' to `cc3').
-
- `x'
- Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63').
- Register numbers not divisible by 4 are excluded not in the
- class but through the use of a machine mode larger than 8
- bytes.
-
- `z'
- Register in the class `SPR_REGS' (`lcr' and `lr').
-
- `A'
- Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7').
-
- `B'
- Register in the class `ACCG_REGS' (`accg0' to `accg7').
-
- `C'
- Register in the class `CR_REGS' (`cc0' to `cc7').
-
- `G'
- Floating point constant zero
-
- `I'
- 6-bit signed integer constant
-
- `J'
- 10-bit signed integer constant
-
- `L'
- 16-bit signed integer constant
-
- `M'
- 16-bit unsigned integer constant
-
- `N'
- 12-bit signed integer constant that is negative--i.e. in the
- range of -2048 to -1
-
- `O'
- Constant zero
-
- `P'
- 12-bit signed integer constant that is greater than
- zero--i.e. in the range of 1 to 2047.
-
-
-_Blackfin family--`config/bfin/constraints.md'_
-
- `a'
- P register
-
- `d'
- D register
-
- `z'
- A call clobbered P register.
-
- `qN'
- A single register. If N is in the range 0 to 7, the
- corresponding D register. If it is `A', then the register P0.
-
- `D'
- Even-numbered D register
-
- `W'
- Odd-numbered D register
-
- `e'
- Accumulator register.
-
- `A'
- Even-numbered accumulator register.
-
- `B'
- Odd-numbered accumulator register.
-
- `b'
- I register
-
- `v'
- B register
-
- `f'
- M register
-
- `c'
- Registers used for circular buffering, i.e. I, B, or L
- registers.
-
- `C'
- The CC register.
-
- `t'
- LT0 or LT1.
-
- `k'
- LC0 or LC1.
-
- `u'
- LB0 or LB1.
-
- `x'
- Any D, P, B, M, I or L register.
-
- `y'
- Additional registers typically used only in prologues and
- epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and
- USP.
-
- `w'
- Any register except accumulators or CC.
-
- `Ksh'
- Signed 16 bit integer (in the range -32768 to 32767)
-
- `Kuh'
- Unsigned 16 bit integer (in the range 0 to 65535)
-
- `Ks7'
- Signed 7 bit integer (in the range -64 to 63)
-
- `Ku7'
- Unsigned 7 bit integer (in the range 0 to 127)
-
- `Ku5'
- Unsigned 5 bit integer (in the range 0 to 31)
-
- `Ks4'
- Signed 4 bit integer (in the range -8 to 7)
-
- `Ks3'
- Signed 3 bit integer (in the range -3 to 4)
-
- `Ku3'
- Unsigned 3 bit integer (in the range 0 to 7)
-
- `PN'
- Constant N, where N is a single-digit constant in the range 0
- to 4.
-
- `PA'
- An integer equal to one of the MACFLAG_XXX constants that is
- suitable for use with either accumulator.
-
- `PB'
- An integer equal to one of the MACFLAG_XXX constants that is
- suitable for use only with accumulator A1.
-
- `M1'
- Constant 255.
-
- `M2'
- Constant 65535.
-
- `J'
- An integer constant with exactly a single bit set.
-
- `L'
- An integer constant with all bits set except exactly one.
-
- `H'
-
- `Q'
- Any SYMBOL_REF.
-
-_M32C--`config/m32c/m32c.c'_
-
- `Rsp'
- `Rfb'
- `Rsb'
- `$sp', `$fb', `$sb'.
-
- `Rcr'
- Any control register, when they're 16 bits wide (nothing if
- control registers are 24 bits wide)
-
- `Rcl'
- Any control register, when they're 24 bits wide.
-
- `R0w'
- `R1w'
- `R2w'
- `R3w'
- $r0, $r1, $r2, $r3.
-
- `R02'
- $r0 or $r2, or $r2r0 for 32 bit values.
-
- `R13'
- $r1 or $r3, or $r3r1 for 32 bit values.
-
- `Rdi'
- A register that can hold a 64 bit value.
-
- `Rhl'
- $r0 or $r1 (registers with addressable high/low bytes)
-
- `R23'
- $r2 or $r3
-
- `Raa'
- Address registers
-
- `Raw'
- Address registers when they're 16 bits wide.
-
- `Ral'
- Address registers when they're 24 bits wide.
-
- `Rqi'
- Registers that can hold QI values.
-
- `Rad'
- Registers that can be used with displacements ($a0, $a1, $sb).
-
- `Rsi'
- Registers that can hold 32 bit values.
-
- `Rhi'
- Registers that can hold 16 bit values.
-
- `Rhc'
- Registers chat can hold 16 bit values, including all control
- registers.
-
- `Rra'
- $r0 through R1, plus $a0 and $a1.
-
- `Rfl'
- The flags register.
-
- `Rmm'
- The memory-based pseudo-registers $mem0 through $mem15.
-
- `Rpi'
- Registers that can hold pointers (16 bit registers for r8c,
- m16c; 24 bit registers for m32cm, m32c).
-
- `Rpa'
- Matches multiple registers in a PARALLEL to form a larger
- register. Used to match function return values.
-
- `Is3'
- -8 ... 7
-
- `IS1'
- -128 ... 127
-
- `IS2'
- -32768 ... 32767
-
- `IU2'
- 0 ... 65535
-
- `In4'
- -8 ... -1 or 1 ... 8
-
- `In5'
- -16 ... -1 or 1 ... 16
-
- `In6'
- -32 ... -1 or 1 ... 32
-
- `IM2'
- -65536 ... -1
-
- `Ilb'
- An 8 bit value with exactly one bit set.
-
- `Ilw'
- A 16 bit value with exactly one bit set.
-
- `Sd'
- The common src/dest memory addressing modes.
-
- `Sa'
- Memory addressed using $a0 or $a1.
-
- `Si'
- Memory addressed with immediate addresses.
-
- `Ss'
- Memory addressed using the stack pointer ($sp).
-
- `Sf'
- Memory addressed using the frame base register ($fb).
-
- `Ss'
- Memory addressed using the small base register ($sb).
-
- `S1'
- $r1h
-
-_MeP--`config/mep/constraints.md'_
-
- `a'
- The $sp register.
-
- `b'
- The $tp register.
-
- `c'
- Any control register.
-
- `d'
- Either the $hi or the $lo register.
-
- `em'
- Coprocessor registers that can be directly loaded ($c0-$c15).
-
- `ex'
- Coprocessor registers that can be moved to each other.
-
- `er'
- Coprocessor registers that can be moved to core registers.
-
- `h'
- The $hi register.
-
- `j'
- The $rpc register.
-
- `l'
- The $lo register.
-
- `t'
- Registers which can be used in $tp-relative addressing.
-
- `v'
- The $gp register.
-
- `x'
- The coprocessor registers.
-
- `y'
- The coprocessor control registers.
-
- `z'
- The $0 register.
-
- `A'
- User-defined register set A.
-
- `B'
- User-defined register set B.
-
- `C'
- User-defined register set C.
-
- `D'
- User-defined register set D.
-
- `I'
- Offsets for $gp-rel addressing.
-
- `J'
- Constants that can be used directly with boolean insns.
-
- `K'
- Constants that can be moved directly to registers.
-
- `L'
- Small constants that can be added to registers.
-
- `M'
- Long shift counts.
-
- `N'
- Small constants that can be compared to registers.
-
- `O'
- Constants that can be loaded into the top half of registers.
-
- `S'
- Signed 8-bit immediates.
-
- `T'
- Symbols encoded for $tp-rel or $gp-rel addressing.
-
- `U'
- Non-constant addresses for loading/saving coprocessor
- registers.
-
- `W'
- The top half of a symbol's value.
-
- `Y'
- A register indirect address without offset.
-
- `Z'
- Symbolic references to the control bus.
-
-
-_MicroBlaze--`config/microblaze/constraints.md'_
-
- `d'
- A general register (`r0' to `r31').
-
- `z'
- A status register (`rmsr', `$fcc1' to `$fcc7').
-
-
-_MIPS--`config/mips/constraints.md'_
-
- `d'
- An address register. This is equivalent to `r' unless
- generating MIPS16 code.
-
- `f'
- A floating-point register (if available).
-
- `h'
- Formerly the `hi' register. This constraint is no longer
- supported.
-
- `l'
- The `lo' register. Use this register to store values that are
- no bigger than a word.
-
- `x'
- The concatenated `hi' and `lo' registers. Use this register
- to store doubleword values.
-
- `c'
- A register suitable for use in an indirect jump. This will
- always be `$25' for `-mabicalls'.
-
- `v'
- Register `$3'. Do not use this constraint in new code; it is
- retained only for compatibility with glibc.
-
- `y'
- Equivalent to `r'; retained for backwards compatibility.
-
- `z'
- A floating-point condition code register.
-
- `I'
- A signed 16-bit constant (for arithmetic instructions).
-
- `J'
- Integer zero.
-
- `K'
- An unsigned 16-bit constant (for logic instructions).
-
- `L'
- A signed 32-bit constant in which the lower 16 bits are zero.
- Such constants can be loaded using `lui'.
-
- `M'
- A constant that cannot be loaded using `lui', `addiu' or
- `ori'.
-
- `N'
- A constant in the range -65535 to -1 (inclusive).
-
- `O'
- A signed 15-bit constant.
-
- `P'
- A constant in the range 1 to 65535 (inclusive).
-
- `G'
- Floating-point zero.
-
- `R'
- An address that can be used in a non-macro load or store.
-
-_Motorola 680x0--`config/m68k/constraints.md'_
-
- `a'
- Address register
-
- `d'
- Data register
-
- `f'
- 68881 floating-point register, if available
-
- `I'
- Integer in the range 1 to 8
-
- `J'
- 16-bit signed number
-
- `K'
- Signed number whose magnitude is greater than 0x80
-
- `L'
- Integer in the range -8 to -1
-
- `M'
- Signed number whose magnitude is greater than 0x100
-
- `N'
- Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate
-
- `O'
- 16 (for rotate using swap)
-
- `P'
- Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate
-
- `R'
- Numbers that mov3q can handle
-
- `G'
- Floating point constant that is not a 68881 constant
-
- `S'
- Operands that satisfy 'm' when -mpcrel is in effect
-
- `T'
- Operands that satisfy 's' when -mpcrel is not in effect
-
- `Q'
- Address register indirect addressing mode
-
- `U'
- Register offset addressing
-
- `W'
- const_call_operand
-
- `Cs'
- symbol_ref or const
-
- `Ci'
- const_int
-
- `C0'
- const_int 0
-
- `Cj'
- Range of signed numbers that don't fit in 16 bits
-
- `Cmvq'
- Integers valid for mvq
-
- `Capsw'
- Integers valid for a moveq followed by a swap
-
- `Cmvz'
- Integers valid for mvz
-
- `Cmvs'
- Integers valid for mvs
-
- `Ap'
- push_operand
-
- `Ac'
- Non-register operands allowed in clr
-
-
-_Motorola 68HC11 & 68HC12 families--`config/m68hc11/m68hc11.h'_
-
- `a'
- Register `a'
-
- `b'
- Register `b'
-
- `d'
- Register `d'
-
- `q'
- An 8-bit register
-
- `t'
- Temporary soft register _.tmp
-
- `u'
- A soft register _.d1 to _.d31
-
- `w'
- Stack pointer register
-
- `x'
- Register `x'
-
- `y'
- Register `y'
-
- `z'
- Pseudo register `z' (replaced by `x' or `y' at the end)
-
- `A'
- An address register: x, y or z
-
- `B'
- An address register: x or y
-
- `D'
- Register pair (x:d) to form a 32-bit value
-
- `L'
- Constants in the range -65536 to 65535
-
- `M'
- Constants whose 16-bit low part is zero
-
- `N'
- Constant integer 1 or -1
-
- `O'
- Constant integer 16
-
- `P'
- Constants in the range -8 to 2
-
-
-_Moxie--`config/moxie/constraints.md'_
-
- `A'
- An absolute address
-
- `B'
- An offset address
-
- `W'
- A register indirect memory operand
-
- `I'
- A constant in the range of 0 to 255.
-
- `N'
- A constant in the range of 0 to -255.
-
-
-_PDP-11--`config/pdp11/constraints.md'_
-
- `a'
- Floating point registers AC0 through AC3. These can be
- loaded from/to memory with a single instruction.
-
- `d'
- Odd numbered general registers (R1, R3, R5). These are used
- for 16-bit multiply operations.
-
- `f'
- Any of the floating point registers (AC0 through AC5).
-
- `G'
- Floating point constant 0.
-
- `I'
- An integer constant that fits in 16 bits.
-
- `J'
- An integer constant whose low order 16 bits are zero.
-
- `K'
- An integer constant that does not meet the constraints for
- codes `I' or `J'.
-
- `L'
- The integer constant 1.
-
- `M'
- The integer constant -1.
-
- `N'
- The integer constant 0.
-
- `O'
- Integer constants -4 through -1 and 1 through 4; shifts by
- these amounts are handled as multiple single-bit shifts
- rather than a single variable-length shift.
-
- `Q'
- A memory reference which requires an additional word (address
- or offset) after the opcode.
-
- `R'
- A memory reference that is encoded within the opcode.
-
-
-_RX--`config/rx/constraints.md'_
-
- `Q'
- An address which does not involve register indirect
- addressing or pre/post increment/decrement addressing.
-
- `Symbol'
- A symbol reference.
-
- `Int08'
- A constant in the range -256 to 255, inclusive.
-
- `Sint08'
- A constant in the range -128 to 127, inclusive.
-
- `Sint16'
- A constant in the range -32768 to 32767, inclusive.
-
- `Sint24'
- A constant in the range -8388608 to 8388607, inclusive.
-
- `Uint04'
- A constant in the range 0 to 15, inclusive.
-
-
-_SPARC--`config/sparc/sparc.h'_
-
- `f'
- Floating-point register on the SPARC-V8 architecture and
- lower floating-point register on the SPARC-V9 architecture.
-
- `e'
- Floating-point register. It is equivalent to `f' on the
- SPARC-V8 architecture and contains both lower and upper
- floating-point registers on the SPARC-V9 architecture.
-
- `c'
- Floating-point condition code register.
-
- `d'
- Lower floating-point register. It is only valid on the
- SPARC-V9 architecture when the Visual Instruction Set is
- available.
-
- `b'
- Floating-point register. It is only valid on the SPARC-V9
- architecture when the Visual Instruction Set is available.
-
- `h'
- 64-bit global or out register for the SPARC-V8+ architecture.
-
- `D'
- A vector constant
-
- `I'
- Signed 13-bit constant
-
- `J'
- Zero
-
- `K'
- 32-bit constant with the low 12 bits clear (a constant that
- can be loaded with the `sethi' instruction)
-
- `L'
- A constant in the range supported by `movcc' instructions
-
- `M'
- A constant in the range supported by `movrcc' instructions
-
- `N'
- Same as `K', except that it verifies that bits that are not
- in the lower 32-bit range are all zero. Must be used instead
- of `K' for modes wider than `SImode'
-
- `O'
- The constant 4096
-
- `G'
- Floating-point zero
-
- `H'
- Signed 13-bit constant, sign-extended to 32 or 64 bits
-
- `Q'
- Floating-point constant whose integral representation can be
- moved into an integer register using a single sethi
- instruction
-
- `R'
- Floating-point constant whose integral representation can be
- moved into an integer register using a single mov instruction
-
- `S'
- Floating-point constant whose integral representation can be
- moved into an integer register using a high/lo_sum
- instruction sequence
-
- `T'
- Memory address aligned to an 8-byte boundary
-
- `U'
- Even register
-
- `W'
- Memory address for `e' constraint registers
-
- `Y'
- Vector zero
-
-
-_SPU--`config/spu/spu.h'_
-
- `a'
- An immediate which can be loaded with the il/ila/ilh/ilhu
- instructions. const_int is treated as a 64 bit value.
-
- `c'
- An immediate for and/xor/or instructions. const_int is
- treated as a 64 bit value.
-
- `d'
- An immediate for the `iohl' instruction. const_int is
- treated as a 64 bit value.
-
- `f'
- An immediate which can be loaded with `fsmbi'.
-
- `A'
- An immediate which can be loaded with the il/ila/ilh/ilhu
- instructions. const_int is treated as a 32 bit value.
-
- `B'
- An immediate for most arithmetic instructions. const_int is
- treated as a 32 bit value.
-
- `C'
- An immediate for and/xor/or instructions. const_int is
- treated as a 32 bit value.
-
- `D'
- An immediate for the `iohl' instruction. const_int is
- treated as a 32 bit value.
-
- `I'
- A constant in the range [-64, 63] for shift/rotate
- instructions.
-
- `J'
- An unsigned 7-bit constant for conversion/nop/channel
- instructions.
-
- `K'
- A signed 10-bit constant for most arithmetic instructions.
-
- `M'
- A signed 16 bit immediate for `stop'.
-
- `N'
- An unsigned 16-bit constant for `iohl' and `fsmbi'.
-
- `O'
- An unsigned 7-bit constant whose 3 least significant bits are
- 0.
-
- `P'
- An unsigned 3-bit constant for 16-byte rotates and shifts
-
- `R'
- Call operand, reg, for indirect calls
-
- `S'
- Call operand, symbol, for relative calls.
-
- `T'
- Call operand, const_int, for absolute calls.
-
- `U'
- An immediate which can be loaded with the il/ila/ilh/ilhu
- instructions. const_int is sign extended to 128 bit.
-
- `W'
- An immediate for shift and rotate instructions. const_int is
- treated as a 32 bit value.
-
- `Y'
- An immediate for and/xor/or instructions. const_int is sign
- extended as a 128 bit.
-
- `Z'
- An immediate for the `iohl' instruction. const_int is sign
- extended to 128 bit.
-
-
-_S/390 and zSeries--`config/s390/s390.h'_
-
- `a'
- Address register (general purpose register except r0)
-
- `c'
- Condition code register
-
- `d'
- Data register (arbitrary general purpose register)
-
- `f'
- Floating-point register
-
- `I'
- Unsigned 8-bit constant (0-255)
-
- `J'
- Unsigned 12-bit constant (0-4095)
-
- `K'
- Signed 16-bit constant (-32768-32767)
-
- `L'
- Value appropriate as displacement.
- `(0..4095)'
- for short displacement
-
- `(-524288..524287)'
- for long displacement
-
- `M'
- Constant integer with a value of 0x7fffffff.
-
- `N'
- Multiple letter constraint followed by 4 parameter letters.
- `0..9:'
- number of the part counting from most to least
- significant
-
- `H,Q:'
- mode of the part
-
- `D,S,H:'
- mode of the containing operand
-
- `0,F:'
- value of the other parts (F--all bits set)
- The constraint matches if the specified part of a constant
- has a value different from its other parts.
-
- `Q'
- Memory reference without index register and with short
- displacement.
-
- `R'
- Memory reference with index register and short displacement.
-
- `S'
- Memory reference without index register but with long
- displacement.
-
- `T'
- Memory reference with index register and long displacement.
-
- `U'
- Pointer with short displacement.
-
- `W'
- Pointer with long displacement.
-
- `Y'
- Shift count operand.
-
-
-_Score family--`config/score/score.h'_
-
- `d'
- Registers from r0 to r32.
-
- `e'
- Registers from r0 to r16.
-
- `t'
- r8--r11 or r22--r27 registers.
-
- `h'
- hi register.
-
- `l'
- lo register.
-
- `x'
- hi + lo register.
-
- `q'
- cnt register.
-
- `y'
- lcb register.
-
- `z'
- scb register.
-
- `a'
- cnt + lcb + scb register.
-
- `c'
- cr0--cr15 register.
-
- `b'
- cp1 registers.
-
- `f'
- cp2 registers.
-
- `i'
- cp3 registers.
-
- `j'
- cp1 + cp2 + cp3 registers.
-
- `I'
- High 16-bit constant (32-bit constant with 16 LSBs zero).
-
- `J'
- Unsigned 5 bit integer (in the range 0 to 31).
-
- `K'
- Unsigned 16 bit integer (in the range 0 to 65535).
-
- `L'
- Signed 16 bit integer (in the range -32768 to 32767).
-
- `M'
- Unsigned 14 bit integer (in the range 0 to 16383).
-
- `N'
- Signed 14 bit integer (in the range -8192 to 8191).
-
- `Z'
- Any SYMBOL_REF.
-
-_Xstormy16--`config/stormy16/stormy16.h'_
-
- `a'
- Register r0.
-
- `b'
- Register r1.
-
- `c'
- Register r2.
-
- `d'
- Register r8.
-
- `e'
- Registers r0 through r7.
-
- `t'
- Registers r0 and r1.
-
- `y'
- The carry register.
-
- `z'
- Registers r8 and r9.
-
- `I'
- A constant between 0 and 3 inclusive.
-
- `J'
- A constant that has exactly one bit set.
-
- `K'
- A constant that has exactly one bit clear.
-
- `L'
- A constant between 0 and 255 inclusive.
-
- `M'
- A constant between -255 and 0 inclusive.
-
- `N'
- A constant between -3 and 0 inclusive.
-
- `O'
- A constant between 1 and 4 inclusive.
-
- `P'
- A constant between -4 and -1 inclusive.
-
- `Q'
- A memory reference that is a stack push.
-
- `R'
- A memory reference that is a stack pop.
-
- `S'
- A memory reference that refers to a constant address of known
- value.
-
- `T'
- The register indicated by Rx (not implemented yet).
-
- `U'
- A constant that is not between 2 and 15 inclusive.
-
- `Z'
- The constant 0.
-
-
-_Xtensa--`config/xtensa/constraints.md'_
-
- `a'
- General-purpose 32-bit register
-
- `b'
- One-bit boolean register
-
- `A'
- MAC16 40-bit accumulator register
-
- `I'
- Signed 12-bit integer constant, for use in MOVI instructions
-
- `J'
- Signed 8-bit integer constant, for use in ADDI instructions
-
- `K'
- Integer constant valid for BccI instructions
-
- `L'
- Unsigned constant valid for BccUI instructions
-
-
-
-
-File: gcc.info, Node: Asm Labels, Next: Explicit Reg Vars, Prev: Constraints, Up: C Extensions
-
-6.43 Controlling Names Used in Assembler Code
-=============================================
-
-You can specify the name to be used in the assembler code for a C
-function or variable by writing the `asm' (or `__asm__') keyword after
-the declarator as follows:
-
- int foo asm ("myfoo") = 2;
-
-This specifies that the name to be used for the variable `foo' in the
-assembler code should be `myfoo' rather than the usual `_foo'.
-
- On systems where an underscore is normally prepended to the name of a C
-function or variable, this feature allows you to define names for the
-linker that do not start with an underscore.
-
- It does not make sense to use this feature with a non-static local
-variable since such variables do not have assembler names. If you are
-trying to put the variable in a particular register, see *note Explicit
-Reg Vars::. GCC presently accepts such code with a warning, but will
-probably be changed to issue an error, rather than a warning, in the
-future.
-
- You cannot use `asm' in this way in a function _definition_; but you
-can get the same effect by writing a declaration for the function
-before its definition and putting `asm' there, like this:
-
- extern func () asm ("FUNC");
-
- func (x, y)
- int x, y;
- /* ... */
-
- It is up to you to make sure that the assembler names you choose do not
-conflict with any other assembler symbols. Also, you must not use a
-register name; that would produce completely invalid assembler code.
-GCC does not as yet have the ability to store static variables in
-registers. Perhaps that will be added.
-
-
-File: gcc.info, Node: Explicit Reg Vars, Next: Alternate Keywords, Prev: Asm Labels, Up: C Extensions
-
-6.44 Variables in Specified Registers
-=====================================
-
-GNU C allows you to put a few global variables into specified hardware
-registers. You can also specify the register in which an ordinary
-register variable should be allocated.
-
- * Global register variables reserve registers throughout the program.
- This may be useful in programs such as programming language
- interpreters which have a couple of global variables that are
- accessed very often.
-
- * Local register variables in specific registers do not reserve the
- registers, except at the point where they are used as input or
- output operands in an `asm' statement and the `asm' statement
- itself is not deleted. The compiler's data flow analysis is
- capable of determining where the specified registers contain live
- values, and where they are available for other uses. Stores into
- local register variables may be deleted when they appear to be
- dead according to dataflow analysis. References to local register
- variables may be deleted or moved or simplified.
-
- These local variables are sometimes convenient for use with the
- extended `asm' feature (*note Extended Asm::), if you want to
- write one output of the assembler instruction directly into a
- particular register. (This will work provided the register you
- specify fits the constraints specified for that operand in the
- `asm'.)
-
-* Menu:
-
-* Global Reg Vars::
-* Local Reg Vars::
-
-
-File: gcc.info, Node: Global Reg Vars, Next: Local Reg Vars, Up: Explicit Reg Vars
-
-6.44.1 Defining Global Register Variables
------------------------------------------
-
-You can define a global register variable in GNU C like this:
-
- register int *foo asm ("a5");
-
-Here `a5' is the name of the register which should be used. Choose a
-register which is normally saved and restored by function calls on your
-machine, so that library routines will not clobber it.
-
- Naturally the register name is cpu-dependent, so you would need to
-conditionalize your program according to cpu type. The register `a5'
-would be a good choice on a 68000 for a variable of pointer type. On
-machines with register windows, be sure to choose a "global" register
-that is not affected magically by the function call mechanism.
-
- In addition, operating systems on one type of cpu may differ in how
-they name the registers; then you would need additional conditionals.
-For example, some 68000 operating systems call this register `%a5'.
-
- Eventually there may be a way of asking the compiler to choose a
-register automatically, but first we need to figure out how it should
-choose and how to enable you to guide the choice. No solution is
-evident.
-
- Defining a global register variable in a certain register reserves that
-register entirely for this use, at least within the current compilation.
-The register will not be allocated for any other purpose in the
-functions in the current compilation. The register will not be saved
-and restored by these functions. Stores into this register are never
-deleted even if they would appear to be dead, but references may be
-deleted or moved or simplified.
-
- It is not safe to access the global register variables from signal
-handlers, or from more than one thread of control, because the system
-library routines may temporarily use the register for other things
-(unless you recompile them specially for the task at hand).
-
- It is not safe for one function that uses a global register variable to
-call another such function `foo' by way of a third function `lose' that
-was compiled without knowledge of this variable (i.e. in a different
-source file in which the variable wasn't declared). This is because
-`lose' might save the register and put some other value there. For
-example, you can't expect a global register variable to be available in
-the comparison-function that you pass to `qsort', since `qsort' might
-have put something else in that register. (If you are prepared to
-recompile `qsort' with the same global register variable, you can solve
-this problem.)
-
- If you want to recompile `qsort' or other source files which do not
-actually use your global register variable, so that they will not use
-that register for any other purpose, then it suffices to specify the
-compiler option `-ffixed-REG'. You need not actually add a global
-register declaration to their source code.
-
- A function which can alter the value of a global register variable
-cannot safely be called from a function compiled without this variable,
-because it could clobber the value the caller expects to find there on
-return. Therefore, the function which is the entry point into the part
-of the program that uses the global register variable must explicitly
-save and restore the value which belongs to its caller.
-
- On most machines, `longjmp' will restore to each global register
-variable the value it had at the time of the `setjmp'. On some
-machines, however, `longjmp' will not change the value of global
-register variables. To be portable, the function that called `setjmp'
-should make other arrangements to save the values of the global register
-variables, and to restore them in a `longjmp'. This way, the same
-thing will happen regardless of what `longjmp' does.
-
- All global register variable declarations must precede all function
-definitions. If such a declaration could appear after function
-definitions, the declaration would be too late to prevent the register
-from being used for other purposes in the preceding functions.
-
- Global register variables may not have initial values, because an
-executable file has no means to supply initial contents for a register.
-
- On the SPARC, there are reports that g3 ... g7 are suitable registers,
-but certain library functions, such as `getwd', as well as the
-subroutines for division and remainder, modify g3 and g4. g1 and g2
-are local temporaries.
-
- On the 68000, a2 ... a5 should be suitable, as should d2 ... d7. Of
-course, it will not do to use more than a few of those.
-
-
-File: gcc.info, Node: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars
-
-6.44.2 Specifying Registers for Local Variables
------------------------------------------------
-
-You can define a local register variable with a specified register like
-this:
-
- register int *foo asm ("a5");
-
-Here `a5' is the name of the register which should be used. Note that
-this is the same syntax used for defining global register variables,
-but for a local variable it would appear within a function.
-
- Naturally the register name is cpu-dependent, but this is not a
-problem, since specific registers are most often useful with explicit
-assembler instructions (*note Extended Asm::). Both of these things
-generally require that you conditionalize your program according to cpu
-type.
-
- In addition, operating systems on one type of cpu may differ in how
-they name the registers; then you would need additional conditionals.
-For example, some 68000 operating systems call this register `%a5'.
-
- Defining such a register variable does not reserve the register; it
-remains available for other uses in places where flow control determines
-the variable's value is not live.
-
- This option does not guarantee that GCC will generate code that has
-this variable in the register you specify at all times. You may not
-code an explicit reference to this register in the _assembler
-instruction template_ part of an `asm' statement and assume it will
-always refer to this variable. However, using the variable as an `asm'
-_operand_ guarantees that the specified register is used for the
-operand.
-
- Stores into local register variables may be deleted when they appear
-to be dead according to dataflow analysis. References to local
-register variables may be deleted or moved or simplified.
-
- As for global register variables, it's recommended that you choose a
-register which is normally saved and restored by function calls on your
-machine, so that library routines will not clobber it. A common
-pitfall is to initialize multiple call-clobbered registers with
-arbitrary expressions, where a function call or library call for an
-arithmetic operator will overwrite a register value from a previous
-assignment, for example `r0' below:
- register int *p1 asm ("r0") = ...;
- register int *p2 asm ("r1") = ...;
- In those cases, a solution is to use a temporary variable for each
-arbitrary expression. *Note Example of asm with clobbered asm reg::.
-
-
-File: gcc.info, Node: Alternate Keywords, Next: Incomplete Enums, Prev: Explicit Reg Vars, Up: C Extensions
-
-6.45 Alternate Keywords
-=======================
-
-`-ansi' and the various `-std' options disable certain keywords. This
-causes trouble when you want to use GNU C extensions, or a
-general-purpose header file that should be usable by all programs,
-including ISO C programs. The keywords `asm', `typeof' and `inline'
-are not available in programs compiled with `-ansi' or `-std' (although
-`inline' can be used in a program compiled with `-std=c99' or
-`-std=c1x'). The ISO C99 keyword `restrict' is only available when
-`-std=gnu99' (which will eventually be the default) or `-std=c99' (or
-the equivalent `-std=iso9899:1999'), or an option for a later standard
-version, is used.
-
- The way to solve these problems is to put `__' at the beginning and
-end of each problematical keyword. For example, use `__asm__' instead
-of `asm', and `__inline__' instead of `inline'.
-
- Other C compilers won't accept these alternative keywords; if you want
-to compile with another compiler, you can define the alternate keywords
-as macros to replace them with the customary keywords. It looks like
-this:
-
- #ifndef __GNUC__
- #define __asm__ asm
- #endif
-
- `-pedantic' and other options cause warnings for many GNU C extensions.
-You can prevent such warnings within one expression by writing
-`__extension__' before the expression. `__extension__' has no effect
-aside from this.
-
-
-File: gcc.info, Node: Incomplete Enums, Next: Function Names, Prev: Alternate Keywords, Up: C Extensions
-
-6.46 Incomplete `enum' Types
-============================
-
-You can define an `enum' tag without specifying its possible values.
-This results in an incomplete type, much like what you get if you write
-`struct foo' without describing the elements. A later declaration
-which does specify the possible values completes the type.
-
- You can't allocate variables or storage using the type while it is
-incomplete. However, you can work with pointers to that type.
-
- This extension may not be very useful, but it makes the handling of
-`enum' more consistent with the way `struct' and `union' are handled.
-
- This extension is not supported by GNU C++.
-
-
-File: gcc.info, Node: Function Names, Next: Return Address, Prev: Incomplete Enums, Up: C Extensions
-
-6.47 Function Names as Strings
-==============================
-
-GCC provides three magic variables which hold the name of the current
-function, as a string. The first of these is `__func__', which is part
-of the C99 standard:
-
- The identifier `__func__' is implicitly declared by the translator as
-if, immediately following the opening brace of each function
-definition, the declaration
-
- static const char __func__[] = "function-name";
-
-appeared, where function-name is the name of the lexically-enclosing
-function. This name is the unadorned name of the function.
-
- `__FUNCTION__' is another name for `__func__'. Older versions of GCC
-recognize only this name. However, it is not standardized. For
-maximum portability, we recommend you use `__func__', but provide a
-fallback definition with the preprocessor:
-
- #if __STDC_VERSION__ < 199901L
- # if __GNUC__ >= 2
- # define __func__ __FUNCTION__
- # else
- # define __func__ "<unknown>"
- # endif
- #endif
-
- In C, `__PRETTY_FUNCTION__' is yet another name for `__func__'.
-However, in C++, `__PRETTY_FUNCTION__' contains the type signature of
-the function as well as its bare name. For example, this program:
-
- extern "C" {
- extern int printf (char *, ...);
- }
-
- class a {
- public:
- void sub (int i)
- {
- printf ("__FUNCTION__ = %s\n", __FUNCTION__);
- printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
- }
- };
-
- int
- main (void)
- {
- a ax;
- ax.sub (0);
- return 0;
- }
-
-gives this output:
-
- __FUNCTION__ = sub
- __PRETTY_FUNCTION__ = void a::sub(int)
-
- These identifiers are not preprocessor macros. In GCC 3.3 and
-earlier, in C only, `__FUNCTION__' and `__PRETTY_FUNCTION__' were
-treated as string literals; they could be used to initialize `char'
-arrays, and they could be concatenated with other string literals. GCC
-3.4 and later treat them as variables, like `__func__'. In C++,
-`__FUNCTION__' and `__PRETTY_FUNCTION__' have always been variables.
-
-
-File: gcc.info, Node: Return Address, Next: Vector Extensions, Prev: Function Names, Up: C Extensions
-
-6.48 Getting the Return or Frame Address of a Function
-======================================================
-
-These functions may be used to get information about the callers of a
-function.
-
- -- Built-in Function: void * __builtin_return_address (unsigned int
- LEVEL)
- This function returns the return address of the current function,
- or of one of its callers. The LEVEL argument is number of frames
- to scan up the call stack. A value of `0' yields the return
- address of the current function, a value of `1' yields the return
- address of the caller of the current function, and so forth. When
- inlining the expected behavior is that the function will return
- the address of the function that will be returned to. To work
- around this behavior use the `noinline' function attribute.
-
- The LEVEL argument must be a constant integer.
-
- On some machines it may be impossible to determine the return
- address of any function other than the current one; in such cases,
- or when the top of the stack has been reached, this function will
- return `0' or a random value. In addition,
- `__builtin_frame_address' may be used to determine if the top of
- the stack has been reached.
-
- Additional post-processing of the returned value may be needed, see
- `__builtin_extract_return_address'.
-
- This function should only be used with a nonzero argument for
- debugging purposes.
-
- -- Built-in Function: void * __builtin_extract_return_address (void
- *ADDR)
- The address as returned by `__builtin_return_address' may have to
- be fed through this function to get the actual encoded address.
- For example, on the 31-bit S/390 platform the highest bit has to
- be masked out, or on SPARC platforms an offset has to be added for
- the true next instruction to be executed.
-
- If no fixup is needed, this function simply passes through ADDR.
-
- -- Built-in Function: void * __builtin_frob_return_address (void *ADDR)
- This function does the reverse of
- `__builtin_extract_return_address'.
-
- -- Built-in Function: void * __builtin_frame_address (unsigned int
- LEVEL)
- This function is similar to `__builtin_return_address', but it
- returns the address of the function frame rather than the return
- address of the function. Calling `__builtin_frame_address' with a
- value of `0' yields the frame address of the current function, a
- value of `1' yields the frame address of the caller of the current
- function, and so forth.
-
- The frame is the area on the stack which holds local variables and
- saved registers. The frame address is normally the address of the
- first word pushed on to the stack by the function. However, the
- exact definition depends upon the processor and the calling
- convention. If the processor has a dedicated frame pointer
- register, and the function has a frame, then
- `__builtin_frame_address' will return the value of the frame
- pointer register.
-
- On some machines it may be impossible to determine the frame
- address of any function other than the current one; in such cases,
- or when the top of the stack has been reached, this function will
- return `0' if the first frame pointer is properly initialized by
- the startup code.
-
- This function should only be used with a nonzero argument for
- debugging purposes.
-
-
-File: gcc.info, Node: Vector Extensions, Next: Offsetof, Prev: Return Address, Up: C Extensions
-
-6.49 Using vector instructions through built-in functions
-=========================================================
-
-On some targets, the instruction set contains SIMD vector instructions
-that operate on multiple values contained in one large register at the
-same time. For example, on the i386 the MMX, 3DNow! and SSE extensions
-can be used this way.
-
- The first step in using these extensions is to provide the necessary
-data types. This should be done using an appropriate `typedef':
-
- typedef int v4si __attribute__ ((vector_size (16)));
-
- The `int' type specifies the base type, while the attribute specifies
-the vector size for the variable, measured in bytes. For example, the
-declaration above causes the compiler to set the mode for the `v4si'
-type to be 16 bytes wide and divided into `int' sized units. For a
-32-bit `int' this means a vector of 4 units of 4 bytes, and the
-corresponding mode of `foo' will be V4SI.
-
- The `vector_size' attribute is only applicable to integral and float
-scalars, although arrays, pointers, and function return values are
-allowed in conjunction with this construct.
-
- All the basic integer types can be used as base types, both as signed
-and as unsigned: `char', `short', `int', `long', `long long'. In
-addition, `float' and `double' can be used to build floating-point
-vector types.
-
- Specifying a combination that is not valid for the current architecture
-will cause GCC to synthesize the instructions using a narrower mode.
-For example, if you specify a variable of type `V4SI' and your
-architecture does not allow for this specific SIMD type, GCC will
-produce code that uses 4 `SIs'.
-
- The types defined in this manner can be used with a subset of normal C
-operations. Currently, GCC will allow using the following operators on
-these types: `+, -, *, /, unary minus, ^, |, &, ~, %'.
-
- The operations behave like C++ `valarrays'. Addition is defined as
-the addition of the corresponding elements of the operands. For
-example, in the code below, each of the 4 elements in A will be added
-to the corresponding 4 elements in B and the resulting vector will be
-stored in C.
-
- typedef int v4si __attribute__ ((vector_size (16)));
-
- v4si a, b, c;
-
- c = a + b;
-
- Subtraction, multiplication, division, and the logical operations
-operate in a similar manner. Likewise, the result of using the unary
-minus or complement operators on a vector type is a vector whose
-elements are the negative or complemented values of the corresponding
-elements in the operand.
-
- In C it is possible to use shifting operators `<<', `>>' on
-integer-type vectors. The operation is defined as following: `{a0, a1,
-..., an} >> {b0, b1, ..., bn} == {a0 >> b0, a1 >> b1, ..., an >> bn}'.
-Vector operands must have the same number of elements. Additionally
-second operands can be a scalar integer in which case the scalar is
-converted to the type used by the vector operand (with possible
-truncation) and each element of this new vector is the scalar's value.
-Consider the following code.
-
- typedef int v4si __attribute__ ((vector_size (16)));
-
- v4si a, b;
-
- b = a >> 1; /* b = a >> {1,1,1,1}; */
-
- In C vectors can be subscripted as if the vector were an array with
-the same number of elements and base type. Out of bound accesses
-invoke undefined behavior at runtime. Warnings for out of bound
-accesses for vector subscription can be enabled with `-Warray-bounds'.
-
- You can declare variables and use them in function calls and returns,
-as well as in assignments and some casts. You can specify a vector
-type as a return type for a function. Vector types can also be used as
-function arguments. It is possible to cast from one vector type to
-another, provided they are of the same size (in fact, you can also cast
-vectors to and from other datatypes of the same size).
-
- You cannot operate between vectors of different lengths or different
-signedness without a cast.
-
- A port that supports hardware vector operations, usually provides a set
-of built-in functions that can be used to operate on vectors. For
-example, a function to add two vectors and multiply the result by a
-third could look like this:
-
- v4si f (v4si a, v4si b, v4si c)
- {
- v4si tmp = __builtin_addv4si (a, b);
- return __builtin_mulv4si (tmp, c);
- }
-
-
-File: gcc.info, Node: Offsetof, Next: Atomic Builtins, Prev: Vector Extensions, Up: C Extensions
-
-6.50 Offsetof
-=============
-
-GCC implements for both C and C++ a syntactic extension to implement
-the `offsetof' macro.
-
- primary:
- "__builtin_offsetof" "(" `typename' "," offsetof_member_designator ")"
-
- offsetof_member_designator:
- `identifier'
- | offsetof_member_designator "." `identifier'
- | offsetof_member_designator "[" `expr' "]"
-
- This extension is sufficient such that
-
- #define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)
-
- is a suitable definition of the `offsetof' macro. In C++, TYPE may be
-dependent. In either case, MEMBER may consist of a single identifier,
-or a sequence of member accesses and array references.
-
-
-File: gcc.info, Node: Atomic Builtins, Next: Object Size Checking, Prev: Offsetof, Up: C Extensions
-
-6.51 Built-in functions for atomic memory access
-================================================
-
-The following builtins are intended to be compatible with those
-described in the `Intel Itanium Processor-specific Application Binary
-Interface', section 7.4. As such, they depart from the normal GCC
-practice of using the "__builtin_" prefix, and further that they are
-overloaded such that they work on multiple types.
-
- The definition given in the Intel documentation allows only for the
-use of the types `int', `long', `long long' as well as their unsigned
-counterparts. GCC will allow any integral scalar or pointer type that
-is 1, 2, 4 or 8 bytes in length.
-
- Not all operations are supported by all target processors. If a
-particular operation cannot be implemented on the target processor, a
-warning will be generated and a call an external function will be
-generated. The external function will carry the same name as the
-builtin, with an additional suffix `_N' where N is the size of the data
-type.
-
- In most cases, these builtins are considered a "full barrier". That
-is, no memory operand will be moved across the operation, either
-forward or backward. Further, instructions will be issued as necessary
-to prevent the processor from speculating loads across the operation
-and from queuing stores after the operation.
-
- All of the routines are described in the Intel documentation to take
-"an optional list of variables protected by the memory barrier". It's
-not clear what is meant by that; it could mean that _only_ the
-following variables are protected, or it could mean that these variables
-should in addition be protected. At present GCC ignores this list and
-protects all variables which are globally accessible. If in the future
-we make some use of this list, an empty list will continue to mean all
-globally accessible variables.
-
-`TYPE __sync_fetch_and_add (TYPE *ptr, TYPE value, ...)'
-`TYPE __sync_fetch_and_sub (TYPE *ptr, TYPE value, ...)'
-`TYPE __sync_fetch_and_or (TYPE *ptr, TYPE value, ...)'
-`TYPE __sync_fetch_and_and (TYPE *ptr, TYPE value, ...)'
-`TYPE __sync_fetch_and_xor (TYPE *ptr, TYPE value, ...)'
-`TYPE __sync_fetch_and_nand (TYPE *ptr, TYPE value, ...)'
- These builtins perform the operation suggested by the name, and
- returns the value that had previously been in memory. That is,
-
- { tmp = *ptr; *ptr OP= value; return tmp; }
- { tmp = *ptr; *ptr = ~(tmp & value); return tmp; } // nand
-
- _Note:_ GCC 4.4 and later implement `__sync_fetch_and_nand'
- builtin as `*ptr = ~(tmp & value)' instead of `*ptr = ~tmp &
- value'.
-
-`TYPE __sync_add_and_fetch (TYPE *ptr, TYPE value, ...)'
-`TYPE __sync_sub_and_fetch (TYPE *ptr, TYPE value, ...)'
-`TYPE __sync_or_and_fetch (TYPE *ptr, TYPE value, ...)'
-`TYPE __sync_and_and_fetch (TYPE *ptr, TYPE value, ...)'
-`TYPE __sync_xor_and_fetch (TYPE *ptr, TYPE value, ...)'
-`TYPE __sync_nand_and_fetch (TYPE *ptr, TYPE value, ...)'
- These builtins perform the operation suggested by the name, and
- return the new value. That is,
-
- { *ptr OP= value; return *ptr; }
- { *ptr = ~(*ptr & value); return *ptr; } // nand
-
- _Note:_ GCC 4.4 and later implement `__sync_nand_and_fetch'
- builtin as `*ptr = ~(*ptr & value)' instead of `*ptr = ~*ptr &
- value'.
-
-`bool __sync_bool_compare_and_swap (TYPE *ptr, TYPE oldval TYPE newval, ...)'
-`TYPE __sync_val_compare_and_swap (TYPE *ptr, TYPE oldval TYPE newval, ...)'
- These builtins perform an atomic compare and swap. That is, if
- the current value of `*PTR' is OLDVAL, then write NEWVAL into
- `*PTR'.
-
- The "bool" version returns true if the comparison is successful and
- NEWVAL was written. The "val" version returns the contents of
- `*PTR' before the operation.
-
-`__sync_synchronize (...)'
- This builtin issues a full memory barrier.
-
-`TYPE __sync_lock_test_and_set (TYPE *ptr, TYPE value, ...)'
- This builtin, as described by Intel, is not a traditional
- test-and-set operation, but rather an atomic exchange operation.
- It writes VALUE into `*PTR', and returns the previous contents of
- `*PTR'.
-
- Many targets have only minimal support for such locks, and do not
- support a full exchange operation. In this case, a target may
- support reduced functionality here by which the _only_ valid value
- to store is the immediate constant 1. The exact value actually
- stored in `*PTR' is implementation defined.
-
- This builtin is not a full barrier, but rather an "acquire
- barrier". This means that references after the builtin cannot
- move to (or be speculated to) before the builtin, but previous
- memory stores may not be globally visible yet, and previous memory
- loads may not yet be satisfied.
-
-`void __sync_lock_release (TYPE *ptr, ...)'
- This builtin releases the lock acquired by
- `__sync_lock_test_and_set'. Normally this means writing the
- constant 0 to `*PTR'.
-
- This builtin is not a full barrier, but rather a "release barrier".
- This means that all previous memory stores are globally visible,
- and all previous memory loads have been satisfied, but following
- memory reads are not prevented from being speculated to before the
- barrier.
-
-
-File: gcc.info, Node: Object Size Checking, Next: Other Builtins, Prev: Atomic Builtins, Up: C Extensions
-
-6.52 Object Size Checking Builtins
-==================================
-
-GCC implements a limited buffer overflow protection mechanism that can
-prevent some buffer overflow attacks.
-
- -- Built-in Function: size_t __builtin_object_size (void * PTR, int
- TYPE)
- is a built-in construct that returns a constant number of bytes
- from PTR to the end of the object PTR pointer points to (if known
- at compile time). `__builtin_object_size' never evaluates its
- arguments for side-effects. If there are any side-effects in
- them, it returns `(size_t) -1' for TYPE 0 or 1 and `(size_t) 0'
- for TYPE 2 or 3. If there are multiple objects PTR can point to
- and all of them are known at compile time, the returned number is
- the maximum of remaining byte counts in those objects if TYPE & 2
- is 0 and minimum if nonzero. If it is not possible to determine
- which objects PTR points to at compile time,
- `__builtin_object_size' should return `(size_t) -1' for TYPE 0 or
- 1 and `(size_t) 0' for TYPE 2 or 3.
-
- TYPE is an integer constant from 0 to 3. If the least significant
- bit is clear, objects are whole variables, if it is set, a closest
- surrounding subobject is considered the object a pointer points to.
- The second bit determines if maximum or minimum of remaining bytes
- is computed.
-
- struct V { char buf1[10]; int b; char buf2[10]; } var;
- char *p = &var.buf1[1], *q = &var.b;
-
- /* Here the object p points to is var. */
- assert (__builtin_object_size (p, 0) == sizeof (var) - 1);
- /* The subobject p points to is var.buf1. */
- assert (__builtin_object_size (p, 1) == sizeof (var.buf1) - 1);
- /* The object q points to is var. */
- assert (__builtin_object_size (q, 0)
- == (char *) (&var + 1) - (char *) &var.b);
- /* The subobject q points to is var.b. */
- assert (__builtin_object_size (q, 1) == sizeof (var.b));
-
- There are built-in functions added for many common string operation
-functions, e.g., for `memcpy' `__builtin___memcpy_chk' built-in is
-provided. This built-in has an additional last argument, which is the
-number of bytes remaining in object the DEST argument points to or
-`(size_t) -1' if the size is not known.
-
- The built-in functions are optimized into the normal string functions
-like `memcpy' if the last argument is `(size_t) -1' or if it is known
-at compile time that the destination object will not be overflown. If
-the compiler can determine at compile time the object will be always
-overflown, it issues a warning.
-
- The intended use can be e.g.
-
- #undef memcpy
- #define bos0(dest) __builtin_object_size (dest, 0)
- #define memcpy(dest, src, n) \
- __builtin___memcpy_chk (dest, src, n, bos0 (dest))
-
- char *volatile p;
- char buf[10];
- /* It is unknown what object p points to, so this is optimized
- into plain memcpy - no checking is possible. */
- memcpy (p, "abcde", n);
- /* Destination is known and length too. It is known at compile
- time there will be no overflow. */
- memcpy (&buf[5], "abcde", 5);
- /* Destination is known, but the length is not known at compile time.
- This will result in __memcpy_chk call that can check for overflow
- at runtime. */
- memcpy (&buf[5], "abcde", n);
- /* Destination is known and it is known at compile time there will
- be overflow. There will be a warning and __memcpy_chk call that
- will abort the program at runtime. */
- memcpy (&buf[6], "abcde", 5);
-
- Such built-in functions are provided for `memcpy', `mempcpy',
-`memmove', `memset', `strcpy', `stpcpy', `strncpy', `strcat' and
-`strncat'.
-
- There are also checking built-in functions for formatted output
-functions.
- int __builtin___sprintf_chk (char *s, int flag, size_t os, const char *fmt, ...);
- int __builtin___snprintf_chk (char *s, size_t maxlen, int flag, size_t os,
- const char *fmt, ...);
- int __builtin___vsprintf_chk (char *s, int flag, size_t os, const char *fmt,
- va_list ap);
- int __builtin___vsnprintf_chk (char *s, size_t maxlen, int flag, size_t os,
- const char *fmt, va_list ap);
-
- The added FLAG argument is passed unchanged to `__sprintf_chk' etc.
-functions and can contain implementation specific flags on what
-additional security measures the checking function might take, such as
-handling `%n' differently.
-
- The OS argument is the object size S points to, like in the other
-built-in functions. There is a small difference in the behavior
-though, if OS is `(size_t) -1', the built-in functions are optimized
-into the non-checking functions only if FLAG is 0, otherwise the
-checking function is called with OS argument set to `(size_t) -1'.
-
- In addition to this, there are checking built-in functions
-`__builtin___printf_chk', `__builtin___vprintf_chk',
-`__builtin___fprintf_chk' and `__builtin___vfprintf_chk'. These have
-just one additional argument, FLAG, right before format string FMT. If
-the compiler is able to optimize them to `fputc' etc. functions, it
-will, otherwise the checking function should be called and the FLAG
-argument passed to it.
-
-
-File: gcc.info, Node: Other Builtins, Next: Target Builtins, Prev: Object Size Checking, Up: C Extensions
-
-6.53 Other built-in functions provided by GCC
-=============================================
-
-GCC provides a large number of built-in functions other than the ones
-mentioned above. Some of these are for internal use in the processing
-of exceptions or variable-length argument lists and will not be
-documented here because they may change from time to time; we do not
-recommend general use of these functions.
-
- The remaining functions are provided for optimization purposes.
-
- GCC includes built-in versions of many of the functions in the standard
-C library. The versions prefixed with `__builtin_' will always be
-treated as having the same meaning as the C library function even if you
-specify the `-fno-builtin' option. (*note C Dialect Options::) Many of
-these functions are only optimized in certain cases; if they are not
-optimized in a particular case, a call to the library function will be
-emitted.
-
- Outside strict ISO C mode (`-ansi', `-std=c90', `-std=c99' or
-`-std=c1x'), the functions `_exit', `alloca', `bcmp', `bzero',
-`dcgettext', `dgettext', `dremf', `dreml', `drem', `exp10f', `exp10l',
-`exp10', `ffsll', `ffsl', `ffs', `fprintf_unlocked', `fputs_unlocked',
-`gammaf', `gammal', `gamma', `gammaf_r', `gammal_r', `gamma_r',
-`gettext', `index', `isascii', `j0f', `j0l', `j0', `j1f', `j1l', `j1',
-`jnf', `jnl', `jn', `lgammaf_r', `lgammal_r', `lgamma_r', `mempcpy',
-`pow10f', `pow10l', `pow10', `printf_unlocked', `rindex', `scalbf',
-`scalbl', `scalb', `signbit', `signbitf', `signbitl', `signbitd32',
-`signbitd64', `signbitd128', `significandf', `significandl',
-`significand', `sincosf', `sincosl', `sincos', `stpcpy', `stpncpy',
-`strcasecmp', `strdup', `strfmon', `strncasecmp', `strndup', `toascii',
-`y0f', `y0l', `y0', `y1f', `y1l', `y1', `ynf', `ynl' and `yn' may be
-handled as built-in functions. All these functions have corresponding
-versions prefixed with `__builtin_', which may be used even in strict
-C90 mode.
-
- The ISO C99 functions `_Exit', `acoshf', `acoshl', `acosh', `asinhf',
-`asinhl', `asinh', `atanhf', `atanhl', `atanh', `cabsf', `cabsl',
-`cabs', `cacosf', `cacoshf', `cacoshl', `cacosh', `cacosl', `cacos',
-`cargf', `cargl', `carg', `casinf', `casinhf', `casinhl', `casinh',
-`casinl', `casin', `catanf', `catanhf', `catanhl', `catanh', `catanl',
-`catan', `cbrtf', `cbrtl', `cbrt', `ccosf', `ccoshf', `ccoshl',
-`ccosh', `ccosl', `ccos', `cexpf', `cexpl', `cexp', `cimagf', `cimagl',
-`cimag', `clogf', `clogl', `clog', `conjf', `conjl', `conj',
-`copysignf', `copysignl', `copysign', `cpowf', `cpowl', `cpow',
-`cprojf', `cprojl', `cproj', `crealf', `creall', `creal', `csinf',
-`csinhf', `csinhl', `csinh', `csinl', `csin', `csqrtf', `csqrtl',
-`csqrt', `ctanf', `ctanhf', `ctanhl', `ctanh', `ctanl', `ctan',
-`erfcf', `erfcl', `erfc', `erff', `erfl', `erf', `exp2f', `exp2l',
-`exp2', `expm1f', `expm1l', `expm1', `fdimf', `fdiml', `fdim', `fmaf',
-`fmal', `fmaxf', `fmaxl', `fmax', `fma', `fminf', `fminl', `fmin',
-`hypotf', `hypotl', `hypot', `ilogbf', `ilogbl', `ilogb', `imaxabs',
-`isblank', `iswblank', `lgammaf', `lgammal', `lgamma', `llabs',
-`llrintf', `llrintl', `llrint', `llroundf', `llroundl', `llround',
-`log1pf', `log1pl', `log1p', `log2f', `log2l', `log2', `logbf',
-`logbl', `logb', `lrintf', `lrintl', `lrint', `lroundf', `lroundl',
-`lround', `nearbyintf', `nearbyintl', `nearbyint', `nextafterf',
-`nextafterl', `nextafter', `nexttowardf', `nexttowardl', `nexttoward',
-`remainderf', `remainderl', `remainder', `remquof', `remquol',
-`remquo', `rintf', `rintl', `rint', `roundf', `roundl', `round',
-`scalblnf', `scalblnl', `scalbln', `scalbnf', `scalbnl', `scalbn',
-`snprintf', `tgammaf', `tgammal', `tgamma', `truncf', `truncl', `trunc',
-`vfscanf', `vscanf', `vsnprintf' and `vsscanf' are handled as built-in
-functions except in strict ISO C90 mode (`-ansi' or `-std=c90').
-
- There are also built-in versions of the ISO C99 functions `acosf',
-`acosl', `asinf', `asinl', `atan2f', `atan2l', `atanf', `atanl',
-`ceilf', `ceill', `cosf', `coshf', `coshl', `cosl', `expf', `expl',
-`fabsf', `fabsl', `floorf', `floorl', `fmodf', `fmodl', `frexpf',
-`frexpl', `ldexpf', `ldexpl', `log10f', `log10l', `logf', `logl',
-`modfl', `modf', `powf', `powl', `sinf', `sinhf', `sinhl', `sinl',
-`sqrtf', `sqrtl', `tanf', `tanhf', `tanhl' and `tanl' that are
-recognized in any mode since ISO C90 reserves these names for the
-purpose to which ISO C99 puts them. All these functions have
-corresponding versions prefixed with `__builtin_'.
-
- The ISO C94 functions `iswalnum', `iswalpha', `iswcntrl', `iswdigit',
-`iswgraph', `iswlower', `iswprint', `iswpunct', `iswspace', `iswupper',
-`iswxdigit', `towlower' and `towupper' are handled as built-in functions
-except in strict ISO C90 mode (`-ansi' or `-std=c90').
-
- The ISO C90 functions `abort', `abs', `acos', `asin', `atan2', `atan',
-`calloc', `ceil', `cosh', `cos', `exit', `exp', `fabs', `floor', `fmod',
-`fprintf', `fputs', `frexp', `fscanf', `isalnum', `isalpha', `iscntrl',
-`isdigit', `isgraph', `islower', `isprint', `ispunct', `isspace',
-`isupper', `isxdigit', `tolower', `toupper', `labs', `ldexp', `log10',
-`log', `malloc', `memchr', `memcmp', `memcpy', `memset', `modf', `pow',
-`printf', `putchar', `puts', `scanf', `sinh', `sin', `snprintf',
-`sprintf', `sqrt', `sscanf', `strcat', `strchr', `strcmp', `strcpy',
-`strcspn', `strlen', `strncat', `strncmp', `strncpy', `strpbrk',
-`strrchr', `strspn', `strstr', `tanh', `tan', `vfprintf', `vprintf' and
-`vsprintf' are all recognized as built-in functions unless
-`-fno-builtin' is specified (or `-fno-builtin-FUNCTION' is specified
-for an individual function). All of these functions have corresponding
-versions prefixed with `__builtin_'.
-
- GCC provides built-in versions of the ISO C99 floating point comparison
-macros that avoid raising exceptions for unordered operands. They have
-the same names as the standard macros ( `isgreater', `isgreaterequal',
-`isless', `islessequal', `islessgreater', and `isunordered') , with
-`__builtin_' prefixed. We intend for a library implementor to be able
-to simply `#define' each standard macro to its built-in equivalent. In
-the same fashion, GCC provides `fpclassify', `isfinite', `isinf_sign'
-and `isnormal' built-ins used with `__builtin_' prefixed. The `isinf'
-and `isnan' builtins appear both with and without the `__builtin_'
-prefix.
-
- -- Built-in Function: int __builtin_types_compatible_p (TYPE1, TYPE2)
- You can use the built-in function `__builtin_types_compatible_p' to
- determine whether two types are the same.
-
- This built-in function returns 1 if the unqualified versions of the
- types TYPE1 and TYPE2 (which are types, not expressions) are
- compatible, 0 otherwise. The result of this built-in function can
- be used in integer constant expressions.
-
- This built-in function ignores top level qualifiers (e.g., `const',
- `volatile'). For example, `int' is equivalent to `const int'.
-
- The type `int[]' and `int[5]' are compatible. On the other hand,
- `int' and `char *' are not compatible, even if the size of their
- types, on the particular architecture are the same. Also, the
- amount of pointer indirection is taken into account when
- determining similarity. Consequently, `short *' is not similar to
- `short **'. Furthermore, two types that are typedefed are
- considered compatible if their underlying types are compatible.
-
- An `enum' type is not considered to be compatible with another
- `enum' type even if both are compatible with the same integer
- type; this is what the C standard specifies. For example, `enum
- {foo, bar}' is not similar to `enum {hot, dog}'.
-
- You would typically use this function in code whose execution
- varies depending on the arguments' types. For example:
-
- #define foo(x) \
- ({ \
- typeof (x) tmp = (x); \
- if (__builtin_types_compatible_p (typeof (x), long double)) \
- tmp = foo_long_double (tmp); \
- else if (__builtin_types_compatible_p (typeof (x), double)) \
- tmp = foo_double (tmp); \
- else if (__builtin_types_compatible_p (typeof (x), float)) \
- tmp = foo_float (tmp); \
- else \
- abort (); \
- tmp; \
- })
-
- _Note:_ This construct is only available for C.
-
-
- -- Built-in Function: TYPE __builtin_choose_expr (CONST_EXP, EXP1,
- EXP2)
- You can use the built-in function `__builtin_choose_expr' to
- evaluate code depending on the value of a constant expression.
- This built-in function returns EXP1 if CONST_EXP, which is an
- integer constant expression, is nonzero. Otherwise it returns
- EXP2.
-
- This built-in function is analogous to the `? :' operator in C,
- except that the expression returned has its type unaltered by
- promotion rules. Also, the built-in function does not evaluate
- the expression that was not chosen. For example, if CONST_EXP
- evaluates to true, EXP2 is not evaluated even if it has
- side-effects.
-
- This built-in function can return an lvalue if the chosen argument
- is an lvalue.
-
- If EXP1 is returned, the return type is the same as EXP1's type.
- Similarly, if EXP2 is returned, its return type is the same as
- EXP2.
-
- Example:
-
- #define foo(x) \
- __builtin_choose_expr ( \
- __builtin_types_compatible_p (typeof (x), double), \
- foo_double (x), \
- __builtin_choose_expr ( \
- __builtin_types_compatible_p (typeof (x), float), \
- foo_float (x), \
- /* The void expression results in a compile-time error \
- when assigning the result to something. */ \
- (void)0))
-
- _Note:_ This construct is only available for C. Furthermore, the
- unused expression (EXP1 or EXP2 depending on the value of
- CONST_EXP) may still generate syntax errors. This may change in
- future revisions.
-
-
- -- Built-in Function: int __builtin_constant_p (EXP)
- You can use the built-in function `__builtin_constant_p' to
- determine if a value is known to be constant at compile-time and
- hence that GCC can perform constant-folding on expressions
- involving that value. The argument of the function is the value
- to test. The function returns the integer 1 if the argument is
- known to be a compile-time constant and 0 if it is not known to be
- a compile-time constant. A return of 0 does not indicate that the
- value is _not_ a constant, but merely that GCC cannot prove it is
- a constant with the specified value of the `-O' option.
-
- You would typically use this function in an embedded application
- where memory was a critical resource. If you have some complex
- calculation, you may want it to be folded if it involves
- constants, but need to call a function if it does not. For
- example:
-
- #define Scale_Value(X) \
- (__builtin_constant_p (X) \
- ? ((X) * SCALE + OFFSET) : Scale (X))
-
- You may use this built-in function in either a macro or an inline
- function. However, if you use it in an inlined function and pass
- an argument of the function as the argument to the built-in, GCC
- will never return 1 when you call the inline function with a
- string constant or compound literal (*note Compound Literals::)
- and will not return 1 when you pass a constant numeric value to
- the inline function unless you specify the `-O' option.
-
- You may also use `__builtin_constant_p' in initializers for static
- data. For instance, you can write
-
- static const int table[] = {
- __builtin_constant_p (EXPRESSION) ? (EXPRESSION) : -1,
- /* ... */
- };
-
- This is an acceptable initializer even if EXPRESSION is not a
- constant expression, including the case where
- `__builtin_constant_p' returns 1 because EXPRESSION can be folded
- to a constant but EXPRESSION contains operands that would not
- otherwise be permitted in a static initializer (for example, `0 &&
- foo ()'). GCC must be more conservative about evaluating the
- built-in in this case, because it has no opportunity to perform
- optimization.
-
- Previous versions of GCC did not accept this built-in in data
- initializers. The earliest version where it is completely safe is
- 3.0.1.
-
- -- Built-in Function: long __builtin_expect (long EXP, long C)
- You may use `__builtin_expect' to provide the compiler with branch
- prediction information. In general, you should prefer to use
- actual profile feedback for this (`-fprofile-arcs'), as
- programmers are notoriously bad at predicting how their programs
- actually perform. However, there are applications in which this
- data is hard to collect.
-
- The return value is the value of EXP, which should be an integral
- expression. The semantics of the built-in are that it is expected
- that EXP == C. For example:
-
- if (__builtin_expect (x, 0))
- foo ();
-
- would indicate that we do not expect to call `foo', since we
- expect `x' to be zero. Since you are limited to integral
- expressions for EXP, you should use constructions such as
-
- if (__builtin_expect (ptr != NULL, 1))
- error ();
-
- when testing pointer or floating-point values.
-
- -- Built-in Function: void __builtin_trap (void)
- This function causes the program to exit abnormally. GCC
- implements this function by using a target-dependent mechanism
- (such as intentionally executing an illegal instruction) or by
- calling `abort'. The mechanism used may vary from release to
- release so you should not rely on any particular implementation.
-
- -- Built-in Function: void __builtin_unreachable (void)
- If control flow reaches the point of the `__builtin_unreachable',
- the program is undefined. It is useful in situations where the
- compiler cannot deduce the unreachability of the code.
-
- One such case is immediately following an `asm' statement that
- will either never terminate, or one that transfers control
- elsewhere and never returns. In this example, without the
- `__builtin_unreachable', GCC would issue a warning that control
- reaches the end of a non-void function. It would also generate
- code to return after the `asm'.
-
- int f (int c, int v)
- {
- if (c)
- {
- return v;
- }
- else
- {
- asm("jmp error_handler");
- __builtin_unreachable ();
- }
- }
-
- Because the `asm' statement unconditionally transfers control out
- of the function, control will never reach the end of the function
- body. The `__builtin_unreachable' is in fact unreachable and
- communicates this fact to the compiler.
-
- Another use for `__builtin_unreachable' is following a call a
- function that never returns but that is not declared
- `__attribute__((noreturn))', as in this example:
-
- void function_that_never_returns (void);
-
- int g (int c)
- {
- if (c)
- {
- return 1;
- }
- else
- {
- function_that_never_returns ();
- __builtin_unreachable ();
- }
- }
-
-
- -- Built-in Function: void __builtin___clear_cache (char *BEGIN, char
- *END)
- This function is used to flush the processor's instruction cache
- for the region of memory between BEGIN inclusive and END
- exclusive. Some targets require that the instruction cache be
- flushed, after modifying memory containing code, in order to obtain
- deterministic behavior.
-
- If the target does not require instruction cache flushes,
- `__builtin___clear_cache' has no effect. Otherwise either
- instructions are emitted in-line to clear the instruction cache or
- a call to the `__clear_cache' function in libgcc is made.
-
- -- Built-in Function: void __builtin_prefetch (const void *ADDR, ...)
- This function is used to minimize cache-miss latency by moving
- data into a cache before it is accessed. You can insert calls to
- `__builtin_prefetch' into code for which you know addresses of
- data in memory that is likely to be accessed soon. If the target
- supports them, data prefetch instructions will be generated. If
- the prefetch is done early enough before the access then the data
- will be in the cache by the time it is accessed.
-
- The value of ADDR is the address of the memory to prefetch. There
- are two optional arguments, RW and LOCALITY. The value of RW is a
- compile-time constant one or zero; one means that the prefetch is
- preparing for a write to the memory address and zero, the default,
- means that the prefetch is preparing for a read. The value
- LOCALITY must be a compile-time constant integer between zero and
- three. A value of zero means that the data has no temporal
- locality, so it need not be left in the cache after the access. A
- value of three means that the data has a high degree of temporal
- locality and should be left in all levels of cache possible.
- Values of one and two mean, respectively, a low or moderate degree
- of temporal locality. The default is three.
-
- for (i = 0; i < n; i++)
- {
- a[i] = a[i] + b[i];
- __builtin_prefetch (&a[i+j], 1, 1);
- __builtin_prefetch (&b[i+j], 0, 1);
- /* ... */
- }
-
- Data prefetch does not generate faults if ADDR is invalid, but the
- address expression itself must be valid. For example, a prefetch
- of `p->next' will not fault if `p->next' is not a valid address,
- but evaluation will fault if `p' is not a valid address.
-
- If the target does not support data prefetch, the address
- expression is evaluated if it includes side effects but no other
- code is generated and GCC does not issue a warning.
-
- -- Built-in Function: double __builtin_huge_val (void)
- Returns a positive infinity, if supported by the floating-point
- format, else `DBL_MAX'. This function is suitable for
- implementing the ISO C macro `HUGE_VAL'.
-
- -- Built-in Function: float __builtin_huge_valf (void)
- Similar to `__builtin_huge_val', except the return type is `float'.
-
- -- Built-in Function: long double __builtin_huge_vall (void)
- Similar to `__builtin_huge_val', except the return type is `long
- double'.
-
- -- Built-in Function: int __builtin_fpclassify (int, int, int, int,
- int, ...)
- This built-in implements the C99 fpclassify functionality. The
- first five int arguments should be the target library's notion of
- the possible FP classes and are used for return values. They must
- be constant values and they must appear in this order: `FP_NAN',
- `FP_INFINITE', `FP_NORMAL', `FP_SUBNORMAL' and `FP_ZERO'. The
- ellipsis is for exactly one floating point value to classify. GCC
- treats the last argument as type-generic, which means it does not
- do default promotion from float to double.
-
- -- Built-in Function: double __builtin_inf (void)
- Similar to `__builtin_huge_val', except a warning is generated if
- the target floating-point format does not support infinities.
-
- -- Built-in Function: _Decimal32 __builtin_infd32 (void)
- Similar to `__builtin_inf', except the return type is `_Decimal32'.
-
- -- Built-in Function: _Decimal64 __builtin_infd64 (void)
- Similar to `__builtin_inf', except the return type is `_Decimal64'.
-
- -- Built-in Function: _Decimal128 __builtin_infd128 (void)
- Similar to `__builtin_inf', except the return type is
- `_Decimal128'.
-
- -- Built-in Function: float __builtin_inff (void)
- Similar to `__builtin_inf', except the return type is `float'.
- This function is suitable for implementing the ISO C99 macro
- `INFINITY'.
-
- -- Built-in Function: long double __builtin_infl (void)
- Similar to `__builtin_inf', except the return type is `long
- double'.
-
- -- Built-in Function: int __builtin_isinf_sign (...)
- Similar to `isinf', except the return value will be negative for
- an argument of `-Inf'. Note while the parameter list is an
- ellipsis, this function only accepts exactly one floating point
- argument. GCC treats this parameter as type-generic, which means
- it does not do default promotion from float to double.
-
- -- Built-in Function: double __builtin_nan (const char *str)
- This is an implementation of the ISO C99 function `nan'.
-
- Since ISO C99 defines this function in terms of `strtod', which we
- do not implement, a description of the parsing is in order. The
- string is parsed as by `strtol'; that is, the base is recognized by
- leading `0' or `0x' prefixes. The number parsed is placed in the
- significand such that the least significant bit of the number is
- at the least significant bit of the significand. The number is
- truncated to fit the significand field provided. The significand
- is forced to be a quiet NaN.
-
- This function, if given a string literal all of which would have
- been consumed by strtol, is evaluated early enough that it is
- considered a compile-time constant.
-
- -- Built-in Function: _Decimal32 __builtin_nand32 (const char *str)
- Similar to `__builtin_nan', except the return type is `_Decimal32'.
-
- -- Built-in Function: _Decimal64 __builtin_nand64 (const char *str)
- Similar to `__builtin_nan', except the return type is `_Decimal64'.
-
- -- Built-in Function: _Decimal128 __builtin_nand128 (const char *str)
- Similar to `__builtin_nan', except the return type is
- `_Decimal128'.
-
- -- Built-in Function: float __builtin_nanf (const char *str)
- Similar to `__builtin_nan', except the return type is `float'.
-
- -- Built-in Function: long double __builtin_nanl (const char *str)
- Similar to `__builtin_nan', except the return type is `long
- double'.
-
- -- Built-in Function: double __builtin_nans (const char *str)
- Similar to `__builtin_nan', except the significand is forced to be
- a signaling NaN. The `nans' function is proposed by WG14 N965.
-
- -- Built-in Function: float __builtin_nansf (const char *str)
- Similar to `__builtin_nans', except the return type is `float'.
-
- -- Built-in Function: long double __builtin_nansl (const char *str)
- Similar to `__builtin_nans', except the return type is `long
- double'.
-
- -- Built-in Function: int __builtin_ffs (unsigned int x)
- Returns one plus the index of the least significant 1-bit of X, or
- if X is zero, returns zero.
-
- -- Built-in Function: int __builtin_clz (unsigned int x)
- Returns the number of leading 0-bits in X, starting at the most
- significant bit position. If X is 0, the result is undefined.
-
- -- Built-in Function: int __builtin_ctz (unsigned int x)
- Returns the number of trailing 0-bits in X, starting at the least
- significant bit position. If X is 0, the result is undefined.
-
- -- Built-in Function: int __builtin_popcount (unsigned int x)
- Returns the number of 1-bits in X.
-
- -- Built-in Function: int __builtin_parity (unsigned int x)
- Returns the parity of X, i.e. the number of 1-bits in X modulo 2.
-
- -- Built-in Function: int __builtin_ffsl (unsigned long)
- Similar to `__builtin_ffs', except the argument type is `unsigned
- long'.
-
- -- Built-in Function: int __builtin_clzl (unsigned long)
- Similar to `__builtin_clz', except the argument type is `unsigned
- long'.
-
- -- Built-in Function: int __builtin_ctzl (unsigned long)
- Similar to `__builtin_ctz', except the argument type is `unsigned
- long'.
-
- -- Built-in Function: int __builtin_popcountl (unsigned long)
- Similar to `__builtin_popcount', except the argument type is
- `unsigned long'.
-
- -- Built-in Function: int __builtin_parityl (unsigned long)
- Similar to `__builtin_parity', except the argument type is
- `unsigned long'.
-
- -- Built-in Function: int __builtin_ffsll (unsigned long long)
- Similar to `__builtin_ffs', except the argument type is `unsigned
- long long'.
-
- -- Built-in Function: int __builtin_clzll (unsigned long long)
- Similar to `__builtin_clz', except the argument type is `unsigned
- long long'.
-
- -- Built-in Function: int __builtin_ctzll (unsigned long long)
- Similar to `__builtin_ctz', except the argument type is `unsigned
- long long'.
-
- -- Built-in Function: int __builtin_popcountll (unsigned long long)
- Similar to `__builtin_popcount', except the argument type is
- `unsigned long long'.
-
- -- Built-in Function: int __builtin_parityll (unsigned long long)
- Similar to `__builtin_parity', except the argument type is
- `unsigned long long'.
-
- -- Built-in Function: double __builtin_powi (double, int)
- Returns the first argument raised to the power of the second.
- Unlike the `pow' function no guarantees about precision and
- rounding are made.
-
- -- Built-in Function: float __builtin_powif (float, int)
- Similar to `__builtin_powi', except the argument and return types
- are `float'.
-
- -- Built-in Function: long double __builtin_powil (long double, int)
- Similar to `__builtin_powi', except the argument and return types
- are `long double'.
-
- -- Built-in Function: int32_t __builtin_bswap32 (int32_t x)
- Returns X with the order of the bytes reversed; for example,
- `0xaabbccdd' becomes `0xddccbbaa'. Byte here always means exactly
- 8 bits.
-
- -- Built-in Function: int64_t __builtin_bswap64 (int64_t x)
- Similar to `__builtin_bswap32', except the argument and return
- types are 64-bit.
-
-
-File: gcc.info, Node: Target Builtins, Next: Target Format Checks, Prev: Other Builtins, Up: C Extensions
-
-6.54 Built-in Functions Specific to Particular Target Machines
-==============================================================
-
-On some target machines, GCC supports many built-in functions specific
-to those machines. Generally these generate calls to specific machine
-instructions, but allow the compiler to schedule those calls.
-
-* Menu:
-
-* Alpha Built-in Functions::
-* ARM iWMMXt Built-in Functions::
-* ARM NEON Intrinsics::
-* Blackfin Built-in Functions::
-* FR-V Built-in Functions::
-* X86 Built-in Functions::
-* MIPS DSP Built-in Functions::
-* MIPS Paired-Single Support::
-* MIPS Loongson Built-in Functions::
-* Other MIPS Built-in Functions::
-* picoChip Built-in Functions::
-* PowerPC AltiVec/VSX Built-in Functions::
-* RX Built-in Functions::
-* SPARC VIS Built-in Functions::
-* SPU Built-in Functions::
-
-
-File: gcc.info, Node: Alpha Built-in Functions, Next: ARM iWMMXt Built-in Functions, Up: Target Builtins
-
-6.54.1 Alpha Built-in Functions
--------------------------------
-
-These built-in functions are available for the Alpha family of
-processors, depending on the command-line switches used.
-
- The following built-in functions are always available. They all
-generate the machine instruction that is part of the name.
-
- long __builtin_alpha_implver (void)
- long __builtin_alpha_rpcc (void)
- long __builtin_alpha_amask (long)
- long __builtin_alpha_cmpbge (long, long)
- long __builtin_alpha_extbl (long, long)
- long __builtin_alpha_extwl (long, long)
- long __builtin_alpha_extll (long, long)
- long __builtin_alpha_extql (long, long)
- long __builtin_alpha_extwh (long, long)
- long __builtin_alpha_extlh (long, long)
- long __builtin_alpha_extqh (long, long)
- long __builtin_alpha_insbl (long, long)
- long __builtin_alpha_inswl (long, long)
- long __builtin_alpha_insll (long, long)
- long __builtin_alpha_insql (long, long)
- long __builtin_alpha_inswh (long, long)
- long __builtin_alpha_inslh (long, long)
- long __builtin_alpha_insqh (long, long)
- long __builtin_alpha_mskbl (long, long)
- long __builtin_alpha_mskwl (long, long)
- long __builtin_alpha_mskll (long, long)
- long __builtin_alpha_mskql (long, long)
- long __builtin_alpha_mskwh (long, long)
- long __builtin_alpha_msklh (long, long)
- long __builtin_alpha_mskqh (long, long)
- long __builtin_alpha_umulh (long, long)
- long __builtin_alpha_zap (long, long)
- long __builtin_alpha_zapnot (long, long)
-
- The following built-in functions are always with `-mmax' or
-`-mcpu=CPU' where CPU is `pca56' or later. They all generate the
-machine instruction that is part of the name.
-
- long __builtin_alpha_pklb (long)
- long __builtin_alpha_pkwb (long)
- long __builtin_alpha_unpkbl (long)
- long __builtin_alpha_unpkbw (long)
- long __builtin_alpha_minub8 (long, long)
- long __builtin_alpha_minsb8 (long, long)
- long __builtin_alpha_minuw4 (long, long)
- long __builtin_alpha_minsw4 (long, long)
- long __builtin_alpha_maxub8 (long, long)
- long __builtin_alpha_maxsb8 (long, long)
- long __builtin_alpha_maxuw4 (long, long)
- long __builtin_alpha_maxsw4 (long, long)
- long __builtin_alpha_perr (long, long)
-
- The following built-in functions are always with `-mcix' or
-`-mcpu=CPU' where CPU is `ev67' or later. They all generate the
-machine instruction that is part of the name.
-
- long __builtin_alpha_cttz (long)
- long __builtin_alpha_ctlz (long)
- long __builtin_alpha_ctpop (long)
-
- The following builtins are available on systems that use the OSF/1
-PALcode. Normally they invoke the `rduniq' and `wruniq' PAL calls, but
-when invoked with `-mtls-kernel', they invoke `rdval' and `wrval'.
-
- void *__builtin_thread_pointer (void)
- void __builtin_set_thread_pointer (void *)
-
-
-File: gcc.info, Node: ARM iWMMXt Built-in Functions, Next: ARM NEON Intrinsics, Prev: Alpha Built-in Functions, Up: Target Builtins
-
-6.54.2 ARM iWMMXt Built-in Functions
-------------------------------------
-
-These built-in functions are available for the ARM family of processors
-when the `-mcpu=iwmmxt' switch is used:
-
- typedef int v2si __attribute__ ((vector_size (8)));
- typedef short v4hi __attribute__ ((vector_size (8)));
- typedef char v8qi __attribute__ ((vector_size (8)));
-
- int __builtin_arm_getwcx (int)
- void __builtin_arm_setwcx (int, int)
- int __builtin_arm_textrmsb (v8qi, int)
- int __builtin_arm_textrmsh (v4hi, int)
- int __builtin_arm_textrmsw (v2si, int)
- int __builtin_arm_textrmub (v8qi, int)
- int __builtin_arm_textrmuh (v4hi, int)
- int __builtin_arm_textrmuw (v2si, int)
- v8qi __builtin_arm_tinsrb (v8qi, int)
- v4hi __builtin_arm_tinsrh (v4hi, int)
- v2si __builtin_arm_tinsrw (v2si, int)
- long long __builtin_arm_tmia (long long, int, int)
- long long __builtin_arm_tmiabb (long long, int, int)
- long long __builtin_arm_tmiabt (long long, int, int)
- long long __builtin_arm_tmiaph (long long, int, int)
- long long __builtin_arm_tmiatb (long long, int, int)
- long long __builtin_arm_tmiatt (long long, int, int)
- int __builtin_arm_tmovmskb (v8qi)
- int __builtin_arm_tmovmskh (v4hi)
- int __builtin_arm_tmovmskw (v2si)
- long long __builtin_arm_waccb (v8qi)
- long long __builtin_arm_wacch (v4hi)
- long long __builtin_arm_waccw (v2si)
- v8qi __builtin_arm_waddb (v8qi, v8qi)
- v8qi __builtin_arm_waddbss (v8qi, v8qi)
- v8qi __builtin_arm_waddbus (v8qi, v8qi)
- v4hi __builtin_arm_waddh (v4hi, v4hi)
- v4hi __builtin_arm_waddhss (v4hi, v4hi)
- v4hi __builtin_arm_waddhus (v4hi, v4hi)
- v2si __builtin_arm_waddw (v2si, v2si)
- v2si __builtin_arm_waddwss (v2si, v2si)
- v2si __builtin_arm_waddwus (v2si, v2si)
- v8qi __builtin_arm_walign (v8qi, v8qi, int)
- long long __builtin_arm_wand(long long, long long)
- long long __builtin_arm_wandn (long long, long long)
- v8qi __builtin_arm_wavg2b (v8qi, v8qi)
- v8qi __builtin_arm_wavg2br (v8qi, v8qi)
- v4hi __builtin_arm_wavg2h (v4hi, v4hi)
- v4hi __builtin_arm_wavg2hr (v4hi, v4hi)
- v8qi __builtin_arm_wcmpeqb (v8qi, v8qi)
- v4hi __builtin_arm_wcmpeqh (v4hi, v4hi)
- v2si __builtin_arm_wcmpeqw (v2si, v2si)
- v8qi __builtin_arm_wcmpgtsb (v8qi, v8qi)
- v4hi __builtin_arm_wcmpgtsh (v4hi, v4hi)
- v2si __builtin_arm_wcmpgtsw (v2si, v2si)
- v8qi __builtin_arm_wcmpgtub (v8qi, v8qi)
- v4hi __builtin_arm_wcmpgtuh (v4hi, v4hi)
- v2si __builtin_arm_wcmpgtuw (v2si, v2si)
- long long __builtin_arm_wmacs (long long, v4hi, v4hi)
- long long __builtin_arm_wmacsz (v4hi, v4hi)
- long long __builtin_arm_wmacu (long long, v4hi, v4hi)
- long long __builtin_arm_wmacuz (v4hi, v4hi)
- v4hi __builtin_arm_wmadds (v4hi, v4hi)
- v4hi __builtin_arm_wmaddu (v4hi, v4hi)
- v8qi __builtin_arm_wmaxsb (v8qi, v8qi)
- v4hi __builtin_arm_wmaxsh (v4hi, v4hi)
- v2si __builtin_arm_wmaxsw (v2si, v2si)
- v8qi __builtin_arm_wmaxub (v8qi, v8qi)
- v4hi __builtin_arm_wmaxuh (v4hi, v4hi)
- v2si __builtin_arm_wmaxuw (v2si, v2si)
- v8qi __builtin_arm_wminsb (v8qi, v8qi)
- v4hi __builtin_arm_wminsh (v4hi, v4hi)
- v2si __builtin_arm_wminsw (v2si, v2si)
- v8qi __builtin_arm_wminub (v8qi, v8qi)
- v4hi __builtin_arm_wminuh (v4hi, v4hi)
- v2si __builtin_arm_wminuw (v2si, v2si)
- v4hi __builtin_arm_wmulsm (v4hi, v4hi)
- v4hi __builtin_arm_wmulul (v4hi, v4hi)
- v4hi __builtin_arm_wmulum (v4hi, v4hi)
- long long __builtin_arm_wor (long long, long long)
- v2si __builtin_arm_wpackdss (long long, long long)
- v2si __builtin_arm_wpackdus (long long, long long)
- v8qi __builtin_arm_wpackhss (v4hi, v4hi)
- v8qi __builtin_arm_wpackhus (v4hi, v4hi)
- v4hi __builtin_arm_wpackwss (v2si, v2si)
- v4hi __builtin_arm_wpackwus (v2si, v2si)
- long long __builtin_arm_wrord (long long, long long)
- long long __builtin_arm_wrordi (long long, int)
- v4hi __builtin_arm_wrorh (v4hi, long long)
- v4hi __builtin_arm_wrorhi (v4hi, int)
- v2si __builtin_arm_wrorw (v2si, long long)
- v2si __builtin_arm_wrorwi (v2si, int)
- v2si __builtin_arm_wsadb (v8qi, v8qi)
- v2si __builtin_arm_wsadbz (v8qi, v8qi)
- v2si __builtin_arm_wsadh (v4hi, v4hi)
- v2si __builtin_arm_wsadhz (v4hi, v4hi)
- v4hi __builtin_arm_wshufh (v4hi, int)
- long long __builtin_arm_wslld (long long, long long)
- long long __builtin_arm_wslldi (long long, int)
- v4hi __builtin_arm_wsllh (v4hi, long long)
- v4hi __builtin_arm_wsllhi (v4hi, int)
- v2si __builtin_arm_wsllw (v2si, long long)
- v2si __builtin_arm_wsllwi (v2si, int)
- long long __builtin_arm_wsrad (long long, long long)
- long long __builtin_arm_wsradi (long long, int)
- v4hi __builtin_arm_wsrah (v4hi, long long)
- v4hi __builtin_arm_wsrahi (v4hi, int)
- v2si __builtin_arm_wsraw (v2si, long long)
- v2si __builtin_arm_wsrawi (v2si, int)
- long long __builtin_arm_wsrld (long long, long long)
- long long __builtin_arm_wsrldi (long long, int)
- v4hi __builtin_arm_wsrlh (v4hi, long long)
- v4hi __builtin_arm_wsrlhi (v4hi, int)
- v2si __builtin_arm_wsrlw (v2si, long long)
- v2si __builtin_arm_wsrlwi (v2si, int)
- v8qi __builtin_arm_wsubb (v8qi, v8qi)
- v8qi __builtin_arm_wsubbss (v8qi, v8qi)
- v8qi __builtin_arm_wsubbus (v8qi, v8qi)
- v4hi __builtin_arm_wsubh (v4hi, v4hi)
- v4hi __builtin_arm_wsubhss (v4hi, v4hi)
- v4hi __builtin_arm_wsubhus (v4hi, v4hi)
- v2si __builtin_arm_wsubw (v2si, v2si)
- v2si __builtin_arm_wsubwss (v2si, v2si)
- v2si __builtin_arm_wsubwus (v2si, v2si)
- v4hi __builtin_arm_wunpckehsb (v8qi)
- v2si __builtin_arm_wunpckehsh (v4hi)
- long long __builtin_arm_wunpckehsw (v2si)
- v4hi __builtin_arm_wunpckehub (v8qi)
- v2si __builtin_arm_wunpckehuh (v4hi)
- long long __builtin_arm_wunpckehuw (v2si)
- v4hi __builtin_arm_wunpckelsb (v8qi)
- v2si __builtin_arm_wunpckelsh (v4hi)
- long long __builtin_arm_wunpckelsw (v2si)
- v4hi __builtin_arm_wunpckelub (v8qi)
- v2si __builtin_arm_wunpckeluh (v4hi)
- long long __builtin_arm_wunpckeluw (v2si)
- v8qi __builtin_arm_wunpckihb (v8qi, v8qi)
- v4hi __builtin_arm_wunpckihh (v4hi, v4hi)
- v2si __builtin_arm_wunpckihw (v2si, v2si)
- v8qi __builtin_arm_wunpckilb (v8qi, v8qi)
- v4hi __builtin_arm_wunpckilh (v4hi, v4hi)
- v2si __builtin_arm_wunpckilw (v2si, v2si)
- long long __builtin_arm_wxor (long long, long long)
- long long __builtin_arm_wzero ()
-
-
-File: gcc.info, Node: ARM NEON Intrinsics, Next: Blackfin Built-in Functions, Prev: ARM iWMMXt Built-in Functions, Up: Target Builtins
-
-6.54.3 ARM NEON Intrinsics
---------------------------
-
-These built-in intrinsics for the ARM Advanced SIMD extension are
-available when the `-mfpu=neon' switch is used:
-
-6.54.3.1 Addition
-.................
-
- * uint32x2_t vadd_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vadd.i32 D0, D0, D0'
-
- * uint16x4_t vadd_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vadd.i16 D0, D0, D0'
-
- * uint8x8_t vadd_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vadd.i8 D0, D0, D0'
-
- * int32x2_t vadd_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vadd.i32 D0, D0, D0'
-
- * int16x4_t vadd_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vadd.i16 D0, D0, D0'
-
- * int8x8_t vadd_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vadd.i8 D0, D0, D0'
-
- * float32x2_t vadd_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vadd.f32 D0, D0, D0'
-
- * uint64x1_t vadd_u64 (uint64x1_t, uint64x1_t)
-
- * int64x1_t vadd_s64 (int64x1_t, int64x1_t)
-
- * uint32x4_t vaddq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vadd.i32 Q0, Q0, Q0'
-
- * uint16x8_t vaddq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vadd.i16 Q0, Q0, Q0'
-
- * uint8x16_t vaddq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vadd.i8 Q0, Q0, Q0'
-
- * int32x4_t vaddq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vadd.i32 Q0, Q0, Q0'
-
- * int16x8_t vaddq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vadd.i16 Q0, Q0, Q0'
-
- * int8x16_t vaddq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vadd.i8 Q0, Q0, Q0'
-
- * uint64x2_t vaddq_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vadd.i64 Q0, Q0, Q0'
-
- * int64x2_t vaddq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vadd.i64 Q0, Q0, Q0'
-
- * float32x4_t vaddq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vadd.f32 Q0, Q0, Q0'
-
- * uint64x2_t vaddl_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vaddl.u32 Q0, D0, D0'
-
- * uint32x4_t vaddl_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vaddl.u16 Q0, D0, D0'
-
- * uint16x8_t vaddl_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vaddl.u8 Q0, D0, D0'
-
- * int64x2_t vaddl_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vaddl.s32 Q0, D0, D0'
-
- * int32x4_t vaddl_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vaddl.s16 Q0, D0, D0'
-
- * int16x8_t vaddl_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vaddl.s8 Q0, D0, D0'
-
- * uint64x2_t vaddw_u32 (uint64x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vaddw.u32 Q0, Q0, D0'
-
- * uint32x4_t vaddw_u16 (uint32x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vaddw.u16 Q0, Q0, D0'
-
- * uint16x8_t vaddw_u8 (uint16x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vaddw.u8 Q0, Q0, D0'
-
- * int64x2_t vaddw_s32 (int64x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vaddw.s32 Q0, Q0, D0'
-
- * int32x4_t vaddw_s16 (int32x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vaddw.s16 Q0, Q0, D0'
-
- * int16x8_t vaddw_s8 (int16x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vaddw.s8 Q0, Q0, D0'
-
- * uint32x2_t vhadd_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vhadd.u32 D0, D0, D0'
-
- * uint16x4_t vhadd_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vhadd.u16 D0, D0, D0'
-
- * uint8x8_t vhadd_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vhadd.u8 D0, D0, D0'
-
- * int32x2_t vhadd_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vhadd.s32 D0, D0, D0'
-
- * int16x4_t vhadd_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vhadd.s16 D0, D0, D0'
-
- * int8x8_t vhadd_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vhadd.s8 D0, D0, D0'
-
- * uint32x4_t vhaddq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vhadd.u32 Q0, Q0, Q0'
-
- * uint16x8_t vhaddq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vhadd.u16 Q0, Q0, Q0'
-
- * uint8x16_t vhaddq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vhadd.u8 Q0, Q0, Q0'
-
- * int32x4_t vhaddq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vhadd.s32 Q0, Q0, Q0'
-
- * int16x8_t vhaddq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vhadd.s16 Q0, Q0, Q0'
-
- * int8x16_t vhaddq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vhadd.s8 Q0, Q0, Q0'
-
- * uint32x2_t vrhadd_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vrhadd.u32 D0, D0, D0'
-
- * uint16x4_t vrhadd_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vrhadd.u16 D0, D0, D0'
-
- * uint8x8_t vrhadd_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vrhadd.u8 D0, D0, D0'
-
- * int32x2_t vrhadd_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vrhadd.s32 D0, D0, D0'
-
- * int16x4_t vrhadd_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vrhadd.s16 D0, D0, D0'
-
- * int8x8_t vrhadd_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vrhadd.s8 D0, D0, D0'
-
- * uint32x4_t vrhaddq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vrhadd.u32 Q0, Q0, Q0'
-
- * uint16x8_t vrhaddq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vrhadd.u16 Q0, Q0, Q0'
-
- * uint8x16_t vrhaddq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vrhadd.u8 Q0, Q0, Q0'
-
- * int32x4_t vrhaddq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vrhadd.s32 Q0, Q0, Q0'
-
- * int16x8_t vrhaddq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vrhadd.s16 Q0, Q0, Q0'
-
- * int8x16_t vrhaddq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vrhadd.s8 Q0, Q0, Q0'
-
- * uint32x2_t vqadd_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vqadd.u32 D0, D0, D0'
-
- * uint16x4_t vqadd_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vqadd.u16 D0, D0, D0'
-
- * uint8x8_t vqadd_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vqadd.u8 D0, D0, D0'
-
- * int32x2_t vqadd_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vqadd.s32 D0, D0, D0'
-
- * int16x4_t vqadd_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vqadd.s16 D0, D0, D0'
-
- * int8x8_t vqadd_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vqadd.s8 D0, D0, D0'
-
- * uint64x1_t vqadd_u64 (uint64x1_t, uint64x1_t)
- _Form of expected instruction(s):_ `vqadd.u64 D0, D0, D0'
-
- * int64x1_t vqadd_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vqadd.s64 D0, D0, D0'
-
- * uint32x4_t vqaddq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vqadd.u32 Q0, Q0, Q0'
-
- * uint16x8_t vqaddq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vqadd.u16 Q0, Q0, Q0'
-
- * uint8x16_t vqaddq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vqadd.u8 Q0, Q0, Q0'
-
- * int32x4_t vqaddq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vqadd.s32 Q0, Q0, Q0'
-
- * int16x8_t vqaddq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vqadd.s16 Q0, Q0, Q0'
-
- * int8x16_t vqaddq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vqadd.s8 Q0, Q0, Q0'
-
- * uint64x2_t vqaddq_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vqadd.u64 Q0, Q0, Q0'
-
- * int64x2_t vqaddq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vqadd.s64 Q0, Q0, Q0'
-
- * uint32x2_t vaddhn_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vaddhn.i64 D0, Q0, Q0'
-
- * uint16x4_t vaddhn_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vaddhn.i32 D0, Q0, Q0'
-
- * uint8x8_t vaddhn_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vaddhn.i16 D0, Q0, Q0'
-
- * int32x2_t vaddhn_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vaddhn.i64 D0, Q0, Q0'
-
- * int16x4_t vaddhn_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vaddhn.i32 D0, Q0, Q0'
-
- * int8x8_t vaddhn_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vaddhn.i16 D0, Q0, Q0'
-
- * uint32x2_t vraddhn_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vraddhn.i64 D0, Q0, Q0'
-
- * uint16x4_t vraddhn_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vraddhn.i32 D0, Q0, Q0'
-
- * uint8x8_t vraddhn_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vraddhn.i16 D0, Q0, Q0'
-
- * int32x2_t vraddhn_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vraddhn.i64 D0, Q0, Q0'
-
- * int16x4_t vraddhn_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vraddhn.i32 D0, Q0, Q0'
-
- * int8x8_t vraddhn_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vraddhn.i16 D0, Q0, Q0'
-
-6.54.3.2 Multiplication
-.......................
-
- * uint32x2_t vmul_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vmul.i32 D0, D0, D0'
-
- * uint16x4_t vmul_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vmul.i16 D0, D0, D0'
-
- * uint8x8_t vmul_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vmul.i8 D0, D0, D0'
-
- * int32x2_t vmul_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vmul.i32 D0, D0, D0'
-
- * int16x4_t vmul_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vmul.i16 D0, D0, D0'
-
- * int8x8_t vmul_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vmul.i8 D0, D0, D0'
-
- * float32x2_t vmul_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vmul.f32 D0, D0, D0'
-
- * poly8x8_t vmul_p8 (poly8x8_t, poly8x8_t)
- _Form of expected instruction(s):_ `vmul.p8 D0, D0, D0'
-
- * uint32x4_t vmulq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vmul.i32 Q0, Q0, Q0'
-
- * uint16x8_t vmulq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vmul.i16 Q0, Q0, Q0'
-
- * uint8x16_t vmulq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vmul.i8 Q0, Q0, Q0'
-
- * int32x4_t vmulq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vmul.i32 Q0, Q0, Q0'
-
- * int16x8_t vmulq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vmul.i16 Q0, Q0, Q0'
-
- * int8x16_t vmulq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vmul.i8 Q0, Q0, Q0'
-
- * float32x4_t vmulq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vmul.f32 Q0, Q0, Q0'
-
- * poly8x16_t vmulq_p8 (poly8x16_t, poly8x16_t)
- _Form of expected instruction(s):_ `vmul.p8 Q0, Q0, Q0'
-
- * int32x2_t vqdmulh_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vqdmulh.s32 D0, D0, D0'
-
- * int16x4_t vqdmulh_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vqdmulh.s16 D0, D0, D0'
-
- * int32x4_t vqdmulhq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vqdmulh.s32 Q0, Q0, Q0'
-
- * int16x8_t vqdmulhq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vqdmulh.s16 Q0, Q0, Q0'
-
- * int32x2_t vqrdmulh_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vqrdmulh.s32 D0, D0, D0'
-
- * int16x4_t vqrdmulh_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vqrdmulh.s16 D0, D0, D0'
-
- * int32x4_t vqrdmulhq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vqrdmulh.s32 Q0, Q0, Q0'
-
- * int16x8_t vqrdmulhq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vqrdmulh.s16 Q0, Q0, Q0'
-
- * uint64x2_t vmull_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vmull.u32 Q0, D0, D0'
-
- * uint32x4_t vmull_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vmull.u16 Q0, D0, D0'
-
- * uint16x8_t vmull_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vmull.u8 Q0, D0, D0'
-
- * int64x2_t vmull_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vmull.s32 Q0, D0, D0'
-
- * int32x4_t vmull_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vmull.s16 Q0, D0, D0'
-
- * int16x8_t vmull_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vmull.s8 Q0, D0, D0'
-
- * poly16x8_t vmull_p8 (poly8x8_t, poly8x8_t)
- _Form of expected instruction(s):_ `vmull.p8 Q0, D0, D0'
-
- * int64x2_t vqdmull_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vqdmull.s32 Q0, D0, D0'
-
- * int32x4_t vqdmull_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vqdmull.s16 Q0, D0, D0'
-
-6.54.3.3 Multiply-accumulate
-............................
-
- * uint32x2_t vmla_u32 (uint32x2_t, uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vmla.i32 D0, D0, D0'
-
- * uint16x4_t vmla_u16 (uint16x4_t, uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vmla.i16 D0, D0, D0'
-
- * uint8x8_t vmla_u8 (uint8x8_t, uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vmla.i8 D0, D0, D0'
-
- * int32x2_t vmla_s32 (int32x2_t, int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vmla.i32 D0, D0, D0'
-
- * int16x4_t vmla_s16 (int16x4_t, int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vmla.i16 D0, D0, D0'
-
- * int8x8_t vmla_s8 (int8x8_t, int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vmla.i8 D0, D0, D0'
-
- * float32x2_t vmla_f32 (float32x2_t, float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vmla.f32 D0, D0, D0'
-
- * uint32x4_t vmlaq_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vmla.i32 Q0, Q0, Q0'
-
- * uint16x8_t vmlaq_u16 (uint16x8_t, uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vmla.i16 Q0, Q0, Q0'
-
- * uint8x16_t vmlaq_u8 (uint8x16_t, uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vmla.i8 Q0, Q0, Q0'
-
- * int32x4_t vmlaq_s32 (int32x4_t, int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vmla.i32 Q0, Q0, Q0'
-
- * int16x8_t vmlaq_s16 (int16x8_t, int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vmla.i16 Q0, Q0, Q0'
-
- * int8x16_t vmlaq_s8 (int8x16_t, int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vmla.i8 Q0, Q0, Q0'
-
- * float32x4_t vmlaq_f32 (float32x4_t, float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vmla.f32 Q0, Q0, Q0'
-
- * uint64x2_t vmlal_u32 (uint64x2_t, uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vmlal.u32 Q0, D0, D0'
-
- * uint32x4_t vmlal_u16 (uint32x4_t, uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vmlal.u16 Q0, D0, D0'
-
- * uint16x8_t vmlal_u8 (uint16x8_t, uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vmlal.u8 Q0, D0, D0'
-
- * int64x2_t vmlal_s32 (int64x2_t, int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vmlal.s32 Q0, D0, D0'
-
- * int32x4_t vmlal_s16 (int32x4_t, int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vmlal.s16 Q0, D0, D0'
-
- * int16x8_t vmlal_s8 (int16x8_t, int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vmlal.s8 Q0, D0, D0'
-
- * int64x2_t vqdmlal_s32 (int64x2_t, int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vqdmlal.s32 Q0, D0, D0'
-
- * int32x4_t vqdmlal_s16 (int32x4_t, int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vqdmlal.s16 Q0, D0, D0'
-
-6.54.3.4 Multiply-subtract
-..........................
-
- * uint32x2_t vmls_u32 (uint32x2_t, uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vmls.i32 D0, D0, D0'
-
- * uint16x4_t vmls_u16 (uint16x4_t, uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vmls.i16 D0, D0, D0'
-
- * uint8x8_t vmls_u8 (uint8x8_t, uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vmls.i8 D0, D0, D0'
-
- * int32x2_t vmls_s32 (int32x2_t, int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vmls.i32 D0, D0, D0'
-
- * int16x4_t vmls_s16 (int16x4_t, int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vmls.i16 D0, D0, D0'
-
- * int8x8_t vmls_s8 (int8x8_t, int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vmls.i8 D0, D0, D0'
-
- * float32x2_t vmls_f32 (float32x2_t, float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vmls.f32 D0, D0, D0'
-
- * uint32x4_t vmlsq_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vmls.i32 Q0, Q0, Q0'
-
- * uint16x8_t vmlsq_u16 (uint16x8_t, uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vmls.i16 Q0, Q0, Q0'
-
- * uint8x16_t vmlsq_u8 (uint8x16_t, uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vmls.i8 Q0, Q0, Q0'
-
- * int32x4_t vmlsq_s32 (int32x4_t, int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vmls.i32 Q0, Q0, Q0'
-
- * int16x8_t vmlsq_s16 (int16x8_t, int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vmls.i16 Q0, Q0, Q0'
-
- * int8x16_t vmlsq_s8 (int8x16_t, int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vmls.i8 Q0, Q0, Q0'
-
- * float32x4_t vmlsq_f32 (float32x4_t, float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vmls.f32 Q0, Q0, Q0'
-
- * uint64x2_t vmlsl_u32 (uint64x2_t, uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vmlsl.u32 Q0, D0, D0'
-
- * uint32x4_t vmlsl_u16 (uint32x4_t, uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vmlsl.u16 Q0, D0, D0'
-
- * uint16x8_t vmlsl_u8 (uint16x8_t, uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vmlsl.u8 Q0, D0, D0'
-
- * int64x2_t vmlsl_s32 (int64x2_t, int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vmlsl.s32 Q0, D0, D0'
-
- * int32x4_t vmlsl_s16 (int32x4_t, int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vmlsl.s16 Q0, D0, D0'
-
- * int16x8_t vmlsl_s8 (int16x8_t, int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vmlsl.s8 Q0, D0, D0'
-
- * int64x2_t vqdmlsl_s32 (int64x2_t, int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vqdmlsl.s32 Q0, D0, D0'
-
- * int32x4_t vqdmlsl_s16 (int32x4_t, int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vqdmlsl.s16 Q0, D0, D0'
-
-6.54.3.5 Subtraction
-....................
-
- * uint32x2_t vsub_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vsub.i32 D0, D0, D0'
-
- * uint16x4_t vsub_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vsub.i16 D0, D0, D0'
-
- * uint8x8_t vsub_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vsub.i8 D0, D0, D0'
-
- * int32x2_t vsub_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vsub.i32 D0, D0, D0'
-
- * int16x4_t vsub_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vsub.i16 D0, D0, D0'
-
- * int8x8_t vsub_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vsub.i8 D0, D0, D0'
-
- * float32x2_t vsub_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vsub.f32 D0, D0, D0'
-
- * uint64x1_t vsub_u64 (uint64x1_t, uint64x1_t)
-
- * int64x1_t vsub_s64 (int64x1_t, int64x1_t)
-
- * uint32x4_t vsubq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vsub.i32 Q0, Q0, Q0'
-
- * uint16x8_t vsubq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vsub.i16 Q0, Q0, Q0'
-
- * uint8x16_t vsubq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vsub.i8 Q0, Q0, Q0'
-
- * int32x4_t vsubq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vsub.i32 Q0, Q0, Q0'
-
- * int16x8_t vsubq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vsub.i16 Q0, Q0, Q0'
-
- * int8x16_t vsubq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vsub.i8 Q0, Q0, Q0'
-
- * uint64x2_t vsubq_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vsub.i64 Q0, Q0, Q0'
-
- * int64x2_t vsubq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vsub.i64 Q0, Q0, Q0'
-
- * float32x4_t vsubq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vsub.f32 Q0, Q0, Q0'
-
- * uint64x2_t vsubl_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vsubl.u32 Q0, D0, D0'
-
- * uint32x4_t vsubl_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vsubl.u16 Q0, D0, D0'
-
- * uint16x8_t vsubl_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vsubl.u8 Q0, D0, D0'
-
- * int64x2_t vsubl_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vsubl.s32 Q0, D0, D0'
-
- * int32x4_t vsubl_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vsubl.s16 Q0, D0, D0'
-
- * int16x8_t vsubl_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vsubl.s8 Q0, D0, D0'
-
- * uint64x2_t vsubw_u32 (uint64x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vsubw.u32 Q0, Q0, D0'
-
- * uint32x4_t vsubw_u16 (uint32x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vsubw.u16 Q0, Q0, D0'
-
- * uint16x8_t vsubw_u8 (uint16x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vsubw.u8 Q0, Q0, D0'
-
- * int64x2_t vsubw_s32 (int64x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vsubw.s32 Q0, Q0, D0'
-
- * int32x4_t vsubw_s16 (int32x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vsubw.s16 Q0, Q0, D0'
-
- * int16x8_t vsubw_s8 (int16x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vsubw.s8 Q0, Q0, D0'
-
- * uint32x2_t vhsub_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vhsub.u32 D0, D0, D0'
-
- * uint16x4_t vhsub_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vhsub.u16 D0, D0, D0'
-
- * uint8x8_t vhsub_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vhsub.u8 D0, D0, D0'
-
- * int32x2_t vhsub_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vhsub.s32 D0, D0, D0'
-
- * int16x4_t vhsub_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vhsub.s16 D0, D0, D0'
-
- * int8x8_t vhsub_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vhsub.s8 D0, D0, D0'
-
- * uint32x4_t vhsubq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vhsub.u32 Q0, Q0, Q0'
-
- * uint16x8_t vhsubq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vhsub.u16 Q0, Q0, Q0'
-
- * uint8x16_t vhsubq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vhsub.u8 Q0, Q0, Q0'
-
- * int32x4_t vhsubq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vhsub.s32 Q0, Q0, Q0'
-
- * int16x8_t vhsubq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vhsub.s16 Q0, Q0, Q0'
-
- * int8x16_t vhsubq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vhsub.s8 Q0, Q0, Q0'
-
- * uint32x2_t vqsub_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vqsub.u32 D0, D0, D0'
-
- * uint16x4_t vqsub_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vqsub.u16 D0, D0, D0'
-
- * uint8x8_t vqsub_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vqsub.u8 D0, D0, D0'
-
- * int32x2_t vqsub_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vqsub.s32 D0, D0, D0'
-
- * int16x4_t vqsub_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vqsub.s16 D0, D0, D0'
-
- * int8x8_t vqsub_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vqsub.s8 D0, D0, D0'
-
- * uint64x1_t vqsub_u64 (uint64x1_t, uint64x1_t)
- _Form of expected instruction(s):_ `vqsub.u64 D0, D0, D0'
-
- * int64x1_t vqsub_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vqsub.s64 D0, D0, D0'
-
- * uint32x4_t vqsubq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vqsub.u32 Q0, Q0, Q0'
-
- * uint16x8_t vqsubq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vqsub.u16 Q0, Q0, Q0'
-
- * uint8x16_t vqsubq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vqsub.u8 Q0, Q0, Q0'
-
- * int32x4_t vqsubq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vqsub.s32 Q0, Q0, Q0'
-
- * int16x8_t vqsubq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vqsub.s16 Q0, Q0, Q0'
-
- * int8x16_t vqsubq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vqsub.s8 Q0, Q0, Q0'
-
- * uint64x2_t vqsubq_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vqsub.u64 Q0, Q0, Q0'
-
- * int64x2_t vqsubq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vqsub.s64 Q0, Q0, Q0'
-
- * uint32x2_t vsubhn_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vsubhn.i64 D0, Q0, Q0'
-
- * uint16x4_t vsubhn_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vsubhn.i32 D0, Q0, Q0'
-
- * uint8x8_t vsubhn_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vsubhn.i16 D0, Q0, Q0'
-
- * int32x2_t vsubhn_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vsubhn.i64 D0, Q0, Q0'
-
- * int16x4_t vsubhn_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vsubhn.i32 D0, Q0, Q0'
-
- * int8x8_t vsubhn_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vsubhn.i16 D0, Q0, Q0'
-
- * uint32x2_t vrsubhn_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vrsubhn.i64 D0, Q0, Q0'
-
- * uint16x4_t vrsubhn_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vrsubhn.i32 D0, Q0, Q0'
-
- * uint8x8_t vrsubhn_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vrsubhn.i16 D0, Q0, Q0'
-
- * int32x2_t vrsubhn_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vrsubhn.i64 D0, Q0, Q0'
-
- * int16x4_t vrsubhn_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vrsubhn.i32 D0, Q0, Q0'
-
- * int8x8_t vrsubhn_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vrsubhn.i16 D0, Q0, Q0'
-
-6.54.3.6 Comparison (equal-to)
-..............................
-
- * uint32x2_t vceq_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vceq.i32 D0, D0, D0'
-
- * uint16x4_t vceq_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vceq.i16 D0, D0, D0'
-
- * uint8x8_t vceq_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vceq.i8 D0, D0, D0'
-
- * uint32x2_t vceq_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vceq.i32 D0, D0, D0'
-
- * uint16x4_t vceq_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vceq.i16 D0, D0, D0'
-
- * uint8x8_t vceq_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vceq.i8 D0, D0, D0'
-
- * uint32x2_t vceq_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vceq.f32 D0, D0, D0'
-
- * uint8x8_t vceq_p8 (poly8x8_t, poly8x8_t)
- _Form of expected instruction(s):_ `vceq.i8 D0, D0, D0'
-
- * uint32x4_t vceqq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vceq.i32 Q0, Q0, Q0'
-
- * uint16x8_t vceqq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vceq.i16 Q0, Q0, Q0'
-
- * uint8x16_t vceqq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vceq.i8 Q0, Q0, Q0'
-
- * uint32x4_t vceqq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vceq.i32 Q0, Q0, Q0'
-
- * uint16x8_t vceqq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vceq.i16 Q0, Q0, Q0'
-
- * uint8x16_t vceqq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vceq.i8 Q0, Q0, Q0'
-
- * uint32x4_t vceqq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vceq.f32 Q0, Q0, Q0'
-
- * uint8x16_t vceqq_p8 (poly8x16_t, poly8x16_t)
- _Form of expected instruction(s):_ `vceq.i8 Q0, Q0, Q0'
-
-6.54.3.7 Comparison (greater-than-or-equal-to)
-..............................................
-
- * uint32x2_t vcge_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vcge.u32 D0, D0, D0'
-
- * uint16x4_t vcge_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vcge.u16 D0, D0, D0'
-
- * uint8x8_t vcge_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vcge.u8 D0, D0, D0'
-
- * uint32x2_t vcge_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vcge.s32 D0, D0, D0'
-
- * uint16x4_t vcge_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vcge.s16 D0, D0, D0'
-
- * uint8x8_t vcge_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vcge.s8 D0, D0, D0'
-
- * uint32x2_t vcge_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vcge.f32 D0, D0, D0'
-
- * uint32x4_t vcgeq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vcge.u32 Q0, Q0, Q0'
-
- * uint16x8_t vcgeq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vcge.u16 Q0, Q0, Q0'
-
- * uint8x16_t vcgeq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vcge.u8 Q0, Q0, Q0'
-
- * uint32x4_t vcgeq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vcge.s32 Q0, Q0, Q0'
-
- * uint16x8_t vcgeq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vcge.s16 Q0, Q0, Q0'
-
- * uint8x16_t vcgeq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vcge.s8 Q0, Q0, Q0'
-
- * uint32x4_t vcgeq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vcge.f32 Q0, Q0, Q0'
-
-6.54.3.8 Comparison (less-than-or-equal-to)
-...........................................
-
- * uint32x2_t vcle_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vcge.u32 D0, D0, D0'
-
- * uint16x4_t vcle_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vcge.u16 D0, D0, D0'
-
- * uint8x8_t vcle_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vcge.u8 D0, D0, D0'
-
- * uint32x2_t vcle_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vcge.s32 D0, D0, D0'
-
- * uint16x4_t vcle_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vcge.s16 D0, D0, D0'
-
- * uint8x8_t vcle_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vcge.s8 D0, D0, D0'
-
- * uint32x2_t vcle_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vcge.f32 D0, D0, D0'
-
- * uint32x4_t vcleq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vcge.u32 Q0, Q0, Q0'
-
- * uint16x8_t vcleq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vcge.u16 Q0, Q0, Q0'
-
- * uint8x16_t vcleq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vcge.u8 Q0, Q0, Q0'
-
- * uint32x4_t vcleq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vcge.s32 Q0, Q0, Q0'
-
- * uint16x8_t vcleq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vcge.s16 Q0, Q0, Q0'
-
- * uint8x16_t vcleq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vcge.s8 Q0, Q0, Q0'
-
- * uint32x4_t vcleq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vcge.f32 Q0, Q0, Q0'
-
-6.54.3.9 Comparison (greater-than)
-..................................
-
- * uint32x2_t vcgt_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vcgt.u32 D0, D0, D0'
-
- * uint16x4_t vcgt_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vcgt.u16 D0, D0, D0'
-
- * uint8x8_t vcgt_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vcgt.u8 D0, D0, D0'
-
- * uint32x2_t vcgt_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vcgt.s32 D0, D0, D0'
-
- * uint16x4_t vcgt_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vcgt.s16 D0, D0, D0'
-
- * uint8x8_t vcgt_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vcgt.s8 D0, D0, D0'
-
- * uint32x2_t vcgt_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vcgt.f32 D0, D0, D0'
-
- * uint32x4_t vcgtq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vcgt.u32 Q0, Q0, Q0'
-
- * uint16x8_t vcgtq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vcgt.u16 Q0, Q0, Q0'
-
- * uint8x16_t vcgtq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vcgt.u8 Q0, Q0, Q0'
-
- * uint32x4_t vcgtq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vcgt.s32 Q0, Q0, Q0'
-
- * uint16x8_t vcgtq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vcgt.s16 Q0, Q0, Q0'
-
- * uint8x16_t vcgtq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vcgt.s8 Q0, Q0, Q0'
-
- * uint32x4_t vcgtq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vcgt.f32 Q0, Q0, Q0'
-
-6.54.3.10 Comparison (less-than)
-................................
-
- * uint32x2_t vclt_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vcgt.u32 D0, D0, D0'
-
- * uint16x4_t vclt_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vcgt.u16 D0, D0, D0'
-
- * uint8x8_t vclt_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vcgt.u8 D0, D0, D0'
-
- * uint32x2_t vclt_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vcgt.s32 D0, D0, D0'
-
- * uint16x4_t vclt_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vcgt.s16 D0, D0, D0'
-
- * uint8x8_t vclt_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vcgt.s8 D0, D0, D0'
-
- * uint32x2_t vclt_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vcgt.f32 D0, D0, D0'
-
- * uint32x4_t vcltq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vcgt.u32 Q0, Q0, Q0'
-
- * uint16x8_t vcltq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vcgt.u16 Q0, Q0, Q0'
-
- * uint8x16_t vcltq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vcgt.u8 Q0, Q0, Q0'
-
- * uint32x4_t vcltq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vcgt.s32 Q0, Q0, Q0'
-
- * uint16x8_t vcltq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vcgt.s16 Q0, Q0, Q0'
-
- * uint8x16_t vcltq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vcgt.s8 Q0, Q0, Q0'
-
- * uint32x4_t vcltq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vcgt.f32 Q0, Q0, Q0'
-
-6.54.3.11 Comparison (absolute greater-than-or-equal-to)
-........................................................
-
- * uint32x2_t vcage_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vacge.f32 D0, D0, D0'
-
- * uint32x4_t vcageq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vacge.f32 Q0, Q0, Q0'
-
-6.54.3.12 Comparison (absolute less-than-or-equal-to)
-.....................................................
-
- * uint32x2_t vcale_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vacge.f32 D0, D0, D0'
-
- * uint32x4_t vcaleq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vacge.f32 Q0, Q0, Q0'
-
-6.54.3.13 Comparison (absolute greater-than)
-............................................
-
- * uint32x2_t vcagt_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vacgt.f32 D0, D0, D0'
-
- * uint32x4_t vcagtq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vacgt.f32 Q0, Q0, Q0'
-
-6.54.3.14 Comparison (absolute less-than)
-.........................................
-
- * uint32x2_t vcalt_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vacgt.f32 D0, D0, D0'
-
- * uint32x4_t vcaltq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vacgt.f32 Q0, Q0, Q0'
-
-6.54.3.15 Test bits
-...................
-
- * uint32x2_t vtst_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vtst.32 D0, D0, D0'
-
- * uint16x4_t vtst_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vtst.16 D0, D0, D0'
-
- * uint8x8_t vtst_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtst.8 D0, D0, D0'
-
- * uint32x2_t vtst_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vtst.32 D0, D0, D0'
-
- * uint16x4_t vtst_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vtst.16 D0, D0, D0'
-
- * uint8x8_t vtst_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vtst.8 D0, D0, D0'
-
- * uint8x8_t vtst_p8 (poly8x8_t, poly8x8_t)
- _Form of expected instruction(s):_ `vtst.8 D0, D0, D0'
-
- * uint32x4_t vtstq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vtst.32 Q0, Q0, Q0'
-
- * uint16x8_t vtstq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vtst.16 Q0, Q0, Q0'
-
- * uint8x16_t vtstq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vtst.8 Q0, Q0, Q0'
-
- * uint32x4_t vtstq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vtst.32 Q0, Q0, Q0'
-
- * uint16x8_t vtstq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vtst.16 Q0, Q0, Q0'
-
- * uint8x16_t vtstq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vtst.8 Q0, Q0, Q0'
-
- * uint8x16_t vtstq_p8 (poly8x16_t, poly8x16_t)
- _Form of expected instruction(s):_ `vtst.8 Q0, Q0, Q0'
-
-6.54.3.16 Absolute difference
-.............................
-
- * uint32x2_t vabd_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vabd.u32 D0, D0, D0'
-
- * uint16x4_t vabd_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vabd.u16 D0, D0, D0'
-
- * uint8x8_t vabd_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vabd.u8 D0, D0, D0'
-
- * int32x2_t vabd_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vabd.s32 D0, D0, D0'
-
- * int16x4_t vabd_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vabd.s16 D0, D0, D0'
-
- * int8x8_t vabd_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vabd.s8 D0, D0, D0'
-
- * float32x2_t vabd_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vabd.f32 D0, D0, D0'
-
- * uint32x4_t vabdq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vabd.u32 Q0, Q0, Q0'
-
- * uint16x8_t vabdq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vabd.u16 Q0, Q0, Q0'
-
- * uint8x16_t vabdq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vabd.u8 Q0, Q0, Q0'
-
- * int32x4_t vabdq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vabd.s32 Q0, Q0, Q0'
-
- * int16x8_t vabdq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vabd.s16 Q0, Q0, Q0'
-
- * int8x16_t vabdq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vabd.s8 Q0, Q0, Q0'
-
- * float32x4_t vabdq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vabd.f32 Q0, Q0, Q0'
-
- * uint64x2_t vabdl_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vabdl.u32 Q0, D0, D0'
-
- * uint32x4_t vabdl_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vabdl.u16 Q0, D0, D0'
-
- * uint16x8_t vabdl_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vabdl.u8 Q0, D0, D0'
-
- * int64x2_t vabdl_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vabdl.s32 Q0, D0, D0'
-
- * int32x4_t vabdl_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vabdl.s16 Q0, D0, D0'
-
- * int16x8_t vabdl_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vabdl.s8 Q0, D0, D0'
-
-6.54.3.17 Absolute difference and accumulate
-............................................
-
- * uint32x2_t vaba_u32 (uint32x2_t, uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vaba.u32 D0, D0, D0'
-
- * uint16x4_t vaba_u16 (uint16x4_t, uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vaba.u16 D0, D0, D0'
-
- * uint8x8_t vaba_u8 (uint8x8_t, uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vaba.u8 D0, D0, D0'
-
- * int32x2_t vaba_s32 (int32x2_t, int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vaba.s32 D0, D0, D0'
-
- * int16x4_t vaba_s16 (int16x4_t, int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vaba.s16 D0, D0, D0'
-
- * int8x8_t vaba_s8 (int8x8_t, int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vaba.s8 D0, D0, D0'
-
- * uint32x4_t vabaq_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vaba.u32 Q0, Q0, Q0'
-
- * uint16x8_t vabaq_u16 (uint16x8_t, uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vaba.u16 Q0, Q0, Q0'
-
- * uint8x16_t vabaq_u8 (uint8x16_t, uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vaba.u8 Q0, Q0, Q0'
-
- * int32x4_t vabaq_s32 (int32x4_t, int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vaba.s32 Q0, Q0, Q0'
-
- * int16x8_t vabaq_s16 (int16x8_t, int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vaba.s16 Q0, Q0, Q0'
-
- * int8x16_t vabaq_s8 (int8x16_t, int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vaba.s8 Q0, Q0, Q0'
-
- * uint64x2_t vabal_u32 (uint64x2_t, uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vabal.u32 Q0, D0, D0'
-
- * uint32x4_t vabal_u16 (uint32x4_t, uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vabal.u16 Q0, D0, D0'
-
- * uint16x8_t vabal_u8 (uint16x8_t, uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vabal.u8 Q0, D0, D0'
-
- * int64x2_t vabal_s32 (int64x2_t, int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vabal.s32 Q0, D0, D0'
-
- * int32x4_t vabal_s16 (int32x4_t, int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vabal.s16 Q0, D0, D0'
-
- * int16x8_t vabal_s8 (int16x8_t, int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vabal.s8 Q0, D0, D0'
-
-6.54.3.18 Maximum
-.................
-
- * uint32x2_t vmax_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vmax.u32 D0, D0, D0'
-
- * uint16x4_t vmax_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vmax.u16 D0, D0, D0'
-
- * uint8x8_t vmax_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vmax.u8 D0, D0, D0'
-
- * int32x2_t vmax_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vmax.s32 D0, D0, D0'
-
- * int16x4_t vmax_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vmax.s16 D0, D0, D0'
-
- * int8x8_t vmax_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vmax.s8 D0, D0, D0'
-
- * float32x2_t vmax_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vmax.f32 D0, D0, D0'
-
- * uint32x4_t vmaxq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vmax.u32 Q0, Q0, Q0'
-
- * uint16x8_t vmaxq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vmax.u16 Q0, Q0, Q0'
-
- * uint8x16_t vmaxq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vmax.u8 Q0, Q0, Q0'
-
- * int32x4_t vmaxq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vmax.s32 Q0, Q0, Q0'
-
- * int16x8_t vmaxq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vmax.s16 Q0, Q0, Q0'
-
- * int8x16_t vmaxq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vmax.s8 Q0, Q0, Q0'
-
- * float32x4_t vmaxq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vmax.f32 Q0, Q0, Q0'
-
-6.54.3.19 Minimum
-.................
-
- * uint32x2_t vmin_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vmin.u32 D0, D0, D0'
-
- * uint16x4_t vmin_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vmin.u16 D0, D0, D0'
-
- * uint8x8_t vmin_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vmin.u8 D0, D0, D0'
-
- * int32x2_t vmin_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vmin.s32 D0, D0, D0'
-
- * int16x4_t vmin_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vmin.s16 D0, D0, D0'
-
- * int8x8_t vmin_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vmin.s8 D0, D0, D0'
-
- * float32x2_t vmin_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vmin.f32 D0, D0, D0'
-
- * uint32x4_t vminq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vmin.u32 Q0, Q0, Q0'
-
- * uint16x8_t vminq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vmin.u16 Q0, Q0, Q0'
-
- * uint8x16_t vminq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vmin.u8 Q0, Q0, Q0'
-
- * int32x4_t vminq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vmin.s32 Q0, Q0, Q0'
-
- * int16x8_t vminq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vmin.s16 Q0, Q0, Q0'
-
- * int8x16_t vminq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vmin.s8 Q0, Q0, Q0'
-
- * float32x4_t vminq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vmin.f32 Q0, Q0, Q0'
-
-6.54.3.20 Pairwise add
-......................
-
- * uint32x2_t vpadd_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vpadd.i32 D0, D0, D0'
-
- * uint16x4_t vpadd_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vpadd.i16 D0, D0, D0'
-
- * uint8x8_t vpadd_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vpadd.i8 D0, D0, D0'
-
- * int32x2_t vpadd_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vpadd.i32 D0, D0, D0'
-
- * int16x4_t vpadd_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vpadd.i16 D0, D0, D0'
-
- * int8x8_t vpadd_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vpadd.i8 D0, D0, D0'
-
- * float32x2_t vpadd_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vpadd.f32 D0, D0, D0'
-
- * uint64x1_t vpaddl_u32 (uint32x2_t)
- _Form of expected instruction(s):_ `vpaddl.u32 D0, D0'
-
- * uint32x2_t vpaddl_u16 (uint16x4_t)
- _Form of expected instruction(s):_ `vpaddl.u16 D0, D0'
-
- * uint16x4_t vpaddl_u8 (uint8x8_t)
- _Form of expected instruction(s):_ `vpaddl.u8 D0, D0'
-
- * int64x1_t vpaddl_s32 (int32x2_t)
- _Form of expected instruction(s):_ `vpaddl.s32 D0, D0'
-
- * int32x2_t vpaddl_s16 (int16x4_t)
- _Form of expected instruction(s):_ `vpaddl.s16 D0, D0'
-
- * int16x4_t vpaddl_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vpaddl.s8 D0, D0'
-
- * uint64x2_t vpaddlq_u32 (uint32x4_t)
- _Form of expected instruction(s):_ `vpaddl.u32 Q0, Q0'
-
- * uint32x4_t vpaddlq_u16 (uint16x8_t)
- _Form of expected instruction(s):_ `vpaddl.u16 Q0, Q0'
-
- * uint16x8_t vpaddlq_u8 (uint8x16_t)
- _Form of expected instruction(s):_ `vpaddl.u8 Q0, Q0'
-
- * int64x2_t vpaddlq_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vpaddl.s32 Q0, Q0'
-
- * int32x4_t vpaddlq_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vpaddl.s16 Q0, Q0'
-
- * int16x8_t vpaddlq_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vpaddl.s8 Q0, Q0'
-
-6.54.3.21 Pairwise add, single_opcode widen and accumulate
-..........................................................
-
- * uint64x1_t vpadal_u32 (uint64x1_t, uint32x2_t)
- _Form of expected instruction(s):_ `vpadal.u32 D0, D0'
-
- * uint32x2_t vpadal_u16 (uint32x2_t, uint16x4_t)
- _Form of expected instruction(s):_ `vpadal.u16 D0, D0'
-
- * uint16x4_t vpadal_u8 (uint16x4_t, uint8x8_t)
- _Form of expected instruction(s):_ `vpadal.u8 D0, D0'
-
- * int64x1_t vpadal_s32 (int64x1_t, int32x2_t)
- _Form of expected instruction(s):_ `vpadal.s32 D0, D0'
-
- * int32x2_t vpadal_s16 (int32x2_t, int16x4_t)
- _Form of expected instruction(s):_ `vpadal.s16 D0, D0'
-
- * int16x4_t vpadal_s8 (int16x4_t, int8x8_t)
- _Form of expected instruction(s):_ `vpadal.s8 D0, D0'
-
- * uint64x2_t vpadalq_u32 (uint64x2_t, uint32x4_t)
- _Form of expected instruction(s):_ `vpadal.u32 Q0, Q0'
-
- * uint32x4_t vpadalq_u16 (uint32x4_t, uint16x8_t)
- _Form of expected instruction(s):_ `vpadal.u16 Q0, Q0'
-
- * uint16x8_t vpadalq_u8 (uint16x8_t, uint8x16_t)
- _Form of expected instruction(s):_ `vpadal.u8 Q0, Q0'
-
- * int64x2_t vpadalq_s32 (int64x2_t, int32x4_t)
- _Form of expected instruction(s):_ `vpadal.s32 Q0, Q0'
-
- * int32x4_t vpadalq_s16 (int32x4_t, int16x8_t)
- _Form of expected instruction(s):_ `vpadal.s16 Q0, Q0'
-
- * int16x8_t vpadalq_s8 (int16x8_t, int8x16_t)
- _Form of expected instruction(s):_ `vpadal.s8 Q0, Q0'
-
-6.54.3.22 Folding maximum
-.........................
-
- * uint32x2_t vpmax_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vpmax.u32 D0, D0, D0'
-
- * uint16x4_t vpmax_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vpmax.u16 D0, D0, D0'
-
- * uint8x8_t vpmax_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vpmax.u8 D0, D0, D0'
-
- * int32x2_t vpmax_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vpmax.s32 D0, D0, D0'
-
- * int16x4_t vpmax_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vpmax.s16 D0, D0, D0'
-
- * int8x8_t vpmax_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vpmax.s8 D0, D0, D0'
-
- * float32x2_t vpmax_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vpmax.f32 D0, D0, D0'
-
-6.54.3.23 Folding minimum
-.........................
-
- * uint32x2_t vpmin_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vpmin.u32 D0, D0, D0'
-
- * uint16x4_t vpmin_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vpmin.u16 D0, D0, D0'
-
- * uint8x8_t vpmin_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vpmin.u8 D0, D0, D0'
-
- * int32x2_t vpmin_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vpmin.s32 D0, D0, D0'
-
- * int16x4_t vpmin_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vpmin.s16 D0, D0, D0'
-
- * int8x8_t vpmin_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vpmin.s8 D0, D0, D0'
-
- * float32x2_t vpmin_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vpmin.f32 D0, D0, D0'
-
-6.54.3.24 Reciprocal step
-.........................
-
- * float32x2_t vrecps_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vrecps.f32 D0, D0, D0'
-
- * float32x4_t vrecpsq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vrecps.f32 Q0, Q0, Q0'
-
- * float32x2_t vrsqrts_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vrsqrts.f32 D0, D0, D0'
-
- * float32x4_t vrsqrtsq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vrsqrts.f32 Q0, Q0, Q0'
-
-6.54.3.25 Vector shift left
-...........................
-
- * uint32x2_t vshl_u32 (uint32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vshl.u32 D0, D0, D0'
-
- * uint16x4_t vshl_u16 (uint16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vshl.u16 D0, D0, D0'
-
- * uint8x8_t vshl_u8 (uint8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vshl.u8 D0, D0, D0'
-
- * int32x2_t vshl_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vshl.s32 D0, D0, D0'
-
- * int16x4_t vshl_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vshl.s16 D0, D0, D0'
-
- * int8x8_t vshl_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vshl.s8 D0, D0, D0'
-
- * uint64x1_t vshl_u64 (uint64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vshl.u64 D0, D0, D0'
-
- * int64x1_t vshl_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vshl.s64 D0, D0, D0'
-
- * uint32x4_t vshlq_u32 (uint32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vshl.u32 Q0, Q0, Q0'
-
- * uint16x8_t vshlq_u16 (uint16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vshl.u16 Q0, Q0, Q0'
-
- * uint8x16_t vshlq_u8 (uint8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vshl.u8 Q0, Q0, Q0'
-
- * int32x4_t vshlq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vshl.s32 Q0, Q0, Q0'
-
- * int16x8_t vshlq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vshl.s16 Q0, Q0, Q0'
-
- * int8x16_t vshlq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vshl.s8 Q0, Q0, Q0'
-
- * uint64x2_t vshlq_u64 (uint64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vshl.u64 Q0, Q0, Q0'
-
- * int64x2_t vshlq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vshl.s64 Q0, Q0, Q0'
-
- * uint32x2_t vrshl_u32 (uint32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vrshl.u32 D0, D0, D0'
-
- * uint16x4_t vrshl_u16 (uint16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vrshl.u16 D0, D0, D0'
-
- * uint8x8_t vrshl_u8 (uint8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vrshl.u8 D0, D0, D0'
-
- * int32x2_t vrshl_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vrshl.s32 D0, D0, D0'
-
- * int16x4_t vrshl_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vrshl.s16 D0, D0, D0'
-
- * int8x8_t vrshl_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vrshl.s8 D0, D0, D0'
-
- * uint64x1_t vrshl_u64 (uint64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vrshl.u64 D0, D0, D0'
-
- * int64x1_t vrshl_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vrshl.s64 D0, D0, D0'
-
- * uint32x4_t vrshlq_u32 (uint32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vrshl.u32 Q0, Q0, Q0'
-
- * uint16x8_t vrshlq_u16 (uint16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vrshl.u16 Q0, Q0, Q0'
-
- * uint8x16_t vrshlq_u8 (uint8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vrshl.u8 Q0, Q0, Q0'
-
- * int32x4_t vrshlq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vrshl.s32 Q0, Q0, Q0'
-
- * int16x8_t vrshlq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vrshl.s16 Q0, Q0, Q0'
-
- * int8x16_t vrshlq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vrshl.s8 Q0, Q0, Q0'
-
- * uint64x2_t vrshlq_u64 (uint64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vrshl.u64 Q0, Q0, Q0'
-
- * int64x2_t vrshlq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vrshl.s64 Q0, Q0, Q0'
-
- * uint32x2_t vqshl_u32 (uint32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vqshl.u32 D0, D0, D0'
-
- * uint16x4_t vqshl_u16 (uint16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vqshl.u16 D0, D0, D0'
-
- * uint8x8_t vqshl_u8 (uint8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vqshl.u8 D0, D0, D0'
-
- * int32x2_t vqshl_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vqshl.s32 D0, D0, D0'
-
- * int16x4_t vqshl_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vqshl.s16 D0, D0, D0'
-
- * int8x8_t vqshl_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vqshl.s8 D0, D0, D0'
-
- * uint64x1_t vqshl_u64 (uint64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vqshl.u64 D0, D0, D0'
-
- * int64x1_t vqshl_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vqshl.s64 D0, D0, D0'
-
- * uint32x4_t vqshlq_u32 (uint32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vqshl.u32 Q0, Q0, Q0'
-
- * uint16x8_t vqshlq_u16 (uint16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vqshl.u16 Q0, Q0, Q0'
-
- * uint8x16_t vqshlq_u8 (uint8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vqshl.u8 Q0, Q0, Q0'
-
- * int32x4_t vqshlq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vqshl.s32 Q0, Q0, Q0'
-
- * int16x8_t vqshlq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vqshl.s16 Q0, Q0, Q0'
-
- * int8x16_t vqshlq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vqshl.s8 Q0, Q0, Q0'
-
- * uint64x2_t vqshlq_u64 (uint64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vqshl.u64 Q0, Q0, Q0'
-
- * int64x2_t vqshlq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vqshl.s64 Q0, Q0, Q0'
-
- * uint32x2_t vqrshl_u32 (uint32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vqrshl.u32 D0, D0, D0'
-
- * uint16x4_t vqrshl_u16 (uint16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vqrshl.u16 D0, D0, D0'
-
- * uint8x8_t vqrshl_u8 (uint8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vqrshl.u8 D0, D0, D0'
-
- * int32x2_t vqrshl_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vqrshl.s32 D0, D0, D0'
-
- * int16x4_t vqrshl_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vqrshl.s16 D0, D0, D0'
-
- * int8x8_t vqrshl_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vqrshl.s8 D0, D0, D0'
-
- * uint64x1_t vqrshl_u64 (uint64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vqrshl.u64 D0, D0, D0'
-
- * int64x1_t vqrshl_s64 (int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vqrshl.s64 D0, D0, D0'
-
- * uint32x4_t vqrshlq_u32 (uint32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vqrshl.u32 Q0, Q0, Q0'
-
- * uint16x8_t vqrshlq_u16 (uint16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vqrshl.u16 Q0, Q0, Q0'
-
- * uint8x16_t vqrshlq_u8 (uint8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vqrshl.u8 Q0, Q0, Q0'
-
- * int32x4_t vqrshlq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vqrshl.s32 Q0, Q0, Q0'
-
- * int16x8_t vqrshlq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vqrshl.s16 Q0, Q0, Q0'
-
- * int8x16_t vqrshlq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vqrshl.s8 Q0, Q0, Q0'
-
- * uint64x2_t vqrshlq_u64 (uint64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vqrshl.u64 Q0, Q0, Q0'
-
- * int64x2_t vqrshlq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vqrshl.s64 Q0, Q0, Q0'
-
-6.54.3.26 Vector shift left by constant
-.......................................
-
- * uint32x2_t vshl_n_u32 (uint32x2_t, const int)
- _Form of expected instruction(s):_ `vshl.i32 D0, D0, #0'
-
- * uint16x4_t vshl_n_u16 (uint16x4_t, const int)
- _Form of expected instruction(s):_ `vshl.i16 D0, D0, #0'
-
- * uint8x8_t vshl_n_u8 (uint8x8_t, const int)
- _Form of expected instruction(s):_ `vshl.i8 D0, D0, #0'
-
- * int32x2_t vshl_n_s32 (int32x2_t, const int)
- _Form of expected instruction(s):_ `vshl.i32 D0, D0, #0'
-
- * int16x4_t vshl_n_s16 (int16x4_t, const int)
- _Form of expected instruction(s):_ `vshl.i16 D0, D0, #0'
-
- * int8x8_t vshl_n_s8 (int8x8_t, const int)
- _Form of expected instruction(s):_ `vshl.i8 D0, D0, #0'
-
- * uint64x1_t vshl_n_u64 (uint64x1_t, const int)
- _Form of expected instruction(s):_ `vshl.i64 D0, D0, #0'
-
- * int64x1_t vshl_n_s64 (int64x1_t, const int)
- _Form of expected instruction(s):_ `vshl.i64 D0, D0, #0'
-
- * uint32x4_t vshlq_n_u32 (uint32x4_t, const int)
- _Form of expected instruction(s):_ `vshl.i32 Q0, Q0, #0'
-
- * uint16x8_t vshlq_n_u16 (uint16x8_t, const int)
- _Form of expected instruction(s):_ `vshl.i16 Q0, Q0, #0'
-
- * uint8x16_t vshlq_n_u8 (uint8x16_t, const int)
- _Form of expected instruction(s):_ `vshl.i8 Q0, Q0, #0'
-
- * int32x4_t vshlq_n_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vshl.i32 Q0, Q0, #0'
-
- * int16x8_t vshlq_n_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vshl.i16 Q0, Q0, #0'
-
- * int8x16_t vshlq_n_s8 (int8x16_t, const int)
- _Form of expected instruction(s):_ `vshl.i8 Q0, Q0, #0'
-
- * uint64x2_t vshlq_n_u64 (uint64x2_t, const int)
- _Form of expected instruction(s):_ `vshl.i64 Q0, Q0, #0'
-
- * int64x2_t vshlq_n_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vshl.i64 Q0, Q0, #0'
-
- * uint32x2_t vqshl_n_u32 (uint32x2_t, const int)
- _Form of expected instruction(s):_ `vqshl.u32 D0, D0, #0'
-
- * uint16x4_t vqshl_n_u16 (uint16x4_t, const int)
- _Form of expected instruction(s):_ `vqshl.u16 D0, D0, #0'
-
- * uint8x8_t vqshl_n_u8 (uint8x8_t, const int)
- _Form of expected instruction(s):_ `vqshl.u8 D0, D0, #0'
-
- * int32x2_t vqshl_n_s32 (int32x2_t, const int)
- _Form of expected instruction(s):_ `vqshl.s32 D0, D0, #0'
-
- * int16x4_t vqshl_n_s16 (int16x4_t, const int)
- _Form of expected instruction(s):_ `vqshl.s16 D0, D0, #0'
-
- * int8x8_t vqshl_n_s8 (int8x8_t, const int)
- _Form of expected instruction(s):_ `vqshl.s8 D0, D0, #0'
-
- * uint64x1_t vqshl_n_u64 (uint64x1_t, const int)
- _Form of expected instruction(s):_ `vqshl.u64 D0, D0, #0'
-
- * int64x1_t vqshl_n_s64 (int64x1_t, const int)
- _Form of expected instruction(s):_ `vqshl.s64 D0, D0, #0'
-
- * uint32x4_t vqshlq_n_u32 (uint32x4_t, const int)
- _Form of expected instruction(s):_ `vqshl.u32 Q0, Q0, #0'
-
- * uint16x8_t vqshlq_n_u16 (uint16x8_t, const int)
- _Form of expected instruction(s):_ `vqshl.u16 Q0, Q0, #0'
-
- * uint8x16_t vqshlq_n_u8 (uint8x16_t, const int)
- _Form of expected instruction(s):_ `vqshl.u8 Q0, Q0, #0'
-
- * int32x4_t vqshlq_n_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vqshl.s32 Q0, Q0, #0'
-
- * int16x8_t vqshlq_n_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vqshl.s16 Q0, Q0, #0'
-
- * int8x16_t vqshlq_n_s8 (int8x16_t, const int)
- _Form of expected instruction(s):_ `vqshl.s8 Q0, Q0, #0'
-
- * uint64x2_t vqshlq_n_u64 (uint64x2_t, const int)
- _Form of expected instruction(s):_ `vqshl.u64 Q0, Q0, #0'
-
- * int64x2_t vqshlq_n_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vqshl.s64 Q0, Q0, #0'
-
- * uint64x1_t vqshlu_n_s64 (int64x1_t, const int)
- _Form of expected instruction(s):_ `vqshlu.s64 D0, D0, #0'
-
- * uint32x2_t vqshlu_n_s32 (int32x2_t, const int)
- _Form of expected instruction(s):_ `vqshlu.s32 D0, D0, #0'
-
- * uint16x4_t vqshlu_n_s16 (int16x4_t, const int)
- _Form of expected instruction(s):_ `vqshlu.s16 D0, D0, #0'
-
- * uint8x8_t vqshlu_n_s8 (int8x8_t, const int)
- _Form of expected instruction(s):_ `vqshlu.s8 D0, D0, #0'
-
- * uint64x2_t vqshluq_n_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vqshlu.s64 Q0, Q0, #0'
-
- * uint32x4_t vqshluq_n_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vqshlu.s32 Q0, Q0, #0'
-
- * uint16x8_t vqshluq_n_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vqshlu.s16 Q0, Q0, #0'
-
- * uint8x16_t vqshluq_n_s8 (int8x16_t, const int)
- _Form of expected instruction(s):_ `vqshlu.s8 Q0, Q0, #0'
-
- * uint64x2_t vshll_n_u32 (uint32x2_t, const int)
- _Form of expected instruction(s):_ `vshll.u32 Q0, D0, #0'
-
- * uint32x4_t vshll_n_u16 (uint16x4_t, const int)
- _Form of expected instruction(s):_ `vshll.u16 Q0, D0, #0'
-
- * uint16x8_t vshll_n_u8 (uint8x8_t, const int)
- _Form of expected instruction(s):_ `vshll.u8 Q0, D0, #0'
-
- * int64x2_t vshll_n_s32 (int32x2_t, const int)
- _Form of expected instruction(s):_ `vshll.s32 Q0, D0, #0'
-
- * int32x4_t vshll_n_s16 (int16x4_t, const int)
- _Form of expected instruction(s):_ `vshll.s16 Q0, D0, #0'
-
- * int16x8_t vshll_n_s8 (int8x8_t, const int)
- _Form of expected instruction(s):_ `vshll.s8 Q0, D0, #0'
-
-6.54.3.27 Vector shift right by constant
-........................................
-
- * uint32x2_t vshr_n_u32 (uint32x2_t, const int)
- _Form of expected instruction(s):_ `vshr.u32 D0, D0, #0'
-
- * uint16x4_t vshr_n_u16 (uint16x4_t, const int)
- _Form of expected instruction(s):_ `vshr.u16 D0, D0, #0'
-
- * uint8x8_t vshr_n_u8 (uint8x8_t, const int)
- _Form of expected instruction(s):_ `vshr.u8 D0, D0, #0'
-
- * int32x2_t vshr_n_s32 (int32x2_t, const int)
- _Form of expected instruction(s):_ `vshr.s32 D0, D0, #0'
-
- * int16x4_t vshr_n_s16 (int16x4_t, const int)
- _Form of expected instruction(s):_ `vshr.s16 D0, D0, #0'
-
- * int8x8_t vshr_n_s8 (int8x8_t, const int)
- _Form of expected instruction(s):_ `vshr.s8 D0, D0, #0'
-
- * uint64x1_t vshr_n_u64 (uint64x1_t, const int)
- _Form of expected instruction(s):_ `vshr.u64 D0, D0, #0'
-
- * int64x1_t vshr_n_s64 (int64x1_t, const int)
- _Form of expected instruction(s):_ `vshr.s64 D0, D0, #0'
-
- * uint32x4_t vshrq_n_u32 (uint32x4_t, const int)
- _Form of expected instruction(s):_ `vshr.u32 Q0, Q0, #0'
-
- * uint16x8_t vshrq_n_u16 (uint16x8_t, const int)
- _Form of expected instruction(s):_ `vshr.u16 Q0, Q0, #0'
-
- * uint8x16_t vshrq_n_u8 (uint8x16_t, const int)
- _Form of expected instruction(s):_ `vshr.u8 Q0, Q0, #0'
-
- * int32x4_t vshrq_n_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vshr.s32 Q0, Q0, #0'
-
- * int16x8_t vshrq_n_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vshr.s16 Q0, Q0, #0'
-
- * int8x16_t vshrq_n_s8 (int8x16_t, const int)
- _Form of expected instruction(s):_ `vshr.s8 Q0, Q0, #0'
-
- * uint64x2_t vshrq_n_u64 (uint64x2_t, const int)
- _Form of expected instruction(s):_ `vshr.u64 Q0, Q0, #0'
-
- * int64x2_t vshrq_n_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vshr.s64 Q0, Q0, #0'
-
- * uint32x2_t vrshr_n_u32 (uint32x2_t, const int)
- _Form of expected instruction(s):_ `vrshr.u32 D0, D0, #0'
-
- * uint16x4_t vrshr_n_u16 (uint16x4_t, const int)
- _Form of expected instruction(s):_ `vrshr.u16 D0, D0, #0'
-
- * uint8x8_t vrshr_n_u8 (uint8x8_t, const int)
- _Form of expected instruction(s):_ `vrshr.u8 D0, D0, #0'
-
- * int32x2_t vrshr_n_s32 (int32x2_t, const int)
- _Form of expected instruction(s):_ `vrshr.s32 D0, D0, #0'
-
- * int16x4_t vrshr_n_s16 (int16x4_t, const int)
- _Form of expected instruction(s):_ `vrshr.s16 D0, D0, #0'
-
- * int8x8_t vrshr_n_s8 (int8x8_t, const int)
- _Form of expected instruction(s):_ `vrshr.s8 D0, D0, #0'
-
- * uint64x1_t vrshr_n_u64 (uint64x1_t, const int)
- _Form of expected instruction(s):_ `vrshr.u64 D0, D0, #0'
-
- * int64x1_t vrshr_n_s64 (int64x1_t, const int)
- _Form of expected instruction(s):_ `vrshr.s64 D0, D0, #0'
-
- * uint32x4_t vrshrq_n_u32 (uint32x4_t, const int)
- _Form of expected instruction(s):_ `vrshr.u32 Q0, Q0, #0'
-
- * uint16x8_t vrshrq_n_u16 (uint16x8_t, const int)
- _Form of expected instruction(s):_ `vrshr.u16 Q0, Q0, #0'
-
- * uint8x16_t vrshrq_n_u8 (uint8x16_t, const int)
- _Form of expected instruction(s):_ `vrshr.u8 Q0, Q0, #0'
-
- * int32x4_t vrshrq_n_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vrshr.s32 Q0, Q0, #0'
-
- * int16x8_t vrshrq_n_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vrshr.s16 Q0, Q0, #0'
-
- * int8x16_t vrshrq_n_s8 (int8x16_t, const int)
- _Form of expected instruction(s):_ `vrshr.s8 Q0, Q0, #0'
-
- * uint64x2_t vrshrq_n_u64 (uint64x2_t, const int)
- _Form of expected instruction(s):_ `vrshr.u64 Q0, Q0, #0'
-
- * int64x2_t vrshrq_n_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vrshr.s64 Q0, Q0, #0'
-
- * uint32x2_t vshrn_n_u64 (uint64x2_t, const int)
- _Form of expected instruction(s):_ `vshrn.i64 D0, Q0, #0'
-
- * uint16x4_t vshrn_n_u32 (uint32x4_t, const int)
- _Form of expected instruction(s):_ `vshrn.i32 D0, Q0, #0'
-
- * uint8x8_t vshrn_n_u16 (uint16x8_t, const int)
- _Form of expected instruction(s):_ `vshrn.i16 D0, Q0, #0'
-
- * int32x2_t vshrn_n_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vshrn.i64 D0, Q0, #0'
-
- * int16x4_t vshrn_n_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vshrn.i32 D0, Q0, #0'
-
- * int8x8_t vshrn_n_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vshrn.i16 D0, Q0, #0'
-
- * uint32x2_t vrshrn_n_u64 (uint64x2_t, const int)
- _Form of expected instruction(s):_ `vrshrn.i64 D0, Q0, #0'
-
- * uint16x4_t vrshrn_n_u32 (uint32x4_t, const int)
- _Form of expected instruction(s):_ `vrshrn.i32 D0, Q0, #0'
-
- * uint8x8_t vrshrn_n_u16 (uint16x8_t, const int)
- _Form of expected instruction(s):_ `vrshrn.i16 D0, Q0, #0'
-
- * int32x2_t vrshrn_n_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vrshrn.i64 D0, Q0, #0'
-
- * int16x4_t vrshrn_n_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vrshrn.i32 D0, Q0, #0'
-
- * int8x8_t vrshrn_n_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vrshrn.i16 D0, Q0, #0'
-
- * uint32x2_t vqshrn_n_u64 (uint64x2_t, const int)
- _Form of expected instruction(s):_ `vqshrn.u64 D0, Q0, #0'
-
- * uint16x4_t vqshrn_n_u32 (uint32x4_t, const int)
- _Form of expected instruction(s):_ `vqshrn.u32 D0, Q0, #0'
-
- * uint8x8_t vqshrn_n_u16 (uint16x8_t, const int)
- _Form of expected instruction(s):_ `vqshrn.u16 D0, Q0, #0'
-
- * int32x2_t vqshrn_n_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vqshrn.s64 D0, Q0, #0'
-
- * int16x4_t vqshrn_n_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vqshrn.s32 D0, Q0, #0'
-
- * int8x8_t vqshrn_n_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vqshrn.s16 D0, Q0, #0'
-
- * uint32x2_t vqrshrn_n_u64 (uint64x2_t, const int)
- _Form of expected instruction(s):_ `vqrshrn.u64 D0, Q0, #0'
-
- * uint16x4_t vqrshrn_n_u32 (uint32x4_t, const int)
- _Form of expected instruction(s):_ `vqrshrn.u32 D0, Q0, #0'
-
- * uint8x8_t vqrshrn_n_u16 (uint16x8_t, const int)
- _Form of expected instruction(s):_ `vqrshrn.u16 D0, Q0, #0'
-
- * int32x2_t vqrshrn_n_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vqrshrn.s64 D0, Q0, #0'
-
- * int16x4_t vqrshrn_n_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vqrshrn.s32 D0, Q0, #0'
-
- * int8x8_t vqrshrn_n_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vqrshrn.s16 D0, Q0, #0'
-
- * uint32x2_t vqshrun_n_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vqshrun.s64 D0, Q0, #0'
-
- * uint16x4_t vqshrun_n_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vqshrun.s32 D0, Q0, #0'
-
- * uint8x8_t vqshrun_n_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vqshrun.s16 D0, Q0, #0'
-
- * uint32x2_t vqrshrun_n_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vqrshrun.s64 D0, Q0, #0'
-
- * uint16x4_t vqrshrun_n_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vqrshrun.s32 D0, Q0, #0'
-
- * uint8x8_t vqrshrun_n_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vqrshrun.s16 D0, Q0, #0'
-
-6.54.3.28 Vector shift right by constant and accumulate
-.......................................................
-
- * uint32x2_t vsra_n_u32 (uint32x2_t, uint32x2_t, const int)
- _Form of expected instruction(s):_ `vsra.u32 D0, D0, #0'
-
- * uint16x4_t vsra_n_u16 (uint16x4_t, uint16x4_t, const int)
- _Form of expected instruction(s):_ `vsra.u16 D0, D0, #0'
-
- * uint8x8_t vsra_n_u8 (uint8x8_t, uint8x8_t, const int)
- _Form of expected instruction(s):_ `vsra.u8 D0, D0, #0'
-
- * int32x2_t vsra_n_s32 (int32x2_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vsra.s32 D0, D0, #0'
-
- * int16x4_t vsra_n_s16 (int16x4_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vsra.s16 D0, D0, #0'
-
- * int8x8_t vsra_n_s8 (int8x8_t, int8x8_t, const int)
- _Form of expected instruction(s):_ `vsra.s8 D0, D0, #0'
-
- * uint64x1_t vsra_n_u64 (uint64x1_t, uint64x1_t, const int)
- _Form of expected instruction(s):_ `vsra.u64 D0, D0, #0'
-
- * int64x1_t vsra_n_s64 (int64x1_t, int64x1_t, const int)
- _Form of expected instruction(s):_ `vsra.s64 D0, D0, #0'
-
- * uint32x4_t vsraq_n_u32 (uint32x4_t, uint32x4_t, const int)
- _Form of expected instruction(s):_ `vsra.u32 Q0, Q0, #0'
-
- * uint16x8_t vsraq_n_u16 (uint16x8_t, uint16x8_t, const int)
- _Form of expected instruction(s):_ `vsra.u16 Q0, Q0, #0'
-
- * uint8x16_t vsraq_n_u8 (uint8x16_t, uint8x16_t, const int)
- _Form of expected instruction(s):_ `vsra.u8 Q0, Q0, #0'
-
- * int32x4_t vsraq_n_s32 (int32x4_t, int32x4_t, const int)
- _Form of expected instruction(s):_ `vsra.s32 Q0, Q0, #0'
-
- * int16x8_t vsraq_n_s16 (int16x8_t, int16x8_t, const int)
- _Form of expected instruction(s):_ `vsra.s16 Q0, Q0, #0'
-
- * int8x16_t vsraq_n_s8 (int8x16_t, int8x16_t, const int)
- _Form of expected instruction(s):_ `vsra.s8 Q0, Q0, #0'
-
- * uint64x2_t vsraq_n_u64 (uint64x2_t, uint64x2_t, const int)
- _Form of expected instruction(s):_ `vsra.u64 Q0, Q0, #0'
-
- * int64x2_t vsraq_n_s64 (int64x2_t, int64x2_t, const int)
- _Form of expected instruction(s):_ `vsra.s64 Q0, Q0, #0'
-
- * uint32x2_t vrsra_n_u32 (uint32x2_t, uint32x2_t, const int)
- _Form of expected instruction(s):_ `vrsra.u32 D0, D0, #0'
-
- * uint16x4_t vrsra_n_u16 (uint16x4_t, uint16x4_t, const int)
- _Form of expected instruction(s):_ `vrsra.u16 D0, D0, #0'
-
- * uint8x8_t vrsra_n_u8 (uint8x8_t, uint8x8_t, const int)
- _Form of expected instruction(s):_ `vrsra.u8 D0, D0, #0'
-
- * int32x2_t vrsra_n_s32 (int32x2_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vrsra.s32 D0, D0, #0'
-
- * int16x4_t vrsra_n_s16 (int16x4_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vrsra.s16 D0, D0, #0'
-
- * int8x8_t vrsra_n_s8 (int8x8_t, int8x8_t, const int)
- _Form of expected instruction(s):_ `vrsra.s8 D0, D0, #0'
-
- * uint64x1_t vrsra_n_u64 (uint64x1_t, uint64x1_t, const int)
- _Form of expected instruction(s):_ `vrsra.u64 D0, D0, #0'
-
- * int64x1_t vrsra_n_s64 (int64x1_t, int64x1_t, const int)
- _Form of expected instruction(s):_ `vrsra.s64 D0, D0, #0'
-
- * uint32x4_t vrsraq_n_u32 (uint32x4_t, uint32x4_t, const int)
- _Form of expected instruction(s):_ `vrsra.u32 Q0, Q0, #0'
-
- * uint16x8_t vrsraq_n_u16 (uint16x8_t, uint16x8_t, const int)
- _Form of expected instruction(s):_ `vrsra.u16 Q0, Q0, #0'
-
- * uint8x16_t vrsraq_n_u8 (uint8x16_t, uint8x16_t, const int)
- _Form of expected instruction(s):_ `vrsra.u8 Q0, Q0, #0'
-
- * int32x4_t vrsraq_n_s32 (int32x4_t, int32x4_t, const int)
- _Form of expected instruction(s):_ `vrsra.s32 Q0, Q0, #0'
-
- * int16x8_t vrsraq_n_s16 (int16x8_t, int16x8_t, const int)
- _Form of expected instruction(s):_ `vrsra.s16 Q0, Q0, #0'
-
- * int8x16_t vrsraq_n_s8 (int8x16_t, int8x16_t, const int)
- _Form of expected instruction(s):_ `vrsra.s8 Q0, Q0, #0'
-
- * uint64x2_t vrsraq_n_u64 (uint64x2_t, uint64x2_t, const int)
- _Form of expected instruction(s):_ `vrsra.u64 Q0, Q0, #0'
-
- * int64x2_t vrsraq_n_s64 (int64x2_t, int64x2_t, const int)
- _Form of expected instruction(s):_ `vrsra.s64 Q0, Q0, #0'
-
-6.54.3.29 Vector shift right and insert
-.......................................
-
- * uint32x2_t vsri_n_u32 (uint32x2_t, uint32x2_t, const int)
- _Form of expected instruction(s):_ `vsri.32 D0, D0, #0'
-
- * uint16x4_t vsri_n_u16 (uint16x4_t, uint16x4_t, const int)
- _Form of expected instruction(s):_ `vsri.16 D0, D0, #0'
-
- * uint8x8_t vsri_n_u8 (uint8x8_t, uint8x8_t, const int)
- _Form of expected instruction(s):_ `vsri.8 D0, D0, #0'
-
- * int32x2_t vsri_n_s32 (int32x2_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vsri.32 D0, D0, #0'
-
- * int16x4_t vsri_n_s16 (int16x4_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vsri.16 D0, D0, #0'
-
- * int8x8_t vsri_n_s8 (int8x8_t, int8x8_t, const int)
- _Form of expected instruction(s):_ `vsri.8 D0, D0, #0'
-
- * uint64x1_t vsri_n_u64 (uint64x1_t, uint64x1_t, const int)
- _Form of expected instruction(s):_ `vsri.64 D0, D0, #0'
-
- * int64x1_t vsri_n_s64 (int64x1_t, int64x1_t, const int)
- _Form of expected instruction(s):_ `vsri.64 D0, D0, #0'
-
- * poly16x4_t vsri_n_p16 (poly16x4_t, poly16x4_t, const int)
- _Form of expected instruction(s):_ `vsri.16 D0, D0, #0'
-
- * poly8x8_t vsri_n_p8 (poly8x8_t, poly8x8_t, const int)
- _Form of expected instruction(s):_ `vsri.8 D0, D0, #0'
-
- * uint32x4_t vsriq_n_u32 (uint32x4_t, uint32x4_t, const int)
- _Form of expected instruction(s):_ `vsri.32 Q0, Q0, #0'
-
- * uint16x8_t vsriq_n_u16 (uint16x8_t, uint16x8_t, const int)
- _Form of expected instruction(s):_ `vsri.16 Q0, Q0, #0'
-
- * uint8x16_t vsriq_n_u8 (uint8x16_t, uint8x16_t, const int)
- _Form of expected instruction(s):_ `vsri.8 Q0, Q0, #0'
-
- * int32x4_t vsriq_n_s32 (int32x4_t, int32x4_t, const int)
- _Form of expected instruction(s):_ `vsri.32 Q0, Q0, #0'
-
- * int16x8_t vsriq_n_s16 (int16x8_t, int16x8_t, const int)
- _Form of expected instruction(s):_ `vsri.16 Q0, Q0, #0'
-
- * int8x16_t vsriq_n_s8 (int8x16_t, int8x16_t, const int)
- _Form of expected instruction(s):_ `vsri.8 Q0, Q0, #0'
-
- * uint64x2_t vsriq_n_u64 (uint64x2_t, uint64x2_t, const int)
- _Form of expected instruction(s):_ `vsri.64 Q0, Q0, #0'
-
- * int64x2_t vsriq_n_s64 (int64x2_t, int64x2_t, const int)
- _Form of expected instruction(s):_ `vsri.64 Q0, Q0, #0'
-
- * poly16x8_t vsriq_n_p16 (poly16x8_t, poly16x8_t, const int)
- _Form of expected instruction(s):_ `vsri.16 Q0, Q0, #0'
-
- * poly8x16_t vsriq_n_p8 (poly8x16_t, poly8x16_t, const int)
- _Form of expected instruction(s):_ `vsri.8 Q0, Q0, #0'
-
-6.54.3.30 Vector shift left and insert
-......................................
-
- * uint32x2_t vsli_n_u32 (uint32x2_t, uint32x2_t, const int)
- _Form of expected instruction(s):_ `vsli.32 D0, D0, #0'
-
- * uint16x4_t vsli_n_u16 (uint16x4_t, uint16x4_t, const int)
- _Form of expected instruction(s):_ `vsli.16 D0, D0, #0'
-
- * uint8x8_t vsli_n_u8 (uint8x8_t, uint8x8_t, const int)
- _Form of expected instruction(s):_ `vsli.8 D0, D0, #0'
-
- * int32x2_t vsli_n_s32 (int32x2_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vsli.32 D0, D0, #0'
-
- * int16x4_t vsli_n_s16 (int16x4_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vsli.16 D0, D0, #0'
-
- * int8x8_t vsli_n_s8 (int8x8_t, int8x8_t, const int)
- _Form of expected instruction(s):_ `vsli.8 D0, D0, #0'
-
- * uint64x1_t vsli_n_u64 (uint64x1_t, uint64x1_t, const int)
- _Form of expected instruction(s):_ `vsli.64 D0, D0, #0'
-
- * int64x1_t vsli_n_s64 (int64x1_t, int64x1_t, const int)
- _Form of expected instruction(s):_ `vsli.64 D0, D0, #0'
-
- * poly16x4_t vsli_n_p16 (poly16x4_t, poly16x4_t, const int)
- _Form of expected instruction(s):_ `vsli.16 D0, D0, #0'
-
- * poly8x8_t vsli_n_p8 (poly8x8_t, poly8x8_t, const int)
- _Form of expected instruction(s):_ `vsli.8 D0, D0, #0'
-
- * uint32x4_t vsliq_n_u32 (uint32x4_t, uint32x4_t, const int)
- _Form of expected instruction(s):_ `vsli.32 Q0, Q0, #0'
-
- * uint16x8_t vsliq_n_u16 (uint16x8_t, uint16x8_t, const int)
- _Form of expected instruction(s):_ `vsli.16 Q0, Q0, #0'
-
- * uint8x16_t vsliq_n_u8 (uint8x16_t, uint8x16_t, const int)
- _Form of expected instruction(s):_ `vsli.8 Q0, Q0, #0'
-
- * int32x4_t vsliq_n_s32 (int32x4_t, int32x4_t, const int)
- _Form of expected instruction(s):_ `vsli.32 Q0, Q0, #0'
-
- * int16x8_t vsliq_n_s16 (int16x8_t, int16x8_t, const int)
- _Form of expected instruction(s):_ `vsli.16 Q0, Q0, #0'
-
- * int8x16_t vsliq_n_s8 (int8x16_t, int8x16_t, const int)
- _Form of expected instruction(s):_ `vsli.8 Q0, Q0, #0'
-
- * uint64x2_t vsliq_n_u64 (uint64x2_t, uint64x2_t, const int)
- _Form of expected instruction(s):_ `vsli.64 Q0, Q0, #0'
-
- * int64x2_t vsliq_n_s64 (int64x2_t, int64x2_t, const int)
- _Form of expected instruction(s):_ `vsli.64 Q0, Q0, #0'
-
- * poly16x8_t vsliq_n_p16 (poly16x8_t, poly16x8_t, const int)
- _Form of expected instruction(s):_ `vsli.16 Q0, Q0, #0'
-
- * poly8x16_t vsliq_n_p8 (poly8x16_t, poly8x16_t, const int)
- _Form of expected instruction(s):_ `vsli.8 Q0, Q0, #0'
-
-6.54.3.31 Absolute value
-........................
-
- * float32x2_t vabs_f32 (float32x2_t)
- _Form of expected instruction(s):_ `vabs.f32 D0, D0'
-
- * int32x2_t vabs_s32 (int32x2_t)
- _Form of expected instruction(s):_ `vabs.s32 D0, D0'
-
- * int16x4_t vabs_s16 (int16x4_t)
- _Form of expected instruction(s):_ `vabs.s16 D0, D0'
-
- * int8x8_t vabs_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vabs.s8 D0, D0'
-
- * float32x4_t vabsq_f32 (float32x4_t)
- _Form of expected instruction(s):_ `vabs.f32 Q0, Q0'
-
- * int32x4_t vabsq_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vabs.s32 Q0, Q0'
-
- * int16x8_t vabsq_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vabs.s16 Q0, Q0'
-
- * int8x16_t vabsq_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vabs.s8 Q0, Q0'
-
- * int32x2_t vqabs_s32 (int32x2_t)
- _Form of expected instruction(s):_ `vqabs.s32 D0, D0'
-
- * int16x4_t vqabs_s16 (int16x4_t)
- _Form of expected instruction(s):_ `vqabs.s16 D0, D0'
-
- * int8x8_t vqabs_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vqabs.s8 D0, D0'
-
- * int32x4_t vqabsq_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vqabs.s32 Q0, Q0'
-
- * int16x8_t vqabsq_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vqabs.s16 Q0, Q0'
-
- * int8x16_t vqabsq_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vqabs.s8 Q0, Q0'
-
-6.54.3.32 Negation
-..................
-
- * float32x2_t vneg_f32 (float32x2_t)
- _Form of expected instruction(s):_ `vneg.f32 D0, D0'
-
- * int32x2_t vneg_s32 (int32x2_t)
- _Form of expected instruction(s):_ `vneg.s32 D0, D0'
-
- * int16x4_t vneg_s16 (int16x4_t)
- _Form of expected instruction(s):_ `vneg.s16 D0, D0'
-
- * int8x8_t vneg_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vneg.s8 D0, D0'
-
- * float32x4_t vnegq_f32 (float32x4_t)
- _Form of expected instruction(s):_ `vneg.f32 Q0, Q0'
-
- * int32x4_t vnegq_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vneg.s32 Q0, Q0'
-
- * int16x8_t vnegq_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vneg.s16 Q0, Q0'
-
- * int8x16_t vnegq_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vneg.s8 Q0, Q0'
-
- * int32x2_t vqneg_s32 (int32x2_t)
- _Form of expected instruction(s):_ `vqneg.s32 D0, D0'
-
- * int16x4_t vqneg_s16 (int16x4_t)
- _Form of expected instruction(s):_ `vqneg.s16 D0, D0'
-
- * int8x8_t vqneg_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vqneg.s8 D0, D0'
-
- * int32x4_t vqnegq_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vqneg.s32 Q0, Q0'
-
- * int16x8_t vqnegq_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vqneg.s16 Q0, Q0'
-
- * int8x16_t vqnegq_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vqneg.s8 Q0, Q0'
-
-6.54.3.33 Bitwise not
-.....................
-
- * uint32x2_t vmvn_u32 (uint32x2_t)
- _Form of expected instruction(s):_ `vmvn D0, D0'
-
- * uint16x4_t vmvn_u16 (uint16x4_t)
- _Form of expected instruction(s):_ `vmvn D0, D0'
-
- * uint8x8_t vmvn_u8 (uint8x8_t)
- _Form of expected instruction(s):_ `vmvn D0, D0'
-
- * int32x2_t vmvn_s32 (int32x2_t)
- _Form of expected instruction(s):_ `vmvn D0, D0'
-
- * int16x4_t vmvn_s16 (int16x4_t)
- _Form of expected instruction(s):_ `vmvn D0, D0'
-
- * int8x8_t vmvn_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vmvn D0, D0'
-
- * poly8x8_t vmvn_p8 (poly8x8_t)
- _Form of expected instruction(s):_ `vmvn D0, D0'
-
- * uint32x4_t vmvnq_u32 (uint32x4_t)
- _Form of expected instruction(s):_ `vmvn Q0, Q0'
-
- * uint16x8_t vmvnq_u16 (uint16x8_t)
- _Form of expected instruction(s):_ `vmvn Q0, Q0'
-
- * uint8x16_t vmvnq_u8 (uint8x16_t)
- _Form of expected instruction(s):_ `vmvn Q0, Q0'
-
- * int32x4_t vmvnq_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vmvn Q0, Q0'
-
- * int16x8_t vmvnq_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vmvn Q0, Q0'
-
- * int8x16_t vmvnq_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vmvn Q0, Q0'
-
- * poly8x16_t vmvnq_p8 (poly8x16_t)
- _Form of expected instruction(s):_ `vmvn Q0, Q0'
-
-6.54.3.34 Count leading sign bits
-.................................
-
- * int32x2_t vcls_s32 (int32x2_t)
- _Form of expected instruction(s):_ `vcls.s32 D0, D0'
-
- * int16x4_t vcls_s16 (int16x4_t)
- _Form of expected instruction(s):_ `vcls.s16 D0, D0'
-
- * int8x8_t vcls_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vcls.s8 D0, D0'
-
- * int32x4_t vclsq_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vcls.s32 Q0, Q0'
-
- * int16x8_t vclsq_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vcls.s16 Q0, Q0'
-
- * int8x16_t vclsq_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vcls.s8 Q0, Q0'
-
-6.54.3.35 Count leading zeros
-.............................
-
- * uint32x2_t vclz_u32 (uint32x2_t)
- _Form of expected instruction(s):_ `vclz.i32 D0, D0'
-
- * uint16x4_t vclz_u16 (uint16x4_t)
- _Form of expected instruction(s):_ `vclz.i16 D0, D0'
-
- * uint8x8_t vclz_u8 (uint8x8_t)
- _Form of expected instruction(s):_ `vclz.i8 D0, D0'
-
- * int32x2_t vclz_s32 (int32x2_t)
- _Form of expected instruction(s):_ `vclz.i32 D0, D0'
-
- * int16x4_t vclz_s16 (int16x4_t)
- _Form of expected instruction(s):_ `vclz.i16 D0, D0'
-
- * int8x8_t vclz_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vclz.i8 D0, D0'
-
- * uint32x4_t vclzq_u32 (uint32x4_t)
- _Form of expected instruction(s):_ `vclz.i32 Q0, Q0'
-
- * uint16x8_t vclzq_u16 (uint16x8_t)
- _Form of expected instruction(s):_ `vclz.i16 Q0, Q0'
-
- * uint8x16_t vclzq_u8 (uint8x16_t)
- _Form of expected instruction(s):_ `vclz.i8 Q0, Q0'
-
- * int32x4_t vclzq_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vclz.i32 Q0, Q0'
-
- * int16x8_t vclzq_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vclz.i16 Q0, Q0'
-
- * int8x16_t vclzq_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vclz.i8 Q0, Q0'
-
-6.54.3.36 Count number of set bits
-..................................
-
- * uint8x8_t vcnt_u8 (uint8x8_t)
- _Form of expected instruction(s):_ `vcnt.8 D0, D0'
-
- * int8x8_t vcnt_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vcnt.8 D0, D0'
-
- * poly8x8_t vcnt_p8 (poly8x8_t)
- _Form of expected instruction(s):_ `vcnt.8 D0, D0'
-
- * uint8x16_t vcntq_u8 (uint8x16_t)
- _Form of expected instruction(s):_ `vcnt.8 Q0, Q0'
-
- * int8x16_t vcntq_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vcnt.8 Q0, Q0'
-
- * poly8x16_t vcntq_p8 (poly8x16_t)
- _Form of expected instruction(s):_ `vcnt.8 Q0, Q0'
-
-6.54.3.37 Reciprocal estimate
-.............................
-
- * float32x2_t vrecpe_f32 (float32x2_t)
- _Form of expected instruction(s):_ `vrecpe.f32 D0, D0'
-
- * uint32x2_t vrecpe_u32 (uint32x2_t)
- _Form of expected instruction(s):_ `vrecpe.u32 D0, D0'
-
- * float32x4_t vrecpeq_f32 (float32x4_t)
- _Form of expected instruction(s):_ `vrecpe.f32 Q0, Q0'
-
- * uint32x4_t vrecpeq_u32 (uint32x4_t)
- _Form of expected instruction(s):_ `vrecpe.u32 Q0, Q0'
-
-6.54.3.38 Reciprocal square-root estimate
-.........................................
-
- * float32x2_t vrsqrte_f32 (float32x2_t)
- _Form of expected instruction(s):_ `vrsqrte.f32 D0, D0'
-
- * uint32x2_t vrsqrte_u32 (uint32x2_t)
- _Form of expected instruction(s):_ `vrsqrte.u32 D0, D0'
-
- * float32x4_t vrsqrteq_f32 (float32x4_t)
- _Form of expected instruction(s):_ `vrsqrte.f32 Q0, Q0'
-
- * uint32x4_t vrsqrteq_u32 (uint32x4_t)
- _Form of expected instruction(s):_ `vrsqrte.u32 Q0, Q0'
-
-6.54.3.39 Get lanes from a vector
-.................................
-
- * uint32_t vget_lane_u32 (uint32x2_t, const int)
- _Form of expected instruction(s):_ `vmov.32 R0, D0[0]'
-
- * uint16_t vget_lane_u16 (uint16x4_t, const int)
- _Form of expected instruction(s):_ `vmov.u16 R0, D0[0]'
-
- * uint8_t vget_lane_u8 (uint8x8_t, const int)
- _Form of expected instruction(s):_ `vmov.u8 R0, D0[0]'
-
- * int32_t vget_lane_s32 (int32x2_t, const int)
- _Form of expected instruction(s):_ `vmov.32 R0, D0[0]'
-
- * int16_t vget_lane_s16 (int16x4_t, const int)
- _Form of expected instruction(s):_ `vmov.s16 R0, D0[0]'
-
- * int8_t vget_lane_s8 (int8x8_t, const int)
- _Form of expected instruction(s):_ `vmov.s8 R0, D0[0]'
-
- * float32_t vget_lane_f32 (float32x2_t, const int)
- _Form of expected instruction(s):_ `vmov.32 R0, D0[0]'
-
- * poly16_t vget_lane_p16 (poly16x4_t, const int)
- _Form of expected instruction(s):_ `vmov.u16 R0, D0[0]'
-
- * poly8_t vget_lane_p8 (poly8x8_t, const int)
- _Form of expected instruction(s):_ `vmov.u8 R0, D0[0]'
-
- * uint64_t vget_lane_u64 (uint64x1_t, const int)
-
- * int64_t vget_lane_s64 (int64x1_t, const int)
-
- * uint32_t vgetq_lane_u32 (uint32x4_t, const int)
- _Form of expected instruction(s):_ `vmov.32 R0, D0[0]'
-
- * uint16_t vgetq_lane_u16 (uint16x8_t, const int)
- _Form of expected instruction(s):_ `vmov.u16 R0, D0[0]'
-
- * uint8_t vgetq_lane_u8 (uint8x16_t, const int)
- _Form of expected instruction(s):_ `vmov.u8 R0, D0[0]'
-
- * int32_t vgetq_lane_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vmov.32 R0, D0[0]'
-
- * int16_t vgetq_lane_s16 (int16x8_t, const int)
- _Form of expected instruction(s):_ `vmov.s16 R0, D0[0]'
-
- * int8_t vgetq_lane_s8 (int8x16_t, const int)
- _Form of expected instruction(s):_ `vmov.s8 R0, D0[0]'
-
- * float32_t vgetq_lane_f32 (float32x4_t, const int)
- _Form of expected instruction(s):_ `vmov.32 R0, D0[0]'
-
- * poly16_t vgetq_lane_p16 (poly16x8_t, const int)
- _Form of expected instruction(s):_ `vmov.u16 R0, D0[0]'
-
- * poly8_t vgetq_lane_p8 (poly8x16_t, const int)
- _Form of expected instruction(s):_ `vmov.u8 R0, D0[0]'
-
- * uint64_t vgetq_lane_u64 (uint64x2_t, const int)
- _Form of expected instruction(s):_ `vmov R0, R0, D0'
-
- * int64_t vgetq_lane_s64 (int64x2_t, const int)
- _Form of expected instruction(s):_ `vmov R0, R0, D0'
-
-6.54.3.40 Set lanes in a vector
-...............................
-
- * uint32x2_t vset_lane_u32 (uint32_t, uint32x2_t, const int)
- _Form of expected instruction(s):_ `vmov.32 D0[0], R0'
-
- * uint16x4_t vset_lane_u16 (uint16_t, uint16x4_t, const int)
- _Form of expected instruction(s):_ `vmov.16 D0[0], R0'
-
- * uint8x8_t vset_lane_u8 (uint8_t, uint8x8_t, const int)
- _Form of expected instruction(s):_ `vmov.8 D0[0], R0'
-
- * int32x2_t vset_lane_s32 (int32_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vmov.32 D0[0], R0'
-
- * int16x4_t vset_lane_s16 (int16_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vmov.16 D0[0], R0'
-
- * int8x8_t vset_lane_s8 (int8_t, int8x8_t, const int)
- _Form of expected instruction(s):_ `vmov.8 D0[0], R0'
-
- * float32x2_t vset_lane_f32 (float32_t, float32x2_t, const int)
- _Form of expected instruction(s):_ `vmov.32 D0[0], R0'
-
- * poly16x4_t vset_lane_p16 (poly16_t, poly16x4_t, const int)
- _Form of expected instruction(s):_ `vmov.16 D0[0], R0'
-
- * poly8x8_t vset_lane_p8 (poly8_t, poly8x8_t, const int)
- _Form of expected instruction(s):_ `vmov.8 D0[0], R0'
-
- * uint64x1_t vset_lane_u64 (uint64_t, uint64x1_t, const int)
-
- * int64x1_t vset_lane_s64 (int64_t, int64x1_t, const int)
-
- * uint32x4_t vsetq_lane_u32 (uint32_t, uint32x4_t, const int)
- _Form of expected instruction(s):_ `vmov.32 D0[0], R0'
-
- * uint16x8_t vsetq_lane_u16 (uint16_t, uint16x8_t, const int)
- _Form of expected instruction(s):_ `vmov.16 D0[0], R0'
-
- * uint8x16_t vsetq_lane_u8 (uint8_t, uint8x16_t, const int)
- _Form of expected instruction(s):_ `vmov.8 D0[0], R0'
-
- * int32x4_t vsetq_lane_s32 (int32_t, int32x4_t, const int)
- _Form of expected instruction(s):_ `vmov.32 D0[0], R0'
-
- * int16x8_t vsetq_lane_s16 (int16_t, int16x8_t, const int)
- _Form of expected instruction(s):_ `vmov.16 D0[0], R0'
-
- * int8x16_t vsetq_lane_s8 (int8_t, int8x16_t, const int)
- _Form of expected instruction(s):_ `vmov.8 D0[0], R0'
-
- * float32x4_t vsetq_lane_f32 (float32_t, float32x4_t, const int)
- _Form of expected instruction(s):_ `vmov.32 D0[0], R0'
-
- * poly16x8_t vsetq_lane_p16 (poly16_t, poly16x8_t, const int)
- _Form of expected instruction(s):_ `vmov.16 D0[0], R0'
-
- * poly8x16_t vsetq_lane_p8 (poly8_t, poly8x16_t, const int)
- _Form of expected instruction(s):_ `vmov.8 D0[0], R0'
-
- * uint64x2_t vsetq_lane_u64 (uint64_t, uint64x2_t, const int)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
- * int64x2_t vsetq_lane_s64 (int64_t, int64x2_t, const int)
- _Form of expected instruction(s):_ `vmov D0, R0, R0'
-
-6.54.3.41 Create vector from literal bit pattern
-................................................
-
- * uint32x2_t vcreate_u32 (uint64_t)
-
- * uint16x4_t vcreate_u16 (uint64_t)
-
- * uint8x8_t vcreate_u8 (uint64_t)
-
- * int32x2_t vcreate_s32 (uint64_t)
-
- * int16x4_t vcreate_s16 (uint64_t)
-
- * int8x8_t vcreate_s8 (uint64_t)
-
- * uint64x1_t vcreate_u64 (uint64_t)
-
- * int64x1_t vcreate_s64 (uint64_t)
-
- * float32x2_t vcreate_f32 (uint64_t)
-
- * poly16x4_t vcreate_p16 (uint64_t)
-
- * poly8x8_t vcreate_p8 (uint64_t)
-
-6.54.3.42 Set all lanes to the same value
-.........................................
-
- * uint32x2_t vdup_n_u32 (uint32_t)
- _Form of expected instruction(s):_ `vdup.32 D0, R0'
-
- * uint16x4_t vdup_n_u16 (uint16_t)
- _Form of expected instruction(s):_ `vdup.16 D0, R0'
-
- * uint8x8_t vdup_n_u8 (uint8_t)
- _Form of expected instruction(s):_ `vdup.8 D0, R0'
-
- * int32x2_t vdup_n_s32 (int32_t)
- _Form of expected instruction(s):_ `vdup.32 D0, R0'
-
- * int16x4_t vdup_n_s16 (int16_t)
- _Form of expected instruction(s):_ `vdup.16 D0, R0'
-
- * int8x8_t vdup_n_s8 (int8_t)
- _Form of expected instruction(s):_ `vdup.8 D0, R0'
-
- * float32x2_t vdup_n_f32 (float32_t)
- _Form of expected instruction(s):_ `vdup.32 D0, R0'
-
- * poly16x4_t vdup_n_p16 (poly16_t)
- _Form of expected instruction(s):_ `vdup.16 D0, R0'
-
- * poly8x8_t vdup_n_p8 (poly8_t)
- _Form of expected instruction(s):_ `vdup.8 D0, R0'
-
- * uint64x1_t vdup_n_u64 (uint64_t)
-
- * int64x1_t vdup_n_s64 (int64_t)
-
- * uint32x4_t vdupq_n_u32 (uint32_t)
- _Form of expected instruction(s):_ `vdup.32 Q0, R0'
-
- * uint16x8_t vdupq_n_u16 (uint16_t)
- _Form of expected instruction(s):_ `vdup.16 Q0, R0'
-
- * uint8x16_t vdupq_n_u8 (uint8_t)
- _Form of expected instruction(s):_ `vdup.8 Q0, R0'
-
- * int32x4_t vdupq_n_s32 (int32_t)
- _Form of expected instruction(s):_ `vdup.32 Q0, R0'
-
- * int16x8_t vdupq_n_s16 (int16_t)
- _Form of expected instruction(s):_ `vdup.16 Q0, R0'
-
- * int8x16_t vdupq_n_s8 (int8_t)
- _Form of expected instruction(s):_ `vdup.8 Q0, R0'
-
- * float32x4_t vdupq_n_f32 (float32_t)
- _Form of expected instruction(s):_ `vdup.32 Q0, R0'
-
- * poly16x8_t vdupq_n_p16 (poly16_t)
- _Form of expected instruction(s):_ `vdup.16 Q0, R0'
-
- * poly8x16_t vdupq_n_p8 (poly8_t)
- _Form of expected instruction(s):_ `vdup.8 Q0, R0'
-
- * uint64x2_t vdupq_n_u64 (uint64_t)
-
- * int64x2_t vdupq_n_s64 (int64_t)
-
- * uint32x2_t vmov_n_u32 (uint32_t)
- _Form of expected instruction(s):_ `vdup.32 D0, R0'
-
- * uint16x4_t vmov_n_u16 (uint16_t)
- _Form of expected instruction(s):_ `vdup.16 D0, R0'
-
- * uint8x8_t vmov_n_u8 (uint8_t)
- _Form of expected instruction(s):_ `vdup.8 D0, R0'
-
- * int32x2_t vmov_n_s32 (int32_t)
- _Form of expected instruction(s):_ `vdup.32 D0, R0'
-
- * int16x4_t vmov_n_s16 (int16_t)
- _Form of expected instruction(s):_ `vdup.16 D0, R0'
-
- * int8x8_t vmov_n_s8 (int8_t)
- _Form of expected instruction(s):_ `vdup.8 D0, R0'
-
- * float32x2_t vmov_n_f32 (float32_t)
- _Form of expected instruction(s):_ `vdup.32 D0, R0'
-
- * poly16x4_t vmov_n_p16 (poly16_t)
- _Form of expected instruction(s):_ `vdup.16 D0, R0'
-
- * poly8x8_t vmov_n_p8 (poly8_t)
- _Form of expected instruction(s):_ `vdup.8 D0, R0'
-
- * uint64x1_t vmov_n_u64 (uint64_t)
-
- * int64x1_t vmov_n_s64 (int64_t)
-
- * uint32x4_t vmovq_n_u32 (uint32_t)
- _Form of expected instruction(s):_ `vdup.32 Q0, R0'
-
- * uint16x8_t vmovq_n_u16 (uint16_t)
- _Form of expected instruction(s):_ `vdup.16 Q0, R0'
-
- * uint8x16_t vmovq_n_u8 (uint8_t)
- _Form of expected instruction(s):_ `vdup.8 Q0, R0'
-
- * int32x4_t vmovq_n_s32 (int32_t)
- _Form of expected instruction(s):_ `vdup.32 Q0, R0'
-
- * int16x8_t vmovq_n_s16 (int16_t)
- _Form of expected instruction(s):_ `vdup.16 Q0, R0'
-
- * int8x16_t vmovq_n_s8 (int8_t)
- _Form of expected instruction(s):_ `vdup.8 Q0, R0'
-
- * float32x4_t vmovq_n_f32 (float32_t)
- _Form of expected instruction(s):_ `vdup.32 Q0, R0'
-
- * poly16x8_t vmovq_n_p16 (poly16_t)
- _Form of expected instruction(s):_ `vdup.16 Q0, R0'
-
- * poly8x16_t vmovq_n_p8 (poly8_t)
- _Form of expected instruction(s):_ `vdup.8 Q0, R0'
-
- * uint64x2_t vmovq_n_u64 (uint64_t)
-
- * int64x2_t vmovq_n_s64 (int64_t)
-
- * uint32x2_t vdup_lane_u32 (uint32x2_t, const int)
- _Form of expected instruction(s):_ `vdup.32 D0, D0[0]'
-
- * uint16x4_t vdup_lane_u16 (uint16x4_t, const int)
- _Form of expected instruction(s):_ `vdup.16 D0, D0[0]'
-
- * uint8x8_t vdup_lane_u8 (uint8x8_t, const int)
- _Form of expected instruction(s):_ `vdup.8 D0, D0[0]'
-
- * int32x2_t vdup_lane_s32 (int32x2_t, const int)
- _Form of expected instruction(s):_ `vdup.32 D0, D0[0]'
-
- * int16x4_t vdup_lane_s16 (int16x4_t, const int)
- _Form of expected instruction(s):_ `vdup.16 D0, D0[0]'
-
- * int8x8_t vdup_lane_s8 (int8x8_t, const int)
- _Form of expected instruction(s):_ `vdup.8 D0, D0[0]'
-
- * float32x2_t vdup_lane_f32 (float32x2_t, const int)
- _Form of expected instruction(s):_ `vdup.32 D0, D0[0]'
-
- * poly16x4_t vdup_lane_p16 (poly16x4_t, const int)
- _Form of expected instruction(s):_ `vdup.16 D0, D0[0]'
-
- * poly8x8_t vdup_lane_p8 (poly8x8_t, const int)
- _Form of expected instruction(s):_ `vdup.8 D0, D0[0]'
-
- * uint64x1_t vdup_lane_u64 (uint64x1_t, const int)
-
- * int64x1_t vdup_lane_s64 (int64x1_t, const int)
-
- * uint32x4_t vdupq_lane_u32 (uint32x2_t, const int)
- _Form of expected instruction(s):_ `vdup.32 Q0, D0[0]'
-
- * uint16x8_t vdupq_lane_u16 (uint16x4_t, const int)
- _Form of expected instruction(s):_ `vdup.16 Q0, D0[0]'
-
- * uint8x16_t vdupq_lane_u8 (uint8x8_t, const int)
- _Form of expected instruction(s):_ `vdup.8 Q0, D0[0]'
-
- * int32x4_t vdupq_lane_s32 (int32x2_t, const int)
- _Form of expected instruction(s):_ `vdup.32 Q0, D0[0]'
-
- * int16x8_t vdupq_lane_s16 (int16x4_t, const int)
- _Form of expected instruction(s):_ `vdup.16 Q0, D0[0]'
-
- * int8x16_t vdupq_lane_s8 (int8x8_t, const int)
- _Form of expected instruction(s):_ `vdup.8 Q0, D0[0]'
-
- * float32x4_t vdupq_lane_f32 (float32x2_t, const int)
- _Form of expected instruction(s):_ `vdup.32 Q0, D0[0]'
-
- * poly16x8_t vdupq_lane_p16 (poly16x4_t, const int)
- _Form of expected instruction(s):_ `vdup.16 Q0, D0[0]'
-
- * poly8x16_t vdupq_lane_p8 (poly8x8_t, const int)
- _Form of expected instruction(s):_ `vdup.8 Q0, D0[0]'
-
- * uint64x2_t vdupq_lane_u64 (uint64x1_t, const int)
-
- * int64x2_t vdupq_lane_s64 (int64x1_t, const int)
-
-6.54.3.43 Combining vectors
-...........................
-
- * uint32x4_t vcombine_u32 (uint32x2_t, uint32x2_t)
-
- * uint16x8_t vcombine_u16 (uint16x4_t, uint16x4_t)
-
- * uint8x16_t vcombine_u8 (uint8x8_t, uint8x8_t)
-
- * int32x4_t vcombine_s32 (int32x2_t, int32x2_t)
-
- * int16x8_t vcombine_s16 (int16x4_t, int16x4_t)
-
- * int8x16_t vcombine_s8 (int8x8_t, int8x8_t)
-
- * uint64x2_t vcombine_u64 (uint64x1_t, uint64x1_t)
-
- * int64x2_t vcombine_s64 (int64x1_t, int64x1_t)
-
- * float32x4_t vcombine_f32 (float32x2_t, float32x2_t)
-
- * poly16x8_t vcombine_p16 (poly16x4_t, poly16x4_t)
-
- * poly8x16_t vcombine_p8 (poly8x8_t, poly8x8_t)
-
-6.54.3.44 Splitting vectors
-...........................
-
- * uint32x2_t vget_high_u32 (uint32x4_t)
-
- * uint16x4_t vget_high_u16 (uint16x8_t)
-
- * uint8x8_t vget_high_u8 (uint8x16_t)
-
- * int32x2_t vget_high_s32 (int32x4_t)
-
- * int16x4_t vget_high_s16 (int16x8_t)
-
- * int8x8_t vget_high_s8 (int8x16_t)
-
- * uint64x1_t vget_high_u64 (uint64x2_t)
-
- * int64x1_t vget_high_s64 (int64x2_t)
-
- * float32x2_t vget_high_f32 (float32x4_t)
-
- * poly16x4_t vget_high_p16 (poly16x8_t)
-
- * poly8x8_t vget_high_p8 (poly8x16_t)
-
- * uint32x2_t vget_low_u32 (uint32x4_t)
- _Form of expected instruction(s):_ `vmov D0, D0'
-
- * uint16x4_t vget_low_u16 (uint16x8_t)
- _Form of expected instruction(s):_ `vmov D0, D0'
-
- * uint8x8_t vget_low_u8 (uint8x16_t)
- _Form of expected instruction(s):_ `vmov D0, D0'
-
- * int32x2_t vget_low_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vmov D0, D0'
-
- * int16x4_t vget_low_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vmov D0, D0'
-
- * int8x8_t vget_low_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vmov D0, D0'
-
- * float32x2_t vget_low_f32 (float32x4_t)
- _Form of expected instruction(s):_ `vmov D0, D0'
-
- * poly16x4_t vget_low_p16 (poly16x8_t)
- _Form of expected instruction(s):_ `vmov D0, D0'
-
- * poly8x8_t vget_low_p8 (poly8x16_t)
- _Form of expected instruction(s):_ `vmov D0, D0'
-
- * uint64x1_t vget_low_u64 (uint64x2_t)
-
- * int64x1_t vget_low_s64 (int64x2_t)
-
-6.54.3.45 Conversions
-.....................
-
- * float32x2_t vcvt_f32_u32 (uint32x2_t)
- _Form of expected instruction(s):_ `vcvt.f32.u32 D0, D0'
-
- * float32x2_t vcvt_f32_s32 (int32x2_t)
- _Form of expected instruction(s):_ `vcvt.f32.s32 D0, D0'
-
- * uint32x2_t vcvt_u32_f32 (float32x2_t)
- _Form of expected instruction(s):_ `vcvt.u32.f32 D0, D0'
-
- * int32x2_t vcvt_s32_f32 (float32x2_t)
- _Form of expected instruction(s):_ `vcvt.s32.f32 D0, D0'
-
- * float32x4_t vcvtq_f32_u32 (uint32x4_t)
- _Form of expected instruction(s):_ `vcvt.f32.u32 Q0, Q0'
-
- * float32x4_t vcvtq_f32_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vcvt.f32.s32 Q0, Q0'
-
- * uint32x4_t vcvtq_u32_f32 (float32x4_t)
- _Form of expected instruction(s):_ `vcvt.u32.f32 Q0, Q0'
-
- * int32x4_t vcvtq_s32_f32 (float32x4_t)
- _Form of expected instruction(s):_ `vcvt.s32.f32 Q0, Q0'
-
- * float32x2_t vcvt_n_f32_u32 (uint32x2_t, const int)
- _Form of expected instruction(s):_ `vcvt.f32.u32 D0, D0, #0'
-
- * float32x2_t vcvt_n_f32_s32 (int32x2_t, const int)
- _Form of expected instruction(s):_ `vcvt.f32.s32 D0, D0, #0'
-
- * uint32x2_t vcvt_n_u32_f32 (float32x2_t, const int)
- _Form of expected instruction(s):_ `vcvt.u32.f32 D0, D0, #0'
-
- * int32x2_t vcvt_n_s32_f32 (float32x2_t, const int)
- _Form of expected instruction(s):_ `vcvt.s32.f32 D0, D0, #0'
-
- * float32x4_t vcvtq_n_f32_u32 (uint32x4_t, const int)
- _Form of expected instruction(s):_ `vcvt.f32.u32 Q0, Q0, #0'
-
- * float32x4_t vcvtq_n_f32_s32 (int32x4_t, const int)
- _Form of expected instruction(s):_ `vcvt.f32.s32 Q0, Q0, #0'
-
- * uint32x4_t vcvtq_n_u32_f32 (float32x4_t, const int)
- _Form of expected instruction(s):_ `vcvt.u32.f32 Q0, Q0, #0'
-
- * int32x4_t vcvtq_n_s32_f32 (float32x4_t, const int)
- _Form of expected instruction(s):_ `vcvt.s32.f32 Q0, Q0, #0'
-
-6.54.3.46 Move, single_opcode narrowing
-.......................................
-
- * uint32x2_t vmovn_u64 (uint64x2_t)
- _Form of expected instruction(s):_ `vmovn.i64 D0, Q0'
-
- * uint16x4_t vmovn_u32 (uint32x4_t)
- _Form of expected instruction(s):_ `vmovn.i32 D0, Q0'
-
- * uint8x8_t vmovn_u16 (uint16x8_t)
- _Form of expected instruction(s):_ `vmovn.i16 D0, Q0'
-
- * int32x2_t vmovn_s64 (int64x2_t)
- _Form of expected instruction(s):_ `vmovn.i64 D0, Q0'
-
- * int16x4_t vmovn_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vmovn.i32 D0, Q0'
-
- * int8x8_t vmovn_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vmovn.i16 D0, Q0'
-
- * uint32x2_t vqmovn_u64 (uint64x2_t)
- _Form of expected instruction(s):_ `vqmovn.u64 D0, Q0'
-
- * uint16x4_t vqmovn_u32 (uint32x4_t)
- _Form of expected instruction(s):_ `vqmovn.u32 D0, Q0'
-
- * uint8x8_t vqmovn_u16 (uint16x8_t)
- _Form of expected instruction(s):_ `vqmovn.u16 D0, Q0'
-
- * int32x2_t vqmovn_s64 (int64x2_t)
- _Form of expected instruction(s):_ `vqmovn.s64 D0, Q0'
-
- * int16x4_t vqmovn_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vqmovn.s32 D0, Q0'
-
- * int8x8_t vqmovn_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vqmovn.s16 D0, Q0'
-
- * uint32x2_t vqmovun_s64 (int64x2_t)
- _Form of expected instruction(s):_ `vqmovun.s64 D0, Q0'
-
- * uint16x4_t vqmovun_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vqmovun.s32 D0, Q0'
-
- * uint8x8_t vqmovun_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vqmovun.s16 D0, Q0'
-
-6.54.3.47 Move, single_opcode long
-..................................
-
- * uint64x2_t vmovl_u32 (uint32x2_t)
- _Form of expected instruction(s):_ `vmovl.u32 Q0, D0'
-
- * uint32x4_t vmovl_u16 (uint16x4_t)
- _Form of expected instruction(s):_ `vmovl.u16 Q0, D0'
-
- * uint16x8_t vmovl_u8 (uint8x8_t)
- _Form of expected instruction(s):_ `vmovl.u8 Q0, D0'
-
- * int64x2_t vmovl_s32 (int32x2_t)
- _Form of expected instruction(s):_ `vmovl.s32 Q0, D0'
-
- * int32x4_t vmovl_s16 (int16x4_t)
- _Form of expected instruction(s):_ `vmovl.s16 Q0, D0'
-
- * int16x8_t vmovl_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vmovl.s8 Q0, D0'
-
-6.54.3.48 Table lookup
-......................
-
- * poly8x8_t vtbl1_p8 (poly8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0}, D0'
-
- * int8x8_t vtbl1_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0}, D0'
-
- * uint8x8_t vtbl1_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0}, D0'
-
- * poly8x8_t vtbl2_p8 (poly8x8x2_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0, D1}, D0'
-
- * int8x8_t vtbl2_s8 (int8x8x2_t, int8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0, D1}, D0'
-
- * uint8x8_t vtbl2_u8 (uint8x8x2_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0, D1}, D0'
-
- * poly8x8_t vtbl3_p8 (poly8x8x3_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0, D1, D2}, D0'
-
- * int8x8_t vtbl3_s8 (int8x8x3_t, int8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0, D1, D2}, D0'
-
- * uint8x8_t vtbl3_u8 (uint8x8x3_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0, D1, D2}, D0'
-
- * poly8x8_t vtbl4_p8 (poly8x8x4_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0, D1, D2, D3},
- D0'
-
- * int8x8_t vtbl4_s8 (int8x8x4_t, int8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0, D1, D2, D3},
- D0'
-
- * uint8x8_t vtbl4_u8 (uint8x8x4_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbl.8 D0, {D0, D1, D2, D3},
- D0'
-
-6.54.3.49 Extended table lookup
-...............................
-
- * poly8x8_t vtbx1_p8 (poly8x8_t, poly8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0}, D0'
-
- * int8x8_t vtbx1_s8 (int8x8_t, int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0}, D0'
-
- * uint8x8_t vtbx1_u8 (uint8x8_t, uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0}, D0'
-
- * poly8x8_t vtbx2_p8 (poly8x8_t, poly8x8x2_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0, D1}, D0'
-
- * int8x8_t vtbx2_s8 (int8x8_t, int8x8x2_t, int8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0, D1}, D0'
-
- * uint8x8_t vtbx2_u8 (uint8x8_t, uint8x8x2_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0, D1}, D0'
-
- * poly8x8_t vtbx3_p8 (poly8x8_t, poly8x8x3_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0, D1, D2}, D0'
-
- * int8x8_t vtbx3_s8 (int8x8_t, int8x8x3_t, int8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0, D1, D2}, D0'
-
- * uint8x8_t vtbx3_u8 (uint8x8_t, uint8x8x3_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0, D1, D2}, D0'
-
- * poly8x8_t vtbx4_p8 (poly8x8_t, poly8x8x4_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0, D1, D2, D3},
- D0'
-
- * int8x8_t vtbx4_s8 (int8x8_t, int8x8x4_t, int8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0, D1, D2, D3},
- D0'
-
- * uint8x8_t vtbx4_u8 (uint8x8_t, uint8x8x4_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtbx.8 D0, {D0, D1, D2, D3},
- D0'
-
-6.54.3.50 Multiply, lane
-........................
-
- * float32x2_t vmul_lane_f32 (float32x2_t, float32x2_t, const int)
- _Form of expected instruction(s):_ `vmul.f32 D0, D0, D0[0]'
-
- * uint32x2_t vmul_lane_u32 (uint32x2_t, uint32x2_t, const int)
- _Form of expected instruction(s):_ `vmul.i32 D0, D0, D0[0]'
-
- * uint16x4_t vmul_lane_u16 (uint16x4_t, uint16x4_t, const int)
- _Form of expected instruction(s):_ `vmul.i16 D0, D0, D0[0]'
-
- * int32x2_t vmul_lane_s32 (int32x2_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vmul.i32 D0, D0, D0[0]'
-
- * int16x4_t vmul_lane_s16 (int16x4_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vmul.i16 D0, D0, D0[0]'
-
- * float32x4_t vmulq_lane_f32 (float32x4_t, float32x2_t, const int)
- _Form of expected instruction(s):_ `vmul.f32 Q0, Q0, D0[0]'
-
- * uint32x4_t vmulq_lane_u32 (uint32x4_t, uint32x2_t, const int)
- _Form of expected instruction(s):_ `vmul.i32 Q0, Q0, D0[0]'
-
- * uint16x8_t vmulq_lane_u16 (uint16x8_t, uint16x4_t, const int)
- _Form of expected instruction(s):_ `vmul.i16 Q0, Q0, D0[0]'
-
- * int32x4_t vmulq_lane_s32 (int32x4_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vmul.i32 Q0, Q0, D0[0]'
-
- * int16x8_t vmulq_lane_s16 (int16x8_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vmul.i16 Q0, Q0, D0[0]'
-
-6.54.3.51 Long multiply, lane
-.............................
-
- * uint64x2_t vmull_lane_u32 (uint32x2_t, uint32x2_t, const int)
- _Form of expected instruction(s):_ `vmull.u32 Q0, D0, D0[0]'
-
- * uint32x4_t vmull_lane_u16 (uint16x4_t, uint16x4_t, const int)
- _Form of expected instruction(s):_ `vmull.u16 Q0, D0, D0[0]'
-
- * int64x2_t vmull_lane_s32 (int32x2_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vmull.s32 Q0, D0, D0[0]'
-
- * int32x4_t vmull_lane_s16 (int16x4_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vmull.s16 Q0, D0, D0[0]'
-
-6.54.3.52 Saturating doubling long multiply, lane
-.................................................
-
- * int64x2_t vqdmull_lane_s32 (int32x2_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vqdmull.s32 Q0, D0, D0[0]'
-
- * int32x4_t vqdmull_lane_s16 (int16x4_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vqdmull.s16 Q0, D0, D0[0]'
-
-6.54.3.53 Saturating doubling multiply high, lane
-.................................................
-
- * int32x4_t vqdmulhq_lane_s32 (int32x4_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vqdmulh.s32 Q0, Q0, D0[0]'
-
- * int16x8_t vqdmulhq_lane_s16 (int16x8_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vqdmulh.s16 Q0, Q0, D0[0]'
-
- * int32x2_t vqdmulh_lane_s32 (int32x2_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vqdmulh.s32 D0, D0, D0[0]'
-
- * int16x4_t vqdmulh_lane_s16 (int16x4_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vqdmulh.s16 D0, D0, D0[0]'
-
- * int32x4_t vqrdmulhq_lane_s32 (int32x4_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vqrdmulh.s32 Q0, Q0, D0[0]'
-
- * int16x8_t vqrdmulhq_lane_s16 (int16x8_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vqrdmulh.s16 Q0, Q0, D0[0]'
-
- * int32x2_t vqrdmulh_lane_s32 (int32x2_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vqrdmulh.s32 D0, D0, D0[0]'
-
- * int16x4_t vqrdmulh_lane_s16 (int16x4_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vqrdmulh.s16 D0, D0, D0[0]'
-
-6.54.3.54 Multiply-accumulate, lane
-...................................
-
- * float32x2_t vmla_lane_f32 (float32x2_t, float32x2_t, float32x2_t,
- const int)
- _Form of expected instruction(s):_ `vmla.f32 D0, D0, D0[0]'
-
- * uint32x2_t vmla_lane_u32 (uint32x2_t, uint32x2_t, uint32x2_t,
- const int)
- _Form of expected instruction(s):_ `vmla.i32 D0, D0, D0[0]'
-
- * uint16x4_t vmla_lane_u16 (uint16x4_t, uint16x4_t, uint16x4_t,
- const int)
- _Form of expected instruction(s):_ `vmla.i16 D0, D0, D0[0]'
-
- * int32x2_t vmla_lane_s32 (int32x2_t, int32x2_t, int32x2_t, const
- int)
- _Form of expected instruction(s):_ `vmla.i32 D0, D0, D0[0]'
-
- * int16x4_t vmla_lane_s16 (int16x4_t, int16x4_t, int16x4_t, const
- int)
- _Form of expected instruction(s):_ `vmla.i16 D0, D0, D0[0]'
-
- * float32x4_t vmlaq_lane_f32 (float32x4_t, float32x4_t, float32x2_t,
- const int)
- _Form of expected instruction(s):_ `vmla.f32 Q0, Q0, D0[0]'
-
- * uint32x4_t vmlaq_lane_u32 (uint32x4_t, uint32x4_t, uint32x2_t,
- const int)
- _Form of expected instruction(s):_ `vmla.i32 Q0, Q0, D0[0]'
-
- * uint16x8_t vmlaq_lane_u16 (uint16x8_t, uint16x8_t, uint16x4_t,
- const int)
- _Form of expected instruction(s):_ `vmla.i16 Q0, Q0, D0[0]'
-
- * int32x4_t vmlaq_lane_s32 (int32x4_t, int32x4_t, int32x2_t, const
- int)
- _Form of expected instruction(s):_ `vmla.i32 Q0, Q0, D0[0]'
-
- * int16x8_t vmlaq_lane_s16 (int16x8_t, int16x8_t, int16x4_t, const
- int)
- _Form of expected instruction(s):_ `vmla.i16 Q0, Q0, D0[0]'
-
- * uint64x2_t vmlal_lane_u32 (uint64x2_t, uint32x2_t, uint32x2_t,
- const int)
- _Form of expected instruction(s):_ `vmlal.u32 Q0, D0, D0[0]'
-
- * uint32x4_t vmlal_lane_u16 (uint32x4_t, uint16x4_t, uint16x4_t,
- const int)
- _Form of expected instruction(s):_ `vmlal.u16 Q0, D0, D0[0]'
-
- * int64x2_t vmlal_lane_s32 (int64x2_t, int32x2_t, int32x2_t, const
- int)
- _Form of expected instruction(s):_ `vmlal.s32 Q0, D0, D0[0]'
-
- * int32x4_t vmlal_lane_s16 (int32x4_t, int16x4_t, int16x4_t, const
- int)
- _Form of expected instruction(s):_ `vmlal.s16 Q0, D0, D0[0]'
-
- * int64x2_t vqdmlal_lane_s32 (int64x2_t, int32x2_t, int32x2_t, const
- int)
- _Form of expected instruction(s):_ `vqdmlal.s32 Q0, D0, D0[0]'
-
- * int32x4_t vqdmlal_lane_s16 (int32x4_t, int16x4_t, int16x4_t, const
- int)
- _Form of expected instruction(s):_ `vqdmlal.s16 Q0, D0, D0[0]'
-
-6.54.3.55 Multiply-subtract, lane
-.................................
-
- * float32x2_t vmls_lane_f32 (float32x2_t, float32x2_t, float32x2_t,
- const int)
- _Form of expected instruction(s):_ `vmls.f32 D0, D0, D0[0]'
-
- * uint32x2_t vmls_lane_u32 (uint32x2_t, uint32x2_t, uint32x2_t,
- const int)
- _Form of expected instruction(s):_ `vmls.i32 D0, D0, D0[0]'
-
- * uint16x4_t vmls_lane_u16 (uint16x4_t, uint16x4_t, uint16x4_t,
- const int)
- _Form of expected instruction(s):_ `vmls.i16 D0, D0, D0[0]'
-
- * int32x2_t vmls_lane_s32 (int32x2_t, int32x2_t, int32x2_t, const
- int)
- _Form of expected instruction(s):_ `vmls.i32 D0, D0, D0[0]'
-
- * int16x4_t vmls_lane_s16 (int16x4_t, int16x4_t, int16x4_t, const
- int)
- _Form of expected instruction(s):_ `vmls.i16 D0, D0, D0[0]'
-
- * float32x4_t vmlsq_lane_f32 (float32x4_t, float32x4_t, float32x2_t,
- const int)
- _Form of expected instruction(s):_ `vmls.f32 Q0, Q0, D0[0]'
-
- * uint32x4_t vmlsq_lane_u32 (uint32x4_t, uint32x4_t, uint32x2_t,
- const int)
- _Form of expected instruction(s):_ `vmls.i32 Q0, Q0, D0[0]'
-
- * uint16x8_t vmlsq_lane_u16 (uint16x8_t, uint16x8_t, uint16x4_t,
- const int)
- _Form of expected instruction(s):_ `vmls.i16 Q0, Q0, D0[0]'
-
- * int32x4_t vmlsq_lane_s32 (int32x4_t, int32x4_t, int32x2_t, const
- int)
- _Form of expected instruction(s):_ `vmls.i32 Q0, Q0, D0[0]'
-
- * int16x8_t vmlsq_lane_s16 (int16x8_t, int16x8_t, int16x4_t, const
- int)
- _Form of expected instruction(s):_ `vmls.i16 Q0, Q0, D0[0]'
-
- * uint64x2_t vmlsl_lane_u32 (uint64x2_t, uint32x2_t, uint32x2_t,
- const int)
- _Form of expected instruction(s):_ `vmlsl.u32 Q0, D0, D0[0]'
-
- * uint32x4_t vmlsl_lane_u16 (uint32x4_t, uint16x4_t, uint16x4_t,
- const int)
- _Form of expected instruction(s):_ `vmlsl.u16 Q0, D0, D0[0]'
-
- * int64x2_t vmlsl_lane_s32 (int64x2_t, int32x2_t, int32x2_t, const
- int)
- _Form of expected instruction(s):_ `vmlsl.s32 Q0, D0, D0[0]'
-
- * int32x4_t vmlsl_lane_s16 (int32x4_t, int16x4_t, int16x4_t, const
- int)
- _Form of expected instruction(s):_ `vmlsl.s16 Q0, D0, D0[0]'
-
- * int64x2_t vqdmlsl_lane_s32 (int64x2_t, int32x2_t, int32x2_t, const
- int)
- _Form of expected instruction(s):_ `vqdmlsl.s32 Q0, D0, D0[0]'
-
- * int32x4_t vqdmlsl_lane_s16 (int32x4_t, int16x4_t, int16x4_t, const
- int)
- _Form of expected instruction(s):_ `vqdmlsl.s16 Q0, D0, D0[0]'
-
-6.54.3.56 Vector multiply by scalar
-...................................
-
- * float32x2_t vmul_n_f32 (float32x2_t, float32_t)
- _Form of expected instruction(s):_ `vmul.f32 D0, D0, D0[0]'
-
- * uint32x2_t vmul_n_u32 (uint32x2_t, uint32_t)
- _Form of expected instruction(s):_ `vmul.i32 D0, D0, D0[0]'
-
- * uint16x4_t vmul_n_u16 (uint16x4_t, uint16_t)
- _Form of expected instruction(s):_ `vmul.i16 D0, D0, D0[0]'
-
- * int32x2_t vmul_n_s32 (int32x2_t, int32_t)
- _Form of expected instruction(s):_ `vmul.i32 D0, D0, D0[0]'
-
- * int16x4_t vmul_n_s16 (int16x4_t, int16_t)
- _Form of expected instruction(s):_ `vmul.i16 D0, D0, D0[0]'
-
- * float32x4_t vmulq_n_f32 (float32x4_t, float32_t)
- _Form of expected instruction(s):_ `vmul.f32 Q0, Q0, D0[0]'
-
- * uint32x4_t vmulq_n_u32 (uint32x4_t, uint32_t)
- _Form of expected instruction(s):_ `vmul.i32 Q0, Q0, D0[0]'
-
- * uint16x8_t vmulq_n_u16 (uint16x8_t, uint16_t)
- _Form of expected instruction(s):_ `vmul.i16 Q0, Q0, D0[0]'
-
- * int32x4_t vmulq_n_s32 (int32x4_t, int32_t)
- _Form of expected instruction(s):_ `vmul.i32 Q0, Q0, D0[0]'
-
- * int16x8_t vmulq_n_s16 (int16x8_t, int16_t)
- _Form of expected instruction(s):_ `vmul.i16 Q0, Q0, D0[0]'
-
-6.54.3.57 Vector long multiply by scalar
-........................................
-
- * uint64x2_t vmull_n_u32 (uint32x2_t, uint32_t)
- _Form of expected instruction(s):_ `vmull.u32 Q0, D0, D0[0]'
-
- * uint32x4_t vmull_n_u16 (uint16x4_t, uint16_t)
- _Form of expected instruction(s):_ `vmull.u16 Q0, D0, D0[0]'
-
- * int64x2_t vmull_n_s32 (int32x2_t, int32_t)
- _Form of expected instruction(s):_ `vmull.s32 Q0, D0, D0[0]'
-
- * int32x4_t vmull_n_s16 (int16x4_t, int16_t)
- _Form of expected instruction(s):_ `vmull.s16 Q0, D0, D0[0]'
-
-6.54.3.58 Vector saturating doubling long multiply by scalar
-............................................................
-
- * int64x2_t vqdmull_n_s32 (int32x2_t, int32_t)
- _Form of expected instruction(s):_ `vqdmull.s32 Q0, D0, D0[0]'
-
- * int32x4_t vqdmull_n_s16 (int16x4_t, int16_t)
- _Form of expected instruction(s):_ `vqdmull.s16 Q0, D0, D0[0]'
-
-6.54.3.59 Vector saturating doubling multiply high by scalar
-............................................................
-
- * int32x4_t vqdmulhq_n_s32 (int32x4_t, int32_t)
- _Form of expected instruction(s):_ `vqdmulh.s32 Q0, Q0, D0[0]'
-
- * int16x8_t vqdmulhq_n_s16 (int16x8_t, int16_t)
- _Form of expected instruction(s):_ `vqdmulh.s16 Q0, Q0, D0[0]'
-
- * int32x2_t vqdmulh_n_s32 (int32x2_t, int32_t)
- _Form of expected instruction(s):_ `vqdmulh.s32 D0, D0, D0[0]'
-
- * int16x4_t vqdmulh_n_s16 (int16x4_t, int16_t)
- _Form of expected instruction(s):_ `vqdmulh.s16 D0, D0, D0[0]'
-
- * int32x4_t vqrdmulhq_n_s32 (int32x4_t, int32_t)
- _Form of expected instruction(s):_ `vqrdmulh.s32 Q0, Q0, D0[0]'
-
- * int16x8_t vqrdmulhq_n_s16 (int16x8_t, int16_t)
- _Form of expected instruction(s):_ `vqrdmulh.s16 Q0, Q0, D0[0]'
-
- * int32x2_t vqrdmulh_n_s32 (int32x2_t, int32_t)
- _Form of expected instruction(s):_ `vqrdmulh.s32 D0, D0, D0[0]'
-
- * int16x4_t vqrdmulh_n_s16 (int16x4_t, int16_t)
- _Form of expected instruction(s):_ `vqrdmulh.s16 D0, D0, D0[0]'
-
-6.54.3.60 Vector multiply-accumulate by scalar
-..............................................
-
- * float32x2_t vmla_n_f32 (float32x2_t, float32x2_t, float32_t)
- _Form of expected instruction(s):_ `vmla.f32 D0, D0, D0[0]'
-
- * uint32x2_t vmla_n_u32 (uint32x2_t, uint32x2_t, uint32_t)
- _Form of expected instruction(s):_ `vmla.i32 D0, D0, D0[0]'
-
- * uint16x4_t vmla_n_u16 (uint16x4_t, uint16x4_t, uint16_t)
- _Form of expected instruction(s):_ `vmla.i16 D0, D0, D0[0]'
-
- * int32x2_t vmla_n_s32 (int32x2_t, int32x2_t, int32_t)
- _Form of expected instruction(s):_ `vmla.i32 D0, D0, D0[0]'
-
- * int16x4_t vmla_n_s16 (int16x4_t, int16x4_t, int16_t)
- _Form of expected instruction(s):_ `vmla.i16 D0, D0, D0[0]'
-
- * float32x4_t vmlaq_n_f32 (float32x4_t, float32x4_t, float32_t)
- _Form of expected instruction(s):_ `vmla.f32 Q0, Q0, D0[0]'
-
- * uint32x4_t vmlaq_n_u32 (uint32x4_t, uint32x4_t, uint32_t)
- _Form of expected instruction(s):_ `vmla.i32 Q0, Q0, D0[0]'
-
- * uint16x8_t vmlaq_n_u16 (uint16x8_t, uint16x8_t, uint16_t)
- _Form of expected instruction(s):_ `vmla.i16 Q0, Q0, D0[0]'
-
- * int32x4_t vmlaq_n_s32 (int32x4_t, int32x4_t, int32_t)
- _Form of expected instruction(s):_ `vmla.i32 Q0, Q0, D0[0]'
-
- * int16x8_t vmlaq_n_s16 (int16x8_t, int16x8_t, int16_t)
- _Form of expected instruction(s):_ `vmla.i16 Q0, Q0, D0[0]'
-
- * uint64x2_t vmlal_n_u32 (uint64x2_t, uint32x2_t, uint32_t)
- _Form of expected instruction(s):_ `vmlal.u32 Q0, D0, D0[0]'
-
- * uint32x4_t vmlal_n_u16 (uint32x4_t, uint16x4_t, uint16_t)
- _Form of expected instruction(s):_ `vmlal.u16 Q0, D0, D0[0]'
-
- * int64x2_t vmlal_n_s32 (int64x2_t, int32x2_t, int32_t)
- _Form of expected instruction(s):_ `vmlal.s32 Q0, D0, D0[0]'
-
- * int32x4_t vmlal_n_s16 (int32x4_t, int16x4_t, int16_t)
- _Form of expected instruction(s):_ `vmlal.s16 Q0, D0, D0[0]'
-
- * int64x2_t vqdmlal_n_s32 (int64x2_t, int32x2_t, int32_t)
- _Form of expected instruction(s):_ `vqdmlal.s32 Q0, D0, D0[0]'
-
- * int32x4_t vqdmlal_n_s16 (int32x4_t, int16x4_t, int16_t)
- _Form of expected instruction(s):_ `vqdmlal.s16 Q0, D0, D0[0]'
-
-6.54.3.61 Vector multiply-subtract by scalar
-............................................
-
- * float32x2_t vmls_n_f32 (float32x2_t, float32x2_t, float32_t)
- _Form of expected instruction(s):_ `vmls.f32 D0, D0, D0[0]'
-
- * uint32x2_t vmls_n_u32 (uint32x2_t, uint32x2_t, uint32_t)
- _Form of expected instruction(s):_ `vmls.i32 D0, D0, D0[0]'
-
- * uint16x4_t vmls_n_u16 (uint16x4_t, uint16x4_t, uint16_t)
- _Form of expected instruction(s):_ `vmls.i16 D0, D0, D0[0]'
-
- * int32x2_t vmls_n_s32 (int32x2_t, int32x2_t, int32_t)
- _Form of expected instruction(s):_ `vmls.i32 D0, D0, D0[0]'
-
- * int16x4_t vmls_n_s16 (int16x4_t, int16x4_t, int16_t)
- _Form of expected instruction(s):_ `vmls.i16 D0, D0, D0[0]'
-
- * float32x4_t vmlsq_n_f32 (float32x4_t, float32x4_t, float32_t)
- _Form of expected instruction(s):_ `vmls.f32 Q0, Q0, D0[0]'
-
- * uint32x4_t vmlsq_n_u32 (uint32x4_t, uint32x4_t, uint32_t)
- _Form of expected instruction(s):_ `vmls.i32 Q0, Q0, D0[0]'
-
- * uint16x8_t vmlsq_n_u16 (uint16x8_t, uint16x8_t, uint16_t)
- _Form of expected instruction(s):_ `vmls.i16 Q0, Q0, D0[0]'
-
- * int32x4_t vmlsq_n_s32 (int32x4_t, int32x4_t, int32_t)
- _Form of expected instruction(s):_ `vmls.i32 Q0, Q0, D0[0]'
-
- * int16x8_t vmlsq_n_s16 (int16x8_t, int16x8_t, int16_t)
- _Form of expected instruction(s):_ `vmls.i16 Q0, Q0, D0[0]'
-
- * uint64x2_t vmlsl_n_u32 (uint64x2_t, uint32x2_t, uint32_t)
- _Form of expected instruction(s):_ `vmlsl.u32 Q0, D0, D0[0]'
-
- * uint32x4_t vmlsl_n_u16 (uint32x4_t, uint16x4_t, uint16_t)
- _Form of expected instruction(s):_ `vmlsl.u16 Q0, D0, D0[0]'
-
- * int64x2_t vmlsl_n_s32 (int64x2_t, int32x2_t, int32_t)
- _Form of expected instruction(s):_ `vmlsl.s32 Q0, D0, D0[0]'
-
- * int32x4_t vmlsl_n_s16 (int32x4_t, int16x4_t, int16_t)
- _Form of expected instruction(s):_ `vmlsl.s16 Q0, D0, D0[0]'
-
- * int64x2_t vqdmlsl_n_s32 (int64x2_t, int32x2_t, int32_t)
- _Form of expected instruction(s):_ `vqdmlsl.s32 Q0, D0, D0[0]'
-
- * int32x4_t vqdmlsl_n_s16 (int32x4_t, int16x4_t, int16_t)
- _Form of expected instruction(s):_ `vqdmlsl.s16 Q0, D0, D0[0]'
-
-6.54.3.62 Vector extract
-........................
-
- * uint32x2_t vext_u32 (uint32x2_t, uint32x2_t, const int)
- _Form of expected instruction(s):_ `vext.32 D0, D0, D0, #0'
-
- * uint16x4_t vext_u16 (uint16x4_t, uint16x4_t, const int)
- _Form of expected instruction(s):_ `vext.16 D0, D0, D0, #0'
-
- * uint8x8_t vext_u8 (uint8x8_t, uint8x8_t, const int)
- _Form of expected instruction(s):_ `vext.8 D0, D0, D0, #0'
-
- * int32x2_t vext_s32 (int32x2_t, int32x2_t, const int)
- _Form of expected instruction(s):_ `vext.32 D0, D0, D0, #0'
-
- * int16x4_t vext_s16 (int16x4_t, int16x4_t, const int)
- _Form of expected instruction(s):_ `vext.16 D0, D0, D0, #0'
-
- * int8x8_t vext_s8 (int8x8_t, int8x8_t, const int)
- _Form of expected instruction(s):_ `vext.8 D0, D0, D0, #0'
-
- * uint64x1_t vext_u64 (uint64x1_t, uint64x1_t, const int)
- _Form of expected instruction(s):_ `vext.64 D0, D0, D0, #0'
-
- * int64x1_t vext_s64 (int64x1_t, int64x1_t, const int)
- _Form of expected instruction(s):_ `vext.64 D0, D0, D0, #0'
-
- * float32x2_t vext_f32 (float32x2_t, float32x2_t, const int)
- _Form of expected instruction(s):_ `vext.32 D0, D0, D0, #0'
-
- * poly16x4_t vext_p16 (poly16x4_t, poly16x4_t, const int)
- _Form of expected instruction(s):_ `vext.16 D0, D0, D0, #0'
-
- * poly8x8_t vext_p8 (poly8x8_t, poly8x8_t, const int)
- _Form of expected instruction(s):_ `vext.8 D0, D0, D0, #0'
-
- * uint32x4_t vextq_u32 (uint32x4_t, uint32x4_t, const int)
- _Form of expected instruction(s):_ `vext.32 Q0, Q0, Q0, #0'
-
- * uint16x8_t vextq_u16 (uint16x8_t, uint16x8_t, const int)
- _Form of expected instruction(s):_ `vext.16 Q0, Q0, Q0, #0'
-
- * uint8x16_t vextq_u8 (uint8x16_t, uint8x16_t, const int)
- _Form of expected instruction(s):_ `vext.8 Q0, Q0, Q0, #0'
-
- * int32x4_t vextq_s32 (int32x4_t, int32x4_t, const int)
- _Form of expected instruction(s):_ `vext.32 Q0, Q0, Q0, #0'
-
- * int16x8_t vextq_s16 (int16x8_t, int16x8_t, const int)
- _Form of expected instruction(s):_ `vext.16 Q0, Q0, Q0, #0'
-
- * int8x16_t vextq_s8 (int8x16_t, int8x16_t, const int)
- _Form of expected instruction(s):_ `vext.8 Q0, Q0, Q0, #0'
-
- * uint64x2_t vextq_u64 (uint64x2_t, uint64x2_t, const int)
- _Form of expected instruction(s):_ `vext.64 Q0, Q0, Q0, #0'
-
- * int64x2_t vextq_s64 (int64x2_t, int64x2_t, const int)
- _Form of expected instruction(s):_ `vext.64 Q0, Q0, Q0, #0'
-
- * float32x4_t vextq_f32 (float32x4_t, float32x4_t, const int)
- _Form of expected instruction(s):_ `vext.32 Q0, Q0, Q0, #0'
-
- * poly16x8_t vextq_p16 (poly16x8_t, poly16x8_t, const int)
- _Form of expected instruction(s):_ `vext.16 Q0, Q0, Q0, #0'
-
- * poly8x16_t vextq_p8 (poly8x16_t, poly8x16_t, const int)
- _Form of expected instruction(s):_ `vext.8 Q0, Q0, Q0, #0'
-
-6.54.3.63 Reverse elements
-..........................
-
- * uint32x2_t vrev64_u32 (uint32x2_t)
- _Form of expected instruction(s):_ `vrev64.32 D0, D0'
-
- * uint16x4_t vrev64_u16 (uint16x4_t)
- _Form of expected instruction(s):_ `vrev64.16 D0, D0'
-
- * uint8x8_t vrev64_u8 (uint8x8_t)
- _Form of expected instruction(s):_ `vrev64.8 D0, D0'
-
- * int32x2_t vrev64_s32 (int32x2_t)
- _Form of expected instruction(s):_ `vrev64.32 D0, D0'
-
- * int16x4_t vrev64_s16 (int16x4_t)
- _Form of expected instruction(s):_ `vrev64.16 D0, D0'
-
- * int8x8_t vrev64_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vrev64.8 D0, D0'
-
- * float32x2_t vrev64_f32 (float32x2_t)
- _Form of expected instruction(s):_ `vrev64.32 D0, D0'
-
- * poly16x4_t vrev64_p16 (poly16x4_t)
- _Form of expected instruction(s):_ `vrev64.16 D0, D0'
-
- * poly8x8_t vrev64_p8 (poly8x8_t)
- _Form of expected instruction(s):_ `vrev64.8 D0, D0'
-
- * uint32x4_t vrev64q_u32 (uint32x4_t)
- _Form of expected instruction(s):_ `vrev64.32 Q0, Q0'
-
- * uint16x8_t vrev64q_u16 (uint16x8_t)
- _Form of expected instruction(s):_ `vrev64.16 Q0, Q0'
-
- * uint8x16_t vrev64q_u8 (uint8x16_t)
- _Form of expected instruction(s):_ `vrev64.8 Q0, Q0'
-
- * int32x4_t vrev64q_s32 (int32x4_t)
- _Form of expected instruction(s):_ `vrev64.32 Q0, Q0'
-
- * int16x8_t vrev64q_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vrev64.16 Q0, Q0'
-
- * int8x16_t vrev64q_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vrev64.8 Q0, Q0'
-
- * float32x4_t vrev64q_f32 (float32x4_t)
- _Form of expected instruction(s):_ `vrev64.32 Q0, Q0'
-
- * poly16x8_t vrev64q_p16 (poly16x8_t)
- _Form of expected instruction(s):_ `vrev64.16 Q0, Q0'
-
- * poly8x16_t vrev64q_p8 (poly8x16_t)
- _Form of expected instruction(s):_ `vrev64.8 Q0, Q0'
-
- * uint16x4_t vrev32_u16 (uint16x4_t)
- _Form of expected instruction(s):_ `vrev32.16 D0, D0'
-
- * int16x4_t vrev32_s16 (int16x4_t)
- _Form of expected instruction(s):_ `vrev32.16 D0, D0'
-
- * uint8x8_t vrev32_u8 (uint8x8_t)
- _Form of expected instruction(s):_ `vrev32.8 D0, D0'
-
- * int8x8_t vrev32_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vrev32.8 D0, D0'
-
- * poly16x4_t vrev32_p16 (poly16x4_t)
- _Form of expected instruction(s):_ `vrev32.16 D0, D0'
-
- * poly8x8_t vrev32_p8 (poly8x8_t)
- _Form of expected instruction(s):_ `vrev32.8 D0, D0'
-
- * uint16x8_t vrev32q_u16 (uint16x8_t)
- _Form of expected instruction(s):_ `vrev32.16 Q0, Q0'
-
- * int16x8_t vrev32q_s16 (int16x8_t)
- _Form of expected instruction(s):_ `vrev32.16 Q0, Q0'
-
- * uint8x16_t vrev32q_u8 (uint8x16_t)
- _Form of expected instruction(s):_ `vrev32.8 Q0, Q0'
-
- * int8x16_t vrev32q_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vrev32.8 Q0, Q0'
-
- * poly16x8_t vrev32q_p16 (poly16x8_t)
- _Form of expected instruction(s):_ `vrev32.16 Q0, Q0'
-
- * poly8x16_t vrev32q_p8 (poly8x16_t)
- _Form of expected instruction(s):_ `vrev32.8 Q0, Q0'
-
- * uint8x8_t vrev16_u8 (uint8x8_t)
- _Form of expected instruction(s):_ `vrev16.8 D0, D0'
-
- * int8x8_t vrev16_s8 (int8x8_t)
- _Form of expected instruction(s):_ `vrev16.8 D0, D0'
-
- * poly8x8_t vrev16_p8 (poly8x8_t)
- _Form of expected instruction(s):_ `vrev16.8 D0, D0'
-
- * uint8x16_t vrev16q_u8 (uint8x16_t)
- _Form of expected instruction(s):_ `vrev16.8 Q0, Q0'
-
- * int8x16_t vrev16q_s8 (int8x16_t)
- _Form of expected instruction(s):_ `vrev16.8 Q0, Q0'
-
- * poly8x16_t vrev16q_p8 (poly8x16_t)
- _Form of expected instruction(s):_ `vrev16.8 Q0, Q0'
-
-6.54.3.64 Bit selection
-.......................
-
- * uint32x2_t vbsl_u32 (uint32x2_t, uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vbsl D0, D0, D0' _or_ `vbit
- D0, D0, D0' _or_ `vbif D0, D0, D0'
-
- * uint16x4_t vbsl_u16 (uint16x4_t, uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vbsl D0, D0, D0' _or_ `vbit
- D0, D0, D0' _or_ `vbif D0, D0, D0'
-
- * uint8x8_t vbsl_u8 (uint8x8_t, uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vbsl D0, D0, D0' _or_ `vbit
- D0, D0, D0' _or_ `vbif D0, D0, D0'
-
- * int32x2_t vbsl_s32 (uint32x2_t, int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vbsl D0, D0, D0' _or_ `vbit
- D0, D0, D0' _or_ `vbif D0, D0, D0'
-
- * int16x4_t vbsl_s16 (uint16x4_t, int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vbsl D0, D0, D0' _or_ `vbit
- D0, D0, D0' _or_ `vbif D0, D0, D0'
-
- * int8x8_t vbsl_s8 (uint8x8_t, int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vbsl D0, D0, D0' _or_ `vbit
- D0, D0, D0' _or_ `vbif D0, D0, D0'
-
- * uint64x1_t vbsl_u64 (uint64x1_t, uint64x1_t, uint64x1_t)
- _Form of expected instruction(s):_ `vbsl D0, D0, D0' _or_ `vbit
- D0, D0, D0' _or_ `vbif D0, D0, D0'
-
- * int64x1_t vbsl_s64 (uint64x1_t, int64x1_t, int64x1_t)
- _Form of expected instruction(s):_ `vbsl D0, D0, D0' _or_ `vbit
- D0, D0, D0' _or_ `vbif D0, D0, D0'
-
- * float32x2_t vbsl_f32 (uint32x2_t, float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vbsl D0, D0, D0' _or_ `vbit
- D0, D0, D0' _or_ `vbif D0, D0, D0'
-
- * poly16x4_t vbsl_p16 (uint16x4_t, poly16x4_t, poly16x4_t)
- _Form of expected instruction(s):_ `vbsl D0, D0, D0' _or_ `vbit
- D0, D0, D0' _or_ `vbif D0, D0, D0'
-
- * poly8x8_t vbsl_p8 (uint8x8_t, poly8x8_t, poly8x8_t)
- _Form of expected instruction(s):_ `vbsl D0, D0, D0' _or_ `vbit
- D0, D0, D0' _or_ `vbif D0, D0, D0'
-
- * uint32x4_t vbslq_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vbsl Q0, Q0, Q0' _or_ `vbit
- Q0, Q0, Q0' _or_ `vbif Q0, Q0, Q0'
-
- * uint16x8_t vbslq_u16 (uint16x8_t, uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vbsl Q0, Q0, Q0' _or_ `vbit
- Q0, Q0, Q0' _or_ `vbif Q0, Q0, Q0'
-
- * uint8x16_t vbslq_u8 (uint8x16_t, uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vbsl Q0, Q0, Q0' _or_ `vbit
- Q0, Q0, Q0' _or_ `vbif Q0, Q0, Q0'
-
- * int32x4_t vbslq_s32 (uint32x4_t, int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vbsl Q0, Q0, Q0' _or_ `vbit
- Q0, Q0, Q0' _or_ `vbif Q0, Q0, Q0'
-
- * int16x8_t vbslq_s16 (uint16x8_t, int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vbsl Q0, Q0, Q0' _or_ `vbit
- Q0, Q0, Q0' _or_ `vbif Q0, Q0, Q0'
-
- * int8x16_t vbslq_s8 (uint8x16_t, int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vbsl Q0, Q0, Q0' _or_ `vbit
- Q0, Q0, Q0' _or_ `vbif Q0, Q0, Q0'
-
- * uint64x2_t vbslq_u64 (uint64x2_t, uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vbsl Q0, Q0, Q0' _or_ `vbit
- Q0, Q0, Q0' _or_ `vbif Q0, Q0, Q0'
-
- * int64x2_t vbslq_s64 (uint64x2_t, int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vbsl Q0, Q0, Q0' _or_ `vbit
- Q0, Q0, Q0' _or_ `vbif Q0, Q0, Q0'
-
- * float32x4_t vbslq_f32 (uint32x4_t, float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vbsl Q0, Q0, Q0' _or_ `vbit
- Q0, Q0, Q0' _or_ `vbif Q0, Q0, Q0'
-
- * poly16x8_t vbslq_p16 (uint16x8_t, poly16x8_t, poly16x8_t)
- _Form of expected instruction(s):_ `vbsl Q0, Q0, Q0' _or_ `vbit
- Q0, Q0, Q0' _or_ `vbif Q0, Q0, Q0'
-
- * poly8x16_t vbslq_p8 (uint8x16_t, poly8x16_t, poly8x16_t)
- _Form of expected instruction(s):_ `vbsl Q0, Q0, Q0' _or_ `vbit
- Q0, Q0, Q0' _or_ `vbif Q0, Q0, Q0'
-
-6.54.3.65 Transpose elements
-............................
-
- * uint32x2x2_t vtrn_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vtrn.32 D0, D1'
-
- * uint16x4x2_t vtrn_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vtrn.16 D0, D1'
-
- * uint8x8x2_t vtrn_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vtrn.8 D0, D1'
-
- * int32x2x2_t vtrn_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vtrn.32 D0, D1'
-
- * int16x4x2_t vtrn_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vtrn.16 D0, D1'
-
- * int8x8x2_t vtrn_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vtrn.8 D0, D1'
-
- * float32x2x2_t vtrn_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vtrn.32 D0, D1'
-
- * poly16x4x2_t vtrn_p16 (poly16x4_t, poly16x4_t)
- _Form of expected instruction(s):_ `vtrn.16 D0, D1'
-
- * poly8x8x2_t vtrn_p8 (poly8x8_t, poly8x8_t)
- _Form of expected instruction(s):_ `vtrn.8 D0, D1'
-
- * uint32x4x2_t vtrnq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vtrn.32 Q0, Q1'
-
- * uint16x8x2_t vtrnq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vtrn.16 Q0, Q1'
-
- * uint8x16x2_t vtrnq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vtrn.8 Q0, Q1'
-
- * int32x4x2_t vtrnq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vtrn.32 Q0, Q1'
-
- * int16x8x2_t vtrnq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vtrn.16 Q0, Q1'
-
- * int8x16x2_t vtrnq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vtrn.8 Q0, Q1'
-
- * float32x4x2_t vtrnq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vtrn.32 Q0, Q1'
-
- * poly16x8x2_t vtrnq_p16 (poly16x8_t, poly16x8_t)
- _Form of expected instruction(s):_ `vtrn.16 Q0, Q1'
-
- * poly8x16x2_t vtrnq_p8 (poly8x16_t, poly8x16_t)
- _Form of expected instruction(s):_ `vtrn.8 Q0, Q1'
-
-6.54.3.66 Zip elements
-......................
-
- * uint32x2x2_t vzip_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vzip.32 D0, D1'
-
- * uint16x4x2_t vzip_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vzip.16 D0, D1'
-
- * uint8x8x2_t vzip_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vzip.8 D0, D1'
-
- * int32x2x2_t vzip_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vzip.32 D0, D1'
-
- * int16x4x2_t vzip_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vzip.16 D0, D1'
-
- * int8x8x2_t vzip_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vzip.8 D0, D1'
-
- * float32x2x2_t vzip_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vzip.32 D0, D1'
-
- * poly16x4x2_t vzip_p16 (poly16x4_t, poly16x4_t)
- _Form of expected instruction(s):_ `vzip.16 D0, D1'
-
- * poly8x8x2_t vzip_p8 (poly8x8_t, poly8x8_t)
- _Form of expected instruction(s):_ `vzip.8 D0, D1'
-
- * uint32x4x2_t vzipq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vzip.32 Q0, Q1'
-
- * uint16x8x2_t vzipq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vzip.16 Q0, Q1'
-
- * uint8x16x2_t vzipq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vzip.8 Q0, Q1'
-
- * int32x4x2_t vzipq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vzip.32 Q0, Q1'
-
- * int16x8x2_t vzipq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vzip.16 Q0, Q1'
-
- * int8x16x2_t vzipq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vzip.8 Q0, Q1'
-
- * float32x4x2_t vzipq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vzip.32 Q0, Q1'
-
- * poly16x8x2_t vzipq_p16 (poly16x8_t, poly16x8_t)
- _Form of expected instruction(s):_ `vzip.16 Q0, Q1'
-
- * poly8x16x2_t vzipq_p8 (poly8x16_t, poly8x16_t)
- _Form of expected instruction(s):_ `vzip.8 Q0, Q1'
-
-6.54.3.67 Unzip elements
-........................
-
- * uint32x2x2_t vuzp_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vuzp.32 D0, D1'
-
- * uint16x4x2_t vuzp_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vuzp.16 D0, D1'
-
- * uint8x8x2_t vuzp_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vuzp.8 D0, D1'
-
- * int32x2x2_t vuzp_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vuzp.32 D0, D1'
-
- * int16x4x2_t vuzp_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vuzp.16 D0, D1'
-
- * int8x8x2_t vuzp_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vuzp.8 D0, D1'
-
- * float32x2x2_t vuzp_f32 (float32x2_t, float32x2_t)
- _Form of expected instruction(s):_ `vuzp.32 D0, D1'
-
- * poly16x4x2_t vuzp_p16 (poly16x4_t, poly16x4_t)
- _Form of expected instruction(s):_ `vuzp.16 D0, D1'
-
- * poly8x8x2_t vuzp_p8 (poly8x8_t, poly8x8_t)
- _Form of expected instruction(s):_ `vuzp.8 D0, D1'
-
- * uint32x4x2_t vuzpq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vuzp.32 Q0, Q1'
-
- * uint16x8x2_t vuzpq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vuzp.16 Q0, Q1'
-
- * uint8x16x2_t vuzpq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vuzp.8 Q0, Q1'
-
- * int32x4x2_t vuzpq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vuzp.32 Q0, Q1'
-
- * int16x8x2_t vuzpq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vuzp.16 Q0, Q1'
-
- * int8x16x2_t vuzpq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vuzp.8 Q0, Q1'
-
- * float32x4x2_t vuzpq_f32 (float32x4_t, float32x4_t)
- _Form of expected instruction(s):_ `vuzp.32 Q0, Q1'
-
- * poly16x8x2_t vuzpq_p16 (poly16x8_t, poly16x8_t)
- _Form of expected instruction(s):_ `vuzp.16 Q0, Q1'
-
- * poly8x16x2_t vuzpq_p8 (poly8x16_t, poly8x16_t)
- _Form of expected instruction(s):_ `vuzp.8 Q0, Q1'
-
-6.54.3.68 Element/structure loads, VLD1 variants
-................................................
-
- * uint32x2_t vld1_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0}, [R0]'
-
- * uint16x4_t vld1_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0}, [R0]'
-
- * uint8x8_t vld1_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0}, [R0]'
-
- * int32x2_t vld1_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0}, [R0]'
-
- * int16x4_t vld1_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0}, [R0]'
-
- * int8x8_t vld1_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0}, [R0]'
-
- * uint64x1_t vld1_u64 (const uint64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0}, [R0]'
-
- * int64x1_t vld1_s64 (const int64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0}, [R0]'
-
- * float32x2_t vld1_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0}, [R0]'
-
- * poly16x4_t vld1_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0}, [R0]'
-
- * poly8x8_t vld1_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0}, [R0]'
-
- * uint32x4_t vld1q_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0, D1}, [R0]'
-
- * uint16x8_t vld1q_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0, D1}, [R0]'
-
- * uint8x16_t vld1q_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0, D1}, [R0]'
-
- * int32x4_t vld1q_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0, D1}, [R0]'
-
- * int16x8_t vld1q_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0, D1}, [R0]'
-
- * int8x16_t vld1q_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0, D1}, [R0]'
-
- * uint64x2_t vld1q_u64 (const uint64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1}, [R0]'
-
- * int64x2_t vld1q_s64 (const int64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1}, [R0]'
-
- * float32x4_t vld1q_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0, D1}, [R0]'
-
- * poly16x8_t vld1q_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0, D1}, [R0]'
-
- * poly8x16_t vld1q_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0, D1}, [R0]'
-
- * uint32x2_t vld1_lane_u32 (const uint32_t *, uint32x2_t, const int)
- _Form of expected instruction(s):_ `vld1.32 {D0[0]}, [R0]'
-
- * uint16x4_t vld1_lane_u16 (const uint16_t *, uint16x4_t, const int)
- _Form of expected instruction(s):_ `vld1.16 {D0[0]}, [R0]'
-
- * uint8x8_t vld1_lane_u8 (const uint8_t *, uint8x8_t, const int)
- _Form of expected instruction(s):_ `vld1.8 {D0[0]}, [R0]'
-
- * int32x2_t vld1_lane_s32 (const int32_t *, int32x2_t, const int)
- _Form of expected instruction(s):_ `vld1.32 {D0[0]}, [R0]'
-
- * int16x4_t vld1_lane_s16 (const int16_t *, int16x4_t, const int)
- _Form of expected instruction(s):_ `vld1.16 {D0[0]}, [R0]'
-
- * int8x8_t vld1_lane_s8 (const int8_t *, int8x8_t, const int)
- _Form of expected instruction(s):_ `vld1.8 {D0[0]}, [R0]'
-
- * float32x2_t vld1_lane_f32 (const float32_t *, float32x2_t, const
- int)
- _Form of expected instruction(s):_ `vld1.32 {D0[0]}, [R0]'
-
- * poly16x4_t vld1_lane_p16 (const poly16_t *, poly16x4_t, const int)
- _Form of expected instruction(s):_ `vld1.16 {D0[0]}, [R0]'
-
- * poly8x8_t vld1_lane_p8 (const poly8_t *, poly8x8_t, const int)
- _Form of expected instruction(s):_ `vld1.8 {D0[0]}, [R0]'
-
- * uint64x1_t vld1_lane_u64 (const uint64_t *, uint64x1_t, const int)
- _Form of expected instruction(s):_ `vld1.64 {D0}, [R0]'
-
- * int64x1_t vld1_lane_s64 (const int64_t *, int64x1_t, const int)
- _Form of expected instruction(s):_ `vld1.64 {D0}, [R0]'
-
- * uint32x4_t vld1q_lane_u32 (const uint32_t *, uint32x4_t, const int)
- _Form of expected instruction(s):_ `vld1.32 {D0[0]}, [R0]'
-
- * uint16x8_t vld1q_lane_u16 (const uint16_t *, uint16x8_t, const int)
- _Form of expected instruction(s):_ `vld1.16 {D0[0]}, [R0]'
-
- * uint8x16_t vld1q_lane_u8 (const uint8_t *, uint8x16_t, const int)
- _Form of expected instruction(s):_ `vld1.8 {D0[0]}, [R0]'
-
- * int32x4_t vld1q_lane_s32 (const int32_t *, int32x4_t, const int)
- _Form of expected instruction(s):_ `vld1.32 {D0[0]}, [R0]'
-
- * int16x8_t vld1q_lane_s16 (const int16_t *, int16x8_t, const int)
- _Form of expected instruction(s):_ `vld1.16 {D0[0]}, [R0]'
-
- * int8x16_t vld1q_lane_s8 (const int8_t *, int8x16_t, const int)
- _Form of expected instruction(s):_ `vld1.8 {D0[0]}, [R0]'
-
- * float32x4_t vld1q_lane_f32 (const float32_t *, float32x4_t, const
- int)
- _Form of expected instruction(s):_ `vld1.32 {D0[0]}, [R0]'
-
- * poly16x8_t vld1q_lane_p16 (const poly16_t *, poly16x8_t, const int)
- _Form of expected instruction(s):_ `vld1.16 {D0[0]}, [R0]'
-
- * poly8x16_t vld1q_lane_p8 (const poly8_t *, poly8x16_t, const int)
- _Form of expected instruction(s):_ `vld1.8 {D0[0]}, [R0]'
-
- * uint64x2_t vld1q_lane_u64 (const uint64_t *, uint64x2_t, const int)
- _Form of expected instruction(s):_ `vld1.64 {D0}, [R0]'
-
- * int64x2_t vld1q_lane_s64 (const int64_t *, int64x2_t, const int)
- _Form of expected instruction(s):_ `vld1.64 {D0}, [R0]'
-
- * uint32x2_t vld1_dup_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0[]}, [R0]'
-
- * uint16x4_t vld1_dup_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0[]}, [R0]'
-
- * uint8x8_t vld1_dup_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0[]}, [R0]'
-
- * int32x2_t vld1_dup_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0[]}, [R0]'
-
- * int16x4_t vld1_dup_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0[]}, [R0]'
-
- * int8x8_t vld1_dup_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0[]}, [R0]'
-
- * float32x2_t vld1_dup_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0[]}, [R0]'
-
- * poly16x4_t vld1_dup_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0[]}, [R0]'
-
- * poly8x8_t vld1_dup_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0[]}, [R0]'
-
- * uint64x1_t vld1_dup_u64 (const uint64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0}, [R0]'
-
- * int64x1_t vld1_dup_s64 (const int64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0}, [R0]'
-
- * uint32x4_t vld1q_dup_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0[], D1[]}, [R0]'
-
- * uint16x8_t vld1q_dup_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0[], D1[]}, [R0]'
-
- * uint8x16_t vld1q_dup_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0[], D1[]}, [R0]'
-
- * int32x4_t vld1q_dup_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0[], D1[]}, [R0]'
-
- * int16x8_t vld1q_dup_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0[], D1[]}, [R0]'
-
- * int8x16_t vld1q_dup_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0[], D1[]}, [R0]'
-
- * float32x4_t vld1q_dup_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld1.32 {D0[], D1[]}, [R0]'
-
- * poly16x8_t vld1q_dup_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld1.16 {D0[], D1[]}, [R0]'
-
- * poly8x16_t vld1q_dup_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld1.8 {D0[], D1[]}, [R0]'
-
- * uint64x2_t vld1q_dup_u64 (const uint64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1}, [R0]'
-
- * int64x2_t vld1q_dup_s64 (const int64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1}, [R0]'
-
-6.54.3.69 Element/structure stores, VST1 variants
-.................................................
-
- * void vst1_u32 (uint32_t *, uint32x2_t)
- _Form of expected instruction(s):_ `vst1.32 {D0}, [R0]'
-
- * void vst1_u16 (uint16_t *, uint16x4_t)
- _Form of expected instruction(s):_ `vst1.16 {D0}, [R0]'
-
- * void vst1_u8 (uint8_t *, uint8x8_t)
- _Form of expected instruction(s):_ `vst1.8 {D0}, [R0]'
-
- * void vst1_s32 (int32_t *, int32x2_t)
- _Form of expected instruction(s):_ `vst1.32 {D0}, [R0]'
-
- * void vst1_s16 (int16_t *, int16x4_t)
- _Form of expected instruction(s):_ `vst1.16 {D0}, [R0]'
-
- * void vst1_s8 (int8_t *, int8x8_t)
- _Form of expected instruction(s):_ `vst1.8 {D0}, [R0]'
-
- * void vst1_u64 (uint64_t *, uint64x1_t)
- _Form of expected instruction(s):_ `vst1.64 {D0}, [R0]'
-
- * void vst1_s64 (int64_t *, int64x1_t)
- _Form of expected instruction(s):_ `vst1.64 {D0}, [R0]'
-
- * void vst1_f32 (float32_t *, float32x2_t)
- _Form of expected instruction(s):_ `vst1.32 {D0}, [R0]'
-
- * void vst1_p16 (poly16_t *, poly16x4_t)
- _Form of expected instruction(s):_ `vst1.16 {D0}, [R0]'
-
- * void vst1_p8 (poly8_t *, poly8x8_t)
- _Form of expected instruction(s):_ `vst1.8 {D0}, [R0]'
-
- * void vst1q_u32 (uint32_t *, uint32x4_t)
- _Form of expected instruction(s):_ `vst1.32 {D0, D1}, [R0]'
-
- * void vst1q_u16 (uint16_t *, uint16x8_t)
- _Form of expected instruction(s):_ `vst1.16 {D0, D1}, [R0]'
-
- * void vst1q_u8 (uint8_t *, uint8x16_t)
- _Form of expected instruction(s):_ `vst1.8 {D0, D1}, [R0]'
-
- * void vst1q_s32 (int32_t *, int32x4_t)
- _Form of expected instruction(s):_ `vst1.32 {D0, D1}, [R0]'
-
- * void vst1q_s16 (int16_t *, int16x8_t)
- _Form of expected instruction(s):_ `vst1.16 {D0, D1}, [R0]'
-
- * void vst1q_s8 (int8_t *, int8x16_t)
- _Form of expected instruction(s):_ `vst1.8 {D0, D1}, [R0]'
-
- * void vst1q_u64 (uint64_t *, uint64x2_t)
- _Form of expected instruction(s):_ `vst1.64 {D0, D1}, [R0]'
-
- * void vst1q_s64 (int64_t *, int64x2_t)
- _Form of expected instruction(s):_ `vst1.64 {D0, D1}, [R0]'
-
- * void vst1q_f32 (float32_t *, float32x4_t)
- _Form of expected instruction(s):_ `vst1.32 {D0, D1}, [R0]'
-
- * void vst1q_p16 (poly16_t *, poly16x8_t)
- _Form of expected instruction(s):_ `vst1.16 {D0, D1}, [R0]'
-
- * void vst1q_p8 (poly8_t *, poly8x16_t)
- _Form of expected instruction(s):_ `vst1.8 {D0, D1}, [R0]'
-
- * void vst1_lane_u32 (uint32_t *, uint32x2_t, const int)
- _Form of expected instruction(s):_ `vst1.32 {D0[0]}, [R0]'
-
- * void vst1_lane_u16 (uint16_t *, uint16x4_t, const int)
- _Form of expected instruction(s):_ `vst1.16 {D0[0]}, [R0]'
-
- * void vst1_lane_u8 (uint8_t *, uint8x8_t, const int)
- _Form of expected instruction(s):_ `vst1.8 {D0[0]}, [R0]'
-
- * void vst1_lane_s32 (int32_t *, int32x2_t, const int)
- _Form of expected instruction(s):_ `vst1.32 {D0[0]}, [R0]'
-
- * void vst1_lane_s16 (int16_t *, int16x4_t, const int)
- _Form of expected instruction(s):_ `vst1.16 {D0[0]}, [R0]'
-
- * void vst1_lane_s8 (int8_t *, int8x8_t, const int)
- _Form of expected instruction(s):_ `vst1.8 {D0[0]}, [R0]'
-
- * void vst1_lane_f32 (float32_t *, float32x2_t, const int)
- _Form of expected instruction(s):_ `vst1.32 {D0[0]}, [R0]'
-
- * void vst1_lane_p16 (poly16_t *, poly16x4_t, const int)
- _Form of expected instruction(s):_ `vst1.16 {D0[0]}, [R0]'
-
- * void vst1_lane_p8 (poly8_t *, poly8x8_t, const int)
- _Form of expected instruction(s):_ `vst1.8 {D0[0]}, [R0]'
-
- * void vst1_lane_s64 (int64_t *, int64x1_t, const int)
- _Form of expected instruction(s):_ `vst1.64 {D0}, [R0]'
-
- * void vst1_lane_u64 (uint64_t *, uint64x1_t, const int)
- _Form of expected instruction(s):_ `vst1.64 {D0}, [R0]'
-
- * void vst1q_lane_u32 (uint32_t *, uint32x4_t, const int)
- _Form of expected instruction(s):_ `vst1.32 {D0[0]}, [R0]'
-
- * void vst1q_lane_u16 (uint16_t *, uint16x8_t, const int)
- _Form of expected instruction(s):_ `vst1.16 {D0[0]}, [R0]'
-
- * void vst1q_lane_u8 (uint8_t *, uint8x16_t, const int)
- _Form of expected instruction(s):_ `vst1.8 {D0[0]}, [R0]'
-
- * void vst1q_lane_s32 (int32_t *, int32x4_t, const int)
- _Form of expected instruction(s):_ `vst1.32 {D0[0]}, [R0]'
-
- * void vst1q_lane_s16 (int16_t *, int16x8_t, const int)
- _Form of expected instruction(s):_ `vst1.16 {D0[0]}, [R0]'
-
- * void vst1q_lane_s8 (int8_t *, int8x16_t, const int)
- _Form of expected instruction(s):_ `vst1.8 {D0[0]}, [R0]'
-
- * void vst1q_lane_f32 (float32_t *, float32x4_t, const int)
- _Form of expected instruction(s):_ `vst1.32 {D0[0]}, [R0]'
-
- * void vst1q_lane_p16 (poly16_t *, poly16x8_t, const int)
- _Form of expected instruction(s):_ `vst1.16 {D0[0]}, [R0]'
-
- * void vst1q_lane_p8 (poly8_t *, poly8x16_t, const int)
- _Form of expected instruction(s):_ `vst1.8 {D0[0]}, [R0]'
-
- * void vst1q_lane_s64 (int64_t *, int64x2_t, const int)
- _Form of expected instruction(s):_ `vst1.64 {D0}, [R0]'
-
- * void vst1q_lane_u64 (uint64_t *, uint64x2_t, const int)
- _Form of expected instruction(s):_ `vst1.64 {D0}, [R0]'
-
-6.54.3.70 Element/structure loads, VLD2 variants
-................................................
-
- * uint32x2x2_t vld2_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld2.32 {D0, D1}, [R0]'
-
- * uint16x4x2_t vld2_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld2.16 {D0, D1}, [R0]'
-
- * uint8x8x2_t vld2_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld2.8 {D0, D1}, [R0]'
-
- * int32x2x2_t vld2_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld2.32 {D0, D1}, [R0]'
-
- * int16x4x2_t vld2_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld2.16 {D0, D1}, [R0]'
-
- * int8x8x2_t vld2_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld2.8 {D0, D1}, [R0]'
-
- * float32x2x2_t vld2_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld2.32 {D0, D1}, [R0]'
-
- * poly16x4x2_t vld2_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld2.16 {D0, D1}, [R0]'
-
- * poly8x8x2_t vld2_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld2.8 {D0, D1}, [R0]'
-
- * uint64x1x2_t vld2_u64 (const uint64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1}, [R0]'
-
- * int64x1x2_t vld2_s64 (const int64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1}, [R0]'
-
- * uint32x4x2_t vld2q_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld2.32 {D0, D1}, [R0]'
-
- * uint16x8x2_t vld2q_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld2.16 {D0, D1}, [R0]'
-
- * uint8x16x2_t vld2q_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld2.8 {D0, D1}, [R0]'
-
- * int32x4x2_t vld2q_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld2.32 {D0, D1}, [R0]'
-
- * int16x8x2_t vld2q_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld2.16 {D0, D1}, [R0]'
-
- * int8x16x2_t vld2q_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld2.8 {D0, D1}, [R0]'
-
- * float32x4x2_t vld2q_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld2.32 {D0, D1}, [R0]'
-
- * poly16x8x2_t vld2q_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld2.16 {D0, D1}, [R0]'
-
- * poly8x16x2_t vld2q_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld2.8 {D0, D1}, [R0]'
-
- * uint32x2x2_t vld2_lane_u32 (const uint32_t *, uint32x2x2_t, const
- int)
- _Form of expected instruction(s):_ `vld2.32 {D0[0], D1[0]}, [R0]'
-
- * uint16x4x2_t vld2_lane_u16 (const uint16_t *, uint16x4x2_t, const
- int)
- _Form of expected instruction(s):_ `vld2.16 {D0[0], D1[0]}, [R0]'
-
- * uint8x8x2_t vld2_lane_u8 (const uint8_t *, uint8x8x2_t, const int)
- _Form of expected instruction(s):_ `vld2.8 {D0[0], D1[0]}, [R0]'
-
- * int32x2x2_t vld2_lane_s32 (const int32_t *, int32x2x2_t, const int)
- _Form of expected instruction(s):_ `vld2.32 {D0[0], D1[0]}, [R0]'
-
- * int16x4x2_t vld2_lane_s16 (const int16_t *, int16x4x2_t, const int)
- _Form of expected instruction(s):_ `vld2.16 {D0[0], D1[0]}, [R0]'
-
- * int8x8x2_t vld2_lane_s8 (const int8_t *, int8x8x2_t, const int)
- _Form of expected instruction(s):_ `vld2.8 {D0[0], D1[0]}, [R0]'
-
- * float32x2x2_t vld2_lane_f32 (const float32_t *, float32x2x2_t,
- const int)
- _Form of expected instruction(s):_ `vld2.32 {D0[0], D1[0]}, [R0]'
-
- * poly16x4x2_t vld2_lane_p16 (const poly16_t *, poly16x4x2_t, const
- int)
- _Form of expected instruction(s):_ `vld2.16 {D0[0], D1[0]}, [R0]'
-
- * poly8x8x2_t vld2_lane_p8 (const poly8_t *, poly8x8x2_t, const int)
- _Form of expected instruction(s):_ `vld2.8 {D0[0], D1[0]}, [R0]'
-
- * int32x4x2_t vld2q_lane_s32 (const int32_t *, int32x4x2_t, const
- int)
- _Form of expected instruction(s):_ `vld2.32 {D0[0], D1[0]}, [R0]'
-
- * int16x8x2_t vld2q_lane_s16 (const int16_t *, int16x8x2_t, const
- int)
- _Form of expected instruction(s):_ `vld2.16 {D0[0], D1[0]}, [R0]'
-
- * uint32x4x2_t vld2q_lane_u32 (const uint32_t *, uint32x4x2_t, const
- int)
- _Form of expected instruction(s):_ `vld2.32 {D0[0], D1[0]}, [R0]'
-
- * uint16x8x2_t vld2q_lane_u16 (const uint16_t *, uint16x8x2_t, const
- int)
- _Form of expected instruction(s):_ `vld2.16 {D0[0], D1[0]}, [R0]'
-
- * float32x4x2_t vld2q_lane_f32 (const float32_t *, float32x4x2_t,
- const int)
- _Form of expected instruction(s):_ `vld2.32 {D0[0], D1[0]}, [R0]'
-
- * poly16x8x2_t vld2q_lane_p16 (const poly16_t *, poly16x8x2_t, const
- int)
- _Form of expected instruction(s):_ `vld2.16 {D0[0], D1[0]}, [R0]'
-
- * uint32x2x2_t vld2_dup_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld2.32 {D0[], D1[]}, [R0]'
-
- * uint16x4x2_t vld2_dup_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld2.16 {D0[], D1[]}, [R0]'
-
- * uint8x8x2_t vld2_dup_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld2.8 {D0[], D1[]}, [R0]'
-
- * int32x2x2_t vld2_dup_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld2.32 {D0[], D1[]}, [R0]'
-
- * int16x4x2_t vld2_dup_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld2.16 {D0[], D1[]}, [R0]'
-
- * int8x8x2_t vld2_dup_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld2.8 {D0[], D1[]}, [R0]'
-
- * float32x2x2_t vld2_dup_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld2.32 {D0[], D1[]}, [R0]'
-
- * poly16x4x2_t vld2_dup_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld2.16 {D0[], D1[]}, [R0]'
-
- * poly8x8x2_t vld2_dup_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld2.8 {D0[], D1[]}, [R0]'
-
- * uint64x1x2_t vld2_dup_u64 (const uint64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1}, [R0]'
-
- * int64x1x2_t vld2_dup_s64 (const int64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1}, [R0]'
-
-6.54.3.71 Element/structure stores, VST2 variants
-.................................................
-
- * void vst2_u32 (uint32_t *, uint32x2x2_t)
- _Form of expected instruction(s):_ `vst2.32 {D0, D1}, [R0]'
-
- * void vst2_u16 (uint16_t *, uint16x4x2_t)
- _Form of expected instruction(s):_ `vst2.16 {D0, D1}, [R0]'
-
- * void vst2_u8 (uint8_t *, uint8x8x2_t)
- _Form of expected instruction(s):_ `vst2.8 {D0, D1}, [R0]'
-
- * void vst2_s32 (int32_t *, int32x2x2_t)
- _Form of expected instruction(s):_ `vst2.32 {D0, D1}, [R0]'
-
- * void vst2_s16 (int16_t *, int16x4x2_t)
- _Form of expected instruction(s):_ `vst2.16 {D0, D1}, [R0]'
-
- * void vst2_s8 (int8_t *, int8x8x2_t)
- _Form of expected instruction(s):_ `vst2.8 {D0, D1}, [R0]'
-
- * void vst2_f32 (float32_t *, float32x2x2_t)
- _Form of expected instruction(s):_ `vst2.32 {D0, D1}, [R0]'
-
- * void vst2_p16 (poly16_t *, poly16x4x2_t)
- _Form of expected instruction(s):_ `vst2.16 {D0, D1}, [R0]'
-
- * void vst2_p8 (poly8_t *, poly8x8x2_t)
- _Form of expected instruction(s):_ `vst2.8 {D0, D1}, [R0]'
-
- * void vst2_u64 (uint64_t *, uint64x1x2_t)
- _Form of expected instruction(s):_ `vst1.64 {D0, D1}, [R0]'
-
- * void vst2_s64 (int64_t *, int64x1x2_t)
- _Form of expected instruction(s):_ `vst1.64 {D0, D1}, [R0]'
-
- * void vst2q_u32 (uint32_t *, uint32x4x2_t)
- _Form of expected instruction(s):_ `vst2.32 {D0, D1}, [R0]'
-
- * void vst2q_u16 (uint16_t *, uint16x8x2_t)
- _Form of expected instruction(s):_ `vst2.16 {D0, D1}, [R0]'
-
- * void vst2q_u8 (uint8_t *, uint8x16x2_t)
- _Form of expected instruction(s):_ `vst2.8 {D0, D1}, [R0]'
-
- * void vst2q_s32 (int32_t *, int32x4x2_t)
- _Form of expected instruction(s):_ `vst2.32 {D0, D1}, [R0]'
-
- * void vst2q_s16 (int16_t *, int16x8x2_t)
- _Form of expected instruction(s):_ `vst2.16 {D0, D1}, [R0]'
-
- * void vst2q_s8 (int8_t *, int8x16x2_t)
- _Form of expected instruction(s):_ `vst2.8 {D0, D1}, [R0]'
-
- * void vst2q_f32 (float32_t *, float32x4x2_t)
- _Form of expected instruction(s):_ `vst2.32 {D0, D1}, [R0]'
-
- * void vst2q_p16 (poly16_t *, poly16x8x2_t)
- _Form of expected instruction(s):_ `vst2.16 {D0, D1}, [R0]'
-
- * void vst2q_p8 (poly8_t *, poly8x16x2_t)
- _Form of expected instruction(s):_ `vst2.8 {D0, D1}, [R0]'
-
- * void vst2_lane_u32 (uint32_t *, uint32x2x2_t, const int)
- _Form of expected instruction(s):_ `vst2.32 {D0[0], D1[0]}, [R0]'
-
- * void vst2_lane_u16 (uint16_t *, uint16x4x2_t, const int)
- _Form of expected instruction(s):_ `vst2.16 {D0[0], D1[0]}, [R0]'
-
- * void vst2_lane_u8 (uint8_t *, uint8x8x2_t, const int)
- _Form of expected instruction(s):_ `vst2.8 {D0[0], D1[0]}, [R0]'
-
- * void vst2_lane_s32 (int32_t *, int32x2x2_t, const int)
- _Form of expected instruction(s):_ `vst2.32 {D0[0], D1[0]}, [R0]'
-
- * void vst2_lane_s16 (int16_t *, int16x4x2_t, const int)
- _Form of expected instruction(s):_ `vst2.16 {D0[0], D1[0]}, [R0]'
-
- * void vst2_lane_s8 (int8_t *, int8x8x2_t, const int)
- _Form of expected instruction(s):_ `vst2.8 {D0[0], D1[0]}, [R0]'
-
- * void vst2_lane_f32 (float32_t *, float32x2x2_t, const int)
- _Form of expected instruction(s):_ `vst2.32 {D0[0], D1[0]}, [R0]'
-
- * void vst2_lane_p16 (poly16_t *, poly16x4x2_t, const int)
- _Form of expected instruction(s):_ `vst2.16 {D0[0], D1[0]}, [R0]'
-
- * void vst2_lane_p8 (poly8_t *, poly8x8x2_t, const int)
- _Form of expected instruction(s):_ `vst2.8 {D0[0], D1[0]}, [R0]'
-
- * void vst2q_lane_s32 (int32_t *, int32x4x2_t, const int)
- _Form of expected instruction(s):_ `vst2.32 {D0[0], D1[0]}, [R0]'
-
- * void vst2q_lane_s16 (int16_t *, int16x8x2_t, const int)
- _Form of expected instruction(s):_ `vst2.16 {D0[0], D1[0]}, [R0]'
-
- * void vst2q_lane_u32 (uint32_t *, uint32x4x2_t, const int)
- _Form of expected instruction(s):_ `vst2.32 {D0[0], D1[0]}, [R0]'
-
- * void vst2q_lane_u16 (uint16_t *, uint16x8x2_t, const int)
- _Form of expected instruction(s):_ `vst2.16 {D0[0], D1[0]}, [R0]'
-
- * void vst2q_lane_f32 (float32_t *, float32x4x2_t, const int)
- _Form of expected instruction(s):_ `vst2.32 {D0[0], D1[0]}, [R0]'
-
- * void vst2q_lane_p16 (poly16_t *, poly16x8x2_t, const int)
- _Form of expected instruction(s):_ `vst2.16 {D0[0], D1[0]}, [R0]'
-
-6.54.3.72 Element/structure loads, VLD3 variants
-................................................
-
- * uint32x2x3_t vld3_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld3.32 {D0, D1, D2}, [R0]'
-
- * uint16x4x3_t vld3_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld3.16 {D0, D1, D2}, [R0]'
-
- * uint8x8x3_t vld3_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld3.8 {D0, D1, D2}, [R0]'
-
- * int32x2x3_t vld3_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld3.32 {D0, D1, D2}, [R0]'
-
- * int16x4x3_t vld3_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld3.16 {D0, D1, D2}, [R0]'
-
- * int8x8x3_t vld3_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld3.8 {D0, D1, D2}, [R0]'
-
- * float32x2x3_t vld3_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld3.32 {D0, D1, D2}, [R0]'
-
- * poly16x4x3_t vld3_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld3.16 {D0, D1, D2}, [R0]'
-
- * poly8x8x3_t vld3_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld3.8 {D0, D1, D2}, [R0]'
-
- * uint64x1x3_t vld3_u64 (const uint64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1, D2}, [R0]'
-
- * int64x1x3_t vld3_s64 (const int64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1, D2}, [R0]'
-
- * uint32x4x3_t vld3q_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld3.32 {D0, D1, D2}, [R0]'
-
- * uint16x8x3_t vld3q_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld3.16 {D0, D1, D2}, [R0]'
-
- * uint8x16x3_t vld3q_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld3.8 {D0, D1, D2}, [R0]'
-
- * int32x4x3_t vld3q_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld3.32 {D0, D1, D2}, [R0]'
-
- * int16x8x3_t vld3q_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld3.16 {D0, D1, D2}, [R0]'
-
- * int8x16x3_t vld3q_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld3.8 {D0, D1, D2}, [R0]'
-
- * float32x4x3_t vld3q_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld3.32 {D0, D1, D2}, [R0]'
-
- * poly16x8x3_t vld3q_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld3.16 {D0, D1, D2}, [R0]'
-
- * poly8x16x3_t vld3q_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld3.8 {D0, D1, D2}, [R0]'
-
- * uint32x2x3_t vld3_lane_u32 (const uint32_t *, uint32x2x3_t, const
- int)
- _Form of expected instruction(s):_ `vld3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * uint16x4x3_t vld3_lane_u16 (const uint16_t *, uint16x4x3_t, const
- int)
- _Form of expected instruction(s):_ `vld3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * uint8x8x3_t vld3_lane_u8 (const uint8_t *, uint8x8x3_t, const int)
- _Form of expected instruction(s):_ `vld3.8 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * int32x2x3_t vld3_lane_s32 (const int32_t *, int32x2x3_t, const int)
- _Form of expected instruction(s):_ `vld3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * int16x4x3_t vld3_lane_s16 (const int16_t *, int16x4x3_t, const int)
- _Form of expected instruction(s):_ `vld3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * int8x8x3_t vld3_lane_s8 (const int8_t *, int8x8x3_t, const int)
- _Form of expected instruction(s):_ `vld3.8 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * float32x2x3_t vld3_lane_f32 (const float32_t *, float32x2x3_t,
- const int)
- _Form of expected instruction(s):_ `vld3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * poly16x4x3_t vld3_lane_p16 (const poly16_t *, poly16x4x3_t, const
- int)
- _Form of expected instruction(s):_ `vld3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * poly8x8x3_t vld3_lane_p8 (const poly8_t *, poly8x8x3_t, const int)
- _Form of expected instruction(s):_ `vld3.8 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * int32x4x3_t vld3q_lane_s32 (const int32_t *, int32x4x3_t, const
- int)
- _Form of expected instruction(s):_ `vld3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * int16x8x3_t vld3q_lane_s16 (const int16_t *, int16x8x3_t, const
- int)
- _Form of expected instruction(s):_ `vld3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * uint32x4x3_t vld3q_lane_u32 (const uint32_t *, uint32x4x3_t, const
- int)
- _Form of expected instruction(s):_ `vld3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * uint16x8x3_t vld3q_lane_u16 (const uint16_t *, uint16x8x3_t, const
- int)
- _Form of expected instruction(s):_ `vld3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * float32x4x3_t vld3q_lane_f32 (const float32_t *, float32x4x3_t,
- const int)
- _Form of expected instruction(s):_ `vld3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * poly16x8x3_t vld3q_lane_p16 (const poly16_t *, poly16x8x3_t, const
- int)
- _Form of expected instruction(s):_ `vld3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * uint32x2x3_t vld3_dup_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld3.32 {D0[], D1[], D2[]},
- [R0]'
-
- * uint16x4x3_t vld3_dup_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld3.16 {D0[], D1[], D2[]},
- [R0]'
-
- * uint8x8x3_t vld3_dup_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld3.8 {D0[], D1[], D2[]},
- [R0]'
-
- * int32x2x3_t vld3_dup_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld3.32 {D0[], D1[], D2[]},
- [R0]'
-
- * int16x4x3_t vld3_dup_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld3.16 {D0[], D1[], D2[]},
- [R0]'
-
- * int8x8x3_t vld3_dup_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld3.8 {D0[], D1[], D2[]},
- [R0]'
-
- * float32x2x3_t vld3_dup_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld3.32 {D0[], D1[], D2[]},
- [R0]'
-
- * poly16x4x3_t vld3_dup_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld3.16 {D0[], D1[], D2[]},
- [R0]'
-
- * poly8x8x3_t vld3_dup_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld3.8 {D0[], D1[], D2[]},
- [R0]'
-
- * uint64x1x3_t vld3_dup_u64 (const uint64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1, D2}, [R0]'
-
- * int64x1x3_t vld3_dup_s64 (const int64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1, D2}, [R0]'
-
-6.54.3.73 Element/structure stores, VST3 variants
-.................................................
-
- * void vst3_u32 (uint32_t *, uint32x2x3_t)
- _Form of expected instruction(s):_ `vst3.32 {D0, D1, D2, D3}, [R0]'
-
- * void vst3_u16 (uint16_t *, uint16x4x3_t)
- _Form of expected instruction(s):_ `vst3.16 {D0, D1, D2, D3}, [R0]'
-
- * void vst3_u8 (uint8_t *, uint8x8x3_t)
- _Form of expected instruction(s):_ `vst3.8 {D0, D1, D2, D3}, [R0]'
-
- * void vst3_s32 (int32_t *, int32x2x3_t)
- _Form of expected instruction(s):_ `vst3.32 {D0, D1, D2, D3}, [R0]'
-
- * void vst3_s16 (int16_t *, int16x4x3_t)
- _Form of expected instruction(s):_ `vst3.16 {D0, D1, D2, D3}, [R0]'
-
- * void vst3_s8 (int8_t *, int8x8x3_t)
- _Form of expected instruction(s):_ `vst3.8 {D0, D1, D2, D3}, [R0]'
-
- * void vst3_f32 (float32_t *, float32x2x3_t)
- _Form of expected instruction(s):_ `vst3.32 {D0, D1, D2, D3}, [R0]'
-
- * void vst3_p16 (poly16_t *, poly16x4x3_t)
- _Form of expected instruction(s):_ `vst3.16 {D0, D1, D2, D3}, [R0]'
-
- * void vst3_p8 (poly8_t *, poly8x8x3_t)
- _Form of expected instruction(s):_ `vst3.8 {D0, D1, D2, D3}, [R0]'
-
- * void vst3_u64 (uint64_t *, uint64x1x3_t)
- _Form of expected instruction(s):_ `vst1.64 {D0, D1, D2, D3}, [R0]'
-
- * void vst3_s64 (int64_t *, int64x1x3_t)
- _Form of expected instruction(s):_ `vst1.64 {D0, D1, D2, D3}, [R0]'
-
- * void vst3q_u32 (uint32_t *, uint32x4x3_t)
- _Form of expected instruction(s):_ `vst3.32 {D0, D1, D2}, [R0]'
-
- * void vst3q_u16 (uint16_t *, uint16x8x3_t)
- _Form of expected instruction(s):_ `vst3.16 {D0, D1, D2}, [R0]'
-
- * void vst3q_u8 (uint8_t *, uint8x16x3_t)
- _Form of expected instruction(s):_ `vst3.8 {D0, D1, D2}, [R0]'
-
- * void vst3q_s32 (int32_t *, int32x4x3_t)
- _Form of expected instruction(s):_ `vst3.32 {D0, D1, D2}, [R0]'
-
- * void vst3q_s16 (int16_t *, int16x8x3_t)
- _Form of expected instruction(s):_ `vst3.16 {D0, D1, D2}, [R0]'
-
- * void vst3q_s8 (int8_t *, int8x16x3_t)
- _Form of expected instruction(s):_ `vst3.8 {D0, D1, D2}, [R0]'
-
- * void vst3q_f32 (float32_t *, float32x4x3_t)
- _Form of expected instruction(s):_ `vst3.32 {D0, D1, D2}, [R0]'
-
- * void vst3q_p16 (poly16_t *, poly16x8x3_t)
- _Form of expected instruction(s):_ `vst3.16 {D0, D1, D2}, [R0]'
-
- * void vst3q_p8 (poly8_t *, poly8x16x3_t)
- _Form of expected instruction(s):_ `vst3.8 {D0, D1, D2}, [R0]'
-
- * void vst3_lane_u32 (uint32_t *, uint32x2x3_t, const int)
- _Form of expected instruction(s):_ `vst3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3_lane_u16 (uint16_t *, uint16x4x3_t, const int)
- _Form of expected instruction(s):_ `vst3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3_lane_u8 (uint8_t *, uint8x8x3_t, const int)
- _Form of expected instruction(s):_ `vst3.8 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3_lane_s32 (int32_t *, int32x2x3_t, const int)
- _Form of expected instruction(s):_ `vst3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3_lane_s16 (int16_t *, int16x4x3_t, const int)
- _Form of expected instruction(s):_ `vst3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3_lane_s8 (int8_t *, int8x8x3_t, const int)
- _Form of expected instruction(s):_ `vst3.8 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3_lane_f32 (float32_t *, float32x2x3_t, const int)
- _Form of expected instruction(s):_ `vst3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3_lane_p16 (poly16_t *, poly16x4x3_t, const int)
- _Form of expected instruction(s):_ `vst3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3_lane_p8 (poly8_t *, poly8x8x3_t, const int)
- _Form of expected instruction(s):_ `vst3.8 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3q_lane_s32 (int32_t *, int32x4x3_t, const int)
- _Form of expected instruction(s):_ `vst3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3q_lane_s16 (int16_t *, int16x8x3_t, const int)
- _Form of expected instruction(s):_ `vst3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3q_lane_u32 (uint32_t *, uint32x4x3_t, const int)
- _Form of expected instruction(s):_ `vst3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3q_lane_u16 (uint16_t *, uint16x8x3_t, const int)
- _Form of expected instruction(s):_ `vst3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3q_lane_f32 (float32_t *, float32x4x3_t, const int)
- _Form of expected instruction(s):_ `vst3.32 {D0[0], D1[0], D2[0]},
- [R0]'
-
- * void vst3q_lane_p16 (poly16_t *, poly16x8x3_t, const int)
- _Form of expected instruction(s):_ `vst3.16 {D0[0], D1[0], D2[0]},
- [R0]'
-
-6.54.3.74 Element/structure loads, VLD4 variants
-................................................
-
- * uint32x2x4_t vld4_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld4.32 {D0, D1, D2, D3}, [R0]'
-
- * uint16x4x4_t vld4_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld4.16 {D0, D1, D2, D3}, [R0]'
-
- * uint8x8x4_t vld4_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld4.8 {D0, D1, D2, D3}, [R0]'
-
- * int32x2x4_t vld4_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld4.32 {D0, D1, D2, D3}, [R0]'
-
- * int16x4x4_t vld4_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld4.16 {D0, D1, D2, D3}, [R0]'
-
- * int8x8x4_t vld4_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld4.8 {D0, D1, D2, D3}, [R0]'
-
- * float32x2x4_t vld4_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld4.32 {D0, D1, D2, D3}, [R0]'
-
- * poly16x4x4_t vld4_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld4.16 {D0, D1, D2, D3}, [R0]'
-
- * poly8x8x4_t vld4_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld4.8 {D0, D1, D2, D3}, [R0]'
-
- * uint64x1x4_t vld4_u64 (const uint64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1, D2, D3}, [R0]'
-
- * int64x1x4_t vld4_s64 (const int64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1, D2, D3}, [R0]'
-
- * uint32x4x4_t vld4q_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld4.32 {D0, D1, D2, D3}, [R0]'
-
- * uint16x8x4_t vld4q_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld4.16 {D0, D1, D2, D3}, [R0]'
-
- * uint8x16x4_t vld4q_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld4.8 {D0, D1, D2, D3}, [R0]'
-
- * int32x4x4_t vld4q_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld4.32 {D0, D1, D2, D3}, [R0]'
-
- * int16x8x4_t vld4q_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld4.16 {D0, D1, D2, D3}, [R0]'
-
- * int8x16x4_t vld4q_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld4.8 {D0, D1, D2, D3}, [R0]'
-
- * float32x4x4_t vld4q_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld4.32 {D0, D1, D2, D3}, [R0]'
-
- * poly16x8x4_t vld4q_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld4.16 {D0, D1, D2, D3}, [R0]'
-
- * poly8x16x4_t vld4q_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld4.8 {D0, D1, D2, D3}, [R0]'
-
- * uint32x2x4_t vld4_lane_u32 (const uint32_t *, uint32x2x4_t, const
- int)
- _Form of expected instruction(s):_ `vld4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * uint16x4x4_t vld4_lane_u16 (const uint16_t *, uint16x4x4_t, const
- int)
- _Form of expected instruction(s):_ `vld4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * uint8x8x4_t vld4_lane_u8 (const uint8_t *, uint8x8x4_t, const int)
- _Form of expected instruction(s):_ `vld4.8 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * int32x2x4_t vld4_lane_s32 (const int32_t *, int32x2x4_t, const int)
- _Form of expected instruction(s):_ `vld4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * int16x4x4_t vld4_lane_s16 (const int16_t *, int16x4x4_t, const int)
- _Form of expected instruction(s):_ `vld4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * int8x8x4_t vld4_lane_s8 (const int8_t *, int8x8x4_t, const int)
- _Form of expected instruction(s):_ `vld4.8 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * float32x2x4_t vld4_lane_f32 (const float32_t *, float32x2x4_t,
- const int)
- _Form of expected instruction(s):_ `vld4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * poly16x4x4_t vld4_lane_p16 (const poly16_t *, poly16x4x4_t, const
- int)
- _Form of expected instruction(s):_ `vld4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * poly8x8x4_t vld4_lane_p8 (const poly8_t *, poly8x8x4_t, const int)
- _Form of expected instruction(s):_ `vld4.8 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * int32x4x4_t vld4q_lane_s32 (const int32_t *, int32x4x4_t, const
- int)
- _Form of expected instruction(s):_ `vld4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * int16x8x4_t vld4q_lane_s16 (const int16_t *, int16x8x4_t, const
- int)
- _Form of expected instruction(s):_ `vld4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * uint32x4x4_t vld4q_lane_u32 (const uint32_t *, uint32x4x4_t, const
- int)
- _Form of expected instruction(s):_ `vld4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * uint16x8x4_t vld4q_lane_u16 (const uint16_t *, uint16x8x4_t, const
- int)
- _Form of expected instruction(s):_ `vld4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * float32x4x4_t vld4q_lane_f32 (const float32_t *, float32x4x4_t,
- const int)
- _Form of expected instruction(s):_ `vld4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * poly16x8x4_t vld4q_lane_p16 (const poly16_t *, poly16x8x4_t, const
- int)
- _Form of expected instruction(s):_ `vld4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * uint32x2x4_t vld4_dup_u32 (const uint32_t *)
- _Form of expected instruction(s):_ `vld4.32 {D0[], D1[], D2[],
- D3[]}, [R0]'
-
- * uint16x4x4_t vld4_dup_u16 (const uint16_t *)
- _Form of expected instruction(s):_ `vld4.16 {D0[], D1[], D2[],
- D3[]}, [R0]'
-
- * uint8x8x4_t vld4_dup_u8 (const uint8_t *)
- _Form of expected instruction(s):_ `vld4.8 {D0[], D1[], D2[],
- D3[]}, [R0]'
-
- * int32x2x4_t vld4_dup_s32 (const int32_t *)
- _Form of expected instruction(s):_ `vld4.32 {D0[], D1[], D2[],
- D3[]}, [R0]'
-
- * int16x4x4_t vld4_dup_s16 (const int16_t *)
- _Form of expected instruction(s):_ `vld4.16 {D0[], D1[], D2[],
- D3[]}, [R0]'
-
- * int8x8x4_t vld4_dup_s8 (const int8_t *)
- _Form of expected instruction(s):_ `vld4.8 {D0[], D1[], D2[],
- D3[]}, [R0]'
-
- * float32x2x4_t vld4_dup_f32 (const float32_t *)
- _Form of expected instruction(s):_ `vld4.32 {D0[], D1[], D2[],
- D3[]}, [R0]'
-
- * poly16x4x4_t vld4_dup_p16 (const poly16_t *)
- _Form of expected instruction(s):_ `vld4.16 {D0[], D1[], D2[],
- D3[]}, [R0]'
-
- * poly8x8x4_t vld4_dup_p8 (const poly8_t *)
- _Form of expected instruction(s):_ `vld4.8 {D0[], D1[], D2[],
- D3[]}, [R0]'
-
- * uint64x1x4_t vld4_dup_u64 (const uint64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1, D2, D3}, [R0]'
-
- * int64x1x4_t vld4_dup_s64 (const int64_t *)
- _Form of expected instruction(s):_ `vld1.64 {D0, D1, D2, D3}, [R0]'
-
-6.54.3.75 Element/structure stores, VST4 variants
-.................................................
-
- * void vst4_u32 (uint32_t *, uint32x2x4_t)
- _Form of expected instruction(s):_ `vst4.32 {D0, D1, D2, D3}, [R0]'
-
- * void vst4_u16 (uint16_t *, uint16x4x4_t)
- _Form of expected instruction(s):_ `vst4.16 {D0, D1, D2, D3}, [R0]'
-
- * void vst4_u8 (uint8_t *, uint8x8x4_t)
- _Form of expected instruction(s):_ `vst4.8 {D0, D1, D2, D3}, [R0]'
-
- * void vst4_s32 (int32_t *, int32x2x4_t)
- _Form of expected instruction(s):_ `vst4.32 {D0, D1, D2, D3}, [R0]'
-
- * void vst4_s16 (int16_t *, int16x4x4_t)
- _Form of expected instruction(s):_ `vst4.16 {D0, D1, D2, D3}, [R0]'
-
- * void vst4_s8 (int8_t *, int8x8x4_t)
- _Form of expected instruction(s):_ `vst4.8 {D0, D1, D2, D3}, [R0]'
-
- * void vst4_f32 (float32_t *, float32x2x4_t)
- _Form of expected instruction(s):_ `vst4.32 {D0, D1, D2, D3}, [R0]'
-
- * void vst4_p16 (poly16_t *, poly16x4x4_t)
- _Form of expected instruction(s):_ `vst4.16 {D0, D1, D2, D3}, [R0]'
-
- * void vst4_p8 (poly8_t *, poly8x8x4_t)
- _Form of expected instruction(s):_ `vst4.8 {D0, D1, D2, D3}, [R0]'
-
- * void vst4_u64 (uint64_t *, uint64x1x4_t)
- _Form of expected instruction(s):_ `vst1.64 {D0, D1, D2, D3}, [R0]'
-
- * void vst4_s64 (int64_t *, int64x1x4_t)
- _Form of expected instruction(s):_ `vst1.64 {D0, D1, D2, D3}, [R0]'
-
- * void vst4q_u32 (uint32_t *, uint32x4x4_t)
- _Form of expected instruction(s):_ `vst4.32 {D0, D1, D2, D3}, [R0]'
-
- * void vst4q_u16 (uint16_t *, uint16x8x4_t)
- _Form of expected instruction(s):_ `vst4.16 {D0, D1, D2, D3}, [R0]'
-
- * void vst4q_u8 (uint8_t *, uint8x16x4_t)
- _Form of expected instruction(s):_ `vst4.8 {D0, D1, D2, D3}, [R0]'
-
- * void vst4q_s32 (int32_t *, int32x4x4_t)
- _Form of expected instruction(s):_ `vst4.32 {D0, D1, D2, D3}, [R0]'
-
- * void vst4q_s16 (int16_t *, int16x8x4_t)
- _Form of expected instruction(s):_ `vst4.16 {D0, D1, D2, D3}, [R0]'
-
- * void vst4q_s8 (int8_t *, int8x16x4_t)
- _Form of expected instruction(s):_ `vst4.8 {D0, D1, D2, D3}, [R0]'
-
- * void vst4q_f32 (float32_t *, float32x4x4_t)
- _Form of expected instruction(s):_ `vst4.32 {D0, D1, D2, D3}, [R0]'
-
- * void vst4q_p16 (poly16_t *, poly16x8x4_t)
- _Form of expected instruction(s):_ `vst4.16 {D0, D1, D2, D3}, [R0]'
-
- * void vst4q_p8 (poly8_t *, poly8x16x4_t)
- _Form of expected instruction(s):_ `vst4.8 {D0, D1, D2, D3}, [R0]'
-
- * void vst4_lane_u32 (uint32_t *, uint32x2x4_t, const int)
- _Form of expected instruction(s):_ `vst4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4_lane_u16 (uint16_t *, uint16x4x4_t, const int)
- _Form of expected instruction(s):_ `vst4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4_lane_u8 (uint8_t *, uint8x8x4_t, const int)
- _Form of expected instruction(s):_ `vst4.8 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4_lane_s32 (int32_t *, int32x2x4_t, const int)
- _Form of expected instruction(s):_ `vst4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4_lane_s16 (int16_t *, int16x4x4_t, const int)
- _Form of expected instruction(s):_ `vst4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4_lane_s8 (int8_t *, int8x8x4_t, const int)
- _Form of expected instruction(s):_ `vst4.8 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4_lane_f32 (float32_t *, float32x2x4_t, const int)
- _Form of expected instruction(s):_ `vst4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4_lane_p16 (poly16_t *, poly16x4x4_t, const int)
- _Form of expected instruction(s):_ `vst4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4_lane_p8 (poly8_t *, poly8x8x4_t, const int)
- _Form of expected instruction(s):_ `vst4.8 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4q_lane_s32 (int32_t *, int32x4x4_t, const int)
- _Form of expected instruction(s):_ `vst4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4q_lane_s16 (int16_t *, int16x8x4_t, const int)
- _Form of expected instruction(s):_ `vst4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4q_lane_u32 (uint32_t *, uint32x4x4_t, const int)
- _Form of expected instruction(s):_ `vst4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4q_lane_u16 (uint16_t *, uint16x8x4_t, const int)
- _Form of expected instruction(s):_ `vst4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4q_lane_f32 (float32_t *, float32x4x4_t, const int)
- _Form of expected instruction(s):_ `vst4.32 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
- * void vst4q_lane_p16 (poly16_t *, poly16x8x4_t, const int)
- _Form of expected instruction(s):_ `vst4.16 {D0[0], D1[0], D2[0],
- D3[0]}, [R0]'
-
-6.54.3.76 Logical operations (AND)
-..................................
-
- * uint32x2_t vand_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vand D0, D0, D0'
-
- * uint16x4_t vand_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vand D0, D0, D0'
-
- * uint8x8_t vand_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vand D0, D0, D0'
-
- * int32x2_t vand_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vand D0, D0, D0'
-
- * int16x4_t vand_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vand D0, D0, D0'
-
- * int8x8_t vand_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vand D0, D0, D0'
-
- * uint64x1_t vand_u64 (uint64x1_t, uint64x1_t)
-
- * int64x1_t vand_s64 (int64x1_t, int64x1_t)
-
- * uint32x4_t vandq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vand Q0, Q0, Q0'
-
- * uint16x8_t vandq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vand Q0, Q0, Q0'
-
- * uint8x16_t vandq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vand Q0, Q0, Q0'
-
- * int32x4_t vandq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vand Q0, Q0, Q0'
-
- * int16x8_t vandq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vand Q0, Q0, Q0'
-
- * int8x16_t vandq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vand Q0, Q0, Q0'
-
- * uint64x2_t vandq_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vand Q0, Q0, Q0'
-
- * int64x2_t vandq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vand Q0, Q0, Q0'
-
-6.54.3.77 Logical operations (OR)
-.................................
-
- * uint32x2_t vorr_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vorr D0, D0, D0'
-
- * uint16x4_t vorr_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vorr D0, D0, D0'
-
- * uint8x8_t vorr_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vorr D0, D0, D0'
-
- * int32x2_t vorr_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vorr D0, D0, D0'
-
- * int16x4_t vorr_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vorr D0, D0, D0'
-
- * int8x8_t vorr_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vorr D0, D0, D0'
-
- * uint64x1_t vorr_u64 (uint64x1_t, uint64x1_t)
-
- * int64x1_t vorr_s64 (int64x1_t, int64x1_t)
-
- * uint32x4_t vorrq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vorr Q0, Q0, Q0'
-
- * uint16x8_t vorrq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vorr Q0, Q0, Q0'
-
- * uint8x16_t vorrq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vorr Q0, Q0, Q0'
-
- * int32x4_t vorrq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vorr Q0, Q0, Q0'
-
- * int16x8_t vorrq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vorr Q0, Q0, Q0'
-
- * int8x16_t vorrq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vorr Q0, Q0, Q0'
-
- * uint64x2_t vorrq_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vorr Q0, Q0, Q0'
-
- * int64x2_t vorrq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vorr Q0, Q0, Q0'
-
-6.54.3.78 Logical operations (exclusive OR)
-...........................................
-
- * uint32x2_t veor_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `veor D0, D0, D0'
-
- * uint16x4_t veor_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `veor D0, D0, D0'
-
- * uint8x8_t veor_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `veor D0, D0, D0'
-
- * int32x2_t veor_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `veor D0, D0, D0'
-
- * int16x4_t veor_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `veor D0, D0, D0'
-
- * int8x8_t veor_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `veor D0, D0, D0'
-
- * uint64x1_t veor_u64 (uint64x1_t, uint64x1_t)
-
- * int64x1_t veor_s64 (int64x1_t, int64x1_t)
-
- * uint32x4_t veorq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `veor Q0, Q0, Q0'
-
- * uint16x8_t veorq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `veor Q0, Q0, Q0'
-
- * uint8x16_t veorq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `veor Q0, Q0, Q0'
-
- * int32x4_t veorq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `veor Q0, Q0, Q0'
-
- * int16x8_t veorq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `veor Q0, Q0, Q0'
-
- * int8x16_t veorq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `veor Q0, Q0, Q0'
-
- * uint64x2_t veorq_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `veor Q0, Q0, Q0'
-
- * int64x2_t veorq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `veor Q0, Q0, Q0'
-
-6.54.3.79 Logical operations (AND-NOT)
-......................................
-
- * uint32x2_t vbic_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vbic D0, D0, D0'
-
- * uint16x4_t vbic_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vbic D0, D0, D0'
-
- * uint8x8_t vbic_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vbic D0, D0, D0'
-
- * int32x2_t vbic_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vbic D0, D0, D0'
-
- * int16x4_t vbic_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vbic D0, D0, D0'
-
- * int8x8_t vbic_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vbic D0, D0, D0'
-
- * uint64x1_t vbic_u64 (uint64x1_t, uint64x1_t)
-
- * int64x1_t vbic_s64 (int64x1_t, int64x1_t)
-
- * uint32x4_t vbicq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vbic Q0, Q0, Q0'
-
- * uint16x8_t vbicq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vbic Q0, Q0, Q0'
-
- * uint8x16_t vbicq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vbic Q0, Q0, Q0'
-
- * int32x4_t vbicq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vbic Q0, Q0, Q0'
-
- * int16x8_t vbicq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vbic Q0, Q0, Q0'
-
- * int8x16_t vbicq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vbic Q0, Q0, Q0'
-
- * uint64x2_t vbicq_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vbic Q0, Q0, Q0'
-
- * int64x2_t vbicq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vbic Q0, Q0, Q0'
-
-6.54.3.80 Logical operations (OR-NOT)
-.....................................
-
- * uint32x2_t vorn_u32 (uint32x2_t, uint32x2_t)
- _Form of expected instruction(s):_ `vorn D0, D0, D0'
-
- * uint16x4_t vorn_u16 (uint16x4_t, uint16x4_t)
- _Form of expected instruction(s):_ `vorn D0, D0, D0'
-
- * uint8x8_t vorn_u8 (uint8x8_t, uint8x8_t)
- _Form of expected instruction(s):_ `vorn D0, D0, D0'
-
- * int32x2_t vorn_s32 (int32x2_t, int32x2_t)
- _Form of expected instruction(s):_ `vorn D0, D0, D0'
-
- * int16x4_t vorn_s16 (int16x4_t, int16x4_t)
- _Form of expected instruction(s):_ `vorn D0, D0, D0'
-
- * int8x8_t vorn_s8 (int8x8_t, int8x8_t)
- _Form of expected instruction(s):_ `vorn D0, D0, D0'
-
- * uint64x1_t vorn_u64 (uint64x1_t, uint64x1_t)
-
- * int64x1_t vorn_s64 (int64x1_t, int64x1_t)
-
- * uint32x4_t vornq_u32 (uint32x4_t, uint32x4_t)
- _Form of expected instruction(s):_ `vorn Q0, Q0, Q0'
-
- * uint16x8_t vornq_u16 (uint16x8_t, uint16x8_t)
- _Form of expected instruction(s):_ `vorn Q0, Q0, Q0'
-
- * uint8x16_t vornq_u8 (uint8x16_t, uint8x16_t)
- _Form of expected instruction(s):_ `vorn Q0, Q0, Q0'
-
- * int32x4_t vornq_s32 (int32x4_t, int32x4_t)
- _Form of expected instruction(s):_ `vorn Q0, Q0, Q0'
-
- * int16x8_t vornq_s16 (int16x8_t, int16x8_t)
- _Form of expected instruction(s):_ `vorn Q0, Q0, Q0'
-
- * int8x16_t vornq_s8 (int8x16_t, int8x16_t)
- _Form of expected instruction(s):_ `vorn Q0, Q0, Q0'
-
- * uint64x2_t vornq_u64 (uint64x2_t, uint64x2_t)
- _Form of expected instruction(s):_ `vorn Q0, Q0, Q0'
-
- * int64x2_t vornq_s64 (int64x2_t, int64x2_t)
- _Form of expected instruction(s):_ `vorn Q0, Q0, Q0'
-
-6.54.3.81 Reinterpret casts
-...........................
-
- * poly8x8_t vreinterpret_p8_u32 (uint32x2_t)
-
- * poly8x8_t vreinterpret_p8_u16 (uint16x4_t)
-
- * poly8x8_t vreinterpret_p8_u8 (uint8x8_t)
-
- * poly8x8_t vreinterpret_p8_s32 (int32x2_t)
-
- * poly8x8_t vreinterpret_p8_s16 (int16x4_t)
-
- * poly8x8_t vreinterpret_p8_s8 (int8x8_t)
-
- * poly8x8_t vreinterpret_p8_u64 (uint64x1_t)
-
- * poly8x8_t vreinterpret_p8_s64 (int64x1_t)
-
- * poly8x8_t vreinterpret_p8_f32 (float32x2_t)
-
- * poly8x8_t vreinterpret_p8_p16 (poly16x4_t)
-
- * poly8x16_t vreinterpretq_p8_u32 (uint32x4_t)
-
- * poly8x16_t vreinterpretq_p8_u16 (uint16x8_t)
-
- * poly8x16_t vreinterpretq_p8_u8 (uint8x16_t)
-
- * poly8x16_t vreinterpretq_p8_s32 (int32x4_t)
-
- * poly8x16_t vreinterpretq_p8_s16 (int16x8_t)
-
- * poly8x16_t vreinterpretq_p8_s8 (int8x16_t)
-
- * poly8x16_t vreinterpretq_p8_u64 (uint64x2_t)
-
- * poly8x16_t vreinterpretq_p8_s64 (int64x2_t)
-
- * poly8x16_t vreinterpretq_p8_f32 (float32x4_t)
-
- * poly8x16_t vreinterpretq_p8_p16 (poly16x8_t)
-
- * poly16x4_t vreinterpret_p16_u32 (uint32x2_t)
-
- * poly16x4_t vreinterpret_p16_u16 (uint16x4_t)
-
- * poly16x4_t vreinterpret_p16_u8 (uint8x8_t)
-
- * poly16x4_t vreinterpret_p16_s32 (int32x2_t)
-
- * poly16x4_t vreinterpret_p16_s16 (int16x4_t)
-
- * poly16x4_t vreinterpret_p16_s8 (int8x8_t)
-
- * poly16x4_t vreinterpret_p16_u64 (uint64x1_t)
-
- * poly16x4_t vreinterpret_p16_s64 (int64x1_t)
-
- * poly16x4_t vreinterpret_p16_f32 (float32x2_t)
-
- * poly16x4_t vreinterpret_p16_p8 (poly8x8_t)
-
- * poly16x8_t vreinterpretq_p16_u32 (uint32x4_t)
-
- * poly16x8_t vreinterpretq_p16_u16 (uint16x8_t)
-
- * poly16x8_t vreinterpretq_p16_u8 (uint8x16_t)
-
- * poly16x8_t vreinterpretq_p16_s32 (int32x4_t)
-
- * poly16x8_t vreinterpretq_p16_s16 (int16x8_t)
-
- * poly16x8_t vreinterpretq_p16_s8 (int8x16_t)
-
- * poly16x8_t vreinterpretq_p16_u64 (uint64x2_t)
-
- * poly16x8_t vreinterpretq_p16_s64 (int64x2_t)
-
- * poly16x8_t vreinterpretq_p16_f32 (float32x4_t)
-
- * poly16x8_t vreinterpretq_p16_p8 (poly8x16_t)
-
- * float32x2_t vreinterpret_f32_u32 (uint32x2_t)
-
- * float32x2_t vreinterpret_f32_u16 (uint16x4_t)
-
- * float32x2_t vreinterpret_f32_u8 (uint8x8_t)
-
- * float32x2_t vreinterpret_f32_s32 (int32x2_t)
-
- * float32x2_t vreinterpret_f32_s16 (int16x4_t)
-
- * float32x2_t vreinterpret_f32_s8 (int8x8_t)
-
- * float32x2_t vreinterpret_f32_u64 (uint64x1_t)
-
- * float32x2_t vreinterpret_f32_s64 (int64x1_t)
-
- * float32x2_t vreinterpret_f32_p16 (poly16x4_t)
-
- * float32x2_t vreinterpret_f32_p8 (poly8x8_t)
-
- * float32x4_t vreinterpretq_f32_u32 (uint32x4_t)
-
- * float32x4_t vreinterpretq_f32_u16 (uint16x8_t)
-
- * float32x4_t vreinterpretq_f32_u8 (uint8x16_t)
-
- * float32x4_t vreinterpretq_f32_s32 (int32x4_t)
-
- * float32x4_t vreinterpretq_f32_s16 (int16x8_t)
-
- * float32x4_t vreinterpretq_f32_s8 (int8x16_t)
-
- * float32x4_t vreinterpretq_f32_u64 (uint64x2_t)
-
- * float32x4_t vreinterpretq_f32_s64 (int64x2_t)
-
- * float32x4_t vreinterpretq_f32_p16 (poly16x8_t)
-
- * float32x4_t vreinterpretq_f32_p8 (poly8x16_t)
-
- * int64x1_t vreinterpret_s64_u32 (uint32x2_t)
-
- * int64x1_t vreinterpret_s64_u16 (uint16x4_t)
-
- * int64x1_t vreinterpret_s64_u8 (uint8x8_t)
-
- * int64x1_t vreinterpret_s64_s32 (int32x2_t)
-
- * int64x1_t vreinterpret_s64_s16 (int16x4_t)
-
- * int64x1_t vreinterpret_s64_s8 (int8x8_t)
-
- * int64x1_t vreinterpret_s64_u64 (uint64x1_t)
-
- * int64x1_t vreinterpret_s64_f32 (float32x2_t)
-
- * int64x1_t vreinterpret_s64_p16 (poly16x4_t)
-
- * int64x1_t vreinterpret_s64_p8 (poly8x8_t)
-
- * int64x2_t vreinterpretq_s64_u32 (uint32x4_t)
-
- * int64x2_t vreinterpretq_s64_u16 (uint16x8_t)
-
- * int64x2_t vreinterpretq_s64_u8 (uint8x16_t)
-
- * int64x2_t vreinterpretq_s64_s32 (int32x4_t)
-
- * int64x2_t vreinterpretq_s64_s16 (int16x8_t)
-
- * int64x2_t vreinterpretq_s64_s8 (int8x16_t)
-
- * int64x2_t vreinterpretq_s64_u64 (uint64x2_t)
-
- * int64x2_t vreinterpretq_s64_f32 (float32x4_t)
-
- * int64x2_t vreinterpretq_s64_p16 (poly16x8_t)
-
- * int64x2_t vreinterpretq_s64_p8 (poly8x16_t)
-
- * uint64x1_t vreinterpret_u64_u32 (uint32x2_t)
-
- * uint64x1_t vreinterpret_u64_u16 (uint16x4_t)
-
- * uint64x1_t vreinterpret_u64_u8 (uint8x8_t)
-
- * uint64x1_t vreinterpret_u64_s32 (int32x2_t)
-
- * uint64x1_t vreinterpret_u64_s16 (int16x4_t)
-
- * uint64x1_t vreinterpret_u64_s8 (int8x8_t)
-
- * uint64x1_t vreinterpret_u64_s64 (int64x1_t)
-
- * uint64x1_t vreinterpret_u64_f32 (float32x2_t)
-
- * uint64x1_t vreinterpret_u64_p16 (poly16x4_t)
-
- * uint64x1_t vreinterpret_u64_p8 (poly8x8_t)
-
- * uint64x2_t vreinterpretq_u64_u32 (uint32x4_t)
-
- * uint64x2_t vreinterpretq_u64_u16 (uint16x8_t)
-
- * uint64x2_t vreinterpretq_u64_u8 (uint8x16_t)
-
- * uint64x2_t vreinterpretq_u64_s32 (int32x4_t)
-
- * uint64x2_t vreinterpretq_u64_s16 (int16x8_t)
-
- * uint64x2_t vreinterpretq_u64_s8 (int8x16_t)
-
- * uint64x2_t vreinterpretq_u64_s64 (int64x2_t)
-
- * uint64x2_t vreinterpretq_u64_f32 (float32x4_t)
-
- * uint64x2_t vreinterpretq_u64_p16 (poly16x8_t)
-
- * uint64x2_t vreinterpretq_u64_p8 (poly8x16_t)
-
- * int8x8_t vreinterpret_s8_u32 (uint32x2_t)
-
- * int8x8_t vreinterpret_s8_u16 (uint16x4_t)
-
- * int8x8_t vreinterpret_s8_u8 (uint8x8_t)
-
- * int8x8_t vreinterpret_s8_s32 (int32x2_t)
-
- * int8x8_t vreinterpret_s8_s16 (int16x4_t)
-
- * int8x8_t vreinterpret_s8_u64 (uint64x1_t)
-
- * int8x8_t vreinterpret_s8_s64 (int64x1_t)
-
- * int8x8_t vreinterpret_s8_f32 (float32x2_t)
-
- * int8x8_t vreinterpret_s8_p16 (poly16x4_t)
-
- * int8x8_t vreinterpret_s8_p8 (poly8x8_t)
-
- * int8x16_t vreinterpretq_s8_u32 (uint32x4_t)
-
- * int8x16_t vreinterpretq_s8_u16 (uint16x8_t)
-
- * int8x16_t vreinterpretq_s8_u8 (uint8x16_t)
-
- * int8x16_t vreinterpretq_s8_s32 (int32x4_t)
-
- * int8x16_t vreinterpretq_s8_s16 (int16x8_t)
-
- * int8x16_t vreinterpretq_s8_u64 (uint64x2_t)
-
- * int8x16_t vreinterpretq_s8_s64 (int64x2_t)
-
- * int8x16_t vreinterpretq_s8_f32 (float32x4_t)
-
- * int8x16_t vreinterpretq_s8_p16 (poly16x8_t)
-
- * int8x16_t vreinterpretq_s8_p8 (poly8x16_t)
-
- * int16x4_t vreinterpret_s16_u32 (uint32x2_t)
-
- * int16x4_t vreinterpret_s16_u16 (uint16x4_t)
-
- * int16x4_t vreinterpret_s16_u8 (uint8x8_t)
-
- * int16x4_t vreinterpret_s16_s32 (int32x2_t)
-
- * int16x4_t vreinterpret_s16_s8 (int8x8_t)
-
- * int16x4_t vreinterpret_s16_u64 (uint64x1_t)
-
- * int16x4_t vreinterpret_s16_s64 (int64x1_t)
-
- * int16x4_t vreinterpret_s16_f32 (float32x2_t)
-
- * int16x4_t vreinterpret_s16_p16 (poly16x4_t)
-
- * int16x4_t vreinterpret_s16_p8 (poly8x8_t)
-
- * int16x8_t vreinterpretq_s16_u32 (uint32x4_t)
-
- * int16x8_t vreinterpretq_s16_u16 (uint16x8_t)
-
- * int16x8_t vreinterpretq_s16_u8 (uint8x16_t)
-
- * int16x8_t vreinterpretq_s16_s32 (int32x4_t)
-
- * int16x8_t vreinterpretq_s16_s8 (int8x16_t)
-
- * int16x8_t vreinterpretq_s16_u64 (uint64x2_t)
-
- * int16x8_t vreinterpretq_s16_s64 (int64x2_t)
-
- * int16x8_t vreinterpretq_s16_f32 (float32x4_t)
-
- * int16x8_t vreinterpretq_s16_p16 (poly16x8_t)
-
- * int16x8_t vreinterpretq_s16_p8 (poly8x16_t)
-
- * int32x2_t vreinterpret_s32_u32 (uint32x2_t)
-
- * int32x2_t vreinterpret_s32_u16 (uint16x4_t)
-
- * int32x2_t vreinterpret_s32_u8 (uint8x8_t)
-
- * int32x2_t vreinterpret_s32_s16 (int16x4_t)
-
- * int32x2_t vreinterpret_s32_s8 (int8x8_t)
-
- * int32x2_t vreinterpret_s32_u64 (uint64x1_t)
-
- * int32x2_t vreinterpret_s32_s64 (int64x1_t)
-
- * int32x2_t vreinterpret_s32_f32 (float32x2_t)
-
- * int32x2_t vreinterpret_s32_p16 (poly16x4_t)
-
- * int32x2_t vreinterpret_s32_p8 (poly8x8_t)
-
- * int32x4_t vreinterpretq_s32_u32 (uint32x4_t)
-
- * int32x4_t vreinterpretq_s32_u16 (uint16x8_t)
-
- * int32x4_t vreinterpretq_s32_u8 (uint8x16_t)
-
- * int32x4_t vreinterpretq_s32_s16 (int16x8_t)
-
- * int32x4_t vreinterpretq_s32_s8 (int8x16_t)
-
- * int32x4_t vreinterpretq_s32_u64 (uint64x2_t)
-
- * int32x4_t vreinterpretq_s32_s64 (int64x2_t)
-
- * int32x4_t vreinterpretq_s32_f32 (float32x4_t)
-
- * int32x4_t vreinterpretq_s32_p16 (poly16x8_t)
-
- * int32x4_t vreinterpretq_s32_p8 (poly8x16_t)
-
- * uint8x8_t vreinterpret_u8_u32 (uint32x2_t)
-
- * uint8x8_t vreinterpret_u8_u16 (uint16x4_t)
-
- * uint8x8_t vreinterpret_u8_s32 (int32x2_t)
-
- * uint8x8_t vreinterpret_u8_s16 (int16x4_t)
-
- * uint8x8_t vreinterpret_u8_s8 (int8x8_t)
-
- * uint8x8_t vreinterpret_u8_u64 (uint64x1_t)
-
- * uint8x8_t vreinterpret_u8_s64 (int64x1_t)
-
- * uint8x8_t vreinterpret_u8_f32 (float32x2_t)
-
- * uint8x8_t vreinterpret_u8_p16 (poly16x4_t)
-
- * uint8x8_t vreinterpret_u8_p8 (poly8x8_t)
-
- * uint8x16_t vreinterpretq_u8_u32 (uint32x4_t)
-
- * uint8x16_t vreinterpretq_u8_u16 (uint16x8_t)
-
- * uint8x16_t vreinterpretq_u8_s32 (int32x4_t)
-
- * uint8x16_t vreinterpretq_u8_s16 (int16x8_t)
-
- * uint8x16_t vreinterpretq_u8_s8 (int8x16_t)
-
- * uint8x16_t vreinterpretq_u8_u64 (uint64x2_t)
-
- * uint8x16_t vreinterpretq_u8_s64 (int64x2_t)
-
- * uint8x16_t vreinterpretq_u8_f32 (float32x4_t)
-
- * uint8x16_t vreinterpretq_u8_p16 (poly16x8_t)
-
- * uint8x16_t vreinterpretq_u8_p8 (poly8x16_t)
-
- * uint16x4_t vreinterpret_u16_u32 (uint32x2_t)
-
- * uint16x4_t vreinterpret_u16_u8 (uint8x8_t)
-
- * uint16x4_t vreinterpret_u16_s32 (int32x2_t)
-
- * uint16x4_t vreinterpret_u16_s16 (int16x4_t)
-
- * uint16x4_t vreinterpret_u16_s8 (int8x8_t)
-
- * uint16x4_t vreinterpret_u16_u64 (uint64x1_t)
-
- * uint16x4_t vreinterpret_u16_s64 (int64x1_t)
-
- * uint16x4_t vreinterpret_u16_f32 (float32x2_t)
-
- * uint16x4_t vreinterpret_u16_p16 (poly16x4_t)
-
- * uint16x4_t vreinterpret_u16_p8 (poly8x8_t)
-
- * uint16x8_t vreinterpretq_u16_u32 (uint32x4_t)
-
- * uint16x8_t vreinterpretq_u16_u8 (uint8x16_t)
-
- * uint16x8_t vreinterpretq_u16_s32 (int32x4_t)
-
- * uint16x8_t vreinterpretq_u16_s16 (int16x8_t)
-
- * uint16x8_t vreinterpretq_u16_s8 (int8x16_t)
-
- * uint16x8_t vreinterpretq_u16_u64 (uint64x2_t)
-
- * uint16x8_t vreinterpretq_u16_s64 (int64x2_t)
-
- * uint16x8_t vreinterpretq_u16_f32 (float32x4_t)
-
- * uint16x8_t vreinterpretq_u16_p16 (poly16x8_t)
-
- * uint16x8_t vreinterpretq_u16_p8 (poly8x16_t)
-
- * uint32x2_t vreinterpret_u32_u16 (uint16x4_t)
-
- * uint32x2_t vreinterpret_u32_u8 (uint8x8_t)
-
- * uint32x2_t vreinterpret_u32_s32 (int32x2_t)
-
- * uint32x2_t vreinterpret_u32_s16 (int16x4_t)
-
- * uint32x2_t vreinterpret_u32_s8 (int8x8_t)
-
- * uint32x2_t vreinterpret_u32_u64 (uint64x1_t)
-
- * uint32x2_t vreinterpret_u32_s64 (int64x1_t)
-
- * uint32x2_t vreinterpret_u32_f32 (float32x2_t)
-
- * uint32x2_t vreinterpret_u32_p16 (poly16x4_t)
-
- * uint32x2_t vreinterpret_u32_p8 (poly8x8_t)
-
- * uint32x4_t vreinterpretq_u32_u16 (uint16x8_t)
-
- * uint32x4_t vreinterpretq_u32_u8 (uint8x16_t)
-
- * uint32x4_t vreinterpretq_u32_s32 (int32x4_t)
-
- * uint32x4_t vreinterpretq_u32_s16 (int16x8_t)
-
- * uint32x4_t vreinterpretq_u32_s8 (int8x16_t)
-
- * uint32x4_t vreinterpretq_u32_u64 (uint64x2_t)
-
- * uint32x4_t vreinterpretq_u32_s64 (int64x2_t)
-
- * uint32x4_t vreinterpretq_u32_f32 (float32x4_t)
-
- * uint32x4_t vreinterpretq_u32_p16 (poly16x8_t)
-
- * uint32x4_t vreinterpretq_u32_p8 (poly8x16_t)
-
-
-File: gcc.info, Node: Blackfin Built-in Functions, Next: FR-V Built-in Functions, Prev: ARM NEON Intrinsics, Up: Target Builtins
-
-6.54.4 Blackfin Built-in Functions
-----------------------------------
-
-Currently, there are two Blackfin-specific built-in functions. These
-are used for generating `CSYNC' and `SSYNC' machine insns without using
-inline assembly; by using these built-in functions the compiler can
-automatically add workarounds for hardware errata involving these
-instructions. These functions are named as follows:
-
- void __builtin_bfin_csync (void)
- void __builtin_bfin_ssync (void)
-
-
-File: gcc.info, Node: FR-V Built-in Functions, Next: X86 Built-in Functions, Prev: Blackfin Built-in Functions, Up: Target Builtins
-
-6.54.5 FR-V Built-in Functions
-------------------------------
-
-GCC provides many FR-V-specific built-in functions. In general, these
-functions are intended to be compatible with those described by `FR-V
-Family, Softune C/C++ Compiler Manual (V6), Fujitsu Semiconductor'.
-The two exceptions are `__MDUNPACKH' and `__MBTOHE', the gcc forms of
-which pass 128-bit values by pointer rather than by value.
-
- Most of the functions are named after specific FR-V instructions.
-Such functions are said to be "directly mapped" and are summarized here
-in tabular form.
-
-* Menu:
-
-* Argument Types::
-* Directly-mapped Integer Functions::
-* Directly-mapped Media Functions::
-* Raw read/write Functions::
-* Other Built-in Functions::
-
-
-File: gcc.info, Node: Argument Types, Next: Directly-mapped Integer Functions, Up: FR-V Built-in Functions
-
-6.54.5.1 Argument Types
-.......................
-
-The arguments to the built-in functions can be divided into three
-groups: register numbers, compile-time constants and run-time values.
-In order to make this classification clear at a glance, the arguments
-and return values are given the following pseudo types:
-
-Pseudo type Real C type Constant? Description
-`uh' `unsigned short' No an unsigned halfword
-`uw1' `unsigned int' No an unsigned word
-`sw1' `int' No a signed word
-`uw2' `unsigned long long' No an unsigned doubleword
-`sw2' `long long' No a signed doubleword
-`const' `int' Yes an integer constant
-`acc' `int' Yes an ACC register number
-`iacc' `int' Yes an IACC register number
-
- These pseudo types are not defined by GCC, they are simply a notational
-convenience used in this manual.
-
- Arguments of type `uh', `uw1', `sw1', `uw2' and `sw2' are evaluated at
-run time. They correspond to register operands in the underlying FR-V
-instructions.
-
- `const' arguments represent immediate operands in the underlying FR-V
-instructions. They must be compile-time constants.
-
- `acc' arguments are evaluated at compile time and specify the number
-of an accumulator register. For example, an `acc' argument of 2 will
-select the ACC2 register.
-
- `iacc' arguments are similar to `acc' arguments but specify the number
-of an IACC register. See *note Other Built-in Functions:: for more
-details.
-
-
-File: gcc.info, Node: Directly-mapped Integer Functions, Next: Directly-mapped Media Functions, Prev: Argument Types, Up: FR-V Built-in Functions
-
-6.54.5.2 Directly-mapped Integer Functions
-..........................................
-
-The functions listed below map directly to FR-V I-type instructions.
-
-Function prototype Example usage Assembly output
-`sw1 __ADDSS (sw1, sw1)' `C = __ADDSS (A, B)' `ADDSS A,B,C'
-`sw1 __SCAN (sw1, sw1)' `C = __SCAN (A, B)' `SCAN A,B,C'
-`sw1 __SCUTSS (sw1)' `B = __SCUTSS (A)' `SCUTSS A,B'
-`sw1 __SLASS (sw1, sw1)' `C = __SLASS (A, B)' `SLASS A,B,C'
-`void __SMASS (sw1, sw1)' `__SMASS (A, B)' `SMASS A,B'
-`void __SMSSS (sw1, sw1)' `__SMSSS (A, B)' `SMSSS A,B'
-`void __SMU (sw1, sw1)' `__SMU (A, B)' `SMU A,B'
-`sw2 __SMUL (sw1, sw1)' `C = __SMUL (A, B)' `SMUL A,B,C'
-`sw1 __SUBSS (sw1, sw1)' `C = __SUBSS (A, B)' `SUBSS A,B,C'
-`uw2 __UMUL (uw1, uw1)' `C = __UMUL (A, B)' `UMUL A,B,C'
-
-
-File: gcc.info, Node: Directly-mapped Media Functions, Next: Raw read/write Functions, Prev: Directly-mapped Integer Functions, Up: FR-V Built-in Functions
-
-6.54.5.3 Directly-mapped Media Functions
-........................................
-
-The functions listed below map directly to FR-V M-type instructions.
-
-Function prototype Example usage Assembly output
-`uw1 __MABSHS (sw1)' `B = __MABSHS (A)' `MABSHS A,B'
-`void __MADDACCS (acc, acc)' `__MADDACCS (B, A)' `MADDACCS A,B'
-`sw1 __MADDHSS (sw1, sw1)' `C = __MADDHSS (A, B)' `MADDHSS A,B,C'
-`uw1 __MADDHUS (uw1, uw1)' `C = __MADDHUS (A, B)' `MADDHUS A,B,C'
-`uw1 __MAND (uw1, uw1)' `C = __MAND (A, B)' `MAND A,B,C'
-`void __MASACCS (acc, acc)' `__MASACCS (B, A)' `MASACCS A,B'
-`uw1 __MAVEH (uw1, uw1)' `C = __MAVEH (A, B)' `MAVEH A,B,C'
-`uw2 __MBTOH (uw1)' `B = __MBTOH (A)' `MBTOH A,B'
-`void __MBTOHE (uw1 *, uw1)' `__MBTOHE (&B, A)' `MBTOHE A,B'
-`void __MCLRACC (acc)' `__MCLRACC (A)' `MCLRACC A'
-`void __MCLRACCA (void)' `__MCLRACCA ()' `MCLRACCA'
-`uw1 __Mcop1 (uw1, uw1)' `C = __Mcop1 (A, B)' `Mcop1 A,B,C'
-`uw1 __Mcop2 (uw1, uw1)' `C = __Mcop2 (A, B)' `Mcop2 A,B,C'
-`uw1 __MCPLHI (uw2, const)' `C = __MCPLHI (A, B)' `MCPLHI A,#B,C'
-`uw1 __MCPLI (uw2, const)' `C = __MCPLI (A, B)' `MCPLI A,#B,C'
-`void __MCPXIS (acc, sw1, sw1)' `__MCPXIS (C, A, B)' `MCPXIS A,B,C'
-`void __MCPXIU (acc, uw1, uw1)' `__MCPXIU (C, A, B)' `MCPXIU A,B,C'
-`void __MCPXRS (acc, sw1, sw1)' `__MCPXRS (C, A, B)' `MCPXRS A,B,C'
-`void __MCPXRU (acc, uw1, uw1)' `__MCPXRU (C, A, B)' `MCPXRU A,B,C'
-`uw1 __MCUT (acc, uw1)' `C = __MCUT (A, B)' `MCUT A,B,C'
-`uw1 __MCUTSS (acc, sw1)' `C = __MCUTSS (A, B)' `MCUTSS A,B,C'
-`void __MDADDACCS (acc, acc)' `__MDADDACCS (B, A)' `MDADDACCS A,B'
-`void __MDASACCS (acc, acc)' `__MDASACCS (B, A)' `MDASACCS A,B'
-`uw2 __MDCUTSSI (acc, const)' `C = __MDCUTSSI (A, B)' `MDCUTSSI A,#B,C'
-`uw2 __MDPACKH (uw2, uw2)' `C = __MDPACKH (A, B)' `MDPACKH A,B,C'
-`uw2 __MDROTLI (uw2, const)' `C = __MDROTLI (A, B)' `MDROTLI A,#B,C'
-`void __MDSUBACCS (acc, acc)' `__MDSUBACCS (B, A)' `MDSUBACCS A,B'
-`void __MDUNPACKH (uw1 *, uw2)' `__MDUNPACKH (&B, A)' `MDUNPACKH A,B'
-`uw2 __MEXPDHD (uw1, const)' `C = __MEXPDHD (A, B)' `MEXPDHD A,#B,C'
-`uw1 __MEXPDHW (uw1, const)' `C = __MEXPDHW (A, B)' `MEXPDHW A,#B,C'
-`uw1 __MHDSETH (uw1, const)' `C = __MHDSETH (A, B)' `MHDSETH A,#B,C'
-`sw1 __MHDSETS (const)' `B = __MHDSETS (A)' `MHDSETS #A,B'
-`uw1 __MHSETHIH (uw1, const)' `B = __MHSETHIH (B, A)' `MHSETHIH #A,B'
-`sw1 __MHSETHIS (sw1, const)' `B = __MHSETHIS (B, A)' `MHSETHIS #A,B'
-`uw1 __MHSETLOH (uw1, const)' `B = __MHSETLOH (B, A)' `MHSETLOH #A,B'
-`sw1 __MHSETLOS (sw1, const)' `B = __MHSETLOS (B, A)' `MHSETLOS #A,B'
-`uw1 __MHTOB (uw2)' `B = __MHTOB (A)' `MHTOB A,B'
-`void __MMACHS (acc, sw1, sw1)' `__MMACHS (C, A, B)' `MMACHS A,B,C'
-`void __MMACHU (acc, uw1, uw1)' `__MMACHU (C, A, B)' `MMACHU A,B,C'
-`void __MMRDHS (acc, sw1, sw1)' `__MMRDHS (C, A, B)' `MMRDHS A,B,C'
-`void __MMRDHU (acc, uw1, uw1)' `__MMRDHU (C, A, B)' `MMRDHU A,B,C'
-`void __MMULHS (acc, sw1, sw1)' `__MMULHS (C, A, B)' `MMULHS A,B,C'
-`void __MMULHU (acc, uw1, uw1)' `__MMULHU (C, A, B)' `MMULHU A,B,C'
-`void __MMULXHS (acc, sw1, sw1)' `__MMULXHS (C, A, B)' `MMULXHS A,B,C'
-`void __MMULXHU (acc, uw1, uw1)' `__MMULXHU (C, A, B)' `MMULXHU A,B,C'
-`uw1 __MNOT (uw1)' `B = __MNOT (A)' `MNOT A,B'
-`uw1 __MOR (uw1, uw1)' `C = __MOR (A, B)' `MOR A,B,C'
-`uw1 __MPACKH (uh, uh)' `C = __MPACKH (A, B)' `MPACKH A,B,C'
-`sw2 __MQADDHSS (sw2, sw2)' `C = __MQADDHSS (A, B)' `MQADDHSS A,B,C'
-`uw2 __MQADDHUS (uw2, uw2)' `C = __MQADDHUS (A, B)' `MQADDHUS A,B,C'
-`void __MQCPXIS (acc, sw2, sw2)' `__MQCPXIS (C, A, B)' `MQCPXIS A,B,C'
-`void __MQCPXIU (acc, uw2, uw2)' `__MQCPXIU (C, A, B)' `MQCPXIU A,B,C'
-`void __MQCPXRS (acc, sw2, sw2)' `__MQCPXRS (C, A, B)' `MQCPXRS A,B,C'
-`void __MQCPXRU (acc, uw2, uw2)' `__MQCPXRU (C, A, B)' `MQCPXRU A,B,C'
-`sw2 __MQLCLRHS (sw2, sw2)' `C = __MQLCLRHS (A, B)' `MQLCLRHS A,B,C'
-`sw2 __MQLMTHS (sw2, sw2)' `C = __MQLMTHS (A, B)' `MQLMTHS A,B,C'
-`void __MQMACHS (acc, sw2, sw2)' `__MQMACHS (C, A, B)' `MQMACHS A,B,C'
-`void __MQMACHU (acc, uw2, uw2)' `__MQMACHU (C, A, B)' `MQMACHU A,B,C'
-`void __MQMACXHS (acc, sw2, `__MQMACXHS (C, A, B)' `MQMACXHS A,B,C'
-sw2)'
-`void __MQMULHS (acc, sw2, sw2)' `__MQMULHS (C, A, B)' `MQMULHS A,B,C'
-`void __MQMULHU (acc, uw2, uw2)' `__MQMULHU (C, A, B)' `MQMULHU A,B,C'
-`void __MQMULXHS (acc, sw2, `__MQMULXHS (C, A, B)' `MQMULXHS A,B,C'
-sw2)'
-`void __MQMULXHU (acc, uw2, `__MQMULXHU (C, A, B)' `MQMULXHU A,B,C'
-uw2)'
-`sw2 __MQSATHS (sw2, sw2)' `C = __MQSATHS (A, B)' `MQSATHS A,B,C'
-`uw2 __MQSLLHI (uw2, int)' `C = __MQSLLHI (A, B)' `MQSLLHI A,B,C'
-`sw2 __MQSRAHI (sw2, int)' `C = __MQSRAHI (A, B)' `MQSRAHI A,B,C'
-`sw2 __MQSUBHSS (sw2, sw2)' `C = __MQSUBHSS (A, B)' `MQSUBHSS A,B,C'
-`uw2 __MQSUBHUS (uw2, uw2)' `C = __MQSUBHUS (A, B)' `MQSUBHUS A,B,C'
-`void __MQXMACHS (acc, sw2, `__MQXMACHS (C, A, B)' `MQXMACHS A,B,C'
-sw2)'
-`void __MQXMACXHS (acc, sw2, `__MQXMACXHS (C, A, B)' `MQXMACXHS A,B,C'
-sw2)'
-`uw1 __MRDACC (acc)' `B = __MRDACC (A)' `MRDACC A,B'
-`uw1 __MRDACCG (acc)' `B = __MRDACCG (A)' `MRDACCG A,B'
-`uw1 __MROTLI (uw1, const)' `C = __MROTLI (A, B)' `MROTLI A,#B,C'
-`uw1 __MROTRI (uw1, const)' `C = __MROTRI (A, B)' `MROTRI A,#B,C'
-`sw1 __MSATHS (sw1, sw1)' `C = __MSATHS (A, B)' `MSATHS A,B,C'
-`uw1 __MSATHU (uw1, uw1)' `C = __MSATHU (A, B)' `MSATHU A,B,C'
-`uw1 __MSLLHI (uw1, const)' `C = __MSLLHI (A, B)' `MSLLHI A,#B,C'
-`sw1 __MSRAHI (sw1, const)' `C = __MSRAHI (A, B)' `MSRAHI A,#B,C'
-`uw1 __MSRLHI (uw1, const)' `C = __MSRLHI (A, B)' `MSRLHI A,#B,C'
-`void __MSUBACCS (acc, acc)' `__MSUBACCS (B, A)' `MSUBACCS A,B'
-`sw1 __MSUBHSS (sw1, sw1)' `C = __MSUBHSS (A, B)' `MSUBHSS A,B,C'
-`uw1 __MSUBHUS (uw1, uw1)' `C = __MSUBHUS (A, B)' `MSUBHUS A,B,C'
-`void __MTRAP (void)' `__MTRAP ()' `MTRAP'
-`uw2 __MUNPACKH (uw1)' `B = __MUNPACKH (A)' `MUNPACKH A,B'
-`uw1 __MWCUT (uw2, uw1)' `C = __MWCUT (A, B)' `MWCUT A,B,C'
-`void __MWTACC (acc, uw1)' `__MWTACC (B, A)' `MWTACC A,B'
-`void __MWTACCG (acc, uw1)' `__MWTACCG (B, A)' `MWTACCG A,B'
-`uw1 __MXOR (uw1, uw1)' `C = __MXOR (A, B)' `MXOR A,B,C'
-
-
-File: gcc.info, Node: Raw read/write Functions, Next: Other Built-in Functions, Prev: Directly-mapped Media Functions, Up: FR-V Built-in Functions
-
-6.54.5.4 Raw read/write Functions
-.................................
-
-This sections describes built-in functions related to read and write
-instructions to access memory. These functions generate `membar'
-instructions to flush the I/O load and stores where appropriate, as
-described in Fujitsu's manual described above.
-
-`unsigned char __builtin_read8 (void *DATA)'
-
-`unsigned short __builtin_read16 (void *DATA)'
-
-`unsigned long __builtin_read32 (void *DATA)'
-
-`unsigned long long __builtin_read64 (void *DATA)'
-
-`void __builtin_write8 (void *DATA, unsigned char DATUM)'
-
-`void __builtin_write16 (void *DATA, unsigned short DATUM)'
-
-`void __builtin_write32 (void *DATA, unsigned long DATUM)'
-
-`void __builtin_write64 (void *DATA, unsigned long long DATUM)'
-
-
-File: gcc.info, Node: Other Built-in Functions, Prev: Raw read/write Functions, Up: FR-V Built-in Functions
-
-6.54.5.5 Other Built-in Functions
-.................................
-
-This section describes built-in functions that are not named after a
-specific FR-V instruction.
-
-`sw2 __IACCreadll (iacc REG)'
- Return the full 64-bit value of IACC0. The REG argument is
- reserved for future expansion and must be 0.
-
-`sw1 __IACCreadl (iacc REG)'
- Return the value of IACC0H if REG is 0 and IACC0L if REG is 1.
- Other values of REG are rejected as invalid.
-
-`void __IACCsetll (iacc REG, sw2 X)'
- Set the full 64-bit value of IACC0 to X. The REG argument is
- reserved for future expansion and must be 0.
-
-`void __IACCsetl (iacc REG, sw1 X)'
- Set IACC0H to X if REG is 0 and IACC0L to X if REG is 1. Other
- values of REG are rejected as invalid.
-
-`void __data_prefetch0 (const void *X)'
- Use the `dcpl' instruction to load the contents of address X into
- the data cache.
-
-`void __data_prefetch (const void *X)'
- Use the `nldub' instruction to load the contents of address X into
- the data cache. The instruction will be issued in slot I1.
-
-
-File: gcc.info, Node: X86 Built-in Functions, Next: MIPS DSP Built-in Functions, Prev: FR-V Built-in Functions, Up: Target Builtins
-
-6.54.6 X86 Built-in Functions
------------------------------
-
-These built-in functions are available for the i386 and x86-64 family
-of computers, depending on the command-line switches used.
-
- Note that, if you specify command-line switches such as `-msse', the
-compiler could use the extended instruction sets even if the built-ins
-are not used explicitly in the program. For this reason, applications
-which perform runtime CPU detection must compile separate files for each
-supported architecture, using the appropriate flags. In particular,
-the file containing the CPU detection code should be compiled without
-these options.
-
- The following machine modes are available for use with MMX built-in
-functions (*note Vector Extensions::): `V2SI' for a vector of two
-32-bit integers, `V4HI' for a vector of four 16-bit integers, and
-`V8QI' for a vector of eight 8-bit integers. Some of the built-in
-functions operate on MMX registers as a whole 64-bit entity, these use
-`V1DI' as their mode.
-
- If 3DNow! extensions are enabled, `V2SF' is used as a mode for a vector
-of two 32-bit floating point values.
-
- If SSE extensions are enabled, `V4SF' is used for a vector of four
-32-bit floating point values. Some instructions use a vector of four
-32-bit integers, these use `V4SI'. Finally, some instructions operate
-on an entire vector register, interpreting it as a 128-bit integer,
-these use mode `TI'.
-
- In 64-bit mode, the x86-64 family of processors uses additional
-built-in functions for efficient use of `TF' (`__float128') 128-bit
-floating point and `TC' 128-bit complex floating point values.
-
- The following floating point built-in functions are available in 64-bit
-mode. All of them implement the function that is part of the name.
-
- __float128 __builtin_fabsq (__float128)
- __float128 __builtin_copysignq (__float128, __float128)
-
- The following floating point built-in functions are made available in
-the 64-bit mode.
-
-`__float128 __builtin_infq (void)'
- Similar to `__builtin_inf', except the return type is `__float128'.
-
-`__float128 __builtin_huge_valq (void)'
- Similar to `__builtin_huge_val', except the return type is
- `__float128'.
-
- The following built-in functions are made available by `-mmmx'. All
-of them generate the machine instruction that is part of the name.
-
- v8qi __builtin_ia32_paddb (v8qi, v8qi)
- v4hi __builtin_ia32_paddw (v4hi, v4hi)
- v2si __builtin_ia32_paddd (v2si, v2si)
- v8qi __builtin_ia32_psubb (v8qi, v8qi)
- v4hi __builtin_ia32_psubw (v4hi, v4hi)
- v2si __builtin_ia32_psubd (v2si, v2si)
- v8qi __builtin_ia32_paddsb (v8qi, v8qi)
- v4hi __builtin_ia32_paddsw (v4hi, v4hi)
- v8qi __builtin_ia32_psubsb (v8qi, v8qi)
- v4hi __builtin_ia32_psubsw (v4hi, v4hi)
- v8qi __builtin_ia32_paddusb (v8qi, v8qi)
- v4hi __builtin_ia32_paddusw (v4hi, v4hi)
- v8qi __builtin_ia32_psubusb (v8qi, v8qi)
- v4hi __builtin_ia32_psubusw (v4hi, v4hi)
- v4hi __builtin_ia32_pmullw (v4hi, v4hi)
- v4hi __builtin_ia32_pmulhw (v4hi, v4hi)
- di __builtin_ia32_pand (di, di)
- di __builtin_ia32_pandn (di,di)
- di __builtin_ia32_por (di, di)
- di __builtin_ia32_pxor (di, di)
- v8qi __builtin_ia32_pcmpeqb (v8qi, v8qi)
- v4hi __builtin_ia32_pcmpeqw (v4hi, v4hi)
- v2si __builtin_ia32_pcmpeqd (v2si, v2si)
- v8qi __builtin_ia32_pcmpgtb (v8qi, v8qi)
- v4hi __builtin_ia32_pcmpgtw (v4hi, v4hi)
- v2si __builtin_ia32_pcmpgtd (v2si, v2si)
- v8qi __builtin_ia32_punpckhbw (v8qi, v8qi)
- v4hi __builtin_ia32_punpckhwd (v4hi, v4hi)
- v2si __builtin_ia32_punpckhdq (v2si, v2si)
- v8qi __builtin_ia32_punpcklbw (v8qi, v8qi)
- v4hi __builtin_ia32_punpcklwd (v4hi, v4hi)
- v2si __builtin_ia32_punpckldq (v2si, v2si)
- v8qi __builtin_ia32_packsswb (v4hi, v4hi)
- v4hi __builtin_ia32_packssdw (v2si, v2si)
- v8qi __builtin_ia32_packuswb (v4hi, v4hi)
-
- v4hi __builtin_ia32_psllw (v4hi, v4hi)
- v2si __builtin_ia32_pslld (v2si, v2si)
- v1di __builtin_ia32_psllq (v1di, v1di)
- v4hi __builtin_ia32_psrlw (v4hi, v4hi)
- v2si __builtin_ia32_psrld (v2si, v2si)
- v1di __builtin_ia32_psrlq (v1di, v1di)
- v4hi __builtin_ia32_psraw (v4hi, v4hi)
- v2si __builtin_ia32_psrad (v2si, v2si)
- v4hi __builtin_ia32_psllwi (v4hi, int)
- v2si __builtin_ia32_pslldi (v2si, int)
- v1di __builtin_ia32_psllqi (v1di, int)
- v4hi __builtin_ia32_psrlwi (v4hi, int)
- v2si __builtin_ia32_psrldi (v2si, int)
- v1di __builtin_ia32_psrlqi (v1di, int)
- v4hi __builtin_ia32_psrawi (v4hi, int)
- v2si __builtin_ia32_psradi (v2si, int)
-
- The following built-in functions are made available either with
-`-msse', or with a combination of `-m3dnow' and `-march=athlon'. All
-of them generate the machine instruction that is part of the name.
-
- v4hi __builtin_ia32_pmulhuw (v4hi, v4hi)
- v8qi __builtin_ia32_pavgb (v8qi, v8qi)
- v4hi __builtin_ia32_pavgw (v4hi, v4hi)
- v1di __builtin_ia32_psadbw (v8qi, v8qi)
- v8qi __builtin_ia32_pmaxub (v8qi, v8qi)
- v4hi __builtin_ia32_pmaxsw (v4hi, v4hi)
- v8qi __builtin_ia32_pminub (v8qi, v8qi)
- v4hi __builtin_ia32_pminsw (v4hi, v4hi)
- int __builtin_ia32_pextrw (v4hi, int)
- v4hi __builtin_ia32_pinsrw (v4hi, int, int)
- int __builtin_ia32_pmovmskb (v8qi)
- void __builtin_ia32_maskmovq (v8qi, v8qi, char *)
- void __builtin_ia32_movntq (di *, di)
- void __builtin_ia32_sfence (void)
-
- The following built-in functions are available when `-msse' is used.
-All of them generate the machine instruction that is part of the name.
-
- int __builtin_ia32_comieq (v4sf, v4sf)
- int __builtin_ia32_comineq (v4sf, v4sf)
- int __builtin_ia32_comilt (v4sf, v4sf)
- int __builtin_ia32_comile (v4sf, v4sf)
- int __builtin_ia32_comigt (v4sf, v4sf)
- int __builtin_ia32_comige (v4sf, v4sf)
- int __builtin_ia32_ucomieq (v4sf, v4sf)
- int __builtin_ia32_ucomineq (v4sf, v4sf)
- int __builtin_ia32_ucomilt (v4sf, v4sf)
- int __builtin_ia32_ucomile (v4sf, v4sf)
- int __builtin_ia32_ucomigt (v4sf, v4sf)
- int __builtin_ia32_ucomige (v4sf, v4sf)
- v4sf __builtin_ia32_addps (v4sf, v4sf)
- v4sf __builtin_ia32_subps (v4sf, v4sf)
- v4sf __builtin_ia32_mulps (v4sf, v4sf)
- v4sf __builtin_ia32_divps (v4sf, v4sf)
- v4sf __builtin_ia32_addss (v4sf, v4sf)
- v4sf __builtin_ia32_subss (v4sf, v4sf)
- v4sf __builtin_ia32_mulss (v4sf, v4sf)
- v4sf __builtin_ia32_divss (v4sf, v4sf)
- v4si __builtin_ia32_cmpeqps (v4sf, v4sf)
- v4si __builtin_ia32_cmpltps (v4sf, v4sf)
- v4si __builtin_ia32_cmpleps (v4sf, v4sf)
- v4si __builtin_ia32_cmpgtps (v4sf, v4sf)
- v4si __builtin_ia32_cmpgeps (v4sf, v4sf)
- v4si __builtin_ia32_cmpunordps (v4sf, v4sf)
- v4si __builtin_ia32_cmpneqps (v4sf, v4sf)
- v4si __builtin_ia32_cmpnltps (v4sf, v4sf)
- v4si __builtin_ia32_cmpnleps (v4sf, v4sf)
- v4si __builtin_ia32_cmpngtps (v4sf, v4sf)
- v4si __builtin_ia32_cmpngeps (v4sf, v4sf)
- v4si __builtin_ia32_cmpordps (v4sf, v4sf)
- v4si __builtin_ia32_cmpeqss (v4sf, v4sf)
- v4si __builtin_ia32_cmpltss (v4sf, v4sf)
- v4si __builtin_ia32_cmpless (v4sf, v4sf)
- v4si __builtin_ia32_cmpunordss (v4sf, v4sf)
- v4si __builtin_ia32_cmpneqss (v4sf, v4sf)
- v4si __builtin_ia32_cmpnlts (v4sf, v4sf)
- v4si __builtin_ia32_cmpnless (v4sf, v4sf)
- v4si __builtin_ia32_cmpordss (v4sf, v4sf)
- v4sf __builtin_ia32_maxps (v4sf, v4sf)
- v4sf __builtin_ia32_maxss (v4sf, v4sf)
- v4sf __builtin_ia32_minps (v4sf, v4sf)
- v4sf __builtin_ia32_minss (v4sf, v4sf)
- v4sf __builtin_ia32_andps (v4sf, v4sf)
- v4sf __builtin_ia32_andnps (v4sf, v4sf)
- v4sf __builtin_ia32_orps (v4sf, v4sf)
- v4sf __builtin_ia32_xorps (v4sf, v4sf)
- v4sf __builtin_ia32_movss (v4sf, v4sf)
- v4sf __builtin_ia32_movhlps (v4sf, v4sf)
- v4sf __builtin_ia32_movlhps (v4sf, v4sf)
- v4sf __builtin_ia32_unpckhps (v4sf, v4sf)
- v4sf __builtin_ia32_unpcklps (v4sf, v4sf)
- v4sf __builtin_ia32_cvtpi2ps (v4sf, v2si)
- v4sf __builtin_ia32_cvtsi2ss (v4sf, int)
- v2si __builtin_ia32_cvtps2pi (v4sf)
- int __builtin_ia32_cvtss2si (v4sf)
- v2si __builtin_ia32_cvttps2pi (v4sf)
- int __builtin_ia32_cvttss2si (v4sf)
- v4sf __builtin_ia32_rcpps (v4sf)
- v4sf __builtin_ia32_rsqrtps (v4sf)
- v4sf __builtin_ia32_sqrtps (v4sf)
- v4sf __builtin_ia32_rcpss (v4sf)
- v4sf __builtin_ia32_rsqrtss (v4sf)
- v4sf __builtin_ia32_sqrtss (v4sf)
- v4sf __builtin_ia32_shufps (v4sf, v4sf, int)
- void __builtin_ia32_movntps (float *, v4sf)
- int __builtin_ia32_movmskps (v4sf)
-
- The following built-in functions are available when `-msse' is used.
-
-`v4sf __builtin_ia32_loadaps (float *)'
- Generates the `movaps' machine instruction as a load from memory.
-
-`void __builtin_ia32_storeaps (float *, v4sf)'
- Generates the `movaps' machine instruction as a store to memory.
-
-`v4sf __builtin_ia32_loadups (float *)'
- Generates the `movups' machine instruction as a load from memory.
-
-`void __builtin_ia32_storeups (float *, v4sf)'
- Generates the `movups' machine instruction as a store to memory.
-
-`v4sf __builtin_ia32_loadsss (float *)'
- Generates the `movss' machine instruction as a load from memory.
-
-`void __builtin_ia32_storess (float *, v4sf)'
- Generates the `movss' machine instruction as a store to memory.
-
-`v4sf __builtin_ia32_loadhps (v4sf, const v2sf *)'
- Generates the `movhps' machine instruction as a load from memory.
-
-`v4sf __builtin_ia32_loadlps (v4sf, const v2sf *)'
- Generates the `movlps' machine instruction as a load from memory
-
-`void __builtin_ia32_storehps (v2sf *, v4sf)'
- Generates the `movhps' machine instruction as a store to memory.
-
-`void __builtin_ia32_storelps (v2sf *, v4sf)'
- Generates the `movlps' machine instruction as a store to memory.
-
- The following built-in functions are available when `-msse2' is used.
-All of them generate the machine instruction that is part of the name.
-
- int __builtin_ia32_comisdeq (v2df, v2df)
- int __builtin_ia32_comisdlt (v2df, v2df)
- int __builtin_ia32_comisdle (v2df, v2df)
- int __builtin_ia32_comisdgt (v2df, v2df)
- int __builtin_ia32_comisdge (v2df, v2df)
- int __builtin_ia32_comisdneq (v2df, v2df)
- int __builtin_ia32_ucomisdeq (v2df, v2df)
- int __builtin_ia32_ucomisdlt (v2df, v2df)
- int __builtin_ia32_ucomisdle (v2df, v2df)
- int __builtin_ia32_ucomisdgt (v2df, v2df)
- int __builtin_ia32_ucomisdge (v2df, v2df)
- int __builtin_ia32_ucomisdneq (v2df, v2df)
- v2df __builtin_ia32_cmpeqpd (v2df, v2df)
- v2df __builtin_ia32_cmpltpd (v2df, v2df)
- v2df __builtin_ia32_cmplepd (v2df, v2df)
- v2df __builtin_ia32_cmpgtpd (v2df, v2df)
- v2df __builtin_ia32_cmpgepd (v2df, v2df)
- v2df __builtin_ia32_cmpunordpd (v2df, v2df)
- v2df __builtin_ia32_cmpneqpd (v2df, v2df)
- v2df __builtin_ia32_cmpnltpd (v2df, v2df)
- v2df __builtin_ia32_cmpnlepd (v2df, v2df)
- v2df __builtin_ia32_cmpngtpd (v2df, v2df)
- v2df __builtin_ia32_cmpngepd (v2df, v2df)
- v2df __builtin_ia32_cmpordpd (v2df, v2df)
- v2df __builtin_ia32_cmpeqsd (v2df, v2df)
- v2df __builtin_ia32_cmpltsd (v2df, v2df)
- v2df __builtin_ia32_cmplesd (v2df, v2df)
- v2df __builtin_ia32_cmpunordsd (v2df, v2df)
- v2df __builtin_ia32_cmpneqsd (v2df, v2df)
- v2df __builtin_ia32_cmpnltsd (v2df, v2df)
- v2df __builtin_ia32_cmpnlesd (v2df, v2df)
- v2df __builtin_ia32_cmpordsd (v2df, v2df)
- v2di __builtin_ia32_paddq (v2di, v2di)
- v2di __builtin_ia32_psubq (v2di, v2di)
- v2df __builtin_ia32_addpd (v2df, v2df)
- v2df __builtin_ia32_subpd (v2df, v2df)
- v2df __builtin_ia32_mulpd (v2df, v2df)
- v2df __builtin_ia32_divpd (v2df, v2df)
- v2df __builtin_ia32_addsd (v2df, v2df)
- v2df __builtin_ia32_subsd (v2df, v2df)
- v2df __builtin_ia32_mulsd (v2df, v2df)
- v2df __builtin_ia32_divsd (v2df, v2df)
- v2df __builtin_ia32_minpd (v2df, v2df)
- v2df __builtin_ia32_maxpd (v2df, v2df)
- v2df __builtin_ia32_minsd (v2df, v2df)
- v2df __builtin_ia32_maxsd (v2df, v2df)
- v2df __builtin_ia32_andpd (v2df, v2df)
- v2df __builtin_ia32_andnpd (v2df, v2df)
- v2df __builtin_ia32_orpd (v2df, v2df)
- v2df __builtin_ia32_xorpd (v2df, v2df)
- v2df __builtin_ia32_movsd (v2df, v2df)
- v2df __builtin_ia32_unpckhpd (v2df, v2df)
- v2df __builtin_ia32_unpcklpd (v2df, v2df)
- v16qi __builtin_ia32_paddb128 (v16qi, v16qi)
- v8hi __builtin_ia32_paddw128 (v8hi, v8hi)
- v4si __builtin_ia32_paddd128 (v4si, v4si)
- v2di __builtin_ia32_paddq128 (v2di, v2di)
- v16qi __builtin_ia32_psubb128 (v16qi, v16qi)
- v8hi __builtin_ia32_psubw128 (v8hi, v8hi)
- v4si __builtin_ia32_psubd128 (v4si, v4si)
- v2di __builtin_ia32_psubq128 (v2di, v2di)
- v8hi __builtin_ia32_pmullw128 (v8hi, v8hi)
- v8hi __builtin_ia32_pmulhw128 (v8hi, v8hi)
- v2di __builtin_ia32_pand128 (v2di, v2di)
- v2di __builtin_ia32_pandn128 (v2di, v2di)
- v2di __builtin_ia32_por128 (v2di, v2di)
- v2di __builtin_ia32_pxor128 (v2di, v2di)
- v16qi __builtin_ia32_pavgb128 (v16qi, v16qi)
- v8hi __builtin_ia32_pavgw128 (v8hi, v8hi)
- v16qi __builtin_ia32_pcmpeqb128 (v16qi, v16qi)
- v8hi __builtin_ia32_pcmpeqw128 (v8hi, v8hi)
- v4si __builtin_ia32_pcmpeqd128 (v4si, v4si)
- v16qi __builtin_ia32_pcmpgtb128 (v16qi, v16qi)
- v8hi __builtin_ia32_pcmpgtw128 (v8hi, v8hi)
- v4si __builtin_ia32_pcmpgtd128 (v4si, v4si)
- v16qi __builtin_ia32_pmaxub128 (v16qi, v16qi)
- v8hi __builtin_ia32_pmaxsw128 (v8hi, v8hi)
- v16qi __builtin_ia32_pminub128 (v16qi, v16qi)
- v8hi __builtin_ia32_pminsw128 (v8hi, v8hi)
- v16qi __builtin_ia32_punpckhbw128 (v16qi, v16qi)
- v8hi __builtin_ia32_punpckhwd128 (v8hi, v8hi)
- v4si __builtin_ia32_punpckhdq128 (v4si, v4si)
- v2di __builtin_ia32_punpckhqdq128 (v2di, v2di)
- v16qi __builtin_ia32_punpcklbw128 (v16qi, v16qi)
- v8hi __builtin_ia32_punpcklwd128 (v8hi, v8hi)
- v4si __builtin_ia32_punpckldq128 (v4si, v4si)
- v2di __builtin_ia32_punpcklqdq128 (v2di, v2di)
- v16qi __builtin_ia32_packsswb128 (v8hi, v8hi)
- v8hi __builtin_ia32_packssdw128 (v4si, v4si)
- v16qi __builtin_ia32_packuswb128 (v8hi, v8hi)
- v8hi __builtin_ia32_pmulhuw128 (v8hi, v8hi)
- void __builtin_ia32_maskmovdqu (v16qi, v16qi)
- v2df __builtin_ia32_loadupd (double *)
- void __builtin_ia32_storeupd (double *, v2df)
- v2df __builtin_ia32_loadhpd (v2df, double const *)
- v2df __builtin_ia32_loadlpd (v2df, double const *)
- int __builtin_ia32_movmskpd (v2df)
- int __builtin_ia32_pmovmskb128 (v16qi)
- void __builtin_ia32_movnti (int *, int)
- void __builtin_ia32_movntpd (double *, v2df)
- void __builtin_ia32_movntdq (v2df *, v2df)
- v4si __builtin_ia32_pshufd (v4si, int)
- v8hi __builtin_ia32_pshuflw (v8hi, int)
- v8hi __builtin_ia32_pshufhw (v8hi, int)
- v2di __builtin_ia32_psadbw128 (v16qi, v16qi)
- v2df __builtin_ia32_sqrtpd (v2df)
- v2df __builtin_ia32_sqrtsd (v2df)
- v2df __builtin_ia32_shufpd (v2df, v2df, int)
- v2df __builtin_ia32_cvtdq2pd (v4si)
- v4sf __builtin_ia32_cvtdq2ps (v4si)
- v4si __builtin_ia32_cvtpd2dq (v2df)
- v2si __builtin_ia32_cvtpd2pi (v2df)
- v4sf __builtin_ia32_cvtpd2ps (v2df)
- v4si __builtin_ia32_cvttpd2dq (v2df)
- v2si __builtin_ia32_cvttpd2pi (v2df)
- v2df __builtin_ia32_cvtpi2pd (v2si)
- int __builtin_ia32_cvtsd2si (v2df)
- int __builtin_ia32_cvttsd2si (v2df)
- long long __builtin_ia32_cvtsd2si64 (v2df)
- long long __builtin_ia32_cvttsd2si64 (v2df)
- v4si __builtin_ia32_cvtps2dq (v4sf)
- v2df __builtin_ia32_cvtps2pd (v4sf)
- v4si __builtin_ia32_cvttps2dq (v4sf)
- v2df __builtin_ia32_cvtsi2sd (v2df, int)
- v2df __builtin_ia32_cvtsi642sd (v2df, long long)
- v4sf __builtin_ia32_cvtsd2ss (v4sf, v2df)
- v2df __builtin_ia32_cvtss2sd (v2df, v4sf)
- void __builtin_ia32_clflush (const void *)
- void __builtin_ia32_lfence (void)
- void __builtin_ia32_mfence (void)
- v16qi __builtin_ia32_loaddqu (const char *)
- void __builtin_ia32_storedqu (char *, v16qi)
- v1di __builtin_ia32_pmuludq (v2si, v2si)
- v2di __builtin_ia32_pmuludq128 (v4si, v4si)
- v8hi __builtin_ia32_psllw128 (v8hi, v8hi)
- v4si __builtin_ia32_pslld128 (v4si, v4si)
- v2di __builtin_ia32_psllq128 (v2di, v2di)
- v8hi __builtin_ia32_psrlw128 (v8hi, v8hi)
- v4si __builtin_ia32_psrld128 (v4si, v4si)
- v2di __builtin_ia32_psrlq128 (v2di, v2di)
- v8hi __builtin_ia32_psraw128 (v8hi, v8hi)
- v4si __builtin_ia32_psrad128 (v4si, v4si)
- v2di __builtin_ia32_pslldqi128 (v2di, int)
- v8hi __builtin_ia32_psllwi128 (v8hi, int)
- v4si __builtin_ia32_pslldi128 (v4si, int)
- v2di __builtin_ia32_psllqi128 (v2di, int)
- v2di __builtin_ia32_psrldqi128 (v2di, int)
- v8hi __builtin_ia32_psrlwi128 (v8hi, int)
- v4si __builtin_ia32_psrldi128 (v4si, int)
- v2di __builtin_ia32_psrlqi128 (v2di, int)
- v8hi __builtin_ia32_psrawi128 (v8hi, int)
- v4si __builtin_ia32_psradi128 (v4si, int)
- v4si __builtin_ia32_pmaddwd128 (v8hi, v8hi)
- v2di __builtin_ia32_movq128 (v2di)
-
- The following built-in functions are available when `-msse3' is used.
-All of them generate the machine instruction that is part of the name.
-
- v2df __builtin_ia32_addsubpd (v2df, v2df)
- v4sf __builtin_ia32_addsubps (v4sf, v4sf)
- v2df __builtin_ia32_haddpd (v2df, v2df)
- v4sf __builtin_ia32_haddps (v4sf, v4sf)
- v2df __builtin_ia32_hsubpd (v2df, v2df)
- v4sf __builtin_ia32_hsubps (v4sf, v4sf)
- v16qi __builtin_ia32_lddqu (char const *)
- void __builtin_ia32_monitor (void *, unsigned int, unsigned int)
- v2df __builtin_ia32_movddup (v2df)
- v4sf __builtin_ia32_movshdup (v4sf)
- v4sf __builtin_ia32_movsldup (v4sf)
- void __builtin_ia32_mwait (unsigned int, unsigned int)
-
- The following built-in functions are available when `-msse3' is used.
-
-`v2df __builtin_ia32_loadddup (double const *)'
- Generates the `movddup' machine instruction as a load from memory.
-
- The following built-in functions are available when `-mssse3' is used.
-All of them generate the machine instruction that is part of the name
-with MMX registers.
-
- v2si __builtin_ia32_phaddd (v2si, v2si)
- v4hi __builtin_ia32_phaddw (v4hi, v4hi)
- v4hi __builtin_ia32_phaddsw (v4hi, v4hi)
- v2si __builtin_ia32_phsubd (v2si, v2si)
- v4hi __builtin_ia32_phsubw (v4hi, v4hi)
- v4hi __builtin_ia32_phsubsw (v4hi, v4hi)
- v4hi __builtin_ia32_pmaddubsw (v8qi, v8qi)
- v4hi __builtin_ia32_pmulhrsw (v4hi, v4hi)
- v8qi __builtin_ia32_pshufb (v8qi, v8qi)
- v8qi __builtin_ia32_psignb (v8qi, v8qi)
- v2si __builtin_ia32_psignd (v2si, v2si)
- v4hi __builtin_ia32_psignw (v4hi, v4hi)
- v1di __builtin_ia32_palignr (v1di, v1di, int)
- v8qi __builtin_ia32_pabsb (v8qi)
- v2si __builtin_ia32_pabsd (v2si)
- v4hi __builtin_ia32_pabsw (v4hi)
-
- The following built-in functions are available when `-mssse3' is used.
-All of them generate the machine instruction that is part of the name
-with SSE registers.
-
- v4si __builtin_ia32_phaddd128 (v4si, v4si)
- v8hi __builtin_ia32_phaddw128 (v8hi, v8hi)
- v8hi __builtin_ia32_phaddsw128 (v8hi, v8hi)
- v4si __builtin_ia32_phsubd128 (v4si, v4si)
- v8hi __builtin_ia32_phsubw128 (v8hi, v8hi)
- v8hi __builtin_ia32_phsubsw128 (v8hi, v8hi)
- v8hi __builtin_ia32_pmaddubsw128 (v16qi, v16qi)
- v8hi __builtin_ia32_pmulhrsw128 (v8hi, v8hi)
- v16qi __builtin_ia32_pshufb128 (v16qi, v16qi)
- v16qi __builtin_ia32_psignb128 (v16qi, v16qi)
- v4si __builtin_ia32_psignd128 (v4si, v4si)
- v8hi __builtin_ia32_psignw128 (v8hi, v8hi)
- v2di __builtin_ia32_palignr128 (v2di, v2di, int)
- v16qi __builtin_ia32_pabsb128 (v16qi)
- v4si __builtin_ia32_pabsd128 (v4si)
- v8hi __builtin_ia32_pabsw128 (v8hi)
-
- The following built-in functions are available when `-msse4.1' is
-used. All of them generate the machine instruction that is part of the
-name.
-
- v2df __builtin_ia32_blendpd (v2df, v2df, const int)
- v4sf __builtin_ia32_blendps (v4sf, v4sf, const int)
- v2df __builtin_ia32_blendvpd (v2df, v2df, v2df)
- v4sf __builtin_ia32_blendvps (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_dppd (v2df, v2df, const int)
- v4sf __builtin_ia32_dpps (v4sf, v4sf, const int)
- v4sf __builtin_ia32_insertps128 (v4sf, v4sf, const int)
- v2di __builtin_ia32_movntdqa (v2di *);
- v16qi __builtin_ia32_mpsadbw128 (v16qi, v16qi, const int)
- v8hi __builtin_ia32_packusdw128 (v4si, v4si)
- v16qi __builtin_ia32_pblendvb128 (v16qi, v16qi, v16qi)
- v8hi __builtin_ia32_pblendw128 (v8hi, v8hi, const int)
- v2di __builtin_ia32_pcmpeqq (v2di, v2di)
- v8hi __builtin_ia32_phminposuw128 (v8hi)
- v16qi __builtin_ia32_pmaxsb128 (v16qi, v16qi)
- v4si __builtin_ia32_pmaxsd128 (v4si, v4si)
- v4si __builtin_ia32_pmaxud128 (v4si, v4si)
- v8hi __builtin_ia32_pmaxuw128 (v8hi, v8hi)
- v16qi __builtin_ia32_pminsb128 (v16qi, v16qi)
- v4si __builtin_ia32_pminsd128 (v4si, v4si)
- v4si __builtin_ia32_pminud128 (v4si, v4si)
- v8hi __builtin_ia32_pminuw128 (v8hi, v8hi)
- v4si __builtin_ia32_pmovsxbd128 (v16qi)
- v2di __builtin_ia32_pmovsxbq128 (v16qi)
- v8hi __builtin_ia32_pmovsxbw128 (v16qi)
- v2di __builtin_ia32_pmovsxdq128 (v4si)
- v4si __builtin_ia32_pmovsxwd128 (v8hi)
- v2di __builtin_ia32_pmovsxwq128 (v8hi)
- v4si __builtin_ia32_pmovzxbd128 (v16qi)
- v2di __builtin_ia32_pmovzxbq128 (v16qi)
- v8hi __builtin_ia32_pmovzxbw128 (v16qi)
- v2di __builtin_ia32_pmovzxdq128 (v4si)
- v4si __builtin_ia32_pmovzxwd128 (v8hi)
- v2di __builtin_ia32_pmovzxwq128 (v8hi)
- v2di __builtin_ia32_pmuldq128 (v4si, v4si)
- v4si __builtin_ia32_pmulld128 (v4si, v4si)
- int __builtin_ia32_ptestc128 (v2di, v2di)
- int __builtin_ia32_ptestnzc128 (v2di, v2di)
- int __builtin_ia32_ptestz128 (v2di, v2di)
- v2df __builtin_ia32_roundpd (v2df, const int)
- v4sf __builtin_ia32_roundps (v4sf, const int)
- v2df __builtin_ia32_roundsd (v2df, v2df, const int)
- v4sf __builtin_ia32_roundss (v4sf, v4sf, const int)
-
- The following built-in functions are available when `-msse4.1' is used.
-
-`v4sf __builtin_ia32_vec_set_v4sf (v4sf, float, const int)'
- Generates the `insertps' machine instruction.
-
-`int __builtin_ia32_vec_ext_v16qi (v16qi, const int)'
- Generates the `pextrb' machine instruction.
-
-`v16qi __builtin_ia32_vec_set_v16qi (v16qi, int, const int)'
- Generates the `pinsrb' machine instruction.
-
-`v4si __builtin_ia32_vec_set_v4si (v4si, int, const int)'
- Generates the `pinsrd' machine instruction.
-
-`v2di __builtin_ia32_vec_set_v2di (v2di, long long, const int)'
- Generates the `pinsrq' machine instruction in 64bit mode.
-
- The following built-in functions are changed to generate new SSE4.1
-instructions when `-msse4.1' is used.
-
-`float __builtin_ia32_vec_ext_v4sf (v4sf, const int)'
- Generates the `extractps' machine instruction.
-
-`int __builtin_ia32_vec_ext_v4si (v4si, const int)'
- Generates the `pextrd' machine instruction.
-
-`long long __builtin_ia32_vec_ext_v2di (v2di, const int)'
- Generates the `pextrq' machine instruction in 64bit mode.
-
- The following built-in functions are available when `-msse4.2' is
-used. All of them generate the machine instruction that is part of the
-name.
-
- v16qi __builtin_ia32_pcmpestrm128 (v16qi, int, v16qi, int, const int)
- int __builtin_ia32_pcmpestri128 (v16qi, int, v16qi, int, const int)
- int __builtin_ia32_pcmpestria128 (v16qi, int, v16qi, int, const int)
- int __builtin_ia32_pcmpestric128 (v16qi, int, v16qi, int, const int)
- int __builtin_ia32_pcmpestrio128 (v16qi, int, v16qi, int, const int)
- int __builtin_ia32_pcmpestris128 (v16qi, int, v16qi, int, const int)
- int __builtin_ia32_pcmpestriz128 (v16qi, int, v16qi, int, const int)
- v16qi __builtin_ia32_pcmpistrm128 (v16qi, v16qi, const int)
- int __builtin_ia32_pcmpistri128 (v16qi, v16qi, const int)
- int __builtin_ia32_pcmpistria128 (v16qi, v16qi, const int)
- int __builtin_ia32_pcmpistric128 (v16qi, v16qi, const int)
- int __builtin_ia32_pcmpistrio128 (v16qi, v16qi, const int)
- int __builtin_ia32_pcmpistris128 (v16qi, v16qi, const int)
- int __builtin_ia32_pcmpistriz128 (v16qi, v16qi, const int)
- v2di __builtin_ia32_pcmpgtq (v2di, v2di)
-
- The following built-in functions are available when `-msse4.2' is used.
-
-`unsigned int __builtin_ia32_crc32qi (unsigned int, unsigned char)'
- Generates the `crc32b' machine instruction.
-
-`unsigned int __builtin_ia32_crc32hi (unsigned int, unsigned short)'
- Generates the `crc32w' machine instruction.
-
-`unsigned int __builtin_ia32_crc32si (unsigned int, unsigned int)'
- Generates the `crc32l' machine instruction.
-
-`unsigned long long __builtin_ia32_crc32di (unsigned long long, unsigned long long)'
- Generates the `crc32q' machine instruction.
-
- The following built-in functions are changed to generate new SSE4.2
-instructions when `-msse4.2' is used.
-
-`int __builtin_popcount (unsigned int)'
- Generates the `popcntl' machine instruction.
-
-`int __builtin_popcountl (unsigned long)'
- Generates the `popcntl' or `popcntq' machine instruction,
- depending on the size of `unsigned long'.
-
-`int __builtin_popcountll (unsigned long long)'
- Generates the `popcntq' machine instruction.
-
- The following built-in functions are available when `-mavx' is used.
-All of them generate the machine instruction that is part of the name.
-
- v4df __builtin_ia32_addpd256 (v4df,v4df)
- v8sf __builtin_ia32_addps256 (v8sf,v8sf)
- v4df __builtin_ia32_addsubpd256 (v4df,v4df)
- v8sf __builtin_ia32_addsubps256 (v8sf,v8sf)
- v4df __builtin_ia32_andnpd256 (v4df,v4df)
- v8sf __builtin_ia32_andnps256 (v8sf,v8sf)
- v4df __builtin_ia32_andpd256 (v4df,v4df)
- v8sf __builtin_ia32_andps256 (v8sf,v8sf)
- v4df __builtin_ia32_blendpd256 (v4df,v4df,int)
- v8sf __builtin_ia32_blendps256 (v8sf,v8sf,int)
- v4df __builtin_ia32_blendvpd256 (v4df,v4df,v4df)
- v8sf __builtin_ia32_blendvps256 (v8sf,v8sf,v8sf)
- v2df __builtin_ia32_cmppd (v2df,v2df,int)
- v4df __builtin_ia32_cmppd256 (v4df,v4df,int)
- v4sf __builtin_ia32_cmpps (v4sf,v4sf,int)
- v8sf __builtin_ia32_cmpps256 (v8sf,v8sf,int)
- v2df __builtin_ia32_cmpsd (v2df,v2df,int)
- v4sf __builtin_ia32_cmpss (v4sf,v4sf,int)
- v4df __builtin_ia32_cvtdq2pd256 (v4si)
- v8sf __builtin_ia32_cvtdq2ps256 (v8si)
- v4si __builtin_ia32_cvtpd2dq256 (v4df)
- v4sf __builtin_ia32_cvtpd2ps256 (v4df)
- v8si __builtin_ia32_cvtps2dq256 (v8sf)
- v4df __builtin_ia32_cvtps2pd256 (v4sf)
- v4si __builtin_ia32_cvttpd2dq256 (v4df)
- v8si __builtin_ia32_cvttps2dq256 (v8sf)
- v4df __builtin_ia32_divpd256 (v4df,v4df)
- v8sf __builtin_ia32_divps256 (v8sf,v8sf)
- v8sf __builtin_ia32_dpps256 (v8sf,v8sf,int)
- v4df __builtin_ia32_haddpd256 (v4df,v4df)
- v8sf __builtin_ia32_haddps256 (v8sf,v8sf)
- v4df __builtin_ia32_hsubpd256 (v4df,v4df)
- v8sf __builtin_ia32_hsubps256 (v8sf,v8sf)
- v32qi __builtin_ia32_lddqu256 (pcchar)
- v32qi __builtin_ia32_loaddqu256 (pcchar)
- v4df __builtin_ia32_loadupd256 (pcdouble)
- v8sf __builtin_ia32_loadups256 (pcfloat)
- v2df __builtin_ia32_maskloadpd (pcv2df,v2df)
- v4df __builtin_ia32_maskloadpd256 (pcv4df,v4df)
- v4sf __builtin_ia32_maskloadps (pcv4sf,v4sf)
- v8sf __builtin_ia32_maskloadps256 (pcv8sf,v8sf)
- void __builtin_ia32_maskstorepd (pv2df,v2df,v2df)
- void __builtin_ia32_maskstorepd256 (pv4df,v4df,v4df)
- void __builtin_ia32_maskstoreps (pv4sf,v4sf,v4sf)
- void __builtin_ia32_maskstoreps256 (pv8sf,v8sf,v8sf)
- v4df __builtin_ia32_maxpd256 (v4df,v4df)
- v8sf __builtin_ia32_maxps256 (v8sf,v8sf)
- v4df __builtin_ia32_minpd256 (v4df,v4df)
- v8sf __builtin_ia32_minps256 (v8sf,v8sf)
- v4df __builtin_ia32_movddup256 (v4df)
- int __builtin_ia32_movmskpd256 (v4df)
- int __builtin_ia32_movmskps256 (v8sf)
- v8sf __builtin_ia32_movshdup256 (v8sf)
- v8sf __builtin_ia32_movsldup256 (v8sf)
- v4df __builtin_ia32_mulpd256 (v4df,v4df)
- v8sf __builtin_ia32_mulps256 (v8sf,v8sf)
- v4df __builtin_ia32_orpd256 (v4df,v4df)
- v8sf __builtin_ia32_orps256 (v8sf,v8sf)
- v2df __builtin_ia32_pd_pd256 (v4df)
- v4df __builtin_ia32_pd256_pd (v2df)
- v4sf __builtin_ia32_ps_ps256 (v8sf)
- v8sf __builtin_ia32_ps256_ps (v4sf)
- int __builtin_ia32_ptestc256 (v4di,v4di,ptest)
- int __builtin_ia32_ptestnzc256 (v4di,v4di,ptest)
- int __builtin_ia32_ptestz256 (v4di,v4di,ptest)
- v8sf __builtin_ia32_rcpps256 (v8sf)
- v4df __builtin_ia32_roundpd256 (v4df,int)
- v8sf __builtin_ia32_roundps256 (v8sf,int)
- v8sf __builtin_ia32_rsqrtps_nr256 (v8sf)
- v8sf __builtin_ia32_rsqrtps256 (v8sf)
- v4df __builtin_ia32_shufpd256 (v4df,v4df,int)
- v8sf __builtin_ia32_shufps256 (v8sf,v8sf,int)
- v4si __builtin_ia32_si_si256 (v8si)
- v8si __builtin_ia32_si256_si (v4si)
- v4df __builtin_ia32_sqrtpd256 (v4df)
- v8sf __builtin_ia32_sqrtps_nr256 (v8sf)
- v8sf __builtin_ia32_sqrtps256 (v8sf)
- void __builtin_ia32_storedqu256 (pchar,v32qi)
- void __builtin_ia32_storeupd256 (pdouble,v4df)
- void __builtin_ia32_storeups256 (pfloat,v8sf)
- v4df __builtin_ia32_subpd256 (v4df,v4df)
- v8sf __builtin_ia32_subps256 (v8sf,v8sf)
- v4df __builtin_ia32_unpckhpd256 (v4df,v4df)
- v8sf __builtin_ia32_unpckhps256 (v8sf,v8sf)
- v4df __builtin_ia32_unpcklpd256 (v4df,v4df)
- v8sf __builtin_ia32_unpcklps256 (v8sf,v8sf)
- v4df __builtin_ia32_vbroadcastf128_pd256 (pcv2df)
- v8sf __builtin_ia32_vbroadcastf128_ps256 (pcv4sf)
- v4df __builtin_ia32_vbroadcastsd256 (pcdouble)
- v4sf __builtin_ia32_vbroadcastss (pcfloat)
- v8sf __builtin_ia32_vbroadcastss256 (pcfloat)
- v2df __builtin_ia32_vextractf128_pd256 (v4df,int)
- v4sf __builtin_ia32_vextractf128_ps256 (v8sf,int)
- v4si __builtin_ia32_vextractf128_si256 (v8si,int)
- v4df __builtin_ia32_vinsertf128_pd256 (v4df,v2df,int)
- v8sf __builtin_ia32_vinsertf128_ps256 (v8sf,v4sf,int)
- v8si __builtin_ia32_vinsertf128_si256 (v8si,v4si,int)
- v4df __builtin_ia32_vperm2f128_pd256 (v4df,v4df,int)
- v8sf __builtin_ia32_vperm2f128_ps256 (v8sf,v8sf,int)
- v8si __builtin_ia32_vperm2f128_si256 (v8si,v8si,int)
- v2df __builtin_ia32_vpermil2pd (v2df,v2df,v2di,int)
- v4df __builtin_ia32_vpermil2pd256 (v4df,v4df,v4di,int)
- v4sf __builtin_ia32_vpermil2ps (v4sf,v4sf,v4si,int)
- v8sf __builtin_ia32_vpermil2ps256 (v8sf,v8sf,v8si,int)
- v2df __builtin_ia32_vpermilpd (v2df,int)
- v4df __builtin_ia32_vpermilpd256 (v4df,int)
- v4sf __builtin_ia32_vpermilps (v4sf,int)
- v8sf __builtin_ia32_vpermilps256 (v8sf,int)
- v2df __builtin_ia32_vpermilvarpd (v2df,v2di)
- v4df __builtin_ia32_vpermilvarpd256 (v4df,v4di)
- v4sf __builtin_ia32_vpermilvarps (v4sf,v4si)
- v8sf __builtin_ia32_vpermilvarps256 (v8sf,v8si)
- int __builtin_ia32_vtestcpd (v2df,v2df,ptest)
- int __builtin_ia32_vtestcpd256 (v4df,v4df,ptest)
- int __builtin_ia32_vtestcps (v4sf,v4sf,ptest)
- int __builtin_ia32_vtestcps256 (v8sf,v8sf,ptest)
- int __builtin_ia32_vtestnzcpd (v2df,v2df,ptest)
- int __builtin_ia32_vtestnzcpd256 (v4df,v4df,ptest)
- int __builtin_ia32_vtestnzcps (v4sf,v4sf,ptest)
- int __builtin_ia32_vtestnzcps256 (v8sf,v8sf,ptest)
- int __builtin_ia32_vtestzpd (v2df,v2df,ptest)
- int __builtin_ia32_vtestzpd256 (v4df,v4df,ptest)
- int __builtin_ia32_vtestzps (v4sf,v4sf,ptest)
- int __builtin_ia32_vtestzps256 (v8sf,v8sf,ptest)
- void __builtin_ia32_vzeroall (void)
- void __builtin_ia32_vzeroupper (void)
- v4df __builtin_ia32_xorpd256 (v4df,v4df)
- v8sf __builtin_ia32_xorps256 (v8sf,v8sf)
-
- The following built-in functions are available when `-maes' is used.
-All of them generate the machine instruction that is part of the name.
-
- v2di __builtin_ia32_aesenc128 (v2di, v2di)
- v2di __builtin_ia32_aesenclast128 (v2di, v2di)
- v2di __builtin_ia32_aesdec128 (v2di, v2di)
- v2di __builtin_ia32_aesdeclast128 (v2di, v2di)
- v2di __builtin_ia32_aeskeygenassist128 (v2di, const int)
- v2di __builtin_ia32_aesimc128 (v2di)
-
- The following built-in function is available when `-mpclmul' is used.
-
-`v2di __builtin_ia32_pclmulqdq128 (v2di, v2di, const int)'
- Generates the `pclmulqdq' machine instruction.
-
- The following built-in function is available when `-mfsgsbase' is
-used. All of them generate the machine instruction that is part of the
-name.
-
- unsigned int __builtin_ia32_rdfsbase32 (void)
- unsigned long long __builtin_ia32_rdfsbase64 (void)
- unsigned int __builtin_ia32_rdgsbase32 (void)
- unsigned long long __builtin_ia32_rdgsbase64 (void)
- void _writefsbase_u32 (unsigned int)
- void _writefsbase_u64 (unsigned long long)
- void _writegsbase_u32 (unsigned int)
- void _writegsbase_u64 (unsigned long long)
-
- The following built-in function is available when `-mrdrnd' is used.
-All of them generate the machine instruction that is part of the name.
-
- unsigned int __builtin_ia32_rdrand16_step (unsigned short *)
- unsigned int __builtin_ia32_rdrand32_step (unsigned int *)
- unsigned int __builtin_ia32_rdrand64_step (unsigned long long *)
-
- The following built-in functions are available when `-msse4a' is used.
-All of them generate the machine instruction that is part of the name.
-
- void __builtin_ia32_movntsd (double *, v2df)
- void __builtin_ia32_movntss (float *, v4sf)
- v2di __builtin_ia32_extrq (v2di, v16qi)
- v2di __builtin_ia32_extrqi (v2di, const unsigned int, const unsigned int)
- v2di __builtin_ia32_insertq (v2di, v2di)
- v2di __builtin_ia32_insertqi (v2di, v2di, const unsigned int, const unsigned int)
-
- The following built-in functions are available when `-mxop' is used.
- v2df __builtin_ia32_vfrczpd (v2df)
- v4sf __builtin_ia32_vfrczps (v4sf)
- v2df __builtin_ia32_vfrczsd (v2df, v2df)
- v4sf __builtin_ia32_vfrczss (v4sf, v4sf)
- v4df __builtin_ia32_vfrczpd256 (v4df)
- v8sf __builtin_ia32_vfrczps256 (v8sf)
- v2di __builtin_ia32_vpcmov (v2di, v2di, v2di)
- v2di __builtin_ia32_vpcmov_v2di (v2di, v2di, v2di)
- v4si __builtin_ia32_vpcmov_v4si (v4si, v4si, v4si)
- v8hi __builtin_ia32_vpcmov_v8hi (v8hi, v8hi, v8hi)
- v16qi __builtin_ia32_vpcmov_v16qi (v16qi, v16qi, v16qi)
- v2df __builtin_ia32_vpcmov_v2df (v2df, v2df, v2df)
- v4sf __builtin_ia32_vpcmov_v4sf (v4sf, v4sf, v4sf)
- v4di __builtin_ia32_vpcmov_v4di256 (v4di, v4di, v4di)
- v8si __builtin_ia32_vpcmov_v8si256 (v8si, v8si, v8si)
- v16hi __builtin_ia32_vpcmov_v16hi256 (v16hi, v16hi, v16hi)
- v32qi __builtin_ia32_vpcmov_v32qi256 (v32qi, v32qi, v32qi)
- v4df __builtin_ia32_vpcmov_v4df256 (v4df, v4df, v4df)
- v8sf __builtin_ia32_vpcmov_v8sf256 (v8sf, v8sf, v8sf)
- v16qi __builtin_ia32_vpcomeqb (v16qi, v16qi)
- v8hi __builtin_ia32_vpcomeqw (v8hi, v8hi)
- v4si __builtin_ia32_vpcomeqd (v4si, v4si)
- v2di __builtin_ia32_vpcomeqq (v2di, v2di)
- v16qi __builtin_ia32_vpcomequb (v16qi, v16qi)
- v4si __builtin_ia32_vpcomequd (v4si, v4si)
- v2di __builtin_ia32_vpcomequq (v2di, v2di)
- v8hi __builtin_ia32_vpcomequw (v8hi, v8hi)
- v8hi __builtin_ia32_vpcomeqw (v8hi, v8hi)
- v16qi __builtin_ia32_vpcomfalseb (v16qi, v16qi)
- v4si __builtin_ia32_vpcomfalsed (v4si, v4si)
- v2di __builtin_ia32_vpcomfalseq (v2di, v2di)
- v16qi __builtin_ia32_vpcomfalseub (v16qi, v16qi)
- v4si __builtin_ia32_vpcomfalseud (v4si, v4si)
- v2di __builtin_ia32_vpcomfalseuq (v2di, v2di)
- v8hi __builtin_ia32_vpcomfalseuw (v8hi, v8hi)
- v8hi __builtin_ia32_vpcomfalsew (v8hi, v8hi)
- v16qi __builtin_ia32_vpcomgeb (v16qi, v16qi)
- v4si __builtin_ia32_vpcomged (v4si, v4si)
- v2di __builtin_ia32_vpcomgeq (v2di, v2di)
- v16qi __builtin_ia32_vpcomgeub (v16qi, v16qi)
- v4si __builtin_ia32_vpcomgeud (v4si, v4si)
- v2di __builtin_ia32_vpcomgeuq (v2di, v2di)
- v8hi __builtin_ia32_vpcomgeuw (v8hi, v8hi)
- v8hi __builtin_ia32_vpcomgew (v8hi, v8hi)
- v16qi __builtin_ia32_vpcomgtb (v16qi, v16qi)
- v4si __builtin_ia32_vpcomgtd (v4si, v4si)
- v2di __builtin_ia32_vpcomgtq (v2di, v2di)
- v16qi __builtin_ia32_vpcomgtub (v16qi, v16qi)
- v4si __builtin_ia32_vpcomgtud (v4si, v4si)
- v2di __builtin_ia32_vpcomgtuq (v2di, v2di)
- v8hi __builtin_ia32_vpcomgtuw (v8hi, v8hi)
- v8hi __builtin_ia32_vpcomgtw (v8hi, v8hi)
- v16qi __builtin_ia32_vpcomleb (v16qi, v16qi)
- v4si __builtin_ia32_vpcomled (v4si, v4si)
- v2di __builtin_ia32_vpcomleq (v2di, v2di)
- v16qi __builtin_ia32_vpcomleub (v16qi, v16qi)
- v4si __builtin_ia32_vpcomleud (v4si, v4si)
- v2di __builtin_ia32_vpcomleuq (v2di, v2di)
- v8hi __builtin_ia32_vpcomleuw (v8hi, v8hi)
- v8hi __builtin_ia32_vpcomlew (v8hi, v8hi)
- v16qi __builtin_ia32_vpcomltb (v16qi, v16qi)
- v4si __builtin_ia32_vpcomltd (v4si, v4si)
- v2di __builtin_ia32_vpcomltq (v2di, v2di)
- v16qi __builtin_ia32_vpcomltub (v16qi, v16qi)
- v4si __builtin_ia32_vpcomltud (v4si, v4si)
- v2di __builtin_ia32_vpcomltuq (v2di, v2di)
- v8hi __builtin_ia32_vpcomltuw (v8hi, v8hi)
- v8hi __builtin_ia32_vpcomltw (v8hi, v8hi)
- v16qi __builtin_ia32_vpcomneb (v16qi, v16qi)
- v4si __builtin_ia32_vpcomned (v4si, v4si)
- v2di __builtin_ia32_vpcomneq (v2di, v2di)
- v16qi __builtin_ia32_vpcomneub (v16qi, v16qi)
- v4si __builtin_ia32_vpcomneud (v4si, v4si)
- v2di __builtin_ia32_vpcomneuq (v2di, v2di)
- v8hi __builtin_ia32_vpcomneuw (v8hi, v8hi)
- v8hi __builtin_ia32_vpcomnew (v8hi, v8hi)
- v16qi __builtin_ia32_vpcomtrueb (v16qi, v16qi)
- v4si __builtin_ia32_vpcomtrued (v4si, v4si)
- v2di __builtin_ia32_vpcomtrueq (v2di, v2di)
- v16qi __builtin_ia32_vpcomtrueub (v16qi, v16qi)
- v4si __builtin_ia32_vpcomtrueud (v4si, v4si)
- v2di __builtin_ia32_vpcomtrueuq (v2di, v2di)
- v8hi __builtin_ia32_vpcomtrueuw (v8hi, v8hi)
- v8hi __builtin_ia32_vpcomtruew (v8hi, v8hi)
- v4si __builtin_ia32_vphaddbd (v16qi)
- v2di __builtin_ia32_vphaddbq (v16qi)
- v8hi __builtin_ia32_vphaddbw (v16qi)
- v2di __builtin_ia32_vphadddq (v4si)
- v4si __builtin_ia32_vphaddubd (v16qi)
- v2di __builtin_ia32_vphaddubq (v16qi)
- v8hi __builtin_ia32_vphaddubw (v16qi)
- v2di __builtin_ia32_vphaddudq (v4si)
- v4si __builtin_ia32_vphadduwd (v8hi)
- v2di __builtin_ia32_vphadduwq (v8hi)
- v4si __builtin_ia32_vphaddwd (v8hi)
- v2di __builtin_ia32_vphaddwq (v8hi)
- v8hi __builtin_ia32_vphsubbw (v16qi)
- v2di __builtin_ia32_vphsubdq (v4si)
- v4si __builtin_ia32_vphsubwd (v8hi)
- v4si __builtin_ia32_vpmacsdd (v4si, v4si, v4si)
- v2di __builtin_ia32_vpmacsdqh (v4si, v4si, v2di)
- v2di __builtin_ia32_vpmacsdql (v4si, v4si, v2di)
- v4si __builtin_ia32_vpmacssdd (v4si, v4si, v4si)
- v2di __builtin_ia32_vpmacssdqh (v4si, v4si, v2di)
- v2di __builtin_ia32_vpmacssdql (v4si, v4si, v2di)
- v4si __builtin_ia32_vpmacsswd (v8hi, v8hi, v4si)
- v8hi __builtin_ia32_vpmacssww (v8hi, v8hi, v8hi)
- v4si __builtin_ia32_vpmacswd (v8hi, v8hi, v4si)
- v8hi __builtin_ia32_vpmacsww (v8hi, v8hi, v8hi)
- v4si __builtin_ia32_vpmadcsswd (v8hi, v8hi, v4si)
- v4si __builtin_ia32_vpmadcswd (v8hi, v8hi, v4si)
- v16qi __builtin_ia32_vpperm (v16qi, v16qi, v16qi)
- v16qi __builtin_ia32_vprotb (v16qi, v16qi)
- v4si __builtin_ia32_vprotd (v4si, v4si)
- v2di __builtin_ia32_vprotq (v2di, v2di)
- v8hi __builtin_ia32_vprotw (v8hi, v8hi)
- v16qi __builtin_ia32_vpshab (v16qi, v16qi)
- v4si __builtin_ia32_vpshad (v4si, v4si)
- v2di __builtin_ia32_vpshaq (v2di, v2di)
- v8hi __builtin_ia32_vpshaw (v8hi, v8hi)
- v16qi __builtin_ia32_vpshlb (v16qi, v16qi)
- v4si __builtin_ia32_vpshld (v4si, v4si)
- v2di __builtin_ia32_vpshlq (v2di, v2di)
- v8hi __builtin_ia32_vpshlw (v8hi, v8hi)
-
- The following built-in functions are available when `-mfma4' is used.
-All of them generate the machine instruction that is part of the name
-with MMX registers.
-
- v2df __builtin_ia32_fmaddpd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fmaddps (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fmaddsd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fmaddss (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fmsubpd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fmsubps (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fmsubsd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fmsubss (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fnmaddpd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fnmaddps (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fnmaddsd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fnmaddss (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fnmsubpd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fnmsubps (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fnmsubsd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fnmsubss (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fmaddsubpd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fmaddsubps (v4sf, v4sf, v4sf)
- v2df __builtin_ia32_fmsubaddpd (v2df, v2df, v2df)
- v4sf __builtin_ia32_fmsubaddps (v4sf, v4sf, v4sf)
- v4df __builtin_ia32_fmaddpd256 (v4df, v4df, v4df)
- v8sf __builtin_ia32_fmaddps256 (v8sf, v8sf, v8sf)
- v4df __builtin_ia32_fmsubpd256 (v4df, v4df, v4df)
- v8sf __builtin_ia32_fmsubps256 (v8sf, v8sf, v8sf)
- v4df __builtin_ia32_fnmaddpd256 (v4df, v4df, v4df)
- v8sf __builtin_ia32_fnmaddps256 (v8sf, v8sf, v8sf)
- v4df __builtin_ia32_fnmsubpd256 (v4df, v4df, v4df)
- v8sf __builtin_ia32_fnmsubps256 (v8sf, v8sf, v8sf)
- v4df __builtin_ia32_fmaddsubpd256 (v4df, v4df, v4df)
- v8sf __builtin_ia32_fmaddsubps256 (v8sf, v8sf, v8sf)
- v4df __builtin_ia32_fmsubaddpd256 (v4df, v4df, v4df)
- v8sf __builtin_ia32_fmsubaddps256 (v8sf, v8sf, v8sf)
-
- The following built-in functions are available when `-mlwp' is used.
-
- void __builtin_ia32_llwpcb16 (void *);
- void __builtin_ia32_llwpcb32 (void *);
- void __builtin_ia32_llwpcb64 (void *);
- void * __builtin_ia32_llwpcb16 (void);
- void * __builtin_ia32_llwpcb32 (void);
- void * __builtin_ia32_llwpcb64 (void);
- void __builtin_ia32_lwpval16 (unsigned short, unsigned int, unsigned short)
- void __builtin_ia32_lwpval32 (unsigned int, unsigned int, unsigned int)
- void __builtin_ia32_lwpval64 (unsigned __int64, unsigned int, unsigned int)
- unsigned char __builtin_ia32_lwpins16 (unsigned short, unsigned int, unsigned short)
- unsigned char __builtin_ia32_lwpins32 (unsigned int, unsigned int, unsigned int)
- unsigned char __builtin_ia32_lwpins64 (unsigned __int64, unsigned int, unsigned int)
-
- The following built-in functions are available when `-mbmi' is used.
-All of them generate the machine instruction that is part of the name.
- unsigned int __builtin_ia32_bextr_u32(unsigned int, unsigned int);
- unsigned long long __builtin_ia32_bextr_u64 (unsigned long long, unsigned long long);
- unsigned short __builtin_ia32_lzcnt_16(unsigned short);
- unsigned int __builtin_ia32_lzcnt_u32(unsigned int);
- unsigned long long __builtin_ia32_lzcnt_u64 (unsigned long long);
-
- The following built-in functions are available when `-mtbm' is used.
-Both of them generate the immediate form of the bextr machine
-instruction.
- unsigned int __builtin_ia32_bextri_u32 (unsigned int, const unsigned int);
- unsigned long long __builtin_ia32_bextri_u64 (unsigned long long, const unsigned long long);
-
- The following built-in functions are available when `-m3dnow' is used.
-All of them generate the machine instruction that is part of the name.
-
- void __builtin_ia32_femms (void)
- v8qi __builtin_ia32_pavgusb (v8qi, v8qi)
- v2si __builtin_ia32_pf2id (v2sf)
- v2sf __builtin_ia32_pfacc (v2sf, v2sf)
- v2sf __builtin_ia32_pfadd (v2sf, v2sf)
- v2si __builtin_ia32_pfcmpeq (v2sf, v2sf)
- v2si __builtin_ia32_pfcmpge (v2sf, v2sf)
- v2si __builtin_ia32_pfcmpgt (v2sf, v2sf)
- v2sf __builtin_ia32_pfmax (v2sf, v2sf)
- v2sf __builtin_ia32_pfmin (v2sf, v2sf)
- v2sf __builtin_ia32_pfmul (v2sf, v2sf)
- v2sf __builtin_ia32_pfrcp (v2sf)
- v2sf __builtin_ia32_pfrcpit1 (v2sf, v2sf)
- v2sf __builtin_ia32_pfrcpit2 (v2sf, v2sf)
- v2sf __builtin_ia32_pfrsqrt (v2sf)
- v2sf __builtin_ia32_pfrsqrtit1 (v2sf, v2sf)
- v2sf __builtin_ia32_pfsub (v2sf, v2sf)
- v2sf __builtin_ia32_pfsubr (v2sf, v2sf)
- v2sf __builtin_ia32_pi2fd (v2si)
- v4hi __builtin_ia32_pmulhrw (v4hi, v4hi)
-
- The following built-in functions are available when both `-m3dnow' and
-`-march=athlon' are used. All of them generate the machine instruction
-that is part of the name.
-
- v2si __builtin_ia32_pf2iw (v2sf)
- v2sf __builtin_ia32_pfnacc (v2sf, v2sf)
- v2sf __builtin_ia32_pfpnacc (v2sf, v2sf)
- v2sf __builtin_ia32_pi2fw (v2si)
- v2sf __builtin_ia32_pswapdsf (v2sf)
- v2si __builtin_ia32_pswapdsi (v2si)
-
-
-File: gcc.info, Node: MIPS DSP Built-in Functions, Next: MIPS Paired-Single Support, Prev: X86 Built-in Functions, Up: Target Builtins
-
-6.54.7 MIPS DSP Built-in Functions
-----------------------------------
-
-The MIPS DSP Application-Specific Extension (ASE) includes new
-instructions that are designed to improve the performance of DSP and
-media applications. It provides instructions that operate on packed
-8-bit/16-bit integer data, Q7, Q15 and Q31 fractional data.
-
- GCC supports MIPS DSP operations using both the generic vector
-extensions (*note Vector Extensions::) and a collection of
-MIPS-specific built-in functions. Both kinds of support are enabled by
-the `-mdsp' command-line option.
-
- Revision 2 of the ASE was introduced in the second half of 2006. This
-revision adds extra instructions to the original ASE, but is otherwise
-backwards-compatible with it. You can select revision 2 using the
-command-line option `-mdspr2'; this option implies `-mdsp'.
-
- The SCOUNT and POS bits of the DSP control register are global. The
-WRDSP, EXTPDP, EXTPDPV and MTHLIP instructions modify the SCOUNT and
-POS bits. During optimization, the compiler will not delete these
-instructions and it will not delete calls to functions containing these
-instructions.
-
- At present, GCC only provides support for operations on 32-bit
-vectors. The vector type associated with 8-bit integer data is usually
-called `v4i8', the vector type associated with Q7 is usually called
-`v4q7', the vector type associated with 16-bit integer data is usually
-called `v2i16', and the vector type associated with Q15 is usually
-called `v2q15'. They can be defined in C as follows:
-
- typedef signed char v4i8 __attribute__ ((vector_size(4)));
- typedef signed char v4q7 __attribute__ ((vector_size(4)));
- typedef short v2i16 __attribute__ ((vector_size(4)));
- typedef short v2q15 __attribute__ ((vector_size(4)));
-
- `v4i8', `v4q7', `v2i16' and `v2q15' values are initialized in the same
-way as aggregates. For example:
-
- v4i8 a = {1, 2, 3, 4};
- v4i8 b;
- b = (v4i8) {5, 6, 7, 8};
-
- v2q15 c = {0x0fcb, 0x3a75};
- v2q15 d;
- d = (v2q15) {0.1234 * 0x1.0p15, 0.4567 * 0x1.0p15};
-
- _Note:_ The CPU's endianness determines the order in which values are
-packed. On little-endian targets, the first value is the least
-significant and the last value is the most significant. The opposite
-order applies to big-endian targets. For example, the code above will
-set the lowest byte of `a' to `1' on little-endian targets and `4' on
-big-endian targets.
-
- _Note:_ Q7, Q15 and Q31 values must be initialized with their integer
-representation. As shown in this example, the integer representation
-of a Q7 value can be obtained by multiplying the fractional value by
-`0x1.0p7'. The equivalent for Q15 values is to multiply by `0x1.0p15'.
-The equivalent for Q31 values is to multiply by `0x1.0p31'.
-
- The table below lists the `v4i8' and `v2q15' operations for which
-hardware support exists. `a' and `b' are `v4i8' values, and `c' and
-`d' are `v2q15' values.
-
-C code MIPS instruction
-`a + b' `addu.qb'
-`c + d' `addq.ph'
-`a - b' `subu.qb'
-`c - d' `subq.ph'
-
- The table below lists the `v2i16' operation for which hardware support
-exists for the DSP ASE REV 2. `e' and `f' are `v2i16' values.
-
-C code MIPS instruction
-`e * f' `mul.ph'
-
- It is easier to describe the DSP built-in functions if we first define
-the following types:
-
- typedef int q31;
- typedef int i32;
- typedef unsigned int ui32;
- typedef long long a64;
-
- `q31' and `i32' are actually the same as `int', but we use `q31' to
-indicate a Q31 fractional value and `i32' to indicate a 32-bit integer
-value. Similarly, `a64' is the same as `long long', but we use `a64'
-to indicate values that will be placed in one of the four DSP
-accumulators (`$ac0', `$ac1', `$ac2' or `$ac3').
-
- Also, some built-in functions prefer or require immediate numbers as
-parameters, because the corresponding DSP instructions accept both
-immediate numbers and register operands, or accept immediate numbers
-only. The immediate parameters are listed as follows.
-
- imm0_3: 0 to 3.
- imm0_7: 0 to 7.
- imm0_15: 0 to 15.
- imm0_31: 0 to 31.
- imm0_63: 0 to 63.
- imm0_255: 0 to 255.
- imm_n32_31: -32 to 31.
- imm_n512_511: -512 to 511.
-
- The following built-in functions map directly to a particular MIPS DSP
-instruction. Please refer to the architecture specification for
-details on what each instruction does.
-
- v2q15 __builtin_mips_addq_ph (v2q15, v2q15)
- v2q15 __builtin_mips_addq_s_ph (v2q15, v2q15)
- q31 __builtin_mips_addq_s_w (q31, q31)
- v4i8 __builtin_mips_addu_qb (v4i8, v4i8)
- v4i8 __builtin_mips_addu_s_qb (v4i8, v4i8)
- v2q15 __builtin_mips_subq_ph (v2q15, v2q15)
- v2q15 __builtin_mips_subq_s_ph (v2q15, v2q15)
- q31 __builtin_mips_subq_s_w (q31, q31)
- v4i8 __builtin_mips_subu_qb (v4i8, v4i8)
- v4i8 __builtin_mips_subu_s_qb (v4i8, v4i8)
- i32 __builtin_mips_addsc (i32, i32)
- i32 __builtin_mips_addwc (i32, i32)
- i32 __builtin_mips_modsub (i32, i32)
- i32 __builtin_mips_raddu_w_qb (v4i8)
- v2q15 __builtin_mips_absq_s_ph (v2q15)
- q31 __builtin_mips_absq_s_w (q31)
- v4i8 __builtin_mips_precrq_qb_ph (v2q15, v2q15)
- v2q15 __builtin_mips_precrq_ph_w (q31, q31)
- v2q15 __builtin_mips_precrq_rs_ph_w (q31, q31)
- v4i8 __builtin_mips_precrqu_s_qb_ph (v2q15, v2q15)
- q31 __builtin_mips_preceq_w_phl (v2q15)
- q31 __builtin_mips_preceq_w_phr (v2q15)
- v2q15 __builtin_mips_precequ_ph_qbl (v4i8)
- v2q15 __builtin_mips_precequ_ph_qbr (v4i8)
- v2q15 __builtin_mips_precequ_ph_qbla (v4i8)
- v2q15 __builtin_mips_precequ_ph_qbra (v4i8)
- v2q15 __builtin_mips_preceu_ph_qbl (v4i8)
- v2q15 __builtin_mips_preceu_ph_qbr (v4i8)
- v2q15 __builtin_mips_preceu_ph_qbla (v4i8)
- v2q15 __builtin_mips_preceu_ph_qbra (v4i8)
- v4i8 __builtin_mips_shll_qb (v4i8, imm0_7)
- v4i8 __builtin_mips_shll_qb (v4i8, i32)
- v2q15 __builtin_mips_shll_ph (v2q15, imm0_15)
- v2q15 __builtin_mips_shll_ph (v2q15, i32)
- v2q15 __builtin_mips_shll_s_ph (v2q15, imm0_15)
- v2q15 __builtin_mips_shll_s_ph (v2q15, i32)
- q31 __builtin_mips_shll_s_w (q31, imm0_31)
- q31 __builtin_mips_shll_s_w (q31, i32)
- v4i8 __builtin_mips_shrl_qb (v4i8, imm0_7)
- v4i8 __builtin_mips_shrl_qb (v4i8, i32)
- v2q15 __builtin_mips_shra_ph (v2q15, imm0_15)
- v2q15 __builtin_mips_shra_ph (v2q15, i32)
- v2q15 __builtin_mips_shra_r_ph (v2q15, imm0_15)
- v2q15 __builtin_mips_shra_r_ph (v2q15, i32)
- q31 __builtin_mips_shra_r_w (q31, imm0_31)
- q31 __builtin_mips_shra_r_w (q31, i32)
- v2q15 __builtin_mips_muleu_s_ph_qbl (v4i8, v2q15)
- v2q15 __builtin_mips_muleu_s_ph_qbr (v4i8, v2q15)
- v2q15 __builtin_mips_mulq_rs_ph (v2q15, v2q15)
- q31 __builtin_mips_muleq_s_w_phl (v2q15, v2q15)
- q31 __builtin_mips_muleq_s_w_phr (v2q15, v2q15)
- a64 __builtin_mips_dpau_h_qbl (a64, v4i8, v4i8)
- a64 __builtin_mips_dpau_h_qbr (a64, v4i8, v4i8)
- a64 __builtin_mips_dpsu_h_qbl (a64, v4i8, v4i8)
- a64 __builtin_mips_dpsu_h_qbr (a64, v4i8, v4i8)
- a64 __builtin_mips_dpaq_s_w_ph (a64, v2q15, v2q15)
- a64 __builtin_mips_dpaq_sa_l_w (a64, q31, q31)
- a64 __builtin_mips_dpsq_s_w_ph (a64, v2q15, v2q15)
- a64 __builtin_mips_dpsq_sa_l_w (a64, q31, q31)
- a64 __builtin_mips_mulsaq_s_w_ph (a64, v2q15, v2q15)
- a64 __builtin_mips_maq_s_w_phl (a64, v2q15, v2q15)
- a64 __builtin_mips_maq_s_w_phr (a64, v2q15, v2q15)
- a64 __builtin_mips_maq_sa_w_phl (a64, v2q15, v2q15)
- a64 __builtin_mips_maq_sa_w_phr (a64, v2q15, v2q15)
- i32 __builtin_mips_bitrev (i32)
- i32 __builtin_mips_insv (i32, i32)
- v4i8 __builtin_mips_repl_qb (imm0_255)
- v4i8 __builtin_mips_repl_qb (i32)
- v2q15 __builtin_mips_repl_ph (imm_n512_511)
- v2q15 __builtin_mips_repl_ph (i32)
- void __builtin_mips_cmpu_eq_qb (v4i8, v4i8)
- void __builtin_mips_cmpu_lt_qb (v4i8, v4i8)
- void __builtin_mips_cmpu_le_qb (v4i8, v4i8)
- i32 __builtin_mips_cmpgu_eq_qb (v4i8, v4i8)
- i32 __builtin_mips_cmpgu_lt_qb (v4i8, v4i8)
- i32 __builtin_mips_cmpgu_le_qb (v4i8, v4i8)
- void __builtin_mips_cmp_eq_ph (v2q15, v2q15)
- void __builtin_mips_cmp_lt_ph (v2q15, v2q15)
- void __builtin_mips_cmp_le_ph (v2q15, v2q15)
- v4i8 __builtin_mips_pick_qb (v4i8, v4i8)
- v2q15 __builtin_mips_pick_ph (v2q15, v2q15)
- v2q15 __builtin_mips_packrl_ph (v2q15, v2q15)
- i32 __builtin_mips_extr_w (a64, imm0_31)
- i32 __builtin_mips_extr_w (a64, i32)
- i32 __builtin_mips_extr_r_w (a64, imm0_31)
- i32 __builtin_mips_extr_s_h (a64, i32)
- i32 __builtin_mips_extr_rs_w (a64, imm0_31)
- i32 __builtin_mips_extr_rs_w (a64, i32)
- i32 __builtin_mips_extr_s_h (a64, imm0_31)
- i32 __builtin_mips_extr_r_w (a64, i32)
- i32 __builtin_mips_extp (a64, imm0_31)
- i32 __builtin_mips_extp (a64, i32)
- i32 __builtin_mips_extpdp (a64, imm0_31)
- i32 __builtin_mips_extpdp (a64, i32)
- a64 __builtin_mips_shilo (a64, imm_n32_31)
- a64 __builtin_mips_shilo (a64, i32)
- a64 __builtin_mips_mthlip (a64, i32)
- void __builtin_mips_wrdsp (i32, imm0_63)
- i32 __builtin_mips_rddsp (imm0_63)
- i32 __builtin_mips_lbux (void *, i32)
- i32 __builtin_mips_lhx (void *, i32)
- i32 __builtin_mips_lwx (void *, i32)
- i32 __builtin_mips_bposge32 (void)
- a64 __builtin_mips_madd (a64, i32, i32);
- a64 __builtin_mips_maddu (a64, ui32, ui32);
- a64 __builtin_mips_msub (a64, i32, i32);
- a64 __builtin_mips_msubu (a64, ui32, ui32);
- a64 __builtin_mips_mult (i32, i32);
- a64 __builtin_mips_multu (ui32, ui32);
-
- The following built-in functions map directly to a particular MIPS DSP
-REV 2 instruction. Please refer to the architecture specification for
-details on what each instruction does.
-
- v4q7 __builtin_mips_absq_s_qb (v4q7);
- v2i16 __builtin_mips_addu_ph (v2i16, v2i16);
- v2i16 __builtin_mips_addu_s_ph (v2i16, v2i16);
- v4i8 __builtin_mips_adduh_qb (v4i8, v4i8);
- v4i8 __builtin_mips_adduh_r_qb (v4i8, v4i8);
- i32 __builtin_mips_append (i32, i32, imm0_31);
- i32 __builtin_mips_balign (i32, i32, imm0_3);
- i32 __builtin_mips_cmpgdu_eq_qb (v4i8, v4i8);
- i32 __builtin_mips_cmpgdu_lt_qb (v4i8, v4i8);
- i32 __builtin_mips_cmpgdu_le_qb (v4i8, v4i8);
- a64 __builtin_mips_dpa_w_ph (a64, v2i16, v2i16);
- a64 __builtin_mips_dps_w_ph (a64, v2i16, v2i16);
- v2i16 __builtin_mips_mul_ph (v2i16, v2i16);
- v2i16 __builtin_mips_mul_s_ph (v2i16, v2i16);
- q31 __builtin_mips_mulq_rs_w (q31, q31);
- v2q15 __builtin_mips_mulq_s_ph (v2q15, v2q15);
- q31 __builtin_mips_mulq_s_w (q31, q31);
- a64 __builtin_mips_mulsa_w_ph (a64, v2i16, v2i16);
- v4i8 __builtin_mips_precr_qb_ph (v2i16, v2i16);
- v2i16 __builtin_mips_precr_sra_ph_w (i32, i32, imm0_31);
- v2i16 __builtin_mips_precr_sra_r_ph_w (i32, i32, imm0_31);
- i32 __builtin_mips_prepend (i32, i32, imm0_31);
- v4i8 __builtin_mips_shra_qb (v4i8, imm0_7);
- v4i8 __builtin_mips_shra_r_qb (v4i8, imm0_7);
- v4i8 __builtin_mips_shra_qb (v4i8, i32);
- v4i8 __builtin_mips_shra_r_qb (v4i8, i32);
- v2i16 __builtin_mips_shrl_ph (v2i16, imm0_15);
- v2i16 __builtin_mips_shrl_ph (v2i16, i32);
- v2i16 __builtin_mips_subu_ph (v2i16, v2i16);
- v2i16 __builtin_mips_subu_s_ph (v2i16, v2i16);
- v4i8 __builtin_mips_subuh_qb (v4i8, v4i8);
- v4i8 __builtin_mips_subuh_r_qb (v4i8, v4i8);
- v2q15 __builtin_mips_addqh_ph (v2q15, v2q15);
- v2q15 __builtin_mips_addqh_r_ph (v2q15, v2q15);
- q31 __builtin_mips_addqh_w (q31, q31);
- q31 __builtin_mips_addqh_r_w (q31, q31);
- v2q15 __builtin_mips_subqh_ph (v2q15, v2q15);
- v2q15 __builtin_mips_subqh_r_ph (v2q15, v2q15);
- q31 __builtin_mips_subqh_w (q31, q31);
- q31 __builtin_mips_subqh_r_w (q31, q31);
- a64 __builtin_mips_dpax_w_ph (a64, v2i16, v2i16);
- a64 __builtin_mips_dpsx_w_ph (a64, v2i16, v2i16);
- a64 __builtin_mips_dpaqx_s_w_ph (a64, v2q15, v2q15);
- a64 __builtin_mips_dpaqx_sa_w_ph (a64, v2q15, v2q15);
- a64 __builtin_mips_dpsqx_s_w_ph (a64, v2q15, v2q15);
- a64 __builtin_mips_dpsqx_sa_w_ph (a64, v2q15, v2q15);
-
-
-File: gcc.info, Node: MIPS Paired-Single Support, Next: MIPS Loongson Built-in Functions, Prev: MIPS DSP Built-in Functions, Up: Target Builtins
-
-6.54.8 MIPS Paired-Single Support
----------------------------------
-
-The MIPS64 architecture includes a number of instructions that operate
-on pairs of single-precision floating-point values. Each pair is
-packed into a 64-bit floating-point register, with one element being
-designated the "upper half" and the other being designated the "lower
-half".
-
- GCC supports paired-single operations using both the generic vector
-extensions (*note Vector Extensions::) and a collection of
-MIPS-specific built-in functions. Both kinds of support are enabled by
-the `-mpaired-single' command-line option.
-
- The vector type associated with paired-single values is usually called
-`v2sf'. It can be defined in C as follows:
-
- typedef float v2sf __attribute__ ((vector_size (8)));
-
- `v2sf' values are initialized in the same way as aggregates. For
-example:
-
- v2sf a = {1.5, 9.1};
- v2sf b;
- float e, f;
- b = (v2sf) {e, f};
-
- _Note:_ The CPU's endianness determines which value is stored in the
-upper half of a register and which value is stored in the lower half.
-On little-endian targets, the first value is the lower one and the
-second value is the upper one. The opposite order applies to
-big-endian targets. For example, the code above will set the lower
-half of `a' to `1.5' on little-endian targets and `9.1' on big-endian
-targets.
-
-
-File: gcc.info, Node: MIPS Loongson Built-in Functions, Next: Other MIPS Built-in Functions, Prev: MIPS Paired-Single Support, Up: Target Builtins
-
-6.54.9 MIPS Loongson Built-in Functions
----------------------------------------
-
-GCC provides intrinsics to access the SIMD instructions provided by the
-ST Microelectronics Loongson-2E and -2F processors. These intrinsics,
-available after inclusion of the `loongson.h' header file, operate on
-the following 64-bit vector types:
-
- * `uint8x8_t', a vector of eight unsigned 8-bit integers;
-
- * `uint16x4_t', a vector of four unsigned 16-bit integers;
-
- * `uint32x2_t', a vector of two unsigned 32-bit integers;
-
- * `int8x8_t', a vector of eight signed 8-bit integers;
-
- * `int16x4_t', a vector of four signed 16-bit integers;
-
- * `int32x2_t', a vector of two signed 32-bit integers.
-
- The intrinsics provided are listed below; each is named after the
-machine instruction to which it corresponds, with suffixes added as
-appropriate to distinguish intrinsics that expand to the same machine
-instruction yet have different argument types. Refer to the
-architecture documentation for a description of the functionality of
-each instruction.
-
- int16x4_t packsswh (int32x2_t s, int32x2_t t);
- int8x8_t packsshb (int16x4_t s, int16x4_t t);
- uint8x8_t packushb (uint16x4_t s, uint16x4_t t);
- uint32x2_t paddw_u (uint32x2_t s, uint32x2_t t);
- uint16x4_t paddh_u (uint16x4_t s, uint16x4_t t);
- uint8x8_t paddb_u (uint8x8_t s, uint8x8_t t);
- int32x2_t paddw_s (int32x2_t s, int32x2_t t);
- int16x4_t paddh_s (int16x4_t s, int16x4_t t);
- int8x8_t paddb_s (int8x8_t s, int8x8_t t);
- uint64_t paddd_u (uint64_t s, uint64_t t);
- int64_t paddd_s (int64_t s, int64_t t);
- int16x4_t paddsh (int16x4_t s, int16x4_t t);
- int8x8_t paddsb (int8x8_t s, int8x8_t t);
- uint16x4_t paddush (uint16x4_t s, uint16x4_t t);
- uint8x8_t paddusb (uint8x8_t s, uint8x8_t t);
- uint64_t pandn_ud (uint64_t s, uint64_t t);
- uint32x2_t pandn_uw (uint32x2_t s, uint32x2_t t);
- uint16x4_t pandn_uh (uint16x4_t s, uint16x4_t t);
- uint8x8_t pandn_ub (uint8x8_t s, uint8x8_t t);
- int64_t pandn_sd (int64_t s, int64_t t);
- int32x2_t pandn_sw (int32x2_t s, int32x2_t t);
- int16x4_t pandn_sh (int16x4_t s, int16x4_t t);
- int8x8_t pandn_sb (int8x8_t s, int8x8_t t);
- uint16x4_t pavgh (uint16x4_t s, uint16x4_t t);
- uint8x8_t pavgb (uint8x8_t s, uint8x8_t t);
- uint32x2_t pcmpeqw_u (uint32x2_t s, uint32x2_t t);
- uint16x4_t pcmpeqh_u (uint16x4_t s, uint16x4_t t);
- uint8x8_t pcmpeqb_u (uint8x8_t s, uint8x8_t t);
- int32x2_t pcmpeqw_s (int32x2_t s, int32x2_t t);
- int16x4_t pcmpeqh_s (int16x4_t s, int16x4_t t);
- int8x8_t pcmpeqb_s (int8x8_t s, int8x8_t t);
- uint32x2_t pcmpgtw_u (uint32x2_t s, uint32x2_t t);
- uint16x4_t pcmpgth_u (uint16x4_t s, uint16x4_t t);
- uint8x8_t pcmpgtb_u (uint8x8_t s, uint8x8_t t);
- int32x2_t pcmpgtw_s (int32x2_t s, int32x2_t t);
- int16x4_t pcmpgth_s (int16x4_t s, int16x4_t t);
- int8x8_t pcmpgtb_s (int8x8_t s, int8x8_t t);
- uint16x4_t pextrh_u (uint16x4_t s, int field);
- int16x4_t pextrh_s (int16x4_t s, int field);
- uint16x4_t pinsrh_0_u (uint16x4_t s, uint16x4_t t);
- uint16x4_t pinsrh_1_u (uint16x4_t s, uint16x4_t t);
- uint16x4_t pinsrh_2_u (uint16x4_t s, uint16x4_t t);
- uint16x4_t pinsrh_3_u (uint16x4_t s, uint16x4_t t);
- int16x4_t pinsrh_0_s (int16x4_t s, int16x4_t t);
- int16x4_t pinsrh_1_s (int16x4_t s, int16x4_t t);
- int16x4_t pinsrh_2_s (int16x4_t s, int16x4_t t);
- int16x4_t pinsrh_3_s (int16x4_t s, int16x4_t t);
- int32x2_t pmaddhw (int16x4_t s, int16x4_t t);
- int16x4_t pmaxsh (int16x4_t s, int16x4_t t);
- uint8x8_t pmaxub (uint8x8_t s, uint8x8_t t);
- int16x4_t pminsh (int16x4_t s, int16x4_t t);
- uint8x8_t pminub (uint8x8_t s, uint8x8_t t);
- uint8x8_t pmovmskb_u (uint8x8_t s);
- int8x8_t pmovmskb_s (int8x8_t s);
- uint16x4_t pmulhuh (uint16x4_t s, uint16x4_t t);
- int16x4_t pmulhh (int16x4_t s, int16x4_t t);
- int16x4_t pmullh (int16x4_t s, int16x4_t t);
- int64_t pmuluw (uint32x2_t s, uint32x2_t t);
- uint8x8_t pasubub (uint8x8_t s, uint8x8_t t);
- uint16x4_t biadd (uint8x8_t s);
- uint16x4_t psadbh (uint8x8_t s, uint8x8_t t);
- uint16x4_t pshufh_u (uint16x4_t dest, uint16x4_t s, uint8_t order);
- int16x4_t pshufh_s (int16x4_t dest, int16x4_t s, uint8_t order);
- uint16x4_t psllh_u (uint16x4_t s, uint8_t amount);
- int16x4_t psllh_s (int16x4_t s, uint8_t amount);
- uint32x2_t psllw_u (uint32x2_t s, uint8_t amount);
- int32x2_t psllw_s (int32x2_t s, uint8_t amount);
- uint16x4_t psrlh_u (uint16x4_t s, uint8_t amount);
- int16x4_t psrlh_s (int16x4_t s, uint8_t amount);
- uint32x2_t psrlw_u (uint32x2_t s, uint8_t amount);
- int32x2_t psrlw_s (int32x2_t s, uint8_t amount);
- uint16x4_t psrah_u (uint16x4_t s, uint8_t amount);
- int16x4_t psrah_s (int16x4_t s, uint8_t amount);
- uint32x2_t psraw_u (uint32x2_t s, uint8_t amount);
- int32x2_t psraw_s (int32x2_t s, uint8_t amount);
- uint32x2_t psubw_u (uint32x2_t s, uint32x2_t t);
- uint16x4_t psubh_u (uint16x4_t s, uint16x4_t t);
- uint8x8_t psubb_u (uint8x8_t s, uint8x8_t t);
- int32x2_t psubw_s (int32x2_t s, int32x2_t t);
- int16x4_t psubh_s (int16x4_t s, int16x4_t t);
- int8x8_t psubb_s (int8x8_t s, int8x8_t t);
- uint64_t psubd_u (uint64_t s, uint64_t t);
- int64_t psubd_s (int64_t s, int64_t t);
- int16x4_t psubsh (int16x4_t s, int16x4_t t);
- int8x8_t psubsb (int8x8_t s, int8x8_t t);
- uint16x4_t psubush (uint16x4_t s, uint16x4_t t);
- uint8x8_t psubusb (uint8x8_t s, uint8x8_t t);
- uint32x2_t punpckhwd_u (uint32x2_t s, uint32x2_t t);
- uint16x4_t punpckhhw_u (uint16x4_t s, uint16x4_t t);
- uint8x8_t punpckhbh_u (uint8x8_t s, uint8x8_t t);
- int32x2_t punpckhwd_s (int32x2_t s, int32x2_t t);
- int16x4_t punpckhhw_s (int16x4_t s, int16x4_t t);
- int8x8_t punpckhbh_s (int8x8_t s, int8x8_t t);
- uint32x2_t punpcklwd_u (uint32x2_t s, uint32x2_t t);
- uint16x4_t punpcklhw_u (uint16x4_t s, uint16x4_t t);
- uint8x8_t punpcklbh_u (uint8x8_t s, uint8x8_t t);
- int32x2_t punpcklwd_s (int32x2_t s, int32x2_t t);
- int16x4_t punpcklhw_s (int16x4_t s, int16x4_t t);
- int8x8_t punpcklbh_s (int8x8_t s, int8x8_t t);
-
-* Menu:
-
-* Paired-Single Arithmetic::
-* Paired-Single Built-in Functions::
-* MIPS-3D Built-in Functions::
-
-
-File: gcc.info, Node: Paired-Single Arithmetic, Next: Paired-Single Built-in Functions, Up: MIPS Loongson Built-in Functions
-
-6.54.9.1 Paired-Single Arithmetic
-.................................
-
-The table below lists the `v2sf' operations for which hardware support
-exists. `a', `b' and `c' are `v2sf' values and `x' is an integral
-value.
-
-C code MIPS instruction
-`a + b' `add.ps'
-`a - b' `sub.ps'
-`-a' `neg.ps'
-`a * b' `mul.ps'
-`a * b + c' `madd.ps'
-`a * b - c' `msub.ps'
-`-(a * b + c)' `nmadd.ps'
-`-(a * b - c)' `nmsub.ps'
-`x ? a : b' `movn.ps'/`movz.ps'
-
- Note that the multiply-accumulate instructions can be disabled using
-the command-line option `-mno-fused-madd'.
-
-
-File: gcc.info, Node: Paired-Single Built-in Functions, Next: MIPS-3D Built-in Functions, Prev: Paired-Single Arithmetic, Up: MIPS Loongson Built-in Functions
-
-6.54.9.2 Paired-Single Built-in Functions
-.........................................
-
-The following paired-single functions map directly to a particular MIPS
-instruction. Please refer to the architecture specification for
-details on what each instruction does.
-
-`v2sf __builtin_mips_pll_ps (v2sf, v2sf)'
- Pair lower lower (`pll.ps').
-
-`v2sf __builtin_mips_pul_ps (v2sf, v2sf)'
- Pair upper lower (`pul.ps').
-
-`v2sf __builtin_mips_plu_ps (v2sf, v2sf)'
- Pair lower upper (`plu.ps').
-
-`v2sf __builtin_mips_puu_ps (v2sf, v2sf)'
- Pair upper upper (`puu.ps').
-
-`v2sf __builtin_mips_cvt_ps_s (float, float)'
- Convert pair to paired single (`cvt.ps.s').
-
-`float __builtin_mips_cvt_s_pl (v2sf)'
- Convert pair lower to single (`cvt.s.pl').
-
-`float __builtin_mips_cvt_s_pu (v2sf)'
- Convert pair upper to single (`cvt.s.pu').
-
-`v2sf __builtin_mips_abs_ps (v2sf)'
- Absolute value (`abs.ps').
-
-`v2sf __builtin_mips_alnv_ps (v2sf, v2sf, int)'
- Align variable (`alnv.ps').
-
- _Note:_ The value of the third parameter must be 0 or 4 modulo 8,
- otherwise the result will be unpredictable. Please read the
- instruction description for details.
-
- The following multi-instruction functions are also available. In each
-case, COND can be any of the 16 floating-point conditions: `f', `un',
-`eq', `ueq', `olt', `ult', `ole', `ule', `sf', `ngle', `seq', `ngl',
-`lt', `nge', `le' or `ngt'.
-
-`v2sf __builtin_mips_movt_c_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)'
-`v2sf __builtin_mips_movf_c_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)'
- Conditional move based on floating point comparison (`c.COND.ps',
- `movt.ps'/`movf.ps').
-
- The `movt' functions return the value X computed by:
-
- c.COND.ps CC,A,B
- mov.ps X,C
- movt.ps X,D,CC
-
- The `movf' functions are similar but use `movf.ps' instead of
- `movt.ps'.
-
-`int __builtin_mips_upper_c_COND_ps (v2sf A, v2sf B)'
-`int __builtin_mips_lower_c_COND_ps (v2sf A, v2sf B)'
- Comparison of two paired-single values (`c.COND.ps',
- `bc1t'/`bc1f').
-
- These functions compare A and B using `c.COND.ps' and return
- either the upper or lower half of the result. For example:
-
- v2sf a, b;
- if (__builtin_mips_upper_c_eq_ps (a, b))
- upper_halves_are_equal ();
- else
- upper_halves_are_unequal ();
-
- if (__builtin_mips_lower_c_eq_ps (a, b))
- lower_halves_are_equal ();
- else
- lower_halves_are_unequal ();
-
-
-File: gcc.info, Node: MIPS-3D Built-in Functions, Prev: Paired-Single Built-in Functions, Up: MIPS Loongson Built-in Functions
-
-6.54.9.3 MIPS-3D Built-in Functions
-...................................
-
-The MIPS-3D Application-Specific Extension (ASE) includes additional
-paired-single instructions that are designed to improve the performance
-of 3D graphics operations. Support for these instructions is controlled
-by the `-mips3d' command-line option.
-
- The functions listed below map directly to a particular MIPS-3D
-instruction. Please refer to the architecture specification for more
-details on what each instruction does.
-
-`v2sf __builtin_mips_addr_ps (v2sf, v2sf)'
- Reduction add (`addr.ps').
-
-`v2sf __builtin_mips_mulr_ps (v2sf, v2sf)'
- Reduction multiply (`mulr.ps').
-
-`v2sf __builtin_mips_cvt_pw_ps (v2sf)'
- Convert paired single to paired word (`cvt.pw.ps').
-
-`v2sf __builtin_mips_cvt_ps_pw (v2sf)'
- Convert paired word to paired single (`cvt.ps.pw').
-
-`float __builtin_mips_recip1_s (float)'
-`double __builtin_mips_recip1_d (double)'
-`v2sf __builtin_mips_recip1_ps (v2sf)'
- Reduced precision reciprocal (sequence step 1) (`recip1.FMT').
-
-`float __builtin_mips_recip2_s (float, float)'
-`double __builtin_mips_recip2_d (double, double)'
-`v2sf __builtin_mips_recip2_ps (v2sf, v2sf)'
- Reduced precision reciprocal (sequence step 2) (`recip2.FMT').
-
-`float __builtin_mips_rsqrt1_s (float)'
-`double __builtin_mips_rsqrt1_d (double)'
-`v2sf __builtin_mips_rsqrt1_ps (v2sf)'
- Reduced precision reciprocal square root (sequence step 1)
- (`rsqrt1.FMT').
-
-`float __builtin_mips_rsqrt2_s (float, float)'
-`double __builtin_mips_rsqrt2_d (double, double)'
-`v2sf __builtin_mips_rsqrt2_ps (v2sf, v2sf)'
- Reduced precision reciprocal square root (sequence step 2)
- (`rsqrt2.FMT').
-
- The following multi-instruction functions are also available. In each
-case, COND can be any of the 16 floating-point conditions: `f', `un',
-`eq', `ueq', `olt', `ult', `ole', `ule', `sf', `ngle', `seq', `ngl',
-`lt', `nge', `le' or `ngt'.
-
-`int __builtin_mips_cabs_COND_s (float A, float B)'
-`int __builtin_mips_cabs_COND_d (double A, double B)'
- Absolute comparison of two scalar values (`cabs.COND.FMT',
- `bc1t'/`bc1f').
-
- These functions compare A and B using `cabs.COND.s' or
- `cabs.COND.d' and return the result as a boolean value. For
- example:
-
- float a, b;
- if (__builtin_mips_cabs_eq_s (a, b))
- true ();
- else
- false ();
-
-`int __builtin_mips_upper_cabs_COND_ps (v2sf A, v2sf B)'
-`int __builtin_mips_lower_cabs_COND_ps (v2sf A, v2sf B)'
- Absolute comparison of two paired-single values (`cabs.COND.ps',
- `bc1t'/`bc1f').
-
- These functions compare A and B using `cabs.COND.ps' and return
- either the upper or lower half of the result. For example:
-
- v2sf a, b;
- if (__builtin_mips_upper_cabs_eq_ps (a, b))
- upper_halves_are_equal ();
- else
- upper_halves_are_unequal ();
-
- if (__builtin_mips_lower_cabs_eq_ps (a, b))
- lower_halves_are_equal ();
- else
- lower_halves_are_unequal ();
-
-`v2sf __builtin_mips_movt_cabs_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)'
-`v2sf __builtin_mips_movf_cabs_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)'
- Conditional move based on absolute comparison (`cabs.COND.ps',
- `movt.ps'/`movf.ps').
-
- The `movt' functions return the value X computed by:
-
- cabs.COND.ps CC,A,B
- mov.ps X,C
- movt.ps X,D,CC
-
- The `movf' functions are similar but use `movf.ps' instead of
- `movt.ps'.
-
-`int __builtin_mips_any_c_COND_ps (v2sf A, v2sf B)'
-`int __builtin_mips_all_c_COND_ps (v2sf A, v2sf B)'
-`int __builtin_mips_any_cabs_COND_ps (v2sf A, v2sf B)'
-`int __builtin_mips_all_cabs_COND_ps (v2sf A, v2sf B)'
- Comparison of two paired-single values (`c.COND.ps'/`cabs.COND.ps',
- `bc1any2t'/`bc1any2f').
-
- These functions compare A and B using `c.COND.ps' or
- `cabs.COND.ps'. The `any' forms return true if either result is
- true and the `all' forms return true if both results are true.
- For example:
-
- v2sf a, b;
- if (__builtin_mips_any_c_eq_ps (a, b))
- one_is_true ();
- else
- both_are_false ();
-
- if (__builtin_mips_all_c_eq_ps (a, b))
- both_are_true ();
- else
- one_is_false ();
-
-`int __builtin_mips_any_c_COND_4s (v2sf A, v2sf B, v2sf C, v2sf D)'
-`int __builtin_mips_all_c_COND_4s (v2sf A, v2sf B, v2sf C, v2sf D)'
-`int __builtin_mips_any_cabs_COND_4s (v2sf A, v2sf B, v2sf C, v2sf D)'
-`int __builtin_mips_all_cabs_COND_4s (v2sf A, v2sf B, v2sf C, v2sf D)'
- Comparison of four paired-single values
- (`c.COND.ps'/`cabs.COND.ps', `bc1any4t'/`bc1any4f').
-
- These functions use `c.COND.ps' or `cabs.COND.ps' to compare A
- with B and to compare C with D. The `any' forms return true if
- any of the four results are true and the `all' forms return true
- if all four results are true. For example:
-
- v2sf a, b, c, d;
- if (__builtin_mips_any_c_eq_4s (a, b, c, d))
- some_are_true ();
- else
- all_are_false ();
-
- if (__builtin_mips_all_c_eq_4s (a, b, c, d))
- all_are_true ();
- else
- some_are_false ();
-
-
-File: gcc.info, Node: picoChip Built-in Functions, Next: PowerPC AltiVec/VSX Built-in Functions, Prev: Other MIPS Built-in Functions, Up: Target Builtins
-
-6.54.10 picoChip Built-in Functions
------------------------------------
-
-GCC provides an interface to selected machine instructions from the
-picoChip instruction set.
-
-`int __builtin_sbc (int VALUE)'
- Sign bit count. Return the number of consecutive bits in VALUE
- which have the same value as the sign-bit. The result is the
- number of leading sign bits minus one, giving the number of
- redundant sign bits in VALUE.
-
-`int __builtin_byteswap (int VALUE)'
- Byte swap. Return the result of swapping the upper and lower
- bytes of VALUE.
-
-`int __builtin_brev (int VALUE)'
- Bit reversal. Return the result of reversing the bits in VALUE.
- Bit 15 is swapped with bit 0, bit 14 is swapped with bit 1, and so
- on.
-
-`int __builtin_adds (int X, int Y)'
- Saturating addition. Return the result of adding X and Y, storing
- the value 32767 if the result overflows.
-
-`int __builtin_subs (int X, int Y)'
- Saturating subtraction. Return the result of subtracting Y from
- X, storing the value -32768 if the result overflows.
-
-`void __builtin_halt (void)'
- Halt. The processor will stop execution. This built-in is useful
- for implementing assertions.
-
-
-
-File: gcc.info, Node: Other MIPS Built-in Functions, Next: picoChip Built-in Functions, Prev: MIPS Loongson Built-in Functions, Up: Target Builtins
-
-6.54.11 Other MIPS Built-in Functions
--------------------------------------
-
-GCC provides other MIPS-specific built-in functions:
-
-`void __builtin_mips_cache (int OP, const volatile void *ADDR)'
- Insert a `cache' instruction with operands OP and ADDR. GCC
- defines the preprocessor macro `___GCC_HAVE_BUILTIN_MIPS_CACHE'
- when this function is available.
-
-
-File: gcc.info, Node: PowerPC AltiVec/VSX Built-in Functions, Next: RX Built-in Functions, Prev: picoChip Built-in Functions, Up: Target Builtins
-
-6.54.12 PowerPC AltiVec Built-in Functions
-------------------------------------------
-
-GCC provides an interface for the PowerPC family of processors to access
-the AltiVec operations described in Motorola's AltiVec Programming
-Interface Manual. The interface is made available by including
-`<altivec.h>' and using `-maltivec' and `-mabi=altivec'. The interface
-supports the following vector types.
-
- vector unsigned char
- vector signed char
- vector bool char
-
- vector unsigned short
- vector signed short
- vector bool short
- vector pixel
-
- vector unsigned int
- vector signed int
- vector bool int
- vector float
-
- If `-mvsx' is used the following additional vector types are
-implemented.
-
- vector unsigned long
- vector signed long
- vector double
-
- The long types are only implemented for 64-bit code generation, and
-the long type is only used in the floating point/integer conversion
-instructions.
-
- GCC's implementation of the high-level language interface available
-from C and C++ code differs from Motorola's documentation in several
-ways.
-
- * A vector constant is a list of constant expressions within curly
- braces.
-
- * A vector initializer requires no cast if the vector constant is of
- the same type as the variable it is initializing.
-
- * If `signed' or `unsigned' is omitted, the signedness of the vector
- type is the default signedness of the base type. The default
- varies depending on the operating system, so a portable program
- should always specify the signedness.
-
- * Compiling with `-maltivec' adds keywords `__vector', `vector',
- `__pixel', `pixel', `__bool' and `bool'. When compiling ISO C,
- the context-sensitive substitution of the keywords `vector',
- `pixel' and `bool' is disabled. To use them, you must include
- `<altivec.h>' instead.
-
- * GCC allows using a `typedef' name as the type specifier for a
- vector type.
-
- * For C, overloaded functions are implemented with macros so the
- following does not work:
-
- vec_add ((vector signed int){1, 2, 3, 4}, foo);
-
- Since `vec_add' is a macro, the vector constant in the example is
- treated as four separate arguments. Wrap the entire argument in
- parentheses for this to work.
-
- _Note:_ Only the `<altivec.h>' interface is supported. Internally,
-GCC uses built-in functions to achieve the functionality in the
-aforementioned header file, but they are not supported and are subject
-to change without notice.
-
- The following interfaces are supported for the generic and specific
-AltiVec operations and the AltiVec predicates. In cases where there is
-a direct mapping between generic and specific operations, only the
-generic names are shown here, although the specific operations can also
-be used.
-
- Arguments that are documented as `const int' require literal integral
-values within the range required for that operation.
-
- vector signed char vec_abs (vector signed char);
- vector signed short vec_abs (vector signed short);
- vector signed int vec_abs (vector signed int);
- vector float vec_abs (vector float);
-
- vector signed char vec_abss (vector signed char);
- vector signed short vec_abss (vector signed short);
- vector signed int vec_abss (vector signed int);
-
- vector signed char vec_add (vector bool char, vector signed char);
- vector signed char vec_add (vector signed char, vector bool char);
- vector signed char vec_add (vector signed char, vector signed char);
- vector unsigned char vec_add (vector bool char, vector unsigned char);
- vector unsigned char vec_add (vector unsigned char, vector bool char);
- vector unsigned char vec_add (vector unsigned char,
- vector unsigned char);
- vector signed short vec_add (vector bool short, vector signed short);
- vector signed short vec_add (vector signed short, vector bool short);
- vector signed short vec_add (vector signed short, vector signed short);
- vector unsigned short vec_add (vector bool short,
- vector unsigned short);
- vector unsigned short vec_add (vector unsigned short,
- vector bool short);
- vector unsigned short vec_add (vector unsigned short,
- vector unsigned short);
- vector signed int vec_add (vector bool int, vector signed int);
- vector signed int vec_add (vector signed int, vector bool int);
- vector signed int vec_add (vector signed int, vector signed int);
- vector unsigned int vec_add (vector bool int, vector unsigned int);
- vector unsigned int vec_add (vector unsigned int, vector bool int);
- vector unsigned int vec_add (vector unsigned int, vector unsigned int);
- vector float vec_add (vector float, vector float);
-
- vector float vec_vaddfp (vector float, vector float);
-
- vector signed int vec_vadduwm (vector bool int, vector signed int);
- vector signed int vec_vadduwm (vector signed int, vector bool int);
- vector signed int vec_vadduwm (vector signed int, vector signed int);
- vector unsigned int vec_vadduwm (vector bool int, vector unsigned int);
- vector unsigned int vec_vadduwm (vector unsigned int, vector bool int);
- vector unsigned int vec_vadduwm (vector unsigned int,
- vector unsigned int);
-
- vector signed short vec_vadduhm (vector bool short,
- vector signed short);
- vector signed short vec_vadduhm (vector signed short,
- vector bool short);
- vector signed short vec_vadduhm (vector signed short,
- vector signed short);
- vector unsigned short vec_vadduhm (vector bool short,
- vector unsigned short);
- vector unsigned short vec_vadduhm (vector unsigned short,
- vector bool short);
- vector unsigned short vec_vadduhm (vector unsigned short,
- vector unsigned short);
-
- vector signed char vec_vaddubm (vector bool char, vector signed char);
- vector signed char vec_vaddubm (vector signed char, vector bool char);
- vector signed char vec_vaddubm (vector signed char, vector signed char);
- vector unsigned char vec_vaddubm (vector bool char,
- vector unsigned char);
- vector unsigned char vec_vaddubm (vector unsigned char,
- vector bool char);
- vector unsigned char vec_vaddubm (vector unsigned char,
- vector unsigned char);
-
- vector unsigned int vec_addc (vector unsigned int, vector unsigned int);
-
- vector unsigned char vec_adds (vector bool char, vector unsigned char);
- vector unsigned char vec_adds (vector unsigned char, vector bool char);
- vector unsigned char vec_adds (vector unsigned char,
- vector unsigned char);
- vector signed char vec_adds (vector bool char, vector signed char);
- vector signed char vec_adds (vector signed char, vector bool char);
- vector signed char vec_adds (vector signed char, vector signed char);
- vector unsigned short vec_adds (vector bool short,
- vector unsigned short);
- vector unsigned short vec_adds (vector unsigned short,
- vector bool short);
- vector unsigned short vec_adds (vector unsigned short,
- vector unsigned short);
- vector signed short vec_adds (vector bool short, vector signed short);
- vector signed short vec_adds (vector signed short, vector bool short);
- vector signed short vec_adds (vector signed short, vector signed short);
- vector unsigned int vec_adds (vector bool int, vector unsigned int);
- vector unsigned int vec_adds (vector unsigned int, vector bool int);
- vector unsigned int vec_adds (vector unsigned int, vector unsigned int);
- vector signed int vec_adds (vector bool int, vector signed int);
- vector signed int vec_adds (vector signed int, vector bool int);
- vector signed int vec_adds (vector signed int, vector signed int);
-
- vector signed int vec_vaddsws (vector bool int, vector signed int);
- vector signed int vec_vaddsws (vector signed int, vector bool int);
- vector signed int vec_vaddsws (vector signed int, vector signed int);
-
- vector unsigned int vec_vadduws (vector bool int, vector unsigned int);
- vector unsigned int vec_vadduws (vector unsigned int, vector bool int);
- vector unsigned int vec_vadduws (vector unsigned int,
- vector unsigned int);
-
- vector signed short vec_vaddshs (vector bool short,
- vector signed short);
- vector signed short vec_vaddshs (vector signed short,
- vector bool short);
- vector signed short vec_vaddshs (vector signed short,
- vector signed short);
-
- vector unsigned short vec_vadduhs (vector bool short,
- vector unsigned short);
- vector unsigned short vec_vadduhs (vector unsigned short,
- vector bool short);
- vector unsigned short vec_vadduhs (vector unsigned short,
- vector unsigned short);
-
- vector signed char vec_vaddsbs (vector bool char, vector signed char);
- vector signed char vec_vaddsbs (vector signed char, vector bool char);
- vector signed char vec_vaddsbs (vector signed char, vector signed char);
-
- vector unsigned char vec_vaddubs (vector bool char,
- vector unsigned char);
- vector unsigned char vec_vaddubs (vector unsigned char,
- vector bool char);
- vector unsigned char vec_vaddubs (vector unsigned char,
- vector unsigned char);
-
- vector float vec_and (vector float, vector float);
- vector float vec_and (vector float, vector bool int);
- vector float vec_and (vector bool int, vector float);
- vector bool int vec_and (vector bool int, vector bool int);
- vector signed int vec_and (vector bool int, vector signed int);
- vector signed int vec_and (vector signed int, vector bool int);
- vector signed int vec_and (vector signed int, vector signed int);
- vector unsigned int vec_and (vector bool int, vector unsigned int);
- vector unsigned int vec_and (vector unsigned int, vector bool int);
- vector unsigned int vec_and (vector unsigned int, vector unsigned int);
- vector bool short vec_and (vector bool short, vector bool short);
- vector signed short vec_and (vector bool short, vector signed short);
- vector signed short vec_and (vector signed short, vector bool short);
- vector signed short vec_and (vector signed short, vector signed short);
- vector unsigned short vec_and (vector bool short,
- vector unsigned short);
- vector unsigned short vec_and (vector unsigned short,
- vector bool short);
- vector unsigned short vec_and (vector unsigned short,
- vector unsigned short);
- vector signed char vec_and (vector bool char, vector signed char);
- vector bool char vec_and (vector bool char, vector bool char);
- vector signed char vec_and (vector signed char, vector bool char);
- vector signed char vec_and (vector signed char, vector signed char);
- vector unsigned char vec_and (vector bool char, vector unsigned char);
- vector unsigned char vec_and (vector unsigned char, vector bool char);
- vector unsigned char vec_and (vector unsigned char,
- vector unsigned char);
-
- vector float vec_andc (vector float, vector float);
- vector float vec_andc (vector float, vector bool int);
- vector float vec_andc (vector bool int, vector float);
- vector bool int vec_andc (vector bool int, vector bool int);
- vector signed int vec_andc (vector bool int, vector signed int);
- vector signed int vec_andc (vector signed int, vector bool int);
- vector signed int vec_andc (vector signed int, vector signed int);
- vector unsigned int vec_andc (vector bool int, vector unsigned int);
- vector unsigned int vec_andc (vector unsigned int, vector bool int);
- vector unsigned int vec_andc (vector unsigned int, vector unsigned int);
- vector bool short vec_andc (vector bool short, vector bool short);
- vector signed short vec_andc (vector bool short, vector signed short);
- vector signed short vec_andc (vector signed short, vector bool short);
- vector signed short vec_andc (vector signed short, vector signed short);
- vector unsigned short vec_andc (vector bool short,
- vector unsigned short);
- vector unsigned short vec_andc (vector unsigned short,
- vector bool short);
- vector unsigned short vec_andc (vector unsigned short,
- vector unsigned short);
- vector signed char vec_andc (vector bool char, vector signed char);
- vector bool char vec_andc (vector bool char, vector bool char);
- vector signed char vec_andc (vector signed char, vector bool char);
- vector signed char vec_andc (vector signed char, vector signed char);
- vector unsigned char vec_andc (vector bool char, vector unsigned char);
- vector unsigned char vec_andc (vector unsigned char, vector bool char);
- vector unsigned char vec_andc (vector unsigned char,
- vector unsigned char);
-
- vector unsigned char vec_avg (vector unsigned char,
- vector unsigned char);
- vector signed char vec_avg (vector signed char, vector signed char);
- vector unsigned short vec_avg (vector unsigned short,
- vector unsigned short);
- vector signed short vec_avg (vector signed short, vector signed short);
- vector unsigned int vec_avg (vector unsigned int, vector unsigned int);
- vector signed int vec_avg (vector signed int, vector signed int);
-
- vector signed int vec_vavgsw (vector signed int, vector signed int);
-
- vector unsigned int vec_vavguw (vector unsigned int,
- vector unsigned int);
-
- vector signed short vec_vavgsh (vector signed short,
- vector signed short);
-
- vector unsigned short vec_vavguh (vector unsigned short,
- vector unsigned short);
-
- vector signed char vec_vavgsb (vector signed char, vector signed char);
-
- vector unsigned char vec_vavgub (vector unsigned char,
- vector unsigned char);
-
- vector float vec_copysign (vector float);
-
- vector float vec_ceil (vector float);
-
- vector signed int vec_cmpb (vector float, vector float);
-
- vector bool char vec_cmpeq (vector signed char, vector signed char);
- vector bool char vec_cmpeq (vector unsigned char, vector unsigned char);
- vector bool short vec_cmpeq (vector signed short, vector signed short);
- vector bool short vec_cmpeq (vector unsigned short,
- vector unsigned short);
- vector bool int vec_cmpeq (vector signed int, vector signed int);
- vector bool int vec_cmpeq (vector unsigned int, vector unsigned int);
- vector bool int vec_cmpeq (vector float, vector float);
-
- vector bool int vec_vcmpeqfp (vector float, vector float);
-
- vector bool int vec_vcmpequw (vector signed int, vector signed int);
- vector bool int vec_vcmpequw (vector unsigned int, vector unsigned int);
-
- vector bool short vec_vcmpequh (vector signed short,
- vector signed short);
- vector bool short vec_vcmpequh (vector unsigned short,
- vector unsigned short);
-
- vector bool char vec_vcmpequb (vector signed char, vector signed char);
- vector bool char vec_vcmpequb (vector unsigned char,
- vector unsigned char);
-
- vector bool int vec_cmpge (vector float, vector float);
-
- vector bool char vec_cmpgt (vector unsigned char, vector unsigned char);
- vector bool char vec_cmpgt (vector signed char, vector signed char);
- vector bool short vec_cmpgt (vector unsigned short,
- vector unsigned short);
- vector bool short vec_cmpgt (vector signed short, vector signed short);
- vector bool int vec_cmpgt (vector unsigned int, vector unsigned int);
- vector bool int vec_cmpgt (vector signed int, vector signed int);
- vector bool int vec_cmpgt (vector float, vector float);
-
- vector bool int vec_vcmpgtfp (vector float, vector float);
-
- vector bool int vec_vcmpgtsw (vector signed int, vector signed int);
-
- vector bool int vec_vcmpgtuw (vector unsigned int, vector unsigned int);
-
- vector bool short vec_vcmpgtsh (vector signed short,
- vector signed short);
-
- vector bool short vec_vcmpgtuh (vector unsigned short,
- vector unsigned short);
-
- vector bool char vec_vcmpgtsb (vector signed char, vector signed char);
-
- vector bool char vec_vcmpgtub (vector unsigned char,
- vector unsigned char);
-
- vector bool int vec_cmple (vector float, vector float);
-
- vector bool char vec_cmplt (vector unsigned char, vector unsigned char);
- vector bool char vec_cmplt (vector signed char, vector signed char);
- vector bool short vec_cmplt (vector unsigned short,
- vector unsigned short);
- vector bool short vec_cmplt (vector signed short, vector signed short);
- vector bool int vec_cmplt (vector unsigned int, vector unsigned int);
- vector bool int vec_cmplt (vector signed int, vector signed int);
- vector bool int vec_cmplt (vector float, vector float);
-
- vector float vec_ctf (vector unsigned int, const int);
- vector float vec_ctf (vector signed int, const int);
-
- vector float vec_vcfsx (vector signed int, const int);
-
- vector float vec_vcfux (vector unsigned int, const int);
-
- vector signed int vec_cts (vector float, const int);
-
- vector unsigned int vec_ctu (vector float, const int);
-
- void vec_dss (const int);
-
- void vec_dssall (void);
-
- void vec_dst (const vector unsigned char *, int, const int);
- void vec_dst (const vector signed char *, int, const int);
- void vec_dst (const vector bool char *, int, const int);
- void vec_dst (const vector unsigned short *, int, const int);
- void vec_dst (const vector signed short *, int, const int);
- void vec_dst (const vector bool short *, int, const int);
- void vec_dst (const vector pixel *, int, const int);
- void vec_dst (const vector unsigned int *, int, const int);
- void vec_dst (const vector signed int *, int, const int);
- void vec_dst (const vector bool int *, int, const int);
- void vec_dst (const vector float *, int, const int);
- void vec_dst (const unsigned char *, int, const int);
- void vec_dst (const signed char *, int, const int);
- void vec_dst (const unsigned short *, int, const int);
- void vec_dst (const short *, int, const int);
- void vec_dst (const unsigned int *, int, const int);
- void vec_dst (const int *, int, const int);
- void vec_dst (const unsigned long *, int, const int);
- void vec_dst (const long *, int, const int);
- void vec_dst (const float *, int, const int);
-
- void vec_dstst (const vector unsigned char *, int, const int);
- void vec_dstst (const vector signed char *, int, const int);
- void vec_dstst (const vector bool char *, int, const int);
- void vec_dstst (const vector unsigned short *, int, const int);
- void vec_dstst (const vector signed short *, int, const int);
- void vec_dstst (const vector bool short *, int, const int);
- void vec_dstst (const vector pixel *, int, const int);
- void vec_dstst (const vector unsigned int *, int, const int);
- void vec_dstst (const vector signed int *, int, const int);
- void vec_dstst (const vector bool int *, int, const int);
- void vec_dstst (const vector float *, int, const int);
- void vec_dstst (const unsigned char *, int, const int);
- void vec_dstst (const signed char *, int, const int);
- void vec_dstst (const unsigned short *, int, const int);
- void vec_dstst (const short *, int, const int);
- void vec_dstst (const unsigned int *, int, const int);
- void vec_dstst (const int *, int, const int);
- void vec_dstst (const unsigned long *, int, const int);
- void vec_dstst (const long *, int, const int);
- void vec_dstst (const float *, int, const int);
-
- void vec_dststt (const vector unsigned char *, int, const int);
- void vec_dststt (const vector signed char *, int, const int);
- void vec_dststt (const vector bool char *, int, const int);
- void vec_dststt (const vector unsigned short *, int, const int);
- void vec_dststt (const vector signed short *, int, const int);
- void vec_dststt (const vector bool short *, int, const int);
- void vec_dststt (const vector pixel *, int, const int);
- void vec_dststt (const vector unsigned int *, int, const int);
- void vec_dststt (const vector signed int *, int, const int);
- void vec_dststt (const vector bool int *, int, const int);
- void vec_dststt (const vector float *, int, const int);
- void vec_dststt (const unsigned char *, int, const int);
- void vec_dststt (const signed char *, int, const int);
- void vec_dststt (const unsigned short *, int, const int);
- void vec_dststt (const short *, int, const int);
- void vec_dststt (const unsigned int *, int, const int);
- void vec_dststt (const int *, int, const int);
- void vec_dststt (const unsigned long *, int, const int);
- void vec_dststt (const long *, int, const int);
- void vec_dststt (const float *, int, const int);
-
- void vec_dstt (const vector unsigned char *, int, const int);
- void vec_dstt (const vector signed char *, int, const int);
- void vec_dstt (const vector bool char *, int, const int);
- void vec_dstt (const vector unsigned short *, int, const int);
- void vec_dstt (const vector signed short *, int, const int);
- void vec_dstt (const vector bool short *, int, const int);
- void vec_dstt (const vector pixel *, int, const int);
- void vec_dstt (const vector unsigned int *, int, const int);
- void vec_dstt (const vector signed int *, int, const int);
- void vec_dstt (const vector bool int *, int, const int);
- void vec_dstt (const vector float *, int, const int);
- void vec_dstt (const unsigned char *, int, const int);
- void vec_dstt (const signed char *, int, const int);
- void vec_dstt (const unsigned short *, int, const int);
- void vec_dstt (const short *, int, const int);
- void vec_dstt (const unsigned int *, int, const int);
- void vec_dstt (const int *, int, const int);
- void vec_dstt (const unsigned long *, int, const int);
- void vec_dstt (const long *, int, const int);
- void vec_dstt (const float *, int, const int);
-
- vector float vec_expte (vector float);
-
- vector float vec_floor (vector float);
-
- vector float vec_ld (int, const vector float *);
- vector float vec_ld (int, const float *);
- vector bool int vec_ld (int, const vector bool int *);
- vector signed int vec_ld (int, const vector signed int *);
- vector signed int vec_ld (int, const int *);
- vector signed int vec_ld (int, const long *);
- vector unsigned int vec_ld (int, const vector unsigned int *);
- vector unsigned int vec_ld (int, const unsigned int *);
- vector unsigned int vec_ld (int, const unsigned long *);
- vector bool short vec_ld (int, const vector bool short *);
- vector pixel vec_ld (int, const vector pixel *);
- vector signed short vec_ld (int, const vector signed short *);
- vector signed short vec_ld (int, const short *);
- vector unsigned short vec_ld (int, const vector unsigned short *);
- vector unsigned short vec_ld (int, const unsigned short *);
- vector bool char vec_ld (int, const vector bool char *);
- vector signed char vec_ld (int, const vector signed char *);
- vector signed char vec_ld (int, const signed char *);
- vector unsigned char vec_ld (int, const vector unsigned char *);
- vector unsigned char vec_ld (int, const unsigned char *);
-
- vector signed char vec_lde (int, const signed char *);
- vector unsigned char vec_lde (int, const unsigned char *);
- vector signed short vec_lde (int, const short *);
- vector unsigned short vec_lde (int, const unsigned short *);
- vector float vec_lde (int, const float *);
- vector signed int vec_lde (int, const int *);
- vector unsigned int vec_lde (int, const unsigned int *);
- vector signed int vec_lde (int, const long *);
- vector unsigned int vec_lde (int, const unsigned long *);
-
- vector float vec_lvewx (int, float *);
- vector signed int vec_lvewx (int, int *);
- vector unsigned int vec_lvewx (int, unsigned int *);
- vector signed int vec_lvewx (int, long *);
- vector unsigned int vec_lvewx (int, unsigned long *);
-
- vector signed short vec_lvehx (int, short *);
- vector unsigned short vec_lvehx (int, unsigned short *);
-
- vector signed char vec_lvebx (int, char *);
- vector unsigned char vec_lvebx (int, unsigned char *);
-
- vector float vec_ldl (int, const vector float *);
- vector float vec_ldl (int, const float *);
- vector bool int vec_ldl (int, const vector bool int *);
- vector signed int vec_ldl (int, const vector signed int *);
- vector signed int vec_ldl (int, const int *);
- vector signed int vec_ldl (int, const long *);
- vector unsigned int vec_ldl (int, const vector unsigned int *);
- vector unsigned int vec_ldl (int, const unsigned int *);
- vector unsigned int vec_ldl (int, const unsigned long *);
- vector bool short vec_ldl (int, const vector bool short *);
- vector pixel vec_ldl (int, const vector pixel *);
- vector signed short vec_ldl (int, const vector signed short *);
- vector signed short vec_ldl (int, const short *);
- vector unsigned short vec_ldl (int, const vector unsigned short *);
- vector unsigned short vec_ldl (int, const unsigned short *);
- vector bool char vec_ldl (int, const vector bool char *);
- vector signed char vec_ldl (int, const vector signed char *);
- vector signed char vec_ldl (int, const signed char *);
- vector unsigned char vec_ldl (int, const vector unsigned char *);
- vector unsigned char vec_ldl (int, const unsigned char *);
-
- vector float vec_loge (vector float);
-
- vector unsigned char vec_lvsl (int, const volatile unsigned char *);
- vector unsigned char vec_lvsl (int, const volatile signed char *);
- vector unsigned char vec_lvsl (int, const volatile unsigned short *);
- vector unsigned char vec_lvsl (int, const volatile short *);
- vector unsigned char vec_lvsl (int, const volatile unsigned int *);
- vector unsigned char vec_lvsl (int, const volatile int *);
- vector unsigned char vec_lvsl (int, const volatile unsigned long *);
- vector unsigned char vec_lvsl (int, const volatile long *);
- vector unsigned char vec_lvsl (int, const volatile float *);
-
- vector unsigned char vec_lvsr (int, const volatile unsigned char *);
- vector unsigned char vec_lvsr (int, const volatile signed char *);
- vector unsigned char vec_lvsr (int, const volatile unsigned short *);
- vector unsigned char vec_lvsr (int, const volatile short *);
- vector unsigned char vec_lvsr (int, const volatile unsigned int *);
- vector unsigned char vec_lvsr (int, const volatile int *);
- vector unsigned char vec_lvsr (int, const volatile unsigned long *);
- vector unsigned char vec_lvsr (int, const volatile long *);
- vector unsigned char vec_lvsr (int, const volatile float *);
-
- vector float vec_madd (vector float, vector float, vector float);
-
- vector signed short vec_madds (vector signed short,
- vector signed short,
- vector signed short);
-
- vector unsigned char vec_max (vector bool char, vector unsigned char);
- vector unsigned char vec_max (vector unsigned char, vector bool char);
- vector unsigned char vec_max (vector unsigned char,
- vector unsigned char);
- vector signed char vec_max (vector bool char, vector signed char);
- vector signed char vec_max (vector signed char, vector bool char);
- vector signed char vec_max (vector signed char, vector signed char);
- vector unsigned short vec_max (vector bool short,
- vector unsigned short);
- vector unsigned short vec_max (vector unsigned short,
- vector bool short);
- vector unsigned short vec_max (vector unsigned short,
- vector unsigned short);
- vector signed short vec_max (vector bool short, vector signed short);
- vector signed short vec_max (vector signed short, vector bool short);
- vector signed short vec_max (vector signed short, vector signed short);
- vector unsigned int vec_max (vector bool int, vector unsigned int);
- vector unsigned int vec_max (vector unsigned int, vector bool int);
- vector unsigned int vec_max (vector unsigned int, vector unsigned int);
- vector signed int vec_max (vector bool int, vector signed int);
- vector signed int vec_max (vector signed int, vector bool int);
- vector signed int vec_max (vector signed int, vector signed int);
- vector float vec_max (vector float, vector float);
-
- vector float vec_vmaxfp (vector float, vector float);
-
- vector signed int vec_vmaxsw (vector bool int, vector signed int);
- vector signed int vec_vmaxsw (vector signed int, vector bool int);
- vector signed int vec_vmaxsw (vector signed int, vector signed int);
-
- vector unsigned int vec_vmaxuw (vector bool int, vector unsigned int);
- vector unsigned int vec_vmaxuw (vector unsigned int, vector bool int);
- vector unsigned int vec_vmaxuw (vector unsigned int,
- vector unsigned int);
-
- vector signed short vec_vmaxsh (vector bool short, vector signed short);
- vector signed short vec_vmaxsh (vector signed short, vector bool short);
- vector signed short vec_vmaxsh (vector signed short,
- vector signed short);
-
- vector unsigned short vec_vmaxuh (vector bool short,
- vector unsigned short);
- vector unsigned short vec_vmaxuh (vector unsigned short,
- vector bool short);
- vector unsigned short vec_vmaxuh (vector unsigned short,
- vector unsigned short);
-
- vector signed char vec_vmaxsb (vector bool char, vector signed char);
- vector signed char vec_vmaxsb (vector signed char, vector bool char);
- vector signed char vec_vmaxsb (vector signed char, vector signed char);
-
- vector unsigned char vec_vmaxub (vector bool char,
- vector unsigned char);
- vector unsigned char vec_vmaxub (vector unsigned char,
- vector bool char);
- vector unsigned char vec_vmaxub (vector unsigned char,
- vector unsigned char);
-
- vector bool char vec_mergeh (vector bool char, vector bool char);
- vector signed char vec_mergeh (vector signed char, vector signed char);
- vector unsigned char vec_mergeh (vector unsigned char,
- vector unsigned char);
- vector bool short vec_mergeh (vector bool short, vector bool short);
- vector pixel vec_mergeh (vector pixel, vector pixel);
- vector signed short vec_mergeh (vector signed short,
- vector signed short);
- vector unsigned short vec_mergeh (vector unsigned short,
- vector unsigned short);
- vector float vec_mergeh (vector float, vector float);
- vector bool int vec_mergeh (vector bool int, vector bool int);
- vector signed int vec_mergeh (vector signed int, vector signed int);
- vector unsigned int vec_mergeh (vector unsigned int,
- vector unsigned int);
-
- vector float vec_vmrghw (vector float, vector float);
- vector bool int vec_vmrghw (vector bool int, vector bool int);
- vector signed int vec_vmrghw (vector signed int, vector signed int);
- vector unsigned int vec_vmrghw (vector unsigned int,
- vector unsigned int);
-
- vector bool short vec_vmrghh (vector bool short, vector bool short);
- vector signed short vec_vmrghh (vector signed short,
- vector signed short);
- vector unsigned short vec_vmrghh (vector unsigned short,
- vector unsigned short);
- vector pixel vec_vmrghh (vector pixel, vector pixel);
-
- vector bool char vec_vmrghb (vector bool char, vector bool char);
- vector signed char vec_vmrghb (vector signed char, vector signed char);
- vector unsigned char vec_vmrghb (vector unsigned char,
- vector unsigned char);
-
- vector bool char vec_mergel (vector bool char, vector bool char);
- vector signed char vec_mergel (vector signed char, vector signed char);
- vector unsigned char vec_mergel (vector unsigned char,
- vector unsigned char);
- vector bool short vec_mergel (vector bool short, vector bool short);
- vector pixel vec_mergel (vector pixel, vector pixel);
- vector signed short vec_mergel (vector signed short,
- vector signed short);
- vector unsigned short vec_mergel (vector unsigned short,
- vector unsigned short);
- vector float vec_mergel (vector float, vector float);
- vector bool int vec_mergel (vector bool int, vector bool int);
- vector signed int vec_mergel (vector signed int, vector signed int);
- vector unsigned int vec_mergel (vector unsigned int,
- vector unsigned int);
-
- vector float vec_vmrglw (vector float, vector float);
- vector signed int vec_vmrglw (vector signed int, vector signed int);
- vector unsigned int vec_vmrglw (vector unsigned int,
- vector unsigned int);
- vector bool int vec_vmrglw (vector bool int, vector bool int);
-
- vector bool short vec_vmrglh (vector bool short, vector bool short);
- vector signed short vec_vmrglh (vector signed short,
- vector signed short);
- vector unsigned short vec_vmrglh (vector unsigned short,
- vector unsigned short);
- vector pixel vec_vmrglh (vector pixel, vector pixel);
-
- vector bool char vec_vmrglb (vector bool char, vector bool char);
- vector signed char vec_vmrglb (vector signed char, vector signed char);
- vector unsigned char vec_vmrglb (vector unsigned char,
- vector unsigned char);
-
- vector unsigned short vec_mfvscr (void);
-
- vector unsigned char vec_min (vector bool char, vector unsigned char);
- vector unsigned char vec_min (vector unsigned char, vector bool char);
- vector unsigned char vec_min (vector unsigned char,
- vector unsigned char);
- vector signed char vec_min (vector bool char, vector signed char);
- vector signed char vec_min (vector signed char, vector bool char);
- vector signed char vec_min (vector signed char, vector signed char);
- vector unsigned short vec_min (vector bool short,
- vector unsigned short);
- vector unsigned short vec_min (vector unsigned short,
- vector bool short);
- vector unsigned short vec_min (vector unsigned short,
- vector unsigned short);
- vector signed short vec_min (vector bool short, vector signed short);
- vector signed short vec_min (vector signed short, vector bool short);
- vector signed short vec_min (vector signed short, vector signed short);
- vector unsigned int vec_min (vector bool int, vector unsigned int);
- vector unsigned int vec_min (vector unsigned int, vector bool int);
- vector unsigned int vec_min (vector unsigned int, vector unsigned int);
- vector signed int vec_min (vector bool int, vector signed int);
- vector signed int vec_min (vector signed int, vector bool int);
- vector signed int vec_min (vector signed int, vector signed int);
- vector float vec_min (vector float, vector float);
-
- vector float vec_vminfp (vector float, vector float);
-
- vector signed int vec_vminsw (vector bool int, vector signed int);
- vector signed int vec_vminsw (vector signed int, vector bool int);
- vector signed int vec_vminsw (vector signed int, vector signed int);
-
- vector unsigned int vec_vminuw (vector bool int, vector unsigned int);
- vector unsigned int vec_vminuw (vector unsigned int, vector bool int);
- vector unsigned int vec_vminuw (vector unsigned int,
- vector unsigned int);
-
- vector signed short vec_vminsh (vector bool short, vector signed short);
- vector signed short vec_vminsh (vector signed short, vector bool short);
- vector signed short vec_vminsh (vector signed short,
- vector signed short);
-
- vector unsigned short vec_vminuh (vector bool short,
- vector unsigned short);
- vector unsigned short vec_vminuh (vector unsigned short,
- vector bool short);
- vector unsigned short vec_vminuh (vector unsigned short,
- vector unsigned short);
-
- vector signed char vec_vminsb (vector bool char, vector signed char);
- vector signed char vec_vminsb (vector signed char, vector bool char);
- vector signed char vec_vminsb (vector signed char, vector signed char);
-
- vector unsigned char vec_vminub (vector bool char,
- vector unsigned char);
- vector unsigned char vec_vminub (vector unsigned char,
- vector bool char);
- vector unsigned char vec_vminub (vector unsigned char,
- vector unsigned char);
-
- vector signed short vec_mladd (vector signed short,
- vector signed short,
- vector signed short);
- vector signed short vec_mladd (vector signed short,
- vector unsigned short,
- vector unsigned short);
- vector signed short vec_mladd (vector unsigned short,
- vector signed short,
- vector signed short);
- vector unsigned short vec_mladd (vector unsigned short,
- vector unsigned short,
- vector unsigned short);
-
- vector signed short vec_mradds (vector signed short,
- vector signed short,
- vector signed short);
-
- vector unsigned int vec_msum (vector unsigned char,
- vector unsigned char,
- vector unsigned int);
- vector signed int vec_msum (vector signed char,
- vector unsigned char,
- vector signed int);
- vector unsigned int vec_msum (vector unsigned short,
- vector unsigned short,
- vector unsigned int);
- vector signed int vec_msum (vector signed short,
- vector signed short,
- vector signed int);
-
- vector signed int vec_vmsumshm (vector signed short,
- vector signed short,
- vector signed int);
-
- vector unsigned int vec_vmsumuhm (vector unsigned short,
- vector unsigned short,
- vector unsigned int);
-
- vector signed int vec_vmsummbm (vector signed char,
- vector unsigned char,
- vector signed int);
-
- vector unsigned int vec_vmsumubm (vector unsigned char,
- vector unsigned char,
- vector unsigned int);
-
- vector unsigned int vec_msums (vector unsigned short,
- vector unsigned short,
- vector unsigned int);
- vector signed int vec_msums (vector signed short,
- vector signed short,
- vector signed int);
-
- vector signed int vec_vmsumshs (vector signed short,
- vector signed short,
- vector signed int);
-
- vector unsigned int vec_vmsumuhs (vector unsigned short,
- vector unsigned short,
- vector unsigned int);
-
- void vec_mtvscr (vector signed int);
- void vec_mtvscr (vector unsigned int);
- void vec_mtvscr (vector bool int);
- void vec_mtvscr (vector signed short);
- void vec_mtvscr (vector unsigned short);
- void vec_mtvscr (vector bool short);
- void vec_mtvscr (vector pixel);
- void vec_mtvscr (vector signed char);
- void vec_mtvscr (vector unsigned char);
- void vec_mtvscr (vector bool char);
-
- vector unsigned short vec_mule (vector unsigned char,
- vector unsigned char);
- vector signed short vec_mule (vector signed char,
- vector signed char);
- vector unsigned int vec_mule (vector unsigned short,
- vector unsigned short);
- vector signed int vec_mule (vector signed short, vector signed short);
-
- vector signed int vec_vmulesh (vector signed short,
- vector signed short);
-
- vector unsigned int vec_vmuleuh (vector unsigned short,
- vector unsigned short);
-
- vector signed short vec_vmulesb (vector signed char,
- vector signed char);
-
- vector unsigned short vec_vmuleub (vector unsigned char,
- vector unsigned char);
-
- vector unsigned short vec_mulo (vector unsigned char,
- vector unsigned char);
- vector signed short vec_mulo (vector signed char, vector signed char);
- vector unsigned int vec_mulo (vector unsigned short,
- vector unsigned short);
- vector signed int vec_mulo (vector signed short, vector signed short);
-
- vector signed int vec_vmulosh (vector signed short,
- vector signed short);
-
- vector unsigned int vec_vmulouh (vector unsigned short,
- vector unsigned short);
-
- vector signed short vec_vmulosb (vector signed char,
- vector signed char);
-
- vector unsigned short vec_vmuloub (vector unsigned char,
- vector unsigned char);
-
- vector float vec_nmsub (vector float, vector float, vector float);
-
- vector float vec_nor (vector float, vector float);
- vector signed int vec_nor (vector signed int, vector signed int);
- vector unsigned int vec_nor (vector unsigned int, vector unsigned int);
- vector bool int vec_nor (vector bool int, vector bool int);
- vector signed short vec_nor (vector signed short, vector signed short);
- vector unsigned short vec_nor (vector unsigned short,
- vector unsigned short);
- vector bool short vec_nor (vector bool short, vector bool short);
- vector signed char vec_nor (vector signed char, vector signed char);
- vector unsigned char vec_nor (vector unsigned char,
- vector unsigned char);
- vector bool char vec_nor (vector bool char, vector bool char);
-
- vector float vec_or (vector float, vector float);
- vector float vec_or (vector float, vector bool int);
- vector float vec_or (vector bool int, vector float);
- vector bool int vec_or (vector bool int, vector bool int);
- vector signed int vec_or (vector bool int, vector signed int);
- vector signed int vec_or (vector signed int, vector bool int);
- vector signed int vec_or (vector signed int, vector signed int);
- vector unsigned int vec_or (vector bool int, vector unsigned int);
- vector unsigned int vec_or (vector unsigned int, vector bool int);
- vector unsigned int vec_or (vector unsigned int, vector unsigned int);
- vector bool short vec_or (vector bool short, vector bool short);
- vector signed short vec_or (vector bool short, vector signed short);
- vector signed short vec_or (vector signed short, vector bool short);
- vector signed short vec_or (vector signed short, vector signed short);
- vector unsigned short vec_or (vector bool short, vector unsigned short);
- vector unsigned short vec_or (vector unsigned short, vector bool short);
- vector unsigned short vec_or (vector unsigned short,
- vector unsigned short);
- vector signed char vec_or (vector bool char, vector signed char);
- vector bool char vec_or (vector bool char, vector bool char);
- vector signed char vec_or (vector signed char, vector bool char);
- vector signed char vec_or (vector signed char, vector signed char);
- vector unsigned char vec_or (vector bool char, vector unsigned char);
- vector unsigned char vec_or (vector unsigned char, vector bool char);
- vector unsigned char vec_or (vector unsigned char,
- vector unsigned char);
-
- vector signed char vec_pack (vector signed short, vector signed short);
- vector unsigned char vec_pack (vector unsigned short,
- vector unsigned short);
- vector bool char vec_pack (vector bool short, vector bool short);
- vector signed short vec_pack (vector signed int, vector signed int);
- vector unsigned short vec_pack (vector unsigned int,
- vector unsigned int);
- vector bool short vec_pack (vector bool int, vector bool int);
-
- vector bool short vec_vpkuwum (vector bool int, vector bool int);
- vector signed short vec_vpkuwum (vector signed int, vector signed int);
- vector unsigned short vec_vpkuwum (vector unsigned int,
- vector unsigned int);
-
- vector bool char vec_vpkuhum (vector bool short, vector bool short);
- vector signed char vec_vpkuhum (vector signed short,
- vector signed short);
- vector unsigned char vec_vpkuhum (vector unsigned short,
- vector unsigned short);
-
- vector pixel vec_packpx (vector unsigned int, vector unsigned int);
-
- vector unsigned char vec_packs (vector unsigned short,
- vector unsigned short);
- vector signed char vec_packs (vector signed short, vector signed short);
- vector unsigned short vec_packs (vector unsigned int,
- vector unsigned int);
- vector signed short vec_packs (vector signed int, vector signed int);
-
- vector signed short vec_vpkswss (vector signed int, vector signed int);
-
- vector unsigned short vec_vpkuwus (vector unsigned int,
- vector unsigned int);
-
- vector signed char vec_vpkshss (vector signed short,
- vector signed short);
-
- vector unsigned char vec_vpkuhus (vector unsigned short,
- vector unsigned short);
-
- vector unsigned char vec_packsu (vector unsigned short,
- vector unsigned short);
- vector unsigned char vec_packsu (vector signed short,
- vector signed short);
- vector unsigned short vec_packsu (vector unsigned int,
- vector unsigned int);
- vector unsigned short vec_packsu (vector signed int, vector signed int);
-
- vector unsigned short vec_vpkswus (vector signed int,
- vector signed int);
-
- vector unsigned char vec_vpkshus (vector signed short,
- vector signed short);
-
- vector float vec_perm (vector float,
- vector float,
- vector unsigned char);
- vector signed int vec_perm (vector signed int,
- vector signed int,
- vector unsigned char);
- vector unsigned int vec_perm (vector unsigned int,
- vector unsigned int,
- vector unsigned char);
- vector bool int vec_perm (vector bool int,
- vector bool int,
- vector unsigned char);
- vector signed short vec_perm (vector signed short,
- vector signed short,
- vector unsigned char);
- vector unsigned short vec_perm (vector unsigned short,
- vector unsigned short,
- vector unsigned char);
- vector bool short vec_perm (vector bool short,
- vector bool short,
- vector unsigned char);
- vector pixel vec_perm (vector pixel,
- vector pixel,
- vector unsigned char);
- vector signed char vec_perm (vector signed char,
- vector signed char,
- vector unsigned char);
- vector unsigned char vec_perm (vector unsigned char,
- vector unsigned char,
- vector unsigned char);
- vector bool char vec_perm (vector bool char,
- vector bool char,
- vector unsigned char);
-
- vector float vec_re (vector float);
-
- vector signed char vec_rl (vector signed char,
- vector unsigned char);
- vector unsigned char vec_rl (vector unsigned char,
- vector unsigned char);
- vector signed short vec_rl (vector signed short, vector unsigned short);
- vector unsigned short vec_rl (vector unsigned short,
- vector unsigned short);
- vector signed int vec_rl (vector signed int, vector unsigned int);
- vector unsigned int vec_rl (vector unsigned int, vector unsigned int);
-
- vector signed int vec_vrlw (vector signed int, vector unsigned int);
- vector unsigned int vec_vrlw (vector unsigned int, vector unsigned int);
-
- vector signed short vec_vrlh (vector signed short,
- vector unsigned short);
- vector unsigned short vec_vrlh (vector unsigned short,
- vector unsigned short);
-
- vector signed char vec_vrlb (vector signed char, vector unsigned char);
- vector unsigned char vec_vrlb (vector unsigned char,
- vector unsigned char);
-
- vector float vec_round (vector float);
-
- vector float vec_recip (vector float, vector float);
-
- vector float vec_rsqrt (vector float);
-
- vector float vec_rsqrte (vector float);
-
- vector float vec_sel (vector float, vector float, vector bool int);
- vector float vec_sel (vector float, vector float, vector unsigned int);
- vector signed int vec_sel (vector signed int,
- vector signed int,
- vector bool int);
- vector signed int vec_sel (vector signed int,
- vector signed int,
- vector unsigned int);
- vector unsigned int vec_sel (vector unsigned int,
- vector unsigned int,
- vector bool int);
- vector unsigned int vec_sel (vector unsigned int,
- vector unsigned int,
- vector unsigned int);
- vector bool int vec_sel (vector bool int,
- vector bool int,
- vector bool int);
- vector bool int vec_sel (vector bool int,
- vector bool int,
- vector unsigned int);
- vector signed short vec_sel (vector signed short,
- vector signed short,
- vector bool short);
- vector signed short vec_sel (vector signed short,
- vector signed short,
- vector unsigned short);
- vector unsigned short vec_sel (vector unsigned short,
- vector unsigned short,
- vector bool short);
- vector unsigned short vec_sel (vector unsigned short,
- vector unsigned short,
- vector unsigned short);
- vector bool short vec_sel (vector bool short,
- vector bool short,
- vector bool short);
- vector bool short vec_sel (vector bool short,
- vector bool short,
- vector unsigned short);
- vector signed char vec_sel (vector signed char,
- vector signed char,
- vector bool char);
- vector signed char vec_sel (vector signed char,
- vector signed char,
- vector unsigned char);
- vector unsigned char vec_sel (vector unsigned char,
- vector unsigned char,
- vector bool char);
- vector unsigned char vec_sel (vector unsigned char,
- vector unsigned char,
- vector unsigned char);
- vector bool char vec_sel (vector bool char,
- vector bool char,
- vector bool char);
- vector bool char vec_sel (vector bool char,
- vector bool char,
- vector unsigned char);
-
- vector signed char vec_sl (vector signed char,
- vector unsigned char);
- vector unsigned char vec_sl (vector unsigned char,
- vector unsigned char);
- vector signed short vec_sl (vector signed short, vector unsigned short);
- vector unsigned short vec_sl (vector unsigned short,
- vector unsigned short);
- vector signed int vec_sl (vector signed int, vector unsigned int);
- vector unsigned int vec_sl (vector unsigned int, vector unsigned int);
-
- vector signed int vec_vslw (vector signed int, vector unsigned int);
- vector unsigned int vec_vslw (vector unsigned int, vector unsigned int);
-
- vector signed short vec_vslh (vector signed short,
- vector unsigned short);
- vector unsigned short vec_vslh (vector unsigned short,
- vector unsigned short);
-
- vector signed char vec_vslb (vector signed char, vector unsigned char);
- vector unsigned char vec_vslb (vector unsigned char,
- vector unsigned char);
-
- vector float vec_sld (vector float, vector float, const int);
- vector signed int vec_sld (vector signed int,
- vector signed int,
- const int);
- vector unsigned int vec_sld (vector unsigned int,
- vector unsigned int,
- const int);
- vector bool int vec_sld (vector bool int,
- vector bool int,
- const int);
- vector signed short vec_sld (vector signed short,
- vector signed short,
- const int);
- vector unsigned short vec_sld (vector unsigned short,
- vector unsigned short,
- const int);
- vector bool short vec_sld (vector bool short,
- vector bool short,
- const int);
- vector pixel vec_sld (vector pixel,
- vector pixel,
- const int);
- vector signed char vec_sld (vector signed char,
- vector signed char,
- const int);
- vector unsigned char vec_sld (vector unsigned char,
- vector unsigned char,
- const int);
- vector bool char vec_sld (vector bool char,
- vector bool char,
- const int);
-
- vector signed int vec_sll (vector signed int,
- vector unsigned int);
- vector signed int vec_sll (vector signed int,
- vector unsigned short);
- vector signed int vec_sll (vector signed int,
- vector unsigned char);
- vector unsigned int vec_sll (vector unsigned int,
- vector unsigned int);
- vector unsigned int vec_sll (vector unsigned int,
- vector unsigned short);
- vector unsigned int vec_sll (vector unsigned int,
- vector unsigned char);
- vector bool int vec_sll (vector bool int,
- vector unsigned int);
- vector bool int vec_sll (vector bool int,
- vector unsigned short);
- vector bool int vec_sll (vector bool int,
- vector unsigned char);
- vector signed short vec_sll (vector signed short,
- vector unsigned int);
- vector signed short vec_sll (vector signed short,
- vector unsigned short);
- vector signed short vec_sll (vector signed short,
- vector unsigned char);
- vector unsigned short vec_sll (vector unsigned short,
- vector unsigned int);
- vector unsigned short vec_sll (vector unsigned short,
- vector unsigned short);
- vector unsigned short vec_sll (vector unsigned short,
- vector unsigned char);
- vector bool short vec_sll (vector bool short, vector unsigned int);
- vector bool short vec_sll (vector bool short, vector unsigned short);
- vector bool short vec_sll (vector bool short, vector unsigned char);
- vector pixel vec_sll (vector pixel, vector unsigned int);
- vector pixel vec_sll (vector pixel, vector unsigned short);
- vector pixel vec_sll (vector pixel, vector unsigned char);
- vector signed char vec_sll (vector signed char, vector unsigned int);
- vector signed char vec_sll (vector signed char, vector unsigned short);
- vector signed char vec_sll (vector signed char, vector unsigned char);
- vector unsigned char vec_sll (vector unsigned char,
- vector unsigned int);
- vector unsigned char vec_sll (vector unsigned char,
- vector unsigned short);
- vector unsigned char vec_sll (vector unsigned char,
- vector unsigned char);
- vector bool char vec_sll (vector bool char, vector unsigned int);
- vector bool char vec_sll (vector bool char, vector unsigned short);
- vector bool char vec_sll (vector bool char, vector unsigned char);
-
- vector float vec_slo (vector float, vector signed char);
- vector float vec_slo (vector float, vector unsigned char);
- vector signed int vec_slo (vector signed int, vector signed char);
- vector signed int vec_slo (vector signed int, vector unsigned char);
- vector unsigned int vec_slo (vector unsigned int, vector signed char);
- vector unsigned int vec_slo (vector unsigned int, vector unsigned char);
- vector signed short vec_slo (vector signed short, vector signed char);
- vector signed short vec_slo (vector signed short, vector unsigned char);
- vector unsigned short vec_slo (vector unsigned short,
- vector signed char);
- vector unsigned short vec_slo (vector unsigned short,
- vector unsigned char);
- vector pixel vec_slo (vector pixel, vector signed char);
- vector pixel vec_slo (vector pixel, vector unsigned char);
- vector signed char vec_slo (vector signed char, vector signed char);
- vector signed char vec_slo (vector signed char, vector unsigned char);
- vector unsigned char vec_slo (vector unsigned char, vector signed char);
- vector unsigned char vec_slo (vector unsigned char,
- vector unsigned char);
-
- vector signed char vec_splat (vector signed char, const int);
- vector unsigned char vec_splat (vector unsigned char, const int);
- vector bool char vec_splat (vector bool char, const int);
- vector signed short vec_splat (vector signed short, const int);
- vector unsigned short vec_splat (vector unsigned short, const int);
- vector bool short vec_splat (vector bool short, const int);
- vector pixel vec_splat (vector pixel, const int);
- vector float vec_splat (vector float, const int);
- vector signed int vec_splat (vector signed int, const int);
- vector unsigned int vec_splat (vector unsigned int, const int);
- vector bool int vec_splat (vector bool int, const int);
-
- vector float vec_vspltw (vector float, const int);
- vector signed int vec_vspltw (vector signed int, const int);
- vector unsigned int vec_vspltw (vector unsigned int, const int);
- vector bool int vec_vspltw (vector bool int, const int);
-
- vector bool short vec_vsplth (vector bool short, const int);
- vector signed short vec_vsplth (vector signed short, const int);
- vector unsigned short vec_vsplth (vector unsigned short, const int);
- vector pixel vec_vsplth (vector pixel, const int);
-
- vector signed char vec_vspltb (vector signed char, const int);
- vector unsigned char vec_vspltb (vector unsigned char, const int);
- vector bool char vec_vspltb (vector bool char, const int);
-
- vector signed char vec_splat_s8 (const int);
-
- vector signed short vec_splat_s16 (const int);
-
- vector signed int vec_splat_s32 (const int);
-
- vector unsigned char vec_splat_u8 (const int);
-
- vector unsigned short vec_splat_u16 (const int);
-
- vector unsigned int vec_splat_u32 (const int);
-
- vector signed char vec_sr (vector signed char, vector unsigned char);
- vector unsigned char vec_sr (vector unsigned char,
- vector unsigned char);
- vector signed short vec_sr (vector signed short,
- vector unsigned short);
- vector unsigned short vec_sr (vector unsigned short,
- vector unsigned short);
- vector signed int vec_sr (vector signed int, vector unsigned int);
- vector unsigned int vec_sr (vector unsigned int, vector unsigned int);
-
- vector signed int vec_vsrw (vector signed int, vector unsigned int);
- vector unsigned int vec_vsrw (vector unsigned int, vector unsigned int);
-
- vector signed short vec_vsrh (vector signed short,
- vector unsigned short);
- vector unsigned short vec_vsrh (vector unsigned short,
- vector unsigned short);
-
- vector signed char vec_vsrb (vector signed char, vector unsigned char);
- vector unsigned char vec_vsrb (vector unsigned char,
- vector unsigned char);
-
- vector signed char vec_sra (vector signed char, vector unsigned char);
- vector unsigned char vec_sra (vector unsigned char,
- vector unsigned char);
- vector signed short vec_sra (vector signed short,
- vector unsigned short);
- vector unsigned short vec_sra (vector unsigned short,
- vector unsigned short);
- vector signed int vec_sra (vector signed int, vector unsigned int);
- vector unsigned int vec_sra (vector unsigned int, vector unsigned int);
-
- vector signed int vec_vsraw (vector signed int, vector unsigned int);
- vector unsigned int vec_vsraw (vector unsigned int,
- vector unsigned int);
-
- vector signed short vec_vsrah (vector signed short,
- vector unsigned short);
- vector unsigned short vec_vsrah (vector unsigned short,
- vector unsigned short);
-
- vector signed char vec_vsrab (vector signed char, vector unsigned char);
- vector unsigned char vec_vsrab (vector unsigned char,
- vector unsigned char);
-
- vector signed int vec_srl (vector signed int, vector unsigned int);
- vector signed int vec_srl (vector signed int, vector unsigned short);
- vector signed int vec_srl (vector signed int, vector unsigned char);
- vector unsigned int vec_srl (vector unsigned int, vector unsigned int);
- vector unsigned int vec_srl (vector unsigned int,
- vector unsigned short);
- vector unsigned int vec_srl (vector unsigned int, vector unsigned char);
- vector bool int vec_srl (vector bool int, vector unsigned int);
- vector bool int vec_srl (vector bool int, vector unsigned short);
- vector bool int vec_srl (vector bool int, vector unsigned char);
- vector signed short vec_srl (vector signed short, vector unsigned int);
- vector signed short vec_srl (vector signed short,
- vector unsigned short);
- vector signed short vec_srl (vector signed short, vector unsigned char);
- vector unsigned short vec_srl (vector unsigned short,
- vector unsigned int);
- vector unsigned short vec_srl (vector unsigned short,
- vector unsigned short);
- vector unsigned short vec_srl (vector unsigned short,
- vector unsigned char);
- vector bool short vec_srl (vector bool short, vector unsigned int);
- vector bool short vec_srl (vector bool short, vector unsigned short);
- vector bool short vec_srl (vector bool short, vector unsigned char);
- vector pixel vec_srl (vector pixel, vector unsigned int);
- vector pixel vec_srl (vector pixel, vector unsigned short);
- vector pixel vec_srl (vector pixel, vector unsigned char);
- vector signed char vec_srl (vector signed char, vector unsigned int);
- vector signed char vec_srl (vector signed char, vector unsigned short);
- vector signed char vec_srl (vector signed char, vector unsigned char);
- vector unsigned char vec_srl (vector unsigned char,
- vector unsigned int);
- vector unsigned char vec_srl (vector unsigned char,
- vector unsigned short);
- vector unsigned char vec_srl (vector unsigned char,
- vector unsigned char);
- vector bool char vec_srl (vector bool char, vector unsigned int);
- vector bool char vec_srl (vector bool char, vector unsigned short);
- vector bool char vec_srl (vector bool char, vector unsigned char);
-
- vector float vec_sro (vector float, vector signed char);
- vector float vec_sro (vector float, vector unsigned char);
- vector signed int vec_sro (vector signed int, vector signed char);
- vector signed int vec_sro (vector signed int, vector unsigned char);
- vector unsigned int vec_sro (vector unsigned int, vector signed char);
- vector unsigned int vec_sro (vector unsigned int, vector unsigned char);
- vector signed short vec_sro (vector signed short, vector signed char);
- vector signed short vec_sro (vector signed short, vector unsigned char);
- vector unsigned short vec_sro (vector unsigned short,
- vector signed char);
- vector unsigned short vec_sro (vector unsigned short,
- vector unsigned char);
- vector pixel vec_sro (vector pixel, vector signed char);
- vector pixel vec_sro (vector pixel, vector unsigned char);
- vector signed char vec_sro (vector signed char, vector signed char);
- vector signed char vec_sro (vector signed char, vector unsigned char);
- vector unsigned char vec_sro (vector unsigned char, vector signed char);
- vector unsigned char vec_sro (vector unsigned char,
- vector unsigned char);
-
- void vec_st (vector float, int, vector float *);
- void vec_st (vector float, int, float *);
- void vec_st (vector signed int, int, vector signed int *);
- void vec_st (vector signed int, int, int *);
- void vec_st (vector unsigned int, int, vector unsigned int *);
- void vec_st (vector unsigned int, int, unsigned int *);
- void vec_st (vector bool int, int, vector bool int *);
- void vec_st (vector bool int, int, unsigned int *);
- void vec_st (vector bool int, int, int *);
- void vec_st (vector signed short, int, vector signed short *);
- void vec_st (vector signed short, int, short *);
- void vec_st (vector unsigned short, int, vector unsigned short *);
- void vec_st (vector unsigned short, int, unsigned short *);
- void vec_st (vector bool short, int, vector bool short *);
- void vec_st (vector bool short, int, unsigned short *);
- void vec_st (vector pixel, int, vector pixel *);
- void vec_st (vector pixel, int, unsigned short *);
- void vec_st (vector pixel, int, short *);
- void vec_st (vector bool short, int, short *);
- void vec_st (vector signed char, int, vector signed char *);
- void vec_st (vector signed char, int, signed char *);
- void vec_st (vector unsigned char, int, vector unsigned char *);
- void vec_st (vector unsigned char, int, unsigned char *);
- void vec_st (vector bool char, int, vector bool char *);
- void vec_st (vector bool char, int, unsigned char *);
- void vec_st (vector bool char, int, signed char *);
-
- void vec_ste (vector signed char, int, signed char *);
- void vec_ste (vector unsigned char, int, unsigned char *);
- void vec_ste (vector bool char, int, signed char *);
- void vec_ste (vector bool char, int, unsigned char *);
- void vec_ste (vector signed short, int, short *);
- void vec_ste (vector unsigned short, int, unsigned short *);
- void vec_ste (vector bool short, int, short *);
- void vec_ste (vector bool short, int, unsigned short *);
- void vec_ste (vector pixel, int, short *);
- void vec_ste (vector pixel, int, unsigned short *);
- void vec_ste (vector float, int, float *);
- void vec_ste (vector signed int, int, int *);
- void vec_ste (vector unsigned int, int, unsigned int *);
- void vec_ste (vector bool int, int, int *);
- void vec_ste (vector bool int, int, unsigned int *);
-
- void vec_stvewx (vector float, int, float *);
- void vec_stvewx (vector signed int, int, int *);
- void vec_stvewx (vector unsigned int, int, unsigned int *);
- void vec_stvewx (vector bool int, int, int *);
- void vec_stvewx (vector bool int, int, unsigned int *);
-
- void vec_stvehx (vector signed short, int, short *);
- void vec_stvehx (vector unsigned short, int, unsigned short *);
- void vec_stvehx (vector bool short, int, short *);
- void vec_stvehx (vector bool short, int, unsigned short *);
- void vec_stvehx (vector pixel, int, short *);
- void vec_stvehx (vector pixel, int, unsigned short *);
-
- void vec_stvebx (vector signed char, int, signed char *);
- void vec_stvebx (vector unsigned char, int, unsigned char *);
- void vec_stvebx (vector bool char, int, signed char *);
- void vec_stvebx (vector bool char, int, unsigned char *);
-
- void vec_stl (vector float, int, vector float *);
- void vec_stl (vector float, int, float *);
- void vec_stl (vector signed int, int, vector signed int *);
- void vec_stl (vector signed int, int, int *);
- void vec_stl (vector unsigned int, int, vector unsigned int *);
- void vec_stl (vector unsigned int, int, unsigned int *);
- void vec_stl (vector bool int, int, vector bool int *);
- void vec_stl (vector bool int, int, unsigned int *);
- void vec_stl (vector bool int, int, int *);
- void vec_stl (vector signed short, int, vector signed short *);
- void vec_stl (vector signed short, int, short *);
- void vec_stl (vector unsigned short, int, vector unsigned short *);
- void vec_stl (vector unsigned short, int, unsigned short *);
- void vec_stl (vector bool short, int, vector bool short *);
- void vec_stl (vector bool short, int, unsigned short *);
- void vec_stl (vector bool short, int, short *);
- void vec_stl (vector pixel, int, vector pixel *);
- void vec_stl (vector pixel, int, unsigned short *);
- void vec_stl (vector pixel, int, short *);
- void vec_stl (vector signed char, int, vector signed char *);
- void vec_stl (vector signed char, int, signed char *);
- void vec_stl (vector unsigned char, int, vector unsigned char *);
- void vec_stl (vector unsigned char, int, unsigned char *);
- void vec_stl (vector bool char, int, vector bool char *);
- void vec_stl (vector bool char, int, unsigned char *);
- void vec_stl (vector bool char, int, signed char *);
-
- vector signed char vec_sub (vector bool char, vector signed char);
- vector signed char vec_sub (vector signed char, vector bool char);
- vector signed char vec_sub (vector signed char, vector signed char);
- vector unsigned char vec_sub (vector bool char, vector unsigned char);
- vector unsigned char vec_sub (vector unsigned char, vector bool char);
- vector unsigned char vec_sub (vector unsigned char,
- vector unsigned char);
- vector signed short vec_sub (vector bool short, vector signed short);
- vector signed short vec_sub (vector signed short, vector bool short);
- vector signed short vec_sub (vector signed short, vector signed short);
- vector unsigned short vec_sub (vector bool short,
- vector unsigned short);
- vector unsigned short vec_sub (vector unsigned short,
- vector bool short);
- vector unsigned short vec_sub (vector unsigned short,
- vector unsigned short);
- vector signed int vec_sub (vector bool int, vector signed int);
- vector signed int vec_sub (vector signed int, vector bool int);
- vector signed int vec_sub (vector signed int, vector signed int);
- vector unsigned int vec_sub (vector bool int, vector unsigned int);
- vector unsigned int vec_sub (vector unsigned int, vector bool int);
- vector unsigned int vec_sub (vector unsigned int, vector unsigned int);
- vector float vec_sub (vector float, vector float);
-
- vector float vec_vsubfp (vector float, vector float);
-
- vector signed int vec_vsubuwm (vector bool int, vector signed int);
- vector signed int vec_vsubuwm (vector signed int, vector bool int);
- vector signed int vec_vsubuwm (vector signed int, vector signed int);
- vector unsigned int vec_vsubuwm (vector bool int, vector unsigned int);
- vector unsigned int vec_vsubuwm (vector unsigned int, vector bool int);
- vector unsigned int vec_vsubuwm (vector unsigned int,
- vector unsigned int);
-
- vector signed short vec_vsubuhm (vector bool short,
- vector signed short);
- vector signed short vec_vsubuhm (vector signed short,
- vector bool short);
- vector signed short vec_vsubuhm (vector signed short,
- vector signed short);
- vector unsigned short vec_vsubuhm (vector bool short,
- vector unsigned short);
- vector unsigned short vec_vsubuhm (vector unsigned short,
- vector bool short);
- vector unsigned short vec_vsubuhm (vector unsigned short,
- vector unsigned short);
-
- vector signed char vec_vsububm (vector bool char, vector signed char);
- vector signed char vec_vsububm (vector signed char, vector bool char);
- vector signed char vec_vsububm (vector signed char, vector signed char);
- vector unsigned char vec_vsububm (vector bool char,
- vector unsigned char);
- vector unsigned char vec_vsububm (vector unsigned char,
- vector bool char);
- vector unsigned char vec_vsububm (vector unsigned char,
- vector unsigned char);
-
- vector unsigned int vec_subc (vector unsigned int, vector unsigned int);
-
- vector unsigned char vec_subs (vector bool char, vector unsigned char);
- vector unsigned char vec_subs (vector unsigned char, vector bool char);
- vector unsigned char vec_subs (vector unsigned char,
- vector unsigned char);
- vector signed char vec_subs (vector bool char, vector signed char);
- vector signed char vec_subs (vector signed char, vector bool char);
- vector signed char vec_subs (vector signed char, vector signed char);
- vector unsigned short vec_subs (vector bool short,
- vector unsigned short);
- vector unsigned short vec_subs (vector unsigned short,
- vector bool short);
- vector unsigned short vec_subs (vector unsigned short,
- vector unsigned short);
- vector signed short vec_subs (vector bool short, vector signed short);
- vector signed short vec_subs (vector signed short, vector bool short);
- vector signed short vec_subs (vector signed short, vector signed short);
- vector unsigned int vec_subs (vector bool int, vector unsigned int);
- vector unsigned int vec_subs (vector unsigned int, vector bool int);
- vector unsigned int vec_subs (vector unsigned int, vector unsigned int);
- vector signed int vec_subs (vector bool int, vector signed int);
- vector signed int vec_subs (vector signed int, vector bool int);
- vector signed int vec_subs (vector signed int, vector signed int);
-
- vector signed int vec_vsubsws (vector bool int, vector signed int);
- vector signed int vec_vsubsws (vector signed int, vector bool int);
- vector signed int vec_vsubsws (vector signed int, vector signed int);
-
- vector unsigned int vec_vsubuws (vector bool int, vector unsigned int);
- vector unsigned int vec_vsubuws (vector unsigned int, vector bool int);
- vector unsigned int vec_vsubuws (vector unsigned int,
- vector unsigned int);
-
- vector signed short vec_vsubshs (vector bool short,
- vector signed short);
- vector signed short vec_vsubshs (vector signed short,
- vector bool short);
- vector signed short vec_vsubshs (vector signed short,
- vector signed short);
-
- vector unsigned short vec_vsubuhs (vector bool short,
- vector unsigned short);
- vector unsigned short vec_vsubuhs (vector unsigned short,
- vector bool short);
- vector unsigned short vec_vsubuhs (vector unsigned short,
- vector unsigned short);
-
- vector signed char vec_vsubsbs (vector bool char, vector signed char);
- vector signed char vec_vsubsbs (vector signed char, vector bool char);
- vector signed char vec_vsubsbs (vector signed char, vector signed char);
-
- vector unsigned char vec_vsububs (vector bool char,
- vector unsigned char);
- vector unsigned char vec_vsububs (vector unsigned char,
- vector bool char);
- vector unsigned char vec_vsububs (vector unsigned char,
- vector unsigned char);
-
- vector unsigned int vec_sum4s (vector unsigned char,
- vector unsigned int);
- vector signed int vec_sum4s (vector signed char, vector signed int);
- vector signed int vec_sum4s (vector signed short, vector signed int);
-
- vector signed int vec_vsum4shs (vector signed short, vector signed int);
-
- vector signed int vec_vsum4sbs (vector signed char, vector signed int);
-
- vector unsigned int vec_vsum4ubs (vector unsigned char,
- vector unsigned int);
-
- vector signed int vec_sum2s (vector signed int, vector signed int);
-
- vector signed int vec_sums (vector signed int, vector signed int);
-
- vector float vec_trunc (vector float);
-
- vector signed short vec_unpackh (vector signed char);
- vector bool short vec_unpackh (vector bool char);
- vector signed int vec_unpackh (vector signed short);
- vector bool int vec_unpackh (vector bool short);
- vector unsigned int vec_unpackh (vector pixel);
-
- vector bool int vec_vupkhsh (vector bool short);
- vector signed int vec_vupkhsh (vector signed short);
-
- vector unsigned int vec_vupkhpx (vector pixel);
-
- vector bool short vec_vupkhsb (vector bool char);
- vector signed short vec_vupkhsb (vector signed char);
-
- vector signed short vec_unpackl (vector signed char);
- vector bool short vec_unpackl (vector bool char);
- vector unsigned int vec_unpackl (vector pixel);
- vector signed int vec_unpackl (vector signed short);
- vector bool int vec_unpackl (vector bool short);
-
- vector unsigned int vec_vupklpx (vector pixel);
-
- vector bool int vec_vupklsh (vector bool short);
- vector signed int vec_vupklsh (vector signed short);
-
- vector bool short vec_vupklsb (vector bool char);
- vector signed short vec_vupklsb (vector signed char);
-
- vector float vec_xor (vector float, vector float);
- vector float vec_xor (vector float, vector bool int);
- vector float vec_xor (vector bool int, vector float);
- vector bool int vec_xor (vector bool int, vector bool int);
- vector signed int vec_xor (vector bool int, vector signed int);
- vector signed int vec_xor (vector signed int, vector bool int);
- vector signed int vec_xor (vector signed int, vector signed int);
- vector unsigned int vec_xor (vector bool int, vector unsigned int);
- vector unsigned int vec_xor (vector unsigned int, vector bool int);
- vector unsigned int vec_xor (vector unsigned int, vector unsigned int);
- vector bool short vec_xor (vector bool short, vector bool short);
- vector signed short vec_xor (vector bool short, vector signed short);
- vector signed short vec_xor (vector signed short, vector bool short);
- vector signed short vec_xor (vector signed short, vector signed short);
- vector unsigned short vec_xor (vector bool short,
- vector unsigned short);
- vector unsigned short vec_xor (vector unsigned short,
- vector bool short);
- vector unsigned short vec_xor (vector unsigned short,
- vector unsigned short);
- vector signed char vec_xor (vector bool char, vector signed char);
- vector bool char vec_xor (vector bool char, vector bool char);
- vector signed char vec_xor (vector signed char, vector bool char);
- vector signed char vec_xor (vector signed char, vector signed char);
- vector unsigned char vec_xor (vector bool char, vector unsigned char);
- vector unsigned char vec_xor (vector unsigned char, vector bool char);
- vector unsigned char vec_xor (vector unsigned char,
- vector unsigned char);
-
- int vec_all_eq (vector signed char, vector bool char);
- int vec_all_eq (vector signed char, vector signed char);
- int vec_all_eq (vector unsigned char, vector bool char);
- int vec_all_eq (vector unsigned char, vector unsigned char);
- int vec_all_eq (vector bool char, vector bool char);
- int vec_all_eq (vector bool char, vector unsigned char);
- int vec_all_eq (vector bool char, vector signed char);
- int vec_all_eq (vector signed short, vector bool short);
- int vec_all_eq (vector signed short, vector signed short);
- int vec_all_eq (vector unsigned short, vector bool short);
- int vec_all_eq (vector unsigned short, vector unsigned short);
- int vec_all_eq (vector bool short, vector bool short);
- int vec_all_eq (vector bool short, vector unsigned short);
- int vec_all_eq (vector bool short, vector signed short);
- int vec_all_eq (vector pixel, vector pixel);
- int vec_all_eq (vector signed int, vector bool int);
- int vec_all_eq (vector signed int, vector signed int);
- int vec_all_eq (vector unsigned int, vector bool int);
- int vec_all_eq (vector unsigned int, vector unsigned int);
- int vec_all_eq (vector bool int, vector bool int);
- int vec_all_eq (vector bool int, vector unsigned int);
- int vec_all_eq (vector bool int, vector signed int);
- int vec_all_eq (vector float, vector float);
-
- int vec_all_ge (vector bool char, vector unsigned char);
- int vec_all_ge (vector unsigned char, vector bool char);
- int vec_all_ge (vector unsigned char, vector unsigned char);
- int vec_all_ge (vector bool char, vector signed char);
- int vec_all_ge (vector signed char, vector bool char);
- int vec_all_ge (vector signed char, vector signed char);
- int vec_all_ge (vector bool short, vector unsigned short);
- int vec_all_ge (vector unsigned short, vector bool short);
- int vec_all_ge (vector unsigned short, vector unsigned short);
- int vec_all_ge (vector signed short, vector signed short);
- int vec_all_ge (vector bool short, vector signed short);
- int vec_all_ge (vector signed short, vector bool short);
- int vec_all_ge (vector bool int, vector unsigned int);
- int vec_all_ge (vector unsigned int, vector bool int);
- int vec_all_ge (vector unsigned int, vector unsigned int);
- int vec_all_ge (vector bool int, vector signed int);
- int vec_all_ge (vector signed int, vector bool int);
- int vec_all_ge (vector signed int, vector signed int);
- int vec_all_ge (vector float, vector float);
-
- int vec_all_gt (vector bool char, vector unsigned char);
- int vec_all_gt (vector unsigned char, vector bool char);
- int vec_all_gt (vector unsigned char, vector unsigned char);
- int vec_all_gt (vector bool char, vector signed char);
- int vec_all_gt (vector signed char, vector bool char);
- int vec_all_gt (vector signed char, vector signed char);
- int vec_all_gt (vector bool short, vector unsigned short);
- int vec_all_gt (vector unsigned short, vector bool short);
- int vec_all_gt (vector unsigned short, vector unsigned short);
- int vec_all_gt (vector bool short, vector signed short);
- int vec_all_gt (vector signed short, vector bool short);
- int vec_all_gt (vector signed short, vector signed short);
- int vec_all_gt (vector bool int, vector unsigned int);
- int vec_all_gt (vector unsigned int, vector bool int);
- int vec_all_gt (vector unsigned int, vector unsigned int);
- int vec_all_gt (vector bool int, vector signed int);
- int vec_all_gt (vector signed int, vector bool int);
- int vec_all_gt (vector signed int, vector signed int);
- int vec_all_gt (vector float, vector float);
-
- int vec_all_in (vector float, vector float);
-
- int vec_all_le (vector bool char, vector unsigned char);
- int vec_all_le (vector unsigned char, vector bool char);
- int vec_all_le (vector unsigned char, vector unsigned char);
- int vec_all_le (vector bool char, vector signed char);
- int vec_all_le (vector signed char, vector bool char);
- int vec_all_le (vector signed char, vector signed char);
- int vec_all_le (vector bool short, vector unsigned short);
- int vec_all_le (vector unsigned short, vector bool short);
- int vec_all_le (vector unsigned short, vector unsigned short);
- int vec_all_le (vector bool short, vector signed short);
- int vec_all_le (vector signed short, vector bool short);
- int vec_all_le (vector signed short, vector signed short);
- int vec_all_le (vector bool int, vector unsigned int);
- int vec_all_le (vector unsigned int, vector bool int);
- int vec_all_le (vector unsigned int, vector unsigned int);
- int vec_all_le (vector bool int, vector signed int);
- int vec_all_le (vector signed int, vector bool int);
- int vec_all_le (vector signed int, vector signed int);
- int vec_all_le (vector float, vector float);
-
- int vec_all_lt (vector bool char, vector unsigned char);
- int vec_all_lt (vector unsigned char, vector bool char);
- int vec_all_lt (vector unsigned char, vector unsigned char);
- int vec_all_lt (vector bool char, vector signed char);
- int vec_all_lt (vector signed char, vector bool char);
- int vec_all_lt (vector signed char, vector signed char);
- int vec_all_lt (vector bool short, vector unsigned short);
- int vec_all_lt (vector unsigned short, vector bool short);
- int vec_all_lt (vector unsigned short, vector unsigned short);
- int vec_all_lt (vector bool short, vector signed short);
- int vec_all_lt (vector signed short, vector bool short);
- int vec_all_lt (vector signed short, vector signed short);
- int vec_all_lt (vector bool int, vector unsigned int);
- int vec_all_lt (vector unsigned int, vector bool int);
- int vec_all_lt (vector unsigned int, vector unsigned int);
- int vec_all_lt (vector bool int, vector signed int);
- int vec_all_lt (vector signed int, vector bool int);
- int vec_all_lt (vector signed int, vector signed int);
- int vec_all_lt (vector float, vector float);
-
- int vec_all_nan (vector float);
-
- int vec_all_ne (vector signed char, vector bool char);
- int vec_all_ne (vector signed char, vector signed char);
- int vec_all_ne (vector unsigned char, vector bool char);
- int vec_all_ne (vector unsigned char, vector unsigned char);
- int vec_all_ne (vector bool char, vector bool char);
- int vec_all_ne (vector bool char, vector unsigned char);
- int vec_all_ne (vector bool char, vector signed char);
- int vec_all_ne (vector signed short, vector bool short);
- int vec_all_ne (vector signed short, vector signed short);
- int vec_all_ne (vector unsigned short, vector bool short);
- int vec_all_ne (vector unsigned short, vector unsigned short);
- int vec_all_ne (vector bool short, vector bool short);
- int vec_all_ne (vector bool short, vector unsigned short);
- int vec_all_ne (vector bool short, vector signed short);
- int vec_all_ne (vector pixel, vector pixel);
- int vec_all_ne (vector signed int, vector bool int);
- int vec_all_ne (vector signed int, vector signed int);
- int vec_all_ne (vector unsigned int, vector bool int);
- int vec_all_ne (vector unsigned int, vector unsigned int);
- int vec_all_ne (vector bool int, vector bool int);
- int vec_all_ne (vector bool int, vector unsigned int);
- int vec_all_ne (vector bool int, vector signed int);
- int vec_all_ne (vector float, vector float);
-
- int vec_all_nge (vector float, vector float);
-
- int vec_all_ngt (vector float, vector float);
-
- int vec_all_nle (vector float, vector float);
-
- int vec_all_nlt (vector float, vector float);
-
- int vec_all_numeric (vector float);
-
- int vec_any_eq (vector signed char, vector bool char);
- int vec_any_eq (vector signed char, vector signed char);
- int vec_any_eq (vector unsigned char, vector bool char);
- int vec_any_eq (vector unsigned char, vector unsigned char);
- int vec_any_eq (vector bool char, vector bool char);
- int vec_any_eq (vector bool char, vector unsigned char);
- int vec_any_eq (vector bool char, vector signed char);
- int vec_any_eq (vector signed short, vector bool short);
- int vec_any_eq (vector signed short, vector signed short);
- int vec_any_eq (vector unsigned short, vector bool short);
- int vec_any_eq (vector unsigned short, vector unsigned short);
- int vec_any_eq (vector bool short, vector bool short);
- int vec_any_eq (vector bool short, vector unsigned short);
- int vec_any_eq (vector bool short, vector signed short);
- int vec_any_eq (vector pixel, vector pixel);
- int vec_any_eq (vector signed int, vector bool int);
- int vec_any_eq (vector signed int, vector signed int);
- int vec_any_eq (vector unsigned int, vector bool int);
- int vec_any_eq (vector unsigned int, vector unsigned int);
- int vec_any_eq (vector bool int, vector bool int);
- int vec_any_eq (vector bool int, vector unsigned int);
- int vec_any_eq (vector bool int, vector signed int);
- int vec_any_eq (vector float, vector float);
-
- int vec_any_ge (vector signed char, vector bool char);
- int vec_any_ge (vector unsigned char, vector bool char);
- int vec_any_ge (vector unsigned char, vector unsigned char);
- int vec_any_ge (vector signed char, vector signed char);
- int vec_any_ge (vector bool char, vector unsigned char);
- int vec_any_ge (vector bool char, vector signed char);
- int vec_any_ge (vector unsigned short, vector bool short);
- int vec_any_ge (vector unsigned short, vector unsigned short);
- int vec_any_ge (vector signed short, vector signed short);
- int vec_any_ge (vector signed short, vector bool short);
- int vec_any_ge (vector bool short, vector unsigned short);
- int vec_any_ge (vector bool short, vector signed short);
- int vec_any_ge (vector signed int, vector bool int);
- int vec_any_ge (vector unsigned int, vector bool int);
- int vec_any_ge (vector unsigned int, vector unsigned int);
- int vec_any_ge (vector signed int, vector signed int);
- int vec_any_ge (vector bool int, vector unsigned int);
- int vec_any_ge (vector bool int, vector signed int);
- int vec_any_ge (vector float, vector float);
-
- int vec_any_gt (vector bool char, vector unsigned char);
- int vec_any_gt (vector unsigned char, vector bool char);
- int vec_any_gt (vector unsigned char, vector unsigned char);
- int vec_any_gt (vector bool char, vector signed char);
- int vec_any_gt (vector signed char, vector bool char);
- int vec_any_gt (vector signed char, vector signed char);
- int vec_any_gt (vector bool short, vector unsigned short);
- int vec_any_gt (vector unsigned short, vector bool short);
- int vec_any_gt (vector unsigned short, vector unsigned short);
- int vec_any_gt (vector bool short, vector signed short);
- int vec_any_gt (vector signed short, vector bool short);
- int vec_any_gt (vector signed short, vector signed short);
- int vec_any_gt (vector bool int, vector unsigned int);
- int vec_any_gt (vector unsigned int, vector bool int);
- int vec_any_gt (vector unsigned int, vector unsigned int);
- int vec_any_gt (vector bool int, vector signed int);
- int vec_any_gt (vector signed int, vector bool int);
- int vec_any_gt (vector signed int, vector signed int);
- int vec_any_gt (vector float, vector float);
-
- int vec_any_le (vector bool char, vector unsigned char);
- int vec_any_le (vector unsigned char, vector bool char);
- int vec_any_le (vector unsigned char, vector unsigned char);
- int vec_any_le (vector bool char, vector signed char);
- int vec_any_le (vector signed char, vector bool char);
- int vec_any_le (vector signed char, vector signed char);
- int vec_any_le (vector bool short, vector unsigned short);
- int vec_any_le (vector unsigned short, vector bool short);
- int vec_any_le (vector unsigned short, vector unsigned short);
- int vec_any_le (vector bool short, vector signed short);
- int vec_any_le (vector signed short, vector bool short);
- int vec_any_le (vector signed short, vector signed short);
- int vec_any_le (vector bool int, vector unsigned int);
- int vec_any_le (vector unsigned int, vector bool int);
- int vec_any_le (vector unsigned int, vector unsigned int);
- int vec_any_le (vector bool int, vector signed int);
- int vec_any_le (vector signed int, vector bool int);
- int vec_any_le (vector signed int, vector signed int);
- int vec_any_le (vector float, vector float);
-
- int vec_any_lt (vector bool char, vector unsigned char);
- int vec_any_lt (vector unsigned char, vector bool char);
- int vec_any_lt (vector unsigned char, vector unsigned char);
- int vec_any_lt (vector bool char, vector signed char);
- int vec_any_lt (vector signed char, vector bool char);
- int vec_any_lt (vector signed char, vector signed char);
- int vec_any_lt (vector bool short, vector unsigned short);
- int vec_any_lt (vector unsigned short, vector bool short);
- int vec_any_lt (vector unsigned short, vector unsigned short);
- int vec_any_lt (vector bool short, vector signed short);
- int vec_any_lt (vector signed short, vector bool short);
- int vec_any_lt (vector signed short, vector signed short);
- int vec_any_lt (vector bool int, vector unsigned int);
- int vec_any_lt (vector unsigned int, vector bool int);
- int vec_any_lt (vector unsigned int, vector unsigned int);
- int vec_any_lt (vector bool int, vector signed int);
- int vec_any_lt (vector signed int, vector bool int);
- int vec_any_lt (vector signed int, vector signed int);
- int vec_any_lt (vector float, vector float);
-
- int vec_any_nan (vector float);
-
- int vec_any_ne (vector signed char, vector bool char);
- int vec_any_ne (vector signed char, vector signed char);
- int vec_any_ne (vector unsigned char, vector bool char);
- int vec_any_ne (vector unsigned char, vector unsigned char);
- int vec_any_ne (vector bool char, vector bool char);
- int vec_any_ne (vector bool char, vector unsigned char);
- int vec_any_ne (vector bool char, vector signed char);
- int vec_any_ne (vector signed short, vector bool short);
- int vec_any_ne (vector signed short, vector signed short);
- int vec_any_ne (vector unsigned short, vector bool short);
- int vec_any_ne (vector unsigned short, vector unsigned short);
- int vec_any_ne (vector bool short, vector bool short);
- int vec_any_ne (vector bool short, vector unsigned short);
- int vec_any_ne (vector bool short, vector signed short);
- int vec_any_ne (vector pixel, vector pixel);
- int vec_any_ne (vector signed int, vector bool int);
- int vec_any_ne (vector signed int, vector signed int);
- int vec_any_ne (vector unsigned int, vector bool int);
- int vec_any_ne (vector unsigned int, vector unsigned int);
- int vec_any_ne (vector bool int, vector bool int);
- int vec_any_ne (vector bool int, vector unsigned int);
- int vec_any_ne (vector bool int, vector signed int);
- int vec_any_ne (vector float, vector float);
-
- int vec_any_nge (vector float, vector float);
-
- int vec_any_ngt (vector float, vector float);
-
- int vec_any_nle (vector float, vector float);
-
- int vec_any_nlt (vector float, vector float);
-
- int vec_any_numeric (vector float);
-
- int vec_any_out (vector float, vector float);
-
- If the vector/scalar (VSX) instruction set is available, the following
-additional functions are available:
-
- vector double vec_abs (vector double);
- vector double vec_add (vector double, vector double);
- vector double vec_and (vector double, vector double);
- vector double vec_and (vector double, vector bool long);
- vector double vec_and (vector bool long, vector double);
- vector double vec_andc (vector double, vector double);
- vector double vec_andc (vector double, vector bool long);
- vector double vec_andc (vector bool long, vector double);
- vector double vec_ceil (vector double);
- vector bool long vec_cmpeq (vector double, vector double);
- vector bool long vec_cmpge (vector double, vector double);
- vector bool long vec_cmpgt (vector double, vector double);
- vector bool long vec_cmple (vector double, vector double);
- vector bool long vec_cmplt (vector double, vector double);
- vector float vec_div (vector float, vector float);
- vector double vec_div (vector double, vector double);
- vector double vec_floor (vector double);
- vector double vec_ld (int, const vector double *);
- vector double vec_ld (int, const double *);
- vector double vec_ldl (int, const vector double *);
- vector double vec_ldl (int, const double *);
- vector unsigned char vec_lvsl (int, const volatile double *);
- vector unsigned char vec_lvsr (int, const volatile double *);
- vector double vec_madd (vector double, vector double, vector double);
- vector double vec_max (vector double, vector double);
- vector double vec_min (vector double, vector double);
- vector float vec_msub (vector float, vector float, vector float);
- vector double vec_msub (vector double, vector double, vector double);
- vector float vec_mul (vector float, vector float);
- vector double vec_mul (vector double, vector double);
- vector float vec_nearbyint (vector float);
- vector double vec_nearbyint (vector double);
- vector float vec_nmadd (vector float, vector float, vector float);
- vector double vec_nmadd (vector double, vector double, vector double);
- vector double vec_nmsub (vector double, vector double, vector double);
- vector double vec_nor (vector double, vector double);
- vector double vec_or (vector double, vector double);
- vector double vec_or (vector double, vector bool long);
- vector double vec_or (vector bool long, vector double);
- vector double vec_perm (vector double,
- vector double,
- vector unsigned char);
- vector double vec_rint (vector double);
- vector double vec_recip (vector double, vector double);
- vector double vec_rsqrt (vector double);
- vector double vec_rsqrte (vector double);
- vector double vec_sel (vector double, vector double, vector bool long);
- vector double vec_sel (vector double, vector double, vector unsigned long);
- vector double vec_sub (vector double, vector double);
- vector float vec_sqrt (vector float);
- vector double vec_sqrt (vector double);
- void vec_st (vector double, int, vector double *);
- void vec_st (vector double, int, double *);
- vector double vec_trunc (vector double);
- vector double vec_xor (vector double, vector double);
- vector double vec_xor (vector double, vector bool long);
- vector double vec_xor (vector bool long, vector double);
- int vec_all_eq (vector double, vector double);
- int vec_all_ge (vector double, vector double);
- int vec_all_gt (vector double, vector double);
- int vec_all_le (vector double, vector double);
- int vec_all_lt (vector double, vector double);
- int vec_all_nan (vector double);
- int vec_all_ne (vector double, vector double);
- int vec_all_nge (vector double, vector double);
- int vec_all_ngt (vector double, vector double);
- int vec_all_nle (vector double, vector double);
- int vec_all_nlt (vector double, vector double);
- int vec_all_numeric (vector double);
- int vec_any_eq (vector double, vector double);
- int vec_any_ge (vector double, vector double);
- int vec_any_gt (vector double, vector double);
- int vec_any_le (vector double, vector double);
- int vec_any_lt (vector double, vector double);
- int vec_any_nan (vector double);
- int vec_any_ne (vector double, vector double);
- int vec_any_nge (vector double, vector double);
- int vec_any_ngt (vector double, vector double);
- int vec_any_nle (vector double, vector double);
- int vec_any_nlt (vector double, vector double);
- int vec_any_numeric (vector double);
-
- vector double vec_vsx_ld (int, const vector double *);
- vector double vec_vsx_ld (int, const double *);
- vector float vec_vsx_ld (int, const vector float *);
- vector float vec_vsx_ld (int, const float *);
- vector bool int vec_vsx_ld (int, const vector bool int *);
- vector signed int vec_vsx_ld (int, const vector signed int *);
- vector signed int vec_vsx_ld (int, const int *);
- vector signed int vec_vsx_ld (int, const long *);
- vector unsigned int vec_vsx_ld (int, const vector unsigned int *);
- vector unsigned int vec_vsx_ld (int, const unsigned int *);
- vector unsigned int vec_vsx_ld (int, const unsigned long *);
- vector bool short vec_vsx_ld (int, const vector bool short *);
- vector pixel vec_vsx_ld (int, const vector pixel *);
- vector signed short vec_vsx_ld (int, const vector signed short *);
- vector signed short vec_vsx_ld (int, const short *);
- vector unsigned short vec_vsx_ld (int, const vector unsigned short *);
- vector unsigned short vec_vsx_ld (int, const unsigned short *);
- vector bool char vec_vsx_ld (int, const vector bool char *);
- vector signed char vec_vsx_ld (int, const vector signed char *);
- vector signed char vec_vsx_ld (int, const signed char *);
- vector unsigned char vec_vsx_ld (int, const vector unsigned char *);
- vector unsigned char vec_vsx_ld (int, const unsigned char *);
-
- void vec_vsx_st (vector double, int, vector double *);
- void vec_vsx_st (vector double, int, double *);
- void vec_vsx_st (vector float, int, vector float *);
- void vec_vsx_st (vector float, int, float *);
- void vec_vsx_st (vector signed int, int, vector signed int *);
- void vec_vsx_st (vector signed int, int, int *);
- void vec_vsx_st (vector unsigned int, int, vector unsigned int *);
- void vec_vsx_st (vector unsigned int, int, unsigned int *);
- void vec_vsx_st (vector bool int, int, vector bool int *);
- void vec_vsx_st (vector bool int, int, unsigned int *);
- void vec_vsx_st (vector bool int, int, int *);
- void vec_vsx_st (vector signed short, int, vector signed short *);
- void vec_vsx_st (vector signed short, int, short *);
- void vec_vsx_st (vector unsigned short, int, vector unsigned short *);
- void vec_vsx_st (vector unsigned short, int, unsigned short *);
- void vec_vsx_st (vector bool short, int, vector bool short *);
- void vec_vsx_st (vector bool short, int, unsigned short *);
- void vec_vsx_st (vector pixel, int, vector pixel *);
- void vec_vsx_st (vector pixel, int, unsigned short *);
- void vec_vsx_st (vector pixel, int, short *);
- void vec_vsx_st (vector bool short, int, short *);
- void vec_vsx_st (vector signed char, int, vector signed char *);
- void vec_vsx_st (vector signed char, int, signed char *);
- void vec_vsx_st (vector unsigned char, int, vector unsigned char *);
- void vec_vsx_st (vector unsigned char, int, unsigned char *);
- void vec_vsx_st (vector bool char, int, vector bool char *);
- void vec_vsx_st (vector bool char, int, unsigned char *);
- void vec_vsx_st (vector bool char, int, signed char *);
-
- Note that the `vec_ld' and `vec_st' builtins will always generate the
-Altivec `LVX' and `STVX' instructions even if the VSX instruction set
-is available. The `vec_vsx_ld' and `vec_vsx_st' builtins will always
-generate the VSX `LXVD2X', `LXVW4X', `STXVD2X', and `STXVW4X'
-instructions.
-
- GCC provides a few other builtins on Powerpc to access certain
-instructions:
- float __builtin_recipdivf (float, float);
- float __builtin_rsqrtf (float);
- double __builtin_recipdiv (double, double);
- double __builtin_rsqrt (double);
- long __builtin_bpermd (long, long);
- int __builtin_bswap16 (int);
-
- The `vec_rsqrt', `__builtin_rsqrt', and `__builtin_rsqrtf' functions
-generate multiple instructions to implement the reciprocal sqrt
-functionality using reciprocal sqrt estimate instructions.
-
- The `__builtin_recipdiv', and `__builtin_recipdivf' functions generate
-multiple instructions to implement division using the reciprocal
-estimate instructions.
-
-
-File: gcc.info, Node: RX Built-in Functions, Next: SPARC VIS Built-in Functions, Prev: PowerPC AltiVec/VSX Built-in Functions, Up: Target Builtins
-
-6.54.13 RX Built-in Functions
------------------------------
-
-GCC supports some of the RX instructions which cannot be expressed in
-the C programming language via the use of built-in functions. The
-following functions are supported:
-
- -- Built-in Function: void __builtin_rx_brk (void)
- Generates the `brk' machine instruction.
-
- -- Built-in Function: void __builtin_rx_clrpsw (int)
- Generates the `clrpsw' machine instruction to clear the specified
- bit in the processor status word.
-
- -- Built-in Function: void __builtin_rx_int (int)
- Generates the `int' machine instruction to generate an interrupt
- with the specified value.
-
- -- Built-in Function: void __builtin_rx_machi (int, int)
- Generates the `machi' machine instruction to add the result of
- multiplying the top 16-bits of the two arguments into the
- accumulator.
-
- -- Built-in Function: void __builtin_rx_maclo (int, int)
- Generates the `maclo' machine instruction to add the result of
- multiplying the bottom 16-bits of the two arguments into the
- accumulator.
-
- -- Built-in Function: void __builtin_rx_mulhi (int, int)
- Generates the `mulhi' machine instruction to place the result of
- multiplying the top 16-bits of the two arguments into the
- accumulator.
-
- -- Built-in Function: void __builtin_rx_mullo (int, int)
- Generates the `mullo' machine instruction to place the result of
- multiplying the bottom 16-bits of the two arguments into the
- accumulator.
-
- -- Built-in Function: int __builtin_rx_mvfachi (void)
- Generates the `mvfachi' machine instruction to read the top
- 32-bits of the accumulator.
-
- -- Built-in Function: int __builtin_rx_mvfacmi (void)
- Generates the `mvfacmi' machine instruction to read the middle
- 32-bits of the accumulator.
-
- -- Built-in Function: int __builtin_rx_mvfc (int)
- Generates the `mvfc' machine instruction which reads the control
- register specified in its argument and returns its value.
-
- -- Built-in Function: void __builtin_rx_mvtachi (int)
- Generates the `mvtachi' machine instruction to set the top 32-bits
- of the accumulator.
-
- -- Built-in Function: void __builtin_rx_mvtaclo (int)
- Generates the `mvtaclo' machine instruction to set the bottom
- 32-bits of the accumulator.
-
- -- Built-in Function: void __builtin_rx_mvtc (int reg, int val)
- Generates the `mvtc' machine instruction which sets control
- register number `reg' to `val'.
-
- -- Built-in Function: void __builtin_rx_mvtipl (int)
- Generates the `mvtipl' machine instruction set the interrupt
- priority level.
-
- -- Built-in Function: void __builtin_rx_racw (int)
- Generates the `racw' machine instruction to round the accumulator
- according to the specified mode.
-
- -- Built-in Function: int __builtin_rx_revw (int)
- Generates the `revw' machine instruction which swaps the bytes in
- the argument so that bits 0-7 now occupy bits 8-15 and vice versa,
- and also bits 16-23 occupy bits 24-31 and vice versa.
-
- -- Built-in Function: void __builtin_rx_rmpa (void)
- Generates the `rmpa' machine instruction which initiates a
- repeated multiply and accumulate sequence.
-
- -- Built-in Function: void __builtin_rx_round (float)
- Generates the `round' machine instruction which returns the
- floating point argument rounded according to the current rounding
- mode set in the floating point status word register.
-
- -- Built-in Function: int __builtin_rx_sat (int)
- Generates the `sat' machine instruction which returns the
- saturated value of the argument.
-
- -- Built-in Function: void __builtin_rx_setpsw (int)
- Generates the `setpsw' machine instruction to set the specified
- bit in the processor status word.
-
- -- Built-in Function: void __builtin_rx_wait (void)
- Generates the `wait' machine instruction.
-
-
-File: gcc.info, Node: SPARC VIS Built-in Functions, Next: SPU Built-in Functions, Prev: RX Built-in Functions, Up: Target Builtins
-
-6.54.14 SPARC VIS Built-in Functions
-------------------------------------
-
-GCC supports SIMD operations on the SPARC using both the generic vector
-extensions (*note Vector Extensions::) as well as built-in functions for
-the SPARC Visual Instruction Set (VIS). When you use the `-mvis'
-switch, the VIS extension is exposed as the following built-in
-functions:
-
- typedef int v2si __attribute__ ((vector_size (8)));
- typedef short v4hi __attribute__ ((vector_size (8)));
- typedef short v2hi __attribute__ ((vector_size (4)));
- typedef char v8qi __attribute__ ((vector_size (8)));
- typedef char v4qi __attribute__ ((vector_size (4)));
-
- void * __builtin_vis_alignaddr (void *, long);
- int64_t __builtin_vis_faligndatadi (int64_t, int64_t);
- v2si __builtin_vis_faligndatav2si (v2si, v2si);
- v4hi __builtin_vis_faligndatav4hi (v4si, v4si);
- v8qi __builtin_vis_faligndatav8qi (v8qi, v8qi);
-
- v4hi __builtin_vis_fexpand (v4qi);
-
- v4hi __builtin_vis_fmul8x16 (v4qi, v4hi);
- v4hi __builtin_vis_fmul8x16au (v4qi, v4hi);
- v4hi __builtin_vis_fmul8x16al (v4qi, v4hi);
- v4hi __builtin_vis_fmul8sux16 (v8qi, v4hi);
- v4hi __builtin_vis_fmul8ulx16 (v8qi, v4hi);
- v2si __builtin_vis_fmuld8sux16 (v4qi, v2hi);
- v2si __builtin_vis_fmuld8ulx16 (v4qi, v2hi);
-
- v4qi __builtin_vis_fpack16 (v4hi);
- v8qi __builtin_vis_fpack32 (v2si, v2si);
- v2hi __builtin_vis_fpackfix (v2si);
- v8qi __builtin_vis_fpmerge (v4qi, v4qi);
-
- int64_t __builtin_vis_pdist (v8qi, v8qi, int64_t);
-
-
-File: gcc.info, Node: SPU Built-in Functions, Prev: SPARC VIS Built-in Functions, Up: Target Builtins
-
-6.54.15 SPU Built-in Functions
-------------------------------
-
-GCC provides extensions for the SPU processor as described in the
-Sony/Toshiba/IBM SPU Language Extensions Specification, which can be
-found at `http://cell.scei.co.jp/' or
-`http://www.ibm.com/developerworks/power/cell/'. GCC's implementation
-differs in several ways.
-
- * The optional extension of specifying vector constants in
- parentheses is not supported.
-
- * A vector initializer requires no cast if the vector constant is of
- the same type as the variable it is initializing.
-
- * If `signed' or `unsigned' is omitted, the signedness of the vector
- type is the default signedness of the base type. The default
- varies depending on the operating system, so a portable program
- should always specify the signedness.
-
- * By default, the keyword `__vector' is added. The macro `vector' is
- defined in `<spu_intrinsics.h>' and can be undefined.
-
- * GCC allows using a `typedef' name as the type specifier for a
- vector type.
-
- * For C, overloaded functions are implemented with macros so the
- following does not work:
-
- spu_add ((vector signed int){1, 2, 3, 4}, foo);
-
- Since `spu_add' is a macro, the vector constant in the example is
- treated as four separate arguments. Wrap the entire argument in
- parentheses for this to work.
-
- * The extended version of `__builtin_expect' is not supported.
-
-
- _Note:_ Only the interface described in the aforementioned
-specification is supported. Internally, GCC uses built-in functions to
-implement the required functionality, but these are not supported and
-are subject to change without notice.
-
-
-File: gcc.info, Node: Target Format Checks, Next: Pragmas, Prev: Target Builtins, Up: C Extensions
-
-6.55 Format Checks Specific to Particular Target Machines
-=========================================================
-
-For some target machines, GCC supports additional options to the format
-attribute (*note Declaring Attributes of Functions: Function
-Attributes.).
-
-* Menu:
-
-* Solaris Format Checks::
-* Darwin Format Checks::
-
-
-File: gcc.info, Node: Solaris Format Checks, Next: Darwin Format Checks, Up: Target Format Checks
-
-6.55.1 Solaris Format Checks
-----------------------------
-
-Solaris targets support the `cmn_err' (or `__cmn_err__') format check.
-`cmn_err' accepts a subset of the standard `printf' conversions, and
-the two-argument `%b' conversion for displaying bit-fields. See the
-Solaris man page for `cmn_err' for more information.
-
-
-File: gcc.info, Node: Darwin Format Checks, Prev: Solaris Format Checks, Up: Target Format Checks
-
-6.55.2 Darwin Format Checks
----------------------------
-
-Darwin targets support the `CFString' (or `__CFString__') in the format
-attribute context. Declarations made with such attribution will be
-parsed for correct syntax and format argument types. However, parsing
-of the format string itself is currently undefined and will not be
-carried out by this version of the compiler.
-
- Additionally, `CFStringRefs' (defined by the `CoreFoundation' headers)
-may also be used as format arguments. Note that the relevant headers
-are only likely to be available on Darwin (OSX) installations. On such
-installations, the XCode and system documentation provide descriptions
-of `CFString', `CFStringRefs' and associated functions.
-
-
-File: gcc.info, Node: Pragmas, Next: Unnamed Fields, Prev: Target Format Checks, Up: C Extensions
-
-6.56 Pragmas Accepted by GCC
-============================
-
-GCC supports several types of pragmas, primarily in order to compile
-code originally written for other compilers. Note that in general we
-do not recommend the use of pragmas; *Note Function Attributes::, for
-further explanation.
-
-* Menu:
-
-* ARM Pragmas::
-* M32C Pragmas::
-* MeP Pragmas::
-* RS/6000 and PowerPC Pragmas::
-* Darwin Pragmas::
-* Solaris Pragmas::
-* Symbol-Renaming Pragmas::
-* Structure-Packing Pragmas::
-* Weak Pragmas::
-* Diagnostic Pragmas::
-* Visibility Pragmas::
-* Push/Pop Macro Pragmas::
-* Function Specific Option Pragmas::
-
-
-File: gcc.info, Node: ARM Pragmas, Next: M32C Pragmas, Up: Pragmas
-
-6.56.1 ARM Pragmas
-------------------
-
-The ARM target defines pragmas for controlling the default addition of
-`long_call' and `short_call' attributes to functions. *Note Function
-Attributes::, for information about the effects of these attributes.
-
-`long_calls'
- Set all subsequent functions to have the `long_call' attribute.
-
-`no_long_calls'
- Set all subsequent functions to have the `short_call' attribute.
-
-`long_calls_off'
- Do not affect the `long_call' or `short_call' attributes of
- subsequent functions.
-
-
-File: gcc.info, Node: M32C Pragmas, Next: MeP Pragmas, Prev: ARM Pragmas, Up: Pragmas
-
-6.56.2 M32C Pragmas
--------------------
-
-`GCC memregs NUMBER'
- Overrides the command-line option `-memregs=' for the current
- file. Use with care! This pragma must be before any function in
- the file, and mixing different memregs values in different objects
- may make them incompatible. This pragma is useful when a
- performance-critical function uses a memreg for temporary values,
- as it may allow you to reduce the number of memregs used.
-
-`ADDRESS NAME ADDRESS'
- For any declared symbols matching NAME, this does three things to
- that symbol: it forces the symbol to be located at the given
- address (a number), it forces the symbol to be volatile, and it
- changes the symbol's scope to be static. This pragma exists for
- compatibility with other compilers, but note that the common
- `1234H' numeric syntax is not supported (use `0x1234' instead).
- Example:
-
- #pragma ADDRESS port3 0x103
- char port3;
-
-
-
-File: gcc.info, Node: MeP Pragmas, Next: RS/6000 and PowerPC Pragmas, Prev: M32C Pragmas, Up: Pragmas
-
-6.56.3 MeP Pragmas
-------------------
-
-`custom io_volatile (on|off)'
- Overrides the command line option `-mio-volatile' for the current
- file. Note that for compatibility with future GCC releases, this
- option should only be used once before any `io' variables in each
- file.
-
-`GCC coprocessor available REGISTERS'
- Specifies which coprocessor registers are available to the register
- allocator. REGISTERS may be a single register, register range
- separated by ellipses, or comma-separated list of those. Example:
-
- #pragma GCC coprocessor available $c0...$c10, $c28
-
-`GCC coprocessor call_saved REGISTERS'
- Specifies which coprocessor registers are to be saved and restored
- by any function using them. REGISTERS may be a single register,
- register range separated by ellipses, or comma-separated list of
- those. Example:
-
- #pragma GCC coprocessor call_saved $c4...$c6, $c31
-
-`GCC coprocessor subclass '(A|B|C|D)' = REGISTERS'
- Creates and defines a register class. These register classes can
- be used by inline `asm' constructs. REGISTERS may be a single
- register, register range separated by ellipses, or comma-separated
- list of those. Example:
-
- #pragma GCC coprocessor subclass 'B' = $c2, $c4, $c6
-
- asm ("cpfoo %0" : "=B" (x));
-
-`GCC disinterrupt NAME , NAME ...'
- For the named functions, the compiler adds code to disable
- interrupts for the duration of those functions. Any functions so
- named, which are not encountered in the source, cause a warning
- that the pragma was not used. Examples:
-
- #pragma disinterrupt foo
- #pragma disinterrupt bar, grill
- int foo () { ... }
-
-`GCC call NAME , NAME ...'
- For the named functions, the compiler always uses a
- register-indirect call model when calling the named functions.
- Examples:
-
- extern int foo ();
- #pragma call foo
-
-
-
-File: gcc.info, Node: RS/6000 and PowerPC Pragmas, Next: Darwin Pragmas, Prev: MeP Pragmas, Up: Pragmas
-
-6.56.4 RS/6000 and PowerPC Pragmas
-----------------------------------
-
-The RS/6000 and PowerPC targets define one pragma for controlling
-whether or not the `longcall' attribute is added to function
-declarations by default. This pragma overrides the `-mlongcall'
-option, but not the `longcall' and `shortcall' attributes. *Note
-RS/6000 and PowerPC Options::, for more information about when long
-calls are and are not necessary.
-
-`longcall (1)'
- Apply the `longcall' attribute to all subsequent function
- declarations.
-
-`longcall (0)'
- Do not apply the `longcall' attribute to subsequent function
- declarations.
-
-
-File: gcc.info, Node: Darwin Pragmas, Next: Solaris Pragmas, Prev: RS/6000 and PowerPC Pragmas, Up: Pragmas
-
-6.56.5 Darwin Pragmas
----------------------
-
-The following pragmas are available for all architectures running the
-Darwin operating system. These are useful for compatibility with other
-Mac OS compilers.
-
-`mark TOKENS...'
- This pragma is accepted, but has no effect.
-
-`options align=ALIGNMENT'
- This pragma sets the alignment of fields in structures. The
- values of ALIGNMENT may be `mac68k', to emulate m68k alignment, or
- `power', to emulate PowerPC alignment. Uses of this pragma nest
- properly; to restore the previous setting, use `reset' for the
- ALIGNMENT.
-
-`segment TOKENS...'
- This pragma is accepted, but has no effect.
-
-`unused (VAR [, VAR]...)'
- This pragma declares variables to be possibly unused. GCC will not
- produce warnings for the listed variables. The effect is similar
- to that of the `unused' attribute, except that this pragma may
- appear anywhere within the variables' scopes.
-
-
-File: gcc.info, Node: Solaris Pragmas, Next: Symbol-Renaming Pragmas, Prev: Darwin Pragmas, Up: Pragmas
-
-6.56.6 Solaris Pragmas
-----------------------
-
-The Solaris target supports `#pragma redefine_extname' (*note
-Symbol-Renaming Pragmas::). It also supports additional `#pragma'
-directives for compatibility with the system compiler.
-
-`align ALIGNMENT (VARIABLE [, VARIABLE]...)'
- Increase the minimum alignment of each VARIABLE to ALIGNMENT.
- This is the same as GCC's `aligned' attribute *note Variable
- Attributes::). Macro expansion occurs on the arguments to this
- pragma when compiling C and Objective-C. It does not currently
- occur when compiling C++, but this is a bug which may be fixed in
- a future release.
-
-`fini (FUNCTION [, FUNCTION]...)'
- This pragma causes each listed FUNCTION to be called after main,
- or during shared module unloading, by adding a call to the `.fini'
- section.
-
-`init (FUNCTION [, FUNCTION]...)'
- This pragma causes each listed FUNCTION to be called during
- initialization (before `main') or during shared module loading, by
- adding a call to the `.init' section.
-
-
-
-File: gcc.info, Node: Symbol-Renaming Pragmas, Next: Structure-Packing Pragmas, Prev: Solaris Pragmas, Up: Pragmas
-
-6.56.7 Symbol-Renaming Pragmas
-------------------------------
-
-For compatibility with the Solaris and Tru64 UNIX system headers, GCC
-supports two `#pragma' directives which change the name used in
-assembly for a given declaration. `#pragma extern_prefix' is only
-available on platforms whose system headers need it. To get this effect
-on all platforms supported by GCC, use the asm labels extension (*note
-Asm Labels::).
-
-`redefine_extname OLDNAME NEWNAME'
- This pragma gives the C function OLDNAME the assembly symbol
- NEWNAME. The preprocessor macro `__PRAGMA_REDEFINE_EXTNAME' will
- be defined if this pragma is available (currently on all
- platforms).
-
-`extern_prefix STRING'
- This pragma causes all subsequent external function and variable
- declarations to have STRING prepended to their assembly symbols.
- This effect may be terminated with another `extern_prefix' pragma
- whose argument is an empty string. The preprocessor macro
- `__PRAGMA_EXTERN_PREFIX' will be defined if this pragma is
- available (currently only on Tru64 UNIX).
-
- These pragmas and the asm labels extension interact in a complicated
-manner. Here are some corner cases you may want to be aware of.
-
- 1. Both pragmas silently apply only to declarations with external
- linkage. Asm labels do not have this restriction.
-
- 2. In C++, both pragmas silently apply only to declarations with "C"
- linkage. Again, asm labels do not have this restriction.
-
- 3. If any of the three ways of changing the assembly name of a
- declaration is applied to a declaration whose assembly name has
- already been determined (either by a previous use of one of these
- features, or because the compiler needed the assembly name in
- order to generate code), and the new name is different, a warning
- issues and the name does not change.
-
- 4. The OLDNAME used by `#pragma redefine_extname' is always the
- C-language name.
-
- 5. If `#pragma extern_prefix' is in effect, and a declaration occurs
- with an asm label attached, the prefix is silently ignored for
- that declaration.
-
- 6. If `#pragma extern_prefix' and `#pragma redefine_extname' apply to
- the same declaration, whichever triggered first wins, and a
- warning issues if they contradict each other. (We would like to
- have `#pragma redefine_extname' always win, for consistency with
- asm labels, but if `#pragma extern_prefix' triggers first we have
- no way of knowing that that happened.)
-
-
-File: gcc.info, Node: Structure-Packing Pragmas, Next: Weak Pragmas, Prev: Symbol-Renaming Pragmas, Up: Pragmas
-
-6.56.8 Structure-Packing Pragmas
---------------------------------
-
-For compatibility with Microsoft Windows compilers, GCC supports a set
-of `#pragma' directives which change the maximum alignment of members
-of structures (other than zero-width bitfields), unions, and classes
-subsequently defined. The N value below always is required to be a
-small power of two and specifies the new alignment in bytes.
-
- 1. `#pragma pack(N)' simply sets the new alignment.
-
- 2. `#pragma pack()' sets the alignment to the one that was in effect
- when compilation started (see also command-line option
- `-fpack-struct[=N]' *note Code Gen Options::).
-
- 3. `#pragma pack(push[,N])' pushes the current alignment setting on
- an internal stack and then optionally sets the new alignment.
-
- 4. `#pragma pack(pop)' restores the alignment setting to the one
- saved at the top of the internal stack (and removes that stack
- entry). Note that `#pragma pack([N])' does not influence this
- internal stack; thus it is possible to have `#pragma pack(push)'
- followed by multiple `#pragma pack(N)' instances and finalized by
- a single `#pragma pack(pop)'.
-
- Some targets, e.g. i386 and powerpc, support the `ms_struct' `#pragma'
-which lays out a structure as the documented `__attribute__
-((ms_struct))'.
- 1. `#pragma ms_struct on' turns on the layout for structures declared.
-
- 2. `#pragma ms_struct off' turns off the layout for structures
- declared.
-
- 3. `#pragma ms_struct reset' goes back to the default layout.
-
-
-File: gcc.info, Node: Weak Pragmas, Next: Diagnostic Pragmas, Prev: Structure-Packing Pragmas, Up: Pragmas
-
-6.56.9 Weak Pragmas
--------------------
-
-For compatibility with SVR4, GCC supports a set of `#pragma' directives
-for declaring symbols to be weak, and defining weak aliases.
-
-`#pragma weak SYMBOL'
- This pragma declares SYMBOL to be weak, as if the declaration had
- the attribute of the same name. The pragma may appear before or
- after the declaration of SYMBOL. It is not an error for SYMBOL to
- never be defined at all.
-
-`#pragma weak SYMBOL1 = SYMBOL2'
- This pragma declares SYMBOL1 to be a weak alias of SYMBOL2. It is
- an error if SYMBOL2 is not defined in the current translation unit.
-
-
-File: gcc.info, Node: Diagnostic Pragmas, Next: Visibility Pragmas, Prev: Weak Pragmas, Up: Pragmas
-
-6.56.10 Diagnostic Pragmas
---------------------------
-
-GCC allows the user to selectively enable or disable certain types of
-diagnostics, and change the kind of the diagnostic. For example, a
-project's policy might require that all sources compile with `-Werror'
-but certain files might have exceptions allowing specific types of
-warnings. Or, a project might selectively enable diagnostics and treat
-them as errors depending on which preprocessor macros are defined.
-
-`#pragma GCC diagnostic KIND OPTION'
- Modifies the disposition of a diagnostic. Note that not all
- diagnostics are modifiable; at the moment only warnings (normally
- controlled by `-W...') can be controlled, and not all of them.
- Use `-fdiagnostics-show-option' to determine which diagnostics are
- controllable and which option controls them.
-
- KIND is `error' to treat this diagnostic as an error, `warning' to
- treat it like a warning (even if `-Werror' is in effect), or
- `ignored' if the diagnostic is to be ignored. OPTION is a double
- quoted string which matches the command-line option.
-
- #pragma GCC diagnostic warning "-Wformat"
- #pragma GCC diagnostic error "-Wformat"
- #pragma GCC diagnostic ignored "-Wformat"
-
- Note that these pragmas override any command-line options. GCC
- keeps track of the location of each pragma, and issues diagnostics
- according to the state as of that point in the source file. Thus,
- pragmas occurring after a line do not affect diagnostics caused by
- that line.
-
-`#pragma GCC diagnostic push'
-`#pragma GCC diagnostic pop'
- Causes GCC to remember the state of the diagnostics as of each
- `push', and restore to that point at each `pop'. If a `pop' has
- no matching `push', the command line options are restored.
-
- #pragma GCC diagnostic error "-Wuninitialized"
- foo(a); /* error is given for this one */
- #pragma GCC diagnostic push
- #pragma GCC diagnostic ignored "-Wuninitialized"
- foo(b); /* no diagnostic for this one */
- #pragma GCC diagnostic pop
- foo(c); /* error is given for this one */
- #pragma GCC diagnostic pop
- foo(d); /* depends on command line options */
-
-
- GCC also offers a simple mechanism for printing messages during
-compilation.
-
-`#pragma message STRING'
- Prints STRING as a compiler message on compilation. The message
- is informational only, and is neither a compilation warning nor an
- error.
-
- #pragma message "Compiling " __FILE__ "..."
-
- STRING may be parenthesized, and is printed with location
- information. For example,
-
- #define DO_PRAGMA(x) _Pragma (#x)
- #define TODO(x) DO_PRAGMA(message ("TODO - " #x))
-
- TODO(Remember to fix this)
-
- prints `/tmp/file.c:4: note: #pragma message: TODO - Remember to
- fix this'.
-
-
-
-File: gcc.info, Node: Visibility Pragmas, Next: Push/Pop Macro Pragmas, Prev: Diagnostic Pragmas, Up: Pragmas
-
-6.56.11 Visibility Pragmas
---------------------------
-
-`#pragma GCC visibility push(VISIBILITY)'
-`#pragma GCC visibility pop'
- This pragma allows the user to set the visibility for multiple
- declarations without having to give each a visibility attribute
- *Note Function Attributes::, for more information about visibility
- and the attribute syntax.
-
- In C++, `#pragma GCC visibility' affects only namespace-scope
- declarations. Class members and template specializations are not
- affected; if you want to override the visibility for a particular
- member or instantiation, you must use an attribute.
-
-
-
-File: gcc.info, Node: Push/Pop Macro Pragmas, Next: Function Specific Option Pragmas, Prev: Visibility Pragmas, Up: Pragmas
-
-6.56.12 Push/Pop Macro Pragmas
-------------------------------
-
-For compatibility with Microsoft Windows compilers, GCC supports
-`#pragma push_macro("MACRO_NAME")' and `#pragma
-pop_macro("MACRO_NAME")'.
-
-`#pragma push_macro("MACRO_NAME")'
- This pragma saves the value of the macro named as MACRO_NAME to
- the top of the stack for this macro.
-
-`#pragma pop_macro("MACRO_NAME")'
- This pragma sets the value of the macro named as MACRO_NAME to the
- value on top of the stack for this macro. If the stack for
- MACRO_NAME is empty, the value of the macro remains unchanged.
-
- For example:
-
- #define X 1
- #pragma push_macro("X")
- #undef X
- #define X -1
- #pragma pop_macro("X")
- int x [X];
-
- In this example, the definition of X as 1 is saved by `#pragma
-push_macro' and restored by `#pragma pop_macro'.
-
-
-File: gcc.info, Node: Function Specific Option Pragmas, Prev: Push/Pop Macro Pragmas, Up: Pragmas
-
-6.56.13 Function Specific Option Pragmas
-----------------------------------------
-
-`#pragma GCC target ("STRING"...)'
- This pragma allows you to set target specific options for functions
- defined later in the source file. One or more strings can be
- specified. Each function that is defined after this point will be
- as if `attribute((target("STRING")))' was specified for that
- function. The parenthesis around the options is optional. *Note
- Function Attributes::, for more information about the `target'
- attribute and the attribute syntax.
-
- The `#pragma GCC target' attribute is not implemented in GCC
- versions earlier than 4.4 for the i386/x86_64 and 4.6 for the
- PowerPC backends. At present, it is not implemented for other
- backends.
-
-`#pragma GCC optimize ("STRING"...)'
- This pragma allows you to set global optimization options for
- functions defined later in the source file. One or more strings
- can be specified. Each function that is defined after this point
- will be as if `attribute((optimize("STRING")))' was specified for
- that function. The parenthesis around the options is optional.
- *Note Function Attributes::, for more information about the
- `optimize' attribute and the attribute syntax.
-
- The `#pragma GCC optimize' pragma is not implemented in GCC
- versions earlier than 4.4.
-
-`#pragma GCC push_options'
-`#pragma GCC pop_options'
- These pragmas maintain a stack of the current target and
- optimization options. It is intended for include files where you
- temporarily want to switch to using a different `#pragma GCC
- target' or `#pragma GCC optimize' and then to pop back to the
- previous options.
-
- The `#pragma GCC push_options' and `#pragma GCC pop_options'
- pragmas are not implemented in GCC versions earlier than 4.4.
-
-`#pragma GCC reset_options'
- This pragma clears the current `#pragma GCC target' and `#pragma
- GCC optimize' to use the default switches as specified on the
- command line.
-
- The `#pragma GCC reset_options' pragma is not implemented in GCC
- versions earlier than 4.4.
-
-
-File: gcc.info, Node: Unnamed Fields, Next: Thread-Local, Prev: Pragmas, Up: C Extensions
-
-6.57 Unnamed struct/union fields within structs/unions
-======================================================
-
-As permitted by ISO C1X and for compatibility with other compilers, GCC
-allows you to define a structure or union that contains, as fields,
-structures and unions without names. For example:
-
- struct {
- int a;
- union {
- int b;
- float c;
- };
- int d;
- } foo;
-
- In this example, the user would be able to access members of the
-unnamed union with code like `foo.b'. Note that only unnamed structs
-and unions are allowed, you may not have, for example, an unnamed `int'.
-
- You must never create such structures that cause ambiguous field
-definitions. For example, this structure:
-
- struct {
- int a;
- struct {
- int a;
- };
- } foo;
-
- It is ambiguous which `a' is being referred to with `foo.a'. The
-compiler gives errors for such constructs.
-
- Unless `-fms-extensions' is used, the unnamed field must be a
-structure or union definition without a tag (for example, `struct { int
-a; };'). If `-fms-extensions' is used, the field may also be a
-definition with a tag such as `struct foo { int a; };', a reference to
-a previously defined structure or union such as `struct foo;', or a
-reference to a `typedef' name for a previously defined structure or
-union type.
-
- The option `-fplan9-extensions' enables `-fms-extensions' as well as
-two other extensions. First, a pointer to a structure is automatically
-converted to a pointer to an anonymous field for assignments and
-function calls. For example:
-
- struct s1 { int a; };
- struct s2 { struct s1; };
- extern void f1 (struct s1 *);
- void f2 (struct s2 *p) { f1 (p); }
-
- In the call to `f1' inside `f2', the pointer `p' is converted into a
-pointer to the anonymous field.
-
- Second, when the type of an anonymous field is a `typedef' for a
-`struct' or `union', code may refer to the field using the name of the
-`typedef'.
-
- typedef struct { int a; } s1;
- struct s2 { s1; };
- s1 f1 (struct s2 *p) { return p->s1; }
-
- These usages are only permitted when they are not ambiguous.
-
-
-File: gcc.info, Node: Thread-Local, Next: Binary constants, Prev: Unnamed Fields, Up: C Extensions
-
-6.58 Thread-Local Storage
-=========================
-
-Thread-local storage (TLS) is a mechanism by which variables are
-allocated such that there is one instance of the variable per extant
-thread. The run-time model GCC uses to implement this originates in
-the IA-64 processor-specific ABI, but has since been migrated to other
-processors as well. It requires significant support from the linker
-(`ld'), dynamic linker (`ld.so'), and system libraries (`libc.so' and
-`libpthread.so'), so it is not available everywhere.
-
- At the user level, the extension is visible with a new storage class
-keyword: `__thread'. For example:
-
- __thread int i;
- extern __thread struct state s;
- static __thread char *p;
-
- The `__thread' specifier may be used alone, with the `extern' or
-`static' specifiers, but with no other storage class specifier. When
-used with `extern' or `static', `__thread' must appear immediately
-after the other storage class specifier.
-
- The `__thread' specifier may be applied to any global, file-scoped
-static, function-scoped static, or static data member of a class. It
-may not be applied to block-scoped automatic or non-static data member.
-
- When the address-of operator is applied to a thread-local variable, it
-is evaluated at run-time and returns the address of the current thread's
-instance of that variable. An address so obtained may be used by any
-thread. When a thread terminates, any pointers to thread-local
-variables in that thread become invalid.
-
- No static initialization may refer to the address of a thread-local
-variable.
-
- In C++, if an initializer is present for a thread-local variable, it
-must be a CONSTANT-EXPRESSION, as defined in 5.19.2 of the ANSI/ISO C++
-standard.
-
- See ELF Handling For Thread-Local Storage
-(http://www.akkadia.org/drepper/tls.pdf) for a detailed explanation of
-the four thread-local storage addressing models, and how the run-time
-is expected to function.
-
-* Menu:
-
-* C99 Thread-Local Edits::
-* C++98 Thread-Local Edits::
-
-
-File: gcc.info, Node: C99 Thread-Local Edits, Next: C++98 Thread-Local Edits, Up: Thread-Local
-
-6.58.1 ISO/IEC 9899:1999 Edits for Thread-Local Storage
--------------------------------------------------------
-
-The following are a set of changes to ISO/IEC 9899:1999 (aka C99) that
-document the exact semantics of the language extension.
-
- * `5.1.2 Execution environments'
-
- Add new text after paragraph 1
-
- Within either execution environment, a "thread" is a flow of
- control within a program. It is implementation defined
- whether or not there may be more than one thread associated
- with a program. It is implementation defined how threads
- beyond the first are created, the name and type of the
- function called at thread startup, and how threads may be
- terminated. However, objects with thread storage duration
- shall be initialized before thread startup.
-
- * `6.2.4 Storage durations of objects'
-
- Add new text before paragraph 3
-
- An object whose identifier is declared with the storage-class
- specifier `__thread' has "thread storage duration". Its
- lifetime is the entire execution of the thread, and its
- stored value is initialized only once, prior to thread
- startup.
-
- * `6.4.1 Keywords'
-
- Add `__thread'.
-
- * `6.7.1 Storage-class specifiers'
-
- Add `__thread' to the list of storage class specifiers in
- paragraph 1.
-
- Change paragraph 2 to
-
- With the exception of `__thread', at most one storage-class
- specifier may be given [...]. The `__thread' specifier may
- be used alone, or immediately following `extern' or `static'.
-
- Add new text after paragraph 6
-
- The declaration of an identifier for a variable that has
- block scope that specifies `__thread' shall also specify
- either `extern' or `static'.
-
- The `__thread' specifier shall be used only with variables.
-
-
-File: gcc.info, Node: C++98 Thread-Local Edits, Prev: C99 Thread-Local Edits, Up: Thread-Local
-
-6.58.2 ISO/IEC 14882:1998 Edits for Thread-Local Storage
---------------------------------------------------------
-
-The following are a set of changes to ISO/IEC 14882:1998 (aka C++98)
-that document the exact semantics of the language extension.
-
- * [intro.execution]
-
- New text after paragraph 4
-
- A "thread" is a flow of control within the abstract machine.
- It is implementation defined whether or not there may be more
- than one thread.
-
- New text after paragraph 7
-
- It is unspecified whether additional action must be taken to
- ensure when and whether side effects are visible to other
- threads.
-
- * [lex.key]
-
- Add `__thread'.
-
- * [basic.start.main]
-
- Add after paragraph 5
-
- The thread that begins execution at the `main' function is
- called the "main thread". It is implementation defined how
- functions beginning threads other than the main thread are
- designated or typed. A function so designated, as well as
- the `main' function, is called a "thread startup function".
- It is implementation defined what happens if a thread startup
- function returns. It is implementation defined what happens
- to other threads when any thread calls `exit'.
-
- * [basic.start.init]
-
- Add after paragraph 4
-
- The storage for an object of thread storage duration shall be
- statically initialized before the first statement of the
- thread startup function. An object of thread storage
- duration shall not require dynamic initialization.
-
- * [basic.start.term]
-
- Add after paragraph 3
-
- The type of an object with thread storage duration shall not
- have a non-trivial destructor, nor shall it be an array type
- whose elements (directly or indirectly) have non-trivial
- destructors.
-
- * [basic.stc]
-
- Add "thread storage duration" to the list in paragraph 1.
-
- Change paragraph 2
-
- Thread, static, and automatic storage durations are
- associated with objects introduced by declarations [...].
-
- Add `__thread' to the list of specifiers in paragraph 3.
-
- * [basic.stc.thread]
-
- New section before [basic.stc.static]
-
- The keyword `__thread' applied to a non-local object gives the
- object thread storage duration.
-
- A local variable or class data member declared both `static'
- and `__thread' gives the variable or member thread storage
- duration.
-
- * [basic.stc.static]
-
- Change paragraph 1
-
- All objects which have neither thread storage duration,
- dynamic storage duration nor are local [...].
-
- * [dcl.stc]
-
- Add `__thread' to the list in paragraph 1.
-
- Change paragraph 1
-
- With the exception of `__thread', at most one
- STORAGE-CLASS-SPECIFIER shall appear in a given
- DECL-SPECIFIER-SEQ. The `__thread' specifier may be used
- alone, or immediately following the `extern' or `static'
- specifiers. [...]
-
- Add after paragraph 5
-
- The `__thread' specifier can be applied only to the names of
- objects and to anonymous unions.
-
- * [class.mem]
-
- Add after paragraph 6
-
- Non-`static' members shall not be `__thread'.
-
-
-File: gcc.info, Node: Binary constants, Prev: Thread-Local, Up: C Extensions
-
-6.59 Binary constants using the `0b' prefix
-===========================================
-
-Integer constants can be written as binary constants, consisting of a
-sequence of `0' and `1' digits, prefixed by `0b' or `0B'. This is
-particularly useful in environments that operate a lot on the bit-level
-(like microcontrollers).
-
- The following statements are identical:
-
- i = 42;
- i = 0x2a;
- i = 052;
- i = 0b101010;
-
- The type of these constants follows the same rules as for octal or
-hexadecimal integer constants, so suffixes like `L' or `UL' can be
-applied.
-
-
-File: gcc.info, Node: C++ Extensions, Next: Objective-C, Prev: C++ Implementation, Up: Top
-
-7 Extensions to the C++ Language
-********************************
-
-The GNU compiler provides these extensions to the C++ language (and you
-can also use most of the C language extensions in your C++ programs).
-If you want to write code that checks whether these features are
-available, you can test for the GNU compiler the same way as for C
-programs: check for a predefined macro `__GNUC__'. You can also use
-`__GNUG__' to test specifically for GNU C++ (*note Predefined Macros:
-(cpp)Common Predefined Macros.).
-
-* Menu:
-
-* C++ Volatiles:: What constitutes an access to a volatile object.
-* Restricted Pointers:: C99 restricted pointers and references.
-* Vague Linkage:: Where G++ puts inlines, vtables and such.
-* C++ Interface:: You can use a single C++ header file for both
- declarations and definitions.
-* Template Instantiation:: Methods for ensuring that exactly one copy of
- each needed template instantiation is emitted.
-* Bound member functions:: You can extract a function pointer to the
- method denoted by a `->*' or `.*' expression.
-* C++ Attributes:: Variable, function, and type attributes for C++ only.
-* Namespace Association:: Strong using-directives for namespace association.
-* Type Traits:: Compiler support for type traits
-* Java Exceptions:: Tweaking exception handling to work with Java.
-* Deprecated Features:: Things will disappear from g++.
-* Backwards Compatibility:: Compatibilities with earlier definitions of C++.
-
-
-File: gcc.info, Node: C++ Volatiles, Next: Restricted Pointers, Up: C++ Extensions
-
-7.1 When is a Volatile C++ Object Accessed?
-===========================================
-
-The C++ standard differs from the C standard in its treatment of
-volatile objects. It fails to specify what constitutes a volatile
-access, except to say that C++ should behave in a similar manner to C
-with respect to volatiles, where possible. However, the different
-lvalueness of expressions between C and C++ complicate the behavior.
-G++ behaves the same as GCC for volatile access, *Note Volatiles: C
-Extensions, for a description of GCC's behavior.
-
- The C and C++ language specifications differ when an object is
-accessed in a void context:
-
- volatile int *src = SOMEVALUE;
- *src;
-
- The C++ standard specifies that such expressions do not undergo lvalue
-to rvalue conversion, and that the type of the dereferenced object may
-be incomplete. The C++ standard does not specify explicitly that it is
-lvalue to rvalue conversion which is responsible for causing an access.
-There is reason to believe that it is, because otherwise certain simple
-expressions become undefined. However, because it would surprise most
-programmers, G++ treats dereferencing a pointer to volatile object of
-complete type as GCC would do for an equivalent type in C. When the
-object has incomplete type, G++ issues a warning; if you wish to force
-an error, you must force a conversion to rvalue with, for instance, a
-static cast.
-
- When using a reference to volatile, G++ does not treat equivalent
-expressions as accesses to volatiles, but instead issues a warning that
-no volatile is accessed. The rationale for this is that otherwise it
-becomes difficult to determine where volatile access occur, and not
-possible to ignore the return value from functions returning volatile
-references. Again, if you wish to force a read, cast the reference to
-an rvalue.
-
- G++ implements the same behavior as GCC does when assigning to a
-volatile object - there is no reread of the assigned-to object, the
-assigned rvalue is reused. Note that in C++ assignment expressions are
-lvalues, and if used as an lvalue, the volatile object will be referred
-to. For instance, VREF will refer to VOBJ, as expected, in the
-following example:
-
- volatile int vobj;
- volatile int &vref = vobj = SOMETHING;
-
-
-File: gcc.info, Node: Restricted Pointers, Next: Vague Linkage, Prev: C++ Volatiles, Up: C++ Extensions
-
-7.2 Restricting Pointer Aliasing
-================================
-
-As with the C front end, G++ understands the C99 feature of restricted
-pointers, specified with the `__restrict__', or `__restrict' type
-qualifier. Because you cannot compile C++ by specifying the `-std=c99'
-language flag, `restrict' is not a keyword in C++.
-
- In addition to allowing restricted pointers, you can specify restricted
-references, which indicate that the reference is not aliased in the
-local context.
-
- void fn (int *__restrict__ rptr, int &__restrict__ rref)
- {
- /* ... */
- }
-
-In the body of `fn', RPTR points to an unaliased integer and RREF
-refers to a (different) unaliased integer.
-
- You may also specify whether a member function's THIS pointer is
-unaliased by using `__restrict__' as a member function qualifier.
-
- void T::fn () __restrict__
- {
- /* ... */
- }
-
-Within the body of `T::fn', THIS will have the effective definition `T
-*__restrict__ const this'. Notice that the interpretation of a
-`__restrict__' member function qualifier is different to that of
-`const' or `volatile' qualifier, in that it is applied to the pointer
-rather than the object. This is consistent with other compilers which
-implement restricted pointers.
-
- As with all outermost parameter qualifiers, `__restrict__' is ignored
-in function definition matching. This means you only need to specify
-`__restrict__' in a function definition, rather than in a function
-prototype as well.
-
-
-File: gcc.info, Node: Vague Linkage, Next: C++ Interface, Prev: Restricted Pointers, Up: C++ Extensions
-
-7.3 Vague Linkage
-=================
-
-There are several constructs in C++ which require space in the object
-file but are not clearly tied to a single translation unit. We say that
-these constructs have "vague linkage". Typically such constructs are
-emitted wherever they are needed, though sometimes we can be more
-clever.
-
-Inline Functions
- Inline functions are typically defined in a header file which can
- be included in many different compilations. Hopefully they can
- usually be inlined, but sometimes an out-of-line copy is
- necessary, if the address of the function is taken or if inlining
- fails. In general, we emit an out-of-line copy in all translation
- units where one is needed. As an exception, we only emit inline
- virtual functions with the vtable, since it will always require a
- copy.
-
- Local static variables and string constants used in an inline
- function are also considered to have vague linkage, since they
- must be shared between all inlined and out-of-line instances of
- the function.
-
-VTables
- C++ virtual functions are implemented in most compilers using a
- lookup table, known as a vtable. The vtable contains pointers to
- the virtual functions provided by a class, and each object of the
- class contains a pointer to its vtable (or vtables, in some
- multiple-inheritance situations). If the class declares any
- non-inline, non-pure virtual functions, the first one is chosen as
- the "key method" for the class, and the vtable is only emitted in
- the translation unit where the key method is defined.
-
- _Note:_ If the chosen key method is later defined as inline, the
- vtable will still be emitted in every translation unit which
- defines it. Make sure that any inline virtuals are declared
- inline in the class body, even if they are not defined there.
-
-`type_info' objects
- C++ requires information about types to be written out in order to
- implement `dynamic_cast', `typeid' and exception handling. For
- polymorphic classes (classes with virtual functions), the
- `type_info' object is written out along with the vtable so that
- `dynamic_cast' can determine the dynamic type of a class object at
- runtime. For all other types, we write out the `type_info' object
- when it is used: when applying `typeid' to an expression, throwing
- an object, or referring to a type in a catch clause or exception
- specification.
-
-Template Instantiations
- Most everything in this section also applies to template
- instantiations, but there are other options as well. *Note
- Where's the Template?: Template Instantiation.
-
-
- When used with GNU ld version 2.8 or later on an ELF system such as
-GNU/Linux or Solaris 2, or on Microsoft Windows, duplicate copies of
-these constructs will be discarded at link time. This is known as
-COMDAT support.
-
- On targets that don't support COMDAT, but do support weak symbols, GCC
-will use them. This way one copy will override all the others, but the
-unused copies will still take up space in the executable.
-
- For targets which do not support either COMDAT or weak symbols, most
-entities with vague linkage will be emitted as local symbols to avoid
-duplicate definition errors from the linker. This will not happen for
-local statics in inlines, however, as having multiple copies will
-almost certainly break things.
-
- *Note Declarations and Definitions in One Header: C++ Interface, for
-another way to control placement of these constructs.
-
-
-File: gcc.info, Node: C++ Interface, Next: Template Instantiation, Prev: Vague Linkage, Up: C++ Extensions
-
-7.4 #pragma interface and implementation
-========================================
-
-`#pragma interface' and `#pragma implementation' provide the user with
-a way of explicitly directing the compiler to emit entities with vague
-linkage (and debugging information) in a particular translation unit.
-
- _Note:_ As of GCC 2.7.2, these `#pragma's are not useful in most
-cases, because of COMDAT support and the "key method" heuristic
-mentioned in *note Vague Linkage::. Using them can actually cause your
-program to grow due to unnecessary out-of-line copies of inline
-functions. Currently (3.4) the only benefit of these `#pragma's is
-reduced duplication of debugging information, and that should be
-addressed soon on DWARF 2 targets with the use of COMDAT groups.
-
-`#pragma interface'
-`#pragma interface "SUBDIR/OBJECTS.h"'
- Use this directive in _header files_ that define object classes,
- to save space in most of the object files that use those classes.
- Normally, local copies of certain information (backup copies of
- inline member functions, debugging information, and the internal
- tables that implement virtual functions) must be kept in each
- object file that includes class definitions. You can use this
- pragma to avoid such duplication. When a header file containing
- `#pragma interface' is included in a compilation, this auxiliary
- information will not be generated (unless the main input source
- file itself uses `#pragma implementation'). Instead, the object
- files will contain references to be resolved at link time.
-
- The second form of this directive is useful for the case where you
- have multiple headers with the same name in different directories.
- If you use this form, you must specify the same string to `#pragma
- implementation'.
-
-`#pragma implementation'
-`#pragma implementation "OBJECTS.h"'
- Use this pragma in a _main input file_, when you want full output
- from included header files to be generated (and made globally
- visible). The included header file, in turn, should use `#pragma
- interface'. Backup copies of inline member functions, debugging
- information, and the internal tables used to implement virtual
- functions are all generated in implementation files.
-
- If you use `#pragma implementation' with no argument, it applies to
- an include file with the same basename(1) as your source file.
- For example, in `allclass.cc', giving just `#pragma implementation'
- by itself is equivalent to `#pragma implementation "allclass.h"'.
-
- In versions of GNU C++ prior to 2.6.0 `allclass.h' was treated as
- an implementation file whenever you would include it from
- `allclass.cc' even if you never specified `#pragma
- implementation'. This was deemed to be more trouble than it was
- worth, however, and disabled.
-
- Use the string argument if you want a single implementation file to
- include code from multiple header files. (You must also use
- `#include' to include the header file; `#pragma implementation'
- only specifies how to use the file--it doesn't actually include
- it.)
-
- There is no way to split up the contents of a single header file
- into multiple implementation files.
-
- `#pragma implementation' and `#pragma interface' also have an effect
-on function inlining.
-
- If you define a class in a header file marked with `#pragma
-interface', the effect on an inline function defined in that class is
-similar to an explicit `extern' declaration--the compiler emits no code
-at all to define an independent version of the function. Its
-definition is used only for inlining with its callers.
-
- Conversely, when you include the same header file in a main source file
-that declares it as `#pragma implementation', the compiler emits code
-for the function itself; this defines a version of the function that
-can be found via pointers (or by callers compiled without inlining).
-If all calls to the function can be inlined, you can avoid emitting the
-function by compiling with `-fno-implement-inlines'. If any calls were
-not inlined, you will get linker errors.
-
- ---------- Footnotes ----------
-
- (1) A file's "basename" was the name stripped of all leading path
-information and of trailing suffixes, such as `.h' or `.C' or `.cc'.
-
-
-File: gcc.info, Node: Template Instantiation, Next: Bound member functions, Prev: C++ Interface, Up: C++ Extensions
-
-7.5 Where's the Template?
-=========================
-
-C++ templates are the first language feature to require more
-intelligence from the environment than one usually finds on a UNIX
-system. Somehow the compiler and linker have to make sure that each
-template instance occurs exactly once in the executable if it is needed,
-and not at all otherwise. There are two basic approaches to this
-problem, which are referred to as the Borland model and the Cfront
-model.
-
-Borland model
- Borland C++ solved the template instantiation problem by adding
- the code equivalent of common blocks to their linker; the compiler
- emits template instances in each translation unit that uses them,
- and the linker collapses them together. The advantage of this
- model is that the linker only has to consider the object files
- themselves; there is no external complexity to worry about. This
- disadvantage is that compilation time is increased because the
- template code is being compiled repeatedly. Code written for this
- model tends to include definitions of all templates in the header
- file, since they must be seen to be instantiated.
-
-Cfront model
- The AT&T C++ translator, Cfront, solved the template instantiation
- problem by creating the notion of a template repository, an
- automatically maintained place where template instances are
- stored. A more modern version of the repository works as follows:
- As individual object files are built, the compiler places any
- template definitions and instantiations encountered in the
- repository. At link time, the link wrapper adds in the objects in
- the repository and compiles any needed instances that were not
- previously emitted. The advantages of this model are more optimal
- compilation speed and the ability to use the system linker; to
- implement the Borland model a compiler vendor also needs to
- replace the linker. The disadvantages are vastly increased
- complexity, and thus potential for error; for some code this can be
- just as transparent, but in practice it can been very difficult to
- build multiple programs in one directory and one program in
- multiple directories. Code written for this model tends to
- separate definitions of non-inline member templates into a
- separate file, which should be compiled separately.
-
- When used with GNU ld version 2.8 or later on an ELF system such as
-GNU/Linux or Solaris 2, or on Microsoft Windows, G++ supports the
-Borland model. On other systems, G++ implements neither automatic
-model.
-
- A future version of G++ will support a hybrid model whereby the
-compiler will emit any instantiations for which the template definition
-is included in the compile, and store template definitions and
-instantiation context information into the object file for the rest.
-The link wrapper will extract that information as necessary and invoke
-the compiler to produce the remaining instantiations. The linker will
-then combine duplicate instantiations.
-
- In the mean time, you have the following options for dealing with
-template instantiations:
-
- 1. Compile your template-using code with `-frepo'. The compiler will
- generate files with the extension `.rpo' listing all of the
- template instantiations used in the corresponding object files
- which could be instantiated there; the link wrapper, `collect2',
- will then update the `.rpo' files to tell the compiler where to
- place those instantiations and rebuild any affected object files.
- The link-time overhead is negligible after the first pass, as the
- compiler will continue to place the instantiations in the same
- files.
-
- This is your best option for application code written for the
- Borland model, as it will just work. Code written for the Cfront
- model will need to be modified so that the template definitions
- are available at one or more points of instantiation; usually this
- is as simple as adding `#include <tmethods.cc>' to the end of each
- template header.
-
- For library code, if you want the library to provide all of the
- template instantiations it needs, just try to link all of its
- object files together; the link will fail, but cause the
- instantiations to be generated as a side effect. Be warned,
- however, that this may cause conflicts if multiple libraries try
- to provide the same instantiations. For greater control, use
- explicit instantiation as described in the next option.
-
- 2. Compile your code with `-fno-implicit-templates' to disable the
- implicit generation of template instances, and explicitly
- instantiate all the ones you use. This approach requires more
- knowledge of exactly which instances you need than do the others,
- but it's less mysterious and allows greater control. You can
- scatter the explicit instantiations throughout your program,
- perhaps putting them in the translation units where the instances
- are used or the translation units that define the templates
- themselves; you can put all of the explicit instantiations you
- need into one big file; or you can create small files like
-
- #include "Foo.h"
- #include "Foo.cc"
-
- template class Foo<int>;
- template ostream& operator <<
- (ostream&, const Foo<int>&);
-
- for each of the instances you need, and create a template
- instantiation library from those.
-
- If you are using Cfront-model code, you can probably get away with
- not using `-fno-implicit-templates' when compiling files that don't
- `#include' the member template definitions.
-
- If you use one big file to do the instantiations, you may want to
- compile it without `-fno-implicit-templates' so you get all of the
- instances required by your explicit instantiations (but not by any
- other files) without having to specify them as well.
-
- G++ has extended the template instantiation syntax given in the ISO
- standard to allow forward declaration of explicit instantiations
- (with `extern'), instantiation of the compiler support data for a
- template class (i.e. the vtable) without instantiating any of its
- members (with `inline'), and instantiation of only the static data
- members of a template class, without the support data or member
- functions (with (`static'):
-
- extern template int max (int, int);
- inline template class Foo<int>;
- static template class Foo<int>;
-
- 3. Do nothing. Pretend G++ does implement automatic instantiation
- management. Code written for the Borland model will work fine, but
- each translation unit will contain instances of each of the
- templates it uses. In a large program, this can lead to an
- unacceptable amount of code duplication.
-
-
-File: gcc.info, Node: Bound member functions, Next: C++ Attributes, Prev: Template Instantiation, Up: C++ Extensions
-
-7.6 Extracting the function pointer from a bound pointer to member function
-===========================================================================
-
-In C++, pointer to member functions (PMFs) are implemented using a wide
-pointer of sorts to handle all the possible call mechanisms; the PMF
-needs to store information about how to adjust the `this' pointer, and
-if the function pointed to is virtual, where to find the vtable, and
-where in the vtable to look for the member function. If you are using
-PMFs in an inner loop, you should really reconsider that decision. If
-that is not an option, you can extract the pointer to the function that
-would be called for a given object/PMF pair and call it directly inside
-the inner loop, to save a bit of time.
-
- Note that you will still be paying the penalty for the call through a
-function pointer; on most modern architectures, such a call defeats the
-branch prediction features of the CPU. This is also true of normal
-virtual function calls.
-
- The syntax for this extension is
-
- extern A a;
- extern int (A::*fp)();
- typedef int (*fptr)(A *);
-
- fptr p = (fptr)(a.*fp);
-
- For PMF constants (i.e. expressions of the form `&Klasse::Member'), no
-object is needed to obtain the address of the function. They can be
-converted to function pointers directly:
-
- fptr p1 = (fptr)(&A::foo);
-
- You must specify `-Wno-pmf-conversions' to use this extension.
-
-
-File: gcc.info, Node: C++ Attributes, Next: Namespace Association, Prev: Bound member functions, Up: C++ Extensions
-
-7.7 C++-Specific Variable, Function, and Type Attributes
-========================================================
-
-Some attributes only make sense for C++ programs.
-
-`init_priority (PRIORITY)'
- In Standard C++, objects defined at namespace scope are guaranteed
- to be initialized in an order in strict accordance with that of
- their definitions _in a given translation unit_. No guarantee is
- made for initializations across translation units. However, GNU
- C++ allows users to control the order of initialization of objects
- defined at namespace scope with the `init_priority' attribute by
- specifying a relative PRIORITY, a constant integral expression
- currently bounded between 101 and 65535 inclusive. Lower numbers
- indicate a higher priority.
-
- In the following example, `A' would normally be created before
- `B', but the `init_priority' attribute has reversed that order:
-
- Some_Class A __attribute__ ((init_priority (2000)));
- Some_Class B __attribute__ ((init_priority (543)));
-
- Note that the particular values of PRIORITY do not matter; only
- their relative ordering.
-
-`java_interface'
- This type attribute informs C++ that the class is a Java
- interface. It may only be applied to classes declared within an
- `extern "Java"' block. Calls to methods declared in this
- interface will be dispatched using GCJ's interface table
- mechanism, instead of regular virtual table dispatch.
-
-
- See also *note Namespace Association::.
-
-
-File: gcc.info, Node: Namespace Association, Next: Type Traits, Prev: C++ Attributes, Up: C++ Extensions
-
-7.8 Namespace Association
-=========================
-
-*Caution:* The semantics of this extension are not fully defined.
-Users should refrain from using this extension as its semantics may
-change subtly over time. It is possible that this extension will be
-removed in future versions of G++.
-
- A using-directive with `__attribute ((strong))' is stronger than a
-normal using-directive in two ways:
-
- * Templates from the used namespace can be specialized and explicitly
- instantiated as though they were members of the using namespace.
-
- * The using namespace is considered an associated namespace of all
- templates in the used namespace for purposes of argument-dependent
- name lookup.
-
- The used namespace must be nested within the using namespace so that
-normal unqualified lookup works properly.
-
- This is useful for composing a namespace transparently from
-implementation namespaces. For example:
-
- namespace std {
- namespace debug {
- template <class T> struct A { };
- }
- using namespace debug __attribute ((__strong__));
- template <> struct A<int> { }; // ok to specialize
-
- template <class T> void f (A<T>);
- }
-
- int main()
- {
- f (std::A<float>()); // lookup finds std::f
- f (std::A<int>());
- }
-
-
-File: gcc.info, Node: Type Traits, Next: Java Exceptions, Prev: Namespace Association, Up: C++ Extensions
-
-7.9 Type Traits
-===============
-
-The C++ front-end implements syntactic extensions that allow to
-determine at compile time various characteristics of a type (or of a
-pair of types).
-
-`__has_nothrow_assign (type)'
- If `type' is const qualified or is a reference type then the trait
- is false. Otherwise if `__has_trivial_assign (type)' is true then
- the trait is true, else if `type' is a cv class or union type with
- copy assignment operators that are known not to throw an exception
- then the trait is true, else it is false. Requires: `type' shall
- be a complete type, (possibly cv-qualified) `void', or an array of
- unknown bound.
-
-`__has_nothrow_copy (type)'
- If `__has_trivial_copy (type)' is true then the trait is true,
- else if `type' is a cv class or union type with copy constructors
- that are known not to throw an exception then the trait is true,
- else it is false. Requires: `type' shall be a complete type,
- (possibly cv-qualified) `void', or an array of unknown bound.
-
-`__has_nothrow_constructor (type)'
- If `__has_trivial_constructor (type)' is true then the trait is
- true, else if `type' is a cv class or union type (or array
- thereof) with a default constructor that is known not to throw an
- exception then the trait is true, else it is false. Requires:
- `type' shall be a complete type, (possibly cv-qualified) `void',
- or an array of unknown bound.
-
-`__has_trivial_assign (type)'
- If `type' is const qualified or is a reference type then the trait
- is false. Otherwise if `__is_pod (type)' is true then the trait is
- true, else if `type' is a cv class or union type with a trivial
- copy assignment ([class.copy]) then the trait is true, else it is
- false. Requires: `type' shall be a complete type, (possibly
- cv-qualified) `void', or an array of unknown bound.
-
-`__has_trivial_copy (type)'
- If `__is_pod (type)' is true or `type' is a reference type then
- the trait is true, else if `type' is a cv class or union type with
- a trivial copy constructor ([class.copy]) then the trait is true,
- else it is false. Requires: `type' shall be a complete type,
- (possibly cv-qualified) `void', or an array of unknown bound.
-
-`__has_trivial_constructor (type)'
- If `__is_pod (type)' is true then the trait is true, else if
- `type' is a cv class or union type (or array thereof) with a
- trivial default constructor ([class.ctor]) then the trait is true,
- else it is false. Requires: `type' shall be a complete type,
- (possibly cv-qualified) `void', or an array of unknown bound.
-
-`__has_trivial_destructor (type)'
- If `__is_pod (type)' is true or `type' is a reference type then
- the trait is true, else if `type' is a cv class or union type (or
- array thereof) with a trivial destructor ([class.dtor]) then the
- trait is true, else it is false. Requires: `type' shall be a
- complete type, (possibly cv-qualified) `void', or an array of
- unknown bound.
-
-`__has_virtual_destructor (type)'
- If `type' is a class type with a virtual destructor ([class.dtor])
- then the trait is true, else it is false. Requires: `type' shall
- be a complete type, (possibly cv-qualified) `void', or an array of
- unknown bound.
-
-`__is_abstract (type)'
- If `type' is an abstract class ([class.abstract]) then the trait
- is true, else it is false. Requires: `type' shall be a complete
- type, (possibly cv-qualified) `void', or an array of unknown bound.
-
-`__is_base_of (base_type, derived_type)'
- If `base_type' is a base class of `derived_type' ([class.derived])
- then the trait is true, otherwise it is false. Top-level cv
- qualifications of `base_type' and `derived_type' are ignored. For
- the purposes of this trait, a class type is considered is own
- base. Requires: if `__is_class (base_type)' and `__is_class
- (derived_type)' are true and `base_type' and `derived_type' are
- not the same type (disregarding cv-qualifiers), `derived_type'
- shall be a complete type. Diagnostic is produced if this
- requirement is not met.
-
-`__is_class (type)'
- If `type' is a cv class type, and not a union type
- ([basic.compound]) the trait is true, else it is false.
-
-`__is_empty (type)'
- If `__is_class (type)' is false then the trait is false.
- Otherwise `type' is considered empty if and only if: `type' has no
- non-static data members, or all non-static data members, if any,
- are bit-fields of length 0, and `type' has no virtual members, and
- `type' has no virtual base classes, and `type' has no base classes
- `base_type' for which `__is_empty (base_type)' is false.
- Requires: `type' shall be a complete type, (possibly cv-qualified)
- `void', or an array of unknown bound.
-
-`__is_enum (type)'
- If `type' is a cv enumeration type ([basic.compound]) the trait is
- true, else it is false.
-
-`__is_literal_type (type)'
- If `type' is a literal type ([basic.types]) the trait is true,
- else it is false. Requires: `type' shall be a complete type,
- (possibly cv-qualified) `void', or an array of unknown bound.
-
-`__is_pod (type)'
- If `type' is a cv POD type ([basic.types]) then the trait is true,
- else it is false. Requires: `type' shall be a complete type,
- (possibly cv-qualified) `void', or an array of unknown bound.
-
-`__is_polymorphic (type)'
- If `type' is a polymorphic class ([class.virtual]) then the trait
- is true, else it is false. Requires: `type' shall be a complete
- type, (possibly cv-qualified) `void', or an array of unknown bound.
-
-`__is_standard_layout (type)'
- If `type' is a standard-layout type ([basic.types]) the trait is
- true, else it is false. Requires: `type' shall be a complete
- type, (possibly cv-qualified) `void', or an array of unknown bound.
-
-`__is_trivial (type)'
- If `type' is a trivial type ([basic.types]) the trait is true,
- else it is false. Requires: `type' shall be a complete type,
- (possibly cv-qualified) `void', or an array of unknown bound.
-
-`__is_union (type)'
- If `type' is a cv union type ([basic.compound]) the trait is true,
- else it is false.
-
-
-
-File: gcc.info, Node: Java Exceptions, Next: Deprecated Features, Prev: Type Traits, Up: C++ Extensions
-
-7.10 Java Exceptions
-====================
-
-The Java language uses a slightly different exception handling model
-from C++. Normally, GNU C++ will automatically detect when you are
-writing C++ code that uses Java exceptions, and handle them
-appropriately. However, if C++ code only needs to execute destructors
-when Java exceptions are thrown through it, GCC will guess incorrectly.
-Sample problematic code is:
-
- struct S { ~S(); };
- extern void bar(); // is written in Java, and may throw exceptions
- void foo()
- {
- S s;
- bar();
- }
-
-The usual effect of an incorrect guess is a link failure, complaining of
-a missing routine called `__gxx_personality_v0'.
-
- You can inform the compiler that Java exceptions are to be used in a
-translation unit, irrespective of what it might think, by writing
-`#pragma GCC java_exceptions' at the head of the file. This `#pragma'
-must appear before any functions that throw or catch exceptions, or run
-destructors when exceptions are thrown through them.
-
- You cannot mix Java and C++ exceptions in the same translation unit.
-It is believed to be safe to throw a C++ exception from one file through
-another file compiled for the Java exception model, or vice versa, but
-there may be bugs in this area.
-
-
-File: gcc.info, Node: Deprecated Features, Next: Backwards Compatibility, Prev: Java Exceptions, Up: C++ Extensions
-
-7.11 Deprecated Features
-========================
-
-In the past, the GNU C++ compiler was extended to experiment with new
-features, at a time when the C++ language was still evolving. Now that
-the C++ standard is complete, some of those features are superseded by
-superior alternatives. Using the old features might cause a warning in
-some cases that the feature will be dropped in the future. In other
-cases, the feature might be gone already.
-
- While the list below is not exhaustive, it documents some of the
-options that are now deprecated:
-
-`-fexternal-templates'
-`-falt-external-templates'
- These are two of the many ways for G++ to implement template
- instantiation. *Note Template Instantiation::. The C++ standard
- clearly defines how template definitions have to be organized
- across implementation units. G++ has an implicit instantiation
- mechanism that should work just fine for standard-conforming code.
-
-`-fstrict-prototype'
-`-fno-strict-prototype'
- Previously it was possible to use an empty prototype parameter
- list to indicate an unspecified number of parameters (like C),
- rather than no parameters, as C++ demands. This feature has been
- removed, except where it is required for backwards compatibility.
- *Note Backwards Compatibility::.
-
- G++ allows a virtual function returning `void *' to be overridden by
-one returning a different pointer type. This extension to the
-covariant return type rules is now deprecated and will be removed from a
-future version.
-
- The G++ minimum and maximum operators (`<?' and `>?') and their
-compound forms (`<?=') and `>?=') have been deprecated and are now
-removed from G++. Code using these operators should be modified to use
-`std::min' and `std::max' instead.
-
- The named return value extension has been deprecated, and is now
-removed from G++.
-
- The use of initializer lists with new expressions has been deprecated,
-and is now removed from G++.
-
- Floating and complex non-type template parameters have been deprecated,
-and are now removed from G++.
-
- The implicit typename extension has been deprecated and is now removed
-from G++.
-
- The use of default arguments in function pointers, function typedefs
-and other places where they are not permitted by the standard is
-deprecated and will be removed from a future version of G++.
-
- G++ allows floating-point literals to appear in integral constant
-expressions, e.g. ` enum E { e = int(2.2 * 3.7) } ' This extension is
-deprecated and will be removed from a future version.
-
- G++ allows static data members of const floating-point type to be
-declared with an initializer in a class definition. The standard only
-allows initializers for static members of const integral types and const
-enumeration types so this extension has been deprecated and will be
-removed from a future version.
-
-
-File: gcc.info, Node: Backwards Compatibility, Prev: Deprecated Features, Up: C++ Extensions
-
-7.12 Backwards Compatibility
-============================
-
-Now that there is a definitive ISO standard C++, G++ has a specification
-to adhere to. The C++ language evolved over time, and features that
-used to be acceptable in previous drafts of the standard, such as the
-ARM [Annotated C++ Reference Manual], are no longer accepted. In order
-to allow compilation of C++ written to such drafts, G++ contains some
-backwards compatibilities. _All such backwards compatibility features
-are liable to disappear in future versions of G++._ They should be
-considered deprecated. *Note Deprecated Features::.
-
-`For scope'
- If a variable is declared at for scope, it used to remain in scope
- until the end of the scope which contained the for statement
- (rather than just within the for scope). G++ retains this, but
- issues a warning, if such a variable is accessed outside the for
- scope.
-
-`Implicit C language'
- Old C system header files did not contain an `extern "C" {...}'
- scope to set the language. On such systems, all header files are
- implicitly scoped inside a C language scope. Also, an empty
- prototype `()' will be treated as an unspecified number of
- arguments, rather than no arguments, as C++ demands.
-
-
-File: gcc.info, Node: Objective-C, Next: Compatibility, Prev: C++ Extensions, Up: Top
-
-8 GNU Objective-C features
-**************************
-
-This document is meant to describe some of the GNU Objective-C
-features. It is not intended to teach you Objective-C. There are
-several resources on the Internet that present the language.
-
-* Menu:
-
-* GNU Objective-C runtime API::
-* Executing code before main::
-* Type encoding::
-* Garbage Collection::
-* Constant string objects::
-* compatibility_alias::
-* Exceptions::
-* Synchronization::
-* Fast enumeration::
-* Messaging with the GNU Objective-C runtime::
-
-
-File: gcc.info, Node: GNU Objective-C runtime API, Next: Executing code before main, Up: Objective-C
-
-8.1 GNU Objective-C runtime API
-===============================
-
-This section is specific for the GNU Objective-C runtime. If you are
-using a different runtime, you can skip it.
-
- The GNU Objective-C runtime provides an API that allows you to
-interact with the Objective-C runtime system, querying the live runtime
-structures and even manipulating them. This allows you for example to
-inspect and navigate classes, methods and protocols; to define new
-classes or new methods, and even to modify existing classes or
-protocols.
-
- If you are using a "Foundation" library such as GNUstep-Base, this
-library will provide you with a rich set of functionality to do most of
-the inspection tasks, and you probably will only need direct access to
-the GNU Objective-C runtime API to define new classes or methods.
-
-* Menu:
-
-* Modern GNU Objective-C runtime API::
-* Traditional GNU Objective-C runtime API::
-
-
-File: gcc.info, Node: Modern GNU Objective-C runtime API, Next: Traditional GNU Objective-C runtime API, Up: GNU Objective-C runtime API
-
-8.1.1 Modern GNU Objective-C runtime API
-----------------------------------------
-
-The GNU Objective-C runtime provides an API which is similar to the one
-provided by the "Objective-C 2.0" Apple/NeXT Objective-C runtime. The
-API is documented in the public header files of the GNU Objective-C
-runtime:
-
- * `objc/objc.h': this is the basic Objective-C header file, defining
- the basic Objective-C types such as `id', `Class' and `BOOL'. You
- have to include this header to do almost anything with Objective-C.
-
- * `objc/runtime.h': this header declares most of the public runtime
- API functions allowing you to inspect and manipulate the
- Objective-C runtime data structures. These functions are fairly
- standardized across Objective-C runtimes and are almost identical
- to the Apple/NeXT Objective-C runtime ones. It does not declare
- functions in some specialized areas (constructing and forwarding
- message invocations, threading) which are in the other headers
- below. You have to include `objc/objc.h' and `objc/runtime.h' to
- use any of the functions, such as `class_getName()', declared in
- `objc/runtime.h'.
-
- * `objc/message.h': this header declares public functions used to
- construct, deconstruct and forward message invocations. Because
- messaging is done in quite a different way on different runtimes,
- functions in this header are specific to the GNU Objective-C
- runtime implementation.
-
- * `objc/objc-exception.h': this header declares some public
- functions related to Objective-C exceptions. For example
- functions in this header allow you to throw an Objective-C
- exception from plain C/C++ code.
-
- * `objc/objc-sync.h': this header declares some public functions
- related to the Objective-C `@synchronized()' syntax, allowing you
- to emulate an Objective-C `@synchronized()' block in plain C/C++
- code.
-
- * `objc/thr.h': this header declares a public runtime API threading
- layer that is only provided by the GNU Objective-C runtime. It
- declares functions such as `objc_mutex_lock()', which provide a
- platform-independent set of threading functions.
-
-
- The header files contain detailed documentation for each function in
-the GNU Objective-C runtime API.
-
-
-File: gcc.info, Node: Traditional GNU Objective-C runtime API, Prev: Modern GNU Objective-C runtime API, Up: GNU Objective-C runtime API
-
-8.1.2 Traditional GNU Objective-C runtime API
----------------------------------------------
-
-The GNU Objective-C runtime used to provide a different API, which we
-call the "traditional" GNU Objective-C runtime API. Functions
-belonging to this API are easy to recognize because they use a
-different naming convention, such as `class_get_super_class()'
-(traditional API) instead of `class_getSuperclass()' (modern API).
-Software using this API includes the file `objc/objc-api.h' where it is
-declared.
-
- The traditional API is deprecated but it is still supported in this
-release of the runtime; you can access it as usual by including
-`objc/objc-api.h'.
-
- If you are using the traditional API you are urged to upgrade your
-software to use the modern API because the traditional API requires
-access to private runtime internals to do anything serious with it; for
-this reason, there is no guarantee that future releases of the GNU
-Objective-C runtime library will be able to provide a fully compatible
-`objc/objc-api.h' as the private runtime internals change. It is
-expected that the next release will hide a number of runtime internals
-making the traditional API nominally supported but fairly useless
-beyond very simple use cases.
-
- Finally, you can not include both `objc/objc-api.h' and
-`objc/runtime.h' at the same time. The traditional and modern APIs
-unfortunately have some conflicting declarations (such as the one for
-`Method') and can not be used at the same time.
-
-
-File: gcc.info, Node: Executing code before main, Next: Type encoding, Prev: GNU Objective-C runtime API, Up: Objective-C
-
-8.2 `+load': Executing code before main
-=======================================
-
-This section is specific for the GNU Objective-C runtime. If you are
-using a different runtime, you can skip it.
-
- The GNU Objective-C runtime provides a way that allows you to execute
-code before the execution of the program enters the `main' function.
-The code is executed on a per-class and a per-category basis, through a
-special class method `+load'.
-
- This facility is very useful if you want to initialize global variables
-which can be accessed by the program directly, without sending a message
-to the class first. The usual way to initialize global variables, in
-the `+initialize' method, might not be useful because `+initialize' is
-only called when the first message is sent to a class object, which in
-some cases could be too late.
-
- Suppose for example you have a `FileStream' class that declares
-`Stdin', `Stdout' and `Stderr' as global variables, like below:
-
-
- FileStream *Stdin = nil;
- FileStream *Stdout = nil;
- FileStream *Stderr = nil;
-
- @implementation FileStream
-
- + (void)initialize
- {
- Stdin = [[FileStream new] initWithFd:0];
- Stdout = [[FileStream new] initWithFd:1];
- Stderr = [[FileStream new] initWithFd:2];
- }
-
- /* Other methods here */
- @end
-
- In this example, the initialization of `Stdin', `Stdout' and `Stderr'
-in `+initialize' occurs too late. The programmer can send a message to
-one of these objects before the variables are actually initialized,
-thus sending messages to the `nil' object. The `+initialize' method
-which actually initializes the global variables is not invoked until
-the first message is sent to the class object. The solution would
-require these variables to be initialized just before entering `main'.
-
- The correct solution of the above problem is to use the `+load' method
-instead of `+initialize':
-
-
- @implementation FileStream
-
- + (void)load
- {
- Stdin = [[FileStream new] initWithFd:0];
- Stdout = [[FileStream new] initWithFd:1];
- Stderr = [[FileStream new] initWithFd:2];
- }
-
- /* Other methods here */
- @end
-
- The `+load' is a method that is not overridden by categories. If a
-class and a category of it both implement `+load', both methods are
-invoked. This allows some additional initializations to be performed in
-a category.
-
- This mechanism is not intended to be a replacement for `+initialize'.
-You should be aware of its limitations when you decide to use it
-instead of `+initialize'.
-
-* Menu:
-
-* What you can and what you cannot do in +load::
-
-
-File: gcc.info, Node: What you can and what you cannot do in +load, Up: Executing code before main
-
-8.2.1 What you can and what you cannot do in `+load'
-----------------------------------------------------
-
-`+load' is to be used only as a last resort. Because it is executed
-very early, most of the Objective-C runtime machinery will not be ready
-when `+load' is executed; hence `+load' works best for executing C code
-that is independent on the Objective-C runtime.
-
- The `+load' implementation in the GNU runtime guarantees you the
-following things:
-
- * you can write whatever C code you like;
-
- * you can allocate and send messages to objects whose class is
- implemented in the same file;
-
- * the `+load' implementation of all super classes of a class are
- executed before the `+load' of that class is executed;
-
- * the `+load' implementation of a class is executed before the
- `+load' implementation of any category.
-
-
- In particular, the following things, even if they can work in a
-particular case, are not guaranteed:
-
- * allocation of or sending messages to arbitrary objects;
-
- * allocation of or sending messages to objects whose classes have a
- category implemented in the same file;
-
- * sending messages to Objective-C constant strings (`@"this is a
- constant string"');
-
-
- You should make no assumptions about receiving `+load' in sibling
-classes when you write `+load' of a class. The order in which sibling
-classes receive `+load' is not guaranteed.
-
- The order in which `+load' and `+initialize' are called could be
-problematic if this matters. If you don't allocate objects inside
-`+load', it is guaranteed that `+load' is called before `+initialize'.
-If you create an object inside `+load' the `+initialize' method of
-object's class is invoked even if `+load' was not invoked. Note if you
-explicitly call `+load' on a class, `+initialize' will be called first.
-To avoid possible problems try to implement only one of these methods.
-
- The `+load' method is also invoked when a bundle is dynamically loaded
-into your running program. This happens automatically without any
-intervening operation from you. When you write bundles and you need to
-write `+load' you can safely create and send messages to objects whose
-classes already exist in the running program. The same restrictions as
-above apply to classes defined in bundle.
-
-
-File: gcc.info, Node: Type encoding, Next: Garbage Collection, Prev: Executing code before main, Up: Objective-C
-
-8.3 Type encoding
-=================
-
-This is an advanced section. Type encodings are used extensively by
-the compiler and by the runtime, but you generally do not need to know
-about them to use Objective-C.
-
- The Objective-C compiler generates type encodings for all the types.
-These type encodings are used at runtime to find out information about
-selectors and methods and about objects and classes.
-
- The types are encoded in the following way:
-
-`_Bool' `B'
-`char' `c'
-`unsigned char' `C'
-`short' `s'
-`unsigned short' `S'
-`int' `i'
-`unsigned int' `I'
-`long' `l'
-`unsigned long' `L'
-`long long' `q'
-`unsigned long `Q'
-long'
-`float' `f'
-`double' `d'
-`long double' `D'
-`void' `v'
-`id' `@'
-`Class' `#'
-`SEL' `:'
-`char*' `*'
-`enum' an `enum' is encoded exactly as the integer type that
- the compiler uses for it, which depends on the
- enumeration values. Often the compiler users
- `unsigned int', which is then encoded as `I'.
-unknown type `?'
-Complex types `j' followed by the inner type. For example
- `_Complex double' is encoded as "jd".
-bit-fields `b' followed by the starting position of the
- bit-field, the type of the bit-field and the size of
- the bit-field (the bit-fields encoding was changed
- from the NeXT's compiler encoding, see below)
-
- The encoding of bit-fields has changed to allow bit-fields to be
-properly handled by the runtime functions that compute sizes and
-alignments of types that contain bit-fields. The previous encoding
-contained only the size of the bit-field. Using only this information
-it is not possible to reliably compute the size occupied by the
-bit-field. This is very important in the presence of the Boehm's
-garbage collector because the objects are allocated using the typed
-memory facility available in this collector. The typed memory
-allocation requires information about where the pointers are located
-inside the object.
-
- The position in the bit-field is the position, counting in bits, of the
-bit closest to the beginning of the structure.
-
- The non-atomic types are encoded as follows:
-
-pointers `^' followed by the pointed type.
-arrays `[' followed by the number of elements in the array
- followed by the type of the elements followed by `]'
-structures `{' followed by the name of the structure (or `?' if the
- structure is unnamed), the `=' sign, the type of the
- members and by `}'
-unions `(' followed by the name of the structure (or `?' if the
- union is unnamed), the `=' sign, the type of the members
- followed by `)'
-vectors `![' followed by the vector_size (the number of bytes
- composing the vector) followed by a comma, followed by
- the alignment (in bytes) of the vector, followed by the
- type of the elements followed by `]'
-
- Here are some types and their encodings, as they are generated by the
-compiler on an i386 machine:
-
-
-Objective-C type Compiler encoding
- int a[10]; `[10i]'
- struct { `{?=i[3f]b128i3b131i2c}'
- int i;
- float f[3];
- int a:3;
- int b:2;
- char c;
- }
- int a __attribute__ ((vector_size (16)));`![16,16i]' (alignment would depend on the machine)
-
-
- In addition to the types the compiler also encodes the type
-specifiers. The table below describes the encoding of the current
-Objective-C type specifiers:
-
-
-Specifier Encoding
-`const' `r'
-`in' `n'
-`inout' `N'
-`out' `o'
-`bycopy' `O'
-`byref' `R'
-`oneway' `V'
-
-
- The type specifiers are encoded just before the type. Unlike types
-however, the type specifiers are only encoded when they appear in method
-argument types.
-
- Note how `const' interacts with pointers:
-
-
-Objective-C type Compiler encoding
- const int `ri'
- const int* `^ri'
- int *const `r^i'
-
-
- `const int*' is a pointer to a `const int', and so is encoded as
-`^ri'. `int* const', instead, is a `const' pointer to an `int', and so
-is encoded as `r^i'.
-
- Finally, there is a complication when encoding `const char *' versus
-`char * const'. Because `char *' is encoded as `*' and not as `^c',
-there is no way to express the fact that `r' applies to the pointer or
-to the pointee.
-
- Hence, it is assumed as a convention that `r*' means `const char *'
-(since it is what is most often meant), and there is no way to encode
-`char *const'. `char *const' would simply be encoded as `*', and the
-`const' is lost.
-
-* Menu:
-
-* Legacy type encoding::
-* @encode::
-* Method signatures::
-
-
-File: gcc.info, Node: Legacy type encoding, Next: @encode, Up: Type encoding
-
-8.3.1 Legacy type encoding
---------------------------
-
-Unfortunately, historically GCC used to have a number of bugs in its
-encoding code. The NeXT runtime expects GCC to emit type encodings in
-this historical format (compatible with GCC-3.3), so when using the
-NeXT runtime, GCC will introduce on purpose a number of incorrect
-encodings:
-
- * the read-only qualifier of the pointee gets emitted before the '^'.
- The read-only qualifier of the pointer itself gets ignored, unless
- it is a typedef. Also, the 'r' is only emitted for the outermost
- type.
-
- * 32-bit longs are encoded as 'l' or 'L', but not always. For
- typedefs, the compiler uses 'i' or 'I' instead if encoding a
- struct field or a pointer.
-
- * `enum's are always encoded as 'i' (int) even if they are actually
- unsigned or long.
-
-
- In addition to that, the NeXT runtime uses a different encoding for
-bitfields. It encodes them as `b' followed by the size, without a bit
-offset or the underlying field type.
-
-
-File: gcc.info, Node: @encode, Next: Method signatures, Prev: Legacy type encoding, Up: Type encoding
-
-8.3.2 @encode
--------------
-
-GNU Objective-C supports the `@encode' syntax that allows you to create
-a type encoding from a C/Objective-C type. For example, `@encode(int)'
-is compiled by the compiler into `"i"'.
-
- `@encode' does not support type qualifiers other than `const'. For
-example, `@encode(const char*)' is valid and is compiled into `"r*"',
-while `@encode(bycopy char *)' is invalid and will cause a compilation
-error.
-
-
-File: gcc.info, Node: Method signatures, Prev: @encode, Up: Type encoding
-
-8.3.3 Method signatures
------------------------
-
-This section documents the encoding of method types, which is rarely
-needed to use Objective-C. You should skip it at a first reading; the
-runtime provides functions that will work on methods and can walk
-through the list of parameters and interpret them for you. These
-functions are part of the public "API" and are the preferred way to
-interact with method signatures from user code.
-
- But if you need to debug a problem with method signatures and need to
-know how they are implemented (i.e., the "ABI"), read on.
-
- Methods have their "signature" encoded and made available to the
-runtime. The "signature" encodes all the information required to
-dynamically build invocations of the method at runtime: return type and
-arguments.
-
- The "signature" is a null-terminated string, composed of the following:
-
- * The return type, including type qualifiers. For example, a method
- returning `int' would have `i' here.
-
- * The total size (in bytes) required to pass all the parameters.
- This includes the two hidden parameters (the object `self' and the
- method selector `_cmd').
-
- * Each argument, with the type encoding, followed by the offset (in
- bytes) of the argument in the list of parameters.
-
-
- For example, a method with no arguments and returning `int' would have
-the signature `i8@0:4' if the size of a pointer is 4. The signature is
-interpreted as follows: the `i' is the return type (an `int'), the `8'
-is the total size of the parameters in bytes (two pointers each of size
-4), the `@0' is the first parameter (an object at byte offset `0') and
-`:4' is the second parameter (a `SEL' at byte offset `4').
-
- You can easily find more examples by running the "strings" program on
-an Objective-C object file compiled by GCC. You'll see a lot of
-strings that look very much like `i8@0:4'. They are signatures of
-Objective-C methods.
-
-
-File: gcc.info, Node: Garbage Collection, Next: Constant string objects, Prev: Type encoding, Up: Objective-C
-
-8.4 Garbage Collection
-======================
-
-This section is specific for the GNU Objective-C runtime. If you are
-using a different runtime, you can skip it.
-
- Support for garbage collection with the GNU runtime has been added by
-using a powerful conservative garbage collector, known as the
-Boehm-Demers-Weiser conservative garbage collector.
-
- To enable the support for it you have to configure the compiler using
-an additional argument, `--enable-objc-gc'. This will build the
-boehm-gc library, and build an additional runtime library which has
-several enhancements to support the garbage collector. The new library
-has a new name, `libobjc_gc.a' to not conflict with the
-non-garbage-collected library.
-
- When the garbage collector is used, the objects are allocated using the
-so-called typed memory allocation mechanism available in the
-Boehm-Demers-Weiser collector. This mode requires precise information
-on where pointers are located inside objects. This information is
-computed once per class, immediately after the class has been
-initialized.
-
- There is a new runtime function `class_ivar_set_gcinvisible()' which
-can be used to declare a so-called "weak pointer" reference. Such a
-pointer is basically hidden for the garbage collector; this can be
-useful in certain situations, especially when you want to keep track of
-the allocated objects, yet allow them to be collected. This kind of
-pointers can only be members of objects, you cannot declare a global
-pointer as a weak reference. Every type which is a pointer type can be
-declared a weak pointer, including `id', `Class' and `SEL'.
-
- Here is an example of how to use this feature. Suppose you want to
-implement a class whose instances hold a weak pointer reference; the
-following class does this:
-
-
- @interface WeakPointer : Object
- {
- const void* weakPointer;
- }
-
- - initWithPointer:(const void*)p;
- - (const void*)weakPointer;
- @end
-
-
- @implementation WeakPointer
-
- + (void)initialize
- {
- class_ivar_set_gcinvisible (self, "weakPointer", YES);
- }
-
- - initWithPointer:(const void*)p
- {
- weakPointer = p;
- return self;
- }
-
- - (const void*)weakPointer
- {
- return weakPointer;
- }
-
- @end
-
- Weak pointers are supported through a new type character specifier
-represented by the `!' character. The `class_ivar_set_gcinvisible()'
-function adds or removes this specifier to the string type description
-of the instance variable named as argument.
-
-
-File: gcc.info, Node: Constant string objects, Next: compatibility_alias, Prev: Garbage Collection, Up: Objective-C
-
-8.5 Constant string objects
-===========================
-
-GNU Objective-C provides constant string objects that are generated
-directly by the compiler. You declare a constant string object by
-prefixing a C constant string with the character `@':
-
- id myString = @"this is a constant string object";
-
- The constant string objects are by default instances of the
-`NXConstantString' class which is provided by the GNU Objective-C
-runtime. To get the definition of this class you must include the
-`objc/NXConstStr.h' header file.
-
- User defined libraries may want to implement their own constant string
-class. To be able to support them, the GNU Objective-C compiler
-provides a new command line options
-`-fconstant-string-class=CLASS-NAME'. The provided class should adhere
-to a strict structure, the same as `NXConstantString''s structure:
-
-
- @interface MyConstantStringClass
- {
- Class isa;
- char *c_string;
- unsigned int len;
- }
- @end
-
- `NXConstantString' inherits from `Object'; user class libraries may
-choose to inherit the customized constant string class from a different
-class than `Object'. There is no requirement in the methods the
-constant string class has to implement, but the final ivar layout of
-the class must be the compatible with the given structure.
-
- When the compiler creates the statically allocated constant string
-object, the `c_string' field will be filled by the compiler with the
-string; the `length' field will be filled by the compiler with the
-string length; the `isa' pointer will be filled with `NULL' by the
-compiler, and it will later be fixed up automatically at runtime by the
-GNU Objective-C runtime library to point to the class which was set by
-the `-fconstant-string-class' option when the object file is loaded (if
-you wonder how it works behind the scenes, the name of the class to
-use, and the list of static objects to fixup, are stored by the
-compiler in the object file in a place where the GNU runtime library
-will find them at runtime).
-
- As a result, when a file is compiled with the
-`-fconstant-string-class' option, all the constant string objects will
-be instances of the class specified as argument to this option. It is
-possible to have multiple compilation units referring to different
-constant string classes, neither the compiler nor the linker impose any
-restrictions in doing this.
-
-
-File: gcc.info, Node: compatibility_alias, Next: Exceptions, Prev: Constant string objects, Up: Objective-C
-
-8.6 compatibility_alias
-=======================
-
-The keyword `@compatibility_alias' allows you to define a class name as
-equivalent to another class name. For example:
-
- @compatibility_alias WOApplication GSWApplication;
-
- tells the compiler that each time it encounters `WOApplication' as a
-class name, it should replace it with `GSWApplication' (that is,
-`WOApplication' is just an alias for `GSWApplication').
-
- There are some constraints on how this can be used--
-
- * `WOApplication' (the alias) must not be an existing class;
-
- * `GSWApplication' (the real class) must be an existing class.
-
-
-
-File: gcc.info, Node: Exceptions, Next: Synchronization, Prev: compatibility_alias, Up: Objective-C
-
-8.7 Exceptions
-==============
-
-GNU Objective-C provides exception support built into the language, as
-in the following example:
-
- @try {
- ...
- @throw expr;
- ...
- }
- @catch (AnObjCClass *exc) {
- ...
- @throw expr;
- ...
- @throw;
- ...
- }
- @catch (AnotherClass *exc) {
- ...
- }
- @catch (id allOthers) {
- ...
- }
- @finally {
- ...
- @throw expr;
- ...
- }
-
- The `@throw' statement may appear anywhere in an Objective-C or
-Objective-C++ program; when used inside of a `@catch' block, the
-`@throw' may appear without an argument (as shown above), in which case
-the object caught by the `@catch' will be rethrown.
-
- Note that only (pointers to) Objective-C objects may be thrown and
-caught using this scheme. When an object is thrown, it will be caught
-by the nearest `@catch' clause capable of handling objects of that
-type, analogously to how `catch' blocks work in C++ and Java. A
-`@catch(id ...)' clause (as shown above) may also be provided to catch
-any and all Objective-C exceptions not caught by previous `@catch'
-clauses (if any).
-
- The `@finally' clause, if present, will be executed upon exit from the
-immediately preceding `@try ... @catch' section. This will happen
-regardless of whether any exceptions are thrown, caught or rethrown
-inside the `@try ... @catch' section, analogously to the behavior of
-the `finally' clause in Java.
-
- There are several caveats to using the new exception mechanism:
-
- * The `-fobjc-exceptions' command line option must be used when
- compiling Objective-C files that use exceptions.
-
- * With the GNU runtime, exceptions are always implemented as "native"
- exceptions and it is recommended that the `-fexceptions' and
- `-shared-libgcc' options are used when linking.
-
- * With the NeXT runtime, although currently designed to be binary
- compatible with `NS_HANDLER'-style idioms provided by the
- `NSException' class, the new exceptions can only be used on Mac OS
- X 10.3 (Panther) and later systems, due to additional functionality
- needed in the NeXT Objective-C runtime.
-
- * As mentioned above, the new exceptions do not support handling
- types other than Objective-C objects. Furthermore, when used from
- Objective-C++, the Objective-C exception model does not
- interoperate with C++ exceptions at this time. This means you
- cannot `@throw' an exception from Objective-C and `catch' it in
- C++, or vice versa (i.e., `throw ... @catch').
-
-
-File: gcc.info, Node: Synchronization, Next: Fast enumeration, Prev: Exceptions, Up: Objective-C
-
-8.8 Synchronization
-===================
-
-GNU Objective-C provides support for synchronized blocks:
-
- @synchronized (ObjCClass *guard) {
- ...
- }
-
- Upon entering the `@synchronized' block, a thread of execution shall
-first check whether a lock has been placed on the corresponding `guard'
-object by another thread. If it has, the current thread shall wait
-until the other thread relinquishes its lock. Once `guard' becomes
-available, the current thread will place its own lock on it, execute
-the code contained in the `@synchronized' block, and finally relinquish
-the lock (thereby making `guard' available to other threads).
-
- Unlike Java, Objective-C does not allow for entire methods to be
-marked `@synchronized'. Note that throwing exceptions out of
-`@synchronized' blocks is allowed, and will cause the guarding object
-to be unlocked properly.
-
- Because of the interactions between synchronization and exception
-handling, you can only use `@synchronized' when compiling with
-exceptions enabled, that is with the command line option
-`-fobjc-exceptions'.
-
-
-File: gcc.info, Node: Fast enumeration, Next: Messaging with the GNU Objective-C runtime, Prev: Synchronization, Up: Objective-C
-
-8.9 Fast enumeration
-====================
-
-* Menu:
-
-* Using fast enumeration::
-* c99-like fast enumeration syntax::
-* Fast enumeration details::
-* Fast enumeration protocol::
-
-
-File: gcc.info, Node: Using fast enumeration, Next: c99-like fast enumeration syntax, Up: Fast enumeration
-
-8.9.1 Using fast enumeration
-----------------------------
-
-GNU Objective-C provides support for the fast enumeration syntax:
-
- id array = ...;
- id object;
-
- for (object in array)
- {
- /* Do something with 'object' */
- }
-
- `array' needs to be an Objective-C object (usually a collection
-object, for example an array, a dictionary or a set) which implements
-the "Fast Enumeration Protocol" (see below). If you are using a
-Foundation library such as GNUstep Base or Apple Cocoa Foundation, all
-collection objects in the library implement this protocol and can be
-used in this way.
-
- The code above would iterate over all objects in `array'. For each of
-them, it assigns it to `object', then executes the `Do something with
-'object'' statements.
-
- Here is a fully worked-out example using a Foundation library (which
-provides the implementation of `NSArray', `NSString' and `NSLog'):
-
- NSArray *array = [NSArray arrayWithObjects: @"1", @"2", @"3", nil];
- NSString *object;
-
- for (object in array)
- NSLog (@"Iterating over %@", object);
-
-
-File: gcc.info, Node: c99-like fast enumeration syntax, Next: Fast enumeration details, Prev: Using fast enumeration, Up: Fast enumeration
-
-8.9.2 c99-like fast enumeration syntax
---------------------------------------
-
-A c99-like declaration syntax is also allowed:
-
- id array = ...;
-
- for (id object in array)
- {
- /* Do something with 'object' */
- }
-
- this is completely equivalent to:
-
- id array = ...;
-
- {
- id object;
- for (object in array)
- {
- /* Do something with 'object' */
- }
- }
-
- but can save some typing.
-
- Note that the option `-std=c99' is not required to allow this syntax
-in Objective-C.
-
-
-File: gcc.info, Node: Fast enumeration details, Next: Fast enumeration protocol, Prev: c99-like fast enumeration syntax, Up: Fast enumeration
-
-8.9.3 Fast enumeration details
-------------------------------
-
-Here is a more technical description with the gory details. Consider
-the code
-
- for (OBJECT EXPRESSION in COLLECTION EXPRESSION)
- {
- STATEMENTS
- }
-
- here is what happens when you run it:
-
- * `COLLECTION EXPRESSION' is evaluated exactly once and the result
- is used as the collection object to iterate over. This means it
- is safe to write code such as `for (object in [NSDictionary
- keyEnumerator]) ...'.
-
- * the iteration is implemented by the compiler by repeatedly getting
- batches of objects from the collection object using the fast
- enumeration protocol (see below), then iterating over all objects
- in the batch. This is faster than a normal enumeration where
- objects are retrieved one by one (hence the name "fast
- enumeration").
-
- * if there are no objects in the collection, then `OBJECT
- EXPRESSION' is set to `nil' and the loop immediately terminates.
-
- * if there are objects in the collection, then for each object in the
- collection (in the order they are returned) `OBJECT EXPRESSION' is
- set to the object, then `STATEMENTS' are executed.
-
- * `STATEMENTS' can contain `break' and `continue' commands, which
- will abort the iteration or skip to the next loop iteration as
- expected.
-
- * when the iteration ends because there are no more objects to
- iterate over, `OBJECT EXPRESSION' is set to `nil'. This allows
- you to determine whether the iteration finished because a `break'
- command was used (in which case `OBJECT EXPRESSION' will remain
- set to the last object that was iterated over) or because it
- iterated over all the objects (in which case `OBJECT EXPRESSION'
- will be set to `nil').
-
- * `STATEMENTS' must not make any changes to the collection object;
- if they do, it is a hard error and the fast enumeration terminates
- by invoking `objc_enumerationMutation', a runtime function that
- normally aborts the program but which can be customized by
- Foundation libraries via `objc_set_mutation_handler' to do
- something different, such as raising an exception.
-
-
-
-File: gcc.info, Node: Fast enumeration protocol, Prev: Fast enumeration details, Up: Fast enumeration
-
-8.9.4 Fast enumeration protocol
--------------------------------
-
-If you want your own collection object to be usable with fast
-enumeration, you need to have it implement the method
-
- - (unsigned long) countByEnumeratingWithState: (NSFastEnumerationState *)state
- objects: (id *)objects
- count: (unsigned long)len;
-
- where `NSFastEnumerationState' must be defined in your code as follows:
-
- typedef struct
- {
- unsigned long state;
- id *itemsPtr;
- unsigned long *mutationsPtr;
- unsigned long extra[5];
- } NSFastEnumerationState;
-
- If no `NSFastEnumerationState' is defined in your code, the compiler
-will automatically replace `NSFastEnumerationState *' with `struct
-__objcFastEnumerationState *', where that type is silently defined by
-the compiler in an identical way. This can be confusing and we
-recommend that you define `NSFastEnumerationState' (as shown above)
-instead.
-
- The method is called repeatedly during a fast enumeration to retrieve
-batches of objects. Each invocation of the method should retrieve the
-next batch of objects.
-
- The return value of the method is the number of objects in the current
-batch; this should not exceed `len', which is the maximum size of a
-batch as requested by the caller. The batch itself is returned in the
-`itemsPtr' field of the `NSFastEnumerationState' struct.
-
- To help with returning the objects, the `objects' array is a C array
-preallocated by the caller (on the stack) of size `len'. In many cases
-you can put the objects you want to return in that `objects' array,
-then do `itemsPtr = objects'. But you don't have to; if your
-collection already has the objects to return in some form of C array,
-it could return them from there instead.
-
- The `state' and `extra' fields of the `NSFastEnumerationState'
-structure allows your collection object to keep track of the state of
-the enumeration. In a simple array implementation, `state' may keep
-track of the index of the last object that was returned, and `extra'
-may be unused.
-
- The `mutationsPtr' field of the `NSFastEnumerationState' is used to
-keep track of mutations. It should point to a number; before working
-on each object, the fast enumeration loop will check that this number
-has not changed. If it has, a mutation has happened and the fast
-enumeration will abort. So, `mutationsPtr' could be set to point to
-some sort of version number of your collection, which is increased by
-one every time there is a change (for example when an object is added
-or removed). Or, if you are content with less strict mutation checks,
-it could point to the number of objects in your collection or some
-other value that can be checked to perform an approximate check that
-the collection has not been mutated.
-
- Finally, note how we declared the `len' argument and the return value
-to be of type `unsigned long'. They could also be declared to be of
-type `unsigned int' and everything would still work.
-
-
-File: gcc.info, Node: Messaging with the GNU Objective-C runtime, Prev: Fast enumeration, Up: Objective-C
-
-8.10 Messaging with the GNU Objective-C runtime
-===============================================
-
-This section is specific for the GNU Objective-C runtime. If you are
-using a different runtime, you can skip it.
-
- The implementation of messaging in the GNU Objective-C runtime is
-designed to be portable, and so is based on standard C.
-
- Sending a message in the GNU Objective-C runtime is composed of two
-separate steps. First, there is a call to the lookup function,
-`objc_msg_lookup ()' (or, in the case of messages to super,
-`objc_msg_lookup_super ()'). This runtime function takes as argument
-the receiver and the selector of the method to be called; it returns
-the `IMP', that is a pointer to the function implementing the method.
-The second step of method invocation consists of casting this pointer
-function to the appropriate function pointer type, and calling the
-function pointed to it with the right arguments.
-
- For example, when the compiler encounters a method invocation such as
-`[object init]', it compiles it into a call to `objc_msg_lookup
-(object, @selector(init))' followed by a cast of the returned value to
-the appropriate function pointer type, and then it calls it.
-
-* Menu:
-
-* Dynamically registering methods::
-* Forwarding hook::
-
-
-File: gcc.info, Node: Dynamically registering methods, Next: Forwarding hook, Up: Messaging with the GNU Objective-C runtime
-
-8.10.1 Dynamically registering methods
---------------------------------------
-
-If `objc_msg_lookup()' does not find a suitable method implementation,
-because the receiver does not implement the required method, it tries
-to see if the class can dynamically register the method.
-
- To do so, the runtime checks if the class of the receiver implements
-the method
-
- + (BOOL) resolveInstanceMethod: (SEL)selector;
-
- in the case of an instance method, or
-
- + (BOOL) resolveClassMethod: (SEL)selector;
-
- in the case of a class method. If the class implements it, the
-runtime invokes it, passing as argument the selector of the original
-method, and if it returns `YES', the runtime tries the lookup again,
-which could now succeed if a matching method was added dynamically by
-`+resolveInstanceMethod:' or `+resolveClassMethod:'.
-
- This allows classes to dynamically register methods (by adding them to
-the class using `class_addMethod') when they are first called. To do
-so, a class should implement `+resolveInstanceMethod:' (or, depending
-on the case, `+resolveClassMethod:') and have it recognize the
-selectors of methods that can be registered dynamically at runtime,
-register them, and return `YES'. It should return `NO' for methods
-that it does not dynamically registered at runtime.
-
- If `+resolveInstanceMethod:' (or `+resolveClassMethod:') is not
-implemented or returns `NO', the runtime then tries the forwarding hook.
-
- Support for `+resolveInstanceMethod:' and `resolveClassMethod:' was
-added to the GNU Objective-C runtime in GCC version 4.6.
-
-
-File: gcc.info, Node: Forwarding hook, Prev: Dynamically registering methods, Up: Messaging with the GNU Objective-C runtime
-
-8.10.2 Forwarding hook
-----------------------
-
-The GNU Objective-C runtime provides a hook, called
-`__objc_msg_forward2', which is called by `objc_msg_lookup()' when it
-can't find a method implementation in the runtime tables and after
-calling `+resolveInstanceMethod:' and `+resolveClassMethod:' has been
-attempted and did not succeed in dynamically registering the method.
-
- To configure the hook, you set the global variable
-`__objc_msg_foward2' to a function with the same argument and return
-types of `objc_msg_lookup()'. When `objc_msg_lookup()' can not find a
-method implementation, it invokes the hook function you provided to get
-a method implementation to return. So, in practice
-`__objc_msg_forward2' allows you to extend `objc_msg_lookup()' by
-adding some custom code that is called to do a further lookup when no
-standard method implementation can be found using the normal lookup.
-
- This hook is generally reserved for "Foundation" libraries such as
-GNUstep Base, which use it to implement their high-level method
-forwarding API, typically based around the `forwardInvocation:' method.
-So, unless you are implementing your own "Foundation" library, you
-should not set this hook.
-
- In a typical forwarding implementation, the `__objc_msg_forward2' hook
-function determines the argument and return type of the method that is
-being looked up, and then creates a function that takes these arguments
-and has that return type, and returns it to the caller. Creating this
-function is non-trivial and is typically performed using a dedicated
-library such as `libffi'.
-
- The forwarding method implementation thus created is returned by
-`objc_msg_lookup()' and is executed as if it was a normal method
-implementation. When the forwarding method implementation is called,
-it is usually expected to pack all arguments into some sort of object
-(typically, an `NSInvocation' in a "Foundation" library), and hand it
-over to the programmer (`forwardInvocation:') who is then allowed to
-manipulate the method invocation using a high-level API provided by the
-"Foundation" library. For example, the programmer may want to examine
-the method invocation arguments and name and potentially change them
-before forwarding the method invocation to one or more local objects
-(`performInvocation:') or even to remote objects (by using Distributed
-Objects or some other mechanism). When all this completes, the return
-value is passed back and must be returned correctly to the original
-caller.
-
- Note that the GNU Objective-C runtime currently provides no support
-for method forwarding or method invocations other than the
-`__objc_msg_forward2' hook.
-
- If the forwarding hook does not exist or returns `NULL', the runtime
-currently attempts forwarding using an older, deprecated API, and if
-that fails, it aborts the program. In future versions of the GNU
-Objective-C runtime, the runtime will immediately abort.
-
-
-File: gcc.info, Node: Compatibility, Next: Gcov, Prev: Objective-C, Up: Top
-
-9 Binary Compatibility
-**********************
-
-Binary compatibility encompasses several related concepts:
-
-"application binary interface (ABI)"
- The set of runtime conventions followed by all of the tools that
- deal with binary representations of a program, including
- compilers, assemblers, linkers, and language runtime support.
- Some ABIs are formal with a written specification, possibly
- designed by multiple interested parties. Others are simply the
- way things are actually done by a particular set of tools.
-
-"ABI conformance"
- A compiler conforms to an ABI if it generates code that follows
- all of the specifications enumerated by that ABI. A library
- conforms to an ABI if it is implemented according to that ABI. An
- application conforms to an ABI if it is built using tools that
- conform to that ABI and does not contain source code that
- specifically changes behavior specified by the ABI.
-
-"calling conventions"
- Calling conventions are a subset of an ABI that specify of how
- arguments are passed and function results are returned.
-
-"interoperability"
- Different sets of tools are interoperable if they generate files
- that can be used in the same program. The set of tools includes
- compilers, assemblers, linkers, libraries, header files, startup
- files, and debuggers. Binaries produced by different sets of
- tools are not interoperable unless they implement the same ABI.
- This applies to different versions of the same tools as well as
- tools from different vendors.
-
-"intercallability"
- Whether a function in a binary built by one set of tools can call a
- function in a binary built by a different set of tools is a subset
- of interoperability.
-
-"implementation-defined features"
- Language standards include lists of implementation-defined
- features whose behavior can vary from one implementation to
- another. Some of these features are normally covered by a
- platform's ABI and others are not. The features that are not
- covered by an ABI generally affect how a program behaves, but not
- intercallability.
-
-"compatibility"
- Conformance to the same ABI and the same behavior of
- implementation-defined features are both relevant for
- compatibility.
-
- The application binary interface implemented by a C or C++ compiler
-affects code generation and runtime support for:
-
- * size and alignment of data types
-
- * layout of structured types
-
- * calling conventions
-
- * register usage conventions
-
- * interfaces for runtime arithmetic support
-
- * object file formats
-
- In addition, the application binary interface implemented by a C++
-compiler affects code generation and runtime support for:
- * name mangling
-
- * exception handling
-
- * invoking constructors and destructors
-
- * layout, alignment, and padding of classes
-
- * layout and alignment of virtual tables
-
- Some GCC compilation options cause the compiler to generate code that
-does not conform to the platform's default ABI. Other options cause
-different program behavior for implementation-defined features that are
-not covered by an ABI. These options are provided for consistency with
-other compilers that do not follow the platform's default ABI or the
-usual behavior of implementation-defined features for the platform. Be
-very careful about using such options.
-
- Most platforms have a well-defined ABI that covers C code, but ABIs
-that cover C++ functionality are not yet common.
-
- Starting with GCC 3.2, GCC binary conventions for C++ are based on a
-written, vendor-neutral C++ ABI that was designed to be specific to
-64-bit Itanium but also includes generic specifications that apply to
-any platform. This C++ ABI is also implemented by other compiler
-vendors on some platforms, notably GNU/Linux and BSD systems. We have
-tried hard to provide a stable ABI that will be compatible with future
-GCC releases, but it is possible that we will encounter problems that
-make this difficult. Such problems could include different
-interpretations of the C++ ABI by different vendors, bugs in the ABI, or
-bugs in the implementation of the ABI in different compilers. GCC's
-`-Wabi' switch warns when G++ generates code that is probably not
-compatible with the C++ ABI.
-
- The C++ library used with a C++ compiler includes the Standard C++
-Library, with functionality defined in the C++ Standard, plus language
-runtime support. The runtime support is included in a C++ ABI, but
-there is no formal ABI for the Standard C++ Library. Two
-implementations of that library are interoperable if one follows the
-de-facto ABI of the other and if they are both built with the same
-compiler, or with compilers that conform to the same ABI for C++
-compiler and runtime support.
-
- When G++ and another C++ compiler conform to the same C++ ABI, but the
-implementations of the Standard C++ Library that they normally use do
-not follow the same ABI for the Standard C++ Library, object files
-built with those compilers can be used in the same program only if they
-use the same C++ library. This requires specifying the location of the
-C++ library header files when invoking the compiler whose usual library
-is not being used. The location of GCC's C++ header files depends on
-how the GCC build was configured, but can be seen by using the G++ `-v'
-option. With default configuration options for G++ 3.3 the compile
-line for a different C++ compiler needs to include
-
- -IGCC_INSTALL_DIRECTORY/include/c++/3.3
-
- Similarly, compiling code with G++ that must use a C++ library other
-than the GNU C++ library requires specifying the location of the header
-files for that other library.
-
- The most straightforward way to link a program to use a particular C++
-library is to use a C++ driver that specifies that C++ library by
-default. The `g++' driver, for example, tells the linker where to find
-GCC's C++ library (`libstdc++') plus the other libraries and startup
-files it needs, in the proper order.
-
- If a program must use a different C++ library and it's not possible to
-do the final link using a C++ driver that uses that library by default,
-it is necessary to tell `g++' the location and name of that library.
-It might also be necessary to specify different startup files and other
-runtime support libraries, and to suppress the use of GCC's support
-libraries with one or more of the options `-nostdlib', `-nostartfiles',
-and `-nodefaultlibs'.
-
-
-File: gcc.info, Node: Gcov, Next: Trouble, Prev: Compatibility, Up: Top
-
-10 `gcov'--a Test Coverage Program
-**********************************
-
-`gcov' is a tool you can use in conjunction with GCC to test code
-coverage in your programs.
-
-* Menu:
-
-* Gcov Intro:: Introduction to gcov.
-* Invoking Gcov:: How to use gcov.
-* Gcov and Optimization:: Using gcov with GCC optimization.
-* Gcov Data Files:: The files used by gcov.
-* Cross-profiling:: Data file relocation.
-
-
-File: gcc.info, Node: Gcov Intro, Next: Invoking Gcov, Up: Gcov
-
-10.1 Introduction to `gcov'
-===========================
-
-`gcov' is a test coverage program. Use it in concert with GCC to
-analyze your programs to help create more efficient, faster running
-code and to discover untested parts of your program. You can use
-`gcov' as a profiling tool to help discover where your optimization
-efforts will best affect your code. You can also use `gcov' along with
-the other profiling tool, `gprof', to assess which parts of your code
-use the greatest amount of computing time.
-
- Profiling tools help you analyze your code's performance. Using a
-profiler such as `gcov' or `gprof', you can find out some basic
-performance statistics, such as:
-
- * how often each line of code executes
-
- * what lines of code are actually executed
-
- * how much computing time each section of code uses
-
- Once you know these things about how your code works when compiled, you
-can look at each module to see which modules should be optimized.
-`gcov' helps you determine where to work on optimization.
-
- Software developers also use coverage testing in concert with
-testsuites, to make sure software is actually good enough for a release.
-Testsuites can verify that a program works as expected; a coverage
-program tests to see how much of the program is exercised by the
-testsuite. Developers can then determine what kinds of test cases need
-to be added to the testsuites to create both better testing and a better
-final product.
-
- You should compile your code without optimization if you plan to use
-`gcov' because the optimization, by combining some lines of code into
-one function, may not give you as much information as you need to look
-for `hot spots' where the code is using a great deal of computer time.
-Likewise, because `gcov' accumulates statistics by line (at the lowest
-resolution), it works best with a programming style that places only
-one statement on each line. If you use complicated macros that expand
-to loops or to other control structures, the statistics are less
-helpful--they only report on the line where the macro call appears. If
-your complex macros behave like functions, you can replace them with
-inline functions to solve this problem.
-
- `gcov' creates a logfile called `SOURCEFILE.gcov' which indicates how
-many times each line of a source file `SOURCEFILE.c' has executed. You
-can use these logfiles along with `gprof' to aid in fine-tuning the
-performance of your programs. `gprof' gives timing information you can
-use along with the information you get from `gcov'.
-
- `gcov' works only on code compiled with GCC. It is not compatible
-with any other profiling or test coverage mechanism.
-
-
-File: gcc.info, Node: Invoking Gcov, Next: Gcov and Optimization, Prev: Gcov Intro, Up: Gcov
-
-10.2 Invoking `gcov'
-====================
-
- gcov [OPTIONS] SOURCEFILES
-
- `gcov' accepts the following options:
-
-`-h'
-`--help'
- Display help about using `gcov' (on the standard output), and exit
- without doing any further processing.
-
-`-v'
-`--version'
- Display the `gcov' version number (on the standard output), and
- exit without doing any further processing.
-
-`-a'
-`--all-blocks'
- Write individual execution counts for every basic block. Normally
- gcov outputs execution counts only for the main blocks of a line.
- With this option you can determine if blocks within a single line
- are not being executed.
-
-`-b'
-`--branch-probabilities'
- Write branch frequencies to the output file, and write branch
- summary info to the standard output. This option allows you to
- see how often each branch in your program was taken.
- Unconditional branches will not be shown, unless the `-u' option
- is given.
-
-`-c'
-`--branch-counts'
- Write branch frequencies as the number of branches taken, rather
- than the percentage of branches taken.
-
-`-m'
-`--pmu-profile'
- Output the additional PMU profile information if available.
-
-`-q'
-`--pmu_profile-path'
- PMU profile path (default `pmuprofile.gcda').
-
-`-n'
-`--no-output'
- Do not create the `gcov' output file.
-
-`-l'
-`--long-file-names'
- Create long file names for included source files. For example, if
- the header file `x.h' contains code, and was included in the file
- `a.c', then running `gcov' on the file `a.c' will produce an
- output file called `a.c##x.h.gcov' instead of `x.h.gcov'. This
- can be useful if `x.h' is included in multiple source files. If
- you use the `-p' option, both the including and included file
- names will be complete path names.
-
-`-p'
-`--preserve-paths'
- Preserve complete path information in the names of generated
- `.gcov' files. Without this option, just the filename component is
- used. With this option, all directories are used, with `/'
- characters translated to `#' characters, `.' directory components
- removed and `..' components renamed to `^'. This is useful if
- sourcefiles are in several different directories. It also affects
- the `-l' option.
-
-`-f'
-`--function-summaries'
- Output summaries for each function in addition to the file level
- summary.
-
-`-o DIRECTORY|FILE'
-`--object-directory DIRECTORY'
-`--object-file FILE'
- Specify either the directory containing the gcov data files, or the
- object path name. The `.gcno', and `.gcda' data files are
- searched for using this option. If a directory is specified, the
- data files are in that directory and named after the source file
- name, without its extension. If a file is specified here, the
- data files are named after that file, without its extension. If
- this option is not supplied, it defaults to the current directory.
-
-`-u'
-`--unconditional-branches'
- When branch probabilities are given, include those of
- unconditional branches. Unconditional branches are normally not
- interesting.
-
-`-d'
-`--display-progress'
- Display the progress on the standard output.
-
-`-i'
-`--intermediate-format'
- Output gcov file in an intermediate text format that can be used by
- `lcov' or other applications. It will output a single *.gcov file
- per *.gcda file. No source code is required.
-
- The format of the intermediate `.gcov' file is plain text with one
- entry per line
-
- SF:SOURCE_FILE_NAME
- FN:LINE_NUMBER,FUNCTION_NAME
- FNDA:EXECUTION_COUNT,FUNCTION_NAME
- BA:LINE_NUM,BRANCH_COVERAGE_TYPE
- DA:LINE NUMBER,EXECUTION_COUNT
-
- Where the BRANCH_COVERAGE_TYPE is
- 0 (Branch not executed)
- 1 (Branch executed, but not taken)
- 2 (Branch executed and taken)
-
- There can be multiple SF entries in an intermediate gcov file. All
- entries following SF pertain to that source file until the next SF
- entry.
-
-
- `gcov' should be run with the current directory the same as that when
-you invoked the compiler. Otherwise it will not be able to locate the
-source files. `gcov' produces files called `MANGLEDNAME.gcov' in the
-current directory. These contain the coverage information of the
-source file they correspond to. One `.gcov' file is produced for each
-source file containing code, which was compiled to produce the data
-files. The MANGLEDNAME part of the output file name is usually simply
-the source file name, but can be something more complicated if the `-l'
-or `-p' options are given. Refer to those options for details.
-
- The `.gcov' files contain the `:' separated fields along with program
-source code. The format is
-
- EXECUTION_COUNT:LINE_NUMBER:SOURCE LINE TEXT
-
- Additional block information may succeed each line, when requested by
-command line option. The EXECUTION_COUNT is `-' for lines containing
-no code and `#####' for lines which were never executed. Some lines of
-information at the start have LINE_NUMBER of zero.
-
- The preamble lines are of the form
-
- -:0:TAG:VALUE
-
- The ordering and number of these preamble lines will be augmented as
-`gcov' development progresses -- do not rely on them remaining
-unchanged. Use TAG to locate a particular preamble line.
-
- The additional block information is of the form
-
- TAG INFORMATION
-
- The INFORMATION is human readable, but designed to be simple enough
-for machine parsing too.
-
- When printing percentages, 0% and 100% are only printed when the values
-are _exactly_ 0% and 100% respectively. Other values which would
-conventionally be rounded to 0% or 100% are instead printed as the
-nearest non-boundary value.
-
- When using `gcov', you must first compile your program with two
-special GCC options: `-fprofile-arcs -ftest-coverage'. This tells the
-compiler to generate additional information needed by gcov (basically a
-flow graph of the program) and also includes additional code in the
-object files for generating the extra profiling information needed by
-gcov. These additional files are placed in the directory where the
-object file is located.
-
- Running the program will cause profile output to be generated. For
-each source file compiled with `-fprofile-arcs', an accompanying
-`.gcda' file will be placed in the object file directory.
-
- Running `gcov' with your program's source file names as arguments will
-now produce a listing of the code along with frequency of execution for
-each line. For example, if your program is called `tmp.c', this is
-what you see when you use the basic `gcov' facility:
-
- $ gcc -fprofile-arcs -ftest-coverage tmp.c
- $ a.out
- $ gcov tmp.c
- 90.00% of 10 source lines executed in file tmp.c
- Creating tmp.c.gcov.
-
- The file `tmp.c.gcov' contains output from `gcov'. Here is a sample:
-
- -: 0:Source:tmp.c
- -: 0:Graph:tmp.gcno
- -: 0:Data:tmp.gcda
- -: 0:Runs:1
- -: 0:Programs:1
- -: 1:#include <stdio.h>
- -: 2:
- -: 3:int main (void)
- 1: 4:{
- 1: 5: int i, total;
- -: 6:
- 1: 7: total = 0;
- -: 8:
- 11: 9: for (i = 0; i < 10; i++)
- 10: 10: total += i;
- -: 11:
- 1: 12: if (total != 45)
- #####: 13: printf ("Failure\n");
- -: 14: else
- 1: 15: printf ("Success\n");
- 1: 16: return 0;
- -: 17:}
-
- When you use the `-a' option, you will get individual block counts,
-and the output looks like this:
-
- -: 0:Source:tmp.c
- -: 0:Graph:tmp.gcno
- -: 0:Data:tmp.gcda
- -: 0:Runs:1
- -: 0:Programs:1
- -: 1:#include <stdio.h>
- -: 2:
- -: 3:int main (void)
- 1: 4:{
- 1: 4-block 0
- 1: 5: int i, total;
- -: 6:
- 1: 7: total = 0;
- -: 8:
- 11: 9: for (i = 0; i < 10; i++)
- 11: 9-block 0
- 10: 10: total += i;
- 10: 10-block 0
- -: 11:
- 1: 12: if (total != 45)
- 1: 12-block 0
- #####: 13: printf ("Failure\n");
- $$$$$: 13-block 0
- -: 14: else
- 1: 15: printf ("Success\n");
- 1: 15-block 0
- 1: 16: return 0;
- 1: 16-block 0
- -: 17:}
-
- In this mode, each basic block is only shown on one line - the last
-line of the block. A multi-line block will only contribute to the
-execution count of that last line, and other lines will not be shown to
-contain code, unless previous blocks end on those lines. The total
-execution count of a line is shown and subsequent lines show the
-execution counts for individual blocks that end on that line. After
-each block, the branch and call counts of the block will be shown, if
-the `-b' option is given.
-
- Because of the way GCC instruments calls, a call count can be shown
-after a line with no individual blocks. As you can see, line 13
-contains a basic block that was not executed.
-
- When you use the `-b' option, your output looks like this:
-
- $ gcov -b tmp.c
- 90.00% of 10 source lines executed in file tmp.c
- 80.00% of 5 branches executed in file tmp.c
- 80.00% of 5 branches taken at least once in file tmp.c
- 50.00% of 2 calls executed in file tmp.c
- Creating tmp.c.gcov.
-
- Here is a sample of a resulting `tmp.c.gcov' file:
-
- -: 0:Source:tmp.c
- -: 0:Graph:tmp.gcno
- -: 0:Data:tmp.gcda
- -: 0:Runs:1
- -: 0:Programs:1
- -: 1:#include <stdio.h>
- -: 2:
- -: 3:int main (void)
- function main called 1 returned 1 blocks executed 75%
- 1: 4:{
- 1: 5: int i, total;
- -: 6:
- 1: 7: total = 0;
- -: 8:
- 11: 9: for (i = 0; i < 10; i++)
- branch 0 taken 91% (fallthrough)
- branch 1 taken 9%
- 10: 10: total += i;
- -: 11:
- 1: 12: if (total != 45)
- branch 0 taken 0% (fallthrough)
- branch 1 taken 100%
- #####: 13: printf ("Failure\n");
- call 0 never executed
- -: 14: else
- 1: 15: printf ("Success\n");
- call 0 called 1 returned 100%
- 1: 16: return 0;
- -: 17:}
-
- For each function, a line is printed showing how many times the
-function is called, how many times it returns and what percentage of the
-function's blocks were executed.
-
- For each basic block, a line is printed after the last line of the
-basic block describing the branch or call that ends the basic block.
-There can be multiple branches and calls listed for a single source
-line if there are multiple basic blocks that end on that line. In this
-case, the branches and calls are each given a number. There is no
-simple way to map these branches and calls back to source constructs.
-In general, though, the lowest numbered branch or call will correspond
-to the leftmost construct on the source line.
-
- For a branch, if it was executed at least once, then a percentage
-indicating the number of times the branch was taken divided by the
-number of times the branch was executed will be printed. Otherwise, the
-message "never executed" is printed.
-
- For a call, if it was executed at least once, then a percentage
-indicating the number of times the call returned divided by the number
-of times the call was executed will be printed. This will usually be
-100%, but may be less for functions that call `exit' or `longjmp', and
-thus may not return every time they are called.
-
- The execution counts are cumulative. If the example program were
-executed again without removing the `.gcda' file, the count for the
-number of times each line in the source was executed would be added to
-the results of the previous run(s). This is potentially useful in
-several ways. For example, it could be used to accumulate data over a
-number of program runs as part of a test verification suite, or to
-provide more accurate long-term information over a large number of
-program runs.
-
- The data in the `.gcda' files is saved immediately before the program
-exits. For each source file compiled with `-fprofile-arcs', the
-profiling code first attempts to read in an existing `.gcda' file; if
-the file doesn't match the executable (differing number of basic block
-counts) it will ignore the contents of the file. It then adds in the
-new execution counts and finally writes the data to the file.
-
-
-File: gcc.info, Node: Gcov and Optimization, Next: Gcov Data Files, Prev: Invoking Gcov, Up: Gcov
-
-10.3 Using `gcov' with GCC Optimization
-=======================================
-
-If you plan to use `gcov' to help optimize your code, you must first
-compile your program with two special GCC options: `-fprofile-arcs
--ftest-coverage'. Aside from that, you can use any other GCC options;
-but if you want to prove that every single line in your program was
-executed, you should not compile with optimization at the same time.
-On some machines the optimizer can eliminate some simple code lines by
-combining them with other lines. For example, code like this:
-
- if (a != b)
- c = 1;
- else
- c = 0;
-
-can be compiled into one instruction on some machines. In this case,
-there is no way for `gcov' to calculate separate execution counts for
-each line because there isn't separate code for each line. Hence the
-`gcov' output looks like this if you compiled the program with
-optimization:
-
- 100: 12:if (a != b)
- 100: 13: c = 1;
- 100: 14:else
- 100: 15: c = 0;
-
- The output shows that this block of code, combined by optimization,
-executed 100 times. In one sense this result is correct, because there
-was only one instruction representing all four of these lines. However,
-the output does not indicate how many times the result was 0 and how
-many times the result was 1.
-
- Inlineable functions can create unexpected line counts. Line counts
-are shown for the source code of the inlineable function, but what is
-shown depends on where the function is inlined, or if it is not inlined
-at all.
-
- If the function is not inlined, the compiler must emit an out of line
-copy of the function, in any object file that needs it. If `fileA.o'
-and `fileB.o' both contain out of line bodies of a particular
-inlineable function, they will also both contain coverage counts for
-that function. When `fileA.o' and `fileB.o' are linked together, the
-linker will, on many systems, select one of those out of line bodies
-for all calls to that function, and remove or ignore the other.
-Unfortunately, it will not remove the coverage counters for the unused
-function body. Hence when instrumented, all but one use of that
-function will show zero counts.
-
- If the function is inlined in several places, the block structure in
-each location might not be the same. For instance, a condition might
-now be calculable at compile time in some instances. Because the
-coverage of all the uses of the inline function will be shown for the
-same source lines, the line counts themselves might seem inconsistent.
-
-
-File: gcc.info, Node: Gcov Data Files, Next: Cross-profiling, Prev: Gcov and Optimization, Up: Gcov
-
-10.4 Brief description of `gcov' data files
-===========================================
-
-`gcov' uses two files for profiling. The names of these files are
-derived from the original _object_ file by substituting the file suffix
-with either `.gcno', or `.gcda'. All of these files are placed in the
-same directory as the object file, and contain data stored in a
-platform-independent format.
-
- The `.gcno' file is generated when the source file is compiled with
-the GCC `-ftest-coverage' option. It contains information to
-reconstruct the basic block graphs and assign source line numbers to
-blocks.
-
- The `.gcda' file is generated when a program containing object files
-built with the GCC `-fprofile-arcs' option is executed. A separate
-`.gcda' file is created for each object file compiled with this option.
-It contains arc transition counts, and some summary information.
-
- The full details of the file format is specified in `gcov-io.h', and
-functions provided in that header file should be used to access the
-coverage files.
-
-
-File: gcc.info, Node: Cross-profiling, Prev: Gcov Data Files, Up: Gcov
-
-10.5 Data file relocation to support cross-profiling
-====================================================
-
-Running the program will cause profile output to be generated. For each
-source file compiled with `-fprofile-arcs', an accompanying `.gcda'
-file will be placed in the object file directory. That implicitly
-requires running the program on the same system as it was built or
-having the same absolute directory structure on the target system. The
-program will try to create the needed directory structure, if it is not
-already present.
-
- To support cross-profiling, a program compiled with `-fprofile-arcs'
-can relocate the data files based on two environment variables:
-
- * GCOV_PREFIX contains the prefix to add to the absolute paths in
- the object file. Prefix can be absolute, or relative. The default
- is no prefix.
-
- * GCOV_PREFIX_STRIP indicates the how many initial directory names
- to strip off the hardwired absolute paths. Default value is 0.
-
- _Note:_ If GCOV_PREFIX_STRIP is set without GCOV_PREFIX is
- undefined, then a relative path is made out of the hardwired
- absolute paths.
-
- For example, if the object file `/user/build/foo.o' was built with
-`-fprofile-arcs', the final executable will try to create the data file
-`/user/build/foo.gcda' when running on the target system. This will
-fail if the corresponding directory does not exist and it is unable to
-create it. This can be overcome by, for example, setting the
-environment as `GCOV_PREFIX=/target/run' and `GCOV_PREFIX_STRIP=1'.
-Such a setting will name the data file `/target/run/build/foo.gcda'.
-
- You must move the data files to the expected directory tree in order to
-use them for profile directed optimizations (`--use-profile'), or to
-use the `gcov' tool.
-
-
-File: gcc.info, Node: Trouble, Next: Bugs, Prev: Gcov, Up: Top
-
-11 Known Causes of Trouble with GCC
-***********************************
-
-This section describes known problems that affect users of GCC. Most
-of these are not GCC bugs per se--if they were, we would fix them. But
-the result for a user may be like the result of a bug.
-
- Some of these problems are due to bugs in other software, some are
-missing features that are too much work to add, and some are places
-where people's opinions differ as to what is best.
-
-* Menu:
-
-* Actual Bugs:: Bugs we will fix later.
-* Cross-Compiler Problems:: Common problems of cross compiling with GCC.
-* Interoperation:: Problems using GCC with other compilers,
- and with certain linkers, assemblers and debuggers.
-* Incompatibilities:: GCC is incompatible with traditional C.
-* Fixed Headers:: GCC uses corrected versions of system header files.
- This is necessary, but doesn't always work smoothly.
-* Standard Libraries:: GCC uses the system C library, which might not be
- compliant with the ISO C standard.
-* Disappointments:: Regrettable things we can't change, but not quite bugs.
-* C++ Misunderstandings:: Common misunderstandings with GNU C++.
-* Non-bugs:: Things we think are right, but some others disagree.
-* Warnings and Errors:: Which problems in your code get warnings,
- and which get errors.
-
-
-File: gcc.info, Node: Actual Bugs, Next: Cross-Compiler Problems, Up: Trouble
-
-11.1 Actual Bugs We Haven't Fixed Yet
-=====================================
-
- * The `fixincludes' script interacts badly with automounters; if the
- directory of system header files is automounted, it tends to be
- unmounted while `fixincludes' is running. This would seem to be a
- bug in the automounter. We don't know any good way to work around
- it.
-
-
-File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Actual Bugs, Up: Trouble
-
-11.2 Cross-Compiler Problems
-============================
-
-You may run into problems with cross compilation on certain machines,
-for several reasons.
-
- * At present, the program `mips-tfile' which adds debug support to
- object files on MIPS systems does not work in a cross compile
- environment.
-
-
-File: gcc.info, Node: Interoperation, Next: Incompatibilities, Prev: Cross-Compiler Problems, Up: Trouble
-
-11.3 Interoperation
-===================
-
-This section lists various difficulties encountered in using GCC
-together with other compilers or with the assemblers, linkers,
-libraries and debuggers on certain systems.
-
- * On many platforms, GCC supports a different ABI for C++ than do
- other compilers, so the object files compiled by GCC cannot be
- used with object files generated by another C++ compiler.
-
- An area where the difference is most apparent is name mangling.
- The use of different name mangling is intentional, to protect you
- from more subtle problems. Compilers differ as to many internal
- details of C++ implementation, including: how class instances are
- laid out, how multiple inheritance is implemented, and how virtual
- function calls are handled. If the name encoding were made the
- same, your programs would link against libraries provided from
- other compilers--but the programs would then crash when run.
- Incompatible libraries are then detected at link time, rather than
- at run time.
-
- * On some BSD systems, including some versions of Ultrix, use of
- profiling causes static variable destructors (currently used only
- in C++) not to be run.
-
- * On some SGI systems, when you use `-lgl_s' as an option, it gets
- translated magically to `-lgl_s -lX11_s -lc_s'. Naturally, this
- does not happen when you use GCC. You must specify all three
- options explicitly.
-
- * On a SPARC, GCC aligns all values of type `double' on an 8-byte
- boundary, and it expects every `double' to be so aligned. The Sun
- compiler usually gives `double' values 8-byte alignment, with one
- exception: function arguments of type `double' may not be aligned.
-
- As a result, if a function compiled with Sun CC takes the address
- of an argument of type `double' and passes this pointer of type
- `double *' to a function compiled with GCC, dereferencing the
- pointer may cause a fatal signal.
-
- One way to solve this problem is to compile your entire program
- with GCC. Another solution is to modify the function that is
- compiled with Sun CC to copy the argument into a local variable;
- local variables are always properly aligned. A third solution is
- to modify the function that uses the pointer to dereference it via
- the following function `access_double' instead of directly with
- `*':
-
- inline double
- access_double (double *unaligned_ptr)
- {
- union d2i { double d; int i[2]; };
-
- union d2i *p = (union d2i *) unaligned_ptr;
- union d2i u;
-
- u.i[0] = p->i[0];
- u.i[1] = p->i[1];
-
- return u.d;
- }
-
- Storing into the pointer can be done likewise with the same union.
-
- * On Solaris, the `malloc' function in the `libmalloc.a' library may
- allocate memory that is only 4 byte aligned. Since GCC on the
- SPARC assumes that doubles are 8 byte aligned, this may result in a
- fatal signal if doubles are stored in memory allocated by the
- `libmalloc.a' library.
-
- The solution is to not use the `libmalloc.a' library. Use instead
- `malloc' and related functions from `libc.a'; they do not have
- this problem.
-
- * On the HP PA machine, ADB sometimes fails to work on functions
- compiled with GCC. Specifically, it fails to work on functions
- that use `alloca' or variable-size arrays. This is because GCC
- doesn't generate HP-UX unwind descriptors for such functions. It
- may even be impossible to generate them.
-
- * Debugging (`-g') is not supported on the HP PA machine, unless you
- use the preliminary GNU tools.
-
- * Taking the address of a label may generate errors from the HP-UX
- PA assembler. GAS for the PA does not have this problem.
-
- * Using floating point parameters for indirect calls to static
- functions will not work when using the HP assembler. There simply
- is no way for GCC to specify what registers hold arguments for
- static functions when using the HP assembler. GAS for the PA does
- not have this problem.
-
- * In extremely rare cases involving some very large functions you may
- receive errors from the HP linker complaining about an out of
- bounds unconditional branch offset. This used to occur more often
- in previous versions of GCC, but is now exceptionally rare. If
- you should run into it, you can work around by making your
- function smaller.
-
- * GCC compiled code sometimes emits warnings from the HP-UX
- assembler of the form:
-
- (warning) Use of GR3 when
- frame >= 8192 may cause conflict.
-
- These warnings are harmless and can be safely ignored.
-
- * In extremely rare cases involving some very large functions you may
- receive errors from the AIX Assembler complaining about a
- displacement that is too large. If you should run into it, you
- can work around by making your function smaller.
-
- * The `libstdc++.a' library in GCC relies on the SVR4 dynamic linker
- semantics which merges global symbols between libraries and
- applications, especially necessary for C++ streams functionality.
- This is not the default behavior of AIX shared libraries and
- dynamic linking. `libstdc++.a' is built on AIX with
- "runtime-linking" enabled so that symbol merging can occur. To
- utilize this feature, the application linked with `libstdc++.a'
- must include the `-Wl,-brtl' flag on the link line. G++ cannot
- impose this because this option may interfere with the semantics
- of the user program and users may not always use `g++' to link his
- or her application. Applications are not required to use the
- `-Wl,-brtl' flag on the link line--the rest of the `libstdc++.a'
- library which is not dependent on the symbol merging semantics
- will continue to function correctly.
-
- * An application can interpose its own definition of functions for
- functions invoked by `libstdc++.a' with "runtime-linking" enabled
- on AIX. To accomplish this the application must be linked with
- "runtime-linking" option and the functions explicitly must be
- exported by the application (`-Wl,-brtl,-bE:exportfile').
-
- * AIX on the RS/6000 provides support (NLS) for environments outside
- of the United States. Compilers and assemblers use NLS to support
- locale-specific representations of various objects including
- floating-point numbers (`.' vs `,' for separating decimal
- fractions). There have been problems reported where the library
- linked with GCC does not produce the same floating-point formats
- that the assembler accepts. If you have this problem, set the
- `LANG' environment variable to `C' or `En_US'.
-
- * Even if you specify `-fdollars-in-identifiers', you cannot
- successfully use `$' in identifiers on the RS/6000 due to a
- restriction in the IBM assembler. GAS supports these identifiers.
-
-
-
-File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: Interoperation, Up: Trouble
-
-11.4 Incompatibilities of GCC
-=============================
-
-There are several noteworthy incompatibilities between GNU C and K&R
-(non-ISO) versions of C.
-
- * GCC normally makes string constants read-only. If several
- identical-looking string constants are used, GCC stores only one
- copy of the string.
-
- One consequence is that you cannot call `mktemp' with a string
- constant argument. The function `mktemp' always alters the string
- its argument points to.
-
- Another consequence is that `sscanf' does not work on some very
- old systems when passed a string constant as its format control
- string or input. This is because `sscanf' incorrectly tries to
- write into the string constant. Likewise `fscanf' and `scanf'.
-
- The solution to these problems is to change the program to use
- `char'-array variables with initialization strings for these
- purposes instead of string constants.
-
- * `-2147483648' is positive.
-
- This is because 2147483648 cannot fit in the type `int', so
- (following the ISO C rules) its data type is `unsigned long int'.
- Negating this value yields 2147483648 again.
-
- * GCC does not substitute macro arguments when they appear inside of
- string constants. For example, the following macro in GCC
-
- #define foo(a) "a"
-
- will produce output `"a"' regardless of what the argument A is.
-
- * When you use `setjmp' and `longjmp', the only automatic variables
- guaranteed to remain valid are those declared `volatile'. This is
- a consequence of automatic register allocation. Consider this
- function:
-
- jmp_buf j;
-
- foo ()
- {
- int a, b;
-
- a = fun1 ();
- if (setjmp (j))
- return a;
-
- a = fun2 ();
- /* `longjmp (j)' may occur in `fun3'. */
- return a + fun3 ();
- }
-
- Here `a' may or may not be restored to its first value when the
- `longjmp' occurs. If `a' is allocated in a register, then its
- first value is restored; otherwise, it keeps the last value stored
- in it.
-
- If you use the `-W' option with the `-O' option, you will get a
- warning when GCC thinks such a problem might be possible.
-
- * Programs that use preprocessing directives in the middle of macro
- arguments do not work with GCC. For example, a program like this
- will not work:
-
- foobar (
- #define luser
- hack)
-
- ISO C does not permit such a construct.
-
- * K&R compilers allow comments to cross over an inclusion boundary
- (i.e. started in an include file and ended in the including file).
-
- * Declarations of external variables and functions within a block
- apply only to the block containing the declaration. In other
- words, they have the same scope as any other declaration in the
- same place.
-
- In some other C compilers, an `extern' declaration affects all the
- rest of the file even if it happens within a block.
-
- * In traditional C, you can combine `long', etc., with a typedef
- name, as shown here:
-
- typedef int foo;
- typedef long foo bar;
-
- In ISO C, this is not allowed: `long' and other type modifiers
- require an explicit `int'.
-
- * PCC allows typedef names to be used as function parameters.
-
- * Traditional C allows the following erroneous pair of declarations
- to appear together in a given scope:
-
- typedef int foo;
- typedef foo foo;
-
- * GCC treats all characters of identifiers as significant.
- According to K&R-1 (2.2), "No more than the first eight characters
- are significant, although more may be used.". Also according to
- K&R-1 (2.2), "An identifier is a sequence of letters and digits;
- the first character must be a letter. The underscore _ counts as
- a letter.", but GCC also allows dollar signs in identifiers.
-
- * PCC allows whitespace in the middle of compound assignment
- operators such as `+='. GCC, following the ISO standard, does not
- allow this.
-
- * GCC complains about unterminated character constants inside of
- preprocessing conditionals that fail. Some programs have English
- comments enclosed in conditionals that are guaranteed to fail; if
- these comments contain apostrophes, GCC will probably report an
- error. For example, this code would produce an error:
-
- #if 0
- You can't expect this to work.
- #endif
-
- The best solution to such a problem is to put the text into an
- actual C comment delimited by `/*...*/'.
-
- * Many user programs contain the declaration `long time ();'. In the
- past, the system header files on many systems did not actually
- declare `time', so it did not matter what type your program
- declared it to return. But in systems with ISO C headers, `time'
- is declared to return `time_t', and if that is not the same as
- `long', then `long time ();' is erroneous.
-
- The solution is to change your program to use appropriate system
- headers (`<time.h>' on systems with ISO C headers) and not to
- declare `time' if the system header files declare it, or failing
- that to use `time_t' as the return type of `time'.
-
- * When compiling functions that return `float', PCC converts it to a
- double. GCC actually returns a `float'. If you are concerned
- with PCC compatibility, you should declare your functions to return
- `double'; you might as well say what you mean.
-
- * When compiling functions that return structures or unions, GCC
- output code normally uses a method different from that used on most
- versions of Unix. As a result, code compiled with GCC cannot call
- a structure-returning function compiled with PCC, and vice versa.
-
- The method used by GCC is as follows: a structure or union which is
- 1, 2, 4 or 8 bytes long is returned like a scalar. A structure or
- union with any other size is stored into an address supplied by
- the caller (usually in a special, fixed register, but on some
- machines it is passed on the stack). The target hook
- `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address.
-
- By contrast, PCC on most target machines returns structures and
- unions of any size by copying the data into an area of static
- storage, and then returning the address of that storage as if it
- were a pointer value. The caller must copy the data from that
- memory area to the place where the value is wanted. GCC does not
- use this method because it is slower and nonreentrant.
-
- On some newer machines, PCC uses a reentrant convention for all
- structure and union returning. GCC on most of these machines uses
- a compatible convention when returning structures and unions in
- memory, but still returns small structures and unions in registers.
-
- You can tell GCC to use a compatible convention for all structure
- and union returning with the option `-fpcc-struct-return'.
-
- * GCC complains about program fragments such as `0x74ae-0x4000'
- which appear to be two hexadecimal constants separated by the minus
- operator. Actually, this string is a single "preprocessing token".
- Each such token must correspond to one token in C. Since this
- does not, GCC prints an error message. Although it may appear
- obvious that what is meant is an operator and two values, the ISO
- C standard specifically requires that this be treated as erroneous.
-
- A "preprocessing token" is a "preprocessing number" if it begins
- with a digit and is followed by letters, underscores, digits,
- periods and `e+', `e-', `E+', `E-', `p+', `p-', `P+', or `P-'
- character sequences. (In strict C90 mode, the sequences `p+',
- `p-', `P+' and `P-' cannot appear in preprocessing numbers.)
-
- To make the above program fragment valid, place whitespace in
- front of the minus sign. This whitespace will end the
- preprocessing number.
-
-
-File: gcc.info, Node: Fixed Headers, Next: Standard Libraries, Prev: Incompatibilities, Up: Trouble
-
-11.5 Fixed Header Files
-=======================
-
-GCC needs to install corrected versions of some system header files.
-This is because most target systems have some header files that won't
-work with GCC unless they are changed. Some have bugs, some are
-incompatible with ISO C, and some depend on special features of other
-compilers.
-
- Installing GCC automatically creates and installs the fixed header
-files, by running a program called `fixincludes'. Normally, you don't
-need to pay attention to this. But there are cases where it doesn't do
-the right thing automatically.
-
- * If you update the system's header files, such as by installing a
- new system version, the fixed header files of GCC are not
- automatically updated. They can be updated using the `mkheaders'
- script installed in `LIBEXECDIR/gcc/TARGET/VERSION/install-tools/'.
-
- * On some systems, header file directories contain machine-specific
- symbolic links in certain places. This makes it possible to share
- most of the header files among hosts running the same version of
- the system on different machine models.
-
- The programs that fix the header files do not understand this
- special way of using symbolic links; therefore, the directory of
- fixed header files is good only for the machine model used to
- build it.
-
- It is possible to make separate sets of fixed header files for the
- different machine models, and arrange a structure of symbolic
- links so as to use the proper set, but you'll have to do this by
- hand.
-
-
-File: gcc.info, Node: Standard Libraries, Next: Disappointments, Prev: Fixed Headers, Up: Trouble
-
-11.6 Standard Libraries
-=======================
-
-GCC by itself attempts to be a conforming freestanding implementation.
-*Note Language Standards Supported by GCC: Standards, for details of
-what this means. Beyond the library facilities required of such an
-implementation, the rest of the C library is supplied by the vendor of
-the operating system. If that C library doesn't conform to the C
-standards, then your programs might get warnings (especially when using
-`-Wall') that you don't expect.
-
- For example, the `sprintf' function on SunOS 4.1.3 returns `char *'
-while the C standard says that `sprintf' returns an `int'. The
-`fixincludes' program could make the prototype for this function match
-the Standard, but that would be wrong, since the function will still
-return `char *'.
-
- If you need a Standard compliant library, then you need to find one, as
-GCC does not provide one. The GNU C library (called `glibc') provides
-ISO C, POSIX, BSD, SystemV and X/Open compatibility for GNU/Linux and
-HURD-based GNU systems; no recent version of it supports other systems,
-though some very old versions did. Version 2.2 of the GNU C library
-includes nearly complete C99 support. You could also ask your
-operating system vendor if newer libraries are available.
-
-
-File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Standard Libraries, Up: Trouble
-
-11.7 Disappointments and Misunderstandings
-==========================================
-
-These problems are perhaps regrettable, but we don't know any practical
-way around them.
-
- * Certain local variables aren't recognized by debuggers when you
- compile with optimization.
-
- This occurs because sometimes GCC optimizes the variable out of
- existence. There is no way to tell the debugger how to compute the
- value such a variable "would have had", and it is not clear that
- would be desirable anyway. So GCC simply does not mention the
- eliminated variable when it writes debugging information.
-
- You have to expect a certain amount of disagreement between the
- executable and your source code, when you use optimization.
-
- * Users often think it is a bug when GCC reports an error for code
- like this:
-
- int foo (struct mumble *);
-
- struct mumble { ... };
-
- int foo (struct mumble *x)
- { ... }
-
- This code really is erroneous, because the scope of `struct
- mumble' in the prototype is limited to the argument list
- containing it. It does not refer to the `struct mumble' defined
- with file scope immediately below--they are two unrelated types
- with similar names in different scopes.
-
- But in the definition of `foo', the file-scope type is used
- because that is available to be inherited. Thus, the definition
- and the prototype do not match, and you get an error.
-
- This behavior may seem silly, but it's what the ISO standard
- specifies. It is easy enough for you to make your code work by
- moving the definition of `struct mumble' above the prototype.
- It's not worth being incompatible with ISO C just to avoid an
- error for the example shown above.
-
- * Accesses to bit-fields even in volatile objects works by accessing
- larger objects, such as a byte or a word. You cannot rely on what
- size of object is accessed in order to read or write the
- bit-field; it may even vary for a given bit-field according to the
- precise usage.
-
- If you care about controlling the amount of memory that is
- accessed, use volatile but do not use bit-fields.
-
- * GCC comes with shell scripts to fix certain known problems in
- system header files. They install corrected copies of various
- header files in a special directory where only GCC will normally
- look for them. The scripts adapt to various systems by searching
- all the system header files for the problem cases that we know
- about.
-
- If new system header files are installed, nothing automatically
- arranges to update the corrected header files. They can be
- updated using the `mkheaders' script installed in
- `LIBEXECDIR/gcc/TARGET/VERSION/install-tools/'.
-
- * On 68000 and x86 systems, for instance, you can get paradoxical
- results if you test the precise values of floating point numbers.
- For example, you can find that a floating point value which is not
- a NaN is not equal to itself. This results from the fact that the
- floating point registers hold a few more bits of precision than
- fit in a `double' in memory. Compiled code moves values between
- memory and floating point registers at its convenience, and moving
- them into memory truncates them.
-
- You can partially avoid this problem by using the `-ffloat-store'
- option (*note Optimize Options::).
-
- * On AIX and other platforms without weak symbol support, templates
- need to be instantiated explicitly and symbols for static members
- of templates will not be generated.
-
- * On AIX, GCC scans object files and library archives for static
- constructors and destructors when linking an application before the
- linker prunes unreferenced symbols. This is necessary to prevent
- the AIX linker from mistakenly assuming that static constructor or
- destructor are unused and removing them before the scanning can
- occur. All static constructors and destructors found will be
- referenced even though the modules in which they occur may not be
- used by the program. This may lead to both increased executable
- size and unexpected symbol references.
-
-
-File: gcc.info, Node: C++ Misunderstandings, Next: Non-bugs, Prev: Disappointments, Up: Trouble
-
-11.8 Common Misunderstandings with GNU C++
-==========================================
-
-C++ is a complex language and an evolving one, and its standard
-definition (the ISO C++ standard) was only recently completed. As a
-result, your C++ compiler may occasionally surprise you, even when its
-behavior is correct. This section discusses some areas that frequently
-give rise to questions of this sort.
-
-* Menu:
-
-* Static Definitions:: Static member declarations are not definitions
-* Name lookup:: Name lookup, templates, and accessing members of base classes
-* Temporaries:: Temporaries may vanish before you expect
-* Copy Assignment:: Copy Assignment operators copy virtual bases twice
-
-
-File: gcc.info, Node: Static Definitions, Next: Name lookup, Up: C++ Misunderstandings
-
-11.8.1 Declare _and_ Define Static Members
-------------------------------------------
-
-When a class has static data members, it is not enough to _declare_ the
-static member; you must also _define_ it. For example:
-
- class Foo
- {
- ...
- void method();
- static int bar;
- };
-
- This declaration only establishes that the class `Foo' has an `int'
-named `Foo::bar', and a member function named `Foo::method'. But you
-still need to define _both_ `method' and `bar' elsewhere. According to
-the ISO standard, you must supply an initializer in one (and only one)
-source file, such as:
-
- int Foo::bar = 0;
-
- Other C++ compilers may not correctly implement the standard behavior.
-As a result, when you switch to `g++' from one of these compilers, you
-may discover that a program that appeared to work correctly in fact
-does not conform to the standard: `g++' reports as undefined symbols
-any static data members that lack definitions.
-
-
-File: gcc.info, Node: Name lookup, Next: Temporaries, Prev: Static Definitions, Up: C++ Misunderstandings
-
-11.8.2 Name lookup, templates, and accessing members of base classes
---------------------------------------------------------------------
-
-The C++ standard prescribes that all names that are not dependent on
-template parameters are bound to their present definitions when parsing
-a template function or class.(1) Only names that are dependent are
-looked up at the point of instantiation. For example, consider
-
- void foo(double);
-
- struct A {
- template <typename T>
- void f () {
- foo (1); // 1
- int i = N; // 2
- T t;
- t.bar(); // 3
- foo (t); // 4
- }
-
- static const int N;
- };
-
- Here, the names `foo' and `N' appear in a context that does not depend
-on the type of `T'. The compiler will thus require that they are
-defined in the context of use in the template, not only before the
-point of instantiation, and will here use `::foo(double)' and `A::N',
-respectively. In particular, it will convert the integer value to a
-`double' when passing it to `::foo(double)'.
-
- Conversely, `bar' and the call to `foo' in the fourth marked line are
-used in contexts that do depend on the type of `T', so they are only
-looked up at the point of instantiation, and you can provide
-declarations for them after declaring the template, but before
-instantiating it. In particular, if you instantiate `A::f<int>', the
-last line will call an overloaded `::foo(int)' if one was provided,
-even if after the declaration of `struct A'.
-
- This distinction between lookup of dependent and non-dependent names is
-called two-stage (or dependent) name lookup. G++ implements it since
-version 3.4.
-
- Two-stage name lookup sometimes leads to situations with behavior
-different from non-template codes. The most common is probably this:
-
- template <typename T> struct Base {
- int i;
- };
-
- template <typename T> struct Derived : public Base<T> {
- int get_i() { return i; }
- };
-
- In `get_i()', `i' is not used in a dependent context, so the compiler
-will look for a name declared at the enclosing namespace scope (which
-is the global scope here). It will not look into the base class, since
-that is dependent and you may declare specializations of `Base' even
-after declaring `Derived', so the compiler can't really know what `i'
-would refer to. If there is no global variable `i', then you will get
-an error message.
-
- In order to make it clear that you want the member of the base class,
-you need to defer lookup until instantiation time, at which the base
-class is known. For this, you need to access `i' in a dependent
-context, by either using `this->i' (remember that `this' is of type
-`Derived<T>*', so is obviously dependent), or using `Base<T>::i'.
-Alternatively, `Base<T>::i' might be brought into scope by a
-`using'-declaration.
-
- Another, similar example involves calling member functions of a base
-class:
-
- template <typename T> struct Base {
- int f();
- };
-
- template <typename T> struct Derived : Base<T> {
- int g() { return f(); };
- };
-
- Again, the call to `f()' is not dependent on template arguments (there
-are no arguments that depend on the type `T', and it is also not
-otherwise specified that the call should be in a dependent context).
-Thus a global declaration of such a function must be available, since
-the one in the base class is not visible until instantiation time. The
-compiler will consequently produce the following error message:
-
- x.cc: In member function `int Derived<T>::g()':
- x.cc:6: error: there are no arguments to `f' that depend on a template
- parameter, so a declaration of `f' must be available
- x.cc:6: error: (if you use `-fpermissive', G++ will accept your code, but
- allowing the use of an undeclared name is deprecated)
-
- To make the code valid either use `this->f()', or `Base<T>::f()'.
-Using the `-fpermissive' flag will also let the compiler accept the
-code, by marking all function calls for which no declaration is visible
-at the time of definition of the template for later lookup at
-instantiation time, as if it were a dependent call. We do not
-recommend using `-fpermissive' to work around invalid code, and it will
-also only catch cases where functions in base classes are called, not
-where variables in base classes are used (as in the example above).
-
- Note that some compilers (including G++ versions prior to 3.4) get
-these examples wrong and accept above code without an error. Those
-compilers do not implement two-stage name lookup correctly.
-
- ---------- Footnotes ----------
-
- (1) The C++ standard just uses the term "dependent" for names that
-depend on the type or value of template parameters. This shorter term
-will also be used in the rest of this section.
-
-
-File: gcc.info, Node: Temporaries, Next: Copy Assignment, Prev: Name lookup, Up: C++ Misunderstandings
-
-11.8.3 Temporaries May Vanish Before You Expect
------------------------------------------------
-
-It is dangerous to use pointers or references to _portions_ of a
-temporary object. The compiler may very well delete the object before
-you expect it to, leaving a pointer to garbage. The most common place
-where this problem crops up is in classes like string classes,
-especially ones that define a conversion function to type `char *' or
-`const char *'--which is one reason why the standard `string' class
-requires you to call the `c_str' member function. However, any class
-that returns a pointer to some internal structure is potentially
-subject to this problem.
-
- For example, a program may use a function `strfunc' that returns
-`string' objects, and another function `charfunc' that operates on
-pointers to `char':
-
- string strfunc ();
- void charfunc (const char *);
-
- void
- f ()
- {
- const char *p = strfunc().c_str();
- ...
- charfunc (p);
- ...
- charfunc (p);
- }
-
-In this situation, it may seem reasonable to save a pointer to the C
-string returned by the `c_str' member function and use that rather than
-call `c_str' repeatedly. However, the temporary string created by the
-call to `strfunc' is destroyed after `p' is initialized, at which point
-`p' is left pointing to freed memory.
-
- Code like this may run successfully under some other compilers,
-particularly obsolete cfront-based compilers that delete temporaries
-along with normal local variables. However, the GNU C++ behavior is
-standard-conforming, so if your program depends on late destruction of
-temporaries it is not portable.
-
- The safe way to write such code is to give the temporary a name, which
-forces it to remain until the end of the scope of the name. For
-example:
-
- const string& tmp = strfunc ();
- charfunc (tmp.c_str ());
-
-
-File: gcc.info, Node: Copy Assignment, Prev: Temporaries, Up: C++ Misunderstandings
-
-11.8.4 Implicit Copy-Assignment for Virtual Bases
--------------------------------------------------
-
-When a base class is virtual, only one subobject of the base class
-belongs to each full object. Also, the constructors and destructors are
-invoked only once, and called from the most-derived class. However,
-such objects behave unspecified when being assigned. For example:
-
- struct Base{
- char *name;
- Base(char *n) : name(strdup(n)){}
- Base& operator= (const Base& other){
- free (name);
- name = strdup (other.name);
- }
- };
-
- struct A:virtual Base{
- int val;
- A():Base("A"){}
- };
-
- struct B:virtual Base{
- int bval;
- B():Base("B"){}
- };
-
- struct Derived:public A, public B{
- Derived():Base("Derived"){}
- };
-
- void func(Derived &d1, Derived &d2)
- {
- d1 = d2;
- }
-
- The C++ standard specifies that `Base::Base' is only called once when
-constructing or copy-constructing a Derived object. It is unspecified
-whether `Base::operator=' is called more than once when the implicit
-copy-assignment for Derived objects is invoked (as it is inside `func'
-in the example).
-
- G++ implements the "intuitive" algorithm for copy-assignment: assign
-all direct bases, then assign all members. In that algorithm, the
-virtual base subobject can be encountered more than once. In the
-example, copying proceeds in the following order: `val', `name' (via
-`strdup'), `bval', and `name' again.
-
- If application code relies on copy-assignment, a user-defined
-copy-assignment operator removes any uncertainties. With such an
-operator, the application can define whether and how the virtual base
-subobject is assigned.
-
-
-File: gcc.info, Node: Non-bugs, Next: Warnings and Errors, Prev: C++ Misunderstandings, Up: Trouble
-
-11.9 Certain Changes We Don't Want to Make
-==========================================
-
-This section lists changes that people frequently request, but which we
-do not make because we think GCC is better without them.
-
- * Checking the number and type of arguments to a function which has
- an old-fashioned definition and no prototype.
-
- Such a feature would work only occasionally--only for calls that
- appear in the same file as the called function, following the
- definition. The only way to check all calls reliably is to add a
- prototype for the function. But adding a prototype eliminates the
- motivation for this feature. So the feature is not worthwhile.
-
- * Warning about using an expression whose type is signed as a shift
- count.
-
- Shift count operands are probably signed more often than unsigned.
- Warning about this would cause far more annoyance than good.
-
- * Warning about assigning a signed value to an unsigned variable.
-
- Such assignments must be very common; warning about them would
- cause more annoyance than good.
-
- * Warning when a non-void function value is ignored.
-
- C contains many standard functions that return a value that most
- programs choose to ignore. One obvious example is `printf'.
- Warning about this practice only leads the defensive programmer to
- clutter programs with dozens of casts to `void'. Such casts are
- required so frequently that they become visual noise. Writing
- those casts becomes so automatic that they no longer convey useful
- information about the intentions of the programmer. For functions
- where the return value should never be ignored, use the
- `warn_unused_result' function attribute (*note Function
- Attributes::).
-
- * Making `-fshort-enums' the default.
-
- This would cause storage layout to be incompatible with most other
- C compilers. And it doesn't seem very important, given that you
- can get the same result in other ways. The case where it matters
- most is when the enumeration-valued object is inside a structure,
- and in that case you can specify a field width explicitly.
-
- * Making bit-fields unsigned by default on particular machines where
- "the ABI standard" says to do so.
-
- The ISO C standard leaves it up to the implementation whether a
- bit-field declared plain `int' is signed or not. This in effect
- creates two alternative dialects of C.
-
- The GNU C compiler supports both dialects; you can specify the
- signed dialect with `-fsigned-bitfields' and the unsigned dialect
- with `-funsigned-bitfields'. However, this leaves open the
- question of which dialect to use by default.
-
- Currently, the preferred dialect makes plain bit-fields signed,
- because this is simplest. Since `int' is the same as `signed int'
- in every other context, it is cleanest for them to be the same in
- bit-fields as well.
-
- Some computer manufacturers have published Application Binary
- Interface standards which specify that plain bit-fields should be
- unsigned. It is a mistake, however, to say anything about this
- issue in an ABI. This is because the handling of plain bit-fields
- distinguishes two dialects of C. Both dialects are meaningful on
- every type of machine. Whether a particular object file was
- compiled using signed bit-fields or unsigned is of no concern to
- other object files, even if they access the same bit-fields in the
- same data structures.
-
- A given program is written in one or the other of these two
- dialects. The program stands a chance to work on most any machine
- if it is compiled with the proper dialect. It is unlikely to work
- at all if compiled with the wrong dialect.
-
- Many users appreciate the GNU C compiler because it provides an
- environment that is uniform across machines. These users would be
- inconvenienced if the compiler treated plain bit-fields
- differently on certain machines.
-
- Occasionally users write programs intended only for a particular
- machine type. On these occasions, the users would benefit if the
- GNU C compiler were to support by default the same dialect as the
- other compilers on that machine. But such applications are rare.
- And users writing a program to run on more than one type of
- machine cannot possibly benefit from this kind of compatibility.
-
- This is why GCC does and will treat plain bit-fields in the same
- fashion on all types of machines (by default).
-
- There are some arguments for making bit-fields unsigned by default
- on all machines. If, for example, this becomes a universal de
- facto standard, it would make sense for GCC to go along with it.
- This is something to be considered in the future.
-
- (Of course, users strongly concerned about portability should
- indicate explicitly in each bit-field whether it is signed or not.
- In this way, they write programs which have the same meaning in
- both C dialects.)
-
- * Undefining `__STDC__' when `-ansi' is not used.
-
- Currently, GCC defines `__STDC__' unconditionally. This provides
- good results in practice.
-
- Programmers normally use conditionals on `__STDC__' to ask whether
- it is safe to use certain features of ISO C, such as function
- prototypes or ISO token concatenation. Since plain `gcc' supports
- all the features of ISO C, the correct answer to these questions is
- "yes".
-
- Some users try to use `__STDC__' to check for the availability of
- certain library facilities. This is actually incorrect usage in
- an ISO C program, because the ISO C standard says that a conforming
- freestanding implementation should define `__STDC__' even though it
- does not have the library facilities. `gcc -ansi -pedantic' is a
- conforming freestanding implementation, and it is therefore
- required to define `__STDC__', even though it does not come with
- an ISO C library.
-
- Sometimes people say that defining `__STDC__' in a compiler that
- does not completely conform to the ISO C standard somehow violates
- the standard. This is illogical. The standard is a standard for
- compilers that claim to support ISO C, such as `gcc -ansi'--not
- for other compilers such as plain `gcc'. Whatever the ISO C
- standard says is relevant to the design of plain `gcc' without
- `-ansi' only for pragmatic reasons, not as a requirement.
-
- GCC normally defines `__STDC__' to be 1, and in addition defines
- `__STRICT_ANSI__' if you specify the `-ansi' option, or a `-std'
- option for strict conformance to some version of ISO C. On some
- hosts, system include files use a different convention, where
- `__STDC__' is normally 0, but is 1 if the user specifies strict
- conformance to the C Standard. GCC follows the host convention
- when processing system include files, but when processing user
- files it follows the usual GNU C convention.
-
- * Undefining `__STDC__' in C++.
-
- Programs written to compile with C++-to-C translators get the
- value of `__STDC__' that goes with the C compiler that is
- subsequently used. These programs must test `__STDC__' to
- determine what kind of C preprocessor that compiler uses: whether
- they should concatenate tokens in the ISO C fashion or in the
- traditional fashion.
-
- These programs work properly with GNU C++ if `__STDC__' is defined.
- They would not work otherwise.
-
- In addition, many header files are written to provide prototypes
- in ISO C but not in traditional C. Many of these header files can
- work without change in C++ provided `__STDC__' is defined. If
- `__STDC__' is not defined, they will all fail, and will all need
- to be changed to test explicitly for C++ as well.
-
- * Deleting "empty" loops.
-
- Historically, GCC has not deleted "empty" loops under the
- assumption that the most likely reason you would put one in a
- program is to have a delay, so deleting them will not make real
- programs run any faster.
-
- However, the rationale here is that optimization of a nonempty loop
- cannot produce an empty one. This held for carefully written C
- compiled with less powerful optimizers but is not always the case
- for carefully written C++ or with more powerful optimizers. Thus
- GCC will remove operations from loops whenever it can determine
- those operations are not externally visible (apart from the time
- taken to execute them, of course). In case the loop can be proved
- to be finite, GCC will also remove the loop itself.
-
- Be aware of this when performing timing tests, for instance the
- following loop can be completely removed, provided
- `some_expression' can provably not change any global state.
-
- {
- int sum = 0;
- int ix;
-
- for (ix = 0; ix != 10000; ix++)
- sum += some_expression;
- }
-
- Even though `sum' is accumulated in the loop, no use is made of
- that summation, so the accumulation can be removed.
-
- * Making side effects happen in the same order as in some other
- compiler.
-
- It is never safe to depend on the order of evaluation of side
- effects. For example, a function call like this may very well
- behave differently from one compiler to another:
-
- void func (int, int);
-
- int i = 2;
- func (i++, i++);
-
- There is no guarantee (in either the C or the C++ standard language
- definitions) that the increments will be evaluated in any
- particular order. Either increment might happen first. `func'
- might get the arguments `2, 3', or it might get `3, 2', or even
- `2, 2'.
-
- * Making certain warnings into errors by default.
-
- Some ISO C testsuites report failure when the compiler does not
- produce an error message for a certain program.
-
- ISO C requires a "diagnostic" message for certain kinds of invalid
- programs, but a warning is defined by GCC to count as a
- diagnostic. If GCC produces a warning but not an error, that is
- correct ISO C support. If testsuites call this "failure", they
- should be run with the GCC option `-pedantic-errors', which will
- turn these warnings into errors.
-
-
-
-File: gcc.info, Node: Warnings and Errors, Prev: Non-bugs, Up: Trouble
-
-11.10 Warning Messages and Error Messages
-=========================================
-
-The GNU compiler can produce two kinds of diagnostics: errors and
-warnings. Each kind has a different purpose:
-
- "Errors" report problems that make it impossible to compile your
- program. GCC reports errors with the source file name and line
- number where the problem is apparent.
-
- "Warnings" report other unusual conditions in your code that _may_
- indicate a problem, although compilation can (and does) proceed.
- Warning messages also report the source file name and line number,
- but include the text `warning:' to distinguish them from error
- messages.
-
- Warnings may indicate danger points where you should check to make sure
-that your program really does what you intend; or the use of obsolete
-features; or the use of nonstandard features of GNU C or C++. Many
-warnings are issued only if you ask for them, with one of the `-W'
-options (for instance, `-Wall' requests a variety of useful warnings).
-
- GCC always tries to compile your program if possible; it never
-gratuitously rejects a program whose meaning is clear merely because
-(for instance) it fails to conform to a standard. In some cases,
-however, the C and C++ standards specify that certain extensions are
-forbidden, and a diagnostic _must_ be issued by a conforming compiler.
-The `-pedantic' option tells GCC to issue warnings in such cases;
-`-pedantic-errors' says to make them errors instead. This does not
-mean that _all_ non-ISO constructs get warnings or errors.
-
- *Note Options to Request or Suppress Warnings: Warning Options, for
-more detail on these and related command-line options.
-
-
-File: gcc.info, Node: Bugs, Next: Service, Prev: Trouble, Up: Top
-
-12 Reporting Bugs
-*****************
-
-Your bug reports play an essential role in making GCC reliable.
-
- When you encounter a problem, the first thing to do is to see if it is
-already known. *Note Trouble::. If it isn't known, then you should
-report the problem.
-
-* Menu:
-
-* Criteria: Bug Criteria. Have you really found a bug?
-* Reporting: Bug Reporting. How to report a bug effectively.
-* Known: Trouble. Known problems.
-* Help: Service. Where to ask for help.
-
-
-File: gcc.info, Node: Bug Criteria, Next: Bug Reporting, Up: Bugs
-
-12.1 Have You Found a Bug?
-==========================
-
-If you are not sure whether you have found a bug, here are some
-guidelines:
-
- * If the compiler gets a fatal signal, for any input whatever, that
- is a compiler bug. Reliable compilers never crash.
-
- * If the compiler produces invalid assembly code, for any input
- whatever (except an `asm' statement), that is a compiler bug,
- unless the compiler reports errors (not just warnings) which would
- ordinarily prevent the assembler from being run.
-
- * If the compiler produces valid assembly code that does not
- correctly execute the input source code, that is a compiler bug.
-
- However, you must double-check to make sure, because you may have a
- program whose behavior is undefined, which happened by chance to
- give the desired results with another C or C++ compiler.
-
- For example, in many nonoptimizing compilers, you can write `x;'
- at the end of a function instead of `return x;', with the same
- results. But the value of the function is undefined if `return'
- is omitted; it is not a bug when GCC produces different results.
-
- Problems often result from expressions with two increment
- operators, as in `f (*p++, *p++)'. Your previous compiler might
- have interpreted that expression the way you intended; GCC might
- interpret it another way. Neither compiler is wrong. The bug is
- in your code.
-
- After you have localized the error to a single source line, it
- should be easy to check for these things. If your program is
- correct and well defined, you have found a compiler bug.
-
- * If the compiler produces an error message for valid input, that is
- a compiler bug.
-
- * If the compiler does not produce an error message for invalid
- input, that is a compiler bug. However, you should note that your
- idea of "invalid input" might be someone else's idea of "an
- extension" or "support for traditional practice".
-
- * If you are an experienced user of one of the languages GCC
- supports, your suggestions for improvement of GCC are welcome in
- any case.
-
-
-File: gcc.info, Node: Bug Reporting, Prev: Bug Criteria, Up: Bugs
-
-12.2 How and where to Report Bugs
-=================================
-
-Bugs should be reported to the bug database at
-`http://gcc.gnu.org/bugs.html'.
-
-
-File: gcc.info, Node: Service, Next: Contributing, Prev: Bugs, Up: Top
-
-13 How To Get Help with GCC
-***************************
-
-If you need help installing, using or changing GCC, there are two ways
-to find it:
-
- * Send a message to a suitable network mailing list. First try
- <gcc-help@gcc.gnu.org> (for help installing or using GCC), and if
- that brings no response, try <gcc@gcc.gnu.org>. For help changing
- GCC, ask <gcc@gcc.gnu.org>. If you think you have found a bug in
- GCC, please report it following the instructions at *note Bug
- Reporting::.
-
- * Look in the service directory for someone who might help you for a
- fee. The service directory is found at
- `http://www.fsf.org/resources/service'.
-
- For further information, see `http://gcc.gnu.org/faq.html#support'.
-
-
-File: gcc.info, Node: Contributing, Next: Funding, Prev: Service, Up: Top
-
-14 Contributing to GCC Development
-**********************************
-
-If you would like to help pretest GCC releases to assure they work well,
-current development sources are available by SVN (see
-`http://gcc.gnu.org/svn.html'). Source and binary snapshots are also
-available for FTP; see `http://gcc.gnu.org/snapshots.html'.
-
- If you would like to work on improvements to GCC, please read the
-advice at these URLs:
-
- `http://gcc.gnu.org/contribute.html'
- `http://gcc.gnu.org/contributewhy.html'
-
-for information on how to make useful contributions and avoid
-duplication of effort. Suggested projects are listed at
-`http://gcc.gnu.org/projects/'.
-
-
-File: gcc.info, Node: Funding, Next: GNU Project, Prev: Contributing, Up: Top
-
-Funding Free Software
-*********************
-
-If you want to have more free software a few years from now, it makes
-sense for you to help encourage people to contribute funds for its
-development. The most effective approach known is to encourage
-commercial redistributors to donate.
-
- Users of free software systems can boost the pace of development by
-encouraging for-a-fee distributors to donate part of their selling price
-to free software developers--the Free Software Foundation, and others.
-
- The way to convince distributors to do this is to demand it and expect
-it from them. So when you compare distributors, judge them partly by
-how much they give to free software development. Show distributors
-they must compete to be the one who gives the most.
-
- To make this approach work, you must insist on numbers that you can
-compare, such as, "We will donate ten dollars to the Frobnitz project
-for each disk sold." Don't be satisfied with a vague promise, such as
-"A portion of the profits are donated," since it doesn't give a basis
-for comparison.
-
- Even a precise fraction "of the profits from this disk" is not very
-meaningful, since creative accounting and unrelated business decisions
-can greatly alter what fraction of the sales price counts as profit.
-If the price you pay is $50, ten percent of the profit is probably less
-than a dollar; it might be a few cents, or nothing at all.
-
- Some redistributors do development work themselves. This is useful
-too; but to keep everyone honest, you need to inquire how much they do,
-and what kind. Some kinds of development make much more long-term
-difference than others. For example, maintaining a separate version of
-a program contributes very little; maintaining the standard version of a
-program for the whole community contributes much. Easy new ports
-contribute little, since someone else would surely do them; difficult
-ports such as adding a new CPU to the GNU Compiler Collection
-contribute more; major new features or packages contribute the most.
-
- By establishing the idea that supporting further development is "the
-proper thing to do" when distributing free software for a fee, we can
-assure a steady flow of resources into making more free software.
-
- Copyright (C) 1994 Free Software Foundation, Inc.
- Verbatim copying and redistribution of this section is permitted
- without royalty; alteration is not permitted.
-
-
-File: gcc.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top
-
-The GNU Project and GNU/Linux
-*****************************
-
-The GNU Project was launched in 1984 to develop a complete Unix-like
-operating system which is free software: the GNU system. (GNU is a
-recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".)
-Variants of the GNU operating system, which use the kernel Linux, are
-now widely used; though these systems are often referred to as "Linux",
-they are more accurately called GNU/Linux systems.
-
- For more information, see:
- `http://www.gnu.org/'
- `http://www.gnu.org/gnu/linux-and-gnu.html'
-
-
-File: gcc.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top
-
-GNU General Public License
-**************************
-
- Version 3, 29 June 2007
-
- Copyright (C) 2007 Free Software Foundation, Inc. `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies of this
- license document, but changing it is not allowed.
-
-Preamble
-========
-
-The GNU General Public License is a free, copyleft license for software
-and other kinds of works.
-
- The licenses for most software and other practical works are designed
-to take away your freedom to share and change the works. By contrast,
-the GNU General Public License is intended to guarantee your freedom to
-share and change all versions of a program-to make sure it remains free
-software for all its users. We, the Free Software Foundation, use the
-GNU General Public License for most of our software; it applies also to
-any other work released this way by its authors. You can apply it to
-your programs, too.
-
- When we speak of free software, we are referring to freedom, not
-price. Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-them if you wish), that you receive source code or can get it if you
-want it, that you can change the software or use pieces of it in new
-free programs, and that you know you can do these things.
-
- To protect your rights, we need to prevent others from denying you
-these rights or asking you to surrender the rights. Therefore, you
-have certain responsibilities if you distribute copies of the software,
-or if you modify it: responsibilities to respect the freedom of others.
-
- For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must pass on to the recipients the same
-freedoms that you received. You must make sure that they, too, receive
-or can get the source code. And you must show them these terms so they
-know their rights.
-
- Developers that use the GNU GPL protect your rights with two steps:
-(1) assert copyright on the software, and (2) offer you this License
-giving you legal permission to copy, distribute and/or modify it.
-
- For the developers' and authors' protection, the GPL clearly explains
-that there is no warranty for this free software. For both users' and
-authors' sake, the GPL requires that modified versions be marked as
-changed, so that their problems will not be attributed erroneously to
-authors of previous versions.
-
- Some devices are designed to deny users access to install or run
-modified versions of the software inside them, although the
-manufacturer can do so. This is fundamentally incompatible with the
-aim of protecting users' freedom to change the software. The
-systematic pattern of such abuse occurs in the area of products for
-individuals to use, which is precisely where it is most unacceptable.
-Therefore, we have designed this version of the GPL to prohibit the
-practice for those products. If such problems arise substantially in
-other domains, we stand ready to extend this provision to those domains
-in future versions of the GPL, as needed to protect the freedom of
-users.
-
- Finally, every program is threatened constantly by software patents.
-States should not allow patents to restrict development and use of
-software on general-purpose computers, but in those that do, we wish to
-avoid the special danger that patents applied to a free program could
-make it effectively proprietary. To prevent this, the GPL assures that
-patents cannot be used to render the program non-free.
-
- The precise terms and conditions for copying, distribution and
-modification follow.
-
-TERMS AND CONDITIONS
-====================
-
- 0. Definitions.
-
- "This License" refers to version 3 of the GNU General Public
- License.
-
- "Copyright" also means copyright-like laws that apply to other
- kinds of works, such as semiconductor masks.
-
- "The Program" refers to any copyrightable work licensed under this
- License. Each licensee is addressed as "you". "Licensees" and
- "recipients" may be individuals or organizations.
-
- To "modify" a work means to copy from or adapt all or part of the
- work in a fashion requiring copyright permission, other than the
- making of an exact copy. The resulting work is called a "modified
- version" of the earlier work or a work "based on" the earlier work.
-
- A "covered work" means either the unmodified Program or a work
- based on the Program.
-
- To "propagate" a work means to do anything with it that, without
- permission, would make you directly or secondarily liable for
- infringement under applicable copyright law, except executing it
- on a computer or modifying a private copy. Propagation includes
- copying, distribution (with or without modification), making
- available to the public, and in some countries other activities as
- well.
-
- To "convey" a work means any kind of propagation that enables other
- parties to make or receive copies. Mere interaction with a user
- through a computer network, with no transfer of a copy, is not
- conveying.
-
- An interactive user interface displays "Appropriate Legal Notices"
- to the extent that it includes a convenient and prominently visible
- feature that (1) displays an appropriate copyright notice, and (2)
- tells the user that there is no warranty for the work (except to
- the extent that warranties are provided), that licensees may
- convey the work under this License, and how to view a copy of this
- License. If the interface presents a list of user commands or
- options, such as a menu, a prominent item in the list meets this
- criterion.
-
- 1. Source Code.
-
- The "source code" for a work means the preferred form of the work
- for making modifications to it. "Object code" means any
- non-source form of a work.
-
- A "Standard Interface" means an interface that either is an
- official standard defined by a recognized standards body, or, in
- the case of interfaces specified for a particular programming
- language, one that is widely used among developers working in that
- language.
-
- The "System Libraries" of an executable work include anything,
- other than the work as a whole, that (a) is included in the normal
- form of packaging a Major Component, but which is not part of that
- Major Component, and (b) serves only to enable use of the work
- with that Major Component, or to implement a Standard Interface
- for which an implementation is available to the public in source
- code form. A "Major Component", in this context, means a major
- essential component (kernel, window system, and so on) of the
- specific operating system (if any) on which the executable work
- runs, or a compiler used to produce the work, or an object code
- interpreter used to run it.
-
- The "Corresponding Source" for a work in object code form means all
- the source code needed to generate, install, and (for an executable
- work) run the object code and to modify the work, including
- scripts to control those activities. However, it does not include
- the work's System Libraries, or general-purpose tools or generally
- available free programs which are used unmodified in performing
- those activities but which are not part of the work. For example,
- Corresponding Source includes interface definition files
- associated with source files for the work, and the source code for
- shared libraries and dynamically linked subprograms that the work
- is specifically designed to require, such as by intimate data
- communication or control flow between those subprograms and other
- parts of the work.
-
- The Corresponding Source need not include anything that users can
- regenerate automatically from other parts of the Corresponding
- Source.
-
- The Corresponding Source for a work in source code form is that
- same work.
-
- 2. Basic Permissions.
-
- All rights granted under this License are granted for the term of
- copyright on the Program, and are irrevocable provided the stated
- conditions are met. This License explicitly affirms your unlimited
- permission to run the unmodified Program. The output from running
- a covered work is covered by this License only if the output,
- given its content, constitutes a covered work. This License
- acknowledges your rights of fair use or other equivalent, as
- provided by copyright law.
-
- You may make, run and propagate covered works that you do not
- convey, without conditions so long as your license otherwise
- remains in force. You may convey covered works to others for the
- sole purpose of having them make modifications exclusively for
- you, or provide you with facilities for running those works,
- provided that you comply with the terms of this License in
- conveying all material for which you do not control copyright.
- Those thus making or running the covered works for you must do so
- exclusively on your behalf, under your direction and control, on
- terms that prohibit them from making any copies of your
- copyrighted material outside their relationship with you.
-
- Conveying under any other circumstances is permitted solely under
- the conditions stated below. Sublicensing is not allowed; section
- 10 makes it unnecessary.
-
- 3. Protecting Users' Legal Rights From Anti-Circumvention Law.
-
- No covered work shall be deemed part of an effective technological
- measure under any applicable law fulfilling obligations under
- article 11 of the WIPO copyright treaty adopted on 20 December
- 1996, or similar laws prohibiting or restricting circumvention of
- such measures.
-
- When you convey a covered work, you waive any legal power to forbid
- circumvention of technological measures to the extent such
- circumvention is effected by exercising rights under this License
- with respect to the covered work, and you disclaim any intention
- to limit operation or modification of the work as a means of
- enforcing, against the work's users, your or third parties' legal
- rights to forbid circumvention of technological measures.
-
- 4. Conveying Verbatim Copies.
-
- You may convey verbatim copies of the Program's source code as you
- receive it, in any medium, provided that you conspicuously and
- appropriately publish on each copy an appropriate copyright notice;
- keep intact all notices stating that this License and any
- non-permissive terms added in accord with section 7 apply to the
- code; keep intact all notices of the absence of any warranty; and
- give all recipients a copy of this License along with the Program.
-
- You may charge any price or no price for each copy that you convey,
- and you may offer support or warranty protection for a fee.
-
- 5. Conveying Modified Source Versions.
-
- You may convey a work based on the Program, or the modifications to
- produce it from the Program, in the form of source code under the
- terms of section 4, provided that you also meet all of these
- conditions:
-
- a. The work must carry prominent notices stating that you
- modified it, and giving a relevant date.
-
- b. The work must carry prominent notices stating that it is
- released under this License and any conditions added under
- section 7. This requirement modifies the requirement in
- section 4 to "keep intact all notices".
-
- c. You must license the entire work, as a whole, under this
- License to anyone who comes into possession of a copy. This
- License will therefore apply, along with any applicable
- section 7 additional terms, to the whole of the work, and all
- its parts, regardless of how they are packaged. This License
- gives no permission to license the work in any other way, but
- it does not invalidate such permission if you have separately
- received it.
-
- d. If the work has interactive user interfaces, each must display
- Appropriate Legal Notices; however, if the Program has
- interactive interfaces that do not display Appropriate Legal
- Notices, your work need not make them do so.
-
- A compilation of a covered work with other separate and independent
- works, which are not by their nature extensions of the covered
- work, and which are not combined with it such as to form a larger
- program, in or on a volume of a storage or distribution medium, is
- called an "aggregate" if the compilation and its resulting
- copyright are not used to limit the access or legal rights of the
- compilation's users beyond what the individual works permit.
- Inclusion of a covered work in an aggregate does not cause this
- License to apply to the other parts of the aggregate.
-
- 6. Conveying Non-Source Forms.
-
- You may convey a covered work in object code form under the terms
- of sections 4 and 5, provided that you also convey the
- machine-readable Corresponding Source under the terms of this
- License, in one of these ways:
-
- a. Convey the object code in, or embodied in, a physical product
- (including a physical distribution medium), accompanied by the
- Corresponding Source fixed on a durable physical medium
- customarily used for software interchange.
-
- b. Convey the object code in, or embodied in, a physical product
- (including a physical distribution medium), accompanied by a
- written offer, valid for at least three years and valid for
- as long as you offer spare parts or customer support for that
- product model, to give anyone who possesses the object code
- either (1) a copy of the Corresponding Source for all the
- software in the product that is covered by this License, on a
- durable physical medium customarily used for software
- interchange, for a price no more than your reasonable cost of
- physically performing this conveying of source, or (2) access
- to copy the Corresponding Source from a network server at no
- charge.
-
- c. Convey individual copies of the object code with a copy of
- the written offer to provide the Corresponding Source. This
- alternative is allowed only occasionally and noncommercially,
- and only if you received the object code with such an offer,
- in accord with subsection 6b.
-
- d. Convey the object code by offering access from a designated
- place (gratis or for a charge), and offer equivalent access
- to the Corresponding Source in the same way through the same
- place at no further charge. You need not require recipients
- to copy the Corresponding Source along with the object code.
- If the place to copy the object code is a network server, the
- Corresponding Source may be on a different server (operated
- by you or a third party) that supports equivalent copying
- facilities, provided you maintain clear directions next to
- the object code saying where to find the Corresponding Source.
- Regardless of what server hosts the Corresponding Source, you
- remain obligated to ensure that it is available for as long
- as needed to satisfy these requirements.
-
- e. Convey the object code using peer-to-peer transmission,
- provided you inform other peers where the object code and
- Corresponding Source of the work are being offered to the
- general public at no charge under subsection 6d.
-
-
- A separable portion of the object code, whose source code is
- excluded from the Corresponding Source as a System Library, need
- not be included in conveying the object code work.
-
- A "User Product" is either (1) a "consumer product", which means
- any tangible personal property which is normally used for personal,
- family, or household purposes, or (2) anything designed or sold for
- incorporation into a dwelling. In determining whether a product
- is a consumer product, doubtful cases shall be resolved in favor of
- coverage. For a particular product received by a particular user,
- "normally used" refers to a typical or common use of that class of
- product, regardless of the status of the particular user or of the
- way in which the particular user actually uses, or expects or is
- expected to use, the product. A product is a consumer product
- regardless of whether the product has substantial commercial,
- industrial or non-consumer uses, unless such uses represent the
- only significant mode of use of the product.
-
- "Installation Information" for a User Product means any methods,
- procedures, authorization keys, or other information required to
- install and execute modified versions of a covered work in that
- User Product from a modified version of its Corresponding Source.
- The information must suffice to ensure that the continued
- functioning of the modified object code is in no case prevented or
- interfered with solely because modification has been made.
-
- If you convey an object code work under this section in, or with,
- or specifically for use in, a User Product, and the conveying
- occurs as part of a transaction in which the right of possession
- and use of the User Product is transferred to the recipient in
- perpetuity or for a fixed term (regardless of how the transaction
- is characterized), the Corresponding Source conveyed under this
- section must be accompanied by the Installation Information. But
- this requirement does not apply if neither you nor any third party
- retains the ability to install modified object code on the User
- Product (for example, the work has been installed in ROM).
-
- The requirement to provide Installation Information does not
- include a requirement to continue to provide support service,
- warranty, or updates for a work that has been modified or
- installed by the recipient, or for the User Product in which it
- has been modified or installed. Access to a network may be denied
- when the modification itself materially and adversely affects the
- operation of the network or violates the rules and protocols for
- communication across the network.
-
- Corresponding Source conveyed, and Installation Information
- provided, in accord with this section must be in a format that is
- publicly documented (and with an implementation available to the
- public in source code form), and must require no special password
- or key for unpacking, reading or copying.
-
- 7. Additional Terms.
-
- "Additional permissions" are terms that supplement the terms of
- this License by making exceptions from one or more of its
- conditions. Additional permissions that are applicable to the
- entire Program shall be treated as though they were included in
- this License, to the extent that they are valid under applicable
- law. If additional permissions apply only to part of the Program,
- that part may be used separately under those permissions, but the
- entire Program remains governed by this License without regard to
- the additional permissions.
-
- When you convey a copy of a covered work, you may at your option
- remove any additional permissions from that copy, or from any part
- of it. (Additional permissions may be written to require their own
- removal in certain cases when you modify the work.) You may place
- additional permissions on material, added by you to a covered work,
- for which you have or can give appropriate copyright permission.
-
- Notwithstanding any other provision of this License, for material
- you add to a covered work, you may (if authorized by the copyright
- holders of that material) supplement the terms of this License
- with terms:
-
- a. Disclaiming warranty or limiting liability differently from
- the terms of sections 15 and 16 of this License; or
-
- b. Requiring preservation of specified reasonable legal notices
- or author attributions in that material or in the Appropriate
- Legal Notices displayed by works containing it; or
-
- c. Prohibiting misrepresentation of the origin of that material,
- or requiring that modified versions of such material be
- marked in reasonable ways as different from the original
- version; or
-
- d. Limiting the use for publicity purposes of names of licensors
- or authors of the material; or
-
- e. Declining to grant rights under trademark law for use of some
- trade names, trademarks, or service marks; or
-
- f. Requiring indemnification of licensors and authors of that
- material by anyone who conveys the material (or modified
- versions of it) with contractual assumptions of liability to
- the recipient, for any liability that these contractual
- assumptions directly impose on those licensors and authors.
-
- All other non-permissive additional terms are considered "further
- restrictions" within the meaning of section 10. If the Program as
- you received it, or any part of it, contains a notice stating that
- it is governed by this License along with a term that is a further
- restriction, you may remove that term. If a license document
- contains a further restriction but permits relicensing or
- conveying under this License, you may add to a covered work
- material governed by the terms of that license document, provided
- that the further restriction does not survive such relicensing or
- conveying.
-
- If you add terms to a covered work in accord with this section, you
- must place, in the relevant source files, a statement of the
- additional terms that apply to those files, or a notice indicating
- where to find the applicable terms.
-
- Additional terms, permissive or non-permissive, may be stated in
- the form of a separately written license, or stated as exceptions;
- the above requirements apply either way.
-
- 8. Termination.
-
- You may not propagate or modify a covered work except as expressly
- provided under this License. Any attempt otherwise to propagate or
- modify it is void, and will automatically terminate your rights
- under this License (including any patent licenses granted under
- the third paragraph of section 11).
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, you do not qualify to receive new
- licenses for the same material under section 10.
-
- 9. Acceptance Not Required for Having Copies.
-
- You are not required to accept this License in order to receive or
- run a copy of the Program. Ancillary propagation of a covered work
- occurring solely as a consequence of using peer-to-peer
- transmission to receive a copy likewise does not require
- acceptance. However, nothing other than this License grants you
- permission to propagate or modify any covered work. These actions
- infringe copyright if you do not accept this License. Therefore,
- by modifying or propagating a covered work, you indicate your
- acceptance of this License to do so.
-
- 10. Automatic Licensing of Downstream Recipients.
-
- Each time you convey a covered work, the recipient automatically
- receives a license from the original licensors, to run, modify and
- propagate that work, subject to this License. You are not
- responsible for enforcing compliance by third parties with this
- License.
-
- An "entity transaction" is a transaction transferring control of an
- organization, or substantially all assets of one, or subdividing an
- organization, or merging organizations. If propagation of a
- covered work results from an entity transaction, each party to that
- transaction who receives a copy of the work also receives whatever
- licenses to the work the party's predecessor in interest had or
- could give under the previous paragraph, plus a right to
- possession of the Corresponding Source of the work from the
- predecessor in interest, if the predecessor has it or can get it
- with reasonable efforts.
-
- You may not impose any further restrictions on the exercise of the
- rights granted or affirmed under this License. For example, you
- may not impose a license fee, royalty, or other charge for
- exercise of rights granted under this License, and you may not
- initiate litigation (including a cross-claim or counterclaim in a
- lawsuit) alleging that any patent claim is infringed by making,
- using, selling, offering for sale, or importing the Program or any
- portion of it.
-
- 11. Patents.
-
- A "contributor" is a copyright holder who authorizes use under this
- License of the Program or a work on which the Program is based.
- The work thus licensed is called the contributor's "contributor
- version".
-
- A contributor's "essential patent claims" are all patent claims
- owned or controlled by the contributor, whether already acquired or
- hereafter acquired, that would be infringed by some manner,
- permitted by this License, of making, using, or selling its
- contributor version, but do not include claims that would be
- infringed only as a consequence of further modification of the
- contributor version. For purposes of this definition, "control"
- includes the right to grant patent sublicenses in a manner
- consistent with the requirements of this License.
-
- Each contributor grants you a non-exclusive, worldwide,
- royalty-free patent license under the contributor's essential
- patent claims, to make, use, sell, offer for sale, import and
- otherwise run, modify and propagate the contents of its
- contributor version.
-
- In the following three paragraphs, a "patent license" is any
- express agreement or commitment, however denominated, not to
- enforce a patent (such as an express permission to practice a
- patent or covenant not to sue for patent infringement). To
- "grant" such a patent license to a party means to make such an
- agreement or commitment not to enforce a patent against the party.
-
- If you convey a covered work, knowingly relying on a patent
- license, and the Corresponding Source of the work is not available
- for anyone to copy, free of charge and under the terms of this
- License, through a publicly available network server or other
- readily accessible means, then you must either (1) cause the
- Corresponding Source to be so available, or (2) arrange to deprive
- yourself of the benefit of the patent license for this particular
- work, or (3) arrange, in a manner consistent with the requirements
- of this License, to extend the patent license to downstream
- recipients. "Knowingly relying" means you have actual knowledge
- that, but for the patent license, your conveying the covered work
- in a country, or your recipient's use of the covered work in a
- country, would infringe one or more identifiable patents in that
- country that you have reason to believe are valid.
-
- If, pursuant to or in connection with a single transaction or
- arrangement, you convey, or propagate by procuring conveyance of, a
- covered work, and grant a patent license to some of the parties
- receiving the covered work authorizing them to use, propagate,
- modify or convey a specific copy of the covered work, then the
- patent license you grant is automatically extended to all
- recipients of the covered work and works based on it.
-
- A patent license is "discriminatory" if it does not include within
- the scope of its coverage, prohibits the exercise of, or is
- conditioned on the non-exercise of one or more of the rights that
- are specifically granted under this License. You may not convey a
- covered work if you are a party to an arrangement with a third
- party that is in the business of distributing software, under
- which you make payment to the third party based on the extent of
- your activity of conveying the work, and under which the third
- party grants, to any of the parties who would receive the covered
- work from you, a discriminatory patent license (a) in connection
- with copies of the covered work conveyed by you (or copies made
- from those copies), or (b) primarily for and in connection with
- specific products or compilations that contain the covered work,
- unless you entered into that arrangement, or that patent license
- was granted, prior to 28 March 2007.
-
- Nothing in this License shall be construed as excluding or limiting
- any implied license or other defenses to infringement that may
- otherwise be available to you under applicable patent law.
-
- 12. No Surrender of Others' Freedom.
-
- If conditions are imposed on you (whether by court order,
- agreement or otherwise) that contradict the conditions of this
- License, they do not excuse you from the conditions of this
- License. If you cannot convey a covered work so as to satisfy
- simultaneously your obligations under this License and any other
- pertinent obligations, then as a consequence you may not convey it
- at all. For example, if you agree to terms that obligate you to
- collect a royalty for further conveying from those to whom you
- convey the Program, the only way you could satisfy both those
- terms and this License would be to refrain entirely from conveying
- the Program.
-
- 13. Use with the GNU Affero General Public License.
-
- Notwithstanding any other provision of this License, you have
- permission to link or combine any covered work with a work licensed
- under version 3 of the GNU Affero General Public License into a
- single combined work, and to convey the resulting work. The terms
- of this License will continue to apply to the part which is the
- covered work, but the special requirements of the GNU Affero
- General Public License, section 13, concerning interaction through
- a network will apply to the combination as such.
-
- 14. Revised Versions of this License.
-
- The Free Software Foundation may publish revised and/or new
- versions of the GNU General Public License from time to time.
- Such new versions will be similar in spirit to the present
- version, but may differ in detail to address new problems or
- concerns.
-
- Each version is given a distinguishing version number. If the
- Program specifies that a certain numbered version of the GNU
- General Public License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that numbered version or of any later version published by the
- Free Software Foundation. If the Program does not specify a
- version number of the GNU General Public License, you may choose
- any version ever published by the Free Software Foundation.
-
- If the Program specifies that a proxy can decide which future
- versions of the GNU General Public License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Program.
-
- Later license versions may give you additional or different
- permissions. However, no additional obligations are imposed on any
- author or copyright holder as a result of your choosing to follow a
- later version.
-
- 15. Disclaimer of Warranty.
-
- THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
- APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
- COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
- WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
- INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE
- RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.
- SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
- NECESSARY SERVICING, REPAIR OR CORRECTION.
-
- 16. Limitation of Liability.
-
- IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
- WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
- AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
- FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
- CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
- THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
- BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
- PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
- PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
- THE POSSIBILITY OF SUCH DAMAGES.
-
- 17. Interpretation of Sections 15 and 16.
-
- If the disclaimer of warranty and limitation of liability provided
- above cannot be given local legal effect according to their terms,
- reviewing courts shall apply local law that most closely
- approximates an absolute waiver of all civil liability in
- connection with the Program, unless a warranty or assumption of
- liability accompanies a copy of the Program in return for a fee.
-
-
-END OF TERMS AND CONDITIONS
-===========================
-
-How to Apply These Terms to Your New Programs
-=============================================
-
-If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these
-terms.
-
- To do so, attach the following notices to the program. It is safest
-to attach them to the start of each source file to most effectively
-state the exclusion of warranty; and each file should have at least the
-"copyright" line and a pointer to where the full notice is found.
-
- ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
- Copyright (C) YEAR NAME OF AUTHOR
-
- This program is free software: you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation, either version 3 of the License, or (at
- your option) any later version.
-
- This program is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program. If not, see `http://www.gnu.org/licenses/'.
-
- Also add information on how to contact you by electronic and paper
-mail.
-
- If the program does terminal interaction, make it output a short
-notice like this when it starts in an interactive mode:
-
- PROGRAM Copyright (C) YEAR NAME OF AUTHOR
- This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
- This is free software, and you are welcome to redistribute it
- under certain conditions; type `show c' for details.
-
- The hypothetical commands `show w' and `show c' should show the
-appropriate parts of the General Public License. Of course, your
-program's commands might be different; for a GUI interface, you would
-use an "about box".
-
- You should also get your employer (if you work as a programmer) or
-school, if any, to sign a "copyright disclaimer" for the program, if
-necessary. For more information on this, and how to apply and follow
-the GNU GPL, see `http://www.gnu.org/licenses/'.
-
- The GNU General Public License does not permit incorporating your
-program into proprietary programs. If your program is a subroutine
-library, you may consider it more useful to permit linking proprietary
-applications with the library. If this is what you want to do, use the
-GNU Lesser General Public License instead of this License. But first,
-please read `http://www.gnu.org/philosophy/why-not-lgpl.html'.
-
-
-File: gcc.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top
-
-GNU Free Documentation License
-******************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
-replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: gcc.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top
-
-Contributors to GCC
-*******************
-
-The GCC project would like to thank its many contributors. Without
-them the project would not have been nearly as successful as it has
-been. Any omissions in this list are accidental. Feel free to contact
-<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or
-some of your contributions are not listed. Please keep this list in
-alphabetical order.
-
- * Analog Devices helped implement the support for complex data types
- and iterators.
-
- * John David Anglin for threading-related fixes and improvements to
- libstdc++-v3, and the HP-UX port.
-
- * James van Artsdalen wrote the code that makes efficient use of the
- Intel 80387 register stack.
-
- * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta
- Series port.
-
- * Alasdair Baird for various bug fixes.
-
- * Giovanni Bajo for analyzing lots of complicated C++ problem
- reports.
-
- * Peter Barada for his work to improve code generation for new
- ColdFire cores.
-
- * Gerald Baumgartner added the signature extension to the C++ front
- end.
-
- * Godmar Back for his Java improvements and encouragement.
-
- * Scott Bambrough for help porting the Java compiler.
-
- * Wolfgang Bangerth for processing tons of bug reports.
-
- * Jon Beniston for his Microsoft Windows port of Java and port to
- Lattice Mico32.
-
- * Daniel Berlin for better DWARF2 support, faster/better
- optimizations, improved alias analysis, plus migrating GCC to
- Bugzilla.
-
- * Geoff Berry for his Java object serialization work and various
- patches.
-
- * Uros Bizjak for the implementation of x87 math built-in functions
- and for various middle end and i386 back end improvements and bug
- fixes.
-
- * Eric Blake for helping to make GCJ and libgcj conform to the
- specifications.
-
- * Janne Blomqvist for contributions to GNU Fortran.
-
- * Segher Boessenkool for various fixes.
-
- * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and
- other Java work.
-
- * Neil Booth for work on cpplib, lang hooks, debug hooks and other
- miscellaneous clean-ups.
-
- * Steven Bosscher for integrating the GNU Fortran front end into GCC
- and for contributing to the tree-ssa branch.
-
- * Eric Botcazou for fixing middle- and backend bugs left and right.
-
- * Per Bothner for his direction via the steering committee and
- various improvements to the infrastructure for supporting new
- languages. Chill front end implementation. Initial
- implementations of cpplib, fix-header, config.guess, libio, and
- past C++ library (libg++) maintainer. Dreaming up, designing and
- implementing much of GCJ.
-
- * Devon Bowen helped port GCC to the Tahoe.
-
- * Don Bowman for mips-vxworks contributions.
-
- * Dave Brolley for work on cpplib and Chill.
-
- * Paul Brook for work on the ARM architecture and maintaining GNU
- Fortran.
-
- * Robert Brown implemented the support for Encore 32000 systems.
-
- * Christian Bruel for improvements to local store elimination.
-
- * Herman A.J. ten Brugge for various fixes.
-
- * Joerg Brunsmann for Java compiler hacking and help with the GCJ
- FAQ.
-
- * Joe Buck for his direction via the steering committee.
-
- * Craig Burley for leadership of the G77 Fortran effort.
-
- * Stephan Buys for contributing Doxygen notes for libstdc++.
-
- * Paolo Carlini for libstdc++ work: lots of efficiency improvements
- to the C++ strings, streambufs and formatted I/O, hard detective
- work on the frustrating localization issues, and keeping up with
- the problem reports.
-
- * John Carr for his alias work, SPARC hacking, infrastructure
- improvements, previous contributions to the steering committee,
- loop optimizations, etc.
-
- * Stephane Carrez for 68HC11 and 68HC12 ports.
-
- * Steve Chamberlain for support for the Renesas SH and H8 processors
- and the PicoJava processor, and for GCJ config fixes.
-
- * Glenn Chambers for help with the GCJ FAQ.
-
- * John-Marc Chandonia for various libgcj patches.
-
- * Denis Chertykov for contributing and maintaining the AVR port, the
- first GCC port for an 8-bit architecture.
-
- * Scott Christley for his Objective-C contributions.
-
- * Eric Christopher for his Java porting help and clean-ups.
-
- * Branko Cibej for more warning contributions.
-
- * The GNU Classpath project for all of their merged runtime code.
-
- * Nick Clifton for arm, mcore, fr30, v850, m32r, rx work, `--help',
- and other random hacking.
-
- * Michael Cook for libstdc++ cleanup patches to reduce warnings.
-
- * R. Kelley Cook for making GCC buildable from a read-only directory
- as well as other miscellaneous build process and documentation
- clean-ups.
-
- * Ralf Corsepius for SH testing and minor bug fixing.
-
- * Stan Cox for care and feeding of the x86 port and lots of behind
- the scenes hacking.
-
- * Alex Crain provided changes for the 3b1.
-
- * Ian Dall for major improvements to the NS32k port.
-
- * Paul Dale for his work to add uClinux platform support to the m68k
- backend.
-
- * Dario Dariol contributed the four varieties of sample programs
- that print a copy of their source.
-
- * Russell Davidson for fstream and stringstream fixes in libstdc++.
-
- * Bud Davis for work on the G77 and GNU Fortran compilers.
-
- * Mo DeJong for GCJ and libgcj bug fixes.
-
- * DJ Delorie for the DJGPP port, build and libiberty maintenance,
- various bug fixes, and the M32C and MeP ports.
-
- * Arnaud Desitter for helping to debug GNU Fortran.
-
- * Gabriel Dos Reis for contributions to G++, contributions and
- maintenance of GCC diagnostics infrastructure, libstdc++-v3,
- including `valarray<>', `complex<>', maintaining the numerics
- library (including that pesky `<limits>' :-) and keeping
- up-to-date anything to do with numbers.
-
- * Ulrich Drepper for his work on glibc, testing of GCC using glibc,
- ISO C99 support, CFG dumping support, etc., plus support of the
- C++ runtime libraries including for all kinds of C interface
- issues, contributing and maintaining `complex<>', sanity checking
- and disbursement, configuration architecture, libio maintenance,
- and early math work.
-
- * Zdenek Dvorak for a new loop unroller and various fixes.
-
- * Michael Eager for his work on the Xilinx MicroBlaze port.
-
- * Richard Earnshaw for his ongoing work with the ARM.
-
- * David Edelsohn for his direction via the steering committee,
- ongoing work with the RS6000/PowerPC port, help cleaning up Haifa
- loop changes, doing the entire AIX port of libstdc++ with his bare
- hands, and for ensuring GCC properly keeps working on AIX.
-
- * Kevin Ediger for the floating point formatting of num_put::do_put
- in libstdc++.
-
- * Phil Edwards for libstdc++ work including configuration hackery,
- documentation maintainer, chief breaker of the web pages, the
- occasional iostream bug fix, and work on shared library symbol
- versioning.
-
- * Paul Eggert for random hacking all over GCC.
-
- * Mark Elbrecht for various DJGPP improvements, and for libstdc++
- configuration support for locales and fstream-related fixes.
-
- * Vadim Egorov for libstdc++ fixes in strings, streambufs, and
- iostreams.
-
- * Christian Ehrhardt for dealing with bug reports.
-
- * Ben Elliston for his work to move the Objective-C runtime into its
- own subdirectory and for his work on autoconf.
-
- * Revital Eres for work on the PowerPC 750CL port.
-
- * Marc Espie for OpenBSD support.
-
- * Doug Evans for much of the global optimization framework, arc,
- m32r, and SPARC work.
-
- * Christopher Faylor for his work on the Cygwin port and for caring
- and feeding the gcc.gnu.org box and saving its users tons of spam.
-
- * Fred Fish for BeOS support and Ada fixes.
-
- * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ.
-
- * Peter Gerwinski for various bug fixes and the Pascal front end.
-
- * Kaveh R. Ghazi for his direction via the steering committee,
- amazing work to make `-W -Wall -W* -Werror' useful, and
- continuously testing GCC on a plethora of platforms. Kaveh
- extends his gratitude to the CAIP Center at Rutgers University for
- providing him with computing resources to work on Free Software
- since the late 1980s.
-
- * John Gilmore for a donation to the FSF earmarked improving GNU
- Java.
-
- * Judy Goldberg for c++ contributions.
-
- * Torbjorn Granlund for various fixes and the c-torture testsuite,
- multiply- and divide-by-constant optimization, improved long long
- support, improved leaf function register allocation, and his
- direction via the steering committee.
-
- * Anthony Green for his `-Os' contributions, the moxie port, and
- Java front end work.
-
- * Stu Grossman for gdb hacking, allowing GCJ developers to debug
- Java code.
-
- * Michael K. Gschwind contributed the port to the PDP-11.
-
- * Richard Guenther for his ongoing middle-end contributions and bug
- fixes and for release management.
-
- * Ron Guilmette implemented the `protoize' and `unprotoize' tools,
- the support for Dwarf symbolic debugging information, and much of
- the support for System V Release 4. He has also worked heavily on
- the Intel 386 and 860 support.
-
- * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload
- GCSE.
-
- * Bruno Haible for improvements in the runtime overhead for EH, new
- warnings and assorted bug fixes.
-
- * Andrew Haley for his amazing Java compiler and library efforts.
-
- * Chris Hanson assisted in making GCC work on HP-UX for the 9000
- series 300.
-
- * Michael Hayes for various thankless work he's done trying to get
- the c30/c40 ports functional. Lots of loop and unroll
- improvements and fixes.
-
- * Dara Hazeghi for wading through myriads of target-specific bug
- reports.
-
- * Kate Hedstrom for staking the G77 folks with an initial testsuite.
-
- * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64
- work, loop opts, and generally fixing lots of old problems we've
- ignored for years, flow rewrite and lots of further stuff,
- including reviewing tons of patches.
-
- * Aldy Hernandez for working on the PowerPC port, SIMD support, and
- various fixes.
-
- * Nobuyuki Hikichi of Software Research Associates, Tokyo,
- contributed the support for the Sony NEWS machine.
-
- * Kazu Hirata for caring and feeding the Renesas H8/300 port and
- various fixes.
-
- * Katherine Holcomb for work on GNU Fortran.
-
- * Manfred Hollstein for his ongoing work to keep the m88k alive, lots
- of testing and bug fixing, particularly of GCC configury code.
-
- * Steve Holmgren for MachTen patches.
-
- * Jan Hubicka for his x86 port improvements.
-
- * Falk Hueffner for working on C and optimization bug reports.
-
- * Bernardo Innocenti for his m68k work, including merging of
- ColdFire improvements and uClinux support.
-
- * Christian Iseli for various bug fixes.
-
- * Kamil Iskra for general m68k hacking.
-
- * Lee Iverson for random fixes and MIPS testing.
-
- * Andreas Jaeger for testing and benchmarking of GCC and various bug
- fixes.
-
- * Jakub Jelinek for his SPARC work and sibling call optimizations as
- well as lots of bug fixes and test cases, and for improving the
- Java build system.
-
- * Janis Johnson for ia64 testing and fixes, her quality improvement
- sidetracks, and web page maintenance.
-
- * Kean Johnston for SCO OpenServer support and various fixes.
-
- * Tim Josling for the sample language treelang based originally on
- Richard Kenner's "toy" language.
-
- * Nicolai Josuttis for additional libstdc++ documentation.
-
- * Klaus Kaempf for his ongoing work to make alpha-vms a viable
- target.
-
- * Steven G. Kargl for work on GNU Fortran.
-
- * David Kashtan of SRI adapted GCC to VMS.
-
- * Ryszard Kabatek for many, many libstdc++ bug fixes and
- optimizations of strings, especially member functions, and for
- auto_ptr fixes.
-
- * Geoffrey Keating for his ongoing work to make the PPC work for
- GNU/Linux and his automatic regression tester.
-
- * Brendan Kehoe for his ongoing work with G++ and for a lot of early
- work in just about every part of libstdc++.
-
- * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
- MIL-STD-1750A.
-
- * Richard Kenner of the New York University Ultracomputer Research
- Laboratory wrote the machine descriptions for the AMD 29000, the
- DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the
- support for instruction attributes. He also made changes to
- better support RISC processors including changes to common
- subexpression elimination, strength reduction, function calling
- sequence handling, and condition code support, in addition to
- generalizing the code for frame pointer elimination and delay slot
- scheduling. Richard Kenner was also the head maintainer of GCC
- for several years.
-
- * Mumit Khan for various contributions to the Cygwin and Mingw32
- ports and maintaining binary releases for Microsoft Windows hosts,
- and for massive libstdc++ porting work to Cygwin/Mingw32.
-
- * Robin Kirkham for cpu32 support.
-
- * Mark Klein for PA improvements.
-
- * Thomas Koenig for various bug fixes.
-
- * Bruce Korb for the new and improved fixincludes code.
-
- * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3
- effort.
-
- * Charles LaBrec contributed the support for the Integrated Solutions
- 68020 system.
-
- * Asher Langton and Mike Kumbera for contributing Cray pointer
- support to GNU Fortran, and for other GNU Fortran improvements.
-
- * Jeff Law for his direction via the steering committee,
- coordinating the entire egcs project and GCC 2.95, rolling out
- snapshots and releases, handling merges from GCC2, reviewing tons
- of patches that might have fallen through the cracks else, and
- random but extensive hacking.
-
- * Marc Lehmann for his direction via the steering committee and
- helping with analysis and improvements of x86 performance.
-
- * Victor Leikehman for work on GNU Fortran.
-
- * Ted Lemon wrote parts of the RTL reader and printer.
-
- * Kriang Lerdsuwanakij for C++ improvements including template as
- template parameter support, and many C++ fixes.
-
- * Warren Levy for tremendous work on libgcj (Java Runtime Library)
- and random work on the Java front end.
-
- * Alain Lichnewsky ported GCC to the MIPS CPU.
-
- * Oskar Liljeblad for hacking on AWT and his many Java bug reports
- and patches.
-
- * Robert Lipe for OpenServer support, new testsuites, testing, etc.
-
- * Chen Liqin for various S+core related fixes/improvement, and for
- maintaining the S+core port.
-
- * Weiwen Liu for testing and various bug fixes.
-
- * Manuel Lo'pez-Iba'n~ez for improving `-Wconversion' and many other
- diagnostics fixes and improvements.
-
- * Dave Love for his ongoing work with the Fortran front end and
- runtime libraries.
-
- * Martin von Lo"wis for internal consistency checking infrastructure,
- various C++ improvements including namespace support, and tons of
- assistance with libstdc++/compiler merges.
-
- * H.J. Lu for his previous contributions to the steering committee,
- many x86 bug reports, prototype patches, and keeping the GNU/Linux
- ports working.
-
- * Greg McGary for random fixes and (someday) bounded pointers.
-
- * Andrew MacLeod for his ongoing work in building a real EH system,
- various code generation improvements, work on the global
- optimizer, etc.
-
- * Vladimir Makarov for hacking some ugly i960 problems, PowerPC
- hacking improvements to compile-time performance, overall
- knowledge and direction in the area of instruction scheduling, and
- design and implementation of the automaton based instruction
- scheduler.
-
- * Bob Manson for his behind the scenes work on dejagnu.
-
- * Philip Martin for lots of libstdc++ string and vector iterator
- fixes and improvements, and string clean up and testsuites.
-
- * All of the Mauve project contributors, for Java test code.
-
- * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements.
-
- * Adam Megacz for his work on the Microsoft Windows port of GCJ.
-
- * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS,
- powerpc, haifa, ECOFF debug support, and other assorted hacking.
-
- * Jason Merrill for his direction via the steering committee and
- leading the G++ effort.
-
- * Martin Michlmayr for testing GCC on several architectures using the
- entire Debian archive.
-
- * David Miller for his direction via the steering committee, lots of
- SPARC work, improvements in jump.c and interfacing with the Linux
- kernel developers.
-
- * Gary Miller ported GCC to Charles River Data Systems machines.
-
- * Alfred Minarik for libstdc++ string and ios bug fixes, and turning
- the entire libstdc++ testsuite namespace-compatible.
-
- * Mark Mitchell for his direction via the steering committee,
- mountains of C++ work, load/store hoisting out of loops, alias
- analysis improvements, ISO C `restrict' support, and serving as
- release manager for GCC 3.x.
-
- * Alan Modra for various GNU/Linux bits and testing.
-
- * Toon Moene for his direction via the steering committee, Fortran
- maintenance, and his ongoing work to make us make Fortran run fast.
-
- * Jason Molenda for major help in the care and feeding of all the
- services on the gcc.gnu.org (formerly egcs.cygnus.com)
- machine--mail, web services, ftp services, etc etc. Doing all
- this work on scrap paper and the backs of envelopes would have
- been... difficult.
-
- * Catherine Moore for fixing various ugly problems we have sent her
- way, including the haifa bug which was killing the Alpha & PowerPC
- Linux kernels.
-
- * Mike Moreton for his various Java patches.
-
- * David Mosberger-Tang for various Alpha improvements, and for the
- initial IA-64 port.
-
- * Stephen Moshier contributed the floating point emulator that
- assists in cross-compilation and permits support for floating
- point numbers wider than 64 bits and for ISO C99 support.
-
- * Bill Moyer for his behind the scenes work on various issues.
-
- * Philippe De Muyter for his work on the m68k port.
-
- * Joseph S. Myers for his work on the PDP-11 port, format checking
- and ISO C99 support, and continuous emphasis on (and contributions
- to) documentation.
-
- * Nathan Myers for his work on libstdc++-v3: architecture and
- authorship through the first three snapshots, including
- implementation of locale infrastructure, string, shadow C headers,
- and the initial project documentation (DESIGN, CHECKLIST, and so
- forth). Later, more work on MT-safe string and shadow headers.
-
- * Felix Natter for documentation on porting libstdc++.
-
- * Nathanael Nerode for cleaning up the configuration/build process.
-
- * NeXT, Inc. donated the front end that supports the Objective-C
- language.
-
- * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to
- the search engine setup, various documentation fixes and other
- small fixes.
-
- * Geoff Noer for his work on getting cygwin native builds working.
-
- * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance
- tracking web pages, GIMPLE tuples, and assorted fixes.
-
- * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64,
- FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and
- related infrastructure improvements.
-
- * Alexandre Oliva for various build infrastructure improvements,
- scripts and amazing testing work, including keeping libtool issues
- sane and happy.
-
- * Stefan Olsson for work on mt_alloc.
-
- * Melissa O'Neill for various NeXT fixes.
-
- * Rainer Orth for random MIPS work, including improvements to GCC's
- o32 ABI support, improvements to dejagnu's MIPS support, Java
- configuration clean-ups and porting work, and maintaining the
- IRIX, Solaris 2, and Tru64 UNIX ports.
-
- * Hartmut Penner for work on the s390 port.
-
- * Paul Petersen wrote the machine description for the Alliant FX/8.
-
- * Alexandre Petit-Bianco for implementing much of the Java compiler
- and continued Java maintainership.
-
- * Matthias Pfaller for major improvements to the NS32k port.
-
- * Gerald Pfeifer for his direction via the steering committee,
- pointing out lots of problems we need to solve, maintenance of the
- web pages, and taking care of documentation maintenance in general.
-
- * Andrew Pinski for processing bug reports by the dozen.
-
- * Ovidiu Predescu for his work on the Objective-C front end and
- runtime libraries.
-
- * Jerry Quinn for major performance improvements in C++ formatted
- I/O.
-
- * Ken Raeburn for various improvements to checker, MIPS ports and
- various cleanups in the compiler.
-
- * Rolf W. Rasmussen for hacking on AWT.
-
- * David Reese of Sun Microsystems contributed to the Solaris on
- PowerPC port.
-
- * Volker Reichelt for keeping up with the problem reports.
-
- * Joern Rennecke for maintaining the sh port, loop, regmove & reload
- hacking.
-
- * Loren J. Rittle for improvements to libstdc++-v3 including the
- FreeBSD port, threading fixes, thread-related configury changes,
- critical threading documentation, and solutions to really tricky
- I/O problems, as well as keeping GCC properly working on FreeBSD
- and continuous testing.
-
- * Craig Rodrigues for processing tons of bug reports.
-
- * Ola Ro"nnerup for work on mt_alloc.
-
- * Gavin Romig-Koch for lots of behind the scenes MIPS work.
-
- * David Ronis inspired and encouraged Craig to rewrite the G77
- documentation in texinfo format by contributing a first pass at a
- translation of the old `g77-0.5.16/f/DOC' file.
-
- * Ken Rose for fixes to GCC's delay slot filling code.
-
- * Paul Rubin wrote most of the preprocessor.
-
- * Pe'tur Runo'lfsson for major performance improvements in C++
- formatted I/O and large file support in C++ filebuf.
-
- * Chip Salzenberg for libstdc++ patches and improvements to locales,
- traits, Makefiles, libio, libtool hackery, and "long long" support.
-
- * Juha Sarlin for improvements to the H8 code generator.
-
- * Greg Satz assisted in making GCC work on HP-UX for the 9000 series
- 300.
-
- * Roger Sayle for improvements to constant folding and GCC's RTL
- optimizers as well as for fixing numerous bugs.
-
- * Bradley Schatz for his work on the GCJ FAQ.
-
- * Peter Schauer wrote the code to allow debugging to work on the
- Alpha.
-
- * William Schelter did most of the work on the Intel 80386 support.
-
- * Tobias Schlu"ter for work on GNU Fortran.
-
- * Bernd Schmidt for various code generation improvements and major
- work in the reload pass as well a serving as release manager for
- GCC 2.95.3.
-
- * Peter Schmid for constant testing of libstdc++--especially
- application testing, going above and beyond what was requested for
- the release criteria--and libstdc++ header file tweaks.
-
- * Jason Schroeder for jcf-dump patches.
-
- * Andreas Schwab for his work on the m68k port.
-
- * Lars Segerlund for work on GNU Fortran.
-
- * Dodji Seketeli for numerous C++ bug fixes and debug info
- improvements.
-
- * Joel Sherrill for his direction via the steering committee, RTEMS
- contributions and RTEMS testing.
-
- * Nathan Sidwell for many C++ fixes/improvements.
-
- * Jeffrey Siegal for helping RMS with the original design of GCC,
- some code which handles the parse tree and RTL data structures,
- constant folding and help with the original VAX & m68k ports.
-
- * Kenny Simpson for prompting libstdc++ fixes due to defect reports
- from the LWG (thereby keeping GCC in line with updates from the
- ISO).
-
- * Franz Sirl for his ongoing work with making the PPC port stable
- for GNU/Linux.
-
- * Andrey Slepuhin for assorted AIX hacking.
-
- * Trevor Smigiel for contributing the SPU port.
-
- * Christopher Smith did the port for Convex machines.
-
- * Danny Smith for his major efforts on the Mingw (and Cygwin) ports.
-
- * Randy Smith finished the Sun FPA support.
-
- * Scott Snyder for queue, iterator, istream, and string fixes and
- libstdc++ testsuite entries. Also for providing the patch to G77
- to add rudimentary support for `INTEGER*1', `INTEGER*2', and
- `LOGICAL*1'.
-
- * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
-
- * Richard Stallman, for writing the original GCC and launching the
- GNU project.
-
- * Jan Stein of the Chalmers Computer Society provided support for
- Genix, as well as part of the 32000 machine description.
-
- * Nigel Stephens for various mips16 related fixes/improvements.
-
- * Jonathan Stone wrote the machine description for the Pyramid
- computer.
-
- * Graham Stott for various infrastructure improvements.
-
- * John Stracke for his Java HTTP protocol fixes.
-
- * Mike Stump for his Elxsi port, G++ contributions over the years
- and more recently his vxworks contributions
-
- * Jeff Sturm for Java porting help, bug fixes, and encouragement.
-
- * Shigeya Suzuki for this fixes for the bsdi platforms.
-
- * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64
- support, general configury hacking, fixincludes, etc.
-
- * Holger Teutsch provided the support for the Clipper CPU.
-
- * Gary Thomas for his ongoing work to make the PPC work for
- GNU/Linux.
-
- * Philipp Thomas for random bug fixes throughout the compiler
-
- * Jason Thorpe for thread support in libstdc++ on NetBSD.
-
- * Kresten Krab Thorup wrote the run time support for the Objective-C
- language and the fantastic Java bytecode interpreter.
-
- * Michael Tiemann for random bug fixes, the first instruction
- scheduler, initial C++ support, function integration, NS32k, SPARC
- and M88k machine description work, delay slot scheduling.
-
- * Andreas Tobler for his work porting libgcj to Darwin.
-
- * Teemu Torma for thread safe exception handling support.
-
- * Leonard Tower wrote parts of the parser, RTL generator, and RTL
- definitions, and of the VAX machine description.
-
- * Daniel Towner and Hariharan Sandanagobalane contributed and
- maintain the picoChip port.
-
- * Tom Tromey for internationalization support and for his many Java
- contributions and libgcj maintainership.
-
- * Lassi Tuura for improvements to config.guess to determine HP
- processor types.
-
- * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes.
-
- * Andy Vaught for the design and initial implementation of the GNU
- Fortran front end.
-
- * Brent Verner for work with the libstdc++ cshadow files and their
- associated configure steps.
-
- * Todd Vierling for contributions for NetBSD ports.
-
- * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
- guidance.
-
- * Dean Wakerley for converting the install documentation from HTML
- to texinfo in time for GCC 3.0.
-
- * Krister Walfridsson for random bug fixes.
-
- * Feng Wang for contributions to GNU Fortran.
-
- * Stephen M. Webb for time and effort on making libstdc++ shadow
- files work with the tricky Solaris 8+ headers, and for pushing the
- build-time header tree.
-
- * John Wehle for various improvements for the x86 code generator,
- related infrastructure improvements to help x86 code generation,
- value range propagation and other work, WE32k port.
-
- * Ulrich Weigand for work on the s390 port.
-
- * Zack Weinberg for major work on cpplib and various other bug fixes.
-
- * Matt Welsh for help with Linux Threads support in GCJ.
-
- * Urban Widmark for help fixing java.io.
-
- * Mark Wielaard for new Java library code and his work integrating
- with Classpath.
-
- * Dale Wiles helped port GCC to the Tahoe.
-
- * Bob Wilson from Tensilica, Inc. for the Xtensa port.
-
- * Jim Wilson for his direction via the steering committee, tackling
- hard problems in various places that nobody else wanted to work
- on, strength reduction and other loop optimizations.
-
- * Paul Woegerer and Tal Agmon for the CRX port.
-
- * Carlo Wood for various fixes.
-
- * Tom Wood for work on the m88k port.
-
- * Canqun Yang for work on GNU Fortran.
-
- * Masanobu Yuhara of Fujitsu Laboratories implemented the machine
- description for the Tron architecture (specifically, the Gmicro).
-
- * Kevin Zachmann helped port GCC to the Tahoe.
-
- * Ayal Zaks for Swing Modulo Scheduling (SMS).
-
- * Xiaoqiang Zhang for work on GNU Fortran.
-
- * Gilles Zunino for help porting Java to Irix.
-
-
- The following people are recognized for their contributions to GNAT,
-the Ada front end of GCC:
- * Bernard Banner
-
- * Romain Berrendonner
-
- * Geert Bosch
-
- * Emmanuel Briot
-
- * Joel Brobecker
-
- * Ben Brosgol
-
- * Vincent Celier
-
- * Arnaud Charlet
-
- * Chien Chieng
-
- * Cyrille Comar
-
- * Cyrille Crozes
-
- * Robert Dewar
-
- * Gary Dismukes
-
- * Robert Duff
-
- * Ed Falis
-
- * Ramon Fernandez
-
- * Sam Figueroa
-
- * Vasiliy Fofanov
-
- * Michael Friess
-
- * Franco Gasperoni
-
- * Ted Giering
-
- * Matthew Gingell
-
- * Laurent Guerby
-
- * Jerome Guitton
-
- * Olivier Hainque
-
- * Jerome Hugues
-
- * Hristian Kirtchev
-
- * Jerome Lambourg
-
- * Bruno Leclerc
-
- * Albert Lee
-
- * Sean McNeil
-
- * Javier Miranda
-
- * Laurent Nana
-
- * Pascal Obry
-
- * Dong-Ik Oh
-
- * Laurent Pautet
-
- * Brett Porter
-
- * Thomas Quinot
-
- * Nicolas Roche
-
- * Pat Rogers
-
- * Jose Ruiz
-
- * Douglas Rupp
-
- * Sergey Rybin
-
- * Gail Schenker
-
- * Ed Schonberg
-
- * Nicolas Setton
-
- * Samuel Tardieu
-
-
- The following people are recognized for their contributions of new
-features, bug reports, testing and integration of classpath/libgcj for
-GCC version 4.1:
- * Lillian Angel for `JTree' implementation and lots Free Swing
- additions and bug fixes.
-
- * Wolfgang Baer for `GapContent' bug fixes.
-
- * Anthony Balkissoon for `JList', Free Swing 1.5 updates and mouse
- event fixes, lots of Free Swing work including `JTable' editing.
-
- * Stuart Ballard for RMI constant fixes.
-
- * Goffredo Baroncelli for `HTTPURLConnection' fixes.
-
- * Gary Benson for `MessageFormat' fixes.
-
- * Daniel Bonniot for `Serialization' fixes.
-
- * Chris Burdess for lots of gnu.xml and http protocol fixes, `StAX'
- and `DOM xml:id' support.
-
- * Ka-Hing Cheung for `TreePath' and `TreeSelection' fixes.
-
- * Archie Cobbs for build fixes, VM interface updates,
- `URLClassLoader' updates.
-
- * Kelley Cook for build fixes.
-
- * Martin Cordova for Suggestions for better `SocketTimeoutException'.
-
- * David Daney for `BitSet' bug fixes, `HttpURLConnection' rewrite
- and improvements.
-
- * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo
- 2D support. Lots of imageio framework additions, lots of AWT and
- Free Swing bug fixes.
-
- * Jeroen Frijters for `ClassLoader' and nio cleanups, serialization
- fixes, better `Proxy' support, bug fixes and IKVM integration.
-
- * Santiago Gala for `AccessControlContext' fixes.
-
- * Nicolas Geoffray for `VMClassLoader' and `AccessController'
- improvements.
-
- * David Gilbert for `basic' and `metal' icon and plaf support and
- lots of documenting, Lots of Free Swing and metal theme additions.
- `MetalIconFactory' implementation.
-
- * Anthony Green for `MIDI' framework, `ALSA' and `DSSI' providers.
-
- * Andrew Haley for `Serialization' and `URLClassLoader' fixes, gcj
- build speedups.
-
- * Kim Ho for `JFileChooser' implementation.
-
- * Andrew John Hughes for `Locale' and net fixes, URI RFC2986
- updates, `Serialization' fixes, `Properties' XML support and
- generic branch work, VMIntegration guide update.
-
- * Bastiaan Huisman for `TimeZone' bug fixing.
-
- * Andreas Jaeger for mprec updates.
-
- * Paul Jenner for better `-Werror' support.
-
- * Ito Kazumitsu for `NetworkInterface' implementation and updates.
-
- * Roman Kennke for `BoxLayout', `GrayFilter' and `SplitPane', plus
- bug fixes all over. Lots of Free Swing work including styled text.
-
- * Simon Kitching for `String' cleanups and optimization suggestions.
-
- * Michael Koch for configuration fixes, `Locale' updates, bug and
- build fixes.
-
- * Guilhem Lavaux for configuration, thread and channel fixes and
- Kaffe integration. JCL native `Pointer' updates. Logger bug fixes.
-
- * David Lichteblau for JCL support library global/local reference
- cleanups.
-
- * Aaron Luchko for JDWP updates and documentation fixes.
-
- * Ziga Mahkovec for `Graphics2D' upgraded to Cairo 0.5 and new regex
- features.
-
- * Sven de Marothy for BMP imageio support, CSS and `TextLayout'
- fixes. `GtkImage' rewrite, 2D, awt, free swing and date/time fixes
- and implementing the Qt4 peers.
-
- * Casey Marshall for crypto algorithm fixes, `FileChannel' lock,
- `SystemLogger' and `FileHandler' rotate implementations, NIO
- `FileChannel.map' support, security and policy updates.
-
- * Bryce McKinlay for RMI work.
-
- * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus
- testing and documenting.
-
- * Kalle Olavi Niemitalo for build fixes.
-
- * Rainer Orth for build fixes.
-
- * Andrew Overholt for `File' locking fixes.
-
- * Ingo Proetel for `Image', `Logger' and `URLClassLoader' updates.
-
- * Olga Rodimina for `MenuSelectionManager' implementation.
-
- * Jan Roehrich for `BasicTreeUI' and `JTree' fixes.
-
- * Julian Scheid for documentation updates and gjdoc support.
-
- * Christian Schlichtherle for zip fixes and cleanups.
-
- * Robert Schuster for documentation updates and beans fixes,
- `TreeNode' enumerations and `ActionCommand' and various fixes, XML
- and URL, AWT and Free Swing bug fixes.
-
- * Keith Seitz for lots of JDWP work.
-
- * Christian Thalinger for 64-bit cleanups, Configuration and VM
- interface fixes and `CACAO' integration, `fdlibm' updates.
-
- * Gael Thomas for `VMClassLoader' boot packages support suggestions.
-
- * Andreas Tobler for Darwin and Solaris testing and fixing, `Qt4'
- support for Darwin/OS X, `Graphics2D' support, `gtk+' updates.
-
- * Dalibor Topic for better `DEBUG' support, build cleanups and Kaffe
- integration. `Qt4' build infrastructure, `SHA1PRNG' and
- `GdkPixbugDecoder' updates.
-
- * Tom Tromey for Eclipse integration, generics work, lots of bug
- fixes and gcj integration including coordinating The Big Merge.
-
- * Mark Wielaard for bug fixes, packaging and release management,
- `Clipboard' implementation, system call interrupts and network
- timeouts and `GdkPixpufDecoder' fixes.
-
-
- In addition to the above, all of which also contributed time and
-energy in testing GCC, we would like to thank the following for their
-contributions to testing:
-
- * Michael Abd-El-Malek
-
- * Thomas Arend
-
- * Bonzo Armstrong
-
- * Steven Ashe
-
- * Chris Baldwin
-
- * David Billinghurst
-
- * Jim Blandy
-
- * Stephane Bortzmeyer
-
- * Horst von Brand
-
- * Frank Braun
-
- * Rodney Brown
-
- * Sidney Cadot
-
- * Bradford Castalia
-
- * Robert Clark
-
- * Jonathan Corbet
-
- * Ralph Doncaster
-
- * Richard Emberson
-
- * Levente Farkas
-
- * Graham Fawcett
-
- * Mark Fernyhough
-
- * Robert A. French
-
- * Jo"rgen Freyh
-
- * Mark K. Gardner
-
- * Charles-Antoine Gauthier
-
- * Yung Shing Gene
-
- * David Gilbert
-
- * Simon Gornall
-
- * Fred Gray
-
- * John Griffin
-
- * Patrik Hagglund
-
- * Phil Hargett
-
- * Amancio Hasty
-
- * Takafumi Hayashi
-
- * Bryan W. Headley
-
- * Kevin B. Hendricks
-
- * Joep Jansen
-
- * Christian Joensson
-
- * Michel Kern
-
- * David Kidd
-
- * Tobias Kuipers
-
- * Anand Krishnaswamy
-
- * A. O. V. Le Blanc
-
- * llewelly
-
- * Damon Love
-
- * Brad Lucier
-
- * Matthias Klose
-
- * Martin Knoblauch
-
- * Rick Lutowski
-
- * Jesse Macnish
-
- * Stefan Morrell
-
- * Anon A. Mous
-
- * Matthias Mueller
-
- * Pekka Nikander
-
- * Rick Niles
-
- * Jon Olson
-
- * Magnus Persson
-
- * Chris Pollard
-
- * Richard Polton
-
- * Derk Reefman
-
- * David Rees
-
- * Paul Reilly
-
- * Tom Reilly
-
- * Torsten Rueger
-
- * Danny Sadinoff
-
- * Marc Schifer
-
- * Erik Schnetter
-
- * Wayne K. Schroll
-
- * David Schuler
-
- * Vin Shelton
-
- * Tim Souder
-
- * Adam Sulmicki
-
- * Bill Thorson
-
- * George Talbot
-
- * Pedro A. M. Vazquez
-
- * Gregory Warnes
-
- * Ian Watson
-
- * David E. Young
-
- * And many others
-
- And finally we'd like to thank everyone who uses the compiler, provides
-feedback and generally reminds us why we're doing this work in the first
-place.
-
-
-File: gcc.info, Node: Option Index, Next: Keyword Index, Prev: Contributors, Up: Top
-
-Option Index
-************
-
-GCC's command line options are indexed here without any initial `-' or
-`--'. Where an option has both positive and negative forms (such as
-`-fOPTION' and `-fno-OPTION'), relevant entries in the manual are
-indexed under the most appropriate form; it may sometimes be useful to
-look up both forms.
-
-
-* Menu:
-
-* ###: Overall Options. (line 209)
-* -fno-keep-inline-dllexport: Optimize Options. (line 305)
-* -fprofile-generate-sampling: Optimize Options. (line 1773)
-* -mcpu: RX Options. (line 30)
-* -Wno-thread-attr-bind-param: Warning Options. (line 606)
-* -Wno-thread-mismatched-lock-acq-rel: Warning Options. (line 594)
-* -Wno-thread-mismatched-lock-order: Warning Options. (line 589)
-* -Wno-thread-reentrant-lock: Warning Options. (line 598)
-* -Wno-thread-unguarded-func: Warning Options. (line 584)
-* -Wno-thread-unguarded-var: Warning Options. (line 579)
-* -Wno-thread-unsupported-lock-name: Warning Options. (line 602)
-* -Wthread-attr-bind-param: Warning Options. (line 606)
-* -Wthread-mismatched-lock-acq-rel: Warning Options. (line 594)
-* -Wthread-mismatched-lock-order: Warning Options. (line 589)
-* -Wthread-reentrant-lock: Warning Options. (line 598)
-* -Wthread-unguarded-func: Warning Options. (line 584)
-* -Wthread-unguarded-var: Warning Options. (line 579)
-* -Wthread-unsupported-lock-name: Warning Options. (line 602)
-* 8bit-idiv: i386 and x86-64 Options.
- (line 680)
-* A: Preprocessor Options.
- (line 551)
-* all_load: Darwin Options. (line 112)
-* allowable_client: Darwin Options. (line 199)
-* ansi <1>: Non-bugs. (line 107)
-* ansi <2>: Other Builtins. (line 22)
-* ansi <3>: C Dialect Options. (line 11)
-* ansi <4>: Standards. (line 16)
-* ansi: Preprocessor Options.
- (line 326)
-* arch_errors_fatal: Darwin Options. (line 116)
-* aux-info: C Dialect Options. (line 154)
-* avx256-split-unaligned-load: i386 and x86-64 Options.
- (line 689)
-* avx256-split-unaligned-store: i386 and x86-64 Options.
- (line 689)
-* B: Directory Options. (line 46)
-* Bdynamic: VxWorks Options. (line 22)
-* bind_at_load: Darwin Options. (line 120)
-* Bstatic: VxWorks Options. (line 22)
-* bundle: Darwin Options. (line 125)
-* bundle_loader: Darwin Options. (line 129)
-* c <1>: Link Options. (line 20)
-* c: Overall Options. (line 164)
-* C: Preprocessor Options.
- (line 609)
-* canonical-prefixes: Overall Options. (line 338)
-* client_name: Darwin Options. (line 199)
-* compatibility_version: Darwin Options. (line 199)
-* coverage: Debugging Options. (line 371)
-* current_version: Darwin Options. (line 199)
-* D: Preprocessor Options.
- (line 34)
-* d: Debugging Options. (line 497)
-* dA: Debugging Options. (line 704)
-* dD <1>: Preprocessor Options.
- (line 583)
-* dD: Debugging Options. (line 708)
-* dead_strip: Darwin Options. (line 199)
-* dependency-file: Darwin Options. (line 199)
-* dH: Debugging Options. (line 712)
-* dI: Preprocessor Options.
- (line 592)
-* dm: Debugging Options. (line 715)
-* dM: Preprocessor Options.
- (line 567)
-* dN: Preprocessor Options.
- (line 589)
-* dp: Debugging Options. (line 719)
-* dP: Debugging Options. (line 724)
-* dU: Preprocessor Options.
- (line 596)
-* dumpmachine: Debugging Options. (line 1203)
-* dumpspecs: Debugging Options. (line 1211)
-* dumpversion: Debugging Options. (line 1207)
-* dv: Debugging Options. (line 728)
-* dx: Debugging Options. (line 733)
-* dylib_file: Darwin Options. (line 199)
-* dylinker_install_name: Darwin Options. (line 199)
-* dynamic: Darwin Options. (line 199)
-* dynamiclib: Darwin Options. (line 133)
-* E <1>: Link Options. (line 20)
-* E: Overall Options. (line 185)
-* EB <1>: MIPS Options. (line 7)
-* EB: ARC Options. (line 12)
-* EL <1>: ARC Options. (line 9)
-* EL: MIPS Options. (line 10)
-* exported_symbols_list: Darwin Options. (line 199)
-* F: Darwin Options. (line 32)
-* fabi-version: C++ Dialect Options.
- (line 20)
-* falign-functions: Optimize Options. (line 1394)
-* falign-jumps: Optimize Options. (line 1444)
-* falign-labels: Optimize Options. (line 1412)
-* falign-loops: Optimize Options. (line 1430)
-* fassociative-math: Optimize Options. (line 1965)
-* fasynchronous-unwind-tables: Code Gen Options. (line 64)
-* fauto-inc-dec: Optimize Options. (line 510)
-* fbounds-check: Code Gen Options. (line 15)
-* fbranch-probabilities: Optimize Options. (line 2098)
-* fbranch-target-load-optimize: Optimize Options. (line 2209)
-* fbranch-target-load-optimize2: Optimize Options. (line 2215)
-* fbtr-bb-exclusive: Optimize Options. (line 2219)
-* fcall-saved: Code Gen Options. (line 262)
-* fcall-used: Code Gen Options. (line 248)
-* fcaller-saves: Optimize Options. (line 779)
-* fcallgraph-profiles-sections: Optimize Options. (line 1863)
-* fcheck-data-deps: Optimize Options. (line 1052)
-* fcheck-new: C++ Dialect Options.
- (line 45)
-* fcombine-stack-adjustments: Optimize Options. (line 792)
-* fcommon: Variable Attributes.
- (line 105)
-* fcompare-debug: Debugging Options. (line 160)
-* fcompare-debug-second: Debugging Options. (line 186)
-* fcompare-elim: Optimize Options. (line 1714)
-* fcond-mismatch: C Dialect Options. (line 290)
-* fconserve-space: C++ Dialect Options.
- (line 55)
-* fconserve-stack: Optimize Options. (line 798)
-* fconstant-string-class: Objective-C and Objective-C++ Dialect Options.
- (line 30)
-* fconstexpr-depth: C++ Dialect Options.
- (line 67)
-* fcprop-registers: Optimize Options. (line 1736)
-* fcrossjumping: Optimize Options. (line 503)
-* fcse-follow-jumps: Optimize Options. (line 431)
-* fcse-skip-blocks: Optimize Options. (line 440)
-* fcx-fortran-rules: Optimize Options. (line 2079)
-* fcx-limited-range: Optimize Options. (line 2067)
-* fdata-sections: Optimize Options. (line 2190)
-* fdbg-cnt: Debugging Options. (line 424)
-* fdbg-cnt-list: Debugging Options. (line 421)
-* fdce: Optimize Options. (line 516)
-* fdebug-prefix-map: Debugging Options. (line 287)
-* fdelayed-branch: Optimize Options. (line 628)
-* fdelete-null-pointer-checks: Optimize Options. (line 539)
-* fdevirtualize: Optimize Options. (line 557)
-* fdiagnostics-show-location: Language Independent Options.
- (line 21)
-* fdiagnostics-show-option: Language Independent Options.
- (line 36)
-* fdirectives-only: Preprocessor Options.
- (line 459)
-* fdisable-: Debugging Options. (line 434)
-* fdollars-in-identifiers <1>: Interoperation. (line 146)
-* fdollars-in-identifiers: Preprocessor Options.
- (line 481)
-* fdse: Optimize Options. (line 520)
-* fdump-class-hierarchy: Debugging Options. (line 764)
-* fdump-final-insns: Debugging Options. (line 154)
-* fdump-ipa: Debugging Options. (line 772)
-* fdump-noaddr: Debugging Options. (line 737)
-* fdump-passes: Debugging Options. (line 790)
-* fdump-rtl-alignments: Debugging Options. (line 516)
-* fdump-rtl-all: Debugging Options. (line 701)
-* fdump-rtl-asmcons: Debugging Options. (line 519)
-* fdump-rtl-auto_inc_dec: Debugging Options. (line 523)
-* fdump-rtl-barriers: Debugging Options. (line 527)
-* fdump-rtl-bbpart: Debugging Options. (line 530)
-* fdump-rtl-bbro: Debugging Options. (line 533)
-* fdump-rtl-btl2: Debugging Options. (line 537)
-* fdump-rtl-bypass: Debugging Options. (line 541)
-* fdump-rtl-ce1: Debugging Options. (line 552)
-* fdump-rtl-ce2: Debugging Options. (line 552)
-* fdump-rtl-ce3: Debugging Options. (line 552)
-* fdump-rtl-combine: Debugging Options. (line 544)
-* fdump-rtl-compgotos: Debugging Options. (line 547)
-* fdump-rtl-cprop_hardreg: Debugging Options. (line 556)
-* fdump-rtl-csa: Debugging Options. (line 559)
-* fdump-rtl-cse1: Debugging Options. (line 563)
-* fdump-rtl-cse2: Debugging Options. (line 563)
-* fdump-rtl-dbr: Debugging Options. (line 570)
-* fdump-rtl-dce: Debugging Options. (line 567)
-* fdump-rtl-dce1: Debugging Options. (line 574)
-* fdump-rtl-dce2: Debugging Options. (line 574)
-* fdump-rtl-dfinish: Debugging Options. (line 698)
-* fdump-rtl-dfinit: Debugging Options. (line 698)
-* fdump-rtl-eh: Debugging Options. (line 578)
-* fdump-rtl-eh_ranges: Debugging Options. (line 581)
-* fdump-rtl-expand: Debugging Options. (line 584)
-* fdump-rtl-fwprop1: Debugging Options. (line 588)
-* fdump-rtl-fwprop2: Debugging Options. (line 588)
-* fdump-rtl-gcse1: Debugging Options. (line 593)
-* fdump-rtl-gcse2: Debugging Options. (line 593)
-* fdump-rtl-init-regs: Debugging Options. (line 597)
-* fdump-rtl-initvals: Debugging Options. (line 600)
-* fdump-rtl-into_cfglayout: Debugging Options. (line 603)
-* fdump-rtl-ira: Debugging Options. (line 606)
-* fdump-rtl-jump: Debugging Options. (line 609)
-* fdump-rtl-loop2: Debugging Options. (line 612)
-* fdump-rtl-mach: Debugging Options. (line 616)
-* fdump-rtl-mode_sw: Debugging Options. (line 620)
-* fdump-rtl-outof_cfglayout: Debugging Options. (line 626)
-* fdump-rtl-peephole2: Debugging Options. (line 629)
-* fdump-rtl-postreload: Debugging Options. (line 632)
-* fdump-rtl-pro_and_epilogue: Debugging Options. (line 635)
-* fdump-rtl-regclass: Debugging Options. (line 698)
-* fdump-rtl-regmove: Debugging Options. (line 638)
-* fdump-rtl-rnreg: Debugging Options. (line 623)
-* fdump-rtl-sched1: Debugging Options. (line 642)
-* fdump-rtl-sched2: Debugging Options. (line 642)
-* fdump-rtl-see: Debugging Options. (line 646)
-* fdump-rtl-seqabstr: Debugging Options. (line 649)
-* fdump-rtl-shorten: Debugging Options. (line 652)
-* fdump-rtl-sibling: Debugging Options. (line 655)
-* fdump-rtl-sms: Debugging Options. (line 668)
-* fdump-rtl-split1: Debugging Options. (line 662)
-* fdump-rtl-split2: Debugging Options. (line 662)
-* fdump-rtl-split3: Debugging Options. (line 662)
-* fdump-rtl-split4: Debugging Options. (line 662)
-* fdump-rtl-split5: Debugging Options. (line 662)
-* fdump-rtl-stack: Debugging Options. (line 672)
-* fdump-rtl-subreg1: Debugging Options. (line 678)
-* fdump-rtl-subreg2: Debugging Options. (line 678)
-* fdump-rtl-subregs_of_mode_finish: Debugging Options. (line 698)
-* fdump-rtl-subregs_of_mode_init: Debugging Options. (line 698)
-* fdump-rtl-unshare: Debugging Options. (line 682)
-* fdump-rtl-vartrack: Debugging Options. (line 685)
-* fdump-rtl-vregs: Debugging Options. (line 688)
-* fdump-rtl-web: Debugging Options. (line 691)
-* fdump-statistics: Debugging Options. (line 794)
-* fdump-translation-unit: Debugging Options. (line 755)
-* fdump-tree: Debugging Options. (line 805)
-* fdump-tree-alias: Debugging Options. (line 899)
-* fdump-tree-all: Debugging Options. (line 989)
-* fdump-tree-ccp: Debugging Options. (line 903)
-* fdump-tree-cfg: Debugging Options. (line 879)
-* fdump-tree-ch: Debugging Options. (line 891)
-* fdump-tree-copyprop: Debugging Options. (line 919)
-* fdump-tree-copyrename: Debugging Options. (line 965)
-* fdump-tree-dce: Debugging Options. (line 927)
-* fdump-tree-dom: Debugging Options. (line 945)
-* fdump-tree-dse: Debugging Options. (line 950)
-* fdump-tree-forwprop: Debugging Options. (line 960)
-* fdump-tree-fre: Debugging Options. (line 915)
-* fdump-tree-gimple: Debugging Options. (line 874)
-* fdump-tree-mudflap: Debugging Options. (line 931)
-* fdump-tree-nrv: Debugging Options. (line 970)
-* fdump-tree-optimized: Debugging Options. (line 871)
-* fdump-tree-original: Debugging Options. (line 868)
-* fdump-tree-phiopt: Debugging Options. (line 955)
-* fdump-tree-pre: Debugging Options. (line 911)
-* fdump-tree-sink: Debugging Options. (line 941)
-* fdump-tree-slp: Debugging Options. (line 980)
-* fdump-tree-sra: Debugging Options. (line 936)
-* fdump-tree-ssa: Debugging Options. (line 895)
-* fdump-tree-store_copyprop: Debugging Options. (line 923)
-* fdump-tree-storeccp: Debugging Options. (line 907)
-* fdump-tree-vcg: Debugging Options. (line 883)
-* fdump-tree-vect: Debugging Options. (line 975)
-* fdump-tree-vrp: Debugging Options. (line 985)
-* fdump-unnumbered: Debugging Options. (line 743)
-* fdump-unnumbered-links: Debugging Options. (line 749)
-* fdwarf2-cfi-asm: Debugging Options. (line 291)
-* fearly-inlining: Optimize Options. (line 262)
-* feliminate-dwarf2-dups: Debugging Options. (line 199)
-* feliminate-unused-debug-symbols: Debugging Options. (line 52)
-* feliminate-unused-debug-types: Debugging Options. (line 1215)
-* fenable-: Debugging Options. (line 434)
-* fenable-icf-debug: Debugging Options. (line 274)
-* fexceptions: Code Gen Options. (line 34)
-* fexcess-precision: Optimize Options. (line 1893)
-* fexec-charset: Preprocessor Options.
- (line 508)
-* fexpensive-optimizations: Optimize Options. (line 564)
-* fextended-identifiers: Preprocessor Options.
- (line 484)
-* ffast-math: Optimize Options. (line 1916)
-* ffinite-math-only: Optimize Options. (line 1991)
-* ffix-and-continue: Darwin Options. (line 106)
-* ffixed: Code Gen Options. (line 236)
-* ffloat-store <1>: Optimize Options. (line 1879)
-* ffloat-store: Disappointments. (line 77)
-* ffor-scope: C++ Dialect Options.
- (line 121)
-* fforward-propagate: Optimize Options. (line 174)
-* ffp-contract: Optimize Options. (line 183)
-* ffreestanding <1>: C Dialect Options. (line 225)
-* ffreestanding <2>: Warning Options. (line 240)
-* ffreestanding <3>: Function Attributes.
- (line 459)
-* ffreestanding: Standards. (line 88)
-* ffriend-injection: C++ Dialect Options.
- (line 91)
-* ffunction-sections: Optimize Options. (line 2190)
-* fgcse: Optimize Options. (line 454)
-* fgcse-after-reload: Optimize Options. (line 490)
-* fgcse-las: Optimize Options. (line 483)
-* fgcse-lm: Optimize Options. (line 465)
-* fgcse-sm: Optimize Options. (line 474)
-* fgnu-runtime: Objective-C and Objective-C++ Dialect Options.
- (line 39)
-* fgnu89-inline: C Dialect Options. (line 133)
-* fgraphite-identity: Optimize Options. (line 1033)
-* fhosted: C Dialect Options. (line 218)
-* fif-conversion: Optimize Options. (line 524)
-* fif-conversion2: Optimize Options. (line 533)
-* filelist: Darwin Options. (line 199)
-* findirect-data: Darwin Options. (line 106)
-* findirect-inlining: Optimize Options. (line 235)
-* finhibit-size-directive: Code Gen Options. (line 158)
-* finline-functions: Optimize Options. (line 243)
-* finline-functions-called-once: Optimize Options. (line 254)
-* finline-limit: Optimize Options. (line 279)
-* finline-small-functions: Optimize Options. (line 227)
-* finput-charset: Preprocessor Options.
- (line 521)
-* finstrument-functions <1>: Code Gen Options. (line 292)
-* finstrument-functions: Function Attributes.
- (line 899)
-* finstrument-functions-exclude-file-list: Code Gen Options. (line 329)
-* finstrument-functions-exclude-function-list: Code Gen Options.
- (line 349)
-* fipa-cp: Optimize Options. (line 868)
-* fipa-cp-clone: Optimize Options. (line 876)
-* fipa-matrix-reorg: Optimize Options. (line 886)
-* fipa-profile: Optimize Options. (line 860)
-* fipa-pta: Optimize Options. (line 854)
-* fipa-pure-const: Optimize Options. (line 832)
-* fipa-reference: Optimize Options. (line 836)
-* fipa-sra: Optimize Options. (line 272)
-* fipa-struct-reorg: Optimize Options. (line 840)
-* fira-loop-pressure: Optimize Options. (line 603)
-* fira-verbose: Optimize Options. (line 623)
-* fivopts: Optimize Options. (line 1128)
-* fkeep-inline-functions <1>: Inline. (line 51)
-* fkeep-inline-functions: Optimize Options. (line 311)
-* fkeep-static-consts: Optimize Options. (line 318)
-* flat_namespace: Darwin Options. (line 199)
-* flax-vector-conversions: C Dialect Options. (line 295)
-* fleading-underscore: Code Gen Options. (line 432)
-* floop-block: Optimize Options. (line 1004)
-* floop-flatten: Optimize Options. (line 1041)
-* floop-interchange: Optimize Options. (line 957)
-* floop-parallelize-all: Optimize Options. (line 1046)
-* floop-strip-mine: Optimize Options. (line 982)
-* flto: Optimize Options. (line 1508)
-* flto-partition: Optimize Options. (line 1672)
-* fmax-errors: Warning Options. (line 18)
-* fmem-report: Debugging Options. (line 315)
-* fmerge-all-constants: Optimize Options. (line 337)
-* fmerge-constants: Optimize Options. (line 327)
-* fmerge-debug-strings: Debugging Options. (line 279)
-* fmessage-length: Language Independent Options.
- (line 15)
-* fmodulo-sched: Optimize Options. (line 348)
-* fmodulo-sched-allow-regmoves: Optimize Options. (line 353)
-* fmove-loop-invariants: Optimize Options. (line 2180)
-* fms-extensions <1>: Unnamed Fields. (line 36)
-* fms-extensions <2>: C Dialect Options. (line 243)
-* fms-extensions: C++ Dialect Options.
- (line 156)
-* fmudflap: Optimize Options. (line 393)
-* fmudflapir: Optimize Options. (line 393)
-* fmudflapth: Optimize Options. (line 393)
-* fnext-runtime: Objective-C and Objective-C++ Dialect Options.
- (line 43)
-* fno-access-control: C++ Dialect Options.
- (line 41)
-* fno-asm: C Dialect Options. (line 170)
-* fno-branch-count-reg: Optimize Options. (line 360)
-* fno-builtin <1>: Function Attributes.
- (line 459)
-* fno-builtin <2>: C Dialect Options. (line 184)
-* fno-builtin <3>: Warning Options. (line 240)
-* fno-builtin: Other Builtins. (line 14)
-* fno-common <1>: Variable Attributes.
- (line 105)
-* fno-common: Code Gen Options. (line 135)
-* fno-compare-debug: Debugging Options. (line 160)
-* fno-deduce-init-list: C++ Dialect Options.
- (line 73)
-* fno-default-inline <1>: C++ Dialect Options.
- (line 330)
-* fno-default-inline <2>: Inline. (line 71)
-* fno-default-inline: Optimize Options. (line 159)
-* fno-defer-pop: Optimize Options. (line 166)
-* fno-diagnostics-show-option: Language Independent Options.
- (line 36)
-* fno-dwarf2-cfi-asm: Debugging Options. (line 291)
-* fno-elide-constructors: C++ Dialect Options.
- (line 104)
-* fno-enforce-eh-specs: C++ Dialect Options.
- (line 110)
-* fno-for-scope: C++ Dialect Options.
- (line 121)
-* fno-function-cse: Optimize Options. (line 370)
-* fno-gnu-keywords: C++ Dialect Options.
- (line 133)
-* fno-guess-branch-probability: Optimize Options. (line 1266)
-* fno-ident: Code Gen Options. (line 155)
-* fno-implement-inlines <1>: C++ Dialect Options.
- (line 150)
-* fno-implement-inlines: C++ Interface. (line 75)
-* fno-implicit-inline-templates: C++ Dialect Options.
- (line 144)
-* fno-implicit-templates <1>: Template Instantiation.
- (line 87)
-* fno-implicit-templates: C++ Dialect Options.
- (line 138)
-* fno-inline: Optimize Options. (line 221)
-* fno-ira-share-save-slots: Optimize Options. (line 611)
-* fno-ira-share-spill-slots: Optimize Options. (line 617)
-* fno-jump-tables: Code Gen Options. (line 228)
-* fno-math-errno: Optimize Options. (line 1930)
-* fno-merge-debug-strings: Debugging Options. (line 279)
-* fno-nil-receivers: Objective-C and Objective-C++ Dialect Options.
- (line 49)
-* fno-nonansi-builtins: C++ Dialect Options.
- (line 161)
-* fno-operator-names: C++ Dialect Options.
- (line 177)
-* fno-optional-diags: C++ Dialect Options.
- (line 181)
-* fno-peephole: Optimize Options. (line 1257)
-* fno-peephole2: Optimize Options. (line 1257)
-* fno-pretty-templates: C++ Dialect Options.
- (line 191)
-* fno-rtti: C++ Dialect Options.
- (line 209)
-* fno-sched-interblock: Optimize Options. (line 654)
-* fno-sched-spec: Optimize Options. (line 659)
-* fno-set-stack-executable: i386 and x86-64 Windows Options.
- (line 46)
-* fno-show-column: Preprocessor Options.
- (line 546)
-* fno-signed-bitfields: C Dialect Options. (line 328)
-* fno-signed-zeros: Optimize Options. (line 2003)
-* fno-stack-limit: Code Gen Options. (line 400)
-* fno-threadsafe-statics: C++ Dialect Options.
- (line 240)
-* fno-toplevel-reorder: Optimize Options. (line 1464)
-* fno-trapping-math: Optimize Options. (line 2013)
-* fno-unsigned-bitfields: C Dialect Options. (line 328)
-* fno-use-cxa-get-exception-ptr: C++ Dialect Options.
- (line 253)
-* fno-var-tracking-assignments: Debugging Options. (line 1126)
-* fno-var-tracking-assignments-toggle: Debugging Options. (line 1136)
-* fno-weak: C++ Dialect Options.
- (line 315)
-* fno-working-directory: Preprocessor Options.
- (line 531)
-* fno-zero-initialized-in-bss: Optimize Options. (line 381)
-* fnon-call-exceptions: Code Gen Options. (line 48)
-* fnothrow-opt: C++ Dialect Options.
- (line 166)
-* fobjc-abi-version: Objective-C and Objective-C++ Dialect Options.
- (line 56)
-* fobjc-call-cxx-cdtors: Objective-C and Objective-C++ Dialect Options.
- (line 67)
-* fobjc-direct-dispatch: Objective-C and Objective-C++ Dialect Options.
- (line 92)
-* fobjc-exceptions: Objective-C and Objective-C++ Dialect Options.
- (line 96)
-* fobjc-gc: Objective-C and Objective-C++ Dialect Options.
- (line 105)
-* fobjc-nilcheck: Objective-C and Objective-C++ Dialect Options.
- (line 111)
-* fobjc-std: Objective-C and Objective-C++ Dialect Options.
- (line 120)
-* fomit-frame-pointer: Optimize Options. (line 194)
-* fopenmp: C Dialect Options. (line 235)
-* foptimize-register-move: Optimize Options. (line 571)
-* foptimize-sibling-calls: Optimize Options. (line 216)
-* force_cpusubtype_ALL: Darwin Options. (line 138)
-* force_flat_namespace: Darwin Options. (line 199)
-* fpack-struct: Code Gen Options. (line 279)
-* fpartial-inlining: Optimize Options. (line 1232)
-* fpcc-struct-return <1>: Code Gen Options. (line 70)
-* fpcc-struct-return: Incompatibilities. (line 170)
-* fpch-deps: Preprocessor Options.
- (line 282)
-* fpch-preprocess: Preprocessor Options.
- (line 290)
-* fpeel-loops: Optimize Options. (line 2172)
-* fpermissive: C++ Dialect Options.
- (line 186)
-* fPIC: Code Gen Options. (line 205)
-* fpic: Code Gen Options. (line 184)
-* fpie: Code Gen Options. (line 218)
-* fPIE: Code Gen Options. (line 218)
-* fplan9-extensions: Unnamed Fields. (line 44)
-* fpmu-profile-generate: Optimize Options. (line 1801)
-* fpmu-profile-use: Optimize Options. (line 1812)
-* fpost-ipa-mem-report: Debugging Options. (line 321)
-* fpre-ipa-mem-report: Debugging Options. (line 319)
-* fpredictive-commoning: Optimize Options. (line 1239)
-* fprefetch-loop-arrays: Optimize Options. (line 1246)
-* fpreprocessed: Preprocessor Options.
- (line 489)
-* fprofile-arcs <1>: Debugging Options. (line 356)
-* fprofile-arcs: Other Builtins. (line 247)
-* fprofile-correction: Optimize Options. (line 1743)
-* fprofile-dir: Optimize Options. (line 1750)
-* fprofile-generate: Optimize Options. (line 1761)
-* fprofile-use: Optimize Options. (line 1786)
-* fprofile-values: Optimize Options. (line 2121)
-* fpu: RX Options. (line 17)
-* frandom-seed: Debugging Options. (line 1020)
-* freciprocal-math: Optimize Options. (line 1982)
-* frecord-gcc-switches: Code Gen Options. (line 174)
-* frecord-gcc-switches-in-elf: Optimize Options. (line 1871)
-* freg-struct-return: Code Gen Options. (line 88)
-* fregmove: Optimize Options. (line 571)
-* frename-registers: Optimize Options. (line 2139)
-* freorder-blocks: Optimize Options. (line 1283)
-* freorder-blocks-and-partition: Optimize Options. (line 1289)
-* freorder-functions: Optimize Options. (line 1300)
-* freplace-objc-classes: Objective-C and Objective-C++ Dialect Options.
- (line 131)
-* frepo <1>: Template Instantiation.
- (line 62)
-* frepo: C++ Dialect Options.
- (line 204)
-* frerun-cse-after-loop: Optimize Options. (line 448)
-* freschedule-modulo-scheduled-loops: Optimize Options. (line 755)
-* fripa: Optimize Options. (line 1817)
-* fripa-disallow-asm-modules: Optimize Options. (line 1825)
-* fripa-disallow-opt-mismatch: Optimize Options. (line 1833)
-* fripa-no-promote-always-inline-func: Optimize Options. (line 1840)
-* fripa-peel-size-limit: Optimize Options. (line 1849)
-* fripa-unroll-size-limit: Optimize Options. (line 1856)
-* fripa-verbose: Optimize Options. (line 1844)
-* frounding-math: Optimize Options. (line 2028)
-* fsched-critical-path-heuristic: Optimize Options. (line 721)
-* fsched-dep-count-heuristic: Optimize Options. (line 748)
-* fsched-group-heuristic: Optimize Options. (line 715)
-* fsched-last-insn-heuristic: Optimize Options. (line 741)
-* fsched-pressure: Optimize Options. (line 664)
-* fsched-rank-heuristic: Optimize Options. (line 734)
-* fsched-spec-insn-heuristic: Optimize Options. (line 727)
-* fsched-spec-load: Optimize Options. (line 673)
-* fsched-spec-load-dangerous: Optimize Options. (line 678)
-* fsched-stalled-insns: Optimize Options. (line 684)
-* fsched-stalled-insns-dep: Optimize Options. (line 694)
-* fsched-verbose: Debugging Options. (line 1030)
-* fsched2-use-superblocks: Optimize Options. (line 704)
-* fschedule-insns: Optimize Options. (line 635)
-* fschedule-insns2: Optimize Options. (line 645)
-* fsection-anchors: Optimize Options. (line 2240)
-* fsel-sched-pipelining: Optimize Options. (line 769)
-* fsel-sched-pipelining-outer-loops: Optimize Options. (line 774)
-* fselective-scheduling: Optimize Options. (line 761)
-* fselective-scheduling2: Optimize Options. (line 765)
-* fshort-double: Code Gen Options. (line 117)
-* fshort-enums <1>: Code Gen Options. (line 106)
-* fshort-enums <2>: Structures unions enumerations and bit-fields implementation.
- (line 43)
-* fshort-enums <3>: Non-bugs. (line 42)
-* fshort-enums: Type Attributes. (line 113)
-* fshort-wchar: Code Gen Options. (line 125)
-* fsignaling-nans: Optimize Options. (line 2048)
-* fsigned-bitfields <1>: Non-bugs. (line 57)
-* fsigned-bitfields: C Dialect Options. (line 328)
-* fsigned-char <1>: C Dialect Options. (line 318)
-* fsigned-char: Characters implementation.
- (line 31)
-* fsingle-precision-constant: Optimize Options. (line 2063)
-* fsplit-ivs-in-unroller: Optimize Options. (line 1213)
-* fsplit-stack <1>: Code Gen Options. (line 414)
-* fsplit-stack: Function Attributes.
- (line 904)
-* fsplit-wide-types: Optimize Options. (line 423)
-* fstack-check: Code Gen Options. (line 361)
-* fstack-limit-register: Code Gen Options. (line 400)
-* fstack-limit-symbol: Code Gen Options. (line 400)
-* fstack-protector: Optimize Options. (line 2223)
-* fstack-protector-all: Optimize Options. (line 2232)
-* fstack-protector-strong: Optimize Options. (line 2235)
-* fstack-usage: Debugging Options. (line 325)
-* fstats: C++ Dialect Options.
- (line 219)
-* fstrict-aliasing: Optimize Options. (line 1313)
-* fstrict-enums: C++ Dialect Options.
- (line 224)
-* fstrict-overflow: Optimize Options. (line 1359)
-* fstrict-volatile-bitfields: Code Gen Options. (line 517)
-* fsyntax-only: Warning Options. (line 14)
-* ftabstop: Preprocessor Options.
- (line 502)
-* ftemplate-depth: C++ Dialect Options.
- (line 233)
-* ftest-coverage: Debugging Options. (line 412)
-* fthread-jumps: Optimize Options. (line 414)
-* ftime-report: Debugging Options. (line 311)
-* ftls-model: Code Gen Options. (line 443)
-* ftracer: Optimize Options. (line 1196)
-* ftrapv: Code Gen Options. (line 22)
-* ftree-bit-ccp: Optimize Options. (line 900)
-* ftree-builtin-call-dce: Optimize Options. (line 920)
-* ftree-ccp: Optimize Options. (line 906)
-* ftree-ch: Optimize Options. (line 940)
-* ftree-copy-prop: Optimize Options. (line 827)
-* ftree-copyrename: Optimize Options. (line 1152)
-* ftree-dce: Optimize Options. (line 916)
-* ftree-dominator-opts: Optimize Options. (line 926)
-* ftree-dse: Optimize Options. (line 933)
-* ftree-forwprop: Optimize Options. (line 812)
-* ftree-fre: Optimize Options. (line 816)
-* ftree-loop-im: Optimize Options. (line 1113)
-* ftree-loop-ivcanon: Optimize Options. (line 1122)
-* ftree-loop-linear: Optimize Options. (line 951)
-* ftree-loop-optimize: Optimize Options. (line 947)
-* ftree-parallelize-loops: Optimize Options. (line 1133)
-* ftree-phiprop: Optimize Options. (line 823)
-* ftree-pre: Optimize Options. (line 808)
-* ftree-pta: Optimize Options. (line 1142)
-* ftree-reassoc: Optimize Options. (line 804)
-* ftree-sink: Optimize Options. (line 896)
-* ftree-slp-vectorize: Optimize Options. (line 1171)
-* ftree-sra: Optimize Options. (line 1146)
-* ftree-ter: Optimize Options. (line 1159)
-* ftree-vect-loop-version: Optimize Options. (line 1175)
-* ftree-vectorize: Optimize Options. (line 1167)
-* ftree-vectorizer-verbose: Debugging Options. (line 993)
-* ftree-vrp: Optimize Options. (line 1187)
-* funit-at-a-time: Optimize Options. (line 1457)
-* funroll-all-loops: Optimize Options. (line 2166)
-* funroll-loops: Optimize Options. (line 1201)
-* funsafe-loop-optimizations: Optimize Options. (line 495)
-* funsafe-math-optimizations: Optimize Options. (line 1948)
-* funsigned-bitfields <1>: Structures unions enumerations and bit-fields implementation.
- (line 17)
-* funsigned-bitfields <2>: C Dialect Options. (line 328)
-* funsigned-bitfields: Non-bugs. (line 57)
-* funsigned-char <1>: C Dialect Options. (line 300)
-* funsigned-char: Characters implementation.
- (line 31)
-* funswitch-loops: Optimize Options. (line 2184)
-* funwind-tables: Code Gen Options. (line 57)
-* fuse-cxa-atexit: C++ Dialect Options.
- (line 246)
-* fvar-tracking: Debugging Options. (line 1116)
-* fvar-tracking-assignments: Debugging Options. (line 1126)
-* fvar-tracking-assignments-toggle: Debugging Options. (line 1136)
-* fvariable-expansion-in-unroller: Optimize Options. (line 1227)
-* fvect-cost-model: Optimize Options. (line 1184)
-* fverbose-asm: Code Gen Options. (line 165)
-* fvisibility: Code Gen Options. (line 451)
-* fvisibility-inlines-hidden: C++ Dialect Options.
- (line 258)
-* fvisibility-ms-compat: C++ Dialect Options.
- (line 286)
-* fvpt: Optimize Options. (line 2130)
-* fweb: Optimize Options. (line 1476)
-* fwhole-program: Optimize Options. (line 1487)
-* fwide-exec-charset: Preprocessor Options.
- (line 513)
-* fworking-directory: Preprocessor Options.
- (line 531)
-* fwrapv: Code Gen Options. (line 26)
-* fzero-link: Objective-C and Objective-C++ Dialect Options.
- (line 141)
-* g: Debugging Options. (line 10)
-* G <1>: System V Options. (line 10)
-* G <2>: MIPS Options. (line 315)
-* G <3>: RS/6000 and PowerPC Options.
- (line 703)
-* G: M32R/D Options. (line 57)
-* gcoff: Debugging Options. (line 70)
-* gdwarf-VERSION: Debugging Options. (line 88)
-* gen-decls: Objective-C and Objective-C++ Dialect Options.
- (line 153)
-* gfull: Darwin Options. (line 71)
-* ggdb: Debugging Options. (line 38)
-* gmlt: Debugging Options. (line 142)
-* gno-strict-dwarf: Debugging Options. (line 105)
-* gstabs: Debugging Options. (line 44)
-* gstabs+: Debugging Options. (line 64)
-* gstrict-dwarf: Debugging Options. (line 99)
-* gtoggle: Debugging Options. (line 146)
-* gused: Darwin Options. (line 66)
-* gvms: Debugging Options. (line 109)
-* gxcoff: Debugging Options. (line 75)
-* gxcoff+: Debugging Options. (line 80)
-* H: Preprocessor Options.
- (line 664)
-* headerpad_max_install_names: Darwin Options. (line 199)
-* help <1>: Preprocessor Options.
- (line 656)
-* help: Overall Options. (line 221)
-* I <1>: Directory Options. (line 10)
-* I: Preprocessor Options.
- (line 65)
-* I- <1>: Directory Options. (line 112)
-* I-: Preprocessor Options.
- (line 373)
-* idirafter: Preprocessor Options.
- (line 415)
-* iframework: Darwin Options. (line 59)
-* imacros: Preprocessor Options.
- (line 406)
-* image_base: Darwin Options. (line 199)
-* imultilib: Preprocessor Options.
- (line 440)
-* include: Preprocessor Options.
- (line 395)
-* init: Darwin Options. (line 199)
-* install_name: Darwin Options. (line 199)
-* iprefix: Preprocessor Options.
- (line 422)
-* iquote <1>: Directory Options. (line 36)
-* iquote: Preprocessor Options.
- (line 452)
-* isysroot: Preprocessor Options.
- (line 434)
-* isystem: Preprocessor Options.
- (line 444)
-* iwithprefix: Preprocessor Options.
- (line 428)
-* iwithprefixbefore: Preprocessor Options.
- (line 428)
-* keep_private_externs: Darwin Options. (line 199)
-* L: Directory Options. (line 42)
-* l: Link Options. (line 26)
-* lobjc: Link Options. (line 53)
-* M: Preprocessor Options.
- (line 173)
-* m: RS/6000 and PowerPC Options.
- (line 552)
-* m1: SH Options. (line 9)
-* m10: PDP-11 Options. (line 29)
-* m128bit-long-double: i386 and x86-64 Options.
- (line 283)
-* m16-bit: CRIS Options. (line 64)
-* m2: SH Options. (line 12)
-* m210: MCore Options. (line 43)
-* m2a: SH Options. (line 30)
-* m2a-nofpu: SH Options. (line 18)
-* m2a-single: SH Options. (line 26)
-* m2a-single-only: SH Options. (line 22)
-* m3: SH Options. (line 34)
-* m31: S/390 and zSeries Options.
- (line 87)
-* m32 <1>: i386 and x86-64 Options.
- (line 697)
-* m32 <2>: RS/6000 and PowerPC Options.
- (line 266)
-* m32: SPARC Options. (line 182)
-* m32-bit: CRIS Options. (line 64)
-* m32bit-doubles: RX Options. (line 10)
-* m32r: M32R/D Options. (line 15)
-* m32r2: M32R/D Options. (line 9)
-* m32rx: M32R/D Options. (line 12)
-* m340: MCore Options. (line 43)
-* m3dnow: i386 and x86-64 Options.
- (line 477)
-* m3e: SH Options. (line 37)
-* m4: SH Options. (line 51)
-* m4-nofpu: SH Options. (line 40)
-* m4-single: SH Options. (line 47)
-* m4-single-only: SH Options. (line 43)
-* m40: PDP-11 Options. (line 23)
-* m45: PDP-11 Options. (line 26)
-* m4a: SH Options. (line 66)
-* m4a-nofpu: SH Options. (line 54)
-* m4a-single: SH Options. (line 62)
-* m4a-single-only: SH Options. (line 58)
-* m4al: SH Options. (line 69)
-* m4byte-functions: MCore Options. (line 27)
-* m5200: M680x0 Options. (line 146)
-* m5206e: M680x0 Options. (line 155)
-* m528x: M680x0 Options. (line 159)
-* m5307: M680x0 Options. (line 163)
-* m5407: M680x0 Options. (line 167)
-* m64 <1>: SPARC Options. (line 182)
-* m64 <2>: S/390 and zSeries Options.
- (line 87)
-* m64 <3>: RS/6000 and PowerPC Options.
- (line 266)
-* m64: i386 and x86-64 Options.
- (line 697)
-* m64bit-doubles: RX Options. (line 10)
-* m68000: M680x0 Options. (line 94)
-* m68010: M680x0 Options. (line 102)
-* m68020: M680x0 Options. (line 108)
-* m68020-40: M680x0 Options. (line 177)
-* m68020-60: M680x0 Options. (line 186)
-* m68030: M680x0 Options. (line 113)
-* m68040: M680x0 Options. (line 118)
-* m68060: M680x0 Options. (line 127)
-* m6811: M68hc1x Options. (line 13)
-* m6812: M68hc1x Options. (line 18)
-* m68881: M680x0 Options. (line 196)
-* m68hc11: M68hc1x Options. (line 13)
-* m68hc12: M68hc1x Options. (line 18)
-* m68hcs12: M68hc1x Options. (line 23)
-* m68S12: M68hc1x Options. (line 23)
-* m8-bit: CRIS Options. (line 64)
-* m96bit-long-double: i386 and x86-64 Options.
- (line 283)
-* mabi <1>: RS/6000 and PowerPC Options.
- (line 583)
-* mabi <2>: ARM Options. (line 10)
-* mabi: i386 and x86-64 Options.
- (line 592)
-* mabi=32: MIPS Options. (line 130)
-* mabi=64: MIPS Options. (line 130)
-* mabi=eabi: MIPS Options. (line 130)
-* mabi=gnu: MMIX Options. (line 20)
-* mabi=ibmlongdouble: RS/6000 and PowerPC Options.
- (line 596)
-* mabi=ieeelongdouble: RS/6000 and PowerPC Options.
- (line 600)
-* mabi=mmixware: MMIX Options. (line 20)
-* mabi=n32: MIPS Options. (line 130)
-* mabi=no-spe: RS/6000 and PowerPC Options.
- (line 593)
-* mabi=o64: MIPS Options. (line 130)
-* mabi=spe: RS/6000 and PowerPC Options.
- (line 588)
-* mabicalls: MIPS Options. (line 154)
-* mabort-on-noreturn: ARM Options. (line 162)
-* mabsdiff: MeP Options. (line 7)
-* mabshi: PDP-11 Options. (line 55)
-* mac0: PDP-11 Options. (line 16)
-* macc-4: FRV Options. (line 113)
-* macc-8: FRV Options. (line 116)
-* maccumulate-outgoing-args <1>: i386 and x86-64 Options.
- (line 609)
-* maccumulate-outgoing-args: SH Options. (line 199)
-* maddress-space-conversion: SPU Options. (line 63)
-* madjust-unroll: SH Options. (line 219)
-* mads: RS/6000 and PowerPC Options.
- (line 626)
-* maix-struct-return: RS/6000 and PowerPC Options.
- (line 576)
-* maix32: RS/6000 and PowerPC Options.
- (line 304)
-* maix64: RS/6000 and PowerPC Options.
- (line 304)
-* malign-300: H8/300 Options. (line 31)
-* malign-double: i386 and x86-64 Options.
- (line 267)
-* malign-int: M680x0 Options. (line 266)
-* malign-labels: FRV Options. (line 104)
-* malign-loops: M32R/D Options. (line 73)
-* malign-natural: RS/6000 and PowerPC Options.
- (line 343)
-* malign-power: RS/6000 and PowerPC Options.
- (line 343)
-* mall-opts: MeP Options. (line 11)
-* malloc-cc: FRV Options. (line 25)
-* malpha-as: DEC Alpha Options. (line 159)
-* maltivec: RS/6000 and PowerPC Options.
- (line 191)
-* mam33: MN10300 Options. (line 17)
-* mam33-2: MN10300 Options. (line 24)
-* mam34: MN10300 Options. (line 28)
-* mandroid: GNU/Linux Options. (line 21)
-* mapcs: ARM Options. (line 22)
-* mapcs-frame: ARM Options. (line 14)
-* mapp-regs <1>: SPARC Options. (line 10)
-* mapp-regs: V850 Options. (line 57)
-* march <1>: i386 and x86-64 Options.
- (line 166)
-* march <2>: S/390 and zSeries Options.
- (line 116)
-* march <3>: ARM Options. (line 108)
-* march <4>: CRIS Options. (line 10)
-* march <5>: M680x0 Options. (line 12)
-* march <6>: HPPA Options. (line 9)
-* march <7>: MIPS Options. (line 14)
-* march: HPPA Options. (line 162)
-* mas100-syntax: RX Options. (line 75)
-* masm=DIALECT: i386 and x86-64 Options.
- (line 223)
-* matomic-updates: SPU Options. (line 78)
-* mauto-incdec: M68hc1x Options. (line 26)
-* mauto-pic: IA-64 Options. (line 50)
-* maverage: MeP Options. (line 16)
-* mavoid-indexed-addresses: RS/6000 and PowerPC Options.
- (line 412)
-* mb: SH Options. (line 74)
-* mbackchain: S/390 and zSeries Options.
- (line 35)
-* mbarrel-shift-enabled: LM32 Options. (line 9)
-* mbase-addresses: MMIX Options. (line 54)
-* mbased=: MeP Options. (line 20)
-* mbcopy: PDP-11 Options. (line 36)
-* mbcopy-builtin: PDP-11 Options. (line 32)
-* mbig: RS/6000 and PowerPC Options.
- (line 493)
-* mbig-endian <1>: IA-64 Options. (line 9)
-* mbig-endian <2>: RS/6000 and PowerPC Options.
- (line 493)
-* mbig-endian <3>: MCore Options. (line 39)
-* mbig-endian: ARM Options. (line 67)
-* mbig-endian-data: RX Options. (line 42)
-* mbig-switch <1>: V850 Options. (line 52)
-* mbig-switch: HPPA Options. (line 23)
-* mbigtable: SH Options. (line 90)
-* mbionic: GNU/Linux Options. (line 17)
-* mbit-align: RS/6000 and PowerPC Options.
- (line 444)
-* mbitfield: M680x0 Options. (line 234)
-* mbitops <1>: MeP Options. (line 26)
-* mbitops: SH Options. (line 94)
-* mblock-move-inline-limit: RS/6000 and PowerPC Options.
- (line 697)
-* mbranch-cheap: PDP-11 Options. (line 65)
-* mbranch-cost: MIPS Options. (line 611)
-* mbranch-cost=NUMBER: M32R/D Options. (line 82)
-* mbranch-expensive: PDP-11 Options. (line 61)
-* mbranch-hints: SPU Options. (line 27)
-* mbranch-likely: MIPS Options. (line 618)
-* mbranch-predict: MMIX Options. (line 49)
-* mbss-plt: RS/6000 and PowerPC Options.
- (line 214)
-* mbuild-constants: DEC Alpha Options. (line 142)
-* mbwx: DEC Alpha Options. (line 171)
-* mc68000: M680x0 Options. (line 94)
-* mc68020: M680x0 Options. (line 108)
-* mc=: MeP Options. (line 31)
-* mcache-size: SPU Options. (line 70)
-* mcall-eabi: RS/6000 and PowerPC Options.
- (line 546)
-* mcall-freebsd: RS/6000 and PowerPC Options.
- (line 564)
-* mcall-gnu: RS/6000 and PowerPC Options.
- (line 560)
-* mcall-linux: RS/6000 and PowerPC Options.
- (line 556)
-* mcall-netbsd: RS/6000 and PowerPC Options.
- (line 568)
-* mcall-prologues: AVR Options. (line 36)
-* mcall-sysv: RS/6000 and PowerPC Options.
- (line 538)
-* mcall-sysv-eabi: RS/6000 and PowerPC Options.
- (line 546)
-* mcall-sysv-noeabi: RS/6000 and PowerPC Options.
- (line 549)
-* mcallee-super-interworking: ARM Options. (line 255)
-* mcaller-super-interworking: ARM Options. (line 262)
-* mcallgraph-data: MCore Options. (line 31)
-* mcc-init: CRIS Options. (line 41)
-* mcfv4e: M680x0 Options. (line 171)
-* mcheck-zero-division: MIPS Options. (line 426)
-* mcirrus-fix-invalid-insns: ARM Options. (line 202)
-* mcix: DEC Alpha Options. (line 171)
-* mcld: i386 and x86-64 Options.
- (line 506)
-* mclip: MeP Options. (line 35)
-* mcmodel=embmedany: SPARC Options. (line 204)
-* mcmodel=kernel: i386 and x86-64 Options.
- (line 719)
-* mcmodel=large <1>: RS/6000 and PowerPC Options.
- (line 185)
-* mcmodel=large: i386 and x86-64 Options.
- (line 731)
-* mcmodel=medany: SPARC Options. (line 198)
-* mcmodel=medium <1>: i386 and x86-64 Options.
- (line 724)
-* mcmodel=medium: RS/6000 and PowerPC Options.
- (line 181)
-* mcmodel=medlow: SPARC Options. (line 187)
-* mcmodel=medmid: SPARC Options. (line 192)
-* mcmodel=small <1>: i386 and x86-64 Options.
- (line 713)
-* mcmodel=small: RS/6000 and PowerPC Options.
- (line 177)
-* mcmpb: RS/6000 and PowerPC Options.
- (line 33)
-* mcode-readable: MIPS Options. (line 386)
-* mcond-exec: FRV Options. (line 152)
-* mcond-move: FRV Options. (line 128)
-* mconfig=: MeP Options. (line 39)
-* mconsole: i386 and x86-64 Windows Options.
- (line 9)
-* mconst-align: CRIS Options. (line 55)
-* mconst16: Xtensa Options. (line 10)
-* mconstant-gp: IA-64 Options. (line 46)
-* mcop: MeP Options. (line 48)
-* mcop32: MeP Options. (line 53)
-* mcop64: MeP Options. (line 56)
-* mcorea: Blackfin Options. (line 150)
-* mcoreb: Blackfin Options. (line 156)
-* mcpu <1>: M680x0 Options. (line 28)
-* mcpu <2>: picoChip Options. (line 9)
-* mcpu <3>: SPARC Options. (line 81)
-* mcpu <4>: i386 and x86-64 Options.
- (line 171)
-* mcpu <5>: CRIS Options. (line 10)
-* mcpu <6>: DEC Alpha Options. (line 223)
-* mcpu <7>: ARM Options. (line 79)
-* mcpu <8>: FRV Options. (line 212)
-* mcpu <9>: RS/6000 and PowerPC Options.
- (line 119)
-* mcpu: ARC Options. (line 23)
-* mcpu32: M680x0 Options. (line 137)
-* mcpu= <1>: M32C Options. (line 7)
-* mcpu= <2>: MicroBlaze Options. (line 20)
-* mcpu=: Blackfin Options. (line 7)
-* mcrc32: i386 and x86-64 Options.
- (line 548)
-* mcsync-anomaly: Blackfin Options. (line 56)
-* mcx16: i386 and x86-64 Options.
- (line 526)
-* MD: Preprocessor Options.
- (line 262)
-* mdalign: SH Options. (line 80)
-* mdata: ARC Options. (line 30)
-* mdata-align: CRIS Options. (line 55)
-* mdc: MeP Options. (line 62)
-* mdebug <1>: M32R/D Options. (line 69)
-* mdebug: S/390 and zSeries Options.
- (line 112)
-* mdebug-main=PREFIX <1>: DEC Alpha/VMS Options.
- (line 13)
-* mdebug-main=PREFIX: IA-64/VMS Options. (line 13)
-* mdec-asm: PDP-11 Options. (line 72)
-* mdisable-callt: V850 Options. (line 93)
-* mdisable-fpregs: HPPA Options. (line 33)
-* mdisable-indexing: HPPA Options. (line 40)
-* mdiv <1>: MeP Options. (line 65)
-* mdiv <2>: MCore Options. (line 15)
-* mdiv: M680x0 Options. (line 208)
-* mdiv=STRATEGY: SH Options. (line 158)
-* mdivide-breaks: MIPS Options. (line 432)
-* mdivide-enabled: LM32 Options. (line 12)
-* mdivide-traps: MIPS Options. (line 432)
-* mdivsi3_libfunc=NAME: SH Options. (line 205)
-* mdll: i386 and x86-64 Windows Options.
- (line 16)
-* mdlmzb: RS/6000 and PowerPC Options.
- (line 437)
-* mdmx: MIPS Options. (line 279)
-* mdouble: FRV Options. (line 38)
-* mdouble-float <1>: RS/6000 and PowerPC Options.
- (line 361)
-* mdouble-float: MIPS Options. (line 237)
-* mdsp: MIPS Options. (line 256)
-* mdspr2: MIPS Options. (line 262)
-* mdual-nops: SPU Options. (line 90)
-* mdwarf2-asm: IA-64 Options. (line 94)
-* mdword: FRV Options. (line 32)
-* mdynamic-no-pic: RS/6000 and PowerPC Options.
- (line 498)
-* mea32: SPU Options. (line 55)
-* mea64: SPU Options. (line 55)
-* meabi: RS/6000 and PowerPC Options.
- (line 645)
-* mearly-stop-bits: IA-64 Options. (line 100)
-* meb <1>: MeP Options. (line 68)
-* meb: Score Options. (line 9)
-* mel <1>: Score Options. (line 12)
-* mel: MeP Options. (line 71)
-* melf <1>: MMIX Options. (line 44)
-* melf: CRIS Options. (line 87)
-* memb: RS/6000 and PowerPC Options.
- (line 640)
-* membedded-data: MIPS Options. (line 373)
-* memregs=: M32C Options. (line 21)
-* mep: V850 Options. (line 16)
-* mepsilon: MMIX Options. (line 15)
-* merror-reloc: SPU Options. (line 10)
-* mesa: S/390 and zSeries Options.
- (line 95)
-* metrax100: CRIS Options. (line 26)
-* metrax4: CRIS Options. (line 26)
-* mexplicit-relocs <1>: DEC Alpha Options. (line 184)
-* mexplicit-relocs: MIPS Options. (line 417)
-* mextern-sdata: MIPS Options. (line 335)
-* MF: Preprocessor Options.
- (line 208)
-* mfast-fp: Blackfin Options. (line 129)
-* mfast-indirect-calls: HPPA Options. (line 52)
-* mfaster-structs: SPARC Options. (line 71)
-* mfdpic: FRV Options. (line 56)
-* mfentry: i386 and x86-64 Options.
- (line 673)
-* mfix: DEC Alpha Options. (line 171)
-* mfix-and-continue: Darwin Options. (line 106)
-* mfix-at697f: SPARC Options. (line 168)
-* mfix-cortex-m3-ldrd: ARM Options. (line 284)
-* mfix-r10000: MIPS Options. (line 503)
-* mfix-r4000: MIPS Options. (line 482)
-* mfix-r4400: MIPS Options. (line 496)
-* mfix-sb1: MIPS Options. (line 535)
-* mfix-vr4120: MIPS Options. (line 514)
-* mfix-vr4130: MIPS Options. (line 528)
-* mfixed-cc: FRV Options. (line 28)
-* mfixed-range <1>: SPU Options. (line 47)
-* mfixed-range <2>: SH Options. (line 212)
-* mfixed-range <3>: IA-64 Options. (line 105)
-* mfixed-range: HPPA Options. (line 59)
-* mflip-mips16: MIPS Options. (line 110)
-* mfloat-abi: ARM Options. (line 41)
-* mfloat-gprs: RS/6000 and PowerPC Options.
- (line 249)
-* mfloat-ieee: DEC Alpha Options. (line 179)
-* mfloat-vax: DEC Alpha Options. (line 179)
-* mfloat32: PDP-11 Options. (line 52)
-* mfloat64: PDP-11 Options. (line 48)
-* mflush-func: MIPS Options. (line 602)
-* mflush-func=NAME: M32R/D Options. (line 94)
-* mflush-trap=NUMBER: M32R/D Options. (line 87)
-* mfmovd: SH Options. (line 97)
-* mforce-no-pic: Xtensa Options. (line 41)
-* mfp: ARM Options. (line 120)
-* mfp-exceptions: MIPS Options. (line 629)
-* mfp-reg: DEC Alpha Options. (line 25)
-* mfp-rounding-mode: DEC Alpha Options. (line 85)
-* mfp-trap-mode: DEC Alpha Options. (line 63)
-* mfp16-format: ARM Options. (line 141)
-* mfp32: MIPS Options. (line 220)
-* mfp64: MIPS Options. (line 223)
-* mfpe: ARM Options. (line 120)
-* mfpmath <1>: i386 and x86-64 Options.
- (line 174)
-* mfpmath: Optimize Options. (line 1908)
-* mfpr-32: FRV Options. (line 13)
-* mfpr-64: FRV Options. (line 16)
-* mfprnd: RS/6000 and PowerPC Options.
- (line 33)
-* mfpu <1>: PDP-11 Options. (line 9)
-* mfpu <2>: SPARC Options. (line 20)
-* mfpu <3>: RS/6000 and PowerPC Options.
- (line 369)
-* mfpu: ARM Options. (line 120)
-* mfriz: RS/6000 and PowerPC Options.
- (line 827)
-* mfull-toc: RS/6000 and PowerPC Options.
- (line 277)
-* mfused-madd <1>: Xtensa Options. (line 19)
-* mfused-madd <2>: IA-64 Options. (line 88)
-* mfused-madd <3>: i386 and x86-64 Options.
- (line 501)
-* mfused-madd <4>: S/390 and zSeries Options.
- (line 137)
-* mfused-madd <5>: MIPS Options. (line 467)
-* mfused-madd: RS/6000 and PowerPC Options.
- (line 421)
-* mg: VAX Options. (line 17)
-* MG: Preprocessor Options.
- (line 217)
-* mgas <1>: HPPA Options. (line 75)
-* mgas: DEC Alpha Options. (line 159)
-* mgen-cell-microcode: RS/6000 and PowerPC Options.
- (line 202)
-* mgettrcost=NUMBER: SH Options. (line 234)
-* mglibc: GNU/Linux Options. (line 9)
-* mgnu: VAX Options. (line 13)
-* mgnu-as: IA-64 Options. (line 18)
-* mgnu-ld <1>: IA-64 Options. (line 23)
-* mgnu-ld: HPPA Options. (line 111)
-* mgotplt: CRIS Options. (line 81)
-* mgp32: MIPS Options. (line 214)
-* mgp64: MIPS Options. (line 217)
-* mgpopt: MIPS Options. (line 358)
-* mgpr-32: FRV Options. (line 7)
-* mgpr-64: FRV Options. (line 10)
-* mgprel-ro: FRV Options. (line 79)
-* mh: H8/300 Options. (line 14)
-* mhard-dfp <1>: S/390 and zSeries Options.
- (line 20)
-* mhard-dfp: RS/6000 and PowerPC Options.
- (line 33)
-* mhard-float <1>: FRV Options. (line 19)
-* mhard-float <2>: RS/6000 and PowerPC Options.
- (line 355)
-* mhard-float <3>: MicroBlaze Options. (line 10)
-* mhard-float <4>: ARM Options. (line 57)
-* mhard-float <5>: SPARC Options. (line 20)
-* mhard-float <6>: S/390 and zSeries Options.
- (line 11)
-* mhard-float <7>: MIPS Options. (line 226)
-* mhard-float: M680x0 Options. (line 196)
-* mhard-quad-float: SPARC Options. (line 41)
-* mhardlit: MCore Options. (line 10)
-* mhint-max-distance: SPU Options. (line 102)
-* mhint-max-nops: SPU Options. (line 96)
-* mhitachi: SH Options. (line 104)
-* mhp-ld: HPPA Options. (line 123)
-* micplb: Blackfin Options. (line 169)
-* mid-shared-library: Blackfin Options. (line 77)
-* mieee <1>: DEC Alpha Options. (line 39)
-* mieee: SH Options. (line 116)
-* mieee-conformant: DEC Alpha Options. (line 134)
-* mieee-fp: i386 and x86-64 Options.
- (line 229)
-* mieee-with-inexact: DEC Alpha Options. (line 52)
-* milp32: IA-64 Options. (line 121)
-* mimpure-text: Solaris 2 Options. (line 9)
-* mincoming-stack-boundary: i386 and x86-64 Options.
- (line 407)
-* mindexed-addressing: SH Options. (line 224)
-* minline-all-stringops: i386 and x86-64 Options.
- (line 630)
-* minline-float-divide-max-throughput: IA-64 Options. (line 58)
-* minline-float-divide-min-latency: IA-64 Options. (line 54)
-* minline-ic_invalidate: SH Options. (line 123)
-* minline-int-divide-max-throughput: IA-64 Options. (line 69)
-* minline-int-divide-min-latency: IA-64 Options. (line 65)
-* minline-plt <1>: Blackfin Options. (line 134)
-* minline-plt: FRV Options. (line 64)
-* minline-sqrt-max-throughput: IA-64 Options. (line 80)
-* minline-sqrt-min-latency: IA-64 Options. (line 76)
-* minline-stringops-dynamically: i386 and x86-64 Options.
- (line 637)
-* minmax: M68hc1x Options. (line 31)
-* minsert-sched-nops: RS/6000 and PowerPC Options.
- (line 526)
-* mint-register: RX Options. (line 99)
-* mint16: PDP-11 Options. (line 40)
-* mint32 <1>: PDP-11 Options. (line 44)
-* mint32: H8/300 Options. (line 28)
-* mint8: AVR Options. (line 43)
-* minterlink-mips16: MIPS Options. (line 117)
-* minvalid-symbols: SH Options. (line 257)
-* mio-volatile: MeP Options. (line 74)
-* mips1: MIPS Options. (line 77)
-* mips16: MIPS Options. (line 102)
-* mips2: MIPS Options. (line 80)
-* mips3: MIPS Options. (line 83)
-* mips32: MIPS Options. (line 89)
-* mips32r2: MIPS Options. (line 92)
-* mips3d: MIPS Options. (line 285)
-* mips4: MIPS Options. (line 86)
-* mips64: MIPS Options. (line 95)
-* mips64r2: MIPS Options. (line 98)
-* misel: RS/6000 and PowerPC Options.
- (line 220)
-* misize: SH Options. (line 135)
-* missue-rate=NUMBER: M32R/D Options. (line 79)
-* mivc2: MeP Options. (line 59)
-* mjump-in-delay: HPPA Options. (line 28)
-* mkernel: Darwin Options. (line 84)
-* mknuthdiv: MMIX Options. (line 33)
-* ml <1>: MeP Options. (line 78)
-* ml: SH Options. (line 77)
-* mlarge-data: DEC Alpha Options. (line 195)
-* mlarge-data-threshold=NUMBER: i386 and x86-64 Options.
- (line 309)
-* mlarge-mem: SPU Options. (line 35)
-* mlarge-text: DEC Alpha Options. (line 213)
-* mleadz: MeP Options. (line 81)
-* mleaf-id-shared-library: Blackfin Options. (line 88)
-* mlibfuncs: MMIX Options. (line 10)
-* mlibrary-pic: FRV Options. (line 110)
-* mlinked-fp: FRV Options. (line 94)
-* mlinker-opt: HPPA Options. (line 85)
-* mlinux: CRIS Options. (line 91)
-* mlittle: RS/6000 and PowerPC Options.
- (line 487)
-* mlittle-endian <1>: RS/6000 and PowerPC Options.
- (line 487)
-* mlittle-endian <2>: MCore Options. (line 39)
-* mlittle-endian <3>: ARM Options. (line 63)
-* mlittle-endian <4>: SPARC Options. (line 176)
-* mlittle-endian: IA-64 Options. (line 13)
-* mlittle-endian-data: RX Options. (line 42)
-* mliw: MN10300 Options. (line 55)
-* mllsc: MIPS Options. (line 242)
-* mlocal-sdata: MIPS Options. (line 323)
-* mlong-calls <1>: M68hc1x Options. (line 35)
-* mlong-calls <2>: ARM Options. (line 167)
-* mlong-calls <3>: MIPS Options. (line 453)
-* mlong-calls <4>: FRV Options. (line 99)
-* mlong-calls <5>: V850 Options. (line 10)
-* mlong-calls: Blackfin Options. (line 117)
-* mlong-double-128: S/390 and zSeries Options.
- (line 29)
-* mlong-double-64: S/390 and zSeries Options.
- (line 29)
-* mlong-load-store: HPPA Options. (line 66)
-* mlong32: MIPS Options. (line 298)
-* mlong64: MIPS Options. (line 293)
-* mlongcall: RS/6000 and PowerPC Options.
- (line 717)
-* mlongcalls: Xtensa Options. (line 72)
-* mlow-64k: Blackfin Options. (line 66)
-* mlp64: IA-64 Options. (line 121)
-* MM: Preprocessor Options.
- (line 198)
-* mm: MeP Options. (line 84)
-* mmac <1>: Score Options. (line 21)
-* mmac: CRX Options. (line 9)
-* mmad: MIPS Options. (line 462)
-* mmalloc64 <1>: DEC Alpha/VMS Options.
- (line 17)
-* mmalloc64: IA-64/VMS Options. (line 17)
-* mmangle-cpu: ARC Options. (line 15)
-* mmax: DEC Alpha Options. (line 171)
-* mmax-constant-size: RX Options. (line 81)
-* mmax-stack-frame: CRIS Options. (line 22)
-* mmcount-ra-address: MIPS Options. (line 678)
-* mmcu: AVR Options. (line 9)
-* MMD: Preprocessor Options.
- (line 278)
-* mmedia: FRV Options. (line 44)
-* mmemcpy <1>: MIPS Options. (line 447)
-* mmemcpy: MicroBlaze Options. (line 13)
-* mmemory-latency: DEC Alpha Options. (line 276)
-* mmfcrf: RS/6000 and PowerPC Options.
- (line 33)
-* mmfpgpr: RS/6000 and PowerPC Options.
- (line 33)
-* mminimal-toc: RS/6000 and PowerPC Options.
- (line 277)
-* mminmax: MeP Options. (line 87)
-* mmmx: i386 and x86-64 Options.
- (line 477)
-* mmodel=large: M32R/D Options. (line 33)
-* mmodel=medium: M32R/D Options. (line 27)
-* mmodel=small: M32R/D Options. (line 18)
-* mmovbe: i386 and x86-64 Options.
- (line 544)
-* mmt: MIPS Options. (line 290)
-* mmul-bug-workaround: CRIS Options. (line 31)
-* mmuladd: FRV Options. (line 50)
-* mmulhw: RS/6000 and PowerPC Options.
- (line 430)
-* mmult: MeP Options. (line 90)
-* mmult-bug: MN10300 Options. (line 9)
-* mmulti-cond-exec: FRV Options. (line 176)
-* mmulticore: Blackfin Options. (line 138)
-* mmultiple: RS/6000 and PowerPC Options.
- (line 380)
-* mmvcle: S/390 and zSeries Options.
- (line 105)
-* mmvme: RS/6000 and PowerPC Options.
- (line 621)
-* mn: H8/300 Options. (line 20)
-* mnested-cond-exec: FRV Options. (line 189)
-* mnew-mnemonics: RS/6000 and PowerPC Options.
- (line 104)
-* mnhwloop: Score Options. (line 15)
-* mno-3dnow: i386 and x86-64 Options.
- (line 477)
-* mno-4byte-functions: MCore Options. (line 27)
-* mno-abicalls: MIPS Options. (line 154)
-* mno-abshi: PDP-11 Options. (line 58)
-* mno-ac0: PDP-11 Options. (line 20)
-* mno-address-space-conversion: SPU Options. (line 63)
-* mno-align-double: i386 and x86-64 Options.
- (line 267)
-* mno-align-int: M680x0 Options. (line 266)
-* mno-align-loops: M32R/D Options. (line 76)
-* mno-align-stringops: i386 and x86-64 Options.
- (line 625)
-* mno-altivec: RS/6000 and PowerPC Options.
- (line 191)
-* mno-am33: MN10300 Options. (line 20)
-* mno-app-regs <1>: V850 Options. (line 61)
-* mno-app-regs: SPARC Options. (line 10)
-* mno-as100-syntax: RX Options. (line 75)
-* mno-atomic-updates: SPU Options. (line 78)
-* mno-avoid-indexed-addresses: RS/6000 and PowerPC Options.
- (line 412)
-* mno-backchain: S/390 and zSeries Options.
- (line 35)
-* mno-base-addresses: MMIX Options. (line 54)
-* mno-bit-align: RS/6000 and PowerPC Options.
- (line 444)
-* mno-bitfield: M680x0 Options. (line 230)
-* mno-branch-likely: MIPS Options. (line 618)
-* mno-branch-predict: MMIX Options. (line 49)
-* mno-bwx: DEC Alpha Options. (line 171)
-* mno-callgraph-data: MCore Options. (line 31)
-* mno-check-zero-division: MIPS Options. (line 426)
-* mno-cirrus-fix-invalid-insns: ARM Options. (line 202)
-* mno-cix: DEC Alpha Options. (line 171)
-* mno-clearbss: MicroBlaze Options. (line 16)
-* mno-cmpb: RS/6000 and PowerPC Options.
- (line 33)
-* mno-cond-exec: FRV Options. (line 158)
-* mno-cond-move: FRV Options. (line 134)
-* mno-const-align: CRIS Options. (line 55)
-* mno-const16: Xtensa Options. (line 10)
-* mno-crt0: MN10300 Options. (line 44)
-* mno-csync-anomaly: Blackfin Options. (line 62)
-* mno-data-align: CRIS Options. (line 55)
-* mno-debug: S/390 and zSeries Options.
- (line 112)
-* mno-div <1>: M680x0 Options. (line 208)
-* mno-div: MCore Options. (line 15)
-* mno-dlmzb: RS/6000 and PowerPC Options.
- (line 437)
-* mno-double: FRV Options. (line 41)
-* mno-dsp: MIPS Options. (line 256)
-* mno-dspr2: MIPS Options. (line 262)
-* mno-dwarf2-asm: IA-64 Options. (line 94)
-* mno-dword: FRV Options. (line 35)
-* mno-eabi: RS/6000 and PowerPC Options.
- (line 645)
-* mno-early-stop-bits: IA-64 Options. (line 100)
-* mno-eflags: FRV Options. (line 125)
-* mno-embedded-data: MIPS Options. (line 373)
-* mno-ep: V850 Options. (line 16)
-* mno-epsilon: MMIX Options. (line 15)
-* mno-explicit-relocs <1>: DEC Alpha Options. (line 184)
-* mno-explicit-relocs: MIPS Options. (line 417)
-* mno-extern-sdata: MIPS Options. (line 335)
-* mno-fancy-math-387: i386 and x86-64 Options.
- (line 256)
-* mno-faster-structs: SPARC Options. (line 71)
-* mno-fix: DEC Alpha Options. (line 171)
-* mno-fix-r10000: MIPS Options. (line 503)
-* mno-fix-r4000: MIPS Options. (line 482)
-* mno-fix-r4400: MIPS Options. (line 496)
-* mno-float32: PDP-11 Options. (line 48)
-* mno-float64: PDP-11 Options. (line 52)
-* mno-flush-func: M32R/D Options. (line 99)
-* mno-flush-trap: M32R/D Options. (line 91)
-* mno-fp-in-toc: RS/6000 and PowerPC Options.
- (line 277)
-* mno-fp-regs: DEC Alpha Options. (line 25)
-* mno-fp-ret-in-387: i386 and x86-64 Options.
- (line 246)
-* mno-fprnd: RS/6000 and PowerPC Options.
- (line 33)
-* mno-fpu: SPARC Options. (line 25)
-* mno-fused-madd <1>: Xtensa Options. (line 19)
-* mno-fused-madd <2>: S/390 and zSeries Options.
- (line 137)
-* mno-fused-madd <3>: RS/6000 and PowerPC Options.
- (line 421)
-* mno-fused-madd <4>: IA-64 Options. (line 88)
-* mno-fused-madd <5>: MIPS Options. (line 467)
-* mno-fused-madd: i386 and x86-64 Options.
- (line 501)
-* mno-gnu-as: IA-64 Options. (line 18)
-* mno-gnu-ld: IA-64 Options. (line 23)
-* mno-gotplt: CRIS Options. (line 81)
-* mno-gpopt: MIPS Options. (line 358)
-* mno-hard-dfp <1>: RS/6000 and PowerPC Options.
- (line 33)
-* mno-hard-dfp: S/390 and zSeries Options.
- (line 20)
-* mno-hardlit: MCore Options. (line 10)
-* mno-id-shared-library: Blackfin Options. (line 84)
-* mno-ieee-fp: i386 and x86-64 Options.
- (line 229)
-* mno-inline-float-divide: IA-64 Options. (line 62)
-* mno-inline-int-divide: IA-64 Options. (line 73)
-* mno-inline-sqrt: IA-64 Options. (line 84)
-* mno-int16: PDP-11 Options. (line 44)
-* mno-int32: PDP-11 Options. (line 40)
-* mno-interlink-mips16: MIPS Options. (line 117)
-* mno-interrupts: AVR Options. (line 32)
-* mno-isel: RS/6000 and PowerPC Options.
- (line 220)
-* mno-knuthdiv: MMIX Options. (line 33)
-* mno-leaf-id-shared-library: Blackfin Options. (line 94)
-* mno-libfuncs: MMIX Options. (line 10)
-* mno-llsc: MIPS Options. (line 242)
-* mno-local-sdata: MIPS Options. (line 323)
-* mno-long-calls <1>: M68hc1x Options. (line 35)
-* mno-long-calls <2>: ARM Options. (line 167)
-* mno-long-calls <3>: Blackfin Options. (line 117)
-* mno-long-calls <4>: MIPS Options. (line 453)
-* mno-long-calls <5>: V850 Options. (line 10)
-* mno-long-calls: HPPA Options. (line 136)
-* mno-longcall: RS/6000 and PowerPC Options.
- (line 717)
-* mno-longcalls: Xtensa Options. (line 72)
-* mno-low-64k: Blackfin Options. (line 70)
-* mno-lsim <1>: FR30 Options. (line 14)
-* mno-lsim: MCore Options. (line 46)
-* mno-mad: MIPS Options. (line 462)
-* mno-max: DEC Alpha Options. (line 171)
-* mno-mcount-ra-address: MIPS Options. (line 678)
-* mno-mdmx: MIPS Options. (line 279)
-* mno-media: FRV Options. (line 47)
-* mno-memcpy: MIPS Options. (line 447)
-* mno-mfcrf: RS/6000 and PowerPC Options.
- (line 33)
-* mno-mfpgpr: RS/6000 and PowerPC Options.
- (line 33)
-* mno-mips16: MIPS Options. (line 102)
-* mno-mips3d: MIPS Options. (line 285)
-* mno-mmx: i386 and x86-64 Options.
- (line 477)
-* mno-mt: MIPS Options. (line 290)
-* mno-mul-bug-workaround: CRIS Options. (line 31)
-* mno-muladd: FRV Options. (line 53)
-* mno-mulhw: RS/6000 and PowerPC Options.
- (line 430)
-* mno-mult-bug: MN10300 Options. (line 13)
-* mno-multi-cond-exec: FRV Options. (line 183)
-* mno-multiple: RS/6000 and PowerPC Options.
- (line 380)
-* mno-mvcle: S/390 and zSeries Options.
- (line 105)
-* mno-nested-cond-exec: FRV Options. (line 195)
-* mno-optimize-membar: FRV Options. (line 205)
-* mno-opts: MeP Options. (line 93)
-* mno-pack: FRV Options. (line 122)
-* mno-packed-stack: S/390 and zSeries Options.
- (line 54)
-* mno-paired: RS/6000 and PowerPC Options.
- (line 234)
-* mno-paired-single: MIPS Options. (line 273)
-* mno-pic: IA-64 Options. (line 26)
-* mno-plt: MIPS Options. (line 181)
-* mno-popcntb: RS/6000 and PowerPC Options.
- (line 33)
-* mno-popcntd: RS/6000 and PowerPC Options.
- (line 33)
-* mno-power: RS/6000 and PowerPC Options.
- (line 33)
-* mno-power2: RS/6000 and PowerPC Options.
- (line 33)
-* mno-powerpc: RS/6000 and PowerPC Options.
- (line 33)
-* mno-powerpc-gfxopt: RS/6000 and PowerPC Options.
- (line 33)
-* mno-powerpc-gpopt: RS/6000 and PowerPC Options.
- (line 33)
-* mno-powerpc64: RS/6000 and PowerPC Options.
- (line 33)
-* mno-prolog-function: V850 Options. (line 23)
-* mno-prologue-epilogue: CRIS Options. (line 71)
-* mno-prototype: RS/6000 and PowerPC Options.
- (line 605)
-* mno-push-args: i386 and x86-64 Options.
- (line 602)
-* mno-red-zone: i386 and x86-64 Options.
- (line 705)
-* mno-register-names: IA-64 Options. (line 37)
-* mno-regnames: RS/6000 and PowerPC Options.
- (line 711)
-* mno-relax-immediate: MCore Options. (line 19)
-* mno-relocatable: RS/6000 and PowerPC Options.
- (line 461)
-* mno-relocatable-lib: RS/6000 and PowerPC Options.
- (line 472)
-* mno-rtd: M680x0 Options. (line 261)
-* mno-scc: FRV Options. (line 146)
-* mno-sched-ar-data-spec: IA-64 Options. (line 135)
-* mno-sched-ar-in-data-spec: IA-64 Options. (line 156)
-* mno-sched-br-data-spec: IA-64 Options. (line 128)
-* mno-sched-br-in-data-spec: IA-64 Options. (line 149)
-* mno-sched-control-spec: IA-64 Options. (line 142)
-* mno-sched-count-spec-in-critical-path: IA-64 Options. (line 183)
-* mno-sched-in-control-spec: IA-64 Options. (line 163)
-* mno-sched-prefer-non-control-spec-insns: IA-64 Options. (line 176)
-* mno-sched-prefer-non-data-spec-insns: IA-64 Options. (line 169)
-* mno-sched-prolog: ARM Options. (line 32)
-* mno-sdata <1>: IA-64 Options. (line 42)
-* mno-sdata: RS/6000 and PowerPC Options.
- (line 692)
-* mno-sep-data: Blackfin Options. (line 112)
-* mno-serialize-volatile: Xtensa Options. (line 35)
-* mno-short: M680x0 Options. (line 225)
-* mno-side-effects: CRIS Options. (line 46)
-* mno-sim: RX Options. (line 70)
-* mno-single-exit: MMIX Options. (line 66)
-* mno-slow-bytes: MCore Options. (line 35)
-* mno-small-exec: S/390 and zSeries Options.
- (line 80)
-* mno-smartmips: MIPS Options. (line 269)
-* mno-soft-float: DEC Alpha Options. (line 10)
-* mno-space-regs: HPPA Options. (line 45)
-* mno-spe: RS/6000 and PowerPC Options.
- (line 229)
-* mno-specld-anomaly: Blackfin Options. (line 52)
-* mno-split-addresses: MIPS Options. (line 411)
-* mno-sse: i386 and x86-64 Options.
- (line 477)
-* mno-stack-align: CRIS Options. (line 55)
-* mno-stack-bias: SPARC Options. (line 213)
-* mno-strict-align <1>: M680x0 Options. (line 286)
-* mno-strict-align: RS/6000 and PowerPC Options.
- (line 456)
-* mno-string: RS/6000 and PowerPC Options.
- (line 391)
-* mno-sum-in-toc: RS/6000 and PowerPC Options.
- (line 277)
-* mno-sym32: MIPS Options. (line 308)
-* mno-target-align: Xtensa Options. (line 59)
-* mno-text-section-literals: Xtensa Options. (line 47)
-* mno-tls-markers: RS/6000 and PowerPC Options.
- (line 750)
-* mno-toc: RS/6000 and PowerPC Options.
- (line 481)
-* mno-toplevel-symbols: MMIX Options. (line 40)
-* mno-tpf-trace: S/390 and zSeries Options.
- (line 131)
-* mno-unaligned-doubles: SPARC Options. (line 59)
-* mno-uninit-const-in-rodata: MIPS Options. (line 381)
-* mno-update: RS/6000 and PowerPC Options.
- (line 402)
-* mno-v8plus: SPARC Options. (line 156)
-* mno-vis: SPARC Options. (line 163)
-* mno-vliw-branch: FRV Options. (line 170)
-* mno-volatile-asm-stop: IA-64 Options. (line 32)
-* mno-vrsave: RS/6000 and PowerPC Options.
- (line 199)
-* mno-vsx: RS/6000 and PowerPC Options.
- (line 243)
-* mno-wide-bitfields: MCore Options. (line 23)
-* mno-xgot <1>: M680x0 Options. (line 318)
-* mno-xgot: MIPS Options. (line 191)
-* mno-xl-compat: RS/6000 and PowerPC Options.
- (line 312)
-* mno-zero-extend: MMIX Options. (line 27)
-* mnobitfield: M680x0 Options. (line 230)
-* mnoliw: MN10300 Options. (line 60)
-* mnomacsave: SH Options. (line 112)
-* mnominmax: M68hc1x Options. (line 31)
-* mnop-fun-dllimport: i386 and x86-64 Windows Options.
- (line 22)
-* mold-mnemonics: RS/6000 and PowerPC Options.
- (line 104)
-* momit-leaf-frame-pointer <1>: i386 and x86-64 Options.
- (line 650)
-* momit-leaf-frame-pointer: Blackfin Options. (line 40)
-* mone-byte-bool: Darwin Options. (line 92)
-* moptimize-membar: FRV Options. (line 201)
-* MP: Preprocessor Options.
- (line 227)
-* mpa-risc-1-0: HPPA Options. (line 19)
-* mpa-risc-1-1: HPPA Options. (line 19)
-* mpa-risc-2-0: HPPA Options. (line 19)
-* mpack: FRV Options. (line 119)
-* mpacked-stack: S/390 and zSeries Options.
- (line 54)
-* mpadstruct: SH Options. (line 138)
-* mpaired: RS/6000 and PowerPC Options.
- (line 234)
-* mpaired-single: MIPS Options. (line 273)
-* mpc32: i386 and x86-64 Options.
- (line 372)
-* mpc64: i386 and x86-64 Options.
- (line 372)
-* mpc80: i386 and x86-64 Options.
- (line 372)
-* mpcrel: M680x0 Options. (line 278)
-* mpdebug: CRIS Options. (line 35)
-* mpe: RS/6000 and PowerPC Options.
- (line 332)
-* mpe-aligned-commons: i386 and x86-64 Windows Options.
- (line 53)
-* mpic-register: ARM Options. (line 198)
-* mplt: MIPS Options. (line 181)
-* mpoke-function-name: ARM Options. (line 212)
-* mpopcntb: RS/6000 and PowerPC Options.
- (line 33)
-* mpopcntd: RS/6000 and PowerPC Options.
- (line 33)
-* mportable-runtime: HPPA Options. (line 71)
-* mpower: RS/6000 and PowerPC Options.
- (line 33)
-* mpower2: RS/6000 and PowerPC Options.
- (line 33)
-* mpowerpc: RS/6000 and PowerPC Options.
- (line 33)
-* mpowerpc-gfxopt: RS/6000 and PowerPC Options.
- (line 33)
-* mpowerpc-gpopt: RS/6000 and PowerPC Options.
- (line 33)
-* mpowerpc64: RS/6000 and PowerPC Options.
- (line 33)
-* mprefergot: SH Options. (line 145)
-* mpreferred-stack-boundary: i386 and x86-64 Options.
- (line 402)
-* mprioritize-restricted-insns: RS/6000 and PowerPC Options.
- (line 510)
-* mprolog-function: V850 Options. (line 23)
-* mprologue-epilogue: CRIS Options. (line 71)
-* mprototype: RS/6000 and PowerPC Options.
- (line 605)
-* mpt-fixed: SH Options. (line 238)
-* mpush-args <1>: i386 and x86-64 Options.
- (line 602)
-* mpush-args: CRX Options. (line 13)
-* MQ: Preprocessor Options.
- (line 253)
-* mr10k-cache-barrier: MIPS Options. (line 540)
-* mrecip <1>: RS/6000 and PowerPC Options.
- (line 762)
-* mrecip: i386 and x86-64 Options.
- (line 554)
-* mrecip-precision: RS/6000 and PowerPC Options.
- (line 798)
-* mrecip=opt: RS/6000 and PowerPC Options.
- (line 775)
-* mregister-names: IA-64 Options. (line 37)
-* mregnames: RS/6000 and PowerPC Options.
- (line 711)
-* mregparm: i386 and x86-64 Options.
- (line 339)
-* mrelax <1>: SH Options. (line 86)
-* mrelax <2>: MN10300 Options. (line 47)
-* mrelax <3>: H8/300 Options. (line 9)
-* mrelax: RX Options. (line 94)
-* mrelax-immediate: MCore Options. (line 19)
-* mrelax-pic-calls: MIPS Options. (line 665)
-* mrelocatable: RS/6000 and PowerPC Options.
- (line 461)
-* mrelocatable-lib: RS/6000 and PowerPC Options.
- (line 472)
-* mrepeat: MeP Options. (line 96)
-* mreturn-pointer-on-d0: MN10300 Options. (line 37)
-* mrodata: ARC Options. (line 30)
-* mrtd <1>: Function Attributes.
- (line 177)
-* mrtd <2>: i386 and x86-64 Options.
- (line 315)
-* mrtd: M680x0 Options. (line 239)
-* mrtp: VxWorks Options. (line 11)
-* ms <1>: MeP Options. (line 100)
-* ms: H8/300 Options. (line 17)
-* ms2600: H8/300 Options. (line 24)
-* msafe-dma: SPU Options. (line 17)
-* msafe-hints: SPU Options. (line 107)
-* msahf: i386 and x86-64 Options.
- (line 534)
-* msatur: MeP Options. (line 105)
-* msave-acc-in-interrupts: RX Options. (line 108)
-* mscc: FRV Options. (line 140)
-* msched-ar-data-spec: IA-64 Options. (line 135)
-* msched-ar-in-data-spec: IA-64 Options. (line 156)
-* msched-br-data-spec: IA-64 Options. (line 128)
-* msched-br-in-data-spec: IA-64 Options. (line 149)
-* msched-control-spec: IA-64 Options. (line 142)
-* msched-costly-dep: RS/6000 and PowerPC Options.
- (line 517)
-* msched-count-spec-in-critical-path: IA-64 Options. (line 183)
-* msched-fp-mem-deps-zero-cost: IA-64 Options. (line 200)
-* msched-in-control-spec: IA-64 Options. (line 163)
-* msched-max-memory-insns: IA-64 Options. (line 209)
-* msched-max-memory-insns-hard-limit: IA-64 Options. (line 215)
-* msched-prefer-non-control-spec-insns: IA-64 Options. (line 176)
-* msched-prefer-non-data-spec-insns: IA-64 Options. (line 169)
-* msched-spec-ldc: IA-64 Options. (line 192)
-* msched-stop-bits-after-every-cycle: IA-64 Options. (line 196)
-* mschedule: HPPA Options. (line 78)
-* mscore5: Score Options. (line 25)
-* mscore5u: Score Options. (line 28)
-* mscore7: Score Options. (line 31)
-* mscore7d: Score Options. (line 34)
-* msda: V850 Options. (line 40)
-* msdata <1>: IA-64 Options. (line 42)
-* msdata: RS/6000 and PowerPC Options.
- (line 679)
-* msdata=data: RS/6000 and PowerPC Options.
- (line 684)
-* msdata=default: RS/6000 and PowerPC Options.
- (line 679)
-* msdata=eabi: RS/6000 and PowerPC Options.
- (line 659)
-* msdata=none <1>: RS/6000 and PowerPC Options.
- (line 692)
-* msdata=none: M32R/D Options. (line 40)
-* msdata=sdata: M32R/D Options. (line 49)
-* msdata=sysv: RS/6000 and PowerPC Options.
- (line 670)
-* msdata=use: M32R/D Options. (line 53)
-* msdram <1>: MeP Options. (line 110)
-* msdram: Blackfin Options. (line 163)
-* msecure-plt: RS/6000 and PowerPC Options.
- (line 209)
-* msel-sched-dont-check-control-spec: IA-64 Options. (line 205)
-* msep-data: Blackfin Options. (line 106)
-* mserialize-volatile: Xtensa Options. (line 35)
-* mshared-library-id: Blackfin Options. (line 99)
-* mshort <1>: M68hc1x Options. (line 40)
-* mshort: M680x0 Options. (line 219)
-* msign-extend-enabled: LM32 Options. (line 18)
-* msim <1>: RX Options. (line 70)
-* msim <2>: RS/6000 and PowerPC Options.
- (line 615)
-* msim <3>: M32C Options. (line 13)
-* msim <4>: MeP Options. (line 114)
-* msim <5>: Xstormy16 Options. (line 9)
-* msim: Blackfin Options. (line 33)
-* msimnovec: MeP Options. (line 117)
-* msimple-fpu: RS/6000 and PowerPC Options.
- (line 365)
-* msingle-exit: MMIX Options. (line 66)
-* msingle-float <1>: RS/6000 and PowerPC Options.
- (line 361)
-* msingle-float: MIPS Options. (line 233)
-* msingle-pic-base <1>: RS/6000 and PowerPC Options.
- (line 504)
-* msingle-pic-base: ARM Options. (line 192)
-* msio: HPPA Options. (line 105)
-* mslow-bytes: MCore Options. (line 35)
-* msmall-data: DEC Alpha Options. (line 195)
-* msmall-data-limit: RX Options. (line 47)
-* msmall-divides: MicroBlaze Options. (line 38)
-* msmall-exec: S/390 and zSeries Options.
- (line 80)
-* msmall-mem: SPU Options. (line 35)
-* msmall-model: FR30 Options. (line 9)
-* msmall-text: DEC Alpha Options. (line 213)
-* msmartmips: MIPS Options. (line 269)
-* msoft-float <1>: M680x0 Options. (line 202)
-* msoft-float <2>: PDP-11 Options. (line 13)
-* msoft-float <3>: S/390 and zSeries Options.
- (line 11)
-* msoft-float <4>: MicroBlaze Options. (line 7)
-* msoft-float <5>: i386 and x86-64 Options.
- (line 234)
-* msoft-float <6>: DEC Alpha Options. (line 10)
-* msoft-float <7>: HPPA Options. (line 91)
-* msoft-float <8>: SPARC Options. (line 25)
-* msoft-float <9>: ARM Options. (line 60)
-* msoft-float <10>: MIPS Options. (line 229)
-* msoft-float <11>: RS/6000 and PowerPC Options.
- (line 355)
-* msoft-float: FRV Options. (line 22)
-* msoft-quad-float: SPARC Options. (line 45)
-* msoft-reg-count: M68hc1x Options. (line 43)
-* mspace <1>: V850 Options. (line 30)
-* mspace: SH Options. (line 142)
-* mspe: RS/6000 and PowerPC Options.
- (line 229)
-* mspecld-anomaly: Blackfin Options. (line 47)
-* msplit-addresses: MIPS Options. (line 411)
-* msse: i386 and x86-64 Options.
- (line 477)
-* msse2avx: i386 and x86-64 Options.
- (line 668)
-* msseregparm: i386 and x86-64 Options.
- (line 350)
-* mstack-align: CRIS Options. (line 55)
-* mstack-bias: SPARC Options. (line 213)
-* mstack-check-l1: Blackfin Options. (line 73)
-* mstack-guard: S/390 and zSeries Options.
- (line 156)
-* mstack-increment: MCore Options. (line 50)
-* mstack-size: S/390 and zSeries Options.
- (line 156)
-* mstackrealign: i386 and x86-64 Options.
- (line 393)
-* mstdmain: SPU Options. (line 40)
-* mstrict-align <1>: RS/6000 and PowerPC Options.
- (line 456)
-* mstrict-align: M680x0 Options. (line 286)
-* mstring: RS/6000 and PowerPC Options.
- (line 391)
-* mstringop-strategy=ALG: i386 and x86-64 Options.
- (line 642)
-* mstructure-size-boundary: ARM Options. (line 147)
-* msvr4-struct-return: RS/6000 and PowerPC Options.
- (line 579)
-* msym32: MIPS Options. (line 308)
-* msynci: MIPS Options. (line 650)
-* MT: Preprocessor Options.
- (line 239)
-* mtarget-align: Xtensa Options. (line 59)
-* mtda: V850 Options. (line 34)
-* mtext: ARC Options. (line 30)
-* mtext-section-literals: Xtensa Options. (line 47)
-* mtf: MeP Options. (line 121)
-* mthread: i386 and x86-64 Windows Options.
- (line 26)
-* mthreads: i386 and x86-64 Options.
- (line 617)
-* mthumb: ARM Options. (line 233)
-* mthumb-interwork: ARM Options. (line 25)
-* mtiny-stack: AVR Options. (line 40)
-* mtiny=: MeP Options. (line 125)
-* mTLS: FRV Options. (line 72)
-* mtls: FRV Options. (line 75)
-* mtls-direct-seg-refs: i386 and x86-64 Options.
- (line 658)
-* mtls-markers: RS/6000 and PowerPC Options.
- (line 750)
-* mtls-size: IA-64 Options. (line 112)
-* mtoc: RS/6000 and PowerPC Options.
- (line 481)
-* mtomcat-stats: FRV Options. (line 209)
-* mtoplevel-symbols: MMIX Options. (line 40)
-* mtp: ARM Options. (line 270)
-* mtpcs-frame: ARM Options. (line 243)
-* mtpcs-leaf-frame: ARM Options. (line 249)
-* mtpf-trace: S/390 and zSeries Options.
- (line 131)
-* mtrap-precision: DEC Alpha Options. (line 109)
-* mtune <1>: i386 and x86-64 Options.
- (line 10)
-* mtune <2>: ARM Options. (line 98)
-* mtune <3>: RS/6000 and PowerPC Options.
- (line 168)
-* mtune <4>: DEC Alpha Options. (line 267)
-* mtune <5>: SPARC Options. (line 143)
-* mtune <6>: IA-64 Options. (line 116)
-* mtune <7>: MN10300 Options. (line 31)
-* mtune <8>: MIPS Options. (line 62)
-* mtune <9>: S/390 and zSeries Options.
- (line 124)
-* mtune <10>: CRIS Options. (line 16)
-* mtune: M680x0 Options. (line 69)
-* muclibc: GNU/Linux Options. (line 13)
-* muls: Score Options. (line 18)
-* multcost=NUMBER: SH Options. (line 155)
-* multi_module: Darwin Options. (line 199)
-* multilib-library-pic: FRV Options. (line 89)
-* multiply-enabled: LM32 Options. (line 15)
-* multiply_defined: Darwin Options. (line 199)
-* multiply_defined_unused: Darwin Options. (line 199)
-* munaligned-doubles: SPARC Options. (line 59)
-* municode: i386 and x86-64 Windows Options.
- (line 30)
-* muninit-const-in-rodata: MIPS Options. (line 381)
-* munix: VAX Options. (line 9)
-* munix-asm: PDP-11 Options. (line 68)
-* munsafe-dma: SPU Options. (line 17)
-* mupdate: RS/6000 and PowerPC Options.
- (line 402)
-* muser-enabled: LM32 Options. (line 21)
-* musermode: SH Options. (line 150)
-* mv850: V850 Options. (line 49)
-* mv850e: V850 Options. (line 81)
-* mv850e1: V850 Options. (line 73)
-* mv850e2: V850 Options. (line 69)
-* mv850e2v3: V850 Options. (line 64)
-* mv850es: V850 Options. (line 77)
-* mv8plus: SPARC Options. (line 156)
-* mveclibabi <1>: RS/6000 and PowerPC Options.
- (line 807)
-* mveclibabi: i386 and x86-64 Options.
- (line 571)
-* mvect8-ret-in-mem: i386 and x86-64 Options.
- (line 360)
-* mvis: SPARC Options. (line 163)
-* mvliw-branch: FRV Options. (line 164)
-* mvms-return-codes <1>: IA-64/VMS Options. (line 9)
-* mvms-return-codes: DEC Alpha/VMS Options.
- (line 9)
-* mvolatile-asm-stop: IA-64 Options. (line 32)
-* mvr4130-align: MIPS Options. (line 639)
-* mvrsave: RS/6000 and PowerPC Options.
- (line 199)
-* mvsx: RS/6000 and PowerPC Options.
- (line 243)
-* mvxworks: RS/6000 and PowerPC Options.
- (line 636)
-* mvzeroupper: i386 and x86-64 Options.
- (line 520)
-* mwarn-cell-microcode: RS/6000 and PowerPC Options.
- (line 205)
-* mwarn-dynamicstack: S/390 and zSeries Options.
- (line 150)
-* mwarn-framesize: S/390 and zSeries Options.
- (line 142)
-* mwarn-reloc: SPU Options. (line 10)
-* mwide-bitfields: MCore Options. (line 23)
-* mwin32: i386 and x86-64 Windows Options.
- (line 35)
-* mwindows: i386 and x86-64 Windows Options.
- (line 41)
-* mword-relocations: ARM Options. (line 278)
-* mwords-little-endian: ARM Options. (line 71)
-* mxgot <1>: MIPS Options. (line 191)
-* mxgot: M680x0 Options. (line 318)
-* mxilinx-fpu: RS/6000 and PowerPC Options.
- (line 375)
-* mxl-barrel-shift: MicroBlaze Options. (line 32)
-* mxl-compat: RS/6000 and PowerPC Options.
- (line 312)
-* mxl-float-convert: MicroBlaze Options. (line 50)
-* mxl-float-sqrt: MicroBlaze Options. (line 53)
-* mxl-gp-opt: MicroBlaze Options. (line 44)
-* mxl-multiply-high: MicroBlaze Options. (line 47)
-* mxl-pattern-compare: MicroBlaze Options. (line 35)
-* mxl-soft-div: MicroBlaze Options. (line 29)
-* mxl-soft-mul: MicroBlaze Options. (line 26)
-* mxl-stack-check: MicroBlaze Options. (line 41)
-* myellowknife: RS/6000 and PowerPC Options.
- (line 631)
-* mzarch: S/390 and zSeries Options.
- (line 95)
-* mzda: V850 Options. (line 45)
-* mzero-extend: MMIX Options. (line 27)
-* no-canonical-prefixes: Overall Options. (line 343)
-* no-integrated-cpp: C Dialect Options. (line 272)
-* no_dead_strip_inits_and_terms: Darwin Options. (line 199)
-* noall_load: Darwin Options. (line 199)
-* nocpp: MIPS Options. (line 477)
-* nodefaultlibs: Link Options. (line 62)
-* nofixprebinding: Darwin Options. (line 199)
-* nofpu: RX Options. (line 17)
-* nolibdld: HPPA Options. (line 188)
-* nomultidefs: Darwin Options. (line 199)
-* non-static: VxWorks Options. (line 16)
-* noprebind: Darwin Options. (line 199)
-* noseglinkedit: Darwin Options. (line 199)
-* nostartfiles: Link Options. (line 57)
-* nostdinc: Preprocessor Options.
- (line 385)
-* nostdinc++ <1>: Preprocessor Options.
- (line 390)
-* nostdinc++: C++ Dialect Options.
- (line 322)
-* nostdlib: Link Options. (line 73)
-* O: Optimize Options. (line 39)
-* o <1>: Preprocessor Options.
- (line 75)
-* o: Overall Options. (line 192)
-* O0: Optimize Options. (line 126)
-* O1: Optimize Options. (line 39)
-* O2: Optimize Options. (line 82)
-* O3: Optimize Options. (line 119)
-* Ofast: Optimize Options. (line 140)
-* Os: Optimize Options. (line 130)
-* p: Debugging Options. (line 295)
-* P: Preprocessor Options.
- (line 603)
-* pagezero_size: Darwin Options. (line 199)
-* param: Optimize Options. (line 2264)
-* pass-exit-codes: Overall Options. (line 150)
-* pedantic <1>: Standards. (line 16)
-* pedantic <2>: Warning Options. (line 72)
-* pedantic <3>: Preprocessor Options.
- (line 163)
-* pedantic <4>: C Extensions. (line 6)
-* pedantic <5>: Alternate Keywords. (line 30)
-* pedantic: Warnings and Errors.
- (line 25)
-* pedantic-errors <1>: Non-bugs. (line 216)
-* pedantic-errors <2>: Warning Options. (line 114)
-* pedantic-errors <3>: Standards. (line 16)
-* pedantic-errors <4>: Warnings and Errors.
- (line 25)
-* pedantic-errors: Preprocessor Options.
- (line 168)
-* pg: Debugging Options. (line 301)
-* pie: Link Options. (line 95)
-* pipe: Overall Options. (line 215)
-* prebind: Darwin Options. (line 199)
-* prebind_all_twolevel_modules: Darwin Options. (line 199)
-* print-file-name: Debugging Options. (line 1140)
-* print-libgcc-file-name: Debugging Options. (line 1170)
-* print-multi-directory: Debugging Options. (line 1146)
-* print-multi-lib: Debugging Options. (line 1151)
-* print-multi-os-directory: Debugging Options. (line 1158)
-* print-objc-runtime-info: Objective-C and Objective-C++ Dialect Options.
- (line 203)
-* print-prog-name: Debugging Options. (line 1167)
-* print-search-dirs: Debugging Options. (line 1178)
-* print-sysroot: Debugging Options. (line 1191)
-* print-sysroot-headers-suffix: Debugging Options. (line 1198)
-* private_bundle: Darwin Options. (line 199)
-* pthread <1>: Solaris 2 Options. (line 37)
-* pthread: RS/6000 and PowerPC Options.
- (line 757)
-* pthreads: Solaris 2 Options. (line 31)
-* Q: Debugging Options. (line 307)
-* Qn: System V Options. (line 18)
-* Qy: System V Options. (line 14)
-* rdynamic: Link Options. (line 101)
-* read_only_relocs: Darwin Options. (line 199)
-* remap: Preprocessor Options.
- (line 651)
-* s: Link Options. (line 108)
-* S <1>: Link Options. (line 20)
-* S: Overall Options. (line 175)
-* save-temps: Debugging Options. (line 1048)
-* save-temps=obj: Debugging Options. (line 1074)
-* sectalign: Darwin Options. (line 199)
-* sectcreate: Darwin Options. (line 199)
-* sectobjectsymbols: Darwin Options. (line 199)
-* sectorder: Darwin Options. (line 199)
-* seg1addr: Darwin Options. (line 199)
-* seg_addr_table: Darwin Options. (line 199)
-* seg_addr_table_filename: Darwin Options. (line 199)
-* segaddr: Darwin Options. (line 199)
-* seglinkedit: Darwin Options. (line 199)
-* segprot: Darwin Options. (line 199)
-* segs_read_only_addr: Darwin Options. (line 199)
-* segs_read_write_addr: Darwin Options. (line 199)
-* shared: Link Options. (line 117)
-* shared-libgcc: Link Options. (line 125)
-* sim: CRIS Options. (line 95)
-* sim2: CRIS Options. (line 101)
-* single_module: Darwin Options. (line 199)
-* specs: Directory Options. (line 89)
-* static <1>: Darwin Options. (line 199)
-* static <2>: HPPA Options. (line 192)
-* static: Link Options. (line 112)
-* static-libgcc: Link Options. (line 125)
-* std <1>: C Dialect Options. (line 47)
-* std <2>: Other Builtins. (line 22)
-* std <3>: Standards. (line 16)
-* std: Non-bugs. (line 107)
-* std=: Preprocessor Options.
- (line 326)
-* sub_library: Darwin Options. (line 199)
-* sub_umbrella: Darwin Options. (line 199)
-* symbolic: Link Options. (line 172)
-* sysroot: Directory Options. (line 97)
-* T: Link Options. (line 178)
-* target-help <1>: Overall Options. (line 230)
-* target-help: Preprocessor Options.
- (line 656)
-* threads <1>: HPPA Options. (line 205)
-* threads: Solaris 2 Options. (line 25)
-* time: Debugging Options. (line 1089)
-* tno-android-cc: GNU/Linux Options. (line 31)
-* tno-android-ld: GNU/Linux Options. (line 35)
-* traditional <1>: C Dialect Options. (line 284)
-* traditional: Incompatibilities. (line 6)
-* traditional-cpp <1>: Preprocessor Options.
- (line 634)
-* traditional-cpp: C Dialect Options. (line 284)
-* trigraphs <1>: C Dialect Options. (line 268)
-* trigraphs: Preprocessor Options.
- (line 638)
-* twolevel_namespace: Darwin Options. (line 199)
-* u: Link Options. (line 211)
-* U: Preprocessor Options.
- (line 57)
-* umbrella: Darwin Options. (line 199)
-* undef: Preprocessor Options.
- (line 61)
-* undefined: Darwin Options. (line 199)
-* unexported_symbols_list: Darwin Options. (line 199)
-* v <1>: Overall Options. (line 203)
-* v: Preprocessor Options.
- (line 660)
-* version <1>: Preprocessor Options.
- (line 673)
-* version: Overall Options. (line 351)
-* W: Incompatibilities. (line 64)
-* w: Preprocessor Options.
- (line 159)
-* W: Warning Options. (line 1385)
-* w: Warning Options. (line 25)
-* Wa: Assembler Options. (line 9)
-* Wabi: C++ Dialect Options.
- (line 336)
-* Waddress: Warning Options. (line 1214)
-* Waggregate-return: Warning Options. (line 1232)
-* Wall <1>: Standard Libraries. (line 6)
-* Wall <2>: Preprocessor Options.
- (line 81)
-* Wall: Warning Options. (line 118)
-* Warray-bounds: Warning Options. (line 877)
-* Wassign-intercept: Objective-C and Objective-C++ Dialect Options.
- (line 157)
-* Wattributes: Warning Options. (line 1237)
-* Wbad-function-cast: Warning Options. (line 1100)
-* Wbuiltin-macro-redefined: Warning Options. (line 1243)
-* Wcast-align: Warning Options. (line 1131)
-* Wcast-qual: Warning Options. (line 1115)
-* Wchar-subscripts: Warning Options. (line 207)
-* Wclobbered: Warning Options. (line 1151)
-* Wcomment <1>: Warning Options. (line 212)
-* Wcomment: Preprocessor Options.
- (line 89)
-* Wcomments: Preprocessor Options.
- (line 89)
-* Wconversion: Warning Options. (line 1155)
-* Wconversion-null: Warning Options. (line 1173)
-* Wcoverage-mismatch: Language Independent Options.
- (line 42)
-* Wctor-dtor-privacy: C++ Dialect Options.
- (line 446)
-* Wdeclaration-after-statement: Warning Options. (line 1009)
-* Wdeprecated: Warning Options. (line 1372)
-* Wdeprecated-declarations: Warning Options. (line 1376)
-* Wdisabled-optimization: Warning Options. (line 1511)
-* Wdiv-by-zero: Warning Options. (line 882)
-* Wdouble-promotion: Warning Options. (line 222)
-* weak_reference_mismatches: Darwin Options. (line 199)
-* Weffc++: C++ Dialect Options.
- (line 479)
-* Wempty-body: Warning Options. (line 1181)
-* Wendif-labels <1>: Preprocessor Options.
- (line 136)
-* Wendif-labels: Warning Options. (line 1019)
-* Wenum-compare: Warning Options. (line 1185)
-* Werror <1>: Preprocessor Options.
- (line 149)
-* Werror: Warning Options. (line 28)
-* Werror=: Warning Options. (line 31)
-* Wextra: Warning Options. (line 1286)
-* Wfatal-errors: Warning Options. (line 48)
-* Wfloat-equal: Warning Options. (line 909)
-* Wformat <1>: Warning Options. (line 1304)
-* Wformat: Function Attributes.
- (line 420)
-* Wformat-contains-nul: Warning Options. (line 279)
-* Wformat-extra-args: Warning Options. (line 283)
-* Wformat-nonliteral <1>: Warning Options. (line 301)
-* Wformat-nonliteral: Function Attributes.
- (line 485)
-* Wformat-security: Warning Options. (line 306)
-* Wformat-y2k: Warning Options. (line 275)
-* Wformat-zero-length: Warning Options. (line 297)
-* Wformat=2: Warning Options. (line 317)
-* Wframe-larger-than: Warning Options. (line 1065)
-* whatsloaded: Darwin Options. (line 199)
-* whyload: Darwin Options. (line 199)
-* Wignored-qualifiers: Warning Options. (line 356)
-* Wimplicit: Warning Options. (line 352)
-* Wimplicit-function-declaration: Warning Options. (line 346)
-* Wimplicit-int: Warning Options. (line 342)
-* Winit-self: Warning Options. (line 329)
-* Winline <1>: Inline. (line 63)
-* Winline: Warning Options. (line 1442)
-* Wint-to-pointer-cast: Warning Options. (line 1469)
-* Winvalid-offsetof: Warning Options. (line 1455)
-* Winvalid-pch: Warning Options. (line 1486)
-* Wjump-misses-init: Warning Options. (line 1190)
-* Wl: Link Options. (line 203)
-* Wlarger-than-LEN: Warning Options. (line 1062)
-* Wlarger-than=LEN: Warning Options. (line 1062)
-* Wlogical-op: Warning Options. (line 1227)
-* Wlong-long: Warning Options. (line 1490)
-* Wmain: Warning Options. (line 367)
-* Wmaybe-uninitialized: Warning Options. (line 711)
-* Wmissing-braces: Warning Options. (line 374)
-* Wmissing-declarations: Warning Options. (line 1278)
-* Wmissing-field-initializers: Warning Options. (line 1286)
-* Wmissing-format-attribute: Warning Options. (line 1304)
-* Wmissing-include-dirs: Warning Options. (line 384)
-* Wmissing-parameter-type: Warning Options. (line 1264)
-* Wmissing-prototypes: Warning Options. (line 1272)
-* Wmultichar: Warning Options. (line 1323)
-* Wnested-externs: Warning Options. (line 1439)
-* Wno-abi: C++ Dialect Options.
- (line 336)
-* Wno-address: Warning Options. (line 1214)
-* Wno-aggregate-return: Warning Options. (line 1232)
-* Wno-all: Warning Options. (line 118)
-* Wno-array-bounds: Warning Options. (line 877)
-* Wno-assign-intercept: Objective-C and Objective-C++ Dialect Options.
- (line 157)
-* Wno-attributes: Warning Options. (line 1237)
-* Wno-bad-function-cast: Warning Options. (line 1100)
-* Wno-builtin-macro-redefined: Warning Options. (line 1243)
-* Wno-cast-align: Warning Options. (line 1131)
-* Wno-cast-qual: Warning Options. (line 1115)
-* Wno-char-subscripts: Warning Options. (line 207)
-* Wno-clobbered: Warning Options. (line 1151)
-* Wno-comment: Warning Options. (line 212)
-* Wno-conversion: Warning Options. (line 1155)
-* Wno-conversion-null: Warning Options. (line 1173)
-* Wno-ctor-dtor-privacy: C++ Dialect Options.
- (line 446)
-* Wno-declaration-after-statement: Warning Options. (line 1009)
-* Wno-deprecated: Warning Options. (line 1372)
-* Wno-deprecated-declarations: Warning Options. (line 1376)
-* Wno-disabled-optimization: Warning Options. (line 1511)
-* Wno-div-by-zero: Warning Options. (line 882)
-* Wno-double-promotion: Warning Options. (line 222)
-* Wno-effc++: C++ Dialect Options.
- (line 479)
-* Wno-empty-body: Warning Options. (line 1181)
-* Wno-endif-labels: Warning Options. (line 1019)
-* Wno-enum-compare: Warning Options. (line 1185)
-* Wno-error: Warning Options. (line 28)
-* Wno-error=: Warning Options. (line 31)
-* Wno-extra: Warning Options. (line 1286)
-* Wno-fatal-errors: Warning Options. (line 48)
-* Wno-float-equal: Warning Options. (line 909)
-* Wno-format: Warning Options. (line 240)
-* Wno-format-contains-nul: Warning Options. (line 279)
-* Wno-format-extra-args: Warning Options. (line 283)
-* Wno-format-nonliteral: Warning Options. (line 301)
-* Wno-format-security: Warning Options. (line 306)
-* Wno-format-y2k: Warning Options. (line 275)
-* Wno-format-zero-length: Warning Options. (line 297)
-* Wno-format=2: Warning Options. (line 317)
-* Wno-ignored-qualifiers: Warning Options. (line 356)
-* Wno-implicit: Warning Options. (line 352)
-* Wno-implicit-function-declaration: Warning Options. (line 346)
-* Wno-implicit-int: Warning Options. (line 342)
-* Wno-init-self: Warning Options. (line 329)
-* Wno-inline: Warning Options. (line 1442)
-* Wno-int-to-pointer-cast: Warning Options. (line 1469)
-* Wno-invalid-offsetof: Warning Options. (line 1455)
-* Wno-invalid-pch: Warning Options. (line 1486)
-* Wno-jump-misses-init: Warning Options. (line 1190)
-* Wno-logical-op: Warning Options. (line 1227)
-* Wno-long-long: Warning Options. (line 1490)
-* Wno-main: Warning Options. (line 367)
-* Wno-maybe-uninitialized: Warning Options. (line 711)
-* Wno-missing-braces: Warning Options. (line 374)
-* Wno-missing-declarations: Warning Options. (line 1278)
-* Wno-missing-field-initializers: Warning Options. (line 1286)
-* Wno-missing-format-attribute: Warning Options. (line 1304)
-* Wno-missing-include-dirs: Warning Options. (line 384)
-* Wno-missing-parameter-type: Warning Options. (line 1264)
-* Wno-missing-prototypes: Warning Options. (line 1272)
-* Wno-mudflap: Warning Options. (line 1531)
-* Wno-multichar: Warning Options. (line 1323)
-* Wno-nested-externs: Warning Options. (line 1439)
-* Wno-noexcept: C++ Dialect Options.
- (line 451)
-* Wno-non-template-friend: C++ Dialect Options.
- (line 516)
-* Wno-non-virtual-dtor: C++ Dialect Options.
- (line 457)
-* Wno-nonnull: Warning Options. (line 322)
-* Wno-old-style-cast: C++ Dialect Options.
- (line 532)
-* Wno-old-style-declaration: Warning Options. (line 1254)
-* Wno-old-style-definition: Warning Options. (line 1260)
-* Wno-overflow: Warning Options. (line 1382)
-* Wno-overlength-strings: Warning Options. (line 1535)
-* Wno-overloaded-virtual: C++ Dialect Options.
- (line 538)
-* Wno-override-init: Warning Options. (line 1385)
-* Wno-packed: Warning Options. (line 1393)
-* Wno-packed-bitfield-compat: Warning Options. (line 1410)
-* Wno-padded: Warning Options. (line 1427)
-* Wno-parentheses: Warning Options. (line 387)
-* Wno-pedantic-ms-format: Warning Options. (line 1080)
-* Wno-pmf-conversions <1>: Bound member functions.
- (line 35)
-* Wno-pmf-conversions: C++ Dialect Options.
- (line 557)
-* Wno-pointer-arith: Warning Options. (line 1086)
-* Wno-pointer-sign: Warning Options. (line 1520)
-* Wno-pointer-to-int-cast: Warning Options. (line 1482)
-* Wno-pragmas: Warning Options. (line 762)
-* Wno-protocol: Objective-C and Objective-C++ Dialect Options.
- (line 161)
-* Wno-real-conversion: Warning Options. (line 1177)
-* Wno-redundant-decls: Warning Options. (line 1434)
-* Wno-reorder: C++ Dialect Options.
- (line 463)
-* Wno-return-type: Warning Options. (line 527)
-* Wno-ripa-opt-mismatch: Warning Options. (line 542)
-* Wno-selector: Objective-C and Objective-C++ Dialect Options.
- (line 171)
-* Wno-self-assign: Warning Options. (line 483)
-* Wno-self-assign-non-pod: Warning Options. (line 506)
-* Wno-sequence-point: Warning Options. (line 437)
-* Wno-shadow: Warning Options. (line 1023)
-* Wno-shadow-compatible-local: Warning Options. (line 1034)
-* Wno-shadow-local: Warning Options. (line 1030)
-* Wno-sign-compare: Warning Options. (line 1201)
-* Wno-sign-conversion: Warning Options. (line 1208)
-* Wno-sign-promo: C++ Dialect Options.
- (line 561)
-* Wno-stack-protector: Warning Options. (line 1526)
-* Wno-strict-aliasing: Warning Options. (line 767)
-* Wno-strict-aliasing=n: Warning Options. (line 775)
-* Wno-strict-null-sentinel: C++ Dialect Options.
- (line 509)
-* Wno-strict-overflow: Warning Options. (line 808)
-* Wno-strict-prototypes: Warning Options. (line 1248)
-* Wno-strict-selector-match: Objective-C and Objective-C++ Dialect Options.
- (line 183)
-* Wno-suggest-attribute=: Warning Options. (line 859)
-* Wno-suggest-attribute=const: Warning Options. (line 865)
-* Wno-suggest-attribute=noreturn: Warning Options. (line 865)
-* Wno-suggest-attribute=pure: Warning Options. (line 865)
-* Wno-switch: Warning Options. (line 550)
-* Wno-switch-default: Warning Options. (line 558)
-* Wno-switch-enum: Warning Options. (line 561)
-* Wno-sync-nand: Warning Options. (line 570)
-* Wno-system-headers: Warning Options. (line 887)
-* Wno-thread-safety: Warning Options. (line 575)
-* Wno-traditional: Warning Options. (line 924)
-* Wno-traditional-conversion: Warning Options. (line 1001)
-* Wno-trampolines: Warning Options. (line 898)
-* Wno-trigraphs: Warning Options. (line 611)
-* Wno-type-limits: Warning Options. (line 1093)
-* Wno-undeclared-selector: Objective-C and Objective-C++ Dialect Options.
- (line 191)
-* Wno-undef: Warning Options. (line 1016)
-* Wno-uninitialized: Warning Options. (line 688)
-* Wno-unknown-pragmas: Warning Options. (line 755)
-* Wno-unsafe-loop-optimizations: Warning Options. (line 1074)
-* Wno-unused: Warning Options. (line 681)
-* Wno-unused-but-set-parameter: Warning Options. (line 616)
-* Wno-unused-but-set-variable: Warning Options. (line 625)
-* Wno-unused-function: Warning Options. (line 635)
-* Wno-unused-label: Warning Options. (line 640)
-* Wno-unused-parameter: Warning Options. (line 647)
-* Wno-unused-result: Warning Options. (line 654)
-* Wno-unused-value: Warning Options. (line 671)
-* Wno-unused-variable: Warning Options. (line 659)
-* Wno-variadic-macros: Warning Options. (line 1495)
-* Wno-vla: Warning Options. (line 1501)
-* Wno-volatile-register-var: Warning Options. (line 1505)
-* Wno-write-strings: Warning Options. (line 1137)
-* Wnoexcept: C++ Dialect Options.
- (line 451)
-* Wnon-template-friend: C++ Dialect Options.
- (line 516)
-* Wnon-virtual-dtor: C++ Dialect Options.
- (line 457)
-* Wnonnull: Warning Options. (line 322)
-* Wnormalized=: Warning Options. (line 1329)
-* Wold-style-cast: C++ Dialect Options.
- (line 532)
-* Wold-style-declaration: Warning Options. (line 1254)
-* Wold-style-definition: Warning Options. (line 1260)
-* Woverflow: Warning Options. (line 1382)
-* Woverlength-strings: Warning Options. (line 1535)
-* Woverloaded-virtual: C++ Dialect Options.
- (line 538)
-* Woverride-init: Warning Options. (line 1385)
-* Wp: Preprocessor Options.
- (line 14)
-* Wpacked: Warning Options. (line 1393)
-* Wpacked-bitfield-compat: Warning Options. (line 1410)
-* Wpadded: Warning Options. (line 1427)
-* Wparentheses: Warning Options. (line 387)
-* Wpedantic-ms-format: Warning Options. (line 1080)
-* Wpmf-conversions: C++ Dialect Options.
- (line 557)
-* Wpointer-arith <1>: Pointer Arith. (line 13)
-* Wpointer-arith: Warning Options. (line 1086)
-* Wpointer-sign: Warning Options. (line 1520)
-* Wpointer-to-int-cast: Warning Options. (line 1482)
-* Wpragmas: Warning Options. (line 762)
-* Wprotocol: Objective-C and Objective-C++ Dialect Options.
- (line 161)
-* wrapper: Overall Options. (line 354)
-* Wreal-conversion: Warning Options. (line 1177)
-* Wredundant-decls: Warning Options. (line 1434)
-* Wreorder: C++ Dialect Options.
- (line 463)
-* Wreturn-type: Warning Options. (line 527)
-* Wripa-opt-mismatch: Warning Options. (line 542)
-* Wselector: Objective-C and Objective-C++ Dialect Options.
- (line 171)
-* Wself-assign: Warning Options. (line 483)
-* Wself-assign-non-pod: Warning Options. (line 506)
-* Wsequence-point: Warning Options. (line 437)
-* Wshadow: Warning Options. (line 1023)
-* Wshadow-compatible-local: Warning Options. (line 1034)
-* Wshadow-local: Warning Options. (line 1030)
-* Wsign-compare: Warning Options. (line 1201)
-* Wsign-conversion: Warning Options. (line 1208)
-* Wsign-promo: C++ Dialect Options.
- (line 561)
-* Wstack-protector: Warning Options. (line 1526)
-* Wstrict-aliasing: Warning Options. (line 767)
-* Wstrict-aliasing=n: Warning Options. (line 775)
-* Wstrict-null-sentinel: C++ Dialect Options.
- (line 509)
-* Wstrict-overflow: Warning Options. (line 808)
-* Wstrict-prototypes: Warning Options. (line 1248)
-* Wstrict-selector-match: Objective-C and Objective-C++ Dialect Options.
- (line 183)
-* Wsuggest-attribute=: Warning Options. (line 859)
-* Wsuggest-attribute=const: Warning Options. (line 865)
-* Wsuggest-attribute=noreturn: Warning Options. (line 865)
-* Wsuggest-attribute=pure: Warning Options. (line 865)
-* Wswitch: Warning Options. (line 550)
-* Wswitch-default: Warning Options. (line 558)
-* Wswitch-enum: Warning Options. (line 561)
-* Wsync-nand: Warning Options. (line 570)
-* Wsystem-headers <1>: Preprocessor Options.
- (line 153)
-* Wsystem-headers: Warning Options. (line 887)
-* Wthread-safety: Warning Options. (line 575)
-* Wtraditional <1>: Warning Options. (line 924)
-* Wtraditional: Preprocessor Options.
- (line 106)
-* Wtraditional-conversion: Warning Options. (line 1001)
-* Wtrampolines: Warning Options. (line 898)
-* Wtrigraphs <1>: Preprocessor Options.
- (line 94)
-* Wtrigraphs: Warning Options. (line 611)
-* Wtype-limits: Warning Options. (line 1093)
-* Wundeclared-selector: Objective-C and Objective-C++ Dialect Options.
- (line 191)
-* Wundef <1>: Preprocessor Options.
- (line 112)
-* Wundef: Warning Options. (line 1016)
-* Wuninitialized: Warning Options. (line 688)
-* Wunknown-pragmas: Warning Options. (line 755)
-* Wunsafe-loop-optimizations: Warning Options. (line 1074)
-* Wunsuffixed-float-constants: Warning Options. (line 1550)
-* Wunused: Warning Options. (line 681)
-* Wunused-but-set-parameter: Warning Options. (line 616)
-* Wunused-but-set-variable: Warning Options. (line 625)
-* Wunused-function: Warning Options. (line 635)
-* Wunused-label: Warning Options. (line 640)
-* Wunused-macros: Preprocessor Options.
- (line 117)
-* Wunused-parameter: Warning Options. (line 647)
-* Wunused-result: Warning Options. (line 654)
-* Wunused-value: Warning Options. (line 671)
-* Wunused-variable: Warning Options. (line 659)
-* Wvariadic-macros: Warning Options. (line 1495)
-* Wvla: Warning Options. (line 1501)
-* Wvolatile-register-var: Warning Options. (line 1505)
-* Wwrite-strings: Warning Options. (line 1137)
-* x <1>: Preprocessor Options.
- (line 310)
-* x: Overall Options. (line 126)
-* Xassembler: Assembler Options. (line 13)
-* Xbind-lazy: VxWorks Options. (line 26)
-* Xbind-now: VxWorks Options. (line 30)
-* Xlinker: Link Options. (line 184)
-* Xpreprocessor: Preprocessor Options.
- (line 25)
-* Ym: System V Options. (line 26)
-* YP: System V Options. (line 22)
-
-
-File: gcc.info, Node: Keyword Index, Prev: Option Index, Up: Top
-
-Keyword Index
-*************
-
-
-* Menu:
-
-* ! in constraint: Multi-Alternative. (line 33)
-* # in constraint: Modifiers. (line 57)
-* #pragma: Pragmas. (line 6)
-* #pragma implementation: C++ Interface. (line 39)
-* #pragma implementation, implied: C++ Interface. (line 46)
-* #pragma interface: C++ Interface. (line 20)
-* #pragma, reason for not using: Function Attributes.
- (line 1767)
-* $: Dollar Signs. (line 6)
-* % in constraint: Modifiers. (line 45)
-* %include: Spec Files. (line 27)
-* %include_noerr: Spec Files. (line 31)
-* %rename: Spec Files. (line 35)
-* & in constraint: Modifiers. (line 25)
-* ': Incompatibilities. (line 116)
-* * in constraint: Modifiers. (line 62)
-* + in constraint: Modifiers. (line 12)
-* -lgcc, use with -nodefaultlibs: Link Options. (line 82)
-* -lgcc, use with -nostdlib: Link Options. (line 82)
-* -nodefaultlibs and unresolved references: Link Options. (line 82)
-* -nostdlib and unresolved references: Link Options. (line 82)
-* .sdata/.sdata2 references (PowerPC): RS/6000 and PowerPC Options.
- (line 703)
-* //: C++ Comments. (line 6)
-* 0 in constraint: Simple Constraints. (line 127)
-* < in constraint: Simple Constraints. (line 48)
-* = in constraint: Modifiers. (line 8)
-* > in constraint: Simple Constraints. (line 61)
-* ? in constraint: Multi-Alternative. (line 27)
-* ?: extensions: Conditionals. (line 6)
-* ?: side effect: Conditionals. (line 20)
-* _ in variables in macros: Typeof. (line 46)
-* __builtin___clear_cache: Other Builtins. (line 329)
-* __builtin___fprintf_chk: Object Size Checking.
- (line 6)
-* __builtin___memcpy_chk: Object Size Checking.
- (line 6)
-* __builtin___memmove_chk: Object Size Checking.
- (line 6)
-* __builtin___mempcpy_chk: Object Size Checking.
- (line 6)
-* __builtin___memset_chk: Object Size Checking.
- (line 6)
-* __builtin___printf_chk: Object Size Checking.
- (line 6)
-* __builtin___snprintf_chk: Object Size Checking.
- (line 6)
-* __builtin___sprintf_chk: Object Size Checking.
- (line 6)
-* __builtin___stpcpy_chk: Object Size Checking.
- (line 6)
-* __builtin___strcat_chk: Object Size Checking.
- (line 6)
-* __builtin___strcpy_chk: Object Size Checking.
- (line 6)
-* __builtin___strncat_chk: Object Size Checking.
- (line 6)
-* __builtin___strncpy_chk: Object Size Checking.
- (line 6)
-* __builtin___vfprintf_chk: Object Size Checking.
- (line 6)
-* __builtin___vprintf_chk: Object Size Checking.
- (line 6)
-* __builtin___vsnprintf_chk: Object Size Checking.
- (line 6)
-* __builtin___vsprintf_chk: Object Size Checking.
- (line 6)
-* __builtin_apply: Constructing Calls. (line 31)
-* __builtin_apply_args: Constructing Calls. (line 20)
-* __builtin_bswap32: Other Builtins. (line 548)
-* __builtin_bswap64: Other Builtins. (line 553)
-* __builtin_choose_expr: Other Builtins. (line 157)
-* __builtin_clz: Other Builtins. (line 481)
-* __builtin_clzl: Other Builtins. (line 499)
-* __builtin_clzll: Other Builtins. (line 519)
-* __builtin_constant_p: Other Builtins. (line 197)
-* __builtin_ctz: Other Builtins. (line 485)
-* __builtin_ctzl: Other Builtins. (line 503)
-* __builtin_ctzll: Other Builtins. (line 523)
-* __builtin_expect: Other Builtins. (line 247)
-* __builtin_extract_return_address: Return Address. (line 37)
-* __builtin_ffs: Other Builtins. (line 477)
-* __builtin_ffsl: Other Builtins. (line 495)
-* __builtin_ffsll: Other Builtins. (line 515)
-* __builtin_fpclassify: Other Builtins. (line 393)
-* __builtin_frame_address: Return Address. (line 51)
-* __builtin_frob_return_address: Return Address. (line 46)
-* __builtin_huge_val: Other Builtins. (line 380)
-* __builtin_huge_valf: Other Builtins. (line 385)
-* __builtin_huge_vall: Other Builtins. (line 388)
-* __builtin_huge_valq: X86 Built-in Functions.
- (line 51)
-* __builtin_inf: Other Builtins. (line 403)
-* __builtin_infd128: Other Builtins. (line 413)
-* __builtin_infd32: Other Builtins. (line 407)
-* __builtin_infd64: Other Builtins. (line 410)
-* __builtin_inff: Other Builtins. (line 417)
-* __builtin_infl: Other Builtins. (line 422)
-* __builtin_infq: X86 Built-in Functions.
- (line 47)
-* __builtin_isfinite: Other Builtins. (line 6)
-* __builtin_isgreater: Other Builtins. (line 6)
-* __builtin_isgreaterequal: Other Builtins. (line 6)
-* __builtin_isinf_sign: Other Builtins. (line 426)
-* __builtin_isless: Other Builtins. (line 6)
-* __builtin_islessequal: Other Builtins. (line 6)
-* __builtin_islessgreater: Other Builtins. (line 6)
-* __builtin_isnormal: Other Builtins. (line 6)
-* __builtin_isunordered: Other Builtins. (line 6)
-* __builtin_nan: Other Builtins. (line 433)
-* __builtin_nand128: Other Builtins. (line 455)
-* __builtin_nand32: Other Builtins. (line 449)
-* __builtin_nand64: Other Builtins. (line 452)
-* __builtin_nanf: Other Builtins. (line 459)
-* __builtin_nanl: Other Builtins. (line 462)
-* __builtin_nans: Other Builtins. (line 466)
-* __builtin_nansf: Other Builtins. (line 470)
-* __builtin_nansl: Other Builtins. (line 473)
-* __builtin_object_size: Object Size Checking.
- (line 11)
-* __builtin_offsetof: Offsetof. (line 6)
-* __builtin_parity: Other Builtins. (line 492)
-* __builtin_parityl: Other Builtins. (line 511)
-* __builtin_parityll: Other Builtins. (line 531)
-* __builtin_popcount: Other Builtins. (line 489)
-* __builtin_popcountl: Other Builtins. (line 507)
-* __builtin_popcountll: Other Builtins. (line 527)
-* __builtin_powi: Other Builtins. (line 535)
-* __builtin_powif: Other Builtins. (line 540)
-* __builtin_powil: Other Builtins. (line 544)
-* __builtin_prefetch: Other Builtins. (line 341)
-* __builtin_return: Constructing Calls. (line 48)
-* __builtin_return_address: Return Address. (line 11)
-* __builtin_rx_brk: RX Built-in Functions.
- (line 11)
-* __builtin_rx_clrpsw: RX Built-in Functions.
- (line 14)
-* __builtin_rx_int: RX Built-in Functions.
- (line 18)
-* __builtin_rx_machi: RX Built-in Functions.
- (line 22)
-* __builtin_rx_maclo: RX Built-in Functions.
- (line 27)
-* __builtin_rx_mulhi: RX Built-in Functions.
- (line 32)
-* __builtin_rx_mullo: RX Built-in Functions.
- (line 37)
-* __builtin_rx_mvfachi: RX Built-in Functions.
- (line 42)
-* __builtin_rx_mvfacmi: RX Built-in Functions.
- (line 46)
-* __builtin_rx_mvfc: RX Built-in Functions.
- (line 50)
-* __builtin_rx_mvtachi: RX Built-in Functions.
- (line 54)
-* __builtin_rx_mvtaclo: RX Built-in Functions.
- (line 58)
-* __builtin_rx_mvtc: RX Built-in Functions.
- (line 62)
-* __builtin_rx_mvtipl: RX Built-in Functions.
- (line 66)
-* __builtin_rx_racw: RX Built-in Functions.
- (line 70)
-* __builtin_rx_revw: RX Built-in Functions.
- (line 74)
-* __builtin_rx_rmpa: RX Built-in Functions.
- (line 79)
-* __builtin_rx_round: RX Built-in Functions.
- (line 83)
-* __builtin_rx_sat: RX Built-in Functions.
- (line 88)
-* __builtin_rx_setpsw: RX Built-in Functions.
- (line 92)
-* __builtin_rx_wait: RX Built-in Functions.
- (line 96)
-* __builtin_trap: Other Builtins. (line 271)
-* __builtin_types_compatible_p: Other Builtins. (line 111)
-* __builtin_unreachable: Other Builtins. (line 278)
-* __builtin_va_arg_pack: Constructing Calls. (line 53)
-* __builtin_va_arg_pack_len: Constructing Calls. (line 76)
-* __complex__ keyword: Complex. (line 6)
-* __declspec(dllexport): Function Attributes.
- (line 259)
-* __declspec(dllimport): Function Attributes.
- (line 294)
-* __extension__: Alternate Keywords. (line 30)
-* __float128 data type: Floating Types. (line 6)
-* __float80 data type: Floating Types. (line 6)
-* __fp16 data type: Half-Precision. (line 6)
-* __func__ identifier: Function Names. (line 6)
-* __FUNCTION__ identifier: Function Names. (line 6)
-* __imag__ keyword: Complex. (line 27)
-* __int128 data types: __int128. (line 6)
-* __PRETTY_FUNCTION__ identifier: Function Names. (line 6)
-* __real__ keyword: Complex. (line 27)
-* __STDC_HOSTED__: Standards. (line 13)
-* __sync_add_and_fetch: Atomic Builtins. (line 61)
-* __sync_and_and_fetch: Atomic Builtins. (line 61)
-* __sync_bool_compare_and_swap: Atomic Builtins. (line 73)
-* __sync_fetch_and_add: Atomic Builtins. (line 45)
-* __sync_fetch_and_and: Atomic Builtins. (line 45)
-* __sync_fetch_and_nand: Atomic Builtins. (line 45)
-* __sync_fetch_and_or: Atomic Builtins. (line 45)
-* __sync_fetch_and_sub: Atomic Builtins. (line 45)
-* __sync_fetch_and_xor: Atomic Builtins. (line 45)
-* __sync_lock_release: Atomic Builtins. (line 103)
-* __sync_lock_test_and_set: Atomic Builtins. (line 85)
-* __sync_nand_and_fetch: Atomic Builtins. (line 61)
-* __sync_or_and_fetch: Atomic Builtins. (line 61)
-* __sync_sub_and_fetch: Atomic Builtins. (line 61)
-* __sync_synchronize: Atomic Builtins. (line 82)
-* __sync_val_compare_and_swap: Atomic Builtins. (line 73)
-* __sync_xor_and_fetch: Atomic Builtins. (line 61)
-* __thread: Thread-Local. (line 6)
-* _Accum data type: Fixed-Point. (line 6)
-* _Complex keyword: Complex. (line 6)
-* _Decimal128 data type: Decimal Float. (line 6)
-* _Decimal32 data type: Decimal Float. (line 6)
-* _Decimal64 data type: Decimal Float. (line 6)
-* _Exit: Other Builtins. (line 6)
-* _exit: Other Builtins. (line 6)
-* _Fract data type: Fixed-Point. (line 6)
-* _Sat data type: Fixed-Point. (line 6)
-* ABI: Compatibility. (line 6)
-* abort: Other Builtins. (line 6)
-* abs: Other Builtins. (line 6)
-* accessing volatiles <1>: Volatiles. (line 6)
-* accessing volatiles: C++ Volatiles. (line 6)
-* acos: Other Builtins. (line 6)
-* acosf: Other Builtins. (line 6)
-* acosh: Other Builtins. (line 6)
-* acoshf: Other Builtins. (line 6)
-* acoshl: Other Builtins. (line 6)
-* acosl: Other Builtins. (line 6)
-* Ada: G++ and GCC. (line 6)
-* additional floating types: Floating Types. (line 6)
-* address constraints: Simple Constraints. (line 154)
-* address of a label: Labels as Values. (line 6)
-* address_operand: Simple Constraints. (line 158)
-* alias attribute: Function Attributes.
- (line 36)
-* aligned attribute <1>: Variable Attributes.
- (line 23)
-* aligned attribute <2>: Type Attributes. (line 31)
-* aligned attribute: Function Attributes.
- (line 49)
-* alignment: Alignment. (line 6)
-* alloc_size attribute: Function Attributes.
- (line 69)
-* alloca: Other Builtins. (line 6)
-* alloca vs variable-length arrays: Variable Length. (line 26)
-* Allow nesting in an interrupt handler on the Blackfin processor.: Function Attributes.
- (line 888)
-* alternate keywords: Alternate Keywords. (line 6)
-* always_inline function attribute: Function Attributes.
- (line 90)
-* AMD x86-64 Options: i386 and x86-64 Options.
- (line 6)
-* AMD1: Standards. (line 13)
-* ANSI C: Standards. (line 13)
-* ANSI C standard: Standards. (line 13)
-* ANSI C89: Standards. (line 13)
-* ANSI support: C Dialect Options. (line 10)
-* ANSI X3.159-1989: Standards. (line 13)
-* apostrophes: Incompatibilities. (line 116)
-* application binary interface: Compatibility. (line 6)
-* ARC Options: ARC Options. (line 6)
-* ARM [Annotated C++ Reference Manual]: Backwards Compatibility.
- (line 6)
-* ARM options: ARM Options. (line 6)
-* arrays of length zero: Zero Length. (line 6)
-* arrays of variable length: Variable Length. (line 6)
-* arrays, non-lvalue: Subscripting. (line 6)
-* artificial function attribute: Function Attributes.
- (line 133)
-* asin: Other Builtins. (line 6)
-* asinf: Other Builtins. (line 6)
-* asinh: Other Builtins. (line 6)
-* asinhf: Other Builtins. (line 6)
-* asinhl: Other Builtins. (line 6)
-* asinl: Other Builtins. (line 6)
-* asm constraints: Constraints. (line 6)
-* asm expressions: Extended Asm. (line 6)
-* assembler instructions: Extended Asm. (line 6)
-* assembler names for identifiers: Asm Labels. (line 6)
-* assembly code, invalid: Bug Criteria. (line 12)
-* atan: Other Builtins. (line 6)
-* atan2: Other Builtins. (line 6)
-* atan2f: Other Builtins. (line 6)
-* atan2l: Other Builtins. (line 6)
-* atanf: Other Builtins. (line 6)
-* atanh: Other Builtins. (line 6)
-* atanhf: Other Builtins. (line 6)
-* atanhl: Other Builtins. (line 6)
-* atanl: Other Builtins. (line 6)
-* attribute of types: Type Attributes. (line 6)
-* attribute of variables: Variable Attributes.
- (line 6)
-* attribute syntax: Attribute Syntax. (line 6)
-* autoincrement/decrement addressing: Simple Constraints. (line 30)
-* automatic inline for C++ member fns: Inline. (line 71)
-* AVR Options: AVR Options. (line 6)
-* Backwards Compatibility: Backwards Compatibility.
- (line 6)
-* base class members: Name lookup. (line 6)
-* bcmp: Other Builtins. (line 6)
-* below100 attribute: Variable Attributes.
- (line 562)
-* binary compatibility: Compatibility. (line 6)
-* Binary constants using the 0b prefix: Binary constants. (line 6)
-* Blackfin Options: Blackfin Options. (line 6)
-* bound pointer to member function: Bound member functions.
- (line 6)
-* bounds checking: Optimize Options. (line 393)
-* bug criteria: Bug Criteria. (line 6)
-* bugs: Bugs. (line 6)
-* bugs, known: Trouble. (line 6)
-* built-in functions <1>: Other Builtins. (line 6)
-* built-in functions: C Dialect Options. (line 184)
-* bzero: Other Builtins. (line 6)
-* C compilation options: Invoking GCC. (line 17)
-* C intermediate output, nonexistent: G++ and GCC. (line 35)
-* C language extensions: C Extensions. (line 6)
-* C language, traditional: C Dialect Options. (line 282)
-* C standard: Standards. (line 13)
-* C standards: Standards. (line 13)
-* C++: G++ and GCC. (line 30)
-* c++: Invoking G++. (line 14)
-* C++ comments: C++ Comments. (line 6)
-* C++ compilation options: Invoking GCC. (line 23)
-* C++ interface and implementation headers: C++ Interface. (line 6)
-* C++ language extensions: C++ Extensions. (line 6)
-* C++ member fns, automatically inline: Inline. (line 71)
-* C++ misunderstandings: C++ Misunderstandings.
- (line 6)
-* C++ options, command line: C++ Dialect Options.
- (line 6)
-* C++ pragmas, effect on inlining: C++ Interface. (line 66)
-* C++ source file suffixes: Invoking G++. (line 6)
-* C++ static data, declaring and defining: Static Definitions.
- (line 6)
-* C1X: Standards. (line 13)
-* C89: Standards. (line 13)
-* C90: Standards. (line 13)
-* C94: Standards. (line 13)
-* C95: Standards. (line 13)
-* C99: Standards. (line 13)
-* C9X: Standards. (line 13)
-* C_INCLUDE_PATH: Environment Variables.
- (line 127)
-* cabs: Other Builtins. (line 6)
-* cabsf: Other Builtins. (line 6)
-* cabsl: Other Builtins. (line 6)
-* cacos: Other Builtins. (line 6)
-* cacosf: Other Builtins. (line 6)
-* cacosh: Other Builtins. (line 6)
-* cacoshf: Other Builtins. (line 6)
-* cacoshl: Other Builtins. (line 6)
-* cacosl: Other Builtins. (line 6)
-* callee_pop_aggregate_return attribute: Function Attributes.
- (line 847)
-* calling functions through the function vector on H8/300, M16C, M32C and SH2A processors: Function Attributes.
- (line 532)
-* calloc: Other Builtins. (line 6)
-* carg: Other Builtins. (line 6)
-* cargf: Other Builtins. (line 6)
-* cargl: Other Builtins. (line 6)
-* case labels in initializers: Designated Inits. (line 6)
-* case ranges: Case Ranges. (line 6)
-* casin: Other Builtins. (line 6)
-* casinf: Other Builtins. (line 6)
-* casinh: Other Builtins. (line 6)
-* casinhf: Other Builtins. (line 6)
-* casinhl: Other Builtins. (line 6)
-* casinl: Other Builtins. (line 6)
-* cast to a union: Cast to Union. (line 6)
-* catan: Other Builtins. (line 6)
-* catanf: Other Builtins. (line 6)
-* catanh: Other Builtins. (line 6)
-* catanhf: Other Builtins. (line 6)
-* catanhl: Other Builtins. (line 6)
-* catanl: Other Builtins. (line 6)
-* cbrt: Other Builtins. (line 6)
-* cbrtf: Other Builtins. (line 6)
-* cbrtl: Other Builtins. (line 6)
-* ccos: Other Builtins. (line 6)
-* ccosf: Other Builtins. (line 6)
-* ccosh: Other Builtins. (line 6)
-* ccoshf: Other Builtins. (line 6)
-* ccoshl: Other Builtins. (line 6)
-* ccosl: Other Builtins. (line 6)
-* ceil: Other Builtins. (line 6)
-* ceilf: Other Builtins. (line 6)
-* ceill: Other Builtins. (line 6)
-* cexp: Other Builtins. (line 6)
-* cexpf: Other Builtins. (line 6)
-* cexpl: Other Builtins. (line 6)
-* character set, execution: Preprocessor Options.
- (line 508)
-* character set, input: Preprocessor Options.
- (line 521)
-* character set, input normalization: Warning Options. (line 1329)
-* character set, wide execution: Preprocessor Options.
- (line 513)
-* cimag: Other Builtins. (line 6)
-* cimagf: Other Builtins. (line 6)
-* cimagl: Other Builtins. (line 6)
-* cleanup attribute: Variable Attributes.
- (line 89)
-* clog: Other Builtins. (line 6)
-* clogf: Other Builtins. (line 6)
-* clogl: Other Builtins. (line 6)
-* COBOL: G++ and GCC. (line 23)
-* code generation conventions: Code Gen Options. (line 6)
-* code, mixed with declarations: Mixed Declarations. (line 6)
-* cold function attribute: Function Attributes.
- (line 1098)
-* command options: Invoking GCC. (line 6)
-* comments, C++ style: C++ Comments. (line 6)
-* common attribute: Variable Attributes.
- (line 105)
-* comparison of signed and unsigned values, warning: Warning Options.
- (line 1201)
-* compiler bugs, reporting: Bug Reporting. (line 6)
-* compiler compared to C++ preprocessor: G++ and GCC. (line 35)
-* compiler options, C++: C++ Dialect Options.
- (line 6)
-* compiler options, Objective-C and Objective-C++: Objective-C and Objective-C++ Dialect Options.
- (line 6)
-* compiler version, specifying: Target Options. (line 6)
-* COMPILER_PATH: Environment Variables.
- (line 88)
-* complex conjugation: Complex. (line 34)
-* complex numbers: Complex. (line 6)
-* compound literals: Compound Literals. (line 6)
-* computed gotos: Labels as Values. (line 6)
-* conditional expressions, extensions: Conditionals. (line 6)
-* conflicting types: Disappointments. (line 21)
-* conj: Other Builtins. (line 6)
-* conjf: Other Builtins. (line 6)
-* conjl: Other Builtins. (line 6)
-* const applied to function: Function Attributes.
- (line 6)
-* const function attribute: Function Attributes.
- (line 183)
-* constants in constraints: Simple Constraints. (line 70)
-* constraint modifier characters: Modifiers. (line 6)
-* constraint, matching: Simple Constraints. (line 139)
-* constraints, asm: Constraints. (line 6)
-* constraints, machine specific: Machine Constraints.
- (line 6)
-* constructing calls: Constructing Calls. (line 6)
-* constructor expressions: Compound Literals. (line 6)
-* constructor function attribute: Function Attributes.
- (line 211)
-* contributors: Contributors. (line 6)
-* copysign: Other Builtins. (line 6)
-* copysignf: Other Builtins. (line 6)
-* copysignl: Other Builtins. (line 6)
-* core dump: Bug Criteria. (line 9)
-* cos: Other Builtins. (line 6)
-* cosf: Other Builtins. (line 6)
-* cosh: Other Builtins. (line 6)
-* coshf: Other Builtins. (line 6)
-* coshl: Other Builtins. (line 6)
-* cosl: Other Builtins. (line 6)
-* CPATH: Environment Variables.
- (line 126)
-* CPLUS_INCLUDE_PATH: Environment Variables.
- (line 128)
-* cpow: Other Builtins. (line 6)
-* cpowf: Other Builtins. (line 6)
-* cpowl: Other Builtins. (line 6)
-* cproj: Other Builtins. (line 6)
-* cprojf: Other Builtins. (line 6)
-* cprojl: Other Builtins. (line 6)
-* creal: Other Builtins. (line 6)
-* crealf: Other Builtins. (line 6)
-* creall: Other Builtins. (line 6)
-* CRIS Options: CRIS Options. (line 6)
-* cross compiling: Target Options. (line 6)
-* CRX Options: CRX Options. (line 6)
-* csin: Other Builtins. (line 6)
-* csinf: Other Builtins. (line 6)
-* csinh: Other Builtins. (line 6)
-* csinhf: Other Builtins. (line 6)
-* csinhl: Other Builtins. (line 6)
-* csinl: Other Builtins. (line 6)
-* csqrt: Other Builtins. (line 6)
-* csqrtf: Other Builtins. (line 6)
-* csqrtl: Other Builtins. (line 6)
-* ctan: Other Builtins. (line 6)
-* ctanf: Other Builtins. (line 6)
-* ctanh: Other Builtins. (line 6)
-* ctanhf: Other Builtins. (line 6)
-* ctanhl: Other Builtins. (line 6)
-* ctanl: Other Builtins. (line 6)
-* Darwin options: Darwin Options. (line 6)
-* dcgettext: Other Builtins. (line 6)
-* dd integer suffix: Decimal Float. (line 6)
-* DD integer suffix: Decimal Float. (line 6)
-* deallocating variable length arrays: Variable Length. (line 22)
-* debugging information options: Debugging Options. (line 6)
-* decimal floating types: Decimal Float. (line 6)
-* declaration scope: Incompatibilities. (line 80)
-* declarations inside expressions: Statement Exprs. (line 6)
-* declarations, mixed with code: Mixed Declarations. (line 6)
-* declaring attributes of functions: Function Attributes.
- (line 6)
-* declaring static data in C++: Static Definitions. (line 6)
-* defining static data in C++: Static Definitions. (line 6)
-* dependencies for make as output: Environment Variables.
- (line 170)
-* dependencies, make: Preprocessor Options.
- (line 173)
-* DEPENDENCIES_OUTPUT: Environment Variables.
- (line 153)
-* dependent name lookup: Name lookup. (line 6)
-* deprecated attribute: Variable Attributes.
- (line 114)
-* deprecated attribute.: Function Attributes.
- (line 234)
-* designated initializers: Designated Inits. (line 6)
-* designator lists: Designated Inits. (line 94)
-* designators: Designated Inits. (line 61)
-* destructor function attribute: Function Attributes.
- (line 211)
-* DF integer suffix: Decimal Float. (line 6)
-* df integer suffix: Decimal Float. (line 6)
-* dgettext: Other Builtins. (line 6)
-* diagnostic messages: Language Independent Options.
- (line 6)
-* dialect options: C Dialect Options. (line 6)
-* digits in constraint: Simple Constraints. (line 127)
-* directory options: Directory Options. (line 6)
-* disinterrupt attribute: Function Attributes.
- (line 254)
-* DL integer suffix: Decimal Float. (line 6)
-* dl integer suffix: Decimal Float. (line 6)
-* dollar signs in identifier names: Dollar Signs. (line 6)
-* double-word arithmetic: Long Long. (line 6)
-* downward funargs: Nested Functions. (line 6)
-* drem: Other Builtins. (line 6)
-* dremf: Other Builtins. (line 6)
-* dreml: Other Builtins. (line 6)
-* E in constraint: Simple Constraints. (line 89)
-* earlyclobber operand: Modifiers. (line 25)
-* eight bit data on the H8/300, H8/300H, and H8S: Function Attributes.
- (line 347)
-* empty structures: Empty Structures. (line 6)
-* environment variables: Environment Variables.
- (line 6)
-* erf: Other Builtins. (line 6)
-* erfc: Other Builtins. (line 6)
-* erfcf: Other Builtins. (line 6)
-* erfcl: Other Builtins. (line 6)
-* erff: Other Builtins. (line 6)
-* erfl: Other Builtins. (line 6)
-* error function attribute: Function Attributes.
- (line 152)
-* error messages: Warnings and Errors.
- (line 6)
-* escaped newlines: Escaped Newlines. (line 6)
-* exception handler functions on the Blackfin processor: Function Attributes.
- (line 357)
-* exclamation point: Multi-Alternative. (line 33)
-* exit: Other Builtins. (line 6)
-* exp: Other Builtins. (line 6)
-* exp10: Other Builtins. (line 6)
-* exp10f: Other Builtins. (line 6)
-* exp10l: Other Builtins. (line 6)
-* exp2: Other Builtins. (line 6)
-* exp2f: Other Builtins. (line 6)
-* exp2l: Other Builtins. (line 6)
-* expf: Other Builtins. (line 6)
-* expl: Other Builtins. (line 6)
-* explicit register variables: Explicit Reg Vars. (line 6)
-* expm1: Other Builtins. (line 6)
-* expm1f: Other Builtins. (line 6)
-* expm1l: Other Builtins. (line 6)
-* expressions containing statements: Statement Exprs. (line 6)
-* expressions, constructor: Compound Literals. (line 6)
-* extended asm: Extended Asm. (line 6)
-* extensible constraints: Simple Constraints. (line 163)
-* extensions, ?:: Conditionals. (line 6)
-* extensions, C language: C Extensions. (line 6)
-* extensions, C++ language: C++ Extensions. (line 6)
-* external declaration scope: Incompatibilities. (line 80)
-* externally_visible attribute.: Function Attributes.
- (line 363)
-* F in constraint: Simple Constraints. (line 94)
-* fabs: Other Builtins. (line 6)
-* fabsf: Other Builtins. (line 6)
-* fabsl: Other Builtins. (line 6)
-* fatal signal: Bug Criteria. (line 9)
-* fdim: Other Builtins. (line 6)
-* fdimf: Other Builtins. (line 6)
-* fdiml: Other Builtins. (line 6)
-* FDL, GNU Free Documentation License: GNU Free Documentation License.
- (line 6)
-* ffs: Other Builtins. (line 6)
-* file name suffix: Overall Options. (line 14)
-* file names: Link Options. (line 10)
-* fixed-point types: Fixed-Point. (line 6)
-* flatten function attribute: Function Attributes.
- (line 145)
-* flexible array members: Zero Length. (line 6)
-* float as function value type: Incompatibilities. (line 141)
-* floating point precision <1>: Disappointments. (line 68)
-* floating point precision: Optimize Options. (line 1883)
-* floor: Other Builtins. (line 6)
-* floorf: Other Builtins. (line 6)
-* floorl: Other Builtins. (line 6)
-* fma: Other Builtins. (line 6)
-* fmaf: Other Builtins. (line 6)
-* fmal: Other Builtins. (line 6)
-* fmax: Other Builtins. (line 6)
-* fmaxf: Other Builtins. (line 6)
-* fmaxl: Other Builtins. (line 6)
-* fmin: Other Builtins. (line 6)
-* fminf: Other Builtins. (line 6)
-* fminl: Other Builtins. (line 6)
-* fmod: Other Builtins. (line 6)
-* fmodf: Other Builtins. (line 6)
-* fmodl: Other Builtins. (line 6)
-* force_align_arg_pointer attribute: Function Attributes.
- (line 1140)
-* format function attribute: Function Attributes.
- (line 420)
-* format_arg function attribute: Function Attributes.
- (line 485)
-* Fortran: G++ and GCC. (line 6)
-* forwarding calls: Constructing Calls. (line 6)
-* fprintf: Other Builtins. (line 6)
-* fprintf_unlocked: Other Builtins. (line 6)
-* fputs: Other Builtins. (line 6)
-* fputs_unlocked: Other Builtins. (line 6)
-* FR30 Options: FR30 Options. (line 6)
-* freestanding environment: Standards. (line 13)
-* freestanding implementation: Standards. (line 13)
-* frexp: Other Builtins. (line 6)
-* frexpf: Other Builtins. (line 6)
-* frexpl: Other Builtins. (line 6)
-* FRV Options: FRV Options. (line 6)
-* fscanf: Other Builtins. (line 6)
-* fscanf, and constant strings: Incompatibilities. (line 17)
-* function addressability on the M32R/D: Function Attributes.
- (line 807)
-* function attributes: Function Attributes.
- (line 6)
-* function pointers, arithmetic: Pointer Arith. (line 6)
-* function prototype declarations: Function Prototypes.
- (line 6)
-* function without a prologue/epilogue code: Function Attributes.
- (line 865)
-* function, size of pointer to: Pointer Arith. (line 6)
-* functions called via pointer on the RS/6000 and PowerPC: Function Attributes.
- (line 761)
-* functions in arbitrary sections: Function Attributes.
- (line 6)
-* functions that are dynamically resolved: Function Attributes.
- (line 6)
-* functions that are passed arguments in registers on the 386: Function Attributes.
- (line 6)
-* functions that behave like malloc: Function Attributes.
- (line 6)
-* functions that do not pop the argument stack on the 386: Function Attributes.
- (line 6)
-* functions that do pop the argument stack on the 386: Function Attributes.
- (line 177)
-* functions that have different compilation options on the 386: Function Attributes.
- (line 6)
-* functions that have different optimization options: Function Attributes.
- (line 6)
-* functions that have no side effects: Function Attributes.
- (line 6)
-* functions that never return: Function Attributes.
- (line 6)
-* functions that pop the argument stack on the 386: Function Attributes.
- (line 6)
-* functions that return more than once: Function Attributes.
- (line 6)
-* functions which do not handle memory bank switching on 68HC11/68HC12: Function Attributes.
- (line 878)
-* functions which handle memory bank switching: Function Attributes.
- (line 375)
-* functions with non-null pointer arguments: Function Attributes.
- (line 6)
-* functions with printf, scanf, strftime or strfmon style arguments: Function Attributes.
- (line 6)
-* G in constraint: Simple Constraints. (line 98)
-* g in constraint: Simple Constraints. (line 120)
-* g++: Invoking G++. (line 14)
-* G++: G++ and GCC. (line 30)
-* gamma: Other Builtins. (line 6)
-* gamma_r: Other Builtins. (line 6)
-* gammaf: Other Builtins. (line 6)
-* gammaf_r: Other Builtins. (line 6)
-* gammal: Other Builtins. (line 6)
-* gammal_r: Other Builtins. (line 6)
-* GCC: G++ and GCC. (line 6)
-* GCC command options: Invoking GCC. (line 6)
-* GCC_EXEC_PREFIX: Environment Variables.
- (line 52)
-* gcc_struct: Type Attributes. (line 319)
-* gcc_struct attribute: Variable Attributes.
- (line 419)
-* gcov: Debugging Options. (line 370)
-* gettext: Other Builtins. (line 6)
-* global offset table: Code Gen Options. (line 184)
-* global register after longjmp: Global Reg Vars. (line 66)
-* global register variables: Global Reg Vars. (line 6)
-* GNAT: G++ and GCC. (line 30)
-* GNU C Compiler: G++ and GCC. (line 6)
-* GNU Compiler Collection: G++ and GCC. (line 6)
-* gnu_inline function attribute: Function Attributes.
- (line 95)
-* Go: G++ and GCC. (line 6)
-* goto with computed label: Labels as Values. (line 6)
-* gprof: Debugging Options. (line 300)
-* grouping options: Invoking GCC. (line 26)
-* H in constraint: Simple Constraints. (line 98)
-* half-precision floating point: Half-Precision. (line 6)
-* hardware models and configurations, specifying: Submodel Options.
- (line 6)
-* hex floats: Hex Floats. (line 6)
-* hk fixed-suffix: Fixed-Point. (line 6)
-* HK fixed-suffix: Fixed-Point. (line 6)
-* hosted environment <1>: C Dialect Options. (line 225)
-* hosted environment: Standards. (line 13)
-* hosted implementation: Standards. (line 13)
-* hot function attribute: Function Attributes.
- (line 1085)
-* HPPA Options: HPPA Options. (line 6)
-* hr fixed-suffix: Fixed-Point. (line 6)
-* HR fixed-suffix: Fixed-Point. (line 6)
-* hypot: Other Builtins. (line 6)
-* hypotf: Other Builtins. (line 6)
-* hypotl: Other Builtins. (line 6)
-* i in constraint: Simple Constraints. (line 70)
-* I in constraint: Simple Constraints. (line 81)
-* i386 and x86-64 Windows Options: i386 and x86-64 Windows Options.
- (line 6)
-* i386 Options: i386 and x86-64 Options.
- (line 6)
-* IA-64 Options: IA-64 Options. (line 6)
-* IBM RS/6000 and PowerPC Options: RS/6000 and PowerPC Options.
- (line 6)
-* identifier names, dollar signs in: Dollar Signs. (line 6)
-* identifiers, names in assembler code: Asm Labels. (line 6)
-* ifunc attribute: Function Attributes.
- (line 648)
-* ilogb: Other Builtins. (line 6)
-* ilogbf: Other Builtins. (line 6)
-* ilogbl: Other Builtins. (line 6)
-* imaxabs: Other Builtins. (line 6)
-* implementation-defined behavior, C language: C Implementation.
- (line 6)
-* implementation-defined behavior, C++ language: C++ Implementation.
- (line 6)
-* implied #pragma implementation: C++ Interface. (line 46)
-* incompatibilities of GCC: Incompatibilities. (line 6)
-* increment operators: Bug Criteria. (line 17)
-* index: Other Builtins. (line 6)
-* indirect calls on ARM: Function Attributes.
- (line 751)
-* indirect calls on MIPS: Function Attributes.
- (line 773)
-* init_priority attribute: C++ Attributes. (line 9)
-* initializations in expressions: Compound Literals. (line 6)
-* initializers with labeled elements: Designated Inits. (line 6)
-* initializers, non-constant: Initializers. (line 6)
-* inline automatic for C++ member fns: Inline. (line 71)
-* inline functions: Inline. (line 6)
-* inline functions, omission of: Inline. (line 51)
-* inlining and C++ pragmas: C++ Interface. (line 66)
-* installation trouble: Trouble. (line 6)
-* integrating function code: Inline. (line 6)
-* Intel 386 Options: i386 and x86-64 Options.
- (line 6)
-* interface and implementation headers, C++: C++ Interface. (line 6)
-* intermediate C version, nonexistent: G++ and GCC. (line 35)
-* interrupt handler functions: Function Attributes.
- (line 395)
-* interrupt handler functions on the Blackfin, m68k, H8/300 and SH processors: Function Attributes.
- (line 688)
-* interrupt service routines on ARM: Function Attributes.
- (line 703)
-* interrupt thread functions on fido: Function Attributes.
- (line 695)
-* introduction: Top. (line 6)
-* invalid assembly code: Bug Criteria. (line 12)
-* invalid input: Bug Criteria. (line 42)
-* invoking g++: Invoking G++. (line 22)
-* isalnum: Other Builtins. (line 6)
-* isalpha: Other Builtins. (line 6)
-* isascii: Other Builtins. (line 6)
-* isblank: Other Builtins. (line 6)
-* iscntrl: Other Builtins. (line 6)
-* isdigit: Other Builtins. (line 6)
-* isgraph: Other Builtins. (line 6)
-* islower: Other Builtins. (line 6)
-* ISO 9899: Standards. (line 13)
-* ISO C: Standards. (line 13)
-* ISO C standard: Standards. (line 13)
-* ISO C1X: Standards. (line 13)
-* ISO C90: Standards. (line 13)
-* ISO C94: Standards. (line 13)
-* ISO C95: Standards. (line 13)
-* ISO C99: Standards. (line 13)
-* ISO C9X: Standards. (line 13)
-* ISO support: C Dialect Options. (line 10)
-* ISO/IEC 9899: Standards. (line 13)
-* isprint: Other Builtins. (line 6)
-* ispunct: Other Builtins. (line 6)
-* isspace: Other Builtins. (line 6)
-* isupper: Other Builtins. (line 6)
-* iswalnum: Other Builtins. (line 6)
-* iswalpha: Other Builtins. (line 6)
-* iswblank: Other Builtins. (line 6)
-* iswcntrl: Other Builtins. (line 6)
-* iswdigit: Other Builtins. (line 6)
-* iswgraph: Other Builtins. (line 6)
-* iswlower: Other Builtins. (line 6)
-* iswprint: Other Builtins. (line 6)
-* iswpunct: Other Builtins. (line 6)
-* iswspace: Other Builtins. (line 6)
-* iswupper: Other Builtins. (line 6)
-* iswxdigit: Other Builtins. (line 6)
-* isxdigit: Other Builtins. (line 6)
-* j0: Other Builtins. (line 6)
-* j0f: Other Builtins. (line 6)
-* j0l: Other Builtins. (line 6)
-* j1: Other Builtins. (line 6)
-* j1f: Other Builtins. (line 6)
-* j1l: Other Builtins. (line 6)
-* Java: G++ and GCC. (line 6)
-* java_interface attribute: C++ Attributes. (line 29)
-* jn: Other Builtins. (line 6)
-* jnf: Other Builtins. (line 6)
-* jnl: Other Builtins. (line 6)
-* k fixed-suffix: Fixed-Point. (line 6)
-* K fixed-suffix: Fixed-Point. (line 6)
-* keep_interrupts_masked attribute: Function Attributes.
- (line 624)
-* keywords, alternate: Alternate Keywords. (line 6)
-* known causes of trouble: Trouble. (line 6)
-* l1_data variable attribute: Variable Attributes.
- (line 330)
-* l1_data_A variable attribute: Variable Attributes.
- (line 330)
-* l1_data_B variable attribute: Variable Attributes.
- (line 330)
-* l1_text function attribute: Function Attributes.
- (line 712)
-* l2 function attribute: Function Attributes.
- (line 718)
-* l2 variable attribute: Variable Attributes.
- (line 338)
-* labeled elements in initializers: Designated Inits. (line 6)
-* labels as values: Labels as Values. (line 6)
-* labs: Other Builtins. (line 6)
-* LANG: Environment Variables.
- (line 21)
-* language dialect options: C Dialect Options. (line 6)
-* LC_ALL: Environment Variables.
- (line 21)
-* LC_CTYPE: Environment Variables.
- (line 21)
-* LC_MESSAGES: Environment Variables.
- (line 21)
-* ldexp: Other Builtins. (line 6)
-* ldexpf: Other Builtins. (line 6)
-* ldexpl: Other Builtins. (line 6)
-* leaf function attribute: Function Attributes.
- (line 724)
-* length-zero arrays: Zero Length. (line 6)
-* lgamma: Other Builtins. (line 6)
-* lgamma_r: Other Builtins. (line 6)
-* lgammaf: Other Builtins. (line 6)
-* lgammaf_r: Other Builtins. (line 6)
-* lgammal: Other Builtins. (line 6)
-* lgammal_r: Other Builtins. (line 6)
-* Libraries: Link Options. (line 24)
-* LIBRARY_PATH: Environment Variables.
- (line 94)
-* link options: Link Options. (line 6)
-* linker script: Link Options. (line 178)
-* lk fixed-suffix: Fixed-Point. (line 6)
-* LK fixed-suffix: Fixed-Point. (line 6)
-* LL integer suffix: Long Long. (line 6)
-* llabs: Other Builtins. (line 6)
-* LLK fixed-suffix: Fixed-Point. (line 6)
-* llk fixed-suffix: Fixed-Point. (line 6)
-* llr fixed-suffix: Fixed-Point. (line 6)
-* LLR fixed-suffix: Fixed-Point. (line 6)
-* llrint: Other Builtins. (line 6)
-* llrintf: Other Builtins. (line 6)
-* llrintl: Other Builtins. (line 6)
-* llround: Other Builtins. (line 6)
-* llroundf: Other Builtins. (line 6)
-* llroundl: Other Builtins. (line 6)
-* LM32 options: LM32 Options. (line 6)
-* load address instruction: Simple Constraints. (line 154)
-* local labels: Local Labels. (line 6)
-* local variables in macros: Typeof. (line 46)
-* local variables, specifying registers: Local Reg Vars. (line 6)
-* locale: Environment Variables.
- (line 21)
-* locale definition: Environment Variables.
- (line 103)
-* log: Other Builtins. (line 6)
-* log10: Other Builtins. (line 6)
-* log10f: Other Builtins. (line 6)
-* log10l: Other Builtins. (line 6)
-* log1p: Other Builtins. (line 6)
-* log1pf: Other Builtins. (line 6)
-* log1pl: Other Builtins. (line 6)
-* log2: Other Builtins. (line 6)
-* log2f: Other Builtins. (line 6)
-* log2l: Other Builtins. (line 6)
-* logb: Other Builtins. (line 6)
-* logbf: Other Builtins. (line 6)
-* logbl: Other Builtins. (line 6)
-* logf: Other Builtins. (line 6)
-* logl: Other Builtins. (line 6)
-* long long data types: Long Long. (line 6)
-* longjmp: Global Reg Vars. (line 66)
-* longjmp incompatibilities: Incompatibilities. (line 39)
-* longjmp warnings: Warning Options. (line 738)
-* lr fixed-suffix: Fixed-Point. (line 6)
-* LR fixed-suffix: Fixed-Point. (line 6)
-* lrint: Other Builtins. (line 6)
-* lrintf: Other Builtins. (line 6)
-* lrintl: Other Builtins. (line 6)
-* lround: Other Builtins. (line 6)
-* lroundf: Other Builtins. (line 6)
-* lroundl: Other Builtins. (line 6)
-* m in constraint: Simple Constraints. (line 17)
-* M32C options: M32C Options. (line 6)
-* M32R/D options: M32R/D Options. (line 6)
-* M680x0 options: M680x0 Options. (line 6)
-* M68hc1x options: M68hc1x Options. (line 6)
-* machine dependent options: Submodel Options. (line 6)
-* machine specific constraints: Machine Constraints.
- (line 6)
-* macro with variable arguments: Variadic Macros. (line 6)
-* macros containing asm: Extended Asm. (line 242)
-* macros, inline alternative: Inline. (line 6)
-* macros, local labels: Local Labels. (line 6)
-* macros, local variables in: Typeof. (line 46)
-* macros, statements in expressions: Statement Exprs. (line 6)
-* macros, types of arguments: Typeof. (line 6)
-* make: Preprocessor Options.
- (line 173)
-* malloc: Other Builtins. (line 6)
-* malloc attribute: Function Attributes.
- (line 783)
-* matching constraint: Simple Constraints. (line 139)
-* MCore options: MCore Options. (line 6)
-* member fns, automatically inline: Inline. (line 71)
-* memchr: Other Builtins. (line 6)
-* memcmp: Other Builtins. (line 6)
-* memcpy: Other Builtins. (line 6)
-* memory references in constraints: Simple Constraints. (line 17)
-* mempcpy: Other Builtins. (line 6)
-* memset: Other Builtins. (line 6)
-* MeP options: MeP Options. (line 6)
-* Mercury: G++ and GCC. (line 23)
-* message formatting: Language Independent Options.
- (line 6)
-* messages, warning: Warning Options. (line 6)
-* messages, warning and error: Warnings and Errors.
- (line 6)
-* MicroBlaze Options: MicroBlaze Options. (line 6)
-* middle-operands, omitted: Conditionals. (line 6)
-* MIPS options: MIPS Options. (line 6)
-* mips16 attribute: Function Attributes.
- (line 793)
-* misunderstandings in C++: C++ Misunderstandings.
- (line 6)
-* mixed declarations and code: Mixed Declarations. (line 6)
-* mktemp, and constant strings: Incompatibilities. (line 13)
-* MMIX Options: MMIX Options. (line 6)
-* MN10300 options: MN10300 Options. (line 6)
-* mode attribute: Variable Attributes.
- (line 134)
-* modf: Other Builtins. (line 6)
-* modff: Other Builtins. (line 6)
-* modfl: Other Builtins. (line 6)
-* modifiers in constraints: Modifiers. (line 6)
-* ms_abi attribute: Function Attributes.
- (line 835)
-* ms_hook_prologue attribute: Function Attributes.
- (line 859)
-* ms_struct: Type Attributes. (line 319)
-* ms_struct attribute: Variable Attributes.
- (line 419)
-* mudflap: Optimize Options. (line 393)
-* multiple alternative constraints: Multi-Alternative. (line 6)
-* multiprecision arithmetic: Long Long. (line 6)
-* n in constraint: Simple Constraints. (line 75)
-* named address spaces: Named Address Spaces.
- (line 6)
-* names used in assembler code: Asm Labels. (line 6)
-* naming convention, implementation headers: C++ Interface. (line 46)
-* nearbyint: Other Builtins. (line 6)
-* nearbyintf: Other Builtins. (line 6)
-* nearbyintl: Other Builtins. (line 6)
-* nested functions: Nested Functions. (line 6)
-* newlines (escaped): Escaped Newlines. (line 6)
-* nextafter: Other Builtins. (line 6)
-* nextafterf: Other Builtins. (line 6)
-* nextafterl: Other Builtins. (line 6)
-* nexttoward: Other Builtins. (line 6)
-* nexttowardf: Other Builtins. (line 6)
-* nexttowardl: Other Builtins. (line 6)
-* NFC: Warning Options. (line 1329)
-* NFKC: Warning Options. (line 1329)
-* NMI handler functions on the Blackfin processor: Function Attributes.
- (line 893)
-* no_instrument_function function attribute: Function Attributes.
- (line 899)
-* no_split_stack function attribute: Function Attributes.
- (line 904)
-* noclone function attribute: Function Attributes.
- (line 920)
-* nocommon attribute: Variable Attributes.
- (line 105)
-* noinline function attribute: Function Attributes.
- (line 910)
-* nomips16 attribute: Function Attributes.
- (line 793)
-* non-constant initializers: Initializers. (line 6)
-* non-static inline function: Inline. (line 85)
-* nonnull function attribute: Function Attributes.
- (line 926)
-* noreturn function attribute: Function Attributes.
- (line 953)
-* nothrow function attribute: Function Attributes.
- (line 995)
-* o in constraint: Simple Constraints. (line 23)
-* OBJC_INCLUDE_PATH: Environment Variables.
- (line 129)
-* Objective-C <1>: G++ and GCC. (line 6)
-* Objective-C: Standards. (line 157)
-* Objective-C and Objective-C++ options, command line: Objective-C and Objective-C++ Dialect Options.
- (line 6)
-* Objective-C++ <1>: Standards. (line 157)
-* Objective-C++: G++ and GCC. (line 6)
-* offsettable address: Simple Constraints. (line 23)
-* old-style function definitions: Function Prototypes.
- (line 6)
-* omitted middle-operands: Conditionals. (line 6)
-* open coding: Inline. (line 6)
-* OpenMP parallel: C Dialect Options. (line 235)
-* operand constraints, asm: Constraints. (line 6)
-* optimize function attribute: Function Attributes.
- (line 1003)
-* optimize options: Optimize Options. (line 6)
-* options to control diagnostics formatting: Language Independent Options.
- (line 6)
-* options to control warnings: Warning Options. (line 6)
-* options, C++: C++ Dialect Options.
- (line 6)
-* options, code generation: Code Gen Options. (line 6)
-* options, debugging: Debugging Options. (line 6)
-* options, dialect: C Dialect Options. (line 6)
-* options, directory search: Directory Options. (line 6)
-* options, GCC command: Invoking GCC. (line 6)
-* options, grouping: Invoking GCC. (line 26)
-* options, linking: Link Options. (line 6)
-* options, Objective-C and Objective-C++: Objective-C and Objective-C++ Dialect Options.
- (line 6)
-* options, optimization: Optimize Options. (line 6)
-* options, order: Invoking GCC. (line 30)
-* options, preprocessor: Preprocessor Options.
- (line 6)
-* order of evaluation, side effects: Non-bugs. (line 196)
-* order of options: Invoking GCC. (line 30)
-* OS_main AVR function attribute: Function Attributes.
- (line 1020)
-* OS_task AVR function attribute: Function Attributes.
- (line 1020)
-* other register constraints: Simple Constraints. (line 163)
-* output file option: Overall Options. (line 191)
-* overloaded virtual function, warning: C++ Dialect Options.
- (line 538)
-* p in constraint: Simple Constraints. (line 154)
-* packed attribute: Variable Attributes.
- (line 145)
-* parameter forward declaration: Variable Length. (line 59)
-* Pascal: G++ and GCC. (line 23)
-* pcs function attribute: Function Attributes.
- (line 1045)
-* PDP-11 Options: PDP-11 Options. (line 6)
-* PIC: Code Gen Options. (line 184)
-* picoChip options: picoChip Options. (line 6)
-* pmf: Bound member functions.
- (line 6)
-* pointer arguments: Function Attributes.
- (line 188)
-* pointer to member function: Bound member functions.
- (line 6)
-* portions of temporary objects, pointers to: Temporaries. (line 6)
-* pow: Other Builtins. (line 6)
-* pow10: Other Builtins. (line 6)
-* pow10f: Other Builtins. (line 6)
-* pow10l: Other Builtins. (line 6)
-* PowerPC options: PowerPC Options. (line 6)
-* powf: Other Builtins. (line 6)
-* powl: Other Builtins. (line 6)
-* pragma GCC optimize: Function Specific Option Pragmas.
- (line 21)
-* pragma GCC pop_options: Function Specific Option Pragmas.
- (line 34)
-* pragma GCC push_options: Function Specific Option Pragmas.
- (line 34)
-* pragma GCC reset_options: Function Specific Option Pragmas.
- (line 44)
-* pragma GCC target: Function Specific Option Pragmas.
- (line 7)
-* pragma, address: M32C Pragmas. (line 15)
-* pragma, align: Solaris Pragmas. (line 11)
-* pragma, call: MeP Pragmas. (line 48)
-* pragma, coprocessor available: MeP Pragmas. (line 13)
-* pragma, coprocessor call_saved: MeP Pragmas. (line 20)
-* pragma, coprocessor subclass: MeP Pragmas. (line 28)
-* pragma, custom io_volatile: MeP Pragmas. (line 7)
-* pragma, diagnostic: Diagnostic Pragmas. (line 14)
-* pragma, disinterrupt: MeP Pragmas. (line 38)
-* pragma, extern_prefix: Symbol-Renaming Pragmas.
- (line 20)
-* pragma, fini: Solaris Pragmas. (line 19)
-* pragma, init: Solaris Pragmas. (line 24)
-* pragma, long_calls: ARM Pragmas. (line 11)
-* pragma, long_calls_off: ARM Pragmas. (line 17)
-* pragma, longcall: RS/6000 and PowerPC Pragmas.
- (line 14)
-* pragma, mark: Darwin Pragmas. (line 11)
-* pragma, memregs: M32C Pragmas. (line 7)
-* pragma, no_long_calls: ARM Pragmas. (line 14)
-* pragma, options align: Darwin Pragmas. (line 14)
-* pragma, pop_macro: Push/Pop Macro Pragmas.
- (line 15)
-* pragma, push_macro: Push/Pop Macro Pragmas.
- (line 11)
-* pragma, reason for not using: Function Attributes.
- (line 1767)
-* pragma, redefine_extname: Symbol-Renaming Pragmas.
- (line 14)
-* pragma, segment: Darwin Pragmas. (line 21)
-* pragma, unused: Darwin Pragmas. (line 24)
-* pragma, visibility: Visibility Pragmas. (line 8)
-* pragma, weak: Weak Pragmas. (line 10)
-* pragmas: Pragmas. (line 6)
-* pragmas in C++, effect on inlining: C++ Interface. (line 66)
-* pragmas, interface and implementation: C++ Interface. (line 6)
-* pragmas, warning of unknown: Warning Options. (line 755)
-* precompiled headers: Precompiled Headers.
- (line 6)
-* preprocessing numbers: Incompatibilities. (line 173)
-* preprocessing tokens: Incompatibilities. (line 173)
-* preprocessor options: Preprocessor Options.
- (line 6)
-* printf: Other Builtins. (line 6)
-* printf_unlocked: Other Builtins. (line 6)
-* prof: Debugging Options. (line 294)
-* progmem AVR variable attribute: Variable Attributes.
- (line 314)
-* promotion of formal parameters: Function Prototypes.
- (line 6)
-* pure function attribute: Function Attributes.
- (line 1063)
-* push address instruction: Simple Constraints. (line 154)
-* putchar: Other Builtins. (line 6)
-* puts: Other Builtins. (line 6)
-* q floating point suffix: Floating Types. (line 6)
-* Q floating point suffix: Floating Types. (line 6)
-* qsort, and global register variables: Global Reg Vars. (line 42)
-* question mark: Multi-Alternative. (line 27)
-* r fixed-suffix: Fixed-Point. (line 6)
-* R fixed-suffix: Fixed-Point. (line 6)
-* r in constraint: Simple Constraints. (line 66)
-* ranges in case statements: Case Ranges. (line 6)
-* read-only strings: Incompatibilities. (line 9)
-* register variable after longjmp: Global Reg Vars. (line 66)
-* registers: Extended Asm. (line 6)
-* registers for local variables: Local Reg Vars. (line 6)
-* registers in constraints: Simple Constraints. (line 66)
-* registers, global allocation: Explicit Reg Vars. (line 6)
-* registers, global variables in: Global Reg Vars. (line 6)
-* regparm attribute: Function Attributes.
- (line 1116)
-* relocation truncated to fit (ColdFire): M680x0 Options. (line 328)
-* relocation truncated to fit (MIPS): MIPS Options. (line 199)
-* remainder: Other Builtins. (line 6)
-* remainderf: Other Builtins. (line 6)
-* remainderl: Other Builtins. (line 6)
-* remquo: Other Builtins. (line 6)
-* remquof: Other Builtins. (line 6)
-* remquol: Other Builtins. (line 6)
-* reordering, warning: C++ Dialect Options.
- (line 463)
-* reporting bugs: Bugs. (line 6)
-* resbank attribute: Function Attributes.
- (line 1148)
-* rest argument (in macro): Variadic Macros. (line 6)
-* restricted pointers: Restricted Pointers.
- (line 6)
-* restricted references: Restricted Pointers.
- (line 6)
-* restricted this pointer: Restricted Pointers.
- (line 6)
-* returns_twice attribute: Function Attributes.
- (line 1162)
-* rindex: Other Builtins. (line 6)
-* rint: Other Builtins. (line 6)
-* rintf: Other Builtins. (line 6)
-* rintl: Other Builtins. (line 6)
-* round: Other Builtins. (line 6)
-* roundf: Other Builtins. (line 6)
-* roundl: Other Builtins. (line 6)
-* RS/6000 and PowerPC Options: RS/6000 and PowerPC Options.
- (line 6)
-* RTTI: Vague Linkage. (line 43)
-* run-time options: Code Gen Options. (line 6)
-* RX Options: RX Options. (line 6)
-* s in constraint: Simple Constraints. (line 102)
-* S/390 and zSeries Options: S/390 and zSeries Options.
- (line 6)
-* save all registers on the Blackfin, H8/300, H8/300H, and H8S: Function Attributes.
- (line 1171)
-* save volatile registers on the MicroBlaze: Function Attributes.
- (line 1176)
-* scalb: Other Builtins. (line 6)
-* scalbf: Other Builtins. (line 6)
-* scalbl: Other Builtins. (line 6)
-* scalbln: Other Builtins. (line 6)
-* scalblnf: Other Builtins. (line 6)
-* scalbn: Other Builtins. (line 6)
-* scalbnf: Other Builtins. (line 6)
-* scanf, and constant strings: Incompatibilities. (line 17)
-* scanfnl: Other Builtins. (line 6)
-* scope of a variable length array: Variable Length. (line 22)
-* scope of declaration: Disappointments. (line 21)
-* scope of external declarations: Incompatibilities. (line 80)
-* Score Options: Score Options. (line 6)
-* search path: Directory Options. (line 6)
-* section function attribute: Function Attributes.
- (line 1184)
-* section variable attribute: Variable Attributes.
- (line 166)
-* sentinel function attribute: Function Attributes.
- (line 1200)
-* setjmp: Global Reg Vars. (line 66)
-* setjmp incompatibilities: Incompatibilities. (line 39)
-* shared strings: Incompatibilities. (line 9)
-* shared variable attribute: Variable Attributes.
- (line 211)
-* side effect in ?:: Conditionals. (line 20)
-* side effects, macro argument: Statement Exprs. (line 35)
-* side effects, order of evaluation: Non-bugs. (line 196)
-* signal handler functions on the AVR processors: Function Attributes.
- (line 1231)
-* signbit: Other Builtins. (line 6)
-* signbitd128: Other Builtins. (line 6)
-* signbitd32: Other Builtins. (line 6)
-* signbitd64: Other Builtins. (line 6)
-* signbitf: Other Builtins. (line 6)
-* signbitl: Other Builtins. (line 6)
-* signed and unsigned values, comparison warning: Warning Options.
- (line 1201)
-* significand: Other Builtins. (line 6)
-* significandf: Other Builtins. (line 6)
-* significandl: Other Builtins. (line 6)
-* simple constraints: Simple Constraints. (line 6)
-* sin: Other Builtins. (line 6)
-* sincos: Other Builtins. (line 6)
-* sincosf: Other Builtins. (line 6)
-* sincosl: Other Builtins. (line 6)
-* sinf: Other Builtins. (line 6)
-* sinh: Other Builtins. (line 6)
-* sinhf: Other Builtins. (line 6)
-* sinhl: Other Builtins. (line 6)
-* sinl: Other Builtins. (line 6)
-* sizeof: Typeof. (line 6)
-* smaller data references: M32R/D Options. (line 57)
-* smaller data references (PowerPC): RS/6000 and PowerPC Options.
- (line 703)
-* snprintf: Other Builtins. (line 6)
-* Solaris 2 options: Solaris 2 Options. (line 6)
-* SPARC options: SPARC Options. (line 6)
-* Spec Files: Spec Files. (line 6)
-* specified registers: Explicit Reg Vars. (line 6)
-* specifying compiler version and target machine: Target Options.
- (line 6)
-* specifying hardware config: Submodel Options. (line 6)
-* specifying machine version: Target Options. (line 6)
-* specifying registers for local variables: Local Reg Vars. (line 6)
-* speed of compilation: Precompiled Headers.
- (line 6)
-* sprintf: Other Builtins. (line 6)
-* SPU options: SPU Options. (line 6)
-* sqrt: Other Builtins. (line 6)
-* sqrtf: Other Builtins. (line 6)
-* sqrtl: Other Builtins. (line 6)
-* sscanf: Other Builtins. (line 6)
-* sscanf, and constant strings: Incompatibilities. (line 17)
-* sseregparm attribute: Function Attributes.
- (line 1133)
-* statements inside expressions: Statement Exprs. (line 6)
-* static data in C++, declaring and defining: Static Definitions.
- (line 6)
-* stpcpy: Other Builtins. (line 6)
-* stpncpy: Other Builtins. (line 6)
-* strcasecmp: Other Builtins. (line 6)
-* strcat: Other Builtins. (line 6)
-* strchr: Other Builtins. (line 6)
-* strcmp: Other Builtins. (line 6)
-* strcpy: Other Builtins. (line 6)
-* strcspn: Other Builtins. (line 6)
-* strdup: Other Builtins. (line 6)
-* strfmon: Other Builtins. (line 6)
-* strftime: Other Builtins. (line 6)
-* string constants: Incompatibilities. (line 9)
-* strlen: Other Builtins. (line 6)
-* strncasecmp: Other Builtins. (line 6)
-* strncat: Other Builtins. (line 6)
-* strncmp: Other Builtins. (line 6)
-* strncpy: Other Builtins. (line 6)
-* strndup: Other Builtins. (line 6)
-* strpbrk: Other Builtins. (line 6)
-* strrchr: Other Builtins. (line 6)
-* strspn: Other Builtins. (line 6)
-* strstr: Other Builtins. (line 6)
-* struct: Unnamed Fields. (line 6)
-* structures: Incompatibilities. (line 146)
-* structures, constructor expression: Compound Literals. (line 6)
-* submodel options: Submodel Options. (line 6)
-* subscripting: Subscripting. (line 6)
-* subscripting and function values: Subscripting. (line 6)
-* suffixes for C++ source: Invoking G++. (line 6)
-* SUNPRO_DEPENDENCIES: Environment Variables.
- (line 169)
-* suppressing warnings: Warning Options. (line 6)
-* surprises in C++: C++ Misunderstandings.
- (line 6)
-* syntax checking: Warning Options. (line 13)
-* syscall_linkage attribute: Function Attributes.
- (line 1253)
-* system headers, warnings from: Warning Options. (line 887)
-* sysv_abi attribute: Function Attributes.
- (line 835)
-* tan: Other Builtins. (line 6)
-* tanf: Other Builtins. (line 6)
-* tanh: Other Builtins. (line 6)
-* tanhf: Other Builtins. (line 6)
-* tanhl: Other Builtins. (line 6)
-* tanl: Other Builtins. (line 6)
-* target function attribute: Function Attributes.
- (line 1260)
-* target machine, specifying: Target Options. (line 6)
-* target options: Target Options. (line 6)
-* target("abm") attribute: Function Attributes.
- (line 1287)
-* target("aes") attribute: Function Attributes.
- (line 1292)
-* target("align-stringops") attribute: Function Attributes.
- (line 1382)
-* target("altivec") attribute: Function Attributes.
- (line 1408)
-* target("arch=ARCH") attribute: Function Attributes.
- (line 1391)
-* target("avoid-indexed-addresses") attribute: Function Attributes.
- (line 1528)
-* target("cld") attribute: Function Attributes.
- (line 1353)
-* target("cmpb") attribute: Function Attributes.
- (line 1414)
-* target("cpu=CPU") attribute: Function Attributes.
- (line 1543)
-* target("dlmzb") attribute: Function Attributes.
- (line 1420)
-* target("fancy-math-387") attribute: Function Attributes.
- (line 1357)
-* target("fma4") attribute: Function Attributes.
- (line 1337)
-* target("fpmath=FPMATH") attribute: Function Attributes.
- (line 1399)
-* target("fprnd") attribute: Function Attributes.
- (line 1427)
-* target("friz") attribute: Function Attributes.
- (line 1519)
-* target("fused-madd") attribute: Function Attributes.
- (line 1362)
-* target("hard-dfp") attribute: Function Attributes.
- (line 1433)
-* target("ieee-fp") attribute: Function Attributes.
- (line 1367)
-* target("inline-all-stringops") attribute: Function Attributes.
- (line 1372)
-* target("inline-stringops-dynamically") attribute: Function Attributes.
- (line 1376)
-* target("isel") attribute: Function Attributes.
- (line 1438)
-* target("longcall") attribute: Function Attributes.
- (line 1538)
-* target("lwp") attribute: Function Attributes.
- (line 1345)
-* target("mfcrf") attribute: Function Attributes.
- (line 1442)
-* target("mfpgpr") attribute: Function Attributes.
- (line 1449)
-* target("mmx") attribute: Function Attributes.
- (line 1296)
-* target("mulhw") attribute: Function Attributes.
- (line 1456)
-* target("multiple") attribute: Function Attributes.
- (line 1463)
-* target("paired") attribute: Function Attributes.
- (line 1533)
-* target("pclmul") attribute: Function Attributes.
- (line 1300)
-* target("popcnt") attribute: Function Attributes.
- (line 1304)
-* target("popcntb") attribute: Function Attributes.
- (line 1474)
-* target("popcntd") attribute: Function Attributes.
- (line 1481)
-* target("powerpc-gfxopt") attribute: Function Attributes.
- (line 1487)
-* target("powerpc-gpopt") attribute: Function Attributes.
- (line 1493)
-* target("recip") attribute: Function Attributes.
- (line 1386)
-* target("recip-precision") attribute: Function Attributes.
- (line 1499)
-* target("sse") attribute: Function Attributes.
- (line 1308)
-* target("sse2") attribute: Function Attributes.
- (line 1312)
-* target("sse3") attribute: Function Attributes.
- (line 1316)
-* target("sse4") attribute: Function Attributes.
- (line 1320)
-* target("sse4.1") attribute: Function Attributes.
- (line 1325)
-* target("sse4.2") attribute: Function Attributes.
- (line 1329)
-* target("sse4a") attribute: Function Attributes.
- (line 1333)
-* target("ssse3") attribute: Function Attributes.
- (line 1349)
-* target("string") attribute: Function Attributes.
- (line 1505)
-* target("tune=TUNE") attribute: Function Attributes.
- (line 1395)
-* target("update") attribute: Function Attributes.
- (line 1468)
-* target("vsx") attribute: Function Attributes.
- (line 1511)
-* target("xop") attribute: Function Attributes.
- (line 1341)
-* TC1: Standards. (line 13)
-* TC2: Standards. (line 13)
-* TC3: Standards. (line 13)
-* Technical Corrigenda: Standards. (line 13)
-* Technical Corrigendum 1: Standards. (line 13)
-* Technical Corrigendum 2: Standards. (line 13)
-* Technical Corrigendum 3: Standards. (line 13)
-* template instantiation: Template Instantiation.
- (line 6)
-* temporaries, lifetime of: Temporaries. (line 6)
-* tgamma: Other Builtins. (line 6)
-* tgammaf: Other Builtins. (line 6)
-* tgammal: Other Builtins. (line 6)
-* Thread-Local Storage: Thread-Local. (line 6)
-* thunks: Nested Functions. (line 6)
-* tiny data section on the H8/300H and H8S: Function Attributes.
- (line 1572)
-* TLS: Thread-Local. (line 6)
-* tls_model attribute: Variable Attributes.
- (line 235)
-* TMPDIR: Environment Variables.
- (line 45)
-* toascii: Other Builtins. (line 6)
-* tolower: Other Builtins. (line 6)
-* toupper: Other Builtins. (line 6)
-* towlower: Other Builtins. (line 6)
-* towupper: Other Builtins. (line 6)
-* traditional C language: C Dialect Options. (line 282)
-* trunc: Other Builtins. (line 6)
-* truncf: Other Builtins. (line 6)
-* truncl: Other Builtins. (line 6)
-* two-stage name lookup: Name lookup. (line 6)
-* type alignment: Alignment. (line 6)
-* type attributes: Type Attributes. (line 6)
-* type_info: Vague Linkage. (line 43)
-* typedef names as function parameters: Incompatibilities. (line 97)
-* typeof: Typeof. (line 6)
-* UHK fixed-suffix: Fixed-Point. (line 6)
-* uhk fixed-suffix: Fixed-Point. (line 6)
-* UHR fixed-suffix: Fixed-Point. (line 6)
-* uhr fixed-suffix: Fixed-Point. (line 6)
-* UK fixed-suffix: Fixed-Point. (line 6)
-* uk fixed-suffix: Fixed-Point. (line 6)
-* ulk fixed-suffix: Fixed-Point. (line 6)
-* ULK fixed-suffix: Fixed-Point. (line 6)
-* ULL integer suffix: Long Long. (line 6)
-* ullk fixed-suffix: Fixed-Point. (line 6)
-* ULLK fixed-suffix: Fixed-Point. (line 6)
-* ULLR fixed-suffix: Fixed-Point. (line 6)
-* ullr fixed-suffix: Fixed-Point. (line 6)
-* ulr fixed-suffix: Fixed-Point. (line 6)
-* ULR fixed-suffix: Fixed-Point. (line 6)
-* undefined behavior: Bug Criteria. (line 17)
-* undefined function value: Bug Criteria. (line 17)
-* underscores in variables in macros: Typeof. (line 46)
-* union: Unnamed Fields. (line 6)
-* union, casting to a: Cast to Union. (line 6)
-* unions: Incompatibilities. (line 146)
-* unknown pragmas, warning: Warning Options. (line 755)
-* unresolved references and -nodefaultlibs: Link Options. (line 82)
-* unresolved references and -nostdlib: Link Options. (line 82)
-* unused attribute.: Function Attributes.
- (line 1584)
-* UR fixed-suffix: Fixed-Point. (line 6)
-* ur fixed-suffix: Fixed-Point. (line 6)
-* use_debug_exception_return attribute: Function Attributes.
- (line 629)
-* use_shadow_register_set attribute: Function Attributes.
- (line 620)
-* used attribute.: Function Attributes.
- (line 1589)
-* User stack pointer in interrupts on the Blackfin: Function Attributes.
- (line 707)
-* V in constraint: Simple Constraints. (line 43)
-* V850 Options: V850 Options. (line 6)
-* vague linkage: Vague Linkage. (line 6)
-* value after longjmp: Global Reg Vars. (line 66)
-* variable addressability on the IA-64: Function Attributes.
- (line 807)
-* variable addressability on the M32R/D: Variable Attributes.
- (line 348)
-* variable alignment: Alignment. (line 6)
-* variable attributes: Variable Attributes.
- (line 6)
-* variable number of arguments: Variadic Macros. (line 6)
-* variable-length array scope: Variable Length. (line 22)
-* variable-length arrays: Variable Length. (line 6)
-* variables in specified registers: Explicit Reg Vars. (line 6)
-* variables, local, in macros: Typeof. (line 46)
-* variadic macros: Variadic Macros. (line 6)
-* VAX options: VAX Options. (line 6)
-* version_id attribute: Function Attributes.
- (line 1595)
-* vfprintf: Other Builtins. (line 6)
-* vfscanf: Other Builtins. (line 6)
-* visibility attribute: Function Attributes.
- (line 1605)
-* VLAs: Variable Length. (line 6)
-* vliw attribute: Function Attributes.
- (line 1699)
-* void pointers, arithmetic: Pointer Arith. (line 6)
-* void, size of pointer to: Pointer Arith. (line 6)
-* volatile access <1>: Volatiles. (line 6)
-* volatile access: C++ Volatiles. (line 6)
-* volatile applied to function: Function Attributes.
- (line 6)
-* volatile read <1>: C++ Volatiles. (line 6)
-* volatile read: Volatiles. (line 6)
-* volatile write <1>: Volatiles. (line 6)
-* volatile write: C++ Volatiles. (line 6)
-* vprintf: Other Builtins. (line 6)
-* vscanf: Other Builtins. (line 6)
-* vsnprintf: Other Builtins. (line 6)
-* vsprintf: Other Builtins. (line 6)
-* vsscanf: Other Builtins. (line 6)
-* vtable: Vague Linkage. (line 28)
-* VxWorks Options: VxWorks Options. (line 6)
-* w floating point suffix: Floating Types. (line 6)
-* W floating point suffix: Floating Types. (line 6)
-* warn_unused_result attribute: Function Attributes.
- (line 1705)
-* warning for comparison of signed and unsigned values: Warning Options.
- (line 1201)
-* warning for overloaded virtual function: C++ Dialect Options.
- (line 538)
-* warning for reordering of member initializers: C++ Dialect Options.
- (line 463)
-* warning for unknown pragmas: Warning Options. (line 755)
-* warning function attribute: Function Attributes.
- (line 165)
-* warning messages: Warning Options. (line 6)
-* warnings from system headers: Warning Options. (line 887)
-* warnings vs errors: Warnings and Errors.
- (line 6)
-* weak attribute: Function Attributes.
- (line 1722)
-* weakref attribute: Function Attributes.
- (line 1731)
-* whitespace: Incompatibilities. (line 112)
-* X in constraint: Simple Constraints. (line 124)
-* X3.159-1989: Standards. (line 13)
-* x86-64 Options: i386 and x86-64 Options.
- (line 6)
-* x86-64 options: x86-64 Options. (line 6)
-* Xstormy16 Options: Xstormy16 Options. (line 6)
-* Xtensa Options: Xtensa Options. (line 6)
-* y0: Other Builtins. (line 6)
-* y0f: Other Builtins. (line 6)
-* y0l: Other Builtins. (line 6)
-* y1: Other Builtins. (line 6)
-* y1f: Other Builtins. (line 6)
-* y1l: Other Builtins. (line 6)
-* yn: Other Builtins. (line 6)
-* ynf: Other Builtins. (line 6)
-* ynl: Other Builtins. (line 6)
-* zero-length arrays: Zero Length. (line 6)
-* zero-size structures: Empty Structures. (line 6)
-* zSeries options: zSeries Options. (line 6)
-
-
-
-Tag Table:
-Node: Top2126
-Node: G++ and GCC3899
-Node: Standards5968
-Node: Invoking GCC18135
-Node: Option Summary21886
-Node: Overall Options59772
-Node: Invoking G++74513
-Node: C Dialect Options76036
-Node: C++ Dialect Options91116
-Node: Objective-C and Objective-C++ Dialect Options116116
-Node: Language Independent Options126655
-Node: Warning Options129579
-Node: Debugging Options198962
-Node: Optimize Options249766
-Ref: Type-punning305804
-Node: Preprocessor Options385215
-Ref: Wtrigraphs389313
-Ref: dashMF394061
-Ref: fdollars-in-identifiers404905
-Node: Assembler Options413466
-Node: Link Options414268
-Ref: Link Options-Footnote-1424626
-Node: Directory Options424960
-Node: Spec Files431249
-Node: Target Options453227
-Node: Submodel Options453626
-Node: ARC Options455245
-Node: ARM Options456435
-Node: AVR Options470166
-Node: Blackfin Options475744
-Node: CRIS Options483692
-Node: CRX Options487433
-Node: Darwin Options487858
-Node: DEC Alpha Options495350
-Node: DEC Alpha/VMS Options507266
-Node: FR30 Options507840
-Node: FRV Options508415
-Node: GNU/Linux Options515132
-Node: H8/300 Options516393
-Node: HPPA Options517460
-Node: i386 and x86-64 Options526960
-Node: i386 and x86-64 Windows Options558120
-Node: IA-64 Options560668
-Node: IA-64/VMS Options568686
-Node: LM32 Options569241
-Node: M32C Options569770
-Node: M32R/D Options571060
-Node: M680x0 Options574647
-Node: M68hc1x Options588654
-Node: MCore Options590223
-Node: MeP Options591730
-Node: MicroBlaze Options595703
-Node: MIPS Options598274
-Node: MMIX Options626194
-Node: MN10300 Options628676
-Node: PDP-11 Options630884
-Node: picoChip Options632578
-Node: PowerPC Options634777
-Node: RS/6000 and PowerPC Options635013
-Node: RX Options671755
-Node: S/390 and zSeries Options677327
-Node: Score Options685258
-Node: SH Options686086
-Node: Solaris 2 Options697225
-Node: SPARC Options698745
-Node: SPU Options708563
-Node: System V Options713567
-Node: V850 Options714390
-Node: VAX Options717969
-Node: VxWorks Options718517
-Node: x86-64 Options719672
-Node: Xstormy16 Options719890
-Node: Xtensa Options720179
-Node: zSeries Options724513
-Node: Code Gen Options724709
-Node: Environment Variables751140
-Node: Precompiled Headers759036
-Node: C Implementation765235
-Node: Translation implementation766898
-Node: Environment implementation767472
-Node: Identifiers implementation768022
-Node: Characters implementation769076
-Node: Integers implementation771882
-Node: Floating point implementation773707
-Node: Arrays and pointers implementation776636
-Ref: Arrays and pointers implementation-Footnote-1778071
-Node: Hints implementation778195
-Node: Structures unions enumerations and bit-fields implementation779661
-Node: Qualifiers implementation781647
-Node: Declarators implementation783419
-Node: Statements implementation783761
-Node: Preprocessing directives implementation784088
-Node: Library functions implementation786193
-Node: Architecture implementation786833
-Node: Locale-specific behavior implementation787536
-Node: C++ Implementation787841
-Node: Conditionally-supported behavior789121
-Node: Exception handling789631
-Node: C Extensions790040
-Node: Statement Exprs794875
-Node: Local Labels799388
-Node: Labels as Values802367
-Ref: Labels as Values-Footnote-1804776
-Node: Nested Functions804959
-Node: Constructing Calls808892
-Node: Typeof813623
-Node: Conditionals816938
-Node: __int128817829
-Node: Long Long818349
-Node: Complex819851
-Node: Floating Types822422
-Node: Half-Precision823560
-Node: Decimal Float825742
-Node: Hex Floats827609
-Node: Fixed-Point828650
-Node: Named Address Spaces831944
-Node: Zero Length833243
-Node: Empty Structures836530
-Node: Variable Length836946
-Node: Variadic Macros839599
-Node: Escaped Newlines841981
-Node: Subscripting842820
-Node: Pointer Arith843543
-Node: Initializers844111
-Node: Compound Literals844607
-Node: Designated Inits846782
-Node: Case Ranges850437
-Node: Cast to Union851120
-Node: Mixed Declarations852216
-Node: Function Attributes852722
-Node: Attribute Syntax933882
-Node: Function Prototypes944328
-Node: C++ Comments946109
-Node: Dollar Signs946628
-Node: Character Escapes947093
-Node: Variable Attributes947387
-Ref: MeP Variable Attributes962713
-Ref: i386 Variable Attributes964674
-Node: Type Attributes970367
-Ref: MeP Type Attributes984108
-Ref: i386 Type Attributes984382
-Ref: PowerPC Type Attributes985222
-Ref: SPU Type Attributes986084
-Node: Alignment986375
-Node: Inline987749
-Node: Volatiles992733
-Node: Extended Asm995628
-Ref: Example of asm with clobbered asm reg1001717
-Ref: Extended asm with goto1011484
-Node: Constraints1019219
-Node: Simple Constraints1020303
-Node: Multi-Alternative1027624
-Node: Modifiers1029341
-Node: Machine Constraints1032235
-Node: Asm Labels1070879
-Node: Explicit Reg Vars1072555
-Node: Global Reg Vars1074163
-Node: Local Reg Vars1078713
-Node: Alternate Keywords1081154
-Node: Incomplete Enums1082640
-Node: Function Names1083397
-Node: Return Address1085559
-Node: Vector Extensions1089112
-Node: Offsetof1093518
-Node: Atomic Builtins1094332
-Node: Object Size Checking1099710
-Node: Other Builtins1105138
-Node: Target Builtins1131818
-Node: Alpha Built-in Functions1132742
-Node: ARM iWMMXt Built-in Functions1135741
-Node: ARM NEON Intrinsics1142460
-Node: Blackfin Built-in Functions1348660
-Node: FR-V Built-in Functions1349274
-Node: Argument Types1350133
-Node: Directly-mapped Integer Functions1351889
-Node: Directly-mapped Media Functions1352971
-Node: Raw read/write Functions1360003
-Node: Other Built-in Functions1360915
-Node: X86 Built-in Functions1362104
-Node: MIPS DSP Built-in Functions1407240
-Node: MIPS Paired-Single Support1419687
-Node: MIPS Loongson Built-in Functions1421188
-Node: Paired-Single Arithmetic1427706
-Node: Paired-Single Built-in Functions1428652
-Node: MIPS-3D Built-in Functions1431322
-Node: picoChip Built-in Functions1436697
-Node: Other MIPS Built-in Functions1438063
-Node: PowerPC AltiVec/VSX Built-in Functions1438587
-Node: RX Built-in Functions1549245
-Node: SPARC VIS Built-in Functions1553255
-Node: SPU Built-in Functions1554934
-Node: Target Format Checks1556716
-Node: Solaris Format Checks1557148
-Node: Darwin Format Checks1557574
-Node: Pragmas1558401
-Node: ARM Pragmas1559111
-Node: M32C Pragmas1559714
-Node: MeP Pragmas1560788
-Node: RS/6000 and PowerPC Pragmas1562857
-Node: Darwin Pragmas1563598
-Node: Solaris Pragmas1564665
-Node: Symbol-Renaming Pragmas1565826
-Node: Structure-Packing Pragmas1568460
-Node: Weak Pragmas1570110
-Node: Diagnostic Pragmas1570844
-Node: Visibility Pragmas1573872
-Node: Push/Pop Macro Pragmas1574624
-Node: Function Specific Option Pragmas1575597
-Node: Unnamed Fields1577861
-Node: Thread-Local1580099
-Node: C99 Thread-Local Edits1582206
-Node: C++98 Thread-Local Edits1584218
-Node: Binary constants1587663
-Node: C++ Extensions1588334
-Node: C++ Volatiles1589982
-Node: Restricted Pointers1592342
-Node: Vague Linkage1593940
-Node: C++ Interface1597602
-Ref: C++ Interface-Footnote-11601899
-Node: Template Instantiation1602036
-Node: Bound member functions1609048
-Node: C++ Attributes1610591
-Node: Namespace Association1612249
-Node: Type Traits1613663
-Node: Java Exceptions1620018
-Node: Deprecated Features1621415
-Node: Backwards Compatibility1624380
-Node: Objective-C1625738
-Node: GNU Objective-C runtime API1626347
-Node: Modern GNU Objective-C runtime API1627354
-Node: Traditional GNU Objective-C runtime API1629791
-Node: Executing code before main1631413
-Node: What you can and what you cannot do in +load1634151
-Node: Type encoding1636541
-Node: Legacy type encoding1641617
-Node: @encode1642708
-Node: Method signatures1643249
-Node: Garbage Collection1645244
-Node: Constant string objects1647878
-Node: compatibility_alias1650386
-Node: Exceptions1651108
-Node: Synchronization1653819
-Node: Fast enumeration1655003
-Node: Using fast enumeration1655315
-Node: c99-like fast enumeration syntax1656526
-Node: Fast enumeration details1657229
-Node: Fast enumeration protocol1659570
-Node: Messaging with the GNU Objective-C runtime1662722
-Node: Dynamically registering methods1664093
-Node: Forwarding hook1665784
-Node: Compatibility1668823
-Node: Gcov1675390
-Node: Gcov Intro1675923
-Node: Invoking Gcov1678641
-Node: Gcov and Optimization1691607
-Node: Gcov Data Files1694262
-Node: Cross-profiling1695402
-Node: Trouble1697253
-Node: Actual Bugs1698738
-Node: Cross-Compiler Problems1699194
-Node: Interoperation1699608
-Node: Incompatibilities1706745
-Node: Fixed Headers1714896
-Node: Standard Libraries1716559
-Node: Disappointments1717931
-Node: C++ Misunderstandings1722289
-Node: Static Definitions1723100
-Node: Name lookup1724153
-Ref: Name lookup-Footnote-11728931
-Node: Temporaries1729118
-Node: Copy Assignment1731094
-Node: Non-bugs1732901
-Node: Warnings and Errors1743408
-Node: Bugs1745172
-Node: Bug Criteria1745736
-Node: Bug Reporting1747946
-Node: Service1748167
-Node: Contributing1748986
-Node: Funding1749726
-Node: GNU Project1752215
-Node: Copying1752861
-Node: GNU Free Documentation License1790389
-Node: Contributors1815526
-Node: Option Index1852395
-Node: Keyword Index2032776
-
-End Tag Table
diff --git a/share/info/gccinstall.info b/share/info/gccinstall.info
deleted file mode 100644
index 408aec4..0000000
--- a/share/info/gccinstall.info
+++ /dev/null
@@ -1,4656 +0,0 @@
-This is doc/gccinstall.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gcc/gcc-4.6/gcc/doc/install.texi.
-
-Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, the Front-Cover texts being (a) (see below), and
-with the Back-Cover Texts being (b) (see below). A copy of the license
-is included in the section entitled "GNU Free Documentation License".
-
- (a) The FSF's Front-Cover Text is:
-
- A GNU Manual
-
- (b) The FSF's Back-Cover Text is:
-
- You have freedom to copy and modify this GNU Manual, like GNU
-software. Copies published by the Free Software Foundation raise
-funds for GNU development.
-
- Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, the Front-Cover texts being (a) (see below), and
-with the Back-Cover Texts being (b) (see below). A copy of the license
-is included in the section entitled "GNU Free Documentation License".
-
- (a) The FSF's Front-Cover Text is:
-
- A GNU Manual
-
- (b) The FSF's Back-Cover Text is:
-
- You have freedom to copy and modify this GNU Manual, like GNU
-software. Copies published by the Free Software Foundation raise
-funds for GNU development.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* gccinstall: (gccinstall). Installing the GNU Compiler Collection.
-END-INFO-DIR-ENTRY
-
-
-File: gccinstall.info, Node: Top, Up: (dir)
-
-* Menu:
-
-* Installing GCC:: This document describes the generic installation
- procedure for GCC as well as detailing some target
- specific installation instructions.
-
-* Specific:: Host/target specific installation notes for GCC.
-* Binaries:: Where to get pre-compiled binaries.
-
-* Old:: Old installation documentation.
-
-* GNU Free Documentation License:: How you can copy and share this manual.
-* Concept Index:: This index has two entries.
-
-
-File: gccinstall.info, Node: Installing GCC, Next: Binaries, Up: Top
-
-1 Installing GCC
-****************
-
- The latest version of this document is always available at
-http://gcc.gnu.org/install/.
-
- This document describes the generic installation procedure for GCC
-as well as detailing some target specific installation instructions.
-
- GCC includes several components that previously were separate
-distributions with their own installation instructions. This document
-supersedes all package specific installation instructions.
-
- _Before_ starting the build/install procedure please check the *note
-host/target specific installation notes: Specific. We recommend you
-browse the entire generic installation instructions before you proceed.
-
- Lists of successful builds for released versions of GCC are
-available at `http://gcc.gnu.org/buildstat.html'. These lists are
-updated as new information becomes available.
-
- The installation procedure itself is broken into five steps.
-
-* Menu:
-
-* Prerequisites::
-* Downloading the source::
-* Configuration::
-* Building::
-* Testing:: (optional)
-* Final install::
-
- Please note that GCC does not support `make uninstall' and probably
-won't do so in the near future as this would open a can of worms.
-Instead, we suggest that you install GCC into a directory of its own
-and simply remove that directory when you do not need that specific
-version of GCC any longer, and, if shared libraries are installed there
-as well, no more binaries exist that use them.
-
-
-File: gccinstall.info, Node: Prerequisites, Next: Downloading the source, Up: Installing GCC
-
-2 Prerequisites
-***************
-
- GCC requires that various tools and packages be available for use in
-the build procedure. Modifying GCC sources requires additional tools
-described below.
-
-Tools/packages necessary for building GCC
-=========================================
-
-ISO C90 compiler
- Necessary to bootstrap GCC, although versions of GCC prior to 3.4
- also allow bootstrapping with a traditional (K&R) C compiler.
-
- To build all languages in a cross-compiler or other configuration
- where 3-stage bootstrap is not performed, you need to start with
- an existing GCC binary (version 2.95 or later) because source code
- for language frontends other than C might use GCC extensions.
-
-GNAT
- In order to build the Ada compiler (GNAT) you must already have
- GNAT installed because portions of the Ada frontend are written in
- Ada (with GNAT extensions.) Refer to the Ada installation
- instructions for more specific information.
-
-A "working" POSIX compatible shell, or GNU bash
- Necessary when running `configure' because some `/bin/sh' shells
- have bugs and may crash when configuring the target libraries. In
- other cases, `/bin/sh' or `ksh' have disastrous corner-case
- performance problems. This can cause target `configure' runs to
- literally take days to complete in some cases.
-
- So on some platforms `/bin/ksh' is sufficient, on others it isn't.
- See the host/target specific instructions for your platform, or
- use `bash' to be sure. Then set `CONFIG_SHELL' in your
- environment to your "good" shell prior to running
- `configure'/`make'.
-
- `zsh' is not a fully compliant POSIX shell and will not work when
- configuring GCC.
-
-A POSIX or SVR4 awk
- Necessary for creating some of the generated source files for GCC.
- If in doubt, use a recent GNU awk version, as some of the older
- ones are broken. GNU awk version 3.1.5 is known to work.
-
-GNU binutils
- Necessary in some circumstances, optional in others. See the
- host/target specific instructions for your platform for the exact
- requirements.
-
-gzip version 1.2.4 (or later) or
-bzip2 version 1.0.2 (or later)
- Necessary to uncompress GCC `tar' files when source code is
- obtained via FTP mirror sites.
-
-GNU make version 3.80 (or later)
- You must have GNU make installed to build GCC.
-
-GNU tar version 1.14 (or later)
- Necessary (only on some platforms) to untar the source code. Many
- systems' `tar' programs will also work, only try GNU `tar' if you
- have problems.
-
-Perl version 5.6.1 (or later)
- Necessary when targetting Darwin, building `libstdc++', and not
- using `--disable-symvers'. Necessary when targetting Solaris 2
- with Sun `ld' and not using `--disable-symvers'. A helper script
- needs `Glob.pm', which is missing from `perl' 5.005 included in
- Solaris 8. The bundled `perl' in Solaris 9 and up works.
-
- Necessary when regenerating `Makefile' dependencies in libiberty.
- Necessary when regenerating `libiberty/functions.texi'. Necessary
- when generating manpages from Texinfo manuals. Used by various
- scripts to generate some files included in SVN (mainly
- Unicode-related and rarely changing) from source tables.
-
-`jar', or InfoZIP (`zip' and `unzip')
- Necessary to build libgcj, the GCJ runtime.
-
-
- Several support libraries are necessary to build GCC, some are
-required, others optional. While any sufficiently new version of
-required tools usually work, library requirements are generally
-stricter. Newer versions may work in some cases, but it's safer to use
-the exact versions documented. We appreciate bug reports about
-problems with newer versions, though.
-
-GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
- Necessary to build GCC. If you do not have it installed in your
- library search path, you will have to configure with the
- `--with-gmp' configure option. See also `--with-gmp-lib' and
- `--with-gmp-include'. Alternatively, if a GMP source distribution
- is found in a subdirectory of your GCC sources named `gmp', it
- will be built together with GCC.
-
-MPFR Library version 2.4.2 (or later)
- Necessary to build GCC. It can be downloaded from
- `http://www.mpfr.org/'. The `--with-mpfr' configure option should
- be used if your MPFR Library is not installed in your default
- library search path. See also `--with-mpfr-lib' and
- `--with-mpfr-include'. Alternatively, if a MPFR source
- distribution is found in a subdirectory of your GCC sources named
- `mpfr', it will be built together with GCC.
-
-MPC Library version 0.8.1 (or later)
- Necessary to build GCC. It can be downloaded from
- `http://www.multiprecision.org/'. The `--with-mpc' configure
- option should be used if your MPC Library is not installed in your
- default library search path. See also `--with-mpc-lib' and
- `--with-mpc-include'. Alternatively, if an MPC source
- distribution is found in a subdirectory of your GCC sources named
- `mpc', it will be built together with GCC.
-
-Parma Polyhedra Library (PPL) version 0.11
- Necessary to build GCC with the Graphite loop optimizations. It
- can be downloaded from `http://www.cs.unipr.it/ppl/Download/'.
-
- The `--with-ppl' configure option should be used if PPL is not
- installed in your default library search path.
-
-CLooG-PPL version 0.15 or CLooG 0.16
- Necessary to build GCC with the Graphite loop optimizations. There
- are two versions available. CLooG-PPL 0.15 as well as CLooG 0.16.
- The former is the default right now. It can be downloaded from
- `ftp://gcc.gnu.org/pub/gcc/infrastructure/' as
- `cloog-ppl-0.15.tar.gz'.
-
- CLooG 0.16 support is still in testing stage, but will be the
- default in future GCC releases. It is also available at
- `ftp://gcc.gnu.org/pub/gcc/infrastructure/' as
- `cloog-0.16.1.tar.gz'. To use it add the additional configure
- option `--enable-cloog-backend=isl'. Even if CLooG 0.16 does not
- use PPL, PPL is still required for Graphite.
-
- In both cases `--with-cloog' configure option should be used if
- CLooG is not installed in your default library search path.
-
-
-Tools/packages necessary for modifying GCC
-==========================================
-
-autoconf version 2.64
-GNU m4 version 1.4.6 (or later)
- Necessary when modifying `configure.ac', `aclocal.m4', etc. to
- regenerate `configure' and `config.in' files.
-
-automake version 1.11.1
- Necessary when modifying a `Makefile.am' file to regenerate its
- associated `Makefile.in'.
-
- Much of GCC does not use automake, so directly edit the
- `Makefile.in' file. Specifically this applies to the `gcc',
- `intl', `libcpp', `libiberty', `libobjc' directories as well as
- any of their subdirectories.
-
- For directories that use automake, GCC requires the latest release
- in the 1.11 series, which is currently 1.11.1. When regenerating
- a directory to a newer version, please update all the directories
- using an older 1.11 to the latest released version.
-
-gettext version 0.14.5 (or later)
- Needed to regenerate `gcc.pot'.
-
-gperf version 2.7.2 (or later)
- Necessary when modifying `gperf' input files, e.g.
- `gcc/cp/cfns.gperf' to regenerate its associated header file, e.g.
- `gcc/cp/cfns.h'.
-
-DejaGnu 1.4.4
-Expect
-Tcl
- Necessary to run the GCC testsuite; see the section on testing for
- details.
-
-autogen version 5.5.4 (or later) and
-guile version 1.4.1 (or later)
- Necessary to regenerate `fixinc/fixincl.x' from
- `fixinc/inclhack.def' and `fixinc/*.tpl'.
-
- Necessary to run `make check' for `fixinc'.
-
- Necessary to regenerate the top level `Makefile.in' file from
- `Makefile.tpl' and `Makefile.def'.
-
-Flex version 2.5.4 (or later)
- Necessary when modifying `*.l' files.
-
- Necessary to build GCC during development because the generated
- output files are not included in the SVN repository. They are
- included in releases.
-
-Texinfo version 4.7 (or later)
- Necessary for running `makeinfo' when modifying `*.texi' files to
- test your changes.
-
- Necessary for running `make dvi' or `make pdf' to create printable
- documentation in DVI or PDF format. Texinfo version 4.8 or later
- is required for `make pdf'.
-
- Necessary to build GCC documentation during development because the
- generated output files are not included in the SVN repository.
- They are included in releases.
-
-TeX (any working version)
- Necessary for running `texi2dvi' and `texi2pdf', which are used
- when running `make dvi' or `make pdf' to create DVI or PDF files,
- respectively.
-
-SVN (any version)
-SSH (any version)
- Necessary to access the SVN repository. Public releases and weekly
- snapshots of the development sources are also available via FTP.
-
-GNU diffutils version 2.7 (or later)
- Useful when submitting patches for the GCC source code.
-
-patch version 2.5.4 (or later)
- Necessary when applying patches, created with `diff', to one's own
- sources.
-
-ecj1
-gjavah
- If you wish to modify `.java' files in libjava, you will need to
- configure with `--enable-java-maintainer-mode', and you will need
- to have executables named `ecj1' and `gjavah' in your path. The
- `ecj1' executable should run the Eclipse Java compiler via the
- GCC-specific entry point. You can download a suitable jar from
- `ftp://sourceware.org/pub/java/', or by running the script
- `contrib/download_ecj'.
-
-antlr.jar version 2.7.1 (or later)
-antlr binary
- If you wish to build the `gjdoc' binary in libjava, you will need
- to have an `antlr.jar' library available. The library is searched
- in system locations but can be configured with `--with-antlr-jar='
- instead. When configuring with `--enable-java-maintainer-mode',
- you will need to have one of the executables named `cantlr',
- `runantlr' or `antlr' in your path.
-
-
-
-File: gccinstall.info, Node: Downloading the source, Next: Configuration, Prev: Prerequisites, Up: Installing GCC
-
-3 Downloading GCC
-*****************
-
- GCC is distributed via SVN and FTP tarballs compressed with `gzip' or
-`bzip2'. It is possible to download a full distribution or specific
-components.
-
- Please refer to the releases web page for information on how to
-obtain GCC.
-
- The full distribution includes the C, C++, Objective-C, Fortran,
-Java, and Ada (in the case of GCC 3.1 and later) compilers. The full
-distribution also includes runtime libraries for C++, Objective-C,
-Fortran, and Java. In GCC 3.0 and later versions, the GNU compiler
-testsuites are also included in the full distribution.
-
- If you choose to download specific components, you must download the
-core GCC distribution plus any language specific distributions you wish
-to use. The core distribution includes the C language front end as
-well as the shared components. Each language has a tarball which
-includes the language front end as well as the language runtime (when
-appropriate).
-
- Unpack the core distribution as well as any language specific
-distributions in the same directory.
-
- If you also intend to build binutils (either to upgrade an existing
-installation or for use in place of the corresponding tools of your
-OS), unpack the binutils distribution either in the same directory or a
-separate one. In the latter case, add symbolic links to any components
-of the binutils you intend to build alongside the compiler (`bfd',
-`binutils', `gas', `gprof', `ld', `opcodes', ...) to the directory
-containing the GCC sources.
-
- Likewise the GMP, MPFR and MPC libraries can be automatically built
-together with GCC. Unpack the GMP, MPFR and/or MPC source
-distributions in the directory containing the GCC sources and rename
-their directories to `gmp', `mpfr' and `mpc', respectively (or use
-symbolic links with the same name).
-
-
-File: gccinstall.info, Node: Configuration, Next: Building, Prev: Downloading the source, Up: Installing GCC
-
-4 Installing GCC: Configuration
-*******************************
-
- Like most GNU software, GCC must be configured before it can be
-built. This document describes the recommended configuration procedure
-for both native and cross targets.
-
- We use SRCDIR to refer to the toplevel source directory for GCC; we
-use OBJDIR to refer to the toplevel build/object directory.
-
- If you obtained the sources via SVN, SRCDIR must refer to the top
-`gcc' directory, the one where the `MAINTAINERS' file can be found, and
-not its `gcc' subdirectory, otherwise the build will fail.
-
- If either SRCDIR or OBJDIR is located on an automounted NFS file
-system, the shell's built-in `pwd' command will return temporary
-pathnames. Using these can lead to various sorts of build problems.
-To avoid this issue, set the `PWDCMD' environment variable to an
-automounter-aware `pwd' command, e.g., `pawd' or `amq -w', during the
-configuration and build phases.
-
- First, we *highly* recommend that GCC be built into a separate
-directory from the sources which does *not* reside within the source
-tree. This is how we generally build GCC; building where SRCDIR ==
-OBJDIR should still work, but doesn't get extensive testing; building
-where OBJDIR is a subdirectory of SRCDIR is unsupported.
-
- If you have previously built GCC in the same directory for a
-different target machine, do `make distclean' to delete all files that
-might be invalid. One of the files this deletes is `Makefile'; if
-`make distclean' complains that `Makefile' does not exist or issues a
-message like "don't know how to make distclean" it probably means that
-the directory is already suitably clean. However, with the recommended
-method of building in a separate OBJDIR, you should simply use a
-different OBJDIR for each target.
-
- Second, when configuring a native system, either `cc' or `gcc' must
-be in your path or you must set `CC' in your environment before running
-configure. Otherwise the configuration scripts may fail.
-
- To configure GCC:
-
- % mkdir OBJDIR
- % cd OBJDIR
- % SRCDIR/configure [OPTIONS] [TARGET]
-
-Distributor options
-===================
-
-If you will be distributing binary versions of GCC, with modifications
-to the source code, you should use the options described in this
-section to make clear that your version contains modifications.
-
-`--with-pkgversion=VERSION'
- Specify a string that identifies your package. You may wish to
- include a build number or build date. This version string will be
- included in the output of `gcc --version'. This suffix does not
- replace the default version string, only the `GCC' part.
-
- The default value is `GCC'.
-
-`--with-bugurl=URL'
- Specify the URL that users should visit if they wish to report a
- bug. You are of course welcome to forward bugs reported to you to
- the FSF, if you determine that they are not bugs in your
- modifications.
-
- The default value refers to the FSF's GCC bug tracker.
-
-
-Target specification
-====================
-
- * GCC has code to correctly determine the correct value for TARGET
- for nearly all native systems. Therefore, we highly recommend you
- do not provide a configure target when configuring a native
- compiler.
-
- * TARGET must be specified as `--target=TARGET' when configuring a
- cross compiler; examples of valid targets would be m68k-elf,
- sh-elf, etc.
-
- * Specifying just TARGET instead of `--target=TARGET' implies that
- the host defaults to TARGET.
-
-Options specification
-=====================
-
-Use OPTIONS to override several configure time options for GCC. A list
-of supported OPTIONS follows; `configure --help' may list other
-options, but those not listed below may not work and should not
-normally be used.
-
- Note that each `--enable' option has a corresponding `--disable'
-option and that each `--with' option has a corresponding `--without'
-option.
-
-`--prefix=DIRNAME'
- Specify the toplevel installation directory. This is the
- recommended way to install the tools into a directory other than
- the default. The toplevel installation directory defaults to
- `/usr/local'.
-
- We *highly* recommend against DIRNAME being the same or a
- subdirectory of OBJDIR or vice versa. If specifying a directory
- beneath a user's home directory tree, some shells will not expand
- DIRNAME correctly if it contains the `~' metacharacter; use
- `$HOME' instead.
-
- The following standard `autoconf' options are supported. Normally
- you should not need to use these options.
- `--exec-prefix=DIRNAME'
- Specify the toplevel installation directory for
- architecture-dependent files. The default is `PREFIX'.
-
- `--bindir=DIRNAME'
- Specify the installation directory for the executables called
- by users (such as `gcc' and `g++'). The default is
- `EXEC-PREFIX/bin'.
-
- `--libdir=DIRNAME'
- Specify the installation directory for object code libraries
- and internal data files of GCC. The default is
- `EXEC-PREFIX/lib'.
-
- `--libexecdir=DIRNAME'
- Specify the installation directory for internal executables
- of GCC. The default is `EXEC-PREFIX/libexec'.
-
- `--with-slibdir=DIRNAME'
- Specify the installation directory for the shared libgcc
- library. The default is `LIBDIR'.
-
- `--datarootdir=DIRNAME'
- Specify the root of the directory tree for read-only
- architecture-independent data files referenced by GCC. The
- default is `PREFIX/share'.
-
- `--infodir=DIRNAME'
- Specify the installation directory for documentation in info
- format. The default is `DATAROOTDIR/info'.
-
- `--datadir=DIRNAME'
- Specify the installation directory for some
- architecture-independent data files referenced by GCC. The
- default is `DATAROOTDIR'.
-
- `--docdir=DIRNAME'
- Specify the installation directory for documentation files
- (other than Info) for GCC. The default is `DATAROOTDIR/doc'.
-
- `--htmldir=DIRNAME'
- Specify the installation directory for HTML documentation
- files. The default is `DOCDIR'.
-
- `--pdfdir=DIRNAME'
- Specify the installation directory for PDF documentation
- files. The default is `DOCDIR'.
-
- `--mandir=DIRNAME'
- Specify the installation directory for manual pages. The
- default is `DATAROOTDIR/man'. (Note that the manual pages
- are only extracts from the full GCC manuals, which are
- provided in Texinfo format. The manpages are derived by an
- automatic conversion process from parts of the full manual.)
-
- `--with-gxx-include-dir=DIRNAME'
- Specify the installation directory for G++ header files. The
- default depends on other configuration options, and differs
- between cross and native configurations.
-
-
-`--program-prefix=PREFIX'
- GCC supports some transformations of the names of its programs when
- installing them. This option prepends PREFIX to the names of
- programs to install in BINDIR (see above). For example, specifying
- `--program-prefix=foo-' would result in `gcc' being installed as
- `/usr/local/bin/foo-gcc'.
-
-`--program-suffix=SUFFIX'
- Appends SUFFIX to the names of programs to install in BINDIR (see
- above). For example, specifying `--program-suffix=-3.1' would
- result in `gcc' being installed as `/usr/local/bin/gcc-3.1'.
-
-`--program-transform-name=PATTERN'
- Applies the `sed' script PATTERN to be applied to the names of
- programs to install in BINDIR (see above). PATTERN has to consist
- of one or more basic `sed' editing commands, separated by
- semicolons. For example, if you want the `gcc' program name to be
- transformed to the installed program `/usr/local/bin/myowngcc' and
- the `g++' program name to be transformed to
- `/usr/local/bin/gspecial++' without changing other program names,
- you could use the pattern
- `--program-transform-name='s/^gcc$/myowngcc/; s/^g++$/gspecial++/''
- to achieve this effect.
-
- All three options can be combined and used together, resulting in
- more complex conversion patterns. As a basic rule, PREFIX (and
- SUFFIX) are prepended (appended) before further transformations
- can happen with a special transformation script PATTERN.
-
- As currently implemented, this option only takes effect for native
- builds; cross compiler binaries' names are not transformed even
- when a transformation is explicitly asked for by one of these
- options.
-
- For native builds, some of the installed programs are also
- installed with the target alias in front of their name, as in
- `i686-pc-linux-gnu-gcc'. All of the above transformations happen
- before the target alias is prepended to the name--so, specifying
- `--program-prefix=foo-' and `program-suffix=-3.1', the resulting
- binary would be installed as
- `/usr/local/bin/i686-pc-linux-gnu-foo-gcc-3.1'.
-
- As a last shortcoming, none of the installed Ada programs are
- transformed yet, which will be fixed in some time.
-
-`--with-local-prefix=DIRNAME'
- Specify the installation directory for local include files. The
- default is `/usr/local'. Specify this option if you want the
- compiler to search directory `DIRNAME/include' for locally
- installed header files _instead_ of `/usr/local/include'.
-
- You should specify `--with-local-prefix' *only* if your site has a
- different convention (not `/usr/local') for where to put
- site-specific files.
-
- The default value for `--with-local-prefix' is `/usr/local'
- regardless of the value of `--prefix'. Specifying `--prefix' has
- no effect on which directory GCC searches for local header files.
- This may seem counterintuitive, but actually it is logical.
-
- The purpose of `--prefix' is to specify where to _install GCC_.
- The local header files in `/usr/local/include'--if you put any in
- that directory--are not part of GCC. They are part of other
- programs--perhaps many others. (GCC installs its own header files
- in another directory which is based on the `--prefix' value.)
-
- Both the local-prefix include directory and the GCC-prefix include
- directory are part of GCC's "system include" directories.
- Although these two directories are not fixed, they need to be
- searched in the proper order for the correct processing of the
- include_next directive. The local-prefix include directory is
- searched before the GCC-prefix include directory. Another
- characteristic of system include directories is that pedantic
- warnings are turned off for headers in these directories.
-
- Some autoconf macros add `-I DIRECTORY' options to the compiler
- command line, to ensure that directories containing installed
- packages' headers are searched. When DIRECTORY is one of GCC's
- system include directories, GCC will ignore the option so that
- system directories continue to be processed in the correct order.
- This may result in a search order different from what was
- specified but the directory will still be searched.
-
- GCC automatically searches for ordinary libraries using
- `GCC_EXEC_PREFIX'. Thus, when the same installation prefix is
- used for both GCC and packages, GCC will automatically search for
- both headers and libraries. This provides a configuration that is
- easy to use. GCC behaves in a manner similar to that when it is
- installed as a system compiler in `/usr'.
-
- Sites that need to install multiple versions of GCC may not want to
- use the above simple configuration. It is possible to use the
- `--program-prefix', `--program-suffix' and
- `--program-transform-name' options to install multiple versions
- into a single directory, but it may be simpler to use different
- prefixes and the `--with-local-prefix' option to specify the
- location of the site-specific files for each version. It will
- then be necessary for users to specify explicitly the location of
- local site libraries (e.g., with `LIBRARY_PATH').
-
- The same value can be used for both `--with-local-prefix' and
- `--prefix' provided it is not `/usr'. This can be used to avoid
- the default search of `/usr/local/include'.
-
- *Do not* specify `/usr' as the `--with-local-prefix'! The
- directory you use for `--with-local-prefix' *must not* contain any
- of the system's standard header files. If it did contain them,
- certain programs would be miscompiled (including GNU Emacs, on
- certain targets), because this would override and nullify the
- header file corrections made by the `fixincludes' script.
-
- Indications are that people who use this option use it based on
- mistaken ideas of what it is for. People use it as if it
- specified where to install part of GCC. Perhaps they make this
- assumption because installing GCC creates the directory.
-
-`--with-runtime-root-prefix=DIRNAME'
- Specifies that DIRNAME is to be used as a prefix before paths to
- files used at runtime, such as the path to the dynamic linker.
- For instance, if the dynamic linker is normally `/lib/ld.so' and
- this option is given as:
- --with-runtime-root-prefix=/other
- then the compiler will cause compiled executables to use
- `/other/lib/ld.so' as their dynamic linker at runtime. This option
- is currently only supported by some targets, notably Linux.
-
-`--with-native-system-header-dir=DIRNAME'
- Specifies that DIRNAME is the directory that contains native system
- header files, rather than `/usr/include'. This option is most
- useful if you are creating a compiler that should be isolated from
- the system as much as possible. It is most commonly used with the
- `--with-sysroot' option and will cause GCC to search DIRNAME
- inside the system root specified by that option.
-
- Please note that for certain targets, such as DJGPP, this value is
- ignored. If the target specifies a default value for native system
- header files then this option is ignored.
-
-`--enable-shared[=PACKAGE[,...]]'
- Build shared versions of libraries, if shared libraries are
- supported on the target platform. Unlike GCC 2.95.x and earlier,
- shared libraries are enabled by default on all platforms that
- support shared libraries.
-
- If a list of packages is given as an argument, build shared
- libraries only for the listed packages. For other packages, only
- static libraries will be built. Package names currently
- recognized in the GCC tree are `libgcc' (also known as `gcc'),
- `libstdc++' (not `libstdc++-v3'), `libffi', `zlib', `boehm-gc',
- `ada', `libada', `libjava', `libgo', and `libobjc'. Note
- `libiberty' does not support shared libraries at all.
-
- Use `--disable-shared' to build only static libraries. Note that
- `--disable-shared' does not accept a list of package names as
- argument, only `--enable-shared' does.
-
-`--with-gnu-as'
- Specify that the compiler should assume that the assembler it
- finds is the GNU assembler. However, this does not modify the
- rules to find an assembler and will result in confusion if the
- assembler found is not actually the GNU assembler. (Confusion may
- also result if the compiler finds the GNU assembler but has not
- been configured with `--with-gnu-as'.) If you have more than one
- assembler installed on your system, you may want to use this
- option in connection with `--with-as=PATHNAME' or
- `--with-build-time-tools=PATHNAME'.
-
- The following systems are the only ones where it makes a difference
- whether you use the GNU assembler. On any other system,
- `--with-gnu-as' has no effect.
-
- * `hppa1.0-ANY-ANY'
-
- * `hppa1.1-ANY-ANY'
-
- * `sparc-sun-solaris2.ANY'
-
- * `sparc64-ANY-solaris2.ANY'
-
-`--with-as=PATHNAME'
- Specify that the compiler should use the assembler pointed to by
- PATHNAME, rather than the one found by the standard rules to find
- an assembler, which are:
- * Unless GCC is being built with a cross compiler, check the
- `LIBEXEC/gcc/TARGET/VERSION' directory. LIBEXEC defaults to
- `EXEC-PREFIX/libexec'; EXEC-PREFIX defaults to PREFIX, which
- defaults to `/usr/local' unless overridden by the
- `--prefix=PATHNAME' switch described above. TARGET is the
- target system triple, such as `sparc-sun-solaris2.7', and
- VERSION denotes the GCC version, such as 3.0.
-
- * If the target system is the same that you are building on,
- check operating system specific directories (e.g.
- `/usr/ccs/bin' on Sun Solaris 2).
-
- * Check in the `PATH' for a tool whose name is prefixed by the
- target system triple.
-
- * Check in the `PATH' for a tool whose name is not prefixed by
- the target system triple, if the host and target system
- triple are the same (in other words, we use a host tool if it
- can be used for the target as well).
-
- You may want to use `--with-as' if no assembler is installed in
- the directories listed above, or if you have multiple assemblers
- installed and want to choose one that is not found by the above
- rules.
-
-`--with-gnu-ld'
- Same as `--with-gnu-as' but for the linker.
-
-`--with-ld=PATHNAME'
- Same as `--with-as' but for the linker.
-
-`--with-stabs'
- Specify that stabs debugging information should be used instead of
- whatever format the host normally uses. Normally GCC uses the
- same debug format as the host system.
-
- On MIPS based systems and on Alphas, you must specify whether you
- want GCC to create the normal ECOFF debugging format, or to use
- BSD-style stabs passed through the ECOFF symbol table. The normal
- ECOFF debug format cannot fully handle languages other than C.
- BSD stabs format can handle other languages, but it only works
- with the GNU debugger GDB.
-
- Normally, GCC uses the ECOFF debugging format by default; if you
- prefer BSD stabs, specify `--with-stabs' when you configure GCC.
-
- No matter which default you choose when you configure GCC, the user
- can use the `-gcoff' and `-gstabs+' options to specify explicitly
- the debug format for a particular compilation.
-
- `--with-stabs' is meaningful on the ISC system on the 386, also, if
- `--with-gas' is used. It selects use of stabs debugging
- information embedded in COFF output. This kind of debugging
- information supports C++ well; ordinary COFF debugging information
- does not.
-
- `--with-stabs' is also meaningful on 386 systems running SVR4. It
- selects use of stabs debugging information embedded in ELF output.
- The C++ compiler currently (2.6.0) does not support the DWARF
- debugging information normally used on 386 SVR4 platforms; stabs
- provide a workable alternative. This requires gas and gdb, as the
- normal SVR4 tools can not generate or interpret stabs.
-
-`--disable-multilib'
- Specify that multiple target libraries to support different target
- variants, calling conventions, etc. should not be built. The
- default is to build a predefined set of them.
-
- Some targets provide finer-grained control over which multilibs
- are built (e.g., `--disable-softfloat'):
- `arc-*-elf*'
- biendian.
-
- `arm-*-*'
- fpu, 26bit, underscore, interwork, biendian, nofmult.
-
- `m68*-*-*'
- softfloat, m68881, m68000, m68020.
-
- `mips*-*-*'
- single-float, biendian, softfloat.
-
- `powerpc*-*-*, rs6000*-*-*'
- aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos,
- biendian, sysv, aix.
-
-
-`--with-multilib-list=LIST'
-`--without-multilib-list'
- Specify what multilibs to build. Currently only implemented for
- sh*-*-*.
-
- LIST is a comma separated list of CPU names. These must be of the
- form `sh*' or `m*' (in which case they match the compiler option
- for that processor). The list should not contain any endian
- options - these are handled by `--with-endian'.
-
- If LIST is empty, then there will be no multilibs for extra
- processors. The multilib for the secondary endian remains enabled.
-
- As a special case, if an entry in the list starts with a `!'
- (exclamation point), then it is added to the list of excluded
- multilibs. Entries of this sort should be compatible with
- `MULTILIB_EXCLUDES' (once the leading `!' has been stripped).
-
- If `--with-multilib-list' is not given, then a default set of
- multilibs is selected based on the value of `--target'. This is
- usually the complete set of libraries, but some targets imply a
- more specialized subset.
-
- Example 1: to configure a compiler for SH4A only, but supporting
- both endians, with little endian being the default:
- --with-cpu=sh4a --with-endian=little,big --with-multilib-list=
-
- Example 2: to configure a compiler for both SH4A and SH4AL-DSP,
- but with only little endian SH4AL:
- --with-cpu=sh4a --with-endian=little,big \
- --with-multilib-list=sh4al,!mb/m4al
-
-`--with-endian=ENDIANS'
- Specify what endians to use. Currently only implemented for
- sh*-*-*.
-
- ENDIANS may be one of the following:
- `big'
- Use big endian exclusively.
-
- `little'
- Use little endian exclusively.
-
- `big,little'
- Use big endian by default. Provide a multilib for little
- endian.
-
- `little,big'
- Use little endian by default. Provide a multilib for big
- endian.
-
-`--enable-threads'
- Specify that the target supports threads. This affects the
- Objective-C compiler and runtime library, and exception handling
- for other languages like C++ and Java. On some systems, this is
- the default.
-
- In general, the best (and, in many cases, the only known) threading
- model available will be configured for use. Beware that on some
- systems, GCC has not been taught what threading models are
- generally available for the system. In this case,
- `--enable-threads' is an alias for `--enable-threads=single'.
-
-`--disable-threads'
- Specify that threading support should be disabled for the system.
- This is an alias for `--enable-threads=single'.
-
-`--enable-threads=LIB'
- Specify that LIB is the thread support library. This affects the
- Objective-C compiler and runtime library, and exception handling
- for other languages like C++ and Java. The possibilities for LIB
- are:
-
- `aix'
- AIX thread support.
-
- `dce'
- DCE thread support.
-
- `gnat'
- Ada tasking support. For non-Ada programs, this setting is
- equivalent to `single'. When used in conjunction with the
- Ada run time, it causes GCC to use the same thread primitives
- as Ada uses. This option is necessary when using both Ada
- and the back end exception handling, which is the default for
- most Ada targets.
-
- `mach'
- Generic MACH thread support, known to work on NeXTSTEP.
- (Please note that the file needed to support this
- configuration, `gthr-mach.h', is missing and thus this
- setting will cause a known bootstrap failure.)
-
- `no'
- This is an alias for `single'.
-
- `posix'
- Generic POSIX/Unix98 thread support.
-
- `posix95'
- Generic POSIX/Unix95 thread support.
-
- `rtems'
- RTEMS thread support.
-
- `single'
- Disable thread support, should work for all platforms.
-
- `solaris'
- Sun Solaris 2/Unix International thread support. Only use
- this if you really need to use this legacy API instead of the
- default, `posix'.
-
- `vxworks'
- VxWorks thread support.
-
- `win32'
- Microsoft Win32 API thread support.
-
- `nks'
- Novell Kernel Services thread support.
-
-`--enable-tls'
- Specify that the target supports TLS (Thread Local Storage).
- Usually configure can correctly determine if TLS is supported. In
- cases where it guesses incorrectly, TLS can be explicitly enabled
- or disabled with `--enable-tls' or `--disable-tls'. This can
- happen if the assembler supports TLS but the C library does not,
- or if the assumptions made by the configure test are incorrect.
-
-`--disable-tls'
- Specify that the target does not support TLS. This is an alias
- for `--enable-tls=no'.
-
-`--with-cpu=CPU'
-`--with-cpu-32=CPU'
-`--with-cpu-64=CPU'
- Specify which cpu variant the compiler should generate code for by
- default. CPU will be used as the default value of the `-mcpu='
- switch. This option is only supported on some targets, including
- ARM, i386, M68k, PowerPC, and SPARC. The `--with-cpu-32' and
- `--with-cpu-64' options specify separate default CPUs for 32-bit
- and 64-bit modes; these options are only supported for i386,
- x86-64 and PowerPC.
-
-`--with-schedule=CPU'
-`--with-arch=CPU'
-`--with-arch-32=CPU'
-`--with-arch-64=CPU'
-`--with-tune=CPU'
-`--with-tune-32=CPU'
-`--with-tune-64=CPU'
-`--with-abi=ABI'
-`--with-fpu=TYPE'
-`--with-float=TYPE'
- These configure options provide default values for the
- `-mschedule=', `-march=', `-mtune=', `-mabi=', and `-mfpu='
- options and for `-mhard-float' or `-msoft-float'. As with
- `--with-cpu', which switches will be accepted and acceptable values
- of the arguments depend on the target.
-
-`--with-mode=MODE'
- Specify if the compiler should default to `-marm' or `-mthumb'.
- This option is only supported on ARM targets.
-
-`--with-fpmath=ISA'
- This options sets `-mfpmath=sse' by default and specifies the
- default ISA for floating-point arithmetics. You can select either
- `sse' which enables `-msse2' or `avx' which enables `-mavx' by
- default. This option is only supported on i386 and x86-64 targets.
-
-`--with-divide=TYPE'
- Specify how the compiler should generate code for checking for
- division by zero. This option is only supported on the MIPS
- target. The possibilities for TYPE are:
- `traps'
- Division by zero checks use conditional traps (this is the
- default on systems that support conditional traps).
-
- `breaks'
- Division by zero checks use the break instruction.
-
-`--with-llsc'
- On MIPS targets, make `-mllsc' the default when no `-mno-lsc'
- option is passed. This is the default for Linux-based targets, as
- the kernel will emulate them if the ISA does not provide them.
-
-`--without-llsc'
- On MIPS targets, make `-mno-llsc' the default when no `-mllsc'
- option is passed.
-
-`--with-synci'
- On MIPS targets, make `-msynci' the default when no `-mno-synci'
- option is passed.
-
-`--without-synci'
- On MIPS targets, make `-mno-synci' the default when no `-msynci'
- option is passed. This is the default.
-
-`--with-mips-plt'
- On MIPS targets, make use of copy relocations and PLTs. These
- features are extensions to the traditional SVR4-based MIPS ABIs
- and require support from GNU binutils and the runtime C library.
-
-`--enable-__cxa_atexit'
- Define if you want to use __cxa_atexit, rather than atexit, to
- register C++ destructors for local statics and global objects.
- This is essential for fully standards-compliant handling of
- destructors, but requires __cxa_atexit in libc. This option is
- currently only available on systems with GNU libc. When enabled,
- this will cause `-fuse-cxa-atexit' to be passed by default.
-
-`--enable-indirect-function'
- Define if you want to enable the `ifunc' attribute. This option is
- currently only available on systems with GNU libc on certain
- targets.
-
-`--enable-target-optspace'
- Specify that target libraries should be optimized for code space
- instead of code speed. This is the default for the m32r platform.
-
-`--with-cpp-install-dir=DIRNAME'
- Specify that the user visible `cpp' program should be installed in
- `PREFIX/DIRNAME/cpp', in addition to BINDIR.
-
-`--enable-comdat'
- Enable COMDAT group support. This is primarily used to override
- the automatically detected value.
-
-`--enable-initfini-array'
- Force the use of sections `.init_array' and `.fini_array' (instead
- of `.init' and `.fini') for constructors and destructors. Option
- `--disable-initfini-array' has the opposite effect. If neither
- option is specified, the configure script will try to guess
- whether the `.init_array' and `.fini_array' sections are supported
- and, if they are, use them.
-
-`--enable-build-with-cxx'
- Build GCC using a C++ compiler rather than a C compiler. This is
- an experimental option which may become the default in a later
- release.
-
-`--enable-maintainer-mode'
- The build rules that regenerate the Autoconf and Automake output
- files as well as the GCC master message catalog `gcc.pot' are
- normally disabled. This is because it can only be rebuilt if the
- complete source tree is present. If you have changed the sources
- and want to rebuild the catalog, configuring with
- `--enable-maintainer-mode' will enable this. Note that you need a
- recent version of the `gettext' tools to do so.
-
-`--disable-bootstrap'
- For a native build, the default configuration is to perform a
- 3-stage bootstrap of the compiler when `make' is invoked, testing
- that GCC can compile itself correctly. If you want to disable
- this process, you can configure with `--disable-bootstrap'.
-
-`--enable-bootstrap'
- In special cases, you may want to perform a 3-stage build even if
- the target and host triplets are different. This is possible when
- the host can run code compiled for the target (e.g. host is
- i686-linux, target is i486-linux). Starting from GCC 4.2, to do
- this you have to configure explicitly with `--enable-bootstrap'.
-
-`--enable-generated-files-in-srcdir'
- Neither the .c and .h files that are generated from Bison and flex
- nor the info manuals and man pages that are built from the .texi
- files are present in the SVN development tree. When building GCC
- from that development tree, or from one of our snapshots, those
- generated files are placed in your build directory, which allows
- for the source to be in a readonly directory.
-
- If you configure with `--enable-generated-files-in-srcdir' then
- those generated files will go into the source directory. This is
- mainly intended for generating release or prerelease tarballs of
- the GCC sources, since it is not a requirement that the users of
- source releases to have flex, Bison, or makeinfo.
-
-`--enable-version-specific-runtime-libs'
- Specify that runtime libraries should be installed in the compiler
- specific subdirectory (`LIBDIR/gcc') rather than the usual places.
- In addition, `libstdc++''s include files will be installed into
- `LIBDIR' unless you overruled it by using
- `--with-gxx-include-dir=DIRNAME'. Using this option is
- particularly useful if you intend to use several versions of GCC in
- parallel. This is currently supported by `libgfortran',
- `libjava', `libmudflap', `libstdc++', and `libobjc'.
-
-`--enable-languages=LANG1,LANG2,...'
- Specify that only a particular subset of compilers and their
- runtime libraries should be built. For a list of valid values for
- LANGN you can issue the following command in the `gcc' directory
- of your GCC source tree:
- grep language= */config-lang.in
- Currently, you can use any of the following: `all', `ada', `c',
- `c++', `fortran', `go', `java', `objc', `obj-c++'. Building the
- Ada compiler has special requirements, see below. If you do not
- pass this flag, or specify the option `all', then all default
- languages available in the `gcc' sub-tree will be configured.
- Ada, Go and Objective-C++ are not default languages; the rest are.
-
-`--enable-stage1-languages=LANG1,LANG2,...'
- Specify that a particular subset of compilers and their runtime
- libraries should be built with the system C compiler during stage
- 1 of the bootstrap process, rather than only in later stages with
- the bootstrapped C compiler. The list of valid values is the same
- as for `--enable-languages', and the option `all' will select all
- of the languages enabled by `--enable-languages'. This option is
- primarily useful for GCC development; for instance, when a
- development version of the compiler cannot bootstrap due to
- compiler bugs, or when one is debugging front ends other than the
- C front end. When this option is used, one can then build the
- target libraries for the specified languages with the stage-1
- compiler by using `make stage1-bubble all-target', or run the
- testsuite on the stage-1 compiler for the specified languages
- using `make stage1-start check-gcc'.
-
-`--disable-libada'
- Specify that the run-time libraries and tools used by GNAT should
- not be built. This can be useful for debugging, or for
- compatibility with previous Ada build procedures, when it was
- required to explicitly do a `make -C gcc gnatlib_and_tools'.
-
-`--disable-libssp'
- Specify that the run-time libraries for stack smashing protection
- should not be built.
-
-`--disable-libquadmath'
- Specify that the GCC quad-precision math library should not be
- built. On some systems, the library is required to be linkable
- when building the Fortran front end, unless
- `--disable-libquadmath-support' is used.
-
-`--disable-libquadmath-support'
- Specify that the Fortran front end and `libgfortran' do not add
- support for `libquadmath' on systems supporting it.
-
-`--disable-libgomp'
- Specify that the run-time libraries used by GOMP should not be
- built.
-
-`--with-dwarf2'
- Specify that the compiler should use DWARF 2 debugging information
- as the default.
-
-`--enable-targets=all'
-`--enable-targets=TARGET_LIST'
- Some GCC targets, e.g. powerpc64-linux, build bi-arch compilers.
- These are compilers that are able to generate either 64-bit or
- 32-bit code. Typically, the corresponding 32-bit target, e.g.
- powerpc-linux for powerpc64-linux, only generates 32-bit code.
- This option enables the 32-bit target to be a bi-arch compiler,
- which is useful when you want a bi-arch compiler that defaults to
- 32-bit, and you are building a bi-arch or multi-arch binutils in a
- combined tree. On mips-linux, this will build a tri-arch compiler
- (ABI o32/n32/64), defaulted to o32. Currently, this option only
- affects sparc-linux, powerpc-linux, x86-linux and mips-linux.
-
-`--enable-secureplt'
- This option enables `-msecure-plt' by default for powerpc-linux.
- *Note RS/6000 and PowerPC Options: (gcc)RS/6000 and PowerPC
- Options,
-
-`--enable-cld'
- This option enables `-mcld' by default for 32-bit x86 targets.
- *Note i386 and x86-64 Options: (gcc)i386 and x86-64 Options,
-
-`--enable-win32-registry'
-`--enable-win32-registry=KEY'
-`--disable-win32-registry'
- The `--enable-win32-registry' option enables Microsoft
- Windows-hosted GCC to look up installations paths in the registry
- using the following key:
-
- `HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\KEY'
-
- KEY defaults to GCC version number, and can be overridden by the
- `--enable-win32-registry=KEY' option. Vendors and distributors
- who use custom installers are encouraged to provide a different
- key, perhaps one comprised of vendor name and GCC version number,
- to avoid conflict with existing installations. This feature is
- enabled by default, and can be disabled by
- `--disable-win32-registry' option. This option has no effect on
- the other hosts.
-
-`--nfp'
- Specify that the machine does not have a floating point unit. This
- option only applies to `m68k-sun-sunosN'. On any other system,
- `--nfp' has no effect.
-
-`--enable-werror'
-`--disable-werror'
-`--enable-werror=yes'
-`--enable-werror=no'
- When you specify this option, it controls whether certain files in
- the compiler are built with `-Werror' in bootstrap stage2 and
- later. If you don't specify it, `-Werror' is turned on for the
- main development trunk. However it defaults to off for release
- branches and final releases. The specific files which get
- `-Werror' are controlled by the Makefiles.
-
-`--enable-checking'
-`--enable-checking=LIST'
- When you specify this option, the compiler is built to perform
- internal consistency checks of the requested complexity. This
- does not change the generated code, but adds error checking within
- the compiler. This will slow down the compiler and may only work
- properly if you are building the compiler with GCC. This is `yes'
- by default when building from SVN or snapshots, but `release' for
- releases. The default for building the stage1 compiler is `yes'.
- More control over the checks may be had by specifying LIST. The
- categories of checks available are `yes' (most common checks
- `assert,misc,tree,gc,rtlflag,runtime'), `no' (no checks at all),
- `all' (all but `valgrind'), `release' (cheapest checks
- `assert,runtime') or `none' (same as `no'). Individual checks can
- be enabled with these flags `assert', `df', `fold', `gc', `gcac'
- `misc', `rtl', `rtlflag', `runtime', `tree', and `valgrind'.
-
- The `valgrind' check requires the external `valgrind' simulator,
- available from `http://valgrind.org/'. The `df', `rtl', `gcac'
- and `valgrind' checks are very expensive. To disable all
- checking, `--disable-checking' or `--enable-checking=none' must be
- explicitly requested. Disabling assertions will make the compiler
- and runtime slightly faster but increase the risk of undetected
- internal errors causing wrong code to be generated.
-
-`--disable-stage1-checking'
-`--enable-stage1-checking'
-`--enable-stage1-checking=LIST'
- If no `--enable-checking' option is specified the stage1 compiler
- will be built with `yes' checking enabled, otherwise the stage1
- checking flags are the same as specified by `--enable-checking'.
- To build the stage1 compiler with different checking options use
- `--enable-stage1-checking'. The list of checking options is the
- same as for `--enable-checking'. If your system is too slow or
- too small to bootstrap a released compiler with checking for
- stage1 enabled, you can use `--disable-stage1-checking' to disable
- checking for the stage1 compiler.
-
-`--enable-coverage'
-`--enable-coverage=LEVEL'
- With this option, the compiler is built to collect self coverage
- information, every time it is run. This is for internal
- development purposes, and only works when the compiler is being
- built with gcc. The LEVEL argument controls whether the compiler
- is built optimized or not, values are `opt' and `noopt'. For
- coverage analysis you want to disable optimization, for
- performance analysis you want to enable optimization. When
- coverage is enabled, the default level is without optimization.
-
-`--enable-gather-detailed-mem-stats'
- When this option is specified more detailed information on memory
- allocation is gathered. This information is printed when using
- `-fmem-report'.
-
-`--with-gc'
-`--with-gc=CHOICE'
- With this option you can specify the garbage collector
- implementation used during the compilation process. CHOICE can be
- one of `page' and `zone', where `page' is the default.
-
-`--enable-nls'
-`--disable-nls'
- The `--enable-nls' option enables Native Language Support (NLS),
- which lets GCC output diagnostics in languages other than American
- English. Native Language Support is enabled by default if not
- doing a canadian cross build. The `--disable-nls' option disables
- NLS.
-
-`--with-included-gettext'
- If NLS is enabled, the `--with-included-gettext' option causes the
- build procedure to prefer its copy of GNU `gettext'.
-
-`--with-catgets'
- If NLS is enabled, and if the host lacks `gettext' but has the
- inferior `catgets' interface, the GCC build procedure normally
- ignores `catgets' and instead uses GCC's copy of the GNU `gettext'
- library. The `--with-catgets' option causes the build procedure
- to use the host's `catgets' in this situation.
-
-`--with-libiconv-prefix=DIR'
- Search for libiconv header files in `DIR/include' and libiconv
- library files in `DIR/lib'.
-
-`--enable-obsolete'
- Enable configuration for an obsoleted system. If you attempt to
- configure GCC for a system (build, host, or target) which has been
- obsoleted, and you do not specify this flag, configure will halt
- with an error message.
-
- All support for systems which have been obsoleted in one release
- of GCC is removed entirely in the next major release, unless
- someone steps forward to maintain the port.
-
-`--enable-decimal-float'
-`--enable-decimal-float=yes'
-`--enable-decimal-float=no'
-`--enable-decimal-float=bid'
-`--enable-decimal-float=dpd'
-`--disable-decimal-float'
- Enable (or disable) support for the C decimal floating point
- extension that is in the IEEE 754-2008 standard. This is enabled
- by default only on PowerPC, i386, and x86_64 GNU/Linux systems.
- Other systems may also support it, but require the user to
- specifically enable it. You can optionally control which decimal
- floating point format is used (either `bid' or `dpd'). The `bid'
- (binary integer decimal) format is default on i386 and x86_64
- systems, and the `dpd' (densely packed decimal) format is default
- on PowerPC systems.
-
-`--enable-fixed-point'
-`--disable-fixed-point'
- Enable (or disable) support for C fixed-point arithmetic. This
- option is enabled by default for some targets (such as MIPS) which
- have hardware-support for fixed-point operations. On other
- targets, you may enable this option manually.
-
-`--with-long-double-128'
- Specify if `long double' type should be 128-bit by default on
- selected GNU/Linux architectures. If using
- `--without-long-double-128', `long double' will be by default
- 64-bit, the same as `double' type. When neither of these
- configure options are used, the default will be 128-bit `long
- double' when built against GNU C Library 2.4 and later, 64-bit
- `long double' otherwise.
-
-`--with-gmp=PATHNAME'
-`--with-gmp-include=PATHNAME'
-`--with-gmp-lib=PATHNAME'
-`--with-mpfr=PATHNAME'
-`--with-mpfr-include=PATHNAME'
-`--with-mpfr-lib=PATHNAME'
-`--with-mpc=PATHNAME'
-`--with-mpc-include=PATHNAME'
-`--with-mpc-lib=PATHNAME'
- If you do not have GMP (the GNU Multiple Precision library), the
- MPFR library and/or the MPC library installed in a standard
- location and you want to build GCC, you can explicitly specify the
- directory where they are installed (`--with-gmp=GMPINSTALLDIR',
- `--with-mpfr=MPFRINSTALLDIR', `--with-mpc=MPCINSTALLDIR'). The
- `--with-gmp=GMPINSTALLDIR' option is shorthand for
- `--with-gmp-lib=GMPINSTALLDIR/lib' and
- `--with-gmp-include=GMPINSTALLDIR/include'. Likewise the
- `--with-mpfr=MPFRINSTALLDIR' option is shorthand for
- `--with-mpfr-lib=MPFRINSTALLDIR/lib' and
- `--with-mpfr-include=MPFRINSTALLDIR/include', also the
- `--with-mpc=MPCINSTALLDIR' option is shorthand for
- `--with-mpc-lib=MPCINSTALLDIR/lib' and
- `--with-mpc-include=MPCINSTALLDIR/include'. If these shorthand
- assumptions are not correct, you can use the explicit include and
- lib options directly. You might also need to ensure the shared
- libraries can be found by the dynamic linker when building and
- using GCC, for example by setting the runtime shared library path
- variable (`LD_LIBRARY_PATH' on GNU/Linux and Solaris systems).
-
- These flags are applicable to the host platform only. When
- building a cross compiler, they will not be used to configure
- target libraries.
-
-`--with-ppl=PATHNAME'
-`--with-ppl-include=PATHNAME'
-`--with-ppl-lib=PATHNAME'
-`--with-cloog=PATHNAME'
-`--with-cloog-include=PATHNAME'
-`--with-cloog-lib=PATHNAME'
- If you do not have PPL (the Parma Polyhedra Library) and the CLooG
- libraries installed in a standard location and you want to build
- GCC, you can explicitly specify the directory where they are
- installed (`--with-ppl=PPLINSTALLDIR',
- `--with-cloog=CLOOGINSTALLDIR'). The `--with-ppl=PPLINSTALLDIR'
- option is shorthand for `--with-ppl-lib=PPLINSTALLDIR/lib' and
- `--with-ppl-include=PPLINSTALLDIR/include'. Likewise the
- `--with-cloog=CLOOGINSTALLDIR' option is shorthand for
- `--with-cloog-lib=CLOOGINSTALLDIR/lib' and
- `--with-cloog-include=CLOOGINSTALLDIR/include'. If these
- shorthand assumptions are not correct, you can use the explicit
- include and lib options directly.
-
- These flags are applicable to the host platform only. When
- building a cross compiler, they will not be used to configure
- target libraries.
-
-`--with-host-libstdcxx=LINKER-ARGS'
- If you are linking with a static copy of PPL, you can use this
- option to specify how the linker should find the standard C++
- library used internally by PPL. Typical values of LINKER-ARGS
- might be `-lstdc++' or `-Wl,-Bstatic,-lstdc++,-Bdynamic -lm'. If
- you are linking with a shared copy of PPL, you probably do not
- need this option; shared library dependencies will cause the
- linker to search for the standard C++ library automatically.
-
-`--with-stage1-ldflags=FLAGS'
- This option may be used to set linker flags to be used when linking
- stage 1 of GCC. These are also used when linking GCC if
- configured with `--disable-bootstrap'. By default no special
- flags are used.
-
-`--with-stage1-libs=LIBS'
- This option may be used to set libraries to be used when linking
- stage 1 of GCC. These are also used when linking GCC if
- configured with `--disable-bootstrap'. The default is the
- argument to `--with-host-libstdcxx', if specified.
-
-`--with-boot-ldflags=FLAGS'
- This option may be used to set linker flags to be used when linking
- stage 2 and later when bootstrapping GCC. If neither
- -with-boot-libs nor -with-host-libstdcxx is set to a value, then
- the default is `-static-libstdc++ -static-libgcc'.
-
-`--with-boot-libs=LIBS'
- This option may be used to set libraries to be used when linking
- stage 2 and later when bootstrapping GCC. The default is the
- argument to `--with-host-libstdcxx', if specified.
-
-`--with-debug-prefix-map=MAP'
- Convert source directory names using `-fdebug-prefix-map' when
- building runtime libraries. `MAP' is a space-separated list of
- maps of the form `OLD=NEW'.
-
-`--enable-linker-build-id'
- Tells GCC to pass `--build-id' option to the linker for all final
- links (links performed without the `-r' or `--relocatable'
- option), if the linker supports it. If you specify
- `--enable-linker-build-id', but your linker does not support
- `--build-id' option, a warning is issued and the
- `--enable-linker-build-id' option is ignored. The default is off.
-
-`--enable-gnu-unique-object'
-`--disable-gnu-unique-object'
- Tells GCC to use the gnu_unique_object relocation for C++ template
- static data members and inline function local statics. Enabled by
- default for a native toolchain with an assembler that accepts it
- and GLIBC 2.11 or above, otherwise disabled.
-
-`--enable-lto'
-`--disable-lto'
- Enable support for link-time optimization (LTO). This is enabled
- by default, and may be disabled using `--disable-lto'.
-
-`--with-plugin-ld=PATHNAME'
- Enable an alternate linker to be used at link-time optimization
- (LTO) link time when `-fuse-linker-plugin' is enabled. This
- linker should have plugin support such as gold starting with
- version 2.20 or GNU ld starting with version 2.21. See
- `-fuse-linker-plugin' for details.
-
-`--enable-canonical-prefixes'
-`--disable-canonical-prefixes'
- Enable prefix canonicalization for GCC files that the GCC driver
- locates relative to its own path. Canonicalized prefixes have any
- `/x/../' elements removed and symbolic links expanded. This is
- enabled by default, and may be disabled using
- `--disable-canonical-prefixes'. See `-canonical-prefixes' or
- `-no-canonical-prefixes' for more details, including how to
- override this configuration option when compiling.
-
-`--with-warn-frame-larger-than-extra-text=TEXT'
- Append `TEXT' to frame size warnings generated by the
- `-Wframe-larger-than' warning flag.
-
-Cross-Compiler-Specific Options
--------------------------------
-
-The following options only apply to building cross compilers.
-
-`--with-sysroot'
-`--with-sysroot=DIR'
- Tells GCC to consider DIR as the root of a tree that contains (a
- subset of) the root filesystem of the target operating system.
- Target system headers, libraries and run-time object files will be
- searched in there. More specifically, this acts as if
- `--sysroot=DIR' was added to the default options of the built
- compiler. The specified directory is not copied into the install
- tree, unlike the options `--with-headers' and `--with-libs' that
- this option obsoletes. The default value, in case
- `--with-sysroot' is not given an argument, is
- `${gcc_tooldir}/sys-root'. If the specified directory is a
- subdirectory of `${exec_prefix}', then it will be found relative to
- the GCC binaries if the installation tree is moved.
-
- This option affects the system root for the compiler used to build
- target libraries (which runs on the build system) and the compiler
- newly installed with `make install'; it does not affect the
- compiler which is used to build GCC itself.
-
- If you specify the `--with-native-system-header-dir=DIRNAME'
- option then the compiler will search that directory within DIRNAME
- for native system headers rather than the default `/usr/include'.
-
-`--with-build-sysroot'
-`--with-build-sysroot=DIR'
- Tells GCC to consider DIR as the system root (see
- `--with-sysroot') while building target libraries, instead of the
- directory specified with `--with-sysroot'. This option is only
- useful when you are already using `--with-sysroot'. You can use
- `--with-build-sysroot' when you are configuring with `--prefix'
- set to a directory that is different from the one in which you are
- installing GCC and your target libraries.
-
- This option affects the system root for the compiler used to build
- target libraries (which runs on the build system); it does not
- affect the compiler which is used to build GCC itself.
-
- If you specify the `--with-native-system-header-dir=DIRNAME'
- option then the compiler will search that directory within DIRNAME
- for native system headers rather than the default `/usr/include'.
-
-`--with-headers'
-`--with-headers=DIR'
- Deprecated in favor of `--with-sysroot'. Specifies that target
- headers are available when building a cross compiler. The DIR
- argument specifies a directory which has the target include files.
- These include files will be copied into the `gcc' install
- directory. _This option with the DIR argument is required_ when
- building a cross compiler, if `PREFIX/TARGET/sys-include' doesn't
- pre-exist. If `PREFIX/TARGET/sys-include' does pre-exist, the DIR
- argument may be omitted. `fixincludes' will be run on these files
- to make them compatible with GCC.
-
-`--without-headers'
- Tells GCC not use any target headers from a libc when building a
- cross compiler. When crossing to GNU/Linux, you need the headers
- so GCC can build the exception handling for libgcc.
-
-`--with-libs'
-`--with-libs="DIR1 DIR2 ... DIRN"'
- Deprecated in favor of `--with-sysroot'. Specifies a list of
- directories which contain the target runtime libraries. These
- libraries will be copied into the `gcc' install directory. If the
- directory list is omitted, this option has no effect.
-
-`--with-newlib'
- Specifies that `newlib' is being used as the target C library.
- This causes `__eprintf' to be omitted from `libgcc.a' on the
- assumption that it will be provided by `newlib'.
-
-`--with-build-time-tools=DIR'
- Specifies where to find the set of target tools (assembler,
- linker, etc.) that will be used while building GCC itself. This
- option can be useful if the directory layouts are different
- between the system you are building GCC on, and the system where
- you will deploy it.
-
- For example, on an `ia64-hp-hpux' system, you may have the GNU
- assembler and linker in `/usr/bin', and the native tools in a
- different path, and build a toolchain that expects to find the
- native tools in `/usr/bin'.
-
- When you use this option, you should ensure that DIR includes
- `ar', `as', `ld', `nm', `ranlib' and `strip' if necessary, and
- possibly `objdump'. Otherwise, GCC may use an inconsistent set of
- tools.
-
-Java-Specific Options
----------------------
-
-The following option applies to the build of the Java front end.
-
-`--disable-libgcj'
- Specify that the run-time libraries used by GCJ should not be
- built. This is useful in case you intend to use GCJ with some
- other run-time, or you're going to install it separately, or it
- just happens not to build on your particular machine. In general,
- if the Java front end is enabled, the GCJ libraries will be
- enabled too, unless they're known to not work on the target
- platform. If GCJ is enabled but `libgcj' isn't built, you may
- need to port it; in this case, before modifying the top-level
- `configure.in' so that `libgcj' is enabled by default on this
- platform, you may use `--enable-libgcj' to override the default.
-
-
- The following options apply to building `libgcj'.
-
-General Options
-...............
-
-`--enable-java-maintainer-mode'
- By default the `libjava' build will not attempt to compile the
- `.java' source files to `.class'. Instead, it will use the
- `.class' files from the source tree. If you use this option you
- must have executables named `ecj1' and `gjavah' in your path for
- use by the build. You must use this option if you intend to
- modify any `.java' files in `libjava'.
-
-`--with-java-home=DIRNAME'
- This `libjava' option overrides the default value of the
- `java.home' system property. It is also used to set
- `sun.boot.class.path' to `DIRNAME/lib/rt.jar'. By default
- `java.home' is set to `PREFIX' and `sun.boot.class.path' to
- `DATADIR/java/libgcj-VERSION.jar'.
-
-`--with-ecj-jar=FILENAME'
- This option can be used to specify the location of an external jar
- file containing the Eclipse Java compiler. A specially modified
- version of this compiler is used by `gcj' to parse `.java' source
- files. If this option is given, the `libjava' build will create
- and install an `ecj1' executable which uses this jar file at
- runtime.
-
- If this option is not given, but an `ecj.jar' file is found in the
- topmost source tree at configure time, then the `libgcj' build
- will create and install `ecj1', and will also install the
- discovered `ecj.jar' into a suitable place in the install tree.
-
- If `ecj1' is not installed, then the user will have to supply one
- on his path in order for `gcj' to properly parse `.java' source
- files. A suitable jar is available from
- `ftp://sourceware.org/pub/java/'.
-
-`--disable-getenv-properties'
- Don't set system properties from `GCJ_PROPERTIES'.
-
-`--enable-hash-synchronization'
- Use a global hash table for monitor locks. Ordinarily, `libgcj''s
- `configure' script automatically makes the correct choice for this
- option for your platform. Only use this if you know you need the
- library to be configured differently.
-
-`--enable-interpreter'
- Enable the Java interpreter. The interpreter is automatically
- enabled by default on all platforms that support it. This option
- is really only useful if you want to disable the interpreter
- (using `--disable-interpreter').
-
-`--disable-java-net'
- Disable java.net. This disables the native part of java.net only,
- using non-functional stubs for native method implementations.
-
-`--disable-jvmpi'
- Disable JVMPI support.
-
-`--disable-libgcj-bc'
- Disable BC ABI compilation of certain parts of libgcj. By default,
- some portions of libgcj are compiled with `-findirect-dispatch'
- and `-fno-indirect-classes', allowing them to be overridden at
- run-time.
-
- If `--disable-libgcj-bc' is specified, libgcj is built without
- these options. This allows the compile-time linker to resolve
- dependencies when statically linking to libgcj. However it makes
- it impossible to override the affected portions of libgcj at
- run-time.
-
-`--enable-reduced-reflection'
- Build most of libgcj with `-freduced-reflection'. This reduces
- the size of libgcj at the expense of not being able to do accurate
- reflection on the classes it contains. This option is safe if you
- know that code using libgcj will never use reflection on the
- standard runtime classes in libgcj (including using serialization,
- RMI or CORBA).
-
-`--with-ecos'
- Enable runtime eCos target support.
-
-`--without-libffi'
- Don't use `libffi'. This will disable the interpreter and JNI
- support as well, as these require `libffi' to work.
-
-`--enable-libgcj-debug'
- Enable runtime debugging code.
-
-`--enable-libgcj-multifile'
- If specified, causes all `.java' source files to be compiled into
- `.class' files in one invocation of `gcj'. This can speed up
- build time, but is more resource-intensive. If this option is
- unspecified or disabled, `gcj' is invoked once for each `.java'
- file to compile into a `.class' file.
-
-`--with-libiconv-prefix=DIR'
- Search for libiconv in `DIR/include' and `DIR/lib'.
-
-`--enable-sjlj-exceptions'
- Force use of the `setjmp'/`longjmp'-based scheme for exceptions.
- `configure' ordinarily picks the correct value based on the
- platform. Only use this option if you are sure you need a
- different setting.
-
-`--with-system-zlib'
- Use installed `zlib' rather than that included with GCC.
-
-`--with-win32-nlsapi=ansi, unicows or unicode'
- Indicates how MinGW `libgcj' translates between UNICODE characters
- and the Win32 API.
-
-`--enable-java-home'
- If enabled, this creates a JPackage compatible SDK environment
- during install. Note that if -enable-java-home is used,
- -with-arch-directory=ARCH must also be specified.
-
-`--with-arch-directory=ARCH'
- Specifies the name to use for the `jre/lib/ARCH' directory in the
- SDK environment created when -enable-java-home is passed. Typical
- names for this directory include i386, amd64, ia64, etc.
-
-`--with-os-directory=DIR'
- Specifies the OS directory for the SDK include directory. This is
- set to auto detect, and is typically 'linux'.
-
-`--with-origin-name=NAME'
- Specifies the JPackage origin name. This defaults to the 'gcj' in
- java-1.5.0-gcj.
-
-`--with-arch-suffix=SUFFIX'
- Specifies the suffix for the sdk directory. Defaults to the empty
- string. Examples include '.x86_64' in
- 'java-1.5.0-gcj-1.5.0.0.x86_64'.
-
-`--with-jvm-root-dir=DIR'
- Specifies where to install the SDK. Default is $(prefix)/lib/jvm.
-
-`--with-jvm-jar-dir=DIR'
- Specifies where to install jars. Default is
- $(prefix)/lib/jvm-exports.
-
-`--with-python-dir=DIR'
- Specifies where to install the Python modules used for
- aot-compile. DIR should not include the prefix used in
- installation. For example, if the Python modules are to be
- installed in /usr/lib/python2.5/site-packages, then
- -with-python-dir=/lib/python2.5/site-packages should be passed. If
- this is not specified, then the Python modules are installed in
- $(prefix)/share/python.
-
-`--enable-aot-compile-rpm'
- Adds aot-compile-rpm to the list of installed scripts.
-
-`--enable-browser-plugin'
- Build the gcjwebplugin web browser plugin.
-
- `ansi'
- Use the single-byte `char' and the Win32 A functions natively,
- translating to and from UNICODE when using these functions.
- If unspecified, this is the default.
-
- `unicows'
- Use the `WCHAR' and Win32 W functions natively. Adds
- `-lunicows' to `libgcj.spec' to link with `libunicows'.
- `unicows.dll' needs to be deployed on Microsoft Windows 9X
- machines running built executables. `libunicows.a', an
- open-source import library around Microsoft's `unicows.dll',
- is obtained from `http://libunicows.sourceforge.net/', which
- also gives details on getting `unicows.dll' from Microsoft.
-
- `unicode'
- Use the `WCHAR' and Win32 W functions natively. Does _not_
- add `-lunicows' to `libgcj.spec'. The built executables will
- only run on Microsoft Windows NT and above.
-
-AWT-Specific Options
-....................
-
-`--with-x'
- Use the X Window System.
-
-`--enable-java-awt=PEER(S)'
- Specifies the AWT peer library or libraries to build alongside
- `libgcj'. If this option is unspecified or disabled, AWT will be
- non-functional. Current valid values are `gtk' and `xlib'.
- Multiple libraries should be separated by a comma (i.e.
- `--enable-java-awt=gtk,xlib').
-
-`--enable-gtk-cairo'
- Build the cairo Graphics2D implementation on GTK.
-
-`--enable-java-gc=TYPE'
- Choose garbage collector. Defaults to `boehm' if unspecified.
-
-`--disable-gtktest'
- Do not try to compile and run a test GTK+ program.
-
-`--disable-glibtest'
- Do not try to compile and run a test GLIB program.
-
-`--with-libart-prefix=PFX'
- Prefix where libart is installed (optional).
-
-`--with-libart-exec-prefix=PFX'
- Exec prefix where libart is installed (optional).
-
-`--disable-libarttest'
- Do not try to compile and run a test libart program.
-
-
-Overriding `configure' test results
-...................................
-
-Sometimes, it might be necessary to override the result of some
-`configure' test, for example in order to ease porting to a new system
-or work around a bug in a test. The toplevel `configure' script
-provides three variables for this:
-
-`build_configargs'
- The contents of this variable is passed to all build `configure'
- scripts.
-
-`host_configargs'
- The contents of this variable is passed to all host `configure'
- scripts.
-
-`target_configargs'
- The contents of this variable is passed to all target `configure'
- scripts.
-
-
- In order to avoid shell and `make' quoting issues for complex
-overrides, you can pass a setting for `CONFIG_SITE' and set variables
-in the site file.
-
-
-File: gccinstall.info, Node: Building, Next: Testing, Prev: Configuration, Up: Installing GCC
-
-5 Building
-**********
-
- Now that GCC is configured, you are ready to build the compiler and
-runtime libraries.
-
- Some commands executed when making the compiler may fail (return a
-nonzero status) and be ignored by `make'. These failures, which are
-often due to files that were not found, are expected, and can safely be
-ignored.
-
- It is normal to have compiler warnings when compiling certain files.
-Unless you are a GCC developer, you can generally ignore these warnings
-unless they cause compilation to fail. Developers should attempt to fix
-any warnings encountered, however they can temporarily continue past
-warnings-as-errors by specifying the configure flag `--disable-werror'.
-
- On certain old systems, defining certain environment variables such
-as `CC' can interfere with the functioning of `make'.
-
- If you encounter seemingly strange errors when trying to build the
-compiler in a directory other than the source directory, it could be
-because you have previously configured the compiler in the source
-directory. Make sure you have done all the necessary preparations.
-
- If you build GCC on a BSD system using a directory stored in an old
-System V file system, problems may occur in running `fixincludes' if the
-System V file system doesn't support symbolic links. These problems
-result in a failure to fix the declaration of `size_t' in
-`sys/types.h'. If you find that `size_t' is a signed type and that
-type mismatches occur, this could be the cause.
-
- The solution is not to use such a directory for building GCC.
-
- Similarly, when building from SVN or snapshots, or if you modify
-`*.l' files, you need the Flex lexical analyzer generator installed.
-If you do not modify `*.l' files, releases contain the Flex-generated
-files and you do not need Flex installed to build them. There is still
-one Flex-based lexical analyzer (part of the build machinery, not of
-GCC itself) that is used even if you only build the C front end.
-
- When building from SVN or snapshots, or if you modify Texinfo
-documentation, you need version 4.7 or later of Texinfo installed if you
-want Info documentation to be regenerated. Releases contain Info
-documentation pre-built for the unmodified documentation in the release.
-
-5.1 Building a native compiler
-==============================
-
-For a native build, the default configuration is to perform a 3-stage
-bootstrap of the compiler when `make' is invoked. This will build the
-entire GCC system and ensure that it compiles itself correctly. It can
-be disabled with the `--disable-bootstrap' parameter to `configure',
-but bootstrapping is suggested because the compiler will be tested more
-completely and could also have better performance.
-
- The bootstrapping process will complete the following steps:
-
- * Build tools necessary to build the compiler.
-
- * Perform a 3-stage bootstrap of the compiler. This includes
- building three times the target tools for use by the compiler such
- as binutils (bfd, binutils, gas, gprof, ld, and opcodes) if they
- have been individually linked or moved into the top level GCC
- source tree before configuring.
-
- * Perform a comparison test of the stage2 and stage3 compilers.
-
- * Build runtime libraries using the stage3 compiler from the
- previous step.
-
-
- If you are short on disk space you might consider `make
-bootstrap-lean' instead. The sequence of compilation is the same
-described above, but object files from the stage1 and stage2 of the
-3-stage bootstrap of the compiler are deleted as soon as they are no
-longer needed.
-
- If you wish to use non-default GCC flags when compiling the stage2
-and stage3 compilers, set `BOOT_CFLAGS' on the command line when doing
-`make'. For example, if you want to save additional space during the
-bootstrap and in the final installation as well, you can build the
-compiler binaries without debugging information as in the following
-example. This will save roughly 40% of disk space both for the
-bootstrap and the final installation. (Libraries will still contain
-debugging information.)
-
- make BOOT_CFLAGS='-O' bootstrap
-
- You can place non-default optimization flags into `BOOT_CFLAGS'; they
-are less well tested here than the default of `-g -O2', but should
-still work. In a few cases, you may find that you need to specify
-special flags such as `-msoft-float' here to complete the bootstrap; or,
-if the native compiler miscompiles the stage1 compiler, you may need to
-work around this, by choosing `BOOT_CFLAGS' to avoid the parts of the
-stage1 compiler that were miscompiled, or by using `make bootstrap4' to
-increase the number of stages of bootstrap.
-
- `BOOT_CFLAGS' does not apply to bootstrapped target libraries.
-Since these are always compiled with the compiler currently being
-bootstrapped, you can use `CFLAGS_FOR_TARGET' to modify their
-compilation flags, as for non-bootstrapped target libraries. Again, if
-the native compiler miscompiles the stage1 compiler, you may need to
-work around this by avoiding non-working parts of the stage1 compiler.
-Use `STAGE1_TFLAGS' to this end.
-
- If you used the flag `--enable-languages=...' to restrict the
-compilers to be built, only those you've actually enabled will be
-built. This will of course only build those runtime libraries, for
-which the particular compiler has been built. Please note, that
-re-defining `LANGUAGES' when calling `make' *does not* work anymore!
-
- If the comparison of stage2 and stage3 fails, this normally indicates
-that the stage2 compiler has compiled GCC incorrectly, and is therefore
-a potentially serious bug which you should investigate and report. (On
-a few systems, meaningful comparison of object files is impossible; they
-always appear "different". If you encounter this problem, you will
-need to disable comparison in the `Makefile'.)
-
- If you do not want to bootstrap your compiler, you can configure with
-`--disable-bootstrap'. In particular cases, you may want to bootstrap
-your compiler even if the target system is not the same as the one you
-are building on: for example, you could build a
-`powerpc-unknown-linux-gnu' toolchain on a
-`powerpc64-unknown-linux-gnu' host. In this case, pass
-`--enable-bootstrap' to the configure script.
-
- `BUILD_CONFIG' can be used to bring in additional customization to
-the build. It can be set to a whitespace-separated list of names. For
-each such `NAME', top-level `config/`NAME'.mk' will be included by the
-top-level `Makefile', bringing in any settings it contains. The
-default `BUILD_CONFIG' can be set using the configure option
-`--with-build-config=`NAME'...'. Some examples of supported build
-configurations are:
-
-`bootstrap-O1'
- Removes any `-O'-started option from `BOOT_CFLAGS', and adds `-O1'
- to it. `BUILD_CONFIG=bootstrap-O1' is equivalent to
- `BOOT_CFLAGS='-g -O1''.
-
-`bootstrap-O3'
- Analogous to `bootstrap-O1'.
-
-`bootstrap-lto'
- Enables Link-Time Optimization for host tools during bootstrapping.
- `BUILD_CONFIG=bootstrap-lto' is equivalent to adding `-flto' to
- `BOOT_CFLAGS'.
-
-`bootstrap-debug'
- Verifies that the compiler generates the same executable code,
- whether or not it is asked to emit debug information. To this
- end, this option builds stage2 host programs without debug
- information, and uses `contrib/compare-debug' to compare them with
- the stripped stage3 object files. If `BOOT_CFLAGS' is overridden
- so as to not enable debug information, stage2 will have it, and
- stage3 won't. This option is enabled by default when GCC
- bootstrapping is enabled, if `strip' can turn object files
- compiled with and without debug info into identical object files.
- In addition to better test coverage, this option makes default
- bootstraps faster and leaner.
-
-`bootstrap-debug-big'
- Rather than comparing stripped object files, as in
- `bootstrap-debug', this option saves internal compiler dumps
- during stage2 and stage3 and compares them as well, which helps
- catch additional potential problems, but at a great cost in terms
- of disk space. It can be specified in addition to
- `bootstrap-debug'.
-
-`bootstrap-debug-lean'
- This option saves disk space compared with `bootstrap-debug-big',
- but at the expense of some recompilation. Instead of saving the
- dumps of stage2 and stage3 until the final compare, it uses
- `-fcompare-debug' to generate, compare and remove the dumps during
- stage3, repeating the compilation that already took place in
- stage2, whose dumps were not saved.
-
-`bootstrap-debug-lib'
- This option tests executable code invariance over debug information
- generation on target libraries, just like `bootstrap-debug-lean'
- tests it on host programs. It builds stage3 libraries with
- `-fcompare-debug', and it can be used along with any of the
- `bootstrap-debug' options above.
-
- There aren't `-lean' or `-big' counterparts to this option because
- most libraries are only build in stage3, so bootstrap compares
- would not get significant coverage. Moreover, the few libraries
- built in stage2 are used in stage3 host programs, so we wouldn't
- want to compile stage2 libraries with different options for
- comparison purposes.
-
-`bootstrap-debug-ckovw'
- Arranges for error messages to be issued if the compiler built on
- any stage is run without the option `-fcompare-debug'. This is
- useful to verify the full `-fcompare-debug' testing coverage. It
- must be used along with `bootstrap-debug-lean' and
- `bootstrap-debug-lib'.
-
-`bootstrap-time'
- Arranges for the run time of each program started by the GCC
- driver, built in any stage, to be logged to `time.log', in the top
- level of the build tree.
-
-
-5.2 Building a cross compiler
-=============================
-
-When building a cross compiler, it is not generally possible to do a
-3-stage bootstrap of the compiler. This makes for an interesting
-problem as parts of GCC can only be built with GCC.
-
- To build a cross compiler, we recommend first building and
-installing a native compiler. You can then use the native GCC compiler
-to build the cross compiler. The installed native compiler needs to be
-GCC version 2.95 or later.
-
- If the cross compiler is to be built with support for the Java
-programming language and the ability to compile .java source files is
-desired, the installed native compiler used to build the cross compiler
-needs to be the same GCC version as the cross compiler. In addition
-the cross compiler needs to be configured with `--with-ecj-jar=...'.
-
- Assuming you have already installed a native copy of GCC and
-configured your cross compiler, issue the command `make', which
-performs the following steps:
-
- * Build host tools necessary to build the compiler.
-
- * Build target tools for use by the compiler such as binutils (bfd,
- binutils, gas, gprof, ld, and opcodes) if they have been
- individually linked or moved into the top level GCC source tree
- before configuring.
-
- * Build the compiler (single stage only).
-
- * Build runtime libraries using the compiler from the previous step.
-
- Note that if an error occurs in any step the make process will exit.
-
- If you are not building GNU binutils in the same source tree as GCC,
-you will need a cross-assembler and cross-linker installed before
-configuring GCC. Put them in the directory `PREFIX/TARGET/bin'. Here
-is a table of the tools you should put in this directory:
-
-`as'
- This should be the cross-assembler.
-
-`ld'
- This should be the cross-linker.
-
-`ar'
- This should be the cross-archiver: a program which can manipulate
- archive files (linker libraries) in the target machine's format.
-
-`ranlib'
- This should be a program to construct a symbol table in an archive
- file.
-
- The installation of GCC will find these programs in that directory,
-and copy or link them to the proper place to for the cross-compiler to
-find them when run later.
-
- The easiest way to provide these files is to build the Binutils
-package. Configure it with the same `--host' and `--target' options
-that you use for configuring GCC, then build and install them. They
-install their executables automatically into the proper directory.
-Alas, they do not support all the targets that GCC supports.
-
- If you are not building a C library in the same source tree as GCC,
-you should also provide the target libraries and headers before
-configuring GCC, specifying the directories with `--with-sysroot' or
-`--with-headers' and `--with-libs'. Many targets also require "start
-files" such as `crt0.o' and `crtn.o' which are linked into each
-executable. There may be several alternatives for `crt0.o', for use
-with profiling or other compilation options. Check your target's
-definition of `STARTFILE_SPEC' to find out what start files it uses.
-
-5.3 Building in parallel
-========================
-
-GNU Make 3.80 and above, which is necessary to build GCC, support
-building in parallel. To activate this, you can use `make -j 2'
-instead of `make'. You can also specify a bigger number, and in most
-cases using a value greater than the number of processors in your
-machine will result in fewer and shorter I/O latency hits, thus
-improving overall throughput; this is especially true for slow drives
-and network filesystems.
-
-5.4 Building the Ada compiler
-=============================
-
-In order to build GNAT, the Ada compiler, you need a working GNAT
-compiler (GCC version 4.0 or later). This includes GNAT tools such as
-`gnatmake' and `gnatlink', since the Ada front end is written in Ada and
-uses some GNAT-specific extensions.
-
- In order to build a cross compiler, it is suggested to install the
-new compiler as native first, and then use it to build the cross
-compiler.
-
- `configure' does not test whether the GNAT installation works and
-has a sufficiently recent version; if too old a GNAT version is
-installed, the build will fail unless `--enable-languages' is used to
-disable building the Ada front end.
-
- `ADA_INCLUDE_PATH' and `ADA_OBJECT_PATH' environment variables must
-not be set when building the Ada compiler, the Ada tools, or the Ada
-runtime libraries. You can check that your build environment is clean
-by verifying that `gnatls -v' lists only one explicit path in each
-section.
-
-5.5 Building with profile feedback
-==================================
-
-It is possible to use profile feedback to optimize the compiler itself.
-This should result in a faster compiler binary. Experiments done on
-x86 using gcc 3.3 showed approximately 7 percent speedup on compiling C
-programs. To bootstrap the compiler with profile feedback, use `make
-profiledbootstrap'.
-
- When `make profiledbootstrap' is run, it will first build a `stage1'
-compiler. This compiler is used to build a `stageprofile' compiler
-instrumented to collect execution counts of instruction and branch
-probabilities. Then runtime libraries are compiled with profile
-collected. Finally a `stagefeedback' compiler is built using the
-information collected.
-
- Unlike standard bootstrap, several additional restrictions apply.
-The compiler used to build `stage1' needs to support a 64-bit integral
-type. It is recommended to only use GCC for this. Also parallel make
-is currently not supported since collisions in profile collecting may
-occur.
-
-
-File: gccinstall.info, Node: Testing, Next: Final install, Prev: Building, Up: Installing GCC
-
-6 Installing GCC: Testing
-*************************
-
- Before you install GCC, we encourage you to run the testsuites and to
-compare your results with results from a similar configuration that have
-been submitted to the gcc-testresults mailing list. Some of these
-archived results are linked from the build status lists at
-`http://gcc.gnu.org/buildstat.html', although not everyone who reports
-a successful build runs the testsuites and submits the results. This
-step is optional and may require you to download additional software,
-but it can give you confidence in your new GCC installation or point out
-problems before you install and start using your new GCC.
-
- First, you must have downloaded the testsuites. These are part of
-the full distribution, but if you downloaded the "core" compiler plus
-any front ends, you must download the testsuites separately.
-
- Second, you must have the testing tools installed. This includes
-DejaGnu, Tcl, and Expect; the DejaGnu site has links to these.
-
- If the directories where `runtest' and `expect' were installed are
-not in the `PATH', you may need to set the following environment
-variables appropriately, as in the following example (which assumes
-that DejaGnu has been installed under `/usr/local'):
-
- TCL_LIBRARY = /usr/local/share/tcl8.0
- DEJAGNULIBS = /usr/local/share/dejagnu
-
- (On systems such as Cygwin, these paths are required to be actual
-paths, not mounts or links; presumably this is due to some lack of
-portability in the DejaGnu code.)
-
- Finally, you can run the testsuite (which may take a long time):
- cd OBJDIR; make -k check
-
- This will test various components of GCC, such as compiler front
-ends and runtime libraries. While running the testsuite, DejaGnu might
-emit some harmless messages resembling `WARNING: Couldn't find the
-global config file.' or `WARNING: Couldn't find tool init file' that
-can be ignored.
-
- If you are testing a cross-compiler, you may want to run the
-testsuite on a simulator as described at
-`http://gcc.gnu.org/simtest-howto.html'.
-
-6.1 How can you run the testsuite on selected tests?
-====================================================
-
-In order to run sets of tests selectively, there are targets `make
-check-gcc' and `make check-g++' in the `gcc' subdirectory of the object
-directory. You can also just run `make check' in a subdirectory of the
-object directory.
-
- A more selective way to just run all `gcc' execute tests in the
-testsuite is to use
-
- make check-gcc RUNTESTFLAGS="execute.exp OTHER-OPTIONS"
-
- Likewise, in order to run only the `g++' "old-deja" tests in the
-testsuite with filenames matching `9805*', you would use
-
- make check-g++ RUNTESTFLAGS="old-deja.exp=9805* OTHER-OPTIONS"
-
- The `*.exp' files are located in the testsuite directories of the GCC
-source, the most important ones being `compile.exp', `execute.exp',
-`dg.exp' and `old-deja.exp'. To get a list of the possible `*.exp'
-files, pipe the output of `make check' into a file and look at the
-`Running ... .exp' lines.
-
-6.2 Passing options and running multiple testsuites
-===================================================
-
-You can pass multiple options to the testsuite using the
-`--target_board' option of DejaGNU, either passed as part of
-`RUNTESTFLAGS', or directly to `runtest' if you prefer to work outside
-the makefiles. For example,
-
- make check-g++ RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
-
- will run the standard `g++' testsuites ("unix" is the target name
-for a standard native testsuite situation), passing `-O3
--fmerge-constants' to the compiler on every test, i.e., slashes
-separate options.
-
- You can run the testsuites multiple times using combinations of
-options with a syntax similar to the brace expansion of popular shells:
-
- ..."--target_board=arm-sim\{-mhard-float,-msoft-float\}\{-O1,-O2,-O3,\}"
-
- (Note the empty option caused by the trailing comma in the final
-group.) The following will run each testsuite eight times using the
-`arm-sim' target, as if you had specified all possible combinations
-yourself:
-
- --target_board=arm-sim/-mhard-float/-O1
- --target_board=arm-sim/-mhard-float/-O2
- --target_board=arm-sim/-mhard-float/-O3
- --target_board=arm-sim/-mhard-float
- --target_board=arm-sim/-msoft-float/-O1
- --target_board=arm-sim/-msoft-float/-O2
- --target_board=arm-sim/-msoft-float/-O3
- --target_board=arm-sim/-msoft-float
-
- They can be combined as many times as you wish, in arbitrary ways.
-This list:
-
- ..."--target_board=unix/-Wextra\{-O3,-fno-strength\}\{-fomit-frame,\}"
-
- will generate four combinations, all involving `-Wextra'.
-
- The disadvantage to this method is that the testsuites are run in
-serial, which is a waste on multiprocessor systems. For users with GNU
-Make and a shell which performs brace expansion, you can run the
-testsuites in parallel by having the shell perform the combinations and
-`make' do the parallel runs. Instead of using `--target_board', use a
-special makefile target:
-
- make -jN check-TESTSUITE//TEST-TARGET/OPTION1/OPTION2/...
-
- For example,
-
- make -j3 check-gcc//sh-hms-sim/{-m1,-m2,-m3,-m3e,-m4}/{,-nofpu}
-
- will run three concurrent "make-gcc" testsuites, eventually testing
-all ten combinations as described above. Note that this is currently
-only supported in the `gcc' subdirectory. (To see how this works, try
-typing `echo' before the example given here.)
-
-6.3 Additional testing for Java Class Libraries
-===============================================
-
-The Java runtime tests can be executed via `make check' in the
-`TARGET/libjava/testsuite' directory in the build tree.
-
- The Mauve Project provides a suite of tests for the Java Class
-Libraries. This suite can be run as part of libgcj testing by placing
-the Mauve tree within the libjava testsuite at
-`libjava/testsuite/libjava.mauve/mauve', or by specifying the location
-of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'.
-
-6.4 How to interpret test results
-=================================
-
-The result of running the testsuite are various `*.sum' and `*.log'
-files in the testsuite subdirectories. The `*.log' files contain a
-detailed log of the compiler invocations and the corresponding results,
-the `*.sum' files summarize the results. These summaries contain
-status codes for all tests:
-
- * PASS: the test passed as expected
-
- * XPASS: the test unexpectedly passed
-
- * FAIL: the test unexpectedly failed
-
- * XFAIL: the test failed as expected
-
- * UNSUPPORTED: the test is not supported on this platform
-
- * ERROR: the testsuite detected an error
-
- * WARNING: the testsuite detected a possible problem
-
- It is normal for some tests to report unexpected failures. At the
-current time the testing harness does not allow fine grained control
-over whether or not a test is expected to fail. This problem should be
-fixed in future releases.
-
-6.5 Submitting test results
-===========================
-
-If you want to report the results to the GCC project, use the
-`contrib/test_summary' shell script. Start it in the OBJDIR with
-
- SRCDIR/contrib/test_summary -p your_commentary.txt \
- -m gcc-testresults@gcc.gnu.org |sh
-
- This script uses the `Mail' program to send the results, so make
-sure it is in your `PATH'. The file `your_commentary.txt' is prepended
-to the testsuite summary and should contain any special remarks you
-have on your results or your build environment. Please do not edit the
-testsuite result block or the subject line, as these messages may be
-automatically processed.
-
-
-File: gccinstall.info, Node: Final install, Prev: Testing, Up: Installing GCC
-
-7 Installing GCC: Final installation
-************************************
-
- Now that GCC has been built (and optionally tested), you can install
-it with
- cd OBJDIR && make install
-
- We strongly recommend to install into a target directory where there
-is no previous version of GCC present. Also, the GNAT runtime should
-not be stripped, as this would break certain features of the debugger
-that depend on this debugging information (catching Ada exceptions for
-instance).
-
- That step completes the installation of GCC; user level binaries can
-be found in `PREFIX/bin' where PREFIX is the value you specified with
-the `--prefix' to configure (or `/usr/local' by default). (If you
-specified `--bindir', that directory will be used instead; otherwise,
-if you specified `--exec-prefix', `EXEC-PREFIX/bin' will be used.)
-Headers for the C++ and Java libraries are installed in
-`PREFIX/include'; libraries in `LIBDIR' (normally `PREFIX/lib');
-internal parts of the compiler in `LIBDIR/gcc' and `LIBEXECDIR/gcc';
-documentation in info format in `INFODIR' (normally `PREFIX/info').
-
- When installing cross-compilers, GCC's executables are not only
-installed into `BINDIR', that is, `EXEC-PREFIX/bin', but additionally
-into `EXEC-PREFIX/TARGET-ALIAS/bin', if that directory exists.
-Typically, such "tooldirs" hold target-specific binutils, including
-assembler and linker.
-
- Installation into a temporary staging area or into a `chroot' jail
-can be achieved with the command
-
- make DESTDIR=PATH-TO-ROOTDIR install
-
-where PATH-TO-ROOTDIR is the absolute path of a directory relative to
-which all installation paths will be interpreted. Note that the
-directory specified by `DESTDIR' need not exist yet; it will be created
-if necessary.
-
- There is a subtle point with tooldirs and `DESTDIR': If you relocate
-a cross-compiler installation with e.g. `DESTDIR=ROOTDIR', then the
-directory `ROOTDIR/EXEC-PREFIX/TARGET-ALIAS/bin' will be filled with
-duplicated GCC executables only if it already exists, it will not be
-created otherwise. This is regarded as a feature, not as a bug,
-because it gives slightly more control to the packagers using the
-`DESTDIR' feature.
-
- You can install stripped programs and libraries with
-
- make install-strip
-
- If you are bootstrapping a released version of GCC then please
-quickly review the build status page for your release, available from
-`http://gcc.gnu.org/buildstat.html'. If your system is not listed for
-the version of GCC that you built, send a note to <gcc@gcc.gnu.org>
-indicating that you successfully built and installed GCC. Include the
-following information:
-
- * Output from running `SRCDIR/config.guess'. Do not send that file
- itself, just the one-line output from running it.
-
- * The output of `gcc -v' for your newly installed `gcc'. This tells
- us which version of GCC you built and the options you passed to
- configure.
-
- * Whether you enabled all languages or a subset of them. If you
- used a full distribution then this information is part of the
- configure options in the output of `gcc -v', but if you downloaded
- the "core" compiler plus additional front ends then it isn't
- apparent which ones you built unless you tell us about it.
-
- * If the build was for GNU/Linux, also include:
- * The distribution name and version (e.g., Red Hat 7.1 or
- Debian 2.2.3); this information should be available from
- `/etc/issue'.
-
- * The version of the Linux kernel, available from `uname
- --version' or `uname -a'.
-
- * The version of glibc you used; for RPM-based systems like Red
- Hat, Mandrake, and SuSE type `rpm -q glibc' to get the glibc
- version, and on systems like Debian and Progeny use `dpkg -l
- libc6'.
- For other systems, you can include similar information if you
- think it is relevant.
-
- * Any other information that you think would be useful to people
- building GCC on the same configuration. The new entry in the
- build status list will include a link to the archived copy of your
- message.
-
- We'd also like to know if the *note host/target specific
-installation notes: Specific. didn't include your host/target
-information or if that information is incomplete or out of date. Send
-a note to <gcc@gcc.gnu.org> detailing how the information should be
-changed.
-
- If you find a bug, please report it following the bug reporting
-guidelines.
-
- If you want to print the GCC manuals, do `cd OBJDIR; make dvi'. You
-will need to have `texi2dvi' (version at least 4.7) and TeX installed.
-This creates a number of `.dvi' files in subdirectories of `OBJDIR';
-these may be converted for printing with programs such as `dvips'.
-Alternately, by using `make pdf' in place of `make dvi', you can create
-documentation in the form of `.pdf' files; this requires `texi2pdf',
-which is included with Texinfo version 4.8 and later. You can also buy
-printed manuals from the Free Software Foundation, though such manuals
-may not be for the most recent version of GCC.
-
- If you would like to generate online HTML documentation, do `cd
-OBJDIR; make html' and HTML will be generated for the gcc manuals in
-`OBJDIR/gcc/HTML'.
-
-
-File: gccinstall.info, Node: Binaries, Next: Specific, Prev: Installing GCC, Up: Top
-
-8 Installing GCC: Binaries
-**************************
-
- We are often asked about pre-compiled versions of GCC. While we
-cannot provide these for all platforms, below you'll find links to
-binaries for various platforms where creating them by yourself is not
-easy due to various reasons.
-
- Please note that we did not create these binaries, nor do we support
-them. If you have any problems installing them, please contact their
-makers.
-
- * AIX:
- * Bull's Freeware and Shareware Archive for AIX;
-
- * Hudson Valley Community College Open Source Software for IBM
- System p;
-
- * AIX 5L and 6 Open Source Packages.
-
- * DOS--DJGPP.
-
- * Renesas H8/300[HS]--GNU Development Tools for the Renesas
- H8/300[HS] Series.
-
- * HP-UX:
- * HP-UX Porting Center;
-
- * Binaries for HP-UX 11.00 at Aachen University of Technology.
-
- * SCO OpenServer/Unixware.
-
- * Solaris 2 (SPARC, Intel):
- * Sunfreeware
-
- * Blastwave
-
- * OpenCSW
-
- * TGCware
-
- * SGI IRIX:
- * Nekoware
-
- * TGCware
-
- * Microsoft Windows:
- * The Cygwin project;
-
- * The MinGW project.
-
- * The Written Word offers binaries for AIX 4.3.3, 5.1 and 5.2, IRIX
- 6.5, Tru64 UNIX 4.0D and 5.1, GNU/Linux (i386), HP-UX 10.20,
- 11.00, and 11.11, and Solaris/SPARC 2.5.1, 2.6, 7, 8, 9 and 10.
-
- * OpenPKG offers binaries for quite a number of platforms.
-
- * The GFortran Wiki has links to GNU Fortran binaries for several
- platforms.
-
-
-File: gccinstall.info, Node: Specific, Next: Old, Prev: Binaries, Up: Top
-
-9 Host/target specific installation notes for GCC
-*************************************************
-
- Please read this document carefully _before_ installing the GNU
-Compiler Collection on your machine.
-
- Note that this list of install notes is _not_ a list of supported
-hosts or targets. Not all supported hosts and targets are listed here,
-only the ones that require host-specific or target-specific information
-are.
-
-alpha*-*-*
-==========
-
-This section contains general configuration information for all
-alpha-based platforms using ELF (in particular, ignore this section for
-DEC OSF/1, Digital UNIX and Tru64 UNIX). In addition to reading this
-section, please read all other sections that match your target.
-
- We require binutils 2.11.2 or newer. Previous binutils releases had
-a number of problems with DWARF 2 debugging information, not the least
-of which is incorrect linking of shared libraries.
-
-alpha*-dec-osf5.1
-=================
-
-Systems using processors that implement the DEC Alpha architecture and
-are running the DEC/Compaq/HP Unix (DEC OSF/1, Digital UNIX, or
-Compaq/HP Tru64 UNIX) operating system, for example the DEC Alpha AXP
-systems.
-
- As of GCC 3.2, versions before `alpha*-dec-osf4' are no longer
-supported. (These are the versions which identify themselves as DEC
-OSF/1.) As of GCC 4.6, support for Tru64 UNIX V4.0 and V5.0 has been
-removed.
-
- On Tru64 UNIX, virtual memory exhausted bootstrap failures may be
-fixed by reconfiguring Kernel Virtual Memory and Swap parameters per
-the `/usr/sbin/sys_check' Tuning Suggestions, or applying the patch in
-`http://gcc.gnu.org/ml/gcc/2002-08/msg00822.html'. Depending on the OS
-version used, you need a data segment size between 512 MB and 1 GB, so
-simply use `ulimit -Sd unlimited'.
-
- As of GNU binutils 2.21, neither GNU `as' nor GNU `ld' are supported
-on Tru64 UNIX, so you must not configure GCC with `--with-gnu-as' or
-`--with-gnu-ld'.
-
- GCC writes a `.verstamp' directive to the assembler output file
-unless it is built as a cross-compiler. It gets the version to use from
-the system header file `/usr/include/stamp.h'. If you install a new
-version of Tru64 UNIX, you should rebuild GCC to pick up the new version
-stamp.
-
- GCC now supports both the native (ECOFF) debugging format used by DBX
-and GDB and an encapsulated STABS format for use only with GDB. See the
-discussion of the `--with-stabs' option of `configure' above for more
-information on these formats and how to select them.
-
- There is a bug in DEC's assembler that produces incorrect line
-numbers for ECOFF format when the `.align' directive is used. To work
-around this problem, GCC will not emit such alignment directives while
-writing ECOFF format debugging information even if optimization is
-being performed. Unfortunately, this has the very undesirable
-side-effect that code addresses when `-O' is specified are different
-depending on whether or not `-g' is also specified.
-
- To avoid this behavior, specify `-gstabs+' and use GDB instead of
-DBX. DEC is now aware of this problem with the assembler and hopes to
-provide a fix shortly.
-
-arc-*-elf
-=========
-
-Argonaut ARC processor. This configuration is intended for embedded
-systems.
-
-arm-*-elf
-=========
-
-ARM-family processors. Subtargets that use the ELF object format
-require GNU binutils 2.13 or newer. Such subtargets include:
-`arm-*-freebsd', `arm-*-netbsdelf', `arm-*-*linux' and `arm-*-rtems'.
-
-avr
-===
-
-ATMEL AVR-family micro controllers. These are used in embedded
-applications. There are no standard Unix configurations. *Note AVR
-Options: (gcc)AVR Options, for the list of supported MCU types.
-
- Use `configure --target=avr --enable-languages="c"' to configure GCC.
-
- Further installation notes and other useful information about AVR
-tools can also be obtained from:
-
- * http://www.nongnu.org/avr/
-
- * http://www.amelek.gda.pl/avr/
-
- We _strongly_ recommend using binutils 2.13 or newer.
-
- The following error:
- Error: register required
-
- indicates that you should upgrade to a newer version of the binutils.
-
-Blackfin
-========
-
-The Blackfin processor, an Analog Devices DSP. *Note Blackfin Options:
-(gcc)Blackfin Options,
-
- More information, and a version of binutils with support for this
-processor, is available at `http://blackfin.uclinux.org'
-
-CRIS
-====
-
-CRIS is the CPU architecture in Axis Communications ETRAX
-system-on-a-chip series. These are used in embedded applications.
-
- *Note CRIS Options: (gcc)CRIS Options, for a list of CRIS-specific
-options.
-
- There are a few different CRIS targets:
-`cris-axis-elf'
- Mainly for monolithic embedded systems. Includes a multilib for
- the `v10' core used in `ETRAX 100 LX'.
-
-`cris-axis-linux-gnu'
- A GNU/Linux port for the CRIS architecture, currently targeting
- `ETRAX 100 LX' by default.
-
- For `cris-axis-elf' you need binutils 2.11 or newer. For
-`cris-axis-linux-gnu' you need binutils 2.12 or newer.
-
- Pre-packaged tools can be obtained from
-`ftp://ftp.axis.com/pub/axis/tools/cris/compiler-kit/'. More
-information about this platform is available at
-`http://developer.axis.com/'.
-
-CRX
-===
-
-The CRX CompactRISC architecture is a low-power 32-bit architecture with
-fast context switching and architectural extensibility features.
-
- *Note CRX Options: (gcc)CRX Options,
-
- Use `configure --target=crx-elf --enable-languages=c,c++' to
-configure GCC for building a CRX cross-compiler. The option
-`--target=crx-elf' is also used to build the `newlib' C library for CRX.
-
- It is also possible to build libstdc++-v3 for the CRX architecture.
-This needs to be done in a separate step with the following configure
-settings:
-
- gcc/libstdc++-v3/configure --host=crx-elf --with-newlib \
- --enable-sjlj-exceptions --enable-cxx-flags='-fexceptions -frtti'
-
-DOS
-===
-
-Please have a look at the binaries page.
-
- You cannot install GCC by itself on MSDOS; it will not compile under
-any MSDOS compiler except itself. You need to get the complete
-compilation package DJGPP, which includes binaries as well as sources,
-and includes all the necessary compilation tools and libraries.
-
-*-*-freebsd*
-============
-
-Support for FreeBSD 1 was discontinued in GCC 3.2. Support for FreeBSD
-2 (and any mutant a.out variants of FreeBSD 3) was discontinued in GCC
-4.0.
-
- In order to better utilize FreeBSD base system functionality and
-match the configuration of the system compiler, GCC 4.5 and above as
-well as GCC 4.4 past 2010-06-20 leverage SSP support in libc (which is
-present on FreeBSD 7 or later) and the use of `__cxa_atexit' by default
-(on FreeBSD 6 or later). The use of `dl_iterate_phdr' inside
-`libgcc_s.so.1' and boehm-gc (on FreeBSD 7 or later) is enabled by GCC
-4.5 and above.
-
- We support FreeBSD using the ELF file format with DWARF 2 debugging
-for all CPU architectures. You may use `-gstabs' instead of `-g', if
-you really want the old debugging format. There are no known issues
-with mixing object files and libraries with different debugging
-formats. Otherwise, this release of GCC should now match more of the
-configuration used in the stock FreeBSD configuration of GCC. In
-particular, `--enable-threads' is now configured by default. However,
-as a general user, do not attempt to replace the system compiler with
-this release. Known to bootstrap and check with good results on
-FreeBSD 7.2-STABLE. In the past, known to bootstrap and check with
-good results on FreeBSD 3.0, 3.4, 4.0, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9 and
-5-CURRENT.
-
- The version of binutils installed in `/usr/bin' probably works with
-this release of GCC. Bootstrapping against the latest GNU binutils
-and/or the version found in `/usr/ports/devel/binutils' has been known
-to enable additional features and improve overall testsuite results.
-However, it is currently known that boehm-gc (which itself is required
-for java) may not configure properly on FreeBSD prior to the FreeBSD
-7.0 release with GNU binutils after 2.16.1.
-
-h8300-hms
-=========
-
-Renesas H8/300 series of processors.
-
- Please have a look at the binaries page.
-
- The calling convention and structure layout has changed in release
-2.6. All code must be recompiled. The calling convention now passes
-the first three arguments in function calls in registers. Structures
-are no longer a multiple of 2 bytes.
-
-hppa*-hp-hpux*
-==============
-
-Support for HP-UX version 9 and older was discontinued in GCC 3.4.
-
- We require using gas/binutils on all hppa platforms. Version 2.19 or
-later is recommended.
-
- It may be helpful to configure GCC with the `--with-gnu-as' and
-`--with-as=...' options to ensure that GCC can find GAS.
-
- The HP assembler should not be used with GCC. It is rarely tested
-and may not work. It shouldn't be used with any languages other than C
-due to its many limitations.
-
- Specifically, `-g' does not work (HP-UX uses a peculiar debugging
-format which GCC does not know about). It also inserts timestamps into
-each object file it creates, causing the 3-stage comparison test to
-fail during a bootstrap. You should be able to continue by saying
-`make all-host all-target' after getting the failure from `make'.
-
- Various GCC features are not supported. For example, it does not
-support weak symbols or alias definitions. As a result, explicit
-template instantiations are required when using C++. This makes it
-difficult if not impossible to build many C++ applications.
-
- There are two default scheduling models for instructions. These are
-PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc
-architecture specified for the target machine when configuring.
-PROCESSOR_8000 is the default. PROCESSOR_7100LC is selected when the
-target is a `hppa1*' machine.
-
- The PROCESSOR_8000 model is not well suited to older processors.
-Thus, it is important to completely specify the machine architecture
-when configuring if you want a model other than PROCESSOR_8000. The
-macro TARGET_SCHED_DEFAULT can be defined in BOOT_CFLAGS if a different
-default scheduling model is desired.
-
- As of GCC 4.0, GCC uses the UNIX 95 namespace for HP-UX 10.10
-through 11.00, and the UNIX 98 namespace for HP-UX 11.11 and later.
-This namespace change might cause problems when bootstrapping with an
-earlier version of GCC or the HP compiler as essentially the same
-namespace is required for an entire build. This problem can be avoided
-in a number of ways. With HP cc, `UNIX_STD' can be set to `95' or
-`98'. Another way is to add an appropriate set of predefines to `CC'.
-The description for the `munix=' option contains a list of the
-predefines used with each standard.
-
- More specific information to `hppa*-hp-hpux*' targets follows.
-
-hppa*-hp-hpux10
-===============
-
-For hpux10.20, we _highly_ recommend you pick up the latest sed patch
-`PHCO_19798' from HP.
-
- The C++ ABI has changed incompatibly in GCC 4.0. COMDAT subspaces
-are used for one-only code and data. This resolves many of the previous
-problems in using C++ on this target. However, the ABI is not
-compatible with the one implemented under HP-UX 11 using secondary
-definitions.
-
-hppa*-hp-hpux11
-===============
-
-GCC 3.0 and up support HP-UX 11. GCC 2.95.x is not supported and cannot
-be used to compile GCC 3.0 and up.
-
- The libffi and libjava libraries haven't been ported to 64-bit HP-UX
-and don't build.
-
- Refer to binaries for information about obtaining precompiled GCC
-binaries for HP-UX. Precompiled binaries must be obtained to build the
-Ada language as it can't be bootstrapped using C. Ada is only
-available for the 32-bit PA-RISC runtime.
-
- Starting with GCC 3.4 an ISO C compiler is required to bootstrap.
-The bundled compiler supports only traditional C; you will need either
-HP's unbundled compiler, or a binary distribution of GCC.
-
- It is possible to build GCC 3.3 starting with the bundled HP
-compiler, but the process requires several steps. GCC 3.3 can then be
-used to build later versions. The fastjar program contains ISO C code
-and can't be built with the HP bundled compiler. This problem can be
-avoided by not building the Java language. For example, use the
-`--enable-languages="c,c++,f77,objc"' option in your configure command.
-
- There are several possible approaches to building the distribution.
-Binutils can be built first using the HP tools. Then, the GCC
-distribution can be built. The second approach is to build GCC first
-using the HP tools, then build binutils, then rebuild GCC. There have
-been problems with various binary distributions, so it is best not to
-start from a binary distribution.
-
- On 64-bit capable systems, there are two distinct targets. Different
-installation prefixes must be used if both are to be installed on the
-same system. The `hppa[1-2]*-hp-hpux11*' target generates code for the
-32-bit PA-RISC runtime architecture and uses the HP linker. The
-`hppa64-hp-hpux11*' target generates 64-bit code for the PA-RISC 2.0
-architecture.
-
- The script config.guess now selects the target type based on the
-compiler detected during configuration. You must define `PATH' or `CC'
-so that configure finds an appropriate compiler for the initial
-bootstrap. When `CC' is used, the definition should contain the
-options that are needed whenever `CC' is used.
-
- Specifically, options that determine the runtime architecture must be
-in `CC' to correctly select the target for the build. It is also
-convenient to place many other compiler options in `CC'. For example,
-`CC="cc -Ac +DA2.0W -Wp,-H16376 -D_CLASSIC_TYPES -D_HPUX_SOURCE"' can
-be used to bootstrap the GCC 3.3 branch with the HP compiler in 64-bit
-K&R/bundled mode. The `+DA2.0W' option will result in the automatic
-selection of the `hppa64-hp-hpux11*' target. The macro definition
-table of cpp needs to be increased for a successful build with the HP
-compiler. _CLASSIC_TYPES and _HPUX_SOURCE need to be defined when
-building with the bundled compiler, or when using the `-Ac' option.
-These defines aren't necessary with `-Ae'.
-
- It is best to explicitly configure the `hppa64-hp-hpux11*' target
-with the `--with-ld=...' option. This overrides the standard search
-for ld. The two linkers supported on this target require different
-commands. The default linker is determined during configuration. As a
-result, it's not possible to switch linkers in the middle of a GCC
-build. This has been reported to sometimes occur in unified builds of
-binutils and GCC.
-
- A recent linker patch must be installed for the correct operation of
-GCC 3.3 and later. `PHSS_26559' and `PHSS_24304' are the oldest linker
-patches that are known to work. They are for HP-UX 11.00 and 11.11,
-respectively. `PHSS_24303', the companion to `PHSS_24304', might be
-usable but it hasn't been tested. These patches have been superseded.
-Consult the HP patch database to obtain the currently recommended
-linker patch for your system.
-
- The patches are necessary for the support of weak symbols on the
-32-bit port, and for the running of initializers and finalizers. Weak
-symbols are implemented using SOM secondary definition symbols. Prior
-to HP-UX 11, there are bugs in the linker support for secondary symbols.
-The patches correct a problem of linker core dumps creating shared
-libraries containing secondary symbols, as well as various other
-linking issues involving secondary symbols.
-
- GCC 3.3 uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capabilities to
-run initializers and finalizers on the 64-bit port. The 32-bit port
-uses the linker `+init' and `+fini' options for the same purpose. The
-patches correct various problems with the +init/+fini options,
-including program core dumps. Binutils 2.14 corrects a problem on the
-64-bit port resulting from HP's non-standard use of the .init and .fini
-sections for array initializers and finalizers.
-
- Although the HP and GNU linkers are both supported for the
-`hppa64-hp-hpux11*' target, it is strongly recommended that the HP
-linker be used for link editing on this target.
-
- At this time, the GNU linker does not support the creation of long
-branch stubs. As a result, it can't successfully link binaries
-containing branch offsets larger than 8 megabytes. In addition, there
-are problems linking shared libraries, linking executables with
-`-static', and with dwarf2 unwind and exception support. It also
-doesn't provide stubs for internal calls to global functions in shared
-libraries, so these calls can't be overloaded.
-
- The HP dynamic loader does not support GNU symbol versioning, so
-symbol versioning is not supported. It may be necessary to disable
-symbol versioning with `--disable-symvers' when using GNU ld.
-
- POSIX threads are the default. The optional DCE thread library is
-not supported, so `--enable-threads=dce' does not work.
-
-*-*-linux-gnu
-=============
-
-Versions of libstdc++-v3 starting with 3.2.1 require bug fixes present
-in glibc 2.2.5 and later. More information is available in the
-libstdc++-v3 documentation.
-
-i?86-*-linux*
-=============
-
-As of GCC 3.3, binutils 2.13.1 or later is required for this platform.
-See bug 10877 for more information.
-
- If you receive Signal 11 errors when building on GNU/Linux, then it
-is possible you have a hardware problem. Further information on this
-can be found on www.bitwizard.nl.
-
-i?86-*-solaris2.[89]
-====================
-
-The Sun assembler in Solaris 8 and 9 has several bugs and limitations.
-While GCC works around them, several features are missing, so it is
-recommended to use the GNU assembler instead. There is no bundled
-version, but the current version, from GNU binutils 2.21, is known to
-work.
-
- Solaris 2/x86 doesn't support the execution of SSE/SSE2 instructions
-before Solaris 9 4/04, even if the CPU supports them. Programs will
-receive `SIGILL' if they try. The fix is available both in Solaris 9
-Update 6 and kernel patch 112234-12 or newer. There is no
-corresponding patch for Solaris 8. To avoid this problem, `-march'
-defaults to `pentiumpro' on Solaris 8 and 9. If you have the patch
-installed, you can configure GCC with an appropriate `--with-arch'
-option, but need GNU `as' for SSE2 support.
-
-i?86-*-solaris2.10
-==================
-
-Use this for Solaris 10 or later on x86 and x86-64 systems. This
-configuration is supported by GCC 4.0 and later versions only. Unlike
-`sparcv9-sun-solaris2*', there is no corresponding 64-bit configuration
-like `amd64-*-solaris2*' or `x86_64-*-solaris2*'.
-
- It is recommended that you configure GCC to use the GNU assembler, in
-`/usr/sfw/bin/gas'. The versions included in Solaris 10, from GNU
-binutils 2.15, and Solaris 11, from GNU binutils 2.19, work fine,
-although the current version, from GNU binutils 2.21, is known to work,
-too. Recent versions of the Sun assembler in `/usr/ccs/bin/as' work
-almost as well, though.
-
- For linking, the Sun linker, is preferred. If you want to use the
-GNU linker instead, which is available in `/usr/sfw/bin/gld', note that
-due to a packaging bug the version in Solaris 10, from GNU binutils
-2.15, cannot be used, while the version in Solaris 11, from GNU binutils
-2.19, works, as does the latest version, from GNU binutils 2.21.
-
- To use GNU `as', configure with the options `--with-gnu-as
---with-as=/usr/sfw/bin/gas'. It may be necessary to configure with
-`--without-gnu-ld --with-ld=/usr/ccs/bin/ld' to guarantee use of Sun
-`ld'.
-
-ia64-*-linux
-============
-
-IA-64 processor (also known as IPF, or Itanium Processor Family)
-running GNU/Linux.
-
- If you are using the installed system libunwind library with
-`--with-system-libunwind', then you must use libunwind 0.98 or later.
-
- None of the following versions of GCC has an ABI that is compatible
-with any of the other versions in this list, with the exception that
-Red Hat 2.96 and Trillian 000171 are compatible with each other: 3.1,
-3.0.2, 3.0.1, 3.0, Red Hat 2.96, and Trillian 000717. This primarily
-affects C++ programs and programs that create shared libraries. GCC
-3.1 or later is recommended for compiling linux, the kernel. As of
-version 3.1 GCC is believed to be fully ABI compliant, and hence no
-more major ABI changes are expected.
-
-ia64-*-hpux*
-============
-
-Building GCC on this target requires the GNU Assembler. The bundled HP
-assembler will not work. To prevent GCC from using the wrong assembler,
-the option `--with-gnu-as' may be necessary.
-
- The GCC libunwind library has not been ported to HPUX. This means
-that for GCC versions 3.2.3 and earlier, `--enable-libunwind-exceptions'
-is required to build GCC. For GCC 3.3 and later, this is the default.
-For gcc 3.4.3 and later, `--enable-libunwind-exceptions' is removed and
-the system libunwind library will always be used.
-
-*-ibm-aix*
-==========
-
-Support for AIX version 3 and older was discontinued in GCC 3.4.
-Support for AIX version 4.2 and older was discontinued in GCC 4.5.
-
- "out of memory" bootstrap failures may indicate a problem with
-process resource limits (ulimit). Hard limits are configured in the
-`/etc/security/limits' system configuration file.
-
- GCC can bootstrap with recent versions of IBM XLC, but bootstrapping
-with an earlier release of GCC is recommended. Bootstrapping with XLC
-requires a larger data segment, which can be enabled through the
-LDR_CNTRL environment variable, e.g.,
-
- % LDR_CNTRL=MAXDATA=0x50000000
- % export LDR_CNTRL
-
- One can start with a pre-compiled version of GCC to build from
-sources. One may delete GCC's "fixed" header files when starting with
-a version of GCC built for an earlier release of AIX.
-
- To speed up the configuration phases of bootstrapping and installing
-GCC, one may use GNU Bash instead of AIX `/bin/sh', e.g.,
-
- % CONFIG_SHELL=/opt/freeware/bin/bash
- % export CONFIG_SHELL
-
- and then proceed as described in the build instructions, where we
-strongly recommend specifying an absolute path to invoke
-SRCDIR/configure.
-
- Because GCC on AIX is built as a 32-bit executable by default,
-(although it can generate 64-bit programs) the GMP and MPFR libraries
-required by gfortran must be 32-bit libraries. Building GMP and MPFR
-as static archive libraries works better than shared libraries.
-
- Errors involving `alloca' when building GCC generally are due to an
-incorrect definition of `CC' in the Makefile or mixing files compiled
-with the native C compiler and GCC. During the stage1 phase of the
-build, the native AIX compiler *must* be invoked as `cc' (not `xlc').
-Once `configure' has been informed of `xlc', one needs to use `make
-distclean' to remove the configure cache files and ensure that `CC'
-environment variable does not provide a definition that will confuse
-`configure'. If this error occurs during stage2 or later, then the
-problem most likely is the version of Make (see above).
-
- The native `as' and `ld' are recommended for bootstrapping on AIX.
-The GNU Assembler, GNU Linker, and GNU Binutils version 2.20 is
-required to bootstrap on AIX 5. The native AIX tools do interoperate
-with GCC.
-
- Building `libstdc++.a' requires a fix for an AIX Assembler bug APAR
-IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1). It also requires a fix
-for another AIX Assembler bug and a co-dependent AIX Archiver fix
-referenced as APAR IY53606 (AIX 5.2) or as APAR IY54774 (AIX 5.1)
-
- `libstdc++' in GCC 3.4 increments the major version number of the
-shared object and GCC installation places the `libstdc++.a' shared
-library in a common location which will overwrite the and GCC 3.3
-version of the shared library. Applications either need to be
-re-linked against the new shared library or the GCC 3.1 and GCC 3.3
-versions of the `libstdc++' shared object needs to be available to the
-AIX runtime loader. The GCC 3.1 `libstdc++.so.4', if present, and GCC
-3.3 `libstdc++.so.5' shared objects can be installed for runtime
-dynamic loading using the following steps to set the `F_LOADONLY' flag
-in the shared object for _each_ multilib `libstdc++.a' installed:
-
- Extract the shared objects from the currently installed
-`libstdc++.a' archive:
- % ar -x libstdc++.a libstdc++.so.4 libstdc++.so.5
-
- Enable the `F_LOADONLY' flag so that the shared object will be
-available for runtime dynamic loading, but not linking:
- % strip -e libstdc++.so.4 libstdc++.so.5
-
- Archive the runtime-only shared object in the GCC 3.4 `libstdc++.a'
-archive:
- % ar -q libstdc++.a libstdc++.so.4 libstdc++.so.5
-
- Linking executables and shared libraries may produce warnings of
-duplicate symbols. The assembly files generated by GCC for AIX always
-have included multiple symbol definitions for certain global variable
-and function declarations in the original program. The warnings should
-not prevent the linker from producing a correct library or runnable
-executable.
-
- AIX 4.3 utilizes a "large format" archive to support both 32-bit and
-64-bit object modules. The routines provided in AIX 4.3.0 and AIX 4.3.1
-to parse archive libraries did not handle the new format correctly.
-These routines are used by GCC and result in error messages during
-linking such as "not a COFF file". The version of the routines shipped
-with AIX 4.3.1 should work for a 32-bit environment. The `-g' option
-of the archive command may be used to create archives of 32-bit objects
-using the original "small format". A correct version of the routines
-is shipped with AIX 4.3.2 and above.
-
- Some versions of the AIX binder (linker) can fail with a relocation
-overflow severe error when the `-bbigtoc' option is used to link
-GCC-produced object files into an executable that overflows the TOC. A
-fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC)
-is available from IBM Customer Support and from its
-techsupport.services.ibm.com website as PTF U455193.
-
- The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump
-core with a segmentation fault when invoked by any version of GCC. A
-fix for APAR IX87327 is available from IBM Customer Support and from its
-techsupport.services.ibm.com website as PTF U461879. This fix is
-incorporated in AIX 4.3.3 and above.
-
- The initial assembler shipped with AIX 4.3.0 generates incorrect
-object files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM
-COMPILER FAILS TO ASSEMBLE/BIND) is available from IBM Customer Support
-and from its techsupport.services.ibm.com website as PTF U453956. This
-fix is incorporated in AIX 4.3.1 and above.
-
- AIX provides National Language Support (NLS). Compilers and
-assemblers use NLS to support locale-specific representations of
-various data formats including floating-point numbers (e.g., `.' vs
-`,' for separating decimal fractions). There have been problems
-reported where GCC does not produce the same floating-point formats
-that the assembler expects. If one encounters this problem, set the
-`LANG' environment variable to `C' or `En_US'.
-
- A default can be specified with the `-mcpu=CPU_TYPE' switch and
-using the configure option `--with-cpu-CPU_TYPE'.
-
-iq2000-*-elf
-============
-
-Vitesse IQ2000 processors. These are used in embedded applications.
-There are no standard Unix configurations.
-
-lm32-*-elf
-==========
-
-Lattice Mico32 processor. This configuration is intended for embedded
-systems.
-
-lm32-*-uclinux
-==============
-
-Lattice Mico32 processor. This configuration is intended for embedded
-systems running uClinux.
-
-m32c-*-elf
-==========
-
-Renesas M32C processor. This configuration is intended for embedded
-systems.
-
-m32r-*-elf
-==========
-
-Renesas M32R processor. This configuration is intended for embedded
-systems.
-
-m6811-elf
-=========
-
-Motorola 68HC11 family micro controllers. These are used in embedded
-applications. There are no standard Unix configurations.
-
-m6812-elf
-=========
-
-Motorola 68HC12 family micro controllers. These are used in embedded
-applications. There are no standard Unix configurations.
-
-m68k-*-*
-========
-
-By default, `m68k-*-elf*', `m68k-*-rtems', `m68k-*-uclinux' and
-`m68k-*-linux' build libraries for both M680x0 and ColdFire processors.
-If you only need the M680x0 libraries, you can omit the ColdFire ones
-by passing `--with-arch=m68k' to `configure'. Alternatively, you can
-omit the M680x0 libraries by passing `--with-arch=cf' to `configure'.
-These targets default to 5206 or 5475 code as appropriate for the
-target system when configured with `--with-arch=cf' and 68020 code
-otherwise.
-
- The `m68k-*-netbsd' and `m68k-*-openbsd' targets also support the
-`--with-arch' option. They will generate ColdFire CFV4e code when
-configured with `--with-arch=cf' and 68020 code otherwise.
-
- You can override the default processors listed above by configuring
-with `--with-cpu=TARGET'. This TARGET can either be a `-mcpu' argument
-or one of the following values: `m68000', `m68010', `m68020', `m68030',
-`m68040', `m68060', `m68020-40' and `m68020-60'.
-
-m68k-*-uclinux
-==============
-
-GCC 4.3 changed the uClinux configuration so that it uses the
-`m68k-linux-gnu' ABI rather than the `m68k-elf' ABI. It also added
-improved support for C++ and flat shared libraries, both of which were
-ABI changes. However, you can still use the original ABI by
-configuring for `m68k-uclinuxoldabi' or `m68k-VENDOR-uclinuxoldabi'.
-
-mep-*-elf
-=========
-
-Toshiba Media embedded Processor. This configuration is intended for
-embedded systems.
-
-microblaze-*-elf
-================
-
-Xilinx MicroBlaze processor. This configuration is intended for
-embedded systems.
-
-mips-*-*
-========
-
-If on a MIPS system you get an error message saying "does not have gp
-sections for all it's [sic] sectons [sic]", don't worry about it. This
-happens whenever you use GAS with the MIPS linker, but there is not
-really anything wrong, and it is okay to use the output file. You can
-stop such warnings by installing the GNU linker.
-
- It would be nice to extend GAS to produce the gp tables, but they are
-optional, and there should not be a warning about their absence.
-
- The libstdc++ atomic locking routines for MIPS targets requires MIPS
-II and later. A patch went in just after the GCC 3.3 release to make
-`mips*-*-*' use the generic implementation instead. You can also
-configure for `mipsel-elf' as a workaround. The `mips*-*-linux*'
-target continues to use the MIPS II routines. More work on this is
-expected in future releases.
-
- The built-in `__sync_*' functions are available on MIPS II and later
-systems and others that support the `ll', `sc' and `sync' instructions.
-This can be overridden by passing `--with-llsc' or `--without-llsc'
-when configuring GCC. Since the Linux kernel emulates these
-instructions if they are missing, the default for `mips*-*-linux*'
-targets is `--with-llsc'. The `--with-llsc' and `--without-llsc'
-configure options may be overridden at compile time by passing the
-`-mllsc' or `-mno-llsc' options to the compiler.
-
- MIPS systems check for division by zero (unless
-`-mno-check-zero-division' is passed to the compiler) by generating
-either a conditional trap or a break instruction. Using trap results
-in smaller code, but is only supported on MIPS II and later. Also,
-some versions of the Linux kernel have a bug that prevents trap from
-generating the proper signal (`SIGFPE'). To enable the use of break,
-use the `--with-divide=breaks' `configure' option when configuring GCC.
-The default is to use traps on systems that support them.
-
- Cross-compilers for the MIPS as target using the MIPS assembler
-currently do not work, because the auxiliary programs `mips-tdump.c'
-and `mips-tfile.c' can't be compiled on anything but a MIPS. It does
-work to cross compile for a MIPS if you use the GNU assembler and
-linker.
-
- The assembler from GNU binutils 2.17 and earlier has a bug in the way
-it sorts relocations for REL targets (o32, o64, EABI). This can cause
-bad code to be generated for simple C++ programs. Also the linker from
-GNU binutils versions prior to 2.17 has a bug which causes the runtime
-linker stubs in very large programs, like `libgcj.so', to be
-incorrectly generated. GNU Binutils 2.18 and later (and snapshots made
-after Nov. 9, 2006) should be free from both of these problems.
-
-mips-sgi-irix5
-==============
-
-Support for IRIX 5 has been removed in GCC 4.6.
-
-mips-sgi-irix6
-==============
-
-Support for IRIX 6 releases before 6.5 has been removed in GCC 4.6, as
-well as support for the O32 ABI. It is _strongly_ recommended to
-upgrade to at least IRIX 6.5.18. This release introduced full ISO C99
-support, though for the N32 and N64 ABIs only.
-
- To build and use GCC on IRIX 6.5, you need the IRIX Development
-Foundation (IDF) and IRIX Development Libraries (IDL). They are
-included with the IRIX 6.5 media.
-
- If you are using SGI's MIPSpro `cc' as your bootstrap compiler, you
-must ensure that the N32 ABI is in use. To test this, compile a simple
-C file with `cc' and then run `file' on the resulting object file. The
-output should look like:
-
- test.o: ELF N32 MSB ...
-
-If you see:
-
- test.o: ELF 32-bit MSB ...
-
-or
-
- test.o: ELF 64-bit MSB ...
-
-then your version of `cc' uses the O32 or N64 ABI by default. You
-should set the environment variable `CC' to `cc -n32' before
-configuring GCC.
-
- If you want the resulting `gcc' to run on old 32-bit systems with
-the MIPS R4400 CPU, you need to ensure that only code for the `mips3'
-instruction set architecture (ISA) is generated. While GCC 3.x does
-this correctly, both GCC 2.95 and SGI's MIPSpro `cc' may change the ISA
-depending on the machine where GCC is built. Using one of them as the
-bootstrap compiler may result in `mips4' code, which won't run at all
-on `mips3'-only systems. For the test program above, you should see:
-
- test.o: ELF N32 MSB mips-3 ...
-
-If you get:
-
- test.o: ELF N32 MSB mips-4 ...
-
-instead, you should set the environment variable `CC' to `cc -n32
--mips3' or `gcc -mips3' respectively before configuring GCC.
-
- MIPSpro C 7.4 may cause bootstrap failures, due to a bug when
-inlining `memcmp'. Either add `-U__INLINE_INTRINSICS' to the `CC'
-environment variable as a workaround or upgrade to MIPSpro C 7.4.1m.
-
- GCC on IRIX 6.5 is usually built to support the N32 and N64 ABIs. If
-you build GCC on a system that doesn't have the N64 libraries installed
-or cannot run 64-bit binaries, you need to configure with
-`--disable-multilib' so GCC doesn't try to use them. Look for
-`/usr/lib64/libc.so.1' to see if you have the 64-bit libraries
-installed.
-
- GCC must be configured with GNU `as'. The latest version, from GNU
-binutils 2.21, is known to work. On the other hand, bootstrap fails
-with GNU `ld' at least since GNU binutils 2.17.
-
- The `--enable-libgcj' option is disabled by default: IRIX 6 uses a
-very low default limit (20480) for the command line length. Although
-`libtool' contains a workaround for this problem, at least the N64
-`libgcj' is known not to build despite this, running into an internal
-error of the native `ld'. A sure fix is to increase this limit
-(`ncargs') to its maximum of 262144 bytes. If you have root access,
-you can use the `systune' command to do this.
-
- `wchar_t' support in `libstdc++' is not available for old IRIX 6.5.x
-releases, x < 19. The problem cannot be autodetected and in order to
-build GCC for such targets you need to configure with
-`--disable-wchar_t'.
-
-moxie-*-elf
-===========
-
-The moxie processor. See `http://moxielogic.org/' for more information
-about this processor.
-
-powerpc-*-*
-===========
-
-You can specify a default version for the `-mcpu=CPU_TYPE' switch by
-using the configure option `--with-cpu-CPU_TYPE'.
-
- You will need binutils 2.15 or newer for a working GCC.
-
-powerpc-*-darwin*
-=================
-
-PowerPC running Darwin (Mac OS X kernel).
-
- Pre-installed versions of Mac OS X may not include any developer
-tools, meaning that you will not be able to build GCC from source. Tool
-binaries are available at `http://opensource.apple.com/'.
-
- This version of GCC requires at least cctools-590.36. The
-cctools-590.36 package referenced from
-`http://gcc.gnu.org/ml/gcc/2006-03/msg00507.html' will not work on
-systems older than 10.3.9 (aka darwin7.9.0).
-
-powerpc-*-elf
-=============
-
-PowerPC system in big endian mode, running System V.4.
-
-powerpc*-*-linux-gnu*
-=====================
-
-PowerPC system in big endian mode running Linux.
-
-powerpc-*-netbsd*
-=================
-
-PowerPC system in big endian mode running NetBSD.
-
-powerpc-*-eabisim
-=================
-
-Embedded PowerPC system in big endian mode for use in running under the
-PSIM simulator.
-
-powerpc-*-eabi
-==============
-
-Embedded PowerPC system in big endian mode.
-
-powerpcle-*-elf
-===============
-
-PowerPC system in little endian mode, running System V.4.
-
-powerpcle-*-eabisim
-===================
-
-Embedded PowerPC system in little endian mode for use in running under
-the PSIM simulator.
-
-powerpcle-*-eabi
-================
-
-Embedded PowerPC system in little endian mode.
-
-rx-*-elf
-========
-
-The Renesas RX processor. See
-`http://eu.renesas.com/fmwk.jsp?cnt=rx600_series_landing.jsp&fp=/products/mpumcu/rx_family/rx600_series'
-for more information about this processor.
-
-s390-*-linux*
-=============
-
-S/390 system running GNU/Linux for S/390.
-
-s390x-*-linux*
-==============
-
-zSeries system (64-bit) running GNU/Linux for zSeries.
-
-s390x-ibm-tpf*
-==============
-
-zSeries system (64-bit) running TPF. This platform is supported as
-cross-compilation target only.
-
-*-*-solaris2*
-=============
-
-Support for Solaris 7 has been removed in GCC 4.6.
-
- Sun does not ship a C compiler with Solaris 2, though you can
-download the Sun Studio compilers for free. Alternatively, you can
-install a pre-built GCC to bootstrap and install GCC. See the binaries
-page for details.
-
- The Solaris 2 `/bin/sh' will often fail to configure `libstdc++-v3',
-`boehm-gc' or `libjava'. We therefore recommend using the following
-initial sequence of commands
-
- % CONFIG_SHELL=/bin/ksh
- % export CONFIG_SHELL
-
-and proceed as described in the configure instructions. In addition we
-strongly recommend specifying an absolute path to invoke
-`SRCDIR/configure'.
-
- Solaris 2 comes with a number of optional OS packages. Some of these
-are needed to use GCC fully, namely `SUNWarc', `SUNWbtool', `SUNWesu',
-`SUNWhea', `SUNWlibm', `SUNWsprot', and `SUNWtoo'. If you did not
-install all optional packages when installing Solaris 2, you will need
-to verify that the packages that GCC needs are installed.
-
- To check whether an optional package is installed, use the `pkginfo'
-command. To add an optional package, use the `pkgadd' command. For
-further details, see the Solaris 2 documentation.
-
- Trying to use the linker and other tools in `/usr/ucb' to install
-GCC has been observed to cause trouble. For example, the linker may
-hang indefinitely. The fix is to remove `/usr/ucb' from your `PATH'.
-
- The build process works more smoothly with the legacy Sun tools so,
-if you have `/usr/xpg4/bin' in your `PATH', we recommend that you place
-`/usr/bin' before `/usr/xpg4/bin' for the duration of the build.
-
- We recommend the use of the Sun assembler or the GNU assembler, in
-conjunction with the Sun linker. The GNU `as' versions included in
-Solaris 10, from GNU binutils 2.15, and Solaris 11, from GNU binutils
-2.19, are known to work. They can be found in `/usr/sfw/bin/gas'.
-Current versions of GNU binutils (2.21) are known to work as well.
-Note that your mileage may vary if you use a combination of the GNU
-tools and the Sun tools: while the combination GNU `as' + Sun `ld'
-should reasonably work, the reverse combination Sun `as' + GNU `ld' is
-known to cause memory corruption at runtime in some cases for C++
-programs. GNU `ld' usually works as well, although the version
-included in Solaris 10 cannot be used due to several bugs. Again, the
-current version (2.21) is known to work, but generally lacks platform
-specific features, so better stay with Sun `ld'.
-
- To enable symbol versioning in `libstdc++' with Sun `ld', you need
-to have any version of GNU `c++filt', which is part of GNU binutils.
-`libstdc++' symbol versioning will be disabled if no appropriate
-version is found. Sun `c++filt' from the Sun Studio compilers does
-_not_ work.
-
- Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or
-newer: `g++' will complain that types are missing. These headers
-assume that omitting the type means `int'; this assumption worked for
-C90 but is wrong for C++, and is now wrong for C99 also.
-
- `g++' accepts such (invalid) constructs with the option
-`-fpermissive'; it will assume that any missing type is `int' (as
-defined by C90).
-
- There are patches for Solaris 8 (108652-24 or newer for SPARC,
-108653-22 for Intel) that fix this bug.
-
- Sun bug 4927647 sometimes causes random spurious testsuite failures
-related to missing diagnostic output. This bug doesn't affect GCC
-itself, rather it is a kernel bug triggered by the `expect' program
-which is used only by the GCC testsuite driver. When the bug causes
-the `expect' program to miss anticipated output, extra testsuite
-failures appear.
-
- There are patches for Solaris 8 (117350-12 or newer for SPARC,
-117351-12 or newer for Intel) and Solaris 9 (117171-11 or newer for
-SPARC, 117172-11 or newer for Intel) that address this problem.
-
- Solaris 8 provides an alternate implementation of the thread
-libraries, `libpthread' and `libthread'. They are required for TLS
-support and have been made the default in Solaris 9, so they are always
-used on Solaris 8.
-
- Thread-local storage (TLS) is supported in Solaris 8 and 9, but
-requires some patches. The `libthread' patches provide the
-`__tls_get_addr' (SPARC, 64-bit x86) resp. `___tls_get_addr' (32-bit
-x86) functions. On Solaris 8, you need 108993-26 or newer on SPARC,
-108994-26 or newer on Intel. On Solaris 9, the necessary support on
-SPARC is present since FCS, while 114432-05 or newer is required on
-Intel. Additionally, on Solaris 8, patch 109147-14 or newer on SPARC or
-109148-22 or newer on Intel are required for the Sun `ld' and runtime
-linker (`ld.so.1') support. Again, Solaris 9/SPARC works since FCS,
-while 113986-02 is required on Intel. The linker patches must be
-installed even if GNU `ld' is used. Sun `as' in Solaris 8 and 9 doesn't
-support the necessary relocations, so GNU `as' must be used. The
-`configure' script checks for those prerequisites and automatically
-enables TLS support if they are met. Although those minimal patch
-versions should work, it is recommended to use the latest patch
-versions which include additional bug fixes.
-
-sparc*-*-*
-==========
-
-This section contains general configuration information for all
-SPARC-based platforms. In addition to reading this section, please
-read all other sections that match your target.
-
- Newer versions of the GNU Multiple Precision Library (GMP), the MPFR
-library and the MPC library are known to be miscompiled by earlier
-versions of GCC on these platforms. We therefore recommend the use of
-the exact versions of these libraries listed as minimal versions in the
-prerequisites.
-
-sparc-sun-solaris2*
-===================
-
-When GCC is configured to use GNU binutils 2.14 or later, the binaries
-produced are smaller than the ones produced using Sun's native tools;
-this difference is quite significant for binaries containing debugging
-information.
-
- Starting with Solaris 7, the operating system is capable of executing
-64-bit SPARC V9 binaries. GCC 3.1 and later properly supports this;
-the `-m64' option enables 64-bit code generation. However, if all you
-want is code tuned for the UltraSPARC CPU, you should try the
-`-mtune=ultrasparc' option instead, which produces code that, unlike
-full 64-bit code, can still run on non-UltraSPARC machines.
-
- When configuring on a Solaris 7 or later system that is running a
-kernel that supports only 32-bit binaries, one must configure with
-`--disable-multilib', since we will not be able to build the 64-bit
-target libraries.
-
- GCC 3.3 and GCC 3.4 trigger code generation bugs in earlier versions
-of the GNU compiler (especially GCC 3.0.x versions), which lead to the
-miscompilation of the stage1 compiler and the subsequent failure of the
-bootstrap process. A workaround is to use GCC 3.2.3 as an intermediary
-stage, i.e. to bootstrap that compiler with the base compiler and then
-use it to bootstrap the final compiler.
-
- GCC 3.4 triggers a code generation bug in versions 5.4 (Sun ONE
-Studio 7) and 5.5 (Sun ONE Studio 8) of the Sun compiler, which causes
-a bootstrap failure in form of a miscompilation of the stage1 compiler
-by the Sun compiler. This is Sun bug 4974440. This is fixed with
-patch 112760-07.
-
- GCC 3.4 changed the default debugging format from Stabs to DWARF-2
-for 32-bit code on Solaris 7 and later. If you use the Sun assembler,
-this change apparently runs afoul of Sun bug 4910101 (which is
-referenced as an x86-only problem by Sun, probably because they do not
-use DWARF-2). A symptom of the problem is that you cannot compile C++
-programs like `groff' 1.19.1 without getting messages similar to the
-following:
-
- ld: warning: relocation error: R_SPARC_UA32: ...
- external symbolic relocation against non-allocatable section
- .debug_info cannot be processed at runtime: relocation ignored.
-
-To work around this problem, compile with `-gstabs+' instead of plain
-`-g'.
-
- When configuring the GNU Multiple Precision Library (GMP), the MPFR
-library or the MPC library on a Solaris 7 or later system, the canonical
-target triplet must be specified as the `build' parameter on the
-configure line. This target triplet can be obtained by invoking
-`./config.guess' in the toplevel source directory of GCC (and not that
-of GMP or MPFR or MPC). For example on a Solaris 9 system:
-
- % ./configure --build=sparc-sun-solaris2.9 --prefix=xxx
-
-sparc-sun-solaris2.10
-=====================
-
-There is a bug in older versions of the Sun assembler which breaks
-thread-local storage (TLS). A typical error message is
-
- ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file /var/tmp//ccamPA1v.o:
- symbol <unknown>: bad symbol type SECT: symbol type must be TLS
-
-This bug is fixed in Sun patch 118683-03 or later.
-
-sparc-*-linux*
-==============
-
-GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4 or
-newer on this platform. All earlier binutils and glibc releases
-mishandled unaligned relocations on `sparc-*-*' targets.
-
-sparc64-*-solaris2*
-===================
-
-When configuring the GNU Multiple Precision Library (GMP) or the MPFR
-library, the canonical target triplet must be specified as the `build'
-parameter on the configure line. For example on a Solaris 9 system:
-
- % ./configure --build=sparc64-sun-solaris2.9 --prefix=xxx
-
- The following compiler flags must be specified in the configure step
-in order to bootstrap this target with the Sun compiler:
-
- % CC="cc -xarch=v9 -xildoff" SRCDIR/configure [OPTIONS] [TARGET]
-
-`-xarch=v9' specifies the SPARC-V9 architecture to the Sun toolchain
-and `-xildoff' turns off the incremental linker.
-
-sparcv9-*-solaris2*
-===================
-
-This is a synonym for `sparc64-*-solaris2*'.
-
-*-*-vxworks*
-============
-
-Support for VxWorks is in flux. At present GCC supports _only_ the
-very recent VxWorks 5.5 (aka Tornado 2.2) release, and only on PowerPC.
-We welcome patches for other architectures supported by VxWorks 5.5.
-Support for VxWorks AE would also be welcome; we believe this is merely
-a matter of writing an appropriate "configlette" (see below). We are
-not interested in supporting older, a.out or COFF-based, versions of
-VxWorks in GCC 3.
-
- VxWorks comes with an older version of GCC installed in
-`$WIND_BASE/host'; we recommend you do not overwrite it. Choose an
-installation PREFIX entirely outside $WIND_BASE. Before running
-`configure', create the directories `PREFIX' and `PREFIX/bin'. Link or
-copy the appropriate assembler, linker, etc. into `PREFIX/bin', and set
-your PATH to include that directory while running both `configure' and
-`make'.
-
- You must give `configure' the `--with-headers=$WIND_BASE/target/h'
-switch so that it can find the VxWorks system headers. Since VxWorks
-is a cross compilation target only, you must also specify
-`--target=TARGET'. `configure' will attempt to create the directory
-`PREFIX/TARGET/sys-include' and copy files into it; make sure the user
-running `configure' has sufficient privilege to do so.
-
- GCC's exception handling runtime requires a special "configlette"
-module, `contrib/gthr_supp_vxw_5x.c'. Follow the instructions in that
-file to add the module to your kernel build. (Future versions of
-VxWorks will incorporate this module.)
-
-x86_64-*-*, amd64-*-*
-=====================
-
-GCC supports the x86-64 architecture implemented by the AMD64 processor
-(amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD.
-On GNU/Linux the default is a bi-arch compiler which is able to generate
-both 64-bit x86-64 and 32-bit x86 code (via the `-m32' switch).
-
-xtensa*-*-elf
-=============
-
-This target is intended for embedded Xtensa systems using the `newlib'
-C library. It uses ELF but does not support shared objects.
-Designed-defined instructions specified via the Tensilica Instruction
-Extension (TIE) language are only supported through inline assembly.
-
- The Xtensa configuration information must be specified prior to
-building GCC. The `include/xtensa-config.h' header file contains the
-configuration information. If you created your own Xtensa
-configuration with the Xtensa Processor Generator, the downloaded files
-include a customized copy of this header file, which you can use to
-replace the default header file.
-
-xtensa*-*-linux*
-================
-
-This target is for Xtensa systems running GNU/Linux. It supports ELF
-shared objects and the GNU C library (glibc). It also generates
-position-independent code (PIC) regardless of whether the `-fpic' or
-`-fPIC' options are used. In other respects, this target is the same
-as the `xtensa*-*-elf' target.
-
-Microsoft Windows
-=================
-
-Intel 16-bit versions
----------------------
-
-The 16-bit versions of Microsoft Windows, such as Windows 3.1, are not
-supported.
-
- However, the 32-bit port has limited support for Microsoft Windows
-3.11 in the Win32s environment, as a target only. See below.
-
-Intel 32-bit versions
----------------------
-
-The 32-bit versions of Windows, including Windows 95, Windows NT,
-Windows XP, and Windows Vista, are supported by several different target
-platforms. These targets differ in which Windows subsystem they target
-and which C libraries are used.
-
- * Cygwin *-*-cygwin: Cygwin provides a user-space Linux API
- emulation layer in the Win32 subsystem.
-
- * Interix *-*-interix: The Interix subsystem provides native support
- for POSIX.
-
- * MinGW *-*-mingw32: MinGW is a native GCC port for the Win32
- subsystem that provides a subset of POSIX.
-
- * MKS i386-pc-mks: NuTCracker from MKS. See
- `http://www.mkssoftware.com/' for more information.
-
-Intel 64-bit versions
----------------------
-
-GCC contains support for x86-64 using the mingw-w64 runtime library,
-available from `http://mingw-w64.sourceforge.net/'. This library
-should be used with the target triple x86_64-pc-mingw32.
-
- Presently Windows for Itanium is not supported.
-
-Windows CE
-----------
-
-Windows CE is supported as a target only on ARM (arm-wince-pe), Hitachi
-SuperH (sh-wince-pe), and MIPS (mips-wince-pe).
-
-Other Windows Platforms
------------------------
-
-GCC no longer supports Windows NT on the Alpha or PowerPC.
-
- GCC no longer supports the Windows POSIX subsystem. However, it does
-support the Interix subsystem. See above.
-
- Old target names including *-*-winnt and *-*-windowsnt are no longer
-used.
-
- PW32 (i386-pc-pw32) support was never completed, and the project
-seems to be inactive. See `http://pw32.sourceforge.net/' for more
-information.
-
- UWIN support has been removed due to a lack of maintenance.
-
-*-*-cygwin
-==========
-
-Ports of GCC are included with the Cygwin environment.
-
- GCC will build under Cygwin without modification; it does not build
-with Microsoft's C++ compiler and there are no plans to make it do so.
-
- The Cygwin native compiler can be configured to target any 32-bit x86
-cpu architecture desired; the default is i686-pc-cygwin. It should be
-used with as up-to-date a version of binutils as possible; use either
-the latest official GNU binutils release in the Cygwin distribution, or
-version 2.20 or above if building your own.
-
-*-*-interix
-===========
-
-The Interix target is used by OpenNT, Interix, Services For UNIX (SFU),
-and Subsystem for UNIX-based Applications (SUA). Applications compiled
-with this target run in the Interix subsystem, which is separate from
-the Win32 subsystem. This target was last known to work in GCC 3.3.
-
-*-*-mingw32
-===========
-
-GCC will build with and support only MinGW runtime 3.12 and later.
-Earlier versions of headers are incompatible with the new default
-semantics of `extern inline' in `-std=c99' and `-std=gnu99' modes.
-
-Older systems
-=============
-
-GCC contains support files for many older (1980s and early 1990s) Unix
-variants. For the most part, support for these systems has not been
-deliberately removed, but it has not been maintained for several years
-and may suffer from bitrot.
-
- Starting with GCC 3.1, each release has a list of "obsoleted"
-systems. Support for these systems is still present in that release,
-but `configure' will fail unless the `--enable-obsolete' option is
-given. Unless a maintainer steps forward, support for these systems
-will be removed from the next release of GCC.
-
- Support for old systems as hosts for GCC can cause problems if the
-workarounds for compiler, library and operating system bugs affect the
-cleanliness or maintainability of the rest of GCC. In some cases, to
-bring GCC up on such a system, if still possible with current GCC, may
-require first installing an old version of GCC which did work on that
-system, and using it to compile a more recent GCC, to avoid bugs in the
-vendor compiler. Old releases of GCC 1 and GCC 2 are available in the
-`old-releases' directory on the GCC mirror sites. Header bugs may
-generally be avoided using `fixincludes', but bugs or deficiencies in
-libraries and the operating system may still cause problems.
-
- Support for older systems as targets for cross-compilation is less
-problematic than support for them as hosts for GCC; if an enthusiast
-wishes to make such a target work again (including resurrecting any of
-the targets that never worked with GCC 2, starting from the last
-version before they were removed), patches following the usual
-requirements would be likely to be accepted, since they should not
-affect the support for more modern targets.
-
- For some systems, old versions of GNU binutils may also be useful,
-and are available from `pub/binutils/old-releases' on sourceware.org
-mirror sites.
-
- Some of the information on specific systems above relates to such
-older systems, but much of the information about GCC on such systems
-(which may no longer be applicable to current GCC) is to be found in
-the GCC texinfo manual.
-
-all ELF targets (SVR4, Solaris 2, etc.)
-=======================================
-
-C++ support is significantly better on ELF targets if you use the GNU
-linker; duplicate copies of inlines, vtables and template
-instantiations will be discarded automatically.
-
-
-File: gccinstall.info, Node: Old, Next: GNU Free Documentation License, Prev: Specific, Up: Top
-
-10 Old installation documentation
-*********************************
-
- Note most of this information is out of date and superseded by the
-previous chapters of this manual. It is provided for historical
-reference only, because of a lack of volunteers to merge it into the
-main manual.
-
-* Menu:
-
-* Configurations:: Configurations Supported by GCC.
-
- Here is the procedure for installing GCC on a GNU or Unix system.
-
- 1. If you have chosen a configuration for GCC which requires other GNU
- tools (such as GAS or the GNU linker) instead of the standard
- system tools, install the required tools in the build directory
- under the names `as', `ld' or whatever is appropriate.
-
- Alternatively, you can do subsequent compilation using a value of
- the `PATH' environment variable such that the necessary GNU tools
- come before the standard system tools.
-
- 2. Specify the host, build and target machine configurations. You do
- this when you run the `configure' script.
-
- The "build" machine is the system which you are using, the "host"
- machine is the system where you want to run the resulting compiler
- (normally the build machine), and the "target" machine is the
- system for which you want the compiler to generate code.
-
- If you are building a compiler to produce code for the machine it
- runs on (a native compiler), you normally do not need to specify
- any operands to `configure'; it will try to guess the type of
- machine you are on and use that as the build, host and target
- machines. So you don't need to specify a configuration when
- building a native compiler unless `configure' cannot figure out
- what your configuration is or guesses wrong.
-
- In those cases, specify the build machine's "configuration name"
- with the `--host' option; the host and target will default to be
- the same as the host machine.
-
- Here is an example:
-
- ./configure --host=sparc-sun-sunos4.1
-
- A configuration name may be canonical or it may be more or less
- abbreviated.
-
- A canonical configuration name has three parts, separated by
- dashes. It looks like this: `CPU-COMPANY-SYSTEM'. (The three
- parts may themselves contain dashes; `configure' can figure out
- which dashes serve which purpose.) For example,
- `m68k-sun-sunos4.1' specifies a Sun 3.
-
- You can also replace parts of the configuration by nicknames or
- aliases. For example, `sun3' stands for `m68k-sun', so
- `sun3-sunos4.1' is another way to specify a Sun 3.
-
- You can specify a version number after any of the system types,
- and some of the CPU types. In most cases, the version is
- irrelevant, and will be ignored. So you might as well specify the
- version if you know it.
-
- See *note Configurations::, for a list of supported configuration
- names and notes on many of the configurations. You should check
- the notes in that section before proceeding any further with the
- installation of GCC.
-
-
-
-File: gccinstall.info, Node: Configurations, Up: Old
-
-10.1 Configurations Supported by GCC
-====================================
-
- Here are the possible CPU types:
-
- 1750a, a29k, alpha, arm, avr, cN, clipper, dsp16xx, elxsi, fr30,
- h8300, hppa1.0, hppa1.1, i370, i386, i486, i586, i686, i786, i860,
- i960, ip2k, m32r, m68000, m68k, m6811, m6812, m88k, mcore, mips,
- mipsel, mips64, mips64el, mn10200, mn10300, ns32k, pdp11, powerpc,
- powerpcle, romp, rs6000, sh, sparc, sparclite, sparc64, v850, vax,
- we32k.
-
- Here are the recognized company names. As you can see, customary
-abbreviations are used rather than the longer official names.
-
- acorn, alliant, altos, apollo, apple, att, bull, cbm, convergent,
- convex, crds, dec, dg, dolphin, elxsi, encore, harris, hitachi,
- hp, ibm, intergraph, isi, mips, motorola, ncr, next, ns, omron,
- plexus, sequent, sgi, sony, sun, tti, unicom, wrs.
-
- The company name is meaningful only to disambiguate when the rest of
-the information supplied is insufficient. You can omit it, writing
-just `CPU-SYSTEM', if it is not needed. For example, `vax-ultrix4.2'
-is equivalent to `vax-dec-ultrix4.2'.
-
- Here is a list of system types:
-
- 386bsd, aix, acis, amigaos, aos, aout, aux, bosx, bsd, clix, coff,
- ctix, cxux, dgux, dynix, ebmon, ecoff, elf, esix, freebsd, hms,
- genix, gnu, linux, linux-gnu, hiux, hpux, iris, irix, isc, luna,
- lynxos, mach, minix, msdos, mvs, netbsd, newsos, nindy, ns, osf,
- osfrose, ptx, riscix, riscos, rtu, sco, sim, solaris, sunos, sym,
- sysv, udi, ultrix, unicos, uniplus, unos, vms, vsta, vxworks,
- winnt, xenix.
-
-You can omit the system type; then `configure' guesses the operating
-system from the CPU and company.
-
- You can add a version number to the system type; this may or may not
-make a difference. For example, you can write `bsd4.3' or `bsd4.4' to
-distinguish versions of BSD. In practice, the version number is most
-needed for `sysv3' and `sysv4', which are often treated differently.
-
- `linux-gnu' is the canonical name for the GNU/Linux target; however
-GCC will also accept `linux'. The version of the kernel in use is not
-relevant on these systems. A suffix such as `libc1' or `aout'
-distinguishes major versions of the C library; all of the suffixed
-versions are obsolete.
-
- If you specify an impossible combination such as `i860-dg-vms', then
-you may get an error message from `configure', or it may ignore part of
-the information and do the best it can with the rest. `configure'
-always prints the canonical name for the alternative that it used. GCC
-does not support all possible alternatives.
-
- Often a particular model of machine has a name. Many machine names
-are recognized as aliases for CPU/company combinations. Thus, the
-machine name `sun3', mentioned above, is an alias for `m68k-sun'.
-Sometimes we accept a company name as a machine name, when the name is
-popularly used for a particular machine. Here is a table of the known
-machine names:
-
- 3300, 3b1, 3bN, 7300, altos3068, altos, apollo68, att-7300,
- balance, convex-cN, crds, decstation-3100, decstation, delta,
- encore, fx2800, gmicro, hp7NN, hp8NN, hp9k2NN, hp9k3NN, hp9k7NN,
- hp9k8NN, iris4d, iris, isi68, m3230, magnum, merlin, miniframe,
- mmax, news-3600, news800, news, next, pbd, pc532, pmax, powerpc,
- powerpcle, ps2, risc-news, rtpc, sun2, sun386i, sun386, sun3,
- sun4, symmetry, tower-32, tower.
-
-Remember that a machine name specifies both the cpu type and the company
-name. If you want to install your own homemade configuration files,
-you can use `local' as the company name to access them. If you use
-configuration `CPU-local', the configuration name without the cpu prefix
-is used to form the configuration file names.
-
- Thus, if you specify `m68k-local', configuration uses files
-`m68k.md', `local.h', `m68k.c', `xm-local.h', `t-local', and `x-local',
-all in the directory `config/m68k'.
-
-
-File: gccinstall.info, Node: GNU Free Documentation License, Next: Concept Index, Prev: Old, Up: Top
-
-GNU Free Documentation License
-******************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: gccinstall.info, Node: Concept Index, Prev: GNU Free Documentation License, Up: Top
-
-Concept Index
-*************
-
-
-* Menu:
-
-* Binaries: Binaries. (line 6)
-* build_configargs: Configuration. (line 1437)
-* Configuration: Configuration. (line 6)
-* configurations supported by GCC: Configurations. (line 6)
-* Downloading GCC: Downloading the source.
- (line 6)
-* Downloading the Source: Downloading the source.
- (line 6)
-* FDL, GNU Free Documentation License: GNU Free Documentation License.
- (line 6)
-* Host specific installation: Specific. (line 6)
-* host_configargs: Configuration. (line 1441)
-* Installing GCC: Binaries: Binaries. (line 6)
-* Installing GCC: Building: Building. (line 6)
-* Installing GCC: Configuration: Configuration. (line 6)
-* Installing GCC: Testing: Testing. (line 6)
-* Prerequisites: Prerequisites. (line 6)
-* Specific: Specific. (line 6)
-* Specific installation notes: Specific. (line 6)
-* Target specific installation: Specific. (line 6)
-* Target specific installation notes: Specific. (line 6)
-* target_configargs: Configuration. (line 1445)
-* Testing: Testing. (line 6)
-* Testsuite: Testing. (line 6)
-
-
-
-Tag Table:
-Node: Top2003
-Node: Installing GCC2561
-Node: Prerequisites4076
-Node: Downloading the source14232
-Node: Configuration16169
-Ref: with-gnu-as31471
-Ref: with-as32369
-Ref: with-gnu-ld33782
-Node: Building79791
-Node: Testing95276
-Node: Final install102973
-Node: Binaries108287
-Node: Specific109888
-Ref: alpha-x-x110394
-Ref: alpha-dec-osf51110883
-Ref: arc-x-elf113081
-Ref: arm-x-elf113181
-Ref: avr113401
-Ref: bfin114041
-Ref: cris114283
-Ref: crx115099
-Ref: dos115777
-Ref: x-x-freebsd116100
-Ref: h8300-hms117937
-Ref: hppa-hp-hpux118289
-Ref: hppa-hp-hpux10120660
-Ref: hppa-hp-hpux11121073
-Ref: x-x-linux-gnu126732
-Ref: ix86-x-linux126925
-Ref: ix86-x-solaris289127238
-Ref: ix86-x-solaris210128082
-Ref: ia64-x-linux129308
-Ref: ia64-x-hpux130078
-Ref: x-ibm-aix130633
-Ref: iq2000-x-elf136871
-Ref: lm32-x-elf137011
-Ref: lm32-x-uclinux137115
-Ref: m32c-x-elf137243
-Ref: m32r-x-elf137345
-Ref: m6811-elf137447
-Ref: m6812-elf137597
-Ref: m68k-x-x137747
-Ref: m68k-x-uclinux138719
-Ref: mep-x-elf139082
-Ref: microblaze-x-elf139192
-Ref: mips-x-x139311
-Ref: mips-sgi-irix5141988
-Ref: mips-sgi-irix6142068
-Ref: moxie-x-elf145136
-Ref: powerpc-x-x145256
-Ref: powerpc-x-darwin145461
-Ref: powerpc-x-elf145955
-Ref: powerpc-x-linux-gnu146040
-Ref: powerpc-x-netbsd146135
-Ref: powerpc-x-eabisim146223
-Ref: powerpc-x-eabi146349
-Ref: powerpcle-x-elf146425
-Ref: powerpcle-x-eabisim146517
-Ref: powerpcle-x-eabi146650
-Ref: rx-x-elf146733
-Ref: s390-x-linux146932
-Ref: s390x-x-linux147004
-Ref: s390x-ibm-tpf147091
-Ref: x-x-solaris2147222
-Ref: sparc-x-x152370
-Ref: sparc-sun-solaris2152872
-Ref: sparc-sun-solaris210155626
-Ref: sparc-x-linux156002
-Ref: sparc64-x-solaris2156227
-Ref: sparcv9-x-solaris2156863
-Ref: x-x-vxworks156950
-Ref: x86-64-x-x158472
-Ref: xtensa-x-elf158800
-Ref: xtensa-x-linux159471
-Ref: windows159812
-Ref: x-x-cygwin161769
-Ref: x-x-interix162322
-Ref: x-x-mingw32162631
-Ref: older162857
-Ref: elf164974
-Node: Old165232
-Node: Configurations168369
-Node: GNU Free Documentation License172351
-Node: Concept Index197498
-
-End Tag Table
diff --git a/share/info/gccint.info b/share/info/gccint.info
deleted file mode 100644
index ac9b051..0000000
--- a/share/info/gccint.info
+++ /dev/null
@@ -1,47869 +0,0 @@
-This is doc/gccint.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gcc/gcc-4.6/gcc/doc/gccint.texi.
-
-Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2010 Free
-Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with the
-Invariant Sections being "Funding Free Software", the Front-Cover Texts
-being (a) (see below), and with the Back-Cover Texts being (b) (see
-below). A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
- (a) The FSF's Front-Cover Text is:
-
- A GNU Manual
-
- (b) The FSF's Back-Cover Text is:
-
- You have freedom to copy and modify this GNU Manual, like GNU
-software. Copies published by the Free Software Foundation raise
-funds for GNU development.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* gccint: (gccint). Internals of the GNU Compiler Collection.
-END-INFO-DIR-ENTRY
- This file documents the internals of the GNU compilers.
-
- Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2010 Free
-Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with the
-Invariant Sections being "Funding Free Software", the Front-Cover Texts
-being (a) (see below), and with the Back-Cover Texts being (b) (see
-below). A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
- (a) The FSF's Front-Cover Text is:
-
- A GNU Manual
-
- (b) The FSF's Back-Cover Text is:
-
- You have freedom to copy and modify this GNU Manual, like GNU
-software. Copies published by the Free Software Foundation raise
-funds for GNU development.
-
-
-
-File: gccint.info, Node: Top, Next: Contributing, Up: (DIR)
-
-Introduction
-************
-
-This manual documents the internals of the GNU compilers, including how
-to port them to new targets and some information about how to write
-front ends for new languages. It corresponds to the compilers
-(GCC) version 4.6.x-google. The use of the GNU compilers is documented
-in a separate manual. *Note Introduction: (gcc)Top.
-
- This manual is mainly a reference manual rather than a tutorial. It
-discusses how to contribute to GCC (*note Contributing::), the
-characteristics of the machines supported by GCC as hosts and targets
-(*note Portability::), how GCC relates to the ABIs on such systems
-(*note Interface::), and the characteristics of the languages for which
-GCC front ends are written (*note Languages::). It then describes the
-GCC source tree structure and build system, some of the interfaces to
-GCC front ends, and how support for a target system is implemented in
-GCC.
-
- Additional tutorial information is linked to from
-`http://gcc.gnu.org/readings.html'.
-
-* Menu:
-
-* Contributing:: How to contribute to testing and developing GCC.
-* Portability:: Goals of GCC's portability features.
-* Interface:: Function-call interface of GCC output.
-* Libgcc:: Low-level runtime library used by GCC.
-* Languages:: Languages for which GCC front ends are written.
-* Source Tree:: GCC source tree structure and build system.
-* Testsuites:: GCC testsuites.
-* Options:: Option specification files.
-* Passes:: Order of passes, what they do, and what each file is for.
-* GENERIC:: Language-independent representation generated by Front Ends
-* GIMPLE:: Tuple representation used by Tree SSA optimizers
-* Tree SSA:: Analysis and optimization of GIMPLE
-* RTL:: Machine-dependent low-level intermediate representation.
-* Control Flow:: Maintaining and manipulating the control flow graph.
-* Loop Analysis and Representation:: Analysis and representation of loops
-* Machine Desc:: How to write machine description instruction patterns.
-* Target Macros:: How to write the machine description C macros and functions.
-* Host Config:: Writing the `xm-MACHINE.h' file.
-* Fragments:: Writing the `t-TARGET' and `x-HOST' files.
-* Collect2:: How `collect2' works; how it finds `ld'.
-* Header Dirs:: Understanding the standard header file directories.
-* Type Information:: GCC's memory management; generating type information.
-* Plugins:: Extending the compiler with plugins.
-* LTO:: Using Link-Time Optimization.
-
-* Funding:: How to help assure funding for free software.
-* GNU Project:: The GNU Project and GNU/Linux.
-
-* Copying:: GNU General Public License says
- how you can copy and share GCC.
-* GNU Free Documentation License:: How you can copy and share this manual.
-* Contributors:: People who have contributed to GCC.
-
-* Option Index:: Index to command line options.
-* Concept Index:: Index of concepts and symbol names.
-
-
-File: gccint.info, Node: Contributing, Next: Portability, Prev: Top, Up: Top
-
-1 Contributing to GCC Development
-*********************************
-
-If you would like to help pretest GCC releases to assure they work well,
-current development sources are available by SVN (see
-`http://gcc.gnu.org/svn.html'). Source and binary snapshots are also
-available for FTP; see `http://gcc.gnu.org/snapshots.html'.
-
- If you would like to work on improvements to GCC, please read the
-advice at these URLs:
-
- `http://gcc.gnu.org/contribute.html'
- `http://gcc.gnu.org/contributewhy.html'
-
-for information on how to make useful contributions and avoid
-duplication of effort. Suggested projects are listed at
-`http://gcc.gnu.org/projects/'.
-
-
-File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top
-
-2 GCC and Portability
-*********************
-
-GCC itself aims to be portable to any machine where `int' is at least a
-32-bit type. It aims to target machines with a flat (non-segmented)
-byte addressed data address space (the code address space can be
-separate). Target ABIs may have 8, 16, 32 or 64-bit `int' type. `char'
-can be wider than 8 bits.
-
- GCC gets most of the information about the target machine from a
-machine description which gives an algebraic formula for each of the
-machine's instructions. This is a very clean way to describe the
-target. But when the compiler needs information that is difficult to
-express in this fashion, ad-hoc parameters have been defined for
-machine descriptions. The purpose of portability is to reduce the
-total work needed on the compiler; it was not of interest for its own
-sake.
-
- GCC does not contain machine dependent code, but it does contain code
-that depends on machine parameters such as endianness (whether the most
-significant byte has the highest or lowest address of the bytes in a
-word) and the availability of autoincrement addressing. In the
-RTL-generation pass, it is often necessary to have multiple strategies
-for generating code for a particular kind of syntax tree, strategies
-that are usable for different combinations of parameters. Often, not
-all possible cases have been addressed, but only the common ones or
-only the ones that have been encountered. As a result, a new target
-may require additional strategies. You will know if this happens
-because the compiler will call `abort'. Fortunately, the new
-strategies can be added in a machine-independent fashion, and will
-affect only the target machines that need them.
-
-
-File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top
-
-3 Interfacing to GCC Output
-***************************
-
-GCC is normally configured to use the same function calling convention
-normally in use on the target system. This is done with the
-machine-description macros described (*note Target Macros::).
-
- However, returning of structure and union values is done differently on
-some target machines. As a result, functions compiled with PCC
-returning such types cannot be called from code compiled with GCC, and
-vice versa. This does not cause trouble often because few Unix library
-routines return structures or unions.
-
- GCC code returns structures and unions that are 1, 2, 4 or 8 bytes
-long in the same registers used for `int' or `double' return values.
-(GCC typically allocates variables of such types in registers also.)
-Structures and unions of other sizes are returned by storing them into
-an address passed by the caller (usually in a register). The target
-hook `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address.
-
- By contrast, PCC on most target machines returns structures and unions
-of any size by copying the data into an area of static storage, and then
-returning the address of that storage as if it were a pointer value.
-The caller must copy the data from that memory area to the place where
-the value is wanted. This is slower than the method used by GCC, and
-fails to be reentrant.
-
- On some target machines, such as RISC machines and the 80386, the
-standard system convention is to pass to the subroutine the address of
-where to return the value. On these machines, GCC has been configured
-to be compatible with the standard compiler, when this method is used.
-It may not be compatible for structures of 1, 2, 4 or 8 bytes.
-
- GCC uses the system's standard convention for passing arguments. On
-some machines, the first few arguments are passed in registers; in
-others, all are passed on the stack. It would be possible to use
-registers for argument passing on any machine, and this would probably
-result in a significant speedup. But the result would be complete
-incompatibility with code that follows the standard convention. So this
-change is practical only if you are switching to GCC as the sole C
-compiler for the system. We may implement register argument passing on
-certain machines once we have a complete GNU system so that we can
-compile the libraries with GCC.
-
- On some machines (particularly the SPARC), certain types of arguments
-are passed "by invisible reference". This means that the value is
-stored in memory, and the address of the memory location is passed to
-the subroutine.
-
- If you use `longjmp', beware of automatic variables. ISO C says that
-automatic variables that are not declared `volatile' have undefined
-values after a `longjmp'. And this is all GCC promises to do, because
-it is very difficult to restore register variables correctly, and one
-of GCC's features is that it can put variables in registers without
-your asking it to.
-
-
-File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top
-
-4 The GCC low-level runtime library
-***********************************
-
-GCC provides a low-level runtime library, `libgcc.a' or `libgcc_s.so.1'
-on some platforms. GCC generates calls to routines in this library
-automatically, whenever it needs to perform some operation that is too
-complicated to emit inline code for.
-
- Most of the routines in `libgcc' handle arithmetic operations that the
-target processor cannot perform directly. This includes integer
-multiply and divide on some machines, and all floating-point and
-fixed-point operations on other machines. `libgcc' also includes
-routines for exception handling, and a handful of miscellaneous
-operations.
-
- Some of these routines can be defined in mostly machine-independent C.
-Others must be hand-written in assembly language for each processor
-that needs them.
-
- GCC will also generate calls to C library routines, such as `memcpy'
-and `memset', in some cases. The set of routines that GCC may possibly
-use is documented in *note Other Builtins: (gcc)Other Builtins.
-
- These routines take arguments and return values of a specific machine
-mode, not a specific C type. *Note Machine Modes::, for an explanation
-of this concept. For illustrative purposes, in this chapter the
-floating point type `float' is assumed to correspond to `SFmode';
-`double' to `DFmode'; and `long double' to both `TFmode' and `XFmode'.
-Similarly, the integer types `int' and `unsigned int' correspond to
-`SImode'; `long' and `unsigned long' to `DImode'; and `long long' and
-`unsigned long long' to `TImode'.
-
-* Menu:
-
-* Integer library routines::
-* Soft float library routines::
-* Decimal float library routines::
-* Fixed-point fractional library routines::
-* Exception handling routines::
-* Miscellaneous routines::
-
-
-File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc
-
-4.1 Routines for integer arithmetic
-===================================
-
-The integer arithmetic routines are used on platforms that don't provide
-hardware support for arithmetic operations on some modes.
-
-4.1.1 Arithmetic functions
---------------------------
-
- -- Runtime Function: int __ashlsi3 (int A, int B)
- -- Runtime Function: long __ashldi3 (long A, int B)
- -- Runtime Function: long long __ashlti3 (long long A, int B)
- These functions return the result of shifting A left by B bits.
-
- -- Runtime Function: int __ashrsi3 (int A, int B)
- -- Runtime Function: long __ashrdi3 (long A, int B)
- -- Runtime Function: long long __ashrti3 (long long A, int B)
- These functions return the result of arithmetically shifting A
- right by B bits.
-
- -- Runtime Function: int __divsi3 (int A, int B)
- -- Runtime Function: long __divdi3 (long A, long B)
- -- Runtime Function: long long __divti3 (long long A, long long B)
- These functions return the quotient of the signed division of A and
- B.
-
- -- Runtime Function: int __lshrsi3 (int A, int B)
- -- Runtime Function: long __lshrdi3 (long A, int B)
- -- Runtime Function: long long __lshrti3 (long long A, int B)
- These functions return the result of logically shifting A right by
- B bits.
-
- -- Runtime Function: int __modsi3 (int A, int B)
- -- Runtime Function: long __moddi3 (long A, long B)
- -- Runtime Function: long long __modti3 (long long A, long long B)
- These functions return the remainder of the signed division of A
- and B.
-
- -- Runtime Function: int __mulsi3 (int A, int B)
- -- Runtime Function: long __muldi3 (long A, long B)
- -- Runtime Function: long long __multi3 (long long A, long long B)
- These functions return the product of A and B.
-
- -- Runtime Function: long __negdi2 (long A)
- -- Runtime Function: long long __negti2 (long long A)
- These functions return the negation of A.
-
- -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned
- int B)
- -- Runtime Function: unsigned long __udivdi3 (unsigned long A,
- unsigned long B)
- -- Runtime Function: unsigned long long __udivti3 (unsigned long long
- A, unsigned long long B)
- These functions return the quotient of the unsigned division of A
- and B.
-
- -- Runtime Function: unsigned long __udivmoddi3 (unsigned long A,
- unsigned long B, unsigned long *C)
- -- Runtime Function: unsigned long long __udivti3 (unsigned long long
- A, unsigned long long B, unsigned long long *C)
- These functions calculate both the quotient and remainder of the
- unsigned division of A and B. The return value is the quotient,
- and the remainder is placed in variable pointed to by C.
-
- -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned
- int B)
- -- Runtime Function: unsigned long __umoddi3 (unsigned long A,
- unsigned long B)
- -- Runtime Function: unsigned long long __umodti3 (unsigned long long
- A, unsigned long long B)
- These functions return the remainder of the unsigned division of A
- and B.
-
-4.1.2 Comparison functions
---------------------------
-
-The following functions implement integral comparisons. These functions
-implement a low-level compare, upon which the higher level comparison
-operators (such as less than and greater than or equal to) can be
-constructed. The returned values lie in the range zero to two, to allow
-the high-level operators to be implemented by testing the returned
-result using either signed or unsigned comparison.
-
- -- Runtime Function: int __cmpdi2 (long A, long B)
- -- Runtime Function: int __cmpti2 (long long A, long long B)
- These functions perform a signed comparison of A and B. If A is
- less than B, they return 0; if A is greater than B, they return 2;
- and if A and B are equal they return 1.
-
- -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B)
- -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned
- long long B)
- These functions perform an unsigned comparison of A and B. If A
- is less than B, they return 0; if A is greater than B, they return
- 2; and if A and B are equal they return 1.
-
-4.1.3 Trapping arithmetic functions
------------------------------------
-
-The following functions implement trapping arithmetic. These functions
-call the libc function `abort' upon signed arithmetic overflow.
-
- -- Runtime Function: int __absvsi2 (int A)
- -- Runtime Function: long __absvdi2 (long A)
- These functions return the absolute value of A.
-
- -- Runtime Function: int __addvsi3 (int A, int B)
- -- Runtime Function: long __addvdi3 (long A, long B)
- These functions return the sum of A and B; that is `A + B'.
-
- -- Runtime Function: int __mulvsi3 (int A, int B)
- -- Runtime Function: long __mulvdi3 (long A, long B)
- The functions return the product of A and B; that is `A * B'.
-
- -- Runtime Function: int __negvsi2 (int A)
- -- Runtime Function: long __negvdi2 (long A)
- These functions return the negation of A; that is `-A'.
-
- -- Runtime Function: int __subvsi3 (int A, int B)
- -- Runtime Function: long __subvdi3 (long A, long B)
- These functions return the difference between B and A; that is `A
- - B'.
-
-4.1.4 Bit operations
---------------------
-
- -- Runtime Function: int __clzsi2 (int A)
- -- Runtime Function: int __clzdi2 (long A)
- -- Runtime Function: int __clzti2 (long long A)
- These functions return the number of leading 0-bits in A, starting
- at the most significant bit position. If A is zero, the result is
- undefined.
-
- -- Runtime Function: int __ctzsi2 (int A)
- -- Runtime Function: int __ctzdi2 (long A)
- -- Runtime Function: int __ctzti2 (long long A)
- These functions return the number of trailing 0-bits in A, starting
- at the least significant bit position. If A is zero, the result is
- undefined.
-
- -- Runtime Function: int __ffsdi2 (long A)
- -- Runtime Function: int __ffsti2 (long long A)
- These functions return the index of the least significant 1-bit in
- A, or the value zero if A is zero. The least significant bit is
- index one.
-
- -- Runtime Function: int __paritysi2 (int A)
- -- Runtime Function: int __paritydi2 (long A)
- -- Runtime Function: int __parityti2 (long long A)
- These functions return the value zero if the number of bits set in
- A is even, and the value one otherwise.
-
- -- Runtime Function: int __popcountsi2 (int A)
- -- Runtime Function: int __popcountdi2 (long A)
- -- Runtime Function: int __popcountti2 (long long A)
- These functions return the number of bits set in A.
-
- -- Runtime Function: int32_t __bswapsi2 (int32_t A)
- -- Runtime Function: int64_t __bswapdi2 (int64_t A)
- These functions return the A byteswapped.
-
-
-File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc
-
-4.2 Routines for floating point emulation
-=========================================
-
-The software floating point library is used on machines which do not
-have hardware support for floating point. It is also used whenever
-`-msoft-float' is used to disable generation of floating point
-instructions. (Not all targets support this switch.)
-
- For compatibility with other compilers, the floating point emulation
-routines can be renamed with the `DECLARE_LIBRARY_RENAMES' macro (*note
-Library Calls::). In this section, the default names are used.
-
- Presently the library does not support `XFmode', which is used for
-`long double' on some architectures.
-
-4.2.1 Arithmetic functions
---------------------------
-
- -- Runtime Function: float __addsf3 (float A, float B)
- -- Runtime Function: double __adddf3 (double A, double B)
- -- Runtime Function: long double __addtf3 (long double A, long double
- B)
- -- Runtime Function: long double __addxf3 (long double A, long double
- B)
- These functions return the sum of A and B.
-
- -- Runtime Function: float __subsf3 (float A, float B)
- -- Runtime Function: double __subdf3 (double A, double B)
- -- Runtime Function: long double __subtf3 (long double A, long double
- B)
- -- Runtime Function: long double __subxf3 (long double A, long double
- B)
- These functions return the difference between B and A; that is,
- A - B.
-
- -- Runtime Function: float __mulsf3 (float A, float B)
- -- Runtime Function: double __muldf3 (double A, double B)
- -- Runtime Function: long double __multf3 (long double A, long double
- B)
- -- Runtime Function: long double __mulxf3 (long double A, long double
- B)
- These functions return the product of A and B.
-
- -- Runtime Function: float __divsf3 (float A, float B)
- -- Runtime Function: double __divdf3 (double A, double B)
- -- Runtime Function: long double __divtf3 (long double A, long double
- B)
- -- Runtime Function: long double __divxf3 (long double A, long double
- B)
- These functions return the quotient of A and B; that is, A / B.
-
- -- Runtime Function: float __negsf2 (float A)
- -- Runtime Function: double __negdf2 (double A)
- -- Runtime Function: long double __negtf2 (long double A)
- -- Runtime Function: long double __negxf2 (long double A)
- These functions return the negation of A. They simply flip the
- sign bit, so they can produce negative zero and negative NaN.
-
-4.2.2 Conversion functions
---------------------------
-
- -- Runtime Function: double __extendsfdf2 (float A)
- -- Runtime Function: long double __extendsftf2 (float A)
- -- Runtime Function: long double __extendsfxf2 (float A)
- -- Runtime Function: long double __extenddftf2 (double A)
- -- Runtime Function: long double __extenddfxf2 (double A)
- These functions extend A to the wider mode of their return type.
-
- -- Runtime Function: double __truncxfdf2 (long double A)
- -- Runtime Function: double __trunctfdf2 (long double A)
- -- Runtime Function: float __truncxfsf2 (long double A)
- -- Runtime Function: float __trunctfsf2 (long double A)
- -- Runtime Function: float __truncdfsf2 (double A)
- These functions truncate A to the narrower mode of their return
- type, rounding toward zero.
-
- -- Runtime Function: int __fixsfsi (float A)
- -- Runtime Function: int __fixdfsi (double A)
- -- Runtime Function: int __fixtfsi (long double A)
- -- Runtime Function: int __fixxfsi (long double A)
- These functions convert A to a signed integer, rounding toward
- zero.
-
- -- Runtime Function: long __fixsfdi (float A)
- -- Runtime Function: long __fixdfdi (double A)
- -- Runtime Function: long __fixtfdi (long double A)
- -- Runtime Function: long __fixxfdi (long double A)
- These functions convert A to a signed long, rounding toward zero.
-
- -- Runtime Function: long long __fixsfti (float A)
- -- Runtime Function: long long __fixdfti (double A)
- -- Runtime Function: long long __fixtfti (long double A)
- -- Runtime Function: long long __fixxfti (long double A)
- These functions convert A to a signed long long, rounding toward
- zero.
-
- -- Runtime Function: unsigned int __fixunssfsi (float A)
- -- Runtime Function: unsigned int __fixunsdfsi (double A)
- -- Runtime Function: unsigned int __fixunstfsi (long double A)
- -- Runtime Function: unsigned int __fixunsxfsi (long double A)
- These functions convert A to an unsigned integer, rounding toward
- zero. Negative values all become zero.
-
- -- Runtime Function: unsigned long __fixunssfdi (float A)
- -- Runtime Function: unsigned long __fixunsdfdi (double A)
- -- Runtime Function: unsigned long __fixunstfdi (long double A)
- -- Runtime Function: unsigned long __fixunsxfdi (long double A)
- These functions convert A to an unsigned long, rounding toward
- zero. Negative values all become zero.
-
- -- Runtime Function: unsigned long long __fixunssfti (float A)
- -- Runtime Function: unsigned long long __fixunsdfti (double A)
- -- Runtime Function: unsigned long long __fixunstfti (long double A)
- -- Runtime Function: unsigned long long __fixunsxfti (long double A)
- These functions convert A to an unsigned long long, rounding
- toward zero. Negative values all become zero.
-
- -- Runtime Function: float __floatsisf (int I)
- -- Runtime Function: double __floatsidf (int I)
- -- Runtime Function: long double __floatsitf (int I)
- -- Runtime Function: long double __floatsixf (int I)
- These functions convert I, a signed integer, to floating point.
-
- -- Runtime Function: float __floatdisf (long I)
- -- Runtime Function: double __floatdidf (long I)
- -- Runtime Function: long double __floatditf (long I)
- -- Runtime Function: long double __floatdixf (long I)
- These functions convert I, a signed long, to floating point.
-
- -- Runtime Function: float __floattisf (long long I)
- -- Runtime Function: double __floattidf (long long I)
- -- Runtime Function: long double __floattitf (long long I)
- -- Runtime Function: long double __floattixf (long long I)
- These functions convert I, a signed long long, to floating point.
-
- -- Runtime Function: float __floatunsisf (unsigned int I)
- -- Runtime Function: double __floatunsidf (unsigned int I)
- -- Runtime Function: long double __floatunsitf (unsigned int I)
- -- Runtime Function: long double __floatunsixf (unsigned int I)
- These functions convert I, an unsigned integer, to floating point.
-
- -- Runtime Function: float __floatundisf (unsigned long I)
- -- Runtime Function: double __floatundidf (unsigned long I)
- -- Runtime Function: long double __floatunditf (unsigned long I)
- -- Runtime Function: long double __floatundixf (unsigned long I)
- These functions convert I, an unsigned long, to floating point.
-
- -- Runtime Function: float __floatuntisf (unsigned long long I)
- -- Runtime Function: double __floatuntidf (unsigned long long I)
- -- Runtime Function: long double __floatuntitf (unsigned long long I)
- -- Runtime Function: long double __floatuntixf (unsigned long long I)
- These functions convert I, an unsigned long long, to floating
- point.
-
-4.2.3 Comparison functions
---------------------------
-
-There are two sets of basic comparison functions.
-
- -- Runtime Function: int __cmpsf2 (float A, float B)
- -- Runtime Function: int __cmpdf2 (double A, double B)
- -- Runtime Function: int __cmptf2 (long double A, long double B)
- These functions calculate a <=> b. That is, if A is less than B,
- they return -1; if A is greater than B, they return 1; and if A
- and B are equal they return 0. If either argument is NaN they
- return 1, but you should not rely on this; if NaN is a
- possibility, use one of the higher-level comparison functions.
-
- -- Runtime Function: int __unordsf2 (float A, float B)
- -- Runtime Function: int __unorddf2 (double A, double B)
- -- Runtime Function: int __unordtf2 (long double A, long double B)
- These functions return a nonzero value if either argument is NaN,
- otherwise 0.
-
- There is also a complete group of higher level functions which
-correspond directly to comparison operators. They implement the ISO C
-semantics for floating-point comparisons, taking NaN into account. Pay
-careful attention to the return values defined for each set. Under the
-hood, all of these routines are implemented as
-
- if (__unordXf2 (a, b))
- return E;
- return __cmpXf2 (a, b);
-
-where E is a constant chosen to give the proper behavior for NaN.
-Thus, the meaning of the return value is different for each set. Do
-not rely on this implementation; only the semantics documented below
-are guaranteed.
-
- -- Runtime Function: int __eqsf2 (float A, float B)
- -- Runtime Function: int __eqdf2 (double A, double B)
- -- Runtime Function: int __eqtf2 (long double A, long double B)
- These functions return zero if neither argument is NaN, and A and
- B are equal.
-
- -- Runtime Function: int __nesf2 (float A, float B)
- -- Runtime Function: int __nedf2 (double A, double B)
- -- Runtime Function: int __netf2 (long double A, long double B)
- These functions return a nonzero value if either argument is NaN,
- or if A and B are unequal.
-
- -- Runtime Function: int __gesf2 (float A, float B)
- -- Runtime Function: int __gedf2 (double A, double B)
- -- Runtime Function: int __getf2 (long double A, long double B)
- These functions return a value greater than or equal to zero if
- neither argument is NaN, and A is greater than or equal to B.
-
- -- Runtime Function: int __ltsf2 (float A, float B)
- -- Runtime Function: int __ltdf2 (double A, double B)
- -- Runtime Function: int __lttf2 (long double A, long double B)
- These functions return a value less than zero if neither argument
- is NaN, and A is strictly less than B.
-
- -- Runtime Function: int __lesf2 (float A, float B)
- -- Runtime Function: int __ledf2 (double A, double B)
- -- Runtime Function: int __letf2 (long double A, long double B)
- These functions return a value less than or equal to zero if
- neither argument is NaN, and A is less than or equal to B.
-
- -- Runtime Function: int __gtsf2 (float A, float B)
- -- Runtime Function: int __gtdf2 (double A, double B)
- -- Runtime Function: int __gttf2 (long double A, long double B)
- These functions return a value greater than zero if neither
- argument is NaN, and A is strictly greater than B.
-
-4.2.4 Other floating-point functions
-------------------------------------
-
- -- Runtime Function: float __powisf2 (float A, int B)
- -- Runtime Function: double __powidf2 (double A, int B)
- -- Runtime Function: long double __powitf2 (long double A, int B)
- -- Runtime Function: long double __powixf2 (long double A, int B)
- These functions convert raise A to the power B.
-
- -- Runtime Function: complex float __mulsc3 (float A, float B, float
- C, float D)
- -- Runtime Function: complex double __muldc3 (double A, double B,
- double C, double D)
- -- Runtime Function: complex long double __multc3 (long double A, long
- double B, long double C, long double D)
- -- Runtime Function: complex long double __mulxc3 (long double A, long
- double B, long double C, long double D)
- These functions return the product of A + iB and C + iD, following
- the rules of C99 Annex G.
-
- -- Runtime Function: complex float __divsc3 (float A, float B, float
- C, float D)
- -- Runtime Function: complex double __divdc3 (double A, double B,
- double C, double D)
- -- Runtime Function: complex long double __divtc3 (long double A, long
- double B, long double C, long double D)
- -- Runtime Function: complex long double __divxc3 (long double A, long
- double B, long double C, long double D)
- These functions return the quotient of A + iB and C + iD (i.e., (A
- + iB) / (C + iD)), following the rules of C99 Annex G.
-
-
-File: gccint.info, Node: Decimal float library routines, Next: Fixed-point fractional library routines, Prev: Soft float library routines, Up: Libgcc
-
-4.3 Routines for decimal floating point emulation
-=================================================
-
-The software decimal floating point library implements IEEE 754-2008
-decimal floating point arithmetic and is only activated on selected
-targets.
-
- The software decimal floating point library supports either DPD
-(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as
-selected at configure time.
-
-4.3.1 Arithmetic functions
---------------------------
-
- -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32
- B)
- -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32
- B)
- -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64
- B)
- -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64
- B)
- -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A,
- _Decimal128 B)
- -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A,
- _Decimal128 B)
- These functions return the sum of A and B.
-
- -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32
- B)
- -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32
- B)
- -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64
- B)
- -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64
- B)
- -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A,
- _Decimal128 B)
- -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A,
- _Decimal128 B)
- These functions return the difference between B and A; that is,
- A - B.
-
- -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32
- B)
- -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32
- B)
- -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64
- B)
- -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64
- B)
- -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A,
- _Decimal128 B)
- -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A,
- _Decimal128 B)
- These functions return the product of A and B.
-
- -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32
- B)
- -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32
- B)
- -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64
- B)
- -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64
- B)
- -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A,
- _Decimal128 B)
- -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A,
- _Decimal128 B)
- These functions return the quotient of A and B; that is, A / B.
-
- -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A)
- -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A)
- -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A)
- -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A)
- -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A)
- -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A)
- These functions return the negation of A. They simply flip the
- sign bit, so they can produce negative zero and negative NaN.
-
-4.3.2 Conversion functions
---------------------------
-
- -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A)
- -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A)
- -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A)
- -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A)
- -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A)
- -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A)
- -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A)
- -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A)
- -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A)
- -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A)
- -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A)
- -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A)
- These functions convert the value A from one decimal floating type
- to another.
-
- -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A)
- -- Runtime Function: _Decimal64 __bid_extendsfdd (float A)
- -- Runtime Function: _Decimal128 __dpd_extendsftd (float A)
- -- Runtime Function: _Decimal128 __bid_extendsftd (float A)
- -- Runtime Function: _Decimal128 __dpd_extenddftd (double A)
- -- Runtime Function: _Decimal128 __bid_extenddftd (double A)
- -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A)
- -- Runtime Function: _Decimal128 __bid_extendxftd (long double A)
- -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A)
- -- Runtime Function: _Decimal32 __bid_truncdfsd (double A)
- -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A)
- -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A)
- -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A)
- -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A)
- -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A)
- -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A)
- -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A)
- -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A)
- These functions convert the value of A from a binary floating type
- to a decimal floating type of a different size.
-
- -- Runtime Function: float __dpd_truncddsf (_Decimal64 A)
- -- Runtime Function: float __bid_truncddsf (_Decimal64 A)
- -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A)
- -- Runtime Function: float __bid_trunctdsf (_Decimal128 A)
- -- Runtime Function: double __dpd_extendsddf (_Decimal32 A)
- -- Runtime Function: double __bid_extendsddf (_Decimal32 A)
- -- Runtime Function: double __dpd_trunctddf (_Decimal128 A)
- -- Runtime Function: double __bid_trunctddf (_Decimal128 A)
- -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A)
- -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A)
- -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A)
- -- Runtime Function: long double __bid_extendddxf (_Decimal64 A)
- -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A)
- -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A)
- -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A)
- -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A)
- -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A)
- -- Runtime Function: long double __bid_extendddtf (_Decimal64 A)
- These functions convert the value of A from a decimal floating type
- to a binary floating type of a different size.
-
- -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A)
- -- Runtime Function: _Decimal32 __bid_extendsfsd (float A)
- -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A)
- -- Runtime Function: _Decimal64 __bid_extenddfdd (double A)
- -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A)
- -- Runtime Function: _Decimal128 __bid_extendtftd (long double A)
- -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A)
- -- Runtime Function: float __bid_truncsdsf (_Decimal32 A)
- -- Runtime Function: double __dpd_truncdddf (_Decimal64 A)
- -- Runtime Function: double __bid_truncdddf (_Decimal64 A)
- -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A)
- -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A)
- These functions convert the value of A between decimal and binary
- floating types of the same size.
-
- -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A)
- -- Runtime Function: int __bid_fixsdsi (_Decimal32 A)
- -- Runtime Function: int __dpd_fixddsi (_Decimal64 A)
- -- Runtime Function: int __bid_fixddsi (_Decimal64 A)
- -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A)
- -- Runtime Function: int __bid_fixtdsi (_Decimal128 A)
- These functions convert A to a signed integer.
-
- -- Runtime Function: long __dpd_fixsddi (_Decimal32 A)
- -- Runtime Function: long __bid_fixsddi (_Decimal32 A)
- -- Runtime Function: long __dpd_fixdddi (_Decimal64 A)
- -- Runtime Function: long __bid_fixdddi (_Decimal64 A)
- -- Runtime Function: long __dpd_fixtddi (_Decimal128 A)
- -- Runtime Function: long __bid_fixtddi (_Decimal128 A)
- These functions convert A to a signed long.
-
- -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A)
- -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A)
- -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A)
- -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A)
- -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A)
- -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A)
- These functions convert A to an unsigned integer. Negative values
- all become zero.
-
- -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A)
- -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A)
- -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A)
- -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A)
- -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A)
- -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A)
- These functions convert A to an unsigned long. Negative values
- all become zero.
-
- -- Runtime Function: _Decimal32 __dpd_floatsisd (int I)
- -- Runtime Function: _Decimal32 __bid_floatsisd (int I)
- -- Runtime Function: _Decimal64 __dpd_floatsidd (int I)
- -- Runtime Function: _Decimal64 __bid_floatsidd (int I)
- -- Runtime Function: _Decimal128 __dpd_floatsitd (int I)
- -- Runtime Function: _Decimal128 __bid_floatsitd (int I)
- These functions convert I, a signed integer, to decimal floating
- point.
-
- -- Runtime Function: _Decimal32 __dpd_floatdisd (long I)
- -- Runtime Function: _Decimal32 __bid_floatdisd (long I)
- -- Runtime Function: _Decimal64 __dpd_floatdidd (long I)
- -- Runtime Function: _Decimal64 __bid_floatdidd (long I)
- -- Runtime Function: _Decimal128 __dpd_floatditd (long I)
- -- Runtime Function: _Decimal128 __bid_floatditd (long I)
- These functions convert I, a signed long, to decimal floating
- point.
-
- -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I)
- -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I)
- -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I)
- -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I)
- -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I)
- -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I)
- These functions convert I, an unsigned integer, to decimal
- floating point.
-
- -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I)
- -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I)
- -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I)
- -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I)
- -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I)
- -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I)
- These functions convert I, an unsigned long, to decimal floating
- point.
-
-4.3.3 Comparison functions
---------------------------
-
- -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B)
- -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B)
- These functions return a nonzero value if either argument is NaN,
- otherwise 0.
-
- There is also a complete group of higher level functions which
-correspond directly to comparison operators. They implement the ISO C
-semantics for floating-point comparisons, taking NaN into account. Pay
-careful attention to the return values defined for each set. Under the
-hood, all of these routines are implemented as
-
- if (__bid_unordXd2 (a, b))
- return E;
- return __bid_cmpXd2 (a, b);
-
-where E is a constant chosen to give the proper behavior for NaN.
-Thus, the meaning of the return value is different for each set. Do
-not rely on this implementation; only the semantics documented below
-are guaranteed.
-
- -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B)
- -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B)
- These functions return zero if neither argument is NaN, and A and
- B are equal.
-
- -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B)
- -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B)
- These functions return a nonzero value if either argument is NaN,
- or if A and B are unequal.
-
- -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B)
- -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B)
- These functions return a value greater than or equal to zero if
- neither argument is NaN, and A is greater than or equal to B.
-
- -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B)
- -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B)
- These functions return a value less than zero if neither argument
- is NaN, and A is strictly less than B.
-
- -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B)
- -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B)
- These functions return a value less than or equal to zero if
- neither argument is NaN, and A is less than or equal to B.
-
- -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B)
- -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B)
- -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B)
- -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B)
- These functions return a value greater than zero if neither
- argument is NaN, and A is strictly greater than B.
-
-
-File: gccint.info, Node: Fixed-point fractional library routines, Next: Exception handling routines, Prev: Decimal float library routines, Up: Libgcc
-
-4.4 Routines for fixed-point fractional emulation
-=================================================
-
-The software fixed-point library implements fixed-point fractional
-arithmetic, and is only activated on selected targets.
-
- For ease of comprehension `fract' is an alias for the `_Fract' type,
-`accum' an alias for `_Accum', and `sat' an alias for `_Sat'.
-
- For illustrative purposes, in this section the fixed-point fractional
-type `short fract' is assumed to correspond to machine mode `QQmode';
-`unsigned short fract' to `UQQmode'; `fract' to `HQmode';
-`unsigned fract' to `UHQmode'; `long fract' to `SQmode';
-`unsigned long fract' to `USQmode'; `long long fract' to `DQmode'; and
-`unsigned long long fract' to `UDQmode'. Similarly the fixed-point
-accumulator type `short accum' corresponds to `HAmode';
-`unsigned short accum' to `UHAmode'; `accum' to `SAmode';
-`unsigned accum' to `USAmode'; `long accum' to `DAmode';
-`unsigned long accum' to `UDAmode'; `long long accum' to `TAmode'; and
-`unsigned long long accum' to `UTAmode'.
-
-4.4.1 Arithmetic functions
---------------------------
-
- -- Runtime Function: short fract __addqq3 (short fract A, short fract
- B)
- -- Runtime Function: fract __addhq3 (fract A, fract B)
- -- Runtime Function: long fract __addsq3 (long fract A, long fract B)
- -- Runtime Function: long long fract __adddq3 (long long fract A, long
- long fract B)
- -- Runtime Function: unsigned short fract __adduqq3 (unsigned short
- fract A, unsigned short fract B)
- -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A,
- unsigned fract B)
- -- Runtime Function: unsigned long fract __addusq3 (unsigned long
- fract A, unsigned long fract B)
- -- Runtime Function: unsigned long long fract __addudq3 (unsigned long
- long fract A, unsigned long long fract B)
- -- Runtime Function: short accum __addha3 (short accum A, short accum
- B)
- -- Runtime Function: accum __addsa3 (accum A, accum B)
- -- Runtime Function: long accum __addda3 (long accum A, long accum B)
- -- Runtime Function: long long accum __addta3 (long long accum A, long
- long accum B)
- -- Runtime Function: unsigned short accum __adduha3 (unsigned short
- accum A, unsigned short accum B)
- -- Runtime Function: unsigned accum __addusa3 (unsigned accum A,
- unsigned accum B)
- -- Runtime Function: unsigned long accum __adduda3 (unsigned long
- accum A, unsigned long accum B)
- -- Runtime Function: unsigned long long accum __adduta3 (unsigned long
- long accum A, unsigned long long accum B)
- These functions return the sum of A and B.
-
- -- Runtime Function: short fract __ssaddqq3 (short fract A, short
- fract B)
- -- Runtime Function: fract __ssaddhq3 (fract A, fract B)
- -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B)
- -- Runtime Function: long long fract __ssadddq3 (long long fract A,
- long long fract B)
- -- Runtime Function: short accum __ssaddha3 (short accum A, short
- accum B)
- -- Runtime Function: accum __ssaddsa3 (accum A, accum B)
- -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B)
- -- Runtime Function: long long accum __ssaddta3 (long long accum A,
- long long accum B)
- These functions return the sum of A and B with signed saturation.
-
- -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short
- fract A, unsigned short fract B)
- -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A,
- unsigned fract B)
- -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long
- fract A, unsigned long fract B)
- -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned
- long long fract A, unsigned long long fract B)
- -- Runtime Function: unsigned short accum __usadduha3 (unsigned short
- accum A, unsigned short accum B)
- -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A,
- unsigned accum B)
- -- Runtime Function: unsigned long accum __usadduda3 (unsigned long
- accum A, unsigned long accum B)
- -- Runtime Function: unsigned long long accum __usadduta3 (unsigned
- long long accum A, unsigned long long accum B)
- These functions return the sum of A and B with unsigned saturation.
-
- -- Runtime Function: short fract __subqq3 (short fract A, short fract
- B)
- -- Runtime Function: fract __subhq3 (fract A, fract B)
- -- Runtime Function: long fract __subsq3 (long fract A, long fract B)
- -- Runtime Function: long long fract __subdq3 (long long fract A, long
- long fract B)
- -- Runtime Function: unsigned short fract __subuqq3 (unsigned short
- fract A, unsigned short fract B)
- -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A,
- unsigned fract B)
- -- Runtime Function: unsigned long fract __subusq3 (unsigned long
- fract A, unsigned long fract B)
- -- Runtime Function: unsigned long long fract __subudq3 (unsigned long
- long fract A, unsigned long long fract B)
- -- Runtime Function: short accum __subha3 (short accum A, short accum
- B)
- -- Runtime Function: accum __subsa3 (accum A, accum B)
- -- Runtime Function: long accum __subda3 (long accum A, long accum B)
- -- Runtime Function: long long accum __subta3 (long long accum A, long
- long accum B)
- -- Runtime Function: unsigned short accum __subuha3 (unsigned short
- accum A, unsigned short accum B)
- -- Runtime Function: unsigned accum __subusa3 (unsigned accum A,
- unsigned accum B)
- -- Runtime Function: unsigned long accum __subuda3 (unsigned long
- accum A, unsigned long accum B)
- -- Runtime Function: unsigned long long accum __subuta3 (unsigned long
- long accum A, unsigned long long accum B)
- These functions return the difference of A and B; that is, `A - B'.
-
- -- Runtime Function: short fract __sssubqq3 (short fract A, short
- fract B)
- -- Runtime Function: fract __sssubhq3 (fract A, fract B)
- -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B)
- -- Runtime Function: long long fract __sssubdq3 (long long fract A,
- long long fract B)
- -- Runtime Function: short accum __sssubha3 (short accum A, short
- accum B)
- -- Runtime Function: accum __sssubsa3 (accum A, accum B)
- -- Runtime Function: long accum __sssubda3 (long accum A, long accum B)
- -- Runtime Function: long long accum __sssubta3 (long long accum A,
- long long accum B)
- These functions return the difference of A and B with signed
- saturation; that is, `A - B'.
-
- -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short
- fract A, unsigned short fract B)
- -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A,
- unsigned fract B)
- -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long
- fract A, unsigned long fract B)
- -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned
- long long fract A, unsigned long long fract B)
- -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short
- accum A, unsigned short accum B)
- -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A,
- unsigned accum B)
- -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long
- accum A, unsigned long accum B)
- -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned
- long long accum A, unsigned long long accum B)
- These functions return the difference of A and B with unsigned
- saturation; that is, `A - B'.
-
- -- Runtime Function: short fract __mulqq3 (short fract A, short fract
- B)
- -- Runtime Function: fract __mulhq3 (fract A, fract B)
- -- Runtime Function: long fract __mulsq3 (long fract A, long fract B)
- -- Runtime Function: long long fract __muldq3 (long long fract A, long
- long fract B)
- -- Runtime Function: unsigned short fract __muluqq3 (unsigned short
- fract A, unsigned short fract B)
- -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A,
- unsigned fract B)
- -- Runtime Function: unsigned long fract __mulusq3 (unsigned long
- fract A, unsigned long fract B)
- -- Runtime Function: unsigned long long fract __muludq3 (unsigned long
- long fract A, unsigned long long fract B)
- -- Runtime Function: short accum __mulha3 (short accum A, short accum
- B)
- -- Runtime Function: accum __mulsa3 (accum A, accum B)
- -- Runtime Function: long accum __mulda3 (long accum A, long accum B)
- -- Runtime Function: long long accum __multa3 (long long accum A, long
- long accum B)
- -- Runtime Function: unsigned short accum __muluha3 (unsigned short
- accum A, unsigned short accum B)
- -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A,
- unsigned accum B)
- -- Runtime Function: unsigned long accum __muluda3 (unsigned long
- accum A, unsigned long accum B)
- -- Runtime Function: unsigned long long accum __muluta3 (unsigned long
- long accum A, unsigned long long accum B)
- These functions return the product of A and B.
-
- -- Runtime Function: short fract __ssmulqq3 (short fract A, short
- fract B)
- -- Runtime Function: fract __ssmulhq3 (fract A, fract B)
- -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B)
- -- Runtime Function: long long fract __ssmuldq3 (long long fract A,
- long long fract B)
- -- Runtime Function: short accum __ssmulha3 (short accum A, short
- accum B)
- -- Runtime Function: accum __ssmulsa3 (accum A, accum B)
- -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B)
- -- Runtime Function: long long accum __ssmulta3 (long long accum A,
- long long accum B)
- These functions return the product of A and B with signed
- saturation.
-
- -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short
- fract A, unsigned short fract B)
- -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A,
- unsigned fract B)
- -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long
- fract A, unsigned long fract B)
- -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned
- long long fract A, unsigned long long fract B)
- -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short
- accum A, unsigned short accum B)
- -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A,
- unsigned accum B)
- -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long
- accum A, unsigned long accum B)
- -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned
- long long accum A, unsigned long long accum B)
- These functions return the product of A and B with unsigned
- saturation.
-
- -- Runtime Function: short fract __divqq3 (short fract A, short fract
- B)
- -- Runtime Function: fract __divhq3 (fract A, fract B)
- -- Runtime Function: long fract __divsq3 (long fract A, long fract B)
- -- Runtime Function: long long fract __divdq3 (long long fract A, long
- long fract B)
- -- Runtime Function: short accum __divha3 (short accum A, short accum
- B)
- -- Runtime Function: accum __divsa3 (accum A, accum B)
- -- Runtime Function: long accum __divda3 (long accum A, long accum B)
- -- Runtime Function: long long accum __divta3 (long long accum A, long
- long accum B)
- These functions return the quotient of the signed division of A
- and B.
-
- -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short
- fract A, unsigned short fract B)
- -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A,
- unsigned fract B)
- -- Runtime Function: unsigned long fract __udivusq3 (unsigned long
- fract A, unsigned long fract B)
- -- Runtime Function: unsigned long long fract __udivudq3 (unsigned
- long long fract A, unsigned long long fract B)
- -- Runtime Function: unsigned short accum __udivuha3 (unsigned short
- accum A, unsigned short accum B)
- -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A,
- unsigned accum B)
- -- Runtime Function: unsigned long accum __udivuda3 (unsigned long
- accum A, unsigned long accum B)
- -- Runtime Function: unsigned long long accum __udivuta3 (unsigned
- long long accum A, unsigned long long accum B)
- These functions return the quotient of the unsigned division of A
- and B.
-
- -- Runtime Function: short fract __ssdivqq3 (short fract A, short
- fract B)
- -- Runtime Function: fract __ssdivhq3 (fract A, fract B)
- -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B)
- -- Runtime Function: long long fract __ssdivdq3 (long long fract A,
- long long fract B)
- -- Runtime Function: short accum __ssdivha3 (short accum A, short
- accum B)
- -- Runtime Function: accum __ssdivsa3 (accum A, accum B)
- -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B)
- -- Runtime Function: long long accum __ssdivta3 (long long accum A,
- long long accum B)
- These functions return the quotient of the signed division of A
- and B with signed saturation.
-
- -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short
- fract A, unsigned short fract B)
- -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A,
- unsigned fract B)
- -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long
- fract A, unsigned long fract B)
- -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned
- long long fract A, unsigned long long fract B)
- -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short
- accum A, unsigned short accum B)
- -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A,
- unsigned accum B)
- -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long
- accum A, unsigned long accum B)
- -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned
- long long accum A, unsigned long long accum B)
- These functions return the quotient of the unsigned division of A
- and B with unsigned saturation.
-
- -- Runtime Function: short fract __negqq2 (short fract A)
- -- Runtime Function: fract __neghq2 (fract A)
- -- Runtime Function: long fract __negsq2 (long fract A)
- -- Runtime Function: long long fract __negdq2 (long long fract A)
- -- Runtime Function: unsigned short fract __neguqq2 (unsigned short
- fract A)
- -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A)
- -- Runtime Function: unsigned long fract __negusq2 (unsigned long
- fract A)
- -- Runtime Function: unsigned long long fract __negudq2 (unsigned long
- long fract A)
- -- Runtime Function: short accum __negha2 (short accum A)
- -- Runtime Function: accum __negsa2 (accum A)
- -- Runtime Function: long accum __negda2 (long accum A)
- -- Runtime Function: long long accum __negta2 (long long accum A)
- -- Runtime Function: unsigned short accum __neguha2 (unsigned short
- accum A)
- -- Runtime Function: unsigned accum __negusa2 (unsigned accum A)
- -- Runtime Function: unsigned long accum __neguda2 (unsigned long
- accum A)
- -- Runtime Function: unsigned long long accum __neguta2 (unsigned long
- long accum A)
- These functions return the negation of A.
-
- -- Runtime Function: short fract __ssnegqq2 (short fract A)
- -- Runtime Function: fract __ssneghq2 (fract A)
- -- Runtime Function: long fract __ssnegsq2 (long fract A)
- -- Runtime Function: long long fract __ssnegdq2 (long long fract A)
- -- Runtime Function: short accum __ssnegha2 (short accum A)
- -- Runtime Function: accum __ssnegsa2 (accum A)
- -- Runtime Function: long accum __ssnegda2 (long accum A)
- -- Runtime Function: long long accum __ssnegta2 (long long accum A)
- These functions return the negation of A with signed saturation.
-
- -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short
- fract A)
- -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A)
- -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long
- fract A)
- -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned
- long long fract A)
- -- Runtime Function: unsigned short accum __usneguha2 (unsigned short
- accum A)
- -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A)
- -- Runtime Function: unsigned long accum __usneguda2 (unsigned long
- accum A)
- -- Runtime Function: unsigned long long accum __usneguta2 (unsigned
- long long accum A)
- These functions return the negation of A with unsigned saturation.
-
- -- Runtime Function: short fract __ashlqq3 (short fract A, int B)
- -- Runtime Function: fract __ashlhq3 (fract A, int B)
- -- Runtime Function: long fract __ashlsq3 (long fract A, int B)
- -- Runtime Function: long long fract __ashldq3 (long long fract A, int
- B)
- -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short
- fract A, int B)
- -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int
- B)
- -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long
- fract A, int B)
- -- Runtime Function: unsigned long long fract __ashludq3 (unsigned
- long long fract A, int B)
- -- Runtime Function: short accum __ashlha3 (short accum A, int B)
- -- Runtime Function: accum __ashlsa3 (accum A, int B)
- -- Runtime Function: long accum __ashlda3 (long accum A, int B)
- -- Runtime Function: long long accum __ashlta3 (long long accum A, int
- B)
- -- Runtime Function: unsigned short accum __ashluha3 (unsigned short
- accum A, int B)
- -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int
- B)
- -- Runtime Function: unsigned long accum __ashluda3 (unsigned long
- accum A, int B)
- -- Runtime Function: unsigned long long accum __ashluta3 (unsigned
- long long accum A, int B)
- These functions return the result of shifting A left by B bits.
-
- -- Runtime Function: short fract __ashrqq3 (short fract A, int B)
- -- Runtime Function: fract __ashrhq3 (fract A, int B)
- -- Runtime Function: long fract __ashrsq3 (long fract A, int B)
- -- Runtime Function: long long fract __ashrdq3 (long long fract A, int
- B)
- -- Runtime Function: short accum __ashrha3 (short accum A, int B)
- -- Runtime Function: accum __ashrsa3 (accum A, int B)
- -- Runtime Function: long accum __ashrda3 (long accum A, int B)
- -- Runtime Function: long long accum __ashrta3 (long long accum A, int
- B)
- These functions return the result of arithmetically shifting A
- right by B bits.
-
- -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short
- fract A, int B)
- -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int
- B)
- -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long
- fract A, int B)
- -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned
- long long fract A, int B)
- -- Runtime Function: unsigned short accum __lshruha3 (unsigned short
- accum A, int B)
- -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int
- B)
- -- Runtime Function: unsigned long accum __lshruda3 (unsigned long
- accum A, int B)
- -- Runtime Function: unsigned long long accum __lshruta3 (unsigned
- long long accum A, int B)
- These functions return the result of logically shifting A right by
- B bits.
-
- -- Runtime Function: fract __ssashlhq3 (fract A, int B)
- -- Runtime Function: long fract __ssashlsq3 (long fract A, int B)
- -- Runtime Function: long long fract __ssashldq3 (long long fract A,
- int B)
- -- Runtime Function: short accum __ssashlha3 (short accum A, int B)
- -- Runtime Function: accum __ssashlsa3 (accum A, int B)
- -- Runtime Function: long accum __ssashlda3 (long accum A, int B)
- -- Runtime Function: long long accum __ssashlta3 (long long accum A,
- int B)
- These functions return the result of shifting A left by B bits
- with signed saturation.
-
- -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short
- fract A, int B)
- -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A,
- int B)
- -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long
- fract A, int B)
- -- Runtime Function: unsigned long long fract __usashludq3 (unsigned
- long long fract A, int B)
- -- Runtime Function: unsigned short accum __usashluha3 (unsigned short
- accum A, int B)
- -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A,
- int B)
- -- Runtime Function: unsigned long accum __usashluda3 (unsigned long
- accum A, int B)
- -- Runtime Function: unsigned long long accum __usashluta3 (unsigned
- long long accum A, int B)
- These functions return the result of shifting A left by B bits
- with unsigned saturation.
-
-4.4.2 Comparison functions
---------------------------
-
-The following functions implement fixed-point comparisons. These
-functions implement a low-level compare, upon which the higher level
-comparison operators (such as less than and greater than or equal to)
-can be constructed. The returned values lie in the range zero to two,
-to allow the high-level operators to be implemented by testing the
-returned result using either signed or unsigned comparison.
-
- -- Runtime Function: int __cmpqq2 (short fract A, short fract B)
- -- Runtime Function: int __cmphq2 (fract A, fract B)
- -- Runtime Function: int __cmpsq2 (long fract A, long fract B)
- -- Runtime Function: int __cmpdq2 (long long fract A, long long fract
- B)
- -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned
- short fract B)
- -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B)
- -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned
- long fract B)
- -- Runtime Function: int __cmpudq2 (unsigned long long fract A,
- unsigned long long fract B)
- -- Runtime Function: int __cmpha2 (short accum A, short accum B)
- -- Runtime Function: int __cmpsa2 (accum A, accum B)
- -- Runtime Function: int __cmpda2 (long accum A, long accum B)
- -- Runtime Function: int __cmpta2 (long long accum A, long long accum
- B)
- -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned
- short accum B)
- -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B)
- -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned
- long accum B)
- -- Runtime Function: int __cmputa2 (unsigned long long accum A,
- unsigned long long accum B)
- These functions perform a signed or unsigned comparison of A and B
- (depending on the selected machine mode). If A is less than B,
- they return 0; if A is greater than B, they return 2; and if A and
- B are equal they return 1.
-
-4.4.3 Conversion functions
---------------------------
-
- -- Runtime Function: fract __fractqqhq2 (short fract A)
- -- Runtime Function: long fract __fractqqsq2 (short fract A)
- -- Runtime Function: long long fract __fractqqdq2 (short fract A)
- -- Runtime Function: short accum __fractqqha (short fract A)
- -- Runtime Function: accum __fractqqsa (short fract A)
- -- Runtime Function: long accum __fractqqda (short fract A)
- -- Runtime Function: long long accum __fractqqta (short fract A)
- -- Runtime Function: unsigned short fract __fractqquqq (short fract A)
- -- Runtime Function: unsigned fract __fractqquhq (short fract A)
- -- Runtime Function: unsigned long fract __fractqqusq (short fract A)
- -- Runtime Function: unsigned long long fract __fractqqudq (short
- fract A)
- -- Runtime Function: unsigned short accum __fractqquha (short fract A)
- -- Runtime Function: unsigned accum __fractqqusa (short fract A)
- -- Runtime Function: unsigned long accum __fractqquda (short fract A)
- -- Runtime Function: unsigned long long accum __fractqquta (short
- fract A)
- -- Runtime Function: signed char __fractqqqi (short fract A)
- -- Runtime Function: short __fractqqhi (short fract A)
- -- Runtime Function: int __fractqqsi (short fract A)
- -- Runtime Function: long __fractqqdi (short fract A)
- -- Runtime Function: long long __fractqqti (short fract A)
- -- Runtime Function: float __fractqqsf (short fract A)
- -- Runtime Function: double __fractqqdf (short fract A)
- -- Runtime Function: short fract __fracthqqq2 (fract A)
- -- Runtime Function: long fract __fracthqsq2 (fract A)
- -- Runtime Function: long long fract __fracthqdq2 (fract A)
- -- Runtime Function: short accum __fracthqha (fract A)
- -- Runtime Function: accum __fracthqsa (fract A)
- -- Runtime Function: long accum __fracthqda (fract A)
- -- Runtime Function: long long accum __fracthqta (fract A)
- -- Runtime Function: unsigned short fract __fracthquqq (fract A)
- -- Runtime Function: unsigned fract __fracthquhq (fract A)
- -- Runtime Function: unsigned long fract __fracthqusq (fract A)
- -- Runtime Function: unsigned long long fract __fracthqudq (fract A)
- -- Runtime Function: unsigned short accum __fracthquha (fract A)
- -- Runtime Function: unsigned accum __fracthqusa (fract A)
- -- Runtime Function: unsigned long accum __fracthquda (fract A)
- -- Runtime Function: unsigned long long accum __fracthquta (fract A)
- -- Runtime Function: signed char __fracthqqi (fract A)
- -- Runtime Function: short __fracthqhi (fract A)
- -- Runtime Function: int __fracthqsi (fract A)
- -- Runtime Function: long __fracthqdi (fract A)
- -- Runtime Function: long long __fracthqti (fract A)
- -- Runtime Function: float __fracthqsf (fract A)
- -- Runtime Function: double __fracthqdf (fract A)
- -- Runtime Function: short fract __fractsqqq2 (long fract A)
- -- Runtime Function: fract __fractsqhq2 (long fract A)
- -- Runtime Function: long long fract __fractsqdq2 (long fract A)
- -- Runtime Function: short accum __fractsqha (long fract A)
- -- Runtime Function: accum __fractsqsa (long fract A)
- -- Runtime Function: long accum __fractsqda (long fract A)
- -- Runtime Function: long long accum __fractsqta (long fract A)
- -- Runtime Function: unsigned short fract __fractsquqq (long fract A)
- -- Runtime Function: unsigned fract __fractsquhq (long fract A)
- -- Runtime Function: unsigned long fract __fractsqusq (long fract A)
- -- Runtime Function: unsigned long long fract __fractsqudq (long fract
- A)
- -- Runtime Function: unsigned short accum __fractsquha (long fract A)
- -- Runtime Function: unsigned accum __fractsqusa (long fract A)
- -- Runtime Function: unsigned long accum __fractsquda (long fract A)
- -- Runtime Function: unsigned long long accum __fractsquta (long fract
- A)
- -- Runtime Function: signed char __fractsqqi (long fract A)
- -- Runtime Function: short __fractsqhi (long fract A)
- -- Runtime Function: int __fractsqsi (long fract A)
- -- Runtime Function: long __fractsqdi (long fract A)
- -- Runtime Function: long long __fractsqti (long fract A)
- -- Runtime Function: float __fractsqsf (long fract A)
- -- Runtime Function: double __fractsqdf (long fract A)
- -- Runtime Function: short fract __fractdqqq2 (long long fract A)
- -- Runtime Function: fract __fractdqhq2 (long long fract A)
- -- Runtime Function: long fract __fractdqsq2 (long long fract A)
- -- Runtime Function: short accum __fractdqha (long long fract A)
- -- Runtime Function: accum __fractdqsa (long long fract A)
- -- Runtime Function: long accum __fractdqda (long long fract A)
- -- Runtime Function: long long accum __fractdqta (long long fract A)
- -- Runtime Function: unsigned short fract __fractdquqq (long long
- fract A)
- -- Runtime Function: unsigned fract __fractdquhq (long long fract A)
- -- Runtime Function: unsigned long fract __fractdqusq (long long fract
- A)
- -- Runtime Function: unsigned long long fract __fractdqudq (long long
- fract A)
- -- Runtime Function: unsigned short accum __fractdquha (long long
- fract A)
- -- Runtime Function: unsigned accum __fractdqusa (long long fract A)
- -- Runtime Function: unsigned long accum __fractdquda (long long fract
- A)
- -- Runtime Function: unsigned long long accum __fractdquta (long long
- fract A)
- -- Runtime Function: signed char __fractdqqi (long long fract A)
- -- Runtime Function: short __fractdqhi (long long fract A)
- -- Runtime Function: int __fractdqsi (long long fract A)
- -- Runtime Function: long __fractdqdi (long long fract A)
- -- Runtime Function: long long __fractdqti (long long fract A)
- -- Runtime Function: float __fractdqsf (long long fract A)
- -- Runtime Function: double __fractdqdf (long long fract A)
- -- Runtime Function: short fract __fracthaqq (short accum A)
- -- Runtime Function: fract __fracthahq (short accum A)
- -- Runtime Function: long fract __fracthasq (short accum A)
- -- Runtime Function: long long fract __fracthadq (short accum A)
- -- Runtime Function: accum __fracthasa2 (short accum A)
- -- Runtime Function: long accum __fracthada2 (short accum A)
- -- Runtime Function: long long accum __fracthata2 (short accum A)
- -- Runtime Function: unsigned short fract __fracthauqq (short accum A)
- -- Runtime Function: unsigned fract __fracthauhq (short accum A)
- -- Runtime Function: unsigned long fract __fracthausq (short accum A)
- -- Runtime Function: unsigned long long fract __fracthaudq (short
- accum A)
- -- Runtime Function: unsigned short accum __fracthauha (short accum A)
- -- Runtime Function: unsigned accum __fracthausa (short accum A)
- -- Runtime Function: unsigned long accum __fracthauda (short accum A)
- -- Runtime Function: unsigned long long accum __fracthauta (short
- accum A)
- -- Runtime Function: signed char __fracthaqi (short accum A)
- -- Runtime Function: short __fracthahi (short accum A)
- -- Runtime Function: int __fracthasi (short accum A)
- -- Runtime Function: long __fracthadi (short accum A)
- -- Runtime Function: long long __fracthati (short accum A)
- -- Runtime Function: float __fracthasf (short accum A)
- -- Runtime Function: double __fracthadf (short accum A)
- -- Runtime Function: short fract __fractsaqq (accum A)
- -- Runtime Function: fract __fractsahq (accum A)
- -- Runtime Function: long fract __fractsasq (accum A)
- -- Runtime Function: long long fract __fractsadq (accum A)
- -- Runtime Function: short accum __fractsaha2 (accum A)
- -- Runtime Function: long accum __fractsada2 (accum A)
- -- Runtime Function: long long accum __fractsata2 (accum A)
- -- Runtime Function: unsigned short fract __fractsauqq (accum A)
- -- Runtime Function: unsigned fract __fractsauhq (accum A)
- -- Runtime Function: unsigned long fract __fractsausq (accum A)
- -- Runtime Function: unsigned long long fract __fractsaudq (accum A)
- -- Runtime Function: unsigned short accum __fractsauha (accum A)
- -- Runtime Function: unsigned accum __fractsausa (accum A)
- -- Runtime Function: unsigned long accum __fractsauda (accum A)
- -- Runtime Function: unsigned long long accum __fractsauta (accum A)
- -- Runtime Function: signed char __fractsaqi (accum A)
- -- Runtime Function: short __fractsahi (accum A)
- -- Runtime Function: int __fractsasi (accum A)
- -- Runtime Function: long __fractsadi (accum A)
- -- Runtime Function: long long __fractsati (accum A)
- -- Runtime Function: float __fractsasf (accum A)
- -- Runtime Function: double __fractsadf (accum A)
- -- Runtime Function: short fract __fractdaqq (long accum A)
- -- Runtime Function: fract __fractdahq (long accum A)
- -- Runtime Function: long fract __fractdasq (long accum A)
- -- Runtime Function: long long fract __fractdadq (long accum A)
- -- Runtime Function: short accum __fractdaha2 (long accum A)
- -- Runtime Function: accum __fractdasa2 (long accum A)
- -- Runtime Function: long long accum __fractdata2 (long accum A)
- -- Runtime Function: unsigned short fract __fractdauqq (long accum A)
- -- Runtime Function: unsigned fract __fractdauhq (long accum A)
- -- Runtime Function: unsigned long fract __fractdausq (long accum A)
- -- Runtime Function: unsigned long long fract __fractdaudq (long accum
- A)
- -- Runtime Function: unsigned short accum __fractdauha (long accum A)
- -- Runtime Function: unsigned accum __fractdausa (long accum A)
- -- Runtime Function: unsigned long accum __fractdauda (long accum A)
- -- Runtime Function: unsigned long long accum __fractdauta (long accum
- A)
- -- Runtime Function: signed char __fractdaqi (long accum A)
- -- Runtime Function: short __fractdahi (long accum A)
- -- Runtime Function: int __fractdasi (long accum A)
- -- Runtime Function: long __fractdadi (long accum A)
- -- Runtime Function: long long __fractdati (long accum A)
- -- Runtime Function: float __fractdasf (long accum A)
- -- Runtime Function: double __fractdadf (long accum A)
- -- Runtime Function: short fract __fracttaqq (long long accum A)
- -- Runtime Function: fract __fracttahq (long long accum A)
- -- Runtime Function: long fract __fracttasq (long long accum A)
- -- Runtime Function: long long fract __fracttadq (long long accum A)
- -- Runtime Function: short accum __fracttaha2 (long long accum A)
- -- Runtime Function: accum __fracttasa2 (long long accum A)
- -- Runtime Function: long accum __fracttada2 (long long accum A)
- -- Runtime Function: unsigned short fract __fracttauqq (long long
- accum A)
- -- Runtime Function: unsigned fract __fracttauhq (long long accum A)
- -- Runtime Function: unsigned long fract __fracttausq (long long accum
- A)
- -- Runtime Function: unsigned long long fract __fracttaudq (long long
- accum A)
- -- Runtime Function: unsigned short accum __fracttauha (long long
- accum A)
- -- Runtime Function: unsigned accum __fracttausa (long long accum A)
- -- Runtime Function: unsigned long accum __fracttauda (long long accum
- A)
- -- Runtime Function: unsigned long long accum __fracttauta (long long
- accum A)
- -- Runtime Function: signed char __fracttaqi (long long accum A)
- -- Runtime Function: short __fracttahi (long long accum A)
- -- Runtime Function: int __fracttasi (long long accum A)
- -- Runtime Function: long __fracttadi (long long accum A)
- -- Runtime Function: long long __fracttati (long long accum A)
- -- Runtime Function: float __fracttasf (long long accum A)
- -- Runtime Function: double __fracttadf (long long accum A)
- -- Runtime Function: short fract __fractuqqqq (unsigned short fract A)
- -- Runtime Function: fract __fractuqqhq (unsigned short fract A)
- -- Runtime Function: long fract __fractuqqsq (unsigned short fract A)
- -- Runtime Function: long long fract __fractuqqdq (unsigned short
- fract A)
- -- Runtime Function: short accum __fractuqqha (unsigned short fract A)
- -- Runtime Function: accum __fractuqqsa (unsigned short fract A)
- -- Runtime Function: long accum __fractuqqda (unsigned short fract A)
- -- Runtime Function: long long accum __fractuqqta (unsigned short
- fract A)
- -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short
- fract A)
- -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned
- short fract A)
- -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned
- short fract A)
- -- Runtime Function: unsigned short accum __fractuqquha (unsigned
- short fract A)
- -- Runtime Function: unsigned accum __fractuqqusa (unsigned short
- fract A)
- -- Runtime Function: unsigned long accum __fractuqquda (unsigned short
- fract A)
- -- Runtime Function: unsigned long long accum __fractuqquta (unsigned
- short fract A)
- -- Runtime Function: signed char __fractuqqqi (unsigned short fract A)
- -- Runtime Function: short __fractuqqhi (unsigned short fract A)
- -- Runtime Function: int __fractuqqsi (unsigned short fract A)
- -- Runtime Function: long __fractuqqdi (unsigned short fract A)
- -- Runtime Function: long long __fractuqqti (unsigned short fract A)
- -- Runtime Function: float __fractuqqsf (unsigned short fract A)
- -- Runtime Function: double __fractuqqdf (unsigned short fract A)
- -- Runtime Function: short fract __fractuhqqq (unsigned fract A)
- -- Runtime Function: fract __fractuhqhq (unsigned fract A)
- -- Runtime Function: long fract __fractuhqsq (unsigned fract A)
- -- Runtime Function: long long fract __fractuhqdq (unsigned fract A)
- -- Runtime Function: short accum __fractuhqha (unsigned fract A)
- -- Runtime Function: accum __fractuhqsa (unsigned fract A)
- -- Runtime Function: long accum __fractuhqda (unsigned fract A)
- -- Runtime Function: long long accum __fractuhqta (unsigned fract A)
- -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned
- fract A)
- -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned
- fract A)
- -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned
- fract A)
- -- Runtime Function: unsigned short accum __fractuhquha (unsigned
- fract A)
- -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A)
- -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract
- A)
- -- Runtime Function: unsigned long long accum __fractuhquta (unsigned
- fract A)
- -- Runtime Function: signed char __fractuhqqi (unsigned fract A)
- -- Runtime Function: short __fractuhqhi (unsigned fract A)
- -- Runtime Function: int __fractuhqsi (unsigned fract A)
- -- Runtime Function: long __fractuhqdi (unsigned fract A)
- -- Runtime Function: long long __fractuhqti (unsigned fract A)
- -- Runtime Function: float __fractuhqsf (unsigned fract A)
- -- Runtime Function: double __fractuhqdf (unsigned fract A)
- -- Runtime Function: short fract __fractusqqq (unsigned long fract A)
- -- Runtime Function: fract __fractusqhq (unsigned long fract A)
- -- Runtime Function: long fract __fractusqsq (unsigned long fract A)
- -- Runtime Function: long long fract __fractusqdq (unsigned long fract
- A)
- -- Runtime Function: short accum __fractusqha (unsigned long fract A)
- -- Runtime Function: accum __fractusqsa (unsigned long fract A)
- -- Runtime Function: long accum __fractusqda (unsigned long fract A)
- -- Runtime Function: long long accum __fractusqta (unsigned long fract
- A)
- -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned
- long fract A)
- -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long
- fract A)
- -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned
- long fract A)
- -- Runtime Function: unsigned short accum __fractusquha (unsigned long
- fract A)
- -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract
- A)
- -- Runtime Function: unsigned long accum __fractusquda (unsigned long
- fract A)
- -- Runtime Function: unsigned long long accum __fractusquta (unsigned
- long fract A)
- -- Runtime Function: signed char __fractusqqi (unsigned long fract A)
- -- Runtime Function: short __fractusqhi (unsigned long fract A)
- -- Runtime Function: int __fractusqsi (unsigned long fract A)
- -- Runtime Function: long __fractusqdi (unsigned long fract A)
- -- Runtime Function: long long __fractusqti (unsigned long fract A)
- -- Runtime Function: float __fractusqsf (unsigned long fract A)
- -- Runtime Function: double __fractusqdf (unsigned long fract A)
- -- Runtime Function: short fract __fractudqqq (unsigned long long
- fract A)
- -- Runtime Function: fract __fractudqhq (unsigned long long fract A)
- -- Runtime Function: long fract __fractudqsq (unsigned long long fract
- A)
- -- Runtime Function: long long fract __fractudqdq (unsigned long long
- fract A)
- -- Runtime Function: short accum __fractudqha (unsigned long long
- fract A)
- -- Runtime Function: accum __fractudqsa (unsigned long long fract A)
- -- Runtime Function: long accum __fractudqda (unsigned long long fract
- A)
- -- Runtime Function: long long accum __fractudqta (unsigned long long
- fract A)
- -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned
- long long fract A)
- -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long
- fract A)
- -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long
- long fract A)
- -- Runtime Function: unsigned short accum __fractudquha (unsigned long
- long fract A)
- -- Runtime Function: unsigned accum __fractudqusa (unsigned long long
- fract A)
- -- Runtime Function: unsigned long accum __fractudquda (unsigned long
- long fract A)
- -- Runtime Function: unsigned long long accum __fractudquta (unsigned
- long long fract A)
- -- Runtime Function: signed char __fractudqqi (unsigned long long
- fract A)
- -- Runtime Function: short __fractudqhi (unsigned long long fract A)
- -- Runtime Function: int __fractudqsi (unsigned long long fract A)
- -- Runtime Function: long __fractudqdi (unsigned long long fract A)
- -- Runtime Function: long long __fractudqti (unsigned long long fract
- A)
- -- Runtime Function: float __fractudqsf (unsigned long long fract A)
- -- Runtime Function: double __fractudqdf (unsigned long long fract A)
- -- Runtime Function: short fract __fractuhaqq (unsigned short accum A)
- -- Runtime Function: fract __fractuhahq (unsigned short accum A)
- -- Runtime Function: long fract __fractuhasq (unsigned short accum A)
- -- Runtime Function: long long fract __fractuhadq (unsigned short
- accum A)
- -- Runtime Function: short accum __fractuhaha (unsigned short accum A)
- -- Runtime Function: accum __fractuhasa (unsigned short accum A)
- -- Runtime Function: long accum __fractuhada (unsigned short accum A)
- -- Runtime Function: long long accum __fractuhata (unsigned short
- accum A)
- -- Runtime Function: unsigned short fract __fractuhauqq (unsigned
- short accum A)
- -- Runtime Function: unsigned fract __fractuhauhq (unsigned short
- accum A)
- -- Runtime Function: unsigned long fract __fractuhausq (unsigned short
- accum A)
- -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned
- short accum A)
- -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short
- accum A)
- -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned
- short accum A)
- -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned
- short accum A)
- -- Runtime Function: signed char __fractuhaqi (unsigned short accum A)
- -- Runtime Function: short __fractuhahi (unsigned short accum A)
- -- Runtime Function: int __fractuhasi (unsigned short accum A)
- -- Runtime Function: long __fractuhadi (unsigned short accum A)
- -- Runtime Function: long long __fractuhati (unsigned short accum A)
- -- Runtime Function: float __fractuhasf (unsigned short accum A)
- -- Runtime Function: double __fractuhadf (unsigned short accum A)
- -- Runtime Function: short fract __fractusaqq (unsigned accum A)
- -- Runtime Function: fract __fractusahq (unsigned accum A)
- -- Runtime Function: long fract __fractusasq (unsigned accum A)
- -- Runtime Function: long long fract __fractusadq (unsigned accum A)
- -- Runtime Function: short accum __fractusaha (unsigned accum A)
- -- Runtime Function: accum __fractusasa (unsigned accum A)
- -- Runtime Function: long accum __fractusada (unsigned accum A)
- -- Runtime Function: long long accum __fractusata (unsigned accum A)
- -- Runtime Function: unsigned short fract __fractusauqq (unsigned
- accum A)
- -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A)
- -- Runtime Function: unsigned long fract __fractusausq (unsigned accum
- A)
- -- Runtime Function: unsigned long long fract __fractusaudq (unsigned
- accum A)
- -- Runtime Function: unsigned short accum __fractusauha2 (unsigned
- accum A)
- -- Runtime Function: unsigned long accum __fractusauda2 (unsigned
- accum A)
- -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned
- accum A)
- -- Runtime Function: signed char __fractusaqi (unsigned accum A)
- -- Runtime Function: short __fractusahi (unsigned accum A)
- -- Runtime Function: int __fractusasi (unsigned accum A)
- -- Runtime Function: long __fractusadi (unsigned accum A)
- -- Runtime Function: long long __fractusati (unsigned accum A)
- -- Runtime Function: float __fractusasf (unsigned accum A)
- -- Runtime Function: double __fractusadf (unsigned accum A)
- -- Runtime Function: short fract __fractudaqq (unsigned long accum A)
- -- Runtime Function: fract __fractudahq (unsigned long accum A)
- -- Runtime Function: long fract __fractudasq (unsigned long accum A)
- -- Runtime Function: long long fract __fractudadq (unsigned long accum
- A)
- -- Runtime Function: short accum __fractudaha (unsigned long accum A)
- -- Runtime Function: accum __fractudasa (unsigned long accum A)
- -- Runtime Function: long accum __fractudada (unsigned long accum A)
- -- Runtime Function: long long accum __fractudata (unsigned long accum
- A)
- -- Runtime Function: unsigned short fract __fractudauqq (unsigned long
- accum A)
- -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum
- A)
- -- Runtime Function: unsigned long fract __fractudausq (unsigned long
- accum A)
- -- Runtime Function: unsigned long long fract __fractudaudq (unsigned
- long accum A)
- -- Runtime Function: unsigned short accum __fractudauha2 (unsigned
- long accum A)
- -- Runtime Function: unsigned accum __fractudausa2 (unsigned long
- accum A)
- -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned
- long accum A)
- -- Runtime Function: signed char __fractudaqi (unsigned long accum A)
- -- Runtime Function: short __fractudahi (unsigned long accum A)
- -- Runtime Function: int __fractudasi (unsigned long accum A)
- -- Runtime Function: long __fractudadi (unsigned long accum A)
- -- Runtime Function: long long __fractudati (unsigned long accum A)
- -- Runtime Function: float __fractudasf (unsigned long accum A)
- -- Runtime Function: double __fractudadf (unsigned long accum A)
- -- Runtime Function: short fract __fractutaqq (unsigned long long
- accum A)
- -- Runtime Function: fract __fractutahq (unsigned long long accum A)
- -- Runtime Function: long fract __fractutasq (unsigned long long accum
- A)
- -- Runtime Function: long long fract __fractutadq (unsigned long long
- accum A)
- -- Runtime Function: short accum __fractutaha (unsigned long long
- accum A)
- -- Runtime Function: accum __fractutasa (unsigned long long accum A)
- -- Runtime Function: long accum __fractutada (unsigned long long accum
- A)
- -- Runtime Function: long long accum __fractutata (unsigned long long
- accum A)
- -- Runtime Function: unsigned short fract __fractutauqq (unsigned long
- long accum A)
- -- Runtime Function: unsigned fract __fractutauhq (unsigned long long
- accum A)
- -- Runtime Function: unsigned long fract __fractutausq (unsigned long
- long accum A)
- -- Runtime Function: unsigned long long fract __fractutaudq (unsigned
- long long accum A)
- -- Runtime Function: unsigned short accum __fractutauha2 (unsigned
- long long accum A)
- -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long
- accum A)
- -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long
- long accum A)
- -- Runtime Function: signed char __fractutaqi (unsigned long long
- accum A)
- -- Runtime Function: short __fractutahi (unsigned long long accum A)
- -- Runtime Function: int __fractutasi (unsigned long long accum A)
- -- Runtime Function: long __fractutadi (unsigned long long accum A)
- -- Runtime Function: long long __fractutati (unsigned long long accum
- A)
- -- Runtime Function: float __fractutasf (unsigned long long accum A)
- -- Runtime Function: double __fractutadf (unsigned long long accum A)
- -- Runtime Function: short fract __fractqiqq (signed char A)
- -- Runtime Function: fract __fractqihq (signed char A)
- -- Runtime Function: long fract __fractqisq (signed char A)
- -- Runtime Function: long long fract __fractqidq (signed char A)
- -- Runtime Function: short accum __fractqiha (signed char A)
- -- Runtime Function: accum __fractqisa (signed char A)
- -- Runtime Function: long accum __fractqida (signed char A)
- -- Runtime Function: long long accum __fractqita (signed char A)
- -- Runtime Function: unsigned short fract __fractqiuqq (signed char A)
- -- Runtime Function: unsigned fract __fractqiuhq (signed char A)
- -- Runtime Function: unsigned long fract __fractqiusq (signed char A)
- -- Runtime Function: unsigned long long fract __fractqiudq (signed
- char A)
- -- Runtime Function: unsigned short accum __fractqiuha (signed char A)
- -- Runtime Function: unsigned accum __fractqiusa (signed char A)
- -- Runtime Function: unsigned long accum __fractqiuda (signed char A)
- -- Runtime Function: unsigned long long accum __fractqiuta (signed
- char A)
- -- Runtime Function: short fract __fracthiqq (short A)
- -- Runtime Function: fract __fracthihq (short A)
- -- Runtime Function: long fract __fracthisq (short A)
- -- Runtime Function: long long fract __fracthidq (short A)
- -- Runtime Function: short accum __fracthiha (short A)
- -- Runtime Function: accum __fracthisa (short A)
- -- Runtime Function: long accum __fracthida (short A)
- -- Runtime Function: long long accum __fracthita (short A)
- -- Runtime Function: unsigned short fract __fracthiuqq (short A)
- -- Runtime Function: unsigned fract __fracthiuhq (short A)
- -- Runtime Function: unsigned long fract __fracthiusq (short A)
- -- Runtime Function: unsigned long long fract __fracthiudq (short A)
- -- Runtime Function: unsigned short accum __fracthiuha (short A)
- -- Runtime Function: unsigned accum __fracthiusa (short A)
- -- Runtime Function: unsigned long accum __fracthiuda (short A)
- -- Runtime Function: unsigned long long accum __fracthiuta (short A)
- -- Runtime Function: short fract __fractsiqq (int A)
- -- Runtime Function: fract __fractsihq (int A)
- -- Runtime Function: long fract __fractsisq (int A)
- -- Runtime Function: long long fract __fractsidq (int A)
- -- Runtime Function: short accum __fractsiha (int A)
- -- Runtime Function: accum __fractsisa (int A)
- -- Runtime Function: long accum __fractsida (int A)
- -- Runtime Function: long long accum __fractsita (int A)
- -- Runtime Function: unsigned short fract __fractsiuqq (int A)
- -- Runtime Function: unsigned fract __fractsiuhq (int A)
- -- Runtime Function: unsigned long fract __fractsiusq (int A)
- -- Runtime Function: unsigned long long fract __fractsiudq (int A)
- -- Runtime Function: unsigned short accum __fractsiuha (int A)
- -- Runtime Function: unsigned accum __fractsiusa (int A)
- -- Runtime Function: unsigned long accum __fractsiuda (int A)
- -- Runtime Function: unsigned long long accum __fractsiuta (int A)
- -- Runtime Function: short fract __fractdiqq (long A)
- -- Runtime Function: fract __fractdihq (long A)
- -- Runtime Function: long fract __fractdisq (long A)
- -- Runtime Function: long long fract __fractdidq (long A)
- -- Runtime Function: short accum __fractdiha (long A)
- -- Runtime Function: accum __fractdisa (long A)
- -- Runtime Function: long accum __fractdida (long A)
- -- Runtime Function: long long accum __fractdita (long A)
- -- Runtime Function: unsigned short fract __fractdiuqq (long A)
- -- Runtime Function: unsigned fract __fractdiuhq (long A)
- -- Runtime Function: unsigned long fract __fractdiusq (long A)
- -- Runtime Function: unsigned long long fract __fractdiudq (long A)
- -- Runtime Function: unsigned short accum __fractdiuha (long A)
- -- Runtime Function: unsigned accum __fractdiusa (long A)
- -- Runtime Function: unsigned long accum __fractdiuda (long A)
- -- Runtime Function: unsigned long long accum __fractdiuta (long A)
- -- Runtime Function: short fract __fracttiqq (long long A)
- -- Runtime Function: fract __fracttihq (long long A)
- -- Runtime Function: long fract __fracttisq (long long A)
- -- Runtime Function: long long fract __fracttidq (long long A)
- -- Runtime Function: short accum __fracttiha (long long A)
- -- Runtime Function: accum __fracttisa (long long A)
- -- Runtime Function: long accum __fracttida (long long A)
- -- Runtime Function: long long accum __fracttita (long long A)
- -- Runtime Function: unsigned short fract __fracttiuqq (long long A)
- -- Runtime Function: unsigned fract __fracttiuhq (long long A)
- -- Runtime Function: unsigned long fract __fracttiusq (long long A)
- -- Runtime Function: unsigned long long fract __fracttiudq (long long
- A)
- -- Runtime Function: unsigned short accum __fracttiuha (long long A)
- -- Runtime Function: unsigned accum __fracttiusa (long long A)
- -- Runtime Function: unsigned long accum __fracttiuda (long long A)
- -- Runtime Function: unsigned long long accum __fracttiuta (long long
- A)
- -- Runtime Function: short fract __fractsfqq (float A)
- -- Runtime Function: fract __fractsfhq (float A)
- -- Runtime Function: long fract __fractsfsq (float A)
- -- Runtime Function: long long fract __fractsfdq (float A)
- -- Runtime Function: short accum __fractsfha (float A)
- -- Runtime Function: accum __fractsfsa (float A)
- -- Runtime Function: long accum __fractsfda (float A)
- -- Runtime Function: long long accum __fractsfta (float A)
- -- Runtime Function: unsigned short fract __fractsfuqq (float A)
- -- Runtime Function: unsigned fract __fractsfuhq (float A)
- -- Runtime Function: unsigned long fract __fractsfusq (float A)
- -- Runtime Function: unsigned long long fract __fractsfudq (float A)
- -- Runtime Function: unsigned short accum __fractsfuha (float A)
- -- Runtime Function: unsigned accum __fractsfusa (float A)
- -- Runtime Function: unsigned long accum __fractsfuda (float A)
- -- Runtime Function: unsigned long long accum __fractsfuta (float A)
- -- Runtime Function: short fract __fractdfqq (double A)
- -- Runtime Function: fract __fractdfhq (double A)
- -- Runtime Function: long fract __fractdfsq (double A)
- -- Runtime Function: long long fract __fractdfdq (double A)
- -- Runtime Function: short accum __fractdfha (double A)
- -- Runtime Function: accum __fractdfsa (double A)
- -- Runtime Function: long accum __fractdfda (double A)
- -- Runtime Function: long long accum __fractdfta (double A)
- -- Runtime Function: unsigned short fract __fractdfuqq (double A)
- -- Runtime Function: unsigned fract __fractdfuhq (double A)
- -- Runtime Function: unsigned long fract __fractdfusq (double A)
- -- Runtime Function: unsigned long long fract __fractdfudq (double A)
- -- Runtime Function: unsigned short accum __fractdfuha (double A)
- -- Runtime Function: unsigned accum __fractdfusa (double A)
- -- Runtime Function: unsigned long accum __fractdfuda (double A)
- -- Runtime Function: unsigned long long accum __fractdfuta (double A)
- These functions convert from fractional and signed non-fractionals
- to fractionals and signed non-fractionals, without saturation.
-
- -- Runtime Function: fract __satfractqqhq2 (short fract A)
- -- Runtime Function: long fract __satfractqqsq2 (short fract A)
- -- Runtime Function: long long fract __satfractqqdq2 (short fract A)
- -- Runtime Function: short accum __satfractqqha (short fract A)
- -- Runtime Function: accum __satfractqqsa (short fract A)
- -- Runtime Function: long accum __satfractqqda (short fract A)
- -- Runtime Function: long long accum __satfractqqta (short fract A)
- -- Runtime Function: unsigned short fract __satfractqquqq (short fract
- A)
- -- Runtime Function: unsigned fract __satfractqquhq (short fract A)
- -- Runtime Function: unsigned long fract __satfractqqusq (short fract
- A)
- -- Runtime Function: unsigned long long fract __satfractqqudq (short
- fract A)
- -- Runtime Function: unsigned short accum __satfractqquha (short fract
- A)
- -- Runtime Function: unsigned accum __satfractqqusa (short fract A)
- -- Runtime Function: unsigned long accum __satfractqquda (short fract
- A)
- -- Runtime Function: unsigned long long accum __satfractqquta (short
- fract A)
- -- Runtime Function: short fract __satfracthqqq2 (fract A)
- -- Runtime Function: long fract __satfracthqsq2 (fract A)
- -- Runtime Function: long long fract __satfracthqdq2 (fract A)
- -- Runtime Function: short accum __satfracthqha (fract A)
- -- Runtime Function: accum __satfracthqsa (fract A)
- -- Runtime Function: long accum __satfracthqda (fract A)
- -- Runtime Function: long long accum __satfracthqta (fract A)
- -- Runtime Function: unsigned short fract __satfracthquqq (fract A)
- -- Runtime Function: unsigned fract __satfracthquhq (fract A)
- -- Runtime Function: unsigned long fract __satfracthqusq (fract A)
- -- Runtime Function: unsigned long long fract __satfracthqudq (fract A)
- -- Runtime Function: unsigned short accum __satfracthquha (fract A)
- -- Runtime Function: unsigned accum __satfracthqusa (fract A)
- -- Runtime Function: unsigned long accum __satfracthquda (fract A)
- -- Runtime Function: unsigned long long accum __satfracthquta (fract A)
- -- Runtime Function: short fract __satfractsqqq2 (long fract A)
- -- Runtime Function: fract __satfractsqhq2 (long fract A)
- -- Runtime Function: long long fract __satfractsqdq2 (long fract A)
- -- Runtime Function: short accum __satfractsqha (long fract A)
- -- Runtime Function: accum __satfractsqsa (long fract A)
- -- Runtime Function: long accum __satfractsqda (long fract A)
- -- Runtime Function: long long accum __satfractsqta (long fract A)
- -- Runtime Function: unsigned short fract __satfractsquqq (long fract
- A)
- -- Runtime Function: unsigned fract __satfractsquhq (long fract A)
- -- Runtime Function: unsigned long fract __satfractsqusq (long fract A)
- -- Runtime Function: unsigned long long fract __satfractsqudq (long
- fract A)
- -- Runtime Function: unsigned short accum __satfractsquha (long fract
- A)
- -- Runtime Function: unsigned accum __satfractsqusa (long fract A)
- -- Runtime Function: unsigned long accum __satfractsquda (long fract A)
- -- Runtime Function: unsigned long long accum __satfractsquta (long
- fract A)
- -- Runtime Function: short fract __satfractdqqq2 (long long fract A)
- -- Runtime Function: fract __satfractdqhq2 (long long fract A)
- -- Runtime Function: long fract __satfractdqsq2 (long long fract A)
- -- Runtime Function: short accum __satfractdqha (long long fract A)
- -- Runtime Function: accum __satfractdqsa (long long fract A)
- -- Runtime Function: long accum __satfractdqda (long long fract A)
- -- Runtime Function: long long accum __satfractdqta (long long fract A)
- -- Runtime Function: unsigned short fract __satfractdquqq (long long
- fract A)
- -- Runtime Function: unsigned fract __satfractdquhq (long long fract A)
- -- Runtime Function: unsigned long fract __satfractdqusq (long long
- fract A)
- -- Runtime Function: unsigned long long fract __satfractdqudq (long
- long fract A)
- -- Runtime Function: unsigned short accum __satfractdquha (long long
- fract A)
- -- Runtime Function: unsigned accum __satfractdqusa (long long fract A)
- -- Runtime Function: unsigned long accum __satfractdquda (long long
- fract A)
- -- Runtime Function: unsigned long long accum __satfractdquta (long
- long fract A)
- -- Runtime Function: short fract __satfracthaqq (short accum A)
- -- Runtime Function: fract __satfracthahq (short accum A)
- -- Runtime Function: long fract __satfracthasq (short accum A)
- -- Runtime Function: long long fract __satfracthadq (short accum A)
- -- Runtime Function: accum __satfracthasa2 (short accum A)
- -- Runtime Function: long accum __satfracthada2 (short accum A)
- -- Runtime Function: long long accum __satfracthata2 (short accum A)
- -- Runtime Function: unsigned short fract __satfracthauqq (short accum
- A)
- -- Runtime Function: unsigned fract __satfracthauhq (short accum A)
- -- Runtime Function: unsigned long fract __satfracthausq (short accum
- A)
- -- Runtime Function: unsigned long long fract __satfracthaudq (short
- accum A)
- -- Runtime Function: unsigned short accum __satfracthauha (short accum
- A)
- -- Runtime Function: unsigned accum __satfracthausa (short accum A)
- -- Runtime Function: unsigned long accum __satfracthauda (short accum
- A)
- -- Runtime Function: unsigned long long accum __satfracthauta (short
- accum A)
- -- Runtime Function: short fract __satfractsaqq (accum A)
- -- Runtime Function: fract __satfractsahq (accum A)
- -- Runtime Function: long fract __satfractsasq (accum A)
- -- Runtime Function: long long fract __satfractsadq (accum A)
- -- Runtime Function: short accum __satfractsaha2 (accum A)
- -- Runtime Function: long accum __satfractsada2 (accum A)
- -- Runtime Function: long long accum __satfractsata2 (accum A)
- -- Runtime Function: unsigned short fract __satfractsauqq (accum A)
- -- Runtime Function: unsigned fract __satfractsauhq (accum A)
- -- Runtime Function: unsigned long fract __satfractsausq (accum A)
- -- Runtime Function: unsigned long long fract __satfractsaudq (accum A)
- -- Runtime Function: unsigned short accum __satfractsauha (accum A)
- -- Runtime Function: unsigned accum __satfractsausa (accum A)
- -- Runtime Function: unsigned long accum __satfractsauda (accum A)
- -- Runtime Function: unsigned long long accum __satfractsauta (accum A)
- -- Runtime Function: short fract __satfractdaqq (long accum A)
- -- Runtime Function: fract __satfractdahq (long accum A)
- -- Runtime Function: long fract __satfractdasq (long accum A)
- -- Runtime Function: long long fract __satfractdadq (long accum A)
- -- Runtime Function: short accum __satfractdaha2 (long accum A)
- -- Runtime Function: accum __satfractdasa2 (long accum A)
- -- Runtime Function: long long accum __satfractdata2 (long accum A)
- -- Runtime Function: unsigned short fract __satfractdauqq (long accum
- A)
- -- Runtime Function: unsigned fract __satfractdauhq (long accum A)
- -- Runtime Function: unsigned long fract __satfractdausq (long accum A)
- -- Runtime Function: unsigned long long fract __satfractdaudq (long
- accum A)
- -- Runtime Function: unsigned short accum __satfractdauha (long accum
- A)
- -- Runtime Function: unsigned accum __satfractdausa (long accum A)
- -- Runtime Function: unsigned long accum __satfractdauda (long accum A)
- -- Runtime Function: unsigned long long accum __satfractdauta (long
- accum A)
- -- Runtime Function: short fract __satfracttaqq (long long accum A)
- -- Runtime Function: fract __satfracttahq (long long accum A)
- -- Runtime Function: long fract __satfracttasq (long long accum A)
- -- Runtime Function: long long fract __satfracttadq (long long accum A)
- -- Runtime Function: short accum __satfracttaha2 (long long accum A)
- -- Runtime Function: accum __satfracttasa2 (long long accum A)
- -- Runtime Function: long accum __satfracttada2 (long long accum A)
- -- Runtime Function: unsigned short fract __satfracttauqq (long long
- accum A)
- -- Runtime Function: unsigned fract __satfracttauhq (long long accum A)
- -- Runtime Function: unsigned long fract __satfracttausq (long long
- accum A)
- -- Runtime Function: unsigned long long fract __satfracttaudq (long
- long accum A)
- -- Runtime Function: unsigned short accum __satfracttauha (long long
- accum A)
- -- Runtime Function: unsigned accum __satfracttausa (long long accum A)
- -- Runtime Function: unsigned long accum __satfracttauda (long long
- accum A)
- -- Runtime Function: unsigned long long accum __satfracttauta (long
- long accum A)
- -- Runtime Function: short fract __satfractuqqqq (unsigned short fract
- A)
- -- Runtime Function: fract __satfractuqqhq (unsigned short fract A)
- -- Runtime Function: long fract __satfractuqqsq (unsigned short fract
- A)
- -- Runtime Function: long long fract __satfractuqqdq (unsigned short
- fract A)
- -- Runtime Function: short accum __satfractuqqha (unsigned short fract
- A)
- -- Runtime Function: accum __satfractuqqsa (unsigned short fract A)
- -- Runtime Function: long accum __satfractuqqda (unsigned short fract
- A)
- -- Runtime Function: long long accum __satfractuqqta (unsigned short
- fract A)
- -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short
- fract A)
- -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned
- short fract A)
- -- Runtime Function: unsigned long long fract __satfractuqqudq2
- (unsigned short fract A)
- -- Runtime Function: unsigned short accum __satfractuqquha (unsigned
- short fract A)
- -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short
- fract A)
- -- Runtime Function: unsigned long accum __satfractuqquda (unsigned
- short fract A)
- -- Runtime Function: unsigned long long accum __satfractuqquta
- (unsigned short fract A)
- -- Runtime Function: short fract __satfractuhqqq (unsigned fract A)
- -- Runtime Function: fract __satfractuhqhq (unsigned fract A)
- -- Runtime Function: long fract __satfractuhqsq (unsigned fract A)
- -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A)
- -- Runtime Function: short accum __satfractuhqha (unsigned fract A)
- -- Runtime Function: accum __satfractuhqsa (unsigned fract A)
- -- Runtime Function: long accum __satfractuhqda (unsigned fract A)
- -- Runtime Function: long long accum __satfractuhqta (unsigned fract A)
- -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned
- fract A)
- -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned
- fract A)
- -- Runtime Function: unsigned long long fract __satfractuhqudq2
- (unsigned fract A)
- -- Runtime Function: unsigned short accum __satfractuhquha (unsigned
- fract A)
- -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A)
- -- Runtime Function: unsigned long accum __satfractuhquda (unsigned
- fract A)
- -- Runtime Function: unsigned long long accum __satfractuhquta
- (unsigned fract A)
- -- Runtime Function: short fract __satfractusqqq (unsigned long fract
- A)
- -- Runtime Function: fract __satfractusqhq (unsigned long fract A)
- -- Runtime Function: long fract __satfractusqsq (unsigned long fract A)
- -- Runtime Function: long long fract __satfractusqdq (unsigned long
- fract A)
- -- Runtime Function: short accum __satfractusqha (unsigned long fract
- A)
- -- Runtime Function: accum __satfractusqsa (unsigned long fract A)
- -- Runtime Function: long accum __satfractusqda (unsigned long fract A)
- -- Runtime Function: long long accum __satfractusqta (unsigned long
- fract A)
- -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned
- long fract A)
- -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long
- fract A)
- -- Runtime Function: unsigned long long fract __satfractusqudq2
- (unsigned long fract A)
- -- Runtime Function: unsigned short accum __satfractusquha (unsigned
- long fract A)
- -- Runtime Function: unsigned accum __satfractusqusa (unsigned long
- fract A)
- -- Runtime Function: unsigned long accum __satfractusquda (unsigned
- long fract A)
- -- Runtime Function: unsigned long long accum __satfractusquta
- (unsigned long fract A)
- -- Runtime Function: short fract __satfractudqqq (unsigned long long
- fract A)
- -- Runtime Function: fract __satfractudqhq (unsigned long long fract A)
- -- Runtime Function: long fract __satfractudqsq (unsigned long long
- fract A)
- -- Runtime Function: long long fract __satfractudqdq (unsigned long
- long fract A)
- -- Runtime Function: short accum __satfractudqha (unsigned long long
- fract A)
- -- Runtime Function: accum __satfractudqsa (unsigned long long fract A)
- -- Runtime Function: long accum __satfractudqda (unsigned long long
- fract A)
- -- Runtime Function: long long accum __satfractudqta (unsigned long
- long fract A)
- -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned
- long long fract A)
- -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long
- long fract A)
- -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned
- long long fract A)
- -- Runtime Function: unsigned short accum __satfractudquha (unsigned
- long long fract A)
- -- Runtime Function: unsigned accum __satfractudqusa (unsigned long
- long fract A)
- -- Runtime Function: unsigned long accum __satfractudquda (unsigned
- long long fract A)
- -- Runtime Function: unsigned long long accum __satfractudquta
- (unsigned long long fract A)
- -- Runtime Function: short fract __satfractuhaqq (unsigned short accum
- A)
- -- Runtime Function: fract __satfractuhahq (unsigned short accum A)
- -- Runtime Function: long fract __satfractuhasq (unsigned short accum
- A)
- -- Runtime Function: long long fract __satfractuhadq (unsigned short
- accum A)
- -- Runtime Function: short accum __satfractuhaha (unsigned short accum
- A)
- -- Runtime Function: accum __satfractuhasa (unsigned short accum A)
- -- Runtime Function: long accum __satfractuhada (unsigned short accum
- A)
- -- Runtime Function: long long accum __satfractuhata (unsigned short
- accum A)
- -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned
- short accum A)
- -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short
- accum A)
- -- Runtime Function: unsigned long fract __satfractuhausq (unsigned
- short accum A)
- -- Runtime Function: unsigned long long fract __satfractuhaudq
- (unsigned short accum A)
- -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short
- accum A)
- -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned
- short accum A)
- -- Runtime Function: unsigned long long accum __satfractuhauta2
- (unsigned short accum A)
- -- Runtime Function: short fract __satfractusaqq (unsigned accum A)
- -- Runtime Function: fract __satfractusahq (unsigned accum A)
- -- Runtime Function: long fract __satfractusasq (unsigned accum A)
- -- Runtime Function: long long fract __satfractusadq (unsigned accum A)
- -- Runtime Function: short accum __satfractusaha (unsigned accum A)
- -- Runtime Function: accum __satfractusasa (unsigned accum A)
- -- Runtime Function: long accum __satfractusada (unsigned accum A)
- -- Runtime Function: long long accum __satfractusata (unsigned accum A)
- -- Runtime Function: unsigned short fract __satfractusauqq (unsigned
- accum A)
- -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A)
- -- Runtime Function: unsigned long fract __satfractusausq (unsigned
- accum A)
- -- Runtime Function: unsigned long long fract __satfractusaudq
- (unsigned accum A)
- -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned
- accum A)
- -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned
- accum A)
- -- Runtime Function: unsigned long long accum __satfractusauta2
- (unsigned accum A)
- -- Runtime Function: short fract __satfractudaqq (unsigned long accum
- A)
- -- Runtime Function: fract __satfractudahq (unsigned long accum A)
- -- Runtime Function: long fract __satfractudasq (unsigned long accum A)
- -- Runtime Function: long long fract __satfractudadq (unsigned long
- accum A)
- -- Runtime Function: short accum __satfractudaha (unsigned long accum
- A)
- -- Runtime Function: accum __satfractudasa (unsigned long accum A)
- -- Runtime Function: long accum __satfractudada (unsigned long accum A)
- -- Runtime Function: long long accum __satfractudata (unsigned long
- accum A)
- -- Runtime Function: unsigned short fract __satfractudauqq (unsigned
- long accum A)
- -- Runtime Function: unsigned fract __satfractudauhq (unsigned long
- accum A)
- -- Runtime Function: unsigned long fract __satfractudausq (unsigned
- long accum A)
- -- Runtime Function: unsigned long long fract __satfractudaudq
- (unsigned long accum A)
- -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned
- long accum A)
- -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long
- accum A)
- -- Runtime Function: unsigned long long accum __satfractudauta2
- (unsigned long accum A)
- -- Runtime Function: short fract __satfractutaqq (unsigned long long
- accum A)
- -- Runtime Function: fract __satfractutahq (unsigned long long accum A)
- -- Runtime Function: long fract __satfractutasq (unsigned long long
- accum A)
- -- Runtime Function: long long fract __satfractutadq (unsigned long
- long accum A)
- -- Runtime Function: short accum __satfractutaha (unsigned long long
- accum A)
- -- Runtime Function: accum __satfractutasa (unsigned long long accum A)
- -- Runtime Function: long accum __satfractutada (unsigned long long
- accum A)
- -- Runtime Function: long long accum __satfractutata (unsigned long
- long accum A)
- -- Runtime Function: unsigned short fract __satfractutauqq (unsigned
- long long accum A)
- -- Runtime Function: unsigned fract __satfractutauhq (unsigned long
- long accum A)
- -- Runtime Function: unsigned long fract __satfractutausq (unsigned
- long long accum A)
- -- Runtime Function: unsigned long long fract __satfractutaudq
- (unsigned long long accum A)
- -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned
- long long accum A)
- -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long
- long accum A)
- -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned
- long long accum A)
- -- Runtime Function: short fract __satfractqiqq (signed char A)
- -- Runtime Function: fract __satfractqihq (signed char A)
- -- Runtime Function: long fract __satfractqisq (signed char A)
- -- Runtime Function: long long fract __satfractqidq (signed char A)
- -- Runtime Function: short accum __satfractqiha (signed char A)
- -- Runtime Function: accum __satfractqisa (signed char A)
- -- Runtime Function: long accum __satfractqida (signed char A)
- -- Runtime Function: long long accum __satfractqita (signed char A)
- -- Runtime Function: unsigned short fract __satfractqiuqq (signed char
- A)
- -- Runtime Function: unsigned fract __satfractqiuhq (signed char A)
- -- Runtime Function: unsigned long fract __satfractqiusq (signed char
- A)
- -- Runtime Function: unsigned long long fract __satfractqiudq (signed
- char A)
- -- Runtime Function: unsigned short accum __satfractqiuha (signed char
- A)
- -- Runtime Function: unsigned accum __satfractqiusa (signed char A)
- -- Runtime Function: unsigned long accum __satfractqiuda (signed char
- A)
- -- Runtime Function: unsigned long long accum __satfractqiuta (signed
- char A)
- -- Runtime Function: short fract __satfracthiqq (short A)
- -- Runtime Function: fract __satfracthihq (short A)
- -- Runtime Function: long fract __satfracthisq (short A)
- -- Runtime Function: long long fract __satfracthidq (short A)
- -- Runtime Function: short accum __satfracthiha (short A)
- -- Runtime Function: accum __satfracthisa (short A)
- -- Runtime Function: long accum __satfracthida (short A)
- -- Runtime Function: long long accum __satfracthita (short A)
- -- Runtime Function: unsigned short fract __satfracthiuqq (short A)
- -- Runtime Function: unsigned fract __satfracthiuhq (short A)
- -- Runtime Function: unsigned long fract __satfracthiusq (short A)
- -- Runtime Function: unsigned long long fract __satfracthiudq (short A)
- -- Runtime Function: unsigned short accum __satfracthiuha (short A)
- -- Runtime Function: unsigned accum __satfracthiusa (short A)
- -- Runtime Function: unsigned long accum __satfracthiuda (short A)
- -- Runtime Function: unsigned long long accum __satfracthiuta (short A)
- -- Runtime Function: short fract __satfractsiqq (int A)
- -- Runtime Function: fract __satfractsihq (int A)
- -- Runtime Function: long fract __satfractsisq (int A)
- -- Runtime Function: long long fract __satfractsidq (int A)
- -- Runtime Function: short accum __satfractsiha (int A)
- -- Runtime Function: accum __satfractsisa (int A)
- -- Runtime Function: long accum __satfractsida (int A)
- -- Runtime Function: long long accum __satfractsita (int A)
- -- Runtime Function: unsigned short fract __satfractsiuqq (int A)
- -- Runtime Function: unsigned fract __satfractsiuhq (int A)
- -- Runtime Function: unsigned long fract __satfractsiusq (int A)
- -- Runtime Function: unsigned long long fract __satfractsiudq (int A)
- -- Runtime Function: unsigned short accum __satfractsiuha (int A)
- -- Runtime Function: unsigned accum __satfractsiusa (int A)
- -- Runtime Function: unsigned long accum __satfractsiuda (int A)
- -- Runtime Function: unsigned long long accum __satfractsiuta (int A)
- -- Runtime Function: short fract __satfractdiqq (long A)
- -- Runtime Function: fract __satfractdihq (long A)
- -- Runtime Function: long fract __satfractdisq (long A)
- -- Runtime Function: long long fract __satfractdidq (long A)
- -- Runtime Function: short accum __satfractdiha (long A)
- -- Runtime Function: accum __satfractdisa (long A)
- -- Runtime Function: long accum __satfractdida (long A)
- -- Runtime Function: long long accum __satfractdita (long A)
- -- Runtime Function: unsigned short fract __satfractdiuqq (long A)
- -- Runtime Function: unsigned fract __satfractdiuhq (long A)
- -- Runtime Function: unsigned long fract __satfractdiusq (long A)
- -- Runtime Function: unsigned long long fract __satfractdiudq (long A)
- -- Runtime Function: unsigned short accum __satfractdiuha (long A)
- -- Runtime Function: unsigned accum __satfractdiusa (long A)
- -- Runtime Function: unsigned long accum __satfractdiuda (long A)
- -- Runtime Function: unsigned long long accum __satfractdiuta (long A)
- -- Runtime Function: short fract __satfracttiqq (long long A)
- -- Runtime Function: fract __satfracttihq (long long A)
- -- Runtime Function: long fract __satfracttisq (long long A)
- -- Runtime Function: long long fract __satfracttidq (long long A)
- -- Runtime Function: short accum __satfracttiha (long long A)
- -- Runtime Function: accum __satfracttisa (long long A)
- -- Runtime Function: long accum __satfracttida (long long A)
- -- Runtime Function: long long accum __satfracttita (long long A)
- -- Runtime Function: unsigned short fract __satfracttiuqq (long long A)
- -- Runtime Function: unsigned fract __satfracttiuhq (long long A)
- -- Runtime Function: unsigned long fract __satfracttiusq (long long A)
- -- Runtime Function: unsigned long long fract __satfracttiudq (long
- long A)
- -- Runtime Function: unsigned short accum __satfracttiuha (long long A)
- -- Runtime Function: unsigned accum __satfracttiusa (long long A)
- -- Runtime Function: unsigned long accum __satfracttiuda (long long A)
- -- Runtime Function: unsigned long long accum __satfracttiuta (long
- long A)
- -- Runtime Function: short fract __satfractsfqq (float A)
- -- Runtime Function: fract __satfractsfhq (float A)
- -- Runtime Function: long fract __satfractsfsq (float A)
- -- Runtime Function: long long fract __satfractsfdq (float A)
- -- Runtime Function: short accum __satfractsfha (float A)
- -- Runtime Function: accum __satfractsfsa (float A)
- -- Runtime Function: long accum __satfractsfda (float A)
- -- Runtime Function: long long accum __satfractsfta (float A)
- -- Runtime Function: unsigned short fract __satfractsfuqq (float A)
- -- Runtime Function: unsigned fract __satfractsfuhq (float A)
- -- Runtime Function: unsigned long fract __satfractsfusq (float A)
- -- Runtime Function: unsigned long long fract __satfractsfudq (float A)
- -- Runtime Function: unsigned short accum __satfractsfuha (float A)
- -- Runtime Function: unsigned accum __satfractsfusa (float A)
- -- Runtime Function: unsigned long accum __satfractsfuda (float A)
- -- Runtime Function: unsigned long long accum __satfractsfuta (float A)
- -- Runtime Function: short fract __satfractdfqq (double A)
- -- Runtime Function: fract __satfractdfhq (double A)
- -- Runtime Function: long fract __satfractdfsq (double A)
- -- Runtime Function: long long fract __satfractdfdq (double A)
- -- Runtime Function: short accum __satfractdfha (double A)
- -- Runtime Function: accum __satfractdfsa (double A)
- -- Runtime Function: long accum __satfractdfda (double A)
- -- Runtime Function: long long accum __satfractdfta (double A)
- -- Runtime Function: unsigned short fract __satfractdfuqq (double A)
- -- Runtime Function: unsigned fract __satfractdfuhq (double A)
- -- Runtime Function: unsigned long fract __satfractdfusq (double A)
- -- Runtime Function: unsigned long long fract __satfractdfudq (double
- A)
- -- Runtime Function: unsigned short accum __satfractdfuha (double A)
- -- Runtime Function: unsigned accum __satfractdfusa (double A)
- -- Runtime Function: unsigned long accum __satfractdfuda (double A)
- -- Runtime Function: unsigned long long accum __satfractdfuta (double
- A)
- The functions convert from fractional and signed non-fractionals to
- fractionals, with saturation.
-
- -- Runtime Function: unsigned char __fractunsqqqi (short fract A)
- -- Runtime Function: unsigned short __fractunsqqhi (short fract A)
- -- Runtime Function: unsigned int __fractunsqqsi (short fract A)
- -- Runtime Function: unsigned long __fractunsqqdi (short fract A)
- -- Runtime Function: unsigned long long __fractunsqqti (short fract A)
- -- Runtime Function: unsigned char __fractunshqqi (fract A)
- -- Runtime Function: unsigned short __fractunshqhi (fract A)
- -- Runtime Function: unsigned int __fractunshqsi (fract A)
- -- Runtime Function: unsigned long __fractunshqdi (fract A)
- -- Runtime Function: unsigned long long __fractunshqti (fract A)
- -- Runtime Function: unsigned char __fractunssqqi (long fract A)
- -- Runtime Function: unsigned short __fractunssqhi (long fract A)
- -- Runtime Function: unsigned int __fractunssqsi (long fract A)
- -- Runtime Function: unsigned long __fractunssqdi (long fract A)
- -- Runtime Function: unsigned long long __fractunssqti (long fract A)
- -- Runtime Function: unsigned char __fractunsdqqi (long long fract A)
- -- Runtime Function: unsigned short __fractunsdqhi (long long fract A)
- -- Runtime Function: unsigned int __fractunsdqsi (long long fract A)
- -- Runtime Function: unsigned long __fractunsdqdi (long long fract A)
- -- Runtime Function: unsigned long long __fractunsdqti (long long
- fract A)
- -- Runtime Function: unsigned char __fractunshaqi (short accum A)
- -- Runtime Function: unsigned short __fractunshahi (short accum A)
- -- Runtime Function: unsigned int __fractunshasi (short accum A)
- -- Runtime Function: unsigned long __fractunshadi (short accum A)
- -- Runtime Function: unsigned long long __fractunshati (short accum A)
- -- Runtime Function: unsigned char __fractunssaqi (accum A)
- -- Runtime Function: unsigned short __fractunssahi (accum A)
- -- Runtime Function: unsigned int __fractunssasi (accum A)
- -- Runtime Function: unsigned long __fractunssadi (accum A)
- -- Runtime Function: unsigned long long __fractunssati (accum A)
- -- Runtime Function: unsigned char __fractunsdaqi (long accum A)
- -- Runtime Function: unsigned short __fractunsdahi (long accum A)
- -- Runtime Function: unsigned int __fractunsdasi (long accum A)
- -- Runtime Function: unsigned long __fractunsdadi (long accum A)
- -- Runtime Function: unsigned long long __fractunsdati (long accum A)
- -- Runtime Function: unsigned char __fractunstaqi (long long accum A)
- -- Runtime Function: unsigned short __fractunstahi (long long accum A)
- -- Runtime Function: unsigned int __fractunstasi (long long accum A)
- -- Runtime Function: unsigned long __fractunstadi (long long accum A)
- -- Runtime Function: unsigned long long __fractunstati (long long
- accum A)
- -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short
- fract A)
- -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short
- fract A)
- -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short
- fract A)
- -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short
- fract A)
- -- Runtime Function: unsigned long long __fractunsuqqti (unsigned
- short fract A)
- -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A)
- -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A)
- -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A)
- -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A)
- -- Runtime Function: unsigned long long __fractunsuhqti (unsigned
- fract A)
- -- Runtime Function: unsigned char __fractunsusqqi (unsigned long
- fract A)
- -- Runtime Function: unsigned short __fractunsusqhi (unsigned long
- fract A)
- -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract
- A)
- -- Runtime Function: unsigned long __fractunsusqdi (unsigned long
- fract A)
- -- Runtime Function: unsigned long long __fractunsusqti (unsigned long
- fract A)
- -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long
- fract A)
- -- Runtime Function: unsigned short __fractunsudqhi (unsigned long
- long fract A)
- -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long
- fract A)
- -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long
- fract A)
- -- Runtime Function: unsigned long long __fractunsudqti (unsigned long
- long fract A)
- -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short
- accum A)
- -- Runtime Function: unsigned short __fractunsuhahi (unsigned short
- accum A)
- -- Runtime Function: unsigned int __fractunsuhasi (unsigned short
- accum A)
- -- Runtime Function: unsigned long __fractunsuhadi (unsigned short
- accum A)
- -- Runtime Function: unsigned long long __fractunsuhati (unsigned
- short accum A)
- -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A)
- -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A)
- -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A)
- -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A)
- -- Runtime Function: unsigned long long __fractunsusati (unsigned
- accum A)
- -- Runtime Function: unsigned char __fractunsudaqi (unsigned long
- accum A)
- -- Runtime Function: unsigned short __fractunsudahi (unsigned long
- accum A)
- -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum
- A)
- -- Runtime Function: unsigned long __fractunsudadi (unsigned long
- accum A)
- -- Runtime Function: unsigned long long __fractunsudati (unsigned long
- accum A)
- -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long
- accum A)
- -- Runtime Function: unsigned short __fractunsutahi (unsigned long
- long accum A)
- -- Runtime Function: unsigned int __fractunsutasi (unsigned long long
- accum A)
- -- Runtime Function: unsigned long __fractunsutadi (unsigned long long
- accum A)
- -- Runtime Function: unsigned long long __fractunsutati (unsigned long
- long accum A)
- -- Runtime Function: short fract __fractunsqiqq (unsigned char A)
- -- Runtime Function: fract __fractunsqihq (unsigned char A)
- -- Runtime Function: long fract __fractunsqisq (unsigned char A)
- -- Runtime Function: long long fract __fractunsqidq (unsigned char A)
- -- Runtime Function: short accum __fractunsqiha (unsigned char A)
- -- Runtime Function: accum __fractunsqisa (unsigned char A)
- -- Runtime Function: long accum __fractunsqida (unsigned char A)
- -- Runtime Function: long long accum __fractunsqita (unsigned char A)
- -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned
- char A)
- -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A)
- -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned
- char A)
- -- Runtime Function: unsigned long long fract __fractunsqiudq
- (unsigned char A)
- -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned
- char A)
- -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A)
- -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned
- char A)
- -- Runtime Function: unsigned long long accum __fractunsqiuta
- (unsigned char A)
- -- Runtime Function: short fract __fractunshiqq (unsigned short A)
- -- Runtime Function: fract __fractunshihq (unsigned short A)
- -- Runtime Function: long fract __fractunshisq (unsigned short A)
- -- Runtime Function: long long fract __fractunshidq (unsigned short A)
- -- Runtime Function: short accum __fractunshiha (unsigned short A)
- -- Runtime Function: accum __fractunshisa (unsigned short A)
- -- Runtime Function: long accum __fractunshida (unsigned short A)
- -- Runtime Function: long long accum __fractunshita (unsigned short A)
- -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned
- short A)
- -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A)
- -- Runtime Function: unsigned long fract __fractunshiusq (unsigned
- short A)
- -- Runtime Function: unsigned long long fract __fractunshiudq
- (unsigned short A)
- -- Runtime Function: unsigned short accum __fractunshiuha (unsigned
- short A)
- -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A)
- -- Runtime Function: unsigned long accum __fractunshiuda (unsigned
- short A)
- -- Runtime Function: unsigned long long accum __fractunshiuta
- (unsigned short A)
- -- Runtime Function: short fract __fractunssiqq (unsigned int A)
- -- Runtime Function: fract __fractunssihq (unsigned int A)
- -- Runtime Function: long fract __fractunssisq (unsigned int A)
- -- Runtime Function: long long fract __fractunssidq (unsigned int A)
- -- Runtime Function: short accum __fractunssiha (unsigned int A)
- -- Runtime Function: accum __fractunssisa (unsigned int A)
- -- Runtime Function: long accum __fractunssida (unsigned int A)
- -- Runtime Function: long long accum __fractunssita (unsigned int A)
- -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned
- int A)
- -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A)
- -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int
- A)
- -- Runtime Function: unsigned long long fract __fractunssiudq
- (unsigned int A)
- -- Runtime Function: unsigned short accum __fractunssiuha (unsigned
- int A)
- -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A)
- -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int
- A)
- -- Runtime Function: unsigned long long accum __fractunssiuta
- (unsigned int A)
- -- Runtime Function: short fract __fractunsdiqq (unsigned long A)
- -- Runtime Function: fract __fractunsdihq (unsigned long A)
- -- Runtime Function: long fract __fractunsdisq (unsigned long A)
- -- Runtime Function: long long fract __fractunsdidq (unsigned long A)
- -- Runtime Function: short accum __fractunsdiha (unsigned long A)
- -- Runtime Function: accum __fractunsdisa (unsigned long A)
- -- Runtime Function: long accum __fractunsdida (unsigned long A)
- -- Runtime Function: long long accum __fractunsdita (unsigned long A)
- -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned
- long A)
- -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A)
- -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned
- long A)
- -- Runtime Function: unsigned long long fract __fractunsdiudq
- (unsigned long A)
- -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned
- long A)
- -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A)
- -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned
- long A)
- -- Runtime Function: unsigned long long accum __fractunsdiuta
- (unsigned long A)
- -- Runtime Function: short fract __fractunstiqq (unsigned long long A)
- -- Runtime Function: fract __fractunstihq (unsigned long long A)
- -- Runtime Function: long fract __fractunstisq (unsigned long long A)
- -- Runtime Function: long long fract __fractunstidq (unsigned long
- long A)
- -- Runtime Function: short accum __fractunstiha (unsigned long long A)
- -- Runtime Function: accum __fractunstisa (unsigned long long A)
- -- Runtime Function: long accum __fractunstida (unsigned long long A)
- -- Runtime Function: long long accum __fractunstita (unsigned long
- long A)
- -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned
- long long A)
- -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long
- long A)
- -- Runtime Function: unsigned long fract __fractunstiusq (unsigned
- long long A)
- -- Runtime Function: unsigned long long fract __fractunstiudq
- (unsigned long long A)
- -- Runtime Function: unsigned short accum __fractunstiuha (unsigned
- long long A)
- -- Runtime Function: unsigned accum __fractunstiusa (unsigned long
- long A)
- -- Runtime Function: unsigned long accum __fractunstiuda (unsigned
- long long A)
- -- Runtime Function: unsigned long long accum __fractunstiuta
- (unsigned long long A)
- These functions convert from fractionals to unsigned
- non-fractionals; and from unsigned non-fractionals to fractionals,
- without saturation.
-
- -- Runtime Function: short fract __satfractunsqiqq (unsigned char A)
- -- Runtime Function: fract __satfractunsqihq (unsigned char A)
- -- Runtime Function: long fract __satfractunsqisq (unsigned char A)
- -- Runtime Function: long long fract __satfractunsqidq (unsigned char
- A)
- -- Runtime Function: short accum __satfractunsqiha (unsigned char A)
- -- Runtime Function: accum __satfractunsqisa (unsigned char A)
- -- Runtime Function: long accum __satfractunsqida (unsigned char A)
- -- Runtime Function: long long accum __satfractunsqita (unsigned char
- A)
- -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned
- char A)
- -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char
- A)
- -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned
- char A)
- -- Runtime Function: unsigned long long fract __satfractunsqiudq
- (unsigned char A)
- -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned
- char A)
- -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char
- A)
- -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned
- char A)
- -- Runtime Function: unsigned long long accum __satfractunsqiuta
- (unsigned char A)
- -- Runtime Function: short fract __satfractunshiqq (unsigned short A)
- -- Runtime Function: fract __satfractunshihq (unsigned short A)
- -- Runtime Function: long fract __satfractunshisq (unsigned short A)
- -- Runtime Function: long long fract __satfractunshidq (unsigned short
- A)
- -- Runtime Function: short accum __satfractunshiha (unsigned short A)
- -- Runtime Function: accum __satfractunshisa (unsigned short A)
- -- Runtime Function: long accum __satfractunshida (unsigned short A)
- -- Runtime Function: long long accum __satfractunshita (unsigned short
- A)
- -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned
- short A)
- -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short
- A)
- -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned
- short A)
- -- Runtime Function: unsigned long long fract __satfractunshiudq
- (unsigned short A)
- -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned
- short A)
- -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short
- A)
- -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned
- short A)
- -- Runtime Function: unsigned long long accum __satfractunshiuta
- (unsigned short A)
- -- Runtime Function: short fract __satfractunssiqq (unsigned int A)
- -- Runtime Function: fract __satfractunssihq (unsigned int A)
- -- Runtime Function: long fract __satfractunssisq (unsigned int A)
- -- Runtime Function: long long fract __satfractunssidq (unsigned int A)
- -- Runtime Function: short accum __satfractunssiha (unsigned int A)
- -- Runtime Function: accum __satfractunssisa (unsigned int A)
- -- Runtime Function: long accum __satfractunssida (unsigned int A)
- -- Runtime Function: long long accum __satfractunssita (unsigned int A)
- -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned
- int A)
- -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A)
- -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned
- int A)
- -- Runtime Function: unsigned long long fract __satfractunssiudq
- (unsigned int A)
- -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned
- int A)
- -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A)
- -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned
- int A)
- -- Runtime Function: unsigned long long accum __satfractunssiuta
- (unsigned int A)
- -- Runtime Function: short fract __satfractunsdiqq (unsigned long A)
- -- Runtime Function: fract __satfractunsdihq (unsigned long A)
- -- Runtime Function: long fract __satfractunsdisq (unsigned long A)
- -- Runtime Function: long long fract __satfractunsdidq (unsigned long
- A)
- -- Runtime Function: short accum __satfractunsdiha (unsigned long A)
- -- Runtime Function: accum __satfractunsdisa (unsigned long A)
- -- Runtime Function: long accum __satfractunsdida (unsigned long A)
- -- Runtime Function: long long accum __satfractunsdita (unsigned long
- A)
- -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned
- long A)
- -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long
- A)
- -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned
- long A)
- -- Runtime Function: unsigned long long fract __satfractunsdiudq
- (unsigned long A)
- -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned
- long A)
- -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long
- A)
- -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned
- long A)
- -- Runtime Function: unsigned long long accum __satfractunsdiuta
- (unsigned long A)
- -- Runtime Function: short fract __satfractunstiqq (unsigned long long
- A)
- -- Runtime Function: fract __satfractunstihq (unsigned long long A)
- -- Runtime Function: long fract __satfractunstisq (unsigned long long
- A)
- -- Runtime Function: long long fract __satfractunstidq (unsigned long
- long A)
- -- Runtime Function: short accum __satfractunstiha (unsigned long long
- A)
- -- Runtime Function: accum __satfractunstisa (unsigned long long A)
- -- Runtime Function: long accum __satfractunstida (unsigned long long
- A)
- -- Runtime Function: long long accum __satfractunstita (unsigned long
- long A)
- -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned
- long long A)
- -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long
- long A)
- -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned
- long long A)
- -- Runtime Function: unsigned long long fract __satfractunstiudq
- (unsigned long long A)
- -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned
- long long A)
- -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long
- long A)
- -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned
- long long A)
- -- Runtime Function: unsigned long long accum __satfractunstiuta
- (unsigned long long A)
- These functions convert from unsigned non-fractionals to
- fractionals, with saturation.
-
-
-File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Fixed-point fractional library routines, Up: Libgcc
-
-4.5 Language-independent routines for exception handling
-========================================================
-
-document me!
-
- _Unwind_DeleteException
- _Unwind_Find_FDE
- _Unwind_ForcedUnwind
- _Unwind_GetGR
- _Unwind_GetIP
- _Unwind_GetLanguageSpecificData
- _Unwind_GetRegionStart
- _Unwind_GetTextRelBase
- _Unwind_GetDataRelBase
- _Unwind_RaiseException
- _Unwind_Resume
- _Unwind_SetGR
- _Unwind_SetIP
- _Unwind_FindEnclosingFunction
- _Unwind_SjLj_Register
- _Unwind_SjLj_Unregister
- _Unwind_SjLj_RaiseException
- _Unwind_SjLj_ForcedUnwind
- _Unwind_SjLj_Resume
- __deregister_frame
- __deregister_frame_info
- __deregister_frame_info_bases
- __register_frame
- __register_frame_info
- __register_frame_info_bases
- __register_frame_info_table
- __register_frame_info_table_bases
- __register_frame_table
-
-
-File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc
-
-4.6 Miscellaneous runtime library routines
-==========================================
-
-4.6.1 Cache control functions
------------------------------
-
- -- Runtime Function: void __clear_cache (char *BEG, char *END)
- This function clears the instruction cache between BEG and END.
-
-4.6.2 Split stack functions and variables
------------------------------------------
-
- -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void
- *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void
- **INITIAL_SP)
- When using `-fsplit-stack', this call may be used to iterate over
- the stack segments. It may be called like this:
- void *next_segment = NULL;
- void *next_sp = NULL;
- void *initial_sp = NULL;
- void *stack;
- size_t stack_size;
- while ((stack = __splitstack_find (next_segment, next_sp,
- &stack_size, &next_segment,
- &next_sp, &initial_sp))
- != NULL)
- {
- /* Stack segment starts at stack and is
- stack_size bytes long. */
- }
-
- There is no way to iterate over the stack segments of a different
- thread. However, what is permitted is for one thread to call this
- with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT,
- NEXT_SP, and INITIAL_SP to a different thread, and then to suspend
- one way or another. A different thread may run the subsequent
- `__splitstack_find' iterations. Of course, this will only work if
- the first thread is suspended while the second thread is calling
- `__splitstack_find'. If not, the second thread could be looking
- at the stack while it is changing, and anything could happen.
-
- -- Variable: __morestack_segments
- -- Variable: __morestack_current_segment
- -- Variable: __morestack_initial_sp
- Internal variables used by the `-fsplit-stack' implementation.
-
-
-File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top
-
-5 Language Front Ends in GCC
-****************************
-
-The interface to front ends for languages in GCC, and in particular the
-`tree' structure (*note GENERIC::), was initially designed for C, and
-many aspects of it are still somewhat biased towards C and C-like
-languages. It is, however, reasonably well suited to other procedural
-languages, and front ends for many such languages have been written for
-GCC.
-
- Writing a compiler as a front end for GCC, rather than compiling
-directly to assembler or generating C code which is then compiled by
-GCC, has several advantages:
-
- * GCC front ends benefit from the support for many different target
- machines already present in GCC.
-
- * GCC front ends benefit from all the optimizations in GCC. Some of
- these, such as alias analysis, may work better when GCC is
- compiling directly from source code then when it is compiling from
- generated C code.
-
- * Better debugging information is generated when compiling directly
- from source code than when going via intermediate generated C code.
-
- Because of the advantages of writing a compiler as a GCC front end,
-GCC front ends have also been created for languages very different from
-those for which GCC was designed, such as the declarative
-logic/functional language Mercury. For these reasons, it may also be
-useful to implement compilers created for specialized purposes (for
-example, as part of a research project) as GCC front ends.
-
-
-File: gccint.info, Node: Source Tree, Next: Testsuites, Prev: Languages, Up: Top
-
-6 Source Tree Structure and Build System
-****************************************
-
-This chapter describes the structure of the GCC source tree, and how
-GCC is built. The user documentation for building and installing GCC
-is in a separate manual (`http://gcc.gnu.org/install/'), with which it
-is presumed that you are familiar.
-
-* Menu:
-
-* Configure Terms:: Configuration terminology and history.
-* Top Level:: The top level source directory.
-* gcc Directory:: The `gcc' subdirectory.
-
-
-File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree
-
-6.1 Configure Terms and History
-===============================
-
-The configure and build process has a long and colorful history, and can
-be confusing to anyone who doesn't know why things are the way they are.
-While there are other documents which describe the configuration process
-in detail, here are a few things that everyone working on GCC should
-know.
-
- There are three system names that the build knows about: the machine
-you are building on ("build"), the machine that you are building for
-("host"), and the machine that GCC will produce code for ("target").
-When you configure GCC, you specify these with `--build=', `--host=',
-and `--target='.
-
- Specifying the host without specifying the build should be avoided, as
-`configure' may (and once did) assume that the host you specify is also
-the build, which may not be true.
-
- If build, host, and target are all the same, this is called a
-"native". If build and host are the same but target is different, this
-is called a "cross". If build, host, and target are all different this
-is called a "canadian" (for obscure reasons dealing with Canada's
-political party and the background of the person working on the build
-at that time). If host and target are the same, but build is
-different, you are using a cross-compiler to build a native for a
-different system. Some people call this a "host-x-host", "crossed
-native", or "cross-built native". If build and target are the same,
-but host is different, you are using a cross compiler to build a cross
-compiler that produces code for the machine you're building on. This
-is rare, so there is no common way of describing it. There is a
-proposal to call this a "crossback".
-
- If build and host are the same, the GCC you are building will also be
-used to build the target libraries (like `libstdc++'). If build and
-host are different, you must have already built and installed a cross
-compiler that will be used to build the target libraries (if you
-configured with `--target=foo-bar', this compiler will be called
-`foo-bar-gcc').
-
- In the case of target libraries, the machine you're building for is the
-machine you specified with `--target'. So, build is the machine you're
-building on (no change there), host is the machine you're building for
-(the target libraries are built for the target, so host is the target
-you specified), and target doesn't apply (because you're not building a
-compiler, you're building libraries). The configure/make process will
-adjust these variables as needed. It also sets `$with_cross_host' to
-the original `--host' value in case you need it.
-
- The `libiberty' support library is built up to three times: once for
-the host, once for the target (even if they are the same), and once for
-the build if build and host are different. This allows it to be used
-by all programs which are generated in the course of the build process.
-
-
-File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree
-
-6.2 Top Level Source Directory
-==============================
-
-The top level source directory in a GCC distribution contains several
-files and directories that are shared with other software distributions
-such as that of GNU Binutils. It also contains several subdirectories
-that contain parts of GCC and its runtime libraries:
-
-`boehm-gc'
- The Boehm conservative garbage collector, used as part of the Java
- runtime library.
-
-`config'
- Autoconf macros and Makefile fragments used throughout the tree.
-
-`contrib'
- Contributed scripts that may be found useful in conjunction with
- GCC. One of these, `contrib/texi2pod.pl', is used to generate man
- pages from Texinfo manuals as part of the GCC build process.
-
-`fixincludes'
- The support for fixing system headers to work with GCC. See
- `fixincludes/README' for more information. The headers fixed by
- this mechanism are installed in `LIBSUBDIR/include-fixed'. Along
- with those headers, `README-fixinc' is also installed, as
- `LIBSUBDIR/include-fixed/README'.
-
-`gcc'
- The main sources of GCC itself (except for runtime libraries),
- including optimizers, support for different target architectures,
- language front ends, and testsuites. *Note The `gcc'
- Subdirectory: gcc Directory, for details.
-
-`gnattools'
- Support tools for GNAT.
-
-`include'
- Headers for the `libiberty' library.
-
-`intl'
- GNU `libintl', from GNU `gettext', for systems which do not
- include it in `libc'.
-
-`libada'
- The Ada runtime library.
-
-`libcpp'
- The C preprocessor library.
-
-`libdecnumber'
- The Decimal Float support library.
-
-`libffi'
- The `libffi' library, used as part of the Java runtime library.
-
-`libgcc'
- The GCC runtime library.
-
-`libgfortran'
- The Fortran runtime library.
-
-`libgo'
- The Go runtime library. The bulk of this library is mirrored from
- the master Go repository (http://code.google.com/p/go/).
-
-`libgomp'
- The GNU OpenMP runtime library.
-
-`libiberty'
- The `libiberty' library, used for portability and for some
- generally useful data structures and algorithms. *Note
- Introduction: (libiberty)Top, for more information about this
- library.
-
-`libjava'
- The Java runtime library.
-
-`libmudflap'
- The `libmudflap' library, used for instrumenting pointer and array
- dereferencing operations.
-
-`libobjc'
- The Objective-C and Objective-C++ runtime library.
-
-`libssp'
- The Stack protector runtime library.
-
-`libstdc++-v3'
- The C++ runtime library.
-
-`lto-plugin'
- Plugin used by `gold' if link-time optimizations are enabled.
-
-`maintainer-scripts'
- Scripts used by the `gccadmin' account on `gcc.gnu.org'.
-
-`zlib'
- The `zlib' compression library, used by the Java front end, as
- part of the Java runtime library, and for compressing and
- uncompressing GCC's intermediate language in LTO object files.
-
- The build system in the top level directory, including how recursion
-into subdirectories works and how building runtime libraries for
-multilibs is handled, is documented in a separate manual, included with
-GNU Binutils. *Note GNU configure and build system: (configure)Top,
-for details.
-
-
-File: gccint.info, Node: gcc Directory, Prev: Top Level, Up: Source Tree
-
-6.3 The `gcc' Subdirectory
-==========================
-
-The `gcc' directory contains many files that are part of the C sources
-of GCC, other files used as part of the configuration and build
-process, and subdirectories including documentation and a testsuite.
-The files that are sources of GCC are documented in a separate chapter.
-*Note Passes and Files of the Compiler: Passes.
-
-* Menu:
-
-* Subdirectories:: Subdirectories of `gcc'.
-* Configuration:: The configuration process, and the files it uses.
-* Build:: The build system in the `gcc' directory.
-* Makefile:: Targets in `gcc/Makefile'.
-* Library Files:: Library source files and headers under `gcc/'.
-* Headers:: Headers installed by GCC.
-* Documentation:: Building documentation in GCC.
-* Front End:: Anatomy of a language front end.
-* Back End:: Anatomy of a target back end.
-
-
-File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory
-
-6.3.1 Subdirectories of `gcc'
------------------------------
-
-The `gcc' directory contains the following subdirectories:
-
-`LANGUAGE'
- Subdirectories for various languages. Directories containing a
- file `config-lang.in' are language subdirectories. The contents of
- the subdirectories `cp' (for C++), `lto' (for LTO), `objc' (for
- Objective-C) and `objcp' (for Objective-C++) are documented in
- this manual (*note Passes and Files of the Compiler: Passes.);
- those for other languages are not. *Note Anatomy of a Language
- Front End: Front End, for details of the files in these
- directories.
-
-`config'
- Configuration files for supported architectures and operating
- systems. *Note Anatomy of a Target Back End: Back End, for
- details of the files in this directory.
-
-`doc'
- Texinfo documentation for GCC, together with automatically
- generated man pages and support for converting the installation
- manual to HTML. *Note Documentation::.
-
-`ginclude'
- System headers installed by GCC, mainly those required by the C
- standard of freestanding implementations. *Note Headers Installed
- by GCC: Headers, for details of when these and other headers are
- installed.
-
-`po'
- Message catalogs with translations of messages produced by GCC into
- various languages, `LANGUAGE.po'. This directory also contains
- `gcc.pot', the template for these message catalogues, `exgettext',
- a wrapper around `gettext' to extract the messages from the GCC
- sources and create `gcc.pot', which is run by `make gcc.pot', and
- `EXCLUDES', a list of files from which messages should not be
- extracted.
-
-`testsuite'
- The GCC testsuites (except for those for runtime libraries).
- *Note Testsuites::.
-
-
-File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory
-
-6.3.2 Configuration in the `gcc' Directory
-------------------------------------------
-
-The `gcc' directory is configured with an Autoconf-generated script
-`configure'. The `configure' script is generated from `configure.ac'
-and `aclocal.m4'. From the files `configure.ac' and `acconfig.h',
-Autoheader generates the file `config.in'. The file `cstamp-h.in' is
-used as a timestamp.
-
-* Menu:
-
-* Config Fragments:: Scripts used by `configure'.
-* System Config:: The `config.build', `config.host', and
- `config.gcc' files.
-* Configuration Files:: Files created by running `configure'.
-
-
-File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration
-
-6.3.2.1 Scripts Used by `configure'
-...................................
-
-`configure' uses some other scripts to help in its work:
-
- * The standard GNU `config.sub' and `config.guess' files, kept in
- the top level directory, are used.
-
- * The file `config.gcc' is used to handle configuration specific to
- the particular target machine. The file `config.build' is used to
- handle configuration specific to the particular build machine.
- The file `config.host' is used to handle configuration specific to
- the particular host machine. (In general, these should only be
- used for features that cannot reasonably be tested in Autoconf
- feature tests.) *Note The `config.build'; `config.host'; and
- `config.gcc' Files: System Config, for details of the contents of
- these files.
-
- * Each language subdirectory has a file `LANGUAGE/config-lang.in'
- that is used for front-end-specific configuration. *Note The
- Front End `config-lang.in' File: Front End Config, for details of
- this file.
-
- * A helper script `configure.frag' is used as part of creating the
- output of `configure'.
-
-
-File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration
-
-6.3.2.2 The `config.build'; `config.host'; and `config.gcc' Files
-.................................................................
-
-The `config.build' file contains specific rules for particular systems
-which GCC is built on. This should be used as rarely as possible, as
-the behavior of the build system can always be detected by autoconf.
-
- The `config.host' file contains specific rules for particular systems
-which GCC will run on. This is rarely needed.
-
- The `config.gcc' file contains specific rules for particular systems
-which GCC will generate code for. This is usually needed.
-
- Each file has a list of the shell variables it sets, with
-descriptions, at the top of the file.
-
- FIXME: document the contents of these files, and what variables should
-be set to control build, host and target configuration.
-
-
-File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration
-
-6.3.2.3 Files Created by `configure'
-....................................
-
-Here we spell out what files will be set up by `configure' in the `gcc'
-directory. Some other files are created as temporary files in the
-configuration process, and are not used in the subsequent build; these
-are not documented.
-
- * `Makefile' is constructed from `Makefile.in', together with the
- host and target fragments (*note Makefile Fragments: Fragments.)
- `t-TARGET' and `x-HOST' from `config', if any, and language
- Makefile fragments `LANGUAGE/Make-lang.in'.
-
- * `auto-host.h' contains information about the host machine
- determined by `configure'. If the host machine is different from
- the build machine, then `auto-build.h' is also created, containing
- such information about the build machine.
-
- * `config.status' is a script that may be run to recreate the
- current configuration.
-
- * `configargs.h' is a header containing details of the arguments
- passed to `configure' to configure GCC, and of the thread model
- used.
-
- * `cstamp-h' is used as a timestamp.
-
- * If a language `config-lang.in' file (*note The Front End
- `config-lang.in' File: Front End Config.) sets `outputs', then the
- files listed in `outputs' there are also generated.
-
- The following configuration headers are created from the Makefile,
-using `mkconfig.sh', rather than directly by `configure'. `config.h',
-`bconfig.h' and `tconfig.h' all contain the `xm-MACHINE.h' header, if
-any, appropriate to the host, build and target machines respectively,
-the configuration headers for the target, and some definitions; for the
-host and build machines, these include the autoconfigured headers
-generated by `configure'. The other configuration headers are
-determined by `config.gcc'. They also contain the typedefs for `rtx',
-`rtvec' and `tree'.
-
- * `config.h', for use in programs that run on the host machine.
-
- * `bconfig.h', for use in programs that run on the build machine.
-
- * `tconfig.h', for use in programs and libraries for the target
- machine.
-
- * `tm_p.h', which includes the header `MACHINE-protos.h' that
- contains prototypes for functions in the target `.c' file. FIXME:
- why is such a separate header necessary?
-
-
-File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory
-
-6.3.3 Build System in the `gcc' Directory
------------------------------------------
-
-FIXME: describe the build system, including what is built in what
-stages. Also list the various source files that are used in the build
-process but aren't source files of GCC itself and so aren't documented
-below (*note Passes::).
-
-
-File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory
-
-6.3.4 Makefile Targets
-----------------------
-
-These targets are available from the `gcc' directory:
-
-`all'
- This is the default target. Depending on what your
- build/host/target configuration is, it coordinates all the things
- that need to be built.
-
-`doc'
- Produce info-formatted documentation and man pages. Essentially it
- calls `make man' and `make info'.
-
-`dvi'
- Produce DVI-formatted documentation.
-
-`pdf'
- Produce PDF-formatted documentation.
-
-`html'
- Produce HTML-formatted documentation.
-
-`man'
- Generate man pages.
-
-`info'
- Generate info-formatted pages.
-
-`mostlyclean'
- Delete the files made while building the compiler.
-
-`clean'
- That, and all the other files built by `make all'.
-
-`distclean'
- That, and all the files created by `configure'.
-
-`maintainer-clean'
- Distclean plus any file that can be generated from other files.
- Note that additional tools may be required beyond what is normally
- needed to build GCC.
-
-`srcextra'
- Generates files in the source directory that are not
- version-controlled but should go into a release tarball.
-
-`srcinfo'
-`srcman'
- Copies the info-formatted and manpage documentation into the source
- directory usually for the purpose of generating a release tarball.
-
-`install'
- Installs GCC.
-
-`uninstall'
- Deletes installed files, though this is not supported.
-
-`check'
- Run the testsuite. This creates a `testsuite' subdirectory that
- has various `.sum' and `.log' files containing the results of the
- testing. You can run subsets with, for example, `make check-gcc'.
- You can specify specific tests by setting `RUNTESTFLAGS' to be the
- name of the `.exp' file, optionally followed by (for some tests)
- an equals and a file wildcard, like:
-
- make check-gcc RUNTESTFLAGS="execute.exp=19980413-*"
-
- Note that running the testsuite may require additional tools be
- installed, such as Tcl or DejaGnu.
-
- The toplevel tree from which you start GCC compilation is not the GCC
-directory, but rather a complex Makefile that coordinates the various
-steps of the build, including bootstrapping the compiler and using the
-new compiler to build target libraries.
-
- When GCC is configured for a native configuration, the default action
-for `make' is to do a full three-stage bootstrap. This means that GCC
-is built three times--once with the native compiler, once with the
-native-built compiler it just built, and once with the compiler it
-built the second time. In theory, the last two should produce the same
-results, which `make compare' can check. Each stage is configured
-separately and compiled into a separate directory, to minimize problems
-due to ABI incompatibilities between the native compiler and GCC.
-
- If you do a change, rebuilding will also start from the first stage
-and "bubble" up the change through the three stages. Each stage is
-taken from its build directory (if it had been built previously),
-rebuilt, and copied to its subdirectory. This will allow you to, for
-example, continue a bootstrap after fixing a bug which causes the
-stage2 build to crash. It does not provide as good coverage of the
-compiler as bootstrapping from scratch, but it ensures that the new
-code is syntactically correct (e.g., that you did not use GCC extensions
-by mistake), and avoids spurious bootstrap comparison failures(1).
-
- Other targets available from the top level include:
-
-`bootstrap-lean'
- Like `bootstrap', except that the various stages are removed once
- they're no longer needed. This saves disk space.
-
-`bootstrap2'
-`bootstrap2-lean'
- Performs only the first two stages of bootstrap. Unlike a
- three-stage bootstrap, this does not perform a comparison to test
- that the compiler is running properly. Note that the disk space
- required by a "lean" bootstrap is approximately independent of the
- number of stages.
-
-`stageN-bubble (N = 1...4, profile, feedback)'
- Rebuild all the stages up to N, with the appropriate flags,
- "bubbling" the changes as described above.
-
-`all-stageN (N = 1...4, profile, feedback)'
- Assuming that stage N has already been built, rebuild it with the
- appropriate flags. This is rarely needed.
-
-`cleanstrap'
- Remove everything (`make clean') and rebuilds (`make bootstrap').
-
-`compare'
- Compares the results of stages 2 and 3. This ensures that the
- compiler is running properly, since it should produce the same
- object files regardless of how it itself was compiled.
-
-`profiledbootstrap'
- Builds a compiler with profiling feedback information. In this
- case, the second and third stages are named `profile' and
- `feedback', respectively. For more information, see *note
- Building with profile feedback: (gccinstall)Building.
-
-`restrap'
- Restart a bootstrap, so that everything that was not built with
- the system compiler is rebuilt.
-
-`stageN-start (N = 1...4, profile, feedback)'
- For each package that is bootstrapped, rename directories so that,
- for example, `gcc' points to the stageN GCC, compiled with the
- stageN-1 GCC(2).
-
- You will invoke this target if you need to test or debug the
- stageN GCC. If you only need to execute GCC (but you need not run
- `make' either to rebuild it or to run test suites), you should be
- able to work directly in the `stageN-gcc' directory. This makes
- it easier to debug multiple stages in parallel.
-
-`stage'
- For each package that is bootstrapped, relocate its build directory
- to indicate its stage. For example, if the `gcc' directory points
- to the stage2 GCC, after invoking this target it will be renamed
- to `stage2-gcc'.
-
-
- If you wish to use non-default GCC flags when compiling the stage2 and
-stage3 compilers, set `BOOT_CFLAGS' on the command line when doing
-`make'.
-
- Usually, the first stage only builds the languages that the compiler
-is written in: typically, C and maybe Ada. If you are debugging a
-miscompilation of a different stage2 front-end (for example, of the
-Fortran front-end), you may want to have front-ends for other languages
-in the first stage as well. To do so, set `STAGE1_LANGUAGES' on the
-command line when doing `make'.
-
- For example, in the aforementioned scenario of debugging a Fortran
-front-end miscompilation caused by the stage1 compiler, you may need a
-command like
-
- make stage2-bubble STAGE1_LANGUAGES=c,fortran
-
- Alternatively, you can use per-language targets to build and test
-languages that are not enabled by default in stage1. For example,
-`make f951' will build a Fortran compiler even in the stage1 build
-directory.
-
- ---------- Footnotes ----------
-
- (1) Except if the compiler was buggy and miscompiled some of the files
-that were not modified. In this case, it's best to use `make restrap'.
-
- (2) Customarily, the system compiler is also termed the `stage0' GCC.
-
-
-File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory
-
-6.3.5 Library Source Files and Headers under the `gcc' Directory
-----------------------------------------------------------------
-
-FIXME: list here, with explanation, all the C source files and headers
-under the `gcc' directory that aren't built into the GCC executable but
-rather are part of runtime libraries and object files, such as
-`crtstuff.c' and `unwind-dw2.c'. *Note Headers Installed by GCC:
-Headers, for more information about the `ginclude' directory.
-
-
-File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory
-
-6.3.6 Headers Installed by GCC
-------------------------------
-
-In general, GCC expects the system C library to provide most of the
-headers to be used with it. However, GCC will fix those headers if
-necessary to make them work with GCC, and will install some headers
-required of freestanding implementations. These headers are installed
-in `LIBSUBDIR/include'. Headers for non-C runtime libraries are also
-installed by GCC; these are not documented here. (FIXME: document them
-somewhere.)
-
- Several of the headers GCC installs are in the `ginclude' directory.
-These headers, `iso646.h', `stdarg.h', `stdbool.h', and `stddef.h', are
-installed in `LIBSUBDIR/include', unless the target Makefile fragment
-(*note Target Fragment::) overrides this by setting `USER_H'.
-
- In addition to these headers and those generated by fixing system
-headers to work with GCC, some other headers may also be installed in
-`LIBSUBDIR/include'. `config.gcc' may set `extra_headers'; this
-specifies additional headers under `config' to be installed on some
-systems.
-
- GCC installs its own version of `<float.h>', from `ginclude/float.h'.
-This is done to cope with command-line options that change the
-representation of floating point numbers.
-
- GCC also installs its own version of `<limits.h>'; this is generated
-from `glimits.h', together with `limitx.h' and `limity.h' if the system
-also has its own version of `<limits.h>'. (GCC provides its own header
-because it is required of ISO C freestanding implementations, but needs
-to include the system header from its own header as well because other
-standards such as POSIX specify additional values to be defined in
-`<limits.h>'.) The system's `<limits.h>' header is used via
-`LIBSUBDIR/include/syslimits.h', which is copied from `gsyslimits.h' if
-it does not need fixing to work with GCC; if it needs fixing,
-`syslimits.h' is the fixed copy.
-
- GCC can also install `<tgmath.h>'. It will do this when `config.gcc'
-sets `use_gcc_tgmath' to `yes'.
-
-
-File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory
-
-6.3.7 Building Documentation
-----------------------------
-
-The main GCC documentation is in the form of manuals in Texinfo format.
-These are installed in Info format; DVI versions may be generated by
-`make dvi', PDF versions by `make pdf', and HTML versions by `make
-html'. In addition, some man pages are generated from the Texinfo
-manuals, there are some other text files with miscellaneous
-documentation, and runtime libraries have their own documentation
-outside the `gcc' directory. FIXME: document the documentation for
-runtime libraries somewhere.
-
-* Menu:
-
-* Texinfo Manuals:: GCC manuals in Texinfo format.
-* Man Page Generation:: Generating man pages from Texinfo manuals.
-* Miscellaneous Docs:: Miscellaneous text files with documentation.
-
-
-File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation
-
-6.3.7.1 Texinfo Manuals
-.......................
-
-The manuals for GCC as a whole, and the C and C++ front ends, are in
-files `doc/*.texi'. Other front ends have their own manuals in files
-`LANGUAGE/*.texi'. Common files `doc/include/*.texi' are provided
-which may be included in multiple manuals; the following files are in
-`doc/include':
-
-`fdl.texi'
- The GNU Free Documentation License.
-
-`funding.texi'
- The section "Funding Free Software".
-
-`gcc-common.texi'
- Common definitions for manuals.
-
-`gpl.texi'
-`gpl_v3.texi'
- The GNU General Public License.
-
-`texinfo.tex'
- A copy of `texinfo.tex' known to work with the GCC manuals.
-
- DVI-formatted manuals are generated by `make dvi', which uses
-`texi2dvi' (via the Makefile macro `$(TEXI2DVI)'). PDF-formatted
-manuals are generated by `make pdf', which uses `texi2pdf' (via the
-Makefile macro `$(TEXI2PDF)'). HTML formatted manuals are generated by
-`make html'. Info manuals are generated by `make info' (which is run
-as part of a bootstrap); this generates the manuals in the source
-directory, using `makeinfo' via the Makefile macro `$(MAKEINFO)', and
-they are included in release distributions.
-
- Manuals are also provided on the GCC web site, in both HTML and
-PostScript forms. This is done via the script
-`maintainer-scripts/update_web_docs_svn'. Each manual to be provided
-online must be listed in the definition of `MANUALS' in that file; a
-file `NAME.texi' must only appear once in the source tree, and the
-output manual must have the same name as the source file. (However,
-other Texinfo files, included in manuals but not themselves the root
-files of manuals, may have names that appear more than once in the
-source tree.) The manual file `NAME.texi' should only include other
-files in its own directory or in `doc/include'. HTML manuals will be
-generated by `makeinfo --html', PostScript manuals by `texi2dvi' and
-`dvips', and PDF manuals by `texi2pdf'. All Texinfo files that are
-parts of manuals must be version-controlled, even if they are generated
-files, for the generation of online manuals to work.
-
- The installation manual, `doc/install.texi', is also provided on the
-GCC web site. The HTML version is generated by the script
-`doc/install.texi2html'.
-
-
-File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation
-
-6.3.7.2 Man Page Generation
-...........................
-
-Because of user demand, in addition to full Texinfo manuals, man pages
-are provided which contain extracts from those manuals. These man
-pages are generated from the Texinfo manuals using
-`contrib/texi2pod.pl' and `pod2man'. (The man page for `g++',
-`cp/g++.1', just contains a `.so' reference to `gcc.1', but all the
-other man pages are generated from Texinfo manuals.)
-
- Because many systems may not have the necessary tools installed to
-generate the man pages, they are only generated if the `configure'
-script detects that recent enough tools are installed, and the
-Makefiles allow generating man pages to fail without aborting the
-build. Man pages are also included in release distributions. They are
-generated in the source directory.
-
- Magic comments in Texinfo files starting `@c man' control what parts
-of a Texinfo file go into a man page. Only a subset of Texinfo is
-supported by `texi2pod.pl', and it may be necessary to add support for
-more Texinfo features to this script when generating new man pages. To
-improve the man page output, some special Texinfo macros are provided
-in `doc/include/gcc-common.texi' which `texi2pod.pl' understands:
-
-`@gcctabopt'
- Use in the form `@table @gcctabopt' for tables of options, where
- for printed output the effect of `@code' is better than that of
- `@option' but for man page output a different effect is wanted.
-
-`@gccoptlist'
- Use for summary lists of options in manuals.
-
-`@gol'
- Use at the end of each line inside `@gccoptlist'. This is
- necessary to avoid problems with differences in how the
- `@gccoptlist' macro is handled by different Texinfo formatters.
-
- FIXME: describe the `texi2pod.pl' input language and magic comments in
-more detail.
-
-
-File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation
-
-6.3.7.3 Miscellaneous Documentation
-...................................
-
-In addition to the formal documentation that is installed by GCC, there
-are several other text files in the `gcc' subdirectory with
-miscellaneous documentation:
-
-`ABOUT-GCC-NLS'
- Notes on GCC's Native Language Support. FIXME: this should be
- part of this manual rather than a separate file.
-
-`ABOUT-NLS'
- Notes on the Free Translation Project.
-
-`COPYING'
-`COPYING3'
- The GNU General Public License, Versions 2 and 3.
-
-`COPYING.LIB'
-`COPYING3.LIB'
- The GNU Lesser General Public License, Versions 2.1 and 3.
-
-`*ChangeLog*'
-`*/ChangeLog*'
- Change log files for various parts of GCC.
-
-`LANGUAGES'
- Details of a few changes to the GCC front-end interface. FIXME:
- the information in this file should be part of general
- documentation of the front-end interface in this manual.
-
-`ONEWS'
- Information about new features in old versions of GCC. (For recent
- versions, the information is on the GCC web site.)
-
-`README.Portability'
- Information about portability issues when writing code in GCC.
- FIXME: why isn't this part of this manual or of the GCC Coding
- Conventions?
-
- FIXME: document such files in subdirectories, at least `config', `cp',
-`objc', `testsuite'.
-
-
-File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory
-
-6.3.8 Anatomy of a Language Front End
--------------------------------------
-
-A front end for a language in GCC has the following parts:
-
- * A directory `LANGUAGE' under `gcc' containing source files for
- that front end. *Note The Front End `LANGUAGE' Directory: Front
- End Directory, for details.
-
- * A mention of the language in the list of supported languages in
- `gcc/doc/install.texi'.
-
- * A mention of the name under which the language's runtime library is
- recognized by `--enable-shared=PACKAGE' in the documentation of
- that option in `gcc/doc/install.texi'.
-
- * A mention of any special prerequisites for building the front end
- in the documentation of prerequisites in `gcc/doc/install.texi'.
-
- * Details of contributors to that front end in
- `gcc/doc/contrib.texi'. If the details are in that front end's
- own manual then there should be a link to that manual's list in
- `contrib.texi'.
-
- * Information about support for that language in
- `gcc/doc/frontends.texi'.
-
- * Information about standards for that language, and the front end's
- support for them, in `gcc/doc/standards.texi'. This may be a link
- to such information in the front end's own manual.
-
- * Details of source file suffixes for that language and `-x LANG'
- options supported, in `gcc/doc/invoke.texi'.
-
- * Entries in `default_compilers' in `gcc.c' for source file suffixes
- for that language.
-
- * Preferably testsuites, which may be under `gcc/testsuite' or
- runtime library directories. FIXME: document somewhere how to
- write testsuite harnesses.
-
- * Probably a runtime library for the language, outside the `gcc'
- directory. FIXME: document this further.
-
- * Details of the directories of any runtime libraries in
- `gcc/doc/sourcebuild.texi'.
-
- * Check targets in `Makefile.def' for the top-level `Makefile' to
- check just the compiler or the compiler and runtime library for the
- language.
-
- If the front end is added to the official GCC source repository, the
-following are also necessary:
-
- * At least one Bugzilla component for bugs in that front end and
- runtime libraries. This category needs to be added to the
- Bugzilla database.
-
- * Normally, one or more maintainers of that front end listed in
- `MAINTAINERS'.
-
- * Mentions on the GCC web site in `index.html' and `frontends.html',
- with any relevant links on `readings.html'. (Front ends that are
- not an official part of GCC may also be listed on
- `frontends.html', with relevant links.)
-
- * A news item on `index.html', and possibly an announcement on the
- <gcc-announce@gcc.gnu.org> mailing list.
-
- * The front end's manuals should be mentioned in
- `maintainer-scripts/update_web_docs_svn' (*note Texinfo Manuals::)
- and the online manuals should be linked to from
- `onlinedocs/index.html'.
-
- * Any old releases or CVS repositories of the front end, before its
- inclusion in GCC, should be made available on the GCC FTP site
- `ftp://gcc.gnu.org/pub/gcc/old-releases/'.
-
- * The release and snapshot script `maintainer-scripts/gcc_release'
- should be updated to generate appropriate tarballs for this front
- end.
-
- * If this front end includes its own version files that include the
- current date, `maintainer-scripts/update_version' should be
- updated accordingly.
-
-* Menu:
-
-* Front End Directory:: The front end `LANGUAGE' directory.
-* Front End Config:: The front end `config-lang.in' file.
-* Front End Makefile:: The front end `Make-lang.in' file.
-
-
-File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End
-
-6.3.8.1 The Front End `LANGUAGE' Directory
-..........................................
-
-A front end `LANGUAGE' directory contains the source files of that
-front end (but not of any runtime libraries, which should be outside
-the `gcc' directory). This includes documentation, and possibly some
-subsidiary programs built alongside the front end. Certain files are
-special and other parts of the compiler depend on their names:
-
-`config-lang.in'
- This file is required in all language subdirectories. *Note The
- Front End `config-lang.in' File: Front End Config, for details of
- its contents
-
-`Make-lang.in'
- This file is required in all language subdirectories. *Note The
- Front End `Make-lang.in' File: Front End Makefile, for details of
- its contents.
-
-`lang.opt'
- This file registers the set of switches that the front end accepts
- on the command line, and their `--help' text. *Note Options::.
-
-`lang-specs.h'
- This file provides entries for `default_compilers' in `gcc.c'
- which override the default of giving an error that a compiler for
- that language is not installed.
-
-`LANGUAGE-tree.def'
- This file, which need not exist, defines any language-specific tree
- codes.
-
-
-File: gccint.info, Node: Front End Config, Next: Front End Makefile, Prev: Front End Directory, Up: Front End
-
-6.3.8.2 The Front End `config-lang.in' File
-...........................................
-
-Each language subdirectory contains a `config-lang.in' file. In
-addition the main directory contains `c-config-lang.in', which contains
-limited information for the C language. This file is a shell script
-that may define some variables describing the language:
-
-`language'
- This definition must be present, and gives the name of the language
- for some purposes such as arguments to `--enable-languages'.
-
-`lang_requires'
- If defined, this variable lists (space-separated) language front
- ends other than C that this front end requires to be enabled (with
- the names given being their `language' settings). For example, the
- Java front end depends on the C++ front end, so sets
- `lang_requires=c++'.
-
-`subdir_requires'
- If defined, this variable lists (space-separated) front end
- directories other than C that this front end requires to be
- present. For example, the Objective-C++ front end uses source
- files from the C++ and Objective-C front ends, so sets
- `subdir_requires="cp objc"'.
-
-`target_libs'
- If defined, this variable lists (space-separated) targets in the
- top level `Makefile' to build the runtime libraries for this
- language, such as `target-libobjc'.
-
-`lang_dirs'
- If defined, this variable lists (space-separated) top level
- directories (parallel to `gcc'), apart from the runtime libraries,
- that should not be configured if this front end is not built.
-
-`build_by_default'
- If defined to `no', this language front end is not built unless
- enabled in a `--enable-languages' argument. Otherwise, front ends
- are built by default, subject to any special logic in
- `configure.ac' (as is present to disable the Ada front end if the
- Ada compiler is not already installed).
-
-`boot_language'
- If defined to `yes', this front end is built in stage1 of the
- bootstrap. This is only relevant to front ends written in their
- own languages.
-
-`compilers'
- If defined, a space-separated list of compiler executables that
- will be run by the driver. The names here will each end with
- `\$(exeext)'.
-
-`outputs'
- If defined, a space-separated list of files that should be
- generated by `configure' substituting values in them. This
- mechanism can be used to create a file `LANGUAGE/Makefile' from
- `LANGUAGE/Makefile.in', but this is deprecated, building
- everything from the single `gcc/Makefile' is preferred.
-
-`gtfiles'
- If defined, a space-separated list of files that should be scanned
- by `gengtype.c' to generate the garbage collection tables and
- routines for this language. This excludes the files that are
- common to all front ends. *Note Type Information::.
-
-
-
-File: gccint.info, Node: Front End Makefile, Prev: Front End Config, Up: Front End
-
-6.3.8.3 The Front End `Make-lang.in' File
-.........................................
-
-Each language subdirectory contains a `Make-lang.in' file. It contains
-targets `LANG.HOOK' (where `LANG' is the setting of `language' in
-`config-lang.in') for the following values of `HOOK', and any other
-Makefile rules required to build those targets (which may if necessary
-use other Makefiles specified in `outputs' in `config-lang.in',
-although this is deprecated). It also adds any testsuite targets that
-can use the standard rule in `gcc/Makefile.in' to the variable
-`lang_checks'.
-
-`all.cross'
-`start.encap'
-`rest.encap'
- FIXME: exactly what goes in each of these targets?
-
-`tags'
- Build an `etags' `TAGS' file in the language subdirectory in the
- source tree.
-
-`info'
- Build info documentation for the front end, in the build directory.
- This target is only called by `make bootstrap' if a suitable
- version of `makeinfo' is available, so does not need to check for
- this, and should fail if an error occurs.
-
-`dvi'
- Build DVI documentation for the front end, in the build directory.
- This should be done using `$(TEXI2DVI)', with appropriate `-I'
- arguments pointing to directories of included files.
-
-`pdf'
- Build PDF documentation for the front end, in the build directory.
- This should be done using `$(TEXI2PDF)', with appropriate `-I'
- arguments pointing to directories of included files.
-
-`html'
- Build HTML documentation for the front end, in the build directory.
-
-`man'
- Build generated man pages for the front end from Texinfo manuals
- (*note Man Page Generation::), in the build directory. This target
- is only called if the necessary tools are available, but should
- ignore errors so as not to stop the build if errors occur; man
- pages are optional and the tools involved may be installed in a
- broken way.
-
-`install-common'
- Install everything that is part of the front end, apart from the
- compiler executables listed in `compilers' in `config-lang.in'.
-
-`install-info'
- Install info documentation for the front end, if it is present in
- the source directory. This target should have dependencies on
- info files that should be installed.
-
-`install-man'
- Install man pages for the front end. This target should ignore
- errors.
-
-`install-plugin'
- Install headers needed for plugins.
-
-`srcextra'
- Copies its dependencies into the source directory. This generally
- should be used for generated files such as Bison output files
- which are not version-controlled, but should be included in any
- release tarballs. This target will be executed during a bootstrap
- if `--enable-generated-files-in-srcdir' was specified as a
- `configure' option.
-
-`srcinfo'
-`srcman'
- Copies its dependencies into the source directory. These targets
- will be executed during a bootstrap if
- `--enable-generated-files-in-srcdir' was specified as a
- `configure' option.
-
-`uninstall'
- Uninstall files installed by installing the compiler. This is
- currently documented not to be supported, so the hook need not do
- anything.
-
-`mostlyclean'
-`clean'
-`distclean'
-`maintainer-clean'
- The language parts of the standard GNU `*clean' targets. *Note
- Standard Targets for Users: (standards)Standard Targets, for
- details of the standard targets. For GCC, `maintainer-clean'
- should delete all generated files in the source directory that are
- not version-controlled, but should not delete anything that is.
-
- `Make-lang.in' must also define a variable `LANG_OBJS' to a list of
-host object files that are used by that language.
-
-
-File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory
-
-6.3.9 Anatomy of a Target Back End
-----------------------------------
-
-A back end for a target architecture in GCC has the following parts:
-
- * A directory `MACHINE' under `gcc/config', containing a machine
- description `MACHINE.md' file (*note Machine Descriptions: Machine
- Desc.), header files `MACHINE.h' and `MACHINE-protos.h' and a
- source file `MACHINE.c' (*note Target Description Macros and
- Functions: Target Macros.), possibly a target Makefile fragment
- `t-MACHINE' (*note The Target Makefile Fragment: Target
- Fragment.), and maybe some other files. The names of these files
- may be changed from the defaults given by explicit specifications
- in `config.gcc'.
-
- * If necessary, a file `MACHINE-modes.def' in the `MACHINE'
- directory, containing additional machine modes to represent
- condition codes. *Note Condition Code::, for further details.
-
- * An optional `MACHINE.opt' file in the `MACHINE' directory,
- containing a list of target-specific options. You can also add
- other option files using the `extra_options' variable in
- `config.gcc'. *Note Options::.
-
- * Entries in `config.gcc' (*note The `config.gcc' File: System
- Config.) for the systems with this target architecture.
-
- * Documentation in `gcc/doc/invoke.texi' for any command-line
- options supported by this target (*note Run-time Target
- Specification: Run-time Target.). This means both entries in the
- summary table of options and details of the individual options.
-
- * Documentation in `gcc/doc/extend.texi' for any target-specific
- attributes supported (*note Defining target-specific uses of
- `__attribute__': Target Attributes.), including where the same
- attribute is already supported on some targets, which are
- enumerated in the manual.
-
- * Documentation in `gcc/doc/extend.texi' for any target-specific
- pragmas supported.
-
- * Documentation in `gcc/doc/extend.texi' of any target-specific
- built-in functions supported.
-
- * Documentation in `gcc/doc/extend.texi' of any target-specific
- format checking styles supported.
-
- * Documentation in `gcc/doc/md.texi' of any target-specific
- constraint letters (*note Constraints for Particular Machines:
- Machine Constraints.).
-
- * A note in `gcc/doc/contrib.texi' under the person or people who
- contributed the target support.
-
- * Entries in `gcc/doc/install.texi' for all target triplets
- supported with this target architecture, giving details of any
- special notes about installation for this target, or saying that
- there are no special notes if there are none.
-
- * Possibly other support outside the `gcc' directory for runtime
- libraries. FIXME: reference docs for this. The `libstdc++'
- porting manual needs to be installed as info for this to work, or
- to be a chapter of this manual.
-
- If the back end is added to the official GCC source repository, the
-following are also necessary:
-
- * An entry for the target architecture in `readings.html' on the GCC
- web site, with any relevant links.
-
- * Details of the properties of the back end and target architecture
- in `backends.html' on the GCC web site.
-
- * A news item about the contribution of support for that target
- architecture, in `index.html' on the GCC web site.
-
- * Normally, one or more maintainers of that target listed in
- `MAINTAINERS'. Some existing architectures may be unmaintained,
- but it would be unusual to add support for a target that does not
- have a maintainer when support is added.
-
-
-File: gccint.info, Node: Testsuites, Next: Options, Prev: Source Tree, Up: Top
-
-7 Testsuites
-************
-
-GCC contains several testsuites to help maintain compiler quality.
-Most of the runtime libraries and language front ends in GCC have
-testsuites. Currently only the C language testsuites are documented
-here; FIXME: document the others.
-
-* Menu:
-
-* Test Idioms:: Idioms used in testsuite code.
-* Test Directives:: Directives used within DejaGnu tests.
-* Ada Tests:: The Ada language testsuites.
-* C Tests:: The C language testsuites.
-* libgcj Tests:: The Java library testsuites.
-* LTO Testing:: Support for testing link-time optimizations.
-* gcov Testing:: Support for testing gcov.
-* profopt Testing:: Support for testing profile-directed optimizations.
-* compat Testing:: Support for testing binary compatibility.
-* Torture Tests:: Support for torture testing using multiple options.
-
-
-File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites
-
-7.1 Idioms Used in Testsuite Code
-=================================
-
-In general, C testcases have a trailing `-N.c', starting with `-1.c',
-in case other testcases with similar names are added later. If the
-test is a test of some well-defined feature, it should have a name
-referring to that feature such as `FEATURE-1.c'. If it does not test a
-well-defined feature but just happens to exercise a bug somewhere in
-the compiler, and a bug report has been filed for this bug in the GCC
-bug database, `prBUG-NUMBER-1.c' is the appropriate form of name.
-Otherwise (for miscellaneous bugs not filed in the GCC bug database),
-and previously more generally, test cases are named after the date on
-which they were added. This allows people to tell at a glance whether
-a test failure is because of a recently found bug that has not yet been
-fixed, or whether it may be a regression, but does not give any other
-information about the bug or where discussion of it may be found. Some
-other language testsuites follow similar conventions.
-
- In the `gcc.dg' testsuite, it is often necessary to test that an error
-is indeed a hard error and not just a warning--for example, where it is
-a constraint violation in the C standard, which must become an error
-with `-pedantic-errors'. The following idiom, where the first line
-shown is line LINE of the file and the line that generates the error,
-is used for this:
-
- /* { dg-bogus "warning" "warning in place of error" } */
- /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */
-
- It may be necessary to check that an expression is an integer constant
-expression and has a certain value. To check that `E' has value `V',
-an idiom similar to the following is used:
-
- char x[((E) == (V) ? 1 : -1)];
-
- In `gcc.dg' tests, `__typeof__' is sometimes used to make assertions
-about the types of expressions. See, for example,
-`gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact
-rules for the types of conditional expressions in the C standard; see,
-for example, `gcc.dg/c99-intconst-1.c'.
-
- It is useful to be able to test that optimizations are being made
-properly. This cannot be done in all cases, but it can be done where
-the optimization will lead to code being optimized away (for example,
-where flow analysis or alias analysis should show that certain code
-cannot be called) or to functions not being called because they have
-been expanded as built-in functions. Such tests go in
-`gcc.c-torture/execute'. Where code should be optimized away, a call
-to a nonexistent function such as `link_failure ()' may be inserted; a
-definition
-
- #ifndef __OPTIMIZE__
- void
- link_failure (void)
- {
- abort ();
- }
- #endif
-
-will also be needed so that linking still succeeds when the test is run
-without optimization. When all calls to a built-in function should
-have been optimized and no calls to the non-built-in version of the
-function should remain, that function may be defined as `static' to
-call `abort ()' (although redeclaring a function as static may not work
-on all targets).
-
- All testcases must be portable. Target-specific testcases must have
-appropriate code to avoid causing failures on unsupported systems;
-unfortunately, the mechanisms for this differ by directory.
-
- FIXME: discuss non-C testsuites here.
-
-
-File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites
-
-7.2 Directives used within DejaGnu tests
-========================================
-
-* Menu:
-
-* Directives:: Syntax and descriptions of test directives.
-* Selectors:: Selecting targets to which a test applies.
-* Effective-Target Keywords:: Keywords describing target attributes.
-* Add Options:: Features for `dg-add-options'
-* Require Support:: Variants of `dg-require-SUPPORT'
-* Final Actions:: Commands for use in `dg-final'
-
-
-File: gccint.info, Node: Directives, Next: Selectors, Up: Test Directives
-
-7.2.1 Syntax and Descriptions of test directives
-------------------------------------------------
-
-Test directives appear within comments in a test source file and begin
-with `dg-'. Some of these are defined within DejaGnu and others are
-local to the GCC testsuite.
-
- The order in which test directives appear in a test can be important:
-directives local to GCC sometimes override information used by the
-DejaGnu directives, which know nothing about the GCC directives, so the
-DejaGnu directives must precede GCC directives.
-
- Several test directives include selectors (*note Selectors::) which
-are usually preceded by the keyword `target' or `xfail'.
-
-7.2.1.1 Specify how to build the test
-.....................................
-
-`{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }'
- DO-WHAT-KEYWORD specifies how the test is compiled and whether it
- is executed. It is one of:
-
- `preprocess'
- Compile with `-E' to run only the preprocessor.
-
- `compile'
- Compile with `-S' to produce an assembly code file.
-
- `assemble'
- Compile with `-c' to produce a relocatable object file.
-
- `link'
- Compile, assemble, and link to produce an executable file.
-
- `run'
- Produce and run an executable file, which is expected to
- return an exit code of 0.
-
- The default is `compile'. That can be overridden for a set of
- tests by redefining `dg-do-what-default' within the `.exp' file
- for those tests.
-
- If the directive includes the optional `{ target SELECTOR }' then
- the test is skipped unless the target system matches the SELECTOR.
-
- If DO-WHAT-KEYWORD is `run' and the directive includes the
- optional `{ xfail SELECTOR }' and the selector is met then the
- test is expected to fail. The `xfail' clause is ignored for other
- values of DO-WHAT-KEYWORD; those tests can use directive
- `dg-xfail-if'.
-
-7.2.1.2 Specify additional compiler options
-...........................................
-
-`{ dg-options OPTIONS [{ target SELECTOR }] }'
- This DejaGnu directive provides a list of compiler options, to be
- used if the target system matches SELECTOR, that replace the
- default options used for this set of tests.
-
-`{ dg-add-options FEATURE ... }'
- Add any compiler options that are needed to access certain
- features. This directive does nothing on targets that enable the
- features by default, or that don't provide them at all. It must
- come after all `dg-options' directives. For supported values of
- FEATURE see *note Add Options::.
-
-7.2.1.3 Modify the test timeout value
-.....................................
-
-The normal timeout limit, in seconds, is found by searching the
-following in order:
-
- * the value defined by an earlier `dg-timeout' directive in the test
-
- * variable TOOL_TIMEOUT defined by the set of tests
-
- * GCC,TIMEOUT set in the target board
-
- * 300
-
-`{ dg-timeout N [{target SELECTOR }] }'
- Set the time limit for the compilation and for the execution of
- the test to the specified number of seconds.
-
-`{ dg-timeout-factor X [{ target SELECTOR }] }'
- Multiply the normal time limit for compilation and execution of
- the test by the specified floating-point factor.
-
-7.2.1.4 Skip a test for some targets
-....................................
-
-`{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }'
- Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each
- element is a string of zero or more GCC options. Skip the test if
- all of the following conditions are met:
- * the test system is included in SELECTOR
-
- * for at least one of the option strings in INCLUDE-OPTS, every
- option from that string is in the set of options with which
- the test would be compiled; use `"*"' for an INCLUDE-OPTS list
- that matches any options; that is the default if INCLUDE-OPTS
- is not specified
-
- * for each of the option strings in EXCLUDE-OPTS, at least one
- option from that string is not in the set of options with
- which the test would be compiled; use `""' for an empty
- EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not
- specified
-
- For example, to skip a test if option `-Os' is present:
-
- /* { dg-skip-if "" { *-*-* } { "-Os" } { "" } } */
-
- To skip a test if both options `-O2' and `-g' are present:
-
- /* { dg-skip-if "" { *-*-* } { "-O2 -g" } { "" } } */
-
- To skip a test if either `-O2' or `-O3' is present:
-
- /* { dg-skip-if "" { *-*-* } { "-O2" "-O3" } { "" } } */
-
- To skip a test unless option `-Os' is present:
-
- /* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */
-
- To skip a test if either `-O2' or `-O3' is used with `-g' but not
- if `-fpic' is also present:
-
- /* { dg-skip-if "" { *-*-* } { "-O2 -g" "-O3 -g" } { "-fpic" } } */
-
-`{ dg-require-effective-target KEYWORD [{ SELECTOR }] }'
- Skip the test if the test target, including current multilib flags,
- is not covered by the effective-target keyword. If the directive
- includes the optional `{ SELECTOR }' then the effective-target
- test is only performed if the target system matches the SELECTOR.
- This directive must appear after any `dg-do' directive in the test
- and before any `dg-additional-sources' directive. *Note
- Effective-Target Keywords::.
-
-`{ dg-require-SUPPORT args }'
- Skip the test if the target does not provide the required support.
- These directives must appear after any `dg-do' directive in the
- test and before any `dg-additional-sources' directive. They
- require at least one argument, which can be an empty string if the
- specific procedure does not examine the argument. *Note Require
- Support::, for a complete list of these directives.
-
-7.2.1.5 Expect a test to fail for some targets
-..............................................
-
-`{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }'
- Expect the test to fail if the conditions (which are the same as
- for `dg-skip-if') are met. This does not affect the execute step.
-
-`{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }'
- Expect the execute step of a test to fail if the conditions (which
- are the same as for `dg-skip-if') are met.
-
-7.2.1.6 Expect the test executable to fail
-..........................................
-
-`{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }'
- Expect the test executable to return a nonzero exit status if the
- conditions (which are the same as for `dg-skip-if') are met.
-
-7.2.1.7 Verify compiler messages
-................................
-
-`{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
- This DejaGnu directive appears on a source line that is expected
- to get an error message, or else specifies the source line
- associated with the message. If there is no message for that line
- or if the text of that message is not matched by REGEXP then the
- check fails and COMMENT is included in the `FAIL' message. The
- check does not look for the string `error' unless it is part of
- REGEXP.
-
-`{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
- This DejaGnu directive appears on a source line that is expected
- to get a warning message, or else specifies the source line
- associated with the message. If there is no message for that line
- or if the text of that message is not matched by REGEXP then the
- check fails and COMMENT is included in the `FAIL' message. The
- check does not look for the string `warning' unless it is part of
- REGEXP.
-
-`{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
- The line is expected to get a message other than an error or
- warning. If there is no message for that line or if the text of
- that message is not matched by REGEXP then the check fails and
- COMMENT is included in the `FAIL' message.
-
-`{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
- This DejaGnu directive appears on a source line that should not
- get a message matching REGEXP, or else specifies the source line
- associated with the bogus message. It is usually used with `xfail'
- to indicate that the message is a known problem for a particular
- set of targets.
-
-`{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }'
- This DejaGnu directive indicates that the test is expected to fail
- due to compiler messages that are not handled by `dg-error',
- `dg-warning' or `dg-bogus'. For this directive `xfail' has the
- same effect as `target'.
-
-`{ dg-prune-output REGEXP }'
- Prune messages matching REGEXP from the test output.
-
-7.2.1.8 Verify output of the test executable
-............................................
-
-`{ dg-output REGEXP [{ target/xfail SELECTOR }] }'
- This DejaGnu directive compares REGEXP to the combined output that
- the test executable writes to `stdout' and `stderr'.
-
-7.2.1.9 Specify additional files for a test
-...........................................
-
-`{ dg-additional-files "FILELIST" }'
- Specify additional files, other than source files, that must be
- copied to the system where the compiler runs.
-
-`{ dg-additional-sources "FILELIST" }'
- Specify additional source files to appear in the compile line
- following the main test file.
-
-7.2.1.10 Add checks at the end of a test
-........................................
-
-`{ dg-final { LOCAL-DIRECTIVE } }'
- This DejaGnu directive is placed within a comment anywhere in the
- source file and is processed after the test has been compiled and
- run. Multiple `dg-final' commands are processed in the order in
- which they appear in the source file. *Note Final Actions::, for
- a list of directives that can be used within `dg-final'.
-
-
-File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives
-
-7.2.2 Selecting targets to which a test applies
------------------------------------------------
-
-Several test directives include SELECTORs to limit the targets for
-which a test is run or to declare that a test is expected to fail on
-particular targets.
-
- A selector is:
- * one or more target triplets, possibly including wildcard characters
-
- * a single effective-target keyword (*note Effective-Target
- Keywords::)
-
- * a logical expression
-
- Depending on the context, the selector specifies whether a test is
-skipped and reported as unsupported or is expected to fail. Use
-`*-*-*' to match any target.
-
- A selector expression appears within curly braces and uses a single
-logical operator: one of `!', `&&', or `||'. An operand is another
-selector expression, an effective-target keyword, a single target
-triplet, or a list of target triplets within quotes or curly braces.
-For example:
-
- { target { ! "hppa*-*-* ia64*-*-*" } }
- { target { powerpc*-*-* && lp64 } }
- { xfail { lp64 || vect_no_align } }
-
-
-File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives
-
-7.2.3 Keywords describing target attributes
--------------------------------------------
-
-Effective-target keywords identify sets of targets that support
-particular functionality. They are used to limit tests to be run only
-for particular targets, or to specify that particular sets of targets
-are expected to fail some tests.
-
- Effective-target keywords are defined in `lib/target-supports.exp' in
-the GCC testsuite, with the exception of those that are documented as
-being local to a particular test directory.
-
- The `effective target' takes into account all of the compiler options
-with which the test will be compiled, including the multilib options.
-By convention, keywords ending in `_nocache' can also include options
-specified for the particular test in an earlier `dg-options' or
-`dg-add-options' directive.
-
-7.2.3.1 Data type sizes
-.......................
-
-`ilp32'
- Target has 32-bit `int', `long', and pointers.
-
-`lp64'
- Target has 32-bit `int', 64-bit `long' and pointers.
-
-`llp64'
- Target has 32-bit `int' and `long', 64-bit `long long' and
- pointers.
-
-`double64'
- Target has 64-bit `double'.
-
-`double64plus'
- Target has `double' that is 64 bits or longer.
-
-`int32plus'
- Target has `int' that is at 32 bits or longer.
-
-`int16'
- Target has `int' that is 16 bits or shorter.
-
-`large_double'
- Target supports `double' that is longer than `float'.
-
-`large_long_double'
- Target supports `long double' that is longer than `double'.
-
-`ptr32plus'
- Target has pointers that are 32 bits or longer.
-
-`size32plus'
- Target supports array and structure sizes that are 32 bits or
- longer.
-
-`4byte_wchar_t'
- Target has `wchar_t' that is at least 4 bytes.
-
-7.2.3.2 Fortran-specific attributes
-...................................
-
-`fortran_integer_16'
- Target supports Fortran `integer' that is 16 bytes or longer.
-
-`fortran_large_int'
- Target supports Fortran `integer' kinds larger than `integer(8)'.
-
-`fortran_large_real'
- Target supports Fortran `real' kinds larger than `real(8)'.
-
-7.2.3.3 Vector-specific attributes
-..................................
-
-`vect_condition'
- Target supports vector conditional operations.
-
-`vect_double'
- Target supports hardware vectors of `double'.
-
-`vect_float'
- Target supports hardware vectors of `float'.
-
-`vect_int'
- Target supports hardware vectors of `int'.
-
-`vect_long'
- Target supports hardware vectors of `long'.
-
-`vect_long_long'
- Target supports hardware vectors of `long long'.
-
-`vect_aligned_arrays'
- Target aligns arrays to vector alignment boundary.
-
-`vect_hw_misalign'
- Target supports a vector misalign access.
-
-`vect_no_align'
- Target does not support a vector alignment mechanism.
-
-`vect_no_int_max'
- Target does not support a vector max instruction on `int'.
-
-`vect_no_int_add'
- Target does not support a vector add instruction on `int'.
-
-`vect_no_bitwise'
- Target does not support vector bitwise instructions.
-
-`vect_char_mult'
- Target supports `vector char' multiplication.
-
-`vect_short_mult'
- Target supports `vector short' multiplication.
-
-`vect_int_mult'
- Target supports `vector int' multiplication.
-
-`vect_extract_even_odd'
- Target supports vector even/odd element extraction.
-
-`vect_extract_even_odd_wide'
- Target supports vector even/odd element extraction of vectors with
- elements `SImode' or larger.
-
-`vect_interleave'
- Target supports vector interleaving.
-
-`vect_strided'
- Target supports vector interleaving and extract even/odd.
-
-`vect_strided_wide'
- Target supports vector interleaving and extract even/odd for wide
- element types.
-
-`vect_perm'
- Target supports vector permutation.
-
-`vect_shift'
- Target supports a hardware vector shift operation.
-
-`vect_widen_sum_hi_to_si'
- Target supports a vector widening summation of `short' operands
- into `int' results, or can promote (unpack) from `short' to `int'.
-
-`vect_widen_sum_qi_to_hi'
- Target supports a vector widening summation of `char' operands
- into `short' results, or can promote (unpack) from `char' to
- `short'.
-
-`vect_widen_sum_qi_to_si'
- Target supports a vector widening summation of `char' operands
- into `int' results.
-
-`vect_widen_mult_qi_to_hi'
- Target supports a vector widening multiplication of `char' operands
- into `short' results, or can promote (unpack) from `char' to
- `short' and perform non-widening multiplication of `short'.
-
-`vect_widen_mult_hi_to_si'
- Target supports a vector widening multiplication of `short'
- operands into `int' results, or can promote (unpack) from `short'
- to `int' and perform non-widening multiplication of `int'.
-
-`vect_sdot_qi'
- Target supports a vector dot-product of `signed char'.
-
-`vect_udot_qi'
- Target supports a vector dot-product of `unsigned char'.
-
-`vect_sdot_hi'
- Target supports a vector dot-product of `signed short'.
-
-`vect_udot_hi'
- Target supports a vector dot-product of `unsigned short'.
-
-`vect_pack_trunc'
- Target supports a vector demotion (packing) of `short' to `char'
- and from `int' to `short' using modulo arithmetic.
-
-`vect_unpack'
- Target supports a vector promotion (unpacking) of `char' to `short'
- and from `char' to `int'.
-
-`vect_intfloat_cvt'
- Target supports conversion from `signed int' to `float'.
-
-`vect_uintfloat_cvt'
- Target supports conversion from `unsigned int' to `float'.
-
-`vect_floatint_cvt'
- Target supports conversion from `float' to `signed int'.
-
-`vect_floatuint_cvt'
- Target supports conversion from `float' to `unsigned int'.
-
-7.2.3.4 Thread Local Storage attributes
-.......................................
-
-`tls'
- Target supports thread-local storage.
-
-`tls_native'
- Target supports native (rather than emulated) thread-local storage.
-
-`tls_runtime'
- Test system supports executing TLS executables.
-
-7.2.3.5 Decimal floating point attributes
-.........................................
-
-`dfp'
- Targets supports compiling decimal floating point extension to C.
-
-`dfp_nocache'
- Including the options used to compile this particular test, the
- target supports compiling decimal floating point extension to C.
-
-`dfprt'
- Test system can execute decimal floating point tests.
-
-`dfprt_nocache'
- Including the options used to compile this particular test, the
- test system can execute decimal floating point tests.
-
-`hard_dfp'
- Target generates decimal floating point instructions with current
- options.
-
-7.2.3.6 ARM-specific attributes
-...............................
-
-`arm32'
- ARM target generates 32-bit code.
-
-`arm_eabi'
- ARM target adheres to the ABI for the ARM Architecture.
-
-`arm_hard_vfp_ok'
- ARM target supports `-mfpu=vfp -mfloat-abi=hard'. Some multilibs
- may be incompatible with these options.
-
-`arm_iwmmxt_ok'
- ARM target supports `-mcpu=iwmmxt'. Some multilibs may be
- incompatible with this option.
-
-`arm_neon'
- ARM target supports generating NEON instructions.
-
-`arm_neon_hw'
- Test system supports executing NEON instructions.
-
-`arm_neon_ok'
- ARM Target supports `-mfpu=neon -mfloat-abi=softfp' or compatible
- options. Some multilibs may be incompatible with these options.
-
-`arm_neon_fp16_ok'
- ARM Target supports `-mfpu=neon-fp16 -mfloat-abi=softfp' or
- compatible options. Some multilibs may be incompatible with these
- options.
-
-`arm_thumb1_ok'
- ARM target generates Thumb-1 code for `-mthumb'.
-
-`arm_thumb2_ok'
- ARM target generates Thumb-2 code for `-mthumb'.
-
-`arm_vfp_ok'
- ARM target supports `-mfpu=vfp -mfloat-abi=softfp'. Some
- multilibs may be incompatible with these options.
-
-7.2.3.7 MIPS-specific attributes
-................................
-
-`mips64'
- MIPS target supports 64-bit instructions.
-
-`nomips16'
- MIPS target does not produce MIPS16 code.
-
-`mips16_attribute'
- MIPS target can generate MIPS16 code.
-
-`mips_loongson'
- MIPS target is a Loongson-2E or -2F target using an ABI that
- supports the Loongson vector modes.
-
-`mips_newabi_large_long_double'
- MIPS target supports `long double' larger than `double' when using
- the new ABI.
-
-`mpaired_single'
- MIPS target supports `-mpaired-single'.
-
-7.2.3.8 PowerPC-specific attributes
-...................................
-
-`powerpc64'
- Test system supports executing 64-bit instructions.
-
-`powerpc_altivec'
- PowerPC target supports AltiVec.
-
-`powerpc_altivec_ok'
- PowerPC target supports `-maltivec'.
-
-`powerpc_fprs'
- PowerPC target supports floating-point registers.
-
-`powerpc_hard_double'
- PowerPC target supports hardware double-precision floating-point.
-
-`powerpc_ppu_ok'
- PowerPC target supports `-mcpu=cell'.
-
-`powerpc_spe'
- PowerPC target supports PowerPC SPE.
-
-`powerpc_spe_nocache'
- Including the options used to compile this particular test, the
- PowerPC target supports PowerPC SPE.
-
-`powerpc_spu'
- PowerPC target supports PowerPC SPU.
-
-`spu_auto_overlay'
- SPU target has toolchain that supports automatic overlay
- generation.
-
-`powerpc_vsx_ok'
- PowerPC target supports `-mvsx'.
-
-`powerpc_405_nocache'
- Including the options used to compile this particular test, the
- PowerPC target supports PowerPC 405.
-
-`vmx_hw'
- PowerPC target supports executing AltiVec instructions.
-
-7.2.3.9 Other hardware attributes
-.................................
-
-`avx'
- Target supports compiling `avx' instructions.
-
-`avx_runtime'
- Target supports the execution of `avx' instructions.
-
-`cell_hw'
- Test system can execute AltiVec and Cell PPU instructions.
-
-`coldfire_fpu'
- Target uses a ColdFire FPU.
-
-`hard_float'
- Target supports FPU instructions.
-
-`sse'
- Target supports compiling `sse' instructions.
-
-`sse_runtime'
- Target supports the execution of `sse' instructions.
-
-`sse2'
- Target supports compiling `sse2' instructions.
-
-`sse2_runtime'
- Target supports the execution of `sse2' instructions.
-
-`sync_char_short'
- Target supports atomic operations on `char' and `short'.
-
-`sync_int_long'
- Target supports atomic operations on `int' and `long'.
-
-`ultrasparc_hw'
- Test environment appears to run executables on a simulator that
- accepts only `EM_SPARC' executables and chokes on `EM_SPARC32PLUS'
- or `EM_SPARCV9' executables.
-
-`vect_cmdline_needed'
- Target requires a command line argument to enable a SIMD
- instruction set.
-
-7.2.3.10 Environment attributes
-...............................
-
-`c'
- The language for the compiler under test is C.
-
-`c++'
- The language for the compiler under test is C++.
-
-`c99_runtime'
- Target provides a full C99 runtime.
-
-`correct_iso_cpp_string_wchar_protos'
- Target `string.h' and `wchar.h' headers provide C++ required
- overloads for `strchr' etc. functions.
-
-`dummy_wcsftime'
- Target uses a dummy `wcsftime' function that always returns zero.
-
-`fd_truncate'
- Target can truncate a file from a file descriptor, as used by
- `libgfortran/io/unix.c:fd_truncate'; i.e. `ftruncate' or `chsize'.
-
-`freestanding'
- Target is `freestanding' as defined in section 4 of the C99
- standard. Effectively, it is a target which supports no extra
- headers or libraries other than what is considered essential.
-
-`init_priority'
- Target supports constructors with initialization priority
- arguments.
-
-`inttypes_types'
- Target has the basic signed and unsigned types in `inttypes.h'.
- This is for tests that GCC's notions of these types agree with
- those in the header, as some systems have only `inttypes.h'.
-
-`lax_strtofp'
- Target might have errors of a few ULP in string to floating-point
- conversion functions and overflow is not always detected correctly
- by those functions.
-
-`newlib'
- Target supports Newlib.
-
-`pow10'
- Target provides `pow10' function.
-
-`pthread'
- Target can compile using `pthread.h' with no errors or warnings.
-
-`pthread_h'
- Target has `pthread.h'.
-
-`run_expensive_tests'
- Expensive testcases (usually those that consume excessive amounts
- of CPU time) should be run on this target. This can be enabled by
- setting the `GCC_TEST_RUN_EXPENSIVE' environment variable to a
- non-empty string.
-
-`simulator'
- Test system runs executables on a simulator (i.e. slowly) rather
- than hardware (i.e. fast).
-
-`stdint_types'
- Target has the basic signed and unsigned C types in `stdint.h'.
- This will be obsolete when GCC ensures a working `stdint.h' for
- all targets.
-
-`trampolines'
- Target supports trampolines.
-
-`uclibc'
- Target supports uClibc.
-
-`unwrapped'
- Target does not use a status wrapper.
-
-`vxworks_kernel'
- Target is a VxWorks kernel.
-
-`vxworks_rtp'
- Target is a VxWorks RTP.
-
-`wchar'
- Target supports wide characters.
-
-7.2.3.11 Other attributes
-.........................
-
-`automatic_stack_alignment'
- Target supports automatic stack alignment.
-
-`cxa_atexit'
- Target uses `__cxa_atexit'.
-
-`default_packed'
- Target has packed layout of structure members by default.
-
-`fgraphite'
- Target supports Graphite optimizations.
-
-`fixed_point'
- Target supports fixed-point extension to C.
-
-`fopenmp'
- Target supports OpenMP via `-fopenmp'.
-
-`fpic'
- Target supports `-fpic' and `-fPIC'.
-
-`freorder'
- Target supports `-freorder-blocks-and-partition'.
-
-`fstack_protector'
- Target supports `-fstack-protector'.
-
-`gas'
- Target uses GNU `as'.
-
-`gc_sections'
- Target supports `--gc-sections'.
-
-`keeps_null_pointer_checks'
- Target keeps null pointer checks, either due to the use of
- `-fno-delete-null-pointer-checks' or hardwired into the target.
-
-`lto'
- Compiler has been configured to support link-time optimization
- (LTO).
-
-`named_sections'
- Target supports named sections.
-
-`natural_alignment_32'
- Target uses natural alignment (aligned to type size) for types of
- 32 bits or less.
-
-`target_natural_alignment_64'
- Target uses natural alignment (aligned to type size) for types of
- 64 bits or less.
-
-`nonpic'
- Target does not generate PIC by default.
-
-`pcc_bitfield_type_matters'
- Target defines `PCC_BITFIELD_TYPE_MATTERS'.
-
-`pe_aligned_commons'
- Target supports `-mpe-aligned-commons'.
-
-`section_anchors'
- Target supports section anchors.
-
-`short_enums'
- Target defaults to short enums.
-
-`static'
- Target supports `-static'.
-
-`static_libgfortran'
- Target supports statically linking `libgfortran'.
-
-`string_merging'
- Target supports merging string constants at link time.
-
-`ucn'
- Target supports compiling and assembling UCN.
-
-`ucn_nocache'
- Including the options used to compile this particular test, the
- target supports compiling and assembling UCN.
-
-`unaligned_stack'
- Target does not guarantee that its `STACK_BOUNDARY' is greater than
- or equal to the required vector alignment.
-
-`vector_alignment_reachable'
- Vector alignment is reachable for types of 32 bits or less.
-
-`vector_alignment_reachable_for_64bit'
- Vector alignment is reachable for types of 64 bits or less.
-
-`wchar_t_char16_t_compatible'
- Target supports `wchar_t' that is compatible with `char16_t'.
-
-`wchar_t_char32_t_compatible'
- Target supports `wchar_t' that is compatible with `char32_t'.
-
-7.2.3.12 Local to tests in `gcc.target/i386'
-............................................
-
-`3dnow'
- Target supports compiling `3dnow' instructions.
-
-`aes'
- Target supports compiling `aes' instructions.
-
-`fma4'
- Target supports compiling `fma4' instructions.
-
-`ms_hook_prologue'
- Target supports attribute `ms_hook_prologue'.
-
-`pclmul'
- Target supports compiling `pclmul' instructions.
-
-`sse3'
- Target supports compiling `sse3' instructions.
-
-`sse4'
- Target supports compiling `sse4' instructions.
-
-`sse4a'
- Target supports compiling `sse4a' instructions.
-
-`ssse3'
- Target supports compiling `ssse3' instructions.
-
-`vaes'
- Target supports compiling `vaes' instructions.
-
-`vpclmul'
- Target supports compiling `vpclmul' instructions.
-
-`xop'
- Target supports compiling `xop' instructions.
-
-7.2.3.13 Local to tests in `gcc.target/spu/ea'
-..............................................
-
-`ealib'
- Target `__ea' library functions are available.
-
-7.2.3.14 Local to tests in `gcc.test-framework'
-...............................................
-
-`no'
- Always returns 0.
-
-`yes'
- Always returns 1.
-
-
-File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives
-
-7.2.4 Features for `dg-add-options'
------------------------------------
-
-The supported values of FEATURE for directive `dg-add-options' are:
-
-`arm_neon'
- NEON support. Only ARM targets support this feature, and only then
- in certain modes; see the *note arm_neon_ok effective target
- keyword: arm_neon_ok.
-
-`arm_neon_fp16'
- NEON and half-precision floating point support. Only ARM targets
- support this feature, and only then in certain modes; see the
- *note arm_neon_fp16_ok effective target keyword: arm_neon_ok.
-
-`bind_pic_locally'
- Add the target-specific flags needed to enable functions to bind
- locally when using pic/PIC passes in the testsuite.
-
-`c99_runtime'
- Add the target-specific flags needed to access the C99 runtime.
-
-`ieee'
- Add the target-specific flags needed to enable full IEEE
- compliance mode.
-
-`mips16_attribute'
- `mips16' function attributes. Only MIPS targets support this
- feature, and only then in certain modes.
-
-`tls'
- Add the target-specific flags needed to use thread-local storage.
-
-
-File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives
-
-7.2.5 Variants of `dg-require-SUPPORT'
---------------------------------------
-
-A few of the `dg-require' directives take arguments.
-
-`dg-require-iconv CODESET'
- Skip the test if the target does not support iconv. CODESET is
- the codeset to convert to.
-
-`dg-require-profiling PROFOPT'
- Skip the test if the target does not support profiling with option
- PROFOPT.
-
-`dg-require-visibility VIS'
- Skip the test if the target does not support the `visibility'
- attribute. If VIS is `""', support for `visibility("hidden")' is
- checked, for `visibility("VIS")' otherwise.
-
- The original `dg-require' directives were defined before there was
-support for effective-target keywords. The directives that do not take
-arguments could be replaced with effective-target keywords.
-
-`dg-require-alias ""'
- Skip the test if the target does not support the `alias' attribute.
-
-`dg-require-ascii-locale ""'
- Skip the test if the host does not support an ASCII locale.
-
-`dg-require-compat-dfp ""'
- Skip this test unless both compilers in a `compat' testsuite
- support decimal floating point.
-
-`dg-require-cxa-atexit ""'
- Skip the test if the target does not support `__cxa_atexit'. This
- is equivalent to `dg-require-effective-target cxa_atexit'.
-
-`dg-require-dll ""'
- Skip the test if the target does not support DLL attributes.
-
-`dg-require-fork ""'
- Skip the test if the target does not support `fork'.
-
-`dg-require-gc-sections ""'
- Skip the test if the target's linker does not support the
- `--gc-sections' flags. This is equivalent to
- `dg-require-effective-target gc-sections'.
-
-`dg-require-host-local ""'
- Skip the test if the host is remote, rather than the same as the
- build system. Some tests are incompatible with DejaGnu's handling
- of remote hosts, which involves copying the source file to the
- host and compiling it with a relative path and "`-o a.out'".
-
-`dg-require-mkfifo ""'
- Skip the test if the target does not support `mkfifo'.
-
-`dg-require-named-sections ""'
- Skip the test is the target does not support named sections. This
- is equivalent to `dg-require-effective-target named_sections'.
-
-`dg-require-weak ""'
- Skip the test if the target does not support weak symbols.
-
-`dg-require-weak-override ""'
- Skip the test if the target does not support overriding weak
- symbols.
-
-
-File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives
-
-7.2.6 Commands for use in `dg-final'
-------------------------------------
-
-The GCC testsuite defines the following directives to be used within
-`dg-final'.
-
-7.2.6.1 Scan a particular file
-..............................
-
-`scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]'
- Passes if REGEXP matches text in FILENAME.
-
-`scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]'
- Passes if REGEXP does not match text in FILENAME.
-
-`scan-module MODULE REGEXP [{ target/xfail SELECTOR }]'
- Passes if REGEXP matches in Fortran module MODULE.
-
-7.2.6.2 Scan the assembly output
-................................
-
-`scan-assembler REGEX [{ target/xfail SELECTOR }]'
- Passes if REGEX matches text in the test's assembler output.
-
-`scan-assembler-not REGEX [{ target/xfail SELECTOR }]'
- Passes if REGEX does not match text in the test's assembler output.
-
-`scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]'
- Passes if REGEX is matched exactly NUM times in the test's
- assembler output.
-
-`scan-assembler-dem REGEX [{ target/xfail SELECTOR }]'
- Passes if REGEX matches text in the test's demangled assembler
- output.
-
-`scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]'
- Passes if REGEX does not match text in the test's demangled
- assembler output.
-
-`scan-hidden SYMBOL [{ target/xfail SELECTOR }]'
- Passes if SYMBOL is defined as a hidden symbol in the test's
- assembly output.
-
-`scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]'
- Passes if SYMBOL is not defined as a hidden symbol in the test's
- assembly output.
-
-7.2.6.3 Scan optimization dump files
-....................................
-
-These commands are available for KIND of `tree', `rtl', and `ipa'.
-
-`scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]'
- Passes if REGEX matches text in the dump file with suffix SUFFIX.
-
-`scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
- Passes if REGEX does not match text in the dump file with suffix
- SUFFIX.
-
-`scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]'
- Passes if REGEX is found exactly NUM times in the dump file with
- suffix SUFFIX.
-
-`scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]'
- Passes if REGEX matches demangled text in the dump file with
- suffix SUFFIX.
-
-`scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
- Passes if REGEX does not match demangled text in the dump file with
- suffix SUFFIX.
-
-7.2.6.4 Verify that an output files exists or not
-.................................................
-
-`output-exists [{ target/xfail SELECTOR }]'
- Passes if compiler output file exists.
-
-`output-exists-not [{ target/xfail SELECTOR }]'
- Passes if compiler output file does not exist.
-
-7.2.6.5 Check for LTO tests
-...........................
-
-`scan-symbol REGEXP [{ target/xfail SELECTOR }]'
- Passes if the pattern is present in the final executable.
-
-7.2.6.6 Checks for `gcov' tests
-...............................
-
-`run-gcov SOURCEFILE'
- Check line counts in `gcov' tests.
-
-`run-gcov [branches] [calls] { OPTS SOURCEFILE }'
- Check branch and/or call counts, in addition to line counts, in
- `gcov' tests.
-
-7.2.6.7 Clean up generated test files
-.....................................
-
-`cleanup-coverage-files'
- Removes coverage data files generated for this test.
-
-`cleanup-ipa-dump SUFFIX'
- Removes IPA dump files generated for this test.
-
-`cleanup-modules'
- Removes Fortran module files generated for this test.
-
-`cleanup-profile-file'
- Removes profiling files generated for this test.
-
-`cleanup-repo-files'
- Removes files generated for this test for `-frepo'.
-
-`cleanup-rtl-dump SUFFIX'
- Removes RTL dump files generated for this test.
-
-`cleanup-saved-temps'
- Removes files for the current test which were kept for
- `-save-temps'.
-
-`cleanup-tree-dump SUFFIX'
- Removes tree dump files matching SUFFIX which were generated for
- this test.
-
-
-File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites
-
-7.3 Ada Language Testsuites
-===========================
-
-The Ada testsuite includes executable tests from the ACATS 2.5
-testsuite, publicly available at
-`http://www.adaic.org/compilers/acats/2.5'.
-
- These tests are integrated in the GCC testsuite in the `ada/acats'
-directory, and enabled automatically when running `make check', assuming
-the Ada language has been enabled when configuring GCC.
-
- You can also run the Ada testsuite independently, using `make
-check-ada', or run a subset of the tests by specifying which chapter to
-run, e.g.:
-
- $ make check-ada CHAPTERS="c3 c9"
-
- The tests are organized by directory, each directory corresponding to
-a chapter of the Ada Reference Manual. So for example, `c9' corresponds
-to chapter 9, which deals with tasking features of the language.
-
- There is also an extra chapter called `gcc' containing a template for
-creating new executable tests, although this is deprecated in favor of
-the `gnat.dg' testsuite.
-
- The tests are run using two `sh' scripts: `run_acats' and
-`run_all.sh'. To run the tests using a simulator or a cross target,
-see the small customization section at the top of `run_all.sh'.
-
- These tests are run using the build tree: they can be run without doing
-a `make install'.
-
-
-File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites
-
-7.4 C Language Testsuites
-=========================
-
-GCC contains the following C language testsuites, in the
-`gcc/testsuite' directory:
-
-`gcc.dg'
- This contains tests of particular features of the C compiler,
- using the more modern `dg' harness. Correctness tests for various
- compiler features should go here if possible.
-
- Magic comments determine whether the file is preprocessed,
- compiled, linked or run. In these tests, error and warning
- message texts are compared against expected texts or regular
- expressions given in comments. These tests are run with the
- options `-ansi -pedantic' unless other options are given in the
- test. Except as noted below they are not run with multiple
- optimization options.
-
-`gcc.dg/compat'
- This subdirectory contains tests for binary compatibility using
- `lib/compat.exp', which in turn uses the language-independent
- support (*note Support for testing binary compatibility: compat
- Testing.).
-
-`gcc.dg/cpp'
- This subdirectory contains tests of the preprocessor.
-
-`gcc.dg/debug'
- This subdirectory contains tests for debug formats. Tests in this
- subdirectory are run for each debug format that the compiler
- supports.
-
-`gcc.dg/format'
- This subdirectory contains tests of the `-Wformat' format
- checking. Tests in this directory are run with and without
- `-DWIDE'.
-
-`gcc.dg/noncompile'
- This subdirectory contains tests of code that should not compile
- and does not need any special compilation options. They are run
- with multiple optimization options, since sometimes invalid code
- crashes the compiler with optimization.
-
-`gcc.dg/special'
- FIXME: describe this.
-
-`gcc.c-torture'
- This contains particular code fragments which have historically
- broken easily. These tests are run with multiple optimization
- options, so tests for features which only break at some
- optimization levels belong here. This also contains tests to
- check that certain optimizations occur. It might be worthwhile to
- separate the correctness tests cleanly from the code quality
- tests, but it hasn't been done yet.
-
-`gcc.c-torture/compat'
- FIXME: describe this.
-
- This directory should probably not be used for new tests.
-
-`gcc.c-torture/compile'
- This testsuite contains test cases that should compile, but do not
- need to link or run. These test cases are compiled with several
- different combinations of optimization options. All warnings are
- disabled for these test cases, so this directory is not suitable if
- you wish to test for the presence or absence of compiler warnings.
- While special options can be set, and tests disabled on specific
- platforms, by the use of `.x' files, mostly these test cases
- should not contain platform dependencies. FIXME: discuss how
- defines such as `NO_LABEL_VALUES' and `STACK_SIZE' are used.
-
-`gcc.c-torture/execute'
- This testsuite contains test cases that should compile, link and
- run; otherwise the same comments as for `gcc.c-torture/compile'
- apply.
-
-`gcc.c-torture/execute/ieee'
- This contains tests which are specific to IEEE floating point.
-
-`gcc.c-torture/unsorted'
- FIXME: describe this.
-
- This directory should probably not be used for new tests.
-
-`gcc.misc-tests'
- This directory contains C tests that require special handling.
- Some of these tests have individual expect files, and others share
- special-purpose expect files:
-
- ``bprob*.c''
- Test `-fbranch-probabilities' using
- `gcc.misc-tests/bprob.exp', which in turn uses the generic,
- language-independent framework (*note Support for testing
- profile-directed optimizations: profopt Testing.).
-
- ``gcov*.c''
- Test `gcov' output using `gcov.exp', which in turn uses the
- language-independent support (*note Support for testing gcov:
- gcov Testing.).
-
- ``i386-pf-*.c''
- Test i386-specific support for data prefetch using
- `i386-prefetch.exp'.
-
-`gcc.test-framework'
-
- ``dg-*.c''
- Test the testsuite itself using
- `gcc.test-framework/test-framework.exp'.
-
-
- FIXME: merge in `testsuite/README.gcc' and discuss the format of test
-cases and magic comments more.
-
-
-File: gccint.info, Node: libgcj Tests, Next: LTO Testing, Prev: C Tests, Up: Testsuites
-
-7.5 The Java library testsuites.
-================================
-
-Runtime tests are executed via `make check' in the
-`TARGET/libjava/testsuite' directory in the build tree. Additional
-runtime tests can be checked into this testsuite.
-
- Regression testing of the core packages in libgcj is also covered by
-the Mauve testsuite. The Mauve Project develops tests for the Java
-Class Libraries. These tests are run as part of libgcj testing by
-placing the Mauve tree within the libjava testsuite sources at
-`libjava/testsuite/libjava.mauve/mauve', or by specifying the location
-of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'.
-
- To detect regressions, a mechanism in `mauve.exp' compares the
-failures for a test run against the list of expected failures in
-`libjava/testsuite/libjava.mauve/xfails' from the source hierarchy.
-Update this file when adding new failing tests to Mauve, or when fixing
-bugs in libgcj that had caused Mauve test failures.
-
- We encourage developers to contribute test cases to Mauve.
-
-
-File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: libgcj Tests, Up: Testsuites
-
-7.6 Support for testing link-time optimizations
-===============================================
-
-Tests for link-time optimizations usually require multiple source files
-that are compiled separately, perhaps with different sets of options.
-There are several special-purpose test directives used for these tests.
-
-`{ dg-lto-do DO-WHAT-KEYWORD }'
- DO-WHAT-KEYWORD specifies how the test is compiled and whether it
- is executed. It is one of:
-
- `assemble'
- Compile with `-c' to produce a relocatable object file.
-
- `link'
- Compile, assemble, and link to produce an executable file.
-
- `run'
- Produce and run an executable file, which is expected to
- return an exit code of 0.
-
- The default is `assemble'. That can be overridden for a set of
- tests by redefining `dg-do-what-default' within the `.exp' file
- for those tests.
-
- Unlike `dg-do', `dg-lto-do' does not support an optional `target'
- or `xfail' list. Use `dg-skip-if', `dg-xfail-if', or
- `dg-xfail-run-if'.
-
-`{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}'
- This directive provides a list of one or more sets of compiler
- options to override LTO_OPTIONS. Each test will be compiled and
- run with each of these sets of options.
-
-`{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}'
- This directive adds OPTIONS to the linker options used.
-
-`{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}'
- This directive removes OPTIONS from the set of linker options used.
-
-
-File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites
-
-7.7 Support for testing `gcov'
-==============================
-
-Language-independent support for testing `gcov', and for checking that
-branch profiling produces expected values, is provided by the expect
-file `lib/gcov.exp'. `gcov' tests also rely on procedures in
-`lib/gcc-dg.exp' to compile and run the test program. A typical `gcov'
-test contains the following DejaGnu commands within comments:
-
- { dg-options "-fprofile-arcs -ftest-coverage" }
- { dg-do run { target native } }
- { dg-final { run-gcov sourcefile } }
-
- Checks of `gcov' output can include line counts, branch percentages,
-and call return percentages. All of these checks are requested via
-commands that appear in comments in the test's source file. Commands
-to check line counts are processed by default. Commands to check
-branch percentages and call return percentages are processed if the
-`run-gcov' command has arguments `branches' or `calls', respectively.
-For example, the following specifies checking both, as well as passing
-`-b' to `gcov':
-
- { dg-final { run-gcov branches calls { -b sourcefile } } }
-
- A line count command appears within a comment on the source line that
-is expected to get the specified count and has the form `count(CNT)'.
-A test should only check line counts for lines that will get the same
-count for any architecture.
-
- Commands to check branch percentages (`branch') and call return
-percentages (`returns') are very similar to each other. A beginning
-command appears on or before the first of a range of lines that will
-report the percentage, and the ending command follows that range of
-lines. The beginning command can include a list of percentages, all of
-which are expected to be found within the range. A range is terminated
-by the next command of the same kind. A command `branch(end)' or
-`returns(end)' marks the end of a range without starting a new one.
-For example:
-
- if (i > 10 && j > i && j < 20) /* branch(27 50 75) */
- /* branch(end) */
- foo (i, j);
-
- For a call return percentage, the value specified is the percentage of
-calls reported to return. For a branch percentage, the value is either
-the expected percentage or 100 minus that value, since the direction of
-a branch can differ depending on the target or the optimization level.
-
- Not all branches and calls need to be checked. A test should not
-check for branches that might be optimized away or replaced with
-predicated instructions. Don't check for calls inserted by the
-compiler or ones that might be inlined or optimized away.
-
- A single test can check for combinations of line counts, branch
-percentages, and call return percentages. The command to check a line
-count must appear on the line that will report that count, but commands
-to check branch percentages and call return percentages can bracket the
-lines that report them.
-
-
-File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites
-
-7.8 Support for testing profile-directed optimizations
-======================================================
-
-The file `profopt.exp' provides language-independent support for
-checking correct execution of a test built with profile-directed
-optimization. This testing requires that a test program be built and
-executed twice. The first time it is compiled to generate profile
-data, and the second time it is compiled to use the data that was
-generated during the first execution. The second execution is to
-verify that the test produces the expected results.
-
- To check that the optimization actually generated better code, a test
-can be built and run a third time with normal optimizations to verify
-that the performance is better with the profile-directed optimizations.
-`profopt.exp' has the beginnings of this kind of support.
-
- `profopt.exp' provides generic support for profile-directed
-optimizations. Each set of tests that uses it provides information
-about a specific optimization:
-
-`tool'
- tool being tested, e.g., `gcc'
-
-`profile_option'
- options used to generate profile data
-
-`feedback_option'
- options used to optimize using that profile data
-
-`prof_ext'
- suffix of profile data files
-
-`PROFOPT_OPTIONS'
- list of options with which to run each test, similar to the lists
- for torture tests
-
-`{ dg-final-generate { LOCAL-DIRECTIVE } }'
- This directive is similar to `dg-final', but the LOCAL-DIRECTIVE
- is run after the generation of profile data.
-
-`{ dg-final-use { LOCAL-DIRECTIVE } }'
- The LOCAL-DIRECTIVE is run after the profile data have been used.
-
-
-File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites
-
-7.9 Support for testing binary compatibility
-============================================
-
-The file `compat.exp' provides language-independent support for binary
-compatibility testing. It supports testing interoperability of two
-compilers that follow the same ABI, or of multiple sets of compiler
-options that should not affect binary compatibility. It is intended to
-be used for testsuites that complement ABI testsuites.
-
- A test supported by this framework has three parts, each in a separate
-source file: a main program and two pieces that interact with each
-other to split up the functionality being tested.
-
-`TESTNAME_main.SUFFIX'
- Contains the main program, which calls a function in file
- `TESTNAME_x.SUFFIX'.
-
-`TESTNAME_x.SUFFIX'
- Contains at least one call to a function in `TESTNAME_y.SUFFIX'.
-
-`TESTNAME_y.SUFFIX'
- Shares data with, or gets arguments from, `TESTNAME_x.SUFFIX'.
-
- Within each test, the main program and one functional piece are
-compiled by the GCC under test. The other piece can be compiled by an
-alternate compiler. If no alternate compiler is specified, then all
-three source files are all compiled by the GCC under test. You can
-specify pairs of sets of compiler options. The first element of such a
-pair specifies options used with the GCC under test, and the second
-element of the pair specifies options used with the alternate compiler.
-Each test is compiled with each pair of options.
-
- `compat.exp' defines default pairs of compiler options. These can be
-overridden by defining the environment variable `COMPAT_OPTIONS' as:
-
- COMPAT_OPTIONS="[list [list {TST1} {ALT1}]
- ...[list {TSTN} {ALTN}]]"
-
- where TSTI and ALTI are lists of options, with TSTI used by the
-compiler under test and ALTI used by the alternate compiler. For
-example, with `[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]',
-the test is first built with `-g -O0' by the compiler under test and
-with `-O3' by the alternate compiler. The test is built a second time
-using `-fpic' by the compiler under test and `-fPIC -O2' by the
-alternate compiler.
-
- An alternate compiler is specified by defining an environment variable
-to be the full pathname of an installed compiler; for C define
-`ALT_CC_UNDER_TEST', and for C++ define `ALT_CXX_UNDER_TEST'. These
-will be written to the `site.exp' file used by DejaGnu. The default is
-to build each test with the compiler under test using the first of each
-pair of compiler options from `COMPAT_OPTIONS'. When
-`ALT_CC_UNDER_TEST' or `ALT_CXX_UNDER_TEST' is `same', each test is
-built using the compiler under test but with combinations of the
-options from `COMPAT_OPTIONS'.
-
- To run only the C++ compatibility suite using the compiler under test
-and another version of GCC using specific compiler options, do the
-following from `OBJDIR/gcc':
-
- rm site.exp
- make -k \
- ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \
- COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \
- check-c++ \
- RUNTESTFLAGS="compat.exp"
-
- A test that fails when the source files are compiled with different
-compilers, but passes when the files are compiled with the same
-compiler, demonstrates incompatibility of the generated code or runtime
-support. A test that fails for the alternate compiler but passes for
-the compiler under test probably tests for a bug that was fixed in the
-compiler under test but is present in the alternate compiler.
-
- The binary compatibility tests support a small number of test framework
-commands that appear within comments in a test file.
-
-`dg-require-*'
- These commands can be used in `TESTNAME_main.SUFFIX' to skip the
- test if specific support is not available on the target.
-
-`dg-options'
- The specified options are used for compiling this particular source
- file, appended to the options from `COMPAT_OPTIONS'. When this
- command appears in `TESTNAME_main.SUFFIX' the options are also
- used to link the test program.
-
-`dg-xfail-if'
- This command can be used in a secondary source file to specify that
- compilation is expected to fail for particular options on
- particular targets.
-
-
-File: gccint.info, Node: Torture Tests, Prev: compat Testing, Up: Testsuites
-
-7.10 Support for torture testing using multiple options
-=======================================================
-
-Throughout the compiler testsuite there are several directories whose
-tests are run multiple times, each with a different set of options.
-These are known as torture tests. `lib/torture-options.exp' defines
-procedures to set up these lists:
-
-`torture-init'
- Initialize use of torture lists.
-
-`set-torture-options'
- Set lists of torture options to use for tests with and without
- loops. Optionally combine a set of torture options with a set of
- other options, as is done with Objective-C runtime options.
-
-`torture-finish'
- Finalize use of torture lists.
-
- The `.exp' file for a set of tests that use torture options must
-include calls to these three procedures if:
-
- * It calls `gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS.
-
- * It calls ${TOOL}`-torture' or ${TOOL}`-torture-execute', where
- TOOL is `c', `fortran', or `objc'.
-
- * It calls `dg-pch'.
-
- It is not necessary for a `.exp' file that calls `gcc-dg-runtest' to
-call the torture procedures if the tests should use the list in
-DG_TORTURE_OPTIONS defined in `gcc-dg.exp'.
-
- Most uses of torture options can override the default lists by defining
-TORTURE_OPTIONS or add to the default list by defining
-ADDITIONAL_TORTURE_OPTIONS. Define these in a `.dejagnurc' file or add
-them to the `site.exp' file; for example
-
- set ADDITIONAL_TORTURE_OPTIONS [list \
- { -O2 -ftree-loop-linear } \
- { -O2 -fpeel-loops } ]
-
-
-File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top
-
-8 Option specification files
-****************************
-
-Most GCC command-line options are described by special option
-definition files, the names of which conventionally end in `.opt'.
-This chapter describes the format of these files.
-
-* Menu:
-
-* Option file format:: The general layout of the files
-* Option properties:: Supported option properties
-
-
-File: gccint.info, Node: Option file format, Next: Option properties, Up: Options
-
-8.1 Option file format
-======================
-
-Option files are a simple list of records in which each field occupies
-its own line and in which the records themselves are separated by blank
-lines. Comments may appear on their own line anywhere within the file
-and are preceded by semicolons. Whitespace is allowed before the
-semicolon.
-
- The files can contain the following types of record:
-
- * A language definition record. These records have two fields: the
- string `Language' and the name of the language. Once a language
- has been declared in this way, it can be used as an option
- property. *Note Option properties::.
-
- * A target specific save record to save additional information. These
- records have two fields: the string `TargetSave', and a
- declaration type to go in the `cl_target_option' structure.
-
- * A variable record to define a variable used to store option
- information. These records have two fields: the string
- `Variable', and a declaration of the type and name of the
- variable, optionally with an initializer (but without any trailing
- `;'). These records may be used for variables used for many
- options where declaring the initializer in a single option
- definition record, or duplicating it in many records, would be
- inappropriate, or for variables set in option handlers rather than
- referenced by `Var' properties.
-
- * A variable record to define a variable used to store option
- information. These records have two fields: the string
- `TargetVariable', and a declaration of the type and name of the
- variable, optionally with an initializer (but without any trailing
- `;'). `TargetVariable' is a combination of `Variable' and
- `TargetSave' records in that the variable is defined in the
- `gcc_options' structure, but these variables are also stored in
- the `cl_target_option' structure. The variables are saved in the
- target save code and restored in the target restore code.
-
- * A variable record to record any additional files that the
- `options.h' file should include. This is useful to provide
- enumeration or structure definitions needed for target variables.
- These records have two fields: the string `HeaderInclude' and the
- name of the include file.
-
- * A variable record to record any additional files that the
- `options.c' file should include. This is useful to provide inline
- functions needed for target variables and/or `#ifdef' sequences to
- properly set up the initialization. These records have two
- fields: the string `SourceInclude' and the name of the include
- file.
-
- * An enumeration record to define a set of strings that may be used
- as arguments to an option or options. These records have three
- fields: the string `Enum', a space-separated list of properties
- and help text used to describe the set of strings in `--help'
- output. Properties use the same format as option properties; the
- following are valid:
- `Name(NAME)'
- This property is required; NAME must be a name (suitable for
- use in C identifiers) used to identify the set of strings in
- `Enum' option properties.
-
- `Type(TYPE)'
- This property is required; TYPE is the C type for variables
- set by options using this enumeration together with `Var'.
-
- `UnknownError(MESSAGE)'
- The message MESSAGE will be used as an error message if the
- argument is invalid; for enumerations without `UnknownError',
- a generic error message is used. MESSAGE should contain a
- single `%qs' format, which will be used to format the invalid
- argument.
-
- * An enumeration value record to define one of the strings in a set
- given in an `Enum' record. These records have two fields: the
- string `EnumValue' and a space-separated list of properties.
- Properties use the same format as option properties; the following
- are valid:
- `Enum(NAME)'
- This property is required; NAME says which `Enum' record this
- `EnumValue' record corresponds to.
-
- `String(STRING)'
- This property is required; STRING is the string option
- argument being described by this record.
-
- `Value(VALUE)'
- This property is required; it says what value (representable
- as `int') should be used for the given string.
-
- `Canonical'
- This property is optional. If present, it says the present
- string is the canonical one among all those with the given
- value. Other strings yielding that value will be mapped to
- this one so specs do not need to handle them.
-
- `DriverOnly'
- This property is optional. If present, the present string
- will only be accepted by the driver. This is used for cases
- such as `-march=native' that are processed by the driver so
- that `gcc -v' shows how the options chosen depended on the
- system on which the compiler was run.
-
- * An option definition record. These records have the following
- fields:
- 1. the name of the option, with the leading "-" removed
-
- 2. a space-separated list of option properties (*note Option
- properties::)
-
- 3. the help text to use for `--help' (omitted if the second field
- contains the `Undocumented' property).
-
- By default, all options beginning with "f", "W" or "m" are
- implicitly assumed to take a "no-" form. This form should not be
- listed separately. If an option beginning with one of these
- letters does not have a "no-" form, you can use the
- `RejectNegative' property to reject it.
-
- The help text is automatically line-wrapped before being displayed.
- Normally the name of the option is printed on the left-hand side of
- the output and the help text is printed on the right. However, if
- the help text contains a tab character, the text to the left of
- the tab is used instead of the option's name and the text to the
- right of the tab forms the help text. This allows you to
- elaborate on what type of argument the option takes.
-
- * A target mask record. These records have one field of the form
- `Mask(X)'. The options-processing script will automatically
- allocate a bit in `target_flags' (*note Run-time Target::) for
- each mask name X and set the macro `MASK_X' to the appropriate
- bitmask. It will also declare a `TARGET_X' macro that has the
- value 1 when bit `MASK_X' is set and 0 otherwise.
-
- They are primarily intended to declare target masks that are not
- associated with user options, either because these masks represent
- internal switches or because the options are not available on all
- configurations and yet the masks always need to be defined.
-
-
-File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options
-
-8.2 Option properties
-=====================
-
-The second field of an option record can specify any of the following
-properties. When an option takes an argument, it is enclosed in
-parentheses following the option property name. The parser that
-handles option files is quite simplistic, and will be tricked by any
-nested parentheses within the argument text itself; in this case, the
-entire option argument can be wrapped in curly braces within the
-parentheses to demarcate it, e.g.:
-
- Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)})
-
-`Common'
- The option is available for all languages and targets.
-
-`Target'
- The option is available for all languages but is target-specific.
-
-`Driver'
- The option is handled by the compiler driver using code not shared
- with the compilers proper (`cc1' etc.).
-
-`LANGUAGE'
- The option is available when compiling for the given language.
-
- It is possible to specify several different languages for the same
- option. Each LANGUAGE must have been declared by an earlier
- `Language' record. *Note Option file format::.
-
-`RejectDriver'
- The option is only handled by the compilers proper (`cc1' etc.)
- and should not be accepted by the driver.
-
-`RejectNegative'
- The option does not have a "no-" form. All options beginning with
- "f", "W" or "m" are assumed to have a "no-" form unless this
- property is used.
-
-`Negative(OTHERNAME)'
- The option will turn off another option OTHERNAME, which is the
- option name with the leading "-" removed. This chain action will
- propagate through the `Negative' property of the option to be
- turned off.
-
-`Joined'
-`Separate'
- The option takes a mandatory argument. `Joined' indicates that
- the option and argument can be included in the same `argv' entry
- (as with `-mflush-func=NAME', for example). `Separate' indicates
- that the option and argument can be separate `argv' entries (as
- with `-o'). An option is allowed to have both of these properties.
-
-`JoinedOrMissing'
- The option takes an optional argument. If the argument is given,
- it will be part of the same `argv' entry as the option itself.
-
- This property cannot be used alongside `Joined' or `Separate'.
-
-`MissingArgError(MESSAGE)'
- For an option marked `Joined' or `Separate', the message MESSAGE
- will be used as an error message if the mandatory argument is
- missing; for options without `MissingArgError', a generic error
- message is used. MESSAGE should contain a single `%qs' format,
- which will be used to format the name of the option passed.
-
-`Args(N)'
- For an option marked `Separate', indicate that it takes N
- arguments. The default is 1.
-
-`UInteger'
- The option's argument is a non-negative integer. The option parser
- will check and convert the argument before passing it to the
- relevant option handler. `UInteger' should also be used on
- options like `-falign-loops' where both `-falign-loops' and
- `-falign-loops'=N are supported to make sure the saved options are
- given a full integer.
-
-`NoDriverArg'
- For an option marked `Separate', the option only takes an argument
- in the compiler proper, not in the driver. This is for
- compatibility with existing options that are used both directly and
- via `-Wp,'; new options should not have this property.
-
-`Var(VAR)'
- The state of this option should be stored in variable VAR
- (actually a macro for `global_options.x_VAR'). The way that the
- state is stored depends on the type of option:
-
- * If the option uses the `Mask' or `InverseMask' properties,
- VAR is the integer variable that contains the mask.
-
- * If the option is a normal on/off switch, VAR is an integer
- variable that is nonzero when the option is enabled. The
- options parser will set the variable to 1 when the positive
- form of the option is used and 0 when the "no-" form is used.
-
- * If the option takes an argument and has the `UInteger'
- property, VAR is an integer variable that stores the value of
- the argument.
-
- * If the option takes an argument and has the `Enum' property,
- VAR is a variable (type given in the `Type' property of the
- `Enum' record whose `Name' property has the same argument as
- the `Enum' property of this option) that stores the value of
- the argument.
-
- * If the option has the `Defer' property, VAR is a pointer to a
- `VEC(cl_deferred_option,heap)' that stores the option for
- later processing. (VAR is declared with type `void *' and
- needs to be cast to `VEC(cl_deferred_option,heap)' before
- use.)
-
- * Otherwise, if the option takes an argument, VAR is a pointer
- to the argument string. The pointer will be null if the
- argument is optional and wasn't given.
-
- The option-processing script will usually zero-initialize VAR.
- You can modify this behavior using `Init'.
-
-`Var(VAR, SET)'
- The option controls an integer variable VAR and is active when VAR
- equals SET. The option parser will set VAR to SET when the
- positive form of the option is used and `!SET' when the "no-" form
- is used.
-
- VAR is declared in the same way as for the single-argument form
- described above.
-
-`Init(VALUE)'
- The variable specified by the `Var' property should be statically
- initialized to VALUE. If more than one option using the same
- variable specifies `Init', all must specify the same initializer.
-
-`Mask(NAME)'
- The option is associated with a bit in the `target_flags' variable
- (*note Run-time Target::) and is active when that bit is set. You
- may also specify `Var' to select a variable other than
- `target_flags'.
-
- The options-processing script will automatically allocate a unique
- bit for the option. If the option is attached to `target_flags',
- the script will set the macro `MASK_NAME' to the appropriate
- bitmask. It will also declare a `TARGET_NAME' macro that has the
- value 1 when the option is active and 0 otherwise. If you use
- `Var' to attach the option to a different variable, the associated
- macros are called `OPTION_MASK_NAME' and `OPTION_NAME'
- respectively.
-
- You can disable automatic bit allocation using `MaskExists'.
-
-`InverseMask(OTHERNAME)'
-`InverseMask(OTHERNAME, THISNAME)'
- The option is the inverse of another option that has the
- `Mask(OTHERNAME)' property. If THISNAME is given, the
- options-processing script will declare a `TARGET_THISNAME' macro
- that is 1 when the option is active and 0 otherwise.
-
-`MaskExists'
- The mask specified by the `Mask' property already exists. No
- `MASK' or `TARGET' definitions should be added to `options.h' in
- response to this option record.
-
- The main purpose of this property is to support synonymous options.
- The first option should use `Mask(NAME)' and the others should use
- `Mask(NAME) MaskExists'.
-
-`Enum(NAME)'
- The option's argument is a string from the set of strings
- associated with the corresponding `Enum' record. The string is
- checked and converted to the integer specified in the corresponding
- `EnumValue' record before being passed to option handlers.
-
-`Defer'
- The option should be stored in a vector, specified with `Var', for
- later processing.
-
-`Alias(OPT)'
-`Alias(OPT, ARG)'
-`Alias(OPT, POSARG, NEGARG)'
- The option is an alias for `-OPT'. In the first form, any
- argument passed to the alias is considered to be passed to `-OPT',
- and `-OPT' is considered to be negated if the alias is used in
- negated form. In the second form, the alias may not be negated or
- have an argument, and POSARG is considered to be passed as an
- argument to `-OPT'. In the third form, the alias may not have an
- argument, if the alias is used in the positive form then POSARG is
- considered to be passed to `-OPT', and if the alias is used in the
- negative form then NEGARG is considered to be passed to `-OPT'.
-
- Aliases should not specify `Var' or `Mask' or `UInteger'. Aliases
- should normally specify the same languages as the target of the
- alias; the flags on the target will be used to determine any
- diagnostic for use of an option for the wrong language, while
- those on the alias will be used to identify what command-line text
- is the option and what text is any argument to that option.
-
- When an `Alias' definition is used for an option, driver specs do
- not need to handle it and no `OPT_' enumeration value is defined
- for it; only the canonical form of the option will be seen in those
- places.
-
-`Ignore'
- This option is ignored apart from printing any warning specified
- using `Warn'. The option will not be seen by specs and no `OPT_'
- enumeration value is defined for it.
-
-`SeparateAlias'
- For an option marked with `Joined', `Separate' and `Alias', the
- option only acts as an alias when passed a separate argument; with
- a joined argument it acts as a normal option, with an `OPT_'
- enumeration value. This is for compatibility with the Java `-d'
- option and should not be used for new options.
-
-`Warn(MESSAGE)'
- If this option is used, output the warning MESSAGE. MESSAGE is a
- format string, either taking a single operand with a `%qs' format
- which is the option name, or not taking any operands, which is
- passed to the `warning' function. If an alias is marked `Warn',
- the target of the alias must not also be marked `Warn'.
-
-`Report'
- The state of the option should be printed by `-fverbose-asm'.
-
-`Warning'
- This is a warning option and should be shown as such in `--help'
- output. This flag does not currently affect anything other than
- `--help'.
-
-`Optimization'
- This is an optimization option. It should be shown as such in
- `--help' output, and any associated variable named using `Var'
- should be saved and restored when the optimization level is
- changed with `optimize' attributes.
-
-`Undocumented'
- The option is deliberately missing documentation and should not be
- included in the `--help' output.
-
-`Condition(COND)'
- The option should only be accepted if preprocessor condition COND
- is true. Note that any C declarations associated with the option
- will be present even if COND is false; COND simply controls
- whether the option is accepted and whether it is printed in the
- `--help' output.
-
-`Save'
- Build the `cl_target_option' structure to hold a copy of the
- option, add the functions `cl_target_option_save' and
- `cl_target_option_restore' to save and restore the options.
-
-`SetByCombined'
- The option may also be set by a combined option such as
- `-ffast-math'. This causes the `gcc_options' struct to have a
- field `frontend_set_NAME', where `NAME' is the name of the field
- holding the value of this option (without the leading `x_'). This
- gives the front end a way to indicate that the value has been set
- explicitly and should not be changed by the combined option. For
- example, some front ends use this to prevent `-ffast-math' and
- `-fno-fast-math' from changing the value of `-fmath-errno' for
- languages that do not use `errno'.
-
-
-
-File: gccint.info, Node: Passes, Next: GENERIC, Prev: Options, Up: Top
-
-9 Passes and Files of the Compiler
-**********************************
-
-This chapter is dedicated to giving an overview of the optimization and
-code generation passes of the compiler. In the process, it describes
-some of the language front end interface, though this description is no
-where near complete.
-
-* Menu:
-
-* Parsing pass:: The language front end turns text into bits.
-* Gimplification pass:: The bits are turned into something we can optimize.
-* Pass manager:: Sequencing the optimization passes.
-* Tree SSA passes:: Optimizations on a high-level representation.
-* RTL passes:: Optimizations on a low-level representation.
-
-
-File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes
-
-9.1 Parsing pass
-================
-
-The language front end is invoked only once, via
-`lang_hooks.parse_file', to parse the entire input. The language front
-end may use any intermediate language representation deemed
-appropriate. The C front end uses GENERIC trees (*note GENERIC::), plus
-a double handful of language specific tree codes defined in
-`c-common.def'. The Fortran front end uses a completely different
-private representation.
-
- At some point the front end must translate the representation used in
-the front end to a representation understood by the language-independent
-portions of the compiler. Current practice takes one of two forms.
-The C front end manually invokes the gimplifier (*note GIMPLE::) on
-each function, and uses the gimplifier callbacks to convert the
-language-specific tree nodes directly to GIMPLE before passing the
-function off to be compiled. The Fortran front end converts from a
-private representation to GENERIC, which is later lowered to GIMPLE
-when the function is compiled. Which route to choose probably depends
-on how well GENERIC (plus extensions) can be made to match up with the
-source language and necessary parsing data structures.
-
- BUG: Gimplification must occur before nested function lowering, and
-nested function lowering must be done by the front end before passing
-the data off to cgraph.
-
- TODO: Cgraph should control nested function lowering. It would only
-be invoked when it is certain that the outer-most function is used.
-
- TODO: Cgraph needs a gimplify_function callback. It should be invoked
-when (1) it is certain that the function is used, (2) warning flags
-specified by the user require some amount of compilation in order to
-honor, (3) the language indicates that semantic analysis is not
-complete until gimplification occurs. Hum... this sounds overly
-complicated. Perhaps we should just have the front end gimplify
-always; in most cases it's only one function call.
-
- The front end needs to pass all function definitions and top level
-declarations off to the middle-end so that they can be compiled and
-emitted to the object file. For a simple procedural language, it is
-usually most convenient to do this as each top level declaration or
-definition is seen. There is also a distinction to be made between
-generating functional code and generating complete debug information.
-The only thing that is absolutely required for functional code is that
-function and data _definitions_ be passed to the middle-end. For
-complete debug information, function, data and type declarations should
-all be passed as well.
-
- In any case, the front end needs each complete top-level function or
-data declaration, and each data definition should be passed to
-`rest_of_decl_compilation'. Each complete type definition should be
-passed to `rest_of_type_compilation'. Each function definition should
-be passed to `cgraph_finalize_function'.
-
- TODO: I know rest_of_compilation currently has all sorts of RTL
-generation semantics. I plan to move all code generation bits (both
-Tree and RTL) to compile_function. Should we hide cgraph from the
-front ends and move back to rest_of_compilation as the official
-interface? Possibly we should rename all three interfaces such that
-the names match in some meaningful way and that is more descriptive
-than "rest_of".
-
- The middle-end will, at its option, emit the function and data
-definitions immediately or queue them for later processing.
-
-
-File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes
-
-9.2 Gimplification pass
-=======================
-
-"Gimplification" is a whimsical term for the process of converting the
-intermediate representation of a function into the GIMPLE language
-(*note GIMPLE::). The term stuck, and so words like "gimplification",
-"gimplify", "gimplifier" and the like are sprinkled throughout this
-section of code.
-
- While a front end may certainly choose to generate GIMPLE directly if
-it chooses, this can be a moderately complex process unless the
-intermediate language used by the front end is already fairly simple.
-Usually it is easier to generate GENERIC trees plus extensions and let
-the language-independent gimplifier do most of the work.
-
- The main entry point to this pass is `gimplify_function_tree' located
-in `gimplify.c'. From here we process the entire function gimplifying
-each statement in turn. The main workhorse for this pass is
-`gimplify_expr'. Approximately everything passes through here at least
-once, and it is from here that we invoke the `lang_hooks.gimplify_expr'
-callback.
-
- The callback should examine the expression in question and return
-`GS_UNHANDLED' if the expression is not a language specific construct
-that requires attention. Otherwise it should alter the expression in
-some way to such that forward progress is made toward producing valid
-GIMPLE. If the callback is certain that the transformation is complete
-and the expression is valid GIMPLE, it should return `GS_ALL_DONE'.
-Otherwise it should return `GS_OK', which will cause the expression to
-be processed again. If the callback encounters an error during the
-transformation (because the front end is relying on the gimplification
-process to finish semantic checks), it should return `GS_ERROR'.
-
-
-File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes
-
-9.3 Pass manager
-================
-
-The pass manager is located in `passes.c', `tree-optimize.c' and
-`tree-pass.h'. Its job is to run all of the individual passes in the
-correct order, and take care of standard bookkeeping that applies to
-every pass.
-
- The theory of operation is that each pass defines a structure that
-represents everything we need to know about that pass--when it should
-be run, how it should be run, what intermediate language form or
-on-the-side data structures it needs. We register the pass to be run
-in some particular order, and the pass manager arranges for everything
-to happen in the correct order.
-
- The actuality doesn't completely live up to the theory at present.
-Command-line switches and `timevar_id_t' enumerations must still be
-defined elsewhere. The pass manager validates constraints but does not
-attempt to (re-)generate data structures or lower intermediate language
-form based on the requirements of the next pass. Nevertheless, what is
-present is useful, and a far sight better than nothing at all.
-
- Each pass should have a unique name. Each pass may have its own dump
-file (for GCC debugging purposes). Passes with a name starting with a
-star do not dump anything. Sometimes passes are supposed to share a
-dump file / option name. To still give these unique names, you can use
-a prefix that is delimited by a space from the part that is used for
-the dump file / option name. E.g. When the pass name is "ud dce", the
-name used for dump file/options is "dce".
-
- TODO: describe the global variables set up by the pass manager, and a
-brief description of how a new pass should use it. I need to look at
-what info RTL passes use first...
-
-
-File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes
-
-9.4 Tree SSA passes
-===================
-
-The following briefly describes the Tree optimization passes that are
-run after gimplification and what source files they are located in.
-
- * Remove useless statements
-
- This pass is an extremely simple sweep across the gimple code in
- which we identify obviously dead code and remove it. Here we do
- things like simplify `if' statements with constant conditions,
- remove exception handling constructs surrounding code that
- obviously cannot throw, remove lexical bindings that contain no
- variables, and other assorted simplistic cleanups. The idea is to
- get rid of the obvious stuff quickly rather than wait until later
- when it's more work to get rid of it. This pass is located in
- `tree-cfg.c' and described by `pass_remove_useless_stmts'.
-
- * Mudflap declaration registration
-
- If mudflap (*note -fmudflap -fmudflapth -fmudflapir: (gcc)Optimize
- Options.) is enabled, we generate code to register some variable
- declarations with the mudflap runtime. Specifically, the runtime
- tracks the lifetimes of those variable declarations that have
- their addresses taken, or whose bounds are unknown at compile time
- (`extern'). This pass generates new exception handling constructs
- (`try'/`finally'), and so must run before those are lowered. In
- addition, the pass enqueues declarations of static variables whose
- lifetimes extend to the entire program. The pass is located in
- `tree-mudflap.c' and is described by `pass_mudflap_1'.
-
- * OpenMP lowering
-
- If OpenMP generation (`-fopenmp') is enabled, this pass lowers
- OpenMP constructs into GIMPLE.
-
- Lowering of OpenMP constructs involves creating replacement
- expressions for local variables that have been mapped using data
- sharing clauses, exposing the control flow of most synchronization
- directives and adding region markers to facilitate the creation of
- the control flow graph. The pass is located in `omp-low.c' and is
- described by `pass_lower_omp'.
-
- * OpenMP expansion
-
- If OpenMP generation (`-fopenmp') is enabled, this pass expands
- parallel regions into their own functions to be invoked by the
- thread library. The pass is located in `omp-low.c' and is
- described by `pass_expand_omp'.
-
- * Lower control flow
-
- This pass flattens `if' statements (`COND_EXPR') and moves lexical
- bindings (`BIND_EXPR') out of line. After this pass, all `if'
- statements will have exactly two `goto' statements in its `then'
- and `else' arms. Lexical binding information for each statement
- will be found in `TREE_BLOCK' rather than being inferred from its
- position under a `BIND_EXPR'. This pass is found in
- `gimple-low.c' and is described by `pass_lower_cf'.
-
- * Lower exception handling control flow
-
- This pass decomposes high-level exception handling constructs
- (`TRY_FINALLY_EXPR' and `TRY_CATCH_EXPR') into a form that
- explicitly represents the control flow involved. After this pass,
- `lookup_stmt_eh_region' will return a non-negative number for any
- statement that may have EH control flow semantics; examine
- `tree_can_throw_internal' or `tree_can_throw_external' for exact
- semantics. Exact control flow may be extracted from
- `foreach_reachable_handler'. The EH region nesting tree is defined
- in `except.h' and built in `except.c'. The lowering pass itself
- is in `tree-eh.c' and is described by `pass_lower_eh'.
-
- * Build the control flow graph
-
- This pass decomposes a function into basic blocks and creates all
- of the edges that connect them. It is located in `tree-cfg.c' and
- is described by `pass_build_cfg'.
-
- * Find all referenced variables
-
- This pass walks the entire function and collects an array of all
- variables referenced in the function, `referenced_vars'. The
- index at which a variable is found in the array is used as a UID
- for the variable within this function. This data is needed by the
- SSA rewriting routines. The pass is located in `tree-dfa.c' and
- is described by `pass_referenced_vars'.
-
- * Enter static single assignment form
-
- This pass rewrites the function such that it is in SSA form. After
- this pass, all `is_gimple_reg' variables will be referenced by
- `SSA_NAME', and all occurrences of other variables will be
- annotated with `VDEFS' and `VUSES'; PHI nodes will have been
- inserted as necessary for each basic block. This pass is located
- in `tree-ssa.c' and is described by `pass_build_ssa'.
-
- * Warn for uninitialized variables
-
- This pass scans the function for uses of `SSA_NAME's that are fed
- by default definition. For non-parameter variables, such uses are
- uninitialized. The pass is run twice, before and after
- optimization (if turned on). In the first pass we only warn for
- uses that are positively uninitialized; in the second pass we warn
- for uses that are possibly uninitialized. The pass is located in
- `tree-ssa.c' and is defined by `pass_early_warn_uninitialized' and
- `pass_late_warn_uninitialized'.
-
- * Dead code elimination
-
- This pass scans the function for statements without side effects
- whose result is unused. It does not do memory life analysis, so
- any value that is stored in memory is considered used. The pass
- is run multiple times throughout the optimization process. It is
- located in `tree-ssa-dce.c' and is described by `pass_dce'.
-
- * Dominator optimizations
-
- This pass performs trivial dominator-based copy and constant
- propagation, expression simplification, and jump threading. It is
- run multiple times throughout the optimization process. It is
- located in `tree-ssa-dom.c' and is described by `pass_dominator'.
-
- * Forward propagation of single-use variables
-
- This pass attempts to remove redundant computation by substituting
- variables that are used once into the expression that uses them and
- seeing if the result can be simplified. It is located in
- `tree-ssa-forwprop.c' and is described by `pass_forwprop'.
-
- * Copy Renaming
-
- This pass attempts to change the name of compiler temporaries
- involved in copy operations such that SSA->normal can coalesce the
- copy away. When compiler temporaries are copies of user
- variables, it also renames the compiler temporary to the user
- variable resulting in better use of user symbols. It is located
- in `tree-ssa-copyrename.c' and is described by `pass_copyrename'.
-
- * PHI node optimizations
-
- This pass recognizes forms of PHI inputs that can be represented as
- conditional expressions and rewrites them into straight line code.
- It is located in `tree-ssa-phiopt.c' and is described by
- `pass_phiopt'.
-
- * May-alias optimization
-
- This pass performs a flow sensitive SSA-based points-to analysis.
- The resulting may-alias, must-alias, and escape analysis
- information is used to promote variables from in-memory
- addressable objects to non-aliased variables that can be renamed
- into SSA form. We also update the `VDEF'/`VUSE' memory tags for
- non-renameable aggregates so that we get fewer false kills. The
- pass is located in `tree-ssa-alias.c' and is described by
- `pass_may_alias'.
-
- Interprocedural points-to information is located in
- `tree-ssa-structalias.c' and described by `pass_ipa_pta'.
-
- * Profiling
-
- This pass rewrites the function in order to collect runtime block
- and value profiling data. Such data may be fed back into the
- compiler on a subsequent run so as to allow optimization based on
- expected execution frequencies. The pass is located in
- `predict.c' and is described by `pass_profile'.
-
- * Lower complex arithmetic
-
- This pass rewrites complex arithmetic operations into their
- component scalar arithmetic operations. The pass is located in
- `tree-complex.c' and is described by `pass_lower_complex'.
-
- * Scalar replacement of aggregates
-
- This pass rewrites suitable non-aliased local aggregate variables
- into a set of scalar variables. The resulting scalar variables are
- rewritten into SSA form, which allows subsequent optimization
- passes to do a significantly better job with them. The pass is
- located in `tree-sra.c' and is described by `pass_sra'.
-
- * Dead store elimination
-
- This pass eliminates stores to memory that are subsequently
- overwritten by another store, without any intervening loads. The
- pass is located in `tree-ssa-dse.c' and is described by `pass_dse'.
-
- * Tail recursion elimination
-
- This pass transforms tail recursion into a loop. It is located in
- `tree-tailcall.c' and is described by `pass_tail_recursion'.
-
- * Forward store motion
-
- This pass sinks stores and assignments down the flowgraph closer
- to their use point. The pass is located in `tree-ssa-sink.c' and
- is described by `pass_sink_code'.
-
- * Partial redundancy elimination
-
- This pass eliminates partially redundant computations, as well as
- performing load motion. The pass is located in `tree-ssa-pre.c'
- and is described by `pass_pre'.
-
- Just before partial redundancy elimination, if
- `-funsafe-math-optimizations' is on, GCC tries to convert
- divisions to multiplications by the reciprocal. The pass is
- located in `tree-ssa-math-opts.c' and is described by
- `pass_cse_reciprocal'.
-
- * Full redundancy elimination
-
- This is a simpler form of PRE that only eliminates redundancies
- that occur an all paths. It is located in `tree-ssa-pre.c' and
- described by `pass_fre'.
-
- * Loop optimization
-
- The main driver of the pass is placed in `tree-ssa-loop.c' and
- described by `pass_loop'.
-
- The optimizations performed by this pass are:
-
- Loop invariant motion. This pass moves only invariants that would
- be hard to handle on RTL level (function calls, operations that
- expand to nontrivial sequences of insns). With `-funswitch-loops'
- it also moves operands of conditions that are invariant out of the
- loop, so that we can use just trivial invariantness analysis in
- loop unswitching. The pass also includes store motion. The pass
- is implemented in `tree-ssa-loop-im.c'.
-
- Canonical induction variable creation. This pass creates a simple
- counter for number of iterations of the loop and replaces the exit
- condition of the loop using it, in case when a complicated
- analysis is necessary to determine the number of iterations.
- Later optimizations then may determine the number easily. The
- pass is implemented in `tree-ssa-loop-ivcanon.c'.
-
- Induction variable optimizations. This pass performs standard
- induction variable optimizations, including strength reduction,
- induction variable merging and induction variable elimination.
- The pass is implemented in `tree-ssa-loop-ivopts.c'.
-
- Loop unswitching. This pass moves the conditional jumps that are
- invariant out of the loops. To achieve this, a duplicate of the
- loop is created for each possible outcome of conditional jump(s).
- The pass is implemented in `tree-ssa-loop-unswitch.c'. This pass
- should eventually replace the RTL level loop unswitching in
- `loop-unswitch.c', but currently the RTL level pass is not
- completely redundant yet due to deficiencies in tree level alias
- analysis.
-
- The optimizations also use various utility functions contained in
- `tree-ssa-loop-manip.c', `cfgloop.c', `cfgloopanal.c' and
- `cfgloopmanip.c'.
-
- Vectorization. This pass transforms loops to operate on vector
- types instead of scalar types. Data parallelism across loop
- iterations is exploited to group data elements from consecutive
- iterations into a vector and operate on them in parallel.
- Depending on available target support the loop is conceptually
- unrolled by a factor `VF' (vectorization factor), which is the
- number of elements operated upon in parallel in each iteration,
- and the `VF' copies of each scalar operation are fused to form a
- vector operation. Additional loop transformations such as peeling
- and versioning may take place to align the number of iterations,
- and to align the memory accesses in the loop. The pass is
- implemented in `tree-vectorizer.c' (the main driver),
- `tree-vect-loop.c' and `tree-vect-loop-manip.c' (loop specific
- parts and general loop utilities), `tree-vect-slp' (loop-aware SLP
- functionality), `tree-vect-stmts.c' and `tree-vect-data-refs.c'.
- Analysis of data references is in `tree-data-ref.c'.
-
- SLP Vectorization. This pass performs vectorization of
- straight-line code. The pass is implemented in `tree-vectorizer.c'
- (the main driver), `tree-vect-slp.c', `tree-vect-stmts.c' and
- `tree-vect-data-refs.c'.
-
- Autoparallelization. This pass splits the loop iteration space to
- run into several threads. The pass is implemented in
- `tree-parloops.c'.
-
- Graphite is a loop transformation framework based on the polyhedral
- model. Graphite stands for Gimple Represented as Polyhedra. The
- internals of this infrastructure are documented in
- `http://gcc.gnu.org/wiki/Graphite'. The passes working on this
- representation are implemented in the various `graphite-*' files.
-
- * Tree level if-conversion for vectorizer
-
- This pass applies if-conversion to simple loops to help vectorizer.
- We identify if convertible loops, if-convert statements and merge
- basic blocks in one big block. The idea is to present loop in such
- form so that vectorizer can have one to one mapping between
- statements and available vector operations. This pass is located
- in `tree-if-conv.c' and is described by `pass_if_conversion'.
-
- * Conditional constant propagation
-
- This pass relaxes a lattice of values in order to identify those
- that must be constant even in the presence of conditional branches.
- The pass is located in `tree-ssa-ccp.c' and is described by
- `pass_ccp'.
-
- A related pass that works on memory loads and stores, and not just
- register values, is located in `tree-ssa-ccp.c' and described by
- `pass_store_ccp'.
-
- * Conditional copy propagation
-
- This is similar to constant propagation but the lattice of values
- is the "copy-of" relation. It eliminates redundant copies from the
- code. The pass is located in `tree-ssa-copy.c' and described by
- `pass_copy_prop'.
-
- A related pass that works on memory copies, and not just register
- copies, is located in `tree-ssa-copy.c' and described by
- `pass_store_copy_prop'.
-
- * Value range propagation
-
- This transformation is similar to constant propagation but instead
- of propagating single constant values, it propagates known value
- ranges. The implementation is based on Patterson's range
- propagation algorithm (Accurate Static Branch Prediction by Value
- Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to
- Patterson's algorithm, this implementation does not propagate
- branch probabilities nor it uses more than a single range per SSA
- name. This means that the current implementation cannot be used
- for branch prediction (though adapting it would not be difficult).
- The pass is located in `tree-vrp.c' and is described by `pass_vrp'.
-
- * Folding built-in functions
-
- This pass simplifies built-in functions, as applicable, with
- constant arguments or with inferable string lengths. It is
- located in `tree-ssa-ccp.c' and is described by
- `pass_fold_builtins'.
-
- * Split critical edges
-
- This pass identifies critical edges and inserts empty basic blocks
- such that the edge is no longer critical. The pass is located in
- `tree-cfg.c' and is described by `pass_split_crit_edges'.
-
- * Control dependence dead code elimination
-
- This pass is a stronger form of dead code elimination that can
- eliminate unnecessary control flow statements. It is located in
- `tree-ssa-dce.c' and is described by `pass_cd_dce'.
-
- * Tail call elimination
-
- This pass identifies function calls that may be rewritten into
- jumps. No code transformation is actually applied here, but the
- data and control flow problem is solved. The code transformation
- requires target support, and so is delayed until RTL. In the
- meantime `CALL_EXPR_TAILCALL' is set indicating the possibility.
- The pass is located in `tree-tailcall.c' and is described by
- `pass_tail_calls'. The RTL transformation is handled by
- `fixup_tail_calls' in `calls.c'.
-
- * Warn for function return without value
-
- For non-void functions, this pass locates return statements that do
- not specify a value and issues a warning. Such a statement may
- have been injected by falling off the end of the function. This
- pass is run last so that we have as much time as possible to prove
- that the statement is not reachable. It is located in
- `tree-cfg.c' and is described by `pass_warn_function_return'.
-
- * Mudflap statement annotation
-
- If mudflap is enabled, we rewrite some memory accesses with code to
- validate that the memory access is correct. In particular,
- expressions involving pointer dereferences (`INDIRECT_REF',
- `ARRAY_REF', etc.) are replaced by code that checks the selected
- address range against the mudflap runtime's database of valid
- regions. This check includes an inline lookup into a
- direct-mapped cache, based on shift/mask operations of the pointer
- value, with a fallback function call into the runtime. The pass
- is located in `tree-mudflap.c' and is described by
- `pass_mudflap_2'.
-
- * Leave static single assignment form
-
- This pass rewrites the function such that it is in normal form. At
- the same time, we eliminate as many single-use temporaries as
- possible, so the intermediate language is no longer GIMPLE, but
- GENERIC. The pass is located in `tree-outof-ssa.c' and is
- described by `pass_del_ssa'.
-
- * Merge PHI nodes that feed into one another
-
- This is part of the CFG cleanup passes. It attempts to join PHI
- nodes from a forwarder CFG block into another block with PHI
- nodes. The pass is located in `tree-cfgcleanup.c' and is
- described by `pass_merge_phi'.
-
- * Return value optimization
-
- If a function always returns the same local variable, and that
- local variable is an aggregate type, then the variable is replaced
- with the return value for the function (i.e., the function's
- DECL_RESULT). This is equivalent to the C++ named return value
- optimization applied to GIMPLE. The pass is located in
- `tree-nrv.c' and is described by `pass_nrv'.
-
- * Return slot optimization
-
- If a function returns a memory object and is called as `var =
- foo()', this pass tries to change the call so that the address of
- `var' is sent to the caller to avoid an extra memory copy. This
- pass is located in `tree-nrv.c' and is described by
- `pass_return_slot'.
-
- * Optimize calls to `__builtin_object_size'
-
- This is a propagation pass similar to CCP that tries to remove
- calls to `__builtin_object_size' when the size of the object can be
- computed at compile-time. This pass is located in
- `tree-object-size.c' and is described by `pass_object_sizes'.
-
- * Loop invariant motion
-
- This pass removes expensive loop-invariant computations out of
- loops. The pass is located in `tree-ssa-loop.c' and described by
- `pass_lim'.
-
- * Loop nest optimizations
-
- This is a family of loop transformations that works on loop nests.
- It includes loop interchange, scaling, skewing and reversal and
- they are all geared to the optimization of data locality in array
- traversals and the removal of dependencies that hamper
- optimizations such as loop parallelization and vectorization. The
- pass is located in `tree-loop-linear.c' and described by
- `pass_linear_transform'.
-
- * Removal of empty loops
-
- This pass removes loops with no code in them. The pass is located
- in `tree-ssa-loop-ivcanon.c' and described by `pass_empty_loop'.
-
- * Unrolling of small loops
-
- This pass completely unrolls loops with few iterations. The pass
- is located in `tree-ssa-loop-ivcanon.c' and described by
- `pass_complete_unroll'.
-
- * Predictive commoning
-
- This pass makes the code reuse the computations from the previous
- iterations of the loops, especially loads and stores to memory.
- It does so by storing the values of these computations to a bank
- of temporary variables that are rotated at the end of loop. To
- avoid the need for this rotation, the loop is then unrolled and
- the copies of the loop body are rewritten to use the appropriate
- version of the temporary variable. This pass is located in
- `tree-predcom.c' and described by `pass_predcom'.
-
- * Array prefetching
-
- This pass issues prefetch instructions for array references inside
- loops. The pass is located in `tree-ssa-loop-prefetch.c' and
- described by `pass_loop_prefetch'.
-
- * Reassociation
-
- This pass rewrites arithmetic expressions to enable optimizations
- that operate on them, like redundancy elimination and
- vectorization. The pass is located in `tree-ssa-reassoc.c' and
- described by `pass_reassoc'.
-
- * Optimization of `stdarg' functions
-
- This pass tries to avoid the saving of register arguments into the
- stack on entry to `stdarg' functions. If the function doesn't use
- any `va_start' macros, no registers need to be saved. If
- `va_start' macros are used, the `va_list' variables don't escape
- the function, it is only necessary to save registers that will be
- used in `va_arg' macros. For instance, if `va_arg' is only used
- with integral types in the function, floating point registers
- don't need to be saved. This pass is located in `tree-stdarg.c'
- and described by `pass_stdarg'.
-
-
-
-File: gccint.info, Node: RTL passes, Prev: Tree SSA passes, Up: Passes
-
-9.5 RTL passes
-==============
-
-The following briefly describes the RTL generation and optimization
-passes that are run after the Tree optimization passes.
-
- * RTL generation
-
- The source files for RTL generation include `stmt.c', `calls.c',
- `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and
- `emit-rtl.c'. Also, the file `insn-emit.c', generated from the
- machine description by the program `genemit', is used in this
- pass. The header file `expr.h' is used for communication within
- this pass.
-
- The header files `insn-flags.h' and `insn-codes.h', generated from
- the machine description by the programs `genflags' and `gencodes',
- tell this pass which standard names are available for use and
- which patterns correspond to them.
-
- * Generation of exception landing pads
-
- This pass generates the glue that handles communication between the
- exception handling library routines and the exception handlers
- within the function. Entry points in the function that are
- invoked by the exception handling library are called "landing
- pads". The code for this pass is located in `except.c'.
-
- * Control flow graph cleanup
-
- This pass removes unreachable code, simplifies jumps to next,
- jumps to jump, jumps across jumps, etc. The pass is run multiple
- times. For historical reasons, it is occasionally referred to as
- the "jump optimization pass". The bulk of the code for this pass
- is in `cfgcleanup.c', and there are support routines in `cfgrtl.c'
- and `jump.c'.
-
- * Forward propagation of single-def values
-
- This pass attempts to remove redundant computation by substituting
- variables that come from a single definition, and seeing if the
- result can be simplified. It performs copy propagation and
- addressing mode selection. The pass is run twice, with values
- being propagated into loops only on the second run. The code is
- located in `fwprop.c'.
-
- * Common subexpression elimination
-
- This pass removes redundant computation within basic blocks, and
- optimizes addressing modes based on cost. The pass is run twice.
- The code for this pass is located in `cse.c'.
-
- * Global common subexpression elimination
-
- This pass performs two different types of GCSE depending on
- whether you are optimizing for size or not (LCM based GCSE tends
- to increase code size for a gain in speed, while Morel-Renvoise
- based GCSE does not). When optimizing for size, GCSE is done
- using Morel-Renvoise Partial Redundancy Elimination, with the
- exception that it does not try to move invariants out of
- loops--that is left to the loop optimization pass. If MR PRE
- GCSE is done, code hoisting (aka unification) is also done, as
- well as load motion. If you are optimizing for speed, LCM (lazy
- code motion) based GCSE is done. LCM is based on the work of
- Knoop, Ruthing, and Steffen. LCM based GCSE also does loop
- invariant code motion. We also perform load and store motion when
- optimizing for speed. Regardless of which type of GCSE is used,
- the GCSE pass also performs global constant and copy propagation.
- The source file for this pass is `gcse.c', and the LCM routines
- are in `lcm.c'.
-
- * Loop optimization
-
- This pass performs several loop related optimizations. The source
- files `cfgloopanal.c' and `cfgloopmanip.c' contain generic loop
- analysis and manipulation code. Initialization and finalization
- of loop structures is handled by `loop-init.c'. A loop invariant
- motion pass is implemented in `loop-invariant.c'. Basic block
- level optimizations--unrolling, peeling and unswitching loops--
- are implemented in `loop-unswitch.c' and `loop-unroll.c'.
- Replacing of the exit condition of loops by special
- machine-dependent instructions is handled by `loop-doloop.c'.
-
- * Jump bypassing
-
- This pass is an aggressive form of GCSE that transforms the control
- flow graph of a function by propagating constants into conditional
- branch instructions. The source file for this pass is `gcse.c'.
-
- * If conversion
-
- This pass attempts to replace conditional branches and surrounding
- assignments with arithmetic, boolean value producing comparison
- instructions, and conditional move instructions. In the very last
- invocation after reload, it will generate predicated instructions
- when supported by the target. The code is located in `ifcvt.c'.
-
- * Web construction
-
- This pass splits independent uses of each pseudo-register. This
- can improve effect of the other transformation, such as CSE or
- register allocation. The code for this pass is located in `web.c'.
-
- * Instruction combination
-
- This pass attempts to combine groups of two or three instructions
- that are related by data flow into single instructions. It
- combines the RTL expressions for the instructions by substitution,
- simplifies the result using algebra, and then attempts to match
- the result against the machine description. The code is located
- in `combine.c'.
-
- * Register movement
-
- This pass looks for cases where matching constraints would force an
- instruction to need a reload, and this reload would be a
- register-to-register move. It then attempts to change the
- registers used by the instruction to avoid the move instruction.
- The code is located in `regmove.c'.
-
- * Mode switching optimization
-
- This pass looks for instructions that require the processor to be
- in a specific "mode" and minimizes the number of mode changes
- required to satisfy all users. What these modes are, and what
- they apply to are completely target-specific. The code for this
- pass is located in `mode-switching.c'.
-
- * Modulo scheduling
-
- This pass looks at innermost loops and reorders their instructions
- by overlapping different iterations. Modulo scheduling is
- performed immediately before instruction scheduling. The code for
- this pass is located in `modulo-sched.c'.
-
- * Instruction scheduling
-
- This pass looks for instructions whose output will not be
- available by the time that it is used in subsequent instructions.
- Memory loads and floating point instructions often have this
- behavior on RISC machines. It re-orders instructions within a
- basic block to try to separate the definition and use of items
- that otherwise would cause pipeline stalls. This pass is
- performed twice, before and after register allocation. The code
- for this pass is located in `haifa-sched.c', `sched-deps.c',
- `sched-ebb.c', `sched-rgn.c' and `sched-vis.c'.
-
- * Register allocation
-
- These passes make sure that all occurrences of pseudo registers are
- eliminated, either by allocating them to a hard register, replacing
- them by an equivalent expression (e.g. a constant) or by placing
- them on the stack. This is done in several subpasses:
-
- * Register move optimizations. This pass makes some simple RTL
- code transformations which improve the subsequent register
- allocation. The source file is `regmove.c'.
-
- * The integrated register allocator (IRA). It is called
- integrated because coalescing, register live range splitting,
- and hard register preferencing are done on-the-fly during
- coloring. It also has better integration with the reload
- pass. Pseudo-registers spilled by the allocator or the
- reload have still a chance to get hard-registers if the
- reload evicts some pseudo-registers from hard-registers. The
- allocator helps to choose better pseudos for spilling based
- on their live ranges and to coalesce stack slots allocated
- for the spilled pseudo-registers. IRA is a regional register
- allocator which is transformed into Chaitin-Briggs allocator
- if there is one region. By default, IRA chooses regions using
- register pressure but the user can force it to use one region
- or regions corresponding to all loops.
-
- Source files of the allocator are `ira.c', `ira-build.c',
- `ira-costs.c', `ira-conflicts.c', `ira-color.c',
- `ira-emit.c', `ira-lives', plus header files `ira.h' and
- `ira-int.h' used for the communication between the allocator
- and the rest of the compiler and between the IRA files.
-
- * Reloading. This pass renumbers pseudo registers with the
- hardware registers numbers they were allocated. Pseudo
- registers that did not get hard registers are replaced with
- stack slots. Then it finds instructions that are invalid
- because a value has failed to end up in a register, or has
- ended up in a register of the wrong kind. It fixes up these
- instructions by reloading the problematical values
- temporarily into registers. Additional instructions are
- generated to do the copying.
-
- The reload pass also optionally eliminates the frame pointer
- and inserts instructions to save and restore call-clobbered
- registers around calls.
-
- Source files are `reload.c' and `reload1.c', plus the header
- `reload.h' used for communication between them.
-
- * Basic block reordering
-
- This pass implements profile guided code positioning. If profile
- information is not available, various types of static analysis are
- performed to make the predictions normally coming from the profile
- feedback (IE execution frequency, branch probability, etc). It is
- implemented in the file `bb-reorder.c', and the various prediction
- routines are in `predict.c'.
-
- * Variable tracking
-
- This pass computes where the variables are stored at each position
- in code and generates notes describing the variable locations to
- RTL code. The location lists are then generated according to these
- notes to debug information if the debugging information format
- supports location lists. The code is located in `var-tracking.c'.
-
- * Delayed branch scheduling
-
- This optional pass attempts to find instructions that can go into
- the delay slots of other instructions, usually jumps and calls.
- The code for this pass is located in `reorg.c'.
-
- * Branch shortening
-
- On many RISC machines, branch instructions have a limited range.
- Thus, longer sequences of instructions must be used for long
- branches. In this pass, the compiler figures out what how far
- each instruction will be from each other instruction, and
- therefore whether the usual instructions, or the longer sequences,
- must be used for each branch. The code for this pass is located
- in `final.c'.
-
- * Register-to-stack conversion
-
- Conversion from usage of some hard registers to usage of a register
- stack may be done at this point. Currently, this is supported only
- for the floating-point registers of the Intel 80387 coprocessor.
- The code for this pass is located in `reg-stack.c'.
-
- * Final
-
- This pass outputs the assembler code for the function. The source
- files are `final.c' plus `insn-output.c'; the latter is generated
- automatically from the machine description by the tool `genoutput'.
- The header file `conditions.h' is used for communication between
- these files. If mudflap is enabled, the queue of deferred
- declarations and any addressed constants (e.g., string literals)
- is processed by `mudflap_finish_file' into a synthetic constructor
- function containing calls into the mudflap runtime.
-
- * Debugging information output
-
- This is run after final because it must output the stack slot
- offsets for pseudo registers that did not get hard registers.
- Source files are `dbxout.c' for DBX symbol table format,
- `sdbout.c' for SDB symbol table format, `dwarfout.c' for DWARF
- symbol table format, files `dwarf2out.c' and `dwarf2asm.c' for
- DWARF2 symbol table format, and `vmsdbgout.c' for VMS debug symbol
- table format.
-
-
-
-File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top
-
-10 RTL Representation
-*********************
-
-The last part of the compiler work is done on a low-level intermediate
-representation called Register Transfer Language. In this language, the
-instructions to be output are described, pretty much one by one, in an
-algebraic form that describes what the instruction does.
-
- RTL is inspired by Lisp lists. It has both an internal form, made up
-of structures that point at other structures, and a textual form that
-is used in the machine description and in printed debugging dumps. The
-textual form uses nested parentheses to indicate the pointers in the
-internal form.
-
-* Menu:
-
-* RTL Objects:: Expressions vs vectors vs strings vs integers.
-* RTL Classes:: Categories of RTL expression objects, and their structure.
-* Accessors:: Macros to access expression operands or vector elts.
-* Special Accessors:: Macros to access specific annotations on RTL.
-* Flags:: Other flags in an RTL expression.
-* Machine Modes:: Describing the size and format of a datum.
-* Constants:: Expressions with constant values.
-* Regs and Memory:: Expressions representing register contents or memory.
-* Arithmetic:: Expressions representing arithmetic on other expressions.
-* Comparisons:: Expressions representing comparison of expressions.
-* Bit-Fields:: Expressions representing bit-fields in memory or reg.
-* Vector Operations:: Expressions involving vector datatypes.
-* Conversions:: Extending, truncating, floating or fixing.
-* RTL Declarations:: Declaring volatility, constancy, etc.
-* Side Effects:: Expressions for storing in registers, etc.
-* Incdec:: Embedded side-effects for autoincrement addressing.
-* Assembler:: Representing `asm' with operands.
-* Debug Information:: Expressions representing debugging information.
-* Insns:: Expression types for entire insns.
-* Calls:: RTL representation of function call insns.
-* Sharing:: Some expressions are unique; others *must* be copied.
-* Reading RTL:: Reading textual RTL from a file.
-
-
-File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL
-
-10.1 RTL Object Types
-=====================
-
-RTL uses five kinds of objects: expressions, integers, wide integers,
-strings and vectors. Expressions are the most important ones. An RTL
-expression ("RTX", for short) is a C structure, but it is usually
-referred to with a pointer; a type that is given the typedef name `rtx'.
-
- An integer is simply an `int'; their written form uses decimal digits.
-A wide integer is an integral object whose type is `HOST_WIDE_INT';
-their written form uses decimal digits.
-
- A string is a sequence of characters. In core it is represented as a
-`char *' in usual C fashion, and it is written in C syntax as well.
-However, strings in RTL may never be null. If you write an empty
-string in a machine description, it is represented in core as a null
-pointer rather than as a pointer to a null character. In certain
-contexts, these null pointers instead of strings are valid. Within RTL
-code, strings are most commonly found inside `symbol_ref' expressions,
-but they appear in other contexts in the RTL expressions that make up
-machine descriptions.
-
- In a machine description, strings are normally written with double
-quotes, as you would in C. However, strings in machine descriptions may
-extend over many lines, which is invalid C, and adjacent string
-constants are not concatenated as they are in C. Any string constant
-may be surrounded with a single set of parentheses. Sometimes this
-makes the machine description easier to read.
-
- There is also a special syntax for strings, which can be useful when C
-code is embedded in a machine description. Wherever a string can
-appear, it is also valid to write a C-style brace block. The entire
-brace block, including the outermost pair of braces, is considered to be
-the string constant. Double quote characters inside the braces are not
-special. Therefore, if you write string constants in the C code, you
-need not escape each quote character with a backslash.
-
- A vector contains an arbitrary number of pointers to expressions. The
-number of elements in the vector is explicitly present in the vector.
-The written form of a vector consists of square brackets (`[...]')
-surrounding the elements, in sequence and with whitespace separating
-them. Vectors of length zero are not created; null pointers are used
-instead.
-
- Expressions are classified by "expression codes" (also called RTX
-codes). The expression code is a name defined in `rtl.def', which is
-also (in uppercase) a C enumeration constant. The possible expression
-codes and their meanings are machine-independent. The code of an RTX
-can be extracted with the macro `GET_CODE (X)' and altered with
-`PUT_CODE (X, NEWCODE)'.
-
- The expression code determines how many operands the expression
-contains, and what kinds of objects they are. In RTL, unlike Lisp, you
-cannot tell by looking at an operand what kind of object it is.
-Instead, you must know from its context--from the expression code of
-the containing expression. For example, in an expression of code
-`subreg', the first operand is to be regarded as an expression and the
-second operand as an integer. In an expression of code `plus', there
-are two operands, both of which are to be regarded as expressions. In
-a `symbol_ref' expression, there is one operand, which is to be
-regarded as a string.
-
- Expressions are written as parentheses containing the name of the
-expression type, its flags and machine mode if any, and then the
-operands of the expression (separated by spaces).
-
- Expression code names in the `md' file are written in lowercase, but
-when they appear in C code they are written in uppercase. In this
-manual, they are shown as follows: `const_int'.
-
- In a few contexts a null pointer is valid where an expression is
-normally wanted. The written form of this is `(nil)'.
-
-
-File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL
-
-10.2 RTL Classes and Formats
-============================
-
-The various expression codes are divided into several "classes", which
-are represented by single characters. You can determine the class of
-an RTX code with the macro `GET_RTX_CLASS (CODE)'. Currently,
-`rtl.def' defines these classes:
-
-`RTX_OBJ'
- An RTX code that represents an actual object, such as a register
- (`REG') or a memory location (`MEM', `SYMBOL_REF'). `LO_SUM') is
- also included; instead, `SUBREG' and `STRICT_LOW_PART' are not in
- this class, but in class `x'.
-
-`RTX_CONST_OBJ'
- An RTX code that represents a constant object. `HIGH' is also
- included in this class.
-
-`RTX_COMPARE'
- An RTX code for a non-symmetric comparison, such as `GEU' or `LT'.
-
-`RTX_COMM_COMPARE'
- An RTX code for a symmetric (commutative) comparison, such as `EQ'
- or `ORDERED'.
-
-`RTX_UNARY'
- An RTX code for a unary arithmetic operation, such as `NEG',
- `NOT', or `ABS'. This category also includes value extension
- (sign or zero) and conversions between integer and floating point.
-
-`RTX_COMM_ARITH'
- An RTX code for a commutative binary operation, such as `PLUS' or
- `AND'. `NE' and `EQ' are comparisons, so they have class `<'.
-
-`RTX_BIN_ARITH'
- An RTX code for a non-commutative binary operation, such as
- `MINUS', `DIV', or `ASHIFTRT'.
-
-`RTX_BITFIELD_OPS'
- An RTX code for a bit-field operation. Currently only
- `ZERO_EXTRACT' and `SIGN_EXTRACT'. These have three inputs and
- are lvalues (so they can be used for insertion as well). *Note
- Bit-Fields::.
-
-`RTX_TERNARY'
- An RTX code for other three input operations. Currently only
- `IF_THEN_ELSE', `VEC_MERGE', `SIGN_EXTRACT', `ZERO_EXTRACT', and
- `FMA'.
-
-`RTX_INSN'
- An RTX code for an entire instruction: `INSN', `JUMP_INSN', and
- `CALL_INSN'. *Note Insns::.
-
-`RTX_MATCH'
- An RTX code for something that matches in insns, such as
- `MATCH_DUP'. These only occur in machine descriptions.
-
-`RTX_AUTOINC'
- An RTX code for an auto-increment addressing mode, such as
- `POST_INC'.
-
-`RTX_EXTRA'
- All other RTX codes. This category includes the remaining codes
- used only in machine descriptions (`DEFINE_*', etc.). It also
- includes all the codes describing side effects (`SET', `USE',
- `CLOBBER', etc.) and the non-insns that may appear on an insn
- chain, such as `NOTE', `BARRIER', and `CODE_LABEL'. `SUBREG' is
- also part of this class.
-
- For each expression code, `rtl.def' specifies the number of contained
-objects and their kinds using a sequence of characters called the
-"format" of the expression code. For example, the format of `subreg'
-is `ei'.
-
- These are the most commonly used format characters:
-
-`e'
- An expression (actually a pointer to an expression).
-
-`i'
- An integer.
-
-`w'
- A wide integer.
-
-`s'
- A string.
-
-`E'
- A vector of expressions.
-
- A few other format characters are used occasionally:
-
-`u'
- `u' is equivalent to `e' except that it is printed differently in
- debugging dumps. It is used for pointers to insns.
-
-`n'
- `n' is equivalent to `i' except that it is printed differently in
- debugging dumps. It is used for the line number or code number of
- a `note' insn.
-
-`S'
- `S' indicates a string which is optional. In the RTL objects in
- core, `S' is equivalent to `s', but when the object is read, from
- an `md' file, the string value of this operand may be omitted. An
- omitted string is taken to be the null string.
-
-`V'
- `V' indicates a vector which is optional. In the RTL objects in
- core, `V' is equivalent to `E', but when the object is read from
- an `md' file, the vector value of this operand may be omitted. An
- omitted vector is effectively the same as a vector of no elements.
-
-`B'
- `B' indicates a pointer to basic block structure.
-
-`0'
- `0' means a slot whose contents do not fit any normal category.
- `0' slots are not printed at all in dumps, and are often used in
- special ways by small parts of the compiler.
-
- There are macros to get the number of operands and the format of an
-expression code:
-
-`GET_RTX_LENGTH (CODE)'
- Number of operands of an RTX of code CODE.
-
-`GET_RTX_FORMAT (CODE)'
- The format of an RTX of code CODE, as a C string.
-
- Some classes of RTX codes always have the same format. For example, it
-is safe to assume that all comparison operations have format `ee'.
-
-`1'
- All codes of this class have format `e'.
-
-`<'
-`c'
-`2'
- All codes of these classes have format `ee'.
-
-`b'
-`3'
- All codes of these classes have format `eee'.
-
-`i'
- All codes of this class have formats that begin with `iuueiee'.
- *Note Insns::. Note that not all RTL objects linked onto an insn
- chain are of class `i'.
-
-`o'
-`m'
-`x'
- You can make no assumptions about the format of these codes.
-
-
-File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL
-
-10.3 Access to Operands
-=======================
-
-Operands of expressions are accessed using the macros `XEXP', `XINT',
-`XWINT' and `XSTR'. Each of these macros takes two arguments: an
-expression-pointer (RTX) and an operand number (counting from zero).
-Thus,
-
- XEXP (X, 2)
-
-accesses operand 2 of expression X, as an expression.
-
- XINT (X, 2)
-
-accesses the same operand as an integer. `XSTR', used in the same
-fashion, would access it as a string.
-
- Any operand can be accessed as an integer, as an expression or as a
-string. You must choose the correct method of access for the kind of
-value actually stored in the operand. You would do this based on the
-expression code of the containing expression. That is also how you
-would know how many operands there are.
-
- For example, if X is a `subreg' expression, you know that it has two
-operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X,
-1)'. If you did `XINT (X, 0)', you would get the address of the
-expression operand but cast as an integer; that might occasionally be
-useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP
-(X, 1)' would also compile without error, and would return the second,
-integer operand cast as an expression pointer, which would probably
-result in a crash when accessed. Nothing stops you from writing `XEXP
-(X, 28)' either, but this will access memory past the end of the
-expression with unpredictable results.
-
- Access to operands which are vectors is more complicated. You can use
-the macro `XVEC' to get the vector-pointer itself, or the macros
-`XVECEXP' and `XVECLEN' to access the elements and length of a vector.
-
-`XVEC (EXP, IDX)'
- Access the vector-pointer which is operand number IDX in EXP.
-
-`XVECLEN (EXP, IDX)'
- Access the length (number of elements) in the vector which is in
- operand number IDX in EXP. This value is an `int'.
-
-`XVECEXP (EXP, IDX, ELTNUM)'
- Access element number ELTNUM in the vector which is in operand
- number IDX in EXP. This value is an RTX.
-
- It is up to you to make sure that ELTNUM is not negative and is
- less than `XVECLEN (EXP, IDX)'.
-
- All the macros defined in this section expand into lvalues and
-therefore can be used to assign the operands, lengths and vector
-elements as well as to access them.
-
-
-File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL
-
-10.4 Access to Special Operands
-===============================
-
-Some RTL nodes have special annotations associated with them.
-
-`MEM'
-
- `MEM_ALIAS_SET (X)'
- If 0, X is not in any alias set, and may alias anything.
- Otherwise, X can only alias `MEM's in a conflicting alias
- set. This value is set in a language-dependent manner in the
- front-end, and should not be altered in the back-end. In
- some front-ends, these numbers may correspond in some way to
- types, or other language-level entities, but they need not,
- and the back-end makes no such assumptions. These set
- numbers are tested with `alias_sets_conflict_p'.
-
- `MEM_EXPR (X)'
- If this register is known to hold the value of some user-level
- declaration, this is that tree node. It may also be a
- `COMPONENT_REF', in which case this is some field reference,
- and `TREE_OPERAND (X, 0)' contains the declaration, or
- another `COMPONENT_REF', or null if there is no compile-time
- object associated with the reference.
-
- `MEM_OFFSET (X)'
- The offset from the start of `MEM_EXPR' as a `CONST_INT' rtx.
-
- `MEM_SIZE (X)'
- The size in bytes of the memory reference as a `CONST_INT'
- rtx. This is mostly relevant for `BLKmode' references as
- otherwise the size is implied by the mode.
-
- `MEM_ALIGN (X)'
- The known alignment in bits of the memory reference.
-
- `MEM_ADDR_SPACE (X)'
- The address space of the memory reference. This will
- commonly be zero for the generic address space.
-
-`REG'
-
- `ORIGINAL_REGNO (X)'
- This field holds the number the register "originally" had;
- for a pseudo register turned into a hard reg this will hold
- the old pseudo register number.
-
- `REG_EXPR (X)'
- If this register is known to hold the value of some user-level
- declaration, this is that tree node.
-
- `REG_OFFSET (X)'
- If this register is known to hold the value of some user-level
- declaration, this is the offset into that logical storage.
-
-`SYMBOL_REF'
-
- `SYMBOL_REF_DECL (X)'
- If the `symbol_ref' X was created for a `VAR_DECL' or a
- `FUNCTION_DECL', that tree is recorded here. If this value is
- null, then X was created by back end code generation routines,
- and there is no associated front end symbol table entry.
-
- `SYMBOL_REF_DECL' may also point to a tree of class `'c'',
- that is, some sort of constant. In this case, the
- `symbol_ref' is an entry in the per-file constant pool;
- again, there is no associated front end symbol table entry.
-
- `SYMBOL_REF_CONSTANT (X)'
- If `CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant
- pool entry for X. It is null otherwise.
-
- `SYMBOL_REF_DATA (X)'
- A field of opaque type used to store `SYMBOL_REF_DECL' or
- `SYMBOL_REF_CONSTANT'.
-
- `SYMBOL_REF_FLAGS (X)'
- In a `symbol_ref', this is used to communicate various
- predicates about the symbol. Some of these are common enough
- to be computed by common code, some are specific to the
- target. The common bits are:
-
- `SYMBOL_FLAG_FUNCTION'
- Set if the symbol refers to a function.
-
- `SYMBOL_FLAG_LOCAL'
- Set if the symbol is local to this "module". See
- `TARGET_BINDS_LOCAL_P'.
-
- `SYMBOL_FLAG_EXTERNAL'
- Set if this symbol is not defined in this translation
- unit. Note that this is not the inverse of
- `SYMBOL_FLAG_LOCAL'.
-
- `SYMBOL_FLAG_SMALL'
- Set if the symbol is located in the small data section.
- See `TARGET_IN_SMALL_DATA_P'.
-
- `SYMBOL_REF_TLS_MODEL (X)'
- This is a multi-bit field accessor that returns the
- `tls_model' to be used for a thread-local storage
- symbol. It returns zero for non-thread-local symbols.
-
- `SYMBOL_FLAG_HAS_BLOCK_INFO'
- Set if the symbol has `SYMBOL_REF_BLOCK' and
- `SYMBOL_REF_BLOCK_OFFSET' fields.
-
- `SYMBOL_FLAG_ANCHOR'
- Set if the symbol is used as a section anchor. "Section
- anchors" are symbols that have a known position within
- an `object_block' and that can be used to access nearby
- members of that block. They are used to implement
- `-fsection-anchors'.
-
- If this flag is set, then `SYMBOL_FLAG_HAS_BLOCK_INFO'
- will be too.
-
- Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for
- the target's use.
-
-`SYMBOL_REF_BLOCK (X)'
- If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the `object_block'
- structure to which the symbol belongs, or `NULL' if it has not
- been assigned a block.
-
-`SYMBOL_REF_BLOCK_OFFSET (X)'
- If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from
- the first object in `SYMBOL_REF_BLOCK (X)'. The value is negative
- if X has not yet been assigned to a block, or it has not been
- given an offset within that block.
-
-
-File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL
-
-10.5 Flags in an RTL Expression
-===============================
-
-RTL expressions contain several flags (one-bit bit-fields) that are
-used in certain types of expression. Most often they are accessed with
-the following macros, which expand into lvalues.
-
-`CONSTANT_POOL_ADDRESS_P (X)'
- Nonzero in a `symbol_ref' if it refers to part of the current
- function's constant pool. For most targets these addresses are in
- a `.rodata' section entirely separate from the function, but for
- some targets the addresses are close to the beginning of the
- function. In either case GCC assumes these addresses can be
- addressed directly, perhaps with the help of base registers.
- Stored in the `unchanging' field and printed as `/u'.
-
-`RTL_CONST_CALL_P (X)'
- In a `call_insn' indicates that the insn represents a call to a
- const function. Stored in the `unchanging' field and printed as
- `/u'.
-
-`RTL_PURE_CALL_P (X)'
- In a `call_insn' indicates that the insn represents a call to a
- pure function. Stored in the `return_val' field and printed as
- `/i'.
-
-`RTL_CONST_OR_PURE_CALL_P (X)'
- In a `call_insn', true if `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P'
- is true.
-
-`RTL_LOOPING_CONST_OR_PURE_CALL_P (X)'
- In a `call_insn' indicates that the insn represents a possibly
- infinite looping call to a const or pure function. Stored in the
- `call' field and printed as `/c'. Only true if one of
- `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' is true.
-
-`INSN_ANNULLED_BRANCH_P (X)'
- In a `jump_insn', `call_insn', or `insn' indicates that the branch
- is an annulling one. See the discussion under `sequence' below.
- Stored in the `unchanging' field and printed as `/u'.
-
-`INSN_DELETED_P (X)'
- In an `insn', `call_insn', `jump_insn', `code_label', `barrier',
- or `note', nonzero if the insn has been deleted. Stored in the
- `volatil' field and printed as `/v'.
-
-`INSN_FROM_TARGET_P (X)'
- In an `insn' or `jump_insn' or `call_insn' in a delay slot of a
- branch, indicates that the insn is from the target of the branch.
- If the branch insn has `INSN_ANNULLED_BRANCH_P' set, this insn
- will only be executed if the branch is taken. For annulled
- branches with `INSN_FROM_TARGET_P' clear, the insn will be
- executed only if the branch is not taken. When
- `INSN_ANNULLED_BRANCH_P' is not set, this insn will always be
- executed. Stored in the `in_struct' field and printed as `/s'.
-
-`LABEL_PRESERVE_P (X)'
- In a `code_label' or `note', indicates that the label is
- referenced by code or data not visible to the RTL of a given
- function. Labels referenced by a non-local goto will have this
- bit set. Stored in the `in_struct' field and printed as `/s'.
-
-`LABEL_REF_NONLOCAL_P (X)'
- In `label_ref' and `reg_label' expressions, nonzero if this is a
- reference to a non-local label. Stored in the `volatil' field and
- printed as `/v'.
-
-`MEM_IN_STRUCT_P (X)'
- In `mem' expressions, nonzero for reference to an entire structure,
- union or array, or to a component of one. Zero for references to a
- scalar variable or through a pointer to a scalar. If both this
- flag and `MEM_SCALAR_P' are clear, then we don't know whether this
- `mem' is in a structure or not. Both flags should never be
- simultaneously set. Stored in the `in_struct' field and printed
- as `/s'.
-
-`MEM_KEEP_ALIAS_SET_P (X)'
- In `mem' expressions, 1 if we should keep the alias set for this
- mem unchanged when we access a component. Set to 1, for example,
- when we are already in a non-addressable component of an aggregate.
- Stored in the `jump' field and printed as `/j'.
-
-`MEM_SCALAR_P (X)'
- In `mem' expressions, nonzero for reference to a scalar known not
- to be a member of a structure, union, or array. Zero for such
- references and for indirections through pointers, even pointers
- pointing to scalar types. If both this flag and `MEM_IN_STRUCT_P'
- are clear, then we don't know whether this `mem' is in a structure
- or not. Both flags should never be simultaneously set. Stored in
- the `return_val' field and printed as `/i'.
-
-`MEM_VOLATILE_P (X)'
- In `mem', `asm_operands', and `asm_input' expressions, nonzero for
- volatile memory references. Stored in the `volatil' field and
- printed as `/v'.
-
-`MEM_NOTRAP_P (X)'
- In `mem', nonzero for memory references that will not trap.
- Stored in the `call' field and printed as `/c'.
-
-`MEM_POINTER (X)'
- Nonzero in a `mem' if the memory reference holds a pointer.
- Stored in the `frame_related' field and printed as `/f'.
-
-`REG_FUNCTION_VALUE_P (X)'
- Nonzero in a `reg' if it is the place in which this function's
- value is going to be returned. (This happens only in a hard
- register.) Stored in the `return_val' field and printed as `/i'.
-
-`REG_POINTER (X)'
- Nonzero in a `reg' if the register holds a pointer. Stored in the
- `frame_related' field and printed as `/f'.
-
-`REG_USERVAR_P (X)'
- In a `reg', nonzero if it corresponds to a variable present in the
- user's source code. Zero for temporaries generated internally by
- the compiler. Stored in the `volatil' field and printed as `/v'.
-
- The same hard register may be used also for collecting the values
- of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero
- in this kind of use.
-
-`RTX_FRAME_RELATED_P (X)'
- Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or
- `set' which is part of a function prologue and sets the stack
- pointer, sets the frame pointer, or saves a register. This flag
- should also be set on an instruction that sets up a temporary
- register to use in place of the frame pointer. Stored in the
- `frame_related' field and printed as `/f'.
-
- In particular, on RISC targets where there are limits on the sizes
- of immediate constants, it is sometimes impossible to reach the
- register save area directly from the stack pointer. In that case,
- a temporary register is used that is near enough to the register
- save area, and the Canonical Frame Address, i.e., DWARF2's logical
- frame pointer, register must (temporarily) be changed to be this
- temporary register. So, the instruction that sets this temporary
- register must be marked as `RTX_FRAME_RELATED_P'.
-
- If the marked instruction is overly complex (defined in terms of
- what `dwarf2out_frame_debug_expr' can handle), you will also have
- to create a `REG_FRAME_RELATED_EXPR' note and attach it to the
- instruction. This note should contain a simple expression of the
- computation performed by this instruction, i.e., one that
- `dwarf2out_frame_debug_expr' can handle.
-
- This flag is required for exception handling support on targets
- with RTL prologues.
-
-`MEM_READONLY_P (X)'
- Nonzero in a `mem', if the memory is statically allocated and
- read-only.
-
- Read-only in this context means never modified during the lifetime
- of the program, not necessarily in ROM or in write-disabled pages.
- A common example of the later is a shared library's global offset
- table. This table is initialized by the runtime loader, so the
- memory is technically writable, but after control is transfered
- from the runtime loader to the application, this memory will never
- be subsequently modified.
-
- Stored in the `unchanging' field and printed as `/u'.
-
-`SCHED_GROUP_P (X)'
- During instruction scheduling, in an `insn', `call_insn' or
- `jump_insn', indicates that the previous insn must be scheduled
- together with this insn. This is used to ensure that certain
- groups of instructions will not be split up by the instruction
- scheduling pass, for example, `use' insns before a `call_insn' may
- not be separated from the `call_insn'. Stored in the `in_struct'
- field and printed as `/s'.
-
-`SET_IS_RETURN_P (X)'
- For a `set', nonzero if it is for a return. Stored in the `jump'
- field and printed as `/j'.
-
-`SIBLING_CALL_P (X)'
- For a `call_insn', nonzero if the insn is a sibling call. Stored
- in the `jump' field and printed as `/j'.
-
-`STRING_POOL_ADDRESS_P (X)'
- For a `symbol_ref' expression, nonzero if it addresses this
- function's string constant pool. Stored in the `frame_related'
- field and printed as `/f'.
-
-`SUBREG_PROMOTED_UNSIGNED_P (X)'
- Returns a value greater then zero for a `subreg' that has
- `SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is
- kept zero-extended, zero if it is kept sign-extended, and less
- then zero if it is extended some other way via the `ptr_extend'
- instruction. Stored in the `unchanging' field and `volatil'
- field, printed as `/u' and `/v'. This macro may only be used to
- get the value it may not be used to change the value. Use
- `SUBREG_PROMOTED_UNSIGNED_SET' to change the value.
-
-`SUBREG_PROMOTED_UNSIGNED_SET (X)'
- Set the `unchanging' and `volatil' fields in a `subreg' to reflect
- zero, sign, or other extension. If `volatil' is zero, then
- `unchanging' as nonzero means zero extension and as zero means
- sign extension. If `volatil' is nonzero then some other type of
- extension was done via the `ptr_extend' instruction.
-
-`SUBREG_PROMOTED_VAR_P (X)'
- Nonzero in a `subreg' if it was made when accessing an object that
- was promoted to a wider mode in accord with the `PROMOTED_MODE'
- machine description macro (*note Storage Layout::). In this case,
- the mode of the `subreg' is the declared mode of the object and
- the mode of `SUBREG_REG' is the mode of the register that holds
- the object. Promoted variables are always either sign- or
- zero-extended to the wider mode on every assignment. Stored in
- the `in_struct' field and printed as `/s'.
-
-`SYMBOL_REF_USED (X)'
- In a `symbol_ref', indicates that X has been used. This is
- normally only used to ensure that X is only declared external
- once. Stored in the `used' field.
-
-`SYMBOL_REF_WEAK (X)'
- In a `symbol_ref', indicates that X has been declared weak.
- Stored in the `return_val' field and printed as `/i'.
-
-`SYMBOL_REF_FLAG (X)'
- In a `symbol_ref', this is used as a flag for machine-specific
- purposes. Stored in the `volatil' field and printed as `/v'.
-
- Most uses of `SYMBOL_REF_FLAG' are historic and may be subsumed by
- `SYMBOL_REF_FLAGS'. Certainly use of `SYMBOL_REF_FLAGS' is
- mandatory if the target requires more than one bit of storage.
-
-`PREFETCH_SCHEDULE_BARRIER_P (X)'
- In a `prefetch', indicates that the prefetch is a scheduling
- barrier. No other INSNs will be moved over it. Stored in the
- `volatil' field and printed as `/v'.
-
- These are the fields to which the above macros refer:
-
-`call'
- In a `mem', 1 means that the memory reference will not trap.
-
- In a `call', 1 means that this pure or const call may possibly
- infinite loop.
-
- In an RTL dump, this flag is represented as `/c'.
-
-`frame_related'
- In an `insn' or `set' expression, 1 means that it is part of a
- function prologue and sets the stack pointer, sets the frame
- pointer, saves a register, or sets up a temporary register to use
- in place of the frame pointer.
-
- In `reg' expressions, 1 means that the register holds a pointer.
-
- In `mem' expressions, 1 means that the memory reference holds a
- pointer.
-
- In `symbol_ref' expressions, 1 means that the reference addresses
- this function's string constant pool.
-
- In an RTL dump, this flag is represented as `/f'.
-
-`in_struct'
- In `mem' expressions, it is 1 if the memory datum referred to is
- all or part of a structure or array; 0 if it is (or might be) a
- scalar variable. A reference through a C pointer has 0 because
- the pointer might point to a scalar variable. This information
- allows the compiler to determine something about possible cases of
- aliasing.
-
- In `reg' expressions, it is 1 if the register has its entire life
- contained within the test expression of some loop.
-
- In `subreg' expressions, 1 means that the `subreg' is accessing an
- object that has had its mode promoted from a wider mode.
-
- In `label_ref' expressions, 1 means that the referenced label is
- outside the innermost loop containing the insn in which the
- `label_ref' was found.
-
- In `code_label' expressions, it is 1 if the label may never be
- deleted. This is used for labels which are the target of
- non-local gotos. Such a label that would have been deleted is
- replaced with a `note' of type `NOTE_INSN_DELETED_LABEL'.
-
- In an `insn' during dead-code elimination, 1 means that the insn is
- dead code.
-
- In an `insn' or `jump_insn' during reorg for an insn in the delay
- slot of a branch, 1 means that this insn is from the target of the
- branch.
-
- In an `insn' during instruction scheduling, 1 means that this insn
- must be scheduled as part of a group together with the previous
- insn.
-
- In an RTL dump, this flag is represented as `/s'.
-
-`return_val'
- In `reg' expressions, 1 means the register contains the value to
- be returned by the current function. On machines that pass
- parameters in registers, the same register number may be used for
- parameters as well, but this flag is not set on such uses.
-
- In `mem' expressions, 1 means the memory reference is to a scalar
- known not to be a member of a structure, union, or array.
-
- In `symbol_ref' expressions, 1 means the referenced symbol is weak.
-
- In `call' expressions, 1 means the call is pure.
-
- In an RTL dump, this flag is represented as `/i'.
-
-`jump'
- In a `mem' expression, 1 means we should keep the alias set for
- this mem unchanged when we access a component.
-
- In a `set', 1 means it is for a return.
-
- In a `call_insn', 1 means it is a sibling call.
-
- In an RTL dump, this flag is represented as `/j'.
-
-`unchanging'
- In `reg' and `mem' expressions, 1 means that the value of the
- expression never changes.
-
- In `subreg' expressions, it is 1 if the `subreg' references an
- unsigned object whose mode has been promoted to a wider mode.
-
- In an `insn' or `jump_insn' in the delay slot of a branch
- instruction, 1 means an annulling branch should be used.
-
- In a `symbol_ref' expression, 1 means that this symbol addresses
- something in the per-function constant pool.
-
- In a `call_insn' 1 means that this instruction is a call to a const
- function.
-
- In an RTL dump, this flag is represented as `/u'.
-
-`used'
- This flag is used directly (without an access macro) at the end of
- RTL generation for a function, to count the number of times an
- expression appears in insns. Expressions that appear more than
- once are copied, according to the rules for shared structure
- (*note Sharing::).
-
- For a `reg', it is used directly (without an access macro) by the
- leaf register renumbering code to ensure that each register is only
- renumbered once.
-
- In a `symbol_ref', it indicates that an external declaration for
- the symbol has already been written.
-
-`volatil'
- In a `mem', `asm_operands', or `asm_input' expression, it is 1 if
- the memory reference is volatile. Volatile memory references may
- not be deleted, reordered or combined.
-
- In a `symbol_ref' expression, it is used for machine-specific
- purposes.
-
- In a `reg' expression, it is 1 if the value is a user-level
- variable. 0 indicates an internal compiler temporary.
-
- In an `insn', 1 means the insn has been deleted.
-
- In `label_ref' and `reg_label' expressions, 1 means a reference to
- a non-local label.
-
- In `prefetch' expressions, 1 means that the containing insn is a
- scheduling barrier.
-
- In an RTL dump, this flag is represented as `/v'.
-
-
-File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL
-
-10.6 Machine Modes
-==================
-
-A machine mode describes a size of data object and the representation
-used for it. In the C code, machine modes are represented by an
-enumeration type, `enum machine_mode', defined in `machmode.def'. Each
-RTL expression has room for a machine mode and so do certain kinds of
-tree expressions (declarations and types, to be precise).
-
- In debugging dumps and machine descriptions, the machine mode of an RTL
-expression is written after the expression code with a colon to separate
-them. The letters `mode' which appear at the end of each machine mode
-name are omitted. For example, `(reg:SI 38)' is a `reg' expression
-with machine mode `SImode'. If the mode is `VOIDmode', it is not
-written at all.
-
- Here is a table of machine modes. The term "byte" below refers to an
-object of `BITS_PER_UNIT' bits (*note Storage Layout::).
-
-`BImode'
- "Bit" mode represents a single bit, for predicate registers.
-
-`QImode'
- "Quarter-Integer" mode represents a single byte treated as an
- integer.
-
-`HImode'
- "Half-Integer" mode represents a two-byte integer.
-
-`PSImode'
- "Partial Single Integer" mode represents an integer which occupies
- four bytes but which doesn't really use all four. On some
- machines, this is the right mode to use for pointers.
-
-`SImode'
- "Single Integer" mode represents a four-byte integer.
-
-`PDImode'
- "Partial Double Integer" mode represents an integer which occupies
- eight bytes but which doesn't really use all eight. On some
- machines, this is the right mode to use for certain pointers.
-
-`DImode'
- "Double Integer" mode represents an eight-byte integer.
-
-`TImode'
- "Tetra Integer" (?) mode represents a sixteen-byte integer.
-
-`OImode'
- "Octa Integer" (?) mode represents a thirty-two-byte integer.
-
-`QFmode'
- "Quarter-Floating" mode represents a quarter-precision (single
- byte) floating point number.
-
-`HFmode'
- "Half-Floating" mode represents a half-precision (two byte)
- floating point number.
-
-`TQFmode'
- "Three-Quarter-Floating" (?) mode represents a
- three-quarter-precision (three byte) floating point number.
-
-`SFmode'
- "Single Floating" mode represents a four byte floating point
- number. In the common case, of a processor with IEEE arithmetic
- and 8-bit bytes, this is a single-precision IEEE floating point
- number; it can also be used for double-precision (on processors
- with 16-bit bytes) and single-precision VAX and IBM types.
-
-`DFmode'
- "Double Floating" mode represents an eight byte floating point
- number. In the common case, of a processor with IEEE arithmetic
- and 8-bit bytes, this is a double-precision IEEE floating point
- number.
-
-`XFmode'
- "Extended Floating" mode represents an IEEE extended floating point
- number. This mode only has 80 meaningful bits (ten bytes). Some
- processors require such numbers to be padded to twelve bytes,
- others to sixteen; this mode is used for either.
-
-`SDmode'
- "Single Decimal Floating" mode represents a four byte decimal
- floating point number (as distinct from conventional binary
- floating point).
-
-`DDmode'
- "Double Decimal Floating" mode represents an eight byte decimal
- floating point number.
-
-`TDmode'
- "Tetra Decimal Floating" mode represents a sixteen byte decimal
- floating point number all 128 of whose bits are meaningful.
-
-`TFmode'
- "Tetra Floating" mode represents a sixteen byte floating point
- number all 128 of whose bits are meaningful. One common use is the
- IEEE quad-precision format.
-
-`QQmode'
- "Quarter-Fractional" mode represents a single byte treated as a
- signed fractional number. The default format is "s.7".
-
-`HQmode'
- "Half-Fractional" mode represents a two-byte signed fractional
- number. The default format is "s.15".
-
-`SQmode'
- "Single Fractional" mode represents a four-byte signed fractional
- number. The default format is "s.31".
-
-`DQmode'
- "Double Fractional" mode represents an eight-byte signed
- fractional number. The default format is "s.63".
-
-`TQmode'
- "Tetra Fractional" mode represents a sixteen-byte signed
- fractional number. The default format is "s.127".
-
-`UQQmode'
- "Unsigned Quarter-Fractional" mode represents a single byte
- treated as an unsigned fractional number. The default format is
- ".8".
-
-`UHQmode'
- "Unsigned Half-Fractional" mode represents a two-byte unsigned
- fractional number. The default format is ".16".
-
-`USQmode'
- "Unsigned Single Fractional" mode represents a four-byte unsigned
- fractional number. The default format is ".32".
-
-`UDQmode'
- "Unsigned Double Fractional" mode represents an eight-byte unsigned
- fractional number. The default format is ".64".
-
-`UTQmode'
- "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned
- fractional number. The default format is ".128".
-
-`HAmode'
- "Half-Accumulator" mode represents a two-byte signed accumulator.
- The default format is "s8.7".
-
-`SAmode'
- "Single Accumulator" mode represents a four-byte signed
- accumulator. The default format is "s16.15".
-
-`DAmode'
- "Double Accumulator" mode represents an eight-byte signed
- accumulator. The default format is "s32.31".
-
-`TAmode'
- "Tetra Accumulator" mode represents a sixteen-byte signed
- accumulator. The default format is "s64.63".
-
-`UHAmode'
- "Unsigned Half-Accumulator" mode represents a two-byte unsigned
- accumulator. The default format is "8.8".
-
-`USAmode'
- "Unsigned Single Accumulator" mode represents a four-byte unsigned
- accumulator. The default format is "16.16".
-
-`UDAmode'
- "Unsigned Double Accumulator" mode represents an eight-byte
- unsigned accumulator. The default format is "32.32".
-
-`UTAmode'
- "Unsigned Tetra Accumulator" mode represents a sixteen-byte
- unsigned accumulator. The default format is "64.64".
-
-`CCmode'
- "Condition Code" mode represents the value of a condition code,
- which is a machine-specific set of bits used to represent the
- result of a comparison operation. Other machine-specific modes
- may also be used for the condition code. These modes are not used
- on machines that use `cc0' (*note Condition Code::).
-
-`BLKmode'
- "Block" mode represents values that are aggregates to which none of
- the other modes apply. In RTL, only memory references can have
- this mode, and only if they appear in string-move or vector
- instructions. On machines which have no such instructions,
- `BLKmode' will not appear in RTL.
-
-`VOIDmode'
- Void mode means the absence of a mode or an unspecified mode. For
- example, RTL expressions of code `const_int' have mode `VOIDmode'
- because they can be taken to have whatever mode the context
- requires. In debugging dumps of RTL, `VOIDmode' is expressed by
- the absence of any mode.
-
-`QCmode, HCmode, SCmode, DCmode, XCmode, TCmode'
- These modes stand for a complex number represented as a pair of
- floating point values. The floating point values are in `QFmode',
- `HFmode', `SFmode', `DFmode', `XFmode', and `TFmode', respectively.
-
-`CQImode, CHImode, CSImode, CDImode, CTImode, COImode'
- These modes stand for a complex number represented as a pair of
- integer values. The integer values are in `QImode', `HImode',
- `SImode', `DImode', `TImode', and `OImode', respectively.
-
- The machine description defines `Pmode' as a C macro which expands
-into the machine mode used for addresses. Normally this is the mode
-whose size is `BITS_PER_WORD', `SImode' on 32-bit machines.
-
- The only modes which a machine description must support are `QImode',
-and the modes corresponding to `BITS_PER_WORD', `FLOAT_TYPE_SIZE' and
-`DOUBLE_TYPE_SIZE'. The compiler will attempt to use `DImode' for
-8-byte structures and unions, but this can be prevented by overriding
-the definition of `MAX_FIXED_MODE_SIZE'. Alternatively, you can have
-the compiler use `TImode' for 16-byte structures and unions. Likewise,
-you can arrange for the C type `short int' to avoid using `HImode'.
-
- Very few explicit references to machine modes remain in the compiler
-and these few references will soon be removed. Instead, the machine
-modes are divided into mode classes. These are represented by the
-enumeration type `enum mode_class' defined in `machmode.h'. The
-possible mode classes are:
-
-`MODE_INT'
- Integer modes. By default these are `BImode', `QImode', `HImode',
- `SImode', `DImode', `TImode', and `OImode'.
-
-`MODE_PARTIAL_INT'
- The "partial integer" modes, `PQImode', `PHImode', `PSImode' and
- `PDImode'.
-
-`MODE_FLOAT'
- Floating point modes. By default these are `QFmode', `HFmode',
- `TQFmode', `SFmode', `DFmode', `XFmode' and `TFmode'.
-
-`MODE_DECIMAL_FLOAT'
- Decimal floating point modes. By default these are `SDmode',
- `DDmode' and `TDmode'.
-
-`MODE_FRACT'
- Signed fractional modes. By default these are `QQmode', `HQmode',
- `SQmode', `DQmode' and `TQmode'.
-
-`MODE_UFRACT'
- Unsigned fractional modes. By default these are `UQQmode',
- `UHQmode', `USQmode', `UDQmode' and `UTQmode'.
-
-`MODE_ACCUM'
- Signed accumulator modes. By default these are `HAmode',
- `SAmode', `DAmode' and `TAmode'.
-
-`MODE_UACCUM'
- Unsigned accumulator modes. By default these are `UHAmode',
- `USAmode', `UDAmode' and `UTAmode'.
-
-`MODE_COMPLEX_INT'
- Complex integer modes. (These are not currently implemented).
-
-`MODE_COMPLEX_FLOAT'
- Complex floating point modes. By default these are `QCmode',
- `HCmode', `SCmode', `DCmode', `XCmode', and `TCmode'.
-
-`MODE_FUNCTION'
- Algol or Pascal function variables including a static chain.
- (These are not currently implemented).
-
-`MODE_CC'
- Modes representing condition code values. These are `CCmode' plus
- any `CC_MODE' modes listed in the `MACHINE-modes.def'. *Note Jump
- Patterns::, also see *note Condition Code::.
-
-`MODE_RANDOM'
- This is a catchall mode class for modes which don't fit into the
- above classes. Currently `VOIDmode' and `BLKmode' are in
- `MODE_RANDOM'.
-
- Here are some C macros that relate to machine modes:
-
-`GET_MODE (X)'
- Returns the machine mode of the RTX X.
-
-`PUT_MODE (X, NEWMODE)'
- Alters the machine mode of the RTX X to be NEWMODE.
-
-`NUM_MACHINE_MODES'
- Stands for the number of machine modes available on the target
- machine. This is one greater than the largest numeric value of any
- machine mode.
-
-`GET_MODE_NAME (M)'
- Returns the name of mode M as a string.
-
-`GET_MODE_CLASS (M)'
- Returns the mode class of mode M.
-
-`GET_MODE_WIDER_MODE (M)'
- Returns the next wider natural mode. For example, the expression
- `GET_MODE_WIDER_MODE (QImode)' returns `HImode'.
-
-`GET_MODE_SIZE (M)'
- Returns the size in bytes of a datum of mode M.
-
-`GET_MODE_BITSIZE (M)'
- Returns the size in bits of a datum of mode M.
-
-`GET_MODE_IBIT (M)'
- Returns the number of integral bits of a datum of fixed-point mode
- M.
-
-`GET_MODE_FBIT (M)'
- Returns the number of fractional bits of a datum of fixed-point
- mode M.
-
-`GET_MODE_MASK (M)'
- Returns a bitmask containing 1 for all bits in a word that fit
- within mode M. This macro can only be used for modes whose
- bitsize is less than or equal to `HOST_BITS_PER_INT'.
-
-`GET_MODE_ALIGNMENT (M)'
- Return the required alignment, in bits, for an object of mode M.
-
-`GET_MODE_UNIT_SIZE (M)'
- Returns the size in bytes of the subunits of a datum of mode M.
- This is the same as `GET_MODE_SIZE' except in the case of complex
- modes. For them, the unit size is the size of the real or
- imaginary part.
-
-`GET_MODE_NUNITS (M)'
- Returns the number of units contained in a mode, i.e.,
- `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'.
-
-`GET_CLASS_NARROWEST_MODE (C)'
- Returns the narrowest mode in mode class C.
-
- The global variables `byte_mode' and `word_mode' contain modes whose
-classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or
-`BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode'
-and `SImode', respectively.
-
-
-File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL
-
-10.7 Constant Expression Types
-==============================
-
-The simplest RTL expressions are those that represent constant values.
-
-`(const_int I)'
- This type of expression represents the integer value I. I is
- customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)',
- which is equivalent to `XWINT (EXP, 0)'.
-
- Constants generated for modes with fewer bits than `HOST_WIDE_INT'
- must be sign extended to full width (e.g., with `gen_int_mode').
-
- There is only one expression object for the integer value zero; it
- is the value of the variable `const0_rtx'. Likewise, the only
- expression for integer value one is found in `const1_rtx', the only
- expression for integer value two is found in `const2_rtx', and the
- only expression for integer value negative one is found in
- `constm1_rtx'. Any attempt to create an expression of code
- `const_int' and value zero, one, two or negative one will return
- `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as
- appropriate.
-
- Similarly, there is only one object for the integer whose value is
- `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If
- `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will
- point to the same object. If `STORE_FLAG_VALUE' is -1,
- `const_true_rtx' and `constm1_rtx' will point to the same object.
-
-`(const_double:M I0 I1 ...)'
- Represents either a floating-point constant of mode M or an
- integer constant too large to fit into `HOST_BITS_PER_WIDE_INT'
- bits but small enough to fit within twice that number of bits (GCC
- does not provide a mechanism to represent even larger constants).
- In the latter case, M will be `VOIDmode'.
-
- If M is `VOIDmode', the bits of the value are stored in I0 and I1.
- I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and
- I1 with `CONST_DOUBLE_HIGH'.
-
- If the constant is floating point (regardless of its precision),
- then the number of integers used to store the value depends on the
- size of `REAL_VALUE_TYPE' (*note Floating Point::). The integers
- represent a floating point number, but not precisely in the target
- machine's or host machine's floating point format. To convert
- them to the precise bit pattern used by the target machine, use
- the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data
- Output::).
-
-`(const_fixed:M ...)'
- Represents a fixed-point constant of mode M. The operand is a
- data structure of type `struct fixed_value' and is accessed with
- the macro `CONST_FIXED_VALUE'. The high part of data is accessed
- with `CONST_FIXED_VALUE_HIGH'; the low part is accessed with
- `CONST_FIXED_VALUE_LOW'.
-
-`(const_vector:M [X0 X1 ...])'
- Represents a vector constant. The square brackets stand for the
- vector containing the constant elements. X0, X1 and so on are the
- `const_int', `const_double' or `const_fixed' elements.
-
- The number of units in a `const_vector' is obtained with the macro
- `CONST_VECTOR_NUNITS' as in `CONST_VECTOR_NUNITS (V)'.
-
- Individual elements in a vector constant are accessed with the
- macro `CONST_VECTOR_ELT' as in `CONST_VECTOR_ELT (V, N)' where V
- is the vector constant and N is the element desired.
-
-`(const_string STR)'
- Represents a constant string with value STR. Currently this is
- used only for insn attributes (*note Insn Attributes::) since
- constant strings in C are placed in memory.
-
-`(symbol_ref:MODE SYMBOL)'
- Represents the value of an assembler label for data. SYMBOL is a
- string that describes the name of the assembler label. If it
- starts with a `*', the label is the rest of SYMBOL not including
- the `*'. Otherwise, the label is SYMBOL, usually prefixed with
- `_'.
-
- The `symbol_ref' contains a mode, which is usually `Pmode'.
- Usually that is the only mode for which a symbol is directly valid.
-
-`(label_ref:MODE LABEL)'
- Represents the value of an assembler label for code. It contains
- one operand, an expression, which must be a `code_label' or a
- `note' of type `NOTE_INSN_DELETED_LABEL' that appears in the
- instruction sequence to identify the place where the label should
- go.
-
- The reason for using a distinct expression type for code label
- references is so that jump optimization can distinguish them.
-
- The `label_ref' contains a mode, which is usually `Pmode'.
- Usually that is the only mode for which a label is directly valid.
-
-`(const:M EXP)'
- Represents a constant that is the result of an assembly-time
- arithmetic computation. The operand, EXP, is an expression that
- contains only constants (`const_int', `symbol_ref' and `label_ref'
- expressions) combined with `plus' and `minus'. However, not all
- combinations are valid, since the assembler cannot do arbitrary
- arithmetic on relocatable symbols.
-
- M should be `Pmode'.
-
-`(high:M EXP)'
- Represents the high-order bits of EXP, usually a `symbol_ref'.
- The number of bits is machine-dependent and is normally the number
- of bits specified in an instruction that initializes the high
- order bits of a register. It is used with `lo_sum' to represent
- the typical two-instruction sequence used in RISC machines to
- reference a global memory location.
-
- M should be `Pmode'.
-
- The macro `CONST0_RTX (MODE)' refers to an expression with value 0 in
-mode MODE. If mode MODE is of mode class `MODE_INT', it returns
-`const0_rtx'. If mode MODE is of mode class `MODE_FLOAT', it returns a
-`CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a
-`CONST_VECTOR' expression in mode MODE. Similarly, the macro
-`CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE
-and similarly for `CONST2_RTX'. The `CONST1_RTX' and `CONST2_RTX'
-macros are undefined for vector modes.
-
-
-File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL
-
-10.8 Registers and Memory
-=========================
-
-Here are the RTL expression types for describing access to machine
-registers and to main memory.
-
-`(reg:M N)'
- For small values of the integer N (those that are less than
- `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine
- register number N: a "hard register". For larger values of N, it
- stands for a temporary value or "pseudo register". The compiler's
- strategy is to generate code assuming an unlimited number of such
- pseudo registers, and later convert them into hard registers or
- into memory references.
-
- M is the machine mode of the reference. It is necessary because
- machines can generally refer to each register in more than one
- mode. For example, a register may contain a full word but there
- may be instructions to refer to it as a half word or as a single
- byte, as well as instructions to refer to it as a floating point
- number of various precisions.
-
- Even for a register that the machine can access in only one mode,
- the mode must always be specified.
-
- The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine
- description, since the number of hard registers on the machine is
- an invariant characteristic of the machine. Note, however, that
- not all of the machine registers must be general registers. All
- the machine registers that can be used for storage of data are
- given hard register numbers, even those that can be used only in
- certain instructions or can hold only certain types of data.
-
- A hard register may be accessed in various modes throughout one
- function, but each pseudo register is given a natural mode and is
- accessed only in that mode. When it is necessary to describe an
- access to a pseudo register using a nonnatural mode, a `subreg'
- expression is used.
-
- A `reg' expression with a machine mode that specifies more than
- one word of data may actually stand for several consecutive
- registers. If in addition the register number specifies a
- hardware register, then it actually represents several consecutive
- hardware registers starting with the specified one.
-
- Each pseudo register number used in a function's RTL code is
- represented by a unique `reg' expression.
-
- Some pseudo register numbers, those within the range of
- `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear
- during the RTL generation phase and are eliminated before the
- optimization phases. These represent locations in the stack frame
- that cannot be determined until RTL generation for the function
- has been completed. The following virtual register numbers are
- defined:
-
- `VIRTUAL_INCOMING_ARGS_REGNUM'
- This points to the first word of the incoming arguments
- passed on the stack. Normally these arguments are placed
- there by the caller, but the callee may have pushed some
- arguments that were previously passed in registers.
-
- When RTL generation is complete, this virtual register is
- replaced by the sum of the register given by
- `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'.
-
- `VIRTUAL_STACK_VARS_REGNUM'
- If `FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this
- points to immediately above the first variable on the stack.
- Otherwise, it points to the first variable on the stack.
-
- `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the
- register given by `FRAME_POINTER_REGNUM' and the value
- `STARTING_FRAME_OFFSET'.
-
- `VIRTUAL_STACK_DYNAMIC_REGNUM'
- This points to the location of dynamically allocated memory
- on the stack immediately after the stack pointer has been
- adjusted by the amount of memory desired.
-
- This virtual register is replaced by the sum of the register
- given by `STACK_POINTER_REGNUM' and the value
- `STACK_DYNAMIC_OFFSET'.
-
- `VIRTUAL_OUTGOING_ARGS_REGNUM'
- This points to the location in the stack at which outgoing
- arguments should be written when the stack is pre-pushed
- (arguments pushed using push insns should always use
- `STACK_POINTER_REGNUM').
-
- This virtual register is replaced by the sum of the register
- given by `STACK_POINTER_REGNUM' and the value
- `STACK_POINTER_OFFSET'.
-
-`(subreg:M1 REG:M2 BYTENUM)'
- `subreg' expressions are used to refer to a register in a machine
- mode other than its natural one, or to refer to one register of a
- multi-part `reg' that actually refers to several registers.
-
- Each pseudo register has a natural mode. If it is necessary to
- operate on it in a different mode, the register must be enclosed
- in a `subreg'.
-
- There are currently three supported types for the first operand of
- a `subreg':
- * pseudo registers This is the most common case. Most
- `subreg's have pseudo `reg's as their first operand.
-
- * mem `subreg's of `mem' were common in earlier versions of GCC
- and are still supported. During the reload pass these are
- replaced by plain `mem's. On machines that do not do
- instruction scheduling, use of `subreg's of `mem' are still
- used, but this is no longer recommended. Such `subreg's are
- considered to be `register_operand's rather than
- `memory_operand's before and during reload. Because of this,
- the scheduling passes cannot properly schedule instructions
- with `subreg's of `mem', so for machines that do scheduling,
- `subreg's of `mem' should never be used. To support this,
- the combine and recog passes have explicit code to inhibit
- the creation of `subreg's of `mem' when `INSN_SCHEDULING' is
- defined.
-
- The use of `subreg's of `mem' after the reload pass is an area
- that is not well understood and should be avoided. There is
- still some code in the compiler to support this, but this
- code has possibly rotted. This use of `subreg's is
- discouraged and will most likely not be supported in the
- future.
-
- * hard registers It is seldom necessary to wrap hard registers
- in `subreg's; such registers would normally reduce to a
- single `reg' rtx. This use of `subreg's is discouraged and
- may not be supported in the future.
-
-
- `subreg's of `subreg's are not supported. Using
- `simplify_gen_subreg' is the recommended way to avoid this problem.
-
- `subreg's come in two distinct flavors, each having its own usage
- and rules:
-
- Paradoxical subregs
- When M1 is strictly wider than M2, the `subreg' expression is
- called "paradoxical". The canonical test for this class of
- `subreg' is:
-
- GET_MODE_SIZE (M1) > GET_MODE_SIZE (M2)
-
- Paradoxical `subreg's can be used as both lvalues and rvalues.
- When used as an lvalue, the low-order bits of the source value
- are stored in REG and the high-order bits are discarded.
- When used as an rvalue, the low-order bits of the `subreg' are
- taken from REG while the high-order bits may or may not be
- defined.
-
- The high-order bits of rvalues are in the following
- circumstances:
-
- * `subreg's of `mem' When M2 is smaller than a word, the
- macro `LOAD_EXTEND_OP', can control how the high-order
- bits are defined.
-
- * `subreg' of `reg's The upper bits are defined when
- `SUBREG_PROMOTED_VAR_P' is true.
- `SUBREG_PROMOTED_UNSIGNED_P' describes what the upper
- bits hold. Such subregs usually represent local
- variables, register variables and parameter pseudo
- variables that have been promoted to a wider mode.
-
-
- BYTENUM is always zero for a paradoxical `subreg', even on
- big-endian targets.
-
- For example, the paradoxical `subreg':
-
- (set (subreg:SI (reg:HI X) 0) Y)
-
- stores the lower 2 bytes of Y in X and discards the upper 2
- bytes. A subsequent:
-
- (set Z (subreg:SI (reg:HI X) 0))
-
- would set the lower two bytes of Z to Y and set the upper two
- bytes to an unknown value assuming `SUBREG_PROMOTED_VAR_P' is
- false.
-
- Normal subregs
- When M1 is at least as narrow as M2 the `subreg' expression
- is called "normal".
-
- Normal `subreg's restrict consideration to certain bits of
- REG. There are two cases. If M1 is smaller than a word, the
- `subreg' refers to the least-significant part (or "lowpart")
- of one word of REG. If M1 is word-sized or greater, the
- `subreg' refers to one or more complete words.
-
- When used as an lvalue, `subreg' is a word-based accessor.
- Storing to a `subreg' modifies all the words of REG that
- overlap the `subreg', but it leaves the other words of REG
- alone.
-
- When storing to a normal `subreg' that is smaller than a word,
- the other bits of the referenced word are usually left in an
- undefined state. This laxity makes it easier to generate
- efficient code for such instructions. To represent an
- instruction that preserves all the bits outside of those in
- the `subreg', use `strict_low_part' or `zero_extract' around
- the `subreg'.
-
- BYTENUM must identify the offset of the first byte of the
- `subreg' from the start of REG, assuming that REG is laid out
- in memory order. The memory order of bytes is defined by two
- target macros, `WORDS_BIG_ENDIAN' and `BYTES_BIG_ENDIAN':
-
- * `WORDS_BIG_ENDIAN', if set to 1, says that byte number
- zero is part of the most significant word; otherwise, it
- is part of the least significant word.
-
- * `BYTES_BIG_ENDIAN', if set to 1, says that byte number
- zero is the most significant byte within a word;
- otherwise, it is the least significant byte within a
- word.
-
- On a few targets, `FLOAT_WORDS_BIG_ENDIAN' disagrees with
- `WORDS_BIG_ENDIAN'. However, most parts of the compiler treat
- floating point values as if they had the same endianness as
- integer values. This works because they handle them solely
- as a collection of integer values, with no particular
- numerical value. Only real.c and the runtime libraries care
- about `FLOAT_WORDS_BIG_ENDIAN'.
-
- Thus,
-
- (subreg:HI (reg:SI X) 2)
-
- on a `BYTES_BIG_ENDIAN', `UNITS_PER_WORD == 4' target is the
- same as
-
- (subreg:HI (reg:SI X) 0)
-
- on a little-endian, `UNITS_PER_WORD == 4' target. Both
- `subreg's access the lower two bytes of register X.
-
-
- A `MODE_PARTIAL_INT' mode behaves as if it were as wide as the
- corresponding `MODE_INT' mode, except that it has an unknown
- number of undefined bits. For example:
-
- (subreg:PSI (reg:SI 0) 0)
-
- accesses the whole of `(reg:SI 0)', but the exact relationship
- between the `PSImode' value and the `SImode' value is not defined.
- If we assume `UNITS_PER_WORD <= 4', then the following two
- `subreg's:
-
- (subreg:PSI (reg:DI 0) 0)
- (subreg:PSI (reg:DI 0) 4)
-
- represent independent 4-byte accesses to the two halves of
- `(reg:DI 0)'. Both `subreg's have an unknown number of undefined
- bits.
-
- If `UNITS_PER_WORD <= 2' then these two `subreg's:
-
- (subreg:HI (reg:PSI 0) 0)
- (subreg:HI (reg:PSI 0) 2)
-
- represent independent 2-byte accesses that together span the whole
- of `(reg:PSI 0)'. Storing to the first `subreg' does not affect
- the value of the second, and vice versa. `(reg:PSI 0)' has an
- unknown number of undefined bits, so the assignment:
-
- (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4))
-
- does not guarantee that `(subreg:HI (reg:PSI 0) 0)' has the value
- `(reg:HI 4)'.
-
- The rules above apply to both pseudo REGs and hard REGs. If the
- semantics are not correct for particular combinations of M1, M2
- and hard REG, the target-specific code must ensure that those
- combinations are never used. For example:
-
- CANNOT_CHANGE_MODE_CLASS (M2, M1, CLASS)
-
- must be true for every class CLASS that includes REG.
-
- The first operand of a `subreg' expression is customarily accessed
- with the `SUBREG_REG' macro and the second operand is customarily
- accessed with the `SUBREG_BYTE' macro.
-
- It has been several years since a platform in which
- `BYTES_BIG_ENDIAN' not equal to `WORDS_BIG_ENDIAN' has been
- tested. Anyone wishing to support such a platform in the future
- may be confronted with code rot.
-
-`(scratch:M)'
- This represents a scratch register that will be required for the
- execution of a single instruction and not used subsequently. It is
- converted into a `reg' by either the local register allocator or
- the reload pass.
-
- `scratch' is usually present inside a `clobber' operation (*note
- Side Effects::).
-
-`(cc0)'
- This refers to the machine's condition code register. It has no
- operands and may not have a machine mode. There are two ways to
- use it:
-
- * To stand for a complete set of condition code flags. This is
- best on most machines, where each comparison sets the entire
- series of flags.
-
- With this technique, `(cc0)' may be validly used in only two
- contexts: as the destination of an assignment (in test and
- compare instructions) and in comparison operators comparing
- against zero (`const_int' with value zero; that is to say,
- `const0_rtx').
-
- * To stand for a single flag that is the result of a single
- condition. This is useful on machines that have only a
- single flag bit, and in which comparison instructions must
- specify the condition to test.
-
- With this technique, `(cc0)' may be validly used in only two
- contexts: as the destination of an assignment (in test and
- compare instructions) where the source is a comparison
- operator, and as the first operand of `if_then_else' (in a
- conditional branch).
-
- There is only one expression object of code `cc0'; it is the value
- of the variable `cc0_rtx'. Any attempt to create an expression of
- code `cc0' will return `cc0_rtx'.
-
- Instructions can set the condition code implicitly. On many
- machines, nearly all instructions set the condition code based on
- the value that they compute or store. It is not necessary to
- record these actions explicitly in the RTL because the machine
- description includes a prescription for recognizing the
- instructions that do so (by means of the macro
- `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions
- whose sole purpose is to set the condition code, and instructions
- that use the condition code, need mention `(cc0)'.
-
- On some machines, the condition code register is given a register
- number and a `reg' is used instead of `(cc0)'. This is usually the
- preferable approach if only a small subset of instructions modify
- the condition code. Other machines store condition codes in
- general registers; in such cases a pseudo register should be used.
-
- Some machines, such as the SPARC and RS/6000, have two sets of
- arithmetic instructions, one that sets and one that does not set
- the condition code. This is best handled by normally generating
- the instruction that does not set the condition code, and making a
- pattern that both performs the arithmetic and sets the condition
- code register (which would not be `(cc0)' in this case). For
- examples, search for `addcc' and `andcc' in `sparc.md'.
-
-`(pc)'
- This represents the machine's program counter. It has no operands
- and may not have a machine mode. `(pc)' may be validly used only
- in certain specific contexts in jump instructions.
-
- There is only one expression object of code `pc'; it is the value
- of the variable `pc_rtx'. Any attempt to create an expression of
- code `pc' will return `pc_rtx'.
-
- All instructions that do not jump alter the program counter
- implicitly by incrementing it, but there is no need to mention
- this in the RTL.
-
-`(mem:M ADDR ALIAS)'
- This RTX represents a reference to main memory at an address
- represented by the expression ADDR. M specifies how large a unit
- of memory is accessed. ALIAS specifies an alias set for the
- reference. In general two items are in different alias sets if
- they cannot reference the same memory address.
-
- The construct `(mem:BLK (scratch))' is considered to alias all
- other memories. Thus it may be used as a memory barrier in
- epilogue stack deallocation patterns.
-
-`(concatM RTX RTX)'
- This RTX represents the concatenation of two other RTXs. This is
- used for complex values. It should only appear in the RTL
- attached to declarations and during RTL generation. It should not
- appear in the ordinary insn chain.
-
-`(concatnM [RTX ...])'
- This RTX represents the concatenation of all the RTX to make a
- single value. Like `concat', this should only appear in
- declarations, and not in the insn chain.
-
-
-File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL
-
-10.9 RTL Expressions for Arithmetic
-===================================
-
-Unless otherwise specified, all the operands of arithmetic expressions
-must be valid for mode M. An operand is valid for mode M if it has
-mode M, or if it is a `const_int' or `const_double' and M is a mode of
-class `MODE_INT'.
-
- For commutative binary operations, constants should be placed in the
-second operand.
-
-`(plus:M X Y)'
-`(ss_plus:M X Y)'
-`(us_plus:M X Y)'
- These three expressions all represent the sum of the values
- represented by X and Y carried out in machine mode M. They differ
- in their behavior on overflow of integer modes. `plus' wraps
- round modulo the width of M; `ss_plus' saturates at the maximum
- signed value representable in M; `us_plus' saturates at the
- maximum unsigned value.
-
-`(lo_sum:M X Y)'
- This expression represents the sum of X and the low-order bits of
- Y. It is used with `high' (*note Constants::) to represent the
- typical two-instruction sequence used in RISC machines to
- reference a global memory location.
-
- The number of low order bits is machine-dependent but is normally
- the number of bits in a `Pmode' item minus the number of bits set
- by `high'.
-
- M should be `Pmode'.
-
-`(minus:M X Y)'
-`(ss_minus:M X Y)'
-`(us_minus:M X Y)'
- These three expressions represent the result of subtracting Y from
- X, carried out in mode M. Behavior on overflow is the same as for
- the three variants of `plus' (see above).
-
-`(compare:M X Y)'
- Represents the result of subtracting Y from X for purposes of
- comparison. The result is computed without overflow, as if with
- infinite precision.
-
- Of course, machines can't really subtract with infinite precision.
- However, they can pretend to do so when only the sign of the
- result will be used, which is the case when the result is stored
- in the condition code. And that is the _only_ way this kind of
- expression may validly be used: as a value to be stored in the
- condition codes, either `(cc0)' or a register. *Note
- Comparisons::.
-
- The mode M is not related to the modes of X and Y, but instead is
- the mode of the condition code value. If `(cc0)' is used, it is
- `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often
- `CCmode'. *Note Condition Code::. If M is `VOIDmode' or
- `CCmode', the operation returns sufficient information (in an
- unspecified format) so that any comparison operator can be applied
- to the result of the `COMPARE' operation. For other modes in
- class `MODE_CC', the operation only returns a subset of this
- information.
-
- Normally, X and Y must have the same mode. Otherwise, `compare'
- is valid only if the mode of X is in class `MODE_INT' and Y is a
- `const_int' or `const_double' with mode `VOIDmode'. The mode of X
- determines what mode the comparison is to be done in; thus it must
- not be `VOIDmode'.
-
- If one of the operands is a constant, it should be placed in the
- second operand and the comparison code adjusted as appropriate.
-
- A `compare' specifying two `VOIDmode' constants is not valid since
- there is no way to know in what mode the comparison is to be
- performed; the comparison must either be folded during the
- compilation or the first operand must be loaded into a register
- while its mode is still known.
-
-`(neg:M X)'
-`(ss_neg:M X)'
-`(us_neg:M X)'
- These two expressions represent the negation (subtraction from
- zero) of the value represented by X, carried out in mode M. They
- differ in the behavior on overflow of integer modes. In the case
- of `neg', the negation of the operand may be a number not
- representable in mode M, in which case it is truncated to M.
- `ss_neg' and `us_neg' ensure that an out-of-bounds result
- saturates to the maximum or minimum signed or unsigned value.
-
-`(mult:M X Y)'
-`(ss_mult:M X Y)'
-`(us_mult:M X Y)'
- Represents the signed product of the values represented by X and Y
- carried out in machine mode M. `ss_mult' and `us_mult' ensure
- that an out-of-bounds result saturates to the maximum or minimum
- signed or unsigned value.
-
- Some machines support a multiplication that generates a product
- wider than the operands. Write the pattern for this as
-
- (mult:M (sign_extend:M X) (sign_extend:M Y))
-
- where M is wider than the modes of X and Y, which need not be the
- same.
-
- For unsigned widening multiplication, use the same idiom, but with
- `zero_extend' instead of `sign_extend'.
-
-`(fma:M X Y Z)'
- Represents the `fma', `fmaf', and `fmal' builtin functions that do
- a combined multiply of X and Y and then adding toZ without doing
- an intermediate rounding step.
-
-`(div:M X Y)'
-`(ss_div:M X Y)'
- Represents the quotient in signed division of X by Y, carried out
- in machine mode M. If M is a floating point mode, it represents
- the exact quotient; otherwise, the integerized quotient. `ss_div'
- ensures that an out-of-bounds result saturates to the maximum or
- minimum signed value.
-
- Some machines have division instructions in which the operands and
- quotient widths are not all the same; you should represent such
- instructions using `truncate' and `sign_extend' as in,
-
- (truncate:M1 (div:M2 X (sign_extend:M2 Y)))
-
-`(udiv:M X Y)'
-`(us_div:M X Y)'
- Like `div' but represents unsigned division. `us_div' ensures
- that an out-of-bounds result saturates to the maximum or minimum
- unsigned value.
-
-`(mod:M X Y)'
-`(umod:M X Y)'
- Like `div' and `udiv' but represent the remainder instead of the
- quotient.
-
-`(smin:M X Y)'
-`(smax:M X Y)'
- Represents the smaller (for `smin') or larger (for `smax') of X
- and Y, interpreted as signed values in mode M. When used with
- floating point, if both operands are zeros, or if either operand
- is `NaN', then it is unspecified which of the two operands is
- returned as the result.
-
-`(umin:M X Y)'
-`(umax:M X Y)'
- Like `smin' and `smax', but the values are interpreted as unsigned
- integers.
-
-`(not:M X)'
- Represents the bitwise complement of the value represented by X,
- carried out in mode M, which must be a fixed-point machine mode.
-
-`(and:M X Y)'
- Represents the bitwise logical-and of the values represented by X
- and Y, carried out in machine mode M, which must be a fixed-point
- machine mode.
-
-`(ior:M X Y)'
- Represents the bitwise inclusive-or of the values represented by X
- and Y, carried out in machine mode M, which must be a fixed-point
- mode.
-
-`(xor:M X Y)'
- Represents the bitwise exclusive-or of the values represented by X
- and Y, carried out in machine mode M, which must be a fixed-point
- mode.
-
-`(ashift:M X C)'
-`(ss_ashift:M X C)'
-`(us_ashift:M X C)'
- These three expressions represent the result of arithmetically
- shifting X left by C places. They differ in their behavior on
- overflow of integer modes. An `ashift' operation is a plain shift
- with no special behavior in case of a change in the sign bit;
- `ss_ashift' and `us_ashift' saturates to the minimum or maximum
- representable value if any of the bits shifted out differs from
- the final sign bit.
-
- X have mode M, a fixed-point machine mode. C be a fixed-point
- mode or be a constant with mode `VOIDmode'; which mode is
- determined by the mode called for in the machine description entry
- for the left-shift instruction. For example, on the VAX, the mode
- of C is `QImode' regardless of M.
-
-`(lshiftrt:M X C)'
-`(ashiftrt:M X C)'
- Like `ashift' but for right shift. Unlike the case for left shift,
- these two operations are distinct.
-
-`(rotate:M X C)'
-`(rotatert:M X C)'
- Similar but represent left and right rotate. If C is a constant,
- use `rotate'.
-
-`(abs:M X)'
-
-`(ss_abs:M X)'
- Represents the absolute value of X, computed in mode M. `ss_abs'
- ensures that an out-of-bounds result saturates to the maximum
- signed value.
-
-`(sqrt:M X)'
- Represents the square root of X, computed in mode M. Most often M
- will be a floating point mode.
-
-`(ffs:M X)'
- Represents one plus the index of the least significant 1-bit in X,
- represented as an integer of mode M. (The value is zero if X is
- zero.) The mode of X need not be M; depending on the target
- machine, various mode combinations may be valid.
-
-`(clz:M X)'
- Represents the number of leading 0-bits in X, represented as an
- integer of mode M, starting at the most significant bit position.
- If X is zero, the value is determined by
- `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one
- of the few expressions that is not invariant under widening. The
- mode of X will usually be an integer mode.
-
-`(ctz:M X)'
- Represents the number of trailing 0-bits in X, represented as an
- integer of mode M, starting at the least significant bit position.
- If X is zero, the value is determined by
- `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case,
- `ctz(x)' is equivalent to `ffs(X) - 1'. The mode of X will
- usually be an integer mode.
-
-`(popcount:M X)'
- Represents the number of 1-bits in X, represented as an integer of
- mode M. The mode of X will usually be an integer mode.
-
-`(parity:M X)'
- Represents the number of 1-bits modulo 2 in X, represented as an
- integer of mode M. The mode of X will usually be an integer mode.
-
-`(bswap:M X)'
- Represents the value X with the order of bytes reversed, carried
- out in mode M, which must be a fixed-point machine mode.
-
-
-File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL
-
-10.10 Comparison Operations
-===========================
-
-Comparison operators test a relation on two operands and are considered
-to represent a machine-dependent nonzero value described by, but not
-necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::) if the relation
-holds, or zero if it does not, for comparison operators whose results
-have a `MODE_INT' mode, `FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the
-relation holds, or zero if it does not, for comparison operators that
-return floating-point values, and a vector of either
-`VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of
-zeros if it does not, for comparison operators that return vector
-results. The mode of the comparison operation is independent of the
-mode of the data being compared. If the comparison operation is being
-tested (e.g., the first operand of an `if_then_else'), the mode must be
-`VOIDmode'.
-
- There are two ways that comparison operations may be used. The
-comparison operators may be used to compare the condition codes `(cc0)'
-against zero, as in `(eq (cc0) (const_int 0))'. Such a construct
-actually refers to the result of the preceding instruction in which the
-condition codes were set. The instruction setting the condition code
-must be adjacent to the instruction using the condition code; only
-`note' insns may separate them.
-
- Alternatively, a comparison operation may directly compare two data
-objects. The mode of the comparison is determined by the operands; they
-must both be valid for a common machine mode. A comparison with both
-operands constant would be invalid as the machine mode could not be
-deduced from it, but such a comparison should never exist in RTL due to
-constant folding.
-
- In the example above, if `(cc0)' were last set to `(compare X Y)', the
-comparison operation is identical to `(eq X Y)'. Usually only one style
-of comparisons is supported on a particular machine, but the combine
-pass will try to merge the operations to produce the `eq' shown in case
-it exists in the context of the particular insn involved.
-
- Inequality comparisons come in two flavors, signed and unsigned. Thus,
-there are distinct expression codes `gt' and `gtu' for signed and
-unsigned greater-than. These can produce different results for the same
-pair of integer values: for example, 1 is signed greater-than -1 but not
-unsigned greater-than, because -1 when regarded as unsigned is actually
-`0xffffffff' which is greater than 1.
-
- The signed comparisons are also used for floating point values.
-Floating point comparisons are distinguished by the machine modes of
-the operands.
-
-`(eq:M X Y)'
- `STORE_FLAG_VALUE' if the values represented by X and Y are equal,
- otherwise 0.
-
-`(ne:M X Y)'
- `STORE_FLAG_VALUE' if the values represented by X and Y are not
- equal, otherwise 0.
-
-`(gt:M X Y)'
- `STORE_FLAG_VALUE' if the X is greater than Y. If they are
- fixed-point, the comparison is done in a signed sense.
-
-`(gtu:M X Y)'
- Like `gt' but does unsigned comparison, on fixed-point numbers
- only.
-
-`(lt:M X Y)'
-`(ltu:M X Y)'
- Like `gt' and `gtu' but test for "less than".
-
-`(ge:M X Y)'
-`(geu:M X Y)'
- Like `gt' and `gtu' but test for "greater than or equal".
-
-`(le:M X Y)'
-`(leu:M X Y)'
- Like `gt' and `gtu' but test for "less than or equal".
-
-`(if_then_else COND THEN ELSE)'
- This is not a comparison operation but is listed here because it is
- always used in conjunction with a comparison operation. To be
- precise, COND is a comparison expression. This expression
- represents a choice, according to COND, between the value
- represented by THEN and the one represented by ELSE.
-
- On most machines, `if_then_else' expressions are valid only to
- express conditional jumps.
-
-`(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)'
- Similar to `if_then_else', but more general. Each of TEST1,
- TEST2, ... is performed in turn. The result of this expression is
- the VALUE corresponding to the first nonzero test, or DEFAULT if
- none of the tests are nonzero expressions.
-
- This is currently not valid for instruction patterns and is
- supported only for insn attributes. *Note Insn Attributes::.
-
-
-File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL
-
-10.11 Bit-Fields
-================
-
-Special expression codes exist to represent bit-field instructions.
-
-`(sign_extract:M LOC SIZE POS)'
- This represents a reference to a sign-extended bit-field contained
- or starting in LOC (a memory or register reference). The bit-field
- is SIZE bits wide and starts at bit POS. The compilation option
- `BITS_BIG_ENDIAN' says which end of the memory unit POS counts
- from.
-
- If LOC is in memory, its mode must be a single-byte integer mode.
- If LOC is in a register, the mode to use is specified by the
- operand of the `insv' or `extv' pattern (*note Standard Names::)
- and is usually a full-word integer mode, which is the default if
- none is specified.
-
- The mode of POS is machine-specific and is also specified in the
- `insv' or `extv' pattern.
-
- The mode M is the same as the mode that would be used for LOC if
- it were a register.
-
- A `sign_extract' can not appear as an lvalue, or part thereof, in
- RTL.
-
-`(zero_extract:M LOC SIZE POS)'
- Like `sign_extract' but refers to an unsigned or zero-extended
- bit-field. The same sequence of bits are extracted, but they are
- filled to an entire word with zeros instead of by sign-extension.
-
- Unlike `sign_extract', this type of expressions can be lvalues in
- RTL; they may appear on the left side of an assignment, indicating
- insertion of a value into the specified bit-field.
-
-
-File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL
-
-10.12 Vector Operations
-=======================
-
-All normal RTL expressions can be used with vector modes; they are
-interpreted as operating on each part of the vector independently.
-Additionally, there are a few new expressions to describe specific
-vector operations.
-
-`(vec_merge:M VEC1 VEC2 ITEMS)'
- This describes a merge operation between two vectors. The result
- is a vector of mode M; its elements are selected from either VEC1
- or VEC2. Which elements are selected is described by ITEMS, which
- is a bit mask represented by a `const_int'; a zero bit indicates
- the corresponding element in the result vector is taken from VEC2
- while a set bit indicates it is taken from VEC1.
-
-`(vec_select:M VEC1 SELECTION)'
- This describes an operation that selects parts of a vector. VEC1
- is the source vector, and SELECTION is a `parallel' that contains a
- `const_int' for each of the subparts of the result vector, giving
- the number of the source subpart that should be stored into it.
- The result mode M is either the submode for a single element of
- VEC1 (if only one subpart is selected), or another vector mode
- with that element submode (if multiple subparts are selected).
-
-`(vec_concat:M VEC1 VEC2)'
- Describes a vector concat operation. The result is a
- concatenation of the vectors VEC1 and VEC2; its length is the sum
- of the lengths of the two inputs.
-
-`(vec_duplicate:M VEC)'
- This operation converts a small vector into a larger one by
- duplicating the input values. The output vector mode must have
- the same submodes as the input vector mode, and the number of
- output parts must be an integer multiple of the number of input
- parts.
-
-
-
-File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL
-
-10.13 Conversions
-=================
-
-All conversions between machine modes must be represented by explicit
-conversion operations. For example, an expression which is the sum of
-a byte and a full word cannot be written as `(plus:SI (reg:QI 34)
-(reg:SI 80))' because the `plus' operation requires two operands of the
-same machine mode. Therefore, the byte-sized operand is enclosed in a
-conversion operation, as in
-
- (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
-
- The conversion operation is not a mere placeholder, because there may
-be more than one way of converting from a given starting mode to the
-desired final mode. The conversion operation code says how to do it.
-
- For all conversion operations, X must not be `VOIDmode' because the
-mode in which to do the conversion would not be known. The conversion
-must either be done at compile-time or X must be placed into a register.
-
-`(sign_extend:M X)'
- Represents the result of sign-extending the value X to machine
- mode M. M must be a fixed-point mode and X a fixed-point value of
- a mode narrower than M.
-
-`(zero_extend:M X)'
- Represents the result of zero-extending the value X to machine
- mode M. M must be a fixed-point mode and X a fixed-point value of
- a mode narrower than M.
-
-`(float_extend:M X)'
- Represents the result of extending the value X to machine mode M.
- M must be a floating point mode and X a floating point value of a
- mode narrower than M.
-
-`(truncate:M X)'
- Represents the result of truncating the value X to machine mode M.
- M must be a fixed-point mode and X a fixed-point value of a mode
- wider than M.
-
-`(ss_truncate:M X)'
- Represents the result of truncating the value X to machine mode M,
- using signed saturation in the case of overflow. Both M and the
- mode of X must be fixed-point modes.
-
-`(us_truncate:M X)'
- Represents the result of truncating the value X to machine mode M,
- using unsigned saturation in the case of overflow. Both M and the
- mode of X must be fixed-point modes.
-
-`(float_truncate:M X)'
- Represents the result of truncating the value X to machine mode M.
- M must be a floating point mode and X a floating point value of a
- mode wider than M.
-
-`(float:M X)'
- Represents the result of converting fixed point value X, regarded
- as signed, to floating point mode M.
-
-`(unsigned_float:M X)'
- Represents the result of converting fixed point value X, regarded
- as unsigned, to floating point mode M.
-
-`(fix:M X)'
- When M is a floating-point mode, represents the result of
- converting floating point value X (valid for mode M) to an
- integer, still represented in floating point mode M, by rounding
- towards zero.
-
- When M is a fixed-point mode, represents the result of converting
- floating point value X to mode M, regarded as signed. How
- rounding is done is not specified, so this operation may be used
- validly in compiling C code only for integer-valued operands.
-
-`(unsigned_fix:M X)'
- Represents the result of converting floating point value X to
- fixed point mode M, regarded as unsigned. How rounding is done is
- not specified.
-
-`(fract_convert:M X)'
- Represents the result of converting fixed-point value X to
- fixed-point mode M, signed integer value X to fixed-point mode M,
- floating-point value X to fixed-point mode M, fixed-point value X
- to integer mode M regarded as signed, or fixed-point value X to
- floating-point mode M. When overflows or underflows happen, the
- results are undefined.
-
-`(sat_fract:M X)'
- Represents the result of converting fixed-point value X to
- fixed-point mode M, signed integer value X to fixed-point mode M,
- or floating-point value X to fixed-point mode M. When overflows
- or underflows happen, the results are saturated to the maximum or
- the minimum.
-
-`(unsigned_fract_convert:M X)'
- Represents the result of converting fixed-point value X to integer
- mode M regarded as unsigned, or unsigned integer value X to
- fixed-point mode M. When overflows or underflows happen, the
- results are undefined.
-
-`(unsigned_sat_fract:M X)'
- Represents the result of converting unsigned integer value X to
- fixed-point mode M. When overflows or underflows happen, the
- results are saturated to the maximum or the minimum.
-
-
-File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL
-
-10.14 Declarations
-==================
-
-Declaration expression codes do not represent arithmetic operations but
-rather state assertions about their operands.
-
-`(strict_low_part (subreg:M (reg:N R) 0))'
- This expression code is used in only one context: as the
- destination operand of a `set' expression. In addition, the
- operand of this expression must be a non-paradoxical `subreg'
- expression.
-
- The presence of `strict_low_part' says that the part of the
- register which is meaningful in mode N, but is not part of mode M,
- is not to be altered. Normally, an assignment to such a subreg is
- allowed to have undefined effects on the rest of the register when
- M is less than a word.
-
-
-File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL
-
-10.15 Side Effect Expressions
-=============================
-
-The expression codes described so far represent values, not actions.
-But machine instructions never produce values; they are meaningful only
-for their side effects on the state of the machine. Special expression
-codes are used to represent side effects.
-
- The body of an instruction is always one of these side effect codes;
-the codes described above, which represent values, appear only as the
-operands of these.
-
-`(set LVAL X)'
- Represents the action of storing the value of X into the place
- represented by LVAL. LVAL must be an expression representing a
- place that can be stored in: `reg' (or `subreg', `strict_low_part'
- or `zero_extract'), `mem', `pc', `parallel', or `cc0'.
-
- If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then
- X must be valid for that mode.
-
- If LVAL is a `reg' whose machine mode is less than the full width
- of the register, then it means that the part of the register
- specified by the machine mode is given the specified value and the
- rest of the register receives an undefined value. Likewise, if
- LVAL is a `subreg' whose machine mode is narrower than the mode of
- the register, the rest of the register can be changed in an
- undefined way.
-
- If LVAL is a `strict_low_part' of a subreg, then the part of the
- register specified by the machine mode of the `subreg' is given
- the value X and the rest of the register is not changed.
-
- If LVAL is a `zero_extract', then the referenced part of the
- bit-field (a memory or register reference) specified by the
- `zero_extract' is given the value X and the rest of the bit-field
- is not changed. Note that `sign_extract' can not appear in LVAL.
-
- If LVAL is `(cc0)', it has no machine mode, and X may be either a
- `compare' expression or a value that may have any mode. The
- latter case represents a "test" instruction. The expression `(set
- (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N)
- (const_int 0)))'. Use the former expression to save space during
- the compilation.
-
- If LVAL is a `parallel', it is used to represent the case of a
- function returning a structure in multiple registers. Each element
- of the `parallel' is an `expr_list' whose first operand is a `reg'
- and whose second operand is a `const_int' representing the offset
- (in bytes) into the structure at which the data in that register
- corresponds. The first element may be null to indicate that the
- structure is also passed partly in memory.
-
- If LVAL is `(pc)', we have a jump instruction, and the
- possibilities for X are very limited. It may be a `label_ref'
- expression (unconditional jump). It may be an `if_then_else'
- (conditional jump), in which case either the second or the third
- operand must be `(pc)' (for the case which does not jump) and the
- other of the two must be a `label_ref' (for the case which does
- jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may
- be a `reg' or a `mem'; these unusual patterns are used to
- represent jumps through branch tables.
-
- If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not
- be `VOIDmode' and the mode of X must be valid for the mode of LVAL.
-
- LVAL is customarily accessed with the `SET_DEST' macro and X with
- the `SET_SRC' macro.
-
-`(return)'
- As the sole expression in a pattern, represents a return from the
- current function, on machines where this can be done with one
- instruction, such as VAXen. On machines where a multi-instruction
- "epilogue" must be executed in order to return from the function,
- returning is done by jumping to a label which precedes the
- epilogue, and the `return' expression code is never used.
-
- Inside an `if_then_else' expression, represents the value to be
- placed in `pc' to return to the caller.
-
- Note that an insn pattern of `(return)' is logically equivalent to
- `(set (pc) (return))', but the latter form is never used.
-
-`(call FUNCTION NARGS)'
- Represents a function call. FUNCTION is a `mem' expression whose
- address is the address of the function to be called. NARGS is an
- expression which can be used for two purposes: on some machines it
- represents the number of bytes of stack argument; on others, it
- represents the number of argument registers.
-
- Each machine has a standard machine mode which FUNCTION must have.
- The machine description defines macro `FUNCTION_MODE' to expand
- into the requisite mode name. The purpose of this mode is to
- specify what kind of addressing is allowed, on machines where the
- allowed kinds of addressing depend on the machine mode being
- addressed.
-
-`(clobber X)'
- Represents the storing or possible storing of an unpredictable,
- undescribed value into X, which must be a `reg', `scratch',
- `parallel' or `mem' expression.
-
- One place this is used is in string instructions that store
- standard values into particular hard registers. It may not be
- worth the trouble to describe the values that are stored, but it
- is essential to inform the compiler that the registers will be
- altered, lest it attempt to keep data in them across the string
- instruction.
-
- If X is `(mem:BLK (const_int 0))' or `(mem:BLK (scratch))', it
- means that all memory locations must be presumed clobbered. If X
- is a `parallel', it has the same meaning as a `parallel' in a
- `set' expression.
-
- Note that the machine description classifies certain hard
- registers as "call-clobbered". All function call instructions are
- assumed by default to clobber these registers, so there is no need
- to use `clobber' expressions to indicate this fact. Also, each
- function call is assumed to have the potential to alter any memory
- location, unless the function is declared `const'.
-
- If the last group of expressions in a `parallel' are each a
- `clobber' expression whose arguments are `reg' or `match_scratch'
- (*note RTL Template::) expressions, the combiner phase can add the
- appropriate `clobber' expressions to an insn it has constructed
- when doing so will cause a pattern to be matched.
-
- This feature can be used, for example, on a machine that whose
- multiply and add instructions don't use an MQ register but which
- has an add-accumulate instruction that does clobber the MQ
- register. Similarly, a combined instruction might require a
- temporary register while the constituent instructions might not.
-
- When a `clobber' expression for a register appears inside a
- `parallel' with other side effects, the register allocator
- guarantees that the register is unoccupied both before and after
- that insn if it is a hard register clobber. For pseudo-register
- clobber, the register allocator and the reload pass do not assign
- the same hard register to the clobber and the input operands if
- there is an insn alternative containing the `&' constraint (*note
- Modifiers::) for the clobber and the hard register is in register
- classes of the clobber in the alternative. You can clobber either
- a specific hard register, a pseudo register, or a `scratch'
- expression; in the latter two cases, GCC will allocate a hard
- register that is available there for use as a temporary.
-
- For instructions that require a temporary register, you should use
- `scratch' instead of a pseudo-register because this will allow the
- combiner phase to add the `clobber' when required. You do this by
- coding (`clobber' (`match_scratch' ...)). If you do clobber a
- pseudo register, use one which appears nowhere else--generate a
- new one each time. Otherwise, you may confuse CSE.
-
- There is one other known use for clobbering a pseudo register in a
- `parallel': when one of the input operands of the insn is also
- clobbered by the insn. In this case, using the same pseudo
- register in the clobber and elsewhere in the insn produces the
- expected results.
-
-`(use X)'
- Represents the use of the value of X. It indicates that the value
- in X at this point in the program is needed, even though it may
- not be apparent why this is so. Therefore, the compiler will not
- attempt to delete previous instructions whose only effect is to
- store a value in X. X must be a `reg' expression.
-
- In some situations, it may be tempting to add a `use' of a
- register in a `parallel' to describe a situation where the value
- of a special register will modify the behavior of the instruction.
- A hypothetical example might be a pattern for an addition that can
- either wrap around or use saturating addition depending on the
- value of a special control register:
-
- (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3)
- (reg:SI 4)] 0))
- (use (reg:SI 1))])
-
- This will not work, several of the optimizers only look at
- expressions locally; it is very likely that if you have multiple
- insns with identical inputs to the `unspec', they will be
- optimized away even if register 1 changes in between.
-
- This means that `use' can _only_ be used to describe that the
- register is live. You should think twice before adding `use'
- statements, more often you will want to use `unspec' instead. The
- `use' RTX is most commonly useful to describe that a fixed
- register is implicitly used in an insn. It is also safe to use in
- patterns where the compiler knows for other reasons that the result
- of the whole pattern is variable, such as `movmemM' or `call'
- patterns.
-
- During the reload phase, an insn that has a `use' as pattern can
- carry a reg_equal note. These `use' insns will be deleted before
- the reload phase exits.
-
- During the delayed branch scheduling phase, X may be an insn.
- This indicates that X previously was located at this place in the
- code and its data dependencies need to be taken into account.
- These `use' insns will be deleted before the delayed branch
- scheduling phase exits.
-
-`(parallel [X0 X1 ...])'
- Represents several side effects performed in parallel. The square
- brackets stand for a vector; the operand of `parallel' is a vector
- of expressions. X0, X1 and so on are individual side effect
- expressions--expressions of code `set', `call', `return',
- `clobber' or `use'.
-
- "In parallel" means that first all the values used in the
- individual side-effects are computed, and second all the actual
- side-effects are performed. For example,
-
- (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
- (set (mem:SI (reg:SI 1)) (reg:SI 1))])
-
- says unambiguously that the values of hard register 1 and the
- memory location addressed by it are interchanged. In both places
- where `(reg:SI 1)' appears as a memory address it refers to the
- value in register 1 _before_ the execution of the insn.
-
- It follows that it is _incorrect_ to use `parallel' and expect the
- result of one `set' to be available for the next one. For
- example, people sometimes attempt to represent a jump-if-zero
- instruction this way:
-
- (parallel [(set (cc0) (reg:SI 34))
- (set (pc) (if_then_else
- (eq (cc0) (const_int 0))
- (label_ref ...)
- (pc)))])
-
- But this is incorrect, because it says that the jump condition
- depends on the condition code value _before_ this instruction, not
- on the new value that is set by this instruction.
-
- Peephole optimization, which takes place together with final
- assembly code output, can produce insns whose patterns consist of
- a `parallel' whose elements are the operands needed to output the
- resulting assembler code--often `reg', `mem' or constant
- expressions. This would not be well-formed RTL at any other stage
- in compilation, but it is ok then because no further optimization
- remains to be done. However, the definition of the macro
- `NOTICE_UPDATE_CC', if any, must deal with such insns if you
- define any peephole optimizations.
-
-`(cond_exec [COND EXPR])'
- Represents a conditionally executed expression. The EXPR is
- executed only if the COND is nonzero. The COND expression must
- not have side-effects, but the EXPR may very well have
- side-effects.
-
-`(sequence [INSNS ...])'
- Represents a sequence of insns. Each of the INSNS that appears in
- the vector is suitable for appearing in the chain of insns, so it
- must be an `insn', `jump_insn', `call_insn', `code_label',
- `barrier' or `note'.
-
- A `sequence' RTX is never placed in an actual insn during RTL
- generation. It represents the sequence of insns that result from a
- `define_expand' _before_ those insns are passed to `emit_insn' to
- insert them in the chain of insns. When actually inserted, the
- individual sub-insns are separated out and the `sequence' is
- forgotten.
-
- After delay-slot scheduling is completed, an insn and all the
- insns that reside in its delay slots are grouped together into a
- `sequence'. The insn requiring the delay slot is the first insn
- in the vector; subsequent insns are to be placed in the delay slot.
-
- `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to
- indicate that a branch insn should be used that will conditionally
- annul the effect of the insns in the delay slots. In such a case,
- `INSN_FROM_TARGET_P' indicates that the insn is from the target of
- the branch and should be executed only if the branch is taken;
- otherwise the insn should be executed only if the branch is not
- taken. *Note Delay Slots::.
-
- These expression codes appear in place of a side effect, as the body of
-an insn, though strictly speaking they do not always describe side
-effects as such:
-
-`(asm_input S)'
- Represents literal assembler code as described by the string S.
-
-`(unspec [OPERANDS ...] INDEX)'
-`(unspec_volatile [OPERANDS ...] INDEX)'
- Represents a machine-specific operation on OPERANDS. INDEX
- selects between multiple machine-specific operations.
- `unspec_volatile' is used for volatile operations and operations
- that may trap; `unspec' is used for other operations.
-
- These codes may appear inside a `pattern' of an insn, inside a
- `parallel', or inside an expression.
-
-`(addr_vec:M [LR0 LR1 ...])'
- Represents a table of jump addresses. The vector elements LR0,
- etc., are `label_ref' expressions. The mode M specifies how much
- space is given to each address; normally M would be `Pmode'.
-
-`(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)'
- Represents a table of jump addresses expressed as offsets from
- BASE. The vector elements LR0, etc., are `label_ref' expressions
- and so is BASE. The mode M specifies how much space is given to
- each address-difference. MIN and MAX are set up by branch
- shortening and hold a label with a minimum and a maximum address,
- respectively. FLAGS indicates the relative position of BASE, MIN
- and MAX to the containing insn and of MIN and MAX to BASE. See
- rtl.def for details.
-
-`(prefetch:M ADDR RW LOCALITY)'
- Represents prefetch of memory at address ADDR. Operand RW is 1 if
- the prefetch is for data to be written, 0 otherwise; targets that
- do not support write prefetches should treat this as a normal
- prefetch. Operand LOCALITY specifies the amount of temporal
- locality; 0 if there is none or 1, 2, or 3 for increasing levels
- of temporal locality; targets that do not support locality hints
- should ignore this.
-
- This insn is used to minimize cache-miss latency by moving data
- into a cache before it is accessed. It should use only
- non-faulting data prefetch instructions.
-
-
-File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL
-
-10.16 Embedded Side-Effects on Addresses
-========================================
-
-Six special side-effect expression codes appear as memory addresses.
-
-`(pre_dec:M X)'
- Represents the side effect of decrementing X by a standard amount
- and represents also the value that X has after being decremented.
- X must be a `reg' or `mem', but most machines allow only a `reg'.
- M must be the machine mode for pointers on the machine in use.
- The amount X is decremented by is the length in bytes of the
- machine mode of the containing memory reference of which this
- expression serves as the address. Here is an example of its use:
-
- (mem:DF (pre_dec:SI (reg:SI 39)))
-
- This says to decrement pseudo register 39 by the length of a
- `DFmode' value and use the result to address a `DFmode' value.
-
-`(pre_inc:M X)'
- Similar, but specifies incrementing X instead of decrementing it.
-
-`(post_dec:M X)'
- Represents the same side effect as `pre_dec' but a different
- value. The value represented here is the value X has before being
- decremented.
-
-`(post_inc:M X)'
- Similar, but specifies incrementing X instead of decrementing it.
-
-`(post_modify:M X Y)'
- Represents the side effect of setting X to Y and represents X
- before X is modified. X must be a `reg' or `mem', but most
- machines allow only a `reg'. M must be the machine mode for
- pointers on the machine in use.
-
- The expression Y must be one of three forms: `(plus:M X Z)',
- `(minus:M X Z)', or `(plus:M X I)', where Z is an index register
- and I is a constant.
-
- Here is an example of its use:
-
- (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42)
- (reg:SI 48))))
-
- This says to modify pseudo register 42 by adding the contents of
- pseudo register 48 to it, after the use of what ever 42 points to.
-
-`(pre_modify:M X EXPR)'
- Similar except side effects happen before the use.
-
- These embedded side effect expressions must be used with care.
-Instruction patterns may not use them. Until the `flow' pass of the
-compiler, they may occur only to represent pushes onto the stack. The
-`flow' pass finds cases where registers are incremented or decremented
-in one instruction and used as an address shortly before or after;
-these cases are then transformed to use pre- or post-increment or
--decrement.
-
- If a register used as the operand of these expressions is used in
-another address in an insn, the original value of the register is used.
-Uses of the register outside of an address are not permitted within the
-same insn as a use in an embedded side effect expression because such
-insns behave differently on different machines and hence must be treated
-as ambiguous and disallowed.
-
- An instruction that can be represented with an embedded side effect
-could also be represented using `parallel' containing an additional
-`set' to describe how the address register is altered. This is not
-done because machines that allow these operations at all typically
-allow them wherever a memory address is called for. Describing them as
-additional parallel stores would require doubling the number of entries
-in the machine description.
-
-
-File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL
-
-10.17 Assembler Instructions as Expressions
-===========================================
-
-The RTX code `asm_operands' represents a value produced by a
-user-specified assembler instruction. It is used to represent an `asm'
-statement with arguments. An `asm' statement with a single output
-operand, like this:
-
- asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
-
-is represented using a single `asm_operands' RTX which represents the
-value that is stored in `outputvar':
-
- (set RTX-FOR-OUTPUTVAR
- (asm_operands "foo %1,%2,%0" "a" 0
- [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
- [(asm_input:M1 "g")
- (asm_input:M2 "di")]))
-
-Here the operands of the `asm_operands' RTX are the assembler template
-string, the output-operand's constraint, the index-number of the output
-operand among the output operands specified, a vector of input operand
-RTX's, and a vector of input-operand modes and constraints. The mode
-M1 is the mode of the sum `x+y'; M2 is that of `*z'.
-
- When an `asm' statement has multiple output values, its insn has
-several such `set' RTX's inside of a `parallel'. Each `set' contains
-an `asm_operands'; all of these share the same assembler template and
-vectors, but each contains the constraint for the respective output
-operand. They are also distinguished by the output-operand index
-number, which is 0, 1, ... for successive output operands.
-
-
-File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL
-
-10.18 Variable Location Debug Information in RTL
-================================================
-
-Variable tracking relies on `MEM_EXPR' and `REG_EXPR' annotations to
-determine what user variables memory and register references refer to.
-
- Variable tracking at assignments uses these notes only when they refer
-to variables that live at fixed locations (e.g., addressable variables,
-global non-automatic variables). For variables whose location may
-vary, it relies on the following types of notes.
-
-`(var_location:MODE VAR EXP STAT)'
- Binds variable `var', a tree, to value EXP, an RTL expression. It
- appears only in `NOTE_INSN_VAR_LOCATION' and `DEBUG_INSN's, with
- slightly different meanings. MODE, if present, represents the
- mode of EXP, which is useful if it is a modeless expression. STAT
- is only meaningful in notes, indicating whether the variable is
- known to be initialized or uninitialized.
-
-`(debug_expr:MODE DECL)'
- Stands for the value bound to the `DEBUG_EXPR_DECL' DECL, that
- points back to it, within value expressions in `VAR_LOCATION'
- nodes.
-
-
-
-File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL
-
-10.19 Insns
-===========
-
-The RTL representation of the code for a function is a doubly-linked
-chain of objects called "insns". Insns are expressions with special
-codes that are used for no other purpose. Some insns are actual
-instructions; others represent dispatch tables for `switch' statements;
-others represent labels to jump to or various sorts of declarative
-information.
-
- In addition to its own specific data, each insn must have a unique
-id-number that distinguishes it from all other insns in the current
-function (after delayed branch scheduling, copies of an insn with the
-same id-number may be present in multiple places in a function, but
-these copies will always be identical and will only appear inside a
-`sequence'), and chain pointers to the preceding and following insns.
-These three fields occupy the same position in every insn, independent
-of the expression code of the insn. They could be accessed with `XEXP'
-and `XINT', but instead three special macros are always used:
-
-`INSN_UID (I)'
- Accesses the unique id of insn I.
-
-`PREV_INSN (I)'
- Accesses the chain pointer to the insn preceding I. If I is the
- first insn, this is a null pointer.
-
-`NEXT_INSN (I)'
- Accesses the chain pointer to the insn following I. If I is the
- last insn, this is a null pointer.
-
- The first insn in the chain is obtained by calling `get_insns'; the
-last insn is the result of calling `get_last_insn'. Within the chain
-delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must
-always correspond: if INSN is not the first insn,
-
- NEXT_INSN (PREV_INSN (INSN)) == INSN
-
-is always true and if INSN is not the last insn,
-
- PREV_INSN (NEXT_INSN (INSN)) == INSN
-
-is always true.
-
- After delay slot scheduling, some of the insns in the chain might be
-`sequence' expressions, which contain a vector of insns. The value of
-`NEXT_INSN' in all but the last of these insns is the next insn in the
-vector; the value of `NEXT_INSN' of the last insn in the vector is the
-same as the value of `NEXT_INSN' for the `sequence' in which it is
-contained. Similar rules apply for `PREV_INSN'.
-
- This means that the above invariants are not necessarily true for insns
-inside `sequence' expressions. Specifically, if INSN is the first insn
-in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn containing
-the `sequence' expression, as is the value of `PREV_INSN (NEXT_INSN
-(INSN))' if INSN is the last insn in the `sequence' expression. You
-can use these expressions to find the containing `sequence' expression.
-
- Every insn has one of the following expression codes:
-
-`insn'
- The expression code `insn' is used for instructions that do not
- jump and do not do function calls. `sequence' expressions are
- always contained in insns with code `insn' even if one of those
- insns should jump or do function calls.
-
- Insns with code `insn' have four additional fields beyond the three
- mandatory ones listed above. These four are described in a table
- below.
-
-`jump_insn'
- The expression code `jump_insn' is used for instructions that may
- jump (or, more generally, may contain `label_ref' expressions to
- which `pc' can be set in that instruction). If there is an
- instruction to return from the current function, it is recorded as
- a `jump_insn'.
-
- `jump_insn' insns have the same extra fields as `insn' insns,
- accessed in the same way and in addition contain a field
- `JUMP_LABEL' which is defined once jump optimization has completed.
-
- For simple conditional and unconditional jumps, this field contains
- the `code_label' to which this insn will (possibly conditionally)
- branch. In a more complex jump, `JUMP_LABEL' records one of the
- labels that the insn refers to; other jump target labels are
- recorded as `REG_LABEL_TARGET' notes. The exception is `addr_vec'
- and `addr_diff_vec', where `JUMP_LABEL' is `NULL_RTX' and the only
- way to find the labels is to scan the entire body of the insn.
-
- Return insns count as jumps, but since they do not refer to any
- labels, their `JUMP_LABEL' is `NULL_RTX'.
-
-`call_insn'
- The expression code `call_insn' is used for instructions that may
- do function calls. It is important to distinguish these
- instructions because they imply that certain registers and memory
- locations may be altered unpredictably.
-
- `call_insn' insns have the same extra fields as `insn' insns,
- accessed in the same way and in addition contain a field
- `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of
- `expr_list' expressions) containing `use' and `clobber'
- expressions that denote hard registers and `MEM's used or
- clobbered by the called function.
-
- A `MEM' generally points to a stack slots in which arguments passed
- to the libcall by reference (*note TARGET_PASS_BY_REFERENCE:
- Register Arguments.) are stored. If the argument is caller-copied
- (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot
- will be mentioned in `CLOBBER' and `USE' entries; if it's
- callee-copied, only a `USE' will appear, and the `MEM' may point
- to addresses that are not stack slots.
-
- `CLOBBER'ed registers in this list augment registers specified in
- `CALL_USED_REGISTERS' (*note Register Basics::).
-
-`code_label'
- A `code_label' insn represents a label that a jump insn can jump
- to. It contains two special fields of data in addition to the
- three standard ones. `CODE_LABEL_NUMBER' is used to hold the
- "label number", a number that identifies this label uniquely among
- all the labels in the compilation (not just in the current
- function). Ultimately, the label is represented in the assembler
- output as an assembler label, usually of the form `LN' where N is
- the label number.
-
- When a `code_label' appears in an RTL expression, it normally
- appears within a `label_ref' which represents the address of the
- label, as a number.
-
- Besides as a `code_label', a label can also be represented as a
- `note' of type `NOTE_INSN_DELETED_LABEL'.
-
- The field `LABEL_NUSES' is only defined once the jump optimization
- phase is completed. It contains the number of times this label is
- referenced in the current function.
-
- The field `LABEL_KIND' differentiates four different types of
- labels: `LABEL_NORMAL', `LABEL_STATIC_ENTRY',
- `LABEL_GLOBAL_ENTRY', and `LABEL_WEAK_ENTRY'. The only labels
- that do not have type `LABEL_NORMAL' are "alternate entry points"
- to the current function. These may be static (visible only in the
- containing translation unit), global (exposed to all translation
- units), or weak (global, but can be overridden by another symbol
- with the same name).
-
- Much of the compiler treats all four kinds of label identically.
- Some of it needs to know whether or not a label is an alternate
- entry point; for this purpose, the macro `LABEL_ALT_ENTRY_P' is
- provided. It is equivalent to testing whether `LABEL_KIND (label)
- == LABEL_NORMAL'. The only place that cares about the distinction
- between static, global, and weak alternate entry points, besides
- the front-end code that creates them, is the function
- `output_alternate_entry_point', in `final.c'.
-
- To set the kind of a label, use the `SET_LABEL_KIND' macro.
-
-`barrier'
- Barriers are placed in the instruction stream when control cannot
- flow past them. They are placed after unconditional jump
- instructions to indicate that the jumps are unconditional and
- after calls to `volatile' functions, which do not return (e.g.,
- `exit'). They contain no information beyond the three standard
- fields.
-
-`note'
- `note' insns are used to represent additional debugging and
- declarative information. They contain two nonstandard fields, an
- integer which is accessed with the macro `NOTE_LINE_NUMBER' and a
- string accessed with `NOTE_SOURCE_FILE'.
-
- If `NOTE_LINE_NUMBER' is positive, the note represents the
- position of a source line and `NOTE_SOURCE_FILE' is the source
- file name that the line came from. These notes control generation
- of line number data in the assembler output.
-
- Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a
- code with one of the following values (and `NOTE_SOURCE_FILE' must
- contain a null pointer):
-
- `NOTE_INSN_DELETED'
- Such a note is completely ignorable. Some passes of the
- compiler delete insns by altering them into notes of this
- kind.
-
- `NOTE_INSN_DELETED_LABEL'
- This marks what used to be a `code_label', but was not used
- for other purposes than taking its address and was
- transformed to mark that no code jumps to it.
-
- `NOTE_INSN_BLOCK_BEG'
- `NOTE_INSN_BLOCK_END'
- These types of notes indicate the position of the beginning
- and end of a level of scoping of variable names. They
- control the output of debugging information.
-
- `NOTE_INSN_EH_REGION_BEG'
- `NOTE_INSN_EH_REGION_END'
- These types of notes indicate the position of the beginning
- and end of a level of scoping for exception handling.
- `NOTE_BLOCK_NUMBER' identifies which `CODE_LABEL' or `note'
- of type `NOTE_INSN_DELETED_LABEL' is associated with the
- given region.
-
- `NOTE_INSN_LOOP_BEG'
- `NOTE_INSN_LOOP_END'
- These types of notes indicate the position of the beginning
- and end of a `while' or `for' loop. They enable the loop
- optimizer to find loops quickly.
-
- `NOTE_INSN_LOOP_CONT'
- Appears at the place in a loop that `continue' statements
- jump to.
-
- `NOTE_INSN_LOOP_VTOP'
- This note indicates the place in a loop where the exit test
- begins for those loops in which the exit test has been
- duplicated. This position becomes another virtual start of
- the loop when considering loop invariants.
-
- `NOTE_INSN_FUNCTION_BEG'
- Appears at the start of the function body, after the function
- prologue.
-
- `NOTE_INSN_VAR_LOCATION'
- This note is used to generate variable location debugging
- information. It indicates that the user variable in its
- `VAR_LOCATION' operand is at the location given in the RTL
- expression, or holds a value that can be computed by
- evaluating the RTL expression from that static point in the
- program up to the next such note for the same user variable.
-
-
- These codes are printed symbolically when they appear in debugging
- dumps.
-
-`debug_insn'
- The expression code `debug_insn' is used for pseudo-instructions
- that hold debugging information for variable tracking at
- assignments (see `-fvar-tracking-assignments' option). They are
- the RTL representation of `GIMPLE_DEBUG' statements (*note
- `GIMPLE_DEBUG'::), with a `VAR_LOCATION' operand that binds a user
- variable tree to an RTL representation of the `value' in the
- corresponding statement. A `DEBUG_EXPR' in it stands for the
- value bound to the corresponding `DEBUG_EXPR_DECL'.
-
- Throughout optimization passes, binding information is kept in
- pseudo-instruction form, so that, unlike notes, it gets the same
- treatment and adjustments that regular instructions would. It is
- the variable tracking pass that turns these pseudo-instructions
- into var location notes, analyzing control flow, value
- equivalences and changes to registers and memory referenced in
- value expressions, propagating the values of debug temporaries and
- determining expressions that can be used to compute the value of
- each user variable at as many points (ranges, actually) in the
- program as possible.
-
- Unlike `NOTE_INSN_VAR_LOCATION', the value expression in an
- `INSN_VAR_LOCATION' denotes a value at that specific point in the
- program, rather than an expression that can be evaluated at any
- later point before an overriding `VAR_LOCATION' is encountered.
- E.g., if a user variable is bound to a `REG' and then a subsequent
- insn modifies the `REG', the note location would keep mapping the
- user variable to the register across the insn, whereas the insn
- location would keep the variable bound to the value, so that the
- variable tracking pass would emit another location note for the
- variable at the point in which the register is modified.
-
-
- The machine mode of an insn is normally `VOIDmode', but some phases
-use the mode for various purposes.
-
- The common subexpression elimination pass sets the mode of an insn to
-`QImode' when it is the first insn in a block that has already been
-processed.
-
- The second Haifa scheduling pass, for targets that can multiple issue,
-sets the mode of an insn to `TImode' when it is believed that the
-instruction begins an issue group. That is, when the instruction
-cannot issue simultaneously with the previous. This may be relied on
-by later passes, in particular machine-dependent reorg.
-
- Here is a table of the extra fields of `insn', `jump_insn' and
-`call_insn' insns:
-
-`PATTERN (I)'
- An expression for the side effect performed by this insn. This
- must be one of the following codes: `set', `call', `use',
- `clobber', `return', `asm_input', `asm_output', `addr_vec',
- `addr_diff_vec', `trap_if', `unspec', `unspec_volatile',
- `parallel', `cond_exec', or `sequence'. If it is a `parallel',
- each element of the `parallel' must be one these codes, except that
- `parallel' expressions cannot be nested and `addr_vec' and
- `addr_diff_vec' are not permitted inside a `parallel' expression.
-
-`INSN_CODE (I)'
- An integer that says which pattern in the machine description
- matches this insn, or -1 if the matching has not yet been
- attempted.
-
- Such matching is never attempted and this field remains -1 on an
- insn whose pattern consists of a single `use', `clobber',
- `asm_input', `addr_vec' or `addr_diff_vec' expression.
-
- Matching is also never attempted on insns that result from an `asm'
- statement. These contain at least one `asm_operands' expression.
- The function `asm_noperands' returns a non-negative value for such
- insns.
-
- In the debugging output, this field is printed as a number
- followed by a symbolic representation that locates the pattern in
- the `md' file as some small positive or negative offset from a
- named pattern.
-
-`LOG_LINKS (I)'
- A list (chain of `insn_list' expressions) giving information about
- dependencies between instructions within a basic block. Neither a
- jump nor a label may come between the related insns. These are
- only used by the schedulers and by combine. This is a deprecated
- data structure. Def-use and use-def chains are now preferred.
-
-`REG_NOTES (I)'
- A list (chain of `expr_list' and `insn_list' expressions) giving
- miscellaneous information about the insn. It is often information
- pertaining to the registers used in this insn.
-
- The `LOG_LINKS' field of an insn is a chain of `insn_list'
-expressions. Each of these has two operands: the first is an insn, and
-the second is another `insn_list' expression (the next one in the
-chain). The last `insn_list' in the chain has a null pointer as second
-operand. The significant thing about the chain is which insns appear
-in it (as first operands of `insn_list' expressions). Their order is
-not significant.
-
- This list is originally set up by the flow analysis pass; it is a null
-pointer until then. Flow only adds links for those data dependencies
-which can be used for instruction combination. For each insn, the flow
-analysis pass adds a link to insns which store into registers values
-that are used for the first time in this insn.
-
- The `REG_NOTES' field of an insn is a chain similar to the `LOG_LINKS'
-field but it includes `expr_list' expressions in addition to
-`insn_list' expressions. There are several kinds of register notes,
-which are distinguished by the machine mode, which in a register note
-is really understood as being an `enum reg_note'. The first operand OP
-of the note is data whose meaning depends on the kind of note.
-
- The macro `REG_NOTE_KIND (X)' returns the kind of register note. Its
-counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the
-register note type of X to be NEWKIND.
-
- Register notes are of three classes: They may say something about an
-input to an insn, they may say something about an output of an insn, or
-they may create a linkage between two insns. There are also a set of
-values that are only used in `LOG_LINKS'.
-
- These register notes annotate inputs to an insn:
-
-`REG_DEAD'
- The value in OP dies in this insn; that is to say, altering the
- value immediately after this insn would not affect the future
- behavior of the program.
-
- It does not follow that the register OP has no useful value after
- this insn since OP is not necessarily modified by this insn.
- Rather, no subsequent instruction uses the contents of OP.
-
-`REG_UNUSED'
- The register OP being set by this insn will not be used in a
- subsequent insn. This differs from a `REG_DEAD' note, which
- indicates that the value in an input will not be used subsequently.
- These two notes are independent; both may be present for the same
- register.
-
-`REG_INC'
- The register OP is incremented (or decremented; at this level
- there is no distinction) by an embedded side effect inside this
- insn. This means it appears in a `post_inc', `pre_inc',
- `post_dec' or `pre_dec' expression.
-
-`REG_NONNEG'
- The register OP is known to have a nonnegative value when this
- insn is reached. This is used so that decrement and branch until
- zero instructions, such as the m68k dbra, can be matched.
-
- The `REG_NONNEG' note is added to insns only if the machine
- description has a `decrement_and_branch_until_zero' pattern.
-
-`REG_LABEL_OPERAND'
- This insn uses OP, a `code_label' or a `note' of type
- `NOTE_INSN_DELETED_LABEL', but is not a `jump_insn', or it is a
- `jump_insn' that refers to the operand as an ordinary operand.
- The label may still eventually be a jump target, but if so in an
- indirect jump in a subsequent insn. The presence of this note
- allows jump optimization to be aware that OP is, in fact, being
- used, and flow optimization to build an accurate flow graph.
-
-`REG_LABEL_TARGET'
- This insn is a `jump_insn' but not an `addr_vec' or
- `addr_diff_vec'. It uses OP, a `code_label' as a direct or
- indirect jump target. Its purpose is similar to that of
- `REG_LABEL_OPERAND'. This note is only present if the insn has
- multiple targets; the last label in the insn (in the highest
- numbered insn-field) goes into the `JUMP_LABEL' field and does not
- have a `REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns.
-
-`REG_CROSSING_JUMP'
- This insn is a branching instruction (either an unconditional jump
- or an indirect jump) which crosses between hot and cold sections,
- which could potentially be very far apart in the executable. The
- presence of this note indicates to other optimizations that this
- branching instruction should not be "collapsed" into a simpler
- branching construct. It is used when the optimization to
- partition basic blocks into hot and cold sections is turned on.
-
-`REG_SETJMP'
- Appears attached to each `CALL_INSN' to `setjmp' or a related
- function.
-
- The following notes describe attributes of outputs of an insn:
-
-`REG_EQUIV'
-`REG_EQUAL'
- This note is only valid on an insn that sets only one register and
- indicates that that register will be equal to OP at run time; the
- scope of this equivalence differs between the two types of notes.
- The value which the insn explicitly copies into the register may
- look different from OP, but they will be equal at run time. If the
- output of the single `set' is a `strict_low_part' expression, the
- note refers to the register that is contained in `SUBREG_REG' of
- the `subreg' expression.
-
- For `REG_EQUIV', the register is equivalent to OP throughout the
- entire function, and could validly be replaced in all its
- occurrences by OP. ("Validly" here refers to the data flow of the
- program; simple replacement may make some insns invalid.) For
- example, when a constant is loaded into a register that is never
- assigned any other value, this kind of note is used.
-
- When a parameter is copied into a pseudo-register at entry to a
- function, a note of this kind records that the register is
- equivalent to the stack slot where the parameter was passed.
- Although in this case the register may be set by other insns, it
- is still valid to replace the register by the stack slot
- throughout the function.
-
- A `REG_EQUIV' note is also used on an instruction which copies a
- register parameter into a pseudo-register at entry to a function,
- if there is a stack slot where that parameter could be stored.
- Although other insns may set the pseudo-register, it is valid for
- the compiler to replace the pseudo-register by stack slot
- throughout the function, provided the compiler ensures that the
- stack slot is properly initialized by making the replacement in
- the initial copy instruction as well. This is used on machines
- for which the calling convention allocates stack space for
- register parameters. See `REG_PARM_STACK_SPACE' in *note Stack
- Arguments::.
-
- In the case of `REG_EQUAL', the register that is set by this insn
- will be equal to OP at run time at the end of this insn but not
- necessarily elsewhere in the function. In this case, OP is
- typically an arithmetic expression. For example, when a sequence
- of insns such as a library call is used to perform an arithmetic
- operation, this kind of note is attached to the insn that produces
- or copies the final value.
-
- These two notes are used in different ways by the compiler passes.
- `REG_EQUAL' is used by passes prior to register allocation (such as
- common subexpression elimination and loop optimization) to tell
- them how to think of that value. `REG_EQUIV' notes are used by
- register allocation to indicate that there is an available
- substitute expression (either a constant or a `mem' expression for
- the location of a parameter on the stack) that may be used in
- place of a register if insufficient registers are available.
-
- Except for stack homes for parameters, which are indicated by a
- `REG_EQUIV' note and are not useful to the early optimization
- passes and pseudo registers that are equivalent to a memory
- location throughout their entire life, which is not detected until
- later in the compilation, all equivalences are initially indicated
- by an attached `REG_EQUAL' note. In the early stages of register
- allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note
- if OP is a constant and the insn represents the only set of its
- destination register.
-
- Thus, compiler passes prior to register allocation need only check
- for `REG_EQUAL' notes and passes subsequent to register allocation
- need only check for `REG_EQUIV' notes.
-
- These notes describe linkages between insns. They occur in pairs: one
-insn has one of a pair of notes that points to a second insn, which has
-the inverse note pointing back to the first insn.
-
-`REG_CC_SETTER'
-`REG_CC_USER'
- On machines that use `cc0', the insns which set and use `cc0' set
- and use `cc0' are adjacent. However, when branch delay slot
- filling is done, this may no longer be true. In this case a
- `REG_CC_USER' note will be placed on the insn setting `cc0' to
- point to the insn using `cc0' and a `REG_CC_SETTER' note will be
- placed on the insn using `cc0' to point to the insn setting `cc0'.
-
- These values are only used in the `LOG_LINKS' field, and indicate the
-type of dependency that each link represents. Links which indicate a
-data dependence (a read after write dependence) do not use any code,
-they simply have mode `VOIDmode', and are printed without any
-descriptive text.
-
-`REG_DEP_TRUE'
- This indicates a true dependence (a read after write dependence).
-
-`REG_DEP_OUTPUT'
- This indicates an output dependence (a write after write
- dependence).
-
-`REG_DEP_ANTI'
- This indicates an anti dependence (a write after read dependence).
-
-
- These notes describe information gathered from gcov profile data. They
-are stored in the `REG_NOTES' field of an insn as an `expr_list'.
-
-`REG_BR_PROB'
- This is used to specify the ratio of branches to non-branches of a
- branch insn according to the profile data. The value is stored as
- a value between 0 and REG_BR_PROB_BASE; larger values indicate a
- higher probability that the branch will be taken.
-
-`REG_BR_PRED'
- These notes are found in JUMP insns after delayed branch scheduling
- has taken place. They indicate both the direction and the
- likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_*
- values.
-
-`REG_FRAME_RELATED_EXPR'
- This is used on an RTX_FRAME_RELATED_P insn wherein the attached
- expression is used in place of the actual insn pattern. This is
- done in cases where the pattern is either complex or misleading.
-
- For convenience, the machine mode in an `insn_list' or `expr_list' is
-printed using these symbolic codes in debugging dumps.
-
- The only difference between the expression codes `insn_list' and
-`expr_list' is that the first operand of an `insn_list' is assumed to
-be an insn and is printed in debugging dumps as the insn's unique id;
-the first operand of an `expr_list' is printed in the ordinary way as
-an expression.
-
-
-File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL
-
-10.20 RTL Representation of Function-Call Insns
-===============================================
-
-Insns that call subroutines have the RTL expression code `call_insn'.
-These insns must satisfy special rules, and their bodies must use a
-special RTL expression code, `call'.
-
- A `call' expression has two operands, as follows:
-
- (call (mem:FM ADDR) NBYTES)
-
-Here NBYTES is an operand that represents the number of bytes of
-argument data being passed to the subroutine, FM is a machine mode
-(which must equal as the definition of the `FUNCTION_MODE' macro in the
-machine description) and ADDR represents the address of the subroutine.
-
- For a subroutine that returns no value, the `call' expression as shown
-above is the entire body of the insn, except that the insn might also
-contain `use' or `clobber' expressions.
-
- For a subroutine that returns a value whose mode is not `BLKmode', the
-value is returned in a hard register. If this register's number is R,
-then the body of the call insn looks like this:
-
- (set (reg:M R)
- (call (mem:FM ADDR) NBYTES))
-
-This RTL expression makes it clear (to the optimizer passes) that the
-appropriate register receives a useful value in this insn.
-
- When a subroutine returns a `BLKmode' value, it is handled by passing
-to the subroutine the address of a place to store the value. So the
-call insn itself does not "return" any value, and it has the same RTL
-form as a call that returns nothing.
-
- On some machines, the call instruction itself clobbers some register,
-for example to contain the return address. `call_insn' insns on these
-machines should have a body which is a `parallel' that contains both
-the `call' expression and `clobber' expressions that indicate which
-registers are destroyed. Similarly, if the call instruction requires
-some register other than the stack pointer that is not explicitly
-mentioned in its RTL, a `use' subexpression should mention that
-register.
-
- Functions that are called are assumed to modify all registers listed in
-the configuration macro `CALL_USED_REGISTERS' (*note Register Basics::)
-and, with the exception of `const' functions and library calls, to
-modify all of memory.
-
- Insns containing just `use' expressions directly precede the
-`call_insn' insn to indicate which registers contain inputs to the
-function. Similarly, if registers other than those in
-`CALL_USED_REGISTERS' are clobbered by the called function, insns
-containing a single `clobber' follow immediately after the call to
-indicate which registers.
-
-
-File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL
-
-10.21 Structure Sharing Assumptions
-===================================
-
-The compiler assumes that certain kinds of RTL expressions are unique;
-there do not exist two distinct objects representing the same value.
-In other cases, it makes an opposite assumption: that no RTL expression
-object of a certain kind appears in more than one place in the
-containing structure.
-
- These assumptions refer to a single function; except for the RTL
-objects that describe global variables and external functions, and a
-few standard objects such as small integer constants, no RTL objects
-are common to two functions.
-
- * Each pseudo-register has only a single `reg' object to represent
- it, and therefore only a single machine mode.
-
- * For any symbolic label, there is only one `symbol_ref' object
- referring to it.
-
- * All `const_int' expressions with equal values are shared.
-
- * There is only one `pc' expression.
-
- * There is only one `cc0' expression.
-
- * There is only one `const_double' expression with value 0 for each
- floating point mode. Likewise for values 1 and 2.
-
- * There is only one `const_vector' expression with value 0 for each
- vector mode, be it an integer or a double constant vector.
-
- * No `label_ref' or `scratch' appears in more than one place in the
- RTL structure; in other words, it is safe to do a tree-walk of all
- the insns in the function and assume that each time a `label_ref'
- or `scratch' is seen it is distinct from all others that are seen.
-
- * Only one `mem' object is normally created for each static variable
- or stack slot, so these objects are frequently shared in all the
- places they appear. However, separate but equal objects for these
- variables are occasionally made.
-
- * When a single `asm' statement has multiple output operands, a
- distinct `asm_operands' expression is made for each output operand.
- However, these all share the vector which contains the sequence of
- input operands. This sharing is used later on to test whether two
- `asm_operands' expressions come from the same statement, so all
- optimizations must carefully preserve the sharing if they copy the
- vector at all.
-
- * No RTL object appears in more than one place in the RTL structure
- except as described above. Many passes of the compiler rely on
- this by assuming that they can modify RTL objects in place without
- unwanted side-effects on other insns.
-
- * During initial RTL generation, shared structure is freely
- introduced. After all the RTL for a function has been generated,
- all shared structure is copied by `unshare_all_rtl' in
- `emit-rtl.c', after which the above rules are guaranteed to be
- followed.
-
- * During the combiner pass, shared structure within an insn can exist
- temporarily. However, the shared structure is copied before the
- combiner is finished with the insn. This is done by calling
- `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'.
-
-
-File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL
-
-10.22 Reading RTL
-=================
-
-To read an RTL object from a file, call `read_rtx'. It takes one
-argument, a stdio stream, and returns a single RTL object. This routine
-is defined in `read-rtl.c'. It is not available in the compiler
-itself, only the various programs that generate the compiler back end
-from the machine description.
-
- People frequently have the idea of using RTL stored as text in a file
-as an interface between a language front end and the bulk of GCC. This
-idea is not feasible.
-
- GCC was designed to use RTL internally only. Correct RTL for a given
-program is very dependent on the particular target machine. And the RTL
-does not contain all the information about the program.
-
- The proper way to interface GCC to a new language front end is with
-the "tree" data structure, described in the files `tree.h' and
-`tree.def'. The documentation for this structure (*note GENERIC::) is
-incomplete.
-
-
-File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: Passes, Up: Top
-
-11 GENERIC
-**********
-
-The purpose of GENERIC is simply to provide a language-independent way
-of representing an entire function in trees. To this end, it was
-necessary to add a few new tree codes to the back end, but most
-everything was already there. If you can express it with the codes in
-`gcc/tree.def', it's GENERIC.
-
- Early on, there was a great deal of debate about how to think about
-statements in a tree IL. In GENERIC, a statement is defined as any
-expression whose value, if any, is ignored. A statement will always
-have `TREE_SIDE_EFFECTS' set (or it will be discarded), but a
-non-statement expression may also have side effects. A `CALL_EXPR',
-for instance.
-
- It would be possible for some local optimizations to work on the
-GENERIC form of a function; indeed, the adapted tree inliner works fine
-on GENERIC, but the current compiler performs inlining after lowering
-to GIMPLE (a restricted form described in the next section). Indeed,
-currently the frontends perform this lowering before handing off to
-`tree_rest_of_compilation', but this seems inelegant.
-
-* Menu:
-
-* Deficiencies:: Topics net yet covered in this document.
-* Tree overview:: All about `tree's.
-* Types:: Fundamental and aggregate types.
-* Declarations:: Type declarations and variables.
-* Attributes:: Declaration and type attributes.
-* Expressions: Expression trees. Operating on data.
-* Statements:: Control flow and related trees.
-* Functions:: Function bodies, linkage, and other aspects.
-* Language-dependent trees:: Topics and trees specific to language front ends.
-* C and C++ Trees:: Trees specific to C and C++.
-* Java Trees:: Trees specific to Java.
-
-
-File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC
-
-11.1 Deficiencies
-=================
-
-There are many places in which this document is incomplet and incorrekt.
-It is, as of yet, only _preliminary_ documentation.
-
-
-File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC
-
-11.2 Overview
-=============
-
-The central data structure used by the internal representation is the
-`tree'. These nodes, while all of the C type `tree', are of many
-varieties. A `tree' is a pointer type, but the object to which it
-points may be of a variety of types. From this point forward, we will
-refer to trees in ordinary type, rather than in `this font', except
-when talking about the actual C type `tree'.
-
- You can tell what kind of node a particular tree is by using the
-`TREE_CODE' macro. Many, many macros take trees as input and return
-trees as output. However, most macros require a certain kind of tree
-node as input. In other words, there is a type-system for trees, but
-it is not reflected in the C type-system.
-
- For safety, it is useful to configure GCC with `--enable-checking'.
-Although this results in a significant performance penalty (since all
-tree types are checked at run-time), and is therefore inappropriate in a
-release version, it is extremely helpful during the development process.
-
- Many macros behave as predicates. Many, although not all, of these
-predicates end in `_P'. Do not rely on the result type of these macros
-being of any particular type. You may, however, rely on the fact that
-the type can be compared to `0', so that statements like
- if (TEST_P (t) && !TEST_P (y))
- x = 1;
- and
- int i = (TEST_P (t) != 0);
- are legal. Macros that return `int' values now may be changed to
-return `tree' values, or other pointers in the future. Even those that
-continue to return `int' may return multiple nonzero codes where
-previously they returned only zero and one. Therefore, you should not
-write code like
- if (TEST_P (t) == 1)
- as this code is not guaranteed to work correctly in the future.
-
- You should not take the address of values returned by the macros or
-functions described here. In particular, no guarantee is given that the
-values are lvalues.
-
- In general, the names of macros are all in uppercase, while the names
-of functions are entirely in lowercase. There are rare exceptions to
-this rule. You should assume that any macro or function whose name is
-made up entirely of uppercase letters may evaluate its arguments more
-than once. You may assume that a macro or function whose name is made
-up entirely of lowercase letters will evaluate its arguments only once.
-
- The `error_mark_node' is a special tree. Its tree code is
-`ERROR_MARK', but since there is only ever one node with that code, the
-usual practice is to compare the tree against `error_mark_node'. (This
-test is just a test for pointer equality.) If an error has occurred
-during front-end processing the flag `errorcount' will be set. If the
-front end has encountered code it cannot handle, it will issue a
-message to the user and set `sorrycount'. When these flags are set,
-any macro or function which normally returns a tree of a particular
-kind may instead return the `error_mark_node'. Thus, if you intend to
-do any processing of erroneous code, you must be prepared to deal with
-the `error_mark_node'.
-
- Occasionally, a particular tree slot (like an operand to an expression,
-or a particular field in a declaration) will be referred to as
-"reserved for the back end". These slots are used to store RTL when
-the tree is converted to RTL for use by the GCC back end. However, if
-that process is not taking place (e.g., if the front end is being hooked
-up to an intelligent editor), then those slots may be used by the back
-end presently in use.
-
- If you encounter situations that do not match this documentation, such
-as tree nodes of types not mentioned here, or macros documented to
-return entities of a particular kind that instead return entities of
-some different kind, you have found a bug, either in the front end or in
-the documentation. Please report these bugs as you would any other bug.
-
-* Menu:
-
-* Macros and Functions::Macros and functions that can be used with all trees.
-* Identifiers:: The names of things.
-* Containers:: Lists and vectors.
-
-
-File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview
-
-11.2.1 Trees
-------------
-
-All GENERIC trees have two fields in common. First, `TREE_CHAIN' is a
-pointer that can be used as a singly-linked list to other trees. The
-other is `TREE_TYPE'. Many trees store the type of an expression or
-declaration in this field.
-
- These are some other functions for handling trees:
-
-`tree_size'
- Return the number of bytes a tree takes.
-
-`build0'
-`build1'
-`build2'
-`build3'
-`build4'
-`build5'
-`build6'
- These functions build a tree and supply values to put in each
- parameter. The basic signature is `code, type, [operands]'.
- `code' is the `TREE_CODE', and `type' is a tree representing the
- `TREE_TYPE'. These are followed by the operands, each of which is
- also a tree.
-
-
-
-File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview
-
-11.2.2 Identifiers
-------------------
-
-An `IDENTIFIER_NODE' represents a slightly more general concept that
-the standard C or C++ concept of identifier. In particular, an
-`IDENTIFIER_NODE' may contain a `$', or other extraordinary characters.
-
- There are never two distinct `IDENTIFIER_NODE's representing the same
-identifier. Therefore, you may use pointer equality to compare
-`IDENTIFIER_NODE's, rather than using a routine like `strcmp'. Use
-`get_identifier' to obtain the unique `IDENTIFIER_NODE' for a supplied
-string.
-
- You can use the following macros to access identifiers:
-`IDENTIFIER_POINTER'
- The string represented by the identifier, represented as a
- `char*'. This string is always `NUL'-terminated, and contains no
- embedded `NUL' characters.
-
-`IDENTIFIER_LENGTH'
- The length of the string returned by `IDENTIFIER_POINTER', not
- including the trailing `NUL'. This value of `IDENTIFIER_LENGTH
- (x)' is always the same as `strlen (IDENTIFIER_POINTER (x))'.
-
-`IDENTIFIER_OPNAME_P'
- This predicate holds if the identifier represents the name of an
- overloaded operator. In this case, you should not depend on the
- contents of either the `IDENTIFIER_POINTER' or the
- `IDENTIFIER_LENGTH'.
-
-`IDENTIFIER_TYPENAME_P'
- This predicate holds if the identifier represents the name of a
- user-defined conversion operator. In this case, the `TREE_TYPE' of
- the `IDENTIFIER_NODE' holds the type to which the conversion
- operator converts.
-
-
-
-File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview
-
-11.2.3 Containers
------------------
-
-Two common container data structures can be represented directly with
-tree nodes. A `TREE_LIST' is a singly linked list containing two trees
-per node. These are the `TREE_PURPOSE' and `TREE_VALUE' of each node.
-(Often, the `TREE_PURPOSE' contains some kind of tag, or additional
-information, while the `TREE_VALUE' contains the majority of the
-payload. In other cases, the `TREE_PURPOSE' is simply `NULL_TREE',
-while in still others both the `TREE_PURPOSE' and `TREE_VALUE' are of
-equal stature.) Given one `TREE_LIST' node, the next node is found by
-following the `TREE_CHAIN'. If the `TREE_CHAIN' is `NULL_TREE', then
-you have reached the end of the list.
-
- A `TREE_VEC' is a simple vector. The `TREE_VEC_LENGTH' is an integer
-(not a tree) giving the number of nodes in the vector. The nodes
-themselves are accessed using the `TREE_VEC_ELT' macro, which takes two
-arguments. The first is the `TREE_VEC' in question; the second is an
-integer indicating which element in the vector is desired. The
-elements are indexed from zero.
-
-
-File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC
-
-11.3 Types
-==========
-
-All types have corresponding tree nodes. However, you should not assume
-that there is exactly one tree node corresponding to each type. There
-are often multiple nodes corresponding to the same type.
-
- For the most part, different kinds of types have different tree codes.
-(For example, pointer types use a `POINTER_TYPE' code while arrays use
-an `ARRAY_TYPE' code.) However, pointers to member functions use the
-`RECORD_TYPE' code. Therefore, when writing a `switch' statement that
-depends on the code associated with a particular type, you should take
-care to handle pointers to member functions under the `RECORD_TYPE'
-case label.
-
- The following functions and macros deal with cv-qualification of types:
-`TYPE_MAIN_VARIANT'
- This macro returns the unqualified version of a type. It may be
- applied to an unqualified type, but it is not always the identity
- function in that case.
-
- A few other macros and functions are usable with all types:
-`TYPE_SIZE'
- The number of bits required to represent the type, represented as
- an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be
- `NULL_TREE'.
-
-`TYPE_ALIGN'
- The alignment of the type, in bits, represented as an `int'.
-
-`TYPE_NAME'
- This macro returns a declaration (in the form of a `TYPE_DECL') for
- the type. (Note this macro does _not_ return an
- `IDENTIFIER_NODE', as you might expect, given its name!) You can
- look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual
- name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type
- that is not a built-in type, the result of a typedef, or a named
- class type.
-
-`TYPE_CANONICAL'
- This macro returns the "canonical" type for the given type node.
- Canonical types are used to improve performance in the C++ and
- Objective-C++ front ends by allowing efficient comparison between
- two type nodes in `same_type_p': if the `TYPE_CANONICAL' values of
- the types are equal, the types are equivalent; otherwise, the types
- are not equivalent. The notion of equivalence for canonical types
- is the same as the notion of type equivalence in the language
- itself. For instance,
-
- When `TYPE_CANONICAL' is `NULL_TREE', there is no canonical type
- for the given type node. In this case, comparison between this
- type and any other type requires the compiler to perform a deep,
- "structural" comparison to see if the two type nodes have the same
- form and properties.
-
- The canonical type for a node is always the most fundamental type
- in the equivalence class of types. For instance, `int' is its own
- canonical type. A typedef `I' of `int' will have `int' as its
- canonical type. Similarly, `I*' and a typedef `IP' (defined to
- `I*') will has `int*' as their canonical type. When building a new
- type node, be sure to set `TYPE_CANONICAL' to the appropriate
- canonical type. If the new type is a compound type (built from
- other types), and any of those other types require structural
- equality, use `SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the
- new type also requires structural equality. Finally, if for some
- reason you cannot guarantee that `TYPE_CANONICAL' will point to
- the canonical type, use `SET_TYPE_STRUCTURAL_EQUALITY' to make
- sure that the new type-and any type constructed based on
- it-requires structural equality. If you suspect that the canonical
- type system is miscomparing types, pass `--param
- verify-canonical-types=1' to the compiler or configure with
- `--enable-checking' to force the compiler to verify its
- canonical-type comparisons against the structural comparisons; the
- compiler will then print any warnings if the canonical types
- miscompare.
-
-`TYPE_STRUCTURAL_EQUALITY_P'
- This predicate holds when the node requires structural equality
- checks, e.g., when `TYPE_CANONICAL' is `NULL_TREE'.
-
-`SET_TYPE_STRUCTURAL_EQUALITY'
- This macro states that the type node it is given requires
- structural equality checks, e.g., it sets `TYPE_CANONICAL' to
- `NULL_TREE'.
-
-`same_type_p'
- This predicate takes two types as input, and holds if they are the
- same type. For example, if one type is a `typedef' for the other,
- or both are `typedef's for the same type. This predicate also
- holds if the two trees given as input are simply copies of one
- another; i.e., there is no difference between them at the source
- level, but, for whatever reason, a duplicate has been made in the
- representation. You should never use `==' (pointer equality) to
- compare types; always use `same_type_p' instead.
-
- Detailed below are the various kinds of types, and the macros that can
-be used to access them. Although other kinds of types are used
-elsewhere in G++, the types described here are the only ones that you
-will encounter while examining the intermediate representation.
-
-`VOID_TYPE'
- Used to represent the `void' type.
-
-`INTEGER_TYPE'
- Used to represent the various integral types, including `char',
- `short', `int', `long', and `long long'. This code is not used
- for enumeration types, nor for the `bool' type. The
- `TYPE_PRECISION' is the number of bits used in the representation,
- represented as an `unsigned int'. (Note that in the general case
- this is not the same value as `TYPE_SIZE'; suppose that there were
- a 24-bit integer type, but that alignment requirements for the ABI
- required 32-bit alignment. Then, `TYPE_SIZE' would be an
- `INTEGER_CST' for 32, while `TYPE_PRECISION' would be 24.) The
- integer type is unsigned if `TYPE_UNSIGNED' holds; otherwise, it
- is signed.
-
- The `TYPE_MIN_VALUE' is an `INTEGER_CST' for the smallest integer
- that may be represented by this type. Similarly, the
- `TYPE_MAX_VALUE' is an `INTEGER_CST' for the largest integer that
- may be represented by this type.
-
-`REAL_TYPE'
- Used to represent the `float', `double', and `long double' types.
- The number of bits in the floating-point representation is given
- by `TYPE_PRECISION', as in the `INTEGER_TYPE' case.
-
-`FIXED_POINT_TYPE'
- Used to represent the `short _Fract', `_Fract', `long _Fract',
- `long long _Fract', `short _Accum', `_Accum', `long _Accum', and
- `long long _Accum' types. The number of bits in the fixed-point
- representation is given by `TYPE_PRECISION', as in the
- `INTEGER_TYPE' case. There may be padding bits, fractional bits
- and integral bits. The number of fractional bits is given by
- `TYPE_FBIT', and the number of integral bits is given by
- `TYPE_IBIT'. The fixed-point type is unsigned if `TYPE_UNSIGNED'
- holds; otherwise, it is signed. The fixed-point type is
- saturating if `TYPE_SATURATING' holds; otherwise, it is not
- saturating.
-
-`COMPLEX_TYPE'
- Used to represent GCC built-in `__complex__' data types. The
- `TREE_TYPE' is the type of the real and imaginary parts.
-
-`ENUMERAL_TYPE'
- Used to represent an enumeration type. The `TYPE_PRECISION' gives
- (as an `int'), the number of bits used to represent the type. If
- there are no negative enumeration constants, `TYPE_UNSIGNED' will
- hold. The minimum and maximum enumeration constants may be
- obtained with `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE', respectively;
- each of these macros returns an `INTEGER_CST'.
-
- The actual enumeration constants themselves may be obtained by
- looking at the `TYPE_VALUES'. This macro will return a
- `TREE_LIST', containing the constants. The `TREE_PURPOSE' of each
- node will be an `IDENTIFIER_NODE' giving the name of the constant;
- the `TREE_VALUE' will be an `INTEGER_CST' giving the value
- assigned to that constant. These constants will appear in the
- order in which they were declared. The `TREE_TYPE' of each of
- these constants will be the type of enumeration type itself.
-
-`BOOLEAN_TYPE'
- Used to represent the `bool' type.
-
-`POINTER_TYPE'
- Used to represent pointer types, and pointer to data member types.
- The `TREE_TYPE' gives the type to which this type points.
-
-`REFERENCE_TYPE'
- Used to represent reference types. The `TREE_TYPE' gives the type
- to which this type refers.
-
-`FUNCTION_TYPE'
- Used to represent the type of non-member functions and of static
- member functions. The `TREE_TYPE' gives the return type of the
- function. The `TYPE_ARG_TYPES' are a `TREE_LIST' of the argument
- types. The `TREE_VALUE' of each node in this list is the type of
- the corresponding argument; the `TREE_PURPOSE' is an expression
- for the default argument value, if any. If the last node in the
- list is `void_list_node' (a `TREE_LIST' node whose `TREE_VALUE' is
- the `void_type_node'), then functions of this type do not take
- variable arguments. Otherwise, they do take a variable number of
- arguments.
-
- Note that in C (but not in C++) a function declared like `void f()'
- is an unprototyped function taking a variable number of arguments;
- the `TYPE_ARG_TYPES' of such a function will be `NULL'.
-
-`METHOD_TYPE'
- Used to represent the type of a non-static member function. Like a
- `FUNCTION_TYPE', the return type is given by the `TREE_TYPE'. The
- type of `*this', i.e., the class of which functions of this type
- are a member, is given by the `TYPE_METHOD_BASETYPE'. The
- `TYPE_ARG_TYPES' is the parameter list, as for a `FUNCTION_TYPE',
- and includes the `this' argument.
-
-`ARRAY_TYPE'
- Used to represent array types. The `TREE_TYPE' gives the type of
- the elements in the array. If the array-bound is present in the
- type, the `TYPE_DOMAIN' is an `INTEGER_TYPE' whose
- `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE' will be the lower and upper
- bounds of the array, respectively. The `TYPE_MIN_VALUE' will
- always be an `INTEGER_CST' for zero, while the `TYPE_MAX_VALUE'
- will be one less than the number of elements in the array, i.e.,
- the highest value which may be used to index an element in the
- array.
-
-`RECORD_TYPE'
- Used to represent `struct' and `class' types, as well as pointers
- to member functions and similar constructs in other languages.
- `TYPE_FIELDS' contains the items contained in this type, each of
- which can be a `FIELD_DECL', `VAR_DECL', `CONST_DECL', or
- `TYPE_DECL'. You may not make any assumptions about the ordering
- of the fields in the type or whether one or more of them overlap.
-
-`UNION_TYPE'
- Used to represent `union' types. Similar to `RECORD_TYPE' except
- that all `FIELD_DECL' nodes in `TYPE_FIELD' start at bit position
- zero.
-
-`QUAL_UNION_TYPE'
- Used to represent part of a variant record in Ada. Similar to
- `UNION_TYPE' except that each `FIELD_DECL' has a `DECL_QUALIFIER'
- field, which contains a boolean expression that indicates whether
- the field is present in the object. The type will only have one
- field, so each field's `DECL_QUALIFIER' is only evaluated if none
- of the expressions in the previous fields in `TYPE_FIELDS' are
- nonzero. Normally these expressions will reference a field in the
- outer object using a `PLACEHOLDER_EXPR'.
-
-`LANG_TYPE'
- This node is used to represent a language-specific type. The front
- end must handle it.
-
-`OFFSET_TYPE'
- This node is used to represent a pointer-to-data member. For a
- data member `X::m' the `TYPE_OFFSET_BASETYPE' is `X' and the
- `TREE_TYPE' is the type of `m'.
-
-
- There are variables whose values represent some of the basic types.
-These include:
-`void_type_node'
- A node for `void'.
-
-`integer_type_node'
- A node for `int'.
-
-`unsigned_type_node.'
- A node for `unsigned int'.
-
-`char_type_node.'
- A node for `char'.
- It may sometimes be useful to compare one of these variables with a
-type in hand, using `same_type_p'.
-
-
-File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC
-
-11.4 Declarations
-=================
-
-This section covers the various kinds of declarations that appear in the
-internal representation, except for declarations of functions
-(represented by `FUNCTION_DECL' nodes), which are described in *note
-Functions::.
-
-* Menu:
-
-* Working with declarations:: Macros and functions that work on
-declarations.
-* Internal structure:: How declaration nodes are represented.
-
-
-File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations
-
-11.4.1 Working with declarations
---------------------------------
-
-Some macros can be used with any kind of declaration. These include:
-`DECL_NAME'
- This macro returns an `IDENTIFIER_NODE' giving the name of the
- entity.
-
-`TREE_TYPE'
- This macro returns the type of the entity declared.
-
-`EXPR_FILENAME'
- This macro returns the name of the file in which the entity was
- declared, as a `char*'. For an entity declared implicitly by the
- compiler (like `__builtin_memcpy'), this will be the string
- `"<internal>"'.
-
-`EXPR_LINENO'
- This macro returns the line number at which the entity was
- declared, as an `int'.
-
-`DECL_ARTIFICIAL'
- This predicate holds if the declaration was implicitly generated
- by the compiler. For example, this predicate will hold of an
- implicitly declared member function, or of the `TYPE_DECL'
- implicitly generated for a class type. Recall that in C++ code
- like:
- struct S {};
- is roughly equivalent to C code like:
- struct S {};
- typedef struct S S;
- The implicitly generated `typedef' declaration is represented by a
- `TYPE_DECL' for which `DECL_ARTIFICIAL' holds.
-
-
- The various kinds of declarations include:
-`LABEL_DECL'
- These nodes are used to represent labels in function bodies. For
- more information, see *note Functions::. These nodes only appear
- in block scopes.
-
-`CONST_DECL'
- These nodes are used to represent enumeration constants. The
- value of the constant is given by `DECL_INITIAL' which will be an
- `INTEGER_CST' with the same type as the `TREE_TYPE' of the
- `CONST_DECL', i.e., an `ENUMERAL_TYPE'.
-
-`RESULT_DECL'
- These nodes represent the value returned by a function. When a
- value is assigned to a `RESULT_DECL', that indicates that the
- value should be returned, via bitwise copy, by the function. You
- can use `DECL_SIZE' and `DECL_ALIGN' on a `RESULT_DECL', just as
- with a `VAR_DECL'.
-
-`TYPE_DECL'
- These nodes represent `typedef' declarations. The `TREE_TYPE' is
- the type declared to have the name given by `DECL_NAME'. In some
- cases, there is no associated name.
-
-`VAR_DECL'
- These nodes represent variables with namespace or block scope, as
- well as static data members. The `DECL_SIZE' and `DECL_ALIGN' are
- analogous to `TYPE_SIZE' and `TYPE_ALIGN'. For a declaration, you
- should always use the `DECL_SIZE' and `DECL_ALIGN' rather than the
- `TYPE_SIZE' and `TYPE_ALIGN' given by the `TREE_TYPE', since
- special attributes may have been applied to the variable to give
- it a particular size and alignment. You may use the predicates
- `DECL_THIS_STATIC' or `DECL_THIS_EXTERN' to test whether the
- storage class specifiers `static' or `extern' were used to declare
- a variable.
-
- If this variable is initialized (but does not require a
- constructor), the `DECL_INITIAL' will be an expression for the
- initializer. The initializer should be evaluated, and a bitwise
- copy into the variable performed. If the `DECL_INITIAL' is the
- `error_mark_node', there is an initializer, but it is given by an
- explicit statement later in the code; no bitwise copy is required.
-
- GCC provides an extension that allows either automatic variables,
- or global variables, to be placed in particular registers. This
- extension is being used for a particular `VAR_DECL' if
- `DECL_REGISTER' holds for the `VAR_DECL', and if
- `DECL_ASSEMBLER_NAME' is not equal to `DECL_NAME'. In that case,
- `DECL_ASSEMBLER_NAME' is the name of the register into which the
- variable will be placed.
-
-`PARM_DECL'
- Used to represent a parameter to a function. Treat these nodes
- similarly to `VAR_DECL' nodes. These nodes only appear in the
- `DECL_ARGUMENTS' for a `FUNCTION_DECL'.
-
- The `DECL_ARG_TYPE' for a `PARM_DECL' is the type that will
- actually be used when a value is passed to this function. It may
- be a wider type than the `TREE_TYPE' of the parameter; for
- example, the ordinary type might be `short' while the
- `DECL_ARG_TYPE' is `int'.
-
-`DEBUG_EXPR_DECL'
- Used to represent an anonymous debug-information temporary created
- to hold an expression as it is optimized away, so that its value
- can be referenced in debug bind statements.
-
-`FIELD_DECL'
- These nodes represent non-static data members. The `DECL_SIZE' and
- `DECL_ALIGN' behave as for `VAR_DECL' nodes. The position of the
- field within the parent record is specified by a combination of
- three attributes. `DECL_FIELD_OFFSET' is the position, counting
- in bytes, of the `DECL_OFFSET_ALIGN'-bit sized word containing the
- bit of the field closest to the beginning of the structure.
- `DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the
- field within this word; this may be nonzero even for fields that
- are not bit-fields, since `DECL_OFFSET_ALIGN' may be greater than
- the natural alignment of the field's type.
-
- If `DECL_C_BIT_FIELD' holds, this field is a bit-field. In a
- bit-field, `DECL_BIT_FIELD_TYPE' also contains the type that was
- originally specified for it, while DECL_TYPE may be a modified
- type with lesser precision, according to the size of the bit field.
-
-`NAMESPACE_DECL'
- Namespaces provide a name hierarchy for other declarations. They
- appear in the `DECL_CONTEXT' of other `_DECL' nodes.
-
-
-
-File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations
-
-11.4.2 Internal structure
--------------------------
-
-`DECL' nodes are represented internally as a hierarchy of structures.
-
-* Menu:
-
-* Current structure hierarchy:: The current DECL node structure
-hierarchy.
-* Adding new DECL node types:: How to add a new DECL node to a
-frontend.
-
-
-File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure
-
-11.4.2.1 Current structure hierarchy
-....................................
-
-`struct tree_decl_minimal'
- This is the minimal structure to inherit from in order for common
- `DECL' macros to work. The fields it contains are a unique ID,
- source location, context, and name.
-
-`struct tree_decl_common'
- This structure inherits from `struct tree_decl_minimal'. It
- contains fields that most `DECL' nodes need, such as a field to
- store alignment, machine mode, size, and attributes.
-
-`struct tree_field_decl'
- This structure inherits from `struct tree_decl_common'. It is
- used to represent `FIELD_DECL'.
-
-`struct tree_label_decl'
- This structure inherits from `struct tree_decl_common'. It is
- used to represent `LABEL_DECL'.
-
-`struct tree_translation_unit_decl'
- This structure inherits from `struct tree_decl_common'. It is
- used to represent `TRANSLATION_UNIT_DECL'.
-
-`struct tree_decl_with_rtl'
- This structure inherits from `struct tree_decl_common'. It
- contains a field to store the low-level RTL associated with a
- `DECL' node.
-
-`struct tree_result_decl'
- This structure inherits from `struct tree_decl_with_rtl'. It is
- used to represent `RESULT_DECL'.
-
-`struct tree_const_decl'
- This structure inherits from `struct tree_decl_with_rtl'. It is
- used to represent `CONST_DECL'.
-
-`struct tree_parm_decl'
- This structure inherits from `struct tree_decl_with_rtl'. It is
- used to represent `PARM_DECL'.
-
-`struct tree_decl_with_vis'
- This structure inherits from `struct tree_decl_with_rtl'. It
- contains fields necessary to store visibility information, as well
- as a section name and assembler name.
-
-`struct tree_var_decl'
- This structure inherits from `struct tree_decl_with_vis'. It is
- used to represent `VAR_DECL'.
-
-`struct tree_function_decl'
- This structure inherits from `struct tree_decl_with_vis'. It is
- used to represent `FUNCTION_DECL'.
-
-
-
-File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure
-
-11.4.2.2 Adding new DECL node types
-...................................
-
-Adding a new `DECL' tree consists of the following steps
-
-Add a new tree code for the `DECL' node
- For language specific `DECL' nodes, there is a `.def' file in each
- frontend directory where the tree code should be added. For
- `DECL' nodes that are part of the middle-end, the code should be
- added to `tree.def'.
-
-Create a new structure type for the `DECL' node
- These structures should inherit from one of the existing
- structures in the language hierarchy by using that structure as
- the first member.
-
- struct tree_foo_decl
- {
- struct tree_decl_with_vis common;
- }
-
- Would create a structure name `tree_foo_decl' that inherits from
- `struct tree_decl_with_vis'.
-
- For language specific `DECL' nodes, this new structure type should
- go in the appropriate `.h' file. For `DECL' nodes that are part
- of the middle-end, the structure type should go in `tree.h'.
-
-Add a member to the tree structure enumerator for the node
- For garbage collection and dynamic checking purposes, each `DECL'
- node structure type is required to have a unique enumerator value
- specified with it. For language specific `DECL' nodes, this new
- enumerator value should go in the appropriate `.def' file. For
- `DECL' nodes that are part of the middle-end, the enumerator
- values are specified in `treestruct.def'.
-
-Update `union tree_node'
- In order to make your new structure type usable, it must be added
- to `union tree_node'. For language specific `DECL' nodes, a new
- entry should be added to the appropriate `.h' file of the form
- struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl;
- For `DECL' nodes that are part of the middle-end, the additional
- member goes directly into `union tree_node' in `tree.h'.
-
-Update dynamic checking info
- In order to be able to check whether accessing a named portion of
- `union tree_node' is legal, and whether a certain `DECL' node
- contains one of the enumerated `DECL' node structures in the
- hierarchy, a simple lookup table is used. This lookup table needs
- to be kept up to date with the tree structure hierarchy, or else
- checking and containment macros will fail inappropriately.
-
- For language specific `DECL' nodes, their is an `init_ts' function
- in an appropriate `.c' file, which initializes the lookup table.
- Code setting up the table for new `DECL' nodes should be added
- there. For each `DECL' tree code and enumerator value
- representing a member of the inheritance hierarchy, the table
- should contain 1 if that tree code inherits (directly or
- indirectly) from that member. Thus, a `FOO_DECL' node derived
- from `struct decl_with_rtl', and enumerator value `TS_FOO_DECL',
- would be set up as follows
- tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1;
- tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1;
- tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1;
- tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1;
-
- For `DECL' nodes that are part of the middle-end, the setup code
- goes into `tree.c'.
-
-Add macros to access any new fields and flags
- Each added field or flag should have a macro that is used to access
- it, that performs appropriate checking to ensure only the right
- type of `DECL' nodes access the field.
-
- These macros generally take the following form
- #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname
- However, if the structure is simply a base class for further
- structures, something like the following should be used
- #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT)
- #define BASE_STRUCT_FIELDNAME(NODE) \
- (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname
-
-
-
-File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC
-
-11.5 Attributes in trees
-========================
-
-Attributes, as specified using the `__attribute__' keyword, are
-represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the
-name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a
-`TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE'
-if there are no arguments; the arguments are stored as the `TREE_VALUE'
-of successive entries in the list, and may be identifiers or
-expressions. The `TREE_CHAIN' of the attribute is the next attribute
-in a list of attributes applying to the same declaration or type, or
-`NULL_TREE' if there are no further attributes in the list.
-
- Attributes may be attached to declarations and to types; these
-attributes may be accessed with the following macros. All attributes
-are stored in this way, and many also cause other changes to the
-declaration or type or to other internal compiler data structures.
-
- -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL)
- This macro returns the attributes on the declaration DECL.
-
- -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE)
- This macro returns the attributes on the type TYPE.
-
-
-File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC
-
-11.6 Expressions
-================
-
-The internal representation for expressions is for the most part quite
-straightforward. However, there are a few facts that one must bear in
-mind. In particular, the expression "tree" is actually a directed
-acyclic graph. (For example there may be many references to the integer
-constant zero throughout the source program; many of these will be
-represented by the same expression node.) You should not rely on
-certain kinds of node being shared, nor should you rely on certain
-kinds of nodes being unshared.
-
- The following macros can be used with all expression nodes:
-
-`TREE_TYPE'
- Returns the type of the expression. This value may not be
- precisely the same type that would be given the expression in the
- original program.
-
- In what follows, some nodes that one might expect to always have type
-`bool' are documented to have either integral or boolean type. At some
-point in the future, the C front end may also make use of this same
-intermediate representation, and at this point these nodes will
-certainly have integral type. The previous sentence is not meant to
-imply that the C++ front end does not or will not give these nodes
-integral type.
-
- Below, we list the various kinds of expression nodes. Except where
-noted otherwise, the operands to an expression are accessed using the
-`TREE_OPERAND' macro. For example, to access the first operand to a
-binary plus expression `expr', use:
-
- TREE_OPERAND (expr, 0)
- As this example indicates, the operands are zero-indexed.
-
-* Menu:
-
-* Constants: Constant expressions.
-* Storage References::
-* Unary and Binary Expressions::
-* Vectors::
-
-
-File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees
-
-11.6.1 Constant expressions
----------------------------
-
-The table below begins with constants, moves on to unary expressions,
-then proceeds to binary expressions, and concludes with various other
-kinds of expressions:
-
-`INTEGER_CST'
- These nodes represent integer constants. Note that the type of
- these constants is obtained with `TREE_TYPE'; they are not always
- of type `int'. In particular, `char' constants are represented
- with `INTEGER_CST' nodes. The value of the integer constant `e' is
- given by
- ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT)
- + TREE_INST_CST_LOW (e))
- HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms.
- Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a
- `HOST_WIDE_INT'. The value of an `INTEGER_CST' is interpreted as
- a signed or unsigned quantity depending on the type of the
- constant. In general, the expression given above will overflow,
- so it should not be used to calculate the value of the constant.
-
- The variable `integer_zero_node' is an integer constant with value
- zero. Similarly, `integer_one_node' is an integer constant with
- value one. The `size_zero_node' and `size_one_node' variables are
- analogous, but have type `size_t' rather than `int'.
-
- The function `tree_int_cst_lt' is a predicate which holds if its
- first argument is less than its second. Both constants are
- assumed to have the same signedness (i.e., either both should be
- signed or both should be unsigned.) The full width of the
- constant is used when doing the comparison; the usual rules about
- promotions and conversions are ignored. Similarly,
- `tree_int_cst_equal' holds if the two constants are equal. The
- `tree_int_cst_sgn' function returns the sign of a constant. The
- value is `1', `0', or `-1' according on whether the constant is
- greater than, equal to, or less than zero. Again, the signedness
- of the constant's type is taken into account; an unsigned constant
- is never less than zero, no matter what its bit-pattern.
-
-`REAL_CST'
- FIXME: Talk about how to obtain representations of this constant,
- do comparisons, and so forth.
-
-`FIXED_CST'
- These nodes represent fixed-point constants. The type of these
- constants is obtained with `TREE_TYPE'. `TREE_FIXED_CST_PTR'
- points to a `struct fixed_value'; `TREE_FIXED_CST' returns the
- structure itself. `struct fixed_value' contains `data' with the
- size of two `HOST_BITS_PER_WIDE_INT' and `mode' as the associated
- fixed-point machine mode for `data'.
-
-`COMPLEX_CST'
- These nodes are used to represent complex number constants, that
- is a `__complex__' whose parts are constant nodes. The
- `TREE_REALPART' and `TREE_IMAGPART' return the real and the
- imaginary parts respectively.
-
-`VECTOR_CST'
- These nodes are used to represent vector constants, whose parts are
- constant nodes. Each individual constant node is either an
- integer or a double constant node. The first operand is a
- `TREE_LIST' of the constant nodes and is accessed through
- `TREE_VECTOR_CST_ELTS'.
-
-`STRING_CST'
- These nodes represent string-constants. The `TREE_STRING_LENGTH'
- returns the length of the string, as an `int'. The
- `TREE_STRING_POINTER' is a `char*' containing the string itself.
- The string may not be `NUL'-terminated, and it may contain
- embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH'
- includes the trailing `NUL' if it is present.
-
- For wide string constants, the `TREE_STRING_LENGTH' is the number
- of bytes in the string, and the `TREE_STRING_POINTER' points to an
- array of the bytes of the string, as represented on the target
- system (that is, as integers in the target endianness). Wide and
- non-wide string constants are distinguished only by the `TREE_TYPE'
- of the `STRING_CST'.
-
- FIXME: The formats of string constants are not well-defined when
- the target system bytes are not the same width as host system
- bytes.
-
-
-
-File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees
-
-11.6.2 References to storage
-----------------------------
-
-`ARRAY_REF'
- These nodes represent array accesses. The first operand is the
- array; the second is the index. To calculate the address of the
- memory accessed, you must scale the index by the size of the type
- of the array elements. The type of these expressions must be the
- type of a component of the array. The third and fourth operands
- are used after gimplification to represent the lower bound and
- component size but should not be used directly; call
- `array_ref_low_bound' and `array_ref_element_size' instead.
-
-`ARRAY_RANGE_REF'
- These nodes represent access to a range (or "slice") of an array.
- The operands are the same as that for `ARRAY_REF' and have the same
- meanings. The type of these expressions must be an array whose
- component type is the same as that of the first operand. The
- range of that array type determines the amount of data these
- expressions access.
-
-`TARGET_MEM_REF'
- These nodes represent memory accesses whose address directly map to
- an addressing mode of the target architecture. The first argument
- is `TMR_SYMBOL' and must be a `VAR_DECL' of an object with a fixed
- address. The second argument is `TMR_BASE' and the third one is
- `TMR_INDEX'. The fourth argument is `TMR_STEP' and must be an
- `INTEGER_CST'. The fifth argument is `TMR_OFFSET' and must be an
- `INTEGER_CST'. Any of the arguments may be NULL if the
- appropriate component does not appear in the address. Address of
- the `TARGET_MEM_REF' is determined in the following way.
-
- &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET
-
- The sixth argument is the reference to the original memory access,
- which is preserved for the purposes of the RTL alias analysis.
- The seventh argument is a tag representing the results of tree
- level alias analysis.
-
-`ADDR_EXPR'
- These nodes are used to represent the address of an object. (These
- expressions will always have pointer or reference type.) The
- operand may be another expression, or it may be a declaration.
-
- As an extension, GCC allows users to take the address of a label.
- In this case, the operand of the `ADDR_EXPR' will be a
- `LABEL_DECL'. The type of such an expression is `void*'.
-
- If the object addressed is not an lvalue, a temporary is created,
- and the address of the temporary is used.
-
-`INDIRECT_REF'
- These nodes are used to represent the object pointed to by a
- pointer. The operand is the pointer being dereferenced; it will
- always have pointer or reference type.
-
-`MEM_REF'
- These nodes are used to represent the object pointed to by a
- pointer offset by a constant. The first operand is the pointer
- being dereferenced; it will always have pointer or reference type.
- The second operand is a pointer constant. Its type is specifying
- the type to be used for type-based alias analysis.
-
-`COMPONENT_REF'
- These nodes represent non-static data member accesses. The first
- operand is the object (rather than a pointer to it); the second
- operand is the `FIELD_DECL' for the data member. The third
- operand represents the byte offset of the field, but should not be
- used directly; call `component_ref_field_offset' instead.
-
-
-
-File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees
-
-11.6.3 Unary and Binary Expressions
------------------------------------
-
-`NEGATE_EXPR'
- These nodes represent unary negation of the single operand, for
- both integer and floating-point types. The type of negation can be
- determined by looking at the type of the expression.
-
- The behavior of this operation on signed arithmetic overflow is
- controlled by the `flag_wrapv' and `flag_trapv' variables.
-
-`ABS_EXPR'
- These nodes represent the absolute value of the single operand, for
- both integer and floating-point types. This is typically used to
- implement the `abs', `labs' and `llabs' builtins for integer
- types, and the `fabs', `fabsf' and `fabsl' builtins for floating
- point types. The type of abs operation can be determined by
- looking at the type of the expression.
-
- This node is not used for complex types. To represent the modulus
- or complex abs of a complex value, use the `BUILT_IN_CABS',
- `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to
- implement the C99 `cabs', `cabsf' and `cabsl' built-in functions.
-
-`BIT_NOT_EXPR'
- These nodes represent bitwise complement, and will always have
- integral type. The only operand is the value to be complemented.
-
-`TRUTH_NOT_EXPR'
- These nodes represent logical negation, and will always have
- integral (or boolean) type. The operand is the value being
- negated. The type of the operand and that of the result are
- always of `BOOLEAN_TYPE' or `INTEGER_TYPE'.
-
-`PREDECREMENT_EXPR'
-`PREINCREMENT_EXPR'
-`POSTDECREMENT_EXPR'
-`POSTINCREMENT_EXPR'
- These nodes represent increment and decrement expressions. The
- value of the single operand is computed, and the operand
- incremented or decremented. In the case of `PREDECREMENT_EXPR' and
- `PREINCREMENT_EXPR', the value of the expression is the value
- resulting after the increment or decrement; in the case of
- `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before
- the increment or decrement occurs. The type of the operand, like
- that of the result, will be either integral, boolean, or
- floating-point.
-
-`FIX_TRUNC_EXPR'
- These nodes represent conversion of a floating-point value to an
- integer. The single operand will have a floating-point type, while
- the complete expression will have an integral (or boolean) type.
- The operand is rounded towards zero.
-
-`FLOAT_EXPR'
- These nodes represent conversion of an integral (or boolean) value
- to a floating-point value. The single operand will have integral
- type, while the complete expression will have a floating-point
- type.
-
- FIXME: How is the operand supposed to be rounded? Is this
- dependent on `-mieee'?
-
-`COMPLEX_EXPR'
- These nodes are used to represent complex numbers constructed from
- two expressions of the same (integer or real) type. The first
- operand is the real part and the second operand is the imaginary
- part.
-
-`CONJ_EXPR'
- These nodes represent the conjugate of their operand.
-
-`REALPART_EXPR'
-`IMAGPART_EXPR'
- These nodes represent respectively the real and the imaginary parts
- of complex numbers (their sole argument).
-
-`NON_LVALUE_EXPR'
- These nodes indicate that their one and only operand is not an
- lvalue. A back end can treat these identically to the single
- operand.
-
-`NOP_EXPR'
- These nodes are used to represent conversions that do not require
- any code-generation. For example, conversion of a `char*' to an
- `int*' does not require any code be generated; such a conversion is
- represented by a `NOP_EXPR'. The single operand is the expression
- to be converted. The conversion from a pointer to a reference is
- also represented with a `NOP_EXPR'.
-
-`CONVERT_EXPR'
- These nodes are similar to `NOP_EXPR's, but are used in those
- situations where code may need to be generated. For example, if an
- `int*' is converted to an `int' code may need to be generated on
- some platforms. These nodes are never used for C++-specific
- conversions, like conversions between pointers to different
- classes in an inheritance hierarchy. Any adjustments that need to
- be made in such cases are always indicated explicitly. Similarly,
- a user-defined conversion is never represented by a
- `CONVERT_EXPR'; instead, the function calls are made explicit.
-
-`FIXED_CONVERT_EXPR'
- These nodes are used to represent conversions that involve
- fixed-point values. For example, from a fixed-point value to
- another fixed-point value, from an integer to a fixed-point value,
- from a fixed-point value to an integer, from a floating-point
- value to a fixed-point value, or from a fixed-point value to a
- floating-point value.
-
-`LSHIFT_EXPR'
-`RSHIFT_EXPR'
- These nodes represent left and right shifts, respectively. The
- first operand is the value to shift; it will always be of integral
- type. The second operand is an expression for the number of bits
- by which to shift. Right shift should be treated as arithmetic,
- i.e., the high-order bits should be zero-filled when the
- expression has unsigned type and filled with the sign bit when the
- expression has signed type. Note that the result is undefined if
- the second operand is larger than or equal to the first operand's
- type size.
-
-`BIT_IOR_EXPR'
-`BIT_XOR_EXPR'
-`BIT_AND_EXPR'
- These nodes represent bitwise inclusive or, bitwise exclusive or,
- and bitwise and, respectively. Both operands will always have
- integral type.
-
-`TRUTH_ANDIF_EXPR'
-`TRUTH_ORIF_EXPR'
- These nodes represent logical "and" and logical "or", respectively.
- These operators are not strict; i.e., the second operand is
- evaluated only if the value of the expression is not determined by
- evaluation of the first operand. The type of the operands and
- that of the result are always of `BOOLEAN_TYPE' or `INTEGER_TYPE'.
-
-`TRUTH_AND_EXPR'
-`TRUTH_OR_EXPR'
-`TRUTH_XOR_EXPR'
- These nodes represent logical and, logical or, and logical
- exclusive or. They are strict; both arguments are always
- evaluated. There are no corresponding operators in C or C++, but
- the front end will sometimes generate these expressions anyhow, if
- it can tell that strictness does not matter. The type of the
- operands and that of the result are always of `BOOLEAN_TYPE' or
- `INTEGER_TYPE'.
-
-`POINTER_PLUS_EXPR'
- This node represents pointer arithmetic. The first operand is
- always a pointer/reference type. The second operand is always an
- unsigned integer type compatible with sizetype. This is the only
- binary arithmetic operand that can operate on pointer types.
-
-`PLUS_EXPR'
-`MINUS_EXPR'
-`MULT_EXPR'
- These nodes represent various binary arithmetic operations.
- Respectively, these operations are addition, subtraction (of the
- second operand from the first) and multiplication. Their operands
- may have either integral or floating type, but there will never be
- case in which one operand is of floating type and the other is of
- integral type.
-
- The behavior of these operations on signed arithmetic overflow is
- controlled by the `flag_wrapv' and `flag_trapv' variables.
-
-`RDIV_EXPR'
- This node represents a floating point division operation.
-
-`TRUNC_DIV_EXPR'
-`FLOOR_DIV_EXPR'
-`CEIL_DIV_EXPR'
-`ROUND_DIV_EXPR'
- These nodes represent integer division operations that return an
- integer result. `TRUNC_DIV_EXPR' rounds towards zero,
- `FLOOR_DIV_EXPR' rounds towards negative infinity, `CEIL_DIV_EXPR'
- rounds towards positive infinity and `ROUND_DIV_EXPR' rounds to
- the closest integer. Integer division in C and C++ is truncating,
- i.e. `TRUNC_DIV_EXPR'.
-
- The behavior of these operations on signed arithmetic overflow,
- when dividing the minimum signed integer by minus one, is
- controlled by the `flag_wrapv' and `flag_trapv' variables.
-
-`TRUNC_MOD_EXPR'
-`FLOOR_MOD_EXPR'
-`CEIL_MOD_EXPR'
-`ROUND_MOD_EXPR'
- These nodes represent the integer remainder or modulus operation.
- The integer modulus of two operands `a' and `b' is defined as `a -
- (a/b)*b' where the division calculated using the corresponding
- division operator. Hence for `TRUNC_MOD_EXPR' this definition
- assumes division using truncation towards zero, i.e.
- `TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating
- division, i.e. `TRUNC_MOD_EXPR'.
-
-`EXACT_DIV_EXPR'
- The `EXACT_DIV_EXPR' code is used to represent integer divisions
- where the numerator is known to be an exact multiple of the
- denominator. This allows the backend to choose between the faster
- of `TRUNC_DIV_EXPR', `CEIL_DIV_EXPR' and `FLOOR_DIV_EXPR' for the
- current target.
-
-`LT_EXPR'
-`LE_EXPR'
-`GT_EXPR'
-`GE_EXPR'
-`EQ_EXPR'
-`NE_EXPR'
- These nodes represent the less than, less than or equal to, greater
- than, greater than or equal to, equal, and not equal comparison
- operators. The first and second operand with either be both of
- integral type or both of floating type. The result type of these
- expressions will always be of integral or boolean type. These
- operations return the result type's zero value for false, and the
- result type's one value for true.
-
- For floating point comparisons, if we honor IEEE NaNs and either
- operand is NaN, then `NE_EXPR' always returns true and the
- remaining operators always return false. On some targets,
- comparisons against an IEEE NaN, other than equality and
- inequality, may generate a floating point exception.
-
-`ORDERED_EXPR'
-`UNORDERED_EXPR'
- These nodes represent non-trapping ordered and unordered comparison
- operators. These operations take two floating point operands and
- determine whether they are ordered or unordered relative to each
- other. If either operand is an IEEE NaN, their comparison is
- defined to be unordered, otherwise the comparison is defined to be
- ordered. The result type of these expressions will always be of
- integral or boolean type. These operations return the result
- type's zero value for false, and the result type's one value for
- true.
-
-`UNLT_EXPR'
-`UNLE_EXPR'
-`UNGT_EXPR'
-`UNGE_EXPR'
-`UNEQ_EXPR'
-`LTGT_EXPR'
- These nodes represent the unordered comparison operators. These
- operations take two floating point operands and determine whether
- the operands are unordered or are less than, less than or equal to,
- greater than, greater than or equal to, or equal respectively. For
- example, `UNLT_EXPR' returns true if either operand is an IEEE NaN
- or the first operand is less than the second. With the possible
- exception of `LTGT_EXPR', all of these operations are guaranteed
- not to generate a floating point exception. The result type of
- these expressions will always be of integral or boolean type.
- These operations return the result type's zero value for false,
- and the result type's one value for true.
-
-`MODIFY_EXPR'
- These nodes represent assignment. The left-hand side is the first
- operand; the right-hand side is the second operand. The left-hand
- side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or
- other lvalue.
-
- These nodes are used to represent not only assignment with `=' but
- also compound assignments (like `+='), by reduction to `='
- assignment. In other words, the representation for `i += 3' looks
- just like that for `i = i + 3'.
-
-`INIT_EXPR'
- These nodes are just like `MODIFY_EXPR', but are used only when a
- variable is initialized, rather than assigned to subsequently.
- This means that we can assume that the target of the
- initialization is not used in computing its own value; any
- reference to the lhs in computing the rhs is undefined.
-
-`COMPOUND_EXPR'
- These nodes represent comma-expressions. The first operand is an
- expression whose value is computed and thrown away prior to the
- evaluation of the second operand. The value of the entire
- expression is the value of the second operand.
-
-`COND_EXPR'
- These nodes represent `?:' expressions. The first operand is of
- boolean or integral type. If it evaluates to a nonzero value, the
- second operand should be evaluated, and returned as the value of
- the expression. Otherwise, the third operand is evaluated, and
- returned as the value of the expression.
-
- The second operand must have the same type as the entire
- expression, unless it unconditionally throws an exception or calls
- a noreturn function, in which case it should have void type. The
- same constraints apply to the third operand. This allows array
- bounds checks to be represented conveniently as `(i >= 0 && i <
- 10) ? i : abort()'.
-
- As a GNU extension, the C language front-ends allow the second
- operand of the `?:' operator may be omitted in the source. For
- example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x'
- is an expression without side-effects. In the tree
- representation, however, the second operand is always present,
- possibly protected by `SAVE_EXPR' if the first argument does cause
- side-effects.
-
-`CALL_EXPR'
- These nodes are used to represent calls to functions, including
- non-static member functions. `CALL_EXPR's are implemented as
- expression nodes with a variable number of operands. Rather than
- using `TREE_OPERAND' to extract them, it is preferable to use the
- specialized accessor macros and functions that operate
- specifically on `CALL_EXPR' nodes.
-
- `CALL_EXPR_FN' returns a pointer to the function to call; it is
- always an expression whose type is a `POINTER_TYPE'.
-
- The number of arguments to the call is returned by
- `call_expr_nargs', while the arguments themselves can be accessed
- with the `CALL_EXPR_ARG' macro. The arguments are zero-indexed
- and numbered left-to-right. You can iterate over the arguments
- using `FOR_EACH_CALL_EXPR_ARG', as in:
-
- tree call, arg;
- call_expr_arg_iterator iter;
- FOR_EACH_CALL_EXPR_ARG (arg, iter, call)
- /* arg is bound to successive arguments of call. */
- ...;
-
- For non-static member functions, there will be an operand
- corresponding to the `this' pointer. There will always be
- expressions corresponding to all of the arguments, even if the
- function is declared with default arguments and some arguments are
- not explicitly provided at the call sites.
-
- `CALL_EXPR's also have a `CALL_EXPR_STATIC_CHAIN' operand that is
- used to implement nested functions. This operand is otherwise
- null.
-
-`CLEANUP_POINT_EXPR'
- These nodes represent full-expressions. The single operand is an
- expression to evaluate. Any destructor calls engendered by the
- creation of temporaries during the evaluation of that expression
- should be performed immediately after the expression is evaluated.
-
-`CONSTRUCTOR'
- These nodes represent the brace-enclosed initializers for a
- structure or array. The first operand is reserved for use by the
- back end. The second operand is a `TREE_LIST'. If the
- `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or
- `UNION_TYPE', then the `TREE_PURPOSE' of each node in the
- `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each
- node will be the expression used to initialize that field.
-
- If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then
- the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an
- `INTEGER_CST' or a `RANGE_EXPR' of two `INTEGER_CST's. A single
- `INTEGER_CST' indicates which element of the array (indexed from
- zero) is being assigned to. A `RANGE_EXPR' indicates an inclusive
- range of elements to initialize. In both cases the `TREE_VALUE'
- is the corresponding initializer. It is re-evaluated for each
- element of a `RANGE_EXPR'. If the `TREE_PURPOSE' is `NULL_TREE',
- then the initializer is for the next available array element.
-
- In the front end, you should not depend on the fields appearing in
- any particular order. However, in the middle end, fields must
- appear in declaration order. You should not assume that all
- fields will be represented. Unrepresented fields will be set to
- zero.
-
-`COMPOUND_LITERAL_EXPR'
- These nodes represent ISO C99 compound literals. The
- `COMPOUND_LITERAL_EXPR_DECL_EXPR' is a `DECL_EXPR' containing an
- anonymous `VAR_DECL' for the unnamed object represented by the
- compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a
- `CONSTRUCTOR' representing the brace-enclosed list of initializers
- in the compound literal. That anonymous `VAR_DECL' can also be
- accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro.
-
-`SAVE_EXPR'
- A `SAVE_EXPR' represents an expression (possibly involving
- side-effects) that is used more than once. The side-effects should
- occur only the first time the expression is evaluated. Subsequent
- uses should just reuse the computed value. The first operand to
- the `SAVE_EXPR' is the expression to evaluate. The side-effects
- should be executed where the `SAVE_EXPR' is first encountered in a
- depth-first preorder traversal of the expression tree.
-
-`TARGET_EXPR'
- A `TARGET_EXPR' represents a temporary object. The first operand
- is a `VAR_DECL' for the temporary variable. The second operand is
- the initializer for the temporary. The initializer is evaluated
- and, if non-void, copied (bitwise) into the temporary. If the
- initializer is void, that means that it will perform the
- initialization itself.
-
- Often, a `TARGET_EXPR' occurs on the right-hand side of an
- assignment, or as the second operand to a comma-expression which is
- itself the right-hand side of an assignment, etc. In this case,
- we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is
- "orphaned". For a normal `TARGET_EXPR' the temporary variable
- should be treated as an alias for the left-hand side of the
- assignment, rather than as a new temporary variable.
-
- The third operand to the `TARGET_EXPR', if present, is a
- cleanup-expression (i.e., destructor call) for the temporary. If
- this expression is orphaned, then this expression must be executed
- when the statement containing this expression is complete. These
- cleanups must always be executed in the order opposite to that in
- which they were encountered. Note that if a temporary is created
- on one branch of a conditional operator (i.e., in the second or
- third operand to a `COND_EXPR'), the cleanup must be run only if
- that branch is actually executed.
-
-`VA_ARG_EXPR'
- This node is used to implement support for the C/C++ variable
- argument-list mechanism. It represents expressions like `va_arg
- (ap, type)'. Its `TREE_TYPE' yields the tree representation for
- `type' and its sole argument yields the representation for `ap'.
-
-
-
-File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees
-
-11.6.4 Vectors
---------------
-
-`VEC_LSHIFT_EXPR'
-`VEC_RSHIFT_EXPR'
- These nodes represent whole vector left and right shifts,
- respectively. The first operand is the vector to shift; it will
- always be of vector type. The second operand is an expression for
- the number of bits by which to shift. Note that the result is
- undefined if the second operand is larger than or equal to the
- first operand's type size.
-
-`VEC_WIDEN_MULT_HI_EXPR'
-`VEC_WIDEN_MULT_LO_EXPR'
- These nodes represent widening vector multiplication of the high
- and low parts of the two input vectors, respectively. Their
- operands are vectors that contain the same number of elements
- (`N') of the same integral type. The result is a vector that
- contains half as many elements, of an integral type whose size is
- twice as wide. In the case of `VEC_WIDEN_MULT_HI_EXPR' the high
- `N/2' elements of the two vector are multiplied to produce the
- vector of `N/2' products. In the case of `VEC_WIDEN_MULT_LO_EXPR'
- the low `N/2' elements of the two vector are multiplied to produce
- the vector of `N/2' products.
-
-`VEC_UNPACK_HI_EXPR'
-`VEC_UNPACK_LO_EXPR'
- These nodes represent unpacking of the high and low parts of the
- input vector, respectively. The single operand is a vector that
- contains `N' elements of the same integral or floating point type.
- The result is a vector that contains half as many elements, of an
- integral or floating point type whose size is twice as wide. In
- the case of `VEC_UNPACK_HI_EXPR' the high `N/2' elements of the
- vector are extracted and widened (promoted). In the case of
- `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the vector are
- extracted and widened (promoted).
-
-`VEC_UNPACK_FLOAT_HI_EXPR'
-`VEC_UNPACK_FLOAT_LO_EXPR'
- These nodes represent unpacking of the high and low parts of the
- input vector, where the values are converted from fixed point to
- floating point. The single operand is a vector that contains `N'
- elements of the same integral type. The result is a vector that
- contains half as many elements of a floating point type whose size
- is twice as wide. In the case of `VEC_UNPACK_HI_EXPR' the high
- `N/2' elements of the vector are extracted, converted and widened.
- In the case of `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the
- vector are extracted, converted and widened.
-
-`VEC_PACK_TRUNC_EXPR'
- This node represents packing of truncated elements of the two
- input vectors into the output vector. Input operands are vectors
- that contain the same number of elements of the same integral or
- floating point type. The result is a vector that contains twice
- as many elements of an integral or floating point type whose size
- is half as wide. The elements of the two vectors are demoted and
- merged (concatenated) to form the output vector.
-
-`VEC_PACK_SAT_EXPR'
- This node represents packing of elements of the two input vectors
- into the output vector using saturation. Input operands are
- vectors that contain the same number of elements of the same
- integral type. The result is a vector that contains twice as many
- elements of an integral type whose size is half as wide. The
- elements of the two vectors are demoted and merged (concatenated)
- to form the output vector.
-
-`VEC_PACK_FIX_TRUNC_EXPR'
- This node represents packing of elements of the two input vectors
- into the output vector, where the values are converted from
- floating point to fixed point. Input operands are vectors that
- contain the same number of elements of a floating point type. The
- result is a vector that contains twice as many elements of an
- integral type whose size is half as wide. The elements of the two
- vectors are merged (concatenated) to form the output vector.
-
-`VEC_EXTRACT_EVEN_EXPR'
-`VEC_EXTRACT_ODD_EXPR'
- These nodes represent extracting of the even/odd elements of the
- two input vectors, respectively. Their operands and result are
- vectors that contain the same number of elements of the same type.
-
-`VEC_INTERLEAVE_HIGH_EXPR'
-`VEC_INTERLEAVE_LOW_EXPR'
- These nodes represent merging and interleaving of the high/low
- elements of the two input vectors, respectively. The operands and
- the result are vectors that contain the same number of elements
- (`N') of the same type. In the case of
- `VEC_INTERLEAVE_HIGH_EXPR', the high `N/2' elements of the first
- input vector are interleaved with the high `N/2' elements of the
- second input vector. In the case of `VEC_INTERLEAVE_LOW_EXPR', the
- low `N/2' elements of the first input vector are interleaved with
- the low `N/2' elements of the second input vector.
-
-
-
-File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC
-
-11.7 Statements
-===============
-
-Most statements in GIMPLE are assignment statements, represented by
-`GIMPLE_ASSIGN'. No other C expressions can appear at statement level;
-a reference to a volatile object is converted into a `GIMPLE_ASSIGN'.
-
- There are also several varieties of complex statements.
-
-* Menu:
-
-* Basic Statements::
-* Blocks::
-* Statement Sequences::
-* Empty Statements::
-* Jumps::
-* Cleanups::
-* OpenMP::
-
-
-File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements
-
-11.7.1 Basic Statements
------------------------
-
-`ASM_EXPR'
- Used to represent an inline assembly statement. For an inline
- assembly statement like:
- asm ("mov x, y");
- The `ASM_STRING' macro will return a `STRING_CST' node for `"mov
- x, y"'. If the original statement made use of the
- extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and
- `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the
- statement, represented as `STRING_CST' nodes. The
- extended-assembly syntax looks like:
- asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
- The first string is the `ASM_STRING', containing the instruction
- template. The next two strings are the output and inputs,
- respectively; this statement has no clobbers. As this example
- indicates, "plain" assembly statements are merely a special case
- of extended assembly statements; they have no cv-qualifiers,
- outputs, inputs, or clobbers. All of the strings will be
- `NUL'-terminated, and will contain no embedded `NUL'-characters.
-
- If the assembly statement is declared `volatile', or if the
- statement was not an extended assembly statement, and is therefore
- implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold
- of the `ASM_EXPR'.
-
-`DECL_EXPR'
- Used to represent a local declaration. The `DECL_EXPR_DECL' macro
- can be used to obtain the entity declared. This declaration may
- be a `LABEL_DECL', indicating that the label declared is a local
- label. (As an extension, GCC allows the declaration of labels
- with scope.) In C, this declaration may be a `FUNCTION_DECL',
- indicating the use of the GCC nested function extension. For more
- information, *note Functions::.
-
-`LABEL_EXPR'
- Used to represent a label. The `LABEL_DECL' declared by this
- statement can be obtained with the `LABEL_EXPR_LABEL' macro. The
- `IDENTIFIER_NODE' giving the name of the label can be obtained from
- the `LABEL_DECL' with `DECL_NAME'.
-
-`GOTO_EXPR'
- Used to represent a `goto' statement. The `GOTO_DESTINATION' will
- usually be a `LABEL_DECL'. However, if the "computed goto"
- extension has been used, the `GOTO_DESTINATION' will be an
- arbitrary expression indicating the destination. This expression
- will always have pointer type.
-
-`RETURN_EXPR'
- Used to represent a `return' statement. Operand 0 represents the
- value to return. It should either be the `RESULT_DECL' for the
- containing function, or a `MODIFY_EXPR' or `INIT_EXPR' setting the
- function's `RESULT_DECL'. It will be `NULL_TREE' if the statement
- was just
- return;
-
-`LOOP_EXPR'
- These nodes represent "infinite" loops. The `LOOP_EXPR_BODY'
- represents the body of the loop. It should be executed forever,
- unless an `EXIT_EXPR' is encountered.
-
-`EXIT_EXPR'
- These nodes represent conditional exits from the nearest enclosing
- `LOOP_EXPR'. The single operand is the condition; if it is
- nonzero, then the loop should be exited. An `EXIT_EXPR' will only
- appear within a `LOOP_EXPR'.
-
-`SWITCH_STMT'
- Used to represent a `switch' statement. The `SWITCH_STMT_COND' is
- the expression on which the switch is occurring. See the
- documentation for an `IF_STMT' for more information on the
- representation used for the condition. The `SWITCH_STMT_BODY' is
- the body of the switch statement. The `SWITCH_STMT_TYPE' is the
- original type of switch expression as given in the source, before
- any compiler conversions.
-
-`CASE_LABEL_EXPR'
- Use to represent a `case' label, range of `case' labels, or a
- `default' label. If `CASE_LOW' is `NULL_TREE', then this is a
- `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then
- this is an ordinary `case' label. In this case, `CASE_LOW' is an
- expression giving the value of the label. Both `CASE_LOW' and
- `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the
- same type as the condition expression in the switch statement.
-
- Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the
- statement is a range of case labels. Such statements originate
- with the extension that allows users to write things of the form:
- case 2 ... 5:
- The first value will be `CASE_LOW', while the second will be
- `CASE_HIGH'.
-
-
-
-File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements
-
-11.7.2 Blocks
--------------
-
-Block scopes and the variables they declare in GENERIC are expressed
-using the `BIND_EXPR' code, which in previous versions of GCC was
-primarily used for the C statement-expression extension.
-
- Variables in a block are collected into `BIND_EXPR_VARS' in
-declaration order through their `TREE_CHAIN' field. Any runtime
-initialization is moved out of `DECL_INITIAL' and into a statement in
-the controlled block. When gimplifying from C or C++, this
-initialization replaces the `DECL_STMT'. These variables will never
-require cleanups. The scope of these variables is just the body
-
- Variable-length arrays (VLAs) complicate this process, as their size
-often refers to variables initialized earlier in the block. To handle
-this, we currently split the block at that point, and move the VLA into
-a new, inner `BIND_EXPR'. This strategy may change in the future.
-
- A C++ program will usually contain more `BIND_EXPR's than there are
-syntactic blocks in the source code, since several C++ constructs have
-implicit scopes associated with them. On the other hand, although the
-C++ front end uses pseudo-scopes to handle cleanups for objects with
-destructors, these don't translate into the GIMPLE form; multiple
-declarations at the same level use the same `BIND_EXPR'.
-
-
-File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements
-
-11.7.3 Statement Sequences
---------------------------
-
-Multiple statements at the same nesting level are collected into a
-`STATEMENT_LIST'. Statement lists are modified and traversed using the
-interface in `tree-iterator.h'.
-
-
-File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements
-
-11.7.4 Empty Statements
------------------------
-
-Whenever possible, statements with no effect are discarded. But if
-they are nested within another construct which cannot be discarded for
-some reason, they are instead replaced with an empty statement,
-generated by `build_empty_stmt'. Initially, all empty statements were
-shared, after the pattern of the Java front end, but this caused a lot
-of trouble in practice.
-
- An empty statement is represented as `(void)0'.
-
-
-File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements
-
-11.7.5 Jumps
-------------
-
-Other jumps are expressed by either `GOTO_EXPR' or `RETURN_EXPR'.
-
- The operand of a `GOTO_EXPR' must be either a label or a variable
-containing the address to jump to.
-
- The operand of a `RETURN_EXPR' is either `NULL_TREE', `RESULT_DECL',
-or a `MODIFY_EXPR' which sets the return value. It would be nice to
-move the `MODIFY_EXPR' into a separate statement, but the special
-return semantics in `expand_return' make that difficult. It may still
-happen in the future, perhaps by moving most of that logic into
-`expand_assignment'.
-
-
-File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements
-
-11.7.6 Cleanups
----------------
-
-Destructors for local C++ objects and similar dynamic cleanups are
-represented in GIMPLE by a `TRY_FINALLY_EXPR'. `TRY_FINALLY_EXPR' has
-two operands, both of which are a sequence of statements to execute.
-The first sequence is executed. When it completes the second sequence
-is executed.
-
- The first sequence may complete in the following ways:
-
- 1. Execute the last statement in the sequence and fall off the end.
-
- 2. Execute a goto statement (`GOTO_EXPR') to an ordinary label
- outside the sequence.
-
- 3. Execute a return statement (`RETURN_EXPR').
-
- 4. Throw an exception. This is currently not explicitly represented
- in GIMPLE.
-
-
- The second sequence is not executed if the first sequence completes by
-calling `setjmp' or `exit' or any other function that does not return.
-The second sequence is also not executed if the first sequence
-completes via a non-local goto or a computed goto (in general the
-compiler does not know whether such a goto statement exits the first
-sequence or not, so we assume that it doesn't).
-
- After the second sequence is executed, if it completes normally by
-falling off the end, execution continues wherever the first sequence
-would have continued, by falling off the end, or doing a goto, etc.
-
- `TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs
-to appear on every edge out of the controlled block; this reduces the
-freedom to move code across these edges. Therefore, the EH lowering
-pass which runs before most of the optimization passes eliminates these
-expressions by explicitly adding the cleanup to each edge. Rethrowing
-the exception is represented using `RESX_EXPR'.
-
-
-File: gccint.info, Node: OpenMP, Prev: Cleanups, Up: Statements
-
-11.7.7 OpenMP
--------------
-
-All the statements starting with `OMP_' represent directives and
-clauses used by the OpenMP API `http://www.openmp.org/'.
-
-`OMP_PARALLEL'
- Represents `#pragma omp parallel [clause1 ... clauseN]'. It has
- four operands:
-
- Operand `OMP_PARALLEL_BODY' is valid while in GENERIC and High
- GIMPLE forms. It contains the body of code to be executed by all
- the threads. During GIMPLE lowering, this operand becomes `NULL'
- and the body is emitted linearly after `OMP_PARALLEL'.
-
- Operand `OMP_PARALLEL_CLAUSES' is the list of clauses associated
- with the directive.
-
- Operand `OMP_PARALLEL_FN' is created by `pass_lower_omp', it
- contains the `FUNCTION_DECL' for the function that will contain
- the body of the parallel region.
-
- Operand `OMP_PARALLEL_DATA_ARG' is also created by
- `pass_lower_omp'. If there are shared variables to be communicated
- to the children threads, this operand will contain the `VAR_DECL'
- that contains all the shared values and variables.
-
-`OMP_FOR'
- Represents `#pragma omp for [clause1 ... clauseN]'. It has 5
- operands:
-
- Operand `OMP_FOR_BODY' contains the loop body.
-
- Operand `OMP_FOR_CLAUSES' is the list of clauses associated with
- the directive.
-
- Operand `OMP_FOR_INIT' is the loop initialization code of the form
- `VAR = N1'.
-
- Operand `OMP_FOR_COND' is the loop conditional expression of the
- form `VAR {<,>,<=,>=} N2'.
-
- Operand `OMP_FOR_INCR' is the loop index increment of the form
- `VAR {+=,-=} INCR'.
-
- Operand `OMP_FOR_PRE_BODY' contains side-effect code from operands
- `OMP_FOR_INIT', `OMP_FOR_COND' and `OMP_FOR_INC'. These
- side-effects are part of the `OMP_FOR' block but must be evaluated
- before the start of loop body.
-
- The loop index variable `VAR' must be a signed integer variable,
- which is implicitly private to each thread. Bounds `N1' and `N2'
- and the increment expression `INCR' are required to be loop
- invariant integer expressions that are evaluated without any
- synchronization. The evaluation order, frequency of evaluation and
- side-effects are unspecified by the standard.
-
-`OMP_SECTIONS'
- Represents `#pragma omp sections [clause1 ... clauseN]'.
-
- Operand `OMP_SECTIONS_BODY' contains the sections body, which in
- turn contains a set of `OMP_SECTION' nodes for each of the
- concurrent sections delimited by `#pragma omp section'.
-
- Operand `OMP_SECTIONS_CLAUSES' is the list of clauses associated
- with the directive.
-
-`OMP_SECTION'
- Section delimiter for `OMP_SECTIONS'.
-
-`OMP_SINGLE'
- Represents `#pragma omp single'.
-
- Operand `OMP_SINGLE_BODY' contains the body of code to be executed
- by a single thread.
-
- Operand `OMP_SINGLE_CLAUSES' is the list of clauses associated
- with the directive.
-
-`OMP_MASTER'
- Represents `#pragma omp master'.
-
- Operand `OMP_MASTER_BODY' contains the body of code to be executed
- by the master thread.
-
-`OMP_ORDERED'
- Represents `#pragma omp ordered'.
-
- Operand `OMP_ORDERED_BODY' contains the body of code to be
- executed in the sequential order dictated by the loop index
- variable.
-
-`OMP_CRITICAL'
- Represents `#pragma omp critical [name]'.
-
- Operand `OMP_CRITICAL_BODY' is the critical section.
-
- Operand `OMP_CRITICAL_NAME' is an optional identifier to label the
- critical section.
-
-`OMP_RETURN'
- This does not represent any OpenMP directive, it is an artificial
- marker to indicate the end of the body of an OpenMP. It is used by
- the flow graph (`tree-cfg.c') and OpenMP region building code
- (`omp-low.c').
-
-`OMP_CONTINUE'
- Similarly, this instruction does not represent an OpenMP
- directive, it is used by `OMP_FOR' and `OMP_SECTIONS' to mark the
- place where the code needs to loop to the next iteration (in the
- case of `OMP_FOR') or the next section (in the case of
- `OMP_SECTIONS').
-
- In some cases, `OMP_CONTINUE' is placed right before `OMP_RETURN'.
- But if there are cleanups that need to occur right after the
- looping body, it will be emitted between `OMP_CONTINUE' and
- `OMP_RETURN'.
-
-`OMP_ATOMIC'
- Represents `#pragma omp atomic'.
-
- Operand 0 is the address at which the atomic operation is to be
- performed.
-
- Operand 1 is the expression to evaluate. The gimplifier tries
- three alternative code generation strategies. Whenever possible,
- an atomic update built-in is used. If that fails, a
- compare-and-swap loop is attempted. If that also fails, a regular
- critical section around the expression is used.
-
-`OMP_CLAUSE'
- Represents clauses associated with one of the `OMP_' directives.
- Clauses are represented by separate sub-codes defined in `tree.h'.
- Clauses codes can be one of: `OMP_CLAUSE_PRIVATE',
- `OMP_CLAUSE_SHARED', `OMP_CLAUSE_FIRSTPRIVATE',
- `OMP_CLAUSE_LASTPRIVATE', `OMP_CLAUSE_COPYIN',
- `OMP_CLAUSE_COPYPRIVATE', `OMP_CLAUSE_IF',
- `OMP_CLAUSE_NUM_THREADS', `OMP_CLAUSE_SCHEDULE',
- `OMP_CLAUSE_NOWAIT', `OMP_CLAUSE_ORDERED', `OMP_CLAUSE_DEFAULT',
- and `OMP_CLAUSE_REDUCTION'. Each code represents the
- corresponding OpenMP clause.
-
- Clauses associated with the same directive are chained together
- via `OMP_CLAUSE_CHAIN'. Those clauses that accept a list of
- variables are restricted to exactly one, accessed with
- `OMP_CLAUSE_VAR'. Therefore, multiple variables under the same
- clause `C' need to be represented as multiple `C' clauses chained
- together. This facilitates adding new clauses during compilation.
-
-
-
-File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC
-
-11.8 Functions
-==============
-
-A function is represented by a `FUNCTION_DECL' node. It stores the
-basic pieces of the function such as body, parameters, and return type
-as well as information on the surrounding context, visibility, and
-linkage.
-
-* Menu:
-
-* Function Basics:: Function names, body, and parameters.
-* Function Properties:: Context, linkage, etc.
-
-
-File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions
-
-11.8.1 Function Basics
-----------------------
-
-A function has four core parts: the name, the parameters, the result,
-and the body. The following macros and functions access these parts of
-a `FUNCTION_DECL' as well as other basic features:
-`DECL_NAME'
- This macro returns the unqualified name of the function, as an
- `IDENTIFIER_NODE'. For an instantiation of a function template,
- the `DECL_NAME' is the unqualified name of the template, not
- something like `f<int>'. The value of `DECL_NAME' is undefined
- when used on a constructor, destructor, overloaded operator, or
- type-conversion operator, or any function that is implicitly
- generated by the compiler. See below for macros that can be used
- to distinguish these cases.
-
-`DECL_ASSEMBLER_NAME'
- This macro returns the mangled name of the function, also an
- `IDENTIFIER_NODE'. This name does not contain leading underscores
- on systems that prefix all identifiers with underscores. The
- mangled name is computed in the same way on all platforms; if
- special processing is required to deal with the object file format
- used on a particular platform, it is the responsibility of the
- back end to perform those modifications. (Of course, the back end
- should not modify `DECL_ASSEMBLER_NAME' itself.)
-
- Using `DECL_ASSEMBLER_NAME' will cause additional memory to be
- allocated (for the mangled name of the entity) so it should be used
- only when emitting assembly code. It should not be used within the
- optimizers to determine whether or not two declarations are the
- same, even though some of the existing optimizers do use it in
- that way. These uses will be removed over time.
-
-`DECL_ARGUMENTS'
- This macro returns the `PARM_DECL' for the first argument to the
- function. Subsequent `PARM_DECL' nodes can be obtained by
- following the `TREE_CHAIN' links.
-
-`DECL_RESULT'
- This macro returns the `RESULT_DECL' for the function.
-
-`DECL_SAVED_TREE'
- This macro returns the complete body of the function.
-
-`TREE_TYPE'
- This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the
- function.
-
-`DECL_INITIAL'
- A function that has a definition in the current translation unit
- will have a non-`NULL' `DECL_INITIAL'. However, back ends should
- not make use of the particular value given by `DECL_INITIAL'.
-
- It should contain a tree of `BLOCK' nodes that mirrors the scopes
- that variables are bound in the function. Each block contains a
- list of decls declared in a basic block, a pointer to a chain of
- blocks at the next lower scope level, then a pointer to the next
- block at the same level and a backpointer to the parent `BLOCK' or
- `FUNCTION_DECL'. So given a function as follows:
-
- void foo()
- {
- int a;
- {
- int b;
- }
- int c;
- }
-
- you would get the following:
-
- tree foo = FUNCTION_DECL;
- tree decl_a = VAR_DECL;
- tree decl_b = VAR_DECL;
- tree decl_c = VAR_DECL;
- tree block_a = BLOCK;
- tree block_b = BLOCK;
- tree block_c = BLOCK;
- BLOCK_VARS(block_a) = decl_a;
- BLOCK_SUBBLOCKS(block_a) = block_b;
- BLOCK_CHAIN(block_a) = block_c;
- BLOCK_SUPERCONTEXT(block_a) = foo;
- BLOCK_VARS(block_b) = decl_b;
- BLOCK_SUPERCONTEXT(block_b) = block_a;
- BLOCK_VARS(block_c) = decl_c;
- BLOCK_SUPERCONTEXT(block_c) = foo;
- DECL_INITIAL(foo) = block_a;
-
-
-
-File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions
-
-11.8.2 Function Properties
---------------------------
-
-To determine the scope of a function, you can use the `DECL_CONTEXT'
-macro. This macro will return the class (either a `RECORD_TYPE' or a
-`UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function
-is a member. For a virtual function, this macro returns the class in
-which the function was actually defined, not the base class in which
-the virtual declaration occurred.
-
- In C, the `DECL_CONTEXT' for a function maybe another function. This
-representation indicates that the GNU nested function extension is in
-use. For details on the semantics of nested functions, see the GCC
-Manual. The nested function can refer to local variables in its
-containing function. Such references are not explicitly marked in the
-tree structure; back ends must look at the `DECL_CONTEXT' for the
-referenced `VAR_DECL'. If the `DECL_CONTEXT' for the referenced
-`VAR_DECL' is not the same as the function currently being processed,
-and neither `DECL_EXTERNAL' nor `TREE_STATIC' hold, then the reference
-is to a local variable in a containing function, and the back end must
-take appropriate action.
-
-`DECL_EXTERNAL'
- This predicate holds if the function is undefined.
-
-`TREE_PUBLIC'
- This predicate holds if the function has external linkage.
-
-`TREE_STATIC'
- This predicate holds if the function has been defined.
-
-`TREE_THIS_VOLATILE'
- This predicate holds if the function does not return normally.
-
-`TREE_READONLY'
- This predicate holds if the function can only read its arguments.
-
-`DECL_PURE_P'
- This predicate holds if the function can only read its arguments,
- but may also read global memory.
-
-`DECL_VIRTUAL_P'
- This predicate holds if the function is virtual.
-
-`DECL_ARTIFICIAL'
- This macro holds if the function was implicitly generated by the
- compiler, rather than explicitly declared. In addition to
- implicitly generated class member functions, this macro holds for
- the special functions created to implement static initialization
- and destruction, to compute run-time type information, and so
- forth.
-
-`DECL_FUNCTION_SPECIFIC_TARGET'
- This macro returns a tree node that holds the target options that
- are to be used to compile this particular function or `NULL_TREE'
- if the function is to be compiled with the target options
- specified on the command line.
-
-`DECL_FUNCTION_SPECIFIC_OPTIMIZATION'
- This macro returns a tree node that holds the optimization options
- that are to be used to compile this particular function or
- `NULL_TREE' if the function is to be compiled with the
- optimization options specified on the command line.
-
-
-
-File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC
-
-11.9 Language-dependent trees
-=============================
-
-Front ends may wish to keep some state associated with various GENERIC
-trees while parsing. To support this, trees provide a set of flags
-that may be used by the front end. They are accessed using
-`TREE_LANG_FLAG_n' where `n' is currently 0 through 6.
-
- If necessary, a front end can use some language-dependent tree codes
-in its GENERIC representation, so long as it provides a hook for
-converting them to GIMPLE and doesn't expect them to work with any
-(hypothetical) optimizers that run before the conversion to GIMPLE. The
-intermediate representation used while parsing C and C++ looks very
-little like GENERIC, but the C and C++ gimplifier hooks are perfectly
-happy to take it as input and spit out GIMPLE.
-
-
-File: gccint.info, Node: C and C++ Trees, Next: Java Trees, Prev: Language-dependent trees, Up: GENERIC
-
-11.10 C and C++ Trees
-=====================
-
-This section documents the internal representation used by GCC to
-represent C and C++ source programs. When presented with a C or C++
-source program, GCC parses the program, performs semantic analysis
-(including the generation of error messages), and then produces the
-internal representation described here. This representation contains a
-complete representation for the entire translation unit provided as
-input to the front end. This representation is then typically processed
-by a code-generator in order to produce machine code, but could also be
-used in the creation of source browsers, intelligent editors, automatic
-documentation generators, interpreters, and any other programs needing
-the ability to process C or C++ code.
-
- This section explains the internal representation. In particular, it
-documents the internal representation for C and C++ source constructs,
-and the macros, functions, and variables that can be used to access
-these constructs. The C++ representation is largely a superset of the
-representation used in the C front end. There is only one construct
-used in C that does not appear in the C++ front end and that is the GNU
-"nested function" extension. Many of the macros documented here do not
-apply in C because the corresponding language constructs do not appear
-in C.
-
- The C and C++ front ends generate a mix of GENERIC trees and ones
-specific to C and C++. These language-specific trees are higher-level
-constructs than the ones in GENERIC to make the parser's job easier.
-This section describes those trees that aren't part of GENERIC as well
-as aspects of GENERIC trees that are treated in a language-specific
-manner.
-
- If you are developing a "back end", be it is a code-generator or some
-other tool, that uses this representation, you may occasionally find
-that you need to ask questions not easily answered by the functions and
-macros available here. If that situation occurs, it is quite likely
-that GCC already supports the functionality you desire, but that the
-interface is simply not documented here. In that case, you should ask
-the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting
-the functionality you require. Similarly, if you find yourself writing
-functions that do not deal directly with your back end, but instead
-might be useful to other people using the GCC front end, you should
-submit your patches for inclusion in GCC.
-
-* Menu:
-
-* Types for C++:: Fundamental and aggregate types.
-* Namespaces:: Namespaces.
-* Classes:: Classes.
-* Functions for C++:: Overloading and accessors for C++.
-* Statements for C++:: Statements specific to C and C++.
-* C++ Expressions:: From `typeid' to `throw'.
-
-
-File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees
-
-11.10.1 Types for C++
----------------------
-
-In C++, an array type is not qualified; rather the type of the array
-elements is qualified. This situation is reflected in the intermediate
-representation. The macros described here will always examine the
-qualification of the underlying element type when applied to an array
-type. (If the element type is itself an array, then the recursion
-continues until a non-array type is found, and the qualification of this
-type is examined.) So, for example, `CP_TYPE_CONST_P' will hold of the
-type `const int ()[7]', denoting an array of seven `int's.
-
- The following functions and macros deal with cv-qualification of types:
-`CP_TYPE_QUALS'
- This macro returns the set of type qualifiers applied to this type.
- This value is `TYPE_UNQUALIFIED' if no qualifiers have been
- applied. The `TYPE_QUAL_CONST' bit is set if the type is
- `const'-qualified. The `TYPE_QUAL_VOLATILE' bit is set if the
- type is `volatile'-qualified. The `TYPE_QUAL_RESTRICT' bit is set
- if the type is `restrict'-qualified.
-
-`CP_TYPE_CONST_P'
- This macro holds if the type is `const'-qualified.
-
-`CP_TYPE_VOLATILE_P'
- This macro holds if the type is `volatile'-qualified.
-
-`CP_TYPE_RESTRICT_P'
- This macro holds if the type is `restrict'-qualified.
-
-`CP_TYPE_CONST_NON_VOLATILE_P'
- This predicate holds for a type that is `const'-qualified, but
- _not_ `volatile'-qualified; other cv-qualifiers are ignored as
- well: only the `const'-ness is tested.
-
-
- A few other macros and functions are usable with all types:
-`TYPE_SIZE'
- The number of bits required to represent the type, represented as
- an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be
- `NULL_TREE'.
-
-`TYPE_ALIGN'
- The alignment of the type, in bits, represented as an `int'.
-
-`TYPE_NAME'
- This macro returns a declaration (in the form of a `TYPE_DECL') for
- the type. (Note this macro does _not_ return an
- `IDENTIFIER_NODE', as you might expect, given its name!) You can
- look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual
- name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type
- that is not a built-in type, the result of a typedef, or a named
- class type.
-
-`CP_INTEGRAL_TYPE'
- This predicate holds if the type is an integral type. Notice that
- in C++, enumerations are _not_ integral types.
-
-`ARITHMETIC_TYPE_P'
- This predicate holds if the type is an integral type (in the C++
- sense) or a floating point type.
-
-`CLASS_TYPE_P'
- This predicate holds for a class-type.
-
-`TYPE_BUILT_IN'
- This predicate holds for a built-in type.
-
-`TYPE_PTRMEM_P'
- This predicate holds if the type is a pointer to data member.
-
-`TYPE_PTR_P'
- This predicate holds if the type is a pointer type, and the
- pointee is not a data member.
-
-`TYPE_PTRFN_P'
- This predicate holds for a pointer to function type.
-
-`TYPE_PTROB_P'
- This predicate holds for a pointer to object type. Note however
- that it does not hold for the generic pointer to object type `void
- *'. You may use `TYPE_PTROBV_P' to test for a pointer to object
- type as well as `void *'.
-
-
- The table below describes types specific to C and C++ as well as
-language-dependent info about GENERIC types.
-
-`POINTER_TYPE'
- Used to represent pointer types, and pointer to data member types.
- If `TREE_TYPE' is a pointer to data member type, then
- `TYPE_PTRMEM_P' will hold. For a pointer to data member type of
- the form `T X::*', `TYPE_PTRMEM_CLASS_TYPE' will be the type `X',
- while `TYPE_PTRMEM_POINTED_TO_TYPE' will be the type `T'.
-
-`RECORD_TYPE'
- Used to represent `struct' and `class' types in C and C++. If
- `TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member
- type. In that case, the `TYPE_PTRMEMFUNC_FN_TYPE' is a
- `POINTER_TYPE' pointing to a `METHOD_TYPE'. The `METHOD_TYPE' is
- the type of a function pointed to by the pointer-to-member
- function. If `TYPE_PTRMEMFUNC_P' does not hold, this type is a
- class type. For more information, *note Classes::.
-
-`UNKNOWN_TYPE'
- This node is used to represent a type the knowledge of which is
- insufficient for a sound processing.
-
-`TYPENAME_TYPE'
- Used to represent a construct of the form `typename T::A'. The
- `TYPE_CONTEXT' is `T'; the `TYPE_NAME' is an `IDENTIFIER_NODE' for
- `A'. If the type is specified via a template-id, then
- `TYPENAME_TYPE_FULLNAME' yields a `TEMPLATE_ID_EXPR'. The
- `TREE_TYPE' is non-`NULL' if the node is implicitly generated in
- support for the implicit typename extension; in which case the
- `TREE_TYPE' is a type node for the base-class.
-
-`TYPEOF_TYPE'
- Used to represent the `__typeof__' extension. The `TYPE_FIELDS'
- is the expression the type of which is being represented.
-
-
-
-File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees
-
-11.10.2 Namespaces
-------------------
-
-The root of the entire intermediate representation is the variable
-`global_namespace'. This is the namespace specified with `::' in C++
-source code. All other namespaces, types, variables, functions, and so
-forth can be found starting with this namespace.
-
- However, except for the fact that it is distinguished as the root of
-the representation, the global namespace is no different from any other
-namespace. Thus, in what follows, we describe namespaces generally,
-rather than the global namespace in particular.
-
- A namespace is represented by a `NAMESPACE_DECL' node.
-
- The following macros and functions can be used on a `NAMESPACE_DECL':
-
-`DECL_NAME'
- This macro is used to obtain the `IDENTIFIER_NODE' corresponding to
- the unqualified name of the name of the namespace (*note
- Identifiers::). The name of the global namespace is `::', even
- though in C++ the global namespace is unnamed. However, you
- should use comparison with `global_namespace', rather than
- `DECL_NAME' to determine whether or not a namespace is the global
- one. An unnamed namespace will have a `DECL_NAME' equal to
- `anonymous_namespace_name'. Within a single translation unit, all
- unnamed namespaces will have the same name.
-
-`DECL_CONTEXT'
- This macro returns the enclosing namespace. The `DECL_CONTEXT' for
- the `global_namespace' is `NULL_TREE'.
-
-`DECL_NAMESPACE_ALIAS'
- If this declaration is for a namespace alias, then
- `DECL_NAMESPACE_ALIAS' is the namespace for which this one is an
- alias.
-
- Do not attempt to use `cp_namespace_decls' for a namespace which is
- an alias. Instead, follow `DECL_NAMESPACE_ALIAS' links until you
- reach an ordinary, non-alias, namespace, and call
- `cp_namespace_decls' there.
-
-`DECL_NAMESPACE_STD_P'
- This predicate holds if the namespace is the special `::std'
- namespace.
-
-`cp_namespace_decls'
- This function will return the declarations contained in the
- namespace, including types, overloaded functions, other
- namespaces, and so forth. If there are no declarations, this
- function will return `NULL_TREE'. The declarations are connected
- through their `TREE_CHAIN' fields.
-
- Although most entries on this list will be declarations,
- `TREE_LIST' nodes may also appear. In this case, the `TREE_VALUE'
- will be an `OVERLOAD'. The value of the `TREE_PURPOSE' is
- unspecified; back ends should ignore this value. As with the
- other kinds of declarations returned by `cp_namespace_decls', the
- `TREE_CHAIN' will point to the next declaration in this list.
-
- For more information on the kinds of declarations that can occur
- on this list, *Note Declarations::. Some declarations will not
- appear on this list. In particular, no `FIELD_DECL',
- `LABEL_DECL', or `PARM_DECL' nodes will appear here.
-
- This function cannot be used with namespaces that have
- `DECL_NAMESPACE_ALIAS' set.
-
-
-
-File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees
-
-11.10.3 Classes
----------------
-
-Besides namespaces, the other high-level scoping construct in C++ is the
-class. (Throughout this manual the term "class" is used to mean the
-types referred to in the ANSI/ISO C++ Standard as classes; these include
-types defined with the `class', `struct', and `union' keywords.)
-
- A class type is represented by either a `RECORD_TYPE' or a
-`UNION_TYPE'. A class declared with the `union' tag is represented by
-a `UNION_TYPE', while classes declared with either the `struct' or the
-`class' tag are represented by `RECORD_TYPE's. You can use the
-`CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular
-type is a `class' as opposed to a `struct'. This macro will be true
-only for classes declared with the `class' tag.
-
- Almost all non-function members are available on the `TYPE_FIELDS'
-list. Given one member, the next can be found by following the
-`TREE_CHAIN'. You should not depend in any way on the order in which
-fields appear on this list. All nodes on this list will be `DECL'
-nodes. A `FIELD_DECL' is used to represent a non-static data member, a
-`VAR_DECL' is used to represent a static data member, and a `TYPE_DECL'
-is used to represent a type. Note that the `CONST_DECL' for an
-enumeration constant will appear on this list, if the enumeration type
-was declared in the class. (Of course, the `TYPE_DECL' for the
-enumeration type will appear here as well.) There are no entries for
-base classes on this list. In particular, there is no `FIELD_DECL' for
-the "base-class portion" of an object.
-
- The `TYPE_VFIELD' is a compiler-generated field used to point to
-virtual function tables. It may or may not appear on the `TYPE_FIELDS'
-list. However, back ends should handle the `TYPE_VFIELD' just like all
-the entries on the `TYPE_FIELDS' list.
-
- The function members are available on the `TYPE_METHODS' list. Again,
-subsequent members are found by following the `TREE_CHAIN' field. If a
-function is overloaded, each of the overloaded functions appears; no
-`OVERLOAD' nodes appear on the `TYPE_METHODS' list. Implicitly
-declared functions (including default constructors, copy constructors,
-assignment operators, and destructors) will appear on this list as well.
-
- Every class has an associated "binfo", which can be obtained with
-`TYPE_BINFO'. Binfos are used to represent base-classes. The binfo
-given by `TYPE_BINFO' is the degenerate case, whereby every class is
-considered to be its own base-class. The base binfos for a particular
-binfo are held in a vector, whose length is obtained with
-`BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with
-`BINFO_BASE_BINFO' and `BINFO_BASE_ITERATE'. To add a new binfo, use
-`BINFO_BASE_APPEND'. The vector of base binfos can be obtained with
-`BINFO_BASE_BINFOS', but normally you do not need to use that. The
-class type associated with a binfo is given by `BINFO_TYPE'. It is not
-always the case that `BINFO_TYPE (TYPE_BINFO (x))', because of typedefs
-and qualified types. Neither is it the case that `TYPE_BINFO
-(BINFO_TYPE (y))' is the same binfo as `y'. The reason is that if `y'
-is a binfo representing a base-class `B' of a derived class `D', then
-`BINFO_TYPE (y)' will be `B', and `TYPE_BINFO (BINFO_TYPE (y))' will be
-`B' as its own base-class, rather than as a base-class of `D'.
-
- The access to a base type can be found with `BINFO_BASE_ACCESS'. This
-will produce `access_public_node', `access_private_node' or
-`access_protected_node'. If bases are always public,
-`BINFO_BASE_ACCESSES' may be `NULL'.
-
- `BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited
-virtually or not. The other flags, `BINFO_MARKED_P' and `BINFO_FLAG_1'
-to `BINFO_FLAG_6' can be used for language specific use.
-
- The following macros can be used on a tree node representing a
-class-type.
-
-`LOCAL_CLASS_P'
- This predicate holds if the class is local class _i.e._ declared
- inside a function body.
-
-`TYPE_POLYMORPHIC_P'
- This predicate holds if the class has at least one virtual function
- (declared or inherited).
-
-`TYPE_HAS_DEFAULT_CONSTRUCTOR'
- This predicate holds whenever its argument represents a class-type
- with default constructor.
-
-`CLASSTYPE_HAS_MUTABLE'
-`TYPE_HAS_MUTABLE_P'
- These predicates hold for a class-type having a mutable data
- member.
-
-`CLASSTYPE_NON_POD_P'
- This predicate holds only for class-types that are not PODs.
-
-`TYPE_HAS_NEW_OPERATOR'
- This predicate holds for a class-type that defines `operator new'.
-
-`TYPE_HAS_ARRAY_NEW_OPERATOR'
- This predicate holds for a class-type for which `operator new[]'
- is defined.
-
-`TYPE_OVERLOADS_CALL_EXPR'
- This predicate holds for class-type for which the function call
- `operator()' is overloaded.
-
-`TYPE_OVERLOADS_ARRAY_REF'
- This predicate holds for a class-type that overloads `operator[]'
-
-`TYPE_OVERLOADS_ARROW'
- This predicate holds for a class-type for which `operator->' is
- overloaded.
-
-
-
-File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees
-
-11.10.4 Functions for C++
--------------------------
-
-A function is represented by a `FUNCTION_DECL' node. A set of
-overloaded functions is sometimes represented by an `OVERLOAD' node.
-
- An `OVERLOAD' node is not a declaration, so none of the `DECL_' macros
-should be used on an `OVERLOAD'. An `OVERLOAD' node is similar to a
-`TREE_LIST'. Use `OVL_CURRENT' to get the function associated with an
-`OVERLOAD' node; use `OVL_NEXT' to get the next `OVERLOAD' node in the
-list of overloaded functions. The macros `OVL_CURRENT' and `OVL_NEXT'
-are actually polymorphic; you can use them to work with `FUNCTION_DECL'
-nodes as well as with overloads. In the case of a `FUNCTION_DECL',
-`OVL_CURRENT' will always return the function itself, and `OVL_NEXT'
-will always be `NULL_TREE'.
-
- To determine the scope of a function, you can use the `DECL_CONTEXT'
-macro. This macro will return the class (either a `RECORD_TYPE' or a
-`UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function
-is a member. For a virtual function, this macro returns the class in
-which the function was actually defined, not the base class in which
-the virtual declaration occurred.
-
- If a friend function is defined in a class scope, the
-`DECL_FRIEND_CONTEXT' macro can be used to determine the class in which
-it was defined. For example, in
- class C { friend void f() {} };
- the `DECL_CONTEXT' for `f' will be the `global_namespace', but the
-`DECL_FRIEND_CONTEXT' will be the `RECORD_TYPE' for `C'.
-
- The following macros and functions can be used on a `FUNCTION_DECL':
-`DECL_MAIN_P'
- This predicate holds for a function that is the program entry point
- `::code'.
-
-`DECL_LOCAL_FUNCTION_P'
- This predicate holds if the function was declared at block scope,
- even though it has a global scope.
-
-`DECL_ANTICIPATED'
- This predicate holds if the function is a built-in function but its
- prototype is not yet explicitly declared.
-
-`DECL_EXTERN_C_FUNCTION_P'
- This predicate holds if the function is declared as an ``extern
- "C"'' function.
-
-`DECL_LINKONCE_P'
- This macro holds if multiple copies of this function may be
- emitted in various translation units. It is the responsibility of
- the linker to merge the various copies. Template instantiations
- are the most common example of functions for which
- `DECL_LINKONCE_P' holds; G++ instantiates needed templates in all
- translation units which require them, and then relies on the
- linker to remove duplicate instantiations.
-
- FIXME: This macro is not yet implemented.
-
-`DECL_FUNCTION_MEMBER_P'
- This macro holds if the function is a member of a class, rather
- than a member of a namespace.
-
-`DECL_STATIC_FUNCTION_P'
- This predicate holds if the function a static member function.
-
-`DECL_NONSTATIC_MEMBER_FUNCTION_P'
- This macro holds for a non-static member function.
-
-`DECL_CONST_MEMFUNC_P'
- This predicate holds for a `const'-member function.
-
-`DECL_VOLATILE_MEMFUNC_P'
- This predicate holds for a `volatile'-member function.
-
-`DECL_CONSTRUCTOR_P'
- This macro holds if the function is a constructor.
-
-`DECL_NONCONVERTING_P'
- This predicate holds if the constructor is a non-converting
- constructor.
-
-`DECL_COMPLETE_CONSTRUCTOR_P'
- This predicate holds for a function which is a constructor for an
- object of a complete type.
-
-`DECL_BASE_CONSTRUCTOR_P'
- This predicate holds for a function which is a constructor for a
- base class sub-object.
-
-`DECL_COPY_CONSTRUCTOR_P'
- This predicate holds for a function which is a copy-constructor.
-
-`DECL_DESTRUCTOR_P'
- This macro holds if the function is a destructor.
-
-`DECL_COMPLETE_DESTRUCTOR_P'
- This predicate holds if the function is the destructor for an
- object a complete type.
-
-`DECL_OVERLOADED_OPERATOR_P'
- This macro holds if the function is an overloaded operator.
-
-`DECL_CONV_FN_P'
- This macro holds if the function is a type-conversion operator.
-
-`DECL_GLOBAL_CTOR_P'
- This predicate holds if the function is a file-scope initialization
- function.
-
-`DECL_GLOBAL_DTOR_P'
- This predicate holds if the function is a file-scope finalization
- function.
-
-`DECL_THUNK_P'
- This predicate holds if the function is a thunk.
-
- These functions represent stub code that adjusts the `this' pointer
- and then jumps to another function. When the jumped-to function
- returns, control is transferred directly to the caller, without
- returning to the thunk. The first parameter to the thunk is
- always the `this' pointer; the thunk should add `THUNK_DELTA' to
- this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.)
-
- Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the
- adjusted `this' pointer must be adjusted again. The complete
- calculation is given by the following pseudo-code:
-
- this += THUNK_DELTA
- if (THUNK_VCALL_OFFSET)
- this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
-
- Finally, the thunk should jump to the location given by
- `DECL_INITIAL'; this will always be an expression for the address
- of a function.
-
-`DECL_NON_THUNK_FUNCTION_P'
- This predicate holds if the function is _not_ a thunk function.
-
-`GLOBAL_INIT_PRIORITY'
- If either `DECL_GLOBAL_CTOR_P' or `DECL_GLOBAL_DTOR_P' holds, then
- this gives the initialization priority for the function. The
- linker will arrange that all functions for which
- `DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority
- before `main' is called. When the program exits, all functions for
- which `DECL_GLOBAL_DTOR_P' holds are run in the reverse order.
-
-`TYPE_RAISES_EXCEPTIONS'
- This macro returns the list of exceptions that a (member-)function
- can raise. The returned list, if non `NULL', is comprised of nodes
- whose `TREE_VALUE' represents a type.
-
-`TYPE_NOTHROW_P'
- This predicate holds when the exception-specification of its
- arguments is of the form ``()''.
-
-`DECL_ARRAY_DELETE_OPERATOR_P'
- This predicate holds if the function an overloaded `operator
- delete[]'.
-
-
-
-File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees
-
-11.10.5 Statements for C++
---------------------------
-
-A function that has a definition in the current translation unit will
-have a non-`NULL' `DECL_INITIAL'. However, back ends should not make
-use of the particular value given by `DECL_INITIAL'.
-
- The `DECL_SAVED_TREE' macro will give the complete body of the
-function.
-
-11.10.5.1 Statements
-....................
-
-There are tree nodes corresponding to all of the source-level statement
-constructs, used within the C and C++ frontends. These are enumerated
-here, together with a list of the various macros that can be used to
-obtain information about them. There are a few macros that can be used
-with all statements:
-
-`STMT_IS_FULL_EXPR_P'
- In C++, statements normally constitute "full expressions";
- temporaries created during a statement are destroyed when the
- statement is complete. However, G++ sometimes represents
- expressions by statements; these statements will not have
- `STMT_IS_FULL_EXPR_P' set. Temporaries created during such
- statements should be destroyed when the innermost enclosing
- statement with `STMT_IS_FULL_EXPR_P' set is exited.
-
-
- Here is the list of the various statement nodes, and the macros used to
-access them. This documentation describes the use of these nodes in
-non-template functions (including instantiations of template functions).
-In template functions, the same nodes are used, but sometimes in
-slightly different ways.
-
- Many of the statements have substatements. For example, a `while'
-loop will have a body, which is itself a statement. If the substatement
-is `NULL_TREE', it is considered equivalent to a statement consisting
-of a single `;', i.e., an expression statement in which the expression
-has been omitted. A substatement may in fact be a list of statements,
-connected via their `TREE_CHAIN's. So, you should always process the
-statement tree by looping over substatements, like this:
- void process_stmt (stmt)
- tree stmt;
- {
- while (stmt)
- {
- switch (TREE_CODE (stmt))
- {
- case IF_STMT:
- process_stmt (THEN_CLAUSE (stmt));
- /* More processing here. */
- break;
-
- ...
- }
-
- stmt = TREE_CHAIN (stmt);
- }
- }
- In other words, while the `then' clause of an `if' statement in C++
-can be only one statement (although that one statement may be a
-compound statement), the intermediate representation will sometimes use
-several statements chained together.
-
-`BREAK_STMT'
- Used to represent a `break' statement. There are no additional
- fields.
-
-`CLEANUP_STMT'
- Used to represent an action that should take place upon exit from
- the enclosing scope. Typically, these actions are calls to
- destructors for local objects, but back ends cannot rely on this
- fact. If these nodes are in fact representing such destructors,
- `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise,
- `CLEANUP_DECL' will be `NULL_TREE'. In any case, the
- `CLEANUP_EXPR' is the expression to execute. The cleanups
- executed on exit from a scope should be run in the reverse order
- of the order in which the associated `CLEANUP_STMT's were
- encountered.
-
-`CONTINUE_STMT'
- Used to represent a `continue' statement. There are no additional
- fields.
-
-`CTOR_STMT'
- Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if
- `CTOR_END_P' holds of the main body of a constructor. See also
- `SUBOBJECT' for more information on how to use these nodes.
-
-`DO_STMT'
- Used to represent a `do' loop. The body of the loop is given by
- `DO_BODY' while the termination condition for the loop is given by
- `DO_COND'. The condition for a `do'-statement is always an
- expression.
-
-`EMPTY_CLASS_EXPR'
- Used to represent a temporary object of a class with no data whose
- address is never taken. (All such objects are interchangeable.)
- The `TREE_TYPE' represents the type of the object.
-
-`EXPR_STMT'
- Used to represent an expression statement. Use `EXPR_STMT_EXPR' to
- obtain the expression.
-
-`FOR_STMT'
- Used to represent a `for' statement. The `FOR_INIT_STMT' is the
- initialization statement for the loop. The `FOR_COND' is the
- termination condition. The `FOR_EXPR' is the expression executed
- right before the `FOR_COND' on each loop iteration; often, this
- expression increments a counter. The body of the loop is given by
- `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return
- statements, while `FOR_COND' and `FOR_EXPR' return expressions.
-
-`HANDLER'
- Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the
- type of exception that will be caught by this handler; it is equal
- (by pointer equality) to `NULL' if this handler is for all types.
- `HANDLER_PARMS' is the `DECL_STMT' for the catch parameter, and
- `HANDLER_BODY' is the code for the block itself.
-
-`IF_STMT'
- Used to represent an `if' statement. The `IF_COND' is the
- expression.
-
- If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a
- statement (usually a `DECL_STMT'). Each time the condition is
- evaluated, the statement should be executed. Then, the
- `TREE_VALUE' should be used as the conditional expression itself.
- This representation is used to handle C++ code like this:
-
- C++ distinguishes between this and `COND_EXPR' for handling
- templates.
-
- if (int i = 7) ...
-
- where there is a new local variable (or variables) declared within
- the condition.
-
- The `THEN_CLAUSE' represents the statement given by the `then'
- condition, while the `ELSE_CLAUSE' represents the statement given
- by the `else' condition.
-
-`SUBOBJECT'
- In a constructor, these nodes are used to mark the point at which a
- subobject of `this' is fully constructed. If, after this point, an
- exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is
- encountered, the `SUBOBJECT_CLEANUP' must be executed. The
- cleanups must be executed in the reverse order in which they
- appear.
-
-`SWITCH_STMT'
- Used to represent a `switch' statement. The `SWITCH_STMT_COND' is
- the expression on which the switch is occurring. See the
- documentation for an `IF_STMT' for more information on the
- representation used for the condition. The `SWITCH_STMT_BODY' is
- the body of the switch statement. The `SWITCH_STMT_TYPE' is the
- original type of switch expression as given in the source, before
- any compiler conversions.
-
-`TRY_BLOCK'
- Used to represent a `try' block. The body of the try block is
- given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER'
- node. The first handler is given by `TRY_HANDLERS'. Subsequent
- handlers are obtained by following the `TREE_CHAIN' link from one
- handler to the next. The body of the handler is given by
- `HANDLER_BODY'.
-
- If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS'
- will not be a `HANDLER' node. Instead, it will be an expression
- that should be executed if an exception is thrown in the try
- block. It must rethrow the exception after executing that code.
- And, if an exception is thrown while the expression is executing,
- `terminate' must be called.
-
-`USING_STMT'
- Used to represent a `using' directive. The namespace is given by
- `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node
- is needed inside template functions, to implement using directives
- during instantiation.
-
-`WHILE_STMT'
- Used to represent a `while' loop. The `WHILE_COND' is the
- termination condition for the loop. See the documentation for an
- `IF_STMT' for more information on the representation used for the
- condition.
-
- The `WHILE_BODY' is the body of the loop.
-
-
-
-File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees
-
-11.10.6 C++ Expressions
------------------------
-
-This section describes expressions specific to the C and C++ front ends.
-
-`TYPEID_EXPR'
- Used to represent a `typeid' expression.
-
-`NEW_EXPR'
-`VEC_NEW_EXPR'
- Used to represent a call to `new' and `new[]' respectively.
-
-`DELETE_EXPR'
-`VEC_DELETE_EXPR'
- Used to represent a call to `delete' and `delete[]' respectively.
-
-`MEMBER_REF'
- Represents a reference to a member of a class.
-
-`THROW_EXPR'
- Represents an instance of `throw' in the program. Operand 0,
- which is the expression to throw, may be `NULL_TREE'.
-
-`AGGR_INIT_EXPR'
- An `AGGR_INIT_EXPR' represents the initialization as the return
- value of a function call, or as the result of a constructor. An
- `AGGR_INIT_EXPR' will only appear as a full-expression, or as the
- second operand of a `TARGET_EXPR'. `AGGR_INIT_EXPR's have a
- representation similar to that of `CALL_EXPR's. You can use the
- `AGGR_INIT_EXPR_FN' and `AGGR_INIT_EXPR_ARG' macros to access the
- function to call and the arguments to pass.
-
- If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the
- initialization is via a constructor call. The address of the
- `AGGR_INIT_EXPR_SLOT' operand, which is always a `VAR_DECL', is
- taken, and this value replaces the first argument in the argument
- list.
-
- In either case, the expression is void.
-
-
-
-File: gccint.info, Node: Java Trees, Prev: C and C++ Trees, Up: GENERIC
-
-11.11 Java Trees
-================
-
-
-File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top
-
-12 GIMPLE
-*********
-
-GIMPLE is a three-address representation derived from GENERIC by
-breaking down GENERIC expressions into tuples of no more than 3
-operands (with some exceptions like function calls). GIMPLE was
-heavily influenced by the SIMPLE IL used by the McCAT compiler project
-at McGill University, though we have made some different choices. For
-one thing, SIMPLE doesn't support `goto'.
-
- Temporaries are introduced to hold intermediate values needed to
-compute complex expressions. Additionally, all the control structures
-used in GENERIC are lowered into conditional jumps, lexical scopes are
-removed and exception regions are converted into an on the side
-exception region tree.
-
- The compiler pass which converts GENERIC into GIMPLE is referred to as
-the `gimplifier'. The gimplifier works recursively, generating GIMPLE
-tuples out of the original GENERIC expressions.
-
- One of the early implementation strategies used for the GIMPLE
-representation was to use the same internal data structures used by
-front ends to represent parse trees. This simplified implementation
-because we could leverage existing functionality and interfaces.
-However, GIMPLE is a much more restrictive representation than abstract
-syntax trees (AST), therefore it does not require the full structural
-complexity provided by the main tree data structure.
-
- The GENERIC representation of a function is stored in the
-`DECL_SAVED_TREE' field of the associated `FUNCTION_DECL' tree node.
-It is converted to GIMPLE by a call to `gimplify_function_tree'.
-
- If a front end wants to include language-specific tree codes in the
-tree representation which it provides to the back end, it must provide a
-definition of `LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the
-front end trees to GIMPLE. Usually such a hook will involve much of
-the same code for expanding front end trees to RTL. This function can
-return fully lowered GIMPLE, or it can return GENERIC trees and let the
-main gimplifier lower them the rest of the way; this is often simpler.
-GIMPLE that is not fully lowered is known as "High GIMPLE" and consists
-of the IL before the pass `pass_lower_cf'. High GIMPLE contains some
-container statements like lexical scopes (represented by `GIMPLE_BIND')
-and nested expressions (e.g., `GIMPLE_TRY'), while "Low GIMPLE" exposes
-all of the implicit jumps for control and exception expressions
-directly in the IL and EH region trees.
-
- The C and C++ front ends currently convert directly from front end
-trees to GIMPLE, and hand that off to the back end rather than first
-converting to GENERIC. Their gimplifier hooks know about all the
-`_STMT' nodes and how to convert them to GENERIC forms. There was some
-work done on a genericization pass which would run first, but the
-existence of `STMT_EXPR' meant that in order to convert all of the C
-statements into GENERIC equivalents would involve walking the entire
-tree anyway, so it was simpler to lower all the way. This might change
-in the future if someone writes an optimization pass which would work
-better with higher-level trees, but currently the optimizers all expect
-GIMPLE.
-
- You can request to dump a C-like representation of the GIMPLE form
-with the flag `-fdump-tree-gimple'.
-
-* Menu:
-
-* Tuple representation::
-* GIMPLE instruction set::
-* GIMPLE Exception Handling::
-* Temporaries::
-* Operands::
-* Manipulating GIMPLE statements::
-* Tuple specific accessors::
-* GIMPLE sequences::
-* Sequence iterators::
-* Adding a new GIMPLE statement code::
-* Statement and operand traversals::
-
-
-File: gccint.info, Node: Tuple representation, Next: GIMPLE instruction set, Up: GIMPLE
-
-12.1 Tuple representation
-=========================
-
-GIMPLE instructions are tuples of variable size divided in two groups:
-a header describing the instruction and its locations, and a variable
-length body with all the operands. Tuples are organized into a
-hierarchy with 3 main classes of tuples.
-
-12.1.1 `gimple_statement_base' (gsbase)
----------------------------------------
-
-This is the root of the hierarchy, it holds basic information needed by
-most GIMPLE statements. There are some fields that may not be relevant
-to every GIMPLE statement, but those were moved into the base structure
-to take advantage of holes left by other fields (thus making the
-structure more compact). The structure takes 4 words (32 bytes) on 64
-bit hosts:
-
-Field Size (bits)
-`code' 8
-`subcode' 16
-`no_warning' 1
-`visited' 1
-`nontemporal_move' 1
-`plf' 2
-`modified' 1
-`has_volatile_ops' 1
-`references_memory_p' 1
-`uid' 32
-`location' 32
-`num_ops' 32
-`bb' 64
-`block' 63
-Total size 32 bytes
-
- * `code' Main identifier for a GIMPLE instruction.
-
- * `subcode' Used to distinguish different variants of the same basic
- instruction or provide flags applicable to a given code. The
- `subcode' flags field has different uses depending on the code of
- the instruction, but mostly it distinguishes instructions of the
- same family. The most prominent use of this field is in
- assignments, where subcode indicates the operation done on the RHS
- of the assignment. For example, a = b + c is encoded as
- `GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'.
-
- * `no_warning' Bitflag to indicate whether a warning has already
- been issued on this statement.
-
- * `visited' General purpose "visited" marker. Set and cleared by
- each pass when needed.
-
- * `nontemporal_move' Bitflag used in assignments that represent
- non-temporal moves. Although this bitflag is only used in
- assignments, it was moved into the base to take advantage of the
- bit holes left by the previous fields.
-
- * `plf' Pass Local Flags. This 2-bit mask can be used as general
- purpose markers by any pass. Passes are responsible for clearing
- and setting these two flags accordingly.
-
- * `modified' Bitflag to indicate whether the statement has been
- modified. Used mainly by the operand scanner to determine when to
- re-scan a statement for operands.
-
- * `has_volatile_ops' Bitflag to indicate whether this statement
- contains operands that have been marked volatile.
-
- * `references_memory_p' Bitflag to indicate whether this statement
- contains memory references (i.e., its operands are either global
- variables, or pointer dereferences or anything that must reside in
- memory).
-
- * `uid' This is an unsigned integer used by passes that want to
- assign IDs to every statement. These IDs must be assigned and used
- by each pass.
-
- * `location' This is a `location_t' identifier to specify source code
- location for this statement. It is inherited from the front end.
-
- * `num_ops' Number of operands that this statement has. This
- specifies the size of the operand vector embedded in the tuple.
- Only used in some tuples, but it is declared in the base tuple to
- take advantage of the 32-bit hole left by the previous fields.
-
- * `bb' Basic block holding the instruction.
-
- * `block' Lexical block holding this statement. Also used for debug
- information generation.
-
-12.1.2 `gimple_statement_with_ops'
-----------------------------------
-
-This tuple is actually split in two: `gimple_statement_with_ops_base'
-and `gimple_statement_with_ops'. This is needed to accommodate the way
-the operand vector is allocated. The operand vector is defined to be an
-array of 1 element. So, to allocate a dynamic number of operands, the
-memory allocator (`gimple_alloc') simply allocates enough memory to
-hold the structure itself plus `N - 1' operands which run "off the end"
-of the structure. For example, to allocate space for a tuple with 3
-operands, `gimple_alloc' reserves `sizeof (struct
-gimple_statement_with_ops) + 2 * sizeof (tree)' bytes.
-
- On the other hand, several fields in this tuple need to be shared with
-the `gimple_statement_with_memory_ops' tuple. So, these common fields
-are placed in `gimple_statement_with_ops_base' which is then inherited
-from the other two tuples.
-
-`gsbase' 256
-`def_ops' 64
-`use_ops' 64
-`op' `num_ops' * 64
-Total size 48 + 8 * `num_ops' bytes
-
- * `gsbase' Inherited from `struct gimple_statement_base'.
-
- * `def_ops' Array of pointers into the operand array indicating all
- the slots that contain a variable written-to by the statement.
- This array is also used for immediate use chaining. Note that it
- would be possible to not rely on this array, but the changes
- required to implement this are pretty invasive.
-
- * `use_ops' Similar to `def_ops' but for variables read by the
- statement.
-
- * `op' Array of trees with `num_ops' slots.
-
-12.1.3 `gimple_statement_with_memory_ops'
------------------------------------------
-
-This tuple is essentially identical to `gimple_statement_with_ops',
-except that it contains 4 additional fields to hold vectors related
-memory stores and loads. Similar to the previous case, the structure
-is split in two to accommodate for the operand vector
-(`gimple_statement_with_memory_ops_base' and
-`gimple_statement_with_memory_ops').
-
-Field Size (bits)
-`gsbase' 256
-`def_ops' 64
-`use_ops' 64
-`vdef_ops' 64
-`vuse_ops' 64
-`stores' 64
-`loads' 64
-`op' `num_ops' * 64
-Total size 80 + 8 * `num_ops' bytes
-
- * `vdef_ops' Similar to `def_ops' but for `VDEF' operators. There is
- one entry per memory symbol written by this statement. This is
- used to maintain the memory SSA use-def and def-def chains.
-
- * `vuse_ops' Similar to `use_ops' but for `VUSE' operators. There is
- one entry per memory symbol loaded by this statement. This is used
- to maintain the memory SSA use-def chains.
-
- * `stores' Bitset with all the UIDs for the symbols written-to by the
- statement. This is different than `vdef_ops' in that all the
- affected symbols are mentioned in this set. If memory
- partitioning is enabled, the `vdef_ops' vector will refer to memory
- partitions. Furthermore, no SSA information is stored in this set.
-
- * `loads' Similar to `stores', but for memory loads. (Note that there
- is some amount of redundancy here, it should be possible to reduce
- memory utilization further by removing these sets).
-
- All the other tuples are defined in terms of these three basic ones.
-Each tuple will add some fields. The main gimple type is defined to be
-the union of all these structures (`GTY' markers elided for clarity):
-
- union gimple_statement_d
- {
- struct gimple_statement_base gsbase;
- struct gimple_statement_with_ops gsops;
- struct gimple_statement_with_memory_ops gsmem;
- struct gimple_statement_omp omp;
- struct gimple_statement_bind gimple_bind;
- struct gimple_statement_catch gimple_catch;
- struct gimple_statement_eh_filter gimple_eh_filter;
- struct gimple_statement_phi gimple_phi;
- struct gimple_statement_resx gimple_resx;
- struct gimple_statement_try gimple_try;
- struct gimple_statement_wce gimple_wce;
- struct gimple_statement_asm gimple_asm;
- struct gimple_statement_omp_critical gimple_omp_critical;
- struct gimple_statement_omp_for gimple_omp_for;
- struct gimple_statement_omp_parallel gimple_omp_parallel;
- struct gimple_statement_omp_task gimple_omp_task;
- struct gimple_statement_omp_sections gimple_omp_sections;
- struct gimple_statement_omp_single gimple_omp_single;
- struct gimple_statement_omp_continue gimple_omp_continue;
- struct gimple_statement_omp_atomic_load gimple_omp_atomic_load;
- struct gimple_statement_omp_atomic_store gimple_omp_atomic_store;
- };
-
-
-File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Tuple representation, Up: GIMPLE
-
-12.2 GIMPLE instruction set
-===========================
-
-The following table briefly describes the GIMPLE instruction set.
-
-Instruction High GIMPLE Low GIMPLE
-`GIMPLE_ASM' x x
-`GIMPLE_ASSIGN' x x
-`GIMPLE_BIND' x
-`GIMPLE_CALL' x x
-`GIMPLE_CATCH' x
-`GIMPLE_COND' x x
-`GIMPLE_DEBUG' x x
-`GIMPLE_EH_FILTER' x
-`GIMPLE_GOTO' x x
-`GIMPLE_LABEL' x x
-`GIMPLE_NOP' x x
-`GIMPLE_OMP_ATOMIC_LOAD' x x
-`GIMPLE_OMP_ATOMIC_STORE' x x
-`GIMPLE_OMP_CONTINUE' x x
-`GIMPLE_OMP_CRITICAL' x x
-`GIMPLE_OMP_FOR' x x
-`GIMPLE_OMP_MASTER' x x
-`GIMPLE_OMP_ORDERED' x x
-`GIMPLE_OMP_PARALLEL' x x
-`GIMPLE_OMP_RETURN' x x
-`GIMPLE_OMP_SECTION' x x
-`GIMPLE_OMP_SECTIONS' x x
-`GIMPLE_OMP_SECTIONS_SWITCH' x x
-`GIMPLE_OMP_SINGLE' x x
-`GIMPLE_PHI' x
-`GIMPLE_RESX' x
-`GIMPLE_RETURN' x x
-`GIMPLE_SWITCH' x x
-`GIMPLE_TRY' x
-
-
-File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE
-
-12.3 Exception Handling
-=======================
-
-Other exception handling constructs are represented using
-`GIMPLE_TRY_CATCH'. `GIMPLE_TRY_CATCH' has two operands. The first
-operand is a sequence of statements to execute. If executing these
-statements does not throw an exception, then the second operand is
-ignored. Otherwise, if an exception is thrown, then the second operand
-of the `GIMPLE_TRY_CATCH' is checked. The second operand may have the
-following forms:
-
- 1. A sequence of statements to execute. When an exception occurs,
- these statements are executed, and then the exception is rethrown.
-
- 2. A sequence of `GIMPLE_CATCH' statements. Each `GIMPLE_CATCH' has
- a list of applicable exception types and handler code. If the
- thrown exception matches one of the caught types, the associated
- handler code is executed. If the handler code falls off the
- bottom, execution continues after the original `GIMPLE_TRY_CATCH'.
-
- 3. A `GIMPLE_EH_FILTER' statement. This has a list of permitted
- exception types, and code to handle a match failure. If the
- thrown exception does not match one of the allowed types, the
- associated match failure code is executed. If the thrown exception
- does match, it continues unwinding the stack looking for the next
- handler.
-
-
- Currently throwing an exception is not directly represented in GIMPLE,
-since it is implemented by calling a function. At some point in the
-future we will want to add some way to express that the call will throw
-an exception of a known type.
-
- Just before running the optimizers, the compiler lowers the high-level
-EH constructs above into a set of `goto's, magic labels, and EH
-regions. Continuing to unwind at the end of a cleanup is represented
-with a `GIMPLE_RESX'.
-
-
-File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE
-
-12.4 Temporaries
-================
-
-When gimplification encounters a subexpression that is too complex, it
-creates a new temporary variable to hold the value of the
-subexpression, and adds a new statement to initialize it before the
-current statement. These special temporaries are known as `expression
-temporaries', and are allocated using `get_formal_tmp_var'. The
-compiler tries to always evaluate identical expressions into the same
-temporary, to simplify elimination of redundant calculations.
-
- We can only use expression temporaries when we know that it will not
-be reevaluated before its value is used, and that it will not be
-otherwise modified(1). Other temporaries can be allocated using
-`get_initialized_tmp_var' or `create_tmp_var'.
-
- Currently, an expression like `a = b + 5' is not reduced any further.
-We tried converting it to something like
- T1 = b + 5;
- a = T1;
- but this bloated the representation for minimal benefit. However, a
-variable which must live in memory cannot appear in an expression; its
-value is explicitly loaded into a temporary first. Similarly, storing
-the value of an expression to a memory variable goes through a
-temporary.
-
- ---------- Footnotes ----------
-
- (1) These restrictions are derived from those in Morgan 4.8.
-
-
-File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE
-
-12.5 Operands
-=============
-
-In general, expressions in GIMPLE consist of an operation and the
-appropriate number of simple operands; these operands must either be a
-GIMPLE rvalue (`is_gimple_val'), i.e. a constant or a register
-variable. More complex operands are factored out into temporaries, so
-that
- a = b + c + d
- becomes
- T1 = b + c;
- a = T1 + d;
-
- The same rule holds for arguments to a `GIMPLE_CALL'.
-
- The target of an assignment is usually a variable, but can also be a
-`MEM_REF' or a compound lvalue as described below.
-
-* Menu:
-
-* Compound Expressions::
-* Compound Lvalues::
-* Conditional Expressions::
-* Logical Operators::
-
-
-File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands
-
-12.5.1 Compound Expressions
----------------------------
-
-The left-hand side of a C comma expression is simply moved into a
-separate statement.
-
-
-File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands
-
-12.5.2 Compound Lvalues
------------------------
-
-Currently compound lvalues involving array and structure field
-references are not broken down; an expression like `a.b[2] = 42' is not
-reduced any further (though complex array subscripts are). This
-restriction is a workaround for limitations in later optimizers; if we
-were to convert this to
-
- T1 = &a.b;
- T1[2] = 42;
-
- alias analysis would not remember that the reference to `T1[2]' came
-by way of `a.b', so it would think that the assignment could alias
-another member of `a'; this broke `struct-alias-1.c'. Future optimizer
-improvements may make this limitation unnecessary.
-
-
-File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands
-
-12.5.3 Conditional Expressions
-------------------------------
-
-A C `?:' expression is converted into an `if' statement with each
-branch assigning to the same temporary. So,
-
- a = b ? c : d;
- becomes
- if (b == 1)
- T1 = c;
- else
- T1 = d;
- a = T1;
-
- The GIMPLE level if-conversion pass re-introduces `?:' expression, if
-appropriate. It is used to vectorize loops with conditions using vector
-conditional operations.
-
- Note that in GIMPLE, `if' statements are represented using
-`GIMPLE_COND', as described below.
-
-
-File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands
-
-12.5.4 Logical Operators
-------------------------
-
-Except when they appear in the condition operand of a `GIMPLE_COND',
-logical `and' and `or' operators are simplified as follows: `a = b &&
-c' becomes
-
- T1 = (bool)b;
- if (T1 == true)
- T1 = (bool)c;
- a = T1;
-
- Note that `T1' in this example cannot be an expression temporary,
-because it has two different assignments.
-
-12.5.5 Manipulating operands
-----------------------------
-
-All gimple operands are of type `tree'. But only certain types of
-trees are allowed to be used as operand tuples. Basic validation is
-controlled by the function `get_gimple_rhs_class', which given a tree
-code, returns an `enum' with the following values of type `enum
-gimple_rhs_class'
-
- * `GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand.
-
- * `GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation.
-
- * `GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation.
-
- * `GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation.
-
- * `GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be
- split into simpler operands (for instance, `SSA_NAME', `VAR_DECL',
- `COMPONENT_REF', etc).
-
- This operand class also acts as an escape hatch for tree nodes
- that may be flattened out into the operand vector, but would need
- more than two slots on the RHS. For instance, a `COND_EXPR'
- expression of the form `(a op b) ? x : y' could be flattened out
- on the operand vector using 4 slots, but it would also require
- additional processing to distinguish `c = a op b' from `c = a op b
- ? x : y'. Something similar occurs with `ASSERT_EXPR'. In time,
- these special case tree expressions should be flattened into the
- operand vector.
-
- For tree nodes in the categories `GIMPLE_TERNARY_RHS',
-`GIMPLE_BINARY_RHS' and `GIMPLE_UNARY_RHS', they cannot be stored
-inside tuples directly. They first need to be flattened and separated
-into individual components. For instance, given the GENERIC expression
-
- a = b + c
-
- its tree representation is:
-
- MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>>
-
- In this case, the GIMPLE form for this statement is logically
-identical to its GENERIC form but in GIMPLE, the `PLUS_EXPR' on the RHS
-of the assignment is not represented as a tree, instead the two
-operands are taken out of the `PLUS_EXPR' sub-tree and flattened into
-the GIMPLE tuple as follows:
-
- GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>>
-
-12.5.6 Operand vector allocation
---------------------------------
-
-The operand vector is stored at the bottom of the three tuple
-structures that accept operands. This means, that depending on the code
-of a given statement, its operand vector will be at different offsets
-from the base of the structure. To access tuple operands use the
-following accessors
-
- -- GIMPLE function: unsigned gimple_num_ops (gimple g)
- Returns the number of operands in statement G.
-
- -- GIMPLE function: tree gimple_op (gimple g, unsigned i)
- Returns operand `I' from statement `G'.
-
- -- GIMPLE function: tree * gimple_ops (gimple g)
- Returns a pointer into the operand vector for statement `G'. This
- is computed using an internal table called `gimple_ops_offset_'[].
- This table is indexed by the gimple code of `G'.
-
- When the compiler is built, this table is filled-in using the
- sizes of the structures used by each statement code defined in
- gimple.def. Since the operand vector is at the bottom of the
- structure, for a gimple code `C' the offset is computed as sizeof
- (struct-of `C') - sizeof (tree).
-
- This mechanism adds one memory indirection to every access when
- using `gimple_op'(), if this becomes a bottleneck, a pass can
- choose to memoize the result from `gimple_ops'() and use that to
- access the operands.
-
-12.5.7 Operand validation
--------------------------
-
-When adding a new operand to a gimple statement, the operand will be
-validated according to what each tuple accepts in its operand vector.
-These predicates are called by the `gimple_NAME_set_...()'. Each tuple
-will use one of the following predicates (Note, this list is not
-exhaustive):
-
- -- GIMPLE function: bool is_gimple_val (tree t)
- Returns true if t is a "GIMPLE value", which are all the
- non-addressable stack variables (variables for which
- `is_gimple_reg' returns true) and constants (expressions for which
- `is_gimple_min_invariant' returns true).
-
- -- GIMPLE function: bool is_gimple_addressable (tree t)
- Returns true if t is a symbol or memory reference whose address
- can be taken.
-
- -- GIMPLE function: bool is_gimple_asm_val (tree t)
- Similar to `is_gimple_val' but it also accepts hard registers.
-
- -- GIMPLE function: bool is_gimple_call_addr (tree t)
- Return true if t is a valid expression to use as the function
- called by a `GIMPLE_CALL'.
-
- -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t)
- Return true if t is a valid expression to use as first operand of
- a `MEM_REF' expression.
-
- -- GIMPLE function: bool is_gimple_constant (tree t)
- Return true if t is a valid gimple constant.
-
- -- GIMPLE function: bool is_gimple_min_invariant (tree t)
- Return true if t is a valid minimal invariant. This is different
- from constants, in that the specific value of t may not be known
- at compile time, but it is known that it doesn't change (e.g., the
- address of a function local variable).
-
- -- GIMPLE function: bool is_gimple_ip_invariant (tree t)
- Return true if t is an interprocedural invariant. This means that
- t is a valid invariant in all functions (e.g. it can be an address
- of a global variable but not of a local one).
-
- -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t)
- Return true if t is an `ADDR_EXPR' that does not change once the
- program is running (and which is valid in all functions).
-
-12.5.8 Statement validation
----------------------------
-
- -- GIMPLE function: bool is_gimple_assign (gimple g)
- Return true if the code of g is `GIMPLE_ASSIGN'.
-
- -- GIMPLE function: bool is_gimple_call (gimple g)
- Return true if the code of g is `GIMPLE_CALL'.
-
- -- GIMPLE function: bool is_gimple_debug (gimple g)
- Return true if the code of g is `GIMPLE_DEBUG'.
-
- -- GIMPLE function: bool gimple_assign_cast_p (gimple g)
- Return true if g is a `GIMPLE_ASSIGN' that performs a type cast
- operation.
-
- -- GIMPLE function: bool gimple_debug_bind_p (gimple g)
- Return true if g is a `GIMPLE_DEBUG' that binds the value of an
- expression to a variable.
-
-
-File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE
-
-12.6 Manipulating GIMPLE statements
-===================================
-
-This section documents all the functions available to handle each of
-the GIMPLE instructions.
-
-12.6.1 Common accessors
------------------------
-
-The following are common accessors for gimple statements.
-
- -- GIMPLE function: enum gimple_code gimple_code (gimple g)
- Return the code for statement `G'.
-
- -- GIMPLE function: basic_block gimple_bb (gimple g)
- Return the basic block to which statement `G' belongs to.
-
- -- GIMPLE function: tree gimple_block (gimple g)
- Return the lexical scope block holding statement `G'.
-
- -- GIMPLE function: tree gimple_expr_type (gimple stmt)
- Return the type of the main expression computed by `STMT'. Return
- `void_type_node' if `STMT' computes nothing. This will only return
- something meaningful for `GIMPLE_ASSIGN', `GIMPLE_COND' and
- `GIMPLE_CALL'. For all other tuple codes, it will return
- `void_type_node'.
-
- -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt)
- Return the tree code for the expression computed by `STMT'. This
- is only meaningful for `GIMPLE_CALL', `GIMPLE_ASSIGN' and
- `GIMPLE_COND'. If `STMT' is `GIMPLE_CALL', it will return
- `CALL_EXPR'. For `GIMPLE_COND', it returns the code of the
- comparison predicate. For `GIMPLE_ASSIGN' it returns the code of
- the operation performed by the `RHS' of the assignment.
-
- -- GIMPLE function: void gimple_set_block (gimple g, tree block)
- Set the lexical scope block of `G' to `BLOCK'.
-
- -- GIMPLE function: location_t gimple_locus (gimple g)
- Return locus information for statement `G'.
-
- -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus)
- Set locus information for statement `G'.
-
- -- GIMPLE function: bool gimple_locus_empty_p (gimple g)
- Return true if `G' does not have locus information.
-
- -- GIMPLE function: bool gimple_no_warning_p (gimple stmt)
- Return true if no warnings should be emitted for statement `STMT'.
-
- -- GIMPLE function: void gimple_set_visited (gimple stmt, bool
- visited_p)
- Set the visited status on statement `STMT' to `VISITED_P'.
-
- -- GIMPLE function: bool gimple_visited_p (gimple stmt)
- Return the visited status on statement `STMT'.
-
- -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask
- plf, bool val_p)
- Set pass local flag `PLF' on statement `STMT' to `VAL_P'.
-
- -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum
- plf_mask plf)
- Return the value of pass local flag `PLF' on statement `STMT'.
-
- -- GIMPLE function: bool gimple_has_ops (gimple g)
- Return true if statement `G' has register or memory operands.
-
- -- GIMPLE function: bool gimple_has_mem_ops (gimple g)
- Return true if statement `G' has memory operands.
-
- -- GIMPLE function: unsigned gimple_num_ops (gimple g)
- Return the number of operands for statement `G'.
-
- -- GIMPLE function: tree * gimple_ops (gimple g)
- Return the array of operands for statement `G'.
-
- -- GIMPLE function: tree gimple_op (gimple g, unsigned i)
- Return operand `I' for statement `G'.
-
- -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i)
- Return a pointer to operand `I' for statement `G'.
-
- -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op)
- Set operand `I' of statement `G' to `OP'.
-
- -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt)
- Return the set of symbols that have had their address taken by
- `STMT'.
-
- -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g)
- Return the set of `DEF' operands for statement `G'.
-
- -- GIMPLE function: void gimple_set_def_ops (gimple g, struct
- def_optype_d *def)
- Set `DEF' to be the set of `DEF' operands for statement `G'.
-
- -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g)
- Return the set of `USE' operands for statement `G'.
-
- -- GIMPLE function: void gimple_set_use_ops (gimple g, struct
- use_optype_d *use)
- Set `USE' to be the set of `USE' operands for statement `G'.
-
- -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g)
- Return the set of `VUSE' operands for statement `G'.
-
- -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct
- voptype_d *ops)
- Set `OPS' to be the set of `VUSE' operands for statement `G'.
-
- -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g)
- Return the set of `VDEF' operands for statement `G'.
-
- -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct
- voptype_d *ops)
- Set `OPS' to be the set of `VDEF' operands for statement `G'.
-
- -- GIMPLE function: bitmap gimple_loaded_syms (gimple g)
- Return the set of symbols loaded by statement `G'. Each element of
- the set is the `DECL_UID' of the corresponding symbol.
-
- -- GIMPLE function: bitmap gimple_stored_syms (gimple g)
- Return the set of symbols stored by statement `G'. Each element of
- the set is the `DECL_UID' of the corresponding symbol.
-
- -- GIMPLE function: bool gimple_modified_p (gimple g)
- Return true if statement `G' has operands and the modified field
- has been set.
-
- -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt)
- Return true if statement `STMT' contains volatile operands.
-
- -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt,
- bool volatilep)
- Return true if statement `STMT' contains volatile operands.
-
- -- GIMPLE function: void update_stmt (gimple s)
- Mark statement `S' as modified, and update it.
-
- -- GIMPLE function: void update_stmt_if_modified (gimple s)
- Update statement `S' if it has been marked modified.
-
- -- GIMPLE function: gimple gimple_copy (gimple stmt)
- Return a deep copy of statement `STMT'.
-
-
-File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE
-
-12.7 Tuple specific accessors
-=============================
-
-* Menu:
-
-* `GIMPLE_ASM'::
-* `GIMPLE_ASSIGN'::
-* `GIMPLE_BIND'::
-* `GIMPLE_CALL'::
-* `GIMPLE_CATCH'::
-* `GIMPLE_COND'::
-* `GIMPLE_DEBUG'::
-* `GIMPLE_EH_FILTER'::
-* `GIMPLE_LABEL'::
-* `GIMPLE_NOP'::
-* `GIMPLE_OMP_ATOMIC_LOAD'::
-* `GIMPLE_OMP_ATOMIC_STORE'::
-* `GIMPLE_OMP_CONTINUE'::
-* `GIMPLE_OMP_CRITICAL'::
-* `GIMPLE_OMP_FOR'::
-* `GIMPLE_OMP_MASTER'::
-* `GIMPLE_OMP_ORDERED'::
-* `GIMPLE_OMP_PARALLEL'::
-* `GIMPLE_OMP_RETURN'::
-* `GIMPLE_OMP_SECTION'::
-* `GIMPLE_OMP_SECTIONS'::
-* `GIMPLE_OMP_SINGLE'::
-* `GIMPLE_PHI'::
-* `GIMPLE_RESX'::
-* `GIMPLE_RETURN'::
-* `GIMPLE_SWITCH'::
-* `GIMPLE_TRY'::
-* `GIMPLE_WITH_CLEANUP_EXPR'::
-
-
-File: gccint.info, Node: `GIMPLE_ASM', Next: `GIMPLE_ASSIGN', Up: Tuple specific accessors
-
-12.7.1 `GIMPLE_ASM'
--------------------
-
- -- GIMPLE function: gimple gimple_build_asm (const char *string,
- ninputs, noutputs, nclobbers, ...)
- Build a `GIMPLE_ASM' statement. This statement is used for
- building in-line assembly constructs. `STRING' is the assembly
- code. `NINPUT' is the number of register inputs. `NOUTPUT' is the
- number of register outputs. `NCLOBBERS' is the number of clobbered
- registers. The rest of the arguments trees for each input,
- output, and clobbered registers.
-
- -- GIMPLE function: gimple gimple_build_asm_vec (const char *,
- VEC(tree,gc) *, VEC(tree,gc) *, VEC(tree,gc) *)
- Identical to gimple_build_asm, but the arguments are passed in
- VECs.
-
- -- GIMPLE function: unsigned gimple_asm_ninputs (gimple g)
- Return the number of input operands for `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: unsigned gimple_asm_noutputs (gimple g)
- Return the number of output operands for `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: unsigned gimple_asm_nclobbers (gimple g)
- Return the number of clobber operands for `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: tree gimple_asm_input_op (gimple g, unsigned index)
- Return input operand `INDEX' of `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: void gimple_asm_set_input_op (gimple g, unsigned
- index, tree in_op)
- Set `IN_OP' to be input operand `INDEX' in `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: tree gimple_asm_output_op (gimple g, unsigned
- index)
- Return output operand `INDEX' of `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: void gimple_asm_set_output_op (gimple g, unsigned
- index, tree out_op)
- Set `OUT_OP' to be output operand `INDEX' in `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: tree gimple_asm_clobber_op (gimple g, unsigned
- index)
- Return clobber operand `INDEX' of `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: void gimple_asm_set_clobber_op (gimple g, unsigned
- index, tree clobber_op)
- Set `CLOBBER_OP' to be clobber operand `INDEX' in `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: const char * gimple_asm_string (gimple g)
- Return the string representing the assembly instruction in
- `GIMPLE_ASM' `G'.
-
- -- GIMPLE function: bool gimple_asm_volatile_p (gimple g)
- Return true if `G' is an asm statement marked volatile.
-
- -- GIMPLE function: void gimple_asm_set_volatile (gimple g)
- Mark asm statement `G' as volatile.
-
- -- GIMPLE function: void gimple_asm_clear_volatile (gimple g)
- Remove volatile marker from asm statement `G'.
-
-
-File: gccint.info, Node: `GIMPLE_ASSIGN', Next: `GIMPLE_BIND', Prev: `GIMPLE_ASM', Up: Tuple specific accessors
-
-12.7.2 `GIMPLE_ASSIGN'
-----------------------
-
- -- GIMPLE function: gimple gimple_build_assign (tree lhs, tree rhs)
- Build a `GIMPLE_ASSIGN' statement. The left-hand side is an lvalue
- passed in lhs. The right-hand side can be either a unary or
- binary tree expression. The expression tree rhs will be flattened
- and its operands assigned to the corresponding operand slots in
- the new statement. This function is useful when you already have
- a tree expression that you want to convert into a tuple. However,
- try to avoid building expression trees for the sole purpose of
- calling this function. If you already have the operands in
- separate trees, it is better to use `gimple_build_assign_with_ops'.
-
- -- GIMPLE function: gimple gimplify_assign (tree dst, tree src,
- gimple_seq *seq_p)
- Build a new `GIMPLE_ASSIGN' tuple and append it to the end of
- `*SEQ_P'.
-
- `DST'/`SRC' are the destination and source respectively. You can pass
-ungimplified trees in `DST' or `SRC', in which case they will be
-converted to a gimple operand if necessary.
-
- This function returns the newly created `GIMPLE_ASSIGN' tuple.
-
- -- GIMPLE function: gimple gimple_build_assign_with_ops (enum
- tree_code subcode, tree lhs, tree op1, tree op2)
- This function is similar to `gimple_build_assign', but is used to
- build a `GIMPLE_ASSIGN' statement when the operands of the
- right-hand side of the assignment are already split into different
- operands.
-
- The left-hand side is an lvalue passed in lhs. Subcode is the
- `tree_code' for the right-hand side of the assignment. Op1 and op2
- are the operands. If op2 is null, subcode must be a `tree_code'
- for a unary expression.
-
- -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g)
- Return the code of the expression computed on the `RHS' of
- assignment statement `G'.
-
- -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class
- (gimple g)
- Return the gimple rhs class of the code for the expression
- computed on the rhs of assignment statement `G'. This will never
- return `GIMPLE_INVALID_RHS'.
-
- -- GIMPLE function: tree gimple_assign_lhs (gimple g)
- Return the `LHS' of assignment statement `G'.
-
- -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g)
- Return a pointer to the `LHS' of assignment statement `G'.
-
- -- GIMPLE function: tree gimple_assign_rhs1 (gimple g)
- Return the first operand on the `RHS' of assignment statement `G'.
-
- -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g)
- Return the address of the first operand on the `RHS' of assignment
- statement `G'.
-
- -- GIMPLE function: tree gimple_assign_rhs2 (gimple g)
- Return the second operand on the `RHS' of assignment statement `G'.
-
- -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g)
- Return the address of the second operand on the `RHS' of assignment
- statement `G'.
-
- -- GIMPLE function: tree gimple_assign_rhs3 (gimple g)
- Return the third operand on the `RHS' of assignment statement `G'.
-
- -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g)
- Return the address of the third operand on the `RHS' of assignment
- statement `G'.
-
- -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs)
- Set `LHS' to be the `LHS' operand of assignment statement `G'.
-
- -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs)
- Set `RHS' to be the first operand on the `RHS' of assignment
- statement `G'.
-
- -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs)
- Set `RHS' to be the second operand on the `RHS' of assignment
- statement `G'.
-
- -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs)
- Set `RHS' to be the third operand on the `RHS' of assignment
- statement `G'.
-
- -- GIMPLE function: bool gimple_assign_cast_p (gimple s)
- Return true if `S' is a type-cast assignment.
-
-
-File: gccint.info, Node: `GIMPLE_BIND', Next: `GIMPLE_CALL', Prev: `GIMPLE_ASSIGN', Up: Tuple specific accessors
-
-12.7.3 `GIMPLE_BIND'
---------------------
-
- -- GIMPLE function: gimple gimple_build_bind (tree vars, gimple_seq
- body)
- Build a `GIMPLE_BIND' statement with a list of variables in `VARS'
- and a body of statements in sequence `BODY'.
-
- -- GIMPLE function: tree gimple_bind_vars (gimple g)
- Return the variables declared in the `GIMPLE_BIND' statement `G'.
-
- -- GIMPLE function: void gimple_bind_set_vars (gimple g, tree vars)
- Set `VARS' to be the set of variables declared in the `GIMPLE_BIND'
- statement `G'.
-
- -- GIMPLE function: void gimple_bind_append_vars (gimple g, tree vars)
- Append `VARS' to the set of variables declared in the `GIMPLE_BIND'
- statement `G'.
-
- -- GIMPLE function: gimple_seq gimple_bind_body (gimple g)
- Return the GIMPLE sequence contained in the `GIMPLE_BIND' statement
- `G'.
-
- -- GIMPLE function: void gimple_bind_set_body (gimple g, gimple_seq
- seq)
- Set `SEQ' to be sequence contained in the `GIMPLE_BIND' statement
- `G'.
-
- -- GIMPLE function: void gimple_bind_add_stmt (gimple gs, gimple stmt)
- Append a statement to the end of a `GIMPLE_BIND''s body.
-
- -- GIMPLE function: void gimple_bind_add_seq (gimple gs, gimple_seq
- seq)
- Append a sequence of statements to the end of a `GIMPLE_BIND''s
- body.
-
- -- GIMPLE function: tree gimple_bind_block (gimple g)
- Return the `TREE_BLOCK' node associated with `GIMPLE_BIND'
- statement `G'. This is analogous to the `BIND_EXPR_BLOCK' field in
- trees.
-
- -- GIMPLE function: void gimple_bind_set_block (gimple g, tree block)
- Set `BLOCK' to be the `TREE_BLOCK' node associated with
- `GIMPLE_BIND' statement `G'.
-
-
-File: gccint.info, Node: `GIMPLE_CALL', Next: `GIMPLE_CATCH', Prev: `GIMPLE_BIND', Up: Tuple specific accessors
-
-12.7.4 `GIMPLE_CALL'
---------------------
-
- -- GIMPLE function: gimple gimple_build_call (tree fn, unsigned nargs,
- ...)
- Build a `GIMPLE_CALL' statement to function `FN'. The argument
- `FN' must be either a `FUNCTION_DECL' or a gimple call address as
- determined by `is_gimple_call_addr'. `NARGS' are the number of
- arguments. The rest of the arguments follow the argument `NARGS',
- and must be trees that are valid as rvalues in gimple (i.e., each
- operand is validated with `is_gimple_operand').
-
- -- GIMPLE function: gimple gimple_build_call_from_tree (tree call_expr)
- Build a `GIMPLE_CALL' from a `CALL_EXPR' node. The arguments and
- the function are taken from the expression directly. This routine
- assumes that `call_expr' is already in GIMPLE form. That is, its
- operands are GIMPLE values and the function call needs no further
- simplification. All the call flags in `call_expr' are copied over
- to the new `GIMPLE_CALL'.
-
- -- GIMPLE function: gimple gimple_build_call_vec (tree fn, `VEC'(tree,
- heap) *args)
- Identical to `gimple_build_call' but the arguments are stored in a
- `VEC'().
-
- -- GIMPLE function: tree gimple_call_lhs (gimple g)
- Return the `LHS' of call statement `G'.
-
- -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g)
- Return a pointer to the `LHS' of call statement `G'.
-
- -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs)
- Set `LHS' to be the `LHS' operand of call statement `G'.
-
- -- GIMPLE function: tree gimple_call_fn (gimple g)
- Return the tree node representing the function called by call
- statement `G'.
-
- -- GIMPLE function: void gimple_call_set_fn (gimple g, tree fn)
- Set `FN' to be the function called by call statement `G'. This has
- to be a gimple value specifying the address of the called function.
-
- -- GIMPLE function: tree gimple_call_fndecl (gimple g)
- If a given `GIMPLE_CALL''s callee is a `FUNCTION_DECL', return it.
- Otherwise return `NULL'. This function is analogous to
- `get_callee_fndecl' in `GENERIC'.
-
- -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl)
- Set the called function to `FNDECL'.
-
- -- GIMPLE function: tree gimple_call_return_type (gimple g)
- Return the type returned by call statement `G'.
-
- -- GIMPLE function: tree gimple_call_chain (gimple g)
- Return the static chain for call statement `G'.
-
- -- GIMPLE function: void gimple_call_set_chain (gimple g, tree chain)
- Set `CHAIN' to be the static chain for call statement `G'.
-
- -- GIMPLE function: unsigned gimple_call_num_args (gimple g)
- Return the number of arguments used by call statement `G'.
-
- -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index)
- Return the argument at position `INDEX' for call statement `G'.
- The first argument is 0.
-
- -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned
- index)
- Return a pointer to the argument at position `INDEX' for call
- statement `G'.
-
- -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned
- index, tree arg)
- Set `ARG' to be the argument at position `INDEX' for call statement
- `G'.
-
- -- GIMPLE function: void gimple_call_set_tail (gimple s)
- Mark call statement `S' as being a tail call (i.e., a call just
- before the exit of a function). These calls are candidate for tail
- call optimization.
-
- -- GIMPLE function: bool gimple_call_tail_p (gimple s)
- Return true if `GIMPLE_CALL' `S' is marked as a tail call.
-
- -- GIMPLE function: void gimple_call_mark_uninlinable (gimple s)
- Mark `GIMPLE_CALL' `S' as being uninlinable.
-
- -- GIMPLE function: bool gimple_call_cannot_inline_p (gimple s)
- Return true if `GIMPLE_CALL' `S' cannot be inlined.
-
- -- GIMPLE function: bool gimple_call_noreturn_p (gimple s)
- Return true if `S' is a noreturn call.
-
- -- GIMPLE function: gimple gimple_call_copy_skip_args (gimple stmt,
- bitmap args_to_skip)
- Build a `GIMPLE_CALL' identical to `STMT' but skipping the
- arguments in the positions marked by the set `ARGS_TO_SKIP'.
-
-
-File: gccint.info, Node: `GIMPLE_CATCH', Next: `GIMPLE_COND', Prev: `GIMPLE_CALL', Up: Tuple specific accessors
-
-12.7.5 `GIMPLE_CATCH'
----------------------
-
- -- GIMPLE function: gimple gimple_build_catch (tree types, gimple_seq
- handler)
- Build a `GIMPLE_CATCH' statement. `TYPES' are the tree types this
- catch handles. `HANDLER' is a sequence of statements with the code
- for the handler.
-
- -- GIMPLE function: tree gimple_catch_types (gimple g)
- Return the types handled by `GIMPLE_CATCH' statement `G'.
-
- -- GIMPLE function: tree * gimple_catch_types_ptr (gimple g)
- Return a pointer to the types handled by `GIMPLE_CATCH' statement
- `G'.
-
- -- GIMPLE function: gimple_seq gimple_catch_handler (gimple g)
- Return the GIMPLE sequence representing the body of the handler of
- `GIMPLE_CATCH' statement `G'.
-
- -- GIMPLE function: void gimple_catch_set_types (gimple g, tree t)
- Set `T' to be the set of types handled by `GIMPLE_CATCH' `G'.
-
- -- GIMPLE function: void gimple_catch_set_handler (gimple g,
- gimple_seq handler)
- Set `HANDLER' to be the body of `GIMPLE_CATCH' `G'.
-
-
-File: gccint.info, Node: `GIMPLE_COND', Next: `GIMPLE_DEBUG', Prev: `GIMPLE_CATCH', Up: Tuple specific accessors
-
-12.7.6 `GIMPLE_COND'
---------------------
-
- -- GIMPLE function: gimple gimple_build_cond (enum tree_code
- pred_code, tree lhs, tree rhs, tree t_label, tree f_label)
- Build a `GIMPLE_COND' statement. `A' `GIMPLE_COND' statement
- compares `LHS' and `RHS' and if the condition in `PRED_CODE' is
- true, jump to the label in `t_label', otherwise jump to the label
- in `f_label'. `PRED_CODE' are relational operator tree codes like
- `EQ_EXPR', `LT_EXPR', `LE_EXPR', `NE_EXPR', etc.
-
- -- GIMPLE function: gimple gimple_build_cond_from_tree (tree cond,
- tree t_label, tree f_label)
- Build a `GIMPLE_COND' statement from the conditional expression
- tree `COND'. `T_LABEL' and `F_LABEL' are as in
- `gimple_build_cond'.
-
- -- GIMPLE function: enum tree_code gimple_cond_code (gimple g)
- Return the code of the predicate computed by conditional statement
- `G'.
-
- -- GIMPLE function: void gimple_cond_set_code (gimple g, enum
- tree_code code)
- Set `CODE' to be the predicate code for the conditional statement
- `G'.
-
- -- GIMPLE function: tree gimple_cond_lhs (gimple g)
- Return the `LHS' of the predicate computed by conditional statement
- `G'.
-
- -- GIMPLE function: void gimple_cond_set_lhs (gimple g, tree lhs)
- Set `LHS' to be the `LHS' operand of the predicate computed by
- conditional statement `G'.
-
- -- GIMPLE function: tree gimple_cond_rhs (gimple g)
- Return the `RHS' operand of the predicate computed by conditional
- `G'.
-
- -- GIMPLE function: void gimple_cond_set_rhs (gimple g, tree rhs)
- Set `RHS' to be the `RHS' operand of the predicate computed by
- conditional statement `G'.
-
- -- GIMPLE function: tree gimple_cond_true_label (gimple g)
- Return the label used by conditional statement `G' when its
- predicate evaluates to true.
-
- -- GIMPLE function: void gimple_cond_set_true_label (gimple g, tree
- label)
- Set `LABEL' to be the label used by conditional statement `G' when
- its predicate evaluates to true.
-
- -- GIMPLE function: void gimple_cond_set_false_label (gimple g, tree
- label)
- Set `LABEL' to be the label used by conditional statement `G' when
- its predicate evaluates to false.
-
- -- GIMPLE function: tree gimple_cond_false_label (gimple g)
- Return the label used by conditional statement `G' when its
- predicate evaluates to false.
-
- -- GIMPLE function: void gimple_cond_make_false (gimple g)
- Set the conditional `COND_STMT' to be of the form 'if (1 == 0)'.
-
- -- GIMPLE function: void gimple_cond_make_true (gimple g)
- Set the conditional `COND_STMT' to be of the form 'if (1 == 1)'.
-
-
-File: gccint.info, Node: `GIMPLE_DEBUG', Next: `GIMPLE_EH_FILTER', Prev: `GIMPLE_COND', Up: Tuple specific accessors
-
-12.7.7 `GIMPLE_DEBUG'
----------------------
-
- -- GIMPLE function: gimple gimple_build_debug_bind (tree var, tree
- value, gimple stmt)
- Build a `GIMPLE_DEBUG' statement with `GIMPLE_DEBUG_BIND' of
- `subcode'. The effect of this statement is to tell debug
- information generation machinery that the value of user variable
- `var' is given by `value' at that point, and to remain with that
- value until `var' runs out of scope, a dynamically-subsequent
- debug bind statement overrides the binding, or conflicting values
- reach a control flow merge point. Even if components of the
- `value' expression change afterwards, the variable is supposed to
- retain the same value, though not necessarily the same location.
-
- It is expected that `var' be most often a tree for automatic user
- variables (`VAR_DECL' or `PARM_DECL') that satisfy the
- requirements for gimple registers, but it may also be a tree for a
- scalarized component of a user variable (`ARRAY_REF',
- `COMPONENT_REF'), or a debug temporary (`DEBUG_EXPR_DECL').
-
- As for `value', it can be an arbitrary tree expression, but it is
- recommended that it be in a suitable form for a gimple assignment
- `RHS'. It is not expected that user variables that could appear
- as `var' ever appear in `value', because in the latter we'd have
- their `SSA_NAME's instead, but even if they were not in SSA form,
- user variables appearing in `value' are to be regarded as part of
- the executable code space, whereas those in `var' are to be
- regarded as part of the source code space. There is no way to
- refer to the value bound to a user variable within a `value'
- expression.
-
- If `value' is `GIMPLE_DEBUG_BIND_NOVALUE', debug information
- generation machinery is informed that the variable `var' is
- unbound, i.e., that its value is indeterminate, which sometimes
- means it is really unavailable, and other times that the compiler
- could not keep track of it.
-
- Block and location information for the newly-created stmt are
- taken from `stmt', if given.
-
- -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt)
- Return the user variable VAR that is bound at `stmt'.
-
- -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt)
- Return the value expression that is bound to a user variable at
- `stmt'.
-
- -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple
- stmt)
- Return a pointer to the value expression that is bound to a user
- variable at `stmt'.
-
- -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree
- var)
- Modify the user variable bound at `stmt' to VAR.
-
- -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt,
- tree var)
- Modify the value bound to the user variable bound at `stmt' to
- VALUE.
-
- -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt)
- Modify the value bound to the user variable bound at `stmt' so
- that the variable becomes unbound.
-
- -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt)
- Return `TRUE' if `stmt' binds a user variable to a value, and
- `FALSE' if it unbinds the variable.
-
-
-File: gccint.info, Node: `GIMPLE_EH_FILTER', Next: `GIMPLE_LABEL', Prev: `GIMPLE_DEBUG', Up: Tuple specific accessors
-
-12.7.8 `GIMPLE_EH_FILTER'
--------------------------
-
- -- GIMPLE function: gimple gimple_build_eh_filter (tree types,
- gimple_seq failure)
- Build a `GIMPLE_EH_FILTER' statement. `TYPES' are the filter's
- types. `FAILURE' is a sequence with the filter's failure action.
-
- -- GIMPLE function: tree gimple_eh_filter_types (gimple g)
- Return the types handled by `GIMPLE_EH_FILTER' statement `G'.
-
- -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g)
- Return a pointer to the types handled by `GIMPLE_EH_FILTER'
- statement `G'.
-
- -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g)
- Return the sequence of statement to execute when `GIMPLE_EH_FILTER'
- statement fails.
-
- -- GIMPLE function: void gimple_eh_filter_set_types (gimple g, tree
- types)
- Set `TYPES' to be the set of types handled by `GIMPLE_EH_FILTER'
- `G'.
-
- -- GIMPLE function: void gimple_eh_filter_set_failure (gimple g,
- gimple_seq failure)
- Set `FAILURE' to be the sequence of statements to execute on
- failure for `GIMPLE_EH_FILTER' `G'.
-
- -- GIMPLE function: bool gimple_eh_filter_must_not_throw (gimple g)
- Return the `EH_FILTER_MUST_NOT_THROW' flag.
-
- -- GIMPLE function: void gimple_eh_filter_set_must_not_throw (gimple
- g, bool mntp)
- Set the `EH_FILTER_MUST_NOT_THROW' flag.
-
-
-File: gccint.info, Node: `GIMPLE_LABEL', Next: `GIMPLE_NOP', Prev: `GIMPLE_EH_FILTER', Up: Tuple specific accessors
-
-12.7.9 `GIMPLE_LABEL'
----------------------
-
- -- GIMPLE function: gimple gimple_build_label (tree label)
- Build a `GIMPLE_LABEL' statement with corresponding to the tree
- label, `LABEL'.
-
- -- GIMPLE function: tree gimple_label_label (gimple g)
- Return the `LABEL_DECL' node used by `GIMPLE_LABEL' statement `G'.
-
- -- GIMPLE function: void gimple_label_set_label (gimple g, tree label)
- Set `LABEL' to be the `LABEL_DECL' node used by `GIMPLE_LABEL'
- statement `G'.
-
- -- GIMPLE function: gimple gimple_build_goto (tree dest)
- Build a `GIMPLE_GOTO' statement to label `DEST'.
-
- -- GIMPLE function: tree gimple_goto_dest (gimple g)
- Return the destination of the unconditional jump `G'.
-
- -- GIMPLE function: void gimple_goto_set_dest (gimple g, tree dest)
- Set `DEST' to be the destination of the unconditional jump `G'.
-
-
-File: gccint.info, Node: `GIMPLE_NOP', Next: `GIMPLE_OMP_ATOMIC_LOAD', Prev: `GIMPLE_LABEL', Up: Tuple specific accessors
-
-12.7.10 `GIMPLE_NOP'
---------------------
-
- -- GIMPLE function: gimple gimple_build_nop (void)
- Build a `GIMPLE_NOP' statement.
-
- -- GIMPLE function: bool gimple_nop_p (gimple g)
- Returns `TRUE' if statement `G' is a `GIMPLE_NOP'.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_LOAD', Next: `GIMPLE_OMP_ATOMIC_STORE', Prev: `GIMPLE_NOP', Up: Tuple specific accessors
-
-12.7.11 `GIMPLE_OMP_ATOMIC_LOAD'
---------------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_atomic_load (tree lhs,
- tree rhs)
- Build a `GIMPLE_OMP_ATOMIC_LOAD' statement. `LHS' is the left-hand
- side of the assignment. `RHS' is the right-hand side of the
- assignment.
-
- -- GIMPLE function: void gimple_omp_atomic_load_set_lhs (gimple g,
- tree lhs)
- Set the `LHS' of an atomic load.
-
- -- GIMPLE function: tree gimple_omp_atomic_load_lhs (gimple g)
- Get the `LHS' of an atomic load.
-
- -- GIMPLE function: void gimple_omp_atomic_load_set_rhs (gimple g,
- tree rhs)
- Set the `RHS' of an atomic set.
-
- -- GIMPLE function: tree gimple_omp_atomic_load_rhs (gimple g)
- Get the `RHS' of an atomic set.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_STORE', Next: `GIMPLE_OMP_CONTINUE', Prev: `GIMPLE_OMP_ATOMIC_LOAD', Up: Tuple specific accessors
-
-12.7.12 `GIMPLE_OMP_ATOMIC_STORE'
----------------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_atomic_store (tree val)
- Build a `GIMPLE_OMP_ATOMIC_STORE' statement. `VAL' is the value to
- be stored.
-
- -- GIMPLE function: void gimple_omp_atomic_store_set_val (gimple g,
- tree val)
- Set the value being stored in an atomic store.
-
- -- GIMPLE function: tree gimple_omp_atomic_store_val (gimple g)
- Return the value being stored in an atomic store.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_CONTINUE', Next: `GIMPLE_OMP_CRITICAL', Prev: `GIMPLE_OMP_ATOMIC_STORE', Up: Tuple specific accessors
-
-12.7.13 `GIMPLE_OMP_CONTINUE'
------------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_continue (tree
- control_def, tree control_use)
- Build a `GIMPLE_OMP_CONTINUE' statement. `CONTROL_DEF' is the
- definition of the control variable. `CONTROL_USE' is the use of
- the control variable.
-
- -- GIMPLE function: tree gimple_omp_continue_control_def (gimple s)
- Return the definition of the control variable on a
- `GIMPLE_OMP_CONTINUE' in `S'.
-
- -- GIMPLE function: tree gimple_omp_continue_control_def_ptr (gimple s)
- Same as above, but return the pointer.
-
- -- GIMPLE function: tree gimple_omp_continue_set_control_def (gimple s)
- Set the control variable definition for a `GIMPLE_OMP_CONTINUE'
- statement in `S'.
-
- -- GIMPLE function: tree gimple_omp_continue_control_use (gimple s)
- Return the use of the control variable on a `GIMPLE_OMP_CONTINUE'
- in `S'.
-
- -- GIMPLE function: tree gimple_omp_continue_control_use_ptr (gimple s)
- Same as above, but return the pointer.
-
- -- GIMPLE function: tree gimple_omp_continue_set_control_use (gimple s)
- Set the control variable use for a `GIMPLE_OMP_CONTINUE' statement
- in `S'.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_CRITICAL', Next: `GIMPLE_OMP_FOR', Prev: `GIMPLE_OMP_CONTINUE', Up: Tuple specific accessors
-
-12.7.14 `GIMPLE_OMP_CRITICAL'
------------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_critical (gimple_seq body,
- tree name)
- Build a `GIMPLE_OMP_CRITICAL' statement. `BODY' is the sequence of
- statements for which only one thread can execute. `NAME' is an
- optional identifier for this critical block.
-
- -- GIMPLE function: tree gimple_omp_critical_name (gimple g)
- Return the name associated with `OMP_CRITICAL' statement `G'.
-
- -- GIMPLE function: tree * gimple_omp_critical_name_ptr (gimple g)
- Return a pointer to the name associated with `OMP' critical
- statement `G'.
-
- -- GIMPLE function: void gimple_omp_critical_set_name (gimple g, tree
- name)
- Set `NAME' to be the name associated with `OMP' critical statement
- `G'.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_FOR', Next: `GIMPLE_OMP_MASTER', Prev: `GIMPLE_OMP_CRITICAL', Up: Tuple specific accessors
-
-12.7.15 `GIMPLE_OMP_FOR'
-------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_for (gimple_seq body, tree
- clauses, tree index, tree initial, tree final, tree incr,
- gimple_seq pre_body, enum tree_code omp_for_cond)
- Build a `GIMPLE_OMP_FOR' statement. `BODY' is sequence of
- statements inside the for loop. `CLAUSES', are any of the `OMP'
- loop construct's clauses: private, firstprivate, lastprivate,
- reductions, ordered, schedule, and nowait. `PRE_BODY' is the
- sequence of statements that are loop invariant. `INDEX' is the
- index variable. `INITIAL' is the initial value of `INDEX'.
- `FINAL' is final value of `INDEX'. OMP_FOR_COND is the predicate
- used to compare `INDEX' and `FINAL'. `INCR' is the increment
- expression.
-
- -- GIMPLE function: tree gimple_omp_for_clauses (gimple g)
- Return the clauses associated with `OMP_FOR' `G'.
-
- -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g)
- Return a pointer to the `OMP_FOR' `G'.
-
- -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree
- clauses)
- Set `CLAUSES' to be the list of clauses associated with `OMP_FOR'
- `G'.
-
- -- GIMPLE function: tree gimple_omp_for_index (gimple g)
- Return the index variable for `OMP_FOR' `G'.
-
- -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g)
- Return a pointer to the index variable for `OMP_FOR' `G'.
-
- -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree
- index)
- Set `INDEX' to be the index variable for `OMP_FOR' `G'.
-
- -- GIMPLE function: tree gimple_omp_for_initial (gimple g)
- Return the initial value for `OMP_FOR' `G'.
-
- -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g)
- Return a pointer to the initial value for `OMP_FOR' `G'.
-
- -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree
- initial)
- Set `INITIAL' to be the initial value for `OMP_FOR' `G'.
-
- -- GIMPLE function: tree gimple_omp_for_final (gimple g)
- Return the final value for `OMP_FOR' `G'.
-
- -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g)
- turn a pointer to the final value for `OMP_FOR' `G'.
-
- -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree
- final)
- Set `FINAL' to be the final value for `OMP_FOR' `G'.
-
- -- GIMPLE function: tree gimple_omp_for_incr (gimple g)
- Return the increment value for `OMP_FOR' `G'.
-
- -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g)
- Return a pointer to the increment value for `OMP_FOR' `G'.
-
- -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr)
- Set `INCR' to be the increment value for `OMP_FOR' `G'.
-
- -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g)
- Return the sequence of statements to execute before the `OMP_FOR'
- statement `G' starts.
-
- -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g,
- gimple_seq pre_body)
- Set `PRE_BODY' to be the sequence of statements to execute before
- the `OMP_FOR' statement `G' starts.
-
- -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum
- tree_code cond)
- Set `COND' to be the condition code for `OMP_FOR' `G'.
-
- -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g)
- Return the condition code associated with `OMP_FOR' `G'.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_MASTER', Next: `GIMPLE_OMP_ORDERED', Prev: `GIMPLE_OMP_FOR', Up: Tuple specific accessors
-
-12.7.16 `GIMPLE_OMP_MASTER'
----------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body)
- Build a `GIMPLE_OMP_MASTER' statement. `BODY' is the sequence of
- statements to be executed by just the master.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_ORDERED', Next: `GIMPLE_OMP_PARALLEL', Prev: `GIMPLE_OMP_MASTER', Up: Tuple specific accessors
-
-12.7.17 `GIMPLE_OMP_ORDERED'
-----------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body)
- Build a `GIMPLE_OMP_ORDERED' statement.
-
- `BODY' is the sequence of statements inside a loop that will executed
-in sequence.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_PARALLEL', Next: `GIMPLE_OMP_RETURN', Prev: `GIMPLE_OMP_ORDERED', Up: Tuple specific accessors
-
-12.7.18 `GIMPLE_OMP_PARALLEL'
------------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_parallel (gimple_seq body,
- tree clauses, tree child_fn, tree data_arg)
- Build a `GIMPLE_OMP_PARALLEL' statement.
-
- `BODY' is sequence of statements which are executed in parallel.
-`CLAUSES', are the `OMP' parallel construct's clauses. `CHILD_FN' is
-the function created for the parallel threads to execute. `DATA_ARG'
-are the shared data argument(s).
-
- -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g)
- Return true if `OMP' parallel statement `G' has the
- `GF_OMP_PARALLEL_COMBINED' flag set.
-
- -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g)
- Set the `GF_OMP_PARALLEL_COMBINED' field in `OMP' parallel
- statement `G'.
-
- -- GIMPLE function: gimple_seq gimple_omp_body (gimple g)
- Return the body for the `OMP' statement `G'.
-
- -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq
- body)
- Set `BODY' to be the body for the `OMP' statement `G'.
-
- -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g)
- Return the clauses associated with `OMP_PARALLEL' `G'.
-
- -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr (gimple g)
- Return a pointer to the clauses associated with `OMP_PARALLEL' `G'.
-
- -- GIMPLE function: void gimple_omp_parallel_set_clauses (gimple g,
- tree clauses)
- Set `CLAUSES' to be the list of clauses associated with
- `OMP_PARALLEL' `G'.
-
- -- GIMPLE function: tree gimple_omp_parallel_child_fn (gimple g)
- Return the child function used to hold the body of `OMP_PARALLEL'
- `G'.
-
- -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr (gimple g)
- Return a pointer to the child function used to hold the body of
- `OMP_PARALLEL' `G'.
-
- -- GIMPLE function: void gimple_omp_parallel_set_child_fn (gimple g,
- tree child_fn)
- Set `CHILD_FN' to be the child function for `OMP_PARALLEL' `G'.
-
- -- GIMPLE function: tree gimple_omp_parallel_data_arg (gimple g)
- Return the artificial argument used to send variables and values
- from the parent to the children threads in `OMP_PARALLEL' `G'.
-
- -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr (gimple g)
- Return a pointer to the data argument for `OMP_PARALLEL' `G'.
-
- -- GIMPLE function: void gimple_omp_parallel_set_data_arg (gimple g,
- tree data_arg)
- Set `DATA_ARG' to be the data argument for `OMP_PARALLEL' `G'.
-
- -- GIMPLE function: bool is_gimple_omp (gimple stmt)
- Returns true when the gimple statement `STMT' is any of the OpenMP
- types.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_RETURN', Next: `GIMPLE_OMP_SECTION', Prev: `GIMPLE_OMP_PARALLEL', Up: Tuple specific accessors
-
-12.7.19 `GIMPLE_OMP_RETURN'
----------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p)
- Build a `GIMPLE_OMP_RETURN' statement. `WAIT_P' is true if this is
- a non-waiting return.
-
- -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s)
- Set the nowait flag on `GIMPLE_OMP_RETURN' statement `S'.
-
- -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g)
- Return true if `OMP' return statement `G' has the
- `GF_OMP_RETURN_NOWAIT' flag set.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_SECTION', Next: `GIMPLE_OMP_SECTIONS', Prev: `GIMPLE_OMP_RETURN', Up: Tuple specific accessors
-
-12.7.20 `GIMPLE_OMP_SECTION'
-----------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body)
- Build a `GIMPLE_OMP_SECTION' statement for a sections statement.
-
- `BODY' is the sequence of statements in the section.
-
- -- GIMPLE function: bool gimple_omp_section_last_p (gimple g)
- Return true if `OMP' section statement `G' has the
- `GF_OMP_SECTION_LAST' flag set.
-
- -- GIMPLE function: void gimple_omp_section_set_last (gimple g)
- Set the `GF_OMP_SECTION_LAST' flag on `G'.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_SECTIONS', Next: `GIMPLE_OMP_SINGLE', Prev: `GIMPLE_OMP_SECTION', Up: Tuple specific accessors
-
-12.7.21 `GIMPLE_OMP_SECTIONS'
------------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_sections (gimple_seq body,
- tree clauses)
- Build a `GIMPLE_OMP_SECTIONS' statement. `BODY' is a sequence of
- section statements. `CLAUSES' are any of the `OMP' sections
- construct's clauses: private, firstprivate, lastprivate,
- reduction, and nowait.
-
- -- GIMPLE function: gimple gimple_build_omp_sections_switch (void)
- Build a `GIMPLE_OMP_SECTIONS_SWITCH' statement.
-
- -- GIMPLE function: tree gimple_omp_sections_control (gimple g)
- Return the control variable associated with the
- `GIMPLE_OMP_SECTIONS' in `G'.
-
- -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g)
- Return a pointer to the clauses associated with the
- `GIMPLE_OMP_SECTIONS' in `G'.
-
- -- GIMPLE function: void gimple_omp_sections_set_control (gimple g,
- tree control)
- Set `CONTROL' to be the set of clauses associated with the
- `GIMPLE_OMP_SECTIONS' in `G'.
-
- -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g)
- Return the clauses associated with `OMP_SECTIONS' `G'.
-
- -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g)
- Return a pointer to the clauses associated with `OMP_SECTIONS' `G'.
-
- -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g,
- tree clauses)
- Set `CLAUSES' to be the set of clauses associated with
- `OMP_SECTIONS' `G'.
-
-
-File: gccint.info, Node: `GIMPLE_OMP_SINGLE', Next: `GIMPLE_PHI', Prev: `GIMPLE_OMP_SECTIONS', Up: Tuple specific accessors
-
-12.7.22 `GIMPLE_OMP_SINGLE'
----------------------------
-
- -- GIMPLE function: gimple gimple_build_omp_single (gimple_seq body,
- tree clauses)
- Build a `GIMPLE_OMP_SINGLE' statement. `BODY' is the sequence of
- statements that will be executed once. `CLAUSES' are any of the
- `OMP' single construct's clauses: private, firstprivate,
- copyprivate, nowait.
-
- -- GIMPLE function: tree gimple_omp_single_clauses (gimple g)
- Return the clauses associated with `OMP_SINGLE' `G'.
-
- -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g)
- Return a pointer to the clauses associated with `OMP_SINGLE' `G'.
-
- -- GIMPLE function: void gimple_omp_single_set_clauses (gimple g, tree
- clauses)
- Set `CLAUSES' to be the clauses associated with `OMP_SINGLE' `G'.
-
-
-File: gccint.info, Node: `GIMPLE_PHI', Next: `GIMPLE_RESX', Prev: `GIMPLE_OMP_SINGLE', Up: Tuple specific accessors
-
-12.7.23 `GIMPLE_PHI'
---------------------
-
- -- GIMPLE function: gimple make_phi_node (tree var, int len)
- Build a `PHI' node with len argument slots for variable var.
-
- -- GIMPLE function: unsigned gimple_phi_capacity (gimple g)
- Return the maximum number of arguments supported by `GIMPLE_PHI'
- `G'.
-
- -- GIMPLE function: unsigned gimple_phi_num_args (gimple g)
- Return the number of arguments in `GIMPLE_PHI' `G'. This must
- always be exactly the number of incoming edges for the basic block
- holding `G'.
-
- -- GIMPLE function: tree gimple_phi_result (gimple g)
- Return the `SSA' name created by `GIMPLE_PHI' `G'.
-
- -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g)
- Return a pointer to the `SSA' name created by `GIMPLE_PHI' `G'.
-
- -- GIMPLE function: void gimple_phi_set_result (gimple g, tree result)
- Set `RESULT' to be the `SSA' name created by `GIMPLE_PHI' `G'.
-
- -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index)
- Return the `PHI' argument corresponding to incoming edge `INDEX'
- for `GIMPLE_PHI' `G'.
-
- -- GIMPLE function: void gimple_phi_set_arg (gimple g, index, struct
- phi_arg_d * phiarg)
- Set `PHIARG' to be the argument corresponding to incoming edge
- `INDEX' for `GIMPLE_PHI' `G'.
-
-
-File: gccint.info, Node: `GIMPLE_RESX', Next: `GIMPLE_RETURN', Prev: `GIMPLE_PHI', Up: Tuple specific accessors
-
-12.7.24 `GIMPLE_RESX'
----------------------
-
- -- GIMPLE function: gimple gimple_build_resx (int region)
- Build a `GIMPLE_RESX' statement which is a statement. This
- statement is a placeholder for _Unwind_Resume before we know if a
- function call or a branch is needed. `REGION' is the exception
- region from which control is flowing.
-
- -- GIMPLE function: int gimple_resx_region (gimple g)
- Return the region number for `GIMPLE_RESX' `G'.
-
- -- GIMPLE function: void gimple_resx_set_region (gimple g, int region)
- Set `REGION' to be the region number for `GIMPLE_RESX' `G'.
-
-
-File: gccint.info, Node: `GIMPLE_RETURN', Next: `GIMPLE_SWITCH', Prev: `GIMPLE_RESX', Up: Tuple specific accessors
-
-12.7.25 `GIMPLE_RETURN'
------------------------
-
- -- GIMPLE function: gimple gimple_build_return (tree retval)
- Build a `GIMPLE_RETURN' statement whose return value is retval.
-
- -- GIMPLE function: tree gimple_return_retval (gimple g)
- Return the return value for `GIMPLE_RETURN' `G'.
-
- -- GIMPLE function: void gimple_return_set_retval (gimple g, tree
- retval)
- Set `RETVAL' to be the return value for `GIMPLE_RETURN' `G'.
-
-
-File: gccint.info, Node: `GIMPLE_SWITCH', Next: `GIMPLE_TRY', Prev: `GIMPLE_RETURN', Up: Tuple specific accessors
-
-12.7.26 `GIMPLE_SWITCH'
------------------------
-
- -- GIMPLE function: gimple gimple_build_switch (unsigned nlabels, tree
- index, tree default_label, ...)
- Build a `GIMPLE_SWITCH' statement. `NLABELS' are the number of
- labels excluding the default label. The default label is passed
- in `DEFAULT_LABEL'. The rest of the arguments are trees
- representing the labels. Each label is a tree of code
- `CASE_LABEL_EXPR'.
-
- -- GIMPLE function: gimple gimple_build_switch_vec (tree index, tree
- default_label, `VEC'(tree,heap) *args)
- This function is an alternate way of building `GIMPLE_SWITCH'
- statements. `INDEX' and `DEFAULT_LABEL' are as in
- gimple_build_switch. `ARGS' is a vector of `CASE_LABEL_EXPR' trees
- that contain the labels.
-
- -- GIMPLE function: unsigned gimple_switch_num_labels (gimple g)
- Return the number of labels associated with the switch statement
- `G'.
-
- -- GIMPLE function: void gimple_switch_set_num_labels (gimple g,
- unsigned nlabels)
- Set `NLABELS' to be the number of labels for the switch statement
- `G'.
-
- -- GIMPLE function: tree gimple_switch_index (gimple g)
- Return the index variable used by the switch statement `G'.
-
- -- GIMPLE function: void gimple_switch_set_index (gimple g, tree index)
- Set `INDEX' to be the index variable for switch statement `G'.
-
- -- GIMPLE function: tree gimple_switch_label (gimple g, unsigned index)
- Return the label numbered `INDEX'. The default label is 0, followed
- by any labels in a switch statement.
-
- -- GIMPLE function: void gimple_switch_set_label (gimple g, unsigned
- index, tree label)
- Set the label number `INDEX' to `LABEL'. 0 is always the default
- label.
-
- -- GIMPLE function: tree gimple_switch_default_label (gimple g)
- Return the default label for a switch statement.
-
- -- GIMPLE function: void gimple_switch_set_default_label (gimple g,
- tree label)
- Set the default label for a switch statement.
-
-
-File: gccint.info, Node: `GIMPLE_TRY', Next: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_SWITCH', Up: Tuple specific accessors
-
-12.7.27 `GIMPLE_TRY'
---------------------
-
- -- GIMPLE function: gimple gimple_build_try (gimple_seq eval,
- gimple_seq cleanup, unsigned int kind)
- Build a `GIMPLE_TRY' statement. `EVAL' is a sequence with the
- expression to evaluate. `CLEANUP' is a sequence of statements to
- run at clean-up time. `KIND' is the enumeration value
- `GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct
- or `GIMPLE_TRY_FINALLY' if this statement denotes a try/finally
- construct.
-
- -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g)
- Return the kind of try block represented by `GIMPLE_TRY' `G'. This
- is either `GIMPLE_TRY_CATCH' or `GIMPLE_TRY_FINALLY'.
-
- -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g)
- Return the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag.
-
- -- GIMPLE function: gimple_seq gimple_try_eval (gimple g)
- Return the sequence of statements used as the body for `GIMPLE_TRY'
- `G'.
-
- -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g)
- Return the sequence of statements used as the cleanup body for
- `GIMPLE_TRY' `G'.
-
- -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g,
- bool catch_is_cleanup)
- Set the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag.
-
- -- GIMPLE function: void gimple_try_set_eval (gimple g, gimple_seq
- eval)
- Set `EVAL' to be the sequence of statements to use as the body for
- `GIMPLE_TRY' `G'.
-
- -- GIMPLE function: void gimple_try_set_cleanup (gimple g, gimple_seq
- cleanup)
- Set `CLEANUP' to be the sequence of statements to use as the
- cleanup body for `GIMPLE_TRY' `G'.
-
-
-File: gccint.info, Node: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_TRY', Up: Tuple specific accessors
-
-12.7.28 `GIMPLE_WITH_CLEANUP_EXPR'
-----------------------------------
-
- -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup)
- Build a `GIMPLE_WITH_CLEANUP_EXPR' statement. `CLEANUP' is the
- clean-up expression.
-
- -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g)
- Return the cleanup sequence for cleanup statement `G'.
-
- -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq
- cleanup)
- Set `CLEANUP' to be the cleanup sequence for `G'.
-
- -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g)
- Return the `CLEANUP_EH_ONLY' flag for a `WCE' tuple.
-
- -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g,
- bool eh_only_p)
- Set the `CLEANUP_EH_ONLY' flag for a `WCE' tuple.
-
-
-File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE
-
-12.8 GIMPLE sequences
-=====================
-
-GIMPLE sequences are the tuple equivalent of `STATEMENT_LIST''s used in
-`GENERIC'. They are used to chain statements together, and when used
-in conjunction with sequence iterators, provide a framework for
-iterating through statements.
-
- GIMPLE sequences are of type struct `gimple_sequence', but are more
-commonly passed by reference to functions dealing with sequences. The
-type for a sequence pointer is `gimple_seq' which is the same as struct
-`gimple_sequence' *. When declaring a local sequence, you can define a
-local variable of type struct `gimple_sequence'. When declaring a
-sequence allocated on the garbage collected heap, use the function
-`gimple_seq_alloc' documented below.
-
- There are convenience functions for iterating through sequences in the
-section entitled Sequence Iterators.
-
- Below is a list of functions to manipulate and query sequences.
-
- -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple
- g)
- Link a gimple statement to the end of the sequence *`SEQ' if `G' is
- not `NULL'. If *`SEQ' is `NULL', allocate a sequence before
- linking.
-
- -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest,
- gimple_seq src)
- Append sequence `SRC' to the end of sequence *`DEST' if `SRC' is
- not `NULL'. If *`DEST' is `NULL', allocate a new sequence before
- appending.
-
- -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src)
- Perform a deep copy of sequence `SRC' and return the result.
-
- -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq)
- Reverse the order of the statements in the sequence `SEQ'. Return
- `SEQ'.
-
- -- GIMPLE function: gimple gimple_seq_first (gimple_seq s)
- Return the first statement in sequence `S'.
-
- -- GIMPLE function: gimple gimple_seq_last (gimple_seq s)
- Return the last statement in sequence `S'.
-
- -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple
- last)
- Set the last statement in sequence `S' to the statement in `LAST'.
-
- -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple
- first)
- Set the first statement in sequence `S' to the statement in
- `FIRST'.
-
- -- GIMPLE function: void gimple_seq_init (gimple_seq s)
- Initialize sequence `S' to an empty sequence.
-
- -- GIMPLE function: gimple_seq gimple_seq_alloc (void)
- Allocate a new sequence in the garbage collected store and return
- it.
-
- -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq
- src)
- Copy the sequence `SRC' into the sequence `DEST'.
-
- -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s)
- Return true if the sequence `S' is empty.
-
- -- GIMPLE function: gimple_seq bb_seq (basic_block bb)
- Returns the sequence of statements in `BB'.
-
- -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq)
- Sets the sequence of statements in `BB' to `SEQ'.
-
- -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq)
- Determine whether `SEQ' contains exactly one statement.
-
-
-File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE
-
-12.9 Sequence iterators
-=======================
-
-Sequence iterators are convenience constructs for iterating through
-statements in a sequence. Given a sequence `SEQ', here is a typical
-use of gimple sequence iterators:
-
- gimple_stmt_iterator gsi;
-
- for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi))
- {
- gimple g = gsi_stmt (gsi);
- /* Do something with gimple statement `G'. */
- }
-
- Backward iterations are possible:
-
- for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi))
-
- Forward and backward iterations on basic blocks are possible with
-`gsi_start_bb' and `gsi_last_bb'.
-
- In the documentation below we sometimes refer to enum
-`gsi_iterator_update'. The valid options for this enumeration are:
-
- * `GSI_NEW_STMT' Only valid when a single statement is added. Move
- the iterator to it.
-
- * `GSI_SAME_STMT' Leave the iterator at the same statement.
-
- * `GSI_CONTINUE_LINKING' Move iterator to whatever position is
- suitable for linking other statements in the same direction.
-
- Below is a list of the functions used to manipulate and use statement
-iterators.
-
- -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq)
- Return a new iterator pointing to the sequence `SEQ''s first
- statement. If `SEQ' is empty, the iterator's basic block is
- `NULL'. Use `gsi_start_bb' instead when the iterator needs to
- always have the correct basic block set.
-
- -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb)
- Return a new iterator pointing to the first statement in basic
- block `BB'.
-
- -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq)
- Return a new iterator initially pointing to the last statement of
- sequence `SEQ'. If `SEQ' is empty, the iterator's basic block is
- `NULL'. Use `gsi_last_bb' instead when the iterator needs to
- always have the correct basic block set.
-
- -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb)
- Return a new iterator pointing to the last statement in basic
- block `BB'.
-
- -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i)
- Return `TRUE' if at the end of `I'.
-
- -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i)
- Return `TRUE' if we're one statement before the end of `I'.
-
- -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i)
- Advance the iterator to the next gimple statement.
-
- -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i)
- Advance the iterator to the previous gimple statement.
-
- -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i)
- Return the current stmt.
-
- -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block
- bb)
- Return a block statement iterator that points to the first
- non-label statement in block `BB'.
-
- -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i)
- Return a pointer to the current stmt.
-
- -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i)
- Return the basic block associated with this iterator.
-
- -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i)
- Return the sequence associated with this iterator.
-
- -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool
- remove_eh_info)
- Remove the current stmt from the sequence. The iterator is
- updated to point to the next statement. When `REMOVE_EH_INFO' is
- true we remove the statement pointed to by iterator `I' from the
- `EH' tables. Otherwise we do not modify the `EH' tables.
- Generally, `REMOVE_EH_INFO' should be true when the statement is
- going to be removed from the `IL' and not reinserted elsewhere.
-
- -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i,
- gimple_seq seq, enum gsi_iterator_update mode)
- Links the sequence of statements `SEQ' before the statement pointed
- by iterator `I'. `MODE' indicates what to do with the iterator
- after insertion (see `enum gsi_iterator_update' above).
-
- -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i,
- gimple g, enum gsi_iterator_update mode)
- Links statement `G' before the statement pointed-to by iterator
- `I'. Updates iterator `I' according to `MODE'.
-
- -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i,
- gimple_seq seq, enum gsi_iterator_update mode)
- Links sequence `SEQ' after the statement pointed-to by iterator
- `I'. `MODE' is as in `gsi_insert_after'.
-
- -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i,
- gimple g, enum gsi_iterator_update mode)
- Links statement `G' after the statement pointed-to by iterator `I'.
- `MODE' is as in `gsi_insert_after'.
-
- -- GIMPLE function: gimple_seq gsi_split_seq_after
- (gimple_stmt_iterator i)
- Move all statements in the sequence after `I' to a new sequence.
- Return this new sequence.
-
- -- GIMPLE function: gimple_seq gsi_split_seq_before
- (gimple_stmt_iterator *i)
- Move all statements in the sequence before `I' to a new sequence.
- Return this new sequence.
-
- -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple
- stmt, bool update_eh_info)
- Replace the statement pointed-to by `I' to `STMT'. If
- `UPDATE_EH_INFO' is true, the exception handling information of
- the original statement is moved to the new statement.
-
- -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i,
- gimple stmt, enum gsi_iterator_update mode)
- Insert statement `STMT' before the statement pointed-to by iterator
- `I', update `STMT''s basic block and scan it for new operands.
- `MODE' specifies how to update iterator `I' after insertion (see
- enum `gsi_iterator_update').
-
- -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator
- *i, gimple_seq seq, enum gsi_iterator_update mode)
- Like `gsi_insert_before', but for all the statements in `SEQ'.
-
- -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i,
- gimple stmt, enum gsi_iterator_update mode)
- Insert statement `STMT' after the statement pointed-to by iterator
- `I', update `STMT''s basic block and scan it for new operands.
- `MODE' specifies how to update iterator `I' after insertion (see
- enum `gsi_iterator_update').
-
- -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator
- *i, gimple_seq seq, enum gsi_iterator_update mode)
- Like `gsi_insert_after', but for all the statements in `SEQ'.
-
- -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt)
- Finds iterator for `STMT'.
-
- -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from,
- gimple_stmt_iterator *to)
- Move the statement at `FROM' so it comes right after the statement
- at `TO'.
-
- -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from,
- gimple_stmt_iterator *to)
- Move the statement at `FROM' so it comes right before the statement
- at `TO'.
-
- -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator
- *from, basic_block bb)
- Move the statement at `FROM' to the end of basic block `BB'.
-
- -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt)
- Add `STMT' to the pending list of edge `E'. No actual insertion is
- made until a call to `gsi_commit_edge_inserts'() is made.
-
- -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq
- seq)
- Add the sequence of statements in `SEQ' to the pending list of edge
- `E'. No actual insertion is made until a call to
- `gsi_commit_edge_inserts'() is made.
-
- -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e,
- gimple stmt)
- Similar to `gsi_insert_on_edge'+`gsi_commit_edge_inserts'. If a
- new block has to be created, it is returned.
-
- -- GIMPLE function: void gsi_commit_one_edge_insert (edge e,
- basic_block *new_bb)
- Commit insertions pending at edge `E'. If a new block is created,
- set `NEW_BB' to this block, otherwise set it to `NULL'.
-
- -- GIMPLE function: void gsi_commit_edge_inserts (void)
- This routine will commit all pending edge insertions, creating any
- new basic blocks which are necessary.
-
-
-File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE
-
-12.10 Adding a new GIMPLE statement code
-========================================
-
-The first step in adding a new GIMPLE statement code, is modifying the
-file `gimple.def', which contains all the GIMPLE codes. Then you must
-add a corresponding structure, and an entry in `union
-gimple_statement_d', both of which are located in `gimple.h'. This in
-turn, will require you to add a corresponding `GTY' tag in
-`gsstruct.def', and code to handle this tag in `gss_for_code' which is
-located in `gimple.c'.
-
- In order for the garbage collector to know the size of the structure
-you created in `gimple.h', you need to add a case to handle your new
-GIMPLE statement in `gimple_size' which is located in `gimple.c'.
-
- You will probably want to create a function to build the new gimple
-statement in `gimple.c'. The function should be called
-`gimple_build_NEW-TUPLE-NAME', and should return the new tuple of type
-gimple.
-
- If your new statement requires accessors for any members or operands
-it may have, put simple inline accessors in `gimple.h' and any
-non-trivial accessors in `gimple.c' with a corresponding prototype in
-`gimple.h'.
-
-
-File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE
-
-12.11 Statement and operand traversals
-======================================
-
-There are two functions available for walking statements and sequences:
-`walk_gimple_stmt' and `walk_gimple_seq', accordingly, and a third
-function for walking the operands in a statement: `walk_gimple_op'.
-
- -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi,
- walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct
- walk_stmt_info *wi)
- This function is used to walk the current statement in `GSI',
- optionally using traversal state stored in `WI'. If `WI' is
- `NULL', no state is kept during the traversal.
-
- The callback `CALLBACK_STMT' is called. If `CALLBACK_STMT' returns
- true, it means that the callback function has handled all the
- operands of the statement and it is not necessary to walk its
- operands.
-
- If `CALLBACK_STMT' is `NULL' or it returns false, `CALLBACK_OP' is
- called on each operand of the statement via `walk_gimple_op'. If
- `walk_gimple_op' returns non-`NULL' for any operand, the remaining
- operands are not scanned.
-
- The return value is that returned by the last call to
- `walk_gimple_op', or `NULL_TREE' if no `CALLBACK_OP' is specified.
-
- -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn
- callback_op, struct walk_stmt_info *wi)
- Use this function to walk the operands of statement `STMT'. Every
- operand is walked via `walk_tree' with optional state information
- in `WI'.
-
- `CALLBACK_OP' is called on each operand of `STMT' via `walk_tree'.
- Additional parameters to `walk_tree' must be stored in `WI'. For
- each operand `OP', `walk_tree' is called as:
-
- walk_tree (&`OP', `CALLBACK_OP', `WI', `PSET')
-
- If `CALLBACK_OP' returns non-`NULL' for an operand, the remaining
- operands are not scanned. The return value is that returned by
- the last call to `walk_tree', or `NULL_TREE' if no `CALLBACK_OP' is
- specified.
-
- -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn
- callback_stmt, walk_tree_fn callback_op, struct
- walk_stmt_info *wi)
- This function walks all the statements in the sequence `SEQ'
- calling `walk_gimple_stmt' on each one. `WI' is as in
- `walk_gimple_stmt'. If `walk_gimple_stmt' returns non-`NULL', the
- walk is stopped and the value returned. Otherwise, all the
- statements are walked and `NULL_TREE' returned.
-
-
-File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top
-
-13 Analysis and Optimization of GIMPLE tuples
-*********************************************
-
-GCC uses three main intermediate languages to represent the program
-during compilation: GENERIC, GIMPLE and RTL. GENERIC is a
-language-independent representation generated by each front end. It is
-used to serve as an interface between the parser and optimizer.
-GENERIC is a common representation that is able to represent programs
-written in all the languages supported by GCC.
-
- GIMPLE and RTL are used to optimize the program. GIMPLE is used for
-target and language independent optimizations (e.g., inlining, constant
-propagation, tail call elimination, redundancy elimination, etc). Much
-like GENERIC, GIMPLE is a language independent, tree based
-representation. However, it differs from GENERIC in that the GIMPLE
-grammar is more restrictive: expressions contain no more than 3
-operands (except function calls), it has no control flow structures and
-expressions with side-effects are only allowed on the right hand side
-of assignments. See the chapter describing GENERIC and GIMPLE for more
-details.
-
- This chapter describes the data structures and functions used in the
-GIMPLE optimizers (also known as "tree optimizers" or "middle end").
-In particular, it focuses on all the macros, data structures, functions
-and programming constructs needed to implement optimization passes for
-GIMPLE.
-
-* Menu:
-
-* Annotations:: Attributes for variables.
-* SSA Operands:: SSA names referenced by GIMPLE statements.
-* SSA:: Static Single Assignment representation.
-* Alias analysis:: Representing aliased loads and stores.
-* Memory model:: Memory model used by the middle-end.
-
-
-File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA
-
-13.1 Annotations
-================
-
-The optimizers need to associate attributes with variables during the
-optimization process. For instance, we need to know whether a variable
-has aliases. All these attributes are stored in data structures called
-annotations which are then linked to the field `ann' in `struct
-tree_common'.
-
- Presently, we define annotations for variables (`var_ann_t').
-Annotations are defined and documented in `tree-flow.h'.
-
-
-File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA
-
-13.2 SSA Operands
-=================
-
-Almost every GIMPLE statement will contain a reference to a variable or
-memory location. Since statements come in different shapes and sizes,
-their operands are going to be located at various spots inside the
-statement's tree. To facilitate access to the statement's operands,
-they are organized into lists associated inside each statement's
-annotation. Each element in an operand list is a pointer to a
-`VAR_DECL', `PARM_DECL' or `SSA_NAME' tree node. This provides a very
-convenient way of examining and replacing operands.
-
- Data flow analysis and optimization is done on all tree nodes
-representing variables. Any node for which `SSA_VAR_P' returns nonzero
-is considered when scanning statement operands. However, not all
-`SSA_VAR_P' variables are processed in the same way. For the purposes
-of optimization, we need to distinguish between references to local
-scalar variables and references to globals, statics, structures,
-arrays, aliased variables, etc. The reason is simple, the compiler can
-gather complete data flow information for a local scalar. On the other
-hand, a global variable may be modified by a function call, it may not
-be possible to keep track of all the elements of an array or the fields
-of a structure, etc.
-
- The operand scanner gathers two kinds of operands: "real" and
-"virtual". An operand for which `is_gimple_reg' returns true is
-considered real, otherwise it is a virtual operand. We also
-distinguish between uses and definitions. An operand is used if its
-value is loaded by the statement (e.g., the operand at the RHS of an
-assignment). If the statement assigns a new value to the operand, the
-operand is considered a definition (e.g., the operand at the LHS of an
-assignment).
-
- Virtual and real operands also have very different data flow
-properties. Real operands are unambiguous references to the full
-object that they represent. For instance, given
-
- {
- int a, b;
- a = b
- }
-
- Since `a' and `b' are non-aliased locals, the statement `a = b' will
-have one real definition and one real use because variable `a' is
-completely modified with the contents of variable `b'. Real definition
-are also known as "killing definitions". Similarly, the use of `b'
-reads all its bits.
-
- In contrast, virtual operands are used with variables that can have a
-partial or ambiguous reference. This includes structures, arrays,
-globals, and aliased variables. In these cases, we have two types of
-definitions. For globals, structures, and arrays, we can determine from
-a statement whether a variable of these types has a killing definition.
-If the variable does, then the statement is marked as having a "must
-definition" of that variable. However, if a statement is only defining
-a part of the variable (i.e. a field in a structure), or if we know
-that a statement might define the variable but we cannot say for sure,
-then we mark that statement as having a "may definition". For
-instance, given
-
- {
- int a, b, *p;
-
- if (...)
- p = &a;
- else
- p = &b;
- *p = 5;
- return *p;
- }
-
- The assignment `*p = 5' may be a definition of `a' or `b'. If we
-cannot determine statically where `p' is pointing to at the time of the
-store operation, we create virtual definitions to mark that statement
-as a potential definition site for `a' and `b'. Memory loads are
-similarly marked with virtual use operands. Virtual operands are shown
-in tree dumps right before the statement that contains them. To
-request a tree dump with virtual operands, use the `-vops' option to
-`-fdump-tree':
-
- {
- int a, b, *p;
-
- if (...)
- p = &a;
- else
- p = &b;
- # a = VDEF <a>
- # b = VDEF <b>
- *p = 5;
-
- # VUSE <a>
- # VUSE <b>
- return *p;
- }
-
- Notice that `VDEF' operands have two copies of the referenced
-variable. This indicates that this is not a killing definition of that
-variable. In this case we refer to it as a "may definition" or
-"aliased store". The presence of the second copy of the variable in
-the `VDEF' operand will become important when the function is converted
-into SSA form. This will be used to link all the non-killing
-definitions to prevent optimizations from making incorrect assumptions
-about them.
-
- Operands are updated as soon as the statement is finished via a call
-to `update_stmt'. If statement elements are changed via `SET_USE' or
-`SET_DEF', then no further action is required (i.e., those macros take
-care of updating the statement). If changes are made by manipulating
-the statement's tree directly, then a call must be made to
-`update_stmt' when complete. Calling one of the `bsi_insert' routines
-or `bsi_replace' performs an implicit call to `update_stmt'.
-
-13.2.1 Operand Iterators And Access Routines
---------------------------------------------
-
-Operands are collected by `tree-ssa-operands.c'. They are stored
-inside each statement's annotation and can be accessed through either
-the operand iterators or an access routine.
-
- The following access routines are available for examining operands:
-
- 1. `SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return
- NULL unless there is exactly one operand matching the specified
- flags. If there is exactly one operand, the operand is returned
- as either a `tree', `def_operand_p', or `use_operand_p'.
-
- tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags);
- use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES);
- def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS);
-
- 2. `ZERO_SSA_OPERANDS': This macro returns true if there are no
- operands matching the specified flags.
-
- if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS))
- return;
-
- 3. `NUM_SSA_OPERANDS': This macro Returns the number of operands
- matching 'flags'. This actually executes a loop to perform the
- count, so only use this if it is really needed.
-
- int count = NUM_SSA_OPERANDS (stmt, flags)
-
- If you wish to iterate over some or all operands, use the
-`FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print
-all the operands for a statement:
-
- void
- print_ops (tree stmt)
- {
- ssa_op_iter;
- tree var;
-
- FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS)
- print_generic_expr (stderr, var, TDF_SLIM);
- }
-
- How to choose the appropriate iterator:
-
- 1. Determine whether you are need to see the operand pointers, or
- just the trees, and choose the appropriate macro:
-
- Need Macro:
- ---- -------
- use_operand_p FOR_EACH_SSA_USE_OPERAND
- def_operand_p FOR_EACH_SSA_DEF_OPERAND
- tree FOR_EACH_SSA_TREE_OPERAND
-
- 2. You need to declare a variable of the type you are interested in,
- and an ssa_op_iter structure which serves as the loop controlling
- variable.
-
- 3. Determine which operands you wish to use, and specify the flags of
- those you are interested in. They are documented in
- `tree-ssa-operands.h':
-
- #define SSA_OP_USE 0x01 /* Real USE operands. */
- #define SSA_OP_DEF 0x02 /* Real DEF operands. */
- #define SSA_OP_VUSE 0x04 /* VUSE operands. */
- #define SSA_OP_VMAYUSE 0x08 /* USE portion of VDEFS. */
- #define SSA_OP_VDEF 0x10 /* DEF portion of VDEFS. */
-
- /* These are commonly grouped operand flags. */
- #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE | SSA_OP_VMAYUSE)
- #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF)
- #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE)
- #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF)
- #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS)
-
- So if you want to look at the use pointers for all the `USE' and
-`VUSE' operands, you would do something like:
-
- use_operand_p use_p;
- ssa_op_iter iter;
-
- FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE))
- {
- process_use_ptr (use_p);
- }
-
- The `TREE' macro is basically the same as the `USE' and `DEF' macros,
-only with the use or def dereferenced via `USE_FROM_PTR (use_p)' and
-`DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use
-and defs flags can be mixed.
-
- tree var;
- ssa_op_iter iter;
-
- FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE)
- {
- print_generic_expr (stderr, var, TDF_SLIM);
- }
-
- `VDEF's are broken into two flags, one for the `DEF' portion
-(`SSA_OP_VDEF') and one for the USE portion (`SSA_OP_VMAYUSE'). If all
-you want to look at are the `VDEF's together, there is a fourth
-iterator macro for this, which returns both a def_operand_p and a
-use_operand_p for each `VDEF' in the statement. Note that you don't
-need any flags for this one.
-
- use_operand_p use_p;
- def_operand_p def_p;
- ssa_op_iter iter;
-
- FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter)
- {
- my_code;
- }
-
- There are many examples in the code as well, as well as the
-documentation in `tree-ssa-operands.h'.
-
- There are also a couple of variants on the stmt iterators regarding PHI
-nodes.
-
- `FOR_EACH_PHI_ARG' Works exactly like `FOR_EACH_SSA_USE_OPERAND',
-except it works over `PHI' arguments instead of statement operands.
-
- /* Look at every virtual PHI use. */
- FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES)
- {
- my_code;
- }
-
- /* Look at every real PHI use. */
- FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES)
- my_code;
-
- /* Look at every PHI use. */
- FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES)
- my_code;
-
- `FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like
-`FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a
-statement or a `PHI' node. These should be used when it is appropriate
-but they are not quite as efficient as the individual `FOR_EACH_PHI'
-and `FOR_EACH_SSA' routines.
-
- FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags)
- {
- my_code;
- }
-
- FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags)
- {
- my_code;
- }
-
-13.2.2 Immediate Uses
----------------------
-
-Immediate use information is now always available. Using the immediate
-use iterators, you may examine every use of any `SSA_NAME'. For
-instance, to change each use of `ssa_var' to `ssa_var2' and call
-fold_stmt on each stmt after that is done:
-
- use_operand_p imm_use_p;
- imm_use_iterator iterator;
- tree ssa_var, stmt;
-
-
- FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var)
- {
- FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator)
- SET_USE (imm_use_p, ssa_var_2);
- fold_stmt (stmt);
- }
-
- There are 2 iterators which can be used. `FOR_EACH_IMM_USE_FAST' is
-used when the immediate uses are not changed, i.e., you are looking at
-the uses, but not setting them.
-
- If they do get changed, then care must be taken that things are not
-changed under the iterators, so use the `FOR_EACH_IMM_USE_STMT' and
-`FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the
-sanity of the use list by moving all the uses for a statement into a
-controlled position, and then iterating over those uses. Then the
-optimization can manipulate the stmt when all the uses have been
-processed. This is a little slower than the FAST version since it adds
-a placeholder element and must sort through the list a bit for each
-statement. This placeholder element must be also be removed if the
-loop is terminated early. The macro `BREAK_FROM_IMM_USE_SAFE' is
-provided to do this :
-
- FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var)
- {
- if (stmt == last_stmt)
- BREAK_FROM_SAFE_IMM_USE (iter);
-
- FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator)
- SET_USE (imm_use_p, ssa_var_2);
- fold_stmt (stmt);
- }
-
- There are checks in `verify_ssa' which verify that the immediate use
-list is up to date, as well as checking that an optimization didn't
-break from the loop without using this macro. It is safe to simply
-'break'; from a `FOR_EACH_IMM_USE_FAST' traverse.
-
- Some useful functions and macros:
- 1. `has_zero_uses (ssa_var)' : Returns true if there are no uses of
- `ssa_var'.
-
- 2. `has_single_use (ssa_var)' : Returns true if there is only a
- single use of `ssa_var'.
-
- 3. `single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' :
- Returns true if there is only a single use of `ssa_var', and also
- returns the use pointer and statement it occurs in, in the second
- and third parameters.
-
- 4. `num_imm_uses (ssa_var)' : Returns the number of immediate uses of
- `ssa_var'. It is better not to use this if possible since it simply
- utilizes a loop to count the uses.
-
- 5. `PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a `PHI'
- node, return the index number for the use. An assert is triggered
- if the use isn't located in a `PHI' node.
-
- 6. `USE_STMT (use_p)' : Return the statement a use occurs in.
-
- Note that uses are not put into an immediate use list until their
-statement is actually inserted into the instruction stream via a
-`bsi_*' routine.
-
- It is also still possible to utilize lazy updating of statements, but
-this should be used only when absolutely required. Both alias analysis
-and the dominator optimizations currently do this.
-
- When lazy updating is being used, the immediate use information is out
-of date and cannot be used reliably. Lazy updating is achieved by
-simply marking statements modified via calls to `mark_stmt_modified'
-instead of `update_stmt'. When lazy updating is no longer required,
-all the modified statements must have `update_stmt' called in order to
-bring them up to date. This must be done before the optimization is
-finished, or `verify_ssa' will trigger an abort.
-
- This is done with a simple loop over the instruction stream:
- block_stmt_iterator bsi;
- basic_block bb;
- FOR_EACH_BB (bb)
- {
- for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
- update_stmt_if_modified (bsi_stmt (bsi));
- }
-
-
-File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA
-
-13.3 Static Single Assignment
-=============================
-
-Most of the tree optimizers rely on the data flow information provided
-by the Static Single Assignment (SSA) form. We implement the SSA form
-as described in `R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K.
-Zadeck. Efficiently Computing Static Single Assignment Form and the
-Control Dependence Graph. ACM Transactions on Programming Languages
-and Systems, 13(4):451-490, October 1991'.
-
- The SSA form is based on the premise that program variables are
-assigned in exactly one location in the program. Multiple assignments
-to the same variable create new versions of that variable. Naturally,
-actual programs are seldom in SSA form initially because variables tend
-to be assigned multiple times. The compiler modifies the program
-representation so that every time a variable is assigned in the code, a
-new version of the variable is created. Different versions of the same
-variable are distinguished by subscripting the variable name with its
-version number. Variables used in the right-hand side of expressions
-are renamed so that their version number matches that of the most
-recent assignment.
-
- We represent variable versions using `SSA_NAME' nodes. The renaming
-process in `tree-ssa.c' wraps every real and virtual operand with an
-`SSA_NAME' node which contains the version number and the statement
-that created the `SSA_NAME'. Only definitions and virtual definitions
-may create new `SSA_NAME' nodes.
-
- Sometimes, flow of control makes it impossible to determine the most
-recent version of a variable. In these cases, the compiler inserts an
-artificial definition for that variable called "PHI function" or "PHI
-node". This new definition merges all the incoming versions of the
-variable to create a new name for it. For instance,
-
- if (...)
- a_1 = 5;
- else if (...)
- a_2 = 2;
- else
- a_3 = 13;
-
- # a_4 = PHI <a_1, a_2, a_3>
- return a_4;
-
- Since it is not possible to determine which of the three branches will
-be taken at runtime, we don't know which of `a_1', `a_2' or `a_3' to
-use at the return statement. So, the SSA renamer creates a new version
-`a_4' which is assigned the result of "merging" `a_1', `a_2' and `a_3'.
-Hence, PHI nodes mean "one of these operands. I don't know which".
-
- The following macros can be used to examine PHI nodes
-
- -- Macro: PHI_RESULT (PHI)
- Returns the `SSA_NAME' created by PHI node PHI (i.e., PHI's LHS).
-
- -- Macro: PHI_NUM_ARGS (PHI)
- Returns the number of arguments in PHI. This number is exactly
- the number of incoming edges to the basic block holding PHI.
-
- -- Macro: PHI_ARG_ELT (PHI, I)
- Returns a tuple representing the Ith argument of PHI. Each
- element of this tuple contains an `SSA_NAME' VAR and the incoming
- edge through which VAR flows.
-
- -- Macro: PHI_ARG_EDGE (PHI, I)
- Returns the incoming edge for the Ith argument of PHI.
-
- -- Macro: PHI_ARG_DEF (PHI, I)
- Returns the `SSA_NAME' for the Ith argument of PHI.
-
-13.3.1 Preserving the SSA form
-------------------------------
-
-Some optimization passes make changes to the function that invalidate
-the SSA property. This can happen when a pass has added new symbols or
-changed the program so that variables that were previously aliased
-aren't anymore. Whenever something like this happens, the affected
-symbols must be renamed into SSA form again. Transformations that emit
-new code or replicate existing statements will also need to update the
-SSA form.
-
- Since GCC implements two different SSA forms for register and virtual
-variables, keeping the SSA form up to date depends on whether you are
-updating register or virtual names. In both cases, the general idea
-behind incremental SSA updates is similar: when new SSA names are
-created, they typically are meant to replace other existing names in
-the program.
-
- For instance, given the following code:
-
- 1 L0:
- 2 x_1 = PHI (0, x_5)
- 3 if (x_1 < 10)
- 4 if (x_1 > 7)
- 5 y_2 = 0
- 6 else
- 7 y_3 = x_1 + x_7
- 8 endif
- 9 x_5 = x_1 + 1
- 10 goto L0;
- 11 endif
-
- Suppose that we insert new names `x_10' and `x_11' (lines `4' and `8').
-
- 1 L0:
- 2 x_1 = PHI (0, x_5)
- 3 if (x_1 < 10)
- 4 x_10 = ...
- 5 if (x_1 > 7)
- 6 y_2 = 0
- 7 else
- 8 x_11 = ...
- 9 y_3 = x_1 + x_7
- 10 endif
- 11 x_5 = x_1 + 1
- 12 goto L0;
- 13 endif
-
- We want to replace all the uses of `x_1' with the new definitions of
-`x_10' and `x_11'. Note that the only uses that should be replaced are
-those at lines `5', `9' and `11'. Also, the use of `x_7' at line `9'
-should _not_ be replaced (this is why we cannot just mark symbol `x' for
-renaming).
-
- Additionally, we may need to insert a PHI node at line `11' because
-that is a merge point for `x_10' and `x_11'. So the use of `x_1' at
-line `11' will be replaced with the new PHI node. The insertion of PHI
-nodes is optional. They are not strictly necessary to preserve the SSA
-form, and depending on what the caller inserted, they may not even be
-useful for the optimizers.
-
- Updating the SSA form is a two step process. First, the pass has to
-identify which names need to be updated and/or which symbols need to be
-renamed into SSA form for the first time. When new names are
-introduced to replace existing names in the program, the mapping
-between the old and the new names are registered by calling
-`register_new_name_mapping' (note that if your pass creates new code by
-duplicating basic blocks, the call to `tree_duplicate_bb' will set up
-the necessary mappings automatically). On the other hand, if your pass
-exposes a new symbol that should be put in SSA form for the first time,
-the new symbol should be registered with `mark_sym_for_renaming'.
-
- After the replacement mappings have been registered and new symbols
-marked for renaming, a call to `update_ssa' makes the registered
-changes. This can be done with an explicit call or by creating `TODO'
-flags in the `tree_opt_pass' structure for your pass. There are
-several `TODO' flags that control the behavior of `update_ssa':
-
- * `TODO_update_ssa'. Update the SSA form inserting PHI nodes for
- newly exposed symbols and virtual names marked for updating. When
- updating real names, only insert PHI nodes for a real name `O_j'
- in blocks reached by all the new and old definitions for `O_j'.
- If the iterated dominance frontier for `O_j' is not pruned, we may
- end up inserting PHI nodes in blocks that have one or more edges
- with no incoming definition for `O_j'. This would lead to
- uninitialized warnings for `O_j''s symbol.
-
- * `TODO_update_ssa_no_phi'. Update the SSA form without inserting
- any new PHI nodes at all. This is used by passes that have either
- inserted all the PHI nodes themselves or passes that need only to
- patch use-def and def-def chains for virtuals (e.g., DCE).
-
- * `TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are
- needed. No pruning of the IDF is done. This is used by passes
- that need the PHI nodes for `O_j' even if it means that some
- arguments will come from the default definition of `O_j''s symbol
- (e.g., `pass_linear_transform').
-
- WARNING: If you need to use this flag, chances are that your pass
- may be doing something wrong. Inserting PHI nodes for an old name
- where not all edges carry a new replacement may lead to silent
- codegen errors or spurious uninitialized warnings.
-
- * `TODO_update_ssa_only_virtuals'. Passes that update the SSA form
- on their own may want to delegate the updating of virtual names to
- the generic updater. Since FUD chains are easier to maintain,
- this simplifies the work they need to do. NOTE: If this flag is
- used, any OLD->NEW mappings for real names are explicitly
- destroyed and only the symbols marked for renaming are processed.
-
-13.3.2 Preserving the virtual SSA form
---------------------------------------
-
-The virtual SSA form is harder to preserve than the non-virtual SSA form
-mainly because the set of virtual operands for a statement may change at
-what some would consider unexpected times. In general, statement
-modifications should be bracketed between calls to `push_stmt_changes'
-and `pop_stmt_changes'. For example,
-
- munge_stmt (tree stmt)
- {
- push_stmt_changes (&stmt);
- ... rewrite STMT ...
- pop_stmt_changes (&stmt);
- }
-
- The call to `push_stmt_changes' saves the current state of the
-statement operands and the call to `pop_stmt_changes' compares the
-saved state with the current one and does the appropriate symbol
-marking for the SSA renamer.
-
- It is possible to modify several statements at a time, provided that
-`push_stmt_changes' and `pop_stmt_changes' are called in LIFO order, as
-when processing a stack of statements.
-
- Additionally, if the pass discovers that it did not need to make
-changes to the statement after calling `push_stmt_changes', it can
-simply discard the topmost change buffer by calling
-`discard_stmt_changes'. This will avoid the expensive operand re-scan
-operation and the buffer comparison that determines if symbols need to
-be marked for renaming.
-
-13.3.3 Examining `SSA_NAME' nodes
----------------------------------
-
-The following macros can be used to examine `SSA_NAME' nodes
-
- -- Macro: SSA_NAME_DEF_STMT (VAR)
- Returns the statement S that creates the `SSA_NAME' VAR. If S is
- an empty statement (i.e., `IS_EMPTY_STMT (S)' returns `true'), it
- means that the first reference to this variable is a USE or a VUSE.
-
- -- Macro: SSA_NAME_VERSION (VAR)
- Returns the version number of the `SSA_NAME' object VAR.
-
-13.3.4 Walking use-def chains
------------------------------
-
- -- Tree SSA function: void walk_use_def_chains (VAR, FN, DATA)
- Walks use-def chains starting at the `SSA_NAME' node VAR. Calls
- function FN at each reaching definition found. Function FN takes
- three arguments: VAR, its defining statement (DEF_STMT) and a
- generic pointer to whatever state information that FN may want to
- maintain (DATA). Function FN is able to stop the walk by
- returning `true', otherwise in order to continue the walk, FN
- should return `false'.
-
- Note, that if DEF_STMT is a `PHI' node, the semantics are slightly
- different. For each argument ARG of the PHI node, this function
- will:
-
- 1. Walk the use-def chains for ARG.
-
- 2. Call `FN (ARG, PHI, DATA)'.
-
- Note how the first argument to FN is no longer the original
- variable VAR, but the PHI argument currently being examined. If
- FN wants to get at VAR, it should call `PHI_RESULT' (PHI).
-
-13.3.5 Walking the dominator tree
----------------------------------
-
- -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB)
- This function walks the dominator tree for the current CFG calling
- a set of callback functions defined in STRUCT DOM_WALK_DATA in
- `domwalk.h'. The call back functions you need to define give you
- hooks to execute custom code at various points during traversal:
-
- 1. Once to initialize any local data needed while processing BB
- and its children. This local data is pushed into an internal
- stack which is automatically pushed and popped as the walker
- traverses the dominator tree.
-
- 2. Once before traversing all the statements in the BB.
-
- 3. Once for every statement inside BB.
-
- 4. Once after traversing all the statements and before recursing
- into BB's dominator children.
-
- 5. It then recurses into all the dominator children of BB.
-
- 6. After recursing into all the dominator children of BB it can,
- optionally, traverse every statement in BB again (i.e.,
- repeating steps 2 and 3).
-
- 7. Once after walking the statements in BB and BB's dominator
- children. At this stage, the block local data stack is
- popped.
-
-
-File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA
-
-13.4 Alias analysis
-===================
-
-Alias analysis in GIMPLE SSA form consists of two pieces. First the
-virtual SSA web ties conflicting memory accesses and provides a SSA
-use-def chain and SSA immediate-use chains for walking possibly
-dependent memory accesses. Second an alias-oracle can be queried to
-disambiguate explicit and implicit memory references.
-
- 1. Memory SSA form.
-
- All statements that may use memory have exactly one accompanied
- use of a virtual SSA name that represents the state of memory at
- the given point in the IL.
-
- All statements that may define memory have exactly one accompanied
- definition of a virtual SSA name using the previous state of memory
- and defining the new state of memory after the given point in the
- IL.
-
- int i;
- int foo (void)
- {
- # .MEM_3 = VDEF <.MEM_2(D)>
- i = 1;
- # VUSE <.MEM_3>
- return i;
- }
-
- The virtual SSA names in this case are `.MEM_2(D)' and `.MEM_3'.
- The store to the global variable `i' defines `.MEM_3' invalidating
- `.MEM_2(D)'. The load from `i' uses that new state `.MEM_3'.
-
- The virtual SSA web serves as constraints to SSA optimizers
- preventing illegitimate code-motion and optimization. It also
- provides a way to walk related memory statements.
-
- 2. Points-to and escape analysis.
-
- Points-to analysis builds a set of constraints from the GIMPLE SSA
- IL representing all pointer operations and facts we do or do not
- know about pointers. Solving this set of constraints yields a
- conservatively correct solution for each pointer variable in the
- program (though we are only interested in SSA name pointers) as to
- what it may possibly point to.
-
- This points-to solution for a given SSA name pointer is stored in
- the `pt_solution' sub-structure of the `SSA_NAME_PTR_INFO' record.
- The following accessor functions are available:
-
- * `pt_solution_includes'
-
- * `pt_solutions_intersect'
-
- Points-to analysis also computes the solution for two special set
- of pointers, `ESCAPED' and `CALLUSED'. Those represent all memory
- that has escaped the scope of analysis or that is used by pure or
- nested const calls.
-
- 3. Type-based alias analysis
-
- Type-based alias analysis is frontend dependent though generic
- support is provided by the middle-end in `alias.c'. TBAA code is
- used by both tree optimizers and RTL optimizers.
-
- Every language that wishes to perform language-specific alias
- analysis should define a function that computes, given a `tree'
- node, an alias set for the node. Nodes in different alias sets
- are not allowed to alias. For an example, see the C front-end
- function `c_get_alias_set'.
-
- 4. Tree alias-oracle
-
- The tree alias-oracle provides means to disambiguate two memory
- references and memory references against statements. The following
- queries are available:
-
- * `refs_may_alias_p'
-
- * `ref_maybe_used_by_stmt_p'
-
- * `stmt_may_clobber_ref_p'
-
- In addition to those two kind of statement walkers are available
- walking statements related to a reference ref.
- `walk_non_aliased_vuses' walks over dominating memory defining
- statements and calls back if the statement does not clobber ref
- providing the non-aliased VUSE. The walk stops at the first
- clobbering statement or if asked to. `walk_aliased_vdefs' walks
- over dominating memory defining statements and calls back on each
- statement clobbering ref providing its aliasing VDEF. The walk
- stops if asked to.
-
-
-
-File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA
-
-13.5 Memory model
-=================
-
-The memory model used by the middle-end models that of the C/C++
-languages. The middle-end has the notion of an effective type of a
-memory region which is used for type-based alias analysis.
-
- The following is a refinement of ISO C99 6.5/6, clarifying the block
-copy case to follow common sense and extending the concept of a dynamic
-effective type to objects with a declared type as required for C++.
-
- The effective type of an object for an access to its stored value is
- the declared type of the object or the effective type determined by
- a previous store to it. If a value is stored into an object through
- an lvalue having a type that is not a character type, then the
- type of the lvalue becomes the effective type of the object for that
- access and for subsequent accesses that do not modify the stored value.
- If a value is copied into an object using `memcpy' or `memmove',
- or is copied as an array of character type, then the effective type
- of the modified object for that access and for subsequent accesses that
- do not modify the value is undetermined. For all other accesses to an
- object, the effective type of the object is simply the type of the
- lvalue used for the access.
-
-
-File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top
-
-14 Analysis and Representation of Loops
-***************************************
-
-GCC provides extensive infrastructure for work with natural loops, i.e.,
-strongly connected components of CFG with only one entry block. This
-chapter describes representation of loops in GCC, both on GIMPLE and in
-RTL, as well as the interfaces to loop-related analyses (induction
-variable analysis and number of iterations analysis).
-
-* Menu:
-
-* Loop representation:: Representation and analysis of loops.
-* Loop querying:: Getting information about loops.
-* Loop manipulation:: Loop manipulation functions.
-* LCSSA:: Loop-closed SSA form.
-* Scalar evolutions:: Induction variables on GIMPLE.
-* loop-iv:: Induction variables on RTL.
-* Number of iterations:: Number of iterations analysis.
-* Dependency analysis:: Data dependency analysis.
-* Lambda:: Linear loop transformations framework.
-* Omega:: A solver for linear programming problems.
-
-
-File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation
-
-14.1 Loop representation
-========================
-
-This chapter describes the representation of loops in GCC, and functions
-that can be used to build, modify and analyze this representation. Most
-of the interfaces and data structures are declared in `cfgloop.h'. At
-the moment, loop structures are analyzed and this information is
-updated only by the optimization passes that deal with loops, but some
-efforts are being made to make it available throughout most of the
-optimization passes.
-
- In general, a natural loop has one entry block (header) and possibly
-several back edges (latches) leading to the header from the inside of
-the loop. Loops with several latches may appear if several loops share
-a single header, or if there is a branching in the middle of the loop.
-The representation of loops in GCC however allows only loops with a
-single latch. During loop analysis, headers of such loops are split and
-forwarder blocks are created in order to disambiguate their structures.
-Heuristic based on profile information and structure of the induction
-variables in the loops is used to determine whether the latches
-correspond to sub-loops or to control flow in a single loop. This means
-that the analysis sometimes changes the CFG, and if you run it in the
-middle of an optimization pass, you must be able to deal with the new
-blocks. You may avoid CFG changes by passing
-`LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note
-however that most other loop manipulation functions will not work
-correctly for loops with multiple latch edges (the functions that only
-query membership of blocks to loops and subloop relationships, or
-enumerate and test loop exits, can be expected to work).
-
- Body of the loop is the set of blocks that are dominated by its header,
-and reachable from its latch against the direction of edges in CFG. The
-loops are organized in a containment hierarchy (tree) such that all the
-loops immediately contained inside loop L are the children of L in the
-tree. This tree is represented by the `struct loops' structure. The
-root of this tree is a fake loop that contains all blocks in the
-function. Each of the loops is represented in a `struct loop'
-structure. Each loop is assigned an index (`num' field of the `struct
-loop' structure), and the pointer to the loop is stored in the
-corresponding field of the `larray' vector in the loops structure. The
-indices do not have to be continuous, there may be empty (`NULL')
-entries in the `larray' created by deleting loops. Also, there is no
-guarantee on the relative order of a loop and its subloops in the
-numbering. The index of a loop never changes.
-
- The entries of the `larray' field should not be accessed directly.
-The function `get_loop' returns the loop description for a loop with
-the given index. `number_of_loops' function returns number of loops in
-the function. To traverse all loops, use `FOR_EACH_LOOP' macro. The
-`flags' argument of the macro is used to determine the direction of
-traversal and the set of loops visited. Each loop is guaranteed to be
-visited exactly once, regardless of the changes to the loop tree, and
-the loops may be removed during the traversal. The newly created loops
-are never traversed, if they need to be visited, this must be done
-separately after their creation. The `FOR_EACH_LOOP' macro allocates
-temporary variables. If the `FOR_EACH_LOOP' loop were ended using
-break or goto, they would not be released; `FOR_EACH_LOOP_BREAK' macro
-must be used instead.
-
- Each basic block contains the reference to the innermost loop it
-belongs to (`loop_father'). For this reason, it is only possible to
-have one `struct loops' structure initialized at the same time for each
-CFG. The global variable `current_loops' contains the `struct loops'
-structure. Many of the loop manipulation functions assume that
-dominance information is up-to-date.
-
- The loops are analyzed through `loop_optimizer_init' function. The
-argument of this function is a set of flags represented in an integer
-bitmask. These flags specify what other properties of the loop
-structures should be calculated/enforced and preserved later:
-
- * `LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes
- to CFG will be performed in the loop analysis, in particular,
- loops with multiple latch edges will not be disambiguated. If a
- loop has multiple latches, its latch block is set to NULL. Most of
- the loop manipulation functions will not work for loops in this
- shape. No other flags that require CFG changes can be passed to
- loop_optimizer_init.
-
- * `LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a
- way that each loop has only one entry edge, and additionally, the
- source block of this entry edge has only one successor. This
- creates a natural place where the code can be moved out of the
- loop, and ensures that the entry edge of the loop leads from its
- immediate super-loop.
-
- * `LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force
- the latch block of each loop to have only one successor. This
- ensures that the latch of the loop does not belong to any of its
- sub-loops, and makes manipulation with the loops significantly
- easier. Most of the loop manipulation functions assume that the
- loops are in this shape. Note that with this flag, the "normal"
- loop without any control flow inside and with one exit consists of
- two basic blocks.
-
- * `LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in
- the strongly connected components that are not natural loops (have
- more than one entry block) are marked with `BB_IRREDUCIBLE_LOOP'
- and `EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks
- and edges that belong to natural loops that are in such an
- irreducible region (but it is set for the entry and exit edges of
- such a loop, if they lead to/from this region).
-
- * `LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and
- updated for each loop. This makes some functions (e.g.,
- `get_loop_exit_edges') more efficient. Some functions (e.g.,
- `single_exit') can be used only if the lists of exits are recorded.
-
- These properties may also be computed/enforced later, using functions
-`create_preheaders', `force_single_succ_latches',
-`mark_irreducible_loops' and `record_loop_exits'.
-
- The memory occupied by the loops structures should be freed with
-`loop_optimizer_finalize' function.
-
- The CFG manipulation functions in general do not update loop
-structures. Specialized versions that additionally do so are provided
-for the most common tasks. On GIMPLE, `cleanup_tree_cfg_loop' function
-can be used to cleanup CFG while updating the loops structures if
-`current_loops' is set.
-
-
-File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation
-
-14.2 Loop querying
-==================
-
-The functions to query the information about loops are declared in
-`cfgloop.h'. Some of the information can be taken directly from the
-structures. `loop_father' field of each basic block contains the
-innermost loop to that the block belongs. The most useful fields of
-loop structure (that are kept up-to-date at all times) are:
-
- * `header', `latch': Header and latch basic blocks of the loop.
-
- * `num_nodes': Number of basic blocks in the loop (including the
- basic blocks of the sub-loops).
-
- * `depth': The depth of the loop in the loops tree, i.e., the number
- of super-loops of the loop.
-
- * `outer', `inner', `next': The super-loop, the first sub-loop, and
- the sibling of the loop in the loops tree.
-
- There are other fields in the loop structures, many of them used only
-by some of the passes, or not updated during CFG changes; in general,
-they should not be accessed directly.
-
- The most important functions to query loop structures are:
-
- * `flow_loops_dump': Dumps the information about loops to a file.
-
- * `verify_loop_structure': Checks consistency of the loop structures.
-
- * `loop_latch_edge': Returns the latch edge of a loop.
-
- * `loop_preheader_edge': If loops have preheaders, returns the
- preheader edge of a loop.
-
- * `flow_loop_nested_p': Tests whether loop is a sub-loop of another
- loop.
-
- * `flow_bb_inside_loop_p': Tests whether a basic block belongs to a
- loop (including its sub-loops).
-
- * `find_common_loop': Finds the common super-loop of two loops.
-
- * `superloop_at_depth': Returns the super-loop of a loop with the
- given depth.
-
- * `tree_num_loop_insns', `num_loop_insns': Estimates the number of
- insns in the loop, on GIMPLE and on RTL.
-
- * `loop_exit_edge_p': Tests whether edge is an exit from a loop.
-
- * `mark_loop_exit_edges': Marks all exit edges of all loops with
- `EDGE_LOOP_EXIT' flag.
-
- * `get_loop_body', `get_loop_body_in_dom_order',
- `get_loop_body_in_bfs_order': Enumerates the basic blocks in the
- loop in depth-first search order in reversed CFG, ordered by
- dominance relation, and breath-first search order, respectively.
-
- * `single_exit': Returns the single exit edge of the loop, or `NULL'
- if the loop has more than one exit. You can only use this
- function if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used.
-
- * `get_loop_exit_edges': Enumerates the exit edges of a loop.
-
- * `just_once_each_iteration_p': Returns true if the basic block is
- executed exactly once during each iteration of a loop (that is, it
- does not belong to a sub-loop, and it dominates the latch of the
- loop).
-
-
-File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation
-
-14.3 Loop manipulation
-======================
-
-The loops tree can be manipulated using the following functions:
-
- * `flow_loop_tree_node_add': Adds a node to the tree.
-
- * `flow_loop_tree_node_remove': Removes a node from the tree.
-
- * `add_bb_to_loop': Adds a basic block to a loop.
-
- * `remove_bb_from_loops': Removes a basic block from loops.
-
- Most low-level CFG functions update loops automatically. The following
-functions handle some more complicated cases of CFG manipulations:
-
- * `remove_path': Removes an edge and all blocks it dominates.
-
- * `split_loop_exit_edge': Splits exit edge of the loop, ensuring
- that PHI node arguments remain in the loop (this ensures that
- loop-closed SSA form is preserved). Only useful on GIMPLE.
-
- Finally, there are some higher-level loop transformations implemented.
-While some of them are written so that they should work on non-innermost
-loops, they are mostly untested in that case, and at the moment, they
-are only reliable for the innermost loops:
-
- * `create_iv': Creates a new induction variable. Only works on
- GIMPLE. `standard_iv_increment_position' can be used to find a
- suitable place for the iv increment.
-
- * `duplicate_loop_to_header_edge',
- `tree_duplicate_loop_to_header_edge': These functions (on RTL and
- on GIMPLE) duplicate the body of the loop prescribed number of
- times on one of the edges entering loop header, thus performing
- either loop unrolling or loop peeling. `can_duplicate_loop_p'
- (`can_unroll_loop_p' on GIMPLE) must be true for the duplicated
- loop.
-
- * `loop_version', `tree_ssa_loop_version': These function create a
- copy of a loop, and a branch before them that selects one of them
- depending on the prescribed condition. This is useful for
- optimizations that need to verify some assumptions in runtime (one
- of the copies of the loop is usually left unchanged, while the
- other one is transformed in some way).
-
- * `tree_unroll_loop': Unrolls the loop, including peeling the extra
- iterations to make the number of iterations divisible by unroll
- factor, updating the exit condition, and removing the exits that
- now cannot be taken. Works only on GIMPLE.
-
-
-File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation
-
-14.4 Loop-closed SSA form
-=========================
-
-Throughout the loop optimizations on tree level, one extra condition is
-enforced on the SSA form: No SSA name is used outside of the loop in
-that it is defined. The SSA form satisfying this condition is called
-"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be
-created at the exits of the loops for the SSA names that are used
-outside of them. Only the real operands (not virtual SSA names) are
-held in LCSSA, in order to save memory.
-
- There are various benefits of LCSSA:
-
- * Many optimizations (value range analysis, final value replacement)
- are interested in the values that are defined in the loop and used
- outside of it, i.e., exactly those for that we create new PHI
- nodes.
-
- * In induction variable analysis, it is not necessary to specify the
- loop in that the analysis should be performed - the scalar
- evolution analysis always returns the results with respect to the
- loop in that the SSA name is defined.
-
- * It makes updating of SSA form during loop transformations simpler.
- Without LCSSA, operations like loop unrolling may force creation
- of PHI nodes arbitrarily far from the loop, while in LCSSA, the
- SSA form can be updated locally. However, since we only keep real
- operands in LCSSA, we cannot use this advantage (we could have
- local updating of real operands, but it is not much more efficient
- than to use generic SSA form updating for it as well; the amount
- of changes to SSA is the same).
-
- However, it also means LCSSA must be updated. This is usually
-straightforward, unless you create a new value in loop and use it
-outside, or unless you manipulate loop exit edges (functions are
-provided to make these manipulations simple).
-`rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA,
-and `verify_loop_closed_ssa' to check that the invariant of LCSSA is
-preserved.
-
-
-File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation
-
-14.5 Scalar evolutions
-======================
-
-Scalar evolutions (SCEV) are used to represent results of induction
-variable analysis on GIMPLE. They enable us to represent variables with
-complicated behavior in a simple and consistent way (we only use it to
-express values of polynomial induction variables, but it is possible to
-extend it). The interfaces to SCEV analysis are declared in
-`tree-scalar-evolution.h'. To use scalar evolutions analysis,
-`scev_initialize' must be used. To stop using SCEV, `scev_finalize'
-should be used. SCEV analysis caches results in order to save time and
-memory. This cache however is made invalid by most of the loop
-transformations, including removal of code. If such a transformation
-is performed, `scev_reset' must be called to clean the caches.
-
- Given an SSA name, its behavior in loops can be analyzed using the
-`analyze_scalar_evolution' function. The returned SCEV however does
-not have to be fully analyzed and it may contain references to other
-SSA names defined in the loop. To resolve these (potentially
-recursive) references, `instantiate_parameters' or `resolve_mixers'
-functions must be used. `instantiate_parameters' is useful when you
-use the results of SCEV only for some analysis, and when you work with
-whole nest of loops at once. It will try replacing all SSA names by
-their SCEV in all loops, including the super-loops of the current loop,
-thus providing a complete information about the behavior of the
-variable in the loop nest. `resolve_mixers' is useful if you work with
-only one loop at a time, and if you possibly need to create code based
-on the value of the induction variable. It will only resolve the SSA
-names defined in the current loop, leaving the SSA names defined
-outside unchanged, even if their evolution in the outer loops is known.
-
- The SCEV is a normal tree expression, except for the fact that it may
-contain several special tree nodes. One of them is `SCEV_NOT_KNOWN',
-used for SSA names whose value cannot be expressed. The other one is
-`POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step
-and loop (both base and step may contain further polynomial chrecs).
-Type of the expression and of base and step must be the same. A
-variable has evolution `POLYNOMIAL_CHREC(base, step, loop)' if it is
-(in the specified loop) equivalent to `x_1' in the following example
-
- while (...)
- {
- x_1 = phi (base, x_2);
- x_2 = x_1 + step;
- }
-
- Note that this includes the language restrictions on the operations.
-For example, if we compile C code and `x' has signed type, then the
-overflow in addition would cause undefined behavior, and we may assume
-that this does not happen. Hence, the value with this SCEV cannot
-overflow (which restricts the number of iterations of such a loop).
-
- In many cases, one wants to restrict the attention just to affine
-induction variables. In this case, the extra expressive power of SCEV
-is not useful, and may complicate the optimizations. In this case,
-`simple_iv' function may be used to analyze a value - the result is a
-loop-invariant base and step.
-
-
-File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation
-
-14.6 IV analysis on RTL
-=======================
-
-The induction variable on RTL is simple and only allows analysis of
-affine induction variables, and only in one loop at once. The interface
-is declared in `cfgloop.h'. Before analyzing induction variables in a
-loop L, `iv_analysis_loop_init' function must be called on L. After
-the analysis (possibly calling `iv_analysis_loop_init' for several
-loops) is finished, `iv_analysis_done' should be called. The following
-functions can be used to access the results of the analysis:
-
- * `iv_analyze': Analyzes a single register used in the given insn.
- If no use of the register in this insn is found, the following
- insns are scanned, so that this function can be called on the insn
- returned by get_condition.
-
- * `iv_analyze_result': Analyzes result of the assignment in the
- given insn.
-
- * `iv_analyze_expr': Analyzes a more complicated expression. All
- its operands are analyzed by `iv_analyze', and hence they must be
- used in the specified insn or one of the following insns.
-
- The description of the induction variable is provided in `struct
-rtx_iv'. In order to handle subregs, the representation is a bit
-complicated; if the value of the `extend' field is not `UNKNOWN', the
-value of the induction variable in the i-th iteration is
-
- delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)),
-
- with the following exception: if `first_special' is true, then the
-value in the first iteration (when `i' is zero) is `delta + mult *
-base'. However, if `extend' is equal to `UNKNOWN', then
-`first_special' must be false, `delta' 0, `mult' 1 and the value in the
-i-th iteration is
-
- subreg_{mode} (base + i * step)
-
- The function `get_iv_value' can be used to perform these calculations.
-
-
-File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation
-
-14.7 Number of iterations analysis
-==================================
-
-Both on GIMPLE and on RTL, there are functions available to determine
-the number of iterations of a loop, with a similar interface. The
-number of iterations of a loop in GCC is defined as the number of
-executions of the loop latch. In many cases, it is not possible to
-determine the number of iterations unconditionally - the determined
-number is correct only if some assumptions are satisfied. The analysis
-tries to verify these conditions using the information contained in the
-program; if it fails, the conditions are returned together with the
-result. The following information and conditions are provided by the
-analysis:
-
- * `assumptions': If this condition is false, the rest of the
- information is invalid.
-
- * `noloop_assumptions' on RTL, `may_be_zero' on GIMPLE: If this
- condition is true, the loop exits in the first iteration.
-
- * `infinite': If this condition is true, the loop is infinite. This
- condition is only available on RTL. On GIMPLE, conditions for
- finiteness of the loop are included in `assumptions'.
-
- * `niter_expr' on RTL, `niter' on GIMPLE: The expression that gives
- number of iterations. The number of iterations is defined as the
- number of executions of the loop latch.
-
- Both on GIMPLE and on RTL, it necessary for the induction variable
-analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL).
-On GIMPLE, the results are stored to `struct tree_niter_desc'
-structure. Number of iterations before the loop is exited through a
-given exit can be determined using `number_of_iterations_exit'
-function. On RTL, the results are returned in `struct niter_desc'
-structure. The corresponding function is named `check_simple_exit'.
-There are also functions that pass through all the exits of a loop and
-try to find one with easy to determine number of iterations -
-`find_loop_niter' on GIMPLE and `find_simple_exit' on RTL. Finally,
-there are functions that provide the same information, but additionally
-cache it, so that repeated calls to number of iterations are not so
-costly - `number_of_latch_executions' on GIMPLE and
-`get_simple_loop_desc' on RTL.
-
- Note that some of these functions may behave slightly differently than
-others - some of them return only the expression for the number of
-iterations, and fail if there are some assumptions. The function
-`number_of_latch_executions' works only for single-exit loops. The
-function `number_of_cond_exit_executions' can be used to determine
-number of executions of the exit condition of a single-exit loop (i.e.,
-the `number_of_latch_executions' increased by one).
-
-
-File: gccint.info, Node: Dependency analysis, Next: Lambda, Prev: Number of iterations, Up: Loop Analysis and Representation
-
-14.8 Data Dependency Analysis
-=============================
-
-The code for the data dependence analysis can be found in
-`tree-data-ref.c' and its interface and data structures are described
-in `tree-data-ref.h'. The function that computes the data dependences
-for all the array and pointer references for a given loop is
-`compute_data_dependences_for_loop'. This function is currently used
-by the linear loop transform and the vectorization passes. Before
-calling this function, one has to allocate two vectors: a first vector
-will contain the set of data references that are contained in the
-analyzed loop body, and the second vector will contain the dependence
-relations between the data references. Thus if the vector of data
-references is of size `n', the vector containing the dependence
-relations will contain `n*n' elements. However if the analyzed loop
-contains side effects, such as calls that potentially can interfere
-with the data references in the current analyzed loop, the analysis
-stops while scanning the loop body for data references, and inserts a
-single `chrec_dont_know' in the dependence relation array.
-
- The data references are discovered in a particular order during the
-scanning of the loop body: the loop body is analyzed in execution order,
-and the data references of each statement are pushed at the end of the
-data reference array. Two data references syntactically occur in the
-program in the same order as in the array of data references. This
-syntactic order is important in some classical data dependence tests,
-and mapping this order to the elements of this array avoids costly
-queries to the loop body representation.
-
- Three types of data references are currently handled: ARRAY_REF,
-INDIRECT_REF and COMPONENT_REF. The data structure for the data
-reference is `data_reference', where `data_reference_p' is a name of a
-pointer to the data reference structure. The structure contains the
-following elements:
-
- * `base_object_info': Provides information about the base object of
- the data reference and its access functions. These access functions
- represent the evolution of the data reference in the loop relative
- to its base, in keeping with the classical meaning of the data
- reference access function for the support of arrays. For example,
- for a reference `a.b[i][j]', the base object is `a.b' and the
- access functions, one for each array subscript, are: `{i_init, +
- i_step}_1, {j_init, +, j_step}_2'.
-
- * `first_location_in_loop': Provides information about the first
- location accessed by the data reference in the loop and about the
- access function used to represent evolution relative to this
- location. This data is used to support pointers, and is not used
- for arrays (for which we have base objects). Pointer accesses are
- represented as a one-dimensional access that starts from the first
- location accessed in the loop. For example:
-
- for1 i
- for2 j
- *((int *)p + i + j) = a[i][j];
-
- The access function of the pointer access is `{0, + 4B}_for2'
- relative to `p + i'. The access functions of the array are
- `{i_init, + i_step}_for1' and `{j_init, +, j_step}_for2' relative
- to `a'.
-
- Usually, the object the pointer refers to is either unknown, or we
- can't prove that the access is confined to the boundaries of a
- certain object.
-
- Two data references can be compared only if at least one of these
- two representations has all its fields filled for both data
- references.
-
- The current strategy for data dependence tests is as follows: If
- both `a' and `b' are represented as arrays, compare
- `a.base_object' and `b.base_object'; if they are equal, apply
- dependence tests (use access functions based on base_objects).
- Else if both `a' and `b' are represented as pointers, compare
- `a.first_location' and `b.first_location'; if they are equal,
- apply dependence tests (use access functions based on first
- location). However, if `a' and `b' are represented differently,
- only try to prove that the bases are definitely different.
-
- * Aliasing information.
-
- * Alignment information.
-
- The structure describing the relation between two data references is
-`data_dependence_relation' and the shorter name for a pointer to such a
-structure is `ddr_p'. This structure contains:
-
- * a pointer to each data reference,
-
- * a tree node `are_dependent' that is set to `chrec_known' if the
- analysis has proved that there is no dependence between these two
- data references, `chrec_dont_know' if the analysis was not able to
- determine any useful result and potentially there could exist a
- dependence between these data references, and `are_dependent' is
- set to `NULL_TREE' if there exist a dependence relation between the
- data references, and the description of this dependence relation is
- given in the `subscripts', `dir_vects', and `dist_vects' arrays,
-
- * a boolean that determines whether the dependence relation can be
- represented by a classical distance vector,
-
- * an array `subscripts' that contains a description of each
- subscript of the data references. Given two array accesses a
- subscript is the tuple composed of the access functions for a given
- dimension. For example, given `A[f1][f2][f3]' and
- `B[g1][g2][g3]', there are three subscripts: `(f1, g1), (f2, g2),
- (f3, g3)'.
-
- * two arrays `dir_vects' and `dist_vects' that contain classical
- representations of the data dependences under the form of
- direction and distance dependence vectors,
-
- * an array of loops `loop_nest' that contains the loops to which the
- distance and direction vectors refer to.
-
- Several functions for pretty printing the information extracted by the
-data dependence analysis are available: `dump_ddrs' prints with a
-maximum verbosity the details of a data dependence relations array,
-`dump_dist_dir_vectors' prints only the classical distance and
-direction vectors for a data dependence relations array, and
-`dump_data_references' prints the details of the data references
-contained in a data reference array.
-
-
-File: gccint.info, Node: Lambda, Next: Omega, Prev: Dependency analysis, Up: Loop Analysis and Representation
-
-14.9 Linear loop transformations framework
-==========================================
-
-Lambda is a framework that allows transformations of loops using
-non-singular matrix based transformations of the iteration space and
-loop bounds. This allows compositions of skewing, scaling, interchange,
-and reversal transformations. These transformations are often used to
-improve cache behavior or remove inner loop dependencies to allow
-parallelization and vectorization to take place.
-
- To perform these transformations, Lambda requires that the loopnest be
-converted into an internal form that can be matrix transformed easily.
-To do this conversion, the function `gcc_loopnest_to_lambda_loopnest'
-is provided. If the loop cannot be transformed using lambda, this
-function will return NULL.
-
- Once a `lambda_loopnest' is obtained from the conversion function, it
-can be transformed by using `lambda_loopnest_transform', which takes a
-transformation matrix to apply. Note that it is up to the caller to
-verify that the transformation matrix is legal to apply to the loop
-(dependence respecting, etc). Lambda simply applies whatever matrix it
-is told to provide. It can be extended to make legal matrices out of
-any non-singular matrix, but this is not currently implemented.
-Legality of a matrix for a given loopnest can be verified using
-`lambda_transform_legal_p'.
-
- Given a transformed loopnest, conversion back into gcc IR is done by
-`lambda_loopnest_to_gcc_loopnest'. This function will modify the loops
-so that they match the transformed loopnest.
-
-
-File: gccint.info, Node: Omega, Prev: Lambda, Up: Loop Analysis and Representation
-
-14.10 Omega a solver for linear programming problems
-====================================================
-
-The data dependence analysis contains several solvers triggered
-sequentially from the less complex ones to the more sophisticated. For
-ensuring the consistency of the results of these solvers, a data
-dependence check pass has been implemented based on two different
-solvers. The second method that has been integrated to GCC is based on
-the Omega dependence solver, written in the 1990's by William Pugh and
-David Wonnacott. Data dependence tests can be formulated using a
-subset of the Presburger arithmetics that can be translated to linear
-constraint systems. These linear constraint systems can then be solved
-using the Omega solver.
-
- The Omega solver is using Fourier-Motzkin's algorithm for variable
-elimination: a linear constraint system containing `n' variables is
-reduced to a linear constraint system with `n-1' variables. The Omega
-solver can also be used for solving other problems that can be
-expressed under the form of a system of linear equalities and
-inequalities. The Omega solver is known to have an exponential worst
-case, also known under the name of "omega nightmare" in the literature,
-but in practice, the omega test is known to be efficient for the common
-data dependence tests.
-
- The interface used by the Omega solver for describing the linear
-programming problems is described in `omega.h', and the solver is
-`omega_solve_problem'.
-
-
-File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top
-
-15 Control Flow Graph
-*********************
-
-A control flow graph (CFG) is a data structure built on top of the
-intermediate code representation (the RTL or `tree' instruction stream)
-abstracting the control flow behavior of a function that is being
-compiled. The CFG is a directed graph where the vertices represent
-basic blocks and edges represent possible transfer of control flow from
-one basic block to another. The data structures used to represent the
-control flow graph are defined in `basic-block.h'.
-
-* Menu:
-
-* Basic Blocks:: The definition and representation of basic blocks.
-* Edges:: Types of edges and their representation.
-* Profile information:: Representation of frequencies and probabilities.
-* Maintaining the CFG:: Keeping the control flow graph and up to date.
-* Liveness information:: Using and maintaining liveness information.
-
-
-File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow
-
-15.1 Basic Blocks
-=================
-
-A basic block is a straight-line sequence of code with only one entry
-point and only one exit. In GCC, basic blocks are represented using
-the `basic_block' data type.
-
- Two pointer members of the `basic_block' structure are the pointers
-`next_bb' and `prev_bb'. These are used to keep doubly linked chain of
-basic blocks in the same order as the underlying instruction stream.
-The chain of basic blocks is updated transparently by the provided API
-for manipulating the CFG. The macro `FOR_EACH_BB' can be used to visit
-all the basic blocks in lexicographical order. Dominator traversals
-are also possible using `walk_dominator_tree'. Given two basic blocks
-A and B, block A dominates block B if A is _always_ executed before B.
-
- The `BASIC_BLOCK' array contains all basic blocks in an unspecified
-order. Each `basic_block' structure has a field that holds a unique
-integer identifier `index' that is the index of the block in the
-`BASIC_BLOCK' array. The total number of basic blocks in the function
-is `n_basic_blocks'. Both the basic block indices and the total number
-of basic blocks may vary during the compilation process, as passes
-reorder, create, duplicate, and destroy basic blocks. The index for
-any block should never be greater than `last_basic_block'.
-
- Special basic blocks represent possible entry and exit points of a
-function. These blocks are called `ENTRY_BLOCK_PTR' and
-`EXIT_BLOCK_PTR'. These blocks do not contain any code, and are not
-elements of the `BASIC_BLOCK' array. Therefore they have been assigned
-unique, negative index numbers.
-
- Each `basic_block' also contains pointers to the first instruction
-(the "head") and the last instruction (the "tail") or "end" of the
-instruction stream contained in a basic block. In fact, since the
-`basic_block' data type is used to represent blocks in both major
-intermediate representations of GCC (`tree' and RTL), there are
-pointers to the head and end of a basic block for both representations.
-
- For RTL, these pointers are `rtx head, end'. In the RTL function
-representation, the head pointer always points either to a
-`NOTE_INSN_BASIC_BLOCK' or to a `CODE_LABEL', if present. In the RTL
-representation of a function, the instruction stream contains not only
-the "real" instructions, but also "notes". Any function that moves or
-duplicates the basic blocks needs to take care of updating of these
-notes. Many of these notes expect that the instruction stream consists
-of linear regions, making such updates difficult. The
-`NOTE_INSN_BASIC_BLOCK' note is the only kind of note that may appear
-in the instruction stream contained in a basic block. The instruction
-stream of a basic block always follows a `NOTE_INSN_BASIC_BLOCK', but
-zero or more `CODE_LABEL' nodes can precede the block note. A basic
-block ends by control flow instruction or last instruction before
-following `CODE_LABEL' or `NOTE_INSN_BASIC_BLOCK'. A `CODE_LABEL'
-cannot appear in the instruction stream of a basic block.
-
- In addition to notes, the jump table vectors are also represented as
-"pseudo-instructions" inside the insn stream. These vectors never
-appear in the basic block and should always be placed just after the
-table jump instructions referencing them. After removing the
-table-jump it is often difficult to eliminate the code computing the
-address and referencing the vector, so cleaning up these vectors is
-postponed until after liveness analysis. Thus the jump table vectors
-may appear in the insn stream unreferenced and without any purpose.
-Before any edge is made "fall-thru", the existence of such construct in
-the way needs to be checked by calling `can_fallthru' function.
-
- For the `tree' representation, the head and end of the basic block are
-being pointed to by the `stmt_list' field, but this special `tree'
-should never be referenced directly. Instead, at the tree level
-abstract containers and iterators are used to access statements and
-expressions in basic blocks. These iterators are called "block
-statement iterators" (BSIs). Grep for `^bsi' in the various `tree-*'
-files. The following snippet will pretty-print all the statements of
-the program in the GIMPLE representation.
-
- FOR_EACH_BB (bb)
- {
- block_stmt_iterator si;
-
- for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si))
- {
- tree stmt = bsi_stmt (si);
- print_generic_stmt (stderr, stmt, 0);
- }
- }
-
-
-File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow
-
-15.2 Edges
-==========
-
-Edges represent possible control flow transfers from the end of some
-basic block A to the head of another basic block B. We say that A is a
-predecessor of B, and B is a successor of A. Edges are represented in
-GCC with the `edge' data type. Each `edge' acts as a link between two
-basic blocks: the `src' member of an edge points to the predecessor
-basic block of the `dest' basic block. The members `preds' and `succs'
-of the `basic_block' data type point to type-safe vectors of edges to
-the predecessors and successors of the block.
-
- When walking the edges in an edge vector, "edge iterators" should be
-used. Edge iterators are constructed using the `edge_iterator' data
-structure and several methods are available to operate on them:
-
-`ei_start'
- This function initializes an `edge_iterator' that points to the
- first edge in a vector of edges.
-
-`ei_last'
- This function initializes an `edge_iterator' that points to the
- last edge in a vector of edges.
-
-`ei_end_p'
- This predicate is `true' if an `edge_iterator' represents the last
- edge in an edge vector.
-
-`ei_one_before_end_p'
- This predicate is `true' if an `edge_iterator' represents the
- second last edge in an edge vector.
-
-`ei_next'
- This function takes a pointer to an `edge_iterator' and makes it
- point to the next edge in the sequence.
-
-`ei_prev'
- This function takes a pointer to an `edge_iterator' and makes it
- point to the previous edge in the sequence.
-
-`ei_edge'
- This function returns the `edge' currently pointed to by an
- `edge_iterator'.
-
-`ei_safe_safe'
- This function returns the `edge' currently pointed to by an
- `edge_iterator', but returns `NULL' if the iterator is pointing at
- the end of the sequence. This function has been provided for
- existing code makes the assumption that a `NULL' edge indicates
- the end of the sequence.
-
-
- The convenience macro `FOR_EACH_EDGE' can be used to visit all of the
-edges in a sequence of predecessor or successor edges. It must not be
-used when an element might be removed during the traversal, otherwise
-elements will be missed. Here is an example of how to use the macro:
-
- edge e;
- edge_iterator ei;
-
- FOR_EACH_EDGE (e, ei, bb->succs)
- {
- if (e->flags & EDGE_FALLTHRU)
- break;
- }
-
- There are various reasons why control flow may transfer from one block
-to another. One possibility is that some instruction, for example a
-`CODE_LABEL', in a linearized instruction stream just always starts a
-new basic block. In this case a "fall-thru" edge links the basic block
-to the first following basic block. But there are several other
-reasons why edges may be created. The `flags' field of the `edge' data
-type is used to store information about the type of edge we are dealing
-with. Each edge is of one of the following types:
-
-_jump_
- No type flags are set for edges corresponding to jump instructions.
- These edges are used for unconditional or conditional jumps and in
- RTL also for table jumps. They are the easiest to manipulate as
- they may be freely redirected when the flow graph is not in SSA
- form.
-
-_fall-thru_
- Fall-thru edges are present in case where the basic block may
- continue execution to the following one without branching. These
- edges have the `EDGE_FALLTHRU' flag set. Unlike other types of
- edges, these edges must come into the basic block immediately
- following in the instruction stream. The function
- `force_nonfallthru' is available to insert an unconditional jump
- in the case that redirection is needed. Note that this may
- require creation of a new basic block.
-
-_exception handling_
- Exception handling edges represent possible control transfers from
- a trapping instruction to an exception handler. The definition of
- "trapping" varies. In C++, only function calls can throw, but for
- Java, exceptions like division by zero or segmentation fault are
- defined and thus each instruction possibly throwing this kind of
- exception needs to be handled as control flow instruction.
- Exception edges have the `EDGE_ABNORMAL' and `EDGE_EH' flags set.
-
- When updating the instruction stream it is easy to change possibly
- trapping instruction to non-trapping, by simply removing the
- exception edge. The opposite conversion is difficult, but should
- not happen anyway. The edges can be eliminated via
- `purge_dead_edges' call.
-
- In the RTL representation, the destination of an exception edge is
- specified by `REG_EH_REGION' note attached to the insn. In case
- of a trapping call the `EDGE_ABNORMAL_CALL' flag is set too. In
- the `tree' representation, this extra flag is not set.
-
- In the RTL representation, the predicate `may_trap_p' may be used
- to check whether instruction still may trap or not. For the tree
- representation, the `tree_could_trap_p' predicate is available,
- but this predicate only checks for possible memory traps, as in
- dereferencing an invalid pointer location.
-
-_sibling calls_
- Sibling calls or tail calls terminate the function in a
- non-standard way and thus an edge to the exit must be present.
- `EDGE_SIBCALL' and `EDGE_ABNORMAL' are set in such case. These
- edges only exist in the RTL representation.
-
-_computed jumps_
- Computed jumps contain edges to all labels in the function
- referenced from the code. All those edges have `EDGE_ABNORMAL'
- flag set. The edges used to represent computed jumps often cause
- compile time performance problems, since functions consisting of
- many taken labels and many computed jumps may have _very_ dense
- flow graphs, so these edges need to be handled with special care.
- During the earlier stages of the compilation process, GCC tries to
- avoid such dense flow graphs by factoring computed jumps. For
- example, given the following series of jumps,
-
- goto *x;
- [ ... ]
-
- goto *x;
- [ ... ]
-
- goto *x;
- [ ... ]
-
- factoring the computed jumps results in the following code sequence
- which has a much simpler flow graph:
-
- goto y;
- [ ... ]
-
- goto y;
- [ ... ]
-
- goto y;
- [ ... ]
-
- y:
- goto *x;
-
- However, the classic problem with this transformation is that it
- has a runtime cost in there resulting code: An extra jump.
- Therefore, the computed jumps are un-factored in the later passes
- of the compiler. Be aware of that when you work on passes in that
- area. There have been numerous examples already where the compile
- time for code with unfactored computed jumps caused some serious
- headaches.
-
-_nonlocal goto handlers_
- GCC allows nested functions to return into caller using a `goto'
- to a label passed to as an argument to the callee. The labels
- passed to nested functions contain special code to cleanup after
- function call. Such sections of code are referred to as "nonlocal
- goto receivers". If a function contains such nonlocal goto
- receivers, an edge from the call to the label is created with the
- `EDGE_ABNORMAL' and `EDGE_ABNORMAL_CALL' flags set.
-
-_function entry points_
- By definition, execution of function starts at basic block 0, so
- there is always an edge from the `ENTRY_BLOCK_PTR' to basic block
- 0. There is no `tree' representation for alternate entry points at
- this moment. In RTL, alternate entry points are specified by
- `CODE_LABEL' with `LABEL_ALTERNATE_NAME' defined. This feature is
- currently used for multiple entry point prologues and is limited
- to post-reload passes only. This can be used by back-ends to emit
- alternate prologues for functions called from different contexts.
- In future full support for multiple entry functions defined by
- Fortran 90 needs to be implemented.
-
-_function exits_
- In the pre-reload representation a function terminates after the
- last instruction in the insn chain and no explicit return
- instructions are used. This corresponds to the fall-thru edge
- into exit block. After reload, optimal RTL epilogues are used
- that use explicit (conditional) return instructions that are
- represented by edges with no flags set.
-
-
-
-File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow
-
-15.3 Profile information
-========================
-
-In many cases a compiler must make a choice whether to trade speed in
-one part of code for speed in another, or to trade code size for code
-speed. In such cases it is useful to know information about how often
-some given block will be executed. That is the purpose for maintaining
-profile within the flow graph. GCC can handle profile information
-obtained through "profile feedback", but it can also estimate branch
-probabilities based on statics and heuristics.
-
- The feedback based profile is produced by compiling the program with
-instrumentation, executing it on a train run and reading the numbers of
-executions of basic blocks and edges back to the compiler while
-re-compiling the program to produce the final executable. This method
-provides very accurate information about where a program spends most of
-its time on the train run. Whether it matches the average run of
-course depends on the choice of train data set, but several studies
-have shown that the behavior of a program usually changes just
-marginally over different data sets.
-
- When profile feedback is not available, the compiler may be asked to
-attempt to predict the behavior of each branch in the program using a
-set of heuristics (see `predict.def' for details) and compute estimated
-frequencies of each basic block by propagating the probabilities over
-the graph.
-
- Each `basic_block' contains two integer fields to represent profile
-information: `frequency' and `count'. The `frequency' is an estimation
-how often is basic block executed within a function. It is represented
-as an integer scaled in the range from 0 to `BB_FREQ_BASE'. The most
-frequently executed basic block in function is initially set to
-`BB_FREQ_BASE' and the rest of frequencies are scaled accordingly.
-During optimization, the frequency of the most frequent basic block can
-both decrease (for instance by loop unrolling) or grow (for instance by
-cross-jumping optimization), so scaling sometimes has to be performed
-multiple times.
-
- The `count' contains hard-counted numbers of execution measured during
-training runs and is nonzero only when profile feedback is available.
-This value is represented as the host's widest integer (typically a 64
-bit integer) of the special type `gcov_type'.
-
- Most optimization passes can use only the frequency information of a
-basic block, but a few passes may want to know hard execution counts.
-The frequencies should always match the counts after scaling, however
-during updating of the profile information numerical error may
-accumulate into quite large errors.
-
- Each edge also contains a branch probability field: an integer in the
-range from 0 to `REG_BR_PROB_BASE'. It represents probability of
-passing control from the end of the `src' basic block to the `dest'
-basic block, i.e. the probability that control will flow along this
-edge. The `EDGE_FREQUENCY' macro is available to compute how
-frequently a given edge is taken. There is a `count' field for each
-edge as well, representing same information as for a basic block.
-
- The basic block frequencies are not represented in the instruction
-stream, but in the RTL representation the edge frequencies are
-represented for conditional jumps (via the `REG_BR_PROB' macro) since
-they are used when instructions are output to the assembly file and the
-flow graph is no longer maintained.
-
- The probability that control flow arrives via a given edge to its
-destination basic block is called "reverse probability" and is not
-directly represented, but it may be easily computed from frequencies of
-basic blocks.
-
- Updating profile information is a delicate task that can unfortunately
-not be easily integrated with the CFG manipulation API. Many of the
-functions and hooks to modify the CFG, such as
-`redirect_edge_and_branch', do not have enough information to easily
-update the profile, so updating it is in the majority of cases left up
-to the caller. It is difficult to uncover bugs in the profile updating
-code, because they manifest themselves only by producing worse code,
-and checking profile consistency is not possible because of numeric
-error accumulation. Hence special attention needs to be given to this
-issue in each pass that modifies the CFG.
-
- It is important to point out that `REG_BR_PROB_BASE' and
-`BB_FREQ_BASE' are both set low enough to be possible to compute second
-power of any frequency or probability in the flow graph, it is not
-possible to even square the `count' field, as modern CPUs are fast
-enough to execute $2^32$ operations quickly.
-
-
-File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow
-
-15.4 Maintaining the CFG
-========================
-
-An important task of each compiler pass is to keep both the control
-flow graph and all profile information up-to-date. Reconstruction of
-the control flow graph after each pass is not an option, since it may be
-very expensive and lost profile information cannot be reconstructed at
-all.
-
- GCC has two major intermediate representations, and both use the
-`basic_block' and `edge' data types to represent control flow. Both
-representations share as much of the CFG maintenance code as possible.
-For each representation, a set of "hooks" is defined so that each
-representation can provide its own implementation of CFG manipulation
-routines when necessary. These hooks are defined in `cfghooks.h'.
-There are hooks for almost all common CFG manipulations, including
-block splitting and merging, edge redirection and creating and deleting
-basic blocks. These hooks should provide everything you need to
-maintain and manipulate the CFG in both the RTL and `tree'
-representation.
-
- At the moment, the basic block boundaries are maintained transparently
-when modifying instructions, so there rarely is a need to move them
-manually (such as in case someone wants to output instruction outside
-basic block explicitly). Often the CFG may be better viewed as
-integral part of instruction chain, than structure built on the top of
-it. However, in principle the control flow graph for the `tree'
-representation is _not_ an integral part of the representation, in that
-a function tree may be expanded without first building a flow graph
-for the `tree' representation at all. This happens when compiling
-without any `tree' optimization enabled. When the `tree' optimizations
-are enabled and the instruction stream is rewritten in SSA form, the
-CFG is very tightly coupled with the instruction stream. In
-particular, statement insertion and removal has to be done with care.
-In fact, the whole `tree' representation can not be easily used or
-maintained without proper maintenance of the CFG simultaneously.
-
- In the RTL representation, each instruction has a `BLOCK_FOR_INSN'
-value that represents pointer to the basic block that contains the
-instruction. In the `tree' representation, the function `bb_for_stmt'
-returns a pointer to the basic block containing the queried statement.
-
- When changes need to be applied to a function in its `tree'
-representation, "block statement iterators" should be used. These
-iterators provide an integrated abstraction of the flow graph and the
-instruction stream. Block statement iterators are constructed using
-the `block_stmt_iterator' data structure and several modifier are
-available, including the following:
-
-`bsi_start'
- This function initializes a `block_stmt_iterator' that points to
- the first non-empty statement in a basic block.
-
-`bsi_last'
- This function initializes a `block_stmt_iterator' that points to
- the last statement in a basic block.
-
-`bsi_end_p'
- This predicate is `true' if a `block_stmt_iterator' represents the
- end of a basic block.
-
-`bsi_next'
- This function takes a `block_stmt_iterator' and makes it point to
- its successor.
-
-`bsi_prev'
- This function takes a `block_stmt_iterator' and makes it point to
- its predecessor.
-
-`bsi_insert_after'
- This function inserts a statement after the `block_stmt_iterator'
- passed in. The final parameter determines whether the statement
- iterator is updated to point to the newly inserted statement, or
- left pointing to the original statement.
-
-`bsi_insert_before'
- This function inserts a statement before the `block_stmt_iterator'
- passed in. The final parameter determines whether the statement
- iterator is updated to point to the newly inserted statement, or
- left pointing to the original statement.
-
-`bsi_remove'
- This function removes the `block_stmt_iterator' passed in and
- rechains the remaining statements in a basic block, if any.
-
- In the RTL representation, the macros `BB_HEAD' and `BB_END' may be
-used to get the head and end `rtx' of a basic block. No abstract
-iterators are defined for traversing the insn chain, but you can just
-use `NEXT_INSN' and `PREV_INSN' instead. *Note Insns::.
-
- Usually a code manipulating pass simplifies the instruction stream and
-the flow of control, possibly eliminating some edges. This may for
-example happen when a conditional jump is replaced with an
-unconditional jump, but also when simplifying possibly trapping
-instruction to non-trapping while compiling Java. Updating of edges is
-not transparent and each optimization pass is required to do so
-manually. However only few cases occur in practice. The pass may call
-`purge_dead_edges' on a given basic block to remove superfluous edges,
-if any.
-
- Another common scenario is redirection of branch instructions, but
-this is best modeled as redirection of edges in the control flow graph
-and thus use of `redirect_edge_and_branch' is preferred over more low
-level functions, such as `redirect_jump' that operate on RTL chain
-only. The CFG hooks defined in `cfghooks.h' should provide the
-complete API required for manipulating and maintaining the CFG.
-
- It is also possible that a pass has to insert control flow instruction
-into the middle of a basic block, thus creating an entry point in the
-middle of the basic block, which is impossible by definition: The block
-must be split to make sure it only has one entry point, i.e. the head
-of the basic block. The CFG hook `split_block' may be used when an
-instruction in the middle of a basic block has to become the target of
-a jump or branch instruction.
-
- For a global optimizer, a common operation is to split edges in the
-flow graph and insert instructions on them. In the RTL representation,
-this can be easily done using the `insert_insn_on_edge' function that
-emits an instruction "on the edge", caching it for a later
-`commit_edge_insertions' call that will take care of moving the
-inserted instructions off the edge into the instruction stream
-contained in a basic block. This includes the creation of new basic
-blocks where needed. In the `tree' representation, the equivalent
-functions are `bsi_insert_on_edge' which inserts a block statement
-iterator on an edge, and `bsi_commit_edge_inserts' which flushes the
-instruction to actual instruction stream.
-
- While debugging the optimization pass, a `verify_flow_info' function
-may be useful to find bugs in the control flow graph updating code.
-
- Note that at present, the representation of control flow in the `tree'
-representation is discarded before expanding to RTL. Long term the CFG
-should be maintained and "expanded" to the RTL representation along
-with the function `tree' itself.
-
-
-File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow
-
-15.5 Liveness information
-=========================
-
-Liveness information is useful to determine whether some register is
-"live" at given point of program, i.e. that it contains a value that
-may be used at a later point in the program. This information is used,
-for instance, during register allocation, as the pseudo registers only
-need to be assigned to a unique hard register or to a stack slot if
-they are live. The hard registers and stack slots may be freely reused
-for other values when a register is dead.
-
- Liveness information is available in the back end starting with
-`pass_df_initialize' and ending with `pass_df_finish'. Three flavors
-of live analysis are available: With `LR', it is possible to determine
-at any point `P' in the function if the register may be used on some
-path from `P' to the end of the function. With `UR', it is possible to
-determine if there is a path from the beginning of the function to `P'
-that defines the variable. `LIVE' is the intersection of the `LR' and
-`UR' and a variable is live at `P' if there is both an assignment that
-reaches it from the beginning of the function and a use that can be
-reached on some path from `P' to the end of the function.
-
- In general `LIVE' is the most useful of the three. The macros
-`DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The
-macros take a basic block number and return a bitmap that is indexed by
-the register number. This information is only guaranteed to be up to
-date after calls are made to `df_analyze'. See the file `df-core.c'
-for details on using the dataflow.
-
- The liveness information is stored partly in the RTL instruction stream
-and partly in the flow graph. Local information is stored in the
-instruction stream: Each instruction may contain `REG_DEAD' notes
-representing that the value of a given register is no longer needed, or
-`REG_UNUSED' notes representing that the value computed by the
-instruction is never used. The second is useful for instructions
-computing multiple values at once.
-
-
-File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top
-
-16 Machine Descriptions
-***********************
-
-A machine description has two parts: a file of instruction patterns
-(`.md' file) and a C header file of macro definitions.
-
- The `.md' file for a target machine contains a pattern for each
-instruction that the target machine supports (or at least each
-instruction that is worth telling the compiler about). It may also
-contain comments. A semicolon causes the rest of the line to be a
-comment, unless the semicolon is inside a quoted string.
-
- See the next chapter for information on the C header file.
-
-* Menu:
-
-* Overview:: How the machine description is used.
-* Patterns:: How to write instruction patterns.
-* Example:: An explained example of a `define_insn' pattern.
-* RTL Template:: The RTL template defines what insns match a pattern.
-* Output Template:: The output template says how to make assembler code
- from such an insn.
-* Output Statement:: For more generality, write C code to output
- the assembler code.
-* Predicates:: Controlling what kinds of operands can be used
- for an insn.
-* Constraints:: Fine-tuning operand selection.
-* Standard Names:: Names mark patterns to use for code generation.
-* Pattern Ordering:: When the order of patterns makes a difference.
-* Dependent Patterns:: Having one pattern may make you need another.
-* Jump Patterns:: Special considerations for patterns for jump insns.
-* Looping Patterns:: How to define patterns for special looping insns.
-* Insn Canonicalizations::Canonicalization of Instructions
-* Expander Definitions::Generating a sequence of several RTL insns
- for a standard operation.
-* Insn Splitting:: Splitting Instructions into Multiple Instructions.
-* Including Patterns:: Including Patterns in Machine Descriptions.
-* Peephole Definitions::Defining machine-specific peephole optimizations.
-* Insn Attributes:: Specifying the value of attributes for generated insns.
-* Conditional Execution::Generating `define_insn' patterns for
- predication.
-* Constant Definitions::Defining symbolic constants that can be used in the
- md file.
-* Iterators:: Using iterators to generate patterns from a template.
-
-
-File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc
-
-16.1 Overview of How the Machine Description is Used
-====================================================
-
-There are three main conversions that happen in the compiler:
-
- 1. The front end reads the source code and builds a parse tree.
-
- 2. The parse tree is used to generate an RTL insn list based on named
- instruction patterns.
-
- 3. The insn list is matched against the RTL templates to produce
- assembler code.
-
-
- For the generate pass, only the names of the insns matter, from either
-a named `define_insn' or a `define_expand'. The compiler will choose
-the pattern with the right name and apply the operands according to the
-documentation later in this chapter, without regard for the RTL
-template or operand constraints. Note that the names the compiler looks
-for are hard-coded in the compiler--it will ignore unnamed patterns and
-patterns with names it doesn't know about, but if you don't provide a
-named pattern it needs, it will abort.
-
- If a `define_insn' is used, the template given is inserted into the
-insn list. If a `define_expand' is used, one of three things happens,
-based on the condition logic. The condition logic may manually create
-new insns for the insn list, say via `emit_insn()', and invoke `DONE'.
-For certain named patterns, it may invoke `FAIL' to tell the compiler
-to use an alternate way of performing that task. If it invokes neither
-`DONE' nor `FAIL', the template given in the pattern is inserted, as if
-the `define_expand' were a `define_insn'.
-
- Once the insn list is generated, various optimization passes convert,
-replace, and rearrange the insns in the insn list. This is where the
-`define_split' and `define_peephole' patterns get used, for example.
-
- Finally, the insn list's RTL is matched up with the RTL templates in
-the `define_insn' patterns, and those patterns are used to emit the
-final assembly code. For this purpose, each named `define_insn' acts
-like it's unnamed, since the names are ignored.
-
-
-File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc
-
-16.2 Everything about Instruction Patterns
-==========================================
-
-Each instruction pattern contains an incomplete RTL expression, with
-pieces to be filled in later, operand constraints that restrict how the
-pieces can be filled in, and an output pattern or C code to generate
-the assembler output, all wrapped up in a `define_insn' expression.
-
- A `define_insn' is an RTL expression containing four or five operands:
-
- 1. An optional name. The presence of a name indicate that this
- instruction pattern can perform a certain standard job for the
- RTL-generation pass of the compiler. This pass knows certain
- names and will use the instruction patterns with those names, if
- the names are defined in the machine description.
-
- The absence of a name is indicated by writing an empty string
- where the name should go. Nameless instruction patterns are never
- used for generating RTL code, but they may permit several simpler
- insns to be combined later on.
-
- Names that are not thus known and used in RTL-generation have no
- effect; they are equivalent to no name at all.
-
- For the purpose of debugging the compiler, you may also specify a
- name beginning with the `*' character. Such a name is used only
- for identifying the instruction in RTL dumps; it is entirely
- equivalent to having a nameless pattern for all other purposes.
-
- 2. The "RTL template" (*note RTL Template::) is a vector of incomplete
- RTL expressions which show what the instruction should look like.
- It is incomplete because it may contain `match_operand',
- `match_operator', and `match_dup' expressions that stand for
- operands of the instruction.
-
- If the vector has only one element, that element is the template
- for the instruction pattern. If the vector has multiple elements,
- then the instruction pattern is a `parallel' expression containing
- the elements described.
-
- 3. A condition. This is a string which contains a C expression that
- is the final test to decide whether an insn body matches this
- pattern.
-
- For a named pattern, the condition (if present) may not depend on
- the data in the insn being matched, but only the
- target-machine-type flags. The compiler needs to test these
- conditions during initialization in order to learn exactly which
- named instructions are available in a particular run.
-
- For nameless patterns, the condition is applied only when matching
- an individual insn, and only after the insn has matched the
- pattern's recognition template. The insn's operands may be found
- in the vector `operands'. For an insn where the condition has
- once matched, it can't be used to control register allocation, for
- example by excluding certain hard registers or hard register
- combinations.
-
- 4. The "output template": a string that says how to output matching
- insns as assembler code. `%' in this string specifies where to
- substitute the value of an operand. *Note Output Template::.
-
- When simple substitution isn't general enough, you can specify a
- piece of C code to compute the output. *Note Output Statement::.
-
- 5. Optionally, a vector containing the values of attributes for insns
- matching this pattern. *Note Insn Attributes::.
-
-
-File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc
-
-16.3 Example of `define_insn'
-=============================
-
-Here is an actual example of an instruction pattern, for the
-68000/68020.
-
- (define_insn "tstsi"
- [(set (cc0)
- (match_operand:SI 0 "general_operand" "rm"))]
- ""
- "*
- {
- if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
- return \"tstl %0\";
- return \"cmpl #0,%0\";
- }")
-
-This can also be written using braced strings:
-
- (define_insn "tstsi"
- [(set (cc0)
- (match_operand:SI 0 "general_operand" "rm"))]
- ""
- {
- if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
- return "tstl %0";
- return "cmpl #0,%0";
- })
-
- This is an instruction that sets the condition codes based on the
-value of a general operand. It has no condition, so any insn whose RTL
-description has the form shown may be handled according to this
-pattern. The name `tstsi' means "test a `SImode' value" and tells the
-RTL generation pass that, when it is necessary to test such a value, an
-insn to do so can be constructed using this pattern.
-
- The output control string is a piece of C code which chooses which
-output template to return based on the kind of operand and the specific
-type of CPU for which code is being generated.
-
- `"rm"' is an operand constraint. Its meaning is explained below.
-
-
-File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc
-
-16.4 RTL Template
-=================
-
-The RTL template is used to define which insns match the particular
-pattern and how to find their operands. For named patterns, the RTL
-template also says how to construct an insn from specified operands.
-
- Construction involves substituting specified operands into a copy of
-the template. Matching involves determining the values that serve as
-the operands in the insn being matched. Both of these activities are
-controlled by special expression types that direct matching and
-substitution of the operands.
-
-`(match_operand:M N PREDICATE CONSTRAINT)'
- This expression is a placeholder for operand number N of the insn.
- When constructing an insn, operand number N will be substituted at
- this point. When matching an insn, whatever appears at this
- position in the insn will be taken as operand number N; but it
- must satisfy PREDICATE or this instruction pattern will not match
- at all.
-
- Operand numbers must be chosen consecutively counting from zero in
- each instruction pattern. There may be only one `match_operand'
- expression in the pattern for each operand number. Usually
- operands are numbered in the order of appearance in `match_operand'
- expressions. In the case of a `define_expand', any operand numbers
- used only in `match_dup' expressions have higher values than all
- other operand numbers.
-
- PREDICATE is a string that is the name of a function that accepts
- two arguments, an expression and a machine mode. *Note
- Predicates::. During matching, the function will be called with
- the putative operand as the expression and M as the mode argument
- (if M is not specified, `VOIDmode' will be used, which normally
- causes PREDICATE to accept any mode). If it returns zero, this
- instruction pattern fails to match. PREDICATE may be an empty
- string; then it means no test is to be done on the operand, so
- anything which occurs in this position is valid.
-
- Most of the time, PREDICATE will reject modes other than M--but
- not always. For example, the predicate `address_operand' uses M
- as the mode of memory ref that the address should be valid for.
- Many predicates accept `const_int' nodes even though their mode is
- `VOIDmode'.
-
- CONSTRAINT controls reloading and the choice of the best register
- class to use for a value, as explained later (*note Constraints::).
- If the constraint would be an empty string, it can be omitted.
-
- People are often unclear on the difference between the constraint
- and the predicate. The predicate helps decide whether a given
- insn matches the pattern. The constraint plays no role in this
- decision; instead, it controls various decisions in the case of an
- insn which does match.
-
-`(match_scratch:M N CONSTRAINT)'
- This expression is also a placeholder for operand number N and
- indicates that operand must be a `scratch' or `reg' expression.
-
- When matching patterns, this is equivalent to
-
- (match_operand:M N "scratch_operand" PRED)
-
- but, when generating RTL, it produces a (`scratch':M) expression.
-
- If the last few expressions in a `parallel' are `clobber'
- expressions whose operands are either a hard register or
- `match_scratch', the combiner can add or delete them when
- necessary. *Note Side Effects::.
-
-`(match_dup N)'
- This expression is also a placeholder for operand number N. It is
- used when the operand needs to appear more than once in the insn.
-
- In construction, `match_dup' acts just like `match_operand': the
- operand is substituted into the insn being constructed. But in
- matching, `match_dup' behaves differently. It assumes that operand
- number N has already been determined by a `match_operand'
- appearing earlier in the recognition template, and it matches only
- an identical-looking expression.
-
- Note that `match_dup' should not be used to tell the compiler that
- a particular register is being used for two operands (example:
- `add' that adds one register to another; the second register is
- both an input operand and the output operand). Use a matching
- constraint (*note Simple Constraints::) for those. `match_dup' is
- for the cases where one operand is used in two places in the
- template, such as an instruction that computes both a quotient and
- a remainder, where the opcode takes two input operands but the RTL
- template has to refer to each of those twice; once for the
- quotient pattern and once for the remainder pattern.
-
-`(match_operator:M N PREDICATE [OPERANDS...])'
- This pattern is a kind of placeholder for a variable RTL expression
- code.
-
- When constructing an insn, it stands for an RTL expression whose
- expression code is taken from that of operand N, and whose
- operands are constructed from the patterns OPERANDS.
-
- When matching an expression, it matches an expression if the
- function PREDICATE returns nonzero on that expression _and_ the
- patterns OPERANDS match the operands of the expression.
-
- Suppose that the function `commutative_operator' is defined as
- follows, to match any expression whose operator is one of the
- commutative arithmetic operators of RTL and whose mode is MODE:
-
- int
- commutative_integer_operator (x, mode)
- rtx x;
- enum machine_mode mode;
- {
- enum rtx_code code = GET_CODE (x);
- if (GET_MODE (x) != mode)
- return 0;
- return (GET_RTX_CLASS (code) == RTX_COMM_ARITH
- || code == EQ || code == NE);
- }
-
- Then the following pattern will match any RTL expression consisting
- of a commutative operator applied to two general operands:
-
- (match_operator:SI 3 "commutative_operator"
- [(match_operand:SI 1 "general_operand" "g")
- (match_operand:SI 2 "general_operand" "g")])
-
- Here the vector `[OPERANDS...]' contains two patterns because the
- expressions to be matched all contain two operands.
-
- When this pattern does match, the two operands of the commutative
- operator are recorded as operands 1 and 2 of the insn. (This is
- done by the two instances of `match_operand'.) Operand 3 of the
- insn will be the entire commutative expression: use `GET_CODE
- (operands[3])' to see which commutative operator was used.
-
- The machine mode M of `match_operator' works like that of
- `match_operand': it is passed as the second argument to the
- predicate function, and that function is solely responsible for
- deciding whether the expression to be matched "has" that mode.
-
- When constructing an insn, argument 3 of the gen-function will
- specify the operation (i.e. the expression code) for the
- expression to be made. It should be an RTL expression, whose
- expression code is copied into a new expression whose operands are
- arguments 1 and 2 of the gen-function. The subexpressions of
- argument 3 are not used; only its expression code matters.
-
- When `match_operator' is used in a pattern for matching an insn,
- it usually best if the operand number of the `match_operator' is
- higher than that of the actual operands of the insn. This improves
- register allocation because the register allocator often looks at
- operands 1 and 2 of insns to see if it can do register tying.
-
- There is no way to specify constraints in `match_operator'. The
- operand of the insn which corresponds to the `match_operator'
- never has any constraints because it is never reloaded as a whole.
- However, if parts of its OPERANDS are matched by `match_operand'
- patterns, those parts may have constraints of their own.
-
-`(match_op_dup:M N[OPERANDS...])'
- Like `match_dup', except that it applies to operators instead of
- operands. When constructing an insn, operand number N will be
- substituted at this point. But in matching, `match_op_dup' behaves
- differently. It assumes that operand number N has already been
- determined by a `match_operator' appearing earlier in the
- recognition template, and it matches only an identical-looking
- expression.
-
-`(match_parallel N PREDICATE [SUBPAT...])'
- This pattern is a placeholder for an insn that consists of a
- `parallel' expression with a variable number of elements. This
- expression should only appear at the top level of an insn pattern.
-
- When constructing an insn, operand number N will be substituted at
- this point. When matching an insn, it matches if the body of the
- insn is a `parallel' expression with at least as many elements as
- the vector of SUBPAT expressions in the `match_parallel', if each
- SUBPAT matches the corresponding element of the `parallel', _and_
- the function PREDICATE returns nonzero on the `parallel' that is
- the body of the insn. It is the responsibility of the predicate
- to validate elements of the `parallel' beyond those listed in the
- `match_parallel'.
-
- A typical use of `match_parallel' is to match load and store
- multiple expressions, which can contain a variable number of
- elements in a `parallel'. For example,
-
- (define_insn ""
- [(match_parallel 0 "load_multiple_operation"
- [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
- (match_operand:SI 2 "memory_operand" "m"))
- (use (reg:SI 179))
- (clobber (reg:SI 179))])]
- ""
- "loadm 0,0,%1,%2")
-
- This example comes from `a29k.md'. The function
- `load_multiple_operation' is defined in `a29k.c' and checks that
- subsequent elements in the `parallel' are the same as the `set' in
- the pattern, except that they are referencing subsequent registers
- and memory locations.
-
- An insn that matches this pattern might look like:
-
- (parallel
- [(set (reg:SI 20) (mem:SI (reg:SI 100)))
- (use (reg:SI 179))
- (clobber (reg:SI 179))
- (set (reg:SI 21)
- (mem:SI (plus:SI (reg:SI 100)
- (const_int 4))))
- (set (reg:SI 22)
- (mem:SI (plus:SI (reg:SI 100)
- (const_int 8))))])
-
-`(match_par_dup N [SUBPAT...])'
- Like `match_op_dup', but for `match_parallel' instead of
- `match_operator'.
-
-
-
-File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc
-
-16.5 Output Templates and Operand Substitution
-==============================================
-
-The "output template" is a string which specifies how to output the
-assembler code for an instruction pattern. Most of the template is a
-fixed string which is output literally. The character `%' is used to
-specify where to substitute an operand; it can also be used to identify
-places where different variants of the assembler require different
-syntax.
-
- In the simplest case, a `%' followed by a digit N says to output
-operand N at that point in the string.
-
- `%' followed by a letter and a digit says to output an operand in an
-alternate fashion. Four letters have standard, built-in meanings
-described below. The machine description macro `PRINT_OPERAND' can
-define additional letters with nonstandard meanings.
-
- `%cDIGIT' can be used to substitute an operand that is a constant
-value without the syntax that normally indicates an immediate operand.
-
- `%nDIGIT' is like `%cDIGIT' except that the value of the constant is
-negated before printing.
-
- `%aDIGIT' can be used to substitute an operand as if it were a memory
-reference, with the actual operand treated as the address. This may be
-useful when outputting a "load address" instruction, because often the
-assembler syntax for such an instruction requires you to write the
-operand as if it were a memory reference.
-
- `%lDIGIT' is used to substitute a `label_ref' into a jump instruction.
-
- `%=' outputs a number which is unique to each instruction in the
-entire compilation. This is useful for making local labels to be
-referred to more than once in a single template that generates multiple
-assembler instructions.
-
- `%' followed by a punctuation character specifies a substitution that
-does not use an operand. Only one case is standard: `%%' outputs a `%'
-into the assembler code. Other nonstandard cases can be defined in the
-`PRINT_OPERAND' macro. You must also define which punctuation
-characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro.
-
- The template may generate multiple assembler instructions. Write the
-text for the instructions, with `\;' between them.
-
- When the RTL contains two operands which are required by constraint to
-match each other, the output template must refer only to the
-lower-numbered operand. Matching operands are not always identical,
-and the rest of the compiler arranges to put the proper RTL expression
-for printing into the lower-numbered operand.
-
- One use of nonstandard letters or punctuation following `%' is to
-distinguish between different assembler languages for the same machine;
-for example, Motorola syntax versus MIT syntax for the 68000. Motorola
-syntax requires periods in most opcode names, while MIT syntax does
-not. For example, the opcode `movel' in MIT syntax is `move.l' in
-Motorola syntax. The same file of patterns is used for both kinds of
-output syntax, but the character sequence `%.' is used in each place
-where Motorola syntax wants a period. The `PRINT_OPERAND' macro for
-Motorola syntax defines the sequence to output a period; the macro for
-MIT syntax defines it to do nothing.
-
- As a special case, a template consisting of the single character `#'
-instructs the compiler to first split the insn, and then output the
-resulting instructions separately. This helps eliminate redundancy in
-the output templates. If you have a `define_insn' that needs to emit
-multiple assembler instructions, and there is a matching `define_split'
-already defined, then you can simply use `#' as the output template
-instead of writing an output template that emits the multiple assembler
-instructions.
-
- If the macro `ASSEMBLER_DIALECT' is defined, you can use construct of
-the form `{option0|option1|option2}' in the templates. These describe
-multiple variants of assembler language syntax. *Note Instruction
-Output::.
-
-
-File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc
-
-16.6 C Statements for Assembler Output
-======================================
-
-Often a single fixed template string cannot produce correct and
-efficient assembler code for all the cases that are recognized by a
-single instruction pattern. For example, the opcodes may depend on the
-kinds of operands; or some unfortunate combinations of operands may
-require extra machine instructions.
-
- If the output control string starts with a `@', then it is actually a
-series of templates, each on a separate line. (Blank lines and leading
-spaces and tabs are ignored.) The templates correspond to the
-pattern's constraint alternatives (*note Multi-Alternative::). For
-example, if a target machine has a two-address add instruction `addr'
-to add into a register and another `addm' to add a register to memory,
-you might write this pattern:
-
- (define_insn "addsi3"
- [(set (match_operand:SI 0 "general_operand" "=r,m")
- (plus:SI (match_operand:SI 1 "general_operand" "0,0")
- (match_operand:SI 2 "general_operand" "g,r")))]
- ""
- "@
- addr %2,%0
- addm %2,%0")
-
- If the output control string starts with a `*', then it is not an
-output template but rather a piece of C program that should compute a
-template. It should execute a `return' statement to return the
-template-string you want. Most such templates use C string literals,
-which require doublequote characters to delimit them. To include these
-doublequote characters in the string, prefix each one with `\'.
-
- If the output control string is written as a brace block instead of a
-double-quoted string, it is automatically assumed to be C code. In that
-case, it is not necessary to put in a leading asterisk, or to escape the
-doublequotes surrounding C string literals.
-
- The operands may be found in the array `operands', whose C data type
-is `rtx []'.
-
- It is very common to select different ways of generating assembler code
-based on whether an immediate operand is within a certain range. Be
-careful when doing this, because the result of `INTVAL' is an integer
-on the host machine. If the host machine has more bits in an `int'
-than the target machine has in the mode in which the constant will be
-used, then some of the bits you get from `INTVAL' will be superfluous.
-For proper results, you must carefully disregard the values of those
-bits.
-
- It is possible to output an assembler instruction and then go on to
-output or compute more of them, using the subroutine `output_asm_insn'.
-This receives two arguments: a template-string and a vector of
-operands. The vector may be `operands', or it may be another array of
-`rtx' that you declare locally and initialize yourself.
-
- When an insn pattern has multiple alternatives in its constraints,
-often the appearance of the assembler code is determined mostly by
-which alternative was matched. When this is so, the C code can test
-the variable `which_alternative', which is the ordinal number of the
-alternative that was actually satisfied (0 for the first, 1 for the
-second alternative, etc.).
-
- For example, suppose there are two opcodes for storing zero, `clrreg'
-for registers and `clrmem' for memory locations. Here is how a pattern
-could use `which_alternative' to choose between them:
-
- (define_insn ""
- [(set (match_operand:SI 0 "general_operand" "=r,m")
- (const_int 0))]
- ""
- {
- return (which_alternative == 0
- ? "clrreg %0" : "clrmem %0");
- })
-
- The example above, where the assembler code to generate was _solely_
-determined by the alternative, could also have been specified as
-follows, having the output control string start with a `@':
-
- (define_insn ""
- [(set (match_operand:SI 0 "general_operand" "=r,m")
- (const_int 0))]
- ""
- "@
- clrreg %0
- clrmem %0")
-
-
-File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc
-
-16.7 Predicates
-===============
-
-A predicate determines whether a `match_operand' or `match_operator'
-expression matches, and therefore whether the surrounding instruction
-pattern will be used for that combination of operands. GCC has a
-number of machine-independent predicates, and you can define
-machine-specific predicates as needed. By convention, predicates used
-with `match_operand' have names that end in `_operand', and those used
-with `match_operator' have names that end in `_operator'.
-
- All predicates are Boolean functions (in the mathematical sense) of
-two arguments: the RTL expression that is being considered at that
-position in the instruction pattern, and the machine mode that the
-`match_operand' or `match_operator' specifies. In this section, the
-first argument is called OP and the second argument MODE. Predicates
-can be called from C as ordinary two-argument functions; this can be
-useful in output templates or other machine-specific code.
-
- Operand predicates can allow operands that are not actually acceptable
-to the hardware, as long as the constraints give reload the ability to
-fix them up (*note Constraints::). However, GCC will usually generate
-better code if the predicates specify the requirements of the machine
-instructions as closely as possible. Reload cannot fix up operands
-that must be constants ("immediate operands"); you must use a predicate
-that allows only constants, or else enforce the requirement in the
-extra condition.
-
- Most predicates handle their MODE argument in a uniform manner. If
-MODE is `VOIDmode' (unspecified), then OP can have any mode. If MODE
-is anything else, then OP must have the same mode, unless OP is a
-`CONST_INT' or integer `CONST_DOUBLE'. These RTL expressions always
-have `VOIDmode', so it would be counterproductive to check that their
-mode matches. Instead, predicates that accept `CONST_INT' and/or
-integer `CONST_DOUBLE' check that the value stored in the constant will
-fit in the requested mode.
-
- Predicates with this behavior are called "normal". `genrecog' can
-optimize the instruction recognizer based on knowledge of how normal
-predicates treat modes. It can also diagnose certain kinds of common
-errors in the use of normal predicates; for instance, it is almost
-always an error to use a normal predicate without specifying a mode.
-
- Predicates that do something different with their MODE argument are
-called "special". The generic predicates `address_operand' and
-`pmode_register_operand' are special predicates. `genrecog' does not
-do any optimizations or diagnosis when special predicates are used.
-
-* Menu:
-
-* Machine-Independent Predicates:: Predicates available to all back ends.
-* Defining Predicates:: How to write machine-specific predicate
- functions.
-
-
-File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates
-
-16.7.1 Machine-Independent Predicates
--------------------------------------
-
-These are the generic predicates available to all back ends. They are
-defined in `recog.c'. The first category of predicates allow only
-constant, or "immediate", operands.
-
- -- Function: immediate_operand
- This predicate allows any sort of constant that fits in MODE. It
- is an appropriate choice for instructions that take operands that
- must be constant.
-
- -- Function: const_int_operand
- This predicate allows any `CONST_INT' expression that fits in
- MODE. It is an appropriate choice for an immediate operand that
- does not allow a symbol or label.
-
- -- Function: const_double_operand
- This predicate accepts any `CONST_DOUBLE' expression that has
- exactly MODE. If MODE is `VOIDmode', it will also accept
- `CONST_INT'. It is intended for immediate floating point
- constants.
-
-The second category of predicates allow only some kind of machine
-register.
-
- -- Function: register_operand
- This predicate allows any `REG' or `SUBREG' expression that is
- valid for MODE. It is often suitable for arithmetic instruction
- operands on a RISC machine.
-
- -- Function: pmode_register_operand
- This is a slight variant on `register_operand' which works around
- a limitation in the machine-description reader.
-
- (match_operand N "pmode_register_operand" CONSTRAINT)
-
- means exactly what
-
- (match_operand:P N "register_operand" CONSTRAINT)
-
- would mean, if the machine-description reader accepted `:P' mode
- suffixes. Unfortunately, it cannot, because `Pmode' is an alias
- for some other mode, and might vary with machine-specific options.
- *Note Misc::.
-
- -- Function: scratch_operand
- This predicate allows hard registers and `SCRATCH' expressions,
- but not pseudo-registers. It is used internally by
- `match_scratch'; it should not be used directly.
-
-The third category of predicates allow only some kind of memory
-reference.
-
- -- Function: memory_operand
- This predicate allows any valid reference to a quantity of mode
- MODE in memory, as determined by the weak form of
- `GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::).
-
- -- Function: address_operand
- This predicate is a little unusual; it allows any operand that is a
- valid expression for the _address_ of a quantity of mode MODE,
- again determined by the weak form of `GO_IF_LEGITIMATE_ADDRESS'.
- To first order, if `(mem:MODE (EXP))' is acceptable to
- `memory_operand', then EXP is acceptable to `address_operand'.
- Note that EXP does not necessarily have the mode MODE.
-
- -- Function: indirect_operand
- This is a stricter form of `memory_operand' which allows only
- memory references with a `general_operand' as the address
- expression. New uses of this predicate are discouraged, because
- `general_operand' is very permissive, so it's hard to tell what an
- `indirect_operand' does or does not allow. If a target has
- different requirements for memory operands for different
- instructions, it is better to define target-specific predicates
- which enforce the hardware's requirements explicitly.
-
- -- Function: push_operand
- This predicate allows a memory reference suitable for pushing a
- value onto the stack. This will be a `MEM' which refers to
- `stack_pointer_rtx', with a side-effect in its address expression
- (*note Incdec::); which one is determined by the `STACK_PUSH_CODE'
- macro (*note Frame Layout::).
-
- -- Function: pop_operand
- This predicate allows a memory reference suitable for popping a
- value off the stack. Again, this will be a `MEM' referring to
- `stack_pointer_rtx', with a side-effect in its address expression.
- However, this time `STACK_POP_CODE' is expected.
-
-The fourth category of predicates allow some combination of the above
-operands.
-
- -- Function: nonmemory_operand
- This predicate allows any immediate or register operand valid for
- MODE.
-
- -- Function: nonimmediate_operand
- This predicate allows any register or memory operand valid for
- MODE.
-
- -- Function: general_operand
- This predicate allows any immediate, register, or memory operand
- valid for MODE.
-
-Finally, there are two generic operator predicates.
-
- -- Function: comparison_operator
- This predicate matches any expression which performs an arithmetic
- comparison in MODE; that is, `COMPARISON_P' is true for the
- expression code.
-
- -- Function: ordered_comparison_operator
- This predicate matches any expression which performs an arithmetic
- comparison in MODE and whose expression code is valid for integer
- modes; that is, the expression code will be one of `eq', `ne',
- `lt', `ltu', `le', `leu', `gt', `gtu', `ge', `geu'.
-
-
-File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates
-
-16.7.2 Defining Machine-Specific Predicates
--------------------------------------------
-
-Many machines have requirements for their operands that cannot be
-expressed precisely using the generic predicates. You can define
-additional predicates using `define_predicate' and
-`define_special_predicate' expressions. These expressions have three
-operands:
-
- * The name of the predicate, as it will be referred to in
- `match_operand' or `match_operator' expressions.
-
- * An RTL expression which evaluates to true if the predicate allows
- the operand OP, false if it does not. This expression can only use
- the following RTL codes:
-
- `MATCH_OPERAND'
- When written inside a predicate expression, a `MATCH_OPERAND'
- expression evaluates to true if the predicate it names would
- allow OP. The operand number and constraint are ignored.
- Due to limitations in `genrecog', you can only refer to
- generic predicates and predicates that have already been
- defined.
-
- `MATCH_CODE'
- This expression evaluates to true if OP or a specified
- subexpression of OP has one of a given list of RTX codes.
-
- The first operand of this expression is a string constant
- containing a comma-separated list of RTX code names (in lower
- case). These are the codes for which the `MATCH_CODE' will
- be true.
-
- The second operand is a string constant which indicates what
- subexpression of OP to examine. If it is absent or the empty
- string, OP itself is examined. Otherwise, the string constant
- must be a sequence of digits and/or lowercase letters. Each
- character indicates a subexpression to extract from the
- current expression; for the first character this is OP, for
- the second and subsequent characters it is the result of the
- previous character. A digit N extracts `XEXP (E, N)'; a
- letter L extracts `XVECEXP (E, 0, N)' where N is the
- alphabetic ordinal of L (0 for `a', 1 for 'b', and so on).
- The `MATCH_CODE' then examines the RTX code of the
- subexpression extracted by the complete string. It is not
- possible to extract components of an `rtvec' that is not at
- position 0 within its RTX object.
-
- `MATCH_TEST'
- This expression has one operand, a string constant containing
- a C expression. The predicate's arguments, OP and MODE, are
- available with those names in the C expression. The
- `MATCH_TEST' evaluates to true if the C expression evaluates
- to a nonzero value. `MATCH_TEST' expressions must not have
- side effects.
-
- `AND'
- `IOR'
- `NOT'
- `IF_THEN_ELSE'
- The basic `MATCH_' expressions can be combined using these
- logical operators, which have the semantics of the C operators
- `&&', `||', `!', and `? :' respectively. As in Common Lisp,
- you may give an `AND' or `IOR' expression an arbitrary number
- of arguments; this has exactly the same effect as writing a
- chain of two-argument `AND' or `IOR' expressions.
-
- * An optional block of C code, which should execute `return true' if
- the predicate is found to match and `return false' if it does not.
- It must not have any side effects. The predicate arguments, OP
- and MODE, are available with those names.
-
- If a code block is present in a predicate definition, then the RTL
- expression must evaluate to true _and_ the code block must execute
- `return true' for the predicate to allow the operand. The RTL
- expression is evaluated first; do not re-check anything in the
- code block that was checked in the RTL expression.
-
- The program `genrecog' scans `define_predicate' and
-`define_special_predicate' expressions to determine which RTX codes are
-possibly allowed. You should always make this explicit in the RTL
-predicate expression, using `MATCH_OPERAND' and `MATCH_CODE'.
-
- Here is an example of a simple predicate definition, from the IA64
-machine description:
-
- ;; True if OP is a `SYMBOL_REF' which refers to the sdata section.
- (define_predicate "small_addr_symbolic_operand"
- (and (match_code "symbol_ref")
- (match_test "SYMBOL_REF_SMALL_ADDR_P (op)")))
-
-And here is another, showing the use of the C block.
-
- ;; True if OP is a register operand that is (or could be) a GR reg.
- (define_predicate "gr_register_operand"
- (match_operand 0 "register_operand")
- {
- unsigned int regno;
- if (GET_CODE (op) == SUBREG)
- op = SUBREG_REG (op);
-
- regno = REGNO (op);
- return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno));
- })
-
- Predicates written with `define_predicate' automatically include a
-test that MODE is `VOIDmode', or OP has the same mode as MODE, or OP is
-a `CONST_INT' or `CONST_DOUBLE'. They do _not_ check specifically for
-integer `CONST_DOUBLE', nor do they test that the value of either kind
-of constant fits in the requested mode. This is because
-target-specific predicates that take constants usually have to do more
-stringent value checks anyway. If you need the exact same treatment of
-`CONST_INT' or `CONST_DOUBLE' that the generic predicates provide, use
-a `MATCH_OPERAND' subexpression to call `const_int_operand',
-`const_double_operand', or `immediate_operand'.
-
- Predicates written with `define_special_predicate' do not get any
-automatic mode checks, and are treated as having special mode handling
-by `genrecog'.
-
- The program `genpreds' is responsible for generating code to test
-predicates. It also writes a header file containing function
-declarations for all machine-specific predicates. It is not necessary
-to declare these predicates in `CPU-protos.h'.
-
-
-File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc
-
-16.8 Operand Constraints
-========================
-
-Each `match_operand' in an instruction pattern can specify constraints
-for the operands allowed. The constraints allow you to fine-tune
-matching within the set of operands allowed by the predicate.
-
- Constraints can say whether an operand may be in a register, and which
-kinds of register; whether the operand can be a memory reference, and
-which kinds of address; whether the operand may be an immediate
-constant, and which possible values it may have. Constraints can also
-require two operands to match. Side-effects aren't allowed in operands
-of inline `asm', unless `<' or `>' constraints are used, because there
-is no guarantee that the side-effects will happen exactly once in an
-instruction that can update the addressing register.
-
-* Menu:
-
-* Simple Constraints:: Basic use of constraints.
-* Multi-Alternative:: When an insn has two alternative constraint-patterns.
-* Class Preferences:: Constraints guide which hard register to put things in.
-* Modifiers:: More precise control over effects of constraints.
-* Disable Insn Alternatives:: Disable insn alternatives using the `enabled' attribute.
-* Machine Constraints:: Existing constraints for some particular machines.
-* Define Constraints:: How to define machine-specific constraints.
-* C Constraint Interface:: How to test constraints from C code.
-
-
-File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints
-
-16.8.1 Simple Constraints
--------------------------
-
-The simplest kind of constraint is a string full of letters, each of
-which describes one kind of operand that is permitted. Here are the
-letters that are allowed:
-
-whitespace
- Whitespace characters are ignored and can be inserted at any
- position except the first. This enables each alternative for
- different operands to be visually aligned in the machine
- description even if they have different number of constraints and
- modifiers.
-
-`m'
- A memory operand is allowed, with any kind of address that the
- machine supports in general. Note that the letter used for the
- general memory constraint can be re-defined by a back end using
- the `TARGET_MEM_CONSTRAINT' macro.
-
-`o'
- A memory operand is allowed, but only if the address is
- "offsettable". This means that adding a small integer (actually,
- the width in bytes of the operand, as determined by its machine
- mode) may be added to the address and the result is also a valid
- memory address.
-
- For example, an address which is constant is offsettable; so is an
- address that is the sum of a register and a constant (as long as a
- slightly larger constant is also within the range of
- address-offsets supported by the machine); but an autoincrement or
- autodecrement address is not offsettable. More complicated
- indirect/indexed addresses may or may not be offsettable depending
- on the other addressing modes that the machine supports.
-
- Note that in an output operand which can be matched by another
- operand, the constraint letter `o' is valid only when accompanied
- by both `<' (if the target machine has predecrement addressing)
- and `>' (if the target machine has preincrement addressing).
-
-`V'
- A memory operand that is not offsettable. In other words,
- anything that would fit the `m' constraint but not the `o'
- constraint.
-
-`<'
- A memory operand with autodecrement addressing (either
- predecrement or postdecrement) is allowed. In inline `asm' this
- constraint is only allowed if the operand is used exactly once in
- an instruction that can handle the side-effects. Not using an
- operand with `<' in constraint string in the inline `asm' pattern
- at all or using it in multiple instructions isn't valid, because
- the side-effects wouldn't be performed or would be performed more
- than once. Furthermore, on some targets the operand with `<' in
- constraint string must be accompanied by special instruction
- suffixes like `%U0' instruction suffix on PowerPC or `%P0' on
- IA-64.
-
-`>'
- A memory operand with autoincrement addressing (either
- preincrement or postincrement) is allowed. In inline `asm' the
- same restrictions as for `<' apply.
-
-`r'
- A register operand is allowed provided that it is in a general
- register.
-
-`i'
- An immediate integer operand (one with constant value) is allowed.
- This includes symbolic constants whose values will be known only at
- assembly time or later.
-
-`n'
- An immediate integer operand with a known numeric value is allowed.
- Many systems cannot support assembly-time constants for operands
- less than a word wide. Constraints for these operands should use
- `n' rather than `i'.
-
-`I', `J', `K', ... `P'
- Other letters in the range `I' through `P' may be defined in a
- machine-dependent fashion to permit immediate integer operands with
- explicit integer values in specified ranges. For example, on the
- 68000, `I' is defined to stand for the range of values 1 to 8.
- This is the range permitted as a shift count in the shift
- instructions.
-
-`E'
- An immediate floating operand (expression code `const_double') is
- allowed, but only if the target floating point format is the same
- as that of the host machine (on which the compiler is running).
-
-`F'
- An immediate floating operand (expression code `const_double' or
- `const_vector') is allowed.
-
-`G', `H'
- `G' and `H' may be defined in a machine-dependent fashion to
- permit immediate floating operands in particular ranges of values.
-
-`s'
- An immediate integer operand whose value is not an explicit
- integer is allowed.
-
- This might appear strange; if an insn allows a constant operand
- with a value not known at compile time, it certainly must allow
- any known value. So why use `s' instead of `i'? Sometimes it
- allows better code to be generated.
-
- For example, on the 68000 in a fullword instruction it is possible
- to use an immediate operand; but if the immediate value is between
- -128 and 127, better code results from loading the value into a
- register and using the register. This is because the load into
- the register can be done with a `moveq' instruction. We arrange
- for this to happen by defining the letter `K' to mean "any integer
- outside the range -128 to 127", and then specifying `Ks' in the
- operand constraints.
-
-`g'
- Any register, memory or immediate integer operand is allowed,
- except for registers that are not general registers.
-
-`X'
- Any operand whatsoever is allowed, even if it does not satisfy
- `general_operand'. This is normally used in the constraint of a
- `match_scratch' when certain alternatives will not actually
- require a scratch register.
-
-`0', `1', `2', ... `9'
- An operand that matches the specified operand number is allowed.
- If a digit is used together with letters within the same
- alternative, the digit should come last.
-
- This number is allowed to be more than a single digit. If multiple
- digits are encountered consecutively, they are interpreted as a
- single decimal integer. There is scant chance for ambiguity,
- since to-date it has never been desirable that `10' be interpreted
- as matching either operand 1 _or_ operand 0. Should this be
- desired, one can use multiple alternatives instead.
-
- This is called a "matching constraint" and what it really means is
- that the assembler has only a single operand that fills two roles
- considered separate in the RTL insn. For example, an add insn has
- two input operands and one output operand in the RTL, but on most
- CISC machines an add instruction really has only two operands, one
- of them an input-output operand:
-
- addl #35,r12
-
- Matching constraints are used in these circumstances. More
- precisely, the two operands that match must include one input-only
- operand and one output-only operand. Moreover, the digit must be a
- smaller number than the number of the operand that uses it in the
- constraint.
-
- For operands to match in a particular case usually means that they
- are identical-looking RTL expressions. But in a few special cases
- specific kinds of dissimilarity are allowed. For example, `*x' as
- an input operand will match `*x++' as an output operand. For
- proper results in such cases, the output template should always
- use the output-operand's number when printing the operand.
-
-`p'
- An operand that is a valid memory address is allowed. This is for
- "load address" and "push address" instructions.
-
- `p' in the constraint must be accompanied by `address_operand' as
- the predicate in the `match_operand'. This predicate interprets
- the mode specified in the `match_operand' as the mode of the memory
- reference for which the address would be valid.
-
-OTHER-LETTERS
- Other letters can be defined in machine-dependent fashion to stand
- for particular classes of registers or other arbitrary operand
- types. `d', `a' and `f' are defined on the 68000/68020 to stand
- for data, address and floating point registers.
-
- In order to have valid assembler code, each operand must satisfy its
-constraint. But a failure to do so does not prevent the pattern from
-applying to an insn. Instead, it directs the compiler to modify the
-code so that the constraint will be satisfied. Usually this is done by
-copying an operand into a register.
-
- Contrast, therefore, the two instruction patterns that follow:
-
- (define_insn ""
- [(set (match_operand:SI 0 "general_operand" "=r")
- (plus:SI (match_dup 0)
- (match_operand:SI 1 "general_operand" "r")))]
- ""
- "...")
-
-which has two operands, one of which must appear in two places, and
-
- (define_insn ""
- [(set (match_operand:SI 0 "general_operand" "=r")
- (plus:SI (match_operand:SI 1 "general_operand" "0")
- (match_operand:SI 2 "general_operand" "r")))]
- ""
- "...")
-
-which has three operands, two of which are required by a constraint to
-be identical. If we are considering an insn of the form
-
- (insn N PREV NEXT
- (set (reg:SI 3)
- (plus:SI (reg:SI 6) (reg:SI 109)))
- ...)
-
-the first pattern would not apply at all, because this insn does not
-contain two identical subexpressions in the right place. The pattern
-would say, "That does not look like an add instruction; try other
-patterns". The second pattern would say, "Yes, that's an add
-instruction, but there is something wrong with it". It would direct
-the reload pass of the compiler to generate additional insns to make
-the constraint true. The results might look like this:
-
- (insn N2 PREV N
- (set (reg:SI 3) (reg:SI 6))
- ...)
-
- (insn N N2 NEXT
- (set (reg:SI 3)
- (plus:SI (reg:SI 3) (reg:SI 109)))
- ...)
-
- It is up to you to make sure that each operand, in each pattern, has
-constraints that can handle any RTL expression that could be present for
-that operand. (When multiple alternatives are in use, each pattern
-must, for each possible combination of operand expressions, have at
-least one alternative which can handle that combination of operands.)
-The constraints don't need to _allow_ any possible operand--when this is
-the case, they do not constrain--but they must at least point the way to
-reloading any possible operand so that it will fit.
-
- * If the constraint accepts whatever operands the predicate permits,
- there is no problem: reloading is never necessary for this operand.
-
- For example, an operand whose constraints permit everything except
- registers is safe provided its predicate rejects registers.
-
- An operand whose predicate accepts only constant values is safe
- provided its constraints include the letter `i'. If any possible
- constant value is accepted, then nothing less than `i' will do; if
- the predicate is more selective, then the constraints may also be
- more selective.
-
- * Any operand expression can be reloaded by copying it into a
- register. So if an operand's constraints allow some kind of
- register, it is certain to be safe. It need not permit all
- classes of registers; the compiler knows how to copy a register
- into another register of the proper class in order to make an
- instruction valid.
-
- * A nonoffsettable memory reference can be reloaded by copying the
- address into a register. So if the constraint uses the letter
- `o', all memory references are taken care of.
-
- * A constant operand can be reloaded by allocating space in memory to
- hold it as preinitialized data. Then the memory reference can be
- used in place of the constant. So if the constraint uses the
- letters `o' or `m', constant operands are not a problem.
-
- * If the constraint permits a constant and a pseudo register used in
- an insn was not allocated to a hard register and is equivalent to
- a constant, the register will be replaced with the constant. If
- the predicate does not permit a constant and the insn is
- re-recognized for some reason, the compiler will crash. Thus the
- predicate must always recognize any objects allowed by the
- constraint.
-
- If the operand's predicate can recognize registers, but the constraint
-does not permit them, it can make the compiler crash. When this
-operand happens to be a register, the reload pass will be stymied,
-because it does not know how to copy a register temporarily into memory.
-
- If the predicate accepts a unary operator, the constraint applies to
-the operand. For example, the MIPS processor at ISA level 3 supports an
-instruction which adds two registers in `SImode' to produce a `DImode'
-result, but only if the registers are correctly sign extended. This
-predicate for the input operands accepts a `sign_extend' of an `SImode'
-register. Write the constraint to indicate the type of register that
-is required for the operand of the `sign_extend'.
-
-
-File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints
-
-16.8.2 Multiple Alternative Constraints
----------------------------------------
-
-Sometimes a single instruction has multiple alternative sets of possible
-operands. For example, on the 68000, a logical-or instruction can
-combine register or an immediate value into memory, or it can combine
-any kind of operand into a register; but it cannot combine one memory
-location into another.
-
- These constraints are represented as multiple alternatives. An
-alternative can be described by a series of letters for each operand.
-The overall constraint for an operand is made from the letters for this
-operand from the first alternative, a comma, the letters for this
-operand from the second alternative, a comma, and so on until the last
-alternative. Here is how it is done for fullword logical-or on the
-68000:
-
- (define_insn "iorsi3"
- [(set (match_operand:SI 0 "general_operand" "=m,d")
- (ior:SI (match_operand:SI 1 "general_operand" "%0,0")
- (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
- ...)
-
- The first alternative has `m' (memory) for operand 0, `0' for operand
-1 (meaning it must match operand 0), and `dKs' for operand 2. The
-second alternative has `d' (data register) for operand 0, `0' for
-operand 1, and `dmKs' for operand 2. The `=' and `%' in the
-constraints apply to all the alternatives; their meaning is explained
-in the next section (*note Class Preferences::).
-
- If all the operands fit any one alternative, the instruction is valid.
-Otherwise, for each alternative, the compiler counts how many
-instructions must be added to copy the operands so that that
-alternative applies. The alternative requiring the least copying is
-chosen. If two alternatives need the same amount of copying, the one
-that comes first is chosen. These choices can be altered with the `?'
-and `!' characters:
-
-`?'
- Disparage slightly the alternative that the `?' appears in, as a
- choice when no alternative applies exactly. The compiler regards
- this alternative as one unit more costly for each `?' that appears
- in it.
-
-`!'
- Disparage severely the alternative that the `!' appears in. This
- alternative can still be used if it fits without reloading, but if
- reloading is needed, some other alternative will be used.
-
- When an insn pattern has multiple alternatives in its constraints,
-often the appearance of the assembler code is determined mostly by which
-alternative was matched. When this is so, the C code for writing the
-assembler code can use the variable `which_alternative', which is the
-ordinal number of the alternative that was actually satisfied (0 for
-the first, 1 for the second alternative, etc.). *Note Output
-Statement::.
-
-
-File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints
-
-16.8.3 Register Class Preferences
----------------------------------
-
-The operand constraints have another function: they enable the compiler
-to decide which kind of hardware register a pseudo register is best
-allocated to. The compiler examines the constraints that apply to the
-insns that use the pseudo register, looking for the machine-dependent
-letters such as `d' and `a' that specify classes of registers. The
-pseudo register is put in whichever class gets the most "votes". The
-constraint letters `g' and `r' also vote: they vote in favor of a
-general register. The machine description says which registers are
-considered general.
-
- Of course, on some machines all registers are equivalent, and no
-register classes are defined. Then none of this complexity is relevant.
-
-
-File: gccint.info, Node: Modifiers, Next: Disable Insn Alternatives, Prev: Class Preferences, Up: Constraints
-
-16.8.4 Constraint Modifier Characters
--------------------------------------
-
-Here are constraint modifier characters.
-
-`='
- Means that this operand is write-only for this instruction: the
- previous value is discarded and replaced by output data.
-
-`+'
- Means that this operand is both read and written by the
- instruction.
-
- When the compiler fixes up the operands to satisfy the constraints,
- it needs to know which operands are inputs to the instruction and
- which are outputs from it. `=' identifies an output; `+'
- identifies an operand that is both input and output; all other
- operands are assumed to be input only.
-
- If you specify `=' or `+' in a constraint, you put it in the first
- character of the constraint string.
-
-`&'
- Means (in a particular alternative) that this operand is an
- "earlyclobber" operand, which is modified before the instruction is
- finished using the input operands. Therefore, this operand may
- not lie in a register that is used as an input operand or as part
- of any memory address.
-
- `&' applies only to the alternative in which it is written. In
- constraints with multiple alternatives, sometimes one alternative
- requires `&' while others do not. See, for example, the `movdf'
- insn of the 68000.
-
- An input operand can be tied to an earlyclobber operand if its only
- use as an input occurs before the early result is written. Adding
- alternatives of this form often allows GCC to produce better code
- when only some of the inputs can be affected by the earlyclobber.
- See, for example, the `mulsi3' insn of the ARM.
-
- `&' does not obviate the need to write `='.
-
-`%'
- Declares the instruction to be commutative for this operand and the
- following operand. This means that the compiler may interchange
- the two operands if that is the cheapest way to make all operands
- fit the constraints. This is often used in patterns for addition
- instructions that really have only two operands: the result must
- go in one of the arguments. Here for example, is how the 68000
- halfword-add instruction is defined:
-
- (define_insn "addhi3"
- [(set (match_operand:HI 0 "general_operand" "=m,r")
- (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
- (match_operand:HI 2 "general_operand" "di,g")))]
- ...)
- GCC can only handle one commutative pair in an asm; if you use
- more, the compiler may fail. Note that you need not use the
- modifier if the two alternatives are strictly identical; this
- would only waste time in the reload pass. The modifier is not
- operational after register allocation, so the result of
- `define_peephole2' and `define_split's performed after reload
- cannot rely on `%' to make the intended insn match.
-
-`#'
- Says that all following characters, up to the next comma, are to be
- ignored as a constraint. They are significant only for choosing
- register preferences.
-
-`*'
- Says that the following character should be ignored when choosing
- register preferences. `*' has no effect on the meaning of the
- constraint as a constraint, and no effect on reloading.
-
- Here is an example: the 68000 has an instruction to sign-extend a
- halfword in a data register, and can also sign-extend a value by
- copying it into an address register. While either kind of
- register is acceptable, the constraints on an address-register
- destination are less strict, so it is best if register allocation
- makes an address register its goal. Therefore, `*' is used so
- that the `d' constraint letter (for data register) is ignored when
- computing register preferences.
-
- (define_insn "extendhisi2"
- [(set (match_operand:SI 0 "general_operand" "=*d,a")
- (sign_extend:SI
- (match_operand:HI 1 "general_operand" "0,g")))]
- ...)
-
-
-File: gccint.info, Node: Machine Constraints, Next: Define Constraints, Prev: Disable Insn Alternatives, Up: Constraints
-
-16.8.5 Constraints for Particular Machines
-------------------------------------------
-
-Whenever possible, you should use the general-purpose constraint letters
-in `asm' arguments, since they will convey meaning more readily to
-people reading your code. Failing that, use the constraint letters
-that usually have very similar meanings across architectures. The most
-commonly used constraints are `m' and `r' (for memory and
-general-purpose registers respectively; *note Simple Constraints::), and
-`I', usually the letter indicating the most common immediate-constant
-format.
-
- Each architecture defines additional constraints. These constraints
-are used by the compiler itself for instruction generation, as well as
-for `asm' statements; therefore, some of the constraints are not
-particularly useful for `asm'. Here is a summary of some of the
-machine-dependent constraints available on some particular machines; it
-includes both constraints that are useful for `asm' and constraints
-that aren't. The compiler source file mentioned in the table heading
-for each architecture is the definitive reference for the meanings of
-that architecture's constraints.
-
-_ARM family--`config/arm/arm.h'_
-
- `f'
- Floating-point register
-
- `w'
- VFP floating-point register
-
- `F'
- One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0,
- 4.0, 5.0 or 10.0
-
- `G'
- Floating-point constant that would satisfy the constraint `F'
- if it were negated
-
- `I'
- Integer that is valid as an immediate operand in a data
- processing instruction. That is, an integer in the range 0
- to 255 rotated by a multiple of 2
-
- `J'
- Integer in the range -4095 to 4095
-
- `K'
- Integer that satisfies constraint `I' when inverted (ones
- complement)
-
- `L'
- Integer that satisfies constraint `I' when negated (twos
- complement)
-
- `M'
- Integer in the range 0 to 32
-
- `Q'
- A memory reference where the exact address is in a single
- register (``m'' is preferable for `asm' statements)
-
- `R'
- An item in the constant pool
-
- `S'
- A symbol in the text segment of the current file
-
- `Uv'
- A memory reference suitable for VFP load/store insns
- (reg+constant offset)
-
- `Uy'
- A memory reference suitable for iWMMXt load/store
- instructions.
-
- `Uq'
- A memory reference suitable for the ARMv4 ldrsb instruction.
-
-_AVR family--`config/avr/constraints.md'_
-
- `l'
- Registers from r0 to r15
-
- `a'
- Registers from r16 to r23
-
- `d'
- Registers from r16 to r31
-
- `w'
- Registers from r24 to r31. These registers can be used in
- `adiw' command
-
- `e'
- Pointer register (r26-r31)
-
- `b'
- Base pointer register (r28-r31)
-
- `q'
- Stack pointer register (SPH:SPL)
-
- `t'
- Temporary register r0
-
- `x'
- Register pair X (r27:r26)
-
- `y'
- Register pair Y (r29:r28)
-
- `z'
- Register pair Z (r31:r30)
-
- `I'
- Constant greater than -1, less than 64
-
- `J'
- Constant greater than -64, less than 1
-
- `K'
- Constant integer 2
-
- `L'
- Constant integer 0
-
- `M'
- Constant that fits in 8 bits
-
- `N'
- Constant integer -1
-
- `O'
- Constant integer 8, 16, or 24
-
- `P'
- Constant integer 1
-
- `G'
- A floating point constant 0.0
-
- `R'
- Integer constant in the range -6 ... 5.
-
- `Q'
- A memory address based on Y or Z pointer with displacement.
-
-_CRX Architecture--`config/crx/crx.h'_
-
- `b'
- Registers from r0 to r14 (registers without stack pointer)
-
- `l'
- Register r16 (64-bit accumulator lo register)
-
- `h'
- Register r17 (64-bit accumulator hi register)
-
- `k'
- Register pair r16-r17. (64-bit accumulator lo-hi pair)
-
- `I'
- Constant that fits in 3 bits
-
- `J'
- Constant that fits in 4 bits
-
- `K'
- Constant that fits in 5 bits
-
- `L'
- Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
-
- `G'
- Floating point constant that is legal for store immediate
-
-_Hewlett-Packard PA-RISC--`config/pa/pa.h'_
-
- `a'
- General register 1
-
- `f'
- Floating point register
-
- `q'
- Shift amount register
-
- `x'
- Floating point register (deprecated)
-
- `y'
- Upper floating point register (32-bit), floating point
- register (64-bit)
-
- `Z'
- Any register
-
- `I'
- Signed 11-bit integer constant
-
- `J'
- Signed 14-bit integer constant
-
- `K'
- Integer constant that can be deposited with a `zdepi'
- instruction
-
- `L'
- Signed 5-bit integer constant
-
- `M'
- Integer constant 0
-
- `N'
- Integer constant that can be loaded with a `ldil' instruction
-
- `O'
- Integer constant whose value plus one is a power of 2
-
- `P'
- Integer constant that can be used for `and' operations in
- `depi' and `extru' instructions
-
- `S'
- Integer constant 31
-
- `U'
- Integer constant 63
-
- `G'
- Floating-point constant 0.0
-
- `A'
- A `lo_sum' data-linkage-table memory operand
-
- `Q'
- A memory operand that can be used as the destination operand
- of an integer store instruction
-
- `R'
- A scaled or unscaled indexed memory operand
-
- `T'
- A memory operand for floating-point loads and stores
-
- `W'
- A register indirect memory operand
-
-_picoChip family--`picochip.h'_
-
- `k'
- Stack register.
-
- `f'
- Pointer register. A register which can be used to access
- memory without supplying an offset. Any other register can
- be used to access memory, but will need a constant offset.
- In the case of the offset being zero, it is more efficient to
- use a pointer register, since this reduces code size.
-
- `t'
- A twin register. A register which may be paired with an
- adjacent register to create a 32-bit register.
-
- `a'
- Any absolute memory address (e.g., symbolic constant, symbolic
- constant + offset).
-
- `I'
- 4-bit signed integer.
-
- `J'
- 4-bit unsigned integer.
-
- `K'
- 8-bit signed integer.
-
- `M'
- Any constant whose absolute value is no greater than 4-bits.
-
- `N'
- 10-bit signed integer
-
- `O'
- 16-bit signed integer.
-
-
-_PowerPC and IBM RS6000--`config/rs6000/rs6000.h'_
-
- `b'
- Address base register
-
- `d'
- Floating point register (containing 64-bit value)
-
- `f'
- Floating point register (containing 32-bit value)
-
- `v'
- Altivec vector register
-
- `wd'
- VSX vector register to hold vector double data
-
- `wf'
- VSX vector register to hold vector float data
-
- `ws'
- VSX vector register to hold scalar float data
-
- `wa'
- Any VSX register
-
- `h'
- `MQ', `CTR', or `LINK' register
-
- `q'
- `MQ' register
-
- `c'
- `CTR' register
-
- `l'
- `LINK' register
-
- `x'
- `CR' register (condition register) number 0
-
- `y'
- `CR' register (condition register)
-
- `z'
- `XER[CA]' carry bit (part of the XER register)
-
- `I'
- Signed 16-bit constant
-
- `J'
- Unsigned 16-bit constant shifted left 16 bits (use `L'
- instead for `SImode' constants)
-
- `K'
- Unsigned 16-bit constant
-
- `L'
- Signed 16-bit constant shifted left 16 bits
-
- `M'
- Constant larger than 31
-
- `N'
- Exact power of 2
-
- `O'
- Zero
-
- `P'
- Constant whose negation is a signed 16-bit constant
-
- `G'
- Floating point constant that can be loaded into a register
- with one instruction per word
-
- `H'
- Integer/Floating point constant that can be loaded into a
- register using three instructions
-
- `m'
- Memory operand. Normally, `m' does not allow addresses that
- update the base register. If `<' or `>' constraint is also
- used, they are allowed and therefore on PowerPC targets in
- that case it is only safe to use `m<>' in an `asm' statement
- if that `asm' statement accesses the operand exactly once.
- The `asm' statement must also use `%U<OPNO>' as a placeholder
- for the "update" flag in the corresponding load or store
- instruction. For example:
-
- asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val));
-
- is correct but:
-
- asm ("st %1,%0" : "=m<>" (mem) : "r" (val));
-
- is not.
-
- `es'
- A "stable" memory operand; that is, one which does not
- include any automodification of the base register. This used
- to be useful when `m' allowed automodification of the base
- register, but as those are now only allowed when `<' or `>'
- is used, `es' is basically the same as `m' without `<' and
- `>'.
-
- `Q'
- Memory operand that is an offset from a register (it is
- usually better to use `m' or `es' in `asm' statements)
-
- `Z'
- Memory operand that is an indexed or indirect from a register
- (it is usually better to use `m' or `es' in `asm' statements)
-
- `R'
- AIX TOC entry
-
- `a'
- Address operand that is an indexed or indirect from a
- register (`p' is preferable for `asm' statements)
-
- `S'
- Constant suitable as a 64-bit mask operand
-
- `T'
- Constant suitable as a 32-bit mask operand
-
- `U'
- System V Release 4 small data area reference
-
- `t'
- AND masks that can be performed by two rldic{l, r}
- instructions
-
- `W'
- Vector constant that does not require memory
-
- `j'
- Vector constant that is all zeros.
-
-
-_Intel 386--`config/i386/constraints.md'_
-
- `R'
- Legacy register--the eight integer registers available on all
- i386 processors (`a', `b', `c', `d', `si', `di', `bp', `sp').
-
- `q'
- Any register accessible as `Rl'. In 32-bit mode, `a', `b',
- `c', and `d'; in 64-bit mode, any integer register.
-
- `Q'
- Any register accessible as `Rh': `a', `b', `c', and `d'.
-
- `l'
- Any register that can be used as the index in a base+index
- memory access: that is, any general register except the stack
- pointer.
-
- `a'
- The `a' register.
-
- `b'
- The `b' register.
-
- `c'
- The `c' register.
-
- `d'
- The `d' register.
-
- `S'
- The `si' register.
-
- `D'
- The `di' register.
-
- `A'
- The `a' and `d' registers. This class is used for
- instructions that return double word results in the `ax:dx'
- register pair. Single word values will be allocated either
- in `ax' or `dx'. For example on i386 the following
- implements `rdtsc':
-
- unsigned long long rdtsc (void)
- {
- unsigned long long tick;
- __asm__ __volatile__("rdtsc":"=A"(tick));
- return tick;
- }
-
- This is not correct on x86_64 as it would allocate tick in
- either `ax' or `dx'. You have to use the following variant
- instead:
-
- unsigned long long rdtsc (void)
- {
- unsigned int tickl, tickh;
- __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh));
- return ((unsigned long long)tickh << 32)|tickl;
- }
-
- `f'
- Any 80387 floating-point (stack) register.
-
- `t'
- Top of 80387 floating-point stack (`%st(0)').
-
- `u'
- Second from top of 80387 floating-point stack (`%st(1)').
-
- `y'
- Any MMX register.
-
- `x'
- Any SSE register.
-
- `Yz'
- First SSE register (`%xmm0').
-
- `Y2'
- Any SSE register, when SSE2 is enabled.
-
- `Yi'
- Any SSE register, when SSE2 and inter-unit moves are enabled.
-
- `Ym'
- Any MMX register, when inter-unit moves are enabled.
-
- `I'
- Integer constant in the range 0 ... 31, for 32-bit shifts.
-
- `J'
- Integer constant in the range 0 ... 63, for 64-bit shifts.
-
- `K'
- Signed 8-bit integer constant.
-
- `L'
- `0xFF' or `0xFFFF', for andsi as a zero-extending move.
-
- `M'
- 0, 1, 2, or 3 (shifts for the `lea' instruction).
-
- `N'
- Unsigned 8-bit integer constant (for `in' and `out'
- instructions).
-
- `O'
- Integer constant in the range 0 ... 127, for 128-bit shifts.
-
- `G'
- Standard 80387 floating point constant.
-
- `C'
- Standard SSE floating point constant.
-
- `e'
- 32-bit signed integer constant, or a symbolic reference known
- to fit that range (for immediate operands in sign-extending
- x86-64 instructions).
-
- `Z'
- 32-bit unsigned integer constant, or a symbolic reference
- known to fit that range (for immediate operands in
- zero-extending x86-64 instructions).
-
-
-_Intel IA-64--`config/ia64/ia64.h'_
-
- `a'
- General register `r0' to `r3' for `addl' instruction
-
- `b'
- Branch register
-
- `c'
- Predicate register (`c' as in "conditional")
-
- `d'
- Application register residing in M-unit
-
- `e'
- Application register residing in I-unit
-
- `f'
- Floating-point register
-
- `m'
- Memory operand. If used together with `<' or `>', the
- operand can have postincrement and postdecrement which
- require printing with `%Pn' on IA-64.
-
- `G'
- Floating-point constant 0.0 or 1.0
-
- `I'
- 14-bit signed integer constant
-
- `J'
- 22-bit signed integer constant
-
- `K'
- 8-bit signed integer constant for logical instructions
-
- `L'
- 8-bit adjusted signed integer constant for compare pseudo-ops
-
- `M'
- 6-bit unsigned integer constant for shift counts
-
- `N'
- 9-bit signed integer constant for load and store
- postincrements
-
- `O'
- The constant zero
-
- `P'
- 0 or -1 for `dep' instruction
-
- `Q'
- Non-volatile memory for floating-point loads and stores
-
- `R'
- Integer constant in the range 1 to 4 for `shladd' instruction
-
- `S'
- Memory operand except postincrement and postdecrement. This
- is now roughly the same as `m' when not used together with `<'
- or `>'.
-
-_FRV--`config/frv/frv.h'_
-
- `a'
- Register in the class `ACC_REGS' (`acc0' to `acc7').
-
- `b'
- Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7').
-
- `c'
- Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0'
- to `icc3').
-
- `d'
- Register in the class `GPR_REGS' (`gr0' to `gr63').
-
- `e'
- Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd
- registers are excluded not in the class but through the use
- of a machine mode larger than 4 bytes.
-
- `f'
- Register in the class `FPR_REGS' (`fr0' to `fr63').
-
- `h'
- Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd
- registers are excluded not in the class but through the use
- of a machine mode larger than 4 bytes.
-
- `l'
- Register in the class `LR_REG' (the `lr' register).
-
- `q'
- Register in the class `QUAD_REGS' (`gr2' to `gr63').
- Register numbers not divisible by 4 are excluded not in the
- class but through the use of a machine mode larger than 8
- bytes.
-
- `t'
- Register in the class `ICC_REGS' (`icc0' to `icc3').
-
- `u'
- Register in the class `FCC_REGS' (`fcc0' to `fcc3').
-
- `v'
- Register in the class `ICR_REGS' (`cc4' to `cc7').
-
- `w'
- Register in the class `FCR_REGS' (`cc0' to `cc3').
-
- `x'
- Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63').
- Register numbers not divisible by 4 are excluded not in the
- class but through the use of a machine mode larger than 8
- bytes.
-
- `z'
- Register in the class `SPR_REGS' (`lcr' and `lr').
-
- `A'
- Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7').
-
- `B'
- Register in the class `ACCG_REGS' (`accg0' to `accg7').
-
- `C'
- Register in the class `CR_REGS' (`cc0' to `cc7').
-
- `G'
- Floating point constant zero
-
- `I'
- 6-bit signed integer constant
-
- `J'
- 10-bit signed integer constant
-
- `L'
- 16-bit signed integer constant
-
- `M'
- 16-bit unsigned integer constant
-
- `N'
- 12-bit signed integer constant that is negative--i.e. in the
- range of -2048 to -1
-
- `O'
- Constant zero
-
- `P'
- 12-bit signed integer constant that is greater than
- zero--i.e. in the range of 1 to 2047.
-
-
-_Blackfin family--`config/bfin/constraints.md'_
-
- `a'
- P register
-
- `d'
- D register
-
- `z'
- A call clobbered P register.
-
- `qN'
- A single register. If N is in the range 0 to 7, the
- corresponding D register. If it is `A', then the register P0.
-
- `D'
- Even-numbered D register
-
- `W'
- Odd-numbered D register
-
- `e'
- Accumulator register.
-
- `A'
- Even-numbered accumulator register.
-
- `B'
- Odd-numbered accumulator register.
-
- `b'
- I register
-
- `v'
- B register
-
- `f'
- M register
-
- `c'
- Registers used for circular buffering, i.e. I, B, or L
- registers.
-
- `C'
- The CC register.
-
- `t'
- LT0 or LT1.
-
- `k'
- LC0 or LC1.
-
- `u'
- LB0 or LB1.
-
- `x'
- Any D, P, B, M, I or L register.
-
- `y'
- Additional registers typically used only in prologues and
- epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and
- USP.
-
- `w'
- Any register except accumulators or CC.
-
- `Ksh'
- Signed 16 bit integer (in the range -32768 to 32767)
-
- `Kuh'
- Unsigned 16 bit integer (in the range 0 to 65535)
-
- `Ks7'
- Signed 7 bit integer (in the range -64 to 63)
-
- `Ku7'
- Unsigned 7 bit integer (in the range 0 to 127)
-
- `Ku5'
- Unsigned 5 bit integer (in the range 0 to 31)
-
- `Ks4'
- Signed 4 bit integer (in the range -8 to 7)
-
- `Ks3'
- Signed 3 bit integer (in the range -3 to 4)
-
- `Ku3'
- Unsigned 3 bit integer (in the range 0 to 7)
-
- `PN'
- Constant N, where N is a single-digit constant in the range 0
- to 4.
-
- `PA'
- An integer equal to one of the MACFLAG_XXX constants that is
- suitable for use with either accumulator.
-
- `PB'
- An integer equal to one of the MACFLAG_XXX constants that is
- suitable for use only with accumulator A1.
-
- `M1'
- Constant 255.
-
- `M2'
- Constant 65535.
-
- `J'
- An integer constant with exactly a single bit set.
-
- `L'
- An integer constant with all bits set except exactly one.
-
- `H'
-
- `Q'
- Any SYMBOL_REF.
-
-_M32C--`config/m32c/m32c.c'_
-
- `Rsp'
- `Rfb'
- `Rsb'
- `$sp', `$fb', `$sb'.
-
- `Rcr'
- Any control register, when they're 16 bits wide (nothing if
- control registers are 24 bits wide)
-
- `Rcl'
- Any control register, when they're 24 bits wide.
-
- `R0w'
- `R1w'
- `R2w'
- `R3w'
- $r0, $r1, $r2, $r3.
-
- `R02'
- $r0 or $r2, or $r2r0 for 32 bit values.
-
- `R13'
- $r1 or $r3, or $r3r1 for 32 bit values.
-
- `Rdi'
- A register that can hold a 64 bit value.
-
- `Rhl'
- $r0 or $r1 (registers with addressable high/low bytes)
-
- `R23'
- $r2 or $r3
-
- `Raa'
- Address registers
-
- `Raw'
- Address registers when they're 16 bits wide.
-
- `Ral'
- Address registers when they're 24 bits wide.
-
- `Rqi'
- Registers that can hold QI values.
-
- `Rad'
- Registers that can be used with displacements ($a0, $a1, $sb).
-
- `Rsi'
- Registers that can hold 32 bit values.
-
- `Rhi'
- Registers that can hold 16 bit values.
-
- `Rhc'
- Registers chat can hold 16 bit values, including all control
- registers.
-
- `Rra'
- $r0 through R1, plus $a0 and $a1.
-
- `Rfl'
- The flags register.
-
- `Rmm'
- The memory-based pseudo-registers $mem0 through $mem15.
-
- `Rpi'
- Registers that can hold pointers (16 bit registers for r8c,
- m16c; 24 bit registers for m32cm, m32c).
-
- `Rpa'
- Matches multiple registers in a PARALLEL to form a larger
- register. Used to match function return values.
-
- `Is3'
- -8 ... 7
-
- `IS1'
- -128 ... 127
-
- `IS2'
- -32768 ... 32767
-
- `IU2'
- 0 ... 65535
-
- `In4'
- -8 ... -1 or 1 ... 8
-
- `In5'
- -16 ... -1 or 1 ... 16
-
- `In6'
- -32 ... -1 or 1 ... 32
-
- `IM2'
- -65536 ... -1
-
- `Ilb'
- An 8 bit value with exactly one bit set.
-
- `Ilw'
- A 16 bit value with exactly one bit set.
-
- `Sd'
- The common src/dest memory addressing modes.
-
- `Sa'
- Memory addressed using $a0 or $a1.
-
- `Si'
- Memory addressed with immediate addresses.
-
- `Ss'
- Memory addressed using the stack pointer ($sp).
-
- `Sf'
- Memory addressed using the frame base register ($fb).
-
- `Ss'
- Memory addressed using the small base register ($sb).
-
- `S1'
- $r1h
-
-_MeP--`config/mep/constraints.md'_
-
- `a'
- The $sp register.
-
- `b'
- The $tp register.
-
- `c'
- Any control register.
-
- `d'
- Either the $hi or the $lo register.
-
- `em'
- Coprocessor registers that can be directly loaded ($c0-$c15).
-
- `ex'
- Coprocessor registers that can be moved to each other.
-
- `er'
- Coprocessor registers that can be moved to core registers.
-
- `h'
- The $hi register.
-
- `j'
- The $rpc register.
-
- `l'
- The $lo register.
-
- `t'
- Registers which can be used in $tp-relative addressing.
-
- `v'
- The $gp register.
-
- `x'
- The coprocessor registers.
-
- `y'
- The coprocessor control registers.
-
- `z'
- The $0 register.
-
- `A'
- User-defined register set A.
-
- `B'
- User-defined register set B.
-
- `C'
- User-defined register set C.
-
- `D'
- User-defined register set D.
-
- `I'
- Offsets for $gp-rel addressing.
-
- `J'
- Constants that can be used directly with boolean insns.
-
- `K'
- Constants that can be moved directly to registers.
-
- `L'
- Small constants that can be added to registers.
-
- `M'
- Long shift counts.
-
- `N'
- Small constants that can be compared to registers.
-
- `O'
- Constants that can be loaded into the top half of registers.
-
- `S'
- Signed 8-bit immediates.
-
- `T'
- Symbols encoded for $tp-rel or $gp-rel addressing.
-
- `U'
- Non-constant addresses for loading/saving coprocessor
- registers.
-
- `W'
- The top half of a symbol's value.
-
- `Y'
- A register indirect address without offset.
-
- `Z'
- Symbolic references to the control bus.
-
-
-_MicroBlaze--`config/microblaze/constraints.md'_
-
- `d'
- A general register (`r0' to `r31').
-
- `z'
- A status register (`rmsr', `$fcc1' to `$fcc7').
-
-
-_MIPS--`config/mips/constraints.md'_
-
- `d'
- An address register. This is equivalent to `r' unless
- generating MIPS16 code.
-
- `f'
- A floating-point register (if available).
-
- `h'
- Formerly the `hi' register. This constraint is no longer
- supported.
-
- `l'
- The `lo' register. Use this register to store values that are
- no bigger than a word.
-
- `x'
- The concatenated `hi' and `lo' registers. Use this register
- to store doubleword values.
-
- `c'
- A register suitable for use in an indirect jump. This will
- always be `$25' for `-mabicalls'.
-
- `v'
- Register `$3'. Do not use this constraint in new code; it is
- retained only for compatibility with glibc.
-
- `y'
- Equivalent to `r'; retained for backwards compatibility.
-
- `z'
- A floating-point condition code register.
-
- `I'
- A signed 16-bit constant (for arithmetic instructions).
-
- `J'
- Integer zero.
-
- `K'
- An unsigned 16-bit constant (for logic instructions).
-
- `L'
- A signed 32-bit constant in which the lower 16 bits are zero.
- Such constants can be loaded using `lui'.
-
- `M'
- A constant that cannot be loaded using `lui', `addiu' or
- `ori'.
-
- `N'
- A constant in the range -65535 to -1 (inclusive).
-
- `O'
- A signed 15-bit constant.
-
- `P'
- A constant in the range 1 to 65535 (inclusive).
-
- `G'
- Floating-point zero.
-
- `R'
- An address that can be used in a non-macro load or store.
-
-_Motorola 680x0--`config/m68k/constraints.md'_
-
- `a'
- Address register
-
- `d'
- Data register
-
- `f'
- 68881 floating-point register, if available
-
- `I'
- Integer in the range 1 to 8
-
- `J'
- 16-bit signed number
-
- `K'
- Signed number whose magnitude is greater than 0x80
-
- `L'
- Integer in the range -8 to -1
-
- `M'
- Signed number whose magnitude is greater than 0x100
-
- `N'
- Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate
-
- `O'
- 16 (for rotate using swap)
-
- `P'
- Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate
-
- `R'
- Numbers that mov3q can handle
-
- `G'
- Floating point constant that is not a 68881 constant
-
- `S'
- Operands that satisfy 'm' when -mpcrel is in effect
-
- `T'
- Operands that satisfy 's' when -mpcrel is not in effect
-
- `Q'
- Address register indirect addressing mode
-
- `U'
- Register offset addressing
-
- `W'
- const_call_operand
-
- `Cs'
- symbol_ref or const
-
- `Ci'
- const_int
-
- `C0'
- const_int 0
-
- `Cj'
- Range of signed numbers that don't fit in 16 bits
-
- `Cmvq'
- Integers valid for mvq
-
- `Capsw'
- Integers valid for a moveq followed by a swap
-
- `Cmvz'
- Integers valid for mvz
-
- `Cmvs'
- Integers valid for mvs
-
- `Ap'
- push_operand
-
- `Ac'
- Non-register operands allowed in clr
-
-
-_Motorola 68HC11 & 68HC12 families--`config/m68hc11/m68hc11.h'_
-
- `a'
- Register `a'
-
- `b'
- Register `b'
-
- `d'
- Register `d'
-
- `q'
- An 8-bit register
-
- `t'
- Temporary soft register _.tmp
-
- `u'
- A soft register _.d1 to _.d31
-
- `w'
- Stack pointer register
-
- `x'
- Register `x'
-
- `y'
- Register `y'
-
- `z'
- Pseudo register `z' (replaced by `x' or `y' at the end)
-
- `A'
- An address register: x, y or z
-
- `B'
- An address register: x or y
-
- `D'
- Register pair (x:d) to form a 32-bit value
-
- `L'
- Constants in the range -65536 to 65535
-
- `M'
- Constants whose 16-bit low part is zero
-
- `N'
- Constant integer 1 or -1
-
- `O'
- Constant integer 16
-
- `P'
- Constants in the range -8 to 2
-
-
-_Moxie--`config/moxie/constraints.md'_
-
- `A'
- An absolute address
-
- `B'
- An offset address
-
- `W'
- A register indirect memory operand
-
- `I'
- A constant in the range of 0 to 255.
-
- `N'
- A constant in the range of 0 to -255.
-
-
-_PDP-11--`config/pdp11/constraints.md'_
-
- `a'
- Floating point registers AC0 through AC3. These can be
- loaded from/to memory with a single instruction.
-
- `d'
- Odd numbered general registers (R1, R3, R5). These are used
- for 16-bit multiply operations.
-
- `f'
- Any of the floating point registers (AC0 through AC5).
-
- `G'
- Floating point constant 0.
-
- `I'
- An integer constant that fits in 16 bits.
-
- `J'
- An integer constant whose low order 16 bits are zero.
-
- `K'
- An integer constant that does not meet the constraints for
- codes `I' or `J'.
-
- `L'
- The integer constant 1.
-
- `M'
- The integer constant -1.
-
- `N'
- The integer constant 0.
-
- `O'
- Integer constants -4 through -1 and 1 through 4; shifts by
- these amounts are handled as multiple single-bit shifts
- rather than a single variable-length shift.
-
- `Q'
- A memory reference which requires an additional word (address
- or offset) after the opcode.
-
- `R'
- A memory reference that is encoded within the opcode.
-
-
-_RX--`config/rx/constraints.md'_
-
- `Q'
- An address which does not involve register indirect
- addressing or pre/post increment/decrement addressing.
-
- `Symbol'
- A symbol reference.
-
- `Int08'
- A constant in the range -256 to 255, inclusive.
-
- `Sint08'
- A constant in the range -128 to 127, inclusive.
-
- `Sint16'
- A constant in the range -32768 to 32767, inclusive.
-
- `Sint24'
- A constant in the range -8388608 to 8388607, inclusive.
-
- `Uint04'
- A constant in the range 0 to 15, inclusive.
-
-
-_SPARC--`config/sparc/sparc.h'_
-
- `f'
- Floating-point register on the SPARC-V8 architecture and
- lower floating-point register on the SPARC-V9 architecture.
-
- `e'
- Floating-point register. It is equivalent to `f' on the
- SPARC-V8 architecture and contains both lower and upper
- floating-point registers on the SPARC-V9 architecture.
-
- `c'
- Floating-point condition code register.
-
- `d'
- Lower floating-point register. It is only valid on the
- SPARC-V9 architecture when the Visual Instruction Set is
- available.
-
- `b'
- Floating-point register. It is only valid on the SPARC-V9
- architecture when the Visual Instruction Set is available.
-
- `h'
- 64-bit global or out register for the SPARC-V8+ architecture.
-
- `D'
- A vector constant
-
- `I'
- Signed 13-bit constant
-
- `J'
- Zero
-
- `K'
- 32-bit constant with the low 12 bits clear (a constant that
- can be loaded with the `sethi' instruction)
-
- `L'
- A constant in the range supported by `movcc' instructions
-
- `M'
- A constant in the range supported by `movrcc' instructions
-
- `N'
- Same as `K', except that it verifies that bits that are not
- in the lower 32-bit range are all zero. Must be used instead
- of `K' for modes wider than `SImode'
-
- `O'
- The constant 4096
-
- `G'
- Floating-point zero
-
- `H'
- Signed 13-bit constant, sign-extended to 32 or 64 bits
-
- `Q'
- Floating-point constant whose integral representation can be
- moved into an integer register using a single sethi
- instruction
-
- `R'
- Floating-point constant whose integral representation can be
- moved into an integer register using a single mov instruction
-
- `S'
- Floating-point constant whose integral representation can be
- moved into an integer register using a high/lo_sum
- instruction sequence
-
- `T'
- Memory address aligned to an 8-byte boundary
-
- `U'
- Even register
-
- `W'
- Memory address for `e' constraint registers
-
- `Y'
- Vector zero
-
-
-_SPU--`config/spu/spu.h'_
-
- `a'
- An immediate which can be loaded with the il/ila/ilh/ilhu
- instructions. const_int is treated as a 64 bit value.
-
- `c'
- An immediate for and/xor/or instructions. const_int is
- treated as a 64 bit value.
-
- `d'
- An immediate for the `iohl' instruction. const_int is
- treated as a 64 bit value.
-
- `f'
- An immediate which can be loaded with `fsmbi'.
-
- `A'
- An immediate which can be loaded with the il/ila/ilh/ilhu
- instructions. const_int is treated as a 32 bit value.
-
- `B'
- An immediate for most arithmetic instructions. const_int is
- treated as a 32 bit value.
-
- `C'
- An immediate for and/xor/or instructions. const_int is
- treated as a 32 bit value.
-
- `D'
- An immediate for the `iohl' instruction. const_int is
- treated as a 32 bit value.
-
- `I'
- A constant in the range [-64, 63] for shift/rotate
- instructions.
-
- `J'
- An unsigned 7-bit constant for conversion/nop/channel
- instructions.
-
- `K'
- A signed 10-bit constant for most arithmetic instructions.
-
- `M'
- A signed 16 bit immediate for `stop'.
-
- `N'
- An unsigned 16-bit constant for `iohl' and `fsmbi'.
-
- `O'
- An unsigned 7-bit constant whose 3 least significant bits are
- 0.
-
- `P'
- An unsigned 3-bit constant for 16-byte rotates and shifts
-
- `R'
- Call operand, reg, for indirect calls
-
- `S'
- Call operand, symbol, for relative calls.
-
- `T'
- Call operand, const_int, for absolute calls.
-
- `U'
- An immediate which can be loaded with the il/ila/ilh/ilhu
- instructions. const_int is sign extended to 128 bit.
-
- `W'
- An immediate for shift and rotate instructions. const_int is
- treated as a 32 bit value.
-
- `Y'
- An immediate for and/xor/or instructions. const_int is sign
- extended as a 128 bit.
-
- `Z'
- An immediate for the `iohl' instruction. const_int is sign
- extended to 128 bit.
-
-
-_S/390 and zSeries--`config/s390/s390.h'_
-
- `a'
- Address register (general purpose register except r0)
-
- `c'
- Condition code register
-
- `d'
- Data register (arbitrary general purpose register)
-
- `f'
- Floating-point register
-
- `I'
- Unsigned 8-bit constant (0-255)
-
- `J'
- Unsigned 12-bit constant (0-4095)
-
- `K'
- Signed 16-bit constant (-32768-32767)
-
- `L'
- Value appropriate as displacement.
- `(0..4095)'
- for short displacement
-
- `(-524288..524287)'
- for long displacement
-
- `M'
- Constant integer with a value of 0x7fffffff.
-
- `N'
- Multiple letter constraint followed by 4 parameter letters.
- `0..9:'
- number of the part counting from most to least
- significant
-
- `H,Q:'
- mode of the part
-
- `D,S,H:'
- mode of the containing operand
-
- `0,F:'
- value of the other parts (F--all bits set)
- The constraint matches if the specified part of a constant
- has a value different from its other parts.
-
- `Q'
- Memory reference without index register and with short
- displacement.
-
- `R'
- Memory reference with index register and short displacement.
-
- `S'
- Memory reference without index register but with long
- displacement.
-
- `T'
- Memory reference with index register and long displacement.
-
- `U'
- Pointer with short displacement.
-
- `W'
- Pointer with long displacement.
-
- `Y'
- Shift count operand.
-
-
-_Score family--`config/score/score.h'_
-
- `d'
- Registers from r0 to r32.
-
- `e'
- Registers from r0 to r16.
-
- `t'
- r8--r11 or r22--r27 registers.
-
- `h'
- hi register.
-
- `l'
- lo register.
-
- `x'
- hi + lo register.
-
- `q'
- cnt register.
-
- `y'
- lcb register.
-
- `z'
- scb register.
-
- `a'
- cnt + lcb + scb register.
-
- `c'
- cr0--cr15 register.
-
- `b'
- cp1 registers.
-
- `f'
- cp2 registers.
-
- `i'
- cp3 registers.
-
- `j'
- cp1 + cp2 + cp3 registers.
-
- `I'
- High 16-bit constant (32-bit constant with 16 LSBs zero).
-
- `J'
- Unsigned 5 bit integer (in the range 0 to 31).
-
- `K'
- Unsigned 16 bit integer (in the range 0 to 65535).
-
- `L'
- Signed 16 bit integer (in the range -32768 to 32767).
-
- `M'
- Unsigned 14 bit integer (in the range 0 to 16383).
-
- `N'
- Signed 14 bit integer (in the range -8192 to 8191).
-
- `Z'
- Any SYMBOL_REF.
-
-_Xstormy16--`config/stormy16/stormy16.h'_
-
- `a'
- Register r0.
-
- `b'
- Register r1.
-
- `c'
- Register r2.
-
- `d'
- Register r8.
-
- `e'
- Registers r0 through r7.
-
- `t'
- Registers r0 and r1.
-
- `y'
- The carry register.
-
- `z'
- Registers r8 and r9.
-
- `I'
- A constant between 0 and 3 inclusive.
-
- `J'
- A constant that has exactly one bit set.
-
- `K'
- A constant that has exactly one bit clear.
-
- `L'
- A constant between 0 and 255 inclusive.
-
- `M'
- A constant between -255 and 0 inclusive.
-
- `N'
- A constant between -3 and 0 inclusive.
-
- `O'
- A constant between 1 and 4 inclusive.
-
- `P'
- A constant between -4 and -1 inclusive.
-
- `Q'
- A memory reference that is a stack push.
-
- `R'
- A memory reference that is a stack pop.
-
- `S'
- A memory reference that refers to a constant address of known
- value.
-
- `T'
- The register indicated by Rx (not implemented yet).
-
- `U'
- A constant that is not between 2 and 15 inclusive.
-
- `Z'
- The constant 0.
-
-
-_Xtensa--`config/xtensa/constraints.md'_
-
- `a'
- General-purpose 32-bit register
-
- `b'
- One-bit boolean register
-
- `A'
- MAC16 40-bit accumulator register
-
- `I'
- Signed 12-bit integer constant, for use in MOVI instructions
-
- `J'
- Signed 8-bit integer constant, for use in ADDI instructions
-
- `K'
- Integer constant valid for BccI instructions
-
- `L'
- Unsigned constant valid for BccUI instructions
-
-
-
-
-File: gccint.info, Node: Disable Insn Alternatives, Next: Machine Constraints, Prev: Modifiers, Up: Constraints
-
-16.8.6 Disable insn alternatives using the `enabled' attribute
---------------------------------------------------------------
-
-The `enabled' insn attribute may be used to disable certain insn
-alternatives for machine-specific reasons. This is useful when adding
-new instructions to an existing pattern which are only available for
-certain cpu architecture levels as specified with the `-march=' option.
-
- If an insn alternative is disabled, then it will never be used. The
-compiler treats the constraints for the disabled alternative as
-unsatisfiable.
-
- In order to make use of the `enabled' attribute a back end has to add
-in the machine description files:
-
- 1. A definition of the `enabled' insn attribute. The attribute is
- defined as usual using the `define_attr' command. This definition
- should be based on other insn attributes and/or target flags. The
- `enabled' attribute is a numeric attribute and should evaluate to
- `(const_int 1)' for an enabled alternative and to `(const_int 0)'
- otherwise.
-
- 2. A definition of another insn attribute used to describe for what
- reason an insn alternative might be available or not. E.g.
- `cpu_facility' as in the example below.
-
- 3. An assignment for the second attribute to each insn definition
- combining instructions which are not all available under the same
- circumstances. (Note: It obviously only makes sense for
- definitions with more than one alternative. Otherwise the insn
- pattern should be disabled or enabled using the insn condition.)
-
- E.g. the following two patterns could easily be merged using the
-`enabled' attribute:
-
-
- (define_insn "*movdi_old"
- [(set (match_operand:DI 0 "register_operand" "=d")
- (match_operand:DI 1 "register_operand" " d"))]
- "!TARGET_NEW"
- "lgr %0,%1")
-
- (define_insn "*movdi_new"
- [(set (match_operand:DI 0 "register_operand" "=d,f,d")
- (match_operand:DI 1 "register_operand" " d,d,f"))]
- "TARGET_NEW"
- "@
- lgr %0,%1
- ldgr %0,%1
- lgdr %0,%1")
-
- to:
-
-
- (define_insn "*movdi_combined"
- [(set (match_operand:DI 0 "register_operand" "=d,f,d")
- (match_operand:DI 1 "register_operand" " d,d,f"))]
- ""
- "@
- lgr %0,%1
- ldgr %0,%1
- lgdr %0,%1"
- [(set_attr "cpu_facility" "*,new,new")])
-
- with the `enabled' attribute defined like this:
-
-
- (define_attr "cpu_facility" "standard,new" (const_string "standard"))
-
- (define_attr "enabled" ""
- (cond [(eq_attr "cpu_facility" "standard") (const_int 1)
- (and (eq_attr "cpu_facility" "new")
- (ne (symbol_ref "TARGET_NEW") (const_int 0)))
- (const_int 1)]
- (const_int 0)))
-
-
-File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Machine Constraints, Up: Constraints
-
-16.8.7 Defining Machine-Specific Constraints
---------------------------------------------
-
-Machine-specific constraints fall into two categories: register and
-non-register constraints. Within the latter category, constraints
-which allow subsets of all possible memory or address operands should
-be specially marked, to give `reload' more information.
-
- Machine-specific constraints can be given names of arbitrary length,
-but they must be entirely composed of letters, digits, underscores
-(`_'), and angle brackets (`< >'). Like C identifiers, they must begin
-with a letter or underscore.
-
- In order to avoid ambiguity in operand constraint strings, no
-constraint can have a name that begins with any other constraint's
-name. For example, if `x' is defined as a constraint name, `xy' may
-not be, and vice versa. As a consequence of this rule, no constraint
-may begin with one of the generic constraint letters: `E F V X g i m n
-o p r s'.
-
- Register constraints correspond directly to register classes. *Note
-Register Classes::. There is thus not much flexibility in their
-definitions.
-
- -- MD Expression: define_register_constraint name regclass docstring
- All three arguments are string constants. NAME is the name of the
- constraint, as it will appear in `match_operand' expressions. If
- NAME is a multi-letter constraint its length shall be the same for
- all constraints starting with the same letter. REGCLASS can be
- either the name of the corresponding register class (*note
- Register Classes::), or a C expression which evaluates to the
- appropriate register class. If it is an expression, it must have
- no side effects, and it cannot look at the operand. The usual use
- of expressions is to map some register constraints to `NO_REGS'
- when the register class is not available on a given
- subarchitecture.
-
- DOCSTRING is a sentence documenting the meaning of the constraint.
- Docstrings are explained further below.
-
- Non-register constraints are more like predicates: the constraint
-definition gives a Boolean expression which indicates whether the
-constraint matches.
-
- -- MD Expression: define_constraint name docstring exp
- The NAME and DOCSTRING arguments are the same as for
- `define_register_constraint', but note that the docstring comes
- immediately after the name for these expressions. EXP is an RTL
- expression, obeying the same rules as the RTL expressions in
- predicate definitions. *Note Defining Predicates::, for details.
- If it evaluates true, the constraint matches; if it evaluates
- false, it doesn't. Constraint expressions should indicate which
- RTL codes they might match, just like predicate expressions.
-
- `match_test' C expressions have access to the following variables:
-
- OP
- The RTL object defining the operand.
-
- MODE
- The machine mode of OP.
-
- IVAL
- `INTVAL (OP)', if OP is a `const_int'.
-
- HVAL
- `CONST_DOUBLE_HIGH (OP)', if OP is an integer `const_double'.
-
- LVAL
- `CONST_DOUBLE_LOW (OP)', if OP is an integer `const_double'.
-
- RVAL
- `CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point
- `const_double'.
-
- The *VAL variables should only be used once another piece of the
- expression has verified that OP is the appropriate kind of RTL
- object.
-
- Most non-register constraints should be defined with
-`define_constraint'. The remaining two definition expressions are only
-appropriate for constraints that should be handled specially by
-`reload' if they fail to match.
-
- -- MD Expression: define_memory_constraint name docstring exp
- Use this expression for constraints that match a subset of all
- memory operands: that is, `reload' can make them match by
- converting the operand to the form `(mem (reg X))', where X is a
- base register (from the register class specified by
- `BASE_REG_CLASS', *note Register Classes::).
-
- For example, on the S/390, some instructions do not accept
- arbitrary memory references, but only those that do not make use
- of an index register. The constraint letter `Q' is defined to
- represent a memory address of this type. If `Q' is defined with
- `define_memory_constraint', a `Q' constraint can handle any memory
- operand, because `reload' knows it can simply copy the memory
- address into a base register if required. This is analogous to
- the way an `o' constraint can handle any memory operand.
-
- The syntax and semantics are otherwise identical to
- `define_constraint'.
-
- -- MD Expression: define_address_constraint name docstring exp
- Use this expression for constraints that match a subset of all
- address operands: that is, `reload' can make the constraint match
- by converting the operand to the form `(reg X)', again with X a
- base register.
-
- Constraints defined with `define_address_constraint' can only be
- used with the `address_operand' predicate, or machine-specific
- predicates that work the same way. They are treated analogously to
- the generic `p' constraint.
-
- The syntax and semantics are otherwise identical to
- `define_constraint'.
-
- For historical reasons, names beginning with the letters `G H' are
-reserved for constraints that match only `const_double's, and names
-beginning with the letters `I J K L M N O P' are reserved for
-constraints that match only `const_int's. This may change in the
-future. For the time being, constraints with these names must be
-written in a stylized form, so that `genpreds' can tell you did it
-correctly:
-
- (define_constraint "[GHIJKLMNOP]..."
- "DOC..."
- (and (match_code "const_int") ; `const_double' for G/H
- CONDITION...)) ; usually a `match_test'
-
- It is fine to use names beginning with other letters for constraints
-that match `const_double's or `const_int's.
-
- Each docstring in a constraint definition should be one or more
-complete sentences, marked up in Texinfo format. _They are currently
-unused._ In the future they will be copied into the GCC manual, in
-*note Machine Constraints::, replacing the hand-maintained tables
-currently found in that section. Also, in the future the compiler may
-use this to give more helpful diagnostics when poor choice of `asm'
-constraints causes a reload failure.
-
- If you put the pseudo-Texinfo directive `@internal' at the beginning
-of a docstring, then (in the future) it will appear only in the
-internals manual's version of the machine-specific constraint tables.
-Use this for constraints that should not appear in `asm' statements.
-
-
-File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints
-
-16.8.8 Testing constraints from C
----------------------------------
-
-It is occasionally useful to test a constraint from C code rather than
-implicitly via the constraint string in a `match_operand'. The
-generated file `tm_p.h' declares a few interfaces for working with
-machine-specific constraints. None of these interfaces work with the
-generic constraints described in *note Simple Constraints::. This may
-change in the future.
-
- *Warning:* `tm_p.h' may declare other functions that operate on
-constraints, besides the ones documented here. Do not use those
-functions from machine-dependent code. They exist to implement the old
-constraint interface that machine-independent components of the
-compiler still expect. They will change or disappear in the future.
-
- Some valid constraint names are not valid C identifiers, so there is a
-mangling scheme for referring to them from C. Constraint names that do
-not contain angle brackets or underscores are left unchanged.
-Underscores are doubled, each `<' is replaced with `_l', and each `>'
-with `_g'. Here are some examples:
-
- *Original* *Mangled*
- `x' `x'
- `P42x' `P42x'
- `P4_x' `P4__x'
- `P4>x' `P4_gx'
- `P4>>' `P4_g_g'
- `P4_g>' `P4__g_g'
-
- Throughout this section, the variable C is either a constraint in the
-abstract sense, or a constant from `enum constraint_num'; the variable
-M is a mangled constraint name (usually as part of a larger identifier).
-
- -- Enum: constraint_num
- For each machine-specific constraint, there is a corresponding
- enumeration constant: `CONSTRAINT_' plus the mangled name of the
- constraint. Functions that take an `enum constraint_num' as an
- argument expect one of these constants.
-
- Machine-independent constraints do not have associated constants.
- This may change in the future.
-
- -- Function: inline bool satisfies_constraint_M (rtx EXP)
- For each machine-specific, non-register constraint M, there is one
- of these functions; it returns `true' if EXP satisfies the
- constraint. These functions are only visible if `rtl.h' was
- included before `tm_p.h'.
-
- -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num
- C)
- Like the `satisfies_constraint_M' functions, but the constraint to
- test is given as an argument, C. If C specifies a register
- constraint, this function will always return `false'.
-
- -- Function: enum reg_class regclass_for_constraint (enum
- constraint_num C)
- Returns the register class associated with C. If C is not a
- register constraint, or those registers are not available for the
- currently selected subtarget, returns `NO_REGS'.
-
- Here is an example use of `satisfies_constraint_M'. In peephole
-optimizations (*note Peephole Definitions::), operand constraint
-strings are ignored, so if there are relevant constraints, they must be
-tested in the C condition. In the example, the optimization is applied
-if operand 2 does _not_ satisfy the `K' constraint. (This is a
-simplified version of a peephole definition from the i386 machine
-description.)
-
- (define_peephole2
- [(match_scratch:SI 3 "r")
- (set (match_operand:SI 0 "register_operand" "")
- (mult:SI (match_operand:SI 1 "memory_operand" "")
- (match_operand:SI 2 "immediate_operand" "")))]
-
- "!satisfies_constraint_K (operands[2])"
-
- [(set (match_dup 3) (match_dup 1))
- (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))]
-
- "")
-
-
-File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc
-
-16.9 Standard Pattern Names For Generation
-==========================================
-
-Here is a table of the instruction names that are meaningful in the RTL
-generation pass of the compiler. Giving one of these names to an
-instruction pattern tells the RTL generation pass that it can use the
-pattern to accomplish a certain task.
-
-`movM'
- Here M stands for a two-letter machine mode name, in lowercase.
- This instruction pattern moves data with that machine mode from
- operand 1 to operand 0. For example, `movsi' moves full-word data.
-
- If operand 0 is a `subreg' with mode M of a register whose own
- mode is wider than M, the effect of this instruction is to store
- the specified value in the part of the register that corresponds
- to mode M. Bits outside of M, but which are within the same
- target word as the `subreg' are undefined. Bits which are outside
- the target word are left unchanged.
-
- This class of patterns is special in several ways. First of all,
- each of these names up to and including full word size _must_ be
- defined, because there is no other way to copy a datum from one
- place to another. If there are patterns accepting operands in
- larger modes, `movM' must be defined for integer modes of those
- sizes.
-
- Second, these patterns are not used solely in the RTL generation
- pass. Even the reload pass can generate move insns to copy values
- from stack slots into temporary registers. When it does so, one
- of the operands is a hard register and the other is an operand
- that can need to be reloaded into a register.
-
- Therefore, when given such a pair of operands, the pattern must
- generate RTL which needs no reloading and needs no temporary
- registers--no registers other than the operands. For example, if
- you support the pattern with a `define_expand', then in such a
- case the `define_expand' mustn't call `force_reg' or any other such
- function which might generate new pseudo registers.
-
- This requirement exists even for subword modes on a RISC machine
- where fetching those modes from memory normally requires several
- insns and some temporary registers.
-
- During reload a memory reference with an invalid address may be
- passed as an operand. Such an address will be replaced with a
- valid address later in the reload pass. In this case, nothing may
- be done with the address except to use it as it stands. If it is
- copied, it will not be replaced with a valid address. No attempt
- should be made to make such an address into a valid address and no
- routine (such as `change_address') that will do so may be called.
- Note that `general_operand' will fail when applied to such an
- address.
-
- The global variable `reload_in_progress' (which must be explicitly
- declared if required) can be used to determine whether such special
- handling is required.
-
- The variety of operands that have reloads depends on the rest of
- the machine description, but typically on a RISC machine these can
- only be pseudo registers that did not get hard registers, while on
- other machines explicit memory references will get optional
- reloads.
-
- If a scratch register is required to move an object to or from
- memory, it can be allocated using `gen_reg_rtx' prior to life
- analysis.
-
- If there are cases which need scratch registers during or after
- reload, you must provide an appropriate secondary_reload target
- hook.
-
- The macro `can_create_pseudo_p' can be used to determine if it is
- unsafe to create new pseudo registers. If this variable is
- nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new
- pseudo.
-
- The constraints on a `movM' must permit moving any hard register
- to any other hard register provided that `HARD_REGNO_MODE_OK'
- permits mode M in both registers and `TARGET_REGISTER_MOVE_COST'
- applied to their classes returns a value of 2.
-
- It is obligatory to support floating point `movM' instructions
- into and out of any registers that can hold fixed point values,
- because unions and structures (which have modes `SImode' or
- `DImode') can be in those registers and they may have floating
- point members.
-
- There may also be a need to support fixed point `movM'
- instructions in and out of floating point registers.
- Unfortunately, I have forgotten why this was so, and I don't know
- whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed
- point values in floating point registers, then the constraints of
- the fixed point `movM' instructions must be designed to avoid ever
- trying to reload into a floating point register.
-
-`reload_inM'
-`reload_outM'
- These named patterns have been obsoleted by the target hook
- `secondary_reload'.
-
- Like `movM', but used when a scratch register is required to move
- between operand 0 and operand 1. Operand 2 describes the scratch
- register. See the discussion of the `SECONDARY_RELOAD_CLASS'
- macro in *note Register Classes::.
-
- There are special restrictions on the form of the `match_operand's
- used in these patterns. First, only the predicate for the reload
- operand is examined, i.e., `reload_in' examines operand 1, but not
- the predicates for operand 0 or 2. Second, there may be only one
- alternative in the constraints. Third, only a single register
- class letter may be used for the constraint; subsequent constraint
- letters are ignored. As a special exception, an empty constraint
- string matches the `ALL_REGS' register class. This may relieve
- ports of the burden of defining an `ALL_REGS' constraint letter
- just for these patterns.
-
-`movstrictM'
- Like `movM' except that if operand 0 is a `subreg' with mode M of
- a register whose natural mode is wider, the `movstrictM'
- instruction is guaranteed not to alter any of the register except
- the part which belongs to mode M.
-
-`movmisalignM'
- This variant of a move pattern is designed to load or store a value
- from a memory address that is not naturally aligned for its mode.
- For a store, the memory will be in operand 0; for a load, the
- memory will be in operand 1. The other operand is guaranteed not
- to be a memory, so that it's easy to tell whether this is a load
- or store.
-
- This pattern is used by the autovectorizer, and when expanding a
- `MISALIGNED_INDIRECT_REF' expression.
-
-`load_multiple'
- Load several consecutive memory locations into consecutive
- registers. Operand 0 is the first of the consecutive registers,
- operand 1 is the first memory location, and operand 2 is a
- constant: the number of consecutive registers.
-
- Define this only if the target machine really has such an
- instruction; do not define this if the most efficient way of
- loading consecutive registers from memory is to do them one at a
- time.
-
- On some machines, there are restrictions as to which consecutive
- registers can be stored into memory, such as particular starting or
- ending register numbers or only a range of valid counts. For those
- machines, use a `define_expand' (*note Expander Definitions::) and
- make the pattern fail if the restrictions are not met.
-
- Write the generated insn as a `parallel' with elements being a
- `set' of one register from the appropriate memory location (you may
- also need `use' or `clobber' elements). Use a `match_parallel'
- (*note RTL Template::) to recognize the insn. See `rs6000.md' for
- examples of the use of this insn pattern.
-
-`store_multiple'
- Similar to `load_multiple', but store several consecutive registers
- into consecutive memory locations. Operand 0 is the first of the
- consecutive memory locations, operand 1 is the first register, and
- operand 2 is a constant: the number of consecutive registers.
-
-`vec_setM'
- Set given field in the vector value. Operand 0 is the vector to
- modify, operand 1 is new value of field and operand 2 specify the
- field index.
-
-`vec_extractM'
- Extract given field from the vector value. Operand 1 is the
- vector, operand 2 specify field index and operand 0 place to store
- value into.
-
-`vec_extract_evenM'
- Extract even elements from the input vectors (operand 1 and
- operand 2). The even elements of operand 2 are concatenated to
- the even elements of operand 1 in their original order. The result
- is stored in operand 0. The output and input vectors should have
- the same modes.
-
-`vec_extract_oddM'
- Extract odd elements from the input vectors (operand 1 and operand
- 2). The odd elements of operand 2 are concatenated to the odd
- elements of operand 1 in their original order. The result is
- stored in operand 0. The output and input vectors should have the
- same modes.
-
-`vec_interleave_highM'
- Merge high elements of the two input vectors into the output
- vector. The output and input vectors should have the same modes
- (`N' elements). The high `N/2' elements of the first input vector
- are interleaved with the high `N/2' elements of the second input
- vector.
-
-`vec_interleave_lowM'
- Merge low elements of the two input vectors into the output
- vector. The output and input vectors should have the same modes
- (`N' elements). The low `N/2' elements of the first input vector
- are interleaved with the low `N/2' elements of the second input
- vector.
-
-`vec_initM'
- Initialize the vector to given values. Operand 0 is the vector to
- initialize and operand 1 is parallel containing values for
- individual fields.
-
-`pushM1'
- Output a push instruction. Operand 0 is value to push. Used only
- when `PUSH_ROUNDING' is defined. For historical reason, this
- pattern may be missing and in such case an `mov' expander is used
- instead, with a `MEM' expression forming the push operation. The
- `mov' expander method is deprecated.
-
-`addM3'
- Add operand 2 and operand 1, storing the result in operand 0. All
- operands must have mode M. This can be used even on two-address
- machines, by means of constraints requiring operands 1 and 0 to be
- the same location.
-
-`ssaddM3', `usaddM3'
-
-`subM3', `sssubM3', `ussubM3'
-
-`mulM3', `ssmulM3', `usmulM3'
-`divM3', `ssdivM3'
-`udivM3', `usdivM3'
-`modM3', `umodM3'
-`uminM3', `umaxM3'
-`andM3', `iorM3', `xorM3'
- Similar, for other arithmetic operations.
-
-`fmaM4'
- Multiply operand 2 and operand 1, then add operand 3, storing the
- result in operand 0. All operands must have mode M. This pattern
- is used to implement the `fma', `fmaf', and `fmal' builtin
- functions from the ISO C99 standard. The `fma' operation may
- produce different results than doing the multiply followed by the
- add if the machine does not perform a rounding step between the
- operations.
-
-`fmsM4'
- Like `fmaM4', except operand 3 subtracted from the product instead
- of added to the product. This is represented in the rtl as
-
- (fma:M OP1 OP2 (neg:M OP3))
-
-`fnmaM4'
- Like `fmaM4' except that the intermediate product is negated
- before being added to operand 3. This is represented in the rtl as
-
- (fma:M (neg:M OP1) OP2 OP3)
-
-`fnmsM4'
- Like `fmsM4' except that the intermediate product is negated
- before subtracting operand 3. This is represented in the rtl as
-
- (fma:M (neg:M OP1) OP2 (neg:M OP3))
-
-`sminM3', `smaxM3'
- Signed minimum and maximum operations. When used with floating
- point, if both operands are zeros, or if either operand is `NaN',
- then it is unspecified which of the two operands is returned as
- the result.
-
-`reduc_smin_M', `reduc_smax_M'
- Find the signed minimum/maximum of the elements of a vector. The
- vector is operand 1, and the scalar result is stored in the least
- significant bits of operand 0 (also a vector). The output and
- input vector should have the same modes.
-
-`reduc_umin_M', `reduc_umax_M'
- Find the unsigned minimum/maximum of the elements of a vector. The
- vector is operand 1, and the scalar result is stored in the least
- significant bits of operand 0 (also a vector). The output and
- input vector should have the same modes.
-
-`reduc_splus_M'
- Compute the sum of the signed elements of a vector. The vector is
- operand 1, and the scalar result is stored in the least
- significant bits of operand 0 (also a vector). The output and
- input vector should have the same modes.
-
-`reduc_uplus_M'
- Compute the sum of the unsigned elements of a vector. The vector
- is operand 1, and the scalar result is stored in the least
- significant bits of operand 0 (also a vector). The output and
- input vector should have the same modes.
-
-`sdot_prodM'
-
-`udot_prodM'
- Compute the sum of the products of two signed/unsigned elements.
- Operand 1 and operand 2 are of the same mode. Their product, which
- is of a wider mode, is computed and added to operand 3. Operand 3
- is of a mode equal or wider than the mode of the product. The
- result is placed in operand 0, which is of the same mode as
- operand 3.
-
-`ssum_widenM3'
-
-`usum_widenM3'
- Operands 0 and 2 are of the same mode, which is wider than the
- mode of operand 1. Add operand 1 to operand 2 and place the
- widened result in operand 0. (This is used express accumulation of
- elements into an accumulator of a wider mode.)
-
-`vec_shl_M', `vec_shr_M'
- Whole vector left/right shift in bits. Operand 1 is a vector to
- be shifted. Operand 2 is an integer shift amount in bits.
- Operand 0 is where the resulting shifted vector is stored. The
- output and input vectors should have the same modes.
-
-`vec_pack_trunc_M'
- Narrow (demote) and merge the elements of two vectors. Operands 1
- and 2 are vectors of the same mode having N integral or floating
- point elements of size S. Operand 0 is the resulting vector in
- which 2*N elements of size N/2 are concatenated after narrowing
- them down using truncation.
-
-`vec_pack_ssat_M', `vec_pack_usat_M'
- Narrow (demote) and merge the elements of two vectors. Operands 1
- and 2 are vectors of the same mode having N integral elements of
- size S. Operand 0 is the resulting vector in which the elements
- of the two input vectors are concatenated after narrowing them
- down using signed/unsigned saturating arithmetic.
-
-`vec_pack_sfix_trunc_M', `vec_pack_ufix_trunc_M'
- Narrow, convert to signed/unsigned integral type and merge the
- elements of two vectors. Operands 1 and 2 are vectors of the same
- mode having N floating point elements of size S. Operand 0 is the
- resulting vector in which 2*N elements of size N/2 are
- concatenated.
-
-`vec_unpacks_hi_M', `vec_unpacks_lo_M'
- Extract and widen (promote) the high/low part of a vector of signed
- integral or floating point elements. The input vector (operand 1)
- has N elements of size S. Widen (promote) the high/low elements
- of the vector using signed or floating point extension and place
- the resulting N/2 values of size 2*S in the output vector (operand
- 0).
-
-`vec_unpacku_hi_M', `vec_unpacku_lo_M'
- Extract and widen (promote) the high/low part of a vector of
- unsigned integral elements. The input vector (operand 1) has N
- elements of size S. Widen (promote) the high/low elements of the
- vector using zero extension and place the resulting N/2 values of
- size 2*S in the output vector (operand 0).
-
-`vec_unpacks_float_hi_M', `vec_unpacks_float_lo_M'
-`vec_unpacku_float_hi_M', `vec_unpacku_float_lo_M'
- Extract, convert to floating point type and widen the high/low
- part of a vector of signed/unsigned integral elements. The input
- vector (operand 1) has N elements of size S. Convert the high/low
- elements of the vector using floating point conversion and place
- the resulting N/2 values of size 2*S in the output vector (operand
- 0).
-
-`vec_widen_umult_hi_M', `vec_widen_umult_lo_M'
-`vec_widen_smult_hi_M', `vec_widen_smult_lo_M'
- Signed/Unsigned widening multiplication. The two inputs (operands
- 1 and 2) are vectors with N signed/unsigned elements of size S.
- Multiply the high/low elements of the two vectors, and put the N/2
- products of size 2*S in the output vector (operand 0).
-
-`mulhisi3'
- Multiply operands 1 and 2, which have mode `HImode', and store a
- `SImode' product in operand 0.
-
-`mulqihi3', `mulsidi3'
- Similar widening-multiplication instructions of other widths.
-
-`umulqihi3', `umulhisi3', `umulsidi3'
- Similar widening-multiplication instructions that do unsigned
- multiplication.
-
-`usmulqihi3', `usmulhisi3', `usmulsidi3'
- Similar widening-multiplication instructions that interpret the
- first operand as unsigned and the second operand as signed, then
- do a signed multiplication.
-
-`smulM3_highpart'
- Perform a signed multiplication of operands 1 and 2, which have
- mode M, and store the most significant half of the product in
- operand 0. The least significant half of the product is discarded.
-
-`umulM3_highpart'
- Similar, but the multiplication is unsigned.
-
-`maddMN4'
- Multiply operands 1 and 2, sign-extend them to mode N, add operand
- 3, and store the result in operand 0. Operands 1 and 2 have mode
- M and operands 0 and 3 have mode N. Both modes must be integer or
- fixed-point modes and N must be twice the size of M.
-
- In other words, `maddMN4' is like `mulMN3' except that it also
- adds operand 3.
-
- These instructions are not allowed to `FAIL'.
-
-`umaddMN4'
- Like `maddMN4', but zero-extend the multiplication operands
- instead of sign-extending them.
-
-`ssmaddMN4'
- Like `maddMN4', but all involved operations must be
- signed-saturating.
-
-`usmaddMN4'
- Like `umaddMN4', but all involved operations must be
- unsigned-saturating.
-
-`msubMN4'
- Multiply operands 1 and 2, sign-extend them to mode N, subtract the
- result from operand 3, and store the result in operand 0.
- Operands 1 and 2 have mode M and operands 0 and 3 have mode N.
- Both modes must be integer or fixed-point modes and N must be twice
- the size of M.
-
- In other words, `msubMN4' is like `mulMN3' except that it also
- subtracts the result from operand 3.
-
- These instructions are not allowed to `FAIL'.
-
-`umsubMN4'
- Like `msubMN4', but zero-extend the multiplication operands
- instead of sign-extending them.
-
-`ssmsubMN4'
- Like `msubMN4', but all involved operations must be
- signed-saturating.
-
-`usmsubMN4'
- Like `umsubMN4', but all involved operations must be
- unsigned-saturating.
-
-`divmodM4'
- Signed division that produces both a quotient and a remainder.
- Operand 1 is divided by operand 2 to produce a quotient stored in
- operand 0 and a remainder stored in operand 3.
-
- For machines with an instruction that produces both a quotient and
- a remainder, provide a pattern for `divmodM4' but do not provide
- patterns for `divM3' and `modM3'. This allows optimization in the
- relatively common case when both the quotient and remainder are
- computed.
-
- If an instruction that just produces a quotient or just a remainder
- exists and is more efficient than the instruction that produces
- both, write the output routine of `divmodM4' to call
- `find_reg_note' and look for a `REG_UNUSED' note on the quotient
- or remainder and generate the appropriate instruction.
-
-`udivmodM4'
- Similar, but does unsigned division.
-
-`ashlM3', `ssashlM3', `usashlM3'
- Arithmetic-shift operand 1 left by a number of bits specified by
- operand 2, and store the result in operand 0. Here M is the mode
- of operand 0 and operand 1; operand 2's mode is specified by the
- instruction pattern, and the compiler will convert the operand to
- that mode before generating the instruction. The meaning of
- out-of-range shift counts can optionally be specified by
- `TARGET_SHIFT_TRUNCATION_MASK'. *Note
- TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type.
-
-`ashrM3', `lshrM3', `rotlM3', `rotrM3'
- Other shift and rotate instructions, analogous to the `ashlM3'
- instructions. Operand 2 is always a scalar type.
-
-`vashlM3', `vashrM3', `vlshrM3', `vrotlM3', `vrotrM3'
- Vector shift and rotate instructions that take vectors as operand 2
- instead of a scalar type.
-
-`negM2', `ssnegM2', `usnegM2'
- Negate operand 1 and store the result in operand 0.
-
-`absM2'
- Store the absolute value of operand 1 into operand 0.
-
-`sqrtM2'
- Store the square root of operand 1 into operand 0.
-
- The `sqrt' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `sqrtf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`fmodM3'
- Store the remainder of dividing operand 1 by operand 2 into
- operand 0, rounded towards zero to an integer.
-
- The `fmod' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `fmodf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`remainderM3'
- Store the remainder of dividing operand 1 by operand 2 into
- operand 0, rounded to the nearest integer.
-
- The `remainder' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `remainderf'
- built-in function uses the mode which corresponds to the C data
- type `float'.
-
-`cosM2'
- Store the cosine of operand 1 into operand 0.
-
- The `cos' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `cosf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`sinM2'
- Store the sine of operand 1 into operand 0.
-
- The `sin' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `sinf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`expM2'
- Store the exponential of operand 1 into operand 0.
-
- The `exp' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `expf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`logM2'
- Store the natural logarithm of operand 1 into operand 0.
-
- The `log' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `logf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`powM3'
- Store the value of operand 1 raised to the exponent operand 2 into
- operand 0.
-
- The `pow' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `powf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`atan2M3'
- Store the arc tangent (inverse tangent) of operand 1 divided by
- operand 2 into operand 0, using the signs of both arguments to
- determine the quadrant of the result.
-
- The `atan2' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `atan2f' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`floorM2'
- Store the largest integral value not greater than argument.
-
- The `floor' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `floorf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`btruncM2'
- Store the argument rounded to integer towards zero.
-
- The `trunc' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `truncf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`roundM2'
- Store the argument rounded to integer away from zero.
-
- The `round' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `roundf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`ceilM2'
- Store the argument rounded to integer away from zero.
-
- The `ceil' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `ceilf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`nearbyintM2'
- Store the argument rounded according to the default rounding mode
-
- The `nearbyint' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `nearbyintf'
- built-in function uses the mode which corresponds to the C data
- type `float'.
-
-`rintM2'
- Store the argument rounded according to the default rounding mode
- and raise the inexact exception when the result differs in value
- from the argument
-
- The `rint' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `rintf' built-in
- function uses the mode which corresponds to the C data type
- `float'.
-
-`lrintMN2'
- Convert operand 1 (valid for floating point mode M) to fixed point
- mode N as a signed number according to the current rounding mode
- and store in operand 0 (which has mode N).
-
-`lroundMN2'
- Convert operand 1 (valid for floating point mode M) to fixed point
- mode N as a signed number rounding to nearest and away from zero
- and store in operand 0 (which has mode N).
-
-`lfloorMN2'
- Convert operand 1 (valid for floating point mode M) to fixed point
- mode N as a signed number rounding down and store in operand 0
- (which has mode N).
-
-`lceilMN2'
- Convert operand 1 (valid for floating point mode M) to fixed point
- mode N as a signed number rounding up and store in operand 0
- (which has mode N).
-
-`copysignM3'
- Store a value with the magnitude of operand 1 and the sign of
- operand 2 into operand 0.
-
- The `copysign' built-in function of C always uses the mode which
- corresponds to the C data type `double' and the `copysignf'
- built-in function uses the mode which corresponds to the C data
- type `float'.
-
-`ffsM2'
- Store into operand 0 one plus the index of the least significant
- 1-bit of operand 1. If operand 1 is zero, store zero. M is the
- mode of operand 0; operand 1's mode is specified by the instruction
- pattern, and the compiler will convert the operand to that mode
- before generating the instruction.
-
- The `ffs' built-in function of C always uses the mode which
- corresponds to the C data type `int'.
-
-`clzM2'
- Store into operand 0 the number of leading 0-bits in X, starting
- at the most significant bit position. If X is 0, the
- `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the
- result is undefined or has a useful value. M is the mode of
- operand 0; operand 1's mode is specified by the instruction
- pattern, and the compiler will convert the operand to that mode
- before generating the instruction.
-
-`ctzM2'
- Store into operand 0 the number of trailing 0-bits in X, starting
- at the least significant bit position. If X is 0, the
- `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the
- result is undefined or has a useful value. M is the mode of
- operand 0; operand 1's mode is specified by the instruction
- pattern, and the compiler will convert the operand to that mode
- before generating the instruction.
-
-`popcountM2'
- Store into operand 0 the number of 1-bits in X. M is the mode of
- operand 0; operand 1's mode is specified by the instruction
- pattern, and the compiler will convert the operand to that mode
- before generating the instruction.
-
-`parityM2'
- Store into operand 0 the parity of X, i.e. the number of 1-bits in
- X modulo 2. M is the mode of operand 0; operand 1's mode is
- specified by the instruction pattern, and the compiler will convert
- the operand to that mode before generating the instruction.
-
-`one_cmplM2'
- Store the bitwise-complement of operand 1 into operand 0.
-
-`movmemM'
- Block move instruction. The destination and source blocks of
- memory are the first two operands, and both are `mem:BLK's with an
- address in mode `Pmode'.
-
- The number of bytes to move is the third operand, in mode M.
- Usually, you specify `word_mode' for M. However, if you can
- generate better code knowing the range of valid lengths is smaller
- than those representable in a full word, you should provide a
- pattern with a mode corresponding to the range of values you can
- handle efficiently (e.g., `QImode' for values in the range 0-127;
- note we avoid numbers that appear negative) and also a pattern
- with `word_mode'.
-
- The fourth operand is the known shared alignment of the source and
- destination, in the form of a `const_int' rtx. Thus, if the
- compiler knows that both source and destination are word-aligned,
- it may provide the value 4 for this operand.
-
- Optional operands 5 and 6 specify expected alignment and size of
- block respectively. The expected alignment differs from alignment
- in operand 4 in a way that the blocks are not required to be
- aligned according to it in all cases. This expected alignment is
- also in bytes, just like operand 4. Expected size, when unknown,
- is set to `(const_int -1)'.
-
- Descriptions of multiple `movmemM' patterns can only be beneficial
- if the patterns for smaller modes have fewer restrictions on their
- first, second and fourth operands. Note that the mode M in
- `movmemM' does not impose any restriction on the mode of
- individually moved data units in the block.
-
- These patterns need not give special consideration to the
- possibility that the source and destination strings might overlap.
-
-`movstr'
- String copy instruction, with `stpcpy' semantics. Operand 0 is an
- output operand in mode `Pmode'. The addresses of the destination
- and source strings are operands 1 and 2, and both are `mem:BLK's
- with addresses in mode `Pmode'. The execution of the expansion of
- this pattern should store in operand 0 the address in which the
- `NUL' terminator was stored in the destination string.
-
-`setmemM'
- Block set instruction. The destination string is the first
- operand, given as a `mem:BLK' whose address is in mode `Pmode'.
- The number of bytes to set is the second operand, in mode M. The
- value to initialize the memory with is the third operand. Targets
- that only support the clearing of memory should reject any value
- that is not the constant 0. See `movmemM' for a discussion of the
- choice of mode.
-
- The fourth operand is the known alignment of the destination, in
- the form of a `const_int' rtx. Thus, if the compiler knows that
- the destination is word-aligned, it may provide the value 4 for
- this operand.
-
- Optional operands 5 and 6 specify expected alignment and size of
- block respectively. The expected alignment differs from alignment
- in operand 4 in a way that the blocks are not required to be
- aligned according to it in all cases. This expected alignment is
- also in bytes, just like operand 4. Expected size, when unknown,
- is set to `(const_int -1)'.
-
- The use for multiple `setmemM' is as for `movmemM'.
-
-`cmpstrnM'
- String compare instruction, with five operands. Operand 0 is the
- output; it has mode M. The remaining four operands are like the
- operands of `movmemM'. The two memory blocks specified are
- compared byte by byte in lexicographic order starting at the
- beginning of each string. The instruction is not allowed to
- prefetch more than one byte at a time since either string may end
- in the first byte and reading past that may access an invalid page
- or segment and cause a fault. The comparison terminates early if
- the fetched bytes are different or if they are equal to zero. The
- effect of the instruction is to store a value in operand 0 whose
- sign indicates the result of the comparison.
-
-`cmpstrM'
- String compare instruction, without known maximum length. Operand
- 0 is the output; it has mode M. The second and third operand are
- the blocks of memory to be compared; both are `mem:BLK' with an
- address in mode `Pmode'.
-
- The fourth operand is the known shared alignment of the source and
- destination, in the form of a `const_int' rtx. Thus, if the
- compiler knows that both source and destination are word-aligned,
- it may provide the value 4 for this operand.
-
- The two memory blocks specified are compared byte by byte in
- lexicographic order starting at the beginning of each string. The
- instruction is not allowed to prefetch more than one byte at a
- time since either string may end in the first byte and reading
- past that may access an invalid page or segment and cause a fault.
- The comparison will terminate when the fetched bytes are different
- or if they are equal to zero. The effect of the instruction is to
- store a value in operand 0 whose sign indicates the result of the
- comparison.
-
-`cmpmemM'
- Block compare instruction, with five operands like the operands of
- `cmpstrM'. The two memory blocks specified are compared byte by
- byte in lexicographic order starting at the beginning of each
- block. Unlike `cmpstrM' the instruction can prefetch any bytes in
- the two memory blocks. Also unlike `cmpstrM' the comparison will
- not stop if both bytes are zero. The effect of the instruction is
- to store a value in operand 0 whose sign indicates the result of
- the comparison.
-
-`strlenM'
- Compute the length of a string, with three operands. Operand 0 is
- the result (of mode M), operand 1 is a `mem' referring to the
- first character of the string, operand 2 is the character to
- search for (normally zero), and operand 3 is a constant describing
- the known alignment of the beginning of the string.
-
-`floatMN2'
- Convert signed integer operand 1 (valid for fixed point mode M) to
- floating point mode N and store in operand 0 (which has mode N).
-
-`floatunsMN2'
- Convert unsigned integer operand 1 (valid for fixed point mode M)
- to floating point mode N and store in operand 0 (which has mode N).
-
-`fixMN2'
- Convert operand 1 (valid for floating point mode M) to fixed point
- mode N as a signed number and store in operand 0 (which has mode
- N). This instruction's result is defined only when the value of
- operand 1 is an integer.
-
- If the machine description defines this pattern, it also needs to
- define the `ftrunc' pattern.
-
-`fixunsMN2'
- Convert operand 1 (valid for floating point mode M) to fixed point
- mode N as an unsigned number and store in operand 0 (which has
- mode N). This instruction's result is defined only when the value
- of operand 1 is an integer.
-
-`ftruncM2'
- Convert operand 1 (valid for floating point mode M) to an integer
- value, still represented in floating point mode M, and store it in
- operand 0 (valid for floating point mode M).
-
-`fix_truncMN2'
- Like `fixMN2' but works for any floating point value of mode M by
- converting the value to an integer.
-
-`fixuns_truncMN2'
- Like `fixunsMN2' but works for any floating point value of mode M
- by converting the value to an integer.
-
-`truncMN2'
- Truncate operand 1 (valid for mode M) to mode N and store in
- operand 0 (which has mode N). Both modes must be fixed point or
- both floating point.
-
-`extendMN2'
- Sign-extend operand 1 (valid for mode M) to mode N and store in
- operand 0 (which has mode N). Both modes must be fixed point or
- both floating point.
-
-`zero_extendMN2'
- Zero-extend operand 1 (valid for mode M) to mode N and store in
- operand 0 (which has mode N). Both modes must be fixed point.
-
-`fractMN2'
- Convert operand 1 of mode M to mode N and store in operand 0
- (which has mode N). Mode M and mode N could be fixed-point to
- fixed-point, signed integer to fixed-point, fixed-point to signed
- integer, floating-point to fixed-point, or fixed-point to
- floating-point. When overflows or underflows happen, the results
- are undefined.
-
-`satfractMN2'
- Convert operand 1 of mode M to mode N and store in operand 0
- (which has mode N). Mode M and mode N could be fixed-point to
- fixed-point, signed integer to fixed-point, or floating-point to
- fixed-point. When overflows or underflows happen, the instruction
- saturates the results to the maximum or the minimum.
-
-`fractunsMN2'
- Convert operand 1 of mode M to mode N and store in operand 0
- (which has mode N). Mode M and mode N could be unsigned integer
- to fixed-point, or fixed-point to unsigned integer. When
- overflows or underflows happen, the results are undefined.
-
-`satfractunsMN2'
- Convert unsigned integer operand 1 of mode M to fixed-point mode N
- and store in operand 0 (which has mode N). When overflows or
- underflows happen, the instruction saturates the results to the
- maximum or the minimum.
-
-`extv'
- Extract a bit-field from operand 1 (a register or memory operand),
- where operand 2 specifies the width in bits and operand 3 the
- starting bit, and store it in operand 0. Operand 0 must have mode
- `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode';
- often `word_mode' is allowed only for registers. Operands 2 and 3
- must be valid for `word_mode'.
-
- The RTL generation pass generates this instruction only with
- constants for operands 2 and 3 and the constant is never zero for
- operand 2.
-
- The bit-field value is sign-extended to a full word integer before
- it is stored in operand 0.
-
-`extzv'
- Like `extv' except that the bit-field value is zero-extended.
-
-`insv'
- Store operand 3 (which must be valid for `word_mode') into a
- bit-field in operand 0, where operand 1 specifies the width in
- bits and operand 2 the starting bit. Operand 0 may have mode
- `byte_mode' or `word_mode'; often `word_mode' is allowed only for
- registers. Operands 1 and 2 must be valid for `word_mode'.
-
- The RTL generation pass generates this instruction only with
- constants for operands 1 and 2 and the constant is never zero for
- operand 1.
-
-`movMODEcc'
- Conditionally move operand 2 or operand 3 into operand 0 according
- to the comparison in operand 1. If the comparison is true,
- operand 2 is moved into operand 0, otherwise operand 3 is moved.
-
- The mode of the operands being compared need not be the same as
- the operands being moved. Some machines, sparc64 for example,
- have instructions that conditionally move an integer value based
- on the floating point condition codes and vice versa.
-
- If the machine does not have conditional move instructions, do not
- define these patterns.
-
-`addMODEcc'
- Similar to `movMODEcc' but for conditional addition. Conditionally
- move operand 2 or (operands 2 + operand 3) into operand 0
- according to the comparison in operand 1. If the comparison is
- true, operand 2 is moved into operand 0, otherwise (operand 2 +
- operand 3) is moved.
-
-`cstoreMODE4'
- Store zero or nonzero in operand 0 according to whether a
- comparison is true. Operand 1 is a comparison operator. Operand
- 2 and operand 3 are the first and second operand of the
- comparison, respectively. You specify the mode that operand 0
- must have when you write the `match_operand' expression. The
- compiler automatically sees which mode you have used and supplies
- an operand of that mode.
-
- The value stored for a true condition must have 1 as its low bit,
- or else must be negative. Otherwise the instruction is not
- suitable and you should omit it from the machine description. You
- describe to the compiler exactly which value is stored by defining
- the macro `STORE_FLAG_VALUE' (*note Misc::). If a description
- cannot be found that can be used for all the possible comparison
- operators, you should pick one and use a `define_expand' to map
- all results onto the one you chose.
-
- These operations may `FAIL', but should do so only in relatively
- uncommon cases; if they would `FAIL' for common cases involving
- integer comparisons, it is best to restrict the predicates to not
- allow these operands. Likewise if a given comparison operator will
- always fail, independent of the operands (for floating-point
- modes, the `ordered_comparison_operator' predicate is often useful
- in this case).
-
- If this pattern is omitted, the compiler will generate a
- conditional branch--for example, it may copy a constant one to the
- target and branching around an assignment of zero to the
- target--or a libcall. If the predicate for operand 1 only rejects
- some operators, it will also try reordering the operands and/or
- inverting the result value (e.g. by an exclusive OR). These
- possibilities could be cheaper or equivalent to the instructions
- used for the `cstoreMODE4' pattern followed by those required to
- convert a positive result from `STORE_FLAG_VALUE' to 1; in this
- case, you can and should make operand 1's predicate reject some
- operators in the `cstoreMODE4' pattern, or remove the pattern
- altogether from the machine description.
-
-`cbranchMODE4'
- Conditional branch instruction combined with a compare instruction.
- Operand 0 is a comparison operator. Operand 1 and operand 2 are
- the first and second operands of the comparison, respectively.
- Operand 3 is a `label_ref' that refers to the label to jump to.
-
-`jump'
- A jump inside a function; an unconditional branch. Operand 0 is
- the `label_ref' of the label to jump to. This pattern name is
- mandatory on all machines.
-
-`call'
- Subroutine call instruction returning no value. Operand 0 is the
- function to call; operand 1 is the number of bytes of arguments
- pushed as a `const_int'; operand 2 is the number of registers used
- as operands.
-
- On most machines, operand 2 is not actually stored into the RTL
- pattern. It is supplied for the sake of some RISC machines which
- need to put this information into the assembler code; they can put
- it in the RTL instead of operand 1.
-
- Operand 0 should be a `mem' RTX whose address is the address of the
- function. Note, however, that this address can be a `symbol_ref'
- expression even if it would not be a legitimate memory address on
- the target machine. If it is also not a valid argument for a call
- instruction, the pattern for this operation should be a
- `define_expand' (*note Expander Definitions::) that places the
- address into a register and uses that register in the call
- instruction.
-
-`call_value'
- Subroutine call instruction returning a value. Operand 0 is the
- hard register in which the value is returned. There are three more
- operands, the same as the three operands of the `call' instruction
- (but with numbers increased by one).
-
- Subroutines that return `BLKmode' objects use the `call' insn.
-
-`call_pop', `call_value_pop'
- Similar to `call' and `call_value', except used if defined and if
- `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that
- contains both the function call and a `set' to indicate the
- adjustment made to the frame pointer.
-
- For machines where `RETURN_POPS_ARGS' can be nonzero, the use of
- these patterns increases the number of functions for which the
- frame pointer can be eliminated, if desired.
-
-`untyped_call'
- Subroutine call instruction returning a value of any type.
- Operand 0 is the function to call; operand 1 is a memory location
- where the result of calling the function is to be stored; operand
- 2 is a `parallel' expression where each element is a `set'
- expression that indicates the saving of a function return value
- into the result block.
-
- This instruction pattern should be defined to support
- `__builtin_apply' on machines where special instructions are needed
- to call a subroutine with arbitrary arguments or to save the value
- returned. This instruction pattern is required on machines that
- have multiple registers that can hold a return value (i.e.
- `FUNCTION_VALUE_REGNO_P' is true for more than one register).
-
-`return'
- Subroutine return instruction. This instruction pattern name
- should be defined only if a single instruction can do all the work
- of returning from a function.
-
- Like the `movM' patterns, this pattern is also used after the RTL
- generation phase. In this case it is to support machines where
- multiple instructions are usually needed to return from a
- function, but some class of functions only requires one
- instruction to implement a return. Normally, the applicable
- functions are those which do not need to save any registers or
- allocate stack space.
-
- For such machines, the condition specified in this pattern should
- only be true when `reload_completed' is nonzero and the function's
- epilogue would only be a single instruction. For machines with
- register windows, the routine `leaf_function_p' may be used to
- determine if a register window push is required.
-
- Machines that have conditional return instructions should define
- patterns such as
-
- (define_insn ""
- [(set (pc)
- (if_then_else (match_operator
- 0 "comparison_operator"
- [(cc0) (const_int 0)])
- (return)
- (pc)))]
- "CONDITION"
- "...")
-
- where CONDITION would normally be the same condition specified on
- the named `return' pattern.
-
-`untyped_return'
- Untyped subroutine return instruction. This instruction pattern
- should be defined to support `__builtin_return' on machines where
- special instructions are needed to return a value of any type.
-
- Operand 0 is a memory location where the result of calling a
- function with `__builtin_apply' is stored; operand 1 is a
- `parallel' expression where each element is a `set' expression
- that indicates the restoring of a function return value from the
- result block.
-
-`nop'
- No-op instruction. This instruction pattern name should always be
- defined to output a no-op in assembler code. `(const_int 0)' will
- do as an RTL pattern.
-
-`indirect_jump'
- An instruction to jump to an address which is operand zero. This
- pattern name is mandatory on all machines.
-
-`casesi'
- Instruction to jump through a dispatch table, including bounds
- checking. This instruction takes five operands:
-
- 1. The index to dispatch on, which has mode `SImode'.
-
- 2. The lower bound for indices in the table, an integer constant.
-
- 3. The total range of indices in the table--the largest index
- minus the smallest one (both inclusive).
-
- 4. A label that precedes the table itself.
-
- 5. A label to jump to if the index has a value outside the
- bounds.
-
- The table is an `addr_vec' or `addr_diff_vec' inside of a
- `jump_insn'. The number of elements in the table is one plus the
- difference between the upper bound and the lower bound.
-
-`tablejump'
- Instruction to jump to a variable address. This is a low-level
- capability which can be used to implement a dispatch table when
- there is no `casesi' pattern.
-
- This pattern requires two operands: the address or offset, and a
- label which should immediately precede the jump table. If the
- macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then
- the first operand is an offset which counts from the address of
- the table; otherwise, it is an absolute address to jump to. In
- either case, the first operand has mode `Pmode'.
-
- The `tablejump' insn is always the last insn before the jump table
- it uses. Its assembler code normally has no need to use the
- second operand, but you should incorporate it in the RTL pattern so
- that the jump optimizer will not delete the table as unreachable
- code.
-
-`decrement_and_branch_until_zero'
- Conditional branch instruction that decrements a register and
- jumps if the register is nonzero. Operand 0 is the register to
- decrement and test; operand 1 is the label to jump to if the
- register is nonzero. *Note Looping Patterns::.
-
- This optional instruction pattern is only used by the combiner,
- typically for loops reversed by the loop optimizer when strength
- reduction is enabled.
-
-`doloop_end'
- Conditional branch instruction that decrements a register and
- jumps if the register is nonzero. This instruction takes five
- operands: Operand 0 is the register to decrement and test; operand
- 1 is the number of loop iterations as a `const_int' or
- `const0_rtx' if this cannot be determined until run-time; operand
- 2 is the actual or estimated maximum number of iterations as a
- `const_int'; operand 3 is the number of enclosed loops as a
- `const_int' (an innermost loop has a value of 1); operand 4 is the
- label to jump to if the register is nonzero. *Note Looping
- Patterns::.
-
- This optional instruction pattern should be defined for machines
- with low-overhead looping instructions as the loop optimizer will
- try to modify suitable loops to utilize it. If nested
- low-overhead looping is not supported, use a `define_expand'
- (*note Expander Definitions::) and make the pattern fail if
- operand 3 is not `const1_rtx'. Similarly, if the actual or
- estimated maximum number of iterations is too large for this
- instruction, make it fail.
-
-`doloop_begin'
- Companion instruction to `doloop_end' required for machines that
- need to perform some initialization, such as loading special
- registers used by a low-overhead looping instruction. If
- initialization insns do not always need to be emitted, use a
- `define_expand' (*note Expander Definitions::) and make it fail.
-
-`canonicalize_funcptr_for_compare'
- Canonicalize the function pointer in operand 1 and store the result
- into operand 0.
-
- Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be
- a `reg', `mem', `symbol_ref', `const_int', etc and also has mode
- `Pmode'.
-
- Canonicalization of a function pointer usually involves computing
- the address of the function which would be called if the function
- pointer were used in an indirect call.
-
- Only define this pattern if function pointers on the target machine
- can have different values but still call the same function when
- used in an indirect call.
-
-`save_stack_block'
-`save_stack_function'
-`save_stack_nonlocal'
-`restore_stack_block'
-`restore_stack_function'
-`restore_stack_nonlocal'
- Most machines save and restore the stack pointer by copying it to
- or from an object of mode `Pmode'. Do not define these patterns on
- such machines.
-
- Some machines require special handling for stack pointer saves and
- restores. On those machines, define the patterns corresponding to
- the non-standard cases by using a `define_expand' (*note Expander
- Definitions::) that produces the required insns. The three types
- of saves and restores are:
-
- 1. `save_stack_block' saves the stack pointer at the start of a
- block that allocates a variable-sized object, and
- `restore_stack_block' restores the stack pointer when the
- block is exited.
-
- 2. `save_stack_function' and `restore_stack_function' do a
- similar job for the outermost block of a function and are
- used when the function allocates variable-sized objects or
- calls `alloca'. Only the epilogue uses the restored stack
- pointer, allowing a simpler save or restore sequence on some
- machines.
-
- 3. `save_stack_nonlocal' is used in functions that contain labels
- branched to by nested functions. It saves the stack pointer
- in such a way that the inner function can use
- `restore_stack_nonlocal' to restore the stack pointer. The
- compiler generates code to restore the frame and argument
- pointer registers, but some machines require saving and
- restoring additional data such as register window information
- or stack backchains. Place insns in these patterns to save
- and restore any such required data.
-
- When saving the stack pointer, operand 0 is the save area and
- operand 1 is the stack pointer. The mode used to allocate the
- save area defaults to `Pmode' but you can override that choice by
- defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::).
- You must specify an integral mode, or `VOIDmode' if no save area
- is needed for a particular type of save (either because no save is
- needed or because a machine-specific save area can be used).
- Operand 0 is the stack pointer and operand 1 is the save area for
- restore operations. If `save_stack_block' is defined, operand 0
- must not be `VOIDmode' since these saves can be arbitrarily nested.
-
- A save area is a `mem' that is at a constant offset from
- `virtual_stack_vars_rtx' when the stack pointer is saved for use by
- nonlocal gotos and a `reg' in the other two cases.
-
-`allocate_stack'
- Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1
- from the stack pointer to create space for dynamically allocated
- data.
-
- Store the resultant pointer to this space into operand 0. If you
- are allocating space from the main stack, do this by emitting a
- move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If
- you are allocating the space elsewhere, generate code to copy the
- location of the space to operand 0. In the latter case, you must
- ensure this space gets freed when the corresponding space on the
- main stack is free.
-
- Do not define this pattern if all that must be done is the
- subtraction. Some machines require other operations such as stack
- probes or maintaining the back chain. Define this pattern to emit
- those operations in addition to updating the stack pointer.
-
-`check_stack'
- If stack checking (*note Stack Checking::) cannot be done on your
- system by probing the stack, define this pattern to perform the
- needed check and signal an error if the stack has overflowed. The
- single operand is the address in the stack farthest from the
- current stack pointer that you need to validate. Normally, on
- platforms where this pattern is needed, you would obtain the stack
- limit from a global or thread-specific variable or register.
-
-`probe_stack'
- If stack checking (*note Stack Checking::) can be done on your
- system by probing the stack but doing it with a "store zero"
- instruction is not valid or optimal, define this pattern to do the
- probing differently and signal an error if the stack has
- overflowed. The single operand is the memory reference in the
- stack that needs to be probed.
-
-`nonlocal_goto'
- Emit code to generate a non-local goto, e.g., a jump from one
- function to a label in an outer function. This pattern has four
- arguments, each representing a value to be used in the jump. The
- first argument is to be loaded into the frame pointer, the second
- is the address to branch to (code to dispatch to the actual label),
- the third is the address of a location where the stack is saved,
- and the last is the address of the label, to be placed in the
- location for the incoming static chain.
-
- On most machines you need not define this pattern, since GCC will
- already generate the correct code, which is to load the frame
- pointer and static chain, restore the stack (using the
- `restore_stack_nonlocal' pattern, if defined), and jump indirectly
- to the dispatcher. You need only define this pattern if this code
- will not work on your machine.
-
-`nonlocal_goto_receiver'
- This pattern, if defined, contains code needed at the target of a
- nonlocal goto after the code already generated by GCC. You will
- not normally need to define this pattern. A typical reason why
- you might need this pattern is if some value, such as a pointer to
- a global table, must be restored when the frame pointer is
- restored. Note that a nonlocal goto only occurs within a
- unit-of-translation, so a global table pointer that is shared by
- all functions of a given module need not be restored. There are
- no arguments.
-
-`exception_receiver'
- This pattern, if defined, contains code needed at the site of an
- exception handler that isn't needed at the site of a nonlocal
- goto. You will not normally need to define this pattern. A
- typical reason why you might need this pattern is if some value,
- such as a pointer to a global table, must be restored after
- control flow is branched to the handler of an exception. There
- are no arguments.
-
-`builtin_setjmp_setup'
- This pattern, if defined, contains additional code needed to
- initialize the `jmp_buf'. You will not normally need to define
- this pattern. A typical reason why you might need this pattern is
- if some value, such as a pointer to a global table, must be
- restored. Though it is preferred that the pointer value be
- recalculated if possible (given the address of a label for
- instance). The single argument is a pointer to the `jmp_buf'.
- Note that the buffer is five words long and that the first three
- are normally used by the generic mechanism.
-
-`builtin_setjmp_receiver'
- This pattern, if defined, contains code needed at the site of a
- built-in setjmp that isn't needed at the site of a nonlocal goto.
- You will not normally need to define this pattern. A typical
- reason why you might need this pattern is if some value, such as a
- pointer to a global table, must be restored. It takes one
- argument, which is the label to which builtin_longjmp transfered
- control; this pattern may be emitted at a small offset from that
- label.
-
-`builtin_longjmp'
- This pattern, if defined, performs the entire action of the
- longjmp. You will not normally need to define this pattern unless
- you also define `builtin_setjmp_setup'. The single argument is a
- pointer to the `jmp_buf'.
-
-`eh_return'
- This pattern, if defined, affects the way `__builtin_eh_return',
- and thence the call frame exception handling library routines, are
- built. It is intended to handle non-trivial actions needed along
- the abnormal return path.
-
- The address of the exception handler to which the function should
- return is passed as operand to this pattern. It will normally
- need to copied by the pattern to some special register or memory
- location. If the pattern needs to determine the location of the
- target call frame in order to do so, it may use
- `EH_RETURN_STACKADJ_RTX', if defined; it will have already been
- assigned.
-
- If this pattern is not defined, the default action will be to
- simply copy the return address to `EH_RETURN_HANDLER_RTX'. Either
- that macro or this pattern needs to be defined if call frame
- exception handling is to be used.
-
-`prologue'
- This pattern, if defined, emits RTL for entry to a function. The
- function entry is responsible for setting up the stack frame,
- initializing the frame pointer register, saving callee saved
- registers, etc.
-
- Using a prologue pattern is generally preferred over defining
- `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the
- prologue.
-
- The `prologue' pattern is particularly useful for targets which
- perform instruction scheduling.
-
-`epilogue'
- This pattern emits RTL for exit from a function. The function
- exit is responsible for deallocating the stack frame, restoring
- callee saved registers and emitting the return instruction.
-
- Using an epilogue pattern is generally preferred over defining
- `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the
- epilogue.
-
- The `epilogue' pattern is particularly useful for targets which
- perform instruction scheduling or which have delay slots for their
- return instruction.
-
-`sibcall_epilogue'
- This pattern, if defined, emits RTL for exit from a function
- without the final branch back to the calling function. This
- pattern will be emitted before any sibling call (aka tail call)
- sites.
-
- The `sibcall_epilogue' pattern must not clobber any arguments used
- for parameter passing or any stack slots for arguments passed to
- the current function.
-
-`trap'
- This pattern, if defined, signals an error, typically by causing
- some kind of signal to be raised. Among other places, it is used
- by the Java front end to signal `invalid array index' exceptions.
-
-`ctrapMM4'
- Conditional trap instruction. Operand 0 is a piece of RTL which
- performs a comparison, and operands 1 and 2 are the arms of the
- comparison. Operand 3 is the trap code, an integer.
-
- A typical `ctrap' pattern looks like
-
- (define_insn "ctrapsi4"
- [(trap_if (match_operator 0 "trap_operator"
- [(match_operand 1 "register_operand")
- (match_operand 2 "immediate_operand")])
- (match_operand 3 "const_int_operand" "i"))]
- ""
- "...")
-
-`prefetch'
- This pattern, if defined, emits code for a non-faulting data
- prefetch instruction. Operand 0 is the address of the memory to
- prefetch. Operand 1 is a constant 1 if the prefetch is preparing
- for a write to the memory address, or a constant 0 otherwise.
- Operand 2 is the expected degree of temporal locality of the data
- and is a value between 0 and 3, inclusive; 0 means that the data
- has no temporal locality, so it need not be left in the cache
- after the access; 3 means that the data has a high degree of
- temporal locality and should be left in all levels of cache
- possible; 1 and 2 mean, respectively, a low or moderate degree of
- temporal locality.
-
- Targets that do not support write prefetches or locality hints can
- ignore the values of operands 1 and 2.
-
-`blockage'
- This pattern defines a pseudo insn that prevents the instruction
- scheduler from moving instructions across the boundary defined by
- the blockage insn. Normally an UNSPEC_VOLATILE pattern.
-
-`memory_barrier'
- If the target memory model is not fully synchronous, then this
- pattern should be defined to an instruction that orders both loads
- and stores before the instruction with respect to loads and stores
- after the instruction. This pattern has no operands.
-
-`sync_compare_and_swapMODE'
- This pattern, if defined, emits code for an atomic compare-and-swap
- operation. Operand 1 is the memory on which the atomic operation
- is performed. Operand 2 is the "old" value to be compared against
- the current contents of the memory location. Operand 3 is the
- "new" value to store in the memory if the compare succeeds.
- Operand 0 is the result of the operation; it should contain the
- contents of the memory before the operation. If the compare
- succeeds, this should obviously be a copy of operand 2.
-
- This pattern must show that both operand 0 and operand 1 are
- modified.
-
- This pattern must issue any memory barrier instructions such that
- all memory operations before the atomic operation occur before the
- atomic operation and all memory operations after the atomic
- operation occur after the atomic operation.
-
- For targets where the success or failure of the compare-and-swap
- operation is available via the status flags, it is possible to
- avoid a separate compare operation and issue the subsequent branch
- or store-flag operation immediately after the compare-and-swap.
- To this end, GCC will look for a `MODE_CC' set in the output of
- `sync_compare_and_swapMODE'; if the machine description includes
- such a set, the target should also define special `cbranchcc4'
- and/or `cstorecc4' instructions. GCC will then be able to take
- the destination of the `MODE_CC' set and pass it to the
- `cbranchcc4' or `cstorecc4' pattern as the first operand of the
- comparison (the second will be `(const_int 0)').
-
-`sync_addMODE', `sync_subMODE'
-`sync_iorMODE', `sync_andMODE'
-`sync_xorMODE', `sync_nandMODE'
- These patterns emit code for an atomic operation on memory.
- Operand 0 is the memory on which the atomic operation is performed.
- Operand 1 is the second operand to the binary operator.
-
- This pattern must issue any memory barrier instructions such that
- all memory operations before the atomic operation occur before the
- atomic operation and all memory operations after the atomic
- operation occur after the atomic operation.
-
- If these patterns are not defined, the operation will be
- constructed from a compare-and-swap operation, if defined.
-
-`sync_old_addMODE', `sync_old_subMODE'
-`sync_old_iorMODE', `sync_old_andMODE'
-`sync_old_xorMODE', `sync_old_nandMODE'
- These patterns are emit code for an atomic operation on memory,
- and return the value that the memory contained before the
- operation. Operand 0 is the result value, operand 1 is the memory
- on which the atomic operation is performed, and operand 2 is the
- second operand to the binary operator.
-
- This pattern must issue any memory barrier instructions such that
- all memory operations before the atomic operation occur before the
- atomic operation and all memory operations after the atomic
- operation occur after the atomic operation.
-
- If these patterns are not defined, the operation will be
- constructed from a compare-and-swap operation, if defined.
-
-`sync_new_addMODE', `sync_new_subMODE'
-`sync_new_iorMODE', `sync_new_andMODE'
-`sync_new_xorMODE', `sync_new_nandMODE'
- These patterns are like their `sync_old_OP' counterparts, except
- that they return the value that exists in the memory location
- after the operation, rather than before the operation.
-
-`sync_lock_test_and_setMODE'
- This pattern takes two forms, based on the capabilities of the
- target. In either case, operand 0 is the result of the operand,
- operand 1 is the memory on which the atomic operation is
- performed, and operand 2 is the value to set in the lock.
-
- In the ideal case, this operation is an atomic exchange operation,
- in which the previous value in memory operand is copied into the
- result operand, and the value operand is stored in the memory
- operand.
-
- For less capable targets, any value operand that is not the
- constant 1 should be rejected with `FAIL'. In this case the
- target may use an atomic test-and-set bit operation. The result
- operand should contain 1 if the bit was previously set and 0 if
- the bit was previously clear. The true contents of the memory
- operand are implementation defined.
-
- This pattern must issue any memory barrier instructions such that
- the pattern as a whole acts as an acquire barrier, that is all
- memory operations after the pattern do not occur until the lock is
- acquired.
-
- If this pattern is not defined, the operation will be constructed
- from a compare-and-swap operation, if defined.
-
-`sync_lock_releaseMODE'
- This pattern, if defined, releases a lock set by
- `sync_lock_test_and_setMODE'. Operand 0 is the memory that
- contains the lock; operand 1 is the value to store in the lock.
-
- If the target doesn't implement full semantics for
- `sync_lock_test_and_setMODE', any value operand which is not the
- constant 0 should be rejected with `FAIL', and the true contents
- of the memory operand are implementation defined.
-
- This pattern must issue any memory barrier instructions such that
- the pattern as a whole acts as a release barrier, that is the lock
- is released only after all previous memory operations have
- completed.
-
- If this pattern is not defined, then a `memory_barrier' pattern
- will be emitted, followed by a store of the value to the memory
- operand.
-
-`stack_protect_set'
- This pattern, if defined, moves a `ptr_mode' value from the memory
- in operand 1 to the memory in operand 0 without leaving the value
- in a register afterward. This is to avoid leaking the value some
- place that an attacker might use to rewrite the stack guard slot
- after having clobbered it.
-
- If this pattern is not defined, then a plain move pattern is
- generated.
-
-`stack_protect_test'
- This pattern, if defined, compares a `ptr_mode' value from the
- memory in operand 1 with the memory in operand 0 without leaving
- the value in a register afterward and branches to operand 2 if the
- values weren't equal.
-
- If this pattern is not defined, then a plain compare pattern and
- conditional branch pattern is used.
-
-`clear_cache'
- This pattern, if defined, flushes the instruction cache for a
- region of memory. The region is bounded to by the Pmode pointers
- in operand 0 inclusive and operand 1 exclusive.
-
- If this pattern is not defined, a call to the library function
- `__clear_cache' is used.
-
-
-
-File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc
-
-16.10 When the Order of Patterns Matters
-========================================
-
-Sometimes an insn can match more than one instruction pattern. Then the
-pattern that appears first in the machine description is the one used.
-Therefore, more specific patterns (patterns that will match fewer
-things) and faster instructions (those that will produce better code
-when they do match) should usually go first in the description.
-
- In some cases the effect of ordering the patterns can be used to hide
-a pattern when it is not valid. For example, the 68000 has an
-instruction for converting a fullword to floating point and another for
-converting a byte to floating point. An instruction converting an
-integer to floating point could match either one. We put the pattern
-to convert the fullword first to make sure that one will be used rather
-than the other. (Otherwise a large integer might be generated as a
-single-byte immediate quantity, which would not work.) Instead of
-using this pattern ordering it would be possible to make the pattern
-for convert-a-byte smart enough to deal properly with any constant
-value.
-
-
-File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc
-
-16.11 Interdependence of Patterns
-=================================
-
-In some cases machines support instructions identical except for the
-machine mode of one or more operands. For example, there may be
-"sign-extend halfword" and "sign-extend byte" instructions whose
-patterns are
-
- (set (match_operand:SI 0 ...)
- (extend:SI (match_operand:HI 1 ...)))
-
- (set (match_operand:SI 0 ...)
- (extend:SI (match_operand:QI 1 ...)))
-
-Constant integers do not specify a machine mode, so an instruction to
-extend a constant value could match either pattern. The pattern it
-actually will match is the one that appears first in the file. For
-correct results, this must be the one for the widest possible mode
-(`HImode', here). If the pattern matches the `QImode' instruction, the
-results will be incorrect if the constant value does not actually fit
-that mode.
-
- Such instructions to extend constants are rarely generated because
-they are optimized away, but they do occasionally happen in nonoptimized
-compilations.
-
- If a constraint in a pattern allows a constant, the reload pass may
-replace a register with a constant permitted by the constraint in some
-cases. Similarly for memory references. Because of this substitution,
-you should not provide separate patterns for increment and decrement
-instructions. Instead, they should be generated from the same pattern
-that supports register-register add insns by examining the operands and
-generating the appropriate machine instruction.
-
-
-File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc
-
-16.12 Defining Jump Instruction Patterns
-========================================
-
-GCC does not assume anything about how the machine realizes jumps. The
-machine description should define a single pattern, usually a
-`define_expand', which expands to all the required insns.
-
- Usually, this would be a comparison insn to set the condition code and
-a separate branch insn testing the condition code and branching or not
-according to its value. For many machines, however, separating
-compares and branches is limiting, which is why the more flexible
-approach with one `define_expand' is used in GCC. The machine
-description becomes clearer for architectures that have
-compare-and-branch instructions but no condition code. It also works
-better when different sets of comparison operators are supported by
-different kinds of conditional branches (e.g. integer vs.
-floating-point), or by conditional branches with respect to conditional
-stores.
-
- Two separate insns are always used if the machine description
-represents a condition code register using the legacy RTL expression
-`(cc0)', and on most machines that use a separate condition code
-register (*note Condition Code::). For machines that use `(cc0)', in
-fact, the set and use of the condition code must be separate and
-adjacent(1), thus allowing flags in `cc_status' to be used (*note
-Condition Code::) and so that the comparison and branch insns could be
-located from each other by using the functions `prev_cc0_setter' and
-`next_cc0_user'.
-
- Even in this case having a single entry point for conditional branches
-is advantageous, because it handles equally well the case where a single
-comparison instruction records the results of both signed and unsigned
-comparison of the given operands (with the branch insns coming in
-distinct signed and unsigned flavors) as in the x86 or SPARC, and the
-case where there are distinct signed and unsigned compare instructions
-and only one set of conditional branch instructions as in the PowerPC.
-
- ---------- Footnotes ----------
-
- (1) `note' insns can separate them, though.
-
-
-File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc
-
-16.13 Defining Looping Instruction Patterns
-===========================================
-
-Some machines have special jump instructions that can be utilized to
-make loops more efficient. A common example is the 68000 `dbra'
-instruction which performs a decrement of a register and a branch if the
-result was greater than zero. Other machines, in particular digital
-signal processors (DSPs), have special block repeat instructions to
-provide low-overhead loop support. For example, the TI TMS320C3x/C4x
-DSPs have a block repeat instruction that loads special registers to
-mark the top and end of a loop and to count the number of loop
-iterations. This avoids the need for fetching and executing a
-`dbra'-like instruction and avoids pipeline stalls associated with the
-jump.
-
- GCC has three special named patterns to support low overhead looping.
-They are `decrement_and_branch_until_zero', `doloop_begin', and
-`doloop_end'. The first pattern, `decrement_and_branch_until_zero', is
-not emitted during RTL generation but may be emitted during the
-instruction combination phase. This requires the assistance of the
-loop optimizer, using information collected during strength reduction,
-to reverse a loop to count down to zero. Some targets also require the
-loop optimizer to add a `REG_NONNEG' note to indicate that the
-iteration count is always positive. This is needed if the target
-performs a signed loop termination test. For example, the 68000 uses a
-pattern similar to the following for its `dbra' instruction:
-
- (define_insn "decrement_and_branch_until_zero"
- [(set (pc)
- (if_then_else
- (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am")
- (const_int -1))
- (const_int 0))
- (label_ref (match_operand 1 "" ""))
- (pc)))
- (set (match_dup 0)
- (plus:SI (match_dup 0)
- (const_int -1)))]
- "find_reg_note (insn, REG_NONNEG, 0)"
- "...")
-
- Note that since the insn is both a jump insn and has an output, it must
-deal with its own reloads, hence the `m' constraints. Also note that
-since this insn is generated by the instruction combination phase
-combining two sequential insns together into an implicit parallel insn,
-the iteration counter needs to be biased by the same amount as the
-decrement operation, in this case -1. Note that the following similar
-pattern will not be matched by the combiner.
-
- (define_insn "decrement_and_branch_until_zero"
- [(set (pc)
- (if_then_else
- (ge (match_operand:SI 0 "general_operand" "+d*am")
- (const_int 1))
- (label_ref (match_operand 1 "" ""))
- (pc)))
- (set (match_dup 0)
- (plus:SI (match_dup 0)
- (const_int -1)))]
- "find_reg_note (insn, REG_NONNEG, 0)"
- "...")
-
- The other two special looping patterns, `doloop_begin' and
-`doloop_end', are emitted by the loop optimizer for certain
-well-behaved loops with a finite number of loop iterations using
-information collected during strength reduction.
-
- The `doloop_end' pattern describes the actual looping instruction (or
-the implicit looping operation) and the `doloop_begin' pattern is an
-optional companion pattern that can be used for initialization needed
-for some low-overhead looping instructions.
-
- Note that some machines require the actual looping instruction to be
-emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting
-the true RTL for a looping instruction at the top of the loop can cause
-problems with flow analysis. So instead, a dummy `doloop' insn is
-emitted at the end of the loop. The machine dependent reorg pass checks
-for the presence of this `doloop' insn and then searches back to the
-top of the loop, where it inserts the true looping insn (provided there
-are no instructions in the loop which would cause problems). Any
-additional labels can be emitted at this point. In addition, if the
-desired special iteration counter register was not allocated, this
-machine dependent reorg pass could emit a traditional compare and jump
-instruction pair.
-
- The essential difference between the `decrement_and_branch_until_zero'
-and the `doloop_end' patterns is that the loop optimizer allocates an
-additional pseudo register for the latter as an iteration counter.
-This pseudo register cannot be used within the loop (i.e., general
-induction variables cannot be derived from it), however, in many cases
-the loop induction variable may become redundant and removed by the
-flow pass.
-
-
-File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc
-
-16.14 Canonicalization of Instructions
-======================================
-
-There are often cases where multiple RTL expressions could represent an
-operation performed by a single machine instruction. This situation is
-most commonly encountered with logical, branch, and multiply-accumulate
-instructions. In such cases, the compiler attempts to convert these
-multiple RTL expressions into a single canonical form to reduce the
-number of insn patterns required.
-
- In addition to algebraic simplifications, following canonicalizations
-are performed:
-
- * For commutative and comparison operators, a constant is always
- made the second operand. If a machine only supports a constant as
- the second operand, only patterns that match a constant in the
- second operand need be supplied.
-
- * For associative operators, a sequence of operators will always
- chain to the left; for instance, only the left operand of an
- integer `plus' can itself be a `plus'. `and', `ior', `xor',
- `plus', `mult', `smin', `smax', `umin', and `umax' are associative
- when applied to integers, and sometimes to floating-point.
-
- * For these operators, if only one operand is a `neg', `not',
- `mult', `plus', or `minus' expression, it will be the first
- operand.
-
- * In combinations of `neg', `mult', `plus', and `minus', the `neg'
- operations (if any) will be moved inside the operations as far as
- possible. For instance, `(neg (mult A B))' is canonicalized as
- `(mult (neg A) B)', but `(plus (mult (neg B) C) A)' is
- canonicalized as `(minus A (mult B C))'.
-
- * For the `compare' operator, a constant is always the second operand
- if the first argument is a condition code register or `(cc0)'.
-
- * An operand of `neg', `not', `mult', `plus', or `minus' is made the
- first operand under the same conditions as above.
-
- * `(ltu (plus A B) B)' is converted to `(ltu (plus A B) A)'.
- Likewise with `geu' instead of `ltu'.
-
- * `(minus X (const_int N))' is converted to `(plus X (const_int
- -N))'.
-
- * Within address computations (i.e., inside `mem'), a left shift is
- converted into the appropriate multiplication by a power of two.
-
- * De Morgan's Law is used to move bitwise negation inside a bitwise
- logical-and or logical-or operation. If this results in only one
- operand being a `not' expression, it will be the first one.
-
- A machine that has an instruction that performs a bitwise
- logical-and of one operand with the bitwise negation of the other
- should specify the pattern for that instruction as
-
- (define_insn ""
- [(set (match_operand:M 0 ...)
- (and:M (not:M (match_operand:M 1 ...))
- (match_operand:M 2 ...)))]
- "..."
- "...")
-
- Similarly, a pattern for a "NAND" instruction should be written
-
- (define_insn ""
- [(set (match_operand:M 0 ...)
- (ior:M (not:M (match_operand:M 1 ...))
- (not:M (match_operand:M 2 ...))))]
- "..."
- "...")
-
- In both cases, it is not necessary to include patterns for the many
- logically equivalent RTL expressions.
-
- * The only possible RTL expressions involving both bitwise
- exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M
- (xor:M X Y))'.
-
- * The sum of three items, one of which is a constant, will only
- appear in the form
-
- (plus:M (plus:M X Y) CONSTANT)
-
- * Equality comparisons of a group of bits (usually a single bit)
- with zero will be written using `zero_extract' rather than the
- equivalent `and' or `sign_extract' operations.
-
-
- Further canonicalization rules are defined in the function
-`commutative_operand_precedence' in `gcc/rtlanal.c'.
-
-
-File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc
-
-16.15 Defining RTL Sequences for Code Generation
-================================================
-
-On some target machines, some standard pattern names for RTL generation
-cannot be handled with single insn, but a sequence of RTL insns can
-represent them. For these target machines, you can write a
-`define_expand' to specify how to generate the sequence of RTL.
-
- A `define_expand' is an RTL expression that looks almost like a
-`define_insn'; but, unlike the latter, a `define_expand' is used only
-for RTL generation and it can produce more than one RTL insn.
-
- A `define_expand' RTX has four operands:
-
- * The name. Each `define_expand' must have a name, since the only
- use for it is to refer to it by name.
-
- * The RTL template. This is a vector of RTL expressions representing
- a sequence of separate instructions. Unlike `define_insn', there
- is no implicit surrounding `PARALLEL'.
-
- * The condition, a string containing a C expression. This
- expression is used to express how the availability of this pattern
- depends on subclasses of target machine, selected by command-line
- options when GCC is run. This is just like the condition of a
- `define_insn' that has a standard name. Therefore, the condition
- (if present) may not depend on the data in the insn being matched,
- but only the target-machine-type flags. The compiler needs to
- test these conditions during initialization in order to learn
- exactly which named instructions are available in a particular run.
-
- * The preparation statements, a string containing zero or more C
- statements which are to be executed before RTL code is generated
- from the RTL template.
-
- Usually these statements prepare temporary registers for use as
- internal operands in the RTL template, but they can also generate
- RTL insns directly by calling routines such as `emit_insn', etc.
- Any such insns precede the ones that come from the RTL template.
-
- Every RTL insn emitted by a `define_expand' must match some
-`define_insn' in the machine description. Otherwise, the compiler will
-crash when trying to generate code for the insn or trying to optimize
-it.
-
- The RTL template, in addition to controlling generation of RTL insns,
-also describes the operands that need to be specified when this pattern
-is used. In particular, it gives a predicate for each operand.
-
- A true operand, which needs to be specified in order to generate RTL
-from the pattern, should be described with a `match_operand' in its
-first occurrence in the RTL template. This enters information on the
-operand's predicate into the tables that record such things. GCC uses
-the information to preload the operand into a register if that is
-required for valid RTL code. If the operand is referred to more than
-once, subsequent references should use `match_dup'.
-
- The RTL template may also refer to internal "operands" which are
-temporary registers or labels used only within the sequence made by the
-`define_expand'. Internal operands are substituted into the RTL
-template with `match_dup', never with `match_operand'. The values of
-the internal operands are not passed in as arguments by the compiler
-when it requests use of this pattern. Instead, they are computed
-within the pattern, in the preparation statements. These statements
-compute the values and store them into the appropriate elements of
-`operands' so that `match_dup' can find them.
-
- There are two special macros defined for use in the preparation
-statements: `DONE' and `FAIL'. Use them with a following semicolon, as
-a statement.
-
-`DONE'
- Use the `DONE' macro to end RTL generation for the pattern. The
- only RTL insns resulting from the pattern on this occasion will be
- those already emitted by explicit calls to `emit_insn' within the
- preparation statements; the RTL template will not be generated.
-
-`FAIL'
- Make the pattern fail on this occasion. When a pattern fails, it
- means that the pattern was not truly available. The calling
- routines in the compiler will try other strategies for code
- generation using other patterns.
-
- Failure is currently supported only for binary (addition,
- multiplication, shifting, etc.) and bit-field (`extv', `extzv',
- and `insv') operations.
-
- If the preparation falls through (invokes neither `DONE' nor `FAIL'),
-then the `define_expand' acts like a `define_insn' in that the RTL
-template is used to generate the insn.
-
- The RTL template is not used for matching, only for generating the
-initial insn list. If the preparation statement always invokes `DONE'
-or `FAIL', the RTL template may be reduced to a simple list of
-operands, such as this example:
-
- (define_expand "addsi3"
- [(match_operand:SI 0 "register_operand" "")
- (match_operand:SI 1 "register_operand" "")
- (match_operand:SI 2 "register_operand" "")]
- ""
- "
- {
- handle_add (operands[0], operands[1], operands[2]);
- DONE;
- }")
-
- Here is an example, the definition of left-shift for the SPUR chip:
-
- (define_expand "ashlsi3"
- [(set (match_operand:SI 0 "register_operand" "")
- (ashift:SI
- (match_operand:SI 1 "register_operand" "")
- (match_operand:SI 2 "nonmemory_operand" "")))]
- ""
- "
-
- {
- if (GET_CODE (operands[2]) != CONST_INT
- || (unsigned) INTVAL (operands[2]) > 3)
- FAIL;
- }")
-
-This example uses `define_expand' so that it can generate an RTL insn
-for shifting when the shift-count is in the supported range of 0 to 3
-but fail in other cases where machine insns aren't available. When it
-fails, the compiler tries another strategy using different patterns
-(such as, a library call).
-
- If the compiler were able to handle nontrivial condition-strings in
-patterns with names, then it would be possible to use a `define_insn'
-in that case. Here is another case (zero-extension on the 68000) which
-makes more use of the power of `define_expand':
-
- (define_expand "zero_extendhisi2"
- [(set (match_operand:SI 0 "general_operand" "")
- (const_int 0))
- (set (strict_low_part
- (subreg:HI
- (match_dup 0)
- 0))
- (match_operand:HI 1 "general_operand" ""))]
- ""
- "operands[1] = make_safe_from (operands[1], operands[0]);")
-
-Here two RTL insns are generated, one to clear the entire output operand
-and the other to copy the input operand into its low half. This
-sequence is incorrect if the input operand refers to [the old value of]
-the output operand, so the preparation statement makes sure this isn't
-so. The function `make_safe_from' copies the `operands[1]' into a
-temporary register if it refers to `operands[0]'. It does this by
-emitting another RTL insn.
-
- Finally, a third example shows the use of an internal operand.
-Zero-extension on the SPUR chip is done by `and'-ing the result against
-a halfword mask. But this mask cannot be represented by a `const_int'
-because the constant value is too large to be legitimate on this
-machine. So it must be copied into a register with `force_reg' and
-then the register used in the `and'.
-
- (define_expand "zero_extendhisi2"
- [(set (match_operand:SI 0 "register_operand" "")
- (and:SI (subreg:SI
- (match_operand:HI 1 "register_operand" "")
- 0)
- (match_dup 2)))]
- ""
- "operands[2]
- = force_reg (SImode, GEN_INT (65535)); ")
-
- _Note:_ If the `define_expand' is used to serve a standard binary or
-unary arithmetic operation or a bit-field operation, then the last insn
-it generates must not be a `code_label', `barrier' or `note'. It must
-be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn
-at the end, emit an insn to copy the result of the operation into
-itself. Such an insn will generate no code, but it can avoid problems
-in the compiler.
-
-
-File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc
-
-16.16 Defining How to Split Instructions
-========================================
-
-There are two cases where you should specify how to split a pattern
-into multiple insns. On machines that have instructions requiring
-delay slots (*note Delay Slots::) or that have instructions whose
-output is not available for multiple cycles (*note Processor pipeline
-description::), the compiler phases that optimize these cases need to
-be able to move insns into one-instruction delay slots. However, some
-insns may generate more than one machine instruction. These insns
-cannot be placed into a delay slot.
-
- Often you can rewrite the single insn as a list of individual insns,
-each corresponding to one machine instruction. The disadvantage of
-doing so is that it will cause the compilation to be slower and require
-more space. If the resulting insns are too complex, it may also
-suppress some optimizations. The compiler splits the insn if there is a
-reason to believe that it might improve instruction or delay slot
-scheduling.
-
- The insn combiner phase also splits putative insns. If three insns are
-merged into one insn with a complex expression that cannot be matched by
-some `define_insn' pattern, the combiner phase attempts to split the
-complex pattern into two insns that are recognized. Usually it can
-break the complex pattern into two patterns by splitting out some
-subexpression. However, in some other cases, such as performing an
-addition of a large constant in two insns on a RISC machine, the way to
-split the addition into two insns is machine-dependent.
-
- The `define_split' definition tells the compiler how to split a
-complex insn into several simpler insns. It looks like this:
-
- (define_split
- [INSN-PATTERN]
- "CONDITION"
- [NEW-INSN-PATTERN-1
- NEW-INSN-PATTERN-2
- ...]
- "PREPARATION-STATEMENTS")
-
- INSN-PATTERN is a pattern that needs to be split and CONDITION is the
-final condition to be tested, as in a `define_insn'. When an insn
-matching INSN-PATTERN and satisfying CONDITION is found, it is replaced
-in the insn list with the insns given by NEW-INSN-PATTERN-1,
-NEW-INSN-PATTERN-2, etc.
-
- The PREPARATION-STATEMENTS are similar to those statements that are
-specified for `define_expand' (*note Expander Definitions::) and are
-executed before the new RTL is generated to prepare for the generated
-code or emit some insns whose pattern is not fixed. Unlike those in
-`define_expand', however, these statements must not generate any new
-pseudo-registers. Once reload has completed, they also must not
-allocate any space in the stack frame.
-
- Patterns are matched against INSN-PATTERN in two different
-circumstances. If an insn needs to be split for delay slot scheduling
-or insn scheduling, the insn is already known to be valid, which means
-that it must have been matched by some `define_insn' and, if
-`reload_completed' is nonzero, is known to satisfy the constraints of
-that `define_insn'. In that case, the new insn patterns must also be
-insns that are matched by some `define_insn' and, if `reload_completed'
-is nonzero, must also satisfy the constraints of those definitions.
-
- As an example of this usage of `define_split', consider the following
-example from `a29k.md', which splits a `sign_extend' from `HImode' to
-`SImode' into a pair of shift insns:
-
- (define_split
- [(set (match_operand:SI 0 "gen_reg_operand" "")
- (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))]
- ""
- [(set (match_dup 0)
- (ashift:SI (match_dup 1)
- (const_int 16)))
- (set (match_dup 0)
- (ashiftrt:SI (match_dup 0)
- (const_int 16)))]
- "
- { operands[1] = gen_lowpart (SImode, operands[1]); }")
-
- When the combiner phase tries to split an insn pattern, it is always
-the case that the pattern is _not_ matched by any `define_insn'. The
-combiner pass first tries to split a single `set' expression and then
-the same `set' expression inside a `parallel', but followed by a
-`clobber' of a pseudo-reg to use as a scratch register. In these
-cases, the combiner expects exactly two new insn patterns to be
-generated. It will verify that these patterns match some `define_insn'
-definitions, so you need not do this test in the `define_split' (of
-course, there is no point in writing a `define_split' that will never
-produce insns that match).
-
- Here is an example of this use of `define_split', taken from
-`rs6000.md':
-
- (define_split
- [(set (match_operand:SI 0 "gen_reg_operand" "")
- (plus:SI (match_operand:SI 1 "gen_reg_operand" "")
- (match_operand:SI 2 "non_add_cint_operand" "")))]
- ""
- [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3)))
- (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))]
- "
- {
- int low = INTVAL (operands[2]) & 0xffff;
- int high = (unsigned) INTVAL (operands[2]) >> 16;
-
- if (low & 0x8000)
- high++, low |= 0xffff0000;
-
- operands[3] = GEN_INT (high << 16);
- operands[4] = GEN_INT (low);
- }")
-
- Here the predicate `non_add_cint_operand' matches any `const_int' that
-is _not_ a valid operand of a single add insn. The add with the
-smaller displacement is written so that it can be substituted into the
-address of a subsequent operation.
-
- An example that uses a scratch register, from the same file, generates
-an equality comparison of a register and a large constant:
-
- (define_split
- [(set (match_operand:CC 0 "cc_reg_operand" "")
- (compare:CC (match_operand:SI 1 "gen_reg_operand" "")
- (match_operand:SI 2 "non_short_cint_operand" "")))
- (clobber (match_operand:SI 3 "gen_reg_operand" ""))]
- "find_single_use (operands[0], insn, 0)
- && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ
- || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)"
- [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4)))
- (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))]
- "
- {
- /* Get the constant we are comparing against, C, and see what it
- looks like sign-extended to 16 bits. Then see what constant
- could be XOR'ed with C to get the sign-extended value. */
-
- int c = INTVAL (operands[2]);
- int sextc = (c << 16) >> 16;
- int xorv = c ^ sextc;
-
- operands[4] = GEN_INT (xorv);
- operands[5] = GEN_INT (sextc);
- }")
-
- To avoid confusion, don't write a single `define_split' that accepts
-some insns that match some `define_insn' as well as some insns that
-don't. Instead, write two separate `define_split' definitions, one for
-the insns that are valid and one for the insns that are not valid.
-
- The splitter is allowed to split jump instructions into sequence of
-jumps or create new jumps in while splitting non-jump instructions. As
-the central flowgraph and branch prediction information needs to be
-updated, several restriction apply.
-
- Splitting of jump instruction into sequence that over by another jump
-instruction is always valid, as compiler expect identical behavior of
-new jump. When new sequence contains multiple jump instructions or new
-labels, more assistance is needed. Splitter is required to create only
-unconditional jumps, or simple conditional jump instructions.
-Additionally it must attach a `REG_BR_PROB' note to each conditional
-jump. A global variable `split_branch_probability' holds the
-probability of the original branch in case it was a simple conditional
-jump, -1 otherwise. To simplify recomputing of edge frequencies, the
-new sequence is required to have only forward jumps to the newly
-created labels.
-
- For the common case where the pattern of a define_split exactly
-matches the pattern of a define_insn, use `define_insn_and_split'. It
-looks like this:
-
- (define_insn_and_split
- [INSN-PATTERN]
- "CONDITION"
- "OUTPUT-TEMPLATE"
- "SPLIT-CONDITION"
- [NEW-INSN-PATTERN-1
- NEW-INSN-PATTERN-2
- ...]
- "PREPARATION-STATEMENTS"
- [INSN-ATTRIBUTES])
-
- INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used
-as in `define_insn'. The NEW-INSN-PATTERN vector and the
-PREPARATION-STATEMENTS are used as in a `define_split'. The
-SPLIT-CONDITION is also used as in `define_split', with the additional
-behavior that if the condition starts with `&&', the condition used for
-the split will be the constructed as a logical "and" of the split
-condition with the insn condition. For example, from i386.md:
-
- (define_insn_and_split "zero_extendhisi2_and"
- [(set (match_operand:SI 0 "register_operand" "=r")
- (zero_extend:SI (match_operand:HI 1 "register_operand" "0")))
- (clobber (reg:CC 17))]
- "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size"
- "#"
- "&& reload_completed"
- [(parallel [(set (match_dup 0)
- (and:SI (match_dup 0) (const_int 65535)))
- (clobber (reg:CC 17))])]
- ""
- [(set_attr "type" "alu1")])
-
- In this case, the actual split condition will be
-`TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'.
-
- The `define_insn_and_split' construction provides exactly the same
-functionality as two separate `define_insn' and `define_split'
-patterns. It exists for compactness, and as a maintenance tool to
-prevent having to ensure the two patterns' templates match.
-
-
-File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc
-
-16.17 Including Patterns in Machine Descriptions.
-=================================================
-
-The `include' pattern tells the compiler tools where to look for
-patterns that are in files other than in the file `.md'. This is used
-only at build time and there is no preprocessing allowed.
-
- It looks like:
-
-
- (include
- PATHNAME)
-
- For example:
-
-
- (include "filestuff")
-
- Where PATHNAME is a string that specifies the location of the file,
-specifies the include file to be in `gcc/config/target/filestuff'. The
-directory `gcc/config/target' is regarded as the default directory.
-
- Machine descriptions may be split up into smaller more manageable
-subsections and placed into subdirectories.
-
- By specifying:
-
-
- (include "BOGUS/filestuff")
-
- the include file is specified to be in
-`gcc/config/TARGET/BOGUS/filestuff'.
-
- Specifying an absolute path for the include file such as;
-
- (include "/u2/BOGUS/filestuff")
- is permitted but is not encouraged.
-
-16.17.1 RTL Generation Tool Options for Directory Search
---------------------------------------------------------
-
-The `-IDIR' option specifies directories to search for machine
-descriptions. For example:
-
-
- genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md
-
- Add the directory DIR to the head of the list of directories to be
-searched for header files. This can be used to override a system
-machine definition file, substituting your own version, since these
-directories are searched before the default machine description file
-directories. If you use more than one `-I' option, the directories are
-scanned in left-to-right order; the standard default directory come
-after.
-
-
-File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc
-
-16.18 Machine-Specific Peephole Optimizers
-==========================================
-
-In addition to instruction patterns the `md' file may contain
-definitions of machine-specific peephole optimizations.
-
- The combiner does not notice certain peephole optimizations when the
-data flow in the program does not suggest that it should try them. For
-example, sometimes two consecutive insns related in purpose can be
-combined even though the second one does not appear to use a register
-computed in the first one. A machine-specific peephole optimizer can
-detect such opportunities.
-
- There are two forms of peephole definitions that may be used. The
-original `define_peephole' is run at assembly output time to match
-insns and substitute assembly text. Use of `define_peephole' is
-deprecated.
-
- A newer `define_peephole2' matches insns and substitutes new insns.
-The `peephole2' pass is run after register allocation but before
-scheduling, which may result in much better code for targets that do
-scheduling.
-
-* Menu:
-
-* define_peephole:: RTL to Text Peephole Optimizers
-* define_peephole2:: RTL to RTL Peephole Optimizers
-
-
-File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions
-
-16.18.1 RTL to Text Peephole Optimizers
----------------------------------------
-
-A definition looks like this:
-
- (define_peephole
- [INSN-PATTERN-1
- INSN-PATTERN-2
- ...]
- "CONDITION"
- "TEMPLATE"
- "OPTIONAL-INSN-ATTRIBUTES")
-
-The last string operand may be omitted if you are not using any
-machine-specific information in this machine description. If present,
-it must obey the same rules as in a `define_insn'.
-
- In this skeleton, INSN-PATTERN-1 and so on are patterns to match
-consecutive insns. The optimization applies to a sequence of insns when
-INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next,
-and so on.
-
- Each of the insns matched by a peephole must also match a
-`define_insn'. Peepholes are checked only at the last stage just
-before code generation, and only optionally. Therefore, any insn which
-would match a peephole but no `define_insn' will cause a crash in code
-generation in an unoptimized compilation, or at various optimization
-stages.
-
- The operands of the insns are matched with `match_operands',
-`match_operator', and `match_dup', as usual. What is not usual is that
-the operand numbers apply to all the insn patterns in the definition.
-So, you can check for identical operands in two insns by using
-`match_operand' in one insn and `match_dup' in the other.
-
- The operand constraints used in `match_operand' patterns do not have
-any direct effect on the applicability of the peephole, but they will
-be validated afterward, so make sure your constraints are general enough
-to apply whenever the peephole matches. If the peephole matches but
-the constraints are not satisfied, the compiler will crash.
-
- It is safe to omit constraints in all the operands of the peephole; or
-you can write constraints which serve as a double-check on the criteria
-previously tested.
-
- Once a sequence of insns matches the patterns, the CONDITION is
-checked. This is a C expression which makes the final decision whether
-to perform the optimization (we do so if the expression is nonzero). If
-CONDITION is omitted (in other words, the string is empty) then the
-optimization is applied to every sequence of insns that matches the
-patterns.
-
- The defined peephole optimizations are applied after register
-allocation is complete. Therefore, the peephole definition can check
-which operands have ended up in which kinds of registers, just by
-looking at the operands.
-
- The way to refer to the operands in CONDITION is to write
-`operands[I]' for operand number I (as matched by `(match_operand I
-...)'). Use the variable `insn' to refer to the last of the insns
-being matched; use `prev_active_insn' to find the preceding insns.
-
- When optimizing computations with intermediate results, you can use
-CONDITION to match only when the intermediate results are not used
-elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN
-is the insn in which you expect the value to be used for the last time
-(from the value of `insn', together with use of `prev_nonnote_insn'),
-and OP is the intermediate value (from `operands[I]').
-
- Applying the optimization means replacing the sequence of insns with
-one new insn. The TEMPLATE controls ultimate output of assembler code
-for this combined insn. It works exactly like the template of a
-`define_insn'. Operand numbers in this template are the same ones used
-in matching the original sequence of insns.
-
- The result of a defined peephole optimizer does not need to match any
-of the insn patterns in the machine description; it does not even have
-an opportunity to match them. The peephole optimizer definition itself
-serves as the insn pattern to control how the insn is output.
-
- Defined peephole optimizers are run as assembler code is being output,
-so the insns they produce are never combined or rearranged in any way.
-
- Here is an example, taken from the 68000 machine description:
-
- (define_peephole
- [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
- (set (match_operand:DF 0 "register_operand" "=f")
- (match_operand:DF 1 "register_operand" "ad"))]
- "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
- {
- rtx xoperands[2];
- xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1);
- #ifdef MOTOROLA
- output_asm_insn ("move.l %1,(sp)", xoperands);
- output_asm_insn ("move.l %1,-(sp)", operands);
- return "fmove.d (sp)+,%0";
- #else
- output_asm_insn ("movel %1,sp@", xoperands);
- output_asm_insn ("movel %1,sp@-", operands);
- return "fmoved sp@+,%0";
- #endif
- })
-
- The effect of this optimization is to change
-
- jbsr _foobar
- addql #4,sp
- movel d1,sp@-
- movel d0,sp@-
- fmoved sp@+,fp0
-
-into
-
- jbsr _foobar
- movel d1,sp@
- movel d0,sp@-
- fmoved sp@+,fp0
-
- INSN-PATTERN-1 and so on look _almost_ like the second operand of
-`define_insn'. There is one important difference: the second operand
-of `define_insn' consists of one or more RTX's enclosed in square
-brackets. Usually, there is only one: then the same action can be
-written as an element of a `define_peephole'. But when there are
-multiple actions in a `define_insn', they are implicitly enclosed in a
-`parallel'. Then you must explicitly write the `parallel', and the
-square brackets within it, in the `define_peephole'. Thus, if an insn
-pattern looks like this,
-
- (define_insn "divmodsi4"
- [(set (match_operand:SI 0 "general_operand" "=d")
- (div:SI (match_operand:SI 1 "general_operand" "0")
- (match_operand:SI 2 "general_operand" "dmsK")))
- (set (match_operand:SI 3 "general_operand" "=d")
- (mod:SI (match_dup 1) (match_dup 2)))]
- "TARGET_68020"
- "divsl%.l %2,%3:%0")
-
-then the way to mention this insn in a peephole is as follows:
-
- (define_peephole
- [...
- (parallel
- [(set (match_operand:SI 0 "general_operand" "=d")
- (div:SI (match_operand:SI 1 "general_operand" "0")
- (match_operand:SI 2 "general_operand" "dmsK")))
- (set (match_operand:SI 3 "general_operand" "=d")
- (mod:SI (match_dup 1) (match_dup 2)))])
- ...]
- ...)
-
-
-File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions
-
-16.18.2 RTL to RTL Peephole Optimizers
---------------------------------------
-
-The `define_peephole2' definition tells the compiler how to substitute
-one sequence of instructions for another sequence, what additional
-scratch registers may be needed and what their lifetimes must be.
-
- (define_peephole2
- [INSN-PATTERN-1
- INSN-PATTERN-2
- ...]
- "CONDITION"
- [NEW-INSN-PATTERN-1
- NEW-INSN-PATTERN-2
- ...]
- "PREPARATION-STATEMENTS")
-
- The definition is almost identical to `define_split' (*note Insn
-Splitting::) except that the pattern to match is not a single
-instruction, but a sequence of instructions.
-
- It is possible to request additional scratch registers for use in the
-output template. If appropriate registers are not free, the pattern
-will simply not match.
-
- Scratch registers are requested with a `match_scratch' pattern at the
-top level of the input pattern. The allocated register (initially) will
-be dead at the point requested within the original sequence. If the
-scratch is used at more than a single point, a `match_dup' pattern at
-the top level of the input pattern marks the last position in the input
-sequence at which the register must be available.
-
- Here is an example from the IA-32 machine description:
-
- (define_peephole2
- [(match_scratch:SI 2 "r")
- (parallel [(set (match_operand:SI 0 "register_operand" "")
- (match_operator:SI 3 "arith_or_logical_operator"
- [(match_dup 0)
- (match_operand:SI 1 "memory_operand" "")]))
- (clobber (reg:CC 17))])]
- "! optimize_size && ! TARGET_READ_MODIFY"
- [(set (match_dup 2) (match_dup 1))
- (parallel [(set (match_dup 0)
- (match_op_dup 3 [(match_dup 0) (match_dup 2)]))
- (clobber (reg:CC 17))])]
- "")
-
-This pattern tries to split a load from its use in the hopes that we'll
-be able to schedule around the memory load latency. It allocates a
-single `SImode' register of class `GENERAL_REGS' (`"r"') that needs to
-be live only at the point just before the arithmetic.
-
- A real example requiring extended scratch lifetimes is harder to come
-by, so here's a silly made-up example:
-
- (define_peephole2
- [(match_scratch:SI 4 "r")
- (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" ""))
- (set (match_operand:SI 2 "" "") (match_dup 1))
- (match_dup 4)
- (set (match_operand:SI 3 "" "") (match_dup 1))]
- "/* determine 1 does not overlap 0 and 2 */"
- [(set (match_dup 4) (match_dup 1))
- (set (match_dup 0) (match_dup 4))
- (set (match_dup 2) (match_dup 4))]
- (set (match_dup 3) (match_dup 4))]
- "")
-
-If we had not added the `(match_dup 4)' in the middle of the input
-sequence, it might have been the case that the register we chose at the
-beginning of the sequence is killed by the first or second `set'.
-
-
-File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc
-
-16.19 Instruction Attributes
-============================
-
-In addition to describing the instruction supported by the target
-machine, the `md' file also defines a group of "attributes" and a set of
-values for each. Every generated insn is assigned a value for each
-attribute. One possible attribute would be the effect that the insn
-has on the machine's condition code. This attribute can then be used
-by `NOTICE_UPDATE_CC' to track the condition codes.
-
-* Menu:
-
-* Defining Attributes:: Specifying attributes and their values.
-* Expressions:: Valid expressions for attribute values.
-* Tagging Insns:: Assigning attribute values to insns.
-* Attr Example:: An example of assigning attributes.
-* Insn Lengths:: Computing the length of insns.
-* Constant Attributes:: Defining attributes that are constant.
-* Delay Slots:: Defining delay slots required for a machine.
-* Processor pipeline description:: Specifying information for insn scheduling.
-
-
-File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes
-
-16.19.1 Defining Attributes and their Values
---------------------------------------------
-
-The `define_attr' expression is used to define each attribute required
-by the target machine. It looks like:
-
- (define_attr NAME LIST-OF-VALUES DEFAULT)
-
- NAME is a string specifying the name of the attribute being defined.
-
- LIST-OF-VALUES is either a string that specifies a comma-separated
-list of values that can be assigned to the attribute, or a null string
-to indicate that the attribute takes numeric values.
-
- DEFAULT is an attribute expression that gives the value of this
-attribute for insns that match patterns whose definition does not
-include an explicit value for this attribute. *Note Attr Example::,
-for more information on the handling of defaults. *Note Constant
-Attributes::, for information on attributes that do not depend on any
-particular insn.
-
- For each defined attribute, a number of definitions are written to the
-`insn-attr.h' file. For cases where an explicit set of values is
-specified for an attribute, the following are defined:
-
- * A `#define' is written for the symbol `HAVE_ATTR_NAME'.
-
- * An enumerated class is defined for `attr_NAME' with elements of
- the form `UPPER-NAME_UPPER-VALUE' where the attribute name and
- value are first converted to uppercase.
-
- * A function `get_attr_NAME' is defined that is passed an insn and
- returns the attribute value for that insn.
-
- For example, if the following is present in the `md' file:
-
- (define_attr "type" "branch,fp,load,store,arith" ...)
-
-the following lines will be written to the file `insn-attr.h'.
-
- #define HAVE_ATTR_type
- enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
- TYPE_STORE, TYPE_ARITH};
- extern enum attr_type get_attr_type ();
-
- If the attribute takes numeric values, no `enum' type will be defined
-and the function to obtain the attribute's value will return `int'.
-
- There are attributes which are tied to a specific meaning. These
-attributes are not free to use for other purposes:
-
-`length'
- The `length' attribute is used to calculate the length of emitted
- code chunks. This is especially important when verifying branch
- distances. *Note Insn Lengths::.
-
-`enabled'
- The `enabled' attribute can be defined to prevent certain
- alternatives of an insn definition from being used during code
- generation. *Note Disable Insn Alternatives::.
-
- Another way of defining an attribute is to use:
-
- (define_enum_attr "ATTR" "ENUM" DEFAULT)
-
- This works in just the same way as `define_attr', except that the list
-of values is taken from a separate enumeration called ENUM (*note
-define_enum::). This form allows you to use the same list of values
-for several attributes without having to repeat the list each time.
-For example:
-
- (define_enum "processor" [
- model_a
- model_b
- ...
- ])
- (define_enum_attr "arch" "processor"
- (const (symbol_ref "target_arch")))
- (define_enum_attr "tune" "processor"
- (const (symbol_ref "target_tune")))
-
- defines the same attributes as:
-
- (define_attr "arch" "model_a,model_b,..."
- (const (symbol_ref "target_arch")))
- (define_attr "tune" "model_a,model_b,..."
- (const (symbol_ref "target_tune")))
-
- but without duplicating the processor list. The second example
-defines two separate C enums (`attr_arch' and `attr_tune') whereas the
-first defines a single C enum (`processor').
-
-
-File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes
-
-16.19.2 Attribute Expressions
------------------------------
-
-RTL expressions used to define attributes use the codes described above
-plus a few specific to attribute definitions, to be discussed below.
-Attribute value expressions must have one of the following forms:
-
-`(const_int I)'
- The integer I specifies the value of a numeric attribute. I must
- be non-negative.
-
- The value of a numeric attribute can be specified either with a
- `const_int', or as an integer represented as a string in
- `const_string', `eq_attr' (see below), `attr', `symbol_ref',
- simple arithmetic expressions, and `set_attr' overrides on
- specific instructions (*note Tagging Insns::).
-
-`(const_string VALUE)'
- The string VALUE specifies a constant attribute value. If VALUE
- is specified as `"*"', it means that the default value of the
- attribute is to be used for the insn containing this expression.
- `"*"' obviously cannot be used in the DEFAULT expression of a
- `define_attr'.
-
- If the attribute whose value is being specified is numeric, VALUE
- must be a string containing a non-negative integer (normally
- `const_int' would be used in this case). Otherwise, it must
- contain one of the valid values for the attribute.
-
-`(if_then_else TEST TRUE-VALUE FALSE-VALUE)'
- TEST specifies an attribute test, whose format is defined below.
- The value of this expression is TRUE-VALUE if TEST is true,
- otherwise it is FALSE-VALUE.
-
-`(cond [TEST1 VALUE1 ...] DEFAULT)'
- The first operand of this expression is a vector containing an even
- number of expressions and consisting of pairs of TEST and VALUE
- expressions. The value of the `cond' expression is that of the
- VALUE corresponding to the first true TEST expression. If none of
- the TEST expressions are true, the value of the `cond' expression
- is that of the DEFAULT expression.
-
- TEST expressions can have one of the following forms:
-
-`(const_int I)'
- This test is true if I is nonzero and false otherwise.
-
-`(not TEST)'
-`(ior TEST1 TEST2)'
-`(and TEST1 TEST2)'
- These tests are true if the indicated logical function is true.
-
-`(match_operand:M N PRED CONSTRAINTS)'
- This test is true if operand N of the insn whose attribute value
- is being determined has mode M (this part of the test is ignored
- if M is `VOIDmode') and the function specified by the string PRED
- returns a nonzero value when passed operand N and mode M (this
- part of the test is ignored if PRED is the null string).
-
- The CONSTRAINTS operand is ignored and should be the null string.
-
-`(le ARITH1 ARITH2)'
-`(leu ARITH1 ARITH2)'
-`(lt ARITH1 ARITH2)'
-`(ltu ARITH1 ARITH2)'
-`(gt ARITH1 ARITH2)'
-`(gtu ARITH1 ARITH2)'
-`(ge ARITH1 ARITH2)'
-`(geu ARITH1 ARITH2)'
-`(ne ARITH1 ARITH2)'
-`(eq ARITH1 ARITH2)'
- These tests are true if the indicated comparison of the two
- arithmetic expressions is true. Arithmetic expressions are formed
- with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and',
- `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt'
- expressions.
-
- `const_int' and `symbol_ref' are always valid terms (*note Insn
- Lengths::,for additional forms). `symbol_ref' is a string
- denoting a C expression that yields an `int' when evaluated by the
- `get_attr_...' routine. It should normally be a global variable.
-
-`(eq_attr NAME VALUE)'
- NAME is a string specifying the name of an attribute.
-
- VALUE is a string that is either a valid value for attribute NAME,
- a comma-separated list of values, or `!' followed by a value or
- list. If VALUE does not begin with a `!', this test is true if
- the value of the NAME attribute of the current insn is in the list
- specified by VALUE. If VALUE begins with a `!', this test is true
- if the attribute's value is _not_ in the specified list.
-
- For example,
-
- (eq_attr "type" "load,store")
-
- is equivalent to
-
- (ior (eq_attr "type" "load") (eq_attr "type" "store"))
-
- If NAME specifies an attribute of `alternative', it refers to the
- value of the compiler variable `which_alternative' (*note Output
- Statement::) and the values must be small integers. For example,
-
- (eq_attr "alternative" "2,3")
-
- is equivalent to
-
- (ior (eq (symbol_ref "which_alternative") (const_int 2))
- (eq (symbol_ref "which_alternative") (const_int 3)))
-
- Note that, for most attributes, an `eq_attr' test is simplified in
- cases where the value of the attribute being tested is known for
- all insns matching a particular pattern. This is by far the most
- common case.
-
-`(attr_flag NAME)'
- The value of an `attr_flag' expression is true if the flag
- specified by NAME is true for the `insn' currently being scheduled.
-
- NAME is a string specifying one of a fixed set of flags to test.
- Test the flags `forward' and `backward' to determine the direction
- of a conditional branch. Test the flags `very_likely', `likely',
- `very_unlikely', and `unlikely' to determine if a conditional
- branch is expected to be taken.
-
- If the `very_likely' flag is true, then the `likely' flag is also
- true. Likewise for the `very_unlikely' and `unlikely' flags.
-
- This example describes a conditional branch delay slot which can
- be nullified for forward branches that are taken (annul-true) or
- for backward branches which are not taken (annul-false).
-
- (define_delay (eq_attr "type" "cbranch")
- [(eq_attr "in_branch_delay" "true")
- (and (eq_attr "in_branch_delay" "true")
- (attr_flag "forward"))
- (and (eq_attr "in_branch_delay" "true")
- (attr_flag "backward"))])
-
- The `forward' and `backward' flags are false if the current `insn'
- being scheduled is not a conditional branch.
-
- The `very_likely' and `likely' flags are true if the `insn' being
- scheduled is not a conditional branch. The `very_unlikely' and
- `unlikely' flags are false if the `insn' being scheduled is not a
- conditional branch.
-
- `attr_flag' is only used during delay slot scheduling and has no
- meaning to other passes of the compiler.
-
-`(attr NAME)'
- The value of another attribute is returned. This is most useful
- for numeric attributes, as `eq_attr' and `attr_flag' produce more
- efficient code for non-numeric attributes.
-
-
-File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes
-
-16.19.3 Assigning Attribute Values to Insns
--------------------------------------------
-
-The value assigned to an attribute of an insn is primarily determined by
-which pattern is matched by that insn (or which `define_peephole'
-generated it). Every `define_insn' and `define_peephole' can have an
-optional last argument to specify the values of attributes for matching
-insns. The value of any attribute not specified in a particular insn
-is set to the default value for that attribute, as specified in its
-`define_attr'. Extensive use of default values for attributes permits
-the specification of the values for only one or two attributes in the
-definition of most insn patterns, as seen in the example in the next
-section.
-
- The optional last argument of `define_insn' and `define_peephole' is a
-vector of expressions, each of which defines the value for a single
-attribute. The most general way of assigning an attribute's value is
-to use a `set' expression whose first operand is an `attr' expression
-giving the name of the attribute being set. The second operand of the
-`set' is an attribute expression (*note Expressions::) giving the value
-of the attribute.
-
- When the attribute value depends on the `alternative' attribute (i.e.,
-which is the applicable alternative in the constraint of the insn), the
-`set_attr_alternative' expression can be used. It allows the
-specification of a vector of attribute expressions, one for each
-alternative.
-
- When the generality of arbitrary attribute expressions is not required,
-the simpler `set_attr' expression can be used, which allows specifying
-a string giving either a single attribute value or a list of attribute
-values, one for each alternative.
-
- The form of each of the above specifications is shown below. In each
-case, NAME is a string specifying the attribute to be set.
-
-`(set_attr NAME VALUE-STRING)'
- VALUE-STRING is either a string giving the desired attribute value,
- or a string containing a comma-separated list giving the values for
- succeeding alternatives. The number of elements must match the
- number of alternatives in the constraint of the insn pattern.
-
- Note that it may be useful to specify `*' for some alternative, in
- which case the attribute will assume its default value for insns
- matching that alternative.
-
-`(set_attr_alternative NAME [VALUE1 VALUE2 ...])'
- Depending on the alternative of the insn, the value will be one of
- the specified values. This is a shorthand for using a `cond' with
- tests on the `alternative' attribute.
-
-`(set (attr NAME) VALUE)'
- The first operand of this `set' must be the special RTL expression
- `attr', whose sole operand is a string giving the name of the
- attribute being set. VALUE is the value of the attribute.
-
- The following shows three different ways of representing the same
-attribute value specification:
-
- (set_attr "type" "load,store,arith")
-
- (set_attr_alternative "type"
- [(const_string "load") (const_string "store")
- (const_string "arith")])
-
- (set (attr "type")
- (cond [(eq_attr "alternative" "1") (const_string "load")
- (eq_attr "alternative" "2") (const_string "store")]
- (const_string "arith")))
-
- The `define_asm_attributes' expression provides a mechanism to specify
-the attributes assigned to insns produced from an `asm' statement. It
-has the form:
-
- (define_asm_attributes [ATTR-SETS])
-
-where ATTR-SETS is specified the same as for both the `define_insn' and
-the `define_peephole' expressions.
-
- These values will typically be the "worst case" attribute values. For
-example, they might indicate that the condition code will be clobbered.
-
- A specification for a `length' attribute is handled specially. The
-way to compute the length of an `asm' insn is to multiply the length
-specified in the expression `define_asm_attributes' by the number of
-machine instructions specified in the `asm' statement, determined by
-counting the number of semicolons and newlines in the string.
-Therefore, the value of the `length' attribute specified in a
-`define_asm_attributes' should be the maximum possible length of a
-single machine instruction.
-
-
-File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes
-
-16.19.4 Example of Attribute Specifications
--------------------------------------------
-
-The judicious use of defaulting is important in the efficient use of
-insn attributes. Typically, insns are divided into "types" and an
-attribute, customarily called `type', is used to represent this value.
-This attribute is normally used only to define the default value for
-other attributes. An example will clarify this usage.
-
- Assume we have a RISC machine with a condition code and in which only
-full-word operations are performed in registers. Let us assume that we
-can divide all insns into loads, stores, (integer) arithmetic
-operations, floating point operations, and branches.
-
- Here we will concern ourselves with determining the effect of an insn
-on the condition code and will limit ourselves to the following possible
-effects: The condition code can be set unpredictably (clobbered), not
-be changed, be set to agree with the results of the operation, or only
-changed if the item previously set into the condition code has been
-modified.
-
- Here is part of a sample `md' file for such a machine:
-
- (define_attr "type" "load,store,arith,fp,branch" (const_string "arith"))
-
- (define_attr "cc" "clobber,unchanged,set,change0"
- (cond [(eq_attr "type" "load")
- (const_string "change0")
- (eq_attr "type" "store,branch")
- (const_string "unchanged")
- (eq_attr "type" "arith")
- (if_then_else (match_operand:SI 0 "" "")
- (const_string "set")
- (const_string "clobber"))]
- (const_string "clobber")))
-
- (define_insn ""
- [(set (match_operand:SI 0 "general_operand" "=r,r,m")
- (match_operand:SI 1 "general_operand" "r,m,r"))]
- ""
- "@
- move %0,%1
- load %0,%1
- store %0,%1"
- [(set_attr "type" "arith,load,store")])
-
- Note that we assume in the above example that arithmetic operations
-performed on quantities smaller than a machine word clobber the
-condition code since they will set the condition code to a value
-corresponding to the full-word result.
-
-
-File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes
-
-16.19.5 Computing the Length of an Insn
----------------------------------------
-
-For many machines, multiple types of branch instructions are provided,
-each for different length branch displacements. In most cases, the
-assembler will choose the correct instruction to use. However, when
-the assembler cannot do so, GCC can when a special attribute, the
-`length' attribute, is defined. This attribute must be defined to have
-numeric values by specifying a null string in its `define_attr'.
-
- In the case of the `length' attribute, two additional forms of
-arithmetic terms are allowed in test expressions:
-
-`(match_dup N)'
- This refers to the address of operand N of the current insn, which
- must be a `label_ref'.
-
-`(pc)'
- This refers to the address of the _current_ insn. It might have
- been more consistent with other usage to make this the address of
- the _next_ insn but this would be confusing because the length of
- the current insn is to be computed.
-
- For normal insns, the length will be determined by value of the
-`length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn
-patterns, the length is computed as the number of vectors multiplied by
-the size of each vector.
-
- Lengths are measured in addressable storage units (bytes).
-
- The following macros can be used to refine the length computation:
-
-`ADJUST_INSN_LENGTH (INSN, LENGTH)'
- If defined, modifies the length assigned to instruction INSN as a
- function of the context in which it is used. LENGTH is an lvalue
- that contains the initially computed length of the insn and should
- be updated with the correct length of the insn.
-
- This macro will normally not be required. A case in which it is
- required is the ROMP. On this machine, the size of an `addr_vec'
- insn must be increased by two to compensate for the fact that
- alignment may be required.
-
- The routine that returns `get_attr_length' (the value of the `length'
-attribute) can be used by the output routine to determine the form of
-the branch instruction to be written, as the example below illustrates.
-
- As an example of the specification of variable-length branches,
-consider the IBM 360. If we adopt the convention that a register will
-be set to the starting address of a function, we can jump to labels
-within 4k of the start using a four-byte instruction. Otherwise, we
-need a six-byte sequence to load the address from memory and then
-branch to it.
-
- On such a machine, a pattern for a branch instruction might be
-specified as follows:
-
- (define_insn "jump"
- [(set (pc)
- (label_ref (match_operand 0 "" "")))]
- ""
- {
- return (get_attr_length (insn) == 4
- ? "b %l0" : "l r15,=a(%l0); br r15");
- }
- [(set (attr "length")
- (if_then_else (lt (match_dup 0) (const_int 4096))
- (const_int 4)
- (const_int 6)))])
-
-
-File: gccint.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes
-
-16.19.6 Constant Attributes
----------------------------
-
-A special form of `define_attr', where the expression for the default
-value is a `const' expression, indicates an attribute that is constant
-for a given run of the compiler. Constant attributes may be used to
-specify which variety of processor is used. For example,
-
- (define_attr "cpu" "m88100,m88110,m88000"
- (const
- (cond [(symbol_ref "TARGET_88100") (const_string "m88100")
- (symbol_ref "TARGET_88110") (const_string "m88110")]
- (const_string "m88000"))))
-
- (define_attr "memory" "fast,slow"
- (const
- (if_then_else (symbol_ref "TARGET_FAST_MEM")
- (const_string "fast")
- (const_string "slow"))))
-
- The routine generated for constant attributes has no parameters as it
-does not depend on any particular insn. RTL expressions used to define
-the value of a constant attribute may use the `symbol_ref' form, but
-may not use either the `match_operand' form or `eq_attr' forms
-involving insn attributes.
-
-
-File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Constant Attributes, Up: Insn Attributes
-
-16.19.7 Delay Slot Scheduling
------------------------------
-
-The insn attribute mechanism can be used to specify the requirements for
-delay slots, if any, on a target machine. An instruction is said to
-require a "delay slot" if some instructions that are physically after
-the instruction are executed as if they were located before it.
-Classic examples are branch and call instructions, which often execute
-the following instruction before the branch or call is performed.
-
- On some machines, conditional branch instructions can optionally
-"annul" instructions in the delay slot. This means that the
-instruction will not be executed for certain branch outcomes. Both
-instructions that annul if the branch is true and instructions that
-annul if the branch is false are supported.
-
- Delay slot scheduling differs from instruction scheduling in that
-determining whether an instruction needs a delay slot is dependent only
-on the type of instruction being generated, not on data flow between the
-instructions. See the next section for a discussion of data-dependent
-instruction scheduling.
-
- The requirement of an insn needing one or more delay slots is indicated
-via the `define_delay' expression. It has the following form:
-
- (define_delay TEST
- [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
- DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
- ...])
-
- TEST is an attribute test that indicates whether this `define_delay'
-applies to a particular insn. If so, the number of required delay
-slots is determined by the length of the vector specified as the second
-argument. An insn placed in delay slot N must satisfy attribute test
-DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns
-may be annulled if the branch is true. Similarly, ANNUL-FALSE-N
-specifies which insns in the delay slot may be annulled if the branch
-is false. If annulling is not supported for that delay slot, `(nil)'
-should be coded.
-
- For example, in the common case where branch and call insns require a
-single delay slot, which may contain any insn other than a branch or
-call, the following would be placed in the `md' file:
-
- (define_delay (eq_attr "type" "branch,call")
- [(eq_attr "type" "!branch,call") (nil) (nil)])
-
- Multiple `define_delay' expressions may be specified. In this case,
-each such expression specifies different delay slot requirements and
-there must be no insn for which tests in two `define_delay' expressions
-are both true.
-
- For example, if we have a machine that requires one delay slot for
-branches but two for calls, no delay slot can contain a branch or call
-insn, and any valid insn in the delay slot for the branch can be
-annulled if the branch is true, we might represent this as follows:
-
- (define_delay (eq_attr "type" "branch")
- [(eq_attr "type" "!branch,call")
- (eq_attr "type" "!branch,call")
- (nil)])
-
- (define_delay (eq_attr "type" "call")
- [(eq_attr "type" "!branch,call") (nil) (nil)
- (eq_attr "type" "!branch,call") (nil) (nil)])
-
-
-File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes
-
-16.19.8 Specifying processor pipeline description
--------------------------------------------------
-
-To achieve better performance, most modern processors (super-pipelined,
-superscalar RISC, and VLIW processors) have many "functional units" on
-which several instructions can be executed simultaneously. An
-instruction starts execution if its issue conditions are satisfied. If
-not, the instruction is stalled until its conditions are satisfied.
-Such "interlock (pipeline) delay" causes interruption of the fetching
-of successor instructions (or demands nop instructions, e.g. for some
-MIPS processors).
-
- There are two major kinds of interlock delays in modern processors.
-The first one is a data dependence delay determining "instruction
-latency time". The instruction execution is not started until all
-source data have been evaluated by prior instructions (there are more
-complex cases when the instruction execution starts even when the data
-are not available but will be ready in given time after the instruction
-execution start). Taking the data dependence delays into account is
-simple. The data dependence (true, output, and anti-dependence) delay
-between two instructions is given by a constant. In most cases this
-approach is adequate. The second kind of interlock delays is a
-reservation delay. The reservation delay means that two instructions
-under execution will be in need of shared processors resources, i.e.
-buses, internal registers, and/or functional units, which are reserved
-for some time. Taking this kind of delay into account is complex
-especially for modern RISC processors.
-
- The task of exploiting more processor parallelism is solved by an
-instruction scheduler. For a better solution to this problem, the
-instruction scheduler has to have an adequate description of the
-processor parallelism (or "pipeline description"). GCC machine
-descriptions describe processor parallelism and functional unit
-reservations for groups of instructions with the aid of "regular
-expressions".
-
- The GCC instruction scheduler uses a "pipeline hazard recognizer" to
-figure out the possibility of the instruction issue by the processor on
-a given simulated processor cycle. The pipeline hazard recognizer is
-automatically generated from the processor pipeline description. The
-pipeline hazard recognizer generated from the machine description is
-based on a deterministic finite state automaton (DFA): the instruction
-issue is possible if there is a transition from one automaton state to
-another one. This algorithm is very fast, and furthermore, its speed
-is not dependent on processor complexity(1).
-
- The rest of this section describes the directives that constitute an
-automaton-based processor pipeline description. The order of these
-constructions within the machine description file is not important.
-
- The following optional construction describes names of automata
-generated and used for the pipeline hazards recognition. Sometimes the
-generated finite state automaton used by the pipeline hazard recognizer
-is large. If we use more than one automaton and bind functional units
-to the automata, the total size of the automata is usually less than
-the size of the single automaton. If there is no one such
-construction, only one finite state automaton is generated.
-
- (define_automaton AUTOMATA-NAMES)
-
- AUTOMATA-NAMES is a string giving names of the automata. The names
-are separated by commas. All the automata should have unique names.
-The automaton name is used in the constructions `define_cpu_unit' and
-`define_query_cpu_unit'.
-
- Each processor functional unit used in the description of instruction
-reservations should be described by the following construction.
-
- (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
-
- UNIT-NAMES is a string giving the names of the functional units
-separated by commas. Don't use name `nothing', it is reserved for
-other goals.
-
- AUTOMATON-NAME is a string giving the name of the automaton with which
-the unit is bound. The automaton should be described in construction
-`define_automaton'. You should give "automaton-name", if there is a
-defined automaton.
-
- The assignment of units to automata are constrained by the uses of the
-units in insn reservations. The most important constraint is: if a
-unit reservation is present on a particular cycle of an alternative for
-an insn reservation, then some unit from the same automaton must be
-present on the same cycle for the other alternatives of the insn
-reservation. The rest of the constraints are mentioned in the
-description of the subsequent constructions.
-
- The following construction describes CPU functional units analogously
-to `define_cpu_unit'. The reservation of such units can be queried for
-an automaton state. The instruction scheduler never queries
-reservation of functional units for given automaton state. So as a
-rule, you don't need this construction. This construction could be
-used for future code generation goals (e.g. to generate VLIW insn
-templates).
-
- (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
-
- UNIT-NAMES is a string giving names of the functional units separated
-by commas.
-
- AUTOMATON-NAME is a string giving the name of the automaton with which
-the unit is bound.
-
- The following construction is the major one to describe pipeline
-characteristics of an instruction.
-
- (define_insn_reservation INSN-NAME DEFAULT_LATENCY
- CONDITION REGEXP)
-
- DEFAULT_LATENCY is a number giving latency time of the instruction.
-There is an important difference between the old description and the
-automaton based pipeline description. The latency time is used for all
-dependencies when we use the old description. In the automaton based
-pipeline description, the given latency time is only used for true
-dependencies. The cost of anti-dependencies is always zero and the
-cost of output dependencies is the difference between latency times of
-the producing and consuming insns (if the difference is negative, the
-cost is considered to be zero). You can always change the default
-costs for any description by using the target hook
-`TARGET_SCHED_ADJUST_COST' (*note Scheduling::).
-
- INSN-NAME is a string giving the internal name of the insn. The
-internal names are used in constructions `define_bypass' and in the
-automaton description file generated for debugging. The internal name
-has nothing in common with the names in `define_insn'. It is a good
-practice to use insn classes described in the processor manual.
-
- CONDITION defines what RTL insns are described by this construction.
-You should remember that you will be in trouble if CONDITION for two or
-more different `define_insn_reservation' constructions is TRUE for an
-insn. In this case what reservation will be used for the insn is not
-defined. Such cases are not checked during generation of the pipeline
-hazards recognizer because in general recognizing that two conditions
-may have the same value is quite difficult (especially if the conditions
-contain `symbol_ref'). It is also not checked during the pipeline
-hazard recognizer work because it would slow down the recognizer
-considerably.
-
- REGEXP is a string describing the reservation of the cpu's functional
-units by the instruction. The reservations are described by a regular
-expression according to the following syntax:
-
- regexp = regexp "," oneof
- | oneof
-
- oneof = oneof "|" allof
- | allof
-
- allof = allof "+" repeat
- | repeat
-
- repeat = element "*" number
- | element
-
- element = cpu_function_unit_name
- | reservation_name
- | result_name
- | "nothing"
- | "(" regexp ")"
-
- * `,' is used for describing the start of the next cycle in the
- reservation.
-
- * `|' is used for describing a reservation described by the first
- regular expression *or* a reservation described by the second
- regular expression *or* etc.
-
- * `+' is used for describing a reservation described by the first
- regular expression *and* a reservation described by the second
- regular expression *and* etc.
-
- * `*' is used for convenience and simply means a sequence in which
- the regular expression are repeated NUMBER times with cycle
- advancing (see `,').
-
- * `cpu_function_unit_name' denotes reservation of the named
- functional unit.
-
- * `reservation_name' -- see description of construction
- `define_reservation'.
-
- * `nothing' denotes no unit reservations.
-
- Sometimes unit reservations for different insns contain common parts.
-In such case, you can simplify the pipeline description by describing
-the common part by the following construction
-
- (define_reservation RESERVATION-NAME REGEXP)
-
- RESERVATION-NAME is a string giving name of REGEXP. Functional unit
-names and reservation names are in the same name space. So the
-reservation names should be different from the functional unit names
-and can not be the reserved name `nothing'.
-
- The following construction is used to describe exceptions in the
-latency time for given instruction pair. This is so called bypasses.
-
- (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES
- [GUARD])
-
- NUMBER defines when the result generated by the instructions given in
-string OUT_INSN_NAMES will be ready for the instructions given in
-string IN_INSN_NAMES. The instructions in the string are separated by
-commas.
-
- GUARD is an optional string giving the name of a C function which
-defines an additional guard for the bypass. The function will get the
-two insns as parameters. If the function returns zero the bypass will
-be ignored for this case. The additional guard is necessary to
-recognize complicated bypasses, e.g. when the consumer is only an
-address of insn `store' (not a stored value).
-
- If there are more one bypass with the same output and input insns, the
-chosen bypass is the first bypass with a guard in description whose
-guard function returns nonzero. If there is no such bypass, then
-bypass without the guard function is chosen.
-
- The following five constructions are usually used to describe VLIW
-processors, or more precisely, to describe a placement of small
-instructions into VLIW instruction slots. They can be used for RISC
-processors, too.
-
- (exclusion_set UNIT-NAMES UNIT-NAMES)
- (presence_set UNIT-NAMES PATTERNS)
- (final_presence_set UNIT-NAMES PATTERNS)
- (absence_set UNIT-NAMES PATTERNS)
- (final_absence_set UNIT-NAMES PATTERNS)
-
- UNIT-NAMES is a string giving names of functional units separated by
-commas.
-
- PATTERNS is a string giving patterns of functional units separated by
-comma. Currently pattern is one unit or units separated by
-white-spaces.
-
- The first construction (`exclusion_set') means that each functional
-unit in the first string can not be reserved simultaneously with a unit
-whose name is in the second string and vice versa. For example, the
-construction is useful for describing processors (e.g. some SPARC
-processors) with a fully pipelined floating point functional unit which
-can execute simultaneously only single floating point insns or only
-double floating point insns.
-
- The second construction (`presence_set') means that each functional
-unit in the first string can not be reserved unless at least one of
-pattern of units whose names are in the second string is reserved.
-This is an asymmetric relation. For example, it is useful for
-description that VLIW `slot1' is reserved after `slot0' reservation.
-We could describe it by the following construction
-
- (presence_set "slot1" "slot0")
-
- Or `slot1' is reserved only after `slot0' and unit `b0' reservation.
-In this case we could write
-
- (presence_set "slot1" "slot0 b0")
-
- The third construction (`final_presence_set') is analogous to
-`presence_set'. The difference between them is when checking is done.
-When an instruction is issued in given automaton state reflecting all
-current and planned unit reservations, the automaton state is changed.
-The first state is a source state, the second one is a result state.
-Checking for `presence_set' is done on the source state reservation,
-checking for `final_presence_set' is done on the result reservation.
-This construction is useful to describe a reservation which is actually
-two subsequent reservations. For example, if we use
-
- (presence_set "slot1" "slot0")
-
- the following insn will be never issued (because `slot1' requires
-`slot0' which is absent in the source state).
-
- (define_reservation "insn_and_nop" "slot0 + slot1")
-
- but it can be issued if we use analogous `final_presence_set'.
-
- The forth construction (`absence_set') means that each functional unit
-in the first string can be reserved only if each pattern of units whose
-names are in the second string is not reserved. This is an asymmetric
-relation (actually `exclusion_set' is analogous to this one but it is
-symmetric). For example it might be useful in a VLIW description to
-say that `slot0' cannot be reserved after either `slot1' or `slot2'
-have been reserved. This can be described as:
-
- (absence_set "slot0" "slot1, slot2")
-
- Or `slot2' can not be reserved if `slot0' and unit `b0' are reserved
-or `slot1' and unit `b1' are reserved. In this case we could write
-
- (absence_set "slot2" "slot0 b0, slot1 b1")
-
- All functional units mentioned in a set should belong to the same
-automaton.
-
- The last construction (`final_absence_set') is analogous to
-`absence_set' but checking is done on the result (state) reservation.
-See comments for `final_presence_set'.
-
- You can control the generator of the pipeline hazard recognizer with
-the following construction.
-
- (automata_option OPTIONS)
-
- OPTIONS is a string giving options which affect the generated code.
-Currently there are the following options:
-
- * "no-minimization" makes no minimization of the automaton. This is
- only worth to do when we are debugging the description and need to
- look more accurately at reservations of states.
-
- * "time" means printing time statistics about the generation of
- automata.
-
- * "stats" means printing statistics about the generated automata
- such as the number of DFA states, NDFA states and arcs.
-
- * "v" means a generation of the file describing the result automata.
- The file has suffix `.dfa' and can be used for the description
- verification and debugging.
-
- * "w" means a generation of warning instead of error for
- non-critical errors.
-
- * "ndfa" makes nondeterministic finite state automata. This affects
- the treatment of operator `|' in the regular expressions. The
- usual treatment of the operator is to try the first alternative
- and, if the reservation is not possible, the second alternative.
- The nondeterministic treatment means trying all alternatives, some
- of them may be rejected by reservations in the subsequent insns.
-
- * "progress" means output of a progress bar showing how many states
- were generated so far for automaton being processed. This is
- useful during debugging a DFA description. If you see too many
- generated states, you could interrupt the generator of the pipeline
- hazard recognizer and try to figure out a reason for generation of
- the huge automaton.
-
- As an example, consider a superscalar RISC machine which can issue
-three insns (two integer insns and one floating point insn) on the
-cycle but can finish only two insns. To describe this, we define the
-following functional units.
-
- (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline")
- (define_cpu_unit "port0, port1")
-
- All simple integer insns can be executed in any integer pipeline and
-their result is ready in two cycles. The simple integer insns are
-issued into the first pipeline unless it is reserved, otherwise they
-are issued into the second pipeline. Integer division and
-multiplication insns can be executed only in the second integer
-pipeline and their results are ready correspondingly in 8 and 4 cycles.
-The integer division is not pipelined, i.e. the subsequent integer
-division insn can not be issued until the current division insn
-finished. Floating point insns are fully pipelined and their results
-are ready in 3 cycles. Where the result of a floating point insn is
-used by an integer insn, an additional delay of one cycle is incurred.
-To describe all of this we could specify
-
- (define_cpu_unit "div")
-
- (define_insn_reservation "simple" 2 (eq_attr "type" "int")
- "(i0_pipeline | i1_pipeline), (port0 | port1)")
-
- (define_insn_reservation "mult" 4 (eq_attr "type" "mult")
- "i1_pipeline, nothing*2, (port0 | port1)")
-
- (define_insn_reservation "div" 8 (eq_attr "type" "div")
- "i1_pipeline, div*7, div + (port0 | port1)")
-
- (define_insn_reservation "float" 3 (eq_attr "type" "float")
- "f_pipeline, nothing, (port0 | port1))
-
- (define_bypass 4 "float" "simple,mult,div")
-
- To simplify the description we could describe the following reservation
-
- (define_reservation "finish" "port0|port1")
-
- and use it in all `define_insn_reservation' as in the following
-construction
-
- (define_insn_reservation "simple" 2 (eq_attr "type" "int")
- "(i0_pipeline | i1_pipeline), finish")
-
- ---------- Footnotes ----------
-
- (1) However, the size of the automaton depends on processor
-complexity. To limit this effect, machine descriptions can split
-orthogonal parts of the machine description among several automata: but
-then, since each of these must be stepped independently, this does
-cause a small decrease in the algorithm's performance.
-
-
-File: gccint.info, Node: Conditional Execution, Next: Constant Definitions, Prev: Insn Attributes, Up: Machine Desc
-
-16.20 Conditional Execution
-===========================
-
-A number of architectures provide for some form of conditional
-execution, or predication. The hallmark of this feature is the ability
-to nullify most of the instructions in the instruction set. When the
-instruction set is large and not entirely symmetric, it can be quite
-tedious to describe these forms directly in the `.md' file. An
-alternative is the `define_cond_exec' template.
-
- (define_cond_exec
- [PREDICATE-PATTERN]
- "CONDITION"
- "OUTPUT-TEMPLATE")
-
- PREDICATE-PATTERN is the condition that must be true for the insn to
-be executed at runtime and should match a relational operator. One can
-use `match_operator' to match several relational operators at once.
-Any `match_operand' operands must have no more than one alternative.
-
- CONDITION is a C expression that must be true for the generated
-pattern to match.
-
- OUTPUT-TEMPLATE is a string similar to the `define_insn' output
-template (*note Output Template::), except that the `*' and `@' special
-cases do not apply. This is only useful if the assembly text for the
-predicate is a simple prefix to the main insn. In order to handle the
-general case, there is a global variable `current_insn_predicate' that
-will contain the entire predicate if the current insn is predicated,
-and will otherwise be `NULL'.
-
- When `define_cond_exec' is used, an implicit reference to the
-`predicable' instruction attribute is made. *Note Insn Attributes::.
-This attribute must be boolean (i.e. have exactly two elements in its
-LIST-OF-VALUES). Further, it must not be used with complex
-expressions. That is, the default and all uses in the insns must be a
-simple constant, not dependent on the alternative or anything else.
-
- For each `define_insn' for which the `predicable' attribute is true, a
-new `define_insn' pattern will be generated that matches a predicated
-version of the instruction. For example,
-
- (define_insn "addsi"
- [(set (match_operand:SI 0 "register_operand" "r")
- (plus:SI (match_operand:SI 1 "register_operand" "r")
- (match_operand:SI 2 "register_operand" "r")))]
- "TEST1"
- "add %2,%1,%0")
-
- (define_cond_exec
- [(ne (match_operand:CC 0 "register_operand" "c")
- (const_int 0))]
- "TEST2"
- "(%0)")
-
-generates a new pattern
-
- (define_insn ""
- [(cond_exec
- (ne (match_operand:CC 3 "register_operand" "c") (const_int 0))
- (set (match_operand:SI 0 "register_operand" "r")
- (plus:SI (match_operand:SI 1 "register_operand" "r")
- (match_operand:SI 2 "register_operand" "r"))))]
- "(TEST2) && (TEST1)"
- "(%3) add %2,%1,%0")
-
-
-File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Conditional Execution, Up: Machine Desc
-
-16.21 Constant Definitions
-==========================
-
-Using literal constants inside instruction patterns reduces legibility
-and can be a maintenance problem.
-
- To overcome this problem, you may use the `define_constants'
-expression. It contains a vector of name-value pairs. From that point
-on, wherever any of the names appears in the MD file, it is as if the
-corresponding value had been written instead. You may use
-`define_constants' multiple times; each appearance adds more constants
-to the table. It is an error to redefine a constant with a different
-value.
-
- To come back to the a29k load multiple example, instead of
-
- (define_insn ""
- [(match_parallel 0 "load_multiple_operation"
- [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
- (match_operand:SI 2 "memory_operand" "m"))
- (use (reg:SI 179))
- (clobber (reg:SI 179))])]
- ""
- "loadm 0,0,%1,%2")
-
- You could write:
-
- (define_constants [
- (R_BP 177)
- (R_FC 178)
- (R_CR 179)
- (R_Q 180)
- ])
-
- (define_insn ""
- [(match_parallel 0 "load_multiple_operation"
- [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
- (match_operand:SI 2 "memory_operand" "m"))
- (use (reg:SI R_CR))
- (clobber (reg:SI R_CR))])]
- ""
- "loadm 0,0,%1,%2")
-
- The constants that are defined with a define_constant are also output
-in the insn-codes.h header file as #defines.
-
- You can also use the machine description file to define enumerations.
-Like the constants defined by `define_constant', these enumerations are
-visible to both the machine description file and the main C code.
-
- The syntax is as follows:
-
- (define_c_enum "NAME" [
- VALUE0
- VALUE1
- ...
- VALUEN
- ])
-
- This definition causes the equivalent of the following C code to appear
-in `insn-constants.h':
-
- enum NAME {
- VALUE0 = 0,
- VALUE1 = 1,
- ...
- VALUEN = N
- };
- #define NUM_CNAME_VALUES (N + 1)
-
- where CNAME is the capitalized form of NAME. It also makes each
-VALUEI available in the machine description file, just as if it had
-been declared with:
-
- (define_constants [(VALUEI I)])
-
- Each VALUEI is usually an upper-case identifier and usually begins
-with CNAME.
-
- You can split the enumeration definition into as many statements as
-you like. The above example is directly equivalent to:
-
- (define_c_enum "NAME" [VALUE0])
- (define_c_enum "NAME" [VALUE1])
- ...
- (define_c_enum "NAME" [VALUEN])
-
- Splitting the enumeration helps to improve the modularity of each
-individual `.md' file. For example, if a port defines its
-synchronization instructions in a separate `sync.md' file, it is
-convenient to define all synchronization-specific enumeration values in
-`sync.md' rather than in the main `.md' file.
-
- Some enumeration names have special significance to GCC:
-
-`unspecv'
- If an enumeration called `unspecv' is defined, GCC will use it
- when printing out `unspec_volatile' expressions. For example:
-
- (define_c_enum "unspecv" [
- UNSPECV_BLOCKAGE
- ])
-
- causes GCC to print `(unspec_volatile ... 0)' as:
-
- (unspec_volatile ... UNSPECV_BLOCKAGE)
-
-`unspec'
- If an enumeration called `unspec' is defined, GCC will use it when
- printing out `unspec' expressions. GCC will also use it when
- printing out `unspec_volatile' expressions unless an `unspecv'
- enumeration is also defined. You can therefore decide whether to
- keep separate enumerations for volatile and non-volatile
- expressions or whether to use the same enumeration for both.
-
- Another way of defining an enumeration is to use `define_enum':
-
- (define_enum "NAME" [
- VALUE0
- VALUE1
- ...
- VALUEN
- ])
-
- This directive implies:
-
- (define_c_enum "NAME" [
- CNAME_CVALUE0
- CNAME_CVALUE1
- ...
- CNAME_CVALUEN
- ])
-
- where CVALUEI is the capitalized form of VALUEI. However, unlike
-`define_c_enum', the enumerations defined by `define_enum' can be used
-in attribute specifications (*note define_enum_attr::).
-
-
-File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc
-
-16.22 Iterators
-===============
-
-Ports often need to define similar patterns for more than one machine
-mode or for more than one rtx code. GCC provides some simple iterator
-facilities to make this process easier.
-
-* Menu:
-
-* Mode Iterators:: Generating variations of patterns for different modes.
-* Code Iterators:: Doing the same for codes.
-
-
-File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators
-
-16.22.1 Mode Iterators
-----------------------
-
-Ports often need to define similar patterns for two or more different
-modes. For example:
-
- * If a processor has hardware support for both single and double
- floating-point arithmetic, the `SFmode' patterns tend to be very
- similar to the `DFmode' ones.
-
- * If a port uses `SImode' pointers in one configuration and `DImode'
- pointers in another, it will usually have very similar `SImode'
- and `DImode' patterns for manipulating pointers.
-
- Mode iterators allow several patterns to be instantiated from one
-`.md' file template. They can be used with any type of rtx-based
-construct, such as a `define_insn', `define_split', or
-`define_peephole2'.
-
-* Menu:
-
-* Defining Mode Iterators:: Defining a new mode iterator.
-* Substitutions:: Combining mode iterators with substitutions
-* Examples:: Examples
-
-
-File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators
-
-16.22.1.1 Defining Mode Iterators
-.................................
-
-The syntax for defining a mode iterator is:
-
- (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")])
-
- This allows subsequent `.md' file constructs to use the mode suffix
-`:NAME'. Every construct that does so will be expanded N times, once
-with every use of `:NAME' replaced by `:MODE1', once with every use
-replaced by `:MODE2', and so on. In the expansion for a particular
-MODEI, every C condition will also require that CONDI be true.
-
- For example:
-
- (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
-
- defines a new mode suffix `:P'. Every construct that uses `:P' will
-be expanded twice, once with every `:P' replaced by `:SI' and once with
-every `:P' replaced by `:DI'. The `:SI' version will only apply if
-`Pmode == SImode' and the `:DI' version will only apply if `Pmode ==
-DImode'.
-
- As with other `.md' conditions, an empty string is treated as "always
-true". `(MODE "")' can also be abbreviated to `MODE'. For example:
-
- (define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
-
- means that the `:DI' expansion only applies if `TARGET_64BIT' but that
-the `:SI' expansion has no such constraint.
-
- Iterators are applied in the order they are defined. This can be
-significant if two iterators are used in a construct that requires
-substitutions. *Note Substitutions::.
-
-
-File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators
-
-16.22.1.2 Substitution in Mode Iterators
-........................................
-
-If an `.md' file construct uses mode iterators, each version of the
-construct will often need slightly different strings or modes. For
-example:
-
- * When a `define_expand' defines several `addM3' patterns (*note
- Standard Names::), each expander will need to use the appropriate
- mode name for M.
-
- * When a `define_insn' defines several instruction patterns, each
- instruction will often use a different assembler mnemonic.
-
- * When a `define_insn' requires operands with different modes, using
- an iterator for one of the operand modes usually requires a
- specific mode for the other operand(s).
-
- GCC supports such variations through a system of "mode attributes".
-There are two standard attributes: `mode', which is the name of the
-mode in lower case, and `MODE', which is the same thing in upper case.
-You can define other attributes using:
-
- (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")])
-
- where NAME is the name of the attribute and VALUEI is the value
-associated with MODEI.
-
- When GCC replaces some :ITERATOR with :MODE, it will scan each string
-and mode in the pattern for sequences of the form `<ITERATOR:ATTR>',
-where ATTR is the name of a mode attribute. If the attribute is
-defined for MODE, the whole `<...>' sequence will be replaced by the
-appropriate attribute value.
-
- For example, suppose an `.md' file has:
-
- (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
- (define_mode_attr load [(SI "lw") (DI "ld")])
-
- If one of the patterns that uses `:P' contains the string
-`"<P:load>\t%0,%1"', the `SI' version of that pattern will use
-`"lw\t%0,%1"' and the `DI' version will use `"ld\t%0,%1"'.
-
- Here is an example of using an attribute for a mode:
-
- (define_mode_iterator LONG [SI DI])
- (define_mode_attr SHORT [(SI "HI") (DI "SI")])
- (define_insn ...
- (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...)
-
- The `ITERATOR:' prefix may be omitted, in which case the substitution
-will be attempted for every iterator expansion.
-
-
-File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators
-
-16.22.1.3 Mode Iterator Examples
-................................
-
-Here is an example from the MIPS port. It defines the following modes
-and attributes (among others):
-
- (define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
- (define_mode_attr d [(SI "") (DI "d")])
-
- and uses the following template to define both `subsi3' and `subdi3':
-
- (define_insn "sub<mode>3"
- [(set (match_operand:GPR 0 "register_operand" "=d")
- (minus:GPR (match_operand:GPR 1 "register_operand" "d")
- (match_operand:GPR 2 "register_operand" "d")))]
- ""
- "<d>subu\t%0,%1,%2"
- [(set_attr "type" "arith")
- (set_attr "mode" "<MODE>")])
-
- This is exactly equivalent to:
-
- (define_insn "subsi3"
- [(set (match_operand:SI 0 "register_operand" "=d")
- (minus:SI (match_operand:SI 1 "register_operand" "d")
- (match_operand:SI 2 "register_operand" "d")))]
- ""
- "subu\t%0,%1,%2"
- [(set_attr "type" "arith")
- (set_attr "mode" "SI")])
-
- (define_insn "subdi3"
- [(set (match_operand:DI 0 "register_operand" "=d")
- (minus:DI (match_operand:DI 1 "register_operand" "d")
- (match_operand:DI 2 "register_operand" "d")))]
- ""
- "dsubu\t%0,%1,%2"
- [(set_attr "type" "arith")
- (set_attr "mode" "DI")])
-
-
-File: gccint.info, Node: Code Iterators, Prev: Mode Iterators, Up: Iterators
-
-16.22.2 Code Iterators
-----------------------
-
-Code iterators operate in a similar way to mode iterators. *Note Mode
-Iterators::.
-
- The construct:
-
- (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")])
-
- defines a pseudo rtx code NAME that can be instantiated as CODEI if
-condition CONDI is true. Each CODEI must have the same rtx format.
-*Note RTL Classes::.
-
- As with mode iterators, each pattern that uses NAME will be expanded N
-times, once with all uses of NAME replaced by CODE1, once with all uses
-replaced by CODE2, and so on. *Note Defining Mode Iterators::.
-
- It is possible to define attributes for codes as well as for modes.
-There are two standard code attributes: `code', the name of the code in
-lower case, and `CODE', the name of the code in upper case. Other
-attributes are defined using:
-
- (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")])
-
- Here's an example of code iterators in action, taken from the MIPS
-port:
-
- (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt
- eq ne gt ge lt le gtu geu ltu leu])
-
- (define_expand "b<code>"
- [(set (pc)
- (if_then_else (any_cond:CC (cc0)
- (const_int 0))
- (label_ref (match_operand 0 ""))
- (pc)))]
- ""
- {
- gen_conditional_branch (operands, <CODE>);
- DONE;
- })
-
- This is equivalent to:
-
- (define_expand "bunordered"
- [(set (pc)
- (if_then_else (unordered:CC (cc0)
- (const_int 0))
- (label_ref (match_operand 0 ""))
- (pc)))]
- ""
- {
- gen_conditional_branch (operands, UNORDERED);
- DONE;
- })
-
- (define_expand "bordered"
- [(set (pc)
- (if_then_else (ordered:CC (cc0)
- (const_int 0))
- (label_ref (match_operand 0 ""))
- (pc)))]
- ""
- {
- gen_conditional_branch (operands, ORDERED);
- DONE;
- })
-
- ...
-
-
-File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top
-
-17 Target Description Macros and Functions
-******************************************
-
-In addition to the file `MACHINE.md', a machine description includes a
-C header file conventionally given the name `MACHINE.h' and a C source
-file named `MACHINE.c'. The header file defines numerous macros that
-convey the information about the target machine that does not fit into
-the scheme of the `.md' file. The file `tm.h' should be a link to
-`MACHINE.h'. The header file `config.h' includes `tm.h' and most
-compiler source files include `config.h'. The source file defines a
-variable `targetm', which is a structure containing pointers to
-functions and data relating to the target machine. `MACHINE.c' should
-also contain their definitions, if they are not defined elsewhere in
-GCC, and other functions called through the macros defined in the `.h'
-file.
-
-* Menu:
-
-* Target Structure:: The `targetm' variable.
-* Driver:: Controlling how the driver runs the compilation passes.
-* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'.
-* Per-Function Data:: Defining data structures for per-function information.
-* Storage Layout:: Defining sizes and alignments of data.
-* Type Layout:: Defining sizes and properties of basic user data types.
-* Registers:: Naming and describing the hardware registers.
-* Register Classes:: Defining the classes of hardware registers.
-* Old Constraints:: The old way to define machine-specific constraints.
-* Stack and Calling:: Defining which way the stack grows and by how much.
-* Varargs:: Defining the varargs macros.
-* Trampolines:: Code set up at run time to enter a nested function.
-* Library Calls:: Controlling how library routines are implicitly called.
-* Addressing Modes:: Defining addressing modes valid for memory operands.
-* Anchored Addresses:: Defining how `-fsection-anchors' should work.
-* Condition Code:: Defining how insns update the condition code.
-* Costs:: Defining relative costs of different operations.
-* Scheduling:: Adjusting the behavior of the instruction scheduler.
-* Sections:: Dividing storage into text, data, and other sections.
-* PIC:: Macros for position independent code.
-* Assembler Format:: Defining how to write insns and pseudo-ops to output.
-* Debugging Info:: Defining the format of debugging output.
-* Floating Point:: Handling floating point for cross-compilers.
-* Mode Switching:: Insertion of mode-switching instructions.
-* Target Attributes:: Defining target-specific uses of `__attribute__'.
-* Emulated TLS:: Emulated TLS support.
-* MIPS Coprocessors:: MIPS coprocessor support and how to customize it.
-* PCH Target:: Validity checking for precompiled headers.
-* C++ ABI:: Controlling C++ ABI changes.
-* Named Address Spaces:: Adding support for named address spaces
-* Misc:: Everything else.
-
-
-File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros
-
-17.1 The Global `targetm' Variable
-==================================
-
- -- Variable: struct gcc_target targetm
- The target `.c' file must define the global `targetm' variable
- which contains pointers to functions and data relating to the
- target machine. The variable is declared in `target.h';
- `target-def.h' defines the macro `TARGET_INITIALIZER' which is
- used to initialize the variable, and macros for the default
- initializers for elements of the structure. The `.c' file should
- override those macros for which the default definition is
- inappropriate. For example:
- #include "target.h"
- #include "target-def.h"
-
- /* Initialize the GCC target structure. */
-
- #undef TARGET_COMP_TYPE_ATTRIBUTES
- #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes
-
- struct gcc_target targetm = TARGET_INITIALIZER;
-
-Where a macro should be defined in the `.c' file in this manner to form
-part of the `targetm' structure, it is documented below as a "Target
-Hook" with a prototype. Many macros will change in future from being
-defined in the `.h' file to being part of the `targetm' structure.
-
-
-File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros
-
-17.2 Controlling the Compilation Driver, `gcc'
-==============================================
-
-You can control the compilation driver.
-
- -- Macro: DRIVER_SELF_SPECS
- A list of specs for the driver itself. It should be a suitable
- initializer for an array of strings, with no surrounding braces.
-
- The driver applies these specs to its own command line between
- loading default `specs' files (but not command-line specified
- ones) and choosing the multilib directory or running any
- subcommands. It applies them in the order given, so each spec can
- depend on the options added by earlier ones. It is also possible
- to remove options using `%<OPTION' in the usual way.
-
- This macro can be useful when a port has several interdependent
- target options. It provides a way of standardizing the command
- line so that the other specs are easier to write.
-
- Do not define this macro if it does not need to do anything.
-
- -- Macro: OPTION_DEFAULT_SPECS
- A list of specs used to support configure-time default options
- (i.e. `--with' options) in the driver. It should be a suitable
- initializer for an array of structures, each containing two
- strings, without the outermost pair of surrounding braces.
-
- The first item in the pair is the name of the default. This must
- match the code in `config.gcc' for the target. The second item is
- a spec to apply if a default with this name was specified. The
- string `%(VALUE)' in the spec will be replaced by the value of the
- default everywhere it occurs.
-
- The driver will apply these specs to its own command line between
- loading default `specs' files and processing `DRIVER_SELF_SPECS',
- using the same mechanism as `DRIVER_SELF_SPECS'.
-
- Do not define this macro if it does not need to do anything.
-
- -- Macro: CPP_SPEC
- A C string constant that tells the GCC driver program options to
- pass to CPP. It can also specify how to translate options you
- give to GCC into options for GCC to pass to the CPP.
-
- Do not define this macro if it does not need to do anything.
-
- -- Macro: CPLUSPLUS_CPP_SPEC
- This macro is just like `CPP_SPEC', but is used for C++, rather
- than C. If you do not define this macro, then the value of
- `CPP_SPEC' (if any) will be used instead.
-
- -- Macro: CC1_SPEC
- A C string constant that tells the GCC driver program options to
- pass to `cc1', `cc1plus', `f771', and the other language front
- ends. It can also specify how to translate options you give to
- GCC into options for GCC to pass to front ends.
-
- Do not define this macro if it does not need to do anything.
-
- -- Macro: CC1PLUS_SPEC
- A C string constant that tells the GCC driver program options to
- pass to `cc1plus'. It can also specify how to translate options
- you give to GCC into options for GCC to pass to the `cc1plus'.
-
- Do not define this macro if it does not need to do anything. Note
- that everything defined in CC1_SPEC is already passed to `cc1plus'
- so there is no need to duplicate the contents of CC1_SPEC in
- CC1PLUS_SPEC.
-
- -- Macro: ASM_SPEC
- A C string constant that tells the GCC driver program options to
- pass to the assembler. It can also specify how to translate
- options you give to GCC into options for GCC to pass to the
- assembler. See the file `sun3.h' for an example of this.
-
- Do not define this macro if it does not need to do anything.
-
- -- Macro: ASM_FINAL_SPEC
- A C string constant that tells the GCC driver program how to run
- any programs which cleanup after the normal assembler. Normally,
- this is not needed. See the file `mips.h' for an example of this.
-
- Do not define this macro if it does not need to do anything.
-
- -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT
- Define this macro, with no value, if the driver should give the
- assembler an argument consisting of a single dash, `-', to
- instruct it to read from its standard input (which will be a pipe
- connected to the output of the compiler proper). This argument is
- given after any `-o' option specifying the name of the output file.
-
- If you do not define this macro, the assembler is assumed to read
- its standard input if given no non-option arguments. If your
- assembler cannot read standard input at all, use a `%{pipe:%e}'
- construct; see `mips.h' for instance.
-
- -- Macro: LINK_SPEC
- A C string constant that tells the GCC driver program options to
- pass to the linker. It can also specify how to translate options
- you give to GCC into options for GCC to pass to the linker.
-
- Do not define this macro if it does not need to do anything.
-
- -- Macro: LIB_SPEC
- Another C string constant used much like `LINK_SPEC'. The
- difference between the two is that `LIB_SPEC' is used at the end
- of the command given to the linker.
-
- If this macro is not defined, a default is provided that loads the
- standard C library from the usual place. See `gcc.c'.
-
- -- Macro: LIBGCC_SPEC
- Another C string constant that tells the GCC driver program how
- and when to place a reference to `libgcc.a' into the linker
- command line. This constant is placed both before and after the
- value of `LIB_SPEC'.
-
- If this macro is not defined, the GCC driver provides a default
- that passes the string `-lgcc' to the linker.
-
- -- Macro: REAL_LIBGCC_SPEC
- By default, if `ENABLE_SHARED_LIBGCC' is defined, the
- `LIBGCC_SPEC' is not directly used by the driver program but is
- instead modified to refer to different versions of `libgcc.a'
- depending on the values of the command line flags `-static',
- `-shared', `-static-libgcc', and `-shared-libgcc'. On targets
- where these modifications are inappropriate, define
- `REAL_LIBGCC_SPEC' instead. `REAL_LIBGCC_SPEC' tells the driver
- how to place a reference to `libgcc' on the link command line,
- but, unlike `LIBGCC_SPEC', it is used unmodified.
-
- -- Macro: USE_LD_AS_NEEDED
- A macro that controls the modifications to `LIBGCC_SPEC' mentioned
- in `REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that
- uses -as-needed and the shared libgcc in place of the static
- exception handler library, when linking without any of `-static',
- `-static-libgcc', or `-shared-libgcc'.
-
- -- Macro: LINK_EH_SPEC
- If defined, this C string constant is added to `LINK_SPEC'. When
- `USE_LD_AS_NEEDED' is zero or undefined, it also affects the
- modifications to `LIBGCC_SPEC' mentioned in `REAL_LIBGCC_SPEC'.
-
- -- Macro: STARTFILE_SPEC
- Another C string constant used much like `LINK_SPEC'. The
- difference between the two is that `STARTFILE_SPEC' is used at the
- very beginning of the command given to the linker.
-
- If this macro is not defined, a default is provided that loads the
- standard C startup file from the usual place. See `gcc.c'.
-
- -- Macro: ENDFILE_SPEC
- Another C string constant used much like `LINK_SPEC'. The
- difference between the two is that `ENDFILE_SPEC' is used at the
- very end of the command given to the linker.
-
- Do not define this macro if it does not need to do anything.
-
- -- Macro: THREAD_MODEL_SPEC
- GCC `-v' will print the thread model GCC was configured to use.
- However, this doesn't work on platforms that are multilibbed on
- thread models, such as AIX 4.3. On such platforms, define
- `THREAD_MODEL_SPEC' such that it evaluates to a string without
- blanks that names one of the recognized thread models. `%*', the
- default value of this macro, will expand to the value of
- `thread_file' set in `config.gcc'.
-
- -- Macro: SYSROOT_SUFFIX_SPEC
- Define this macro to add a suffix to the target sysroot when GCC is
- configured with a sysroot. This will cause GCC to search for
- usr/lib, et al, within sysroot+suffix.
-
- -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC
- Define this macro to add a headers_suffix to the target sysroot
- when GCC is configured with a sysroot. This will cause GCC to
- pass the updated sysroot+headers_suffix to CPP, causing it to
- search for usr/include, et al, within sysroot+headers_suffix.
-
- -- Macro: EXTRA_SPECS
- Define this macro to provide additional specifications to put in
- the `specs' file that can be used in various specifications like
- `CC1_SPEC'.
-
- The definition should be an initializer for an array of structures,
- containing a string constant, that defines the specification name,
- and a string constant that provides the specification.
-
- Do not define this macro if it does not need to do anything.
-
- `EXTRA_SPECS' is useful when an architecture contains several
- related targets, which have various `..._SPECS' which are similar
- to each other, and the maintainer would like one central place to
- keep these definitions.
-
- For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to
- define either `_CALL_SYSV' when the System V calling sequence is
- used or `_CALL_AIX' when the older AIX-based calling sequence is
- used.
-
- The `config/rs6000/rs6000.h' target file defines:
-
- #define EXTRA_SPECS \
- { "cpp_sysv_default", CPP_SYSV_DEFAULT },
-
- #define CPP_SYS_DEFAULT ""
-
- The `config/rs6000/sysv.h' target file defines:
- #undef CPP_SPEC
- #define CPP_SPEC \
- "%{posix: -D_POSIX_SOURCE } \
- %{mcall-sysv: -D_CALL_SYSV } \
- %{!mcall-sysv: %(cpp_sysv_default) } \
- %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}"
-
- #undef CPP_SYSV_DEFAULT
- #define CPP_SYSV_DEFAULT "-D_CALL_SYSV"
-
- while the `config/rs6000/eabiaix.h' target file defines
- `CPP_SYSV_DEFAULT' as:
-
- #undef CPP_SYSV_DEFAULT
- #define CPP_SYSV_DEFAULT "-D_CALL_AIX"
-
- -- Macro: LINK_LIBGCC_SPECIAL_1
- Define this macro if the driver program should find the library
- `libgcc.a'. If you do not define this macro, the driver program
- will pass the argument `-lgcc' to tell the linker to do the search.
-
- -- Macro: LINK_GCC_C_SEQUENCE_SPEC
- The sequence in which libgcc and libc are specified to the linker.
- By default this is `%G %L %G'.
-
- -- Macro: LINK_COMMAND_SPEC
- A C string constant giving the complete command line need to
- execute the linker. When you do this, you will need to update
- your port each time a change is made to the link command line
- within `gcc.c'. Therefore, define this macro only if you need to
- completely redefine the command line for invoking the linker and
- there is no other way to accomplish the effect you need.
- Overriding this macro may be avoidable by overriding
- `LINK_GCC_C_SEQUENCE_SPEC' instead.
-
- -- Macro: LINK_ELIMINATE_DUPLICATE_LDIRECTORIES
- A nonzero value causes `collect2' to remove duplicate
- `-LDIRECTORY' search directories from linking commands. Do not
- give it a nonzero value if removing duplicate search directories
- changes the linker's semantics.
-
- -- Macro: MULTILIB_DEFAULTS
- Define this macro as a C expression for the initializer of an
- array of string to tell the driver program which options are
- defaults for this target and thus do not need to be handled
- specially when using `MULTILIB_OPTIONS'.
-
- Do not define this macro if `MULTILIB_OPTIONS' is not defined in
- the target makefile fragment or if none of the options listed in
- `MULTILIB_OPTIONS' are set by default. *Note Target Fragment::.
-
- -- Macro: RELATIVE_PREFIX_NOT_LINKDIR
- Define this macro to tell `gcc' that it should only translate a
- `-B' prefix into a `-L' linker option if the prefix indicates an
- absolute file name.
-
- -- Macro: MD_EXEC_PREFIX
- If defined, this macro is an additional prefix to try after
- `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the
- compiler is built as a cross compiler. If you define
- `MD_EXEC_PREFIX', then be sure to add it to the list of
- directories used to find the assembler in `configure.in'.
-
- -- Macro: STANDARD_STARTFILE_PREFIX
- Define this macro as a C string constant if you wish to override
- the standard choice of `libdir' as the default prefix to try when
- searching for startup files such as `crt0.o'.
- `STANDARD_STARTFILE_PREFIX' is not searched when the compiler is
- built as a cross compiler.
-
- -- Macro: STANDARD_STARTFILE_PREFIX_1
- Define this macro as a C string constant if you wish to override
- the standard choice of `/lib' as a prefix to try after the default
- prefix when searching for startup files such as `crt0.o'.
- `STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is
- built as a cross compiler.
-
- -- Macro: STANDARD_STARTFILE_PREFIX_2
- Define this macro as a C string constant if you wish to override
- the standard choice of `/lib' as yet another prefix to try after
- the default prefix when searching for startup files such as
- `crt0.o'. `STANDARD_STARTFILE_PREFIX_2' is not searched when the
- compiler is built as a cross compiler.
-
- -- Macro: MD_STARTFILE_PREFIX
- If defined, this macro supplies an additional prefix to try after
- the standard prefixes. `MD_EXEC_PREFIX' is not searched when the
- compiler is built as a cross compiler.
-
- -- Macro: MD_STARTFILE_PREFIX_1
- If defined, this macro supplies yet another prefix to try after the
- standard prefixes. It is not searched when the compiler is built
- as a cross compiler.
-
- -- Macro: INIT_ENVIRONMENT
- Define this macro as a C string constant if you wish to set
- environment variables for programs called by the driver, such as
- the assembler and loader. The driver passes the value of this
- macro to `putenv' to initialize the necessary environment
- variables.
-
- -- Macro: LOCAL_INCLUDE_DIR
- Define this macro as a C string constant if you wish to override
- the standard choice of `/usr/local/include' as the default prefix
- to try when searching for local header files. `LOCAL_INCLUDE_DIR'
- comes before `SYSTEM_INCLUDE_DIR' in the search order.
-
- Cross compilers do not search either `/usr/local/include' or its
- replacement.
-
- -- Macro: SYSTEM_INCLUDE_DIR
- Define this macro as a C string constant if you wish to specify a
- system-specific directory to search for header files before the
- standard directory. `SYSTEM_INCLUDE_DIR' comes before
- `STANDARD_INCLUDE_DIR' in the search order.
-
- Cross compilers do not use this macro and do not search the
- directory specified.
-
- -- Macro: STANDARD_INCLUDE_DIR
- Define this macro as a C string constant if you wish to override
- the standard choice of `/usr/include' as the default prefix to try
- when searching for header files.
-
- Cross compilers ignore this macro and do not search either
- `/usr/include' or its replacement.
-
- -- Macro: STANDARD_INCLUDE_COMPONENT
- The "component" corresponding to `STANDARD_INCLUDE_DIR'. See
- `INCLUDE_DEFAULTS', below, for the description of components. If
- you do not define this macro, no component is used.
-
- -- Macro: INCLUDE_DEFAULTS
- Define this macro if you wish to override the entire default
- search path for include files. For a native compiler, the default
- search path usually consists of `GCC_INCLUDE_DIR',
- `LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR',
- `GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition,
- `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined
- automatically by `Makefile', and specify private search areas for
- GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++
- programs.
-
- The definition should be an initializer for an array of structures.
- Each array element should have four elements: the directory name (a
- string constant), the component name (also a string constant), a
- flag for C++-only directories, and a flag showing that the
- includes in the directory don't need to be wrapped in `extern `C''
- when compiling C++. Mark the end of the array with a null element.
-
- The component name denotes what GNU package the include file is
- part of, if any, in all uppercase letters. For example, it might
- be `GCC' or `BINUTILS'. If the package is part of a
- vendor-supplied operating system, code the component name as `0'.
-
- For example, here is the definition used for VAX/VMS:
-
- #define INCLUDE_DEFAULTS \
- { \
- { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \
- { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \
- { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \
- { ".", 0, 0, 0}, \
- { 0, 0, 0, 0} \
- }
-
- Here is the order of prefixes tried for exec files:
-
- 1. Any prefixes specified by the user with `-B'.
-
- 2. The environment variable `GCC_EXEC_PREFIX' or, if `GCC_EXEC_PREFIX'
- is not set and the compiler has not been installed in the
- configure-time PREFIX, the location in which the compiler has
- actually been installed.
-
- 3. The directories specified by the environment variable
- `COMPILER_PATH'.
-
- 4. The macro `STANDARD_EXEC_PREFIX', if the compiler has been
- installed in the configured-time PREFIX.
-
- 5. The location `/usr/libexec/gcc/', but only if this is a native
- compiler.
-
- 6. The location `/usr/lib/gcc/', but only if this is a native
- compiler.
-
- 7. The macro `MD_EXEC_PREFIX', if defined, but only if this is a
- native compiler.
-
- Here is the order of prefixes tried for startfiles:
-
- 1. Any prefixes specified by the user with `-B'.
-
- 2. The environment variable `GCC_EXEC_PREFIX' or its automatically
- determined value based on the installed toolchain location.
-
- 3. The directories specified by the environment variable
- `LIBRARY_PATH' (or port-specific name; native only, cross
- compilers do not use this).
-
- 4. The macro `STANDARD_EXEC_PREFIX', but only if the toolchain is
- installed in the configured PREFIX or this is a native compiler.
-
- 5. The location `/usr/lib/gcc/', but only if this is a native
- compiler.
-
- 6. The macro `MD_EXEC_PREFIX', if defined, but only if this is a
- native compiler.
-
- 7. The macro `MD_STARTFILE_PREFIX', if defined, but only if this is a
- native compiler, or we have a target system root.
-
- 8. The macro `MD_STARTFILE_PREFIX_1', if defined, but only if this is
- a native compiler, or we have a target system root.
-
- 9. The macro `STANDARD_STARTFILE_PREFIX', with any sysroot
- modifications. If this path is relative it will be prefixed by
- `GCC_EXEC_PREFIX' and the machine suffix or `STANDARD_EXEC_PREFIX'
- and the machine suffix.
-
- 10. The macro `STANDARD_STARTFILE_PREFIX_1', but only if this is a
- native compiler, or we have a target system root. The default for
- this macro is `/lib/'.
-
- 11. The macro `STANDARD_STARTFILE_PREFIX_2', but only if this is a
- native compiler, or we have a target system root. The default for
- this macro is `/usr/lib/'.
-
-
-File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros
-
-17.3 Run-time Target Specification
-==================================
-
-Here are run-time target specifications.
-
- -- Macro: TARGET_CPU_CPP_BUILTINS ()
- This function-like macro expands to a block of code that defines
- built-in preprocessor macros and assertions for the target CPU,
- using the functions `builtin_define', `builtin_define_std' and
- `builtin_assert'. When the front end calls this macro it provides
- a trailing semicolon, and since it has finished command line
- option processing your code can use those results freely.
-
- `builtin_assert' takes a string in the form you pass to the
- command-line option `-A', such as `cpu=mips', and creates the
- assertion. `builtin_define' takes a string in the form accepted
- by option `-D' and unconditionally defines the macro.
-
- `builtin_define_std' takes a string representing the name of an
- object-like macro. If it doesn't lie in the user's namespace,
- `builtin_define_std' defines it unconditionally. Otherwise, it
- defines a version with two leading underscores, and another version
- with two leading and trailing underscores, and defines the original
- only if an ISO standard was not requested on the command line. For
- example, passing `unix' defines `__unix', `__unix__' and possibly
- `unix'; passing `_mips' defines `__mips', `__mips__' and possibly
- `_mips', and passing `_ABI64' defines only `_ABI64'.
-
- You can also test for the C dialect being compiled. The variable
- `c_language' is set to one of `clk_c', `clk_cplusplus' or
- `clk_objective_c'. Note that if we are preprocessing assembler,
- this variable will be `clk_c' but the function-like macro
- `preprocessing_asm_p()' will return true, so you might want to
- check for that first. If you need to check for strict ANSI, the
- variable `flag_iso' can be used. The function-like macro
- `preprocessing_trad_p()' can be used to check for traditional
- preprocessing.
-
- -- Macro: TARGET_OS_CPP_BUILTINS ()
- Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional
- and is used for the target operating system instead.
-
- -- Macro: TARGET_OBJFMT_CPP_BUILTINS ()
- Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional
- and is used for the target object format. `elfos.h' uses this
- macro to define `__ELF__', so you probably do not need to define
- it yourself.
-
- -- Variable: extern int target_flags
- This variable is declared in `options.h', which is included before
- any target-specific headers.
-
- -- Target Hook: int TARGET_DEFAULT_TARGET_FLAGS
- This variable specifies the initial value of `target_flags'. Its
- default setting is 0.
-
- -- Target Hook: bool TARGET_HANDLE_OPTION (size_t CODE, const char
- *ARG, int VALUE)
- This hook is called whenever the user specifies one of the
- target-specific options described by the `.opt' definition files
- (*note Options::). It has the opportunity to do some
- option-specific processing and should return true if the option is
- valid. The default definition does nothing but return true.
-
- CODE specifies the `OPT_NAME' enumeration value associated with
- the selected option; NAME is just a rendering of the option name
- in which non-alphanumeric characters are replaced by underscores.
- ARG specifies the string argument and is null if no argument was
- given. If the option is flagged as a `UInteger' (*note Option
- properties::), VALUE is the numeric value of the argument.
- Otherwise VALUE is 1 if the positive form of the option was used
- and 0 if the "no-" form was.
-
- -- Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char
- *ARG, int VALUE)
- This target hook is called whenever the user specifies one of the
- target-specific C language family options described by the `.opt'
- definition files(*note Options::). It has the opportunity to do
- some option-specific processing and should return true if the
- option is valid. The arguments are like for
- `TARGET_HANDLE_OPTION'. The default definition does nothing but
- return false.
-
- In general, you should use `TARGET_HANDLE_OPTION' to handle
- options. However, if processing an option requires routines that
- are only available in the C (and related language) front ends,
- then you should use `TARGET_HANDLE_C_OPTION' instead.
-
- -- Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree STRING)
- Targets may provide a string object type that can be used within
- and between C, C++ and their respective Objective-C dialects. A
- string object might, for example, embed encoding and length
- information. These objects are considered opaque to the compiler
- and handled as references. An ideal implementation makes the
- composition of the string object match that of the Objective-C
- `NSString' (`NXString' for GNUStep), allowing efficient
- interworking between C-only and Objective-C code. If a target
- implements string objects then this hook should return a reference
- to such an object constructed from the normal `C' string
- representation provided in STRING. At present, the hook is used by
- Objective-C only, to obtain a common-format string object when the
- target provides one.
-
- -- Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree
- STRINGREF)
- If a target implements string objects then this hook should return
- `true' if STRINGREF is a valid reference to such an object.
-
- -- Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree
- FORMAT_ARG, tree ARGS_LIST)
- If a target implements string objects then this hook should should
- provide a facility to check the function arguments in ARGS_LIST
- against the format specifiers in FORMAT_ARG where the type of
- FORMAT_ARG is one recognized as a valid string reference type.
-
- -- Macro: TARGET_VERSION
- This macro is a C statement to print on `stderr' a string
- describing the particular machine description choice. Every
- machine description should define `TARGET_VERSION'. For example:
-
- #ifdef MOTOROLA
- #define TARGET_VERSION \
- fprintf (stderr, " (68k, Motorola syntax)");
- #else
- #define TARGET_VERSION \
- fprintf (stderr, " (68k, MIT syntax)");
- #endif
-
- -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void)
- This target function is similar to the hook
- `TARGET_OPTION_OVERRIDE' but is called when the optimize level is
- changed via an attribute or pragma or when it is reset at the end
- of the code affected by the attribute or pragma. It is not called
- at the beginning of compilation when `TARGET_OPTION_OVERRIDE' is
- called so if you want to perform these actions then, you should
- have `TARGET_OPTION_OVERRIDE' call
- `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'.
-
- -- Macro: C_COMMON_OVERRIDE_OPTIONS
- This is similar to the `TARGET_OPTION_OVERRIDE' hook but is only
- used in the C language frontends (C, Objective-C, C++,
- Objective-C++) and so can be used to alter option flag variables
- which only exist in those frontends.
-
- -- Target Hook: const struct default_options *
-TARGET_OPTION_OPTIMIZATION_TABLE
- Some machines may desire to change what optimizations are
- performed for various optimization levels. This variable, if
- defined, describes options to enable at particular sets of
- optimization levels. These options are processed once just after
- the optimization level is determined and before the remainder of
- the command options have been parsed, so may be overridden by other
- options passed explicitly.
-
- This processing is run once at program startup and when the
- optimization options are changed via `#pragma GCC optimize' or by
- using the `optimize' attribute.
-
- -- Target Hook: void TARGET_OPTION_INIT_STRUCT (struct gcc_options
- *OPTS)
- Set target-dependent initial values of fields in OPTS.
-
- -- Target Hook: void TARGET_OPTION_DEFAULT_PARAMS (void)
- Set target-dependent default values for `--param' settings, using
- calls to `set_default_param_value'.
-
- -- Target Hook: void TARGET_HELP (void)
- This hook is called in response to the user invoking
- `--target-help' on the command line. It gives the target a chance
- to display extra information on the target specific command line
- options found in its `.opt' file.
-
- -- Macro: SWITCHABLE_TARGET
- Some targets need to switch between substantially different
- subtargets during compilation. For example, the MIPS target has
- one subtarget for the traditional MIPS architecture and another
- for MIPS16. Source code can switch between these two
- subarchitectures using the `mips16' and `nomips16' attributes.
-
- Such subtargets can differ in things like the set of available
- registers, the set of available instructions, the costs of various
- operations, and so on. GCC caches a lot of this type of
- information in global variables, and recomputing them for each
- subtarget takes a significant amount of time. The compiler
- therefore provides a facility for maintaining several versions of
- the global variables and quickly switching between them; see
- `target-globals.h' for details.
-
- Define this macro to 1 if your target needs this facility. The
- default is 0.
-
-
-File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros
-
-17.4 Defining data structures for per-function information.
-===========================================================
-
-If the target needs to store information on a per-function basis, GCC
-provides a macro and a couple of variables to allow this. Note, just
-using statics to store the information is a bad idea, since GCC supports
-nested functions, so you can be halfway through encoding one function
-when another one comes along.
-
- GCC defines a data structure called `struct function' which contains
-all of the data specific to an individual function. This structure
-contains a field called `machine' whose type is `struct
-machine_function *', which can be used by targets to point to their own
-specific data.
-
- If a target needs per-function specific data it should define the type
-`struct machine_function' and also the macro `INIT_EXPANDERS'. This
-macro should be used to initialize the function pointer
-`init_machine_status'. This pointer is explained below.
-
- One typical use of per-function, target specific data is to create an
-RTX to hold the register containing the function's return address. This
-RTX can then be used to implement the `__builtin_return_address'
-function, for level 0.
-
- Note--earlier implementations of GCC used a single data area to hold
-all of the per-function information. Thus when processing of a nested
-function began the old per-function data had to be pushed onto a stack,
-and when the processing was finished, it had to be popped off the
-stack. GCC used to provide function pointers called
-`save_machine_status' and `restore_machine_status' to handle the saving
-and restoring of the target specific information. Since the single
-data area approach is no longer used, these pointers are no longer
-supported.
-
- -- Macro: INIT_EXPANDERS
- Macro called to initialize any target specific information. This
- macro is called once per function, before generation of any RTL
- has begun. The intention of this macro is to allow the
- initialization of the function pointer `init_machine_status'.
-
- -- Variable: void (*)(struct function *) init_machine_status
- If this function pointer is non-`NULL' it will be called once per
- function, before function compilation starts, in order to allow the
- target to perform any target specific initialization of the
- `struct function' structure. It is intended that this would be
- used to initialize the `machine' of that structure.
-
- `struct machine_function' structures are expected to be freed by
- GC. Generally, any memory that they reference must be allocated
- by using GC allocation, including the structure itself.
-
-
-File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros
-
-17.5 Storage Layout
-===================
-
-Note that the definitions of the macros in this table which are sizes or
-alignments measured in bits do not need to be constant. They can be C
-expressions that refer to static variables, such as the `target_flags'.
-*Note Run-time Target::.
-
- -- Macro: BITS_BIG_ENDIAN
- Define this macro to have the value 1 if the most significant bit
- in a byte has the lowest number; otherwise define it to have the
- value zero. This means that bit-field instructions count from the
- most significant bit. If the machine has no bit-field
- instructions, then this must still be defined, but it doesn't
- matter which value it is defined to. This macro need not be a
- constant.
-
- This macro does not affect the way structure fields are packed into
- bytes or words; that is controlled by `BYTES_BIG_ENDIAN'.
-
- -- Macro: BYTES_BIG_ENDIAN
- Define this macro to have the value 1 if the most significant byte
- in a word has the lowest number. This macro need not be a
- constant.
-
- -- Macro: WORDS_BIG_ENDIAN
- Define this macro to have the value 1 if, in a multiword object,
- the most significant word has the lowest number. This applies to
- both memory locations and registers; GCC fundamentally assumes
- that the order of words in memory is the same as the order in
- registers. This macro need not be a constant.
-
- -- Macro: FLOAT_WORDS_BIG_ENDIAN
- Define this macro to have the value 1 if `DFmode', `XFmode' or
- `TFmode' floating point numbers are stored in memory with the word
- containing the sign bit at the lowest address; otherwise define it
- to have the value 0. This macro need not be a constant.
-
- You need not define this macro if the ordering is the same as for
- multi-word integers.
-
- -- Macro: BITS_PER_UNIT
- Define this macro to be the number of bits in an addressable
- storage unit (byte). If you do not define this macro the default
- is 8.
-
- -- Macro: BITS_PER_WORD
- Number of bits in a word. If you do not define this macro, the
- default is `BITS_PER_UNIT * UNITS_PER_WORD'.
-
- -- Macro: MAX_BITS_PER_WORD
- Maximum number of bits in a word. If this is undefined, the
- default is `BITS_PER_WORD'. Otherwise, it is the constant value
- that is the largest value that `BITS_PER_WORD' can have at
- run-time.
-
- -- Macro: UNITS_PER_WORD
- Number of storage units in a word; normally the size of a
- general-purpose register, a power of two from 1 or 8.
-
- -- Macro: MIN_UNITS_PER_WORD
- Minimum number of units in a word. If this is undefined, the
- default is `UNITS_PER_WORD'. Otherwise, it is the constant value
- that is the smallest value that `UNITS_PER_WORD' can have at
- run-time.
-
- -- Macro: POINTER_SIZE
- Width of a pointer, in bits. You must specify a value no wider
- than the width of `Pmode'. If it is not equal to the width of
- `Pmode', you must define `POINTERS_EXTEND_UNSIGNED'. If you do
- not specify a value the default is `BITS_PER_WORD'.
-
- -- Macro: POINTERS_EXTEND_UNSIGNED
- A C expression that determines how pointers should be extended from
- `ptr_mode' to either `Pmode' or `word_mode'. It is greater than
- zero if pointers should be zero-extended, zero if they should be
- sign-extended, and negative if some other sort of conversion is
- needed. In the last case, the extension is done by the target's
- `ptr_extend' instruction.
-
- You need not define this macro if the `ptr_mode', `Pmode' and
- `word_mode' are all the same width.
-
- -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE)
- A macro to update M and UNSIGNEDP when an object whose type is
- TYPE and which has the specified mode and signedness is to be
- stored in a register. This macro is only called when TYPE is a
- scalar type.
-
- On most RISC machines, which only have operations that operate on
- a full register, define this macro to set M to `word_mode' if M is
- an integer mode narrower than `BITS_PER_WORD'. In most cases,
- only integer modes should be widened because wider-precision
- floating-point operations are usually more expensive than their
- narrower counterparts.
-
- For most machines, the macro definition does not change UNSIGNEDP.
- However, some machines, have instructions that preferentially
- handle either signed or unsigned quantities of certain modes. For
- example, on the DEC Alpha, 32-bit loads from memory and 32-bit add
- instructions sign-extend the result to 64 bits. On such machines,
- set UNSIGNEDP according to which kind of extension is more
- efficient.
-
- Do not define this macro if it would never modify M.
-
- -- Target Hook: enum machine_mode TARGET_PROMOTE_FUNCTION_MODE
- (const_tree TYPE, enum machine_mode MODE, int *PUNSIGNEDP,
- const_tree FUNTYPE, int FOR_RETURN)
- Like `PROMOTE_MODE', but it is applied to outgoing function
- arguments or function return values. The target hook should
- return the new mode and possibly change `*PUNSIGNEDP' if the
- promotion should change signedness. This function is called only
- for scalar _or pointer_ types.
-
- FOR_RETURN allows to distinguish the promotion of arguments and
- return values. If it is `1', a return value is being promoted and
- `TARGET_FUNCTION_VALUE' must perform the same promotions done here.
- If it is `2', the returned mode should be that of the register in
- which an incoming parameter is copied, or the outgoing result is
- computed; then the hook should return the same mode as
- `promote_mode', though the signedness may be different.
-
- The default is to not promote arguments and return values. You can
- also define the hook to
- `default_promote_function_mode_always_promote' if you would like
- to apply the same rules given by `PROMOTE_MODE'.
-
- -- Macro: PARM_BOUNDARY
- Normal alignment required for function parameters on the stack, in
- bits. All stack parameters receive at least this much alignment
- regardless of data type. On most machines, this is the same as the
- size of an integer.
-
- -- Macro: STACK_BOUNDARY
- Define this macro to the minimum alignment enforced by hardware
- for the stack pointer on this machine. The definition is a C
- expression for the desired alignment (measured in bits). This
- value is used as a default if `PREFERRED_STACK_BOUNDARY' is not
- defined. On most machines, this should be the same as
- `PARM_BOUNDARY'.
-
- -- Macro: PREFERRED_STACK_BOUNDARY
- Define this macro if you wish to preserve a certain alignment for
- the stack pointer, greater than what the hardware enforces. The
- definition is a C expression for the desired alignment (measured
- in bits). This macro must evaluate to a value equal to or larger
- than `STACK_BOUNDARY'.
-
- -- Macro: INCOMING_STACK_BOUNDARY
- Define this macro if the incoming stack boundary may be different
- from `PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a
- value equal to or larger than `STACK_BOUNDARY'.
-
- -- Macro: FUNCTION_BOUNDARY
- Alignment required for a function entry point, in bits.
-
- -- Macro: BIGGEST_ALIGNMENT
- Biggest alignment that any data type can require on this machine,
- in bits. Note that this is not the biggest alignment that is
- supported, just the biggest alignment that, when violated, may
- cause a fault.
-
- -- Macro: MALLOC_ABI_ALIGNMENT
- Alignment, in bits, a C conformant malloc implementation has to
- provide. If not defined, the default value is `BITS_PER_WORD'.
-
- -- Macro: ATTRIBUTE_ALIGNED_VALUE
- Alignment used by the `__attribute__ ((aligned))' construct. If
- not defined, the default value is `BIGGEST_ALIGNMENT'.
-
- -- Macro: MINIMUM_ATOMIC_ALIGNMENT
- If defined, the smallest alignment, in bits, that can be given to
- an object that can be referenced in one operation, without
- disturbing any nearby object. Normally, this is `BITS_PER_UNIT',
- but may be larger on machines that don't have byte or half-word
- store operations.
-
- -- Macro: BIGGEST_FIELD_ALIGNMENT
- Biggest alignment that any structure or union field can require on
- this machine, in bits. If defined, this overrides
- `BIGGEST_ALIGNMENT' for structure and union fields only, unless
- the field alignment has been set by the `__attribute__ ((aligned
- (N)))' construct.
-
- -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED)
- An expression for the alignment of a structure field FIELD if the
- alignment computed in the usual way (including applying of
- `BIGGEST_ALIGNMENT' and `BIGGEST_FIELD_ALIGNMENT' to the
- alignment) is COMPUTED. It overrides alignment only if the field
- alignment has not been set by the `__attribute__ ((aligned (N)))'
- construct.
-
- -- Macro: MAX_STACK_ALIGNMENT
- Biggest stack alignment guaranteed by the backend. Use this macro
- to specify the maximum alignment of a variable on stack.
-
- If not defined, the default value is `STACK_BOUNDARY'.
-
-
- -- Macro: MAX_OFILE_ALIGNMENT
- Biggest alignment supported by the object file format of this
- machine. Use this macro to limit the alignment which can be
- specified using the `__attribute__ ((aligned (N)))' construct. If
- not defined, the default value is `BIGGEST_ALIGNMENT'.
-
- On systems that use ELF, the default (in `config/elfos.h') is the
- largest supported 32-bit ELF section alignment representable on a
- 32-bit host e.g. `(((unsigned HOST_WIDEST_INT) 1 << 28) * 8)'. On
- 32-bit ELF the largest supported section alignment in bits is
- `(0x80000000 * 8)', but this is not representable on 32-bit hosts.
-
- -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN)
- If defined, a C expression to compute the alignment for a variable
- in the static store. TYPE is the data type, and BASIC-ALIGN is
- the alignment that the object would ordinarily have. The value of
- this macro is used instead of that alignment to align the object.
-
- If this macro is not defined, then BASIC-ALIGN is used.
-
- One use of this macro is to increase alignment of medium-size data
- to make it all fit in fewer cache lines. Another is to cause
- character arrays to be word-aligned so that `strcpy' calls that
- copy constants to character arrays can be done inline.
-
- -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN)
- If defined, a C expression to compute the alignment given to a
- constant that is being placed in memory. CONSTANT is the constant
- and BASIC-ALIGN is the alignment that the object would ordinarily
- have. The value of this macro is used instead of that alignment to
- align the object.
-
- If this macro is not defined, then BASIC-ALIGN is used.
-
- The typical use of this macro is to increase alignment for string
- constants to be word aligned so that `strcpy' calls that copy
- constants can be done inline.
-
- -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN)
- If defined, a C expression to compute the alignment for a variable
- in the local store. TYPE is the data type, and BASIC-ALIGN is the
- alignment that the object would ordinarily have. The value of this
- macro is used instead of that alignment to align the object.
-
- If this macro is not defined, then BASIC-ALIGN is used.
-
- One use of this macro is to increase alignment of medium-size data
- to make it all fit in fewer cache lines.
-
- If the value of this macro has a type, it should be an unsigned
- type.
-
- -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN)
- If defined, a C expression to compute the alignment for stack slot.
- TYPE is the data type, MODE is the widest mode available, and
- BASIC-ALIGN is the alignment that the slot would ordinarily have.
- The value of this macro is used instead of that alignment to align
- the slot.
-
- If this macro is not defined, then BASIC-ALIGN is used when TYPE
- is `NULL'. Otherwise, `LOCAL_ALIGNMENT' will be used.
-
- This macro is to set alignment of stack slot to the maximum
- alignment of all possible modes which the slot may have.
-
- If the value of this macro has a type, it should be an unsigned
- type.
-
- -- Macro: LOCAL_DECL_ALIGNMENT (DECL)
- If defined, a C expression to compute the alignment for a local
- variable DECL.
-
- If this macro is not defined, then `LOCAL_ALIGNMENT (TREE_TYPE
- (DECL), DECL_ALIGN (DECL))' is used.
-
- One use of this macro is to increase alignment of medium-size data
- to make it all fit in fewer cache lines.
-
- If the value of this macro has a type, it should be an unsigned
- type.
-
- -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN)
- If defined, a C expression to compute the minimum required
- alignment for dynamic stack realignment purposes for EXP (a type
- or decl), MODE, assuming normal alignment ALIGN.
-
- If this macro is not defined, then ALIGN will be used.
-
- -- Macro: EMPTY_FIELD_BOUNDARY
- Alignment in bits to be given to a structure bit-field that
- follows an empty field such as `int : 0;'.
-
- If `PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro.
-
- -- Macro: STRUCTURE_SIZE_BOUNDARY
- Number of bits which any structure or union's size must be a
- multiple of. Each structure or union's size is rounded up to a
- multiple of this.
-
- If you do not define this macro, the default is the same as
- `BITS_PER_UNIT'.
-
- -- Macro: STRICT_ALIGNMENT
- Define this macro to be the value 1 if instructions will fail to
- work if given data not on the nominal alignment. If instructions
- will merely go slower in that case, define this macro as 0.
-
- -- Macro: PCC_BITFIELD_TYPE_MATTERS
- Define this if you wish to imitate the way many other C compilers
- handle alignment of bit-fields and the structures that contain
- them.
-
- The behavior is that the type written for a named bit-field (`int',
- `short', or other integer type) imposes an alignment for the entire
- structure, as if the structure really did contain an ordinary
- field of that type. In addition, the bit-field is placed within
- the structure so that it would fit within such a field, not
- crossing a boundary for it.
-
- Thus, on most machines, a named bit-field whose type is written as
- `int' would not cross a four-byte boundary, and would force
- four-byte alignment for the whole structure. (The alignment used
- may not be four bytes; it is controlled by the other alignment
- parameters.)
-
- An unnamed bit-field will not affect the alignment of the
- containing structure.
-
- If the macro is defined, its definition should be a C expression;
- a nonzero value for the expression enables this behavior.
-
- Note that if this macro is not defined, or its value is zero, some
- bit-fields may cross more than one alignment boundary. The
- compiler can support such references if there are `insv', `extv',
- and `extzv' insns that can directly reference memory.
-
- The other known way of making bit-fields work is to define
- `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then
- every structure can be accessed with fullwords.
-
- Unless the machine has bit-field instructions or you define
- `STRUCTURE_SIZE_BOUNDARY' that way, you must define
- `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value.
-
- If your aim is to make GCC use the same conventions for laying out
- bit-fields as are used by another compiler, here is how to
- investigate what the other compiler does. Compile and run this
- program:
-
- struct foo1
- {
- char x;
- char :0;
- char y;
- };
-
- struct foo2
- {
- char x;
- int :0;
- char y;
- };
-
- main ()
- {
- printf ("Size of foo1 is %d\n",
- sizeof (struct foo1));
- printf ("Size of foo2 is %d\n",
- sizeof (struct foo2));
- exit (0);
- }
-
- If this prints 2 and 5, then the compiler's behavior is what you
- would get from `PCC_BITFIELD_TYPE_MATTERS'.
-
- -- Macro: BITFIELD_NBYTES_LIMITED
- Like `PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited
- to aligning a bit-field within the structure.
-
- -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void)
- When `PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine
- whether unnamed bitfields affect the alignment of the containing
- structure. The hook should return true if the structure should
- inherit the alignment requirements of an unnamed bitfield's type.
-
- -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void)
- This target hook should return `true' if accesses to volatile
- bitfields should use the narrowest mode possible. It should
- return `false' if these accesses should use the bitfield container
- type.
-
- The default is `!TARGET_STRICT_ALIGN'.
-
- -- Macro: MEMBER_TYPE_FORCES_BLK (FIELD, MODE)
- Return 1 if a structure or array containing FIELD should be
- accessed using `BLKMODE'.
-
- If FIELD is the only field in the structure, MODE is its mode,
- otherwise MODE is VOIDmode. MODE is provided in the case where
- structures of one field would require the structure's mode to
- retain the field's mode.
-
- Normally, this is not needed.
-
- -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED)
- Define this macro as an expression for the alignment of a type
- (given by TYPE as a tree node) if the alignment computed in the
- usual way is COMPUTED and the alignment explicitly specified was
- SPECIFIED.
-
- The default is to use SPECIFIED if it is larger; otherwise, use
- the smaller of COMPUTED and `BIGGEST_ALIGNMENT'
-
- -- Macro: MAX_FIXED_MODE_SIZE
- An integer expression for the size in bits of the largest integer
- machine mode that should actually be used. All integer machine
- modes of this size or smaller can be used for structures and
- unions with the appropriate sizes. If this macro is undefined,
- `GET_MODE_BITSIZE (DImode)' is assumed.
-
- -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL)
- If defined, an expression of type `enum machine_mode' that
- specifies the mode of the save area operand of a
- `save_stack_LEVEL' named pattern (*note Standard Names::).
- SAVE_LEVEL is one of `SAVE_BLOCK', `SAVE_FUNCTION', or
- `SAVE_NONLOCAL' and selects which of the three named patterns is
- having its mode specified.
-
- You need not define this macro if it always returns `Pmode'. You
- would most commonly define this macro if the `save_stack_LEVEL'
- patterns need to support both a 32- and a 64-bit mode.
-
- -- Macro: STACK_SIZE_MODE
- If defined, an expression of type `enum machine_mode' that
- specifies the mode of the size increment operand of an
- `allocate_stack' named pattern (*note Standard Names::).
-
- You need not define this macro if it always returns `word_mode'.
- You would most commonly define this macro if the `allocate_stack'
- pattern needs to support both a 32- and a 64-bit mode.
-
- -- Target Hook: enum machine_mode TARGET_LIBGCC_CMP_RETURN_MODE (void)
- This target hook should return the mode to be used for the return
- value of compare instructions expanded to libgcc calls. If not
- defined `word_mode' is returned which is the right choice for a
- majority of targets.
-
- -- Target Hook: enum machine_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void)
- This target hook should return the mode to be used for the shift
- count operand of shift instructions expanded to libgcc calls. If
- not defined `word_mode' is returned which is the right choice for
- a majority of targets.
-
- -- Target Hook: enum machine_mode TARGET_UNWIND_WORD_MODE (void)
- Return machine mode to be used for `_Unwind_Word' type. The
- default is to use `word_mode'.
-
- -- Macro: ROUND_TOWARDS_ZERO
- If defined, this macro should be true if the prevailing rounding
- mode is towards zero.
-
- Defining this macro only affects the way `libgcc.a' emulates
- floating-point arithmetic.
-
- Not defining this macro is equivalent to returning zero.
-
- -- Macro: LARGEST_EXPONENT_IS_NORMAL (SIZE)
- This macro should return true if floats with SIZE bits do not have
- a NaN or infinity representation, but use the largest exponent for
- normal numbers instead.
-
- Defining this macro only affects the way `libgcc.a' emulates
- floating-point arithmetic.
-
- The default definition of this macro returns false for all sizes.
-
- -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree
- RECORD_TYPE)
- This target hook returns `true' if bit-fields in the given
- RECORD_TYPE are to be laid out following the rules of Microsoft
- Visual C/C++, namely: (i) a bit-field won't share the same storage
- unit with the previous bit-field if their underlying types have
- different sizes, and the bit-field will be aligned to the highest
- alignment of the underlying types of itself and of the previous
- bit-field; (ii) a zero-sized bit-field will affect the alignment of
- the whole enclosing structure, even if it is unnamed; except that
- (iii) a zero-sized bit-field will be disregarded unless it follows
- another bit-field of nonzero size. If this hook returns `true',
- other macros that control bit-field layout are ignored.
-
- When a bit-field is inserted into a packed record, the whole size
- of the underlying type is used by one or more same-size adjacent
- bit-fields (that is, if its long:3, 32 bits is used in the record,
- and any additional adjacent long bit-fields are packed into the
- same chunk of 32 bits. However, if the size changes, a new field
- of that size is allocated). In an unpacked record, this is the
- same as using alignment, but not equivalent when packing.
-
- If both MS bit-fields and `__attribute__((packed))' are used, the
- latter will take precedence. If `__attribute__((packed))' is used
- on a single field when MS bit-fields are in use, it will take
- precedence for that field, but the alignment of the rest of the
- structure may affect its placement.
-
- -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void)
- Returns true if the target supports decimal floating point.
-
- -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void)
- Returns true if the target supports fixed-point arithmetic.
-
- -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void)
- This hook is called just before expansion into rtl, allowing the
- target to perform additional initializations or analysis before
- the expansion. For example, the rs6000 port uses it to allocate a
- scratch stack slot for use in copying SDmode values between memory
- and floating point registers whenever the function being expanded
- has any SDmode usage.
-
- -- Target Hook: void TARGET_INSTANTIATE_DECLS (void)
- This hook allows the backend to perform additional instantiations
- on rtl that are not actually in any insns yet, but will be later.
-
- -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE)
- If your target defines any fundamental types, or any types your
- target uses should be mangled differently from the default, define
- this hook to return the appropriate encoding for these types as
- part of a C++ mangled name. The TYPE argument is the tree
- structure representing the type to be mangled. The hook may be
- applied to trees which are not target-specific fundamental types;
- it should return `NULL' for all such types, as well as arguments
- it does not recognize. If the return value is not `NULL', it must
- point to a statically-allocated string constant.
-
- Target-specific fundamental types might be new fundamental types or
- qualified versions of ordinary fundamental types. Encode new
- fundamental types as `u N NAME', where NAME is the name used for
- the type in source code, and N is the length of NAME in decimal.
- Encode qualified versions of ordinary types as `U N NAME CODE',
- where NAME is the name used for the type qualifier in source code,
- N is the length of NAME as above, and CODE is the code used to
- represent the unqualified version of this type. (See
- `write_builtin_type' in `cp/mangle.c' for the list of codes.) In
- both cases the spaces are for clarity; do not include any spaces
- in your string.
-
- This hook is applied to types prior to typedef resolution. If the
- mangled name for a particular type depends only on that type's
- main variant, you can perform typedef resolution yourself using
- `TYPE_MAIN_VARIANT' before mangling.
-
- The default version of this hook always returns `NULL', which is
- appropriate for a target that does not define any new fundamental
- types.
-
-
-File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros
-
-17.6 Layout of Source Language Data Types
-=========================================
-
-These macros define the sizes and other characteristics of the standard
-basic data types used in programs being compiled. Unlike the macros in
-the previous section, these apply to specific features of C and related
-languages, rather than to fundamental aspects of storage layout.
-
- -- Macro: INT_TYPE_SIZE
- A C expression for the size in bits of the type `int' on the
- target machine. If you don't define this, the default is one word.
-
- -- Macro: SHORT_TYPE_SIZE
- A C expression for the size in bits of the type `short' on the
- target machine. If you don't define this, the default is half a
- word. (If this would be less than one storage unit, it is rounded
- up to one unit.)
-
- -- Macro: LONG_TYPE_SIZE
- A C expression for the size in bits of the type `long' on the
- target machine. If you don't define this, the default is one word.
-
- -- Macro: ADA_LONG_TYPE_SIZE
- On some machines, the size used for the Ada equivalent of the type
- `long' by a native Ada compiler differs from that used by C. In
- that situation, define this macro to be a C expression to be used
- for the size of that type. If you don't define this, the default
- is the value of `LONG_TYPE_SIZE'.
-
- -- Macro: LONG_LONG_TYPE_SIZE
- A C expression for the size in bits of the type `long long' on the
- target machine. If you don't define this, the default is two
- words. If you want to support GNU Ada on your machine, the value
- of this macro must be at least 64.
-
- -- Macro: CHAR_TYPE_SIZE
- A C expression for the size in bits of the type `char' on the
- target machine. If you don't define this, the default is
- `BITS_PER_UNIT'.
-
- -- Macro: BOOL_TYPE_SIZE
- A C expression for the size in bits of the C++ type `bool' and C99
- type `_Bool' on the target machine. If you don't define this, and
- you probably shouldn't, the default is `CHAR_TYPE_SIZE'.
-
- -- Macro: FLOAT_TYPE_SIZE
- A C expression for the size in bits of the type `float' on the
- target machine. If you don't define this, the default is one word.
-
- -- Macro: DOUBLE_TYPE_SIZE
- A C expression for the size in bits of the type `double' on the
- target machine. If you don't define this, the default is two
- words.
-
- -- Macro: LONG_DOUBLE_TYPE_SIZE
- A C expression for the size in bits of the type `long double' on
- the target machine. If you don't define this, the default is two
- words.
-
- -- Macro: SHORT_FRACT_TYPE_SIZE
- A C expression for the size in bits of the type `short _Fract' on
- the target machine. If you don't define this, the default is
- `BITS_PER_UNIT'.
-
- -- Macro: FRACT_TYPE_SIZE
- A C expression for the size in bits of the type `_Fract' on the
- target machine. If you don't define this, the default is
- `BITS_PER_UNIT * 2'.
-
- -- Macro: LONG_FRACT_TYPE_SIZE
- A C expression for the size in bits of the type `long _Fract' on
- the target machine. If you don't define this, the default is
- `BITS_PER_UNIT * 4'.
-
- -- Macro: LONG_LONG_FRACT_TYPE_SIZE
- A C expression for the size in bits of the type `long long _Fract'
- on the target machine. If you don't define this, the default is
- `BITS_PER_UNIT * 8'.
-
- -- Macro: SHORT_ACCUM_TYPE_SIZE
- A C expression for the size in bits of the type `short _Accum' on
- the target machine. If you don't define this, the default is
- `BITS_PER_UNIT * 2'.
-
- -- Macro: ACCUM_TYPE_SIZE
- A C expression for the size in bits of the type `_Accum' on the
- target machine. If you don't define this, the default is
- `BITS_PER_UNIT * 4'.
-
- -- Macro: LONG_ACCUM_TYPE_SIZE
- A C expression for the size in bits of the type `long _Accum' on
- the target machine. If you don't define this, the default is
- `BITS_PER_UNIT * 8'.
-
- -- Macro: LONG_LONG_ACCUM_TYPE_SIZE
- A C expression for the size in bits of the type `long long _Accum'
- on the target machine. If you don't define this, the default is
- `BITS_PER_UNIT * 16'.
-
- -- Macro: LIBGCC2_LONG_DOUBLE_TYPE_SIZE
- Define this macro if `LONG_DOUBLE_TYPE_SIZE' is not constant or if
- you want routines in `libgcc2.a' for a size other than
- `LONG_DOUBLE_TYPE_SIZE'. If you don't define this, the default is
- `LONG_DOUBLE_TYPE_SIZE'.
-
- -- Macro: LIBGCC2_HAS_DF_MODE
- Define this macro if neither `DOUBLE_TYPE_SIZE' nor
- `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is `DFmode' but you want `DFmode'
- routines in `libgcc2.a' anyway. If you don't define this and
- either `DOUBLE_TYPE_SIZE' or `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64
- then the default is 1, otherwise it is 0.
-
- -- Macro: LIBGCC2_HAS_XF_MODE
- Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not
- `XFmode' but you want `XFmode' routines in `libgcc2.a' anyway. If
- you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 80
- then the default is 1, otherwise it is 0.
-
- -- Macro: LIBGCC2_HAS_TF_MODE
- Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not
- `TFmode' but you want `TFmode' routines in `libgcc2.a' anyway. If
- you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 128
- then the default is 1, otherwise it is 0.
-
- -- Macro: SF_SIZE
- -- Macro: DF_SIZE
- -- Macro: XF_SIZE
- -- Macro: TF_SIZE
- Define these macros to be the size in bits of the mantissa of
- `SFmode', `DFmode', `XFmode' and `TFmode' values, if the defaults
- in `libgcc2.h' are inappropriate. By default, `FLT_MANT_DIG' is
- used for `SF_SIZE', `LDBL_MANT_DIG' for `XF_SIZE' and `TF_SIZE',
- and `DBL_MANT_DIG' or `LDBL_MANT_DIG' for `DF_SIZE' according to
- whether `DOUBLE_TYPE_SIZE' or `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is
- 64.
-
- -- Macro: TARGET_FLT_EVAL_METHOD
- A C expression for the value for `FLT_EVAL_METHOD' in `float.h',
- assuming, if applicable, that the floating-point control word is
- in its default state. If you do not define this macro the value of
- `FLT_EVAL_METHOD' will be zero.
-
- -- Macro: WIDEST_HARDWARE_FP_SIZE
- A C expression for the size in bits of the widest floating-point
- format supported by the hardware. If you define this macro, you
- must specify a value less than or equal to the value of
- `LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the
- value of `LONG_DOUBLE_TYPE_SIZE' is the default.
-
- -- Macro: DEFAULT_SIGNED_CHAR
- An expression whose value is 1 or 0, according to whether the type
- `char' should be signed or unsigned by default. The user can
- always override this default with the options `-fsigned-char' and
- `-funsigned-char'.
-
- -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void)
- This target hook should return true if the compiler should give an
- `enum' type only as many bytes as it takes to represent the range
- of possible values of that type. It should return false if all
- `enum' types should be allocated like `int'.
-
- The default is to return false.
-
- -- Macro: SIZE_TYPE
- A C expression for a string describing the name of the data type
- to use for size values. The typedef name `size_t' is defined
- using the contents of the string.
-
- The string can contain more than one keyword. If so, separate
- them with spaces, and write first any length keyword, then
- `unsigned' if appropriate, and finally `int'. The string must
- exactly match one of the data type names defined in the function
- `init_decl_processing' in the file `c-decl.c'. You may not omit
- `int' or change the order--that would cause the compiler to crash
- on startup.
-
- If you don't define this macro, the default is `"long unsigned
- int"'.
-
- -- Macro: PTRDIFF_TYPE
- A C expression for a string describing the name of the data type
- to use for the result of subtracting two pointers. The typedef
- name `ptrdiff_t' is defined using the contents of the string. See
- `SIZE_TYPE' above for more information.
-
- If you don't define this macro, the default is `"long int"'.
-
- -- Macro: WCHAR_TYPE
- A C expression for a string describing the name of the data type
- to use for wide characters. The typedef name `wchar_t' is defined
- using the contents of the string. See `SIZE_TYPE' above for more
- information.
-
- If you don't define this macro, the default is `"int"'.
-
- -- Macro: WCHAR_TYPE_SIZE
- A C expression for the size in bits of the data type for wide
- characters. This is used in `cpp', which cannot make use of
- `WCHAR_TYPE'.
-
- -- Macro: WINT_TYPE
- A C expression for a string describing the name of the data type to
- use for wide characters passed to `printf' and returned from
- `getwc'. The typedef name `wint_t' is defined using the contents
- of the string. See `SIZE_TYPE' above for more information.
-
- If you don't define this macro, the default is `"unsigned int"'.
-
- -- Macro: INTMAX_TYPE
- A C expression for a string describing the name of the data type
- that can represent any value of any standard or extended signed
- integer type. The typedef name `intmax_t' is defined using the
- contents of the string. See `SIZE_TYPE' above for more
- information.
-
- If you don't define this macro, the default is the first of
- `"int"', `"long int"', or `"long long int"' that has as much
- precision as `long long int'.
-
- -- Macro: UINTMAX_TYPE
- A C expression for a string describing the name of the data type
- that can represent any value of any standard or extended unsigned
- integer type. The typedef name `uintmax_t' is defined using the
- contents of the string. See `SIZE_TYPE' above for more
- information.
-
- If you don't define this macro, the default is the first of
- `"unsigned int"', `"long unsigned int"', or `"long long unsigned
- int"' that has as much precision as `long long unsigned int'.
-
- -- Macro: SIG_ATOMIC_TYPE
- -- Macro: INT8_TYPE
- -- Macro: INT16_TYPE
- -- Macro: INT32_TYPE
- -- Macro: INT64_TYPE
- -- Macro: UINT8_TYPE
- -- Macro: UINT16_TYPE
- -- Macro: UINT32_TYPE
- -- Macro: UINT64_TYPE
- -- Macro: INT_LEAST8_TYPE
- -- Macro: INT_LEAST16_TYPE
- -- Macro: INT_LEAST32_TYPE
- -- Macro: INT_LEAST64_TYPE
- -- Macro: UINT_LEAST8_TYPE
- -- Macro: UINT_LEAST16_TYPE
- -- Macro: UINT_LEAST32_TYPE
- -- Macro: UINT_LEAST64_TYPE
- -- Macro: INT_FAST8_TYPE
- -- Macro: INT_FAST16_TYPE
- -- Macro: INT_FAST32_TYPE
- -- Macro: INT_FAST64_TYPE
- -- Macro: UINT_FAST8_TYPE
- -- Macro: UINT_FAST16_TYPE
- -- Macro: UINT_FAST32_TYPE
- -- Macro: UINT_FAST64_TYPE
- -- Macro: INTPTR_TYPE
- -- Macro: UINTPTR_TYPE
- C expressions for the standard types `sig_atomic_t', `int8_t',
- `int16_t', `int32_t', `int64_t', `uint8_t', `uint16_t',
- `uint32_t', `uint64_t', `int_least8_t', `int_least16_t',
- `int_least32_t', `int_least64_t', `uint_least8_t',
- `uint_least16_t', `uint_least32_t', `uint_least64_t',
- `int_fast8_t', `int_fast16_t', `int_fast32_t', `int_fast64_t',
- `uint_fast8_t', `uint_fast16_t', `uint_fast32_t', `uint_fast64_t',
- `intptr_t', and `uintptr_t'. See `SIZE_TYPE' above for more
- information.
-
- If any of these macros evaluates to a null pointer, the
- corresponding type is not supported; if GCC is configured to
- provide `<stdint.h>' in such a case, the header provided may not
- conform to C99, depending on the type in question. The defaults
- for all of these macros are null pointers.
-
- -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION
- The C++ compiler represents a pointer-to-member-function with a
- struct that looks like:
-
- struct {
- union {
- void (*fn)();
- ptrdiff_t vtable_index;
- };
- ptrdiff_t delta;
- };
-
- The C++ compiler must use one bit to indicate whether the function
- that will be called through a pointer-to-member-function is
- virtual. Normally, we assume that the low-order bit of a function
- pointer must always be zero. Then, by ensuring that the
- vtable_index is odd, we can distinguish which variant of the union
- is in use. But, on some platforms function pointers can be odd,
- and so this doesn't work. In that case, we use the low-order bit
- of the `delta' field, and shift the remainder of the `delta' field
- to the left.
-
- GCC will automatically make the right selection about where to
- store this bit using the `FUNCTION_BOUNDARY' setting for your
- platform. However, some platforms such as ARM/Thumb have
- `FUNCTION_BOUNDARY' set such that functions always start at even
- addresses, but the lowest bit of pointers to functions indicate
- whether the function at that address is in ARM or Thumb mode. If
- this is the case of your architecture, you should define this
- macro to `ptrmemfunc_vbit_in_delta'.
-
- In general, you should not have to define this macro. On
- architectures in which function addresses are always even,
- according to `FUNCTION_BOUNDARY', GCC will automatically define
- this macro to `ptrmemfunc_vbit_in_pfn'.
-
- -- Macro: TARGET_VTABLE_USES_DESCRIPTORS
- Normally, the C++ compiler uses function pointers in vtables. This
- macro allows the target to change to use "function descriptors"
- instead. Function descriptors are found on targets for whom a
- function pointer is actually a small data structure. Normally the
- data structure consists of the actual code address plus a data
- pointer to which the function's data is relative.
-
- If vtables are used, the value of this macro should be the number
- of words that the function descriptor occupies.
-
- -- Macro: TARGET_VTABLE_ENTRY_ALIGN
- By default, the vtable entries are void pointers, the so the
- alignment is the same as pointer alignment. The value of this
- macro specifies the alignment of the vtable entry in bits. It
- should be defined only when special alignment is necessary. */
-
- -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE
- There are a few non-descriptor entries in the vtable at offsets
- below zero. If these entries must be padded (say, to preserve the
- alignment specified by `TARGET_VTABLE_ENTRY_ALIGN'), set this to
- the number of words in each data entry.
-
-
-File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros
-
-17.7 Register Usage
-===================
-
-This section explains how to describe what registers the target machine
-has, and how (in general) they can be used.
-
- The description of which registers a specific instruction can use is
-done with register classes; see *note Register Classes::. For
-information on using registers to access a stack frame, see *note Frame
-Registers::. For passing values in registers, see *note Register
-Arguments::. For returning values in registers, see *note Scalar
-Return::.
-
-* Menu:
-
-* Register Basics:: Number and kinds of registers.
-* Allocation Order:: Order in which registers are allocated.
-* Values in Registers:: What kinds of values each reg can hold.
-* Leaf Functions:: Renumbering registers for leaf functions.
-* Stack Registers:: Handling a register stack such as 80387.
-
-
-File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers
-
-17.7.1 Basic Characteristics of Registers
------------------------------------------
-
-Registers have various characteristics.
-
- -- Macro: FIRST_PSEUDO_REGISTER
- Number of hardware registers known to the compiler. They receive
- numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first
- pseudo register's number really is assigned the number
- `FIRST_PSEUDO_REGISTER'.
-
- -- Macro: FIXED_REGISTERS
- An initializer that says which registers are used for fixed
- purposes all throughout the compiled code and are therefore not
- available for general allocation. These would include the stack
- pointer, the frame pointer (except on machines where that can be
- used as a general register when no frame pointer is needed), the
- program counter on machines where that is considered one of the
- addressable registers, and any other numbered register with a
- standard use.
-
- This information is expressed as a sequence of numbers, separated
- by commas and surrounded by braces. The Nth number is 1 if
- register N is fixed, 0 otherwise.
-
- The table initialized from this macro, and the table initialized by
- the following one, may be overridden at run time either
- automatically, by the actions of the macro
- `CONDITIONAL_REGISTER_USAGE', or by the user with the command
- options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
-
- -- Macro: CALL_USED_REGISTERS
- Like `FIXED_REGISTERS' but has 1 for each register that is
- clobbered (in general) by function calls as well as for fixed
- registers. This macro therefore identifies the registers that are
- not available for general allocation of values that must live
- across function calls.
-
- If a register has 0 in `CALL_USED_REGISTERS', the compiler
- automatically saves it on function entry and restores it on
- function exit, if the register is used within the function.
-
- -- Macro: CALL_REALLY_USED_REGISTERS
- Like `CALL_USED_REGISTERS' except this macro doesn't require that
- the entire set of `FIXED_REGISTERS' be included.
- (`CALL_USED_REGISTERS' must be a superset of `FIXED_REGISTERS').
- This macro is optional. If not specified, it defaults to the value
- of `CALL_USED_REGISTERS'.
-
- -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE)
- A C expression that is nonzero if it is not permissible to store a
- value of mode MODE in hard register number REGNO across a call
- without some part of it being clobbered. For most machines this
- macro need not be defined. It is only required for machines that
- do not preserve the entire contents of a register across a call.
-
- -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void)
- This hook may conditionally modify five variables `fixed_regs',
- `call_used_regs', `global_regs', `reg_names', and
- `reg_class_contents', to take into account any dependence of these
- register sets on target flags. The first three of these are of
- type `char []' (interpreted as Boolean vectors). `global_regs' is
- a `const char *[]', and `reg_class_contents' is a `HARD_REG_SET'.
- Before the macro is called, `fixed_regs', `call_used_regs',
- `reg_class_contents', and `reg_names' have been initialized from
- `FIXED_REGISTERS', `CALL_USED_REGISTERS', `REG_CLASS_CONTENTS',
- and `REGISTER_NAMES', respectively. `global_regs' has been
- cleared, and any `-ffixed-REG', `-fcall-used-REG' and
- `-fcall-saved-REG' command options have been applied.
-
- If the usage of an entire class of registers depends on the target
- flags, you may indicate this to GCC by using this macro to modify
- `fixed_regs' and `call_used_regs' to 1 for each of the registers
- in the classes which should not be used by GCC. Also define the
- macro `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' to
- return `NO_REGS' if it is called with a letter for a class that
- shouldn't be used.
-
- (However, if this class is not included in `GENERAL_REGS' and all
- of the insn patterns whose constraints permit this class are
- controlled by target switches, then GCC will automatically avoid
- using these registers when the target switches are opposed to
- them.)
-
- -- Macro: INCOMING_REGNO (OUT)
- Define this macro if the target machine has register windows.
- This C expression returns the register number as seen by the
- called function corresponding to the register number OUT as seen
- by the calling function. Return OUT if register number OUT is not
- an outbound register.
-
- -- Macro: OUTGOING_REGNO (IN)
- Define this macro if the target machine has register windows.
- This C expression returns the register number as seen by the
- calling function corresponding to the register number IN as seen
- by the called function. Return IN if register number IN is not an
- inbound register.
-
- -- Macro: LOCAL_REGNO (REGNO)
- Define this macro if the target machine has register windows.
- This C expression returns true if the register is call-saved but
- is in the register window. Unlike most call-saved registers, such
- registers need not be explicitly restored on function exit or
- during non-local gotos.
-
- -- Macro: PC_REGNUM
- If the program counter has a register number, define this as that
- register number. Otherwise, do not define it.
-
-
-File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers
-
-17.7.2 Order of Allocation of Registers
----------------------------------------
-
-Registers are allocated in order.
-
- -- Macro: REG_ALLOC_ORDER
- If defined, an initializer for a vector of integers, containing the
- numbers of hard registers in the order in which GCC should prefer
- to use them (from most preferred to least).
-
- If this macro is not defined, registers are used lowest numbered
- first (all else being equal).
-
- One use of this macro is on machines where the highest numbered
- registers must always be saved and the save-multiple-registers
- instruction supports only sequences of consecutive registers. On
- such machines, define `REG_ALLOC_ORDER' to be an initializer that
- lists the highest numbered allocable register first.
-
- -- Macro: ADJUST_REG_ALLOC_ORDER
- A C statement (sans semicolon) to choose the order in which to
- allocate hard registers for pseudo-registers local to a basic
- block.
-
- Store the desired register order in the array `reg_alloc_order'.
- Element 0 should be the register to allocate first; element 1, the
- next register; and so on.
-
- The macro body should not assume anything about the contents of
- `reg_alloc_order' before execution of the macro.
-
- On most machines, it is not necessary to define this macro.
-
- -- Macro: HONOR_REG_ALLOC_ORDER
- Normally, IRA tries to estimate the costs for saving a register in
- the prologue and restoring it in the epilogue. This discourages
- it from using call-saved registers. If a machine wants to ensure
- that IRA allocates registers in the order given by REG_ALLOC_ORDER
- even if some call-saved registers appear earlier than call-used
- ones, this macro should be defined.
-
- -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO)
- In some case register allocation order is not enough for the
- Integrated Register Allocator (IRA) to generate a good code. If
- this macro is defined, it should return a floating point value
- based on REGNO. The cost of using REGNO for a pseudo will be
- increased by approximately the pseudo's usage frequency times the
- value returned by this macro. Not defining this macro is
- equivalent to having it always return `0.0'.
-
- On most machines, it is not necessary to define this macro.
-
-
-File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers
-
-17.7.3 How Values Fit in Registers
-----------------------------------
-
-This section discusses the macros that describe which kinds of values
-(specifically, which machine modes) each register can hold, and how many
-consecutive registers are needed for a given mode.
-
- -- Macro: HARD_REGNO_NREGS (REGNO, MODE)
- A C expression for the number of consecutive hard registers,
- starting at register number REGNO, required to hold a value of mode
- MODE. This macro must never return zero, even if a register
- cannot hold the requested mode - indicate that with
- HARD_REGNO_MODE_OK and/or CANNOT_CHANGE_MODE_CLASS instead.
-
- On a machine where all registers are exactly one word, a suitable
- definition of this macro is
-
- #define HARD_REGNO_NREGS(REGNO, MODE) \
- ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
- / UNITS_PER_WORD)
-
- -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE)
- A C expression that is nonzero if a value of mode MODE, stored in
- memory, ends with padding that causes it to take up more space than
- in registers starting at register number REGNO (as determined by
- multiplying GCC's notion of the size of the register when
- containing this mode by the number of registers returned by
- `HARD_REGNO_NREGS'). By default this is zero.
-
- For example, if a floating-point value is stored in three 32-bit
- registers but takes up 128 bits in memory, then this would be
- nonzero.
-
- This macros only needs to be defined if there are cases where
- `subreg_get_info' would otherwise wrongly determine that a
- `subreg' can be represented by an offset to the register number,
- when in fact such a `subreg' would contain some of the padding not
- stored in registers and so not be representable.
-
- -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE)
- For values of REGNO and MODE for which
- `HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression
- returning the greater number of registers required to hold the
- value including any padding. In the example above, the value
- would be four.
-
- -- Macro: REGMODE_NATURAL_SIZE (MODE)
- Define this macro if the natural size of registers that hold values
- of mode MODE is not the word size. It is a C expression that
- should give the natural size in bytes for the specified mode. It
- is used by the register allocator to try to optimize its results.
- This happens for example on SPARC 64-bit where the natural size of
- floating-point registers is still 32-bit.
-
- -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE)
- A C expression that is nonzero if it is permissible to store a
- value of mode MODE in hard register number REGNO (or in several
- registers starting with that one). For a machine where all
- registers are equivalent, a suitable definition is
-
- #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
-
- You need not include code to check for the numbers of fixed
- registers, because the allocation mechanism considers them to be
- always occupied.
-
- On some machines, double-precision values must be kept in even/odd
- register pairs. You can implement that by defining this macro to
- reject odd register numbers for such modes.
-
- The minimum requirement for a mode to be OK in a register is that
- the `movMODE' instruction pattern support moves between the
- register and other hard register in the same class and that moving
- a value into the register and back out not alter it.
-
- Since the same instruction used to move `word_mode' will work for
- all narrower integer modes, it is not necessary on any machine for
- `HARD_REGNO_MODE_OK' to distinguish between these modes, provided
- you define patterns `movhi', etc., to take advantage of this. This
- is useful because of the interaction between `HARD_REGNO_MODE_OK'
- and `MODES_TIEABLE_P'; it is very desirable for all integer modes
- to be tieable.
-
- Many machines have special registers for floating point arithmetic.
- Often people assume that floating point machine modes are allowed
- only in floating point registers. This is not true. Any
- registers that can hold integers can safely _hold_ a floating
- point machine mode, whether or not floating arithmetic can be done
- on it in those registers. Integer move instructions can be used
- to move the values.
-
- On some machines, though, the converse is true: fixed-point machine
- modes may not go in floating registers. This is true if the
- floating registers normalize any value stored in them, because
- storing a non-floating value there would garble it. In this case,
- `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in
- floating registers. But if the floating registers do not
- automatically normalize, if you can store any bit pattern in one
- and retrieve it unchanged without a trap, then any machine mode
- may go in a floating register, so you can define this macro to say
- so.
-
- The primary significance of special floating registers is rather
- that they are the registers acceptable in floating point arithmetic
- instructions. However, this is of no concern to
- `HARD_REGNO_MODE_OK'. You handle it by writing the proper
- constraints for those instructions.
-
- On some machines, the floating registers are especially slow to
- access, so that it is better to store a value in a stack frame
- than in such a register if floating point arithmetic is not being
- done. As long as the floating registers are not in class
- `GENERAL_REGS', they will not be used unless some pattern's
- constraint asks for one.
-
- -- Macro: HARD_REGNO_RENAME_OK (FROM, TO)
- A C expression that is nonzero if it is OK to rename a hard
- register FROM to another hard register TO.
-
- One common use of this macro is to prevent renaming of a register
- to another register that is not saved by a prologue in an interrupt
- handler.
-
- The default is always nonzero.
-
- -- Macro: MODES_TIEABLE_P (MODE1, MODE2)
- A C expression that is nonzero if a value of mode MODE1 is
- accessible in mode MODE2 without copying.
-
- If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
- MODE2)' are always the same for any R, then `MODES_TIEABLE_P
- (MODE1, MODE2)' should be nonzero. If they differ for any R, you
- should define this macro to return zero unless some other
- mechanism ensures the accessibility of the value in a narrower
- mode.
-
- You should define this macro to return nonzero in as many cases as
- possible since doing so will allow GCC to perform better register
- allocation.
-
- -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO)
- This target hook should return `true' if it is OK to use a hard
- register REGNO as scratch reg in peephole2.
-
- One common use of this macro is to prevent using of a register that
- is not saved by a prologue in an interrupt handler.
-
- The default version of this hook always returns `true'.
-
- -- Macro: AVOID_CCMODE_COPIES
- Define this macro if the compiler should avoid copies to/from
- `CCmode' registers. You should only define this macro if support
- for copying to/from `CCmode' is incomplete.
-
-
-File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers
-
-17.7.4 Handling Leaf Functions
-------------------------------
-
-On some machines, a leaf function (i.e., one which makes no calls) can
-run more efficiently if it does not make its own register window.
-Often this means it is required to receive its arguments in the
-registers where they are passed by the caller, instead of the registers
-where they would normally arrive.
-
- The special treatment for leaf functions generally applies only when
-other conditions are met; for example, often they may use only those
-registers for its own variables and temporaries. We use the term "leaf
-function" to mean a function that is suitable for this special
-handling, so that functions with no calls are not necessarily "leaf
-functions".
-
- GCC assigns register numbers before it knows whether the function is
-suitable for leaf function treatment. So it needs to renumber the
-registers in order to output a leaf function. The following macros
-accomplish this.
-
- -- Macro: LEAF_REGISTERS
- Name of a char vector, indexed by hard register number, which
- contains 1 for a register that is allowable in a candidate for leaf
- function treatment.
-
- If leaf function treatment involves renumbering the registers,
- then the registers marked here should be the ones before
- renumbering--those that GCC would ordinarily allocate. The
- registers which will actually be used in the assembler code, after
- renumbering, should not be marked with 1 in this vector.
-
- Define this macro only if the target machine offers a way to
- optimize the treatment of leaf functions.
-
- -- Macro: LEAF_REG_REMAP (REGNO)
- A C expression whose value is the register number to which REGNO
- should be renumbered, when a function is treated as a leaf
- function.
-
- If REGNO is a register number which should not appear in a leaf
- function before renumbering, then the expression should yield -1,
- which will cause the compiler to abort.
-
- Define this macro only if the target machine offers a way to
- optimize the treatment of leaf functions, and registers need to be
- renumbered to do this.
-
- `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' must
-usually treat leaf functions specially. They can test the C variable
-`current_function_is_leaf' which is nonzero for leaf functions.
-`current_function_is_leaf' is set prior to local register allocation
-and is valid for the remaining compiler passes. They can also test the
-C variable `current_function_uses_only_leaf_regs' which is nonzero for
-leaf functions which only use leaf registers.
-`current_function_uses_only_leaf_regs' is valid after all passes that
-modify the instructions have been run and is only useful if
-`LEAF_REGISTERS' is defined.
-
-
-File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers
-
-17.7.5 Registers That Form a Stack
-----------------------------------
-
-There are special features to handle computers where some of the
-"registers" form a stack. Stack registers are normally written by
-pushing onto the stack, and are numbered relative to the top of the
-stack.
-
- Currently, GCC can only handle one group of stack-like registers, and
-they must be consecutively numbered. Furthermore, the existing support
-for stack-like registers is specific to the 80387 floating point
-coprocessor. If you have a new architecture that uses stack-like
-registers, you will need to do substantial work on `reg-stack.c' and
-write your machine description to cooperate with it, as well as
-defining these macros.
-
- -- Macro: STACK_REGS
- Define this if the machine has any stack-like registers.
-
- -- Macro: STACK_REG_COVER_CLASS
- This is a cover class containing the stack registers. Define this
- if the machine has any stack-like registers.
-
- -- Macro: FIRST_STACK_REG
- The number of the first stack-like register. This one is the top
- of the stack.
-
- -- Macro: LAST_STACK_REG
- The number of the last stack-like register. This one is the
- bottom of the stack.
-
-
-File: gccint.info, Node: Register Classes, Next: Old Constraints, Prev: Registers, Up: Target Macros
-
-17.8 Register Classes
-=====================
-
-On many machines, the numbered registers are not all equivalent. For
-example, certain registers may not be allowed for indexed addressing;
-certain registers may not be allowed in some instructions. These
-machine restrictions are described to the compiler using "register
-classes".
-
- You define a number of register classes, giving each one a name and
-saying which of the registers belong to it. Then you can specify
-register classes that are allowed as operands to particular instruction
-patterns.
-
- In general, each register will belong to several classes. In fact, one
-class must be named `ALL_REGS' and contain all the registers. Another
-class must be named `NO_REGS' and contain no registers. Often the
-union of two classes will be another class; however, this is not
-required.
-
- One of the classes must be named `GENERAL_REGS'. There is nothing
-terribly special about the name, but the operand constraint letters `r'
-and `g' specify this class. If `GENERAL_REGS' is the same as
-`ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
-
- Order the classes so that if class X is contained in class Y then X
-has a lower class number than Y.
-
- The way classes other than `GENERAL_REGS' are specified in operand
-constraints is through machine-dependent operand constraint letters.
-You can define such letters to correspond to various classes, then use
-them in operand constraints.
-
- You should define a class for the union of two classes whenever some
-instruction allows both classes. For example, if an instruction allows
-either a floating point (coprocessor) register or a general register
-for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS'
-which includes both of them. Otherwise you will get suboptimal code,
-or even internal compiler errors when reload cannot find a register in
-the the class computed via `reg_class_subunion'.
-
- You must also specify certain redundant information about the register
-classes: for each class, which classes contain it and which ones are
-contained in it; for each pair of classes, the largest class contained
-in their union.
-
- When a value occupying several consecutive registers is expected in a
-certain class, all the registers used must belong to that class.
-Therefore, register classes cannot be used to enforce a requirement for
-a register pair to start with an even-numbered register. The way to
-specify this requirement is with `HARD_REGNO_MODE_OK'.
-
- Register classes used for input-operands of bitwise-and or shift
-instructions have a special requirement: each such class must have, for
-each fixed-point machine mode, a subclass whose registers can transfer
-that mode to or from memory. For example, on some machines, the
-operations for single-byte values (`QImode') are limited to certain
-registers. When this is so, each register class that is used in a
-bitwise-and or shift instruction must have a subclass consisting of
-registers from which single-byte values can be loaded or stored. This
-is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to
-return.
-
- -- Data type: enum reg_class
- An enumerated type that must be defined with all the register
- class names as enumerated values. `NO_REGS' must be first.
- `ALL_REGS' must be the last register class, followed by one more
- enumerated value, `LIM_REG_CLASSES', which is not a register class
- but rather tells how many classes there are.
-
- Each register class has a number, which is the value of casting
- the class name to type `int'. The number serves as an index in
- many of the tables described below.
-
- -- Macro: N_REG_CLASSES
- The number of distinct register classes, defined as follows:
-
- #define N_REG_CLASSES (int) LIM_REG_CLASSES
-
- -- Macro: REG_CLASS_NAMES
- An initializer containing the names of the register classes as C
- string constants. These names are used in writing some of the
- debugging dumps.
-
- -- Macro: REG_CLASS_CONTENTS
- An initializer containing the contents of the register classes, as
- integers which are bit masks. The Nth integer specifies the
- contents of class N. The way the integer MASK is interpreted is
- that register R is in the class if `MASK & (1 << R)' is 1.
-
- When the machine has more than 32 registers, an integer does not
- suffice. Then the integers are replaced by sub-initializers,
- braced groupings containing several integers. Each
- sub-initializer must be suitable as an initializer for the type
- `HARD_REG_SET' which is defined in `hard-reg-set.h'. In this
- situation, the first integer in each sub-initializer corresponds to
- registers 0 through 31, the second integer to registers 32 through
- 63, and so on.
-
- -- Macro: REGNO_REG_CLASS (REGNO)
- A C expression whose value is a register class containing hard
- register REGNO. In general there is more than one such class;
- choose a class which is "minimal", meaning that no smaller class
- also contains the register.
-
- -- Macro: BASE_REG_CLASS
- A macro whose definition is the name of the class to which a valid
- base register must belong. A base register is one used in an
- address which is the register value plus a displacement.
-
- -- Macro: MODE_BASE_REG_CLASS (MODE)
- This is a variation of the `BASE_REG_CLASS' macro which allows the
- selection of a base register in a mode dependent manner. If MODE
- is VOIDmode then it should return the same value as
- `BASE_REG_CLASS'.
-
- -- Macro: MODE_BASE_REG_REG_CLASS (MODE)
- A C expression whose value is the register class to which a valid
- base register must belong in order to be used in a base plus index
- register address. You should define this macro if base plus index
- addresses have different requirements than other base register
- uses.
-
- -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, OUTER_CODE, INDEX_CODE)
- A C expression whose value is the register class to which a valid
- base register must belong. OUTER_CODE and INDEX_CODE define the
- context in which the base register occurs. OUTER_CODE is the code
- of the immediately enclosing expression (`MEM' for the top level
- of an address, `ADDRESS' for something that occurs in an
- `address_operand'). INDEX_CODE is the code of the corresponding
- index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise.
-
- -- Macro: INDEX_REG_CLASS
- A macro whose definition is the name of the class to which a valid
- index register must belong. An index register is one used in an
- address where its value is either multiplied by a scale factor or
- added to another register (as well as added to a displacement).
-
- -- Macro: REGNO_OK_FOR_BASE_P (NUM)
- A C expression which is nonzero if register number NUM is suitable
- for use as a base register in operand addresses.
-
- -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)
- A C expression that is just like `REGNO_OK_FOR_BASE_P', except that
- that expression may examine the mode of the memory reference in
- MODE. You should define this macro if the mode of the memory
- reference affects whether a register may be used as a base
- register. If you define this macro, the compiler will use it
- instead of `REGNO_OK_FOR_BASE_P'. The mode may be `VOIDmode' for
- addresses that appear outside a `MEM', i.e., as an
- `address_operand'.
-
- -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE)
- A C expression which is nonzero if register number NUM is suitable
- for use as a base register in base plus index operand addresses,
- accessing memory in mode MODE. It may be either a suitable hard
- register or a pseudo register that has been allocated such a hard
- register. You should define this macro if base plus index
- addresses have different requirements than other base register
- uses.
-
- Use of this macro is deprecated; please use the more general
- `REGNO_MODE_CODE_OK_FOR_BASE_P'.
-
- -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, OUTER_CODE,
- INDEX_CODE)
- A C expression that is just like `REGNO_MODE_OK_FOR_BASE_P', except
- that that expression may examine the context in which the register
- appears in the memory reference. OUTER_CODE is the code of the
- immediately enclosing expression (`MEM' if at the top level of the
- address, `ADDRESS' for something that occurs in an
- `address_operand'). INDEX_CODE is the code of the corresponding
- index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise.
- The mode may be `VOIDmode' for addresses that appear outside a
- `MEM', i.e., as an `address_operand'.
-
- -- Macro: REGNO_OK_FOR_INDEX_P (NUM)
- A C expression which is nonzero if register number NUM is suitable
- for use as an index register in operand addresses. It may be
- either a suitable hard register or a pseudo register that has been
- allocated such a hard register.
-
- The difference between an index register and a base register is
- that the index register may be scaled. If an address involves the
- sum of two registers, neither one of them scaled, then either one
- may be labeled the "base" and the other the "index"; but whichever
- labeling is used must fit the machine's constraints of which
- registers may serve in each capacity. The compiler will try both
- labelings, looking for one that is valid, and will reload one or
- both registers only if neither labeling works.
-
- -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t
- RCLASS)
- A target hook that places additional preference on the register
- class to use when it is necessary to rename a register in class
- RCLASS to another class, or perhaps NO_REGS, if no preferred
- register class is found or hook `preferred_rename_class' is not
- implemented. Sometimes returning a more restrictive class makes
- better code. For example, on ARM, thumb-2 instructions using
- `LO_REGS' may be smaller than instructions using `GENERIC_REGS'.
- By returning `LO_REGS' from `preferred_rename_class', code size
- can be reduced.
-
- -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X,
- reg_class_t RCLASS)
- A target hook that places additional restrictions on the register
- class to use when it is necessary to copy value X into a register
- in class RCLASS. The value is a register class; perhaps RCLASS,
- or perhaps another, smaller class.
-
- The default version of this hook always returns value of `rclass'
- argument.
-
- Sometimes returning a more restrictive class makes better code.
- For example, on the 68000, when X is an integer constant that is
- in range for a `moveq' instruction, the value of this macro is
- always `DATA_REGS' as long as RCLASS includes the data registers.
- Requiring a data register guarantees that a `moveq' will be used.
-
- One case where `TARGET_PREFERRED_RELOAD_CLASS' must not return
- RCLASS is if X is a legitimate constant which cannot be loaded
- into some register class. By returning `NO_REGS' you can force X
- into a memory location. For example, rs6000 can load immediate
- values into general-purpose registers, but does not have an
- instruction for loading an immediate value into a floating-point
- register, so `TARGET_PREFERRED_RELOAD_CLASS' returns `NO_REGS' when
- X is a floating-point constant. If the constant can't be loaded
- into any kind of register, code generation will be better if
- `LEGITIMATE_CONSTANT_P' makes the constant illegitimate instead of
- using `TARGET_PREFERRED_RELOAD_CLASS'.
-
- If an insn has pseudos in it after register allocation, reload
- will go through the alternatives and call repeatedly
- `TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning
- `NO_REGS', in this case, makes reload add a `!' in front of the
- constraint: the x86 back-end uses this feature to discourage usage
- of 387 registers when math is done in the SSE registers (and vice
- versa).
-
- -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS)
- A C expression that places additional restrictions on the register
- class to use when it is necessary to copy value X into a register
- in class CLASS. The value is a register class; perhaps CLASS, or
- perhaps another, smaller class. On many machines, the following
- definition is safe:
-
- #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
-
- Sometimes returning a more restrictive class makes better code.
- For example, on the 68000, when X is an integer constant that is
- in range for a `moveq' instruction, the value of this macro is
- always `DATA_REGS' as long as CLASS includes the data registers.
- Requiring a data register guarantees that a `moveq' will be used.
-
- One case where `PREFERRED_RELOAD_CLASS' must not return CLASS is
- if X is a legitimate constant which cannot be loaded into some
- register class. By returning `NO_REGS' you can force X into a
- memory location. For example, rs6000 can load immediate values
- into general-purpose registers, but does not have an instruction
- for loading an immediate value into a floating-point register, so
- `PREFERRED_RELOAD_CLASS' returns `NO_REGS' when X is a
- floating-point constant. If the constant can't be loaded into any
- kind of register, code generation will be better if
- `LEGITIMATE_CONSTANT_P' makes the constant illegitimate instead of
- using `PREFERRED_RELOAD_CLASS'.
-
- If an insn has pseudos in it after register allocation, reload
- will go through the alternatives and call repeatedly
- `PREFERRED_RELOAD_CLASS' to find the best one. Returning
- `NO_REGS', in this case, makes reload add a `!' in front of the
- constraint: the x86 back-end uses this feature to discourage usage
- of 387 registers when math is done in the SSE registers (and vice
- versa).
-
- -- Macro: PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)
- Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of
- input reloads. If you don't define this macro, the default is to
- use CLASS, unchanged.
-
- You can also use `PREFERRED_OUTPUT_RELOAD_CLASS' to discourage
- reload from using some alternatives, like `PREFERRED_RELOAD_CLASS'.
-
- -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx
- X, reg_class_t RCLASS)
- Like `TARGET_PREFERRED_RELOAD_CLASS', but for output reloads
- instead of input reloads.
-
- The default version of this hook always returns value of `rclass'
- argument.
-
- You can also use `TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to
- discourage reload from using some alternatives, like
- `TARGET_PREFERRED_RELOAD_CLASS'.
-
- -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS)
- A C expression that places additional restrictions on the register
- class to use when it is necessary to be able to hold a value of
- mode MODE in a reload register for which class CLASS would
- ordinarily be used.
-
- Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when
- there are certain modes that simply can't go in certain reload
- classes.
-
- The value is a register class; perhaps CLASS, or perhaps another,
- smaller class.
-
- Don't define this macro unless the target machine has limitations
- which require the macro to do something nontrivial.
-
- -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X,
- reg_class_t RELOAD_CLASS, enum machine_mode RELOAD_MODE,
- secondary_reload_info *SRI)
- Many machines have some registers that cannot be copied directly
- to or from memory or even from other types of registers. An
- example is the `MQ' register, which on most machines, can only be
- copied to or from general registers, but not memory. Below, we
- shall be using the term 'intermediate register' when a move
- operation cannot be performed directly, but has to be done by
- copying the source into the intermediate register first, and then
- copying the intermediate register to the destination. An
- intermediate register always has the same mode as source and
- destination. Since it holds the actual value being copied, reload
- might apply optimizations to re-use an intermediate register and
- eliding the copy from the source when it can determine that the
- intermediate register still holds the required value.
-
- Another kind of secondary reload is required on some machines which
- allow copying all registers to and from memory, but require a
- scratch register for stores to some memory locations (e.g., those
- with symbolic address on the RT, and those with certain symbolic
- address on the SPARC when compiling PIC). Scratch registers need
- not have the same mode as the value being copied, and usually hold
- a different value than that being copied. Special patterns in the
- md file are needed to describe how the copy is performed with the
- help of the scratch register; these patterns also describe the
- number, register class(es) and mode(s) of the scratch register(s).
-
- In some cases, both an intermediate and a scratch register are
- required.
-
- For input reloads, this target hook is called with nonzero IN_P,
- and X is an rtx that needs to be copied to a register of class
- RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook
- is called with zero IN_P, and a register of class RELOAD_CLASS
- needs to be copied to rtx X in RELOAD_MODE.
-
- If copying a register of RELOAD_CLASS from/to X requires an
- intermediate register, the hook `secondary_reload' should return
- the register class required for this intermediate register. If no
- intermediate register is required, it should return NO_REGS. If
- more than one intermediate register is required, describe the one
- that is closest in the copy chain to the reload register.
-
- If scratch registers are needed, you also have to describe how to
- perform the copy from/to the reload register to/from this closest
- intermediate register. Or if no intermediate register is
- required, but still a scratch register is needed, describe the
- copy from/to the reload register to/from the reload operand X.
-
- You do this by setting `sri->icode' to the instruction code of a
- pattern in the md file which performs the move. Operands 0 and 1
- are the output and input of this copy, respectively. Operands
- from operand 2 onward are for scratch operands. These scratch
- operands must have a mode, and a single-register-class output
- constraint.
-
- When an intermediate register is used, the `secondary_reload' hook
- will be called again to determine how to copy the intermediate
- register to/from the reload operand X, so your hook must also have
- code to handle the register class of the intermediate operand.
-
- X might be a pseudo-register or a `subreg' of a pseudo-register,
- which could either be in a hard register or in memory. Use
- `true_regnum' to find out; it will return -1 if the pseudo is in
- memory and the hard register number if it is in a register.
-
- Scratch operands in memory (constraint `"=m"' / `"=&m"') are
- currently not supported. For the time being, you will have to
- continue to use `SECONDARY_MEMORY_NEEDED' for that purpose.
-
- `copy_cost' also uses this target hook to find out how values are
- copied. If you want it to include some extra cost for the need to
- allocate (a) scratch register(s), set `sri->extra_cost' to the
- additional cost. Or if two dependent moves are supposed to have a
- lower cost than the sum of the individual moves due to expected
- fortuitous scheduling and/or special forwarding logic, you can set
- `sri->extra_cost' to a negative amount.
-
- -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X)
- -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)
- -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)
- These macros are obsolete, new ports should use the target hook
- `TARGET_SECONDARY_RELOAD' instead.
-
- These are obsolete macros, replaced by the
- `TARGET_SECONDARY_RELOAD' target hook. Older ports still define
- these macros to indicate to the reload phase that it may need to
- allocate at least one register for a reload in addition to the
- register to contain the data. Specifically, if copying X to a
- register CLASS in MODE requires an intermediate register, you were
- supposed to define `SECONDARY_INPUT_RELOAD_CLASS' to return the
- largest register class all of whose registers can be used as
- intermediate registers or scratch registers.
-
- If copying a register CLASS in MODE to X requires an intermediate
- or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' was supposed
- to be defined be defined to return the largest register class
- required. If the requirements for input and output reloads were
- the same, the macro `SECONDARY_RELOAD_CLASS' should have been used
- instead of defining both macros identically.
-
- The values returned by these macros are often `GENERAL_REGS'.
- Return `NO_REGS' if no spare register is needed; i.e., if X can be
- directly copied to or from a register of CLASS in MODE without
- requiring a scratch register. Do not define this macro if it
- would always return `NO_REGS'.
-
- If a scratch register is required (either with or without an
- intermediate register), you were supposed to define patterns for
- `reload_inM' or `reload_outM', as required (*note Standard
- Names::. These patterns, which were normally implemented with a
- `define_expand', should be similar to the `movM' patterns, except
- that operand 2 is the scratch register.
-
- These patterns need constraints for the reload register and scratch
- register that contain a single register class. If the original
- reload register (whose class is CLASS) can meet the constraint
- given in the pattern, the value returned by these macros is used
- for the class of the scratch register. Otherwise, two additional
- reload registers are required. Their classes are obtained from
- the constraints in the insn pattern.
-
- X might be a pseudo-register or a `subreg' of a pseudo-register,
- which could either be in a hard register or in memory. Use
- `true_regnum' to find out; it will return -1 if the pseudo is in
- memory and the hard register number if it is in a register.
-
- These macros should not be used in the case where a particular
- class of registers can only be copied to memory and not to another
- class of registers. In that case, secondary reload registers are
- not needed and would not be helpful. Instead, a stack location
- must be used to perform the copy and the `movM' pattern should use
- memory as an intermediate storage. This case often occurs between
- floating-point and general registers.
-
- -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)
- Certain machines have the property that some registers cannot be
- copied to some other registers without using memory. Define this
- macro on those machines to be a C expression that is nonzero if
- objects of mode M in registers of CLASS1 can only be copied to
- registers of class CLASS2 by storing a register of CLASS1 into
- memory and loading that memory location into a register of CLASS2.
-
- Do not define this macro if its value would always be zero.
-
- -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE)
- Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler
- allocates a stack slot for a memory location needed for register
- copies. If this macro is defined, the compiler instead uses the
- memory location defined by this macro.
-
- Do not define this macro if you do not define
- `SECONDARY_MEMORY_NEEDED'.
-
- -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE)
- When the compiler needs a secondary memory location to copy
- between two registers of mode MODE, it normally allocates
- sufficient memory to hold a quantity of `BITS_PER_WORD' bits and
- performs the store and load operations in a mode that many bits
- wide and whose class is the same as that of MODE.
-
- This is right thing to do on most machines because it ensures that
- all bits of the register are copied and prevents accesses to the
- registers in a narrower mode, which some machines prohibit for
- floating-point registers.
-
- However, this default behavior is not correct on some machines,
- such as the DEC Alpha, that store short integers in floating-point
- registers differently than in integer registers. On those
- machines, the default widening will not work correctly and you
- must define this macro to suppress that widening in some cases.
- See the file `alpha.h' for details.
-
- Do not define this macro if you do not define
- `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is
- `BITS_PER_WORD' bits wide is correct for your machine.
-
- -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS)
- A target hook which returns `true' if pseudos that have been
- assigned to registers of class RCLASS would likely be spilled
- because registers of RCLASS are needed for spill registers.
-
- The default version of this target hook returns `true' if RCLASS
- has exactly one register and `false' otherwise. On most machines,
- this default should be used. Only use this target hook to some
- other expression if pseudos allocated by `local-alloc.c' end up in
- memory because their hard registers were needed for spill
- registers. If this target hook returns `false' for those classes,
- those pseudos will only be allocated by `global.c', which knows
- how to reallocate the pseudo to another register. If there would
- not be another register available for reallocation, you should not
- change the implementation of this target hook since the only
- effect of such implementation would be to slow down register
- allocation.
-
- -- Macro: CLASS_MAX_NREGS (CLASS, MODE)
- A C expression for the maximum number of consecutive registers of
- class CLASS needed to hold a value of mode MODE.
-
- This is closely related to the macro `HARD_REGNO_NREGS'. In fact,
- the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be
- the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all
- REGNO values in the class CLASS.
-
- This macro helps control the handling of multiple-word values in
- the reload pass.
-
- -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS)
- If defined, a C expression that returns nonzero for a CLASS for
- which a change from mode FROM to mode TO is invalid.
-
- For the example, loading 32-bit integer or floating-point objects
- into floating-point registers on the Alpha extends them to 64 bits.
- Therefore loading a 64-bit object and then storing it as a 32-bit
- object does not store the low-order 32 bits, as would be the case
- for a normal register. Therefore, `alpha.h' defines
- `CANNOT_CHANGE_MODE_CLASS' as below:
-
- #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
- (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \
- ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0)
-
- -- Target Hook: const reg_class_t * TARGET_IRA_COVER_CLASSES (void)
- Return an array of cover classes for the Integrated Register
- Allocator (IRA). Cover classes are a set of non-intersecting
- register classes covering all hard registers used for register
- allocation purposes. If a move between two registers in the same
- cover class is possible, it should be cheaper than a load or store
- of the registers. The array is terminated by a `LIM_REG_CLASSES'
- element.
-
- The order of cover classes in the array is important. If two
- classes have the same cost of usage for a pseudo, the class
- occurred first in the array is chosen for the pseudo.
-
- This hook is called once at compiler startup, after the
- command-line options have been processed. It is then re-examined
- by every call to `target_reinit'.
-
- The default implementation returns `IRA_COVER_CLASSES', if defined,
- otherwise there is no default implementation. You must define
- either this macro or `IRA_COVER_CLASSES' in order to use the
- integrated register allocator with Chaitin-Briggs coloring. If the
- macro is not defined, the only available coloring algorithm is
- Chow's priority coloring.
-
- This hook must not be modified from `NULL' to non-`NULL' or vice
- versa by command-line option processing.
-
- -- Macro: IRA_COVER_CLASSES
- See the documentation for `TARGET_IRA_COVER_CLASSES'.
-
-
-File: gccint.info, Node: Old Constraints, Next: Stack and Calling, Prev: Register Classes, Up: Target Macros
-
-17.9 Obsolete Macros for Defining Constraints
-=============================================
-
-Machine-specific constraints can be defined with these macros instead
-of the machine description constructs described in *note Define
-Constraints::. This mechanism is obsolete. New ports should not use
-it; old ports should convert to the new mechanism.
-
- -- Macro: CONSTRAINT_LEN (CHAR, STR)
- For the constraint at the start of STR, which starts with the
- letter C, return the length. This allows you to have register
- class / constant / extra constraints that are longer than a single
- letter; you don't need to define this macro if you can do with
- single-letter constraints only. The definition of this macro
- should use DEFAULT_CONSTRAINT_LEN for all the characters that you
- don't want to handle specially. There are some sanity checks in
- genoutput.c that check the constraint lengths for the md file, so
- you can also use this macro to help you while you are
- transitioning from a byzantine single-letter-constraint scheme:
- when you return a negative length for a constraint you want to
- re-use, genoutput will complain about every instance where it is
- used in the md file.
-
- -- Macro: REG_CLASS_FROM_LETTER (CHAR)
- A C expression which defines the machine-dependent operand
- constraint letters for register classes. If CHAR is such a
- letter, the value should be the register class corresponding to
- it. Otherwise, the value should be `NO_REGS'. The register
- letter `r', corresponding to class `GENERAL_REGS', will not be
- passed to this macro; you do not need to handle it.
-
- -- Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR)
- Like `REG_CLASS_FROM_LETTER', but you also get the constraint
- string passed in STR, so that you can use suffixes to distinguish
- between different variants.
-
- -- Macro: CONST_OK_FOR_LETTER_P (VALUE, C)
- A C expression that defines the machine-dependent operand
- constraint letters (`I', `J', `K', ... `P') that specify
- particular ranges of integer values. If C is one of those
- letters, the expression should check that VALUE, an integer, is in
- the appropriate range and return 1 if so, 0 otherwise. If C is
- not one of those letters, the value should be 0 regardless of
- VALUE.
-
- -- Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
- Like `CONST_OK_FOR_LETTER_P', but you also get the constraint
- string passed in STR, so that you can use suffixes to distinguish
- between different variants.
-
- -- Macro: CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)
- A C expression that defines the machine-dependent operand
- constraint letters that specify particular ranges of
- `const_double' values (`G' or `H').
-
- If C is one of those letters, the expression should check that
- VALUE, an RTX of code `const_double', is in the appropriate range
- and return 1 if so, 0 otherwise. If C is not one of those
- letters, the value should be 0 regardless of VALUE.
-
- `const_double' is used for all floating-point constants and for
- `DImode' fixed-point constants. A given letter can accept either
- or both kinds of values. It can use `GET_MODE' to distinguish
- between these kinds.
-
- -- Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
- Like `CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the
- constraint string passed in STR, so that you can use suffixes to
- distinguish between different variants.
-
- -- Macro: EXTRA_CONSTRAINT (VALUE, C)
- A C expression that defines the optional machine-dependent
- constraint letters that can be used to segregate specific types of
- operands, usually memory references, for the target machine. Any
- letter that is not elsewhere defined and not matched by
- `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' may be used.
- Normally this macro will not be defined.
-
- If it is required for a particular target machine, it should
- return 1 if VALUE corresponds to the operand type represented by
- the constraint letter C. If C is not defined as an extra
- constraint, the value returned should be 0 regardless of VALUE.
-
- For example, on the ROMP, load instructions cannot have their
- output in r0 if the memory reference contains a symbolic address.
- Constraint letter `Q' is defined as representing a memory address
- that does _not_ contain a symbolic address. An alternative is
- specified with a `Q' constraint on the input and `r' on the
- output. The next alternative specifies `m' on the input and a
- register class that does not include r0 on the output.
-
- -- Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR)
- Like `EXTRA_CONSTRAINT', but you also get the constraint string
- passed in STR, so that you can use suffixes to distinguish between
- different variants.
-
- -- Macro: EXTRA_MEMORY_CONSTRAINT (C, STR)
- A C expression that defines the optional machine-dependent
- constraint letters, amongst those accepted by `EXTRA_CONSTRAINT',
- that should be treated like memory constraints by the reload pass.
-
- It should return 1 if the operand type represented by the
- constraint at the start of STR, the first letter of which is the
- letter C, comprises a subset of all memory references including
- all those whose address is simply a base register. This allows
- the reload pass to reload an operand, if it does not directly
- correspond to the operand type of C, by copying its address into a
- base register.
-
- For example, on the S/390, some instructions do not accept
- arbitrary memory references, but only those that do not make use
- of an index register. The constraint letter `Q' is defined via
- `EXTRA_CONSTRAINT' as representing a memory address of this type.
- If the letter `Q' is marked as `EXTRA_MEMORY_CONSTRAINT', a `Q'
- constraint can handle any memory operand, because the reload pass
- knows it can be reloaded by copying the memory address into a base
- register if required. This is analogous to the way an `o'
- constraint can handle any memory operand.
-
- -- Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR)
- A C expression that defines the optional machine-dependent
- constraint letters, amongst those accepted by `EXTRA_CONSTRAINT' /
- `EXTRA_CONSTRAINT_STR', that should be treated like address
- constraints by the reload pass.
-
- It should return 1 if the operand type represented by the
- constraint at the start of STR, which starts with the letter C,
- comprises a subset of all memory addresses including all those
- that consist of just a base register. This allows the reload pass
- to reload an operand, if it does not directly correspond to the
- operand type of STR, by copying it into a base register.
-
- Any constraint marked as `EXTRA_ADDRESS_CONSTRAINT' can only be
- used with the `address_operand' predicate. It is treated
- analogously to the `p' constraint.
-
-
-File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Old Constraints, Up: Target Macros
-
-17.10 Stack Layout and Calling Conventions
-==========================================
-
-This describes the stack layout and calling conventions.
-
-* Menu:
-
-* Frame Layout::
-* Exception Handling::
-* Stack Checking::
-* Frame Registers::
-* Elimination::
-* Stack Arguments::
-* Register Arguments::
-* Scalar Return::
-* Aggregate Return::
-* Caller Saves::
-* Function Entry::
-* Profiling::
-* Tail Calls::
-* Stack Smashing Protection::
-
-
-File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling
-
-17.10.1 Basic Stack Layout
---------------------------
-
-Here is the basic stack layout.
-
- -- Macro: STACK_GROWS_DOWNWARD
- Define this macro if pushing a word onto the stack moves the stack
- pointer to a smaller address.
-
- When we say, "define this macro if ...", it means that the
- compiler checks this macro only with `#ifdef' so the precise
- definition used does not matter.
-
- -- Macro: STACK_PUSH_CODE
- This macro defines the operation used when something is pushed on
- the stack. In RTL, a push operation will be `(set (mem
- (STACK_PUSH_CODE (reg sp))) ...)'
-
- The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'.
- Which of these is correct depends on the stack direction and on
- whether the stack pointer points to the last item on the stack or
- whether it points to the space for the next item on the stack.
-
- The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined,
- which is almost always right, and `PRE_INC' otherwise, which is
- often wrong.
-
- -- Macro: FRAME_GROWS_DOWNWARD
- Define this macro to nonzero value if the addresses of local
- variable slots are at negative offsets from the frame pointer.
-
- -- Macro: ARGS_GROW_DOWNWARD
- Define this macro if successive arguments to a function occupy
- decreasing addresses on the stack.
-
- -- Macro: STARTING_FRAME_OFFSET
- Offset from the frame pointer to the first local variable slot to
- be allocated.
-
- If `FRAME_GROWS_DOWNWARD', find the next slot's offset by
- subtracting the first slot's length from `STARTING_FRAME_OFFSET'.
- Otherwise, it is found by adding the length of the first slot to
- the value `STARTING_FRAME_OFFSET'.
-
- -- Macro: STACK_ALIGNMENT_NEEDED
- Define to zero to disable final alignment of the stack during
- reload. The nonzero default for this macro is suitable for most
- ports.
-
- On ports where `STARTING_FRAME_OFFSET' is nonzero or where there
- is a register save block following the local block that doesn't
- require alignment to `STACK_BOUNDARY', it may be beneficial to
- disable stack alignment and do it in the backend.
-
- -- Macro: STACK_POINTER_OFFSET
- Offset from the stack pointer register to the first location at
- which outgoing arguments are placed. If not specified, the
- default value of zero is used. This is the proper value for most
- machines.
-
- If `ARGS_GROW_DOWNWARD', this is the offset to the location above
- the first location at which outgoing arguments are placed.
-
- -- Macro: FIRST_PARM_OFFSET (FUNDECL)
- Offset from the argument pointer register to the first argument's
- address. On some machines it may depend on the data type of the
- function.
-
- If `ARGS_GROW_DOWNWARD', this is the offset to the location above
- the first argument's address.
-
- -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL)
- Offset from the stack pointer register to an item dynamically
- allocated on the stack, e.g., by `alloca'.
-
- The default value for this macro is `STACK_POINTER_OFFSET' plus the
- length of the outgoing arguments. The default is correct for most
- machines. See `function.c' for details.
-
- -- Macro: INITIAL_FRAME_ADDRESS_RTX
- A C expression whose value is RTL representing the address of the
- initial stack frame. This address is passed to `RETURN_ADDR_RTX'
- and `DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a
- reasonable default value will be used. Define this macro in order
- to make frame pointer elimination work in the presence of
- `__builtin_frame_address (count)' and `__builtin_return_address
- (count)' for `count' not equal to zero.
-
- -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)
- A C expression whose value is RTL representing the address in a
- stack frame where the pointer to the caller's frame is stored.
- Assume that FRAMEADDR is an RTL expression for the address of the
- stack frame itself.
-
- If you don't define this macro, the default is to return the value
- of FRAMEADDR--that is, the stack frame address is also the address
- of the stack word that points to the previous frame.
-
- -- Macro: SETUP_FRAME_ADDRESSES
- If defined, a C expression that produces the machine-specific code
- to setup the stack so that arbitrary frames can be accessed. For
- example, on the SPARC, we must flush all of the register windows
- to the stack before we can access arbitrary stack frames. You
- will seldom need to define this macro.
-
- -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void)
- This target hook should return an rtx that is used to store the
- address of the current frame into the built in `setjmp' buffer.
- The default value, `virtual_stack_vars_rtx', is correct for most
- machines. One reason you may need to define this target hook is if
- `hard_frame_pointer_rtx' is the appropriate value on your machine.
-
- -- Macro: FRAME_ADDR_RTX (FRAMEADDR)
- A C expression whose value is RTL representing the value of the
- frame address for the current frame. FRAMEADDR is the frame
- pointer of the current frame. This is used for
- __builtin_frame_address. You need only define this macro if the
- frame address is not the same as the frame pointer. Most machines
- do not need to define it.
-
- -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR)
- A C expression whose value is RTL representing the value of the
- return address for the frame COUNT steps up from the current
- frame, after the prologue. FRAMEADDR is the frame pointer of the
- COUNT frame, or the frame pointer of the COUNT - 1 frame if
- `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined.
-
- The value of the expression must always be the correct address when
- COUNT is zero, but may be `NULL_RTX' if there is no way to
- determine the return address of other frames.
-
- -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME
- Define this if the return address of a particular stack frame is
- accessed from the frame pointer of the previous stack frame.
-
- -- Macro: INCOMING_RETURN_ADDR_RTX
- A C expression whose value is RTL representing the location of the
- incoming return address at the beginning of any function, before
- the prologue. This RTL is either a `REG', indicating that the
- return value is saved in `REG', or a `MEM' representing a location
- in the stack.
-
- You only need to define this macro if you want to support call
- frame debugging information like that provided by DWARF 2.
-
- If this RTL is a `REG', you should also define
- `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'.
-
- -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN
- A C expression whose value is an integer giving a DWARF 2 column
- number that may be used as an alternative return column. The
- column must not correspond to any gcc hard register (that is, it
- must not be in the range of `DWARF_FRAME_REGNUM').
-
- This macro can be useful if `DWARF_FRAME_RETURN_COLUMN' is set to a
- general register, but an alternative column needs to be used for
- signal frames. Some targets have also used different frame return
- columns over time.
-
- -- Macro: DWARF_ZERO_REG
- A C expression whose value is an integer giving a DWARF 2 register
- number that is considered to always have the value zero. This
- should only be defined if the target has an architected zero
- register, and someone decided it was a good idea to use that
- register number to terminate the stack backtrace. New ports
- should avoid this.
-
- -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char
- *LABEL, rtx PATTERN, int INDEX)
- This target hook allows the backend to emit frame-related insns
- that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame
- debugging info engine will invoke it on insns of the form
- (set (reg) (unspec [...] UNSPEC_INDEX))
- and
- (set (reg) (unspec_volatile [...] UNSPECV_INDEX)).
- to let the backend emit the call frame instructions. LABEL is the
- CFI label attached to the insn, PATTERN is the pattern of the insn
- and INDEX is `UNSPEC_INDEX' or `UNSPECV_INDEX'.
-
- -- Macro: INCOMING_FRAME_SP_OFFSET
- A C expression whose value is an integer giving the offset, in
- bytes, from the value of the stack pointer register to the top of
- the stack frame at the beginning of any function, before the
- prologue. The top of the frame is defined to be the value of the
- stack pointer in the previous frame, just before the call
- instruction.
-
- You only need to define this macro if you want to support call
- frame debugging information like that provided by DWARF 2.
-
- -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL)
- A C expression whose value is an integer giving the offset, in
- bytes, from the argument pointer to the canonical frame address
- (cfa). The final value should coincide with that calculated by
- `INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable
- during virtual register instantiation.
-
- The default value for this macro is `FIRST_PARM_OFFSET (fundecl) +
- crtl->args.pretend_args_size', which is correct for most machines;
- in general, the arguments are found immediately before the stack
- frame. Note that this is not the case on some targets that save
- registers into the caller's frame, such as SPARC and rs6000, and
- so such targets need to define this macro.
-
- You only need to define this macro if the default is incorrect,
- and you want to support call frame debugging information like that
- provided by DWARF 2.
-
- -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL)
- If defined, a C expression whose value is an integer giving the
- offset in bytes from the frame pointer to the canonical frame
- address (cfa). The final value should coincide with that
- calculated by `INCOMING_FRAME_SP_OFFSET'.
-
- Normally the CFA is calculated as an offset from the argument
- pointer, via `ARG_POINTER_CFA_OFFSET', but if the argument pointer
- is variable due to the ABI, this may not be possible. If this
- macro is defined, it implies that the virtual register
- instantiation should be based on the frame pointer instead of the
- argument pointer. Only one of `FRAME_POINTER_CFA_OFFSET' and
- `ARG_POINTER_CFA_OFFSET' should be defined.
-
- -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL)
- If defined, a C expression whose value is an integer giving the
- offset in bytes from the canonical frame address (cfa) to the
- frame base used in DWARF 2 debug information. The default is
- zero. A different value may reduce the size of debug information
- on some ports.
-
-
-File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling
-
-17.10.2 Exception Handling Support
-----------------------------------
-
- -- Macro: EH_RETURN_DATA_REGNO (N)
- A C expression whose value is the Nth register number used for
- data by exception handlers, or `INVALID_REGNUM' if fewer than N
- registers are usable.
-
- The exception handling library routines communicate with the
- exception handlers via a set of agreed upon registers. Ideally
- these registers should be call-clobbered; it is possible to use
- call-saved registers, but may negatively impact code size. The
- target must support at least 2 data registers, but should define 4
- if there are enough free registers.
-
- You must define this macro if you want to support call frame
- exception handling like that provided by DWARF 2.
-
- -- Macro: EH_RETURN_STACKADJ_RTX
- A C expression whose value is RTL representing a location in which
- to store a stack adjustment to be applied before function return.
- This is used to unwind the stack to an exception handler's call
- frame. It will be assigned zero on code paths that return
- normally.
-
- Typically this is a call-clobbered hard register that is otherwise
- untouched by the epilogue, but could also be a stack slot.
-
- Do not define this macro if the stack pointer is saved and restored
- by the regular prolog and epilog code in the call frame itself; in
- this case, the exception handling library routines will update the
- stack location to be restored in place. Otherwise, you must define
- this macro if you want to support call frame exception handling
- like that provided by DWARF 2.
-
- -- Macro: EH_RETURN_HANDLER_RTX
- A C expression whose value is RTL representing a location in which
- to store the address of an exception handler to which we should
- return. It will not be assigned on code paths that return
- normally.
-
- Typically this is the location in the call frame at which the
- normal return address is stored. For targets that return by
- popping an address off the stack, this might be a memory address
- just below the _target_ call frame rather than inside the current
- call frame. If defined, `EH_RETURN_STACKADJ_RTX' will have already
- been assigned, so it may be used to calculate the location of the
- target call frame.
-
- Some targets have more complex requirements than storing to an
- address calculable during initial code generation. In that case
- the `eh_return' instruction pattern should be used instead.
-
- If you want to support call frame exception handling, you must
- define either this macro or the `eh_return' instruction pattern.
-
- -- Macro: RETURN_ADDR_OFFSET
- If defined, an integer-valued C expression for which rtl will be
- generated to add it to the exception handler address before it is
- searched in the exception handling tables, and to subtract it
- again from the address before using it to return to the exception
- handler.
-
- -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL)
- This macro chooses the encoding of pointers embedded in the
- exception handling sections. If at all possible, this should be
- defined such that the exception handling section will not require
- dynamic relocations, and so may be read-only.
-
- CODE is 0 for data, 1 for code labels, 2 for function pointers.
- GLOBAL is true if the symbol may be affected by dynamic
- relocations. The macro should return a combination of the
- `DW_EH_PE_*' defines as found in `dwarf2.h'.
-
- If this macro is not defined, pointers will not be encoded but
- represented directly.
-
- -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE,
- ADDR, DONE)
- This macro allows the target to emit whatever special magic is
- required to represent the encoding chosen by
- `ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of
- pc-relative and indirect encodings; this must be defined if the
- target uses text-relative or data-relative encodings.
-
- This is a C statement that branches to DONE if the format was
- handled. ENCODING is the format chosen, SIZE is the number of
- bytes that the format occupies, ADDR is the `SYMBOL_REF' to be
- emitted.
-
- -- Macro: MD_UNWIND_SUPPORT
- A string specifying a file to be #include'd in unwind-dw2.c. The
- file so included typically defines `MD_FALLBACK_FRAME_STATE_FOR'.
-
- -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS)
- This macro allows the target to add CPU and operating system
- specific code to the call-frame unwinder for use when there is no
- unwind data available. The most common reason to implement this
- macro is to unwind through signal frames.
-
- This macro is called from `uw_frame_state_for' in `unwind-dw2.c',
- `unwind-dw2-xtensa.c' and `unwind-ia64.c'. CONTEXT is an
- `_Unwind_Context'; FS is an `_Unwind_FrameState'. Examine
- `context->ra' for the address of the code being executed and
- `context->cfa' for the stack pointer value. If the frame can be
- decoded, the register save addresses should be updated in FS and
- the macro should evaluate to `_URC_NO_REASON'. If the frame
- cannot be decoded, the macro should evaluate to
- `_URC_END_OF_STACK'.
-
- For proper signal handling in Java this macro is accompanied by
- `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h'
- headers.
-
- -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS)
- This macro allows the target to add operating system specific code
- to the call-frame unwinder to handle the IA-64 `.unwabi' unwinding
- directive, usually used for signal or interrupt frames.
-
- This macro is called from `uw_update_context' in `unwind-ia64.c'.
- CONTEXT is an `_Unwind_Context'; FS is an `_Unwind_FrameState'.
- Examine `fs->unwabi' for the abi and context in the `.unwabi'
- directive. If the `.unwabi' directive can be handled, the
- register save addresses should be updated in FS.
-
- -- Macro: TARGET_USES_WEAK_UNWIND_INFO
- A C expression that evaluates to true if the target requires unwind
- info to be given comdat linkage. Define it to be `1' if comdat
- linkage is necessary. The default is `0'.
-
-
-File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling
-
-17.10.3 Specifying How Stack Checking is Done
----------------------------------------------
-
-GCC will check that stack references are within the boundaries of the
-stack, if the option `-fstack-check' is specified, in one of three ways:
-
- 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC
- will assume that you have arranged for full stack checking to be
- done at appropriate places in the configuration files. GCC will
- not do other special processing.
-
- 2. If `STACK_CHECK_BUILTIN' is zero and the value of the
- `STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume
- that you have arranged for static stack checking (checking of the
- static stack frame of functions) to be done at appropriate places
- in the configuration files. GCC will only emit code to do dynamic
- stack checking (checking on dynamic stack allocations) using the
- third approach below.
-
- 3. If neither of the above are true, GCC will generate code to
- periodically "probe" the stack pointer using the values of the
- macros defined below.
-
- If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is
-defined, GCC will change its allocation strategy for large objects if
-the option `-fstack-check' is specified: they will always be allocated
-dynamically if their size exceeds `STACK_CHECK_MAX_VAR_SIZE' bytes.
-
- -- Macro: STACK_CHECK_BUILTIN
- A nonzero value if stack checking is done by the configuration
- files in a machine-dependent manner. You should define this macro
- if stack checking is required by the ABI of your machine or if you
- would like to do stack checking in some more efficient way than
- the generic approach. The default value of this macro is zero.
-
- -- Macro: STACK_CHECK_STATIC_BUILTIN
- A nonzero value if static stack checking is done by the
- configuration files in a machine-dependent manner. You should
- define this macro if you would like to do static stack checking in
- some more efficient way than the generic approach. The default
- value of this macro is zero.
-
- -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP
- An integer specifying the interval at which GCC must generate
- stack probe instructions, defined as 2 raised to this integer.
- You will normally define this macro so that the interval be no
- larger than the size of the "guard pages" at the end of a stack
- area. The default value of 12 (4096-byte interval) is suitable
- for most systems.
-
- -- Macro: STACK_CHECK_MOVING_SP
- An integer which is nonzero if GCC should move the stack pointer
- page by page when doing probes. This can be necessary on systems
- where the stack pointer contains the bottom address of the memory
- area accessible to the executing thread at any point in time. In
- this situation an alternate signal stack is required in order to
- be able to recover from a stack overflow. The default value of
- this macro is zero.
-
- -- Macro: STACK_CHECK_PROTECT
- The number of bytes of stack needed to recover from a stack
- overflow, for languages where such a recovery is supported. The
- default value of 75 words with the `setjmp'/`longjmp'-based
- exception handling mechanism and 8192 bytes with other exception
- handling mechanisms should be adequate for most machines.
-
- The following macros are relevant only if neither STACK_CHECK_BUILTIN
-nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether
-in the opposite case.
-
- -- Macro: STACK_CHECK_MAX_FRAME_SIZE
- The maximum size of a stack frame, in bytes. GCC will generate
- probe instructions in non-leaf functions to ensure at least this
- many bytes of stack are available. If a stack frame is larger
- than this size, stack checking will not be reliable and GCC will
- issue a warning. The default is chosen so that GCC only generates
- one instruction on most systems. You should normally not change
- the default value of this macro.
-
- -- Macro: STACK_CHECK_FIXED_FRAME_SIZE
- GCC uses this value to generate the above warning message. It
- represents the amount of fixed frame used by a function, not
- including space for any callee-saved registers, temporaries and
- user variables. You need only specify an upper bound for this
- amount and will normally use the default of four words.
-
- -- Macro: STACK_CHECK_MAX_VAR_SIZE
- The maximum size, in bytes, of an object that GCC will place in the
- fixed area of the stack frame when the user specifies
- `-fstack-check'. GCC computed the default from the values of the
- above macros and you will normally not need to override that
- default.
-
-
-File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling
-
-17.10.4 Registers That Address the Stack Frame
-----------------------------------------------
-
-This discusses registers that address the stack frame.
-
- -- Macro: STACK_POINTER_REGNUM
- The register number of the stack pointer register, which must also
- be a fixed register according to `FIXED_REGISTERS'. On most
- machines, the hardware determines which register this is.
-
- -- Macro: FRAME_POINTER_REGNUM
- The register number of the frame pointer register, which is used to
- access automatic variables in the stack frame. On some machines,
- the hardware determines which register this is. On other
- machines, you can choose any register you wish for this purpose.
-
- -- Macro: HARD_FRAME_POINTER_REGNUM
- On some machines the offset between the frame pointer and starting
- offset of the automatic variables is not known until after register
- allocation has been done (for example, because the saved registers
- are between these two locations). On those machines, define
- `FRAME_POINTER_REGNUM' the number of a special, fixed register to
- be used internally until the offset is known, and define
- `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number
- used for the frame pointer.
-
- You should define this macro only in the very rare circumstances
- when it is not possible to calculate the offset between the frame
- pointer and the automatic variables until after register
- allocation has been completed. When this macro is defined, you
- must also indicate in your definition of `ELIMINABLE_REGS' how to
- eliminate `FRAME_POINTER_REGNUM' into either
- `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'.
-
- Do not define this macro if it would be the same as
- `FRAME_POINTER_REGNUM'.
-
- -- Macro: ARG_POINTER_REGNUM
- The register number of the arg pointer register, which is used to
- access the function's argument list. On some machines, this is
- the same as the frame pointer register. On some machines, the
- hardware determines which register this is. On other machines,
- you can choose any register you wish for this purpose. If this is
- not the same register as the frame pointer register, then you must
- mark it as a fixed register according to `FIXED_REGISTERS', or
- arrange to be able to eliminate it (*note Elimination::).
-
- -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER
- Define this to a preprocessor constant that is nonzero if
- `hard_frame_pointer_rtx' and `frame_pointer_rtx' should be the
- same. The default definition is `(HARD_FRAME_POINTER_REGNUM ==
- FRAME_POINTER_REGNUM)'; you only need to define this macro if that
- definition is not suitable for use in preprocessor conditionals.
-
- -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER
- Define this to a preprocessor constant that is nonzero if
- `hard_frame_pointer_rtx' and `arg_pointer_rtx' should be the same.
- The default definition is `(HARD_FRAME_POINTER_REGNUM ==
- ARG_POINTER_REGNUM)'; you only need to define this macro if that
- definition is not suitable for use in preprocessor conditionals.
-
- -- Macro: RETURN_ADDRESS_POINTER_REGNUM
- The register number of the return address pointer register, which
- is used to access the current function's return address from the
- stack. On some machines, the return address is not at a fixed
- offset from the frame pointer or stack pointer or argument
- pointer. This register can be defined to point to the return
- address on the stack, and then be converted by `ELIMINABLE_REGS'
- into either the frame pointer or stack pointer.
-
- Do not define this macro unless there is no other way to get the
- return address from the stack.
-
- -- Macro: STATIC_CHAIN_REGNUM
- -- Macro: STATIC_CHAIN_INCOMING_REGNUM
- Register numbers used for passing a function's static chain
- pointer. If register windows are used, the register number as
- seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM',
- while the register number as seen by the calling function is
- `STATIC_CHAIN_REGNUM'. If these registers are the same,
- `STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
-
- The static chain register need not be a fixed register.
-
- If the static chain is passed in memory, these macros should not be
- defined; instead, the `TARGET_STATIC_CHAIN' hook should be used.
-
- -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL, bool
- INCOMING_P)
- This hook replaces the use of `STATIC_CHAIN_REGNUM' et al for
- targets that may use different static chain locations for different
- nested functions. This may be required if the target has function
- attributes that affect the calling conventions of the function and
- those calling conventions use different static chain locations.
-
- The default version of this hook uses `STATIC_CHAIN_REGNUM' et al.
-
- If the static chain is passed in memory, this hook should be used
- to provide rtx giving `mem' expressions that denote where they are
- stored. Often the `mem' expression as seen by the caller will be
- at an offset from the stack pointer and the `mem' expression as
- seen by the callee will be at an offset from the frame pointer. The
- variables `stack_pointer_rtx', `frame_pointer_rtx', and
- `arg_pointer_rtx' will have been initialized and should be used to
- refer to those items.
-
- -- Macro: DWARF_FRAME_REGISTERS
- This macro specifies the maximum number of hard registers that can
- be saved in a call frame. This is used to size data structures
- used in DWARF2 exception handling.
-
- Prior to GCC 3.0, this macro was needed in order to establish a
- stable exception handling ABI in the face of adding new hard
- registers for ISA extensions. In GCC 3.0 and later, the EH ABI is
- insulated from changes in the number of hard registers.
- Nevertheless, this macro can still be used to reduce the runtime
- memory requirements of the exception handling routines, which can
- be substantial if the ISA contains a lot of registers that are not
- call-saved.
-
- If this macro is not defined, it defaults to
- `FIRST_PSEUDO_REGISTER'.
-
- -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS
- This macro is similar to `DWARF_FRAME_REGISTERS', but is provided
- for backward compatibility in pre GCC 3.0 compiled code.
-
- If this macro is not defined, it defaults to
- `DWARF_FRAME_REGISTERS'.
-
- -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO)
- Define this macro if the target's representation for dwarf
- registers is different than the internal representation for unwind
- column. Given a dwarf register, this macro should return the
- internal unwind column number to use instead.
-
- See the PowerPC's SPE target for an example.
-
- -- Macro: DWARF_FRAME_REGNUM (REGNO)
- Define this macro if the target's representation for dwarf
- registers used in .eh_frame or .debug_frame is different from that
- used in other debug info sections. Given a GCC hard register
- number, this macro should return the .eh_frame register number.
- The default is `DBX_REGISTER_NUMBER (REGNO)'.
-
-
- -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH)
- Define this macro to map register numbers held in the call frame
- info that GCC has collected using `DWARF_FRAME_REGNUM' to those
- that should be output in .debug_frame (`FOR_EH' is zero) and
- .eh_frame (`FOR_EH' is nonzero). The default is to return `REGNO'.
-
-
-
-File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling
-
-17.10.5 Eliminating Frame Pointer and Arg Pointer
--------------------------------------------------
-
-This is about eliminating the frame pointer and arg pointer.
-
- -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void)
- This target hook should return `true' if a function must have and
- use a frame pointer. This target hook is called in the reload
- pass. If its return value is `true' the function will have a
- frame pointer.
-
- This target hook can in principle examine the current function and
- decide according to the facts, but on most machines the constant
- `false' or the constant `true' suffices. Use `false' when the
- machine allows code to be generated with no frame pointer, and
- doing so saves some time or space. Use `true' when there is no
- possible advantage to avoiding a frame pointer.
-
- In certain cases, the compiler does not know how to produce valid
- code without a frame pointer. The compiler recognizes those cases
- and automatically gives the function a frame pointer regardless of
- what `TARGET_FRAME_POINTER_REQUIRED' returns. You don't need to
- worry about them.
-
- In a function that does not require a frame pointer, the frame
- pointer register can be allocated for ordinary usage, unless you
- mark it as a fixed register. See `FIXED_REGISTERS' for more
- information.
-
- Default return value is `false'.
-
- -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)
- A C statement to store in the variable DEPTH-VAR the difference
- between the frame pointer and the stack pointer values immediately
- after the function prologue. The value would be computed from
- information such as the result of `get_frame_size ()' and the
- tables of registers `regs_ever_live' and `call_used_regs'.
-
- If `ELIMINABLE_REGS' is defined, this macro will be not be used and
- need not be defined. Otherwise, it must be defined even if
- `TARGET_FRAME_POINTER_REQUIRED' always returns true; in that case,
- you may set DEPTH-VAR to anything.
-
- -- Macro: ELIMINABLE_REGS
- If defined, this macro specifies a table of register pairs used to
- eliminate unneeded registers that point into the stack frame. If
- it is not defined, the only elimination attempted by the compiler
- is to replace references to the frame pointer with references to
- the stack pointer.
-
- The definition of this macro is a list of structure
- initializations, each of which specifies an original and
- replacement register.
-
- On some machines, the position of the argument pointer is not
- known until the compilation is completed. In such a case, a
- separate hard register must be used for the argument pointer.
- This register can be eliminated by replacing it with either the
- frame pointer or the argument pointer, depending on whether or not
- the frame pointer has been eliminated.
-
- In this case, you might specify:
- #define ELIMINABLE_REGS \
- {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
- {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
- {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
-
- Note that the elimination of the argument pointer with the stack
- pointer is specified first since that is the preferred elimination.
-
- -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const
- int TO_REG)
- This target hook should returns `true' if the compiler is allowed
- to try to replace register number FROM_REG with register number
- TO_REG. This target hook need only be defined if `ELIMINABLE_REGS'
- is defined, and will usually be `true', since most of the cases
- preventing register elimination are things that the compiler
- already knows about.
-
- Default return value is `true'.
-
- -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)
- This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It
- specifies the initial difference between the specified pair of
- registers. This macro must be defined if `ELIMINABLE_REGS' is
- defined.
-
-
-File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling
-
-17.10.6 Passing Function Arguments on the Stack
------------------------------------------------
-
-The macros in this section control how arguments are passed on the
-stack. See the following section for other macros that control passing
-certain arguments in registers.
-
- -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE)
- This target hook returns `true' if an argument declared in a
- prototype as an integral type smaller than `int' should actually be
- passed as an `int'. In addition to avoiding errors in certain
- cases of mismatch, it also makes for better code on certain
- machines. The default is to not promote prototypes.
-
- -- Macro: PUSH_ARGS
- A C expression. If nonzero, push insns will be used to pass
- outgoing arguments. If the target machine does not have a push
- instruction, set it to zero. That directs GCC to use an alternate
- strategy: to allocate the entire argument block and then store the
- arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING'
- must be defined too.
-
- -- Macro: PUSH_ARGS_REVERSED
- A C expression. If nonzero, function arguments will be evaluated
- from last to first, rather than from first to last. If this macro
- is not defined, it defaults to `PUSH_ARGS' on targets where the
- stack and args grow in opposite directions, and 0 otherwise.
-
- -- Macro: PUSH_ROUNDING (NPUSHED)
- A C expression that is the number of bytes actually pushed onto the
- stack when an instruction attempts to push NPUSHED bytes.
-
- On some machines, the definition
-
- #define PUSH_ROUNDING(BYTES) (BYTES)
-
- will suffice. But on other machines, instructions that appear to
- push one byte actually push two bytes in an attempt to maintain
- alignment. Then the definition should be
-
- #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
-
- If the value of this macro has a type, it should be an unsigned
- type.
-
- -- Macro: ACCUMULATE_OUTGOING_ARGS
- A C expression. If nonzero, the maximum amount of space required
- for outgoing arguments will be computed and placed into the
- variable `current_function_outgoing_args_size'. No space will be
- pushed onto the stack for each call; instead, the function
- prologue should increase the stack frame size by this amount.
-
- Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not
- proper.
-
- -- Macro: REG_PARM_STACK_SPACE (FNDECL)
- Define this macro if functions should assume that stack space has
- been allocated for arguments even when their values are passed in
- registers.
-
- The value of this macro is the size, in bytes, of the area
- reserved for arguments passed in registers for the function
- represented by FNDECL, which can be zero if GCC is calling a
- library function. The argument FNDECL can be the FUNCTION_DECL,
- or the type itself of the function.
-
- This space can be allocated by the caller, or be a part of the
- machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says
- which.
-
- -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE)
- Define this to a nonzero value if it is the responsibility of the
- caller to allocate the area reserved for arguments passed in
- registers when calling a function of FNTYPE. FNTYPE may be NULL
- if the function called is a library function.
-
- If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
- whether the space for these arguments counts in the value of
- `current_function_outgoing_args_size'.
-
- -- Macro: STACK_PARMS_IN_REG_PARM_AREA
- Define this macro if `REG_PARM_STACK_SPACE' is defined, but the
- stack parameters don't skip the area specified by it.
-
- Normally, when a parameter is not passed in registers, it is
- placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
- Defining this macro suppresses this behavior and causes the
- parameter to be passed on the stack in its natural location.
-
- -- Target Hook: int TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree
- FUNTYPE, int SIZE)
- This target hook returns the number of bytes of its own arguments
- that a function pops on returning, or 0 if the function pops no
- arguments and the caller must therefore pop them all after the
- function returns.
-
- FUNDECL is a C variable whose value is a tree node that describes
- the function in question. Normally it is a node of type
- `FUNCTION_DECL' that describes the declaration of the function.
- From this you can obtain the `DECL_ATTRIBUTES' of the function.
-
- FUNTYPE is a C variable whose value is a tree node that describes
- the function in question. Normally it is a node of type
- `FUNCTION_TYPE' that describes the data type of the function.
- From this it is possible to obtain the data types of the value and
- arguments (if known).
-
- When a call to a library function is being considered, FUNDECL
- will contain an identifier node for the library function. Thus, if
- you need to distinguish among various library functions, you can
- do so by their names. Note that "library function" in this
- context means a function used to perform arithmetic, whose name is
- known specially in the compiler and was not mentioned in the C
- code being compiled.
-
- SIZE is the number of bytes of arguments passed on the stack. If
- a variable number of bytes is passed, it is zero, and argument
- popping will always be the responsibility of the calling function.
-
- On the VAX, all functions always pop their arguments, so the
- definition of this macro is SIZE. On the 68000, using the standard
- calling convention, no functions pop their arguments, so the value
- of the macro is always 0 in this case. But an alternative calling
- convention is available in which functions that take a fixed
- number of arguments pop them but other functions (such as
- `printf') pop nothing (the caller pops all). When this convention
- is in use, FUNTYPE is examined to determine whether a function
- takes a fixed number of arguments.
-
- -- Macro: CALL_POPS_ARGS (CUM)
- A C expression that should indicate the number of bytes a call
- sequence pops off the stack. It is added to the value of
- `RETURN_POPS_ARGS' when compiling a function call.
-
- CUM is the variable in which all arguments to the called function
- have been accumulated.
-
- On certain architectures, such as the SH5, a call trampoline is
- used that pops certain registers off the stack, depending on the
- arguments that have been passed to the function. Since this is a
- property of the call site, not of the called function,
- `RETURN_POPS_ARGS' is not appropriate.
-
-
-File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling
-
-17.10.7 Passing Arguments in Registers
---------------------------------------
-
-This section describes the macros which let you control how various
-types of arguments are passed in registers or how they are arranged in
-the stack.
-
- -- Macro: FUNCTION_ARG (CUM, MODE, TYPE, NAMED)
- A C expression that controls whether a function argument is passed
- in a register, and which register.
-
- The arguments are CUM, which summarizes all the previous
- arguments; MODE, the machine mode of the argument; TYPE, the data
- type of the argument as a tree node or 0 if that is not known
- (which happens for C support library functions); and NAMED, which
- is 1 for an ordinary argument and 0 for nameless arguments that
- correspond to `...' in the called function's prototype. TYPE can
- be an incomplete type if a syntax error has previously occurred.
-
- The value of the expression is usually either a `reg' RTX for the
- hard register in which to pass the argument, or zero to pass the
- argument on the stack.
-
- For machines like the VAX and 68000, where normally all arguments
- are pushed, zero suffices as a definition.
-
- The value of the expression can also be a `parallel' RTX. This is
- used when an argument is passed in multiple locations. The mode
- of the `parallel' should be the mode of the entire argument. The
- `parallel' holds any number of `expr_list' pairs; each one
- describes where part of the argument is passed. In each
- `expr_list' the first operand must be a `reg' RTX for the hard
- register in which to pass this part of the argument, and the mode
- of the register RTX indicates how large this part of the argument
- is. The second operand of the `expr_list' is a `const_int' which
- gives the offset in bytes into the entire argument of where this
- part starts. As a special exception the first `expr_list' in the
- `parallel' RTX may have a first operand of zero. This indicates
- that the entire argument is also stored on the stack.
-
- The last time this macro is called, it is called with `MODE ==
- VOIDmode', and its result is passed to the `call' or `call_value'
- pattern as operands 2 and 3 respectively.
-
- The usual way to make the ISO library `stdarg.h' work on a machine
- where some arguments are usually passed in registers, is to cause
- nameless arguments to be passed on the stack instead. This is done
- by making `FUNCTION_ARG' return 0 whenever NAMED is 0.
-
- You may use the hook `targetm.calls.must_pass_in_stack' in the
- definition of this macro to determine if this argument is of a
- type that must be passed in the stack. If `REG_PARM_STACK_SPACE'
- is not defined and `FUNCTION_ARG' returns nonzero for such an
- argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is
- defined, the argument will be computed in the stack and then
- loaded into a register.
-
- -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (enum machine_mode
- MODE, const_tree TYPE)
- This target hook should return `true' if we should not pass TYPE
- solely in registers. The file `expr.h' defines a definition that
- is usually appropriate, refer to `expr.h' for additional
- documentation.
-
- -- Macro: FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)
- Define this macro if the target machine has "register windows", so
- that the register in which a function sees an arguments is not
- necessarily the same as the one in which the caller passed the
- argument.
-
- For such machines, `FUNCTION_ARG' computes the register in which
- the caller passes the value, and `FUNCTION_INCOMING_ARG' should be
- defined in a similar fashion to tell the function being called
- where the arguments will arrive.
-
- If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
- both purposes.
-
- -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (CUMULATIVE_ARGS *CUM,
- enum machine_mode MODE, tree TYPE, bool NAMED)
- This target hook returns the number of bytes at the beginning of an
- argument that must be put in registers. The value must be zero for
- arguments that are passed entirely in registers or that are
- entirely pushed on the stack.
-
- On some machines, certain arguments must be passed partially in
- registers and partially in memory. On these machines, typically
- the first few words of arguments are passed in registers, and the
- rest on the stack. If a multi-word argument (a `double' or a
- structure) crosses that boundary, its first few words must be
- passed in registers and the rest must be pushed. This macro tells
- the compiler when this occurs, and how many bytes should go in
- registers.
-
- `FUNCTION_ARG' for these arguments should return the first
- register to be used by the caller for this argument; likewise
- `FUNCTION_INCOMING_ARG', for the called function.
-
- -- Target Hook: bool TARGET_PASS_BY_REFERENCE (CUMULATIVE_ARGS *CUM,
- enum machine_mode MODE, const_tree TYPE, bool NAMED)
- This target hook should return `true' if an argument at the
- position indicated by CUM should be passed by reference. This
- predicate is queried after target independent reasons for being
- passed by reference, such as `TREE_ADDRESSABLE (type)'.
-
- If the hook returns true, a copy of that argument is made in
- memory and a pointer to the argument is passed instead of the
- argument itself. The pointer is passed in whatever way is
- appropriate for passing a pointer to that type.
-
- -- Target Hook: bool TARGET_CALLEE_COPIES (CUMULATIVE_ARGS *CUM, enum
- machine_mode MODE, const_tree TYPE, bool NAMED)
- The function argument described by the parameters to this hook is
- known to be passed by reference. The hook should return true if
- the function argument should be copied by the callee instead of
- copied by the caller.
-
- For any argument for which the hook returns true, if it can be
- determined that the argument is not modified, then a copy need not
- be generated.
-
- The default version of this hook always returns false.
-
- -- Macro: CUMULATIVE_ARGS
- A C type for declaring a variable that is used as the first
- argument of `FUNCTION_ARG' and other related values. For some
- target machines, the type `int' suffices and can hold the number
- of bytes of argument so far.
-
- There is no need to record in `CUMULATIVE_ARGS' anything about the
- arguments that have been passed on the stack. The compiler has
- other variables to keep track of that. For target machines on
- which all arguments are passed on the stack, there is no need to
- store anything in `CUMULATIVE_ARGS'; however, the data structure
- must exist and should not be empty, so use `int'.
-
- -- Macro: OVERRIDE_ABI_FORMAT (FNDECL)
- If defined, this macro is called before generating any code for a
- function, but after the CFUN descriptor for the function has been
- created. The back end may use this macro to update CFUN to
- reflect an ABI other than that which would normally be used by
- default. If the compiler is generating code for a
- compiler-generated function, FNDECL may be `NULL'.
-
- -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL,
- N_NAMED_ARGS)
- A C statement (sans semicolon) for initializing the variable CUM
- for the state at the beginning of the argument list. The variable
- has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node
- for the data type of the function which will receive the args, or
- 0 if the args are to a compiler support library function. For
- direct calls that are not libcalls, FNDECL contain the declaration
- node of the function. FNDECL is also set when
- `INIT_CUMULATIVE_ARGS' is used to find arguments for the function
- being compiled. N_NAMED_ARGS is set to the number of named
- arguments, including a structure return address if it is passed as
- a parameter, when making a call. When processing incoming
- arguments, N_NAMED_ARGS is set to -1.
-
- When processing a call to a compiler support library function,
- LIBNAME identifies which one. It is a `symbol_ref' rtx which
- contains the name of the function, as a string. LIBNAME is 0 when
- an ordinary C function call is being processed. Thus, each time
- this macro is called, either LIBNAME or FNTYPE is nonzero, but
- never both of them at once.
-
- -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME)
- Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls,
- it gets a `MODE' argument instead of FNTYPE, that would be `NULL'.
- INDIRECT would always be zero, too. If this macro is not defined,
- `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead.
-
- -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)
- Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
- finding the arguments for the function being compiled. If this
- macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead.
-
- The value passed for LIBNAME is always 0, since library routines
- with special calling conventions are never compiled with GCC. The
- argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'.
-
- -- Macro: FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)
- A C statement (sans semicolon) to update the summarizer variable
- CUM to advance past an argument in the argument list. The values
- MODE, TYPE and NAMED describe that argument. Once this is done,
- the variable CUM is suitable for analyzing the _following_
- argument with `FUNCTION_ARG', etc.
-
- This macro need not do anything if the argument in question was
- passed on the stack. The compiler knows how to track the amount
- of stack space used for arguments without any special help.
-
- -- Macro: FUNCTION_ARG_OFFSET (MODE, TYPE)
- If defined, a C expression that is the number of bytes to add to
- the offset of the argument passed in memory. This is needed for
- the SPU, which passes `char' and `short' arguments in the preferred
- slot that is in the middle of the quad word instead of starting at
- the top.
-
- -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE)
- If defined, a C expression which determines whether, and in which
- direction, to pad out an argument with extra space. The value
- should be of type `enum direction': either `upward' to pad above
- the argument, `downward' to pad below, or `none' to inhibit
- padding.
-
- The _amount_ of padding is always just enough to reach the next
- multiple of `TARGET_FUNCTION_ARG_BOUNDARY'; this macro does not
- control it.
-
- This macro has a default definition which is right for most
- systems. For little-endian machines, the default is to pad
- upward. For big-endian machines, the default is to pad downward
- for an argument of constant size shorter than an `int', and upward
- otherwise.
-
- -- Macro: PAD_VARARGS_DOWN
- If defined, a C expression which determines whether the default
- implementation of va_arg will attempt to pad down before reading
- the next argument, if that argument is smaller than its aligned
- space as controlled by `PARM_BOUNDARY'. If this macro is not
- defined, all such arguments are padded down if `BYTES_BIG_ENDIAN'
- is true.
-
- -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST)
- Specify padding for the last element of a block move between
- registers and memory. FIRST is nonzero if this is the only
- element. Defining this macro allows better control of register
- function parameters on big-endian machines, without using
- `PARALLEL' rtl. In particular, `MUST_PASS_IN_STACK' need not test
- padding and mode of types in registers, as there is no longer a
- "wrong" part of a register; For example, a three byte aggregate
- may be passed in the high part of a register if so required.
-
- -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (enum
- machine_mode MODE, const_tree TYPE)
- This hook returns the alignment boundary, in bits, of an argument
- with the specified mode and type. The default hook returns
- `PARM_BOUNDARY' for all arguments.
-
- -- Macro: FUNCTION_ARG_REGNO_P (REGNO)
- A C expression that is nonzero if REGNO is the number of a hard
- register in which function arguments are sometimes passed. This
- does _not_ include implicit arguments such as the static chain and
- the structure-value address. On many machines, no registers can be
- used for this purpose since all function arguments are pushed on
- the stack.
-
- -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE)
- This hook should return true if parameter of type TYPE are passed
- as two scalar parameters. By default, GCC will attempt to pack
- complex arguments into the target's word size. Some ABIs require
- complex arguments to be split and treated as their individual
- components. For example, on AIX64, complex floats should be
- passed in a pair of floating point registers, even though a
- complex float would fit in one 64-bit floating point register.
-
- The default value of this hook is `NULL', which is treated as
- always false.
-
- -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void)
- This hook returns a type node for `va_list' for the target. The
- default version of the hook returns `void*'.
-
- -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char
- **PNAME, tree *PTREE)
- This target hook is used in function `c_common_nodes_and_builtins'
- to iterate through the target specific builtin types for va_list.
- The variable IDX is used as iterator. PNAME has to be a pointer to
- a `const char *' and PTREE a pointer to a `tree' typed variable.
- The arguments PNAME and PTREE are used to store the result of this
- macro and are set to the name of the va_list builtin type and its
- internal type. If the return value of this macro is zero, then
- there is no more element. Otherwise the IDX should be increased
- for the next call of this macro to iterate through all types.
-
- -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL)
- This hook returns the va_list type of the calling convention
- specified by FNDECL. The default version of this hook returns
- `va_list_type_node'.
-
- -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE)
- This hook returns the va_list type of the calling convention
- specified by the type of TYPE. If TYPE is not a valid va_list
- type, it returns `NULL_TREE'.
-
- -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree
- TYPE, gimple_seq *PRE_P, gimple_seq *POST_P)
- This hook performs target-specific gimplification of
- `VA_ARG_EXPR'. The first two parameters correspond to the
- arguments to `va_arg'; the latter two are as in
- `gimplify.c:gimplify_expr'.
-
- -- Target Hook: bool TARGET_VALID_POINTER_MODE (enum machine_mode MODE)
- Define this to return nonzero if the port can handle pointers with
- machine mode MODE. The default version of this hook returns true
- for both `ptr_mode' and `Pmode'.
-
- -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (struct ao_ref_s *REF)
- Define this to return nonzero if the memory reference REF may
- alias with the system C library errno location. The default
- version of this hook assumes the system C library errno location
- is either a declaration of type int or accessed by dereferencing
- a pointer to int.
-
- -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (enum machine_mode
- MODE)
- Define this to return nonzero if the port is prepared to handle
- insns involving scalar mode MODE. For a scalar mode to be
- considered supported, all the basic arithmetic and comparisons
- must work.
-
- The default version of this hook returns true for any mode
- required to handle the basic C types (as defined by the port).
- Included here are the double-word arithmetic supported by the code
- in `optabs.c'.
-
- -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (enum machine_mode
- MODE)
- Define this to return nonzero if the port is prepared to handle
- insns involving vector mode MODE. At the very least, it must have
- move patterns for this mode.
-
- -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P (enum
- machine_mode MODE)
- Define this to return nonzero for machine modes for which the port
- has small register classes. If this target hook returns nonzero
- for a given MODE, the compiler will try to minimize the lifetime
- of registers in MODE. The hook may be called with `VOIDmode' as
- argument. In this case, the hook is expected to return nonzero if
- it returns nonzero for any mode.
-
- On some machines, it is risky to let hard registers live across
- arbitrary insns. Typically, these machines have instructions that
- require values to be in specific registers (like an accumulator),
- and reload will fail if the required hard register is used for
- another purpose across such an insn.
-
- Passes before reload do not know which hard registers will be used
- in an instruction, but the machine modes of the registers set or
- used in the instruction are already known. And for some machines,
- register classes are small for, say, integer registers but not for
- floating point registers. For example, the AMD x86-64
- architecture requires specific registers for the legacy x86
- integer instructions, but there are many SSE registers for
- floating point operations. On such targets, a good strategy may
- be to return nonzero from this hook for `INTEGRAL_MODE_P' machine
- modes but zero for the SSE register classes.
-
- The default version of this hook returns false for any mode. It
- is always safe to redefine this hook to return with a nonzero
- value. But if you unnecessarily define it, you will reduce the
- amount of optimizations that can be performed in some cases. If
- you do not define this hook to return a nonzero value when it is
- required, the compiler will run out of spill registers and print a
- fatal error message.
-
- -- Target Hook: unsigned int TARGET_FLAGS_REGNUM
- If the target has a dedicated flags register, and it needs to use
- the post-reload comparison elimination pass, then this value
- should be set appropriately.
-
-
-File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling
-
-17.10.8 How Scalar Function Values Are Returned
------------------------------------------------
-
-This section discusses the macros that control returning scalars as
-values--values that can fit in registers.
-
- -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE,
- const_tree FN_DECL_OR_TYPE, bool OUTGOING)
- Define this to return an RTX representing the place where a
- function returns or receives a value of data type RET_TYPE, a tree
- node representing a data type. FN_DECL_OR_TYPE is a tree node
- representing `FUNCTION_DECL' or `FUNCTION_TYPE' of a function
- being called. If OUTGOING is false, the hook should compute the
- register in which the caller will see the return value.
- Otherwise, the hook should return an RTX representing the place
- where a function returns a value.
-
- On many machines, only `TYPE_MODE (RET_TYPE)' is relevant.
- (Actually, on most machines, scalar values are returned in the same
- place regardless of mode.) The value of the expression is usually
- a `reg' RTX for the hard register where the return value is stored.
- The value can also be a `parallel' RTX, if the return value is in
- multiple places. See `FUNCTION_ARG' for an explanation of the
- `parallel' form. Note that the callee will populate every
- location specified in the `parallel', but if the first element of
- the `parallel' contains the whole return value, callers will use
- that element as the canonical location and ignore the others. The
- m68k port uses this type of `parallel' to return pointers in both
- `%a0' (the canonical location) and `%d0'.
-
- If `TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply
- the same promotion rules specified in `PROMOTE_MODE' if VALTYPE is
- a scalar type.
-
- If the precise function being called is known, FUNC is a tree node
- (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
- makes it possible to use a different value-returning convention
- for specific functions when all their calls are known.
-
- Some target machines have "register windows" so that the register
- in which a function returns its value is not the same as the one
- in which the caller sees the value. For such machines, you should
- return different RTX depending on OUTGOING.
-
- `TARGET_FUNCTION_VALUE' is not used for return values with
- aggregate data types, because these are returned in another way.
- See `TARGET_STRUCT_VALUE_RTX' and related macros, below.
-
- -- Macro: FUNCTION_VALUE (VALTYPE, FUNC)
- This macro has been deprecated. Use `TARGET_FUNCTION_VALUE' for a
- new target instead.
-
- -- Macro: LIBCALL_VALUE (MODE)
- A C expression to create an RTX representing the place where a
- library function returns a value of mode MODE.
-
- Note that "library function" in this context means a compiler
- support routine, used to perform arithmetic, whose name is known
- specially by the compiler and was not mentioned in the C code being
- compiled.
-
- -- Target Hook: rtx TARGET_LIBCALL_VALUE (enum machine_mode MODE,
- const_rtx FUN)
- Define this hook if the back-end needs to know the name of the
- libcall function in order to determine where the result should be
- returned.
-
- The mode of the result is given by MODE and the name of the called
- library function is given by FUN. The hook should return an RTX
- representing the place where the library function result will be
- returned.
-
- If this hook is not defined, then LIBCALL_VALUE will be used.
-
- -- Macro: FUNCTION_VALUE_REGNO_P (REGNO)
- A C expression that is nonzero if REGNO is the number of a hard
- register in which the values of called function may come back.
-
- A register whose use for returning values is limited to serving as
- the second of a pair (for a value of type `double', say) need not
- be recognized by this macro. So for most machines, this definition
- suffices:
-
- #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
-
- If the machine has register windows, so that the caller and the
- called function use different registers for the return value, this
- macro should recognize only the caller's register numbers.
-
- This macro has been deprecated. Use
- `TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead.
-
- -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int
- REGNO)
- A target hook that return `true' if REGNO is the number of a hard
- register in which the values of called function may come back.
-
- A register whose use for returning values is limited to serving as
- the second of a pair (for a value of type `double', say) need not
- be recognized by this target hook.
-
- If the machine has register windows, so that the caller and the
- called function use different registers for the return value, this
- target hook should recognize only the caller's register numbers.
-
- If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be
- used.
-
- -- Macro: APPLY_RESULT_SIZE
- Define this macro if `untyped_call' and `untyped_return' need more
- space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and
- restoring an arbitrary return value.
-
- -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE)
- This hook should return true if values of type TYPE are returned
- at the most significant end of a register (in other words, if they
- are padded at the least significant end). You can assume that TYPE
- is returned in a register; the caller is required to check this.
-
- Note that the register provided by `TARGET_FUNCTION_VALUE' must be
- able to hold the complete return value. For example, if a 1-, 2-
- or 3-byte structure is returned at the most significant end of a
- 4-byte register, `TARGET_FUNCTION_VALUE' should provide an
- `SImode' rtx.
-
-
-File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling
-
-17.10.9 How Large Values Are Returned
--------------------------------------
-
-When a function value's mode is `BLKmode' (and in some other cases),
-the value is not returned according to `TARGET_FUNCTION_VALUE' (*note
-Scalar Return::). Instead, the caller passes the address of a block of
-memory in which the value should be stored. This address is called the
-"structure value address".
-
- This section describes how to control returning structure values in
-memory.
-
- -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE,
- const_tree FNTYPE)
- This target hook should return a nonzero value to say to return the
- function value in memory, just as large structures are always
- returned. Here TYPE will be the data type of the value, and FNTYPE
- will be the type of the function doing the returning, or `NULL' for
- libcalls.
-
- Note that values of mode `BLKmode' must be explicitly handled by
- this function. Also, the option `-fpcc-struct-return' takes
- effect regardless of this macro. On most systems, it is possible
- to leave the hook undefined; this causes a default definition to
- be used, whose value is the constant 1 for `BLKmode' values, and 0
- otherwise.
-
- Do not use this hook to indicate that structures and unions should
- always be returned in memory. You should instead use
- `DEFAULT_PCC_STRUCT_RETURN' to indicate this.
-
- -- Macro: DEFAULT_PCC_STRUCT_RETURN
- Define this macro to be 1 if all structure and union return values
- must be in memory. Since this results in slower code, this should
- be defined only if needed for compatibility with other compilers
- or with an ABI. If you define this macro to be 0, then the
- conventions used for structure and union return values are decided
- by the `TARGET_RETURN_IN_MEMORY' target hook.
-
- If not defined, this defaults to the value 1.
-
- -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING)
- This target hook should return the location of the structure value
- address (normally a `mem' or `reg'), or 0 if the address is passed
- as an "invisible" first argument. Note that FNDECL may be `NULL',
- for libcalls. You do not need to define this target hook if the
- address is always passed as an "invisible" first argument.
-
- On some architectures the place where the structure value address
- is found by the called function is not the same place that the
- caller put it. This can be due to register windows, or it could
- be because the function prologue moves it to a different place.
- INCOMING is `1' or `2' when the location is needed in the context
- of the called function, and `0' in the context of the caller.
-
- If INCOMING is nonzero and the address is to be found on the
- stack, return a `mem' which refers to the frame pointer. If
- INCOMING is `2', the result is being used to fetch the structure
- value address at the beginning of a function. If you need to emit
- adjusting code, you should do it at this point.
-
- -- Macro: PCC_STATIC_STRUCT_RETURN
- Define this macro if the usual system convention on the target
- machine for returning structures and unions is for the called
- function to return the address of a static variable containing the
- value.
-
- Do not define this if the usual system convention is for the
- caller to pass an address to the subroutine.
-
- This macro has effect in `-fpcc-struct-return' mode, but it does
- nothing when you use `-freg-struct-return' mode.
-
- -- Target Hook: enum machine_mode TARGET_GET_RAW_RESULT_MODE (int
- REGNO)
- This target hook returns the mode to be used when accessing raw
- return registers in `__builtin_return'. Define this macro if the
- value in REG_RAW_MODE is not correct.
-
- -- Target Hook: enum machine_mode TARGET_GET_RAW_ARG_MODE (int REGNO)
- This target hook returns the mode to be used when accessing raw
- argument registers in `__builtin_apply_args'. Define this macro
- if the value in REG_RAW_MODE is not correct.
-
-
-File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling
-
-17.10.10 Caller-Saves Register Allocation
------------------------------------------
-
-If you enable it, GCC can save registers around function calls. This
-makes it possible to use call-clobbered registers to hold variables that
-must live across calls.
-
- -- Macro: CALLER_SAVE_PROFITABLE (REFS, CALLS)
- A C expression to determine whether it is worthwhile to consider
- placing a pseudo-register in a call-clobbered hard register and
- saving and restoring it around each function call. The expression
- should be 1 when this is worth doing, and 0 otherwise.
-
- If you don't define this macro, a default is used which is good on
- most machines: `4 * CALLS < REFS'.
-
- -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS)
- A C expression specifying which mode is required for saving NREGS
- of a pseudo-register in call-clobbered hard register REGNO. If
- REGNO is unsuitable for caller save, `VOIDmode' should be
- returned. For most machines this macro need not be defined since
- GCC will select the smallest suitable mode.
-
-
-File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling
-
-17.10.11 Function Entry and Exit
---------------------------------
-
-This section describes the macros that output function entry
-("prologue") and exit ("epilogue") code.
-
- -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE,
- HOST_WIDE_INT SIZE)
- If defined, a function that outputs the assembler code for entry
- to a function. The prologue is responsible for setting up the
- stack frame, initializing the frame pointer register, saving
- registers that must be saved, and allocating SIZE additional bytes
- of storage for the local variables. SIZE is an integer. FILE is
- a stdio stream to which the assembler code should be output.
-
- The label for the beginning of the function need not be output by
- this macro. That has already been done when the macro is run.
-
- To determine which registers to save, the macro can refer to the
- array `regs_ever_live': element R is nonzero if hard register R is
- used anywhere within the function. This implies the function
- prologue should save register R, provided it is not one of the
- call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must
- likewise use `regs_ever_live'.)
-
- On machines that have "register windows", the function entry code
- does not save on the stack the registers that are in the windows,
- even if they are supposed to be preserved by function calls;
- instead it takes appropriate steps to "push" the register stack,
- if any non-call-used registers are used in the function.
-
- On machines where functions may or may not have frame-pointers, the
- function entry code must vary accordingly; it must set up the frame
- pointer if one is wanted, and not otherwise. To determine whether
- a frame pointer is in wanted, the macro can refer to the variable
- `frame_pointer_needed'. The variable's value will be 1 at run
- time in a function that needs a frame pointer. *Note
- Elimination::.
-
- The function entry code is responsible for allocating any stack
- space required for the function. This stack space consists of the
- regions listed below. In most cases, these regions are allocated
- in the order listed, with the last listed region closest to the
- top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is
- defined, and the highest address if it is not defined). You can
- use a different order for a machine if doing so is more convenient
- or required for compatibility reasons. Except in cases where
- required by standard or by a debugger, there is no reason why the
- stack layout used by GCC need agree with that used by other
- compilers for a machine.
-
- -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE)
- If defined, a function that outputs assembler code at the end of a
- prologue. This should be used when the function prologue is being
- emitted as RTL, and you have some extra assembler that needs to be
- emitted. *Note prologue instruction pattern::.
-
- -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE)
- If defined, a function that outputs assembler code at the start of
- an epilogue. This should be used when the function epilogue is
- being emitted as RTL, and you have some extra assembler that needs
- to be emitted. *Note epilogue instruction pattern::.
-
- -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE,
- HOST_WIDE_INT SIZE)
- If defined, a function that outputs the assembler code for exit
- from a function. The epilogue is responsible for restoring the
- saved registers and stack pointer to their values when the
- function was called, and returning control to the caller. This
- macro takes the same arguments as the macro
- `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are
- determined from `regs_ever_live' and `CALL_USED_REGISTERS' in the
- same way.
-
- On some machines, there is a single instruction that does all the
- work of returning from the function. On these machines, give that
- instruction the name `return' and do not define the macro
- `TARGET_ASM_FUNCTION_EPILOGUE' at all.
-
- Do not define a pattern named `return' if you want the
- `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target
- switches to control whether return instructions or epilogues are
- used, define a `return' pattern with a validity condition that
- tests the target switches appropriately. If the `return'
- pattern's validity condition is false, epilogues will be used.
-
- On machines where functions may or may not have frame-pointers, the
- function exit code must vary accordingly. Sometimes the code for
- these two cases is completely different. To determine whether a
- frame pointer is wanted, the macro can refer to the variable
- `frame_pointer_needed'. The variable's value will be 1 when
- compiling a function that needs a frame pointer.
-
- Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and
- `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially.
- The C variable `current_function_is_leaf' is nonzero for such a
- function. *Note Leaf Functions::.
-
- On some machines, some functions pop their arguments on exit while
- others leave that for the caller to do. For example, the 68020
- when given `-mrtd' pops arguments in functions that take a fixed
- number of arguments.
-
- Your definition of the macro `RETURN_POPS_ARGS' decides which
- functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE'
- needs to know what was decided. The number of bytes of the current
- function's arguments that this function should pop is available in
- `crtl->args.pops_args'. *Note Scalar Return::.
-
- * A region of `current_function_pretend_args_size' bytes of
- uninitialized space just underneath the first argument arriving on
- the stack. (This may not be at the very start of the allocated
- stack region if the calling sequence has pushed anything else
- since pushing the stack arguments. But usually, on such machines,
- nothing else has been pushed yet, because the function prologue
- itself does all the pushing.) This region is used on machines
- where an argument may be passed partly in registers and partly in
- memory, and, in some cases to support the features in `<stdarg.h>'.
-
- * An area of memory used to save certain registers used by the
- function. The size of this area, which may also include space for
- such things as the return address and pointers to previous stack
- frames, is machine-specific and usually depends on which registers
- have been used in the function. Machines with register windows
- often do not require a save area.
-
- * A region of at least SIZE bytes, possibly rounded up to an
- allocation boundary, to contain the local variables of the
- function. On some machines, this region and the save area may
- occur in the opposite order, with the save area closer to the top
- of the stack.
-
- * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a region of
- `current_function_outgoing_args_size' bytes to be used for outgoing
- argument lists of the function. *Note Stack Arguments::.
-
- -- Macro: EXIT_IGNORE_STACK
- Define this macro as a C expression that is nonzero if the return
- instruction or the function epilogue ignores the value of the stack
- pointer; in other words, if it is safe to delete an instruction to
- adjust the stack pointer before a return from the function. The
- default is 0.
-
- Note that this macro's value is relevant only for functions for
- which frame pointers are maintained. It is never safe to delete a
- final stack adjustment in a function that has no frame pointer,
- and the compiler knows this regardless of `EXIT_IGNORE_STACK'.
-
- -- Macro: EPILOGUE_USES (REGNO)
- Define this macro as a C expression that is nonzero for registers
- that are used by the epilogue or the `return' pattern. The stack
- and frame pointer registers are already assumed to be used as
- needed.
-
- -- Macro: EH_USES (REGNO)
- Define this macro as a C expression that is nonzero for registers
- that are used by the exception handling mechanism, and so should
- be considered live on entry to an exception edge.
-
- -- Macro: DELAY_SLOTS_FOR_EPILOGUE
- Define this macro if the function epilogue contains delay slots to
- which instructions from the rest of the function can be "moved".
- The definition should be a C expression whose value is an integer
- representing the number of delay slots there.
-
- -- Macro: ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)
- A C expression that returns 1 if INSN can be placed in delay slot
- number N of the epilogue.
-
- The argument N is an integer which identifies the delay slot now
- being considered (since different slots may have different rules of
- eligibility). It is never negative and is always less than the
- number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE'
- returns). If you reject a particular insn for a given delay slot,
- in principle, it may be reconsidered for a subsequent delay slot.
- Also, other insns may (at least in principle) be considered for
- the so far unfilled delay slot.
-
- The insns accepted to fill the epilogue delay slots are put in an
- RTL list made with `insn_list' objects, stored in the variable
- `current_function_epilogue_delay_list'. The insn for the first
- delay slot comes first in the list. Your definition of the macro
- `TARGET_ASM_FUNCTION_EPILOGUE' should fill the delay slots by
- outputting the insns in this list, usually by calling
- `final_scan_insn'.
-
- You need not define this macro if you did not define
- `DELAY_SLOTS_FOR_EPILOGUE'.
-
- -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree
- THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT
- VCALL_OFFSET, tree FUNCTION)
- A function that outputs the assembler code for a thunk function,
- used to implement C++ virtual function calls with multiple
- inheritance. The thunk acts as a wrapper around a virtual
- function, adjusting the implicit object parameter before handing
- control off to the real function.
-
- First, emit code to add the integer DELTA to the location that
- contains the incoming first argument. Assume that this argument
- contains a pointer, and is the one used to pass the `this' pointer
- in C++. This is the incoming argument _before_ the function
- prologue, e.g. `%o0' on a sparc. The addition must preserve the
- values of all other incoming arguments.
-
- Then, if VCALL_OFFSET is nonzero, an additional adjustment should
- be made after adding `delta'. In particular, if P is the adjusted
- pointer, the following adjustment should be made:
-
- p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)]
-
- After the additions, emit code to jump to FUNCTION, which is a
- `FUNCTION_DECL'. This is a direct pure jump, not a call, and does
- not touch the return address. Hence returning from FUNCTION will
- return to whoever called the current `thunk'.
-
- The effect must be as if FUNCTION had been called directly with
- the adjusted first argument. This macro is responsible for
- emitting all of the code for a thunk function;
- `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE'
- are not invoked.
-
- The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already
- been extracted from it.) It might possibly be useful on some
- targets, but probably not.
-
- If you do not define this macro, the target-independent code in
- the C++ front end will generate a less efficient heavyweight thunk
- that calls FUNCTION instead of jumping to it. The generic
- approach does not support varargs.
-
- -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree
- THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT
- VCALL_OFFSET, const_tree FUNCTION)
- A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would
- be able to output the assembler code for the thunk function
- specified by the arguments it is passed, and false otherwise. In
- the latter case, the generic approach will be used by the C++
- front end, with the limitations previously exposed.
-
-
-File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling
-
-17.10.12 Generating Code for Profiling
---------------------------------------
-
-These macros will help you generate code for profiling.
-
- -- Macro: FUNCTION_PROFILER (FILE, LABELNO)
- A C statement or compound statement to output to FILE some
- assembler code to call the profiling subroutine `mcount'.
-
- The details of how `mcount' expects to be called are determined by
- your operating system environment, not by GCC. To figure them out,
- compile a small program for profiling using the system's installed
- C compiler and look at the assembler code that results.
-
- Older implementations of `mcount' expect the address of a counter
- variable to be loaded into some register. The name of this
- variable is `LP' followed by the number LABELNO, so you would
- generate the name using `LP%d' in a `fprintf'.
-
- -- Macro: PROFILE_HOOK
- A C statement or compound statement to output to FILE some assembly
- code to call the profiling subroutine `mcount' even the target does
- not support profiling.
-
- -- Macro: NO_PROFILE_COUNTERS
- Define this macro to be an expression with a nonzero value if the
- `mcount' subroutine on your system does not need a counter variable
- allocated for each function. This is true for almost all modern
- implementations. If you define this macro, you must not use the
- LABELNO argument to `FUNCTION_PROFILER'.
-
- -- Macro: PROFILE_BEFORE_PROLOGUE
- Define this macro if the code for function profiling should come
- before the function prologue. Normally, the profiling code comes
- after.
-
-
-File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling
-
-17.10.13 Permitting tail calls
-------------------------------
-
- -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree
- EXP)
- True if it is ok to do sibling call optimization for the specified
- call expression EXP. DECL will be the called function, or `NULL'
- if this is an indirect call.
-
- It is not uncommon for limitations of calling conventions to
- prevent tail calls to functions outside the current unit of
- translation, or during PIC compilation. The hook is used to
- enforce these restrictions, as the `sibcall' md pattern can not
- fail, or fall over to a "normal" call. The criteria for
- successful sibling call optimization may vary greatly between
- different architectures.
-
- -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS)
- Add any hard registers to REGS that are live on entry to the
- function. This hook only needs to be defined to provide registers
- that cannot be found by examination of FUNCTION_ARG_REGNO_P, the
- callee saved registers, STATIC_CHAIN_INCOMING_REGNUM,
- STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX,
- FRAME_POINTER_REGNUM, EH_USES, FRAME_POINTER_REGNUM,
- ARG_POINTER_REGNUM, and the PIC_OFFSET_TABLE_REGNUM.
-
-
-File: gccint.info, Node: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling
-
-17.10.14 Stack smashing protection
-----------------------------------
-
- -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void)
- This hook returns a `DECL' node for the external variable to use
- for the stack protection guard. This variable is initialized by
- the runtime to some random value and is used to initialize the
- guard value that is placed at the top of the local stack frame.
- The type of this variable must be `ptr_type_node'.
-
- The default version of this hook creates a variable called
- `__stack_chk_guard', which is normally defined in `libgcc2.c'.
-
- -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void)
- This hook returns a tree expression that alerts the runtime that
- the stack protect guard variable has been modified. This
- expression should involve a call to a `noreturn' function.
-
- The default version of this hook invokes a function called
- `__stack_chk_fail', taking no arguments. This function is
- normally defined in `libgcc2.c'.
-
- -- Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, struct
- gcc_options *OPTS)
- Whether this target supports splitting the stack when the options
- described in OPTS have been passed. This is called after options
- have been parsed, so the target may reject splitting the stack in
- some configurations. The default version of this hook returns
- false. If REPORT is true, this function may issue a warning or
- error; if REPORT is false, it must simply return a value
-
-
-File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros
-
-17.11 Implementing the Varargs Macros
-=====================================
-
-GCC comes with an implementation of `<varargs.h>' and `<stdarg.h>' that
-work without change on machines that pass arguments on the stack.
-Other machines require their own implementations of varargs, and the
-two machine independent header files must have conditionals to include
-it.
-
- ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in the
-calling convention for `va_start'. The traditional implementation
-takes just one argument, which is the variable in which to store the
-argument pointer. The ISO implementation of `va_start' takes an
-additional second argument. The user is supposed to write the last
-named argument of the function here.
-
- However, `va_start' should not use this argument. The way to find the
-end of the named arguments is with the built-in functions described
-below.
-
- -- Macro: __builtin_saveregs ()
- Use this built-in function to save the argument registers in
- memory so that the varargs mechanism can access them. Both ISO
- and traditional versions of `va_start' must use
- `__builtin_saveregs', unless you use
- `TARGET_SETUP_INCOMING_VARARGS' (see below) instead.
-
- On some machines, `__builtin_saveregs' is open-coded under the
- control of the target hook `TARGET_EXPAND_BUILTIN_SAVEREGS'. On
- other machines, it calls a routine written in assembler language,
- found in `libgcc2.c'.
-
- Code generated for the call to `__builtin_saveregs' appears at the
- beginning of the function, as opposed to where the call to
- `__builtin_saveregs' is written, regardless of what the code is.
- This is because the registers must be saved before the function
- starts to use them for its own purposes.
-
- -- Macro: __builtin_next_arg (LASTARG)
- This builtin returns the address of the first anonymous stack
- argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns
- the address of the location above the first anonymous stack
- argument. Use it in `va_start' to initialize the pointer for
- fetching arguments from the stack. Also use it in `va_start' to
- verify that the second parameter LASTARG is the last named argument
- of the current function.
-
- -- Macro: __builtin_classify_type (OBJECT)
- Since each machine has its own conventions for which data types are
- passed in which kind of register, your implementation of `va_arg'
- has to embody these conventions. The easiest way to categorize the
- specified data type is to use `__builtin_classify_type' together
- with `sizeof' and `__alignof__'.
-
- `__builtin_classify_type' ignores the value of OBJECT, considering
- only its data type. It returns an integer describing what kind of
- type that is--integer, floating, pointer, structure, and so on.
-
- The file `typeclass.h' defines an enumeration that you can use to
- interpret the values of `__builtin_classify_type'.
-
- These machine description macros help implement varargs:
-
- -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void)
- If defined, this hook produces the machine-specific code for a
- call to `__builtin_saveregs'. This code will be moved to the very
- beginning of the function, before any parameter access are made.
- The return value of this function should be an RTX that contains
- the value to use as the return of `__builtin_saveregs'.
-
- -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (CUMULATIVE_ARGS
- *ARGS_SO_FAR, enum machine_mode MODE, tree TYPE, int
- *PRETEND_ARGS_SIZE, int SECOND_TIME)
- This target hook offers an alternative to using
- `__builtin_saveregs' and defining the hook
- `TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous
- register arguments into the stack so that all the arguments appear
- to have been passed consecutively on the stack. Once this is
- done, you can use the standard implementation of varargs that
- works for machines that pass all their arguments on the stack.
-
- The argument ARGS_SO_FAR points to the `CUMULATIVE_ARGS' data
- structure, containing the values that are obtained after
- processing the named arguments. The arguments MODE and TYPE
- describe the last named argument--its machine mode and its data
- type as a tree node.
-
- The target hook should do two things: first, push onto the stack
- all the argument registers _not_ used for the named arguments, and
- second, store the size of the data thus pushed into the
- `int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value
- that you store here will serve as additional offset for setting up
- the stack frame.
-
- Because you must generate code to push the anonymous arguments at
- compile time without knowing their data types,
- `TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that
- have just a single category of argument register and use it
- uniformly for all data types.
-
- If the argument SECOND_TIME is nonzero, it means that the
- arguments of the function are being analyzed for the second time.
- This happens for an inline function, which is not actually
- compiled until the end of the source file. The hook
- `TARGET_SETUP_INCOMING_VARARGS' should not generate any
- instructions in this case.
-
- -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (CUMULATIVE_ARGS
- *CA)
- Define this hook to return `true' if the location where a function
- argument is passed depends on whether or not it is a named
- argument.
-
- This hook controls how the NAMED argument to `FUNCTION_ARG' is set
- for varargs and stdarg functions. If this hook returns `true',
- the NAMED argument is always true for named arguments, and false
- for unnamed arguments. If it returns `false', but
- `TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns `true', then all
- arguments are treated as named. Otherwise, all named arguments
- except the last are treated as named.
-
- You need not define this hook if it always returns `false'.
-
- -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED
- (CUMULATIVE_ARGS *CA)
- If you need to conditionally change ABIs so that one works with
- `TARGET_SETUP_INCOMING_VARARGS', but the other works like neither
- `TARGET_SETUP_INCOMING_VARARGS' nor
- `TARGET_STRICT_ARGUMENT_NAMING' was defined, then define this hook
- to return `true' if `TARGET_SETUP_INCOMING_VARARGS' is used,
- `false' otherwise. Otherwise, you should not define this hook.
-
-
-File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros
-
-17.12 Trampolines for Nested Functions
-======================================
-
-A "trampoline" is a small piece of code that is created at run time
-when the address of a nested function is taken. It normally resides on
-the stack, in the stack frame of the containing function. These macros
-tell GCC how to generate code to allocate and initialize a trampoline.
-
- The instructions in the trampoline must do two things: load a constant
-address into the static chain register, and jump to the real address of
-the nested function. On CISC machines such as the m68k, this requires
-two instructions, a move immediate and a jump. Then the two addresses
-exist in the trampoline as word-long immediate operands. On RISC
-machines, it is often necessary to load each address into a register in
-two parts. Then pieces of each address form separate immediate
-operands.
-
- The code generated to initialize the trampoline must store the variable
-parts--the static chain value and the function address--into the
-immediate operands of the instructions. On a CISC machine, this is
-simply a matter of copying each address to a memory reference at the
-proper offset from the start of the trampoline. On a RISC machine, it
-may be necessary to take out pieces of the address and store them
-separately.
-
- -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F)
- This hook is called by `assemble_trampoline_template' to output,
- on the stream F, assembler code for a block of data that contains
- the constant parts of a trampoline. This code should not include a
- label--the label is taken care of automatically.
-
- If you do not define this hook, it means no template is needed for
- the target. Do not define this hook on systems where the block
- move code to copy the trampoline into place would be larger than
- the code to generate it on the spot.
-
- -- Macro: TRAMPOLINE_SECTION
- Return the section into which the trampoline template is to be
- placed (*note Sections::). The default value is
- `readonly_data_section'.
-
- -- Macro: TRAMPOLINE_SIZE
- A C expression for the size in bytes of the trampoline, as an
- integer.
-
- -- Macro: TRAMPOLINE_ALIGNMENT
- Alignment required for trampolines, in bits.
-
- If you don't define this macro, the value of `FUNCTION_ALIGNMENT'
- is used for aligning trampolines.
-
- -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL,
- rtx STATIC_CHAIN)
- This hook is called to initialize a trampoline. M_TRAMP is an RTX
- for the memory block for the trampoline; FNDECL is the
- `FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX
- for the static chain value that should be passed to the function
- when it is called.
-
- If the target defines `TARGET_ASM_TRAMPOLINE_TEMPLATE', then the
- first thing this hook should do is emit a block move into M_TRAMP
- from the memory block returned by `assemble_trampoline_template'.
- Note that the block move need only cover the constant parts of the
- trampoline. If the target isolates the variable parts of the
- trampoline to the end, not all `TRAMPOLINE_SIZE' bytes need be
- copied.
-
- If the target requires any other actions, such as flushing caches
- or enabling stack execution, these actions should be performed
- after initializing the trampoline proper.
-
- -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR)
- This hook should perform any machine-specific adjustment in the
- address of the trampoline. Its argument contains the address of
- the memory block that was passed to `TARGET_TRAMPOLINE_INIT'. In
- case the address to be used for a function call should be
- different from the address at which the template was stored, the
- different address should be returned; otherwise ADDR should be
- returned unchanged. If this hook is not defined, ADDR will be
- used for function calls.
-
- Implementing trampolines is difficult on many machines because they
-have separate instruction and data caches. Writing into a stack
-location fails to clear the memory in the instruction cache, so when
-the program jumps to that location, it executes the old contents.
-
- Here are two possible solutions. One is to clear the relevant parts of
-the instruction cache whenever a trampoline is set up. The other is to
-make all trampolines identical, by having them jump to a standard
-subroutine. The former technique makes trampoline execution faster; the
-latter makes initialization faster.
-
- To clear the instruction cache when a trampoline is initialized, define
-the following macro.
-
- -- Macro: CLEAR_INSN_CACHE (BEG, END)
- If defined, expands to a C expression clearing the _instruction
- cache_ in the specified interval. The definition of this macro
- would typically be a series of `asm' statements. Both BEG and END
- are both pointer expressions.
-
- The operating system may also require the stack to be made executable
-before calling the trampoline. To implement this requirement, define
-the following macro.
-
- -- Macro: ENABLE_EXECUTE_STACK
- Define this macro if certain operations must be performed before
- executing code located on the stack. The macro should expand to a
- series of C file-scope constructs (e.g. functions) and provide a
- unique entry point named `__enable_execute_stack'. The target is
- responsible for emitting calls to the entry point in the code, for
- example from the `TARGET_TRAMPOLINE_INIT' hook.
-
- To use a standard subroutine, define the following macro. In addition,
-you must make sure that the instructions in a trampoline fill an entire
-cache line with identical instructions, or else ensure that the
-beginning of the trampoline code is always aligned at the same point in
-its cache line. Look in `m68k.h' as a guide.
-
- -- Macro: TRANSFER_FROM_TRAMPOLINE
- Define this macro if trampolines need a special subroutine to do
- their work. The macro should expand to a series of `asm'
- statements which will be compiled with GCC. They go in a library
- function named `__transfer_from_trampoline'.
-
- If you need to avoid executing the ordinary prologue code of a
- compiled C function when you jump to the subroutine, you can do so
- by placing a special label of your own in the assembler code. Use
- one `asm' statement to generate an assembler label, and another to
- make the label global. Then trampolines can use that label to
- jump directly to your special assembler code.
-
-
-File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros
-
-17.13 Implicit Calls to Library Routines
-========================================
-
-Here is an explanation of implicit calls to library routines.
-
- -- Macro: DECLARE_LIBRARY_RENAMES
- This macro, if defined, should expand to a piece of C code that
- will get expanded when compiling functions for libgcc.a. It can
- be used to provide alternate names for GCC's internal library
- functions if there are ABI-mandated names that the compiler should
- provide.
-
- -- Target Hook: void TARGET_INIT_LIBFUNCS (void)
- This hook should declare additional library routines or rename
- existing ones, using the functions `set_optab_libfunc' and
- `init_one_libfunc' defined in `optabs.c'. `init_optabs' calls
- this macro after initializing all the normal library routines.
-
- The default is to do nothing. Most ports don't need to define
- this hook.
-
- -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON)
- This macro should return `true' if the library routine that
- implements the floating point comparison operator COMPARISON in
- mode MODE will return a boolean, and FALSE if it will return a
- tristate.
-
- GCC's own floating point libraries return tristates from the
- comparison operators, so the default returns false always. Most
- ports don't need to define this macro.
-
- -- Macro: TARGET_LIB_INT_CMP_BIASED
- This macro should evaluate to `true' if the integer comparison
- functions (like `__cmpdi2') return 0 to indicate that the first
- operand is smaller than the second, 1 to indicate that they are
- equal, and 2 to indicate that the first operand is greater than
- the second. If this macro evaluates to `false' the comparison
- functions return -1, 0, and 1 instead of 0, 1, and 2. If the
- target uses the routines in `libgcc.a', you do not need to define
- this macro.
-
- -- Macro: TARGET_EDOM
- The value of `EDOM' on the target machine, as a C integer constant
- expression. If you don't define this macro, GCC does not attempt
- to deposit the value of `EDOM' into `errno' directly. Look in
- `/usr/include/errno.h' to find the value of `EDOM' on your system.
-
- If you do not define `TARGET_EDOM', then compiled code reports
- domain errors by calling the library function and letting it
- report the error. If mathematical functions on your system use
- `matherr' when there is an error, then you should leave
- `TARGET_EDOM' undefined so that `matherr' is used normally.
-
- -- Macro: GEN_ERRNO_RTX
- Define this macro as a C expression to create an rtl expression
- that refers to the global "variable" `errno'. (On certain systems,
- `errno' may not actually be a variable.) If you don't define this
- macro, a reasonable default is used.
-
- -- Macro: TARGET_C99_FUNCTIONS
- When this macro is nonzero, GCC will implicitly optimize `sin'
- calls into `sinf' and similarly for other functions defined by C99
- standard. The default is zero because a number of existing
- systems lack support for these functions in their runtime so this
- macro needs to be redefined to one on systems that do support the
- C99 runtime.
-
- -- Macro: TARGET_HAS_SINCOS
- When this macro is nonzero, GCC will implicitly optimize calls to
- `sin' and `cos' with the same argument to a call to `sincos'. The
- default is zero. The target has to provide the following
- functions:
- void sincos(double x, double *sin, double *cos);
- void sincosf(float x, float *sin, float *cos);
- void sincosl(long double x, long double *sin, long double *cos);
-
- -- Macro: NEXT_OBJC_RUNTIME
- Define this macro to generate code for Objective-C message sending
- using the calling convention of the NeXT system. This calling
- convention involves passing the object, the selector and the
- method arguments all at once to the method-lookup library function.
-
- The default calling convention passes just the object and the
- selector to the lookup function, which returns a pointer to the
- method.
-
-
-File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros
-
-17.14 Addressing Modes
-======================
-
-This is about addressing modes.
-
- -- Macro: HAVE_PRE_INCREMENT
- -- Macro: HAVE_PRE_DECREMENT
- -- Macro: HAVE_POST_INCREMENT
- -- Macro: HAVE_POST_DECREMENT
- A C expression that is nonzero if the machine supports
- pre-increment, pre-decrement, post-increment, or post-decrement
- addressing respectively.
-
- -- Macro: HAVE_PRE_MODIFY_DISP
- -- Macro: HAVE_POST_MODIFY_DISP
- A C expression that is nonzero if the machine supports pre- or
- post-address side-effect generation involving constants other than
- the size of the memory operand.
-
- -- Macro: HAVE_PRE_MODIFY_REG
- -- Macro: HAVE_POST_MODIFY_REG
- A C expression that is nonzero if the machine supports pre- or
- post-address side-effect generation involving a register
- displacement.
-
- -- Macro: CONSTANT_ADDRESS_P (X)
- A C expression that is 1 if the RTX X is a constant which is a
- valid address. On most machines the default definition of
- `(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable,
- but a few machines are more restrictive as to which constant
- addresses are supported.
-
- -- Macro: CONSTANT_P (X)
- `CONSTANT_P', which is defined by target-independent code, accepts
- integer-values expressions whose values are not explicitly known,
- such as `symbol_ref', `label_ref', and `high' expressions and
- `const' arithmetic expressions, in addition to `const_int' and
- `const_double' expressions.
-
- -- Macro: MAX_REGS_PER_ADDRESS
- A number, the maximum number of registers that can appear in a
- valid memory address. Note that it is up to you to specify a
- value equal to the maximum number that
- `TARGET_LEGITIMATE_ADDRESS_P' would ever accept.
-
- -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (enum machine_mode
- MODE, rtx X, bool STRICT)
- A function that returns whether X (an RTX) is a legitimate memory
- address on the target machine for a memory operand of mode MODE.
-
- Legitimate addresses are defined in two variants: a strict variant
- and a non-strict one. The STRICT parameter chooses which variant
- is desired by the caller.
-
- The strict variant is used in the reload pass. It must be defined
- so that any pseudo-register that has not been allocated a hard
- register is considered a memory reference. This is because in
- contexts where some kind of register is required, a
- pseudo-register with no hard register must be rejected. For
- non-hard registers, the strict variant should look up the
- `reg_renumber' array; it should then proceed using the hard
- register number in the array, or treat the pseudo as a memory
- reference if the array holds `-1'.
-
- The non-strict variant is used in other passes. It must be
- defined to accept all pseudo-registers in every context where some
- kind of register is required.
-
- Normally, constant addresses which are the sum of a `symbol_ref'
- and an integer are stored inside a `const' RTX to mark them as
- constant. Therefore, there is no need to recognize such sums
- specifically as legitimate addresses. Normally you would simply
- recognize any `const' as legitimate.
-
- Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant
- sums that are not marked with `const'. It assumes that a naked
- `plus' indicates indexing. If so, then you _must_ reject such
- naked constant sums as illegitimate addresses, so that none of
- them will be given to `PRINT_OPERAND_ADDRESS'.
-
- On some machines, whether a symbolic address is legitimate depends
- on the section that the address refers to. On these machines,
- define the target hook `TARGET_ENCODE_SECTION_INFO' to store the
- information into the `symbol_ref', and then check for it here.
- When you see a `const', you will have to look inside it to find the
- `symbol_ref' in order to determine the section. *Note Assembler
- Format::.
-
- Some ports are still using a deprecated legacy substitute for this
- hook, the `GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this
- syntax:
-
- #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)
-
- and should `goto LABEL' if the address X is a valid address on the
- target machine for a memory operand of mode MODE.
-
- Compiler source files that want to use the strict variant of this
- macro define the macro `REG_OK_STRICT'. You should use an `#ifdef
- REG_OK_STRICT' conditional to define the strict variant in that
- case and the non-strict variant otherwise.
-
- Using the hook is usually simpler because it limits the number of
- files that are recompiled when changes are made.
-
- -- Macro: TARGET_MEM_CONSTRAINT
- A single character to be used instead of the default `'m''
- character for general memory addresses. This defines the
- constraint letter which matches the memory addresses accepted by
- `TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to
- support new address formats in your back end without changing the
- semantics of the `'m'' constraint. This is necessary in order to
- preserve functionality of inline assembly constructs using the
- `'m'' constraint.
-
- -- Macro: FIND_BASE_TERM (X)
- A C expression to determine the base term of address X, or to
- provide a simplified version of X from which `alias.c' can easily
- find the base term. This macro is used in only two places:
- `find_base_value' and `find_base_term' in `alias.c'.
-
- It is always safe for this macro to not be defined. It exists so
- that alias analysis can understand machine-dependent addresses.
-
- The typical use of this macro is to handle addresses containing a
- label_ref or symbol_ref within an UNSPEC.
-
- -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, enum
- machine_mode MODE)
- This hook is given an invalid memory address X for an operand of
- mode MODE and should try to return a valid memory address.
-
- X will always be the result of a call to `break_out_memory_refs',
- and OLDX will be the operand that was given to that function to
- produce X.
-
- The code of the hook should not alter the substructure of X. If
- it transforms X into a more legitimate form, it should return the
- new X.
-
- It is not necessary for this hook to come up with a legitimate
- address. The compiler has standard ways of doing so in all cases.
- In fact, it is safe to omit this hook or make it return X if it
- cannot find a valid way to legitimize the address. But often a
- machine-dependent strategy can generate better code.
-
- -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS,
- WIN)
- A C compound statement that attempts to replace X, which is an
- address that needs reloading, with a valid memory address for an
- operand of mode MODE. WIN will be a C statement label elsewhere
- in the code. It is not necessary to define this macro, but it
- might be useful for performance reasons.
-
- For example, on the i386, it is sometimes possible to use a single
- reload register instead of two by reloading a sum of two pseudo
- registers into a register. On the other hand, for number of RISC
- processors offsets are limited so that often an intermediate
- address needs to be generated in order to address a stack slot.
- By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the
- intermediate addresses generated for adjacent some stack slots can
- be made identical, and thus be shared.
-
- _Note_: This macro should be used with caution. It is necessary
- to know something of how reload works in order to effectively use
- this, and it is quite easy to produce macros that build in too
- much knowledge of reload internals.
-
- _Note_: This macro must be able to reload an address created by a
- previous invocation of this macro. If it fails to handle such
- addresses then the compiler may generate incorrect code or abort.
-
- The macro definition should use `push_reload' to indicate parts
- that need reloading; OPNUM, TYPE and IND_LEVELS are usually
- suitable to be passed unaltered to `push_reload'.
-
- The code generated by this macro must not alter the substructure of
- X. If it transforms X into a more legitimate form, it should
- assign X (which will always be a C variable) a new value. This
- also applies to parts that you change indirectly by calling
- `push_reload'.
-
- The macro definition may use `strict_memory_address_p' to test if
- the address has become legitimate.
-
- If you want to change only a part of X, one standard way of doing
- this is to use `copy_rtx'. Note, however, that it unshares only a
- single level of rtl. Thus, if the part to be changed is not at the
- top level, you'll need to replace first the top level. It is not
- necessary for this macro to come up with a legitimate address;
- but often a machine-dependent strategy can generate better code.
-
- -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR)
- This hook returns `true' if memory address ADDR can have different
- meanings depending on the machine mode of the memory reference it
- is used for or if the address is valid for some modes but not
- others.
-
- Autoincrement and autodecrement addresses typically have
- mode-dependent effects because the amount of the increment or
- decrement is the size of the operand being addressed. Some
- machines have other mode-dependent addresses. Many RISC machines
- have no mode-dependent addresses.
-
- You may assume that ADDR is a valid address for the machine.
-
- The default version of this hook returns `false'.
-
- -- Macro: GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)
- A C statement or compound statement with a conditional `goto
- LABEL;' executed if memory address X (an RTX) can have different
- meanings depending on the machine mode of the memory reference it
- is used for or if the address is valid for some modes but not
- others.
-
- Autoincrement and autodecrement addresses typically have
- mode-dependent effects because the amount of the increment or
- decrement is the size of the operand being addressed. Some
- machines have other mode-dependent addresses. Many RISC machines
- have no mode-dependent addresses.
-
- You may assume that ADDR is a valid address for the machine.
-
- These are obsolete macros, replaced by the
- `TARGET_MODE_DEPENDENT_ADDRESS_P' target hook.
-
- -- Macro: LEGITIMATE_CONSTANT_P (X)
- A C expression that is nonzero if X is a legitimate constant for
- an immediate operand on the target machine. You can assume that X
- satisfies `CONSTANT_P', so you need not check this. In fact, `1'
- is a suitable definition for this macro on machines where anything
- `CONSTANT_P' is valid.
-
- -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X)
- This hook is used to undo the possibly obfuscating effects of the
- `LEGITIMIZE_ADDRESS' and `LEGITIMIZE_RELOAD_ADDRESS' target
- macros. Some backend implementations of these macros wrap symbol
- references inside an `UNSPEC' rtx to represent PIC or similar
- addressing modes. This target hook allows GCC's optimizers to
- understand the semantics of these opaque `UNSPEC's by converting
- them back into their original form.
-
- -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (rtx X)
- This hook should return true if X is of a form that cannot (or
- should not) be spilled to the constant pool. The default version
- of this hook returns false.
-
- The primary reason to define this hook is to prevent reload from
- deciding that a non-legitimate constant would be better reloaded
- from the constant pool instead of spilling and reloading a register
- holding the constant. This restriction is often true of addresses
- of TLS symbols for various targets.
-
- -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (enum
- machine_mode MODE, const_rtx X)
- This hook should return true if pool entries for constant X can be
- placed in an `object_block' structure. MODE is the mode of X.
-
- The default version returns false for all constants.
-
- -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (unsigned FN, bool
- MD_FN, bool SQRT)
- This hook should return the DECL of a function that implements
- reciprocal of the builtin function with builtin function code FN,
- or `NULL_TREE' if such a function is not available. MD_FN is true
- when FN is a code of a machine-dependent builtin function. When
- SQRT is true, additional optimizations that apply only to the
- reciprocal of a square root function are performed, and only
- reciprocals of `sqrt' function are valid.
-
- -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void)
- This hook should return the DECL of a function F that given an
- address ADDR as an argument returns a mask M that can be used to
- extract from two vectors the relevant data that resides in ADDR in
- case ADDR is not properly aligned.
-
- The autovectorizer, when vectorizing a load operation from an
- address ADDR that may be unaligned, will generate two vector loads
- from the two aligned addresses around ADDR. It then generates a
- `REALIGN_LOAD' operation to extract the relevant data from the two
- loaded vectors. The first two arguments to `REALIGN_LOAD', V1 and
- V2, are the two vectors, each of size VS, and the third argument,
- OFF, defines how the data will be extracted from these two
- vectors: if OFF is 0, then the returned vector is V2; otherwise,
- the returned vector is composed from the last VS-OFF elements of
- V1 concatenated to the first OFF elements of V2.
-
- If this hook is defined, the autovectorizer will generate a call
- to F (using the DECL tree that this hook returns) and will use the
- return value of F as the argument OFF to `REALIGN_LOAD'.
- Therefore, the mask M returned by F should comply with the
- semantics expected by `REALIGN_LOAD' described above. If this
- hook is not defined, then ADDR will be used as the argument OFF to
- `REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR
- will be considered.
-
- -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN (tree X)
- This hook should return the DECL of a function F that implements
- widening multiplication of the even elements of two input vectors
- of type X.
-
- If this hook is defined, the autovectorizer will use it along with
- the `TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD' target hook when
- vectorizing widening multiplication in cases that the order of the
- results does not have to be preserved (e.g. used only by a
- reduction computation). Otherwise, the `widen_mult_hi/lo' idioms
- will be used.
-
- -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD (tree X)
- This hook should return the DECL of a function F that implements
- widening multiplication of the odd elements of two input vectors
- of type X.
-
- If this hook is defined, the autovectorizer will use it along with
- the `TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN' target hook when
- vectorizing widening multiplication in cases that the order of the
- results does not have to be preserved (e.g. used only by a
- reduction computation). Otherwise, the `widen_mult_hi/lo' idioms
- will be used.
-
- -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum
- vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN)
- Returns cost of different scalar or vector statements for
- vectorization cost model. For vector memory operations the cost
- may depend on type (VECTYPE) and misalignment value (MISALIGN).
-
- -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE
- (const_tree TYPE, bool IS_PACKED)
- Return true if vector alignment is reachable (by peeling N
- iterations) for the given type.
-
- -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VEC_PERM (tree TYPE,
- tree *MASK_ELEMENT_TYPE)
- Target builtin that implements vector permute.
-
- -- Target Hook: bool TARGET_VECTORIZE_BUILTIN_VEC_PERM_OK (tree
- VEC_TYPE, tree MASK)
- Return true if a vector created for `builtin_vec_perm' is valid.
-
- -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned
- CODE, tree DEST_TYPE, tree SRC_TYPE)
- This hook should return the DECL of a function that implements
- conversion of the input vector of type SRC_TYPE to type DEST_TYPE.
- The value of CODE is one of the enumerators in `enum tree_code' and
- specifies how the conversion is to be applied (truncation,
- rounding, etc.).
-
- If this hook is defined, the autovectorizer will use the
- `TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing
- conversion. Otherwise, it will return `NULL_TREE'.
-
- -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
- (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN)
- This hook should return the decl of a function that implements the
- vectorized variant of the builtin function with builtin function
- code CODE or `NULL_TREE' if such a function is not available. The
- value of FNDECL is the builtin function declaration. The return
- type of the vectorized function shall be of vector type
- VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN.
-
- -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
- (enum machine_mode MODE, const_tree TYPE, int MISALIGNMENT,
- bool IS_PACKED)
- This hook should return true if the target supports misaligned
- vector store/load of a specific factor denoted in the MISALIGNMENT
- parameter. The vector store/load should be of machine mode MODE
- and the elements in the vectors should be of type TYPE. IS_PACKED
- parameter is true if the memory access is defined in a packed
- struct.
-
- -- Target Hook: enum machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE
- (enum machine_mode MODE)
- This hook should return the preferred mode for vectorizing scalar
- mode MODE. The default is equal to `word_mode', because the
- vectorizer can do some transformations even in absence of
- specialized SIMD hardware.
-
- -- Target Hook: unsigned int
-TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES (void)
- This hook should return a mask of sizes that should be iterated
- over after trying to autovectorize using the vector size derived
- from the mode returned by `TARGET_VECTORIZE_PREFERRED_SIMD_MODE'.
- The default is zero which means to not iterate over other vector
- sizes.
-
-
-File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros
-
-17.15 Anchored Addresses
-========================
-
-GCC usually addresses every static object as a separate entity. For
-example, if we have:
-
- static int a, b, c;
- int foo (void) { return a + b + c; }
-
- the code for `foo' will usually calculate three separate symbolic
-addresses: those of `a', `b' and `c'. On some targets, it would be
-better to calculate just one symbolic address and access the three
-variables relative to it. The equivalent pseudocode would be something
-like:
-
- int foo (void)
- {
- register int *xr = &x;
- return xr[&a - &x] + xr[&b - &x] + xr[&c - &x];
- }
-
- (which isn't valid C). We refer to shared addresses like `x' as
-"section anchors". Their use is controlled by `-fsection-anchors'.
-
- The hooks below describe the target properties that GCC needs to know
-in order to make effective use of section anchors. It won't use
-section anchors at all unless either `TARGET_MIN_ANCHOR_OFFSET' or
-`TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value.
-
- -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET
- The minimum offset that should be applied to a section anchor. On
- most targets, it should be the smallest offset that can be applied
- to a base register while still giving a legitimate address for
- every mode. The default value is 0.
-
- -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET
- Like `TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive)
- offset that should be applied to section anchors. The default
- value is 0.
-
- -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X)
- Write the assembly code to define section anchor X, which is a
- `SYMBOL_REF' for which `SYMBOL_REF_ANCHOR_P (X)' is true. The
- hook is called with the assembly output position set to the
- beginning of `SYMBOL_REF_BLOCK (X)'.
-
- If `ASM_OUTPUT_DEF' is available, the hook's default definition
- uses it to define the symbol as `. + SYMBOL_REF_BLOCK_OFFSET (X)'.
- If `ASM_OUTPUT_DEF' is not available, the hook's default definition
- is `NULL', which disables the use of section anchors altogether.
-
- -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X)
- Return true if GCC should attempt to use anchors to access
- `SYMBOL_REF' X. You can assume `SYMBOL_REF_HAS_BLOCK_INFO_P (X)'
- and `!SYMBOL_REF_ANCHOR_P (X)'.
-
- The default version is correct for most targets, but you might
- need to intercept this hook to handle things like target-specific
- attributes or target-specific sections.
-
-
-File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros
-
-17.16 Condition Code Status
-===========================
-
-The macros in this section can be split in two families, according to
-the two ways of representing condition codes in GCC.
-
- The first representation is the so called `(cc0)' representation
-(*note Jump Patterns::), where all instructions can have an implicit
-clobber of the condition codes. The second is the condition code
-register representation, which provides better schedulability for
-architectures that do have a condition code register, but on which most
-instructions do not affect it. The latter category includes most RISC
-machines.
-
- The implicit clobbering poses a strong restriction on the placement of
-the definition and use of the condition code, which need to be in
-adjacent insns for machines using `(cc0)'. This can prevent important
-optimizations on some machines. For example, on the IBM RS/6000, there
-is a delay for taken branches unless the condition code register is set
-three instructions earlier than the conditional branch. The instruction
-scheduler cannot perform this optimization if it is not permitted to
-separate the definition and use of the condition code register.
-
- For this reason, it is possible and suggested to use a register to
-represent the condition code for new ports. If there is a specific
-condition code register in the machine, use a hard register. If the
-condition code or comparison result can be placed in any general
-register, or if there are multiple condition registers, use a pseudo
-register. Registers used to store the condition code value will
-usually have a mode that is in class `MODE_CC'.
-
- Alternatively, you can use `BImode' if the comparison operator is
-specified already in the compare instruction. In this case, you are not
-interested in most macros in this section.
-
-* Menu:
-
-* CC0 Condition Codes:: Old style representation of condition codes.
-* MODE_CC Condition Codes:: Modern representation of condition codes.
-* Cond Exec Macros:: Macros to control conditional execution.
-
-
-File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code
-
-17.16.1 Representation of condition codes using `(cc0)'
--------------------------------------------------------
-
-The file `conditions.h' defines a variable `cc_status' to describe how
-the condition code was computed (in case the interpretation of the
-condition code depends on the instruction that it was set by). This
-variable contains the RTL expressions on which the condition code is
-currently based, and several standard flags.
-
- Sometimes additional machine-specific flags must be defined in the
-machine description header file. It can also add additional
-machine-specific information by defining `CC_STATUS_MDEP'.
-
- -- Macro: CC_STATUS_MDEP
- C code for a data type which is used for declaring the `mdep'
- component of `cc_status'. It defaults to `int'.
-
- This macro is not used on machines that do not use `cc0'.
-
- -- Macro: CC_STATUS_MDEP_INIT
- A C expression to initialize the `mdep' field to "empty". The
- default definition does nothing, since most machines don't use the
- field anyway. If you want to use the field, you should probably
- define this macro to initialize it.
-
- This macro is not used on machines that do not use `cc0'.
-
- -- Macro: NOTICE_UPDATE_CC (EXP, INSN)
- A C compound statement to set the components of `cc_status'
- appropriately for an insn INSN whose body is EXP. It is this
- macro's responsibility to recognize insns that set the condition
- code as a byproduct of other activity as well as those that
- explicitly set `(cc0)'.
-
- This macro is not used on machines that do not use `cc0'.
-
- If there are insns that do not set the condition code but do alter
- other machine registers, this macro must check to see whether they
- invalidate the expressions that the condition code is recorded as
- reflecting. For example, on the 68000, insns that store in address
- registers do not set the condition code, which means that usually
- `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
- But suppose that the previous insn set the condition code based on
- location `a4@(102)' and the current insn stores a new value in
- `a4'. Although the condition code is not changed by this, it will
- no longer be true that it reflects the contents of `a4@(102)'.
- Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case
- to say that nothing is known about the condition code value.
-
- The definition of `NOTICE_UPDATE_CC' must be prepared to deal with
- the results of peephole optimization: insns whose patterns are
- `parallel' RTXs containing various `reg', `mem' or constants which
- are just the operands. The RTL structure of these insns is not
- sufficient to indicate what the insns actually do. What
- `NOTICE_UPDATE_CC' should do when it sees one is just to run
- `CC_STATUS_INIT'.
-
- A possible definition of `NOTICE_UPDATE_CC' is to call a function
- that looks at an attribute (*note Insn Attributes::) named, for
- example, `cc'. This avoids having detailed information about
- patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.
-
-
-File: gccint.info, Node: MODE_CC Condition Codes, Next: Cond Exec Macros, Prev: CC0 Condition Codes, Up: Condition Code
-
-17.16.2 Representation of condition codes using registers
----------------------------------------------------------
-
- -- Macro: SELECT_CC_MODE (OP, X, Y)
- On many machines, the condition code may be produced by other
- instructions than compares, for example the branch can use
- directly the condition code set by a subtract instruction.
- However, on some machines when the condition code is set this way
- some bits (such as the overflow bit) are not set in the same way
- as a test instruction, so that a different branch instruction must
- be used for some conditional branches. When this happens, use the
- machine mode of the condition code register to record different
- formats of the condition code register. Modes can also be used to
- record which compare instruction (e.g. a signed or an unsigned
- comparison) produced the condition codes.
-
- If other modes than `CCmode' are required, add them to
- `MACHINE-modes.def' and define `SELECT_CC_MODE' to choose a mode
- given an operand of a compare. This is needed because the modes
- have to be chosen not only during RTL generation but also, for
- example, by instruction combination. The result of
- `SELECT_CC_MODE' should be consistent with the mode used in the
- patterns; for example to support the case of the add on the SPARC
- discussed above, we have the pattern
-
- (define_insn ""
- [(set (reg:CC_NOOV 0)
- (compare:CC_NOOV
- (plus:SI (match_operand:SI 0 "register_operand" "%r")
- (match_operand:SI 1 "arith_operand" "rI"))
- (const_int 0)))]
- ""
- "...")
-
- together with a `SELECT_CC_MODE' that returns `CC_NOOVmode' for
- comparisons whose argument is a `plus':
-
- #define SELECT_CC_MODE(OP,X,Y) \
- (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \
- ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \
- : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \
- || GET_CODE (X) == NEG) \
- ? CC_NOOVmode : CCmode))
-
- Another reason to use modes is to retain information on which
- operands were used by the comparison; see `REVERSIBLE_CC_MODE'
- later in this section.
-
- You should define this macro if and only if you define extra CC
- modes in `MACHINE-modes.def'.
-
- -- Macro: CANONICALIZE_COMPARISON (CODE, OP0, OP1)
- On some machines not all possible comparisons are defined, but you
- can convert an invalid comparison into a valid one. For example,
- the Alpha does not have a `GT' comparison, but you can use an `LT'
- comparison instead and swap the order of the operands.
-
- On such machines, define this macro to be a C statement to do any
- required conversions. CODE is the initial comparison code and OP0
- and OP1 are the left and right operands of the comparison,
- respectively. You should modify CODE, OP0, and OP1 as required.
-
- GCC will not assume that the comparison resulting from this macro
- is valid but will see if the resulting insn matches a pattern in
- the `md' file.
-
- You need not define this macro if it would never change the
- comparison code or operands.
-
- -- Macro: REVERSIBLE_CC_MODE (MODE)
- A C expression whose value is one if it is always safe to reverse a
- comparison whose mode is MODE. If `SELECT_CC_MODE' can ever
- return MODE for a floating-point inequality comparison, then
- `REVERSIBLE_CC_MODE (MODE)' must be zero.
-
- You need not define this macro if it would always returns zero or
- if the floating-point format is anything other than
- `IEEE_FLOAT_FORMAT'. For example, here is the definition used on
- the SPARC, where floating-point inequality comparisons are always
- given `CCFPEmode':
-
- #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode)
-
- -- Macro: REVERSE_CONDITION (CODE, MODE)
- A C expression whose value is reversed condition code of the CODE
- for comparison done in CC_MODE MODE. The macro is used only in
- case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in
- case machine has some non-standard way how to reverse certain
- conditionals. For instance in case all floating point conditions
- are non-trapping, compiler may freely convert unordered compares
- to ordered one. Then definition may look like:
-
- #define REVERSE_CONDITION(CODE, MODE) \
- ((MODE) != CCFPmode ? reverse_condition (CODE) \
- : reverse_condition_maybe_unordered (CODE))
-
- -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int
- *P1, unsigned int *P2)
- On targets which do not use `(cc0)', and which use a hard register
- rather than a pseudo-register to hold condition codes, the regular
- CSE passes are often not able to identify cases in which the hard
- register is set to a common value. Use this hook to enable a
- small pass which optimizes such cases. This hook should return
- true to enable this pass, and it should set the integers to which
- its arguments point to the hard register numbers used for
- condition codes. When there is only one such register, as is true
- on most systems, the integer pointed to by P2 should be set to
- `INVALID_REGNUM'.
-
- The default version of this hook returns false.
-
- -- Target Hook: enum machine_mode TARGET_CC_MODES_COMPATIBLE (enum
- machine_mode M1, enum machine_mode M2)
- On targets which use multiple condition code modes in class
- `MODE_CC', it is sometimes the case that a comparison can be
- validly done in more than one mode. On such a system, define this
- target hook to take two mode arguments and to return a mode in
- which both comparisons may be validly done. If there is no such
- mode, return `VOIDmode'.
-
- The default version of this hook checks whether the modes are the
- same. If they are, it returns that mode. If they are different,
- it returns `VOIDmode'.
-
-
-File: gccint.info, Node: Cond Exec Macros, Prev: MODE_CC Condition Codes, Up: Condition Code
-
-17.16.3 Macros to control conditional execution
------------------------------------------------
-
-There is one macro that may need to be defined for targets supporting
-conditional execution, independent of how they represent conditional
-branches.
-
- -- Macro: REVERSE_CONDEXEC_PREDICATES_P (OP1, OP2)
- A C expression that returns true if the conditional execution
- predicate OP1, a comparison operation, is the inverse of OP2 and
- vice versa. Define this to return 0 if the target has conditional
- execution predicates that cannot be reversed safely. There is no
- need to validate that the arguments of op1 and op2 are the same,
- this is done separately. If no expansion is specified, this macro
- is defined as follows:
-
- #define REVERSE_CONDEXEC_PREDICATES_P (x, y) \
- (GET_CODE ((x)) == reversed_comparison_code ((y), NULL))
-
-
-File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros
-
-17.17 Describing Relative Costs of Operations
-=============================================
-
-These macros let you describe the relative speed of various operations
-on the target machine.
-
- -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO)
- A C expression for the cost of moving data of mode MODE from a
- register in class FROM to one in class TO. The classes are
- expressed using the enumeration values such as `GENERAL_REGS'. A
- value of 2 is the default; other values are interpreted relative to
- that.
-
- It is not required that the cost always equal 2 when FROM is the
- same as TO; on some machines it is expensive to move between
- registers if they are not general registers.
-
- If reload sees an insn consisting of a single `set' between two
- hard registers, and if `REGISTER_MOVE_COST' applied to their
- classes returns a value of 2, reload does not check to ensure that
- the constraints of the insn are met. Setting a cost of other than
- 2 will allow reload to verify that the constraints are met. You
- should do this if the `movM' pattern's constraints do not allow
- such copying.
-
- These macros are obsolete, new ports should use the target hook
- `TARGET_REGISTER_MOVE_COST' instead.
-
- -- Target Hook: int TARGET_REGISTER_MOVE_COST (enum machine_mode MODE,
- reg_class_t FROM, reg_class_t TO)
- This target hook should return the cost of moving data of mode MODE
- from a register in class FROM to one in class TO. The classes are
- expressed using the enumeration values such as `GENERAL_REGS'. A
- value of 2 is the default; other values are interpreted relative to
- that.
-
- It is not required that the cost always equal 2 when FROM is the
- same as TO; on some machines it is expensive to move between
- registers if they are not general registers.
-
- If reload sees an insn consisting of a single `set' between two
- hard registers, and if `TARGET_REGISTER_MOVE_COST' applied to their
- classes returns a value of 2, reload does not check to ensure that
- the constraints of the insn are met. Setting a cost of other than
- 2 will allow reload to verify that the constraints are met. You
- should do this if the `movM' pattern's constraints do not allow
- such copying.
-
- The default version of this function returns 2.
-
- -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN)
- A C expression for the cost of moving data of mode MODE between a
- register of class CLASS and memory; IN is zero if the value is to
- be written to memory, nonzero if it is to be read in. This cost
- is relative to those in `REGISTER_MOVE_COST'. If moving between
- registers and memory is more expensive than between two registers,
- you should define this macro to express the relative cost.
-
- If you do not define this macro, GCC uses a default cost of 4 plus
- the cost of copying via a secondary reload register, if one is
- needed. If your machine requires a secondary reload register to
- copy between memory and a register of CLASS but the reload
- mechanism is more complex than copying via an intermediate, define
- this macro to reflect the actual cost of the move.
-
- GCC defines the function `memory_move_secondary_cost' if secondary
- reloads are needed. It computes the costs due to copying via a
- secondary register. If your machine copies from memory using a
- secondary register in the conventional way but the default base
- value of 4 is not correct for your machine, define this macro to
- add some other value to the result of that function. The
- arguments to that function are the same as to this macro.
-
- These macros are obsolete, new ports should use the target hook
- `TARGET_MEMORY_MOVE_COST' instead.
-
- -- Target Hook: int TARGET_MEMORY_MOVE_COST (enum machine_mode MODE,
- reg_class_t RCLASS, bool IN)
- This target hook should return the cost of moving data of mode MODE
- between a register of class RCLASS and memory; IN is `false' if
- the value is to be written to memory, `true' if it is to be read
- in. This cost is relative to those in `TARGET_REGISTER_MOVE_COST'.
- If moving between registers and memory is more expensive than
- between two registers, you should add this target hook to express
- the relative cost.
-
- If you do not add this target hook, GCC uses a default cost of 4
- plus the cost of copying via a secondary reload register, if one is
- needed. If your machine requires a secondary reload register to
- copy between memory and a register of RCLASS but the reload
- mechanism is more complex than copying via an intermediate, use
- this target hook to reflect the actual cost of the move.
-
- GCC defines the function `memory_move_secondary_cost' if secondary
- reloads are needed. It computes the costs due to copying via a
- secondary register. If your machine copies from memory using a
- secondary register in the conventional way but the default base
- value of 4 is not correct for your machine, use this target hook
- to add some other value to the result of that function. The
- arguments to that function are the same as to this target hook.
-
- -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P)
- A C expression for the cost of a branch instruction. A value of 1
- is the default; other values are interpreted relative to that.
- Parameter SPEED_P is true when the branch in question should be
- optimized for speed. When it is false, `BRANCH_COST' should
- return a value optimal for code size rather than performance.
- PREDICTABLE_P is true for well-predicted branches. On many
- architectures the `BRANCH_COST' can be reduced then.
-
- Here are additional macros which do not specify precise relative costs,
-but only that certain actions are more expensive than GCC would
-ordinarily expect.
-
- -- Macro: SLOW_BYTE_ACCESS
- Define this macro as a C expression which is nonzero if accessing
- less than a word of memory (i.e. a `char' or a `short') is no
- faster than accessing a word of memory, i.e., if such access
- require more than one instruction or if there is no difference in
- cost between byte and (aligned) word loads.
-
- When this macro is not defined, the compiler will access a field by
- finding the smallest containing object; when it is defined, a
- fullword load will be used if alignment permits. Unless bytes
- accesses are faster than word accesses, using word accesses is
- preferable since it may eliminate subsequent memory access if
- subsequent accesses occur to other fields in the same word of the
- structure, but to different bytes.
-
- -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT)
- Define this macro to be the value 1 if memory accesses described
- by the MODE and ALIGNMENT parameters have a cost many times greater
- than aligned accesses, for example if they are emulated in a trap
- handler.
-
- When this macro is nonzero, the compiler will act as if
- `STRICT_ALIGNMENT' were nonzero when generating code for block
- moves. This can cause significantly more instructions to be
- produced. Therefore, do not set this macro nonzero if unaligned
- accesses only add a cycle or two to the time for a memory access.
-
- If the value of this macro is always zero, it need not be defined.
- If this macro is defined, it should produce a nonzero value when
- `STRICT_ALIGNMENT' is nonzero.
-
- -- Macro: MOVE_RATIO (SPEED)
- The threshold of number of scalar memory-to-memory move insns,
- _below_ which a sequence of insns should be generated instead of a
- string move insn or a library call. Increasing the value will
- always make code faster, but eventually incurs high cost in
- increased code size.
-
- Note that on machines where the corresponding move insn is a
- `define_expand' that emits a sequence of insns, this macro counts
- the number of such sequences.
-
- The parameter SPEED is true if the code is currently being
- optimized for speed rather than size.
-
- If you don't define this, a reasonable default is used.
-
- -- Macro: MOVE_BY_PIECES_P (SIZE, ALIGNMENT)
- A C expression used to determine whether `move_by_pieces' will be
- used to copy a chunk of memory, or whether some other block move
- mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns'
- returns less than `MOVE_RATIO'.
-
- -- Macro: MOVE_MAX_PIECES
- A C expression used by `move_by_pieces' to determine the largest
- unit a load or store used to copy memory is. Defaults to
- `MOVE_MAX'.
-
- -- Macro: CLEAR_RATIO (SPEED)
- The threshold of number of scalar move insns, _below_ which a
- sequence of insns should be generated to clear memory instead of a
- string clear insn or a library call. Increasing the value will
- always make code faster, but eventually incurs high cost in
- increased code size.
-
- The parameter SPEED is true if the code is currently being
- optimized for speed rather than size.
-
- If you don't define this, a reasonable default is used.
-
- -- Macro: CLEAR_BY_PIECES_P (SIZE, ALIGNMENT)
- A C expression used to determine whether `clear_by_pieces' will be
- used to clear a chunk of memory, or whether some other block clear
- mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns'
- returns less than `CLEAR_RATIO'.
-
- -- Macro: SET_RATIO (SPEED)
- The threshold of number of scalar move insns, _below_ which a
- sequence of insns should be generated to set memory to a constant
- value, instead of a block set insn or a library call. Increasing
- the value will always make code faster, but eventually incurs high
- cost in increased code size.
-
- The parameter SPEED is true if the code is currently being
- optimized for speed rather than size.
-
- If you don't define this, it defaults to the value of `MOVE_RATIO'.
-
- -- Macro: SET_BY_PIECES_P (SIZE, ALIGNMENT)
- A C expression used to determine whether `store_by_pieces' will be
- used to set a chunk of memory to a constant value, or whether some
- other mechanism will be used. Used by `__builtin_memset' when
- storing values other than constant zero. Defaults to 1 if
- `move_by_pieces_ninsns' returns less than `SET_RATIO'.
-
- -- Macro: STORE_BY_PIECES_P (SIZE, ALIGNMENT)
- A C expression used to determine whether `store_by_pieces' will be
- used to set a chunk of memory to a constant string value, or
- whether some other mechanism will be used. Used by
- `__builtin_strcpy' when called with a constant source string.
- Defaults to 1 if `move_by_pieces_ninsns' returns less than
- `MOVE_RATIO'.
-
- -- Macro: USE_LOAD_POST_INCREMENT (MODE)
- A C expression used to determine whether a load postincrement is a
- good thing to use for a given mode. Defaults to the value of
- `HAVE_POST_INCREMENT'.
-
- -- Macro: USE_LOAD_POST_DECREMENT (MODE)
- A C expression used to determine whether a load postdecrement is a
- good thing to use for a given mode. Defaults to the value of
- `HAVE_POST_DECREMENT'.
-
- -- Macro: USE_LOAD_PRE_INCREMENT (MODE)
- A C expression used to determine whether a load preincrement is a
- good thing to use for a given mode. Defaults to the value of
- `HAVE_PRE_INCREMENT'.
-
- -- Macro: USE_LOAD_PRE_DECREMENT (MODE)
- A C expression used to determine whether a load predecrement is a
- good thing to use for a given mode. Defaults to the value of
- `HAVE_PRE_DECREMENT'.
-
- -- Macro: USE_STORE_POST_INCREMENT (MODE)
- A C expression used to determine whether a store postincrement is
- a good thing to use for a given mode. Defaults to the value of
- `HAVE_POST_INCREMENT'.
-
- -- Macro: USE_STORE_POST_DECREMENT (MODE)
- A C expression used to determine whether a store postdecrement is
- a good thing to use for a given mode. Defaults to the value of
- `HAVE_POST_DECREMENT'.
-
- -- Macro: USE_STORE_PRE_INCREMENT (MODE)
- This macro is used to determine whether a store preincrement is a
- good thing to use for a given mode. Defaults to the value of
- `HAVE_PRE_INCREMENT'.
-
- -- Macro: USE_STORE_PRE_DECREMENT (MODE)
- This macro is used to determine whether a store predecrement is a
- good thing to use for a given mode. Defaults to the value of
- `HAVE_PRE_DECREMENT'.
-
- -- Macro: NO_FUNCTION_CSE
- Define this macro if it is as good or better to call a constant
- function address than to call an address kept in a register.
-
- -- Macro: RANGE_TEST_NON_SHORT_CIRCUIT
- Define this macro if a non-short-circuit operation produced by
- `fold_range_test ()' is optimal. This macro defaults to true if
- `BRANCH_COST' is greater than or equal to the value 2.
-
- -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int
- OUTER_CODE, int *TOTAL, bool SPEED)
- This target hook describes the relative costs of RTL expressions.
-
- The cost may depend on the precise form of the expression, which is
- available for examination in X, and the rtx code of the expression
- in which it is contained, found in OUTER_CODE. CODE is the
- expression code--redundant, since it can be obtained with
- `GET_CODE (X)'.
-
- In implementing this hook, you can use the construct
- `COSTS_N_INSNS (N)' to specify a cost equal to N fast instructions.
-
- On entry to the hook, `*TOTAL' contains a default estimate for the
- cost of the expression. The hook should modify this value as
- necessary. Traditionally, the default costs are `COSTS_N_INSNS
- (5)' for multiplications, `COSTS_N_INSNS (7)' for division and
- modulus operations, and `COSTS_N_INSNS (1)' for all other
- operations.
-
- When optimizing for code size, i.e. when `speed' is false, this
- target hook should be used to estimate the relative size cost of
- an expression, again relative to `COSTS_N_INSNS'.
-
- The hook returns true when all subexpressions of X have been
- processed, and false when `rtx_cost' should recurse.
-
- -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, bool SPEED)
- This hook computes the cost of an addressing mode that contains
- ADDRESS. If not defined, the cost is computed from the ADDRESS
- expression and the `TARGET_RTX_COST' hook.
-
- For most CISC machines, the default cost is a good approximation
- of the true cost of the addressing mode. However, on RISC
- machines, all instructions normally have the same length and
- execution time. Hence all addresses will have equal costs.
-
- In cases where more than one form of an address is known, the form
- with the lowest cost will be used. If multiple forms have the
- same, lowest, cost, the one that is the most complex will be used.
-
- For example, suppose an address that is equal to the sum of a
- register and a constant is used twice in the same basic block.
- When this macro is not defined, the address will be computed in a
- register and memory references will be indirect through that
- register. On machines where the cost of the addressing mode
- containing the sum is no higher than that of a simple indirect
- reference, this will produce an additional instruction and
- possibly require an additional register. Proper specification of
- this macro eliminates this overhead for such machines.
-
- This hook is never called with an invalid address.
-
- On machines where an address involving more than one register is as
- cheap as an address computation involving only one register,
- defining `TARGET_ADDRESS_COST' to reflect this can cause two
- registers to be live over a region of code where only one would
- have been if `TARGET_ADDRESS_COST' were not defined in that
- manner. This effect should be considered in the definition of
- this macro. Equivalent costs should probably only be given to
- addresses with different numbers of registers on machines with
- lots of registers.
-
-
-File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros
-
-17.18 Adjusting the Instruction Scheduler
-=========================================
-
-The instruction scheduler may need a fair amount of machine-specific
-adjustment in order to produce good code. GCC provides several target
-hooks for this purpose. It is usually enough to define just a few of
-them: try the first ones in this list first.
-
- -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void)
- This hook returns the maximum number of instructions that can ever
- issue at the same time on the target machine. The default is one.
- Although the insn scheduler can define itself the possibility of
- issue an insn on the same cycle, the value can serve as an
- additional constraint to issue insns on the same simulated
- processor cycle (see hooks `TARGET_SCHED_REORDER' and
- `TARGET_SCHED_REORDER2'). This value must be constant over the
- entire compilation. If you need it to vary depending on what the
- instructions are, you must use `TARGET_SCHED_VARIABLE_ISSUE'.
-
- -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int
- VERBOSE, rtx INSN, int MORE)
- This hook is executed by the scheduler after it has scheduled an
- insn from the ready list. It should return the number of insns
- which can still be issued in the current cycle. The default is
- `MORE - 1' for insns other than `CLOBBER' and `USE', which
- normally are not counted against the issue rate. You should
- define this hook if some insns take more machine resources than
- others, so that fewer insns can follow them in the same cycle.
- FILE is either a null pointer, or a stdio stream to write any
- debug output to. VERBOSE is the verbose level provided by
- `-fsched-verbose-N'. INSN is the instruction that was scheduled.
-
- -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx
- DEP_INSN, int COST)
- This function corrects the value of COST based on the relationship
- between INSN and DEP_INSN through the dependence LINK. It should
- return the new value. The default is to make no adjustment to
- COST. This can be used for example to specify to the scheduler
- using the traditional pipeline description that an output- or
- anti-dependence does not incur the same cost as a data-dependence.
- If the scheduler using the automaton based pipeline description,
- the cost of anti-dependence is zero and the cost of
- output-dependence is maximum of one and the difference of latency
- times of the first and the second insns. If these values are not
- acceptable, you could use the hook to modify them too. See also
- *note Processor pipeline description::.
-
- -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int
- PRIORITY)
- This hook adjusts the integer scheduling priority PRIORITY of
- INSN. It should return the new priority. Increase the priority to
- execute INSN earlier, reduce the priority to execute INSN later.
- Do not define this hook if you do not need to adjust the
- scheduling priorities of insns.
-
- -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx
- *READY, int *N_READYP, int CLOCK)
- This hook is executed by the scheduler after it has scheduled the
- ready list, to allow the machine description to reorder it (for
- example to combine two small instructions together on `VLIW'
- machines). FILE is either a null pointer, or a stdio stream to
- write any debug output to. VERBOSE is the verbose level provided
- by `-fsched-verbose-N'. READY is a pointer to the ready list of
- instructions that are ready to be scheduled. N_READYP is a
- pointer to the number of elements in the ready list. The scheduler
- reads the ready list in reverse order, starting with
- READY[*N_READYP - 1] and going to READY[0]. CLOCK is the timer
- tick of the scheduler. You may modify the ready list and the
- number of ready insns. The return value is the number of insns
- that can issue this cycle; normally this is just `issue_rate'.
- See also `TARGET_SCHED_REORDER2'.
-
- -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE,
- rtx *READY, int *N_READYP, int CLOCK)
- Like `TARGET_SCHED_REORDER', but called at a different time. That
- function is called whenever the scheduler starts a new cycle.
- This one is called once per iteration over a cycle, immediately
- after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list
- and return the number of insns to be scheduled in the same cycle.
- Defining this hook can be useful if there are frequent situations
- where scheduling one insn causes other insns to become ready in
- the same cycle. These other insns can then be taken into account
- properly.
-
- -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx
- HEAD, rtx TAIL)
- This hook is called after evaluation forward dependencies of insns
- in chain given by two parameter values (HEAD and TAIL
- correspondingly) but before insns scheduling of the insn chain.
- For example, it can be used for better insn classification if it
- requires analysis of dependencies. This hook can use backward and
- forward dependencies of the insn scheduler because they are already
- calculated.
-
- -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int
- MAX_READY)
- This hook is executed by the scheduler at the beginning of each
- block of instructions that are to be scheduled. FILE is either a
- null pointer, or a stdio stream to write any debug output to.
- VERBOSE is the verbose level provided by `-fsched-verbose-N'.
- MAX_READY is the maximum number of insns in the current scheduling
- region that can be live at the same time. This can be used to
- allocate scratch space if it is needed, e.g. by
- `TARGET_SCHED_REORDER'.
-
- -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE)
- This hook is executed by the scheduler at the end of each block of
- instructions that are to be scheduled. It can be used to perform
- cleanup of any actions done by the other scheduling hooks. FILE
- is either a null pointer, or a stdio stream to write any debug
- output to. VERBOSE is the verbose level provided by
- `-fsched-verbose-N'.
-
- -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int
- VERBOSE, int OLD_MAX_UID)
- This hook is executed by the scheduler after function level
- initializations. FILE is either a null pointer, or a stdio stream
- to write any debug output to. VERBOSE is the verbose level
- provided by `-fsched-verbose-N'. OLD_MAX_UID is the maximum insn
- uid when scheduling begins.
-
- -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int
- VERBOSE)
- This is the cleanup hook corresponding to
- `TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a
- stdio stream to write any debug output to. VERBOSE is the verbose
- level provided by `-fsched-verbose-N'.
-
- -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void)
- The hook returns an RTL insn. The automaton state used in the
- pipeline hazard recognizer is changed as if the insn were scheduled
- when the new simulated processor cycle starts. Usage of the hook
- may simplify the automaton pipeline description for some VLIW
- processors. If the hook is defined, it is used only for the
- automaton based pipeline description. The default is not to
- change the state when the new simulated processor cycle starts.
-
- -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void)
- The hook can be used to initialize data used by the previous hook.
-
- -- Target Hook: rtx TARGET_SCHED_DFA_POST_CYCLE_INSN (void)
- The hook is analogous to `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used
- to changed the state as if the insn were scheduled when the new
- simulated processor cycle finishes.
-
- -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void)
- The hook is analogous to `TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but
- used to initialize data used by the previous hook.
-
- -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void)
- The hook to notify target that the current simulated cycle is
- about to finish. The hook is analogous to
- `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in
- more complicated situations - e.g., when advancing state on a
- single insn is not enough.
-
- -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void)
- The hook to notify target that new simulated cycle has just
- started. The hook is analogous to
- `TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in
- more complicated situations - e.g., when advancing state on a
- single insn is not enough.
-
- -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD
- (void)
- This hook controls better choosing an insn from the ready insn
- queue for the DFA-based insn scheduler. Usually the scheduler
- chooses the first insn from the queue. If the hook returns a
- positive value, an additional scheduler code tries all
- permutations of `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD
- ()' subsequent ready insns to choose an insn whose issue will
- result in maximal number of issued insns on the same cycle. For
- the VLIW processor, the code could actually solve the problem of
- packing simple insns into the VLIW insn. Of course, if the rules
- of VLIW packing are described in the automaton.
-
- This code also could be used for superscalar RISC processors. Let
- us consider a superscalar RISC processor with 3 pipelines. Some
- insns can be executed in pipelines A or B, some insns can be
- executed only in pipelines B or C, and one insn can be executed in
- pipeline B. The processor may issue the 1st insn into A and the
- 2nd one into B. In this case, the 3rd insn will wait for freeing B
- until the next cycle. If the scheduler issues the 3rd insn the
- first, the processor could issue all 3 insns per cycle.
-
- Actually this code demonstrates advantages of the automaton based
- pipeline hazard recognizer. We try quickly and easy many insn
- schedules to choose the best one.
-
- The default is no multipass scheduling.
-
- -- Target Hook: int
-TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx INSN)
- This hook controls what insns from the ready insn queue will be
- considered for the multipass insn scheduling. If the hook returns
- zero for INSN, the insn will be not chosen to be issued.
-
- The default is that any ready insns can be chosen to be issued.
-
- -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void
- *DATA, char *READY_TRY, int N_READY, bool FIRST_CYCLE_INSN_P)
- This hook prepares the target backend for a new round of multipass
- scheduling.
-
- -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void
- *DATA, char *READY_TRY, int N_READY, rtx INSN, const void
- *PREV_DATA)
- This hook is called when multipass scheduling evaluates
- instruction INSN.
-
- -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK
- (const void *DATA, char *READY_TRY, int N_READY)
- This is called when multipass scheduling backtracks from
- evaluation of an instruction.
-
- -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const
- void *DATA)
- This hook notifies the target about the result of the concluded
- current round of multipass scheduling.
-
- -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void
- *DATA)
- This hook initializes target-specific data used in multipass
- scheduling.
-
- -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void
- *DATA)
- This hook finalizes target-specific data used in multipass
- scheduling.
-
- -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int
- VERBOSE, rtx INSN, int LAST_CLOCK, int CLOCK, int *SORT_P)
- This hook is called by the insn scheduler before issuing INSN on
- cycle CLOCK. If the hook returns nonzero, INSN is not issued on
- this processor cycle. Instead, the processor cycle is advanced.
- If *SORT_P is zero, the insn ready queue is not sorted on the new
- cycle start as usually. DUMP and VERBOSE specify the file and
- verbosity level to use for debugging output. LAST_CLOCK and CLOCK
- are, respectively, the processor cycle on which the previous insn
- has been issued, and the current processor cycle.
-
- -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep
- *_DEP, int COST, int DISTANCE)
- This hook is used to define which dependences are considered
- costly by the target, so costly that it is not advisable to
- schedule the insns that are involved in the dependence too close
- to one another. The parameters to this hook are as follows: The
- first parameter _DEP is the dependence being evaluated. The
- second parameter COST is the cost of the dependence as estimated
- by the scheduler, and the third parameter DISTANCE is the distance
- in cycles between the two insns. The hook returns `true' if
- considering the distance between the two insns the dependence
- between them is considered costly by the target, and `false'
- otherwise.
-
- Defining this hook can be useful in multiple-issue out-of-order
- machines, where (a) it's practically hopeless to predict the
- actual data/resource delays, however: (b) there's a better chance
- to predict the actual grouping that will be formed, and (c)
- correctly emulating the grouping can be very important. In such
- targets one may want to allow issuing dependent insns closer to
- one another--i.e., closer than the dependence distance; however,
- not in cases of "costly dependences", which this hooks allows to
- define.
-
- -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void)
- This hook is called by the insn scheduler after emitting a new
- instruction to the instruction stream. The hook notifies a target
- backend to extend its per instruction data structures.
-
- -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void)
- Return a pointer to a store large enough to hold target scheduling
- context.
-
- -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool
- CLEAN_P)
- Initialize store pointed to by TC to hold target scheduling
- context. It CLEAN_P is true then initialize TC as if scheduler is
- at the beginning of the block. Otherwise, copy the current
- context into TC.
-
- -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC)
- Copy target scheduling context pointed to by TC to the current
- context.
-
- -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC)
- Deallocate internal data in target scheduling context pointed to
- by TC.
-
- -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC)
- Deallocate a store for target scheduling context pointed to by TC.
-
- -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx INSN, int
- REQUEST, rtx *NEW_PAT)
- This hook is called by the insn scheduler when INSN has only
- speculative dependencies and therefore can be scheduled
- speculatively. The hook is used to check if the pattern of INSN
- has a speculative version and, in case of successful check, to
- generate that speculative pattern. The hook should return 1, if
- the instruction has a speculative form, or -1, if it doesn't.
- REQUEST describes the type of requested speculation. If the
- return value equals 1 then NEW_PAT is assigned the generated
- speculative pattern.
-
- -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (int DEP_STATUS)
- This hook is called by the insn scheduler during generation of
- recovery code for INSN. It should return `true', if the
- corresponding check instruction should branch to recovery code, or
- `false' otherwise.
-
- -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx INSN, rtx LABEL,
- int MUTATE_P)
- This hook is called by the insn scheduler to generate a pattern
- for recovery check instruction. If MUTATE_P is zero, then INSN is
- a speculative instruction for which the check should be generated.
- LABEL is either a label of a basic block, where recovery code
- should be emitted, or a null pointer, when requested check doesn't
- branch to recovery code (a simple check). If MUTATE_P is nonzero,
- then a pattern for a branchy check corresponding to a simple check
- denoted by INSN should be generated. In this case LABEL can't be
- null.
-
- -- Target Hook: bool
-TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC (const_rtx
- INSN)
- This hook is used as a workaround for
- `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD' not being
- called on the first instruction of the ready list. The hook is
- used to discard speculative instructions that stand first in the
- ready list from being scheduled on the current cycle. If the hook
- returns `false', INSN will not be chosen to be issued. For
- non-speculative instructions, the hook should always return
- `true'. For example, in the ia64 backend the hook is used to
- cancel data speculative insns when the ALAT table is nearly full.
-
- -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct
- spec_info_def *SPEC_INFO)
- This hook is used by the insn scheduler to find out what features
- should be enabled/used. The structure *SPEC_INFO should be filled
- in by the target. The structure describes speculation types that
- can be used in the scheduler.
-
- -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G)
- This hook is called by the swing modulo scheduler to calculate a
- resource-based lower bound which is based on the resources
- available in the machine and the resources required by each
- instruction. The target backend can use G to calculate such
- bound. A very simple lower bound will be used in case this hook
- is not implemented: the total number of instructions divided by
- the issue rate.
-
- -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx INSN, int X)
- This hook is called by Haifa Scheduler. It returns true if
- dispatch scheduling is supported in hardware and the condition
- specified in the parameter is true.
-
- -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx INSN, int X)
- This hook is called by Haifa Scheduler. It performs the operation
- specified in its second parameter.
-
-
-File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros
-
-17.19 Dividing the Output into Sections (Texts, Data, ...)
-==========================================================
-
-An object file is divided into sections containing different types of
-data. In the most common case, there are three sections: the "text
-section", which holds instructions and read-only data; the "data
-section", which holds initialized writable data; and the "bss section",
-which holds uninitialized data. Some systems have other kinds of
-sections.
-
- `varasm.c' provides several well-known sections, such as
-`text_section', `data_section' and `bss_section'. The normal way of
-controlling a `FOO_section' variable is to define the associated
-`FOO_SECTION_ASM_OP' macro, as described below. The macros are only
-read once, when `varasm.c' initializes itself, so their values must be
-run-time constants. They may however depend on command-line flags.
-
- _Note:_ Some run-time files, such `crtstuff.c', also make use of the
-`FOO_SECTION_ASM_OP' macros, and expect them to be string literals.
-
- Some assemblers require a different string to be written every time a
-section is selected. If your assembler falls into this category, you
-should define the `TARGET_ASM_INIT_SECTIONS' hook and use
-`get_unnamed_section' to set up the sections.
-
- You must always create a `text_section', either by defining
-`TEXT_SECTION_ASM_OP' or by initializing `text_section' in
-`TARGET_ASM_INIT_SECTIONS'. The same is true of `data_section' and
-`DATA_SECTION_ASM_OP'. If you do not create a distinct
-`readonly_data_section', the default is to reuse `text_section'.
-
- All the other `varasm.c' sections are optional, and are null if the
-target does not provide them.
-
- -- Macro: TEXT_SECTION_ASM_OP
- A C expression whose value is a string, including spacing,
- containing the assembler operation that should precede
- instructions and read-only data. Normally `"\t.text"' is right.
-
- -- Macro: HOT_TEXT_SECTION_NAME
- If defined, a C string constant for the name of the section
- containing most frequently executed functions of the program. If
- not defined, GCC will provide a default definition if the target
- supports named sections.
-
- -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME
- If defined, a C string constant for the name of the section
- containing unlikely executed functions in the program.
-
- -- Macro: DATA_SECTION_ASM_OP
- A C expression whose value is a string, including spacing,
- containing the assembler operation to identify the following data
- as writable initialized data. Normally `"\t.data"' is right.
-
- -- Macro: SDATA_SECTION_ASM_OP
- If defined, a C expression whose value is a string, including
- spacing, containing the assembler operation to identify the
- following data as initialized, writable small data.
-
- -- Macro: READONLY_DATA_SECTION_ASM_OP
- A C expression whose value is a string, including spacing,
- containing the assembler operation to identify the following data
- as read-only initialized data.
-
- -- Macro: BSS_SECTION_ASM_OP
- If defined, a C expression whose value is a string, including
- spacing, containing the assembler operation to identify the
- following data as uninitialized global data. If not defined, and
- neither `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined,
- uninitialized global data will be output in the data section if
- `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be
- used.
-
- -- Macro: SBSS_SECTION_ASM_OP
- If defined, a C expression whose value is a string, including
- spacing, containing the assembler operation to identify the
- following data as uninitialized, writable small data.
-
- -- Macro: TLS_COMMON_ASM_OP
- If defined, a C expression whose value is a string containing the
- assembler operation to identify the following data as thread-local
- common data. The default is `".tls_common"'.
-
- -- Macro: TLS_SECTION_ASM_FLAG
- If defined, a C expression whose value is a character constant
- containing the flag used to mark a section as a TLS section. The
- default is `'T''.
-
- -- Macro: INIT_SECTION_ASM_OP
- If defined, a C expression whose value is a string, including
- spacing, containing the assembler operation to identify the
- following data as initialization code. If not defined, GCC will
- assume such a section does not exist. This section has no
- corresponding `init_section' variable; it is used entirely in
- runtime code.
-
- -- Macro: FINI_SECTION_ASM_OP
- If defined, a C expression whose value is a string, including
- spacing, containing the assembler operation to identify the
- following data as finalization code. If not defined, GCC will
- assume such a section does not exist. This section has no
- corresponding `fini_section' variable; it is used entirely in
- runtime code.
-
- -- Macro: INIT_ARRAY_SECTION_ASM_OP
- If defined, a C expression whose value is a string, including
- spacing, containing the assembler operation to identify the
- following data as part of the `.init_array' (or equivalent)
- section. If not defined, GCC will assume such a section does not
- exist. Do not define both this macro and `INIT_SECTION_ASM_OP'.
-
- -- Macro: FINI_ARRAY_SECTION_ASM_OP
- If defined, a C expression whose value is a string, including
- spacing, containing the assembler operation to identify the
- following data as part of the `.fini_array' (or equivalent)
- section. If not defined, GCC will assume such a section does not
- exist. Do not define both this macro and `FINI_SECTION_ASM_OP'.
-
- -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION)
- If defined, an ASM statement that switches to a different section
- via SECTION_OP, calls FUNCTION, and switches back to the text
- section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or
- `FINI_SECTION_ASM_OP' to calls to initialization and finalization
- functions from the init and fini sections. By default, this macro
- uses a simple function call. Some ports need hand-crafted
- assembly code to avoid dependencies on registers initialized in
- the function prologue or to ensure that constant pools don't end
- up too far way in the text section.
-
- -- Macro: TARGET_LIBGCC_SDATA_SECTION
- If defined, a string which names the section into which small
- variables defined in crtstuff and libgcc should go. This is useful
- when the target has options for optimizing access to small data,
- and you want the crtstuff and libgcc routines to be conservative
- in what they expect of your application yet liberal in what your
- application expects. For example, for targets with a `.sdata'
- section (like MIPS), you could compile crtstuff with `-G 0' so
- that it doesn't require small data support from your application,
- but use this macro to put small data into `.sdata' so that your
- application can access these variables whether it uses small data
- or not.
-
- -- Macro: FORCE_CODE_SECTION_ALIGN
- If defined, an ASM statement that aligns a code section to some
- arbitrary boundary. This is used to force all fragments of the
- `.init' and `.fini' sections to have to same alignment and thus
- prevent the linker from having to add any padding.
-
- -- Macro: JUMP_TABLES_IN_TEXT_SECTION
- Define this macro to be an expression with a nonzero value if jump
- tables (for `tablejump' insns) should be output in the text
- section, along with the assembler instructions. Otherwise, the
- readonly data section is used.
-
- This macro is irrelevant if there is no separate readonly data
- section.
-
- -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void)
- Define this hook if you need to do something special to set up the
- `varasm.c' sections, or if your target has some special sections
- of its own that you need to create.
-
- GCC calls this hook after processing the command line, but before
- writing any assembly code, and before calling any of the
- section-returning hooks described below.
-
- -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void)
- Return a mask describing how relocations should be treated when
- selecting sections. Bit 1 should be set if global relocations
- should be placed in a read-write section; bit 0 should be set if
- local relocations should be placed in a read-write section.
-
- The default version of this function returns 3 when `-fpic' is in
- effect, and 0 otherwise. The hook is typically redefined when the
- target cannot support (some kinds of) dynamic relocations in
- read-only sections even in executables.
-
- -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int
- RELOC, unsigned HOST_WIDE_INT ALIGN)
- Return the section into which EXP should be placed. You can
- assume that EXP is either a `VAR_DECL' node or a constant of some
- sort. RELOC indicates whether the initial value of EXP requires
- link-time relocations. Bit 0 is set when variable contains local
- relocations only, while bit 1 is set for global relocations.
- ALIGN is the constant alignment in bits.
-
- The default version of this function takes care of putting
- read-only variables in `readonly_data_section'.
-
- See also USE_SELECT_SECTION_FOR_FUNCTIONS.
-
- -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS
- Define this macro if you wish TARGET_ASM_SELECT_SECTION to be
- called for `FUNCTION_DECL's as well as for variables and constants.
-
- In the case of a `FUNCTION_DECL', RELOC will be zero if the
- function has been determined to be likely to be called, and
- nonzero if it is unlikely to be called.
-
- -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC)
- Build up a unique section name, expressed as a `STRING_CST' node,
- and assign it to `DECL_SECTION_NAME (DECL)'. As with
- `TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial
- value of EXP requires link-time relocations.
-
- The default version of this function appends the symbol name to the
- ELF section name that would normally be used for the symbol. For
- example, the function `foo' would be placed in `.text.foo'.
- Whatever the actual target object format, this is often good
- enough.
-
- -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree
- DECL)
- Return the readonly data section associated with
- `DECL_SECTION_NAME (DECL)'. The default version of this function
- selects `.gnu.linkonce.r.name' if the function's section is
- `.gnu.linkonce.t.name', `.rodata.name' if function is in
- `.text.name', and the normal readonly-data section otherwise.
-
- -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (enum
- machine_mode MODE, rtx X, unsigned HOST_WIDE_INT ALIGN)
- Return the section into which a constant X, of mode MODE, should
- be placed. You can assume that X is some kind of constant in RTL.
- The argument MODE is redundant except in the case of a `const_int'
- rtx. ALIGN is the constant alignment in bits.
-
- The default version of this function takes care of putting symbolic
- constants in `flag_pic' mode in `data_section' and everything else
- in `readonly_data_section'.
-
- -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL,
- tree ID)
- Define this hook if you need to postprocess the assembler name
- generated by target-independent code. The ID provided to this
- hook will be the computed name (e.g., the macro `DECL_NAME' of the
- DECL in C, or the mangled name of the DECL in C++). The return
- value of the hook is an `IDENTIFIER_NODE' for the appropriate
- mangled name on your target system. The default implementation of
- this hook just returns the ID provided.
-
- -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL,
- int NEW_DECL_P)
- Define this hook if references to a symbol or a constant must be
- treated differently depending on something about the variable or
- function named by the symbol (such as what section it is in).
-
- The hook is executed immediately after rtl has been created for
- DECL, which may be a variable or function declaration or an entry
- in the constant pool. In either case, RTL is the rtl in question.
- Do _not_ use `DECL_RTL (DECL)' in this hook; that field may not
- have been initialized yet.
-
- In the case of a constant, it is safe to assume that the rtl is a
- `mem' whose address is a `symbol_ref'. Most decls will also have
- this form, but that is not guaranteed. Global register variables,
- for instance, will have a `reg' for their rtl. (Normally the
- right thing to do with such unusual rtl is leave it alone.)
-
- The NEW_DECL_P argument will be true if this is the first time
- that `TARGET_ENCODE_SECTION_INFO' has been invoked on this decl.
- It will be false for subsequent invocations, which will happen for
- duplicate declarations. Whether or not anything must be done for
- the duplicate declaration depends on whether the hook examines
- `DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is
- called for a constant.
-
- The usual thing for this hook to do is to record flags in the
- `symbol_ref', using `SYMBOL_REF_FLAG' or `SYMBOL_REF_FLAGS'.
- Historically, the name string was modified if it was necessary to
- encode more than one bit of information, but this practice is now
- discouraged; use `SYMBOL_REF_FLAGS'.
-
- The default definition of this hook, `default_encode_section_info'
- in `varasm.c', sets a number of commonly-useful bits in
- `SYMBOL_REF_FLAGS'. Check whether the default does what you need
- before overriding it.
-
- -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char
- *NAME)
- Decode NAME and return the real name part, sans the characters
- that `TARGET_ENCODE_SECTION_INFO' may have added.
-
- -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP)
- Returns true if EXP should be placed into a "small data" section.
- The default version of this hook always returns false.
-
- -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION
- Contains the value true if the target places read-only "small
- data" into a separate section. The default value is false.
-
- -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void)
- It returns true if target wants profile code emitted before
- prologue.
-
- The default version of this hook use the target macro
- `PROFILE_BEFORE_PROLOGUE'.
-
- -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP)
- Returns true if EXP names an object for which name resolution
- rules must resolve to the current "module" (dynamic shared library
- or executable image).
-
- The default version of this hook implements the name resolution
- rules for ELF, which has a looser model of global name binding
- than other currently supported object file formats.
-
- -- Target Hook: bool TARGET_HAVE_TLS
- Contains the value true if the target supports thread-local
- storage. The default value is false.
-
-
-File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros
-
-17.20 Position Independent Code
-===============================
-
-This section describes macros that help implement generation of position
-independent code. Simply defining these macros is not enough to
-generate valid PIC; you must also add support to the hook
-`TARGET_LEGITIMATE_ADDRESS_P' and to the macro `PRINT_OPERAND_ADDRESS',
-as well as `LEGITIMIZE_ADDRESS'. You must modify the definition of
-`movsi' to do something appropriate when the source operand contains a
-symbolic address. You may also need to alter the handling of switch
-statements so that they use relative addresses.
-
- -- Macro: PIC_OFFSET_TABLE_REGNUM
- The register number of the register used to address a table of
- static data addresses in memory. In some cases this register is
- defined by a processor's "application binary interface" (ABI).
- When this macro is defined, RTL is generated for this register
- once, as with the stack pointer and frame pointer registers. If
- this macro is not defined, it is up to the machine-dependent files
- to allocate such a register (if necessary). Note that this
- register must be fixed when in use (e.g. when `flag_pic' is true).
-
- -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
- A C expression that is nonzero if the register defined by
- `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined,
- the default is zero. Do not define this macro if
- `PIC_OFFSET_TABLE_REGNUM' is not defined.
-
- -- Macro: LEGITIMATE_PIC_OPERAND_P (X)
- A C expression that is nonzero if X is a legitimate immediate
- operand on the target machine when generating position independent
- code. You can assume that X satisfies `CONSTANT_P', so you need
- not check this. You can also assume FLAG_PIC is true, so you need
- not check it either. You need not define this macro if all
- constants (including `SYMBOL_REF') can be immediate operands when
- generating position independent code.
-
-
-File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros
-
-17.21 Defining the Output Assembler Language
-============================================
-
-This section describes macros whose principal purpose is to describe how
-to write instructions in assembler language--rather than what the
-instructions do.
-
-* Menu:
-
-* File Framework:: Structural information for the assembler file.
-* Data Output:: Output of constants (numbers, strings, addresses).
-* Uninitialized Data:: Output of uninitialized variables.
-* Label Output:: Output and generation of labels.
-* Initialization:: General principles of initialization
- and termination routines.
-* Macros for Initialization::
- Specific macros that control the handling of
- initialization and termination routines.
-* Instruction Output:: Output of actual instructions.
-* Dispatch Tables:: Output of jump tables.
-* Exception Region Output:: Output of exception region code.
-* Alignment Output:: Pseudo ops for alignment and skipping data.
-
-
-File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format
-
-17.21.1 The Overall Framework of an Assembler File
---------------------------------------------------
-
-This describes the overall framework of an assembly file.
-
- -- Target Hook: void TARGET_ASM_FILE_START (void)
- Output to `asm_out_file' any text which the assembler expects to
- find at the beginning of a file. The default behavior is
- controlled by two flags, documented below. Unless your target's
- assembler is quite unusual, if you override the default, you
- should call `default_file_start' at some point in your target
- hook. This lets other target files rely on these variables.
-
- -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF
- If this flag is true, the text of the macro `ASM_APP_OFF' will be
- printed as the very first line in the assembly file, unless
- `-fverbose-asm' is in effect. (If that macro has been defined to
- the empty string, this variable has no effect.) With the normal
- definition of `ASM_APP_OFF', the effect is to notify the GNU
- assembler that it need not bother stripping comments or extra
- whitespace from its input. This allows it to work a bit faster.
-
- The default is false. You should not set it to true unless you
- have verified that your port does not generate any extra
- whitespace or comments that will cause GAS to issue errors in
- NO_APP mode.
-
- -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE
- If this flag is true, `output_file_directive' will be called for
- the primary source file, immediately after printing `ASM_APP_OFF'
- (if that is enabled). Most ELF assemblers expect this to be done.
- The default is false.
-
- -- Target Hook: void TARGET_ASM_FILE_END (void)
- Output to `asm_out_file' any text which the assembler expects to
- find at the end of a file. The default is to output nothing.
-
- -- Function: void file_end_indicate_exec_stack ()
- Some systems use a common convention, the `.note.GNU-stack'
- special section, to indicate whether or not an object file relies
- on the stack being executable. If your system uses this
- convention, you should define `TARGET_ASM_FILE_END' to this
- function. If you need to do other things in that hook, have your
- hook function call this function.
-
- -- Target Hook: void TARGET_ASM_LTO_START (void)
- Output to `asm_out_file' any text which the assembler expects to
- find at the start of an LTO section. The default is to output
- nothing.
-
- -- Target Hook: void TARGET_ASM_LTO_END (void)
- Output to `asm_out_file' any text which the assembler expects to
- find at the end of an LTO section. The default is to output
- nothing.
-
- -- Target Hook: void TARGET_ASM_CODE_END (void)
- Output to `asm_out_file' any text which is needed before emitting
- unwind info and debug info at the end of a file. Some targets emit
- here PIC setup thunks that cannot be emitted at the end of file,
- because they couldn't have unwind info then. The default is to
- output nothing.
-
- -- Macro: ASM_COMMENT_START
- A C string constant describing how to begin a comment in the target
- assembler language. The compiler assumes that the comment will
- end at the end of the line.
-
- -- Macro: ASM_APP_ON
- A C string constant for text to be output before each `asm'
- statement or group of consecutive ones. Normally this is
- `"#APP"', which is a comment that has no effect on most assemblers
- but tells the GNU assembler that it must check the lines that
- follow for all valid assembler constructs.
-
- -- Macro: ASM_APP_OFF
- A C string constant for text to be output after each `asm'
- statement or group of consecutive ones. Normally this is
- `"#NO_APP"', which tells the GNU assembler to resume making the
- time-saving assumptions that are valid for ordinary compiler
- output.
-
- -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME)
- A C statement to output COFF information or DWARF debugging
- information which indicates that filename NAME is the current
- source file to the stdio stream STREAM.
-
- This macro need not be defined if the standard form of output for
- the file format in use is appropriate.
-
- -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE,
- const char *NAME)
- Output COFF information or DWARF debugging information which
- indicates that filename NAME is the current source file to the
- stdio stream FILE.
-
- This target hook need not be defined if the standard form of
- output for the file format in use is appropriate.
-
- -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING)
- A C statement to output the string STRING to the stdio stream
- STREAM. If you do not call the function `output_quoted_string' in
- your config files, GCC will only call it to output filenames to
- the assembler source. So you can use it to canonicalize the format
- of the filename using this macro.
-
- -- Macro: ASM_OUTPUT_IDENT (STREAM, STRING)
- A C statement to output something to the assembler file to handle a
- `#ident' directive containing the text STRING. If this macro is
- not defined, nothing is output for a `#ident' directive.
-
- -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME,
- unsigned int FLAGS, tree DECL)
- Output assembly directives to switch to section NAME. The section
- should have attributes as specified by FLAGS, which is a bit mask
- of the `SECTION_*' flags defined in `output.h'. If DECL is
- non-NULL, it is the `VAR_DECL' or `FUNCTION_DECL' with which this
- section is associated.
-
- -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum
- node_frequency FREQ, bool STARTUP, bool EXIT)
- Return preferred text (sub)section for function DECL. Main
- purpose of this function is to separate cold, normal and hot
- functions. STARTUP is true when function is known to be used only
- at startup (from static constructors or it is `main()'). EXIT is
- true when function is known to be used only at exit (from static
- destructors). Return NULL if function should go to default text
- section.
-
- -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE
- *FILE, tree DECL, bool NEW_IS_COLD)
- Used by the target to emit any assembler directives or additional
- labels needed when a function is partitioned between different
- sections. Output should be written to FILE. The function decl
- is available as DECL and the new section is `cold' if NEW_IS_COLD
- is `true'.
-
- -- Target Hook: bool TARGET_HAVE_NAMED_SECTIONS
- This flag is true if the target supports
- `TARGET_ASM_NAMED_SECTION'. It must not be modified by
- command-line option processing.
-
- -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS
- This flag is true if we can create zeroed data by switching to a
- BSS section and then using `ASM_OUTPUT_SKIP' to allocate the space.
- This is true on most ELF targets.
-
- -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL,
- const char *NAME, int RELOC)
- Choose a set of section attributes for use by
- `TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a
- section name, and whether or not the declaration's initializer may
- contain runtime relocations. DECL may be null, in which case
- read-write data should be assumed.
-
- The default version of this function handles choosing code vs data,
- read-only vs read-write data, and `flag_pic'. You should only
- need to override this if your target has special flags that might
- be set via `__attribute__'.
-
- -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type
- TYPE, const char *TEXT)
- Provides the target with the ability to record the gcc command line
- switches that have been passed to the compiler, and options that
- are enabled. The TYPE argument specifies what is being recorded.
- It can take the following values:
-
- `SWITCH_TYPE_PASSED'
- TEXT is a command line switch that has been set by the user.
-
- `SWITCH_TYPE_ENABLED'
- TEXT is an option which has been enabled. This might be as a
- direct result of a command line switch, or because it is
- enabled by default or because it has been enabled as a side
- effect of a different command line switch. For example, the
- `-O2' switch enables various different individual
- optimization passes.
-
- `SWITCH_TYPE_DESCRIPTIVE'
- TEXT is either NULL or some descriptive text which should be
- ignored. If TEXT is NULL then it is being used to warn the
- target hook that either recording is starting or ending. The
- first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL,
- the warning is for start up and the second time the warning
- is for wind down. This feature is to allow the target hook
- to make any necessary preparations before it starts to record
- switches and to perform any necessary tidying up after it has
- finished recording switches.
-
- `SWITCH_TYPE_LINE_START'
- This option can be ignored by this target hook.
-
- `SWITCH_TYPE_LINE_END'
- This option can be ignored by this target hook.
-
- The hook's return value must be zero. Other return values may be
- supported in the future.
-
- By default this hook is set to NULL, but an example implementation
- is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES,
- it records the switches as ASCII text inside a new, string
- mergeable section in the assembler output file. The name of the
- new section is provided by the
- `TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook.
-
- -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION
- This is the name of the section that will be created by the example
- ELF implementation of the `TARGET_ASM_RECORD_GCC_SWITCHES' target
- hook.
-
-
-File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format
-
-17.21.2 Output of Data
-----------------------
-
- -- Target Hook: const char * TARGET_ASM_BYTE_OP
- -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP
- -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP
- -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP
- -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP
- -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP
- -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP
- -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP
- -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP
- These hooks specify assembly directives for creating certain kinds
- of integer object. The `TARGET_ASM_BYTE_OP' directive creates a
- byte-sized object, the `TARGET_ASM_ALIGNED_HI_OP' one creates an
- aligned two-byte object, and so on. Any of the hooks may be
- `NULL', indicating that no suitable directive is available.
-
- The compiler will print these strings at the start of a new line,
- followed immediately by the object's initial value. In most cases,
- the string should contain a tab, a pseudo-op, and then another tab.
-
- -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int
- ALIGNED_P)
- The `assemble_integer' function uses this hook to output an
- integer object. X is the object's value, SIZE is its size in
- bytes and ALIGNED_P indicates whether it is aligned. The function
- should return `true' if it was able to output the object. If it
- returns false, `assemble_integer' will try to split the object
- into smaller parts.
-
- The default implementation of this hook will use the
- `TARGET_ASM_BYTE_OP' family of strings, returning `false' when the
- relevant string is `NULL'.
-
- -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE,
- rtx X)
- A target hook to recognize RTX patterns that `output_addr_const'
- can't deal with, and output assembly code to FILE corresponding to
- the pattern X. This may be used to allow machine-dependent
- `UNSPEC's to appear within constants.
-
- If target hook fails to recognize a pattern, it must return
- `false', so that a standard error message is printed. If it
- prints an error message itself, by calling, for example,
- `output_operand_lossage', it may just return `true'.
-
- -- Macro: OUTPUT_ADDR_CONST_EXTRA (STREAM, X, FAIL)
- A C statement to recognize RTX patterns that `output_addr_const'
- can't deal with, and output assembly code to STREAM corresponding
- to the pattern X. This may be used to allow machine-dependent
- `UNSPEC's to appear within constants.
-
- If `OUTPUT_ADDR_CONST_EXTRA' fails to recognize a pattern, it must
- `goto fail', so that a standard error message is printed. If it
- prints an error message itself, by calling, for example,
- `output_operand_lossage', it may just complete normally.
-
- -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN)
- A C statement to output to the stdio stream STREAM an assembler
- instruction to assemble a string constant containing the LEN bytes
- at PTR. PTR will be a C expression of type `char *' and LEN a C
- expression of type `int'.
-
- If the assembler has a `.ascii' pseudo-op as found in the Berkeley
- Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'.
-
- -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N)
- A C statement to output word N of a function descriptor for DECL.
- This must be defined if `TARGET_VTABLE_USES_DESCRIPTORS' is
- defined, and is otherwise unused.
-
- -- Macro: CONSTANT_POOL_BEFORE_FUNCTION
- You may define this macro as a C expression. You should define the
- expression to have a nonzero value if GCC should output the
- constant pool for a function before the code for the function, or
- a zero value if GCC should output the constant pool after the
- function. If you do not define this macro, the usual case, GCC
- will output the constant pool before the function.
-
- -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE)
- A C statement to output assembler commands to define the start of
- the constant pool for a function. FUNNAME is a string giving the
- name of the function. Should the return type of the function be
- required, it can be obtained via FUNDECL. SIZE is the size, in
- bytes, of the constant pool that will be written immediately after
- this call.
-
- If no constant-pool prefix is required, the usual case, this macro
- need not be defined.
-
- -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN,
- LABELNO, JUMPTO)
- A C statement (with or without semicolon) to output a constant in
- the constant pool, if it needs special treatment. (This macro
- need not do anything for RTL expressions that can be output
- normally.)
-
- The argument FILE is the standard I/O stream to output the
- assembler code on. X is the RTL expression for the constant to
- output, and MODE is the machine mode (in case X is a `const_int').
- ALIGN is the required alignment for the value X; you should output
- an assembler directive to force this much alignment.
-
- The argument LABELNO is a number to use in an internal label for
- the address of this pool entry. The definition of this macro is
- responsible for outputting the label definition at the proper
- place. Here is how to do this:
-
- `(*targetm.asm_out.internal_label)' (FILE, "LC", LABELNO);
-
- When you output a pool entry specially, you should end with a
- `goto' to the label JUMPTO. This will prevent the same pool entry
- from being output a second time in the usual manner.
-
- You need not define this macro if it would do nothing.
-
- -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE)
- A C statement to output assembler commands to at the end of the
- constant pool for a function. FUNNAME is a string giving the name
- of the function. Should the return type of the function be
- required, you can obtain it via FUNDECL. SIZE is the size, in
- bytes, of the constant pool that GCC wrote immediately before this
- call.
-
- If no constant-pool epilogue is required, the usual case, you need
- not define this macro.
-
- -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR)
- Define this macro as a C expression which is nonzero if C is used
- as a logical line separator by the assembler. STR points to the
- position in the string where C was found; this can be used if a
- line separator uses multiple characters.
-
- If you do not define this macro, the default is that only the
- character `;' is treated as a logical line separator.
-
- -- Target Hook: const char * TARGET_ASM_OPEN_PAREN
- -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN
- These target hooks are C string constants, describing the syntax
- in the assembler for grouping arithmetic expressions. If not
- overridden, they default to normal parentheses, which is correct
- for most assemblers.
-
- These macros are provided by `real.h' for writing the definitions of
-`ASM_OUTPUT_DOUBLE' and the like:
-
- -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L)
- -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L)
- -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L)
- -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L)
- -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L)
- -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L)
- These translate X, of type `REAL_VALUE_TYPE', to the target's
- floating point representation, and store its bit pattern in the
- variable L. For `REAL_VALUE_TO_TARGET_SINGLE' and
- `REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple
- `long int'. For the others, it should be an array of `long int'.
- The number of elements in this array is determined by the size of
- the desired target floating point data type: 32 bits of it go in
- each `long int' array element. Each array element holds 32 bits
- of the result, even if `long int' is wider than 32 bits on the
- host machine.
-
- The array element values are designed so that you can print them
- out using `fprintf' in the order they should appear in the target
- machine's memory.
-
-
-File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format
-
-17.21.3 Output of Uninitialized Variables
------------------------------------------
-
-Each of the macros in this section is used to do the whole job of
-outputting a single uninitialized variable.
-
- -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM the assembler definition of a common-label named NAME whose
- size is SIZE bytes. The variable ROUNDED is the size rounded up
- to whatever alignment the caller wants. It is possible that SIZE
- may be zero, for instance if a struct with no other member than a
- zero-length array is defined. In this case, the backend must
- output a symbol definition that allocates at least one byte, both
- so that the address of the resulting object does not compare equal
- to any other, and because some object formats cannot even express
- the concept of a zero-sized common symbol, as that is how they
- represent an ordinary undefined external.
-
- Use the expression `assemble_name (STREAM, NAME)' to output the
- name itself; before and after that, output the additional
- assembler syntax for defining the name, and a newline.
-
- This macro controls how the assembler definitions of uninitialized
- common global variables are output.
-
- -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT)
- Like `ASM_OUTPUT_COMMON' except takes the required alignment as a
- separate, explicit argument. If you define this macro, it is used
- in place of `ASM_OUTPUT_COMMON', and gives you more flexibility in
- handling the required alignment of the variable. The alignment is
- specified as the number of bits.
-
- -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE,
- ALIGNMENT)
- Like `ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable
- to be output, if there is one, or `NULL_TREE' if there is no
- corresponding variable. If you define this macro, GCC will use it
- in place of both `ASM_OUTPUT_COMMON' and
- `ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to
- see the variable's decl in order to chose what to output.
-
- -- Macro: ASM_OUTPUT_BSS (STREAM, DECL, NAME, SIZE, ROUNDED)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM the assembler definition of uninitialized global DECL named
- NAME whose size is SIZE bytes. The variable ROUNDED is the size
- rounded up to whatever alignment the caller wants.
-
- Try to use function `asm_output_bss' defined in `varasm.c' when
- defining this macro. If unable, use the expression `assemble_name
- (STREAM, NAME)' to output the name itself; before and after that,
- output the additional assembler syntax for defining the name, and
- a newline.
-
- There are two ways of handling global BSS. One is to define either
- this macro or its aligned counterpart, `ASM_OUTPUT_ALIGNED_BSS'.
- The other is to have `TARGET_ASM_SELECT_SECTION' return a
- switchable BSS section (*note
- TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do
- both.
-
- Some languages do not have `common' data, and require a non-common
- form of global BSS in order to handle uninitialized globals
- efficiently. C++ is one example of this. However, if the target
- does not support global BSS, the front end may choose to make
- globals common in order to save space in the object file.
-
- -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT)
- Like `ASM_OUTPUT_BSS' except takes the required alignment as a
- separate, explicit argument. If you define this macro, it is used
- in place of `ASM_OUTPUT_BSS', and gives you more flexibility in
- handling the required alignment of the variable. The alignment is
- specified as the number of bits.
-
- Try to use function `asm_output_aligned_bss' defined in file
- `varasm.c' when defining this macro.
-
- -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM the assembler definition of a local-common-label named NAME
- whose size is SIZE bytes. The variable ROUNDED is the size
- rounded up to whatever alignment the caller wants.
-
- Use the expression `assemble_name (STREAM, NAME)' to output the
- name itself; before and after that, output the additional
- assembler syntax for defining the name, and a newline.
-
- This macro controls how the assembler definitions of uninitialized
- static variables are output.
-
- -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT)
- Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a
- separate, explicit argument. If you define this macro, it is used
- in place of `ASM_OUTPUT_LOCAL', and gives you more flexibility in
- handling the required alignment of the variable. The alignment is
- specified as the number of bits.
-
- -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE,
- ALIGNMENT)
- Like `ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to
- be output, if there is one, or `NULL_TREE' if there is no
- corresponding variable. If you define this macro, GCC will use it
- in place of both `ASM_OUTPUT_DECL' and `ASM_OUTPUT_ALIGNED_DECL'.
- Define this macro when you need to see the variable's decl in
- order to chose what to output.
-
-
-File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format
-
-17.21.4 Output and Generation of Labels
----------------------------------------
-
-This is about outputting labels.
-
- -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM the assembler definition of a label named NAME. Use the
- expression `assemble_name (STREAM, NAME)' to output the name
- itself; before and after that, output the additional assembler
- syntax for defining the name, and a newline. A default definition
- of this macro is provided which is correct for most systems.
-
- -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM the assembler definition of a label named NAME of a
- function. Use the expression `assemble_name (STREAM, NAME)' to
- output the name itself; before and after that, output the
- additional assembler syntax for defining the name, and a newline.
- A default definition of this macro is provided which is correct
- for most systems.
-
- If this macro is not defined, then the function name is defined in
- the usual manner as a label (by means of `ASM_OUTPUT_LABEL').
-
- -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME)
- Identical to `ASM_OUTPUT_LABEL', except that NAME is known to
- refer to a compiler-generated label. The default definition uses
- `assemble_name_raw', which is like `assemble_name' except that it
- is more efficient.
-
- -- Macro: SIZE_ASM_OP
- A C string containing the appropriate assembler directive to
- specify the size of a symbol, without any arguments. On systems
- that use ELF, the default (in `config/elfos.h') is `"\t.size\t"';
- on other systems, the default is not to define this macro.
-
- Define this macro only if it is correct to use the default
- definitions of `ASM_OUTPUT_SIZE_DIRECTIVE' and
- `ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own
- custom definitions of those macros, or if you do not need explicit
- symbol sizes at all, do not define this macro.
-
- -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM a directive telling the assembler that the size of the
- symbol NAME is SIZE. SIZE is a `HOST_WIDE_INT'. If you define
- `SIZE_ASM_OP', a default definition of this macro is provided.
-
- -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM a directive telling the assembler to calculate the size of
- the symbol NAME by subtracting its address from the current
- address.
-
- If you define `SIZE_ASM_OP', a default definition of this macro is
- provided. The default assumes that the assembler recognizes a
- special `.' symbol as referring to the current address, and can
- calculate the difference between this and another symbol. If your
- assembler does not recognize `.' or cannot do calculations with
- it, you will need to redefine `ASM_OUTPUT_MEASURED_SIZE' to use
- some other technique.
-
- -- Macro: TYPE_ASM_OP
- A C string containing the appropriate assembler directive to
- specify the type of a symbol, without any arguments. On systems
- that use ELF, the default (in `config/elfos.h') is `"\t.type\t"';
- on other systems, the default is not to define this macro.
-
- Define this macro only if it is correct to use the default
- definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you
- need your own custom definition of this macro, or if you do not
- need explicit symbol types at all, do not define this macro.
-
- -- Macro: TYPE_OPERAND_FMT
- A C string which specifies (using `printf' syntax) the format of
- the second operand to `TYPE_ASM_OP'. On systems that use ELF, the
- default (in `config/elfos.h') is `"@%s"'; on other systems, the
- default is not to define this macro.
-
- Define this macro only if it is correct to use the default
- definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you
- need your own custom definition of this macro, or if you do not
- need explicit symbol types at all, do not define this macro.
-
- -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM a directive telling the assembler that the type of the
- symbol NAME is TYPE. TYPE is a C string; currently, that string
- is always either `"function"' or `"object"', but you should not
- count on this.
-
- If you define `TYPE_ASM_OP' and `TYPE_OPERAND_FMT', a default
- definition of this macro is provided.
-
- -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM any text necessary for declaring the name NAME of a
- function which is being defined. This macro is responsible for
- outputting the label definition (perhaps using
- `ASM_OUTPUT_FUNCTION_LABEL'). The argument DECL is the
- `FUNCTION_DECL' tree node representing the function.
-
- If this macro is not defined, then the function name is defined in
- the usual manner as a label (by means of
- `ASM_OUTPUT_FUNCTION_LABEL').
-
- You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition
- of this macro.
-
- -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM any text necessary for declaring the size of a function
- which is being defined. The argument NAME is the name of the
- function. The argument DECL is the `FUNCTION_DECL' tree node
- representing the function.
-
- If this macro is not defined, then the function size is not
- defined.
-
- You may wish to use `ASM_OUTPUT_MEASURED_SIZE' in the definition
- of this macro.
-
- -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM any text necessary for declaring the name NAME of an
- initialized variable which is being defined. This macro must
- output the label definition (perhaps using `ASM_OUTPUT_LABEL').
- The argument DECL is the `VAR_DECL' tree node representing the
- variable.
-
- If this macro is not defined, then the variable name is defined in
- the usual manner as a label (by means of `ASM_OUTPUT_LABEL').
-
- You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' and/or
- `ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro.
-
- -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE,
- const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE)
- A target hook to output to the stdio stream FILE any text necessary
- for declaring the name NAME of a constant which is being defined.
- This target hook is responsible for outputting the label
- definition (perhaps using `assemble_label'). The argument EXP is
- the value of the constant, and SIZE is the size of the constant in
- bytes. The NAME will be an internal label.
-
- The default version of this target hook, define the NAME in the
- usual manner as a label (by means of `assemble_label').
-
- You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in this target
- hook.
-
- -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM any text necessary for claiming a register REGNO for a
- global variable DECL with name NAME.
-
- If you don't define this macro, that is equivalent to defining it
- to do nothing.
-
- -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND)
- A C statement (sans semicolon) to finish up declaring a variable
- name once the compiler has processed its initializer fully and
- thus has had a chance to determine the size of an array when
- controlled by an initializer. This is used on systems where it's
- necessary to declare something about the size of the object.
-
- If you don't define this macro, that is equivalent to defining it
- to do nothing.
-
- You may wish to use `ASM_OUTPUT_SIZE_DIRECTIVE' and/or
- `ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro.
-
- -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const
- char *NAME)
- This target hook is a function to output to the stdio stream
- STREAM some commands that will make the label NAME global; that
- is, available for reference from other files.
-
- The default implementation relies on a proper definition of
- `GLOBAL_ASM_OP'.
-
- -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM,
- tree DECL)
- This target hook is a function to output to the stdio stream
- STREAM some commands that will make the name associated with DECL
- global; that is, available for reference from other files.
-
- The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL
- target hook.
-
- -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM some commands that will make the label NAME weak; that is,
- available for reference from other files but only used if no other
- definition is available. Use the expression `assemble_name
- (STREAM, NAME)' to output the name itself; before and after that,
- output the additional assembler syntax for making that name weak,
- and a newline.
-
- If you don't define this macro or `ASM_WEAKEN_DECL', GCC will not
- support weak symbols and you should not define the `SUPPORTS_WEAK'
- macro.
-
- -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE)
- Combines (and replaces) the function of `ASM_WEAKEN_LABEL' and
- `ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function
- or variable decl. If VALUE is not `NULL', this C statement should
- output to the stdio stream STREAM assembler code which defines
- (equates) the weak symbol NAME to have the value VALUE. If VALUE
- is `NULL', it should output commands to make NAME weak.
-
- -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE)
- Outputs a directive that enables NAME to be used to refer to
- symbol VALUE with weak-symbol semantics. `decl' is the
- declaration of `name'.
-
- -- Macro: SUPPORTS_WEAK
- A preprocessor constant expression which evaluates to true if the
- target supports weak symbols.
-
- If you don't define this macro, `defaults.h' provides a default
- definition. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is
- defined, the default definition is `1'; otherwise, it is `0'.
-
- -- Macro: TARGET_SUPPORTS_WEAK
- A C expression which evaluates to true if the target supports weak
- symbols.
-
- If you don't define this macro, `defaults.h' provides a default
- definition. The default definition is `(SUPPORTS_WEAK)'. Define
- this macro if you want to control weak symbol support with a
- compiler flag such as `-melf'.
-
- -- Macro: MAKE_DECL_ONE_ONLY (DECL)
- A C statement (sans semicolon) to mark DECL to be emitted as a
- public symbol such that extra copies in multiple translation units
- will be discarded by the linker. Define this macro if your object
- file format provides support for this concept, such as the `COMDAT'
- section flags in the Microsoft Windows PE/COFF format, and this
- support requires changes to DECL, such as putting it in a separate
- section.
-
- -- Macro: SUPPORTS_ONE_ONLY
- A C expression which evaluates to true if the target supports
- one-only semantics.
-
- If you don't define this macro, `varasm.c' provides a default
- definition. If `MAKE_DECL_ONE_ONLY' is defined, the default
- definition is `1'; otherwise, it is `0'. Define this macro if you
- want to control one-only symbol support with a compiler flag, or if
- setting the `DECL_ONE_ONLY' flag is enough to mark a declaration to
- be emitted as one-only.
-
- -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int
- VISIBILITY)
- This target hook is a function to output to ASM_OUT_FILE some
- commands that will make the symbol(s) associated with DECL have
- hidden, protected or internal visibility as specified by
- VISIBILITY.
-
- -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC
- A C expression that evaluates to true if the target's linker
- expects that weak symbols do not appear in a static archive's
- table of contents. The default is `0'.
-
- Leaving weak symbols out of an archive's table of contents means
- that, if a symbol will only have a definition in one translation
- unit and will have undefined references from other translation
- units, that symbol should not be weak. Defining this macro to be
- nonzero will thus have the effect that certain symbols that would
- normally be weak (explicit template instantiations, and vtables
- for polymorphic classes with noninline key methods) will instead
- be nonweak.
-
- The C++ ABI requires this macro to be zero. Define this macro for
- targets where full C++ ABI compliance is impossible and where
- linker restrictions require weak symbols to be left out of a
- static archive's table of contents.
-
- -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM any text necessary for declaring the name of an external
- symbol named NAME which is referenced in this compilation but not
- defined. The value of DECL is the tree node for the declaration.
-
- This macro need not be defined if it does not need to output
- anything. The GNU assembler and most Unix assemblers don't
- require anything.
-
- -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF)
- This target hook is a function to output to ASM_OUT_FILE an
- assembler pseudo-op to declare a library function name external.
- The name of the library function is given by SYMREF, which is a
- `symbol_ref'.
-
- -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char
- *SYMBOL)
- This target hook is a function to output to ASM_OUT_FILE an
- assembler directive to annotate SYMBOL as used. The Darwin target
- uses the .no_dead_code_strip directive.
-
- -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM a reference in assembler syntax to a label named NAME.
- This should add `_' to the front of the name, if that is customary
- on your operating system, as it is in most Berkeley Unix systems.
- This macro is used in `assemble_name'.
-
- -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME)
- Given a symbol NAME, perform same mangling as `varasm.c''s
- `assemble_name', but in memory rather than to a file stream,
- returning result as an `IDENTIFIER_NODE'. Required for correct
- LTO symtabs. The default implementation calls the
- `TARGET_STRIP_NAME_ENCODING' hook and then prepends the
- `USER_LABEL_PREFIX', if any.
-
- -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM)
- A C statement (sans semicolon) to output a reference to
- `SYMBOL_REF' SYM. If not defined, `assemble_name' will be used to
- output the name of the symbol. This macro may be used to modify
- the way a symbol is referenced depending on information encoded by
- `TARGET_ENCODE_SECTION_INFO'.
-
- -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF)
- A C statement (sans semicolon) to output a reference to BUF, the
- result of `ASM_GENERATE_INTERNAL_LABEL'. If not defined,
- `assemble_name' will be used to output the name of the symbol.
- This macro is not used by `output_asm_label', or the `%l'
- specifier that calls it; the intention is that this macro should
- be set when it is necessary to output a label differently when its
- address is being taken.
-
- -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const
- char *PREFIX, unsigned long LABELNO)
- A function to output to the stdio stream STREAM a label whose name
- is made from the string PREFIX and the number LABELNO.
-
- It is absolutely essential that these labels be distinct from the
- labels used for user-level functions and variables. Otherwise,
- certain programs will have name conflicts with internal labels.
-
- It is desirable to exclude internal labels from the symbol table
- of the object file. Most assemblers have a naming convention for
- labels that should be excluded; on many systems, the letter `L' at
- the beginning of a label has this effect. You should find out what
- convention your system uses, and follow it.
-
- The default version of this function utilizes
- `ASM_GENERATE_INTERNAL_LABEL'.
-
- -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM)
- A C statement to output to the stdio stream STREAM a debug info
- label whose name is made from the string PREFIX and the number
- NUM. This is useful for VLIW targets, where debug info labels may
- need to be treated differently than branch target labels. On some
- systems, branch target labels must be at the beginning of
- instruction bundles, but debug info labels can occur in the middle
- of instruction bundles.
-
- If this macro is not defined, then
- `(*targetm.asm_out.internal_label)' will be used.
-
- -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM)
- A C statement to store into the string STRING a label whose name
- is made from the string PREFIX and the number NUM.
-
- This string, when output subsequently by `assemble_name', should
- produce the output that `(*targetm.asm_out.internal_label)' would
- produce with the same PREFIX and NUM.
-
- If the string begins with `*', then `assemble_name' will output
- the rest of the string unchanged. It is often convenient for
- `ASM_GENERATE_INTERNAL_LABEL' to use `*' in this way. If the
- string doesn't start with `*', then `ASM_OUTPUT_LABELREF' gets to
- output the string, and may change it. (Of course,
- `ASM_OUTPUT_LABELREF' is also part of your machine description, so
- you should know what it does on your machine.)
-
- -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER)
- A C expression to assign to OUTVAR (which is a variable of type
- `char *') a newly allocated string made from the string NAME and
- the number NUMBER, with some suitable punctuation added. Use
- `alloca' to get space for the string.
-
- The string will be used as an argument to `ASM_OUTPUT_LABELREF' to
- produce an assembler label for an internal static variable whose
- name is NAME. Therefore, the string must be such as to result in
- valid assembler code. The argument NUMBER is different each time
- this macro is executed; it prevents conflicts between
- similarly-named internal static variables in different scopes.
-
- Ideally this string should not be a valid C identifier, to prevent
- any conflict with the user's own symbols. Most assemblers allow
- periods or percent signs in assembler symbols; putting at least
- one of these between the name and the number will suffice.
-
- If this macro is not defined, a default definition will be provided
- which is correct for most systems.
-
- -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE)
- A C statement to output to the stdio stream STREAM assembler code
- which defines (equates) the symbol NAME to have the value VALUE.
-
- If `SET_ASM_OP' is defined, a default definition is provided which
- is correct for most systems.
-
- -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME,
- DECL_OF_VALUE)
- A C statement to output to the stdio stream STREAM assembler code
- which defines (equates) the symbol whose tree node is DECL_OF_NAME
- to have the value of the tree node DECL_OF_VALUE. This macro will
- be used in preference to `ASM_OUTPUT_DEF' if it is defined and if
- the tree nodes are available.
-
- If `SET_ASM_OP' is defined, a default definition is provided which
- is correct for most systems.
-
- -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE)
- A C statement that evaluates to true if the assembler code which
- defines (equates) the symbol whose tree node is DECL_OF_NAME to
- have the value of the tree node DECL_OF_VALUE should be emitted
- near the end of the current compilation unit. The default is to
- not defer output of defines. This macro affects defines output by
- `ASM_OUTPUT_DEF' and `ASM_OUTPUT_DEF_FROM_DECLS'.
-
- -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE)
- A C statement to output to the stdio stream STREAM assembler code
- which defines (equates) the weak symbol NAME to have the value
- VALUE. If VALUE is `NULL', it defines NAME as an undefined weak
- symbol.
-
- Define this macro if the target only supports weak aliases; define
- `ASM_OUTPUT_DEF' instead if possible.
-
- -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME,
- SEL_NAME)
- Define this macro to override the default assembler names used for
- Objective-C methods.
-
- The default name is a unique method number followed by the name of
- the class (e.g. `_1_Foo'). For methods in categories, the name of
- the category is also included in the assembler name (e.g.
- `_1_Foo_Bar').
-
- These names are safe on most systems, but make debugging difficult
- since the method's selector is not present in the name.
- Therefore, particular systems define other ways of computing names.
-
- BUF is an expression of type `char *' which gives you a buffer in
- which to store the name; its length is as long as CLASS_NAME,
- CAT_NAME and SEL_NAME put together, plus 50 characters extra.
-
- The argument IS_INST specifies whether the method is an instance
- method or a class method; CLASS_NAME is the name of the class;
- CAT_NAME is the name of the category (or `NULL' if the method is
- not in a category); and SEL_NAME is the name of the selector.
-
- On systems where the assembler can handle quoted names, you can
- use this macro to provide more human-readable names.
-
- -- Macro: ASM_DECLARE_CLASS_REFERENCE (STREAM, NAME)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM commands to declare that the label NAME is an Objective-C
- class reference. This is only needed for targets whose linkers
- have special support for NeXT-style runtimes.
-
- -- Macro: ASM_DECLARE_UNRESOLVED_REFERENCE (STREAM, NAME)
- A C statement (sans semicolon) to output to the stdio stream
- STREAM commands to declare that the label NAME is an unresolved
- Objective-C class reference. This is only needed for targets
- whose linkers have special support for NeXT-style runtimes.
-
-
-File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format
-
-17.21.5 How Initialization Functions Are Handled
-------------------------------------------------
-
-The compiled code for certain languages includes "constructors" (also
-called "initialization routines")--functions to initialize data in the
-program when the program is started. These functions need to be called
-before the program is "started"--that is to say, before `main' is
-called.
-
- Compiling some languages generates "destructors" (also called
-"termination routines") that should be called when the program
-terminates.
-
- To make the initialization and termination functions work, the compiler
-must output something in the assembler code to cause those functions to
-be called at the appropriate time. When you port the compiler to a new
-system, you need to specify how to do this.
-
- There are two major ways that GCC currently supports the execution of
-initialization and termination functions. Each way has two variants.
-Much of the structure is common to all four variations.
-
- The linker must build two lists of these functions--a list of
-initialization functions, called `__CTOR_LIST__', and a list of
-termination functions, called `__DTOR_LIST__'.
-
- Each list always begins with an ignored function pointer (which may
-hold 0, -1, or a count of the function pointers after it, depending on
-the environment). This is followed by a series of zero or more function
-pointers to constructors (or destructors), followed by a function
-pointer containing zero.
-
- Depending on the operating system and its executable file format,
-either `crtstuff.c' or `libgcc2.c' traverses these lists at startup
-time and exit time. Constructors are called in reverse order of the
-list; destructors in forward order.
-
- The best way to handle static constructors works only for object file
-formats which provide arbitrarily-named sections. A section is set
-aside for a list of constructors, and another for a list of destructors.
-Traditionally these are called `.ctors' and `.dtors'. Each object file
-that defines an initialization function also puts a word in the
-constructor section to point to that function. The linker accumulates
-all these words into one contiguous `.ctors' section. Termination
-functions are handled similarly.
-
- This method will be chosen as the default by `target-def.h' if
-`TARGET_ASM_NAMED_SECTION' is defined. A target that does not support
-arbitrary sections, but does support special designated constructor and
-destructor sections may define `CTORS_SECTION_ASM_OP' and
-`DTORS_SECTION_ASM_OP' to achieve the same effect.
-
- When arbitrary sections are available, there are two variants,
-depending upon how the code in `crtstuff.c' is called. On systems that
-support a ".init" section which is executed at program startup, parts
-of `crtstuff.c' are compiled into that section. The program is linked
-by the `gcc' driver like this:
-
- ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o
-
- The prologue of a function (`__init') appears in the `.init' section
-of `crti.o'; the epilogue appears in `crtn.o'. Likewise for the
-function `__fini' in the ".fini" section. Normally these files are
-provided by the operating system or by the GNU C library, but are
-provided by GCC for a few targets.
-
- The objects `crtbegin.o' and `crtend.o' are (for most targets)
-compiled from `crtstuff.c'. They contain, among other things, code
-fragments within the `.init' and `.fini' sections that branch to
-routines in the `.text' section. The linker will pull all parts of a
-section together, which results in a complete `__init' function that
-invokes the routines we need at startup.
-
- To use this variant, you must define the `INIT_SECTION_ASM_OP' macro
-properly.
-
- If no init section is available, when GCC compiles any function called
-`main' (or more accurately, any function designated as a program entry
-point by the language front end calling `expand_main_function'), it
-inserts a procedure call to `__main' as the first executable code after
-the function prologue. The `__main' function is defined in `libgcc2.c'
-and runs the global constructors.
-
- In file formats that don't support arbitrary sections, there are again
-two variants. In the simplest variant, the GNU linker (GNU `ld') and
-an `a.out' format must be used. In this case, `TARGET_ASM_CONSTRUCTOR'
-is defined to produce a `.stabs' entry of type `N_SETT', referencing
-the name `__CTOR_LIST__', and with the address of the void function
-containing the initialization code as its value. The GNU linker
-recognizes this as a request to add the value to a "set"; the values
-are accumulated, and are eventually placed in the executable as a
-vector in the format described above, with a leading (ignored) count
-and a trailing zero element. `TARGET_ASM_DESTRUCTOR' is handled
-similarly. Since no init section is available, the absence of
-`INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main'
-as above, starting the initialization process.
-
- The last variant uses neither arbitrary sections nor the GNU linker.
-This is preferable when you want to do dynamic linking and when using
-file formats which the GNU linker does not support, such as `ECOFF'. In
-this case, `TARGET_HAVE_CTORS_DTORS' is false, initialization and
-termination functions are recognized simply by their names. This
-requires an extra program in the linkage step, called `collect2'. This
-program pretends to be the linker, for use with GCC; it does its job by
-running the ordinary linker, but also arranges to include the vectors of
-initialization and termination functions. These functions are called
-via `__main' as described above. In order to use this method,
-`use_collect2' must be defined in the target in `config.gcc'.
-
- The following section describes the specific macros that control and
-customize the handling of initialization and termination functions.
-
-
-File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format
-
-17.21.6 Macros Controlling Initialization Routines
---------------------------------------------------
-
-Here are the macros that control how the compiler handles initialization
-and termination functions:
-
- -- Macro: INIT_SECTION_ASM_OP
- If defined, a C string constant, including spacing, for the
- assembler operation to identify the following data as
- initialization code. If not defined, GCC will assume such a
- section does not exist. When you are using special sections for
- initialization and termination functions, this macro also controls
- how `crtstuff.c' and `libgcc2.c' arrange to run the initialization
- functions.
-
- -- Macro: HAS_INIT_SECTION
- If defined, `main' will not call `__main' as described above.
- This macro should be defined for systems that control start-up code
- on a symbol-by-symbol basis, such as OSF/1, and should not be
- defined explicitly for systems that support `INIT_SECTION_ASM_OP'.
-
- -- Macro: LD_INIT_SWITCH
- If defined, a C string constant for a switch that tells the linker
- that the following symbol is an initialization routine.
-
- -- Macro: LD_FINI_SWITCH
- If defined, a C string constant for a switch that tells the linker
- that the following symbol is a finalization routine.
-
- -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC)
- If defined, a C statement that will write a function that can be
- automatically called when a shared library is loaded. The function
- should call FUNC, which takes no arguments. If not defined, and
- the object format requires an explicit initialization function,
- then a function called `_GLOBAL__DI' will be generated.
-
- This function and the following one are used by collect2 when
- linking a shared library that needs constructors or destructors,
- or has DWARF2 exception tables embedded in the code.
-
- -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC)
- If defined, a C statement that will write a function that can be
- automatically called when a shared library is unloaded. The
- function should call FUNC, which takes no arguments. If not
- defined, and the object format requires an explicit finalization
- function, then a function called `_GLOBAL__DD' will be generated.
-
- -- Macro: INVOKE__main
- If defined, `main' will call `__main' despite the presence of
- `INIT_SECTION_ASM_OP'. This macro should be defined for systems
- where the init section is not actually run automatically, but is
- still useful for collecting the lists of constructors and
- destructors.
-
- -- Macro: SUPPORTS_INIT_PRIORITY
- If nonzero, the C++ `init_priority' attribute is supported and the
- compiler should emit instructions to control the order of
- initialization of objects. If zero, the compiler will issue an
- error message upon encountering an `init_priority' attribute.
-
- -- Target Hook: bool TARGET_HAVE_CTORS_DTORS
- This value is true if the target supports some "native" method of
- collecting constructors and destructors to be run at startup and
- exit. It is false if we must use `collect2'.
-
- -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY)
- If defined, a function that outputs assembler code to arrange to
- call the function referenced by SYMBOL at initialization time.
-
- Assume that SYMBOL is a `SYMBOL_REF' for a function taking no
- arguments and with no return value. If the target supports
- initialization priorities, PRIORITY is a value between 0 and
- `MAX_INIT_PRIORITY'; otherwise it must be `DEFAULT_INIT_PRIORITY'.
-
- If this macro is not defined by the target, a suitable default will
- be chosen if (1) the target supports arbitrary section names, (2)
- the target defines `CTORS_SECTION_ASM_OP', or (3) `USE_COLLECT2'
- is not defined.
-
- -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY)
- This is like `TARGET_ASM_CONSTRUCTOR' but used for termination
- functions rather than initialization functions.
-
- If `TARGET_HAVE_CTORS_DTORS' is true, the initialization routine
-generated for the generated object file will have static linkage.
-
- If your system uses `collect2' as the means of processing
-constructors, then that program normally uses `nm' to scan an object
-file for constructor functions to be called.
-
- On certain kinds of systems, you can define this macro to make
-`collect2' work faster (and, in some cases, make it work at all):
-
- -- Macro: OBJECT_FORMAT_COFF
- Define this macro if the system uses COFF (Common Object File
- Format) object files, so that `collect2' can assume this format
- and scan object files directly for dynamic constructor/destructor
- functions.
-
- This macro is effective only in a native compiler; `collect2' as
- part of a cross compiler always uses `nm' for the target machine.
-
- -- Macro: REAL_NM_FILE_NAME
- Define this macro as a C string constant containing the file name
- to use to execute `nm'. The default is to search the path
- normally for `nm'.
-
- -- Macro: NM_FLAGS
- `collect2' calls `nm' to scan object files for static constructors
- and destructors and LTO info. By default, `-n' is passed. Define
- `NM_FLAGS' to a C string constant if other options are needed to
- get the same output format as GNU `nm -n' produces.
-
- If your system supports shared libraries and has a program to list the
-dynamic dependencies of a given library or executable, you can define
-these macros to enable support for running initialization and
-termination functions in shared libraries:
-
- -- Macro: LDD_SUFFIX
- Define this macro to a C string constant containing the name of
- the program which lists dynamic dependencies, like `ldd' under
- SunOS 4.
-
- -- Macro: PARSE_LDD_OUTPUT (PTR)
- Define this macro to be C code that extracts filenames from the
- output of the program denoted by `LDD_SUFFIX'. PTR is a variable
- of type `char *' that points to the beginning of a line of output
- from `LDD_SUFFIX'. If the line lists a dynamic dependency, the
- code must advance PTR to the beginning of the filename on that
- line. Otherwise, it must set PTR to `NULL'.
-
- -- Macro: SHLIB_SUFFIX
- Define this macro to a C string constant containing the default
- shared library extension of the target (e.g., `".so"'). `collect2'
- strips version information after this suffix when generating global
- constructor and destructor names. This define is only needed on
- targets that use `collect2' to process constructors and
- destructors.
-
-
-File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format
-
-17.21.7 Output of Assembler Instructions
-----------------------------------------
-
-This describes assembler instruction output.
-
- -- Macro: REGISTER_NAMES
- A C initializer containing the assembler's names for the machine
- registers, each one as a C string constant. This is what
- translates register numbers in the compiler into assembler
- language.
-
- -- Macro: ADDITIONAL_REGISTER_NAMES
- If defined, a C initializer for an array of structures containing
- a name and a register number. This macro defines additional names
- for hard registers, thus allowing the `asm' option in declarations
- to refer to registers using alternate names.
-
- -- Macro: OVERLAPPING_REGISTER_NAMES
- If defined, a C initializer for an array of structures containing a
- name, a register number and a count of the number of consecutive
- machine registers the name overlaps. This macro defines additional
- names for hard registers, thus allowing the `asm' option in
- declarations to refer to registers using alternate names. Unlike
- `ADDITIONAL_REGISTER_NAMES', this macro should be used when the
- register name implies multiple underlying registers.
-
- This macro should be used when it is important that a clobber in an
- `asm' statement clobbers all the underlying values implied by the
- register name. For example, on ARM, clobbering the
- double-precision VFP register "d0" implies clobbering both
- single-precision registers "s0" and "s1".
-
- -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR)
- Define this macro if you are using an unusual assembler that
- requires different names for the machine instructions.
-
- The definition is a C statement or statements which output an
- assembler instruction opcode to the stdio stream STREAM. The
- macro-operand PTR is a variable of type `char *' which points to
- the opcode name in its "internal" form--the form that is written
- in the machine description. The definition should output the
- opcode name to STREAM, performing any translation you desire, and
- increment the variable PTR to point at the end of the opcode so
- that it will not be output twice.
-
- In fact, your macro definition may process less than the entire
- opcode name, or more than the opcode name; but if you want to
- process text that includes `%'-sequences to substitute operands,
- you must take care of the substitution yourself. Just be sure to
- increment PTR over whatever text should not be output normally.
-
- If you need to look at the operand values, they can be found as the
- elements of `recog_data.operand'.
-
- If the macro definition does nothing, the instruction is output in
- the usual way.
-
- -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS)
- If defined, a C statement to be executed just prior to the output
- of assembler code for INSN, to modify the extracted operands so
- they will be output differently.
-
- Here the argument OPVEC is the vector containing the operands
- extracted from INSN, and NOPERANDS is the number of elements of
- the vector which contain meaningful data for this insn. The
- contents of this vector are what will be used to convert the insn
- template into assembler code, so you can change the assembler
- output by changing the contents of the vector.
-
- This macro is useful when various assembler syntaxes share a single
- file of instruction patterns; by defining this macro differently,
- you can cause a large class of instructions to be output
- differently (such as with rearranged operands). Naturally,
- variations in assembler syntax affecting individual insn patterns
- ought to be handled by writing conditional output routines in
- those patterns.
-
- If this macro is not defined, it is equivalent to a null statement.
-
- -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, rtx
- INSN, rtx *OPVEC, int NOPERANDS)
- If defined, this target hook is a function which is executed just
- after the output of assembler code for INSN, to change the mode of
- the assembler if necessary.
-
- Here the argument OPVEC is the vector containing the operands
- extracted from INSN, and NOPERANDS is the number of elements of
- the vector which contain meaningful data for this insn. The
- contents of this vector are what was used to convert the insn
- template into assembler code, so you can change the assembler mode
- by checking the contents of the vector.
-
- -- Macro: PRINT_OPERAND (STREAM, X, CODE)
- A C compound statement to output to stdio stream STREAM the
- assembler syntax for an instruction operand X. X is an RTL
- expression.
-
- CODE is a value that can be used to specify one of several ways of
- printing the operand. It is used when identical operands must be
- printed differently depending on the context. CODE comes from the
- `%' specification that was used to request printing of the
- operand. If the specification was just `%DIGIT' then CODE is 0;
- if the specification was `%LTR DIGIT' then CODE is the ASCII code
- for LTR.
-
- If X is a register, this macro should print the register's name.
- The names can be found in an array `reg_names' whose type is `char
- *[]'. `reg_names' is initialized from `REGISTER_NAMES'.
-
- When the machine description has a specification `%PUNCT' (a `%'
- followed by a punctuation character), this macro is called with a
- null pointer for X and the punctuation character for CODE.
-
- -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE)
- A C expression which evaluates to true if CODE is a valid
- punctuation character for use in the `PRINT_OPERAND' macro. If
- `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no
- punctuation characters (except for the standard one, `%') are used
- in this way.
-
- -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X)
- A C compound statement to output to stdio stream STREAM the
- assembler syntax for an instruction operand that is a memory
- reference whose address is X. X is an RTL expression.
-
- On some machines, the syntax for a symbolic address depends on the
- section that the address refers to. On these machines, define the
- hook `TARGET_ENCODE_SECTION_INFO' to store the information into the
- `symbol_ref', and then check for it here. *Note Assembler
- Format::.
-
- -- Macro: DBR_OUTPUT_SEQEND (FILE)
- A C statement, to be executed after all slot-filler instructions
- have been output. If necessary, call `dbr_sequence_length' to
- determine the number of slots filled in a sequence (zero if not
- currently outputting a sequence), to decide how many no-ops to
- output, or whatever.
-
- Don't define this macro if it has nothing to do, but it is helpful
- in reading assembly output if the extent of the delay sequence is
- made explicit (e.g. with white space).
-
- Note that output routines for instructions with delay slots must be
-prepared to deal with not being output as part of a sequence (i.e. when
-the scheduling pass is not run, or when no slot fillers could be
-found.) The variable `final_sequence' is null when not processing a
-sequence, otherwise it contains the `sequence' rtx being output.
-
- -- Macro: REGISTER_PREFIX
- -- Macro: LOCAL_LABEL_PREFIX
- -- Macro: USER_LABEL_PREFIX
- -- Macro: IMMEDIATE_PREFIX
- If defined, C string expressions to be used for the `%R', `%L',
- `%U', and `%I' options of `asm_fprintf' (see `final.c'). These
- are useful when a single `md' file must support multiple assembler
- formats. In that case, the various `tm.h' files can define these
- macros differently.
-
- -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT)
- If defined this macro should expand to a series of `case'
- statements which will be parsed inside the `switch' statement of
- the `asm_fprintf' function. This allows targets to define extra
- printf formats which may useful when generating their assembler
- statements. Note that uppercase letters are reserved for future
- generic extensions to asm_fprintf, and so are not available to
- target specific code. The output file is given by the parameter
- FILE. The varargs input pointer is ARGPTR and the rest of the
- format string, starting the character after the one that is being
- switched upon, is pointed to by FORMAT.
-
- -- Macro: ASSEMBLER_DIALECT
- If your target supports multiple dialects of assembler language
- (such as different opcodes), define this macro as a C expression
- that gives the numeric index of the assembler language dialect to
- use, with zero as the first variant.
-
- If this macro is defined, you may use constructs of the form
- `{option0|option1|option2...}'
- in the output templates of patterns (*note Output Template::) or
- in the first argument of `asm_fprintf'. This construct outputs
- `option0', `option1', `option2', etc., if the value of
- `ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters
- within these strings retain their usual meaning. If there are
- fewer alternatives within the braces than the value of
- `ASSEMBLER_DIALECT', the construct outputs nothing.
-
- If you do not define this macro, the characters `{', `|' and `}'
- do not have any special meaning when used in templates or operands
- to `asm_fprintf'.
-
- Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX',
- `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the
- variations in assembler language syntax with that mechanism.
- Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax
- if the syntax variant are larger and involve such things as
- different opcodes or operand order.
-
- -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO)
- A C expression to output to STREAM some assembler code which will
- push hard register number REGNO onto the stack. The code need not
- be optimal, since this macro is used only when profiling.
-
- -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO)
- A C expression to output to STREAM some assembler code which will
- pop hard register number REGNO off of the stack. The code need
- not be optimal, since this macro is used only when profiling.
-
-
-File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format
-
-17.21.8 Output of Dispatch Tables
----------------------------------
-
-This concerns dispatch tables.
-
- -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL)
- A C statement to output to the stdio stream STREAM an assembler
- pseudo-instruction to generate a difference between two labels.
- VALUE and REL are the numbers of two internal labels. The
- definitions of these labels are output using
- `(*targetm.asm_out.internal_label)', and they must be printed in
- the same way here. For example,
-
- fprintf (STREAM, "\t.word L%d-L%d\n",
- VALUE, REL)
-
- You must provide this macro on machines where the addresses in a
- dispatch table are relative to the table's own address. If
- defined, GCC will also use this macro on all machines when
- producing PIC. BODY is the body of the `ADDR_DIFF_VEC'; it is
- provided so that the mode and flags can be read.
-
- -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)
- This macro should be provided on machines where the addresses in a
- dispatch table are absolute.
-
- The definition should be a C statement to output to the stdio
- stream STREAM an assembler pseudo-instruction to generate a
- reference to a label. VALUE is the number of an internal label
- whose definition is output using
- `(*targetm.asm_out.internal_label)'. For example,
-
- fprintf (STREAM, "\t.word L%d\n", VALUE)
-
- -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)
- Define this if the label before a jump-table needs to be output
- specially. The first three arguments are the same as for
- `(*targetm.asm_out.internal_label)'; the fourth argument is the
- jump-table which follows (a `jump_insn' containing an `addr_vec'
- or `addr_diff_vec').
-
- This feature is used on system V to output a `swbeg' statement for
- the table.
-
- If this macro is not defined, these labels are output with
- `(*targetm.asm_out.internal_label)'.
-
- -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)
- Define this if something special must be output at the end of a
- jump-table. The definition should be a C statement to be executed
- after the assembler code for the table is written. It should write
- the appropriate code to stdio stream STREAM. The argument TABLE
- is the jump-table insn, and NUM is the label-number of the
- preceding label.
-
- If this macro is not defined, nothing special is output at the end
- of the jump-table.
-
- -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree
- DECL, int FOR_EH, int EMPTY)
- This target hook emits a label at the beginning of each FDE. It
- should be defined on targets where FDEs need special labels, and it
- should write the appropriate label, for the FDE associated with the
- function declaration DECL, to the stdio stream STREAM. The third
- argument, FOR_EH, is a boolean: true if this is for an exception
- table. The fourth argument, EMPTY, is a boolean: true if this is
- a placeholder label for an omitted FDE.
-
- The default is that FDEs are not given nonlocal labels.
-
- -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM)
- This target hook emits a label at the beginning of the exception
- table. It should be defined on targets where it is desirable for
- the table to be broken up according to function.
-
- The default is that no label is emitted.
-
- -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx
- PERSONALITY)
- If the target implements `TARGET_ASM_UNWIND_EMIT', this hook may
- be used to emit a directive to install a personality hook into the
- unwind info. This hook should not be used if dwarf2 unwind info
- is used.
-
- -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx INSN)
- This target hook emits assembly directives required to unwind the
- given instruction. This is only used when
- `TARGET_EXCEPT_UNWIND_INFO' returns `UI_TARGET'.
-
- -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN
- True if the `TARGET_ASM_UNWIND_EMIT' hook should be called before
- the assembly for INSN has been emitted, false if the hook should
- be called afterward.
-
-
-File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format
-
-17.21.9 Assembler Commands for Exception Regions
-------------------------------------------------
-
-This describes commands marking the start and the end of an exception
-region.
-
- -- Macro: EH_FRAME_SECTION_NAME
- If defined, a C string constant for the name of the section
- containing exception handling frame unwind information. If not
- defined, GCC will provide a default definition if the target
- supports named sections. `crtstuff.c' uses this macro to switch
- to the appropriate section.
-
- You should define this symbol if your target supports DWARF 2 frame
- unwind information and the default definition does not work.
-
- -- Macro: EH_FRAME_IN_DATA_SECTION
- If defined, DWARF 2 frame unwind information will be placed in the
- data section even though the target supports named sections. This
- might be necessary, for instance, if the system linker does garbage
- collection and sections cannot be marked as not to be collected.
-
- Do not define this macro unless `TARGET_ASM_NAMED_SECTION' is also
- defined.
-
- -- Macro: EH_TABLES_CAN_BE_READ_ONLY
- Define this macro to 1 if your target is such that no frame unwind
- information encoding used with non-PIC code will ever require a
- runtime relocation, but the linker may not support merging
- read-only and read-write sections into a single read-write section.
-
- -- Macro: MASK_RETURN_ADDR
- An rtx used to mask the return address found via
- `RETURN_ADDR_RTX', so that it does not contain any extraneous set
- bits in it.
-
- -- Macro: DWARF2_UNWIND_INFO
- Define this macro to 0 if your target supports DWARF 2 frame unwind
- information, but it does not yet work with exception handling.
- Otherwise, if your target supports this information (if it defines
- `INCOMING_RETURN_ADDR_RTX' and either `UNALIGNED_INT_ASM_OP' or
- `OBJECT_FORMAT_ELF'), GCC will provide a default definition of 1.
-
- -- Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO
- (struct gcc_options *OPTS)
- This hook defines the mechanism that will be used for exception
- handling by the target. If the target has ABI specified unwind
- tables, the hook should return `UI_TARGET'. If the target is to
- use the `setjmp'/`longjmp'-based exception handling scheme, the
- hook should return `UI_SJLJ'. If the target supports DWARF 2
- frame unwind information, the hook should return `UI_DWARF2'.
-
- A target may, if exceptions are disabled, choose to return
- `UI_NONE'. This may end up simplifying other parts of
- target-specific code. The default implementation of this hook
- never returns `UI_NONE'.
-
- Note that the value returned by this hook should be constant. It
- should not depend on anything except the command-line switches
- described by OPTS. In particular, the setting `UI_SJLJ' must be
- fixed at compiler start-up as C pre-processor macros and builtin
- functions related to exception handling are set up depending on
- this setting.
-
- The default implementation of the hook first honors the
- `--enable-sjlj-exceptions' configure option, then
- `DWARF2_UNWIND_INFO', and finally defaults to `UI_SJLJ'. If
- `DWARF2_UNWIND_INFO' depends on command-line options, the target
- must define this hook so that OPTS is used correctly.
-
- -- Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT
- This variable should be set to `true' if the target ABI requires
- unwinding tables even when exceptions are not used. It must not
- be modified by command-line option processing.
-
- -- Macro: DONT_USE_BUILTIN_SETJMP
- Define this macro to 1 if the `setjmp'/`longjmp'-based scheme
- should use the `setjmp'/`longjmp' functions from the C library
- instead of the `__builtin_setjmp'/`__builtin_longjmp' machinery.
-
- -- Macro: DWARF_CIE_DATA_ALIGNMENT
- This macro need only be defined if the target might save registers
- in the function prologue at an offset to the stack pointer that is
- not aligned to `UNITS_PER_WORD'. The definition should be the
- negative minimum alignment if `STACK_GROWS_DOWNWARD' is defined,
- and the positive minimum alignment otherwise. *Note SDB and
- DWARF::. Only applicable if the target supports DWARF 2 frame
- unwind information.
-
- -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO
- Contains the value true if the target should add a zero word onto
- the end of a Dwarf-2 frame info section when used for exception
- handling. Default value is false if `EH_FRAME_SECTION_NAME' is
- defined, and true otherwise.
-
- -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG)
- Given a register, this hook should return a parallel of registers
- to represent where to find the register pieces. Define this hook
- if the register and its mode are represented in Dwarf in
- non-contiguous locations, or if the register should be represented
- in more than one register in Dwarf. Otherwise, this hook should
- return `NULL_RTX'. If not defined, the default is to return
- `NULL_RTX'.
-
- -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS)
- If some registers are represented in Dwarf-2 unwind information in
- multiple pieces, define this hook to fill in information about the
- sizes of those pieces in the table used by the unwinder at runtime.
- It will be called by `expand_builtin_init_dwarf_reg_sizes' after
- filling in a single size corresponding to each hard register;
- ADDRESS is the address of the table.
-
- -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM)
- This hook is used to output a reference from a frame unwinding
- table to the type_info object identified by SYM. It should return
- `true' if the reference was output. Returning `false' will cause
- the reference to be output using the normal Dwarf2 routines.
-
- -- Target Hook: bool TARGET_ARM_EABI_UNWINDER
- This flag should be set to `true' on targets that use an ARM EABI
- based unwinding library, and `false' on other targets. This
- effects the format of unwinding tables, and how the unwinder in
- entered after running a cleanup. The default is `false'.
-
-
-File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format
-
-17.21.10 Assembler Commands for Alignment
------------------------------------------
-
-This describes commands for alignment.
-
- -- Macro: JUMP_ALIGN (LABEL)
- The alignment (log base 2) to put in front of LABEL, which is a
- common destination of jumps and has no fallthru incoming edge.
-
- This macro need not be defined if you don't want any special
- alignment to be done at such a time. Most machine descriptions do
- not currently define the macro.
-
- Unless it's necessary to inspect the LABEL parameter, it is better
- to set the variable ALIGN_JUMPS in the target's
- `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the
- user's selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation.
-
- -- Target Hook: int TARGET_ASM_JUMP_ALIGN_MAX_SKIP (rtx LABEL)
- The maximum number of bytes to skip before LABEL when applying
- `JUMP_ALIGN'. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is
- defined.
-
- -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL)
- The alignment (log base 2) to put in front of LABEL, which follows
- a `BARRIER'.
-
- This macro need not be defined if you don't want any special
- alignment to be done at such a time. Most machine descriptions do
- not currently define the macro.
-
- -- Target Hook: int TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP (rtx
- LABEL)
- The maximum number of bytes to skip before LABEL when applying
- `LABEL_ALIGN_AFTER_BARRIER'. This works only if
- `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
-
- -- Macro: LOOP_ALIGN (LABEL)
- The alignment (log base 2) to put in front of LABEL, which follows
- a `NOTE_INSN_LOOP_BEG' note.
-
- This macro need not be defined if you don't want any special
- alignment to be done at such a time. Most machine descriptions do
- not currently define the macro.
-
- Unless it's necessary to inspect the LABEL parameter, it is better
- to set the variable `align_loops' in the target's
- `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the
- user's selection in `align_loops' in a `LOOP_ALIGN' implementation.
-
- -- Target Hook: int TARGET_ASM_LOOP_ALIGN_MAX_SKIP (rtx LABEL)
- The maximum number of bytes to skip when applying `LOOP_ALIGN' to
- LABEL. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
-
- -- Macro: LABEL_ALIGN (LABEL)
- The alignment (log base 2) to put in front of LABEL. If
- `LABEL_ALIGN_AFTER_BARRIER' / `LOOP_ALIGN' specify a different
- alignment, the maximum of the specified values is used.
-
- Unless it's necessary to inspect the LABEL parameter, it is better
- to set the variable `align_labels' in the target's
- `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the
- user's selection in `align_labels' in a `LABEL_ALIGN'
- implementation.
-
- -- Target Hook: int TARGET_ASM_LABEL_ALIGN_MAX_SKIP (rtx LABEL)
- The maximum number of bytes to skip when applying `LABEL_ALIGN' to
- LABEL. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
-
- -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES)
- A C statement to output to the stdio stream STREAM an assembler
- instruction to advance the location counter by NBYTES bytes.
- Those bytes should be zero when loaded. NBYTES will be a C
- expression of type `unsigned HOST_WIDE_INT'.
-
- -- Macro: ASM_NO_SKIP_IN_TEXT
- Define this macro if `ASM_OUTPUT_SKIP' should not be used in the
- text section because it fails to put zeros in the bytes that are
- skipped. This is true on many Unix systems, where the pseudo-op
- to skip bytes produces no-op instructions rather than zeros when
- used in the text section.
-
- -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER)
- A C statement to output to the stdio stream STREAM an assembler
- command to advance the location counter to a multiple of 2 to the
- POWER bytes. POWER will be a C expression of type `int'.
-
- -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER)
- Like `ASM_OUTPUT_ALIGN', except that the "nop" instruction is used
- for padding, if necessary.
-
- -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP)
- A C statement to output to the stdio stream STREAM an assembler
- command to advance the location counter to a multiple of 2 to the
- POWER bytes, but only if MAX_SKIP or fewer bytes are needed to
- satisfy the alignment request. POWER and MAX_SKIP will be a C
- expression of type `int'.
-
-
-File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros
-
-17.22 Controlling Debugging Information Format
-==============================================
-
-This describes how to specify debugging information.
-
-* Menu:
-
-* All Debuggers:: Macros that affect all debugging formats uniformly.
-* DBX Options:: Macros enabling specific options in DBX format.
-* DBX Hooks:: Hook macros for varying DBX format.
-* File Names and DBX:: Macros controlling output of file names in DBX format.
-* SDB and DWARF:: Macros for SDB (COFF) and DWARF formats.
-* VMS Debug:: Macros for VMS debug format.
-
-
-File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info
-
-17.22.1 Macros Affecting All Debugging Formats
-----------------------------------------------
-
-These macros affect all debugging formats.
-
- -- Macro: DBX_REGISTER_NUMBER (REGNO)
- A C expression that returns the DBX register number for the
- compiler register number REGNO. In the default macro provided,
- the value of this expression will be REGNO itself. But sometimes
- there are some registers that the compiler knows about and DBX
- does not, or vice versa. In such cases, some register may need to
- have one number in the compiler and another for DBX.
-
- If two registers have consecutive numbers inside GCC, and they can
- be used as a pair to hold a multiword value, then they _must_ have
- consecutive numbers after renumbering with `DBX_REGISTER_NUMBER'.
- Otherwise, debuggers will be unable to access such a pair, because
- they expect register pairs to be consecutive in their own
- numbering scheme.
-
- If you find yourself defining `DBX_REGISTER_NUMBER' in way that
- does not preserve register pairs, then what you must do instead is
- redefine the actual register numbering scheme.
-
- -- Macro: DEBUGGER_AUTO_OFFSET (X)
- A C expression that returns the integer offset value for an
- automatic variable having address X (an RTL expression). The
- default computation assumes that X is based on the frame-pointer
- and gives the offset from the frame-pointer. This is required for
- targets that produce debugging output for DBX or COFF-style
- debugging output for SDB and allow the frame-pointer to be
- eliminated when the `-g' options is used.
-
- -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X)
- A C expression that returns the integer offset value for an
- argument having address X (an RTL expression). The nominal offset
- is OFFSET.
-
- -- Macro: PREFERRED_DEBUGGING_TYPE
- A C expression that returns the type of debugging output GCC should
- produce when the user specifies just `-g'. Define this if you
- have arranged for GCC to support more than one format of debugging
- output. Currently, the allowable values are `DBX_DEBUG',
- `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', `XCOFF_DEBUG',
- `VMS_DEBUG', and `VMS_AND_DWARF2_DEBUG'.
-
- When the user specifies `-ggdb', GCC normally also uses the value
- of this macro to select the debugging output format, but with two
- exceptions. If `DWARF2_DEBUGGING_INFO' is defined, GCC uses the
- value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is
- defined, GCC uses `DBX_DEBUG'.
-
- The value of this macro only affects the default debugging output;
- the user can always get a specific type of output by using
- `-gstabs', `-gcoff', `-gdwarf-2', `-gxcoff', or `-gvms'.
-
-
-File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info
-
-17.22.2 Specific Options for DBX Output
----------------------------------------
-
-These are specific options for DBX output.
-
- -- Macro: DBX_DEBUGGING_INFO
- Define this macro if GCC should produce debugging output for DBX
- in response to the `-g' option.
-
- -- Macro: XCOFF_DEBUGGING_INFO
- Define this macro if GCC should produce XCOFF format debugging
- output in response to the `-g' option. This is a variant of DBX
- format.
-
- -- Macro: DEFAULT_GDB_EXTENSIONS
- Define this macro to control whether GCC should by default generate
- GDB's extended version of DBX debugging information (assuming
- DBX-format debugging information is enabled at all). If you don't
- define the macro, the default is 1: always generate the extended
- information if there is any occasion to.
-
- -- Macro: DEBUG_SYMS_TEXT
- Define this macro if all `.stabs' commands should be output while
- in the text section.
-
- -- Macro: ASM_STABS_OP
- A C string constant, including spacing, naming the assembler
- pseudo op to use instead of `"\t.stabs\t"' to define an ordinary
- debugging symbol. If you don't define this macro, `"\t.stabs\t"'
- is used. This macro applies only to DBX debugging information
- format.
-
- -- Macro: ASM_STABD_OP
- A C string constant, including spacing, naming the assembler
- pseudo op to use instead of `"\t.stabd\t"' to define a debugging
- symbol whose value is the current location. If you don't define
- this macro, `"\t.stabd\t"' is used. This macro applies only to
- DBX debugging information format.
-
- -- Macro: ASM_STABN_OP
- A C string constant, including spacing, naming the assembler
- pseudo op to use instead of `"\t.stabn\t"' to define a debugging
- symbol with no name. If you don't define this macro,
- `"\t.stabn\t"' is used. This macro applies only to DBX debugging
- information format.
-
- -- Macro: DBX_NO_XREFS
- Define this macro if DBX on your system does not support the
- construct `xsTAGNAME'. On some systems, this construct is used to
- describe a forward reference to a structure named TAGNAME. On
- other systems, this construct is not supported at all.
-
- -- Macro: DBX_CONTIN_LENGTH
- A symbol name in DBX-format debugging information is normally
- continued (split into two separate `.stabs' directives) when it
- exceeds a certain length (by default, 80 characters). On some
- operating systems, DBX requires this splitting; on others,
- splitting must not be done. You can inhibit splitting by defining
- this macro with the value zero. You can override the default
- splitting-length by defining this macro as an expression for the
- length you desire.
-
- -- Macro: DBX_CONTIN_CHAR
- Normally continuation is indicated by adding a `\' character to
- the end of a `.stabs' string when a continuation follows. To use
- a different character instead, define this macro as a character
- constant for the character you want to use. Do not define this
- macro if backslash is correct for your system.
-
- -- Macro: DBX_STATIC_STAB_DATA_SECTION
- Define this macro if it is necessary to go to the data section
- before outputting the `.stabs' pseudo-op for a non-global static
- variable.
-
- -- Macro: DBX_TYPE_DECL_STABS_CODE
- The value to use in the "code" field of the `.stabs' directive for
- a typedef. The default is `N_LSYM'.
-
- -- Macro: DBX_STATIC_CONST_VAR_CODE
- The value to use in the "code" field of the `.stabs' directive for
- a static variable located in the text section. DBX format does not
- provide any "right" way to do this. The default is `N_FUN'.
-
- -- Macro: DBX_REGPARM_STABS_CODE
- The value to use in the "code" field of the `.stabs' directive for
- a parameter passed in registers. DBX format does not provide any
- "right" way to do this. The default is `N_RSYM'.
-
- -- Macro: DBX_REGPARM_STABS_LETTER
- The letter to use in DBX symbol data to identify a symbol as a
- parameter passed in registers. DBX format does not customarily
- provide any way to do this. The default is `'P''.
-
- -- Macro: DBX_FUNCTION_FIRST
- Define this macro if the DBX information for a function and its
- arguments should precede the assembler code for the function.
- Normally, in DBX format, the debugging information entirely
- follows the assembler code.
-
- -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE
- Define this macro, with value 1, if the value of a symbol
- describing the scope of a block (`N_LBRAC' or `N_RBRAC') should be
- relative to the start of the enclosing function. Normally, GCC
- uses an absolute address.
-
- -- Macro: DBX_LINES_FUNCTION_RELATIVE
- Define this macro, with value 1, if the value of a symbol
- indicating the current line number (`N_SLINE') should be relative
- to the start of the enclosing function. Normally, GCC uses an
- absolute address.
-
- -- Macro: DBX_USE_BINCL
- Define this macro if GCC should generate `N_BINCL' and `N_EINCL'
- stabs for included header files, as on Sun systems. This macro
- also directs GCC to output a type number as a pair of a file
- number and a type number within the file. Normally, GCC does not
- generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single
- number for a type number.
-
-
-File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info
-
-17.22.3 Open-Ended Hooks for DBX Format
----------------------------------------
-
-These are hooks for DBX format.
-
- -- Macro: DBX_OUTPUT_LBRAC (STREAM, NAME)
- Define this macro to say how to output to STREAM the debugging
- information for the start of a scope level for variable names. The
- argument NAME is the name of an assembler symbol (for use with
- `assemble_name') whose value is the address where the scope begins.
-
- -- Macro: DBX_OUTPUT_RBRAC (STREAM, NAME)
- Like `DBX_OUTPUT_LBRAC', but for the end of a scope level.
-
- -- Macro: DBX_OUTPUT_NFUN (STREAM, LSCOPE_LABEL, DECL)
- Define this macro if the target machine requires special handling
- to output an `N_FUN' entry for the function DECL.
-
- -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER)
- A C statement to output DBX debugging information before code for
- line number LINE of the current source file to the stdio stream
- STREAM. COUNTER is the number of time the macro was invoked,
- including the current invocation; it is intended to generate
- unique labels in the assembly output.
-
- This macro should not be defined if the default output is correct,
- or if it can be made correct by defining
- `DBX_LINES_FUNCTION_RELATIVE'.
-
- -- Macro: NO_DBX_FUNCTION_END
- Some stabs encapsulation formats (in particular ECOFF), cannot
- handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx
- extension construct. On those machines, define this macro to turn
- this feature off without disturbing the rest of the gdb extensions.
-
- -- Macro: NO_DBX_BNSYM_ENSYM
- Some assemblers cannot handle the `.stabd BNSYM/ENSYM,0,0' gdb dbx
- extension construct. On those machines, define this macro to turn
- this feature off without disturbing the rest of the gdb extensions.
-
-
-File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info
-
-17.22.4 File Names in DBX Format
---------------------------------
-
-This describes file names in DBX format.
-
- -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME)
- A C statement to output DBX debugging information to the stdio
- stream STREAM, which indicates that file NAME is the main source
- file--the file specified as the input file for compilation. This
- macro is called only once, at the beginning of compilation.
-
- This macro need not be defined if the standard form of output for
- DBX debugging information is appropriate.
-
- It may be necessary to refer to a label equal to the beginning of
- the text section. You can use `assemble_name (stream,
- ltext_label_name)' to do so. If you do this, you must also set
- the variable USED_LTEXT_LABEL_NAME to `true'.
-
- -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY
- Define this macro, with value 1, if GCC should not emit an
- indication of the current directory for compilation and current
- source language at the beginning of the file.
-
- -- Macro: NO_DBX_GCC_MARKER
- Define this macro, with value 1, if GCC should not emit an
- indication that this object file was compiled by GCC. The default
- is to emit an `N_OPT' stab at the beginning of every source file,
- with `gcc2_compiled.' for the string and value 0.
-
- -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME)
- A C statement to output DBX debugging information at the end of
- compilation of the main source file NAME. Output should be
- written to the stdio stream STREAM.
-
- If you don't define this macro, nothing special is output at the
- end of compilation, which is correct for most machines.
-
- -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END
- Define this macro _instead of_ defining
- `DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at
- the end of compilation is an `N_SO' stab with an empty string,
- whose value is the highest absolute text address in the file.
-
-
-File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info
-
-17.22.5 Macros for SDB and DWARF Output
----------------------------------------
-
-Here are macros for SDB and DWARF output.
-
- -- Macro: SDB_DEBUGGING_INFO
- Define this macro if GCC should produce COFF-style debugging output
- for SDB in response to the `-g' option.
-
- -- Macro: DWARF2_DEBUGGING_INFO
- Define this macro if GCC should produce dwarf version 2 format
- debugging output in response to the `-g' option.
-
- -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree
- FUNCTION)
- Define this to enable the dwarf attribute
- `DW_AT_calling_convention' to be emitted for each function.
- Instead of an integer return the enum value for the `DW_CC_'
- tag.
-
- To support optional call frame debugging information, you must also
- define `INCOMING_RETURN_ADDR_RTX' and either set
- `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the
- prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as
- appropriate from `TARGET_ASM_FUNCTION_PROLOGUE' if you don't.
-
- -- Macro: DWARF2_FRAME_INFO
- Define this macro to a nonzero value if GCC should always output
- Dwarf 2 frame information. If `TARGET_EXCEPT_UNWIND_INFO' (*note
- Exception Region Output::) returns `UI_DWARF2', and exceptions are
- enabled, GCC will output this information not matter how you
- define `DWARF2_FRAME_INFO'.
-
- -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void)
- This hook defines the mechanism that will be used for describing
- frame unwind information to the debugger. Normally the hook will
- return `UI_DWARF2' if DWARF 2 debug information is enabled, and
- return `UI_NONE' otherwise.
-
- A target may return `UI_DWARF2' even when DWARF 2 debug information
- is disabled in order to always output DWARF 2 frame information.
-
- A target may return `UI_TARGET' if it has ABI specified unwind
- tables. This will suppress generation of the normal debug frame
- unwind information.
-
- -- Macro: DWARF2_ASM_LINE_DEBUG_INFO
- Define this macro to be a nonzero value if the assembler can
- generate Dwarf 2 line debug info sections. This will result in
- much more compact line number tables, and hence is desirable if it
- works.
-
- -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS
- True if the `.debug_pubtypes' and `.debug_pubnames' sections
- should be emitted. These sections are not used on most platforms,
- and in particular GDB does not use them.
-
- -- Target Hook: bool TARGET_DELAY_SCHED2
- True if sched2 is not to be run at its normal place. This usually
- means it will be run as part of machine-specific reorg.
-
- -- Target Hook: bool TARGET_DELAY_VARTRACK
- True if vartrack is not to be run at its normal place. This
- usually means it will be run as part of machine-specific reorg.
-
- -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2)
- A C statement to issue assembly directives that create a difference
- LAB1 minus LAB2, using an integer of the given SIZE.
-
- -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2)
- A C statement to issue assembly directives that create a difference
- between the two given labels in system defined units, e.g.
- instruction slots on IA64 VMS, using an integer of the given size.
-
- -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, SECTION)
- A C statement to issue assembly directives that create a
- section-relative reference to the given LABEL, using an integer of
- the given SIZE. The label is known to be defined in the given
- SECTION.
-
- -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL)
- A C statement to issue assembly directives that create a
- self-relative reference to the given LABEL, using an integer of
- the given SIZE.
-
- -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL)
- A C statement to issue assembly directives that create a reference
- to the DWARF table identifier LABEL from the current section. This
- is used on some systems to avoid garbage collecting a DWARF table
- which is referenced by a function.
-
- -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int
- SIZE, rtx X)
- If defined, this target hook is a function which outputs a
- DTP-relative reference to the given TLS symbol of the specified
- size.
-
- -- Macro: PUT_SDB_...
- Define these macros to override the assembler syntax for the
- special SDB assembler directives. See `sdbout.c' for a list of
- these macros and their arguments. If the standard syntax is used,
- you need not define them yourself.
-
- -- Macro: SDB_DELIM
- Some assemblers do not support a semicolon as a delimiter, even
- between SDB assembler directives. In that case, define this macro
- to be the delimiter to use (usually `\n'). It is not necessary to
- define a new set of `PUT_SDB_OP' macros if this is the only change
- required.
-
- -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES
- Define this macro to allow references to unknown structure, union,
- or enumeration tags to be emitted. Standard COFF does not allow
- handling of unknown references, MIPS ECOFF has support for it.
-
- -- Macro: SDB_ALLOW_FORWARD_REFERENCES
- Define this macro to allow references to structure, union, or
- enumeration tags that have not yet been seen to be handled. Some
- assemblers choke if forward tags are used, while some require it.
-
- -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE)
- A C statement to output SDB debugging information before code for
- line number LINE of the current source file to the stdio stream
- STREAM. The default is to emit an `.ln' directive.
-
-
-File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info
-
-17.22.6 Macros for VMS Debug Format
------------------------------------
-
-Here are macros for VMS debug format.
-
- -- Macro: VMS_DEBUGGING_INFO
- Define this macro if GCC should produce debugging output for VMS
- in response to the `-g' option. The default behavior for VMS is
- to generate minimal debug info for a traceback in the absence of
- `-g' unless explicitly overridden with `-g0'. This behavior is
- controlled by `TARGET_OPTION_OPTIMIZATION' and
- `TARGET_OPTION_OVERRIDE'.
-
-
-File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros
-
-17.23 Cross Compilation and Floating Point
-==========================================
-
-While all modern machines use twos-complement representation for
-integers, there are a variety of representations for floating point
-numbers. This means that in a cross-compiler the representation of
-floating point numbers in the compiled program may be different from
-that used in the machine doing the compilation.
-
- Because different representation systems may offer different amounts of
-range and precision, all floating point constants must be represented in
-the target machine's format. Therefore, the cross compiler cannot
-safely use the host machine's floating point arithmetic; it must emulate
-the target's arithmetic. To ensure consistency, GCC always uses
-emulation to work with floating point values, even when the host and
-target floating point formats are identical.
-
- The following macros are provided by `real.h' for the compiler to use.
-All parts of the compiler which generate or optimize floating-point
-calculations must use these macros. They may evaluate their operands
-more than once, so operands must not have side effects.
-
- -- Macro: REAL_VALUE_TYPE
- The C data type to be used to hold a floating point value in the
- target machine's format. Typically this is a `struct' containing
- an array of `HOST_WIDE_INT', but all code should treat it as an
- opaque quantity.
-
- -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
- Compares for equality the two values, X and Y. If the target
- floating point format supports negative zeroes and/or NaNs,
- `REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and `REAL_VALUES_EQUAL
- (NaN, NaN)' is false.
-
- -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
- Tests whether X is less than Y.
-
- -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X)
- Truncates X to a signed integer, rounding toward zero.
-
- -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX
- (REAL_VALUE_TYPE X)
- Truncates X to an unsigned integer, rounding toward zero. If X is
- negative, returns zero.
-
- -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum
- machine_mode MODE)
- Converts STRING into a floating point number in the target
- machine's representation for mode MODE. This routine can handle
- both decimal and hexadecimal floating point constants, using the
- syntax defined by the C language for both.
-
- -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X)
- Returns 1 if X is negative (including negative zero), 0 otherwise.
-
- -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X)
- Determines whether X represents infinity (positive or negative).
-
- -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X)
- Determines whether X represents a "NaN" (not-a-number).
-
- -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code
- CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
- Calculates an arithmetic operation on the two floating point values
- X and Y, storing the result in OUTPUT (which must be a variable).
-
- The operation to be performed is specified by CODE. Only the
- following codes are supported: `PLUS_EXPR', `MINUS_EXPR',
- `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'.
-
- If `REAL_ARITHMETIC' is asked to evaluate division by zero and the
- target's floating point format cannot represent infinity, it will
- call `abort'. Callers should check for this situation first, using
- `MODE_HAS_INFINITIES'. *Note Storage Layout::.
-
- -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X)
- Returns the negative of the floating point value X.
-
- -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X)
- Returns the absolute value of X.
-
- -- Macro: REAL_VALUE_TYPE REAL_VALUE_TRUNCATE (REAL_VALUE_TYPE MODE,
- enum machine_mode X)
- Truncates the floating point value X to fit in MODE. The return
- value is still a full-size `REAL_VALUE_TYPE', but it has an
- appropriate bit pattern to be output as a floating constant whose
- precision accords with mode MODE.
-
- -- Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT
- HIGH, REAL_VALUE_TYPE X)
- Converts a floating point value X into a double-precision integer
- which is then stored into LOW and HIGH. If the value is not
- integral, it is truncated.
-
- -- Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT
- LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE)
- Converts a double-precision integer found in LOW and HIGH, into a
- floating point value which is then stored into X. The value is
- truncated to fit in mode MODE.
-
-
-File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros
-
-17.24 Mode Switching Instructions
-=================================
-
-The following macros control mode switching optimizations:
-
- -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY)
- Define this macro if the port needs extra instructions inserted
- for mode switching in an optimizing compilation.
-
- For an example, the SH4 can perform both single and double
- precision floating point operations, but to perform a single
- precision operation, the FPSCR PR bit has to be cleared, while for
- a double precision operation, this bit has to be set. Changing
- the PR bit requires a general purpose register as a scratch
- register, hence these FPSCR sets have to be inserted before
- reload, i.e. you can't put this into instruction emitting or
- `TARGET_MACHINE_DEPENDENT_REORG'.
-
- You can have multiple entities that are mode-switched, and select
- at run time which entities actually need it.
- `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY
- that needs mode-switching. If you define this macro, you also
- have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED',
- `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'. `MODE_AFTER',
- `MODE_ENTRY', and `MODE_EXIT' are optional.
-
- -- Macro: NUM_MODES_FOR_MODE_SWITCHING
- If you define `OPTIMIZE_MODE_SWITCHING', you have to define this as
- initializer for an array of integers. Each initializer element N
- refers to an entity that needs mode switching, and specifies the
- number of different modes that might need to be set for this
- entity. The position of the initializer in the
- initializer--starting counting at zero--determines the integer
- that is used to refer to the mode-switched entity in question. In
- macros that take mode arguments / yield a mode result, modes are
- represented as numbers 0 ... N - 1. N is used to specify that no
- mode switch is needed / supplied.
-
- -- Macro: MODE_NEEDED (ENTITY, INSN)
- ENTITY is an integer specifying a mode-switched entity. If
- `OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to
- return an integer value not larger than the corresponding element
- in `NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY
- must be switched into prior to the execution of INSN.
-
- -- Macro: MODE_AFTER (MODE, INSN)
- If this macro is defined, it is evaluated for every INSN during
- mode switching. It determines the mode that an insn results in (if
- different from the incoming mode).
-
- -- Macro: MODE_ENTRY (ENTITY)
- If this macro is defined, it is evaluated for every ENTITY that
- needs mode switching. It should evaluate to an integer, which is
- a mode that ENTITY is assumed to be switched to at function entry.
- If `MODE_ENTRY' is defined then `MODE_EXIT' must be defined.
-
- -- Macro: MODE_EXIT (ENTITY)
- If this macro is defined, it is evaluated for every ENTITY that
- needs mode switching. It should evaluate to an integer, which is
- a mode that ENTITY is assumed to be switched to at function exit.
- If `MODE_EXIT' is defined then `MODE_ENTRY' must be defined.
-
- -- Macro: MODE_PRIORITY_TO_MODE (ENTITY, N)
- This macro specifies the order in which modes for ENTITY are
- processed. 0 is the highest priority,
- `NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value
- of the macro should be an integer designating a mode for ENTITY.
- For any fixed ENTITY, `mode_priority_to_mode' (ENTITY, N) shall be
- a bijection in 0 ... `num_modes_for_mode_switching[ENTITY] - 1'.
-
- -- Macro: EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE)
- Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE
- is the set of hard registers live at the point where the insn(s)
- are to be inserted.
-
-
-File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros
-
-17.25 Defining target-specific uses of `__attribute__'
-======================================================
-
-Target-specific attributes may be defined for functions, data and types.
-These are described using the following target hooks; they also need to
-be documented in `extend.texi'.
-
- -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE
- If defined, this target hook points to an array of `struct
- attribute_spec' (defined in `tree.h') specifying the machine
- specific attributes for this target and some of the restrictions
- on the entities to which these attributes are applied and the
- arguments they take.
-
- -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree
- NAME)
- If defined, this target hook is a function which returns true if
- the machine-specific attribute named NAME expects an identifier
- given as its first argument to be passed on as a plain identifier,
- not subjected to name lookup. If this is not defined, the default
- is false for all machine-specific attributes.
-
- -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1,
- const_tree TYPE2)
- If defined, this target hook is a function which returns zero if
- the attributes on TYPE1 and TYPE2 are incompatible, one if they
- are compatible, and two if they are nearly compatible (which
- causes a warning to be generated). If this is not defined,
- machine-specific attributes are supposed always to be compatible.
-
- -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE)
- If defined, this target hook is a function which assigns default
- attributes to the newly defined TYPE.
-
- -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree
- TYPE2)
- Define this target hook if the merging of type attributes needs
- special handling. If defined, the result is a list of the combined
- `TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that
- `comptypes' has already been called and returned 1. This function
- may call `merge_attributes' to handle machine-independent merging.
-
- -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree
- NEWDECL)
- Define this target hook if the merging of decl attributes needs
- special handling. If defined, the result is a list of the combined
- `DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate
- declaration of OLDDECL. Examples of when this is needed are when
- one attribute overrides another, or when an attribute is nullified
- by a subsequent definition. This function may call
- `merge_attributes' to handle machine-independent merging.
-
- If the only target-specific handling you require is `dllimport'
- for Microsoft Windows targets, you should define the macro
- `TARGET_DLLIMPORT_DECL_ATTRIBUTES' to `1'. The compiler will then
- define a function called `merge_dllimport_decl_attributes' which
- can then be defined as the expansion of
- `TARGET_MERGE_DECL_ATTRIBUTES'. You can also add
- `handle_dll_attribute' in the attribute table for your port to
- perform initial processing of the `dllimport' and `dllexport'
- attributes. This is done in `i386/cygwin.h' and `i386/i386.c',
- for example.
-
- -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree
- DECL)
- DECL is a variable or function with `__attribute__((dllimport))'
- specified. Use this hook if the target needs to add extra
- validation checks to `handle_dll_attribute'.
-
- -- Macro: TARGET_DECLSPEC
- Define this macro to a nonzero value if you want to treat
- `__declspec(X)' as equivalent to `__attribute((X))'. By default,
- this behavior is enabled only for targets that define
- `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of
- `__declspec' is via a built-in macro, but you should not rely on
- this implementation detail.
-
- -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree
- *ATTR_PTR)
- Define this target hook if you want to be able to add attributes
- to a decl when it is being created. This is normally useful for
- back ends which wish to implement a pragma by using the attributes
- which correspond to the pragma's effect. The NODE argument is the
- decl which is being created. The ATTR_PTR argument is a pointer
- to the attribute list for this decl. The list itself should not
- be modified, since it may be shared with other decls, but
- attributes may be chained on the head of the list and `*ATTR_PTR'
- modified to point to the new attributes, or a copy of the list may
- be made if further changes are needed.
-
- -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree
- FNDECL)
- This target hook returns `true' if it is ok to inline FNDECL into
- the current function, despite its having target-specific
- attributes, `false' otherwise. By default, if a function has a
- target specific attribute attached to it, it will not be inlined.
-
- -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL,
- tree NAME, tree ARGS, int FLAGS)
- This hook is called to parse the `attribute(option("..."))', and
- it allows the function to set different target machine compile time
- options for the current function that might be different than the
- options specified on the command line. The hook should return
- `true' if the options are valid.
-
- The hook should set the DECL_FUNCTION_SPECIFIC_TARGET field in the
- function declaration to hold a pointer to a target specific STRUCT
- CL_TARGET_OPTION structure.
-
- -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR)
- This hook is called to save any additional target specific
- information in the STRUCT CL_TARGET_OPTION structure for function
- specific options. *Note Option file format::.
-
- -- Target Hook: void TARGET_OPTION_RESTORE (struct cl_target_option
- *PTR)
- This hook is called to restore any additional target specific
- information in the STRUCT CL_TARGET_OPTION structure for function
- specific options.
-
- -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT,
- struct cl_target_option *PTR)
- This hook is called to print any additional target specific
- information in the STRUCT CL_TARGET_OPTION structure for function
- specific options.
-
- -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree
- POP_TARGET)
- This target hook parses the options for `#pragma GCC option' to
- set the machine specific options for functions that occur later in
- the input stream. The options should be the same as handled by the
- `TARGET_OPTION_VALID_ATTRIBUTE_P' hook.
-
- -- Target Hook: void TARGET_OPTION_OVERRIDE (void)
- Sometimes certain combinations of command options do not make
- sense on a particular target machine. You can override the hook
- `TARGET_OPTION_OVERRIDE' to take account of this. This hooks is
- called once just after all the command options have been parsed.
-
- Don't use this hook to turn on various extra optimizations for
- `-O'. That is what `TARGET_OPTION_OPTIMIZATION' is for.
-
- If you need to do something whenever the optimization level is
- changed via the optimize attribute or pragma, see
- `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'
-
- -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE)
- This target hook returns `false' if the CALLER function cannot
- inline CALLEE, based on target specific information. By default,
- inlining is not allowed if the callee function has function
- specific target options and the caller does not use the same
- options.
-
-
-File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros
-
-17.26 Emulating TLS
-===================
-
-For targets whose psABI does not provide Thread Local Storage via
-specific relocations and instruction sequences, an emulation layer is
-used. A set of target hooks allows this emulation layer to be
-configured for the requirements of a particular target. For instance
-the psABI may in fact specify TLS support in terms of an emulation
-layer.
-
- The emulation layer works by creating a control object for every TLS
-object. To access the TLS object, a lookup function is provided which,
-when given the address of the control object, will return the address
-of the current thread's instance of the TLS object.
-
- -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS
- Contains the name of the helper function that uses a TLS control
- object to locate a TLS instance. The default causes libgcc's
- emulated TLS helper function to be used.
-
- -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON
- Contains the name of the helper function that should be used at
- program startup to register TLS objects that are implicitly
- initialized to zero. If this is `NULL', all TLS objects will have
- explicit initializers. The default causes libgcc's emulated TLS
- registration function to be used.
-
- -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION
- Contains the name of the section in which TLS control variables
- should be placed. The default of `NULL' allows these to be placed
- in any section.
-
- -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION
- Contains the name of the section in which TLS initializers should
- be placed. The default of `NULL' allows these to be placed in any
- section.
-
- -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX
- Contains the prefix to be prepended to TLS control variable names.
- The default of `NULL' uses a target-specific prefix.
-
- -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX
- Contains the prefix to be prepended to TLS initializer objects.
- The default of `NULL' uses a target-specific prefix.
-
- -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME)
- Specifies a function that generates the FIELD_DECLs for a TLS
- control object type. TYPE is the RECORD_TYPE the fields are for
- and NAME should be filled with the structure tag, if the default of
- `__emutls_object' is unsuitable. The default creates a type
- suitable for libgcc's emulated TLS function.
-
- -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree
- TMPL_ADDR)
- Specifies a function that generates the CONSTRUCTOR to initialize a
- TLS control object. VAR is the TLS control object, DECL is the
- TLS object and TMPL_ADDR is the address of the initializer. The
- default initializes libgcc's emulated TLS control object.
-
- -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED
- Specifies whether the alignment of TLS control variable objects is
- fixed and should not be increased as some backends may do to
- optimize single objects. The default is false.
-
- -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS
- Specifies whether a DWARF `DW_OP_form_tls_address' location
- descriptor may be used to describe emulated TLS control objects.
-
-
-File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros
-
-17.27 Defining coprocessor specifics for MIPS targets.
-======================================================
-
-The MIPS specification allows MIPS implementations to have as many as 4
-coprocessors, each with as many as 32 private registers. GCC supports
-accessing these registers and transferring values between the registers
-and memory using asm-ized variables. For example:
-
- register unsigned int cp0count asm ("c0r1");
- unsigned int d;
-
- d = cp0count + 3;
-
- ("c0r1" is the default name of register 1 in coprocessor 0; alternate
-names may be added as described below, or the default names may be
-overridden entirely in `SUBTARGET_CONDITIONAL_REGISTER_USAGE'.)
-
- Coprocessor registers are assumed to be epilogue-used; sets to them
-will be preserved even if it does not appear that the register is used
-again later in the function.
-
- Another note: according to the MIPS spec, coprocessor 1 (if present) is
-the FPU. One accesses COP1 registers through standard mips
-floating-point support; they are not included in this mechanism.
-
- There is one macro used in defining the MIPS coprocessor interface
-which you may want to override in subtargets; it is described below.
-
- -- Macro: ALL_COP_ADDITIONAL_REGISTER_NAMES
- A comma-separated list (with leading comma) of pairs describing the
- alternate names of coprocessor registers. The format of each
- entry should be
- { ALTERNATENAME, REGISTER_NUMBER}
- Default: empty.
-
-
-File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros
-
-17.28 Parameters for Precompiled Header Validity Checking
-=========================================================
-
- -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ)
- This hook returns a pointer to the data needed by
- `TARGET_PCH_VALID_P' and sets `*SZ' to the size of the data in
- bytes.
-
- -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA,
- size_t SZ)
- This hook checks whether the options used to create a PCH file are
- compatible with the current settings. It returns `NULL' if so and
- a suitable error message if not. Error messages will be presented
- to the user and must be localized using `_(MSG)'.
-
- DATA is the data that was returned by `TARGET_GET_PCH_VALIDITY'
- when the PCH file was created and SZ is the size of that data in
- bytes. It's safe to assume that the data was created by the same
- version of the compiler, so no format checking is needed.
-
- The default definition of `default_pch_valid_p' should be suitable
- for most targets.
-
- -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int
- PCH_FLAGS)
- If this hook is nonnull, the default implementation of
- `TARGET_PCH_VALID_P' will use it to check for compatible values of
- `target_flags'. PCH_FLAGS specifies the value that `target_flags'
- had when the PCH file was created. The return value is the same
- as for `TARGET_PCH_VALID_P'.
-
-
-File: gccint.info, Node: C++ ABI, Next: Named Address Spaces, Prev: PCH Target, Up: Target Macros
-
-17.29 C++ ABI parameters
-========================
-
- -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void)
- Define this hook to override the integer type used for guard
- variables. These are used to implement one-time construction of
- static objects. The default is long_long_integer_type_node.
-
- -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void)
- This hook determines how guard variables are used. It should
- return `false' (the default) if the first byte should be used. A
- return value of `true' indicates that only the least significant
- bit should be used.
-
- -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE)
- This hook returns the size of the cookie to use when allocating an
- array whose elements have the indicated TYPE. Assumes that it is
- already known that a cookie is needed. The default is `max(sizeof
- (size_t), alignof(type))', as defined in section 2.7 of the
- IA64/Generic C++ ABI.
-
- -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void)
- This hook should return `true' if the element size should be
- stored in array cookies. The default is to return `false'.
-
- -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int
- IMPORT_EXPORT)
- If defined by a backend this hook allows the decision made to
- export class TYPE to be overruled. Upon entry IMPORT_EXPORT will
- contain 1 if the class is going to be exported, -1 if it is going
- to be imported and 0 otherwise. This function should return the
- modified value and perform any other actions necessary to support
- the backend's targeted operating system.
-
- -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void)
- This hook should return `true' if constructors and destructors
- return the address of the object created/destroyed. The default
- is to return `false'.
-
- -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void)
- This hook returns true if the key method for a class (i.e., the
- method which, if defined in the current translation unit, causes
- the virtual table to be emitted) may be an inline function. Under
- the standard Itanium C++ ABI the key method may be an inline
- function so long as the function is not declared inline in the
- class definition. Under some variants of the ABI, an inline
- function can never be the key method. The default is to return
- `true'.
-
- -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree
- DECL)
- DECL is a virtual table, virtual table table, typeinfo object, or
- other similar implicit class data object that will be emitted with
- external linkage in this translation unit. No ELF visibility has
- been explicitly specified. If the target needs to specify a
- visibility other than that of the containing class, use this hook
- to set `DECL_VISIBILITY' and `DECL_VISIBILITY_SPECIFIED'.
-
- -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void)
- This hook returns true (the default) if virtual tables and other
- similar implicit class data objects are always COMDAT if they have
- external linkage. If this hook returns false, then class data for
- classes whose virtual table will be emitted in only one translation
- unit will not be COMDAT.
-
- -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void)
- This hook returns true (the default) if the RTTI information for
- the basic types which is defined in the C++ runtime should always
- be COMDAT, false if it should not be COMDAT.
-
- -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void)
- This hook returns true if `__aeabi_atexit' (as defined by the ARM
- EABI) should be used to register static destructors when
- `-fuse-cxa-atexit' is in effect. The default is to return false
- to use `__cxa_atexit'.
-
- -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void)
- This hook returns true if the target `atexit' function can be used
- in the same manner as `__cxa_atexit' to register C++ static
- destructors. This requires that `atexit'-registered functions in
- shared libraries are run in the correct order when the libraries
- are unloaded. The default is to return false.
-
- -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE)
- TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has
- just been defined. Use this hook to make adjustments to the class
- (eg, tweak visibility or perform any other required target
- modifications).
-
-
-File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: C++ ABI, Up: Target Macros
-
-17.30 Adding support for named address spaces
-=============================================
-
-The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards
-committee, `Programming Languages - C - Extensions to support embedded
-processors', specifies a syntax for embedded processors to specify
-alternate address spaces. You can configure a GCC port to support
-section 5.1 of the draft report to add support for address spaces other
-than the default address space. These address spaces are new keywords
-that are similar to the `volatile' and `const' type attributes.
-
- Pointers to named address spaces can have a different size than
-pointers to the generic address space.
-
- For example, the SPU port uses the `__ea' address space to refer to
-memory in the host processor, rather than memory local to the SPU
-processor. Access to memory in the `__ea' address space involves
-issuing DMA operations to move data between the host processor and the
-local processor memory address space. Pointers in the `__ea' address
-space are either 32 bits or 64 bits based on the `-mea32' or `-mea64'
-switches (native SPU pointers are always 32 bits).
-
- Internally, address spaces are represented as a small integer in the
-range 0 to 15 with address space 0 being reserved for the generic
-address space.
-
- To register a named address space qualifier keyword with the C front
-end, the target may call the `c_register_addr_space' routine. For
-example, the SPU port uses the following to declare `__ea' as the
-keyword for named address space #1:
- #define ADDR_SPACE_EA 1
- c_register_addr_space ("__ea", ADDR_SPACE_EA);
-
- -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_POINTER_MODE
- (addr_space_t ADDRESS_SPACE)
- Define this to return the machine mode to use for pointers to
- ADDRESS_SPACE if the target supports named address spaces. The
- default version of this hook returns `ptr_mode' for the generic
- address space only.
-
- -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_ADDRESS_MODE
- (addr_space_t ADDRESS_SPACE)
- Define this to return the machine mode to use for addresses in
- ADDRESS_SPACE if the target supports named address spaces. The
- default version of this hook returns `Pmode' for the generic
- address space only.
-
- -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE (enum
- machine_mode MODE, addr_space_t AS)
- Define this to return nonzero if the port can handle pointers with
- machine mode MODE to address space AS. This target hook is the
- same as the `TARGET_VALID_POINTER_MODE' target hook, except that
- it includes explicit named address space support. The default
- version of this hook returns true for the modes returned by either
- the `TARGET_ADDR_SPACE_POINTER_MODE' or
- `TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given
- address space.
-
- -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P (enum
- machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS)
- Define this to return true if EXP is a valid address for mode MODE
- in the named address space AS. The STRICT parameter says whether
- strict addressing is in effect after reload has finished. This
- target hook is the same as the `TARGET_LEGITIMATE_ADDRESS_P'
- target hook, except that it includes explicit named address space
- support.
-
- -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx
- OLDX, enum machine_mode MODE, addr_space_t AS)
- Define this to modify an invalid address X to be a valid address
- with mode MODE in the named address space AS. This target hook is
- the same as the `TARGET_LEGITIMIZE_ADDRESS' target hook, except
- that it includes explicit named address space support.
-
- -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t
- SUPERSET, addr_space_t SUBSET)
- Define this to return whether the SUBSET named address space is
- contained within the SUPERSET named address space. Pointers to a
- named address space that is a subset of another named address space
- will be converted automatically without a cast if used together in
- arithmetic operations. Pointers to a superset address space can be
- converted to pointers to a subset address space via explicit casts.
-
- -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE,
- tree TO_TYPE)
- Define this to convert the pointer expression represented by the
- RTL OP with type FROM_TYPE that points to a named address space to
- a new pointer expression with type TO_TYPE that points to a
- different named address space. When this hook it called, it is
- guaranteed that one of the two address spaces is a subset of the
- other, as determined by the `TARGET_ADDR_SPACE_SUBSET_P' target
- hook.
-
-
-File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros
-
-17.31 Miscellaneous Parameters
-==============================
-
-Here are several miscellaneous parameters.
-
- -- Macro: HAS_LONG_COND_BRANCH
- Define this boolean macro to indicate whether or not your
- architecture has conditional branches that can span all of memory.
- It is used in conjunction with an optimization that partitions hot
- and cold basic blocks into separate sections of the executable.
- If this macro is set to false, gcc will convert any conditional
- branches that attempt to cross between sections into unconditional
- branches or indirect jumps.
-
- -- Macro: HAS_LONG_UNCOND_BRANCH
- Define this boolean macro to indicate whether or not your
- architecture has unconditional branches that can span all of
- memory. It is used in conjunction with an optimization that
- partitions hot and cold basic blocks into separate sections of the
- executable. If this macro is set to false, gcc will convert any
- unconditional branches that attempt to cross between sections into
- indirect jumps.
-
- -- Macro: CASE_VECTOR_MODE
- An alias for a machine mode name. This is the machine mode that
- elements of a jump-table should have.
-
- -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY)
- Optional: return the preferred mode for an `addr_diff_vec' when
- the minimum and maximum offset are known. If you define this, it
- enables extra code in branch shortening to deal with
- `addr_diff_vec'. To make this work, you also have to define
- `INSN_ALIGN' and make the alignment for `addr_diff_vec' explicit.
- The BODY argument is provided so that the offset_unsigned and scale
- flags can be updated.
-
- -- Macro: CASE_VECTOR_PC_RELATIVE
- Define this macro to be a C expression to indicate when jump-tables
- should contain relative addresses. You need not define this macro
- if jump-tables never contain relative addresses, or jump-tables
- should contain relative addresses only when `-fPIC' or `-fPIC' is
- in effect.
-
- -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void)
- This function return the smallest number of different values for
- which it is best to use a jump-table instead of a tree of
- conditional branches. The default is four for machines with a
- `casesi' instruction and five otherwise. This is best for most
- machines.
-
- -- Macro: CASE_USE_BIT_TESTS
- Define this macro to be a C expression to indicate whether C switch
- statements may be implemented by a sequence of bit tests. This is
- advantageous on processors that can efficiently implement left
- shift of 1 by the number of bits held in a register, but
- inappropriate on targets that would require a loop. By default,
- this macro returns `true' if the target defines an `ashlsi3'
- pattern, and `false' otherwise.
-
- -- Macro: WORD_REGISTER_OPERATIONS
- Define this macro if operations between registers with integral
- mode smaller than a word are always performed on the entire
- register. Most RISC machines have this property and most CISC
- machines do not.
-
- -- Macro: LOAD_EXTEND_OP (MEM_MODE)
- Define this macro to be a C expression indicating when insns that
- read memory in MEM_MODE, an integral mode narrower than a word,
- set the bits outside of MEM_MODE to be either the sign-extension
- or the zero-extension of the data read. Return `SIGN_EXTEND' for
- values of MEM_MODE for which the insn sign-extends, `ZERO_EXTEND'
- for which it zero-extends, and `UNKNOWN' for other modes.
-
- This macro is not called with MEM_MODE non-integral or with a width
- greater than or equal to `BITS_PER_WORD', so you may return any
- value in this case. Do not define this macro if it would always
- return `UNKNOWN'. On machines where this macro is defined, you
- will normally define it as the constant `SIGN_EXTEND' or
- `ZERO_EXTEND'.
-
- You may return a non-`UNKNOWN' value even if for some hard
- registers the sign extension is not performed, if for the
- `REGNO_REG_CLASS' of these hard registers
- `CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is
- MEM_MODE and the TO mode is any integral mode larger than this but
- not larger than `word_mode'.
-
- You must return `UNKNOWN' if for some hard registers that allow
- this mode, `CANNOT_CHANGE_MODE_CLASS' says that they cannot change
- to `word_mode', but that they can change to another integral mode
- that is larger then MEM_MODE but still smaller than `word_mode'.
-
- -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND
- Define this macro if loading short immediate values into registers
- sign extends.
-
- -- Macro: FIXUNS_TRUNC_LIKE_FIX_TRUNC
- Define this macro if the same instructions that convert a floating
- point number to a signed fixed point number also convert validly
- to an unsigned one.
-
- -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL (enum
- machine_mode MODE)
- When `-ffast-math' is in effect, GCC tries to optimize divisions
- by the same divisor, by turning them into multiplications by the
- reciprocal. This target hook specifies the minimum number of
- divisions that should be there for GCC to perform the optimization
- for a variable of mode MODE. The default implementation returns 3
- if the machine has an instruction for the division, and 2 if it
- does not.
-
- -- Macro: MOVE_MAX
- The maximum number of bytes that a single instruction can move
- quickly between memory and registers or between two memory
- locations.
-
- -- Macro: MAX_MOVE_MAX
- The maximum number of bytes that a single instruction can move
- quickly between memory and registers or between two memory
- locations. If this is undefined, the default is `MOVE_MAX'.
- Otherwise, it is the constant value that is the largest value that
- `MOVE_MAX' can have at run-time.
-
- -- Macro: SHIFT_COUNT_TRUNCATED
- A C expression that is nonzero if on this machine the number of
- bits actually used for the count of a shift operation is equal to
- the number of bits needed to represent the size of the object
- being shifted. When this macro is nonzero, the compiler will
- assume that it is safe to omit a sign-extend, zero-extend, and
- certain bitwise `and' instructions that truncates the count of a
- shift operation. On machines that have instructions that act on
- bit-fields at variable positions, which may include `bit test'
- instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables
- deletion of truncations of the values that serve as arguments to
- bit-field instructions.
-
- If both types of instructions truncate the count (for shifts) and
- position (for bit-field operations), or if no variable-position
- bit-field instructions exist, you should define this macro.
-
- However, on some machines, such as the 80386 and the 680x0,
- truncation only applies to shift operations and not the (real or
- pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED'
- to be zero on such machines. Instead, add patterns to the `md'
- file that include the implied truncation of the shift instructions.
-
- You need not define this macro if it would always have the value
- of zero.
-
- -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK
- (enum machine_mode MODE)
- This function describes how the standard shift patterns for MODE
- deal with shifts by negative amounts or by more than the width of
- the mode. *Note shift patterns::.
-
- On many machines, the shift patterns will apply a mask M to the
- shift count, meaning that a fixed-width shift of X by Y is
- equivalent to an arbitrary-width shift of X by Y & M. If this is
- true for mode MODE, the function should return M, otherwise it
- should return 0. A return value of 0 indicates that no particular
- behavior is guaranteed.
-
- Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does
- _not_ apply to general shift rtxes; it applies only to instructions
- that are generated by the named shift patterns.
-
- The default implementation of this function returns
- `GET_MODE_BITSIZE (MODE) - 1' if `SHIFT_COUNT_TRUNCATED' and 0
- otherwise. This definition is always safe, but if
- `SHIFT_COUNT_TRUNCATED' is false, and some shift patterns
- nevertheless truncate the shift count, you may get better code by
- overriding it.
-
- -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)
- A C expression which is nonzero if on this machine it is safe to
- "convert" an integer of INPREC bits to one of OUTPREC bits (where
- OUTPREC is smaller than INPREC) by merely operating on it as if it
- had only OUTPREC bits.
-
- On many machines, this expression can be 1.
-
- When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for
- modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result.
- If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in
- such cases may improve things.
-
- -- Target Hook: int TARGET_MODE_REP_EXTENDED (enum machine_mode MODE,
- enum machine_mode REP_MODE)
- The representation of an integral mode can be such that the values
- are always extended to a wider integral mode. Return
- `SIGN_EXTEND' if values of MODE are represented in sign-extended
- form to REP_MODE. Return `UNKNOWN' otherwise. (Currently, none
- of the targets use zero-extended representation this way so unlike
- `LOAD_EXTEND_OP', `TARGET_MODE_REP_EXTENDED' is expected to return
- either `SIGN_EXTEND' or `UNKNOWN'. Also no target extends MODE to
- REP_MODE so that REP_MODE is not the next widest integral mode and
- currently we take advantage of this fact.)
-
- Similarly to `LOAD_EXTEND_OP' you may return a non-`UNKNOWN' value
- even if the extension is not performed on certain hard registers
- as long as for the `REGNO_REG_CLASS' of these hard registers
- `CANNOT_CHANGE_MODE_CLASS' returns nonzero.
-
- Note that `TARGET_MODE_REP_EXTENDED' and `LOAD_EXTEND_OP' describe
- two related properties. If you define `TARGET_MODE_REP_EXTENDED
- (mode, word_mode)' you probably also want to define
- `LOAD_EXTEND_OP (mode)' to return the same type of extension.
-
- In order to enforce the representation of `mode',
- `TRULY_NOOP_TRUNCATION' should return false when truncating to
- `mode'.
-
- -- Macro: STORE_FLAG_VALUE
- A C expression describing the value returned by a comparison
- operator with an integral mode and stored by a store-flag
- instruction (`cstoreMODE4') when the condition is true. This
- description must apply to _all_ the `cstoreMODE4' patterns and all
- the comparison operators whose results have a `MODE_INT' mode.
-
- A value of 1 or -1 means that the instruction implementing the
- comparison operator returns exactly 1 or -1 when the comparison is
- true and 0 when the comparison is false. Otherwise, the value
- indicates which bits of the result are guaranteed to be 1 when the
- comparison is true. This value is interpreted in the mode of the
- comparison operation, which is given by the mode of the first
- operand in the `cstoreMODE4' pattern. Either the low bit or the
- sign bit of `STORE_FLAG_VALUE' be on. Presently, only those bits
- are used by the compiler.
-
- If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will
- generate code that depends only on the specified bits. It can also
- replace comparison operators with equivalent operations if they
- cause the required bits to be set, even if the remaining bits are
- undefined. For example, on a machine whose comparison operators
- return an `SImode' value and where `STORE_FLAG_VALUE' is defined as
- `0x80000000', saying that just the sign bit is relevant, the
- expression
-
- (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0))
-
- can be converted to
-
- (ashift:SI X (const_int N))
-
- where N is the appropriate shift count to move the bit being
- tested into the sign bit.
-
- There is no way to describe a machine that always sets the
- low-order bit for a true value, but does not guarantee the value
- of any other bits, but we do not know of any machine that has such
- an instruction. If you are trying to port GCC to such a machine,
- include an instruction to perform a logical-and of the result with
- 1 in the pattern for the comparison operators and let us know at
- <gcc@gcc.gnu.org>.
-
- Often, a machine will have multiple instructions that obtain a
- value from a comparison (or the condition codes). Here are rules
- to guide the choice of value for `STORE_FLAG_VALUE', and hence the
- instructions to be used:
-
- * Use the shortest sequence that yields a valid definition for
- `STORE_FLAG_VALUE'. It is more efficient for the compiler to
- "normalize" the value (convert it to, e.g., 1 or 0) than for
- the comparison operators to do so because there may be
- opportunities to combine the normalization with other
- operations.
-
- * For equal-length sequences, use a value of 1 or -1, with -1
- being slightly preferred on machines with expensive jumps and
- 1 preferred on other machines.
-
- * As a second choice, choose a value of `0x80000001' if
- instructions exist that set both the sign and low-order bits
- but do not define the others.
-
- * Otherwise, use a value of `0x80000000'.
-
- Many machines can produce both the value chosen for
- `STORE_FLAG_VALUE' and its negation in the same number of
- instructions. On those machines, you should also define a pattern
- for those cases, e.g., one matching
-
- (set A (neg:M (ne:M B C)))
-
- Some machines can also perform `and' or `plus' operations on
- condition code values with less instructions than the corresponding
- `cstoreMODE4' insn followed by `and' or `plus'. On those
- machines, define the appropriate patterns. Use the names `incscc'
- and `decscc', respectively, for the patterns which perform `plus'
- or `minus' operations on condition code values. See `rs6000.md'
- for some examples. The GNU Superoptimizer can be used to find
- such instruction sequences on other machines.
-
- If this macro is not defined, the default value, 1, is used. You
- need not define `STORE_FLAG_VALUE' if the machine has no store-flag
- instructions, or if the value generated by these instructions is 1.
-
- -- Macro: FLOAT_STORE_FLAG_VALUE (MODE)
- A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is
- returned when comparison operators with floating-point results are
- true. Define this macro on machines that have comparison
- operations that return floating-point values. If there are no
- such operations, do not define this macro.
-
- -- Macro: VECTOR_STORE_FLAG_VALUE (MODE)
- A C expression that gives a rtx representing the nonzero true
- element for vector comparisons. The returned rtx should be valid
- for the inner mode of MODE which is guaranteed to be a vector
- mode. Define this macro on machines that have vector comparison
- operations that return a vector result. If there are no such
- operations, do not define this macro. Typically, this macro is
- defined as `const1_rtx' or `constm1_rtx'. This macro may return
- `NULL_RTX' to prevent the compiler optimizing such vector
- comparison operations for the given mode.
-
- -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
- -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
- A C expression that indicates whether the architecture defines a
- value for `clz' or `ctz' with a zero operand. A result of `0'
- indicates the value is undefined. If the value is defined for
- only the RTL expression, the macro should evaluate to `1'; if the
- value applies also to the corresponding optab entry (which is
- normally the case if it expands directly into the corresponding
- RTL), then the macro should evaluate to `2'. In the cases where
- the value is defined, VALUE should be set to this value.
-
- If this macro is not defined, the value of `clz' or `ctz' at zero
- is assumed to be undefined.
-
- This macro must be defined if the target's expansion for `ffs'
- relies on a particular value to get correct results. Otherwise it
- is not necessary, though it may be used to optimize some corner
- cases, and to provide a default expansion for the `ffs' optab.
-
- Note that regardless of this macro the "definedness" of `clz' and
- `ctz' at zero do _not_ extend to the builtin functions visible to
- the user. Thus one may be free to adjust the value at will to
- match the target expansion of these operations without fear of
- breaking the API.
-
- -- Macro: Pmode
- An alias for the machine mode for pointers. On most machines,
- define this to be the integer mode corresponding to the width of a
- hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit
- machines. On some machines you must define this to be one of the
- partial integer modes, such as `PSImode'.
-
- The width of `Pmode' must be at least as large as the value of
- `POINTER_SIZE'. If it is not equal, you must define the macro
- `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to
- `Pmode'.
-
- -- Macro: FUNCTION_MODE
- An alias for the machine mode used for memory references to
- functions being called, in `call' RTL expressions. On most CISC
- machines, where an instruction can begin at any byte address, this
- should be `QImode'. On most RISC machines, where all instructions
- have fixed size and alignment, this should be a mode with the same
- size and alignment as the machine instruction words - typically
- `SImode' or `HImode'.
-
- -- Macro: STDC_0_IN_SYSTEM_HEADERS
- In normal operation, the preprocessor expands `__STDC__' to the
- constant 1, to signify that GCC conforms to ISO Standard C. On
- some hosts, like Solaris, the system compiler uses a different
- convention, where `__STDC__' is normally 0, but is 1 if the user
- specifies strict conformance to the C Standard.
-
- Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host
- convention when processing system header files, but when
- processing user files `__STDC__' will always expand to 1.
-
- -- Macro: NO_IMPLICIT_EXTERN_C
- Define this macro if the system header files support C++ as well
- as C. This macro inhibits the usual method of using system header
- files in C++, which is to pretend that the file's contents are
- enclosed in `extern "C" {...}'.
-
- -- Macro: REGISTER_TARGET_PRAGMAS ()
- Define this macro if you want to implement any target-specific
- pragmas. If defined, it is a C expression which makes a series of
- calls to `c_register_pragma' or `c_register_pragma_with_expansion'
- for each pragma. The macro may also do any setup required for the
- pragmas.
-
- The primary reason to define this macro is to provide
- compatibility with other compilers for the same target. In
- general, we discourage definition of target-specific pragmas for
- GCC.
-
- If the pragma can be implemented by attributes then you should
- consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as
- well.
-
- Preprocessor macros that appear on pragma lines are not expanded.
- All `#pragma' directives that do not match any registered pragma
- are silently ignored, unless the user specifies
- `-Wunknown-pragmas'.
-
- -- Function: void c_register_pragma (const char *SPACE, const char
- *NAME, void (*CALLBACK) (struct cpp_reader *))
- -- Function: void c_register_pragma_with_expansion (const char *SPACE,
- const char *NAME, void (*CALLBACK) (struct cpp_reader *))
- Each call to `c_register_pragma' or
- `c_register_pragma_with_expansion' establishes one pragma. The
- CALLBACK routine will be called when the preprocessor encounters a
- pragma of the form
-
- #pragma [SPACE] NAME ...
-
- SPACE is the case-sensitive namespace of the pragma, or `NULL' to
- put the pragma in the global namespace. The callback routine
- receives PFILE as its first argument, which can be passed on to
- cpplib's functions if necessary. You can lex tokens after the
- NAME by calling `pragma_lex'. Tokens that are not read by the
- callback will be silently ignored. The end of the line is
- indicated by a token of type `CPP_EOF'. Macro expansion occurs on
- the arguments of pragmas registered with
- `c_register_pragma_with_expansion' but not on the arguments of
- pragmas registered with `c_register_pragma'.
-
- Note that the use of `pragma_lex' is specific to the C and C++
- compilers. It will not work in the Java or Fortran compilers, or
- any other language compilers for that matter. Thus if
- `pragma_lex' is going to be called from target-specific code, it
- must only be done so when building the C and C++ compilers. This
- can be done by defining the variables `c_target_objs' and
- `cxx_target_objs' in the target entry in the `config.gcc' file.
- These variables should name the target-specific, language-specific
- object file which contains the code that uses `pragma_lex'. Note
- it will also be necessary to add a rule to the makefile fragment
- pointed to by `tmake_file' that shows how to build this object
- file.
-
- -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION
- Define this macro if macros should be expanded in the arguments of
- `#pragma pack'.
-
- -- Target Hook: bool TARGET_HANDLE_PRAGMA_EXTERN_PREFIX
- True if `#pragma extern_prefix' is to be supported.
-
- -- Macro: TARGET_DEFAULT_PACK_STRUCT
- If your target requires a structure packing default other than 0
- (meaning the machine default), define this macro to the necessary
- value (in bytes). This must be a value that would also be valid
- to use with `#pragma pack()' (that is, a small power of two).
-
- -- Macro: DOLLARS_IN_IDENTIFIERS
- Define this macro to control use of the character `$' in
- identifier names for the C family of languages. 0 means `$' is
- not allowed by default; 1 means it is allowed. 1 is the default;
- there is no need to define this macro in that case.
-
- -- Macro: NO_DOLLAR_IN_LABEL
- Define this macro if the assembler does not accept the character
- `$' in label names. By default constructors and destructors in
- G++ have `$' in the identifiers. If this macro is defined, `.' is
- used instead.
-
- -- Macro: NO_DOT_IN_LABEL
- Define this macro if the assembler does not accept the character
- `.' in label names. By default constructors and destructors in G++
- have names that use `.'. If this macro is defined, these names
- are rewritten to avoid `.'.
-
- -- Macro: INSN_SETS_ARE_DELAYED (INSN)
- Define this macro as a C expression that is nonzero if it is safe
- for the delay slot scheduler to place instructions in the delay
- slot of INSN, even if they appear to use a resource set or
- clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC
- knows that every `call_insn' has this behavior. On machines where
- some `insn' or `jump_insn' is really a function call and hence has
- this behavior, you should define this macro.
-
- You need not define this macro if it would always return zero.
-
- -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN)
- Define this macro as a C expression that is nonzero if it is safe
- for the delay slot scheduler to place instructions in the delay
- slot of INSN, even if they appear to set or clobber a resource
- referenced in INSN. INSN is always a `jump_insn' or an `insn'.
- On machines where some `insn' or `jump_insn' is really a function
- call and its operands are registers whose use is actually in the
- subroutine it calls, you should define this macro. Doing so
- allows the delay slot scheduler to move instructions which copy
- arguments into the argument registers into the delay slot of INSN.
-
- You need not define this macro if it would always return zero.
-
- -- Macro: MULTIPLE_SYMBOL_SPACES
- Define this macro as a C expression that is nonzero if, in some
- cases, global symbols from one translation unit may not be bound
- to undefined symbols in another translation unit without user
- intervention. For instance, under Microsoft Windows symbols must
- be explicitly imported from shared libraries (DLLs).
-
- You need not define this macro if it would always evaluate to zero.
-
- -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree
- INPUTS, tree CLOBBERS)
- This target hook should add to CLOBBERS `STRING_CST' trees for any
- hard regs the port wishes to automatically clobber for an asm. It
- should return the result of the last `tree_cons' used to add a
- clobber. The OUTPUTS, INPUTS and CLOBBER lists are the
- corresponding parameters to the asm and may be inspected to avoid
- clobbering a register that is an input or output of the asm. You
- can use `tree_overlaps_hard_reg_set', declared in `tree.h', to test
- for overlap with regards to asm-declared registers.
-
- -- Macro: MATH_LIBRARY
- Define this macro as a C string constant for the linker argument
- to link in the system math library, minus the initial `"-l"', or
- `""' if the target does not have a separate math library.
-
- You need only define this macro if the default of `"m"' is wrong.
-
- -- Macro: LIBRARY_PATH_ENV
- Define this macro as a C string constant for the environment
- variable that specifies where the linker should look for libraries.
-
- You need only define this macro if the default of `"LIBRARY_PATH"'
- is wrong.
-
- -- Macro: TARGET_POSIX_IO
- Define this macro if the target supports the following POSIX file
- functions, access, mkdir and file locking with fcntl / F_SETLKW.
- Defining `TARGET_POSIX_IO' will enable the test coverage code to
- use file locking when exiting a program, which avoids race
- conditions if the program has forked. It will also create
- directories at run-time for cross-profiling.
-
- -- Macro: MAX_CONDITIONAL_EXECUTE
- A C expression for the maximum number of instructions to execute
- via conditional execution instructions instead of a branch. A
- value of `BRANCH_COST'+1 is the default if the machine does not
- use cc0, and 1 if it does use cc0.
-
- -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR)
- Used if the target needs to perform machine-dependent
- modifications on the conditionals used for turning basic blocks
- into conditionally executed code. CE_INFO points to a data
- structure, `struct ce_if_block', which contains information about
- the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the
- tests that are used for converting the then-block and the
- else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a
- null pointer if the tests cannot be converted.
-
- -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR,
- FALSE_EXPR)
- Like `IFCVT_MODIFY_TESTS', but used when converting more
- complicated if-statements into conditions combined by `and' and
- `or' operations. BB contains the basic block that contains the
- test that is currently being processed and about to be turned into
- a condition.
-
- -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN)
- A C expression to modify the PATTERN of an INSN that is to be
- converted to conditional execution format. CE_INFO points to a
- data structure, `struct ce_if_block', which contains information
- about the currently processed blocks.
-
- -- Macro: IFCVT_MODIFY_FINAL (CE_INFO)
- A C expression to perform any final machine dependent
- modifications in converting code to conditional execution. The
- involved basic blocks can be found in the `struct ce_if_block'
- structure that is pointed to by CE_INFO.
-
- -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO)
- A C expression to cancel any machine dependent modifications in
- converting code to conditional execution. The involved basic
- blocks can be found in the `struct ce_if_block' structure that is
- pointed to by CE_INFO.
-
- -- Macro: IFCVT_INIT_EXTRA_FIELDS (CE_INFO)
- A C expression to initialize any extra fields in a `struct
- ce_if_block' structure, which are defined by the
- `IFCVT_EXTRA_FIELDS' macro.
-
- -- Macro: IFCVT_EXTRA_FIELDS
- If defined, it should expand to a set of field declarations that
- will be added to the `struct ce_if_block' structure. These should
- be initialized by the `IFCVT_INIT_EXTRA_FIELDS' macro.
-
- -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void)
- If non-null, this hook performs a target-specific pass over the
- instruction stream. The compiler will run it at all optimization
- levels, just before the point at which it normally does
- delayed-branch scheduling.
-
- The exact purpose of the hook varies from target to target. Some
- use it to do transformations that are necessary for correctness,
- such as laying out in-function constant pools or avoiding hardware
- hazards. Others use it as an opportunity to do some
- machine-dependent optimizations.
-
- You need not implement the hook if it has nothing to do. The
- default definition is null.
-
- -- Target Hook: void TARGET_INIT_BUILTINS (void)
- Define this hook if you have any machine-specific built-in
- functions that need to be defined. It should be a function that
- performs the necessary setup.
-
- Machine specific built-in functions can be useful to expand
- special machine instructions that would otherwise not normally be
- generated because they have no equivalent in the source language
- (for example, SIMD vector instructions or prefetch instructions).
-
- To create a built-in function, call the function
- `lang_hooks.builtin_function' which is defined by the language
- front end. You can use any type nodes set up by
- `build_common_tree_nodes' and `build_common_tree_nodes_2'; only
- language front ends that use those two functions will call
- `TARGET_INIT_BUILTINS'.
-
- -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool
- INITIALIZE_P)
- Define this hook if you have any machine-specific built-in
- functions that need to be defined. It should be a function that
- returns the builtin function declaration for the builtin function
- code CODE. If there is no such builtin and it cannot be
- initialized at this time if INITIALIZE_P is true the function
- should return `NULL_TREE'. If CODE is out of range the function
- should return `error_mark_node'.
-
- -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx
- SUBTARGET, enum machine_mode MODE, int IGNORE)
- Expand a call to a machine specific built-in function that was set
- up by `TARGET_INIT_BUILTINS'. EXP is the expression for the
- function call; the result should go to TARGET if that is
- convenient, and have mode MODE if that is convenient. SUBTARGET
- may be used as the target for computing one of EXP's operands.
- IGNORE is nonzero if the value is to be ignored. This function
- should return the result of the call to the built-in function.
-
- -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int
- LOC, tree FNDECL, void *ARGLIST)
- Select a replacement for a machine specific built-in function that
- was set up by `TARGET_INIT_BUILTINS'. This is done _before_
- regular type checking, and so allows the target to implement a
- crude form of function overloading. FNDECL is the declaration of
- the built-in function. ARGLIST is the list of arguments passed to
- the built-in function. The result is a complete expression that
- implements the operation, usually another `CALL_EXPR'. ARGLIST
- really has type `VEC(tree,gc)*'
-
- -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS,
- tree *ARGP, bool IGNORE)
- Fold a call to a machine specific built-in function that was set
- up by `TARGET_INIT_BUILTINS'. FNDECL is the declaration of the
- built-in function. N_ARGS is the number of arguments passed to
- the function; the arguments themselves are pointed to by ARGP.
- The result is another tree containing a simplified expression for
- the call's result. If IGNORE is true the value will be ignored.
-
- -- Target Hook: int TARGET_MVERSION_FUNCTION (tree FNDECL, tree
- *OPTIMIZATION_NODE_CHAIN, tree *COND_FUNC_DECL)
- Check if a function needs to be multi-versioned to support
- variants of this architecture. FNDECL is the declaration of the
- function.
-
- -- Target Hook: bool TARGET_SLOW_UNALIGNED_VECTOR_MEMOP (void)
- Return true if unaligned vector memory load/store is a slow
- operation on this target.
-
- -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const_rtx
- INSN)
- Take an instruction in INSN and return NULL if it is valid within a
- low-overhead loop, otherwise return a string explaining why doloop
- could not be applied.
-
- Many targets use special registers for low-overhead looping. For
- any instruction that clobbers these this function should return a
- string indicating the reason why the doloop could not be applied.
- By default, the RTL loop optimizer does not use a present doloop
- pattern for loops containing function calls or branch on table
- instructions.
-
- -- Macro: MD_CAN_REDIRECT_BRANCH (BRANCH1, BRANCH2)
- Take a branch insn in BRANCH1 and another in BRANCH2. Return true
- if redirecting BRANCH1 to the destination of BRANCH2 is possible.
-
- On some targets, branches may have a limited range. Optimizing the
- filling of delay slots can result in branches being redirected,
- and this may in turn cause a branch offset to overflow.
-
- -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE)
- This target hook returns `true' if X is considered to be
- commutative. Usually, this is just COMMUTATIVE_P (X), but the HP
- PA doesn't consider PLUS to be commutative inside a MEM.
- OUTER_CODE is the rtx code of the enclosing rtl, if known,
- otherwise it is UNKNOWN.
-
- -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG)
- When the initial value of a hard register has been copied in a
- pseudo register, it is often not necessary to actually allocate
- another register to this pseudo register, because the original
- hard register or a stack slot it has been saved into can be used.
- `TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register
- allocation once for each hard register that had its initial value
- copied by using `get_func_hard_reg_initial_val' or
- `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if
- you don't want to do any special allocation, a `REG' rtx--that
- would typically be the hard register itself, if it is known not to
- be clobbered--or a `MEM'. If you are returning a `MEM', this is
- only a hint for the allocator; it might decide to use another
- register anyways. You may use `current_function_leaf_function' in
- the hook, functions that use `REG_N_SETS', to determine if the hard
- register in question will not be clobbered. The default value of
- this hook is `NULL', which disables any special allocation.
-
- -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned
- FLAGS)
- This target hook returns nonzero if X, an `unspec' or
- `unspec_volatile' operation, might cause a trap. Targets can use
- this hook to enhance precision of analysis for `unspec' and
- `unspec_volatile' operations. You may call `may_trap_p_1' to
- analyze inner elements of X in which case FLAGS should be passed
- along.
-
- -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL)
- The compiler invokes this hook whenever it changes its current
- function context (`cfun'). You can define this function if the
- back end needs to perform any initialization or reset actions on a
- per-function basis. For example, it may be used to implement
- function attributes that affect register usage or code generation
- patterns. The argument DECL is the declaration for the new
- function context, and may be null to indicate that the compiler
- has left a function context and is returning to processing at the
- top level. The default hook function does nothing.
-
- GCC sets `cfun' to a dummy function context during initialization
- of some parts of the back end. The hook function is not invoked
- in this situation; you need not worry about the hook being invoked
- recursively, or when the back end is in a partially-initialized
- state. `cfun' might be `NULL' to indicate processing at top level,
- outside of any function scope.
-
- -- Macro: TARGET_OBJECT_SUFFIX
- Define this macro to be a C string representing the suffix for
- object files on your target machine. If you do not define this
- macro, GCC will use `.o' as the suffix for object files.
-
- -- Macro: TARGET_EXECUTABLE_SUFFIX
- Define this macro to be a C string representing the suffix to be
- automatically added to executable files on your target machine.
- If you do not define this macro, GCC will use the null string as
- the suffix for executable files.
-
- -- Macro: COLLECT_EXPORT_LIST
- If defined, `collect2' will scan the individual object files
- specified on its command line and create an export list for the
- linker. Define this macro for systems like AIX, where the linker
- discards object files that are not referenced from `main' and uses
- export lists.
-
- -- Macro: MODIFY_JNI_METHOD_CALL (MDECL)
- Define this macro to a C expression representing a variant of the
- method call MDECL, if Java Native Interface (JNI) methods must be
- invoked differently from other methods on your target. For
- example, on 32-bit Microsoft Windows, JNI methods must be invoked
- using the `stdcall' calling convention and this macro is then
- defined as this expression:
-
- build_type_attribute_variant (MDECL,
- build_tree_list
- (get_identifier ("stdcall"),
- NULL))
-
- -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void)
- This target hook returns `true' past the point in which new jump
- instructions could be created. On machines that require a
- register for every jump such as the SHmedia ISA of SH5, this point
- would typically be reload, so this target hook should be defined
- to a function such as:
-
- static bool
- cannot_modify_jumps_past_reload_p ()
- {
- return (reload_completed || reload_in_progress);
- }
-
- -- Target Hook: reg_class_t TARGET_BRANCH_TARGET_REGISTER_CLASS (void)
- This target hook returns a register class for which branch target
- register optimizations should be applied. All registers in this
- class should be usable interchangeably. After reload, registers
- in this class will be re-allocated and loads will be hoisted out
- of loops and be subjected to inter-block scheduling.
-
- -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool
- AFTER_PROLOGUE_EPILOGUE_GEN)
- Branch target register optimization will by default exclude
- callee-saved registers that are not already live during the
- current function; if this target hook returns true, they will be
- included. The target code must than make sure that all target
- registers in the class returned by
- `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are
- saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and
- epilogues have already been generated. Note, even if you only
- return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still
- are likely to have to make special provisions in
- `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved
- target registers.
-
- -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void)
- This target hook returns true if the target supports conditional
- execution. This target hook is required only when the target has
- several different modes and they have different conditional
- execution capability, such as ARM.
-
- -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL,
- struct loop *LOOP)
- This target hook returns a new value for the number of times LOOP
- should be unrolled. The parameter NUNROLL is the number of times
- the loop is to be unrolled. The parameter LOOP is a pointer to the
- loop, which is going to be checked for unrolling. This target hook
- is required only when the target has special constraints like
- maximum number of memory accesses.
-
- -- Macro: POWI_MAX_MULTS
- If defined, this macro is interpreted as a signed integer C
- expression that specifies the maximum number of floating point
- multiplications that should be emitted when expanding
- exponentiation by an integer constant inline. When this value is
- defined, exponentiation requiring more than this number of
- multiplications is implemented by calling the system library's
- `pow', `powf' or `powl' routines. The default value places no
- upper bound on the multiplication count.
-
- -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char
- *IPREFIX, int STDINC)
- This target hook should register any extra include files for the
- target. The parameter STDINC indicates if normal include files
- are present. The parameter SYSROOT is the system root directory.
- The parameter IPREFIX is the prefix for the gcc directory.
-
- -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const
- char *IPREFIX, int STDINC)
- This target hook should register any extra include files for the
- target before any standard headers. The parameter STDINC
- indicates if normal include files are present. The parameter
- SYSROOT is the system root directory. The parameter IPREFIX is
- the prefix for the gcc directory.
-
- -- Macro: void TARGET_OPTF (char *PATH)
- This target hook should register special include paths for the
- target. The parameter PATH is the include to register. On Darwin
- systems, this is used for Framework includes, which have semantics
- that are different from `-I'.
-
- -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL)
- This target macro returns `true' if it is safe to use a local alias
- for a virtual function FNDECL when constructing thunks, `false'
- otherwise. By default, the macro returns `true' for all
- functions, if a target supports aliases (i.e. defines
- `ASM_OUTPUT_DEF'), `false' otherwise,
-
- -- Macro: TARGET_FORMAT_TYPES
- If defined, this macro is the name of a global variable containing
- target-specific format checking information for the `-Wformat'
- option. The default is to have no target-specific format checks.
-
- -- Macro: TARGET_N_FORMAT_TYPES
- If defined, this macro is the number of entries in
- `TARGET_FORMAT_TYPES'.
-
- -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES
- If defined, this macro is the name of a global variable containing
- target-specific format overrides for the `-Wformat' option. The
- default is to have no target-specific format overrides. If defined,
- `TARGET_FORMAT_TYPES' must be defined, too.
-
- -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT
- If defined, this macro specifies the number of entries in
- `TARGET_OVERRIDES_FORMAT_ATTRIBUTES'.
-
- -- Macro: TARGET_OVERRIDES_FORMAT_INIT
- If defined, this macro specifies the optional initialization
- routine for target specific customizations of the system printf
- and scanf formatter settings.
-
- -- Target Hook: bool TARGET_RELAXED_ORDERING
- If set to `true', means that the target's memory model does not
- guarantee that loads which do not depend on one another will access
- main memory in the order of the instruction stream; if ordering is
- important, an explicit memory barrier must be used. This is true
- of many recent processors which implement a policy of "relaxed,"
- "weak," or "release" memory consistency, such as Alpha, PowerPC,
- and ia64. The default is `false'.
-
- -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN
- (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL)
- If defined, this macro returns the diagnostic message when it is
- illegal to pass argument VAL to function FUNCDECL with prototype
- TYPELIST.
-
- -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree
- FROMTYPE, const_tree TOTYPE)
- If defined, this macro returns the diagnostic message when it is
- invalid to convert from FROMTYPE to TOTYPE, or `NULL' if validity
- should be determined by the front end.
-
- -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP,
- const_tree TYPE)
- If defined, this macro returns the diagnostic message when it is
- invalid to apply operation OP (where unary plus is denoted by
- `CONVERT_EXPR') to an operand of type TYPE, or `NULL' if validity
- should be determined by the front end.
-
- -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP,
- const_tree TYPE1, const_tree TYPE2)
- If defined, this macro returns the diagnostic message when it is
- invalid to apply operation OP to operands of types TYPE1 and
- TYPE2, or `NULL' if validity should be determined by the front end.
-
- -- Target Hook: const char * TARGET_INVALID_PARAMETER_TYPE (const_tree
- TYPE)
- If defined, this macro returns the diagnostic message when it is
- invalid for functions to include parameters of type TYPE, or
- `NULL' if validity should be determined by the front end. This is
- currently used only by the C and C++ front ends.
-
- -- Target Hook: const char * TARGET_INVALID_RETURN_TYPE (const_tree
- TYPE)
- If defined, this macro returns the diagnostic message when it is
- invalid for functions to have return type TYPE, or `NULL' if
- validity should be determined by the front end. This is currently
- used only by the C and C++ front ends.
-
- -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE)
- If defined, this target hook returns the type to which values of
- TYPE should be promoted when they appear in expressions, analogous
- to the integer promotions, or `NULL_TREE' to use the front end's
- normal promotion rules. This hook is useful when there are
- target-specific types with special promotion rules. This is
- currently used only by the C and C++ front ends.
-
- -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR)
- If defined, this hook returns the result of converting EXPR to
- TYPE. It should return the converted expression, or `NULL_TREE'
- to apply the front end's normal conversion rules. This hook is
- useful when there are target-specific types with special
- conversion rules. This is currently used only by the C and C++
- front ends.
-
- -- Macro: TARGET_USE_JCR_SECTION
- This macro determines whether to use the JCR section to register
- Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1
- if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true,
- else 0.
-
- -- Macro: OBJC_JBLEN
- This macro determines the size of the objective C jump buffer for
- the NeXT runtime. By default, OBJC_JBLEN is defined to an
- innocuous value.
-
- -- Macro: LIBGCC2_UNWIND_ATTRIBUTE
- Define this macro if any target-specific attributes need to be
- attached to the functions in `libgcc' that provide low-level
- support for call stack unwinding. It is used in declarations in
- `unwind-generic.h' and the associated definitions of those
- functions.
-
- -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void)
- Define this macro to update the current function stack boundary if
- necessary.
-
- -- Target Hook: rtx TARGET_GET_DRAP_RTX (void)
- This hook should return an rtx for Dynamic Realign Argument
- Pointer (DRAP) if a different argument pointer register is needed
- to access the function's argument list due to stack realignment.
- Return `NULL' if no DRAP is needed.
-
- -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void)
- When optimization is disabled, this hook indicates whether or not
- arguments should be allocated to stack slots. Normally, GCC
- allocates stacks slots for arguments when not optimizing in order
- to make debugging easier. However, when a function is declared
- with `__attribute__((naked))', there is no stack frame, and the
- compiler cannot safely move arguments from the registers in which
- they are passed to the stack. Therefore, this hook should return
- true in general, but false for naked functions. The default
- implementation always returns true.
-
- -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR
- On some architectures it can take multiple instructions to
- synthesize a constant. If there is another constant already in a
- register that is close enough in value then it is preferable that
- the new constant is computed from this register using immediate
- addition or subtraction. We accomplish this through CSE. Besides
- the value of the constant we also add a lower and an upper
- constant anchor to the available expressions. These are then
- queried when encountering new constants. The anchors are computed
- by rounding the constant up and down to a multiple of the value of
- `TARGET_CONST_ANCHOR'. `TARGET_CONST_ANCHOR' should be the
- maximum positive value accepted by immediate-add plus one. We
- currently assume that the value of `TARGET_CONST_ANCHOR' is a
- power of 2. For example, on MIPS, where add-immediate takes a
- 16-bit signed value, `TARGET_CONST_ANCHOR' is set to `0x8000'.
- The default value is zero, which disables this optimization.
-
-
-File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top
-
-18 Host Configuration
-*********************
-
-Most details about the machine and system on which the compiler is
-actually running are detected by the `configure' script. Some things
-are impossible for `configure' to detect; these are described in two
-ways, either by macros defined in a file named `xm-MACHINE.h' or by
-hook functions in the file specified by the OUT_HOST_HOOK_OBJ variable
-in `config.gcc'. (The intention is that very few hosts will need a
-header file but nearly every fully supported host will need to override
-some hooks.)
-
- If you need to define only a few macros, and they have simple
-definitions, consider using the `xm_defines' variable in your
-`config.gcc' entry instead of creating a host configuration header.
-*Note System Config::.
-
-* Menu:
-
-* Host Common:: Things every host probably needs implemented.
-* Filesystem:: Your host can't have the letter `a' in filenames?
-* Host Misc:: Rare configuration options for hosts.
-
-
-File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config
-
-18.1 Host Common
-================
-
-Some things are just not portable, even between similar operating
-systems, and are too difficult for autoconf to detect. They get
-implemented using hook functions in the file specified by the
-HOST_HOOK_OBJ variable in `config.gcc'.
-
- -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void)
- This host hook is used to set up handling for extra signals. The
- most common thing to do in this hook is to detect stack overflow.
-
- -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int
- FD)
- This host hook returns the address of some space that is likely to
- be free in some subsequent invocation of the compiler. We intend
- to load the PCH data at this address such that the data need not
- be relocated. The area should be able to hold SIZE bytes. If the
- host uses `mmap', FD is an open file descriptor that can be used
- for probing.
-
- -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS,
- size_t SIZE, int FD, size_t OFFSET)
- This host hook is called when a PCH file is about to be loaded.
- We want to load SIZE bytes from FD at OFFSET into memory at
- ADDRESS. The given address will be the result of a previous
- invocation of `HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we
- couldn't allocate SIZE bytes at ADDRESS. Return 0 if the memory
- is allocated but the data is not loaded. Return 1 if the hook has
- performed everything.
-
- If the implementation uses reserved address space, free any
- reserved space beyond SIZE, regardless of the return value. If no
- PCH will be loaded, this hook may be called with SIZE zero, in
- which case all reserved address space should be freed.
-
- Do not try to handle values of ADDRESS that could not have been
- returned by this executable; just return -1. Such values usually
- indicate an out-of-date PCH file (built by some other GCC
- executable), and such a PCH file won't work.
-
- -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void);
- This host hook returns the alignment required for allocating
- virtual memory. Usually this is the same as getpagesize, but on
- some hosts the alignment for reserving memory differs from the
- pagesize for committing memory.
-
-
-File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config
-
-18.2 Host Filesystem
-====================
-
-GCC needs to know a number of things about the semantics of the host
-machine's filesystem. Filesystems with Unix and MS-DOS semantics are
-automatically detected. For other systems, you can define the
-following macros in `xm-MACHINE.h'.
-
-`HAVE_DOS_BASED_FILE_SYSTEM'
- This macro is automatically defined by `system.h' if the host file
- system obeys the semantics defined by MS-DOS instead of Unix. DOS
- file systems are case insensitive, file specifications may begin
- with a drive letter, and both forward slash and backslash (`/' and
- `\') are directory separators.
-
-`DIR_SEPARATOR'
-`DIR_SEPARATOR_2'
- If defined, these macros expand to character constants specifying
- separators for directory names within a file specification.
- `system.h' will automatically give them appropriate values on Unix
- and MS-DOS file systems. If your file system is neither of these,
- define one or both appropriately in `xm-MACHINE.h'.
-
- However, operating systems like VMS, where constructing a pathname
- is more complicated than just stringing together directory names
- separated by a special character, should not define either of these
- macros.
-
-`PATH_SEPARATOR'
- If defined, this macro should expand to a character constant
- specifying the separator for elements of search paths. The default
- value is a colon (`:'). DOS-based systems usually, but not
- always, use semicolon (`;').
-
-`VMS'
- Define this macro if the host system is VMS.
-
-`HOST_OBJECT_SUFFIX'
- Define this macro to be a C string representing the suffix for
- object files on your host machine. If you do not define this
- macro, GCC will use `.o' as the suffix for object files.
-
-`HOST_EXECUTABLE_SUFFIX'
- Define this macro to be a C string representing the suffix for
- executable files on your host machine. If you do not define this
- macro, GCC will use the null string as the suffix for executable
- files.
-
-`HOST_BIT_BUCKET'
- A pathname defined by the host operating system, which can be
- opened as a file and written to, but all the information written
- is discarded. This is commonly known as a "bit bucket" or "null
- device". If you do not define this macro, GCC will use
- `/dev/null' as the bit bucket. If the host does not support a bit
- bucket, define this macro to an invalid filename.
-
-`UPDATE_PATH_HOST_CANONICALIZE (PATH)'
- If defined, a C statement (sans semicolon) that performs
- host-dependent canonicalization when a path used in a compilation
- driver or preprocessor is canonicalized. PATH is a malloc-ed path
- to be canonicalized. If the C statement does canonicalize PATH
- into a different buffer, the old path should be freed and the new
- buffer should have been allocated with malloc.
-
-`DUMPFILE_FORMAT'
- Define this macro to be a C string representing the format to use
- for constructing the index part of debugging dump file names. The
- resultant string must fit in fifteen bytes. The full filename
- will be the concatenation of: the prefix of the assembler file
- name, the string resulting from applying this format to an index
- number, and a string unique to each dump file kind, e.g. `rtl'.
-
- If you do not define this macro, GCC will use `.%02d.'. You should
- define this macro if using the default will create an invalid file
- name.
-
-`DELETE_IF_ORDINARY'
- Define this macro to be a C statement (sans semicolon) that
- performs host-dependent removal of ordinary temp files in the
- compilation driver.
-
- If you do not define this macro, GCC will use the default version.
- You should define this macro if the default version does not
- reliably remove the temp file as, for example, on VMS which allows
- multiple versions of a file.
-
-`HOST_LACKS_INODE_NUMBERS'
- Define this macro if the host filesystem does not report
- meaningful inode numbers in struct stat.
-
-
-File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config
-
-18.3 Host Misc
-==============
-
-`FATAL_EXIT_CODE'
- A C expression for the status code to be returned when the compiler
- exits after serious errors. The default is the system-provided
- macro `EXIT_FAILURE', or `1' if the system doesn't define that
- macro. Define this macro only if these defaults are incorrect.
-
-`SUCCESS_EXIT_CODE'
- A C expression for the status code to be returned when the compiler
- exits without serious errors. (Warnings are not serious errors.)
- The default is the system-provided macro `EXIT_SUCCESS', or `0' if
- the system doesn't define that macro. Define this macro only if
- these defaults are incorrect.
-
-`USE_C_ALLOCA'
- Define this macro if GCC should use the C implementation of
- `alloca' provided by `libiberty.a'. This only affects how some
- parts of the compiler itself allocate memory. It does not change
- code generation.
-
- When GCC is built with a compiler other than itself, the C `alloca'
- is always used. This is because most other implementations have
- serious bugs. You should define this macro only on a system where
- no stack-based `alloca' can possibly work. For instance, if a
- system has a small limit on the size of the stack, GCC's builtin
- `alloca' will not work reliably.
-
-`COLLECT2_HOST_INITIALIZATION'
- If defined, a C statement (sans semicolon) that performs
- host-dependent initialization when `collect2' is being initialized.
-
-`GCC_DRIVER_HOST_INITIALIZATION'
- If defined, a C statement (sans semicolon) that performs
- host-dependent initialization when a compilation driver is being
- initialized.
-
-`HOST_LONG_LONG_FORMAT'
- If defined, the string used to indicate an argument of type `long
- long' to functions like `printf'. The default value is `"ll"'.
-
-`HOST_LONG_FORMAT'
- If defined, the string used to indicate an argument of type `long'
- to functions like `printf'. The default value is `"l"'.
-
-`HOST_PTR_PRINTF'
- If defined, the string used to indicate an argument of type `void
- *' to functions like `printf'. The default value is `"%p"'.
-
- In addition, if `configure' generates an incorrect definition of any
-of the macros in `auto-host.h', you can override that definition in a
-host configuration header. If you need to do this, first see if it is
-possible to fix `configure'.
-
-
-File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top
-
-19 Makefile Fragments
-*********************
-
-When you configure GCC using the `configure' script, it will construct
-the file `Makefile' from the template file `Makefile.in'. When it does
-this, it can incorporate makefile fragments from the `config'
-directory. These are used to set Makefile parameters that are not
-amenable to being calculated by autoconf. The list of fragments to
-incorporate is set by `config.gcc' (and occasionally `config.build' and
-`config.host'); *Note System Config::.
-
- Fragments are named either `t-TARGET' or `x-HOST', depending on
-whether they are relevant to configuring GCC to produce code for a
-particular target, or to configuring GCC to run on a particular host.
-Here TARGET and HOST are mnemonics which usually have some relationship
-to the canonical system name, but no formal connection.
-
- If these files do not exist, it means nothing needs to be added for a
-given target or host. Most targets need a few `t-TARGET' fragments,
-but needing `x-HOST' fragments is rare.
-
-* Menu:
-
-* Target Fragment:: Writing `t-TARGET' files.
-* Host Fragment:: Writing `x-HOST' files.
-
-
-File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments
-
-19.1 Target Makefile Fragments
-==============================
-
-Target makefile fragments can set these Makefile variables.
-
-`LIBGCC2_CFLAGS'
- Compiler flags to use when compiling `libgcc2.c'.
-
-`LIB2FUNCS_EXTRA'
- A list of source file names to be compiled or assembled and
- inserted into `libgcc.a'.
-
-`Floating Point Emulation'
- To have GCC include software floating point libraries in `libgcc.a'
- define `FPBIT' and `DPBIT' along with a few rules as follows:
- # We want fine grained libraries, so use the new code
- # to build the floating point emulation libraries.
- FPBIT = fp-bit.c
- DPBIT = dp-bit.c
-
-
- fp-bit.c: $(srcdir)/config/fp-bit.c
- echo '#define FLOAT' > fp-bit.c
- cat $(srcdir)/config/fp-bit.c >> fp-bit.c
-
- dp-bit.c: $(srcdir)/config/fp-bit.c
- cat $(srcdir)/config/fp-bit.c > dp-bit.c
-
- You may need to provide additional #defines at the beginning of
- `fp-bit.c' and `dp-bit.c' to control target endianness and other
- options.
-
-`CRTSTUFF_T_CFLAGS'
- Special flags used when compiling `crtstuff.c'. *Note
- Initialization::.
-
-`CRTSTUFF_T_CFLAGS_S'
- Special flags used when compiling `crtstuff.c' for shared linking.
- Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'.
- *Note Initialization::.
-
-`MULTILIB_OPTIONS'
- For some targets, invoking GCC in different ways produces objects
- that can not be linked together. For example, for some targets GCC
- produces both big and little endian code. For these targets, you
- must arrange for multiple versions of `libgcc.a' to be compiled,
- one for each set of incompatible options. When GCC invokes the
- linker, it arranges to link in the right version of `libgcc.a',
- based on the command line options used.
-
- The `MULTILIB_OPTIONS' macro lists the set of options for which
- special versions of `libgcc.a' must be built. Write options that
- are mutually incompatible side by side, separated by a slash.
- Write options that may be used together separated by a space. The
- build procedure will build all combinations of compatible options.
-
- For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020
- msoft-float', `Makefile' will build special versions of `libgcc.a'
- using the following sets of options: `-m68000', `-m68020',
- `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'.
-
-`MULTILIB_DIRNAMES'
- If `MULTILIB_OPTIONS' is used, this variable specifies the
- directory names that should be used to hold the various libraries.
- Write one element in `MULTILIB_DIRNAMES' for each element in
- `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the
- default value will be `MULTILIB_OPTIONS', with all slashes treated
- as spaces.
-
- For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020
- msoft-float', then the default value of `MULTILIB_DIRNAMES' is
- `m68000 m68020 msoft-float'. You may specify a different value if
- you desire a different set of directory names.
-
-`MULTILIB_MATCHES'
- Sometimes the same option may be written in two different ways.
- If an option is listed in `MULTILIB_OPTIONS', GCC needs to know
- about any synonyms. In that case, set `MULTILIB_MATCHES' to a
- list of items of the form `option=option' to describe all relevant
- synonyms. For example, `m68000=mc68000 m68020=mc68020'.
-
-`MULTILIB_EXCEPTIONS'
- Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being
- specified, there are combinations that should not be built. In
- that case, set `MULTILIB_EXCEPTIONS' to be all of the switch
- exceptions in shell case syntax that should not be built.
-
- For example the ARM processor cannot execute both hardware floating
- point instructions and the reduced size THUMB instructions at the
- same time, so there is no need to build libraries with both of
- these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to:
- *mthumb/*mhard-float*
-
-`MULTILIB_EXTRA_OPTS'
- Sometimes it is desirable that when building multiple versions of
- `libgcc.a' certain options should always be passed on to the
- compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list
- of options to be used for all builds. If you set this, you should
- probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it.
-
-`NATIVE_SYSTEM_HEADER_DIR'
- If the default location for system headers is not `/usr/include',
- you must set this to the directory containing the headers. This
- value should match the value of the `SYSTEM_INCLUDE_DIR' macro.
-
-`SPECS'
- Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since
- it does not affect the build of target libraries, at least not the
- build of the default multilib. One possible work-around is to use
- `DRIVER_SELF_SPECS' to bring options from the `specs' file as if
- they had been passed in the compiler driver command line.
- However, you don't want to be adding these options after the
- toolchain is installed, so you can instead tweak the `specs' file
- that will be used during the toolchain build, while you still
- install the original, built-in `specs'. The trick is to set
- `SPECS' to some other filename (say `specs.install'), that will
- then be created out of the built-in specs, and introduce a
- `Makefile' rule to generate the `specs' file that's going to be
- used at build time out of your `specs.install'.
-
-`T_CFLAGS'
- These are extra flags to pass to the C compiler. They are used
- both when building GCC, and when compiling things with the
- just-built GCC. This variable is deprecated and should not be
- used.
-
-
-File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments
-
-19.2 Host Makefile Fragments
-============================
-
-The use of `x-HOST' fragments is discouraged. You should only use it
-for makefile dependencies.
-
-
-File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top
-
-20 `collect2'
-*************
-
-GCC uses a utility called `collect2' on nearly all systems to arrange
-to call various initialization functions at start time.
-
- The program `collect2' works by linking the program once and looking
-through the linker output file for symbols with particular names
-indicating they are constructor functions. If it finds any, it creates
-a new temporary `.c' file containing a table of them, compiles it, and
-links the program a second time including that file.
-
- The actual calls to the constructors are carried out by a subroutine
-called `__main', which is called (automatically) at the beginning of
-the body of `main' (provided `main' was compiled with GNU CC). Calling
-`__main' is necessary, even when compiling C code, to allow linking C
-and C++ object code together. (If you use `-nostdlib', you get an
-unresolved reference to `__main', since it's defined in the standard
-GCC library. Include `-lgcc' at the end of your compiler command line
-to resolve this reference.)
-
- The program `collect2' is installed as `ld' in the directory where the
-passes of the compiler are installed. When `collect2' needs to find
-the _real_ `ld', it tries the following file names:
-
- * a hard coded linker file name, if GCC was configured with the
- `--with-ld' option.
-
- * `real-ld' in the directories listed in the compiler's search
- directories.
-
- * `real-ld' in the directories listed in the environment variable
- `PATH'.
-
- * The file specified in the `REAL_LD_FILE_NAME' configuration macro,
- if specified.
-
- * `ld' in the compiler's search directories, except that `collect2'
- will not execute itself recursively.
-
- * `ld' in `PATH'.
-
- "The compiler's search directories" means all the directories where
-`gcc' searches for passes of the compiler. This includes directories
-that you specify with `-B'.
-
- Cross-compilers search a little differently:
-
- * `real-ld' in the compiler's search directories.
-
- * `TARGET-real-ld' in `PATH'.
-
- * The file specified in the `REAL_LD_FILE_NAME' configuration macro,
- if specified.
-
- * `ld' in the compiler's search directories.
-
- * `TARGET-ld' in `PATH'.
-
- `collect2' explicitly avoids running `ld' using the file name under
-which `collect2' itself was invoked. In fact, it remembers up a list
-of such names--in case one copy of `collect2' finds another copy (or
-version) of `collect2' installed as `ld' in a second place in the
-search path.
-
- `collect2' searches for the utilities `nm' and `strip' using the same
-algorithm as above for `ld'.
-
-
-File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top
-
-21 Standard Header File Directories
-***********************************
-
-`GCC_INCLUDE_DIR' means the same thing for native and cross. It is
-where GCC stores its private include files, and also where GCC stores
-the fixed include files. A cross compiled GCC runs `fixincludes' on
-the header files in `$(tooldir)/include'. (If the cross compilation
-header files need to be fixed, they must be installed before GCC is
-built. If the cross compilation header files are already suitable for
-GCC, nothing special need be done).
-
- `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It
-is where `g++' looks first for header files. The C++ library installs
-only target independent header files in that directory.
-
- `LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't
-install anything there. It is normally `/usr/local/include'. This is
-where local additions to a packaged system should place header files.
-
- `CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't
-install anything there.
-
- `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is
-the place for other packages to install header files that GCC will use.
-For a cross-compiler, this is the equivalent of `/usr/include'. When
-you build a cross-compiler, `fixincludes' processes any header files in
-this directory.
-
-
-File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top
-
-22 Memory Management and Type Information
-*****************************************
-
-GCC uses some fairly sophisticated memory management techniques, which
-involve determining information about GCC's data structures from GCC's
-source code and using this information to perform garbage collection and
-implement precompiled headers.
-
- A full C parser would be too complicated for this task, so a limited
-subset of C is interpreted and special markers are used to determine
-what parts of the source to look at. All `struct' and `union'
-declarations that define data structures that are allocated under
-control of the garbage collector must be marked. All global variables
-that hold pointers to garbage-collected memory must also be marked.
-Finally, all global variables that need to be saved and restored by a
-precompiled header must be marked. (The precompiled header mechanism
-can only save static variables if they're scalar. Complex data
-structures must be allocated in garbage-collected memory to be saved in
-a precompiled header.)
-
- The full format of a marker is
- GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...))
- but in most cases no options are needed. The outer double parentheses
-are still necessary, though: `GTY(())'. Markers can appear:
-
- * In a structure definition, before the open brace;
-
- * In a global variable declaration, after the keyword `static' or
- `extern'; and
-
- * In a structure field definition, before the name of the field.
-
- Here are some examples of marking simple data structures and globals.
-
- struct GTY(()) TAG
- {
- FIELDS...
- };
-
- typedef struct GTY(()) TAG
- {
- FIELDS...
- } *TYPENAME;
-
- static GTY(()) struct TAG *LIST; /* points to GC memory */
- static GTY(()) int COUNTER; /* save counter in a PCH */
-
- The parser understands simple typedefs such as `typedef struct TAG
-*NAME;' and `typedef int NAME;'. These don't need to be marked.
-
-* Menu:
-
-* GTY Options:: What goes inside a `GTY(())'.
-* GGC Roots:: Making global variables GGC roots.
-* Files:: How the generated files work.
-* Invoking the garbage collector:: How to invoke the garbage collector.
-* Troubleshooting:: When something does not work as expected.
-
-
-File: gccint.info, Node: GTY Options, Next: GGC Roots, Up: Type Information
-
-22.1 The Inside of a `GTY(())'
-==============================
-
-Sometimes the C code is not enough to fully describe the type
-structure. Extra information can be provided with `GTY' options and
-additional markers. Some options take a parameter, which may be either
-a string or a type name, depending on the parameter. If an option
-takes no parameter, it is acceptable either to omit the parameter
-entirely, or to provide an empty string as a parameter. For example,
-`GTY ((skip))' and `GTY ((skip ("")))' are equivalent.
-
- When the parameter is a string, often it is a fragment of C code. Four
-special escapes may be used in these strings, to refer to pieces of the
-data structure being marked:
-
-`%h'
- The current structure.
-
-`%1'
- The structure that immediately contains the current structure.
-
-`%0'
- The outermost structure that contains the current structure.
-
-`%a'
- A partial expression of the form `[i1][i2]...' that indexes the
- array item currently being marked.
-
- For instance, suppose that you have a structure of the form
- struct A {
- ...
- };
- struct B {
- struct A foo[12];
- };
- and `b' is a variable of type `struct B'. When marking `b.foo[11]',
-`%h' would expand to `b.foo[11]', `%0' and `%1' would both expand to
-`b', and `%a' would expand to `[11]'.
-
- As in ordinary C, adjacent strings will be concatenated; this is
-helpful when you have a complicated expression.
- GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE"
- " ? TYPE_NEXT_VARIANT (&%h.generic)"
- " : TREE_CHAIN (&%h.generic)")))
-
- The available options are:
-
-`length ("EXPRESSION")'
- There are two places the type machinery will need to be explicitly
- told the length of an array. The first case is when a structure
- ends in a variable-length array, like this:
- struct GTY(()) rtvec_def {
- int num_elem; /* number of elements */
- rtx GTY ((length ("%h.num_elem"))) elem[1];
- };
-
- In this case, the `length' option is used to override the specified
- array length (which should usually be `1'). The parameter of the
- option is a fragment of C code that calculates the length.
-
- The second case is when a structure or a global variable contains a
- pointer to an array, like this:
- struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter;
- In this case, `iter' has been allocated by writing something like
- x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse);
- and the `collapse' provides the length of the field.
-
- This second use of `length' also works on global variables, like: static GTY((length("reg_known_value_size"))) rtx *reg_known_value;
-
-`skip'
- If `skip' is applied to a field, the type machinery will ignore it.
- This is somewhat dangerous; the only safe use is in a union when
- one field really isn't ever used.
-
-`desc ("EXPRESSION")'
-`tag ("CONSTANT")'
-`default'
- The type machinery needs to be told which field of a `union' is
- currently active. This is done by giving each field a constant
- `tag' value, and then specifying a discriminator using `desc'.
- The value of the expression given by `desc' is compared against
- each `tag' value, each of which should be different. If no `tag'
- is matched, the field marked with `default' is used if there is
- one, otherwise no field in the union will be marked.
-
- In the `desc' option, the "current structure" is the union that it
- discriminates. Use `%1' to mean the structure containing it.
- There are no escapes available to the `tag' option, since it is a
- constant.
-
- For example,
- struct GTY(()) tree_binding
- {
- struct tree_common common;
- union tree_binding_u {
- tree GTY ((tag ("0"))) scope;
- struct cp_binding_level * GTY ((tag ("1"))) level;
- } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope;
- tree value;
- };
-
- In this example, the value of BINDING_HAS_LEVEL_P when applied to a
- `struct tree_binding *' is presumed to be 0 or 1. If 1, the type
- mechanism will treat the field `level' as being present and if 0,
- will treat the field `scope' as being present.
-
-`param_is (TYPE)'
-`use_param'
- Sometimes it's convenient to define some data structure to work on
- generic pointers (that is, `PTR') and then use it with a specific
- type. `param_is' specifies the real type pointed to, and
- `use_param' says where in the generic data structure that type
- should be put.
-
- For instance, to have a `htab_t' that points to trees, one would
- write the definition of `htab_t' like this:
- typedef struct GTY(()) {
- ...
- void ** GTY ((use_param, ...)) entries;
- ...
- } htab_t;
- and then declare variables like this:
- static htab_t GTY ((param_is (union tree_node))) ict;
-
-`paramN_is (TYPE)'
-`use_paramN'
- In more complicated cases, the data structure might need to work on
- several different types, which might not necessarily all be
- pointers. For this, `param1_is' through `param9_is' may be used to
- specify the real type of a field identified by `use_param1' through
- `use_param9'.
-
-`use_params'
- When a structure contains another structure that is parameterized,
- there's no need to do anything special, the inner structure
- inherits the parameters of the outer one. When a structure
- contains a pointer to a parameterized structure, the type
- machinery won't automatically detect this (it could, it just
- doesn't yet), so it's necessary to tell it that the pointed-to
- structure should use the same parameters as the outer structure.
- This is done by marking the pointer with the `use_params' option.
-
-`deletable'
- `deletable', when applied to a global variable, indicates that when
- garbage collection runs, there's no need to mark anything pointed
- to by this variable, it can just be set to `NULL' instead. This
- is used to keep a list of free structures around for re-use.
-
-`if_marked ("EXPRESSION")'
- Suppose you want some kinds of object to be unique, and so you put
- them in a hash table. If garbage collection marks the hash table,
- these objects will never be freed, even if the last other
- reference to them goes away. GGC has special handling to deal
- with this: if you use the `if_marked' option on a global hash
- table, GGC will call the routine whose name is the parameter to
- the option on each hash table entry. If the routine returns
- nonzero, the hash table entry will be marked as usual. If the
- routine returns zero, the hash table entry will be deleted.
-
- The routine `ggc_marked_p' can be used to determine if an element
- has been marked already; in fact, the usual case is to use
- `if_marked ("ggc_marked_p")'.
-
-`mark_hook ("HOOK-ROUTINE-NAME")'
- If provided for a structure or union type, the given
- HOOK-ROUTINE-NAME (between double-quotes) is the name of a routine
- called when the garbage collector has just marked the data as
- reachable. This routine should not change the data, or call any ggc
- routine. Its only argument is a pointer to the just marked (const)
- structure or union.
-
-`maybe_undef'
- When applied to a field, `maybe_undef' indicates that it's OK if
- the structure that this fields points to is never defined, so long
- as this field is always `NULL'. This is used to avoid requiring
- backends to define certain optional structures. It doesn't work
- with language frontends.
-
-`nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")'
- The type machinery expects all pointers to point to the start of an
- object. Sometimes for abstraction purposes it's convenient to have
- a pointer which points inside an object. So long as it's possible
- to convert the original object to and from the pointer, such
- pointers can still be used. TYPE is the type of the original
- object, the TO EXPRESSION returns the pointer given the original
- object, and the FROM EXPRESSION returns the original object given
- the pointer. The pointer will be available using the `%h' escape.
-
-`chain_next ("EXPRESSION")'
-`chain_prev ("EXPRESSION")'
-`chain_circular ("EXPRESSION")'
- It's helpful for the type machinery to know if objects are often
- chained together in long lists; this lets it generate code that
- uses less stack space by iterating along the list instead of
- recursing down it. `chain_next' is an expression for the next
- item in the list, `chain_prev' is an expression for the previous
- item. For singly linked lists, use only `chain_next'; for doubly
- linked lists, use both. The machinery requires that taking the
- next item of the previous item gives the original item.
- `chain_circular' is similar to `chain_next', but can be used for
- circular single linked lists.
-
-`reorder ("FUNCTION NAME")'
- Some data structures depend on the relative ordering of pointers.
- If the precompiled header machinery needs to change that ordering,
- it will call the function referenced by the `reorder' option,
- before changing the pointers in the object that's pointed to by
- the field the option applies to. The function must take four
- arguments, with the signature
- `void *, void *, gt_pointer_operator, void *'. The first
- parameter is a pointer to the structure that contains the object
- being updated, or the object itself if there is no containing
- structure. The second parameter is a cookie that should be
- ignored. The third parameter is a routine that, given a pointer,
- will update it to its correct new value. The fourth parameter is
- a cookie that must be passed to the second parameter.
-
- PCH cannot handle data structures that depend on the absolute
- values of pointers. `reorder' functions can be expensive. When
- possible, it is better to depend on properties of the data, like
- an ID number or the hash of a string instead.
-
-`variable_size'
- The type machinery expects the types to be of constant size. When
- this is not true, for example, with structs that have array fields
- or unions, the type machinery cannot tell how many bytes need to
- be allocated at each allocation. The `variable_size' is used to
- mark such types. The type machinery then provides allocators that
- take a parameter indicating an exact size of object being
- allocated. Note that the size must be provided in bytes whereas
- the `length' option works with array lengths in number of elements.
-
- For example,
- struct GTY((variable_size)) sorted_fields_type {
- int len;
- tree GTY((length ("%h.len"))) elts[1];
- };
-
- Then the objects of `struct sorted_fields_type' are allocated in GC
- memory as follows:
- field_vec = ggc_alloc_sorted_fields_type (size);
-
- If FIELD_VEC->ELTS stores N elements, then SIZE could be
- calculated as follows:
- size_t size = sizeof (struct sorted_fields_type) + n * sizeof (tree);
-
-`special ("NAME")'
- The `special' option is used to mark types that have to be dealt
- with by special case machinery. The parameter is the name of the
- special case. See `gengtype.c' for further details. Avoid adding
- new special cases unless there is no other alternative.
-
-
-File: gccint.info, Node: GGC Roots, Next: Files, Prev: GTY Options, Up: Type Information
-
-22.2 Marking Roots for the Garbage Collector
-============================================
-
-In addition to keeping track of types, the type machinery also locates
-the global variables ("roots") that the garbage collector starts at.
-Roots must be declared using one of the following syntaxes:
-
- * `extern GTY(([OPTIONS])) TYPE NAME;'
-
- * `static GTY(([OPTIONS])) TYPE NAME;'
- The syntax
- * `GTY(([OPTIONS])) TYPE NAME;'
- is _not_ accepted. There should be an `extern' declaration of such a
-variable in a header somewhere--mark that, not the definition. Or, if
-the variable is only used in one file, make it `static'.
-
-
-File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information
-
-22.3 Source Files Containing Type Information
-=============================================
-
-Whenever you add `GTY' markers to a source file that previously had
-none, or create a new source file containing `GTY' markers, there are
-three things you need to do:
-
- 1. You need to add the file to the list of source files the type
- machinery scans. There are four cases:
-
- a. For a back-end file, this is usually done automatically; if
- not, you should add it to `target_gtfiles' in the appropriate
- port's entries in `config.gcc'.
-
- b. For files shared by all front ends, add the filename to the
- `GTFILES' variable in `Makefile.in'.
-
- c. For files that are part of one front end, add the filename to
- the `gtfiles' variable defined in the appropriate
- `config-lang.in'. For C, the file is `c-config-lang.in'.
- Headers should appear before non-headers in this list.
-
- d. For files that are part of some but not all front ends, add
- the filename to the `gtfiles' variable of _all_ the front ends
- that use it.
-
- 2. If the file was a header file, you'll need to check that it's
- included in the right place to be visible to the generated files.
- For a back-end header file, this should be done automatically.
- For a front-end header file, it needs to be included by the same
- file that includes `gtype-LANG.h'. For other header files, it
- needs to be included in `gtype-desc.c', which is a generated file,
- so add it to `ifiles' in `open_base_file' in `gengtype.c'.
-
- For source files that aren't header files, the machinery will
- generate a header file that should be included in the source file
- you just changed. The file will be called `gt-PATH.h' where PATH
- is the pathname relative to the `gcc' directory with slashes
- replaced by -, so for example the header file to be included in
- `cp/parser.c' is called `gt-cp-parser.c'. The generated header
- file should be included after everything else in the source file.
- Don't forget to mention this file as a dependency in the
- `Makefile'!
-
-
- For language frontends, there is another file that needs to be included
-somewhere. It will be called `gtype-LANG.h', where LANG is the name of
-the subdirectory the language is contained in.
-
- Plugins can add additional root tables. Run the `gengtype' utility in
-plugin mode as `gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C'
-with your plugin files PLUGIN*.C using `GTY' to generate the
-PLUGINOUT.H file. The GCC build tree is needed to be present in that
-mode.
-
-
-File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information
-
-22.4 How to invoke the garbage collector
-========================================
-
-The GCC garbage collector GGC is only invoked explicitly. In contrast
-with many other garbage collectors, it is not implicitly invoked by
-allocation routines when a lot of memory has been consumed. So the only
-way to have GGC reclaim storage it to call the `ggc_collect' function
-explicitly. This call is an expensive operation, as it may have to
-scan the entire heap. Beware that local variables (on the GCC call
-stack) are not followed by such an invocation (as many other garbage
-collectors do): you should reference all your data from static or
-external `GTY'-ed variables, and it is advised to call `ggc_collect'
-with a shallow call stack. The GGC is an exact mark and sweep garbage
-collector (so it does not scan the call stack for pointers). In
-practice GCC passes don't often call `ggc_collect' themselves, because
-it is called by the pass manager between passes.
-
- At the time of the `ggc_collect' call all pointers in the GC-marked
-structures must be valid or `NULL'. In practice this means that there
-should not be uninitialized pointer fields in the structures even if
-your code never reads or writes those fields at a particular instance.
-One way to ensure this is to use cleared versions of allocators unless
-all the fields are initialized manually immediately after allocation.
-
-
-File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information
-
-22.5 Troubleshooting the garbage collector
-==========================================
-
-With the current garbage collector implementation, most issues should
-show up as GCC compilation errors. Some of the most commonly
-encountered issues are described below.
-
- * Gengtype does not produce allocators for a `GTY'-marked type.
- Gengtype checks if there is at least one possible path from GC
- roots to at least one instance of each type before outputting
- allocators. If there is no such path, the `GTY' markers will be
- ignored and no allocators will be output. Solve this by making
- sure that there exists at least one such path. If creating it is
- unfeasible or raises a "code smell", consider if you really must
- use GC for allocating such type.
-
- * Link-time errors about undefined `gt_ggc_r_foo_bar' and
- similarly-named symbols. Check if your `foo_bar' source file has
- `#include "gt-foo_bar.h"' as its very last line.
-
-
-
-File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top
-
-23 Plugins
-**********
-
-23.1 Loading Plugins
-====================
-
-Plugins are supported on platforms that support `-ldl -rdynamic'. They
-are loaded by the compiler using `dlopen' and invoked at pre-determined
-locations in the compilation process.
-
- Plugins are loaded with
-
- `-fplugin=/path/to/NAME.so' `-fplugin-arg-NAME-KEY1[=VALUE1]'
-
- The plugin arguments are parsed by GCC and passed to respective
-plugins as key-value pairs. Multiple plugins can be invoked by
-specifying multiple `-fplugin' arguments.
-
- A plugin can be simply given by its short name (no dots or slashes).
-When simply passing `-fplugin=NAME', the plugin is loaded from the
-`plugin' directory, so `-fplugin=NAME' is the same as `-fplugin=`gcc
--print-file-name=plugin`/NAME.so', using backquote shell syntax to
-query the `plugin' directory.
-
-23.2 Plugin API
-===============
-
-Plugins are activated by the compiler at specific events as defined in
-`gcc-plugin.h'. For each event of interest, the plugin should call
-`register_callback' specifying the name of the event and address of the
-callback function that will handle that event.
-
- The header `gcc-plugin.h' must be the first gcc header to be included.
-
-23.2.1 Plugin license check
----------------------------
-
-Every plugin should define the global symbol `plugin_is_GPL_compatible'
-to assert that it has been licensed under a GPL-compatible license. If
-this symbol does not exist, the compiler will emit a fatal error and
-exit with the error message:
-
- fatal error: plugin NAME is not licensed under a GPL-compatible license
- NAME: undefined symbol: plugin_is_GPL_compatible
- compilation terminated
-
- The declared type of the symbol should be int, to match a forward
-declaration in `gcc-plugin.h' that suppresses C++ mangling. It does
-not need to be in any allocated section, though. The compiler merely
-asserts that the symbol exists in the global scope. Something like
-this is enough:
-
- int plugin_is_GPL_compatible;
-
-23.2.2 Plugin initialization
-----------------------------
-
-Every plugin should export a function called `plugin_init' that is
-called right after the plugin is loaded. This function is responsible
-for registering all the callbacks required by the plugin and do any
-other required initialization.
-
- This function is called from `compile_file' right before invoking the
-parser. The arguments to `plugin_init' are:
-
- * `plugin_info': Plugin invocation information.
-
- * `version': GCC version.
-
- The `plugin_info' struct is defined as follows:
-
- struct plugin_name_args
- {
- char *base_name; /* Short name of the plugin
- (filename without .so suffix). */
- const char *full_name; /* Path to the plugin as specified with
- -fplugin=. */
- int argc; /* Number of arguments specified with
- -fplugin-arg-.... */
- struct plugin_argument *argv; /* Array of ARGC key-value pairs. */
- const char *version; /* Version string provided by plugin. */
- const char *help; /* Help string provided by plugin. */
- }
-
- If initialization fails, `plugin_init' must return a non-zero value.
-Otherwise, it should return 0.
-
- The version of the GCC compiler loading the plugin is described by the
-following structure:
-
- struct plugin_gcc_version
- {
- const char *basever;
- const char *datestamp;
- const char *devphase;
- const char *revision;
- const char *configuration_arguments;
- };
-
- The function `plugin_default_version_check' takes two pointers to such
-structure and compare them field by field. It can be used by the
-plugin's `plugin_init' function.
-
- The version of GCC used to compile the plugin can be found in the
-symbol `gcc_version' defined in the header `plugin-version.h'. The
-recommended version check to perform looks like
-
- #include "plugin-version.h"
- ...
-
- int
- plugin_init (struct plugin_name_args *plugin_info,
- struct plugin_gcc_version *version)
- {
- if (!plugin_default_version_check (version, &gcc_version))
- return 1;
-
- }
-
- but you can also check the individual fields if you want a less strict
-check.
-
-23.2.3 Plugin callbacks
------------------------
-
-Callback functions have the following prototype:
-
- /* The prototype for a plugin callback function.
- gcc_data - event-specific data provided by GCC
- user_data - plugin-specific data provided by the plug-in. */
- typedef void (*plugin_callback_func)(void *gcc_data, void *user_data);
-
- Callbacks can be invoked at the following pre-determined events:
-
- enum plugin_event
- {
- PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */
- PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */
- PLUGIN_FINISH_UNIT, /* Useful for summary processing. */
- PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */
- PLUGIN_FINISH, /* Called before GCC exits. */
- PLUGIN_INFO, /* Information about the plugin. */
- PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */
- PLUGIN_GGC_MARKING, /* Extend the GGC marking. */
- PLUGIN_GGC_END, /* Called at end of GGC. */
- PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */
- PLUGIN_REGISTER_GGC_CACHES, /* Register an extra GGC cache table. */
- PLUGIN_ATTRIBUTES, /* Called during attribute registration */
- PLUGIN_START_UNIT, /* Called before processing a translation unit. */
- PLUGIN_PRAGMAS, /* Called during pragma registration. */
- /* Called before first pass from all_passes. */
- PLUGIN_ALL_PASSES_START,
- /* Called after last pass from all_passes. */
- PLUGIN_ALL_PASSES_END,
- /* Called before first ipa pass. */
- PLUGIN_ALL_IPA_PASSES_START,
- /* Called after last ipa pass. */
- PLUGIN_ALL_IPA_PASSES_END,
- /* Allows to override pass gate decision for current_pass. */
- PLUGIN_OVERRIDE_GATE,
- /* Called before executing a pass. */
- PLUGIN_PASS_EXECUTION,
- /* Called before executing subpasses of a GIMPLE_PASS in
- execute_ipa_pass_list. */
- PLUGIN_EARLY_GIMPLE_PASSES_START,
- /* Called after executing subpasses of a GIMPLE_PASS in
- execute_ipa_pass_list. */
- PLUGIN_EARLY_GIMPLE_PASSES_END,
- /* Called when a pass is first instantiated. */
- PLUGIN_NEW_PASS,
-
- PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback
- array. */
- };
-
- In addition, plugins can also look up the enumerator of a named event,
-and / or generate new events dynamically, by calling the function
-`get_named_event_id'.
-
- To register a callback, the plugin calls `register_callback' with the
-arguments:
-
- * `char *name': Plugin name.
-
- * `int event': The event code.
-
- * `plugin_callback_func callback': The function that handles `event'.
-
- * `void *user_data': Pointer to plugin-specific data.
-
- For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO,
-PLUGIN_REGISTER_GGC_ROOTS and PLUGIN_REGISTER_GGC_CACHES pseudo-events
-the `callback' should be null, and the `user_data' is specific.
-
- When the PLUGIN_PRAGMAS event is triggered (with a null pointer as
-data from GCC), plugins may register their own pragmas using functions
-like `c_register_pragma' or `c_register_pragma_with_expansion'.
-
-23.3 Interacting with the pass manager
-======================================
-
-There needs to be a way to add/reorder/remove passes dynamically. This
-is useful for both analysis plugins (plugging in after a certain pass
-such as CFG or an IPA pass) and optimization plugins.
-
- Basic support for inserting new passes or replacing existing passes is
-provided. A plugin registers a new pass with GCC by calling
-`register_callback' with the `PLUGIN_PASS_MANAGER_SETUP' event and a
-pointer to a `struct register_pass_info' object defined as follows
-
- enum pass_positioning_ops
- {
- PASS_POS_INSERT_AFTER, // Insert after the reference pass.
- PASS_POS_INSERT_BEFORE, // Insert before the reference pass.
- PASS_POS_REPLACE // Replace the reference pass.
- };
-
- struct register_pass_info
- {
- struct opt_pass *pass; /* New pass provided by the plugin. */
- const char *reference_pass_name; /* Name of the reference pass for hooking
- up the new pass. */
- int ref_pass_instance_number; /* Insert the pass at the specified
- instance number of the reference pass. */
- /* Do it for every instance if it is 0. */
- enum pass_positioning_ops pos_op; /* how to insert the new pass. */
- };
-
-
- /* Sample plugin code that registers a new pass. */
- int
- plugin_init (struct plugin_name_args *plugin_info,
- struct plugin_gcc_version *version)
- {
- struct register_pass_info pass_info;
-
- ...
-
- /* Code to fill in the pass_info object with new pass information. */
-
- ...
-
- /* Register the new pass. */
- register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info);
-
- ...
- }
-
-23.4 Interacting with the GCC Garbage Collector
-===============================================
-
-Some plugins may want to be informed when GGC (the GCC Garbage
-Collector) is running. They can register callbacks for the
-`PLUGIN_GGC_START' and `PLUGIN_GGC_END' events (for which the callback
-is called with a null `gcc_data') to be notified of the start or end of
-the GCC garbage collection.
-
- Some plugins may need to have GGC mark additional data. This can be
-done by registering a callback (called with a null `gcc_data') for the
-`PLUGIN_GGC_MARKING' event. Such callbacks can call the `ggc_set_mark'
-routine, preferably thru the `ggc_mark' macro (and conversely, these
-routines should usually not be used in plugins outside of the
-`PLUGIN_GGC_MARKING' event).
-
- Some plugins may need to add extra GGC root tables, e.g. to handle
-their own `GTY'-ed data. This can be done with the
-`PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the
-extra root table (of type `struct ggc_root_tab*') as `user_data'.
-Plugins that want to use the `if_marked' hash table option can add the
-extra GGC cache tables generated by `gengtype' using the
-`PLUGIN_REGISTER_GGC_CACHES' pseudo-event with a null callback and the
-extra cache table (of type `struct ggc_cache_tab*') as `user_data'.
-Running the `gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility
-generates these extra root tables.
-
- You should understand the details of memory management inside GCC
-before using `PLUGIN_GGC_MARKING', `PLUGIN_REGISTER_GGC_ROOTS' or
-`PLUGIN_REGISTER_GGC_CACHES'.
-
-23.5 Giving information about a plugin
-======================================
-
-A plugin should give some information to the user about itself. This
-uses the following structure:
-
- struct plugin_info
- {
- const char *version;
- const char *help;
- };
-
- Such a structure is passed as the `user_data' by the plugin's init
-routine using `register_callback' with the `PLUGIN_INFO' pseudo-event
-and a null callback.
-
-23.6 Registering custom attributes or pragmas
-=============================================
-
-For analysis (or other) purposes it is useful to be able to add custom
-attributes or pragmas.
-
- The `PLUGIN_ATTRIBUTES' callback is called during attribute
-registration. Use the `register_attribute' function to register custom
-attributes.
-
- /* Attribute handler callback */
- static tree
- handle_user_attribute (tree *node, tree name, tree args,
- int flags, bool *no_add_attrs)
- {
- return NULL_TREE;
- }
-
- /* Attribute definition */
- static struct attribute_spec user_attr =
- { "user", 1, 1, false, false, false, handle_user_attribute };
-
- /* Plugin callback called during attribute registration.
- Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL)
- */
- static void
- register_attributes (void *event_data, void *data)
- {
- warning (0, G_("Callback to register attributes"));
- register_attribute (&user_attr);
- }
-
- The `PLUGIN_PRAGMAS' callback is called during pragmas registration.
-Use the `c_register_pragma' or `c_register_pragma_with_expansion'
-functions to register custom pragmas.
-
- /* Plugin callback called during pragmas registration. Registered with
- register_callback (plugin_name, PLUGIN_PRAGMAS,
- register_my_pragma, NULL);
- */
- static void
- register_my_pragma (void *event_data, void *data)
- {
- warning (0, G_("Callback to register pragmas"));
- c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello);
- }
-
- It is suggested to pass `"GCCPLUGIN"' (or a short name identifying
-your plugin) as the "space" argument of your pragma.
-
-23.7 Recording information about pass execution
-===============================================
-
-The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass
-(the same as current_pass) as `gcc_data' to the callback. You can also
-inspect cfun to find out about which function this pass is executed for.
-Note that this event will only be invoked if the gate check (if
-applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use
-other hooks, like `PLUGIN_ALL_PASSES_START', `PLUGIN_ALL_PASSES_END',
-`PLUGIN_ALL_IPA_PASSES_START', `PLUGIN_ALL_IPA_PASSES_END',
-`PLUGIN_EARLY_GIMPLE_PASSES_START', and/or
-`PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your
-plugin(s) in order to get context for the pass execution.
-
-23.8 Controlling which passes are being run
-===========================================
-
-After the original gate function for a pass is called, its result - the
-gate status - is stored as an integer. Then the event
-`PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in
-the `gcc_data' parameter to the callback function. A nonzero value of
-the gate status means that the pass is to be executed. You can both
-read and write the gate status via the passed pointer.
-
-23.9 Keeping track of available passes
-======================================
-
-When your plugin is loaded, you can inspect the various pass lists to
-determine what passes are available. However, other plugins might add
-new passes. Also, future changes to GCC might cause generic passes to
-be added after plugin loading. When a pass is first added to one of
-the pass lists, the event `PLUGIN_NEW_PASS' is invoked, with the
-callback parameter `gcc_data' pointing to the new pass.
-
-23.10 Building GCC plugins
-==========================
-
-If plugins are enabled, GCC installs the headers needed to build a
-plugin (somewhere in the installation tree, e.g. under `/usr/local').
-In particular a `plugin/include' directory is installed, containing all
-the header files needed to build plugins.
-
- On most systems, you can query this `plugin' directory by invoking
-`gcc -print-file-name=plugin' (replace if needed `gcc' with the
-appropriate program path).
-
- Inside plugins, this `plugin' directory name can be queried by calling
-`default_plugin_dir_name ()'.
-
- The following GNU Makefile excerpt shows how to build a simple plugin:
-
- GCC=gcc
- PLUGIN_SOURCE_FILES= plugin1.c plugin2.c
- PLUGIN_OBJECT_FILES= $(patsubst %.c,%.o,$(PLUGIN_SOURCE_FILES))
- GCCPLUGINS_DIR:= $(shell $(GCC) -print-file-name=plugin)
- CFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -O2
-
- plugin.so: $(PLUGIN_OBJECT_FILES)
- $(GCC) -shared $^ -o $@
-
- A single source file plugin may be built with `gcc -I`gcc
--print-file-name=plugin`/include -fPIC -shared -O2 plugin.c -o
-plugin.so', using backquote shell syntax to query the `plugin'
-directory.
-
- Plugins needing to use `gengtype' require a GCC build directory for
-the same version of GCC that they will be linked against.
-
-
-File: gccint.info, Node: LTO, Next: Funding, Prev: Plugins, Up: Top
-
-24 Link Time Optimization
-*************************
-
-24.1 Design Overview
-====================
-
-Link time optimization is implemented as a GCC front end for a bytecode
-representation of GIMPLE that is emitted in special sections of `.o'
-files. Currently, LTO support is enabled in most ELF-based systems, as
-well as darwin, cygwin and mingw systems.
-
- Since GIMPLE bytecode is saved alongside final object code, object
-files generated with LTO support are larger than regular object files.
-This "fat" object format makes it easy to integrate LTO into existing
-build systems, as one can, for instance, produce archives of the files.
-Additionally, one might be able to ship one set of fat objects which
-could be used both for development and the production of optimized
-builds. A, perhaps surprising, side effect of this feature is that any
-mistake in the toolchain that leads to LTO information not being used
-(e.g. an older `libtool' calling `ld' directly). This is both an
-advantage, as the system is more robust, and a disadvantage, as the
-user is not informed that the optimization has been disabled.
-
- The current implementation only produces "fat" objects, effectively
-doubling compilation time and increasing file sizes up to 5x the
-original size. This hides the problem that some tools, such as `ar'
-and `nm', need to understand symbol tables of LTO sections. These
-tools were extended to use the plugin infrastructure, and with these
-problems solved, GCC will also support "slim" objects consisting of the
-intermediate code alone.
-
- At the highest level, LTO splits the compiler in two. The first half
-(the "writer") produces a streaming representation of all the internal
-data structures needed to optimize and generate code. This includes
-declarations, types, the callgraph and the GIMPLE representation of
-function bodies.
-
- When `-flto' is given during compilation of a source file, the pass
-manager executes all the passes in `all_lto_gen_passes'. Currently,
-this phase is composed of two IPA passes:
-
- * `pass_ipa_lto_gimple_out' This pass executes the function
- `lto_output' in `lto-streamer-out.c', which traverses the call
- graph encoding every reachable declaration, type and function.
- This generates a memory representation of all the file sections
- described below.
-
- * `pass_ipa_lto_finish_out' This pass executes the function
- `produce_asm_for_decls' in `lto-streamer-out.c', which takes the
- memory image built in the previous pass and encodes it in the
- corresponding ELF file sections.
-
- The second half of LTO support is the "reader". This is implemented
-as the GCC front end `lto1' in `lto/lto.c'. When `collect2' detects a
-link set of `.o'/`.a' files with LTO information and the `-flto' is
-enabled, it invokes `lto1' which reads the set of files and aggregates
-them into a single translation unit for optimization. The main entry
-point for the reader is `lto/lto.c':`lto_main'.
-
-24.1.1 LTO modes of operation
------------------------------
-
-One of the main goals of the GCC link-time infrastructure was to allow
-effective compilation of large programs. For this reason GCC
-implements two link-time compilation modes.
-
- 1. _LTO mode_, in which the whole program is read into the compiler
- at link-time and optimized in a similar way as if it were a single
- source-level compilation unit.
-
- 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs
- and/or a distributed compilation environment to quickly link large
- applications. WHOPR stands for WHOle Program optimizeR (not to be
- confused with the semantics of `-fwhole-program'). It partitions
- the aggregated callgraph from many different `.o' files and
- distributes the compilation of the sub-graphs to different CPUs.
-
- Note that distributed compilation is not implemented yet, but since
- the parallelism is facilitated via generating a `Makefile', it
- would be easy to implement.
-
- WHOPR splits LTO into three main stages:
- 1. Local generation (LGEN) This stage executes in parallel. Every
- file in the program is compiled into the intermediate language and
- packaged together with the local call-graph and summary
- information. This stage is the same for both the LTO and WHOPR
- compilation mode.
-
- 2. Whole Program Analysis (WPA) WPA is performed sequentially. The
- global call-graph is generated, and a global analysis procedure
- makes transformation decisions. The global call-graph is
- partitioned to facilitate parallel optimization during phase 3.
- The results of the WPA stage are stored into new object files
- which contain the partitions of program expressed in the
- intermediate language and the optimization decisions.
-
- 3. Local transformations (LTRANS) This stage executes in parallel.
- All the decisions made during phase 2 are implemented locally in
- each partitioned object file, and the final object code is
- generated. Optimizations which cannot be decided efficiently
- during the phase 2 may be performed on the local call-graph
- partitions.
-
- WHOPR can be seen as an extension of the usual LTO mode of
-compilation. In LTO, WPA and LTRANS are executed within a single
-execution of the compiler, after the whole program has been read into
-memory.
-
- When compiling in WHOPR mode, the callgraph is partitioned during the
-WPA stage. The whole program is split into a given number of
-partitions of roughly the same size. The compiler tries to minimize
-the number of references which cross partition boundaries. The main
-advantage of WHOPR is to allow the parallel execution of LTRANS stages,
-which are the most time-consuming part of the compilation process.
-Additionally, it avoids the need to load the whole program into memory.
-
-24.2 LTO file sections
-======================
-
-LTO information is stored in several ELF sections inside object files.
-Data structures and enum codes for sections are defined in
-`lto-streamer.h'.
-
- These sections are emitted from `lto-streamer-out.c' and mapped in all
-at once from `lto/lto.c':`lto_file_read'. The individual functions
-dealing with the reading/writing of each section are described below.
-
- * Command line options (`.gnu.lto_.opts')
-
- This section contains the command line options used to generate the
- object files. This is used at link time to determine the
- optimization level and other settings when they are not explicitly
- specified at the linker command line.
-
- Currently, GCC does not support combining LTO object files compiled
- with different set of the command line options into a single
- binary. At link time, the options given on the command line and
- the options saved on all the files in a link-time set are applied
- globally. No attempt is made at validating the combination of
- flags (other than the usual validation done by option processing).
- This is implemented in `lto/lto.c':`lto_read_all_file_options'.
-
- * Symbol table (`.gnu.lto_.symtab')
-
- This table replaces the ELF symbol table for functions and
- variables represented in the LTO IL. Symbols used and exported by
- the optimized assembly code of "fat" objects might not match the
- ones used and exported by the intermediate code. This table is
- necessary because the intermediate code is less optimized and thus
- requires a separate symbol table.
-
- Additionally, the binary code in the "fat" object will lack a call
- to a function, since the call was optimized out at compilation time
- after the intermediate language was streamed out. In some special
- cases, the same optimization may not happen during link-time
- optimization. This would lead to an undefined symbol if only one
- symbol table was used.
-
- The symbol table is emitted in
- `lto-streamer-out.c':`produce_symtab'.
-
- * Global declarations and types (`.gnu.lto_.decls')
-
- This section contains an intermediate language dump of all
- declarations and types required to represent the callgraph, static
- variables and top-level debug info.
-
- The contents of this section are emitted in
- `lto-streamer-out.c':`produce_asm_for_decls'. Types and symbols
- are emitted in a topological order that preserves the sharing of
- pointers when the file is read back in
- (`lto.c':`read_cgraph_and_symbols').
-
- * The callgraph (`.gnu.lto_.cgraph')
-
- This section contains the basic data structure used by the GCC
- inter-procedural optimization infrastructure. This section stores
- an annotated multi-graph which represents the functions and call
- sites as well as the variables, aliases and top-level `asm'
- statements.
-
- This section is emitted in `lto-streamer-out.c':`output_cgraph'
- and read in `lto-cgraph.c':`input_cgraph'.
-
- * IPA references (`.gnu.lto_.refs')
-
- This section contains references between function and static
- variables. It is emitted by `lto-cgraph.c':`output_refs' and read
- by `lto-cgraph.c':`input_refs'.
-
- * Function bodies (`.gnu.lto_.function_body.<name>')
-
- This section contains function bodies in the intermediate language
- representation. Every function body is in a separate section to
- allow copying of the section independently to different object
- files or reading the function on demand.
-
- Functions are emitted in `lto-streamer-out.c':`output_function'
- and read in `lto-streamer-in.c':`input_function'.
-
- * Static variable initializers (`.gnu.lto_.vars')
-
- This section contains all the symbols in the global variable pool.
- It is emitted by `lto-cgraph.c':`output_varpool' and read in
- `lto-cgraph.c':`input_cgraph'.
-
- * Summaries and optimization summaries used by IPA passes
- (`.gnu.lto_.<xxx>', where `<xxx>' is one of `jmpfuncs',
- `pureconst' or `reference')
-
- These sections are used by IPA passes that need to emit summary
- information during LTO generation to be read and aggregated at
- link time. Each pass is responsible for implementing two pass
- manager hooks: one for writing the summary and another for reading
- it in. The format of these sections is entirely up to each
- individual pass. The only requirement is that the writer and
- reader hooks agree on the format.
-
-24.3 Using summary information in IPA passes
-============================================
-
-Programs are represented internally as a _callgraph_ (a multi-graph
-where nodes are functions and edges are call sites) and a _varpool_ (a
-list of static and external variables in the program).
-
- The inter-procedural optimization is organized as a sequence of
-individual passes, which operate on the callgraph and the varpool. To
-make the implementation of WHOPR possible, every inter-procedural
-optimization pass is split into several stages that are executed at
-different times during WHOPR compilation:
-
- * LGEN time
- 1. _Generate summary_ (`generate_summary' in `struct
- ipa_opt_pass_d'). This stage analyzes every function body
- and variable initializer is examined and stores relevant
- information into a pass-specific data structure.
-
- 2. _Write summary_ (`write_summary' in `struct ipa_opt_pass_d').
- This stage writes all the pass-specific information generated
- by `generate_summary'. Summaries go into their own
- `LTO_section_*' sections that have to be declared in
- `lto-streamer.h':`enum lto_section_type'. A new section is
- created by calling `create_output_block' and data can be
- written using the `lto_output_*' routines.
-
- * WPA time
- 1. _Read summary_ (`read_summary' in `struct ipa_opt_pass_d').
- This stage reads all the pass-specific information in exactly
- the same order that it was written by `write_summary'.
-
- 2. _Execute_ (`execute' in `struct opt_pass'). This performs
- inter-procedural propagation. This must be done without
- actual access to the individual function bodies or variable
- initializers. Typically, this results in a transitive
- closure operation over the summary information of all the
- nodes in the callgraph.
-
- 3. _Write optimization summary_ (`write_optimization_summary' in
- `struct ipa_opt_pass_d'). This writes the result of the
- inter-procedural propagation into the object file. This can
- use the same data structures and helper routines used in
- `write_summary'.
-
- * LTRANS time
- 1. _Read optimization summary_ (`read_optimization_summary' in
- `struct ipa_opt_pass_d'). The counterpart to
- `write_optimization_summary'. This reads the interprocedural
- optimization decisions in exactly the same format emitted by
- `write_optimization_summary'.
-
- 2. _Transform_ (`function_transform' and `variable_transform' in
- `struct ipa_opt_pass_d'). The actual function bodies and
- variable initializers are updated based on the information
- passed down from the _Execute_ stage.
-
- The implementation of the inter-procedural passes are shared between
-LTO, WHOPR and classic non-LTO compilation.
-
- * During the traditional file-by-file mode every pass executes its
- own _Generate summary_, _Execute_, and _Transform_ stages within
- the single execution context of the compiler.
-
- * In LTO compilation mode, every pass uses _Generate summary_ and
- _Write summary_ stages at compilation time, while the _Read
- summary_, _Execute_, and _Transform_ stages are executed at link
- time.
-
- * In WHOPR mode all stages are used.
-
- To simplify development, the GCC pass manager differentiates between
-normal inter-procedural passes and small inter-procedural passes. A
-_small inter-procedural pass_ (`SIMPLE_IPA_PASS') is a pass that does
-everything at once and thus it can not be executed during WPA in WHOPR
-mode. It defines only the _Execute_ stage and during this stage it
-accesses and modifies the function bodies. Such passes are useful for
-optimization at LGEN or LTRANS time and are used, for example, to
-implement early optimization before writing object files. The simple
-inter-procedural passes can also be used for easier prototyping and
-development of a new inter-procedural pass.
-
-24.3.1 Virtual clones
----------------------
-
-One of the main challenges of introducing the WHOPR compilation mode
-was addressing the interactions between optimization passes. In LTO
-compilation mode, the passes are executed in a sequence, each of which
-consists of analysis (or _Generate summary_), propagation (or
-_Execute_) and _Transform_ stages. Once the work of one pass is
-finished, the next pass sees the updated program representation and can
-execute. This makes the individual passes dependent on each other.
-
- In WHOPR mode all passes first execute their _Generate summary_ stage.
-Then summary writing marks the end of the LGEN stage. At WPA time, the
-summaries are read back into memory and all passes run the _Execute_
-stage. Optimization summaries are streamed and sent to LTRANS, where
-all the passes execute the _Transform_ stage.
-
- Most optimization passes split naturally into analysis, propagation
-and transformation stages. But some do not. The main problem arises
-when one pass performs changes and the following pass gets confused by
-seeing different callgraphs between the _Transform_ stage and the
-_Generate summary_ or _Execute_ stage. This means that the passes are
-required to communicate their decisions with each other.
-
- To facilitate this communication, the GCC callgraph infrastructure
-implements _virtual clones_, a method of representing the changes
-performed by the optimization passes in the callgraph without needing
-to update function bodies.
-
- A _virtual clone_ in the callgraph is a function that has no
-associated body, just a description of how to create its body based on
-a different function (which itself may be a virtual clone).
-
- The description of function modifications includes adjustments to the
-function's signature (which allows, for example, removing or adding
-function arguments), substitutions to perform on the function body,
-and, for inlined functions, a pointer to the function that it will be
-inlined into.
-
- It is also possible to redirect any edge of the callgraph from a
-function to its virtual clone. This implies updating of the call site
-to adjust for the new function signature.
-
- Most of the transformations performed by inter-procedural
-optimizations can be represented via virtual clones. For instance, a
-constant propagation pass can produce a virtual clone of the function
-which replaces one of its arguments by a constant. The inliner can
-represent its decisions by producing a clone of a function whose body
-will be later integrated into a given function.
-
- Using _virtual clones_, the program can be easily updated during the
-_Execute_ stage, solving most of pass interactions problems that would
-otherwise occur during _Transform_.
-
- Virtual clones are later materialized in the LTRANS stage and turned
-into real functions. Passes executed after the virtual clone were
-introduced also perform their _Transform_ stage on new functions, so
-for a pass there is no significant difference between operating on a
-real function or a virtual clone introduced before its _Execute_ stage.
-
- Optimization passes then work on virtual clones introduced before
-their _Execute_ stage as if they were real functions. The only
-difference is that clones are not visible during the _Generate Summary_
-stage.
-
- To keep function summaries updated, the callgraph interface allows an
-optimizer to register a callback that is called every time a new clone
-is introduced as well as when the actual function or variable is
-generated or when a function or variable is removed. These hooks are
-registered in the _Generate summary_ stage and allow the pass to keep
-its information intact until the _Execute_ stage. The same hooks can
-also be registered during the _Execute_ stage to keep the optimization
-summaries updated for the _Transform_ stage.
-
-24.3.2 IPA references
----------------------
-
-GCC represents IPA references in the callgraph. For a function or
-variable `A', the _IPA reference_ is a list of all locations where the
-address of `A' is taken and, when `A' is a variable, a list of all
-direct stores and reads to/from `A'. References represent an oriented
-multi-graph on the union of nodes of the callgraph and the varpool. See
-`ipa-reference.c':`ipa_reference_write_optimization_summary' and
-`ipa-reference.c':`ipa_reference_read_optimization_summary' for details.
-
-24.3.3 Jump functions
----------------------
-
-Suppose that an optimization pass sees a function `A' and it knows the
-values of (some of) its arguments. The _jump function_ describes the
-value of a parameter of a given function call in function `A' based on
-this knowledge.
-
- Jump functions are used by several optimizations, such as the
-inter-procedural constant propagation pass and the devirtualization
-pass. The inliner also uses jump functions to perform inlining of
-callbacks.
-
-24.4 Whole program assumptions, linker plugin and symbol visibilities
-=====================================================================
-
-Link-time optimization gives relatively minor benefits when used alone.
-The problem is that propagation of inter-procedural information does
-not work well across functions and variables that are called or
-referenced by other compilation units (such as from a dynamically
-linked library). We say that such functions are variables are
-_externally visible_.
-
- To make the situation even more difficult, many applications organize
-themselves as a set of shared libraries, and the default ELF visibility
-rules allow one to overwrite any externally visible symbol with a
-different symbol at runtime. This basically disables any optimizations
-across such functions and variables, because the compiler cannot be
-sure that the function body it is seeing is the same function body that
-will be used at runtime. Any function or variable not declared
-`static' in the sources degrades the quality of inter-procedural
-optimization.
-
- To avoid this problem the compiler must assume that it sees the whole
-program when doing link-time optimization. Strictly speaking, the
-whole program is rarely visible even at link-time. Standard system
-libraries are usually linked dynamically or not provided with the
-link-time information. In GCC, the whole program option
-(`-fwhole-program') asserts that every function and variable defined in
-the current compilation unit is static, except for function `main'
-(note: at link time, the current unit is the union of all objects
-compiled with LTO). Since some functions and variables need to be
-referenced externally, for example by another DSO or from an assembler
-file, GCC also provides the function and variable attribute
-`externally_visible' which can be used to disable the effect of
-`-fwhole-program' on a specific symbol.
-
- The whole program mode assumptions are slightly more complex in C++,
-where inline functions in headers are put into _COMDAT_ sections.
-COMDAT function and variables can be defined by multiple object files
-and their bodies are unified at link-time and dynamic link-time.
-COMDAT functions are changed to local only when their address is not
-taken and thus un-sharing them with a library is not harmful. COMDAT
-variables always remain externally visible, however for readonly
-variables it is assumed that their initializers cannot be overwritten
-by a different value.
-
- GCC provides the function and variable attribute `visibility' that can
-be used to specify the visibility of externally visible symbols (or
-alternatively an `-fdefault-visibility' command line option). ELF
-defines the `default', `protected', `hidden' and `internal'
-visibilities.
-
- The most commonly used is visibility is `hidden'. It specifies that
-the symbol cannot be referenced from outside of the current shared
-library. Unfortunately, this information cannot be used directly by
-the link-time optimization in the compiler since the whole shared
-library also might contain non-LTO objects and those are not visible to
-the compiler.
-
- GCC solves this problem using linker plugins. A _linker plugin_ is an
-interface to the linker that allows an external program to claim the
-ownership of a given object file. The linker then performs the linking
-procedure by querying the plugin about the symbol table of the claimed
-objects and once the linking decisions are complete, the plugin is
-allowed to provide the final object file before the actual linking is
-made. The linker plugin obtains the symbol resolution information
-which specifies which symbols provided by the claimed objects are bound
-from the rest of a binary being linked.
-
- Currently, the linker plugin works only in combination with the Gold
-linker, but a GNU ld implementation is under development.
-
- GCC is designed to be independent of the rest of the toolchain and
-aims to support linkers without plugin support. For this reason it
-does not use the linker plugin by default. Instead, the object files
-are examined by `collect2' before being passed to the linker and
-objects found to have LTO sections are passed to `lto1' first. This
-mode does not work for library archives. The decision on what object
-files from the archive are needed depends on the actual linking and
-thus GCC would have to implement the linker itself. The resolution
-information is missing too and thus GCC needs to make an educated guess
-based on `-fwhole-program'. Without the linker plugin GCC also assumes
-that symbols are declared `hidden' and not referred by non-LTO code by
-default.
-
-24.5 Internal flags controlling `lto1'
-======================================
-
-The following flags are passed into `lto1' and are not meant to be used
-directly from the command line.
-
- * -fwpa This option runs the serial part of the link-time optimizer
- performing the inter-procedural propagation (WPA mode). The
- compiler reads in summary information from all inputs and performs
- an analysis based on summary information only. It generates
- object files for subsequent runs of the link-time optimizer where
- individual object files are optimized using both summary
- information from the WPA mode and the actual function bodies. It
- then drives the LTRANS phase.
-
- * -fltrans This option runs the link-time optimizer in the
- local-transformation (LTRANS) mode, which reads in output from a
- previous run of the LTO in WPA mode. In the LTRANS mode, LTO
- optimizes an object and produces the final assembly.
-
- * -fltrans-output-list=FILE This option specifies a file to which
- the names of LTRANS output files are written. This option is only
- meaningful in conjunction with `-fwpa'.
-
-
-File: gccint.info, Node: Funding, Next: GNU Project, Prev: LTO, Up: Top
-
-Funding Free Software
-*********************
-
-If you want to have more free software a few years from now, it makes
-sense for you to help encourage people to contribute funds for its
-development. The most effective approach known is to encourage
-commercial redistributors to donate.
-
- Users of free software systems can boost the pace of development by
-encouraging for-a-fee distributors to donate part of their selling price
-to free software developers--the Free Software Foundation, and others.
-
- The way to convince distributors to do this is to demand it and expect
-it from them. So when you compare distributors, judge them partly by
-how much they give to free software development. Show distributors
-they must compete to be the one who gives the most.
-
- To make this approach work, you must insist on numbers that you can
-compare, such as, "We will donate ten dollars to the Frobnitz project
-for each disk sold." Don't be satisfied with a vague promise, such as
-"A portion of the profits are donated," since it doesn't give a basis
-for comparison.
-
- Even a precise fraction "of the profits from this disk" is not very
-meaningful, since creative accounting and unrelated business decisions
-can greatly alter what fraction of the sales price counts as profit.
-If the price you pay is $50, ten percent of the profit is probably less
-than a dollar; it might be a few cents, or nothing at all.
-
- Some redistributors do development work themselves. This is useful
-too; but to keep everyone honest, you need to inquire how much they do,
-and what kind. Some kinds of development make much more long-term
-difference than others. For example, maintaining a separate version of
-a program contributes very little; maintaining the standard version of a
-program for the whole community contributes much. Easy new ports
-contribute little, since someone else would surely do them; difficult
-ports such as adding a new CPU to the GNU Compiler Collection
-contribute more; major new features or packages contribute the most.
-
- By establishing the idea that supporting further development is "the
-proper thing to do" when distributing free software for a fee, we can
-assure a steady flow of resources into making more free software.
-
- Copyright (C) 1994 Free Software Foundation, Inc.
- Verbatim copying and redistribution of this section is permitted
- without royalty; alteration is not permitted.
-
-
-File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top
-
-The GNU Project and GNU/Linux
-*****************************
-
-The GNU Project was launched in 1984 to develop a complete Unix-like
-operating system which is free software: the GNU system. (GNU is a
-recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".)
-Variants of the GNU operating system, which use the kernel Linux, are
-now widely used; though these systems are often referred to as "Linux",
-they are more accurately called GNU/Linux systems.
-
- For more information, see:
- `http://www.gnu.org/'
- `http://www.gnu.org/gnu/linux-and-gnu.html'
-
-
-File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top
-
-GNU General Public License
-**************************
-
- Version 3, 29 June 2007
-
- Copyright (C) 2007 Free Software Foundation, Inc. `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies of this
- license document, but changing it is not allowed.
-
-Preamble
-========
-
-The GNU General Public License is a free, copyleft license for software
-and other kinds of works.
-
- The licenses for most software and other practical works are designed
-to take away your freedom to share and change the works. By contrast,
-the GNU General Public License is intended to guarantee your freedom to
-share and change all versions of a program-to make sure it remains free
-software for all its users. We, the Free Software Foundation, use the
-GNU General Public License for most of our software; it applies also to
-any other work released this way by its authors. You can apply it to
-your programs, too.
-
- When we speak of free software, we are referring to freedom, not
-price. Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-them if you wish), that you receive source code or can get it if you
-want it, that you can change the software or use pieces of it in new
-free programs, and that you know you can do these things.
-
- To protect your rights, we need to prevent others from denying you
-these rights or asking you to surrender the rights. Therefore, you
-have certain responsibilities if you distribute copies of the software,
-or if you modify it: responsibilities to respect the freedom of others.
-
- For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must pass on to the recipients the same
-freedoms that you received. You must make sure that they, too, receive
-or can get the source code. And you must show them these terms so they
-know their rights.
-
- Developers that use the GNU GPL protect your rights with two steps:
-(1) assert copyright on the software, and (2) offer you this License
-giving you legal permission to copy, distribute and/or modify it.
-
- For the developers' and authors' protection, the GPL clearly explains
-that there is no warranty for this free software. For both users' and
-authors' sake, the GPL requires that modified versions be marked as
-changed, so that their problems will not be attributed erroneously to
-authors of previous versions.
-
- Some devices are designed to deny users access to install or run
-modified versions of the software inside them, although the
-manufacturer can do so. This is fundamentally incompatible with the
-aim of protecting users' freedom to change the software. The
-systematic pattern of such abuse occurs in the area of products for
-individuals to use, which is precisely where it is most unacceptable.
-Therefore, we have designed this version of the GPL to prohibit the
-practice for those products. If such problems arise substantially in
-other domains, we stand ready to extend this provision to those domains
-in future versions of the GPL, as needed to protect the freedom of
-users.
-
- Finally, every program is threatened constantly by software patents.
-States should not allow patents to restrict development and use of
-software on general-purpose computers, but in those that do, we wish to
-avoid the special danger that patents applied to a free program could
-make it effectively proprietary. To prevent this, the GPL assures that
-patents cannot be used to render the program non-free.
-
- The precise terms and conditions for copying, distribution and
-modification follow.
-
-TERMS AND CONDITIONS
-====================
-
- 0. Definitions.
-
- "This License" refers to version 3 of the GNU General Public
- License.
-
- "Copyright" also means copyright-like laws that apply to other
- kinds of works, such as semiconductor masks.
-
- "The Program" refers to any copyrightable work licensed under this
- License. Each licensee is addressed as "you". "Licensees" and
- "recipients" may be individuals or organizations.
-
- To "modify" a work means to copy from or adapt all or part of the
- work in a fashion requiring copyright permission, other than the
- making of an exact copy. The resulting work is called a "modified
- version" of the earlier work or a work "based on" the earlier work.
-
- A "covered work" means either the unmodified Program or a work
- based on the Program.
-
- To "propagate" a work means to do anything with it that, without
- permission, would make you directly or secondarily liable for
- infringement under applicable copyright law, except executing it
- on a computer or modifying a private copy. Propagation includes
- copying, distribution (with or without modification), making
- available to the public, and in some countries other activities as
- well.
-
- To "convey" a work means any kind of propagation that enables other
- parties to make or receive copies. Mere interaction with a user
- through a computer network, with no transfer of a copy, is not
- conveying.
-
- An interactive user interface displays "Appropriate Legal Notices"
- to the extent that it includes a convenient and prominently visible
- feature that (1) displays an appropriate copyright notice, and (2)
- tells the user that there is no warranty for the work (except to
- the extent that warranties are provided), that licensees may
- convey the work under this License, and how to view a copy of this
- License. If the interface presents a list of user commands or
- options, such as a menu, a prominent item in the list meets this
- criterion.
-
- 1. Source Code.
-
- The "source code" for a work means the preferred form of the work
- for making modifications to it. "Object code" means any
- non-source form of a work.
-
- A "Standard Interface" means an interface that either is an
- official standard defined by a recognized standards body, or, in
- the case of interfaces specified for a particular programming
- language, one that is widely used among developers working in that
- language.
-
- The "System Libraries" of an executable work include anything,
- other than the work as a whole, that (a) is included in the normal
- form of packaging a Major Component, but which is not part of that
- Major Component, and (b) serves only to enable use of the work
- with that Major Component, or to implement a Standard Interface
- for which an implementation is available to the public in source
- code form. A "Major Component", in this context, means a major
- essential component (kernel, window system, and so on) of the
- specific operating system (if any) on which the executable work
- runs, or a compiler used to produce the work, or an object code
- interpreter used to run it.
-
- The "Corresponding Source" for a work in object code form means all
- the source code needed to generate, install, and (for an executable
- work) run the object code and to modify the work, including
- scripts to control those activities. However, it does not include
- the work's System Libraries, or general-purpose tools or generally
- available free programs which are used unmodified in performing
- those activities but which are not part of the work. For example,
- Corresponding Source includes interface definition files
- associated with source files for the work, and the source code for
- shared libraries and dynamically linked subprograms that the work
- is specifically designed to require, such as by intimate data
- communication or control flow between those subprograms and other
- parts of the work.
-
- The Corresponding Source need not include anything that users can
- regenerate automatically from other parts of the Corresponding
- Source.
-
- The Corresponding Source for a work in source code form is that
- same work.
-
- 2. Basic Permissions.
-
- All rights granted under this License are granted for the term of
- copyright on the Program, and are irrevocable provided the stated
- conditions are met. This License explicitly affirms your unlimited
- permission to run the unmodified Program. The output from running
- a covered work is covered by this License only if the output,
- given its content, constitutes a covered work. This License
- acknowledges your rights of fair use or other equivalent, as
- provided by copyright law.
-
- You may make, run and propagate covered works that you do not
- convey, without conditions so long as your license otherwise
- remains in force. You may convey covered works to others for the
- sole purpose of having them make modifications exclusively for
- you, or provide you with facilities for running those works,
- provided that you comply with the terms of this License in
- conveying all material for which you do not control copyright.
- Those thus making or running the covered works for you must do so
- exclusively on your behalf, under your direction and control, on
- terms that prohibit them from making any copies of your
- copyrighted material outside their relationship with you.
-
- Conveying under any other circumstances is permitted solely under
- the conditions stated below. Sublicensing is not allowed; section
- 10 makes it unnecessary.
-
- 3. Protecting Users' Legal Rights From Anti-Circumvention Law.
-
- No covered work shall be deemed part of an effective technological
- measure under any applicable law fulfilling obligations under
- article 11 of the WIPO copyright treaty adopted on 20 December
- 1996, or similar laws prohibiting or restricting circumvention of
- such measures.
-
- When you convey a covered work, you waive any legal power to forbid
- circumvention of technological measures to the extent such
- circumvention is effected by exercising rights under this License
- with respect to the covered work, and you disclaim any intention
- to limit operation or modification of the work as a means of
- enforcing, against the work's users, your or third parties' legal
- rights to forbid circumvention of technological measures.
-
- 4. Conveying Verbatim Copies.
-
- You may convey verbatim copies of the Program's source code as you
- receive it, in any medium, provided that you conspicuously and
- appropriately publish on each copy an appropriate copyright notice;
- keep intact all notices stating that this License and any
- non-permissive terms added in accord with section 7 apply to the
- code; keep intact all notices of the absence of any warranty; and
- give all recipients a copy of this License along with the Program.
-
- You may charge any price or no price for each copy that you convey,
- and you may offer support or warranty protection for a fee.
-
- 5. Conveying Modified Source Versions.
-
- You may convey a work based on the Program, or the modifications to
- produce it from the Program, in the form of source code under the
- terms of section 4, provided that you also meet all of these
- conditions:
-
- a. The work must carry prominent notices stating that you
- modified it, and giving a relevant date.
-
- b. The work must carry prominent notices stating that it is
- released under this License and any conditions added under
- section 7. This requirement modifies the requirement in
- section 4 to "keep intact all notices".
-
- c. You must license the entire work, as a whole, under this
- License to anyone who comes into possession of a copy. This
- License will therefore apply, along with any applicable
- section 7 additional terms, to the whole of the work, and all
- its parts, regardless of how they are packaged. This License
- gives no permission to license the work in any other way, but
- it does not invalidate such permission if you have separately
- received it.
-
- d. If the work has interactive user interfaces, each must display
- Appropriate Legal Notices; however, if the Program has
- interactive interfaces that do not display Appropriate Legal
- Notices, your work need not make them do so.
-
- A compilation of a covered work with other separate and independent
- works, which are not by their nature extensions of the covered
- work, and which are not combined with it such as to form a larger
- program, in or on a volume of a storage or distribution medium, is
- called an "aggregate" if the compilation and its resulting
- copyright are not used to limit the access or legal rights of the
- compilation's users beyond what the individual works permit.
- Inclusion of a covered work in an aggregate does not cause this
- License to apply to the other parts of the aggregate.
-
- 6. Conveying Non-Source Forms.
-
- You may convey a covered work in object code form under the terms
- of sections 4 and 5, provided that you also convey the
- machine-readable Corresponding Source under the terms of this
- License, in one of these ways:
-
- a. Convey the object code in, or embodied in, a physical product
- (including a physical distribution medium), accompanied by the
- Corresponding Source fixed on a durable physical medium
- customarily used for software interchange.
-
- b. Convey the object code in, or embodied in, a physical product
- (including a physical distribution medium), accompanied by a
- written offer, valid for at least three years and valid for
- as long as you offer spare parts or customer support for that
- product model, to give anyone who possesses the object code
- either (1) a copy of the Corresponding Source for all the
- software in the product that is covered by this License, on a
- durable physical medium customarily used for software
- interchange, for a price no more than your reasonable cost of
- physically performing this conveying of source, or (2) access
- to copy the Corresponding Source from a network server at no
- charge.
-
- c. Convey individual copies of the object code with a copy of
- the written offer to provide the Corresponding Source. This
- alternative is allowed only occasionally and noncommercially,
- and only if you received the object code with such an offer,
- in accord with subsection 6b.
-
- d. Convey the object code by offering access from a designated
- place (gratis or for a charge), and offer equivalent access
- to the Corresponding Source in the same way through the same
- place at no further charge. You need not require recipients
- to copy the Corresponding Source along with the object code.
- If the place to copy the object code is a network server, the
- Corresponding Source may be on a different server (operated
- by you or a third party) that supports equivalent copying
- facilities, provided you maintain clear directions next to
- the object code saying where to find the Corresponding Source.
- Regardless of what server hosts the Corresponding Source, you
- remain obligated to ensure that it is available for as long
- as needed to satisfy these requirements.
-
- e. Convey the object code using peer-to-peer transmission,
- provided you inform other peers where the object code and
- Corresponding Source of the work are being offered to the
- general public at no charge under subsection 6d.
-
-
- A separable portion of the object code, whose source code is
- excluded from the Corresponding Source as a System Library, need
- not be included in conveying the object code work.
-
- A "User Product" is either (1) a "consumer product", which means
- any tangible personal property which is normally used for personal,
- family, or household purposes, or (2) anything designed or sold for
- incorporation into a dwelling. In determining whether a product
- is a consumer product, doubtful cases shall be resolved in favor of
- coverage. For a particular product received by a particular user,
- "normally used" refers to a typical or common use of that class of
- product, regardless of the status of the particular user or of the
- way in which the particular user actually uses, or expects or is
- expected to use, the product. A product is a consumer product
- regardless of whether the product has substantial commercial,
- industrial or non-consumer uses, unless such uses represent the
- only significant mode of use of the product.
-
- "Installation Information" for a User Product means any methods,
- procedures, authorization keys, or other information required to
- install and execute modified versions of a covered work in that
- User Product from a modified version of its Corresponding Source.
- The information must suffice to ensure that the continued
- functioning of the modified object code is in no case prevented or
- interfered with solely because modification has been made.
-
- If you convey an object code work under this section in, or with,
- or specifically for use in, a User Product, and the conveying
- occurs as part of a transaction in which the right of possession
- and use of the User Product is transferred to the recipient in
- perpetuity or for a fixed term (regardless of how the transaction
- is characterized), the Corresponding Source conveyed under this
- section must be accompanied by the Installation Information. But
- this requirement does not apply if neither you nor any third party
- retains the ability to install modified object code on the User
- Product (for example, the work has been installed in ROM).
-
- The requirement to provide Installation Information does not
- include a requirement to continue to provide support service,
- warranty, or updates for a work that has been modified or
- installed by the recipient, or for the User Product in which it
- has been modified or installed. Access to a network may be denied
- when the modification itself materially and adversely affects the
- operation of the network or violates the rules and protocols for
- communication across the network.
-
- Corresponding Source conveyed, and Installation Information
- provided, in accord with this section must be in a format that is
- publicly documented (and with an implementation available to the
- public in source code form), and must require no special password
- or key for unpacking, reading or copying.
-
- 7. Additional Terms.
-
- "Additional permissions" are terms that supplement the terms of
- this License by making exceptions from one or more of its
- conditions. Additional permissions that are applicable to the
- entire Program shall be treated as though they were included in
- this License, to the extent that they are valid under applicable
- law. If additional permissions apply only to part of the Program,
- that part may be used separately under those permissions, but the
- entire Program remains governed by this License without regard to
- the additional permissions.
-
- When you convey a copy of a covered work, you may at your option
- remove any additional permissions from that copy, or from any part
- of it. (Additional permissions may be written to require their own
- removal in certain cases when you modify the work.) You may place
- additional permissions on material, added by you to a covered work,
- for which you have or can give appropriate copyright permission.
-
- Notwithstanding any other provision of this License, for material
- you add to a covered work, you may (if authorized by the copyright
- holders of that material) supplement the terms of this License
- with terms:
-
- a. Disclaiming warranty or limiting liability differently from
- the terms of sections 15 and 16 of this License; or
-
- b. Requiring preservation of specified reasonable legal notices
- or author attributions in that material or in the Appropriate
- Legal Notices displayed by works containing it; or
-
- c. Prohibiting misrepresentation of the origin of that material,
- or requiring that modified versions of such material be
- marked in reasonable ways as different from the original
- version; or
-
- d. Limiting the use for publicity purposes of names of licensors
- or authors of the material; or
-
- e. Declining to grant rights under trademark law for use of some
- trade names, trademarks, or service marks; or
-
- f. Requiring indemnification of licensors and authors of that
- material by anyone who conveys the material (or modified
- versions of it) with contractual assumptions of liability to
- the recipient, for any liability that these contractual
- assumptions directly impose on those licensors and authors.
-
- All other non-permissive additional terms are considered "further
- restrictions" within the meaning of section 10. If the Program as
- you received it, or any part of it, contains a notice stating that
- it is governed by this License along with a term that is a further
- restriction, you may remove that term. If a license document
- contains a further restriction but permits relicensing or
- conveying under this License, you may add to a covered work
- material governed by the terms of that license document, provided
- that the further restriction does not survive such relicensing or
- conveying.
-
- If you add terms to a covered work in accord with this section, you
- must place, in the relevant source files, a statement of the
- additional terms that apply to those files, or a notice indicating
- where to find the applicable terms.
-
- Additional terms, permissive or non-permissive, may be stated in
- the form of a separately written license, or stated as exceptions;
- the above requirements apply either way.
-
- 8. Termination.
-
- You may not propagate or modify a covered work except as expressly
- provided under this License. Any attempt otherwise to propagate or
- modify it is void, and will automatically terminate your rights
- under this License (including any patent licenses granted under
- the third paragraph of section 11).
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, you do not qualify to receive new
- licenses for the same material under section 10.
-
- 9. Acceptance Not Required for Having Copies.
-
- You are not required to accept this License in order to receive or
- run a copy of the Program. Ancillary propagation of a covered work
- occurring solely as a consequence of using peer-to-peer
- transmission to receive a copy likewise does not require
- acceptance. However, nothing other than this License grants you
- permission to propagate or modify any covered work. These actions
- infringe copyright if you do not accept this License. Therefore,
- by modifying or propagating a covered work, you indicate your
- acceptance of this License to do so.
-
- 10. Automatic Licensing of Downstream Recipients.
-
- Each time you convey a covered work, the recipient automatically
- receives a license from the original licensors, to run, modify and
- propagate that work, subject to this License. You are not
- responsible for enforcing compliance by third parties with this
- License.
-
- An "entity transaction" is a transaction transferring control of an
- organization, or substantially all assets of one, or subdividing an
- organization, or merging organizations. If propagation of a
- covered work results from an entity transaction, each party to that
- transaction who receives a copy of the work also receives whatever
- licenses to the work the party's predecessor in interest had or
- could give under the previous paragraph, plus a right to
- possession of the Corresponding Source of the work from the
- predecessor in interest, if the predecessor has it or can get it
- with reasonable efforts.
-
- You may not impose any further restrictions on the exercise of the
- rights granted or affirmed under this License. For example, you
- may not impose a license fee, royalty, or other charge for
- exercise of rights granted under this License, and you may not
- initiate litigation (including a cross-claim or counterclaim in a
- lawsuit) alleging that any patent claim is infringed by making,
- using, selling, offering for sale, or importing the Program or any
- portion of it.
-
- 11. Patents.
-
- A "contributor" is a copyright holder who authorizes use under this
- License of the Program or a work on which the Program is based.
- The work thus licensed is called the contributor's "contributor
- version".
-
- A contributor's "essential patent claims" are all patent claims
- owned or controlled by the contributor, whether already acquired or
- hereafter acquired, that would be infringed by some manner,
- permitted by this License, of making, using, or selling its
- contributor version, but do not include claims that would be
- infringed only as a consequence of further modification of the
- contributor version. For purposes of this definition, "control"
- includes the right to grant patent sublicenses in a manner
- consistent with the requirements of this License.
-
- Each contributor grants you a non-exclusive, worldwide,
- royalty-free patent license under the contributor's essential
- patent claims, to make, use, sell, offer for sale, import and
- otherwise run, modify and propagate the contents of its
- contributor version.
-
- In the following three paragraphs, a "patent license" is any
- express agreement or commitment, however denominated, not to
- enforce a patent (such as an express permission to practice a
- patent or covenant not to sue for patent infringement). To
- "grant" such a patent license to a party means to make such an
- agreement or commitment not to enforce a patent against the party.
-
- If you convey a covered work, knowingly relying on a patent
- license, and the Corresponding Source of the work is not available
- for anyone to copy, free of charge and under the terms of this
- License, through a publicly available network server or other
- readily accessible means, then you must either (1) cause the
- Corresponding Source to be so available, or (2) arrange to deprive
- yourself of the benefit of the patent license for this particular
- work, or (3) arrange, in a manner consistent with the requirements
- of this License, to extend the patent license to downstream
- recipients. "Knowingly relying" means you have actual knowledge
- that, but for the patent license, your conveying the covered work
- in a country, or your recipient's use of the covered work in a
- country, would infringe one or more identifiable patents in that
- country that you have reason to believe are valid.
-
- If, pursuant to or in connection with a single transaction or
- arrangement, you convey, or propagate by procuring conveyance of, a
- covered work, and grant a patent license to some of the parties
- receiving the covered work authorizing them to use, propagate,
- modify or convey a specific copy of the covered work, then the
- patent license you grant is automatically extended to all
- recipients of the covered work and works based on it.
-
- A patent license is "discriminatory" if it does not include within
- the scope of its coverage, prohibits the exercise of, or is
- conditioned on the non-exercise of one or more of the rights that
- are specifically granted under this License. You may not convey a
- covered work if you are a party to an arrangement with a third
- party that is in the business of distributing software, under
- which you make payment to the third party based on the extent of
- your activity of conveying the work, and under which the third
- party grants, to any of the parties who would receive the covered
- work from you, a discriminatory patent license (a) in connection
- with copies of the covered work conveyed by you (or copies made
- from those copies), or (b) primarily for and in connection with
- specific products or compilations that contain the covered work,
- unless you entered into that arrangement, or that patent license
- was granted, prior to 28 March 2007.
-
- Nothing in this License shall be construed as excluding or limiting
- any implied license or other defenses to infringement that may
- otherwise be available to you under applicable patent law.
-
- 12. No Surrender of Others' Freedom.
-
- If conditions are imposed on you (whether by court order,
- agreement or otherwise) that contradict the conditions of this
- License, they do not excuse you from the conditions of this
- License. If you cannot convey a covered work so as to satisfy
- simultaneously your obligations under this License and any other
- pertinent obligations, then as a consequence you may not convey it
- at all. For example, if you agree to terms that obligate you to
- collect a royalty for further conveying from those to whom you
- convey the Program, the only way you could satisfy both those
- terms and this License would be to refrain entirely from conveying
- the Program.
-
- 13. Use with the GNU Affero General Public License.
-
- Notwithstanding any other provision of this License, you have
- permission to link or combine any covered work with a work licensed
- under version 3 of the GNU Affero General Public License into a
- single combined work, and to convey the resulting work. The terms
- of this License will continue to apply to the part which is the
- covered work, but the special requirements of the GNU Affero
- General Public License, section 13, concerning interaction through
- a network will apply to the combination as such.
-
- 14. Revised Versions of this License.
-
- The Free Software Foundation may publish revised and/or new
- versions of the GNU General Public License from time to time.
- Such new versions will be similar in spirit to the present
- version, but may differ in detail to address new problems or
- concerns.
-
- Each version is given a distinguishing version number. If the
- Program specifies that a certain numbered version of the GNU
- General Public License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that numbered version or of any later version published by the
- Free Software Foundation. If the Program does not specify a
- version number of the GNU General Public License, you may choose
- any version ever published by the Free Software Foundation.
-
- If the Program specifies that a proxy can decide which future
- versions of the GNU General Public License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Program.
-
- Later license versions may give you additional or different
- permissions. However, no additional obligations are imposed on any
- author or copyright holder as a result of your choosing to follow a
- later version.
-
- 15. Disclaimer of Warranty.
-
- THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
- APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
- COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
- WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
- INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE
- RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.
- SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
- NECESSARY SERVICING, REPAIR OR CORRECTION.
-
- 16. Limitation of Liability.
-
- IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
- WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
- AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
- FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
- CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
- THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
- BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
- PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
- PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
- THE POSSIBILITY OF SUCH DAMAGES.
-
- 17. Interpretation of Sections 15 and 16.
-
- If the disclaimer of warranty and limitation of liability provided
- above cannot be given local legal effect according to their terms,
- reviewing courts shall apply local law that most closely
- approximates an absolute waiver of all civil liability in
- connection with the Program, unless a warranty or assumption of
- liability accompanies a copy of the Program in return for a fee.
-
-
-END OF TERMS AND CONDITIONS
-===========================
-
-How to Apply These Terms to Your New Programs
-=============================================
-
-If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these
-terms.
-
- To do so, attach the following notices to the program. It is safest
-to attach them to the start of each source file to most effectively
-state the exclusion of warranty; and each file should have at least the
-"copyright" line and a pointer to where the full notice is found.
-
- ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
- Copyright (C) YEAR NAME OF AUTHOR
-
- This program is free software: you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation, either version 3 of the License, or (at
- your option) any later version.
-
- This program is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program. If not, see `http://www.gnu.org/licenses/'.
-
- Also add information on how to contact you by electronic and paper
-mail.
-
- If the program does terminal interaction, make it output a short
-notice like this when it starts in an interactive mode:
-
- PROGRAM Copyright (C) YEAR NAME OF AUTHOR
- This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
- This is free software, and you are welcome to redistribute it
- under certain conditions; type `show c' for details.
-
- The hypothetical commands `show w' and `show c' should show the
-appropriate parts of the General Public License. Of course, your
-program's commands might be different; for a GUI interface, you would
-use an "about box".
-
- You should also get your employer (if you work as a programmer) or
-school, if any, to sign a "copyright disclaimer" for the program, if
-necessary. For more information on this, and how to apply and follow
-the GNU GPL, see `http://www.gnu.org/licenses/'.
-
- The GNU General Public License does not permit incorporating your
-program into proprietary programs. If your program is a subroutine
-library, you may consider it more useful to permit linking proprietary
-applications with the library. If this is what you want to do, use the
-GNU Lesser General Public License instead of this License. But first,
-please read `http://www.gnu.org/philosophy/why-not-lgpl.html'.
-
-
-File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top
-
-GNU Free Documentation License
-******************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
-replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top
-
-Contributors to GCC
-*******************
-
-The GCC project would like to thank its many contributors. Without
-them the project would not have been nearly as successful as it has
-been. Any omissions in this list are accidental. Feel free to contact
-<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or
-some of your contributions are not listed. Please keep this list in
-alphabetical order.
-
- * Analog Devices helped implement the support for complex data types
- and iterators.
-
- * John David Anglin for threading-related fixes and improvements to
- libstdc++-v3, and the HP-UX port.
-
- * James van Artsdalen wrote the code that makes efficient use of the
- Intel 80387 register stack.
-
- * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta
- Series port.
-
- * Alasdair Baird for various bug fixes.
-
- * Giovanni Bajo for analyzing lots of complicated C++ problem
- reports.
-
- * Peter Barada for his work to improve code generation for new
- ColdFire cores.
-
- * Gerald Baumgartner added the signature extension to the C++ front
- end.
-
- * Godmar Back for his Java improvements and encouragement.
-
- * Scott Bambrough for help porting the Java compiler.
-
- * Wolfgang Bangerth for processing tons of bug reports.
-
- * Jon Beniston for his Microsoft Windows port of Java and port to
- Lattice Mico32.
-
- * Daniel Berlin for better DWARF2 support, faster/better
- optimizations, improved alias analysis, plus migrating GCC to
- Bugzilla.
-
- * Geoff Berry for his Java object serialization work and various
- patches.
-
- * Uros Bizjak for the implementation of x87 math built-in functions
- and for various middle end and i386 back end improvements and bug
- fixes.
-
- * Eric Blake for helping to make GCJ and libgcj conform to the
- specifications.
-
- * Janne Blomqvist for contributions to GNU Fortran.
-
- * Segher Boessenkool for various fixes.
-
- * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and
- other Java work.
-
- * Neil Booth for work on cpplib, lang hooks, debug hooks and other
- miscellaneous clean-ups.
-
- * Steven Bosscher for integrating the GNU Fortran front end into GCC
- and for contributing to the tree-ssa branch.
-
- * Eric Botcazou for fixing middle- and backend bugs left and right.
-
- * Per Bothner for his direction via the steering committee and
- various improvements to the infrastructure for supporting new
- languages. Chill front end implementation. Initial
- implementations of cpplib, fix-header, config.guess, libio, and
- past C++ library (libg++) maintainer. Dreaming up, designing and
- implementing much of GCJ.
-
- * Devon Bowen helped port GCC to the Tahoe.
-
- * Don Bowman for mips-vxworks contributions.
-
- * Dave Brolley for work on cpplib and Chill.
-
- * Paul Brook for work on the ARM architecture and maintaining GNU
- Fortran.
-
- * Robert Brown implemented the support for Encore 32000 systems.
-
- * Christian Bruel for improvements to local store elimination.
-
- * Herman A.J. ten Brugge for various fixes.
-
- * Joerg Brunsmann for Java compiler hacking and help with the GCJ
- FAQ.
-
- * Joe Buck for his direction via the steering committee.
-
- * Craig Burley for leadership of the G77 Fortran effort.
-
- * Stephan Buys for contributing Doxygen notes for libstdc++.
-
- * Paolo Carlini for libstdc++ work: lots of efficiency improvements
- to the C++ strings, streambufs and formatted I/O, hard detective
- work on the frustrating localization issues, and keeping up with
- the problem reports.
-
- * John Carr for his alias work, SPARC hacking, infrastructure
- improvements, previous contributions to the steering committee,
- loop optimizations, etc.
-
- * Stephane Carrez for 68HC11 and 68HC12 ports.
-
- * Steve Chamberlain for support for the Renesas SH and H8 processors
- and the PicoJava processor, and for GCJ config fixes.
-
- * Glenn Chambers for help with the GCJ FAQ.
-
- * John-Marc Chandonia for various libgcj patches.
-
- * Denis Chertykov for contributing and maintaining the AVR port, the
- first GCC port for an 8-bit architecture.
-
- * Scott Christley for his Objective-C contributions.
-
- * Eric Christopher for his Java porting help and clean-ups.
-
- * Branko Cibej for more warning contributions.
-
- * The GNU Classpath project for all of their merged runtime code.
-
- * Nick Clifton for arm, mcore, fr30, v850, m32r, rx work, `--help',
- and other random hacking.
-
- * Michael Cook for libstdc++ cleanup patches to reduce warnings.
-
- * R. Kelley Cook for making GCC buildable from a read-only directory
- as well as other miscellaneous build process and documentation
- clean-ups.
-
- * Ralf Corsepius for SH testing and minor bug fixing.
-
- * Stan Cox for care and feeding of the x86 port and lots of behind
- the scenes hacking.
-
- * Alex Crain provided changes for the 3b1.
-
- * Ian Dall for major improvements to the NS32k port.
-
- * Paul Dale for his work to add uClinux platform support to the m68k
- backend.
-
- * Dario Dariol contributed the four varieties of sample programs
- that print a copy of their source.
-
- * Russell Davidson for fstream and stringstream fixes in libstdc++.
-
- * Bud Davis for work on the G77 and GNU Fortran compilers.
-
- * Mo DeJong for GCJ and libgcj bug fixes.
-
- * DJ Delorie for the DJGPP port, build and libiberty maintenance,
- various bug fixes, and the M32C and MeP ports.
-
- * Arnaud Desitter for helping to debug GNU Fortran.
-
- * Gabriel Dos Reis for contributions to G++, contributions and
- maintenance of GCC diagnostics infrastructure, libstdc++-v3,
- including `valarray<>', `complex<>', maintaining the numerics
- library (including that pesky `<limits>' :-) and keeping
- up-to-date anything to do with numbers.
-
- * Ulrich Drepper for his work on glibc, testing of GCC using glibc,
- ISO C99 support, CFG dumping support, etc., plus support of the
- C++ runtime libraries including for all kinds of C interface
- issues, contributing and maintaining `complex<>', sanity checking
- and disbursement, configuration architecture, libio maintenance,
- and early math work.
-
- * Zdenek Dvorak for a new loop unroller and various fixes.
-
- * Michael Eager for his work on the Xilinx MicroBlaze port.
-
- * Richard Earnshaw for his ongoing work with the ARM.
-
- * David Edelsohn for his direction via the steering committee,
- ongoing work with the RS6000/PowerPC port, help cleaning up Haifa
- loop changes, doing the entire AIX port of libstdc++ with his bare
- hands, and for ensuring GCC properly keeps working on AIX.
-
- * Kevin Ediger for the floating point formatting of num_put::do_put
- in libstdc++.
-
- * Phil Edwards for libstdc++ work including configuration hackery,
- documentation maintainer, chief breaker of the web pages, the
- occasional iostream bug fix, and work on shared library symbol
- versioning.
-
- * Paul Eggert for random hacking all over GCC.
-
- * Mark Elbrecht for various DJGPP improvements, and for libstdc++
- configuration support for locales and fstream-related fixes.
-
- * Vadim Egorov for libstdc++ fixes in strings, streambufs, and
- iostreams.
-
- * Christian Ehrhardt for dealing with bug reports.
-
- * Ben Elliston for his work to move the Objective-C runtime into its
- own subdirectory and for his work on autoconf.
-
- * Revital Eres for work on the PowerPC 750CL port.
-
- * Marc Espie for OpenBSD support.
-
- * Doug Evans for much of the global optimization framework, arc,
- m32r, and SPARC work.
-
- * Christopher Faylor for his work on the Cygwin port and for caring
- and feeding the gcc.gnu.org box and saving its users tons of spam.
-
- * Fred Fish for BeOS support and Ada fixes.
-
- * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ.
-
- * Peter Gerwinski for various bug fixes and the Pascal front end.
-
- * Kaveh R. Ghazi for his direction via the steering committee,
- amazing work to make `-W -Wall -W* -Werror' useful, and
- continuously testing GCC on a plethora of platforms. Kaveh
- extends his gratitude to the CAIP Center at Rutgers University for
- providing him with computing resources to work on Free Software
- since the late 1980s.
-
- * John Gilmore for a donation to the FSF earmarked improving GNU
- Java.
-
- * Judy Goldberg for c++ contributions.
-
- * Torbjorn Granlund for various fixes and the c-torture testsuite,
- multiply- and divide-by-constant optimization, improved long long
- support, improved leaf function register allocation, and his
- direction via the steering committee.
-
- * Anthony Green for his `-Os' contributions, the moxie port, and
- Java front end work.
-
- * Stu Grossman for gdb hacking, allowing GCJ developers to debug
- Java code.
-
- * Michael K. Gschwind contributed the port to the PDP-11.
-
- * Richard Guenther for his ongoing middle-end contributions and bug
- fixes and for release management.
-
- * Ron Guilmette implemented the `protoize' and `unprotoize' tools,
- the support for Dwarf symbolic debugging information, and much of
- the support for System V Release 4. He has also worked heavily on
- the Intel 386 and 860 support.
-
- * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload
- GCSE.
-
- * Bruno Haible for improvements in the runtime overhead for EH, new
- warnings and assorted bug fixes.
-
- * Andrew Haley for his amazing Java compiler and library efforts.
-
- * Chris Hanson assisted in making GCC work on HP-UX for the 9000
- series 300.
-
- * Michael Hayes for various thankless work he's done trying to get
- the c30/c40 ports functional. Lots of loop and unroll
- improvements and fixes.
-
- * Dara Hazeghi for wading through myriads of target-specific bug
- reports.
-
- * Kate Hedstrom for staking the G77 folks with an initial testsuite.
-
- * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64
- work, loop opts, and generally fixing lots of old problems we've
- ignored for years, flow rewrite and lots of further stuff,
- including reviewing tons of patches.
-
- * Aldy Hernandez for working on the PowerPC port, SIMD support, and
- various fixes.
-
- * Nobuyuki Hikichi of Software Research Associates, Tokyo,
- contributed the support for the Sony NEWS machine.
-
- * Kazu Hirata for caring and feeding the Renesas H8/300 port and
- various fixes.
-
- * Katherine Holcomb for work on GNU Fortran.
-
- * Manfred Hollstein for his ongoing work to keep the m88k alive, lots
- of testing and bug fixing, particularly of GCC configury code.
-
- * Steve Holmgren for MachTen patches.
-
- * Jan Hubicka for his x86 port improvements.
-
- * Falk Hueffner for working on C and optimization bug reports.
-
- * Bernardo Innocenti for his m68k work, including merging of
- ColdFire improvements and uClinux support.
-
- * Christian Iseli for various bug fixes.
-
- * Kamil Iskra for general m68k hacking.
-
- * Lee Iverson for random fixes and MIPS testing.
-
- * Andreas Jaeger for testing and benchmarking of GCC and various bug
- fixes.
-
- * Jakub Jelinek for his SPARC work and sibling call optimizations as
- well as lots of bug fixes and test cases, and for improving the
- Java build system.
-
- * Janis Johnson for ia64 testing and fixes, her quality improvement
- sidetracks, and web page maintenance.
-
- * Kean Johnston for SCO OpenServer support and various fixes.
-
- * Tim Josling for the sample language treelang based originally on
- Richard Kenner's "toy" language.
-
- * Nicolai Josuttis for additional libstdc++ documentation.
-
- * Klaus Kaempf for his ongoing work to make alpha-vms a viable
- target.
-
- * Steven G. Kargl for work on GNU Fortran.
-
- * David Kashtan of SRI adapted GCC to VMS.
-
- * Ryszard Kabatek for many, many libstdc++ bug fixes and
- optimizations of strings, especially member functions, and for
- auto_ptr fixes.
-
- * Geoffrey Keating for his ongoing work to make the PPC work for
- GNU/Linux and his automatic regression tester.
-
- * Brendan Kehoe for his ongoing work with G++ and for a lot of early
- work in just about every part of libstdc++.
-
- * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
- MIL-STD-1750A.
-
- * Richard Kenner of the New York University Ultracomputer Research
- Laboratory wrote the machine descriptions for the AMD 29000, the
- DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the
- support for instruction attributes. He also made changes to
- better support RISC processors including changes to common
- subexpression elimination, strength reduction, function calling
- sequence handling, and condition code support, in addition to
- generalizing the code for frame pointer elimination and delay slot
- scheduling. Richard Kenner was also the head maintainer of GCC
- for several years.
-
- * Mumit Khan for various contributions to the Cygwin and Mingw32
- ports and maintaining binary releases for Microsoft Windows hosts,
- and for massive libstdc++ porting work to Cygwin/Mingw32.
-
- * Robin Kirkham for cpu32 support.
-
- * Mark Klein for PA improvements.
-
- * Thomas Koenig for various bug fixes.
-
- * Bruce Korb for the new and improved fixincludes code.
-
- * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3
- effort.
-
- * Charles LaBrec contributed the support for the Integrated Solutions
- 68020 system.
-
- * Asher Langton and Mike Kumbera for contributing Cray pointer
- support to GNU Fortran, and for other GNU Fortran improvements.
-
- * Jeff Law for his direction via the steering committee,
- coordinating the entire egcs project and GCC 2.95, rolling out
- snapshots and releases, handling merges from GCC2, reviewing tons
- of patches that might have fallen through the cracks else, and
- random but extensive hacking.
-
- * Marc Lehmann for his direction via the steering committee and
- helping with analysis and improvements of x86 performance.
-
- * Victor Leikehman for work on GNU Fortran.
-
- * Ted Lemon wrote parts of the RTL reader and printer.
-
- * Kriang Lerdsuwanakij for C++ improvements including template as
- template parameter support, and many C++ fixes.
-
- * Warren Levy for tremendous work on libgcj (Java Runtime Library)
- and random work on the Java front end.
-
- * Alain Lichnewsky ported GCC to the MIPS CPU.
-
- * Oskar Liljeblad for hacking on AWT and his many Java bug reports
- and patches.
-
- * Robert Lipe for OpenServer support, new testsuites, testing, etc.
-
- * Chen Liqin for various S+core related fixes/improvement, and for
- maintaining the S+core port.
-
- * Weiwen Liu for testing and various bug fixes.
-
- * Manuel Lo'pez-Iba'n~ez for improving `-Wconversion' and many other
- diagnostics fixes and improvements.
-
- * Dave Love for his ongoing work with the Fortran front end and
- runtime libraries.
-
- * Martin von Lo"wis for internal consistency checking infrastructure,
- various C++ improvements including namespace support, and tons of
- assistance with libstdc++/compiler merges.
-
- * H.J. Lu for his previous contributions to the steering committee,
- many x86 bug reports, prototype patches, and keeping the GNU/Linux
- ports working.
-
- * Greg McGary for random fixes and (someday) bounded pointers.
-
- * Andrew MacLeod for his ongoing work in building a real EH system,
- various code generation improvements, work on the global
- optimizer, etc.
-
- * Vladimir Makarov for hacking some ugly i960 problems, PowerPC
- hacking improvements to compile-time performance, overall
- knowledge and direction in the area of instruction scheduling, and
- design and implementation of the automaton based instruction
- scheduler.
-
- * Bob Manson for his behind the scenes work on dejagnu.
-
- * Philip Martin for lots of libstdc++ string and vector iterator
- fixes and improvements, and string clean up and testsuites.
-
- * All of the Mauve project contributors, for Java test code.
-
- * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements.
-
- * Adam Megacz for his work on the Microsoft Windows port of GCJ.
-
- * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS,
- powerpc, haifa, ECOFF debug support, and other assorted hacking.
-
- * Jason Merrill for his direction via the steering committee and
- leading the G++ effort.
-
- * Martin Michlmayr for testing GCC on several architectures using the
- entire Debian archive.
-
- * David Miller for his direction via the steering committee, lots of
- SPARC work, improvements in jump.c and interfacing with the Linux
- kernel developers.
-
- * Gary Miller ported GCC to Charles River Data Systems machines.
-
- * Alfred Minarik for libstdc++ string and ios bug fixes, and turning
- the entire libstdc++ testsuite namespace-compatible.
-
- * Mark Mitchell for his direction via the steering committee,
- mountains of C++ work, load/store hoisting out of loops, alias
- analysis improvements, ISO C `restrict' support, and serving as
- release manager for GCC 3.x.
-
- * Alan Modra for various GNU/Linux bits and testing.
-
- * Toon Moene for his direction via the steering committee, Fortran
- maintenance, and his ongoing work to make us make Fortran run fast.
-
- * Jason Molenda for major help in the care and feeding of all the
- services on the gcc.gnu.org (formerly egcs.cygnus.com)
- machine--mail, web services, ftp services, etc etc. Doing all
- this work on scrap paper and the backs of envelopes would have
- been... difficult.
-
- * Catherine Moore for fixing various ugly problems we have sent her
- way, including the haifa bug which was killing the Alpha & PowerPC
- Linux kernels.
-
- * Mike Moreton for his various Java patches.
-
- * David Mosberger-Tang for various Alpha improvements, and for the
- initial IA-64 port.
-
- * Stephen Moshier contributed the floating point emulator that
- assists in cross-compilation and permits support for floating
- point numbers wider than 64 bits and for ISO C99 support.
-
- * Bill Moyer for his behind the scenes work on various issues.
-
- * Philippe De Muyter for his work on the m68k port.
-
- * Joseph S. Myers for his work on the PDP-11 port, format checking
- and ISO C99 support, and continuous emphasis on (and contributions
- to) documentation.
-
- * Nathan Myers for his work on libstdc++-v3: architecture and
- authorship through the first three snapshots, including
- implementation of locale infrastructure, string, shadow C headers,
- and the initial project documentation (DESIGN, CHECKLIST, and so
- forth). Later, more work on MT-safe string and shadow headers.
-
- * Felix Natter for documentation on porting libstdc++.
-
- * Nathanael Nerode for cleaning up the configuration/build process.
-
- * NeXT, Inc. donated the front end that supports the Objective-C
- language.
-
- * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to
- the search engine setup, various documentation fixes and other
- small fixes.
-
- * Geoff Noer for his work on getting cygwin native builds working.
-
- * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance
- tracking web pages, GIMPLE tuples, and assorted fixes.
-
- * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64,
- FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and
- related infrastructure improvements.
-
- * Alexandre Oliva for various build infrastructure improvements,
- scripts and amazing testing work, including keeping libtool issues
- sane and happy.
-
- * Stefan Olsson for work on mt_alloc.
-
- * Melissa O'Neill for various NeXT fixes.
-
- * Rainer Orth for random MIPS work, including improvements to GCC's
- o32 ABI support, improvements to dejagnu's MIPS support, Java
- configuration clean-ups and porting work, and maintaining the
- IRIX, Solaris 2, and Tru64 UNIX ports.
-
- * Hartmut Penner for work on the s390 port.
-
- * Paul Petersen wrote the machine description for the Alliant FX/8.
-
- * Alexandre Petit-Bianco for implementing much of the Java compiler
- and continued Java maintainership.
-
- * Matthias Pfaller for major improvements to the NS32k port.
-
- * Gerald Pfeifer for his direction via the steering committee,
- pointing out lots of problems we need to solve, maintenance of the
- web pages, and taking care of documentation maintenance in general.
-
- * Andrew Pinski for processing bug reports by the dozen.
-
- * Ovidiu Predescu for his work on the Objective-C front end and
- runtime libraries.
-
- * Jerry Quinn for major performance improvements in C++ formatted
- I/O.
-
- * Ken Raeburn for various improvements to checker, MIPS ports and
- various cleanups in the compiler.
-
- * Rolf W. Rasmussen for hacking on AWT.
-
- * David Reese of Sun Microsystems contributed to the Solaris on
- PowerPC port.
-
- * Volker Reichelt for keeping up with the problem reports.
-
- * Joern Rennecke for maintaining the sh port, loop, regmove & reload
- hacking.
-
- * Loren J. Rittle for improvements to libstdc++-v3 including the
- FreeBSD port, threading fixes, thread-related configury changes,
- critical threading documentation, and solutions to really tricky
- I/O problems, as well as keeping GCC properly working on FreeBSD
- and continuous testing.
-
- * Craig Rodrigues for processing tons of bug reports.
-
- * Ola Ro"nnerup for work on mt_alloc.
-
- * Gavin Romig-Koch for lots of behind the scenes MIPS work.
-
- * David Ronis inspired and encouraged Craig to rewrite the G77
- documentation in texinfo format by contributing a first pass at a
- translation of the old `g77-0.5.16/f/DOC' file.
-
- * Ken Rose for fixes to GCC's delay slot filling code.
-
- * Paul Rubin wrote most of the preprocessor.
-
- * Pe'tur Runo'lfsson for major performance improvements in C++
- formatted I/O and large file support in C++ filebuf.
-
- * Chip Salzenberg for libstdc++ patches and improvements to locales,
- traits, Makefiles, libio, libtool hackery, and "long long" support.
-
- * Juha Sarlin for improvements to the H8 code generator.
-
- * Greg Satz assisted in making GCC work on HP-UX for the 9000 series
- 300.
-
- * Roger Sayle for improvements to constant folding and GCC's RTL
- optimizers as well as for fixing numerous bugs.
-
- * Bradley Schatz for his work on the GCJ FAQ.
-
- * Peter Schauer wrote the code to allow debugging to work on the
- Alpha.
-
- * William Schelter did most of the work on the Intel 80386 support.
-
- * Tobias Schlu"ter for work on GNU Fortran.
-
- * Bernd Schmidt for various code generation improvements and major
- work in the reload pass as well a serving as release manager for
- GCC 2.95.3.
-
- * Peter Schmid for constant testing of libstdc++--especially
- application testing, going above and beyond what was requested for
- the release criteria--and libstdc++ header file tweaks.
-
- * Jason Schroeder for jcf-dump patches.
-
- * Andreas Schwab for his work on the m68k port.
-
- * Lars Segerlund for work on GNU Fortran.
-
- * Dodji Seketeli for numerous C++ bug fixes and debug info
- improvements.
-
- * Joel Sherrill for his direction via the steering committee, RTEMS
- contributions and RTEMS testing.
-
- * Nathan Sidwell for many C++ fixes/improvements.
-
- * Jeffrey Siegal for helping RMS with the original design of GCC,
- some code which handles the parse tree and RTL data structures,
- constant folding and help with the original VAX & m68k ports.
-
- * Kenny Simpson for prompting libstdc++ fixes due to defect reports
- from the LWG (thereby keeping GCC in line with updates from the
- ISO).
-
- * Franz Sirl for his ongoing work with making the PPC port stable
- for GNU/Linux.
-
- * Andrey Slepuhin for assorted AIX hacking.
-
- * Trevor Smigiel for contributing the SPU port.
-
- * Christopher Smith did the port for Convex machines.
-
- * Danny Smith for his major efforts on the Mingw (and Cygwin) ports.
-
- * Randy Smith finished the Sun FPA support.
-
- * Scott Snyder for queue, iterator, istream, and string fixes and
- libstdc++ testsuite entries. Also for providing the patch to G77
- to add rudimentary support for `INTEGER*1', `INTEGER*2', and
- `LOGICAL*1'.
-
- * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
-
- * Richard Stallman, for writing the original GCC and launching the
- GNU project.
-
- * Jan Stein of the Chalmers Computer Society provided support for
- Genix, as well as part of the 32000 machine description.
-
- * Nigel Stephens for various mips16 related fixes/improvements.
-
- * Jonathan Stone wrote the machine description for the Pyramid
- computer.
-
- * Graham Stott for various infrastructure improvements.
-
- * John Stracke for his Java HTTP protocol fixes.
-
- * Mike Stump for his Elxsi port, G++ contributions over the years
- and more recently his vxworks contributions
-
- * Jeff Sturm for Java porting help, bug fixes, and encouragement.
-
- * Shigeya Suzuki for this fixes for the bsdi platforms.
-
- * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64
- support, general configury hacking, fixincludes, etc.
-
- * Holger Teutsch provided the support for the Clipper CPU.
-
- * Gary Thomas for his ongoing work to make the PPC work for
- GNU/Linux.
-
- * Philipp Thomas for random bug fixes throughout the compiler
-
- * Jason Thorpe for thread support in libstdc++ on NetBSD.
-
- * Kresten Krab Thorup wrote the run time support for the Objective-C
- language and the fantastic Java bytecode interpreter.
-
- * Michael Tiemann for random bug fixes, the first instruction
- scheduler, initial C++ support, function integration, NS32k, SPARC
- and M88k machine description work, delay slot scheduling.
-
- * Andreas Tobler for his work porting libgcj to Darwin.
-
- * Teemu Torma for thread safe exception handling support.
-
- * Leonard Tower wrote parts of the parser, RTL generator, and RTL
- definitions, and of the VAX machine description.
-
- * Daniel Towner and Hariharan Sandanagobalane contributed and
- maintain the picoChip port.
-
- * Tom Tromey for internationalization support and for his many Java
- contributions and libgcj maintainership.
-
- * Lassi Tuura for improvements to config.guess to determine HP
- processor types.
-
- * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes.
-
- * Andy Vaught for the design and initial implementation of the GNU
- Fortran front end.
-
- * Brent Verner for work with the libstdc++ cshadow files and their
- associated configure steps.
-
- * Todd Vierling for contributions for NetBSD ports.
-
- * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
- guidance.
-
- * Dean Wakerley for converting the install documentation from HTML
- to texinfo in time for GCC 3.0.
-
- * Krister Walfridsson for random bug fixes.
-
- * Feng Wang for contributions to GNU Fortran.
-
- * Stephen M. Webb for time and effort on making libstdc++ shadow
- files work with the tricky Solaris 8+ headers, and for pushing the
- build-time header tree.
-
- * John Wehle for various improvements for the x86 code generator,
- related infrastructure improvements to help x86 code generation,
- value range propagation and other work, WE32k port.
-
- * Ulrich Weigand for work on the s390 port.
-
- * Zack Weinberg for major work on cpplib and various other bug fixes.
-
- * Matt Welsh for help with Linux Threads support in GCJ.
-
- * Urban Widmark for help fixing java.io.
-
- * Mark Wielaard for new Java library code and his work integrating
- with Classpath.
-
- * Dale Wiles helped port GCC to the Tahoe.
-
- * Bob Wilson from Tensilica, Inc. for the Xtensa port.
-
- * Jim Wilson for his direction via the steering committee, tackling
- hard problems in various places that nobody else wanted to work
- on, strength reduction and other loop optimizations.
-
- * Paul Woegerer and Tal Agmon for the CRX port.
-
- * Carlo Wood for various fixes.
-
- * Tom Wood for work on the m88k port.
-
- * Canqun Yang for work on GNU Fortran.
-
- * Masanobu Yuhara of Fujitsu Laboratories implemented the machine
- description for the Tron architecture (specifically, the Gmicro).
-
- * Kevin Zachmann helped port GCC to the Tahoe.
-
- * Ayal Zaks for Swing Modulo Scheduling (SMS).
-
- * Xiaoqiang Zhang for work on GNU Fortran.
-
- * Gilles Zunino for help porting Java to Irix.
-
-
- The following people are recognized for their contributions to GNAT,
-the Ada front end of GCC:
- * Bernard Banner
-
- * Romain Berrendonner
-
- * Geert Bosch
-
- * Emmanuel Briot
-
- * Joel Brobecker
-
- * Ben Brosgol
-
- * Vincent Celier
-
- * Arnaud Charlet
-
- * Chien Chieng
-
- * Cyrille Comar
-
- * Cyrille Crozes
-
- * Robert Dewar
-
- * Gary Dismukes
-
- * Robert Duff
-
- * Ed Falis
-
- * Ramon Fernandez
-
- * Sam Figueroa
-
- * Vasiliy Fofanov
-
- * Michael Friess
-
- * Franco Gasperoni
-
- * Ted Giering
-
- * Matthew Gingell
-
- * Laurent Guerby
-
- * Jerome Guitton
-
- * Olivier Hainque
-
- * Jerome Hugues
-
- * Hristian Kirtchev
-
- * Jerome Lambourg
-
- * Bruno Leclerc
-
- * Albert Lee
-
- * Sean McNeil
-
- * Javier Miranda
-
- * Laurent Nana
-
- * Pascal Obry
-
- * Dong-Ik Oh
-
- * Laurent Pautet
-
- * Brett Porter
-
- * Thomas Quinot
-
- * Nicolas Roche
-
- * Pat Rogers
-
- * Jose Ruiz
-
- * Douglas Rupp
-
- * Sergey Rybin
-
- * Gail Schenker
-
- * Ed Schonberg
-
- * Nicolas Setton
-
- * Samuel Tardieu
-
-
- The following people are recognized for their contributions of new
-features, bug reports, testing and integration of classpath/libgcj for
-GCC version 4.1:
- * Lillian Angel for `JTree' implementation and lots Free Swing
- additions and bug fixes.
-
- * Wolfgang Baer for `GapContent' bug fixes.
-
- * Anthony Balkissoon for `JList', Free Swing 1.5 updates and mouse
- event fixes, lots of Free Swing work including `JTable' editing.
-
- * Stuart Ballard for RMI constant fixes.
-
- * Goffredo Baroncelli for `HTTPURLConnection' fixes.
-
- * Gary Benson for `MessageFormat' fixes.
-
- * Daniel Bonniot for `Serialization' fixes.
-
- * Chris Burdess for lots of gnu.xml and http protocol fixes, `StAX'
- and `DOM xml:id' support.
-
- * Ka-Hing Cheung for `TreePath' and `TreeSelection' fixes.
-
- * Archie Cobbs for build fixes, VM interface updates,
- `URLClassLoader' updates.
-
- * Kelley Cook for build fixes.
-
- * Martin Cordova for Suggestions for better `SocketTimeoutException'.
-
- * David Daney for `BitSet' bug fixes, `HttpURLConnection' rewrite
- and improvements.
-
- * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo
- 2D support. Lots of imageio framework additions, lots of AWT and
- Free Swing bug fixes.
-
- * Jeroen Frijters for `ClassLoader' and nio cleanups, serialization
- fixes, better `Proxy' support, bug fixes and IKVM integration.
-
- * Santiago Gala for `AccessControlContext' fixes.
-
- * Nicolas Geoffray for `VMClassLoader' and `AccessController'
- improvements.
-
- * David Gilbert for `basic' and `metal' icon and plaf support and
- lots of documenting, Lots of Free Swing and metal theme additions.
- `MetalIconFactory' implementation.
-
- * Anthony Green for `MIDI' framework, `ALSA' and `DSSI' providers.
-
- * Andrew Haley for `Serialization' and `URLClassLoader' fixes, gcj
- build speedups.
-
- * Kim Ho for `JFileChooser' implementation.
-
- * Andrew John Hughes for `Locale' and net fixes, URI RFC2986
- updates, `Serialization' fixes, `Properties' XML support and
- generic branch work, VMIntegration guide update.
-
- * Bastiaan Huisman for `TimeZone' bug fixing.
-
- * Andreas Jaeger for mprec updates.
-
- * Paul Jenner for better `-Werror' support.
-
- * Ito Kazumitsu for `NetworkInterface' implementation and updates.
-
- * Roman Kennke for `BoxLayout', `GrayFilter' and `SplitPane', plus
- bug fixes all over. Lots of Free Swing work including styled text.
-
- * Simon Kitching for `String' cleanups and optimization suggestions.
-
- * Michael Koch for configuration fixes, `Locale' updates, bug and
- build fixes.
-
- * Guilhem Lavaux for configuration, thread and channel fixes and
- Kaffe integration. JCL native `Pointer' updates. Logger bug fixes.
-
- * David Lichteblau for JCL support library global/local reference
- cleanups.
-
- * Aaron Luchko for JDWP updates and documentation fixes.
-
- * Ziga Mahkovec for `Graphics2D' upgraded to Cairo 0.5 and new regex
- features.
-
- * Sven de Marothy for BMP imageio support, CSS and `TextLayout'
- fixes. `GtkImage' rewrite, 2D, awt, free swing and date/time fixes
- and implementing the Qt4 peers.
-
- * Casey Marshall for crypto algorithm fixes, `FileChannel' lock,
- `SystemLogger' and `FileHandler' rotate implementations, NIO
- `FileChannel.map' support, security and policy updates.
-
- * Bryce McKinlay for RMI work.
-
- * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus
- testing and documenting.
-
- * Kalle Olavi Niemitalo for build fixes.
-
- * Rainer Orth for build fixes.
-
- * Andrew Overholt for `File' locking fixes.
-
- * Ingo Proetel for `Image', `Logger' and `URLClassLoader' updates.
-
- * Olga Rodimina for `MenuSelectionManager' implementation.
-
- * Jan Roehrich for `BasicTreeUI' and `JTree' fixes.
-
- * Julian Scheid for documentation updates and gjdoc support.
-
- * Christian Schlichtherle for zip fixes and cleanups.
-
- * Robert Schuster for documentation updates and beans fixes,
- `TreeNode' enumerations and `ActionCommand' and various fixes, XML
- and URL, AWT and Free Swing bug fixes.
-
- * Keith Seitz for lots of JDWP work.
-
- * Christian Thalinger for 64-bit cleanups, Configuration and VM
- interface fixes and `CACAO' integration, `fdlibm' updates.
-
- * Gael Thomas for `VMClassLoader' boot packages support suggestions.
-
- * Andreas Tobler for Darwin and Solaris testing and fixing, `Qt4'
- support for Darwin/OS X, `Graphics2D' support, `gtk+' updates.
-
- * Dalibor Topic for better `DEBUG' support, build cleanups and Kaffe
- integration. `Qt4' build infrastructure, `SHA1PRNG' and
- `GdkPixbugDecoder' updates.
-
- * Tom Tromey for Eclipse integration, generics work, lots of bug
- fixes and gcj integration including coordinating The Big Merge.
-
- * Mark Wielaard for bug fixes, packaging and release management,
- `Clipboard' implementation, system call interrupts and network
- timeouts and `GdkPixpufDecoder' fixes.
-
-
- In addition to the above, all of which also contributed time and
-energy in testing GCC, we would like to thank the following for their
-contributions to testing:
-
- * Michael Abd-El-Malek
-
- * Thomas Arend
-
- * Bonzo Armstrong
-
- * Steven Ashe
-
- * Chris Baldwin
-
- * David Billinghurst
-
- * Jim Blandy
-
- * Stephane Bortzmeyer
-
- * Horst von Brand
-
- * Frank Braun
-
- * Rodney Brown
-
- * Sidney Cadot
-
- * Bradford Castalia
-
- * Robert Clark
-
- * Jonathan Corbet
-
- * Ralph Doncaster
-
- * Richard Emberson
-
- * Levente Farkas
-
- * Graham Fawcett
-
- * Mark Fernyhough
-
- * Robert A. French
-
- * Jo"rgen Freyh
-
- * Mark K. Gardner
-
- * Charles-Antoine Gauthier
-
- * Yung Shing Gene
-
- * David Gilbert
-
- * Simon Gornall
-
- * Fred Gray
-
- * John Griffin
-
- * Patrik Hagglund
-
- * Phil Hargett
-
- * Amancio Hasty
-
- * Takafumi Hayashi
-
- * Bryan W. Headley
-
- * Kevin B. Hendricks
-
- * Joep Jansen
-
- * Christian Joensson
-
- * Michel Kern
-
- * David Kidd
-
- * Tobias Kuipers
-
- * Anand Krishnaswamy
-
- * A. O. V. Le Blanc
-
- * llewelly
-
- * Damon Love
-
- * Brad Lucier
-
- * Matthias Klose
-
- * Martin Knoblauch
-
- * Rick Lutowski
-
- * Jesse Macnish
-
- * Stefan Morrell
-
- * Anon A. Mous
-
- * Matthias Mueller
-
- * Pekka Nikander
-
- * Rick Niles
-
- * Jon Olson
-
- * Magnus Persson
-
- * Chris Pollard
-
- * Richard Polton
-
- * Derk Reefman
-
- * David Rees
-
- * Paul Reilly
-
- * Tom Reilly
-
- * Torsten Rueger
-
- * Danny Sadinoff
-
- * Marc Schifer
-
- * Erik Schnetter
-
- * Wayne K. Schroll
-
- * David Schuler
-
- * Vin Shelton
-
- * Tim Souder
-
- * Adam Sulmicki
-
- * Bill Thorson
-
- * George Talbot
-
- * Pedro A. M. Vazquez
-
- * Gregory Warnes
-
- * Ian Watson
-
- * David E. Young
-
- * And many others
-
- And finally we'd like to thank everyone who uses the compiler, provides
-feedback and generally reminds us why we're doing this work in the first
-place.
-
-
-File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top
-
-Option Index
-************
-
-GCC's command line options are indexed here without any initial `-' or
-`--'. Where an option has both positive and negative forms (such as
-`-fOPTION' and `-fno-OPTION'), relevant entries in the manual are
-indexed under the most appropriate form; it may sometimes be useful to
-look up both forms.
-
-
-* Menu:
-
-* fltrans: LTO. (line 499)
-* fltrans-output-list: LTO. (line 504)
-* fwpa: LTO. (line 490)
-* msoft-float: Soft float library routines.
- (line 6)
-
-
-File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top
-
-Concept Index
-*************
-
-
-* Menu:
-
-* ! in constraint: Multi-Alternative. (line 47)
-* # in constraint: Modifiers. (line 67)
-* # in template: Output Template. (line 66)
-* #pragma: Misc. (line 381)
-* % in constraint: Modifiers. (line 45)
-* % in GTY option: GTY Options. (line 18)
-* % in template: Output Template. (line 6)
-* & in constraint: Modifiers. (line 25)
-* (nil): RTL Objects. (line 73)
-* * in constraint: Modifiers. (line 72)
-* * in template: Output Statement. (line 29)
-* + in constraint: Modifiers. (line 12)
-* -fsection-anchors <1>: Anchored Addresses. (line 6)
-* -fsection-anchors: Special Accessors. (line 110)
-* /c in RTL dump: Flags. (line 239)
-* /f in RTL dump: Flags. (line 247)
-* /i in RTL dump: Flags. (line 299)
-* /j in RTL dump: Flags. (line 314)
-* /s in RTL dump: Flags. (line 263)
-* /u in RTL dump: Flags. (line 324)
-* /v in RTL dump: Flags. (line 356)
-* 0 in constraint: Simple Constraints. (line 130)
-* < in constraint: Simple Constraints. (line 48)
-* = in constraint: Modifiers. (line 8)
-* > in constraint: Simple Constraints. (line 61)
-* ? in constraint: Multi-Alternative. (line 41)
-* \: Output Template. (line 46)
-* __absvdi2: Integer library routines.
- (line 107)
-* __absvsi2: Integer library routines.
- (line 106)
-* __addda3: Fixed-point fractional library routines.
- (line 45)
-* __adddf3: Soft float library routines.
- (line 23)
-* __adddq3: Fixed-point fractional library routines.
- (line 33)
-* __addha3: Fixed-point fractional library routines.
- (line 43)
-* __addhq3: Fixed-point fractional library routines.
- (line 30)
-* __addqq3: Fixed-point fractional library routines.
- (line 29)
-* __addsa3: Fixed-point fractional library routines.
- (line 44)
-* __addsf3: Soft float library routines.
- (line 22)
-* __addsq3: Fixed-point fractional library routines.
- (line 31)
-* __addta3: Fixed-point fractional library routines.
- (line 47)
-* __addtf3: Soft float library routines.
- (line 25)
-* __adduda3: Fixed-point fractional library routines.
- (line 53)
-* __addudq3: Fixed-point fractional library routines.
- (line 41)
-* __adduha3: Fixed-point fractional library routines.
- (line 49)
-* __adduhq3: Fixed-point fractional library routines.
- (line 37)
-* __adduqq3: Fixed-point fractional library routines.
- (line 35)
-* __addusa3: Fixed-point fractional library routines.
- (line 51)
-* __addusq3: Fixed-point fractional library routines.
- (line 39)
-* __adduta3: Fixed-point fractional library routines.
- (line 55)
-* __addvdi3: Integer library routines.
- (line 111)
-* __addvsi3: Integer library routines.
- (line 110)
-* __addxf3: Soft float library routines.
- (line 27)
-* __ashlda3: Fixed-point fractional library routines.
- (line 351)
-* __ashldi3: Integer library routines.
- (line 14)
-* __ashldq3: Fixed-point fractional library routines.
- (line 340)
-* __ashlha3: Fixed-point fractional library routines.
- (line 349)
-* __ashlhq3: Fixed-point fractional library routines.
- (line 337)
-* __ashlqq3: Fixed-point fractional library routines.
- (line 336)
-* __ashlsa3: Fixed-point fractional library routines.
- (line 350)
-* __ashlsi3: Integer library routines.
- (line 13)
-* __ashlsq3: Fixed-point fractional library routines.
- (line 338)
-* __ashlta3: Fixed-point fractional library routines.
- (line 353)
-* __ashlti3: Integer library routines.
- (line 15)
-* __ashluda3: Fixed-point fractional library routines.
- (line 359)
-* __ashludq3: Fixed-point fractional library routines.
- (line 348)
-* __ashluha3: Fixed-point fractional library routines.
- (line 355)
-* __ashluhq3: Fixed-point fractional library routines.
- (line 344)
-* __ashluqq3: Fixed-point fractional library routines.
- (line 342)
-* __ashlusa3: Fixed-point fractional library routines.
- (line 357)
-* __ashlusq3: Fixed-point fractional library routines.
- (line 346)
-* __ashluta3: Fixed-point fractional library routines.
- (line 361)
-* __ashrda3: Fixed-point fractional library routines.
- (line 371)
-* __ashrdi3: Integer library routines.
- (line 19)
-* __ashrdq3: Fixed-point fractional library routines.
- (line 368)
-* __ashrha3: Fixed-point fractional library routines.
- (line 369)
-* __ashrhq3: Fixed-point fractional library routines.
- (line 365)
-* __ashrqq3: Fixed-point fractional library routines.
- (line 364)
-* __ashrsa3: Fixed-point fractional library routines.
- (line 370)
-* __ashrsi3: Integer library routines.
- (line 18)
-* __ashrsq3: Fixed-point fractional library routines.
- (line 366)
-* __ashrta3: Fixed-point fractional library routines.
- (line 373)
-* __ashrti3: Integer library routines.
- (line 20)
-* __bid_adddd3: Decimal float library routines.
- (line 25)
-* __bid_addsd3: Decimal float library routines.
- (line 21)
-* __bid_addtd3: Decimal float library routines.
- (line 29)
-* __bid_divdd3: Decimal float library routines.
- (line 68)
-* __bid_divsd3: Decimal float library routines.
- (line 64)
-* __bid_divtd3: Decimal float library routines.
- (line 72)
-* __bid_eqdd2: Decimal float library routines.
- (line 259)
-* __bid_eqsd2: Decimal float library routines.
- (line 257)
-* __bid_eqtd2: Decimal float library routines.
- (line 261)
-* __bid_extendddtd2: Decimal float library routines.
- (line 92)
-* __bid_extendddtf: Decimal float library routines.
- (line 140)
-* __bid_extendddxf: Decimal float library routines.
- (line 134)
-* __bid_extenddfdd: Decimal float library routines.
- (line 147)
-* __bid_extenddftd: Decimal float library routines.
- (line 107)
-* __bid_extendsddd2: Decimal float library routines.
- (line 88)
-* __bid_extendsddf: Decimal float library routines.
- (line 128)
-* __bid_extendsdtd2: Decimal float library routines.
- (line 90)
-* __bid_extendsdtf: Decimal float library routines.
- (line 138)
-* __bid_extendsdxf: Decimal float library routines.
- (line 132)
-* __bid_extendsfdd: Decimal float library routines.
- (line 103)
-* __bid_extendsfsd: Decimal float library routines.
- (line 145)
-* __bid_extendsftd: Decimal float library routines.
- (line 105)
-* __bid_extendtftd: Decimal float library routines.
- (line 149)
-* __bid_extendxftd: Decimal float library routines.
- (line 109)
-* __bid_fixdddi: Decimal float library routines.
- (line 170)
-* __bid_fixddsi: Decimal float library routines.
- (line 162)
-* __bid_fixsddi: Decimal float library routines.
- (line 168)
-* __bid_fixsdsi: Decimal float library routines.
- (line 160)
-* __bid_fixtddi: Decimal float library routines.
- (line 172)
-* __bid_fixtdsi: Decimal float library routines.
- (line 164)
-* __bid_fixunsdddi: Decimal float library routines.
- (line 187)
-* __bid_fixunsddsi: Decimal float library routines.
- (line 178)
-* __bid_fixunssddi: Decimal float library routines.
- (line 185)
-* __bid_fixunssdsi: Decimal float library routines.
- (line 176)
-* __bid_fixunstddi: Decimal float library routines.
- (line 189)
-* __bid_fixunstdsi: Decimal float library routines.
- (line 180)
-* __bid_floatdidd: Decimal float library routines.
- (line 205)
-* __bid_floatdisd: Decimal float library routines.
- (line 203)
-* __bid_floatditd: Decimal float library routines.
- (line 207)
-* __bid_floatsidd: Decimal float library routines.
- (line 196)
-* __bid_floatsisd: Decimal float library routines.
- (line 194)
-* __bid_floatsitd: Decimal float library routines.
- (line 198)
-* __bid_floatunsdidd: Decimal float library routines.
- (line 223)
-* __bid_floatunsdisd: Decimal float library routines.
- (line 221)
-* __bid_floatunsditd: Decimal float library routines.
- (line 225)
-* __bid_floatunssidd: Decimal float library routines.
- (line 214)
-* __bid_floatunssisd: Decimal float library routines.
- (line 212)
-* __bid_floatunssitd: Decimal float library routines.
- (line 216)
-* __bid_gedd2: Decimal float library routines.
- (line 277)
-* __bid_gesd2: Decimal float library routines.
- (line 275)
-* __bid_getd2: Decimal float library routines.
- (line 279)
-* __bid_gtdd2: Decimal float library routines.
- (line 304)
-* __bid_gtsd2: Decimal float library routines.
- (line 302)
-* __bid_gttd2: Decimal float library routines.
- (line 306)
-* __bid_ledd2: Decimal float library routines.
- (line 295)
-* __bid_lesd2: Decimal float library routines.
- (line 293)
-* __bid_letd2: Decimal float library routines.
- (line 297)
-* __bid_ltdd2: Decimal float library routines.
- (line 286)
-* __bid_ltsd2: Decimal float library routines.
- (line 284)
-* __bid_lttd2: Decimal float library routines.
- (line 288)
-* __bid_muldd3: Decimal float library routines.
- (line 54)
-* __bid_mulsd3: Decimal float library routines.
- (line 50)
-* __bid_multd3: Decimal float library routines.
- (line 58)
-* __bid_nedd2: Decimal float library routines.
- (line 268)
-* __bid_negdd2: Decimal float library routines.
- (line 78)
-* __bid_negsd2: Decimal float library routines.
- (line 76)
-* __bid_negtd2: Decimal float library routines.
- (line 80)
-* __bid_nesd2: Decimal float library routines.
- (line 266)
-* __bid_netd2: Decimal float library routines.
- (line 270)
-* __bid_subdd3: Decimal float library routines.
- (line 39)
-* __bid_subsd3: Decimal float library routines.
- (line 35)
-* __bid_subtd3: Decimal float library routines.
- (line 43)
-* __bid_truncdddf: Decimal float library routines.
- (line 153)
-* __bid_truncddsd2: Decimal float library routines.
- (line 94)
-* __bid_truncddsf: Decimal float library routines.
- (line 124)
-* __bid_truncdfsd: Decimal float library routines.
- (line 111)
-* __bid_truncsdsf: Decimal float library routines.
- (line 151)
-* __bid_trunctddd2: Decimal float library routines.
- (line 98)
-* __bid_trunctddf: Decimal float library routines.
- (line 130)
-* __bid_trunctdsd2: Decimal float library routines.
- (line 96)
-* __bid_trunctdsf: Decimal float library routines.
- (line 126)
-* __bid_trunctdtf: Decimal float library routines.
- (line 155)
-* __bid_trunctdxf: Decimal float library routines.
- (line 136)
-* __bid_trunctfdd: Decimal float library routines.
- (line 119)
-* __bid_trunctfsd: Decimal float library routines.
- (line 115)
-* __bid_truncxfdd: Decimal float library routines.
- (line 117)
-* __bid_truncxfsd: Decimal float library routines.
- (line 113)
-* __bid_unorddd2: Decimal float library routines.
- (line 235)
-* __bid_unordsd2: Decimal float library routines.
- (line 233)
-* __bid_unordtd2: Decimal float library routines.
- (line 237)
-* __bswapdi2: Integer library routines.
- (line 162)
-* __bswapsi2: Integer library routines.
- (line 161)
-* __builtin_classify_type: Varargs. (line 51)
-* __builtin_next_arg: Varargs. (line 42)
-* __builtin_saveregs: Varargs. (line 24)
-* __clear_cache: Miscellaneous routines.
- (line 10)
-* __clzdi2: Integer library routines.
- (line 131)
-* __clzsi2: Integer library routines.
- (line 130)
-* __clzti2: Integer library routines.
- (line 132)
-* __cmpda2: Fixed-point fractional library routines.
- (line 451)
-* __cmpdf2: Soft float library routines.
- (line 164)
-* __cmpdi2: Integer library routines.
- (line 87)
-* __cmpdq2: Fixed-point fractional library routines.
- (line 441)
-* __cmpha2: Fixed-point fractional library routines.
- (line 449)
-* __cmphq2: Fixed-point fractional library routines.
- (line 438)
-* __cmpqq2: Fixed-point fractional library routines.
- (line 437)
-* __cmpsa2: Fixed-point fractional library routines.
- (line 450)
-* __cmpsf2: Soft float library routines.
- (line 163)
-* __cmpsq2: Fixed-point fractional library routines.
- (line 439)
-* __cmpta2: Fixed-point fractional library routines.
- (line 453)
-* __cmptf2: Soft float library routines.
- (line 165)
-* __cmpti2: Integer library routines.
- (line 88)
-* __cmpuda2: Fixed-point fractional library routines.
- (line 458)
-* __cmpudq2: Fixed-point fractional library routines.
- (line 448)
-* __cmpuha2: Fixed-point fractional library routines.
- (line 455)
-* __cmpuhq2: Fixed-point fractional library routines.
- (line 444)
-* __cmpuqq2: Fixed-point fractional library routines.
- (line 443)
-* __cmpusa2: Fixed-point fractional library routines.
- (line 456)
-* __cmpusq2: Fixed-point fractional library routines.
- (line 446)
-* __cmputa2: Fixed-point fractional library routines.
- (line 460)
-* __CTOR_LIST__: Initialization. (line 25)
-* __ctzdi2: Integer library routines.
- (line 138)
-* __ctzsi2: Integer library routines.
- (line 137)
-* __ctzti2: Integer library routines.
- (line 139)
-* __divda3: Fixed-point fractional library routines.
- (line 227)
-* __divdc3: Soft float library routines.
- (line 252)
-* __divdf3: Soft float library routines.
- (line 48)
-* __divdi3: Integer library routines.
- (line 25)
-* __divdq3: Fixed-point fractional library routines.
- (line 223)
-* __divha3: Fixed-point fractional library routines.
- (line 225)
-* __divhq3: Fixed-point fractional library routines.
- (line 220)
-* __divqq3: Fixed-point fractional library routines.
- (line 219)
-* __divsa3: Fixed-point fractional library routines.
- (line 226)
-* __divsc3: Soft float library routines.
- (line 250)
-* __divsf3: Soft float library routines.
- (line 47)
-* __divsi3: Integer library routines.
- (line 24)
-* __divsq3: Fixed-point fractional library routines.
- (line 221)
-* __divta3: Fixed-point fractional library routines.
- (line 229)
-* __divtc3: Soft float library routines.
- (line 254)
-* __divtf3: Soft float library routines.
- (line 50)
-* __divti3: Integer library routines.
- (line 26)
-* __divxc3: Soft float library routines.
- (line 256)
-* __divxf3: Soft float library routines.
- (line 52)
-* __dpd_adddd3: Decimal float library routines.
- (line 23)
-* __dpd_addsd3: Decimal float library routines.
- (line 19)
-* __dpd_addtd3: Decimal float library routines.
- (line 27)
-* __dpd_divdd3: Decimal float library routines.
- (line 66)
-* __dpd_divsd3: Decimal float library routines.
- (line 62)
-* __dpd_divtd3: Decimal float library routines.
- (line 70)
-* __dpd_eqdd2: Decimal float library routines.
- (line 258)
-* __dpd_eqsd2: Decimal float library routines.
- (line 256)
-* __dpd_eqtd2: Decimal float library routines.
- (line 260)
-* __dpd_extendddtd2: Decimal float library routines.
- (line 91)
-* __dpd_extendddtf: Decimal float library routines.
- (line 139)
-* __dpd_extendddxf: Decimal float library routines.
- (line 133)
-* __dpd_extenddfdd: Decimal float library routines.
- (line 146)
-* __dpd_extenddftd: Decimal float library routines.
- (line 106)
-* __dpd_extendsddd2: Decimal float library routines.
- (line 87)
-* __dpd_extendsddf: Decimal float library routines.
- (line 127)
-* __dpd_extendsdtd2: Decimal float library routines.
- (line 89)
-* __dpd_extendsdtf: Decimal float library routines.
- (line 137)
-* __dpd_extendsdxf: Decimal float library routines.
- (line 131)
-* __dpd_extendsfdd: Decimal float library routines.
- (line 102)
-* __dpd_extendsfsd: Decimal float library routines.
- (line 144)
-* __dpd_extendsftd: Decimal float library routines.
- (line 104)
-* __dpd_extendtftd: Decimal float library routines.
- (line 148)
-* __dpd_extendxftd: Decimal float library routines.
- (line 108)
-* __dpd_fixdddi: Decimal float library routines.
- (line 169)
-* __dpd_fixddsi: Decimal float library routines.
- (line 161)
-* __dpd_fixsddi: Decimal float library routines.
- (line 167)
-* __dpd_fixsdsi: Decimal float library routines.
- (line 159)
-* __dpd_fixtddi: Decimal float library routines.
- (line 171)
-* __dpd_fixtdsi: Decimal float library routines.
- (line 163)
-* __dpd_fixunsdddi: Decimal float library routines.
- (line 186)
-* __dpd_fixunsddsi: Decimal float library routines.
- (line 177)
-* __dpd_fixunssddi: Decimal float library routines.
- (line 184)
-* __dpd_fixunssdsi: Decimal float library routines.
- (line 175)
-* __dpd_fixunstddi: Decimal float library routines.
- (line 188)
-* __dpd_fixunstdsi: Decimal float library routines.
- (line 179)
-* __dpd_floatdidd: Decimal float library routines.
- (line 204)
-* __dpd_floatdisd: Decimal float library routines.
- (line 202)
-* __dpd_floatditd: Decimal float library routines.
- (line 206)
-* __dpd_floatsidd: Decimal float library routines.
- (line 195)
-* __dpd_floatsisd: Decimal float library routines.
- (line 193)
-* __dpd_floatsitd: Decimal float library routines.
- (line 197)
-* __dpd_floatunsdidd: Decimal float library routines.
- (line 222)
-* __dpd_floatunsdisd: Decimal float library routines.
- (line 220)
-* __dpd_floatunsditd: Decimal float library routines.
- (line 224)
-* __dpd_floatunssidd: Decimal float library routines.
- (line 213)
-* __dpd_floatunssisd: Decimal float library routines.
- (line 211)
-* __dpd_floatunssitd: Decimal float library routines.
- (line 215)
-* __dpd_gedd2: Decimal float library routines.
- (line 276)
-* __dpd_gesd2: Decimal float library routines.
- (line 274)
-* __dpd_getd2: Decimal float library routines.
- (line 278)
-* __dpd_gtdd2: Decimal float library routines.
- (line 303)
-* __dpd_gtsd2: Decimal float library routines.
- (line 301)
-* __dpd_gttd2: Decimal float library routines.
- (line 305)
-* __dpd_ledd2: Decimal float library routines.
- (line 294)
-* __dpd_lesd2: Decimal float library routines.
- (line 292)
-* __dpd_letd2: Decimal float library routines.
- (line 296)
-* __dpd_ltdd2: Decimal float library routines.
- (line 285)
-* __dpd_ltsd2: Decimal float library routines.
- (line 283)
-* __dpd_lttd2: Decimal float library routines.
- (line 287)
-* __dpd_muldd3: Decimal float library routines.
- (line 52)
-* __dpd_mulsd3: Decimal float library routines.
- (line 48)
-* __dpd_multd3: Decimal float library routines.
- (line 56)
-* __dpd_nedd2: Decimal float library routines.
- (line 267)
-* __dpd_negdd2: Decimal float library routines.
- (line 77)
-* __dpd_negsd2: Decimal float library routines.
- (line 75)
-* __dpd_negtd2: Decimal float library routines.
- (line 79)
-* __dpd_nesd2: Decimal float library routines.
- (line 265)
-* __dpd_netd2: Decimal float library routines.
- (line 269)
-* __dpd_subdd3: Decimal float library routines.
- (line 37)
-* __dpd_subsd3: Decimal float library routines.
- (line 33)
-* __dpd_subtd3: Decimal float library routines.
- (line 41)
-* __dpd_truncdddf: Decimal float library routines.
- (line 152)
-* __dpd_truncddsd2: Decimal float library routines.
- (line 93)
-* __dpd_truncddsf: Decimal float library routines.
- (line 123)
-* __dpd_truncdfsd: Decimal float library routines.
- (line 110)
-* __dpd_truncsdsf: Decimal float library routines.
- (line 150)
-* __dpd_trunctddd2: Decimal float library routines.
- (line 97)
-* __dpd_trunctddf: Decimal float library routines.
- (line 129)
-* __dpd_trunctdsd2: Decimal float library routines.
- (line 95)
-* __dpd_trunctdsf: Decimal float library routines.
- (line 125)
-* __dpd_trunctdtf: Decimal float library routines.
- (line 154)
-* __dpd_trunctdxf: Decimal float library routines.
- (line 135)
-* __dpd_trunctfdd: Decimal float library routines.
- (line 118)
-* __dpd_trunctfsd: Decimal float library routines.
- (line 114)
-* __dpd_truncxfdd: Decimal float library routines.
- (line 116)
-* __dpd_truncxfsd: Decimal float library routines.
- (line 112)
-* __dpd_unorddd2: Decimal float library routines.
- (line 234)
-* __dpd_unordsd2: Decimal float library routines.
- (line 232)
-* __dpd_unordtd2: Decimal float library routines.
- (line 236)
-* __DTOR_LIST__: Initialization. (line 25)
-* __eqdf2: Soft float library routines.
- (line 194)
-* __eqsf2: Soft float library routines.
- (line 193)
-* __eqtf2: Soft float library routines.
- (line 195)
-* __extenddftf2: Soft float library routines.
- (line 68)
-* __extenddfxf2: Soft float library routines.
- (line 69)
-* __extendsfdf2: Soft float library routines.
- (line 65)
-* __extendsftf2: Soft float library routines.
- (line 66)
-* __extendsfxf2: Soft float library routines.
- (line 67)
-* __ffsdi2: Integer library routines.
- (line 144)
-* __ffsti2: Integer library routines.
- (line 145)
-* __fixdfdi: Soft float library routines.
- (line 88)
-* __fixdfsi: Soft float library routines.
- (line 81)
-* __fixdfti: Soft float library routines.
- (line 94)
-* __fixsfdi: Soft float library routines.
- (line 87)
-* __fixsfsi: Soft float library routines.
- (line 80)
-* __fixsfti: Soft float library routines.
- (line 93)
-* __fixtfdi: Soft float library routines.
- (line 89)
-* __fixtfsi: Soft float library routines.
- (line 82)
-* __fixtfti: Soft float library routines.
- (line 95)
-* __fixunsdfdi: Soft float library routines.
- (line 108)
-* __fixunsdfsi: Soft float library routines.
- (line 101)
-* __fixunsdfti: Soft float library routines.
- (line 115)
-* __fixunssfdi: Soft float library routines.
- (line 107)
-* __fixunssfsi: Soft float library routines.
- (line 100)
-* __fixunssfti: Soft float library routines.
- (line 114)
-* __fixunstfdi: Soft float library routines.
- (line 109)
-* __fixunstfsi: Soft float library routines.
- (line 102)
-* __fixunstfti: Soft float library routines.
- (line 116)
-* __fixunsxfdi: Soft float library routines.
- (line 110)
-* __fixunsxfsi: Soft float library routines.
- (line 103)
-* __fixunsxfti: Soft float library routines.
- (line 117)
-* __fixxfdi: Soft float library routines.
- (line 90)
-* __fixxfsi: Soft float library routines.
- (line 83)
-* __fixxfti: Soft float library routines.
- (line 96)
-* __floatdidf: Soft float library routines.
- (line 128)
-* __floatdisf: Soft float library routines.
- (line 127)
-* __floatditf: Soft float library routines.
- (line 129)
-* __floatdixf: Soft float library routines.
- (line 130)
-* __floatsidf: Soft float library routines.
- (line 122)
-* __floatsisf: Soft float library routines.
- (line 121)
-* __floatsitf: Soft float library routines.
- (line 123)
-* __floatsixf: Soft float library routines.
- (line 124)
-* __floattidf: Soft float library routines.
- (line 134)
-* __floattisf: Soft float library routines.
- (line 133)
-* __floattitf: Soft float library routines.
- (line 135)
-* __floattixf: Soft float library routines.
- (line 136)
-* __floatundidf: Soft float library routines.
- (line 146)
-* __floatundisf: Soft float library routines.
- (line 145)
-* __floatunditf: Soft float library routines.
- (line 147)
-* __floatundixf: Soft float library routines.
- (line 148)
-* __floatunsidf: Soft float library routines.
- (line 140)
-* __floatunsisf: Soft float library routines.
- (line 139)
-* __floatunsitf: Soft float library routines.
- (line 141)
-* __floatunsixf: Soft float library routines.
- (line 142)
-* __floatuntidf: Soft float library routines.
- (line 152)
-* __floatuntisf: Soft float library routines.
- (line 151)
-* __floatuntitf: Soft float library routines.
- (line 153)
-* __floatuntixf: Soft float library routines.
- (line 154)
-* __fractdadf: Fixed-point fractional library routines.
- (line 636)
-* __fractdadi: Fixed-point fractional library routines.
- (line 633)
-* __fractdadq: Fixed-point fractional library routines.
- (line 616)
-* __fractdaha2: Fixed-point fractional library routines.
- (line 617)
-* __fractdahi: Fixed-point fractional library routines.
- (line 631)
-* __fractdahq: Fixed-point fractional library routines.
- (line 614)
-* __fractdaqi: Fixed-point fractional library routines.
- (line 630)
-* __fractdaqq: Fixed-point fractional library routines.
- (line 613)
-* __fractdasa2: Fixed-point fractional library routines.
- (line 618)
-* __fractdasf: Fixed-point fractional library routines.
- (line 635)
-* __fractdasi: Fixed-point fractional library routines.
- (line 632)
-* __fractdasq: Fixed-point fractional library routines.
- (line 615)
-* __fractdata2: Fixed-point fractional library routines.
- (line 619)
-* __fractdati: Fixed-point fractional library routines.
- (line 634)
-* __fractdauda: Fixed-point fractional library routines.
- (line 627)
-* __fractdaudq: Fixed-point fractional library routines.
- (line 624)
-* __fractdauha: Fixed-point fractional library routines.
- (line 625)
-* __fractdauhq: Fixed-point fractional library routines.
- (line 621)
-* __fractdauqq: Fixed-point fractional library routines.
- (line 620)
-* __fractdausa: Fixed-point fractional library routines.
- (line 626)
-* __fractdausq: Fixed-point fractional library routines.
- (line 622)
-* __fractdauta: Fixed-point fractional library routines.
- (line 629)
-* __fractdfda: Fixed-point fractional library routines.
- (line 1025)
-* __fractdfdq: Fixed-point fractional library routines.
- (line 1022)
-* __fractdfha: Fixed-point fractional library routines.
- (line 1023)
-* __fractdfhq: Fixed-point fractional library routines.
- (line 1020)
-* __fractdfqq: Fixed-point fractional library routines.
- (line 1019)
-* __fractdfsa: Fixed-point fractional library routines.
- (line 1024)
-* __fractdfsq: Fixed-point fractional library routines.
- (line 1021)
-* __fractdfta: Fixed-point fractional library routines.
- (line 1026)
-* __fractdfuda: Fixed-point fractional library routines.
- (line 1033)
-* __fractdfudq: Fixed-point fractional library routines.
- (line 1030)
-* __fractdfuha: Fixed-point fractional library routines.
- (line 1031)
-* __fractdfuhq: Fixed-point fractional library routines.
- (line 1028)
-* __fractdfuqq: Fixed-point fractional library routines.
- (line 1027)
-* __fractdfusa: Fixed-point fractional library routines.
- (line 1032)
-* __fractdfusq: Fixed-point fractional library routines.
- (line 1029)
-* __fractdfuta: Fixed-point fractional library routines.
- (line 1034)
-* __fractdida: Fixed-point fractional library routines.
- (line 975)
-* __fractdidq: Fixed-point fractional library routines.
- (line 972)
-* __fractdiha: Fixed-point fractional library routines.
- (line 973)
-* __fractdihq: Fixed-point fractional library routines.
- (line 970)
-* __fractdiqq: Fixed-point fractional library routines.
- (line 969)
-* __fractdisa: Fixed-point fractional library routines.
- (line 974)
-* __fractdisq: Fixed-point fractional library routines.
- (line 971)
-* __fractdita: Fixed-point fractional library routines.
- (line 976)
-* __fractdiuda: Fixed-point fractional library routines.
- (line 983)
-* __fractdiudq: Fixed-point fractional library routines.
- (line 980)
-* __fractdiuha: Fixed-point fractional library routines.
- (line 981)
-* __fractdiuhq: Fixed-point fractional library routines.
- (line 978)
-* __fractdiuqq: Fixed-point fractional library routines.
- (line 977)
-* __fractdiusa: Fixed-point fractional library routines.
- (line 982)
-* __fractdiusq: Fixed-point fractional library routines.
- (line 979)
-* __fractdiuta: Fixed-point fractional library routines.
- (line 984)
-* __fractdqda: Fixed-point fractional library routines.
- (line 544)
-* __fractdqdf: Fixed-point fractional library routines.
- (line 566)
-* __fractdqdi: Fixed-point fractional library routines.
- (line 563)
-* __fractdqha: Fixed-point fractional library routines.
- (line 542)
-* __fractdqhi: Fixed-point fractional library routines.
- (line 561)
-* __fractdqhq2: Fixed-point fractional library routines.
- (line 540)
-* __fractdqqi: Fixed-point fractional library routines.
- (line 560)
-* __fractdqqq2: Fixed-point fractional library routines.
- (line 539)
-* __fractdqsa: Fixed-point fractional library routines.
- (line 543)
-* __fractdqsf: Fixed-point fractional library routines.
- (line 565)
-* __fractdqsi: Fixed-point fractional library routines.
- (line 562)
-* __fractdqsq2: Fixed-point fractional library routines.
- (line 541)
-* __fractdqta: Fixed-point fractional library routines.
- (line 545)
-* __fractdqti: Fixed-point fractional library routines.
- (line 564)
-* __fractdquda: Fixed-point fractional library routines.
- (line 557)
-* __fractdqudq: Fixed-point fractional library routines.
- (line 552)
-* __fractdquha: Fixed-point fractional library routines.
- (line 554)
-* __fractdquhq: Fixed-point fractional library routines.
- (line 548)
-* __fractdquqq: Fixed-point fractional library routines.
- (line 547)
-* __fractdqusa: Fixed-point fractional library routines.
- (line 555)
-* __fractdqusq: Fixed-point fractional library routines.
- (line 550)
-* __fractdquta: Fixed-point fractional library routines.
- (line 559)
-* __fracthada2: Fixed-point fractional library routines.
- (line 572)
-* __fracthadf: Fixed-point fractional library routines.
- (line 590)
-* __fracthadi: Fixed-point fractional library routines.
- (line 587)
-* __fracthadq: Fixed-point fractional library routines.
- (line 570)
-* __fracthahi: Fixed-point fractional library routines.
- (line 585)
-* __fracthahq: Fixed-point fractional library routines.
- (line 568)
-* __fracthaqi: Fixed-point fractional library routines.
- (line 584)
-* __fracthaqq: Fixed-point fractional library routines.
- (line 567)
-* __fracthasa2: Fixed-point fractional library routines.
- (line 571)
-* __fracthasf: Fixed-point fractional library routines.
- (line 589)
-* __fracthasi: Fixed-point fractional library routines.
- (line 586)
-* __fracthasq: Fixed-point fractional library routines.
- (line 569)
-* __fracthata2: Fixed-point fractional library routines.
- (line 573)
-* __fracthati: Fixed-point fractional library routines.
- (line 588)
-* __fracthauda: Fixed-point fractional library routines.
- (line 581)
-* __fracthaudq: Fixed-point fractional library routines.
- (line 578)
-* __fracthauha: Fixed-point fractional library routines.
- (line 579)
-* __fracthauhq: Fixed-point fractional library routines.
- (line 575)
-* __fracthauqq: Fixed-point fractional library routines.
- (line 574)
-* __fracthausa: Fixed-point fractional library routines.
- (line 580)
-* __fracthausq: Fixed-point fractional library routines.
- (line 576)
-* __fracthauta: Fixed-point fractional library routines.
- (line 583)
-* __fracthida: Fixed-point fractional library routines.
- (line 943)
-* __fracthidq: Fixed-point fractional library routines.
- (line 940)
-* __fracthiha: Fixed-point fractional library routines.
- (line 941)
-* __fracthihq: Fixed-point fractional library routines.
- (line 938)
-* __fracthiqq: Fixed-point fractional library routines.
- (line 937)
-* __fracthisa: Fixed-point fractional library routines.
- (line 942)
-* __fracthisq: Fixed-point fractional library routines.
- (line 939)
-* __fracthita: Fixed-point fractional library routines.
- (line 944)
-* __fracthiuda: Fixed-point fractional library routines.
- (line 951)
-* __fracthiudq: Fixed-point fractional library routines.
- (line 948)
-* __fracthiuha: Fixed-point fractional library routines.
- (line 949)
-* __fracthiuhq: Fixed-point fractional library routines.
- (line 946)
-* __fracthiuqq: Fixed-point fractional library routines.
- (line 945)
-* __fracthiusa: Fixed-point fractional library routines.
- (line 950)
-* __fracthiusq: Fixed-point fractional library routines.
- (line 947)
-* __fracthiuta: Fixed-point fractional library routines.
- (line 952)
-* __fracthqda: Fixed-point fractional library routines.
- (line 498)
-* __fracthqdf: Fixed-point fractional library routines.
- (line 514)
-* __fracthqdi: Fixed-point fractional library routines.
- (line 511)
-* __fracthqdq2: Fixed-point fractional library routines.
- (line 495)
-* __fracthqha: Fixed-point fractional library routines.
- (line 496)
-* __fracthqhi: Fixed-point fractional library routines.
- (line 509)
-* __fracthqqi: Fixed-point fractional library routines.
- (line 508)
-* __fracthqqq2: Fixed-point fractional library routines.
- (line 493)
-* __fracthqsa: Fixed-point fractional library routines.
- (line 497)
-* __fracthqsf: Fixed-point fractional library routines.
- (line 513)
-* __fracthqsi: Fixed-point fractional library routines.
- (line 510)
-* __fracthqsq2: Fixed-point fractional library routines.
- (line 494)
-* __fracthqta: Fixed-point fractional library routines.
- (line 499)
-* __fracthqti: Fixed-point fractional library routines.
- (line 512)
-* __fracthquda: Fixed-point fractional library routines.
- (line 506)
-* __fracthqudq: Fixed-point fractional library routines.
- (line 503)
-* __fracthquha: Fixed-point fractional library routines.
- (line 504)
-* __fracthquhq: Fixed-point fractional library routines.
- (line 501)
-* __fracthquqq: Fixed-point fractional library routines.
- (line 500)
-* __fracthqusa: Fixed-point fractional library routines.
- (line 505)
-* __fracthqusq: Fixed-point fractional library routines.
- (line 502)
-* __fracthquta: Fixed-point fractional library routines.
- (line 507)
-* __fractqida: Fixed-point fractional library routines.
- (line 925)
-* __fractqidq: Fixed-point fractional library routines.
- (line 922)
-* __fractqiha: Fixed-point fractional library routines.
- (line 923)
-* __fractqihq: Fixed-point fractional library routines.
- (line 920)
-* __fractqiqq: Fixed-point fractional library routines.
- (line 919)
-* __fractqisa: Fixed-point fractional library routines.
- (line 924)
-* __fractqisq: Fixed-point fractional library routines.
- (line 921)
-* __fractqita: Fixed-point fractional library routines.
- (line 926)
-* __fractqiuda: Fixed-point fractional library routines.
- (line 934)
-* __fractqiudq: Fixed-point fractional library routines.
- (line 931)
-* __fractqiuha: Fixed-point fractional library routines.
- (line 932)
-* __fractqiuhq: Fixed-point fractional library routines.
- (line 928)
-* __fractqiuqq: Fixed-point fractional library routines.
- (line 927)
-* __fractqiusa: Fixed-point fractional library routines.
- (line 933)
-* __fractqiusq: Fixed-point fractional library routines.
- (line 929)
-* __fractqiuta: Fixed-point fractional library routines.
- (line 936)
-* __fractqqda: Fixed-point fractional library routines.
- (line 474)
-* __fractqqdf: Fixed-point fractional library routines.
- (line 492)
-* __fractqqdi: Fixed-point fractional library routines.
- (line 489)
-* __fractqqdq2: Fixed-point fractional library routines.
- (line 471)
-* __fractqqha: Fixed-point fractional library routines.
- (line 472)
-* __fractqqhi: Fixed-point fractional library routines.
- (line 487)
-* __fractqqhq2: Fixed-point fractional library routines.
- (line 469)
-* __fractqqqi: Fixed-point fractional library routines.
- (line 486)
-* __fractqqsa: Fixed-point fractional library routines.
- (line 473)
-* __fractqqsf: Fixed-point fractional library routines.
- (line 491)
-* __fractqqsi: Fixed-point fractional library routines.
- (line 488)
-* __fractqqsq2: Fixed-point fractional library routines.
- (line 470)
-* __fractqqta: Fixed-point fractional library routines.
- (line 475)
-* __fractqqti: Fixed-point fractional library routines.
- (line 490)
-* __fractqquda: Fixed-point fractional library routines.
- (line 483)
-* __fractqqudq: Fixed-point fractional library routines.
- (line 480)
-* __fractqquha: Fixed-point fractional library routines.
- (line 481)
-* __fractqquhq: Fixed-point fractional library routines.
- (line 477)
-* __fractqquqq: Fixed-point fractional library routines.
- (line 476)
-* __fractqqusa: Fixed-point fractional library routines.
- (line 482)
-* __fractqqusq: Fixed-point fractional library routines.
- (line 478)
-* __fractqquta: Fixed-point fractional library routines.
- (line 485)
-* __fractsada2: Fixed-point fractional library routines.
- (line 596)
-* __fractsadf: Fixed-point fractional library routines.
- (line 612)
-* __fractsadi: Fixed-point fractional library routines.
- (line 609)
-* __fractsadq: Fixed-point fractional library routines.
- (line 594)
-* __fractsaha2: Fixed-point fractional library routines.
- (line 595)
-* __fractsahi: Fixed-point fractional library routines.
- (line 607)
-* __fractsahq: Fixed-point fractional library routines.
- (line 592)
-* __fractsaqi: Fixed-point fractional library routines.
- (line 606)
-* __fractsaqq: Fixed-point fractional library routines.
- (line 591)
-* __fractsasf: Fixed-point fractional library routines.
- (line 611)
-* __fractsasi: Fixed-point fractional library routines.
- (line 608)
-* __fractsasq: Fixed-point fractional library routines.
- (line 593)
-* __fractsata2: Fixed-point fractional library routines.
- (line 597)
-* __fractsati: Fixed-point fractional library routines.
- (line 610)
-* __fractsauda: Fixed-point fractional library routines.
- (line 604)
-* __fractsaudq: Fixed-point fractional library routines.
- (line 601)
-* __fractsauha: Fixed-point fractional library routines.
- (line 602)
-* __fractsauhq: Fixed-point fractional library routines.
- (line 599)
-* __fractsauqq: Fixed-point fractional library routines.
- (line 598)
-* __fractsausa: Fixed-point fractional library routines.
- (line 603)
-* __fractsausq: Fixed-point fractional library routines.
- (line 600)
-* __fractsauta: Fixed-point fractional library routines.
- (line 605)
-* __fractsfda: Fixed-point fractional library routines.
- (line 1009)
-* __fractsfdq: Fixed-point fractional library routines.
- (line 1006)
-* __fractsfha: Fixed-point fractional library routines.
- (line 1007)
-* __fractsfhq: Fixed-point fractional library routines.
- (line 1004)
-* __fractsfqq: Fixed-point fractional library routines.
- (line 1003)
-* __fractsfsa: Fixed-point fractional library routines.
- (line 1008)
-* __fractsfsq: Fixed-point fractional library routines.
- (line 1005)
-* __fractsfta: Fixed-point fractional library routines.
- (line 1010)
-* __fractsfuda: Fixed-point fractional library routines.
- (line 1017)
-* __fractsfudq: Fixed-point fractional library routines.
- (line 1014)
-* __fractsfuha: Fixed-point fractional library routines.
- (line 1015)
-* __fractsfuhq: Fixed-point fractional library routines.
- (line 1012)
-* __fractsfuqq: Fixed-point fractional library routines.
- (line 1011)
-* __fractsfusa: Fixed-point fractional library routines.
- (line 1016)
-* __fractsfusq: Fixed-point fractional library routines.
- (line 1013)
-* __fractsfuta: Fixed-point fractional library routines.
- (line 1018)
-* __fractsida: Fixed-point fractional library routines.
- (line 959)
-* __fractsidq: Fixed-point fractional library routines.
- (line 956)
-* __fractsiha: Fixed-point fractional library routines.
- (line 957)
-* __fractsihq: Fixed-point fractional library routines.
- (line 954)
-* __fractsiqq: Fixed-point fractional library routines.
- (line 953)
-* __fractsisa: Fixed-point fractional library routines.
- (line 958)
-* __fractsisq: Fixed-point fractional library routines.
- (line 955)
-* __fractsita: Fixed-point fractional library routines.
- (line 960)
-* __fractsiuda: Fixed-point fractional library routines.
- (line 967)
-* __fractsiudq: Fixed-point fractional library routines.
- (line 964)
-* __fractsiuha: Fixed-point fractional library routines.
- (line 965)
-* __fractsiuhq: Fixed-point fractional library routines.
- (line 962)
-* __fractsiuqq: Fixed-point fractional library routines.
- (line 961)
-* __fractsiusa: Fixed-point fractional library routines.
- (line 966)
-* __fractsiusq: Fixed-point fractional library routines.
- (line 963)
-* __fractsiuta: Fixed-point fractional library routines.
- (line 968)
-* __fractsqda: Fixed-point fractional library routines.
- (line 520)
-* __fractsqdf: Fixed-point fractional library routines.
- (line 538)
-* __fractsqdi: Fixed-point fractional library routines.
- (line 535)
-* __fractsqdq2: Fixed-point fractional library routines.
- (line 517)
-* __fractsqha: Fixed-point fractional library routines.
- (line 518)
-* __fractsqhi: Fixed-point fractional library routines.
- (line 533)
-* __fractsqhq2: Fixed-point fractional library routines.
- (line 516)
-* __fractsqqi: Fixed-point fractional library routines.
- (line 532)
-* __fractsqqq2: Fixed-point fractional library routines.
- (line 515)
-* __fractsqsa: Fixed-point fractional library routines.
- (line 519)
-* __fractsqsf: Fixed-point fractional library routines.
- (line 537)
-* __fractsqsi: Fixed-point fractional library routines.
- (line 534)
-* __fractsqta: Fixed-point fractional library routines.
- (line 521)
-* __fractsqti: Fixed-point fractional library routines.
- (line 536)
-* __fractsquda: Fixed-point fractional library routines.
- (line 529)
-* __fractsqudq: Fixed-point fractional library routines.
- (line 526)
-* __fractsquha: Fixed-point fractional library routines.
- (line 527)
-* __fractsquhq: Fixed-point fractional library routines.
- (line 523)
-* __fractsquqq: Fixed-point fractional library routines.
- (line 522)
-* __fractsqusa: Fixed-point fractional library routines.
- (line 528)
-* __fractsqusq: Fixed-point fractional library routines.
- (line 524)
-* __fractsquta: Fixed-point fractional library routines.
- (line 531)
-* __fracttada2: Fixed-point fractional library routines.
- (line 643)
-* __fracttadf: Fixed-point fractional library routines.
- (line 664)
-* __fracttadi: Fixed-point fractional library routines.
- (line 661)
-* __fracttadq: Fixed-point fractional library routines.
- (line 640)
-* __fracttaha2: Fixed-point fractional library routines.
- (line 641)
-* __fracttahi: Fixed-point fractional library routines.
- (line 659)
-* __fracttahq: Fixed-point fractional library routines.
- (line 638)
-* __fracttaqi: Fixed-point fractional library routines.
- (line 658)
-* __fracttaqq: Fixed-point fractional library routines.
- (line 637)
-* __fracttasa2: Fixed-point fractional library routines.
- (line 642)
-* __fracttasf: Fixed-point fractional library routines.
- (line 663)
-* __fracttasi: Fixed-point fractional library routines.
- (line 660)
-* __fracttasq: Fixed-point fractional library routines.
- (line 639)
-* __fracttati: Fixed-point fractional library routines.
- (line 662)
-* __fracttauda: Fixed-point fractional library routines.
- (line 655)
-* __fracttaudq: Fixed-point fractional library routines.
- (line 650)
-* __fracttauha: Fixed-point fractional library routines.
- (line 652)
-* __fracttauhq: Fixed-point fractional library routines.
- (line 646)
-* __fracttauqq: Fixed-point fractional library routines.
- (line 645)
-* __fracttausa: Fixed-point fractional library routines.
- (line 653)
-* __fracttausq: Fixed-point fractional library routines.
- (line 648)
-* __fracttauta: Fixed-point fractional library routines.
- (line 657)
-* __fracttida: Fixed-point fractional library routines.
- (line 991)
-* __fracttidq: Fixed-point fractional library routines.
- (line 988)
-* __fracttiha: Fixed-point fractional library routines.
- (line 989)
-* __fracttihq: Fixed-point fractional library routines.
- (line 986)
-* __fracttiqq: Fixed-point fractional library routines.
- (line 985)
-* __fracttisa: Fixed-point fractional library routines.
- (line 990)
-* __fracttisq: Fixed-point fractional library routines.
- (line 987)
-* __fracttita: Fixed-point fractional library routines.
- (line 992)
-* __fracttiuda: Fixed-point fractional library routines.
- (line 1000)
-* __fracttiudq: Fixed-point fractional library routines.
- (line 997)
-* __fracttiuha: Fixed-point fractional library routines.
- (line 998)
-* __fracttiuhq: Fixed-point fractional library routines.
- (line 994)
-* __fracttiuqq: Fixed-point fractional library routines.
- (line 993)
-* __fracttiusa: Fixed-point fractional library routines.
- (line 999)
-* __fracttiusq: Fixed-point fractional library routines.
- (line 995)
-* __fracttiuta: Fixed-point fractional library routines.
- (line 1002)
-* __fractudada: Fixed-point fractional library routines.
- (line 858)
-* __fractudadf: Fixed-point fractional library routines.
- (line 881)
-* __fractudadi: Fixed-point fractional library routines.
- (line 878)
-* __fractudadq: Fixed-point fractional library routines.
- (line 855)
-* __fractudaha: Fixed-point fractional library routines.
- (line 856)
-* __fractudahi: Fixed-point fractional library routines.
- (line 876)
-* __fractudahq: Fixed-point fractional library routines.
- (line 852)
-* __fractudaqi: Fixed-point fractional library routines.
- (line 875)
-* __fractudaqq: Fixed-point fractional library routines.
- (line 851)
-* __fractudasa: Fixed-point fractional library routines.
- (line 857)
-* __fractudasf: Fixed-point fractional library routines.
- (line 880)
-* __fractudasi: Fixed-point fractional library routines.
- (line 877)
-* __fractudasq: Fixed-point fractional library routines.
- (line 853)
-* __fractudata: Fixed-point fractional library routines.
- (line 860)
-* __fractudati: Fixed-point fractional library routines.
- (line 879)
-* __fractudaudq: Fixed-point fractional library routines.
- (line 868)
-* __fractudauha2: Fixed-point fractional library routines.
- (line 870)
-* __fractudauhq: Fixed-point fractional library routines.
- (line 864)
-* __fractudauqq: Fixed-point fractional library routines.
- (line 862)
-* __fractudausa2: Fixed-point fractional library routines.
- (line 872)
-* __fractudausq: Fixed-point fractional library routines.
- (line 866)
-* __fractudauta2: Fixed-point fractional library routines.
- (line 874)
-* __fractudqda: Fixed-point fractional library routines.
- (line 766)
-* __fractudqdf: Fixed-point fractional library routines.
- (line 791)
-* __fractudqdi: Fixed-point fractional library routines.
- (line 787)
-* __fractudqdq: Fixed-point fractional library routines.
- (line 761)
-* __fractudqha: Fixed-point fractional library routines.
- (line 763)
-* __fractudqhi: Fixed-point fractional library routines.
- (line 785)
-* __fractudqhq: Fixed-point fractional library routines.
- (line 757)
-* __fractudqqi: Fixed-point fractional library routines.
- (line 784)
-* __fractudqqq: Fixed-point fractional library routines.
- (line 756)
-* __fractudqsa: Fixed-point fractional library routines.
- (line 764)
-* __fractudqsf: Fixed-point fractional library routines.
- (line 790)
-* __fractudqsi: Fixed-point fractional library routines.
- (line 786)
-* __fractudqsq: Fixed-point fractional library routines.
- (line 759)
-* __fractudqta: Fixed-point fractional library routines.
- (line 768)
-* __fractudqti: Fixed-point fractional library routines.
- (line 789)
-* __fractudquda: Fixed-point fractional library routines.
- (line 780)
-* __fractudquha: Fixed-point fractional library routines.
- (line 776)
-* __fractudquhq2: Fixed-point fractional library routines.
- (line 772)
-* __fractudquqq2: Fixed-point fractional library routines.
- (line 770)
-* __fractudqusa: Fixed-point fractional library routines.
- (line 778)
-* __fractudqusq2: Fixed-point fractional library routines.
- (line 774)
-* __fractudquta: Fixed-point fractional library routines.
- (line 782)
-* __fractuhada: Fixed-point fractional library routines.
- (line 799)
-* __fractuhadf: Fixed-point fractional library routines.
- (line 822)
-* __fractuhadi: Fixed-point fractional library routines.
- (line 819)
-* __fractuhadq: Fixed-point fractional library routines.
- (line 796)
-* __fractuhaha: Fixed-point fractional library routines.
- (line 797)
-* __fractuhahi: Fixed-point fractional library routines.
- (line 817)
-* __fractuhahq: Fixed-point fractional library routines.
- (line 793)
-* __fractuhaqi: Fixed-point fractional library routines.
- (line 816)
-* __fractuhaqq: Fixed-point fractional library routines.
- (line 792)
-* __fractuhasa: Fixed-point fractional library routines.
- (line 798)
-* __fractuhasf: Fixed-point fractional library routines.
- (line 821)
-* __fractuhasi: Fixed-point fractional library routines.
- (line 818)
-* __fractuhasq: Fixed-point fractional library routines.
- (line 794)
-* __fractuhata: Fixed-point fractional library routines.
- (line 801)
-* __fractuhati: Fixed-point fractional library routines.
- (line 820)
-* __fractuhauda2: Fixed-point fractional library routines.
- (line 813)
-* __fractuhaudq: Fixed-point fractional library routines.
- (line 809)
-* __fractuhauhq: Fixed-point fractional library routines.
- (line 805)
-* __fractuhauqq: Fixed-point fractional library routines.
- (line 803)
-* __fractuhausa2: Fixed-point fractional library routines.
- (line 811)
-* __fractuhausq: Fixed-point fractional library routines.
- (line 807)
-* __fractuhauta2: Fixed-point fractional library routines.
- (line 815)
-* __fractuhqda: Fixed-point fractional library routines.
- (line 702)
-* __fractuhqdf: Fixed-point fractional library routines.
- (line 723)
-* __fractuhqdi: Fixed-point fractional library routines.
- (line 720)
-* __fractuhqdq: Fixed-point fractional library routines.
- (line 699)
-* __fractuhqha: Fixed-point fractional library routines.
- (line 700)
-* __fractuhqhi: Fixed-point fractional library routines.
- (line 718)
-* __fractuhqhq: Fixed-point fractional library routines.
- (line 697)
-* __fractuhqqi: Fixed-point fractional library routines.
- (line 717)
-* __fractuhqqq: Fixed-point fractional library routines.
- (line 696)
-* __fractuhqsa: Fixed-point fractional library routines.
- (line 701)
-* __fractuhqsf: Fixed-point fractional library routines.
- (line 722)
-* __fractuhqsi: Fixed-point fractional library routines.
- (line 719)
-* __fractuhqsq: Fixed-point fractional library routines.
- (line 698)
-* __fractuhqta: Fixed-point fractional library routines.
- (line 703)
-* __fractuhqti: Fixed-point fractional library routines.
- (line 721)
-* __fractuhquda: Fixed-point fractional library routines.
- (line 714)
-* __fractuhqudq2: Fixed-point fractional library routines.
- (line 709)
-* __fractuhquha: Fixed-point fractional library routines.
- (line 711)
-* __fractuhquqq2: Fixed-point fractional library routines.
- (line 705)
-* __fractuhqusa: Fixed-point fractional library routines.
- (line 712)
-* __fractuhqusq2: Fixed-point fractional library routines.
- (line 707)
-* __fractuhquta: Fixed-point fractional library routines.
- (line 716)
-* __fractunsdadi: Fixed-point fractional library routines.
- (line 1555)
-* __fractunsdahi: Fixed-point fractional library routines.
- (line 1553)
-* __fractunsdaqi: Fixed-point fractional library routines.
- (line 1552)
-* __fractunsdasi: Fixed-point fractional library routines.
- (line 1554)
-* __fractunsdati: Fixed-point fractional library routines.
- (line 1556)
-* __fractunsdida: Fixed-point fractional library routines.
- (line 1707)
-* __fractunsdidq: Fixed-point fractional library routines.
- (line 1704)
-* __fractunsdiha: Fixed-point fractional library routines.
- (line 1705)
-* __fractunsdihq: Fixed-point fractional library routines.
- (line 1702)
-* __fractunsdiqq: Fixed-point fractional library routines.
- (line 1701)
-* __fractunsdisa: Fixed-point fractional library routines.
- (line 1706)
-* __fractunsdisq: Fixed-point fractional library routines.
- (line 1703)
-* __fractunsdita: Fixed-point fractional library routines.
- (line 1708)
-* __fractunsdiuda: Fixed-point fractional library routines.
- (line 1720)
-* __fractunsdiudq: Fixed-point fractional library routines.
- (line 1715)
-* __fractunsdiuha: Fixed-point fractional library routines.
- (line 1717)
-* __fractunsdiuhq: Fixed-point fractional library routines.
- (line 1711)
-* __fractunsdiuqq: Fixed-point fractional library routines.
- (line 1710)
-* __fractunsdiusa: Fixed-point fractional library routines.
- (line 1718)
-* __fractunsdiusq: Fixed-point fractional library routines.
- (line 1713)
-* __fractunsdiuta: Fixed-point fractional library routines.
- (line 1722)
-* __fractunsdqdi: Fixed-point fractional library routines.
- (line 1539)
-* __fractunsdqhi: Fixed-point fractional library routines.
- (line 1537)
-* __fractunsdqqi: Fixed-point fractional library routines.
- (line 1536)
-* __fractunsdqsi: Fixed-point fractional library routines.
- (line 1538)
-* __fractunsdqti: Fixed-point fractional library routines.
- (line 1541)
-* __fractunshadi: Fixed-point fractional library routines.
- (line 1545)
-* __fractunshahi: Fixed-point fractional library routines.
- (line 1543)
-* __fractunshaqi: Fixed-point fractional library routines.
- (line 1542)
-* __fractunshasi: Fixed-point fractional library routines.
- (line 1544)
-* __fractunshati: Fixed-point fractional library routines.
- (line 1546)
-* __fractunshida: Fixed-point fractional library routines.
- (line 1663)
-* __fractunshidq: Fixed-point fractional library routines.
- (line 1660)
-* __fractunshiha: Fixed-point fractional library routines.
- (line 1661)
-* __fractunshihq: Fixed-point fractional library routines.
- (line 1658)
-* __fractunshiqq: Fixed-point fractional library routines.
- (line 1657)
-* __fractunshisa: Fixed-point fractional library routines.
- (line 1662)
-* __fractunshisq: Fixed-point fractional library routines.
- (line 1659)
-* __fractunshita: Fixed-point fractional library routines.
- (line 1664)
-* __fractunshiuda: Fixed-point fractional library routines.
- (line 1676)
-* __fractunshiudq: Fixed-point fractional library routines.
- (line 1671)
-* __fractunshiuha: Fixed-point fractional library routines.
- (line 1673)
-* __fractunshiuhq: Fixed-point fractional library routines.
- (line 1667)
-* __fractunshiuqq: Fixed-point fractional library routines.
- (line 1666)
-* __fractunshiusa: Fixed-point fractional library routines.
- (line 1674)
-* __fractunshiusq: Fixed-point fractional library routines.
- (line 1669)
-* __fractunshiuta: Fixed-point fractional library routines.
- (line 1678)
-* __fractunshqdi: Fixed-point fractional library routines.
- (line 1529)
-* __fractunshqhi: Fixed-point fractional library routines.
- (line 1527)
-* __fractunshqqi: Fixed-point fractional library routines.
- (line 1526)
-* __fractunshqsi: Fixed-point fractional library routines.
- (line 1528)
-* __fractunshqti: Fixed-point fractional library routines.
- (line 1530)
-* __fractunsqida: Fixed-point fractional library routines.
- (line 1641)
-* __fractunsqidq: Fixed-point fractional library routines.
- (line 1638)
-* __fractunsqiha: Fixed-point fractional library routines.
- (line 1639)
-* __fractunsqihq: Fixed-point fractional library routines.
- (line 1636)
-* __fractunsqiqq: Fixed-point fractional library routines.
- (line 1635)
-* __fractunsqisa: Fixed-point fractional library routines.
- (line 1640)
-* __fractunsqisq: Fixed-point fractional library routines.
- (line 1637)
-* __fractunsqita: Fixed-point fractional library routines.
- (line 1642)
-* __fractunsqiuda: Fixed-point fractional library routines.
- (line 1654)
-* __fractunsqiudq: Fixed-point fractional library routines.
- (line 1649)
-* __fractunsqiuha: Fixed-point fractional library routines.
- (line 1651)
-* __fractunsqiuhq: Fixed-point fractional library routines.
- (line 1645)
-* __fractunsqiuqq: Fixed-point fractional library routines.
- (line 1644)
-* __fractunsqiusa: Fixed-point fractional library routines.
- (line 1652)
-* __fractunsqiusq: Fixed-point fractional library routines.
- (line 1647)
-* __fractunsqiuta: Fixed-point fractional library routines.
- (line 1656)
-* __fractunsqqdi: Fixed-point fractional library routines.
- (line 1524)
-* __fractunsqqhi: Fixed-point fractional library routines.
- (line 1522)
-* __fractunsqqqi: Fixed-point fractional library routines.
- (line 1521)
-* __fractunsqqsi: Fixed-point fractional library routines.
- (line 1523)
-* __fractunsqqti: Fixed-point fractional library routines.
- (line 1525)
-* __fractunssadi: Fixed-point fractional library routines.
- (line 1550)
-* __fractunssahi: Fixed-point fractional library routines.
- (line 1548)
-* __fractunssaqi: Fixed-point fractional library routines.
- (line 1547)
-* __fractunssasi: Fixed-point fractional library routines.
- (line 1549)
-* __fractunssati: Fixed-point fractional library routines.
- (line 1551)
-* __fractunssida: Fixed-point fractional library routines.
- (line 1685)
-* __fractunssidq: Fixed-point fractional library routines.
- (line 1682)
-* __fractunssiha: Fixed-point fractional library routines.
- (line 1683)
-* __fractunssihq: Fixed-point fractional library routines.
- (line 1680)
-* __fractunssiqq: Fixed-point fractional library routines.
- (line 1679)
-* __fractunssisa: Fixed-point fractional library routines.
- (line 1684)
-* __fractunssisq: Fixed-point fractional library routines.
- (line 1681)
-* __fractunssita: Fixed-point fractional library routines.
- (line 1686)
-* __fractunssiuda: Fixed-point fractional library routines.
- (line 1698)
-* __fractunssiudq: Fixed-point fractional library routines.
- (line 1693)
-* __fractunssiuha: Fixed-point fractional library routines.
- (line 1695)
-* __fractunssiuhq: Fixed-point fractional library routines.
- (line 1689)
-* __fractunssiuqq: Fixed-point fractional library routines.
- (line 1688)
-* __fractunssiusa: Fixed-point fractional library routines.
- (line 1696)
-* __fractunssiusq: Fixed-point fractional library routines.
- (line 1691)
-* __fractunssiuta: Fixed-point fractional library routines.
- (line 1700)
-* __fractunssqdi: Fixed-point fractional library routines.
- (line 1534)
-* __fractunssqhi: Fixed-point fractional library routines.
- (line 1532)
-* __fractunssqqi: Fixed-point fractional library routines.
- (line 1531)
-* __fractunssqsi: Fixed-point fractional library routines.
- (line 1533)
-* __fractunssqti: Fixed-point fractional library routines.
- (line 1535)
-* __fractunstadi: Fixed-point fractional library routines.
- (line 1560)
-* __fractunstahi: Fixed-point fractional library routines.
- (line 1558)
-* __fractunstaqi: Fixed-point fractional library routines.
- (line 1557)
-* __fractunstasi: Fixed-point fractional library routines.
- (line 1559)
-* __fractunstati: Fixed-point fractional library routines.
- (line 1562)
-* __fractunstida: Fixed-point fractional library routines.
- (line 1730)
-* __fractunstidq: Fixed-point fractional library routines.
- (line 1727)
-* __fractunstiha: Fixed-point fractional library routines.
- (line 1728)
-* __fractunstihq: Fixed-point fractional library routines.
- (line 1724)
-* __fractunstiqq: Fixed-point fractional library routines.
- (line 1723)
-* __fractunstisa: Fixed-point fractional library routines.
- (line 1729)
-* __fractunstisq: Fixed-point fractional library routines.
- (line 1725)
-* __fractunstita: Fixed-point fractional library routines.
- (line 1732)
-* __fractunstiuda: Fixed-point fractional library routines.
- (line 1746)
-* __fractunstiudq: Fixed-point fractional library routines.
- (line 1740)
-* __fractunstiuha: Fixed-point fractional library routines.
- (line 1742)
-* __fractunstiuhq: Fixed-point fractional library routines.
- (line 1736)
-* __fractunstiuqq: Fixed-point fractional library routines.
- (line 1734)
-* __fractunstiusa: Fixed-point fractional library routines.
- (line 1744)
-* __fractunstiusq: Fixed-point fractional library routines.
- (line 1738)
-* __fractunstiuta: Fixed-point fractional library routines.
- (line 1748)
-* __fractunsudadi: Fixed-point fractional library routines.
- (line 1622)
-* __fractunsudahi: Fixed-point fractional library routines.
- (line 1618)
-* __fractunsudaqi: Fixed-point fractional library routines.
- (line 1616)
-* __fractunsudasi: Fixed-point fractional library routines.
- (line 1620)
-* __fractunsudati: Fixed-point fractional library routines.
- (line 1624)
-* __fractunsudqdi: Fixed-point fractional library routines.
- (line 1596)
-* __fractunsudqhi: Fixed-point fractional library routines.
- (line 1592)
-* __fractunsudqqi: Fixed-point fractional library routines.
- (line 1590)
-* __fractunsudqsi: Fixed-point fractional library routines.
- (line 1594)
-* __fractunsudqti: Fixed-point fractional library routines.
- (line 1598)
-* __fractunsuhadi: Fixed-point fractional library routines.
- (line 1606)
-* __fractunsuhahi: Fixed-point fractional library routines.
- (line 1602)
-* __fractunsuhaqi: Fixed-point fractional library routines.
- (line 1600)
-* __fractunsuhasi: Fixed-point fractional library routines.
- (line 1604)
-* __fractunsuhati: Fixed-point fractional library routines.
- (line 1608)
-* __fractunsuhqdi: Fixed-point fractional library routines.
- (line 1576)
-* __fractunsuhqhi: Fixed-point fractional library routines.
- (line 1574)
-* __fractunsuhqqi: Fixed-point fractional library routines.
- (line 1573)
-* __fractunsuhqsi: Fixed-point fractional library routines.
- (line 1575)
-* __fractunsuhqti: Fixed-point fractional library routines.
- (line 1578)
-* __fractunsuqqdi: Fixed-point fractional library routines.
- (line 1570)
-* __fractunsuqqhi: Fixed-point fractional library routines.
- (line 1566)
-* __fractunsuqqqi: Fixed-point fractional library routines.
- (line 1564)
-* __fractunsuqqsi: Fixed-point fractional library routines.
- (line 1568)
-* __fractunsuqqti: Fixed-point fractional library routines.
- (line 1572)
-* __fractunsusadi: Fixed-point fractional library routines.
- (line 1612)
-* __fractunsusahi: Fixed-point fractional library routines.
- (line 1610)
-* __fractunsusaqi: Fixed-point fractional library routines.
- (line 1609)
-* __fractunsusasi: Fixed-point fractional library routines.
- (line 1611)
-* __fractunsusati: Fixed-point fractional library routines.
- (line 1614)
-* __fractunsusqdi: Fixed-point fractional library routines.
- (line 1586)
-* __fractunsusqhi: Fixed-point fractional library routines.
- (line 1582)
-* __fractunsusqqi: Fixed-point fractional library routines.
- (line 1580)
-* __fractunsusqsi: Fixed-point fractional library routines.
- (line 1584)
-* __fractunsusqti: Fixed-point fractional library routines.
- (line 1588)
-* __fractunsutadi: Fixed-point fractional library routines.
- (line 1632)
-* __fractunsutahi: Fixed-point fractional library routines.
- (line 1628)
-* __fractunsutaqi: Fixed-point fractional library routines.
- (line 1626)
-* __fractunsutasi: Fixed-point fractional library routines.
- (line 1630)
-* __fractunsutati: Fixed-point fractional library routines.
- (line 1634)
-* __fractuqqda: Fixed-point fractional library routines.
- (line 672)
-* __fractuqqdf: Fixed-point fractional library routines.
- (line 695)
-* __fractuqqdi: Fixed-point fractional library routines.
- (line 692)
-* __fractuqqdq: Fixed-point fractional library routines.
- (line 669)
-* __fractuqqha: Fixed-point fractional library routines.
- (line 670)
-* __fractuqqhi: Fixed-point fractional library routines.
- (line 690)
-* __fractuqqhq: Fixed-point fractional library routines.
- (line 666)
-* __fractuqqqi: Fixed-point fractional library routines.
- (line 689)
-* __fractuqqqq: Fixed-point fractional library routines.
- (line 665)
-* __fractuqqsa: Fixed-point fractional library routines.
- (line 671)
-* __fractuqqsf: Fixed-point fractional library routines.
- (line 694)
-* __fractuqqsi: Fixed-point fractional library routines.
- (line 691)
-* __fractuqqsq: Fixed-point fractional library routines.
- (line 667)
-* __fractuqqta: Fixed-point fractional library routines.
- (line 674)
-* __fractuqqti: Fixed-point fractional library routines.
- (line 693)
-* __fractuqquda: Fixed-point fractional library routines.
- (line 686)
-* __fractuqqudq2: Fixed-point fractional library routines.
- (line 680)
-* __fractuqquha: Fixed-point fractional library routines.
- (line 682)
-* __fractuqquhq2: Fixed-point fractional library routines.
- (line 676)
-* __fractuqqusa: Fixed-point fractional library routines.
- (line 684)
-* __fractuqqusq2: Fixed-point fractional library routines.
- (line 678)
-* __fractuqquta: Fixed-point fractional library routines.
- (line 688)
-* __fractusada: Fixed-point fractional library routines.
- (line 829)
-* __fractusadf: Fixed-point fractional library routines.
- (line 850)
-* __fractusadi: Fixed-point fractional library routines.
- (line 847)
-* __fractusadq: Fixed-point fractional library routines.
- (line 826)
-* __fractusaha: Fixed-point fractional library routines.
- (line 827)
-* __fractusahi: Fixed-point fractional library routines.
- (line 845)
-* __fractusahq: Fixed-point fractional library routines.
- (line 824)
-* __fractusaqi: Fixed-point fractional library routines.
- (line 844)
-* __fractusaqq: Fixed-point fractional library routines.
- (line 823)
-* __fractusasa: Fixed-point fractional library routines.
- (line 828)
-* __fractusasf: Fixed-point fractional library routines.
- (line 849)
-* __fractusasi: Fixed-point fractional library routines.
- (line 846)
-* __fractusasq: Fixed-point fractional library routines.
- (line 825)
-* __fractusata: Fixed-point fractional library routines.
- (line 830)
-* __fractusati: Fixed-point fractional library routines.
- (line 848)
-* __fractusauda2: Fixed-point fractional library routines.
- (line 841)
-* __fractusaudq: Fixed-point fractional library routines.
- (line 837)
-* __fractusauha2: Fixed-point fractional library routines.
- (line 839)
-* __fractusauhq: Fixed-point fractional library routines.
- (line 833)
-* __fractusauqq: Fixed-point fractional library routines.
- (line 832)
-* __fractusausq: Fixed-point fractional library routines.
- (line 835)
-* __fractusauta2: Fixed-point fractional library routines.
- (line 843)
-* __fractusqda: Fixed-point fractional library routines.
- (line 731)
-* __fractusqdf: Fixed-point fractional library routines.
- (line 754)
-* __fractusqdi: Fixed-point fractional library routines.
- (line 751)
-* __fractusqdq: Fixed-point fractional library routines.
- (line 728)
-* __fractusqha: Fixed-point fractional library routines.
- (line 729)
-* __fractusqhi: Fixed-point fractional library routines.
- (line 749)
-* __fractusqhq: Fixed-point fractional library routines.
- (line 725)
-* __fractusqqi: Fixed-point fractional library routines.
- (line 748)
-* __fractusqqq: Fixed-point fractional library routines.
- (line 724)
-* __fractusqsa: Fixed-point fractional library routines.
- (line 730)
-* __fractusqsf: Fixed-point fractional library routines.
- (line 753)
-* __fractusqsi: Fixed-point fractional library routines.
- (line 750)
-* __fractusqsq: Fixed-point fractional library routines.
- (line 726)
-* __fractusqta: Fixed-point fractional library routines.
- (line 733)
-* __fractusqti: Fixed-point fractional library routines.
- (line 752)
-* __fractusquda: Fixed-point fractional library routines.
- (line 745)
-* __fractusqudq2: Fixed-point fractional library routines.
- (line 739)
-* __fractusquha: Fixed-point fractional library routines.
- (line 741)
-* __fractusquhq2: Fixed-point fractional library routines.
- (line 737)
-* __fractusquqq2: Fixed-point fractional library routines.
- (line 735)
-* __fractusqusa: Fixed-point fractional library routines.
- (line 743)
-* __fractusquta: Fixed-point fractional library routines.
- (line 747)
-* __fractutada: Fixed-point fractional library routines.
- (line 893)
-* __fractutadf: Fixed-point fractional library routines.
- (line 918)
-* __fractutadi: Fixed-point fractional library routines.
- (line 914)
-* __fractutadq: Fixed-point fractional library routines.
- (line 888)
-* __fractutaha: Fixed-point fractional library routines.
- (line 890)
-* __fractutahi: Fixed-point fractional library routines.
- (line 912)
-* __fractutahq: Fixed-point fractional library routines.
- (line 884)
-* __fractutaqi: Fixed-point fractional library routines.
- (line 911)
-* __fractutaqq: Fixed-point fractional library routines.
- (line 883)
-* __fractutasa: Fixed-point fractional library routines.
- (line 891)
-* __fractutasf: Fixed-point fractional library routines.
- (line 917)
-* __fractutasi: Fixed-point fractional library routines.
- (line 913)
-* __fractutasq: Fixed-point fractional library routines.
- (line 886)
-* __fractutata: Fixed-point fractional library routines.
- (line 895)
-* __fractutati: Fixed-point fractional library routines.
- (line 916)
-* __fractutauda2: Fixed-point fractional library routines.
- (line 909)
-* __fractutaudq: Fixed-point fractional library routines.
- (line 903)
-* __fractutauha2: Fixed-point fractional library routines.
- (line 905)
-* __fractutauhq: Fixed-point fractional library routines.
- (line 899)
-* __fractutauqq: Fixed-point fractional library routines.
- (line 897)
-* __fractutausa2: Fixed-point fractional library routines.
- (line 907)
-* __fractutausq: Fixed-point fractional library routines.
- (line 901)
-* __gedf2: Soft float library routines.
- (line 206)
-* __gesf2: Soft float library routines.
- (line 205)
-* __getf2: Soft float library routines.
- (line 207)
-* __gtdf2: Soft float library routines.
- (line 224)
-* __gtsf2: Soft float library routines.
- (line 223)
-* __gttf2: Soft float library routines.
- (line 225)
-* __ledf2: Soft float library routines.
- (line 218)
-* __lesf2: Soft float library routines.
- (line 217)
-* __letf2: Soft float library routines.
- (line 219)
-* __lshrdi3: Integer library routines.
- (line 31)
-* __lshrsi3: Integer library routines.
- (line 30)
-* __lshrti3: Integer library routines.
- (line 32)
-* __lshruda3: Fixed-point fractional library routines.
- (line 390)
-* __lshrudq3: Fixed-point fractional library routines.
- (line 384)
-* __lshruha3: Fixed-point fractional library routines.
- (line 386)
-* __lshruhq3: Fixed-point fractional library routines.
- (line 380)
-* __lshruqq3: Fixed-point fractional library routines.
- (line 378)
-* __lshrusa3: Fixed-point fractional library routines.
- (line 388)
-* __lshrusq3: Fixed-point fractional library routines.
- (line 382)
-* __lshruta3: Fixed-point fractional library routines.
- (line 392)
-* __ltdf2: Soft float library routines.
- (line 212)
-* __ltsf2: Soft float library routines.
- (line 211)
-* __lttf2: Soft float library routines.
- (line 213)
-* __main: Collect2. (line 15)
-* __moddi3: Integer library routines.
- (line 37)
-* __modsi3: Integer library routines.
- (line 36)
-* __modti3: Integer library routines.
- (line 38)
-* __morestack_current_segment: Miscellaneous routines.
- (line 46)
-* __morestack_initial_sp: Miscellaneous routines.
- (line 47)
-* __morestack_segments: Miscellaneous routines.
- (line 45)
-* __mulda3: Fixed-point fractional library routines.
- (line 171)
-* __muldc3: Soft float library routines.
- (line 241)
-* __muldf3: Soft float library routines.
- (line 40)
-* __muldi3: Integer library routines.
- (line 43)
-* __muldq3: Fixed-point fractional library routines.
- (line 159)
-* __mulha3: Fixed-point fractional library routines.
- (line 169)
-* __mulhq3: Fixed-point fractional library routines.
- (line 156)
-* __mulqq3: Fixed-point fractional library routines.
- (line 155)
-* __mulsa3: Fixed-point fractional library routines.
- (line 170)
-* __mulsc3: Soft float library routines.
- (line 239)
-* __mulsf3: Soft float library routines.
- (line 39)
-* __mulsi3: Integer library routines.
- (line 42)
-* __mulsq3: Fixed-point fractional library routines.
- (line 157)
-* __multa3: Fixed-point fractional library routines.
- (line 173)
-* __multc3: Soft float library routines.
- (line 243)
-* __multf3: Soft float library routines.
- (line 42)
-* __multi3: Integer library routines.
- (line 44)
-* __muluda3: Fixed-point fractional library routines.
- (line 179)
-* __muludq3: Fixed-point fractional library routines.
- (line 167)
-* __muluha3: Fixed-point fractional library routines.
- (line 175)
-* __muluhq3: Fixed-point fractional library routines.
- (line 163)
-* __muluqq3: Fixed-point fractional library routines.
- (line 161)
-* __mulusa3: Fixed-point fractional library routines.
- (line 177)
-* __mulusq3: Fixed-point fractional library routines.
- (line 165)
-* __muluta3: Fixed-point fractional library routines.
- (line 181)
-* __mulvdi3: Integer library routines.
- (line 115)
-* __mulvsi3: Integer library routines.
- (line 114)
-* __mulxc3: Soft float library routines.
- (line 245)
-* __mulxf3: Soft float library routines.
- (line 44)
-* __nedf2: Soft float library routines.
- (line 200)
-* __negda2: Fixed-point fractional library routines.
- (line 299)
-* __negdf2: Soft float library routines.
- (line 56)
-* __negdi2: Integer library routines.
- (line 47)
-* __negdq2: Fixed-point fractional library routines.
- (line 289)
-* __negha2: Fixed-point fractional library routines.
- (line 297)
-* __neghq2: Fixed-point fractional library routines.
- (line 287)
-* __negqq2: Fixed-point fractional library routines.
- (line 286)
-* __negsa2: Fixed-point fractional library routines.
- (line 298)
-* __negsf2: Soft float library routines.
- (line 55)
-* __negsq2: Fixed-point fractional library routines.
- (line 288)
-* __negta2: Fixed-point fractional library routines.
- (line 300)
-* __negtf2: Soft float library routines.
- (line 57)
-* __negti2: Integer library routines.
- (line 48)
-* __neguda2: Fixed-point fractional library routines.
- (line 305)
-* __negudq2: Fixed-point fractional library routines.
- (line 296)
-* __neguha2: Fixed-point fractional library routines.
- (line 302)
-* __neguhq2: Fixed-point fractional library routines.
- (line 292)
-* __neguqq2: Fixed-point fractional library routines.
- (line 291)
-* __negusa2: Fixed-point fractional library routines.
- (line 303)
-* __negusq2: Fixed-point fractional library routines.
- (line 294)
-* __neguta2: Fixed-point fractional library routines.
- (line 307)
-* __negvdi2: Integer library routines.
- (line 119)
-* __negvsi2: Integer library routines.
- (line 118)
-* __negxf2: Soft float library routines.
- (line 58)
-* __nesf2: Soft float library routines.
- (line 199)
-* __netf2: Soft float library routines.
- (line 201)
-* __paritydi2: Integer library routines.
- (line 151)
-* __paritysi2: Integer library routines.
- (line 150)
-* __parityti2: Integer library routines.
- (line 152)
-* __popcountdi2: Integer library routines.
- (line 157)
-* __popcountsi2: Integer library routines.
- (line 156)
-* __popcountti2: Integer library routines.
- (line 158)
-* __powidf2: Soft float library routines.
- (line 233)
-* __powisf2: Soft float library routines.
- (line 232)
-* __powitf2: Soft float library routines.
- (line 234)
-* __powixf2: Soft float library routines.
- (line 235)
-* __satfractdadq: Fixed-point fractional library routines.
- (line 1153)
-* __satfractdaha2: Fixed-point fractional library routines.
- (line 1154)
-* __satfractdahq: Fixed-point fractional library routines.
- (line 1151)
-* __satfractdaqq: Fixed-point fractional library routines.
- (line 1150)
-* __satfractdasa2: Fixed-point fractional library routines.
- (line 1155)
-* __satfractdasq: Fixed-point fractional library routines.
- (line 1152)
-* __satfractdata2: Fixed-point fractional library routines.
- (line 1156)
-* __satfractdauda: Fixed-point fractional library routines.
- (line 1166)
-* __satfractdaudq: Fixed-point fractional library routines.
- (line 1162)
-* __satfractdauha: Fixed-point fractional library routines.
- (line 1164)
-* __satfractdauhq: Fixed-point fractional library routines.
- (line 1159)
-* __satfractdauqq: Fixed-point fractional library routines.
- (line 1158)
-* __satfractdausa: Fixed-point fractional library routines.
- (line 1165)
-* __satfractdausq: Fixed-point fractional library routines.
- (line 1160)
-* __satfractdauta: Fixed-point fractional library routines.
- (line 1168)
-* __satfractdfda: Fixed-point fractional library routines.
- (line 1506)
-* __satfractdfdq: Fixed-point fractional library routines.
- (line 1503)
-* __satfractdfha: Fixed-point fractional library routines.
- (line 1504)
-* __satfractdfhq: Fixed-point fractional library routines.
- (line 1501)
-* __satfractdfqq: Fixed-point fractional library routines.
- (line 1500)
-* __satfractdfsa: Fixed-point fractional library routines.
- (line 1505)
-* __satfractdfsq: Fixed-point fractional library routines.
- (line 1502)
-* __satfractdfta: Fixed-point fractional library routines.
- (line 1507)
-* __satfractdfuda: Fixed-point fractional library routines.
- (line 1515)
-* __satfractdfudq: Fixed-point fractional library routines.
- (line 1512)
-* __satfractdfuha: Fixed-point fractional library routines.
- (line 1513)
-* __satfractdfuhq: Fixed-point fractional library routines.
- (line 1509)
-* __satfractdfuqq: Fixed-point fractional library routines.
- (line 1508)
-* __satfractdfusa: Fixed-point fractional library routines.
- (line 1514)
-* __satfractdfusq: Fixed-point fractional library routines.
- (line 1510)
-* __satfractdfuta: Fixed-point fractional library routines.
- (line 1517)
-* __satfractdida: Fixed-point fractional library routines.
- (line 1456)
-* __satfractdidq: Fixed-point fractional library routines.
- (line 1453)
-* __satfractdiha: Fixed-point fractional library routines.
- (line 1454)
-* __satfractdihq: Fixed-point fractional library routines.
- (line 1451)
-* __satfractdiqq: Fixed-point fractional library routines.
- (line 1450)
-* __satfractdisa: Fixed-point fractional library routines.
- (line 1455)
-* __satfractdisq: Fixed-point fractional library routines.
- (line 1452)
-* __satfractdita: Fixed-point fractional library routines.
- (line 1457)
-* __satfractdiuda: Fixed-point fractional library routines.
- (line 1464)
-* __satfractdiudq: Fixed-point fractional library routines.
- (line 1461)
-* __satfractdiuha: Fixed-point fractional library routines.
- (line 1462)
-* __satfractdiuhq: Fixed-point fractional library routines.
- (line 1459)
-* __satfractdiuqq: Fixed-point fractional library routines.
- (line 1458)
-* __satfractdiusa: Fixed-point fractional library routines.
- (line 1463)
-* __satfractdiusq: Fixed-point fractional library routines.
- (line 1460)
-* __satfractdiuta: Fixed-point fractional library routines.
- (line 1465)
-* __satfractdqda: Fixed-point fractional library routines.
- (line 1098)
-* __satfractdqha: Fixed-point fractional library routines.
- (line 1096)
-* __satfractdqhq2: Fixed-point fractional library routines.
- (line 1094)
-* __satfractdqqq2: Fixed-point fractional library routines.
- (line 1093)
-* __satfractdqsa: Fixed-point fractional library routines.
- (line 1097)
-* __satfractdqsq2: Fixed-point fractional library routines.
- (line 1095)
-* __satfractdqta: Fixed-point fractional library routines.
- (line 1099)
-* __satfractdquda: Fixed-point fractional library routines.
- (line 1111)
-* __satfractdqudq: Fixed-point fractional library routines.
- (line 1106)
-* __satfractdquha: Fixed-point fractional library routines.
- (line 1108)
-* __satfractdquhq: Fixed-point fractional library routines.
- (line 1102)
-* __satfractdquqq: Fixed-point fractional library routines.
- (line 1101)
-* __satfractdqusa: Fixed-point fractional library routines.
- (line 1109)
-* __satfractdqusq: Fixed-point fractional library routines.
- (line 1104)
-* __satfractdquta: Fixed-point fractional library routines.
- (line 1113)
-* __satfracthada2: Fixed-point fractional library routines.
- (line 1119)
-* __satfracthadq: Fixed-point fractional library routines.
- (line 1117)
-* __satfracthahq: Fixed-point fractional library routines.
- (line 1115)
-* __satfracthaqq: Fixed-point fractional library routines.
- (line 1114)
-* __satfracthasa2: Fixed-point fractional library routines.
- (line 1118)
-* __satfracthasq: Fixed-point fractional library routines.
- (line 1116)
-* __satfracthata2: Fixed-point fractional library routines.
- (line 1120)
-* __satfracthauda: Fixed-point fractional library routines.
- (line 1132)
-* __satfracthaudq: Fixed-point fractional library routines.
- (line 1127)
-* __satfracthauha: Fixed-point fractional library routines.
- (line 1129)
-* __satfracthauhq: Fixed-point fractional library routines.
- (line 1123)
-* __satfracthauqq: Fixed-point fractional library routines.
- (line 1122)
-* __satfracthausa: Fixed-point fractional library routines.
- (line 1130)
-* __satfracthausq: Fixed-point fractional library routines.
- (line 1125)
-* __satfracthauta: Fixed-point fractional library routines.
- (line 1134)
-* __satfracthida: Fixed-point fractional library routines.
- (line 1424)
-* __satfracthidq: Fixed-point fractional library routines.
- (line 1421)
-* __satfracthiha: Fixed-point fractional library routines.
- (line 1422)
-* __satfracthihq: Fixed-point fractional library routines.
- (line 1419)
-* __satfracthiqq: Fixed-point fractional library routines.
- (line 1418)
-* __satfracthisa: Fixed-point fractional library routines.
- (line 1423)
-* __satfracthisq: Fixed-point fractional library routines.
- (line 1420)
-* __satfracthita: Fixed-point fractional library routines.
- (line 1425)
-* __satfracthiuda: Fixed-point fractional library routines.
- (line 1432)
-* __satfracthiudq: Fixed-point fractional library routines.
- (line 1429)
-* __satfracthiuha: Fixed-point fractional library routines.
- (line 1430)
-* __satfracthiuhq: Fixed-point fractional library routines.
- (line 1427)
-* __satfracthiuqq: Fixed-point fractional library routines.
- (line 1426)
-* __satfracthiusa: Fixed-point fractional library routines.
- (line 1431)
-* __satfracthiusq: Fixed-point fractional library routines.
- (line 1428)
-* __satfracthiuta: Fixed-point fractional library routines.
- (line 1433)
-* __satfracthqda: Fixed-point fractional library routines.
- (line 1064)
-* __satfracthqdq2: Fixed-point fractional library routines.
- (line 1061)
-* __satfracthqha: Fixed-point fractional library routines.
- (line 1062)
-* __satfracthqqq2: Fixed-point fractional library routines.
- (line 1059)
-* __satfracthqsa: Fixed-point fractional library routines.
- (line 1063)
-* __satfracthqsq2: Fixed-point fractional library routines.
- (line 1060)
-* __satfracthqta: Fixed-point fractional library routines.
- (line 1065)
-* __satfracthquda: Fixed-point fractional library routines.
- (line 1072)
-* __satfracthqudq: Fixed-point fractional library routines.
- (line 1069)
-* __satfracthquha: Fixed-point fractional library routines.
- (line 1070)
-* __satfracthquhq: Fixed-point fractional library routines.
- (line 1067)
-* __satfracthquqq: Fixed-point fractional library routines.
- (line 1066)
-* __satfracthqusa: Fixed-point fractional library routines.
- (line 1071)
-* __satfracthqusq: Fixed-point fractional library routines.
- (line 1068)
-* __satfracthquta: Fixed-point fractional library routines.
- (line 1073)
-* __satfractqida: Fixed-point fractional library routines.
- (line 1402)
-* __satfractqidq: Fixed-point fractional library routines.
- (line 1399)
-* __satfractqiha: Fixed-point fractional library routines.
- (line 1400)
-* __satfractqihq: Fixed-point fractional library routines.
- (line 1397)
-* __satfractqiqq: Fixed-point fractional library routines.
- (line 1396)
-* __satfractqisa: Fixed-point fractional library routines.
- (line 1401)
-* __satfractqisq: Fixed-point fractional library routines.
- (line 1398)
-* __satfractqita: Fixed-point fractional library routines.
- (line 1403)
-* __satfractqiuda: Fixed-point fractional library routines.
- (line 1415)
-* __satfractqiudq: Fixed-point fractional library routines.
- (line 1410)
-* __satfractqiuha: Fixed-point fractional library routines.
- (line 1412)
-* __satfractqiuhq: Fixed-point fractional library routines.
- (line 1406)
-* __satfractqiuqq: Fixed-point fractional library routines.
- (line 1405)
-* __satfractqiusa: Fixed-point fractional library routines.
- (line 1413)
-* __satfractqiusq: Fixed-point fractional library routines.
- (line 1408)
-* __satfractqiuta: Fixed-point fractional library routines.
- (line 1417)
-* __satfractqqda: Fixed-point fractional library routines.
- (line 1043)
-* __satfractqqdq2: Fixed-point fractional library routines.
- (line 1040)
-* __satfractqqha: Fixed-point fractional library routines.
- (line 1041)
-* __satfractqqhq2: Fixed-point fractional library routines.
- (line 1038)
-* __satfractqqsa: Fixed-point fractional library routines.
- (line 1042)
-* __satfractqqsq2: Fixed-point fractional library routines.
- (line 1039)
-* __satfractqqta: Fixed-point fractional library routines.
- (line 1044)
-* __satfractqquda: Fixed-point fractional library routines.
- (line 1056)
-* __satfractqqudq: Fixed-point fractional library routines.
- (line 1051)
-* __satfractqquha: Fixed-point fractional library routines.
- (line 1053)
-* __satfractqquhq: Fixed-point fractional library routines.
- (line 1047)
-* __satfractqquqq: Fixed-point fractional library routines.
- (line 1046)
-* __satfractqqusa: Fixed-point fractional library routines.
- (line 1054)
-* __satfractqqusq: Fixed-point fractional library routines.
- (line 1049)
-* __satfractqquta: Fixed-point fractional library routines.
- (line 1058)
-* __satfractsada2: Fixed-point fractional library routines.
- (line 1140)
-* __satfractsadq: Fixed-point fractional library routines.
- (line 1138)
-* __satfractsaha2: Fixed-point fractional library routines.
- (line 1139)
-* __satfractsahq: Fixed-point fractional library routines.
- (line 1136)
-* __satfractsaqq: Fixed-point fractional library routines.
- (line 1135)
-* __satfractsasq: Fixed-point fractional library routines.
- (line 1137)
-* __satfractsata2: Fixed-point fractional library routines.
- (line 1141)
-* __satfractsauda: Fixed-point fractional library routines.
- (line 1148)
-* __satfractsaudq: Fixed-point fractional library routines.
- (line 1145)
-* __satfractsauha: Fixed-point fractional library routines.
- (line 1146)
-* __satfractsauhq: Fixed-point fractional library routines.
- (line 1143)
-* __satfractsauqq: Fixed-point fractional library routines.
- (line 1142)
-* __satfractsausa: Fixed-point fractional library routines.
- (line 1147)
-* __satfractsausq: Fixed-point fractional library routines.
- (line 1144)
-* __satfractsauta: Fixed-point fractional library routines.
- (line 1149)
-* __satfractsfda: Fixed-point fractional library routines.
- (line 1490)
-* __satfractsfdq: Fixed-point fractional library routines.
- (line 1487)
-* __satfractsfha: Fixed-point fractional library routines.
- (line 1488)
-* __satfractsfhq: Fixed-point fractional library routines.
- (line 1485)
-* __satfractsfqq: Fixed-point fractional library routines.
- (line 1484)
-* __satfractsfsa: Fixed-point fractional library routines.
- (line 1489)
-* __satfractsfsq: Fixed-point fractional library routines.
- (line 1486)
-* __satfractsfta: Fixed-point fractional library routines.
- (line 1491)
-* __satfractsfuda: Fixed-point fractional library routines.
- (line 1498)
-* __satfractsfudq: Fixed-point fractional library routines.
- (line 1495)
-* __satfractsfuha: Fixed-point fractional library routines.
- (line 1496)
-* __satfractsfuhq: Fixed-point fractional library routines.
- (line 1493)
-* __satfractsfuqq: Fixed-point fractional library routines.
- (line 1492)
-* __satfractsfusa: Fixed-point fractional library routines.
- (line 1497)
-* __satfractsfusq: Fixed-point fractional library routines.
- (line 1494)
-* __satfractsfuta: Fixed-point fractional library routines.
- (line 1499)
-* __satfractsida: Fixed-point fractional library routines.
- (line 1440)
-* __satfractsidq: Fixed-point fractional library routines.
- (line 1437)
-* __satfractsiha: Fixed-point fractional library routines.
- (line 1438)
-* __satfractsihq: Fixed-point fractional library routines.
- (line 1435)
-* __satfractsiqq: Fixed-point fractional library routines.
- (line 1434)
-* __satfractsisa: Fixed-point fractional library routines.
- (line 1439)
-* __satfractsisq: Fixed-point fractional library routines.
- (line 1436)
-* __satfractsita: Fixed-point fractional library routines.
- (line 1441)
-* __satfractsiuda: Fixed-point fractional library routines.
- (line 1448)
-* __satfractsiudq: Fixed-point fractional library routines.
- (line 1445)
-* __satfractsiuha: Fixed-point fractional library routines.
- (line 1446)
-* __satfractsiuhq: Fixed-point fractional library routines.
- (line 1443)
-* __satfractsiuqq: Fixed-point fractional library routines.
- (line 1442)
-* __satfractsiusa: Fixed-point fractional library routines.
- (line 1447)
-* __satfractsiusq: Fixed-point fractional library routines.
- (line 1444)
-* __satfractsiuta: Fixed-point fractional library routines.
- (line 1449)
-* __satfractsqda: Fixed-point fractional library routines.
- (line 1079)
-* __satfractsqdq2: Fixed-point fractional library routines.
- (line 1076)
-* __satfractsqha: Fixed-point fractional library routines.
- (line 1077)
-* __satfractsqhq2: Fixed-point fractional library routines.
- (line 1075)
-* __satfractsqqq2: Fixed-point fractional library routines.
- (line 1074)
-* __satfractsqsa: Fixed-point fractional library routines.
- (line 1078)
-* __satfractsqta: Fixed-point fractional library routines.
- (line 1080)
-* __satfractsquda: Fixed-point fractional library routines.
- (line 1090)
-* __satfractsqudq: Fixed-point fractional library routines.
- (line 1086)
-* __satfractsquha: Fixed-point fractional library routines.
- (line 1088)
-* __satfractsquhq: Fixed-point fractional library routines.
- (line 1083)
-* __satfractsquqq: Fixed-point fractional library routines.
- (line 1082)
-* __satfractsqusa: Fixed-point fractional library routines.
- (line 1089)
-* __satfractsqusq: Fixed-point fractional library routines.
- (line 1084)
-* __satfractsquta: Fixed-point fractional library routines.
- (line 1092)
-* __satfracttada2: Fixed-point fractional library routines.
- (line 1175)
-* __satfracttadq: Fixed-point fractional library routines.
- (line 1172)
-* __satfracttaha2: Fixed-point fractional library routines.
- (line 1173)
-* __satfracttahq: Fixed-point fractional library routines.
- (line 1170)
-* __satfracttaqq: Fixed-point fractional library routines.
- (line 1169)
-* __satfracttasa2: Fixed-point fractional library routines.
- (line 1174)
-* __satfracttasq: Fixed-point fractional library routines.
- (line 1171)
-* __satfracttauda: Fixed-point fractional library routines.
- (line 1187)
-* __satfracttaudq: Fixed-point fractional library routines.
- (line 1182)
-* __satfracttauha: Fixed-point fractional library routines.
- (line 1184)
-* __satfracttauhq: Fixed-point fractional library routines.
- (line 1178)
-* __satfracttauqq: Fixed-point fractional library routines.
- (line 1177)
-* __satfracttausa: Fixed-point fractional library routines.
- (line 1185)
-* __satfracttausq: Fixed-point fractional library routines.
- (line 1180)
-* __satfracttauta: Fixed-point fractional library routines.
- (line 1189)
-* __satfracttida: Fixed-point fractional library routines.
- (line 1472)
-* __satfracttidq: Fixed-point fractional library routines.
- (line 1469)
-* __satfracttiha: Fixed-point fractional library routines.
- (line 1470)
-* __satfracttihq: Fixed-point fractional library routines.
- (line 1467)
-* __satfracttiqq: Fixed-point fractional library routines.
- (line 1466)
-* __satfracttisa: Fixed-point fractional library routines.
- (line 1471)
-* __satfracttisq: Fixed-point fractional library routines.
- (line 1468)
-* __satfracttita: Fixed-point fractional library routines.
- (line 1473)
-* __satfracttiuda: Fixed-point fractional library routines.
- (line 1481)
-* __satfracttiudq: Fixed-point fractional library routines.
- (line 1478)
-* __satfracttiuha: Fixed-point fractional library routines.
- (line 1479)
-* __satfracttiuhq: Fixed-point fractional library routines.
- (line 1475)
-* __satfracttiuqq: Fixed-point fractional library routines.
- (line 1474)
-* __satfracttiusa: Fixed-point fractional library routines.
- (line 1480)
-* __satfracttiusq: Fixed-point fractional library routines.
- (line 1476)
-* __satfracttiuta: Fixed-point fractional library routines.
- (line 1483)
-* __satfractudada: Fixed-point fractional library routines.
- (line 1351)
-* __satfractudadq: Fixed-point fractional library routines.
- (line 1347)
-* __satfractudaha: Fixed-point fractional library routines.
- (line 1349)
-* __satfractudahq: Fixed-point fractional library routines.
- (line 1344)
-* __satfractudaqq: Fixed-point fractional library routines.
- (line 1343)
-* __satfractudasa: Fixed-point fractional library routines.
- (line 1350)
-* __satfractudasq: Fixed-point fractional library routines.
- (line 1345)
-* __satfractudata: Fixed-point fractional library routines.
- (line 1353)
-* __satfractudaudq: Fixed-point fractional library routines.
- (line 1361)
-* __satfractudauha2: Fixed-point fractional library routines.
- (line 1363)
-* __satfractudauhq: Fixed-point fractional library routines.
- (line 1357)
-* __satfractudauqq: Fixed-point fractional library routines.
- (line 1355)
-* __satfractudausa2: Fixed-point fractional library routines.
- (line 1365)
-* __satfractudausq: Fixed-point fractional library routines.
- (line 1359)
-* __satfractudauta2: Fixed-point fractional library routines.
- (line 1367)
-* __satfractudqda: Fixed-point fractional library routines.
- (line 1276)
-* __satfractudqdq: Fixed-point fractional library routines.
- (line 1271)
-* __satfractudqha: Fixed-point fractional library routines.
- (line 1273)
-* __satfractudqhq: Fixed-point fractional library routines.
- (line 1267)
-* __satfractudqqq: Fixed-point fractional library routines.
- (line 1266)
-* __satfractudqsa: Fixed-point fractional library routines.
- (line 1274)
-* __satfractudqsq: Fixed-point fractional library routines.
- (line 1269)
-* __satfractudqta: Fixed-point fractional library routines.
- (line 1278)
-* __satfractudquda: Fixed-point fractional library routines.
- (line 1290)
-* __satfractudquha: Fixed-point fractional library routines.
- (line 1286)
-* __satfractudquhq2: Fixed-point fractional library routines.
- (line 1282)
-* __satfractudquqq2: Fixed-point fractional library routines.
- (line 1280)
-* __satfractudqusa: Fixed-point fractional library routines.
- (line 1288)
-* __satfractudqusq2: Fixed-point fractional library routines.
- (line 1284)
-* __satfractudquta: Fixed-point fractional library routines.
- (line 1292)
-* __satfractuhada: Fixed-point fractional library routines.
- (line 1304)
-* __satfractuhadq: Fixed-point fractional library routines.
- (line 1299)
-* __satfractuhaha: Fixed-point fractional library routines.
- (line 1301)
-* __satfractuhahq: Fixed-point fractional library routines.
- (line 1295)
-* __satfractuhaqq: Fixed-point fractional library routines.
- (line 1294)
-* __satfractuhasa: Fixed-point fractional library routines.
- (line 1302)
-* __satfractuhasq: Fixed-point fractional library routines.
- (line 1297)
-* __satfractuhata: Fixed-point fractional library routines.
- (line 1306)
-* __satfractuhauda2: Fixed-point fractional library routines.
- (line 1318)
-* __satfractuhaudq: Fixed-point fractional library routines.
- (line 1314)
-* __satfractuhauhq: Fixed-point fractional library routines.
- (line 1310)
-* __satfractuhauqq: Fixed-point fractional library routines.
- (line 1308)
-* __satfractuhausa2: Fixed-point fractional library routines.
- (line 1316)
-* __satfractuhausq: Fixed-point fractional library routines.
- (line 1312)
-* __satfractuhauta2: Fixed-point fractional library routines.
- (line 1320)
-* __satfractuhqda: Fixed-point fractional library routines.
- (line 1224)
-* __satfractuhqdq: Fixed-point fractional library routines.
- (line 1221)
-* __satfractuhqha: Fixed-point fractional library routines.
- (line 1222)
-* __satfractuhqhq: Fixed-point fractional library routines.
- (line 1219)
-* __satfractuhqqq: Fixed-point fractional library routines.
- (line 1218)
-* __satfractuhqsa: Fixed-point fractional library routines.
- (line 1223)
-* __satfractuhqsq: Fixed-point fractional library routines.
- (line 1220)
-* __satfractuhqta: Fixed-point fractional library routines.
- (line 1225)
-* __satfractuhquda: Fixed-point fractional library routines.
- (line 1236)
-* __satfractuhqudq2: Fixed-point fractional library routines.
- (line 1231)
-* __satfractuhquha: Fixed-point fractional library routines.
- (line 1233)
-* __satfractuhquqq2: Fixed-point fractional library routines.
- (line 1227)
-* __satfractuhqusa: Fixed-point fractional library routines.
- (line 1234)
-* __satfractuhqusq2: Fixed-point fractional library routines.
- (line 1229)
-* __satfractuhquta: Fixed-point fractional library routines.
- (line 1238)
-* __satfractunsdida: Fixed-point fractional library routines.
- (line 1834)
-* __satfractunsdidq: Fixed-point fractional library routines.
- (line 1831)
-* __satfractunsdiha: Fixed-point fractional library routines.
- (line 1832)
-* __satfractunsdihq: Fixed-point fractional library routines.
- (line 1828)
-* __satfractunsdiqq: Fixed-point fractional library routines.
- (line 1827)
-* __satfractunsdisa: Fixed-point fractional library routines.
- (line 1833)
-* __satfractunsdisq: Fixed-point fractional library routines.
- (line 1829)
-* __satfractunsdita: Fixed-point fractional library routines.
- (line 1836)
-* __satfractunsdiuda: Fixed-point fractional library routines.
- (line 1850)
-* __satfractunsdiudq: Fixed-point fractional library routines.
- (line 1844)
-* __satfractunsdiuha: Fixed-point fractional library routines.
- (line 1846)
-* __satfractunsdiuhq: Fixed-point fractional library routines.
- (line 1840)
-* __satfractunsdiuqq: Fixed-point fractional library routines.
- (line 1838)
-* __satfractunsdiusa: Fixed-point fractional library routines.
- (line 1848)
-* __satfractunsdiusq: Fixed-point fractional library routines.
- (line 1842)
-* __satfractunsdiuta: Fixed-point fractional library routines.
- (line 1852)
-* __satfractunshida: Fixed-point fractional library routines.
- (line 1786)
-* __satfractunshidq: Fixed-point fractional library routines.
- (line 1783)
-* __satfractunshiha: Fixed-point fractional library routines.
- (line 1784)
-* __satfractunshihq: Fixed-point fractional library routines.
- (line 1780)
-* __satfractunshiqq: Fixed-point fractional library routines.
- (line 1779)
-* __satfractunshisa: Fixed-point fractional library routines.
- (line 1785)
-* __satfractunshisq: Fixed-point fractional library routines.
- (line 1781)
-* __satfractunshita: Fixed-point fractional library routines.
- (line 1788)
-* __satfractunshiuda: Fixed-point fractional library routines.
- (line 1802)
-* __satfractunshiudq: Fixed-point fractional library routines.
- (line 1796)
-* __satfractunshiuha: Fixed-point fractional library routines.
- (line 1798)
-* __satfractunshiuhq: Fixed-point fractional library routines.
- (line 1792)
-* __satfractunshiuqq: Fixed-point fractional library routines.
- (line 1790)
-* __satfractunshiusa: Fixed-point fractional library routines.
- (line 1800)
-* __satfractunshiusq: Fixed-point fractional library routines.
- (line 1794)
-* __satfractunshiuta: Fixed-point fractional library routines.
- (line 1804)
-* __satfractunsqida: Fixed-point fractional library routines.
- (line 1760)
-* __satfractunsqidq: Fixed-point fractional library routines.
- (line 1757)
-* __satfractunsqiha: Fixed-point fractional library routines.
- (line 1758)
-* __satfractunsqihq: Fixed-point fractional library routines.
- (line 1754)
-* __satfractunsqiqq: Fixed-point fractional library routines.
- (line 1753)
-* __satfractunsqisa: Fixed-point fractional library routines.
- (line 1759)
-* __satfractunsqisq: Fixed-point fractional library routines.
- (line 1755)
-* __satfractunsqita: Fixed-point fractional library routines.
- (line 1762)
-* __satfractunsqiuda: Fixed-point fractional library routines.
- (line 1776)
-* __satfractunsqiudq: Fixed-point fractional library routines.
- (line 1770)
-* __satfractunsqiuha: Fixed-point fractional library routines.
- (line 1772)
-* __satfractunsqiuhq: Fixed-point fractional library routines.
- (line 1766)
-* __satfractunsqiuqq: Fixed-point fractional library routines.
- (line 1764)
-* __satfractunsqiusa: Fixed-point fractional library routines.
- (line 1774)
-* __satfractunsqiusq: Fixed-point fractional library routines.
- (line 1768)
-* __satfractunsqiuta: Fixed-point fractional library routines.
- (line 1778)
-* __satfractunssida: Fixed-point fractional library routines.
- (line 1811)
-* __satfractunssidq: Fixed-point fractional library routines.
- (line 1808)
-* __satfractunssiha: Fixed-point fractional library routines.
- (line 1809)
-* __satfractunssihq: Fixed-point fractional library routines.
- (line 1806)
-* __satfractunssiqq: Fixed-point fractional library routines.
- (line 1805)
-* __satfractunssisa: Fixed-point fractional library routines.
- (line 1810)
-* __satfractunssisq: Fixed-point fractional library routines.
- (line 1807)
-* __satfractunssita: Fixed-point fractional library routines.
- (line 1812)
-* __satfractunssiuda: Fixed-point fractional library routines.
- (line 1824)
-* __satfractunssiudq: Fixed-point fractional library routines.
- (line 1819)
-* __satfractunssiuha: Fixed-point fractional library routines.
- (line 1821)
-* __satfractunssiuhq: Fixed-point fractional library routines.
- (line 1815)
-* __satfractunssiuqq: Fixed-point fractional library routines.
- (line 1814)
-* __satfractunssiusa: Fixed-point fractional library routines.
- (line 1822)
-* __satfractunssiusq: Fixed-point fractional library routines.
- (line 1817)
-* __satfractunssiuta: Fixed-point fractional library routines.
- (line 1826)
-* __satfractunstida: Fixed-point fractional library routines.
- (line 1864)
-* __satfractunstidq: Fixed-point fractional library routines.
- (line 1859)
-* __satfractunstiha: Fixed-point fractional library routines.
- (line 1861)
-* __satfractunstihq: Fixed-point fractional library routines.
- (line 1855)
-* __satfractunstiqq: Fixed-point fractional library routines.
- (line 1854)
-* __satfractunstisa: Fixed-point fractional library routines.
- (line 1862)
-* __satfractunstisq: Fixed-point fractional library routines.
- (line 1857)
-* __satfractunstita: Fixed-point fractional library routines.
- (line 1866)
-* __satfractunstiuda: Fixed-point fractional library routines.
- (line 1880)
-* __satfractunstiudq: Fixed-point fractional library routines.
- (line 1874)
-* __satfractunstiuha: Fixed-point fractional library routines.
- (line 1876)
-* __satfractunstiuhq: Fixed-point fractional library routines.
- (line 1870)
-* __satfractunstiuqq: Fixed-point fractional library routines.
- (line 1868)
-* __satfractunstiusa: Fixed-point fractional library routines.
- (line 1878)
-* __satfractunstiusq: Fixed-point fractional library routines.
- (line 1872)
-* __satfractunstiuta: Fixed-point fractional library routines.
- (line 1882)
-* __satfractuqqda: Fixed-point fractional library routines.
- (line 1201)
-* __satfractuqqdq: Fixed-point fractional library routines.
- (line 1196)
-* __satfractuqqha: Fixed-point fractional library routines.
- (line 1198)
-* __satfractuqqhq: Fixed-point fractional library routines.
- (line 1192)
-* __satfractuqqqq: Fixed-point fractional library routines.
- (line 1191)
-* __satfractuqqsa: Fixed-point fractional library routines.
- (line 1199)
-* __satfractuqqsq: Fixed-point fractional library routines.
- (line 1194)
-* __satfractuqqta: Fixed-point fractional library routines.
- (line 1203)
-* __satfractuqquda: Fixed-point fractional library routines.
- (line 1215)
-* __satfractuqqudq2: Fixed-point fractional library routines.
- (line 1209)
-* __satfractuqquha: Fixed-point fractional library routines.
- (line 1211)
-* __satfractuqquhq2: Fixed-point fractional library routines.
- (line 1205)
-* __satfractuqqusa: Fixed-point fractional library routines.
- (line 1213)
-* __satfractuqqusq2: Fixed-point fractional library routines.
- (line 1207)
-* __satfractuqquta: Fixed-point fractional library routines.
- (line 1217)
-* __satfractusada: Fixed-point fractional library routines.
- (line 1327)
-* __satfractusadq: Fixed-point fractional library routines.
- (line 1324)
-* __satfractusaha: Fixed-point fractional library routines.
- (line 1325)
-* __satfractusahq: Fixed-point fractional library routines.
- (line 1322)
-* __satfractusaqq: Fixed-point fractional library routines.
- (line 1321)
-* __satfractusasa: Fixed-point fractional library routines.
- (line 1326)
-* __satfractusasq: Fixed-point fractional library routines.
- (line 1323)
-* __satfractusata: Fixed-point fractional library routines.
- (line 1328)
-* __satfractusauda2: Fixed-point fractional library routines.
- (line 1339)
-* __satfractusaudq: Fixed-point fractional library routines.
- (line 1335)
-* __satfractusauha2: Fixed-point fractional library routines.
- (line 1337)
-* __satfractusauhq: Fixed-point fractional library routines.
- (line 1331)
-* __satfractusauqq: Fixed-point fractional library routines.
- (line 1330)
-* __satfractusausq: Fixed-point fractional library routines.
- (line 1333)
-* __satfractusauta2: Fixed-point fractional library routines.
- (line 1341)
-* __satfractusqda: Fixed-point fractional library routines.
- (line 1248)
-* __satfractusqdq: Fixed-point fractional library routines.
- (line 1244)
-* __satfractusqha: Fixed-point fractional library routines.
- (line 1246)
-* __satfractusqhq: Fixed-point fractional library routines.
- (line 1241)
-* __satfractusqqq: Fixed-point fractional library routines.
- (line 1240)
-* __satfractusqsa: Fixed-point fractional library routines.
- (line 1247)
-* __satfractusqsq: Fixed-point fractional library routines.
- (line 1242)
-* __satfractusqta: Fixed-point fractional library routines.
- (line 1250)
-* __satfractusquda: Fixed-point fractional library routines.
- (line 1262)
-* __satfractusqudq2: Fixed-point fractional library routines.
- (line 1256)
-* __satfractusquha: Fixed-point fractional library routines.
- (line 1258)
-* __satfractusquhq2: Fixed-point fractional library routines.
- (line 1254)
-* __satfractusquqq2: Fixed-point fractional library routines.
- (line 1252)
-* __satfractusqusa: Fixed-point fractional library routines.
- (line 1260)
-* __satfractusquta: Fixed-point fractional library routines.
- (line 1264)
-* __satfractutada: Fixed-point fractional library routines.
- (line 1379)
-* __satfractutadq: Fixed-point fractional library routines.
- (line 1374)
-* __satfractutaha: Fixed-point fractional library routines.
- (line 1376)
-* __satfractutahq: Fixed-point fractional library routines.
- (line 1370)
-* __satfractutaqq: Fixed-point fractional library routines.
- (line 1369)
-* __satfractutasa: Fixed-point fractional library routines.
- (line 1377)
-* __satfractutasq: Fixed-point fractional library routines.
- (line 1372)
-* __satfractutata: Fixed-point fractional library routines.
- (line 1381)
-* __satfractutauda2: Fixed-point fractional library routines.
- (line 1395)
-* __satfractutaudq: Fixed-point fractional library routines.
- (line 1389)
-* __satfractutauha2: Fixed-point fractional library routines.
- (line 1391)
-* __satfractutauhq: Fixed-point fractional library routines.
- (line 1385)
-* __satfractutauqq: Fixed-point fractional library routines.
- (line 1383)
-* __satfractutausa2: Fixed-point fractional library routines.
- (line 1393)
-* __satfractutausq: Fixed-point fractional library routines.
- (line 1387)
-* __splitstack_find: Miscellaneous routines.
- (line 18)
-* __ssaddda3: Fixed-point fractional library routines.
- (line 67)
-* __ssadddq3: Fixed-point fractional library routines.
- (line 63)
-* __ssaddha3: Fixed-point fractional library routines.
- (line 65)
-* __ssaddhq3: Fixed-point fractional library routines.
- (line 60)
-* __ssaddqq3: Fixed-point fractional library routines.
- (line 59)
-* __ssaddsa3: Fixed-point fractional library routines.
- (line 66)
-* __ssaddsq3: Fixed-point fractional library routines.
- (line 61)
-* __ssaddta3: Fixed-point fractional library routines.
- (line 69)
-* __ssashlda3: Fixed-point fractional library routines.
- (line 402)
-* __ssashldq3: Fixed-point fractional library routines.
- (line 399)
-* __ssashlha3: Fixed-point fractional library routines.
- (line 400)
-* __ssashlhq3: Fixed-point fractional library routines.
- (line 396)
-* __ssashlsa3: Fixed-point fractional library routines.
- (line 401)
-* __ssashlsq3: Fixed-point fractional library routines.
- (line 397)
-* __ssashlta3: Fixed-point fractional library routines.
- (line 404)
-* __ssdivda3: Fixed-point fractional library routines.
- (line 261)
-* __ssdivdq3: Fixed-point fractional library routines.
- (line 257)
-* __ssdivha3: Fixed-point fractional library routines.
- (line 259)
-* __ssdivhq3: Fixed-point fractional library routines.
- (line 254)
-* __ssdivqq3: Fixed-point fractional library routines.
- (line 253)
-* __ssdivsa3: Fixed-point fractional library routines.
- (line 260)
-* __ssdivsq3: Fixed-point fractional library routines.
- (line 255)
-* __ssdivta3: Fixed-point fractional library routines.
- (line 263)
-* __ssmulda3: Fixed-point fractional library routines.
- (line 193)
-* __ssmuldq3: Fixed-point fractional library routines.
- (line 189)
-* __ssmulha3: Fixed-point fractional library routines.
- (line 191)
-* __ssmulhq3: Fixed-point fractional library routines.
- (line 186)
-* __ssmulqq3: Fixed-point fractional library routines.
- (line 185)
-* __ssmulsa3: Fixed-point fractional library routines.
- (line 192)
-* __ssmulsq3: Fixed-point fractional library routines.
- (line 187)
-* __ssmulta3: Fixed-point fractional library routines.
- (line 195)
-* __ssnegda2: Fixed-point fractional library routines.
- (line 316)
-* __ssnegdq2: Fixed-point fractional library routines.
- (line 313)
-* __ssnegha2: Fixed-point fractional library routines.
- (line 314)
-* __ssneghq2: Fixed-point fractional library routines.
- (line 311)
-* __ssnegqq2: Fixed-point fractional library routines.
- (line 310)
-* __ssnegsa2: Fixed-point fractional library routines.
- (line 315)
-* __ssnegsq2: Fixed-point fractional library routines.
- (line 312)
-* __ssnegta2: Fixed-point fractional library routines.
- (line 317)
-* __sssubda3: Fixed-point fractional library routines.
- (line 129)
-* __sssubdq3: Fixed-point fractional library routines.
- (line 125)
-* __sssubha3: Fixed-point fractional library routines.
- (line 127)
-* __sssubhq3: Fixed-point fractional library routines.
- (line 122)
-* __sssubqq3: Fixed-point fractional library routines.
- (line 121)
-* __sssubsa3: Fixed-point fractional library routines.
- (line 128)
-* __sssubsq3: Fixed-point fractional library routines.
- (line 123)
-* __sssubta3: Fixed-point fractional library routines.
- (line 131)
-* __subda3: Fixed-point fractional library routines.
- (line 107)
-* __subdf3: Soft float library routines.
- (line 31)
-* __subdq3: Fixed-point fractional library routines.
- (line 95)
-* __subha3: Fixed-point fractional library routines.
- (line 105)
-* __subhq3: Fixed-point fractional library routines.
- (line 92)
-* __subqq3: Fixed-point fractional library routines.
- (line 91)
-* __subsa3: Fixed-point fractional library routines.
- (line 106)
-* __subsf3: Soft float library routines.
- (line 30)
-* __subsq3: Fixed-point fractional library routines.
- (line 93)
-* __subta3: Fixed-point fractional library routines.
- (line 109)
-* __subtf3: Soft float library routines.
- (line 33)
-* __subuda3: Fixed-point fractional library routines.
- (line 115)
-* __subudq3: Fixed-point fractional library routines.
- (line 103)
-* __subuha3: Fixed-point fractional library routines.
- (line 111)
-* __subuhq3: Fixed-point fractional library routines.
- (line 99)
-* __subuqq3: Fixed-point fractional library routines.
- (line 97)
-* __subusa3: Fixed-point fractional library routines.
- (line 113)
-* __subusq3: Fixed-point fractional library routines.
- (line 101)
-* __subuta3: Fixed-point fractional library routines.
- (line 117)
-* __subvdi3: Integer library routines.
- (line 123)
-* __subvsi3: Integer library routines.
- (line 122)
-* __subxf3: Soft float library routines.
- (line 35)
-* __truncdfsf2: Soft float library routines.
- (line 76)
-* __trunctfdf2: Soft float library routines.
- (line 73)
-* __trunctfsf2: Soft float library routines.
- (line 75)
-* __truncxfdf2: Soft float library routines.
- (line 72)
-* __truncxfsf2: Soft float library routines.
- (line 74)
-* __ucmpdi2: Integer library routines.
- (line 93)
-* __ucmpti2: Integer library routines.
- (line 95)
-* __udivdi3: Integer library routines.
- (line 54)
-* __udivmoddi3: Integer library routines.
- (line 61)
-* __udivsi3: Integer library routines.
- (line 52)
-* __udivti3: Integer library routines.
- (line 63)
-* __udivuda3: Fixed-point fractional library routines.
- (line 246)
-* __udivudq3: Fixed-point fractional library routines.
- (line 240)
-* __udivuha3: Fixed-point fractional library routines.
- (line 242)
-* __udivuhq3: Fixed-point fractional library routines.
- (line 236)
-* __udivuqq3: Fixed-point fractional library routines.
- (line 234)
-* __udivusa3: Fixed-point fractional library routines.
- (line 244)
-* __udivusq3: Fixed-point fractional library routines.
- (line 238)
-* __udivuta3: Fixed-point fractional library routines.
- (line 248)
-* __umoddi3: Integer library routines.
- (line 71)
-* __umodsi3: Integer library routines.
- (line 69)
-* __umodti3: Integer library routines.
- (line 73)
-* __unorddf2: Soft float library routines.
- (line 173)
-* __unordsf2: Soft float library routines.
- (line 172)
-* __unordtf2: Soft float library routines.
- (line 174)
-* __usadduda3: Fixed-point fractional library routines.
- (line 85)
-* __usaddudq3: Fixed-point fractional library routines.
- (line 79)
-* __usadduha3: Fixed-point fractional library routines.
- (line 81)
-* __usadduhq3: Fixed-point fractional library routines.
- (line 75)
-* __usadduqq3: Fixed-point fractional library routines.
- (line 73)
-* __usaddusa3: Fixed-point fractional library routines.
- (line 83)
-* __usaddusq3: Fixed-point fractional library routines.
- (line 77)
-* __usadduta3: Fixed-point fractional library routines.
- (line 87)
-* __usashluda3: Fixed-point fractional library routines.
- (line 421)
-* __usashludq3: Fixed-point fractional library routines.
- (line 415)
-* __usashluha3: Fixed-point fractional library routines.
- (line 417)
-* __usashluhq3: Fixed-point fractional library routines.
- (line 411)
-* __usashluqq3: Fixed-point fractional library routines.
- (line 409)
-* __usashlusa3: Fixed-point fractional library routines.
- (line 419)
-* __usashlusq3: Fixed-point fractional library routines.
- (line 413)
-* __usashluta3: Fixed-point fractional library routines.
- (line 423)
-* __usdivuda3: Fixed-point fractional library routines.
- (line 280)
-* __usdivudq3: Fixed-point fractional library routines.
- (line 274)
-* __usdivuha3: Fixed-point fractional library routines.
- (line 276)
-* __usdivuhq3: Fixed-point fractional library routines.
- (line 270)
-* __usdivuqq3: Fixed-point fractional library routines.
- (line 268)
-* __usdivusa3: Fixed-point fractional library routines.
- (line 278)
-* __usdivusq3: Fixed-point fractional library routines.
- (line 272)
-* __usdivuta3: Fixed-point fractional library routines.
- (line 282)
-* __usmuluda3: Fixed-point fractional library routines.
- (line 212)
-* __usmuludq3: Fixed-point fractional library routines.
- (line 206)
-* __usmuluha3: Fixed-point fractional library routines.
- (line 208)
-* __usmuluhq3: Fixed-point fractional library routines.
- (line 202)
-* __usmuluqq3: Fixed-point fractional library routines.
- (line 200)
-* __usmulusa3: Fixed-point fractional library routines.
- (line 210)
-* __usmulusq3: Fixed-point fractional library routines.
- (line 204)
-* __usmuluta3: Fixed-point fractional library routines.
- (line 214)
-* __usneguda2: Fixed-point fractional library routines.
- (line 331)
-* __usnegudq2: Fixed-point fractional library routines.
- (line 326)
-* __usneguha2: Fixed-point fractional library routines.
- (line 328)
-* __usneguhq2: Fixed-point fractional library routines.
- (line 322)
-* __usneguqq2: Fixed-point fractional library routines.
- (line 321)
-* __usnegusa2: Fixed-point fractional library routines.
- (line 329)
-* __usnegusq2: Fixed-point fractional library routines.
- (line 324)
-* __usneguta2: Fixed-point fractional library routines.
- (line 333)
-* __ussubuda3: Fixed-point fractional library routines.
- (line 148)
-* __ussubudq3: Fixed-point fractional library routines.
- (line 142)
-* __ussubuha3: Fixed-point fractional library routines.
- (line 144)
-* __ussubuhq3: Fixed-point fractional library routines.
- (line 138)
-* __ussubuqq3: Fixed-point fractional library routines.
- (line 136)
-* __ussubusa3: Fixed-point fractional library routines.
- (line 146)
-* __ussubusq3: Fixed-point fractional library routines.
- (line 140)
-* __ussubuta3: Fixed-point fractional library routines.
- (line 150)
-* abort: Portability. (line 21)
-* abs: Arithmetic. (line 200)
-* abs and attributes: Expressions. (line 64)
-* ABS_EXPR: Unary and Binary Expressions.
- (line 6)
-* absence_set: Processor pipeline description.
- (line 220)
-* absM2 instruction pattern: Standard Names. (line 479)
-* absolute value: Arithmetic. (line 200)
-* access to operands: Accessors. (line 6)
-* access to special operands: Special Accessors. (line 6)
-* accessors: Accessors. (line 6)
-* ACCUM_TYPE_SIZE: Type Layout. (line 88)
-* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 49)
-* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135)
-* ADA_LONG_TYPE_SIZE: Type Layout. (line 26)
-* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code.
- (line 6)
-* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15)
-* addM3 instruction pattern: Standard Names. (line 216)
-* addMODEcc instruction pattern: Standard Names. (line 917)
-* addr_diff_vec: Side Effects. (line 302)
-* addr_diff_vec, length of: Insn Lengths. (line 26)
-* ADDR_EXPR: Storage References. (line 6)
-* addr_vec: Side Effects. (line 297)
-* addr_vec, length of: Insn Lengths. (line 26)
-* address constraints: Simple Constraints. (line 164)
-* address_operand <1>: Machine-Independent Predicates.
- (line 63)
-* address_operand: Simple Constraints. (line 168)
-* addressing modes: Addressing Modes. (line 6)
-* ADJUST_FIELD_ALIGN: Storage Layout. (line 189)
-* ADJUST_INSN_LENGTH: Insn Lengths. (line 35)
-* ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 23)
-* aggregates as return values: Aggregate Return. (line 6)
-* alias: Alias analysis. (line 6)
-* ALL_COP_ADDITIONAL_REGISTER_NAMES: MIPS Coprocessors. (line 32)
-* ALL_REGS: Register Classes. (line 17)
-* allocate_stack instruction pattern: Standard Names. (line 1227)
-* alternate entry points: Insns. (line 140)
-* anchored addresses: Anchored Addresses. (line 6)
-* and: Arithmetic. (line 158)
-* and and attributes: Expressions. (line 50)
-* and, canonicalization of: Insn Canonicalizations.
- (line 52)
-* andM3 instruction pattern: Standard Names. (line 222)
-* annotations: Annotations. (line 6)
-* APPLY_RESULT_SIZE: Scalar Return. (line 112)
-* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 194)
-* ARG_POINTER_REGNUM: Frame Registers. (line 41)
-* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65)
-* arg_pointer_rtx: Frame Registers. (line 104)
-* ARGS_GROW_DOWNWARD: Frame Layout. (line 35)
-* argument passing: Interface. (line 36)
-* arguments in registers: Register Arguments. (line 6)
-* arguments on stack: Stack Arguments. (line 6)
-* arithmetic library: Soft float library routines.
- (line 6)
-* arithmetic shift: Arithmetic. (line 173)
-* arithmetic shift with signed saturation: Arithmetic. (line 173)
-* arithmetic shift with unsigned saturation: Arithmetic. (line 173)
-* arithmetic, in RTL: Arithmetic. (line 6)
-* ARITHMETIC_TYPE_P: Types for C++. (line 61)
-* array: Types. (line 6)
-* ARRAY_RANGE_REF: Storage References. (line 6)
-* ARRAY_REF: Storage References. (line 6)
-* ARRAY_TYPE: Types. (line 6)
-* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 89)
-* ashift: Arithmetic. (line 173)
-* ashift and attributes: Expressions. (line 64)
-* ashiftrt: Arithmetic. (line 190)
-* ashiftrt and attributes: Expressions. (line 64)
-* ashlM3 instruction pattern: Standard Names. (line 458)
-* ashrM3 instruction pattern: Standard Names. (line 468)
-* ASM_APP_OFF: File Framework. (line 78)
-* ASM_APP_ON: File Framework. (line 71)
-* ASM_COMMENT_START: File Framework. (line 66)
-* ASM_DECLARE_CLASS_REFERENCE: Label Output. (line 465)
-* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 99)
-* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 114)
-* ASM_DECLARE_OBJECT_NAME: Label Output. (line 127)
-* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 156)
-* ASM_DECLARE_UNRESOLVED_REFERENCE: Label Output. (line 471)
-* ASM_FINAL_SPEC: Driver. (line 82)
-* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 164)
-* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 383)
-* asm_fprintf: Instruction Output. (line 151)
-* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 162)
-* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 367)
-* asm_input: Side Effects. (line 284)
-* asm_input and /v: Flags. (line 94)
-* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82)
-* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 79)
-* asm_noperands: Insns. (line 307)
-* asm_operands and /v: Flags. (line 94)
-* asm_operands, RTL sharing: Sharing. (line 45)
-* asm_operands, usage: Assembler. (line 6)
-* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9)
-* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26)
-* ASM_OUTPUT_ALIGN: Alignment Output. (line 86)
-* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 91)
-* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 71)
-* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 30)
-* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 38)
-* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 102)
-* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 94)
-* ASM_OUTPUT_ASCII: Data Output. (line 62)
-* ASM_OUTPUT_BSS: Uninitialized Data. (line 46)
-* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51)
-* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38)
-* ASM_OUTPUT_COMMON: Uninitialized Data. (line 10)
-* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 355)
-* ASM_OUTPUT_DEF: Label Output. (line 404)
-* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 412)
-* ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 69)
-* ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 78)
-* ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 84)
-* ASM_OUTPUT_DWARF_TABLE_REF: SDB and DWARF. (line 89)
-* ASM_OUTPUT_DWARF_VMS_DELTA: SDB and DWARF. (line 73)
-* ASM_OUTPUT_EXTERNAL: Label Output. (line 284)
-* ASM_OUTPUT_FDESC: Data Output. (line 71)
-* ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 17)
-* ASM_OUTPUT_IDENT: File Framework. (line 109)
-* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 29)
-* ASM_OUTPUT_LABEL: Label Output. (line 9)
-* ASM_OUTPUT_LABEL_REF: Label Output. (line 328)
-* ASM_OUTPUT_LABELREF: Label Output. (line 306)
-* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 81)
-* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 95)
-* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 53)
-* ASM_OUTPUT_OPCODE: Instruction Output. (line 36)
-* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 121)
-* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 84)
-* ASM_OUTPUT_REG_POP: Instruction Output. (line 206)
-* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 201)
-* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 47)
-* ASM_OUTPUT_SKIP: Alignment Output. (line 73)
-* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 85)
-* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 96)
-* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 321)
-* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 89)
-* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 430)
-* ASM_OUTPUT_WEAKREF: Label Output. (line 216)
-* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67)
-* ASM_SPEC: Driver. (line 74)
-* ASM_STABD_OP: DBX Options. (line 36)
-* ASM_STABN_OP: DBX Options. (line 43)
-* ASM_STABS_OP: DBX Options. (line 29)
-* ASM_WEAKEN_DECL: Label Output. (line 208)
-* ASM_WEAKEN_LABEL: Label Output. (line 195)
-* assemble_name: Label Output. (line 8)
-* assemble_name_raw: Label Output. (line 28)
-* assembler format: File Framework. (line 6)
-* assembler instructions in RTL: Assembler. (line 6)
-* ASSEMBLER_DIALECT: Instruction Output. (line 174)
-* assigning attribute values to insns: Tagging Insns. (line 6)
-* asterisk in template: Output Statement. (line 29)
-* atan2M3 instruction pattern: Standard Names. (line 549)
-* attr <1>: Expressions. (line 154)
-* attr: Tagging Insns. (line 54)
-* attr_flag: Expressions. (line 119)
-* attribute expressions: Expressions. (line 6)
-* attribute specifications: Attr Example. (line 6)
-* attribute specifications example: Attr Example. (line 6)
-* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 171)
-* attributes: Attributes. (line 6)
-* attributes, defining: Defining Attributes.
- (line 6)
-* attributes, target-specific: Target Attributes. (line 6)
-* autoincrement addressing, availability: Portability. (line 21)
-* autoincrement/decrement addressing: Simple Constraints. (line 30)
-* automata_option: Processor pipeline description.
- (line 301)
-* automaton based pipeline description: Processor pipeline description.
- (line 6)
-* automaton based scheduler: Processor pipeline description.
- (line 6)
-* AVOID_CCMODE_COPIES: Values in Registers.
- (line 153)
-* backslash: Output Template. (line 46)
-* barrier: Insns. (line 160)
-* barrier and /f: Flags. (line 125)
-* barrier and /v: Flags. (line 44)
-* BASE_REG_CLASS: Register Classes. (line 109)
-* basic block: Basic Blocks. (line 6)
-* Basic Statements: Basic Statements. (line 6)
-* basic-block.h: Control Flow. (line 6)
-* BASIC_BLOCK: Basic Blocks. (line 19)
-* basic_block: Basic Blocks. (line 6)
-* BB_HEAD, BB_END: Maintaining the CFG.
- (line 88)
-* bb_seq: GIMPLE sequences. (line 73)
-* BIGGEST_ALIGNMENT: Storage Layout. (line 161)
-* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 182)
-* BImode: Machine Modes. (line 22)
-* BIND_EXPR: Unary and Binary Expressions.
- (line 6)
-* BINFO_TYPE: Classes. (line 6)
-* bit-fields: Bit-Fields. (line 6)
-* BIT_AND_EXPR: Unary and Binary Expressions.
- (line 6)
-* BIT_IOR_EXPR: Unary and Binary Expressions.
- (line 6)
-* BIT_NOT_EXPR: Unary and Binary Expressions.
- (line 6)
-* BIT_XOR_EXPR: Unary and Binary Expressions.
- (line 6)
-* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 379)
-* BITS_BIG_ENDIAN: Storage Layout. (line 12)
-* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8)
-* BITS_PER_UNIT: Storage Layout. (line 45)
-* BITS_PER_WORD: Storage Layout. (line 50)
-* bitwise complement: Arithmetic. (line 154)
-* bitwise exclusive-or: Arithmetic. (line 168)
-* bitwise inclusive-or: Arithmetic. (line 163)
-* bitwise logical-and: Arithmetic. (line 158)
-* BLKmode: Machine Modes. (line 183)
-* BLKmode, and function return values: Calls. (line 23)
-* block statement iterators <1>: Maintaining the CFG.
- (line 45)
-* block statement iterators: Basic Blocks. (line 68)
-* BLOCK_FOR_INSN, bb_for_stmt: Maintaining the CFG.
- (line 40)
-* BLOCK_REG_PADDING: Register Arguments. (line 228)
-* blockage instruction pattern: Standard Names. (line 1417)
-* Blocks: Blocks. (line 6)
-* bool: Misc. (line 854)
-* BOOL_TYPE_SIZE: Type Layout. (line 44)
-* BOOLEAN_TYPE: Types. (line 6)
-* branch prediction: Profile information.
- (line 24)
-* BRANCH_COST: Costs. (line 105)
-* break_out_memory_refs: Addressing Modes. (line 135)
-* BREAK_STMT: Statements for C++. (line 6)
-* bsi_commit_edge_inserts: Maintaining the CFG.
- (line 118)
-* bsi_end_p: Maintaining the CFG.
- (line 60)
-* bsi_insert_after: Maintaining the CFG.
- (line 72)
-* bsi_insert_before: Maintaining the CFG.
- (line 78)
-* bsi_insert_on_edge: Maintaining the CFG.
- (line 118)
-* bsi_last: Maintaining the CFG.
- (line 56)
-* bsi_next: Maintaining the CFG.
- (line 64)
-* bsi_prev: Maintaining the CFG.
- (line 68)
-* bsi_remove: Maintaining the CFG.
- (line 84)
-* bsi_start: Maintaining the CFG.
- (line 52)
-* BSS_SECTION_ASM_OP: Sections. (line 68)
-* bswap: Arithmetic. (line 241)
-* btruncM2 instruction pattern: Standard Names. (line 567)
-* build0: Macros and Functions.
- (line 16)
-* build1: Macros and Functions.
- (line 17)
-* build2: Macros and Functions.
- (line 18)
-* build3: Macros and Functions.
- (line 19)
-* build4: Macros and Functions.
- (line 20)
-* build5: Macros and Functions.
- (line 21)
-* build6: Macros and Functions.
- (line 22)
-* builtin_longjmp instruction pattern: Standard Names. (line 1320)
-* builtin_setjmp_receiver instruction pattern: Standard Names.
- (line 1310)
-* builtin_setjmp_setup instruction pattern: Standard Names. (line 1299)
-* byte_mode: Machine Modes. (line 336)
-* BYTES_BIG_ENDIAN: Storage Layout. (line 24)
-* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 221)
-* C statements for assembler output: Output Statement. (line 6)
-* C99 math functions, implicit usage: Library Calls. (line 62)
-* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 142)
-* c_register_pragma: Misc. (line 404)
-* c_register_pragma_with_expansion: Misc. (line 406)
-* call <1>: Side Effects. (line 86)
-* call: Flags. (line 239)
-* call instruction pattern: Standard Names. (line 974)
-* call usage: Calls. (line 10)
-* call, in call_insn: Flags. (line 33)
-* call, in mem: Flags. (line 99)
-* call-clobbered register: Register Basics. (line 35)
-* call-saved register: Register Basics. (line 46)
-* call-used register: Register Basics. (line 53)
-* CALL_EXPR: Unary and Binary Expressions.
- (line 6)
-* call_insn: Insns. (line 95)
-* call_insn and /c: Flags. (line 33)
-* call_insn and /f: Flags. (line 125)
-* call_insn and /i: Flags. (line 24)
-* call_insn and /j: Flags. (line 179)
-* call_insn and /s: Flags. (line 49)
-* call_insn and /u: Flags. (line 19)
-* call_insn and /u or /i: Flags. (line 29)
-* call_insn and /v: Flags. (line 44)
-* CALL_INSN_FUNCTION_USAGE: Insns. (line 101)
-* call_pop instruction pattern: Standard Names. (line 1002)
-* CALL_POPS_ARGS: Stack Arguments. (line 133)
-* CALL_REALLY_USED_REGISTERS: Register Basics. (line 46)
-* CALL_USED_REGISTERS: Register Basics. (line 35)
-* call_used_regs: Register Basics. (line 59)
-* call_value instruction pattern: Standard Names. (line 994)
-* call_value_pop instruction pattern: Standard Names. (line 1002)
-* CALLER_SAVE_PROFITABLE: Caller Saves. (line 11)
-* calling conventions: Stack and Calling. (line 6)
-* calling functions in RTL: Calls. (line 6)
-* can_create_pseudo_p: Standard Names. (line 75)
-* can_fallthru: Basic Blocks. (line 57)
-* canadian: Configure Terms. (line 6)
-* CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 522)
-* CANNOT_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory.
- (line 280)
-* canonicalization of instructions: Insn Canonicalizations.
- (line 6)
-* CANONICALIZE_COMPARISON: MODE_CC Condition Codes.
- (line 55)
-* canonicalize_funcptr_for_compare instruction pattern: Standard Names.
- (line 1158)
-* CASE_USE_BIT_TESTS: Misc. (line 54)
-* CASE_VECTOR_MODE: Misc. (line 27)
-* CASE_VECTOR_PC_RELATIVE: Misc. (line 40)
-* CASE_VECTOR_SHORTEN_MODE: Misc. (line 31)
-* casesi instruction pattern: Standard Names. (line 1082)
-* cbranchMODE4 instruction pattern: Standard Names. (line 963)
-* cc0 <1>: Regs and Memory. (line 307)
-* cc0: CC0 Condition Codes.
- (line 6)
-* cc0, RTL sharing: Sharing. (line 27)
-* cc0_rtx: Regs and Memory. (line 333)
-* CC1_SPEC: Driver. (line 56)
-* CC1PLUS_SPEC: Driver. (line 64)
-* cc_status: CC0 Condition Codes.
- (line 6)
-* CC_STATUS_MDEP: CC0 Condition Codes.
- (line 17)
-* CC_STATUS_MDEP_INIT: CC0 Condition Codes.
- (line 23)
-* CCmode <1>: Machine Modes. (line 176)
-* CCmode: MODE_CC Condition Codes.
- (line 6)
-* CDImode: Machine Modes. (line 202)
-* CEIL_DIV_EXPR: Unary and Binary Expressions.
- (line 6)
-* CEIL_MOD_EXPR: Unary and Binary Expressions.
- (line 6)
-* ceilM2 instruction pattern: Standard Names. (line 583)
-* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 226)
-* CFG, Control Flow Graph: Control Flow. (line 6)
-* cfghooks.h: Maintaining the CFG.
- (line 6)
-* cgraph_finalize_function: Parsing pass. (line 52)
-* chain_circular: GTY Options. (line 191)
-* chain_next: GTY Options. (line 191)
-* chain_prev: GTY Options. (line 191)
-* change_address: Standard Names. (line 47)
-* CHAR_TYPE_SIZE: Type Layout. (line 39)
-* check_stack instruction pattern: Standard Names. (line 1245)
-* CHImode: Machine Modes. (line 202)
-* class definitions, register: Register Classes. (line 6)
-* class preference constraints: Class Preferences. (line 6)
-* class, scope: Classes. (line 6)
-* CLASS_MAX_NREGS: Register Classes. (line 510)
-* CLASS_TYPE_P: Types for C++. (line 65)
-* classes of RTX codes: RTL Classes. (line 6)
-* CLASSTYPE_DECLARED_CLASS: Classes. (line 6)
-* CLASSTYPE_HAS_MUTABLE: Classes. (line 85)
-* CLASSTYPE_NON_POD_P: Classes. (line 90)
-* CLEANUP_DECL: Statements for C++. (line 6)
-* CLEANUP_EXPR: Statements for C++. (line 6)
-* CLEANUP_POINT_EXPR: Unary and Binary Expressions.
- (line 6)
-* CLEANUP_STMT: Statements for C++. (line 6)
-* Cleanups: Cleanups. (line 6)
-* CLEAR_BY_PIECES_P: Costs. (line 188)
-* clear_cache instruction pattern: Standard Names. (line 1561)
-* CLEAR_INSN_CACHE: Trampolines. (line 99)
-* CLEAR_RATIO: Costs. (line 176)
-* clobber: Side Effects. (line 100)
-* clz: Arithmetic. (line 217)
-* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 319)
-* clzM2 instruction pattern: Standard Names. (line 648)
-* cmpmemM instruction pattern: Standard Names. (line 781)
-* cmpstrM instruction pattern: Standard Names. (line 760)
-* cmpstrnM instruction pattern: Standard Names. (line 747)
-* code generation RTL sequences: Expander Definitions.
- (line 6)
-* code iterators in .md files: Code Iterators. (line 6)
-* code_label: Insns. (line 119)
-* code_label and /i: Flags. (line 59)
-* code_label and /v: Flags. (line 44)
-* CODE_LABEL_NUMBER: Insns. (line 119)
-* codes, RTL expression: RTL Objects. (line 47)
-* COImode: Machine Modes. (line 202)
-* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32)
-* COLLECT_EXPORT_LIST: Misc. (line 753)
-* COLLECT_SHARED_FINI_FUNC: Macros for Initialization.
- (line 44)
-* COLLECT_SHARED_INIT_FUNC: Macros for Initialization.
- (line 33)
-* commit_edge_insertions: Maintaining the CFG.
- (line 118)
-* compare: Arithmetic. (line 43)
-* compare, canonicalization of: Insn Canonicalizations.
- (line 37)
-* comparison_operator: Machine-Independent Predicates.
- (line 111)
-* compiler passes and files: Passes. (line 6)
-* complement, bitwise: Arithmetic. (line 154)
-* COMPLEX_CST: Constant expressions.
- (line 6)
-* COMPLEX_EXPR: Unary and Binary Expressions.
- (line 6)
-* COMPLEX_TYPE: Types. (line 6)
-* COMPONENT_REF: Storage References. (line 6)
-* Compound Expressions: Compound Expressions.
- (line 6)
-* Compound Lvalues: Compound Lvalues. (line 6)
-* COMPOUND_EXPR: Unary and Binary Expressions.
- (line 6)
-* COMPOUND_LITERAL_EXPR: Unary and Binary Expressions.
- (line 6)
-* COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions.
- (line 367)
-* COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions.
- (line 367)
-* computed jump: Edges. (line 128)
-* computing the length of an insn: Insn Lengths. (line 6)
-* concat: Regs and Memory. (line 385)
-* concatn: Regs and Memory. (line 391)
-* cond: Comparisons. (line 90)
-* cond and attributes: Expressions. (line 37)
-* cond_exec: Side Effects. (line 248)
-* COND_EXPR: Unary and Binary Expressions.
- (line 6)
-* condition code register: Regs and Memory. (line 307)
-* condition code status: Condition Code. (line 6)
-* condition codes: Comparisons. (line 20)
-* conditional execution <1>: Cond Exec Macros. (line 6)
-* conditional execution: Conditional Execution.
- (line 6)
-* Conditional Expressions: Conditional Expressions.
- (line 6)
-* conditions, in patterns: Patterns. (line 43)
-* configuration file <1>: Filesystem. (line 6)
-* configuration file: Host Misc. (line 6)
-* configure terms: Configure Terms. (line 6)
-* CONJ_EXPR: Unary and Binary Expressions.
- (line 6)
-* const: Constants. (line 99)
-* CONST0_RTX: Constants. (line 119)
-* const0_rtx: Constants. (line 16)
-* CONST1_RTX: Constants. (line 119)
-* const1_rtx: Constants. (line 16)
-* CONST2_RTX: Constants. (line 119)
-* const2_rtx: Constants. (line 16)
-* CONST_DECL: Declarations. (line 6)
-* const_double: Constants. (line 32)
-* const_double, RTL sharing: Sharing. (line 29)
-* CONST_DOUBLE_LOW: Constants. (line 39)
-* CONST_DOUBLE_OK_FOR_CONSTRAINT_P: Old Constraints. (line 69)
-* CONST_DOUBLE_OK_FOR_LETTER_P: Old Constraints. (line 54)
-* const_double_operand: Machine-Independent Predicates.
- (line 21)
-* const_fixed: Constants. (line 52)
-* const_int: Constants. (line 8)
-* const_int and attribute tests: Expressions. (line 47)
-* const_int and attributes: Expressions. (line 10)
-* const_int, RTL sharing: Sharing. (line 23)
-* const_int_operand: Machine-Independent Predicates.
- (line 16)
-* CONST_OK_FOR_CONSTRAINT_P: Old Constraints. (line 49)
-* CONST_OK_FOR_LETTER_P: Old Constraints. (line 40)
-* const_string: Constants. (line 71)
-* const_string and attributes: Expressions. (line 20)
-* const_true_rtx: Constants. (line 26)
-* const_vector: Constants. (line 59)
-* const_vector, RTL sharing: Sharing. (line 32)
-* constant attributes: Constant Attributes.
- (line 6)
-* constant definitions: Constant Definitions.
- (line 6)
-* CONSTANT_ADDRESS_P: Addressing Modes. (line 29)
-* CONSTANT_ALIGNMENT: Storage Layout. (line 229)
-* CONSTANT_P: Addressing Modes. (line 36)
-* CONSTANT_POOL_ADDRESS_P: Flags. (line 10)
-* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 76)
-* constants in constraints: Simple Constraints. (line 70)
-* constm1_rtx: Constants. (line 16)
-* constraint modifier characters: Modifiers. (line 6)
-* constraint, matching: Simple Constraints. (line 142)
-* CONSTRAINT_LEN: Old Constraints. (line 12)
-* constraint_num: C Constraint Interface.
- (line 38)
-* constraint_satisfied_p: C Constraint Interface.
- (line 54)
-* constraints: Constraints. (line 6)
-* constraints, defining: Define Constraints. (line 6)
-* constraints, defining, obsolete method: Old Constraints. (line 6)
-* constraints, machine specific: Machine Constraints.
- (line 6)
-* constraints, testing: C Constraint Interface.
- (line 6)
-* CONSTRUCTOR: Unary and Binary Expressions.
- (line 6)
-* constructors, automatic calls: Collect2. (line 15)
-* constructors, output of: Initialization. (line 6)
-* container: Containers. (line 6)
-* CONTINUE_STMT: Statements for C++. (line 6)
-* contributors: Contributors. (line 6)
-* controlling register usage: Register Basics. (line 73)
-* controlling the compilation driver: Driver. (line 6)
-* conventions, run-time: Interface. (line 6)
-* conversions: Conversions. (line 6)
-* CONVERT_EXPR: Unary and Binary Expressions.
- (line 6)
-* copy_rtx: Addressing Modes. (line 188)
-* copy_rtx_if_shared: Sharing. (line 64)
-* copysignM3 instruction pattern: Standard Names. (line 629)
-* cosM2 instruction pattern: Standard Names. (line 508)
-* costs of instructions: Costs. (line 6)
-* CP_INTEGRAL_TYPE: Types for C++. (line 57)
-* cp_namespace_decls: Namespaces. (line 49)
-* CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33)
-* CP_TYPE_CONST_P: Types for C++. (line 24)
-* CP_TYPE_QUALS: Types for C++. (line 6)
-* CP_TYPE_RESTRICT_P: Types for C++. (line 30)
-* CP_TYPE_VOLATILE_P: Types for C++. (line 27)
-* CPLUSPLUS_CPP_SPEC: Driver. (line 51)
-* CPP_SPEC: Driver. (line 44)
-* CQImode: Machine Modes. (line 202)
-* cross compilation and floating point: Floating Point. (line 6)
-* CRT_CALL_STATIC_FUNCTION: Sections. (line 122)
-* CRTSTUFF_T_CFLAGS: Target Fragment. (line 35)
-* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 39)
-* CSImode: Machine Modes. (line 202)
-* cstoreMODE4 instruction pattern: Standard Names. (line 924)
-* CTImode: Machine Modes. (line 202)
-* ctrapMM4 instruction pattern: Standard Names. (line 1386)
-* ctz: Arithmetic. (line 225)
-* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 320)
-* ctzM2 instruction pattern: Standard Names. (line 657)
-* CUMULATIVE_ARGS: Register Arguments. (line 127)
-* current_function_epilogue_delay_list: Function Entry. (line 181)
-* current_function_is_leaf: Leaf Functions. (line 51)
-* current_function_outgoing_args_size: Stack Arguments. (line 48)
-* current_function_pops_args: Function Entry. (line 106)
-* current_function_pretend_args_size: Function Entry. (line 112)
-* current_function_uses_only_leaf_regs: Leaf Functions. (line 51)
-* current_insn_predicate: Conditional Execution.
- (line 26)
-* DAmode: Machine Modes. (line 152)
-* data bypass: Processor pipeline description.
- (line 106)
-* data dependence delays: Processor pipeline description.
- (line 6)
-* Data Dependency Analysis: Dependency analysis.
- (line 6)
-* data structures: Per-Function Data. (line 6)
-* DATA_ALIGNMENT: Storage Layout. (line 216)
-* DATA_SECTION_ASM_OP: Sections. (line 53)
-* DBR_OUTPUT_SEQEND: Instruction Output. (line 135)
-* dbr_sequence_length: Instruction Output. (line 134)
-* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 103)
-* DBX_CONTIN_CHAR: DBX Options. (line 66)
-* DBX_CONTIN_LENGTH: DBX Options. (line 56)
-* DBX_DEBUGGING_INFO: DBX Options. (line 9)
-* DBX_FUNCTION_FIRST: DBX Options. (line 97)
-* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 109)
-* DBX_NO_XREFS: DBX Options. (line 50)
-* DBX_OUTPUT_LBRAC: DBX Hooks. (line 9)
-* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 34)
-* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9)
-* DBX_OUTPUT_NFUN: DBX Hooks. (line 18)
-* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX.
- (line 42)
-* DBX_OUTPUT_RBRAC: DBX Hooks. (line 15)
-* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 22)
-* DBX_REGISTER_NUMBER: All Debuggers. (line 9)
-* DBX_REGPARM_STABS_CODE: DBX Options. (line 87)
-* DBX_REGPARM_STABS_LETTER: DBX Options. (line 92)
-* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82)
-* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73)
-* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78)
-* DBX_USE_BINCL: DBX Options. (line 115)
-* DCmode: Machine Modes. (line 197)
-* DDmode: Machine Modes. (line 90)
-* De Morgan's law: Insn Canonicalizations.
- (line 52)
-* dead_or_set_p: define_peephole. (line 65)
-* debug_expr: Debug Information. (line 22)
-* DEBUG_EXPR_DECL: Declarations. (line 6)
-* debug_insn: Insns. (line 239)
-* DEBUG_SYMS_TEXT: DBX Options. (line 25)
-* DEBUGGER_ARG_OFFSET: All Debuggers. (line 37)
-* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28)
-* decimal float library: Decimal float library routines.
- (line 6)
-* DECL_ALIGN: Declarations. (line 6)
-* DECL_ANTICIPATED: Functions for C++. (line 42)
-* DECL_ARGUMENTS: Function Basics. (line 36)
-* DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158)
-* DECL_ARTIFICIAL <1>: Function Basics. (line 6)
-* DECL_ARTIFICIAL <2>: Function Properties.
- (line 47)
-* DECL_ARTIFICIAL: Working with declarations.
- (line 24)
-* DECL_ASSEMBLER_NAME: Function Basics. (line 19)
-* DECL_ATTRIBUTES: Attributes. (line 22)
-* DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88)
-* DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84)
-* DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98)
-* DECL_CONST_MEMFUNC_P: Functions for C++. (line 71)
-* DECL_CONSTRUCTOR_P: Functions for C++. (line 77)
-* DECL_CONTEXT: Namespaces. (line 31)
-* DECL_CONV_FN_P: Functions for C++. (line 105)
-* DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92)
-* DECL_DESTRUCTOR_P: Functions for C++. (line 95)
-* DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46)
-* DECL_EXTERNAL <1>: Function Properties.
- (line 25)
-* DECL_EXTERNAL: Declarations. (line 6)
-* DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61)
-* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Basics. (line 6)
-* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Properties.
- (line 61)
-* DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Basics. (line 6)
-* DECL_FUNCTION_SPECIFIC_TARGET: Function Properties.
- (line 55)
-* DECL_GLOBAL_CTOR_P: Functions for C++. (line 108)
-* DECL_GLOBAL_DTOR_P: Functions for C++. (line 112)
-* DECL_INITIAL <1>: Function Basics. (line 51)
-* DECL_INITIAL: Declarations. (line 6)
-* DECL_LINKONCE_P: Functions for C++. (line 50)
-* DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38)
-* DECL_MAIN_P: Functions for C++. (line 34)
-* DECL_NAME <1>: Function Basics. (line 9)
-* DECL_NAME <2>: Namespaces. (line 20)
-* DECL_NAME: Working with declarations.
- (line 7)
-* DECL_NAMESPACE_ALIAS: Namespaces. (line 35)
-* DECL_NAMESPACE_STD_P: Namespaces. (line 45)
-* DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138)
-* DECL_NONCONVERTING_P: Functions for C++. (line 80)
-* DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68)
-* DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102)
-* DECL_PURE_P: Function Properties.
- (line 40)
-* DECL_RESULT: Function Basics. (line 41)
-* DECL_SAVED_TREE: Function Basics. (line 44)
-* DECL_SIZE: Declarations. (line 6)
-* DECL_STATIC_FUNCTION_P: Functions for C++. (line 65)
-* DECL_STMT: Statements for C++. (line 6)
-* DECL_STMT_DECL: Statements for C++. (line 6)
-* DECL_THUNK_P: Functions for C++. (line 116)
-* DECL_VIRTUAL_P: Function Properties.
- (line 44)
-* DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74)
-* declaration: Declarations. (line 6)
-* declarations, RTL: RTL Declarations. (line 6)
-* DECLARE_LIBRARY_RENAMES: Library Calls. (line 9)
-* decrement_and_branch_until_zero instruction pattern: Standard Names.
- (line 1120)
-* default: GTY Options. (line 77)
-* default_file_start: File Framework. (line 8)
-* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18)
-* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 35)
-* DEFAULT_SIGNED_CHAR: Type Layout. (line 153)
-* define_address_constraint: Define Constraints. (line 107)
-* define_asm_attributes: Tagging Insns. (line 73)
-* define_attr: Defining Attributes.
- (line 6)
-* define_automaton: Processor pipeline description.
- (line 53)
-* define_bypass: Processor pipeline description.
- (line 197)
-* define_c_enum: Constant Definitions.
- (line 49)
-* define_code_attr: Code Iterators. (line 6)
-* define_code_iterator: Code Iterators. (line 6)
-* define_cond_exec: Conditional Execution.
- (line 13)
-* define_constants: Constant Definitions.
- (line 6)
-* define_constraint: Define Constraints. (line 48)
-* define_cpu_unit: Processor pipeline description.
- (line 68)
-* define_delay: Delay Slots. (line 25)
-* define_enum: Constant Definitions.
- (line 118)
-* define_enum_attr <1>: Defining Attributes.
- (line 64)
-* define_enum_attr: Constant Definitions.
- (line 136)
-* define_expand: Expander Definitions.
- (line 11)
-* define_insn: Patterns. (line 6)
-* define_insn example: Example. (line 6)
-* define_insn_and_split: Insn Splitting. (line 170)
-* define_insn_reservation: Processor pipeline description.
- (line 106)
-* define_memory_constraint: Define Constraints. (line 88)
-* define_mode_attr: Substitutions. (line 6)
-* define_mode_iterator: Defining Mode Iterators.
- (line 6)
-* define_peephole: define_peephole. (line 6)
-* define_peephole2: define_peephole2. (line 6)
-* define_predicate: Defining Predicates.
- (line 6)
-* define_query_cpu_unit: Processor pipeline description.
- (line 90)
-* define_register_constraint: Define Constraints. (line 28)
-* define_reservation: Processor pipeline description.
- (line 186)
-* define_special_predicate: Defining Predicates.
- (line 6)
-* define_split: Insn Splitting. (line 32)
-* defining attributes and their values: Defining Attributes.
- (line 6)
-* defining constraints: Define Constraints. (line 6)
-* defining constraints, obsolete method: Old Constraints. (line 6)
-* defining jump instruction patterns: Jump Patterns. (line 6)
-* defining looping instruction patterns: Looping Patterns. (line 6)
-* defining peephole optimizers: Peephole Definitions.
- (line 6)
-* defining predicates: Defining Predicates.
- (line 6)
-* defining RTL sequences for code generation: Expander Definitions.
- (line 6)
-* delay slots, defining: Delay Slots. (line 6)
-* DELAY_SLOTS_FOR_EPILOGUE: Function Entry. (line 163)
-* deletable: GTY Options. (line 145)
-* DELETE_IF_ORDINARY: Filesystem. (line 79)
-* Dependent Patterns: Dependent Patterns. (line 6)
-* desc: GTY Options. (line 77)
-* destructors, output of: Initialization. (line 6)
-* deterministic finite state automaton: Processor pipeline description.
- (line 301)
-* DF_SIZE: Type Layout. (line 129)
-* DFmode: Machine Modes. (line 73)
-* digits in constraint: Simple Constraints. (line 130)
-* DImode: Machine Modes. (line 45)
-* DIR_SEPARATOR: Filesystem. (line 18)
-* DIR_SEPARATOR_2: Filesystem. (line 19)
-* directory options .md: Including Patterns. (line 44)
-* disabling certain registers: Register Basics. (line 73)
-* dispatch table: Dispatch Tables. (line 8)
-* div: Arithmetic. (line 116)
-* div and attributes: Expressions. (line 64)
-* division: Arithmetic. (line 136)
-* divM3 instruction pattern: Standard Names. (line 222)
-* divmodM4 instruction pattern: Standard Names. (line 438)
-* DO_BODY: Statements for C++. (line 6)
-* DO_COND: Statements for C++. (line 6)
-* DO_STMT: Statements for C++. (line 6)
-* DOLLARS_IN_IDENTIFIERS: Misc. (line 451)
-* doloop_begin instruction pattern: Standard Names. (line 1151)
-* doloop_end instruction pattern: Standard Names. (line 1130)
-* DONE: Expander Definitions.
- (line 74)
-* DONT_USE_BUILTIN_SETJMP: Exception Region Output.
- (line 79)
-* DOUBLE_TYPE_SIZE: Type Layout. (line 53)
-* DQmode: Machine Modes. (line 115)
-* driver: Driver. (line 6)
-* DRIVER_SELF_SPECS: Driver. (line 9)
-* DUMPFILE_FORMAT: Filesystem. (line 67)
-* DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 50)
-* DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13)
-* DWARF2_FRAME_INFO: SDB and DWARF. (line 30)
-* DWARF2_FRAME_REG_OUT: Frame Registers. (line 150)
-* DWARF2_UNWIND_INFO: Exception Region Output.
- (line 40)
-* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 152)
-* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output.
- (line 84)
-* DWARF_FRAME_REGISTERS: Frame Registers. (line 110)
-* DWARF_FRAME_REGNUM: Frame Registers. (line 142)
-* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134)
-* DWARF_ZERO_REG: Frame Layout. (line 163)
-* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 92)
-* E in constraint: Simple Constraints. (line 89)
-* earlyclobber operand: Modifiers. (line 25)
-* edge: Edges. (line 6)
-* edge in the flow graph: Edges. (line 6)
-* edge iterators: Edges. (line 15)
-* edge splitting: Maintaining the CFG.
- (line 118)
-* EDGE_ABNORMAL: Edges. (line 128)
-* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171)
-* EDGE_ABNORMAL, EDGE_EH: Edges. (line 96)
-* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 122)
-* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 86)
-* EDOM, implicit usage: Library Calls. (line 44)
-* EH_FRAME_IN_DATA_SECTION: Exception Region Output.
- (line 20)
-* EH_FRAME_SECTION_NAME: Exception Region Output.
- (line 10)
-* eh_return instruction pattern: Standard Names. (line 1326)
-* EH_RETURN_DATA_REGNO: Exception Handling. (line 7)
-* EH_RETURN_HANDLER_RTX: Exception Handling. (line 39)
-* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22)
-* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output.
- (line 29)
-* EH_USES: Function Entry. (line 158)
-* ei_edge: Edges. (line 43)
-* ei_end_p: Edges. (line 27)
-* ei_last: Edges. (line 23)
-* ei_next: Edges. (line 35)
-* ei_one_before_end_p: Edges. (line 31)
-* ei_prev: Edges. (line 39)
-* ei_safe_safe: Edges. (line 47)
-* ei_start: Edges. (line 19)
-* ELIGIBLE_FOR_EPILOGUE_DELAY: Function Entry. (line 169)
-* ELIMINABLE_REGS: Elimination. (line 47)
-* ELSE_CLAUSE: Statements for C++. (line 6)
-* Embedded C: Fixed-point fractional library routines.
- (line 6)
-* EMIT_MODE_SET: Mode Switching. (line 74)
-* Empty Statements: Empty Statements. (line 6)
-* EMPTY_CLASS_EXPR: Statements for C++. (line 6)
-* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 292)
-* Emulated TLS: Emulated TLS. (line 6)
-* ENABLE_EXECUTE_STACK: Trampolines. (line 109)
-* enabled: Disable Insn Alternatives.
- (line 6)
-* ENDFILE_SPEC: Driver. (line 156)
-* endianness: Portability. (line 21)
-* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 28)
-* enum machine_mode: Machine Modes. (line 6)
-* enum reg_class: Register Classes. (line 67)
-* ENUMERAL_TYPE: Types. (line 6)
-* enumerations: Constant Definitions.
- (line 49)
-* epilogue: Function Entry. (line 6)
-* epilogue instruction pattern: Standard Names. (line 1358)
-* EPILOGUE_USES: Function Entry. (line 152)
-* eq: Comparisons. (line 52)
-* eq and attributes: Expressions. (line 64)
-* eq_attr: Expressions. (line 85)
-* EQ_EXPR: Unary and Binary Expressions.
- (line 6)
-* equal: Comparisons. (line 52)
-* errno, implicit usage: Library Calls. (line 56)
-* EXACT_DIV_EXPR: Unary and Binary Expressions.
- (line 6)
-* examining SSA_NAMEs: SSA. (line 218)
-* exception handling <1>: Edges. (line 96)
-* exception handling: Exception Handling. (line 6)
-* exception_receiver instruction pattern: Standard Names. (line 1290)
-* exclamation point: Multi-Alternative. (line 47)
-* exclusion_set: Processor pipeline description.
- (line 220)
-* exclusive-or, bitwise: Arithmetic. (line 168)
-* EXIT_EXPR: Unary and Binary Expressions.
- (line 6)
-* EXIT_IGNORE_STACK: Function Entry. (line 140)
-* expander definitions: Expander Definitions.
- (line 6)
-* expM2 instruction pattern: Standard Names. (line 524)
-* EXPR_FILENAME: Working with declarations.
- (line 14)
-* EXPR_LINENO: Working with declarations.
- (line 20)
-* expr_list: Insns. (line 545)
-* EXPR_STMT: Statements for C++. (line 6)
-* EXPR_STMT_EXPR: Statements for C++. (line 6)
-* expression: Expression trees. (line 6)
-* expression codes: RTL Objects. (line 47)
-* extendMN2 instruction pattern: Standard Names. (line 839)
-* extensible constraints: Simple Constraints. (line 173)
-* EXTRA_ADDRESS_CONSTRAINT: Old Constraints. (line 123)
-* EXTRA_CONSTRAINT: Old Constraints. (line 74)
-* EXTRA_CONSTRAINT_STR: Old Constraints. (line 95)
-* EXTRA_MEMORY_CONSTRAINT: Old Constraints. (line 100)
-* EXTRA_SPECS: Driver. (line 183)
-* extv instruction pattern: Standard Names. (line 875)
-* extzv instruction pattern: Standard Names. (line 890)
-* F in constraint: Simple Constraints. (line 94)
-* FAIL: Expander Definitions.
- (line 80)
-* fall-thru: Edges. (line 69)
-* FATAL_EXIT_CODE: Host Misc. (line 6)
-* FDL, GNU Free Documentation License: GNU Free Documentation License.
- (line 6)
-* features, optional, in system conventions: Run-time Target.
- (line 59)
-* ffs: Arithmetic. (line 211)
-* ffsM2 instruction pattern: Standard Names. (line 638)
-* FIELD_DECL: Declarations. (line 6)
-* file_end_indicate_exec_stack: File Framework. (line 41)
-* files and passes of the compiler: Passes. (line 6)
-* files, generated: Files. (line 6)
-* final_absence_set: Processor pipeline description.
- (line 220)
-* FINAL_PRESCAN_INSN: Instruction Output. (line 61)
-* final_presence_set: Processor pipeline description.
- (line 220)
-* final_scan_insn: Function Entry. (line 181)
-* final_sequence: Instruction Output. (line 145)
-* FIND_BASE_TERM: Addressing Modes. (line 119)
-* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 115)
-* FINI_SECTION_ASM_OP: Sections. (line 100)
-* finite state automaton minimization: Processor pipeline description.
- (line 301)
-* FIRST_PARM_OFFSET: Frame Layout. (line 67)
-* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65)
-* FIRST_PSEUDO_REGISTER: Register Basics. (line 9)
-* FIRST_STACK_REG: Stack Registers. (line 27)
-* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51)
-* fix: Conversions. (line 66)
-* FIX_TRUNC_EXPR: Unary and Binary Expressions.
- (line 6)
-* fix_truncMN2 instruction pattern: Standard Names. (line 826)
-* fixed register: Register Basics. (line 15)
-* fixed-point fractional library: Fixed-point fractional library routines.
- (line 6)
-* FIXED_CONVERT_EXPR: Unary and Binary Expressions.
- (line 6)
-* FIXED_CST: Constant expressions.
- (line 6)
-* FIXED_POINT_TYPE: Types. (line 6)
-* FIXED_REGISTERS: Register Basics. (line 15)
-* fixed_regs: Register Basics. (line 59)
-* fixMN2 instruction pattern: Standard Names. (line 806)
-* FIXUNS_TRUNC_LIKE_FIX_TRUNC: Misc. (line 100)
-* fixuns_truncMN2 instruction pattern: Standard Names. (line 830)
-* fixunsMN2 instruction pattern: Standard Names. (line 815)
-* flags in RTL expression: Flags. (line 6)
-* float: Conversions. (line 58)
-* FLOAT_EXPR: Unary and Binary Expressions.
- (line 6)
-* float_extend: Conversions. (line 33)
-* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 25)
-* FLOAT_STORE_FLAG_VALUE: Misc. (line 301)
-* float_truncate: Conversions. (line 53)
-* FLOAT_TYPE_SIZE: Type Layout. (line 49)
-* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 36)
-* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory.
- (line 226)
-* floating point and cross compilation: Floating Point. (line 6)
-* Floating Point Emulation: Target Fragment. (line 15)
-* floatMN2 instruction pattern: Standard Names. (line 798)
-* floatunsMN2 instruction pattern: Standard Names. (line 802)
-* FLOOR_DIV_EXPR: Unary and Binary Expressions.
- (line 6)
-* FLOOR_MOD_EXPR: Unary and Binary Expressions.
- (line 6)
-* floorM2 instruction pattern: Standard Names. (line 559)
-* flow-insensitive alias analysis: Alias analysis. (line 6)
-* flow-sensitive alias analysis: Alias analysis. (line 6)
-* fma: Arithmetic. (line 111)
-* fmaM4 instruction pattern: Standard Names. (line 234)
-* fmodM3 instruction pattern: Standard Names. (line 490)
-* fmsM4 instruction pattern: Standard Names. (line 243)
-* fnmaM4 instruction pattern: Standard Names. (line 249)
-* fnmsM4 instruction pattern: Standard Names. (line 255)
-* FOR_BODY: Statements for C++. (line 6)
-* FOR_COND: Statements for C++. (line 6)
-* FOR_EXPR: Statements for C++. (line 6)
-* FOR_INIT_STMT: Statements for C++. (line 6)
-* FOR_STMT: Statements for C++. (line 6)
-* FORCE_CODE_SECTION_ALIGN: Sections. (line 146)
-* force_reg: Standard Names. (line 36)
-* fract_convert: Conversions. (line 82)
-* FRACT_TYPE_SIZE: Type Layout. (line 68)
-* fractional types: Fixed-point fractional library routines.
- (line 6)
-* fractMN2 instruction pattern: Standard Names. (line 848)
-* fractunsMN2 instruction pattern: Standard Names. (line 863)
-* frame layout: Frame Layout. (line 6)
-* FRAME_ADDR_RTX: Frame Layout. (line 116)
-* FRAME_GROWS_DOWNWARD: Frame Layout. (line 31)
-* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory.
- (line 69)
-* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 212)
-* frame_pointer_needed: Function Entry. (line 34)
-* FRAME_POINTER_REGNUM: Frame Registers. (line 14)
-* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory.
- (line 74)
-* frame_pointer_rtx: Frame Registers. (line 104)
-* frame_related: Flags. (line 247)
-* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags.
- (line 125)
-* frame_related, in mem: Flags. (line 103)
-* frame_related, in reg: Flags. (line 112)
-* frame_related, in symbol_ref: Flags. (line 183)
-* frequency, count, BB_FREQ_BASE: Profile information.
- (line 30)
-* ftruncM2 instruction pattern: Standard Names. (line 821)
-* function <1>: Functions for C++. (line 6)
-* function: Functions. (line 6)
-* function call conventions: Interface. (line 6)
-* function entry and exit: Function Entry. (line 6)
-* function entry point, alternate function entry point: Edges.
- (line 180)
-* function properties: Function Properties.
- (line 6)
-* function-call insns: Calls. (line 6)
-* FUNCTION_ARG: Register Arguments. (line 11)
-* FUNCTION_ARG_ADVANCE: Register Arguments. (line 185)
-* FUNCTION_ARG_OFFSET: Register Arguments. (line 196)
-* FUNCTION_ARG_PADDING: Register Arguments. (line 203)
-* FUNCTION_ARG_REGNO_P: Register Arguments. (line 244)
-* FUNCTION_BOUNDARY: Storage Layout. (line 158)
-* FUNCTION_DECL <1>: Functions. (line 6)
-* FUNCTION_DECL: Functions for C++. (line 6)
-* FUNCTION_INCOMING_ARG: Register Arguments. (line 68)
-* FUNCTION_MODE: Misc. (line 356)
-* FUNCTION_PROFILER: Profiling. (line 9)
-* FUNCTION_TYPE: Types. (line 6)
-* FUNCTION_VALUE: Scalar Return. (line 52)
-* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78)
-* functions, leaf: Leaf Functions. (line 6)
-* fundamental type: Types. (line 6)
-* G in constraint: Simple Constraints. (line 98)
-* g in constraint: Simple Constraints. (line 120)
-* garbage collector, invocation: Invoking the garbage collector.
- (line 6)
-* garbage collector, troubleshooting: Troubleshooting. (line 6)
-* GCC and portability: Portability. (line 6)
-* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36)
-* gcov_type: Profile information.
- (line 41)
-* ge: Comparisons. (line 72)
-* ge and attributes: Expressions. (line 64)
-* GE_EXPR: Unary and Binary Expressions.
- (line 6)
-* GEN_ERRNO_RTX: Library Calls. (line 57)
-* gencodes: RTL passes. (line 18)
-* general_operand: Machine-Independent Predicates.
- (line 105)
-* GENERAL_REGS: Register Classes. (line 23)
-* generated files: Files. (line 6)
-* generating assembler output: Output Statement. (line 6)
-* generating insns: RTL Template. (line 6)
-* GENERIC <1>: GENERIC. (line 6)
-* GENERIC: Parsing pass. (line 6)
-* generic predicates: Machine-Independent Predicates.
- (line 6)
-* genflags: RTL passes. (line 18)
-* get_attr: Expressions. (line 80)
-* get_attr_length: Insn Lengths. (line 46)
-* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 333)
-* GET_CODE: RTL Objects. (line 47)
-* get_frame_size: Elimination. (line 34)
-* get_insns: Insns. (line 34)
-* get_last_insn: Insns. (line 34)
-* GET_MODE: Machine Modes. (line 280)
-* GET_MODE_ALIGNMENT: Machine Modes. (line 320)
-* GET_MODE_BITSIZE: Machine Modes. (line 304)
-* GET_MODE_CLASS: Machine Modes. (line 294)
-* GET_MODE_FBIT: Machine Modes. (line 311)
-* GET_MODE_IBIT: Machine Modes. (line 307)
-* GET_MODE_MASK: Machine Modes. (line 315)
-* GET_MODE_NAME: Machine Modes. (line 291)
-* GET_MODE_NUNITS: Machine Modes. (line 329)
-* GET_MODE_SIZE: Machine Modes. (line 301)
-* GET_MODE_UNIT_SIZE: Machine Modes. (line 323)
-* GET_MODE_WIDER_MODE: Machine Modes. (line 297)
-* GET_RTX_CLASS: RTL Classes. (line 6)
-* GET_RTX_FORMAT: RTL Classes. (line 131)
-* GET_RTX_LENGTH: RTL Classes. (line 128)
-* geu: Comparisons. (line 72)
-* geu and attributes: Expressions. (line 64)
-* GGC: Type Information. (line 6)
-* ggc_collect: Invoking the garbage collector.
- (line 6)
-* GIMPLE <1>: Gimplification pass.
- (line 6)
-* GIMPLE <2>: GIMPLE. (line 6)
-* GIMPLE: Parsing pass. (line 14)
-* GIMPLE Exception Handling: GIMPLE Exception Handling.
- (line 6)
-* GIMPLE instruction set: GIMPLE instruction set.
- (line 6)
-* GIMPLE sequences: GIMPLE sequences. (line 6)
-* gimple_addresses_taken: Manipulating GIMPLE statements.
- (line 90)
-* GIMPLE_ASM: GIMPLE_ASM. (line 6)
-* gimple_asm_clear_volatile: GIMPLE_ASM. (line 63)
-* gimple_asm_clobber_op: GIMPLE_ASM. (line 46)
-* gimple_asm_input_op: GIMPLE_ASM. (line 30)
-* gimple_asm_nclobbers: GIMPLE_ASM. (line 27)
-* gimple_asm_ninputs: GIMPLE_ASM. (line 21)
-* gimple_asm_noutputs: GIMPLE_ASM. (line 24)
-* gimple_asm_output_op: GIMPLE_ASM. (line 38)
-* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 50)
-* gimple_asm_set_input_op: GIMPLE_ASM. (line 34)
-* gimple_asm_set_output_op: GIMPLE_ASM. (line 42)
-* gimple_asm_set_volatile: GIMPLE_ASM. (line 60)
-* gimple_asm_string: GIMPLE_ASM. (line 53)
-* gimple_asm_volatile_p: GIMPLE_ASM. (line 57)
-* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6)
-* gimple_assign_cast_p <1>: Logical Operators. (line 160)
-* gimple_assign_cast_p: GIMPLE_ASSIGN. (line 93)
-* gimple_assign_lhs: GIMPLE_ASSIGN. (line 51)
-* gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 54)
-* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 57)
-* gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 60)
-* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 64)
-* gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 67)
-* gimple_assign_rhs3: GIMPLE_ASSIGN. (line 71)
-* gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 74)
-* gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 46)
-* gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 41)
-* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 78)
-* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 81)
-* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 85)
-* gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 89)
-* gimple_bb: Manipulating GIMPLE statements.
- (line 18)
-* GIMPLE_BIND: GIMPLE_BIND. (line 6)
-* gimple_bind_add_seq: GIMPLE_BIND. (line 36)
-* gimple_bind_add_stmt: GIMPLE_BIND. (line 32)
-* gimple_bind_append_vars: GIMPLE_BIND. (line 19)
-* gimple_bind_block: GIMPLE_BIND. (line 40)
-* gimple_bind_body: GIMPLE_BIND. (line 23)
-* gimple_bind_set_block: GIMPLE_BIND. (line 45)
-* gimple_bind_set_body: GIMPLE_BIND. (line 28)
-* gimple_bind_set_vars: GIMPLE_BIND. (line 15)
-* gimple_bind_vars: GIMPLE_BIND. (line 12)
-* gimple_block: Manipulating GIMPLE statements.
- (line 21)
-* gimple_build_asm: GIMPLE_ASM. (line 8)
-* gimple_build_asm_vec: GIMPLE_ASM. (line 17)
-* gimple_build_assign: GIMPLE_ASSIGN. (line 7)
-* gimple_build_assign_with_ops: GIMPLE_ASSIGN. (line 30)
-* gimple_build_bind: GIMPLE_BIND. (line 8)
-* gimple_build_call: GIMPLE_CALL. (line 8)
-* gimple_build_call_from_tree: GIMPLE_CALL. (line 16)
-* gimple_build_call_vec: GIMPLE_CALL. (line 25)
-* gimple_build_catch: GIMPLE_CATCH. (line 8)
-* gimple_build_cond: GIMPLE_COND. (line 8)
-* gimple_build_cond_from_tree: GIMPLE_COND. (line 16)
-* gimple_build_debug_bind: GIMPLE_DEBUG. (line 8)
-* gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 8)
-* gimple_build_goto: GIMPLE_LABEL. (line 18)
-* gimple_build_label: GIMPLE_LABEL. (line 7)
-* gimple_build_nop: GIMPLE_NOP. (line 7)
-* gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD.
- (line 8)
-* gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE.
- (line 7)
-* gimple_build_omp_continue: GIMPLE_OMP_CONTINUE.
- (line 8)
-* gimple_build_omp_critical: GIMPLE_OMP_CRITICAL.
- (line 8)
-* gimple_build_omp_for: GIMPLE_OMP_FOR. (line 9)
-* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 7)
-* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 7)
-* gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL.
- (line 8)
-* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 7)
-* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 7)
-* gimple_build_omp_sections: GIMPLE_OMP_SECTIONS.
- (line 8)
-* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS.
- (line 14)
-* gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 8)
-* gimple_build_resx: GIMPLE_RESX. (line 7)
-* gimple_build_return: GIMPLE_RETURN. (line 7)
-* gimple_build_switch: GIMPLE_SWITCH. (line 8)
-* gimple_build_switch_vec: GIMPLE_SWITCH. (line 16)
-* gimple_build_try: GIMPLE_TRY. (line 8)
-* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR.
- (line 7)
-* GIMPLE_CALL: GIMPLE_CALL. (line 6)
-* gimple_call_arg: GIMPLE_CALL. (line 66)
-* gimple_call_arg_ptr: GIMPLE_CALL. (line 71)
-* gimple_call_cannot_inline_p: GIMPLE_CALL. (line 91)
-* gimple_call_chain: GIMPLE_CALL. (line 57)
-* gimple_call_copy_skip_args: GIMPLE_CALL. (line 98)
-* gimple_call_fn: GIMPLE_CALL. (line 38)
-* gimple_call_fndecl: GIMPLE_CALL. (line 46)
-* gimple_call_lhs: GIMPLE_CALL. (line 29)
-* gimple_call_lhs_ptr: GIMPLE_CALL. (line 32)
-* gimple_call_mark_uninlinable: GIMPLE_CALL. (line 88)
-* gimple_call_noreturn_p: GIMPLE_CALL. (line 94)
-* gimple_call_num_args: GIMPLE_CALL. (line 63)
-* gimple_call_return_type: GIMPLE_CALL. (line 54)
-* gimple_call_set_arg: GIMPLE_CALL. (line 76)
-* gimple_call_set_chain: GIMPLE_CALL. (line 60)
-* gimple_call_set_fn: GIMPLE_CALL. (line 42)
-* gimple_call_set_fndecl: GIMPLE_CALL. (line 51)
-* gimple_call_set_lhs: GIMPLE_CALL. (line 35)
-* gimple_call_set_tail: GIMPLE_CALL. (line 80)
-* gimple_call_tail_p: GIMPLE_CALL. (line 85)
-* GIMPLE_CATCH: GIMPLE_CATCH. (line 6)
-* gimple_catch_handler: GIMPLE_CATCH. (line 20)
-* gimple_catch_set_handler: GIMPLE_CATCH. (line 28)
-* gimple_catch_set_types: GIMPLE_CATCH. (line 24)
-* gimple_catch_types: GIMPLE_CATCH. (line 13)
-* gimple_catch_types_ptr: GIMPLE_CATCH. (line 16)
-* gimple_code: Manipulating GIMPLE statements.
- (line 15)
-* GIMPLE_COND: GIMPLE_COND. (line 6)
-* gimple_cond_code: GIMPLE_COND. (line 21)
-* gimple_cond_false_label: GIMPLE_COND. (line 60)
-* gimple_cond_lhs: GIMPLE_COND. (line 30)
-* gimple_cond_make_false: GIMPLE_COND. (line 64)
-* gimple_cond_make_true: GIMPLE_COND. (line 67)
-* gimple_cond_rhs: GIMPLE_COND. (line 38)
-* gimple_cond_set_code: GIMPLE_COND. (line 26)
-* gimple_cond_set_false_label: GIMPLE_COND. (line 56)
-* gimple_cond_set_lhs: GIMPLE_COND. (line 34)
-* gimple_cond_set_rhs: GIMPLE_COND. (line 42)
-* gimple_cond_set_true_label: GIMPLE_COND. (line 51)
-* gimple_cond_true_label: GIMPLE_COND. (line 46)
-* gimple_copy: Manipulating GIMPLE statements.
- (line 147)
-* GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6)
-* GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6)
-* gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 48)
-* gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 53)
-* gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 45)
-* gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 70)
-* gimple_debug_bind_p: Logical Operators. (line 164)
-* gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 66)
-* gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 62)
-* gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 58)
-* gimple_def_ops: Manipulating GIMPLE statements.
- (line 94)
-* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6)
-* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 19)
-* gimple_eh_filter_must_not_throw: GIMPLE_EH_FILTER. (line 33)
-* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 29)
-* gimple_eh_filter_set_must_not_throw: GIMPLE_EH_FILTER. (line 37)
-* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 24)
-* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 12)
-* gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 15)
-* gimple_expr_code: Manipulating GIMPLE statements.
- (line 31)
-* gimple_expr_type: Manipulating GIMPLE statements.
- (line 24)
-* gimple_goto_dest: GIMPLE_LABEL. (line 21)
-* gimple_goto_set_dest: GIMPLE_LABEL. (line 24)
-* gimple_has_mem_ops: Manipulating GIMPLE statements.
- (line 72)
-* gimple_has_ops: Manipulating GIMPLE statements.
- (line 69)
-* gimple_has_volatile_ops: Manipulating GIMPLE statements.
- (line 134)
-* GIMPLE_LABEL: GIMPLE_LABEL. (line 6)
-* gimple_label_label: GIMPLE_LABEL. (line 11)
-* gimple_label_set_label: GIMPLE_LABEL. (line 14)
-* gimple_loaded_syms: Manipulating GIMPLE statements.
- (line 122)
-* gimple_locus: Manipulating GIMPLE statements.
- (line 42)
-* gimple_locus_empty_p: Manipulating GIMPLE statements.
- (line 48)
-* gimple_modified_p: Manipulating GIMPLE statements.
- (line 130)
-* gimple_no_warning_p: Manipulating GIMPLE statements.
- (line 51)
-* GIMPLE_NOP: GIMPLE_NOP. (line 6)
-* gimple_nop_p: GIMPLE_NOP. (line 10)
-* gimple_num_ops <1>: Logical Operators. (line 78)
-* gimple_num_ops: Manipulating GIMPLE statements.
- (line 75)
-* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD.
- (line 6)
-* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD.
- (line 17)
-* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD.
- (line 24)
-* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD.
- (line 14)
-* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD.
- (line 21)
-* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE.
- (line 6)
-* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE.
- (line 12)
-* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE.
- (line 15)
-* gimple_omp_body: GIMPLE_OMP_PARALLEL.
- (line 24)
-* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE.
- (line 6)
-* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE.
- (line 13)
-* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE.
- (line 17)
-* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE.
- (line 24)
-* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE.
- (line 28)
-* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE.
- (line 20)
-* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE.
- (line 31)
-* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL.
- (line 6)
-* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL.
- (line 13)
-* gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL.
- (line 16)
-* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL.
- (line 21)
-* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6)
-* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 20)
-* gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 23)
-* gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 83)
-* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 51)
-* gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 54)
-* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 61)
-* gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 64)
-* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 31)
-* gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 34)
-* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 41)
-* gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 44)
-* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 70)
-* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 27)
-* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 80)
-* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 58)
-* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 67)
-* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 38)
-* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 48)
-* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 75)
-* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6)
-* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6)
-* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL.
- (line 6)
-* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL.
- (line 42)
-* gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL.
- (line 46)
-* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL.
- (line 31)
-* gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL.
- (line 34)
-* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL.
- (line 16)
-* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL.
- (line 54)
-* gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL.
- (line 58)
-* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL.
- (line 51)
-* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL.
- (line 38)
-* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL.
- (line 20)
-* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL.
- (line 62)
-* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6)
-* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 14)
-* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 11)
-* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6)
-* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 12)
-* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 16)
-* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS.
- (line 6)
-* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS.
- (line 30)
-* gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS.
- (line 33)
-* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS.
- (line 17)
-* gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS.
- (line 21)
-* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS.
- (line 37)
-* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS.
- (line 26)
-* gimple_omp_set_body: GIMPLE_OMP_PARALLEL.
- (line 28)
-* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6)
-* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 14)
-* gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 17)
-* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 21)
-* gimple_op <1>: Manipulating GIMPLE statements.
- (line 81)
-* gimple_op: Logical Operators. (line 81)
-* gimple_op_ptr: Manipulating GIMPLE statements.
- (line 84)
-* gimple_ops <1>: Logical Operators. (line 84)
-* gimple_ops: Manipulating GIMPLE statements.
- (line 78)
-* GIMPLE_PHI: GIMPLE_PHI. (line 6)
-* gimple_phi_arg: GIMPLE_PHI. (line 28)
-* gimple_phi_capacity: GIMPLE_PHI. (line 10)
-* gimple_phi_num_args: GIMPLE_PHI. (line 14)
-* gimple_phi_result: GIMPLE_PHI. (line 19)
-* gimple_phi_result_ptr: GIMPLE_PHI. (line 22)
-* gimple_phi_set_arg: GIMPLE_PHI. (line 33)
-* gimple_phi_set_result: GIMPLE_PHI. (line 25)
-* gimple_plf: Manipulating GIMPLE statements.
- (line 66)
-* GIMPLE_RESX: GIMPLE_RESX. (line 6)
-* gimple_resx_region: GIMPLE_RESX. (line 13)
-* gimple_resx_set_region: GIMPLE_RESX. (line 16)
-* GIMPLE_RETURN: GIMPLE_RETURN. (line 6)
-* gimple_return_retval: GIMPLE_RETURN. (line 10)
-* gimple_return_set_retval: GIMPLE_RETURN. (line 14)
-* gimple_seq_add_seq: GIMPLE sequences. (line 32)
-* gimple_seq_add_stmt: GIMPLE sequences. (line 26)
-* gimple_seq_alloc: GIMPLE sequences. (line 62)
-* gimple_seq_copy: GIMPLE sequences. (line 67)
-* gimple_seq_deep_copy: GIMPLE sequences. (line 37)
-* gimple_seq_empty_p: GIMPLE sequences. (line 70)
-* gimple_seq_first: GIMPLE sequences. (line 44)
-* gimple_seq_init: GIMPLE sequences. (line 59)
-* gimple_seq_last: GIMPLE sequences. (line 47)
-* gimple_seq_reverse: GIMPLE sequences. (line 40)
-* gimple_seq_set_first: GIMPLE sequences. (line 55)
-* gimple_seq_set_last: GIMPLE sequences. (line 51)
-* gimple_seq_singleton_p: GIMPLE sequences. (line 79)
-* gimple_set_block: Manipulating GIMPLE statements.
- (line 39)
-* gimple_set_def_ops: Manipulating GIMPLE statements.
- (line 98)
-* gimple_set_has_volatile_ops: Manipulating GIMPLE statements.
- (line 138)
-* gimple_set_locus: Manipulating GIMPLE statements.
- (line 45)
-* gimple_set_op: Manipulating GIMPLE statements.
- (line 87)
-* gimple_set_plf: Manipulating GIMPLE statements.
- (line 62)
-* gimple_set_use_ops: Manipulating GIMPLE statements.
- (line 105)
-* gimple_set_vdef_ops: Manipulating GIMPLE statements.
- (line 119)
-* gimple_set_visited: Manipulating GIMPLE statements.
- (line 55)
-* gimple_set_vuse_ops: Manipulating GIMPLE statements.
- (line 112)
-* gimple_statement_base: Tuple representation.
- (line 14)
-* gimple_statement_with_ops: Tuple representation.
- (line 96)
-* gimple_stored_syms: Manipulating GIMPLE statements.
- (line 126)
-* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6)
-* gimple_switch_default_label: GIMPLE_SWITCH. (line 46)
-* gimple_switch_index: GIMPLE_SWITCH. (line 31)
-* gimple_switch_label: GIMPLE_SWITCH. (line 37)
-* gimple_switch_num_labels: GIMPLE_SWITCH. (line 22)
-* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 50)
-* gimple_switch_set_index: GIMPLE_SWITCH. (line 34)
-* gimple_switch_set_label: GIMPLE_SWITCH. (line 42)
-* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 27)
-* GIMPLE_TRY: GIMPLE_TRY. (line 6)
-* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 20)
-* gimple_try_cleanup: GIMPLE_TRY. (line 27)
-* gimple_try_eval: GIMPLE_TRY. (line 23)
-* gimple_try_kind: GIMPLE_TRY. (line 16)
-* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 32)
-* gimple_try_set_cleanup: GIMPLE_TRY. (line 41)
-* gimple_try_set_eval: GIMPLE_TRY. (line 36)
-* gimple_use_ops: Manipulating GIMPLE statements.
- (line 101)
-* gimple_vdef_ops: Manipulating GIMPLE statements.
- (line 115)
-* gimple_visited_p: Manipulating GIMPLE statements.
- (line 58)
-* gimple_vuse_ops: Manipulating GIMPLE statements.
- (line 108)
-* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR.
- (line 11)
-* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR.
- (line 18)
-* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR.
- (line 15)
-* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR.
- (line 22)
-* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR.
- (line 6)
-* gimplification <1>: Parsing pass. (line 14)
-* gimplification: Gimplification pass.
- (line 6)
-* gimplifier: Parsing pass. (line 14)
-* gimplify_assign: GIMPLE_ASSIGN. (line 19)
-* gimplify_expr: Gimplification pass.
- (line 18)
-* gimplify_function_tree: Gimplification pass.
- (line 18)
-* GLOBAL_INIT_PRIORITY: Functions for C++. (line 141)
-* global_regs: Register Basics. (line 59)
-* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 91)
-* GO_IF_MODE_DEPENDENT_ADDRESS: Addressing Modes. (line 212)
-* greater than: Comparisons. (line 60)
-* gsi_after_labels: Sequence iterators. (line 76)
-* gsi_bb: Sequence iterators. (line 83)
-* gsi_commit_edge_inserts: Sequence iterators. (line 194)
-* gsi_commit_one_edge_insert: Sequence iterators. (line 190)
-* gsi_end_p: Sequence iterators. (line 60)
-* gsi_for_stmt: Sequence iterators. (line 157)
-* gsi_insert_after: Sequence iterators. (line 147)
-* gsi_insert_before: Sequence iterators. (line 136)
-* gsi_insert_on_edge: Sequence iterators. (line 174)
-* gsi_insert_on_edge_immediate: Sequence iterators. (line 185)
-* gsi_insert_seq_after: Sequence iterators. (line 154)
-* gsi_insert_seq_before: Sequence iterators. (line 143)
-* gsi_insert_seq_on_edge: Sequence iterators. (line 179)
-* gsi_last: Sequence iterators. (line 50)
-* gsi_last_bb: Sequence iterators. (line 56)
-* gsi_link_after: Sequence iterators. (line 115)
-* gsi_link_before: Sequence iterators. (line 105)
-* gsi_link_seq_after: Sequence iterators. (line 110)
-* gsi_link_seq_before: Sequence iterators. (line 99)
-* gsi_move_after: Sequence iterators. (line 161)
-* gsi_move_before: Sequence iterators. (line 166)
-* gsi_move_to_bb_end: Sequence iterators. (line 171)
-* gsi_next: Sequence iterators. (line 66)
-* gsi_one_before_end_p: Sequence iterators. (line 63)
-* gsi_prev: Sequence iterators. (line 69)
-* gsi_remove: Sequence iterators. (line 90)
-* gsi_replace: Sequence iterators. (line 130)
-* gsi_seq: Sequence iterators. (line 86)
-* gsi_split_seq_after: Sequence iterators. (line 120)
-* gsi_split_seq_before: Sequence iterators. (line 125)
-* gsi_start: Sequence iterators. (line 40)
-* gsi_start_bb: Sequence iterators. (line 46)
-* gsi_stmt: Sequence iterators. (line 72)
-* gsi_stmt_ptr: Sequence iterators. (line 80)
-* gt: Comparisons. (line 60)
-* gt and attributes: Expressions. (line 64)
-* GT_EXPR: Unary and Binary Expressions.
- (line 6)
-* gtu: Comparisons. (line 64)
-* gtu and attributes: Expressions. (line 64)
-* GTY: Type Information. (line 6)
-* H in constraint: Simple Constraints. (line 98)
-* HAmode: Machine Modes. (line 144)
-* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 438)
-* HANDLER: Statements for C++. (line 6)
-* HANDLER_BODY: Statements for C++. (line 6)
-* HANDLER_PARMS: Statements for C++. (line 6)
-* hard registers: Regs and Memory. (line 9)
-* HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 58)
-* HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 51)
-* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20)
-* HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53)
-* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 20)
-* HARD_REGNO_MODE_OK: Values in Registers.
- (line 58)
-* HARD_REGNO_NREGS: Values in Registers.
- (line 11)
-* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers.
- (line 25)
-* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers.
- (line 43)
-* HARD_REGNO_RENAME_OK: Values in Registers.
- (line 119)
-* HAS_INIT_SECTION: Macros for Initialization.
- (line 19)
-* HAS_LONG_COND_BRANCH: Misc. (line 9)
-* HAS_LONG_UNCOND_BRANCH: Misc. (line 18)
-* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11)
-* HAVE_POST_DECREMENT: Addressing Modes. (line 12)
-* HAVE_POST_INCREMENT: Addressing Modes. (line 11)
-* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18)
-* HAVE_POST_MODIFY_REG: Addressing Modes. (line 24)
-* HAVE_PRE_DECREMENT: Addressing Modes. (line 10)
-* HAVE_PRE_INCREMENT: Addressing Modes. (line 9)
-* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17)
-* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23)
-* HCmode: Machine Modes. (line 197)
-* HFmode: Machine Modes. (line 58)
-* high: Constants. (line 109)
-* HImode: Machine Modes. (line 29)
-* HImode, in insn: Insns. (line 272)
-* HONOR_REG_ALLOC_ORDER: Allocation Order. (line 37)
-* host configuration: Host Config. (line 6)
-* host functions: Host Common. (line 6)
-* host hooks: Host Common. (line 6)
-* host makefile fragment: Host Fragment. (line 6)
-* HOST_BIT_BUCKET: Filesystem. (line 51)
-* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45)
-* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 12)
-* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 45)
-* HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 17)
-* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 26)
-* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89)
-* HOST_LONG_FORMAT: Host Misc. (line 45)
-* HOST_LONG_LONG_FORMAT: Host Misc. (line 41)
-* HOST_OBJECT_SUFFIX: Filesystem. (line 40)
-* HOST_PTR_PRINTF: Host Misc. (line 49)
-* HOT_TEXT_SECTION_NAME: Sections. (line 43)
-* HQmode: Machine Modes. (line 107)
-* i in constraint: Simple Constraints. (line 70)
-* I in constraint: Simple Constraints. (line 81)
-* identifier: Identifiers. (line 6)
-* IDENTIFIER_LENGTH: Identifiers. (line 22)
-* IDENTIFIER_NODE: Identifiers. (line 6)
-* IDENTIFIER_OPNAME_P: Identifiers. (line 27)
-* IDENTIFIER_POINTER: Identifiers. (line 17)
-* IDENTIFIER_TYPENAME_P: Identifiers. (line 33)
-* IEEE 754-2008: Decimal float library routines.
- (line 6)
-* IF_COND: Statements for C++. (line 6)
-* if_marked: GTY Options. (line 151)
-* IF_STMT: Statements for C++. (line 6)
-* if_then_else: Comparisons. (line 80)
-* if_then_else and attributes: Expressions. (line 32)
-* if_then_else usage: Side Effects. (line 56)
-* IFCVT_EXTRA_FIELDS: Misc. (line 582)
-* IFCVT_INIT_EXTRA_FIELDS: Misc. (line 577)
-* IFCVT_MODIFY_CANCEL: Misc. (line 571)
-* IFCVT_MODIFY_FINAL: Misc. (line 565)
-* IFCVT_MODIFY_INSN: Misc. (line 559)
-* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 552)
-* IFCVT_MODIFY_TESTS: Misc. (line 541)
-* IMAGPART_EXPR: Unary and Binary Expressions.
- (line 6)
-* Immediate Uses: SSA Operands. (line 274)
-* immediate_operand: Machine-Independent Predicates.
- (line 11)
-* IMMEDIATE_PREFIX: Instruction Output. (line 155)
-* in_struct: Flags. (line 263)
-* in_struct, in code_label and note: Flags. (line 59)
-* in_struct, in insn and jump_insn and call_insn: Flags. (line 49)
-* in_struct, in insn, jump_insn and call_insn: Flags. (line 166)
-* in_struct, in mem: Flags. (line 70)
-* in_struct, in subreg: Flags. (line 205)
-* include: Including Patterns. (line 6)
-* INCLUDE_DEFAULTS: Driver. (line 344)
-* inclusive-or, bitwise: Arithmetic. (line 163)
-* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 183)
-* INCOMING_REGNO: Register Basics. (line 88)
-* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 139)
-* INCOMING_STACK_BOUNDARY: Storage Layout. (line 153)
-* INDEX_REG_CLASS: Register Classes. (line 136)
-* indirect_jump instruction pattern: Standard Names. (line 1078)
-* indirect_operand: Machine-Independent Predicates.
- (line 71)
-* INDIRECT_REF: Storage References. (line 6)
-* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 108)
-* INIT_CUMULATIVE_ARGS: Register Arguments. (line 149)
-* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 176)
-* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 170)
-* INIT_ENVIRONMENT: Driver. (line 306)
-* INIT_EXPANDERS: Per-Function Data. (line 39)
-* INIT_EXPR: Unary and Binary Expressions.
- (line 6)
-* init_machine_status: Per-Function Data. (line 45)
-* init_one_libfunc: Library Calls. (line 15)
-* INIT_SECTION_ASM_OP <1>: Macros for Initialization.
- (line 10)
-* INIT_SECTION_ASM_OP: Sections. (line 92)
-* INITIAL_ELIMINATION_OFFSET: Elimination. (line 85)
-* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 83)
-* INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 35)
-* initialization routines: Initialization. (line 6)
-* inlining: Target Attributes. (line 95)
-* insert_insn_on_edge: Maintaining the CFG.
- (line 118)
-* insn: Insns. (line 63)
-* insn and /f: Flags. (line 125)
-* insn and /j: Flags. (line 175)
-* insn and /s: Flags. (line 166)
-* insn and /u: Flags. (line 39)
-* insn and /v: Flags. (line 44)
-* insn attributes: Insn Attributes. (line 6)
-* insn canonicalization: Insn Canonicalizations.
- (line 6)
-* insn includes: Including Patterns. (line 6)
-* insn lengths, computing: Insn Lengths. (line 6)
-* insn splitting: Insn Splitting. (line 6)
-* insn-attr.h: Defining Attributes.
- (line 24)
-* INSN_ANNULLED_BRANCH_P: Flags. (line 39)
-* INSN_CODE: Insns. (line 298)
-* INSN_DELETED_P: Flags. (line 44)
-* INSN_FROM_TARGET_P: Flags. (line 49)
-* insn_list: Insns. (line 545)
-* INSN_REFERENCES_ARE_DELAYED: Misc. (line 480)
-* INSN_SETS_ARE_DELAYED: Misc. (line 469)
-* INSN_UID: Insns. (line 23)
-* INSN_VAR_LOCATION: Insns. (line 239)
-* insns: Insns. (line 6)
-* insns, generating: RTL Template. (line 6)
-* insns, recognizing: RTL Template. (line 6)
-* instruction attributes: Insn Attributes. (line 6)
-* instruction latency time: Processor pipeline description.
- (line 197)
-* instruction patterns: Patterns. (line 6)
-* instruction splitting: Insn Splitting. (line 6)
-* insv instruction pattern: Standard Names. (line 893)
-* INT16_TYPE: Type Layout. (line 236)
-* INT32_TYPE: Type Layout. (line 237)
-* INT64_TYPE: Type Layout. (line 238)
-* INT8_TYPE: Type Layout. (line 235)
-* INT_FAST16_TYPE: Type Layout. (line 252)
-* INT_FAST32_TYPE: Type Layout. (line 253)
-* INT_FAST64_TYPE: Type Layout. (line 254)
-* INT_FAST8_TYPE: Type Layout. (line 251)
-* INT_LEAST16_TYPE: Type Layout. (line 244)
-* INT_LEAST32_TYPE: Type Layout. (line 245)
-* INT_LEAST64_TYPE: Type Layout. (line 246)
-* INT_LEAST8_TYPE: Type Layout. (line 243)
-* INT_TYPE_SIZE: Type Layout. (line 12)
-* INTEGER_CST: Constant expressions.
- (line 6)
-* INTEGER_TYPE: Types. (line 6)
-* Interdependence of Patterns: Dependent Patterns. (line 6)
-* interfacing to GCC output: Interface. (line 6)
-* interlock delays: Processor pipeline description.
- (line 6)
-* intermediate representation lowering: Parsing pass. (line 14)
-* INTMAX_TYPE: Type Layout. (line 212)
-* INTPTR_TYPE: Type Layout. (line 259)
-* introduction: Top. (line 6)
-* INVOKE__main: Macros for Initialization.
- (line 51)
-* ior: Arithmetic. (line 163)
-* ior and attributes: Expressions. (line 50)
-* ior, canonicalization of: Insn Canonicalizations.
- (line 52)
-* iorM3 instruction pattern: Standard Names. (line 222)
-* IRA_COVER_CLASSES: Register Classes. (line 564)
-* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 45)
-* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 132)
-* is_gimple_addressable: Logical Operators. (line 115)
-* is_gimple_asm_val: Logical Operators. (line 119)
-* is_gimple_assign: Logical Operators. (line 151)
-* is_gimple_call: Logical Operators. (line 154)
-* is_gimple_call_addr: Logical Operators. (line 122)
-* is_gimple_constant: Logical Operators. (line 130)
-* is_gimple_debug: Logical Operators. (line 157)
-* is_gimple_ip_invariant: Logical Operators. (line 139)
-* is_gimple_ip_invariant_address: Logical Operators. (line 144)
-* is_gimple_mem_ref_addr: Logical Operators. (line 126)
-* is_gimple_min_invariant: Logical Operators. (line 133)
-* is_gimple_omp: GIMPLE_OMP_PARALLEL.
- (line 65)
-* is_gimple_val: Logical Operators. (line 109)
-* iterators in .md files: Iterators. (line 6)
-* IV analysis on GIMPLE: Scalar evolutions. (line 6)
-* IV analysis on RTL: loop-iv. (line 6)
-* jump: Flags. (line 314)
-* jump instruction pattern: Standard Names. (line 969)
-* jump instruction patterns: Jump Patterns. (line 6)
-* jump instructions and set: Side Effects. (line 56)
-* jump, in call_insn: Flags. (line 179)
-* jump, in insn: Flags. (line 175)
-* jump, in mem: Flags. (line 79)
-* JUMP_ALIGN: Alignment Output. (line 9)
-* jump_insn: Insns. (line 73)
-* jump_insn and /f: Flags. (line 125)
-* jump_insn and /s: Flags. (line 49)
-* jump_insn and /u: Flags. (line 39)
-* jump_insn and /v: Flags. (line 44)
-* JUMP_LABEL: Insns. (line 80)
-* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 152)
-* Jumps: Jumps. (line 6)
-* LABEL_ALIGN: Alignment Output. (line 58)
-* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 27)
-* LABEL_ALT_ENTRY_P: Insns. (line 140)
-* LABEL_ALTERNATE_NAME: Edges. (line 180)
-* LABEL_DECL: Declarations. (line 6)
-* LABEL_KIND: Insns. (line 140)
-* LABEL_NUSES: Insns. (line 136)
-* LABEL_PRESERVE_P: Flags. (line 59)
-* label_ref: Constants. (line 86)
-* label_ref and /v: Flags. (line 65)
-* label_ref, RTL sharing: Sharing. (line 35)
-* LABEL_REF_NONLOCAL_P: Flags. (line 65)
-* lang_hooks.gimplify_expr: Gimplification pass.
- (line 18)
-* lang_hooks.parse_file: Parsing pass. (line 6)
-* language-dependent trees: Language-dependent trees.
- (line 6)
-* language-independent intermediate representation: Parsing pass.
- (line 14)
-* large return values: Aggregate Return. (line 6)
-* LARGEST_EXPONENT_IS_NORMAL: Storage Layout. (line 470)
-* LAST_STACK_REG: Stack Registers. (line 31)
-* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51)
-* lceilMN2: Standard Names. (line 624)
-* LCSSA: LCSSA. (line 6)
-* LD_FINI_SWITCH: Macros for Initialization.
- (line 29)
-* LD_INIT_SWITCH: Macros for Initialization.
- (line 25)
-* LDD_SUFFIX: Macros for Initialization.
- (line 122)
-* le: Comparisons. (line 76)
-* le and attributes: Expressions. (line 64)
-* LE_EXPR: Unary and Binary Expressions.
- (line 6)
-* leaf functions: Leaf Functions. (line 6)
-* leaf_function_p: Standard Names. (line 1040)
-* LEAF_REG_REMAP: Leaf Functions. (line 39)
-* LEAF_REGISTERS: Leaf Functions. (line 25)
-* left rotate: Arithmetic. (line 195)
-* left shift: Arithmetic. (line 173)
-* LEGITIMATE_CONSTANT_P: Addressing Modes. (line 230)
-* LEGITIMATE_PIC_OPERAND_P: PIC. (line 32)
-* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 151)
-* length: GTY Options. (line 50)
-* less than: Comparisons. (line 68)
-* less than or equal: Comparisons. (line 76)
-* leu: Comparisons. (line 76)
-* leu and attributes: Expressions. (line 64)
-* lfloorMN2: Standard Names. (line 619)
-* LIB2FUNCS_EXTRA: Target Fragment. (line 11)
-* LIB_SPEC: Driver. (line 108)
-* LIBCALL_VALUE: Scalar Return. (line 56)
-* libgcc.a: Library Calls. (line 6)
-* LIBGCC2_CFLAGS: Target Fragment. (line 8)
-* LIBGCC2_HAS_DF_MODE: Type Layout. (line 109)
-* LIBGCC2_HAS_TF_MODE: Type Layout. (line 122)
-* LIBGCC2_HAS_XF_MODE: Type Layout. (line 116)
-* LIBGCC2_LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 103)
-* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 960)
-* LIBGCC_SPEC: Driver. (line 116)
-* library subroutine names: Library Calls. (line 6)
-* LIBRARY_PATH_ENV: Misc. (line 520)
-* LIMIT_RELOAD_CLASS: Register Classes. (line 298)
-* Linear loop transformations framework: Lambda. (line 6)
-* LINK_COMMAND_SPEC: Driver. (line 237)
-* LINK_EH_SPEC: Driver. (line 143)
-* LINK_ELIMINATE_DUPLICATE_LDIRECTORIES: Driver. (line 247)
-* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 233)
-* LINK_LIBGCC_SPECIAL_1: Driver. (line 228)
-* LINK_SPEC: Driver. (line 101)
-* list: Containers. (line 6)
-* Liveness representation: Liveness information.
- (line 6)
-* lo_sum: Arithmetic. (line 24)
-* load address instruction: Simple Constraints. (line 164)
-* LOAD_EXTEND_OP: Misc. (line 69)
-* load_multiple instruction pattern: Standard Names. (line 137)
-* LOCAL_ALIGNMENT: Storage Layout. (line 242)
-* LOCAL_CLASS_P: Classes. (line 73)
-* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 272)
-* LOCAL_INCLUDE_DIR: Driver. (line 313)
-* LOCAL_LABEL_PREFIX: Instruction Output. (line 153)
-* LOCAL_REGNO: Register Basics. (line 102)
-* LOG_LINKS: Insns. (line 317)
-* Logical Operators: Logical Operators. (line 6)
-* logical-and, bitwise: Arithmetic. (line 158)
-* logM2 instruction pattern: Standard Names. (line 532)
-* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 93)
-* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 58)
-* LONG_FRACT_TYPE_SIZE: Type Layout. (line 73)
-* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 98)
-* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 78)
-* LONG_LONG_TYPE_SIZE: Type Layout. (line 33)
-* LONG_TYPE_SIZE: Type Layout. (line 22)
-* longjmp and automatic variables: Interface. (line 52)
-* Loop analysis: Loop representation.
- (line 6)
-* Loop manipulation: Loop manipulation. (line 6)
-* Loop querying: Loop querying. (line 6)
-* Loop representation: Loop representation.
- (line 6)
-* Loop-closed SSA form: LCSSA. (line 6)
-* LOOP_ALIGN: Alignment Output. (line 41)
-* LOOP_EXPR: Unary and Binary Expressions.
- (line 6)
-* looping instruction patterns: Looping Patterns. (line 6)
-* lowering, language-dependent intermediate representation: Parsing pass.
- (line 14)
-* lrintMN2: Standard Names. (line 609)
-* lroundMN2: Standard Names. (line 614)
-* LSHIFT_EXPR: Unary and Binary Expressions.
- (line 6)
-* lshiftrt: Arithmetic. (line 190)
-* lshiftrt and attributes: Expressions. (line 64)
-* lshrM3 instruction pattern: Standard Names. (line 468)
-* lt: Comparisons. (line 68)
-* lt and attributes: Expressions. (line 64)
-* LT_EXPR: Unary and Binary Expressions.
- (line 6)
-* LTGT_EXPR: Unary and Binary Expressions.
- (line 6)
-* lto: LTO. (line 6)
-* ltrans: LTO. (line 6)
-* ltu: Comparisons. (line 68)
-* m in constraint: Simple Constraints. (line 17)
-* machine attributes: Target Attributes. (line 6)
-* machine description macros: Target Macros. (line 6)
-* machine descriptions: Machine Desc. (line 6)
-* machine mode conversions: Conversions. (line 6)
-* machine modes: Machine Modes. (line 6)
-* machine specific constraints: Machine Constraints.
- (line 6)
-* machine-independent predicates: Machine-Independent Predicates.
- (line 6)
-* macros, target description: Target Macros. (line 6)
-* maddMN4 instruction pattern: Standard Names. (line 391)
-* MAKE_DECL_ONE_ONLY: Label Output. (line 238)
-* make_phi_node: GIMPLE_PHI. (line 7)
-* make_safe_from: Expander Definitions.
- (line 148)
-* makefile fragment: Fragments. (line 6)
-* makefile targets: Makefile. (line 6)
-* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 167)
-* Manipulating GIMPLE statements: Manipulating GIMPLE statements.
- (line 6)
-* mark_hook: GTY Options. (line 166)
-* marking roots: GGC Roots. (line 6)
-* MASK_RETURN_ADDR: Exception Region Output.
- (line 35)
-* match_dup <1>: RTL Template. (line 73)
-* match_dup: define_peephole2. (line 28)
-* match_dup and attributes: Insn Lengths. (line 16)
-* match_op_dup: RTL Template. (line 163)
-* match_operand: RTL Template. (line 16)
-* match_operand and attributes: Expressions. (line 55)
-* match_operator: RTL Template. (line 95)
-* match_par_dup: RTL Template. (line 219)
-* match_parallel: RTL Template. (line 172)
-* match_scratch <1>: define_peephole2. (line 28)
-* match_scratch: RTL Template. (line 58)
-* matching constraint: Simple Constraints. (line 142)
-* matching operands: Output Template. (line 49)
-* math library: Soft float library routines.
- (line 6)
-* math, in RTL: Arithmetic. (line 6)
-* MATH_LIBRARY: Misc. (line 513)
-* matherr: Library Calls. (line 44)
-* MAX_BITS_PER_WORD: Storage Layout. (line 54)
-* MAX_CONDITIONAL_EXECUTE: Misc. (line 535)
-* MAX_FIXED_MODE_SIZE: Storage Layout. (line 417)
-* MAX_MOVE_MAX: Misc. (line 120)
-* MAX_OFILE_ALIGNMENT: Storage Layout. (line 204)
-* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 43)
-* MAX_STACK_ALIGNMENT: Storage Layout. (line 197)
-* maxM3 instruction pattern: Standard Names. (line 261)
-* may_trap_p, tree_could_trap_p: Edges. (line 115)
-* maybe_undef: GTY Options. (line 174)
-* mcount: Profiling. (line 12)
-* MD_CAN_REDIRECT_BRANCH: Misc. (line 682)
-* MD_EXEC_PREFIX: Driver. (line 268)
-* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 98)
-* MD_HANDLE_UNWABI: Exception Handling. (line 118)
-* MD_STARTFILE_PREFIX: Driver. (line 296)
-* MD_STARTFILE_PREFIX_1: Driver. (line 301)
-* MD_UNWIND_SUPPORT: Exception Handling. (line 94)
-* mem: Regs and Memory. (line 374)
-* mem and /c: Flags. (line 99)
-* mem and /f: Flags. (line 103)
-* mem and /i: Flags. (line 85)
-* mem and /j: Flags. (line 79)
-* mem and /s: Flags. (line 70)
-* mem and /u: Flags. (line 152)
-* mem and /v: Flags. (line 94)
-* mem, RTL sharing: Sharing. (line 40)
-* MEM_ADDR_SPACE: Special Accessors. (line 39)
-* MEM_ALIAS_SET: Special Accessors. (line 9)
-* MEM_ALIGN: Special Accessors. (line 36)
-* MEM_EXPR: Special Accessors. (line 20)
-* MEM_IN_STRUCT_P: Flags. (line 70)
-* MEM_KEEP_ALIAS_SET_P: Flags. (line 79)
-* MEM_NOTRAP_P: Flags. (line 99)
-* MEM_OFFSET: Special Accessors. (line 28)
-* MEM_POINTER: Flags. (line 103)
-* MEM_READONLY_P: Flags. (line 152)
-* MEM_REF: Storage References. (line 6)
-* MEM_SCALAR_P: Flags. (line 85)
-* MEM_SIZE: Special Accessors. (line 31)
-* MEM_VOLATILE_P: Flags. (line 94)
-* MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 397)
-* memory model: Memory model. (line 6)
-* memory reference, nonoffsettable: Simple Constraints. (line 256)
-* memory references in constraints: Simple Constraints. (line 17)
-* memory_barrier instruction pattern: Standard Names. (line 1422)
-* MEMORY_MOVE_COST: Costs. (line 54)
-* memory_operand: Machine-Independent Predicates.
- (line 58)
-* METHOD_TYPE: Types. (line 6)
-* MIN_UNITS_PER_WORD: Storage Layout. (line 64)
-* MINIMUM_ALIGNMENT: Storage Layout. (line 285)
-* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 175)
-* minM3 instruction pattern: Standard Names. (line 261)
-* minus: Arithmetic. (line 36)
-* minus and attributes: Expressions. (line 64)
-* minus, canonicalization of: Insn Canonicalizations.
- (line 27)
-* MINUS_EXPR: Unary and Binary Expressions.
- (line 6)
-* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6)
-* mod: Arithmetic. (line 136)
-* mod and attributes: Expressions. (line 64)
-* mode classes: Machine Modes. (line 219)
-* mode iterators in .md files: Mode Iterators. (line 6)
-* mode switching: Mode Switching. (line 6)
-* MODE_ACCUM: Machine Modes. (line 249)
-* MODE_AFTER: Mode Switching. (line 49)
-* MODE_BASE_REG_CLASS: Register Classes. (line 114)
-* MODE_BASE_REG_REG_CLASS: Register Classes. (line 120)
-* MODE_CC <1>: Machine Modes. (line 268)
-* MODE_CC: MODE_CC Condition Codes.
- (line 6)
-* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 127)
-* MODE_COMPLEX_FLOAT: Machine Modes. (line 260)
-* MODE_COMPLEX_INT: Machine Modes. (line 257)
-* MODE_DECIMAL_FLOAT: Machine Modes. (line 237)
-* MODE_ENTRY: Mode Switching. (line 54)
-* MODE_EXIT: Mode Switching. (line 60)
-* MODE_FLOAT: Machine Modes. (line 233)
-* MODE_FRACT: Machine Modes. (line 241)
-* MODE_FUNCTION: Machine Modes. (line 264)
-* MODE_INT: Machine Modes. (line 225)
-* MODE_NEEDED: Mode Switching. (line 42)
-* MODE_PARTIAL_INT: Machine Modes. (line 229)
-* MODE_PRIORITY_TO_MODE: Mode Switching. (line 66)
-* MODE_RANDOM: Machine Modes. (line 273)
-* MODE_UACCUM: Machine Modes. (line 253)
-* MODE_UFRACT: Machine Modes. (line 245)
-* MODES_TIEABLE_P: Values in Registers.
- (line 129)
-* modifiers in constraints: Modifiers. (line 6)
-* MODIFY_EXPR: Unary and Binary Expressions.
- (line 6)
-* MODIFY_JNI_METHOD_CALL: Misc. (line 760)
-* modM3 instruction pattern: Standard Names. (line 222)
-* modulo scheduling: RTL passes. (line 131)
-* MOVE_BY_PIECES_P: Costs. (line 165)
-* MOVE_MAX: Misc. (line 115)
-* MOVE_MAX_PIECES: Costs. (line 171)
-* MOVE_RATIO: Costs. (line 149)
-* movM instruction pattern: Standard Names. (line 11)
-* movmemM instruction pattern: Standard Names. (line 681)
-* movmisalignM instruction pattern: Standard Names. (line 126)
-* movMODEcc instruction pattern: Standard Names. (line 904)
-* movstr instruction pattern: Standard Names. (line 716)
-* movstrictM instruction pattern: Standard Names. (line 120)
-* msubMN4 instruction pattern: Standard Names. (line 414)
-* mulhisi3 instruction pattern: Standard Names. (line 367)
-* mulM3 instruction pattern: Standard Names. (line 222)
-* mulqihi3 instruction pattern: Standard Names. (line 371)
-* mulsidi3 instruction pattern: Standard Names. (line 371)
-* mult: Arithmetic. (line 92)
-* mult and attributes: Expressions. (line 64)
-* mult, canonicalization of: Insn Canonicalizations.
- (line 27)
-* MULT_EXPR: Unary and Binary Expressions.
- (line 6)
-* MULTILIB_DEFAULTS: Driver. (line 253)
-* MULTILIB_DIRNAMES: Target Fragment. (line 64)
-* MULTILIB_EXCEPTIONS: Target Fragment. (line 84)
-* MULTILIB_EXTRA_OPTS: Target Fragment. (line 96)
-* MULTILIB_MATCHES: Target Fragment. (line 77)
-* MULTILIB_OPTIONS: Target Fragment. (line 44)
-* multiple alternative constraints: Multi-Alternative. (line 6)
-* MULTIPLE_SYMBOL_SPACES: Misc. (line 493)
-* multiplication: Arithmetic. (line 92)
-* multiplication with signed saturation: Arithmetic. (line 92)
-* multiplication with unsigned saturation: Arithmetic. (line 92)
-* n in constraint: Simple Constraints. (line 75)
-* N_REG_CLASSES: Register Classes. (line 78)
-* name: Identifiers. (line 6)
-* named address spaces: Named Address Spaces.
- (line 6)
-* named patterns and conditions: Patterns. (line 47)
-* names, pattern: Standard Names. (line 6)
-* namespace, scope: Namespaces. (line 6)
-* NAMESPACE_DECL <1>: Declarations. (line 6)
-* NAMESPACE_DECL: Namespaces. (line 6)
-* NATIVE_SYSTEM_HEADER_DIR: Target Fragment. (line 103)
-* ne: Comparisons. (line 56)
-* ne and attributes: Expressions. (line 64)
-* NE_EXPR: Unary and Binary Expressions.
- (line 6)
-* nearbyintM2 instruction pattern: Standard Names. (line 591)
-* neg: Arithmetic. (line 81)
-* neg and attributes: Expressions. (line 64)
-* neg, canonicalization of: Insn Canonicalizations.
- (line 27)
-* NEGATE_EXPR: Unary and Binary Expressions.
- (line 6)
-* negation: Arithmetic. (line 81)
-* negation with signed saturation: Arithmetic. (line 81)
-* negation with unsigned saturation: Arithmetic. (line 81)
-* negM2 instruction pattern: Standard Names. (line 476)
-* nested functions, trampolines for: Trampolines. (line 6)
-* nested_ptr: GTY Options. (line 181)
-* next_bb, prev_bb, FOR_EACH_BB: Basic Blocks. (line 10)
-* NEXT_INSN: Insns. (line 30)
-* NEXT_OBJC_RUNTIME: Library Calls. (line 80)
-* nil: RTL Objects. (line 73)
-* NM_FLAGS: Macros for Initialization.
- (line 111)
-* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 39)
-* NO_DBX_FUNCTION_END: DBX Hooks. (line 33)
-* NO_DBX_GCC_MARKER: File Names and DBX. (line 28)
-* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 23)
-* NO_DOLLAR_IN_LABEL: Misc. (line 457)
-* NO_DOT_IN_LABEL: Misc. (line 463)
-* NO_FUNCTION_CSE: Costs. (line 261)
-* NO_IMPLICIT_EXTERN_C: Misc. (line 376)
-* NO_PROFILE_COUNTERS: Profiling. (line 28)
-* NO_REGS: Register Classes. (line 17)
-* NON_LVALUE_EXPR: Unary and Binary Expressions.
- (line 6)
-* nondeterministic finite state automaton: Processor pipeline description.
- (line 301)
-* nonimmediate_operand: Machine-Independent Predicates.
- (line 101)
-* nonlocal goto handler: Edges. (line 171)
-* nonlocal_goto instruction pattern: Standard Names. (line 1262)
-* nonlocal_goto_receiver instruction pattern: Standard Names.
- (line 1279)
-* nonmemory_operand: Machine-Independent Predicates.
- (line 97)
-* nonoffsettable memory reference: Simple Constraints. (line 256)
-* nop instruction pattern: Standard Names. (line 1073)
-* NOP_EXPR: Unary and Binary Expressions.
- (line 6)
-* normal predicates: Predicates. (line 31)
-* not: Arithmetic. (line 154)
-* not and attributes: Expressions. (line 50)
-* not equal: Comparisons. (line 56)
-* not, canonicalization of: Insn Canonicalizations.
- (line 27)
-* note: Insns. (line 168)
-* note and /i: Flags. (line 59)
-* note and /v: Flags. (line 44)
-* NOTE_INSN_BASIC_BLOCK, CODE_LABEL, notes: Basic Blocks. (line 41)
-* NOTE_INSN_BLOCK_BEG: Insns. (line 193)
-* NOTE_INSN_BLOCK_END: Insns. (line 193)
-* NOTE_INSN_DELETED: Insns. (line 183)
-* NOTE_INSN_DELETED_LABEL: Insns. (line 188)
-* NOTE_INSN_EH_REGION_BEG: Insns. (line 199)
-* NOTE_INSN_EH_REGION_END: Insns. (line 199)
-* NOTE_INSN_FUNCTION_BEG: Insns. (line 223)
-* NOTE_INSN_LOOP_BEG: Insns. (line 207)
-* NOTE_INSN_LOOP_CONT: Insns. (line 213)
-* NOTE_INSN_LOOP_END: Insns. (line 207)
-* NOTE_INSN_LOOP_VTOP: Insns. (line 217)
-* NOTE_INSN_VAR_LOCATION: Insns. (line 227)
-* NOTE_LINE_NUMBER: Insns. (line 168)
-* NOTE_SOURCE_FILE: Insns. (line 168)
-* NOTE_VAR_LOCATION: Insns. (line 227)
-* NOTICE_UPDATE_CC: CC0 Condition Codes.
- (line 31)
-* NUM_MACHINE_MODES: Machine Modes. (line 286)
-* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30)
-* Number of iterations analysis: Number of iterations.
- (line 6)
-* o in constraint: Simple Constraints. (line 23)
-* OBJC_GEN_METHOD_LABEL: Label Output. (line 440)
-* OBJC_JBLEN: Misc. (line 955)
-* OBJECT_FORMAT_COFF: Macros for Initialization.
- (line 97)
-* OFFSET_TYPE: Types. (line 6)
-* offsettable address: Simple Constraints. (line 23)
-* OImode: Machine Modes. (line 51)
-* Omega a solver for linear programming problems: Omega. (line 6)
-* OMP_ATOMIC: OpenMP. (line 6)
-* OMP_CLAUSE: OpenMP. (line 6)
-* OMP_CONTINUE: OpenMP. (line 6)
-* OMP_CRITICAL: OpenMP. (line 6)
-* OMP_FOR: OpenMP. (line 6)
-* OMP_MASTER: OpenMP. (line 6)
-* OMP_ORDERED: OpenMP. (line 6)
-* OMP_PARALLEL: OpenMP. (line 6)
-* OMP_RETURN: OpenMP. (line 6)
-* OMP_SECTION: OpenMP. (line 6)
-* OMP_SECTIONS: OpenMP. (line 6)
-* OMP_SINGLE: OpenMP. (line 6)
-* one_cmplM2 instruction pattern: Standard Names. (line 678)
-* operand access: Accessors. (line 6)
-* Operand Access Routines: SSA Operands. (line 119)
-* operand constraints: Constraints. (line 6)
-* Operand Iterators: SSA Operands. (line 119)
-* operand predicates: Predicates. (line 6)
-* operand substitution: Output Template. (line 6)
-* Operands: Operands. (line 6)
-* operands <1>: SSA Operands. (line 6)
-* operands: Patterns. (line 53)
-* operator predicates: Predicates. (line 6)
-* optc-gen.awk: Options. (line 6)
-* Optimization infrastructure for GIMPLE: Tree SSA. (line 6)
-* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9)
-* option specification files: Options. (line 6)
-* OPTION_DEFAULT_SPECS: Driver. (line 26)
-* optional hardware or system features: Run-time Target. (line 59)
-* options, directory search: Including Patterns. (line 44)
-* order of register allocation: Allocation Order. (line 6)
-* ordered_comparison_operator: Machine-Independent Predicates.
- (line 116)
-* ORDERED_EXPR: Unary and Binary Expressions.
- (line 6)
-* Ordering of Patterns: Pattern Ordering. (line 6)
-* ORIGINAL_REGNO: Special Accessors. (line 44)
-* other register constraints: Simple Constraints. (line 173)
-* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 74)
-* OUTGOING_REGNO: Register Basics. (line 95)
-* output of assembler code: File Framework. (line 6)
-* output statements: Output Statement. (line 6)
-* output templates: Output Template. (line 6)
-* OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 51)
-* output_asm_insn: Output Statement. (line 53)
-* OUTPUT_QUOTED_STRING: File Framework. (line 102)
-* OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 21)
-* OVERLOAD: Functions for C++. (line 6)
-* OVERRIDE_ABI_FORMAT: Register Arguments. (line 140)
-* OVL_CURRENT: Functions for C++. (line 6)
-* OVL_NEXT: Functions for C++. (line 6)
-* p in constraint: Simple Constraints. (line 164)
-* PAD_VARARGS_DOWN: Register Arguments. (line 220)
-* parallel: Side Effects. (line 204)
-* param_is: GTY Options. (line 109)
-* parameters, c++ abi: C++ ABI. (line 6)
-* parameters, miscellaneous: Misc. (line 6)
-* parameters, precompiled headers: PCH Target. (line 6)
-* paramN_is: GTY Options. (line 127)
-* parity: Arithmetic. (line 237)
-* parityM2 instruction pattern: Standard Names. (line 672)
-* PARM_BOUNDARY: Storage Layout. (line 132)
-* PARM_DECL: Declarations. (line 6)
-* PARSE_LDD_OUTPUT: Macros for Initialization.
- (line 127)
-* passes and files of the compiler: Passes. (line 6)
-* passing arguments: Interface. (line 36)
-* PATH_SEPARATOR: Filesystem. (line 31)
-* PATTERN: Insns. (line 288)
-* pattern conditions: Patterns. (line 43)
-* pattern names: Standard Names. (line 6)
-* Pattern Ordering: Pattern Ordering. (line 6)
-* patterns: Patterns. (line 6)
-* pc: Regs and Memory. (line 361)
-* pc and attributes: Insn Lengths. (line 20)
-* pc, RTL sharing: Sharing. (line 25)
-* PC_REGNUM: Register Basics. (line 109)
-* pc_rtx: Regs and Memory. (line 366)
-* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 311)
-* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 65)
-* PDImode: Machine Modes. (line 40)
-* peephole optimization, RTL representation: Side Effects. (line 238)
-* peephole optimizer definitions: Peephole Definitions.
- (line 6)
-* per-function data: Per-Function Data. (line 6)
-* percent sign: Output Template. (line 6)
-* PHI nodes: SSA. (line 31)
-* PHI_ARG_DEF: SSA. (line 71)
-* PHI_ARG_EDGE: SSA. (line 68)
-* PHI_ARG_ELT: SSA. (line 63)
-* PHI_NUM_ARGS: SSA. (line 59)
-* PHI_RESULT: SSA. (line 56)
-* PIC: PIC. (line 6)
-* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26)
-* PIC_OFFSET_TABLE_REGNUM: PIC. (line 16)
-* pipeline hazard recognizer: Processor pipeline description.
- (line 6)
-* Plugins: Plugins. (line 6)
-* plus: Arithmetic. (line 14)
-* plus and attributes: Expressions. (line 64)
-* plus, canonicalization of: Insn Canonicalizations.
- (line 27)
-* PLUS_EXPR: Unary and Binary Expressions.
- (line 6)
-* Pmode: Misc. (line 344)
-* pmode_register_operand: Machine-Independent Predicates.
- (line 35)
-* pointer: Types. (line 6)
-* POINTER_PLUS_EXPR: Unary and Binary Expressions.
- (line 6)
-* POINTER_SIZE: Storage Layout. (line 70)
-* POINTER_TYPE: Types. (line 6)
-* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 76)
-* pop_operand: Machine-Independent Predicates.
- (line 88)
-* popcount: Arithmetic. (line 233)
-* popcountM2 instruction pattern: Standard Names. (line 666)
-* portability: Portability. (line 6)
-* position independent code: PIC. (line 6)
-* post_dec: Incdec. (line 25)
-* post_inc: Incdec. (line 30)
-* post_modify: Incdec. (line 33)
-* POSTDECREMENT_EXPR: Unary and Binary Expressions.
- (line 6)
-* POSTINCREMENT_EXPR: Unary and Binary Expressions.
- (line 6)
-* POWI_MAX_MULTS: Misc. (line 823)
-* powM3 instruction pattern: Standard Names. (line 540)
-* pragma: Misc. (line 381)
-* pre_dec: Incdec. (line 8)
-* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 127)
-* pre_inc: Incdec. (line 22)
-* pre_modify: Incdec. (line 51)
-* PREDECREMENT_EXPR: Unary and Binary Expressions.
- (line 6)
-* predefined macros: Run-time Target. (line 6)
-* predicates: Predicates. (line 6)
-* predicates and machine modes: Predicates. (line 31)
-* predication <1>: Cond Exec Macros. (line 6)
-* predication: Conditional Execution.
- (line 6)
-* predict.def: Profile information.
- (line 24)
-* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 42)
-* PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 278)
-* PREFERRED_RELOAD_CLASS: Register Classes. (line 243)
-* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 146)
-* prefetch: Side Effects. (line 312)
-* prefetch and /v: Flags. (line 232)
-* prefetch instruction pattern: Standard Names. (line 1401)
-* PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 232)
-* PREINCREMENT_EXPR: Unary and Binary Expressions.
- (line 6)
-* presence_set: Processor pipeline description.
- (line 220)
-* preserving SSA form: SSA. (line 76)
-* preserving virtual SSA form: SSA. (line 186)
-* prev_active_insn: define_peephole. (line 60)
-* PREV_INSN: Insns. (line 26)
-* PRINT_OPERAND: Instruction Output. (line 96)
-* PRINT_OPERAND_ADDRESS: Instruction Output. (line 124)
-* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 117)
-* probe_stack instruction pattern: Standard Names. (line 1254)
-* processor functional units: Processor pipeline description.
- (line 6)
-* processor pipeline description: Processor pipeline description.
- (line 6)
-* product: Arithmetic. (line 92)
-* profile feedback: Profile information.
- (line 14)
-* profile representation: Profile information.
- (line 6)
-* PROFILE_BEFORE_PROLOGUE: Profiling. (line 35)
-* PROFILE_HOOK: Profiling. (line 23)
-* profiling, code generation: Profiling. (line 6)
-* program counter: Regs and Memory. (line 362)
-* prologue: Function Entry. (line 6)
-* prologue instruction pattern: Standard Names. (line 1345)
-* PROMOTE_MODE: Storage Layout. (line 87)
-* pseudo registers: Regs and Memory. (line 9)
-* PSImode: Machine Modes. (line 32)
-* PTRDIFF_TYPE: Type Layout. (line 183)
-* purge_dead_edges <1>: Edges. (line 104)
-* purge_dead_edges: Maintaining the CFG.
- (line 93)
-* push address instruction: Simple Constraints. (line 164)
-* PUSH_ARGS: Stack Arguments. (line 18)
-* PUSH_ARGS_REVERSED: Stack Arguments. (line 26)
-* push_operand: Machine-Independent Predicates.
- (line 81)
-* push_reload: Addressing Modes. (line 175)
-* PUSH_ROUNDING: Stack Arguments. (line 32)
-* pushM1 instruction pattern: Standard Names. (line 209)
-* PUT_CODE: RTL Objects. (line 47)
-* PUT_MODE: Machine Modes. (line 283)
-* PUT_REG_NOTE_KIND: Insns. (line 350)
-* PUT_SDB_: SDB and DWARF. (line 101)
-* QCmode: Machine Modes. (line 197)
-* QFmode: Machine Modes. (line 54)
-* QImode: Machine Modes. (line 25)
-* QImode, in insn: Insns. (line 272)
-* QQmode: Machine Modes. (line 103)
-* qualified type <1>: Types for C++. (line 6)
-* qualified type: Types. (line 6)
-* querying function unit reservations: Processor pipeline description.
- (line 90)
-* question mark: Multi-Alternative. (line 41)
-* quotient: Arithmetic. (line 116)
-* r in constraint: Simple Constraints. (line 66)
-* RANGE_TEST_NON_SHORT_CIRCUIT: Costs. (line 265)
-* RDIV_EXPR: Unary and Binary Expressions.
- (line 6)
-* READONLY_DATA_SECTION_ASM_OP: Sections. (line 63)
-* real operands: SSA Operands. (line 6)
-* REAL_ARITHMETIC: Floating Point. (line 66)
-* REAL_CST: Constant expressions.
- (line 6)
-* REAL_LIBGCC_SPEC: Driver. (line 125)
-* REAL_NM_FILE_NAME: Macros for Initialization.
- (line 106)
-* REAL_TYPE: Types. (line 6)
-* REAL_VALUE_ABS: Floating Point. (line 82)
-* REAL_VALUE_ATOF: Floating Point. (line 50)
-* REAL_VALUE_FIX: Floating Point. (line 41)
-* REAL_VALUE_FROM_INT: Floating Point. (line 99)
-* REAL_VALUE_ISINF: Floating Point. (line 59)
-* REAL_VALUE_ISNAN: Floating Point. (line 62)
-* REAL_VALUE_NEGATE: Floating Point. (line 79)
-* REAL_VALUE_NEGATIVE: Floating Point. (line 56)
-* REAL_VALUE_TO_INT: Floating Point. (line 93)
-* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 156)
-* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 154)
-* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 155)
-* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 152)
-* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 153)
-* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 151)
-* REAL_VALUE_TRUNCATE: Floating Point. (line 86)
-* REAL_VALUE_TYPE: Floating Point. (line 26)
-* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 45)
-* REAL_VALUES_EQUAL: Floating Point. (line 32)
-* REAL_VALUES_LESS: Floating Point. (line 38)
-* REALPART_EXPR: Unary and Binary Expressions.
- (line 6)
-* recog_data.operand: Instruction Output. (line 54)
-* recognizing insns: RTL Template. (line 6)
-* RECORD_TYPE <1>: Types. (line 6)
-* RECORD_TYPE: Classes. (line 6)
-* redirect_edge_and_branch: Profile information.
- (line 71)
-* redirect_edge_and_branch, redirect_jump: Maintaining the CFG.
- (line 103)
-* reduc_smax_M instruction pattern: Standard Names. (line 267)
-* reduc_smin_M instruction pattern: Standard Names. (line 267)
-* reduc_splus_M instruction pattern: Standard Names. (line 279)
-* reduc_umax_M instruction pattern: Standard Names. (line 273)
-* reduc_umin_M instruction pattern: Standard Names. (line 273)
-* reduc_uplus_M instruction pattern: Standard Names. (line 285)
-* reference: Types. (line 6)
-* REFERENCE_TYPE: Types. (line 6)
-* reg: Regs and Memory. (line 9)
-* reg and /f: Flags. (line 112)
-* reg and /i: Flags. (line 107)
-* reg and /v: Flags. (line 116)
-* reg, RTL sharing: Sharing. (line 17)
-* REG_ALLOC_ORDER: Allocation Order. (line 9)
-* REG_BR_PRED: Insns. (line 531)
-* REG_BR_PROB: Insns. (line 525)
-* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information.
- (line 82)
-* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information.
- (line 52)
-* REG_CC_SETTER: Insns. (line 496)
-* REG_CC_USER: Insns. (line 496)
-* reg_class_contents: Register Basics. (line 59)
-* REG_CLASS_CONTENTS: Register Classes. (line 88)
-* REG_CLASS_FROM_CONSTRAINT: Old Constraints. (line 35)
-* REG_CLASS_FROM_LETTER: Old Constraints. (line 27)
-* REG_CLASS_NAMES: Register Classes. (line 83)
-* REG_CROSSING_JUMP: Insns. (line 409)
-* REG_DEAD: Insns. (line 361)
-* REG_DEAD, REG_UNUSED: Liveness information.
- (line 32)
-* REG_DEP_ANTI: Insns. (line 518)
-* REG_DEP_OUTPUT: Insns. (line 514)
-* REG_DEP_TRUE: Insns. (line 511)
-* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 110)
-* REG_EQUAL: Insns. (line 424)
-* REG_EQUIV: Insns. (line 424)
-* REG_EXPR: Special Accessors. (line 50)
-* REG_FRAME_RELATED_EXPR: Insns. (line 537)
-* REG_FUNCTION_VALUE_P: Flags. (line 107)
-* REG_INC: Insns. (line 377)
-* reg_label and /v: Flags. (line 65)
-* REG_LABEL_OPERAND: Insns. (line 391)
-* REG_LABEL_TARGET: Insns. (line 400)
-* reg_names <1>: Instruction Output. (line 108)
-* reg_names: Register Basics. (line 59)
-* REG_NONNEG: Insns. (line 383)
-* REG_NOTE_KIND: Insns. (line 350)
-* REG_NOTES: Insns. (line 324)
-* REG_OFFSET: Special Accessors. (line 54)
-* REG_OK_STRICT: Addressing Modes. (line 100)
-* REG_PARM_STACK_SPACE: Stack Arguments. (line 59)
-* REG_PARM_STACK_SPACE, and FUNCTION_ARG: Register Arguments.
- (line 52)
-* REG_POINTER: Flags. (line 112)
-* REG_SETJMP: Insns. (line 418)
-* REG_UNUSED: Insns. (line 370)
-* REG_USERVAR_P: Flags. (line 116)
-* regclass_for_constraint: C Constraint Interface.
- (line 60)
-* register allocation order: Allocation Order. (line 6)
-* register class definitions: Register Classes. (line 6)
-* register class preference constraints: Class Preferences. (line 6)
-* register pairs: Values in Registers.
- (line 69)
-* Register Transfer Language (RTL): RTL. (line 6)
-* register usage: Registers. (line 6)
-* REGISTER_MOVE_COST: Costs. (line 10)
-* REGISTER_NAMES: Instruction Output. (line 9)
-* register_operand: Machine-Independent Predicates.
- (line 30)
-* REGISTER_PREFIX: Instruction Output. (line 152)
-* REGISTER_TARGET_PRAGMAS: Misc. (line 382)
-* registers arguments: Register Arguments. (line 6)
-* registers in constraints: Simple Constraints. (line 66)
-* REGMODE_NATURAL_SIZE: Values in Registers.
- (line 50)
-* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 169)
-* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 146)
-* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 156)
-* REGNO_OK_FOR_BASE_P: Register Classes. (line 142)
-* REGNO_OK_FOR_INDEX_P: Register Classes. (line 180)
-* REGNO_REG_CLASS: Register Classes. (line 103)
-* regs_ever_live: Function Entry. (line 21)
-* regular expressions: Processor pipeline description.
- (line 106)
-* relative costs: Costs. (line 6)
-* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 263)
-* reload_completed: Standard Names. (line 1040)
-* reload_in instruction pattern: Standard Names. (line 99)
-* reload_in_progress: Standard Names. (line 57)
-* reload_out instruction pattern: Standard Names. (line 99)
-* reloading: RTL passes. (line 182)
-* remainder: Arithmetic. (line 136)
-* remainderM3 instruction pattern: Standard Names. (line 499)
-* reorder: GTY Options. (line 205)
-* representation of RTL: RTL. (line 6)
-* reservation delays: Processor pipeline description.
- (line 6)
-* rest_of_decl_compilation: Parsing pass. (line 52)
-* rest_of_type_compilation: Parsing pass. (line 52)
-* restore_stack_block instruction pattern: Standard Names. (line 1174)
-* restore_stack_function instruction pattern: Standard Names.
- (line 1174)
-* restore_stack_nonlocal instruction pattern: Standard Names.
- (line 1174)
-* RESULT_DECL: Declarations. (line 6)
-* return: Side Effects. (line 72)
-* return instruction pattern: Standard Names. (line 1027)
-* return values in registers: Scalar Return. (line 6)
-* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 135)
-* RETURN_ADDR_OFFSET: Exception Handling. (line 60)
-* RETURN_ADDR_RTX: Frame Layout. (line 124)
-* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 65)
-* RETURN_EXPR: Statements for C++. (line 6)
-* RETURN_STMT: Statements for C++. (line 6)
-* return_val: Flags. (line 299)
-* return_val, in call_insn: Flags. (line 24)
-* return_val, in mem: Flags. (line 85)
-* return_val, in reg: Flags. (line 107)
-* return_val, in symbol_ref: Flags. (line 220)
-* returning aggregate values: Aggregate Return. (line 6)
-* returning structures and unions: Interface. (line 10)
-* reverse probability: Profile information.
- (line 66)
-* REVERSE_CONDEXEC_PREDICATES_P: Cond Exec Macros. (line 11)
-* REVERSE_CONDITION: MODE_CC Condition Codes.
- (line 87)
-* REVERSIBLE_CC_MODE: MODE_CC Condition Codes.
- (line 73)
-* right rotate: Arithmetic. (line 195)
-* right shift: Arithmetic. (line 190)
-* rintM2 instruction pattern: Standard Names. (line 599)
-* RISC: Processor pipeline description.
- (line 220)
-* roots, marking: GGC Roots. (line 6)
-* rotate: Arithmetic. (line 195)
-* rotatert: Arithmetic. (line 195)
-* rotlM3 instruction pattern: Standard Names. (line 468)
-* rotrM3 instruction pattern: Standard Names. (line 468)
-* ROUND_DIV_EXPR: Unary and Binary Expressions.
- (line 6)
-* ROUND_MOD_EXPR: Unary and Binary Expressions.
- (line 6)
-* ROUND_TOWARDS_ZERO: Storage Layout. (line 461)
-* ROUND_TYPE_ALIGN: Storage Layout. (line 408)
-* roundM2 instruction pattern: Standard Names. (line 575)
-* RSHIFT_EXPR: Unary and Binary Expressions.
- (line 6)
-* RTL addition: Arithmetic. (line 14)
-* RTL addition with signed saturation: Arithmetic. (line 14)
-* RTL addition with unsigned saturation: Arithmetic. (line 14)
-* RTL classes: RTL Classes. (line 6)
-* RTL comparison: Arithmetic. (line 43)
-* RTL comparison operations: Comparisons. (line 6)
-* RTL constant expression types: Constants. (line 6)
-* RTL constants: Constants. (line 6)
-* RTL declarations: RTL Declarations. (line 6)
-* RTL difference: Arithmetic. (line 36)
-* RTL expression: RTL Objects. (line 6)
-* RTL expressions for arithmetic: Arithmetic. (line 6)
-* RTL format: RTL Classes. (line 72)
-* RTL format characters: RTL Classes. (line 77)
-* RTL function-call insns: Calls. (line 6)
-* RTL insn template: RTL Template. (line 6)
-* RTL integers: RTL Objects. (line 6)
-* RTL memory expressions: Regs and Memory. (line 6)
-* RTL object types: RTL Objects. (line 6)
-* RTL postdecrement: Incdec. (line 6)
-* RTL postincrement: Incdec. (line 6)
-* RTL predecrement: Incdec. (line 6)
-* RTL preincrement: Incdec. (line 6)
-* RTL register expressions: Regs and Memory. (line 6)
-* RTL representation: RTL. (line 6)
-* RTL side effect expressions: Side Effects. (line 6)
-* RTL strings: RTL Objects. (line 6)
-* RTL structure sharing assumptions: Sharing. (line 6)
-* RTL subtraction: Arithmetic. (line 36)
-* RTL subtraction with signed saturation: Arithmetic. (line 36)
-* RTL subtraction with unsigned saturation: Arithmetic. (line 36)
-* RTL sum: Arithmetic. (line 14)
-* RTL vectors: RTL Objects. (line 6)
-* RTL_CONST_CALL_P: Flags. (line 19)
-* RTL_CONST_OR_PURE_CALL_P: Flags. (line 29)
-* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 33)
-* RTL_PURE_CALL_P: Flags. (line 24)
-* RTX (See RTL): RTL Objects. (line 6)
-* RTX codes, classes of: RTL Classes. (line 6)
-* RTX_FRAME_RELATED_P: Flags. (line 125)
-* run-time conventions: Interface. (line 6)
-* run-time target specification: Run-time Target. (line 6)
-* s in constraint: Simple Constraints. (line 102)
-* same_type_p: Types. (line 88)
-* SAmode: Machine Modes. (line 148)
-* sat_fract: Conversions. (line 90)
-* satfractMN2 instruction pattern: Standard Names. (line 856)
-* satfractunsMN2 instruction pattern: Standard Names. (line 869)
-* satisfies_constraint_: C Constraint Interface.
- (line 47)
-* SAVE_EXPR: Unary and Binary Expressions.
- (line 6)
-* save_stack_block instruction pattern: Standard Names. (line 1174)
-* save_stack_function instruction pattern: Standard Names. (line 1174)
-* save_stack_nonlocal instruction pattern: Standard Names. (line 1174)
-* SBSS_SECTION_ASM_OP: Sections. (line 77)
-* Scalar evolutions: Scalar evolutions. (line 6)
-* scalars, returned as values: Scalar Return. (line 6)
-* SCHED_GROUP_P: Flags. (line 166)
-* SCmode: Machine Modes. (line 197)
-* scratch: Regs and Memory. (line 298)
-* scratch operands: Regs and Memory. (line 298)
-* scratch, RTL sharing: Sharing. (line 35)
-* scratch_operand: Machine-Independent Predicates.
- (line 50)
-* SDATA_SECTION_ASM_OP: Sections. (line 58)
-* SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 119)
-* SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 114)
-* SDB_DEBUGGING_INFO: SDB and DWARF. (line 9)
-* SDB_DELIM: SDB and DWARF. (line 107)
-* SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 124)
-* SDmode: Machine Modes. (line 85)
-* sdot_prodM instruction pattern: Standard Names. (line 291)
-* search options: Including Patterns. (line 44)
-* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 394)
-* SECONDARY_MEMORY_NEEDED: Register Classes. (line 450)
-* SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 469)
-* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 460)
-* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 395)
-* SECONDARY_RELOAD_CLASS: Register Classes. (line 393)
-* SELECT_CC_MODE: MODE_CC Condition Codes.
- (line 7)
-* sequence: Side Effects. (line 254)
-* Sequence iterators: Sequence iterators. (line 6)
-* set: Side Effects. (line 15)
-* set and /f: Flags. (line 125)
-* SET_ASM_OP: Label Output. (line 418)
-* set_attr: Tagging Insns. (line 31)
-* set_attr_alternative: Tagging Insns. (line 49)
-* set_bb_seq: GIMPLE sequences. (line 76)
-* SET_BY_PIECES_P: Costs. (line 206)
-* SET_DEST: Side Effects. (line 69)
-* SET_IS_RETURN_P: Flags. (line 175)
-* SET_LABEL_KIND: Insns. (line 140)
-* set_optab_libfunc: Library Calls. (line 15)
-* SET_RATIO: Costs. (line 194)
-* SET_SRC: Side Effects. (line 69)
-* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 83)
-* setmemM instruction pattern: Standard Names. (line 724)
-* SETUP_FRAME_ADDRESSES: Frame Layout. (line 102)
-* SF_SIZE: Type Layout. (line 128)
-* SFmode: Machine Modes. (line 66)
-* sharing of RTL components: Sharing. (line 6)
-* shift: Arithmetic. (line 173)
-* SHIFT_COUNT_TRUNCATED: Misc. (line 127)
-* SHLIB_SUFFIX: Macros for Initialization.
- (line 135)
-* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 83)
-* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 63)
-* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 96)
-* SHORT_TYPE_SIZE: Type Layout. (line 16)
-* sibcall_epilogue instruction pattern: Standard Names. (line 1371)
-* sibling call: Edges. (line 122)
-* SIBLING_CALL_P: Flags. (line 179)
-* SIG_ATOMIC_TYPE: Type Layout. (line 234)
-* sign_extend: Conversions. (line 23)
-* sign_extract: Bit-Fields. (line 8)
-* sign_extract, canonicalization of: Insn Canonicalizations.
- (line 88)
-* signed division: Arithmetic. (line 116)
-* signed division with signed saturation: Arithmetic. (line 116)
-* signed maximum: Arithmetic. (line 141)
-* signed minimum: Arithmetic. (line 141)
-* SImode: Machine Modes. (line 37)
-* simple constraints: Simple Constraints. (line 6)
-* sincos math function, implicit usage: Library Calls. (line 70)
-* sinM2 instruction pattern: Standard Names. (line 516)
-* SIZE_ASM_OP: Label Output. (line 35)
-* SIZE_TYPE: Type Layout. (line 167)
-* skip: GTY Options. (line 72)
-* SLOW_BYTE_ACCESS: Costs. (line 118)
-* SLOW_UNALIGNED_ACCESS: Costs. (line 133)
-* smax: Arithmetic. (line 141)
-* smin: Arithmetic. (line 141)
-* sms, swing, software pipelining: RTL passes. (line 131)
-* smulM3_highpart instruction pattern: Standard Names. (line 383)
-* soft float library: Soft float library routines.
- (line 6)
-* special: GTY Options. (line 249)
-* special predicates: Predicates. (line 31)
-* SPECS: Target Fragment. (line 108)
-* speed of instructions: Costs. (line 6)
-* split_block: Maintaining the CFG.
- (line 110)
-* splitting instructions: Insn Splitting. (line 6)
-* SQmode: Machine Modes. (line 111)
-* sqrt: Arithmetic. (line 207)
-* sqrtM2 instruction pattern: Standard Names. (line 482)
-* square root: Arithmetic. (line 207)
-* ss_abs: Arithmetic. (line 200)
-* ss_ashift: Arithmetic. (line 173)
-* ss_div: Arithmetic. (line 116)
-* ss_minus: Arithmetic. (line 36)
-* ss_mult: Arithmetic. (line 92)
-* ss_neg: Arithmetic. (line 81)
-* ss_plus: Arithmetic. (line 14)
-* ss_truncate: Conversions. (line 43)
-* SSA: SSA. (line 6)
-* SSA_NAME_DEF_STMT: SSA. (line 221)
-* SSA_NAME_VERSION: SSA. (line 226)
-* ssaddM3 instruction pattern: Standard Names. (line 222)
-* ssashlM3 instruction pattern: Standard Names. (line 458)
-* ssdivM3 instruction pattern: Standard Names. (line 222)
-* ssmaddMN4 instruction pattern: Standard Names. (line 406)
-* ssmsubMN4 instruction pattern: Standard Names. (line 430)
-* ssmulM3 instruction pattern: Standard Names. (line 222)
-* ssnegM2 instruction pattern: Standard Names. (line 476)
-* sssubM3 instruction pattern: Standard Names. (line 222)
-* ssum_widenM3 instruction pattern: Standard Names. (line 301)
-* stack arguments: Stack Arguments. (line 6)
-* stack frame layout: Frame Layout. (line 6)
-* stack smashing protection: Stack Smashing Protection.
- (line 6)
-* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 48)
-* STACK_BOUNDARY: Storage Layout. (line 138)
-* STACK_CHECK_BUILTIN: Stack Checking. (line 32)
-* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83)
-* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74)
-* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90)
-* STACK_CHECK_MOVING_SP: Stack Checking. (line 54)
-* STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 46)
-* STACK_CHECK_PROTECT: Stack Checking. (line 63)
-* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 39)
-* STACK_DYNAMIC_OFFSET: Frame Layout. (line 75)
-* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory.
- (line 83)
-* STACK_GROWS_DOWNWARD: Frame Layout. (line 9)
-* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 84)
-* STACK_POINTER_OFFSET: Frame Layout. (line 58)
-* STACK_POINTER_OFFSET and virtual registers: Regs and Memory.
- (line 93)
-* STACK_POINTER_REGNUM: Frame Registers. (line 9)
-* STACK_POINTER_REGNUM and virtual registers: Regs and Memory.
- (line 83)
-* stack_pointer_rtx: Frame Registers. (line 104)
-* stack_protect_set instruction pattern: Standard Names. (line 1542)
-* stack_protect_test instruction pattern: Standard Names. (line 1552)
-* STACK_PUSH_CODE: Frame Layout. (line 17)
-* STACK_REG_COVER_CLASS: Stack Registers. (line 23)
-* STACK_REGS: Stack Registers. (line 20)
-* STACK_SAVEAREA_MODE: Storage Layout. (line 424)
-* STACK_SIZE_MODE: Storage Layout. (line 436)
-* STACK_SLOT_ALIGNMENT: Storage Layout. (line 256)
-* standard pattern names: Standard Names. (line 6)
-* STANDARD_INCLUDE_COMPONENT: Driver. (line 339)
-* STANDARD_INCLUDE_DIR: Driver. (line 331)
-* STANDARD_STARTFILE_PREFIX: Driver. (line 275)
-* STANDARD_STARTFILE_PREFIX_1: Driver. (line 282)
-* STANDARD_STARTFILE_PREFIX_2: Driver. (line 289)
-* STARTFILE_SPEC: Driver. (line 148)
-* STARTING_FRAME_OFFSET: Frame Layout. (line 39)
-* STARTING_FRAME_OFFSET and virtual registers: Regs and Memory.
- (line 74)
-* Statement and operand traversals: Statement and operand traversals.
- (line 6)
-* Statement Sequences: Statement Sequences.
- (line 6)
-* statements <1>: Statements for C++. (line 6)
-* statements: Function Properties.
- (line 6)
-* Statements: Statements. (line 6)
-* Static profile estimation: Profile information.
- (line 24)
-* static single assignment: SSA. (line 6)
-* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 78)
-* STATIC_CHAIN_REGNUM: Frame Registers. (line 77)
-* stdarg.h and register arguments: Register Arguments. (line 47)
-* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 365)
-* STMT_EXPR: Unary and Binary Expressions.
- (line 6)
-* STMT_IS_FULL_EXPR_P: Statements for C++. (line 22)
-* storage layout: Storage Layout. (line 6)
-* STORE_BY_PIECES_P: Costs. (line 213)
-* STORE_FLAG_VALUE: Misc. (line 216)
-* store_multiple instruction pattern: Standard Names. (line 160)
-* strcpy: Storage Layout. (line 223)
-* STRICT_ALIGNMENT: Storage Layout. (line 306)
-* strict_low_part: RTL Declarations. (line 9)
-* strict_memory_address_p: Addressing Modes. (line 185)
-* STRING_CST: Constant expressions.
- (line 6)
-* STRING_POOL_ADDRESS_P: Flags. (line 183)
-* strlenM instruction pattern: Standard Names. (line 791)
-* structure value address: Aggregate Return. (line 6)
-* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 298)
-* structures, returning: Interface. (line 10)
-* subM3 instruction pattern: Standard Names. (line 222)
-* SUBOBJECT: Statements for C++. (line 6)
-* SUBOBJECT_CLEANUP: Statements for C++. (line 6)
-* subreg: Regs and Memory. (line 97)
-* subreg and /s: Flags. (line 205)
-* subreg and /u: Flags. (line 198)
-* subreg and /u and /v: Flags. (line 188)
-* subreg, in strict_low_part: RTL Declarations. (line 9)
-* SUBREG_BYTE: Regs and Memory. (line 289)
-* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 188)
-* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 198)
-* SUBREG_PROMOTED_VAR_P: Flags. (line 205)
-* SUBREG_REG: Regs and Memory. (line 289)
-* SUCCESS_EXIT_CODE: Host Misc. (line 12)
-* SUPPORTS_INIT_PRIORITY: Macros for Initialization.
- (line 58)
-* SUPPORTS_ONE_ONLY: Label Output. (line 247)
-* SUPPORTS_WEAK: Label Output. (line 221)
-* SWITCH_BODY: Statements for C++. (line 6)
-* SWITCH_COND: Statements for C++. (line 6)
-* SWITCH_STMT: Statements for C++. (line 6)
-* SWITCHABLE_TARGET: Run-time Target. (line 176)
-* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 110)
-* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 92)
-* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 85)
-* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 106)
-* SYMBOL_FLAG_LOCAL: Special Accessors. (line 88)
-* SYMBOL_FLAG_SMALL: Special Accessors. (line 97)
-* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 101)
-* symbol_ref: Constants. (line 76)
-* symbol_ref and /f: Flags. (line 183)
-* symbol_ref and /i: Flags. (line 220)
-* symbol_ref and /u: Flags. (line 10)
-* symbol_ref and /v: Flags. (line 224)
-* symbol_ref, RTL sharing: Sharing. (line 20)
-* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 110)
-* SYMBOL_REF_BLOCK: Special Accessors. (line 123)
-* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 128)
-* SYMBOL_REF_CONSTANT: Special Accessors. (line 71)
-* SYMBOL_REF_DATA: Special Accessors. (line 75)
-* SYMBOL_REF_DECL: Special Accessors. (line 59)
-* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 92)
-* SYMBOL_REF_FLAG: Flags. (line 224)
-* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 269)
-* SYMBOL_REF_FLAGS: Special Accessors. (line 79)
-* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 85)
-* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 106)
-* SYMBOL_REF_LOCAL_P: Special Accessors. (line 88)
-* SYMBOL_REF_SMALL_P: Special Accessors. (line 97)
-* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 101)
-* SYMBOL_REF_USED: Flags. (line 215)
-* SYMBOL_REF_WEAK: Flags. (line 220)
-* symbolic label: Sharing. (line 20)
-* sync_addMODE instruction pattern: Standard Names. (line 1458)
-* sync_andMODE instruction pattern: Standard Names. (line 1458)
-* sync_compare_and_swapMODE instruction pattern: Standard Names.
- (line 1428)
-* sync_iorMODE instruction pattern: Standard Names. (line 1458)
-* sync_lock_releaseMODE instruction pattern: Standard Names. (line 1523)
-* sync_lock_test_and_setMODE instruction pattern: Standard Names.
- (line 1497)
-* sync_nandMODE instruction pattern: Standard Names. (line 1458)
-* sync_new_addMODE instruction pattern: Standard Names. (line 1490)
-* sync_new_andMODE instruction pattern: Standard Names. (line 1490)
-* sync_new_iorMODE instruction pattern: Standard Names. (line 1490)
-* sync_new_nandMODE instruction pattern: Standard Names. (line 1490)
-* sync_new_subMODE instruction pattern: Standard Names. (line 1490)
-* sync_new_xorMODE instruction pattern: Standard Names. (line 1490)
-* sync_old_addMODE instruction pattern: Standard Names. (line 1473)
-* sync_old_andMODE instruction pattern: Standard Names. (line 1473)
-* sync_old_iorMODE instruction pattern: Standard Names. (line 1473)
-* sync_old_nandMODE instruction pattern: Standard Names. (line 1473)
-* sync_old_subMODE instruction pattern: Standard Names. (line 1473)
-* sync_old_xorMODE instruction pattern: Standard Names. (line 1473)
-* sync_subMODE instruction pattern: Standard Names. (line 1458)
-* sync_xorMODE instruction pattern: Standard Names. (line 1458)
-* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 177)
-* SYSROOT_SUFFIX_SPEC: Driver. (line 172)
-* SYSTEM_INCLUDE_DIR: Driver. (line 322)
-* t-TARGET: Target Fragment. (line 6)
-* table jump: Basic Blocks. (line 57)
-* tablejump instruction pattern: Standard Names. (line 1102)
-* tag: GTY Options. (line 77)
-* tagging insns: Tagging Insns. (line 6)
-* tail calls: Tail Calls. (line 6)
-* TAmode: Machine Modes. (line 156)
-* target attributes: Target Attributes. (line 6)
-* target description macros: Target Macros. (line 6)
-* target functions: Target Structure. (line 6)
-* target hooks: Target Structure. (line 6)
-* target makefile fragment: Target Fragment. (line 6)
-* target specifications: Run-time Target. (line 6)
-* TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces.
- (line 45)
-* TARGET_ADDR_SPACE_CONVERT: Named Address Spaces.
- (line 88)
-* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces.
- (line 63)
-* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces.
- (line 72)
-* TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces.
- (line 38)
-* TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces.
- (line 79)
-* TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces.
- (line 52)
-* TARGET_ADDRESS_COST: Costs. (line 297)
-* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 383)
-* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 697)
-* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 977)
-* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 83)
-* TARGET_ARM_EABI_UNWINDER: Exception Region Output.
- (line 122)
-* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10)
-* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8)
-* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9)
-* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11)
-* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 259)
-* TARGET_ASM_BYTE_OP: Data Output. (line 7)
-* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 237)
-* TARGET_ASM_CLOSE_PAREN: Data Output. (line 142)
-* TARGET_ASM_CODE_END: File Framework. (line 59)
-* TARGET_ASM_CONSTRUCTOR: Macros for Initialization.
- (line 69)
-* TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 142)
-* TARGET_ASM_DESTRUCTOR: Macros for Initialization.
- (line 83)
-* TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 82)
-* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 74)
-* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 63)
-* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 294)
-* TARGET_ASM_FILE_END: File Framework. (line 37)
-* TARGET_ASM_FILE_START: File Framework. (line 9)
-* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17)
-* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31)
-* TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 84)
-* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61)
-* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55)
-* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68)
-* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11)
-* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 216)
-* TARGET_ASM_FUNCTION_SECTION: File Framework. (line 123)
-* TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework.
- (line 133)
-* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 187)
-* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 178)
-* TARGET_ASM_INIT_SECTIONS: Sections. (line 161)
-* TARGET_ASM_INTEGER: Data Output. (line 27)
-* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 338)
-* TARGET_ASM_JUMP_ALIGN_MAX_SKIP: Alignment Output. (line 22)
-* TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output.
- (line 36)
-* TARGET_ASM_LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 69)
-* TARGET_ASM_LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 54)
-* TARGET_ASM_LTO_END: File Framework. (line 54)
-* TARGET_ASM_LTO_START: File Framework. (line 49)
-* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 301)
-* TARGET_ASM_NAMED_SECTION: File Framework. (line 115)
-* TARGET_ASM_OPEN_PAREN: Data Output. (line 141)
-* TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 40)
-* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 44)
-* TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 96)
-* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 195)
-* TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 94)
-* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 164)
-* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 208)
-* TARGET_ASM_RELOC_RW_MASK: Sections. (line 170)
-* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 224)
-* TARGET_ASM_SELECT_SECTION: Sections. (line 182)
-* TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 29)
-* TARGET_ASM_TTYPE: Exception Region Output.
- (line 116)
-* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14)
-* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12)
-* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13)
-* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15)
-* TARGET_ASM_UNIQUE_SECTION: Sections. (line 203)
-* TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 88)
-* TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 93)
-* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11)
-* TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 19)
-* TARGET_BINDS_LOCAL_P: Sections. (line 301)
-* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 794)
-* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 786)
-* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 264)
-* TARGET_BUILTIN_DECL: Misc. (line 620)
-* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 265)
-* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 109)
-* TARGET_C99_FUNCTIONS: Library Calls. (line 63)
-* TARGET_CALLEE_COPIES: Register Arguments. (line 115)
-* TARGET_CAN_ELIMINATE: Elimination. (line 75)
-* TARGET_CAN_INLINE_P: Target Attributes. (line 150)
-* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 246)
-* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 773)
-* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 285)
-* TARGET_CASE_VALUES_THRESHOLD: Misc. (line 47)
-* TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes.
- (line 116)
-* TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 28)
-* TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 113)
-* TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 492)
-* TARGET_COMMUTATIVE_P: Misc. (line 690)
-* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 27)
-* TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60)
-* TARGET_CONST_ANCHOR: Misc. (line 988)
-* TARGET_CONVERT_TO_TYPE: Misc. (line 941)
-* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9)
-* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 87)
-* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 38)
-* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 62)
-* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 25)
-* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 54)
-* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 18)
-* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 12)
-* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 7)
-* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 30)
-* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 43)
-* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 69)
-* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 74)
-* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 80)
-* TARGET_DEBUG_UNWIND_INFO: SDB and DWARF. (line 37)
-* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 508)
-* TARGET_DECLSPEC: Target Attributes. (line 73)
-* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 445)
-* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 159)
-* TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 56)
-* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 422)
-* TARGET_DELAY_SCHED2: SDB and DWARF. (line 61)
-* TARGET_DELAY_VARTRACK: SDB and DWARF. (line 65)
-* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 237)
-* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55)
-* TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 18)
-* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 172)
-* TARGET_DWARF_REGISTER_SPAN: Exception Region Output.
- (line 99)
-* TARGET_EDOM: Library Calls. (line 45)
-* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 68)
-* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 19)
-* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 24)
-* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 45)
-* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 36)
-* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 63)
-* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 49)
-* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 57)
-* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 41)
-* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 31)
-* TARGET_ENCODE_SECTION_INFO: Sections. (line 245)
-* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes.
- (line 83)
-* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 128)
-* TARGET_ENUM_VA_LIST_P: Register Arguments. (line 269)
-* TARGET_EXCEPT_UNWIND_INFO: Exception Region Output.
- (line 48)
-* TARGET_EXECUTABLE_SUFFIX: Misc. (line 747)
-* TARGET_EXPAND_BUILTIN: Misc. (line 630)
-* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 67)
-* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 514)
-* TARGET_EXPR: Unary and Binary Expressions.
- (line 6)
-* TARGET_EXTRA_INCLUDES: Misc. (line 834)
-* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 21)
-* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 841)
-* TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes.
- (line 101)
-* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 511)
-* target_flags: Run-time Target. (line 52)
-* TARGET_FLAGS_REGNUM: Register Arguments. (line 361)
-* TARGET_FLT_EVAL_METHOD: Type Layout. (line 140)
-* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 280)
-* TARGET_FOLD_BUILTIN: Misc. (line 651)
-* TARGET_FORMAT_TYPES: Misc. (line 861)
-* TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 9)
-* TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 239)
-* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 95)
-* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8)
-* TARGET_FUNCTION_VALUE: Scalar Return. (line 11)
-* TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 97)
-* TARGET_GET_DRAP_RTX: Misc. (line 971)
-* TARGET_GET_PCH_VALIDITY: PCH Target. (line 7)
-* TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 83)
-* TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 78)
-* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 291)
-* TARGET_HANDLE_C_OPTION: Run-time Target. (line 78)
-* TARGET_HANDLE_OPTION: Run-time Target. (line 61)
-* TARGET_HANDLE_PRAGMA_EXTERN_PREFIX: Misc. (line 442)
-* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers.
- (line 144)
-* TARGET_HAS_SINCOS: Library Calls. (line 71)
-* TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 808)
-* TARGET_HAVE_CTORS_DTORS: Macros for Initialization.
- (line 64)
-* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 140)
-* TARGET_HAVE_SRODATA_SECTION: Sections. (line 290)
-* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 145)
-* TARGET_HAVE_TLS: Sections. (line 310)
-* TARGET_HELP: Run-time Target. (line 170)
-* TARGET_IN_SMALL_DATA_P: Sections. (line 286)
-* TARGET_INIT_BUILTINS: Misc. (line 602)
-* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output.
- (line 108)
-* TARGET_INIT_LIBFUNCS: Library Calls. (line 16)
-* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 82)
-* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 522)
-* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 895)
-* TARGET_INVALID_BINARY_OP: Misc. (line 914)
-* TARGET_INVALID_CONVERSION: Misc. (line 901)
-* TARGET_INVALID_PARAMETER_TYPE: Misc. (line 920)
-* TARGET_INVALID_RETURN_TYPE: Misc. (line 927)
-* TARGET_INVALID_UNARY_OP: Misc. (line 907)
-* TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 670)
-* TARGET_IRA_COVER_CLASSES: Register Classes. (line 537)
-* TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 50)
-* TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 132)
-* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 35)
-* TARGET_LIBCALL_VALUE: Scalar Return. (line 66)
-* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 445)
-* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 133)
-* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 451)
-* TARGET_LOOP_UNROLL_ADJUST: Misc. (line 815)
-* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 587)
-* TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 313)
-* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 235)
-* TARGET_MANGLE_TYPE: Storage Layout. (line 526)
-* TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 39)
-* TARGET_MD_ASM_CLOBBERS: Misc. (line 503)
-* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 109)
-* TARGET_MEM_REF: Storage References. (line 6)
-* TARGET_MEMORY_MOVE_COST: Costs. (line 81)
-* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 47)
-* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 39)
-* TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 33)
-* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 106)
-* TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 196)
-* TARGET_MODE_REP_EXTENDED: Misc. (line 191)
-* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 481)
-* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 62)
-* TARGET_MUST_PASS_IN_STACK, and FUNCTION_ARG: Register Arguments.
- (line 52)
-* TARGET_MVERSION_FUNCTION: Misc. (line 660)
-* TARGET_N_FORMAT_TYPES: Misc. (line 866)
-* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 389)
-* TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 92)
-* TARGET_OBJECT_SUFFIX: Misc. (line 742)
-* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46)
-* TARGET_OPTF: Misc. (line 848)
-* TARGET_OPTION_DEFAULT_PARAMS: Run-time Target. (line 166)
-* TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 163)
-* TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 149)
-* TARGET_OPTION_OVERRIDE: Target Attributes. (line 137)
-* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 131)
-* TARGET_OPTION_PRINT: Target Attributes. (line 125)
-* TARGET_OPTION_RESTORE: Target Attributes. (line 119)
-* TARGET_OPTION_SAVE: Target Attributes. (line 113)
-* TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 102)
-* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42)
-* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 132)
-* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 870)
-* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 876)
-* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 880)
-* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 103)
-* TARGET_PCH_VALID_P: PCH Target. (line 13)
-* TARGET_POSIX_IO: Misc. (line 527)
-* TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 287)
-* TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 208)
-* TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 196)
-* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 128)
-* TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 294)
-* TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 112)
-* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11)
-* TARGET_PROMOTED_TYPE: Misc. (line 933)
-* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 277)
-* TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 302)
-* TARGET_REGISTER_MOVE_COST: Costs. (line 33)
-* TARGET_RELAXED_ORDERING: Misc. (line 885)
-* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 640)
-* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 17)
-* TARGET_RETURN_IN_MSB: Scalar Return. (line 117)
-* TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 94)
-* TARGET_RTX_COSTS: Costs. (line 271)
-* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 310)
-* TARGET_SCHED_ADJUST_COST: Scheduling. (line 37)
-* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 52)
-* TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 274)
-* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 289)
-* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 89)
-* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 235)
-* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 160)
-* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 144)
-* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 153)
-* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 132)
-* TARGET_SCHED_DISPATCH: Scheduling. (line 355)
-* TARGET_SCHED_DISPATCH_DO: Scheduling. (line 360)
-* TARGET_SCHED_FINISH: Scheduling. (line 109)
-* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 126)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 215)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 204)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling.
- (line 168)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling.
- (line 196)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC: Scheduling.
- (line 328)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 220)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 230)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 225)
-* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 210)
-* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 293)
-* TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 315)
-* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 269)
-* TARGET_SCHED_INIT: Scheduling. (line 99)
-* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 149)
-* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 141)
-* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 118)
-* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 279)
-* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 246)
-* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12)
-* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 308)
-* TARGET_SCHED_REORDER: Scheduling. (line 60)
-* TARGET_SCHED_REORDER2: Scheduling. (line 77)
-* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 285)
-* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 340)
-* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 346)
-* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 297)
-* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 24)
-* TARGET_SECONDARY_RELOAD: Register Classes. (line 316)
-* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 151)
-* TARGET_SET_CURRENT_FUNCTION: Misc. (line 724)
-* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 34)
-* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 76)
-* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 154)
-* TARGET_SLOW_UNALIGNED_VECTOR_MEMOP: Misc. (line 665)
-* TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments.
- (line 328)
-* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 252)
-* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection.
- (line 17)
-* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection.
- (line 7)
-* TARGET_STATIC_CHAIN: Frame Registers. (line 92)
-* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 112)
-* TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 108)
-* TARGET_STRIP_NAME_ENCODING: Sections. (line 282)
-* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 45)
-* TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection.
- (line 27)
-* TARGET_SUPPORTS_WEAK: Label Output. (line 229)
-* TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output.
- (line 93)
-* TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 75)
-* TARGET_TRAMPOLINE_INIT: Trampolines. (line 56)
-* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 716)
-* TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output.
- (line 74)
-* TARGET_UNWIND_WORD_MODE: Storage Layout. (line 457)
-* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 967)
-* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 55)
-* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 258)
-* TARGET_USE_JCR_SECTION: Misc. (line 949)
-* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 129)
-* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 68)
-* TARGET_VALID_POINTER_MODE: Register Arguments. (line 297)
-* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 322)
-* TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES: Addressing Modes.
- (line 382)
-* TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 344)
-* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 274)
-* TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN: Addressing Modes. (line 300)
-* TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD: Addressing Modes. (line 312)
-* TARGET_VECTORIZE_BUILTIN_VEC_PERM: Addressing Modes. (line 336)
-* TARGET_VECTORIZE_BUILTIN_VEC_PERM_OK: Addressing Modes. (line 340)
-* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes.
- (line 325)
-* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes.
- (line 356)
-* TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 375)
-* TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes.
- (line 366)
-* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes.
- (line 331)
-* TARGET_VERSION: Run-time Target. (line 119)
-* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 330)
-* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 324)
-* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 313)
-* TARGET_WANT_DEBUG_PUB_SECTIONS: SDB and DWARF. (line 56)
-* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 265)
-* targetm: Target Structure. (line 7)
-* targets, makefile: Makefile. (line 6)
-* TCmode: Machine Modes. (line 197)
-* TDmode: Machine Modes. (line 94)
-* TEMPLATE_DECL: Declarations. (line 6)
-* Temporaries: Temporaries. (line 6)
-* termination routines: Initialization. (line 6)
-* testing constraints: C Constraint Interface.
- (line 6)
-* TEXT_SECTION_ASM_OP: Sections. (line 38)
-* TF_SIZE: Type Layout. (line 131)
-* TFmode: Machine Modes. (line 98)
-* THEN_CLAUSE: Statements for C++. (line 6)
-* THREAD_MODEL_SPEC: Driver. (line 163)
-* THROW_EXPR: Unary and Binary Expressions.
- (line 6)
-* THUNK_DECL: Declarations. (line 6)
-* THUNK_DELTA: Declarations. (line 6)
-* TImode: Machine Modes. (line 48)
-* TImode, in insn: Insns. (line 272)
-* TLS_COMMON_ASM_OP: Sections. (line 82)
-* TLS_SECTION_ASM_FLAG: Sections. (line 87)
-* tm.h macros: Target Macros. (line 6)
-* TQFmode: Machine Modes. (line 62)
-* TQmode: Machine Modes. (line 119)
-* TRAMPOLINE_ALIGNMENT: Trampolines. (line 49)
-* TRAMPOLINE_SECTION: Trampolines. (line 40)
-* TRAMPOLINE_SIZE: Trampolines. (line 45)
-* trampolines for nested functions: Trampolines. (line 6)
-* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 123)
-* trap instruction pattern: Standard Names. (line 1381)
-* tree <1>: Macros and Functions.
- (line 6)
-* tree: Tree overview. (line 6)
-* Tree SSA: Tree SSA. (line 6)
-* TREE_CHAIN: Macros and Functions.
- (line 6)
-* TREE_CODE: Tree overview. (line 6)
-* tree_int_cst_equal: Constant expressions.
- (line 6)
-* TREE_INT_CST_HIGH: Constant expressions.
- (line 6)
-* TREE_INT_CST_LOW: Constant expressions.
- (line 6)
-* tree_int_cst_lt: Constant expressions.
- (line 6)
-* TREE_LIST: Containers. (line 6)
-* TREE_OPERAND: Expression trees. (line 6)
-* TREE_PUBLIC <1>: Function Basics. (line 6)
-* TREE_PUBLIC: Function Properties.
- (line 28)
-* TREE_PURPOSE: Containers. (line 6)
-* TREE_READONLY: Function Properties.
- (line 37)
-* tree_size: Macros and Functions.
- (line 13)
-* TREE_STATIC: Function Properties.
- (line 31)
-* TREE_STRING_LENGTH: Constant expressions.
- (line 6)
-* TREE_STRING_POINTER: Constant expressions.
- (line 6)
-* TREE_THIS_VOLATILE: Function Properties.
- (line 34)
-* TREE_TYPE <1>: Expression trees. (line 17)
-* TREE_TYPE <2>: Macros and Functions.
- (line 6)
-* TREE_TYPE <3>: Types. (line 6)
-* TREE_TYPE <4>: Function Basics. (line 47)
-* TREE_TYPE <5>: Working with declarations.
- (line 11)
-* TREE_TYPE <6>: Types for C++. (line 6)
-* TREE_TYPE: Expression trees. (line 6)
-* TREE_VALUE: Containers. (line 6)
-* TREE_VEC: Containers. (line 6)
-* TREE_VEC_ELT: Containers. (line 6)
-* TREE_VEC_LENGTH: Containers. (line 6)
-* TRULY_NOOP_TRUNCATION: Misc. (line 177)
-* TRUNC_DIV_EXPR: Unary and Binary Expressions.
- (line 6)
-* TRUNC_MOD_EXPR: Unary and Binary Expressions.
- (line 6)
-* truncate: Conversions. (line 38)
-* truncMN2 instruction pattern: Standard Names. (line 834)
-* TRUTH_AND_EXPR: Unary and Binary Expressions.
- (line 6)
-* TRUTH_ANDIF_EXPR: Unary and Binary Expressions.
- (line 6)
-* TRUTH_NOT_EXPR: Unary and Binary Expressions.
- (line 6)
-* TRUTH_OR_EXPR: Unary and Binary Expressions.
- (line 6)
-* TRUTH_ORIF_EXPR: Unary and Binary Expressions.
- (line 6)
-* TRUTH_XOR_EXPR: Unary and Binary Expressions.
- (line 6)
-* TRY_BLOCK: Statements for C++. (line 6)
-* TRY_HANDLERS: Statements for C++. (line 6)
-* TRY_STMTS: Statements for C++. (line 6)
-* Tuple specific accessors: Tuple specific accessors.
- (line 6)
-* tuples: Tuple representation.
- (line 6)
-* type: Types. (line 6)
-* type declaration: Declarations. (line 6)
-* TYPE_ALIGN <1>: Types. (line 30)
-* TYPE_ALIGN <2>: Types for C++. (line 6)
-* TYPE_ALIGN: Types. (line 6)
-* TYPE_ARG_TYPES <1>: Types for C++. (line 6)
-* TYPE_ARG_TYPES: Types. (line 6)
-* TYPE_ASM_OP: Label Output. (line 67)
-* TYPE_ATTRIBUTES: Attributes. (line 25)
-* TYPE_BINFO: Classes. (line 6)
-* TYPE_BUILT_IN: Types for C++. (line 68)
-* TYPE_CANONICAL: Types. (line 6)
-* TYPE_CONTEXT <1>: Types for C++. (line 6)
-* TYPE_CONTEXT: Types. (line 6)
-* TYPE_DECL: Declarations. (line 6)
-* TYPE_FIELDS <1>: Types for C++. (line 6)
-* TYPE_FIELDS <2>: Classes. (line 6)
-* TYPE_FIELDS: Types. (line 6)
-* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 96)
-* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 81)
-* TYPE_HAS_MUTABLE_P: Classes. (line 86)
-* TYPE_HAS_NEW_OPERATOR: Classes. (line 93)
-* TYPE_MAIN_VARIANT <1>: Types. (line 19)
-* TYPE_MAIN_VARIANT: Types for C++. (line 6)
-* TYPE_MAX_VALUE: Types. (line 6)
-* TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6)
-* TYPE_METHOD_BASETYPE: Types. (line 6)
-* TYPE_METHODS: Classes. (line 6)
-* TYPE_MIN_VALUE: Types. (line 6)
-* TYPE_NAME <1>: Types. (line 6)
-* TYPE_NAME: Types for C++. (line 6)
-* TYPE_NOTHROW_P: Functions for C++. (line 154)
-* TYPE_OFFSET_BASETYPE <1>: Types. (line 6)
-* TYPE_OFFSET_BASETYPE: Types for C++. (line 6)
-* TYPE_OPERAND_FMT: Label Output. (line 78)
-* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 104)
-* TYPE_OVERLOADS_ARROW: Classes. (line 107)
-* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 100)
-* TYPE_POLYMORPHIC_P: Classes. (line 77)
-* TYPE_PRECISION <1>: Types. (line 6)
-* TYPE_PRECISION: Types for C++. (line 6)
-* TYPE_PTR_P: Types for C++. (line 74)
-* TYPE_PTRFN_P: Types for C++. (line 78)
-* TYPE_PTRMEM_P: Types for C++. (line 6)
-* TYPE_PTROB_P: Types for C++. (line 81)
-* TYPE_PTROBV_P: Types for C++. (line 6)
-* TYPE_QUAL_CONST <1>: Types for C++. (line 6)
-* TYPE_QUAL_CONST: Types. (line 6)
-* TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6)
-* TYPE_QUAL_RESTRICT: Types. (line 6)
-* TYPE_QUAL_VOLATILE <1>: Types. (line 6)
-* TYPE_QUAL_VOLATILE: Types for C++. (line 6)
-* TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149)
-* TYPE_SIZE <1>: Types for C++. (line 40)
-* TYPE_SIZE: Types. (line 25)
-* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6)
-* TYPE_UNQUALIFIED <1>: Types. (line 6)
-* TYPE_UNQUALIFIED: Types for C++. (line 6)
-* TYPE_VFIELD: Classes. (line 6)
-* TYPENAME_TYPE: Types for C++. (line 6)
-* TYPENAME_TYPE_FULLNAME <1>: Types. (line 6)
-* TYPENAME_TYPE_FULLNAME: Types for C++. (line 6)
-* TYPEOF_TYPE: Types for C++. (line 6)
-* UDAmode: Machine Modes. (line 168)
-* udiv: Arithmetic. (line 130)
-* udivM3 instruction pattern: Standard Names. (line 222)
-* udivmodM4 instruction pattern: Standard Names. (line 455)
-* udot_prodM instruction pattern: Standard Names. (line 292)
-* UDQmode: Machine Modes. (line 136)
-* UHAmode: Machine Modes. (line 160)
-* UHQmode: Machine Modes. (line 128)
-* UINT16_TYPE: Type Layout. (line 240)
-* UINT32_TYPE: Type Layout. (line 241)
-* UINT64_TYPE: Type Layout. (line 242)
-* UINT8_TYPE: Type Layout. (line 239)
-* UINT_FAST16_TYPE: Type Layout. (line 256)
-* UINT_FAST32_TYPE: Type Layout. (line 257)
-* UINT_FAST64_TYPE: Type Layout. (line 258)
-* UINT_FAST8_TYPE: Type Layout. (line 255)
-* UINT_LEAST16_TYPE: Type Layout. (line 248)
-* UINT_LEAST32_TYPE: Type Layout. (line 249)
-* UINT_LEAST64_TYPE: Type Layout. (line 250)
-* UINT_LEAST8_TYPE: Type Layout. (line 247)
-* UINTMAX_TYPE: Type Layout. (line 223)
-* UINTPTR_TYPE: Type Layout. (line 260)
-* umaddMN4 instruction pattern: Standard Names. (line 402)
-* umax: Arithmetic. (line 149)
-* umaxM3 instruction pattern: Standard Names. (line 222)
-* umin: Arithmetic. (line 149)
-* uminM3 instruction pattern: Standard Names. (line 222)
-* umod: Arithmetic. (line 136)
-* umodM3 instruction pattern: Standard Names. (line 222)
-* umsubMN4 instruction pattern: Standard Names. (line 426)
-* umulhisi3 instruction pattern: Standard Names. (line 374)
-* umulM3_highpart instruction pattern: Standard Names. (line 388)
-* umulqihi3 instruction pattern: Standard Names. (line 374)
-* umulsidi3 instruction pattern: Standard Names. (line 374)
-* unchanging: Flags. (line 324)
-* unchanging, in call_insn: Flags. (line 19)
-* unchanging, in jump_insn, call_insn and insn: Flags. (line 39)
-* unchanging, in mem: Flags. (line 152)
-* unchanging, in subreg: Flags. (line 188)
-* unchanging, in symbol_ref: Flags. (line 10)
-* UNEQ_EXPR: Unary and Binary Expressions.
- (line 6)
-* UNGE_EXPR: Unary and Binary Expressions.
- (line 6)
-* UNGT_EXPR: Unary and Binary Expressions.
- (line 6)
-* UNION_TYPE <1>: Types. (line 6)
-* UNION_TYPE: Classes. (line 6)
-* unions, returning: Interface. (line 10)
-* UNITS_PER_WORD: Storage Layout. (line 60)
-* UNKNOWN_TYPE <1>: Types for C++. (line 6)
-* UNKNOWN_TYPE: Types. (line 6)
-* UNLE_EXPR: Unary and Binary Expressions.
- (line 6)
-* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 49)
-* UNLT_EXPR: Unary and Binary Expressions.
- (line 6)
-* UNORDERED_EXPR: Unary and Binary Expressions.
- (line 6)
-* unshare_all_rtl: Sharing. (line 58)
-* unsigned division: Arithmetic. (line 130)
-* unsigned division with unsigned saturation: Arithmetic. (line 130)
-* unsigned greater than: Comparisons. (line 72)
-* unsigned less than: Comparisons. (line 76)
-* unsigned minimum and maximum: Arithmetic. (line 149)
-* unsigned_fix: Conversions. (line 77)
-* unsigned_float: Conversions. (line 62)
-* unsigned_fract_convert: Conversions. (line 97)
-* unsigned_sat_fract: Conversions. (line 103)
-* unspec <1>: Constant Definitions.
- (line 111)
-* unspec: Side Effects. (line 287)
-* unspec_volatile <1>: Constant Definitions.
- (line 99)
-* unspec_volatile: Side Effects. (line 287)
-* untyped_call instruction pattern: Standard Names. (line 1012)
-* untyped_return instruction pattern: Standard Names. (line 1062)
-* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59)
-* update_ssa: SSA. (line 76)
-* update_stmt <1>: Manipulating GIMPLE statements.
- (line 141)
-* update_stmt: SSA Operands. (line 6)
-* update_stmt_if_modified: Manipulating GIMPLE statements.
- (line 144)
-* UQQmode: Machine Modes. (line 123)
-* us_ashift: Arithmetic. (line 173)
-* us_minus: Arithmetic. (line 36)
-* us_mult: Arithmetic. (line 92)
-* us_neg: Arithmetic. (line 81)
-* us_plus: Arithmetic. (line 14)
-* us_truncate: Conversions. (line 48)
-* usaddM3 instruction pattern: Standard Names. (line 222)
-* USAmode: Machine Modes. (line 164)
-* usashlM3 instruction pattern: Standard Names. (line 458)
-* usdivM3 instruction pattern: Standard Names. (line 222)
-* use: Side Effects. (line 162)
-* USE_C_ALLOCA: Host Misc. (line 19)
-* USE_LD_AS_NEEDED: Driver. (line 136)
-* USE_LOAD_POST_DECREMENT: Costs. (line 226)
-* USE_LOAD_POST_INCREMENT: Costs. (line 221)
-* USE_LOAD_PRE_DECREMENT: Costs. (line 236)
-* USE_LOAD_PRE_INCREMENT: Costs. (line 231)
-* use_param: GTY Options. (line 109)
-* use_paramN: GTY Options. (line 127)
-* use_params: GTY Options. (line 135)
-* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 195)
-* USE_STORE_POST_DECREMENT: Costs. (line 246)
-* USE_STORE_POST_INCREMENT: Costs. (line 241)
-* USE_STORE_PRE_DECREMENT: Costs. (line 256)
-* USE_STORE_PRE_INCREMENT: Costs. (line 251)
-* used: Flags. (line 342)
-* used, in symbol_ref: Flags. (line 215)
-* USER_LABEL_PREFIX: Instruction Output. (line 154)
-* USING_STMT: Statements for C++. (line 6)
-* usmaddMN4 instruction pattern: Standard Names. (line 410)
-* usmsubMN4 instruction pattern: Standard Names. (line 434)
-* usmulhisi3 instruction pattern: Standard Names. (line 378)
-* usmulM3 instruction pattern: Standard Names. (line 222)
-* usmulqihi3 instruction pattern: Standard Names. (line 378)
-* usmulsidi3 instruction pattern: Standard Names. (line 378)
-* usnegM2 instruction pattern: Standard Names. (line 476)
-* USQmode: Machine Modes. (line 132)
-* ussubM3 instruction pattern: Standard Names. (line 222)
-* usum_widenM3 instruction pattern: Standard Names. (line 302)
-* UTAmode: Machine Modes. (line 172)
-* UTQmode: Machine Modes. (line 140)
-* V in constraint: Simple Constraints. (line 43)
-* VA_ARG_EXPR: Unary and Binary Expressions.
- (line 6)
-* values, returned by functions: Scalar Return. (line 6)
-* VAR_DECL: Declarations. (line 6)
-* var_location: Debug Information. (line 14)
-* varargs implementation: Varargs. (line 6)
-* variable: Declarations. (line 6)
-* Variable Location Debug Information in RTL: Debug Information.
- (line 6)
-* variable_size: GTY Options. (line 225)
-* vashlM3 instruction pattern: Standard Names. (line 472)
-* vashrM3 instruction pattern: Standard Names. (line 472)
-* vec_concat: Vector Operations. (line 28)
-* vec_duplicate: Vector Operations. (line 33)
-* VEC_EXTRACT_EVEN_EXPR: Vectors. (line 6)
-* vec_extract_evenM instruction pattern: Standard Names. (line 176)
-* VEC_EXTRACT_ODD_EXPR: Vectors. (line 6)
-* vec_extract_oddM instruction pattern: Standard Names. (line 183)
-* vec_extractM instruction pattern: Standard Names. (line 171)
-* vec_initM instruction pattern: Standard Names. (line 204)
-* VEC_INTERLEAVE_HIGH_EXPR: Vectors. (line 6)
-* vec_interleave_highM instruction pattern: Standard Names. (line 190)
-* VEC_INTERLEAVE_LOW_EXPR: Vectors. (line 6)
-* vec_interleave_lowM instruction pattern: Standard Names. (line 197)
-* VEC_LSHIFT_EXPR: Vectors. (line 6)
-* vec_merge: Vector Operations. (line 11)
-* VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6)
-* VEC_PACK_SAT_EXPR: Vectors. (line 6)
-* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 329)
-* vec_pack_ssat_M instruction pattern: Standard Names. (line 322)
-* VEC_PACK_TRUNC_EXPR: Vectors. (line 6)
-* vec_pack_trunc_M instruction pattern: Standard Names. (line 315)
-* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 329)
-* vec_pack_usat_M instruction pattern: Standard Names. (line 322)
-* VEC_RSHIFT_EXPR: Vectors. (line 6)
-* vec_select: Vector Operations. (line 19)
-* vec_setM instruction pattern: Standard Names. (line 166)
-* vec_shl_M instruction pattern: Standard Names. (line 309)
-* vec_shr_M instruction pattern: Standard Names. (line 309)
-* VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6)
-* VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6)
-* VEC_UNPACK_HI_EXPR: Vectors. (line 6)
-* VEC_UNPACK_LO_EXPR: Vectors. (line 6)
-* vec_unpacks_float_hi_M instruction pattern: Standard Names.
- (line 351)
-* vec_unpacks_float_lo_M instruction pattern: Standard Names.
- (line 351)
-* vec_unpacks_hi_M instruction pattern: Standard Names. (line 336)
-* vec_unpacks_lo_M instruction pattern: Standard Names. (line 336)
-* vec_unpacku_float_hi_M instruction pattern: Standard Names.
- (line 351)
-* vec_unpacku_float_lo_M instruction pattern: Standard Names.
- (line 351)
-* vec_unpacku_hi_M instruction pattern: Standard Names. (line 344)
-* vec_unpacku_lo_M instruction pattern: Standard Names. (line 344)
-* VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6)
-* VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6)
-* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 360)
-* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 360)
-* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 360)
-* vec_widen_umult_lo__M instruction pattern: Standard Names. (line 360)
-* vector: Containers. (line 6)
-* vector operations: Vector Operations. (line 6)
-* VECTOR_CST: Constant expressions.
- (line 6)
-* VECTOR_STORE_FLAG_VALUE: Misc. (line 308)
-* virtual operands: SSA Operands. (line 6)
-* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59)
-* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87)
-* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78)
-* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69)
-* VLIW: Processor pipeline description.
- (line 6)
-* vlshrM3 instruction pattern: Standard Names. (line 472)
-* VMS: Filesystem. (line 37)
-* VMS_DEBUGGING_INFO: VMS Debug. (line 9)
-* VOID_TYPE: Types. (line 6)
-* VOIDmode: Machine Modes. (line 190)
-* volatil: Flags. (line 356)
-* volatil, in insn, call_insn, jump_insn, code_label, barrier, and note: Flags.
- (line 44)
-* volatil, in label_ref and reg_label: Flags. (line 65)
-* volatil, in mem, asm_operands, and asm_input: Flags. (line 94)
-* volatil, in reg: Flags. (line 116)
-* volatil, in subreg: Flags. (line 188)
-* volatil, in symbol_ref: Flags. (line 224)
-* volatile memory references: Flags. (line 357)
-* volatile, in prefetch: Flags. (line 232)
-* voting between constraint alternatives: Class Preferences. (line 6)
-* vrotlM3 instruction pattern: Standard Names. (line 472)
-* vrotrM3 instruction pattern: Standard Names. (line 472)
-* walk_dominator_tree: SSA. (line 256)
-* walk_gimple_op: Statement and operand traversals.
- (line 32)
-* walk_gimple_seq: Statement and operand traversals.
- (line 50)
-* walk_gimple_stmt: Statement and operand traversals.
- (line 13)
-* walk_use_def_chains: SSA. (line 232)
-* WCHAR_TYPE: Type Layout. (line 191)
-* WCHAR_TYPE_SIZE: Type Layout. (line 199)
-* which_alternative: Output Statement. (line 59)
-* WHILE_BODY: Statements for C++. (line 6)
-* WHILE_COND: Statements for C++. (line 6)
-* WHILE_STMT: Statements for C++. (line 6)
-* whopr: LTO. (line 6)
-* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 146)
-* WINT_TYPE: Type Layout. (line 204)
-* word_mode: Machine Modes. (line 336)
-* WORD_REGISTER_OPERATIONS: Misc. (line 63)
-* WORDS_BIG_ENDIAN: Storage Layout. (line 29)
-* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 217)
-* wpa: LTO. (line 6)
-* X in constraint: Simple Constraints. (line 124)
-* x-HOST: Host Fragment. (line 6)
-* XCmode: Machine Modes. (line 197)
-* XCOFF_DEBUGGING_INFO: DBX Options. (line 13)
-* XEXP: Accessors. (line 6)
-* XF_SIZE: Type Layout. (line 130)
-* XFmode: Machine Modes. (line 79)
-* XINT: Accessors. (line 6)
-* xm-MACHINE.h <1>: Host Misc. (line 6)
-* xm-MACHINE.h: Filesystem. (line 6)
-* xor: Arithmetic. (line 168)
-* xor, canonicalization of: Insn Canonicalizations.
- (line 79)
-* xorM3 instruction pattern: Standard Names. (line 222)
-* XSTR: Accessors. (line 6)
-* XVEC: Accessors. (line 41)
-* XVECEXP: Accessors. (line 48)
-* XVECLEN: Accessors. (line 44)
-* XWINT: Accessors. (line 6)
-* zero_extend: Conversions. (line 28)
-* zero_extendMN2 instruction pattern: Standard Names. (line 844)
-* zero_extract: Bit-Fields. (line 30)
-* zero_extract, canonicalization of: Insn Canonicalizations.
- (line 88)
-
-
-
-Tag Table:
-Node: Top2086
-Node: Contributing5181
-Node: Portability5922
-Node: Interface7710
-Node: Libgcc10750
-Node: Integer library routines12591
-Node: Soft float library routines19430
-Node: Decimal float library routines31367
-Node: Fixed-point fractional library routines47124
-Node: Exception handling routines147522
-Node: Miscellaneous routines148629
-Node: Languages150749
-Node: Source Tree152298
-Node: Configure Terms152880
-Node: Top Level155838
-Node: gcc Directory159150
-Node: Subdirectories160100
-Node: Configuration161972
-Node: Config Fragments162692
-Node: System Config163921
-Node: Configuration Files164857
-Node: Build167214
-Node: Makefile167626
-Ref: Makefile-Footnote-1174429
-Ref: Makefile-Footnote-2174574
-Node: Library Files174646
-Node: Headers175208
-Node: Documentation177291
-Node: Texinfo Manuals178150
-Node: Man Page Generation180494
-Node: Miscellaneous Docs182409
-Node: Front End183798
-Node: Front End Directory187491
-Node: Front End Config188811
-Node: Front End Makefile191753
-Node: Back End195535
-Node: Testsuites199214
-Node: Test Idioms200145
-Node: Test Directives203542
-Node: Directives204069
-Node: Selectors214137
-Node: Effective-Target Keywords215279
-Ref: arm_neon_ok222512
-Ref: arm_neon_fp16_ok222673
-Node: Add Options231869
-Node: Require Support233066
-Node: Final Actions235573
-Node: Ada Tests239636
-Node: C Tests240978
-Node: libgcj Tests245401
-Node: LTO Testing246528
-Node: gcov Testing248175
-Node: profopt Testing251162
-Node: compat Testing252877
-Node: Torture Tests257117
-Node: Options258734
-Node: Option file format259174
-Node: Option properties266145
-Node: Passes277699
-Node: Parsing pass278443
-Node: Gimplification pass281973
-Node: Pass manager283806
-Node: Tree SSA passes285600
-Node: RTL passes308072
-Node: RTL320415
-Node: RTL Objects322603
-Node: RTL Classes326477
-Node: Accessors331475
-Node: Special Accessors333869
-Node: Flags339235
-Node: Machine Modes355410
-Node: Constants367722
-Node: Regs and Memory373751
-Node: Arithmetic391652
-Node: Comparisons401479
-Node: Bit-Fields405771
-Node: Vector Operations407323
-Node: Conversions409158
-Node: RTL Declarations413656
-Node: Side Effects414477
-Node: Incdec430799
-Node: Assembler434134
-Node: Debug Information435679
-Node: Insns436877
-Node: Calls463077
-Node: Sharing465670
-Node: Reading RTL468780
-Node: GENERIC469772
-Node: Deficiencies471645
-Node: Tree overview471886
-Node: Macros and Functions476013
-Node: Identifiers476838
-Node: Containers478449
-Node: Types479606
-Node: Declarations491702
-Node: Working with declarations492197
-Node: Internal structure497803
-Node: Current structure hierarchy498187
-Node: Adding new DECL node types500281
-Node: Attributes504354
-Node: Expression trees505599
-Node: Constant expressions507352
-Node: Storage References511571
-Node: Unary and Binary Expressions515090
-Node: Vectors534508
-Node: Statements539437
-Node: Basic Statements539957
-Node: Blocks544464
-Node: Statement Sequences545868
-Node: Empty Statements546201
-Node: Jumps546775
-Node: Cleanups547428
-Node: OpenMP549196
-Node: Functions554943
-Node: Function Basics555414
-Node: Function Properties559099
-Node: Language-dependent trees561881
-Node: C and C++ Trees562767
-Node: Types for C++565671
-Node: Namespaces570637
-Node: Classes573744
-Node: Functions for C++578822
-Node: Statements for C++585075
-Node: C++ Expressions593123
-Node: Java Trees594624
-Node: GIMPLE594737
-Node: Tuple representation598358
-Node: GIMPLE instruction set606634
-Node: GIMPLE Exception Handling608302
-Node: Temporaries610216
-Ref: Temporaries-Footnote-1611531
-Node: Operands611594
-Node: Compound Expressions612356
-Node: Compound Lvalues612590
-Node: Conditional Expressions613352
-Node: Logical Operators614010
-Node: Manipulating GIMPLE statements620767
-Node: Tuple specific accessors626701
-Node: `GIMPLE_ASM'627520
-Node: `GIMPLE_ASSIGN'630153
-Node: `GIMPLE_BIND'634259
-Node: `GIMPLE_CALL'636066
-Node: `GIMPLE_CATCH'640336
-Node: `GIMPLE_COND'641480
-Node: `GIMPLE_DEBUG'644268
-Node: `GIMPLE_EH_FILTER'647651
-Node: `GIMPLE_LABEL'649139
-Node: `GIMPLE_NOP'650114
-Node: `GIMPLE_OMP_ATOMIC_LOAD'650483
-Node: `GIMPLE_OMP_ATOMIC_STORE'651393
-Node: `GIMPLE_OMP_CONTINUE'652032
-Node: `GIMPLE_OMP_CRITICAL'653382
-Node: `GIMPLE_OMP_FOR'654319
-Node: `GIMPLE_OMP_MASTER'657834
-Node: `GIMPLE_OMP_ORDERED'658217
-Node: `GIMPLE_OMP_PARALLEL'658617
-Node: `GIMPLE_OMP_RETURN'661389
-Node: `GIMPLE_OMP_SECTION'662039
-Node: `GIMPLE_OMP_SECTIONS'662705
-Node: `GIMPLE_OMP_SINGLE'664311
-Node: `GIMPLE_PHI'665248
-Node: `GIMPLE_RESX'666663
-Node: `GIMPLE_RETURN'667382
-Node: `GIMPLE_SWITCH'667950
-Node: `GIMPLE_TRY'670088
-Node: `GIMPLE_WITH_CLEANUP_EXPR'671878
-Node: GIMPLE sequences672761
-Node: Sequence iterators675967
-Node: Adding a new GIMPLE statement code684423
-Node: Statement and operand traversals685699
-Node: Tree SSA688299
-Node: Annotations690085
-Node: SSA Operands690611
-Node: SSA705142
-Node: Alias analysis717433
-Node: Memory model721213
-Node: Loop Analysis and Representation722576
-Node: Loop representation723757
-Node: Loop querying730677
-Node: Loop manipulation733510
-Node: LCSSA735878
-Node: Scalar evolutions737950
-Node: loop-iv741194
-Node: Number of iterations743120
-Node: Dependency analysis745929
-Node: Lambda752297
-Node: Omega753968
-Node: Control Flow755533
-Node: Basic Blocks756528
-Node: Edges761096
-Node: Profile information769658
-Node: Maintaining the CFG774344
-Node: Liveness information781221
-Node: Machine Desc783347
-Node: Overview785815
-Node: Patterns787856
-Node: Example791294
-Node: RTL Template792729
-Node: Output Template803384
-Node: Output Statement807349
-Node: Predicates811311
-Node: Machine-Independent Predicates814229
-Node: Defining Predicates819174
-Node: Constraints825139
-Node: Simple Constraints826621
-Node: Multi-Alternative839477
-Node: Class Preferences842318
-Node: Modifiers843210
-Node: Machine Constraints847342
-Node: Disable Insn Alternatives886496
-Node: Define Constraints889389
-Node: C Constraint Interface896170
-Node: Standard Names899811
-Ref: shift patterns919752
-Ref: prologue instruction pattern960386
-Ref: epilogue instruction pattern960879
-Node: Pattern Ordering970601
-Node: Dependent Patterns971837
-Node: Jump Patterns973457
-Ref: Jump Patterns-Footnote-1975601
-Node: Looping Patterns975647
-Node: Insn Canonicalizations980375
-Node: Expander Definitions984326
-Node: Insn Splitting992444
-Node: Including Patterns1002046
-Node: Peephole Definitions1003826
-Node: define_peephole1005079
-Node: define_peephole21011410
-Node: Insn Attributes1014477
-Node: Defining Attributes1015583
-Ref: define_enum_attr1018102
-Node: Expressions1019137
-Node: Tagging Insns1025739
-Node: Attr Example1030092
-Node: Insn Lengths1032466
-Node: Constant Attributes1035525
-Node: Delay Slots1036694
-Node: Processor pipeline description1039918
-Ref: Processor pipeline description-Footnote-11057536
-Node: Conditional Execution1057858
-Node: Constant Definitions1060711
-Ref: define_enum1064502
-Node: Iterators1064990
-Node: Mode Iterators1065437
-Node: Defining Mode Iterators1066415
-Node: Substitutions1067909
-Node: Examples1070150
-Node: Code Iterators1071598
-Node: Target Macros1073855
-Node: Target Structure1076943
-Node: Driver1078212
-Node: Run-time Target1097598
-Node: Per-Function Data1107235
-Node: Storage Layout1110000
-Node: Type Layout1135234
-Node: Registers1149705
-Node: Register Basics1150679
-Node: Allocation Order1156184
-Node: Values in Registers1158630
-Node: Leaf Functions1166119
-Node: Stack Registers1168977
-Node: Register Classes1170249
-Node: Old Constraints1199396
-Node: Stack and Calling1206548
-Node: Frame Layout1207082
-Node: Exception Handling1217962
-Node: Stack Checking1224340
-Node: Frame Registers1229153
-Node: Elimination1236819
-Node: Stack Arguments1241048
-Node: Register Arguments1247945
-Node: Scalar Return1266725
-Node: Aggregate Return1272804
-Node: Caller Saves1277014
-Node: Function Entry1278192
-Node: Profiling1290820
-Node: Tail Calls1292519
-Node: Stack Smashing Protection1293885
-Node: Varargs1295510
-Node: Trampolines1302196
-Node: Library Calls1308843
-Node: Addressing Modes1313044
-Node: Anchored Addresses1332060
-Node: Condition Code1334709
-Node: CC0 Condition Codes1336838
-Node: MODE_CC Condition Codes1340084
-Node: Cond Exec Macros1346311
-Node: Costs1347288
-Node: Scheduling1363499
-Node: Sections1382420
-Node: PIC1397721
-Node: Assembler Format1399781
-Node: File Framework1400919
-Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1407808
-Node: Data Output1411073
-Node: Uninitialized Data1419422
-Node: Label Output1424986
-Node: Initialization1448058
-Node: Macros for Initialization1454020
-Node: Instruction Output1460743
-Node: Dispatch Tables1471245
-Node: Exception Region Output1475623
-Node: Alignment Output1481967
-Node: Debugging Info1486512
-Node: All Debuggers1487182
-Node: DBX Options1490037
-Node: DBX Hooks1495486
-Node: File Names and DBX1497412
-Node: SDB and DWARF1499524
-Node: VMS Debug1505371
-Node: Floating Point1505958
-Node: Mode Switching1510781
-Node: Target Attributes1514707
-Node: Emulated TLS1522619
-Node: MIPS Coprocessors1526009
-Node: PCH Target1527578
-Node: C++ ABI1529120
-Node: Named Address Spaces1533769
-Node: Misc1538708
-Ref: TARGET_SHIFT_TRUNCATION_MASK1546136
-Node: Host Config1589538
-Node: Host Common1590606
-Node: Filesystem1592985
-Node: Host Misc1597100
-Node: Fragments1599549
-Node: Target Fragment1600744
-Node: Host Fragment1606634
-Node: Collect21606874
-Node: Header Dirs1609510
-Node: Type Information1610933
-Node: GTY Options1613290
-Node: GGC Roots1624980
-Node: Files1625700
-Node: Invoking the garbage collector1628446
-Node: Troubleshooting1629949
-Node: Plugins1631025
-Node: LTO1647396
-Node: Funding1672442
-Node: GNU Project1674925
-Node: Copying1675574
-Node: GNU Free Documentation License1713105
-Node: Contributors1738245
-Node: Option Index1775117
-Node: Concept Index1775921
-
-End Tag Table
diff --git a/share/info/gdb.info b/share/info/gdb.info
deleted file mode 100644
index 5838703..0000000
--- a/share/info/gdb.info
+++ /dev/null
@@ -1,39097 +0,0 @@
-This is gdb.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gdb/gdb-7.3.x/gdb/doc/gdb.texinfo.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* Gdb: (gdb). The GNU debugger.
-END-INFO-DIR-ENTRY
-
- Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996,
-1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
-2010 Free Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with the
-Invariant Sections being "Free Software" and "Free Software Needs Free
-Documentation", with the Front-Cover Texts being "A GNU Manual," and
-with the Back-Cover Texts as in (a) below.
-
- (a) The FSF's Back-Cover Text is: "You are free to copy and modify
-this GNU Manual. Buying copies from GNU Press supports the FSF in
-developing GNU and promoting software freedom."
-
- This file documents the GNU debugger GDB.
-
- This is the Tenth Edition, of `Debugging with GDB: the GNU
-Source-Level Debugger' for GDB (GDB) Version 7.3.1-gg2.
-
- Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996,
-1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
-2010 Free Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with the
-Invariant Sections being "Free Software" and "Free Software Needs Free
-Documentation", with the Front-Cover Texts being "A GNU Manual," and
-with the Back-Cover Texts as in (a) below.
-
- (a) The FSF's Back-Cover Text is: "You are free to copy and modify
-this GNU Manual. Buying copies from GNU Press supports the FSF in
-developing GNU and promoting software freedom."
-
-
-File: gdb.info, Node: Top, Next: Summary, Prev: (dir), Up: (dir)
-
-Debugging with GDB
-******************
-
-This file describes GDB, the GNU symbolic debugger.
-
- This is the Tenth Edition, for GDB (GDB) Version 7.3.1-gg2.
-
- Copyright (C) 1988-2010 Free Software Foundation, Inc.
-
- This edition of the GDB manual is dedicated to the memory of Fred
-Fish. Fred was a long-standing contributor to GDB and to Free software
-in general. We will miss him.
-
-* Menu:
-
-* Summary:: Summary of GDB
-* Sample Session:: A sample GDB session
-
-* Invocation:: Getting in and out of GDB
-* Commands:: GDB commands
-* Running:: Running programs under GDB
-* Stopping:: Stopping and continuing
-* Reverse Execution:: Running programs backward
-* Process Record and Replay:: Recording inferior's execution and replaying it
-* Stack:: Examining the stack
-* Source:: Examining source files
-* Data:: Examining data
-* Optimized Code:: Debugging optimized code
-* Macros:: Preprocessor Macros
-* Tracepoints:: Debugging remote targets non-intrusively
-* Overlays:: Debugging programs that use overlays
-
-* Languages:: Using GDB with different languages
-
-* Symbols:: Examining the symbol table
-* Altering:: Altering execution
-* GDB Files:: GDB files
-* Targets:: Specifying a debugging target
-* Remote Debugging:: Debugging remote programs
-* Configurations:: Configuration-specific information
-* Controlling GDB:: Controlling GDB
-* Extending GDB:: Extending GDB
-* Interpreters:: Command Interpreters
-* TUI:: GDB Text User Interface
-* Emacs:: Using GDB under GNU Emacs
-* GDB/MI:: GDB's Machine Interface.
-* Annotations:: GDB's annotation interface.
-* JIT Interface:: Using the JIT debugging interface.
-
-* GDB Bugs:: Reporting bugs in GDB
-
-
-* Command Line Editing:: Command Line Editing
-* Using History Interactively:: Using History Interactively
-* In Memoriam:: In Memoriam
-* Formatting Documentation:: How to format and print GDB documentation
-* Installing GDB:: Installing GDB
-* Maintenance Commands:: Maintenance Commands
-* Remote Protocol:: GDB Remote Serial Protocol
-* Agent Expressions:: The GDB Agent Expression Mechanism
-* Target Descriptions:: How targets can describe themselves to
- GDB
-* Operating System Information:: Getting additional information from
- the operating system
-* Trace File Format:: GDB trace file format
-* Copying:: GNU General Public License says
- how you can copy and share GDB
-* GNU Free Documentation License:: The license for this documentation
-* Index:: Index
-
-
-File: gdb.info, Node: Summary, Next: Sample Session, Prev: Top, Up: Top
-
-Summary of GDB
-**************
-
-The purpose of a debugger such as GDB is to allow you to see what is
-going on "inside" another program while it executes--or what another
-program was doing at the moment it crashed.
-
- GDB can do four main kinds of things (plus other things in support of
-these) to help you catch bugs in the act:
-
- * Start your program, specifying anything that might affect its
- behavior.
-
- * Make your program stop on specified conditions.
-
- * Examine what has happened, when your program has stopped.
-
- * Change things in your program, so you can experiment with
- correcting the effects of one bug and go on to learn about another.
-
- You can use GDB to debug programs written in C and C++. For more
-information, see *note Supported Languages: Supported Languages. For
-more information, see *note C and C++: C.
-
- Support for D is partial. For information on D, see *note D: D.
-
- Support for Modula-2 is partial. For information on Modula-2, see
-*note Modula-2: Modula-2.
-
- Support for OpenCL C is partial. For information on OpenCL C, see
-*note OpenCL C: OpenCL C.
-
- Debugging Pascal programs which use sets, subranges, file variables,
-or nested functions does not currently work. GDB does not support
-entering expressions, printing values, or similar features using Pascal
-syntax.
-
- GDB can be used to debug programs written in Fortran, although it
-may be necessary to refer to some variables with a trailing underscore.
-
- GDB can be used to debug programs written in Objective-C, using
-either the Apple/NeXT or the GNU Objective-C runtime.
-
-* Menu:
-
-* Free Software:: Freely redistributable software
-* Contributors:: Contributors to GDB
-
-
-File: gdb.info, Node: Free Software, Next: Contributors, Up: Summary
-
-Free Software
-=============
-
-GDB is "free software", protected by the GNU General Public License
-(GPL). The GPL gives you the freedom to copy or adapt a licensed
-program--but every person getting a copy also gets with it the freedom
-to modify that copy (which means that they must get access to the
-source code), and the freedom to distribute further copies. Typical
-software companies use copyrights to limit your freedoms; the Free
-Software Foundation uses the GPL to preserve these freedoms.
-
- Fundamentally, the General Public License is a license which says
-that you have these freedoms and that you cannot take these freedoms
-away from anyone else.
-
-Free Software Needs Free Documentation
-======================================
-
-The biggest deficiency in the free software community today is not in
-the software--it is the lack of good free documentation that we can
-include with the free software. Many of our most important programs do
-not come with free reference manuals and free introductory texts.
-Documentation is an essential part of any software package; when an
-important free software package does not come with a free manual and a
-free tutorial, that is a major gap. We have many such gaps today.
-
- Consider Perl, for instance. The tutorial manuals that people
-normally use are non-free. How did this come about? Because the
-authors of those manuals published them with restrictive terms--no
-copying, no modification, source files not available--which exclude
-them from the free software world.
-
- That wasn't the first time this sort of thing happened, and it was
-far from the last. Many times we have heard a GNU user eagerly
-describe a manual that he is writing, his intended contribution to the
-community, only to learn that he had ruined everything by signing a
-publication contract to make it non-free.
-
- Free documentation, like free software, is a matter of freedom, not
-price. The problem with the non-free manual is not that publishers
-charge a price for printed copies--that in itself is fine. (The Free
-Software Foundation sells printed copies of manuals, too.) The problem
-is the restrictions on the use of the manual. Free manuals are
-available in source code form, and give you permission to copy and
-modify. Non-free manuals do not allow this.
-
- The criteria of freedom for a free manual are roughly the same as for
-free software. Redistribution (including the normal kinds of
-commercial redistribution) must be permitted, so that the manual can
-accompany every copy of the program, both on-line and on paper.
-
- Permission for modification of the technical content is crucial too.
-When people modify the software, adding or changing features, if they
-are conscientious they will change the manual too--so they can provide
-accurate and clear documentation for the modified program. A manual
-that leaves you no choice but to write a new manual to document a
-changed version of the program is not really available to our community.
-
- Some kinds of limits on the way modification is handled are
-acceptable. For example, requirements to preserve the original
-author's copyright notice, the distribution terms, or the list of
-authors, are ok. It is also no problem to require modified versions to
-include notice that they were modified. Even entire sections that may
-not be deleted or changed are acceptable, as long as they deal with
-nontechnical topics (like this one). These kinds of restrictions are
-acceptable because they don't obstruct the community's normal use of
-the manual.
-
- However, it must be possible to modify all the _technical_ content
-of the manual, and then distribute the result in all the usual media,
-through all the usual channels. Otherwise, the restrictions obstruct
-the use of the manual, it is not free, and we need another manual to
-replace it.
-
- Please spread the word about this issue. Our community continues to
-lose manuals to proprietary publishing. If we spread the word that
-free software needs free reference manuals and free tutorials, perhaps
-the next person who wants to contribute by writing documentation will
-realize, before it is too late, that only free manuals contribute to
-the free software community.
-
- If you are writing documentation, please insist on publishing it
-under the GNU Free Documentation License or another free documentation
-license. Remember that this decision requires your approval--you don't
-have to let the publisher decide. Some commercial publishers will use
-a free license if you insist, but they will not propose the option; it
-is up to you to raise the issue and say firmly that this is what you
-want. If the publisher you are dealing with refuses, please try other
-publishers. If you're not sure whether a proposed license is free,
-write to <licensing@gnu.org>.
-
- You can encourage commercial publishers to sell more free, copylefted
-manuals and tutorials by buying them, and particularly by buying copies
-from the publishers that paid for their writing or for major
-improvements. Meanwhile, try to avoid buying non-free documentation at
-all. Check the distribution terms of a manual before you buy it, and
-insist that whoever seeks your business must respect your freedom.
-Check the history of the book, and try to reward the publishers that
-have paid or pay the authors to work on it.
-
- The Free Software Foundation maintains a list of free documentation
-published by other publishers, at
-`http://www.fsf.org/doc/other-free-books.html'.
-
-
-File: gdb.info, Node: Contributors, Prev: Free Software, Up: Summary
-
-Contributors to GDB
-===================
-
-Richard Stallman was the original author of GDB, and of many other GNU
-programs. Many others have contributed to its development. This
-section attempts to credit major contributors. One of the virtues of
-free software is that everyone is free to contribute to it; with
-regret, we cannot actually acknowledge everyone here. The file
-`ChangeLog' in the GDB distribution approximates a blow-by-blow account.
-
- Changes much prior to version 2.0 are lost in the mists of time.
-
- _Plea:_ Additions to this section are particularly welcome. If you
- or your friends (or enemies, to be evenhanded) have been unfairly
- omitted from this list, we would like to add your names!
-
- So that they may not regard their many labors as thankless, we
-particularly thank those who shepherded GDB through major releases:
-Andrew Cagney (releases 6.3, 6.2, 6.1, 6.0, 5.3, 5.2, 5.1 and 5.0); Jim
-Blandy (release 4.18); Jason Molenda (release 4.17); Stan Shebs
-(release 4.14); Fred Fish (releases 4.16, 4.15, 4.13, 4.12, 4.11, 4.10,
-and 4.9); Stu Grossman and John Gilmore (releases 4.8, 4.7, 4.6, 4.5,
-and 4.4); John Gilmore (releases 4.3, 4.2, 4.1, 4.0, and 3.9); Jim
-Kingdon (releases 3.5, 3.4, and 3.3); and Randy Smith (releases 3.2,
-3.1, and 3.0).
-
- Richard Stallman, assisted at various times by Peter TerMaat, Chris
-Hanson, and Richard Mlynarik, handled releases through 2.8.
-
- Michael Tiemann is the author of most of the GNU C++ support in GDB,
-with significant additional contributions from Per Bothner and Daniel
-Berlin. James Clark wrote the GNU C++ demangler. Early work on C++
-was by Peter TerMaat (who also did much general update work leading to
-release 3.0).
-
- GDB uses the BFD subroutine library to examine multiple object-file
-formats; BFD was a joint project of David V. Henkel-Wallace, Rich
-Pixley, Steve Chamberlain, and John Gilmore.
-
- David Johnson wrote the original COFF support; Pace Willison did the
-original support for encapsulated COFF.
-
- Brent Benson of Harris Computer Systems contributed DWARF 2 support.
-
- Adam de Boor and Bradley Davis contributed the ISI Optimum V support.
-Per Bothner, Noboyuki Hikichi, and Alessandro Forin contributed MIPS
-support. Jean-Daniel Fekete contributed Sun 386i support. Chris
-Hanson improved the HP9000 support. Noboyuki Hikichi and Tomoyuki
-Hasei contributed Sony/News OS 3 support. David Johnson contributed
-Encore Umax support. Jyrki Kuoppala contributed Altos 3068 support.
-Jeff Law contributed HP PA and SOM support. Keith Packard contributed
-NS32K support. Doug Rabson contributed Acorn Risc Machine support.
-Bob Rusk contributed Harris Nighthawk CX-UX support. Chris Smith
-contributed Convex support (and Fortran debugging). Jonathan Stone
-contributed Pyramid support. Michael Tiemann contributed SPARC support.
-Tim Tucker contributed support for the Gould NP1 and Gould Powernode.
-Pace Willison contributed Intel 386 support. Jay Vosburgh contributed
-Symmetry support. Marko Mlinar contributed OpenRISC 1000 support.
-
- Andreas Schwab contributed M68K GNU/Linux support.
-
- Rich Schaefer and Peter Schauer helped with support of SunOS shared
-libraries.
-
- Jay Fenlason and Roland McGrath ensured that GDB and GAS agree about
-several machine instruction sets.
-
- Patrick Duval, Ted Goldstein, Vikram Koka and Glenn Engel helped
-develop remote debugging. Intel Corporation, Wind River Systems, AMD,
-and ARM contributed remote debugging modules for the i960, VxWorks,
-A29K UDI, and RDI targets, respectively.
-
- Brian Fox is the author of the readline libraries providing
-command-line editing and command history.
-
- Andrew Beers of SUNY Buffalo wrote the language-switching code, the
-Modula-2 support, and contributed the Languages chapter of this manual.
-
- Fred Fish wrote most of the support for Unix System Vr4. He also
-enhanced the command-completion support to cover C++ overloaded symbols.
-
- Hitachi America (now Renesas America), Ltd. sponsored the support for
-H8/300, H8/500, and Super-H processors.
-
- NEC sponsored the support for the v850, Vr4xxx, and Vr5xxx
-processors.
-
- Mitsubishi (now Renesas) sponsored the support for D10V, D30V, and
-M32R/D processors.
-
- Toshiba sponsored the support for the TX39 Mips processor.
-
- Matsushita sponsored the support for the MN10200 and MN10300
-processors.
-
- Fujitsu sponsored the support for SPARClite and FR30 processors.
-
- Kung Hsu, Jeff Law, and Rick Sladkey added support for hardware
-watchpoints.
-
- Michael Snyder added support for tracepoints.
-
- Stu Grossman wrote gdbserver.
-
- Jim Kingdon, Peter Schauer, Ian Taylor, and Stu Grossman made nearly
-innumerable bug fixes and cleanups throughout GDB.
-
- The following people at the Hewlett-Packard Company contributed
-support for the PA-RISC 2.0 architecture, HP-UX 10.20, 10.30, and 11.0
-(narrow mode), HP's implementation of kernel threads, HP's aC++
-compiler, and the Text User Interface (nee Terminal User Interface):
-Ben Krepp, Richard Title, John Bishop, Susan Macchia, Kathy Mann,
-Satish Pai, India Paul, Steve Rehrauer, and Elena Zannoni. Kim Haase
-provided HP-specific information in this manual.
-
- DJ Delorie ported GDB to MS-DOS, for the DJGPP project. Robert
-Hoehne made significant contributions to the DJGPP port.
-
- Cygnus Solutions has sponsored GDB maintenance and much of its
-development since 1991. Cygnus engineers who have worked on GDB
-fulltime include Mark Alexander, Jim Blandy, Per Bothner, Kevin
-Buettner, Edith Epstein, Chris Faylor, Fred Fish, Martin Hunt, Jim
-Ingham, John Gilmore, Stu Grossman, Kung Hsu, Jim Kingdon, John Metzler,
-Fernando Nasser, Geoffrey Noer, Dawn Perchik, Rich Pixley, Zdenek
-Radouch, Keith Seitz, Stan Shebs, David Taylor, and Elena Zannoni. In
-addition, Dave Brolley, Ian Carmichael, Steve Chamberlain, Nick Clifton,
-JT Conklin, Stan Cox, DJ Delorie, Ulrich Drepper, Frank Eigler, Doug
-Evans, Sean Fagan, David Henkel-Wallace, Richard Henderson, Jeff
-Holcomb, Jeff Law, Jim Lemke, Tom Lord, Bob Manson, Michael Meissner,
-Jason Merrill, Catherine Moore, Drew Moseley, Ken Raeburn, Gavin
-Romig-Koch, Rob Savoye, Jamie Smith, Mike Stump, Ian Taylor, Angela
-Thomas, Michael Tiemann, Tom Tromey, Ron Unrau, Jim Wilson, and David
-Zuhn have made contributions both large and small.
-
- Andrew Cagney, Fernando Nasser, and Elena Zannoni, while working for
-Cygnus Solutions, implemented the original GDB/MI interface.
-
- Jim Blandy added support for preprocessor macros, while working for
-Red Hat.
-
- Andrew Cagney designed GDB's architecture vector. Many people
-including Andrew Cagney, Stephane Carrez, Randolph Chung, Nick Duffek,
-Richard Henderson, Mark Kettenis, Grace Sainsbury, Kei Sakamoto,
-Yoshinori Sato, Michael Snyder, Andreas Schwab, Jason Thorpe, Corinna
-Vinschen, Ulrich Weigand, and Elena Zannoni, helped with the migration
-of old architectures to this new framework.
-
- Andrew Cagney completely re-designed and re-implemented GDB's
-unwinder framework, this consisting of a fresh new design featuring
-frame IDs, independent frame sniffers, and the sentinel frame. Mark
-Kettenis implemented the DWARF 2 unwinder, Jeff Johnston the libunwind
-unwinder, and Andrew Cagney the dummy, sentinel, tramp, and trad
-unwinders. The architecture-specific changes, each involving a
-complete rewrite of the architecture's frame code, were carried out by
-Jim Blandy, Joel Brobecker, Kevin Buettner, Andrew Cagney, Stephane
-Carrez, Randolph Chung, Orjan Friberg, Richard Henderson, Daniel
-Jacobowitz, Jeff Johnston, Mark Kettenis, Theodore A. Roth, Kei
-Sakamoto, Yoshinori Sato, Michael Snyder, Corinna Vinschen, and Ulrich
-Weigand.
-
- Christian Zankel, Ross Morley, Bob Wilson, and Maxim Grigoriev from
-Tensilica, Inc. contributed support for Xtensa processors. Others who
-have worked on the Xtensa port of GDB in the past include Steve Tjiang,
-John Newlin, and Scott Foehner.
-
- Michael Eager and staff of Xilinx, Inc., contributed support for the
-Xilinx MicroBlaze architecture.
-
-
-File: gdb.info, Node: Sample Session, Next: Invocation, Prev: Summary, Up: Top
-
-1 A Sample GDB Session
-**********************
-
-You can use this manual at your leisure to read all about GDB.
-However, a handful of commands are enough to get started using the
-debugger. This chapter illustrates those commands.
-
- One of the preliminary versions of GNU `m4' (a generic macro
-processor) exhibits the following bug: sometimes, when we change its
-quote strings from the default, the commands used to capture one macro
-definition within another stop working. In the following short `m4'
-session, we define a macro `foo' which expands to `0000'; we then use
-the `m4' built-in `defn' to define `bar' as the same thing. However,
-when we change the open quote string to `<QUOTE>' and the close quote
-string to `<UNQUOTE>', the same procedure fails to define a new synonym
-`baz':
-
- $ cd gnu/m4
- $ ./m4
- define(foo,0000)
-
- foo
- 0000
- define(bar,defn(`foo'))
-
- bar
- 0000
- changequote(<QUOTE>,<UNQUOTE>)
-
- define(baz,defn(<QUOTE>foo<UNQUOTE>))
- baz
- Ctrl-d
- m4: End of input: 0: fatal error: EOF in string
-
-Let us use GDB to try to see what is going on.
-
- $ gdb m4
- GDB is free software and you are welcome to distribute copies
- of it under certain conditions; type "show copying" to see
- the conditions.
- There is absolutely no warranty for GDB; type "show warranty"
- for details.
-
- GDB 7.3.1-gg2, Copyright 1999 Free Software Foundation, Inc...
- (gdb)
-
-GDB reads only enough symbol data to know where to find the rest when
-needed; as a result, the first prompt comes up very quickly. We now
-tell GDB to use a narrower display width than usual, so that examples
-fit in this manual.
-
- (gdb) set width 70
-
-We need to see how the `m4' built-in `changequote' works. Having
-looked at the source, we know the relevant subroutine is
-`m4_changequote', so we set a breakpoint there with the GDB `break'
-command.
-
- (gdb) break m4_changequote
- Breakpoint 1 at 0x62f4: file builtin.c, line 879.
-
-Using the `run' command, we start `m4' running under GDB control; as
-long as control does not reach the `m4_changequote' subroutine, the
-program runs as usual:
-
- (gdb) run
- Starting program: /work/Editorial/gdb/gnu/m4/m4
- define(foo,0000)
-
- foo
- 0000
-
-To trigger the breakpoint, we call `changequote'. GDB suspends
-execution of `m4', displaying information about the context where it
-stops.
-
- changequote(<QUOTE>,<UNQUOTE>)
-
- Breakpoint 1, m4_changequote (argc=3, argv=0x33c70)
- at builtin.c:879
- 879 if (bad_argc(TOKEN_DATA_TEXT(argv[0]),argc,1,3))
-
-Now we use the command `n' (`next') to advance execution to the next
-line of the current function.
-
- (gdb) n
- 882 set_quotes((argc >= 2) ? TOKEN_DATA_TEXT(argv[1])\
- : nil,
-
-`set_quotes' looks like a promising subroutine. We can go into it by
-using the command `s' (`step') instead of `next'. `step' goes to the
-next line to be executed in _any_ subroutine, so it steps into
-`set_quotes'.
-
- (gdb) s
- set_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "<UNQUOTE>")
- at input.c:530
- 530 if (lquote != def_lquote)
-
-The display that shows the subroutine where `m4' is now suspended (and
-its arguments) is called a stack frame display. It shows a summary of
-the stack. We can use the `backtrace' command (which can also be
-spelled `bt'), to see where we are in the stack as a whole: the
-`backtrace' command displays a stack frame for each active subroutine.
-
- (gdb) bt
- #0 set_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "<UNQUOTE>")
- at input.c:530
- #1 0x6344 in m4_changequote (argc=3, argv=0x33c70)
- at builtin.c:882
- #2 0x8174 in expand_macro (sym=0x33320) at macro.c:242
- #3 0x7a88 in expand_token (obs=0x0, t=209696, td=0xf7fffa30)
- at macro.c:71
- #4 0x79dc in expand_input () at macro.c:40
- #5 0x2930 in main (argc=0, argv=0xf7fffb20) at m4.c:195
-
-We step through a few more lines to see what happens. The first two
-times, we can use `s'; the next two times we use `n' to avoid falling
-into the `xstrdup' subroutine.
-
- (gdb) s
- 0x3b5c 532 if (rquote != def_rquote)
- (gdb) s
- 0x3b80 535 lquote = (lq == nil || *lq == '\0') ? \
- def_lquote : xstrdup(lq);
- (gdb) n
- 536 rquote = (rq == nil || *rq == '\0') ? def_rquote\
- : xstrdup(rq);
- (gdb) n
- 538 len_lquote = strlen(rquote);
-
-The last line displayed looks a little odd; we can examine the variables
-`lquote' and `rquote' to see if they are in fact the new left and right
-quotes we specified. We use the command `p' (`print') to see their
-values.
-
- (gdb) p lquote
- $1 = 0x35d40 "<QUOTE>"
- (gdb) p rquote
- $2 = 0x35d50 "<UNQUOTE>"
-
-`lquote' and `rquote' are indeed the new left and right quotes. To
-look at some context, we can display ten lines of source surrounding
-the current line with the `l' (`list') command.
-
- (gdb) l
- 533 xfree(rquote);
- 534
- 535 lquote = (lq == nil || *lq == '\0') ? def_lquote\
- : xstrdup (lq);
- 536 rquote = (rq == nil || *rq == '\0') ? def_rquote\
- : xstrdup (rq);
- 537
- 538 len_lquote = strlen(rquote);
- 539 len_rquote = strlen(lquote);
- 540 }
- 541
- 542 void
-
-Let us step past the two lines that set `len_lquote' and `len_rquote',
-and then examine the values of those variables.
-
- (gdb) n
- 539 len_rquote = strlen(lquote);
- (gdb) n
- 540 }
- (gdb) p len_lquote
- $3 = 9
- (gdb) p len_rquote
- $4 = 7
-
-That certainly looks wrong, assuming `len_lquote' and `len_rquote' are
-meant to be the lengths of `lquote' and `rquote' respectively. We can
-set them to better values using the `p' command, since it can print the
-value of any expression--and that expression can include subroutine
-calls and assignments.
-
- (gdb) p len_lquote=strlen(lquote)
- $5 = 7
- (gdb) p len_rquote=strlen(rquote)
- $6 = 9
-
-Is that enough to fix the problem of using the new quotes with the `m4'
-built-in `defn'? We can allow `m4' to continue executing with the `c'
-(`continue') command, and then try the example that caused trouble
-initially:
-
- (gdb) c
- Continuing.
-
- define(baz,defn(<QUOTE>foo<UNQUOTE>))
-
- baz
- 0000
-
-Success! The new quotes now work just as well as the default ones. The
-problem seems to have been just the two typos defining the wrong
-lengths. We allow `m4' exit by giving it an EOF as input:
-
- Ctrl-d
- Program exited normally.
-
-The message `Program exited normally.' is from GDB; it indicates `m4'
-has finished executing. We can end our GDB session with the GDB `quit'
-command.
-
- (gdb) quit
-
-
-File: gdb.info, Node: Invocation, Next: Commands, Prev: Sample Session, Up: Top
-
-2 Getting In and Out of GDB
-***************************
-
-This chapter discusses how to start GDB, and how to get out of it. The
-essentials are:
- * type `gdb' to start GDB.
-
- * type `quit' or `Ctrl-d' to exit.
-
-* Menu:
-
-* Invoking GDB:: How to start GDB
-* Quitting GDB:: How to quit GDB
-* Shell Commands:: How to use shell commands inside GDB
-* Logging Output:: How to log GDB's output to a file
-
-
-File: gdb.info, Node: Invoking GDB, Next: Quitting GDB, Up: Invocation
-
-2.1 Invoking GDB
-================
-
-Invoke GDB by running the program `gdb'. Once started, GDB reads
-commands from the terminal until you tell it to exit.
-
- You can also run `gdb' with a variety of arguments and options, to
-specify more of your debugging environment at the outset.
-
- The command-line options described here are designed to cover a
-variety of situations; in some environments, some of these options may
-effectively be unavailable.
-
- The most usual way to start GDB is with one argument, specifying an
-executable program:
-
- gdb PROGRAM
-
-You can also start with both an executable program and a core file
-specified:
-
- gdb PROGRAM CORE
-
- You can, instead, specify a process ID as a second argument, if you
-want to debug a running process:
-
- gdb PROGRAM 1234
-
-would attach GDB to process `1234' (unless you also have a file named
-`1234'; GDB does check for a core file first).
-
- Taking advantage of the second command-line argument requires a
-fairly complete operating system; when you use GDB as a remote debugger
-attached to a bare board, there may not be any notion of "process", and
-there is often no way to get a core dump. GDB will warn you if it is
-unable to attach or to read core dumps.
-
- You can optionally have `gdb' pass any arguments after the
-executable file to the inferior using `--args'. This option stops
-option processing.
- gdb --args gcc -O2 -c foo.c
- This will cause `gdb' to debug `gcc', and to set `gcc''s
-command-line arguments (*note Arguments::) to `-O2 -c foo.c'.
-
- You can run `gdb' without printing the front material, which
-describes GDB's non-warranty, by specifying `-silent':
-
- gdb -silent
-
-You can further control how GDB starts up by using command-line
-options. GDB itself can remind you of the options available.
-
-Type
-
- gdb -help
-
-to display all available options and briefly describe their use (`gdb
--h' is a shorter equivalent).
-
- All options and command line arguments you give are processed in
-sequential order. The order makes a difference when the `-x' option is
-used.
-
-* Menu:
-
-* File Options:: Choosing files
-* Mode Options:: Choosing modes
-* Startup:: What GDB does during startup
-
-
-File: gdb.info, Node: File Options, Next: Mode Options, Up: Invoking GDB
-
-2.1.1 Choosing Files
---------------------
-
-When GDB starts, it reads any arguments other than options as
-specifying an executable file and core file (or process ID). This is
-the same as if the arguments were specified by the `-se' and `-c' (or
-`-p') options respectively. (GDB reads the first argument that does
-not have an associated option flag as equivalent to the `-se' option
-followed by that argument; and the second argument that does not have
-an associated option flag, if any, as equivalent to the `-c'/`-p'
-option followed by that argument.) If the second argument begins with
-a decimal digit, GDB will first attempt to attach to it as a process,
-and if that fails, attempt to open it as a corefile. If you have a
-corefile whose name begins with a digit, you can prevent GDB from
-treating it as a pid by prefixing it with `./', e.g. `./12345'.
-
- If GDB has not been configured to included core file support, such
-as for most embedded targets, then it will complain about a second
-argument and ignore it.
-
- Many options have both long and short forms; both are shown in the
-following list. GDB also recognizes the long forms if you truncate
-them, so long as enough of the option is present to be unambiguous.
-(If you prefer, you can flag option arguments with `--' rather than
-`-', though we illustrate the more usual convention.)
-
-`-symbols FILE'
-`-s FILE'
- Read symbol table from file FILE.
-
-`-exec FILE'
-`-e FILE'
- Use file FILE as the executable file to execute when appropriate,
- and for examining pure data in conjunction with a core dump.
-
-`-se FILE'
- Read symbol table from file FILE and use it as the executable file.
-
-`-core FILE'
-`-c FILE'
- Use file FILE as a core dump to examine.
-
-`-pid NUMBER'
-`-p NUMBER'
- Connect to process ID NUMBER, as with the `attach' command.
-
-`-command FILE'
-`-x FILE'
- Execute commands from file FILE. The contents of this file is
- evaluated exactly as the `source' command would. *Note Command
- files: Command Files.
-
-`-eval-command COMMAND'
-`-ex COMMAND'
- Execute a single GDB command.
-
- This option may be used multiple times to call multiple commands.
- It may also be interleaved with `-command' as required.
-
- gdb -ex 'target sim' -ex 'load' \
- -x setbreakpoints -ex 'run' a.out
-
-`-directory DIRECTORY'
-`-d DIRECTORY'
- Add DIRECTORY to the path to search for source and script files.
-
-`-r'
-`-readnow'
- Read each symbol file's entire symbol table immediately, rather
- than the default, which is to read it incrementally as it is
- needed. This makes startup slower, but makes future operations
- faster.
-
-
-
-File: gdb.info, Node: Mode Options, Next: Startup, Prev: File Options, Up: Invoking GDB
-
-2.1.2 Choosing Modes
---------------------
-
-You can run GDB in various alternative modes--for example, in batch
-mode or quiet mode.
-
-`-nx'
-`-n'
- Do not execute commands found in any initialization files.
- Normally, GDB executes the commands in these files after all the
- command options and arguments have been processed. *Note Command
- Files: Command Files.
-
-`-quiet'
-`-silent'
-`-q'
- "Quiet". Do not print the introductory and copyright messages.
- These messages are also suppressed in batch mode.
-
-`-batch'
- Run in batch mode. Exit with status `0' after processing all the
- command files specified with `-x' (and all commands from
- initialization files, if not inhibited with `-n'). Exit with
- nonzero status if an error occurs in executing the GDB commands in
- the command files. Batch mode also disables pagination, sets
- unlimited terminal width and height *note Screen Size::, and acts
- as if `set confirm off' were in effect (*note Messages/Warnings::).
-
- Batch mode may be useful for running GDB as a filter, for example
- to download and run a program on another computer; in order to
- make this more useful, the message
-
- Program exited normally.
-
- (which is ordinarily issued whenever a program running under GDB
- control terminates) is not issued when running in batch mode.
-
-`-batch-silent'
- Run in batch mode exactly like `-batch', but totally silently. All
- GDB output to `stdout' is prevented (`stderr' is unaffected).
- This is much quieter than `-silent' and would be useless for an
- interactive session.
-
- This is particularly useful when using targets that give `Loading
- section' messages, for example.
-
- Note that targets that give their output via GDB, as opposed to
- writing directly to `stdout', will also be made silent.
-
-`-return-child-result'
- The return code from GDB will be the return code from the child
- process (the process being debugged), with the following
- exceptions:
-
- * GDB exits abnormally. E.g., due to an incorrect argument or
- an internal error. In this case the exit code is the same as
- it would have been without `-return-child-result'.
-
- * The user quits with an explicit value. E.g., `quit 1'.
-
- * The child process never runs, or is not allowed to terminate,
- in which case the exit code will be -1.
-
- This option is useful in conjunction with `-batch' or
- `-batch-silent', when GDB is being used as a remote program loader
- or simulator interface.
-
-`-nowindows'
-`-nw'
- "No windows". If GDB comes with a graphical user interface (GUI)
- built in, then this option tells GDB to only use the command-line
- interface. If no GUI is available, this option has no effect.
-
-`-windows'
-`-w'
- If GDB includes a GUI, then this option requires it to be used if
- possible.
-
-`-cd DIRECTORY'
- Run GDB using DIRECTORY as its working directory, instead of the
- current directory.
-
-`-data-directory DIRECTORY'
- Run GDB using DIRECTORY as its data directory. The data directory
- is where GDB searches for its auxiliary files. *Note Data Files::.
-
-`-fullname'
-`-f'
- GNU Emacs sets this option when it runs GDB as a subprocess. It
- tells GDB to output the full file name and line number in a
- standard, recognizable fashion each time a stack frame is
- displayed (which includes each time your program stops). This
- recognizable format looks like two `\032' characters, followed by
- the file name, line number and character position separated by
- colons, and a newline. The Emacs-to-GDB interface program uses
- the two `\032' characters as a signal to display the source code
- for the frame.
-
-`-epoch'
- The Epoch Emacs-GDB interface sets this option when it runs GDB as
- a subprocess. It tells GDB to modify its print routines so as to
- allow Epoch to display values of expressions in a separate window.
-
-`-annotate LEVEL'
- This option sets the "annotation level" inside GDB. Its effect is
- identical to using `set annotate LEVEL' (*note Annotations::).
- The annotation LEVEL controls how much information GDB prints
- together with its prompt, values of expressions, source lines, and
- other types of output. Level 0 is the normal, level 1 is for use
- when GDB is run as a subprocess of GNU Emacs, level 3 is the
- maximum annotation suitable for programs that control GDB, and
- level 2 has been deprecated.
-
- The annotation mechanism has largely been superseded by GDB/MI
- (*note GDB/MI::).
-
-`--args'
- Change interpretation of command line so that arguments following
- the executable file are passed as command line arguments to the
- inferior. This option stops option processing.
-
-`-baud BPS'
-`-b BPS'
- Set the line speed (baud rate or bits per second) of any serial
- interface used by GDB for remote debugging.
-
-`-l TIMEOUT'
- Set the timeout (in seconds) of any communication used by GDB for
- remote debugging.
-
-`-tty DEVICE'
-`-t DEVICE'
- Run using DEVICE for your program's standard input and output.
-
-`-tui'
- Activate the "Text User Interface" when starting. The Text User
- Interface manages several text windows on the terminal, showing
- source, assembly, registers and GDB command outputs (*note GDB
- Text User Interface: TUI.). Alternatively, the Text User
- Interface can be enabled by invoking the program `gdbtui'. Do not
- use this option if you run GDB from Emacs (*note Using GDB under
- GNU Emacs: Emacs.).
-
-`-interpreter INTERP'
- Use the interpreter INTERP for interface with the controlling
- program or device. This option is meant to be set by programs
- which communicate with GDB using it as a back end. *Note Command
- Interpreters: Interpreters.
-
- `--interpreter=mi' (or `--interpreter=mi2') causes GDB to use the
- "GDB/MI interface" (*note The GDB/MI Interface: GDB/MI.) included
- since GDB version 6.0. The previous GDB/MI interface, included in
- GDB version 5.3 and selected with `--interpreter=mi1', is
- deprecated. Earlier GDB/MI interfaces are no longer supported.
-
-`-write'
- Open the executable and core files for both reading and writing.
- This is equivalent to the `set write on' command inside GDB (*note
- Patching::).
-
-`-statistics'
- This option causes GDB to print statistics about time and memory
- usage after it completes each command and returns to the prompt.
-
-`-version'
- This option causes GDB to print its version number and no-warranty
- blurb, and exit.
-
-`-disable-gdb-index'
- This option causes GDB to avoid using the `.gdb_index' ELF
- section, even if present in the executable or a shared library.
- This section improves the speed of loading of debug information.
- This option is present as an escape hatch in case there is a
- problem with the contents of this section.
-
-
-
-File: gdb.info, Node: Startup, Prev: Mode Options, Up: Invoking GDB
-
-2.1.3 What GDB Does During Startup
-----------------------------------
-
-Here's the description of what GDB does during session startup:
-
- 1. Sets up the command interpreter as specified by the command line
- (*note interpreter: Mode Options.).
-
- 2. Reads the system-wide "init file" (if `--with-system-gdbinit' was
- used when building GDB; *note System-wide configuration and
- settings: System-wide configuration.) and executes all the
- commands in that file.
-
- 3. Reads the init file (if any) in your home directory(1) and
- executes all the commands in that file.
-
- 4. Processes command line options and operands.
-
- 5. Reads and executes the commands from init file (if any) in the
- current working directory. This is only done if the current
- directory is different from your home directory. Thus, you can
- have more than one init file, one generic in your home directory,
- and another, specific to the program you are debugging, in the
- directory where you invoke GDB.
-
- 6. If the command line specified a program to debug, or a process to
- attach to, or a core file, GDB loads any auto-loaded scripts
- provided for the program or for its loaded shared libraries.
- *Note Auto-loading::.
-
- If you wish to disable the auto-loading during startup, you must
- do something like the following:
-
- $ gdb -ex "set auto-load-scripts off" -ex "file myprogram"
-
- The following does not work because the auto-loading is turned off
- too late:
-
- $ gdb -ex "set auto-load-scripts off" myprogram
-
- 7. Reads command files specified by the `-x' option. *Note Command
- Files::, for more details about GDB command files.
-
- 8. Reads the command history recorded in the "history file". *Note
- Command History::, for more details about the command history and
- the files where GDB records it.
-
- Init files use the same syntax as "command files" (*note Command
-Files::) and are processed by GDB in the same way. The init file in
-your home directory can set options (such as `set complaints') that
-affect subsequent processing of command line options and operands.
-Init files are not executed if you use the `-nx' option (*note Choosing
-Modes: Mode Options.).
-
- To display the list of init files loaded by gdb at startup, you can
-use `gdb --help'.
-
- The GDB init files are normally called `.gdbinit'. The DJGPP port
-of GDB uses the name `gdb.ini', due to the limitations of file names
-imposed by DOS filesystems. The Windows ports of GDB use the standard
-name, but if they find a `gdb.ini' file, they warn you about that and
-suggest to rename the file to the standard name.
-
- ---------- Footnotes ----------
-
- (1) On DOS/Windows systems, the home directory is the one pointed to
-by the `HOME' environment variable.
-
-
-File: gdb.info, Node: Quitting GDB, Next: Shell Commands, Prev: Invoking GDB, Up: Invocation
-
-2.2 Quitting GDB
-================
-
-`quit [EXPRESSION]'
-`q'
- To exit GDB, use the `quit' command (abbreviated `q'), or type an
- end-of-file character (usually `Ctrl-d'). If you do not supply
- EXPRESSION, GDB will terminate normally; otherwise it will
- terminate using the result of EXPRESSION as the error code.
-
- An interrupt (often `Ctrl-c') does not exit from GDB, but rather
-terminates the action of any GDB command that is in progress and
-returns to GDB command level. It is safe to type the interrupt
-character at any time because GDB does not allow it to take effect
-until a time when it is safe.
-
- If you have been using GDB to control an attached process or device,
-you can release it with the `detach' command (*note Debugging an
-Already-running Process: Attach.).
-
-
-File: gdb.info, Node: Shell Commands, Next: Logging Output, Prev: Quitting GDB, Up: Invocation
-
-2.3 Shell Commands
-==================
-
-If you need to execute occasional shell commands during your debugging
-session, there is no need to leave or suspend GDB; you can just use the
-`shell' command.
-
-`shell COMMAND STRING'
- Invoke a standard shell to execute COMMAND STRING. If it exists,
- the environment variable `SHELL' determines which shell to run.
- Otherwise GDB uses the default shell (`/bin/sh' on Unix systems,
- `COMMAND.COM' on MS-DOS, etc.).
-
- The utility `make' is often needed in development environments. You
-do not have to use the `shell' command for this purpose in GDB:
-
-`make MAKE-ARGS'
- Execute the `make' program with the specified arguments. This is
- equivalent to `shell make MAKE-ARGS'.
-
-
-File: gdb.info, Node: Logging Output, Prev: Shell Commands, Up: Invocation
-
-2.4 Logging Output
-==================
-
-You may want to save the output of GDB commands to a file. There are
-several commands to control GDB's logging.
-
-`set logging on'
- Enable logging.
-
-`set logging off'
- Disable logging.
-
-`set logging file FILE'
- Change the name of the current logfile. The default logfile is
- `gdb.txt'.
-
-`set logging overwrite [on|off]'
- By default, GDB will append to the logfile. Set `overwrite' if
- you want `set logging on' to overwrite the logfile instead.
-
-`set logging redirect [on|off]'
- By default, GDB output will go to both the terminal and the
- logfile. Set `redirect' if you want output to go only to the log
- file.
-
-`show logging'
- Show the current values of the logging settings.
-
-
-File: gdb.info, Node: Commands, Next: Running, Prev: Invocation, Up: Top
-
-3 GDB Commands
-**************
-
-You can abbreviate a GDB command to the first few letters of the command
-name, if that abbreviation is unambiguous; and you can repeat certain
-GDB commands by typing just <RET>. You can also use the <TAB> key to
-get GDB to fill out the rest of a word in a command (or to show you the
-alternatives available, if there is more than one possibility).
-
-* Menu:
-
-* Command Syntax:: How to give commands to GDB
-* Completion:: Command completion
-* Help:: How to ask GDB for help
-
-
-File: gdb.info, Node: Command Syntax, Next: Completion, Up: Commands
-
-3.1 Command Syntax
-==================
-
-A GDB command is a single line of input. There is no limit on how long
-it can be. It starts with a command name, which is followed by
-arguments whose meaning depends on the command name. For example, the
-command `step' accepts an argument which is the number of times to
-step, as in `step 5'. You can also use the `step' command with no
-arguments. Some commands do not allow any arguments.
-
- GDB command names may always be truncated if that abbreviation is
-unambiguous. Other possible command abbreviations are listed in the
-documentation for individual commands. In some cases, even ambiguous
-abbreviations are allowed; for example, `s' is specially defined as
-equivalent to `step' even though there are other commands whose names
-start with `s'. You can test abbreviations by using them as arguments
-to the `help' command.
-
- A blank line as input to GDB (typing just <RET>) means to repeat the
-previous command. Certain commands (for example, `run') will not
-repeat this way; these are commands whose unintentional repetition
-might cause trouble and which you are unlikely to want to repeat.
-User-defined commands can disable this feature; see *note dont-repeat:
-Define.
-
- The `list' and `x' commands, when you repeat them with <RET>,
-construct new arguments rather than repeating exactly as typed. This
-permits easy scanning of source or memory.
-
- GDB can also use <RET> in another way: to partition lengthy output,
-in a way similar to the common utility `more' (*note Screen Size:
-Screen Size.). Since it is easy to press one <RET> too many in this
-situation, GDB disables command repetition after any command that
-generates this sort of display.
-
- Any text from a `#' to the end of the line is a comment; it does
-nothing. This is useful mainly in command files (*note Command Files:
-Command Files.).
-
- The `Ctrl-o' binding is useful for repeating a complex sequence of
-commands. This command accepts the current line, like <RET>, and then
-fetches the next line relative to the current line from the history for
-editing.
-
-
-File: gdb.info, Node: Completion, Next: Help, Prev: Command Syntax, Up: Commands
-
-3.2 Command Completion
-======================
-
-GDB can fill in the rest of a word in a command for you, if there is
-only one possibility; it can also show you what the valid possibilities
-are for the next word in a command, at any time. This works for GDB
-commands, GDB subcommands, and the names of symbols in your program.
-
- Press the <TAB> key whenever you want GDB to fill out the rest of a
-word. If there is only one possibility, GDB fills in the word, and
-waits for you to finish the command (or press <RET> to enter it). For
-example, if you type
-
- (gdb) info bre <TAB>
-
-GDB fills in the rest of the word `breakpoints', since that is the only
-`info' subcommand beginning with `bre':
-
- (gdb) info breakpoints
-
-You can either press <RET> at this point, to run the `info breakpoints'
-command, or backspace and enter something else, if `breakpoints' does
-not look like the command you expected. (If you were sure you wanted
-`info breakpoints' in the first place, you might as well just type
-<RET> immediately after `info bre', to exploit command abbreviations
-rather than command completion).
-
- If there is more than one possibility for the next word when you
-press <TAB>, GDB sounds a bell. You can either supply more characters
-and try again, or just press <TAB> a second time; GDB displays all the
-possible completions for that word. For example, you might want to set
-a breakpoint on a subroutine whose name begins with `make_', but when
-you type `b make_<TAB>' GDB just sounds the bell. Typing <TAB> again
-displays all the function names in your program that begin with those
-characters, for example:
-
- (gdb) b make_ <TAB>
-GDB sounds bell; press <TAB> again, to see:
- make_a_section_from_file make_environ
- make_abs_section make_function_type
- make_blockvector make_pointer_type
- make_cleanup make_reference_type
- make_command make_symbol_completion_list
- (gdb) b make_
-
-After displaying the available possibilities, GDB copies your partial
-input (`b make_' in the example) so you can finish the command.
-
- If you just want to see the list of alternatives in the first place,
-you can press `M-?' rather than pressing <TAB> twice. `M-?' means
-`<META> ?'. You can type this either by holding down a key designated
-as the <META> shift on your keyboard (if there is one) while typing
-`?', or as <ESC> followed by `?'.
-
- Sometimes the string you need, while logically a "word", may contain
-parentheses or other characters that GDB normally excludes from its
-notion of a word. To permit word completion to work in this situation,
-you may enclose words in `'' (single quote marks) in GDB commands.
-
- The most likely situation where you might need this is in typing the
-name of a C++ function. This is because C++ allows function
-overloading (multiple definitions of the same function, distinguished
-by argument type). For example, when you want to set a breakpoint you
-may need to distinguish whether you mean the version of `name' that
-takes an `int' parameter, `name(int)', or the version that takes a
-`float' parameter, `name(float)'. To use the word-completion
-facilities in this situation, type a single quote `'' at the beginning
-of the function name. This alerts GDB that it may need to consider
-more information than usual when you press <TAB> or `M-?' to request
-word completion:
-
- (gdb) b 'bubble( M-?
- bubble(double,double) bubble(int,int)
- (gdb) b 'bubble(
-
- In some cases, GDB can tell that completing a name requires using
-quotes. When this happens, GDB inserts the quote for you (while
-completing as much as it can) if you do not type the quote in the first
-place:
-
- (gdb) b bub <TAB>
-GDB alters your input line to the following, and rings a bell:
- (gdb) b 'bubble(
-
-In general, GDB can tell that a quote is needed (and inserts it) if you
-have not yet started typing the argument list when you ask for
-completion on an overloaded symbol.
-
- For more information about overloaded functions, see *note C++
-Expressions: C Plus Plus Expressions. You can use the command `set
-overload-resolution off' to disable overload resolution; see *note GDB
-Features for C++: Debugging C Plus Plus.
-
- When completing in an expression which looks up a field in a
-structure, GDB also tries(1) to limit completions to the field names
-available in the type of the left-hand-side:
-
- (gdb) p gdb_stdout.M-?
- magic to_delete to_fputs to_put to_rewind
- to_data to_flush to_isatty to_read to_write
-
-This is because the `gdb_stdout' is a variable of the type `struct
-ui_file' that is defined in GDB sources as follows:
-
- struct ui_file
- {
- int *magic;
- ui_file_flush_ftype *to_flush;
- ui_file_write_ftype *to_write;
- ui_file_fputs_ftype *to_fputs;
- ui_file_read_ftype *to_read;
- ui_file_delete_ftype *to_delete;
- ui_file_isatty_ftype *to_isatty;
- ui_file_rewind_ftype *to_rewind;
- ui_file_put_ftype *to_put;
- void *to_data;
- }
-
- ---------- Footnotes ----------
-
- (1) The completer can be confused by certain kinds of invalid
-expressions. Also, it only examines the static type of the expression,
-not the dynamic type.
-
-
-File: gdb.info, Node: Help, Prev: Completion, Up: Commands
-
-3.3 Getting Help
-================
-
-You can always ask GDB itself for information on its commands, using
-the command `help'.
-
-`help'
-`h'
- You can use `help' (abbreviated `h') with no arguments to display
- a short list of named classes of commands:
-
- (gdb) help
- List of classes of commands:
-
- aliases -- Aliases of other commands
- breakpoints -- Making program stop at certain points
- data -- Examining data
- files -- Specifying and examining files
- internals -- Maintenance commands
- obscure -- Obscure features
- running -- Running the program
- stack -- Examining the stack
- status -- Status inquiries
- support -- Support facilities
- tracepoints -- Tracing of program execution without
- stopping the program
- user-defined -- User-defined commands
-
- Type "help" followed by a class name for a list of
- commands in that class.
- Type "help" followed by command name for full
- documentation.
- Command name abbreviations are allowed if unambiguous.
- (gdb)
-
-`help CLASS'
- Using one of the general help classes as an argument, you can get a
- list of the individual commands in that class. For example, here
- is the help display for the class `status':
-
- (gdb) help status
- Status inquiries.
-
- List of commands:
-
- info -- Generic command for showing things
- about the program being debugged
- show -- Generic command for showing things
- about the debugger
-
- Type "help" followed by command name for full
- documentation.
- Command name abbreviations are allowed if unambiguous.
- (gdb)
-
-`help COMMAND'
- With a command name as `help' argument, GDB displays a short
- paragraph on how to use that command.
-
-`apropos ARGS'
- The `apropos' command searches through all of the GDB commands,
- and their documentation, for the regular expression specified in
- ARGS. It prints out all matches found. For example:
-
- apropos reload
-
- results in:
-
- set symbol-reloading -- Set dynamic symbol table reloading
- multiple times in one run
- show symbol-reloading -- Show dynamic symbol table reloading
- multiple times in one run
-
-`complete ARGS'
- The `complete ARGS' command lists all the possible completions for
- the beginning of a command. Use ARGS to specify the beginning of
- the command you want completed. For example:
-
- complete i
-
- results in:
-
- if
- ignore
- info
- inspect
-
- This is intended for use by GNU Emacs.
-
- In addition to `help', you can use the GDB commands `info' and
-`show' to inquire about the state of your program, or the state of GDB
-itself. Each command supports many topics of inquiry; this manual
-introduces each of them in the appropriate context. The listings under
-`info' and under `show' in the Index point to all the sub-commands.
-*Note Index::.
-
-`info'
- This command (abbreviated `i') is for describing the state of your
- program. For example, you can show the arguments passed to a
- function with `info args', list the registers currently in use
- with `info registers', or list the breakpoints you have set with
- `info breakpoints'. You can get a complete list of the `info'
- sub-commands with `help info'.
-
-`set'
- You can assign the result of an expression to an environment
- variable with `set'. For example, you can set the GDB prompt to a
- $-sign with `set prompt $'.
-
-`show'
- In contrast to `info', `show' is for describing the state of GDB
- itself. You can change most of the things you can `show', by
- using the related command `set'; for example, you can control what
- number system is used for displays with `set radix', or simply
- inquire which is currently in use with `show radix'.
-
- To display all the settable parameters and their current values,
- you can use `show' with no arguments; you may also use `info set'.
- Both commands produce the same display.
-
- Here are three miscellaneous `show' subcommands, all of which are
-exceptional in lacking corresponding `set' commands:
-
-`show version'
- Show what version of GDB is running. You should include this
- information in GDB bug-reports. If multiple versions of GDB are
- in use at your site, you may need to determine which version of
- GDB you are running; as GDB evolves, new commands are introduced,
- and old ones may wither away. Also, many system vendors ship
- variant versions of GDB, and there are variant versions of GDB in
- GNU/Linux distributions as well. The version number is the same
- as the one announced when you start GDB.
-
-`show copying'
-`info copying'
- Display information about permission for copying GDB.
-
-`show warranty'
-`info warranty'
- Display the GNU "NO WARRANTY" statement, or a warranty, if your
- version of GDB comes with one.
-
-
-
-File: gdb.info, Node: Running, Next: Stopping, Prev: Commands, Up: Top
-
-4 Running Programs Under GDB
-****************************
-
-When you run a program under GDB, you must first generate debugging
-information when you compile it.
-
- You may start GDB with its arguments, if any, in an environment of
-your choice. If you are doing native debugging, you may redirect your
-program's input and output, debug an already running process, or kill a
-child process.
-
-* Menu:
-
-* Compilation:: Compiling for debugging
-* Starting:: Starting your program
-* Arguments:: Your program's arguments
-* Environment:: Your program's environment
-
-* Working Directory:: Your program's working directory
-* Input/Output:: Your program's input and output
-* Attach:: Debugging an already-running process
-* Kill Process:: Killing the child process
-
-* Inferiors and Programs:: Debugging multiple inferiors and programs
-* Threads:: Debugging programs with multiple threads
-* Forks:: Debugging forks
-* Checkpoint/Restart:: Setting a _bookmark_ to return to later
-
-
-File: gdb.info, Node: Compilation, Next: Starting, Up: Running
-
-4.1 Compiling for Debugging
-===========================
-
-In order to debug a program effectively, you need to generate debugging
-information when you compile it. This debugging information is stored
-in the object file; it describes the data type of each variable or
-function and the correspondence between source line numbers and
-addresses in the executable code.
-
- To request debugging information, specify the `-g' option when you
-run the compiler.
-
- Programs that are to be shipped to your customers are compiled with
-optimizations, using the `-O' compiler option. However, some compilers
-are unable to handle the `-g' and `-O' options together. Using those
-compilers, you cannot generate optimized executables containing
-debugging information.
-
- GCC, the GNU C/C++ compiler, supports `-g' with or without `-O',
-making it possible to debug optimized code. We recommend that you
-_always_ use `-g' whenever you compile a program. You may think your
-program is correct, but there is no sense in pushing your luck. For
-more information, see *note Optimized Code::.
-
- Older versions of the GNU C compiler permitted a variant option
-`-gg' for debugging information. GDB no longer supports this format;
-if your GNU C compiler has this option, do not use it.
-
- GDB knows about preprocessor macros and can show you their expansion
-(*note Macros::). Most compilers do not include information about
-preprocessor macros in the debugging information if you specify the
-`-g' flag alone, because this information is rather large. Version 3.1
-and later of GCC, the GNU C compiler, provides macro information if you
-specify the options `-gdwarf-2' and `-g3'; the former option requests
-debugging information in the Dwarf 2 format, and the latter requests
-"extra information". In the future, we hope to find more compact ways
-to represent macro information, so that it can be included with `-g'
-alone.
-
-
-File: gdb.info, Node: Starting, Next: Arguments, Prev: Compilation, Up: Running
-
-4.2 Starting your Program
-=========================
-
-`run'
-`r'
- Use the `run' command to start your program under GDB. You must
- first specify the program name (except on VxWorks) with an
- argument to GDB (*note Getting In and Out of GDB: Invocation.), or
- by using the `file' or `exec-file' command (*note Commands to
- Specify Files: Files.).
-
-
- If you are running your program in an execution environment that
-supports processes, `run' creates an inferior process and makes that
-process run your program. In some environments without processes,
-`run' jumps to the start of your program. Other targets, like
-`remote', are always running. If you get an error message like this
-one:
-
- The "remote" target does not support "run".
- Try "help target" or "continue".
-
-then use `continue' to run your program. You may need `load' first
-(*note load::).
-
- The execution of a program is affected by certain information it
-receives from its superior. GDB provides ways to specify this
-information, which you must do _before_ starting your program. (You
-can change it after starting your program, but such changes only affect
-your program the next time you start it.) This information may be
-divided into four categories:
-
-The _arguments._
- Specify the arguments to give your program as the arguments of the
- `run' command. If a shell is available on your target, the shell
- is used to pass the arguments, so that you may use normal
- conventions (such as wildcard expansion or variable substitution)
- in describing the arguments. In Unix systems, you can control
- which shell is used with the `SHELL' environment variable. *Note
- Your Program's Arguments: Arguments.
-
-The _environment._
- Your program normally inherits its environment from GDB, but you
- can use the GDB commands `set environment' and `unset environment'
- to change parts of the environment that affect your program.
- *Note Your Program's Environment: Environment.
-
-The _working directory._
- Your program inherits its working directory from GDB. You can set
- the GDB working directory with the `cd' command in GDB. *Note
- Your Program's Working Directory: Working Directory.
-
-The _standard input and output._
- Your program normally uses the same device for standard input and
- standard output as GDB is using. You can redirect input and output
- in the `run' command line, or you can use the `tty' command to set
- a different device for your program. *Note Your Program's Input
- and Output: Input/Output.
-
- _Warning:_ While input and output redirection work, you cannot use
- pipes to pass the output of the program you are debugging to
- another program; if you attempt this, GDB is likely to wind up
- debugging the wrong program.
-
- When you issue the `run' command, your program begins to execute
-immediately. *Note Stopping and Continuing: Stopping, for discussion
-of how to arrange for your program to stop. Once your program has
-stopped, you may call functions in your program, using the `print' or
-`call' commands. *Note Examining Data: Data.
-
- If the modification time of your symbol file has changed since the
-last time GDB read its symbols, GDB discards its symbol table, and
-reads it again. When it does this, GDB tries to retain your current
-breakpoints.
-
-`start'
- The name of the main procedure can vary from language to language.
- With C or C++, the main procedure name is always `main', but other
- languages such as Ada do not require a specific name for their
- main procedure. The debugger provides a convenient way to start
- the execution of the program and to stop at the beginning of the
- main procedure, depending on the language used.
-
- The `start' command does the equivalent of setting a temporary
- breakpoint at the beginning of the main procedure and then invoking
- the `run' command.
-
- Some programs contain an "elaboration" phase where some startup
- code is executed before the main procedure is called. This
- depends on the languages used to write your program. In C++, for
- instance, constructors for static and global objects are executed
- before `main' is called. It is therefore possible that the
- debugger stops before reaching the main procedure. However, the
- temporary breakpoint will remain to halt execution.
-
- Specify the arguments to give to your program as arguments to the
- `start' command. These arguments will be given verbatim to the
- underlying `run' command. Note that the same arguments will be
- reused if no argument is provided during subsequent calls to
- `start' or `run'.
-
- It is sometimes necessary to debug the program during elaboration.
- In these cases, using the `start' command would stop the execution
- of your program too late, as the program would have already
- completed the elaboration phase. Under these circumstances,
- insert breakpoints in your elaboration code before running your
- program.
-
-`set exec-wrapper WRAPPER'
-`show exec-wrapper'
-`unset exec-wrapper'
- When `exec-wrapper' is set, the specified wrapper is used to
- launch programs for debugging. GDB starts your program with a
- shell command of the form `exec WRAPPER PROGRAM'. Quoting is
- added to PROGRAM and its arguments, but not to WRAPPER, so you
- should add quotes if appropriate for your shell. The wrapper runs
- until it executes your program, and then GDB takes control.
-
- You can use any program that eventually calls `execve' with its
- arguments as a wrapper. Several standard Unix utilities do this,
- e.g. `env' and `nohup'. Any Unix shell script ending with `exec
- "$@"' will also work.
-
- For example, you can use `env' to pass an environment variable to
- the debugged program, without setting the variable in your shell's
- environment:
-
- (gdb) set exec-wrapper env 'LD_PRELOAD=libtest.so'
- (gdb) run
-
- This command is available when debugging locally on most targets,
- excluding DJGPP, Cygwin, MS Windows, and QNX Neutrino.
-
-`set disable-randomization'
-`set disable-randomization on'
- This option (enabled by default in GDB) will turn off the native
- randomization of the virtual address space of the started program.
- This option is useful for multiple debugging sessions to make the
- execution better reproducible and memory addresses reusable across
- debugging sessions.
-
- This feature is implemented only on GNU/Linux. You can get the
- same behavior using
-
- (gdb) set exec-wrapper setarch `uname -m` -R
-
-`set disable-randomization off'
- Leave the behavior of the started executable unchanged. Some bugs
- rear their ugly heads only when the program is loaded at certain
- addresses. If your bug disappears when you run the program under
- GDB, that might be because GDB by default disables the address
- randomization on platforms, such as GNU/Linux, which do that for
- stand-alone programs. Use `set disable-randomization off' to try
- to reproduce such elusive bugs.
-
- The virtual address space randomization is implemented only on
- GNU/Linux. It protects the programs against some kinds of
- security attacks. In these cases the attacker needs to know the
- exact location of a concrete executable code. Randomizing its
- location makes it impossible to inject jumps misusing a code at
- its expected addresses.
-
- Prelinking shared libraries provides a startup performance
- advantage but it makes addresses in these libraries predictable
- for privileged processes by having just unprivileged access at the
- target system. Reading the shared library binary gives enough
- information for assembling the malicious code misusing it. Still
- even a prelinked shared library can get loaded at a new random
- address just requiring the regular relocation process during the
- startup. Shared libraries not already prelinked are always loaded
- at a randomly chosen address.
-
- Position independent executables (PIE) contain position
- independent code similar to the shared libraries and therefore
- such executables get loaded at a randomly chosen address upon
- startup. PIE executables always load even already prelinked
- shared libraries at a random address. You can build such
- executable using `gcc -fPIE -pie'.
-
- Heap (malloc storage), stack and custom mmap areas are always
- placed randomly (as long as the randomization is enabled).
-
-`show disable-randomization'
- Show the current setting of the explicit disable of the native
- randomization of the virtual address space of the started program.
-
-
-
-File: gdb.info, Node: Arguments, Next: Environment, Prev: Starting, Up: Running
-
-4.3 Your Program's Arguments
-============================
-
-The arguments to your program can be specified by the arguments of the
-`run' command. They are passed to a shell, which expands wildcard
-characters and performs redirection of I/O, and thence to your program.
-Your `SHELL' environment variable (if it exists) specifies what shell
-GDB uses. If you do not define `SHELL', GDB uses the default shell
-(`/bin/sh' on Unix).
-
- On non-Unix systems, the program is usually invoked directly by GDB,
-which emulates I/O redirection via the appropriate system calls, and
-the wildcard characters are expanded by the startup code of the
-program, not by the shell.
-
- `run' with no arguments uses the same arguments used by the previous
-`run', or those set by the `set args' command.
-
-`set args'
- Specify the arguments to be used the next time your program is
- run. If `set args' has no arguments, `run' executes your program
- with no arguments. Once you have run your program with arguments,
- using `set args' before the next `run' is the only way to run it
- again without arguments.
-
-`show args'
- Show the arguments to give your program when it is started.
-
-
-File: gdb.info, Node: Environment, Next: Working Directory, Prev: Arguments, Up: Running
-
-4.4 Your Program's Environment
-==============================
-
-The "environment" consists of a set of environment variables and their
-values. Environment variables conventionally record such things as
-your user name, your home directory, your terminal type, and your search
-path for programs to run. Usually you set up environment variables with
-the shell and they are inherited by all the other programs you run.
-When debugging, it can be useful to try running your program with a
-modified environment without having to start GDB over again.
-
-`path DIRECTORY'
- Add DIRECTORY to the front of the `PATH' environment variable (the
- search path for executables) that will be passed to your program.
- The value of `PATH' used by GDB does not change. You may specify
- several directory names, separated by whitespace or by a
- system-dependent separator character (`:' on Unix, `;' on MS-DOS
- and MS-Windows). If DIRECTORY is already in the path, it is moved
- to the front, so it is searched sooner.
-
- You can use the string `$cwd' to refer to whatever is the current
- working directory at the time GDB searches the path. If you use
- `.' instead, it refers to the directory where you executed the
- `path' command. GDB replaces `.' in the DIRECTORY argument (with
- the current path) before adding DIRECTORY to the search path.
-
-`show paths'
- Display the list of search paths for executables (the `PATH'
- environment variable).
-
-`show environment [VARNAME]'
- Print the value of environment variable VARNAME to be given to
- your program when it starts. If you do not supply VARNAME, print
- the names and values of all environment variables to be given to
- your program. You can abbreviate `environment' as `env'.
-
-`set environment VARNAME [=VALUE]'
- Set environment variable VARNAME to VALUE. The value changes for
- your program only, not for GDB itself. VALUE may be any string;
- the values of environment variables are just strings, and any
- interpretation is supplied by your program itself. The VALUE
- parameter is optional; if it is eliminated, the variable is set to
- a null value.
-
- For example, this command:
-
- set env USER = foo
-
- tells the debugged program, when subsequently run, that its user
- is named `foo'. (The spaces around `=' are used for clarity here;
- they are not actually required.)
-
-`unset environment VARNAME'
- Remove variable VARNAME from the environment to be passed to your
- program. This is different from `set env VARNAME ='; `unset
- environment' removes the variable from the environment, rather
- than assigning it an empty value.
-
- _Warning:_ On Unix systems, GDB runs your program using the shell
-indicated by your `SHELL' environment variable if it exists (or
-`/bin/sh' if not). If your `SHELL' variable names a shell that runs an
-initialization file--such as `.cshrc' for C-shell, or `.bashrc' for
-BASH--any variables you set in that file affect your program. You may
-wish to move setting of environment variables to files that are only
-run when you sign on, such as `.login' or `.profile'.
-
-
-File: gdb.info, Node: Working Directory, Next: Input/Output, Prev: Environment, Up: Running
-
-4.5 Your Program's Working Directory
-====================================
-
-Each time you start your program with `run', it inherits its working
-directory from the current working directory of GDB. The GDB working
-directory is initially whatever it inherited from its parent process
-(typically the shell), but you can specify a new working directory in
-GDB with the `cd' command.
-
- The GDB working directory also serves as a default for the commands
-that specify files for GDB to operate on. *Note Commands to Specify
-Files: Files.
-
-`cd DIRECTORY'
- Set the GDB working directory to DIRECTORY.
-
-`pwd'
- Print the GDB working directory.
-
- It is generally impossible to find the current working directory of
-the process being debugged (since a program can change its directory
-during its run). If you work on a system where GDB is configured with
-the `/proc' support, you can use the `info proc' command (*note SVR4
-Process Information::) to find out the current working directory of the
-debuggee.
-
-
-File: gdb.info, Node: Input/Output, Next: Attach, Prev: Working Directory, Up: Running
-
-4.6 Your Program's Input and Output
-===================================
-
-By default, the program you run under GDB does input and output to the
-same terminal that GDB uses. GDB switches the terminal to its own
-terminal modes to interact with you, but it records the terminal modes
-your program was using and switches back to them when you continue
-running your program.
-
-`info terminal'
- Displays information recorded by GDB about the terminal modes your
- program is using.
-
- You can redirect your program's input and/or output using shell
-redirection with the `run' command. For example,
-
- run > outfile
-
-starts your program, diverting its output to the file `outfile'.
-
- Another way to specify where your program should do input and output
-is with the `tty' command. This command accepts a file name as
-argument, and causes this file to be the default for future `run'
-commands. It also resets the controlling terminal for the child
-process, for future `run' commands. For example,
-
- tty /dev/ttyb
-
-directs that processes started with subsequent `run' commands default
-to do input and output on the terminal `/dev/ttyb' and have that as
-their controlling terminal.
-
- An explicit redirection in `run' overrides the `tty' command's
-effect on the input/output device, but not its effect on the controlling
-terminal.
-
- When you use the `tty' command or redirect input in the `run'
-command, only the input _for your program_ is affected. The input for
-GDB still comes from your terminal. `tty' is an alias for `set
-inferior-tty'.
-
- You can use the `show inferior-tty' command to tell GDB to display
-the name of the terminal that will be used for future runs of your
-program.
-
-`set inferior-tty /dev/ttyb'
- Set the tty for the program being debugged to /dev/ttyb.
-
-`show inferior-tty'
- Show the current tty for the program being debugged.
-
-
-File: gdb.info, Node: Attach, Next: Kill Process, Prev: Input/Output, Up: Running
-
-4.7 Debugging an Already-running Process
-========================================
-
-`attach PROCESS-ID'
- This command attaches to a running process--one that was started
- outside GDB. (`info files' shows your active targets.) The
- command takes as argument a process ID. The usual way to find out
- the PROCESS-ID of a Unix process is with the `ps' utility, or with
- the `jobs -l' shell command.
-
- `attach' does not repeat if you press <RET> a second time after
- executing the command.
-
- To use `attach', your program must be running in an environment
-which supports processes; for example, `attach' does not work for
-programs on bare-board targets that lack an operating system. You must
-also have permission to send the process a signal.
-
- When you use `attach', the debugger finds the program running in the
-process first by looking in the current working directory, then (if the
-program is not found) by using the source file search path (*note
-Specifying Source Directories: Source Path.). You can also use the
-`file' command to load the program. *Note Commands to Specify Files:
-Files.
-
- The first thing GDB does after arranging to debug the specified
-process is to stop it. You can examine and modify an attached process
-with all the GDB commands that are ordinarily available when you start
-processes with `run'. You can insert breakpoints; you can step and
-continue; you can modify storage. If you would rather the process
-continue running, you may use the `continue' command after attaching
-GDB to the process.
-
-`detach'
- When you have finished debugging the attached process, you can use
- the `detach' command to release it from GDB control. Detaching
- the process continues its execution. After the `detach' command,
- that process and GDB become completely independent once more, and
- you are ready to `attach' another process or start one with `run'.
- `detach' does not repeat if you press <RET> again after executing
- the command.
-
- If you exit GDB while you have an attached process, you detach that
-process. If you use the `run' command, you kill that process. By
-default, GDB asks for confirmation if you try to do either of these
-things; you can control whether or not you need to confirm by using the
-`set confirm' command (*note Optional Warnings and Messages:
-Messages/Warnings.).
-
-
-File: gdb.info, Node: Kill Process, Next: Inferiors and Programs, Prev: Attach, Up: Running
-
-4.8 Killing the Child Process
-=============================
-
-`kill'
- Kill the child process in which your program is running under GDB.
-
- This command is useful if you wish to debug a core dump instead of a
-running process. GDB ignores any core dump file while your program is
-running.
-
- On some operating systems, a program cannot be executed outside GDB
-while you have breakpoints set on it inside GDB. You can use the
-`kill' command in this situation to permit running your program outside
-the debugger.
-
- The `kill' command is also useful if you wish to recompile and
-relink your program, since on many systems it is impossible to modify an
-executable file while it is running in a process. In this case, when
-you next type `run', GDB notices that the file has changed, and reads
-the symbol table again (while trying to preserve your current
-breakpoint settings).
-
-
-File: gdb.info, Node: Inferiors and Programs, Next: Threads, Prev: Kill Process, Up: Running
-
-4.9 Debugging Multiple Inferiors and Programs
-=============================================
-
-GDB lets you run and debug multiple programs in a single session. In
-addition, GDB on some systems may let you run several programs
-simultaneously (otherwise you have to exit from one before starting
-another). In the most general case, you can have multiple threads of
-execution in each of multiple processes, launched from multiple
-executables.
-
- GDB represents the state of each program execution with an object
-called an "inferior". An inferior typically corresponds to a process,
-but is more general and applies also to targets that do not have
-processes. Inferiors may be created before a process runs, and may be
-retained after a process exits. Inferiors have unique identifiers that
-are different from process ids. Usually each inferior will also have
-its own distinct address space, although some embedded targets may have
-several inferiors running in different parts of a single address space.
-Each inferior may in turn have multiple threads running in it.
-
- To find out what inferiors exist at any moment, use `info inferiors':
-
-`info inferiors'
- Print a list of all inferiors currently being managed by GDB.
-
- GDB displays for each inferior (in this order):
-
- 1. the inferior number assigned by GDB
-
- 2. the target system's inferior identifier
-
- 3. the name of the executable the inferior is running.
-
-
- An asterisk `*' preceding the GDB inferior number indicates the
- current inferior.
-
- For example,
-
- (gdb) info inferiors
- Num Description Executable
- 2 process 2307 hello
- * 1 process 3401 goodbye
-
- To switch focus between inferiors, use the `inferior' command:
-
-`inferior INFNO'
- Make inferior number INFNO the current inferior. The argument
- INFNO is the inferior number assigned by GDB, as shown in the
- first field of the `info inferiors' display.
-
- You can get multiple executables into a debugging session via the
-`add-inferior' and `clone-inferior' commands. On some systems GDB can
-add inferiors to the debug session automatically by following calls to
-`fork' and `exec'. To remove inferiors from the debugging session use
-the `remove-inferiors' command.
-
-`add-inferior [ -copies N ] [ -exec EXECUTABLE ]'
- Adds N inferiors to be run using EXECUTABLE as the executable. N
- defaults to 1. If no executable is specified, the inferiors
- begins empty, with no program. You can still assign or change the
- program assigned to the inferior at any time by using the `file'
- command with the executable name as its argument.
-
-`clone-inferior [ -copies N ] [ INFNO ]'
- Adds N inferiors ready to execute the same program as inferior
- INFNO. N defaults to 1. INFNO defaults to the number of the
- current inferior. This is a convenient command when you want to
- run another instance of the inferior you are debugging.
-
- (gdb) info inferiors
- Num Description Executable
- * 1 process 29964 helloworld
- (gdb) clone-inferior
- Added inferior 2.
- 1 inferiors added.
- (gdb) info inferiors
- Num Description Executable
- 2 <null> helloworld
- * 1 process 29964 helloworld
-
- You can now simply switch focus to inferior 2 and run it.
-
-`remove-inferiors INFNO...'
- Removes the inferior or inferiors INFNO.... It is not possible to
- remove an inferior that is running with this command. For those,
- use the `kill' or `detach' command first.
-
-
- To quit debugging one of the running inferiors that is not the
-current inferior, you can either detach from it by using the
-`detach inferior' command (allowing it to run independently), or kill it
-using the `kill inferiors' command:
-
-`detach inferior INFNO...'
- Detach from the inferior or inferiors identified by GDB inferior
- number(s) INFNO.... Note that the inferior's entry still stays on
- the list of inferiors shown by `info inferiors', but its
- Description will show `<null>'.
-
-`kill inferiors INFNO...'
- Kill the inferior or inferiors identified by GDB inferior
- number(s) INFNO.... Note that the inferior's entry still stays on
- the list of inferiors shown by `info inferiors', but its
- Description will show `<null>'.
-
- After the successful completion of a command such as `detach',
-`detach inferiors', `kill' or `kill inferiors', or after a normal
-process exit, the inferior is still valid and listed with `info
-inferiors', ready to be restarted.
-
- To be notified when inferiors are started or exit under GDB's
-control use `set print inferior-events':
-
-`set print inferior-events'
-`set print inferior-events on'
-`set print inferior-events off'
- The `set print inferior-events' command allows you to enable or
- disable printing of messages when GDB notices that new inferiors
- have started or that inferiors have exited or have been detached.
- By default, these messages will not be printed.
-
-`show print inferior-events'
- Show whether messages will be printed when GDB detects that
- inferiors have started, exited or have been detached.
-
- Many commands will work the same with multiple programs as with a
-single program: e.g., `print myglobal' will simply display the value of
-`myglobal' in the current inferior.
-
- Occasionaly, when debugging GDB itself, it may be useful to get more
-info about the relationship of inferiors, programs, address spaces in a
-debug session. You can do that with the `maint info program-spaces'
-command.
-
-`maint info program-spaces'
- Print a list of all program spaces currently being managed by GDB.
-
- GDB displays for each program space (in this order):
-
- 1. the program space number assigned by GDB
-
- 2. the name of the executable loaded into the program space,
- with e.g., the `file' command.
-
-
- An asterisk `*' preceding the GDB program space number indicates
- the current program space.
-
- In addition, below each program space line, GDB prints extra
- information that isn't suitable to display in tabular form. For
- example, the list of inferiors bound to the program space.
-
- (gdb) maint info program-spaces
- Id Executable
- 2 goodbye
- Bound inferiors: ID 1 (process 21561)
- * 1 hello
-
- Here we can see that no inferior is running the program `hello',
- while `process 21561' is running the program `goodbye'. On some
- targets, it is possible that multiple inferiors are bound to the
- same program space. The most common example is that of debugging
- both the parent and child processes of a `vfork' call. For
- example,
-
- (gdb) maint info program-spaces
- Id Executable
- * 1 vfork-test
- Bound inferiors: ID 2 (process 18050), ID 1 (process 18045)
-
- Here, both inferior 2 and inferior 1 are running in the same
- program space as a result of inferior 1 having executed a `vfork'
- call.
-
-
-File: gdb.info, Node: Threads, Next: Forks, Prev: Inferiors and Programs, Up: Running
-
-4.10 Debugging Programs with Multiple Threads
-=============================================
-
-In some operating systems, such as HP-UX and Solaris, a single program
-may have more than one "thread" of execution. The precise semantics of
-threads differ from one operating system to another, but in general the
-threads of a single program are akin to multiple processes--except that
-they share one address space (that is, they can all examine and modify
-the same variables). On the other hand, each thread has its own
-registers and execution stack, and perhaps private memory.
-
- GDB provides these facilities for debugging multi-thread programs:
-
- * automatic notification of new threads
-
- * `thread THREADNO', a command to switch among threads
-
- * `info threads', a command to inquire about existing threads
-
- * `thread apply [THREADNO] [ALL] ARGS', a command to apply a command
- to a list of threads
-
- * thread-specific breakpoints
-
- * `set print thread-events', which controls printing of messages on
- thread start and exit.
-
- * `set libthread-db-search-path PATH', which lets the user specify
- which `libthread_db' to use if the default choice isn't compatible
- with the program.
-
- _Warning:_ These facilities are not yet available on every GDB
- configuration where the operating system supports threads. If
- your GDB does not support threads, these commands have no effect.
- For example, a system without thread support shows no output from
- `info threads', and always rejects the `thread' command, like this:
-
- (gdb) info threads
- (gdb) thread 1
- Thread ID 1 not known. Use the "info threads" command to
- see the IDs of currently known threads.
-
- The GDB thread debugging facility allows you to observe all threads
-while your program runs--but whenever GDB takes control, one thread in
-particular is always the focus of debugging. This thread is called the
-"current thread". Debugging commands show program information from the
-perspective of the current thread.
-
- Whenever GDB detects a new thread in your program, it displays the
-target system's identification for the thread with a message in the
-form `[New SYSTAG]'. SYSTAG is a thread identifier whose form varies
-depending on the particular system. For example, on GNU/Linux, you
-might see
-
- [New Thread 0x41e02940 (LWP 25582)]
-
-when GDB notices a new thread. In contrast, on an SGI system, the
-SYSTAG is simply something like `process 368', with no further
-qualifier.
-
- For debugging purposes, GDB associates its own thread number--always
-a single integer--with each thread in your program.
-
-`info threads [ID...]'
- Display a summary of all threads currently in your program.
- Optional argument ID... is one or more thread ids separated by
- spaces, and means to print information only about the specified
- thread or threads. GDB displays for each thread (in this order):
-
- 1. the thread number assigned by GDB
-
- 2. the target system's thread identifier (SYSTAG)
-
- 3. the thread's name, if one is known. A thread can either be
- named by the user (see `thread name', below), or, in some
- cases, by the program itself.
-
- 4. the current stack frame summary for that thread
-
- An asterisk `*' to the left of the GDB thread number indicates the
- current thread.
-
- For example,
-
- (gdb) info threads
- Id Target Id Frame
- 3 process 35 thread 27 0x34e5 in sigpause ()
- 2 process 35 thread 23 0x34e5 in sigpause ()
- * 1 process 35 thread 13 main (argc=1, argv=0x7ffffff8)
- at threadtest.c:68
-
- On Solaris, you can display more information about user threads with
-a Solaris-specific command:
-
-`maint info sol-threads'
- Display info on Solaris user threads.
-
-`thread THREADNO'
- Make thread number THREADNO the current thread. The command
- argument THREADNO is the internal GDB thread number, as shown in
- the first field of the `info threads' display. GDB responds by
- displaying the system identifier of the thread you selected, and
- its current stack frame summary:
-
- (gdb) thread 2
- [Switching to thread 2 (Thread 0xb7fdab70 (LWP 12747))]
- #0 some_function (ignore=0x0) at example.c:8
- 8 printf ("hello\n");
-
- As with the `[New ...]' message, the form of the text after
- `Switching to' depends on your system's conventions for identifying
- threads.
-
- The debugger convenience variable `$_thread' contains the number
- of the current thread. You may find this useful in writing
- breakpoint conditional expressions, command scripts, and so forth.
- See *Note Convenience Variables: Convenience Vars, for general
- information on convenience variables.
-
-`thread apply [THREADNO | all] COMMAND'
- The `thread apply' command allows you to apply the named COMMAND
- to one or more threads. Specify the numbers of the threads that
- you want affected with the command argument THREADNO. It can be a
- single thread number, one of the numbers shown in the first field
- of the `info threads' display; or it could be a range of thread
- numbers, as in `2-4'. To apply a command to all threads, type
- `thread apply all COMMAND'.
-
-`thread name [NAME]'
- This command assigns a name to the current thread. If no argument
- is given, any existing user-specified name is removed. The thread
- name appears in the `info threads' display.
-
- On some systems, such as GNU/Linux, GDB is able to determine the
- name of the thread as given by the OS. On these systems, a name
- specified with `thread name' will override the system-give name,
- and removing the user-specified name will cause GDB to once again
- display the system-specified name.
-
-`thread find [REGEXP]'
- Search for and display thread ids whose name or SYSTAG matches the
- supplied regular expression.
-
- As well as being the complement to the `thread name' command, this
- command also allows you to identify a thread by its target SYSTAG.
- For instance, on GNU/Linux, the target SYSTAG is the LWP id.
-
- (GDB) thread find 26688
- Thread 4 has target id 'Thread 0x41e02940 (LWP 26688)'
- (GDB) info thread 4
- Id Target Id Frame
- 4 Thread 0x41e02940 (LWP 26688) 0x00000031ca6cd372 in select ()
-
-`set print thread-events'
-`set print thread-events on'
-`set print thread-events off'
- The `set print thread-events' command allows you to enable or
- disable printing of messages when GDB notices that new threads have
- started or that threads have exited. By default, these messages
- will be printed if detection of these events is supported by the
- target. Note that these messages cannot be disabled on all
- targets.
-
-`show print thread-events'
- Show whether messages will be printed when GDB detects that threads
- have started and exited.
-
- *Note Stopping and Starting Multi-thread Programs: Thread Stops, for
-more information about how GDB behaves when you stop and start programs
-with multiple threads.
-
- *Note Setting Watchpoints: Set Watchpoints, for information about
-watchpoints in programs with multiple threads.
-
-`set libthread-db-search-path [PATH]'
- If this variable is set, PATH is a colon-separated list of
- directories GDB will use to search for `libthread_db'. If you
- omit PATH, `libthread-db-search-path' will be reset to its default
- value (`$sdir:$pdir' on GNU/Linux and Solaris systems).
- Internally, the default value comes from the
- `LIBTHREAD_DB_SEARCH_PATH' macro.
-
- On GNU/Linux and Solaris systems, GDB uses a "helper"
- `libthread_db' library to obtain information about threads in the
- inferior process. GDB will use `libthread-db-search-path' to find
- `libthread_db'.
-
- A special entry `$sdir' for `libthread-db-search-path' refers to
- the default system directories that are normally searched for
- loading shared libraries.
-
- A special entry `$pdir' for `libthread-db-search-path' refers to
- the directory from which `libpthread' was loaded in the inferior
- process.
-
- For any `libthread_db' library GDB finds in above directories, GDB
- attempts to initialize it with the current inferior process. If
- this initialization fails (which could happen because of a version
- mismatch between `libthread_db' and `libpthread'), GDB will unload
- `libthread_db', and continue with the next directory. If none of
- `libthread_db' libraries initialize successfully, GDB will issue a
- warning and thread debugging will be disabled.
-
- Setting `libthread-db-search-path' is currently implemented only
- on some platforms.
-
-`show libthread-db-search-path'
- Display current libthread_db search path.
-
-`set debug libthread-db'
-`show debug libthread-db'
- Turns on or off display of `libthread_db'-related events. Use `1'
- to enable, `0' to disable.
-
-
-File: gdb.info, Node: Forks, Next: Checkpoint/Restart, Prev: Threads, Up: Running
-
-4.11 Debugging Forks
-====================
-
-On most systems, GDB has no special support for debugging programs
-which create additional processes using the `fork' function. When a
-program forks, GDB will continue to debug the parent process and the
-child process will run unimpeded. If you have set a breakpoint in any
-code which the child then executes, the child will get a `SIGTRAP'
-signal which (unless it catches the signal) will cause it to terminate.
-
- However, if you want to debug the child process there is a workaround
-which isn't too painful. Put a call to `sleep' in the code which the
-child process executes after the fork. It may be useful to sleep only
-if a certain environment variable is set, or a certain file exists, so
-that the delay need not occur when you don't want to run GDB on the
-child. While the child is sleeping, use the `ps' program to get its
-process ID. Then tell GDB (a new invocation of GDB if you are also
-debugging the parent process) to attach to the child process (*note
-Attach::). From that point on you can debug the child process just
-like any other process which you attached to.
-
- On some systems, GDB provides support for debugging programs that
-create additional processes using the `fork' or `vfork' functions.
-Currently, the only platforms with this feature are HP-UX (11.x and
-later only?) and GNU/Linux (kernel version 2.5.60 and later).
-
- By default, when a program forks, GDB will continue to debug the
-parent process and the child process will run unimpeded.
-
- If you want to follow the child process instead of the parent
-process, use the command `set follow-fork-mode'.
-
-`set follow-fork-mode MODE'
- Set the debugger response to a program call of `fork' or `vfork'.
- A call to `fork' or `vfork' creates a new process. The MODE
- argument can be:
-
- `parent'
- The original process is debugged after a fork. The child
- process runs unimpeded. This is the default.
-
- `child'
- The new process is debugged after a fork. The parent process
- runs unimpeded.
-
-
-`show follow-fork-mode'
- Display the current debugger response to a `fork' or `vfork' call.
-
- On Linux, if you want to debug both the parent and child processes,
-use the command `set detach-on-fork'.
-
-`set detach-on-fork MODE'
- Tells gdb whether to detach one of the processes after a fork, or
- retain debugger control over them both.
-
- `on'
- The child process (or parent process, depending on the value
- of `follow-fork-mode') will be detached and allowed to run
- independently. This is the default.
-
- `off'
- Both processes will be held under the control of GDB. One
- process (child or parent, depending on the value of
- `follow-fork-mode') is debugged as usual, while the other is
- held suspended.
-
-
-`show detach-on-fork'
- Show whether detach-on-fork mode is on/off.
-
- If you choose to set `detach-on-fork' mode off, then GDB will retain
-control of all forked processes (including nested forks). You can list
-the forked processes under the control of GDB by using the
-`info inferiors' command, and switch from one fork to another by using
-the `inferior' command (*note Debugging Multiple Inferiors and
-Programs: Inferiors and Programs.).
-
- To quit debugging one of the forked processes, you can either detach
-from it by using the `detach inferiors' command (allowing it to run
-independently), or kill it using the `kill inferiors' command. *Note
-Debugging Multiple Inferiors and Programs: Inferiors and Programs.
-
- If you ask to debug a child process and a `vfork' is followed by an
-`exec', GDB executes the new target up to the first breakpoint in the
-new target. If you have a breakpoint set on `main' in your original
-program, the breakpoint will also be set on the child process's `main'.
-
- On some systems, when a child process is spawned by `vfork', you
-cannot debug the child or parent until an `exec' call completes.
-
- If you issue a `run' command to GDB after an `exec' call executes,
-the new target restarts. To restart the parent process, use the `file'
-command with the parent executable name as its argument. By default,
-after an `exec' call executes, GDB discards the symbols of the previous
-executable image. You can change this behaviour with the
-`set follow-exec-mode' command.
-
-`set follow-exec-mode MODE'
- Set debugger response to a program call of `exec'. An `exec' call
- replaces the program image of a process.
-
- `follow-exec-mode' can be:
-
- `new'
- GDB creates a new inferior and rebinds the process to this
- new inferior. The program the process was running before the
- `exec' call can be restarted afterwards by restarting the
- original inferior.
-
- For example:
-
- (gdb) info inferiors
- (gdb) info inferior
- Id Description Executable
- * 1 <null> prog1
- (gdb) run
- process 12020 is executing new program: prog2
- Program exited normally.
- (gdb) info inferiors
- Id Description Executable
- * 2 <null> prog2
- 1 <null> prog1
-
- `same'
- GDB keeps the process bound to the same inferior. The new
- executable image replaces the previous executable loaded in
- the inferior. Restarting the inferior after the `exec' call,
- with e.g., the `run' command, restarts the executable the
- process was running after the `exec' call. This is the
- default mode.
-
- For example:
-
- (gdb) info inferiors
- Id Description Executable
- * 1 <null> prog1
- (gdb) run
- process 12020 is executing new program: prog2
- Program exited normally.
- (gdb) info inferiors
- Id Description Executable
- * 1 <null> prog2
-
-
- You can use the `catch' command to make GDB stop whenever a `fork',
-`vfork', or `exec' call is made. *Note Setting Catchpoints: Set
-Catchpoints.
-
-
-File: gdb.info, Node: Checkpoint/Restart, Prev: Forks, Up: Running
-
-4.12 Setting a _Bookmark_ to Return to Later
-============================================
-
-On certain operating systems(1), GDB is able to save a "snapshot" of a
-program's state, called a "checkpoint", and come back to it later.
-
- Returning to a checkpoint effectively undoes everything that has
-happened in the program since the `checkpoint' was saved. This
-includes changes in memory, registers, and even (within some limits)
-system state. Effectively, it is like going back in time to the moment
-when the checkpoint was saved.
-
- Thus, if you're stepping thru a program and you think you're getting
-close to the point where things go wrong, you can save a checkpoint.
-Then, if you accidentally go too far and miss the critical statement,
-instead of having to restart your program from the beginning, you can
-just go back to the checkpoint and start again from there.
-
- This can be especially useful if it takes a lot of time or steps to
-reach the point where you think the bug occurs.
-
- To use the `checkpoint'/`restart' method of debugging:
-
-`checkpoint'
- Save a snapshot of the debugged program's current execution state.
- The `checkpoint' command takes no arguments, but each checkpoint
- is assigned a small integer id, similar to a breakpoint id.
-
-`info checkpoints'
- List the checkpoints that have been saved in the current debugging
- session. For each checkpoint, the following information will be
- listed:
-
- `Checkpoint ID'
-
- `Process ID'
-
- `Code Address'
-
- `Source line, or label'
-
-`restart CHECKPOINT-ID'
- Restore the program state that was saved as checkpoint number
- CHECKPOINT-ID. All program variables, registers, stack frames
- etc. will be returned to the values that they had when the
- checkpoint was saved. In essence, gdb will "wind back the clock"
- to the point in time when the checkpoint was saved.
-
- Note that breakpoints, GDB variables, command history etc. are
- not affected by restoring a checkpoint. In general, a checkpoint
- only restores things that reside in the program being debugged,
- not in the debugger.
-
-`delete checkpoint CHECKPOINT-ID'
- Delete the previously-saved checkpoint identified by CHECKPOINT-ID.
-
-
- Returning to a previously saved checkpoint will restore the user
-state of the program being debugged, plus a significant subset of the
-system (OS) state, including file pointers. It won't "un-write" data
-from a file, but it will rewind the file pointer to the previous
-location, so that the previously written data can be overwritten. For
-files opened in read mode, the pointer will also be restored so that the
-previously read data can be read again.
-
- Of course, characters that have been sent to a printer (or other
-external device) cannot be "snatched back", and characters received
-from eg. a serial device can be removed from internal program buffers,
-but they cannot be "pushed back" into the serial pipeline, ready to be
-received again. Similarly, the actual contents of files that have been
-changed cannot be restored (at this time).
-
- However, within those constraints, you actually can "rewind" your
-program to a previously saved point in time, and begin debugging it
-again -- and you can change the course of events so as to debug a
-different execution path this time.
-
- Finally, there is one bit of internal program state that will be
-different when you return to a checkpoint -- the program's process id.
-Each checkpoint will have a unique process id (or PID), and each will
-be different from the program's original PID. If your program has
-saved a local copy of its process id, this could potentially pose a
-problem.
-
-4.12.1 A Non-obvious Benefit of Using Checkpoints
--------------------------------------------------
-
-On some systems such as GNU/Linux, address space randomization is
-performed on new processes for security reasons. This makes it
-difficult or impossible to set a breakpoint, or watchpoint, on an
-absolute address if you have to restart the program, since the absolute
-location of a symbol will change from one execution to the next.
-
- A checkpoint, however, is an _identical_ copy of a process.
-Therefore if you create a checkpoint at (eg.) the start of main, and
-simply return to that checkpoint instead of restarting the process, you
-can avoid the effects of address randomization and your symbols will
-all stay in the same place.
-
- ---------- Footnotes ----------
-
- (1) Currently, only GNU/Linux.
-
-
-File: gdb.info, Node: Stopping, Next: Reverse Execution, Prev: Running, Up: Top
-
-5 Stopping and Continuing
-*************************
-
-The principal purposes of using a debugger are so that you can stop your
-program before it terminates; or so that, if your program runs into
-trouble, you can investigate and find out why.
-
- Inside GDB, your program may stop for any of several reasons, such
-as a signal, a breakpoint, or reaching a new line after a GDB command
-such as `step'. You may then examine and change variables, set new
-breakpoints or remove old ones, and then continue execution. Usually,
-the messages shown by GDB provide ample explanation of the status of
-your program--but you can also explicitly request this information at
-any time.
-
-`info program'
- Display information about the status of your program: whether it is
- running or not, what process it is, and why it stopped.
-
-* Menu:
-
-* Breakpoints:: Breakpoints, watchpoints, and catchpoints
-* Continuing and Stepping:: Resuming execution
-* Signals:: Signals
-* Thread Stops:: Stopping and starting multi-thread programs
-
-
-File: gdb.info, Node: Breakpoints, Next: Continuing and Stepping, Up: Stopping
-
-5.1 Breakpoints, Watchpoints, and Catchpoints
-=============================================
-
-A "breakpoint" makes your program stop whenever a certain point in the
-program is reached. For each breakpoint, you can add conditions to
-control in finer detail whether your program stops. You can set
-breakpoints with the `break' command and its variants (*note Setting
-Breakpoints: Set Breaks.), to specify the place where your program
-should stop by line number, function name or exact address in the
-program.
-
- On some systems, you can set breakpoints in shared libraries before
-the executable is run. There is a minor limitation on HP-UX systems:
-you must wait until the executable is run in order to set breakpoints
-in shared library routines that are not called directly by the program
-(for example, routines that are arguments in a `pthread_create' call).
-
- A "watchpoint" is a special breakpoint that stops your program when
-the value of an expression changes. The expression may be a value of a
-variable, or it could involve values of one or more variables combined
-by operators, such as `a + b'. This is sometimes called "data
-breakpoints". You must use a different command to set watchpoints
-(*note Setting Watchpoints: Set Watchpoints.), but aside from that, you
-can manage a watchpoint like any other breakpoint: you enable, disable,
-and delete both breakpoints and watchpoints using the same commands.
-
- You can arrange to have values from your program displayed
-automatically whenever GDB stops at a breakpoint. *Note Automatic
-Display: Auto Display.
-
- A "catchpoint" is another special breakpoint that stops your program
-when a certain kind of event occurs, such as the throwing of a C++
-exception or the loading of a library. As with watchpoints, you use a
-different command to set a catchpoint (*note Setting Catchpoints: Set
-Catchpoints.), but aside from that, you can manage a catchpoint like any
-other breakpoint. (To stop when your program receives a signal, use the
-`handle' command; see *note Signals: Signals.)
-
- GDB assigns a number to each breakpoint, watchpoint, or catchpoint
-when you create it; these numbers are successive integers starting with
-one. In many of the commands for controlling various features of
-breakpoints you use the breakpoint number to say which breakpoint you
-want to change. Each breakpoint may be "enabled" or "disabled"; if
-disabled, it has no effect on your program until you enable it again.
-
- Some GDB commands accept a range of breakpoints on which to operate.
-A breakpoint range is either a single breakpoint number, like `5', or
-two such numbers, in increasing order, separated by a hyphen, like
-`5-7'. When a breakpoint range is given to a command, all breakpoints
-in that range are operated on.
-
-* Menu:
-
-* Set Breaks:: Setting breakpoints
-* Set Watchpoints:: Setting watchpoints
-* Set Catchpoints:: Setting catchpoints
-* Delete Breaks:: Deleting breakpoints
-* Disabling:: Disabling breakpoints
-* Conditions:: Break conditions
-* Break Commands:: Breakpoint command lists
-* Save Breakpoints:: How to save breakpoints in a file
-* Error in Breakpoints:: ``Cannot insert breakpoints''
-* Breakpoint-related Warnings:: ``Breakpoint address adjusted...''
-
-
-File: gdb.info, Node: Set Breaks, Next: Set Watchpoints, Up: Breakpoints
-
-5.1.1 Setting Breakpoints
--------------------------
-
-Breakpoints are set with the `break' command (abbreviated `b'). The
-debugger convenience variable `$bpnum' records the number of the
-breakpoint you've set most recently; see *note Convenience Variables:
-Convenience Vars, for a discussion of what you can do with convenience
-variables.
-
-`break LOCATION'
- Set a breakpoint at the given LOCATION, which can specify a
- function name, a line number, or an address of an instruction.
- (*Note Specify Location::, for a list of all the possible ways to
- specify a LOCATION.) The breakpoint will stop your program just
- before it executes any of the code in the specified LOCATION.
-
- When using source languages that permit overloading of symbols,
- such as C++, a function name may refer to more than one possible
- place to break. *Note Ambiguous Expressions: Ambiguous
- Expressions, for a discussion of that situation.
-
- It is also possible to insert a breakpoint that will stop the
- program only if a specific thread (*note Thread-Specific
- Breakpoints::) or a specific task (*note Ada Tasks::) hits that
- breakpoint.
-
-`break'
- When called without any arguments, `break' sets a breakpoint at
- the next instruction to be executed in the selected stack frame
- (*note Examining the Stack: Stack.). In any selected frame but the
- innermost, this makes your program stop as soon as control returns
- to that frame. This is similar to the effect of a `finish'
- command in the frame inside the selected frame--except that
- `finish' does not leave an active breakpoint. If you use `break'
- without an argument in the innermost frame, GDB stops the next
- time it reaches the current location; this may be useful inside
- loops.
-
- GDB normally ignores breakpoints when it resumes execution, until
- at least one instruction has been executed. If it did not do
- this, you would be unable to proceed past a breakpoint without
- first disabling the breakpoint. This rule applies whether or not
- the breakpoint already existed when your program stopped.
-
-`break ... if COND'
- Set a breakpoint with condition COND; evaluate the expression COND
- each time the breakpoint is reached, and stop only if the value is
- nonzero--that is, if COND evaluates as true. `...' stands for one
- of the possible arguments described above (or no argument)
- specifying where to break. *Note Break Conditions: Conditions,
- for more information on breakpoint conditions.
-
-`tbreak ARGS'
- Set a breakpoint enabled only for one stop. ARGS are the same as
- for the `break' command, and the breakpoint is set in the same
- way, but the breakpoint is automatically deleted after the first
- time your program stops there. *Note Disabling Breakpoints:
- Disabling.
-
-`hbreak ARGS'
- Set a hardware-assisted breakpoint. ARGS are the same as for the
- `break' command and the breakpoint is set in the same way, but the
- breakpoint requires hardware support and some target hardware may
- not have this support. The main purpose of this is EPROM/ROM code
- debugging, so you can set a breakpoint at an instruction without
- changing the instruction. This can be used with the new
- trap-generation provided by SPARClite DSU and most x86-based
- targets. These targets will generate traps when a program
- accesses some data or instruction address that is assigned to the
- debug registers. However the hardware breakpoint registers can
- take a limited number of breakpoints. For example, on the DSU,
- only two data breakpoints can be set at a time, and GDB will
- reject this command if more than two are used. Delete or disable
- unused hardware breakpoints before setting new ones (*note
- Disabling Breakpoints: Disabling.). *Note Break Conditions:
- Conditions. For remote targets, you can restrict the number of
- hardware breakpoints GDB will use, see *note set remote
- hardware-breakpoint-limit::.
-
-`thbreak ARGS'
- Set a hardware-assisted breakpoint enabled only for one stop. ARGS
- are the same as for the `hbreak' command and the breakpoint is set
- in the same way. However, like the `tbreak' command, the
- breakpoint is automatically deleted after the first time your
- program stops there. Also, like the `hbreak' command, the
- breakpoint requires hardware support and some target hardware may
- not have this support. *Note Disabling Breakpoints: Disabling.
- See also *note Break Conditions: Conditions.
-
-`rbreak REGEX'
- Set breakpoints on all functions matching the regular expression
- REGEX. This command sets an unconditional breakpoint on all
- matches, printing a list of all breakpoints it set. Once these
- breakpoints are set, they are treated just like the breakpoints
- set with the `break' command. You can delete them, disable them,
- or make them conditional the same way as any other breakpoint.
-
- The syntax of the regular expression is the standard one used with
- tools like `grep'. Note that this is different from the syntax
- used by shells, so for instance `foo*' matches all functions that
- include an `fo' followed by zero or more `o's. There is an
- implicit `.*' leading and trailing the regular expression you
- supply, so to match only functions that begin with `foo', use
- `^foo'.
-
- When debugging C++ programs, `rbreak' is useful for setting
- breakpoints on overloaded functions that are not members of any
- special classes.
-
- The `rbreak' command can be used to set breakpoints in *all* the
- functions in a program, like this:
-
- (gdb) rbreak .
-
-`rbreak FILE:REGEX'
- If `rbreak' is called with a filename qualification, it limits the
- search for functions matching the given regular expression to the
- specified FILE. This can be used, for example, to set breakpoints
- on every function in a given file:
-
- (gdb) rbreak file.c:.
-
- The colon separating the filename qualifier from the regex may
- optionally be surrounded by spaces.
-
-`info breakpoints [N...]'
-`info break [N...]'
- Print a table of all breakpoints, watchpoints, and catchpoints set
- and not deleted. Optional argument N means print information only
- about the specified breakpoint(s) (or watchpoint(s) or
- catchpoint(s)). For each breakpoint, following columns are
- printed:
-
- _Breakpoint Numbers_
-
- _Type_
- Breakpoint, watchpoint, or catchpoint.
-
- _Disposition_
- Whether the breakpoint is marked to be disabled or deleted
- when hit.
-
- _Enabled or Disabled_
- Enabled breakpoints are marked with `y'. `n' marks
- breakpoints that are not enabled.
-
- _Address_
- Where the breakpoint is in your program, as a memory address.
- For a pending breakpoint whose address is not yet known, this
- field will contain `<PENDING>'. Such breakpoint won't fire
- until a shared library that has the symbol or line referred
- by breakpoint is loaded. See below for details. A
- breakpoint with several locations will have `<MULTIPLE>' in
- this field--see below for details.
-
- _What_
- Where the breakpoint is in the source for your program, as a
- file and line number. For a pending breakpoint, the original
- string passed to the breakpoint command will be listed as it
- cannot be resolved until the appropriate shared library is
- loaded in the future.
-
- If a breakpoint is conditional, `info break' shows the condition on
- the line following the affected breakpoint; breakpoint commands,
- if any, are listed after that. A pending breakpoint is allowed to
- have a condition specified for it. The condition is not parsed
- for validity until a shared library is loaded that allows the
- pending breakpoint to resolve to a valid location.
-
- `info break' with a breakpoint number N as argument lists only
- that breakpoint. The convenience variable `$_' and the default
- examining-address for the `x' command are set to the address of
- the last breakpoint listed (*note Examining Memory: Memory.).
-
- `info break' displays a count of the number of times the breakpoint
- has been hit. This is especially useful in conjunction with the
- `ignore' command. You can ignore a large number of breakpoint
- hits, look at the breakpoint info to see how many times the
- breakpoint was hit, and then run again, ignoring one less than
- that number. This will get you quickly to the last hit of that
- breakpoint.
-
- GDB allows you to set any number of breakpoints at the same place in
-your program. There is nothing silly or meaningless about this. When
-the breakpoints are conditional, this is even useful (*note Break
-Conditions: Conditions.).
-
- It is possible that a breakpoint corresponds to several locations in
-your program. Examples of this situation are:
-
- * For a C++ constructor, the GCC compiler generates several
- instances of the function body, used in different cases.
-
- * For a C++ template function, a given line in the function can
- correspond to any number of instantiations.
-
- * For an inlined function, a given source line can correspond to
- several places where that function is inlined.
-
- In all those cases, GDB will insert a breakpoint at all the relevant
-locations(1).
-
- A breakpoint with multiple locations is displayed in the breakpoint
-table using several rows--one header row, followed by one row for each
-breakpoint location. The header row has `<MULTIPLE>' in the address
-column. The rows for individual locations contain the actual addresses
-for locations, and show the functions to which those locations belong.
-The number column for a location is of the form
-BREAKPOINT-NUMBER.LOCATION-NUMBER.
-
- For example:
-
- Num Type Disp Enb Address What
- 1 breakpoint keep y <MULTIPLE>
- stop only if i==1
- breakpoint already hit 1 time
- 1.1 y 0x080486a2 in void foo<int>() at t.cc:8
- 1.2 y 0x080486ca in void foo<double>() at t.cc:8
-
- Each location can be individually enabled or disabled by passing
-BREAKPOINT-NUMBER.LOCATION-NUMBER as argument to the `enable' and
-`disable' commands. Note that you cannot delete the individual
-locations from the list, you can only delete the entire list of
-locations that belong to their parent breakpoint (with the `delete NUM'
-command, where NUM is the number of the parent breakpoint, 1 in the
-above example). Disabling or enabling the parent breakpoint (*note
-Disabling::) affects all of the locations that belong to that
-breakpoint.
-
- It's quite common to have a breakpoint inside a shared library.
-Shared libraries can be loaded and unloaded explicitly, and possibly
-repeatedly, as the program is executed. To support this use case, GDB
-updates breakpoint locations whenever any shared library is loaded or
-unloaded. Typically, you would set a breakpoint in a shared library at
-the beginning of your debugging session, when the library is not
-loaded, and when the symbols from the library are not available. When
-you try to set breakpoint, GDB will ask you if you want to set a so
-called "pending breakpoint"--breakpoint whose address is not yet
-resolved.
-
- After the program is run, whenever a new shared library is loaded,
-GDB reevaluates all the breakpoints. When a newly loaded shared
-library contains the symbol or line referred to by some pending
-breakpoint, that breakpoint is resolved and becomes an ordinary
-breakpoint. When a library is unloaded, all breakpoints that refer to
-its symbols or source lines become pending again.
-
- This logic works for breakpoints with multiple locations, too. For
-example, if you have a breakpoint in a C++ template function, and a
-newly loaded shared library has an instantiation of that template, a
-new location is added to the list of locations for the breakpoint.
-
- Except for having unresolved address, pending breakpoints do not
-differ from regular breakpoints. You can set conditions or commands,
-enable and disable them and perform other breakpoint operations.
-
- GDB provides some additional commands for controlling what happens
-when the `break' command cannot resolve breakpoint address
-specification to an address:
-
-`set breakpoint pending auto'
- This is the default behavior. When GDB cannot find the breakpoint
- location, it queries you whether a pending breakpoint should be
- created.
-
-`set breakpoint pending on'
- This indicates that an unrecognized breakpoint location should
- automatically result in a pending breakpoint being created.
-
-`set breakpoint pending off'
- This indicates that pending breakpoints are not to be created. Any
- unrecognized breakpoint location results in an error. This
- setting does not affect any pending breakpoints previously created.
-
-`show breakpoint pending'
- Show the current behavior setting for creating pending breakpoints.
-
- The settings above only affect the `break' command and its variants.
-Once breakpoint is set, it will be automatically updated as shared
-libraries are loaded and unloaded.
-
- For some targets, GDB can automatically decide if hardware or
-software breakpoints should be used, depending on whether the
-breakpoint address is read-only or read-write. This applies to
-breakpoints set with the `break' command as well as to internal
-breakpoints set by commands like `next' and `finish'. For breakpoints
-set with `hbreak', GDB will always use hardware breakpoints.
-
- You can control this automatic behaviour with the following
-commands::
-
-`set breakpoint auto-hw on'
- This is the default behavior. When GDB sets a breakpoint, it will
- try to use the target memory map to decide if software or hardware
- breakpoint must be used.
-
-`set breakpoint auto-hw off'
- This indicates GDB should not automatically select breakpoint
- type. If the target provides a memory map, GDB will warn when
- trying to set software breakpoint at a read-only address.
-
- GDB normally implements breakpoints by replacing the program code at
-the breakpoint address with a special instruction, which, when
-executed, given control to the debugger. By default, the program code
-is so modified only when the program is resumed. As soon as the
-program stops, GDB restores the original instructions. This behaviour
-guards against leaving breakpoints inserted in the target should gdb
-abrubptly disconnect. However, with slow remote targets, inserting and
-removing breakpoint can reduce the performance. This behavior can be
-controlled with the following commands::
-
-`set breakpoint always-inserted off'
- All breakpoints, including newly added by the user, are inserted in
- the target only when the target is resumed. All breakpoints are
- removed from the target when it stops.
-
-`set breakpoint always-inserted on'
- Causes all breakpoints to be inserted in the target at all times.
- If the user adds a new breakpoint, or changes an existing
- breakpoint, the breakpoints in the target are updated immediately.
- A breakpoint is removed from the target only when breakpoint
- itself is removed.
-
-`set breakpoint always-inserted auto'
- This is the default mode. If GDB is controlling the inferior in
- non-stop mode (*note Non-Stop Mode::), gdb behaves as if
- `breakpoint always-inserted' mode is on. If GDB is controlling
- the inferior in all-stop mode, GDB behaves as if `breakpoint
- always-inserted' mode is off.
-
- GDB itself sometimes sets breakpoints in your program for special
-purposes, such as proper handling of `longjmp' (in C programs). These
-internal breakpoints are assigned negative numbers, starting with `-1';
-`info breakpoints' does not display them. You can see these
-breakpoints with the GDB maintenance command `maint info breakpoints'
-(*note maint info breakpoints::).
-
- ---------- Footnotes ----------
-
- (1) As of this writing, multiple-location breakpoints work only if
-there's line number information for all the locations. This means that
-they will generally not work in system libraries, unless you have debug
-info with line numbers for them.
-
-
-File: gdb.info, Node: Set Watchpoints, Next: Set Catchpoints, Prev: Set Breaks, Up: Breakpoints
-
-5.1.2 Setting Watchpoints
--------------------------
-
-You can use a watchpoint to stop execution whenever the value of an
-expression changes, without having to predict a particular place where
-this may happen. (This is sometimes called a "data breakpoint".) The
-expression may be as simple as the value of a single variable, or as
-complex as many variables combined by operators. Examples include:
-
- * A reference to the value of a single variable.
-
- * An address cast to an appropriate data type. For example, `*(int
- *)0x12345678' will watch a 4-byte region at the specified address
- (assuming an `int' occupies 4 bytes).
-
- * An arbitrarily complex expression, such as `a*b + c/d'. The
- expression can use any operators valid in the program's native
- language (*note Languages::).
-
- You can set a watchpoint on an expression even if the expression can
-not be evaluated yet. For instance, you can set a watchpoint on
-`*global_ptr' before `global_ptr' is initialized. GDB will stop when
-your program sets `global_ptr' and the expression produces a valid
-value. If the expression becomes valid in some other way than changing
-a variable (e.g. if the memory pointed to by `*global_ptr' becomes
-readable as the result of a `malloc' call), GDB may not stop until the
-next time the expression changes.
-
- Depending on your system, watchpoints may be implemented in software
-or hardware. GDB does software watchpointing by single-stepping your
-program and testing the variable's value each time, which is hundreds of
-times slower than normal execution. (But this may still be worth it, to
-catch errors where you have no clue what part of your program is the
-culprit.)
-
- On some systems, such as HP-UX, PowerPC, GNU/Linux and most other
-x86-based targets, GDB includes support for hardware watchpoints, which
-do not slow down the running of your program.
-
-`watch [-l|-location] EXPR [thread THREADNUM]'
- Set a watchpoint for an expression. GDB will break when the
- expression EXPR is written into by the program and its value
- changes. The simplest (and the most popular) use of this command
- is to watch the value of a single variable:
-
- (gdb) watch foo
-
- If the command includes a `[thread THREADNUM]' clause, GDB breaks
- only when the thread identified by THREADNUM changes the value of
- EXPR. If any other threads change the value of EXPR, GDB will not
- break. Note that watchpoints restricted to a single thread in
- this way only work with Hardware Watchpoints.
-
- Ordinarily a watchpoint respects the scope of variables in EXPR
- (see below). The `-location' argument tells GDB to instead watch
- the memory referred to by EXPR. In this case, GDB will evaluate
- EXPR, take the address of the result, and watch the memory at that
- address. The type of the result is used to determine the size of
- the watched memory. If the expression's result does not have an
- address, then GDB will print an error.
-
-`rwatch [-l|-location] EXPR [thread THREADNUM]'
- Set a watchpoint that will break when the value of EXPR is read by
- the program.
-
-`awatch [-l|-location] EXPR [thread THREADNUM]'
- Set a watchpoint that will break when EXPR is either read from or
- written into by the program.
-
-`info watchpoints [N...]'
- This command prints a list of watchpoints, using the same format as
- `info break' (*note Set Breaks::).
-
- If you watch for a change in a numerically entered address you need
-to dereference it, as the address itself is just a constant number
-which will never change. GDB refuses to create a watchpoint that
-watches a never-changing value:
-
- (gdb) watch 0x600850
- Cannot watch constant value 0x600850.
- (gdb) watch *(int *) 0x600850
- Watchpoint 1: *(int *) 6293584
-
- GDB sets a "hardware watchpoint" if possible. Hardware watchpoints
-execute very quickly, and the debugger reports a change in value at the
-exact instruction where the change occurs. If GDB cannot set a
-hardware watchpoint, it sets a software watchpoint, which executes more
-slowly and reports the change in value at the next _statement_, not the
-instruction, after the change occurs.
-
- You can force GDB to use only software watchpoints with the `set
-can-use-hw-watchpoints 0' command. With this variable set to zero, GDB
-will never try to use hardware watchpoints, even if the underlying
-system supports them. (Note that hardware-assisted watchpoints that
-were set _before_ setting `can-use-hw-watchpoints' to zero will still
-use the hardware mechanism of watching expression values.)
-
-`set can-use-hw-watchpoints'
- Set whether or not to use hardware watchpoints.
-
-`show can-use-hw-watchpoints'
- Show the current mode of using hardware watchpoints.
-
- For remote targets, you can restrict the number of hardware
-watchpoints GDB will use, see *note set remote
-hardware-breakpoint-limit::.
-
- When you issue the `watch' command, GDB reports
-
- Hardware watchpoint NUM: EXPR
-
-if it was able to set a hardware watchpoint.
-
- Currently, the `awatch' and `rwatch' commands can only set hardware
-watchpoints, because accesses to data that don't change the value of
-the watched expression cannot be detected without examining every
-instruction as it is being executed, and GDB does not do that
-currently. If GDB finds that it is unable to set a hardware breakpoint
-with the `awatch' or `rwatch' command, it will print a message like
-this:
-
- Expression cannot be implemented with read/access watchpoint.
-
- Sometimes, GDB cannot set a hardware watchpoint because the data
-type of the watched expression is wider than what a hardware watchpoint
-on the target machine can handle. For example, some systems can only
-watch regions that are up to 4 bytes wide; on such systems you cannot
-set hardware watchpoints for an expression that yields a
-double-precision floating-point number (which is typically 8 bytes
-wide). As a work-around, it might be possible to break the large region
-into a series of smaller ones and watch them with separate watchpoints.
-
- If you set too many hardware watchpoints, GDB might be unable to
-insert all of them when you resume the execution of your program.
-Since the precise number of active watchpoints is unknown until such
-time as the program is about to be resumed, GDB might not be able to
-warn you about this when you set the watchpoints, and the warning will
-be printed only when the program is resumed:
-
- Hardware watchpoint NUM: Could not insert watchpoint
-
-If this happens, delete or disable some of the watchpoints.
-
- Watching complex expressions that reference many variables can also
-exhaust the resources available for hardware-assisted watchpoints.
-That's because GDB needs to watch every variable in the expression with
-separately allocated resources.
-
- If you call a function interactively using `print' or `call', any
-watchpoints you have set will be inactive until GDB reaches another
-kind of breakpoint or the call completes.
-
- GDB automatically deletes watchpoints that watch local (automatic)
-variables, or expressions that involve such variables, when they go out
-of scope, that is, when the execution leaves the block in which these
-variables were defined. In particular, when the program being debugged
-terminates, _all_ local variables go out of scope, and so only
-watchpoints that watch global variables remain set. If you rerun the
-program, you will need to set all such watchpoints again. One way of
-doing that would be to set a code breakpoint at the entry to the `main'
-function and when it breaks, set all the watchpoints.
-
- In multi-threaded programs, watchpoints will detect changes to the
-watched expression from every thread.
-
- _Warning:_ In multi-threaded programs, software watchpoints have
- only limited usefulness. If GDB creates a software watchpoint, it
- can only watch the value of an expression _in a single thread_.
- If you are confident that the expression can only change due to
- the current thread's activity (and if you are also confident that
- no other thread can become current), then you can use software
- watchpoints as usual. However, GDB may not notice when a
- non-current thread's activity changes the expression. (Hardware
- watchpoints, in contrast, watch an expression in all threads.)
-
- *Note set remote hardware-watchpoint-limit::.
-
-
-File: gdb.info, Node: Set Catchpoints, Next: Delete Breaks, Prev: Set Watchpoints, Up: Breakpoints
-
-5.1.3 Setting Catchpoints
--------------------------
-
-You can use "catchpoints" to cause the debugger to stop for certain
-kinds of program events, such as C++ exceptions or the loading of a
-shared library. Use the `catch' command to set a catchpoint.
-
-`catch EVENT'
- Stop when EVENT occurs. EVENT can be any of the following:
- `throw'
- The throwing of a C++ exception.
-
- `catch'
- The catching of a C++ exception.
-
- `exception'
- An Ada exception being raised. If an exception name is
- specified at the end of the command (eg `catch exception
- Program_Error'), the debugger will stop only when this
- specific exception is raised. Otherwise, the debugger stops
- execution when any Ada exception is raised.
-
- When inserting an exception catchpoint on a user-defined
- exception whose name is identical to one of the exceptions
- defined by the language, the fully qualified name must be
- used as the exception name. Otherwise, GDB will assume that
- it should stop on the pre-defined exception rather than the
- user-defined one. For instance, assuming an exception called
- `Constraint_Error' is defined in package `Pck', then the
- command to use to catch such exceptions is `catch exception
- Pck.Constraint_Error'.
-
- `exception unhandled'
- An exception that was raised but is not handled by the
- program.
-
- `assert'
- A failed Ada assertion.
-
- `exec'
- A call to `exec'. This is currently only available for HP-UX
- and GNU/Linux.
-
- `syscall'
- `syscall [NAME | NUMBER] ...'
- A call to or return from a system call, a.k.a. "syscall". A
- syscall is a mechanism for application programs to request a
- service from the operating system (OS) or one of the OS
- system services. GDB can catch some or all of the syscalls
- issued by the debuggee, and show the related information for
- each syscall. If no argument is specified, calls to and
- returns from all system calls will be caught.
-
- NAME can be any system call name that is valid for the
- underlying OS. Just what syscalls are valid depends on the
- OS. On GNU and Unix systems, you can find the full list of
- valid syscall names on `/usr/include/asm/unistd.h'.
-
- Normally, GDB knows in advance which syscalls are valid for
- each OS, so you can use the GDB command-line completion
- facilities (*note command completion: Completion.) to list the
- available choices.
-
- You may also specify the system call numerically. A syscall's
- number is the value passed to the OS's syscall dispatcher to
- identify the requested service. When you specify the syscall
- by its name, GDB uses its database of syscalls to convert the
- name into the corresponding numeric code, but using the
- number directly may be useful if GDB's database does not have
- the complete list of syscalls on your system (e.g., because
- GDB lags behind the OS upgrades).
-
- The example below illustrates how this command works if you
- don't provide arguments to it:
-
- (gdb) catch syscall
- Catchpoint 1 (syscall)
- (gdb) r
- Starting program: /tmp/catch-syscall
-
- Catchpoint 1 (call to syscall 'close'), \
- 0xffffe424 in __kernel_vsyscall ()
- (gdb) c
- Continuing.
-
- Catchpoint 1 (returned from syscall 'close'), \
- 0xffffe424 in __kernel_vsyscall ()
- (gdb)
-
- Here is an example of catching a system call by name:
-
- (gdb) catch syscall chroot
- Catchpoint 1 (syscall 'chroot' [61])
- (gdb) r
- Starting program: /tmp/catch-syscall
-
- Catchpoint 1 (call to syscall 'chroot'), \
- 0xffffe424 in __kernel_vsyscall ()
- (gdb) c
- Continuing.
-
- Catchpoint 1 (returned from syscall 'chroot'), \
- 0xffffe424 in __kernel_vsyscall ()
- (gdb)
-
- An example of specifying a system call numerically. In the
- case below, the syscall number has a corresponding entry in
- the XML file, so GDB finds its name and prints it:
-
- (gdb) catch syscall 252
- Catchpoint 1 (syscall(s) 'exit_group')
- (gdb) r
- Starting program: /tmp/catch-syscall
-
- Catchpoint 1 (call to syscall 'exit_group'), \
- 0xffffe424 in __kernel_vsyscall ()
- (gdb) c
- Continuing.
-
- Program exited normally.
- (gdb)
-
- However, there can be situations when there is no
- corresponding name in XML file for that syscall number. In
- this case, GDB prints a warning message saying that it was
- not able to find the syscall name, but the catchpoint will be
- set anyway. See the example below:
-
- (gdb) catch syscall 764
- warning: The number '764' does not represent a known syscall.
- Catchpoint 2 (syscall 764)
- (gdb)
-
- If you configure GDB using the `--without-expat' option, it
- will not be able to display syscall names. Also, if your
- architecture does not have an XML file describing its system
- calls, you will not be able to see the syscall names. It is
- important to notice that these two features are used for
- accessing the syscall name database. In either case, you
- will see a warning like this:
-
- (gdb) catch syscall
- warning: Could not open "syscalls/i386-linux.xml"
- warning: Could not load the syscall XML file 'syscalls/i386-linux.xml'.
- GDB will not be able to display syscall names.
- Catchpoint 1 (syscall)
- (gdb)
-
- Of course, the file name will change depending on your
- architecture and system.
-
- Still using the example above, you can also try to catch a
- syscall by its number. In this case, you would see something
- like:
-
- (gdb) catch syscall 252
- Catchpoint 1 (syscall(s) 252)
-
- Again, in this case GDB would not be able to display
- syscall's names.
-
- `fork'
- A call to `fork'. This is currently only available for HP-UX
- and GNU/Linux.
-
- `vfork'
- A call to `vfork'. This is currently only available for HP-UX
- and GNU/Linux.
-
-
-`tcatch EVENT'
- Set a catchpoint that is enabled only for one stop. The
- catchpoint is automatically deleted after the first time the event
- is caught.
-
-
- Use the `info break' command to list the current catchpoints.
-
- There are currently some limitations to C++ exception handling
-(`catch throw' and `catch catch') in GDB:
-
- * If you call a function interactively, GDB normally returns control
- to you when the function has finished executing. If the call
- raises an exception, however, the call may bypass the mechanism
- that returns control to you and cause your program either to abort
- or to simply continue running until it hits a breakpoint, catches
- a signal that GDB is listening for, or exits. This is the case
- even if you set a catchpoint for the exception; catchpoints on
- exceptions are disabled within interactive calls.
-
- * You cannot raise an exception interactively.
-
- * You cannot install an exception handler interactively.
-
- Sometimes `catch' is not the best way to debug exception handling:
-if you need to know exactly where an exception is raised, it is better
-to stop _before_ the exception handler is called, since that way you
-can see the stack before any unwinding takes place. If you set a
-breakpoint in an exception handler instead, it may not be easy to find
-out where the exception was raised.
-
- To stop just before an exception handler is called, you need some
-knowledge of the implementation. In the case of GNU C++, exceptions are
-raised by calling a library function named `__raise_exception' which
-has the following ANSI C interface:
-
- /* ADDR is where the exception identifier is stored.
- ID is the exception identifier. */
- void __raise_exception (void **addr, void *id);
-
-To make the debugger catch all exceptions before any stack unwinding
-takes place, set a breakpoint on `__raise_exception' (*note
-Breakpoints; Watchpoints; and Exceptions: Breakpoints.).
-
- With a conditional breakpoint (*note Break Conditions: Conditions.)
-that depends on the value of ID, you can stop your program when a
-specific exception is raised. You can use multiple conditional
-breakpoints to stop your program when any of a number of exceptions are
-raised.
-
-
-File: gdb.info, Node: Delete Breaks, Next: Disabling, Prev: Set Catchpoints, Up: Breakpoints
-
-5.1.4 Deleting Breakpoints
---------------------------
-
-It is often necessary to eliminate a breakpoint, watchpoint, or
-catchpoint once it has done its job and you no longer want your program
-to stop there. This is called "deleting" the breakpoint. A breakpoint
-that has been deleted no longer exists; it is forgotten.
-
- With the `clear' command you can delete breakpoints according to
-where they are in your program. With the `delete' command you can
-delete individual breakpoints, watchpoints, or catchpoints by specifying
-their breakpoint numbers.
-
- It is not necessary to delete a breakpoint to proceed past it. GDB
-automatically ignores breakpoints on the first instruction to be
-executed when you continue execution without changing the execution
-address.
-
-`clear'
- Delete any breakpoints at the next instruction to be executed in
- the selected stack frame (*note Selecting a Frame: Selection.).
- When the innermost frame is selected, this is a good way to delete
- a breakpoint where your program just stopped.
-
-`clear LOCATION'
- Delete any breakpoints set at the specified LOCATION. *Note
- Specify Location::, for the various forms of LOCATION; the most
- useful ones are listed below:
-
- `clear FUNCTION'
- `clear FILENAME:FUNCTION'
- Delete any breakpoints set at entry to the named FUNCTION.
-
- `clear LINENUM'
- `clear FILENAME:LINENUM'
- Delete any breakpoints set at or within the code of the
- specified LINENUM of the specified FILENAME.
-
-`delete [breakpoints] [RANGE...]'
- Delete the breakpoints, watchpoints, or catchpoints of the
- breakpoint ranges specified as arguments. If no argument is
- specified, delete all breakpoints (GDB asks confirmation, unless
- you have `set confirm off'). You can abbreviate this command as
- `d'.
-
-
-File: gdb.info, Node: Disabling, Next: Conditions, Prev: Delete Breaks, Up: Breakpoints
-
-5.1.5 Disabling Breakpoints
----------------------------
-
-Rather than deleting a breakpoint, watchpoint, or catchpoint, you might
-prefer to "disable" it. This makes the breakpoint inoperative as if it
-had been deleted, but remembers the information on the breakpoint so
-that you can "enable" it again later.
-
- You disable and enable breakpoints, watchpoints, and catchpoints with
-the `enable' and `disable' commands, optionally specifying one or more
-breakpoint numbers as arguments. Use `info break' to print a list of
-all breakpoints, watchpoints, and catchpoints if you do not know which
-numbers to use.
-
- Disabling and enabling a breakpoint that has multiple locations
-affects all of its locations.
-
- A breakpoint, watchpoint, or catchpoint can have any of four
-different states of enablement:
-
- * Enabled. The breakpoint stops your program. A breakpoint set
- with the `break' command starts out in this state.
-
- * Disabled. The breakpoint has no effect on your program.
-
- * Enabled once. The breakpoint stops your program, but then becomes
- disabled.
-
- * Enabled for deletion. The breakpoint stops your program, but
- immediately after it does so it is deleted permanently. A
- breakpoint set with the `tbreak' command starts out in this state.
-
- You can use the following commands to enable or disable breakpoints,
-watchpoints, and catchpoints:
-
-`disable [breakpoints] [RANGE...]'
- Disable the specified breakpoints--or all breakpoints, if none are
- listed. A disabled breakpoint has no effect but is not forgotten.
- All options such as ignore-counts, conditions and commands are
- remembered in case the breakpoint is enabled again later. You may
- abbreviate `disable' as `dis'.
-
-`enable [breakpoints] [RANGE...]'
- Enable the specified breakpoints (or all defined breakpoints).
- They become effective once again in stopping your program.
-
-`enable [breakpoints] once RANGE...'
- Enable the specified breakpoints temporarily. GDB disables any of
- these breakpoints immediately after stopping your program.
-
-`enable [breakpoints] delete RANGE...'
- Enable the specified breakpoints to work once, then die. GDB
- deletes any of these breakpoints as soon as your program stops
- there. Breakpoints set by the `tbreak' command start out in this
- state.
-
- Except for a breakpoint set with `tbreak' (*note Setting
-Breakpoints: Set Breaks.), breakpoints that you set are initially
-enabled; subsequently, they become disabled or enabled only when you
-use one of the commands above. (The command `until' can set and delete
-a breakpoint of its own, but it does not change the state of your other
-breakpoints; see *note Continuing and Stepping: Continuing and
-Stepping.)
-
-
-File: gdb.info, Node: Conditions, Next: Break Commands, Prev: Disabling, Up: Breakpoints
-
-5.1.6 Break Conditions
-----------------------
-
-The simplest sort of breakpoint breaks every time your program reaches a
-specified place. You can also specify a "condition" for a breakpoint.
-A condition is just a Boolean expression in your programming language
-(*note Expressions: Expressions.). A breakpoint with a condition
-evaluates the expression each time your program reaches it, and your
-program stops only if the condition is _true_.
-
- This is the converse of using assertions for program validation; in
-that situation, you want to stop when the assertion is violated--that
-is, when the condition is false. In C, if you want to test an
-assertion expressed by the condition ASSERT, you should set the
-condition `! ASSERT' on the appropriate breakpoint.
-
- Conditions are also accepted for watchpoints; you may not need them,
-since a watchpoint is inspecting the value of an expression anyhow--but
-it might be simpler, say, to just set a watchpoint on a variable name,
-and specify a condition that tests whether the new value is an
-interesting one.
-
- Break conditions can have side effects, and may even call functions
-in your program. This can be useful, for example, to activate functions
-that log program progress, or to use your own print functions to format
-special data structures. The effects are completely predictable unless
-there is another enabled breakpoint at the same address. (In that
-case, GDB might see the other breakpoint first and stop your program
-without checking the condition of this one.) Note that breakpoint
-commands are usually more convenient and flexible than break conditions
-for the purpose of performing side effects when a breakpoint is reached
-(*note Breakpoint Command Lists: Break Commands.).
-
- Break conditions can be specified when a breakpoint is set, by using
-`if' in the arguments to the `break' command. *Note Setting
-Breakpoints: Set Breaks. They can also be changed at any time with the
-`condition' command.
-
- You can also use the `if' keyword with the `watch' command. The
-`catch' command does not recognize the `if' keyword; `condition' is the
-only way to impose a further condition on a catchpoint.
-
-`condition BNUM EXPRESSION'
- Specify EXPRESSION as the break condition for breakpoint,
- watchpoint, or catchpoint number BNUM. After you set a condition,
- breakpoint BNUM stops your program only if the value of EXPRESSION
- is true (nonzero, in C). When you use `condition', GDB checks
- EXPRESSION immediately for syntactic correctness, and to determine
- whether symbols in it have referents in the context of your
- breakpoint. If EXPRESSION uses symbols not referenced in the
- context of the breakpoint, GDB prints an error message:
-
- No symbol "foo" in current context.
-
- GDB does not actually evaluate EXPRESSION at the time the
- `condition' command (or a command that sets a breakpoint with a
- condition, like `break if ...') is given, however. *Note
- Expressions: Expressions.
-
-`condition BNUM'
- Remove the condition from breakpoint number BNUM. It becomes an
- ordinary unconditional breakpoint.
-
- A special case of a breakpoint condition is to stop only when the
-breakpoint has been reached a certain number of times. This is so
-useful that there is a special way to do it, using the "ignore count"
-of the breakpoint. Every breakpoint has an ignore count, which is an
-integer. Most of the time, the ignore count is zero, and therefore has
-no effect. But if your program reaches a breakpoint whose ignore count
-is positive, then instead of stopping, it just decrements the ignore
-count by one and continues. As a result, if the ignore count value is
-N, the breakpoint does not stop the next N times your program reaches
-it.
-
-`ignore BNUM COUNT'
- Set the ignore count of breakpoint number BNUM to COUNT. The next
- COUNT times the breakpoint is reached, your program's execution
- does not stop; other than to decrement the ignore count, GDB takes
- no action.
-
- To make the breakpoint stop the next time it is reached, specify a
- count of zero.
-
- When you use `continue' to resume execution of your program from a
- breakpoint, you can specify an ignore count directly as an
- argument to `continue', rather than using `ignore'. *Note
- Continuing and Stepping: Continuing and Stepping.
-
- If a breakpoint has a positive ignore count and a condition, the
- condition is not checked. Once the ignore count reaches zero, GDB
- resumes checking the condition.
-
- You could achieve the effect of the ignore count with a condition
- such as `$foo-- <= 0' using a debugger convenience variable that
- is decremented each time. *Note Convenience Variables:
- Convenience Vars.
-
- Ignore counts apply to breakpoints, watchpoints, and catchpoints.
-
-
-File: gdb.info, Node: Break Commands, Next: Save Breakpoints, Prev: Conditions, Up: Breakpoints
-
-5.1.7 Breakpoint Command Lists
-------------------------------
-
-You can give any breakpoint (or watchpoint or catchpoint) a series of
-commands to execute when your program stops due to that breakpoint. For
-example, you might want to print the values of certain expressions, or
-enable other breakpoints.
-
-`commands [RANGE...]'
-`... COMMAND-LIST ...'
-`end'
- Specify a list of commands for the given breakpoints. The commands
- themselves appear on the following lines. Type a line containing
- just `end' to terminate the commands.
-
- To remove all commands from a breakpoint, type `commands' and
- follow it immediately with `end'; that is, give no commands.
-
- With no argument, `commands' refers to the last breakpoint,
- watchpoint, or catchpoint set (not to the breakpoint most recently
- encountered). If the most recent breakpoints were set with a
- single command, then the `commands' will apply to all the
- breakpoints set by that command. This applies to breakpoints set
- by `rbreak', and also applies when a single `break' command
- creates multiple breakpoints (*note Ambiguous Expressions:
- Ambiguous Expressions.).
-
- Pressing <RET> as a means of repeating the last GDB command is
-disabled within a COMMAND-LIST.
-
- You can use breakpoint commands to start your program up again.
-Simply use the `continue' command, or `step', or any other command that
-resumes execution.
-
- Any other commands in the command list, after a command that resumes
-execution, are ignored. This is because any time you resume execution
-(even with a simple `next' or `step'), you may encounter another
-breakpoint--which could have its own command list, leading to
-ambiguities about which list to execute.
-
- If the first command you specify in a command list is `silent', the
-usual message about stopping at a breakpoint is not printed. This may
-be desirable for breakpoints that are to print a specific message and
-then continue. If none of the remaining commands print anything, you
-see no sign that the breakpoint was reached. `silent' is meaningful
-only at the beginning of a breakpoint command list.
-
- The commands `echo', `output', and `printf' allow you to print
-precisely controlled output, and are often useful in silent
-breakpoints. *Note Commands for Controlled Output: Output.
-
- For example, here is how you could use breakpoint commands to print
-the value of `x' at entry to `foo' whenever `x' is positive.
-
- break foo if x>0
- commands
- silent
- printf "x is %d\n",x
- cont
- end
-
- One application for breakpoint commands is to compensate for one bug
-so you can test for another. Put a breakpoint just after the erroneous
-line of code, give it a condition to detect the case in which something
-erroneous has been done, and give it commands to assign correct values
-to any variables that need them. End with the `continue' command so
-that your program does not stop, and start with the `silent' command so
-that no output is produced. Here is an example:
-
- break 403
- commands
- silent
- set x = y + 4
- cont
- end
-
-
-File: gdb.info, Node: Save Breakpoints, Next: Error in Breakpoints, Prev: Break Commands, Up: Breakpoints
-
-5.1.8 How to save breakpoints to a file
----------------------------------------
-
-To save breakpoint definitions to a file use the `save breakpoints'
-command.
-
-`save breakpoints [FILENAME]'
- This command saves all current breakpoint definitions together with
- their commands and ignore counts, into a file `FILENAME' suitable
- for use in a later debugging session. This includes all types of
- breakpoints (breakpoints, watchpoints, catchpoints, tracepoints).
- To read the saved breakpoint definitions, use the `source' command
- (*note Command Files::). Note that watchpoints with expressions
- involving local variables may fail to be recreated because it may
- not be possible to access the context where the watchpoint is
- valid anymore. Because the saved breakpoint definitions are
- simply a sequence of GDB commands that recreate the breakpoints,
- you can edit the file in your favorite editing program, and remove
- the breakpoint definitions you're not interested in, or that can
- no longer be recreated.
-
-
-File: gdb.info, Node: Error in Breakpoints, Next: Breakpoint-related Warnings, Prev: Save Breakpoints, Up: Breakpoints
-
-5.1.9 "Cannot insert breakpoints"
----------------------------------
-
-If you request too many active hardware-assisted breakpoints and
-watchpoints, you will see this error message:
-
- Stopped; cannot insert breakpoints.
- You may have requested too many hardware breakpoints and watchpoints.
-
-This message is printed when you attempt to resume the program, since
-only then GDB knows exactly how many hardware breakpoints and
-watchpoints it needs to insert.
-
- When this message is printed, you need to disable or remove some of
-the hardware-assisted breakpoints and watchpoints, and then continue.
-
-
-File: gdb.info, Node: Breakpoint-related Warnings, Prev: Error in Breakpoints, Up: Breakpoints
-
-5.1.10 "Breakpoint address adjusted..."
----------------------------------------
-
-Some processor architectures place constraints on the addresses at
-which breakpoints may be placed. For architectures thus constrained,
-GDB will attempt to adjust the breakpoint's address to comply with the
-constraints dictated by the architecture.
-
- One example of such an architecture is the Fujitsu FR-V. The FR-V is
-a VLIW architecture in which a number of RISC-like instructions may be
-bundled together for parallel execution. The FR-V architecture
-constrains the location of a breakpoint instruction within such a
-bundle to the instruction with the lowest address. GDB honors this
-constraint by adjusting a breakpoint's address to the first in the
-bundle.
-
- It is not uncommon for optimized code to have bundles which contain
-instructions from different source statements, thus it may happen that
-a breakpoint's address will be adjusted from one source statement to
-another. Since this adjustment may significantly alter GDB's
-breakpoint related behavior from what the user expects, a warning is
-printed when the breakpoint is first set and also when the breakpoint
-is hit.
-
- A warning like the one below is printed when setting a breakpoint
-that's been subject to address adjustment:
-
- warning: Breakpoint address adjusted from 0x00010414 to 0x00010410.
-
- Such warnings are printed both for user settable and GDB's internal
-breakpoints. If you see one of these warnings, you should verify that
-a breakpoint set at the adjusted address will have the desired affect.
-If not, the breakpoint in question may be removed and other breakpoints
-may be set which will have the desired behavior. E.g., it may be
-sufficient to place the breakpoint at a later instruction. A
-conditional breakpoint may also be useful in some cases to prevent the
-breakpoint from triggering too often.
-
- GDB will also issue a warning when stopping at one of these adjusted
-breakpoints:
-
- warning: Breakpoint 1 address previously adjusted from 0x00010414
- to 0x00010410.
-
- When this warning is encountered, it may be too late to take remedial
-action except in cases where the breakpoint is hit earlier or more
-frequently than expected.
-
-
-File: gdb.info, Node: Continuing and Stepping, Next: Signals, Prev: Breakpoints, Up: Stopping
-
-5.2 Continuing and Stepping
-===========================
-
-"Continuing" means resuming program execution until your program
-completes normally. In contrast, "stepping" means executing just one
-more "step" of your program, where "step" may mean either one line of
-source code, or one machine instruction (depending on what particular
-command you use). Either when continuing or when stepping, your
-program may stop even sooner, due to a breakpoint or a signal. (If it
-stops due to a signal, you may want to use `handle', or use `signal 0'
-to resume execution. *Note Signals: Signals.)
-
-`continue [IGNORE-COUNT]'
-`c [IGNORE-COUNT]'
-`fg [IGNORE-COUNT]'
- Resume program execution, at the address where your program last
- stopped; any breakpoints set at that address are bypassed. The
- optional argument IGNORE-COUNT allows you to specify a further
- number of times to ignore a breakpoint at this location; its
- effect is like that of `ignore' (*note Break Conditions:
- Conditions.).
-
- The argument IGNORE-COUNT is meaningful only when your program
- stopped due to a breakpoint. At other times, the argument to
- `continue' is ignored.
-
- The synonyms `c' and `fg' (for "foreground", as the debugged
- program is deemed to be the foreground program) are provided
- purely for convenience, and have exactly the same behavior as
- `continue'.
-
- To resume execution at a different place, you can use `return'
-(*note Returning from a Function: Returning.) to go back to the calling
-function; or `jump' (*note Continuing at a Different Address: Jumping.)
-to go to an arbitrary location in your program.
-
- A typical technique for using stepping is to set a breakpoint (*note
-Breakpoints; Watchpoints; and Catchpoints: Breakpoints.) at the
-beginning of the function or the section of your program where a problem
-is believed to lie, run your program until it stops at that breakpoint,
-and then step through the suspect area, examining the variables that are
-interesting, until you see the problem happen.
-
-`step'
- Continue running your program until control reaches a different
- source line, then stop it and return control to GDB. This command
- is abbreviated `s'.
-
- _Warning:_ If you use the `step' command while control is
- within a function that was compiled without debugging
- information, execution proceeds until control reaches a
- function that does have debugging information. Likewise, it
- will not step into a function which is compiled without
- debugging information. To step through functions without
- debugging information, use the `stepi' command, described
- below.
-
- The `step' command only stops at the first instruction of a source
- line. This prevents the multiple stops that could otherwise occur
- in `switch' statements, `for' loops, etc. `step' continues to
- stop if a function that has debugging information is called within
- the line. In other words, `step' _steps inside_ any functions
- called within the line.
-
- Also, the `step' command only enters a function if there is line
- number information for the function. Otherwise it acts like the
- `next' command. This avoids problems when using `cc -gl' on MIPS
- machines. Previously, `step' entered subroutines if there was any
- debugging information about the routine.
-
-`step COUNT'
- Continue running as in `step', but do so COUNT times. If a
- breakpoint is reached, or a signal not related to stepping occurs
- before COUNT steps, stepping stops right away.
-
-`next [COUNT]'
- Continue to the next source line in the current (innermost) stack
- frame. This is similar to `step', but function calls that appear
- within the line of code are executed without stopping. Execution
- stops when control reaches a different line of code at the
- original stack level that was executing when you gave the `next'
- command. This command is abbreviated `n'.
-
- An argument COUNT is a repeat count, as for `step'.
-
- The `next' command only stops at the first instruction of a source
- line. This prevents multiple stops that could otherwise occur in
- `switch' statements, `for' loops, etc.
-
-`set step-mode'
-`set step-mode on'
- The `set step-mode on' command causes the `step' command to stop
- at the first instruction of a function which contains no debug line
- information rather than stepping over it.
-
- This is useful in cases where you may be interested in inspecting
- the machine instructions of a function which has no symbolic info
- and do not want GDB to automatically skip over this function.
-
-`set step-mode off'
- Causes the `step' command to step over any functions which
- contains no debug information. This is the default.
-
-`show step-mode'
- Show whether GDB will stop in or step over functions without
- source line debug information.
-
-`finish'
- Continue running until just after function in the selected stack
- frame returns. Print the returned value (if any). This command
- can be abbreviated as `fin'.
-
- Contrast this with the `return' command (*note Returning from a
- Function: Returning.).
-
-`until'
-`u'
- Continue running until a source line past the current line, in the
- current stack frame, is reached. This command is used to avoid
- single stepping through a loop more than once. It is like the
- `next' command, except that when `until' encounters a jump, it
- automatically continues execution until the program counter is
- greater than the address of the jump.
-
- This means that when you reach the end of a loop after single
- stepping though it, `until' makes your program continue execution
- until it exits the loop. In contrast, a `next' command at the end
- of a loop simply steps back to the beginning of the loop, which
- forces you to step through the next iteration.
-
- `until' always stops your program if it attempts to exit the
- current stack frame.
-
- `until' may produce somewhat counterintuitive results if the order
- of machine code does not match the order of the source lines. For
- example, in the following excerpt from a debugging session, the `f'
- (`frame') command shows that execution is stopped at line `206';
- yet when we use `until', we get to line `195':
-
- (gdb) f
- #0 main (argc=4, argv=0xf7fffae8) at m4.c:206
- 206 expand_input();
- (gdb) until
- 195 for ( ; argc > 0; NEXTARG) {
-
- This happened because, for execution efficiency, the compiler had
- generated code for the loop closure test at the end, rather than
- the start, of the loop--even though the test in a C `for'-loop is
- written before the body of the loop. The `until' command appeared
- to step back to the beginning of the loop when it advanced to this
- expression; however, it has not really gone to an earlier
- statement--not in terms of the actual machine code.
-
- `until' with no argument works by means of single instruction
- stepping, and hence is slower than `until' with an argument.
-
-`until LOCATION'
-`u LOCATION'
- Continue running your program until either the specified location
- is reached, or the current stack frame returns. LOCATION is any of
- the forms described in *note Specify Location::. This form of the
- command uses temporary breakpoints, and hence is quicker than
- `until' without an argument. The specified location is actually
- reached only if it is in the current frame. This implies that
- `until' can be used to skip over recursive function invocations.
- For instance in the code below, if the current location is line
- `96', issuing `until 99' will execute the program up to line `99'
- in the same invocation of factorial, i.e., after the inner
- invocations have returned.
-
- 94 int factorial (int value)
- 95 {
- 96 if (value > 1) {
- 97 value *= factorial (value - 1);
- 98 }
- 99 return (value);
- 100 }
-
-`advance LOCATION'
- Continue running the program up to the given LOCATION. An
- argument is required, which should be of one of the forms
- described in *note Specify Location::. Execution will also stop
- upon exit from the current stack frame. This command is similar
- to `until', but `advance' will not skip over recursive function
- calls, and the target location doesn't have to be in the same
- frame as the current one.
-
-`stepi'
-`stepi ARG'
-`si'
- Execute one machine instruction, then stop and return to the
- debugger.
-
- It is often useful to do `display/i $pc' when stepping by machine
- instructions. This makes GDB automatically display the next
- instruction to be executed, each time your program stops. *Note
- Automatic Display: Auto Display.
-
- An argument is a repeat count, as in `step'.
-
-`nexti'
-`nexti ARG'
-`ni'
- Execute one machine instruction, but if it is a function call,
- proceed until the function returns.
-
- An argument is a repeat count, as in `next'.
-
-
-File: gdb.info, Node: Signals, Next: Thread Stops, Prev: Continuing and Stepping, Up: Stopping
-
-5.3 Signals
-===========
-
-A signal is an asynchronous event that can happen in a program. The
-operating system defines the possible kinds of signals, and gives each
-kind a name and a number. For example, in Unix `SIGINT' is the signal
-a program gets when you type an interrupt character (often `Ctrl-c');
-`SIGSEGV' is the signal a program gets from referencing a place in
-memory far away from all the areas in use; `SIGALRM' occurs when the
-alarm clock timer goes off (which happens only if your program has
-requested an alarm).
-
- Some signals, including `SIGALRM', are a normal part of the
-functioning of your program. Others, such as `SIGSEGV', indicate
-errors; these signals are "fatal" (they kill your program immediately)
-if the program has not specified in advance some other way to handle
-the signal. `SIGINT' does not indicate an error in your program, but
-it is normally fatal so it can carry out the purpose of the interrupt:
-to kill the program.
-
- GDB has the ability to detect any occurrence of a signal in your
-program. You can tell GDB in advance what to do for each kind of
-signal.
-
- Normally, GDB is set up to let the non-erroneous signals like
-`SIGALRM' be silently passed to your program (so as not to interfere
-with their role in the program's functioning) but to stop your program
-immediately whenever an error signal happens. You can change these
-settings with the `handle' command.
-
-`info signals'
-`info handle'
- Print a table of all the kinds of signals and how GDB has been
- told to handle each one. You can use this to see the signal
- numbers of all the defined types of signals.
-
-`info signals SIG'
- Similar, but print information only about the specified signal
- number.
-
- `info handle' is an alias for `info signals'.
-
-`handle SIGNAL [KEYWORDS...]'
- Change the way GDB handles signal SIGNAL. SIGNAL can be the
- number of a signal or its name (with or without the `SIG' at the
- beginning); a list of signal numbers of the form `LOW-HIGH'; or
- the word `all', meaning all the known signals. Optional arguments
- KEYWORDS, described below, say what change to make.
-
- The keywords allowed by the `handle' command can be abbreviated.
-Their full names are:
-
-`nostop'
- GDB should not stop your program when this signal happens. It may
- still print a message telling you that the signal has come in.
-
-`stop'
- GDB should stop your program when this signal happens. This
- implies the `print' keyword as well.
-
-`print'
- GDB should print a message when this signal happens.
-
-`noprint'
- GDB should not mention the occurrence of the signal at all. This
- implies the `nostop' keyword as well.
-
-`pass'
-`noignore'
- GDB should allow your program to see this signal; your program can
- handle the signal, or else it may terminate if the signal is fatal
- and not handled. `pass' and `noignore' are synonyms.
-
-`nopass'
-`ignore'
- GDB should not allow your program to see this signal. `nopass'
- and `ignore' are synonyms.
-
- When a signal stops your program, the signal is not visible to the
-program until you continue. Your program sees the signal then, if
-`pass' is in effect for the signal in question _at that time_. In
-other words, after GDB reports a signal, you can use the `handle'
-command with `pass' or `nopass' to control whether your program sees
-that signal when you continue.
-
- The default is set to `nostop', `noprint', `pass' for non-erroneous
-signals such as `SIGALRM', `SIGWINCH' and `SIGCHLD', and to `stop',
-`print', `pass' for the erroneous signals.
-
- You can also use the `signal' command to prevent your program from
-seeing a signal, or cause it to see a signal it normally would not see,
-or to give it any signal at any time. For example, if your program
-stopped due to some sort of memory reference error, you might store
-correct values into the erroneous variables and continue, hoping to see
-more execution; but your program would probably terminate immediately as
-a result of the fatal signal once it saw the signal. To prevent this,
-you can continue with `signal 0'. *Note Giving your Program a Signal:
-Signaling.
-
- On some targets, GDB can inspect extra signal information associated
-with the intercepted signal, before it is actually delivered to the
-program being debugged. This information is exported by the
-convenience variable `$_siginfo', and consists of data that is passed
-by the kernel to the signal handler at the time of the receipt of a
-signal. The data type of the information itself is target dependent.
-You can see the data type using the `ptype $_siginfo' command. On Unix
-systems, it typically corresponds to the standard `siginfo_t' type, as
-defined in the `signal.h' system header.
-
- Here's an example, on a GNU/Linux system, printing the stray
-referenced address that raised a segmentation fault.
-
- (gdb) continue
- Program received signal SIGSEGV, Segmentation fault.
- 0x0000000000400766 in main ()
- 69 *(int *)p = 0;
- (gdb) ptype $_siginfo
- type = struct {
- int si_signo;
- int si_errno;
- int si_code;
- union {
- int _pad[28];
- struct {...} _kill;
- struct {...} _timer;
- struct {...} _rt;
- struct {...} _sigchld;
- struct {...} _sigfault;
- struct {...} _sigpoll;
- } _sifields;
- }
- (gdb) ptype $_siginfo._sifields._sigfault
- type = struct {
- void *si_addr;
- }
- (gdb) p $_siginfo._sifields._sigfault.si_addr
- $1 = (void *) 0x7ffff7ff7000
-
- Depending on target support, `$_siginfo' may also be writable.
-
-
-File: gdb.info, Node: Thread Stops, Prev: Signals, Up: Stopping
-
-5.4 Stopping and Starting Multi-thread Programs
-===============================================
-
-GDB supports debugging programs with multiple threads (*note Debugging
-Programs with Multiple Threads: Threads.). There are two modes of
-controlling execution of your program within the debugger. In the
-default mode, referred to as "all-stop mode", when any thread in your
-program stops (for example, at a breakpoint or while being stepped),
-all other threads in the program are also stopped by GDB. On some
-targets, GDB also supports "non-stop mode", in which other threads can
-continue to run freely while you examine the stopped thread in the
-debugger.
-
-* Menu:
-
-* All-Stop Mode:: All threads stop when GDB takes control
-* Non-Stop Mode:: Other threads continue to execute
-* Background Execution:: Running your program asynchronously
-* Thread-Specific Breakpoints:: Controlling breakpoints
-* Interrupted System Calls:: GDB may interfere with system calls
-* Observer Mode:: GDB does not alter program behavior
-
-
-File: gdb.info, Node: All-Stop Mode, Next: Non-Stop Mode, Up: Thread Stops
-
-5.4.1 All-Stop Mode
--------------------
-
-In all-stop mode, whenever your program stops under GDB for any reason,
-_all_ threads of execution stop, not just the current thread. This
-allows you to examine the overall state of the program, including
-switching between threads, without worrying that things may change
-underfoot.
-
- Conversely, whenever you restart the program, _all_ threads start
-executing. _This is true even when single-stepping_ with commands like
-`step' or `next'.
-
- In particular, GDB cannot single-step all threads in lockstep.
-Since thread scheduling is up to your debugging target's operating
-system (not controlled by GDB), other threads may execute more than one
-statement while the current thread completes a single step. Moreover,
-in general other threads stop in the middle of a statement, rather than
-at a clean statement boundary, when the program stops.
-
- You might even find your program stopped in another thread after
-continuing or even single-stepping. This happens whenever some other
-thread runs into a breakpoint, a signal, or an exception before the
-first thread completes whatever you requested.
-
- Whenever GDB stops your program, due to a breakpoint or a signal, it
-automatically selects the thread where that breakpoint or signal
-happened. GDB alerts you to the context switch with a message such as
-`[Switching to Thread N]' to identify the thread.
-
- On some OSes, you can modify GDB's default behavior by locking the
-OS scheduler to allow only a single thread to run.
-
-`set scheduler-locking MODE'
- Set the scheduler locking mode. If it is `off', then there is no
- locking and any thread may run at any time. If `on', then only the
- current thread may run when the inferior is resumed. The `step'
- mode optimizes for single-stepping; it prevents other threads from
- preempting the current thread while you are stepping, so that the
- focus of debugging does not change unexpectedly. Other threads
- only rarely (or never) get a chance to run when you step. They
- are more likely to run when you `next' over a function call, and
- they are completely free to run when you use commands like
- `continue', `until', or `finish'. However, unless another thread
- hits a breakpoint during its timeslice, GDB does not change the
- current thread away from the thread that you are debugging.
-
-`show scheduler-locking'
- Display the current scheduler locking mode.
-
- By default, when you issue one of the execution commands such as
-`continue', `next' or `step', GDB allows only threads of the current
-inferior to run. For example, if GDB is attached to two inferiors,
-each with two threads, the `continue' command resumes only the two
-threads of the current inferior. This is useful, for example, when you
-debug a program that forks and you want to hold the parent stopped (so
-that, for instance, it doesn't run to exit), while you debug the child.
-In other situations, you may not be interested in inspecting the
-current state of any of the processes GDB is attached to, and you may
-want to resume them all until some breakpoint is hit. In the latter
-case, you can instruct GDB to allow all threads of all the inferiors to
-run with the `set schedule-multiple' command.
-
-`set schedule-multiple'
- Set the mode for allowing threads of multiple processes to be
- resumed when an execution command is issued. When `on', all
- threads of all processes are allowed to run. When `off', only the
- threads of the current process are resumed. The default is `off'.
- The `scheduler-locking' mode takes precedence when set to `on', or
- while you are stepping and set to `step'.
-
-`show schedule-multiple'
- Display the current mode for resuming the execution of threads of
- multiple processes.
-
-
-File: gdb.info, Node: Non-Stop Mode, Next: Background Execution, Prev: All-Stop Mode, Up: Thread Stops
-
-5.4.2 Non-Stop Mode
--------------------
-
-For some multi-threaded targets, GDB supports an optional mode of
-operation in which you can examine stopped program threads in the
-debugger while other threads continue to execute freely. This
-minimizes intrusion when debugging live systems, such as programs where
-some threads have real-time constraints or must continue to respond to
-external events. This is referred to as "non-stop" mode.
-
- In non-stop mode, when a thread stops to report a debugging event,
-_only_ that thread is stopped; GDB does not stop other threads as well,
-in contrast to the all-stop mode behavior. Additionally, execution
-commands such as `continue' and `step' apply by default only to the
-current thread in non-stop mode, rather than all threads as in all-stop
-mode. This allows you to control threads explicitly in ways that are
-not possible in all-stop mode -- for example, stepping one thread while
-allowing others to run freely, stepping one thread while holding all
-others stopped, or stepping several threads independently and
-simultaneously.
-
- To enter non-stop mode, use this sequence of commands before you run
-or attach to your program:
-
- # Enable the async interface.
- set target-async 1
-
- # If using the CLI, pagination breaks non-stop.
- set pagination off
-
- # Finally, turn it on!
- set non-stop on
-
- You can use these commands to manipulate the non-stop mode setting:
-
-`set non-stop on'
- Enable selection of non-stop mode.
-
-`set non-stop off'
- Disable selection of non-stop mode.
-
-`show non-stop'
- Show the current non-stop enablement setting.
-
- Note these commands only reflect whether non-stop mode is enabled,
-not whether the currently-executing program is being run in non-stop
-mode. In particular, the `set non-stop' preference is only consulted
-when GDB starts or connects to the target program, and it is generally
-not possible to switch modes once debugging has started. Furthermore,
-since not all targets support non-stop mode, even when you have enabled
-non-stop mode, GDB may still fall back to all-stop operation by default.
-
- In non-stop mode, all execution commands apply only to the current
-thread by default. That is, `continue' only continues one thread. To
-continue all threads, issue `continue -a' or `c -a'.
-
- You can use GDB's background execution commands (*note Background
-Execution::) to run some threads in the background while you continue
-to examine or step others from GDB. The MI execution commands (*note
-GDB/MI Program Execution::) are always executed asynchronously in
-non-stop mode.
-
- Suspending execution is done with the `interrupt' command when
-running in the background, or `Ctrl-c' during foreground execution. In
-all-stop mode, this stops the whole process; but in non-stop mode the
-interrupt applies only to the current thread. To stop the whole
-program, use `interrupt -a'.
-
- Other execution commands do not currently support the `-a' option.
-
- In non-stop mode, when a thread stops, GDB doesn't automatically make
-that thread current, as it does in all-stop mode. This is because the
-thread stop notifications are asynchronous with respect to GDB's
-command interpreter, and it would be confusing if GDB unexpectedly
-changed to a different thread just as you entered a command to operate
-on the previously current thread.
-
-
-File: gdb.info, Node: Background Execution, Next: Thread-Specific Breakpoints, Prev: Non-Stop Mode, Up: Thread Stops
-
-5.4.3 Background Execution
---------------------------
-
-GDB's execution commands have two variants: the normal foreground
-(synchronous) behavior, and a background (asynchronous) behavior. In
-foreground execution, GDB waits for the program to report that some
-thread has stopped before prompting for another command. In background
-execution, GDB immediately gives a command prompt so that you can issue
-other commands while your program runs.
-
- You need to explicitly enable asynchronous mode before you can use
-background execution commands. You can use these commands to
-manipulate the asynchronous mode setting:
-
-`set target-async on'
- Enable asynchronous mode.
-
-`set target-async off'
- Disable asynchronous mode.
-
-`show target-async'
- Show the current target-async setting.
-
- If the target doesn't support async mode, GDB issues an error
-message if you attempt to use the background execution commands.
-
- To specify background execution, add a `&' to the command. For
-example, the background form of the `continue' command is `continue&',
-or just `c&'. The execution commands that accept background execution
-are:
-
-`run'
- *Note Starting your Program: Starting.
-
-`attach'
- *Note Debugging an Already-running Process: Attach.
-
-`step'
- *Note step: Continuing and Stepping.
-
-`stepi'
- *Note stepi: Continuing and Stepping.
-
-`next'
- *Note next: Continuing and Stepping.
-
-`nexti'
- *Note nexti: Continuing and Stepping.
-
-`continue'
- *Note continue: Continuing and Stepping.
-
-`finish'
- *Note finish: Continuing and Stepping.
-
-`until'
- *Note until: Continuing and Stepping.
-
-
- Background execution is especially useful in conjunction with
-non-stop mode for debugging programs with multiple threads; see *note
-Non-Stop Mode::. However, you can also use these commands in the
-normal all-stop mode with the restriction that you cannot issue another
-execution command until the previous one finishes. Examples of
-commands that are valid in all-stop mode while the program is running
-include `help' and `info break'.
-
- You can interrupt your program while it is running in the background
-by using the `interrupt' command.
-
-`interrupt'
-`interrupt -a'
- Suspend execution of the running program. In all-stop mode,
- `interrupt' stops the whole process, but in non-stop mode, it stops
- only the current thread. To stop the whole program in non-stop
- mode, use `interrupt -a'.
-
-
-File: gdb.info, Node: Thread-Specific Breakpoints, Next: Interrupted System Calls, Prev: Background Execution, Up: Thread Stops
-
-5.4.4 Thread-Specific Breakpoints
----------------------------------
-
-When your program has multiple threads (*note Debugging Programs with
-Multiple Threads: Threads.), you can choose whether to set breakpoints
-on all threads, or on a particular thread.
-
-`break LINESPEC thread THREADNO'
-`break LINESPEC thread THREADNO if ...'
- LINESPEC specifies source lines; there are several ways of writing
- them (*note Specify Location::), but the effect is always to
- specify some source line.
-
- Use the qualifier `thread THREADNO' with a breakpoint command to
- specify that you only want GDB to stop the program when a
- particular thread reaches this breakpoint. THREADNO is one of the
- numeric thread identifiers assigned by GDB, shown in the first
- column of the `info threads' display.
-
- If you do not specify `thread THREADNO' when you set a breakpoint,
- the breakpoint applies to _all_ threads of your program.
-
- You can use the `thread' qualifier on conditional breakpoints as
- well; in this case, place `thread THREADNO' before or after the
- breakpoint condition, like this:
-
- (gdb) break frik.c:13 thread 28 if bartab > lim
-
-
-
-File: gdb.info, Node: Interrupted System Calls, Next: Observer Mode, Prev: Thread-Specific Breakpoints, Up: Thread Stops
-
-5.4.5 Interrupted System Calls
-------------------------------
-
-There is an unfortunate side effect when using GDB to debug
-multi-threaded programs. If one thread stops for a breakpoint, or for
-some other reason, and another thread is blocked in a system call, then
-the system call may return prematurely. This is a consequence of the
-interaction between multiple threads and the signals that GDB uses to
-implement breakpoints and other events that stop execution.
-
- To handle this problem, your program should check the return value of
-each system call and react appropriately. This is good programming
-style anyways.
-
- For example, do not write code like this:
-
- sleep (10);
-
- The call to `sleep' will return early if a different thread stops at
-a breakpoint or for some other reason.
-
- Instead, write this:
-
- int unslept = 10;
- while (unslept > 0)
- unslept = sleep (unslept);
-
- A system call is allowed to return early, so the system is still
-conforming to its specification. But GDB does cause your
-multi-threaded program to behave differently than it would without GDB.
-
- Also, GDB uses internal breakpoints in the thread library to monitor
-certain events such as thread creation and thread destruction. When
-such an event happens, a system call in another thread may return
-prematurely, even though your program does not appear to stop.
-
-
-File: gdb.info, Node: Observer Mode, Prev: Interrupted System Calls, Up: Thread Stops
-
-5.4.6 Observer Mode
--------------------
-
-If you want to build on non-stop mode and observe program behavior
-without any chance of disruption by GDB, you can set variables to
-disable all of the debugger's attempts to modify state, whether by
-writing memory, inserting breakpoints, etc. These operate at a low
-level, intercepting operations from all commands.
-
- When all of these are set to `off', then GDB is said to be "observer
-mode". As a convenience, the variable `observer' can be set to disable
-these, plus enable non-stop mode.
-
- Note that GDB will not prevent you from making nonsensical
-combinations of these settings. For instance, if you have enabled
-`may-insert-breakpoints' but disabled `may-write-memory', then
-breakpoints that work by writing trap instructions into the code stream
-will still not be able to be placed.
-
-`set observer on'
-`set observer off'
- When set to `on', this disables all the permission variables below
- (except for `insert-fast-tracepoints'), plus enables non-stop
- debugging. Setting this to `off' switches back to normal
- debugging, though remaining in non-stop mode.
-
-`show observer'
- Show whether observer mode is on or off.
-
-`set may-write-registers on'
-`set may-write-registers off'
- This controls whether GDB will attempt to alter the values of
- registers, such as with assignment expressions in `print', or the
- `jump' command. It defaults to `on'.
-
-`show may-write-registers'
- Show the current permission to write registers.
-
-`set may-write-memory on'
-`set may-write-memory off'
- This controls whether GDB will attempt to alter the contents of
- memory, such as with assignment expressions in `print'. It
- defaults to `on'.
-
-`show may-write-memory'
- Show the current permission to write memory.
-
-`set may-insert-breakpoints on'
-`set may-insert-breakpoints off'
- This controls whether GDB will attempt to insert breakpoints.
- This affects all breakpoints, including internal breakpoints
- defined by GDB. It defaults to `on'.
-
-`show may-insert-breakpoints'
- Show the current permission to insert breakpoints.
-
-`set may-insert-tracepoints on'
-`set may-insert-tracepoints off'
- This controls whether GDB will attempt to insert (regular)
- tracepoints at the beginning of a tracing experiment. It affects
- only non-fast tracepoints, fast tracepoints being under the
- control of `may-insert-fast-tracepoints'. It defaults to `on'.
-
-`show may-insert-tracepoints'
- Show the current permission to insert tracepoints.
-
-`set may-insert-fast-tracepoints on'
-`set may-insert-fast-tracepoints off'
- This controls whether GDB will attempt to insert fast tracepoints
- at the beginning of a tracing experiment. It affects only fast
- tracepoints, regular (non-fast) tracepoints being under the
- control of `may-insert-tracepoints'. It defaults to `on'.
-
-`show may-insert-fast-tracepoints'
- Show the current permission to insert fast tracepoints.
-
-`set may-interrupt on'
-`set may-interrupt off'
- This controls whether GDB will attempt to interrupt or stop
- program execution. When this variable is `off', the `interrupt'
- command will have no effect, nor will `Ctrl-c'. It defaults to
- `on'.
-
-`show may-interrupt'
- Show the current permission to interrupt or stop the program.
-
-
-
-File: gdb.info, Node: Reverse Execution, Next: Process Record and Replay, Prev: Stopping, Up: Top
-
-6 Running programs backward
-***************************
-
-When you are debugging a program, it is not unusual to realize that you
-have gone too far, and some event of interest has already happened. If
-the target environment supports it, GDB can allow you to "rewind" the
-program by running it backward.
-
- A target environment that supports reverse execution should be able
-to "undo" the changes in machine state that have taken place as the
-program was executing normally. Variables, registers etc. should
-revert to their previous values. Obviously this requires a great deal
-of sophistication on the part of the target environment; not all target
-environments can support reverse execution.
-
- When a program is executed in reverse, the instructions that have
-most recently been executed are "un-executed", in reverse order. The
-program counter runs backward, following the previous thread of
-execution in reverse. As each instruction is "un-executed", the values
-of memory and/or registers that were changed by that instruction are
-reverted to their previous states. After executing a piece of source
-code in reverse, all side effects of that code should be "undone", and
-all variables should be returned to their prior values(1).
-
- If you are debugging in a target environment that supports reverse
-execution, GDB provides the following commands.
-
-`reverse-continue [IGNORE-COUNT]'
-`rc [IGNORE-COUNT]'
- Beginning at the point where your program last stopped, start
- executing in reverse. Reverse execution will stop for breakpoints
- and synchronous exceptions (signals), just like normal execution.
- Behavior of asynchronous signals depends on the target environment.
-
-`reverse-step [COUNT]'
- Run the program backward until control reaches the start of a
- different source line; then stop it, and return control to GDB.
-
- Like the `step' command, `reverse-step' will only stop at the
- beginning of a source line. It "un-executes" the previously
- executed source line. If the previous source line included calls
- to debuggable functions, `reverse-step' will step (backward) into
- the called function, stopping at the beginning of the _last_
- statement in the called function (typically a return statement).
-
- Also, as with the `step' command, if non-debuggable functions are
- called, `reverse-step' will run thru them backward without
- stopping.
-
-`reverse-stepi [COUNT]'
- Reverse-execute one machine instruction. Note that the instruction
- to be reverse-executed is _not_ the one pointed to by the program
- counter, but the instruction executed prior to that one. For
- instance, if the last instruction was a jump, `reverse-stepi' will
- take you back from the destination of the jump to the jump
- instruction itself.
-
-`reverse-next [COUNT]'
- Run backward to the beginning of the previous line executed in the
- current (innermost) stack frame. If the line contains function
- calls, they will be "un-executed" without stopping. Starting from
- the first line of a function, `reverse-next' will take you back to
- the caller of that function, _before_ the function was called,
- just as the normal `next' command would take you from the last
- line of a function back to its return to its caller (2).
-
-`reverse-nexti [COUNT]'
- Like `nexti', `reverse-nexti' executes a single instruction in
- reverse, except that called functions are "un-executed" atomically.
- That is, if the previously executed instruction was a return from
- another function, `reverse-nexti' will continue to execute in
- reverse until the call to that function (from the current stack
- frame) is reached.
-
-`reverse-finish'
- Just as the `finish' command takes you to the point where the
- current function returns, `reverse-finish' takes you to the point
- where it was called. Instead of ending up at the end of the
- current function invocation, you end up at the beginning.
-
-`set exec-direction'
- Set the direction of target execution.
-
-`set exec-direction reverse'
- GDB will perform all execution commands in reverse, until the
- exec-direction mode is changed to "forward". Affected commands
- include `step, stepi, next, nexti, continue, and finish'. The
- `return' command cannot be used in reverse mode.
-
-`set exec-direction forward'
- GDB will perform all execution commands in the normal fashion.
- This is the default.
-
- ---------- Footnotes ----------
-
- (1) Note that some side effects are easier to undo than others. For
-instance, memory and registers are relatively easy, but device I/O is
-hard. Some targets may be able undo things like device I/O, and some
-may not.
-
- The contract between GDB and the reverse executing target requires
-only that the target do something reasonable when GDB tells it to
-execute backwards, and then report the results back to GDB. Whatever
-the target reports back to GDB, GDB will report back to the user. GDB
-assumes that the memory and registers that the target reports are in a
-consistant state, but GDB accepts whatever it is given.
-
- (2) Unless the code is too heavily optimized.
-
-
-File: gdb.info, Node: Process Record and Replay, Next: Stack, Prev: Reverse Execution, Up: Top
-
-7 Recording Inferior's Execution and Replaying It
-*************************************************
-
-On some platforms, GDB provides a special "process record and replay"
-target that can record a log of the process execution, and replay it
-later with both forward and reverse execution commands.
-
- When this target is in use, if the execution log includes the record
-for the next instruction, GDB will debug in "replay mode". In the
-replay mode, the inferior does not really execute code instructions.
-Instead, all the events that normally happen during code execution are
-taken from the execution log. While code is not really executed in
-replay mode, the values of registers (including the program counter
-register) and the memory of the inferior are still changed as they
-normally would. Their contents are taken from the execution log.
-
- If the record for the next instruction is not in the execution log,
-GDB will debug in "record mode". In this mode, the inferior executes
-normally, and GDB records the execution log for future replay.
-
- The process record and replay target supports reverse execution
-(*note Reverse Execution::), even if the platform on which the inferior
-runs does not. However, the reverse execution is limited in this case
-by the range of the instructions recorded in the execution log. In
-other words, reverse execution on platforms that don't support it
-directly can only be done in the replay mode.
-
- When debugging in the reverse direction, GDB will work in replay
-mode as long as the execution log includes the record for the previous
-instruction; otherwise, it will work in record mode, if the platform
-supports reverse execution, or stop if not.
-
- For architecture environments that support process record and replay,
-GDB provides the following commands:
-
-`target record'
- This command starts the process record and replay target. The
- process record and replay target can only debug a process that is
- already running. Therefore, you need first to start the process
- with the `run' or `start' commands, and then start the recording
- with the `target record' command.
-
- Both `record' and `rec' are aliases of `target record'.
-
- Displaced stepping (*note displaced stepping: Maintenance
- Commands.) will be automatically disabled when process record and
- replay target is started. That's because the process record and
- replay target doesn't support displaced stepping.
-
- If the inferior is in the non-stop mode (*note Non-Stop Mode::) or
- in the asynchronous execution mode (*note Background Execution::),
- the process record and replay target cannot be started because it
- doesn't support these two modes.
-
-`record stop'
- Stop the process record and replay target. When process record and
- replay target stops, the entire execution log will be deleted and
- the inferior will either be terminated, or will remain in its
- final state.
-
- When you stop the process record and replay target in record mode
- (at the end of the execution log), the inferior will be stopped at
- the next instruction that would have been recorded. In other
- words, if you record for a while and then stop recording, the
- inferior process will be left in the same state as if the
- recording never happened.
-
- On the other hand, if the process record and replay target is
- stopped while in replay mode (that is, not at the end of the
- execution log, but at some earlier point), the inferior process
- will become "live" at that earlier state, and it will then be
- possible to continue the usual "live" debugging of the process
- from that state.
-
- When the inferior process exits, or GDB detaches from it, process
- record and replay target will automatically stop itself.
-
-`record save FILENAME'
- Save the execution log to a file `FILENAME'. Default filename is
- `gdb_record.PROCESS_ID', where PROCESS_ID is the process ID of the
- inferior.
-
-`record restore FILENAME'
- Restore the execution log from a file `FILENAME'. File must have
- been created with `record save'.
-
-`set record insn-number-max LIMIT'
- Set the limit of instructions to be recorded. Default value is
- 200000.
-
- If LIMIT is a positive number, then GDB will start deleting
- instructions from the log once the number of the record
- instructions becomes greater than LIMIT. For every new recorded
- instruction, GDB will delete the earliest recorded instruction to
- keep the number of recorded instructions at the limit. (Since
- deleting recorded instructions loses information, GDB lets you
- control what happens when the limit is reached, by means of the
- `stop-at-limit' option, described below.)
-
- If LIMIT is zero, GDB will never delete recorded instructions from
- the execution log. The number of recorded instructions is
- unlimited in this case.
-
-`show record insn-number-max'
- Show the limit of instructions to be recorded.
-
-`set record stop-at-limit'
- Control the behavior when the number of recorded instructions
- reaches the limit. If ON (the default), GDB will stop when the
- limit is reached for the first time and ask you whether you want
- to stop the inferior or continue running it and recording the
- execution log. If you decide to continue recording, each new
- recorded instruction will cause the oldest one to be deleted.
-
- If this option is OFF, GDB will automatically delete the oldest
- record to make room for each new one, without asking.
-
-`show record stop-at-limit'
- Show the current setting of `stop-at-limit'.
-
-`set record memory-query'
- Control the behavior when GDB is unable to record memory changes
- caused by an instruction. If ON, GDB will query whether to stop
- the inferior in that case.
-
- If this option is OFF (the default), GDB will automatically ignore
- the effect of such instructions on memory. Later, when GDB
- replays this execution log, it will mark the log of this
- instruction as not accessible, and it will not affect the replay
- results.
-
-`show record memory-query'
- Show the current setting of `memory-query'.
-
-`info record'
- Show various statistics about the state of process record and its
- in-memory execution log buffer, including:
-
- * Whether in record mode or replay mode.
-
- * Lowest recorded instruction number (counting from when the
- current execution log started recording instructions).
-
- * Highest recorded instruction number.
-
- * Current instruction about to be replayed (if in replay mode).
-
- * Number of instructions contained in the execution log.
-
- * Maximum number of instructions that may be contained in the
- execution log.
-
-`record delete'
- When record target runs in replay mode ("in the past"), delete the
- subsequent execution log and begin to record a new execution log
- starting from the current address. This means you will abandon
- the previously recorded "future" and begin recording a new
- "future".
-
-
-File: gdb.info, Node: Stack, Next: Source, Prev: Process Record and Replay, Up: Top
-
-8 Examining the Stack
-*********************
-
-When your program has stopped, the first thing you need to know is
-where it stopped and how it got there.
-
- Each time your program performs a function call, information about
-the call is generated. That information includes the location of the
-call in your program, the arguments of the call, and the local
-variables of the function being called. The information is saved in a
-block of data called a "stack frame". The stack frames are allocated
-in a region of memory called the "call stack".
-
- When your program stops, the GDB commands for examining the stack
-allow you to see all of this information.
-
- One of the stack frames is "selected" by GDB and many GDB commands
-refer implicitly to the selected frame. In particular, whenever you
-ask GDB for the value of a variable in your program, the value is found
-in the selected frame. There are special GDB commands to select
-whichever frame you are interested in. *Note Selecting a Frame:
-Selection.
-
- When your program stops, GDB automatically selects the currently
-executing frame and describes it briefly, similar to the `frame'
-command (*note Information about a Frame: Frame Info.).
-
-* Menu:
-
-* Frames:: Stack frames
-* Backtrace:: Backtraces
-* Selection:: Selecting a frame
-* Frame Info:: Information on a frame
-
-
-File: gdb.info, Node: Frames, Next: Backtrace, Up: Stack
-
-8.1 Stack Frames
-================
-
-The call stack is divided up into contiguous pieces called "stack
-frames", or "frames" for short; each frame is the data associated with
-one call to one function. The frame contains the arguments given to
-the function, the function's local variables, and the address at which
-the function is executing.
-
- When your program is started, the stack has only one frame, that of
-the function `main'. This is called the "initial" frame or the
-"outermost" frame. Each time a function is called, a new frame is
-made. Each time a function returns, the frame for that function
-invocation is eliminated. If a function is recursive, there can be
-many frames for the same function. The frame for the function in which
-execution is actually occurring is called the "innermost" frame. This
-is the most recently created of all the stack frames that still exist.
-
- Inside your program, stack frames are identified by their addresses.
-A stack frame consists of many bytes, each of which has its own
-address; each kind of computer has a convention for choosing one byte
-whose address serves as the address of the frame. Usually this address
-is kept in a register called the "frame pointer register" (*note $fp:
-Registers.) while execution is going on in that frame.
-
- GDB assigns numbers to all existing stack frames, starting with zero
-for the innermost frame, one for the frame that called it, and so on
-upward. These numbers do not really exist in your program; they are
-assigned by GDB to give you a way of designating stack frames in GDB
-commands.
-
- Some compilers provide a way to compile functions so that they
-operate without stack frames. (For example, the GCC option
- `-fomit-frame-pointer'
- generates functions without a frame.) This is occasionally done
-with heavily used library functions to save the frame setup time. GDB
-has limited facilities for dealing with these function invocations. If
-the innermost function invocation has no stack frame, GDB nevertheless
-regards it as though it had a separate frame, which is numbered zero as
-usual, allowing correct tracing of the function call chain. However,
-GDB has no provision for frameless functions elsewhere in the stack.
-
-`frame ARGS'
- The `frame' command allows you to move from one stack frame to
- another, and to print the stack frame you select. ARGS may be
- either the address of the frame or the stack frame number.
- Without an argument, `frame' prints the current stack frame.
-
-`select-frame'
- The `select-frame' command allows you to move from one stack frame
- to another without printing the frame. This is the silent version
- of `frame'.
-
-
-File: gdb.info, Node: Backtrace, Next: Selection, Prev: Frames, Up: Stack
-
-8.2 Backtraces
-==============
-
-A backtrace is a summary of how your program got where it is. It shows
-one line per frame, for many frames, starting with the currently
-executing frame (frame zero), followed by its caller (frame one), and
-on up the stack.
-
-`backtrace'
-`bt'
- Print a backtrace of the entire stack: one line per frame for all
- frames in the stack.
-
- You can stop the backtrace at any time by typing the system
- interrupt character, normally `Ctrl-c'.
-
-`backtrace N'
-`bt N'
- Similar, but print only the innermost N frames.
-
-`backtrace -N'
-`bt -N'
- Similar, but print only the outermost N frames.
-
-`backtrace full'
-`bt full'
-`bt full N'
-`bt full -N'
- Print the values of the local variables also. N specifies the
- number of frames to print, as described above.
-
- The names `where' and `info stack' (abbreviated `info s') are
-additional aliases for `backtrace'.
-
- In a multi-threaded program, GDB by default shows the backtrace only
-for the current thread. To display the backtrace for several or all of
-the threads, use the command `thread apply' (*note thread apply:
-Threads.). For example, if you type `thread apply all backtrace', GDB
-will display the backtrace for all the threads; this is handy when you
-debug a core dump of a multi-threaded program.
-
- Each line in the backtrace shows the frame number and the function
-name. The program counter value is also shown--unless you use `set
-print address off'. The backtrace also shows the source file name and
-line number, as well as the arguments to the function. The program
-counter value is omitted if it is at the beginning of the code for that
-line number.
-
- Here is an example of a backtrace. It was made with the command `bt
-3', so it shows the innermost three frames.
-
- #0 m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8)
- at builtin.c:993
- #1 0x6e38 in expand_macro (sym=0x2b600, data=...) at macro.c:242
- #2 0x6840 in expand_token (obs=0x0, t=177664, td=0xf7fffb08)
- at macro.c:71
- (More stack frames follow...)
-
-The display for frame zero does not begin with a program counter value,
-indicating that your program has stopped at the beginning of the code
-for line `993' of `builtin.c'.
-
-The value of parameter `data' in frame 1 has been replaced by `...'.
-By default, GDB prints the value of a parameter only if it is a scalar
-(integer, pointer, enumeration, etc). See command `set print
-frame-arguments' in *note Print Settings:: for more details on how to
-configure the way function parameter values are printed.
-
- If your program was compiled with optimizations, some compilers will
-optimize away arguments passed to functions if those arguments are
-never used after the call. Such optimizations generate code that
-passes arguments through registers, but doesn't store those arguments
-in the stack frame. GDB has no way of displaying such arguments in
-stack frames other than the innermost one. Here's what such a
-backtrace might look like:
-
- #0 m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8)
- at builtin.c:993
- #1 0x6e38 in expand_macro (sym=<optimized out>) at macro.c:242
- #2 0x6840 in expand_token (obs=0x0, t=<optimized out>, td=0xf7fffb08)
- at macro.c:71
- (More stack frames follow...)
-
-The values of arguments that were not saved in their stack frames are
-shown as `<optimized out>'.
-
- If you need to display the values of such optimized-out arguments,
-either deduce that from other variables whose values depend on the one
-you are interested in, or recompile without optimizations.
-
- Most programs have a standard user entry point--a place where system
-libraries and startup code transition into user code. For C this is
-`main'(1). When GDB finds the entry function in a backtrace it will
-terminate the backtrace, to avoid tracing into highly system-specific
-(and generally uninteresting) code.
-
- If you need to examine the startup code, or limit the number of
-levels in a backtrace, you can change this behavior:
-
-`set backtrace past-main'
-`set backtrace past-main on'
- Backtraces will continue past the user entry point.
-
-`set backtrace past-main off'
- Backtraces will stop when they encounter the user entry point.
- This is the default.
-
-`show backtrace past-main'
- Display the current user entry point backtrace policy.
-
-`set backtrace past-entry'
-`set backtrace past-entry on'
- Backtraces will continue past the internal entry point of an
- application. This entry point is encoded by the linker when the
- application is built, and is likely before the user entry point
- `main' (or equivalent) is called.
-
-`set backtrace past-entry off'
- Backtraces will stop when they encounter the internal entry point
- of an application. This is the default.
-
-`show backtrace past-entry'
- Display the current internal entry point backtrace policy.
-
-`set backtrace limit N'
-`set backtrace limit 0'
- Limit the backtrace to N levels. A value of zero means unlimited.
-
-`show backtrace limit'
- Display the current limit on backtrace levels.
-
- ---------- Footnotes ----------
-
- (1) Note that embedded programs (the so-called "free-standing"
-environment) are not required to have a `main' function as the entry
-point. They could even have multiple entry points.
-
-
-File: gdb.info, Node: Selection, Next: Frame Info, Prev: Backtrace, Up: Stack
-
-8.3 Selecting a Frame
-=====================
-
-Most commands for examining the stack and other data in your program
-work on whichever stack frame is selected at the moment. Here are the
-commands for selecting a stack frame; all of them finish by printing a
-brief description of the stack frame just selected.
-
-`frame N'
-`f N'
- Select frame number N. Recall that frame zero is the innermost
- (currently executing) frame, frame one is the frame that called the
- innermost one, and so on. The highest-numbered frame is the one
- for `main'.
-
-`frame ADDR'
-`f ADDR'
- Select the frame at address ADDR. This is useful mainly if the
- chaining of stack frames has been damaged by a bug, making it
- impossible for GDB to assign numbers properly to all frames. In
- addition, this can be useful when your program has multiple stacks
- and switches between them.
-
- On the SPARC architecture, `frame' needs two addresses to select
- an arbitrary frame: a frame pointer and a stack pointer.
-
- On the MIPS and Alpha architecture, it needs two addresses: a stack
- pointer and a program counter.
-
- On the 29k architecture, it needs three addresses: a register stack
- pointer, a program counter, and a memory stack pointer.
-
-`up N'
- Move N frames up the stack. For positive numbers N, this advances
- toward the outermost frame, to higher frame numbers, to frames
- that have existed longer. N defaults to one.
-
-`down N'
- Move N frames down the stack. For positive numbers N, this
- advances toward the innermost frame, to lower frame numbers, to
- frames that were created more recently. N defaults to one. You
- may abbreviate `down' as `do'.
-
- All of these commands end by printing two lines of output describing
-the frame. The first line shows the frame number, the function name,
-the arguments, and the source file and line number of execution in that
-frame. The second line shows the text of that source line.
-
- For example:
-
- (gdb) up
- #1 0x22f0 in main (argc=1, argv=0xf7fffbf4, env=0xf7fffbfc)
- at env.c:10
- 10 read_input_file (argv[i]);
-
- After such a printout, the `list' command with no arguments prints
-ten lines centered on the point of execution in the frame. You can
-also edit the program at the point of execution with your favorite
-editing program by typing `edit'. *Note Printing Source Lines: List,
-for details.
-
-`up-silently N'
-`down-silently N'
- These two commands are variants of `up' and `down', respectively;
- they differ in that they do their work silently, without causing
- display of the new frame. They are intended primarily for use in
- GDB command scripts, where the output might be unnecessary and
- distracting.
-
-
-File: gdb.info, Node: Frame Info, Prev: Selection, Up: Stack
-
-8.4 Information About a Frame
-=============================
-
-There are several other commands to print information about the selected
-stack frame.
-
-`frame'
-`f'
- When used without any argument, this command does not change which
- frame is selected, but prints a brief description of the currently
- selected stack frame. It can be abbreviated `f'. With an
- argument, this command is used to select a stack frame. *Note
- Selecting a Frame: Selection.
-
-`info frame'
-`info f'
- This command prints a verbose description of the selected stack
- frame, including:
-
- * the address of the frame
-
- * the address of the next frame down (called by this frame)
-
- * the address of the next frame up (caller of this frame)
-
- * the language in which the source code corresponding to this
- frame is written
-
- * the address of the frame's arguments
-
- * the address of the frame's local variables
-
- * the program counter saved in it (the address of execution in
- the caller frame)
-
- * which registers were saved in the frame
-
- The verbose description is useful when something has gone wrong
- that has made the stack format fail to fit the usual conventions.
-
-`info frame ADDR'
-`info f ADDR'
- Print a verbose description of the frame at address ADDR, without
- selecting that frame. The selected frame remains unchanged by this
- command. This requires the same kind of address (more than one
- for some architectures) that you specify in the `frame' command.
- *Note Selecting a Frame: Selection.
-
-`info args'
- Print the arguments of the selected frame, each on a separate line.
-
-`info locals'
- Print the local variables of the selected frame, each on a separate
- line. These are all variables (declared either static or
- automatic) accessible at the point of execution of the selected
- frame.
-
-`info catch'
- Print a list of all the exception handlers that are active in the
- current stack frame at the current point of execution. To see
- other exception handlers, visit the associated frame (using the
- `up', `down', or `frame' commands); then type `info catch'. *Note
- Setting Catchpoints: Set Catchpoints.
-
-
-
-File: gdb.info, Node: Source, Next: Data, Prev: Stack, Up: Top
-
-9 Examining Source Files
-************************
-
-GDB can print parts of your program's source, since the debugging
-information recorded in the program tells GDB what source files were
-used to build it. When your program stops, GDB spontaneously prints
-the line where it stopped. Likewise, when you select a stack frame
-(*note Selecting a Frame: Selection.), GDB prints the line where
-execution in that frame has stopped. You can print other portions of
-source files by explicit command.
-
- If you use GDB through its GNU Emacs interface, you may prefer to
-use Emacs facilities to view source; see *note Using GDB under GNU
-Emacs: Emacs.
-
-* Menu:
-
-* List:: Printing source lines
-* Specify Location:: How to specify code locations
-* Edit:: Editing source files
-* Search:: Searching source files
-* Source Path:: Specifying source directories
-* Machine Code:: Source and machine code
-
-
-File: gdb.info, Node: List, Next: Specify Location, Up: Source
-
-9.1 Printing Source Lines
-=========================
-
-To print lines from a source file, use the `list' command (abbreviated
-`l'). By default, ten lines are printed. There are several ways to
-specify what part of the file you want to print; see *note Specify
-Location::, for the full list.
-
- Here are the forms of the `list' command most commonly used:
-
-`list LINENUM'
- Print lines centered around line number LINENUM in the current
- source file.
-
-`list FUNCTION'
- Print lines centered around the beginning of function FUNCTION.
-
-`list'
- Print more lines. If the last lines printed were printed with a
- `list' command, this prints lines following the last lines
- printed; however, if the last line printed was a solitary line
- printed as part of displaying a stack frame (*note Examining the
- Stack: Stack.), this prints lines centered around that line.
-
-`list -'
- Print lines just before the lines last printed.
-
- By default, GDB prints ten source lines with any of these forms of
-the `list' command. You can change this using `set listsize':
-
-`set listsize COUNT'
- Make the `list' command display COUNT source lines (unless the
- `list' argument explicitly specifies some other number).
-
-`show listsize'
- Display the number of lines that `list' prints.
-
- Repeating a `list' command with <RET> discards the argument, so it
-is equivalent to typing just `list'. This is more useful than listing
-the same lines again. An exception is made for an argument of `-';
-that argument is preserved in repetition so that each repetition moves
-up in the source file.
-
- In general, the `list' command expects you to supply zero, one or two
-"linespecs". Linespecs specify source lines; there are several ways of
-writing them (*note Specify Location::), but the effect is always to
-specify some source line.
-
- Here is a complete description of the possible arguments for `list':
-
-`list LINESPEC'
- Print lines centered around the line specified by LINESPEC.
-
-`list FIRST,LAST'
- Print lines from FIRST to LAST. Both arguments are linespecs.
- When a `list' command has two linespecs, and the source file of
- the second linespec is omitted, this refers to the same source
- file as the first linespec.
-
-`list ,LAST'
- Print lines ending with LAST.
-
-`list FIRST,'
- Print lines starting with FIRST.
-
-`list +'
- Print lines just after the lines last printed.
-
-`list -'
- Print lines just before the lines last printed.
-
-`list'
- As described in the preceding table.
-
-
-File: gdb.info, Node: Specify Location, Next: Edit, Prev: List, Up: Source
-
-9.2 Specifying a Location
-=========================
-
-Several GDB commands accept arguments that specify a location of your
-program's code. Since GDB is a source-level debugger, a location
-usually specifies some line in the source code; for that reason,
-locations are also known as "linespecs".
-
- Here are all the different ways of specifying a code location that
-GDB understands:
-
-`LINENUM'
- Specifies the line number LINENUM of the current source file.
-
-`-OFFSET'
-`+OFFSET'
- Specifies the line OFFSET lines before or after the "current
- line". For the `list' command, the current line is the last one
- printed; for the breakpoint commands, this is the line at which
- execution stopped in the currently selected "stack frame" (*note
- Frames: Frames, for a description of stack frames.) When used as
- the second of the two linespecs in a `list' command, this
- specifies the line OFFSET lines up or down from the first linespec.
-
-`FILENAME:LINENUM'
- Specifies the line LINENUM in the source file FILENAME.
-
-`FUNCTION'
- Specifies the line that begins the body of the function FUNCTION.
- For example, in C, this is the line with the open brace.
-
-`FUNCTION:LABEL'
- Specifies the line where LABEL appears in FUNCTION.
-
-`FILENAME:FUNCTION'
- Specifies the line that begins the body of the function FUNCTION
- in the file FILENAME. You only need the file name with a function
- name to avoid ambiguity when there are identically named functions
- in different source files.
-
-`LABEL'
- Specifies the line at which the label named LABEL appears. GDB
- searches for the label in the function corresponding to the
- currently selected stack frame. If there is no current selected
- stack frame (for instance, if the inferior is not running), then
- GDB will not search for a label.
-
-`*ADDRESS'
- Specifies the program address ADDRESS. For line-oriented
- commands, such as `list' and `edit', this specifies a source line
- that contains ADDRESS. For `break' and other breakpoint oriented
- commands, this can be used to set breakpoints in parts of your
- program which do not have debugging information or source files.
-
- Here ADDRESS may be any expression valid in the current working
- language (*note working language: Languages.) that specifies a code
- address. In addition, as a convenience, GDB extends the semantics
- of expressions used in locations to cover the situations that
- frequently happen during debugging. Here are the various forms of
- ADDRESS:
-
- `EXPRESSION'
- Any expression valid in the current working language.
-
- `FUNCADDR'
- An address of a function or procedure derived from its name.
- In C, C++, Java, Objective-C, Fortran, minimal, and assembly,
- this is simply the function's name FUNCTION (and actually a
- special case of a valid expression). In Pascal and Modula-2,
- this is `&FUNCTION'. In Ada, this is `FUNCTION'Address'
- (although the Pascal form also works).
-
- This form specifies the address of the function's first
- instruction, before the stack frame and arguments have been
- set up.
-
- `'FILENAME'::FUNCADDR'
- Like FUNCADDR above, but also specifies the name of the source
- file explicitly. This is useful if the name of the function
- does not specify the function unambiguously, e.g., if there
- are several functions with identical names in different
- source files.
-
-
-
-File: gdb.info, Node: Edit, Next: Search, Prev: Specify Location, Up: Source
-
-9.3 Editing Source Files
-========================
-
-To edit the lines in a source file, use the `edit' command. The
-editing program of your choice is invoked with the current line set to
-the active line in the program. Alternatively, there are several ways
-to specify what part of the file you want to print if you want to see
-other parts of the program:
-
-`edit LOCATION'
- Edit the source file specified by `location'. Editing starts at
- that LOCATION, e.g., at the specified source line of the specified
- file. *Note Specify Location::, for all the possible forms of the
- LOCATION argument; here are the forms of the `edit' command most
- commonly used:
-
- `edit NUMBER'
- Edit the current source file with NUMBER as the active line
- number.
-
- `edit FUNCTION'
- Edit the file containing FUNCTION at the beginning of its
- definition.
-
-
-9.3.1 Choosing your Editor
---------------------------
-
-You can customize GDB to use any editor you want (1). By default, it
-is `/bin/ex', but you can change this by setting the environment
-variable `EDITOR' before using GDB. For example, to configure GDB to
-use the `vi' editor, you could use these commands with the `sh' shell:
- EDITOR=/usr/bin/vi
- export EDITOR
- gdb ...
- or in the `csh' shell,
- setenv EDITOR /usr/bin/vi
- gdb ...
-
- ---------- Footnotes ----------
-
- (1) The only restriction is that your editor (say `ex'), recognizes
-the following command-line syntax:
- ex +NUMBER file
- The optional numeric value +NUMBER specifies the number of the line
-in the file where to start editing.
-
-
-File: gdb.info, Node: Search, Next: Source Path, Prev: Edit, Up: Source
-
-9.4 Searching Source Files
-==========================
-
-There are two commands for searching through the current source file
-for a regular expression.
-
-`forward-search REGEXP'
-`search REGEXP'
- The command `forward-search REGEXP' checks each line, starting
- with the one following the last line listed, for a match for
- REGEXP. It lists the line that is found. You can use the synonym
- `search REGEXP' or abbreviate the command name as `fo'.
-
-`reverse-search REGEXP'
- The command `reverse-search REGEXP' checks each line, starting
- with the one before the last line listed and going backward, for a
- match for REGEXP. It lists the line that is found. You can
- abbreviate this command as `rev'.
-
-
-File: gdb.info, Node: Source Path, Next: Machine Code, Prev: Search, Up: Source
-
-9.5 Specifying Source Directories
-=================================
-
-Executable programs sometimes do not record the directories of the
-source files from which they were compiled, just the names. Even when
-they do, the directories could be moved between the compilation and
-your debugging session. GDB has a list of directories to search for
-source files; this is called the "source path". Each time GDB wants a
-source file, it tries all the directories in the list, in the order
-they are present in the list, until it finds a file with the desired
-name.
-
- For example, suppose an executable references the file
-`/usr/src/foo-1.0/lib/foo.c', and our source path is `/mnt/cross'. The
-file is first looked up literally; if this fails,
-`/mnt/cross/usr/src/foo-1.0/lib/foo.c' is tried; if this fails,
-`/mnt/cross/foo.c' is opened; if this fails, an error message is
-printed. GDB does not look up the parts of the source file name, such
-as `/mnt/cross/src/foo-1.0/lib/foo.c'. Likewise, the subdirectories of
-the source path are not searched: if the source path is `/mnt/cross',
-and the binary refers to `foo.c', GDB would not find it under
-`/mnt/cross/usr/src/foo-1.0/lib'.
-
- Plain file names, relative file names with leading directories, file
-names containing dots, etc. are all treated as described above; for
-instance, if the source path is `/mnt/cross', and the source file is
-recorded as `../lib/foo.c', GDB would first try `../lib/foo.c', then
-`/mnt/cross/../lib/foo.c', and after that--`/mnt/cross/foo.c'.
-
- Note that the executable search path is _not_ used to locate the
-source files.
-
- Whenever you reset or rearrange the source path, GDB clears out any
-information it has cached about where source files are found and where
-each line is in the file.
-
- When you start GDB, its source path includes only `cdir' and `cwd',
-in that order. To add other directories, use the `directory' command.
-
- The search path is used to find both program source files and GDB
-script files (read using the `-command' option and `source' command).
-
- In addition to the source path, GDB provides a set of commands that
-manage a list of source path substitution rules. A "substitution rule"
-specifies how to rewrite source directories stored in the program's
-debug information in case the sources were moved to a different
-directory between compilation and debugging. A rule is made of two
-strings, the first specifying what needs to be rewritten in the path,
-and the second specifying how it should be rewritten. In *note set
-substitute-path::, we name these two parts FROM and TO respectively.
-GDB does a simple string replacement of FROM with TO at the start of
-the directory part of the source file name, and uses that result
-instead of the original file name to look up the sources.
-
- Using the previous example, suppose the `foo-1.0' tree has been
-moved from `/usr/src' to `/mnt/cross', then you can tell GDB to replace
-`/usr/src' in all source path names with `/mnt/cross'. The first
-lookup will then be `/mnt/cross/foo-1.0/lib/foo.c' in place of the
-original location of `/usr/src/foo-1.0/lib/foo.c'. To define a source
-path substitution rule, use the `set substitute-path' command (*note
-set substitute-path::).
-
- To avoid unexpected substitution results, a rule is applied only if
-the FROM part of the directory name ends at a directory separator. For
-instance, a rule substituting `/usr/source' into `/mnt/cross' will be
-applied to `/usr/source/foo-1.0' but not to `/usr/sourceware/foo-2.0'.
-And because the substitution is applied only at the beginning of the
-directory name, this rule will not be applied to
-`/root/usr/source/baz.c' either.
-
- In many cases, you can achieve the same result using the `directory'
-command. However, `set substitute-path' can be more efficient in the
-case where the sources are organized in a complex tree with multiple
-subdirectories. With the `directory' command, you need to add each
-subdirectory of your project. If you moved the entire tree while
-preserving its internal organization, then `set substitute-path' allows
-you to direct the debugger to all the sources with one single command.
-
- `set substitute-path' is also more than just a shortcut command.
-The source path is only used if the file at the original location no
-longer exists. On the other hand, `set substitute-path' modifies the
-debugger behavior to look at the rewritten location instead. So, if
-for any reason a source file that is not relevant to your executable is
-located at the original location, a substitution rule is the only
-method available to point GDB at the new location.
-
- You can configure a default source path substitution rule by
-configuring GDB with the `--with-relocated-sources=DIR' option. The DIR
-should be the name of a directory under GDB's configured prefix (set
-with `--prefix' or `--exec-prefix'), and directory names in debug
-information under DIR will be adjusted automatically if the installed
-GDB is moved to a new location. This is useful if GDB, libraries or
-executables with debug information and corresponding source code are
-being moved together.
-
-`directory DIRNAME ...'
-
-`dir DIRNAME ...'
- Add directory DIRNAME to the front of the source path. Several
- directory names may be given to this command, separated by `:'
- (`;' on MS-DOS and MS-Windows, where `:' usually appears as part
- of absolute file names) or whitespace. You may specify a
- directory that is already in the source path; this moves it
- forward, so GDB searches it sooner.
-
- You can use the string `$cdir' to refer to the compilation
- directory (if one is recorded), and `$cwd' to refer to the current
- working directory. `$cwd' is not the same as `.'--the former
- tracks the current working directory as it changes during your GDB
- session, while the latter is immediately expanded to the current
- directory at the time you add an entry to the source path.
-
-`directory'
- Reset the source path to its default value (`$cdir:$cwd' on Unix
- systems). This requires confirmation.
-
-`set directories PATH-LIST'
- Set the source path to PATH-LIST. `$cdir:$cwd' are added if
- missing.
-
-`show directories'
- Print the source path: show which directories it contains.
-
-`set substitute-path FROM TO'
- Define a source path substitution rule, and add it at the end of
- the current list of existing substitution rules. If a rule with
- the same FROM was already defined, then the old rule is also
- deleted.
-
- For example, if the file `/foo/bar/baz.c' was moved to
- `/mnt/cross/baz.c', then the command
-
- (gdb) set substitute-path /usr/src /mnt/cross
-
- will tell GDB to replace `/usr/src' with `/mnt/cross', which will
- allow GDB to find the file `baz.c' even though it was moved.
-
- In the case when more than one substitution rule have been defined,
- the rules are evaluated one by one in the order where they have
- been defined. The first one matching, if any, is selected to
- perform the substitution.
-
- For instance, if we had entered the following commands:
-
- (gdb) set substitute-path /usr/src/include /mnt/include
- (gdb) set substitute-path /usr/src /mnt/src
-
- GDB would then rewrite `/usr/src/include/defs.h' into
- `/mnt/include/defs.h' by using the first rule. However, it would
- use the second rule to rewrite `/usr/src/lib/foo.c' into
- `/mnt/src/lib/foo.c'.
-
-`unset substitute-path [path]'
- If a path is specified, search the current list of substitution
- rules for a rule that would rewrite that path. Delete that rule
- if found. A warning is emitted by the debugger if no rule could
- be found.
-
- If no path is specified, then all substitution rules are deleted.
-
-`show substitute-path [path]'
- If a path is specified, then print the source path substitution
- rule which would rewrite that path, if any.
-
- If no path is specified, then print all existing source path
- substitution rules.
-
-
- If your source path is cluttered with directories that are no longer
-of interest, GDB may sometimes cause confusion by finding the wrong
-versions of source. You can correct the situation as follows:
-
- 1. Use `directory' with no argument to reset the source path to its
- default value.
-
- 2. Use `directory' with suitable arguments to reinstall the
- directories you want in the source path. You can add all the
- directories in one command.
-
-
-File: gdb.info, Node: Machine Code, Prev: Source Path, Up: Source
-
-9.6 Source and Machine Code
-===========================
-
-You can use the command `info line' to map source lines to program
-addresses (and vice versa), and the command `disassemble' to display a
-range of addresses as machine instructions. You can use the command
-`set disassemble-next-line' to set whether to disassemble next source
-line when execution stops. When run under GNU Emacs mode, the `info
-line' command causes the arrow to point to the line specified. Also,
-`info line' prints addresses in symbolic form as well as hex.
-
-`info line LINESPEC'
- Print the starting and ending addresses of the compiled code for
- source line LINESPEC. You can specify source lines in any of the
- ways documented in *note Specify Location::.
-
- For example, we can use `info line' to discover the location of the
-object code for the first line of function `m4_changequote':
-
- (gdb) info line m4_changequote
- Line 895 of "builtin.c" starts at pc 0x634c and ends at 0x6350.
-
-We can also inquire (using `*ADDR' as the form for LINESPEC) what
-source line covers a particular address:
- (gdb) info line *0x63ff
- Line 926 of "builtin.c" starts at pc 0x63e4 and ends at 0x6404.
-
- After `info line', the default address for the `x' command is
-changed to the starting address of the line, so that `x/i' is
-sufficient to begin examining the machine code (*note Examining Memory:
-Memory.). Also, this address is saved as the value of the convenience
-variable `$_' (*note Convenience Variables: Convenience Vars.).
-
-`disassemble'
-`disassemble /m'
-`disassemble /r'
- This specialized command dumps a range of memory as machine
- instructions. It can also print mixed source+disassembly by
- specifying the `/m' modifier and print the raw instructions in hex
- as well as in symbolic form by specifying the `/r'. The default
- memory range is the function surrounding the program counter of
- the selected frame. A single argument to this command is a
- program counter value; GDB dumps the function surrounding this
- value. When two arguments are given, they should be separated by
- a comma, possibly surrounded by whitespace. The arguments specify
- a range of addresses to dump, in one of two forms:
-
- `START,END'
- the addresses from START (inclusive) to END (exclusive)
-
- `START,+LENGTH'
- the addresses from START (inclusive) to `START+LENGTH'
- (exclusive).
-
- When 2 arguments are specified, the name of the function is also
- printed (since there could be several functions in the given
- range).
-
- The argument(s) can be any expression yielding a numeric value,
- such as `0x32c4', `&main+10' or `$pc - 8'.
-
- If the range of memory being disassembled contains current program
- counter, the instruction at that location is shown with a `=>'
- marker.
-
- The following example shows the disassembly of a range of addresses
-of HP PA-RISC 2.0 code:
-
- (gdb) disas 0x32c4, 0x32e4
- Dump of assembler code from 0x32c4 to 0x32e4:
- 0x32c4 <main+204>: addil 0,dp
- 0x32c8 <main+208>: ldw 0x22c(sr0,r1),r26
- 0x32cc <main+212>: ldil 0x3000,r31
- 0x32d0 <main+216>: ble 0x3f8(sr4,r31)
- 0x32d4 <main+220>: ldo 0(r31),rp
- 0x32d8 <main+224>: addil -0x800,dp
- 0x32dc <main+228>: ldo 0x588(r1),r26
- 0x32e0 <main+232>: ldil 0x3000,r31
- End of assembler dump.
-
- Here is an example showing mixed source+assembly for Intel x86, when
-the program is stopped just after function prologue:
-
- (gdb) disas /m main
- Dump of assembler code for function main:
- 5 {
- 0x08048330 <+0>: push %ebp
- 0x08048331 <+1>: mov %esp,%ebp
- 0x08048333 <+3>: sub $0x8,%esp
- 0x08048336 <+6>: and $0xfffffff0,%esp
- 0x08048339 <+9>: sub $0x10,%esp
-
- 6 printf ("Hello.\n");
- => 0x0804833c <+12>: movl $0x8048440,(%esp)
- 0x08048343 <+19>: call 0x8048284 <puts@plt>
-
- 7 return 0;
- 8 }
- 0x08048348 <+24>: mov $0x0,%eax
- 0x0804834d <+29>: leave
- 0x0804834e <+30>: ret
-
- End of assembler dump.
-
- Here is another example showing raw instructions in hex for AMD
-x86-64,
-
- (gdb) disas /r 0x400281,+10
- Dump of assembler code from 0x400281 to 0x40028b:
- 0x0000000000400281: 38 36 cmp %dh,(%rsi)
- 0x0000000000400283: 2d 36 34 2e 73 sub $0x732e3436,%eax
- 0x0000000000400288: 6f outsl %ds:(%rsi),(%dx)
- 0x0000000000400289: 2e 32 00 xor %cs:(%rax),%al
- End of assembler dump.
-
- Some architectures have more than one commonly-used set of
-instruction mnemonics or other syntax.
-
- For programs that were dynamically linked and use shared libraries,
-instructions that call functions or branch to locations in the shared
-libraries might show a seemingly bogus location--it's actually a
-location of the relocation table. On some architectures, GDB might be
-able to resolve these to actual function names.
-
-`set disassembly-flavor INSTRUCTION-SET'
- Select the instruction set to use when disassembling the program
- via the `disassemble' or `x/i' commands.
-
- Currently this command is only defined for the Intel x86 family.
- You can set INSTRUCTION-SET to either `intel' or `att'. The
- default is `att', the AT&T flavor used by default by Unix
- assemblers for x86-based targets.
-
-`show disassembly-flavor'
- Show the current setting of the disassembly flavor.
-
-`set disassemble-next-line'
-`show disassemble-next-line'
- Control whether or not GDB will disassemble the next source line
- or instruction when execution stops. If ON, GDB will display
- disassembly of the next source line when execution of the program
- being debugged stops. This is _in addition_ to displaying the
- source line itself, which GDB always does if possible. If the
- next source line cannot be displayed for some reason (e.g., if GDB
- cannot find the source file, or there's no line info in the debug
- info), GDB will display disassembly of the next _instruction_
- instead of showing the next source line. If AUTO, GDB will
- display disassembly of next instruction only if the source line
- cannot be displayed. This setting causes GDB to display some
- feedback when you step through a function with no line info or
- whose source file is unavailable. The default is OFF, which means
- never display the disassembly of the next line or instruction.
-
-
-File: gdb.info, Node: Data, Next: Optimized Code, Prev: Source, Up: Top
-
-10 Examining Data
-*****************
-
-The usual way to examine data in your program is with the `print'
-command (abbreviated `p'), or its synonym `inspect'. It evaluates and
-prints the value of an expression of the language your program is
-written in (*note Using GDB with Different Languages: Languages.). It
-may also print the expression using a Python-based pretty-printer
-(*note Pretty Printing::).
-
-`print EXPR'
-`print /F EXPR'
- EXPR is an expression (in the source language). By default the
- value of EXPR is printed in a format appropriate to its data type;
- you can choose a different format by specifying `/F', where F is a
- letter specifying the format; see *note Output Formats: Output
- Formats.
-
-`print'
-`print /F'
- If you omit EXPR, GDB displays the last value again (from the
- "value history"; *note Value History: Value History.). This
- allows you to conveniently inspect the same value in an
- alternative format.
-
- A more low-level way of examining data is with the `x' command. It
-examines data in memory at a specified address and prints it in a
-specified format. *Note Examining Memory: Memory.
-
- If you are interested in information about types, or about how the
-fields of a struct or a class are declared, use the `ptype EXP' command
-rather than `print'. *Note Examining the Symbol Table: Symbols.
-
-* Menu:
-
-* Expressions:: Expressions
-* Ambiguous Expressions:: Ambiguous Expressions
-* Variables:: Program variables
-* Arrays:: Artificial arrays
-* Output Formats:: Output formats
-* Memory:: Examining memory
-* Auto Display:: Automatic display
-* Print Settings:: Print settings
-* Pretty Printing:: Python pretty printing
-* Value History:: Value history
-* Convenience Vars:: Convenience variables
-* Registers:: Registers
-* Floating Point Hardware:: Floating point hardware
-* Vector Unit:: Vector Unit
-* OS Information:: Auxiliary data provided by operating system
-* Memory Region Attributes:: Memory region attributes
-* Dump/Restore Files:: Copy between memory and a file
-* Core File Generation:: Cause a program dump its core
-* Character Sets:: Debugging programs that use a different
- character set than GDB does
-* Caching Remote Data:: Data caching for remote targets
-* Searching Memory:: Searching memory for a sequence of bytes
-
-
-File: gdb.info, Node: Expressions, Next: Ambiguous Expressions, Up: Data
-
-10.1 Expressions
-================
-
-`print' and many other GDB commands accept an expression and compute
-its value. Any kind of constant, variable or operator defined by the
-programming language you are using is valid in an expression in GDB.
-This includes conditional expressions, function calls, casts, and
-string constants. It also includes preprocessor macros, if you
-compiled your program to include this information; see *note
-Compilation::.
-
- GDB supports array constants in expressions input by the user. The
-syntax is {ELEMENT, ELEMENT...}. For example, you can use the command
-`print {1, 2, 3}' to create an array of three integers. If you pass an
-array to a function or assign it to a program variable, GDB copies the
-array to memory that is `malloc'ed in the target program.
-
- Because C is so widespread, most of the expressions shown in
-examples in this manual are in C. *Note Using GDB with Different
-Languages: Languages, for information on how to use expressions in other
-languages.
-
- In this section, we discuss operators that you can use in GDB
-expressions regardless of your programming language.
-
- Casts are supported in all languages, not just in C, because it is so
-useful to cast a number into a pointer in order to examine a structure
-at that address in memory.
-
- GDB supports these operators, in addition to those common to
-programming languages:
-
-`@'
- `@' is a binary operator for treating parts of memory as arrays.
- *Note Artificial Arrays: Arrays, for more information.
-
-`::'
- `::' allows you to specify a variable in terms of the file or
- function where it is defined. *Note Program Variables: Variables.
-
-`{TYPE} ADDR'
- Refers to an object of type TYPE stored at address ADDR in memory.
- ADDR may be any expression whose value is an integer or pointer
- (but parentheses are required around binary operators, just as in
- a cast). This construct is allowed regardless of what kind of
- data is normally supposed to reside at ADDR.
-
-
-File: gdb.info, Node: Ambiguous Expressions, Next: Variables, Prev: Expressions, Up: Data
-
-10.2 Ambiguous Expressions
-==========================
-
-Expressions can sometimes contain some ambiguous elements. For
-instance, some programming languages (notably Ada, C++ and Objective-C)
-permit a single function name to be defined several times, for
-application in different contexts. This is called "overloading".
-Another example involving Ada is generics. A "generic package" is
-similar to C++ templates and is typically instantiated several times,
-resulting in the same function name being defined in different contexts.
-
- In some cases and depending on the language, it is possible to adjust
-the expression to remove the ambiguity. For instance in C++, you can
-specify the signature of the function you want to break on, as in
-`break FUNCTION(TYPES)'. In Ada, using the fully qualified name of
-your function often makes the expression unambiguous as well.
-
- When an ambiguity that needs to be resolved is detected, the debugger
-has the capability to display a menu of numbered choices for each
-possibility, and then waits for the selection with the prompt `>'. The
-first option is always `[0] cancel', and typing `0 <RET>' aborts the
-current command. If the command in which the expression was used
-allows more than one choice to be selected, the next option in the menu
-is `[1] all', and typing `1 <RET>' selects all possible choices.
-
- For example, the following session excerpt shows an attempt to set a
-breakpoint at the overloaded symbol `String::after'. We choose three
-particular definitions of that function name:
-
- (gdb) b String::after
- [0] cancel
- [1] all
- [2] file:String.cc; line number:867
- [3] file:String.cc; line number:860
- [4] file:String.cc; line number:875
- [5] file:String.cc; line number:853
- [6] file:String.cc; line number:846
- [7] file:String.cc; line number:735
- > 2 4 6
- Breakpoint 1 at 0xb26c: file String.cc, line 867.
- Breakpoint 2 at 0xb344: file String.cc, line 875.
- Breakpoint 3 at 0xafcc: file String.cc, line 846.
- Multiple breakpoints were set.
- Use the "delete" command to delete unwanted
- breakpoints.
- (gdb)
-
-`set multiple-symbols MODE'
- This option allows you to adjust the debugger behavior when an
- expression is ambiguous.
-
- By default, MODE is set to `all'. If the command with which the
- expression is used allows more than one choice, then GDB
- automatically selects all possible choices. For instance,
- inserting a breakpoint on a function using an ambiguous name
- results in a breakpoint inserted on each possible match. However,
- if a unique choice must be made, then GDB uses the menu to help
- you disambiguate the expression. For instance, printing the
- address of an overloaded function will result in the use of the
- menu.
-
- When MODE is set to `ask', the debugger always uses the menu when
- an ambiguity is detected.
-
- Finally, when MODE is set to `cancel', the debugger reports an
- error due to the ambiguity and the command is aborted.
-
-`show multiple-symbols'
- Show the current value of the `multiple-symbols' setting.
-
-
-File: gdb.info, Node: Variables, Next: Arrays, Prev: Ambiguous Expressions, Up: Data
-
-10.3 Program Variables
-======================
-
-The most common kind of expression to use is the name of a variable in
-your program.
-
- Variables in expressions are understood in the selected stack frame
-(*note Selecting a Frame: Selection.); they must be either:
-
- * global (or file-static)
-
-or
-
- * visible according to the scope rules of the programming language
- from the point of execution in that frame
-
-This means that in the function
-
- foo (a)
- int a;
- {
- bar (a);
- {
- int b = test ();
- bar (b);
- }
- }
-
-you can examine and use the variable `a' whenever your program is
-executing within the function `foo', but you can only use or examine
-the variable `b' while your program is executing inside the block where
-`b' is declared.
-
- There is an exception: you can refer to a variable or function whose
-scope is a single source file even if the current execution point is not
-in this file. But it is possible to have more than one such variable or
-function with the same name (in different source files). If that
-happens, referring to that name has unpredictable effects. If you wish,
-you can specify a static variable in a particular function or file,
-using the colon-colon (`::') notation:
-
- FILE::VARIABLE
- FUNCTION::VARIABLE
-
-Here FILE or FUNCTION is the name of the context for the static
-VARIABLE. In the case of file names, you can use quotes to make sure
-GDB parses the file name as a single word--for example, to print a
-global value of `x' defined in `f2.c':
-
- (gdb) p 'f2.c'::x
-
- This use of `::' is very rarely in conflict with the very similar
-use of the same notation in C++. GDB also supports use of the C++
-scope resolution operator in GDB expressions.
-
- _Warning:_ Occasionally, a local variable may appear to have the
- wrong value at certain points in a function--just after entry to a
- new scope, and just before exit.
- You may see this problem when you are stepping by machine
-instructions. This is because, on most machines, it takes more than
-one instruction to set up a stack frame (including local variable
-definitions); if you are stepping by machine instructions, variables
-may appear to have the wrong values until the stack frame is completely
-built. On exit, it usually also takes more than one machine
-instruction to destroy a stack frame; after you begin stepping through
-that group of instructions, local variable definitions may be gone.
-
- This may also happen when the compiler does significant
-optimizations. To be sure of always seeing accurate values, turn off
-all optimization when compiling.
-
- Another possible effect of compiler optimizations is to optimize
-unused variables out of existence, or assign variables to registers (as
-opposed to memory addresses). Depending on the support for such cases
-offered by the debug info format used by the compiler, GDB might not be
-able to display values for such local variables. If that happens, GDB
-will print a message like this:
-
- No symbol "foo" in current context.
-
- To solve such problems, either recompile without optimizations, or
-use a different debug info format, if the compiler supports several such
-formats. For example, GCC, the GNU C/C++ compiler, usually supports
-the `-gstabs+' option. `-gstabs+' produces debug info in a format that
-is superior to formats such as COFF. You may be able to use DWARF 2
-(`-gdwarf-2'), which is also an effective form for debug info. *Note
-Options for Debugging Your Program or GCC: (gcc.info)Debugging Options.
-*Note C and C++: C, for more information about debug info formats that
-are best suited to C++ programs.
-
- If you ask to print an object whose contents are unknown to GDB,
-e.g., because its data type is not completely specified by the debug
-information, GDB will say `<incomplete type>'. *Note incomplete type:
-Symbols, for more about this.
-
- Strings are identified as arrays of `char' values without specified
-signedness. Arrays of either `signed char' or `unsigned char' get
-printed as arrays of 1 byte sized integers. `-fsigned-char' or
-`-funsigned-char' GCC options have no effect as GDB defines literal
-string type `"char"' as `char' without a sign. For program code
-
- char var0[] = "A";
- signed char var1[] = "A";
-
- You get during debugging
- (gdb) print var0
- $1 = "A"
- (gdb) print var1
- $2 = {65 'A', 0 '\0'}
-
-
-File: gdb.info, Node: Arrays, Next: Output Formats, Prev: Variables, Up: Data
-
-10.4 Artificial Arrays
-======================
-
-It is often useful to print out several successive objects of the same
-type in memory; a section of an array, or an array of dynamically
-determined size for which only a pointer exists in the program.
-
- You can do this by referring to a contiguous span of memory as an
-"artificial array", using the binary operator `@'. The left operand of
-`@' should be the first element of the desired array and be an
-individual object. The right operand should be the desired length of
-the array. The result is an array value whose elements are all of the
-type of the left argument. The first element is actually the left
-argument; the second element comes from bytes of memory immediately
-following those that hold the first element, and so on. Here is an
-example. If a program says
-
- int *array = (int *) malloc (len * sizeof (int));
-
-you can print the contents of `array' with
-
- p *array@len
-
- The left operand of `@' must reside in memory. Array values made
-with `@' in this way behave just like other arrays in terms of
-subscripting, and are coerced to pointers when used in expressions.
-Artificial arrays most often appear in expressions via the value history
-(*note Value History: Value History.), after printing one out.
-
- Another way to create an artificial array is to use a cast. This
-re-interprets a value as if it were an array. The value need not be in
-memory:
- (gdb) p/x (short[2])0x12345678
- $1 = {0x1234, 0x5678}
-
- As a convenience, if you leave the array length out (as in
-`(TYPE[])VALUE') GDB calculates the size to fill the value (as
-`sizeof(VALUE)/sizeof(TYPE)':
- (gdb) p/x (short[])0x12345678
- $2 = {0x1234, 0x5678}
-
- Sometimes the artificial array mechanism is not quite enough; in
-moderately complex data structures, the elements of interest may not
-actually be adjacent--for example, if you are interested in the values
-of pointers in an array. One useful work-around in this situation is
-to use a convenience variable (*note Convenience Variables: Convenience
-Vars.) as a counter in an expression that prints the first interesting
-value, and then repeat that expression via <RET>. For instance,
-suppose you have an array `dtab' of pointers to structures, and you are
-interested in the values of a field `fv' in each structure. Here is an
-example of what you might type:
-
- set $i = 0
- p dtab[$i++]->fv
- <RET>
- <RET>
- ...
-
-
-File: gdb.info, Node: Output Formats, Next: Memory, Prev: Arrays, Up: Data
-
-10.5 Output Formats
-===================
-
-By default, GDB prints a value according to its data type. Sometimes
-this is not what you want. For example, you might want to print a
-number in hex, or a pointer in decimal. Or you might want to view data
-in memory at a certain address as a character string or as an
-instruction. To do these things, specify an "output format" when you
-print a value.
-
- The simplest use of output formats is to say how to print a value
-already computed. This is done by starting the arguments of the
-`print' command with a slash and a format letter. The format letters
-supported are:
-
-`x'
- Regard the bits of the value as an integer, and print the integer
- in hexadecimal.
-
-`d'
- Print as integer in signed decimal.
-
-`u'
- Print as integer in unsigned decimal.
-
-`o'
- Print as integer in octal.
-
-`t'
- Print as integer in binary. The letter `t' stands for "two". (1)
-
-`a'
- Print as an address, both absolute in hexadecimal and as an offset
- from the nearest preceding symbol. You can use this format used
- to discover where (in what function) an unknown address is located:
-
- (gdb) p/a 0x54320
- $3 = 0x54320 <_initialize_vx+396>
-
- The command `info symbol 0x54320' yields similar results. *Note
- info symbol: Symbols.
-
-`c'
- Regard as an integer and print it as a character constant. This
- prints both the numerical value and its character representation.
- The character representation is replaced with the octal escape
- `\nnn' for characters outside the 7-bit ASCII range.
-
- Without this format, GDB displays `char', `unsigned char', and
- `signed char' data as character constants. Single-byte members of
- vectors are displayed as integer data.
-
-`f'
- Regard the bits of the value as a floating point number and print
- using typical floating point syntax.
-
-`s'
- Regard as a string, if possible. With this format, pointers to
- single-byte data are displayed as null-terminated strings and
- arrays of single-byte data are displayed as fixed-length strings.
- Other values are displayed in their natural types.
-
- Without this format, GDB displays pointers to and arrays of
- `char', `unsigned char', and `signed char' as strings.
- Single-byte members of a vector are displayed as an integer array.
-
-`r'
- Print using the `raw' formatting. By default, GDB will use a
- Python-based pretty-printer, if one is available (*note Pretty
- Printing::). This typically results in a higher-level display of
- the value's contents. The `r' format bypasses any Python
- pretty-printer which might exist.
-
- For example, to print the program counter in hex (*note
-Registers::), type
-
- p/x $pc
-
-Note that no space is required before the slash; this is because command
-names in GDB cannot contain a slash.
-
- To reprint the last value in the value history with a different
-format, you can use the `print' command with just a format and no
-expression. For example, `p/x' reprints the last value in hex.
-
- ---------- Footnotes ----------
-
- (1) `b' cannot be used because these format letters are also used
-with the `x' command, where `b' stands for "byte"; see *note Examining
-Memory: Memory.
-
-
-File: gdb.info, Node: Memory, Next: Auto Display, Prev: Output Formats, Up: Data
-
-10.6 Examining Memory
-=====================
-
-You can use the command `x' (for "examine") to examine memory in any of
-several formats, independently of your program's data types.
-
-`x/NFU ADDR'
-`x ADDR'
-`x'
- Use the `x' command to examine memory.
-
- N, F, and U are all optional parameters that specify how much memory
-to display and how to format it; ADDR is an expression giving the
-address where you want to start displaying memory. If you use defaults
-for NFU, you need not type the slash `/'. Several commands set
-convenient defaults for ADDR.
-
-N, the repeat count
- The repeat count is a decimal integer; the default is 1. It
- specifies how much memory (counting by units U) to display.
-
-F, the display format
- The display format is one of the formats used by `print' (`x',
- `d', `u', `o', `t', `a', `c', `f', `s'), and in addition `i' (for
- machine instructions). The default is `x' (hexadecimal)
- initially. The default changes each time you use either `x' or
- `print'.
-
-U, the unit size
- The unit size is any of
-
- `b'
- Bytes.
-
- `h'
- Halfwords (two bytes).
-
- `w'
- Words (four bytes). This is the initial default.
-
- `g'
- Giant words (eight bytes).
-
- Each time you specify a unit size with `x', that size becomes the
- default unit the next time you use `x'. For the `i' format, the
- unit size is ignored and is normally not written. For the `s'
- format, the unit size defaults to `b', unless it is explicitly
- given. Use `x /hs' to display 16-bit char strings and `x /ws' to
- display 32-bit strings. The next use of `x /s' will again display
- 8-bit strings. Note that the results depend on the programming
- language of the current compilation unit. If the language is C,
- the `s' modifier will use the UTF-16 encoding while `w' will use
- UTF-32. The encoding is set by the programming language and cannot
- be altered.
-
-ADDR, starting display address
- ADDR is the address where you want GDB to begin displaying memory.
- The expression need not have a pointer value (though it may); it
- is always interpreted as an integer address of a byte of memory.
- *Note Expressions: Expressions, for more information on
- expressions. The default for ADDR is usually just after the last
- address examined--but several other commands also set the default
- address: `info breakpoints' (to the address of the last breakpoint
- listed), `info line' (to the starting address of a line), and
- `print' (if you use it to display a value from memory).
-
- For example, `x/3uh 0x54320' is a request to display three halfwords
-(`h') of memory, formatted as unsigned decimal integers (`u'), starting
-at address `0x54320'. `x/4xw $sp' prints the four words (`w') of
-memory above the stack pointer (here, `$sp'; *note Registers:
-Registers.) in hexadecimal (`x').
-
- Since the letters indicating unit sizes are all distinct from the
-letters specifying output formats, you do not have to remember whether
-unit size or format comes first; either order works. The output
-specifications `4xw' and `4wx' mean exactly the same thing. (However,
-the count N must come first; `wx4' does not work.)
-
- Even though the unit size U is ignored for the formats `s' and `i',
-you might still want to use a count N; for example, `3i' specifies that
-you want to see three machine instructions, including any operands.
-For convenience, especially when used with the `display' command, the
-`i' format also prints branch delay slot instructions, if any, beyond
-the count specified, which immediately follow the last instruction that
-is within the count. The command `disassemble' gives an alternative
-way of inspecting machine instructions; see *note Source and Machine
-Code: Machine Code.
-
- All the defaults for the arguments to `x' are designed to make it
-easy to continue scanning memory with minimal specifications each time
-you use `x'. For example, after you have inspected three machine
-instructions with `x/3i ADDR', you can inspect the next seven with just
-`x/7'. If you use <RET> to repeat the `x' command, the repeat count N
-is used again; the other arguments default as for successive uses of
-`x'.
-
- When examining machine instructions, the instruction at current
-program counter is shown with a `=>' marker. For example:
-
- (gdb) x/5i $pc-6
- 0x804837f <main+11>: mov %esp,%ebp
- 0x8048381 <main+13>: push %ecx
- 0x8048382 <main+14>: sub $0x4,%esp
- => 0x8048385 <main+17>: movl $0x8048460,(%esp)
- 0x804838c <main+24>: call 0x80482d4 <puts@plt>
-
- The addresses and contents printed by the `x' command are not saved
-in the value history because there is often too much of them and they
-would get in the way. Instead, GDB makes these values available for
-subsequent use in expressions as values of the convenience variables
-`$_' and `$__'. After an `x' command, the last address examined is
-available for use in expressions in the convenience variable `$_'. The
-contents of that address, as examined, are available in the convenience
-variable `$__'.
-
- If the `x' command has a repeat count, the address and contents saved
-are from the last memory unit printed; this is not the same as the last
-address printed if several units were printed on the last line of
-output.
-
- When you are debugging a program running on a remote target machine
-(*note Remote Debugging::), you may wish to verify the program's image
-in the remote machine's memory against the executable file you
-downloaded to the target. The `compare-sections' command is provided
-for such situations.
-
-`compare-sections [SECTION-NAME]'
- Compare the data of a loadable section SECTION-NAME in the
- executable file of the program being debugged with the same
- section in the remote machine's memory, and report any mismatches.
- With no arguments, compares all loadable sections. This command's
- availability depends on the target's support for the `"qCRC"'
- remote request.
-
-
-File: gdb.info, Node: Auto Display, Next: Print Settings, Prev: Memory, Up: Data
-
-10.7 Automatic Display
-======================
-
-If you find that you want to print the value of an expression frequently
-(to see how it changes), you might want to add it to the "automatic
-display list" so that GDB prints its value each time your program stops.
-Each expression added to the list is given a number to identify it; to
-remove an expression from the list, you specify that number. The
-automatic display looks like this:
-
- 2: foo = 38
- 3: bar[5] = (struct hack *) 0x3804
-
-This display shows item numbers, expressions and their current values.
-As with displays you request manually using `x' or `print', you can
-specify the output format you prefer; in fact, `display' decides
-whether to use `print' or `x' depending your format specification--it
-uses `x' if you specify either the `i' or `s' format, or a unit size;
-otherwise it uses `print'.
-
-`display EXPR'
- Add the expression EXPR to the list of expressions to display each
- time your program stops. *Note Expressions: Expressions.
-
- `display' does not repeat if you press <RET> again after using it.
-
-`display/FMT EXPR'
- For FMT specifying only a display format and not a size or count,
- add the expression EXPR to the auto-display list but arrange to
- display it each time in the specified format FMT. *Note Output
- Formats: Output Formats.
-
-`display/FMT ADDR'
- For FMT `i' or `s', or including a unit-size or a number of units,
- add the expression ADDR as a memory address to be examined each
- time your program stops. Examining means in effect doing `x/FMT
- ADDR'. *Note Examining Memory: Memory.
-
- For example, `display/i $pc' can be helpful, to see the machine
-instruction about to be executed each time execution stops (`$pc' is a
-common name for the program counter; *note Registers: Registers.).
-
-`undisplay DNUMS...'
-`delete display DNUMS...'
- Remove items from the list of expressions to display. Specify the
- numbers of the displays that you want affected with the command
- argument DNUMS. It can be a single display number, one of the
- numbers shown in the first field of the `info display' display; or
- it could be a range of display numbers, as in `2-4'.
-
- `undisplay' does not repeat if you press <RET> after using it.
- (Otherwise you would just get the error `No display number ...'.)
-
-`disable display DNUMS...'
- Disable the display of item numbers DNUMS. A disabled display
- item is not printed automatically, but is not forgotten. It may be
- enabled again later. Specify the numbers of the displays that you
- want affected with the command argument DNUMS. It can be a single
- display number, one of the numbers shown in the first field of the
- `info display' display; or it could be a range of display numbers,
- as in `2-4'.
-
-`enable display DNUMS...'
- Enable display of item numbers DNUMS. It becomes effective once
- again in auto display of its expression, until you specify
- otherwise. Specify the numbers of the displays that you want
- affected with the command argument DNUMS. It can be a single
- display number, one of the numbers shown in the first field of the
- `info display' display; or it could be a range of display numbers,
- as in `2-4'.
-
-`display'
- Display the current values of the expressions on the list, just as
- is done when your program stops.
-
-`info display'
- Print the list of expressions previously set up to display
- automatically, each one with its item number, but without showing
- the values. This includes disabled expressions, which are marked
- as such. It also includes expressions which would not be
- displayed right now because they refer to automatic variables not
- currently available.
-
- If a display expression refers to local variables, then it does not
-make sense outside the lexical context for which it was set up. Such an
-expression is disabled when execution enters a context where one of its
-variables is not defined. For example, if you give the command
-`display last_char' while inside a function with an argument
-`last_char', GDB displays this argument while your program continues to
-stop inside that function. When it stops elsewhere--where there is no
-variable `last_char'--the display is disabled automatically. The next
-time your program stops where `last_char' is meaningful, you can enable
-the display expression once again.
-
-
-File: gdb.info, Node: Print Settings, Next: Pretty Printing, Prev: Auto Display, Up: Data
-
-10.8 Print Settings
-===================
-
-GDB provides the following ways to control how arrays, structures, and
-symbols are printed.
-
-These settings are useful for debugging programs in any language:
-
-`set print address'
-`set print address on'
- GDB prints memory addresses showing the location of stack traces,
- structure values, pointer values, breakpoints, and so forth, even
- when it also displays the contents of those addresses. The default
- is `on'. For example, this is what a stack frame display looks
- like with `set print address on':
-
- (gdb) f
- #0 set_quotes (lq=0x34c78 "<<", rq=0x34c88 ">>")
- at input.c:530
- 530 if (lquote != def_lquote)
-
-`set print address off'
- Do not print addresses when displaying their contents. For
- example, this is the same stack frame displayed with `set print
- address off':
-
- (gdb) set print addr off
- (gdb) f
- #0 set_quotes (lq="<<", rq=">>") at input.c:530
- 530 if (lquote != def_lquote)
-
- You can use `set print address off' to eliminate all machine
- dependent displays from the GDB interface. For example, with
- `print address off', you should get the same text for backtraces on
- all machines--whether or not they involve pointer arguments.
-
-`show print address'
- Show whether or not addresses are to be printed.
-
- When GDB prints a symbolic address, it normally prints the closest
-earlier symbol plus an offset. If that symbol does not uniquely
-identify the address (for example, it is a name whose scope is a single
-source file), you may need to clarify. One way to do this is with
-`info line', for example `info line *0x4537'. Alternately, you can set
-GDB to print the source file and line number when it prints a symbolic
-address:
-
-`set print symbol-filename on'
- Tell GDB to print the source file name and line number of a symbol
- in the symbolic form of an address.
-
-`set print symbol-filename off'
- Do not print source file name and line number of a symbol. This
- is the default.
-
-`show print symbol-filename'
- Show whether or not GDB will print the source file name and line
- number of a symbol in the symbolic form of an address.
-
- Another situation where it is helpful to show symbol filenames and
-line numbers is when disassembling code; GDB shows you the line number
-and source file that corresponds to each instruction.
-
- Also, you may wish to see the symbolic form only if the address being
-printed is reasonably close to the closest earlier symbol:
-
-`set print max-symbolic-offset MAX-OFFSET'
- Tell GDB to only display the symbolic form of an address if the
- offset between the closest earlier symbol and the address is less
- than MAX-OFFSET. The default is 0, which tells GDB to always
- print the symbolic form of an address if any symbol precedes it.
-
-`show print max-symbolic-offset'
- Ask how large the maximum offset is that GDB prints in a symbolic
- address.
-
- If you have a pointer and you are not sure where it points, try `set
-print symbol-filename on'. Then you can determine the name and source
-file location of the variable where it points, using `p/a POINTER'.
-This interprets the address in symbolic form. For example, here GDB
-shows that a variable `ptt' points at another variable `t', defined in
-`hi2.c':
-
- (gdb) set print symbol-filename on
- (gdb) p/a ptt
- $4 = 0xe008 <t in hi2.c>
-
- _Warning:_ For pointers that point to a local variable, `p/a' does
- not show the symbol name and filename of the referent, even with
- the appropriate `set print' options turned on.
-
- Other settings control how different kinds of objects are printed:
-
-`set print array'
-`set print array on'
- Pretty print arrays. This format is more convenient to read, but
- uses more space. The default is off.
-
-`set print array off'
- Return to compressed format for arrays.
-
-`show print array'
- Show whether compressed or pretty format is selected for displaying
- arrays.
-
-`set print array-indexes'
-`set print array-indexes on'
- Print the index of each element when displaying arrays. May be
- more convenient to locate a given element in the array or quickly
- find the index of a given element in that printed array. The
- default is off.
-
-`set print array-indexes off'
- Stop printing element indexes when displaying arrays.
-
-`show print array-indexes'
- Show whether the index of each element is printed when displaying
- arrays.
-
-`set print elements NUMBER-OF-ELEMENTS'
- Set a limit on how many elements of an array GDB will print. If
- GDB is printing a large array, it stops printing after it has
- printed the number of elements set by the `set print elements'
- command. This limit also applies to the display of strings. When
- GDB starts, this limit is set to 200. Setting NUMBER-OF-ELEMENTS
- to zero means that the printing is unlimited.
-
-`show print elements'
- Display the number of elements of a large array that GDB will
- print. If the number is 0, then the printing is unlimited.
-
-`set print frame-arguments VALUE'
- This command allows to control how the values of arguments are
- printed when the debugger prints a frame (*note Frames::). The
- possible values are:
-
- `all'
- The values of all arguments are printed.
-
- `scalars'
- Print the value of an argument only if it is a scalar. The
- value of more complex arguments such as arrays, structures,
- unions, etc, is replaced by `...'. This is the default.
- Here is an example where only scalar arguments are shown:
-
- #1 0x08048361 in call_me (i=3, s=..., ss=0xbf8d508c, u=..., e=green)
- at frame-args.c:23
-
- `none'
- None of the argument values are printed. Instead, the value
- of each argument is replaced by `...'. In this case, the
- example above now becomes:
-
- #1 0x08048361 in call_me (i=..., s=..., ss=..., u=..., e=...)
- at frame-args.c:23
-
- By default, only scalar arguments are printed. This command can
- be used to configure the debugger to print the value of all
- arguments, regardless of their type. However, it is often
- advantageous to not print the value of more complex parameters.
- For instance, it reduces the amount of information printed in each
- frame, making the backtrace more readable. Also, it improves
- performance when displaying Ada frames, because the computation of
- large arguments can sometimes be CPU-intensive, especially in
- large applications. Setting `print frame-arguments' to `scalars'
- (the default) or `none' avoids this computation, thus speeding up
- the display of each Ada frame.
-
-`show print frame-arguments'
- Show how the value of arguments should be displayed when printing
- a frame.
-
-`set print repeats'
- Set the threshold for suppressing display of repeated array
- elements. When the number of consecutive identical elements of an
- array exceeds the threshold, GDB prints the string `"<repeats N
- times>"', where N is the number of identical repetitions, instead
- of displaying the identical elements themselves. Setting the
- threshold to zero will cause all elements to be individually
- printed. The default threshold is 10.
-
-`show print repeats'
- Display the current threshold for printing repeated identical
- elements.
-
-`set print null-stop'
- Cause GDB to stop printing the characters of an array when the
- first NULL is encountered. This is useful when large arrays
- actually contain only short strings. The default is off.
-
-`show print null-stop'
- Show whether GDB stops printing an array on the first NULL
- character.
-
-`set print pretty on'
- Cause GDB to print structures in an indented format with one member
- per line, like this:
-
- $1 = {
- next = 0x0,
- flags = {
- sweet = 1,
- sour = 1
- },
- meat = 0x54 "Pork"
- }
-
-`set print pretty off'
- Cause GDB to print structures in a compact format, like this:
-
- $1 = {next = 0x0, flags = {sweet = 1, sour = 1}, \
- meat = 0x54 "Pork"}
-
- This is the default format.
-
-`show print pretty'
- Show which format GDB is using to print structures.
-
-`set print sevenbit-strings on'
- Print using only seven-bit characters; if this option is set, GDB
- displays any eight-bit characters (in strings or character values)
- using the notation `\'NNN. This setting is best if you are
- working in English (ASCII) and you use the high-order bit of
- characters as a marker or "meta" bit.
-
-`set print sevenbit-strings off'
- Print full eight-bit characters. This allows the use of more
- international character sets, and is the default.
-
-`show print sevenbit-strings'
- Show whether or not GDB is printing only seven-bit characters.
-
-`set print union on'
- Tell GDB to print unions which are contained in structures and
- other unions. This is the default setting.
-
-`set print union off'
- Tell GDB not to print unions which are contained in structures and
- other unions. GDB will print `"{...}"' instead.
-
-`show print union'
- Ask GDB whether or not it will print unions which are contained in
- structures and other unions.
-
- For example, given the declarations
-
- typedef enum {Tree, Bug} Species;
- typedef enum {Big_tree, Acorn, Seedling} Tree_forms;
- typedef enum {Caterpillar, Cocoon, Butterfly}
- Bug_forms;
-
- struct thing {
- Species it;
- union {
- Tree_forms tree;
- Bug_forms bug;
- } form;
- };
-
- struct thing foo = {Tree, {Acorn}};
-
- with `set print union on' in effect `p foo' would print
-
- $1 = {it = Tree, form = {tree = Acorn, bug = Cocoon}}
-
- and with `set print union off' in effect it would print
-
- $1 = {it = Tree, form = {...}}
-
- `set print union' affects programs written in C-like languages and
- in Pascal.
-
-These settings are of interest when debugging C++ programs:
-
-`set print demangle'
-`set print demangle on'
- Print C++ names in their source form rather than in the encoded
- ("mangled") form passed to the assembler and linker for type-safe
- linkage. The default is on.
-
-`show print demangle'
- Show whether C++ names are printed in mangled or demangled form.
-
-`set print asm-demangle'
-`set print asm-demangle on'
- Print C++ names in their source form rather than their mangled
- form, even in assembler code printouts such as instruction
- disassemblies. The default is off.
-
-`show print asm-demangle'
- Show whether C++ names in assembly listings are printed in mangled
- or demangled form.
-
-`set demangle-style STYLE'
- Choose among several encoding schemes used by different compilers
- to represent C++ names. The choices for STYLE are currently:
-
- `auto'
- Allow GDB to choose a decoding style by inspecting your
- program.
-
- `gnu'
- Decode based on the GNU C++ compiler (`g++') encoding
- algorithm. This is the default.
-
- `hp'
- Decode based on the HP ANSI C++ (`aCC') encoding algorithm.
-
- `lucid'
- Decode based on the Lucid C++ compiler (`lcc') encoding
- algorithm.
-
- `arm'
- Decode using the algorithm in the `C++ Annotated Reference
- Manual'. *Warning:* this setting alone is not sufficient to
- allow debugging `cfront'-generated executables. GDB would
- require further enhancement to permit that.
-
- If you omit STYLE, you will see a list of possible formats.
-
-`show demangle-style'
- Display the encoding style currently in use for decoding C++
- symbols.
-
-`set print object'
-`set print object on'
- When displaying a pointer to an object, identify the _actual_
- (derived) type of the object rather than the _declared_ type, using
- the virtual function table.
-
-`set print object off'
- Display only the declared type of objects, without reference to the
- virtual function table. This is the default setting.
-
-`show print object'
- Show whether actual, or declared, object types are displayed.
-
-`set print static-members'
-`set print static-members on'
- Print static members when displaying a C++ object. The default is
- on.
-
-`set print static-members off'
- Do not print static members when displaying a C++ object.
-
-`show print static-members'
- Show whether C++ static members are printed or not.
-
-`set print pascal_static-members'
-`set print pascal_static-members on'
- Print static members when displaying a Pascal object. The default
- is on.
-
-`set print pascal_static-members off'
- Do not print static members when displaying a Pascal object.
-
-`show print pascal_static-members'
- Show whether Pascal static members are printed or not.
-
-`set print vtbl'
-`set print vtbl on'
- Pretty print C++ virtual function tables. The default is off.
- (The `vtbl' commands do not work on programs compiled with the HP
- ANSI C++ compiler (`aCC').)
-
-`set print vtbl off'
- Do not pretty print C++ virtual function tables.
-
-`show print vtbl'
- Show whether C++ virtual function tables are pretty printed, or
- not.
-
-
-File: gdb.info, Node: Pretty Printing, Next: Value History, Prev: Print Settings, Up: Data
-
-10.9 Pretty Printing
-====================
-
-GDB provides a mechanism to allow pretty-printing of values using
-Python code. It greatly simplifies the display of complex objects.
-This mechanism works for both MI and the CLI.
-
-* Menu:
-
-* Pretty-Printer Introduction:: Introduction to pretty-printers
-* Pretty-Printer Example:: An example pretty-printer
-* Pretty-Printer Commands:: Pretty-printer commands
-
-
-File: gdb.info, Node: Pretty-Printer Introduction, Next: Pretty-Printer Example, Up: Pretty Printing
-
-10.9.1 Pretty-Printer Introduction
-----------------------------------
-
-When GDB prints a value, it first sees if there is a pretty-printer
-registered for the value. If there is then GDB invokes the
-pretty-printer to print the value. Otherwise the value is printed
-normally.
-
- Pretty-printers are normally named. This makes them easy to manage.
-The `info pretty-printer' command will list all the installed
-pretty-printers with their names. If a pretty-printer can handle
-multiple data types, then its "subprinters" are the printers for the
-individual data types. Each such subprinter has its own name. The
-format of the name is PRINTER-NAME;SUBPRINTER-NAME.
-
- Pretty-printers are installed by "registering" them with GDB.
-Typically they are automatically loaded and registered when the
-corresponding debug information is loaded, thus making them available
-without having to do anything special.
-
- There are three places where a pretty-printer can be registered.
-
- * Pretty-printers registered globally are available when debugging
- all inferiors.
-
- * Pretty-printers registered with a program space are available only
- when debugging that program. *Note Progspaces In Python::, for
- more details on program spaces in Python.
-
- * Pretty-printers registered with an objfile are loaded and unloaded
- with the corresponding objfile (e.g., shared library). *Note
- Objfiles In Python::, for more details on objfiles in Python.
-
- *Note Selecting Pretty-Printers::, for further information on how
-pretty-printers are selected,
-
- *Note Writing a Pretty-Printer::, for implementing pretty printers
-for new types.
-
-
-File: gdb.info, Node: Pretty-Printer Example, Next: Pretty-Printer Commands, Prev: Pretty-Printer Introduction, Up: Pretty Printing
-
-10.9.2 Pretty-Printer Example
------------------------------
-
-Here is how a C++ `std::string' looks without a pretty-printer:
-
- (gdb) print s
- $1 = {
- static npos = 4294967295,
- _M_dataplus = {
- <std::allocator<char>> = {
- <__gnu_cxx::new_allocator<char>> = {
- <No data fields>}, <No data fields>
- },
- members of std::basic_string<char, std::char_traits<char>,
- std::allocator<char> >::_Alloc_hider:
- _M_p = 0x804a014 "abcd"
- }
- }
-
- With a pretty-printer for `std::string' only the contents are
-printed:
-
- (gdb) print s
- $2 = "abcd"
-
-
-File: gdb.info, Node: Pretty-Printer Commands, Prev: Pretty-Printer Example, Up: Pretty Printing
-
-10.9.3 Pretty-Printer Commands
-------------------------------
-
-`info pretty-printer [OBJECT-REGEXP [NAME-REGEXP]]'
- Print the list of installed pretty-printers. This includes
- disabled pretty-printers, which are marked as such.
-
- OBJECT-REGEXP is a regular expression matching the objects whose
- pretty-printers to list. Objects can be `global', the program
- space's file (*note Progspaces In Python::), and the object files
- within that program space (*note Objfiles In Python::). *Note
- Selecting Pretty-Printers::, for details on how GDB looks up a
- printer from these three objects.
-
- NAME-REGEXP is a regular expression matching the name of the
- printers to list.
-
-`disable pretty-printer [OBJECT-REGEXP [NAME-REGEXP]]'
- Disable pretty-printers matching OBJECT-REGEXP and NAME-REGEXP. A
- disabled pretty-printer is not forgotten, it may be enabled again
- later.
-
-`enable pretty-printer [OBJECT-REGEXP [NAME-REGEXP]]'
- Enable pretty-printers matching OBJECT-REGEXP and NAME-REGEXP.
-
- Example:
-
- Suppose we have three pretty-printers installed: one from library1.so
-named `foo' that prints objects of type `foo', and another from
-library2.so named `bar' that prints two types of objects, `bar1' and
-`bar2'.
-
- (gdb) info pretty-printer
- library1.so:
- foo
- library2.so:
- bar
- bar1
- bar2
- (gdb) info pretty-printer library2
- library2.so:
- bar
- bar1
- bar2
- (gdb) disable pretty-printer library1
- 1 printer disabled
- 2 of 3 printers enabled
- (gdb) info pretty-printer
- library1.so:
- foo [disabled]
- library2.so:
- bar
- bar1
- bar2
- (gdb) disable pretty-printer library2 bar:bar1
- 1 printer disabled
- 1 of 3 printers enabled
- (gdb) info pretty-printer library2
- library1.so:
- foo [disabled]
- library2.so:
- bar
- bar1 [disabled]
- bar2
- (gdb) disable pretty-printer library2 bar
- 1 printer disabled
- 0 of 3 printers enabled
- (gdb) info pretty-printer library2
- library1.so:
- foo [disabled]
- library2.so:
- bar [disabled]
- bar1 [disabled]
- bar2
-
- Note that for `bar' the entire printer can be disabled, as can each
-individual subprinter.
-
-
-File: gdb.info, Node: Value History, Next: Convenience Vars, Prev: Pretty Printing, Up: Data
-
-10.10 Value History
-===================
-
-Values printed by the `print' command are saved in the GDB "value
-history". This allows you to refer to them in other expressions.
-Values are kept until the symbol table is re-read or discarded (for
-example with the `file' or `symbol-file' commands). When the symbol
-table changes, the value history is discarded, since the values may
-contain pointers back to the types defined in the symbol table.
-
- The values printed are given "history numbers" by which you can
-refer to them. These are successive integers starting with one.
-`print' shows you the history number assigned to a value by printing
-`$NUM = ' before the value; here NUM is the history number.
-
- To refer to any previous value, use `$' followed by the value's
-history number. The way `print' labels its output is designed to
-remind you of this. Just `$' refers to the most recent value in the
-history, and `$$' refers to the value before that. `$$N' refers to the
-Nth value from the end; `$$2' is the value just prior to `$$', `$$1' is
-equivalent to `$$', and `$$0' is equivalent to `$'.
-
- For example, suppose you have just printed a pointer to a structure
-and want to see the contents of the structure. It suffices to type
-
- p *$
-
- If you have a chain of structures where the component `next' points
-to the next one, you can print the contents of the next one with this:
-
- p *$.next
-
-You can print successive links in the chain by repeating this
-command--which you can do by just typing <RET>.
-
- Note that the history records values, not expressions. If the value
-of `x' is 4 and you type these commands:
-
- print x
- set x=5
-
-then the value recorded in the value history by the `print' command
-remains 4 even though the value of `x' has changed.
-
-`show values'
- Print the last ten values in the value history, with their item
- numbers. This is like `p $$9' repeated ten times, except that
- `show values' does not change the history.
-
-`show values N'
- Print ten history values centered on history item number N.
-
-`show values +'
- Print ten history values just after the values last printed. If
- no more values are available, `show values +' produces no display.
-
- Pressing <RET> to repeat `show values N' has exactly the same effect
-as `show values +'.
-
-
-File: gdb.info, Node: Convenience Vars, Next: Registers, Prev: Value History, Up: Data
-
-10.11 Convenience Variables
-===========================
-
-GDB provides "convenience variables" that you can use within GDB to
-hold on to a value and refer to it later. These variables exist
-entirely within GDB; they are not part of your program, and setting a
-convenience variable has no direct effect on further execution of your
-program. That is why you can use them freely.
-
- Convenience variables are prefixed with `$'. Any name preceded by
-`$' can be used for a convenience variable, unless it is one of the
-predefined machine-specific register names (*note Registers:
-Registers.). (Value history references, in contrast, are _numbers_
-preceded by `$'. *Note Value History: Value History.)
-
- You can save a value in a convenience variable with an assignment
-expression, just as you would set a variable in your program. For
-example:
-
- set $foo = *object_ptr
-
-would save in `$foo' the value contained in the object pointed to by
-`object_ptr'.
-
- Using a convenience variable for the first time creates it, but its
-value is `void' until you assign a new value. You can alter the value
-with another assignment at any time.
-
- Convenience variables have no fixed types. You can assign a
-convenience variable any type of value, including structures and
-arrays, even if that variable already has a value of a different type.
-The convenience variable, when used as an expression, has the type of
-its current value.
-
-`show convenience'
- Print a list of convenience variables used so far, and their
- values. Abbreviated `show conv'.
-
-`init-if-undefined $VARIABLE = EXPRESSION'
- Set a convenience variable if it has not already been set. This
- is useful for user-defined commands that keep some state. It is
- similar, in concept, to using local static variables with
- initializers in C (except that convenience variables are global).
- It can also be used to allow users to override default values used
- in a command script.
-
- If the variable is already defined then the expression is not
- evaluated so any side-effects do not occur.
-
- One of the ways to use a convenience variable is as a counter to be
-incremented or a pointer to be advanced. For example, to print a field
-from successive elements of an array of structures:
-
- set $i = 0
- print bar[$i++]->contents
-
-Repeat that command by typing <RET>.
-
- Some convenience variables are created automatically by GDB and given
-values likely to be useful.
-
-`$_'
- The variable `$_' is automatically set by the `x' command to the
- last address examined (*note Examining Memory: Memory.). Other
- commands which provide a default address for `x' to examine also
- set `$_' to that address; these commands include `info line' and
- `info breakpoint'. The type of `$_' is `void *' except when set
- by the `x' command, in which case it is a pointer to the type of
- `$__'.
-
-`$__'
- The variable `$__' is automatically set by the `x' command to the
- value found in the last address examined. Its type is chosen to
- match the format in which the data was printed.
-
-`$_exitcode'
- The variable `$_exitcode' is automatically set to the exit code
- when the program being debugged terminates.
-
-`$_sdata'
- The variable `$_sdata' contains extra collected static tracepoint
- data. *Note Tracepoint Action Lists: Tracepoint Actions. Note
- that `$_sdata' could be empty, if not inspecting a trace buffer, or
- if extra static tracepoint data has not been collected.
-
-`$_siginfo'
- The variable `$_siginfo' contains extra signal information (*note
- extra signal information::). Note that `$_siginfo' could be
- empty, if the application has not yet received any signals. For
- example, it will be empty before you execute the `run' command.
-
-`$_tlb'
- The variable `$_tlb' is automatically set when debugging
- applications running on MS-Windows in native mode or connected to
- gdbserver that supports the `qGetTIBAddr' request. *Note General
- Query Packets::. This variable contains the address of the thread
- information block.
-
-
- On HP-UX systems, if you refer to a function or variable name that
-begins with a dollar sign, GDB searches for a user or system name
-first, before it searches for a convenience variable.
-
- GDB also supplies some "convenience functions". These have a syntax
-similar to convenience variables. A convenience function can be used
-in an expression just like an ordinary function; however, a convenience
-function is implemented internally to GDB.
-
-`help function'
- Print a list of all convenience functions.
-
-
-File: gdb.info, Node: Registers, Next: Floating Point Hardware, Prev: Convenience Vars, Up: Data
-
-10.12 Registers
-===============
-
-You can refer to machine register contents, in expressions, as variables
-with names starting with `$'. The names of registers are different for
-each machine; use `info registers' to see the names used on your
-machine.
-
-`info registers'
- Print the names and values of all registers except floating-point
- and vector registers (in the selected stack frame).
-
-`info all-registers'
- Print the names and values of all registers, including
- floating-point and vector registers (in the selected stack frame).
-
-`info registers REGNAME ...'
- Print the "relativized" value of each specified register REGNAME.
- As discussed in detail below, register values are normally
- relative to the selected stack frame. REGNAME may be any register
- name valid on the machine you are using, with or without the
- initial `$'.
-
- GDB has four "standard" register names that are available (in
-expressions) on most machines--whenever they do not conflict with an
-architecture's canonical mnemonics for registers. The register names
-`$pc' and `$sp' are used for the program counter register and the stack
-pointer. `$fp' is used for a register that contains a pointer to the
-current stack frame, and `$ps' is used for a register that contains the
-processor status. For example, you could print the program counter in
-hex with
-
- p/x $pc
-
-or print the instruction to be executed next with
-
- x/i $pc
-
-or add four to the stack pointer(1) with
-
- set $sp += 4
-
- Whenever possible, these four standard register names are available
-on your machine even though the machine has different canonical
-mnemonics, so long as there is no conflict. The `info registers'
-command shows the canonical names. For example, on the SPARC, `info
-registers' displays the processor status register as `$psr' but you can
-also refer to it as `$ps'; and on x86-based machines `$ps' is an alias
-for the EFLAGS register.
-
- GDB always considers the contents of an ordinary register as an
-integer when the register is examined in this way. Some machines have
-special registers which can hold nothing but floating point; these
-registers are considered to have floating point values. There is no way
-to refer to the contents of an ordinary register as floating point value
-(although you can _print_ it as a floating point value with `print/f
-$REGNAME').
-
- Some registers have distinct "raw" and "virtual" data formats. This
-means that the data format in which the register contents are saved by
-the operating system is not the same one that your program normally
-sees. For example, the registers of the 68881 floating point
-coprocessor are always saved in "extended" (raw) format, but all C
-programs expect to work with "double" (virtual) format. In such cases,
-GDB normally works with the virtual format only (the format that makes
-sense for your program), but the `info registers' command prints the
-data in both formats.
-
- Some machines have special registers whose contents can be
-interpreted in several different ways. For example, modern x86-based
-machines have SSE and MMX registers that can hold several values packed
-together in several different formats. GDB refers to such registers in
-`struct' notation:
-
- (gdb) print $xmm1
- $1 = {
- v4_float = {0, 3.43859137e-038, 1.54142831e-044, 1.821688e-044},
- v2_double = {9.92129282474342e-303, 2.7585945287983262e-313},
- v16_int8 = "\000\000\000\000\3706;\001\v\000\000\000\r\000\000",
- v8_int16 = {0, 0, 14072, 315, 11, 0, 13, 0},
- v4_int32 = {0, 20657912, 11, 13},
- v2_int64 = {88725056443645952, 55834574859},
- uint128 = 0x0000000d0000000b013b36f800000000
- }
-
-To set values of such registers, you need to tell GDB which view of the
-register you wish to change, as if you were assigning value to a
-`struct' member:
-
- (gdb) set $xmm1.uint128 = 0x000000000000000000000000FFFFFFFF
-
- Normally, register values are relative to the selected stack frame
-(*note Selecting a Frame: Selection.). This means that you get the
-value that the register would contain if all stack frames farther in
-were exited and their saved registers restored. In order to see the
-true contents of hardware registers, you must select the innermost
-frame (with `frame 0').
-
- However, GDB must deduce where registers are saved, from the machine
-code generated by your compiler. If some registers are not saved, or if
-GDB is unable to locate the saved registers, the selected stack frame
-makes no difference.
-
- ---------- Footnotes ----------
-
- (1) This is a way of removing one word from the stack, on machines
-where stacks grow downward in memory (most machines, nowadays). This
-assumes that the innermost stack frame is selected; setting `$sp' is
-not allowed when other stack frames are selected. To pop entire frames
-off the stack, regardless of machine architecture, use `return'; see
-*note Returning from a Function: Returning.
-
-
-File: gdb.info, Node: Floating Point Hardware, Next: Vector Unit, Prev: Registers, Up: Data
-
-10.13 Floating Point Hardware
-=============================
-
-Depending on the configuration, GDB may be able to give you more
-information about the status of the floating point hardware.
-
-`info float'
- Display hardware-dependent information about the floating point
- unit. The exact contents and layout vary depending on the
- floating point chip. Currently, `info float' is supported on the
- ARM and x86 machines.
-
-
-File: gdb.info, Node: Vector Unit, Next: OS Information, Prev: Floating Point Hardware, Up: Data
-
-10.14 Vector Unit
-=================
-
-Depending on the configuration, GDB may be able to give you more
-information about the status of the vector unit.
-
-`info vector'
- Display information about the vector unit. The exact contents and
- layout vary depending on the hardware.
-
-
-File: gdb.info, Node: OS Information, Next: Memory Region Attributes, Prev: Vector Unit, Up: Data
-
-10.15 Operating System Auxiliary Information
-============================================
-
-GDB provides interfaces to useful OS facilities that can help you debug
-your program.
-
- When GDB runs on a "Posix system" (such as GNU or Unix machines), it
-interfaces with the inferior via the `ptrace' system call. The
-operating system creates a special sata structure, called `struct
-user', for this interface. You can use the command `info udot' to
-display the contents of this data structure.
-
-`info udot'
- Display the contents of the `struct user' maintained by the OS
- kernel for the program being debugged. GDB displays the contents
- of `struct user' as a list of hex numbers, similar to the
- `examine' command.
-
- Some operating systems supply an "auxiliary vector" to programs at
-startup. This is akin to the arguments and environment that you
-specify for a program, but contains a system-dependent variety of
-binary values that tell system libraries important details about the
-hardware, operating system, and process. Each value's purpose is
-identified by an integer tag; the meanings are well-known but
-system-specific. Depending on the configuration and operating system
-facilities, GDB may be able to show you this information. For remote
-targets, this functionality may further depend on the remote stub's
-support of the `qXfer:auxv:read' packet, see *note qXfer auxiliary
-vector read::.
-
-`info auxv'
- Display the auxiliary vector of the inferior, which can be either a
- live process or a core dump file. GDB prints each tag value
- numerically, and also shows names and text descriptions for
- recognized tags. Some values in the vector are numbers, some bit
- masks, and some pointers to strings or other data. GDB displays
- each value in the most appropriate form for a recognized tag, and
- in hexadecimal for an unrecognized tag.
-
- On some targets, GDB can access operating-system-specific information
-and display it to user, without interpretation. For remote targets,
-this functionality depends on the remote stub's support of the
-`qXfer:osdata:read' packet, see *note qXfer osdata read::.
-
-`info os'
- List the types of OS information available for the target. If the
- target does not return a list of possible types, this command will
- report an error.
-
-`info os processes'
- Display the list of processes on the target. For each process,
- GDB prints the process identifier, the name of the user, and the
- command corresponding to the process.
-
-
-File: gdb.info, Node: Memory Region Attributes, Next: Dump/Restore Files, Prev: OS Information, Up: Data
-
-10.16 Memory Region Attributes
-==============================
-
-"Memory region attributes" allow you to describe special handling
-required by regions of your target's memory. GDB uses attributes to
-determine whether to allow certain types of memory accesses; whether to
-use specific width accesses; and whether to cache target memory. By
-default the description of memory regions is fetched from the target
-(if the current target supports this), but the user can override the
-fetched regions.
-
- Defined memory regions can be individually enabled and disabled.
-When a memory region is disabled, GDB uses the default attributes when
-accessing memory in that region. Similarly, if no memory regions have
-been defined, GDB uses the default attributes when accessing all memory.
-
- When a memory region is defined, it is given a number to identify it;
-to enable, disable, or remove a memory region, you specify that number.
-
-`mem LOWER UPPER ATTRIBUTES...'
- Define a memory region bounded by LOWER and UPPER with attributes
- ATTRIBUTES..., and add it to the list of regions monitored by GDB.
- Note that UPPER == 0 is a special case: it is treated as the
- target's maximum memory address. (0xffff on 16 bit targets,
- 0xffffffff on 32 bit targets, etc.)
-
-`mem auto'
- Discard any user changes to the memory regions and use
- target-supplied regions, if available, or no regions if the target
- does not support.
-
-`delete mem NUMS...'
- Remove memory regions NUMS... from the list of regions monitored
- by GDB.
-
-`disable mem NUMS...'
- Disable monitoring of memory regions NUMS.... A disabled memory
- region is not forgotten. It may be enabled again later.
-
-`enable mem NUMS...'
- Enable monitoring of memory regions NUMS....
-
-`info mem'
- Print a table of all defined memory regions, with the following
- columns for each region:
-
- _Memory Region Number_
-
- _Enabled or Disabled._
- Enabled memory regions are marked with `y'. Disabled memory
- regions are marked with `n'.
-
- _Lo Address_
- The address defining the inclusive lower bound of the memory
- region.
-
- _Hi Address_
- The address defining the exclusive upper bound of the memory
- region.
-
- _Attributes_
- The list of attributes set for this memory region.
-
-10.16.1 Attributes
-------------------
-
-10.16.1.1 Memory Access Mode
-............................
-
-The access mode attributes set whether GDB may make read or write
-accesses to a memory region.
-
- While these attributes prevent GDB from performing invalid memory
-accesses, they do nothing to prevent the target system, I/O DMA, etc.
-from accessing memory.
-
-`ro'
- Memory is read only.
-
-`wo'
- Memory is write only.
-
-`rw'
- Memory is read/write. This is the default.
-
-10.16.1.2 Memory Access Size
-............................
-
-The access size attribute tells GDB to use specific sized accesses in
-the memory region. Often memory mapped device registers require
-specific sized accesses. If no access size attribute is specified, GDB
-may use accesses of any size.
-
-`8'
- Use 8 bit memory accesses.
-
-`16'
- Use 16 bit memory accesses.
-
-`32'
- Use 32 bit memory accesses.
-
-`64'
- Use 64 bit memory accesses.
-
-10.16.1.3 Data Cache
-....................
-
-The data cache attributes set whether GDB will cache target memory.
-While this generally improves performance by reducing debug protocol
-overhead, it can lead to incorrect results because GDB does not know
-about volatile variables or memory mapped device registers.
-
-`cache'
- Enable GDB to cache target memory.
-
-`nocache'
- Disable GDB from caching target memory. This is the default.
-
-10.16.2 Memory Access Checking
-------------------------------
-
-GDB can be instructed to refuse accesses to memory that is not
-explicitly described. This can be useful if accessing such regions has
-undesired effects for a specific target, or to provide better error
-checking. The following commands control this behaviour.
-
-`set mem inaccessible-by-default [on|off]'
- If `on' is specified, make GDB treat memory not explicitly
- described by the memory ranges as non-existent and refuse accesses
- to such memory. The checks are only performed if there's at least
- one memory range defined. If `off' is specified, make GDB treat
- the memory not explicitly described by the memory ranges as RAM.
- The default value is `on'.
-
-`show mem inaccessible-by-default'
- Show the current handling of accesses to unknown memory.
-
-
-File: gdb.info, Node: Dump/Restore Files, Next: Core File Generation, Prev: Memory Region Attributes, Up: Data
-
-10.17 Copy Between Memory and a File
-====================================
-
-You can use the commands `dump', `append', and `restore' to copy data
-between target memory and a file. The `dump' and `append' commands
-write data to a file, and the `restore' command reads data from a file
-back into the inferior's memory. Files may be in binary, Motorola
-S-record, Intel hex, or Tektronix Hex format; however, GDB can only
-append to binary files.
-
-`dump [FORMAT] memory FILENAME START_ADDR END_ADDR'
-`dump [FORMAT] value FILENAME EXPR'
- Dump the contents of memory from START_ADDR to END_ADDR, or the
- value of EXPR, to FILENAME in the given format.
-
- The FORMAT parameter may be any one of:
- `binary'
- Raw binary form.
-
- `ihex'
- Intel hex format.
-
- `srec'
- Motorola S-record format.
-
- `tekhex'
- Tektronix Hex format.
-
- GDB uses the same definitions of these formats as the GNU binary
- utilities, like `objdump' and `objcopy'. If FORMAT is omitted,
- GDB dumps the data in raw binary form.
-
-`append [binary] memory FILENAME START_ADDR END_ADDR'
-`append [binary] value FILENAME EXPR'
- Append the contents of memory from START_ADDR to END_ADDR, or the
- value of EXPR, to the file FILENAME, in raw binary form. (GDB can
- only append data to files in raw binary form.)
-
-`restore FILENAME [binary] BIAS START END'
- Restore the contents of file FILENAME into memory. The `restore'
- command can automatically recognize any known BFD file format,
- except for raw binary. To restore a raw binary file you must
- specify the optional keyword `binary' after the filename.
-
- If BIAS is non-zero, its value will be added to the addresses
- contained in the file. Binary files always start at address zero,
- so they will be restored at address BIAS. Other bfd files have a
- built-in location; they will be restored at offset BIAS from that
- location.
-
- If START and/or END are non-zero, then only data between file
- offset START and file offset END will be restored. These offsets
- are relative to the addresses in the file, before the BIAS
- argument is applied.
-
-
-
-File: gdb.info, Node: Core File Generation, Next: Character Sets, Prev: Dump/Restore Files, Up: Data
-
-10.18 How to Produce a Core File from Your Program
-==================================================
-
-A "core file" or "core dump" is a file that records the memory image of
-a running process and its process status (register values etc.). Its
-primary use is post-mortem debugging of a program that crashed while it
-ran outside a debugger. A program that crashes automatically produces
-a core file, unless this feature is disabled by the user. *Note
-Files::, for information on invoking GDB in the post-mortem debugging
-mode.
-
- Occasionally, you may wish to produce a core file of the program you
-are debugging in order to preserve a snapshot of its state. GDB has a
-special command for that.
-
-`generate-core-file [FILE]'
-`gcore [FILE]'
- Produce a core dump of the inferior process. The optional argument
- FILE specifies the file name where to put the core dump. If not
- specified, the file name defaults to `core.PID', where PID is the
- inferior process ID.
-
- Note that this command is implemented only for some systems (as of
- this writing, GNU/Linux, FreeBSD, Solaris, Unixware, and S390).
-
-
-File: gdb.info, Node: Character Sets, Next: Caching Remote Data, Prev: Core File Generation, Up: Data
-
-10.19 Character Sets
-====================
-
-If the program you are debugging uses a different character set to
-represent characters and strings than the one GDB uses itself, GDB can
-automatically translate between the character sets for you. The
-character set GDB uses we call the "host character set"; the one the
-inferior program uses we call the "target character set".
-
- For example, if you are running GDB on a GNU/Linux system, which
-uses the ISO Latin 1 character set, but you are using GDB's remote
-protocol (*note Remote Debugging::) to debug a program running on an
-IBM mainframe, which uses the EBCDIC character set, then the host
-character set is Latin-1, and the target character set is EBCDIC. If
-you give GDB the command `set target-charset EBCDIC-US', then GDB
-translates between EBCDIC and Latin 1 as you print character or string
-values, or use character and string literals in expressions.
-
- GDB has no way to automatically recognize which character set the
-inferior program uses; you must tell it, using the `set target-charset'
-command, described below.
-
- Here are the commands for controlling GDB's character set support:
-
-`set target-charset CHARSET'
- Set the current target character set to CHARSET. To display the
- list of supported target character sets, type
- `set target-charset <TAB><TAB>'.
-
-`set host-charset CHARSET'
- Set the current host character set to CHARSET.
-
- By default, GDB uses a host character set appropriate to the
- system it is running on; you can override that default using the
- `set host-charset' command. On some systems, GDB cannot
- automatically determine the appropriate host character set. In
- this case, GDB uses `UTF-8'.
-
- GDB can only use certain character sets as its host character set.
- If you type `set host-charset <TAB><TAB>', GDB will list the host
- character sets it supports.
-
-`set charset CHARSET'
- Set the current host and target character sets to CHARSET. As
- above, if you type `set charset <TAB><TAB>', GDB will list the
- names of the character sets that can be used for both host and
- target.
-
-`show charset'
- Show the names of the current host and target character sets.
-
-`show host-charset'
- Show the name of the current host character set.
-
-`show target-charset'
- Show the name of the current target character set.
-
-`set target-wide-charset CHARSET'
- Set the current target's wide character set to CHARSET. This is
- the character set used by the target's `wchar_t' type. To display
- the list of supported wide character sets, type
- `set target-wide-charset <TAB><TAB>'.
-
-`show target-wide-charset'
- Show the name of the current target's wide character set.
-
- Here is an example of GDB's character set support in action. Assume
-that the following source code has been placed in the file
-`charset-test.c':
-
- #include <stdio.h>
-
- char ascii_hello[]
- = {72, 101, 108, 108, 111, 44, 32, 119,
- 111, 114, 108, 100, 33, 10, 0};
- char ibm1047_hello[]
- = {200, 133, 147, 147, 150, 107, 64, 166,
- 150, 153, 147, 132, 90, 37, 0};
-
- main ()
- {
- printf ("Hello, world!\n");
- }
-
- In this program, `ascii_hello' and `ibm1047_hello' are arrays
-containing the string `Hello, world!' followed by a newline, encoded in
-the ASCII and IBM1047 character sets.
-
- We compile the program, and invoke the debugger on it:
-
- $ gcc -g charset-test.c -o charset-test
- $ gdb -nw charset-test
- GNU gdb 2001-12-19-cvs
- Copyright 2001 Free Software Foundation, Inc.
- ...
- (gdb)
-
- We can use the `show charset' command to see what character sets GDB
-is currently using to interpret and display characters and strings:
-
- (gdb) show charset
- The current host and target character set is `ISO-8859-1'.
- (gdb)
-
- For the sake of printing this manual, let's use ASCII as our initial
-character set:
- (gdb) set charset ASCII
- (gdb) show charset
- The current host and target character set is `ASCII'.
- (gdb)
-
- Let's assume that ASCII is indeed the correct character set for our
-host system -- in other words, let's assume that if GDB prints
-characters using the ASCII character set, our terminal will display
-them properly. Since our current target character set is also ASCII,
-the contents of `ascii_hello' print legibly:
-
- (gdb) print ascii_hello
- $1 = 0x401698 "Hello, world!\n"
- (gdb) print ascii_hello[0]
- $2 = 72 'H'
- (gdb)
-
- GDB uses the target character set for character and string literals
-you use in expressions:
-
- (gdb) print '+'
- $3 = 43 '+'
- (gdb)
-
- The ASCII character set uses the number 43 to encode the `+'
-character.
-
- GDB relies on the user to tell it which character set the target
-program uses. If we print `ibm1047_hello' while our target character
-set is still ASCII, we get jibberish:
-
- (gdb) print ibm1047_hello
- $4 = 0x4016a8 "\310\205\223\223\226k@\246\226\231\223\204Z%"
- (gdb) print ibm1047_hello[0]
- $5 = 200 '\310'
- (gdb)
-
- If we invoke the `set target-charset' followed by <TAB><TAB>, GDB
-tells us the character sets it supports:
-
- (gdb) set target-charset
- ASCII EBCDIC-US IBM1047 ISO-8859-1
- (gdb) set target-charset
-
- We can select IBM1047 as our target character set, and examine the
-program's strings again. Now the ASCII string is wrong, but GDB
-translates the contents of `ibm1047_hello' from the target character
-set, IBM1047, to the host character set, ASCII, and they display
-correctly:
-
- (gdb) set target-charset IBM1047
- (gdb) show charset
- The current host character set is `ASCII'.
- The current target character set is `IBM1047'.
- (gdb) print ascii_hello
- $6 = 0x401698 "\110\145%%?\054\040\167?\162%\144\041\012"
- (gdb) print ascii_hello[0]
- $7 = 72 '\110'
- (gdb) print ibm1047_hello
- $8 = 0x4016a8 "Hello, world!\n"
- (gdb) print ibm1047_hello[0]
- $9 = 200 'H'
- (gdb)
-
- As above, GDB uses the target character set for character and string
-literals you use in expressions:
-
- (gdb) print '+'
- $10 = 78 '+'
- (gdb)
-
- The IBM1047 character set uses the number 78 to encode the `+'
-character.
-
-
-File: gdb.info, Node: Caching Remote Data, Next: Searching Memory, Prev: Character Sets, Up: Data
-
-10.20 Caching Data of Remote Targets
-====================================
-
-GDB caches data exchanged between the debugger and a remote target
-(*note Remote Debugging::). Such caching generally improves
-performance, because it reduces the overhead of the remote protocol by
-bundling memory reads and writes into large chunks. Unfortunately,
-simply caching everything would lead to incorrect results, since GDB
-does not necessarily know anything about volatile values, memory-mapped
-I/O addresses, etc. Furthermore, in non-stop mode (*note Non-Stop
-Mode::) memory can be changed _while_ a gdb command is executing.
-Therefore, by default, GDB only caches data known to be on the stack(1).
-Other regions of memory can be explicitly marked as cacheable; see
-*note Memory Region Attributes::.
-
-`set remotecache on'
-`set remotecache off'
- This option no longer does anything; it exists for compatibility
- with old scripts.
-
-`show remotecache'
- Show the current state of the obsolete remotecache flag.
-
-`set stack-cache on'
-`set stack-cache off'
- Enable or disable caching of stack accesses. When `ON', use
- caching. By default, this option is `ON'.
-
-`show stack-cache'
- Show the current state of data caching for memory accesses.
-
-`info dcache [line]'
- Print the information about the data cache performance. The
- information displayed includes the dcache width and depth, and for
- each cache line, its number, address, and how many times it was
- referenced. This command is useful for debugging the data cache
- operation.
-
- If a line number is specified, the contents of that line will be
- printed in hex.
-
-`set dcache size SIZE'
- Set maximum number of entries in dcache (dcache depth above).
-
-`set dcache line-size LINE-SIZE'
- Set number of bytes each dcache entry caches (dcache width above).
- Must be a power of 2.
-
-`show dcache size'
- Show maximum number of dcache entries. See also *note info
- dcache: Caching Remote Data.
-
-`show dcache line-size'
- Show default size of dcache lines. See also *note info dcache:
- Caching Remote Data.
-
-
- ---------- Footnotes ----------
-
- (1) In non-stop mode, it is moderately rare for a running thread to
-modify the stack of a stopped thread in a way that would interfere with
-a backtrace, and caching of stack reads provides a significant speed up
-of remote backtraces.
-
-
-File: gdb.info, Node: Searching Memory, Prev: Caching Remote Data, Up: Data
-
-10.21 Search Memory
-===================
-
-Memory can be searched for a particular sequence of bytes with the
-`find' command.
-
-`find [/SN] START_ADDR, +LEN, VAL1 [, VAL2, ...]'
-`find [/SN] START_ADDR, END_ADDR, VAL1 [, VAL2, ...]'
- Search memory for the sequence of bytes specified by VAL1, VAL2,
- etc. The search begins at address START_ADDR and continues for
- either LEN bytes or through to END_ADDR inclusive.
-
- S and N are optional parameters. They may be specified in either
-order, apart or together.
-
-S, search query size
- The size of each search query value.
-
- `b'
- bytes
-
- `h'
- halfwords (two bytes)
-
- `w'
- words (four bytes)
-
- `g'
- giant words (eight bytes)
-
- All values are interpreted in the current language. This means,
- for example, that if the current source language is C/C++ then
- searching for the string "hello" includes the trailing '\0'.
-
- If the value size is not specified, it is taken from the value's
- type in the current language. This is useful when one wants to
- specify the search pattern as a mixture of types. Note that this
- means, for example, that in the case of C-like languages a search
- for an untyped 0x42 will search for `(int) 0x42' which is
- typically four bytes.
-
-N, maximum number of finds
- The maximum number of matches to print. The default is to print
- all finds.
-
- You can use strings as search values. Quote them with double-quotes
-(`"'). The string value is copied into the search pattern byte by byte,
-regardless of the endianness of the target and the size specification.
-
- The address of each match found is printed as well as a count of the
-number of matches found.
-
- The address of the last value found is stored in convenience variable
-`$_'. A count of the number of matches is stored in `$numfound'.
-
- For example, if stopped at the `printf' in this function:
-
- void
- hello ()
- {
- static char hello[] = "hello-hello";
- static struct { char c; short s; int i; }
- __attribute__ ((packed)) mixed
- = { 'c', 0x1234, 0x87654321 };
- printf ("%s\n", hello);
- }
-
-you get during debugging:
-
- (gdb) find &hello[0], +sizeof(hello), "hello"
- 0x804956d <hello.1620+6>
- 1 pattern found
- (gdb) find &hello[0], +sizeof(hello), 'h', 'e', 'l', 'l', 'o'
- 0x8049567 <hello.1620>
- 0x804956d <hello.1620+6>
- 2 patterns found
- (gdb) find /b1 &hello[0], +sizeof(hello), 'h', 0x65, 'l'
- 0x8049567 <hello.1620>
- 1 pattern found
- (gdb) find &mixed, +sizeof(mixed), (char) 'c', (short) 0x1234, (int) 0x87654321
- 0x8049560 <mixed.1625>
- 1 pattern found
- (gdb) print $numfound
- $1 = 1
- (gdb) print $_
- $2 = (void *) 0x8049560
-
-
-File: gdb.info, Node: Optimized Code, Next: Macros, Prev: Data, Up: Top
-
-11 Debugging Optimized Code
-***************************
-
-Almost all compilers support optimization. With optimization disabled,
-the compiler generates assembly code that corresponds directly to your
-source code, in a simplistic way. As the compiler applies more
-powerful optimizations, the generated assembly code diverges from your
-original source code. With help from debugging information generated
-by the compiler, GDB can map from the running program back to
-constructs from your original source.
-
- GDB is more accurate with optimization disabled. If you can
-recompile without optimization, it is easier to follow the progress of
-your program during debugging. But, there are many cases where you may
-need to debug an optimized version.
-
- When you debug a program compiled with `-g -O', remember that the
-optimizer has rearranged your code; the debugger shows you what is
-really there. Do not be too surprised when the execution path does not
-exactly match your source file! An extreme example: if you define a
-variable, but never use it, GDB never sees that variable--because the
-compiler optimizes it out of existence.
-
- Some things do not work as well with `-g -O' as with just `-g',
-particularly on machines with instruction scheduling. If in doubt,
-recompile with `-g' alone, and if this fixes the problem, please report
-it to us as a bug (including a test case!). *Note Variables::, for
-more information about debugging optimized code.
-
-* Menu:
-
-* Inline Functions:: How GDB presents inlining
-
-
-File: gdb.info, Node: Inline Functions, Up: Optimized Code
-
-11.1 Inline Functions
-=====================
-
-"Inlining" is an optimization that inserts a copy of the function body
-directly at each call site, instead of jumping to a shared routine.
-GDB displays inlined functions just like non-inlined functions. They
-appear in backtraces. You can view their arguments and local
-variables, step into them with `step', skip them with `next', and
-escape from them with `finish'. You can check whether a function was
-inlined by using the `info frame' command.
-
- For GDB to support inlined functions, the compiler must record
-information about inlining in the debug information -- GCC using the
-DWARF 2 format does this, and several other compilers do also. GDB
-only supports inlined functions when using DWARF 2. Versions of GCC
-before 4.1 do not emit two required attributes (`DW_AT_call_file' and
-`DW_AT_call_line'); GDB does not display inlined function calls with
-earlier versions of GCC. It instead displays the arguments and local
-variables of inlined functions as local variables in the caller.
-
- The body of an inlined function is directly included at its call
-site; unlike a non-inlined function, there are no instructions devoted
-to the call. GDB still pretends that the call site and the start of
-the inlined function are different instructions. Stepping to the call
-site shows the call site, and then stepping again shows the first line
-of the inlined function, even though no additional instructions are
-executed.
-
- This makes source-level debugging much clearer; you can see both the
-context of the call and then the effect of the call. Only stepping by
-a single instruction using `stepi' or `nexti' does not do this; single
-instruction steps always show the inlined body.
-
- There are some ways that GDB does not pretend that inlined function
-calls are the same as normal calls:
-
- * You cannot set breakpoints on inlined functions. GDB either
- reports that there is no symbol with that name, or else sets the
- breakpoint only on non-inlined copies of the function. This
- limitation will be removed in a future version of GDB; until then,
- set a breakpoint by line number on the first line of the inlined
- function instead.
-
- * Setting breakpoints at the call site of an inlined function may not
- work, because the call site does not contain any code. GDB may
- incorrectly move the breakpoint to the next line of the enclosing
- function, after the call. This limitation will be removed in a
- future version of GDB; until then, set a breakpoint on an earlier
- line or inside the inlined function instead.
-
- * GDB cannot locate the return value of inlined calls after using
- the `finish' command. This is a limitation of compiler-generated
- debugging information; after `finish', you can step to the next
- line and print a variable where your program stored the return
- value.
-
-
-
-File: gdb.info, Node: Macros, Next: Tracepoints, Prev: Optimized Code, Up: Top
-
-12 C Preprocessor Macros
-************************
-
-Some languages, such as C and C++, provide a way to define and invoke
-"preprocessor macros" which expand into strings of tokens. GDB can
-evaluate expressions containing macro invocations, show the result of
-macro expansion, and show a macro's definition, including where it was
-defined.
-
- You may need to compile your program specially to provide GDB with
-information about preprocessor macros. Most compilers do not include
-macros in their debugging information, even when you compile with the
-`-g' flag. *Note Compilation::.
-
- A program may define a macro at one point, remove that definition
-later, and then provide a different definition after that. Thus, at
-different points in the program, a macro may have different
-definitions, or have no definition at all. If there is a current stack
-frame, GDB uses the macros in scope at that frame's source code line.
-Otherwise, GDB uses the macros in scope at the current listing location;
-see *note List::.
-
- Whenever GDB evaluates an expression, it always expands any macro
-invocations present in the expression. GDB also provides the following
-commands for working with macros explicitly.
-
-`macro expand EXPRESSION'
-`macro exp EXPRESSION'
- Show the results of expanding all preprocessor macro invocations in
- EXPRESSION. Since GDB simply expands macros, but does not parse
- the result, EXPRESSION need not be a valid expression; it can be
- any string of tokens.
-
-`macro expand-once EXPRESSION'
-`macro exp1 EXPRESSION'
- (This command is not yet implemented.) Show the results of
- expanding those preprocessor macro invocations that appear
- explicitly in EXPRESSION. Macro invocations appearing in that
- expansion are left unchanged. This command allows you to see the
- effect of a particular macro more clearly, without being confused
- by further expansions. Since GDB simply expands macros, but does
- not parse the result, EXPRESSION need not be a valid expression; it
- can be any string of tokens.
-
-`info macro MACRO'
- Show the definition of the macro named MACRO, and describe the
- source location or compiler command-line where that definition was
- established.
-
-`macro define MACRO REPLACEMENT-LIST'
-`macro define MACRO(ARGLIST) REPLACEMENT-LIST'
- Introduce a definition for a preprocessor macro named MACRO,
- invocations of which are replaced by the tokens given in
- REPLACEMENT-LIST. The first form of this command defines an
- "object-like" macro, which takes no arguments; the second form
- defines a "function-like" macro, which takes the arguments given in
- ARGLIST.
-
- A definition introduced by this command is in scope in every
- expression evaluated in GDB, until it is removed with the `macro
- undef' command, described below. The definition overrides all
- definitions for MACRO present in the program being debugged, as
- well as any previous user-supplied definition.
-
-`macro undef MACRO'
- Remove any user-supplied definition for the macro named MACRO.
- This command only affects definitions provided with the `macro
- define' command, described above; it cannot remove definitions
- present in the program being debugged.
-
-`macro list'
- List all the macros defined using the `macro define' command.
-
- Here is a transcript showing the above commands in action. First, we
-show our source files:
-
- $ cat sample.c
- #include <stdio.h>
- #include "sample.h"
-
- #define M 42
- #define ADD(x) (M + x)
-
- main ()
- {
- #define N 28
- printf ("Hello, world!\n");
- #undef N
- printf ("We're so creative.\n");
- #define N 1729
- printf ("Goodbye, world!\n");
- }
- $ cat sample.h
- #define Q <
- $
-
- Now, we compile the program using the GNU C compiler, GCC. We pass
-the `-gdwarf-2' and `-g3' flags to ensure the compiler includes
-information about preprocessor macros in the debugging information.
-
- $ gcc -gdwarf-2 -g3 sample.c -o sample
- $
-
- Now, we start GDB on our sample program:
-
- $ gdb -nw sample
- GNU gdb 2002-05-06-cvs
- Copyright 2002 Free Software Foundation, Inc.
- GDB is free software, ...
- (gdb)
-
- We can expand macros and examine their definitions, even when the
-program is not running. GDB uses the current listing position to
-decide which macro definitions are in scope:
-
- (gdb) list main
- 3
- 4 #define M 42
- 5 #define ADD(x) (M + x)
- 6
- 7 main ()
- 8 {
- 9 #define N 28
- 10 printf ("Hello, world!\n");
- 11 #undef N
- 12 printf ("We're so creative.\n");
- (gdb) info macro ADD
- Defined at /home/jimb/gdb/macros/play/sample.c:5
- #define ADD(x) (M + x)
- (gdb) info macro Q
- Defined at /home/jimb/gdb/macros/play/sample.h:1
- included at /home/jimb/gdb/macros/play/sample.c:2
- #define Q <
- (gdb) macro expand ADD(1)
- expands to: (42 + 1)
- (gdb) macro expand-once ADD(1)
- expands to: once (M + 1)
- (gdb)
-
- In the example above, note that `macro expand-once' expands only the
-macro invocation explicit in the original text -- the invocation of
-`ADD' -- but does not expand the invocation of the macro `M', which was
-introduced by `ADD'.
-
- Once the program is running, GDB uses the macro definitions in force
-at the source line of the current stack frame:
-
- (gdb) break main
- Breakpoint 1 at 0x8048370: file sample.c, line 10.
- (gdb) run
- Starting program: /home/jimb/gdb/macros/play/sample
-
- Breakpoint 1, main () at sample.c:10
- 10 printf ("Hello, world!\n");
- (gdb)
-
- At line 10, the definition of the macro `N' at line 9 is in force:
-
- (gdb) info macro N
- Defined at /home/jimb/gdb/macros/play/sample.c:9
- #define N 28
- (gdb) macro expand N Q M
- expands to: 28 < 42
- (gdb) print N Q M
- $1 = 1
- (gdb)
-
- As we step over directives that remove `N''s definition, and then
-give it a new definition, GDB finds the definition (or lack thereof) in
-force at each point:
-
- (gdb) next
- Hello, world!
- 12 printf ("We're so creative.\n");
- (gdb) info macro N
- The symbol `N' has no definition as a C/C++ preprocessor macro
- at /home/jimb/gdb/macros/play/sample.c:12
- (gdb) next
- We're so creative.
- 14 printf ("Goodbye, world!\n");
- (gdb) info macro N
- Defined at /home/jimb/gdb/macros/play/sample.c:13
- #define N 1729
- (gdb) macro expand N Q M
- expands to: 1729 < 42
- (gdb) print N Q M
- $2 = 0
- (gdb)
-
- In addition to source files, macros can be defined on the
-compilation command line using the `-DNAME=VALUE' syntax. For macros
-defined in such a way, GDB displays the location of their definition as
-line zero of the source file submitted to the compiler.
-
- (gdb) info macro __STDC__
- Defined at /home/jimb/gdb/macros/play/sample.c:0
- -D__STDC__=1
- (gdb)
-
-
-File: gdb.info, Node: Tracepoints, Next: Overlays, Prev: Macros, Up: Top
-
-13 Tracepoints
-**************
-
-In some applications, it is not feasible for the debugger to interrupt
-the program's execution long enough for the developer to learn anything
-helpful about its behavior. If the program's correctness depends on
-its real-time behavior, delays introduced by a debugger might cause the
-program to change its behavior drastically, or perhaps fail, even when
-the code itself is correct. It is useful to be able to observe the
-program's behavior without interrupting it.
-
- Using GDB's `trace' and `collect' commands, you can specify
-locations in the program, called "tracepoints", and arbitrary
-expressions to evaluate when those tracepoints are reached. Later,
-using the `tfind' command, you can examine the values those expressions
-had when the program hit the tracepoints. The expressions may also
-denote objects in memory--structures or arrays, for example--whose
-values GDB should record; while visiting a particular tracepoint, you
-may inspect those objects as if they were in memory at that moment.
-However, because GDB records these values without interacting with you,
-it can do so quickly and unobtrusively, hopefully not disturbing the
-program's behavior.
-
- The tracepoint facility is currently available only for remote
-targets. *Note Targets::. In addition, your remote target must know
-how to collect trace data. This functionality is implemented in the
-remote stub; however, none of the stubs distributed with GDB support
-tracepoints as of this writing. The format of the remote packets used
-to implement tracepoints are described in *note Tracepoint Packets::.
-
- It is also possible to get trace data from a file, in a manner
-reminiscent of corefiles; you specify the filename, and use `tfind' to
-search through the file. *Note Trace Files::, for more details.
-
- This chapter describes the tracepoint commands and features.
-
-* Menu:
-
-* Set Tracepoints::
-* Analyze Collected Data::
-* Tracepoint Variables::
-* Trace Files::
-
-
-File: gdb.info, Node: Set Tracepoints, Next: Analyze Collected Data, Up: Tracepoints
-
-13.1 Commands to Set Tracepoints
-================================
-
-Before running such a "trace experiment", an arbitrary number of
-tracepoints can be set. A tracepoint is actually a special type of
-breakpoint (*note Set Breaks::), so you can manipulate it using
-standard breakpoint commands. For instance, as with breakpoints,
-tracepoint numbers are successive integers starting from one, and many
-of the commands associated with tracepoints take the tracepoint number
-as their argument, to identify which tracepoint to work on.
-
- For each tracepoint, you can specify, in advance, some arbitrary set
-of data that you want the target to collect in the trace buffer when it
-hits that tracepoint. The collected data can include registers, local
-variables, or global data. Later, you can use GDB commands to examine
-the values these data had at the time the tracepoint was hit.
-
- Tracepoints do not support every breakpoint feature. Ignore counts
-on tracepoints have no effect, and tracepoints cannot run GDB commands
-when they are hit. Tracepoints may not be thread-specific either.
-
- Some targets may support "fast tracepoints", which are inserted in a
-different way (such as with a jump instead of a trap), that is faster
-but possibly restricted in where they may be installed.
-
- Regular and fast tracepoints are dynamic tracing facilities, meaning
-that they can be used to insert tracepoints at (almost) any location in
-the target. Some targets may also support controlling "static
-tracepoints" from GDB. With static tracing, a set of instrumentation
-points, also known as "markers", are embedded in the target program,
-and can be activated or deactivated by name or address. These are
-usually placed at locations which facilitate investigating what the
-target is actually doing. GDB's support for static tracing includes
-being able to list instrumentation points, and attach them with GDB
-defined high level tracepoints that expose the whole range of
-convenience of GDB's tracepoints support. Namely, support for
-collecting registers values and values of global or local (to the
-instrumentation point) variables; tracepoint conditions and trace state
-variables. The act of installing a GDB static tracepoint on an
-instrumentation point, or marker, is referred to as "probing" a static
-tracepoint marker.
-
- `gdbserver' supports tracepoints on some target systems. *Note
-Tracepoints support in `gdbserver': Server.
-
- This section describes commands to set tracepoints and associated
-conditions and actions.
-
-* Menu:
-
-* Create and Delete Tracepoints::
-* Enable and Disable Tracepoints::
-* Tracepoint Passcounts::
-* Tracepoint Conditions::
-* Trace State Variables::
-* Tracepoint Actions::
-* Listing Tracepoints::
-* Listing Static Tracepoint Markers::
-* Starting and Stopping Trace Experiments::
-* Tracepoint Restrictions::
-
-
-File: gdb.info, Node: Create and Delete Tracepoints, Next: Enable and Disable Tracepoints, Up: Set Tracepoints
-
-13.1.1 Create and Delete Tracepoints
-------------------------------------
-
-`trace LOCATION'
- The `trace' command is very similar to the `break' command. Its
- argument LOCATION can be a source line, a function name, or an
- address in the target program. *Note Specify Location::. The
- `trace' command defines a tracepoint, which is a point in the
- target program where the debugger will briefly stop, collect some
- data, and then allow the program to continue. Setting a
- tracepoint or changing its actions doesn't take effect until the
- next `tstart' command, and once a trace experiment is running,
- further changes will not have any effect until the next trace
- experiment starts.
-
- Here are some examples of using the `trace' command:
-
- (gdb) trace foo.c:121 // a source file and line number
-
- (gdb) trace +2 // 2 lines forward
-
- (gdb) trace my_function // first source line of function
-
- (gdb) trace *my_function // EXACT start address of function
-
- (gdb) trace *0x2117c4 // an address
-
- You can abbreviate `trace' as `tr'.
-
-`trace LOCATION if COND'
- Set a tracepoint with condition COND; evaluate the expression COND
- each time the tracepoint is reached, and collect data only if the
- value is nonzero--that is, if COND evaluates as true. *Note
- Tracepoint Conditions: Tracepoint Conditions, for more information
- on tracepoint conditions.
-
-`ftrace LOCATION [ if COND ]'
- The `ftrace' command sets a fast tracepoint. For targets that
- support them, fast tracepoints will use a more efficient but
- possibly less general technique to trigger data collection, such
- as a jump instruction instead of a trap, or some sort of hardware
- support. It may not be possible to create a fast tracepoint at
- the desired location, in which case the command will exit with an
- explanatory message.
-
- GDB handles arguments to `ftrace' exactly as for `trace'.
-
-`strace LOCATION [ if COND ]'
- The `strace' command sets a static tracepoint. For targets that
- support it, setting a static tracepoint probes a static
- instrumentation point, or marker, found at LOCATION. It may not
- be possible to set a static tracepoint at the desired location, in
- which case the command will exit with an explanatory message.
-
- GDB handles arguments to `strace' exactly as for `trace', with the
- addition that the user can also specify `-m MARKER' as LOCATION.
- This probes the marker identified by the MARKER string identifier.
- This identifier depends on the static tracepoint backend library
- your program is using. You can find all the marker identifiers in
- the `ID' field of the `info static-tracepoint-markers' command
- output. *Note Listing Static Tracepoint Markers: Listing Static
- Tracepoint Markers. For example, in the following small program
- using the UST tracing engine:
-
- main ()
- {
- trace_mark(ust, bar33, "str %s", "FOOBAZ");
- }
-
- the marker id is composed of joining the first two arguments to the
- `trace_mark' call with a slash, which translates to:
-
- (gdb) info static-tracepoint-markers
- Cnt Enb ID Address What
- 1 n ust/bar33 0x0000000000400ddc in main at stexample.c:22
- Data: "str %s"
- [etc...]
-
- so you may probe the marker above with:
-
- (gdb) strace -m ust/bar33
-
- Static tracepoints accept an extra collect action -- `collect
- $_sdata'. This collects arbitrary user data passed in the probe
- point call to the tracing library. In the UST example above,
- you'll see that the third argument to `trace_mark' is a
- printf-like format string. The user data is then the result of
- running that formating string against the following arguments.
- Note that `info static-tracepoint-markers' command output lists
- that format string in the `Data:' field.
-
- You can inspect this data when analyzing the trace buffer, by
- printing the $_sdata variable like any other variable available to
- GDB. *Note Tracepoint Action Lists: Tracepoint Actions.
-
- The convenience variable `$tpnum' records the tracepoint number of
- the most recently set tracepoint.
-
-`delete tracepoint [NUM]'
- Permanently delete one or more tracepoints. With no argument, the
- default is to delete all tracepoints. Note that the regular
- `delete' command can remove tracepoints also.
-
- Examples:
-
- (gdb) delete trace 1 2 3 // remove three tracepoints
-
- (gdb) delete trace // remove all tracepoints
-
- You can abbreviate this command as `del tr'.
-
-
-File: gdb.info, Node: Enable and Disable Tracepoints, Next: Tracepoint Passcounts, Prev: Create and Delete Tracepoints, Up: Set Tracepoints
-
-13.1.2 Enable and Disable Tracepoints
--------------------------------------
-
-These commands are deprecated; they are equivalent to plain `disable'
-and `enable'.
-
-`disable tracepoint [NUM]'
- Disable tracepoint NUM, or all tracepoints if no argument NUM is
- given. A disabled tracepoint will have no effect during the next
- trace experiment, but it is not forgotten. You can re-enable a
- disabled tracepoint using the `enable tracepoint' command.
-
-`enable tracepoint [NUM]'
- Enable tracepoint NUM, or all tracepoints. The enabled
- tracepoints will become effective the next time a trace experiment
- is run.
-
-
-File: gdb.info, Node: Tracepoint Passcounts, Next: Tracepoint Conditions, Prev: Enable and Disable Tracepoints, Up: Set Tracepoints
-
-13.1.3 Tracepoint Passcounts
-----------------------------
-
-`passcount [N [NUM]]'
- Set the "passcount" of a tracepoint. The passcount is a way to
- automatically stop a trace experiment. If a tracepoint's
- passcount is N, then the trace experiment will be automatically
- stopped on the N'th time that tracepoint is hit. If the
- tracepoint number NUM is not specified, the `passcount' command
- sets the passcount of the most recently defined tracepoint. If no
- passcount is given, the trace experiment will run until stopped
- explicitly by the user.
-
- Examples:
-
- (gdb) passcount 5 2 // Stop on the 5th execution of
- `// tracepoint 2'
-
- (gdb) passcount 12 // Stop on the 12th execution of the
- `// most recently defined tracepoint.'
- (gdb) trace foo
- (gdb) pass 3
- (gdb) trace bar
- (gdb) pass 2
- (gdb) trace baz
- (gdb) pass 1 // Stop tracing when foo has been
- `// executed 3 times OR when bar has'
- `// been executed 2 times'
- `// OR when baz has been executed 1 time.'
-
-
-
-File: gdb.info, Node: Tracepoint Conditions, Next: Trace State Variables, Prev: Tracepoint Passcounts, Up: Set Tracepoints
-
-13.1.4 Tracepoint Conditions
-----------------------------
-
-The simplest sort of tracepoint collects data every time your program
-reaches a specified place. You can also specify a "condition" for a
-tracepoint. A condition is just a Boolean expression in your
-programming language (*note Expressions: Expressions.). A tracepoint
-with a condition evaluates the expression each time your program
-reaches it, and data collection happens only if the condition is true.
-
- Tracepoint conditions can be specified when a tracepoint is set, by
-using `if' in the arguments to the `trace' command. *Note Setting
-Tracepoints: Create and Delete Tracepoints. They can also be set or
-changed at any time with the `condition' command, just as with
-breakpoints.
-
- Unlike breakpoint conditions, GDB does not actually evaluate the
-conditional expression itself. Instead, GDB encodes the expression
-into an agent expression (*note Agent Expressions::) suitable for
-execution on the target, independently of GDB. Global variables become
-raw memory locations, locals become stack accesses, and so forth.
-
- For instance, suppose you have a function that is usually called
-frequently, but should not be called after an error has occurred. You
-could use the following tracepoint command to collect data about calls
-of that function that happen while the error code is propagating
-through the program; an unconditional tracepoint could end up
-collecting thousands of useless trace frames that you would have to
-search through.
-
- (gdb) trace normal_operation if errcode > 0
-
-
-File: gdb.info, Node: Trace State Variables, Next: Tracepoint Actions, Prev: Tracepoint Conditions, Up: Set Tracepoints
-
-13.1.5 Trace State Variables
-----------------------------
-
-A "trace state variable" is a special type of variable that is created
-and managed by target-side code. The syntax is the same as that for
-GDB's convenience variables (a string prefixed with "$"), but they are
-stored on the target. They must be created explicitly, using a
-`tvariable' command. They are always 64-bit signed integers.
-
- Trace state variables are remembered by GDB, and downloaded to the
-target along with tracepoint information when the trace experiment
-starts. There are no intrinsic limits on the number of trace state
-variables, beyond memory limitations of the target.
-
- Although trace state variables are managed by the target, you can use
-them in print commands and expressions as if they were convenience
-variables; GDB will get the current value from the target while the
-trace experiment is running. Trace state variables share the same
-namespace as other "$" variables, which means that you cannot have
-trace state variables with names like `$23' or `$pc', nor can you have
-a trace state variable and a convenience variable with the same name.
-
-`tvariable $NAME [ = EXPRESSION ]'
- The `tvariable' command creates a new trace state variable named
- `$NAME', and optionally gives it an initial value of EXPRESSION.
- EXPRESSION is evaluated when this command is entered; the result
- will be converted to an integer if possible, otherwise GDB will
- report an error. A subsequent `tvariable' command specifying the
- same name does not create a variable, but instead assigns the
- supplied initial value to the existing variable of that name,
- overwriting any previous initial value. The default initial value
- is 0.
-
-`info tvariables'
- List all the trace state variables along with their initial values.
- Their current values may also be displayed, if the trace
- experiment is currently running.
-
-`delete tvariable [ $NAME ... ]'
- Delete the given trace state variables, or all of them if no
- arguments are specified.
-
-
-
-File: gdb.info, Node: Tracepoint Actions, Next: Listing Tracepoints, Prev: Trace State Variables, Up: Set Tracepoints
-
-13.1.6 Tracepoint Action Lists
-------------------------------
-
-`actions [NUM]'
- This command will prompt for a list of actions to be taken when the
- tracepoint is hit. If the tracepoint number NUM is not specified,
- this command sets the actions for the one that was most recently
- defined (so that you can define a tracepoint and then say
- `actions' without bothering about its number). You specify the
- actions themselves on the following lines, one action at a time,
- and terminate the actions list with a line containing just `end'.
- So far, the only defined actions are `collect', `teval', and
- `while-stepping'.
-
- `actions' is actually equivalent to `commands' (*note Breakpoint
- Command Lists: Break Commands.), except that only the defined
- actions are allowed; any other GDB command is rejected.
-
- To remove all actions from a tracepoint, type `actions NUM' and
- follow it immediately with `end'.
-
- (gdb) collect DATA // collect some data
-
- (gdb) while-stepping 5 // single-step 5 times, collect data
-
- (gdb) end // signals the end of actions.
-
- In the following example, the action list begins with `collect'
- commands indicating the things to be collected when the tracepoint
- is hit. Then, in order to single-step and collect additional data
- following the tracepoint, a `while-stepping' command is used,
- followed by the list of things to be collected after each step in a
- sequence of single steps. The `while-stepping' command is
- terminated by its own separate `end' command. Lastly, the action
- list is terminated by an `end' command.
-
- (gdb) trace foo
- (gdb) actions
- Enter actions for tracepoint 1, one per line:
- > collect bar,baz
- > collect $regs
- > while-stepping 12
- > collect $pc, arr[i]
- > end
- end
-
-`collect EXPR1, EXPR2, ...'
- Collect values of the given expressions when the tracepoint is hit.
- This command accepts a comma-separated list of any valid
- expressions. In addition to global, static, or local variables,
- the following special arguments are supported:
-
- `$regs'
- Collect all registers.
-
- `$args'
- Collect all function arguments.
-
- `$locals'
- Collect all local variables.
-
- `$_sdata'
- Collect static tracepoint marker specific data. Only
- available for static tracepoints. *Note Tracepoint Action
- Lists: Tracepoint Actions. On the UST static tracepoints
- library backend, an instrumentation point resembles a
- `printf' function call. The tracing library is able to
- collect user specified data formatted to a character string
- using the format provided by the programmer that instrumented
- the program. Other backends have similar mechanisms. Here's
- an example of a UST marker call:
-
- const char master_name[] = "$your_name";
- trace_mark(channel1, marker1, "hello %s", master_name)
-
- In this case, collecting `$_sdata' collects the string `hello
- $yourname'. When analyzing the trace buffer, you can inspect
- `$_sdata' like any other variable available to GDB.
-
- You can give several consecutive `collect' commands, each one with
- a single argument, or one `collect' command with several arguments
- separated by commas; the effect is the same.
-
- The command `info scope' (*note info scope: Symbols.) is
- particularly useful for figuring out what data to collect.
-
-`teval EXPR1, EXPR2, ...'
- Evaluate the given expressions when the tracepoint is hit. This
- command accepts a comma-separated list of expressions. The results
- are discarded, so this is mainly useful for assigning values to
- trace state variables (*note Trace State Variables::) without
- adding those values to the trace buffer, as would be the case if
- the `collect' action were used.
-
-`while-stepping N'
- Perform N single-step instruction traces after the tracepoint,
- collecting new data after each step. The `while-stepping' command
- is followed by the list of what to collect while stepping
- (followed by its own `end' command):
-
- > while-stepping 12
- > collect $regs, myglobal
- > end
- >
-
- Note that `$pc' is not automatically collected by
- `while-stepping'; you need to explicitly collect that register if
- you need it. You may abbreviate `while-stepping' as `ws' or
- `stepping'.
-
-`set default-collect EXPR1, EXPR2, ...'
- This variable is a list of expressions to collect at each
- tracepoint hit. It is effectively an additional `collect' action
- prepended to every tracepoint action list. The expressions are
- parsed individually for each tracepoint, so for instance a
- variable named `xyz' may be interpreted as a global for one
- tracepoint, and a local for another, as appropriate to the
- tracepoint's location.
-
-`show default-collect'
- Show the list of expressions that are collected by default at each
- tracepoint hit.
-
-
-
-File: gdb.info, Node: Listing Tracepoints, Next: Listing Static Tracepoint Markers, Prev: Tracepoint Actions, Up: Set Tracepoints
-
-13.1.7 Listing Tracepoints
---------------------------
-
-`info tracepoints [NUM...]'
- Display information about the tracepoint NUM. If you don't
- specify a tracepoint number, displays information about all the
- tracepoints defined so far. The format is similar to that used for
- `info breakpoints'; in fact, `info tracepoints' is the same
- command, simply restricting itself to tracepoints.
-
- A tracepoint's listing may include additional information specific
- to tracing:
-
- * its passcount as given by the `passcount N' command
-
- (gdb) info trace
- Num Type Disp Enb Address What
- 1 tracepoint keep y 0x0804ab57 in foo() at main.cxx:7
- while-stepping 20
- collect globfoo, $regs
- end
- collect globfoo2
- end
- pass count 1200
- (gdb)
-
- This command can be abbreviated `info tp'.
-
-
-File: gdb.info, Node: Listing Static Tracepoint Markers, Next: Starting and Stopping Trace Experiments, Prev: Listing Tracepoints, Up: Set Tracepoints
-
-13.1.8 Listing Static Tracepoint Markers
-----------------------------------------
-
-`info static-tracepoint-markers'
- Display information about all static tracepoint markers defined in
- the program.
-
- For each marker, the following columns are printed:
-
- _Count_
- An incrementing counter, output to help readability. This is
- not a stable identifier.
-
- _ID_
- The marker ID, as reported by the target.
-
- _Enabled or Disabled_
- Probed markers are tagged with `y'. `n' identifies marks
- that are not enabled.
-
- _Address_
- Where the marker is in your program, as a memory address.
-
- _What_
- Where the marker is in the source for your program, as a file
- and line number. If the debug information included in the
- program does not allow GDB to locate the source of the
- marker, this column will be left blank.
-
- In addition, the following information may be printed for each
- marker:
-
- _Data_
- User data passed to the tracing library by the marker call.
- In the UST backend, this is the format string passed as
- argument to the marker call.
-
- _Static tracepoints probing the marker_
- The list of static tracepoints attached to the marker.
-
- (gdb) info static-tracepoint-markers
- Cnt ID Enb Address What
- 1 ust/bar2 y 0x0000000000400e1a in main at stexample.c:25
- Data: number1 %d number2 %d
- Probed by static tracepoints: #2
- 2 ust/bar33 n 0x0000000000400c87 in main at stexample.c:24
- Data: str %s
- (gdb)
-
-
-File: gdb.info, Node: Starting and Stopping Trace Experiments, Next: Tracepoint Restrictions, Prev: Listing Static Tracepoint Markers, Up: Set Tracepoints
-
-13.1.9 Starting and Stopping Trace Experiments
-----------------------------------------------
-
-`tstart'
- This command takes no arguments. It starts the trace experiment,
- and begins collecting data. This has the side effect of
- discarding all the data collected in the trace buffer during the
- previous trace experiment.
-
-`tstop'
- This command takes no arguments. It ends the trace experiment, and
- stops collecting data.
-
- *Note*: a trace experiment and data collection may stop
- automatically if any tracepoint's passcount is reached (*note
- Tracepoint Passcounts::), or if the trace buffer becomes full.
-
-`tstatus'
- This command displays the status of the current trace data
- collection.
-
- Here is an example of the commands we described so far:
-
- (gdb) trace gdb_c_test
- (gdb) actions
- Enter actions for tracepoint #1, one per line.
- > collect $regs,$locals,$args
- > while-stepping 11
- > collect $regs
- > end
- > end
- (gdb) tstart
- [time passes ...]
- (gdb) tstop
-
- You can choose to continue running the trace experiment even if GDB
-disconnects from the target, voluntarily or involuntarily. For
-commands such as `detach', the debugger will ask what you want to do
-with the trace. But for unexpected terminations (GDB crash, network
-outage), it would be unfortunate to lose hard-won trace data, so the
-variable `disconnected-tracing' lets you decide whether the trace should
-continue running without GDB.
-
-`set disconnected-tracing on'
-`set disconnected-tracing off'
- Choose whether a tracing run should continue to run if GDB has
- disconnected from the target. Note that `detach' or `quit' will
- ask you directly what to do about a running trace no matter what
- this variable's setting, so the variable is mainly useful for
- handling unexpected situations, such as loss of the network.
-
-`show disconnected-tracing'
- Show the current choice for disconnected tracing.
-
-
- When you reconnect to the target, the trace experiment may or may not
-still be running; it might have filled the trace buffer in the
-meantime, or stopped for one of the other reasons. If it is running,
-it will continue after reconnection.
-
- Upon reconnection, the target will upload information about the
-tracepoints in effect. GDB will then compare that information to the
-set of tracepoints currently defined, and attempt to match them up,
-allowing for the possibility that the numbers may have changed due to
-creation and deletion in the meantime. If one of the target's
-tracepoints does not match any in GDB, the debugger will create a new
-tracepoint, so that you have a number with which to specify that
-tracepoint. This matching-up process is necessarily heuristic, and it
-may result in useless tracepoints being created; you may simply delete
-them if they are of no use.
-
- If your target agent supports a "circular trace buffer", then you
-can run a trace experiment indefinitely without filling the trace
-buffer; when space runs out, the agent deletes already-collected trace
-frames, oldest first, until there is enough room to continue
-collecting. This is especially useful if your tracepoints are being
-hit too often, and your trace gets terminated prematurely because the
-buffer is full. To ask for a circular trace buffer, simply set
-`circular-trace-buffer' to on. You can set this at any time, including
-during tracing; if the agent can do it, it will change buffer handling
-on the fly, otherwise it will not take effect until the next run.
-
-`set circular-trace-buffer on'
-`set circular-trace-buffer off'
- Choose whether a tracing run should use a linear or circular buffer
- for trace data. A linear buffer will not lose any trace data, but
- may fill up prematurely, while a circular buffer will discard old
- trace data, but it will have always room for the latest tracepoint
- hits.
-
-`show circular-trace-buffer'
- Show the current choice for the trace buffer. Note that this may
- not match the agent's current buffer handling, nor is it
- guaranteed to match the setting that might have been in effect
- during a past run, for instance if you are looking at frames from
- a trace file.
-
-
-
-File: gdb.info, Node: Tracepoint Restrictions, Prev: Starting and Stopping Trace Experiments, Up: Set Tracepoints
-
-13.1.10 Tracepoint Restrictions
--------------------------------
-
-There are a number of restrictions on the use of tracepoints. As
-described above, tracepoint data gathering occurs on the target without
-interaction from GDB. Thus the full capabilities of the debugger are
-not available during data gathering, and then at data examination time,
-you will be limited by only having what was collected. The following
-items describe some common problems, but it is not exhaustive, and you
-may run into additional difficulties not mentioned here.
-
- * Tracepoint expressions are intended to gather objects (lvalues).
- Thus the full flexibility of GDB's expression evaluator is not
- available. You cannot call functions, cast objects to aggregate
- types, access convenience variables or modify values (except by
- assignment to trace state variables). Some language features may
- implicitly call functions (for instance Objective-C fields with
- accessors), and therefore cannot be collected either.
-
- * Collection of local variables, either individually or in bulk with
- `$locals' or `$args', during `while-stepping' may behave
- erratically. The stepping action may enter a new scope (for
- instance by stepping into a function), or the location of the
- variable may change (for instance it is loaded into a register).
- The tracepoint data recorded uses the location information for the
- variables that is correct for the tracepoint location. When the
- tracepoint is created, it is not possible, in general, to determine
- where the steps of a `while-stepping' sequence will advance the
- program--particularly if a conditional branch is stepped.
-
- * Collection of an incompletely-initialized or partially-destroyed
- object may result in something that GDB cannot display, or displays
- in a misleading way.
-
- * When GDB displays a pointer to character it automatically
- dereferences the pointer to also display characters of the string
- being pointed to. However, collecting the pointer during tracing
- does not automatically collect the string. You need to explicitly
- dereference the pointer and provide size information if you want to
- collect not only the pointer, but the memory pointed to. For
- example, `*ptr@50' can be used to collect the 50 element array
- pointed to by `ptr'.
-
- * It is not possible to collect a complete stack backtrace at a
- tracepoint. Instead, you may collect the registers and a few
- hundred bytes from the stack pointer with something like
- `*$esp@300' (adjust to use the name of the actual stack pointer
- register on your target architecture, and the amount of stack you
- wish to capture). Then the `backtrace' command will show a
- partial backtrace when using a trace frame. The number of stack
- frames that can be examined depends on the sizes of the frames in
- the collected stack. Note that if you ask for a block so large
- that it goes past the bottom of the stack, the target agent may
- report an error trying to read from an invalid address.
-
- * If you do not collect registers at a tracepoint, GDB can infer
- that the value of `$pc' must be the same as the address of the
- tracepoint and use that when you are looking at a trace frame for
- that tracepoint. However, this cannot work if the tracepoint has
- multiple locations (for instance if it was set in a function that
- was inlined), or if it has a `while-stepping' loop. In those cases
- GDB will warn you that it can't infer `$pc', and default it to
- zero.
-
-
-
-File: gdb.info, Node: Analyze Collected Data, Next: Tracepoint Variables, Prev: Set Tracepoints, Up: Tracepoints
-
-13.2 Using the Collected Data
-=============================
-
-After the tracepoint experiment ends, you use GDB commands for
-examining the trace data. The basic idea is that each tracepoint
-collects a trace "snapshot" every time it is hit and another snapshot
-every time it single-steps. All these snapshots are consecutively
-numbered from zero and go into a buffer, and you can examine them
-later. The way you examine them is to "focus" on a specific trace
-snapshot. When the remote stub is focused on a trace snapshot, it will
-respond to all GDB requests for memory and registers by reading from
-the buffer which belongs to that snapshot, rather than from _real_
-memory or registers of the program being debugged. This means that
-*all* GDB commands (`print', `info registers', `backtrace', etc.) will
-behave as if we were currently debugging the program state as it was
-when the tracepoint occurred. Any requests for data that are not in
-the buffer will fail.
-
-* Menu:
-
-* tfind:: How to select a trace snapshot
-* tdump:: How to display all data for a snapshot
-* save tracepoints:: How to save tracepoints for a future run
-
-
-File: gdb.info, Node: tfind, Next: tdump, Up: Analyze Collected Data
-
-13.2.1 `tfind N'
-----------------
-
-The basic command for selecting a trace snapshot from the buffer is
-`tfind N', which finds trace snapshot number N, counting from zero. If
-no argument N is given, the next snapshot is selected.
-
- Here are the various forms of using the `tfind' command.
-
-`tfind start'
- Find the first snapshot in the buffer. This is a synonym for
- `tfind 0' (since 0 is the number of the first snapshot).
-
-`tfind none'
- Stop debugging trace snapshots, resume _live_ debugging.
-
-`tfind end'
- Same as `tfind none'.
-
-`tfind'
- No argument means find the next trace snapshot.
-
-`tfind -'
- Find the previous trace snapshot before the current one. This
- permits retracing earlier steps.
-
-`tfind tracepoint NUM'
- Find the next snapshot associated with tracepoint NUM. Search
- proceeds forward from the last examined trace snapshot. If no
- argument NUM is given, it means find the next snapshot collected
- for the same tracepoint as the current snapshot.
-
-`tfind pc ADDR'
- Find the next snapshot associated with the value ADDR of the
- program counter. Search proceeds forward from the last examined
- trace snapshot. If no argument ADDR is given, it means find the
- next snapshot with the same value of PC as the current snapshot.
-
-`tfind outside ADDR1, ADDR2'
- Find the next snapshot whose PC is outside the given range of
- addresses (exclusive).
-
-`tfind range ADDR1, ADDR2'
- Find the next snapshot whose PC is between ADDR1 and ADDR2
- (inclusive).
-
-`tfind line [FILE:]N'
- Find the next snapshot associated with the source line N. If the
- optional argument FILE is given, refer to line N in that source
- file. Search proceeds forward from the last examined trace
- snapshot. If no argument N is given, it means find the next line
- other than the one currently being examined; thus saying `tfind
- line' repeatedly can appear to have the same effect as stepping
- from line to line in a _live_ debugging session.
-
- The default arguments for the `tfind' commands are specifically
-designed to make it easy to scan through the trace buffer. For
-instance, `tfind' with no argument selects the next trace snapshot, and
-`tfind -' with no argument selects the previous trace snapshot. So, by
-giving one `tfind' command, and then simply hitting <RET> repeatedly
-you can examine all the trace snapshots in order. Or, by saying `tfind
--' and then hitting <RET> repeatedly you can examine the snapshots in
-reverse order. The `tfind line' command with no argument selects the
-snapshot for the next source line executed. The `tfind pc' command with
-no argument selects the next snapshot with the same program counter
-(PC) as the current frame. The `tfind tracepoint' command with no
-argument selects the next trace snapshot collected by the same
-tracepoint as the current one.
-
- In addition to letting you scan through the trace buffer manually,
-these commands make it easy to construct GDB scripts that scan through
-the trace buffer and print out whatever collected data you are
-interested in. Thus, if we want to examine the PC, FP, and SP
-registers from each trace frame in the buffer, we can say this:
-
- (gdb) tfind start
- (gdb) while ($trace_frame != -1)
- > printf "Frame %d, PC = %08X, SP = %08X, FP = %08X\n", \
- $trace_frame, $pc, $sp, $fp
- > tfind
- > end
-
- Frame 0, PC = 0020DC64, SP = 0030BF3C, FP = 0030BF44
- Frame 1, PC = 0020DC6C, SP = 0030BF38, FP = 0030BF44
- Frame 2, PC = 0020DC70, SP = 0030BF34, FP = 0030BF44
- Frame 3, PC = 0020DC74, SP = 0030BF30, FP = 0030BF44
- Frame 4, PC = 0020DC78, SP = 0030BF2C, FP = 0030BF44
- Frame 5, PC = 0020DC7C, SP = 0030BF28, FP = 0030BF44
- Frame 6, PC = 0020DC80, SP = 0030BF24, FP = 0030BF44
- Frame 7, PC = 0020DC84, SP = 0030BF20, FP = 0030BF44
- Frame 8, PC = 0020DC88, SP = 0030BF1C, FP = 0030BF44
- Frame 9, PC = 0020DC8E, SP = 0030BF18, FP = 0030BF44
- Frame 10, PC = 00203F6C, SP = 0030BE3C, FP = 0030BF14
-
- Or, if we want to examine the variable `X' at each source line in
-the buffer:
-
- (gdb) tfind start
- (gdb) while ($trace_frame != -1)
- > printf "Frame %d, X == %d\n", $trace_frame, X
- > tfind line
- > end
-
- Frame 0, X = 1
- Frame 7, X = 2
- Frame 13, X = 255
-
-
-File: gdb.info, Node: tdump, Next: save tracepoints, Prev: tfind, Up: Analyze Collected Data
-
-13.2.2 `tdump'
---------------
-
-This command takes no arguments. It prints all the data collected at
-the current trace snapshot.
-
- (gdb) trace 444
- (gdb) actions
- Enter actions for tracepoint #2, one per line:
- > collect $regs, $locals, $args, gdb_long_test
- > end
-
- (gdb) tstart
-
- (gdb) tfind line 444
- #0 gdb_test (p1=0x11, p2=0x22, p3=0x33, p4=0x44, p5=0x55, p6=0x66)
- at gdb_test.c:444
- 444 printp( "%s: arguments = 0x%X 0x%X 0x%X 0x%X 0x%X 0x%X\n", )
-
- (gdb) tdump
- Data collected at tracepoint 2, trace frame 1:
- d0 0xc4aa0085 -995491707
- d1 0x18 24
- d2 0x80 128
- d3 0x33 51
- d4 0x71aea3d 119204413
- d5 0x22 34
- d6 0xe0 224
- d7 0x380035 3670069
- a0 0x19e24a 1696330
- a1 0x3000668 50333288
- a2 0x100 256
- a3 0x322000 3284992
- a4 0x3000698 50333336
- a5 0x1ad3cc 1758156
- fp 0x30bf3c 0x30bf3c
- sp 0x30bf34 0x30bf34
- ps 0x0 0
- pc 0x20b2c8 0x20b2c8
- fpcontrol 0x0 0
- fpstatus 0x0 0
- fpiaddr 0x0 0
- p = 0x20e5b4 "gdb-test"
- p1 = (void *) 0x11
- p2 = (void *) 0x22
- p3 = (void *) 0x33
- p4 = (void *) 0x44
- p5 = (void *) 0x55
- p6 = (void *) 0x66
- gdb_long_test = 17 '\021'
-
- (gdb)
-
- `tdump' works by scanning the tracepoint's current collection
-actions and printing the value of each expression listed. So `tdump'
-can fail, if after a run, you change the tracepoint's actions to
-mention variables that were not collected during the run.
-
- Also, for tracepoints with `while-stepping' loops, `tdump' uses the
-collected value of `$pc' to distinguish between trace frames that were
-collected at the tracepoint hit, and frames that were collected while
-stepping. This allows it to correctly choose whether to display the
-basic list of collections, or the collections from the body of the
-while-stepping loop. However, if `$pc' was not collected, then `tdump'
-will always attempt to dump using the basic collection list, and may
-fail if a while-stepping frame does not include all the same data that
-is collected at the tracepoint hit.
-
-
-File: gdb.info, Node: save tracepoints, Prev: tdump, Up: Analyze Collected Data
-
-13.2.3 `save tracepoints FILENAME'
-----------------------------------
-
-This command saves all current tracepoint definitions together with
-their actions and passcounts, into a file `FILENAME' suitable for use
-in a later debugging session. To read the saved tracepoint
-definitions, use the `source' command (*note Command Files::). The
-`save-tracepoints' command is a deprecated alias for `save tracepoints'
-
-
-File: gdb.info, Node: Tracepoint Variables, Next: Trace Files, Prev: Analyze Collected Data, Up: Tracepoints
-
-13.3 Convenience Variables for Tracepoints
-==========================================
-
-`(int) $trace_frame'
- The current trace snapshot (a.k.a. "frame") number, or -1 if no
- snapshot is selected.
-
-`(int) $tracepoint'
- The tracepoint for the current trace snapshot.
-
-`(int) $trace_line'
- The line number for the current trace snapshot.
-
-`(char []) $trace_file'
- The source file for the current trace snapshot.
-
-`(char []) $trace_func'
- The name of the function containing `$tracepoint'.
-
- Note: `$trace_file' is not suitable for use in `printf', use
-`output' instead.
-
- Here's a simple example of using these convenience variables for
-stepping through all the trace snapshots and printing some of their
-data. Note that these are not the same as trace state variables, which
-are managed by the target.
-
- (gdb) tfind start
-
- (gdb) while $trace_frame != -1
- > output $trace_file
- > printf ", line %d (tracepoint #%d)\n", $trace_line, $tracepoint
- > tfind
- > end
-
-
-File: gdb.info, Node: Trace Files, Prev: Tracepoint Variables, Up: Tracepoints
-
-13.4 Using Trace Files
-======================
-
-In some situations, the target running a trace experiment may no longer
-be available; perhaps it crashed, or the hardware was needed for a
-different activity. To handle these cases, you can arrange to dump the
-trace data into a file, and later use that file as a source of trace
-data, via the `target tfile' command.
-
-`tsave [ -r ] FILENAME'
- Save the trace data to FILENAME. By default, this command assumes
- that FILENAME refers to the host filesystem, so if necessary GDB
- will copy raw trace data up from the target and then save it. If
- the target supports it, you can also supply the optional argument
- `-r' ("remote") to direct the target to save the data directly
- into FILENAME in its own filesystem, which may be more efficient
- if the trace buffer is very large. (Note, however, that `target
- tfile' can only read from files accessible to the host.)
-
-`target tfile FILENAME'
- Use the file named FILENAME as a source of trace data. Commands
- that examine data work as they do with a live target, but it is not
- possible to run any new trace experiments. `tstatus' will report
- the state of the trace run at the moment the data was saved, as
- well as the current trace frame you are examining. FILENAME must
- be on a filesystem accessible to the host.
-
-
-
-File: gdb.info, Node: Overlays, Next: Languages, Prev: Tracepoints, Up: Top
-
-14 Debugging Programs That Use Overlays
-***************************************
-
-If your program is too large to fit completely in your target system's
-memory, you can sometimes use "overlays" to work around this problem.
-GDB provides some support for debugging programs that use overlays.
-
-* Menu:
-
-* How Overlays Work:: A general explanation of overlays.
-* Overlay Commands:: Managing overlays in GDB.
-* Automatic Overlay Debugging:: GDB can find out which overlays are
- mapped by asking the inferior.
-* Overlay Sample Program:: A sample program using overlays.
-
-
-File: gdb.info, Node: How Overlays Work, Next: Overlay Commands, Up: Overlays
-
-14.1 How Overlays Work
-======================
-
-Suppose you have a computer whose instruction address space is only 64
-kilobytes long, but which has much more memory which can be accessed by
-other means: special instructions, segment registers, or memory
-management hardware, for example. Suppose further that you want to
-adapt a program which is larger than 64 kilobytes to run on this system.
-
- One solution is to identify modules of your program which are
-relatively independent, and need not call each other directly; call
-these modules "overlays". Separate the overlays from the main program,
-and place their machine code in the larger memory. Place your main
-program in instruction memory, but leave at least enough space there to
-hold the largest overlay as well.
-
- Now, to call a function located in an overlay, you must first copy
-that overlay's machine code from the large memory into the space set
-aside for it in the instruction memory, and then jump to its entry point
-there.
-
- Data Instruction Larger
- Address Space Address Space Address Space
- +-----------+ +-----------+ +-----------+
- | | | | | |
- +-----------+ +-----------+ +-----------+<-- overlay 1
- | program | | main | .----| overlay 1 | load address
- | variables | | program | | +-----------+
- | and heap | | | | | |
- +-----------+ | | | +-----------+<-- overlay 2
- | | +-----------+ | | | load address
- +-----------+ | | | .-| overlay 2 |
- | | | | | |
- mapped --->+-----------+ | | +-----------+
- address | | | | | |
- | overlay | <-' | | |
- | area | <---' +-----------+<-- overlay 3
- | | <---. | | load address
- +-----------+ `--| overlay 3 |
- | | | |
- +-----------+ | |
- +-----------+
- | |
- +-----------+
-
- A code overlay
-
- The diagram (*note A code overlay::) shows a system with separate
-data and instruction address spaces. To map an overlay, the program
-copies its code from the larger address space to the instruction
-address space. Since the overlays shown here all use the same mapped
-address, only one may be mapped at a time. For a system with a single
-address space for data and instructions, the diagram would be similar,
-except that the program variables and heap would share an address space
-with the main program and the overlay area.
-
- An overlay loaded into instruction memory and ready for use is
-called a "mapped" overlay; its "mapped address" is its address in the
-instruction memory. An overlay not present (or only partially present)
-in instruction memory is called "unmapped"; its "load address" is its
-address in the larger memory. The mapped address is also called the
-"virtual memory address", or "VMA"; the load address is also called the
-"load memory address", or "LMA".
-
- Unfortunately, overlays are not a completely transparent way to
-adapt a program to limited instruction memory. They introduce a new
-set of global constraints you must keep in mind as you design your
-program:
-
- * Before calling or returning to a function in an overlay, your
- program must make sure that overlay is actually mapped.
- Otherwise, the call or return will transfer control to the right
- address, but in the wrong overlay, and your program will probably
- crash.
-
- * If the process of mapping an overlay is expensive on your system,
- you will need to choose your overlays carefully to minimize their
- effect on your program's performance.
-
- * The executable file you load onto your system must contain each
- overlay's instructions, appearing at the overlay's load address,
- not its mapped address. However, each overlay's instructions must
- be relocated and its symbols defined as if the overlay were at its
- mapped address. You can use GNU linker scripts to specify
- different load and relocation addresses for pieces of your
- program; see *note Overlay Description: (ld.info)Overlay
- Description.
-
- * The procedure for loading executable files onto your system must
- be able to load their contents into the larger address space as
- well as the instruction and data spaces.
-
-
- The overlay system described above is rather simple, and could be
-improved in many ways:
-
- * If your system has suitable bank switch registers or memory
- management hardware, you could use those facilities to make an
- overlay's load area contents simply appear at their mapped address
- in instruction space. This would probably be faster than copying
- the overlay to its mapped area in the usual way.
-
- * If your overlays are small enough, you could set aside more than
- one overlay area, and have more than one overlay mapped at a time.
-
- * You can use overlays to manage data, as well as instructions. In
- general, data overlays are even less transparent to your design
- than code overlays: whereas code overlays only require care when
- you call or return to functions, data overlays require care every
- time you access the data. Also, if you change the contents of a
- data overlay, you must copy its contents back out to its load
- address before you can copy a different data overlay into the same
- mapped area.
-
-
-
-File: gdb.info, Node: Overlay Commands, Next: Automatic Overlay Debugging, Prev: How Overlays Work, Up: Overlays
-
-14.2 Overlay Commands
-=====================
-
-To use GDB's overlay support, each overlay in your program must
-correspond to a separate section of the executable file. The section's
-virtual memory address and load memory address must be the overlay's
-mapped and load addresses. Identifying overlays with sections allows
-GDB to determine the appropriate address of a function or variable,
-depending on whether the overlay is mapped or not.
-
- GDB's overlay commands all start with the word `overlay'; you can
-abbreviate this as `ov' or `ovly'. The commands are:
-
-`overlay off'
- Disable GDB's overlay support. When overlay support is disabled,
- GDB assumes that all functions and variables are always present at
- their mapped addresses. By default, GDB's overlay support is
- disabled.
-
-`overlay manual'
- Enable "manual" overlay debugging. In this mode, GDB relies on
- you to tell it which overlays are mapped, and which are not, using
- the `overlay map-overlay' and `overlay unmap-overlay' commands
- described below.
-
-`overlay map-overlay OVERLAY'
-`overlay map OVERLAY'
- Tell GDB that OVERLAY is now mapped; OVERLAY must be the name of
- the object file section containing the overlay. When an overlay
- is mapped, GDB assumes it can find the overlay's functions and
- variables at their mapped addresses. GDB assumes that any other
- overlays whose mapped ranges overlap that of OVERLAY are now
- unmapped.
-
-`overlay unmap-overlay OVERLAY'
-`overlay unmap OVERLAY'
- Tell GDB that OVERLAY is no longer mapped; OVERLAY must be the
- name of the object file section containing the overlay. When an
- overlay is unmapped, GDB assumes it can find the overlay's
- functions and variables at their load addresses.
-
-`overlay auto'
- Enable "automatic" overlay debugging. In this mode, GDB consults
- a data structure the overlay manager maintains in the inferior to
- see which overlays are mapped. For details, see *note Automatic
- Overlay Debugging::.
-
-`overlay load-target'
-`overlay load'
- Re-read the overlay table from the inferior. Normally, GDB
- re-reads the table GDB automatically each time the inferior stops,
- so this command should only be necessary if you have changed the
- overlay mapping yourself using GDB. This command is only useful
- when using automatic overlay debugging.
-
-`overlay list-overlays'
-`overlay list'
- Display a list of the overlays currently mapped, along with their
- mapped addresses, load addresses, and sizes.
-
-
- Normally, when GDB prints a code address, it includes the name of
-the function the address falls in:
-
- (gdb) print main
- $3 = {int ()} 0x11a0 <main>
- When overlay debugging is enabled, GDB recognizes code in unmapped
-overlays, and prints the names of unmapped functions with asterisks
-around them. For example, if `foo' is a function in an unmapped
-overlay, GDB prints it this way:
-
- (gdb) overlay list
- No sections are mapped.
- (gdb) print foo
- $5 = {int (int)} 0x100000 <*foo*>
- When `foo''s overlay is mapped, GDB prints the function's name
-normally:
-
- (gdb) overlay list
- Section .ov.foo.text, loaded at 0x100000 - 0x100034,
- mapped at 0x1016 - 0x104a
- (gdb) print foo
- $6 = {int (int)} 0x1016 <foo>
-
- When overlay debugging is enabled, GDB can find the correct address
-for functions and variables in an overlay, whether or not the overlay
-is mapped. This allows most GDB commands, like `break' and
-`disassemble', to work normally, even on unmapped code. However, GDB's
-breakpoint support has some limitations:
-
- * You can set breakpoints in functions in unmapped overlays, as long
- as GDB can write to the overlay at its load address.
-
- * GDB can not set hardware or simulator-based breakpoints in
- unmapped overlays. However, if you set a breakpoint at the end of
- your overlay manager (and tell GDB which overlays are now mapped,
- if you are using manual overlay management), GDB will re-set its
- breakpoints properly.
-
-
-File: gdb.info, Node: Automatic Overlay Debugging, Next: Overlay Sample Program, Prev: Overlay Commands, Up: Overlays
-
-14.3 Automatic Overlay Debugging
-================================
-
-GDB can automatically track which overlays are mapped and which are
-not, given some simple co-operation from the overlay manager in the
-inferior. If you enable automatic overlay debugging with the `overlay
-auto' command (*note Overlay Commands::), GDB looks in the inferior's
-memory for certain variables describing the current state of the
-overlays.
-
- Here are the variables your overlay manager must define to support
-GDB's automatic overlay debugging:
-
-`_ovly_table':
- This variable must be an array of the following structures:
-
- struct
- {
- /* The overlay's mapped address. */
- unsigned long vma;
-
- /* The size of the overlay, in bytes. */
- unsigned long size;
-
- /* The overlay's load address. */
- unsigned long lma;
-
- /* Non-zero if the overlay is currently mapped;
- zero otherwise. */
- unsigned long mapped;
- }
-
-`_novlys':
- This variable must be a four-byte signed integer, holding the total
- number of elements in `_ovly_table'.
-
-
- To decide whether a particular overlay is mapped or not, GDB looks
-for an entry in `_ovly_table' whose `vma' and `lma' members equal the
-VMA and LMA of the overlay's section in the executable file. When GDB
-finds a matching entry, it consults the entry's `mapped' member to
-determine whether the overlay is currently mapped.
-
- In addition, your overlay manager may define a function called
-`_ovly_debug_event'. If this function is defined, GDB will silently
-set a breakpoint there. If the overlay manager then calls this
-function whenever it has changed the overlay table, this will enable
-GDB to accurately keep track of which overlays are in program memory,
-and update any breakpoints that may be set in overlays. This will
-allow breakpoints to work even if the overlays are kept in ROM or other
-non-writable memory while they are not being executed.
-
-
-File: gdb.info, Node: Overlay Sample Program, Prev: Automatic Overlay Debugging, Up: Overlays
-
-14.4 Overlay Sample Program
-===========================
-
-When linking a program which uses overlays, you must place the overlays
-at their load addresses, while relocating them to run at their mapped
-addresses. To do this, you must write a linker script (*note Overlay
-Description: (ld.info)Overlay Description.). Unfortunately, since
-linker scripts are specific to a particular host system, target
-architecture, and target memory layout, this manual cannot provide
-portable sample code demonstrating GDB's overlay support.
-
- However, the GDB source distribution does contain an overlaid
-program, with linker scripts for a few systems, as part of its test
-suite. The program consists of the following files from
-`gdb/testsuite/gdb.base':
-
-`overlays.c'
- The main program file.
-
-`ovlymgr.c'
- A simple overlay manager, used by `overlays.c'.
-
-`foo.c'
-`bar.c'
-`baz.c'
-`grbx.c'
- Overlay modules, loaded and used by `overlays.c'.
-
-`d10v.ld'
-`m32r.ld'
- Linker scripts for linking the test program on the `d10v-elf' and
- `m32r-elf' targets.
-
- You can build the test program using the `d10v-elf' GCC
-cross-compiler like this:
-
- $ d10v-elf-gcc -g -c overlays.c
- $ d10v-elf-gcc -g -c ovlymgr.c
- $ d10v-elf-gcc -g -c foo.c
- $ d10v-elf-gcc -g -c bar.c
- $ d10v-elf-gcc -g -c baz.c
- $ d10v-elf-gcc -g -c grbx.c
- $ d10v-elf-gcc -g overlays.o ovlymgr.o foo.o bar.o \
- baz.o grbx.o -Wl,-Td10v.ld -o overlays
-
- The build process is identical for any other architecture, except
-that you must substitute the appropriate compiler and linker script for
-the target system for `d10v-elf-gcc' and `d10v.ld'.
-
-
-File: gdb.info, Node: Languages, Next: Symbols, Prev: Overlays, Up: Top
-
-15 Using GDB with Different Languages
-*************************************
-
-Although programming languages generally have common aspects, they are
-rarely expressed in the same manner. For instance, in ANSI C,
-dereferencing a pointer `p' is accomplished by `*p', but in Modula-2,
-it is accomplished by `p^'. Values can also be represented (and
-displayed) differently. Hex numbers in C appear as `0x1ae', while in
-Modula-2 they appear as `1AEH'.
-
- Language-specific information is built into GDB for some languages,
-allowing you to express operations like the above in your program's
-native language, and allowing GDB to output values in a manner
-consistent with the syntax of your program's native language. The
-language you use to build expressions is called the "working language".
-
-* Menu:
-
-* Setting:: Switching between source languages
-* Show:: Displaying the language
-* Checks:: Type and range checks
-* Supported Languages:: Supported languages
-* Unsupported Languages:: Unsupported languages
-
-
-File: gdb.info, Node: Setting, Next: Show, Up: Languages
-
-15.1 Switching Between Source Languages
-=======================================
-
-There are two ways to control the working language--either have GDB set
-it automatically, or select it manually yourself. You can use the `set
-language' command for either purpose. On startup, GDB defaults to
-setting the language automatically. The working language is used to
-determine how expressions you type are interpreted, how values are
-printed, etc.
-
- In addition to the working language, every source file that GDB
-knows about has its own working language. For some object file
-formats, the compiler might indicate which language a particular source
-file is in. However, most of the time GDB infers the language from the
-name of the file. The language of a source file controls whether C++
-names are demangled--this way `backtrace' can show each frame
-appropriately for its own language. There is no way to set the
-language of a source file from within GDB, but you can set the language
-associated with a filename extension. *Note Displaying the Language:
-Show.
-
- This is most commonly a problem when you use a program, such as
-`cfront' or `f2c', that generates C but is written in another language.
-In that case, make the program use `#line' directives in its C output;
-that way GDB will know the correct language of the source code of the
-original program, and will display that source code, not the generated
-C code.
-
-* Menu:
-
-* Filenames:: Filename extensions and languages.
-* Manually:: Setting the working language manually
-* Automatically:: Having GDB infer the source language
-
-
-File: gdb.info, Node: Filenames, Next: Manually, Up: Setting
-
-15.1.1 List of Filename Extensions and Languages
-------------------------------------------------
-
-If a source file name ends in one of the following extensions, then GDB
-infers that its language is the one indicated.
-
-`.ada'
-`.ads'
-`.adb'
-`.a'
- Ada source file.
-
-`.c'
- C source file
-
-`.C'
-`.cc'
-`.cp'
-`.cpp'
-`.cxx'
-`.c++'
- C++ source file
-
-`.d'
- D source file
-
-`.m'
- Objective-C source file
-
-`.f'
-`.F'
- Fortran source file
-
-`.mod'
- Modula-2 source file
-
-`.s'
-`.S'
- Assembler source file. This actually behaves almost like C, but
- GDB does not skip over function prologues when stepping.
-
- In addition, you may set the language associated with a filename
-extension. *Note Displaying the Language: Show.
-
-
-File: gdb.info, Node: Manually, Next: Automatically, Prev: Filenames, Up: Setting
-
-15.1.2 Setting the Working Language
------------------------------------
-
-If you allow GDB to set the language automatically, expressions are
-interpreted the same way in your debugging session and your program.
-
- If you wish, you may set the language manually. To do this, issue
-the command `set language LANG', where LANG is the name of a language,
-such as `c' or `modula-2'. For a list of the supported languages, type
-`set language'.
-
- Setting the language manually prevents GDB from updating the working
-language automatically. This can lead to confusion if you try to debug
-a program when the working language is not the same as the source
-language, when an expression is acceptable to both languages--but means
-different things. For instance, if the current source file were
-written in C, and GDB was parsing Modula-2, a command such as:
-
- print a = b + c
-
-might not have the effect you intended. In C, this means to add `b'
-and `c' and place the result in `a'. The result printed would be the
-value of `a'. In Modula-2, this means to compare `a' to the result of
-`b+c', yielding a `BOOLEAN' value.
-
-
-File: gdb.info, Node: Automatically, Prev: Manually, Up: Setting
-
-15.1.3 Having GDB Infer the Source Language
--------------------------------------------
-
-To have GDB set the working language automatically, use `set language
-local' or `set language auto'. GDB then infers the working language.
-That is, when your program stops in a frame (usually by encountering a
-breakpoint), GDB sets the working language to the language recorded for
-the function in that frame. If the language for a frame is unknown
-(that is, if the function or block corresponding to the frame was
-defined in a source file that does not have a recognized extension),
-the current working language is not changed, and GDB issues a warning.
-
- This may not seem necessary for most programs, which are written
-entirely in one source language. However, program modules and libraries
-written in one source language can be used by a main program written in
-a different source language. Using `set language auto' in this case
-frees you from having to set the working language manually.
-
-
-File: gdb.info, Node: Show, Next: Checks, Prev: Setting, Up: Languages
-
-15.2 Displaying the Language
-============================
-
-The following commands help you find out which language is the working
-language, and also what language source files were written in.
-
-`show language'
- Display the current working language. This is the language you
- can use with commands such as `print' to build and compute
- expressions that may involve variables in your program.
-
-`info frame'
- Display the source language for this frame. This language becomes
- the working language if you use an identifier from this frame.
- *Note Information about a Frame: Frame Info, to identify the other
- information listed here.
-
-`info source'
- Display the source language of this source file. *Note Examining
- the Symbol Table: Symbols, to identify the other information
- listed here.
-
- In unusual circumstances, you may have source files with extensions
-not in the standard list. You can then set the extension associated
-with a language explicitly:
-
-`set extension-language EXT LANGUAGE'
- Tell GDB that source files with extension EXT are to be assumed as
- written in the source language LANGUAGE.
-
-`info extensions'
- List all the filename extensions and the associated languages.
-
-
-File: gdb.info, Node: Checks, Next: Supported Languages, Prev: Show, Up: Languages
-
-15.3 Type and Range Checking
-============================
-
- _Warning:_ In this release, the GDB commands for type and range
- checking are included, but they do not yet have any effect. This
- section documents the intended facilities.
-
- Some languages are designed to guard you against making seemingly
-common errors through a series of compile- and run-time checks. These
-include checking the type of arguments to functions and operators, and
-making sure mathematical overflows are caught at run time. Checks such
-as these help to ensure a program's correctness once it has been
-compiled by eliminating type mismatches, and providing active checks
-for range errors when your program is running.
-
- GDB can check for conditions like the above if you wish. Although
-GDB does not check the statements in your program, it can check
-expressions entered directly into GDB for evaluation via the `print'
-command, for example. As with the working language, GDB can also
-decide whether or not to check automatically based on your program's
-source language. *Note Supported Languages: Supported Languages, for
-the default settings of supported languages.
-
-* Menu:
-
-* Type Checking:: An overview of type checking
-* Range Checking:: An overview of range checking
-
-
-File: gdb.info, Node: Type Checking, Next: Range Checking, Up: Checks
-
-15.3.1 An Overview of Type Checking
------------------------------------
-
-Some languages, such as Modula-2, are strongly typed, meaning that the
-arguments to operators and functions have to be of the correct type,
-otherwise an error occurs. These checks prevent type mismatch errors
-from ever causing any run-time problems. For example,
-
- 1 + 2 => 3
-but
- error--> 1 + 2.3
-
- The second example fails because the `CARDINAL' 1 is not
-type-compatible with the `REAL' 2.3.
-
- For the expressions you use in GDB commands, you can tell the GDB
-type checker to skip checking; to treat any mismatches as errors and
-abandon the expression; or to only issue warnings when type mismatches
-occur, but evaluate the expression anyway. When you choose the last of
-these, GDB evaluates expressions like the second example above, but
-also issues a warning.
-
- Even if you turn type checking off, there may be other reasons
-related to type that prevent GDB from evaluating an expression. For
-instance, GDB does not know how to add an `int' and a `struct foo'.
-These particular type errors have nothing to do with the language in
-use, and usually arise from expressions, such as the one described
-above, which make little sense to evaluate anyway.
-
- Each language defines to what degree it is strict about type. For
-instance, both Modula-2 and C require the arguments to arithmetical
-operators to be numbers. In C, enumerated types and pointers can be
-represented as numbers, so that they are valid arguments to mathematical
-operators. *Note Supported Languages: Supported Languages, for further
-details on specific languages.
-
- GDB provides some additional commands for controlling the type
-checker:
-
-`set check type auto'
- Set type checking on or off based on the current working language.
- *Note Supported Languages: Supported Languages, for the default
- settings for each language.
-
-`set check type on'
-`set check type off'
- Set type checking on or off, overriding the default setting for the
- current working language. Issue a warning if the setting does not
- match the language default. If any type mismatches occur in
- evaluating an expression while type checking is on, GDB prints a
- message and aborts evaluation of the expression.
-
-`set check type warn'
- Cause the type checker to issue warnings, but to always attempt to
- evaluate the expression. Evaluating the expression may still be
- impossible for other reasons. For example, GDB cannot add numbers
- and structures.
-
-`show type'
- Show the current setting of the type checker, and whether or not
- GDB is setting it automatically.
-
-
-File: gdb.info, Node: Range Checking, Prev: Type Checking, Up: Checks
-
-15.3.2 An Overview of Range Checking
-------------------------------------
-
-In some languages (such as Modula-2), it is an error to exceed the
-bounds of a type; this is enforced with run-time checks. Such range
-checking is meant to ensure program correctness by making sure
-computations do not overflow, or indices on an array element access do
-not exceed the bounds of the array.
-
- For expressions you use in GDB commands, you can tell GDB to treat
-range errors in one of three ways: ignore them, always treat them as
-errors and abandon the expression, or issue warnings but evaluate the
-expression anyway.
-
- A range error can result from numerical overflow, from exceeding an
-array index bound, or when you type a constant that is not a member of
-any type. Some languages, however, do not treat overflows as an error.
-In many implementations of C, mathematical overflow causes the result
-to "wrap around" to lower values--for example, if M is the largest
-integer value, and S is the smallest, then
-
- M + 1 => S
-
- This, too, is specific to individual languages, and in some cases
-specific to individual compilers or machines. *Note Supported
-Languages: Supported Languages, for further details on specific
-languages.
-
- GDB provides some additional commands for controlling the range
-checker:
-
-`set check range auto'
- Set range checking on or off based on the current working language.
- *Note Supported Languages: Supported Languages, for the default
- settings for each language.
-
-`set check range on'
-`set check range off'
- Set range checking on or off, overriding the default setting for
- the current working language. A warning is issued if the setting
- does not match the language default. If a range error occurs and
- range checking is on, then a message is printed and evaluation of
- the expression is aborted.
-
-`set check range warn'
- Output messages when the GDB range checker detects a range error,
- but attempt to evaluate the expression anyway. Evaluating the
- expression may still be impossible for other reasons, such as
- accessing memory that the process does not own (a typical example
- from many Unix systems).
-
-`show range'
- Show the current setting of the range checker, and whether or not
- it is being set automatically by GDB.
-
-
-File: gdb.info, Node: Supported Languages, Next: Unsupported Languages, Prev: Checks, Up: Languages
-
-15.4 Supported Languages
-========================
-
-GDB supports C, C++, D, Objective-C, Fortran, Java, OpenCL C, Pascal,
-assembly, Modula-2, and Ada. Some GDB features may be used in
-expressions regardless of the language you use: the GDB `@' and `::'
-operators, and the `{type}addr' construct (*note Expressions:
-Expressions.) can be used with the constructs of any supported language.
-
- The following sections detail to what degree each source language is
-supported by GDB. These sections are not meant to be language
-tutorials or references, but serve only as a reference guide to what the
-GDB expression parser accepts, and what input and output formats should
-look like for different languages. There are many good books written
-on each of these languages; please look to these for a language
-reference or tutorial.
-
-* Menu:
-
-* C:: C and C++
-* D:: D
-* Objective-C:: Objective-C
-* OpenCL C:: OpenCL C
-* Fortran:: Fortran
-* Pascal:: Pascal
-* Modula-2:: Modula-2
-* Ada:: Ada
-
-
-File: gdb.info, Node: C, Next: D, Up: Supported Languages
-
-15.4.1 C and C++
-----------------
-
-Since C and C++ are so closely related, many features of GDB apply to
-both languages. Whenever this is the case, we discuss those languages
-together.
-
- The C++ debugging facilities are jointly implemented by the C++
-compiler and GDB. Therefore, to debug your C++ code effectively, you
-must compile your C++ programs with a supported C++ compiler, such as
-GNU `g++', or the HP ANSI C++ compiler (`aCC').
-
- For best results when using GNU C++, use the DWARF 2 debugging
-format; if it doesn't work on your system, try the stabs+ debugging
-format. You can select those formats explicitly with the `g++'
-command-line options `-gdwarf-2' and `-gstabs+'. *Note Options for
-Debugging Your Program or GCC: (gcc.info)Debugging Options.
-
-* Menu:
-
-* C Operators:: C and C++ operators
-* C Constants:: C and C++ constants
-* C Plus Plus Expressions:: C++ expressions
-* C Defaults:: Default settings for C and C++
-* C Checks:: C and C++ type and range checks
-* Debugging C:: GDB and C
-* Debugging C Plus Plus:: GDB features for C++
-* Decimal Floating Point:: Numbers in Decimal Floating Point format
-
-
-File: gdb.info, Node: C Operators, Next: C Constants, Up: C
-
-15.4.1.1 C and C++ Operators
-............................
-
-Operators must be defined on values of specific types. For instance,
-`+' is defined on numbers, but not on structures. Operators are often
-defined on groups of types.
-
- For the purposes of C and C++, the following definitions hold:
-
- * _Integral types_ include `int' with any of its storage-class
- specifiers; `char'; `enum'; and, for C++, `bool'.
-
- * _Floating-point types_ include `float', `double', and `long
- double' (if supported by the target platform).
-
- * _Pointer types_ include all types defined as `(TYPE *)'.
-
- * _Scalar types_ include all of the above.
-
-
-The following operators are supported. They are listed here in order
-of increasing precedence:
-
-`,'
- The comma or sequencing operator. Expressions in a
- comma-separated list are evaluated from left to right, with the
- result of the entire expression being the last expression
- evaluated.
-
-`='
- Assignment. The value of an assignment expression is the value
- assigned. Defined on scalar types.
-
-`OP='
- Used in an expression of the form `A OP= B', and translated to
- `A = A OP B'. `OP=' and `=' have the same precedence. OP is any
- one of the operators `|', `^', `&', `<<', `>>', `+', `-', `*',
- `/', `%'.
-
-`?:'
- The ternary operator. `A ? B : C' can be thought of as: if A
- then B else C. A should be of an integral type.
-
-`||'
- Logical OR. Defined on integral types.
-
-`&&'
- Logical AND. Defined on integral types.
-
-`|'
- Bitwise OR. Defined on integral types.
-
-`^'
- Bitwise exclusive-OR. Defined on integral types.
-
-`&'
- Bitwise AND. Defined on integral types.
-
-`==, !='
- Equality and inequality. Defined on scalar types. The value of
- these expressions is 0 for false and non-zero for true.
-
-`<, >, <=, >='
- Less than, greater than, less than or equal, greater than or equal.
- Defined on scalar types. The value of these expressions is 0 for
- false and non-zero for true.
-
-`<<, >>'
- left shift, and right shift. Defined on integral types.
-
-`@'
- The GDB "artificial array" operator (*note Expressions:
- Expressions.).
-
-`+, -'
- Addition and subtraction. Defined on integral types,
- floating-point types and pointer types.
-
-`*, /, %'
- Multiplication, division, and modulus. Multiplication and
- division are defined on integral and floating-point types.
- Modulus is defined on integral types.
-
-`++, --'
- Increment and decrement. When appearing before a variable, the
- operation is performed before the variable is used in an
- expression; when appearing after it, the variable's value is used
- before the operation takes place.
-
-`*'
- Pointer dereferencing. Defined on pointer types. Same precedence
- as `++'.
-
-`&'
- Address operator. Defined on variables. Same precedence as `++'.
-
- For debugging C++, GDB implements a use of `&' beyond what is
- allowed in the C++ language itself: you can use `&(&REF)' to
- examine the address where a C++ reference variable (declared with
- `&REF') is stored.
-
-`-'
- Negative. Defined on integral and floating-point types. Same
- precedence as `++'.
-
-`!'
- Logical negation. Defined on integral types. Same precedence as
- `++'.
-
-`~'
- Bitwise complement operator. Defined on integral types. Same
- precedence as `++'.
-
-`., ->'
- Structure member, and pointer-to-structure member. For
- convenience, GDB regards the two as equivalent, choosing whether
- to dereference a pointer based on the stored type information.
- Defined on `struct' and `union' data.
-
-`.*, ->*'
- Dereferences of pointers to members.
-
-`[]'
- Array indexing. `A[I]' is defined as `*(A+I)'. Same precedence
- as `->'.
-
-`()'
- Function parameter list. Same precedence as `->'.
-
-`::'
- C++ scope resolution operator. Defined on `struct', `union', and
- `class' types.
-
-`::'
- Doubled colons also represent the GDB scope operator (*note
- Expressions: Expressions.). Same precedence as `::', above.
-
- If an operator is redefined in the user code, GDB usually attempts
-to invoke the redefined version instead of using the operator's
-predefined meaning.
-
-
-File: gdb.info, Node: C Constants, Next: C Plus Plus Expressions, Prev: C Operators, Up: C
-
-15.4.1.2 C and C++ Constants
-............................
-
-GDB allows you to express the constants of C and C++ in the following
-ways:
-
- * Integer constants are a sequence of digits. Octal constants are
- specified by a leading `0' (i.e. zero), and hexadecimal constants
- by a leading `0x' or `0X'. Constants may also end with a letter
- `l', specifying that the constant should be treated as a `long'
- value.
-
- * Floating point constants are a sequence of digits, followed by a
- decimal point, followed by a sequence of digits, and optionally
- followed by an exponent. An exponent is of the form:
- `e[[+]|-]NNN', where NNN is another sequence of digits. The `+'
- is optional for positive exponents. A floating-point constant may
- also end with a letter `f' or `F', specifying that the constant
- should be treated as being of the `float' (as opposed to the
- default `double') type; or with a letter `l' or `L', which
- specifies a `long double' constant.
-
- * Enumerated constants consist of enumerated identifiers, or their
- integral equivalents.
-
- * Character constants are a single character surrounded by single
- quotes (`''), or a number--the ordinal value of the corresponding
- character (usually its ASCII value). Within quotes, the single
- character may be represented by a letter or by "escape sequences",
- which are of the form `\NNN', where NNN is the octal representation
- of the character's ordinal value; or of the form `\X', where `X'
- is a predefined special character--for example, `\n' for newline.
-
- * String constants are a sequence of character constants surrounded
- by double quotes (`"'). Any valid character constant (as described
- above) may appear. Double quotes within the string must be
- preceded by a backslash, so for instance `"a\"b'c"' is a string of
- five characters.
-
- * Pointer constants are an integral value. You can also write
- pointers to constants using the C operator `&'.
-
- * Array constants are comma-separated lists surrounded by braces `{'
- and `}'; for example, `{1,2,3}' is a three-element array of
- integers, `{{1,2}, {3,4}, {5,6}}' is a three-by-two array, and
- `{&"hi", &"there", &"fred"}' is a three-element array of pointers.
-
-
-File: gdb.info, Node: C Plus Plus Expressions, Next: C Defaults, Prev: C Constants, Up: C
-
-15.4.1.3 C++ Expressions
-........................
-
-GDB expression handling can interpret most C++ expressions.
-
- _Warning:_ GDB can only debug C++ code if you use the proper
- compiler and the proper debug format. Currently, GDB works best
- when debugging C++ code that is compiled with GCC 2.95.3 or with
- GCC 3.1 or newer, using the options `-gdwarf-2' or `-gstabs+'.
- DWARF 2 is preferred over stabs+. Most configurations of GCC emit
- either DWARF 2 or stabs+ as their default debug format, so you
- usually don't need to specify a debug format explicitly. Other
- compilers and/or debug formats are likely to work badly or not at
- all when using GDB to debug C++ code.
-
- 1. Member function calls are allowed; you can use expressions like
-
- count = aml->GetOriginal(x, y)
-
- 2. While a member function is active (in the selected stack frame),
- your expressions have the same namespace available as the member
- function; that is, GDB allows implicit references to the class
- instance pointer `this' following the same rules as C++.
-
- 3. You can call overloaded functions; GDB resolves the function call
- to the right definition, with some restrictions. GDB does not
- perform overload resolution involving user-defined type
- conversions, calls to constructors, or instantiations of templates
- that do not exist in the program. It also cannot handle ellipsis
- argument lists or default arguments.
-
- It does perform integral conversions and promotions, floating-point
- promotions, arithmetic conversions, pointer conversions,
- conversions of class objects to base classes, and standard
- conversions such as those of functions or arrays to pointers; it
- requires an exact match on the number of function arguments.
-
- Overload resolution is always performed, unless you have specified
- `set overload-resolution off'. *Note GDB Features for C++:
- Debugging C Plus Plus.
-
- You must specify `set overload-resolution off' in order to use an
- explicit function signature to call an overloaded function, as in
- p 'foo(char,int)'('x', 13)
-
- The GDB command-completion facility can simplify this; see *note
- Command Completion: Completion.
-
- 4. GDB understands variables declared as C++ references; you can use
- them in expressions just as you do in C++ source--they are
- automatically dereferenced.
-
- In the parameter list shown when GDB displays a frame, the values
- of reference variables are not displayed (unlike other variables);
- this avoids clutter, since references are often used for large
- structures. The _address_ of a reference variable is always
- shown, unless you have specified `set print address off'.
-
- 5. GDB supports the C++ name resolution operator `::'--your
- expressions can use it just as expressions in your program do.
- Since one scope may be defined in another, you can use `::'
- repeatedly if necessary, for example in an expression like
- `SCOPE1::SCOPE2::NAME'. GDB also allows resolving name scope by
- reference to source files, in both C and C++ debugging (*note
- Program Variables: Variables.).
-
- In addition, when used with HP's C++ compiler, GDB supports calling
-virtual functions correctly, printing out virtual bases of objects,
-calling functions in a base subobject, casting objects, and invoking
-user-defined operators.
-
-
-File: gdb.info, Node: C Defaults, Next: C Checks, Prev: C Plus Plus Expressions, Up: C
-
-15.4.1.4 C and C++ Defaults
-...........................
-
-If you allow GDB to set type and range checking automatically, they
-both default to `off' whenever the working language changes to C or
-C++. This happens regardless of whether you or GDB selects the working
-language.
-
- If you allow GDB to set the language automatically, it recognizes
-source files whose names end with `.c', `.C', or `.cc', etc, and when
-GDB enters code compiled from one of these files, it sets the working
-language to C or C++. *Note Having GDB Infer the Source Language:
-Automatically, for further details.
-
-
-File: gdb.info, Node: C Checks, Next: Debugging C, Prev: C Defaults, Up: C
-
-15.4.1.5 C and C++ Type and Range Checks
-........................................
-
-By default, when GDB parses C or C++ expressions, type checking is not
-used. However, if you turn type checking on, GDB considers two
-variables type equivalent if:
-
- * The two variables are structured and have the same structure,
- union, or enumerated tag.
-
- * The two variables have the same type name, or types that have been
- declared equivalent through `typedef'.
-
-
- Range checking, if turned on, is done on mathematical operations.
-Array indices are not checked, since they are often used to index a
-pointer that is not itself an array.
-
-
-File: gdb.info, Node: Debugging C, Next: Debugging C Plus Plus, Prev: C Checks, Up: C
-
-15.4.1.6 GDB and C
-..................
-
-The `set print union' and `show print union' commands apply to the
-`union' type. When set to `on', any `union' that is inside a `struct'
-or `class' is also printed. Otherwise, it appears as `{...}'.
-
- The `@' operator aids in the debugging of dynamic arrays, formed
-with pointers and a memory allocation function. *Note Expressions:
-Expressions.
-
-
-File: gdb.info, Node: Debugging C Plus Plus, Next: Decimal Floating Point, Prev: Debugging C, Up: C
-
-15.4.1.7 GDB Features for C++
-.............................
-
-Some GDB commands are particularly useful with C++, and some are
-designed specifically for use with C++. Here is a summary:
-
-`breakpoint menus'
- When you want a breakpoint in a function whose name is overloaded,
- GDB has the capability to display a menu of possible breakpoint
- locations to help you specify which function definition you want.
- *Note Ambiguous Expressions: Ambiguous Expressions.
-
-`rbreak REGEX'
- Setting breakpoints using regular expressions is helpful for
- setting breakpoints on overloaded functions that are not members
- of any special classes. *Note Setting Breakpoints: Set Breaks.
-
-`catch throw'
-`catch catch'
- Debug C++ exception handling using these commands. *Note Setting
- Catchpoints: Set Catchpoints.
-
-`ptype TYPENAME'
- Print inheritance relationships as well as other information for
- type TYPENAME. *Note Examining the Symbol Table: Symbols.
-
-`set print demangle'
-`show print demangle'
-`set print asm-demangle'
-`show print asm-demangle'
- Control whether C++ symbols display in their source form, both when
- displaying code as C++ source and when displaying disassemblies.
- *Note Print Settings: Print Settings.
-
-`set print object'
-`show print object'
- Choose whether to print derived (actual) or declared types of
- objects. *Note Print Settings: Print Settings.
-
-`set print vtbl'
-`show print vtbl'
- Control the format for printing virtual function tables. *Note
- Print Settings: Print Settings. (The `vtbl' commands do not work
- on programs compiled with the HP ANSI C++ compiler (`aCC').)
-
-`set overload-resolution on'
- Enable overload resolution for C++ expression evaluation. The
- default is on. For overloaded functions, GDB evaluates the
- arguments and searches for a function whose signature matches the
- argument types, using the standard C++ conversion rules (see *note
- C++ Expressions: C Plus Plus Expressions, for details). If it
- cannot find a match, it emits a message.
-
-`set overload-resolution off'
- Disable overload resolution for C++ expression evaluation. For
- overloaded functions that are not class member functions, GDB
- chooses the first function of the specified name that it finds in
- the symbol table, whether or not its arguments are of the correct
- type. For overloaded functions that are class member functions,
- GDB searches for a function whose signature _exactly_ matches the
- argument types.
-
-`show overload-resolution'
- Show the current setting of overload resolution.
-
-`Overloaded symbol names'
- You can specify a particular definition of an overloaded symbol,
- using the same notation that is used to declare such symbols in
- C++: type `SYMBOL(TYPES)' rather than just SYMBOL. You can also
- use the GDB command-line word completion facilities to list the
- available choices, or to finish the type list for you. *Note
- Command Completion: Completion, for details on how to do this.
-
-
-File: gdb.info, Node: Decimal Floating Point, Prev: Debugging C Plus Plus, Up: C
-
-15.4.1.8 Decimal Floating Point format
-......................................
-
-GDB can examine, set and perform computations with numbers in decimal
-floating point format, which in the C language correspond to the
-`_Decimal32', `_Decimal64' and `_Decimal128' types as specified by the
-extension to support decimal floating-point arithmetic.
-
- There are two encodings in use, depending on the architecture: BID
-(Binary Integer Decimal) for x86 and x86-64, and DPD (Densely Packed
-Decimal) for PowerPC. GDB will use the appropriate encoding for the
-configured target.
-
- Because of a limitation in `libdecnumber', the library used by GDB
-to manipulate decimal floating point numbers, it is not possible to
-convert (using a cast, for example) integers wider than 32-bit to
-decimal float.
-
- In addition, in order to imitate GDB's behaviour with binary floating
-point computations, error checking in decimal float operations ignores
-underflow, overflow and divide by zero exceptions.
-
- In the PowerPC architecture, GDB provides a set of pseudo-registers
-to inspect `_Decimal128' values stored in floating point registers.
-See *note PowerPC: PowerPC. for more details.
-
-
-File: gdb.info, Node: D, Next: Objective-C, Prev: C, Up: Supported Languages
-
-15.4.2 D
---------
-
-GDB can be used to debug programs written in D and compiled with GDC,
-LDC or DMD compilers. Currently GDB supports only one D specific
-feature -- dynamic arrays.
-
-
-File: gdb.info, Node: Objective-C, Next: OpenCL C, Prev: D, Up: Supported Languages
-
-15.4.3 Objective-C
-------------------
-
-This section provides information about some commands and command
-options that are useful for debugging Objective-C code. See also *note
-info classes: Symbols, and *note info selectors: Symbols, for a few
-more commands specific to Objective-C support.
-
-* Menu:
-
-* Method Names in Commands::
-* The Print Command with Objective-C::
-
-
-File: gdb.info, Node: Method Names in Commands, Next: The Print Command with Objective-C, Up: Objective-C
-
-15.4.3.1 Method Names in Commands
-.................................
-
-The following commands have been extended to accept Objective-C method
-names as line specifications:
-
- * `clear'
-
- * `break'
-
- * `info line'
-
- * `jump'
-
- * `list'
-
- A fully qualified Objective-C method name is specified as
-
- -[CLASS METHODNAME]
-
- where the minus sign is used to indicate an instance method and a
-plus sign (not shown) is used to indicate a class method. The class
-name CLASS and method name METHODNAME are enclosed in brackets, similar
-to the way messages are specified in Objective-C source code. For
-example, to set a breakpoint at the `create' instance method of class
-`Fruit' in the program currently being debugged, enter:
-
- break -[Fruit create]
-
- To list ten program lines around the `initialize' class method,
-enter:
-
- list +[NSText initialize]
-
- In the current version of GDB, the plus or minus sign is required.
-In future versions of GDB, the plus or minus sign will be optional, but
-you can use it to narrow the search. It is also possible to specify
-just a method name:
-
- break create
-
- You must specify the complete method name, including any colons. If
-your program's source files contain more than one `create' method,
-you'll be presented with a numbered list of classes that implement that
-method. Indicate your choice by number, or type `0' to exit if none
-apply.
-
- As another example, to clear a breakpoint established at the
-`makeKeyAndOrderFront:' method of the `NSWindow' class, enter:
-
- clear -[NSWindow makeKeyAndOrderFront:]
-
-
-File: gdb.info, Node: The Print Command with Objective-C, Prev: Method Names in Commands, Up: Objective-C
-
-15.4.3.2 The Print Command With Objective-C
-...........................................
-
-The print command has also been extended to accept methods. For
-example:
-
- print -[OBJECT hash]
-
-will tell GDB to send the `hash' message to OBJECT and print the
-result. Also, an additional command has been added, `print-object' or
-`po' for short, which is meant to print the description of an object.
-However, this command may only work with certain Objective-C libraries
-that have a particular hook function, `_NSPrintForDebugger', defined.
-
-
-File: gdb.info, Node: OpenCL C, Next: Fortran, Prev: Objective-C, Up: Supported Languages
-
-15.4.4 OpenCL C
----------------
-
-This section provides information about GDBs OpenCL C support.
-
-* Menu:
-
-* OpenCL C Datatypes::
-* OpenCL C Expressions::
-* OpenCL C Operators::
-
-
-File: gdb.info, Node: OpenCL C Datatypes, Next: OpenCL C Expressions, Up: OpenCL C
-
-15.4.4.1 OpenCL C Datatypes
-...........................
-
-GDB supports the builtin scalar and vector datatypes specified by
-OpenCL 1.1. In addition the half- and double-precision floating point
-data types of the `cl_khr_fp16' and `cl_khr_fp64' OpenCL extensions are
-also known to GDB.
-
-
-File: gdb.info, Node: OpenCL C Expressions, Next: OpenCL C Operators, Prev: OpenCL C Datatypes, Up: OpenCL C
-
-15.4.4.2 OpenCL C Expressions
-.............................
-
-GDB supports accesses to vector components including the access as
-lvalue where possible. Since OpenCL C is based on C99 most C
-expressions supported by GDB can be used as well.
-
-
-File: gdb.info, Node: OpenCL C Operators, Prev: OpenCL C Expressions, Up: OpenCL C
-
-15.4.4.3 OpenCL C Operators
-...........................
-
-GDB supports the operators specified by OpenCL 1.1 for scalar and
-vector data types.
-
-
-File: gdb.info, Node: Fortran, Next: Pascal, Prev: OpenCL C, Up: Supported Languages
-
-15.4.5 Fortran
---------------
-
-GDB can be used to debug programs written in Fortran, but it currently
-supports only the features of Fortran 77 language.
-
- Some Fortran compilers (GNU Fortran 77 and Fortran 95 compilers
-among them) append an underscore to the names of variables and
-functions. When you debug programs compiled by those compilers, you
-will need to refer to variables and functions with a trailing
-underscore.
-
-* Menu:
-
-* Fortran Operators:: Fortran operators and expressions
-* Fortran Defaults:: Default settings for Fortran
-* Special Fortran Commands:: Special GDB commands for Fortran
-
-
-File: gdb.info, Node: Fortran Operators, Next: Fortran Defaults, Up: Fortran
-
-15.4.5.1 Fortran Operators and Expressions
-..........................................
-
-Operators must be defined on values of specific types. For instance,
-`+' is defined on numbers, but not on characters or other non-
-arithmetic types. Operators are often defined on groups of types.
-
-`**'
- The exponentiation operator. It raises the first operand to the
- power of the second one.
-
-`:'
- The range operator. Normally used in the form of array(low:high)
- to represent a section of array.
-
-`%'
- The access component operator. Normally used to access elements
- in derived types. Also suitable for unions. As unions aren't
- part of regular Fortran, this can only happen when accessing a
- register that uses a gdbarch-defined union type.
-
-
-File: gdb.info, Node: Fortran Defaults, Next: Special Fortran Commands, Prev: Fortran Operators, Up: Fortran
-
-15.4.5.2 Fortran Defaults
-.........................
-
-Fortran symbols are usually case-insensitive, so GDB by default uses
-case-insensitive matches for Fortran symbols. You can change that with
-the `set case-insensitive' command, see *note Symbols::, for the
-details.
-
-
-File: gdb.info, Node: Special Fortran Commands, Prev: Fortran Defaults, Up: Fortran
-
-15.4.5.3 Special Fortran Commands
-.................................
-
-GDB has some commands to support Fortran-specific features, such as
-displaying common blocks.
-
-`info common [COMMON-NAME]'
- This command prints the values contained in the Fortran `COMMON'
- block whose name is COMMON-NAME. With no argument, the names of
- all `COMMON' blocks visible at the current program location are
- printed.
-
-
-File: gdb.info, Node: Pascal, Next: Modula-2, Prev: Fortran, Up: Supported Languages
-
-15.4.6 Pascal
--------------
-
-Debugging Pascal programs which use sets, subranges, file variables, or
-nested functions does not currently work. GDB does not support
-entering expressions, printing values, or similar features using Pascal
-syntax.
-
- The Pascal-specific command `set print pascal_static-members'
-controls whether static members of Pascal objects are displayed. *Note
-pascal_static-members: Print Settings.
-
-
-File: gdb.info, Node: Modula-2, Next: Ada, Prev: Pascal, Up: Supported Languages
-
-15.4.7 Modula-2
----------------
-
-The extensions made to GDB to support Modula-2 only support output from
-the GNU Modula-2 compiler (which is currently being developed). Other
-Modula-2 compilers are not currently supported, and attempting to debug
-executables produced by them is most likely to give an error as GDB
-reads in the executable's symbol table.
-
-* Menu:
-
-* M2 Operators:: Built-in operators
-* Built-In Func/Proc:: Built-in functions and procedures
-* M2 Constants:: Modula-2 constants
-* M2 Types:: Modula-2 types
-* M2 Defaults:: Default settings for Modula-2
-* Deviations:: Deviations from standard Modula-2
-* M2 Checks:: Modula-2 type and range checks
-* M2 Scope:: The scope operators `::' and `.'
-* GDB/M2:: GDB and Modula-2
-
-
-File: gdb.info, Node: M2 Operators, Next: Built-In Func/Proc, Up: Modula-2
-
-15.4.7.1 Operators
-..................
-
-Operators must be defined on values of specific types. For instance,
-`+' is defined on numbers, but not on structures. Operators are often
-defined on groups of types. For the purposes of Modula-2, the
-following definitions hold:
-
- * _Integral types_ consist of `INTEGER', `CARDINAL', and their
- subranges.
-
- * _Character types_ consist of `CHAR' and its subranges.
-
- * _Floating-point types_ consist of `REAL'.
-
- * _Pointer types_ consist of anything declared as `POINTER TO TYPE'.
-
- * _Scalar types_ consist of all of the above.
-
- * _Set types_ consist of `SET' and `BITSET' types.
-
- * _Boolean types_ consist of `BOOLEAN'.
-
-The following operators are supported, and appear in order of
-increasing precedence:
-
-`,'
- Function argument or array index separator.
-
-`:='
- Assignment. The value of VAR `:=' VALUE is VALUE.
-
-`<, >'
- Less than, greater than on integral, floating-point, or enumerated
- types.
-
-`<=, >='
- Less than or equal to, greater than or equal to on integral,
- floating-point and enumerated types, or set inclusion on set
- types. Same precedence as `<'.
-
-`=, <>, #'
- Equality and two ways of expressing inequality, valid on scalar
- types. Same precedence as `<'. In GDB scripts, only `<>' is
- available for inequality, since `#' conflicts with the script
- comment character.
-
-`IN'
- Set membership. Defined on set types and the types of their
- members. Same precedence as `<'.
-
-`OR'
- Boolean disjunction. Defined on boolean types.
-
-`AND, &'
- Boolean conjunction. Defined on boolean types.
-
-`@'
- The GDB "artificial array" operator (*note Expressions:
- Expressions.).
-
-`+, -'
- Addition and subtraction on integral and floating-point types, or
- union and difference on set types.
-
-`*'
- Multiplication on integral and floating-point types, or set
- intersection on set types.
-
-`/'
- Division on floating-point types, or symmetric set difference on
- set types. Same precedence as `*'.
-
-`DIV, MOD'
- Integer division and remainder. Defined on integral types. Same
- precedence as `*'.
-
-`-'
- Negative. Defined on `INTEGER' and `REAL' data.
-
-`^'
- Pointer dereferencing. Defined on pointer types.
-
-`NOT'
- Boolean negation. Defined on boolean types. Same precedence as
- `^'.
-
-`.'
- `RECORD' field selector. Defined on `RECORD' data. Same
- precedence as `^'.
-
-`[]'
- Array indexing. Defined on `ARRAY' data. Same precedence as `^'.
-
-`()'
- Procedure argument list. Defined on `PROCEDURE' objects. Same
- precedence as `^'.
-
-`::, .'
- GDB and Modula-2 scope operators.
-
- _Warning:_ Set expressions and their operations are not yet
- supported, so GDB treats the use of the operator `IN', or the use
- of operators `+', `-', `*', `/', `=', , `<>', `#', `<=', and `>='
- on sets as an error.
-
-
-File: gdb.info, Node: Built-In Func/Proc, Next: M2 Constants, Prev: M2 Operators, Up: Modula-2
-
-15.4.7.2 Built-in Functions and Procedures
-..........................................
-
-Modula-2 also makes available several built-in procedures and functions.
-In describing these, the following metavariables are used:
-
-A
- represents an `ARRAY' variable.
-
-C
- represents a `CHAR' constant or variable.
-
-I
- represents a variable or constant of integral type.
-
-M
- represents an identifier that belongs to a set. Generally used in
- the same function with the metavariable S. The type of S should
- be `SET OF MTYPE' (where MTYPE is the type of M).
-
-N
- represents a variable or constant of integral or floating-point
- type.
-
-R
- represents a variable or constant of floating-point type.
-
-T
- represents a type.
-
-V
- represents a variable.
-
-X
- represents a variable or constant of one of many types. See the
- explanation of the function for details.
-
- All Modula-2 built-in procedures also return a result, described
-below.
-
-`ABS(N)'
- Returns the absolute value of N.
-
-`CAP(C)'
- If C is a lower case letter, it returns its upper case equivalent,
- otherwise it returns its argument.
-
-`CHR(I)'
- Returns the character whose ordinal value is I.
-
-`DEC(V)'
- Decrements the value in the variable V by one. Returns the new
- value.
-
-`DEC(V,I)'
- Decrements the value in the variable V by I. Returns the new
- value.
-
-`EXCL(M,S)'
- Removes the element M from the set S. Returns the new set.
-
-`FLOAT(I)'
- Returns the floating point equivalent of the integer I.
-
-`HIGH(A)'
- Returns the index of the last member of A.
-
-`INC(V)'
- Increments the value in the variable V by one. Returns the new
- value.
-
-`INC(V,I)'
- Increments the value in the variable V by I. Returns the new
- value.
-
-`INCL(M,S)'
- Adds the element M to the set S if it is not already there.
- Returns the new set.
-
-`MAX(T)'
- Returns the maximum value of the type T.
-
-`MIN(T)'
- Returns the minimum value of the type T.
-
-`ODD(I)'
- Returns boolean TRUE if I is an odd number.
-
-`ORD(X)'
- Returns the ordinal value of its argument. For example, the
- ordinal value of a character is its ASCII value (on machines
- supporting the ASCII character set). X must be of an ordered
- type, which include integral, character and enumerated types.
-
-`SIZE(X)'
- Returns the size of its argument. X can be a variable or a type.
-
-`TRUNC(R)'
- Returns the integral part of R.
-
-`TSIZE(X)'
- Returns the size of its argument. X can be a variable or a type.
-
-`VAL(T,I)'
- Returns the member of the type T whose ordinal value is I.
-
- _Warning:_ Sets and their operations are not yet supported, so
- GDB treats the use of procedures `INCL' and `EXCL' as an error.
-
-
-File: gdb.info, Node: M2 Constants, Next: M2 Types, Prev: Built-In Func/Proc, Up: Modula-2
-
-15.4.7.3 Constants
-..................
-
-GDB allows you to express the constants of Modula-2 in the following
-ways:
-
- * Integer constants are simply a sequence of digits. When used in an
- expression, a constant is interpreted to be type-compatible with
- the rest of the expression. Hexadecimal integers are specified by
- a trailing `H', and octal integers by a trailing `B'.
-
- * Floating point constants appear as a sequence of digits, followed
- by a decimal point and another sequence of digits. An optional
- exponent can then be specified, in the form `E[+|-]NNN', where
- `[+|-]NNN' is the desired exponent. All of the digits of the
- floating point constant must be valid decimal (base 10) digits.
-
- * Character constants consist of a single character enclosed by a
- pair of like quotes, either single (`'') or double (`"'). They may
- also be expressed by their ordinal value (their ASCII value,
- usually) followed by a `C'.
-
- * String constants consist of a sequence of characters enclosed by a
- pair of like quotes, either single (`'') or double (`"'). Escape
- sequences in the style of C are also allowed. *Note C and C++
- Constants: C Constants, for a brief explanation of escape
- sequences.
-
- * Enumerated constants consist of an enumerated identifier.
-
- * Boolean constants consist of the identifiers `TRUE' and `FALSE'.
-
- * Pointer constants consist of integral values only.
-
- * Set constants are not yet supported.
-
-
-File: gdb.info, Node: M2 Types, Next: M2 Defaults, Prev: M2 Constants, Up: Modula-2
-
-15.4.7.4 Modula-2 Types
-.......................
-
-Currently GDB can print the following data types in Modula-2 syntax:
-array types, record types, set types, pointer types, procedure types,
-enumerated types, subrange types and base types. You can also print
-the contents of variables declared using these type. This section
-gives a number of simple source code examples together with sample GDB
-sessions.
-
- The first example contains the following section of code:
-
- VAR
- s: SET OF CHAR ;
- r: [20..40] ;
-
-and you can request GDB to interrogate the type and value of `r' and
-`s'.
-
- (gdb) print s
- {'A'..'C', 'Z'}
- (gdb) ptype s
- SET OF CHAR
- (gdb) print r
- 21
- (gdb) ptype r
- [20..40]
-
-Likewise if your source code declares `s' as:
-
- VAR
- s: SET ['A'..'Z'] ;
-
-then you may query the type of `s' by:
-
- (gdb) ptype s
- type = SET ['A'..'Z']
-
-Note that at present you cannot interactively manipulate set
-expressions using the debugger.
-
- The following example shows how you might declare an array in
-Modula-2 and how you can interact with GDB to print its type and
-contents:
-
- VAR
- s: ARRAY [-10..10] OF CHAR ;
-
- (gdb) ptype s
- ARRAY [-10..10] OF CHAR
-
- Note that the array handling is not yet complete and although the
-type is printed correctly, expression handling still assumes that all
-arrays have a lower bound of zero and not `-10' as in the example above.
-
- Here are some more type related Modula-2 examples:
-
- TYPE
- colour = (blue, red, yellow, green) ;
- t = [blue..yellow] ;
- VAR
- s: t ;
- BEGIN
- s := blue ;
-
-The GDB interaction shows how you can query the data type and value of
-a variable.
-
- (gdb) print s
- $1 = blue
- (gdb) ptype t
- type = [blue..yellow]
-
-In this example a Modula-2 array is declared and its contents
-displayed. Observe that the contents are written in the same way as
-their `C' counterparts.
-
- VAR
- s: ARRAY [1..5] OF CARDINAL ;
- BEGIN
- s[1] := 1 ;
-
- (gdb) print s
- $1 = {1, 0, 0, 0, 0}
- (gdb) ptype s
- type = ARRAY [1..5] OF CARDINAL
-
- The Modula-2 language interface to GDB also understands pointer
-types as shown in this example:
-
- VAR
- s: POINTER TO ARRAY [1..5] OF CARDINAL ;
- BEGIN
- NEW(s) ;
- s^[1] := 1 ;
-
-and you can request that GDB describes the type of `s'.
-
- (gdb) ptype s
- type = POINTER TO ARRAY [1..5] OF CARDINAL
-
- GDB handles compound types as we can see in this example. Here we
-combine array types, record types, pointer types and subrange types:
-
- TYPE
- foo = RECORD
- f1: CARDINAL ;
- f2: CHAR ;
- f3: myarray ;
- END ;
-
- myarray = ARRAY myrange OF CARDINAL ;
- myrange = [-2..2] ;
- VAR
- s: POINTER TO ARRAY myrange OF foo ;
-
-and you can ask GDB to describe the type of `s' as shown below.
-
- (gdb) ptype s
- type = POINTER TO ARRAY [-2..2] OF foo = RECORD
- f1 : CARDINAL;
- f2 : CHAR;
- f3 : ARRAY [-2..2] OF CARDINAL;
- END
-
-
-File: gdb.info, Node: M2 Defaults, Next: Deviations, Prev: M2 Types, Up: Modula-2
-
-15.4.7.5 Modula-2 Defaults
-..........................
-
-If type and range checking are set automatically by GDB, they both
-default to `on' whenever the working language changes to Modula-2.
-This happens regardless of whether you or GDB selected the working
-language.
-
- If you allow GDB to set the language automatically, then entering
-code compiled from a file whose name ends with `.mod' sets the working
-language to Modula-2. *Note Having GDB Infer the Source Language:
-Automatically, for further details.
-
-
-File: gdb.info, Node: Deviations, Next: M2 Checks, Prev: M2 Defaults, Up: Modula-2
-
-15.4.7.6 Deviations from Standard Modula-2
-..........................................
-
-A few changes have been made to make Modula-2 programs easier to debug.
-This is done primarily via loosening its type strictness:
-
- * Unlike in standard Modula-2, pointer constants can be formed by
- integers. This allows you to modify pointer variables during
- debugging. (In standard Modula-2, the actual address contained in
- a pointer variable is hidden from you; it can only be modified
- through direct assignment to another pointer variable or
- expression that returned a pointer.)
-
- * C escape sequences can be used in strings and characters to
- represent non-printable characters. GDB prints out strings with
- these escape sequences embedded. Single non-printable characters
- are printed using the `CHR(NNN)' format.
-
- * The assignment operator (`:=') returns the value of its right-hand
- argument.
-
- * All built-in procedures both modify _and_ return their argument.
-
-
-File: gdb.info, Node: M2 Checks, Next: M2 Scope, Prev: Deviations, Up: Modula-2
-
-15.4.7.7 Modula-2 Type and Range Checks
-.......................................
-
- _Warning:_ in this release, GDB does not yet perform type or range
- checking.
-
- GDB considers two Modula-2 variables type equivalent if:
-
- * They are of types that have been declared equivalent via a `TYPE
- T1 = T2' statement
-
- * They have been declared on the same line. (Note: This is true of
- the GNU Modula-2 compiler, but it may not be true of other
- compilers.)
-
- As long as type checking is enabled, any attempt to combine variables
-whose types are not equivalent is an error.
-
- Range checking is done on all mathematical operations, assignment,
-array index bounds, and all built-in functions and procedures.
-
-
-File: gdb.info, Node: M2 Scope, Next: GDB/M2, Prev: M2 Checks, Up: Modula-2
-
-15.4.7.8 The Scope Operators `::' and `.'
-.........................................
-
-There are a few subtle differences between the Modula-2 scope operator
-(`.') and the GDB scope operator (`::'). The two have similar syntax:
-
-
- MODULE . ID
- SCOPE :: ID
-
-where SCOPE is the name of a module or a procedure, MODULE the name of
-a module, and ID is any declared identifier within your program, except
-another module.
-
- Using the `::' operator makes GDB search the scope specified by
-SCOPE for the identifier ID. If it is not found in the specified
-scope, then GDB searches all scopes enclosing the one specified by
-SCOPE.
-
- Using the `.' operator makes GDB search the current scope for the
-identifier specified by ID that was imported from the definition module
-specified by MODULE. With this operator, it is an error if the
-identifier ID was not imported from definition module MODULE, or if ID
-is not an identifier in MODULE.
-
-
-File: gdb.info, Node: GDB/M2, Prev: M2 Scope, Up: Modula-2
-
-15.4.7.9 GDB and Modula-2
-.........................
-
-Some GDB commands have little use when debugging Modula-2 programs.
-Five subcommands of `set print' and `show print' apply specifically to
-C and C++: `vtbl', `demangle', `asm-demangle', `object', and `union'.
-The first four apply to C++, and the last to the C `union' type, which
-has no direct analogue in Modula-2.
-
- The `@' operator (*note Expressions: Expressions.), while available
-with any language, is not useful with Modula-2. Its intent is to aid
-the debugging of "dynamic arrays", which cannot be created in Modula-2
-as they can in C or C++. However, because an address can be specified
-by an integral constant, the construct `{TYPE}ADREXP' is still useful.
-
- In GDB scripts, the Modula-2 inequality operator `#' is interpreted
-as the beginning of a comment. Use `<>' instead.
-
-
-File: gdb.info, Node: Ada, Prev: Modula-2, Up: Supported Languages
-
-15.4.8 Ada
-----------
-
-The extensions made to GDB for Ada only support output from the GNU Ada
-(GNAT) compiler. Other Ada compilers are not currently supported, and
-attempting to debug executables produced by them is most likely to be
-difficult.
-
-* Menu:
-
-* Ada Mode Intro:: General remarks on the Ada syntax
- and semantics supported by Ada mode
- in GDB.
-* Omissions from Ada:: Restrictions on the Ada expression syntax.
-* Additions to Ada:: Extensions of the Ada expression syntax.
-* Stopping Before Main Program:: Debugging the program during elaboration.
-* Ada Tasks:: Listing and setting breakpoints in tasks.
-* Ada Tasks and Core Files:: Tasking Support when Debugging Core Files
-* Ravenscar Profile:: Tasking Support when using the Ravenscar
- Profile
-* Ada Glitches:: Known peculiarities of Ada mode.
-
-
-File: gdb.info, Node: Ada Mode Intro, Next: Omissions from Ada, Up: Ada
-
-15.4.8.1 Introduction
-.....................
-
-The Ada mode of GDB supports a fairly large subset of Ada expression
-syntax, with some extensions. The philosophy behind the design of this
-subset is
-
- * That GDB should provide basic literals and access to operations for
- arithmetic, dereferencing, field selection, indexing, and
- subprogram calls, leaving more sophisticated computations to
- subprograms written into the program (which therefore may be
- called from GDB).
-
- * That type safety and strict adherence to Ada language restrictions
- are not particularly important to the GDB user.
-
- * That brevity is important to the GDB user.
-
- Thus, for brevity, the debugger acts as if all names declared in
-user-written packages are directly visible, even if they are not visible
-according to Ada rules, thus making it unnecessary to fully qualify most
-names with their packages, regardless of context. Where this causes
-ambiguity, GDB asks the user's intent.
-
- The debugger will start in Ada mode if it detects an Ada main
-program. As for other languages, it will enter Ada mode when stopped
-in a program that was translated from an Ada source file.
-
- While in Ada mode, you may use `-' for comments. This is useful
-mostly for documenting command files. The standard GDB comment (`#')
-still works at the beginning of a line in Ada mode, but not in the
-middle (to allow based literals).
-
- The debugger supports limited overloading. Given a subprogram call
-in which the function symbol has multiple definitions, it will use the
-number of actual parameters and some information about their types to
-attempt to narrow the set of definitions. It also makes very limited
-use of context, preferring procedures to functions in the context of
-the `call' command, and functions to procedures elsewhere.
-
-
-File: gdb.info, Node: Omissions from Ada, Next: Additions to Ada, Prev: Ada Mode Intro, Up: Ada
-
-15.4.8.2 Omissions from Ada
-...........................
-
-Here are the notable omissions from the subset:
-
- * Only a subset of the attributes are supported:
-
- - 'First, 'Last, and 'Length on array objects (not on types
- and subtypes).
-
- - 'Min and 'Max.
-
- - 'Pos and 'Val.
-
- - 'Tag.
-
- - 'Range on array objects (not subtypes), but only as the right
- operand of the membership (`in') operator.
-
- - 'Access, 'Unchecked_Access, and 'Unrestricted_Access (a GNAT
- extension).
-
- - 'Address.
-
- * The names in `Characters.Latin_1' are not available and
- concatenation is not implemented. Thus, escape characters in
- strings are not currently available.
-
- * Equality tests (`=' and `/=') on arrays test for bitwise equality
- of representations. They will generally work correctly for
- strings and arrays whose elements have integer or enumeration
- types. They may not work correctly for arrays whose element types
- have user-defined equality, for arrays of real values (in
- particular, IEEE-conformant floating point, because of negative
- zeroes and NaNs), and for arrays whose elements contain unused
- bits with indeterminate values.
-
- * The other component-by-component array operations (`and', `or',
- `xor', `not', and relational tests other than equality) are not
- implemented.
-
- * There is limited support for array and record aggregates. They are
- permitted only on the right sides of assignments, as in these
- examples:
-
- (gdb) set An_Array := (1, 2, 3, 4, 5, 6)
- (gdb) set An_Array := (1, others => 0)
- (gdb) set An_Array := (0|4 => 1, 1..3 => 2, 5 => 6)
- (gdb) set A_2D_Array := ((1, 2, 3), (4, 5, 6), (7, 8, 9))
- (gdb) set A_Record := (1, "Peter", True);
- (gdb) set A_Record := (Name => "Peter", Id => 1, Alive => True)
-
- Changing a discriminant's value by assigning an aggregate has an
- undefined effect if that discriminant is used within the record.
- However, you can first modify discriminants by directly assigning
- to them (which normally would not be allowed in Ada), and then
- performing an aggregate assignment. For example, given a variable
- `A_Rec' declared to have a type such as:
-
- type Rec (Len : Small_Integer := 0) is record
- Id : Integer;
- Vals : IntArray (1 .. Len);
- end record;
-
- you can assign a value with a different size of `Vals' with two
- assignments:
-
- (gdb) set A_Rec.Len := 4
- (gdb) set A_Rec := (Id => 42, Vals => (1, 2, 3, 4))
-
- As this example also illustrates, GDB is very loose about the usual
- rules concerning aggregates. You may leave out some of the
- components of an array or record aggregate (such as the `Len'
- component in the assignment to `A_Rec' above); they will retain
- their original values upon assignment. You may freely use dynamic
- values as indices in component associations. You may even use
- overlapping or redundant component associations, although which
- component values are assigned in such cases is not defined.
-
- * Calls to dispatching subprograms are not implemented.
-
- * The overloading algorithm is much more limited (i.e., less
- selective) than that of real Ada. It makes only limited use of
- the context in which a subexpression appears to resolve its
- meaning, and it is much looser in its rules for allowing type
- matches. As a result, some function calls will be ambiguous, and
- the user will be asked to choose the proper resolution.
-
- * The `new' operator is not implemented.
-
- * Entry calls are not implemented.
-
- * Aside from printing, arithmetic operations on the native VAX
- floating-point formats are not supported.
-
- * It is not possible to slice a packed array.
-
- * The names `True' and `False', when not part of a qualified name,
- are interpreted as if implicitly prefixed by `Standard',
- regardless of context. Should your program redefine these names
- in a package or procedure (at best a dubious practice), you will
- have to use fully qualified names to access their new definitions.
-
-
-File: gdb.info, Node: Additions to Ada, Next: Stopping Before Main Program, Prev: Omissions from Ada, Up: Ada
-
-15.4.8.3 Additions to Ada
-.........................
-
-As it does for other languages, GDB makes certain generic extensions to
-Ada (*note Expressions::):
-
- * If the expression E is a variable residing in memory (typically a
- local variable or array element) and N is a positive integer, then
- `E@N' displays the values of E and the N-1 adjacent variables
- following it in memory as an array. In Ada, this operator is
- generally not necessary, since its prime use is in displaying
- parts of an array, and slicing will usually do this in Ada.
- However, there are occasional uses when debugging programs in
- which certain debugging information has been optimized away.
-
- * `B::VAR' means "the variable named VAR that appears in function or
- file B." When B is a file name, you must typically surround it in
- single quotes.
-
- * The expression `{TYPE} ADDR' means "the variable of type TYPE that
- appears at address ADDR."
-
- * A name starting with `$' is a convenience variable (*note
- Convenience Vars::) or a machine register (*note Registers::).
-
- In addition, GDB provides a few other shortcuts and outright
-additions specific to Ada:
-
- * The assignment statement is allowed as an expression, returning
- its right-hand operand as its value. Thus, you may enter
-
- (gdb) set x := y + 3
- (gdb) print A(tmp := y + 1)
-
- * The semicolon is allowed as an "operator," returning as its value
- the value of its right-hand operand. This allows, for example,
- complex conditional breaks:
-
- (gdb) break f
- (gdb) condition 1 (report(i); k += 1; A(k) > 100)
-
- * Rather than use catenation and symbolic character names to
- introduce special characters into strings, one may instead use a
- special bracket notation, which is also used to print strings. A
- sequence of characters of the form `["XX"]' within a string or
- character literal denotes the (single) character whose numeric
- encoding is XX in hexadecimal. The sequence of characters `["""]'
- also denotes a single quotation mark in strings. For example,
- "One line.["0a"]Next line.["0a"]"
- contains an ASCII newline character (`Ada.Characters.Latin_1.LF')
- after each period.
-
- * The subtype used as a prefix for the attributes 'Pos, 'Min, and
- 'Max is optional (and is ignored in any case). For example, it is
- valid to write
-
- (gdb) print 'max(x, y)
-
- * When printing arrays, GDB uses positional notation when the array
- has a lower bound of 1, and uses a modified named notation
- otherwise. For example, a one-dimensional array of three integers
- with a lower bound of 3 might print as
-
- (3 => 10, 17, 1)
-
- That is, in contrast to valid Ada, only the first component has a
- `=>' clause.
-
- * You may abbreviate attributes in expressions with any unique,
- multi-character subsequence of their names (an exact match gets
- preference). For example, you may use a'len, a'gth, or a'lh in
- place of a'length.
-
- * Since Ada is case-insensitive, the debugger normally maps
- identifiers you type to lower case. The GNAT compiler uses
- upper-case characters for some of its internal identifiers, which
- are normally of no interest to users. For the rare occasions when
- you actually have to look at them, enclose them in angle brackets
- to avoid the lower-case mapping. For example,
- (gdb) print <JMPBUF_SAVE>[0]
-
- * Printing an object of class-wide type or dereferencing an
- access-to-class-wide value will display all the components of the
- object's specific type (as indicated by its run-time tag).
- Likewise, component selection on such a value will operate on the
- specific type of the object.
-
-
-
-File: gdb.info, Node: Stopping Before Main Program, Next: Ada Tasks, Prev: Additions to Ada, Up: Ada
-
-15.4.8.4 Stopping at the Very Beginning
-.......................................
-
-It is sometimes necessary to debug the program during elaboration, and
-before reaching the main procedure. As defined in the Ada Reference
-Manual, the elaboration code is invoked from a procedure called
-`adainit'. To run your program up to the beginning of elaboration,
-simply use the following two commands: `tbreak adainit' and `run'.
-
-
-File: gdb.info, Node: Ada Tasks, Next: Ada Tasks and Core Files, Prev: Stopping Before Main Program, Up: Ada
-
-15.4.8.5 Extensions for Ada Tasks
-.................................
-
-Support for Ada tasks is analogous to that for threads (*note
-Threads::). GDB provides the following task-related commands:
-
-`info tasks'
- This command shows a list of current Ada tasks, as in the
- following example:
-
- (gdb) info tasks
- ID TID P-ID Pri State Name
- 1 8088000 0 15 Child Activation Wait main_task
- 2 80a4000 1 15 Accept Statement b
- 3 809a800 1 15 Child Activation Wait a
- * 4 80ae800 3 15 Runnable c
-
- In this listing, the asterisk before the last task indicates it to
- be the task currently being inspected.
-
- ID
- Represents GDB's internal task number.
-
- TID
- The Ada task ID.
-
- P-ID
- The parent's task ID (GDB's internal task number).
-
- Pri
- The base priority of the task.
-
- State
- Current state of the task.
-
- `Unactivated'
- The task has been created but has not been activated.
- It cannot be executing.
-
- `Runnable'
- The task is not blocked for any reason known to Ada.
- (It may be waiting for a mutex, though.) It is
- conceptually "executing" in normal mode.
-
- `Terminated'
- The task is terminated, in the sense of ARM 9.3 (5).
- Any dependents that were waiting on terminate
- alternatives have been awakened and have terminated
- themselves.
-
- `Child Activation Wait'
- The task is waiting for created tasks to complete
- activation.
-
- `Accept Statement'
- The task is waiting on an accept or selective wait
- statement.
-
- `Waiting on entry call'
- The task is waiting on an entry call.
-
- `Async Select Wait'
- The task is waiting to start the abortable part of an
- asynchronous select statement.
-
- `Delay Sleep'
- The task is waiting on a select statement with only a
- delay alternative open.
-
- `Child Termination Wait'
- The task is sleeping having completed a master within
- itself, and is waiting for the tasks dependent on that
- master to become terminated or waiting on a terminate
- Phase.
-
- `Wait Child in Term Alt'
- The task is sleeping waiting for tasks on terminate
- alternatives to finish terminating.
-
- `Accepting RV with TASKNO'
- The task is accepting a rendez-vous with the task TASKNO.
-
- Name
- Name of the task in the program.
-
-
-`info task TASKNO'
- This command shows detailled informations on the specified task,
- as in the following example:
- (gdb) info tasks
- ID TID P-ID Pri State Name
- 1 8077880 0 15 Child Activation Wait main_task
- * 2 807c468 1 15 Runnable task_1
- (gdb) info task 2
- Ada Task: 0x807c468
- Name: task_1
- Thread: 0x807f378
- Parent: 1 (main_task)
- Base Priority: 15
- State: Runnable
-
-`task'
- This command prints the ID of the current task.
-
- (gdb) info tasks
- ID TID P-ID Pri State Name
- 1 8077870 0 15 Child Activation Wait main_task
- * 2 807c458 1 15 Runnable t
- (gdb) task
- [Current task is 2]
-
-`task TASKNO'
- This command is like the `thread THREADNO' command (*note
- Threads::). It switches the context of debugging from the current
- task to the given task.
-
- (gdb) info tasks
- ID TID P-ID Pri State Name
- 1 8077870 0 15 Child Activation Wait main_task
- * 2 807c458 1 15 Runnable t
- (gdb) task 1
- [Switching to task 1]
- #0 0x8067726 in pthread_cond_wait ()
- (gdb) bt
- #0 0x8067726 in pthread_cond_wait ()
- #1 0x8056714 in system.os_interface.pthread_cond_wait ()
- #2 0x805cb63 in system.task_primitives.operations.sleep ()
- #3 0x806153e in system.tasking.stages.activate_tasks ()
- #4 0x804aacc in un () at un.adb:5
-
-`break LINESPEC task TASKNO'
-`break LINESPEC task TASKNO if ...'
- These commands are like the `break ... thread ...' command (*note
- Thread Stops::). LINESPEC specifies source lines, as described in
- *note Specify Location::.
-
- Use the qualifier `task TASKNO' with a breakpoint command to
- specify that you only want GDB to stop the program when a
- particular Ada task reaches this breakpoint. TASKNO is one of the
- numeric task identifiers assigned by GDB, shown in the first
- column of the `info tasks' display.
-
- If you do not specify `task TASKNO' when you set a breakpoint, the
- breakpoint applies to _all_ tasks of your program.
-
- You can use the `task' qualifier on conditional breakpoints as
- well; in this case, place `task TASKNO' before the breakpoint
- condition (before the `if').
-
- For example,
-
- (gdb) info tasks
- ID TID P-ID Pri State Name
- 1 140022020 0 15 Child Activation Wait main_task
- 2 140045060 1 15 Accept/Select Wait t2
- 3 140044840 1 15 Runnable t1
- * 4 140056040 1 15 Runnable t3
- (gdb) b 15 task 2
- Breakpoint 5 at 0x120044cb0: file test_task_debug.adb, line 15.
- (gdb) cont
- Continuing.
- task # 1 running
- task # 2 running
-
- Breakpoint 5, test_task_debug () at test_task_debug.adb:15
- 15 flush;
- (gdb) info tasks
- ID TID P-ID Pri State Name
- 1 140022020 0 15 Child Activation Wait main_task
- * 2 140045060 1 15 Runnable t2
- 3 140044840 1 15 Runnable t1
- 4 140056040 1 15 Delay Sleep t3
-
-
-File: gdb.info, Node: Ada Tasks and Core Files, Next: Ravenscar Profile, Prev: Ada Tasks, Up: Ada
-
-15.4.8.6 Tasking Support when Debugging Core Files
-..................................................
-
-When inspecting a core file, as opposed to debugging a live program,
-tasking support may be limited or even unavailable, depending on the
-platform being used. For instance, on x86-linux, the list of tasks is
-available, but task switching is not supported. On Tru64, however,
-task switching will work as usual.
-
- On certain platforms, including Tru64, the debugger needs to perform
-some memory writes in order to provide Ada tasking support. When
-inspecting a core file, this means that the core file must be opened
-with read-write privileges, using the command `"set write on"' (*note
-Patching::). Under these circumstances, you should make a backup copy
-of the core file before inspecting it with GDB.
-
-
-File: gdb.info, Node: Ravenscar Profile, Next: Ada Glitches, Prev: Ada Tasks and Core Files, Up: Ada
-
-15.4.8.7 Tasking Support when using the Ravenscar Profile
-.........................................................
-
-The "Ravenscar Profile" is a subset of the Ada tasking features,
-specifically designed for systems with safety-critical real-time
-requirements.
-
-`set ravenscar task-switching on'
- Allows task switching when debugging a program that uses the
- Ravenscar Profile. This is the default.
-
-`set ravenscar task-switching off'
- Turn off task switching when debugging a program that uses the
- Ravenscar Profile. This is mostly intended to disable the code
- that adds support for the Ravenscar Profile, in case a bug in
- either GDB or in the Ravenscar runtime is preventing GDB from
- working properly. To be effective, this command should be run
- before the program is started.
-
-`show ravenscar task-switching'
- Show whether it is possible to switch from task to task in a
- program using the Ravenscar Profile.
-
-
-
-File: gdb.info, Node: Ada Glitches, Prev: Ravenscar Profile, Up: Ada
-
-15.4.8.8 Known Peculiarities of Ada Mode
-........................................
-
-Besides the omissions listed previously (*note Omissions from Ada::),
-we know of several problems with and limitations of Ada mode in GDB,
-some of which will be fixed with planned future releases of the debugger
-and the GNU Ada compiler.
-
- * Static constants that the compiler chooses not to materialize as
- objects in storage are invisible to the debugger.
-
- * Named parameter associations in function argument lists are
- ignored (the argument lists are treated as positional).
-
- * Many useful library packages are currently invisible to the
- debugger.
-
- * Fixed-point arithmetic, conversions, input, and output is carried
- out using floating-point arithmetic, and may give results that
- only approximate those on the host machine.
-
- * The GNAT compiler never generates the prefix `Standard' for any of
- the standard symbols defined by the Ada language. GDB knows about
- this: it will strip the prefix from names when you use it, and
- will never look for a name you have so qualified among local
- symbols, nor match against symbols in other packages or
- subprograms. If you have defined entities anywhere in your
- program other than parameters and local variables whose simple
- names match names in `Standard', GNAT's lack of qualification here
- can cause confusion. When this happens, you can usually resolve
- the confusion by qualifying the problematic names with package
- `Standard' explicitly.
-
- Older versions of the compiler sometimes generate erroneous debugging
-information, resulting in the debugger incorrectly printing the value
-of affected entities. In some cases, the debugger is able to work
-around an issue automatically. In other cases, the debugger is able to
-work around the issue, but the work-around has to be specifically
-enabled.
-
-`set ada trust-PAD-over-XVS on'
- Configure GDB to strictly follow the GNAT encoding when computing
- the value of Ada entities, particularly when `PAD' and `PAD___XVS'
- types are involved (see `ada/exp_dbug.ads' in the GCC sources for
- a complete description of the encoding used by the GNAT compiler).
- This is the default.
-
-`set ada trust-PAD-over-XVS off'
- This is related to the encoding using by the GNAT compiler. If
- GDB sometimes prints the wrong value for certain entities,
- changing `ada trust-PAD-over-XVS' to `off' activates a work-around
- which may fix the issue. It is always safe to set `ada
- trust-PAD-over-XVS' to `off', but this incurs a slight performance
- penalty, so it is recommended to leave this setting to `on' unless
- necessary.
-
-
-
-File: gdb.info, Node: Unsupported Languages, Prev: Supported Languages, Up: Languages
-
-15.5 Unsupported Languages
-==========================
-
-In addition to the other fully-supported programming languages, GDB
-also provides a pseudo-language, called `minimal'. It does not
-represent a real programming language, but provides a set of
-capabilities close to what the C or assembly languages provide. This
-should allow most simple operations to be performed while debugging an
-application that uses a language currently not supported by GDB.
-
- If the language is set to `auto', GDB will automatically select this
-language if the current frame corresponds to an unsupported language.
-
-
-File: gdb.info, Node: Symbols, Next: Altering, Prev: Languages, Up: Top
-
-16 Examining the Symbol Table
-*****************************
-
-The commands described in this chapter allow you to inquire about the
-symbols (names of variables, functions and types) defined in your
-program. This information is inherent in the text of your program and
-does not change as your program executes. GDB finds it in your
-program's symbol table, in the file indicated when you started GDB
-(*note Choosing Files: File Options.), or by one of the file-management
-commands (*note Commands to Specify Files: Files.).
-
- Occasionally, you may need to refer to symbols that contain unusual
-characters, which GDB ordinarily treats as word delimiters. The most
-frequent case is in referring to static variables in other source files
-(*note Program Variables: Variables.). File names are recorded in
-object files as debugging symbols, but GDB would ordinarily parse a
-typical file name, like `foo.c', as the three words `foo' `.' `c'. To
-allow GDB to recognize `foo.c' as a single symbol, enclose it in single
-quotes; for example,
-
- p 'foo.c'::x
-
-looks up the value of `x' in the scope of the file `foo.c'.
-
-`set case-sensitive on'
-`set case-sensitive off'
-`set case-sensitive auto'
- Normally, when GDB looks up symbols, it matches their names with
- case sensitivity determined by the current source language.
- Occasionally, you may wish to control that. The command `set
- case-sensitive' lets you do that by specifying `on' for
- case-sensitive matches or `off' for case-insensitive ones. If you
- specify `auto', case sensitivity is reset to the default suitable
- for the source language. The default is case-sensitive matches
- for all languages except for Fortran, for which the default is
- case-insensitive matches.
-
-`show case-sensitive'
- This command shows the current setting of case sensitivity for
- symbols lookups.
-
-`info address SYMBOL'
- Describe where the data for SYMBOL is stored. For a register
- variable, this says which register it is kept in. For a
- non-register local variable, this prints the stack-frame offset at
- which the variable is always stored.
-
- Note the contrast with `print &SYMBOL', which does not work at all
- for a register variable, and for a stack local variable prints the
- exact address of the current instantiation of the variable.
-
-`info symbol ADDR'
- Print the name of a symbol which is stored at the address ADDR.
- If no symbol is stored exactly at ADDR, GDB prints the nearest
- symbol and an offset from it:
-
- (gdb) info symbol 0x54320
- _initialize_vx + 396 in section .text
-
- This is the opposite of the `info address' command. You can use
- it to find out the name of a variable or a function given its
- address.
-
- For dynamically linked executables, the name of executable or
- shared library containing the symbol is also printed:
-
- (gdb) info symbol 0x400225
- _start + 5 in section .text of /tmp/a.out
- (gdb) info symbol 0x2aaaac2811cf
- __read_nocancel + 6 in section .text of /usr/lib64/libc.so.6
-
-`whatis [ARG]'
- Print the data type of ARG, which can be either an expression or a
- data type. With no argument, print the data type of `$', the last
- value in the value history. If ARG is an expression, it is not
- actually evaluated, and any side-effecting operations (such as
- assignments or function calls) inside it do not take place. If
- ARG is a type name, it may be the name of a type or typedef, or
- for C code it may have the form `class CLASS-NAME', `struct
- STRUCT-TAG', `union UNION-TAG' or `enum ENUM-TAG'. *Note
- Expressions: Expressions.
-
-`ptype [ARG]'
- `ptype' accepts the same arguments as `whatis', but prints a
- detailed description of the type, instead of just the name of the
- type. *Note Expressions: Expressions.
-
- For example, for this variable declaration:
-
- struct complex {double real; double imag;} v;
-
- the two commands give this output:
-
- (gdb) whatis v
- type = struct complex
- (gdb) ptype v
- type = struct complex {
- double real;
- double imag;
- }
-
- As with `whatis', using `ptype' without an argument refers to the
- type of `$', the last value in the value history.
-
- Sometimes, programs use opaque data types or incomplete
- specifications of complex data structure. If the debug
- information included in the program does not allow GDB to display
- a full declaration of the data type, it will say `<incomplete
- type>'. For example, given these declarations:
-
- struct foo;
- struct foo *fooptr;
-
- but no definition for `struct foo' itself, GDB will say:
-
- (gdb) ptype foo
- $1 = <incomplete type>
-
- "Incomplete type" is C terminology for data types that are not
- completely specified.
-
-`info types REGEXP'
-`info types'
- Print a brief description of all types whose names match the
- regular expression REGEXP (or all types in your program, if you
- supply no argument). Each complete typename is matched as though
- it were a complete line; thus, `i type value' gives information on
- all types in your program whose names include the string `value',
- but `i type ^value$' gives information only on types whose complete
- name is `value'.
-
- This command differs from `ptype' in two ways: first, like
- `whatis', it does not print a detailed description; second, it
- lists all source files where a type is defined.
-
-`info scope LOCATION'
- List all the variables local to a particular scope. This command
- accepts a LOCATION argument--a function name, a source line, or an
- address preceded by a `*', and prints all the variables local to
- the scope defined by that location. (*Note Specify Location::, for
- details about supported forms of LOCATION.) For example:
-
- (gdb) info scope command_line_handler
- Scope for command_line_handler:
- Symbol rl is an argument at stack/frame offset 8, length 4.
- Symbol linebuffer is in static storage at address 0x150a18, length 4.
- Symbol linelength is in static storage at address 0x150a1c, length 4.
- Symbol p is a local variable in register $esi, length 4.
- Symbol p1 is a local variable in register $ebx, length 4.
- Symbol nline is a local variable in register $edx, length 4.
- Symbol repeat is a local variable at frame offset -8, length 4.
-
- This command is especially useful for determining what data to
- collect during a "trace experiment", see *note collect: Tracepoint
- Actions.
-
-`info source'
- Show information about the current source file--that is, the
- source file for the function containing the current point of
- execution:
- * the name of the source file, and the directory containing it,
-
- * the directory it was compiled in,
-
- * its length, in lines,
-
- * which programming language it is written in,
-
- * whether the executable includes debugging information for
- that file, and if so, what format the information is in
- (e.g., STABS, Dwarf 2, etc.), and
-
- * whether the debugging information includes information about
- preprocessor macros.
-
-`info sources'
- Print the names of all source files in your program for which
- there is debugging information, organized into two lists: files
- whose symbols have already been read, and files whose symbols will
- be read when needed.
-
-`info functions'
- Print the names and data types of all defined functions.
-
-`info functions REGEXP'
- Print the names and data types of all defined functions whose
- names contain a match for regular expression REGEXP. Thus, `info
- fun step' finds all functions whose names include `step'; `info
- fun ^step' finds those whose names start with `step'. If a
- function name contains characters that conflict with the regular
- expression language (e.g. `operator*()'), they may be quoted with
- a backslash.
-
-`info variables'
- Print the names and data types of all variables that are defined
- outside of functions (i.e. excluding local variables).
-
-`info variables REGEXP'
- Print the names and data types of all variables (except for local
- variables) whose names contain a match for regular expression
- REGEXP.
-
-`info classes'
-`info classes REGEXP'
- Display all Objective-C classes in your program, or (with the
- REGEXP argument) all those matching a particular regular
- expression.
-
-`info selectors'
-`info selectors REGEXP'
- Display all Objective-C selectors in your program, or (with the
- REGEXP argument) all those matching a particular regular
- expression.
-
- Some systems allow individual object files that make up your
- program to be replaced without stopping and restarting your
- program. For example, in VxWorks you can simply recompile a
- defective object file and keep on running. If you are running on
- one of these systems, you can allow GDB to reload the symbols for
- automatically relinked modules:
-
- `set symbol-reloading on'
- Replace symbol definitions for the corresponding source file
- when an object file with a particular name is seen again.
-
- `set symbol-reloading off'
- Do not replace symbol definitions when encountering object
- files of the same name more than once. This is the default
- state; if you are not running on a system that permits
- automatic relinking of modules, you should leave
- `symbol-reloading' off, since otherwise GDB may discard
- symbols when linking large programs, that may contain several
- modules (from different directories or libraries) with the
- same name.
-
- `show symbol-reloading'
- Show the current `on' or `off' setting.
-
-`set opaque-type-resolution on'
- Tell GDB to resolve opaque types. An opaque type is a type
- declared as a pointer to a `struct', `class', or `union'--for
- example, `struct MyType *'--that is used in one source file
- although the full declaration of `struct MyType' is in another
- source file. The default is on.
-
- A change in the setting of this subcommand will not take effect
- until the next time symbols for a file are loaded.
-
-`set opaque-type-resolution off'
- Tell GDB not to resolve opaque types. In this case, the type is
- printed as follows:
- {<no data fields>}
-
-`show opaque-type-resolution'
- Show whether opaque types are resolved or not.
-
-`set print symbol-loading'
-`set print symbol-loading on'
-`set print symbol-loading off'
- The `set print symbol-loading' command allows you to enable or
- disable printing of messages when GDB loads symbols. By default,
- these messages will be printed, and normally this is what you
- want. Disabling these messages is useful when debugging
- applications with lots of shared libraries where the quantity of
- output can be more annoying than useful.
-
-`show print symbol-loading'
- Show whether messages will be printed when GDB loads symbols.
-
-`maint print symbols FILENAME'
-`maint print psymbols FILENAME'
-`maint print msymbols FILENAME'
- Write a dump of debugging symbol data into the file FILENAME.
- These commands are used to debug the GDB symbol-reading code. Only
- symbols with debugging data are included. If you use `maint print
- symbols', GDB includes all the symbols for which it has already
- collected full details: that is, FILENAME reflects symbols for
- only those files whose symbols GDB has read. You can use the
- command `info sources' to find out which files these are. If you
- use `maint print psymbols' instead, the dump shows information
- about symbols that GDB only knows partially--that is, symbols
- defined in files that GDB has skimmed, but not yet read
- completely. Finally, `maint print msymbols' dumps just the
- minimal symbol information required for each object file from
- which GDB has read some symbols. *Note Commands to Specify Files:
- Files, for a discussion of how GDB reads symbols (in the
- description of `symbol-file').
-
-`maint info symtabs [ REGEXP ]'
-`maint info psymtabs [ REGEXP ]'
- List the `struct symtab' or `struct partial_symtab' structures
- whose names match REGEXP. If REGEXP is not given, list them all.
- The output includes expressions which you can copy into a GDB
- debugging this one to examine a particular structure in more
- detail. For example:
-
- (gdb) maint info psymtabs dwarf2read
- { objfile /home/gnu/build/gdb/gdb
- ((struct objfile *) 0x82e69d0)
- { psymtab /home/gnu/src/gdb/dwarf2read.c
- ((struct partial_symtab *) 0x8474b10)
- readin no
- fullname (null)
- text addresses 0x814d3c8 -- 0x8158074
- globals (* (struct partial_symbol **) 0x8507a08 @ 9)
- statics (* (struct partial_symbol **) 0x40e95b78 @ 2882)
- dependencies (none)
- }
- }
- (gdb) maint info symtabs
- (gdb)
- We see that there is one partial symbol table whose filename
- contains the string `dwarf2read', belonging to the `gdb'
- executable; and we see that GDB has not read in any symtabs yet at
- all. If we set a breakpoint on a function, that will cause GDB to
- read the symtab for the compilation unit containing that function:
-
- (gdb) break dwarf2_psymtab_to_symtab
- Breakpoint 1 at 0x814e5da: file /home/gnu/src/gdb/dwarf2read.c,
- line 1574.
- (gdb) maint info symtabs
- { objfile /home/gnu/build/gdb/gdb
- ((struct objfile *) 0x82e69d0)
- { symtab /home/gnu/src/gdb/dwarf2read.c
- ((struct symtab *) 0x86c1f38)
- dirname (null)
- fullname (null)
- blockvector ((struct blockvector *) 0x86c1bd0) (primary)
- linetable ((struct linetable *) 0x8370fa0)
- debugformat DWARF 2
- }
- }
- (gdb)
-
-
-File: gdb.info, Node: Altering, Next: GDB Files, Prev: Symbols, Up: Top
-
-17 Altering Execution
-*********************
-
-Once you think you have found an error in your program, you might want
-to find out for certain whether correcting the apparent error would
-lead to correct results in the rest of the run. You can find the
-answer by experiment, using the GDB features for altering execution of
-the program.
-
- For example, you can store new values into variables or memory
-locations, give your program a signal, restart it at a different
-address, or even return prematurely from a function.
-
-* Menu:
-
-* Assignment:: Assignment to variables
-* Jumping:: Continuing at a different address
-* Signaling:: Giving your program a signal
-* Returning:: Returning from a function
-* Calling:: Calling your program's functions
-* Patching:: Patching your program
-
-
-File: gdb.info, Node: Assignment, Next: Jumping, Up: Altering
-
-17.1 Assignment to Variables
-============================
-
-To alter the value of a variable, evaluate an assignment expression.
-*Note Expressions: Expressions. For example,
-
- print x=4
-
-stores the value 4 into the variable `x', and then prints the value of
-the assignment expression (which is 4). *Note Using GDB with Different
-Languages: Languages, for more information on operators in supported
-languages.
-
- If you are not interested in seeing the value of the assignment, use
-the `set' command instead of the `print' command. `set' is really the
-same as `print' except that the expression's value is not printed and
-is not put in the value history (*note Value History: Value History.).
-The expression is evaluated only for its effects.
-
- If the beginning of the argument string of the `set' command appears
-identical to a `set' subcommand, use the `set variable' command instead
-of just `set'. This command is identical to `set' except for its lack
-of subcommands. For example, if your program has a variable `width',
-you get an error if you try to set a new value with just `set
-width=13', because GDB has the command `set width':
-
- (gdb) whatis width
- type = double
- (gdb) p width
- $4 = 13
- (gdb) set width=47
- Invalid syntax in expression.
-
-The invalid expression, of course, is `=47'. In order to actually set
-the program's variable `width', use
-
- (gdb) set var width=47
-
- Because the `set' command has many subcommands that can conflict
-with the names of program variables, it is a good idea to use the `set
-variable' command instead of just `set'. For example, if your program
-has a variable `g', you run into problems if you try to set a new value
-with just `set g=4', because GDB has the command `set gnutarget',
-abbreviated `set g':
-
- (gdb) whatis g
- type = double
- (gdb) p g
- $1 = 1
- (gdb) set g=4
- (gdb) p g
- $2 = 1
- (gdb) r
- The program being debugged has been started already.
- Start it from the beginning? (y or n) y
- Starting program: /home/smith/cc_progs/a.out
- "/home/smith/cc_progs/a.out": can't open to read symbols:
- Invalid bfd target.
- (gdb) show g
- The current BFD target is "=4".
-
-The program variable `g' did not change, and you silently set the
-`gnutarget' to an invalid value. In order to set the variable `g', use
-
- (gdb) set var g=4
-
- GDB allows more implicit conversions in assignments than C; you can
-freely store an integer value into a pointer variable or vice versa,
-and you can convert any structure to any other structure that is the
-same length or shorter.
-
- To store values into arbitrary places in memory, use the `{...}'
-construct to generate a value of specified type at a specified address
-(*note Expressions: Expressions.). For example, `{int}0x83040' refers
-to memory location `0x83040' as an integer (which implies a certain size
-and representation in memory), and
-
- set {int}0x83040 = 4
-
-stores the value 4 into that memory location.
-
-
-File: gdb.info, Node: Jumping, Next: Signaling, Prev: Assignment, Up: Altering
-
-17.2 Continuing at a Different Address
-======================================
-
-Ordinarily, when you continue your program, you do so at the place where
-it stopped, with the `continue' command. You can instead continue at
-an address of your own choosing, with the following commands:
-
-`jump LINESPEC'
-`jump LOCATION'
- Resume execution at line LINESPEC or at address given by LOCATION.
- Execution stops again immediately if there is a breakpoint there.
- *Note Specify Location::, for a description of the different forms
- of LINESPEC and LOCATION. It is common practice to use the
- `tbreak' command in conjunction with `jump'. *Note Setting
- Breakpoints: Set Breaks.
-
- The `jump' command does not change the current stack frame, or the
- stack pointer, or the contents of any memory location or any
- register other than the program counter. If line LINESPEC is in a
- different function from the one currently executing, the results
- may be bizarre if the two functions expect different patterns of
- arguments or of local variables. For this reason, the `jump'
- command requests confirmation if the specified line is not in the
- function currently executing. However, even bizarre results are
- predictable if you are well acquainted with the machine-language
- code of your program.
-
- On many systems, you can get much the same effect as the `jump'
-command by storing a new value into the register `$pc'. The difference
-is that this does not start your program running; it only changes the
-address of where it _will_ run when you continue. For example,
-
- set $pc = 0x485
-
-makes the next `continue' command or stepping command execute at
-address `0x485', rather than at the address where your program stopped.
-*Note Continuing and Stepping: Continuing and Stepping.
-
- The most common occasion to use the `jump' command is to back
-up--perhaps with more breakpoints set--over a portion of a program that
-has already executed, in order to examine its execution in more detail.
-
-
-File: gdb.info, Node: Signaling, Next: Returning, Prev: Jumping, Up: Altering
-
-17.3 Giving your Program a Signal
-=================================
-
-`signal SIGNAL'
- Resume execution where your program stopped, but immediately give
- it the signal SIGNAL. SIGNAL can be the name or the number of a
- signal. For example, on many systems `signal 2' and `signal
- SIGINT' are both ways of sending an interrupt signal.
-
- Alternatively, if SIGNAL is zero, continue execution without
- giving a signal. This is useful when your program stopped on
- account of a signal and would ordinary see the signal when resumed
- with the `continue' command; `signal 0' causes it to resume
- without a signal.
-
- `signal' does not repeat when you press <RET> a second time after
- executing the command.
-
- Invoking the `signal' command is not the same as invoking the `kill'
-utility from the shell. Sending a signal with `kill' causes GDB to
-decide what to do with the signal depending on the signal handling
-tables (*note Signals::). The `signal' command passes the signal
-directly to your program.
-
-
-File: gdb.info, Node: Returning, Next: Calling, Prev: Signaling, Up: Altering
-
-17.4 Returning from a Function
-==============================
-
-`return'
-`return EXPRESSION'
- You can cancel execution of a function call with the `return'
- command. If you give an EXPRESSION argument, its value is used as
- the function's return value.
-
- When you use `return', GDB discards the selected stack frame (and
-all frames within it). You can think of this as making the discarded
-frame return prematurely. If you wish to specify a value to be
-returned, give that value as the argument to `return'.
-
- This pops the selected stack frame (*note Selecting a Frame:
-Selection.), and any other frames inside of it, leaving its caller as
-the innermost remaining frame. That frame becomes selected. The
-specified value is stored in the registers used for returning values of
-functions.
-
- The `return' command does not resume execution; it leaves the
-program stopped in the state that would exist if the function had just
-returned. In contrast, the `finish' command (*note Continuing and
-Stepping: Continuing and Stepping.) resumes execution until the
-selected stack frame returns naturally.
-
- GDB needs to know how the EXPRESSION argument should be set for the
-inferior. The concrete registers assignment depends on the OS ABI and
-the type being returned by the selected stack frame. For example it is
-common for OS ABI to return floating point values in FPU registers
-while integer values in CPU registers. Still some ABIs return even
-floating point values in CPU registers. Larger integer widths (such as
-`long long int') also have specific placement rules. GDB already knows
-the OS ABI from its current target so it needs to find out also the
-type being returned to make the assignment into the right register(s).
-
- Normally, the selected stack frame has debug info. GDB will always
-use the debug info instead of the implicit type of EXPRESSION when the
-debug info is available. For example, if you type `return -1', and the
-function in the current stack frame is declared to return a `long long
-int', GDB transparently converts the implicit `int' value of -1 into a
-`long long int':
-
- Breakpoint 1, func () at gdb.base/return-nodebug.c:29
- 29 return 31;
- (gdb) return -1
- Make func return now? (y or n) y
- #0 0x004004f6 in main () at gdb.base/return-nodebug.c:43
- 43 printf ("result=%lld\n", func ());
- (gdb)
-
- However, if the selected stack frame does not have a debug info,
-e.g., if the function was compiled without debug info, GDB has to find
-out the type to return from user. Specifying a different type by
-mistake may set the value in different inferior registers than the
-caller code expects. For example, typing `return -1' with its implicit
-type `int' would set only a part of a `long long int' result for a
-debug info less function (on 32-bit architectures). Therefore the user
-is required to specify the return type by an appropriate cast
-explicitly:
-
- Breakpoint 2, 0x0040050b in func ()
- (gdb) return -1
- Return value type not available for selected stack frame.
- Please use an explicit cast of the value to return.
- (gdb) return (long long int) -1
- Make selected stack frame return now? (y or n) y
- #0 0x00400526 in main ()
- (gdb)
-
-
-File: gdb.info, Node: Calling, Next: Patching, Prev: Returning, Up: Altering
-
-17.5 Calling Program Functions
-==============================
-
-`print EXPR'
- Evaluate the expression EXPR and display the resulting value.
- EXPR may include calls to functions in the program being debugged.
-
-`call EXPR'
- Evaluate the expression EXPR without displaying `void' returned
- values.
-
- You can use this variant of the `print' command if you want to
- execute a function from your program that does not return anything
- (a.k.a. "a void function"), but without cluttering the output with
- `void' returned values that GDB will otherwise print. If the
- result is not void, it is printed and saved in the value history.
-
- It is possible for the function you call via the `print' or `call'
-command to generate a signal (e.g., if there's a bug in the function,
-or if you passed it incorrect arguments). What happens in that case is
-controlled by the `set unwindonsignal' command.
-
- Similarly, with a C++ program it is possible for the function you
-call via the `print' or `call' command to generate an exception that is
-not handled due to the constraints of the dummy frame. In this case,
-any exception that is raised in the frame, but has an out-of-frame
-exception handler will not be found. GDB builds a dummy-frame for the
-inferior function call, and the unwinder cannot seek for exception
-handlers outside of this dummy-frame. What happens in that case is
-controlled by the `set unwind-on-terminating-exception' command.
-
-`set unwindonsignal'
- Set unwinding of the stack if a signal is received while in a
- function that GDB called in the program being debugged. If set to
- on, GDB unwinds the stack it created for the call and restores the
- context to what it was before the call. If set to off (the
- default), GDB stops in the frame where the signal was received.
-
-`show unwindonsignal'
- Show the current setting of stack unwinding in the functions
- called by GDB.
-
-`set unwind-on-terminating-exception'
- Set unwinding of the stack if a C++ exception is raised, but left
- unhandled while in a function that GDB called in the program being
- debugged. If set to on (the default), GDB unwinds the stack it
- created for the call and restores the context to what it was before
- the call. If set to off, GDB the exception is delivered to the
- default C++ exception handler and the inferior terminated.
-
-`show unwind-on-terminating-exception'
- Show the current setting of stack unwinding in the functions
- called by GDB.
-
-
- Sometimes, a function you wish to call is actually a "weak alias"
-for another function. In such case, GDB might not pick up the type
-information, including the types of the function arguments, which
-causes GDB to call the inferior function incorrectly. As a result, the
-called function will function erroneously and may even crash. A
-solution to that is to use the name of the aliased function instead.
-
-
-File: gdb.info, Node: Patching, Prev: Calling, Up: Altering
-
-17.6 Patching Programs
-======================
-
-By default, GDB opens the file containing your program's executable
-code (or the corefile) read-only. This prevents accidental alterations
-to machine code; but it also prevents you from intentionally patching
-your program's binary.
-
- If you'd like to be able to patch the binary, you can specify that
-explicitly with the `set write' command. For example, you might want
-to turn on internal debugging flags, or even to make emergency repairs.
-
-`set write on'
-`set write off'
- If you specify `set write on', GDB opens executable and core files
- for both reading and writing; if you specify `set write off' (the
- default), GDB opens them read-only.
-
- If you have already loaded a file, you must load it again (using
- the `exec-file' or `core-file' command) after changing `set
- write', for your new setting to take effect.
-
-`show write'
- Display whether executable files and core files are opened for
- writing as well as reading.
-
-
-File: gdb.info, Node: GDB Files, Next: Targets, Prev: Altering, Up: Top
-
-18 GDB Files
-************
-
-GDB needs to know the file name of the program to be debugged, both in
-order to read its symbol table and in order to start your program. To
-debug a core dump of a previous run, you must also tell GDB the name of
-the core dump file.
-
-* Menu:
-
-* Files:: Commands to specify files
-* Separate Debug Files:: Debugging information in separate files
-* Index Files:: Index files speed up GDB
-* Symbol Errors:: Errors reading symbol files
-* Data Files:: GDB data files
-
-
-File: gdb.info, Node: Files, Next: Separate Debug Files, Up: GDB Files
-
-18.1 Commands to Specify Files
-==============================
-
-You may want to specify executable and core dump file names. The usual
-way to do this is at start-up time, using the arguments to GDB's
-start-up commands (*note Getting In and Out of GDB: Invocation.).
-
- Occasionally it is necessary to change to a different file during a
-GDB session. Or you may run GDB and forget to specify a file you want
-to use. Or you are debugging a remote target via `gdbserver' (*note
-file: Server.). In these situations the GDB commands to specify new
-files are useful.
-
-`file FILENAME'
- Use FILENAME as the program to be debugged. It is read for its
- symbols and for the contents of pure memory. It is also the
- program executed when you use the `run' command. If you do not
- specify a directory and the file is not found in the GDB working
- directory, GDB uses the environment variable `PATH' as a list of
- directories to search, just as the shell does when looking for a
- program to run. You can change the value of this variable, for
- both GDB and your program, using the `path' command.
-
- You can load unlinked object `.o' files into GDB using the `file'
- command. You will not be able to "run" an object file, but you
- can disassemble functions and inspect variables. Also, if the
- underlying BFD functionality supports it, you could use `gdb
- -write' to patch object files using this technique. Note that GDB
- can neither interpret nor modify relocations in this case, so
- branches and some initialized variables will appear to go to the
- wrong place. But this feature is still handy from time to time.
-
-`file'
- `file' with no argument makes GDB discard any information it has
- on both executable file and the symbol table.
-
-`exec-file [ FILENAME ]'
- Specify that the program to be run (but not the symbol table) is
- found in FILENAME. GDB searches the environment variable `PATH'
- if necessary to locate your program. Omitting FILENAME means to
- discard information on the executable file.
-
-`symbol-file [ FILENAME ]'
- Read symbol table information from file FILENAME. `PATH' is
- searched when necessary. Use the `file' command to get both symbol
- table and program to run from the same file.
-
- `symbol-file' with no argument clears out GDB information on your
- program's symbol table.
-
- The `symbol-file' command causes GDB to forget the contents of
- some breakpoints and auto-display expressions. This is because
- they may contain pointers to the internal data recording symbols
- and data types, which are part of the old symbol table data being
- discarded inside GDB.
-
- `symbol-file' does not repeat if you press <RET> again after
- executing it once.
-
- When GDB is configured for a particular environment, it
- understands debugging information in whatever format is the
- standard generated for that environment; you may use either a GNU
- compiler, or other compilers that adhere to the local conventions.
- Best results are usually obtained from GNU compilers; for example,
- using `GCC' you can generate debugging information for optimized
- code.
-
- For most kinds of object files, with the exception of old SVR3
- systems using COFF, the `symbol-file' command does not normally
- read the symbol table in full right away. Instead, it scans the
- symbol table quickly to find which source files and which symbols
- are present. The details are read later, one source file at a
- time, as they are needed.
-
- The purpose of this two-stage reading strategy is to make GDB
- start up faster. For the most part, it is invisible except for
- occasional pauses while the symbol table details for a particular
- source file are being read. (The `set verbose' command can turn
- these pauses into messages if desired. *Note Optional Warnings
- and Messages: Messages/Warnings.)
-
- We have not implemented the two-stage strategy for COFF yet. When
- the symbol table is stored in COFF format, `symbol-file' reads the
- symbol table data in full right away. Note that "stabs-in-COFF"
- still does the two-stage strategy, since the debug info is actually
- in stabs format.
-
-`symbol-file [ -readnow ] FILENAME'
-`file [ -readnow ] FILENAME'
- You can override the GDB two-stage strategy for reading symbol
- tables by using the `-readnow' option with any of the commands that
- load symbol table information, if you want to be sure GDB has the
- entire symbol table available.
-
-`core-file [FILENAME]'
-`core'
- Specify the whereabouts of a core dump file to be used as the
- "contents of memory". Traditionally, core files contain only some
- parts of the address space of the process that generated them; GDB
- can access the executable file itself for other parts.
-
- `core-file' with no argument specifies that no core file is to be
- used.
-
- Note that the core file is ignored when your program is actually
- running under GDB. So, if you have been running your program and
- you wish to debug a core file instead, you must kill the
- subprocess in which the program is running. To do this, use the
- `kill' command (*note Killing the Child Process: Kill Process.).
-
-`add-symbol-file FILENAME ADDRESS'
-`add-symbol-file FILENAME ADDRESS [ -readnow ]'
-`add-symbol-file FILENAME -sSECTION ADDRESS ...'
- The `add-symbol-file' command reads additional symbol table
- information from the file FILENAME. You would use this command
- when FILENAME has been dynamically loaded (by some other means)
- into the program that is running. ADDRESS should be the memory
- address at which the file has been loaded; GDB cannot figure this
- out for itself. You can additionally specify an arbitrary number
- of `-sSECTION ADDRESS' pairs, to give an explicit section name and
- base address for that section. You can specify any ADDRESS as an
- expression.
-
- The symbol table of the file FILENAME is added to the symbol table
- originally read with the `symbol-file' command. You can use the
- `add-symbol-file' command any number of times; the new symbol data
- thus read keeps adding to the old. To discard all old symbol data
- instead, use the `symbol-file' command without any arguments.
-
- Although FILENAME is typically a shared library file, an
- executable file, or some other object file which has been fully
- relocated for loading into a process, you can also load symbolic
- information from relocatable `.o' files, as long as:
-
- * the file's symbolic information refers only to linker symbols
- defined in that file, not to symbols defined by other object
- files,
-
- * every section the file's symbolic information refers to has
- actually been loaded into the inferior, as it appears in the
- file, and
-
- * you can determine the address at which every section was
- loaded, and provide these to the `add-symbol-file' command.
-
- Some embedded operating systems, like Sun Chorus and VxWorks, can
- load relocatable files into an already running program; such
- systems typically make the requirements above easy to meet.
- However, it's important to recognize that many native systems use
- complex link procedures (`.linkonce' section factoring and C++
- constructor table assembly, for example) that make the
- requirements difficult to meet. In general, one cannot assume
- that using `add-symbol-file' to read a relocatable object file's
- symbolic information will have the same effect as linking the
- relocatable object file into the program in the normal way.
-
- `add-symbol-file' does not repeat if you press <RET> after using
- it.
-
-`add-symbol-file-from-memory ADDRESS'
- Load symbols from the given ADDRESS in a dynamically loaded object
- file whose image is mapped directly into the inferior's memory.
- For example, the Linux kernel maps a `syscall DSO' into each
- process's address space; this DSO provides kernel-specific code for
- some system calls. The argument can be any expression whose
- evaluation yields the address of the file's shared object file
- header. For this command to work, you must have used
- `symbol-file' or `exec-file' commands in advance.
-
-`add-shared-symbol-files LIBRARY-FILE'
-`assf LIBRARY-FILE'
- The `add-shared-symbol-files' command can currently be used only
- in the Cygwin build of GDB on MS-Windows OS, where it is an alias
- for the `dll-symbols' command (*note Cygwin Native::). GDB
- automatically looks for shared libraries, however if GDB does not
- find yours, you can invoke `add-shared-symbol-files'. It takes
- one argument: the shared library's file name. `assf' is a
- shorthand alias for `add-shared-symbol-files'.
-
-`section SECTION ADDR'
- The `section' command changes the base address of the named
- SECTION of the exec file to ADDR. This can be used if the exec
- file does not contain section addresses, (such as in the `a.out'
- format), or when the addresses specified in the file itself are
- wrong. Each section must be changed separately. The `info files'
- command, described below, lists all the sections and their
- addresses.
-
-`info files'
-`info target'
- `info files' and `info target' are synonymous; both print the
- current target (*note Specifying a Debugging Target: Targets.),
- including the names of the executable and core dump files
- currently in use by GDB, and the files from which symbols were
- loaded. The command `help target' lists all possible targets
- rather than current ones.
-
-`maint info sections'
- Another command that can give you extra information about program
- sections is `maint info sections'. In addition to the section
- information displayed by `info files', this command displays the
- flags and file offset of each section in the executable and core
- dump files. In addition, `maint info sections' provides the
- following command options (which may be arbitrarily combined):
-
- `ALLOBJ'
- Display sections for all loaded object files, including
- shared libraries.
-
- `SECTIONS'
- Display info only for named SECTIONS.
-
- `SECTION-FLAGS'
- Display info only for sections for which SECTION-FLAGS are
- true. The section flags that GDB currently knows about are:
- `ALLOC'
- Section will have space allocated in the process when
- loaded. Set for all sections except those containing
- debug information.
-
- `LOAD'
- Section will be loaded from the file into the child
- process memory. Set for pre-initialized code and data,
- clear for `.bss' sections.
-
- `RELOC'
- Section needs to be relocated before loading.
-
- `READONLY'
- Section cannot be modified by the child process.
-
- `CODE'
- Section contains executable code only.
-
- `DATA'
- Section contains data only (no executable code).
-
- `ROM'
- Section will reside in ROM.
-
- `CONSTRUCTOR'
- Section contains data for constructor/destructor lists.
-
- `HAS_CONTENTS'
- Section is not empty.
-
- `NEVER_LOAD'
- An instruction to the linker to not output the section.
-
- `COFF_SHARED_LIBRARY'
- A notification to the linker that the section contains
- COFF shared library information.
-
- `IS_COMMON'
- Section contains common symbols.
-
-`set trust-readonly-sections on'
- Tell GDB that readonly sections in your object file really are
- read-only (i.e. that their contents will not change). In that
- case, GDB can fetch values from these sections out of the object
- file, rather than from the target program. For some targets
- (notably embedded ones), this can be a significant enhancement to
- debugging performance.
-
- The default is off.
-
-`set trust-readonly-sections off'
- Tell GDB not to trust readonly sections. This means that the
- contents of the section might change while the program is running,
- and must therefore be fetched from the target when needed.
-
-`show trust-readonly-sections'
- Show the current setting of trusting readonly sections.
-
- All file-specifying commands allow both absolute and relative file
-names as arguments. GDB always converts the file name to an absolute
-file name and remembers it that way.
-
- GDB supports GNU/Linux, MS-Windows, HP-UX, SunOS, SVr4, Irix, and
-IBM RS/6000 AIX shared libraries.
-
- On MS-Windows GDB must be linked with the Expat library to support
-shared libraries. *Note Expat::.
-
- GDB automatically loads symbol definitions from shared libraries
-when you use the `run' command, or when you examine a core file.
-(Before you issue the `run' command, GDB does not understand references
-to a function in a shared library, however--unless you are debugging a
-core file).
-
- On HP-UX, if the program loads a library explicitly, GDB
-automatically loads the symbols at the time of the `shl_load' call.
-
- There are times, however, when you may wish to not automatically load
-symbol definitions from shared libraries, such as when they are
-particularly large or there are many of them.
-
- To control the automatic loading of shared library symbols, use the
-commands:
-
-`set auto-solib-add MODE'
- If MODE is `on', symbols from all shared object libraries will be
- loaded automatically when the inferior begins execution, you
- attach to an independently started inferior, or when the dynamic
- linker informs GDB that a new library has been loaded. If MODE is
- `off', symbols must be loaded manually, using the `sharedlibrary'
- command. The default value is `on'.
-
- If your program uses lots of shared libraries with debug info that
- takes large amounts of memory, you can decrease the GDB memory
- footprint by preventing it from automatically loading the symbols
- from shared libraries. To that end, type `set auto-solib-add off'
- before running the inferior, then load each library whose debug
- symbols you do need with `sharedlibrary REGEXP', where REGEXP is a
- regular expression that matches the libraries whose symbols you
- want to be loaded.
-
-`show auto-solib-add'
- Display the current autoloading mode.
-
- To explicitly load shared library symbols, use the `sharedlibrary'
-command:
-
-`info share REGEX'
-`info sharedlibrary REGEX'
- Print the names of the shared libraries which are currently loaded
- that match REGEX. If REGEX is omitted then print all shared
- libraries that are loaded.
-
-`sharedlibrary REGEX'
-`share REGEX'
- Load shared object library symbols for files matching a Unix
- regular expression. As with files loaded automatically, it only
- loads shared libraries required by your program for a core file or
- after typing `run'. If REGEX is omitted all shared libraries
- required by your program are loaded.
-
-`nosharedlibrary'
- Unload all shared object library symbols. This discards all
- symbols that have been loaded from all shared libraries. Symbols
- from shared libraries that were loaded by explicit user requests
- are not discarded.
-
- Sometimes you may wish that GDB stops and gives you control when any
-of shared library events happen. Use the `set stop-on-solib-events'
-command for this:
-
-`set stop-on-solib-events'
- This command controls whether GDB should give you control when the
- dynamic linker notifies it about some shared library event. The
- most common event of interest is loading or unloading of a new
- shared library.
-
-`show stop-on-solib-events'
- Show whether GDB stops and gives you control when shared library
- events happen.
-
- Shared libraries are also supported in many cross or remote debugging
-configurations. GDB needs to have access to the target's libraries;
-this can be accomplished either by providing copies of the libraries on
-the host system, or by asking GDB to automatically retrieve the
-libraries from the target. If copies of the target libraries are
-provided, they need to be the same as the target libraries, although the
-copies on the target can be stripped as long as the copies on the host
-are not.
-
- For remote debugging, you need to tell GDB where the target
-libraries are, so that it can load the correct copies--otherwise, it
-may try to load the host's libraries. GDB has two variables to specify
-the search directories for target libraries.
-
-`set sysroot PATH'
- Use PATH as the system root for the program being debugged. Any
- absolute shared library paths will be prefixed with PATH; many
- runtime loaders store the absolute paths to the shared library in
- the target program's memory. If you use `set sysroot' to find
- shared libraries, they need to be laid out in the same way that
- they are on the target, with e.g. a `/lib' and `/usr/lib' hierarchy
- under PATH.
-
- If PATH starts with the sequence `remote:', GDB will retrieve the
- target libraries from the remote system. This is only supported
- when using a remote target that supports the `remote get' command
- (*note Sending files to a remote system: File Transfer.). The
- part of PATH following the initial `remote:' (if present) is used
- as system root prefix on the remote file system. (1)
-
- For targets with an MS-DOS based filesystem, such as MS-Windows and
- SymbianOS, GDB tries prefixing a few variants of the target
- absolute file name with PATH. But first, on Unix hosts, GDB
- converts all backslash directory separators into forward slashes,
- because the backslash is not a directory separator on Unix:
-
- c:\foo\bar.dll => c:/foo/bar.dll
-
- Then, GDB attempts prefixing the target file name with PATH, and
- looks for the resulting file name in the host file system:
-
- c:/foo/bar.dll => /path/to/sysroot/c:/foo/bar.dll
-
- If that does not find the shared library, GDB tries removing the
- `:' character from the drive spec, both for convenience, and, for
- the case of the host file system not supporting file names with
- colons:
-
- c:/foo/bar.dll => /path/to/sysroot/c/foo/bar.dll
-
- This makes it possible to have a system root that mirrors a target
- with more than one drive. E.g., you may want to setup your local
- copies of the target system shared libraries like so (note `c' vs
- `z'):
-
- `/path/to/sysroot/c/sys/bin/foo.dll'
- `/path/to/sysroot/c/sys/bin/bar.dll'
- `/path/to/sysroot/z/sys/bin/bar.dll'
-
- and point the system root at `/path/to/sysroot', so that GDB can
- find the correct copies of both `c:\sys\bin\foo.dll', and
- `z:\sys\bin\bar.dll'.
-
- If that still does not find the shared library, GDB tries removing
- the whole drive spec from the target file name:
-
- c:/foo/bar.dll => /path/to/sysroot/foo/bar.dll
-
- This last lookup makes it possible to not care about the drive
- name, if you don't want or need to.
-
- The `set solib-absolute-prefix' command is an alias for `set
- sysroot'.
-
- You can set the default system root by using the configure-time
- `--with-sysroot' option. If the system root is inside GDB's
- configured binary prefix (set with `--prefix' or `--exec-prefix'),
- then the default system root will be updated automatically if the
- installed GDB is moved to a new location.
-
-`show sysroot'
- Display the current shared library prefix.
-
-`set solib-search-path PATH'
- If this variable is set, PATH is a colon-separated list of
- directories to search for shared libraries. `solib-search-path'
- is used after `sysroot' fails to locate the library, or if the
- path to the library is relative instead of absolute. If you want
- to use `solib-search-path' instead of `sysroot', be sure to set
- `sysroot' to a nonexistent directory to prevent GDB from finding
- your host's libraries. `sysroot' is preferred; setting it to a
- nonexistent directory may interfere with automatic loading of
- shared library symbols.
-
-`show solib-search-path'
- Display the current shared library search path.
-
-`set target-file-system-kind KIND'
- Set assumed file system kind for target reported file names.
-
- Shared library file names as reported by the target system may not
- make sense as is on the system GDB is running on. For example,
- when remote debugging a target that has MS-DOS based file system
- semantics, from a Unix host, the target may be reporting to GDB a
- list of loaded shared libraries with file names such as
- `c:\Windows\kernel32.dll'. On Unix hosts, there's no concept of
- drive letters, so the `c:\' prefix is not normally understood as
- indicating an absolute file name, and neither is the backslash
- normally considered a directory separator character. In that case,
- the native file system would interpret this whole absolute file
- name as a relative file name with no directory components. This
- would make it impossible to point GDB at a copy of the remote
- target's shared libraries on the host using `set sysroot', and
- impractical with `set solib-search-path'. Setting
- `target-file-system-kind' to `dos-based' tells GDB to interpret
- such file names similarly to how the target would, and to map them
- to file names valid on GDB's native file system semantics. The
- value of KIND can be `"auto"', in addition to one of the supported
- file system kinds. In that case, GDB tries to determine the
- appropriate file system variant based on the current target's
- operating system (*note Configuring the Current ABI: ABI.). The
- supported file system settings are:
-
- `unix'
- Instruct GDB to assume the target file system is of Unix
- kind. Only file names starting the forward slash (`/')
- character are considered absolute, and the directory
- separator character is also the forward slash.
-
- `dos-based'
- Instruct GDB to assume the target file system is DOS based.
- File names starting with either a forward slash, or a drive
- letter followed by a colon (e.g., `c:'), are considered
- absolute, and both the slash (`/') and the backslash (`\\')
- characters are considered directory separators.
-
- `auto'
- Instruct GDB to use the file system kind associated with the
- target operating system (*note Configuring the Current ABI:
- ABI.). This is the default.
-
- When processing file names provided by the user, GDB frequently
-needs to compare them to the file names recorded in the program's debug
-info. Normally, GDB compares just the "base names" of the files as
-strings, which is reasonably fast even for very large programs. (The
-base name of a file is the last portion of its name, after stripping
-all the leading directories.) This shortcut in comparison is based
-upon the assumption that files cannot have more than one base name.
-This is usually true, but references to files that use symlinks or
-similar filesystem facilities violate that assumption. If your program
-records files using such facilities, or if you provide file names to
-GDB using symlinks etc., you can set `basenames-may-differ' to `true'
-to instruct GDB to completely canonicalize each pair of file names it
-needs to compare. This will make file-name comparisons accurate, but
-at a price of a significant slowdown.
-
-`set basenames-may-differ'
- Set whether a source file may have multiple base names.
-
-`show basenames-may-differ'
- Show whether a source file may have multiple base names.
-
- ---------- Footnotes ----------
-
- (1) If you want to specify a local system root using a directory
-that happens to be named `remote:', you need to use some equivalent
-variant of the name like `./remote:'.
-
-
-File: gdb.info, Node: Separate Debug Files, Next: Index Files, Prev: Files, Up: GDB Files
-
-18.2 Debugging Information in Separate Files
-============================================
-
-GDB allows you to put a program's debugging information in a file
-separate from the executable itself, in a way that allows GDB to find
-and load the debugging information automatically. Since debugging
-information can be very large--sometimes larger than the executable
-code itself--some systems distribute debugging information for their
-executables in separate files, which users can install only when they
-need to debug a problem.
-
- GDB supports two ways of specifying the separate debug info file:
-
- * The executable contains a "debug link" that specifies the name of
- the separate debug info file. The separate debug file's name is
- usually `EXECUTABLE.debug', where EXECUTABLE is the name of the
- corresponding executable file without leading directories (e.g.,
- `ls.debug' for `/usr/bin/ls'). In addition, the debug link
- specifies a 32-bit "Cyclic Redundancy Check" (CRC) checksum for
- the debug file, which GDB uses to validate that the executable and
- the debug file came from the same build.
-
- * The executable contains a "build ID", a unique bit string that is
- also present in the corresponding debug info file. (This is
- supported only on some operating systems, notably those which use
- the ELF format for binary files and the GNU Binutils.) For more
- details about this feature, see the description of the `--build-id'
- command-line option in *note Command Line Options:
- (ld.info)Options. The debug info file's name is not specified
- explicitly by the build ID, but can be computed from the build ID,
- see below.
-
- Depending on the way the debug info file is specified, GDB uses two
-different methods of looking for the debug file:
-
- * For the "debug link" method, GDB looks up the named file in the
- directory of the executable file, then in a subdirectory of that
- directory named `.debug', and finally under the global debug
- directory, in a subdirectory whose name is identical to the leading
- directories of the executable's absolute file name.
-
- * For the "build ID" method, GDB looks in the `.build-id'
- subdirectory of the global debug directory for a file named
- `NN/NNNNNNNN.debug', where NN are the first 2 hex characters of
- the build ID bit string, and NNNNNNNN are the rest of the bit
- string. (Real build ID strings are 32 or more hex characters, not
- 10.)
-
- So, for example, suppose you ask GDB to debug `/usr/bin/ls', which
-has a debug link that specifies the file `ls.debug', and a build ID
-whose value in hex is `abcdef1234'. If the global debug directory is
-`/usr/lib/debug', then GDB will look for the following debug
-information files, in the indicated order:
-
- - `/usr/lib/debug/.build-id/ab/cdef1234.debug'
-
- - `/usr/bin/ls.debug'
-
- - `/usr/bin/.debug/ls.debug'
-
- - `/usr/lib/debug/usr/bin/ls.debug'.
-
- You can set the global debugging info directory's name, and view the
-name GDB is currently using.
-
-`set debug-file-directory DIRECTORIES'
- Set the directories which GDB searches for separate debugging
- information files to DIRECTORY. Multiple directory components can
- be set concatenating them by a directory separator.
-
-`show debug-file-directory'
- Show the directories GDB searches for separate debugging
- information files.
-
-
- A debug link is a special section of the executable file named
-`.gnu_debuglink'. The section must contain:
-
- * A filename, with any leading directory components removed,
- followed by a zero byte,
-
- * zero to three bytes of padding, as needed to reach the next
- four-byte boundary within the section, and
-
- * a four-byte CRC checksum, stored in the same endianness used for
- the executable file itself. The checksum is computed on the
- debugging information file's full contents by the function given
- below, passing zero as the CRC argument.
-
- Any executable file format can carry a debug link, as long as it can
-contain a section named `.gnu_debuglink' with the contents described
-above.
-
- The build ID is a special section in the executable file (and in
-other ELF binary files that GDB may consider). This section is often
-named `.note.gnu.build-id', but that name is not mandatory. It
-contains unique identification for the built files--the ID remains the
-same across multiple builds of the same build tree. The default
-algorithm SHA1 produces 160 bits (40 hexadecimal characters) of the
-content for the build ID string. The same section with an identical
-value is present in the original built binary with symbols, in its
-stripped variant, and in the separate debugging information file.
-
- The debugging information file itself should be an ordinary
-executable, containing a full set of linker symbols, sections, and
-debugging information. The sections of the debugging information file
-should have the same names, addresses, and sizes as the original file,
-but they need not contain any data--much like a `.bss' section in an
-ordinary executable.
-
- The GNU binary utilities (Binutils) package includes the `objcopy'
-utility that can produce the separated executable / debugging
-information file pairs using the following commands:
-
- objcopy --only-keep-debug foo foo.debug
- strip -g foo
-
-These commands remove the debugging information from the executable
-file `foo' and place it in the file `foo.debug'. You can use the
-first, second or both methods to link the two files:
-
- * The debug link method needs the following additional command to
- also leave behind a debug link in `foo':
-
- objcopy --add-gnu-debuglink=foo.debug foo
-
- Ulrich Drepper's `elfutils' package, starting with version 0.53,
- contains a version of the `strip' command such that the command
- `strip foo -f foo.debug' has the same functionality as the two
- `objcopy' commands and the `ln -s' command above, together.
-
- * Build ID gets embedded into the main executable using `ld
- --build-id' or the GCC counterpart `gcc -Wl,--build-id'. Build ID
- support plus compatibility fixes for debug files separation are
- present in GNU binary utilities (Binutils) package since version
- 2.18.
-
-The CRC used in `.gnu_debuglink' is the CRC-32 defined in IEEE 802.3
-using the polynomial:
-
- x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11
- + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1
-
- The function is computed byte at a time, taking the least
-significant bit of each byte first. The initial pattern `0xffffffff'
-is used, to ensure leading zeros affect the CRC and the final result is
-inverted to ensure trailing zeros also affect the CRC.
-
- _Note:_ This is the same CRC polynomial as used in handling the
-"Remote Serial Protocol" `qCRC' packet (*note GDB Remote Serial
-Protocol: Remote Protocol.). However in the case of the Remote Serial
-Protocol, the CRC is computed _most_ significant bit first, and the
-result is not inverted, so trailing zeros have no effect on the CRC
-value.
-
- To complete the description, we show below the code of the function
-which produces the CRC used in `.gnu_debuglink'. Inverting the
-initially supplied `crc' argument means that an initial call to this
-function passing in zero will start computing the CRC using
-`0xffffffff'.
-
- unsigned long
- gnu_debuglink_crc32 (unsigned long crc,
- unsigned char *buf, size_t len)
- {
- static const unsigned long crc32_table[256] =
- {
- 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419,
- 0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4,
- 0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07,
- 0x90bf1d91, 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
- 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 0x136c9856,
- 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9,
- 0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4,
- 0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
- 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3,
- 0x45df5c75, 0xdcd60dcf, 0xabd13d59, 0x26d930ac, 0x51de003a,
- 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599,
- 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
- 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190,
- 0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f,
- 0x9fbfe4a5, 0xe8b8d433, 0x7807c9a2, 0x0f00f934, 0x9609a88e,
- 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
- 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 0x6c0695ed,
- 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950,
- 0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3,
- 0xfbd44c65, 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
- 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a,
- 0x346ed9fc, 0xad678846, 0xda60b8d0, 0x44042d73, 0x33031de5,
- 0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c, 0x270241aa, 0xbe0b1010,
- 0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
- 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17,
- 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6,
- 0x03b6e20c, 0x74b1d29a, 0xead54739, 0x9dd277af, 0x04db2615,
- 0x73dc1683, 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
- 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, 0xf00f9344,
- 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb,
- 0x196c3671, 0x6e6b06e7, 0xfed41b76, 0x89d32be0, 0x10da7a5a,
- 0x67dd4acc, 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
- 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, 0xd1bb67f1,
- 0xa6bc5767, 0x3fb506dd, 0x48b2364b, 0xd80d2bda, 0xaf0a1b4c,
- 0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55, 0x316e8eef,
- 0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
- 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe,
- 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31,
- 0x2cd99e8b, 0x5bdeae1d, 0x9b64c2b0, 0xec63f226, 0x756aa39c,
- 0x026d930a, 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
- 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, 0x92d28e9b,
- 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 0x86d3d2d4, 0xf1d4e242,
- 0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1,
- 0x18b74777, 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
- 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, 0xa00ae278,
- 0xd70dd2ee, 0x4e048354, 0x3903b3c2, 0xa7672661, 0xd06016f7,
- 0x4969474d, 0x3e6e77db, 0xaed16a4a, 0xd9d65adc, 0x40df0b66,
- 0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
- 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605,
- 0xcdd70693, 0x54de5729, 0x23d967bf, 0xb3667a2e, 0xc4614ab8,
- 0x5d681b02, 0x2a6f2b94, 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b,
- 0x2d02ef8d
- };
- unsigned char *end;
-
- crc = ~crc & 0xffffffff;
- for (end = buf + len; buf < end; ++buf)
- crc = crc32_table[(crc ^ *buf) & 0xff] ^ (crc >> 8);
- return ~crc & 0xffffffff;
- }
-
-This computation does not apply to the "build ID" method.
-
-
-File: gdb.info, Node: Index Files, Next: Symbol Errors, Prev: Separate Debug Files, Up: GDB Files
-
-18.3 Index Files Speed Up GDB
-=============================
-
-When GDB finds a symbol file, it scans the symbols in the file in order
-to construct an internal symbol table. This lets most GDB operations
-work quickly--at the cost of a delay early on. For large programs,
-this delay can be quite lengthy, so GDB provides a way to build an
-index, which speeds up startup.
-
- The index is stored as a section in the symbol file. GDB can write
-the index to a file, then you can put it into the symbol file using
-`objcopy'.
-
- To create an index file, use the `save gdb-index' command:
-
-`save gdb-index DIRECTORY'
- Create an index file for each symbol file currently known by GDB.
- Each file is named after its corresponding symbol file, with
- `.gdb-index' appended, and is written into the given DIRECTORY.
-
- Once you have created an index file you can merge it into your symbol
-file, here named `symfile', using `objcopy':
-
- $ objcopy --add-section .gdb_index=symfile.gdb-index \
- --set-section-flags .gdb_index=readonly symfile symfile
-
- There are currently some limitation on indices. They only work when
-for DWARF debugging information, not stabs. And, they do not currently
-work for programs using Ada.
-
-
-File: gdb.info, Node: Symbol Errors, Next: Data Files, Prev: Index Files, Up: GDB Files
-
-18.4 Errors Reading Symbol Files
-================================
-
-While reading a symbol file, GDB occasionally encounters problems, such
-as symbol types it does not recognize, or known bugs in compiler
-output. By default, GDB does not notify you of such problems, since
-they are relatively common and primarily of interest to people
-debugging compilers. If you are interested in seeing information about
-ill-constructed symbol tables, you can either ask GDB to print only one
-message about each such type of problem, no matter how many times the
-problem occurs; or you can ask GDB to print more messages, to see how
-many times the problems occur, with the `set complaints' command (*note
-Optional Warnings and Messages: Messages/Warnings.).
-
- The messages currently printed, and their meanings, include:
-
-`inner block not inside outer block in SYMBOL'
- The symbol information shows where symbol scopes begin and end
- (such as at the start of a function or a block of statements).
- This error indicates that an inner scope block is not fully
- contained in its outer scope blocks.
-
- GDB circumvents the problem by treating the inner block as if it
- had the same scope as the outer block. In the error message,
- SYMBOL may be shown as "`(don't know)'" if the outer block is not a
- function.
-
-`block at ADDRESS out of order'
- The symbol information for symbol scope blocks should occur in
- order of increasing addresses. This error indicates that it does
- not do so.
-
- GDB does not circumvent this problem, and has trouble locating
- symbols in the source file whose symbols it is reading. (You can
- often determine what source file is affected by specifying `set
- verbose on'. *Note Optional Warnings and Messages:
- Messages/Warnings.)
-
-`bad block start address patched'
- The symbol information for a symbol scope block has a start address
- smaller than the address of the preceding source line. This is
- known to occur in the SunOS 4.1.1 (and earlier) C compiler.
-
- GDB circumvents the problem by treating the symbol scope block as
- starting on the previous source line.
-
-`bad string table offset in symbol N'
- Symbol number N contains a pointer into the string table which is
- larger than the size of the string table.
-
- GDB circumvents the problem by considering the symbol to have the
- name `foo', which may cause other problems if many symbols end up
- with this name.
-
-`unknown symbol type `0xNN''
- The symbol information contains new data types that GDB does not
- yet know how to read. `0xNN' is the symbol type of the
- uncomprehended information, in hexadecimal.
-
- GDB circumvents the error by ignoring this symbol information.
- This usually allows you to debug your program, though certain
- symbols are not accessible. If you encounter such a problem and
- feel like debugging it, you can debug `gdb' with itself, breakpoint
- on `complain', then go up to the function `read_dbx_symtab' and
- examine `*bufp' to see the symbol.
-
-`stub type has NULL name'
- GDB could not find the full definition for a struct or class.
-
-`const/volatile indicator missing (ok if using g++ v1.x), got...'
- The symbol information for a C++ member function is missing some
- information that recent versions of the compiler should have
- output for it.
-
-`info mismatch between compiler and debugger'
- GDB could not parse a type specification output by the compiler.
-
-
-
-File: gdb.info, Node: Data Files, Prev: Symbol Errors, Up: GDB Files
-
-18.5 GDB Data Files
-===================
-
-GDB will sometimes read an auxiliary data file. These files are kept
-in a directory known as the "data directory".
-
- You can set the data directory's name, and view the name GDB is
-currently using.
-
-`set data-directory DIRECTORY'
- Set the directory which GDB searches for auxiliary data files to
- DIRECTORY.
-
-`show data-directory'
- Show the directory GDB searches for auxiliary data files.
-
- You can set the default data directory by using the configure-time
-`--with-gdb-datadir' option. If the data directory is inside GDB's
-configured binary prefix (set with `--prefix' or `--exec-prefix'), then
-the default data directory will be updated automatically if the
-installed GDB is moved to a new location.
-
- The data directory may also be specified with the `--data-directory'
-command line option. *Note Mode Options::.
-
-
-File: gdb.info, Node: Targets, Next: Remote Debugging, Prev: GDB Files, Up: Top
-
-19 Specifying a Debugging Target
-********************************
-
-A "target" is the execution environment occupied by your program.
-
- Often, GDB runs in the same host environment as your program; in
-that case, the debugging target is specified as a side effect when you
-use the `file' or `core' commands. When you need more flexibility--for
-example, running GDB on a physically separate host, or controlling a
-standalone system over a serial port or a realtime system over a TCP/IP
-connection--you can use the `target' command to specify one of the
-target types configured for GDB (*note Commands for Managing Targets:
-Target Commands.).
-
- It is possible to build GDB for several different "target
-architectures". When GDB is built like that, you can choose one of the
-available architectures with the `set architecture' command.
-
-`set architecture ARCH'
- This command sets the current target architecture to ARCH. The
- value of ARCH can be `"auto"', in addition to one of the supported
- architectures.
-
-`show architecture'
- Show the current target architecture.
-
-`set processor'
-`processor'
- These are alias commands for, respectively, `set architecture' and
- `show architecture'.
-
-* Menu:
-
-* Active Targets:: Active targets
-* Target Commands:: Commands for managing targets
-* Byte Order:: Choosing target byte order
-
-
-File: gdb.info, Node: Active Targets, Next: Target Commands, Up: Targets
-
-19.1 Active Targets
-===================
-
-There are multiple classes of targets such as: processes, executable
-files or recording sessions. Core files belong to the process class,
-making core file and process mutually exclusive. Otherwise, GDB can
-work concurrently on multiple active targets, one in each class. This
-allows you to (for example) start a process and inspect its activity,
-while still having access to the executable file after the process
-finishes. Or if you start process recording (*note Reverse
-Execution::) and `reverse-step' there, you are presented a virtual
-layer of the recording target, while the process target remains stopped
-at the chronologically last point of the process execution.
-
- Use the `core-file' and `exec-file' commands to select a new core
-file or executable target (*note Commands to Specify Files: Files.). To
-specify as a target a process that is already running, use the `attach'
-command (*note Debugging an Already-running Process: Attach.).
-
-
-File: gdb.info, Node: Target Commands, Next: Byte Order, Prev: Active Targets, Up: Targets
-
-19.2 Commands for Managing Targets
-==================================
-
-`target TYPE PARAMETERS'
- Connects the GDB host environment to a target machine or process.
- A target is typically a protocol for talking to debugging
- facilities. You use the argument TYPE to specify the type or
- protocol of the target machine.
-
- Further PARAMETERS are interpreted by the target protocol, but
- typically include things like device names or host names to connect
- with, process numbers, and baud rates.
-
- The `target' command does not repeat if you press <RET> again
- after executing the command.
-
-`help target'
- Displays the names of all targets available. To display targets
- currently selected, use either `info target' or `info files'
- (*note Commands to Specify Files: Files.).
-
-`help target NAME'
- Describe a particular target, including any parameters necessary to
- select it.
-
-`set gnutarget ARGS'
- GDB uses its own library BFD to read your files. GDB knows
- whether it is reading an "executable", a "core", or a ".o" file;
- however, you can specify the file format with the `set gnutarget'
- command. Unlike most `target' commands, with `gnutarget' the
- `target' refers to a program, not a machine.
-
- _Warning:_ To specify a file format with `set gnutarget', you
- must know the actual BFD name.
-
- *Note Commands to Specify Files: Files.
-
-`show gnutarget'
- Use the `show gnutarget' command to display what file format
- `gnutarget' is set to read. If you have not set `gnutarget', GDB
- will determine the file format for each file automatically, and
- `show gnutarget' displays `The current BDF target is "auto"'.
-
- Here are some common targets (available, or not, depending on the GDB
-configuration):
-
-`target exec PROGRAM'
- An executable file. `target exec PROGRAM' is the same as
- `exec-file PROGRAM'.
-
-`target core FILENAME'
- A core dump file. `target core FILENAME' is the same as
- `core-file FILENAME'.
-
-`target remote MEDIUM'
- A remote system connected to GDB via a serial line or network
- connection. This command tells GDB to use its own remote protocol
- over MEDIUM for debugging. *Note Remote Debugging::.
-
- For example, if you have a board connected to `/dev/ttya' on the
- machine running GDB, you could say:
-
- target remote /dev/ttya
-
- `target remote' supports the `load' command. This is only useful
- if you have some other way of getting the stub to the target
- system, and you can put it somewhere in memory where it won't get
- clobbered by the download.
-
-`target sim [SIMARGS] ...'
- Builtin CPU simulator. GDB includes simulators for most
- architectures. In general,
- target sim
- load
- run
- works; however, you cannot assume that a specific memory map,
- device drivers, or even basic I/O is available, although some
- simulators do provide these. For info about any
- processor-specific simulator details, see the appropriate section
- in *note Embedded Processors: Embedded Processors.
-
-
- Some configurations may include these targets as well:
-
-`target nrom DEV'
- NetROM ROM emulator. This target only supports downloading.
-
-
- Different targets are available on different configurations of GDB;
-your configuration may have more or fewer targets.
-
- Many remote targets require you to download the executable's code
-once you've successfully established a connection. You may wish to
-control various aspects of this process.
-
-`set hash'
- This command controls whether a hash mark `#' is displayed while
- downloading a file to the remote monitor. If on, a hash mark is
- displayed after each S-record is successfully downloaded to the
- monitor.
-
-`show hash'
- Show the current status of displaying the hash mark.
-
-`set debug monitor'
- Enable or disable display of communications messages between GDB
- and the remote monitor.
-
-`show debug monitor'
- Show the current status of displaying communications between GDB
- and the remote monitor.
-
-`load FILENAME'
- Depending on what remote debugging facilities are configured into
- GDB, the `load' command may be available. Where it exists, it is
- meant to make FILENAME (an executable) available for debugging on
- the remote system--by downloading, or dynamic linking, for example.
- `load' also records the FILENAME symbol table in GDB, like the
- `add-symbol-file' command.
-
- If your GDB does not have a `load' command, attempting to execute
- it gets the error message "`You can't do that when your target is
- ...'"
-
- The file is loaded at whatever address is specified in the
- executable. For some object file formats, you can specify the
- load address when you link the program; for other formats, like
- a.out, the object file format specifies a fixed address.
-
- Depending on the remote side capabilities, GDB may be able to load
- programs into flash memory.
-
- `load' does not repeat if you press <RET> again after using it.
-
-
-File: gdb.info, Node: Byte Order, Prev: Target Commands, Up: Targets
-
-19.3 Choosing Target Byte Order
-===============================
-
-Some types of processors, such as the MIPS, PowerPC, and Renesas SH,
-offer the ability to run either big-endian or little-endian byte
-orders. Usually the executable or symbol will include a bit to
-designate the endian-ness, and you will not need to worry about which
-to use. However, you may still find it useful to adjust GDB's idea of
-processor endian-ness manually.
-
-`set endian big'
- Instruct GDB to assume the target is big-endian.
-
-`set endian little'
- Instruct GDB to assume the target is little-endian.
-
-`set endian auto'
- Instruct GDB to use the byte order associated with the executable.
-
-`show endian'
- Display GDB's current idea of the target byte order.
-
-
- Note that these commands merely adjust interpretation of symbolic
-data on the host, and that they have absolutely no effect on the target
-system.
-
-
-File: gdb.info, Node: Remote Debugging, Next: Configurations, Prev: Targets, Up: Top
-
-20 Debugging Remote Programs
-****************************
-
-If you are trying to debug a program running on a machine that cannot
-run GDB in the usual way, it is often useful to use remote debugging.
-For example, you might use remote debugging on an operating system
-kernel, or on a small system which does not have a general purpose
-operating system powerful enough to run a full-featured debugger.
-
- Some configurations of GDB have special serial or TCP/IP interfaces
-to make this work with particular debugging targets. In addition, GDB
-comes with a generic serial protocol (specific to GDB, but not specific
-to any particular target system) which you can use if you write the
-remote stubs--the code that runs on the remote system to communicate
-with GDB.
-
- Other remote targets may be available in your configuration of GDB;
-use `help target' to list them.
-
-* Menu:
-
-* Connecting:: Connecting to a remote target
-* File Transfer:: Sending files to a remote system
-* Server:: Using the gdbserver program
-* Remote Configuration:: Remote configuration
-* Remote Stub:: Implementing a remote stub
-
-
-File: gdb.info, Node: Connecting, Next: File Transfer, Up: Remote Debugging
-
-20.1 Connecting to a Remote Target
-==================================
-
-On the GDB host machine, you will need an unstripped copy of your
-program, since GDB needs symbol and debugging information. Start up
-GDB as usual, using the name of the local copy of your program as the
-first argument.
-
- GDB can communicate with the target over a serial line, or over an
-IP network using TCP or UDP. In each case, GDB uses the same protocol
-for debugging your program; only the medium carrying the debugging
-packets varies. The `target remote' command establishes a connection
-to the target. Its arguments indicate which medium to use:
-
-`target remote SERIAL-DEVICE'
- Use SERIAL-DEVICE to communicate with the target. For example, to
- use a serial line connected to the device named `/dev/ttyb':
-
- target remote /dev/ttyb
-
- If you're using a serial line, you may want to give GDB the
- `--baud' option, or use the `set remotebaud' command (*note set
- remotebaud: Remote Configuration.) before the `target' command.
-
-`target remote `HOST:PORT''
-`target remote `tcp:HOST:PORT''
- Debug using a TCP connection to PORT on HOST. The HOST may be
- either a host name or a numeric IP address; PORT must be a decimal
- number. The HOST could be the target machine itself, if it is
- directly connected to the net, or it might be a terminal server
- which in turn has a serial line to the target.
-
- For example, to connect to port 2828 on a terminal server named
- `manyfarms':
-
- target remote manyfarms:2828
-
- If your remote target is actually running on the same machine as
- your debugger session (e.g. a simulator for your target running on
- the same host), you can omit the hostname. For example, to
- connect to port 1234 on your local machine:
-
- target remote :1234
- Note that the colon is still required here.
-
-`target remote `udp:HOST:PORT''
- Debug using UDP packets to PORT on HOST. For example, to connect
- to UDP port 2828 on a terminal server named `manyfarms':
-
- target remote udp:manyfarms:2828
-
- When using a UDP connection for remote debugging, you should keep
- in mind that the `U' stands for "Unreliable". UDP can silently
- drop packets on busy or unreliable networks, which will cause
- havoc with your debugging session.
-
-`target remote | COMMAND'
- Run COMMAND in the background and communicate with it using a
- pipe. The COMMAND is a shell command, to be parsed and expanded
- by the system's command shell, `/bin/sh'; it should expect remote
- protocol packets on its standard input, and send replies on its
- standard output. You could use this to run a stand-alone simulator
- that speaks the remote debugging protocol, to make net connections
- using programs like `ssh', or for other similar tricks.
-
- If COMMAND closes its standard output (perhaps by exiting), GDB
- will try to send it a `SIGTERM' signal. (If the program has
- already exited, this will have no effect.)
-
-
- Once the connection has been established, you can use all the usual
-commands to examine and change data. The remote program is already
-running; you can use `step' and `continue', and you do not need to use
-`run'.
-
- Whenever GDB is waiting for the remote program, if you type the
-interrupt character (often `Ctrl-c'), GDB attempts to stop the program.
-This may or may not succeed, depending in part on the hardware and the
-serial drivers the remote system uses. If you type the interrupt
-character once again, GDB displays this prompt:
-
- Interrupted while waiting for the program.
- Give up (and stop debugging it)? (y or n)
-
- If you type `y', GDB abandons the remote debugging session. (If you
-decide you want to try again later, you can use `target remote' again
-to connect once more.) If you type `n', GDB goes back to waiting.
-
-`detach'
- When you have finished debugging the remote program, you can use
- the `detach' command to release it from GDB control. Detaching
- from the target normally resumes its execution, but the results
- will depend on your particular remote stub. After the `detach'
- command, GDB is free to connect to another target.
-
-`disconnect'
- The `disconnect' command behaves like `detach', except that the
- target is generally not resumed. It will wait for GDB (this
- instance or another one) to connect and continue debugging. After
- the `disconnect' command, GDB is again free to connect to another
- target.
-
-`monitor CMD'
- This command allows you to send arbitrary commands directly to the
- remote monitor. Since GDB doesn't care about the commands it
- sends like this, this command is the way to extend GDB--you can
- add new commands that only the external monitor will understand
- and implement.
-
-
-File: gdb.info, Node: File Transfer, Next: Server, Prev: Connecting, Up: Remote Debugging
-
-20.2 Sending files to a remote system
-=====================================
-
-Some remote targets offer the ability to transfer files over the same
-connection used to communicate with GDB. This is convenient for
-targets accessible through other means, e.g. GNU/Linux systems running
-`gdbserver' over a network interface. For other targets, e.g. embedded
-devices with only a single serial port, this may be the only way to
-upload or download files.
-
- Not all remote targets support these commands.
-
-`remote put HOSTFILE TARGETFILE'
- Copy file HOSTFILE from the host system (the machine running GDB)
- to TARGETFILE on the target system.
-
-`remote get TARGETFILE HOSTFILE'
- Copy file TARGETFILE from the target system to HOSTFILE on the
- host system.
-
-`remote delete TARGETFILE'
- Delete TARGETFILE from the target system.
-
-
-
-File: gdb.info, Node: Server, Next: Remote Configuration, Prev: File Transfer, Up: Remote Debugging
-
-20.3 Using the `gdbserver' Program
-==================================
-
-`gdbserver' is a control program for Unix-like systems, which allows
-you to connect your program with a remote GDB via `target remote'--but
-without linking in the usual debugging stub.
-
- `gdbserver' is not a complete replacement for the debugging stubs,
-because it requires essentially the same operating-system facilities
-that GDB itself does. In fact, a system that can run `gdbserver' to
-connect to a remote GDB could also run GDB locally! `gdbserver' is
-sometimes useful nevertheless, because it is a much smaller program
-than GDB itself. It is also easier to port than all of GDB, so you may
-be able to get started more quickly on a new system by using
-`gdbserver'. Finally, if you develop code for real-time systems, you
-may find that the tradeoffs involved in real-time operation make it
-more convenient to do as much development work as possible on another
-system, for example by cross-compiling. You can use `gdbserver' to
-make a similar choice for debugging.
-
- GDB and `gdbserver' communicate via either a serial line or a TCP
-connection, using the standard GDB remote serial protocol.
-
- _Warning:_ `gdbserver' does not have any built-in security. Do
- not run `gdbserver' connected to any public network; a GDB
- connection to `gdbserver' provides access to the target system
- with the same privileges as the user running `gdbserver'.
-
-20.3.1 Running `gdbserver'
---------------------------
-
-Run `gdbserver' on the target system. You need a copy of the program
-you want to debug, including any libraries it requires. `gdbserver'
-does not need your program's symbol table, so you can strip the program
-if necessary to save space. GDB on the host system does all the symbol
-handling.
-
- To use the server, you must tell it how to communicate with GDB; the
-name of your program; and the arguments for your program. The usual
-syntax is:
-
- target> gdbserver COMM PROGRAM [ ARGS ... ]
-
- COMM is either a device name (to use a serial line) or a TCP
-hostname and portnumber. For example, to debug Emacs with the argument
-`foo.txt' and communicate with GDB over the serial port `/dev/com1':
-
- target> gdbserver /dev/com1 emacs foo.txt
-
- `gdbserver' waits passively for the host GDB to communicate with it.
-
- To use a TCP connection instead of a serial line:
-
- target> gdbserver host:2345 emacs foo.txt
-
- The only difference from the previous example is the first argument,
-specifying that you are communicating with the host GDB via TCP. The
-`host:2345' argument means that `gdbserver' is to expect a TCP
-connection from machine `host' to local TCP port 2345. (Currently, the
-`host' part is ignored.) You can choose any number you want for the
-port number as long as it does not conflict with any TCP ports already
-in use on the target system (for example, `23' is reserved for
-`telnet').(1) You must use the same port number with the host GDB
-`target remote' command.
-
-20.3.1.1 Attaching to a Running Program
-.......................................
-
-On some targets, `gdbserver' can also attach to running programs. This
-is accomplished via the `--attach' argument. The syntax is:
-
- target> gdbserver --attach COMM PID
-
- PID is the process ID of a currently running process. It isn't
-necessary to point `gdbserver' at a binary for the running process.
-
- You can debug processes by name instead of process ID if your target
-has the `pidof' utility:
-
- target> gdbserver --attach COMM `pidof PROGRAM`
-
- In case more than one copy of PROGRAM is running, or PROGRAM has
-multiple threads, most versions of `pidof' support the `-s' option to
-only return the first process ID.
-
-20.3.1.2 Multi-Process Mode for `gdbserver'
-...........................................
-
-When you connect to `gdbserver' using `target remote', `gdbserver'
-debugs the specified program only once. When the program exits, or you
-detach from it, GDB closes the connection and `gdbserver' exits.
-
- If you connect using `target extended-remote', `gdbserver' enters
-multi-process mode. When the debugged program exits, or you detach
-from it, GDB stays connected to `gdbserver' even though no program is
-running. The `run' and `attach' commands instruct `gdbserver' to run
-or attach to a new program. The `run' command uses `set remote
-exec-file' (*note set remote exec-file::) to select the program to run.
-Command line arguments are supported, except for wildcard expansion and
-I/O redirection (*note Arguments::).
-
- To start `gdbserver' without supplying an initial command to run or
-process ID to attach, use the `--multi' command line option. Then you
-can connect using `target extended-remote' and start the program you
-want to debug.
-
- `gdbserver' does not automatically exit in multi-process mode. You
-can terminate it by using `monitor exit' (*note Monitor Commands for
-gdbserver::).
-
-20.3.1.3 Other Command-Line Arguments for `gdbserver'
-.....................................................
-
-The `--debug' option tells `gdbserver' to display extra status
-information about the debugging process. The `--remote-debug' option
-tells `gdbserver' to display remote protocol debug output. These
-options are intended for `gdbserver' development and for bug reports to
-the developers.
-
- The `--wrapper' option specifies a wrapper to launch programs for
-debugging. The option should be followed by the name of the wrapper,
-then any command-line arguments to pass to the wrapper, then `--'
-indicating the end of the wrapper arguments.
-
- `gdbserver' runs the specified wrapper program with a combined
-command line including the wrapper arguments, then the name of the
-program to debug, then any arguments to the program. The wrapper runs
-until it executes your program, and then GDB gains control.
-
- You can use any program that eventually calls `execve' with its
-arguments as a wrapper. Several standard Unix utilities do this, e.g.
-`env' and `nohup'. Any Unix shell script ending with `exec "$@"' will
-also work.
-
- For example, you can use `env' to pass an environment variable to
-the debugged program, without setting the variable in `gdbserver''s
-environment:
-
- $ gdbserver --wrapper env LD_PRELOAD=libtest.so -- :2222 ./testprog
-
-20.3.2 Connecting to `gdbserver'
---------------------------------
-
-Run GDB on the host system.
-
- First make sure you have the necessary symbol files. Load symbols
-for your application using the `file' command before you connect. Use
-`set sysroot' to locate target libraries (unless your GDB was compiled
-with the correct sysroot using `--with-sysroot').
-
- The symbol file and target libraries must exactly match the
-executable and libraries on the target, with one exception: the files
-on the host system should not be stripped, even if the files on the
-target system are. Mismatched or missing files will lead to confusing
-results during debugging. On GNU/Linux targets, mismatched or missing
-files may also prevent `gdbserver' from debugging multi-threaded
-programs.
-
- Connect to your target (*note Connecting to a Remote Target:
-Connecting.). For TCP connections, you must start up `gdbserver' prior
-to using the `target remote' command. Otherwise you may get an error
-whose text depends on the host system, but which usually looks
-something like `Connection refused'. Don't use the `load' command in
-GDB when using `gdbserver', since the program is already on the target.
-
-20.3.3 Monitor Commands for `gdbserver'
----------------------------------------
-
-During a GDB session using `gdbserver', you can use the `monitor'
-command to send special requests to `gdbserver'. Here are the
-available commands.
-
-`monitor help'
- List the available monitor commands.
-
-`monitor set debug 0'
-`monitor set debug 1'
- Disable or enable general debugging messages.
-
-`monitor set remote-debug 0'
-`monitor set remote-debug 1'
- Disable or enable specific debugging messages associated with the
- remote protocol (*note Remote Protocol::).
-
-`monitor set libthread-db-search-path [PATH]'
- When this command is issued, PATH is a colon-separated list of
- directories to search for `libthread_db' (*note set
- libthread-db-search-path: Threads.). If you omit PATH,
- `libthread-db-search-path' will be reset to its default value.
-
- The special entry `$pdir' for `libthread-db-search-path' is not
- supported in `gdbserver'.
-
-`monitor exit'
- Tell gdbserver to exit immediately. This command should be
- followed by `disconnect' to close the debugging session.
- `gdbserver' will detach from any attached processes and kill any
- processes it created. Use `monitor exit' to terminate `gdbserver'
- at the end of a multi-process mode debug session.
-
-
-20.3.4 Tracepoints support in `gdbserver'
------------------------------------------
-
-On some targets, `gdbserver' supports tracepoints, fast tracepoints and
-static tracepoints.
-
- For fast or static tracepoints to work, a special library called the
-"in-process agent" (IPA), must be loaded in the inferior process. This
-library is built and distributed as an integral part of `gdbserver'.
-In addition, support for static tracepoints requires building the
-in-process agent library with static tracepoints support. At present,
-the UST (LTTng Userspace Tracer, `http://lttng.org/ust') tracing engine
-is supported. This support is automatically available if UST
-development headers are found in the standard include path when
-`gdbserver' is built, or if `gdbserver' was explicitly configured using
-`--with-ust' to point at such headers. You can explicitly disable the
-support using `--with-ust=no'.
-
- There are several ways to load the in-process agent in your program:
-
-`Specifying it as dependency at link time'
- You can link your program dynamically with the in-process agent
- library. On most systems, this is accomplished by adding
- `-linproctrace' to the link command.
-
-`Using the system's preloading mechanisms'
- You can force loading the in-process agent at startup time by using
- your system's support for preloading shared libraries. Many Unixes
- support the concept of preloading user defined libraries. In most
- cases, you do that by specifying `LD_PRELOAD=libinproctrace.so' in
- the environment. See also the description of `gdbserver''s
- `--wrapper' command line option.
-
-`Using GDB to force loading the agent at run time'
- On some systems, you can force the inferior to load a shared
- library, by calling a dynamic loader function in the inferior that
- takes care of dynamically looking up and loading a shared library.
- On most Unix systems, the function is `dlopen'. You'll use the
- `call' command for that. For example:
-
- (gdb) call dlopen ("libinproctrace.so", ...)
-
- Note that on most Unix systems, for the `dlopen' function to be
- available, the program needs to be linked with `-ldl'.
-
- On systems that have a userspace dynamic loader, like most Unix
-systems, when you connect to `gdbserver' using `target remote', you'll
-find that the program is stopped at the dynamic loader's entry point,
-and no shared library has been loaded in the program's address space
-yet, including the in-process agent. In that case, before being able
-to use any of the fast or static tracepoints features, you need to let
-the loader run and load the shared libraries. The simplest way to do
-that is to run the program to the main procedure. E.g., if debugging a
-C or C++ program, start `gdbserver' like so:
-
- $ gdbserver :9999 myprogram
-
- Start GDB and connect to `gdbserver' like so, and run to main:
-
- $ gdb myprogram
- (gdb) target remote myhost:9999
- 0x00007f215893ba60 in ?? () from /lib64/ld-linux-x86-64.so.2
- (gdb) b main
- (gdb) continue
-
- The in-process tracing agent library should now be loaded into the
-process; you can confirm it with the `info sharedlibrary' command,
-which will list `libinproctrace.so' as loaded in the process. You are
-now ready to install fast tracepoints, list static tracepoint markers,
-probe static tracepoints markers, and start tracing.
-
- ---------- Footnotes ----------
-
- (1) If you choose a port number that conflicts with another service,
-`gdbserver' prints an error message and exits.
-
-
-File: gdb.info, Node: Remote Configuration, Next: Remote Stub, Prev: Server, Up: Remote Debugging
-
-20.4 Remote Configuration
-=========================
-
-This section documents the configuration options available when
-debugging remote programs. For the options related to the File I/O
-extensions of the remote protocol, see *note system-call-allowed:
-system.
-
-`set remoteaddresssize BITS'
- Set the maximum size of address in a memory packet to the specified
- number of bits. GDB will mask off the address bits above that
- number, when it passes addresses to the remote target. The
- default value is the number of bits in the target's address.
-
-`show remoteaddresssize'
- Show the current value of remote address size in bits.
-
-`set remotebaud N'
- Set the baud rate for the remote serial I/O to N baud. The value
- is used to set the speed of the serial port used for debugging
- remote targets.
-
-`show remotebaud'
- Show the current speed of the remote connection.
-
-`set remotebreak'
- If set to on, GDB sends a `BREAK' signal to the remote when you
- type `Ctrl-c' to interrupt the program running on the remote. If
- set to off, GDB sends the `Ctrl-C' character instead. The default
- is off, since most remote systems expect to see `Ctrl-C' as the
- interrupt signal.
-
-`show remotebreak'
- Show whether GDB sends `BREAK' or `Ctrl-C' to interrupt the remote
- program.
-
-`set remoteflow on'
-`set remoteflow off'
- Enable or disable hardware flow control (`RTS'/`CTS') on the
- serial port used to communicate to the remote target.
-
-`show remoteflow'
- Show the current setting of hardware flow control.
-
-`set remotelogbase BASE'
- Set the base (a.k.a. radix) of logging serial protocol
- communications to BASE. Supported values of BASE are: `ascii',
- `octal', and `hex'. The default is `ascii'.
-
-`show remotelogbase'
- Show the current setting of the radix for logging remote serial
- protocol.
-
-`set remotelogfile FILE'
- Record remote serial communications on the named FILE. The
- default is not to record at all.
-
-`show remotelogfile.'
- Show the current setting of the file name on which to record the
- serial communications.
-
-`set remotetimeout NUM'
- Set the timeout limit to wait for the remote target to respond to
- NUM seconds. The default is 2 seconds.
-
-`show remotetimeout'
- Show the current number of seconds to wait for the remote target
- responses.
-
-`set remote hardware-watchpoint-limit LIMIT'
-`set remote hardware-breakpoint-limit LIMIT'
- Restrict GDB to using LIMIT remote hardware breakpoint or
- watchpoints. A limit of -1, the default, is treated as unlimited.
-
-`set remote exec-file FILENAME'
-`show remote exec-file'
- Select the file used for `run' with `target extended-remote'.
- This should be set to a filename valid on the target system. If
- it is not set, the target will use a default filename (e.g. the
- last program run).
-
-`set remote interrupt-sequence'
- Allow the user to select one of `Ctrl-C', a `BREAK' or `BREAK-g'
- as the sequence to the remote target in order to interrupt the
- execution. `Ctrl-C' is a default. Some system prefers `BREAK'
- which is high level of serial line for some certain time. Linux
- kernel prefers `BREAK-g', a.k.a Magic SysRq g. It is `BREAK'
- signal followed by character `g'.
-
-`show interrupt-sequence'
- Show which of `Ctrl-C', `BREAK' or `BREAK-g' is sent by GDB to
- interrupt the remote program. `BREAK-g' is BREAK signal followed
- by `g' and also known as Magic SysRq g.
-
-`set remote interrupt-on-connect'
- Specify whether interrupt-sequence is sent to remote target when
- GDB connects to it. This is mostly needed when you debug Linux
- kernel. Linux kernel expects `BREAK' followed by `g' which is
- known as Magic SysRq g in order to connect GDB.
-
-`show interrupt-on-connect'
- Show whether interrupt-sequence is sent to remote target when GDB
- connects to it.
-
-`set tcp auto-retry on'
- Enable auto-retry for remote TCP connections. This is useful if
- the remote debugging agent is launched in parallel with GDB; there
- is a race condition because the agent may not become ready to
- accept the connection before GDB attempts to connect. When
- auto-retry is enabled, if the initial attempt to connect fails,
- GDB reattempts to establish the connection using the timeout
- specified by `set tcp connect-timeout'.
-
-`set tcp auto-retry off'
- Do not auto-retry failed TCP connections.
-
-`show tcp auto-retry'
- Show the current auto-retry setting.
-
-`set tcp connect-timeout SECONDS'
- Set the timeout for establishing a TCP connection to the remote
- target to SECONDS. The timeout affects both polling to retry
- failed connections (enabled by `set tcp auto-retry on') and
- waiting for connections that are merely slow to complete, and
- represents an approximate cumulative value.
-
-`show tcp connect-timeout'
- Show the current connection timeout setting.
-
- The GDB remote protocol autodetects the packets supported by your
-debugging stub. If you need to override the autodetection, you can use
-these commands to enable or disable individual packets. Each packet
-can be set to `on' (the remote target supports this packet), `off' (the
-remote target does not support this packet), or `auto' (detect remote
-target support for this packet). They all default to `auto'. For more
-information about each packet, see *note Remote Protocol::.
-
- During normal use, you should not have to use any of these commands.
-If you do, that may be a bug in your remote debugging stub, or a bug in
-GDB. You may want to report the problem to the GDB developers.
-
- For each packet NAME, the command to enable or disable the packet is
-`set remote NAME-packet'. The available settings are:
-
-Command Name Remote Packet Related Features
-`fetch-register' `p' `info registers'
-`set-register' `P' `set'
-`binary-download' `X' `load', `set'
-`read-aux-vector' `qXfer:auxv:read' `info auxv'
-`symbol-lookup' `qSymbol' Detecting
- multiple threads
-`attach' `vAttach' `attach'
-`verbose-resume' `vCont' Stepping or
- resuming multiple
- threads
-`run' `vRun' `run'
-`software-breakpoint'`Z0' `break'
-`hardware-breakpoint'`Z1' `hbreak'
-`write-watchpoint' `Z2' `watch'
-`read-watchpoint' `Z3' `rwatch'
-`access-watchpoint' `Z4' `awatch'
-`target-features' `qXfer:features:read' `set architecture'
-`library-info' `qXfer:libraries:read' `info
- sharedlibrary'
-`memory-map' `qXfer:memory-map:read' `info mem'
-`read-sdata-object' `qXfer:sdata:read' `print $_sdata'
-`read-spu-object' `qXfer:spu:read' `info spu'
-`write-spu-object' `qXfer:spu:write' `info spu'
-`read-siginfo-object'`qXfer:siginfo:read' `print $_siginfo'
-`write-siginfo-object'`qXfer:siginfo:write' `set $_siginfo'
-`threads' `qXfer:threads:read' `info threads'
-`get-thread-local- `qGetTLSAddr' Displaying
-storage-address' `__thread'
- variables
-`get-thread-information-block-address'`qGetTIBAddr' Display
- MS-Windows Thread
- Information Block.
-`search-memory' `qSearch:memory' `find'
-`supported-packets' `qSupported' Remote
- communications
- parameters
-`pass-signals' `QPassSignals' `handle SIGNAL'
-`hostio-close-packet'`vFile:close' `remote get',
- `remote put'
-`hostio-open-packet' `vFile:open' `remote get',
- `remote put'
-`hostio-pread-packet'`vFile:pread' `remote get',
- `remote put'
-`hostio-pwrite-packet'`vFile:pwrite' `remote get',
- `remote put'
-`hostio-unlink-packet'`vFile:unlink' `remote delete'
-`noack-packet' `QStartNoAckMode' Packet
- acknowledgment
-`osdata' `qXfer:osdata:read' `info os'
-`query-attached' `qAttached' Querying remote
- process attach
- state.
-`traceframe-info' `qXfer:traceframe-info:read'Traceframe info
-
-
-File: gdb.info, Node: Remote Stub, Prev: Remote Configuration, Up: Remote Debugging
-
-20.5 Implementing a Remote Stub
-===============================
-
-The stub files provided with GDB implement the target side of the
-communication protocol, and the GDB side is implemented in the GDB
-source file `remote.c'. Normally, you can simply allow these
-subroutines to communicate, and ignore the details. (If you're
-implementing your own stub file, you can still ignore the details: start
-with one of the existing stub files. `sparc-stub.c' is the best
-organized, and therefore the easiest to read.)
-
- To debug a program running on another machine (the debugging
-"target" machine), you must first arrange for all the usual
-prerequisites for the program to run by itself. For example, for a C
-program, you need:
-
- 1. A startup routine to set up the C runtime environment; these
- usually have a name like `crt0'. The startup routine may be
- supplied by your hardware supplier, or you may have to write your
- own.
-
- 2. A C subroutine library to support your program's subroutine calls,
- notably managing input and output.
-
- 3. A way of getting your program to the other machine--for example, a
- download program. These are often supplied by the hardware
- manufacturer, but you may have to write your own from hardware
- documentation.
-
- The next step is to arrange for your program to use a serial port to
-communicate with the machine where GDB is running (the "host" machine).
-In general terms, the scheme looks like this:
-
-_On the host,_
- GDB already understands how to use this protocol; when everything
- else is set up, you can simply use the `target remote' command
- (*note Specifying a Debugging Target: Targets.).
-
-_On the target,_
- you must link with your program a few special-purpose subroutines
- that implement the GDB remote serial protocol. The file
- containing these subroutines is called a "debugging stub".
-
- On certain remote targets, you can use an auxiliary program
- `gdbserver' instead of linking a stub into your program. *Note
- Using the `gdbserver' Program: Server, for details.
-
- The debugging stub is specific to the architecture of the remote
-machine; for example, use `sparc-stub.c' to debug programs on SPARC
-boards.
-
- These working remote stubs are distributed with GDB:
-
-`i386-stub.c'
- For Intel 386 and compatible architectures.
-
-`m68k-stub.c'
- For Motorola 680x0 architectures.
-
-`sh-stub.c'
- For Renesas SH architectures.
-
-`sparc-stub.c'
- For SPARC architectures.
-
-`sparcl-stub.c'
- For Fujitsu SPARCLITE architectures.
-
-
- The `README' file in the GDB distribution may list other recently
-added stubs.
-
-* Menu:
-
-* Stub Contents:: What the stub can do for you
-* Bootstrapping:: What you must do for the stub
-* Debug Session:: Putting it all together
-
-
-File: gdb.info, Node: Stub Contents, Next: Bootstrapping, Up: Remote Stub
-
-20.5.1 What the Stub Can Do for You
------------------------------------
-
-The debugging stub for your architecture supplies these three
-subroutines:
-
-`set_debug_traps'
- This routine arranges for `handle_exception' to run when your
- program stops. You must call this subroutine explicitly near the
- beginning of your program.
-
-`handle_exception'
- This is the central workhorse, but your program never calls it
- explicitly--the setup code arranges for `handle_exception' to run
- when a trap is triggered.
-
- `handle_exception' takes control when your program stops during
- execution (for example, on a breakpoint), and mediates
- communications with GDB on the host machine. This is where the
- communications protocol is implemented; `handle_exception' acts as
- the GDB representative on the target machine. It begins by
- sending summary information on the state of your program, then
- continues to execute, retrieving and transmitting any information
- GDB needs, until you execute a GDB command that makes your program
- resume; at that point, `handle_exception' returns control to your
- own code on the target machine.
-
-`breakpoint'
- Use this auxiliary subroutine to make your program contain a
- breakpoint. Depending on the particular situation, this may be
- the only way for GDB to get control. For instance, if your target
- machine has some sort of interrupt button, you won't need to call
- this; pressing the interrupt button transfers control to
- `handle_exception'--in effect, to GDB. On some machines, simply
- receiving characters on the serial port may also trigger a trap;
- again, in that situation, you don't need to call `breakpoint' from
- your own program--simply running `target remote' from the host GDB
- session gets control.
-
- Call `breakpoint' if none of these is true, or if you simply want
- to make certain your program stops at a predetermined point for the
- start of your debugging session.
-
-
-File: gdb.info, Node: Bootstrapping, Next: Debug Session, Prev: Stub Contents, Up: Remote Stub
-
-20.5.2 What You Must Do for the Stub
-------------------------------------
-
-The debugging stubs that come with GDB are set up for a particular chip
-architecture, but they have no information about the rest of your
-debugging target machine.
-
- First of all you need to tell the stub how to communicate with the
-serial port.
-
-`int getDebugChar()'
- Write this subroutine to read a single character from the serial
- port. It may be identical to `getchar' for your target system; a
- different name is used to allow you to distinguish the two if you
- wish.
-
-`void putDebugChar(int)'
- Write this subroutine to write a single character to the serial
- port. It may be identical to `putchar' for your target system; a
- different name is used to allow you to distinguish the two if you
- wish.
-
- If you want GDB to be able to stop your program while it is running,
-you need to use an interrupt-driven serial driver, and arrange for it
-to stop when it receives a `^C' (`\003', the control-C character).
-That is the character which GDB uses to tell the remote system to stop.
-
- Getting the debugging target to return the proper status to GDB
-probably requires changes to the standard stub; one quick and dirty way
-is to just execute a breakpoint instruction (the "dirty" part is that
-GDB reports a `SIGTRAP' instead of a `SIGINT').
-
- Other routines you need to supply are:
-
-`void exceptionHandler (int EXCEPTION_NUMBER, void *EXCEPTION_ADDRESS)'
- Write this function to install EXCEPTION_ADDRESS in the exception
- handling tables. You need to do this because the stub does not
- have any way of knowing what the exception handling tables on your
- target system are like (for example, the processor's table might
- be in ROM, containing entries which point to a table in RAM).
- EXCEPTION_NUMBER is the exception number which should be changed;
- its meaning is architecture-dependent (for example, different
- numbers might represent divide by zero, misaligned access, etc).
- When this exception occurs, control should be transferred directly
- to EXCEPTION_ADDRESS, and the processor state (stack, registers,
- and so on) should be just as it is when a processor exception
- occurs. So if you want to use a jump instruction to reach
- EXCEPTION_ADDRESS, it should be a simple jump, not a jump to
- subroutine.
-
- For the 386, EXCEPTION_ADDRESS should be installed as an interrupt
- gate so that interrupts are masked while the handler runs. The
- gate should be at privilege level 0 (the most privileged level).
- The SPARC and 68k stubs are able to mask interrupts themselves
- without help from `exceptionHandler'.
-
-`void flush_i_cache()'
- On SPARC and SPARCLITE only, write this subroutine to flush the
- instruction cache, if any, on your target machine. If there is no
- instruction cache, this subroutine may be a no-op.
-
- On target machines that have instruction caches, GDB requires this
- function to make certain that the state of your program is stable.
-
-You must also make sure this library routine is available:
-
-`void *memset(void *, int, int)'
- This is the standard library function `memset' that sets an area of
- memory to a known value. If you have one of the free versions of
- `libc.a', `memset' can be found there; otherwise, you must either
- obtain it from your hardware manufacturer, or write your own.
-
- If you do not use the GNU C compiler, you may need other standard
-library subroutines as well; this varies from one stub to another, but
-in general the stubs are likely to use any of the common library
-subroutines which `GCC' generates as inline code.
-
-
-File: gdb.info, Node: Debug Session, Prev: Bootstrapping, Up: Remote Stub
-
-20.5.3 Putting it All Together
-------------------------------
-
-In summary, when your program is ready to debug, you must follow these
-steps.
-
- 1. Make sure you have defined the supporting low-level routines
- (*note What You Must Do for the Stub: Bootstrapping.):
- `getDebugChar', `putDebugChar',
- `flush_i_cache', `memset', `exceptionHandler'.
-
- 2. Insert these lines near the top of your program:
-
- set_debug_traps();
- breakpoint();
-
- 3. For the 680x0 stub only, you need to provide a variable called
- `exceptionHook'. Normally you just use:
-
- void (*exceptionHook)() = 0;
-
- but if before calling `set_debug_traps', you set it to point to a
- function in your program, that function is called when `GDB'
- continues after stopping on a trap (for example, bus error). The
- function indicated by `exceptionHook' is called with one
- parameter: an `int' which is the exception number.
-
- 4. Compile and link together: your program, the GDB debugging stub for
- your target architecture, and the supporting subroutines.
-
- 5. Make sure you have a serial connection between your target machine
- and the GDB host, and identify the serial port on the host.
-
- 6. Download your program to your target machine (or get it there by
- whatever means the manufacturer provides), and start it.
-
- 7. Start GDB on the host, and connect to the target (*note Connecting
- to a Remote Target: Connecting.).
-
-
-
-File: gdb.info, Node: Configurations, Next: Controlling GDB, Prev: Remote Debugging, Up: Top
-
-21 Configuration-Specific Information
-*************************************
-
-While nearly all GDB commands are available for all native and cross
-versions of the debugger, there are some exceptions. This chapter
-describes things that are only available in certain configurations.
-
- There are three major categories of configurations: native
-configurations, where the host and target are the same, embedded
-operating system configurations, which are usually the same for several
-different processor architectures, and bare embedded processors, which
-are quite different from each other.
-
-* Menu:
-
-* Native::
-* Embedded OS::
-* Embedded Processors::
-* Architectures::
-
-
-File: gdb.info, Node: Native, Next: Embedded OS, Up: Configurations
-
-21.1 Native
-===========
-
-This section describes details specific to particular native
-configurations.
-
-* Menu:
-
-* HP-UX:: HP-UX
-* BSD libkvm Interface:: Debugging BSD kernel memory images
-* SVR4 Process Information:: SVR4 process information
-* DJGPP Native:: Features specific to the DJGPP port
-* Cygwin Native:: Features specific to the Cygwin port
-* Hurd Native:: Features specific to GNU Hurd
-* Neutrino:: Features specific to QNX Neutrino
-* Darwin:: Features specific to Darwin
-
-
-File: gdb.info, Node: HP-UX, Next: BSD libkvm Interface, Up: Native
-
-21.1.1 HP-UX
-------------
-
-On HP-UX systems, if you refer to a function or variable name that
-begins with a dollar sign, GDB searches for a user or system name
-first, before it searches for a convenience variable.
-
-
-File: gdb.info, Node: BSD libkvm Interface, Next: SVR4 Process Information, Prev: HP-UX, Up: Native
-
-21.1.2 BSD libkvm Interface
----------------------------
-
-BSD-derived systems (FreeBSD/NetBSD/OpenBSD) have a kernel memory
-interface that provides a uniform interface for accessing kernel virtual
-memory images, including live systems and crash dumps. GDB uses this
-interface to allow you to debug live kernels and kernel crash dumps on
-many native BSD configurations. This is implemented as a special `kvm'
-debugging target. For debugging a live system, load the currently
-running kernel into GDB and connect to the `kvm' target:
-
- (gdb) target kvm
-
- For debugging crash dumps, provide the file name of the crash dump
-as an argument:
-
- (gdb) target kvm /var/crash/bsd.0
-
- Once connected to the `kvm' target, the following commands are
-available:
-
-`kvm pcb'
- Set current context from the "Process Control Block" (PCB) address.
-
-`kvm proc'
- Set current context from proc address. This command isn't
- available on modern FreeBSD systems.
-
-
-File: gdb.info, Node: SVR4 Process Information, Next: DJGPP Native, Prev: BSD libkvm Interface, Up: Native
-
-21.1.3 SVR4 Process Information
--------------------------------
-
-Many versions of SVR4 and compatible systems provide a facility called
-`/proc' that can be used to examine the image of a running process
-using file-system subroutines. If GDB is configured for an operating
-system with this facility, the command `info proc' is available to
-report information about the process running your program, or about any
-process running on your system. `info proc' works only on SVR4 systems
-that include the `procfs' code. This includes, as of this writing,
-GNU/Linux, OSF/1 (Digital Unix), Solaris, Irix, and Unixware, but not
-HP-UX, for example.
-
-`info proc'
-`info proc PROCESS-ID'
- Summarize available information about any running process. If a
- process ID is specified by PROCESS-ID, display information about
- that process; otherwise display information about the program being
- debugged. The summary includes the debugged process ID, the
- command line used to invoke it, its current working directory, and
- its executable file's absolute file name.
-
- On some systems, PROCESS-ID can be of the form `[PID]/TID' which
- specifies a certain thread ID within a process. If the optional
- PID part is missing, it means a thread from the process being
- debugged (the leading `/' still needs to be present, or else GDB
- will interpret the number as a process ID rather than a thread ID).
-
-`info proc mappings'
- Report the memory address space ranges accessible in the program,
- with information on whether the process has read, write, or
- execute access rights to each range. On GNU/Linux systems, each
- memory range includes the object file which is mapped to that
- range, instead of the memory access rights to that range.
-
-`info proc stat'
-`info proc status'
- These subcommands are specific to GNU/Linux systems. They show
- the process-related information, including the user ID and group
- ID; how many threads are there in the process; its virtual memory
- usage; the signals that are pending, blocked, and ignored; its
- TTY; its consumption of system and user time; its stack size; its
- `nice' value; etc. For more information, see the `proc' man page
- (type `man 5 proc' from your shell prompt).
-
-`info proc all'
- Show all the information about the process described under all of
- the above `info proc' subcommands.
-
-`set procfs-trace'
- This command enables and disables tracing of `procfs' API calls.
-
-`show procfs-trace'
- Show the current state of `procfs' API call tracing.
-
-`set procfs-file FILE'
- Tell GDB to write `procfs' API trace to the named FILE. GDB
- appends the trace info to the previous contents of the file. The
- default is to display the trace on the standard output.
-
-`show procfs-file'
- Show the file to which `procfs' API trace is written.
-
-`proc-trace-entry'
-`proc-trace-exit'
-`proc-untrace-entry'
-`proc-untrace-exit'
- These commands enable and disable tracing of entries into and exits
- from the `syscall' interface.
-
-`info pidlist'
- For QNX Neutrino only, this command displays the list of all the
- processes and all the threads within each process.
-
-`info meminfo'
- For QNX Neutrino only, this command displays the list of all
- mapinfos.
-
-
-File: gdb.info, Node: DJGPP Native, Next: Cygwin Native, Prev: SVR4 Process Information, Up: Native
-
-21.1.4 Features for Debugging DJGPP Programs
---------------------------------------------
-
-DJGPP is a port of the GNU development tools to MS-DOS and MS-Windows.
-DJGPP programs are 32-bit protected-mode programs that use the "DPMI"
-(DOS Protected-Mode Interface) API to run on top of real-mode DOS
-systems and their emulations.
-
- GDB supports native debugging of DJGPP programs, and defines a few
-commands specific to the DJGPP port. This subsection describes those
-commands.
-
-`info dos'
- This is a prefix of DJGPP-specific commands which print
- information about the target system and important OS structures.
-
-`info dos sysinfo'
- This command displays assorted information about the underlying
- platform: the CPU type and features, the OS version and flavor, the
- DPMI version, and the available conventional and DPMI memory.
-
-`info dos gdt'
-`info dos ldt'
-`info dos idt'
- These 3 commands display entries from, respectively, Global, Local,
- and Interrupt Descriptor Tables (GDT, LDT, and IDT). The
- descriptor tables are data structures which store a descriptor for
- each segment that is currently in use. The segment's selector is
- an index into a descriptor table; the table entry for that index
- holds the descriptor's base address and limit, and its attributes
- and access rights.
-
- A typical DJGPP program uses 3 segments: a code segment, a data
- segment (used for both data and the stack), and a DOS segment
- (which allows access to DOS/BIOS data structures and absolute
- addresses in conventional memory). However, the DPMI host will
- usually define additional segments in order to support the DPMI
- environment.
-
- These commands allow to display entries from the descriptor tables.
- Without an argument, all entries from the specified table are
- displayed. An argument, which should be an integer expression,
- means display a single entry whose index is given by the argument.
- For example, here's a convenient way to display information about
- the debugged program's data segment:
-
- `(gdb) info dos ldt $ds'
- `0x13f: base=0x11970000 limit=0x0009ffff 32-Bit Data (Read/Write, Exp-up)'
-
-
- This comes in handy when you want to see whether a pointer is
- outside the data segment's limit (i.e. "garbled").
-
-`info dos pde'
-`info dos pte'
- These two commands display entries from, respectively, the Page
- Directory and the Page Tables. Page Directories and Page Tables
- are data structures which control how virtual memory addresses are
- mapped into physical addresses. A Page Table includes an entry
- for every page of memory that is mapped into the program's address
- space; there may be several Page Tables, each one holding up to
- 4096 entries. A Page Directory has up to 4096 entries, one each
- for every Page Table that is currently in use.
-
- Without an argument, `info dos pde' displays the entire Page
- Directory, and `info dos pte' displays all the entries in all of
- the Page Tables. An argument, an integer expression, given to the
- `info dos pde' command means display only that entry from the Page
- Directory table. An argument given to the `info dos pte' command
- means display entries from a single Page Table, the one pointed to
- by the specified entry in the Page Directory.
-
- These commands are useful when your program uses "DMA" (Direct
- Memory Access), which needs physical addresses to program the DMA
- controller.
-
- These commands are supported only with some DPMI servers.
-
-`info dos address-pte ADDR'
- This command displays the Page Table entry for a specified linear
- address. The argument ADDR is a linear address which should
- already have the appropriate segment's base address added to it,
- because this command accepts addresses which may belong to _any_
- segment. For example, here's how to display the Page Table entry
- for the page where a variable `i' is stored:
-
- `(gdb) info dos address-pte __djgpp_base_address + (char *)&i'
- `Page Table entry for address 0x11a00d30:'
- `Base=0x02698000 Dirty Acc. Not-Cached Write-Back Usr Read-Write +0xd30'
-
-
- This says that `i' is stored at offset `0xd30' from the page whose
- physical base address is `0x02698000', and shows all the
- attributes of that page.
-
- Note that you must cast the addresses of variables to a `char *',
- since otherwise the value of `__djgpp_base_address', the base
- address of all variables and functions in a DJGPP program, will be
- added using the rules of C pointer arithmetics: if `i' is declared
- an `int', GDB will add 4 times the value of `__djgpp_base_address'
- to the address of `i'.
-
- Here's another example, it displays the Page Table entry for the
- transfer buffer:
-
- `(gdb) info dos address-pte *((unsigned *)&_go32_info_block + 3)'
- `Page Table entry for address 0x29110:'
- `Base=0x00029000 Dirty Acc. Not-Cached Write-Back Usr Read-Write +0x110'
-
-
- (The `+ 3' offset is because the transfer buffer's address is the
- 3rd member of the `_go32_info_block' structure.) The output
- clearly shows that this DPMI server maps the addresses in
- conventional memory 1:1, i.e. the physical (`0x00029000' +
- `0x110') and linear (`0x29110') addresses are identical.
-
- This command is supported only with some DPMI servers.
-
- In addition to native debugging, the DJGPP port supports remote
-debugging via a serial data link. The following commands are specific
-to remote serial debugging in the DJGPP port of GDB.
-
-`set com1base ADDR'
- This command sets the base I/O port address of the `COM1' serial
- port.
-
-`set com1irq IRQ'
- This command sets the "Interrupt Request" (`IRQ') line to use for
- the `COM1' serial port.
-
- There are similar commands `set com2base', `set com3irq', etc. for
- setting the port address and the `IRQ' lines for the other 3 COM
- ports.
-
- The related commands `show com1base', `show com1irq' etc. display
- the current settings of the base address and the `IRQ' lines used
- by the COM ports.
-
-`info serial'
- This command prints the status of the 4 DOS serial ports. For each
- port, it prints whether it's active or not, its I/O base address
- and IRQ number, whether it uses a 16550-style FIFO, its baudrate,
- and the counts of various errors encountered so far.
-
-
-File: gdb.info, Node: Cygwin Native, Next: Hurd Native, Prev: DJGPP Native, Up: Native
-
-21.1.5 Features for Debugging MS Windows PE Executables
--------------------------------------------------------
-
-GDB supports native debugging of MS Windows programs, including DLLs
-with and without symbolic debugging information.
-
- MS-Windows programs that call `SetConsoleMode' to switch off the
-special meaning of the `Ctrl-C' keystroke cannot be interrupted by
-typing `C-c'. For this reason, GDB on MS-Windows supports `C-<BREAK>'
-as an alternative interrupt key sequence, which can be used to
-interrupt the debuggee even if it ignores `C-c'.
-
- There are various additional Cygwin-specific commands, described in
-this section. Working with DLLs that have no debugging symbols is
-described in *note Non-debug DLL Symbols::.
-
-`info w32'
- This is a prefix of MS Windows-specific commands which print
- information about the target system and important OS structures.
-
-`info w32 selector'
- This command displays information returned by the Win32 API
- `GetThreadSelectorEntry' function. It takes an optional argument
- that is evaluated to a long value to give the information about
- this given selector. Without argument, this command displays
- information about the six segment registers.
-
-`info w32 thread-information-block'
- This command displays thread specific information stored in the
- Thread Information Block (readable on the X86 CPU family using
- `$fs' selector for 32-bit programs and `$gs' for 64-bit programs).
-
-`info dll'
- This is a Cygwin-specific alias of `info shared'.
-
-`dll-symbols'
- This command loads symbols from a dll similarly to add-sym command
- but without the need to specify a base address.
-
-`set cygwin-exceptions MODE'
- If MODE is `on', GDB will break on exceptions that happen inside
- the Cygwin DLL. If MODE is `off', GDB will delay recognition of
- exceptions, and may ignore some exceptions which seem to be caused
- by internal Cygwin DLL "bookkeeping". This option is meant
- primarily for debugging the Cygwin DLL itself; the default value
- is `off' to avoid annoying GDB users with false `SIGSEGV' signals.
-
-`show cygwin-exceptions'
- Displays whether GDB will break on exceptions that happen inside
- the Cygwin DLL itself.
-
-`set new-console MODE'
- If MODE is `on' the debuggee will be started in a new console on
- next start. If MODE is `off', the debuggee will be started in the
- same console as the debugger.
-
-`show new-console'
- Displays whether a new console is used when the debuggee is
- started.
-
-`set new-group MODE'
- This boolean value controls whether the debuggee should start a
- new group or stay in the same group as the debugger. This affects
- the way the Windows OS handles `Ctrl-C'.
-
-`show new-group'
- Displays current value of new-group boolean.
-
-`set debugevents'
- This boolean value adds debug output concerning kernel events
- related to the debuggee seen by the debugger. This includes
- events that signal thread and process creation and exit, DLL
- loading and unloading, console interrupts, and debugging messages
- produced by the Windows `OutputDebugString' API call.
-
-`set debugexec'
- This boolean value adds debug output concerning execute events
- (such as resume thread) seen by the debugger.
-
-`set debugexceptions'
- This boolean value adds debug output concerning exceptions in the
- debuggee seen by the debugger.
-
-`set debugmemory'
- This boolean value adds debug output concerning debuggee memory
- reads and writes by the debugger.
-
-`set shell'
- This boolean values specifies whether the debuggee is called via a
- shell or directly (default value is on).
-
-`show shell'
- Displays if the debuggee will be started with a shell.
-
-
-* Menu:
-
-* Non-debug DLL Symbols:: Support for DLLs without debugging symbols
-
-
-File: gdb.info, Node: Non-debug DLL Symbols, Up: Cygwin Native
-
-21.1.5.1 Support for DLLs without Debugging Symbols
-...................................................
-
-Very often on windows, some of the DLLs that your program relies on do
-not include symbolic debugging information (for example,
-`kernel32.dll'). When GDB doesn't recognize any debugging symbols in a
-DLL, it relies on the minimal amount of symbolic information contained
-in the DLL's export table. This section describes working with such
-symbols, known internally to GDB as "minimal symbols".
-
- Note that before the debugged program has started execution, no DLLs
-will have been loaded. The easiest way around this problem is simply to
-start the program -- either by setting a breakpoint or letting the
-program run once to completion. It is also possible to force GDB to
-load a particular DLL before starting the executable -- see the shared
-library information in *note Files::, or the `dll-symbols' command in
-*note Cygwin Native::. Currently, explicitly loading symbols from a
-DLL with no debugging information will cause the symbol names to be
-duplicated in GDB's lookup table, which may adversely affect symbol
-lookup performance.
-
-21.1.5.2 DLL Name Prefixes
-..........................
-
-In keeping with the naming conventions used by the Microsoft debugging
-tools, DLL export symbols are made available with a prefix based on the
-DLL name, for instance `KERNEL32!CreateFileA'. The plain name is also
-entered into the symbol table, so `CreateFileA' is often sufficient.
-In some cases there will be name clashes within a program (particularly
-if the executable itself includes full debugging symbols) necessitating
-the use of the fully qualified name when referring to the contents of
-the DLL. Use single-quotes around the name to avoid the exclamation
-mark ("!") being interpreted as a language operator.
-
- Note that the internal name of the DLL may be all upper-case, even
-though the file name of the DLL is lower-case, or vice-versa. Since
-symbols within GDB are _case-sensitive_ this may cause some confusion.
-If in doubt, try the `info functions' and `info variables' commands or
-even `maint print msymbols' (*note Symbols::). Here's an example:
-
- (gdb) info function CreateFileA
- All functions matching regular expression "CreateFileA":
-
- Non-debugging symbols:
- 0x77e885f4 CreateFileA
- 0x77e885f4 KERNEL32!CreateFileA
-
- (gdb) info function !
- All functions matching regular expression "!":
-
- Non-debugging symbols:
- 0x6100114c cygwin1!__assert
- 0x61004034 cygwin1!_dll_crt0@0
- 0x61004240 cygwin1!dll_crt0(per_process *)
- [etc...]
-
-21.1.5.3 Working with Minimal Symbols
-.....................................
-
-Symbols extracted from a DLL's export table do not contain very much
-type information. All that GDB can do is guess whether a symbol refers
-to a function or variable depending on the linker section that contains
-the symbol. Also note that the actual contents of the memory contained
-in a DLL are not available unless the program is running. This means
-that you cannot examine the contents of a variable or disassemble a
-function within a DLL without a running program.
-
- Variables are generally treated as pointers and dereferenced
-automatically. For this reason, it is often necessary to prefix a
-variable name with the address-of operator ("&") and provide explicit
-type information in the command. Here's an example of the type of
-problem:
-
- (gdb) print 'cygwin1!__argv'
- $1 = 268572168
-
- (gdb) x 'cygwin1!__argv'
- 0x10021610: "\230y\""
-
- And two possible solutions:
-
- (gdb) print ((char **)'cygwin1!__argv')[0]
- $2 = 0x22fd98 "/cygdrive/c/mydirectory/myprogram"
-
- (gdb) x/2x &'cygwin1!__argv'
- 0x610c0aa8 <cygwin1!__argv>: 0x10021608 0x00000000
- (gdb) x/x 0x10021608
- 0x10021608: 0x0022fd98
- (gdb) x/s 0x0022fd98
- 0x22fd98: "/cygdrive/c/mydirectory/myprogram"
-
- Setting a break point within a DLL is possible even before the
-program starts execution. However, under these circumstances, GDB can't
-examine the initial instructions of the function in order to skip the
-function's frame set-up code. You can work around this by using "*&" to
-set the breakpoint at a raw memory address:
-
- (gdb) break *&'python22!PyOS_Readline'
- Breakpoint 1 at 0x1e04eff0
-
- The author of these extensions is not entirely convinced that
-setting a break point within a shared DLL like `kernel32.dll' is
-completely safe.
-
-
-File: gdb.info, Node: Hurd Native, Next: Neutrino, Prev: Cygwin Native, Up: Native
-
-21.1.6 Commands Specific to GNU Hurd Systems
---------------------------------------------
-
-This subsection describes GDB commands specific to the GNU Hurd native
-debugging.
-
-`set signals'
-`set sigs'
- This command toggles the state of inferior signal interception by
- GDB. Mach exceptions, such as breakpoint traps, are not affected
- by this command. `sigs' is a shorthand alias for `signals'.
-
-`show signals'
-`show sigs'
- Show the current state of intercepting inferior's signals.
-
-`set signal-thread'
-`set sigthread'
- This command tells GDB which thread is the `libc' signal thread.
- That thread is run when a signal is delivered to a running
- process. `set sigthread' is the shorthand alias of `set
- signal-thread'.
-
-`show signal-thread'
-`show sigthread'
- These two commands show which thread will run when the inferior is
- delivered a signal.
-
-`set stopped'
- This commands tells GDB that the inferior process is stopped, as
- with the `SIGSTOP' signal. The stopped process can be continued
- by delivering a signal to it.
-
-`show stopped'
- This command shows whether GDB thinks the debuggee is stopped.
-
-`set exceptions'
- Use this command to turn off trapping of exceptions in the
- inferior. When exception trapping is off, neither breakpoints nor
- single-stepping will work. To restore the default, set exception
- trapping on.
-
-`show exceptions'
- Show the current state of trapping exceptions in the inferior.
-
-`set task pause'
- This command toggles task suspension when GDB has control.
- Setting it to on takes effect immediately, and the task is
- suspended whenever GDB gets control. Setting it to off will take
- effect the next time the inferior is continued. If this option is
- set to off, you can use `set thread default pause on' or `set
- thread pause on' (see below) to pause individual threads.
-
-`show task pause'
- Show the current state of task suspension.
-
-`set task detach-suspend-count'
- This command sets the suspend count the task will be left with when
- GDB detaches from it.
-
-`show task detach-suspend-count'
- Show the suspend count the task will be left with when detaching.
-
-`set task exception-port'
-`set task excp'
- This command sets the task exception port to which GDB will
- forward exceptions. The argument should be the value of the "send
- rights" of the task. `set task excp' is a shorthand alias.
-
-`set noninvasive'
- This command switches GDB to a mode that is the least invasive as
- far as interfering with the inferior is concerned. This is the
- same as using `set task pause', `set exceptions', and `set
- signals' to values opposite to the defaults.
-
-`info send-rights'
-`info receive-rights'
-`info port-rights'
-`info port-sets'
-`info dead-names'
-`info ports'
-`info psets'
- These commands display information about, respectively, send
- rights, receive rights, port rights, port sets, and dead names of
- a task. There are also shorthand aliases: `info ports' for `info
- port-rights' and `info psets' for `info port-sets'.
-
-`set thread pause'
- This command toggles current thread suspension when GDB has
- control. Setting it to on takes effect immediately, and the
- current thread is suspended whenever GDB gets control. Setting it
- to off will take effect the next time the inferior is continued.
- Normally, this command has no effect, since when GDB has control,
- the whole task is suspended. However, if you used `set task pause
- off' (see above), this command comes in handy to suspend only the
- current thread.
-
-`show thread pause'
- This command shows the state of current thread suspension.
-
-`set thread run'
- This command sets whether the current thread is allowed to run.
-
-`show thread run'
- Show whether the current thread is allowed to run.
-
-`set thread detach-suspend-count'
- This command sets the suspend count GDB will leave on a thread
- when detaching. This number is relative to the suspend count
- found by GDB when it notices the thread; use `set thread
- takeover-suspend-count' to force it to an absolute value.
-
-`show thread detach-suspend-count'
- Show the suspend count GDB will leave on the thread when detaching.
-
-`set thread exception-port'
-`set thread excp'
- Set the thread exception port to which to forward exceptions. This
- overrides the port set by `set task exception-port' (see above).
- `set thread excp' is the shorthand alias.
-
-`set thread takeover-suspend-count'
- Normally, GDB's thread suspend counts are relative to the value
- GDB finds when it notices each thread. This command changes the
- suspend counts to be absolute instead.
-
-`set thread default'
-`show thread default'
- Each of the above `set thread' commands has a `set thread default'
- counterpart (e.g., `set thread default pause', `set thread default
- exception-port', etc.). The `thread default' variety of commands
- sets the default thread properties for all threads; you can then
- change the properties of individual threads with the non-default
- commands.
-
-
-File: gdb.info, Node: Neutrino, Next: Darwin, Prev: Hurd Native, Up: Native
-
-21.1.7 QNX Neutrino
--------------------
-
-GDB provides the following commands specific to the QNX Neutrino target:
-
-`set debug nto-debug'
- When set to on, enables debugging messages specific to the QNX
- Neutrino support.
-
-`show debug nto-debug'
- Show the current state of QNX Neutrino messages.
-
-
-File: gdb.info, Node: Darwin, Prev: Neutrino, Up: Native
-
-21.1.8 Darwin
--------------
-
-GDB provides the following commands specific to the Darwin target:
-
-`set debug darwin NUM'
- When set to a non zero value, enables debugging messages specific
- to the Darwin support. Higher values produce more verbose output.
-
-`show debug darwin'
- Show the current state of Darwin messages.
-
-`set debug mach-o NUM'
- When set to a non zero value, enables debugging messages while GDB
- is reading Darwin object files. ("Mach-O" is the file format used
- on Darwin for object and executable files.) Higher values produce
- more verbose output. This is a command to diagnose problems
- internal to GDB and should not be needed in normal usage.
-
-`show debug mach-o'
- Show the current state of Mach-O file messages.
-
-`set mach-exceptions on'
-`set mach-exceptions off'
- On Darwin, faults are first reported as a Mach exception and are
- then mapped to a Posix signal. Use this command to turn on
- trapping of Mach exceptions in the inferior. This might be
- sometimes useful to better understand the cause of a fault. The
- default is off.
-
-`show mach-exceptions'
- Show the current state of exceptions trapping.
-
-
-File: gdb.info, Node: Embedded OS, Next: Embedded Processors, Prev: Native, Up: Configurations
-
-21.2 Embedded Operating Systems
-===============================
-
-This section describes configurations involving the debugging of
-embedded operating systems that are available for several different
-architectures.
-
-* Menu:
-
-* VxWorks:: Using GDB with VxWorks
-
- GDB includes the ability to debug programs running on various
-real-time operating systems.
-
-
-File: gdb.info, Node: VxWorks, Up: Embedded OS
-
-21.2.1 Using GDB with VxWorks
------------------------------
-
-`target vxworks MACHINENAME'
- A VxWorks system, attached via TCP/IP. The argument MACHINENAME
- is the target system's machine name or IP address.
-
-
- On VxWorks, `load' links FILENAME dynamically on the current target
-system as well as adding its symbols in GDB.
-
- GDB enables developers to spawn and debug tasks running on networked
-VxWorks targets from a Unix host. Already-running tasks spawned from
-the VxWorks shell can also be debugged. GDB uses code that runs on
-both the Unix host and on the VxWorks target. The program `gdb' is
-installed and executed on the Unix host. (It may be installed with the
-name `vxgdb', to distinguish it from a GDB for debugging programs on
-the host itself.)
-
-`VxWorks-timeout ARGS'
- All VxWorks-based targets now support the option `vxworks-timeout'.
- This option is set by the user, and ARGS represents the number of
- seconds GDB waits for responses to rpc's. You might use this if
- your VxWorks target is a slow software simulator or is on the far
- side of a thin network line.
-
- The following information on connecting to VxWorks was current when
-this manual was produced; newer releases of VxWorks may use revised
-procedures.
-
- To use GDB with VxWorks, you must rebuild your VxWorks kernel to
-include the remote debugging interface routines in the VxWorks library
-`rdb.a'. To do this, define `INCLUDE_RDB' in the VxWorks configuration
-file `configAll.h' and rebuild your VxWorks kernel. The resulting
-kernel contains `rdb.a', and spawns the source debugging task
-`tRdbTask' when VxWorks is booted. For more information on configuring
-and remaking VxWorks, see the manufacturer's manual.
-
- Once you have included `rdb.a' in your VxWorks system image and set
-your Unix execution search path to find GDB, you are ready to run GDB.
-From your Unix host, run `gdb' (or `vxgdb', depending on your
-installation).
-
- GDB comes up showing the prompt:
-
- (vxgdb)
-
-* Menu:
-
-* VxWorks Connection:: Connecting to VxWorks
-* VxWorks Download:: VxWorks download
-* VxWorks Attach:: Running tasks
-
-
-File: gdb.info, Node: VxWorks Connection, Next: VxWorks Download, Up: VxWorks
-
-21.2.1.1 Connecting to VxWorks
-..............................
-
-The GDB command `target' lets you connect to a VxWorks target on the
-network. To connect to a target whose host name is "`tt'", type:
-
- (vxgdb) target vxworks tt
-
- GDB displays messages like these:
-
- Attaching remote machine across net...
- Connected to tt.
-
- GDB then attempts to read the symbol tables of any object modules
-loaded into the VxWorks target since it was last booted. GDB locates
-these files by searching the directories listed in the command search
-path (*note Your Program's Environment: Environment.); if it fails to
-find an object file, it displays a message such as:
-
- prog.o: No such file or directory.
-
- When this happens, add the appropriate directory to the search path
-with the GDB command `path', and execute the `target' command again.
-
-
-File: gdb.info, Node: VxWorks Download, Next: VxWorks Attach, Prev: VxWorks Connection, Up: VxWorks
-
-21.2.1.2 VxWorks Download
-.........................
-
-If you have connected to the VxWorks target and you want to debug an
-object that has not yet been loaded, you can use the GDB `load' command
-to download a file from Unix to VxWorks incrementally. The object file
-given as an argument to the `load' command is actually opened twice:
-first by the VxWorks target in order to download the code, then by GDB
-in order to read the symbol table. This can lead to problems if the
-current working directories on the two systems differ. If both systems
-have NFS mounted the same filesystems, you can avoid these problems by
-using absolute paths. Otherwise, it is simplest to set the working
-directory on both systems to the directory in which the object file
-resides, and then to reference the file by its name, without any path.
-For instance, a program `prog.o' may reside in `VXPATH/vw/demo/rdb' in
-VxWorks and in `HOSTPATH/vw/demo/rdb' on the host. To load this
-program, type this on VxWorks:
-
- -> cd "VXPATH/vw/demo/rdb"
-
-Then, in GDB, type:
-
- (vxgdb) cd HOSTPATH/vw/demo/rdb
- (vxgdb) load prog.o
-
- GDB displays a response similar to this:
-
- Reading symbol data from wherever/vw/demo/rdb/prog.o... done.
-
- You can also use the `load' command to reload an object module after
-editing and recompiling the corresponding source file. Note that this
-makes GDB delete all currently-defined breakpoints, auto-displays, and
-convenience variables, and to clear the value history. (This is
-necessary in order to preserve the integrity of debugger's data
-structures that reference the target system's symbol table.)
-
-
-File: gdb.info, Node: VxWorks Attach, Prev: VxWorks Download, Up: VxWorks
-
-21.2.1.3 Running Tasks
-......................
-
-You can also attach to an existing task using the `attach' command as
-follows:
-
- (vxgdb) attach TASK
-
-where TASK is the VxWorks hexadecimal task ID. The task can be running
-or suspended when you attach to it. Running tasks are suspended at the
-time of attachment.
-
-
-File: gdb.info, Node: Embedded Processors, Next: Architectures, Prev: Embedded OS, Up: Configurations
-
-21.3 Embedded Processors
-========================
-
-This section goes into details specific to particular embedded
-configurations.
-
- Whenever a specific embedded processor has a simulator, GDB allows
-to send an arbitrary command to the simulator.
-
-`sim COMMAND'
- Send an arbitrary COMMAND string to the simulator. Consult the
- documentation for the specific simulator in use for information
- about acceptable commands.
-
-* Menu:
-
-* ARM:: ARM RDI
-* M32R/D:: Renesas M32R/D
-* M68K:: Motorola M68K
-* MicroBlaze:: Xilinx MicroBlaze
-* MIPS Embedded:: MIPS Embedded
-* OpenRISC 1000:: OpenRisc 1000
-* PA:: HP PA Embedded
-* PowerPC Embedded:: PowerPC Embedded
-* Sparclet:: Tsqware Sparclet
-* Sparclite:: Fujitsu Sparclite
-* Z8000:: Zilog Z8000
-* AVR:: Atmel AVR
-* CRIS:: CRIS
-* Super-H:: Renesas Super-H
-
-
-File: gdb.info, Node: ARM, Next: M32R/D, Up: Embedded Processors
-
-21.3.1 ARM
-----------
-
-`target rdi DEV'
- ARM Angel monitor, via RDI library interface to ADP protocol. You
- may use this target to communicate with both boards running the
- Angel monitor, or with the EmbeddedICE JTAG debug device.
-
-`target rdp DEV'
- ARM Demon monitor.
-
-
- GDB provides the following ARM-specific commands:
-
-`set arm disassembler'
- This commands selects from a list of disassembly styles. The
- `"std"' style is the standard style.
-
-`show arm disassembler'
- Show the current disassembly style.
-
-`set arm apcs32'
- This command toggles ARM operation mode between 32-bit and 26-bit.
-
-`show arm apcs32'
- Display the current usage of the ARM 32-bit mode.
-
-`set arm fpu FPUTYPE'
- This command sets the ARM floating-point unit (FPU) type. The
- argument FPUTYPE can be one of these:
-
- `auto'
- Determine the FPU type by querying the OS ABI.
-
- `softfpa'
- Software FPU, with mixed-endian doubles on little-endian ARM
- processors.
-
- `fpa'
- GCC-compiled FPA co-processor.
-
- `softvfp'
- Software FPU with pure-endian doubles.
-
- `vfp'
- VFP co-processor.
-
-`show arm fpu'
- Show the current type of the FPU.
-
-`set arm abi'
- This command forces GDB to use the specified ABI.
-
-`show arm abi'
- Show the currently used ABI.
-
-`set arm fallback-mode (arm|thumb|auto)'
- GDB uses the symbol table, when available, to determine whether
- instructions are ARM or Thumb. This command controls GDB's
- default behavior when the symbol table is not available. The
- default is `auto', which causes GDB to use the current execution
- mode (from the `T' bit in the `CPSR' register).
-
-`show arm fallback-mode'
- Show the current fallback instruction mode.
-
-`set arm force-mode (arm|thumb|auto)'
- This command overrides use of the symbol table to determine whether
- instructions are ARM or Thumb. The default is `auto', which
- causes GDB to use the symbol table and then the setting of `set
- arm fallback-mode'.
-
-`show arm force-mode'
- Show the current forced instruction mode.
-
-`set debug arm'
- Toggle whether to display ARM-specific debugging messages from the
- ARM target support subsystem.
-
-`show debug arm'
- Show whether ARM-specific debugging messages are enabled.
-
- The following commands are available when an ARM target is debugged
-using the RDI interface:
-
-`rdilogfile [FILE]'
- Set the filename for the ADP (Angel Debugger Protocol) packet log.
- With an argument, sets the log file to the specified FILE. With
- no argument, show the current log file name. The default log file
- is `rdi.log'.
-
-`rdilogenable [ARG]'
- Control logging of ADP packets. With an argument of 1 or `"yes"'
- enables logging, with an argument 0 or `"no"' disables it. With
- no arguments displays the current setting. When logging is
- enabled, ADP packets exchanged between GDB and the RDI target
- device are logged to a file.
-
-`set rdiromatzero'
- Tell GDB whether the target has ROM at address 0. If on, vector
- catching is disabled, so that zero address can be used. If off
- (the default), vector catching is enabled. For this command to
- take effect, it needs to be invoked prior to the `target rdi'
- command.
-
-`show rdiromatzero'
- Show the current setting of ROM at zero address.
-
-`set rdiheartbeat'
- Enable or disable RDI heartbeat packets. It is not recommended to
- turn on this option, since it confuses ARM and EPI JTAG interface,
- as well as the Angel monitor.
-
-`show rdiheartbeat'
- Show the setting of RDI heartbeat packets.
-
-`target sim [SIMARGS] ...'
- The GDB ARM simulator accepts the following optional arguments.
-
- `--swi-support=TYPE'
- Tell the simulator which SWI interfaces to support. TYPE may
- be a comma separated list of the following values. The
- default value is `all'.
-
- `none'
-
- `demon'
-
- `angel'
-
- `redboot'
-
- `all'
-
-
-File: gdb.info, Node: M32R/D, Next: M68K, Prev: ARM, Up: Embedded Processors
-
-21.3.2 Renesas M32R/D and M32R/SDI
-----------------------------------
-
-`target m32r DEV'
- Renesas M32R/D ROM monitor.
-
-`target m32rsdi DEV'
- Renesas M32R SDI server, connected via parallel port to the board.
-
- The following GDB commands are specific to the M32R monitor:
-
-`set download-path PATH'
- Set the default path for finding downloadable SREC files.
-
-`show download-path'
- Show the default path for downloadable SREC files.
-
-`set board-address ADDR'
- Set the IP address for the M32R-EVA target board.
-
-`show board-address'
- Show the current IP address of the target board.
-
-`set server-address ADDR'
- Set the IP address for the download server, which is the GDB's
- host machine.
-
-`show server-address'
- Display the IP address of the download server.
-
-`upload [FILE]'
- Upload the specified SREC FILE via the monitor's Ethernet upload
- capability. If no FILE argument is given, the current executable
- file is uploaded.
-
-`tload [FILE]'
- Test the `upload' command.
-
- The following commands are available for M32R/SDI:
-
-`sdireset'
- This command resets the SDI connection.
-
-`sdistatus'
- This command shows the SDI connection status.
-
-`debug_chaos'
- Instructs the remote that M32R/Chaos debugging is to be used.
-
-`use_debug_dma'
- Instructs the remote to use the DEBUG_DMA method of accessing
- memory.
-
-`use_mon_code'
- Instructs the remote to use the MON_CODE method of accessing
- memory.
-
-`use_ib_break'
- Instructs the remote to set breakpoints by IB break.
-
-`use_dbt_break'
- Instructs the remote to set breakpoints by DBT.
-
-
-File: gdb.info, Node: M68K, Next: MicroBlaze, Prev: M32R/D, Up: Embedded Processors
-
-21.3.3 M68k
------------
-
-The Motorola m68k configuration includes ColdFire support, and a target
-command for the following ROM monitor.
-
-`target dbug DEV'
- dBUG ROM monitor for Motorola ColdFire.
-
-
-
-File: gdb.info, Node: MicroBlaze, Next: MIPS Embedded, Prev: M68K, Up: Embedded Processors
-
-21.3.4 MicroBlaze
------------------
-
-The MicroBlaze is a soft-core processor supported on various Xilinx
-FPGAs, such as Spartan or Virtex series. Boards with these processors
-usually have JTAG ports which connect to a host system running the
-Xilinx Embedded Development Kit (EDK) or Software Development Kit (SDK).
-This host system is used to download the configuration bitstream to the
-target FPGA. The Xilinx Microprocessor Debugger (XMD) program
-communicates with the target board using the JTAG interface and
-presents a `gdbserver' interface to the board. By default `xmd' uses
-port `1234'. (While it is possible to change this default port, it
-requires the use of undocumented `xmd' commands. Contact Xilinx
-support if you need to do this.)
-
- Use these GDB commands to connect to the MicroBlaze target processor.
-
-`target remote :1234'
- Use this command to connect to the target if you are running GDB
- on the same system as `xmd'.
-
-`target remote XMD-HOST:1234'
- Use this command to connect to the target if it is connected to
- `xmd' running on a different system named XMD-HOST.
-
-`load'
- Use this command to download a program to the MicroBlaze target.
-
-`set debug microblaze N'
- Enable MicroBlaze-specific debugging messages if non-zero.
-
-`show debug microblaze N'
- Show MicroBlaze-specific debugging level.
-
-
-File: gdb.info, Node: MIPS Embedded, Next: OpenRISC 1000, Prev: MicroBlaze, Up: Embedded Processors
-
-21.3.5 MIPS Embedded
---------------------
-
-GDB can use the MIPS remote debugging protocol to talk to a MIPS board
-attached to a serial line. This is available when you configure GDB
-with `--target=mips-idt-ecoff'.
-
- Use these GDB commands to specify the connection to your target
-board:
-
-`target mips PORT'
- To run a program on the board, start up `gdb' with the name of
- your program as the argument. To connect to the board, use the
- command `target mips PORT', where PORT is the name of the serial
- port connected to the board. If the program has not already been
- downloaded to the board, you may use the `load' command to
- download it. You can then use all the usual GDB commands.
-
- For example, this sequence connects to the target board through a
- serial port, and loads and runs a program called PROG through the
- debugger:
-
- host$ gdb PROG
- GDB is free software and ...
- (gdb) target mips /dev/ttyb
- (gdb) load PROG
- (gdb) run
-
-`target mips HOSTNAME:PORTNUMBER'
- On some GDB host configurations, you can specify a TCP connection
- (for instance, to a serial line managed by a terminal
- concentrator) instead of a serial port, using the syntax
- `HOSTNAME:PORTNUMBER'.
-
-`target pmon PORT'
- PMON ROM monitor.
-
-`target ddb PORT'
- NEC's DDB variant of PMON for Vr4300.
-
-`target lsi PORT'
- LSI variant of PMON.
-
-`target r3900 DEV'
- Densan DVE-R3900 ROM monitor for Toshiba R3900 Mips.
-
-`target array DEV'
- Array Tech LSI33K RAID controller board.
-
-
-GDB also supports these special commands for MIPS targets:
-
-`set mipsfpu double'
-`set mipsfpu single'
-`set mipsfpu none'
-`set mipsfpu auto'
-`show mipsfpu'
- If your target board does not support the MIPS floating point
- coprocessor, you should use the command `set mipsfpu none' (if you
- need this, you may wish to put the command in your GDB init file).
- This tells GDB how to find the return value of functions which
- return floating point values. It also allows GDB to avoid saving
- the floating point registers when calling functions on the board.
- If you are using a floating point coprocessor with only single
- precision floating point support, as on the R4650 processor, use
- the command `set mipsfpu single'. The default double precision
- floating point coprocessor may be selected using `set mipsfpu
- double'.
-
- In previous versions the only choices were double precision or no
- floating point, so `set mipsfpu on' will select double precision
- and `set mipsfpu off' will select no floating point.
-
- As usual, you can inquire about the `mipsfpu' variable with `show
- mipsfpu'.
-
-`set timeout SECONDS'
-`set retransmit-timeout SECONDS'
-`show timeout'
-`show retransmit-timeout'
- You can control the timeout used while waiting for a packet, in
- the MIPS remote protocol, with the `set timeout SECONDS' command.
- The default is 5 seconds. Similarly, you can control the timeout
- used while waiting for an acknowledgment of a packet with the `set
- retransmit-timeout SECONDS' command. The default is 3 seconds.
- You can inspect both values with `show timeout' and `show
- retransmit-timeout'. (These commands are _only_ available when
- GDB is configured for `--target=mips-idt-ecoff'.)
-
- The timeout set by `set timeout' does not apply when GDB is
- waiting for your program to stop. In that case, GDB waits forever
- because it has no way of knowing how long the program is going to
- run before stopping.
-
-`set syn-garbage-limit NUM'
- Limit the maximum number of characters GDB should ignore when it
- tries to synchronize with the remote target. The default is 10
- characters. Setting the limit to -1 means there's no limit.
-
-`show syn-garbage-limit'
- Show the current limit on the number of characters to ignore when
- trying to synchronize with the remote system.
-
-`set monitor-prompt PROMPT'
- Tell GDB to expect the specified PROMPT string from the remote
- monitor. The default depends on the target:
- pmon target
- `PMON'
-
- ddb target
- `NEC010'
-
- lsi target
- `PMON>'
-
-`show monitor-prompt'
- Show the current strings GDB expects as the prompt from the remote
- monitor.
-
-`set monitor-warnings'
- Enable or disable monitor warnings about hardware breakpoints.
- This has effect only for the `lsi' target. When on, GDB will
- display warning messages whose codes are returned by the `lsi'
- PMON monitor for breakpoint commands.
-
-`show monitor-warnings'
- Show the current setting of printing monitor warnings.
-
-`pmon COMMAND'
- This command allows sending an arbitrary COMMAND string to the
- monitor. The monitor must be in debug mode for this to work.
-
-
-File: gdb.info, Node: OpenRISC 1000, Next: PA, Prev: MIPS Embedded, Up: Embedded Processors
-
-21.3.6 OpenRISC 1000
---------------------
-
-See OR1k Architecture document (`www.opencores.org') for more
-information about platform and commands.
-
-`target jtag jtag://HOST:PORT'
- Connects to remote JTAG server. JTAG remote server can be either
- an or1ksim or JTAG server, connected via parallel port to the
- board.
-
- Example: `target jtag jtag://localhost:9999'
-
-`or1ksim COMMAND'
- If connected to `or1ksim' OpenRISC 1000 Architectural Simulator,
- proprietary commands can be executed.
-
-`info or1k spr'
- Displays spr groups.
-
-`info or1k spr GROUP'
-`info or1k spr GROUPNO'
- Displays register names in selected group.
-
-`info or1k spr GROUP REGISTER'
-`info or1k spr REGISTER'
-`info or1k spr GROUPNO REGISTERNO'
-`info or1k spr REGISTERNO'
- Shows information about specified spr register.
-
-`spr GROUP REGISTER VALUE'
-`spr REGISTER VALUE'
-`spr GROUPNO REGISTERNO VALUE'
-`spr REGISTERNO VALUE'
- Writes VALUE to specified spr register.
-
- Some implementations of OpenRISC 1000 Architecture also have
-hardware trace. It is very similar to GDB trace, except it does not
-interfere with normal program execution and is thus much faster.
-Hardware breakpoints/watchpoint triggers can be set using:
-`$LEA/$LDATA'
- Load effective address/data
-
-`$SEA/$SDATA'
- Store effective address/data
-
-`$AEA/$ADATA'
- Access effective address ($SEA or $LEA) or data ($SDATA/$LDATA)
-
-`$FETCH'
- Fetch data
-
- When triggered, it can capture low level data, like: `PC', `LSEA',
-`LDATA', `SDATA', `READSPR', `WRITESPR', `INSTR'.
-
- `htrace' commands:
-`hwatch CONDITIONAL'
- Set hardware watchpoint on combination of Load/Store Effective
- Address(es) or Data. For example:
-
- `hwatch ($LEA == my_var) && ($LDATA < 50) || ($SEA == my_var) &&
- ($SDATA >= 50)'
-
- `hwatch ($LEA == my_var) && ($LDATA < 50) || ($SEA == my_var) &&
- ($SDATA >= 50)'
-
-`htrace info'
- Display information about current HW trace configuration.
-
-`htrace trigger CONDITIONAL'
- Set starting criteria for HW trace.
-
-`htrace qualifier CONDITIONAL'
- Set acquisition qualifier for HW trace.
-
-`htrace stop CONDITIONAL'
- Set HW trace stopping criteria.
-
-`htrace record [DATA]*'
- Selects the data to be recorded, when qualifier is met and HW
- trace was triggered.
-
-`htrace enable'
-`htrace disable'
- Enables/disables the HW trace.
-
-`htrace rewind [FILENAME]'
- Clears currently recorded trace data.
-
- If filename is specified, new trace file is made and any newly
- collected data will be written there.
-
-`htrace print [START [LEN]]'
- Prints trace buffer, using current record configuration.
-
-`htrace mode continuous'
- Set continuous trace mode.
-
-`htrace mode suspend'
- Set suspend trace mode.
-
-
-
-File: gdb.info, Node: PowerPC Embedded, Next: Sparclet, Prev: PA, Up: Embedded Processors
-
-21.3.7 PowerPC Embedded
------------------------
-
-GDB supports using the DVC (Data Value Compare) register to implement
-in hardware simple hardware watchpoint conditions of the form:
-
- (gdb) watch ADDRESS|VARIABLE \
- if ADDRESS|VARIABLE == CONSTANT EXPRESSION
-
- The DVC register will be automatically used when GDB detects such
-pattern in a condition expression, and the created watchpoint uses one
-debug register (either the `exact-watchpoints' option is on and the
-variable is scalar, or the variable has a length of one byte). This
-feature is available in native GDB running on a Linux kernel version
-2.6.34 or newer.
-
- When running on PowerPC embedded processors, GDB automatically uses
-ranged hardware watchpoints, unless the `exact-watchpoints' option is
-on, in which case watchpoints using only one debug register are created
-when watching variables of scalar types.
-
- You can create an artificial array to watch an arbitrary memory
-region using one of the following commands (*note Expressions::):
-
- (gdb) watch *((char *) ADDRESS)@LENGTH
- (gdb) watch {char[LENGTH]} ADDRESS
-
- PowerPC embedded processors support hardware accelerated "ranged
-breakpoints". A ranged breakpoint stops execution of the inferior
-whenever it executes an instruction at any address within the range it
-specifies. To set a ranged breakpoint in GDB, use the `break-range'
-command.
-
- GDB provides the following PowerPC-specific commands:
-
-`break-range START-LOCATION, END-LOCATION'
- Set a breakpoint for an address range. START-LOCATION and
- END-LOCATION can specify a function name, a line number, an offset
- of lines from the current line or from the start location, or an
- address of an instruction (see *note Specify Location::, for a
- list of all the possible ways to specify a LOCATION.) The
- breakpoint will stop execution of the inferior whenever it
- executes an instruction at any address within the specified range,
- (including START-LOCATION and END-LOCATION.)
-
-`set powerpc soft-float'
-`show powerpc soft-float'
- Force GDB to use (or not use) a software floating point calling
- convention. By default, GDB selects the calling convention based
- on the selected architecture and the provided executable file.
-
-`set powerpc vector-abi'
-`show powerpc vector-abi'
- Force GDB to use the specified calling convention for vector
- arguments and return values. The valid options are `auto';
- `generic', to avoid vector registers even if they are present;
- `altivec', to use AltiVec registers; and `spe' to use SPE
- registers. By default, GDB selects the calling convention based
- on the selected architecture and the provided executable file.
-
-`set powerpc exact-watchpoints'
-`show powerpc exact-watchpoints'
- Allow GDB to use only one debug register when watching a variable
- of scalar type, thus assuming that the variable is accessed
- through the address of its first byte.
-
-`target dink32 DEV'
- DINK32 ROM monitor.
-
-`target ppcbug DEV'
-
-`target ppcbug1 DEV'
- PPCBUG ROM monitor for PowerPC.
-
-`target sds DEV'
- SDS monitor, running on a PowerPC board (such as Motorola's ADS).
-
- The following commands specific to the SDS protocol are supported by
-GDB:
-
-`set sdstimeout NSEC'
- Set the timeout for SDS protocol reads to be NSEC seconds. The
- default is 2 seconds.
-
-`show sdstimeout'
- Show the current value of the SDS timeout.
-
-`sds COMMAND'
- Send the specified COMMAND string to the SDS monitor.
-
-
-File: gdb.info, Node: PA, Next: PowerPC Embedded, Prev: OpenRISC 1000, Up: Embedded Processors
-
-21.3.8 HP PA Embedded
----------------------
-
-`target op50n DEV'
- OP50N monitor, running on an OKI HPPA board.
-
-`target w89k DEV'
- W89K monitor, running on a Winbond HPPA board.
-
-
-
-File: gdb.info, Node: Sparclet, Next: Sparclite, Prev: PowerPC Embedded, Up: Embedded Processors
-
-21.3.9 Tsqware Sparclet
------------------------
-
-GDB enables developers to debug tasks running on Sparclet targets from
-a Unix host. GDB uses code that runs on both the Unix host and on the
-Sparclet target. The program `gdb' is installed and executed on the
-Unix host.
-
-`remotetimeout ARGS'
- GDB supports the option `remotetimeout'. This option is set by
- the user, and ARGS represents the number of seconds GDB waits for
- responses.
-
- When compiling for debugging, include the options `-g' to get debug
-information and `-Ttext' to relocate the program to where you wish to
-load it on the target. You may also want to add the options `-n' or
-`-N' in order to reduce the size of the sections. Example:
-
- sparclet-aout-gcc prog.c -Ttext 0x12010000 -g -o prog -N
-
- You can use `objdump' to verify that the addresses are what you
-intended:
-
- sparclet-aout-objdump --headers --syms prog
-
- Once you have set your Unix execution search path to find GDB, you
-are ready to run GDB. From your Unix host, run `gdb' (or
-`sparclet-aout-gdb', depending on your installation).
-
- GDB comes up showing the prompt:
-
- (gdbslet)
-
-* Menu:
-
-* Sparclet File:: Setting the file to debug
-* Sparclet Connection:: Connecting to Sparclet
-* Sparclet Download:: Sparclet download
-* Sparclet Execution:: Running and debugging
-
-
-File: gdb.info, Node: Sparclet File, Next: Sparclet Connection, Up: Sparclet
-
-21.3.9.1 Setting File to Debug
-..............................
-
-The GDB command `file' lets you choose with program to debug.
-
- (gdbslet) file prog
-
- GDB then attempts to read the symbol table of `prog'. GDB locates
-the file by searching the directories listed in the command search path.
-If the file was compiled with debug information (option `-g'), source
-files will be searched as well. GDB locates the source files by
-searching the directories listed in the directory search path (*note
-Your Program's Environment: Environment.). If it fails to find a file,
-it displays a message such as:
-
- prog: No such file or directory.
-
- When this happens, add the appropriate directories to the search
-paths with the GDB commands `path' and `dir', and execute the `target'
-command again.
-
-
-File: gdb.info, Node: Sparclet Connection, Next: Sparclet Download, Prev: Sparclet File, Up: Sparclet
-
-21.3.9.2 Connecting to Sparclet
-...............................
-
-The GDB command `target' lets you connect to a Sparclet target. To
-connect to a target on serial port "`ttya'", type:
-
- (gdbslet) target sparclet /dev/ttya
- Remote target sparclet connected to /dev/ttya
- main () at ../prog.c:3
-
- GDB displays messages like these:
-
- Connected to ttya.
-
-
-File: gdb.info, Node: Sparclet Download, Next: Sparclet Execution, Prev: Sparclet Connection, Up: Sparclet
-
-21.3.9.3 Sparclet Download
-..........................
-
-Once connected to the Sparclet target, you can use the GDB `load'
-command to download the file from the host to the target. The file
-name and load offset should be given as arguments to the `load' command.
-Since the file format is aout, the program must be loaded to the
-starting address. You can use `objdump' to find out what this value
-is. The load offset is an offset which is added to the VMA (virtual
-memory address) of each of the file's sections. For instance, if the
-program `prog' was linked to text address 0x1201000, with data at
-0x12010160 and bss at 0x12010170, in GDB, type:
-
- (gdbslet) load prog 0x12010000
- Loading section .text, size 0xdb0 vma 0x12010000
-
- If the code is loaded at a different address then what the program
-was linked to, you may need to use the `section' and `add-symbol-file'
-commands to tell GDB where to map the symbol table.
-
-
-File: gdb.info, Node: Sparclet Execution, Prev: Sparclet Download, Up: Sparclet
-
-21.3.9.4 Running and Debugging
-..............................
-
-You can now begin debugging the task using GDB's execution control
-commands, `b', `step', `run', etc. See the GDB manual for the list of
-commands.
-
- (gdbslet) b main
- Breakpoint 1 at 0x12010000: file prog.c, line 3.
- (gdbslet) run
- Starting program: prog
- Breakpoint 1, main (argc=1, argv=0xeffff21c) at prog.c:3
- 3 char *symarg = 0;
- (gdbslet) step
- 4 char *execarg = "hello!";
- (gdbslet)
-
-
-File: gdb.info, Node: Sparclite, Next: Z8000, Prev: Sparclet, Up: Embedded Processors
-
-21.3.10 Fujitsu Sparclite
--------------------------
-
-`target sparclite DEV'
- Fujitsu sparclite boards, used only for the purpose of loading.
- You must use an additional command to debug the program. For
- example: target remote DEV using GDB standard remote protocol.
-
-
-
-File: gdb.info, Node: Z8000, Next: AVR, Prev: Sparclite, Up: Embedded Processors
-
-21.3.11 Zilog Z8000
--------------------
-
-When configured for debugging Zilog Z8000 targets, GDB includes a Z8000
-simulator.
-
- For the Z8000 family, `target sim' simulates either the Z8002 (the
-unsegmented variant of the Z8000 architecture) or the Z8001 (the
-segmented variant). The simulator recognizes which architecture is
-appropriate by inspecting the object code.
-
-`target sim ARGS'
- Debug programs on a simulated CPU. If the simulator supports setup
- options, specify them via ARGS.
-
-After specifying this target, you can debug programs for the simulated
-CPU in the same style as programs for your host computer; use the
-`file' command to load a new program image, the `run' command to run
-your program, and so on.
-
- As well as making available all the usual machine registers (*note
-Registers: Registers.), the Z8000 simulator provides three additional
-items of information as specially named registers:
-
-`cycles'
- Counts clock-ticks in the simulator.
-
-`insts'
- Counts instructions run in the simulator.
-
-`time'
- Execution time in 60ths of a second.
-
-
- You can refer to these values in GDB expressions with the usual
-conventions; for example, `b fputc if $cycles>5000' sets a conditional
-breakpoint that suspends only after at least 5000 simulated clock ticks.
-
-
-File: gdb.info, Node: AVR, Next: CRIS, Prev: Z8000, Up: Embedded Processors
-
-21.3.12 Atmel AVR
------------------
-
-When configured for debugging the Atmel AVR, GDB supports the following
-AVR-specific commands:
-
-`info io_registers'
- This command displays information about the AVR I/O registers. For
- each register, GDB prints its number and value.
-
-
-File: gdb.info, Node: CRIS, Next: Super-H, Prev: AVR, Up: Embedded Processors
-
-21.3.13 CRIS
-------------
-
-When configured for debugging CRIS, GDB provides the following
-CRIS-specific commands:
-
-`set cris-version VER'
- Set the current CRIS version to VER, either `10' or `32'. The
- CRIS version affects register names and sizes. This command is
- useful in case autodetection of the CRIS version fails.
-
-`show cris-version'
- Show the current CRIS version.
-
-`set cris-dwarf2-cfi'
- Set the usage of DWARF-2 CFI for CRIS debugging. The default is
- `on'. Change to `off' when using `gcc-cris' whose version is below
- `R59'.
-
-`show cris-dwarf2-cfi'
- Show the current state of using DWARF-2 CFI.
-
-`set cris-mode MODE'
- Set the current CRIS mode to MODE. It should only be changed when
- debugging in guru mode, in which case it should be set to `guru'
- (the default is `normal').
-
-`show cris-mode'
- Show the current CRIS mode.
-
-
-File: gdb.info, Node: Super-H, Prev: CRIS, Up: Embedded Processors
-
-21.3.14 Renesas Super-H
------------------------
-
-For the Renesas Super-H processor, GDB provides these commands:
-
-`regs'
- Show the values of all Super-H registers.
-
-`set sh calling-convention CONVENTION'
- Set the calling-convention used when calling functions from GDB.
- Allowed values are `gcc', which is the default setting, and
- `renesas'. With the `gcc' setting, functions are called using the
- GCC calling convention. If the DWARF-2 information of the called
- function specifies that the function follows the Renesas calling
- convention, the function is called using the Renesas calling
- convention. If the calling convention is set to `renesas', the
- Renesas calling convention is always used, regardless of the
- DWARF-2 information. This can be used to override the default of
- `gcc' if debug information is missing, or the compiler does not
- emit the DWARF-2 calling convention entry for a function.
-
-`show sh calling-convention'
- Show the current calling convention setting.
-
-
-
-File: gdb.info, Node: Architectures, Prev: Embedded Processors, Up: Configurations
-
-21.4 Architectures
-==================
-
-This section describes characteristics of architectures that affect all
-uses of GDB with the architecture, both native and cross.
-
-* Menu:
-
-* i386::
-* A29K::
-* Alpha::
-* MIPS::
-* HPPA:: HP PA architecture
-* SPU:: Cell Broadband Engine SPU architecture
-* PowerPC::
-
-
-File: gdb.info, Node: i386, Next: A29K, Up: Architectures
-
-21.4.1 x86 Architecture-specific Issues
----------------------------------------
-
-`set struct-convention MODE'
- Set the convention used by the inferior to return `struct's and
- `union's from functions to MODE. Possible values of MODE are
- `"pcc"', `"reg"', and `"default"' (the default). `"default"' or
- `"pcc"' means that `struct's are returned on the stack, while
- `"reg"' means that a `struct' or a `union' whose size is 1, 2, 4,
- or 8 bytes will be returned in a register.
-
-`show struct-convention'
- Show the current setting of the convention to return `struct's
- from functions.
-
-
-File: gdb.info, Node: A29K, Next: Alpha, Prev: i386, Up: Architectures
-
-21.4.2 A29K
------------
-
-`set rstack_high_address ADDRESS'
- On AMD 29000 family processors, registers are saved in a separate
- "register stack". There is no way for GDB to determine the extent
- of this stack. Normally, GDB just assumes that the stack is
- "large enough". This may result in GDB referencing memory
- locations that do not exist. If necessary, you can get around
- this problem by specifying the ending address of the register
- stack with the `set rstack_high_address' command. The argument
- should be an address, which you probably want to precede with `0x'
- to specify in hexadecimal.
-
-`show rstack_high_address'
- Display the current limit of the register stack, on AMD 29000
- family processors.
-
-
-
-File: gdb.info, Node: Alpha, Next: MIPS, Prev: A29K, Up: Architectures
-
-21.4.3 Alpha
-------------
-
-See the following section.
-
-
-File: gdb.info, Node: MIPS, Next: HPPA, Prev: Alpha, Up: Architectures
-
-21.4.4 MIPS
------------
-
-Alpha- and MIPS-based computers use an unusual stack frame, which
-sometimes requires GDB to search backward in the object code to find
-the beginning of a function.
-
- To improve response time (especially for embedded applications, where
-GDB may be restricted to a slow serial line for this search) you may
-want to limit the size of this search, using one of these commands:
-
-`set heuristic-fence-post LIMIT'
- Restrict GDB to examining at most LIMIT bytes in its search for
- the beginning of a function. A value of 0 (the default) means
- there is no limit. However, except for 0, the larger the limit
- the more bytes `heuristic-fence-post' must search and therefore
- the longer it takes to run. You should only need to use this
- command when debugging a stripped executable.
-
-`show heuristic-fence-post'
- Display the current limit.
-
-These commands are available _only_ when GDB is configured for
-debugging programs on Alpha or MIPS processors.
-
- Several MIPS-specific commands are available when debugging MIPS
-programs:
-
-`set mips abi ARG'
- Tell GDB which MIPS ABI is used by the inferior. Possible values
- of ARG are:
-
- `auto'
- The default ABI associated with the current binary (this is
- the default).
-
- `o32'
-
- `o64'
-
- `n32'
-
- `n64'
-
- `eabi32'
-
- `eabi64'
-
- `auto'
-
-`show mips abi'
- Show the MIPS ABI used by GDB to debug the inferior.
-
-`set mipsfpu'
-`show mipsfpu'
- *Note set mipsfpu: MIPS Embedded.
-
-`set mips mask-address ARG'
- This command determines whether the most-significant 32 bits of
- 64-bit MIPS addresses are masked off. The argument ARG can be
- `on', `off', or `auto'. The latter is the default setting, which
- lets GDB determine the correct value.
-
-`show mips mask-address'
- Show whether the upper 32 bits of MIPS addresses are masked off or
- not.
-
-`set remote-mips64-transfers-32bit-regs'
- This command controls compatibility with 64-bit MIPS targets that
- transfer data in 32-bit quantities. If you have an old MIPS 64
- target that transfers 32 bits for some registers, like SR and FSR,
- and 64 bits for other registers, set this option to `on'.
-
-`show remote-mips64-transfers-32bit-regs'
- Show the current setting of compatibility with older MIPS 64
- targets.
-
-`set debug mips'
- This command turns on and off debugging messages for the
- MIPS-specific target code in GDB.
-
-`show debug mips'
- Show the current setting of MIPS debugging messages.
-
-
-File: gdb.info, Node: HPPA, Next: SPU, Prev: MIPS, Up: Architectures
-
-21.4.5 HPPA
------------
-
-When GDB is debugging the HP PA architecture, it provides the following
-special commands:
-
-`set debug hppa'
- This command determines whether HPPA architecture-specific
- debugging messages are to be displayed.
-
-`show debug hppa'
- Show whether HPPA debugging messages are displayed.
-
-`maint print unwind ADDRESS'
- This command displays the contents of the unwind table entry at the
- given ADDRESS.
-
-
-
-File: gdb.info, Node: SPU, Next: PowerPC, Prev: HPPA, Up: Architectures
-
-21.4.6 Cell Broadband Engine SPU architecture
----------------------------------------------
-
-When GDB is debugging the Cell Broadband Engine SPU architecture, it
-provides the following special commands:
-
-`info spu event'
- Display SPU event facility status. Shows current event mask and
- pending event status.
-
-`info spu signal'
- Display SPU signal notification facility status. Shows pending
- signal-control word and signal notification mode of both signal
- notification channels.
-
-`info spu mailbox'
- Display SPU mailbox facility status. Shows all pending entries,
- in order of processing, in each of the SPU Write Outbound, SPU
- Write Outbound Interrupt, and SPU Read Inbound mailboxes.
-
-`info spu dma'
- Display MFC DMA status. Shows all pending commands in the MFC DMA
- queue. For each entry, opcode, tag, class IDs, effective and
- local store addresses and transfer size are shown.
-
-`info spu proxydma'
- Display MFC Proxy-DMA status. Shows all pending commands in the
- MFC Proxy-DMA queue. For each entry, opcode, tag, class IDs,
- effective and local store addresses and transfer size are shown.
-
-
- When GDB is debugging a combined PowerPC/SPU application on the Cell
-Broadband Engine, it provides in addition the following special
-commands:
-
-`set spu stop-on-load ARG'
- Set whether to stop for new SPE threads. When set to `on', GDB
- will give control to the user when a new SPE thread enters its
- `main' function. The default is `off'.
-
-`show spu stop-on-load'
- Show whether to stop for new SPE threads.
-
-`set spu auto-flush-cache ARG'
- Set whether to automatically flush the software-managed cache.
- When set to `on', GDB will automatically cause the SPE
- software-managed cache to be flushed whenever SPE execution stops.
- This provides a consistent view of PowerPC memory that is accessed
- via the cache. If an application does not use the
- software-managed cache, this option has no effect.
-
-`show spu auto-flush-cache'
- Show whether to automatically flush the software-managed cache.
-
-
-
-File: gdb.info, Node: PowerPC, Prev: SPU, Up: Architectures
-
-21.4.7 PowerPC
---------------
-
-When GDB is debugging the PowerPC architecture, it provides a set of
-pseudo-registers to enable inspection of 128-bit wide Decimal Floating
-Point numbers stored in the floating point registers. These values must
-be stored in two consecutive registers, always starting at an even
-register like `f0' or `f2'.
-
- The pseudo-registers go from `$dl0' through `$dl15', and are formed
-by joining the even/odd register pairs `f0' and `f1' for `$dl0', `f2'
-and `f3' for `$dl1' and so on.
-
- For POWER7 processors, GDB provides a set of pseudo-registers, the
-64-bit wide Extended Floating Point Registers (`f32' through `f63').
-
-
-File: gdb.info, Node: Controlling GDB, Next: Extending GDB, Prev: Configurations, Up: Top
-
-22 Controlling GDB
-******************
-
-You can alter the way GDB interacts with you by using the `set'
-command. For commands controlling how GDB displays data, see *note
-Print Settings: Print Settings. Other settings are described here.
-
-* Menu:
-
-* Prompt:: Prompt
-* Editing:: Command editing
-* Command History:: Command history
-* Screen Size:: Screen size
-* Numbers:: Numbers
-* ABI:: Configuring the current ABI
-* Messages/Warnings:: Optional warnings and messages
-* Debugging Output:: Optional messages about internal happenings
-* Other Misc Settings:: Other Miscellaneous Settings
-
-
-File: gdb.info, Node: Prompt, Next: Editing, Up: Controlling GDB
-
-22.1 Prompt
-===========
-
-GDB indicates its readiness to read a command by printing a string
-called the "prompt". This string is normally `(gdb)'. You can change
-the prompt string with the `set prompt' command. For instance, when
-debugging GDB with GDB, it is useful to change the prompt in one of the
-GDB sessions so that you can always tell which one you are talking to.
-
- _Note:_ `set prompt' does not add a space for you after the prompt
-you set. This allows you to set a prompt which ends in a space or a
-prompt that does not.
-
-`set prompt NEWPROMPT'
- Directs GDB to use NEWPROMPT as its prompt string henceforth.
-
-`show prompt'
- Prints a line of the form: `Gdb's prompt is: YOUR-PROMPT'
-
-
-File: gdb.info, Node: Editing, Next: Command History, Prev: Prompt, Up: Controlling GDB
-
-22.2 Command Editing
-====================
-
-GDB reads its input commands via the "Readline" interface. This GNU
-library provides consistent behavior for programs which provide a
-command line interface to the user. Advantages are GNU Emacs-style or
-"vi"-style inline editing of commands, `csh'-like history substitution,
-and a storage and recall of command history across debugging sessions.
-
- You may control the behavior of command line editing in GDB with the
-command `set'.
-
-`set editing'
-`set editing on'
- Enable command line editing (enabled by default).
-
-`set editing off'
- Disable command line editing.
-
-`show editing'
- Show whether command line editing is enabled.
-
- *Note Command Line Editing::, for more details about the Readline
-interface. Users unfamiliar with GNU Emacs or `vi' are encouraged to
-read that chapter.
-
-
-File: gdb.info, Node: Command History, Next: Screen Size, Prev: Editing, Up: Controlling GDB
-
-22.3 Command History
-====================
-
-GDB can keep track of the commands you type during your debugging
-sessions, so that you can be certain of precisely what happened. Use
-these commands to manage the GDB command history facility.
-
- GDB uses the GNU History library, a part of the Readline package, to
-provide the history facility. *Note Using History Interactively::, for
-the detailed description of the History library.
-
- To issue a command to GDB without affecting certain aspects of the
-state which is seen by users, prefix it with `server ' (*note Server
-Prefix::). This means that this command will not affect the command
-history, nor will it affect GDB's notion of which command to repeat if
-<RET> is pressed on a line by itself.
-
- The server prefix does not affect the recording of values into the
-value history; to print a value without recording it into the value
-history, use the `output' command instead of the `print' command.
-
- Here is the description of GDB commands related to command history.
-
-`set history filename FNAME'
- Set the name of the GDB command history file to FNAME. This is
- the file where GDB reads an initial command history list, and
- where it writes the command history from this session when it
- exits. You can access this list through history expansion or
- through the history command editing characters listed below. This
- file defaults to the value of the environment variable
- `GDBHISTFILE', or to `./.gdb_history' (`./_gdb_history' on MS-DOS)
- if this variable is not set.
-
-`set history save'
-`set history save on'
- Record command history in a file, whose name may be specified with
- the `set history filename' command. By default, this option is
- disabled.
-
-`set history save off'
- Stop recording command history in a file.
-
-`set history size SIZE'
- Set the number of commands which GDB keeps in its history list.
- This defaults to the value of the environment variable `HISTSIZE',
- or to 256 if this variable is not set.
-
- History expansion assigns special meaning to the character `!'.
-*Note Event Designators::, for more details.
-
- Since `!' is also the logical not operator in C, history expansion
-is off by default. If you decide to enable history expansion with the
-`set history expansion on' command, you may sometimes need to follow
-`!' (when it is used as logical not, in an expression) with a space or
-a tab to prevent it from being expanded. The readline history
-facilities do not attempt substitution on the strings `!=' and `!(',
-even when history expansion is enabled.
-
- The commands to control history expansion are:
-
-`set history expansion on'
-`set history expansion'
- Enable history expansion. History expansion is off by default.
-
-`set history expansion off'
- Disable history expansion.
-
-`show history'
-`show history filename'
-`show history save'
-`show history size'
-`show history expansion'
- These commands display the state of the GDB history parameters.
- `show history' by itself displays all four states.
-
-`show commands'
- Display the last ten commands in the command history.
-
-`show commands N'
- Print ten commands centered on command number N.
-
-`show commands +'
- Print ten commands just after the commands last printed.
-
-
-File: gdb.info, Node: Screen Size, Next: Numbers, Prev: Command History, Up: Controlling GDB
-
-22.4 Screen Size
-================
-
-Certain commands to GDB may produce large amounts of information output
-to the screen. To help you read all of it, GDB pauses and asks you for
-input at the end of each page of output. Type <RET> when you want to
-continue the output, or `q' to discard the remaining output. Also, the
-screen width setting determines when to wrap lines of output.
-Depending on what is being printed, GDB tries to break the line at a
-readable place, rather than simply letting it overflow onto the
-following line.
-
- Normally GDB knows the size of the screen from the terminal driver
-software. For example, on Unix GDB uses the termcap data base together
-with the value of the `TERM' environment variable and the `stty rows'
-and `stty cols' settings. If this is not correct, you can override it
-with the `set height' and `set width' commands:
-
-`set height LPP'
-`show height'
-`set width CPL'
-`show width'
- These `set' commands specify a screen height of LPP lines and a
- screen width of CPL characters. The associated `show' commands
- display the current settings.
-
- If you specify a height of zero lines, GDB does not pause during
- output no matter how long the output is. This is useful if output
- is to a file or to an editor buffer.
-
- Likewise, you can specify `set width 0' to prevent GDB from
- wrapping its output.
-
-`set pagination on'
-`set pagination off'
- Turn the output pagination on or off; the default is on. Turning
- pagination off is the alternative to `set height 0'. Note that
- running GDB with the `--batch' option (*note -batch: Mode
- Options.) also automatically disables pagination.
-
-`show pagination'
- Show the current pagination mode.
-
-
-File: gdb.info, Node: Numbers, Next: ABI, Prev: Screen Size, Up: Controlling GDB
-
-22.5 Numbers
-============
-
-You can always enter numbers in octal, decimal, or hexadecimal in GDB
-by the usual conventions: octal numbers begin with `0', decimal numbers
-end with `.', and hexadecimal numbers begin with `0x'. Numbers that
-neither begin with `0' or `0x', nor end with a `.' are, by default,
-entered in base 10; likewise, the default display for numbers--when no
-particular format is specified--is base 10. You can change the default
-base for both input and output with the commands described below.
-
-`set input-radix BASE'
- Set the default base for numeric input. Supported choices for
- BASE are decimal 8, 10, or 16. BASE must itself be specified
- either unambiguously or using the current input radix; for
- example, any of
-
- set input-radix 012
- set input-radix 10.
- set input-radix 0xa
-
- sets the input base to decimal. On the other hand, `set
- input-radix 10' leaves the input radix unchanged, no matter what
- it was, since `10', being without any leading or trailing signs of
- its base, is interpreted in the current radix. Thus, if the
- current radix is 16, `10' is interpreted in hex, i.e. as 16
- decimal, which doesn't change the radix.
-
-`set output-radix BASE'
- Set the default base for numeric display. Supported choices for
- BASE are decimal 8, 10, or 16. BASE must itself be specified
- either unambiguously or using the current input radix.
-
-`show input-radix'
- Display the current default base for numeric input.
-
-`show output-radix'
- Display the current default base for numeric display.
-
-`set radix [BASE]'
-`show radix'
- These commands set and show the default base for both input and
- output of numbers. `set radix' sets the radix of input and output
- to the same base; without an argument, it resets the radix back to
- its default value of 10.
-
-
-
-File: gdb.info, Node: ABI, Next: Messages/Warnings, Prev: Numbers, Up: Controlling GDB
-
-22.6 Configuring the Current ABI
-================================
-
-GDB can determine the "ABI" (Application Binary Interface) of your
-application automatically. However, sometimes you need to override its
-conclusions. Use these commands to manage GDB's view of the current
-ABI.
-
- One GDB configuration can debug binaries for multiple operating
-system targets, either via remote debugging or native emulation. GDB
-will autodetect the "OS ABI" (Operating System ABI) in use, but you can
-override its conclusion using the `set osabi' command. One example
-where this is useful is in debugging of binaries which use an alternate
-C library (e.g. UCLIBC for GNU/Linux) which does not have the same
-identifying marks that the standard C library for your platform
-provides.
-
-`show osabi'
- Show the OS ABI currently in use.
-
-`set osabi'
- With no argument, show the list of registered available OS ABI's.
-
-`set osabi ABI'
- Set the current OS ABI to ABI.
-
- Generally, the way that an argument of type `float' is passed to a
-function depends on whether the function is prototyped. For a
-prototyped (i.e. ANSI/ISO style) function, `float' arguments are passed
-unchanged, according to the architecture's convention for `float'. For
-unprototyped (i.e. K&R style) functions, `float' arguments are first
-promoted to type `double' and then passed.
-
- Unfortunately, some forms of debug information do not reliably
-indicate whether a function is prototyped. If GDB calls a function
-that is not marked as prototyped, it consults `set
-coerce-float-to-double'.
-
-`set coerce-float-to-double'
-`set coerce-float-to-double on'
- Arguments of type `float' will be promoted to `double' when passed
- to an unprototyped function. This is the default setting.
-
-`set coerce-float-to-double off'
- Arguments of type `float' will be passed directly to unprototyped
- functions.
-
-`show coerce-float-to-double'
- Show the current setting of promoting `float' to `double'.
-
- GDB needs to know the ABI used for your program's C++ objects. The
-correct C++ ABI depends on which C++ compiler was used to build your
-application. GDB only fully supports programs with a single C++ ABI;
-if your program contains code using multiple C++ ABI's or if GDB can
-not identify your program's ABI correctly, you can tell GDB which ABI
-to use. Currently supported ABI's include "gnu-v2", for `g++' versions
-before 3.0, "gnu-v3", for `g++' versions 3.0 and later, and "hpaCC" for
-the HP ANSI C++ compiler. Other C++ compilers may use the "gnu-v2" or
-"gnu-v3" ABI's as well. The default setting is "auto".
-
-`show cp-abi'
- Show the C++ ABI currently in use.
-
-`set cp-abi'
- With no argument, show the list of supported C++ ABI's.
-
-`set cp-abi ABI'
-`set cp-abi auto'
- Set the current C++ ABI to ABI, or return to automatic detection.
-
-
-File: gdb.info, Node: Messages/Warnings, Next: Debugging Output, Prev: ABI, Up: Controlling GDB
-
-22.7 Optional Warnings and Messages
-===================================
-
-By default, GDB is silent about its inner workings. If you are running
-on a slow machine, you may want to use the `set verbose' command. This
-makes GDB tell you when it does a lengthy internal operation, so you
-will not think it has crashed.
-
- Currently, the messages controlled by `set verbose' are those which
-announce that the symbol table for a source file is being read; see
-`symbol-file' in *note Commands to Specify Files: Files.
-
-`set verbose on'
- Enables GDB output of certain informational messages.
-
-`set verbose off'
- Disables GDB output of certain informational messages.
-
-`show verbose'
- Displays whether `set verbose' is on or off.
-
- By default, if GDB encounters bugs in the symbol table of an object
-file, it is silent; but if you are debugging a compiler, you may find
-this information useful (*note Errors Reading Symbol Files: Symbol
-Errors.).
-
-`set complaints LIMIT'
- Permits GDB to output LIMIT complaints about each type of unusual
- symbols before becoming silent about the problem. Set LIMIT to
- zero to suppress all complaints; set it to a large number to
- prevent complaints from being suppressed.
-
-`show complaints'
- Displays how many symbol complaints GDB is permitted to produce.
-
-
- By default, GDB is cautious, and asks what sometimes seems to be a
-lot of stupid questions to confirm certain commands. For example, if
-you try to run a program which is already running:
-
- (gdb) run
- The program being debugged has been started already.
- Start it from the beginning? (y or n)
-
- If you are willing to unflinchingly face the consequences of your own
-commands, you can disable this "feature":
-
-`set confirm off'
- Disables confirmation requests. Note that running GDB with the
- `--batch' option (*note -batch: Mode Options.) also automatically
- disables confirmation requests.
-
-`set confirm on'
- Enables confirmation requests (the default).
-
-`show confirm'
- Displays state of confirmation requests.
-
-
- If you need to debug user-defined commands or sourced files you may
-find it useful to enable "command tracing". In this mode each command
-will be printed as it is executed, prefixed with one or more `+'
-symbols, the quantity denoting the call depth of each command.
-
-`set trace-commands on'
- Enable command tracing.
-
-`set trace-commands off'
- Disable command tracing.
-
-`show trace-commands'
- Display the current state of command tracing.
-
-
-File: gdb.info, Node: Debugging Output, Next: Other Misc Settings, Prev: Messages/Warnings, Up: Controlling GDB
-
-22.8 Optional Messages about Internal Happenings
-================================================
-
-GDB has commands that enable optional debugging messages from various
-GDB subsystems; normally these commands are of interest to GDB
-maintainers, or when reporting a bug. This section documents those
-commands.
-
-`set exec-done-display'
- Turns on or off the notification of asynchronous commands'
- completion. When on, GDB will print a message when an
- asynchronous command finishes its execution. The default is off.
-
-`show exec-done-display'
- Displays the current setting of asynchronous command completion
- notification.
-
-`set debug arch'
- Turns on or off display of gdbarch debugging info. The default is
- off
-
-`show debug arch'
- Displays the current state of displaying gdbarch debugging info.
-
-`set debug aix-thread'
- Display debugging messages about inner workings of the AIX thread
- module.
-
-`show debug aix-thread'
- Show the current state of AIX thread debugging info display.
-
-`set debug check-physname'
- Check the results of the "physname" computation. When reading
- DWARF debugging information for C++, GDB attempts to compute each
- entity's name. GDB can do this computation in two different ways,
- depending on exactly what information is present. When enabled,
- this setting causes GDB to compute the names both ways and display
- any discrepancies.
-
-`show debug check-physname'
- Show the current state of "physname" checking.
-
-`set debug dwarf2-die'
- Dump DWARF2 DIEs after they are read in. The value is the number
- of nesting levels to print. A value of zero turns off the display.
-
-`show debug dwarf2-die'
- Show the current state of DWARF2 DIE debugging.
-
-`set debug displaced'
- Turns on or off display of GDB debugging info for the displaced
- stepping support. The default is off.
-
-`show debug displaced'
- Displays the current state of displaying GDB debugging info
- related to displaced stepping.
-
-`set debug event'
- Turns on or off display of GDB event debugging info. The default
- is off.
-
-`show debug event'
- Displays the current state of displaying GDB event debugging info.
-
-`set debug expression'
- Turns on or off display of debugging info about GDB expression
- parsing. The default is off.
-
-`show debug expression'
- Displays the current state of displaying debugging info about GDB
- expression parsing.
-
-`set debug frame'
- Turns on or off display of GDB frame debugging info. The default
- is off.
-
-`show debug frame'
- Displays the current state of displaying GDB frame debugging info.
-
-`set debug gnu-nat'
- Turns on or off debugging messages from the GNU/Hurd debug support.
-
-`show debug gnu-nat'
- Show the current state of GNU/Hurd debugging messages.
-
-`set debug infrun'
- Turns on or off display of GDB debugging info for running the
- inferior. The default is off. `infrun.c' contains GDB's runtime
- state machine used for implementing operations such as
- single-stepping the inferior.
-
-`show debug infrun'
- Displays the current state of GDB inferior debugging.
-
-`set debug jit'
- Turns on or off debugging messages from JIT debug support.
-
-`show debug jit'
- Displays the current state of GDB JIT debugging.
-
-`set debug lin-lwp'
- Turns on or off debugging messages from the Linux LWP debug
- support.
-
-`show debug lin-lwp'
- Show the current state of Linux LWP debugging messages.
-
-`set debug lin-lwp-async'
- Turns on or off debugging messages from the Linux LWP async debug
- support.
-
-`show debug lin-lwp-async'
- Show the current state of Linux LWP async debugging messages.
-
-`set debug observer'
- Turns on or off display of GDB observer debugging. This includes
- info such as the notification of observable events.
-
-`show debug observer'
- Displays the current state of observer debugging.
-
-`set debug overload'
- Turns on or off display of GDB C++ overload debugging info. This
- includes info such as ranking of functions, etc. The default is
- off.
-
-`show debug overload'
- Displays the current state of displaying GDB C++ overload
- debugging info.
-
-`set debug parser'
- Turns on or off the display of expression parser debugging output.
- Internally, this sets the `yydebug' variable in the expression
- parser. *Note Tracing Your Parser: (bison)Tracing, for details.
- The default is off.
-
-`show debug parser'
- Show the current state of expression parser debugging.
-
-`set debug remote'
- Turns on or off display of reports on all packets sent back and
- forth across the serial line to the remote machine. The info is
- printed on the GDB standard output stream. The default is off.
-
-`show debug remote'
- Displays the state of display of remote packets.
-
-`set debug serial'
- Turns on or off display of GDB serial debugging info. The default
- is off.
-
-`show debug serial'
- Displays the current state of displaying GDB serial debugging info.
-
-`set debug solib-frv'
- Turns on or off debugging messages for FR-V shared-library code.
-
-`show debug solib-frv'
- Display the current state of FR-V shared-library code debugging
- messages.
-
-`set debug target'
- Turns on or off display of GDB target debugging info. This info
- includes what is going on at the target level of GDB, as it
- happens. The default is 0. Set it to 1 to track events, and to 2
- to also track the value of large memory transfers. Changes to
- this flag do not take effect until the next time you connect to a
- target or use the `run' command.
-
-`show debug target'
- Displays the current state of displaying GDB target debugging info.
-
-`set debug timestamp'
- Turns on or off display of timestamps with GDB debugging info.
- When enabled, seconds and microseconds are displayed before each
- debugging message.
-
-`show debug timestamp'
- Displays the current state of displaying timestamps with GDB
- debugging info.
-
-`set debugvarobj'
- Turns on or off display of GDB variable object debugging info. The
- default is off.
-
-`show debugvarobj'
- Displays the current state of displaying GDB variable object
- debugging info.
-
-`set debug xml'
- Turns on or off debugging messages for built-in XML parsers.
-
-`show debug xml'
- Displays the current state of XML debugging messages.
-
-
-File: gdb.info, Node: Other Misc Settings, Prev: Debugging Output, Up: Controlling GDB
-
-22.9 Other Miscellaneous Settings
-=================================
-
-`set interactive-mode'
- If `on', forces GDB to assume that GDB was started in a terminal.
- In practice, this means that GDB should wait for the user to
- answer queries generated by commands entered at the command
- prompt. If `off', forces GDB to operate in the opposite mode, and
- it uses the default answers to all queries. If `auto' (the
- default), GDB tries to determine whether its standard input is a
- terminal, and works in interactive-mode if it is,
- non-interactively otherwise.
-
- In the vast majority of cases, the debugger should be able to guess
- correctly which mode should be used. But this setting can be
- useful in certain specific cases, such as running a MinGW GDB
- inside a cygwin window.
-
-`show interactive-mode'
- Displays whether the debugger is operating in interactive mode or
- not.
-
-
-File: gdb.info, Node: Extending GDB, Next: Interpreters, Prev: Controlling GDB, Up: Top
-
-23 Extending GDB
-****************
-
-GDB provides two mechanisms for extension. The first is based on
-composition of GDB commands, and the second is based on the Python
-scripting language.
-
- To facilitate the use of these extensions, GDB is capable of
-evaluating the contents of a file. When doing so, GDB can recognize
-which scripting language is being used by looking at the filename
-extension. Files with an unrecognized filename extension are always
-treated as a GDB Command Files. *Note Command files: Command Files.
-
- You can control how GDB evaluates these files with the following
-setting:
-
-`set script-extension off'
- All scripts are always evaluated as GDB Command Files.
-
-`set script-extension soft'
- The debugger determines the scripting language based on filename
- extension. If this scripting language is supported, GDB evaluates
- the script using that language. Otherwise, it evaluates the file
- as a GDB Command File.
-
-`set script-extension strict'
- The debugger determines the scripting language based on filename
- extension, and evaluates the script using that language. If the
- language is not supported, then the evaluation fails.
-
-`show script-extension'
- Display the current value of the `script-extension' option.
-
-
-* Menu:
-
-* Sequences:: Canned Sequences of Commands
-* Python:: Scripting GDB using Python
-
-
-File: gdb.info, Node: Sequences, Next: Python, Up: Extending GDB
-
-23.1 Canned Sequences of Commands
-=================================
-
-Aside from breakpoint commands (*note Breakpoint Command Lists: Break
-Commands.), GDB provides two ways to store sequences of commands for
-execution as a unit: user-defined commands and command files.
-
-* Menu:
-
-* Define:: How to define your own commands
-* Hooks:: Hooks for user-defined commands
-* Command Files:: How to write scripts of commands to be stored in a file
-* Output:: Commands for controlled output
-
-
-File: gdb.info, Node: Define, Next: Hooks, Up: Sequences
-
-23.1.1 User-defined Commands
-----------------------------
-
-A "user-defined command" is a sequence of GDB commands to which you
-assign a new name as a command. This is done with the `define'
-command. User commands may accept up to 10 arguments separated by
-whitespace. Arguments are accessed within the user command via
-`$arg0...$arg9'. A trivial example:
-
- define adder
- print $arg0 + $arg1 + $arg2
- end
-
-To execute the command use:
-
- adder 1 2 3
-
-This defines the command `adder', which prints the sum of its three
-arguments. Note the arguments are text substitutions, so they may
-reference variables, use complex expressions, or even perform inferior
-functions calls.
-
- In addition, `$argc' may be used to find out how many arguments have
-been passed. This expands to a number in the range 0...10.
-
- define adder
- if $argc == 2
- print $arg0 + $arg1
- end
- if $argc == 3
- print $arg0 + $arg1 + $arg2
- end
- end
-
-`define COMMANDNAME'
- Define a command named COMMANDNAME. If there is already a command
- by that name, you are asked to confirm that you want to redefine
- it. COMMANDNAME may be a bare command name consisting of letters,
- numbers, dashes, and underscores. It may also start with any
- predefined prefix command. For example, `define target my-target'
- creates a user-defined `target my-target' command.
-
- The definition of the command is made up of other GDB command
- lines, which are given following the `define' command. The end of
- these commands is marked by a line containing `end'.
-
-`document COMMANDNAME'
- Document the user-defined command COMMANDNAME, so that it can be
- accessed by `help'. The command COMMANDNAME must already be
- defined. This command reads lines of documentation just as
- `define' reads the lines of the command definition, ending with
- `end'. After the `document' command is finished, `help' on command
- COMMANDNAME displays the documentation you have written.
-
- You may use the `document' command again to change the
- documentation of a command. Redefining the command with `define'
- does not change the documentation.
-
-`dont-repeat'
- Used inside a user-defined command, this tells GDB that this
- command should not be repeated when the user hits <RET> (*note
- repeat last command: Command Syntax.).
-
-`help user-defined'
- List all user-defined commands, with the first line of the
- documentation (if any) for each.
-
-`show user'
-`show user COMMANDNAME'
- Display the GDB commands used to define COMMANDNAME (but not its
- documentation). If no COMMANDNAME is given, display the
- definitions for all user-defined commands.
-
-`show max-user-call-depth'
-`set max-user-call-depth'
- The value of `max-user-call-depth' controls how many recursion
- levels are allowed in user-defined commands before GDB suspects an
- infinite recursion and aborts the command.
-
- In addition to the above commands, user-defined commands frequently
-use control flow commands, described in *note Command Files::.
-
- When user-defined commands are executed, the commands of the
-definition are not printed. An error in any command stops execution of
-the user-defined command.
-
- If used interactively, commands that would ask for confirmation
-proceed without asking when used inside a user-defined command. Many
-GDB commands that normally print messages to say what they are doing
-omit the messages when used in a user-defined command.
-
-
-File: gdb.info, Node: Hooks, Next: Command Files, Prev: Define, Up: Sequences
-
-23.1.2 User-defined Command Hooks
----------------------------------
-
-You may define "hooks", which are a special kind of user-defined
-command. Whenever you run the command `foo', if the user-defined
-command `hook-foo' exists, it is executed (with no arguments) before
-that command.
-
- A hook may also be defined which is run after the command you
-executed. Whenever you run the command `foo', if the user-defined
-command `hookpost-foo' exists, it is executed (with no arguments) after
-that command. Post-execution hooks may exist simultaneously with
-pre-execution hooks, for the same command.
-
- It is valid for a hook to call the command which it hooks. If this
-occurs, the hook is not re-executed, thereby avoiding infinite
-recursion.
-
- In addition, a pseudo-command, `stop' exists. Defining
-(`hook-stop') makes the associated commands execute every time
-execution stops in your program: before breakpoint commands are run,
-displays are printed, or the stack frame is printed.
-
- For example, to ignore `SIGALRM' signals while single-stepping, but
-treat them normally during normal execution, you could define:
-
- define hook-stop
- handle SIGALRM nopass
- end
-
- define hook-run
- handle SIGALRM pass
- end
-
- define hook-continue
- handle SIGALRM pass
- end
-
- As a further example, to hook at the beginning and end of the `echo'
-command, and to add extra text to the beginning and end of the message,
-you could define:
-
- define hook-echo
- echo <<<---
- end
-
- define hookpost-echo
- echo --->>>\n
- end
-
- (gdb) echo Hello World
- <<<---Hello World--->>>
- (gdb)
-
- You can define a hook for any single-word command in GDB, but not
-for command aliases; you should define a hook for the basic command
-name, e.g. `backtrace' rather than `bt'. You can hook a multi-word
-command by adding `hook-' or `hookpost-' to the last word of the
-command, e.g. `define target hook-remote' to add a hook to `target
-remote'.
-
- If an error occurs during the execution of your hook, execution of
-GDB commands stops and GDB issues a prompt (before the command that you
-actually typed had a chance to run).
-
- If you try to define a hook which does not match any known command,
-you get a warning from the `define' command.
-
-
-File: gdb.info, Node: Command Files, Next: Output, Prev: Hooks, Up: Sequences
-
-23.1.3 Command Files
---------------------
-
-A command file for GDB is a text file made of lines that are GDB
-commands. Comments (lines starting with `#') may also be included. An
-empty line in a command file does nothing; it does not mean to repeat
-the last command, as it would from the terminal.
-
- You can request the execution of a command file with the `source'
-command. Note that the `source' command is also used to evaluate
-scripts that are not Command Files. The exact behavior can be
-configured using the `script-extension' setting. *Note Extending GDB:
-Extending GDB.
-
-`source [-s] [-v] FILENAME'
- Execute the command file FILENAME.
-
- The lines in a command file are generally executed sequentially,
-unless the order of execution is changed by one of the _flow-control
-commands_ described below. The commands are not printed as they are
-executed. An error in any command terminates execution of the command
-file and control is returned to the console.
-
- GDB first searches for FILENAME in the current directory. If the
-file is not found there, and FILENAME does not specify a directory,
-then GDB also looks for the file on the source search path (specified
-with the `directory' command); except that `$cdir' is not searched
-because the compilation directory is not relevant to scripts.
-
- If `-s' is specified, then GDB searches for FILENAME on the search
-path even if FILENAME specifies a directory. The search is done by
-appending FILENAME to each element of the search path. So, for
-example, if FILENAME is `mylib/myscript' and the search path contains
-`/home/user' then GDB will look for the script
-`/home/user/mylib/myscript'. The search is also done if FILENAME is an
-absolute path. For example, if FILENAME is `/tmp/myscript' and the
-search path contains `/home/user' then GDB will look for the script
-`/home/user/tmp/myscript'. For DOS-like systems, if FILENAME contains
-a drive specification, it is stripped before concatenation. For
-example, if FILENAME is `d:myscript' and the search path contains
-`c:/tmp' then GDB will look for the script `c:/tmp/myscript'.
-
- If `-v', for verbose mode, is given then GDB displays each command
-as it is executed. The option must be given before FILENAME, and is
-interpreted as part of the filename anywhere else.
-
- Commands that would ask for confirmation if used interactively
-proceed without asking when used in a command file. Many GDB commands
-that normally print messages to say what they are doing omit the
-messages when called from command files.
-
- GDB also accepts command input from standard input. In this mode,
-normal output goes to standard output and error output goes to standard
-error. Errors in a command file supplied on standard input do not
-terminate execution of the command file--execution continues with the
-next command.
-
- gdb < cmds > log 2>&1
-
- (The syntax above will vary depending on the shell used.) This
-example will execute commands from the file `cmds'. All output and
-errors would be directed to `log'.
-
- Since commands stored on command files tend to be more general than
-commands typed interactively, they frequently need to deal with
-complicated situations, such as different or unexpected values of
-variables and symbols, changes in how the program being debugged is
-built, etc. GDB provides a set of flow-control commands to deal with
-these complexities. Using these commands, you can write complex
-scripts that loop over data structures, execute commands conditionally,
-etc.
-
-`if'
-`else'
- This command allows to include in your script conditionally
- executed commands. The `if' command takes a single argument, which
- is an expression to evaluate. It is followed by a series of
- commands that are executed only if the expression is true (its
- value is nonzero). There can then optionally be an `else' line,
- followed by a series of commands that are only executed if the
- expression was false. The end of the list is marked by a line
- containing `end'.
-
-`while'
- This command allows to write loops. Its syntax is similar to
- `if': the command takes a single argument, which is an expression
- to evaluate, and must be followed by the commands to execute, one
- per line, terminated by an `end'. These commands are called the
- "body" of the loop. The commands in the body of `while' are
- executed repeatedly as long as the expression evaluates to true.
-
-`loop_break'
- This command exits the `while' loop in whose body it is included.
- Execution of the script continues after that `while's `end' line.
-
-`loop_continue'
- This command skips the execution of the rest of the body of
- commands in the `while' loop in whose body it is included.
- Execution branches to the beginning of the `while' loop, where it
- evaluates the controlling expression.
-
-`end'
- Terminate the block of commands that are the body of `if', `else',
- or `while' flow-control commands.
-
-
-File: gdb.info, Node: Output, Prev: Command Files, Up: Sequences
-
-23.1.4 Commands for Controlled Output
--------------------------------------
-
-During the execution of a command file or a user-defined command, normal
-GDB output is suppressed; the only output that appears is what is
-explicitly printed by the commands in the definition. This section
-describes three commands useful for generating exactly the output you
-want.
-
-`echo TEXT'
- Print TEXT. Nonprinting characters can be included in TEXT using
- C escape sequences, such as `\n' to print a newline. *No newline
- is printed unless you specify one.* In addition to the standard C
- escape sequences, a backslash followed by a space stands for a
- space. This is useful for displaying a string with spaces at the
- beginning or the end, since leading and trailing spaces are
- otherwise trimmed from all arguments. To print ` and foo = ', use
- the command `echo \ and foo = \ '.
-
- A backslash at the end of TEXT can be used, as in C, to continue
- the command onto subsequent lines. For example,
-
- echo This is some text\n\
- which is continued\n\
- onto several lines.\n
-
- produces the same output as
-
- echo This is some text\n
- echo which is continued\n
- echo onto several lines.\n
-
-`output EXPRESSION'
- Print the value of EXPRESSION and nothing but that value: no
- newlines, no `$NN = '. The value is not entered in the value
- history either. *Note Expressions: Expressions, for more
- information on expressions.
-
-`output/FMT EXPRESSION'
- Print the value of EXPRESSION in format FMT. You can use the same
- formats as for `print'. *Note Output Formats: Output Formats, for
- more information.
-
-`printf TEMPLATE, EXPRESSIONS...'
- Print the values of one or more EXPRESSIONS under the control of
- the string TEMPLATE. To print several values, make EXPRESSIONS be
- a comma-separated list of individual expressions, which may be
- either numbers or pointers. Their values are printed as specified
- by TEMPLATE, exactly as a C program would do by executing the code
- below:
-
- printf (TEMPLATE, EXPRESSIONS...);
-
- As in `C' `printf', ordinary characters in TEMPLATE are printed
- verbatim, while "conversion specification" introduced by the `%'
- character cause subsequent EXPRESSIONS to be evaluated, their
- values converted and formatted according to type and style
- information encoded in the conversion specifications, and then
- printed.
-
- For example, you can print two values in hex like this:
-
- printf "foo, bar-foo = 0x%x, 0x%x\n", foo, bar-foo
-
- `printf' supports all the standard `C' conversion specifications,
- including the flags and modifiers between the `%' character and
- the conversion letter, with the following exceptions:
-
- * The argument-ordering modifiers, such as `2$', are not
- supported.
-
- * The modifier `*' is not supported for specifying precision or
- width.
-
- * The `'' flag (for separation of digits into groups according
- to `LC_NUMERIC'') is not supported.
-
- * The type modifiers `hh', `j', `t', and `z' are not supported.
-
- * The conversion letter `n' (as in `%n') is not supported.
-
- * The conversion letters `a' and `A' are not supported.
-
- Note that the `ll' type modifier is supported only if the
- underlying `C' implementation used to build GDB supports the `long
- long int' type, and the `L' type modifier is supported only if
- `long double' type is available.
-
- As in `C', `printf' supports simple backslash-escape sequences,
- such as `\n', `\t', `\\', `\"', `\a', and `\f', that consist of
- backslash followed by a single character. Octal and hexadecimal
- escape sequences are not supported.
-
- Additionally, `printf' supports conversion specifications for DFP
- ("Decimal Floating Point") types using the following length
- modifiers together with a floating point specifier. letters:
-
- * `H' for printing `Decimal32' types.
-
- * `D' for printing `Decimal64' types.
-
- * `DD' for printing `Decimal128' types.
-
- If the underlying `C' implementation used to build GDB has support
- for the three length modifiers for DFP types, other modifiers such
- as width and precision will also be available for GDB to use.
-
- In case there is no such `C' support, no additional modifiers will
- be available and the value will be printed in the standard way.
-
- Here's an example of printing DFP types using the above conversion
- letters:
- printf "D32: %Hf - D64: %Df - D128: %DDf\n",1.2345df,1.2E10dd,1.2E1dl
-
-`eval TEMPLATE, EXPRESSIONS...'
- Convert the values of one or more EXPRESSIONS under the control of
- the string TEMPLATE to a command line, and call it.
-
-
-
-File: gdb.info, Node: Python, Prev: Sequences, Up: Extending GDB
-
-23.2 Scripting GDB using Python
-===============================
-
-You can script GDB using the Python programming language
-(http://www.python.org/). This feature is available only if GDB was
-configured using `--with-python'.
-
- Python scripts used by GDB should be installed in
-`DATA-DIRECTORY/python', where DATA-DIRECTORY is the data directory as
-determined at GDB startup (*note Data Files::). This directory, known
-as the "python directory", is automatically added to the Python Search
-Path in order to allow the Python interpreter to locate all scripts
-installed at this location.
-
-* Menu:
-
-* Python Commands:: Accessing Python from GDB.
-* Python API:: Accessing GDB from Python.
-* Auto-loading:: Automatically loading Python code.
-* Python modules:: Python modules provided by GDB.
-
-
-File: gdb.info, Node: Python Commands, Next: Python API, Up: Python
-
-23.2.1 Python Commands
-----------------------
-
-GDB provides one command for accessing the Python interpreter, and one
-related setting:
-
-`python [CODE]'
- The `python' command can be used to evaluate Python code.
-
- If given an argument, the `python' command will evaluate the
- argument as a Python command. For example:
-
- (gdb) python print 23
- 23
-
- If you do not provide an argument to `python', it will act as a
- multi-line command, like `define'. In this case, the Python
- script is made up of subsequent command lines, given after the
- `python' command. This command list is terminated using a line
- containing `end'. For example:
-
- (gdb) python
- Type python script
- End with a line saying just "end".
- >print 23
- >end
- 23
-
-`maint set python print-stack'
- By default, GDB will print a stack trace when an error occurs in a
- Python script. This can be controlled using `maint set python
- print-stack': if `on', the default, then Python stack printing is
- enabled; if `off', then Python stack printing is disabled.
-
- It is also possible to execute a Python script from the GDB
-interpreter:
-
-`source `script-name''
- The script name must end with `.py' and GDB must be configured to
- recognize the script language based on filename extension using
- the `script-extension' setting. *Note Extending GDB: Extending
- GDB.
-
-`python execfile ("script-name")'
- This method is based on the `execfile' Python built-in function,
- and thus is always available.
-
-
-File: gdb.info, Node: Python API, Next: Auto-loading, Prev: Python Commands, Up: Python
-
-23.2.2 Python API
------------------
-
-At startup, GDB overrides Python's `sys.stdout' and `sys.stderr' to
-print using GDB's output-paging streams. A Python program which
-outputs to one of these streams may have its output interrupted by the
-user (*note Screen Size::). In this situation, a Python
-`KeyboardInterrupt' exception is thrown.
-
-* Menu:
-
-* Basic Python:: Basic Python Functions.
-* Exception Handling:: How Python exceptions are translated.
-* Values From Inferior:: Python representation of values.
-* Types In Python:: Python representation of types.
-* Pretty Printing API:: Pretty-printing values.
-* Selecting Pretty-Printers:: How GDB chooses a pretty-printer.
-* Writing a Pretty-Printer:: Writing a Pretty-Printer.
-* Inferiors In Python:: Python representation of inferiors (processes)
-* Events In Python:: Listening for events from GDB.
-* Threads In Python:: Accessing inferior threads from Python.
-* Commands In Python:: Implementing new commands in Python.
-* Parameters In Python:: Adding new GDB parameters.
-* Functions In Python:: Writing new convenience functions.
-* Progspaces In Python:: Program spaces.
-* Objfiles In Python:: Object files.
-* Frames In Python:: Accessing inferior stack frames from Python.
-* Blocks In Python:: Accessing frame blocks from Python.
-* Symbols In Python:: Python representation of symbols.
-* Symbol Tables In Python:: Python representation of symbol tables.
-* Lazy Strings In Python:: Python representation of lazy strings.
-* Breakpoints In Python:: Manipulating breakpoints using Python.
-
-
-File: gdb.info, Node: Basic Python, Next: Exception Handling, Up: Python API
-
-23.2.2.1 Basic Python
-.....................
-
-GDB introduces a new Python module, named `gdb'. All methods and
-classes added by GDB are placed in this module. GDB automatically
-`import's the `gdb' module for use in all scripts evaluated by the
-`python' command.
-
- -- Variable: PYTHONDIR
- A string containing the python directory (*note Python::).
-
- -- Function: execute command [from_tty] [to_string]
- Evaluate COMMAND, a string, as a GDB CLI command. If a GDB
- exception happens while COMMAND runs, it is translated as
- described in *note Exception Handling: Exception Handling.
-
- FROM_TTY specifies whether GDB ought to consider this command as
- having originated from the user invoking it interactively. It
- must be a boolean value. If omitted, it defaults to `False'.
-
- By default, any output produced by COMMAND is sent to GDB's
- standard output. If the TO_STRING parameter is `True', then
- output will be collected by `gdb.execute' and returned as a
- string. The default is `False', in which case the return value is
- `None'. If TO_STRING is `True', the GDB virtual terminal will be
- temporarily set to unlimited width and height, and its pagination
- will be disabled; *note Screen Size::.
-
- -- Function: breakpoints
- Return a sequence holding all of GDB's breakpoints. *Note
- Breakpoints In Python::, for more information.
-
- -- Function: parameter parameter
- Return the value of a GDB parameter. PARAMETER is a string naming
- the parameter to look up; PARAMETER may contain spaces if the
- parameter has a multi-part name. For example, `print object' is a
- valid parameter name.
-
- If the named parameter does not exist, this function throws a
- `gdb.error' (*note Exception Handling::). Otherwise, the
- parameter's value is converted to a Python value of the appropriate
- type, and returned.
-
- -- Function: history number
- Return a value from GDB's value history (*note Value History::).
- NUMBER indicates which history element to return. If NUMBER is
- negative, then GDB will take its absolute value and count backward
- from the last element (i.e., the most recent element) to find the
- value to return. If NUMBER is zero, then GDB will return the most
- recent element. If the element specified by NUMBER doesn't exist
- in the value history, a `gdb.error' exception will be raised.
-
- If no exception is raised, the return value is always an instance
- of `gdb.Value' (*note Values From Inferior::).
-
- -- Function: parse_and_eval expression
- Parse EXPRESSION as an expression in the current language,
- evaluate it, and return the result as a `gdb.Value'. EXPRESSION
- must be a string.
-
- This function can be useful when implementing a new command (*note
- Commands In Python::), as it provides a way to parse the command's
- argument as an expression. It is also useful simply to compute
- values, for example, it is the only way to get the value of a
- convenience variable (*note Convenience Vars::) as a `gdb.Value'.
-
- -- Function: post_event event
- Put EVENT, a callable object taking no arguments, into GDB's
- internal event queue. This callable will be invoked at some later
- point, during GDB's event processing. Events posted using
- `post_event' will be run in the order in which they were posted;
- however, there is no way to know when they will be processed
- relative to other events inside GDB.
-
- GDB is not thread-safe. If your Python program uses multiple
- threads, you must be careful to only call GDB-specific functions
- in the main GDB thread. `post_event' ensures this. For example:
-
- (gdb) python
- >import threading
- >
- >class Writer():
- > def __init__(self, message):
- > self.message = message;
- > def __call__(self):
- > gdb.write(self.message)
- >
- >class MyThread1 (threading.Thread):
- > def run (self):
- > gdb.post_event(Writer("Hello "))
- >
- >class MyThread2 (threading.Thread):
- > def run (self):
- > gdb.post_event(Writer("World\n"))
- >
- >MyThread1().start()
- >MyThread2().start()
- >end
- (gdb) Hello World
-
- -- Function: write string [stream]
- Print a string to GDB's paginated output stream. The optional
- STREAM determines the stream to print to. The default stream is
- GDB's standard output stream. Possible stream values are:
-
- `STDOUT'
- GDB's standard output stream.
-
- `STDERR'
- GDB's standard error stream.
-
- `STDLOG'
- GDB's log stream (*note Logging Output::).
-
- Writing to `sys.stdout' or `sys.stderr' will automatically call
- this function and will automatically direct the output to the
- relevant stream.
-
- -- Function: flush
- Flush the buffer of a GDB paginated stream so that the contents
- are displayed immediately. GDB will flush the contents of a
- stream automatically when it encounters a newline in the buffer.
- The optional STREAM determines the stream to flush. The default
- stream is GDB's standard output stream. Possible stream values
- are:
-
- `STDOUT'
- GDB's standard output stream.
-
- `STDERR'
- GDB's standard error stream.
-
- `STDLOG'
- GDB's log stream (*note Logging Output::).
-
-
- Flushing `sys.stdout' or `sys.stderr' will automatically call this
- function for the relevant stream.
-
- -- Function: target_charset
- Return the name of the current target character set (*note
- Character Sets::). This differs from
- `gdb.parameter('target-charset')' in that `auto' is never returned.
-
- -- Function: target_wide_charset
- Return the name of the current target wide character set (*note
- Character Sets::). This differs from
- `gdb.parameter('target-wide-charset')' in that `auto' is never
- returned.
-
- -- Function: solib_name address
- Return the name of the shared library holding the given ADDRESS as
- a string, or `None'.
-
- -- Function: decode_line [expression]
- Return locations of the line specified by EXPRESSION, or of the
- current line if no argument was given. This function returns a
- Python tuple containing two elements. The first element contains
- a string holding any unparsed section of EXPRESSION (or `None' if
- the expression has been fully parsed). The second element contains
- either `None' or another tuple that contains all the locations
- that match the expression represented as `gdb.Symtab_and_line'
- objects (*note Symbol Tables In Python::). If EXPRESSION is
- provided, it is decoded the way that GDB's inbuilt `break' or
- `edit' commands do (*note Specify Location::).
-
-
-File: gdb.info, Node: Exception Handling, Next: Values From Inferior, Prev: Basic Python, Up: Python API
-
-23.2.2.2 Exception Handling
-...........................
-
-When executing the `python' command, Python exceptions uncaught within
-the Python code are translated to calls to GDB error-reporting
-mechanism. If the command that called `python' does not handle the
-error, GDB will terminate it and print an error message containing the
-Python exception name, the associated value, and the Python call stack
-backtrace at the point where the exception was raised. Example:
-
- (gdb) python print foo
- Traceback (most recent call last):
- File "<string>", line 1, in <module>
- NameError: name 'foo' is not defined
-
- GDB errors that happen in GDB commands invoked by Python code are
-converted to Python exceptions. The type of the Python exception
-depends on the error.
-
-`gdb.error'
- This is the base class for most exceptions generated by GDB. It
- is derived from `RuntimeError', for compatibility with earlier
- versions of GDB.
-
- If an error occurring in GDB does not fit into some more specific
- category, then the generated exception will have this type.
-
-`gdb.MemoryError'
- This is a subclass of `gdb.error' which is thrown when an
- operation tried to access invalid memory in the inferior.
-
-`KeyboardInterrupt'
- User interrupt (via `C-c' or by typing `q' at a pagination prompt)
- is translated to a Python `KeyboardInterrupt' exception.
-
- In all cases, your exception handler will see the GDB error message
-as its value and the Python call stack backtrace at the Python
-statement closest to where the GDB error occured as the traceback.
-
- When implementing GDB commands in Python via `gdb.Command', it is
-useful to be able to throw an exception that doesn't cause a traceback
-to be printed. For example, the user may have invoked the command
-incorrectly. Use the `gdb.GdbError' exception to handle this case.
-Example:
-
- (gdb) python
- >class HelloWorld (gdb.Command):
- > """Greet the whole world."""
- > def __init__ (self):
- > super (HelloWorld, self).__init__ ("hello-world", gdb.COMMAND_OBSCURE)
- > def invoke (self, args, from_tty):
- > argv = gdb.string_to_argv (args)
- > if len (argv) != 0:
- > raise gdb.GdbError ("hello-world takes no arguments")
- > print "Hello, World!"
- >HelloWorld ()
- >end
- (gdb) hello-world 42
- hello-world takes no arguments
-
-
-File: gdb.info, Node: Values From Inferior, Next: Types In Python, Prev: Exception Handling, Up: Python API
-
-23.2.2.3 Values From Inferior
-.............................
-
-GDB provides values it obtains from the inferior program in an object
-of type `gdb.Value'. GDB uses this object for its internal bookkeeping
-of the inferior's values, and for fetching values when necessary.
-
- Inferior values that are simple scalars can be used directly in
-Python expressions that are valid for the value's data type. Here's an
-example for an integer or floating-point value `some_val':
-
- bar = some_val + 2
-
-As result of this, `bar' will also be a `gdb.Value' object whose values
-are of the same type as those of `some_val'.
-
- Inferior values that are structures or instances of some class can
-be accessed using the Python "dictionary syntax". For example, if
-`some_val' is a `gdb.Value' instance holding a structure, you can
-access its `foo' element with:
-
- bar = some_val['foo']
-
- Again, `bar' will also be a `gdb.Value' object.
-
- A `gdb.Value' that represents a function can be executed via
-inferior function call. Any arguments provided to the call must match
-the function's prototype, and must be provided in the order specified
-by that prototype.
-
- For example, `some_val' is a `gdb.Value' instance representing a
-function that takes two integers as arguments. To execute this
-function, call it like so:
-
- result = some_val (10,20)
-
- Any values returned from a function call will be stored as a
-`gdb.Value'.
-
- The following attributes are provided:
-
- -- Instance Variable of Value: address
- If this object is addressable, this read-only attribute holds
- a `gdb.Value' object representing the address. Otherwise,
- this attribute holds `None'.
-
- -- Instance Variable of Value: is_optimized_out
- This read-only boolean attribute is true if the compiler
- optimized out this value, thus it is not available for
- fetching from the inferior.
-
- -- Instance Variable of Value: type
- The type of this `gdb.Value'. The value of this attribute is
- a `gdb.Type' object (*note Types In Python::).
-
- -- Instance Variable of Value: dynamic_type
- The dynamic type of this `gdb.Value'. This uses C++ run-time
- type information (RTTI) to determine the dynamic type of the
- value. If this value is of class type, it will return the
- class in which the value is embedded, if any. If this value
- is of pointer or reference to a class type, it will compute
- the dynamic type of the referenced object, and return a
- pointer or reference to that type, respectively. In all
- other cases, it will return the value's static type.
-
- Note that this feature will only work when debugging a C++
- program that includes RTTI for the object in question.
- Otherwise, it will just return the static type of the value
- as in `ptype foo' (*note ptype: Symbols.).
-
- The following methods are provided:
-
- -- Method on Value: __init__ VAL
- Many Python values can be converted directly to a `gdb.Value'
- via this object initializer. Specifically:
-
- Python boolean
- A Python boolean is converted to the boolean type from
- the current language.
-
- Python integer
- A Python integer is converted to the C `long' type for
- the current architecture.
-
- Python long
- A Python long is converted to the C `long long' type for
- the current architecture.
-
- Python float
- A Python float is converted to the C `double' type for
- the current architecture.
-
- Python string
- A Python string is converted to a target string, using
- the current target encoding.
-
- `gdb.Value'
- If `val' is a `gdb.Value', then a copy of the value is
- made.
-
- `gdb.LazyString'
- If `val' is a `gdb.LazyString' (*note Lazy Strings In
- Python::), then the lazy string's `value' method is
- called, and its result is used.
-
- -- Method on Value: cast type
- Return a new instance of `gdb.Value' that is the result of
- casting this instance to the type described by TYPE, which
- must be a `gdb.Type' object. If the cast cannot be performed
- for some reason, this method throws an exception.
-
- -- Method on Value: dereference
- For pointer data types, this method returns a new `gdb.Value'
- object whose contents is the object pointed to by the
- pointer. For example, if `foo' is a C pointer to an `int',
- declared in your C program as
-
- int *foo;
-
- then you can use the corresponding `gdb.Value' to access what
- `foo' points to like this:
-
- bar = foo.dereference ()
-
- The result `bar' will be a `gdb.Value' object holding the
- value pointed to by `foo'.
-
- -- Method on Value: dynamic_cast type
- Like `Value.cast', but works as if the C++ `dynamic_cast'
- operator were used. Consult a C++ reference for details.
-
- -- Method on Value: reinterpret_cast type
- Like `Value.cast', but works as if the C++ `reinterpret_cast'
- operator were used. Consult a C++ reference for details.
-
- -- Method on Value: string [encoding] [errors] [length]
- If this `gdb.Value' represents a string, then this method
- converts the contents to a Python string. Otherwise, this
- method will throw an exception.
-
- Strings are recognized in a language-specific way; whether a
- given `gdb.Value' represents a string is determined by the
- current language.
-
- For C-like languages, a value is a string if it is a pointer
- to or an array of characters or ints. The string is assumed
- to be terminated by a zero of the appropriate width. However
- if the optional length argument is given, the string will be
- converted to that given length, ignoring any embedded zeros
- that the string may contain.
-
- If the optional ENCODING argument is given, it must be a
- string naming the encoding of the string in the `gdb.Value',
- such as `"ascii"', `"iso-8859-6"' or `"utf-8"'. It accepts
- the same encodings as the corresponding argument to Python's
- `string.decode' method, and the Python codec machinery will
- be used to convert the string. If ENCODING is not given, or
- if ENCODING is the empty string, then either the
- `target-charset' (*note Character Sets::) will be used, or a
- language-specific encoding will be used, if the current
- language is able to supply one.
-
- The optional ERRORS argument is the same as the corresponding
- argument to Python's `string.decode' method.
-
- If the optional LENGTH argument is given, the string will be
- fetched and converted to the given length.
-
- -- Method on Value: lazy_string [encoding] [length]
- If this `gdb.Value' represents a string, then this method
- converts the contents to a `gdb.LazyString' (*note Lazy
- Strings In Python::). Otherwise, this method will throw an
- exception.
-
- If the optional ENCODING argument is given, it must be a
- string naming the encoding of the `gdb.LazyString'. Some
- examples are: `ascii', `iso-8859-6' or `utf-8'. If the
- ENCODING argument is an encoding that GDB does recognize, GDB
- will raise an error.
-
- When a lazy string is printed, the GDB encoding machinery is
- used to convert the string during printing. If the optional
- ENCODING argument is not provided, or is an empty string, GDB
- will automatically select the encoding most suitable for the
- string type. For further information on encoding in GDB
- please see *note Character Sets::.
-
- If the optional LENGTH argument is given, the string will be
- fetched and encoded to the length of characters specified. If
- the LENGTH argument is not provided, the string will be
- fetched and encoded until a null of appropriate width is
- found.
-
-
-File: gdb.info, Node: Types In Python, Next: Pretty Printing API, Prev: Values From Inferior, Up: Python API
-
-23.2.2.4 Types In Python
-........................
-
-GDB represents types from the inferior using the class `gdb.Type'.
-
- The following type-related functions are available in the `gdb'
-module:
-
- -- Function: lookup_type name [block]
- This function looks up a type by name. NAME is the name of the
- type to look up. It must be a string.
-
- If BLOCK is given, then NAME is looked up in that scope.
- Otherwise, it is searched for globally.
-
- Ordinarily, this function will return an instance of `gdb.Type'.
- If the named type cannot be found, it will throw an exception.
-
- An instance of `Type' has the following attributes:
-
- -- Instance Variable of Type: code
- The type code for this type. The type code will be one of the
- `TYPE_CODE_' constants defined below.
-
- -- Instance Variable of Type: sizeof
- The size of this type, in target `char' units. Usually, a
- target's `char' type will be an 8-bit byte. However, on some
- unusual platforms, this type may have a different size.
-
- -- Instance Variable of Type: tag
- The tag name for this type. The tag name is the name after
- `struct', `union', or `enum' in C and C++; not all languages
- have this concept. If this type has no tag name, then `None'
- is returned.
-
- The following methods are provided:
-
- -- Method on Type: fields
- For structure and union types, this method returns the
- fields. Range types have two fields, the minimum and maximum
- values. Enum types have one field per enum constant.
- Function and method types have one field per parameter. The
- base types of C++ classes are also represented as fields. If
- the type has no fields, or does not fit into one of these
- categories, an empty sequence will be returned.
-
- Each field is an object, with some pre-defined attributes:
- `bitpos'
- This attribute is not available for `static' fields (as
- in C++ or Java). For non-`static' fields, the value is
- the bit position of the field.
-
- `name'
- The name of the field, or `None' for anonymous fields.
-
- `artificial'
- This is `True' if the field is artificial, usually
- meaning that it was provided by the compiler and not the
- user. This attribute is always provided, and is `False'
- if the field is not artificial.
-
- `is_base_class'
- This is `True' if the field represents a base class of a
- C++ structure. This attribute is always provided, and
- is `False' if the field is not a base class of the type
- that is the argument of `fields', or if that type was
- not a C++ class.
-
- `bitsize'
- If the field is packed, or is a bitfield, then this will
- have a non-zero value, which is the size of the field in
- bits. Otherwise, this will be zero; in this case the
- field's size is given by its type.
-
- `type'
- The type of the field. This is usually an instance of
- `Type', but it can be `None' in some situations.
-
- -- Method on Type: array N1 [N2]
- Return a new `gdb.Type' object which represents an array of
- this type. If one argument is given, it is the inclusive
- upper bound of the array; in this case the lower bound is
- zero. If two arguments are given, the first argument is the
- lower bound of the array, and the second argument is the
- upper bound of the array. An array's length must not be
- negative, but the bounds can be.
-
- -- Method on Type: const
- Return a new `gdb.Type' object which represents a
- `const'-qualified variant of this type.
-
- -- Method on Type: volatile
- Return a new `gdb.Type' object which represents a
- `volatile'-qualified variant of this type.
-
- -- Method on Type: unqualified
- Return a new `gdb.Type' object which represents an unqualified
- variant of this type. That is, the result is neither `const'
- nor `volatile'.
-
- -- Method on Type: range
- Return a Python `Tuple' object that contains two elements: the
- low bound of the argument type and the high bound of that
- type. If the type does not have a range, GDB will raise a
- `gdb.error' exception (*note Exception Handling::).
-
- -- Method on Type: reference
- Return a new `gdb.Type' object which represents a reference
- to this type.
-
- -- Method on Type: pointer
- Return a new `gdb.Type' object which represents a pointer to
- this type.
-
- -- Method on Type: strip_typedefs
- Return a new `gdb.Type' that represents the real type, after
- removing all layers of typedefs.
-
- -- Method on Type: target
- Return a new `gdb.Type' object which represents the target
- type of this type.
-
- For a pointer type, the target type is the type of the
- pointed-to object. For an array type (meaning C-like
- arrays), the target type is the type of the elements of the
- array. For a function or method type, the target type is the
- type of the return value. For a complex type, the target
- type is the type of the elements. For a typedef, the target
- type is the aliased type.
-
- If the type does not have a target, this method will throw an
- exception.
-
- -- Method on Type: template_argument n [block]
- If this `gdb.Type' is an instantiation of a template, this
- will return a new `gdb.Type' which represents the type of the
- Nth template argument.
-
- If this `gdb.Type' is not a template type, this will throw an
- exception. Ordinarily, only C++ code will have template
- types.
-
- If BLOCK is given, then NAME is looked up in that scope.
- Otherwise, it is searched for globally.
-
- Each type has a code, which indicates what category this type falls
-into. The available type categories are represented by constants
-defined in the `gdb' module:
-
-`TYPE_CODE_PTR'
- The type is a pointer.
-
-`TYPE_CODE_ARRAY'
- The type is an array.
-
-`TYPE_CODE_STRUCT'
- The type is a structure.
-
-`TYPE_CODE_UNION'
- The type is a union.
-
-`TYPE_CODE_ENUM'
- The type is an enum.
-
-`TYPE_CODE_FLAGS'
- A bit flags type, used for things such as status registers.
-
-`TYPE_CODE_FUNC'
- The type is a function.
-
-`TYPE_CODE_INT'
- The type is an integer type.
-
-`TYPE_CODE_FLT'
- A floating point type.
-
-`TYPE_CODE_VOID'
- The special type `void'.
-
-`TYPE_CODE_SET'
- A Pascal set type.
-
-`TYPE_CODE_RANGE'
- A range type, that is, an integer type with bounds.
-
-`TYPE_CODE_STRING'
- A string type. Note that this is only used for certain languages
- with language-defined string types; C strings are not represented
- this way.
-
-`TYPE_CODE_BITSTRING'
- A string of bits.
-
-`TYPE_CODE_ERROR'
- An unknown or erroneous type.
-
-`TYPE_CODE_METHOD'
- A method type, as found in C++ or Java.
-
-`TYPE_CODE_METHODPTR'
- A pointer-to-member-function.
-
-`TYPE_CODE_MEMBERPTR'
- A pointer-to-member.
-
-`TYPE_CODE_REF'
- A reference type.
-
-`TYPE_CODE_CHAR'
- A character type.
-
-`TYPE_CODE_BOOL'
- A boolean type.
-
-`TYPE_CODE_COMPLEX'
- A complex float type.
-
-`TYPE_CODE_TYPEDEF'
- A typedef to some other type.
-
-`TYPE_CODE_NAMESPACE'
- A C++ namespace.
-
-`TYPE_CODE_DECFLOAT'
- A decimal floating point type.
-
-`TYPE_CODE_INTERNAL_FUNCTION'
- A function internal to GDB. This is the type used to represent
- convenience functions.
-
- Further support for types is provided in the `gdb.types' Python
-module (*note gdb.types::).
-
-
-File: gdb.info, Node: Pretty Printing API, Next: Selecting Pretty-Printers, Prev: Types In Python, Up: Python API
-
-23.2.2.5 Pretty Printing API
-............................
-
-An example output is provided (*note Pretty Printing::).
-
- A pretty-printer is just an object that holds a value and implements
-a specific interface, defined here.
-
- -- Operation on pretty printer: children (self)
- GDB will call this method on a pretty-printer to compute the
- children of the pretty-printer's value.
-
- This method must return an object conforming to the Python iterator
- protocol. Each item returned by the iterator must be a tuple
- holding two elements. The first element is the "name" of the
- child; the second element is the child's value. The value can be
- any Python object which is convertible to a GDB value.
-
- This method is optional. If it does not exist, GDB will act as
- though the value has no children.
-
- -- Operation on pretty printer: display_hint (self)
- The CLI may call this method and use its result to change the
- formatting of a value. The result will also be supplied to an MI
- consumer as a `displayhint' attribute of the variable being
- printed.
-
- This method is optional. If it does exist, this method must
- return a string.
-
- Some display hints are predefined by GDB:
-
- `array'
- Indicate that the object being printed is "array-like". The
- CLI uses this to respect parameters such as `set print
- elements' and `set print array'.
-
- `map'
- Indicate that the object being printed is "map-like", and
- that the children of this value can be assumed to alternate
- between keys and values.
-
- `string'
- Indicate that the object being printed is "string-like". If
- the printer's `to_string' method returns a Python string of
- some kind, then GDB will call its internal language-specific
- string-printing function to format the string. For the CLI
- this means adding quotation marks, possibly escaping some
- characters, respecting `set print elements', and the like.
-
- -- Operation on pretty printer: to_string (self)
- GDB will call this method to display the string representation of
- the value passed to the object's constructor.
-
- When printing from the CLI, if the `to_string' method exists, then
- GDB will prepend its result to the values returned by `children'.
- Exactly how this formatting is done is dependent on the display
- hint, and may change as more hints are added. Also, depending on
- the print settings (*note Print Settings::), the CLI may print
- just the result of `to_string' in a stack trace, omitting the
- result of `children'.
-
- If this method returns a string, it is printed verbatim.
-
- Otherwise, if this method returns an instance of `gdb.Value', then
- GDB prints this value. This may result in a call to another
- pretty-printer.
-
- If instead the method returns a Python value which is convertible
- to a `gdb.Value', then GDB performs the conversion and prints the
- resulting value. Again, this may result in a call to another
- pretty-printer. Python scalars (integers, floats, and booleans)
- and strings are convertible to `gdb.Value'; other types are not.
-
- Finally, if this method returns `None' then no further operations
- are peformed in this method and nothing is printed.
-
- If the result is not one of these types, an exception is raised.
-
- GDB provides a function which can be used to look up the default
-pretty-printer for a `gdb.Value':
-
- -- Function: default_visualizer value
- This function takes a `gdb.Value' object as an argument. If a
- pretty-printer for this value exists, then it is returned. If no
- such printer exists, then this returns `None'.
-
-
-File: gdb.info, Node: Selecting Pretty-Printers, Next: Writing a Pretty-Printer, Prev: Pretty Printing API, Up: Python API
-
-23.2.2.6 Selecting Pretty-Printers
-..................................
-
-The Python list `gdb.pretty_printers' contains an array of functions or
-callable objects that have been registered via addition as a
-pretty-printer. Printers in this list are called `global' printers,
-they're available when debugging all inferiors. Each `gdb.Progspace'
-contains a `pretty_printers' attribute. Each `gdb.Objfile' also
-contains a `pretty_printers' attribute.
-
- Each function on these lists is passed a single `gdb.Value' argument
-and should return a pretty-printer object conforming to the interface
-definition above (*note Pretty Printing API::). If a function cannot
-create a pretty-printer for the value, it should return `None'.
-
- GDB first checks the `pretty_printers' attribute of each
-`gdb.Objfile' in the current program space and iteratively calls each
-enabled lookup routine in the list for that `gdb.Objfile' until it
-receives a pretty-printer object. If no pretty-printer is found in the
-objfile lists, GDB then searches the pretty-printer list of the current
-program space, calling each enabled function until an object is
-returned. After these lists have been exhausted, it tries the global
-`gdb.pretty_printers' list, again calling each enabled function until an
-object is returned.
-
- The order in which the objfiles are searched is not specified. For a
-given list, functions are always invoked from the head of the list, and
-iterated over sequentially until the end of the list, or a printer
-object is returned.
-
- For various reasons a pretty-printer may not work. For example, the
-underlying data structure may have changed and the pretty-printer is
-out of date.
-
- The consequences of a broken pretty-printer are severe enough that
-GDB provides support for enabling and disabling individual printers.
-For example, if `print frame-arguments' is on, a backtrace can become
-highly illegible if any argument is printed with a broken printer.
-
- Pretty-printers are enabled and disabled by attaching an `enabled'
-attribute to the registered function or callable object. If this
-attribute is present and its value is `False', the printer is disabled,
-otherwise the printer is enabled.
-
-
-File: gdb.info, Node: Writing a Pretty-Printer, Next: Inferiors In Python, Prev: Selecting Pretty-Printers, Up: Python API
-
-23.2.2.7 Writing a Pretty-Printer
-.................................
-
-A pretty-printer consists of two parts: a lookup function to detect if
-the type is supported, and the printer itself.
-
- Here is an example showing how a `std::string' printer might be
-written. *Note Pretty Printing API::, for details on the API this class
-must provide.
-
- class StdStringPrinter(object):
- "Print a std::string"
-
- def __init__(self, val):
- self.val = val
-
- def to_string(self):
- return self.val['_M_dataplus']['_M_p']
-
- def display_hint(self):
- return 'string'
-
- And here is an example showing how a lookup function for the printer
-example above might be written.
-
- def str_lookup_function(val):
- lookup_tag = val.type.tag
- if lookup_tag == None:
- return None
- regex = re.compile("^std::basic_string<char,.*>$")
- if regex.match(lookup_tag):
- return StdStringPrinter(val)
- return None
-
- The example lookup function extracts the value's type, and attempts
-to match it to a type that it can pretty-print. If it is a type the
-printer can pretty-print, it will return a printer object. If not, it
-returns `None'.
-
- We recommend that you put your core pretty-printers into a Python
-package. If your pretty-printers are for use with a library, we
-further recommend embedding a version number into the package name.
-This practice will enable GDB to load multiple versions of your
-pretty-printers at the same time, because they will have different
-names.
-
- You should write auto-loaded code (*note Auto-loading::) such that it
-can be evaluated multiple times without changing its meaning. An ideal
-auto-load file will consist solely of `import's of your printer
-modules, followed by a call to a register pretty-printers with the
-current objfile.
-
- Taken as a whole, this approach will scale nicely to multiple
-inferiors, each potentially using a different library version.
-Embedding a version number in the Python package name will ensure that
-GDB is able to load both sets of printers simultaneously. Then,
-because the search for pretty-printers is done by objfile, and because
-your auto-loaded code took care to register your library's printers
-with a specific objfile, GDB will find the correct printers for the
-specific version of the library used by each inferior.
-
- To continue the `std::string' example (*note Pretty Printing API::),
-this code might appear in `gdb.libstdcxx.v6':
-
- def register_printers(objfile):
- objfile.pretty_printers.add(str_lookup_function)
-
-And then the corresponding contents of the auto-load file would be:
-
- import gdb.libstdcxx.v6
- gdb.libstdcxx.v6.register_printers(gdb.current_objfile())
-
- The previous example illustrates a basic pretty-printer. There are
-a few things that can be improved on. The printer doesn't have a name,
-making it hard to identify in a list of installed printers. The lookup
-function has a name, but lookup functions can have arbitrary, even
-identical, names.
-
- Second, the printer only handles one type, whereas a library
-typically has several types. One could install a lookup function for
-each desired type in the library, but one could also have a single
-lookup function recognize several types. The latter is the
-conventional way this is handled. If a pretty-printer can handle
-multiple data types, then its "subprinters" are the printers for the
-individual data types.
-
- The `gdb.printing' module provides a formal way of solving these
-problems (*note gdb.printing::). Here is another example that handles
-multiple types.
-
- These are the types we are going to pretty-print:
-
- struct foo { int a, b; };
- struct bar { struct foo x, y; };
-
- Here are the printers:
-
- class fooPrinter:
- """Print a foo object."""
-
- def __init__(self, val):
- self.val = val
-
- def to_string(self):
- return ("a=<" + str(self.val["a"]) +
- "> b=<" + str(self.val["b"]) + ">")
-
- class barPrinter:
- """Print a bar object."""
-
- def __init__(self, val):
- self.val = val
-
- def to_string(self):
- return ("x=<" + str(self.val["x"]) +
- "> y=<" + str(self.val["y"]) + ">")
-
- This example doesn't need a lookup function, that is handled by the
-`gdb.printing' module. Instead a function is provided to build up the
-object that handles the lookup.
-
- import gdb.printing
-
- def build_pretty_printer():
- pp = gdb.printing.RegexpCollectionPrettyPrinter(
- "my_library")
- pp.add_printer('foo', '^foo$', fooPrinter)
- pp.add_printer('bar', '^bar$', barPrinter)
- return pp
-
- And here is the autoload support:
-
- import gdb.printing
- import my_library
- gdb.printing.register_pretty_printer(
- gdb.current_objfile(),
- my_library.build_pretty_printer())
-
- Finally, when this printer is loaded into GDB, here is the
-corresponding output of `info pretty-printer':
-
- (gdb) info pretty-printer
- my_library.so:
- my_library
- foo
- bar
-
-
-File: gdb.info, Node: Inferiors In Python, Next: Events In Python, Prev: Writing a Pretty-Printer, Up: Python API
-
-23.2.2.8 Inferiors In Python
-............................
-
-Programs which are being run under GDB are called inferiors (*note
-Inferiors and Programs::). Python scripts can access information about
-and manipulate inferiors controlled by GDB via objects of the
-`gdb.Inferior' class.
-
- The following inferior-related functions are available in the `gdb'
-module:
-
- -- Function: inferiors
- Return a tuple containing all inferior objects.
-
- A `gdb.Inferior' object has the following attributes:
-
- -- Instance Variable of Inferior: num
- ID of inferior, as assigned by GDB.
-
- -- Instance Variable of Inferior: pid
- Process ID of the inferior, as assigned by the underlying
- operating system.
-
- -- Instance Variable of Inferior: was_attached
- Boolean signaling whether the inferior was created using
- `attach', or started by GDB itself.
-
- A `gdb.Inferior' object has the following methods:
-
- -- Method on Inferior: is_valid
- Returns `True' if the `gdb.Inferior' object is valid, `False'
- if not. A `gdb.Inferior' object will become invalid if the
- inferior no longer exists within GDB. All other
- `gdb.Inferior' methods will throw an exception if it is
- invalid at the time the method is called.
-
- -- Method on Inferior: threads
- This method returns a tuple holding all the threads which are
- valid when it is called. If there are no valid threads, the
- method will return an empty tuple.
-
- -- Method on Inferior: read_memory address length
- Read LENGTH bytes of memory from the inferior, starting at
- ADDRESS. Returns a buffer object, which behaves much like an
- array or a string. It can be modified and given to the
- `gdb.write_memory' function.
-
- -- Method on Inferior: write_memory address buffer [length]
- Write the contents of BUFFER to the inferior, starting at
- ADDRESS. The BUFFER parameter must be a Python object which
- supports the buffer protocol, i.e., a string, an array or the
- object returned from `gdb.read_memory'. If given, LENGTH
- determines the number of bytes from BUFFER to be written.
-
- -- Method on Inferior: search_memory address length pattern
- Search a region of the inferior memory starting at ADDRESS
- with the given LENGTH using the search pattern supplied in
- PATTERN. The PATTERN parameter must be a Python object which
- supports the buffer protocol, i.e., a string, an array or the
- object returned from `gdb.read_memory'. Returns a Python
- `Long' containing the address where the pattern was found, or
- `None' if the pattern could not be found.
-
-
-File: gdb.info, Node: Events In Python, Next: Threads In Python, Prev: Inferiors In Python, Up: Python API
-
-23.2.2.9 Events In Python
-.........................
-
-GDB provides a general event facility so that Python code can be
-notified of various state changes, particularly changes that occur in
-the inferior.
-
- An "event" is just an object that describes some state change. The
-type of the object and its attributes will vary depending on the details
-of the change. All the existing events are described below.
-
- In order to be notified of an event, you must register an event
-handler with an "event registry". An event registry is an object in the
-`gdb.events' module which dispatches particular events. A registry
-provides methods to register and unregister event handlers:
-
- -- Method on EventRegistry: connect object
- Add the given callable OBJECT to the registry. This object
- will be called when an event corresponding to this registry
- occurs.
-
- -- Method on EventRegistry: disconnect object
- Remove the given OBJECT from the registry. Once removed, the
- object will no longer receive notifications of events.
-
- Here is an example:
-
- def exit_handler (event):
- print "event type: exit"
- print "exit code: %d" % (event.exit_code)
-
- gdb.events.exited.connect (exit_handler)
-
- In the above example we connect our handler `exit_handler' to the
-registry `events.exited'. Once connected, `exit_handler' gets called
-when the inferior exits. The argument "event" in this example is of
-type `gdb.ExitedEvent'. As you can see in the example the
-`ExitedEvent' object has an attribute which indicates the exit code of
-the inferior.
-
- The following is a listing of the event registries that are
-available and details of the events they emit:
-
-`events.cont'
- Emits `gdb.ThreadEvent'.
-
- Some events can be thread specific when GDB is running in non-stop
- mode. When represented in Python, these events all extend
- `gdb.ThreadEvent'. Note, this event is not emitted directly;
- instead, events which are emitted by this or other modules might
- extend this event. Examples of these events are
- `gdb.BreakpointEvent' and `gdb.ContinueEvent'.
-
- -- Instance Variable of ThreadEvent: inferior_thread
- In non-stop mode this attribute will be set to the
- specific thread which was involved in the emitted event.
- Otherwise, it will be set to `None'.
-
- Emits `gdb.ContinueEvent' which extends `gdb.ThreadEvent'.
-
- This event indicates that the inferior has been continued after a
- stop. For inherited attribute refer to `gdb.ThreadEvent' above.
-
-`events.exited'
- Emits `events.ExitedEvent' which indicates that the inferior has
- exited. `events.ExitedEvent' has one optional attribute. This
- attribute will exist only in the case that the inferior exited
- with some status.
- -- Instance Variable of ExitedEvent: exit_code
- An integer representing the exit code which the inferior
- has returned.
-
-`events.stop'
- Emits `gdb.StopEvent' which extends `gdb.ThreadEvent'.
-
- Indicates that the inferior has stopped. All events emitted by
- this registry extend StopEvent. As a child of `gdb.ThreadEvent',
- `gdb.StopEvent' will indicate the stopped thread when GDB is
- running in non-stop mode. Refer to `gdb.ThreadEvent' above for
- more details.
-
- Emits `gdb.SignalEvent' which extends `gdb.StopEvent'.
-
- This event indicates that the inferior or one of its threads has
- received as signal. `gdb.SignalEvent' has the following
- attributes:
-
- -- Instance Variable of SignalEvent: stop_signal
- A string representing the signal received by the
- inferior. A list of possible signal values can be
- obtained by running the command `info signals' in the
- GDB command prompt.
-
- Also emits `gdb.BreakpointEvent' which extends `gdb.StopEvent'.
-
- `gdb.BreakpointEvent' event indicates that a breakpoint has been
- hit, and has the following attributes:
-
- -- Instance Variable of BreakpointEvent: breakpoint
- A reference to the breakpoint that was hit of type
- `gdb.Breakpoint'. *Note Breakpoints In Python::, for
- details of the `gdb.Breakpoint' object.
-
-
-
-File: gdb.info, Node: Threads In Python, Next: Commands In Python, Prev: Events In Python, Up: Python API
-
-23.2.2.10 Threads In Python
-...........................
-
-Python scripts can access information about, and manipulate inferior
-threads controlled by GDB, via objects of the `gdb.InferiorThread'
-class.
-
- The following thread-related functions are available in the `gdb'
-module:
-
- -- Function: selected_thread
- This function returns the thread object for the selected thread.
- If there is no selected thread, this will return `None'.
-
- A `gdb.InferiorThread' object has the following attributes:
-
- -- Instance Variable of InferiorThread: name
- The name of the thread. If the user specified a name using
- `thread name', then this returns that name. Otherwise, if an
- OS-supplied name is available, then it is returned.
- Otherwise, this returns `None'.
-
- This attribute can be assigned to. The new value must be a
- string object, which sets the new name, or `None', which
- removes any user-specified thread name.
-
- -- Instance Variable of InferiorThread: num
- ID of the thread, as assigned by GDB.
-
- -- Instance Variable of InferiorThread: ptid
- ID of the thread, as assigned by the operating system. This
- attribute is a tuple containing three integers. The first is
- the Process ID (PID); the second is the Lightweight Process
- ID (LWPID), and the third is the Thread ID (TID). Either the
- LWPID or TID may be 0, which indicates that the operating
- system does not use that identifier.
-
- A `gdb.InferiorThread' object has the following methods:
-
- -- Method on InferiorThread: is_valid
- Returns `True' if the `gdb.InferiorThread' object is valid,
- `False' if not. A `gdb.InferiorThread' object will become
- invalid if the thread exits, or the inferior that the thread
- belongs is deleted. All other `gdb.InferiorThread' methods
- will throw an exception if it is invalid at the time the
- method is called.
-
- -- Method on InferiorThread: switch
- This changes GDB's currently selected thread to the one
- represented by this object.
-
- -- Method on InferiorThread: is_stopped
- Return a Boolean indicating whether the thread is stopped.
-
- -- Method on InferiorThread: is_running
- Return a Boolean indicating whether the thread is running.
-
- -- Method on InferiorThread: is_exited
- Return a Boolean indicating whether the thread is exited.
-
-
-File: gdb.info, Node: Commands In Python, Next: Parameters In Python, Prev: Threads In Python, Up: Python API
-
-23.2.2.11 Commands In Python
-............................
-
-You can implement new GDB CLI commands in Python. A CLI command is
-implemented using an instance of the `gdb.Command' class, most commonly
-using a subclass.
-
- -- Method on Command: __init__ name COMMAND_CLASS [COMPLETER_CLASS]
- [PREFIX]
- The object initializer for `Command' registers the new command
- with GDB. This initializer is normally invoked from the subclass'
- own `__init__' method.
-
- NAME is the name of the command. If NAME consists of multiple
- words, then the initial words are looked for as prefix commands.
- In this case, if one of the prefix commands does not exist, an
- exception is raised.
-
- There is no support for multi-line commands.
-
- COMMAND_CLASS should be one of the `COMMAND_' constants defined
- below. This argument tells GDB how to categorize the new command
- in the help system.
-
- COMPLETER_CLASS is an optional argument. If given, it should be
- one of the `COMPLETE_' constants defined below. This argument
- tells GDB how to perform completion for this command. If not
- given, GDB will attempt to complete using the object's `complete'
- method (see below); if no such method is found, an error will
- occur when completion is attempted.
-
- PREFIX is an optional argument. If `True', then the new command
- is a prefix command; sub-commands of this command may be
- registered.
-
- The help text for the new command is taken from the Python
- documentation string for the command's class, if there is one. If
- no documentation string is provided, the default value "This
- command is not documented." is used.
-
- -- Method on Command: dont_repeat
- By default, a GDB command is repeated when the user enters a blank
- line at the command prompt. A command can suppress this behavior
- by invoking the `dont_repeat' method. This is similar to the user
- command `dont-repeat', see *note dont-repeat: Define.
-
- -- Method on Command: invoke argument from_tty
- This method is called by GDB when this command is invoked.
-
- ARGUMENT is a string. It is the argument to the command, after
- leading and trailing whitespace has been stripped.
-
- FROM_TTY is a boolean argument. When true, this means that the
- command was entered by the user at the terminal; when false it
- means that the command came from elsewhere.
-
- If this method throws an exception, it is turned into a GDB
- `error' call. Otherwise, the return value is ignored.
-
- To break ARGUMENT up into an argv-like string use
- `gdb.string_to_argv'. This function behaves identically to GDB's
- internal argument lexer `buildargv'. It is recommended to use
- this for consistency. Arguments are separated by spaces and may
- be quoted. Example:
-
- print gdb.string_to_argv ("1 2\ \\\"3 '4 \"5' \"6 '7\"")
- ['1', '2 "3', '4 "5', "6 '7"]
-
-
- -- Method on Command: complete text word
- This method is called by GDB when the user attempts completion on
- this command. All forms of completion are handled by this method,
- that is, the <TAB> and <M-?> key bindings (*note Completion::),
- and the `complete' command (*note complete: Help.).
-
- The arguments TEXT and WORD are both strings. TEXT holds the
- complete command line up to the cursor's location. WORD holds the
- last word of the command line; this is computed using a
- word-breaking heuristic.
-
- The `complete' method can return several values:
- * If the return value is a sequence, the contents of the
- sequence are used as the completions. It is up to `complete'
- to ensure that the contents actually do complete the word. A
- zero-length sequence is allowed, it means that there were no
- completions available. Only string elements of the sequence
- are used; other elements in the sequence are ignored.
-
- * If the return value is one of the `COMPLETE_' constants
- defined below, then the corresponding GDB-internal completion
- function is invoked, and its result is used.
-
- * All other results are treated as though there were no
- available completions.
-
- When a new command is registered, it must be declared as a member of
-some general class of commands. This is used to classify top-level
-commands in the on-line help system; note that prefix commands are not
-listed under their own category but rather that of their top-level
-command. The available classifications are represented by constants
-defined in the `gdb' module:
-
-`COMMAND_NONE'
- The command does not belong to any particular class. A command in
- this category will not be displayed in any of the help categories.
-
-`COMMAND_RUNNING'
- The command is related to running the inferior. For example,
- `start', `step', and `continue' are in this category. Type `help
- running' at the GDB prompt to see a list of commands in this
- category.
-
-`COMMAND_DATA'
- The command is related to data or variables. For example, `call',
- `find', and `print' are in this category. Type `help data' at the
- GDB prompt to see a list of commands in this category.
-
-`COMMAND_STACK'
- The command has to do with manipulation of the stack. For example,
- `backtrace', `frame', and `return' are in this category. Type
- `help stack' at the GDB prompt to see a list of commands in this
- category.
-
-`COMMAND_FILES'
- This class is used for file-related commands. For example,
- `file', `list' and `section' are in this category. Type `help
- files' at the GDB prompt to see a list of commands in this
- category.
-
-`COMMAND_SUPPORT'
- This should be used for "support facilities", generally meaning
- things that are useful to the user when interacting with GDB, but
- not related to the state of the inferior. For example, `help',
- `make', and `shell' are in this category. Type `help support' at
- the GDB prompt to see a list of commands in this category.
-
-`COMMAND_STATUS'
- The command is an `info'-related command, that is, related to the
- state of GDB itself. For example, `info', `macro', and `show' are
- in this category. Type `help status' at the GDB prompt to see a
- list of commands in this category.
-
-`COMMAND_BREAKPOINTS'
- The command has to do with breakpoints. For example, `break',
- `clear', and `delete' are in this category. Type `help
- breakpoints' at the GDB prompt to see a list of commands in this
- category.
-
-`COMMAND_TRACEPOINTS'
- The command has to do with tracepoints. For example, `trace',
- `actions', and `tfind' are in this category. Type `help
- tracepoints' at the GDB prompt to see a list of commands in this
- category.
-
-`COMMAND_OBSCURE'
- The command is only used in unusual circumstances, or is not of
- general interest to users. For example, `checkpoint', `fork', and
- `stop' are in this category. Type `help obscure' at the GDB
- prompt to see a list of commands in this category.
-
-`COMMAND_MAINTENANCE'
- The command is only useful to GDB maintainers. The `maintenance'
- and `flushregs' commands are in this category. Type `help
- internals' at the GDB prompt to see a list of commands in this
- category.
-
- A new command can use a predefined completion function, either by
-specifying it via an argument at initialization, or by returning it
-from the `complete' method. These predefined completion constants are
-all defined in the `gdb' module:
-
-`COMPLETE_NONE'
- This constant means that no completion should be done.
-
-`COMPLETE_FILENAME'
- This constant means that filename completion should be performed.
-
-`COMPLETE_LOCATION'
- This constant means that location completion should be done.
- *Note Specify Location::.
-
-`COMPLETE_COMMAND'
- This constant means that completion should examine GDB command
- names.
-
-`COMPLETE_SYMBOL'
- This constant means that completion should be done using symbol
- names as the source.
-
- The following code snippet shows how a trivial CLI command can be
-implemented in Python:
-
- class HelloWorld (gdb.Command):
- """Greet the whole world."""
-
- def __init__ (self):
- super (HelloWorld, self).__init__ ("hello-world", gdb.COMMAND_OBSCURE)
-
- def invoke (self, arg, from_tty):
- print "Hello, World!"
-
- HelloWorld ()
-
- The last line instantiates the class, and is necessary to trigger the
-registration of the command with GDB. Depending on how the Python code
-is read into GDB, you may need to import the `gdb' module explicitly.
-
-
-File: gdb.info, Node: Parameters In Python, Next: Functions In Python, Prev: Commands In Python, Up: Python API
-
-23.2.2.12 Parameters In Python
-..............................
-
-You can implement new GDB parameters using Python. A new parameter is
-implemented as an instance of the `gdb.Parameter' class.
-
- Parameters are exposed to the user via the `set' and `show'
-commands. *Note Help::.
-
- There are many parameters that already exist and can be set in GDB.
-Two examples are: `set follow fork' and `set charset'. Setting these
-parameters influences certain behavior in GDB. Similarly, you can
-define parameters that can be used to influence behavior in custom
-Python scripts and commands.
-
- -- Method on Parameter: __init__ name COMMAND-CLASS PARAMETER-CLASS
- [ENUM-SEQUENCE]
- The object initializer for `Parameter' registers the new parameter
- with GDB. This initializer is normally invoked from the subclass'
- own `__init__' method.
-
- NAME is the name of the new parameter. If NAME consists of
- multiple words, then the initial words are looked for as prefix
- parameters. An example of this can be illustrated with the `set
- print' set of parameters. If NAME is `print foo', then `print'
- will be searched as the prefix parameter. In this case the
- parameter can subsequently be accessed in GDB as `set print foo'.
-
- If NAME consists of multiple words, and no prefix parameter group
- can be found, an exception is raised.
-
- COMMAND-CLASS should be one of the `COMMAND_' constants (*note
- Commands In Python::). This argument tells GDB how to categorize
- the new parameter in the help system.
-
- PARAMETER-CLASS should be one of the `PARAM_' constants defined
- below. This argument tells GDB the type of the new parameter;
- this information is used for input validation and completion.
-
- If PARAMETER-CLASS is `PARAM_ENUM', then ENUM-SEQUENCE must be a
- sequence of strings. These strings represent the possible values
- for the parameter.
-
- If PARAMETER-CLASS is not `PARAM_ENUM', then the presence of a
- fourth argument will cause an exception to be thrown.
-
- The help text for the new parameter is taken from the Python
- documentation string for the parameter's class, if there is one.
- If there is no documentation string, a default value is used.
-
- -- Instance Variable of Parameter: set_doc
- If this attribute exists, and is a string, then its value is used
- as the help text for this parameter's `set' command. The value is
- examined when `Parameter.__init__' is invoked; subsequent changes
- have no effect.
-
- -- Instance Variable of Parameter: show_doc
- If this attribute exists, and is a string, then its value is used
- as the help text for this parameter's `show' command. The value is
- examined when `Parameter.__init__' is invoked; subsequent changes
- have no effect.
-
- -- Instance Variable of Parameter: value
- The `value' attribute holds the underlying value of the parameter.
- It can be read and assigned to just as any other attribute. GDB
- does validation when assignments are made.
-
- There are two methods that should be implemented in any `Parameter'
-class. These are:
-
- -- Operation on parameter: get_set_string self
- GDB will call this method when a PARAMETER's value has been
- changed via the `set' API (for example, `set foo off'). The
- `value' attribute has already been populated with the new value
- and may be used in output. This method must return a string.
-
- -- Operation on parameter: get_show_string self svalue
- GDB will call this method when a PARAMETER's `show' API has been
- invoked (for example, `show foo'). The argument `svalue' receives
- the string representation of the current value. This method must
- return a string.
-
- When a new parameter is defined, its type must be specified. The
-available types are represented by constants defined in the `gdb'
-module:
-
-`PARAM_BOOLEAN'
- The value is a plain boolean. The Python boolean values, `True'
- and `False' are the only valid values.
-
-`PARAM_AUTO_BOOLEAN'
- The value has three possible states: true, false, and `auto'. In
- Python, true and false are represented using boolean constants, and
- `auto' is represented using `None'.
-
-`PARAM_UINTEGER'
- The value is an unsigned integer. The value of 0 should be
- interpreted to mean "unlimited".
-
-`PARAM_INTEGER'
- The value is a signed integer. The value of 0 should be
- interpreted to mean "unlimited".
-
-`PARAM_STRING'
- The value is a string. When the user modifies the string, any
- escape sequences, such as `\t', `\f', and octal escapes, are
- translated into corresponding characters and encoded into the
- current host charset.
-
-`PARAM_STRING_NOESCAPE'
- The value is a string. When the user modifies the string, escapes
- are passed through untranslated.
-
-`PARAM_OPTIONAL_FILENAME'
- The value is a either a filename (a string), or `None'.
-
-`PARAM_FILENAME'
- The value is a filename. This is just like
- `PARAM_STRING_NOESCAPE', but uses file names for completion.
-
-`PARAM_ZINTEGER'
- The value is an integer. This is like `PARAM_INTEGER', except 0
- is interpreted as itself.
-
-`PARAM_ENUM'
- The value is a string, which must be one of a collection string
- constants provided when the parameter is created.
-
-
-File: gdb.info, Node: Functions In Python, Next: Progspaces In Python, Prev: Parameters In Python, Up: Python API
-
-23.2.2.13 Writing new convenience functions
-...........................................
-
-You can implement new convenience functions (*note Convenience Vars::)
-in Python. A convenience function is an instance of a subclass of the
-class `gdb.Function'.
-
- -- Method on Function: __init__ name
- The initializer for `Function' registers the new function with
- GDB. The argument NAME is the name of the function, a string.
- The function will be visible to the user as a convenience variable
- of type `internal function', whose name is the same as the given
- NAME.
-
- The documentation for the new function is taken from the
- documentation string for the new class.
-
- -- Method on Function: invoke *ARGS
- When a convenience function is evaluated, its arguments are
- converted to instances of `gdb.Value', and then the function's
- `invoke' method is called. Note that GDB does not predetermine
- the arity of convenience functions. Instead, all available
- arguments are passed to `invoke', following the standard Python
- calling convention. In particular, a convenience function can
- have default values for parameters without ill effect.
-
- The return value of this method is used as its value in the
- enclosing expression. If an ordinary Python value is returned, it
- is converted to a `gdb.Value' following the usual rules.
-
- The following code snippet shows how a trivial convenience function
-can be implemented in Python:
-
- class Greet (gdb.Function):
- """Return string to greet someone.
- Takes a name as argument."""
-
- def __init__ (self):
- super (Greet, self).__init__ ("greet")
-
- def invoke (self, name):
- return "Hello, %s!" % name.string ()
-
- Greet ()
-
- The last line instantiates the class, and is necessary to trigger the
-registration of the function with GDB. Depending on how the Python
-code is read into GDB, you may need to import the `gdb' module
-explicitly.
-
-
-File: gdb.info, Node: Progspaces In Python, Next: Objfiles In Python, Prev: Functions In Python, Up: Python API
-
-23.2.2.14 Program Spaces In Python
-..................................
-
-A program space, or "progspace", represents a symbolic view of an
-address space. It consists of all of the objfiles of the program.
-*Note Objfiles In Python::. *Note program spaces: Inferiors and
-Programs, for more details about program spaces.
-
- The following progspace-related functions are available in the `gdb'
-module:
-
- -- Function: current_progspace
- This function returns the program space of the currently selected
- inferior. *Note Inferiors and Programs::.
-
- -- Function: progspaces
- Return a sequence of all the progspaces currently known to GDB.
-
- Each progspace is represented by an instance of the `gdb.Progspace'
-class.
-
- -- Instance Variable of Progspace: filename
- The file name of the progspace as a string.
-
- -- Instance Variable of Progspace: pretty_printers
- The `pretty_printers' attribute is a list of functions. It is
- used to look up pretty-printers. A `Value' is passed to each
- function in order; if the function returns `None', then the search
- continues. Otherwise, the return value should be an object which
- is used to format the value. *Note Pretty Printing API::, for more
- information.
-
-
-File: gdb.info, Node: Objfiles In Python, Next: Frames In Python, Prev: Progspaces In Python, Up: Python API
-
-23.2.2.15 Objfiles In Python
-............................
-
-GDB loads symbols for an inferior from various symbol-containing files
-(*note Files::). These include the primary executable file, any shared
-libraries used by the inferior, and any separate debug info files
-(*note Separate Debug Files::). GDB calls these symbol-containing
-files "objfiles".
-
- The following objfile-related functions are available in the `gdb'
-module:
-
- -- Function: current_objfile
- When auto-loading a Python script (*note Auto-loading::), GDB sets
- the "current objfile" to the corresponding objfile. This function
- returns the current objfile. If there is no current objfile, this
- function returns `None'.
-
- -- Function: objfiles
- Return a sequence of all the objfiles current known to GDB. *Note
- Objfiles In Python::.
-
- Each objfile is represented by an instance of the `gdb.Objfile'
-class.
-
- -- Instance Variable of Objfile: filename
- The file name of the objfile as a string.
-
- -- Instance Variable of Objfile: pretty_printers
- The `pretty_printers' attribute is a list of functions. It is
- used to look up pretty-printers. A `Value' is passed to each
- function in order; if the function returns `None', then the search
- continues. Otherwise, the return value should be an object which
- is used to format the value. *Note Pretty Printing API::, for more
- information.
-
- A `gdb.Objfile' object has the following methods:
-
- -- Method on Objfile: is_valid
- Returns `True' if the `gdb.Objfile' object is valid, `False' if
- not. A `gdb.Objfile' object can become invalid if the object file
- it refers to is not loaded in GDB any longer. All other
- `gdb.Objfile' methods will throw an exception if it is invalid at
- the time the method is called.
-
-
-File: gdb.info, Node: Frames In Python, Next: Blocks In Python, Prev: Objfiles In Python, Up: Python API
-
-23.2.2.16 Accessing inferior stack frames from Python.
-......................................................
-
-When the debugged program stops, GDB is able to analyze its call stack
-(*note Stack frames: Frames.). The `gdb.Frame' class represents a
-frame in the stack. A `gdb.Frame' object is only valid while its
-corresponding frame exists in the inferior's stack. If you try to use
-an invalid frame object, GDB will throw a `gdb.error' exception (*note
-Exception Handling::).
-
- Two `gdb.Frame' objects can be compared for equality with the `=='
-operator, like:
-
- (gdb) python print gdb.newest_frame() == gdb.selected_frame ()
- True
-
- The following frame-related functions are available in the `gdb'
-module:
-
- -- Function: selected_frame
- Return the selected frame object. (*note Selecting a Frame:
- Selection.).
-
- -- Function: newest_frame
- Return the newest frame object for the selected thread.
-
- -- Function: frame_stop_reason_string reason
- Return a string explaining the reason why GDB stopped unwinding
- frames, as expressed by the given REASON code (an integer, see the
- `unwind_stop_reason' method further down in this section).
-
- A `gdb.Frame' object has the following methods:
-
- -- Method on Frame: is_valid
- Returns true if the `gdb.Frame' object is valid, false if not.
- A frame object can become invalid if the frame it refers to
- doesn't exist anymore in the inferior. All `gdb.Frame'
- methods will throw an exception if it is invalid at the time
- the method is called.
-
- -- Method on Frame: name
- Returns the function name of the frame, or `None' if it can't
- be obtained.
-
- -- Method on Frame: type
- Returns the type of the frame. The value can be one of:
- `gdb.NORMAL_FRAME'
- An ordinary stack frame.
-
- `gdb.DUMMY_FRAME'
- A fake stack frame that was created by GDB when
- performing an inferior function call.
-
- `gdb.INLINE_FRAME'
- A frame representing an inlined function. The function
- was inlined into a `gdb.NORMAL_FRAME' that is older than
- this one.
-
- `gdb.SIGTRAMP_FRAME'
- A signal trampoline frame. This is the frame created by
- the OS when it calls into a signal handler.
-
- `gdb.ARCH_FRAME'
- A fake stack frame representing a cross-architecture
- call.
-
- `gdb.SENTINEL_FRAME'
- This is like `gdb.NORMAL_FRAME', but it is only used for
- the newest frame.
-
- -- Method on Frame: unwind_stop_reason
- Return an integer representing the reason why it's not
- possible to find more frames toward the outermost frame. Use
- `gdb.frame_stop_reason_string' to convert the value returned
- by this function to a string.
-
- -- Method on Frame: pc
- Returns the frame's resume address.
-
- -- Method on Frame: block
- Return the frame's code block. *Note Blocks In Python::.
-
- -- Method on Frame: function
- Return the symbol for the function corresponding to this
- frame. *Note Symbols In Python::.
-
- -- Method on Frame: older
- Return the frame that called this frame.
-
- -- Method on Frame: newer
- Return the frame called by this frame.
-
- -- Method on Frame: find_sal
- Return the frame's symtab and line object. *Note Symbol
- Tables In Python::.
-
- -- Method on Frame: read_var variable [block]
- Return the value of VARIABLE in this frame. If the optional
- argument BLOCK is provided, search for the variable from that
- block; otherwise start at the frame's current block (which is
- determined by the frame's current program counter). VARIABLE
- must be a string or a `gdb.Symbol' object. BLOCK must be a
- `gdb.Block' object.
-
- -- Method on Frame: select
- Set this frame to be the selected frame. *Note Examining the
- Stack: Stack.
-
-
-File: gdb.info, Node: Blocks In Python, Next: Symbols In Python, Prev: Frames In Python, Up: Python API
-
-23.2.2.17 Accessing frame blocks from Python.
-.............................................
-
-Within each frame, GDB maintains information on each block stored in
-that frame. These blocks are organized hierarchically, and are
-represented individually in Python as a `gdb.Block'. Please see *note
-Frames In Python::, for a more in-depth discussion on frames.
-Furthermore, see *note Examining the Stack: Stack, for more detailed
-technical information on GDB's book-keeping of the stack.
-
- The following block-related functions are available in the `gdb'
-module:
-
- -- Function: block_for_pc pc
- Return the `gdb.Block' containing the given PC value. If the
- block cannot be found for the PC value specified, the function
- will return `None'.
-
- A `gdb.Block' object has the following methods:
-
- -- Method on Block: is_valid
- Returns `True' if the `gdb.Block' object is valid, `False' if
- not. A block object can become invalid if the block it
- refers to doesn't exist anymore in the inferior. All other
- `gdb.Block' methods will throw an exception if it is invalid
- at the time the method is called. This method is also made
- available to the Python iterator object that `gdb.Block'
- provides in an iteration context and via the Python `iter'
- built-in function.
-
- A `gdb.Block' object has the following attributes:
-
- -- Instance Variable of Block: start
- The start address of the block. This attribute is not
- writable.
-
- -- Instance Variable of Block: end
- The end address of the block. This attribute is not writable.
-
- -- Instance Variable of Block: function
- The name of the block represented as a `gdb.Symbol'. If the
- block is not named, then this attribute holds `None'. This
- attribute is not writable.
-
- -- Instance Variable of Block: superblock
- The block containing this block. If this parent block does
- not exist, this attribute holds `None'. This attribute is
- not writable.
-
-
-File: gdb.info, Node: Symbols In Python, Next: Symbol Tables In Python, Prev: Blocks In Python, Up: Python API
-
-23.2.2.18 Python representation of Symbols.
-...........................................
-
-GDB represents every variable, function and type as an entry in a
-symbol table. *Note Examining the Symbol Table: Symbols. Similarly,
-Python represents these symbols in GDB with the `gdb.Symbol' object.
-
- The following symbol-related functions are available in the `gdb'
-module:
-
- -- Function: lookup_symbol name [block] [domain]
- This function searches for a symbol by name. The search scope can
- be restricted to the parameters defined in the optional domain and
- block arguments.
-
- NAME is the name of the symbol. It must be a string. The
- optional BLOCK argument restricts the search to symbols visible in
- that BLOCK. The BLOCK argument must be a `gdb.Block' object. If
- omitted, the block for the current frame is used. The optional
- DOMAIN argument restricts the search to the domain type. The
- DOMAIN argument must be a domain constant defined in the `gdb'
- module and described later in this chapter.
-
- The result is a tuple of two elements. The first element is a
- `gdb.Symbol' object or `None' if the symbol is not found. If the
- symbol is found, the second element is `True' if the symbol is a
- field of a method's object (e.g., `this' in C++), otherwise it is
- `False'. If the symbol is not found, the second element is
- `False'.
-
- -- Function: lookup_global_symbol name [domain]
- This function searches for a global symbol by name. The search
- scope can be restricted to by the domain argument.
-
- NAME is the name of the symbol. It must be a string. The
- optional DOMAIN argument restricts the search to the domain type.
- The DOMAIN argument must be a domain constant defined in the `gdb'
- module and described later in this chapter.
-
- The result is a `gdb.Symbol' object or `None' if the symbol is not
- found.
-
- A `gdb.Symbol' object has the following attributes:
-
- -- Instance Variable of Symbol: type
- The type of the symbol or `None' if no type is recorded.
- This attribute is represented as a `gdb.Type' object. *Note
- Types In Python::. This attribute is not writable.
-
- -- Instance Variable of Symbol: symtab
- The symbol table in which the symbol appears. This attribute
- is represented as a `gdb.Symtab' object. *Note Symbol Tables
- In Python::. This attribute is not writable.
-
- -- Instance Variable of Symbol: name
- The name of the symbol as a string. This attribute is not
- writable.
-
- -- Instance Variable of Symbol: linkage_name
- The name of the symbol, as used by the linker (i.e., may be
- mangled). This attribute is not writable.
-
- -- Instance Variable of Symbol: print_name
- The name of the symbol in a form suitable for output. This
- is either `name' or `linkage_name', depending on whether the
- user asked GDB to display demangled or mangled names.
-
- -- Instance Variable of Symbol: addr_class
- The address class of the symbol. This classifies how to find
- the value of a symbol. Each address class is a constant
- defined in the `gdb' module and described later in this
- chapter.
-
- -- Instance Variable of Symbol: is_argument
- `True' if the symbol is an argument of a function.
-
- -- Instance Variable of Symbol: is_constant
- `True' if the symbol is a constant.
-
- -- Instance Variable of Symbol: is_function
- `True' if the symbol is a function or a method.
-
- -- Instance Variable of Symbol: is_variable
- `True' if the symbol is a variable.
-
- A `gdb.Symbol' object has the following methods:
-
- -- Method on Symbol: is_valid
- Returns `True' if the `gdb.Symbol' object is valid, `False'
- if not. A `gdb.Symbol' object can become invalid if the
- symbol it refers to does not exist in GDB any longer. All
- other `gdb.Symbol' methods will throw an exception if it is
- invalid at the time the method is called.
-
- The available domain categories in `gdb.Symbol' are represented as
-constants in the `gdb' module:
-
-`SYMBOL_UNDEF_DOMAIN'
- This is used when a domain has not been discovered or none of the
- following domains apply. This usually indicates an error either
- in the symbol information or in GDB's handling of symbols.
-
-`SYMBOL_VAR_DOMAIN'
- This domain contains variables, function names, typedef names and
- enum type values.
-
-`SYMBOL_STRUCT_DOMAIN'
- This domain holds struct, union and enum type names.
-
-`SYMBOL_LABEL_DOMAIN'
- This domain contains names of labels (for gotos).
-
-`SYMBOL_VARIABLES_DOMAIN'
- This domain holds a subset of the `SYMBOLS_VAR_DOMAIN'; it
- contains everything minus functions and types.
-
-`SYMBOL_FUNCTION_DOMAIN'
- This domain contains all functions.
-
-`SYMBOL_TYPES_DOMAIN'
- This domain contains all types.
-
- The available address class categories in `gdb.Symbol' are
-represented as constants in the `gdb' module:
-
-`SYMBOL_LOC_UNDEF'
- If this is returned by address class, it indicates an error either
- in the symbol information or in GDB's handling of symbols.
-
-`SYMBOL_LOC_CONST'
- Value is constant int.
-
-`SYMBOL_LOC_STATIC'
- Value is at a fixed address.
-
-`SYMBOL_LOC_REGISTER'
- Value is in a register.
-
-`SYMBOL_LOC_ARG'
- Value is an argument. This value is at the offset stored within
- the symbol inside the frame's argument list.
-
-`SYMBOL_LOC_REF_ARG'
- Value address is stored in the frame's argument list. Just like
- `LOC_ARG' except that the value's address is stored at the offset,
- not the value itself.
-
-`SYMBOL_LOC_REGPARM_ADDR'
- Value is a specified register. Just like `LOC_REGISTER' except
- the register holds the address of the argument instead of the
- argument itself.
-
-`SYMBOL_LOC_LOCAL'
- Value is a local variable.
-
-`SYMBOL_LOC_TYPEDEF'
- Value not used. Symbols in the domain `SYMBOL_STRUCT_DOMAIN' all
- have this class.
-
-`SYMBOL_LOC_BLOCK'
- Value is a block.
-
-`SYMBOL_LOC_CONST_BYTES'
- Value is a byte-sequence.
-
-`SYMBOL_LOC_UNRESOLVED'
- Value is at a fixed address, but the address of the variable has
- to be determined from the minimal symbol table whenever the
- variable is referenced.
-
-`SYMBOL_LOC_OPTIMIZED_OUT'
- The value does not actually exist in the program.
-
-`SYMBOL_LOC_COMPUTED'
- The value's address is a computed location.
-
-
-File: gdb.info, Node: Symbol Tables In Python, Next: Lazy Strings In Python, Prev: Symbols In Python, Up: Python API
-
-23.2.2.19 Symbol table representation in Python.
-................................................
-
-Access to symbol table data maintained by GDB on the inferior is
-exposed to Python via two objects: `gdb.Symtab_and_line' and
-`gdb.Symtab'. Symbol table and line data for a frame is returned from
-the `find_sal' method in `gdb.Frame' object. *Note Frames In Python::.
-
- For more information on GDB's symbol table management, see *note
-Examining the Symbol Table: Symbols, for more information.
-
- A `gdb.Symtab_and_line' object has the following attributes:
-
- -- Instance Variable of Symtab_and_line: symtab
- The symbol table object (`gdb.Symtab') for this frame. This
- attribute is not writable.
-
- -- Instance Variable of Symtab_and_line: pc
- Indicates the current program counter address. This
- attribute is not writable.
-
- -- Instance Variable of Symtab_and_line: line
- Indicates the current line number for this object. This
- attribute is not writable.
-
- A `gdb.Symtab_and_line' object has the following methods:
-
- -- Method on Symtab_and_line: is_valid
- Returns `True' if the `gdb.Symtab_and_line' object is valid,
- `False' if not. A `gdb.Symtab_and_line' object can become
- invalid if the Symbol table and line object it refers to does
- not exist in GDB any longer. All other `gdb.Symtab_and_line'
- methods will throw an exception if it is invalid at the time
- the method is called.
-
- A `gdb.Symtab' object has the following attributes:
-
- -- Instance Variable of Symtab: filename
- The symbol table's source filename. This attribute is not
- writable.
-
- -- Instance Variable of Symtab: objfile
- The symbol table's backing object file. *Note Objfiles In
- Python::. This attribute is not writable.
-
- A `gdb.Symtab' object has the following methods:
-
- -- Method on Symtab: is_valid
- Returns `True' if the `gdb.Symtab' object is valid, `False'
- if not. A `gdb.Symtab' object can become invalid if the
- symbol table it refers to does not exist in GDB any longer.
- All other `gdb.Symtab' methods will throw an exception if it
- is invalid at the time the method is called.
-
- -- Method on Symtab: fullname
- Return the symbol table's source absolute file name.
-
-
-File: gdb.info, Node: Breakpoints In Python, Prev: Lazy Strings In Python, Up: Python API
-
-23.2.2.20 Manipulating breakpoints using Python
-...............................................
-
-Python code can manipulate breakpoints via the `gdb.Breakpoint' class.
-
- -- Method on Breakpoint: __init__ spec [type] [wp_class] [internal]
- Create a new breakpoint. SPEC is a string naming the location of
- the breakpoint, or an expression that defines a watchpoint. The
- contents can be any location recognized by the `break' command, or
- in the case of a watchpoint, by the `watch' command. The optional
- TYPE denotes the breakpoint to create from the types defined later
- in this chapter. This argument can be either: `BP_BREAKPOINT' or
- `BP_WATCHPOINT'. TYPE defaults to `BP_BREAKPOINT'. The optional
- INTERNAL argument allows the breakpoint to become invisible to the
- user. The breakpoint will neither be reported when created, nor
- will it be listed in the output from `info breakpoints' (but will
- be listed with the `maint info breakpoints' command). The
- optional WP_CLASS argument defines the class of watchpoint to
- create, if TYPE is `BP_WATCHPOINT'. If a watchpoint class is not
- provided, it is assumed to be a WP_WRITE class.
-
- -- Operation on gdb.Breakpoint: stop (self)
- The `gdb.Breakpoint' class can be sub-classed and, in particular,
- you may choose to implement the `stop' method. If this method is
- defined as a sub-class of `gdb.Breakpoint', it will be called when
- the inferior reaches any location of a breakpoint which
- instantiates that sub-class. If the method returns `True', the
- inferior will be stopped at the location of the breakpoint,
- otherwise the inferior will continue.
-
- If there are multiple breakpoints at the same location with a
- `stop' method, each one will be called regardless of the return
- status of the previous. This ensures that all `stop' methods have
- a chance to execute at that location. In this scenario if one of
- the methods returns `True' but the others return `False', the
- inferior will still be stopped.
-
- Example `stop' implementation:
-
- class MyBreakpoint (gdb.Breakpoint):
- def stop (self):
- inf_val = gdb.parse_and_eval("foo")
- if inf_val == 3:
- return True
- return False
-
- The available watchpoint types represented by constants are defined
-in the `gdb' module:
-
-`WP_READ'
- Read only watchpoint.
-
-`WP_WRITE'
- Write only watchpoint.
-
-`WP_ACCESS'
- Read/Write watchpoint.
-
- -- Method on Breakpoint: is_valid
- Return `True' if this `Breakpoint' object is valid, `False'
- otherwise. A `Breakpoint' object can become invalid if the user
- deletes the breakpoint. In this case, the object still exists,
- but the underlying breakpoint does not. In the cases of
- watchpoint scope, the watchpoint remains valid even if execution
- of the inferior leaves the scope of that watchpoint.
-
- -- Method on Breakpoint: delete
- Permanently deletes the GDB breakpoint. This also invalidates the
- Python `Breakpoint' object. Any further access to this object's
- attributes or methods will raise an error.
-
- -- Instance Variable of Breakpoint: enabled
- This attribute is `True' if the breakpoint is enabled, and `False'
- otherwise. This attribute is writable.
-
- -- Instance Variable of Breakpoint: silent
- This attribute is `True' if the breakpoint is silent, and `False'
- otherwise. This attribute is writable.
-
- Note that a breakpoint can also be silent if it has commands and
- the first command is `silent'. This is not reported by the
- `silent' attribute.
-
- -- Instance Variable of Breakpoint: thread
- If the breakpoint is thread-specific, this attribute holds the
- thread id. If the breakpoint is not thread-specific, this
- attribute is `None'. This attribute is writable.
-
- -- Instance Variable of Breakpoint: task
- If the breakpoint is Ada task-specific, this attribute holds the
- Ada task id. If the breakpoint is not task-specific (or the
- underlying language is not Ada), this attribute is `None'. This
- attribute is writable.
-
- -- Instance Variable of Breakpoint: ignore_count
- This attribute holds the ignore count for the breakpoint, an
- integer. This attribute is writable.
-
- -- Instance Variable of Breakpoint: number
- This attribute holds the breakpoint's number -- the identifier
- used by the user to manipulate the breakpoint. This attribute is
- not writable.
-
- -- Instance Variable of Breakpoint: type
- This attribute holds the breakpoint's type -- the identifier used
- to determine the actual breakpoint type or use-case. This
- attribute is not writable.
-
- -- Instance Variable of Breakpoint: visible
- This attribute tells whether the breakpoint is visible to the user
- when set, or when the `info breakpoints' command is run. This
- attribute is not writable.
-
- The available types are represented by constants defined in the `gdb'
-module:
-
-`BP_BREAKPOINT'
- Normal code breakpoint.
-
-`BP_WATCHPOINT'
- Watchpoint breakpoint.
-
-`BP_HARDWARE_WATCHPOINT'
- Hardware assisted watchpoint.
-
-`BP_READ_WATCHPOINT'
- Hardware assisted read watchpoint.
-
-`BP_ACCESS_WATCHPOINT'
- Hardware assisted access watchpoint.
-
- -- Instance Variable of Breakpoint: hit_count
- This attribute holds the hit count for the breakpoint, an integer.
- This attribute is writable, but currently it can only be set to
- zero.
-
- -- Instance Variable of Breakpoint: location
- This attribute holds the location of the breakpoint, as specified
- by the user. It is a string. If the breakpoint does not have a
- location (that is, it is a watchpoint) the attribute's value is
- `None'. This attribute is not writable.
-
- -- Instance Variable of Breakpoint: expression
- This attribute holds a breakpoint expression, as specified by the
- user. It is a string. If the breakpoint does not have an
- expression (the breakpoint is not a watchpoint) the attribute's
- value is `None'. This attribute is not writable.
-
- -- Instance Variable of Breakpoint: condition
- This attribute holds the condition of the breakpoint, as specified
- by the user. It is a string. If there is no condition, this
- attribute's value is `None'. This attribute is writable.
-
- -- Instance Variable of Breakpoint: commands
- This attribute holds the commands attached to the breakpoint. If
- there are commands, this attribute's value is a string holding all
- the commands, separated by newlines. If there are no commands,
- this attribute is `None'. This attribute is not writable.
-
-
-File: gdb.info, Node: Lazy Strings In Python, Next: Breakpoints In Python, Prev: Symbol Tables In Python, Up: Python API
-
-23.2.2.21 Python representation of lazy strings.
-................................................
-
-A "lazy string" is a string whose contents is not retrieved or encoded
-until it is needed.
-
- A `gdb.LazyString' is represented in GDB as an `address' that points
-to a region of memory, an `encoding' that will be used to encode that
-region of memory, and a `length' to delimit the region of memory that
-represents the string. The difference between a `gdb.LazyString' and a
-string wrapped within a `gdb.Value' is that a `gdb.LazyString' will be
-treated differently by GDB when printing. A `gdb.LazyString' is
-retrieved and encoded during printing, while a `gdb.Value' wrapping a
-string is immediately retrieved and encoded on creation.
-
- A `gdb.LazyString' object has the following functions:
-
- -- Method on LazyString: value
- Convert the `gdb.LazyString' to a `gdb.Value'. This value will
- point to the string in memory, but will lose all the delayed
- retrieval, encoding and handling that GDB applies to a
- `gdb.LazyString'.
-
- -- Instance Variable of LazyString: address
- This attribute holds the address of the string. This attribute is
- not writable.
-
- -- Instance Variable of LazyString: length
- This attribute holds the length of the string in characters. If
- the length is -1, then the string will be fetched and encoded up
- to the first null of appropriate width. This attribute is not
- writable.
-
- -- Instance Variable of LazyString: encoding
- This attribute holds the encoding that will be applied to the
- string when the string is printed by GDB. If the encoding is not
- set, or contains an empty string, then GDB will select the most
- appropriate encoding when the string is printed. This attribute
- is not writable.
-
- -- Instance Variable of LazyString: type
- This attribute holds the type that is represented by the lazy
- string's type. For a lazy string this will always be a pointer
- type. To resolve this to the lazy string's character type, use
- the type's `target' method. *Note Types In Python::. This
- attribute is not writable.
-
-
-File: gdb.info, Node: Auto-loading, Next: Python modules, Prev: Python API, Up: Python
-
-23.2.3 Auto-loading
--------------------
-
-When a new object file is read (for example, due to the `file' command,
-or because the inferior has loaded a shared library), GDB will look for
-Python support scripts in several ways: `OBJFILE-gdb.py' and
-`.debug_gdb_scripts' section.
-
-* Menu:
-
-* objfile-gdb.py file:: The `OBJFILE-gdb.py' file
-* .debug_gdb_scripts section:: The `.debug_gdb_scripts' section
-* Which flavor to choose?::
-
- The auto-loading feature is useful for supplying application-specific
-debugging commands and scripts.
-
- Auto-loading can be enabled or disabled, and the list of auto-loaded
-scripts can be printed.
-
-`set auto-load-scripts [yes|no]'
- Enable or disable the auto-loading of Python scripts.
-
-`show auto-load-scripts'
- Show whether auto-loading of Python scripts is enabled or disabled.
-
-`info auto-load-scripts [REGEXP]'
- Print the list of all scripts that GDB auto-loaded.
-
- Also printed is the list of scripts that were mentioned in the
- `.debug_gdb_scripts' section and were not found (*note
- .debug_gdb_scripts section::). This is useful because their names
- are not printed when GDB tries to load them and fails. There may
- be many of them, and printing an error message for each one is
- problematic.
-
- If REGEXP is supplied only scripts with matching names are printed.
-
- Example:
-
- (gdb) info auto-load-scripts
- Loaded Script
- Yes py-section-script.py
- full name: /tmp/py-section-script.py
- Missing my-foo-pretty-printers.py
-
- When reading an auto-loaded file, GDB sets the "current objfile".
-This is available via the `gdb.current_objfile' function (*note
-Objfiles In Python::). This can be useful for registering
-objfile-specific pretty-printers.
-
-
-File: gdb.info, Node: objfile-gdb.py file, Next: .debug_gdb_scripts section, Up: Auto-loading
-
-23.2.3.1 The `OBJFILE-gdb.py' file
-..................................
-
-When a new object file is read, GDB looks for a file named
-`OBJFILE-gdb.py', where OBJFILE is the object file's real name, formed
-by ensuring that the file name is absolute, following all symlinks, and
-resolving `.' and `..' components. If this file exists and is
-readable, GDB will evaluate it as a Python script.
-
- If this file does not exist, and if the parameter
-`debug-file-directory' is set (*note Separate Debug Files::), then GDB
-will look for REAL-NAME in all of the directories mentioned in the
-value of `debug-file-directory'.
-
- Finally, if this file does not exist, then GDB will look for a file
-named `DATA-DIRECTORY/python/auto-load/REAL-NAME', where DATA-DIRECTORY
-is GDB's data directory (available via `show data-directory', *note
-Data Files::), and REAL-NAME is the object file's real name, as
-described above.
-
- GDB does not track which files it has already auto-loaded this way.
-GDB will load the associated script every time the corresponding
-OBJFILE is opened. So your `-gdb.py' file should be careful to avoid
-errors if it is evaluated more than once.
-
-
-File: gdb.info, Node: .debug_gdb_scripts section, Next: Which flavor to choose?, Prev: objfile-gdb.py file, Up: Auto-loading
-
-23.2.3.2 The `.debug_gdb_scripts' section
-.........................................
-
-For systems using file formats like ELF and COFF, when GDB loads a new
-object file it will look for a special section named
-`.debug_gdb_scripts'. If this section exists, its contents is a list
-of names of scripts to load.
-
- GDB will look for each specified script file first in the current
-directory and then along the source search path (*note Specifying
-Source Directories: Source Path.), except that `$cdir' is not searched,
-since the compilation directory is not relevant to scripts.
-
- Entries can be placed in section `.debug_gdb_scripts' with, for
-example, this GCC macro:
-
- /* Note: The "MS" section flags are to remove duplicates. */
- #define DEFINE_GDB_SCRIPT(script_name) \
- asm("\
- .pushsection \".debug_gdb_scripts\", \"MS\",@progbits,1\n\
- .byte 1\n\
- .asciz \"" script_name "\"\n\
- .popsection \n\
- ");
-
-Then one can reference the macro in a header or source file like this:
-
- DEFINE_GDB_SCRIPT ("my-app-scripts.py")
-
- The script name may include directories if desired.
-
- If the macro is put in a header, any application or library using
-this header will get a reference to the specified script.
-
-
-File: gdb.info, Node: Which flavor to choose?, Prev: .debug_gdb_scripts section, Up: Auto-loading
-
-23.2.3.3 Which flavor to choose?
-................................
-
-Given the multiple ways of auto-loading Python scripts, it might not
-always be clear which one to choose. This section provides some
-guidance.
-
- Benefits of the `-gdb.py' way:
-
- * Can be used with file formats that don't support multiple sections.
-
- * Ease of finding scripts for public libraries.
-
- Scripts specified in the `.debug_gdb_scripts' section are searched
- for in the source search path. For publicly installed libraries,
- e.g., `libstdc++', there typically isn't a source directory in
- which to find the script.
-
- * Doesn't require source code additions.
-
- Benefits of the `.debug_gdb_scripts' way:
-
- * Works with static linking.
-
- Scripts for libraries done the `-gdb.py' way require an objfile to
- trigger their loading. When an application is statically linked
- the only objfile available is the executable, and it is cumbersome
- to attach all the scripts from all the input libraries to the
- executable's `-gdb.py' script.
-
- * Works with classes that are entirely inlined.
-
- Some classes can be entirely inlined, and thus there may not be an
- associated shared library to attach a `-gdb.py' script to.
-
- * Scripts needn't be copied out of the source tree.
-
- In some circumstances, apps can be built out of large collections
- of internal libraries, and the build infrastructure necessary to
- install the `-gdb.py' scripts in a place where GDB can find them is
- cumbersome. It may be easier to specify the scripts in the
- `.debug_gdb_scripts' section as relative paths, and add a path to
- the top of the source tree to the source search path.
-
-
-File: gdb.info, Node: Python modules, Prev: Auto-loading, Up: Python
-
-23.2.4 Python modules
----------------------
-
-GDB comes with a module to assist writing Python code.
-
-* Menu:
-
-* gdb.printing:: Building and registering pretty-printers.
-* gdb.types:: Utilities for working with types.
-
-
-File: gdb.info, Node: gdb.printing, Next: gdb.types, Up: Python modules
-
-23.2.4.1 gdb.printing
-.....................
-
-This module provides a collection of utilities for working with
-pretty-printers.
-
-`PrettyPrinter (NAME, SUBPRINTERS=None)'
- This class specifies the API that makes `info pretty-printer',
- `enable pretty-printer' and `disable pretty-printer' work.
- Pretty-printers should generally inherit from this class.
-
-`SubPrettyPrinter (NAME)'
- For printers that handle multiple types, this class specifies the
- corresponding API for the subprinters.
-
-`RegexpCollectionPrettyPrinter (NAME)'
- Utility class for handling multiple printers, all recognized via
- regular expressions. *Note Writing a Pretty-Printer::, for an
- example.
-
-`register_pretty_printer (OBJ, PRINTER, REPLACE=False)'
- Register PRINTER with the pretty-printer list of OBJ. If REPLACE
- is `True' then any existing copy of the printer is replaced.
- Otherwise a `RuntimeError' exception is raised if a printer with
- the same name already exists.
-
-
-File: gdb.info, Node: gdb.types, Prev: gdb.printing, Up: Python modules
-
-23.2.4.2 gdb.types
-..................
-
-This module provides a collection of utilities for working with
-`gdb.Types' objects.
-
-`get_basic_type (TYPE)'
- Return TYPE with const and volatile qualifiers stripped, and with
- typedefs and C++ references converted to the underlying type.
-
- C++ example:
-
- typedef const int const_int;
- const_int foo (3);
- const_int& foo_ref (foo);
- int main () { return 0; }
-
- Then in gdb:
-
- (gdb) start
- (gdb) python import gdb.types
- (gdb) python foo_ref = gdb.parse_and_eval("foo_ref")
- (gdb) python print gdb.types.get_basic_type(foo_ref.type)
- int
-
-`has_field (TYPE, FIELD)'
- Return `True' if TYPE, assumed to be a type with fields (e.g., a
- structure or union), has field FIELD.
-
-`make_enum_dict (ENUM_TYPE)'
- Return a Python `dictionary' type produced from ENUM_TYPE.
-
-
-File: gdb.info, Node: Interpreters, Next: TUI, Prev: Extending GDB, Up: Top
-
-24 Command Interpreters
-***********************
-
-GDB supports multiple command interpreters, and some command
-infrastructure to allow users or user interface writers to switch
-between interpreters or run commands in other interpreters.
-
- GDB currently supports two command interpreters, the console
-interpreter (sometimes called the command-line interpreter or CLI) and
-the machine interface interpreter (or GDB/MI). This manual describes
-both of these interfaces in great detail.
-
- By default, GDB will start with the console interpreter. However,
-the user may choose to start GDB with another interpreter by specifying
-the `-i' or `--interpreter' startup options. Defined interpreters
-include:
-
-`console'
- The traditional console or command-line interpreter. This is the
- most often used interpreter with GDB. With no interpreter
- specified at runtime, GDB will use this interpreter.
-
-`mi'
- The newest GDB/MI interface (currently `mi2'). Used primarily by
- programs wishing to use GDB as a backend for a debugger GUI or an
- IDE. For more information, see *note The GDB/MI Interface: GDB/MI.
-
-`mi2'
- The current GDB/MI interface.
-
-`mi1'
- The GDB/MI interface included in GDB 5.1, 5.2, and 5.3.
-
-
- The interpreter being used by GDB may not be dynamically switched at
-runtime. Although possible, this could lead to a very precarious
-situation. Consider an IDE using GDB/MI. If a user enters the command
-"interpreter-set console" in a console view, GDB would switch to using
-the console interpreter, rendering the IDE inoperable!
-
- Although you may only choose a single interpreter at startup, you
-may execute commands in any interpreter from the current interpreter
-using the appropriate command. If you are running the console
-interpreter, simply use the `interpreter-exec' command:
-
- interpreter-exec mi "-data-list-register-names"
-
- GDB/MI has a similar command, although it is only available in
-versions of GDB which support GDB/MI version 2 (or greater).
-
-
-File: gdb.info, Node: TUI, Next: Emacs, Prev: Interpreters, Up: Top
-
-25 GDB Text User Interface
-**************************
-
-* Menu:
-
-* TUI Overview:: TUI overview
-* TUI Keys:: TUI key bindings
-* TUI Single Key Mode:: TUI single key mode
-* TUI Commands:: TUI-specific commands
-* TUI Configuration:: TUI configuration variables
-
- The GDB Text User Interface (TUI) is a terminal interface which uses
-the `curses' library to show the source file, the assembly output, the
-program registers and GDB commands in separate text windows. The TUI
-mode is supported only on platforms where a suitable version of the
-`curses' library is available.
-
- The TUI mode is enabled by default when you invoke GDB as either
-`gdbtui' or `gdb -tui'. You can also switch in and out of TUI mode
-while GDB runs by using various TUI commands and key bindings, such as
-`C-x C-a'. *Note TUI Key Bindings: TUI Keys.
-
-
-File: gdb.info, Node: TUI Overview, Next: TUI Keys, Up: TUI
-
-25.1 TUI Overview
-=================
-
-In TUI mode, GDB can display several text windows:
-
-_command_
- This window is the GDB command window with the GDB prompt and the
- GDB output. The GDB input is still managed using readline.
-
-_source_
- The source window shows the source file of the program. The
- current line and active breakpoints are displayed in this window.
-
-_assembly_
- The assembly window shows the disassembly output of the program.
-
-_register_
- This window shows the processor registers. Registers are
- highlighted when their values change.
-
- The source and assembly windows show the current program position by
-highlighting the current line and marking it with a `>' marker.
-Breakpoints are indicated with two markers. The first marker indicates
-the breakpoint type:
-
-`B'
- Breakpoint which was hit at least once.
-
-`b'
- Breakpoint which was never hit.
-
-`H'
- Hardware breakpoint which was hit at least once.
-
-`h'
- Hardware breakpoint which was never hit.
-
- The second marker indicates whether the breakpoint is enabled or not:
-
-`+'
- Breakpoint is enabled.
-
-`-'
- Breakpoint is disabled.
-
- The source, assembly and register windows are updated when the
-current thread changes, when the frame changes, or when the program
-counter changes.
-
- These windows are not all visible at the same time. The command
-window is always visible. The others can be arranged in several
-layouts:
-
- * source only,
-
- * assembly only,
-
- * source and assembly,
-
- * source and registers, or
-
- * assembly and registers.
-
- A status line above the command window shows the following
-information:
-
-_target_
- Indicates the current GDB target. (*note Specifying a Debugging
- Target: Targets.).
-
-_process_
- Gives the current process or thread number. When no process is
- being debugged, this field is set to `No process'.
-
-_function_
- Gives the current function name for the selected frame. The name
- is demangled if demangling is turned on (*note Print Settings::).
- When there is no symbol corresponding to the current program
- counter, the string `??' is displayed.
-
-_line_
- Indicates the current line number for the selected frame. When
- the current line number is not known, the string `??' is displayed.
-
-_pc_
- Indicates the current program counter address.
-
-
-File: gdb.info, Node: TUI Keys, Next: TUI Single Key Mode, Prev: TUI Overview, Up: TUI
-
-25.2 TUI Key Bindings
-=====================
-
-The TUI installs several key bindings in the readline keymaps (*note
-Command Line Editing::). The following key bindings are installed for
-both TUI mode and the GDB standard mode.
-
-`C-x C-a'
-`C-x a'
-`C-x A'
- Enter or leave the TUI mode. When leaving the TUI mode, the
- curses window management stops and GDB operates using its standard
- mode, writing on the terminal directly. When reentering the TUI
- mode, control is given back to the curses windows. The screen is
- then refreshed.
-
-`C-x 1'
- Use a TUI layout with only one window. The layout will either be
- `source' or `assembly'. When the TUI mode is not active, it will
- switch to the TUI mode.
-
- Think of this key binding as the Emacs `C-x 1' binding.
-
-`C-x 2'
- Use a TUI layout with at least two windows. When the current
- layout already has two windows, the next layout with two windows
- is used. When a new layout is chosen, one window will always be
- common to the previous layout and the new one.
-
- Think of it as the Emacs `C-x 2' binding.
-
-`C-x o'
- Change the active window. The TUI associates several key bindings
- (like scrolling and arrow keys) with the active window. This
- command gives the focus to the next TUI window.
-
- Think of it as the Emacs `C-x o' binding.
-
-`C-x s'
- Switch in and out of the TUI SingleKey mode that binds single keys
- to GDB commands (*note TUI Single Key Mode::).
-
- The following key bindings only work in the TUI mode:
-
-<PgUp>
- Scroll the active window one page up.
-
-<PgDn>
- Scroll the active window one page down.
-
-<Up>
- Scroll the active window one line up.
-
-<Down>
- Scroll the active window one line down.
-
-<Left>
- Scroll the active window one column left.
-
-<Right>
- Scroll the active window one column right.
-
-`C-L'
- Refresh the screen.
-
- Because the arrow keys scroll the active window in the TUI mode, they
-are not available for their normal use by readline unless the command
-window has the focus. When another window is active, you must use
-other readline key bindings such as `C-p', `C-n', `C-b' and `C-f' to
-control the command window.
-
-
-File: gdb.info, Node: TUI Single Key Mode, Next: TUI Commands, Prev: TUI Keys, Up: TUI
-
-25.3 TUI Single Key Mode
-========================
-
-The TUI also provides a "SingleKey" mode, which binds several
-frequently used GDB commands to single keys. Type `C-x s' to switch
-into this mode, where the following key bindings are used:
-
-`c'
- continue
-
-`d'
- down
-
-`f'
- finish
-
-`n'
- next
-
-`q'
- exit the SingleKey mode.
-
-`r'
- run
-
-`s'
- step
-
-`u'
- up
-
-`v'
- info locals
-
-`w'
- where
-
- Other keys temporarily switch to the GDB command prompt. The key
-that was pressed is inserted in the editing buffer so that it is
-possible to type most GDB commands without interaction with the TUI
-SingleKey mode. Once the command is entered the TUI SingleKey mode is
-restored. The only way to permanently leave this mode is by typing `q'
-or `C-x s'.
-
-
-File: gdb.info, Node: TUI Commands, Next: TUI Configuration, Prev: TUI Single Key Mode, Up: TUI
-
-25.4 TUI-specific Commands
-==========================
-
-The TUI has specific commands to control the text windows. These
-commands are always available, even when GDB is not in the TUI mode.
-When GDB is in the standard mode, most of these commands will
-automatically switch to the TUI mode.
-
- Note that if GDB's `stdout' is not connected to a terminal, or GDB
-has been started with the machine interface interpreter (*note The
-GDB/MI Interface: GDB/MI.), most of these commands will fail with an
-error, because it would not be possible or desirable to enable curses
-window management.
-
-`info win'
- List and give the size of all displayed windows.
-
-`layout next'
- Display the next layout.
-
-`layout prev'
- Display the previous layout.
-
-`layout src'
- Display the source window only.
-
-`layout asm'
- Display the assembly window only.
-
-`layout split'
- Display the source and assembly window.
-
-`layout regs'
- Display the register window together with the source or assembly
- window.
-
-`focus next'
- Make the next window active for scrolling.
-
-`focus prev'
- Make the previous window active for scrolling.
-
-`focus src'
- Make the source window active for scrolling.
-
-`focus asm'
- Make the assembly window active for scrolling.
-
-`focus regs'
- Make the register window active for scrolling.
-
-`focus cmd'
- Make the command window active for scrolling.
-
-`refresh'
- Refresh the screen. This is similar to typing `C-L'.
-
-`tui reg float'
- Show the floating point registers in the register window.
-
-`tui reg general'
- Show the general registers in the register window.
-
-`tui reg next'
- Show the next register group. The list of register groups as well
- as their order is target specific. The predefined register groups
- are the following: `general', `float', `system', `vector', `all',
- `save', `restore'.
-
-`tui reg system'
- Show the system registers in the register window.
-
-`update'
- Update the source window and the current execution point.
-
-`winheight NAME +COUNT'
-`winheight NAME -COUNT'
- Change the height of the window NAME by COUNT lines. Positive
- counts increase the height, while negative counts decrease it.
-
-`tabset NCHARS'
- Set the width of tab stops to be NCHARS characters.
-
-
-File: gdb.info, Node: TUI Configuration, Prev: TUI Commands, Up: TUI
-
-25.5 TUI Configuration Variables
-================================
-
-Several configuration variables control the appearance of TUI windows.
-
-`set tui border-kind KIND'
- Select the border appearance for the source, assembly and register
- windows. The possible values are the following:
- `space'
- Use a space character to draw the border.
-
- `ascii'
- Use ASCII characters `+', `-' and `|' to draw the border.
-
- `acs'
- Use the Alternate Character Set to draw the border. The
- border is drawn using character line graphics if the terminal
- supports them.
-
-`set tui border-mode MODE'
-`set tui active-border-mode MODE'
- Select the display attributes for the borders of the inactive
- windows or the active window. The MODE can be one of the
- following:
- `normal'
- Use normal attributes to display the border.
-
- `standout'
- Use standout mode.
-
- `reverse'
- Use reverse video mode.
-
- `half'
- Use half bright mode.
-
- `half-standout'
- Use half bright and standout mode.
-
- `bold'
- Use extra bright or bold mode.
-
- `bold-standout'
- Use extra bright or bold and standout mode.
-
-
-File: gdb.info, Node: Emacs, Next: GDB/MI, Prev: TUI, Up: Top
-
-26 Using GDB under GNU Emacs
-****************************
-
-A special interface allows you to use GNU Emacs to view (and edit) the
-source files for the program you are debugging with GDB.
-
- To use this interface, use the command `M-x gdb' in Emacs. Give the
-executable file you want to debug as an argument. This command starts
-GDB as a subprocess of Emacs, with input and output through a newly
-created Emacs buffer.
-
- Running GDB under Emacs can be just like running GDB normally except
-for two things:
-
- * All "terminal" input and output goes through an Emacs buffer,
- called the GUD buffer.
-
- This applies both to GDB commands and their output, and to the
- input and output done by the program you are debugging.
-
- This is useful because it means that you can copy the text of
- previous commands and input them again; you can even use parts of
- the output in this way.
-
- All the facilities of Emacs' Shell mode are available for
- interacting with your program. In particular, you can send
- signals the usual way--for example, `C-c C-c' for an interrupt,
- `C-c C-z' for a stop.
-
- * GDB displays source code through Emacs.
-
- Each time GDB displays a stack frame, Emacs automatically finds the
- source file for that frame and puts an arrow (`=>') at the left
- margin of the current line. Emacs uses a separate buffer for
- source display, and splits the screen to show both your GDB session
- and the source.
-
- Explicit GDB `list' or search commands still produce output as
- usual, but you probably have no reason to use them from Emacs.
-
- We call this "text command mode". Emacs 22.1, and later, also uses
-a graphical mode, enabled by default, which provides further buffers
-that can control the execution and describe the state of your program.
-*Note GDB Graphical Interface: (Emacs)GDB Graphical Interface.
-
- If you specify an absolute file name when prompted for the `M-x gdb'
-argument, then Emacs sets your current working directory to where your
-program resides. If you only specify the file name, then Emacs sets
-your current working directory to to the directory associated with the
-previous buffer. In this case, GDB may find your program by searching
-your environment's `PATH' variable, but on some operating systems it
-might not find the source. So, although the GDB input and output
-session proceeds normally, the auxiliary buffer does not display the
-current source and line of execution.
-
- The initial working directory of GDB is printed on the top line of
-the GUD buffer and this serves as a default for the commands that
-specify files for GDB to operate on. *Note Commands to Specify Files:
-Files.
-
- By default, `M-x gdb' calls the program called `gdb'. If you need
-to call GDB by a different name (for example, if you keep several
-configurations around, with different names) you can customize the
-Emacs variable `gud-gdb-command-name' to run the one you want.
-
- In the GUD buffer, you can use these special Emacs commands in
-addition to the standard Shell mode commands:
-
-`C-h m'
- Describe the features of Emacs' GUD Mode.
-
-`C-c C-s'
- Execute to another source line, like the GDB `step' command; also
- update the display window to show the current file and location.
-
-`C-c C-n'
- Execute to next source line in this function, skipping all function
- calls, like the GDB `next' command. Then update the display window
- to show the current file and location.
-
-`C-c C-i'
- Execute one instruction, like the GDB `stepi' command; update
- display window accordingly.
-
-`C-c C-f'
- Execute until exit from the selected stack frame, like the GDB
- `finish' command.
-
-`C-c C-r'
- Continue execution of your program, like the GDB `continue'
- command.
-
-`C-c <'
- Go up the number of frames indicated by the numeric argument
- (*note Numeric Arguments: (Emacs)Arguments.), like the GDB `up'
- command.
-
-`C-c >'
- Go down the number of frames indicated by the numeric argument,
- like the GDB `down' command.
-
- In any source file, the Emacs command `C-x <SPC>' (`gud-break')
-tells GDB to set a breakpoint on the source line point is on.
-
- In text command mode, if you type `M-x speedbar', Emacs displays a
-separate frame which shows a backtrace when the GUD buffer is current.
-Move point to any frame in the stack and type <RET> to make it become
-the current frame and display the associated source in the source
-buffer. Alternatively, click `Mouse-2' to make the selected frame
-become the current one. In graphical mode, the speedbar displays watch
-expressions.
-
- If you accidentally delete the source-display buffer, an easy way to
-get it back is to type the command `f' in the GDB buffer, to request a
-frame display; when you run under Emacs, this recreates the source
-buffer if necessary to show you the context of the current frame.
-
- The source files displayed in Emacs are in ordinary Emacs buffers
-which are visiting the source files in the usual way. You can edit the
-files with these buffers if you wish; but keep in mind that GDB
-communicates with Emacs in terms of line numbers. If you add or delete
-lines from the text, the line numbers that GDB knows cease to
-correspond properly with the code.
-
- A more detailed description of Emacs' interaction with GDB is given
-in the Emacs manual (*note Debuggers: (Emacs)Debuggers.).
-
-
-File: gdb.info, Node: GDB/MI, Next: Annotations, Prev: Emacs, Up: Top
-
-27 The GDB/MI Interface
-***********************
-
-Function and Purpose
-====================
-
-GDB/MI is a line based machine oriented text interface to GDB and is
-activated by specifying using the `--interpreter' command line option
-(*note Mode Options::). It is specifically intended to support the
-development of systems which use the debugger as just one small
-component of a larger system.
-
- This chapter is a specification of the GDB/MI interface. It is
-written in the form of a reference manual.
-
- Note that GDB/MI is still under construction, so some of the
-features described below are incomplete and subject to change (*note
-GDB/MI Development and Front Ends: GDB/MI Development and Front Ends.).
-
-Notation and Terminology
-========================
-
-This chapter uses the following notation:
-
- * `|' separates two alternatives.
-
- * `[ SOMETHING ]' indicates that SOMETHING is optional: it may or
- may not be given.
-
- * `( GROUP )*' means that GROUP inside the parentheses may repeat
- zero or more times.
-
- * `( GROUP )+' means that GROUP inside the parentheses may repeat
- one or more times.
-
- * `"STRING"' means a literal STRING.
-
-* Menu:
-
-* GDB/MI General Design::
-* GDB/MI Command Syntax::
-* GDB/MI Compatibility with CLI::
-* GDB/MI Development and Front Ends::
-* GDB/MI Output Records::
-* GDB/MI Simple Examples::
-* GDB/MI Command Description Format::
-* GDB/MI Breakpoint Commands::
-* GDB/MI Program Context::
-* GDB/MI Thread Commands::
-* GDB/MI Program Execution::
-* GDB/MI Stack Manipulation::
-* GDB/MI Variable Objects::
-* GDB/MI Data Manipulation::
-* GDB/MI Tracepoint Commands::
-* GDB/MI Symbol Query::
-* GDB/MI File Commands::
-* GDB/MI Target Manipulation::
-* GDB/MI File Transfer Commands::
-* GDB/MI Miscellaneous Commands::
-
-
-File: gdb.info, Node: GDB/MI General Design, Next: GDB/MI Command Syntax, Up: GDB/MI
-
-27.1 GDB/MI General Design
-==========================
-
-Interaction of a GDB/MI frontend with GDB involves three
-parts--commands sent to GDB, responses to those commands and
-notifications. Each command results in exactly one response,
-indicating either successful completion of the command, or an error.
-For the commands that do not resume the target, the response contains
-the requested information. For the commands that resume the target, the
-response only indicates whether the target was successfully resumed.
-Notifications is the mechanism for reporting changes in the state of the
-target, or in GDB state, that cannot conveniently be associated with a
-command and reported as part of that command response.
-
- The important examples of notifications are:
- * Exec notifications. These are used to report changes in target
- state--when a target is resumed, or stopped. It would not be
- feasible to include this information in response of resuming
- commands, because one resume commands can result in multiple
- events in different threads. Also, quite some time may pass
- before any event happens in the target, while a frontend needs to
- know whether the resuming command itself was successfully executed.
-
- * Console output, and status notifications. Console output
- notifications are used to report output of CLI commands, as well as
- diagnostics for other commands. Status notifications are used to
- report the progress of a long-running operation. Naturally,
- including this information in command response would mean no
- output is produced until the command is finished, which is
- undesirable.
-
- * General notifications. Commands may have various side effects on
- the GDB or target state beyond their official purpose. For
- example, a command may change the selected thread. Although such
- changes can be included in command response, using notification
- allows for more orthogonal frontend design.
-
-
- There's no guarantee that whenever an MI command reports an error,
-GDB or the target are in any specific state, and especially, the state
-is not reverted to the state before the MI command was processed.
-Therefore, whenever an MI command results in an error, we recommend
-that the frontend refreshes all the information shown in the user
-interface.
-
-* Menu:
-
-* Context management::
-* Asynchronous and non-stop modes::
-* Thread groups::
-
-
-File: gdb.info, Node: Context management, Next: Asynchronous and non-stop modes, Up: GDB/MI General Design
-
-27.1.1 Context management
--------------------------
-
-In most cases when GDB accesses the target, this access is done in
-context of a specific thread and frame (*note Frames::). Often, even
-when accessing global data, the target requires that a thread be
-specified. The CLI interface maintains the selected thread and frame,
-and supplies them to target on each command. This is convenient,
-because a command line user would not want to specify that information
-explicitly on each command, and because user interacts with GDB via a
-single terminal, so no confusion is possible as to what thread and
-frame are the current ones.
-
- In the case of MI, the concept of selected thread and frame is less
-useful. First, a frontend can easily remember this information itself.
-Second, a graphical frontend can have more than one window, each one
-used for debugging a different thread, and the frontend might want to
-access additional threads for internal purposes. This increases the
-risk that by relying on implicitly selected thread, the frontend may be
-operating on a wrong one. Therefore, each MI command should explicitly
-specify which thread and frame to operate on. To make it possible,
-each MI command accepts the `--thread' and `--frame' options, the value
-to each is GDB identifier for thread and frame to operate on.
-
- Usually, each top-level window in a frontend allows the user to
-select a thread and a frame, and remembers the user selection for
-further operations. However, in some cases GDB may suggest that the
-current thread be changed. For example, when stopping on a breakpoint
-it is reasonable to switch to the thread where breakpoint is hit. For
-another example, if the user issues the CLI `thread' command via the
-frontend, it is desirable to change the frontend's selected thread to
-the one specified by user. GDB communicates the suggestion to change
-current thread using the `=thread-selected' notification. No such
-notification is available for the selected frame at the moment.
-
- Note that historically, MI shares the selected thread with CLI, so
-frontends used the `-thread-select' to execute commands in the right
-context. However, getting this to work right is cumbersome. The
-simplest way is for frontend to emit `-thread-select' command before
-every command. This doubles the number of commands that need to be
-sent. The alternative approach is to suppress `-thread-select' if the
-selected thread in GDB is supposed to be identical to the thread the
-frontend wants to operate on. However, getting this optimization right
-can be tricky. In particular, if the frontend sends several commands
-to GDB, and one of the commands changes the selected thread, then the
-behaviour of subsequent commands will change. So, a frontend should
-either wait for response from such problematic commands, or explicitly
-add `-thread-select' for all subsequent commands. No frontend is known
-to do this exactly right, so it is suggested to just always pass the
-`--thread' and `--frame' options.
-
-
-File: gdb.info, Node: Asynchronous and non-stop modes, Next: Thread groups, Prev: Context management, Up: GDB/MI General Design
-
-27.1.2 Asynchronous command execution and non-stop mode
--------------------------------------------------------
-
-On some targets, GDB is capable of processing MI commands even while
-the target is running. This is called "asynchronous command execution"
-(*note Background Execution::). The frontend may specify a preferrence
-for asynchronous execution using the `-gdb-set target-async 1' command,
-which should be emitted before either running the executable or
-attaching to the target. After the frontend has started the executable
-or attached to the target, it can find if asynchronous execution is
-enabled using the `-list-target-features' command.
-
- Even if GDB can accept a command while target is running, many
-commands that access the target do not work when the target is running.
-Therefore, asynchronous command execution is most useful when combined
-with non-stop mode (*note Non-Stop Mode::). Then, it is possible to
-examine the state of one thread, while other threads are running.
-
- When a given thread is running, MI commands that try to access the
-target in the context of that thread may not work, or may work only on
-some targets. In particular, commands that try to operate on thread's
-stack will not work, on any target. Commands that read memory, or
-modify breakpoints, may work or not work, depending on the target. Note
-that even commands that operate on global state, such as `print',
-`set', and breakpoint commands, still access the target in the context
-of a specific thread, so frontend should try to find a stopped thread
-and perform the operation on that thread (using the `--thread' option).
-
- Which commands will work in the context of a running thread is
-highly target dependent. However, the two commands `-exec-interrupt',
-to stop a thread, and `-thread-info', to find the state of a thread,
-will always work.
-
-
-File: gdb.info, Node: Thread groups, Prev: Asynchronous and non-stop modes, Up: GDB/MI General Design
-
-27.1.3 Thread groups
---------------------
-
-GDB may be used to debug several processes at the same time. On some
-platfroms, GDB may support debugging of several hardware systems, each
-one having several cores with several different processes running on
-each core. This section describes the MI mechanism to support such
-debugging scenarios.
-
- The key observation is that regardless of the structure of the
-target, MI can have a global list of threads, because most commands that
-accept the `--thread' option do not need to know what process that
-thread belongs to. Therefore, it is not necessary to introduce neither
-additional `--process' option, nor an notion of the current process in
-the MI interface. The only strictly new feature that is required is
-the ability to find how the threads are grouped into processes.
-
- To allow the user to discover such grouping, and to support arbitrary
-hierarchy of machines/cores/processes, MI introduces the concept of a
-"thread group". Thread group is a collection of threads and other
-thread groups. A thread group always has a string identifier, a type,
-and may have additional attributes specific to the type. A new
-command, `-list-thread-groups', returns the list of top-level thread
-groups, which correspond to processes that GDB is debugging at the
-moment. By passing an identifier of a thread group to the
-`-list-thread-groups' command, it is possible to obtain the members of
-specific thread group.
-
- To allow the user to easily discover processes, and other objects, he
-wishes to debug, a concept of "available thread group" is introduced.
-Available thread group is an thread group that GDB is not debugging,
-but that can be attached to, using the `-target-attach' command. The
-list of available top-level thread groups can be obtained using
-`-list-thread-groups --available'. In general, the content of a thread
-group may be only retrieved only after attaching to that thread group.
-
- Thread groups are related to inferiors (*note Inferiors and
-Programs::). Each inferior corresponds to a thread group of a special
-type `process', and some additional operations are permitted on such
-thread groups.
-
-
-File: gdb.info, Node: GDB/MI Command Syntax, Next: GDB/MI Compatibility with CLI, Prev: GDB/MI General Design, Up: GDB/MI
-
-27.2 GDB/MI Command Syntax
-==========================
-
-* Menu:
-
-* GDB/MI Input Syntax::
-* GDB/MI Output Syntax::
-
-
-File: gdb.info, Node: GDB/MI Input Syntax, Next: GDB/MI Output Syntax, Up: GDB/MI Command Syntax
-
-27.2.1 GDB/MI Input Syntax
---------------------------
-
-`COMMAND ==>'
- `CLI-COMMAND | MI-COMMAND'
-
-`CLI-COMMAND ==>'
- `[ TOKEN ] CLI-COMMAND NL', where CLI-COMMAND is any existing GDB
- CLI command.
-
-`MI-COMMAND ==>'
- `[ TOKEN ] "-" OPERATION ( " " OPTION )* `[' " --" `]' ( " "
- PARAMETER )* NL'
-
-`TOKEN ==>'
- "any sequence of digits"
-
-`OPTION ==>'
- `"-" PARAMETER [ " " PARAMETER ]'
-
-`PARAMETER ==>'
- `NON-BLANK-SEQUENCE | C-STRING'
-
-`OPERATION ==>'
- _any of the operations described in this chapter_
-
-`NON-BLANK-SEQUENCE ==>'
- _anything, provided it doesn't contain special characters such as
- "-", NL, """ and of course " "_
-
-`C-STRING ==>'
- `""" SEVEN-BIT-ISO-C-STRING-CONTENT """'
-
-`NL ==>'
- `CR | CR-LF'
-
-Notes:
-
- * The CLI commands are still handled by the MI interpreter; their
- output is described below.
-
- * The `TOKEN', when present, is passed back when the command
- finishes.
-
- * Some MI commands accept optional arguments as part of the parameter
- list. Each option is identified by a leading `-' (dash) and may be
- followed by an optional argument parameter. Options occur first
- in the parameter list and can be delimited from normal parameters
- using `--' (this is useful when some parameters begin with a dash).
-
- Pragmatics:
-
- * We want easy access to the existing CLI syntax (for debugging).
-
- * We want it to be easy to spot a MI operation.
-
-
-File: gdb.info, Node: GDB/MI Output Syntax, Prev: GDB/MI Input Syntax, Up: GDB/MI Command Syntax
-
-27.2.2 GDB/MI Output Syntax
----------------------------
-
-The output from GDB/MI consists of zero or more out-of-band records
-followed, optionally, by a single result record. This result record is
-for the most recent command. The sequence of output records is
-terminated by `(gdb)'.
-
- If an input command was prefixed with a `TOKEN' then the
-corresponding output for that command will also be prefixed by that same
-TOKEN.
-
-`OUTPUT ==>'
- `( OUT-OF-BAND-RECORD )* [ RESULT-RECORD ] "(gdb)" NL'
-
-`RESULT-RECORD ==>'
- ` [ TOKEN ] "^" RESULT-CLASS ( "," RESULT )* NL'
-
-`OUT-OF-BAND-RECORD ==>'
- `ASYNC-RECORD | STREAM-RECORD'
-
-`ASYNC-RECORD ==>'
- `EXEC-ASYNC-OUTPUT | STATUS-ASYNC-OUTPUT | NOTIFY-ASYNC-OUTPUT'
-
-`EXEC-ASYNC-OUTPUT ==>'
- `[ TOKEN ] "*" ASYNC-OUTPUT'
-
-`STATUS-ASYNC-OUTPUT ==>'
- `[ TOKEN ] "+" ASYNC-OUTPUT'
-
-`NOTIFY-ASYNC-OUTPUT ==>'
- `[ TOKEN ] "=" ASYNC-OUTPUT'
-
-`ASYNC-OUTPUT ==>'
- `ASYNC-CLASS ( "," RESULT )* NL'
-
-`RESULT-CLASS ==>'
- `"done" | "running" | "connected" | "error" | "exit"'
-
-`ASYNC-CLASS ==>'
- `"stopped" | OTHERS' (where OTHERS will be added depending on the
- needs--this is still in development).
-
-`RESULT ==>'
- ` VARIABLE "=" VALUE'
-
-`VARIABLE ==>'
- ` STRING '
-
-`VALUE ==>'
- ` CONST | TUPLE | LIST '
-
-`CONST ==>'
- `C-STRING'
-
-`TUPLE ==>'
- ` "{}" | "{" RESULT ( "," RESULT )* "}" '
-
-`LIST ==>'
- ` "[]" | "[" VALUE ( "," VALUE )* "]" | "[" RESULT ( "," RESULT )*
- "]" '
-
-`STREAM-RECORD ==>'
- `CONSOLE-STREAM-OUTPUT | TARGET-STREAM-OUTPUT | LOG-STREAM-OUTPUT'
-
-`CONSOLE-STREAM-OUTPUT ==>'
- `"~" C-STRING'
-
-`TARGET-STREAM-OUTPUT ==>'
- `"@" C-STRING'
-
-`LOG-STREAM-OUTPUT ==>'
- `"&" C-STRING'
-
-`NL ==>'
- `CR | CR-LF'
-
-`TOKEN ==>'
- _any sequence of digits_.
-
-Notes:
-
- * All output sequences end in a single line containing a period.
-
- * The `TOKEN' is from the corresponding request. Note that for all
- async output, while the token is allowed by the grammar and may be
- output by future versions of GDB for select async output messages,
- it is generally omitted. Frontends should treat all async output
- as reporting general changes in the state of the target and there
- should be no need to associate async output to any prior command.
-
- * STATUS-ASYNC-OUTPUT contains on-going status information about the
- progress of a slow operation. It can be discarded. All status
- output is prefixed by `+'.
-
- * EXEC-ASYNC-OUTPUT contains asynchronous state change on the target
- (stopped, started, disappeared). All async output is prefixed by
- `*'.
-
- * NOTIFY-ASYNC-OUTPUT contains supplementary information that the
- client should handle (e.g., a new breakpoint information). All
- notify output is prefixed by `='.
-
- * CONSOLE-STREAM-OUTPUT is output that should be displayed as is in
- the console. It is the textual response to a CLI command. All
- the console output is prefixed by `~'.
-
- * TARGET-STREAM-OUTPUT is the output produced by the target program.
- All the target output is prefixed by `@'.
-
- * LOG-STREAM-OUTPUT is output text coming from GDB's internals, for
- instance messages that should be displayed as part of an error
- log. All the log output is prefixed by `&'.
-
- * New GDB/MI commands should only output LISTS containing VALUES.
-
-
- *Note GDB/MI Stream Records: GDB/MI Stream Records, for more details
-about the various output records.
-
-
-File: gdb.info, Node: GDB/MI Compatibility with CLI, Next: GDB/MI Development and Front Ends, Prev: GDB/MI Command Syntax, Up: GDB/MI
-
-27.3 GDB/MI Compatibility with CLI
-==================================
-
-For the developers convenience CLI commands can be entered directly,
-but there may be some unexpected behaviour. For example, commands that
-query the user will behave as if the user replied yes, breakpoint
-command lists are not executed and some CLI commands, such as `if',
-`when' and `define', prompt for further input with `>', which is not
-valid MI output.
-
- This feature may be removed at some stage in the future and it is
-recommended that front ends use the `-interpreter-exec' command (*note
--interpreter-exec::).
-
-
-File: gdb.info, Node: GDB/MI Development and Front Ends, Next: GDB/MI Output Records, Prev: GDB/MI Compatibility with CLI, Up: GDB/MI
-
-27.4 GDB/MI Development and Front Ends
-======================================
-
-The application which takes the MI output and presents the state of the
-program being debugged to the user is called a "front end".
-
- Although GDB/MI is still incomplete, it is currently being used by a
-variety of front ends to GDB. This makes it difficult to introduce new
-functionality without breaking existing usage. This section tries to
-minimize the problems by describing how the protocol might change.
-
- Some changes in MI need not break a carefully designed front end, and
-for these the MI version will remain unchanged. The following is a
-list of changes that may occur within one level, so front ends should
-parse MI output in a way that can handle them:
-
- * New MI commands may be added.
-
- * New fields may be added to the output of any MI command.
-
- * The range of values for fields with specified values, e.g.,
- `in_scope' (*note -var-update::) may be extended.
-
-
- If the changes are likely to break front ends, the MI version level
-will be increased by one. This will allow the front end to parse the
-output according to the MI version. Apart from mi0, new versions of
-GDB will not support old versions of MI and it will be the
-responsibility of the front end to work with the new one.
-
- The best way to avoid unexpected changes in MI that might break your
-front end is to make your project known to GDB developers and follow
-development on <gdb@sourceware.org> and <gdb-patches@sourceware.org>.
-
-
-File: gdb.info, Node: GDB/MI Output Records, Next: GDB/MI Simple Examples, Prev: GDB/MI Development and Front Ends, Up: GDB/MI
-
-27.5 GDB/MI Output Records
-==========================
-
-* Menu:
-
-* GDB/MI Result Records::
-* GDB/MI Stream Records::
-* GDB/MI Async Records::
-* GDB/MI Frame Information::
-* GDB/MI Thread Information::
-* GDB/MI Ada Exception Information::
-
-
-File: gdb.info, Node: GDB/MI Result Records, Next: GDB/MI Stream Records, Up: GDB/MI Output Records
-
-27.5.1 GDB/MI Result Records
-----------------------------
-
-In addition to a number of out-of-band notifications, the response to a
-GDB/MI command includes one of the following result indications:
-
-`"^done" [ "," RESULTS ]'
- The synchronous operation was successful, `RESULTS' are the return
- values.
-
-`"^running"'
- This result record is equivalent to `^done'. Historically, it was
- output instead of `^done' if the command has resumed the target.
- This behaviour is maintained for backward compatibility, but all
- frontends should treat `^done' and `^running' identically and rely
- on the `*running' output record to determine which threads are
- resumed.
-
-`"^connected"'
- GDB has connected to a remote target.
-
-`"^error" "," C-STRING'
- The operation failed. The `C-STRING' contains the corresponding
- error message.
-
-`"^exit"'
- GDB has terminated.
-
-
-
-File: gdb.info, Node: GDB/MI Stream Records, Next: GDB/MI Async Records, Prev: GDB/MI Result Records, Up: GDB/MI Output Records
-
-27.5.2 GDB/MI Stream Records
-----------------------------
-
-GDB internally maintains a number of output streams: the console, the
-target, and the log. The output intended for each of these streams is
-funneled through the GDB/MI interface using "stream records".
-
- Each stream record begins with a unique "prefix character" which
-identifies its stream (*note GDB/MI Output Syntax: GDB/MI Output
-Syntax.). In addition to the prefix, each stream record contains a
-`STRING-OUTPUT'. This is either raw text (with an implicit new line)
-or a quoted C string (which does not contain an implicit newline).
-
-`"~" STRING-OUTPUT'
- The console output stream contains text that should be displayed
- in the CLI console window. It contains the textual responses to
- CLI commands.
-
-`"@" STRING-OUTPUT'
- The target output stream contains any textual output from the
- running target. This is only present when GDB's event loop is
- truly asynchronous, which is currently only the case for remote
- targets.
-
-`"&" STRING-OUTPUT'
- The log stream contains debugging messages being produced by GDB's
- internals.
-
-
-File: gdb.info, Node: GDB/MI Async Records, Next: GDB/MI Frame Information, Prev: GDB/MI Stream Records, Up: GDB/MI Output Records
-
-27.5.3 GDB/MI Async Records
----------------------------
-
-"Async" records are used to notify the GDB/MI client of additional
-changes that have occurred. Those changes can either be a consequence
-of GDB/MI commands (e.g., a breakpoint modified) or a result of target
-activity (e.g., target stopped).
-
- The following is the list of possible async records:
-
-`*running,thread-id="THREAD"'
- The target is now running. The THREAD field tells which specific
- thread is now running, and can be `all' if all threads are
- running. The frontend should assume that no interaction with a
- running thread is possible after this notification is produced.
- The frontend should not assume that this notification is output
- only once for any command. GDB may emit this notification several
- times, either for different threads, because it cannot resume all
- threads together, or even for a single thread, if the thread must
- be stepped though some code before letting it run freely.
-
-`*stopped,reason="REASON",thread-id="ID",stopped-threads="STOPPED",core="CORE"'
- The target has stopped. The REASON field can have one of the
- following values:
-
- `breakpoint-hit'
- A breakpoint was reached.
-
- `watchpoint-trigger'
- A watchpoint was triggered.
-
- `read-watchpoint-trigger'
- A read watchpoint was triggered.
-
- `access-watchpoint-trigger'
- An access watchpoint was triggered.
-
- `function-finished'
- An -exec-finish or similar CLI command was accomplished.
-
- `location-reached'
- An -exec-until or similar CLI command was accomplished.
-
- `watchpoint-scope'
- A watchpoint has gone out of scope.
-
- `end-stepping-range'
- An -exec-next, -exec-next-instruction, -exec-step,
- -exec-step-instruction or similar CLI command was
- accomplished.
-
- `exited-signalled'
- The inferior exited because of a signal.
-
- `exited'
- The inferior exited.
-
- `exited-normally'
- The inferior exited normally.
-
- `signal-received'
- A signal was received by the inferior.
-
- The ID field identifies the thread that directly caused the stop -
- for example by hitting a breakpoint. Depending on whether all-stop
- mode is in effect (*note All-Stop Mode::), GDB may either stop all
- threads, or only the thread that directly triggered the stop. If
- all threads are stopped, the STOPPED field will have the value of
- `"all"'. Otherwise, the value of the STOPPED field will be a list
- of thread identifiers. Presently, this list will always include a
- single thread, but frontend should be prepared to see several
- threads in the list. The CORE field reports the processor core on
- which the stop event has happened. This field may be absent if
- such information is not available.
-
-`=thread-group-added,id="ID"'
-`=thread-group-removed,id="ID"'
- A thread group was either added or removed. The ID field contains
- the GDB identifier of the thread group. When a thread group is
- added, it generally might not be associated with a running
- process. When a thread group is removed, its id becomes invalid
- and cannot be used in any way.
-
-`=thread-group-started,id="ID",pid="PID"'
- A thread group became associated with a running program, either
- because the program was just started or the thread group was
- attached to a program. The ID field contains the GDB identifier
- of the thread group. The PID field contains process identifier,
- specific to the operating system.
-
-`=thread-group-exited,id="ID"[,exit-code="CODE"]'
- A thread group is no longer associated with a running program,
- either because the program has exited, or because it was detached
- from. The ID field contains the GDB identifier of the thread
- group. CODE is the exit code of the inferior; it exists only when
- the inferior exited with some code.
-
-`=thread-created,id="ID",group-id="GID"'
-`=thread-exited,id="ID",group-id="GID"'
- A thread either was created, or has exited. The ID field contains
- the GDB identifier of the thread. The GID field identifies the
- thread group this thread belongs to.
-
-`=thread-selected,id="ID"'
- Informs that the selected thread was changed as result of the last
- command. This notification is not emitted as result of
- `-thread-select' command but is emitted whenever an MI command
- that is not documented to change the selected thread actually
- changes it. In particular, invoking, directly or indirectly (via
- user-defined command), the CLI `thread' command, will generate
- this notification.
-
- We suggest that in response to this notification, front ends
- highlight the selected thread and cause subsequent commands to
- apply to that thread.
-
-`=library-loaded,...'
- Reports that a new library file was loaded by the program. This
- notification has 4 fields--ID, TARGET-NAME, HOST-NAME, and
- SYMBOLS-LOADED. The ID field is an opaque identifier of the
- library. For remote debugging case, TARGET-NAME and HOST-NAME
- fields give the name of the library file on the target, and on the
- host respectively. For native debugging, both those fields have
- the same value. The SYMBOLS-LOADED field is emitted only for
- backward compatibility and should not be relied on to convey any
- useful information. The THREAD-GROUP field, if present, specifies
- the id of the thread group in whose context the library was
- loaded. If the field is absent, it means the library was loaded
- in the context of all present thread groups.
-
-`=library-unloaded,...'
- Reports that a library was unloaded by the program. This
- notification has 3 fields--ID, TARGET-NAME and HOST-NAME with the
- same meaning as for the `=library-loaded' notification. The
- THREAD-GROUP field, if present, specifies the id of the thread
- group in whose context the library was unloaded. If the field is
- absent, it means the library was unloaded in the context of all
- present thread groups.
-
-
-
-File: gdb.info, Node: GDB/MI Frame Information, Next: GDB/MI Thread Information, Prev: GDB/MI Async Records, Up: GDB/MI Output Records
-
-27.5.4 GDB/MI Frame Information
--------------------------------
-
-Response from many MI commands includes an information about stack
-frame. This information is a tuple that may have the following fields:
-
-`level'
- The level of the stack frame. The innermost frame has the level of
- zero. This field is always present.
-
-`func'
- The name of the function corresponding to the frame. This field
- may be absent if GDB is unable to determine the function name.
-
-`addr'
- The code address for the frame. This field is always present.
-
-`file'
- The name of the source files that correspond to the frame's code
- address. This field may be absent.
-
-`line'
- The source line corresponding to the frames' code address. This
- field may be absent.
-
-`from'
- The name of the binary file (either executable or shared library)
- the corresponds to the frame's code address. This field may be
- absent.
-
-
-
-File: gdb.info, Node: GDB/MI Thread Information, Next: GDB/MI Ada Exception Information, Prev: GDB/MI Frame Information, Up: GDB/MI Output Records
-
-27.5.5 GDB/MI Thread Information
---------------------------------
-
-Whenever GDB has to report an information about a thread, it uses a
-tuple with the following fields:
-
-`id'
- The numeric id assigned to the thread by GDB. This field is
- always present.
-
-`target-id'
- Target-specific string identifying the thread. This field is
- always present.
-
-`details'
- Additional information about the thread provided by the target.
- It is supposed to be human-readable and not interpreted by the
- frontend. This field is optional.
-
-`state'
- Either `stopped' or `running', depending on whether the thread is
- presently running. This field is always present.
-
-`core'
- The value of this field is an integer number of the processor core
- the thread was last seen on. This field is optional.
-
-
-File: gdb.info, Node: GDB/MI Ada Exception Information, Prev: GDB/MI Thread Information, Up: GDB/MI Output Records
-
-27.5.6 GDB/MI Ada Exception Information
----------------------------------------
-
-Whenever a `*stopped' record is emitted because the program stopped
-after hitting an exception catchpoint (*note Set Catchpoints::), GDB
-provides the name of the exception that was raised via the
-`exception-name' field.
-
-
-File: gdb.info, Node: GDB/MI Simple Examples, Next: GDB/MI Command Description Format, Prev: GDB/MI Output Records, Up: GDB/MI
-
-27.6 Simple Examples of GDB/MI Interaction
-==========================================
-
-This subsection presents several simple examples of interaction using
-the GDB/MI interface. In these examples, `->' means that the following
-line is passed to GDB/MI as input, while `<-' means the output received
-from GDB/MI.
-
- Note the line breaks shown in the examples are here only for
-readability, they don't appear in the real output.
-
-Setting a Breakpoint
---------------------
-
-Setting a breakpoint generates synchronous output which contains
-detailed information of the breakpoint.
-
- -> -break-insert main
- <- ^done,bkpt={number="1",type="breakpoint",disp="keep",
- enabled="y",addr="0x08048564",func="main",file="myprog.c",
- fullname="/home/nickrob/myprog.c",line="68",times="0"}
- <- (gdb)
-
-Program Execution
------------------
-
-Program execution generates asynchronous records and MI gives the
-reason that execution stopped.
-
- -> -exec-run
- <- ^running
- <- (gdb)
- <- *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",thread-id="0",
- frame={addr="0x08048564",func="main",
- args=[{name="argc",value="1"},{name="argv",value="0xbfc4d4d4"}],
- file="myprog.c",fullname="/home/nickrob/myprog.c",line="68"}
- <- (gdb)
- -> -exec-continue
- <- ^running
- <- (gdb)
- <- *stopped,reason="exited-normally"
- <- (gdb)
-
-Quitting GDB
-------------
-
-Quitting GDB just prints the result class `^exit'.
-
- -> (gdb)
- <- -gdb-exit
- <- ^exit
-
- Please note that `^exit' is printed immediately, but it might take
-some time for GDB to actually exit. During that time, GDB performs
-necessary cleanups, including killing programs being debugged or
-disconnecting from debug hardware, so the frontend should wait till GDB
-exits and should only forcibly kill GDB if it fails to exit in
-reasonable time.
-
-A Bad Command
--------------
-
-Here's what happens if you pass a non-existent command:
-
- -> -rubbish
- <- ^error,msg="Undefined MI command: rubbish"
- <- (gdb)
-
-
-File: gdb.info, Node: GDB/MI Command Description Format, Next: GDB/MI Breakpoint Commands, Prev: GDB/MI Simple Examples, Up: GDB/MI
-
-27.7 GDB/MI Command Description Format
-======================================
-
-The remaining sections describe blocks of commands. Each block of
-commands is laid out in a fashion similar to this section.
-
-Motivation
-----------
-
-The motivation for this collection of commands.
-
-Introduction
-------------
-
-A brief introduction to this collection of commands as a whole.
-
-Commands
---------
-
-For each command in the block, the following is described:
-
-Synopsis
-........
-
- -command ARGS...
-
-Result
-......
-
-GDB Command
-...........
-
-The corresponding GDB CLI command(s), if any.
-
-Example
-.......
-
-Example(s) formatted for readability. Some of the described commands
-have not been implemented yet and these are labeled N.A. (not
-available).
-
-
-File: gdb.info, Node: GDB/MI Breakpoint Commands, Next: GDB/MI Program Context, Prev: GDB/MI Command Description Format, Up: GDB/MI
-
-27.8 GDB/MI Breakpoint Commands
-===============================
-
-This section documents GDB/MI commands for manipulating breakpoints.
-
-The `-break-after' Command
---------------------------
-
-Synopsis
-........
-
- -break-after NUMBER COUNT
-
- The breakpoint number NUMBER is not in effect until it has been hit
-COUNT times. To see how this is reflected in the output of the
-`-break-list' command, see the description of the `-break-list' command
-below.
-
-GDB Command
-...........
-
-The corresponding GDB command is `ignore'.
-
-Example
-.......
-
- (gdb)
- -break-insert main
- ^done,bkpt={number="1",type="breakpoint",disp="keep",
- enabled="y",addr="0x000100d0",func="main",file="hello.c",
- fullname="/home/foo/hello.c",line="5",times="0"}
- (gdb)
- -break-after 1 3
- ~
- ^done
- (gdb)
- -break-list
- ^done,BreakpointTable={nr_rows="1",nr_cols="6",
- hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
- {width="14",alignment="-1",col_name="type",colhdr="Type"},
- {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
- {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
- {width="10",alignment="-1",col_name="addr",colhdr="Address"},
- {width="40",alignment="2",col_name="what",colhdr="What"}],
- body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
- addr="0x000100d0",func="main",file="hello.c",fullname="/home/foo/hello.c",
- line="5",times="0",ignore="3"}]}
- (gdb)
-
-The `-break-commands' Command
------------------------------
-
-Synopsis
-........
-
- -break-commands NUMBER [ COMMAND1 ... COMMANDN ]
-
- Specifies the CLI commands that should be executed when breakpoint
-NUMBER is hit. The parameters COMMAND1 to COMMANDN are the commands.
-If no command is specified, any previously-set commands are cleared.
-*Note Break Commands::. Typical use of this functionality is tracing a
-program, that is, printing of values of some variables whenever
-breakpoint is hit and then continuing.
-
-GDB Command
-...........
-
-The corresponding GDB command is `commands'.
-
-Example
-.......
-
- (gdb)
- -break-insert main
- ^done,bkpt={number="1",type="breakpoint",disp="keep",
- enabled="y",addr="0x000100d0",func="main",file="hello.c",
- fullname="/home/foo/hello.c",line="5",times="0"}
- (gdb)
- -break-commands 1 "print v" "continue"
- ^done
- (gdb)
-
-The `-break-condition' Command
-------------------------------
-
-Synopsis
-........
-
- -break-condition NUMBER EXPR
-
- Breakpoint NUMBER will stop the program only if the condition in
-EXPR is true. The condition becomes part of the `-break-list' output
-(see the description of the `-break-list' command below).
-
-GDB Command
-...........
-
-The corresponding GDB command is `condition'.
-
-Example
-.......
-
- (gdb)
- -break-condition 1 1
- ^done
- (gdb)
- -break-list
- ^done,BreakpointTable={nr_rows="1",nr_cols="6",
- hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
- {width="14",alignment="-1",col_name="type",colhdr="Type"},
- {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
- {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
- {width="10",alignment="-1",col_name="addr",colhdr="Address"},
- {width="40",alignment="2",col_name="what",colhdr="What"}],
- body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
- addr="0x000100d0",func="main",file="hello.c",fullname="/home/foo/hello.c",
- line="5",cond="1",times="0",ignore="3"}]}
- (gdb)
-
-The `-break-delete' Command
----------------------------
-
-Synopsis
-........
-
- -break-delete ( BREAKPOINT )+
-
- Delete the breakpoint(s) whose number(s) are specified in the
-argument list. This is obviously reflected in the breakpoint list.
-
-GDB Command
-...........
-
-The corresponding GDB command is `delete'.
-
-Example
-.......
-
- (gdb)
- -break-delete 1
- ^done
- (gdb)
- -break-list
- ^done,BreakpointTable={nr_rows="0",nr_cols="6",
- hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
- {width="14",alignment="-1",col_name="type",colhdr="Type"},
- {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
- {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
- {width="10",alignment="-1",col_name="addr",colhdr="Address"},
- {width="40",alignment="2",col_name="what",colhdr="What"}],
- body=[]}
- (gdb)
-
-The `-break-disable' Command
-----------------------------
-
-Synopsis
-........
-
- -break-disable ( BREAKPOINT )+
-
- Disable the named BREAKPOINT(s). The field `enabled' in the break
-list is now set to `n' for the named BREAKPOINT(s).
-
-GDB Command
-...........
-
-The corresponding GDB command is `disable'.
-
-Example
-.......
-
- (gdb)
- -break-disable 2
- ^done
- (gdb)
- -break-list
- ^done,BreakpointTable={nr_rows="1",nr_cols="6",
- hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
- {width="14",alignment="-1",col_name="type",colhdr="Type"},
- {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
- {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
- {width="10",alignment="-1",col_name="addr",colhdr="Address"},
- {width="40",alignment="2",col_name="what",colhdr="What"}],
- body=[bkpt={number="2",type="breakpoint",disp="keep",enabled="n",
- addr="0x000100d0",func="main",file="hello.c",fullname="/home/foo/hello.c",
- line="5",times="0"}]}
- (gdb)
-
-The `-break-enable' Command
----------------------------
-
-Synopsis
-........
-
- -break-enable ( BREAKPOINT )+
-
- Enable (previously disabled) BREAKPOINT(s).
-
-GDB Command
-...........
-
-The corresponding GDB command is `enable'.
-
-Example
-.......
-
- (gdb)
- -break-enable 2
- ^done
- (gdb)
- -break-list
- ^done,BreakpointTable={nr_rows="1",nr_cols="6",
- hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
- {width="14",alignment="-1",col_name="type",colhdr="Type"},
- {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
- {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
- {width="10",alignment="-1",col_name="addr",colhdr="Address"},
- {width="40",alignment="2",col_name="what",colhdr="What"}],
- body=[bkpt={number="2",type="breakpoint",disp="keep",enabled="y",
- addr="0x000100d0",func="main",file="hello.c",fullname="/home/foo/hello.c",
- line="5",times="0"}]}
- (gdb)
-
-The `-break-info' Command
--------------------------
-
-Synopsis
-........
-
- -break-info BREAKPOINT
-
- Get information about a single breakpoint.
-
-GDB Command
-...........
-
-The corresponding GDB command is `info break BREAKPOINT'.
-
-Example
-.......
-
-N.A.
-
-The `-break-insert' Command
----------------------------
-
-Synopsis
-........
-
- -break-insert [ -t ] [ -h ] [ -f ] [ -d ] [ -a ]
- [ -c CONDITION ] [ -i IGNORE-COUNT ]
- [ -p THREAD ] [ LOCATION ]
-
-If specified, LOCATION, can be one of:
-
- * function
-
- * filename:linenum
-
- * filename:function
-
- * *address
-
- The possible optional parameters of this command are:
-
-`-t'
- Insert a temporary breakpoint.
-
-`-h'
- Insert a hardware breakpoint.
-
-`-c CONDITION'
- Make the breakpoint conditional on CONDITION.
-
-`-i IGNORE-COUNT'
- Initialize the IGNORE-COUNT.
-
-`-f'
- If LOCATION cannot be parsed (for example if it refers to unknown
- files or functions), create a pending breakpoint. Without this
- flag, GDB will report an error, and won't create a breakpoint, if
- LOCATION cannot be parsed.
-
-`-d'
- Create a disabled breakpoint.
-
-`-a'
- Create a tracepoint. *Note Tracepoints::. When this parameter is
- used together with `-h', a fast tracepoint is created.
-
-Result
-......
-
-The result is in the form:
-
- ^done,bkpt={number="NUMBER",type="TYPE",disp="del"|"keep",
- enabled="y"|"n",addr="HEX",func="FUNCNAME",file="FILENAME",
- fullname="FULL_FILENAME",line="LINENO",[thread="THREADNO,]
- times="TIMES"}
-
-where NUMBER is the GDB number for this breakpoint, FUNCNAME is the
-name of the function where the breakpoint was inserted, FILENAME is the
-name of the source file which contains this function, LINENO is the
-source line number within that file and TIMES the number of times that
-the breakpoint has been hit (always 0 for -break-insert but may be
-greater for -break-info or -break-list which use the same output).
-
- Note: this format is open to change.
-
-GDB Command
-...........
-
-The corresponding GDB commands are `break', `tbreak', `hbreak',
-`thbreak', and `rbreak'.
-
-Example
-.......
-
- (gdb)
- -break-insert main
- ^done,bkpt={number="1",addr="0x0001072c",file="recursive2.c",
- fullname="/home/foo/recursive2.c,line="4",times="0"}
- (gdb)
- -break-insert -t foo
- ^done,bkpt={number="2",addr="0x00010774",file="recursive2.c",
- fullname="/home/foo/recursive2.c,line="11",times="0"}
- (gdb)
- -break-list
- ^done,BreakpointTable={nr_rows="2",nr_cols="6",
- hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
- {width="14",alignment="-1",col_name="type",colhdr="Type"},
- {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
- {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
- {width="10",alignment="-1",col_name="addr",colhdr="Address"},
- {width="40",alignment="2",col_name="what",colhdr="What"}],
- body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
- addr="0x0001072c", func="main",file="recursive2.c",
- fullname="/home/foo/recursive2.c,"line="4",times="0"},
- bkpt={number="2",type="breakpoint",disp="del",enabled="y",
- addr="0x00010774",func="foo",file="recursive2.c",
- fullname="/home/foo/recursive2.c",line="11",times="0"}]}
- (gdb)
- -break-insert -r foo.*
- ~int foo(int, int);
- ^done,bkpt={number="3",addr="0x00010774",file="recursive2.c,
- "fullname="/home/foo/recursive2.c",line="11",times="0"}
- (gdb)
-
-The `-break-list' Command
--------------------------
-
-Synopsis
-........
-
- -break-list
-
- Displays the list of inserted breakpoints, showing the following
-fields:
-
-`Number'
- number of the breakpoint
-
-`Type'
- type of the breakpoint: `breakpoint' or `watchpoint'
-
-`Disposition'
- should the breakpoint be deleted or disabled when it is hit: `keep'
- or `nokeep'
-
-`Enabled'
- is the breakpoint enabled or no: `y' or `n'
-
-`Address'
- memory location at which the breakpoint is set
-
-`What'
- logical location of the breakpoint, expressed by function name,
- file name, line number
-
-`Times'
- number of times the breakpoint has been hit
-
- If there are no breakpoints or watchpoints, the `BreakpointTable'
-`body' field is an empty list.
-
-GDB Command
-...........
-
-The corresponding GDB command is `info break'.
-
-Example
-.......
-
- (gdb)
- -break-list
- ^done,BreakpointTable={nr_rows="2",nr_cols="6",
- hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
- {width="14",alignment="-1",col_name="type",colhdr="Type"},
- {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
- {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
- {width="10",alignment="-1",col_name="addr",colhdr="Address"},
- {width="40",alignment="2",col_name="what",colhdr="What"}],
- body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
- addr="0x000100d0",func="main",file="hello.c",line="5",times="0"},
- bkpt={number="2",type="breakpoint",disp="keep",enabled="y",
- addr="0x00010114",func="foo",file="hello.c",fullname="/home/foo/hello.c",
- line="13",times="0"}]}
- (gdb)
-
- Here's an example of the result when there are no breakpoints:
-
- (gdb)
- -break-list
- ^done,BreakpointTable={nr_rows="0",nr_cols="6",
- hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
- {width="14",alignment="-1",col_name="type",colhdr="Type"},
- {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
- {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
- {width="10",alignment="-1",col_name="addr",colhdr="Address"},
- {width="40",alignment="2",col_name="what",colhdr="What"}],
- body=[]}
- (gdb)
-
-The `-break-passcount' Command
-------------------------------
-
-Synopsis
-........
-
- -break-passcount TRACEPOINT-NUMBER PASSCOUNT
-
- Set the passcount for tracepoint TRACEPOINT-NUMBER to PASSCOUNT. If
-the breakpoint referred to by TRACEPOINT-NUMBER is not a tracepoint,
-error is emitted. This corresponds to CLI command `passcount'.
-
-The `-break-watch' Command
---------------------------
-
-Synopsis
-........
-
- -break-watch [ -a | -r ]
-
- Create a watchpoint. With the `-a' option it will create an
-"access" watchpoint, i.e., a watchpoint that triggers either on a read
-from or on a write to the memory location. With the `-r' option, the
-watchpoint created is a "read" watchpoint, i.e., it will trigger only
-when the memory location is accessed for reading. Without either of
-the options, the watchpoint created is a regular watchpoint, i.e., it
-will trigger when the memory location is accessed for writing. *Note
-Setting Watchpoints: Set Watchpoints.
-
- Note that `-break-list' will report a single list of watchpoints and
-breakpoints inserted.
-
-GDB Command
-...........
-
-The corresponding GDB commands are `watch', `awatch', and `rwatch'.
-
-Example
-.......
-
-Setting a watchpoint on a variable in the `main' function:
-
- (gdb)
- -break-watch x
- ^done,wpt={number="2",exp="x"}
- (gdb)
- -exec-continue
- ^running
- (gdb)
- *stopped,reason="watchpoint-trigger",wpt={number="2",exp="x"},
- value={old="-268439212",new="55"},
- frame={func="main",args=[],file="recursive2.c",
- fullname="/home/foo/bar/recursive2.c",line="5"}
- (gdb)
-
- Setting a watchpoint on a variable local to a function. GDB will
-stop the program execution twice: first for the variable changing
-value, then for the watchpoint going out of scope.
-
- (gdb)
- -break-watch C
- ^done,wpt={number="5",exp="C"}
- (gdb)
- -exec-continue
- ^running
- (gdb)
- *stopped,reason="watchpoint-trigger",
- wpt={number="5",exp="C"},value={old="-276895068",new="3"},
- frame={func="callee4",args=[],
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="13"}
- (gdb)
- -exec-continue
- ^running
- (gdb)
- *stopped,reason="watchpoint-scope",wpnum="5",
- frame={func="callee3",args=[{name="strarg",
- value="0x11940 \"A string argument.\""}],
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="18"}
- (gdb)
-
- Listing breakpoints and watchpoints, at different points in the
-program execution. Note that once the watchpoint goes out of scope, it
-is deleted.
-
- (gdb)
- -break-watch C
- ^done,wpt={number="2",exp="C"}
- (gdb)
- -break-list
- ^done,BreakpointTable={nr_rows="2",nr_cols="6",
- hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
- {width="14",alignment="-1",col_name="type",colhdr="Type"},
- {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
- {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
- {width="10",alignment="-1",col_name="addr",colhdr="Address"},
- {width="40",alignment="2",col_name="what",colhdr="What"}],
- body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
- addr="0x00010734",func="callee4",
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/devo/gdb/testsuite/gdb.mi/basics.c"line="8",times="1"},
- bkpt={number="2",type="watchpoint",disp="keep",
- enabled="y",addr="",what="C",times="0"}]}
- (gdb)
- -exec-continue
- ^running
- (gdb)
- *stopped,reason="watchpoint-trigger",wpt={number="2",exp="C"},
- value={old="-276895068",new="3"},
- frame={func="callee4",args=[],
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="13"}
- (gdb)
- -break-list
- ^done,BreakpointTable={nr_rows="2",nr_cols="6",
- hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
- {width="14",alignment="-1",col_name="type",colhdr="Type"},
- {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
- {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
- {width="10",alignment="-1",col_name="addr",colhdr="Address"},
- {width="40",alignment="2",col_name="what",colhdr="What"}],
- body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
- addr="0x00010734",func="callee4",
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/devo/gdb/testsuite/gdb.mi/basics.c",line="8",times="1"},
- bkpt={number="2",type="watchpoint",disp="keep",
- enabled="y",addr="",what="C",times="-5"}]}
- (gdb)
- -exec-continue
- ^running
- ^done,reason="watchpoint-scope",wpnum="2",
- frame={func="callee3",args=[{name="strarg",
- value="0x11940 \"A string argument.\""}],
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="18"}
- (gdb)
- -break-list
- ^done,BreakpointTable={nr_rows="1",nr_cols="6",
- hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
- {width="14",alignment="-1",col_name="type",colhdr="Type"},
- {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
- {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
- {width="10",alignment="-1",col_name="addr",colhdr="Address"},
- {width="40",alignment="2",col_name="what",colhdr="What"}],
- body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
- addr="0x00010734",func="callee4",
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/devo/gdb/testsuite/gdb.mi/basics.c",line="8",
- times="1"}]}
- (gdb)
-
-
-File: gdb.info, Node: GDB/MI Program Context, Next: GDB/MI Thread Commands, Prev: GDB/MI Breakpoint Commands, Up: GDB/MI
-
-27.9 GDB/MI Program Context
-============================
-
-The `-exec-arguments' Command
------------------------------
-
-Synopsis
-........
-
- -exec-arguments ARGS
-
- Set the inferior program arguments, to be used in the next
-`-exec-run'.
-
-GDB Command
-...........
-
-The corresponding GDB command is `set args'.
-
-Example
-.......
-
- (gdb)
- -exec-arguments -v word
- ^done
- (gdb)
-
-The `-environment-cd' Command
------------------------------
-
-Synopsis
-........
-
- -environment-cd PATHDIR
-
- Set GDB's working directory.
-
-GDB Command
-...........
-
-The corresponding GDB command is `cd'.
-
-Example
-.......
-
- (gdb)
- -environment-cd /kwikemart/marge/ezannoni/flathead-dev/devo/gdb
- ^done
- (gdb)
-
-The `-environment-directory' Command
-------------------------------------
-
-Synopsis
-........
-
- -environment-directory [ -r ] [ PATHDIR ]+
-
- Add directories PATHDIR to beginning of search path for source files.
-If the `-r' option is used, the search path is reset to the default
-search path. If directories PATHDIR are supplied in addition to the
-`-r' option, the search path is first reset and then addition occurs as
-normal. Multiple directories may be specified, separated by blanks.
-Specifying multiple directories in a single command results in the
-directories added to the beginning of the search path in the same order
-they were presented in the command. If blanks are needed as part of a
-directory name, double-quotes should be used around the name. In the
-command output, the path will show up separated by the system
-directory-separator character. The directory-separator character must
-not be used in any directory name. If no directories are specified,
-the current search path is displayed.
-
-GDB Command
-...........
-
-The corresponding GDB command is `dir'.
-
-Example
-.......
-
- (gdb)
- -environment-directory /kwikemart/marge/ezannoni/flathead-dev/devo/gdb
- ^done,source-path="/kwikemart/marge/ezannoni/flathead-dev/devo/gdb:$cdir:$cwd"
- (gdb)
- -environment-directory ""
- ^done,source-path="/kwikemart/marge/ezannoni/flathead-dev/devo/gdb:$cdir:$cwd"
- (gdb)
- -environment-directory -r /home/jjohnstn/src/gdb /usr/src
- ^done,source-path="/home/jjohnstn/src/gdb:/usr/src:$cdir:$cwd"
- (gdb)
- -environment-directory -r
- ^done,source-path="$cdir:$cwd"
- (gdb)
-
-The `-environment-path' Command
--------------------------------
-
-Synopsis
-........
-
- -environment-path [ -r ] [ PATHDIR ]+
-
- Add directories PATHDIR to beginning of search path for object files.
-If the `-r' option is used, the search path is reset to the original
-search path that existed at gdb start-up. If directories PATHDIR are
-supplied in addition to the `-r' option, the search path is first reset
-and then addition occurs as normal. Multiple directories may be
-specified, separated by blanks. Specifying multiple directories in a
-single command results in the directories added to the beginning of the
-search path in the same order they were presented in the command. If
-blanks are needed as part of a directory name, double-quotes should be
-used around the name. In the command output, the path will show up
-separated by the system directory-separator character. The
-directory-separator character must not be used in any directory name.
-If no directories are specified, the current path is displayed.
-
-GDB Command
-...........
-
-The corresponding GDB command is `path'.
-
-Example
-.......
-
- (gdb)
- -environment-path
- ^done,path="/usr/bin"
- (gdb)
- -environment-path /kwikemart/marge/ezannoni/flathead-dev/ppc-eabi/gdb /bin
- ^done,path="/kwikemart/marge/ezannoni/flathead-dev/ppc-eabi/gdb:/bin:/usr/bin"
- (gdb)
- -environment-path -r /usr/local/bin
- ^done,path="/usr/local/bin:/usr/bin"
- (gdb)
-
-The `-environment-pwd' Command
-------------------------------
-
-Synopsis
-........
-
- -environment-pwd
-
- Show the current working directory.
-
-GDB Command
-...........
-
-The corresponding GDB command is `pwd'.
-
-Example
-.......
-
- (gdb)
- -environment-pwd
- ^done,cwd="/kwikemart/marge/ezannoni/flathead-dev/devo/gdb"
- (gdb)
-
-
-File: gdb.info, Node: GDB/MI Thread Commands, Next: GDB/MI Program Execution, Prev: GDB/MI Program Context, Up: GDB/MI
-
-27.10 GDB/MI Thread Commands
-============================
-
-The `-thread-info' Command
---------------------------
-
-Synopsis
-........
-
- -thread-info [ THREAD-ID ]
-
- Reports information about either a specific thread, if the THREAD-ID
-parameter is present, or about all threads. When printing information
-about all threads, also reports the current thread.
-
-GDB Command
-...........
-
-The `info thread' command prints the same information about all threads.
-
-Result
-......
-
-The result is a list of threads. The following attributes are defined
-for a given thread:
-
-`current'
- This field exists only for the current thread. It has the value
- `*'.
-
-`id'
- The identifier that GDB uses to refer to the thread.
-
-`target-id'
- The identifier that the target uses to refer to the thread.
-
-`details'
- Extra information about the thread, in a target-specific format.
- This field is optional.
-
-`name'
- The name of the thread. If the user specified a name using the
- `thread name' command, then this name is given. Otherwise, if GDB
- can extract the thread name from the target, then that name is
- given. If GDB cannot find the thread name, then this field is
- omitted.
-
-`frame'
- The stack frame currently executing in the thread.
-
-`state'
- The thread's state. The `state' field may have the following
- values:
-
- `stopped'
- The thread is stopped. Frame information is available for
- stopped threads.
-
- `running'
- The thread is running. There's no frame information for
- running threads.
-
-
-`core'
- If GDB can find the CPU core on which this thread is running, then
- this field is the core identifier. This field is optional.
-
-
-Example
-.......
-
- -thread-info
- ^done,threads=[
- {id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",
- frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",
- args=[]},state="running"},
- {id="1",target-id="Thread 0xb7e156b0 (LWP 21254)",
- frame={level="0",addr="0x0804891f",func="foo",
- args=[{name="i",value="10"}],
- file="/tmp/a.c",fullname="/tmp/a.c",line="158"},
- state="running"}],
- current-thread-id="1"
- (gdb)
-
-The `-thread-list-ids' Command
-------------------------------
-
-Synopsis
-........
-
- -thread-list-ids
-
- Produces a list of the currently known GDB thread ids. At the end
-of the list it also prints the total number of such threads.
-
- This command is retained for historical reasons, the `-thread-info'
-command should be used instead.
-
-GDB Command
-...........
-
-Part of `info threads' supplies the same information.
-
-Example
-.......
-
- (gdb)
- -thread-list-ids
- ^done,thread-ids={thread-id="3",thread-id="2",thread-id="1"},
- current-thread-id="1",number-of-threads="3"
- (gdb)
-
-The `-thread-select' Command
-----------------------------
-
-Synopsis
-........
-
- -thread-select THREADNUM
-
- Make THREADNUM the current thread. It prints the number of the new
-current thread, and the topmost frame for that thread.
-
- This command is deprecated in favor of explicitly using the
-`--thread' option to each command.
-
-GDB Command
-...........
-
-The corresponding GDB command is `thread'.
-
-Example
-.......
-
- (gdb)
- -exec-next
- ^running
- (gdb)
- *stopped,reason="end-stepping-range",thread-id="2",line="187",
- file="../../../devo/gdb/testsuite/gdb.threads/linux-dp.c"
- (gdb)
- -thread-list-ids
- ^done,
- thread-ids={thread-id="3",thread-id="2",thread-id="1"},
- number-of-threads="3"
- (gdb)
- -thread-select 3
- ^done,new-thread-id="3",
- frame={level="0",func="vprintf",
- args=[{name="format",value="0x8048e9c \"%*s%c %d %c\\n\""},
- {name="arg",value="0x2"}],file="vprintf.c",line="31"}
- (gdb)
-
-
-File: gdb.info, Node: GDB/MI Program Execution, Next: GDB/MI Stack Manipulation, Prev: GDB/MI Thread Commands, Up: GDB/MI
-
-27.11 GDB/MI Program Execution
-==============================
-
-These are the asynchronous commands which generate the out-of-band
-record `*stopped'. Currently GDB only really executes asynchronously
-with remote targets and this interaction is mimicked in other cases.
-
-The `-exec-continue' Command
-----------------------------
-
-Synopsis
-........
-
- -exec-continue [--reverse] [--all|--thread-group N]
-
- Resumes the execution of the inferior program, which will continue
-to execute until it reaches a debugger stop event. If the `--reverse'
-option is specified, execution resumes in reverse until it reaches a
-stop event. Stop events may include
- * breakpoints or watchpoints
-
- * signals or exceptions
-
- * the end of the process (or its beginning under `--reverse')
-
- * the end or beginning of a replay log if one is being used.
- In all-stop mode (*note All-Stop Mode::), may resume only one
-thread, or all threads, depending on the value of the
-`scheduler-locking' variable. If `--all' is specified, all threads (in
-all inferiors) will be resumed. The `--all' option is ignored in
-all-stop mode. If the `--thread-group' options is specified, then all
-threads in that thread group are resumed.
-
-GDB Command
-...........
-
-The corresponding GDB corresponding is `continue'.
-
-Example
-.......
-
- -exec-continue
- ^running
- (gdb)
- @Hello world
- *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",frame={
- func="foo",args=[],file="hello.c",fullname="/home/foo/bar/hello.c",
- line="13"}
- (gdb)
-
-The `-exec-finish' Command
---------------------------
-
-Synopsis
-........
-
- -exec-finish [--reverse]
-
- Resumes the execution of the inferior program until the current
-function is exited. Displays the results returned by the function. If
-the `--reverse' option is specified, resumes the reverse execution of
-the inferior program until the point where current function was called.
-
-GDB Command
-...........
-
-The corresponding GDB command is `finish'.
-
-Example
-.......
-
-Function returning `void'.
-
- -exec-finish
- ^running
- (gdb)
- @hello from foo
- *stopped,reason="function-finished",frame={func="main",args=[],
- file="hello.c",fullname="/home/foo/bar/hello.c",line="7"}
- (gdb)
-
- Function returning other than `void'. The name of the internal GDB
-variable storing the result is printed, together with the value itself.
-
- -exec-finish
- ^running
- (gdb)
- *stopped,reason="function-finished",frame={addr="0x000107b0",func="foo",
- args=[{name="a",value="1"],{name="b",value="9"}},
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- gdb-result-var="$1",return-value="0"
- (gdb)
-
-The `-exec-interrupt' Command
------------------------------
-
-Synopsis
-........
-
- -exec-interrupt [--all|--thread-group N]
-
- Interrupts the background execution of the target. Note how the
-token associated with the stop message is the one for the execution
-command that has been interrupted. The token for the interrupt itself
-only appears in the `^done' output. If the user is trying to interrupt
-a non-running program, an error message will be printed.
-
- Note that when asynchronous execution is enabled, this command is
-asynchronous just like other execution commands. That is, first the
-`^done' response will be printed, and the target stop will be reported
-after that using the `*stopped' notification.
-
- In non-stop mode, only the context thread is interrupted by default.
-All threads (in all inferiors) will be interrupted if the `--all'
-option is specified. If the `--thread-group' option is specified, all
-threads in that group will be interrupted.
-
-GDB Command
-...........
-
-The corresponding GDB command is `interrupt'.
-
-Example
-.......
-
- (gdb)
- 111-exec-continue
- 111^running
-
- (gdb)
- 222-exec-interrupt
- 222^done
- (gdb)
- 111*stopped,signal-name="SIGINT",signal-meaning="Interrupt",
- frame={addr="0x00010140",func="foo",args=[],file="try.c",
- fullname="/home/foo/bar/try.c",line="13"}
- (gdb)
-
- (gdb)
- -exec-interrupt
- ^error,msg="mi_cmd_exec_interrupt: Inferior not executing."
- (gdb)
-
-The `-exec-jump' Command
-------------------------
-
-Synopsis
-........
-
- -exec-jump LOCATION
-
- Resumes execution of the inferior program at the location specified
-by parameter. *Note Specify Location::, for a description of the
-different forms of LOCATION.
-
-GDB Command
-...........
-
-The corresponding GDB command is `jump'.
-
-Example
-.......
-
- -exec-jump foo.c:10
- *running,thread-id="all"
- ^running
-
-The `-exec-next' Command
-------------------------
-
-Synopsis
-........
-
- -exec-next [--reverse]
-
- Resumes execution of the inferior program, stopping when the
-beginning of the next source line is reached.
-
- If the `--reverse' option is specified, resumes reverse execution of
-the inferior program, stopping at the beginning of the previous source
-line. If you issue this command on the first line of a function, it
-will take you back to the caller of that function, to the source line
-where the function was called.
-
-GDB Command
-...........
-
-The corresponding GDB command is `next'.
-
-Example
-.......
-
- -exec-next
- ^running
- (gdb)
- *stopped,reason="end-stepping-range",line="8",file="hello.c"
- (gdb)
-
-The `-exec-next-instruction' Command
-------------------------------------
-
-Synopsis
-........
-
- -exec-next-instruction [--reverse]
-
- Executes one machine instruction. If the instruction is a function
-call, continues until the function returns. If the program stops at an
-instruction in the middle of a source line, the address will be printed
-as well.
-
- If the `--reverse' option is specified, resumes reverse execution of
-the inferior program, stopping at the previous instruction. If the
-previously executed instruction was a return from another function, it
-will continue to execute in reverse until the call to that function
-(from the current stack frame) is reached.
-
-GDB Command
-...........
-
-The corresponding GDB command is `nexti'.
-
-Example
-.......
-
- (gdb)
- -exec-next-instruction
- ^running
-
- (gdb)
- *stopped,reason="end-stepping-range",
- addr="0x000100d4",line="5",file="hello.c"
- (gdb)
-
-The `-exec-return' Command
---------------------------
-
-Synopsis
-........
-
- -exec-return
-
- Makes current function return immediately. Doesn't execute the
-inferior. Displays the new current frame.
-
-GDB Command
-...........
-
-The corresponding GDB command is `return'.
-
-Example
-.......
-
- (gdb)
- 200-break-insert callee4
- 200^done,bkpt={number="1",addr="0x00010734",
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="8"}
- (gdb)
- 000-exec-run
- 000^running
- (gdb)
- 000*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",
- frame={func="callee4",args=[],
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="8"}
- (gdb)
- 205-break-delete
- 205^done
- (gdb)
- 111-exec-return
- 111^done,frame={level="0",func="callee3",
- args=[{name="strarg",
- value="0x11940 \"A string argument.\""}],
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="18"}
- (gdb)
-
-The `-exec-run' Command
------------------------
-
-Synopsis
-........
-
- -exec-run [--all | --thread-group N]
-
- Starts execution of the inferior from the beginning. The inferior
-executes until either a breakpoint is encountered or the program exits.
-In the latter case the output will include an exit code, if the program
-has exited exceptionally.
-
- When no option is specified, the current inferior is started. If the
-`--thread-group' option is specified, it should refer to a thread group
-of type `process', and that thread group will be started. If the
-`--all' option is specified, then all inferiors will be started.
-
-GDB Command
-...........
-
-The corresponding GDB command is `run'.
-
-Examples
-........
-
- (gdb)
- -break-insert main
- ^done,bkpt={number="1",addr="0x0001072c",file="recursive2.c",line="4"}
- (gdb)
- -exec-run
- ^running
- (gdb)
- *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",
- frame={func="main",args=[],file="recursive2.c",
- fullname="/home/foo/bar/recursive2.c",line="4"}
- (gdb)
-
-Program exited normally:
-
- (gdb)
- -exec-run
- ^running
- (gdb)
- x = 55
- *stopped,reason="exited-normally"
- (gdb)
-
-Program exited exceptionally:
-
- (gdb)
- -exec-run
- ^running
- (gdb)
- x = 55
- *stopped,reason="exited",exit-code="01"
- (gdb)
-
- Another way the program can terminate is if it receives a signal
-such as `SIGINT'. In this case, GDB/MI displays this:
-
- (gdb)
- *stopped,reason="exited-signalled",signal-name="SIGINT",
- signal-meaning="Interrupt"
-
-The `-exec-step' Command
-------------------------
-
-Synopsis
-........
-
- -exec-step [--reverse]
-
- Resumes execution of the inferior program, stopping when the
-beginning of the next source line is reached, if the next source line
-is not a function call. If it is, stop at the first instruction of the
-called function. If the `--reverse' option is specified, resumes
-reverse execution of the inferior program, stopping at the beginning of
-the previously executed source line.
-
-GDB Command
-...........
-
-The corresponding GDB command is `step'.
-
-Example
-.......
-
-Stepping into a function:
-
- -exec-step
- ^running
- (gdb)
- *stopped,reason="end-stepping-range",
- frame={func="foo",args=[{name="a",value="10"},
- {name="b",value="0"}],file="recursive2.c",
- fullname="/home/foo/bar/recursive2.c",line="11"}
- (gdb)
-
- Regular stepping:
-
- -exec-step
- ^running
- (gdb)
- *stopped,reason="end-stepping-range",line="14",file="recursive2.c"
- (gdb)
-
-The `-exec-step-instruction' Command
-------------------------------------
-
-Synopsis
-........
-
- -exec-step-instruction [--reverse]
-
- Resumes the inferior which executes one machine instruction. If the
-`--reverse' option is specified, resumes reverse execution of the
-inferior program, stopping at the previously executed instruction. The
-output, once GDB has stopped, will vary depending on whether we have
-stopped in the middle of a source line or not. In the former case, the
-address at which the program stopped will be printed as well.
-
-GDB Command
-...........
-
-The corresponding GDB command is `stepi'.
-
-Example
-.......
-
- (gdb)
- -exec-step-instruction
- ^running
-
- (gdb)
- *stopped,reason="end-stepping-range",
- frame={func="foo",args=[],file="try.c",
- fullname="/home/foo/bar/try.c",line="10"}
- (gdb)
- -exec-step-instruction
- ^running
-
- (gdb)
- *stopped,reason="end-stepping-range",
- frame={addr="0x000100f4",func="foo",args=[],file="try.c",
- fullname="/home/foo/bar/try.c",line="10"}
- (gdb)
-
-The `-exec-until' Command
--------------------------
-
-Synopsis
-........
-
- -exec-until [ LOCATION ]
-
- Executes the inferior until the LOCATION specified in the argument
-is reached. If there is no argument, the inferior executes until a
-source line greater than the current one is reached. The reason for
-stopping in this case will be `location-reached'.
-
-GDB Command
-...........
-
-The corresponding GDB command is `until'.
-
-Example
-.......
-
- (gdb)
- -exec-until recursive2.c:6
- ^running
- (gdb)
- x = 55
- *stopped,reason="location-reached",frame={func="main",args=[],
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="6"}
- (gdb)
-
-
-File: gdb.info, Node: GDB/MI Stack Manipulation, Next: GDB/MI Variable Objects, Prev: GDB/MI Program Execution, Up: GDB/MI
-
-27.12 GDB/MI Stack Manipulation Commands
-========================================
-
-The `-stack-info-frame' Command
--------------------------------
-
-Synopsis
-........
-
- -stack-info-frame
-
- Get info on the selected frame.
-
-GDB Command
-...........
-
-The corresponding GDB command is `info frame' or `frame' (without
-arguments).
-
-Example
-.......
-
- (gdb)
- -stack-info-frame
- ^done,frame={level="1",addr="0x0001076c",func="callee3",
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="17"}
- (gdb)
-
-The `-stack-info-depth' Command
--------------------------------
-
-Synopsis
-........
-
- -stack-info-depth [ MAX-DEPTH ]
-
- Return the depth of the stack. If the integer argument MAX-DEPTH is
-specified, do not count beyond MAX-DEPTH frames.
-
-GDB Command
-...........
-
-There's no equivalent GDB command.
-
-Example
-.......
-
-For a stack with frame levels 0 through 11:
-
- (gdb)
- -stack-info-depth
- ^done,depth="12"
- (gdb)
- -stack-info-depth 4
- ^done,depth="4"
- (gdb)
- -stack-info-depth 12
- ^done,depth="12"
- (gdb)
- -stack-info-depth 11
- ^done,depth="11"
- (gdb)
- -stack-info-depth 13
- ^done,depth="12"
- (gdb)
-
-The `-stack-list-arguments' Command
------------------------------------
-
-Synopsis
-........
-
- -stack-list-arguments PRINT-VALUES
- [ LOW-FRAME HIGH-FRAME ]
-
- Display a list of the arguments for the frames between LOW-FRAME and
-HIGH-FRAME (inclusive). If LOW-FRAME and HIGH-FRAME are not provided,
-list the arguments for the whole call stack. If the two arguments are
-equal, show the single frame at the corresponding level. It is an
-error if LOW-FRAME is larger than the actual number of frames. On the
-other hand, HIGH-FRAME may be larger than the actual number of frames,
-in which case only existing frames will be returned.
-
- If PRINT-VALUES is 0 or `--no-values', print only the names of the
-variables; if it is 1 or `--all-values', print also their values; and
-if it is 2 or `--simple-values', print the name, type and value for
-simple data types, and the name and type for arrays, structures and
-unions.
-
- Use of this command to obtain arguments in a single frame is
-deprecated in favor of the `-stack-list-variables' command.
-
-GDB Command
-...........
-
-GDB does not have an equivalent command. `gdbtk' has a `gdb_get_args'
-command which partially overlaps with the functionality of
-`-stack-list-arguments'.
-
-Example
-.......
-
- (gdb)
- -stack-list-frames
- ^done,
- stack=[
- frame={level="0",addr="0x00010734",func="callee4",
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="8"},
- frame={level="1",addr="0x0001076c",func="callee3",
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="17"},
- frame={level="2",addr="0x0001078c",func="callee2",
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="22"},
- frame={level="3",addr="0x000107b4",func="callee1",
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="27"},
- frame={level="4",addr="0x000107e0",func="main",
- file="../../../devo/gdb/testsuite/gdb.mi/basics.c",
- fullname="/home/foo/bar/devo/gdb/testsuite/gdb.mi/basics.c",line="32"}]
- (gdb)
- -stack-list-arguments 0
- ^done,
- stack-args=[
- frame={level="0",args=[]},
- frame={level="1",args=[name="strarg"]},
- frame={level="2",args=[name="intarg",name="strarg"]},
- frame={level="3",args=[name="intarg",name="strarg",name="fltarg"]},
- frame={level="4",args=[]}]
- (gdb)
- -stack-list-arguments 1
- ^done,
- stack-args=[
- frame={level="0",args=[]},
- frame={level="1",
- args=[{name="strarg",value="0x11940 \"A string argument.\""}]},
- frame={level="2",args=[
- {name="intarg",value="2"},
- {name="strarg",value="0x11940 \"A string argument.\""}]},
- {frame={level="3",args=[
- {name="intarg",value="2"},
- {name="strarg",value="0x11940 \"A string argument.\""},
- {name="fltarg",value="3.5"}]},
- frame={level="4",args=[]}]
- (gdb)
- -stack-list-arguments 0 2 2
- ^done,stack-args=[frame={level="2",args=[name="intarg",name="strarg"]}]
- (gdb)
- -stack-list-arguments 1 2 2
- ^done,stack-args=[frame={level="2",
- args=[{name="intarg",value="2"},
- {name="strarg",value="0x11940 \"A string argument.\""}]}]
- (gdb)
-
-The `-stack-list-frames' Command
---------------------------------
-
-Synopsis
-........
-
- -stack-list-frames [ LOW-FRAME HIGH-FRAME ]
-
- List the frames currently on the stack. For each frame it displays
-the following info:
-
-`LEVEL'
- The frame number, 0 being the topmost frame, i.e., the innermost
- function.
-
-`ADDR'
- The `$pc' value for that frame.
-
-`FUNC'
- Function name.
-
-`FILE'
- File name of the source file where the function lives.
-
-`FULLNAME'
- The full file name of the source file where the function lives.
-
-`LINE'
- Line number corresponding to the `$pc'.
-
-`FROM'
- The shared library where this function is defined. This is only
- given if the frame's function is not known.
-
- If invoked without arguments, this command prints a backtrace for the
-whole stack. If given two integer arguments, it shows the frames whose
-levels are between the two arguments (inclusive). If the two arguments
-are equal, it shows the single frame at the corresponding level. It is
-an error if LOW-FRAME is larger than the actual number of frames. On
-the other hand, HIGH-FRAME may be larger than the actual number of
-frames, in which case only existing frames will be returned.
-
-GDB Command
-...........
-
-The corresponding GDB commands are `backtrace' and `where'.
-
-Example
-.......
-
-Full stack backtrace:
-
- (gdb)
- -stack-list-frames
- ^done,stack=
- [frame={level="0",addr="0x0001076c",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="11"},
- frame={level="1",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="2",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="3",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="4",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="5",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="6",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="7",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="8",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="9",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="10",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="11",addr="0x00010738",func="main",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="4"}]
- (gdb)
-
- Show frames between LOW_FRAME and HIGH_FRAME:
-
- (gdb)
- -stack-list-frames 3 5
- ^done,stack=
- [frame={level="3",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="4",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"},
- frame={level="5",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}]
- (gdb)
-
- Show a single frame:
-
- (gdb)
- -stack-list-frames 3 3
- ^done,stack=
- [frame={level="3",addr="0x000107a4",func="foo",
- file="recursive2.c",fullname="/home/foo/bar/recursive2.c",line="14"}]
- (gdb)
-
-The `-stack-list-locals' Command
---------------------------------
-
-Synopsis
-........
-
- -stack-list-locals PRINT-VALUES
-
- Display the local variable names for the selected frame. If
-PRINT-VALUES is 0 or `--no-values', print only the names of the
-variables; if it is 1 or `--all-values', print also their values; and
-if it is 2 or `--simple-values', print the name, type and value for
-simple data types, and the name and type for arrays, structures and
-unions. In this last case, a frontend can immediately display the
-value of simple data types and create variable objects for other data
-types when the user wishes to explore their values in more detail.
-
- This command is deprecated in favor of the `-stack-list-variables'
-command.
-
-GDB Command
-...........
-
-`info locals' in GDB, `gdb_get_locals' in `gdbtk'.
-
-Example
-.......
-
- (gdb)
- -stack-list-locals 0
- ^done,locals=[name="A",name="B",name="C"]
- (gdb)
- -stack-list-locals --all-values
- ^done,locals=[{name="A",value="1"},{name="B",value="2"},
- {name="C",value="{1, 2, 3}"}]
- -stack-list-locals --simple-values
- ^done,locals=[{name="A",type="int",value="1"},
- {name="B",type="int",value="2"},{name="C",type="int [3]"}]
- (gdb)
-
-The `-stack-list-variables' Command
------------------------------------
-
-Synopsis
-........
-
- -stack-list-variables PRINT-VALUES
-
- Display the names of local variables and function arguments for the
-selected frame. If PRINT-VALUES is 0 or `--no-values', print only the
-names of the variables; if it is 1 or `--all-values', print also their
-values; and if it is 2 or `--simple-values', print the name, type and
-value for simple data types, and the name and type for arrays,
-structures and unions.
-
-Example
-.......
-
- (gdb)
- -stack-list-variables --thread 1 --frame 0 --all-values
- ^done,variables=[{name="x",value="11"},{name="s",value="{a = 1, b = 2}"}]
- (gdb)
-
-The `-stack-select-frame' Command
----------------------------------
-
-Synopsis
-........
-
- -stack-select-frame FRAMENUM
-
- Change the selected frame. Select a different frame FRAMENUM on the
-stack.
-
- This command in deprecated in favor of passing the `--frame' option
-to every command.
-
-GDB Command
-...........
-
-The corresponding GDB commands are `frame', `up', `down',
-`select-frame', `up-silent', and `down-silent'.
-
-Example
-.......
-
- (gdb)
- -stack-select-frame 2
- ^done
- (gdb)
-
-
-File: gdb.info, Node: GDB/MI Variable Objects, Next: GDB/MI Data Manipulation, Prev: GDB/MI Stack Manipulation, Up: GDB/MI
-
-27.13 GDB/MI Variable Objects
-=============================
-
-Introduction to Variable Objects
---------------------------------
-
-Variable objects are "object-oriented" MI interface for examining and
-changing values of expressions. Unlike some other MI interfaces that
-work with expressions, variable objects are specifically designed for
-simple and efficient presentation in the frontend. A variable object
-is identified by string name. When a variable object is created, the
-frontend specifies the expression for that variable object. The
-expression can be a simple variable, or it can be an arbitrary complex
-expression, and can even involve CPU registers. After creating a
-variable object, the frontend can invoke other variable object
-operations--for example to obtain or change the value of a variable
-object, or to change display format.
-
- Variable objects have hierarchical tree structure. Any variable
-object that corresponds to a composite type, such as structure in C, has
-a number of child variable objects, for example corresponding to each
-element of a structure. A child variable object can itself have
-children, recursively. Recursion ends when we reach leaf variable
-objects, which always have built-in types. Child variable objects are
-created only by explicit request, so if a frontend is not interested in
-the children of a particular variable object, no child will be created.
-
- For a leaf variable object it is possible to obtain its value as a
-string, or set the value from a string. String value can be also
-obtained for a non-leaf variable object, but it's generally a string
-that only indicates the type of the object, and does not list its
-contents. Assignment to a non-leaf variable object is not allowed.
-
- A frontend does not need to read the values of all variable objects
-each time the program stops. Instead, MI provides an update command
-that lists all variable objects whose values has changed since the last
-update operation. This considerably reduces the amount of data that
-must be transferred to the frontend. As noted above, children variable
-objects are created on demand, and only leaf variable objects have a
-real value. As result, gdb will read target memory only for leaf
-variables that frontend has created.
-
- The automatic update is not always desirable. For example, a
-frontend might want to keep a value of some expression for future
-reference, and never update it. For another example, fetching memory
-is relatively slow for embedded targets, so a frontend might want to
-disable automatic update for the variables that are either not visible
-on the screen, or "closed". This is possible using so called "frozen
-variable objects". Such variable objects are never implicitly updated.
-
- Variable objects can be either "fixed" or "floating". For the fixed
-variable object, the expression is parsed when the variable object is
-created, including associating identifiers to specific variables. The
-meaning of expression never changes. For a floating variable object
-the values of variables whose names appear in the expressions are
-re-evaluated every time in the context of the current frame. Consider
-this example:
-
- void do_work(...)
- {
- struct work_state state;
-
- if (...)
- do_work(...);
- }
-
- If a fixed variable object for the `state' variable is created in
-this function, and we enter the recursive call, the the variable object
-will report the value of `state' in the top-level `do_work' invocation.
-On the other hand, a floating variable object will report the value of
-`state' in the current frame.
-
- If an expression specified when creating a fixed variable object
-refers to a local variable, the variable object becomes bound to the
-thread and frame in which the variable object is created. When such
-variable object is updated, GDB makes sure that the thread/frame
-combination the variable object is bound to still exists, and
-re-evaluates the variable object in context of that thread/frame.
-
- The following is the complete set of GDB/MI operations defined to
-access this functionality:
-
-*Operation* *Description*
-`-enable-pretty-printing' enable Python-based pretty-printing
-`-var-create' create a variable object
-`-var-delete' delete the variable object and/or its
- children
-`-var-set-format' set the display format of this variable
-`-var-show-format' show the display format of this variable
-`-var-info-num-children' tells how many children this object has
-`-var-list-children' return a list of the object's children
-`-var-info-type' show the type of this variable object
-`-var-info-expression' print parent-relative expression that this
- variable object represents
-`-var-info-path-expression' print full expression that this variable
- object represents
-`-var-show-attributes' is this variable editable? does it exist
- here?
-`-var-evaluate-expression' get the value of this variable
-`-var-assign' set the value of this variable
-`-var-update' update the variable and its children
-`-var-set-frozen' set frozeness attribute
-`-var-set-update-range' set range of children to display on update
-
- In the next subsection we describe each operation in detail and
-suggest how it can be used.
-
-Description And Use of Operations on Variable Objects
------------------------------------------------------
-
-The `-enable-pretty-printing' Command
--------------------------------------
-
- -enable-pretty-printing
-
- GDB allows Python-based visualizers to affect the output of the MI
-variable object commands. However, because there was no way to
-implement this in a fully backward-compatible way, a front end must
-request that this functionality be enabled.
-
- Once enabled, this feature cannot be disabled.
-
- Note that if Python support has not been compiled into GDB, this
-command will still succeed (and do nothing).
-
- This feature is currently (as of GDB 7.0) experimental, and may work
-differently in future versions of GDB.
-
-The `-var-create' Command
--------------------------
-
-Synopsis
-........
-
- -var-create {NAME | "-"}
- {FRAME-ADDR | "*" | "@"} EXPRESSION
-
- This operation creates a variable object, which allows the
-monitoring of a variable, the result of an expression, a memory cell or
-a CPU register.
-
- The NAME parameter is the string by which the object can be
-referenced. It must be unique. If `-' is specified, the varobj system
-will generate a string "varNNNNNN" automatically. It will be unique
-provided that one does not specify NAME of that format. The command
-fails if a duplicate name is found.
-
- The frame under which the expression should be evaluated can be
-specified by FRAME-ADDR. A `*' indicates that the current frame should
-be used. A `@' indicates that a floating variable object must be
-created.
-
- EXPRESSION is any expression valid on the current language set (must
-not begin with a `*'), or one of the following:
-
- * `*ADDR', where ADDR is the address of a memory cell
-
- * `*ADDR-ADDR' -- a memory address range (TBD)
-
- * `$REGNAME' -- a CPU register name
-
- A varobj's contents may be provided by a Python-based
-pretty-printer. In this case the varobj is known as a "dynamic
-varobj". Dynamic varobjs have slightly different semantics in some
-cases. If the `-enable-pretty-printing' command is not sent, then GDB
-will never create a dynamic varobj. This ensures backward
-compatibility for existing clients.
-
-Result
-......
-
-This operation returns attributes of the newly-created varobj. These
-are:
-
-`name'
- The name of the varobj.
-
-`numchild'
- The number of children of the varobj. This number is not
- necessarily reliable for a dynamic varobj. Instead, you must
- examine the `has_more' attribute.
-
-`value'
- The varobj's scalar value. For a varobj whose type is some sort of
- aggregate (e.g., a `struct'), or for a dynamic varobj, this value
- will not be interesting.
-
-`type'
- The varobj's type. This is a string representation of the type, as
- would be printed by the GDB CLI.
-
-`thread-id'
- If a variable object is bound to a specific thread, then this is
- the thread's identifier.
-
-`has_more'
- For a dynamic varobj, this indicates whether there appear to be any
- children available. For a non-dynamic varobj, this will be 0.
-
-`dynamic'
- This attribute will be present and have the value `1' if the
- varobj is a dynamic varobj. If the varobj is not a dynamic varobj,
- then this attribute will not be present.
-
-`displayhint'
- A dynamic varobj can supply a display hint to the front end. The
- value comes directly from the Python pretty-printer object's
- `display_hint' method. *Note Pretty Printing API::.
-
- Typical output will look like this:
-
- name="NAME",numchild="N",type="TYPE",thread-id="M",
- has_more="HAS_MORE"
-
-The `-var-delete' Command
--------------------------
-
-Synopsis
-........
-
- -var-delete [ -c ] NAME
-
- Deletes a previously created variable object and all of its children.
-With the `-c' option, just deletes the children.
-
- Returns an error if the object NAME is not found.
-
-The `-var-set-format' Command
------------------------------
-
-Synopsis
-........
-
- -var-set-format NAME FORMAT-SPEC
-
- Sets the output format for the value of the object NAME to be
-FORMAT-SPEC.
-
- The syntax for the FORMAT-SPEC is as follows:
-
- FORMAT-SPEC ==>
- {binary | decimal | hexadecimal | octal | natural}
-
- The natural format is the default format choosen automatically based
-on the variable type (like decimal for an `int', hex for pointers,
-etc.).
-
- For a variable with children, the format is set only on the variable
-itself, and the children are not affected.
-
-The `-var-show-format' Command
-------------------------------
-
-Synopsis
-........
-
- -var-show-format NAME
-
- Returns the format used to display the value of the object NAME.
-
- FORMAT ==>
- FORMAT-SPEC
-
-The `-var-info-num-children' Command
-------------------------------------
-
-Synopsis
-........
-
- -var-info-num-children NAME
-
- Returns the number of children of a variable object NAME:
-
- numchild=N
-
- Note that this number is not completely reliable for a dynamic
-varobj. It will return the current number of children, but more
-children may be available.
-
-The `-var-list-children' Command
---------------------------------
-
-Synopsis
-........
-
- -var-list-children [PRINT-VALUES] NAME [FROM TO]
-Return a list of the children of the specified variable object and
-create variable objects for them, if they do not already exist. With a
-single argument or if PRINT-VALUES has a value of 0 or `--no-values',
-print only the names of the variables; if PRINT-VALUES is 1 or
-`--all-values', also print their values; and if it is 2 or
-`--simple-values' print the name and value for simple data types and
-just the name for arrays, structures and unions.
-
- FROM and TO, if specified, indicate the range of children to report.
-If FROM or TO is less than zero, the range is reset and all children
-will be reported. Otherwise, children starting at FROM (zero-based)
-and up to and excluding TO will be reported.
-
- If a child range is requested, it will only affect the current call
-to `-var-list-children', but not future calls to `-var-update'. For
-this, you must instead use `-var-set-update-range'. The intent of this
-approach is to enable a front end to implement any update approach it
-likes; for example, scrolling a view may cause the front end to request
-more children with `-var-list-children', and then the front end could
-call `-var-set-update-range' with a different range to ensure that
-future updates are restricted to just the visible items.
-
- For each child the following results are returned:
-
-NAME
- Name of the variable object created for this child.
-
-EXP
- The expression to be shown to the user by the front end to
- designate this child. For example this may be the name of a
- structure member.
-
- For a dynamic varobj, this value cannot be used to form an
- expression. There is no way to do this at all with a dynamic
- varobj.
-
- For C/C++ structures there are several pseudo children returned to
- designate access qualifiers. For these pseudo children EXP is
- `public', `private', or `protected'. In this case the type and
- value are not present.
-
- A dynamic varobj will not report the access qualifying
- pseudo-children, regardless of the language. This information is
- not available at all with a dynamic varobj.
-
-NUMCHILD
- Number of children this child has. For a dynamic varobj, this
- will be 0.
-
-TYPE
- The type of the child.
-
-VALUE
- If values were requested, this is the value.
-
-THREAD-ID
- If this variable object is associated with a thread, this is the
- thread id. Otherwise this result is not present.
-
-FROZEN
- If the variable object is frozen, this variable will be present
- with a value of 1.
-
- The result may have its own attributes:
-
-`displayhint'
- A dynamic varobj can supply a display hint to the front end. The
- value comes directly from the Python pretty-printer object's
- `display_hint' method. *Note Pretty Printing API::.
-
-`has_more'
- This is an integer attribute which is nonzero if there are children
- remaining after the end of the selected range.
-
-Example
-.......
-
- (gdb)
- -var-list-children n
- ^done,numchild=N,children=[child={name=NAME,exp=EXP,
- numchild=N,type=TYPE},(repeats N times)]
- (gdb)
- -var-list-children --all-values n
- ^done,numchild=N,children=[child={name=NAME,exp=EXP,
- numchild=N,value=VALUE,type=TYPE},(repeats N times)]
-
-The `-var-info-type' Command
-----------------------------
-
-Synopsis
-........
-
- -var-info-type NAME
-
- Returns the type of the specified variable NAME. The type is
-returned as a string in the same format as it is output by the GDB CLI:
-
- type=TYPENAME
-
-The `-var-info-expression' Command
-----------------------------------
-
-Synopsis
-........
-
- -var-info-expression NAME
-
- Returns a string that is suitable for presenting this variable
-object in user interface. The string is generally not valid expression
-in the current language, and cannot be evaluated.
-
- For example, if `a' is an array, and variable object `A' was created
-for `a', then we'll get this output:
-
- (gdb) -var-info-expression A.1
- ^done,lang="C",exp="1"
-
-Here, the values of `lang' can be `{"C" | "C++" | "Java"}'.
-
- Note that the output of the `-var-list-children' command also
-includes those expressions, so the `-var-info-expression' command is of
-limited use.
-
-The `-var-info-path-expression' Command
----------------------------------------
-
-Synopsis
-........
-
- -var-info-path-expression NAME
-
- Returns an expression that can be evaluated in the current context
-and will yield the same value that a variable object has. Compare this
-with the `-var-info-expression' command, which result can be used only
-for UI presentation. Typical use of the `-var-info-path-expression'
-command is creating a watchpoint from a variable object.
-
- This command is currently not valid for children of a dynamic varobj,
-and will give an error when invoked on one.
-
- For example, suppose `C' is a C++ class, derived from class `Base',
-and that the `Base' class has a member called `m_size'. Assume a
-variable `c' is has the type of `C' and a variable object `C' was
-created for variable `c'. Then, we'll get this output:
- (gdb) -var-info-path-expression C.Base.public.m_size
- ^done,path_expr=((Base)c).m_size)
-
-The `-var-show-attributes' Command
-----------------------------------
-
-Synopsis
-........
-
- -var-show-attributes NAME
-
- List attributes of the specified variable object NAME:
-
- status=ATTR [ ( ,ATTR )* ]
-
-where ATTR is `{ { editable | noneditable } | TBD }'.
-
-The `-var-evaluate-expression' Command
---------------------------------------
-
-Synopsis
-........
-
- -var-evaluate-expression [-f FORMAT-SPEC] NAME
-
- Evaluates the expression that is represented by the specified
-variable object and returns its value as a string. The format of the
-string can be specified with the `-f' option. The possible values of
-this option are the same as for `-var-set-format' (*note
--var-set-format::). If the `-f' option is not specified, the current
-display format will be used. The current display format can be changed
-using the `-var-set-format' command.
-
- value=VALUE
-
- Note that one must invoke `-var-list-children' for a variable before
-the value of a child variable can be evaluated.
-
-The `-var-assign' Command
--------------------------
-
-Synopsis
-........
-
- -var-assign NAME EXPRESSION
-
- Assigns the value of EXPRESSION to the variable object specified by
-NAME. The object must be `editable'. If the variable's value is
-altered by the assign, the variable will show up in any subsequent
-`-var-update' list.
-
-Example
-.......
-
- (gdb)
- -var-assign var1 3
- ^done,value="3"
- (gdb)
- -var-update *
- ^done,changelist=[{name="var1",in_scope="true",type_changed="false"}]
- (gdb)
-
-The `-var-update' Command
--------------------------
-
-Synopsis
-........
-
- -var-update [PRINT-VALUES] {NAME | "*"}
-
- Reevaluate the expressions corresponding to the variable object NAME
-and all its direct and indirect children, and return the list of
-variable objects whose values have changed; NAME must be a root
-variable object. Here, "changed" means that the result of
-`-var-evaluate-expression' before and after the `-var-update' is
-different. If `*' is used as the variable object names, all existing
-variable objects are updated, except for frozen ones (*note
--var-set-frozen::). The option PRINT-VALUES determines whether both
-names and values, or just names are printed. The possible values of
-this option are the same as for `-var-list-children' (*note
--var-list-children::). It is recommended to use the `--all-values'
-option, to reduce the number of MI commands needed on each program stop.
-
- With the `*' parameter, if a variable object is bound to a currently
-running thread, it will not be updated, without any diagnostic.
-
- If `-var-set-update-range' was previously used on a varobj, then
-only the selected range of children will be reported.
-
- `-var-update' reports all the changed varobjs in a tuple named
-`changelist'.
-
- Each item in the change list is itself a tuple holding:
-
-`name'
- The name of the varobj.
-
-`value'
- If values were requested for this update, then this field will be
- present and will hold the value of the varobj.
-
-`in_scope'
- This field is a string which may take one of three values:
-
- `"true"'
- The variable object's current value is valid.
-
- `"false"'
- The variable object does not currently hold a valid value but
- it may hold one in the future if its associated expression
- comes back into scope.
-
- `"invalid"'
- The variable object no longer holds a valid value. This can
- occur when the executable file being debugged has changed,
- either through recompilation or by using the GDB `file'
- command. The front end should normally choose to delete
- these variable objects.
-
- In the future new values may be added to this list so the front
- should be prepared for this possibility. *Note GDB/MI Development
- and Front Ends: GDB/MI Development and Front Ends.
-
-`type_changed'
- This is only present if the varobj is still valid. If the type
- changed, then this will be the string `true'; otherwise it will be
- `false'.
-
-`new_type'
- If the varobj's type changed, then this field will be present and
- will hold the new type.
-
-`new_num_children'
- For a dynamic varobj, if the number of children changed, or if the
- type changed, this will be the new number of children.
-
- The `numchild' field in other varobj responses is generally not
- valid for a dynamic varobj - it will show the number of children
- that GDB knows about, but because dynamic varobjs lazily
- instantiate their children, this will not reflect the number of
- children which may be available.
-
- The `new_num_children' attribute only reports changes to the
- number of children known by GDB. This is the only way to detect
- whether an update has removed children (which necessarily can only
- happen at the end of the update range).
-
-`displayhint'
- The display hint, if any.
-
-`has_more'
- This is an integer value, which will be 1 if there are more
- children available outside the varobj's update range.
-
-`dynamic'
- This attribute will be present and have the value `1' if the
- varobj is a dynamic varobj. If the varobj is not a dynamic varobj,
- then this attribute will not be present.
-
-`new_children'
- If new children were added to a dynamic varobj within the selected
- update range (as set by `-var-set-update-range'), then they will
- be listed in this attribute.
-
-Example
-.......
-
- (gdb)
- -var-assign var1 3
- ^done,value="3"
- (gdb)
- -var-update --all-values var1
- ^done,changelist=[{name="var1",value="3",in_scope="true",
- type_changed="false"}]
- (gdb)
-
-The `-var-set-frozen' Command
------------------------------
-
-Synopsis
-........
-
- -var-set-frozen NAME FLAG
-
- Set the frozenness flag on the variable object NAME. The FLAG
-parameter should be either `1' to make the variable frozen or `0' to
-make it unfrozen. If a variable object is frozen, then neither itself,
-nor any of its children, are implicitly updated by `-var-update' of a
-parent variable or by `-var-update *'. Only `-var-update' of the
-variable itself will update its value and values of its children.
-After a variable object is unfrozen, it is implicitly updated by all
-subsequent `-var-update' operations. Unfreezing a variable does not
-update it, only subsequent `-var-update' does.
-
-Example
-.......
-
- (gdb)
- -var-set-frozen V 1
- ^done
- (gdb)
-
-The `-var-set-update-range' command
------------------------------------
-
-Synopsis
-........
-
- -var-set-update-range NAME FROM TO
-
- Set the range of children to be returned by future invocations of
-`-var-update'.
-
- FROM and TO indicate the range of children to report. If FROM or TO
-is less than zero, the range is reset and all children will be
-reported. Otherwise, children starting at FROM (zero-based) and up to
-and excluding TO will be reported.
-
-Example
-.......
-
- (gdb)
- -var-set-update-range V 1 2
- ^done
-
-The `-var-set-visualizer' command
----------------------------------
-
-Synopsis
-........
-
- -var-set-visualizer NAME VISUALIZER
-
- Set a visualizer for the variable object NAME.
-
- VISUALIZER is the visualizer to use. The special value `None' means
-to disable any visualizer in use.
-
- If not `None', VISUALIZER must be a Python expression. This
-expression must evaluate to a callable object which accepts a single
-argument. GDB will call this object with the value of the varobj NAME
-as an argument (this is done so that the same Python pretty-printing
-code can be used for both the CLI and MI). When called, this object
-must return an object which conforms to the pretty-printing interface
-(*note Pretty Printing API::).
-
- The pre-defined function `gdb.default_visualizer' may be used to
-select a visualizer by following the built-in process (*note Selecting
-Pretty-Printers::). This is done automatically when a varobj is
-created, and so ordinarily is not needed.
-
- This feature is only available if Python support is enabled. The MI
-command `-list-features' (*note GDB/MI Miscellaneous Commands::) can be
-used to check this.
-
-Example
-.......
-
-Resetting the visualizer:
-
- (gdb)
- -var-set-visualizer V None
- ^done
-
- Reselecting the default (type-based) visualizer:
-
- (gdb)
- -var-set-visualizer V gdb.default_visualizer
- ^done
-
- Suppose `SomeClass' is a visualizer class. A lambda expression can
-be used to instantiate this class for a varobj:
-
- (gdb)
- -var-set-visualizer V "lambda val: SomeClass()"
- ^done
-
-
-File: gdb.info, Node: GDB/MI Data Manipulation, Next: GDB/MI Tracepoint Commands, Prev: GDB/MI Variable Objects, Up: GDB/MI
-
-27.14 GDB/MI Data Manipulation
-==============================
-
-This section describes the GDB/MI commands that manipulate data:
-examine memory and registers, evaluate expressions, etc.
-
-The `-data-disassemble' Command
--------------------------------
-
-Synopsis
-........
-
- -data-disassemble
- [ -s START-ADDR -e END-ADDR ]
- | [ -f FILENAME -l LINENUM [ -n LINES ] ]
- -- MODE
-
-Where:
-
-`START-ADDR'
- is the beginning address (or `$pc')
-
-`END-ADDR'
- is the end address
-
-`FILENAME'
- is the name of the file to disassemble
-
-`LINENUM'
- is the line number to disassemble around
-
-`LINES'
- is the number of disassembly lines to be produced. If it is -1,
- the whole function will be disassembled, in case no END-ADDR is
- specified. If END-ADDR is specified as a non-zero value, and
- LINES is lower than the number of disassembly lines between
- START-ADDR and END-ADDR, only LINES lines are displayed; if LINES
- is higher than the number of lines between START-ADDR and
- END-ADDR, only the lines up to END-ADDR are displayed.
-
-`MODE'
- is either 0 (meaning only disassembly), 1 (meaning mixed source and
- disassembly), 2 (meaning disassembly with raw opcodes), or 3
- (meaning mixed source and disassembly with raw opcodes).
-
-Result
-......
-
-The output for each instruction is composed of four fields:
-
- * Address
-
- * Func-name
-
- * Offset
-
- * Instruction
-
- Note that whatever included in the instruction field, is not
-manipulated directly by GDB/MI, i.e., it is not possible to adjust its
-format.
-
-GDB Command
-...........
-
-There's no direct mapping from this command to the CLI.
-
-Example
-.......
-
-Disassemble from the current value of `$pc' to `$pc + 20':
-
- (gdb)
- -data-disassemble -s $pc -e "$pc + 20" -- 0
- ^done,
- asm_insns=[
- {address="0x000107c0",func-name="main",offset="4",
- inst="mov 2, %o0"},
- {address="0x000107c4",func-name="main",offset="8",
- inst="sethi %hi(0x11800), %o2"},
- {address="0x000107c8",func-name="main",offset="12",
- inst="or %o2, 0x140, %o1\t! 0x11940 <_lib_version+8>"},
- {address="0x000107cc",func-name="main",offset="16",
- inst="sethi %hi(0x11800), %o2"},
- {address="0x000107d0",func-name="main",offset="20",
- inst="or %o2, 0x168, %o4\t! 0x11968 <_lib_version+48>"}]
- (gdb)
-
- Disassemble the whole `main' function. Line 32 is part of `main'.
-
- -data-disassemble -f basics.c -l 32 -- 0
- ^done,asm_insns=[
- {address="0x000107bc",func-name="main",offset="0",
- inst="save %sp, -112, %sp"},
- {address="0x000107c0",func-name="main",offset="4",
- inst="mov 2, %o0"},
- {address="0x000107c4",func-name="main",offset="8",
- inst="sethi %hi(0x11800), %o2"},
- [...]
- {address="0x0001081c",func-name="main",offset="96",inst="ret "},
- {address="0x00010820",func-name="main",offset="100",inst="restore "}]
- (gdb)
-
- Disassemble 3 instructions from the start of `main':
-
- (gdb)
- -data-disassemble -f basics.c -l 32 -n 3 -- 0
- ^done,asm_insns=[
- {address="0x000107bc",func-name="main",offset="0",
- inst="save %sp, -112, %sp"},
- {address="0x000107c0",func-name="main",offset="4",
- inst="mov 2, %o0"},
- {address="0x000107c4",func-name="main",offset="8",
- inst="sethi %hi(0x11800), %o2"}]
- (gdb)
-
- Disassemble 3 instructions from the start of `main' in mixed mode:
-
- (gdb)
- -data-disassemble -f basics.c -l 32 -n 3 -- 1
- ^done,asm_insns=[
- src_and_asm_line={line="31",
- file="/kwikemart/marge/ezannoni/flathead-dev/devo/gdb/ \
- testsuite/gdb.mi/basics.c",line_asm_insn=[
- {address="0x000107bc",func-name="main",offset="0",
- inst="save %sp, -112, %sp"}]},
- src_and_asm_line={line="32",
- file="/kwikemart/marge/ezannoni/flathead-dev/devo/gdb/ \
- testsuite/gdb.mi/basics.c",line_asm_insn=[
- {address="0x000107c0",func-name="main",offset="4",
- inst="mov 2, %o0"},
- {address="0x000107c4",func-name="main",offset="8",
- inst="sethi %hi(0x11800), %o2"}]}]
- (gdb)
-
-The `-data-evaluate-expression' Command
----------------------------------------
-
-Synopsis
-........
-
- -data-evaluate-expression EXPR
-
- Evaluate EXPR as an expression. The expression could contain an
-inferior function call. The function call will execute synchronously.
-If the expression contains spaces, it must be enclosed in double quotes.
-
-GDB Command
-...........
-
-The corresponding GDB commands are `print', `output', and `call'. In
-`gdbtk' only, there's a corresponding `gdb_eval' command.
-
-Example
-.......
-
-In the following example, the numbers that precede the commands are the
-"tokens" described in *note GDB/MI Command Syntax: GDB/MI Command
-Syntax. Notice how GDB/MI returns the same tokens in its output.
-
- 211-data-evaluate-expression A
- 211^done,value="1"
- (gdb)
- 311-data-evaluate-expression &A
- 311^done,value="0xefffeb7c"
- (gdb)
- 411-data-evaluate-expression A+3
- 411^done,value="4"
- (gdb)
- 511-data-evaluate-expression "A + 3"
- 511^done,value="4"
- (gdb)
-
-The `-data-list-changed-registers' Command
-------------------------------------------
-
-Synopsis
-........
-
- -data-list-changed-registers
-
- Display a list of the registers that have changed.
-
-GDB Command
-...........
-
-GDB doesn't have a direct analog for this command; `gdbtk' has the
-corresponding command `gdb_changed_register_list'.
-
-Example
-.......
-
-On a PPC MBX board:
-
- (gdb)
- -exec-continue
- ^running
-
- (gdb)
- *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={
- func="main",args=[],file="try.c",fullname="/home/foo/bar/try.c",
- line="5"}
- (gdb)
- -data-list-changed-registers
- ^done,changed-registers=["0","1","2","4","5","6","7","8","9",
- "10","11","13","14","15","16","17","18","19","20","21","22","23",
- "24","25","26","27","28","30","31","64","65","66","67","69"]
- (gdb)
-
-The `-data-list-register-names' Command
----------------------------------------
-
-Synopsis
-........
-
- -data-list-register-names [ ( REGNO )+ ]
-
- Show a list of register names for the current target. If no
-arguments are given, it shows a list of the names of all the registers.
-If integer numbers are given as arguments, it will print a list of the
-names of the registers corresponding to the arguments. To ensure
-consistency between a register name and its number, the output list may
-include empty register names.
-
-GDB Command
-...........
-
-GDB does not have a command which corresponds to
-`-data-list-register-names'. In `gdbtk' there is a corresponding
-command `gdb_regnames'.
-
-Example
-.......
-
-For the PPC MBX board:
- (gdb)
- -data-list-register-names
- ^done,register-names=["r0","r1","r2","r3","r4","r5","r6","r7",
- "r8","r9","r10","r11","r12","r13","r14","r15","r16","r17","r18",
- "r19","r20","r21","r22","r23","r24","r25","r26","r27","r28","r29",
- "r30","r31","f0","f1","f2","f3","f4","f5","f6","f7","f8","f9",
- "f10","f11","f12","f13","f14","f15","f16","f17","f18","f19","f20",
- "f21","f22","f23","f24","f25","f26","f27","f28","f29","f30","f31",
- "", "pc","ps","cr","lr","ctr","xer"]
- (gdb)
- -data-list-register-names 1 2 3
- ^done,register-names=["r1","r2","r3"]
- (gdb)
-
-The `-data-list-register-values' Command
-----------------------------------------
-
-Synopsis
-........
-
- -data-list-register-values FMT [ ( REGNO )*]
-
- Display the registers' contents. FMT is the format according to
-which the registers' contents are to be returned, followed by an
-optional list of numbers specifying the registers to display. A
-missing list of numbers indicates that the contents of all the
-registers must be returned.
-
- Allowed formats for FMT are:
-
-`x'
- Hexadecimal
-
-`o'
- Octal
-
-`t'
- Binary
-
-`d'
- Decimal
-
-`r'
- Raw
-
-`N'
- Natural
-
-GDB Command
-...........
-
-The corresponding GDB commands are `info reg', `info all-reg', and (in
-`gdbtk') `gdb_fetch_registers'.
-
-Example
-.......
-
-For a PPC MBX board (note: line breaks are for readability only, they
-don't appear in the actual output):
-
- (gdb)
- -data-list-register-values r 64 65
- ^done,register-values=[{number="64",value="0xfe00a300"},
- {number="65",value="0x00029002"}]
- (gdb)
- -data-list-register-values x
- ^done,register-values=[{number="0",value="0xfe0043c8"},
- {number="1",value="0x3fff88"},{number="2",value="0xfffffffe"},
- {number="3",value="0x0"},{number="4",value="0xa"},
- {number="5",value="0x3fff68"},{number="6",value="0x3fff58"},
- {number="7",value="0xfe011e98"},{number="8",value="0x2"},
- {number="9",value="0xfa202820"},{number="10",value="0xfa202808"},
- {number="11",value="0x1"},{number="12",value="0x0"},
- {number="13",value="0x4544"},{number="14",value="0xffdfffff"},
- {number="15",value="0xffffffff"},{number="16",value="0xfffffeff"},
- {number="17",value="0xefffffed"},{number="18",value="0xfffffffe"},
- {number="19",value="0xffffffff"},{number="20",value="0xffffffff"},
- {number="21",value="0xffffffff"},{number="22",value="0xfffffff7"},
- {number="23",value="0xffffffff"},{number="24",value="0xffffffff"},
- {number="25",value="0xffffffff"},{number="26",value="0xfffffffb"},
- {number="27",value="0xffffffff"},{number="28",value="0xf7bfffff"},
- {number="29",value="0x0"},{number="30",value="0xfe010000"},
- {number="31",value="0x0"},{number="32",value="0x0"},
- {number="33",value="0x0"},{number="34",value="0x0"},
- {number="35",value="0x0"},{number="36",value="0x0"},
- {number="37",value="0x0"},{number="38",value="0x0"},
- {number="39",value="0x0"},{number="40",value="0x0"},
- {number="41",value="0x0"},{number="42",value="0x0"},
- {number="43",value="0x0"},{number="44",value="0x0"},
- {number="45",value="0x0"},{number="46",value="0x0"},
- {number="47",value="0x0"},{number="48",value="0x0"},
- {number="49",value="0x0"},{number="50",value="0x0"},
- {number="51",value="0x0"},{number="52",value="0x0"},
- {number="53",value="0x0"},{number="54",value="0x0"},
- {number="55",value="0x0"},{number="56",value="0x0"},
- {number="57",value="0x0"},{number="58",value="0x0"},
- {number="59",value="0x0"},{number="60",value="0x0"},
- {number="61",value="0x0"},{number="62",value="0x0"},
- {number="63",value="0x0"},{number="64",value="0xfe00a300"},
- {number="65",value="0x29002"},{number="66",value="0x202f04b5"},
- {number="67",value="0xfe0043b0"},{number="68",value="0xfe00b3e4"},
- {number="69",value="0x20002b03"}]
- (gdb)
-
-The `-data-read-memory' Command
--------------------------------
-
-This command is deprecated, use `-data-read-memory-bytes' instead.
-
-Synopsis
-........
-
- -data-read-memory [ -o BYTE-OFFSET ]
- ADDRESS WORD-FORMAT WORD-SIZE
- NR-ROWS NR-COLS [ ASCHAR ]
-
-where:
-
-`ADDRESS'
- An expression specifying the address of the first memory word to be
- read. Complex expressions containing embedded white space should
- be quoted using the C convention.
-
-`WORD-FORMAT'
- The format to be used to print the memory words. The notation is
- the same as for GDB's `print' command (*note Output Formats:
- Output Formats.).
-
-`WORD-SIZE'
- The size of each memory word in bytes.
-
-`NR-ROWS'
- The number of rows in the output table.
-
-`NR-COLS'
- The number of columns in the output table.
-
-`ASCHAR'
- If present, indicates that each row should include an ASCII dump.
- The value of ASCHAR is used as a padding character when a byte is
- not a member of the printable ASCII character set (printable ASCII
- characters are those whose code is between 32 and 126,
- inclusively).
-
-`BYTE-OFFSET'
- An offset to add to the ADDRESS before fetching memory.
-
- This command displays memory contents as a table of NR-ROWS by
-NR-COLS words, each word being WORD-SIZE bytes. In total, `NR-ROWS *
-NR-COLS * WORD-SIZE' bytes are read (returned as `total-bytes').
-Should less than the requested number of bytes be returned by the
-target, the missing words are identified using `N/A'. The number of
-bytes read from the target is returned in `nr-bytes' and the starting
-address used to read memory in `addr'.
-
- The address of the next/previous row or page is available in
-`next-row' and `prev-row', `next-page' and `prev-page'.
-
-GDB Command
-...........
-
-The corresponding GDB command is `x'. `gdbtk' has `gdb_get_mem' memory
-read command.
-
-Example
-.......
-
-Read six bytes of memory starting at `bytes+6' but then offset by `-6'
-bytes. Format as three rows of two columns. One byte per word.
-Display each word in hex.
-
- (gdb)
- 9-data-read-memory -o -6 -- bytes+6 x 1 3 2
- 9^done,addr="0x00001390",nr-bytes="6",total-bytes="6",
- next-row="0x00001396",prev-row="0x0000138e",next-page="0x00001396",
- prev-page="0x0000138a",memory=[
- {addr="0x00001390",data=["0x00","0x01"]},
- {addr="0x00001392",data=["0x02","0x03"]},
- {addr="0x00001394",data=["0x04","0x05"]}]
- (gdb)
-
- Read two bytes of memory starting at address `shorts + 64' and
-display as a single word formatted in decimal.
-
- (gdb)
- 5-data-read-memory shorts+64 d 2 1 1
- 5^done,addr="0x00001510",nr-bytes="2",total-bytes="2",
- next-row="0x00001512",prev-row="0x0000150e",
- next-page="0x00001512",prev-page="0x0000150e",memory=[
- {addr="0x00001510",data=["128"]}]
- (gdb)
-
- Read thirty two bytes of memory starting at `bytes+16' and format as
-eight rows of four columns. Include a string encoding with `x' used as
-the non-printable character.
-
- (gdb)
- 4-data-read-memory bytes+16 x 1 8 4 x
- 4^done,addr="0x000013a0",nr-bytes="32",total-bytes="32",
- next-row="0x000013c0",prev-row="0x0000139c",
- next-page="0x000013c0",prev-page="0x00001380",memory=[
- {addr="0x000013a0",data=["0x10","0x11","0x12","0x13"],ascii="xxxx"},
- {addr="0x000013a4",data=["0x14","0x15","0x16","0x17"],ascii="xxxx"},
- {addr="0x000013a8",data=["0x18","0x19","0x1a","0x1b"],ascii="xxxx"},
- {addr="0x000013ac",data=["0x1c","0x1d","0x1e","0x1f"],ascii="xxxx"},
- {addr="0x000013b0",data=["0x20","0x21","0x22","0x23"],ascii=" !\"#"},
- {addr="0x000013b4",data=["0x24","0x25","0x26","0x27"],ascii="$%&'"},
- {addr="0x000013b8",data=["0x28","0x29","0x2a","0x2b"],ascii="()*+"},
- {addr="0x000013bc",data=["0x2c","0x2d","0x2e","0x2f"],ascii=",-./"}]
- (gdb)
-
-The `-data-read-memory-bytes' Command
--------------------------------------
-
-Synopsis
-........
-
- -data-read-memory-bytes [ -o BYTE-OFFSET ]
- ADDRESS COUNT
-
-where:
-
-`ADDRESS'
- An expression specifying the address of the first memory word to be
- read. Complex expressions containing embedded white space should
- be quoted using the C convention.
-
-`COUNT'
- The number of bytes to read. This should be an integer literal.
-
-`BYTE-OFFSET'
- The offsets in bytes relative to ADDRESS at which to start
- reading. This should be an integer literal. This option is
- provided so that a frontend is not required to first evaluate
- address and then perform address arithmetics itself.
-
-
- This command attempts to read all accessible memory regions in the
-specified range. First, all regions marked as unreadable in the memory
-map (if one is defined) will be skipped. *Note Memory Region
-Attributes::. Second, GDB will attempt to read the remaining regions.
-For each one, if reading full region results in an errors, GDB will try
-to read a subset of the region.
-
- In general, every single byte in the region may be readable or not,
-and the only way to read every readable byte is to try a read at every
-address, which is not practical. Therefore, GDB will attempt to read
-all accessible bytes at either beginning or the end of the region,
-using a binary division scheme. This heuristic works well for reading
-accross a memory map boundary. Note that if a region has a readable
-range that is neither at the beginning or the end, GDB will not read it.
-
- The result record (*note GDB/MI Result Records::) that is output of
-the command includes a field named `memory' whose content is a list of
-tuples. Each tuple represent a successfully read memory block and has
-the following fields:
-
-`begin'
- The start address of the memory block, as hexadecimal literal.
-
-`end'
- The end address of the memory block, as hexadecimal literal.
-
-`offset'
- The offset of the memory block, as hexadecimal literal, relative to
- the start address passed to `-data-read-memory-bytes'.
-
-`contents'
- The contents of the memory block, in hex.
-
-
-GDB Command
-...........
-
-The corresponding GDB command is `x'.
-
-Example
-.......
-
- (gdb)
- -data-read-memory-bytes &a 10
- ^done,memory=[{begin="0xbffff154",offset="0x00000000",
- end="0xbffff15e",
- contents="01000000020000000300"}]
- (gdb)
-
-The `-data-write-memory-bytes' Command
---------------------------------------
-
-Synopsis
-........
-
- -data-write-memory-bytes ADDRESS CONTENTS
-
-where:
-
-`ADDRESS'
- An expression specifying the address of the first memory word to be
- read. Complex expressions containing embedded white space should
- be quoted using the C convention.
-
-`CONTENTS'
- The hex-encoded bytes to write.
-
-
-GDB Command
-...........
-
-There's no corresponding GDB command.
-
-Example
-.......
-
- (gdb)
- -data-write-memory-bytes &a "aabbccdd"
- ^done
- (gdb)
-
-
-File: gdb.info, Node: GDB/MI Tracepoint Commands, Next: GDB/MI Symbol Query, Prev: GDB/MI Data Manipulation, Up: GDB/MI
-
-27.15 GDB/MI Tracepoint Commands
-================================
-
-The commands defined in this section implement MI support for
-tracepoints. For detailed introduction, see *note Tracepoints::.
-
-The `-trace-find' Command
--------------------------
-
-Synopsis
-........
-
- -trace-find MODE [PARAMETERS...]
-
- Find a trace frame using criteria defined by MODE and PARAMETERS.
-The following table lists permissible modes and their parameters. For
-details of operation, see *note tfind::.
-
-`none'
- No parameters are required. Stops examining trace frames.
-
-`frame-number'
- An integer is required as parameter. Selects tracepoint frame with
- that index.
-
-`tracepoint-number'
- An integer is required as parameter. Finds next trace frame that
- corresponds to tracepoint with the specified number.
-
-`pc'
- An address is required as parameter. Finds next trace frame that
- corresponds to any tracepoint at the specified address.
-
-`pc-inside-range'
- Two addresses are required as parameters. Finds next trace frame
- that corresponds to a tracepoint at an address inside the
- specified range. Both bounds are considered to be inside the
- range.
-
-`pc-outside-range'
- Two addresses are required as parameters. Finds next trace frame
- that corresponds to a tracepoint at an address outside the
- specified range. Both bounds are considered to be inside the
- range.
-
-`line'
- Line specification is required as parameter. *Note Specify
- Location::. Finds next trace frame that corresponds to a
- tracepoint at the specified location.
-
-
- If `none' was passed as MODE, the response does not have fields.
-Otherwise, the response may have the following fields:
-
-`found'
- This field has either `0' or `1' as the value, depending on
- whether a matching tracepoint was found.
-
-`traceframe'
- The index of the found traceframe. This field is present iff the
- `found' field has value of `1'.
-
-`tracepoint'
- The index of the found tracepoint. This field is present iff the
- `found' field has value of `1'.
-
-`frame'
- The information about the frame corresponding to the found trace
- frame. This field is present only if a trace frame was found.
- *Note GDB/MI Frame Information::, for description of this field.
-
-
-GDB Command
-...........
-
-The corresponding GDB command is `tfind'.
-
--trace-define-variable
-----------------------
-
-Synopsis
-........
-
- -trace-define-variable NAME [ VALUE ]
-
- Create trace variable NAME if it does not exist. If VALUE is
-specified, sets the initial value of the specified trace variable to
-that value. Note that the NAME should start with the `$' character.
-
-GDB Command
-...........
-
-The corresponding GDB command is `tvariable'.
-
--trace-list-variables
----------------------
-
-Synopsis
-........
-
- -trace-list-variables
-
- Return a table of all defined trace variables. Each element of the
-table has the following fields:
-
-`name'
- The name of the trace variable. This field is always present.
-
-`initial'
- The initial value. This is a 64-bit signed integer. This field
- is always present.
-
-`current'
- The value the trace variable has at the moment. This is a 64-bit
- signed integer. This field is absent iff current value is not
- defined, for example if the trace was never run, or is presently
- running.
-
-
-GDB Command
-...........
-
-The corresponding GDB command is `tvariables'.
-
-Example
-.......
-
- (gdb)
- -trace-list-variables
- ^done,trace-variables={nr_rows="1",nr_cols="3",
- hdr=[{width="15",alignment="-1",col_name="name",colhdr="Name"},
- {width="11",alignment="-1",col_name="initial",colhdr="Initial"},
- {width="11",alignment="-1",col_name="current",colhdr="Current"}],
- body=[variable={name="$trace_timestamp",initial="0"}
- variable={name="$foo",initial="10",current="15"}]}
- (gdb)
-
--trace-save
------------
-
-Synopsis
-........
-
- -trace-save [-r ] FILENAME
-
- Saves the collected trace data to FILENAME. Without the `-r'
-option, the data is downloaded from the target and saved in a local
-file. With the `-r' option the target is asked to perform the save.
-
-GDB Command
-...........
-
-The corresponding GDB command is `tsave'.
-
--trace-start
-------------
-
-Synopsis
-........
-
- -trace-start
-
- Starts a tracing experiments. The result of this command does not
-have any fields.
-
-GDB Command
-...........
-
-The corresponding GDB command is `tstart'.
-
--trace-status
--------------
-
-Synopsis
-........
-
- -trace-status
-
- Obtains the status of a tracing experiment. The result may include
-the following fields:
-
-`supported'
- May have a value of either `0', when no tracing operations are
- supported, `1', when all tracing operations are supported, or
- `file' when examining trace file. In the latter case, examining
- of trace frame is possible but new tracing experiement cannot be
- started. This field is always present.
-
-`running'
- May have a value of either `0' or `1' depending on whether tracing
- experiement is in progress on target. This field is present if
- `supported' field is not `0'.
-
-`stop-reason'
- Report the reason why the tracing was stopped last time. This
- field may be absent iff tracing was never stopped on target yet.
- The value of `request' means the tracing was stopped as result of
- the `-trace-stop' command. The value of `overflow' means the
- tracing buffer is full. The value of `disconnection' means
- tracing was automatically stopped when GDB has disconnected. The
- value of `passcount' means tracing was stopped when a tracepoint
- was passed a maximal number of times for that tracepoint. This
- field is present if `supported' field is not `0'.
-
-`stopping-tracepoint'
- The number of tracepoint whose passcount as exceeded. This field
- is present iff the `stop-reason' field has the value of
- `passcount'.
-
-`frames'
-`frames-created'
- The `frames' field is a count of the total number of trace frames
- in the trace buffer, while `frames-created' is the total created
- during the run, including ones that were discarded, such as when a
- circular trace buffer filled up. Both fields are optional.
-
-`buffer-size'
-`buffer-free'
- These fields tell the current size of the tracing buffer and the
- remaining space. These fields are optional.
-
-`circular'
- The value of the circular trace buffer flag. `1' means that the
- trace buffer is circular and old trace frames will be discarded if
- necessary to make room, `0' means that the trace buffer is linear
- and may fill up.
-
-`disconnected'
- The value of the disconnected tracing flag. `1' means that
- tracing will continue after GDB disconnects, `0' means that the
- trace run will stop.
-
-
-GDB Command
-...........
-
-The corresponding GDB command is `tstatus'.
-
--trace-stop
------------
-
-Synopsis
-........
-
- -trace-stop
-
- Stops a tracing experiment. The result of this command has the same
-fields as `-trace-status', except that the `supported' and `running'
-fields are not output.
-
-GDB Command
-...........
-
-The corresponding GDB command is `tstop'.
-
-
-File: gdb.info, Node: GDB/MI Symbol Query, Next: GDB/MI File Commands, Prev: GDB/MI Tracepoint Commands, Up: GDB/MI
-
-27.16 GDB/MI Symbol Query Commands
-==================================
-
-The `-symbol-list-lines' Command
---------------------------------
-
-Synopsis
-........
-
- -symbol-list-lines FILENAME
-
- Print the list of lines that contain code and their associated
-program addresses for the given source filename. The entries are
-sorted in ascending PC order.
-
-GDB Command
-...........
-
-There is no corresponding GDB command.
-
-Example
-.......
-
- (gdb)
- -symbol-list-lines basics.c
- ^done,lines=[{pc="0x08048554",line="7"},{pc="0x0804855a",line="8"}]
- (gdb)
-
-
-File: gdb.info, Node: GDB/MI File Commands, Next: GDB/MI Target Manipulation, Prev: GDB/MI Symbol Query, Up: GDB/MI
-
-27.17 GDB/MI File Commands
-==========================
-
-This section describes the GDB/MI commands to specify executable file
-names and to read in and obtain symbol table information.
-
-The `-file-exec-and-symbols' Command
-------------------------------------
-
-Synopsis
-........
-
- -file-exec-and-symbols FILE
-
- Specify the executable file to be debugged. This file is the one
-from which the symbol table is also read. If no file is specified, the
-command clears the executable and symbol information. If breakpoints
-are set when using this command with no arguments, GDB will produce
-error messages. Otherwise, no output is produced, except a completion
-notification.
-
-GDB Command
-...........
-
-The corresponding GDB command is `file'.
-
-Example
-.......
-
- (gdb)
- -file-exec-and-symbols /kwikemart/marge/ezannoni/TRUNK/mbx/hello.mbx
- ^done
- (gdb)
-
-The `-file-exec-file' Command
------------------------------
-
-Synopsis
-........
-
- -file-exec-file FILE
-
- Specify the executable file to be debugged. Unlike
-`-file-exec-and-symbols', the symbol table is _not_ read from this
-file. If used without argument, GDB clears the information about the
-executable file. No output is produced, except a completion
-notification.
-
-GDB Command
-...........
-
-The corresponding GDB command is `exec-file'.
-
-Example
-.......
-
- (gdb)
- -file-exec-file /kwikemart/marge/ezannoni/TRUNK/mbx/hello.mbx
- ^done
- (gdb)
-
-The `-file-list-exec-source-file' Command
------------------------------------------
-
-Synopsis
-........
-
- -file-list-exec-source-file
-
- List the line number, the current source file, and the absolute path
-to the current source file for the current executable. The macro
-information field has a value of `1' or `0' depending on whether or not
-the file includes preprocessor macro information.
-
-GDB Command
-...........
-
-The GDB equivalent is `info source'
-
-Example
-.......
-
- (gdb)
- 123-file-list-exec-source-file
- 123^done,line="1",file="foo.c",fullname="/home/bar/foo.c,macro-info="1"
- (gdb)
-
-The `-file-list-exec-source-files' Command
-------------------------------------------
-
-Synopsis
-........
-
- -file-list-exec-source-files
-
- List the source files for the current executable.
-
- It will always output the filename, but only when GDB can find the
-absolute file name of a source file, will it output the fullname.
-
-GDB Command
-...........
-
-The GDB equivalent is `info sources'. `gdbtk' has an analogous command
-`gdb_listfiles'.
-
-Example
-.......
-
- (gdb)
- -file-list-exec-source-files
- ^done,files=[
- {file=foo.c,fullname=/home/foo.c},
- {file=/home/bar.c,fullname=/home/bar.c},
- {file=gdb_could_not_find_fullpath.c}]
- (gdb)
-
-The `-file-symbol-file' Command
--------------------------------
-
-Synopsis
-........
-
- -file-symbol-file FILE
-
- Read symbol table info from the specified FILE argument. When used
-without arguments, clears GDB's symbol table info. No output is
-produced, except for a completion notification.
-
-GDB Command
-...........
-
-The corresponding GDB command is `symbol-file'.
-
-Example
-.......
-
- (gdb)
- -file-symbol-file /kwikemart/marge/ezannoni/TRUNK/mbx/hello.mbx
- ^done
- (gdb)
-
-
-File: gdb.info, Node: GDB/MI Target Manipulation, Next: GDB/MI File Transfer Commands, Prev: GDB/MI File Commands, Up: GDB/MI
-
-27.18 GDB/MI Target Manipulation Commands
-=========================================
-
-The `-target-attach' Command
-----------------------------
-
-Synopsis
-........
-
- -target-attach PID | GID | FILE
-
- Attach to a process PID or a file FILE outside of GDB, or a thread
-group GID. If attaching to a thread group, the id previously returned
-by `-list-thread-groups --available' must be used.
-
-GDB Command
-...........
-
-The corresponding GDB command is `attach'.
-
-Example
-.......
-
- (gdb)
- -target-attach 34
- =thread-created,id="1"
- *stopped,thread-id="1",frame={addr="0xb7f7e410",func="bar",args=[]}
- ^done
- (gdb)
-
-The `-target-detach' Command
-----------------------------
-
-Synopsis
-........
-
- -target-detach [ PID | GID ]
-
- Detach from the remote target which normally resumes its execution.
-If either PID or GID is specified, detaches from either the specified
-process, or specified thread group. There's no output.
-
-GDB Command
-...........
-
-The corresponding GDB command is `detach'.
-
-Example
-.......
-
- (gdb)
- -target-detach
- ^done
- (gdb)
-
-The `-target-disconnect' Command
---------------------------------
-
-Synopsis
-........
-
- -target-disconnect
-
- Disconnect from the remote target. There's no output and the target
-is generally not resumed.
-
-GDB Command
-...........
-
-The corresponding GDB command is `disconnect'.
-
-Example
-.......
-
- (gdb)
- -target-disconnect
- ^done
- (gdb)
-
-The `-target-download' Command
-------------------------------
-
-Synopsis
-........
-
- -target-download
-
- Loads the executable onto the remote target. It prints out an
-update message every half second, which includes the fields:
-
-`section'
- The name of the section.
-
-`section-sent'
- The size of what has been sent so far for that section.
-
-`section-size'
- The size of the section.
-
-`total-sent'
- The total size of what was sent so far (the current and the
- previous sections).
-
-`total-size'
- The size of the overall executable to download.
-
-Each message is sent as status record (*note GDB/MI Output Syntax:
-GDB/MI Output Syntax.).
-
- In addition, it prints the name and size of the sections, as they are
-downloaded. These messages include the following fields:
-
-`section'
- The name of the section.
-
-`section-size'
- The size of the section.
-
-`total-size'
- The size of the overall executable to download.
-
-At the end, a summary is printed.
-
-GDB Command
-...........
-
-The corresponding GDB command is `load'.
-
-Example
-.......
-
-Note: each status message appears on a single line. Here the messages
-have been broken down so that they can fit onto a page.
-
- (gdb)
- -target-download
- +download,{section=".text",section-size="6668",total-size="9880"}
- +download,{section=".text",section-sent="512",section-size="6668",
- total-sent="512",total-size="9880"}
- +download,{section=".text",section-sent="1024",section-size="6668",
- total-sent="1024",total-size="9880"}
- +download,{section=".text",section-sent="1536",section-size="6668",
- total-sent="1536",total-size="9880"}
- +download,{section=".text",section-sent="2048",section-size="6668",
- total-sent="2048",total-size="9880"}
- +download,{section=".text",section-sent="2560",section-size="6668",
- total-sent="2560",total-size="9880"}
- +download,{section=".text",section-sent="3072",section-size="6668",
- total-sent="3072",total-size="9880"}
- +download,{section=".text",section-sent="3584",section-size="6668",
- total-sent="3584",total-size="9880"}
- +download,{section=".text",section-sent="4096",section-size="6668",
- total-sent="4096",total-size="9880"}
- +download,{section=".text",section-sent="4608",section-size="6668",
- total-sent="4608",total-size="9880"}
- +download,{section=".text",section-sent="5120",section-size="6668",
- total-sent="5120",total-size="9880"}
- +download,{section=".text",section-sent="5632",section-size="6668",
- total-sent="5632",total-size="9880"}
- +download,{section=".text",section-sent="6144",section-size="6668",
- total-sent="6144",total-size="9880"}
- +download,{section=".text",section-sent="6656",section-size="6668",
- total-sent="6656",total-size="9880"}
- +download,{section=".init",section-size="28",total-size="9880"}
- +download,{section=".fini",section-size="28",total-size="9880"}
- +download,{section=".data",section-size="3156",total-size="9880"}
- +download,{section=".data",section-sent="512",section-size="3156",
- total-sent="7236",total-size="9880"}
- +download,{section=".data",section-sent="1024",section-size="3156",
- total-sent="7748",total-size="9880"}
- +download,{section=".data",section-sent="1536",section-size="3156",
- total-sent="8260",total-size="9880"}
- +download,{section=".data",section-sent="2048",section-size="3156",
- total-sent="8772",total-size="9880"}
- +download,{section=".data",section-sent="2560",section-size="3156",
- total-sent="9284",total-size="9880"}
- +download,{section=".data",section-sent="3072",section-size="3156",
- total-sent="9796",total-size="9880"}
- ^done,address="0x10004",load-size="9880",transfer-rate="6586",
- write-rate="429"
- (gdb)
-
-GDB Command
-...........
-
-No equivalent.
-
-Example
-.......
-
-N.A.
-
-The `-target-select' Command
-----------------------------
-
-Synopsis
-........
-
- -target-select TYPE PARAMETERS ...
-
- Connect GDB to the remote target. This command takes two args:
-
-`TYPE'
- The type of target, for instance `remote', etc.
-
-`PARAMETERS'
- Device names, host names and the like. *Note Commands for
- Managing Targets: Target Commands, for more details.
-
- The output is a connection notification, followed by the address at
-which the target program is, in the following form:
-
- ^connected,addr="ADDRESS",func="FUNCTION NAME",
- args=[ARG LIST]
-
-GDB Command
-...........
-
-The corresponding GDB command is `target'.
-
-Example
-.......
-
- (gdb)
- -target-select remote /dev/ttya
- ^connected,addr="0xfe00a300",func="??",args=[]
- (gdb)
-
-
-File: gdb.info, Node: GDB/MI File Transfer Commands, Next: GDB/MI Miscellaneous Commands, Prev: GDB/MI Target Manipulation, Up: GDB/MI
-
-27.19 GDB/MI File Transfer Commands
-===================================
-
-The `-target-file-put' Command
-------------------------------
-
-Synopsis
-........
-
- -target-file-put HOSTFILE TARGETFILE
-
- Copy file HOSTFILE from the host system (the machine running GDB) to
-TARGETFILE on the target system.
-
-GDB Command
-...........
-
-The corresponding GDB command is `remote put'.
-
-Example
-.......
-
- (gdb)
- -target-file-put localfile remotefile
- ^done
- (gdb)
-
-The `-target-file-get' Command
-------------------------------
-
-Synopsis
-........
-
- -target-file-get TARGETFILE HOSTFILE
-
- Copy file TARGETFILE from the target system to HOSTFILE on the host
-system.
-
-GDB Command
-...........
-
-The corresponding GDB command is `remote get'.
-
-Example
-.......
-
- (gdb)
- -target-file-get remotefile localfile
- ^done
- (gdb)
-
-The `-target-file-delete' Command
----------------------------------
-
-Synopsis
-........
-
- -target-file-delete TARGETFILE
-
- Delete TARGETFILE from the target system.
-
-GDB Command
-...........
-
-The corresponding GDB command is `remote delete'.
-
-Example
-.......
-
- (gdb)
- -target-file-delete remotefile
- ^done
- (gdb)
-
-
-File: gdb.info, Node: GDB/MI Miscellaneous Commands, Prev: GDB/MI File Transfer Commands, Up: GDB/MI
-
-27.20 Miscellaneous GDB/MI Commands
-===================================
-
-The `-gdb-exit' Command
------------------------
-
-Synopsis
-........
-
- -gdb-exit
-
- Exit GDB immediately.
-
-GDB Command
-...........
-
-Approximately corresponds to `quit'.
-
-Example
-.......
-
- (gdb)
- -gdb-exit
- ^exit
-
-The `-gdb-set' Command
-----------------------
-
-Synopsis
-........
-
- -gdb-set
-
- Set an internal GDB variable.
-
-GDB Command
-...........
-
-The corresponding GDB command is `set'.
-
-Example
-.......
-
- (gdb)
- -gdb-set $foo=3
- ^done
- (gdb)
-
-The `-gdb-show' Command
------------------------
-
-Synopsis
-........
-
- -gdb-show
-
- Show the current value of a GDB variable.
-
-GDB Command
-...........
-
-The corresponding GDB command is `show'.
-
-Example
-.......
-
- (gdb)
- -gdb-show annotate
- ^done,value="0"
- (gdb)
-
-The `-gdb-version' Command
---------------------------
-
-Synopsis
-........
-
- -gdb-version
-
- Show version information for GDB. Used mostly in testing.
-
-GDB Command
-...........
-
-The GDB equivalent is `show version'. GDB by default shows this
-information when you start an interactive session.
-
-Example
-.......
-
- (gdb)
- -gdb-version
- ~GNU gdb 5.2.1
- ~Copyright 2000 Free Software Foundation, Inc.
- ~GDB is free software, covered by the GNU General Public License, and
- ~you are welcome to change it and/or distribute copies of it under
- ~ certain conditions.
- ~Type "show copying" to see the conditions.
- ~There is absolutely no warranty for GDB. Type "show warranty" for
- ~ details.
- ~This GDB was configured as
- "--host=sparc-sun-solaris2.5.1 --target=ppc-eabi".
- ^done
- (gdb)
-
-The `-list-features' Command
-----------------------------
-
-Returns a list of particular features of the MI protocol that this
-version of gdb implements. A feature can be a command, or a new field
-in an output of some command, or even an important bugfix. While a
-frontend can sometimes detect presence of a feature at runtime, it is
-easier to perform detection at debugger startup.
-
- The command returns a list of strings, with each string naming an
-available feature. Each returned string is just a name, it does not
-have any internal structure. The list of possible feature names is
-given below.
-
- Example output:
-
- (gdb) -list-features
- ^done,result=["feature1","feature2"]
-
- The current list of features is:
-
-`frozen-varobjs'
- Indicates presence of the `-var-set-frozen' command, as well as
- possible presense of the `frozen' field in the output of
- `-varobj-create'.
-
-`pending-breakpoints'
- Indicates presence of the `-f' option to the `-break-insert'
- command.
-
-`python'
- Indicates presence of Python scripting support, Python-based
- pretty-printing commands, and possible presence of the
- `display_hint' field in the output of `-var-list-children'
-
-`thread-info'
- Indicates presence of the `-thread-info' command.
-
-`data-read-memory-bytes'
- Indicates presense of the `-data-read-memory-bytes' and the
- `-data-write-memory-bytes' commands.
-
-
-The `-list-target-features' Command
------------------------------------
-
-Returns a list of particular features that are supported by the target.
-Those features affect the permitted MI commands, but unlike the
-features reported by the `-list-features' command, the features depend
-on which target GDB is using at the moment. Whenever a target can
-change, due to commands such as `-target-select', `-target-attach' or
-`-exec-run', the list of target features may change, and the frontend
-should obtain it again. Example output:
-
- (gdb) -list-features
- ^done,result=["async"]
-
- The current list of features is:
-
-`async'
- Indicates that the target is capable of asynchronous command
- execution, which means that GDB will accept further commands while
- the target is running.
-
-`reverse'
- Indicates that the target is capable of reverse execution. *Note
- Reverse Execution::, for more information.
-
-
-The `-list-thread-groups' Command
----------------------------------
-
-Synopsis
---------
-
- -list-thread-groups [ --available ] [ --recurse 1 ] [ GROUP ... ]
-
- Lists thread groups (*note Thread groups::). When a single thread
-group is passed as the argument, lists the children of that group.
-When several thread group are passed, lists information about those
-thread groups. Without any parameters, lists information about all
-top-level thread groups.
-
- Normally, thread groups that are being debugged are reported. With
-the `--available' option, GDB reports thread groups available on the
-target.
-
- The output of this command may have either a `threads' result or a
-`groups' result. The `thread' result has a list of tuples as value,
-with each tuple describing a thread (*note GDB/MI Thread
-Information::). The `groups' result has a list of tuples as value,
-each tuple describing a thread group. If top-level groups are
-requested (that is, no parameter is passed), or when several groups are
-passed, the output always has a `groups' result. The format of the
-`group' result is described below.
-
- To reduce the number of roundtrips it's possible to list thread
-groups together with their children, by passing the `--recurse' option
-and the recursion depth. Presently, only recursion depth of 1 is
-permitted. If this option is present, then every reported thread group
-will also include its children, either as `group' or `threads' field.
-
- In general, any combination of option and parameters is permitted,
-with the following caveats:
-
- * When a single thread group is passed, the output will typically be
- the `threads' result. Because threads may not contain anything,
- the `recurse' option will be ignored.
-
- * When the `--available' option is passed, limited information may
- be available. In particular, the list of threads of a process
- might be inaccessible. Further, specifying specific thread groups
- might not give any performance advantage over listing all thread
- groups. The frontend should assume that `-list-thread-groups
- --available' is always an expensive operation and cache the
- results.
-
-
- The `groups' result is a list of tuples, where each tuple may have
-the following fields:
-
-`id'
- Identifier of the thread group. This field is always present.
- The identifier is an opaque string; frontends should not try to
- convert it to an integer, even though it might look like one.
-
-`type'
- The type of the thread group. At present, only `process' is a
- valid type.
-
-`pid'
- The target-specific process identifier. This field is only present
- for thread groups of type `process' and only if the process exists.
-
-`num_children'
- The number of children this thread group has. This field may be
- absent for an available thread group.
-
-`threads'
- This field has a list of tuples as value, each tuple describing a
- thread. It may be present if the `--recurse' option is specified,
- and it's actually possible to obtain the threads.
-
-`cores'
- This field is a list of integers, each identifying a core that one
- thread of the group is running on. This field may be absent if
- such information is not available.
-
-`executable'
- The name of the executable file that corresponds to this thread
- group. The field is only present for thread groups of type
- `process', and only if there is a corresponding executable file.
-
-
-Example
--------
-
- gdb
- -list-thread-groups
- ^done,groups=[{id="17",type="process",pid="yyy",num_children="2"}]
- -list-thread-groups 17
- ^done,threads=[{id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",
- frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",args=[]},state="running"},
- {id="1",target-id="Thread 0xb7e156b0 (LWP 21254)",
- frame={level="0",addr="0x0804891f",func="foo",args=[{name="i",value="10"}],
- file="/tmp/a.c",fullname="/tmp/a.c",line="158"},state="running"}]]
- -list-thread-groups --available
- ^done,groups=[{id="17",type="process",pid="yyy",num_children="2",cores=[1,2]}]
- -list-thread-groups --available --recurse 1
- ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2],
- threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]},
- {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]},..]
- -list-thread-groups --available --recurse 1 17 18
- ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2],
- threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]},
- {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]},...]
-
-The `-add-inferior' Command
----------------------------
-
-Synopsis
---------
-
- -add-inferior
-
- Creates a new inferior (*note Inferiors and Programs::). The created
-inferior is not associated with any executable. Such association may
-be established with the `-file-exec-and-symbols' command (*note GDB/MI
-File Commands::). The command response has a single field,
-`thread-group', whose value is the identifier of the thread group
-corresponding to the new inferior.
-
-Example
--------
-
- gdb
- -add-inferior
- ^done,thread-group="i3"
-
-The `-interpreter-exec' Command
--------------------------------
-
-Synopsis
---------
-
- -interpreter-exec INTERPRETER COMMAND
-Execute the specified COMMAND in the given INTERPRETER.
-
-GDB Command
------------
-
-The corresponding GDB command is `interpreter-exec'.
-
-Example
--------
-
- (gdb)
- -interpreter-exec console "break main"
- &"During symbol reading, couldn't parse type; debugger out of date?.\n"
- &"During symbol reading, bad structure-type format.\n"
- ~"Breakpoint 1 at 0x8074fc6: file ../../src/gdb/main.c, line 743.\n"
- ^done
- (gdb)
-
-The `-inferior-tty-set' Command
--------------------------------
-
-Synopsis
---------
-
- -inferior-tty-set /dev/pts/1
-
- Set terminal for future runs of the program being debugged.
-
-GDB Command
------------
-
-The corresponding GDB command is `set inferior-tty' /dev/pts/1.
-
-Example
--------
-
- (gdb)
- -inferior-tty-set /dev/pts/1
- ^done
- (gdb)
-
-The `-inferior-tty-show' Command
---------------------------------
-
-Synopsis
---------
-
- -inferior-tty-show
-
- Show terminal for future runs of program being debugged.
-
-GDB Command
------------
-
-The corresponding GDB command is `show inferior-tty'.
-
-Example
--------
-
- (gdb)
- -inferior-tty-set /dev/pts/1
- ^done
- (gdb)
- -inferior-tty-show
- ^done,inferior_tty_terminal="/dev/pts/1"
- (gdb)
-
-The `-enable-timings' Command
------------------------------
-
-Synopsis
---------
-
- -enable-timings [yes | no]
-
- Toggle the printing of the wallclock, user and system times for an MI
-command as a field in its output. This command is to help frontend
-developers optimize the performance of their code. No argument is
-equivalent to `yes'.
-
-GDB Command
------------
-
-No equivalent.
-
-Example
--------
-
- (gdb)
- -enable-timings
- ^done
- (gdb)
- -break-insert main
- ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
- addr="0x080484ed",func="main",file="myprog.c",
- fullname="/home/nickrob/myprog.c",line="73",times="0"},
- time={wallclock="0.05185",user="0.00800",system="0.00000"}
- (gdb)
- -enable-timings no
- ^done
- (gdb)
- -exec-run
- ^running
- (gdb)
- *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",thread-id="0",
- frame={addr="0x080484ed",func="main",args=[{name="argc",value="1"},
- {name="argv",value="0xbfb60364"}],file="myprog.c",
- fullname="/home/nickrob/myprog.c",line="73"}
- (gdb)
-
-
-File: gdb.info, Node: Annotations, Next: JIT Interface, Prev: GDB/MI, Up: Top
-
-28 GDB Annotations
-******************
-
-This chapter describes annotations in GDB. Annotations were designed
-to interface GDB to graphical user interfaces or other similar programs
-which want to interact with GDB at a relatively high level.
-
- The annotation mechanism has largely been superseded by GDB/MI
-(*note GDB/MI::).
-
-* Menu:
-
-* Annotations Overview:: What annotations are; the general syntax.
-* Server Prefix:: Issuing a command without affecting user state.
-* Prompting:: Annotations marking GDB's need for input.
-* Errors:: Annotations for error messages.
-* Invalidation:: Some annotations describe things now invalid.
-* Annotations for Running::
- Whether the program is running, how it stopped, etc.
-* Source Annotations:: Annotations describing source code.
-
-
-File: gdb.info, Node: Annotations Overview, Next: Server Prefix, Up: Annotations
-
-28.1 What is an Annotation?
-===========================
-
-Annotations start with a newline character, two `control-z' characters,
-and the name of the annotation. If there is no additional information
-associated with this annotation, the name of the annotation is followed
-immediately by a newline. If there is additional information, the name
-of the annotation is followed by a space, the additional information,
-and a newline. The additional information cannot contain newline
-characters.
-
- Any output not beginning with a newline and two `control-z'
-characters denotes literal output from GDB. Currently there is no need
-for GDB to output a newline followed by two `control-z' characters, but
-if there was such a need, the annotations could be extended with an
-`escape' annotation which means those three characters as output.
-
- The annotation LEVEL, which is specified using the `--annotate'
-command line option (*note Mode Options::), controls how much
-information GDB prints together with its prompt, values of expressions,
-source lines, and other types of output. Level 0 is for no
-annotations, level 1 is for use when GDB is run as a subprocess of GNU
-Emacs, level 3 is the maximum annotation suitable for programs that
-control GDB, and level 2 annotations have been made obsolete (*note
-Limitations of the Annotation Interface: (annotate)Limitations.).
-
-`set annotate LEVEL'
- The GDB command `set annotate' sets the level of annotations to
- the specified LEVEL.
-
-`show annotate'
- Show the current annotation level.
-
- This chapter describes level 3 annotations.
-
- A simple example of starting up GDB with annotations is:
-
- $ gdb --annotate=3
- GNU gdb 6.0
- Copyright 2003 Free Software Foundation, Inc.
- GDB is free software, covered by the GNU General Public License,
- and you are welcome to change it and/or distribute copies of it
- under certain conditions.
- Type "show copying" to see the conditions.
- There is absolutely no warranty for GDB. Type "show warranty"
- for details.
- This GDB was configured as "i386-pc-linux-gnu"
-
- ^Z^Zpre-prompt
- (gdb)
- ^Z^Zprompt
- quit
-
- ^Z^Zpost-prompt
- $
-
- Here `quit' is input to GDB; the rest is output from GDB. The three
-lines beginning `^Z^Z' (where `^Z' denotes a `control-z' character) are
-annotations; the rest is output from GDB.
-
-
-File: gdb.info, Node: Server Prefix, Next: Prompting, Prev: Annotations Overview, Up: Annotations
-
-28.2 The Server Prefix
-======================
-
-If you prefix a command with `server ' then it will not affect the
-command history, nor will it affect GDB's notion of which command to
-repeat if <RET> is pressed on a line by itself. This means that
-commands can be run behind a user's back by a front-end in a
-transparent manner.
-
- The `server ' prefix does not affect the recording of values into
-the value history; to print a value without recording it into the value
-history, use the `output' command instead of the `print' command.
-
- Using this prefix also disables confirmation requests (*note
-confirmation requests::).
-
-
-File: gdb.info, Node: Prompting, Next: Errors, Prev: Server Prefix, Up: Annotations
-
-28.3 Annotation for GDB Input
-=============================
-
-When GDB prompts for input, it annotates this fact so it is possible to
-know when to send output, when the output from a given command is over,
-etc.
-
- Different kinds of input each have a different "input type". Each
-input type has three annotations: a `pre-' annotation, which denotes
-the beginning of any prompt which is being output, a plain annotation,
-which denotes the end of the prompt, and then a `post-' annotation
-which denotes the end of any echo which may (or may not) be associated
-with the input. For example, the `prompt' input type features the
-following annotations:
-
- ^Z^Zpre-prompt
- ^Z^Zprompt
- ^Z^Zpost-prompt
-
- The input types are
-
-`prompt'
- When GDB is prompting for a command (the main GDB prompt).
-
-`commands'
- When GDB prompts for a set of commands, like in the `commands'
- command. The annotations are repeated for each command which is
- input.
-
-`overload-choice'
- When GDB wants the user to select between various overloaded
- functions.
-
-`query'
- When GDB wants the user to confirm a potentially dangerous
- operation.
-
-`prompt-for-continue'
- When GDB is asking the user to press return to continue. Note:
- Don't expect this to work well; instead use `set height 0' to
- disable prompting. This is because the counting of lines is buggy
- in the presence of annotations.
-
-
-File: gdb.info, Node: Errors, Next: Invalidation, Prev: Prompting, Up: Annotations
-
-28.4 Errors
-===========
-
- ^Z^Zquit
-
- This annotation occurs right before GDB responds to an interrupt.
-
- ^Z^Zerror
-
- This annotation occurs right before GDB responds to an error.
-
- Quit and error annotations indicate that any annotations which GDB
-was in the middle of may end abruptly. For example, if a
-`value-history-begin' annotation is followed by a `error', one cannot
-expect to receive the matching `value-history-end'. One cannot expect
-not to receive it either, however; an error annotation does not
-necessarily mean that GDB is immediately returning all the way to the
-top level.
-
- A quit or error annotation may be preceded by
-
- ^Z^Zerror-begin
-
- Any output between that and the quit or error annotation is the error
-message.
-
- Warning messages are not yet annotated.
-
-
-File: gdb.info, Node: Invalidation, Next: Annotations for Running, Prev: Errors, Up: Annotations
-
-28.5 Invalidation Notices
-=========================
-
-The following annotations say that certain pieces of state may have
-changed.
-
-`^Z^Zframes-invalid'
- The frames (for example, output from the `backtrace' command) may
- have changed.
-
-`^Z^Zbreakpoints-invalid'
- The breakpoints may have changed. For example, the user just
- added or deleted a breakpoint.
-
-
-File: gdb.info, Node: Annotations for Running, Next: Source Annotations, Prev: Invalidation, Up: Annotations
-
-28.6 Running the Program
-========================
-
-When the program starts executing due to a GDB command such as `step'
-or `continue',
-
- ^Z^Zstarting
-
- is output. When the program stops,
-
- ^Z^Zstopped
-
- is output. Before the `stopped' annotation, a variety of
-annotations describe how the program stopped.
-
-`^Z^Zexited EXIT-STATUS'
- The program exited, and EXIT-STATUS is the exit status (zero for
- successful exit, otherwise nonzero).
-
-`^Z^Zsignalled'
- The program exited with a signal. After the `^Z^Zsignalled', the
- annotation continues:
-
- INTRO-TEXT
- ^Z^Zsignal-name
- NAME
- ^Z^Zsignal-name-end
- MIDDLE-TEXT
- ^Z^Zsignal-string
- STRING
- ^Z^Zsignal-string-end
- END-TEXT
-
- where NAME is the name of the signal, such as `SIGILL' or
- `SIGSEGV', and STRING is the explanation of the signal, such as
- `Illegal Instruction' or `Segmentation fault'. INTRO-TEXT,
- MIDDLE-TEXT, and END-TEXT are for the user's benefit and have no
- particular format.
-
-`^Z^Zsignal'
- The syntax of this annotation is just like `signalled', but GDB is
- just saying that the program received the signal, not that it was
- terminated with it.
-
-`^Z^Zbreakpoint NUMBER'
- The program hit breakpoint number NUMBER.
-
-`^Z^Zwatchpoint NUMBER'
- The program hit watchpoint number NUMBER.
-
-
-File: gdb.info, Node: Source Annotations, Prev: Annotations for Running, Up: Annotations
-
-28.7 Displaying Source
-======================
-
-The following annotation is used instead of displaying source code:
-
- ^Z^Zsource FILENAME:LINE:CHARACTER:MIDDLE:ADDR
-
- where FILENAME is an absolute file name indicating which source
-file, LINE is the line number within that file (where 1 is the first
-line in the file), CHARACTER is the character position within the file
-(where 0 is the first character in the file) (for most debug formats
-this will necessarily point to the beginning of a line), MIDDLE is
-`middle' if ADDR is in the middle of the line, or `beg' if ADDR is at
-the beginning of the line, and ADDR is the address in the target
-program associated with the source which is being displayed. ADDR is
-in the form `0x' followed by one or more lowercase hex digits (note
-that this does not depend on the language).
-
-
-File: gdb.info, Node: JIT Interface, Next: GDB Bugs, Prev: Annotations, Up: Top
-
-29 JIT Compilation Interface
-****************************
-
-This chapter documents GDB's "just-in-time" (JIT) compilation
-interface. A JIT compiler is a program or library that generates native
-executable code at runtime and executes it, usually in order to achieve
-good performance while maintaining platform independence.
-
- Programs that use JIT compilation are normally difficult to debug
-because portions of their code are generated at runtime, instead of
-being loaded from object files, which is where GDB normally finds the
-program's symbols and debug information. In order to debug programs
-that use JIT compilation, GDB has an interface that allows the program
-to register in-memory symbol files with GDB at runtime.
-
- If you are using GDB to debug a program that uses this interface,
-then it should work transparently so long as you have not stripped the
-binary. If you are developing a JIT compiler, then the interface is
-documented in the rest of this chapter. At this time, the only known
-client of this interface is the LLVM JIT.
-
- Broadly speaking, the JIT interface mirrors the dynamic loader
-interface. The JIT compiler communicates with GDB by writing data into
-a global variable and calling a fuction at a well-known symbol. When
-GDB attaches, it reads a linked list of symbol files from the global
-variable to find existing code, and puts a breakpoint in the function
-so that it can find out about additional code.
-
-* Menu:
-
-* Declarations:: Relevant C struct declarations
-* Registering Code:: Steps to register code
-* Unregistering Code:: Steps to unregister code
-
-
-File: gdb.info, Node: Declarations, Next: Registering Code, Up: JIT Interface
-
-29.1 JIT Declarations
-=====================
-
-These are the relevant struct declarations that a C program should
-include to implement the interface:
-
- typedef enum
- {
- JIT_NOACTION = 0,
- JIT_REGISTER_FN,
- JIT_UNREGISTER_FN
- } jit_actions_t;
-
- struct jit_code_entry
- {
- struct jit_code_entry *next_entry;
- struct jit_code_entry *prev_entry;
- const char *symfile_addr;
- uint64_t symfile_size;
- };
-
- struct jit_descriptor
- {
- uint32_t version;
- /* This type should be jit_actions_t, but we use uint32_t
- to be explicit about the bitwidth. */
- uint32_t action_flag;
- struct jit_code_entry *relevant_entry;
- struct jit_code_entry *first_entry;
- };
-
- /* GDB puts a breakpoint in this function. */
- void __attribute__((noinline)) __jit_debug_register_code() { };
-
- /* Make sure to specify the version statically, because the
- debugger may check the version before we can set it. */
- struct jit_descriptor __jit_debug_descriptor = { 1, 0, 0, 0 };
-
- If the JIT is multi-threaded, then it is important that the JIT
-synchronize any modifications to this global data properly, which can
-easily be done by putting a global mutex around modifications to these
-structures.
-
-
-File: gdb.info, Node: Registering Code, Next: Unregistering Code, Prev: Declarations, Up: JIT Interface
-
-29.2 Registering Code
-=====================
-
-To register code with GDB, the JIT should follow this protocol:
-
- * Generate an object file in memory with symbols and other desired
- debug information. The file must include the virtual addresses of
- the sections.
-
- * Create a code entry for the file, which gives the start and size
- of the symbol file.
-
- * Add it to the linked list in the JIT descriptor.
-
- * Point the relevant_entry field of the descriptor at the entry.
-
- * Set `action_flag' to `JIT_REGISTER' and call
- `__jit_debug_register_code'.
-
- When GDB is attached and the breakpoint fires, GDB uses the
-`relevant_entry' pointer so it doesn't have to walk the list looking for
-new code. However, the linked list must still be maintained in order
-to allow GDB to attach to a running process and still find the symbol
-files.
-
-
-File: gdb.info, Node: Unregistering Code, Prev: Registering Code, Up: JIT Interface
-
-29.3 Unregistering Code
-=======================
-
-If code is freed, then the JIT should use the following protocol:
-
- * Remove the code entry corresponding to the code from the linked
- list.
-
- * Point the `relevant_entry' field of the descriptor at the code
- entry.
-
- * Set `action_flag' to `JIT_UNREGISTER' and call
- `__jit_debug_register_code'.
-
- If the JIT frees or recompiles code without unregistering it, then
-GDB and the JIT will leak the memory used for the associated symbol
-files.
-
-
-File: gdb.info, Node: GDB Bugs, Next: Command Line Editing, Prev: JIT Interface, Up: Top
-
-30 Reporting Bugs in GDB
-************************
-
-Your bug reports play an essential role in making GDB 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 GDB work
-better. Bug reports are your contribution to the maintenance of GDB.
-
- 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
-
-
-File: gdb.info, Node: Bug Criteria, Next: Bug Reporting, Up: GDB Bugs
-
-30.1 Have You Found a Bug?
-==========================
-
-If you are not sure whether you have found a bug, here are some
-guidelines:
-
- * If the debugger gets a fatal signal, for any input whatever, that
- is a GDB bug. Reliable debuggers never crash.
-
- * If GDB produces an error message for valid input, that is a bug.
- (Note that if you're cross debugging, the problem may also be
- somewhere in the connection to the target.)
-
- * If GDB 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".
-
- * If you are an experienced user of debugging tools, your suggestions
- for improvement of GDB are welcome in any case.
-
-
-File: gdb.info, Node: Bug Reporting, Prev: Bug Criteria, Up: GDB Bugs
-
-30.2 How to Report Bugs
-=======================
-
-A number of companies and individuals offer support for GNU products.
-If you obtained GDB 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 `etc/SERVICE' in the GNU Emacs distribution.
-
- In any event, we also recommend that you submit bug reports for GDB.
-The preferred method is to submit them directly using GDB's Bugs web
-page (http://www.gnu.org/software/gdb/bugs/). Alternatively, the
-e-mail gateway <bug-gdb@gnu.org> can be used.
-
- *Do not send bug reports to `info-gdb', or to `help-gdb', or to any
-newsgroups.* Most users of GDB do not want to receive bug reports.
-Those that do have arranged to receive `bug-gdb'.
-
- The mailing list `bug-gdb' has a newsgroup `gnu.gdb.bug' which
-serves as a repeater. The mailing list and the newsgroup carry exactly
-the same messages. Often people think of posting bug reports to the
-newsgroup instead of mailing them. This appears to work, but it has one
-problem which can be crucial: a newsgroup posting often lacks a mail
-path back to the sender. Thus, if we need to ask for more information,
-we may be unable to reach you. For this reason, it is better to send
-bug reports to the mailing list.
-
- The fundamental principle of reporting bugs usefully is this:
-*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 the variable 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 debugger 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. It may be that the bug has been reported previously, but
-neither you nor we can know that unless your bug report is complete and
-self-contained.
-
- Sometimes people give a few sketchy facts and ask, "Does this ring a
-bell?" Those bug reports are useless, and we urge everyone to _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:
-
- * The version of GDB. GDB announces it if you start with no
- arguments; you can also print it at any time using `show version'.
-
- Without this, we will not know whether there is any point in
- looking for the bug in the current version of GDB.
-
- * The type of machine you are using, and the operating system name
- and version number.
-
- * What compiler (and its version) was used to compile GDB--e.g.
- "gcc-2.8.1".
-
- * What compiler (and its version) was used to compile the program
- you are debugging--e.g. "gcc-2.8.1", or "HP92453-01 A.10.32.03 HP
- C Compiler". For GCC, you can say `gcc --version' to get this
- information; for other compilers, see the documentation for those
- compilers.
-
- * The command arguments you gave the compiler to compile your
- example and observe the bug. For example, did you use `-O'? 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.
-
- * A complete input script, and all necessary source files, that will
- reproduce the bug.
-
- * 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 GDB 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 GDB 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.
-
- To collect all this information, you can use a session recording
- program such as `script', which is available on many Unix systems.
- Just run your GDB session inside `script' and then include the
- `typescript' file with your bug report.
-
- Another way to record a GDB session is to run GDB inside Emacs and
- then save the entire buffer to a file.
-
- * If you wish to suggest changes to the GDB source, send us context
- diffs. If you even discuss something in the GDB 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.
-
-
- Here are some things that are not necessary:
-
- * 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 _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.
-
- * 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 GDB 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.
-
- * 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.
-
-
-File: gdb.info, Node: Command Line Editing, Next: Using History Interactively, Prev: GDB Bugs, Up: Top
-
-31 Command Line Editing
-***********************
-
-This chapter describes the basic features of the GNU command line
-editing interface.
-
-* Menu:
-
-* Introduction and Notation:: Notation used in this text.
-* Readline Interaction:: The minimum set of commands for editing a line.
-* Readline Init File:: Customizing Readline from a user's view.
-* Bindable Readline Commands:: A description of most of the Readline commands
- available for binding
-* Readline vi Mode:: A short description of how to make Readline
- behave like the vi editor.
-
-
-File: gdb.info, Node: Introduction and Notation, Next: Readline Interaction, Up: Command Line Editing
-
-31.1 Introduction to Line Editing
-=================================
-
-The following paragraphs describe the notation used to represent
-keystrokes.
-
- The text `C-k' is read as `Control-K' and describes the character
-produced when the <k> key is pressed while the Control key is depressed.
-
- The text `M-k' is read as `Meta-K' and describes the character
-produced when the Meta key (if you have one) is depressed, and the <k>
-key is pressed. The Meta key is labeled <ALT> on many keyboards. On
-keyboards with two keys labeled <ALT> (usually to either side of the
-space bar), the <ALT> on the left side is generally set to work as a
-Meta key. The <ALT> key on the right may also be configured to work as
-a Meta key or may be configured as some other modifier, such as a
-Compose key for typing accented characters.
-
- If you do not have a Meta or <ALT> key, or another key working as a
-Meta key, the identical keystroke can be generated by typing <ESC>
-_first_, and then typing <k>. Either process is known as "metafying"
-the <k> key.
-
- The text `M-C-k' is read as `Meta-Control-k' and describes the
-character produced by "metafying" `C-k'.
-
- In addition, several keys have their own names. Specifically,
-<DEL>, <ESC>, <LFD>, <SPC>, <RET>, and <TAB> all stand for themselves
-when seen in this text, or in an init file (*note Readline Init File::).
-If your keyboard lacks a <LFD> key, typing <C-j> will produce the
-desired character. The <RET> key may be labeled <Return> or <Enter> on
-some keyboards.
-
-
-File: gdb.info, Node: Readline Interaction, Next: Readline Init File, Prev: Introduction and Notation, Up: Command Line Editing
-
-31.2 Readline Interaction
-=========================
-
-Often during an interactive session you type in a long line of text,
-only to notice that the first word on the line is misspelled. The
-Readline library gives you a set of commands for manipulating the text
-as you type it in, allowing you to just fix your typo, and not forcing
-you to retype the majority of the line. Using these editing commands,
-you move the cursor to the place that needs correction, and delete or
-insert the text of the corrections. Then, when you are satisfied with
-the line, you simply press <RET>. You do not have to be at the end of
-the line to press <RET>; the entire line is accepted regardless of the
-location of the cursor within the line.
-
-* Menu:
-
-* Readline Bare Essentials:: The least you need to know about Readline.
-* Readline Movement Commands:: Moving about the input line.
-* Readline Killing Commands:: How to delete text, and how to get it back!
-* Readline Arguments:: Giving numeric arguments to commands.
-* Searching:: Searching through previous lines.
-
-
-File: gdb.info, Node: Readline Bare Essentials, Next: Readline Movement Commands, Up: Readline Interaction
-
-31.2.1 Readline Bare Essentials
--------------------------------
-
-In order to enter characters into the line, simply type them. The typed
-character appears where the cursor was, and then the cursor moves one
-space to the right. If you mistype a character, you can use your erase
-character to back up and delete the mistyped character.
-
- Sometimes you may mistype a character, and not notice the error
-until you have typed several other characters. In that case, you can
-type `C-b' to move the cursor to the left, and then correct your
-mistake. Afterwards, you can move the cursor to the right with `C-f'.
-
- When you add text in the middle of a line, you will notice that
-characters to the right of the cursor are `pushed over' to make room
-for the text that you have inserted. Likewise, when you delete text
-behind the cursor, characters to the right of the cursor are `pulled
-back' to fill in the blank space created by the removal of the text. A
-list of the bare essentials for editing the text of an input line
-follows.
-
-`C-b'
- Move back one character.
-
-`C-f'
- Move forward one character.
-
-<DEL> or <Backspace>
- Delete the character to the left of the cursor.
-
-`C-d'
- Delete the character underneath the cursor.
-
-Printing characters
- Insert the character into the line at the cursor.
-
-`C-_' or `C-x C-u'
- Undo the last editing command. You can undo all the way back to an
- empty line.
-
-(Depending on your configuration, the <Backspace> key be set to delete
-the character to the left of the cursor and the <DEL> key set to delete
-the character underneath the cursor, like `C-d', rather than the
-character to the left of the cursor.)
-
-
-File: gdb.info, Node: Readline Movement Commands, Next: Readline Killing Commands, Prev: Readline Bare Essentials, Up: Readline Interaction
-
-31.2.2 Readline Movement Commands
----------------------------------
-
-The above table describes the most basic keystrokes that you need in
-order to do editing of the input line. For your convenience, many
-other commands have been added in addition to `C-b', `C-f', `C-d', and
-<DEL>. Here are some commands for moving more rapidly about the line.
-
-`C-a'
- Move to the start of the line.
-
-`C-e'
- Move to the end of the line.
-
-`M-f'
- Move forward a word, where a word is composed of letters and
- digits.
-
-`M-b'
- Move backward a word.
-
-`C-l'
- Clear the screen, reprinting the current line at the top.
-
- Notice how `C-f' moves forward a character, while `M-f' moves
-forward a word. It is a loose convention that control keystrokes
-operate on characters while meta keystrokes operate on words.
-
-
-File: gdb.info, Node: Readline Killing Commands, Next: Readline Arguments, Prev: Readline Movement Commands, Up: Readline Interaction
-
-31.2.3 Readline Killing Commands
---------------------------------
-
-"Killing" text means to delete the text from the line, but to save it
-away for later use, usually by "yanking" (re-inserting) it back into
-the line. (`Cut' and `paste' are more recent jargon for `kill' and
-`yank'.)
-
- If the description for a command says that it `kills' text, then you
-can be sure that you can get the text back in a different (or the same)
-place later.
-
- When you use a kill command, the text is saved in a "kill-ring".
-Any number of consecutive kills save all of the killed text together, so
-that when you yank it back, you get it all. The kill ring is not line
-specific; the text that you killed on a previously typed line is
-available to be yanked back later, when you are typing another line.
-
- Here is the list of commands for killing text.
-
-`C-k'
- Kill the text from the current cursor position to the end of the
- line.
-
-`M-d'
- Kill from the cursor to the end of the current word, or, if between
- words, to the end of the next word. Word boundaries are the same
- as those used by `M-f'.
-
-`M-<DEL>'
- Kill from the cursor the start of the current word, or, if between
- words, to the start of the previous word. Word boundaries are the
- same as those used by `M-b'.
-
-`C-w'
- Kill from the cursor to the previous whitespace. This is
- different than `M-<DEL>' because the word boundaries differ.
-
-
- Here is how to "yank" the text back into the line. Yanking means to
-copy the most-recently-killed text from the kill buffer.
-
-`C-y'
- Yank the most recently killed text back into the buffer at the
- cursor.
-
-`M-y'
- Rotate the kill-ring, and yank the new top. You can only do this
- if the prior command is `C-y' or `M-y'.
-
-
-File: gdb.info, Node: Readline Arguments, Next: Searching, Prev: Readline Killing Commands, Up: Readline Interaction
-
-31.2.4 Readline Arguments
--------------------------
-
-You can pass numeric arguments to Readline commands. Sometimes the
-argument acts as a repeat count, other times it is the sign of the
-argument that is significant. If you pass a negative argument to a
-command which normally acts in a forward direction, that command will
-act in a backward direction. For example, to kill text back to the
-start of the line, you might type `M-- C-k'.
-
- The general way to pass numeric arguments to a command is to type
-meta digits before the command. If the first `digit' typed is a minus
-sign (`-'), then the sign of the argument will be negative. Once you
-have typed one meta digit to get the argument started, you can type the
-remainder of the digits, and then the command. For example, to give
-the `C-d' command an argument of 10, you could type `M-1 0 C-d', which
-will delete the next ten characters on the input line.
-
-
-File: gdb.info, Node: Searching, Prev: Readline Arguments, Up: Readline Interaction
-
-31.2.5 Searching for Commands in the History
---------------------------------------------
-
-Readline provides commands for searching through the command history
-for lines containing a specified string. There are two search modes:
-"incremental" and "non-incremental".
-
- Incremental searches begin before the user has finished typing the
-search string. As each character of the search string is typed,
-Readline displays the next entry from the history matching the string
-typed so far. An incremental search requires only as many characters
-as needed to find the desired history entry. To search backward in the
-history for a particular string, type `C-r'. Typing `C-s' searches
-forward through the history. The characters present in the value of
-the `isearch-terminators' variable are used to terminate an incremental
-search. If that variable has not been assigned a value, the <ESC> and
-`C-J' characters will terminate an incremental search. `C-g' will
-abort an incremental search and restore the original line. When the
-search is terminated, the history entry containing the search string
-becomes the current line.
-
- To find other matching entries in the history list, type `C-r' or
-`C-s' as appropriate. This will search backward or forward in the
-history for the next entry matching the search string typed so far.
-Any other key sequence bound to a Readline command will terminate the
-search and execute that command. For instance, a <RET> will terminate
-the search and accept the line, thereby executing the command from the
-history list. A movement command will terminate the search, make the
-last line found the current line, and begin editing.
-
- Readline remembers the last incremental search string. If two
-`C-r's are typed without any intervening characters defining a new
-search string, any remembered search string is used.
-
- Non-incremental searches read the entire search string before
-starting to search for matching history lines. The search string may be
-typed by the user or be part of the contents of the current line.
-
-
-File: gdb.info, Node: Readline Init File, Next: Bindable Readline Commands, Prev: Readline Interaction, Up: Command Line Editing
-
-31.3 Readline Init File
-=======================
-
-Although the Readline library comes with a set of Emacs-like
-keybindings installed by default, it is possible to use a different set
-of keybindings. Any user can customize programs that use Readline by
-putting commands in an "inputrc" file, conventionally in his home
-directory. The name of this file is taken from the value of the
-environment variable `INPUTRC'. If that variable is unset, the default
-is `~/.inputrc'.
-
- When a program which uses the Readline library starts up, the init
-file is read, and the key bindings are set.
-
- In addition, the `C-x C-r' command re-reads this init file, thus
-incorporating any changes that you might have made to it.
-
-* Menu:
-
-* Readline Init File Syntax:: Syntax for the commands in the inputrc file.
-
-* Conditional Init Constructs:: Conditional key bindings in the inputrc file.
-
-* Sample Init File:: An example inputrc file.
-
-
-File: gdb.info, Node: Readline Init File Syntax, Next: Conditional Init Constructs, Up: Readline Init File
-
-31.3.1 Readline Init File Syntax
---------------------------------
-
-There are only a few basic constructs allowed in the Readline init
-file. Blank lines are ignored. Lines beginning with a `#' are
-comments. Lines beginning with a `$' indicate conditional constructs
-(*note Conditional Init Constructs::). Other lines denote variable
-settings and key bindings.
-
-Variable Settings
- You can modify the run-time behavior of Readline by altering the
- values of variables in Readline using the `set' command within the
- init file. The syntax is simple:
-
- set VARIABLE VALUE
-
- Here, for example, is how to change from the default Emacs-like
- key binding to use `vi' line editing commands:
-
- set editing-mode vi
-
- Variable names and values, where appropriate, are recognized
- without regard to case. Unrecognized variable names are ignored.
-
- Boolean variables (those that can be set to on or off) are set to
- on if the value is null or empty, ON (case-insensitive), or 1.
- Any other value results in the variable being set to off.
-
- A great deal of run-time behavior is changeable with the following
- variables.
-
- `bell-style'
- Controls what happens when Readline wants to ring the
- terminal bell. If set to `none', Readline never rings the
- bell. If set to `visible', Readline uses a visible bell if
- one is available. If set to `audible' (the default),
- Readline attempts to ring the terminal's bell.
-
- `bind-tty-special-chars'
- If set to `on', Readline attempts to bind the control
- characters treated specially by the kernel's terminal driver
- to their Readline equivalents.
-
- `comment-begin'
- The string to insert at the beginning of the line when the
- `insert-comment' command is executed. The default value is
- `"#"'.
-
- `completion-ignore-case'
- If set to `on', Readline performs filename matching and
- completion in a case-insensitive fashion. The default value
- is `off'.
-
- `completion-query-items'
- The number of possible completions that determines when the
- user is asked whether the list of possibilities should be
- displayed. If the number of possible completions is greater
- than this value, Readline will ask the user whether or not he
- wishes to view them; otherwise, they are simply listed. This
- variable must be set to an integer value greater than or
- equal to 0. A negative value means Readline should never ask.
- The default limit is `100'.
-
- `convert-meta'
- If set to `on', Readline will convert characters with the
- eighth bit set to an ASCII key sequence by stripping the
- eighth bit and prefixing an <ESC> character, converting them
- to a meta-prefixed key sequence. The default value is `on'.
-
- `disable-completion'
- If set to `On', Readline will inhibit word completion.
- Completion characters will be inserted into the line as if
- they had been mapped to `self-insert'. The default is `off'.
-
- `editing-mode'
- The `editing-mode' variable controls which default set of key
- bindings is used. By default, Readline starts up in Emacs
- editing mode, where the keystrokes are most similar to Emacs.
- This variable can be set to either `emacs' or `vi'.
-
- `enable-keypad'
- When set to `on', Readline will try to enable the application
- keypad when it is called. Some systems need this to enable
- the arrow keys. The default is `off'.
-
- `expand-tilde'
- If set to `on', tilde expansion is performed when Readline
- attempts word completion. The default is `off'.
-
- `history-preserve-point'
- If set to `on', the history code attempts to place point at
- the same location on each history line retrieved with
- `previous-history' or `next-history'. The default is `off'.
-
- `horizontal-scroll-mode'
- This variable can be set to either `on' or `off'. Setting it
- to `on' means that the text of the lines being edited will
- scroll horizontally on a single screen line when they are
- longer than the width of the screen, instead of wrapping onto
- a new screen line. By default, this variable is set to `off'.
-
- `input-meta'
- If set to `on', Readline will enable eight-bit input (it will
- not clear the eighth bit in the characters it reads),
- regardless of what the terminal claims it can support. The
- default value is `off'. The name `meta-flag' is a synonym
- for this variable.
-
- `isearch-terminators'
- The string of characters that should terminate an incremental
- search without subsequently executing the character as a
- command (*note Searching::). If this variable has not been
- given a value, the characters <ESC> and `C-J' will terminate
- an incremental search.
-
- `keymap'
- Sets Readline's idea of the current keymap for key binding
- commands. Acceptable `keymap' names are `emacs',
- `emacs-standard', `emacs-meta', `emacs-ctlx', `vi', `vi-move',
- `vi-command', and `vi-insert'. `vi' is equivalent to
- `vi-command'; `emacs' is equivalent to `emacs-standard'. The
- default value is `emacs'. The value of the `editing-mode'
- variable also affects the default keymap.
-
- `mark-directories'
- If set to `on', completed directory names have a slash
- appended. The default is `on'.
-
- `mark-modified-lines'
- This variable, when set to `on', causes Readline to display an
- asterisk (`*') at the start of history lines which have been
- modified. This variable is `off' by default.
-
- `mark-symlinked-directories'
- If set to `on', completed names which are symbolic links to
- directories have a slash appended (subject to the value of
- `mark-directories'). The default is `off'.
-
- `match-hidden-files'
- This variable, when set to `on', causes Readline to match
- files whose names begin with a `.' (hidden files) when
- performing filename completion, unless the leading `.' is
- supplied by the user in the filename to be completed. This
- variable is `on' by default.
-
- `output-meta'
- If set to `on', Readline will display characters with the
- eighth bit set directly rather than as a meta-prefixed escape
- sequence. The default is `off'.
-
- `page-completions'
- If set to `on', Readline uses an internal `more'-like pager
- to display a screenful of possible completions at a time.
- This variable is `on' by default.
-
- `print-completions-horizontally'
- If set to `on', Readline will display completions with matches
- sorted horizontally in alphabetical order, rather than down
- the screen. The default is `off'.
-
- `show-all-if-ambiguous'
- This alters the default behavior of the completion functions.
- If set to `on', words which have more than one possible
- completion cause the matches to be listed immediately instead
- of ringing the bell. The default value is `off'.
-
- `show-all-if-unmodified'
- This alters the default behavior of the completion functions
- in a fashion similar to SHOW-ALL-IF-AMBIGUOUS. If set to
- `on', words which have more than one possible completion
- without any possible partial completion (the possible
- completions don't share a common prefix) cause the matches to
- be listed immediately instead of ringing the bell. The
- default value is `off'.
-
- `visible-stats'
- If set to `on', a character denoting a file's type is
- appended to the filename when listing possible completions.
- The default is `off'.
-
-
-Key Bindings
- The syntax for controlling key bindings in the init file is
- simple. First you need to find the name of the command that you
- want to change. The following sections contain tables of the
- command name, the default keybinding, if any, and a short
- description of what the command does.
-
- Once you know the name of the command, simply place on a line in
- the init file the name of the key you wish to bind the command to,
- a colon, and then the name of the command. The name of the key
- can be expressed in different ways, depending on what you find most
- comfortable.
-
- In addition to command names, readline allows keys to be bound to
- a string that is inserted when the key is pressed (a MACRO).
-
- KEYNAME: FUNCTION-NAME or MACRO
- KEYNAME is the name of a key spelled out in English. For
- example:
- Control-u: universal-argument
- Meta-Rubout: backward-kill-word
- Control-o: "> output"
-
- In the above example, `C-u' is bound to the function
- `universal-argument', `M-DEL' is bound to the function
- `backward-kill-word', and `C-o' is bound to run the macro
- expressed on the right hand side (that is, to insert the text
- `> output' into the line).
-
- A number of symbolic character names are recognized while
- processing this key binding syntax: DEL, ESC, ESCAPE, LFD,
- NEWLINE, RET, RETURN, RUBOUT, SPACE, SPC, and TAB.
-
- "KEYSEQ": FUNCTION-NAME or MACRO
- KEYSEQ differs from KEYNAME above in that strings denoting an
- entire key sequence can be specified, by placing the key
- sequence in double quotes. Some GNU Emacs style key escapes
- can be used, as in the following example, but the special
- character names are not recognized.
-
- "\C-u": universal-argument
- "\C-x\C-r": re-read-init-file
- "\e[11~": "Function Key 1"
-
- In the above example, `C-u' is again bound to the function
- `universal-argument' (just as it was in the first example),
- `C-x C-r' is bound to the function `re-read-init-file', and
- `<ESC> <[> <1> <1> <~>' is bound to insert the text `Function
- Key 1'.
-
-
- The following GNU Emacs style escape sequences are available when
- specifying key sequences:
-
- `\C-'
- control prefix
-
- `\M-'
- meta prefix
-
- `\e'
- an escape character
-
- `\\'
- backslash
-
- `\"'
- <">, a double quotation mark
-
- `\''
- <'>, a single quote or apostrophe
-
- In addition to the GNU Emacs style escape sequences, a second set
- of backslash escapes is available:
-
- `\a'
- alert (bell)
-
- `\b'
- backspace
-
- `\d'
- delete
-
- `\f'
- form feed
-
- `\n'
- newline
-
- `\r'
- carriage return
-
- `\t'
- horizontal tab
-
- `\v'
- vertical tab
-
- `\NNN'
- the eight-bit character whose value is the octal value NNN
- (one to three digits)
-
- `\xHH'
- the eight-bit character whose value is the hexadecimal value
- HH (one or two hex digits)
-
- When entering the text of a macro, single or double quotes must be
- used to indicate a macro definition. Unquoted text is assumed to
- be a function name. In the macro body, the backslash escapes
- described above are expanded. Backslash will quote any other
- character in the macro text, including `"' and `''. For example,
- the following binding will make `C-x \' insert a single `\' into
- the line:
- "\C-x\\": "\\"
-
-
-
-File: gdb.info, Node: Conditional Init Constructs, Next: Sample Init File, Prev: Readline Init File Syntax, Up: Readline Init File
-
-31.3.2 Conditional Init Constructs
-----------------------------------
-
-Readline implements a facility similar in spirit to the conditional
-compilation features of the C preprocessor which allows key bindings
-and variable settings to be performed as the result of tests. There
-are four parser directives used.
-
-`$if'
- The `$if' construct allows bindings to be made based on the
- editing mode, the terminal being used, or the application using
- Readline. The text of the test extends to the end of the line; no
- characters are required to isolate it.
-
- `mode'
- The `mode=' form of the `$if' directive is used to test
- whether Readline is in `emacs' or `vi' mode. This may be
- used in conjunction with the `set keymap' command, for
- instance, to set bindings in the `emacs-standard' and
- `emacs-ctlx' keymaps only if Readline is starting out in
- `emacs' mode.
-
- `term'
- The `term=' form may be used to include terminal-specific key
- bindings, perhaps to bind the key sequences output by the
- terminal's function keys. The word on the right side of the
- `=' is tested against both the full name of the terminal and
- the portion of the terminal name before the first `-'. This
- allows `sun' to match both `sun' and `sun-cmd', for instance.
-
- `application'
- The APPLICATION construct is used to include
- application-specific settings. Each program using the
- Readline library sets the APPLICATION NAME, and you can test
- for a particular value. This could be used to bind key
- sequences to functions useful for a specific program. For
- instance, the following command adds a key sequence that
- quotes the current or previous word in Bash:
- $if Bash
- # Quote the current or previous word
- "\C-xq": "\eb\"\ef\""
- $endif
-
-`$endif'
- This command, as seen in the previous example, terminates an `$if'
- command.
-
-`$else'
- Commands in this branch of the `$if' directive are executed if the
- test fails.
-
-`$include'
- This directive takes a single filename as an argument and reads
- commands and bindings from that file. For example, the following
- directive reads from `/etc/inputrc':
- $include /etc/inputrc
-
-
-File: gdb.info, Node: Sample Init File, Prev: Conditional Init Constructs, Up: Readline Init File
-
-31.3.3 Sample Init File
------------------------
-
-Here is an example of an INPUTRC file. This illustrates key binding,
-variable assignment, and conditional syntax.
-
-
- # This file controls the behaviour of line input editing for
- # programs that use the GNU Readline library. Existing
- # programs include FTP, Bash, and GDB.
- #
- # You can re-read the inputrc file with C-x C-r.
- # Lines beginning with '#' are comments.
- #
- # First, include any systemwide bindings and variable
- # assignments from /etc/Inputrc
- $include /etc/Inputrc
-
- #
- # Set various bindings for emacs mode.
-
- set editing-mode emacs
-
- $if mode=emacs
-
- Meta-Control-h: backward-kill-word Text after the function name is ignored
-
- #
- # Arrow keys in keypad mode
- #
- #"\M-OD": backward-char
- #"\M-OC": forward-char
- #"\M-OA": previous-history
- #"\M-OB": next-history
- #
- # Arrow keys in ANSI mode
- #
- "\M-[D": backward-char
- "\M-[C": forward-char
- "\M-[A": previous-history
- "\M-[B": next-history
- #
- # Arrow keys in 8 bit keypad mode
- #
- #"\M-\C-OD": backward-char
- #"\M-\C-OC": forward-char
- #"\M-\C-OA": previous-history
- #"\M-\C-OB": next-history
- #
- # Arrow keys in 8 bit ANSI mode
- #
- #"\M-\C-[D": backward-char
- #"\M-\C-[C": forward-char
- #"\M-\C-[A": previous-history
- #"\M-\C-[B": next-history
-
- C-q: quoted-insert
-
- $endif
-
- # An old-style binding. This happens to be the default.
- TAB: complete
-
- # Macros that are convenient for shell interaction
- $if Bash
- # edit the path
- "\C-xp": "PATH=${PATH}\e\C-e\C-a\ef\C-f"
- # prepare to type a quoted word --
- # insert open and close double quotes
- # and move to just after the open quote
- "\C-x\"": "\"\"\C-b"
- # insert a backslash (testing backslash escapes
- # in sequences and macros)
- "\C-x\\": "\\"
- # Quote the current or previous word
- "\C-xq": "\eb\"\ef\""
- # Add a binding to refresh the line, which is unbound
- "\C-xr": redraw-current-line
- # Edit variable on current line.
- "\M-\C-v": "\C-a\C-k$\C-y\M-\C-e\C-a\C-y="
- $endif
-
- # use a visible bell if one is available
- set bell-style visible
-
- # don't strip characters to 7 bits when reading
- set input-meta on
-
- # allow iso-latin1 characters to be inserted rather
- # than converted to prefix-meta sequences
- set convert-meta off
-
- # display characters with the eighth bit set directly
- # rather than as meta-prefixed characters
- set output-meta on
-
- # if there are more than 150 possible completions for
- # a word, ask the user if he wants to see all of them
- set completion-query-items 150
-
- # For FTP
- $if Ftp
- "\C-xg": "get \M-?"
- "\C-xt": "put \M-?"
- "\M-.": yank-last-arg
- $endif
-
-
-File: gdb.info, Node: Bindable Readline Commands, Next: Readline vi Mode, Prev: Readline Init File, Up: Command Line Editing
-
-31.4 Bindable Readline Commands
-===============================
-
-* Menu:
-
-* Commands For Moving:: Moving about the line.
-* Commands For History:: Getting at previous lines.
-* Commands For Text:: Commands for changing text.
-* Commands For Killing:: Commands for killing and yanking.
-* Numeric Arguments:: Specifying numeric arguments, repeat counts.
-* Commands For Completion:: Getting Readline to do the typing for you.
-* Keyboard Macros:: Saving and re-executing typed characters
-* Miscellaneous Commands:: Other miscellaneous commands.
-
- This section describes Readline commands that may be bound to key
-sequences. Command names without an accompanying key sequence are
-unbound by default.
-
- In the following descriptions, "point" refers to the current cursor
-position, and "mark" refers to a cursor position saved by the
-`set-mark' command. The text between the point and mark is referred to
-as the "region".
-
-
-File: gdb.info, Node: Commands For Moving, Next: Commands For History, Up: Bindable Readline Commands
-
-31.4.1 Commands For Moving
---------------------------
-
-`beginning-of-line (C-a)'
- Move to the start of the current line.
-
-`end-of-line (C-e)'
- Move to the end of the line.
-
-`forward-char (C-f)'
- Move forward a character.
-
-`backward-char (C-b)'
- Move back a character.
-
-`forward-word (M-f)'
- Move forward to the end of the next word. Words are composed of
- letters and digits.
-
-`backward-word (M-b)'
- Move back to the start of the current or previous word. Words are
- composed of letters and digits.
-
-`clear-screen (C-l)'
- Clear the screen and redraw the current line, leaving the current
- line at the top of the screen.
-
-`redraw-current-line ()'
- Refresh the current line. By default, this is unbound.
-
-
-
-File: gdb.info, Node: Commands For History, Next: Commands For Text, Prev: Commands For Moving, Up: Bindable Readline Commands
-
-31.4.2 Commands For Manipulating The History
---------------------------------------------
-
-`accept-line (Newline or Return)'
- Accept the line regardless of where the cursor is. If this line is
- non-empty, it may be added to the history list for future recall
- with `add_history()'. If this line is a modified history line,
- the history line is restored to its original state.
-
-`previous-history (C-p)'
- Move `back' through the history list, fetching the previous
- command.
-
-`next-history (C-n)'
- Move `forward' through the history list, fetching the next command.
-
-`beginning-of-history (M-<)'
- Move to the first line in the history.
-
-`end-of-history (M->)'
- Move to the end of the input history, i.e., the line currently
- being entered.
-
-`reverse-search-history (C-r)'
- Search backward starting at the current line and moving `up'
- through the history as necessary. This is an incremental search.
-
-`forward-search-history (C-s)'
- Search forward starting at the current line and moving `down'
- through the the history as necessary. This is an incremental
- search.
-
-`non-incremental-reverse-search-history (M-p)'
- Search backward starting at the current line and moving `up'
- through the history as necessary using a non-incremental search
- for a string supplied by the user.
-
-`non-incremental-forward-search-history (M-n)'
- Search forward starting at the current line and moving `down'
- through the the history as necessary using a non-incremental search
- for a string supplied by the user.
-
-`history-search-forward ()'
- Search forward through the history for the string of characters
- between the start of the current line and the point. This is a
- non-incremental search. By default, this command is unbound.
-
-`history-search-backward ()'
- Search backward through the history for the string of characters
- between the start of the current line and the point. This is a
- non-incremental search. By default, this command is unbound.
-
-`yank-nth-arg (M-C-y)'
- Insert the first argument to the previous command (usually the
- second word on the previous line) at point. With an argument N,
- insert the Nth word from the previous command (the words in the
- previous command begin with word 0). A negative argument inserts
- the Nth word from the end of the previous command. Once the
- argument N is computed, the argument is extracted as if the `!N'
- history expansion had been specified.
-
-`yank-last-arg (M-. or M-_)'
- Insert last argument to the previous command (the last word of the
- previous history entry). With an argument, behave exactly like
- `yank-nth-arg'. Successive calls to `yank-last-arg' move back
- through the history list, inserting the last argument of each line
- in turn. The history expansion facilities are used to extract the
- last argument, as if the `!$' history expansion had been specified.
-
-
-
-File: gdb.info, Node: Commands For Text, Next: Commands For Killing, Prev: Commands For History, Up: Bindable Readline Commands
-
-31.4.3 Commands For Changing Text
----------------------------------
-
-`delete-char (C-d)'
- Delete the character at point. If point is at the beginning of
- the line, there are no characters in the line, and the last
- character typed was not bound to `delete-char', then return EOF.
-
-`backward-delete-char (Rubout)'
- Delete the character behind the cursor. A numeric argument means
- to kill the characters instead of deleting them.
-
-`forward-backward-delete-char ()'
- Delete the character under the cursor, unless the cursor is at the
- end of the line, in which case the character behind the cursor is
- deleted. By default, this is not bound to a key.
-
-`quoted-insert (C-q or C-v)'
- Add the next character typed to the line verbatim. This is how to
- insert key sequences like `C-q', for example.
-
-`tab-insert (M-<TAB>)'
- Insert a tab character.
-
-`self-insert (a, b, A, 1, !, ...)'
- Insert yourself.
-
-`transpose-chars (C-t)'
- Drag the character before the cursor forward over the character at
- the cursor, moving the cursor forward as well. If the insertion
- point is at the end of the line, then this transposes the last two
- characters of the line. Negative arguments have no effect.
-
-`transpose-words (M-t)'
- Drag the word before point past the word after point, moving point
- past that word as well. If the insertion point is at the end of
- the line, this transposes the last two words on the line.
-
-`upcase-word (M-u)'
- Uppercase the current (or following) word. With a negative
- argument, uppercase the previous word, but do not move the cursor.
-
-`downcase-word (M-l)'
- Lowercase the current (or following) word. With a negative
- argument, lowercase the previous word, but do not move the cursor.
-
-`capitalize-word (M-c)'
- Capitalize the current (or following) word. With a negative
- argument, capitalize the previous word, but do not move the cursor.
-
-`overwrite-mode ()'
- Toggle overwrite mode. With an explicit positive numeric argument,
- switches to overwrite mode. With an explicit non-positive numeric
- argument, switches to insert mode. This command affects only
- `emacs' mode; `vi' mode does overwrite differently. Each call to
- `readline()' starts in insert mode.
-
- In overwrite mode, characters bound to `self-insert' replace the
- text at point rather than pushing the text to the right.
- Characters bound to `backward-delete-char' replace the character
- before point with a space.
-
- By default, this command is unbound.
-
-
-
-File: gdb.info, Node: Commands For Killing, Next: Numeric Arguments, Prev: Commands For Text, Up: Bindable Readline Commands
-
-31.4.4 Killing And Yanking
---------------------------
-
-`kill-line (C-k)'
- Kill the text from point to the end of the line.
-
-`backward-kill-line (C-x Rubout)'
- Kill backward to the beginning of the line.
-
-`unix-line-discard (C-u)'
- Kill backward from the cursor to the beginning of the current line.
-
-`kill-whole-line ()'
- Kill all characters on the current line, no matter where point is.
- By default, this is unbound.
-
-`kill-word (M-d)'
- Kill from point to the end of the current word, or if between
- words, to the end of the next word. Word boundaries are the same
- as `forward-word'.
-
-`backward-kill-word (M-<DEL>)'
- Kill the word behind point. Word boundaries are the same as
- `backward-word'.
-
-`unix-word-rubout (C-w)'
- Kill the word behind point, using white space as a word boundary.
- The killed text is saved on the kill-ring.
-
-`unix-filename-rubout ()'
- Kill the word behind point, using white space and the slash
- character as the word boundaries. The killed text is saved on the
- kill-ring.
-
-`delete-horizontal-space ()'
- Delete all spaces and tabs around point. By default, this is
- unbound.
-
-`kill-region ()'
- Kill the text in the current region. By default, this command is
- unbound.
-
-`copy-region-as-kill ()'
- Copy the text in the region to the kill buffer, so it can be yanked
- right away. By default, this command is unbound.
-
-`copy-backward-word ()'
- Copy the word before point to the kill buffer. The word
- boundaries are the same as `backward-word'. By default, this
- command is unbound.
-
-`copy-forward-word ()'
- Copy the word following point to the kill buffer. The word
- boundaries are the same as `forward-word'. By default, this
- command is unbound.
-
-`yank (C-y)'
- Yank the top of the kill ring into the buffer at point.
-
-`yank-pop (M-y)'
- Rotate the kill-ring, and yank the new top. You can only do this
- if the prior command is `yank' or `yank-pop'.
-
-
-File: gdb.info, Node: Numeric Arguments, Next: Commands For Completion, Prev: Commands For Killing, Up: Bindable Readline Commands
-
-31.4.5 Specifying Numeric Arguments
------------------------------------
-
-`digit-argument (M-0, M-1, ... M--)'
- Add this digit to the argument already accumulating, or start a new
- argument. `M--' starts a negative argument.
-
-`universal-argument ()'
- This is another way to specify an argument. If this command is
- followed by one or more digits, optionally with a leading minus
- sign, those digits define the argument. If the command is
- followed by digits, executing `universal-argument' again ends the
- numeric argument, but is otherwise ignored. As a special case, if
- this command is immediately followed by a character that is
- neither a digit or minus sign, the argument count for the next
- command is multiplied by four. The argument count is initially
- one, so executing this function the first time makes the argument
- count four, a second time makes the argument count sixteen, and so
- on. By default, this is not bound to a key.
-
-
-File: gdb.info, Node: Commands For Completion, Next: Keyboard Macros, Prev: Numeric Arguments, Up: Bindable Readline Commands
-
-31.4.6 Letting Readline Type For You
-------------------------------------
-
-`complete (<TAB>)'
- Attempt to perform completion on the text before point. The
- actual completion performed is application-specific. The default
- is filename completion.
-
-`possible-completions (M-?)'
- List the possible completions of the text before point.
-
-`insert-completions (M-*)'
- Insert all completions of the text before point that would have
- been generated by `possible-completions'.
-
-`menu-complete ()'
- Similar to `complete', but replaces the word to be completed with
- a single match from the list of possible completions. Repeated
- execution of `menu-complete' steps through the list of possible
- completions, inserting each match in turn. At the end of the list
- of completions, the bell is rung (subject to the setting of
- `bell-style') and the original text is restored. An argument of N
- moves N positions forward in the list of matches; a negative
- argument may be used to move backward through the list. This
- command is intended to be bound to <TAB>, but is unbound by
- default.
-
-`delete-char-or-list ()'
- Deletes the character under the cursor if not at the beginning or
- end of the line (like `delete-char'). If at the end of the line,
- behaves identically to `possible-completions'. This command is
- unbound by default.
-
-
-
-File: gdb.info, Node: Keyboard Macros, Next: Miscellaneous Commands, Prev: Commands For Completion, Up: Bindable Readline Commands
-
-31.4.7 Keyboard Macros
-----------------------
-
-`start-kbd-macro (C-x ()'
- Begin saving the characters typed into the current keyboard macro.
-
-`end-kbd-macro (C-x ))'
- Stop saving the characters typed into the current keyboard macro
- and save the definition.
-
-`call-last-kbd-macro (C-x e)'
- Re-execute the last keyboard macro defined, by making the
- characters in the macro appear as if typed at the keyboard.
-
-
-
-File: gdb.info, Node: Miscellaneous Commands, Prev: Keyboard Macros, Up: Bindable Readline Commands
-
-31.4.8 Some Miscellaneous Commands
-----------------------------------
-
-`re-read-init-file (C-x C-r)'
- Read in the contents of the INPUTRC file, and incorporate any
- bindings or variable assignments found there.
-
-`abort (C-g)'
- Abort the current editing command and ring the terminal's bell
- (subject to the setting of `bell-style').
-
-`do-uppercase-version (M-a, M-b, M-X, ...)'
- If the metafied character X is lowercase, run the command that is
- bound to the corresponding uppercase character.
-
-`prefix-meta (<ESC>)'
- Metafy the next character typed. This is for keyboards without a
- meta key. Typing `<ESC> f' is equivalent to typing `M-f'.
-
-`undo (C-_ or C-x C-u)'
- Incremental undo, separately remembered for each line.
-
-`revert-line (M-r)'
- Undo all changes made to this line. This is like executing the
- `undo' command enough times to get back to the beginning.
-
-`tilde-expand (M-~)'
- Perform tilde expansion on the current word.
-
-`set-mark (C-@)'
- Set the mark to the point. If a numeric argument is supplied, the
- mark is set to that position.
-
-`exchange-point-and-mark (C-x C-x)'
- Swap the point with the mark. The current cursor position is set
- to the saved position, and the old cursor position is saved as the
- mark.
-
-`character-search (C-])'
- A character is read and point is moved to the next occurrence of
- that character. A negative count searches for previous
- occurrences.
-
-`character-search-backward (M-C-])'
- A character is read and point is moved to the previous occurrence
- of that character. A negative count searches for subsequent
- occurrences.
-
-`insert-comment (M-#)'
- Without a numeric argument, the value of the `comment-begin'
- variable is inserted at the beginning of the current line. If a
- numeric argument is supplied, this command acts as a toggle: if
- the characters at the beginning of the line do not match the value
- of `comment-begin', the value is inserted, otherwise the
- characters in `comment-begin' are deleted from the beginning of
- the line. In either case, the line is accepted as if a newline
- had been typed.
-
-`dump-functions ()'
- Print all of the functions and their key bindings to the Readline
- output stream. If a numeric argument is supplied, the output is
- formatted in such a way that it can be made part of an INPUTRC
- file. This command is unbound by default.
-
-`dump-variables ()'
- Print all of the settable variables and their values to the
- Readline output stream. If a numeric argument is supplied, the
- output is formatted in such a way that it can be made part of an
- INPUTRC file. This command is unbound by default.
-
-`dump-macros ()'
- Print all of the Readline key sequences bound to macros and the
- strings they output. If a numeric argument is supplied, the
- output is formatted in such a way that it can be made part of an
- INPUTRC file. This command is unbound by default.
-
-`emacs-editing-mode (C-e)'
- When in `vi' command mode, this causes a switch to `emacs' editing
- mode.
-
-`vi-editing-mode (M-C-j)'
- When in `emacs' editing mode, this causes a switch to `vi' editing
- mode.
-
-
-
-File: gdb.info, Node: Readline vi Mode, Prev: Bindable Readline Commands, Up: Command Line Editing
-
-31.5 Readline vi Mode
-=====================
-
-While the Readline library does not have a full set of `vi' editing
-functions, it does contain enough to allow simple editing of the line.
-The Readline `vi' mode behaves as specified in the POSIX 1003.2
-standard.
-
- In order to switch interactively between `emacs' and `vi' editing
-modes, use the command `M-C-j' (bound to emacs-editing-mode when in
-`vi' mode and to vi-editing-mode in `emacs' mode). The Readline
-default is `emacs' mode.
-
- When you enter a line in `vi' mode, you are already placed in
-`insertion' mode, as if you had typed an `i'. Pressing <ESC> switches
-you into `command' mode, where you can edit the text of the line with
-the standard `vi' movement keys, move to previous history lines with
-`k' and subsequent lines with `j', and so forth.
-
-
-File: gdb.info, Node: Using History Interactively, Next: In Memoriam, Prev: Command Line Editing, Up: Top
-
-32 Using History Interactively
-******************************
-
-This chapter describes how to use the GNU History Library interactively,
-from a user's standpoint. It should be considered a user's guide. For
-information on using the GNU History Library in other programs, see the
-GNU Readline Library Manual.
-
-* Menu:
-
-* History Interaction:: What it feels like using History as a user.
-
-
-File: gdb.info, Node: History Interaction, Up: Using History Interactively
-
-32.1 History Expansion
-======================
-
-The History library provides a history expansion feature that is similar
-to the history expansion provided by `csh'. This section describes the
-syntax used to manipulate the history information.
-
- History expansions introduce words from the history list into the
-input stream, making it easy to repeat commands, insert the arguments
-to a previous command into the current input line, or fix errors in
-previous commands quickly.
-
- History expansion takes place in two parts. The first is to
-determine which line from the history list should be used during
-substitution. The second is to select portions of that line for
-inclusion into the current one. The line selected from the history is
-called the "event", and the portions of that line that are acted upon
-are called "words". Various "modifiers" are available to manipulate
-the selected words. The line is broken into words in the same fashion
-that Bash does, so that several words surrounded by quotes are
-considered one word. History expansions are introduced by the
-appearance of the history expansion character, which is `!' by default.
-
-* Menu:
-
-* Event Designators:: How to specify which history line to use.
-* Word Designators:: Specifying which words are of interest.
-* Modifiers:: Modifying the results of substitution.
-
-
-File: gdb.info, Node: Event Designators, Next: Word Designators, Up: History Interaction
-
-32.1.1 Event Designators
-------------------------
-
-An event designator is a reference to a command line entry in the
-history list.
-
-`!'
- Start a history substitution, except when followed by a space, tab,
- the end of the line, or `='.
-
-`!N'
- Refer to command line N.
-
-`!-N'
- Refer to the command N lines back.
-
-`!!'
- Refer to the previous command. This is a synonym for `!-1'.
-
-`!STRING'
- Refer to the most recent command starting with STRING.
-
-`!?STRING[?]'
- Refer to the most recent command containing STRING. The trailing
- `?' may be omitted if the STRING is followed immediately by a
- newline.
-
-`^STRING1^STRING2^'
- Quick Substitution. Repeat the last command, replacing STRING1
- with STRING2. Equivalent to `!!:s/STRING1/STRING2/'.
-
-`!#'
- The entire command line typed so far.
-
-
-
-File: gdb.info, Node: Word Designators, Next: Modifiers, Prev: Event Designators, Up: History Interaction
-
-32.1.2 Word Designators
------------------------
-
-Word designators are used to select desired words from the event. A
-`:' separates the event specification from the word designator. It may
-be omitted if the word designator begins with a `^', `$', `*', `-', or
-`%'. Words are numbered from the beginning of the line, with the first
-word being denoted by 0 (zero). Words are inserted into the current
-line separated by single spaces.
-
- For example,
-
-`!!'
- designates the preceding command. When you type this, the
- preceding command is repeated in toto.
-
-`!!:$'
- designates the last argument of the preceding command. This may be
- shortened to `!$'.
-
-`!fi:2'
- designates the second argument of the most recent command starting
- with the letters `fi'.
-
- Here are the word designators:
-
-`0 (zero)'
- The `0'th word. For many applications, this is the command word.
-
-`N'
- The Nth word.
-
-`^'
- The first argument; that is, word 1.
-
-`$'
- The last argument.
-
-`%'
- The word matched by the most recent `?STRING?' search.
-
-`X-Y'
- A range of words; `-Y' abbreviates `0-Y'.
-
-`*'
- All of the words, except the `0'th. This is a synonym for `1-$'.
- It is not an error to use `*' if there is just one word in the
- event; the empty string is returned in that case.
-
-`X*'
- Abbreviates `X-$'
-
-`X-'
- Abbreviates `X-$' like `X*', but omits the last word.
-
-
- If a word designator is supplied without an event specification, the
-previous command is used as the event.
-
-
-File: gdb.info, Node: Modifiers, Prev: Word Designators, Up: History Interaction
-
-32.1.3 Modifiers
-----------------
-
-After the optional word designator, you can add a sequence of one or
-more of the following modifiers, each preceded by a `:'.
-
-`h'
- Remove a trailing pathname component, leaving only the head.
-
-`t'
- Remove all leading pathname components, leaving the tail.
-
-`r'
- Remove a trailing suffix of the form `.SUFFIX', leaving the
- basename.
-
-`e'
- Remove all but the trailing suffix.
-
-`p'
- Print the new command but do not execute it.
-
-`s/OLD/NEW/'
- Substitute NEW for the first occurrence of OLD in the event line.
- Any delimiter may be used in place of `/'. The delimiter may be
- quoted in OLD and NEW with a single backslash. If `&' appears in
- NEW, it is replaced by OLD. A single backslash will quote the
- `&'. The final delimiter is optional if it is the last character
- on the input line.
-
-`&'
- Repeat the previous substitution.
-
-`g'
-`a'
- Cause changes to be applied over the entire event line. Used in
- conjunction with `s', as in `gs/OLD/NEW/', or with `&'.
-
-`G'
- Apply the following `s' modifier once to each word in the event.
-
-
-
-File: gdb.info, Node: In Memoriam, Next: Formatting Documentation, Prev: Using History Interactively, Up: Top
-
-Appendix A In Memoriam
-**********************
-
-The GDB project mourns the loss of the following long-time contributors:
-
-`Fred Fish'
- Fred was a long-standing contributor to GDB (1991-2006), and to
- Free Software in general. Outside of GDB, he was known in the
- Amiga world for his series of Fish Disks, and the GeekGadget
- project.
-
-`Michael Snyder'
- Michael was one of the Global Maintainers of the GDB project, with
- contributions recorded as early as 1996, until 2011. In addition
- to his day to day participation, he was a large driving force
- behind adding Reverse Debugging to GDB.
-
- Beyond their technical contributions to the project, they were also
-enjoyable members of the Free Software Community. We will miss them.
-
-
-File: gdb.info, Node: Formatting Documentation, Next: Installing GDB, Prev: In Memoriam, Up: Top
-
-Appendix B Formatting Documentation
-***********************************
-
-The GDB 4 release includes an already-formatted reference card, ready
-for printing with PostScript or Ghostscript, in the `gdb' subdirectory
-of the main source directory(1). If you can use PostScript or
-Ghostscript with your printer, you can print the reference card
-immediately with `refcard.ps'.
-
- The release also includes the source for the reference card. You
-can format it, using TeX, by typing:
-
- make refcard.dvi
-
- The GDB reference card is designed to print in "landscape" mode on
-US "letter" size paper; that is, on a sheet 11 inches wide by 8.5 inches
-high. You will need to specify this form of printing as an option to
-your DVI output program.
-
- All the documentation for GDB comes as part of the machine-readable
-distribution. The documentation is written in Texinfo format, which is
-a documentation system that uses a single source file to produce both
-on-line information and a printed manual. You can use one of the Info
-formatting commands to create the on-line version of the documentation
-and TeX (or `texi2roff') to typeset the printed version.
-
- GDB includes an already formatted copy of the on-line Info version
-of this manual in the `gdb' subdirectory. The main Info file is
-`gdb-7.3.1-gg2/gdb/gdb.info', and it refers to subordinate files
-matching `gdb.info*' in the same directory. If necessary, you can
-print out these files, or read them with any editor; but they are
-easier to read using the `info' subsystem in GNU Emacs or the
-standalone `info' program, available as part of the GNU Texinfo
-distribution.
-
- If you want to format these Info files yourself, you need one of the
-Info formatting programs, such as `texinfo-format-buffer' or `makeinfo'.
-
- If you have `makeinfo' installed, and are in the top level GDB
-source directory (`gdb-7.3.1-gg2', in the case of version 7.3.1-gg2),
-you can make the Info file by typing:
-
- cd gdb
- make gdb.info
-
- If you want to typeset and print copies of this manual, you need TeX,
-a program to print its DVI output files, and `texinfo.tex', the Texinfo
-definitions file.
-
- TeX is a typesetting program; it does not print files directly, but
-produces output files called DVI files. To print a typeset document,
-you need a program to print DVI files. If your system has TeX
-installed, chances are it has such a program. The precise command to
-use depends on your system; `lpr -d' is common; another (for PostScript
-devices) is `dvips'. The DVI print command may require a file name
-without any extension or a `.dvi' extension.
-
- TeX also requires a macro definitions file called `texinfo.tex'.
-This file tells TeX how to typeset a document written in Texinfo
-format. On its own, TeX cannot either read or typeset a Texinfo file.
-`texinfo.tex' is distributed with GDB and is located in the
-`gdb-VERSION-NUMBER/texinfo' directory.
-
- If you have TeX and a DVI printer program installed, you can typeset
-and print this manual. First switch to the `gdb' subdirectory of the
-main source directory (for example, to `gdb-7.3.1-gg2/gdb') and type:
-
- make gdb.dvi
-
- Then give `gdb.dvi' to your DVI printing program.
-
- ---------- Footnotes ----------
-
- (1) In `gdb-7.3.1-gg2/gdb/refcard.ps' of the version 7.3.1-gg2
-release.
-
-
-File: gdb.info, Node: Installing GDB, Next: Maintenance Commands, Prev: Formatting Documentation, Up: Top
-
-Appendix C Installing GDB
-*************************
-
-* Menu:
-
-* Requirements:: Requirements for building GDB
-* Running Configure:: Invoking the GDB `configure' script
-* Separate Objdir:: Compiling GDB in another directory
-* Config Names:: Specifying names for hosts and targets
-* Configure Options:: Summary of options for configure
-* System-wide configuration:: Having a system-wide init file
-
-
-File: gdb.info, Node: Requirements, Next: Running Configure, Up: Installing GDB
-
-C.1 Requirements for Building GDB
-=================================
-
-Building GDB requires various tools and packages to be available.
-Other packages will be used only if they are found.
-
-Tools/Packages Necessary for Building GDB
-=========================================
-
-ISO C90 compiler
- GDB is written in ISO C90. It should be buildable with any
- working C90 compiler, e.g. GCC.
-
-
-Tools/Packages Optional for Building GDB
-========================================
-
-Expat
- GDB can use the Expat XML parsing library. This library may be
- included with your operating system distribution; if it is not, you
- can get the latest version from `http://expat.sourceforge.net'.
- The `configure' script will search for this library in several
- standard locations; if it is installed in an unusual path, you can
- use the `--with-libexpat-prefix' option to specify its location.
-
- Expat is used for:
-
- * Remote protocol memory maps (*note Memory Map Format::)
-
- * Target descriptions (*note Target Descriptions::)
-
- * Remote shared library lists (*note Library List Format::)
-
- * MS-Windows shared libraries (*note Shared Libraries::)
-
- * Traceframe info (*note Traceframe Info Format::)
-
-zlib
- GDB will use the `zlib' library, if available, to read compressed
- debug sections. Some linkers, such as GNU gold, are capable of
- producing binaries with compressed debug sections. If GDB is
- compiled with `zlib', it will be able to read the debug
- information in such binaries.
-
- The `zlib' library is likely included with your operating system
- distribution; if it is not, you can get the latest version from
- `http://zlib.net'.
-
-iconv
- GDB's features related to character sets (*note Character Sets::)
- require a functioning `iconv' implementation. If you are on a GNU
- system, then this is provided by the GNU C Library. Some other
- systems also provide a working `iconv'.
-
- If GDB is using the `iconv' program which is installed in a
- non-standard place, you will need to tell GDB where to find it.
- This is done with `--with-iconv-bin' which specifies the directory
- that contains the `iconv' program.
-
- On systems without `iconv', you can install GNU Libiconv. If you
- have previously installed Libiconv, you can use the
- `--with-libiconv-prefix' option to configure.
-
- GDB's top-level `configure' and `Makefile' will arrange to build
- Libiconv if a directory named `libiconv' appears in the top-most
- source directory. If Libiconv is built this way, and if the
- operating system does not provide a suitable `iconv'
- implementation, then the just-built library will automatically be
- used by GDB. One easy way to set this up is to download GNU
- Libiconv, unpack it, and then rename the directory holding the
- Libiconv source code to `libiconv'.
-
-
-File: gdb.info, Node: Running Configure, Next: Separate Objdir, Prev: Requirements, Up: Installing GDB
-
-C.2 Invoking the GDB `configure' Script
-=======================================
-
-GDB comes with a `configure' script that automates the process of
-preparing GDB for installation; you can then use `make' to build the
-`gdb' program.
-
- The GDB distribution includes all the source code you need for GDB
-in a single directory, whose name is usually composed by appending the
-version number to `gdb'.
-
- For example, the GDB version 7.3.1-gg2 distribution is in the
-`gdb-7.3.1-gg2' directory. That directory contains:
-
-`gdb-7.3.1-gg2/configure (and supporting files)'
- script for configuring GDB and all its supporting libraries
-
-`gdb-7.3.1-gg2/gdb'
- the source specific to GDB itself
-
-`gdb-7.3.1-gg2/bfd'
- source for the Binary File Descriptor library
-
-`gdb-7.3.1-gg2/include'
- GNU include files
-
-`gdb-7.3.1-gg2/libiberty'
- source for the `-liberty' free software library
-
-`gdb-7.3.1-gg2/opcodes'
- source for the library of opcode tables and disassemblers
-
-`gdb-7.3.1-gg2/readline'
- source for the GNU command-line interface
-
-`gdb-7.3.1-gg2/glob'
- source for the GNU filename pattern-matching subroutine
-
-`gdb-7.3.1-gg2/mmalloc'
- source for the GNU memory-mapped malloc package
-
- The simplest way to configure and build GDB is to run `configure'
-from the `gdb-VERSION-NUMBER' source directory, which in this example
-is the `gdb-7.3.1-gg2' directory.
-
- First switch to the `gdb-VERSION-NUMBER' source directory if you are
-not already in it; then run `configure'. Pass the identifier for the
-platform on which GDB will run as an argument.
-
- For example:
-
- cd gdb-7.3.1-gg2
- ./configure HOST
- make
-
-where HOST is an identifier such as `sun4' or `decstation', that
-identifies the platform where GDB will run. (You can often leave off
-HOST; `configure' tries to guess the correct value by examining your
-system.)
-
- Running `configure HOST' and then running `make' builds the `bfd',
-`readline', `mmalloc', and `libiberty' libraries, then `gdb' itself.
-The configured source files, and the binaries, are left in the
-corresponding source directories.
-
- `configure' is a Bourne-shell (`/bin/sh') script; if your system
-does not recognize this automatically when you run a different shell,
-you may need to run `sh' on it explicitly:
-
- sh configure HOST
-
- If you run `configure' from a directory that contains source
-directories for multiple libraries or programs, such as the
-`gdb-7.3.1-gg2' source directory for version 7.3.1-gg2, `configure'
-creates configuration files for every directory level underneath (unless
-you tell it not to, with the `--norecursion' option).
-
- You should run the `configure' script from the top directory in the
-source tree, the `gdb-VERSION-NUMBER' directory. If you run
-`configure' from one of the subdirectories, you will configure only
-that subdirectory. That is usually not what you want. In particular,
-if you run the first `configure' from the `gdb' subdirectory of the
-`gdb-VERSION-NUMBER' directory, you will omit the configuration of
-`bfd', `readline', and other sibling directories of the `gdb'
-subdirectory. This leads to build errors about missing include files
-such as `bfd/bfd.h'.
-
- You can install `gdb' anywhere; it has no hardwired paths. However,
-you should make sure that the shell on your path (named by the `SHELL'
-environment variable) is publicly readable. Remember that GDB uses the
-shell to start your program--some systems refuse to let GDB debug child
-processes whose programs are not readable.
-
-
-File: gdb.info, Node: Separate Objdir, Next: Config Names, Prev: Running Configure, Up: Installing GDB
-
-C.3 Compiling GDB in Another Directory
-======================================
-
-If you want to run GDB versions for several host or target machines,
-you need a different `gdb' compiled for each combination of host and
-target. `configure' is designed to make this easy by allowing you to
-generate each configuration in a separate subdirectory, rather than in
-the source directory. If your `make' program handles the `VPATH'
-feature (GNU `make' does), running `make' in each of these directories
-builds the `gdb' program specified there.
-
- To build `gdb' in a separate directory, run `configure' with the
-`--srcdir' option to specify where to find the source. (You also need
-to specify a path to find `configure' itself from your working
-directory. If the path to `configure' would be the same as the
-argument to `--srcdir', you can leave out the `--srcdir' option; it is
-assumed.)
-
- For example, with version 7.3.1-gg2, you can build GDB in a separate
-directory for a Sun 4 like this:
-
- cd gdb-7.3.1-gg2
- mkdir ../gdb-sun4
- cd ../gdb-sun4
- ../gdb-7.3.1-gg2/configure sun4
- make
-
- When `configure' builds a configuration using a remote source
-directory, it creates a tree for the binaries with the same structure
-(and using the same names) as the tree under the source directory. In
-the example, you'd find the Sun 4 library `libiberty.a' in the
-directory `gdb-sun4/libiberty', and GDB itself in `gdb-sun4/gdb'.
-
- Make sure that your path to the `configure' script has just one
-instance of `gdb' in it. If your path to `configure' looks like
-`../gdb-7.3.1-gg2/gdb/configure', you are configuring only one
-subdirectory of GDB, not the whole package. This leads to build errors
-about missing include files such as `bfd/bfd.h'.
-
- One popular reason to build several GDB configurations in separate
-directories is to configure GDB for cross-compiling (where GDB runs on
-one machine--the "host"--while debugging programs that run on another
-machine--the "target"). You specify a cross-debugging target by giving
-the `--target=TARGET' option to `configure'.
-
- When you run `make' to build a program or library, you must run it
-in a configured directory--whatever directory you were in when you
-called `configure' (or one of its subdirectories).
-
- The `Makefile' that `configure' generates in each source directory
-also runs recursively. If you type `make' in a source directory such
-as `gdb-7.3.1-gg2' (or in a separate configured directory configured
-with `--srcdir=DIRNAME/gdb-7.3.1-gg2'), you will build all the required
-libraries, and then build GDB.
-
- When you have multiple hosts or targets configured in separate
-directories, you can run `make' on them in parallel (for example, if
-they are NFS-mounted on each of the hosts); they will not interfere
-with each other.
-
-
-File: gdb.info, Node: Config Names, Next: Configure Options, Prev: Separate Objdir, Up: Installing GDB
-
-C.4 Specifying Names for Hosts and Targets
-==========================================
-
-The specifications used for hosts and targets in the `configure' script
-are based on a three-part naming scheme, but some short predefined
-aliases are also supported. The full naming scheme encodes three pieces
-of information in the following pattern:
-
- ARCHITECTURE-VENDOR-OS
-
- For example, you can use the alias `sun4' as a HOST argument, or as
-the value for TARGET in a `--target=TARGET' option. The equivalent
-full name is `sparc-sun-sunos4'.
-
- The `configure' script accompanying GDB does not provide any query
-facility to list all supported host and target names or aliases.
-`configure' calls the Bourne shell script `config.sub' to map
-abbreviations to full names; you can read the script, if you wish, or
-you can use it to test your guesses on abbreviations--for example:
-
- % sh config.sub i386-linux
- i386-pc-linux-gnu
- % sh config.sub alpha-linux
- alpha-unknown-linux-gnu
- % sh config.sub hp9k700
- hppa1.1-hp-hpux
- % sh config.sub sun4
- sparc-sun-sunos4.1.1
- % sh config.sub sun3
- m68k-sun-sunos4.1.1
- % sh config.sub i986v
- Invalid configuration `i986v': machine `i986v' not recognized
-
-`config.sub' is also distributed in the GDB source directory
-(`gdb-7.3.1-gg2', for version 7.3.1-gg2).
-
-
-File: gdb.info, Node: Configure Options, Next: System-wide configuration, Prev: Config Names, Up: Installing GDB
-
-C.5 `configure' Options
-=======================
-
-Here is a summary of the `configure' options and arguments that are
-most often useful for building GDB. `configure' also has several other
-options not listed here. *note (configure.info)What Configure Does::,
-for a full explanation of `configure'.
-
- configure [--help]
- [--prefix=DIR]
- [--exec-prefix=DIR]
- [--srcdir=DIRNAME]
- [--norecursion] [--rm]
- [--target=TARGET]
- HOST
-
-You may introduce options with a single `-' rather than `--' if you
-prefer; but you may abbreviate option names if you use `--'.
-
-`--help'
- Display a quick summary of how to invoke `configure'.
-
-`--prefix=DIR'
- Configure the source to install programs and files under directory
- `DIR'.
-
-`--exec-prefix=DIR'
- Configure the source to install programs under directory `DIR'.
-
-`--srcdir=DIRNAME'
- *Warning: using this option requires GNU `make', or another `make'
- that implements the `VPATH' feature.*
- Use this option to make configurations in directories separate
- from the GDB source directories. Among other things, you can use
- this to build (or maintain) several configurations simultaneously,
- in separate directories. `configure' writes
- configuration-specific files in the current directory, but
- arranges for them to use the source in the directory DIRNAME.
- `configure' creates directories under the working directory in
- parallel to the source directories below DIRNAME.
-
-`--norecursion'
- Configure only the directory level where `configure' is executed;
- do not propagate configuration to subdirectories.
-
-`--target=TARGET'
- Configure GDB for cross-debugging programs running on the specified
- TARGET. Without this option, GDB is configured to debug programs
- that run on the same machine (HOST) as GDB itself.
-
- There is no convenient way to generate a list of all available
- targets.
-
-`HOST ...'
- Configure GDB to run on the specified HOST.
-
- There is no convenient way to generate a list of all available
- hosts.
-
- There are many other options available as well, but they are
-generally needed for special purposes only.
-
-
-File: gdb.info, Node: System-wide configuration, Prev: Configure Options, Up: Installing GDB
-
-C.6 System-wide configuration and settings
-==========================================
-
-GDB can be configured to have a system-wide init file; this file will
-be read and executed at startup (*note What GDB does during startup:
-Startup.).
-
- Here is the corresponding configure option:
-
-`--with-system-gdbinit=FILE'
- Specify that the default location of the system-wide init file is
- FILE.
-
- If GDB has been configured with the option `--prefix=$prefix', it
-may be subject to relocation. Two possible cases:
-
- * If the default location of this init file contains `$prefix', it
- will be subject to relocation. Suppose that the configure options
- are `--prefix=$prefix --with-system-gdbinit=$prefix/etc/gdbinit';
- if GDB is moved from `$prefix' to `$install', the system init file
- is looked for as `$install/etc/gdbinit' instead of
- `$prefix/etc/gdbinit'.
-
- * By contrast, if the default location does not contain the prefix,
- it will not be relocated. E.g. if GDB has been configured with
- `--prefix=/usr/local --with-system-gdbinit=/usr/share/gdb/gdbinit',
- then GDB will always look for `/usr/share/gdb/gdbinit', wherever
- GDB is installed.
-
-
-File: gdb.info, Node: Maintenance Commands, Next: Remote Protocol, Prev: Installing GDB, Up: Top
-
-Appendix D Maintenance Commands
-*******************************
-
-In addition to commands intended for GDB users, GDB includes a number
-of commands intended for GDB developers, that are not documented
-elsewhere in this manual. These commands are provided here for
-reference. (For commands that turn on debugging messages, see *note
-Debugging Output::.)
-
-`maint agent EXPRESSION'
-`maint agent-eval EXPRESSION'
- Translate the given EXPRESSION into remote agent bytecodes. This
- command is useful for debugging the Agent Expression mechanism
- (*note Agent Expressions::). The `agent' version produces an
- expression useful for data collection, such as by tracepoints,
- while `maint agent-eval' produces an expression that evaluates
- directly to a result. For instance, a collection expression for
- `globa + globb' will include bytecodes to record four bytes of
- memory at each of the addresses of `globa' and `globb', while
- discarding the result of the addition, while an evaluation
- expression will do the addition and return the sum.
-
-`maint info breakpoints'
- Using the same format as `info breakpoints', display both the
- breakpoints you've set explicitly, and those GDB is using for
- internal purposes. Internal breakpoints are shown with negative
- breakpoint numbers. The type column identifies what kind of
- breakpoint is shown:
-
- `breakpoint'
- Normal, explicitly set breakpoint.
-
- `watchpoint'
- Normal, explicitly set watchpoint.
-
- `longjmp'
- Internal breakpoint, used to handle correctly stepping through
- `longjmp' calls.
-
- `longjmp resume'
- Internal breakpoint at the target of a `longjmp'.
-
- `until'
- Temporary internal breakpoint used by the GDB `until' command.
-
- `finish'
- Temporary internal breakpoint used by the GDB `finish'
- command.
-
- `shlib events'
- Shared library events.
-
-
-`set displaced-stepping'
-`show displaced-stepping'
- Control whether or not GDB will do "displaced stepping" if the
- target supports it. Displaced stepping is a way to single-step
- over breakpoints without removing them from the inferior, by
- executing an out-of-line copy of the instruction that was
- originally at the breakpoint location. It is also known as
- out-of-line single-stepping.
-
- `set displaced-stepping on'
- If the target architecture supports it, GDB will use
- displaced stepping to step over breakpoints.
-
- `set displaced-stepping off'
- GDB will not use displaced stepping to step over breakpoints,
- even if such is supported by the target architecture.
-
- `set displaced-stepping auto'
- This is the default mode. GDB will use displaced stepping
- only if non-stop mode is active (*note Non-Stop Mode::) and
- the target architecture supports displaced stepping.
-
-`maint check-symtabs'
- Check the consistency of psymtabs and symtabs.
-
-`maint cplus first_component NAME'
- Print the first C++ class/namespace component of NAME.
-
-`maint cplus namespace'
- Print the list of possible C++ namespaces.
-
-`maint demangle NAME'
- Demangle a C++ or Objective-C mangled NAME.
-
-`maint deprecate COMMAND [REPLACEMENT]'
-`maint undeprecate COMMAND'
- Deprecate or undeprecate the named COMMAND. Deprecated commands
- cause GDB to issue a warning when you use them. The optional
- argument REPLACEMENT says which newer command should be used in
- favor of the deprecated one; if it is given, GDB will mention the
- replacement as part of the warning.
-
-`maint dump-me'
- Cause a fatal signal in the debugger and force it to dump its core.
- This is supported only on systems which support aborting a program
- with the `SIGQUIT' signal.
-
-`maint internal-error [MESSAGE-TEXT]'
-`maint internal-warning [MESSAGE-TEXT]'
- Cause GDB to call the internal function `internal_error' or
- `internal_warning' and hence behave as though an internal error or
- internal warning has been detected. In addition to reporting the
- internal problem, these functions give the user the opportunity to
- either quit GDB or create a core file of the current GDB session.
-
- These commands take an optional parameter MESSAGE-TEXT that is
- used as the text of the error or warning message.
-
- Here's an example of using `internal-error':
-
- (gdb) maint internal-error testing, 1, 2
- .../maint.c:121: internal-error: testing, 1, 2
- A problem internal to GDB has been detected. Further
- debugging may prove unreliable.
- Quit this debugging session? (y or n) n
- Create a core file? (y or n) n
- (gdb)
-
-`maint set internal-error ACTION [ask|yes|no]'
-`maint show internal-error ACTION'
-`maint set internal-warning ACTION [ask|yes|no]'
-`maint show internal-warning ACTION'
- When GDB reports an internal problem (error or warning) it gives
- the user the opportunity to both quit GDB and create a core file
- of the current GDB session. These commands let you override the
- default behaviour for each particular ACTION, described in the
- table below.
-
- `quit'
- You can specify that GDB should always (yes) or never (no)
- quit. The default is to ask the user what to do.
-
- `corefile'
- You can specify that GDB should always (yes) or never (no)
- create a core file. The default is to ask the user what to
- do.
-
-`maint packet TEXT'
- If GDB is talking to an inferior via the serial protocol, then
- this command sends the string TEXT to the inferior, and displays
- the response packet. GDB supplies the initial `$' character, the
- terminating `#' character, and the checksum.
-
-`maint print architecture [FILE]'
- Print the entire architecture configuration. The optional argument
- FILE names the file where the output goes.
-
-`maint print c-tdesc'
- Print the current target description (*note Target Descriptions::)
- as a C source file. The created source file can be used in GDB
- when an XML parser is not available to parse the description.
-
-`maint print dummy-frames'
- Prints the contents of GDB's internal dummy-frame stack.
-
- (gdb) b add
- ...
- (gdb) print add(2,3)
- Breakpoint 2, add (a=2, b=3) at ...
- 58 return (a + b);
- The program being debugged stopped while in a function called from GDB.
- ...
- (gdb) maint print dummy-frames
- 0x1a57c80: pc=0x01014068 fp=0x0200bddc sp=0x0200bdd6
- top=0x0200bdd4 id={stack=0x200bddc,code=0x101405c}
- call_lo=0x01014000 call_hi=0x01014001
- (gdb)
-
- Takes an optional file parameter.
-
-`maint print registers [FILE]'
-`maint print raw-registers [FILE]'
-`maint print cooked-registers [FILE]'
-`maint print register-groups [FILE]'
- Print GDB's internal register data structures.
-
- The command `maint print raw-registers' includes the contents of
- the raw register cache; the command `maint print cooked-registers'
- includes the (cooked) value of all registers, including registers
- which aren't available on the target nor visible to user; and the
- command `maint print register-groups' includes the groups that each
- register is a member of. *Note Registers: (gdbint)Registers.
-
- These commands take an optional parameter, a file name to which to
- write the information.
-
-`maint print reggroups [FILE]'
- Print GDB's internal register group data structures. The optional
- argument FILE tells to what file to write the information.
-
- The register groups info looks like this:
-
- (gdb) maint print reggroups
- Group Type
- general user
- float user
- all user
- vector user
- system user
- save internal
- restore internal
-
-`flushregs'
- This command forces GDB to flush its internal register cache.
-
-`maint print objfiles'
- Print a dump of all known object files. For each object file, this
- command prints its name, address in memory, and all of its psymtabs
- and symtabs.
-
-`maint print section-scripts [REGEXP]'
- Print a dump of scripts specified in the `.debug_gdb_section'
- section. If REGEXP is specified, only print scripts loaded by
- object files matching REGEXP. For each script, this command
- prints its name as specified in the objfile, and the full path if
- known. *Note .debug_gdb_scripts section::.
-
-`maint print statistics'
- This command prints, for each object file in the program, various
- data about that object file followed by the byte cache ("bcache")
- statistics for the object file. The objfile data includes the
- number of minimal, partial, full, and stabs symbols, the number of
- types defined by the objfile, the number of as yet unexpanded psym
- tables, the number of line tables and string tables, and the
- amount of memory used by the various tables. The bcache
- statistics include the counts, sizes, and counts of duplicates of
- all and unique objects, max, average, and median entry size, total
- memory used and its overhead and savings, and various measures of
- the hash table size and chain lengths.
-
-`maint print target-stack'
- A "target" is an interface between the debugger and a particular
- kind of file or process. Targets can be stacked in "strata", so
- that more than one target can potentially respond to a request.
- In particular, memory accesses will walk down the stack of targets
- until they find a target that is interested in handling that
- particular address.
-
- This command prints a short description of each layer that was
- pushed on the "target stack", starting from the top layer down to
- the bottom one.
-
-`maint print type EXPR'
- Print the type chain for a type specified by EXPR. The argument
- can be either a type name or a symbol. If it is a symbol, the
- type of that symbol is described. The type chain produced by this
- command is a recursive definition of the data type as stored in
- GDB's data structures, including its flags and contained types.
-
-`maint set dwarf2 always-disassemble'
-
-`maint show dwarf2 always-disassemble'
- Control the behavior of `info address' when using DWARF debugging
- information.
-
- The default is `off', which means that GDB should try to describe
- a variable's location in an easily readable format. When `on',
- GDB will instead display the DWARF location expression in an
- assembly-like format. Note that some locations are too complex
- for GDB to describe simply; in this case you will always see the
- disassembly form.
-
- Here is an example of the resulting disassembly:
-
- (gdb) info addr argc
- Symbol "argc" is a complex DWARF expression:
- 1: DW_OP_fbreg 0
-
- For more information on these expressions, see the DWARF standard
- (http://www.dwarfstd.org/).
-
-`maint set dwarf2 max-cache-age'
-`maint show dwarf2 max-cache-age'
- Control the DWARF 2 compilation unit cache.
-
- In object files with inter-compilation-unit references, such as
- those produced by the GCC option `-feliminate-dwarf2-dups', the
- DWARF 2 reader needs to frequently refer to previously read
- compilation units. This setting controls how long a compilation
- unit will remain in the cache if it is not referenced. A higher
- limit means that cached compilation units will be stored in memory
- longer, and more total memory will be used. Setting it to zero
- disables caching, which will slow down GDB startup, but reduce
- memory consumption.
-
-`maint set profile'
-`maint show profile'
- Control profiling of GDB.
-
- Profiling will be disabled until you use the `maint set profile'
- command to enable it. When you enable profiling, the system will
- begin collecting timing and execution count data; when you disable
- profiling or exit GDB, the results will be written to a log file.
- Remember that if you use profiling, GDB will overwrite the
- profiling log file (often called `gmon.out'). If you have a
- record of important profiling data in a `gmon.out' file, be sure
- to move it to a safe location.
-
- Configuring with `--enable-profiling' arranges for GDB to be
- compiled with the `-pg' compiler option.
-
-`maint set show-debug-regs'
-`maint show show-debug-regs'
- Control whether to show variables that mirror the hardware debug
- registers. Use `ON' to enable, `OFF' to disable. If enabled, the
- debug registers values are shown when GDB inserts or removes a
- hardware breakpoint or watchpoint, and when the inferior triggers
- a hardware-assisted breakpoint or watchpoint.
-
-`maint set show-all-tib'
-`maint show show-all-tib'
- Control whether to show all non zero areas within a 1k block
- starting at thread local base, when using the `info w32
- thread-information-block' command.
-
-`maint space'
- Control whether to display memory usage for each command. If set
- to a nonzero value, GDB will display how much memory each command
- took, following the command's own output. This can also be
- requested by invoking GDB with the `--statistics' command-line
- switch (*note Mode Options::).
-
-`maint time'
- Control whether to display the execution time for each command. If
- set to a nonzero value, GDB will display how much time it took to
- execute each command, following the command's own output. The
- time is not printed for the commands that run the target, since
- there's no mechanism currently to compute how much time was spend
- by GDB and how much time was spend by the program been debugged.
- it's not possibly currently This can also be requested by invoking
- GDB with the `--statistics' command-line switch (*note Mode
- Options::).
-
-`maint translate-address [SECTION] ADDR'
- Find the symbol stored at the location specified by the address
- ADDR and an optional section name SECTION. If found, GDB prints
- the name of the closest symbol and an offset from the symbol's
- location to the specified address. This is similar to the `info
- address' command (*note Symbols::), except that this command also
- allows to find symbols in other sections.
-
- If section was not specified, the section in which the symbol was
- found is also printed. For dynamically linked executables, the
- name of executable or shared library containing the symbol is
- printed as well.
-
-
- The following command is useful for non-interactive invocations of
-GDB, such as in the test suite.
-
-`set watchdog NSEC'
- Set the maximum number of seconds GDB will wait for the target
- operation to finish. If this time expires, GDB reports and error
- and the command is aborted.
-
-`show watchdog'
- Show the current setting of the target wait timeout.
-
-
-File: gdb.info, Node: Remote Protocol, Next: Agent Expressions, Prev: Maintenance Commands, Up: Top
-
-Appendix E GDB Remote Serial Protocol
-*************************************
-
-* Menu:
-
-* Overview::
-* Packets::
-* Stop Reply Packets::
-* General Query Packets::
-* Architecture-Specific Protocol Details::
-* Tracepoint Packets::
-* Host I/O Packets::
-* Interrupts::
-* Notification Packets::
-* Remote Non-Stop::
-* Packet Acknowledgment::
-* Examples::
-* File-I/O Remote Protocol Extension::
-* Library List Format::
-* Memory Map Format::
-* Thread List Format::
-* Traceframe Info Format::
-
-
-File: gdb.info, Node: Overview, Next: Packets, Up: Remote Protocol
-
-E.1 Overview
-============
-
-There may be occasions when you need to know something about the
-protocol--for example, if there is only one serial port to your target
-machine, you might want your program to do something special if it
-recognizes a packet meant for GDB.
-
- In the examples below, `->' and `<-' are used to indicate
-transmitted and received data, respectively.
-
- All GDB commands and responses (other than acknowledgments and
-notifications, see *note Notification Packets::) are sent as a PACKET.
-A PACKET is introduced with the character `$', the actual PACKET-DATA,
-and the terminating character `#' followed by a two-digit CHECKSUM:
-
- `$'PACKET-DATA`#'CHECKSUM
- The two-digit CHECKSUM is computed as the modulo 256 sum of all
-characters between the leading `$' and the trailing `#' (an eight bit
-unsigned checksum).
-
- Implementors should note that prior to GDB 5.0 the protocol
-specification also included an optional two-digit SEQUENCE-ID:
-
- `$'SEQUENCE-ID`:'PACKET-DATA`#'CHECKSUM
-
-That SEQUENCE-ID was appended to the acknowledgment. GDB has never
-output SEQUENCE-IDs. Stubs that handle packets added since GDB 5.0
-must not accept SEQUENCE-ID.
-
- When either the host or the target machine receives a packet, the
-first response expected is an acknowledgment: either `+' (to indicate
-the package was received correctly) or `-' (to request retransmission):
-
- -> `$'PACKET-DATA`#'CHECKSUM
- <- `+'
- The `+'/`-' acknowledgments can be disabled once a connection is
-established. *Note Packet Acknowledgment::, for details.
-
- The host (GDB) sends COMMANDs, and the target (the debugging stub
-incorporated in your program) sends a RESPONSE. In the case of step
-and continue COMMANDs, the response is only sent when the operation has
-completed, and the target has again stopped all threads in all attached
-processes. This is the default all-stop mode behavior, but the remote
-protocol also supports GDB's non-stop execution mode; see *note Remote
-Non-Stop::, for details.
-
- PACKET-DATA consists of a sequence of characters with the exception
-of `#' and `$' (see `X' packet for additional exceptions).
-
- Fields within the packet should be separated using `,' `;' or `:'.
-Except where otherwise noted all numbers are represented in HEX with
-leading zeros suppressed.
-
- Implementors should note that prior to GDB 5.0, the character `:'
-could not appear as the third character in a packet (as it would
-potentially conflict with the SEQUENCE-ID).
-
- Binary data in most packets is encoded either as two hexadecimal
-digits per byte of binary data. This allowed the traditional remote
-protocol to work over connections which were only seven-bit clean.
-Some packets designed more recently assume an eight-bit clean
-connection, and use a more efficient encoding to send and receive
-binary data.
-
- The binary data representation uses `7d' (ASCII `}') as an escape
-character. Any escaped byte is transmitted as the escape character
-followed by the original character XORed with `0x20'. For example, the
-byte `0x7d' would be transmitted as the two bytes `0x7d 0x5d'. The
-bytes `0x23' (ASCII `#'), `0x24' (ASCII `$'), and `0x7d' (ASCII `}')
-must always be escaped. Responses sent by the stub must also escape
-`0x2a' (ASCII `*'), so that it is not interpreted as the start of a
-run-length encoded sequence (described next).
-
- Response DATA can be run-length encoded to save space. Run-length
-encoding replaces runs of identical characters with one instance of the
-repeated character, followed by a `*' and a repeat count. The repeat
-count is itself sent encoded, to avoid binary characters in DATA: a
-value of N is sent as `N+29'. For a repeat count greater or equal to
-3, this produces a printable ASCII character, e.g. a space (ASCII code
-32) for a repeat count of 3. (This is because run-length encoding
-starts to win for counts 3 or more.) Thus, for example, `0* ' is a
-run-length encoding of "0000": the space character after `*' means
-repeat the leading `0' `32 - 29 = 3' more times.
-
- The printable characters `#' and `$' or with a numeric value greater
-than 126 must not be used. Runs of six repeats (`#') or seven repeats
-(`$') can be expanded using a repeat count of only five (`"'). For
-example, `00000000' can be encoded as `0*"00'.
-
- The error response returned for some packets includes a two character
-error number. That number is not well defined.
-
- For any COMMAND not supported by the stub, an empty response
-(`$#00') should be returned. That way it is possible to extend the
-protocol. A newer GDB can tell if a packet is supported based on that
-response.
-
- A stub is required to support the `g', `G', `m', `M', `c', and `s'
-COMMANDs. All other COMMANDs are optional.
-
-
-File: gdb.info, Node: Packets, Next: Stop Reply Packets, Prev: Overview, Up: Remote Protocol
-
-E.2 Packets
-===========
-
-The following table provides a complete list of all currently defined
-COMMANDs and their corresponding response DATA. *Note File-I/O Remote
-Protocol Extension::, for details about the File I/O extension of the
-remote protocol.
-
- Each packet's description has a template showing the packet's overall
-syntax, followed by an explanation of the packet's meaning. We include
-spaces in some of the templates for clarity; these are not part of the
-packet's syntax. No GDB packet uses spaces to separate its components.
-For example, a template like `foo BAR BAZ' describes a packet beginning
-with the three ASCII bytes `foo', followed by a BAR, followed directly
-by a BAZ. GDB does not transmit a space character between the `foo'
-and the BAR, or between the BAR and the BAZ.
-
- Several packets and replies include a THREAD-ID field to identify a
-thread. Normally these are positive numbers with a target-specific
-interpretation, formatted as big-endian hex strings. A THREAD-ID can
-also be a literal `-1' to indicate all threads, or `0' to pick any
-thread.
-
- In addition, the remote protocol supports a multiprocess feature in
-which the THREAD-ID syntax is extended to optionally include both
-process and thread ID fields, as `pPID.TID'. The PID (process) and TID
-(thread) components each have the format described above: a positive
-number with target-specific interpretation formatted as a big-endian
-hex string, literal `-1' to indicate all processes or threads
-(respectively), or `0' to indicate an arbitrary process or thread.
-Specifying just a process, as `pPID', is equivalent to `pPID.-1'. It
-is an error to specify all processes but a specific thread, such as
-`p-1.TID'. Note that the `p' prefix is _not_ used for those packets
-and replies explicitly documented to include a process ID, rather than
-a THREAD-ID.
-
- The multiprocess THREAD-ID syntax extensions are only used if both
-GDB and the stub report support for the `multiprocess' feature using
-`qSupported'. *Note multiprocess extensions::, for more information.
-
- Note that all packet forms beginning with an upper- or lower-case
-letter, other than those described here, are reserved for future use.
-
- Here are the packet descriptions.
-
-`!'
- Enable extended mode. In extended mode, the remote server is made
- persistent. The `R' packet is used to restart the program being
- debugged.
-
- Reply:
- `OK'
- The remote target both supports and has enabled extended mode.
-
-`?'
- Indicate the reason the target halted. The reply is the same as
- for step and continue. This packet has a special interpretation
- when the target is in non-stop mode; see *note Remote Non-Stop::.
-
- Reply: *Note Stop Reply Packets::, for the reply specifications.
-
-`A ARGLEN,ARGNUM,ARG,...'
- Initialized `argv[]' array passed into program. ARGLEN specifies
- the number of bytes in the hex encoded byte stream ARG. See
- `gdbserver' for more details.
-
- Reply:
- `OK'
- The arguments were set.
-
- `E NN'
- An error occurred.
-
-`b BAUD'
- (Don't use this packet; its behavior is not well-defined.) Change
- the serial line speed to BAUD.
-
- JTC: _When does the transport layer state change? When it's
- received, or after the ACK is transmitted. In either case, there
- are problems if the command or the acknowledgment packet is
- dropped._
-
- Stan: _If people really wanted to add something like this, and get
- it working for the first time, they ought to modify ser-unix.c to
- send some kind of out-of-band message to a specially-setup stub
- and have the switch happen "in between" packets, so that from
- remote protocol's point of view, nothing actually happened._
-
-`B ADDR,MODE'
- Set (MODE is `S') or clear (MODE is `C') a breakpoint at ADDR.
-
- Don't use this packet. Use the `Z' and `z' packets instead (*note
- insert breakpoint or watchpoint packet::).
-
-`bc'
- Backward continue. Execute the target system in reverse. No
- parameter. *Note Reverse Execution::, for more information.
-
- Reply: *Note Stop Reply Packets::, for the reply specifications.
-
-`bs'
- Backward single step. Execute one instruction in reverse. No
- parameter. *Note Reverse Execution::, for more information.
-
- Reply: *Note Stop Reply Packets::, for the reply specifications.
-
-`c [ADDR]'
- Continue. ADDR is address to resume. If ADDR is omitted, resume
- at current address.
-
- Reply: *Note Stop Reply Packets::, for the reply specifications.
-
-`C SIG[;ADDR]'
- Continue with signal SIG (hex signal number). If `;ADDR' is
- omitted, resume at same address.
-
- Reply: *Note Stop Reply Packets::, for the reply specifications.
-
-`d'
- Toggle debug flag.
-
- Don't use this packet; instead, define a general set packet (*note
- General Query Packets::).
-
-`D'
-`D;PID'
- The first form of the packet is used to detach GDB from the remote
- system. It is sent to the remote target before GDB disconnects
- via the `detach' command.
-
- The second form, including a process ID, is used when multiprocess
- protocol extensions are enabled (*note multiprocess extensions::),
- to detach only a specific process. The PID is specified as a
- big-endian hex string.
-
- Reply:
- `OK'
- for success
-
- `E NN'
- for an error
-
-`F RC,EE,CF;XX'
- A reply from GDB to an `F' packet sent by the target. This is
- part of the File-I/O protocol extension. *Note File-I/O Remote
- Protocol Extension::, for the specification.
-
-`g'
- Read general registers.
-
- Reply:
- `XX...'
- Each byte of register data is described by two hex digits.
- The bytes with the register are transmitted in target byte
- order. The size of each register and their position within
- the `g' packet are determined by the GDB internal gdbarch
- functions `DEPRECATED_REGISTER_RAW_SIZE' and
- `gdbarch_register_name'. The specification of several
- standard `g' packets is specified below.
-
- When reading registers from a trace frame (*note Using the
- Collected Data: Analyze Collected Data.), the stub may also
- return a string of literal `x''s in place of the register
- data digits, to indicate that the corresponding register has
- not been collected, thus its value is unavailable. For
- example, for an architecture with 4 registers of 4 bytes
- each, the following reply indicates to GDB that registers 0
- and 2 have not been collected, while registers 1 and 3 have
- been collected, and both have zero value:
-
- -> `g'
- <- `xxxxxxxx00000000xxxxxxxx00000000'
-
- `E NN'
- for an error.
-
-`G XX...'
- Write general registers. *Note read registers packet::, for a
- description of the XX... data.
-
- Reply:
- `OK'
- for success
-
- `E NN'
- for an error
-
-`H C THREAD-ID'
- Set thread for subsequent operations (`m', `M', `g', `G', et.al.).
- C depends on the operation to be performed: it should be `c' for
- step and continue operations, `g' for other operations. The
- thread designator THREAD-ID has the format and interpretation
- described in *note thread-id syntax::.
-
- Reply:
- `OK'
- for success
-
- `E NN'
- for an error
-
-`i [ADDR[,NNN]]'
- Step the remote target by a single clock cycle. If `,NNN' is
- present, cycle step NNN cycles. If ADDR is present, cycle step
- starting at that address.
-
-`I'
- Signal, then cycle step. *Note step with signal packet::. *Note
- cycle step packet::.
-
-`k'
- Kill request.
-
- FIXME: _There is no description of how to operate when a specific
- thread context has been selected (i.e. does 'k' kill only that
- thread?)_.
-
-`m ADDR,LENGTH'
- Read LENGTH bytes of memory starting at address ADDR. Note that
- ADDR may not be aligned to any particular boundary.
-
- The stub need not use any particular size or alignment when
- gathering data from memory for the response; even if ADDR is
- word-aligned and LENGTH is a multiple of the word size, the stub
- is free to use byte accesses, or not. For this reason, this
- packet may not be suitable for accessing memory-mapped I/O devices.
-
- Reply:
- `XX...'
- Memory contents; each byte is transmitted as a two-digit
- hexadecimal number. The reply may contain fewer bytes than
- requested if the server was able to read only part of the
- region of memory.
-
- `E NN'
- NN is errno
-
-`M ADDR,LENGTH:XX...'
- Write LENGTH bytes of memory starting at address ADDR. XX... is
- the data; each byte is transmitted as a two-digit hexadecimal
- number.
-
- Reply:
- `OK'
- for success
-
- `E NN'
- for an error (this includes the case where only part of the
- data was written).
-
-`p N'
- Read the value of register N; N is in hex. *Note read registers
- packet::, for a description of how the returned register value is
- encoded.
-
- Reply:
- `XX...'
- the register's value
-
- `E NN'
- for an error
-
- `'
- Indicating an unrecognized QUERY.
-
-`P N...=R...'
- Write register N... with value R.... The register number N is in
- hexadecimal, and R... contains two hex digits for each byte in the
- register (target byte order).
-
- Reply:
- `OK'
- for success
-
- `E NN'
- for an error
-
-`q NAME PARAMS...'
-`Q NAME PARAMS...'
- General query (`q') and set (`Q'). These packets are described
- fully in *note General Query Packets::.
-
-`r'
- Reset the entire system.
-
- Don't use this packet; use the `R' packet instead.
-
-`R XX'
- Restart the program being debugged. XX, while needed, is ignored.
- This packet is only available in extended mode (*note extended
- mode::).
-
- The `R' packet has no reply.
-
-`s [ADDR]'
- Single step. ADDR is the address at which to resume. If ADDR is
- omitted, resume at same address.
-
- Reply: *Note Stop Reply Packets::, for the reply specifications.
-
-`S SIG[;ADDR]'
- Step with signal. This is analogous to the `C' packet, but
- requests a single-step, rather than a normal resumption of
- execution.
-
- Reply: *Note Stop Reply Packets::, for the reply specifications.
-
-`t ADDR:PP,MM'
- Search backwards starting at address ADDR for a match with pattern
- PP and mask MM. PP and MM are 4 bytes. ADDR must be at least 3
- digits.
-
-`T THREAD-ID'
- Find out if the thread THREAD-ID is alive. *Note thread-id
- syntax::.
-
- Reply:
- `OK'
- thread is still alive
-
- `E NN'
- thread is dead
-
-`v'
- Packets starting with `v' are identified by a multi-letter name,
- up to the first `;' or `?' (or the end of the packet).
-
-`vAttach;PID'
- Attach to a new process with the specified process ID PID. The
- process ID is a hexadecimal integer identifying the process. In
- all-stop mode, all threads in the attached process are stopped; in
- non-stop mode, it may be attached without being stopped if that is
- supported by the target.
-
- This packet is only available in extended mode (*note extended
- mode::).
-
- Reply:
- `E NN'
- for an error
-
- `Any stop packet'
- for success in all-stop mode (*note Stop Reply Packets::)
-
- `OK'
- for success in non-stop mode (*note Remote Non-Stop::)
-
-`vCont[;ACTION[:THREAD-ID]]...'
- Resume the inferior, specifying different actions for each thread.
- If an action is specified with no THREAD-ID, then it is applied to
- any threads that don't have a specific action specified; if no
- default action is specified then other threads should remain
- stopped in all-stop mode and in their current state in non-stop
- mode. Specifying multiple default actions is an error; specifying
- no actions is also an error. Thread IDs are specified using the
- syntax described in *note thread-id syntax::.
-
- Currently supported actions are:
-
- `c'
- Continue.
-
- `C SIG'
- Continue with signal SIG. The signal SIG should be two hex
- digits.
-
- `s'
- Step.
-
- `S SIG'
- Step with signal SIG. The signal SIG should be two hex
- digits.
-
- `t'
- Stop.
-
- The optional argument ADDR normally associated with the `c', `C',
- `s', and `S' packets is not supported in `vCont'.
-
- The `t' action is only relevant in non-stop mode (*note Remote
- Non-Stop::) and may be ignored by the stub otherwise. A stop
- reply should be generated for any affected thread not already
- stopped. When a thread is stopped by means of a `t' action, the
- corresponding stop reply should indicate that the thread has
- stopped with signal `0', regardless of whether the target uses
- some other signal as an implementation detail.
-
- Reply: *Note Stop Reply Packets::, for the reply specifications.
-
-`vCont?'
- Request a list of actions supported by the `vCont' packet.
-
- Reply:
- `vCont[;ACTION...]'
- The `vCont' packet is supported. Each ACTION is a supported
- command in the `vCont' packet.
-
- `'
- The `vCont' packet is not supported.
-
-`vFile:OPERATION:PARAMETER...'
- Perform a file operation on the target system. For details, see
- *note Host I/O Packets::.
-
-`vFlashErase:ADDR,LENGTH'
- Direct the stub to erase LENGTH bytes of flash starting at ADDR.
- The region may enclose any number of flash blocks, but its start
- and end must fall on block boundaries, as indicated by the flash
- block size appearing in the memory map (*note Memory Map
- Format::). GDB groups flash memory programming operations
- together, and sends a `vFlashDone' request after each group; the
- stub is allowed to delay erase operation until the `vFlashDone'
- packet is received.
-
- The stub must support `vCont' if it reports support for
- multiprocess extensions (*note multiprocess extensions::). Note
- that in this case `vCont' actions can be specified to apply to all
- threads in a process by using the `pPID.-1' form of the THREAD-ID.
-
- Reply:
- `OK'
- for success
-
- `E NN'
- for an error
-
-`vFlashWrite:ADDR:XX...'
- Direct the stub to write data to flash address ADDR. The data is
- passed in binary form using the same encoding as for the `X'
- packet (*note Binary Data::). The memory ranges specified by
- `vFlashWrite' packets preceding a `vFlashDone' packet must not
- overlap, and must appear in order of increasing addresses
- (although `vFlashErase' packets for higher addresses may already
- have been received; the ordering is guaranteed only between
- `vFlashWrite' packets). If a packet writes to an address that was
- neither erased by a preceding `vFlashErase' packet nor by some
- other target-specific method, the results are unpredictable.
-
- Reply:
- `OK'
- for success
-
- `E.memtype'
- for vFlashWrite addressing non-flash memory
-
- `E NN'
- for an error
-
-`vFlashDone'
- Indicate to the stub that flash programming operation is finished.
- The stub is permitted to delay or batch the effects of a group of
- `vFlashErase' and `vFlashWrite' packets until a `vFlashDone'
- packet is received. The contents of the affected regions of flash
- memory are unpredictable until the `vFlashDone' request is
- completed.
-
-`vKill;PID'
- Kill the process with the specified process ID. PID is a
- hexadecimal integer identifying the process. This packet is used
- in preference to `k' when multiprocess protocol extensions are
- supported; see *note multiprocess extensions::.
-
- Reply:
- `E NN'
- for an error
-
- `OK'
- for success
-
-`vRun;FILENAME[;ARGUMENT]...'
- Run the program FILENAME, passing it each ARGUMENT on its command
- line. The file and arguments are hex-encoded strings. If
- FILENAME is an empty string, the stub may use a default program
- (e.g. the last program run). The program is created in the stopped
- state.
-
- This packet is only available in extended mode (*note extended
- mode::).
-
- Reply:
- `E NN'
- for an error
-
- `Any stop packet'
- for success (*note Stop Reply Packets::)
-
-`vStopped'
- In non-stop mode (*note Remote Non-Stop::), acknowledge a previous
- stop reply and prompt for the stub to report another one.
-
- Reply:
- `Any stop packet'
- if there is another unreported stop event (*note Stop Reply
- Packets::)
-
- `OK'
- if there are no unreported stop events
-
-`X ADDR,LENGTH:XX...'
- Write data to memory, where the data is transmitted in binary.
- ADDR is address, LENGTH is number of bytes, `XX...' is binary data
- (*note Binary Data::).
-
- Reply:
- `OK'
- for success
-
- `E NN'
- for an error
-
-`z TYPE,ADDR,KIND'
-`Z TYPE,ADDR,KIND'
- Insert (`Z') or remove (`z') a TYPE breakpoint or watchpoint
- starting at address ADDRESS of kind KIND.
-
- Each breakpoint and watchpoint packet TYPE is documented
- separately.
-
- _Implementation notes: A remote target shall return an empty string
- for an unrecognized breakpoint or watchpoint packet TYPE. A
- remote target shall support either both or neither of a given
- `ZTYPE...' and `zTYPE...' packet pair. To avoid potential
- problems with duplicate packets, the operations should be
- implemented in an idempotent way._
-
-`z0,ADDR,KIND'
-`Z0,ADDR,KIND'
- Insert (`Z0') or remove (`z0') a memory breakpoint at address ADDR
- of type KIND.
-
- A memory breakpoint is implemented by replacing the instruction at
- ADDR with a software breakpoint or trap instruction. The KIND is
- target-specific and typically indicates the size of the breakpoint
- in bytes that should be inserted. E.g., the ARM and MIPS can
- insert either a 2 or 4 byte breakpoint. Some architectures have
- additional meanings for KIND; see *note Architecture-Specific
- Protocol Details::.
-
- _Implementation note: It is possible for a target to copy or move
- code that contains memory breakpoints (e.g., when implementing
- overlays). The behavior of this packet, in the presence of such a
- target, is not defined._
-
- Reply:
- `OK'
- success
-
- `'
- not supported
-
- `E NN'
- for an error
-
-`z1,ADDR,KIND'
-`Z1,ADDR,KIND'
- Insert (`Z1') or remove (`z1') a hardware breakpoint at address
- ADDR.
-
- A hardware breakpoint is implemented using a mechanism that is not
- dependant on being able to modify the target's memory. KIND has
- the same meaning as in `Z0' packets.
-
- _Implementation note: A hardware breakpoint is not affected by code
- movement._
-
- Reply:
- `OK'
- success
-
- `'
- not supported
-
- `E NN'
- for an error
-
-`z2,ADDR,KIND'
-`Z2,ADDR,KIND'
- Insert (`Z2') or remove (`z2') a write watchpoint at ADDR. KIND
- is interpreted as the number of bytes to watch.
-
- Reply:
- `OK'
- success
-
- `'
- not supported
-
- `E NN'
- for an error
-
-`z3,ADDR,KIND'
-`Z3,ADDR,KIND'
- Insert (`Z3') or remove (`z3') a read watchpoint at ADDR. KIND is
- interpreted as the number of bytes to watch.
-
- Reply:
- `OK'
- success
-
- `'
- not supported
-
- `E NN'
- for an error
-
-`z4,ADDR,KIND'
-`Z4,ADDR,KIND'
- Insert (`Z4') or remove (`z4') an access watchpoint at ADDR. KIND
- is interpreted as the number of bytes to watch.
-
- Reply:
- `OK'
- success
-
- `'
- not supported
-
- `E NN'
- for an error
-
-
-
-File: gdb.info, Node: Stop Reply Packets, Next: General Query Packets, Prev: Packets, Up: Remote Protocol
-
-E.3 Stop Reply Packets
-======================
-
-The `C', `c', `S', `s', `vCont', `vAttach', `vRun', `vStopped', and `?'
-packets can receive any of the below as a reply. Except for `?' and
-`vStopped', that reply is only returned when the target halts. In the
-below the exact meaning of "signal number" is defined by the header
-`include/gdb/signals.h' in the GDB source code.
-
- As in the description of request packets, we include spaces in the
-reply templates for clarity; these are not part of the reply packet's
-syntax. No GDB stop reply packet uses spaces to separate its
-components.
-
-`S AA'
- The program received signal number AA (a two-digit hexadecimal
- number). This is equivalent to a `T' response with no N:R pairs.
-
-`T AA N1:R1;N2:R2;...'
- The program received signal number AA (a two-digit hexadecimal
- number). This is equivalent to an `S' response, except that the
- `N:R' pairs can carry values of important registers and other
- information directly in the stop reply packet, reducing round-trip
- latency. Single-step and breakpoint traps are reported this way.
- Each `N:R' pair is interpreted as follows:
-
- * If N is a hexadecimal number, it is a register number, and the
- corresponding R gives that register's value. R is a series
- of bytes in target byte order, with each byte given by a
- two-digit hex number.
-
- * If N is `thread', then R is the THREAD-ID of the stopped
- thread, as specified in *note thread-id syntax::.
-
- * If N is `core', then R is the hexadecimal number of the core
- on which the stop event was detected.
-
- * If N is a recognized "stop reason", it describes a more
- specific event that stopped the target. The currently
- defined stop reasons are listed below. AA should be `05',
- the trap signal. At most one stop reason should be present.
-
- * Otherwise, GDB should ignore this `N:R' pair and go on to the
- next; this allows us to extend the protocol in the future.
-
- The currently defined stop reasons are:
-
- `watch'
- `rwatch'
- `awatch'
- The packet indicates a watchpoint hit, and R is the data
- address, in hex.
-
- `library'
- The packet indicates that the loaded libraries have changed.
- GDB should use `qXfer:libraries:read' to fetch a new list of
- loaded libraries. R is ignored.
-
- `replaylog'
- The packet indicates that the target cannot continue replaying
- logged execution events, because it has reached the end (or
- the beginning when executing backward) of the log. The value
- of R will be either `begin' or `end'. *Note Reverse
- Execution::, for more information.
-
-`W AA'
-`W AA ; process:PID'
- The process exited, and AA is the exit status. This is only
- applicable to certain targets.
-
- The second form of the response, including the process ID of the
- exited process, can be used only when GDB has reported support for
- multiprocess protocol extensions; see *note multiprocess
- extensions::. The PID is formatted as a big-endian hex string.
-
-`X AA'
-`X AA ; process:PID'
- The process terminated with signal AA.
-
- The second form of the response, including the process ID of the
- terminated process, can be used only when GDB has reported support
- for multiprocess protocol extensions; see *note multiprocess
- extensions::. The PID is formatted as a big-endian hex string.
-
-`O XX...'
- `XX...' is hex encoding of ASCII data, to be written as the
- program's console output. This can happen at any time while the
- program is running and the debugger should continue to wait for
- `W', `T', etc. This reply is not permitted in non-stop mode.
-
-`F CALL-ID,PARAMETER...'
- CALL-ID is the identifier which says which host system call should
- be called. This is just the name of the function. Translation
- into the correct system call is only applicable as it's defined in
- GDB. *Note File-I/O Remote Protocol Extension::, for a list of
- implemented system calls.
-
- `PARAMETER...' is a list of parameters as defined for this very
- system call.
-
- The target replies with this packet when it expects GDB to call a
- host system call on behalf of the target. GDB replies with an
- appropriate `F' packet and keeps up waiting for the next reply
- packet from the target. The latest `C', `c', `S' or `s' action is
- expected to be continued. *Note File-I/O Remote Protocol
- Extension::, for more details.
-
-
-
-File: gdb.info, Node: General Query Packets, Next: Architecture-Specific Protocol Details, Prev: Stop Reply Packets, Up: Remote Protocol
-
-E.4 General Query Packets
-=========================
-
-Packets starting with `q' are "general query packets"; packets starting
-with `Q' are "general set packets". General query and set packets are
-a semi-unified form for retrieving and sending information to and from
-the stub.
-
- The initial letter of a query or set packet is followed by a name
-indicating what sort of thing the packet applies to. For example, GDB
-may use a `qSymbol' packet to exchange symbol definitions with the
-stub. These packet names follow some conventions:
-
- * The name must not contain commas, colons or semicolons.
-
- * Most GDB query and set packets have a leading upper case letter.
-
- * The names of custom vendor packets should use a company prefix, in
- lower case, followed by a period. For example, packets designed at
- the Acme Corporation might begin with `qacme.foo' (for querying
- foos) or `Qacme.bar' (for setting bars).
-
- The name of a query or set packet should be separated from any
-parameters by a `:'; the parameters themselves should be separated by
-`,' or `;'. Stubs must be careful to match the full packet name, and
-check for a separator or the end of the packet, in case two packet
-names share a common prefix. New packets should not begin with `qC',
-`qP', or `qL'(1).
-
- Like the descriptions of the other packets, each description here
-has a template showing the packet's overall syntax, followed by an
-explanation of the packet's meaning. We include spaces in some of the
-templates for clarity; these are not part of the packet's syntax. No
-GDB packet uses spaces to separate its components.
-
- Here are the currently defined query and set packets:
-
-`QAllow:OP:VAL...'
- Specify which operations GDB expects to request of the target, as
- a semicolon-separated list of operation name and value pairs.
- Possible values for OP include `WriteReg', `WriteMem',
- `InsertBreak', `InsertTrace', `InsertFastTrace', and `Stop'. VAL
- is either 0, indicating that GDB will not request the operation,
- or 1, indicating that it may. (The target can then use this to
- set up its own internals optimally, for instance if the debugger
- never expects to insert breakpoints, it may not need to install
- its own trap handler.)
-
-`qC'
- Return the current thread ID.
-
- Reply:
- `QC THREAD-ID'
- Where THREAD-ID is a thread ID as documented in *note
- thread-id syntax::.
-
- `(anything else)'
- Any other reply implies the old thread ID.
-
-`qCRC:ADDR,LENGTH'
- Compute the CRC checksum of a block of memory using CRC-32 defined
- in IEEE 802.3. The CRC is computed byte at a time, taking the most
- significant bit of each byte first. The initial pattern code
- `0xffffffff' is used to ensure leading zeros affect the CRC.
-
- _Note:_ This is the same CRC used in validating separate debug
- files (*note Debugging Information in Separate Files: Separate
- Debug Files.). However the algorithm is slightly different. When
- validating separate debug files, the CRC is computed taking the
- _least_ significant bit of each byte first, and the final result
- is inverted to detect trailing zeros.
-
- Reply:
- `E NN'
- An error (such as memory fault)
-
- `C CRC32'
- The specified memory region's checksum is CRC32.
-
-`qfThreadInfo'
-`qsThreadInfo'
- Obtain a list of all active thread IDs from the target (OS).
- Since there may be too many active threads to fit into one reply
- packet, this query works iteratively: it may require more than one
- query/reply sequence to obtain the entire list of threads. The
- first query of the sequence will be the `qfThreadInfo' query;
- subsequent queries in the sequence will be the `qsThreadInfo'
- query.
-
- NOTE: This packet replaces the `qL' query (see below).
-
- Reply:
- `m THREAD-ID'
- A single thread ID
-
- `m THREAD-ID,THREAD-ID...'
- a comma-separated list of thread IDs
-
- `l'
- (lower case letter `L') denotes end of list.
-
- In response to each query, the target will reply with a list of
- one or more thread IDs, separated by commas. GDB will respond to
- each reply with a request for more thread ids (using the `qs' form
- of the query), until the target responds with `l' (lower-case ell,
- for "last"). Refer to *note thread-id syntax::, for the format of
- the THREAD-ID fields.
-
-`qGetTLSAddr:THREAD-ID,OFFSET,LM'
- Fetch the address associated with thread local storage specified
- by THREAD-ID, OFFSET, and LM.
-
- THREAD-ID is the thread ID associated with the thread for which to
- fetch the TLS address. *Note thread-id syntax::.
-
- OFFSET is the (big endian, hex encoded) offset associated with the
- thread local variable. (This offset is obtained from the debug
- information associated with the variable.)
-
- LM is the (big endian, hex encoded) OS/ABI-specific encoding of the
- the load module associated with the thread local storage. For
- example, a GNU/Linux system will pass the link map address of the
- shared object associated with the thread local storage under
- consideration. Other operating environments may choose to
- represent the load module differently, so the precise meaning of
- this parameter will vary.
-
- Reply:
- `XX...'
- Hex encoded (big endian) bytes representing the address of
- the thread local storage requested.
-
- `E NN'
- An error occurred. NN are hex digits.
-
- `'
- An empty reply indicates that `qGetTLSAddr' is not supported
- by the stub.
-
-`qGetTIBAddr:THREAD-ID'
- Fetch address of the Windows OS specific Thread Information Block.
-
- THREAD-ID is the thread ID associated with the thread.
-
- Reply:
- `XX...'
- Hex encoded (big endian) bytes representing the linear
- address of the thread information block.
-
- `E NN'
- An error occured. This means that either the thread was not
- found, or the address could not be retrieved.
-
- `'
- An empty reply indicates that `qGetTIBAddr' is not supported
- by the stub.
-
-`qL STARTFLAG THREADCOUNT NEXTTHREAD'
- Obtain thread information from RTOS. Where: STARTFLAG (one hex
- digit) is one to indicate the first query and zero to indicate a
- subsequent query; THREADCOUNT (two hex digits) is the maximum
- number of threads the response packet can contain; and NEXTTHREAD
- (eight hex digits), for subsequent queries (STARTFLAG is zero), is
- returned in the response as ARGTHREAD.
-
- Don't use this packet; use the `qfThreadInfo' query instead (see
- above).
-
- Reply:
- `qM COUNT DONE ARGTHREAD THREAD...'
- Where: COUNT (two hex digits) is the number of threads being
- returned; DONE (one hex digit) is zero to indicate more
- threads and one indicates no further threads; ARGTHREADID
- (eight hex digits) is NEXTTHREAD from the request packet;
- THREAD... is a sequence of thread IDs from the target.
- THREADID (eight hex digits). See
- `remote.c:parse_threadlist_response()'.
-
-`qOffsets'
- Get section offsets that the target used when relocating the
- downloaded image.
-
- Reply:
- `Text=XXX;Data=YYY[;Bss=ZZZ]'
- Relocate the `Text' section by XXX from its original address.
- Relocate the `Data' section by YYY from its original address.
- If the object file format provides segment information (e.g.
- ELF `PT_LOAD' program headers), GDB will relocate entire
- segments by the supplied offsets.
-
- _Note: while a `Bss' offset may be included in the response,
- GDB ignores this and instead applies the `Data' offset to the
- `Bss' section._
-
- `TextSeg=XXX[;DataSeg=YYY]'
- Relocate the first segment of the object file, which
- conventionally contains program code, to a starting address
- of XXX. If `DataSeg' is specified, relocate the second
- segment, which conventionally contains modifiable data, to a
- starting address of YYY. GDB will report an error if the
- object file does not contain segment information, or does not
- contain at least as many segments as mentioned in the reply.
- Extra segments are kept at fixed offsets relative to the last
- relocated segment.
-
-`qP MODE THREAD-ID'
- Returns information on THREAD-ID. Where: MODE is a hex encoded 32
- bit mode; THREAD-ID is a thread ID (*note thread-id syntax::).
-
- Don't use this packet; use the `qThreadExtraInfo' query instead
- (see below).
-
- Reply: see `remote.c:remote_unpack_thread_info_response()'.
-
-`QNonStop:1'
-
-`QNonStop:0'
- Enter non-stop (`QNonStop:1') or all-stop (`QNonStop:0') mode.
- *Note Remote Non-Stop::, for more information.
-
- Reply:
- `OK'
- The request succeeded.
-
- `E NN'
- An error occurred. NN are hex digits.
-
- `'
- An empty reply indicates that `QNonStop' is not supported by
- the stub.
-
- This packet is not probed by default; the remote stub must request
- it, by supplying an appropriate `qSupported' response (*note
- qSupported::). Use of this packet is controlled by the `set
- non-stop' command; *note Non-Stop Mode::.
-
-`QPassSignals: SIGNAL [;SIGNAL]...'
- Each listed SIGNAL should be passed directly to the inferior
- process. Signals are numbered identically to continue packets and
- stop replies (*note Stop Reply Packets::). Each SIGNAL list item
- should be strictly greater than the previous item. These signals
- do not need to stop the inferior, or be reported to GDB. All
- other signals should be reported to GDB. Multiple `QPassSignals'
- packets do not combine; any earlier `QPassSignals' list is
- completely replaced by the new list. This packet improves
- performance when using `handle SIGNAL nostop noprint pass'.
-
- Reply:
- `OK'
- The request succeeded.
-
- `E NN'
- An error occurred. NN are hex digits.
-
- `'
- An empty reply indicates that `QPassSignals' is not supported
- by the stub.
-
- Use of this packet is controlled by the `set remote pass-signals'
- command (*note set remote pass-signals: Remote Configuration.).
- This packet is not probed by default; the remote stub must request
- it, by supplying an appropriate `qSupported' response (*note
- qSupported::).
-
-`qRcmd,COMMAND'
- COMMAND (hex encoded) is passed to the local interpreter for
- execution. Invalid commands should be reported using the output
- string. Before the final result packet, the target may also
- respond with a number of intermediate `OOUTPUT' console output
- packets. _Implementors should note that providing access to a
- stubs's interpreter may have security implications_.
-
- Reply:
- `OK'
- A command response with no output.
-
- `OUTPUT'
- A command response with the hex encoded output string OUTPUT.
-
- `E NN'
- Indicate a badly formed request.
-
- `'
- An empty reply indicates that `qRcmd' is not recognized.
-
- (Note that the `qRcmd' packet's name is separated from the command
- by a `,', not a `:', contrary to the naming conventions above.
- Please don't use this packet as a model for new packets.)
-
-`qSearch:memory:ADDRESS;LENGTH;SEARCH-PATTERN'
- Search LENGTH bytes at ADDRESS for SEARCH-PATTERN. ADDRESS and
- LENGTH are encoded in hex. SEARCH-PATTERN is a sequence of bytes,
- hex encoded.
-
- Reply:
- `0'
- The pattern was not found.
-
- `1,address'
- The pattern was found at ADDRESS.
-
- `E NN'
- A badly formed request or an error was encountered while
- searching memory.
-
- `'
- An empty reply indicates that `qSearch:memory' is not
- recognized.
-
-`QStartNoAckMode'
- Request that the remote stub disable the normal `+'/`-' protocol
- acknowledgments (*note Packet Acknowledgment::).
-
- Reply:
- `OK'
- The stub has switched to no-acknowledgment mode. GDB
- acknowledges this reponse, but neither the stub nor GDB shall
- send or expect further `+'/`-' acknowledgments in the current
- connection.
-
- `'
- An empty reply indicates that the stub does not support
- no-acknowledgment mode.
-
-`qSupported [:GDBFEATURE [;GDBFEATURE]... ]'
- Tell the remote stub about features supported by GDB, and query
- the stub for features it supports. This packet allows GDB and the
- remote stub to take advantage of each others' features.
- `qSupported' also consolidates multiple feature probes at startup,
- to improve GDB performance--a single larger packet performs better
- than multiple smaller probe packets on high-latency links. Some
- features may enable behavior which must not be on by default, e.g.
- because it would confuse older clients or stubs. Other features
- may describe packets which could be automatically probed for, but
- are not. These features must be reported before GDB will use
- them. This "default unsupported" behavior is not appropriate for
- all packets, but it helps to keep the initial connection time
- under control with new versions of GDB which support increasing
- numbers of packets.
-
- Reply:
- `STUBFEATURE [;STUBFEATURE]...'
- The stub supports or does not support each returned
- STUBFEATURE, depending on the form of each STUBFEATURE (see
- below for the possible forms).
-
- `'
- An empty reply indicates that `qSupported' is not recognized,
- or that no features needed to be reported to GDB.
-
- The allowed forms for each feature (either a GDBFEATURE in the
- `qSupported' packet, or a STUBFEATURE in the response) are:
-
- `NAME=VALUE'
- The remote protocol feature NAME is supported, and associated
- with the specified VALUE. The format of VALUE depends on the
- feature, but it must not include a semicolon.
-
- `NAME+'
- The remote protocol feature NAME is supported, and does not
- need an associated value.
-
- `NAME-'
- The remote protocol feature NAME is not supported.
-
- `NAME?'
- The remote protocol feature NAME may be supported, and GDB
- should auto-detect support in some other way when it is
- needed. This form will not be used for GDBFEATURE
- notifications, but may be used for STUBFEATURE responses.
-
- Whenever the stub receives a `qSupported' request, the supplied
- set of GDB features should override any previous request. This
- allows GDB to put the stub in a known state, even if the stub had
- previously been communicating with a different version of GDB.
-
- The following values of GDBFEATURE (for the packet sent by GDB)
- are defined:
-
- `multiprocess'
- This feature indicates whether GDB supports multiprocess
- extensions to the remote protocol. GDB does not use such
- extensions unless the stub also reports that it supports them
- by including `multiprocess+' in its `qSupported' reply.
- *Note multiprocess extensions::, for details.
-
- `xmlRegisters'
- This feature indicates that GDB supports the XML target
- description. If the stub sees `xmlRegisters=' with target
- specific strings separated by a comma, it will report register
- description.
-
- `qRelocInsn'
- This feature indicates whether GDB supports the `qRelocInsn'
- packet (*note Relocate instruction reply packet: Tracepoint
- Packets.).
-
- Stubs should ignore any unknown values for GDBFEATURE. Any GDB
- which sends a `qSupported' packet supports receiving packets of
- unlimited length (earlier versions of GDB may reject overly long
- responses). Additional values for GDBFEATURE may be defined in
- the future to let the stub take advantage of new features in GDB,
- e.g. incompatible improvements in the remote protocol--the
- `multiprocess' feature is an example of such a feature. The
- stub's reply should be independent of the GDBFEATURE entries sent
- by GDB; first GDB describes all the features it supports, and then
- the stub replies with all the features it supports.
-
- Similarly, GDB will silently ignore unrecognized stub feature
- responses, as long as each response uses one of the standard forms.
-
- Some features are flags. A stub which supports a flag feature
- should respond with a `+' form response. Other features require
- values, and the stub should respond with an `=' form response.
-
- Each feature has a default value, which GDB will use if
- `qSupported' is not available or if the feature is not mentioned
- in the `qSupported' response. The default values are fixed; a
- stub is free to omit any feature responses that match the defaults.
-
- Not all features can be probed, but for those which can, the
- probing mechanism is useful: in some cases, a stub's internal
- architecture may not allow the protocol layer to know some
- information about the underlying target in advance. This is
- especially common in stubs which may be configured for multiple
- targets.
-
- These are the currently defined stub features and their properties:
-
- Feature Name Value Default Probe Allowed
- Required
- `PacketSize' Yes `-' No
- `qXfer:auxv:read' No `-' Yes
- `qXfer:features:read' No `-' Yes
- `qXfer:libraries:read' No `-' Yes
- `qXfer:memory-map:read' No `-' Yes
- `qXfer:sdata:read' No `-' Yes
- `qXfer:spu:read' No `-' Yes
- `qXfer:spu:write' No `-' Yes
- `qXfer:siginfo:read' No `-' Yes
- `qXfer:siginfo:write' No `-' Yes
- `qXfer:threads:read' No `-' Yes
- `qXfer:traceframe-info:read'No `-' Yes
- `QNonStop' No `-' Yes
- `QPassSignals' No `-' Yes
- `QStartNoAckMode' No `-' Yes
- `multiprocess' No `-' No
- `ConditionalTracepoints'No `-' No
- `ReverseContinue' No `-' No
- `ReverseStep' No `-' No
- `TracepointSource' No `-' No
- `QAllow' No `-' No
-
- These are the currently defined stub features, in more detail:
-
- `PacketSize=BYTES'
- The remote stub can accept packets up to at least BYTES in
- length. GDB will send packets up to this size for bulk
- transfers, and will never send larger packets. This is a
- limit on the data characters in the packet, including the
- frame and checksum. There is no trailing NUL byte in a
- remote protocol packet; if the stub stores packets in a
- NUL-terminated format, it should allow an extra byte in its
- buffer for the NUL. If this stub feature is not supported,
- GDB guesses based on the size of the `g' packet response.
-
- `qXfer:auxv:read'
- The remote stub understands the `qXfer:auxv:read' packet
- (*note qXfer auxiliary vector read::).
-
- `qXfer:features:read'
- The remote stub understands the `qXfer:features:read' packet
- (*note qXfer target description read::).
-
- `qXfer:libraries:read'
- The remote stub understands the `qXfer:libraries:read' packet
- (*note qXfer library list read::).
-
- `qXfer:memory-map:read'
- The remote stub understands the `qXfer:memory-map:read' packet
- (*note qXfer memory map read::).
-
- `qXfer:sdata:read'
- The remote stub understands the `qXfer:sdata:read' packet
- (*note qXfer sdata read::).
-
- `qXfer:spu:read'
- The remote stub understands the `qXfer:spu:read' packet
- (*note qXfer spu read::).
-
- `qXfer:spu:write'
- The remote stub understands the `qXfer:spu:write' packet
- (*note qXfer spu write::).
-
- `qXfer:siginfo:read'
- The remote stub understands the `qXfer:siginfo:read' packet
- (*note qXfer siginfo read::).
-
- `qXfer:siginfo:write'
- The remote stub understands the `qXfer:siginfo:write' packet
- (*note qXfer siginfo write::).
-
- `qXfer:threads:read'
- The remote stub understands the `qXfer:threads:read' packet
- (*note qXfer threads read::).
-
- `qXfer:traceframe-info:read'
- The remote stub understands the `qXfer:traceframe-info:read'
- packet (*note qXfer traceframe info read::).
-
- `QNonStop'
- The remote stub understands the `QNonStop' packet (*note
- QNonStop::).
-
- `QPassSignals'
- The remote stub understands the `QPassSignals' packet (*note
- QPassSignals::).
-
- `QStartNoAckMode'
- The remote stub understands the `QStartNoAckMode' packet and
- prefers to operate in no-acknowledgment mode. *Note Packet
- Acknowledgment::.
-
- `multiprocess'
- The remote stub understands the multiprocess extensions to
- the remote protocol syntax. The multiprocess extensions
- affect the syntax of thread IDs in both packets and replies
- (*note thread-id syntax::), and add process IDs to the `D'
- packet and `W' and `X' replies. Note that reporting this
- feature indicates support for the syntactic extensions only,
- not that the stub necessarily supports debugging of more than
- one process at a time. The stub must not use multiprocess
- extensions in packet replies unless GDB has also indicated it
- supports them in its `qSupported' request.
-
- `qXfer:osdata:read'
- The remote stub understands the `qXfer:osdata:read' packet
- ((*note qXfer osdata read::).
-
- `ConditionalTracepoints'
- The remote stub accepts and implements conditional
- expressions defined for tracepoints (*note Tracepoint
- Conditions::).
-
- `ReverseContinue'
- The remote stub accepts and implements the reverse continue
- packet (*note bc::).
-
- `ReverseStep'
- The remote stub accepts and implements the reverse step packet
- (*note bs::).
-
- `TracepointSource'
- The remote stub understands the `QTDPsrc' packet that supplies
- the source form of tracepoint definitions.
-
- `QAllow'
- The remote stub understands the `QAllow' packet.
-
- `StaticTracepoint'
- The remote stub supports static tracepoints.
-
-
-`qSymbol::'
- Notify the target that GDB is prepared to serve symbol lookup
- requests. Accept requests from the target for the values of
- symbols.
-
- Reply:
- `OK'
- The target does not need to look up any (more) symbols.
-
- `qSymbol:SYM_NAME'
- The target requests the value of symbol SYM_NAME (hex
- encoded). GDB may provide the value by using the
- `qSymbol:SYM_VALUE:SYM_NAME' message, described below.
-
-`qSymbol:SYM_VALUE:SYM_NAME'
- Set the value of SYM_NAME to SYM_VALUE.
-
- SYM_NAME (hex encoded) is the name of a symbol whose value the
- target has previously requested.
-
- SYM_VALUE (hex) is the value for symbol SYM_NAME. If GDB cannot
- supply a value for SYM_NAME, then this field will be empty.
-
- Reply:
- `OK'
- The target does not need to look up any (more) symbols.
-
- `qSymbol:SYM_NAME'
- The target requests the value of a new symbol SYM_NAME (hex
- encoded). GDB will continue to supply the values of symbols
- (if available), until the target ceases to request them.
-
-`qTBuffer'
-
-`QTBuffer'
-
-`QTDisconnected'
-`QTDP'
-`QTDPsrc'
-`QTDV'
-`qTfP'
-`qTfV'
-`QTFrame'
- *Note Tracepoint Packets::.
-
-`qThreadExtraInfo,THREAD-ID'
- Obtain a printable string description of a thread's attributes from
- the target OS. THREAD-ID is a thread ID; see *note thread-id
- syntax::. This string may contain anything that the target OS
- thinks is interesting for GDB to tell the user about the thread.
- The string is displayed in GDB's `info threads' display. Some
- examples of possible thread extra info strings are `Runnable', or
- `Blocked on Mutex'.
-
- Reply:
- `XX...'
- Where `XX...' is a hex encoding of ASCII data, comprising the
- printable string containing the extra information about the
- thread's attributes.
-
- (Note that the `qThreadExtraInfo' packet's name is separated from
- the command by a `,', not a `:', contrary to the naming
- conventions above. Please don't use this packet as a model for new
- packets.)
-
-`QTSave'
-
-`qTsP'
-
-`qTsV'
-`QTStart'
-`QTStop'
-`QTinit'
-`QTro'
-`qTStatus'
-`qTV'
-`qTfSTM'
-`qTsSTM'
-`qTSTMat'
- *Note Tracepoint Packets::.
-
-`qXfer:OBJECT:read:ANNEX:OFFSET,LENGTH'
- Read uninterpreted bytes from the target's special data area
- identified by the keyword OBJECT. Request LENGTH bytes starting
- at OFFSET bytes into the data. The content and encoding of ANNEX
- is specific to OBJECT; it can supply additional details about what
- data to access.
-
- Here are the specific requests of this form defined so far. All
- `qXfer:OBJECT:read:...' requests use the same reply formats,
- listed below.
-
- `qXfer:auxv:read::OFFSET,LENGTH'
- Access the target's "auxiliary vector". *Note auxiliary
- vector: OS Information. Note ANNEX must be empty.
-
- This packet is not probed by default; the remote stub must
- request it, by supplying an appropriate `qSupported' response
- (*note qSupported::).
-
- `qXfer:features:read:ANNEX:OFFSET,LENGTH'
- Access the "target description". *Note Target
- Descriptions::. The annex specifies which XML document to
- access. The main description is always loaded from the
- `target.xml' annex.
-
- This packet is not probed by default; the remote stub must
- request it, by supplying an appropriate `qSupported' response
- (*note qSupported::).
-
- `qXfer:libraries:read:ANNEX:OFFSET,LENGTH'
- Access the target's list of loaded libraries. *Note Library
- List Format::. The annex part of the generic `qXfer' packet
- must be empty (*note qXfer read::).
-
- Targets which maintain a list of libraries in the program's
- memory do not need to implement this packet; it is designed
- for platforms where the operating system manages the list of
- loaded libraries.
-
- This packet is not probed by default; the remote stub must
- request it, by supplying an appropriate `qSupported' response
- (*note qSupported::).
-
- `qXfer:memory-map:read::OFFSET,LENGTH'
- Access the target's "memory-map". *Note Memory Map Format::.
- The annex part of the generic `qXfer' packet must be empty
- (*note qXfer read::).
-
- This packet is not probed by default; the remote stub must
- request it, by supplying an appropriate `qSupported' response
- (*note qSupported::).
-
- `qXfer:sdata:read::OFFSET,LENGTH'
- Read contents of the extra collected static tracepoint marker
- information. The annex part of the generic `qXfer' packet
- must be empty (*note qXfer read::). *Note Tracepoint Action
- Lists: Tracepoint Actions.
-
- This packet is not probed by default; the remote stub must
- request it, by supplying an appropriate `qSupported' response
- (*note qSupported::).
-
- `qXfer:siginfo:read::OFFSET,LENGTH'
- Read contents of the extra signal information on the target
- system. The annex part of the generic `qXfer' packet must be
- empty (*note qXfer read::).
-
- This packet is not probed by default; the remote stub must
- request it, by supplying an appropriate `qSupported' response
- (*note qSupported::).
-
- `qXfer:spu:read:ANNEX:OFFSET,LENGTH'
- Read contents of an `spufs' file on the target system. The
- annex specifies which file to read; it must be of the form
- `ID/NAME', where ID specifies an SPU context ID in the target
- process, and NAME identifes the `spufs' file in that context
- to be accessed.
-
- This packet is not probed by default; the remote stub must
- request it, by supplying an appropriate `qSupported' response
- (*note qSupported::).
-
- `qXfer:threads:read::OFFSET,LENGTH'
- Access the list of threads on target. *Note Thread List
- Format::. The annex part of the generic `qXfer' packet must
- be empty (*note qXfer read::).
-
- This packet is not probed by default; the remote stub must
- request it, by supplying an appropriate `qSupported' response
- (*note qSupported::).
-
- `qXfer:traceframe-info:read::OFFSET,LENGTH'
- Return a description of the current traceframe's contents.
- *Note Traceframe Info Format::. The annex part of the generic
- `qXfer' packet must be empty (*note qXfer read::).
-
- This packet is not probed by default; the remote stub must
- request it, by supplying an appropriate `qSupported' response
- (*note qSupported::).
-
- `qXfer:osdata:read::OFFSET,LENGTH'
- Access the target's "operating system information". *Note
- Operating System Information::.
-
-
- Reply:
- `m DATA'
- Data DATA (*note Binary Data::) has been read from the
- target. There may be more data at a higher address (although
- it is permitted to return `m' even for the last valid block
- of data, as long as at least one byte of data was read).
- DATA may have fewer bytes than the LENGTH in the request.
-
- `l DATA'
- Data DATA (*note Binary Data::) has been read from the target.
- There is no more data to be read. DATA may have fewer bytes
- than the LENGTH in the request.
-
- `l'
- The OFFSET in the request is at the end of the data. There
- is no more data to be read.
-
- `E00'
- The request was malformed, or ANNEX was invalid.
-
- `E NN'
- The offset was invalid, or there was an error encountered
- reading the data. NN is a hex-encoded `errno' value.
-
- `'
- An empty reply indicates the OBJECT string was not recognized
- by the stub, or that the object does not support reading.
-
-`qXfer:OBJECT:write:ANNEX:OFFSET:DATA...'
- Write uninterpreted bytes into the target's special data area
- identified by the keyword OBJECT, starting at OFFSET bytes into
- the data. DATA... is the binary-encoded data (*note Binary
- Data::) to be written. The content and encoding of ANNEX is
- specific to OBJECT; it can supply additional details about what
- data to access.
-
- Here are the specific requests of this form defined so far. All
- `qXfer:OBJECT:write:...' requests use the same reply formats,
- listed below.
-
- `qXfer:siginfo:write::OFFSET:DATA...'
- Write DATA to the extra signal information on the target
- system. The annex part of the generic `qXfer' packet must be
- empty (*note qXfer write::).
-
- This packet is not probed by default; the remote stub must
- request it, by supplying an appropriate `qSupported' response
- (*note qSupported::).
-
- `qXfer:spu:write:ANNEX:OFFSET:DATA...'
- Write DATA to an `spufs' file on the target system. The
- annex specifies which file to write; it must be of the form
- `ID/NAME', where ID specifies an SPU context ID in the target
- process, and NAME identifes the `spufs' file in that context
- to be accessed.
-
- This packet is not probed by default; the remote stub must
- request it, by supplying an appropriate `qSupported' response
- (*note qSupported::).
-
- Reply:
- `NN'
- NN (hex encoded) is the number of bytes written. This may be
- fewer bytes than supplied in the request.
-
- `E00'
- The request was malformed, or ANNEX was invalid.
-
- `E NN'
- The offset was invalid, or there was an error encountered
- writing the data. NN is a hex-encoded `errno' value.
-
- `'
- An empty reply indicates the OBJECT string was not recognized
- by the stub, or that the object does not support writing.
-
-`qXfer:OBJECT:OPERATION:...'
- Requests of this form may be added in the future. When a stub does
- not recognize the OBJECT keyword, or its support for OBJECT does
- not recognize the OPERATION keyword, the stub must respond with an
- empty packet.
-
-`qAttached:PID'
- Return an indication of whether the remote server attached to an
- existing process or created a new process. When the multiprocess
- protocol extensions are supported (*note multiprocess
- extensions::), PID is an integer in hexadecimal format identifying
- the target process. Otherwise, GDB will omit the PID field and
- the query packet will be simplified as `qAttached'.
-
- This query is used, for example, to know whether the remote process
- should be detached or killed when a GDB session is ended with the
- `quit' command.
-
- Reply:
- `1'
- The remote server attached to an existing process.
-
- `0'
- The remote server created a new process.
-
- `E NN'
- A badly formed request or an error was encountered.
-
-
- ---------- Footnotes ----------
-
- (1) The `qP' and `qL' packets predate these conventions, and have
-arguments without any terminator for the packet name; we suspect they
-are in widespread use in places that are difficult to upgrade. The
-`qC' packet has no arguments, but some existing stubs (e.g. RedBoot)
-are known to not check for the end of the packet.
-
-
-File: gdb.info, Node: Architecture-Specific Protocol Details, Next: Tracepoint Packets, Prev: General Query Packets, Up: Remote Protocol
-
-E.5 Architecture-Specific Protocol Details
-==========================================
-
-This section describes how the remote protocol is applied to specific
-target architectures. Also see *note Standard Target Features::, for
-details of XML target descriptions for each architecture.
-
-E.5.1 ARM
----------
-
-E.5.1.1 Breakpoint Kinds
-........................
-
-These breakpoint kinds are defined for the `Z0' and `Z1' packets.
-
-2
- 16-bit Thumb mode breakpoint.
-
-3
- 32-bit Thumb mode (Thumb-2) breakpoint.
-
-4
- 32-bit ARM mode breakpoint.
-
-
-E.5.2 MIPS
-----------
-
-E.5.2.1 Register Packet Format
-..............................
-
-The following `g'/`G' packets have previously been defined. In the
-below, some thirty-two bit registers are transferred as sixty-four
-bits. Those registers should be zero/sign extended (which?) to fill
-the space allocated. Register bytes are transferred in target byte
-order. The two nibbles within a register byte are transferred
-most-significant - least-significant.
-
-MIPS32
- All registers are transferred as thirty-two bit quantities in the
- order: 32 general-purpose; sr; lo; hi; bad; cause; pc; 32
- floating-point registers; fsr; fir; fp.
-
-MIPS64
- All registers are transferred as sixty-four bit quantities
- (including thirty-two bit registers such as `sr'). The ordering
- is the same as `MIPS32'.
-
-
-
-File: gdb.info, Node: Tracepoint Packets, Next: Host I/O Packets, Prev: Architecture-Specific Protocol Details, Up: Remote Protocol
-
-E.6 Tracepoint Packets
-======================
-
-Here we describe the packets GDB uses to implement tracepoints (*note
-Tracepoints::).
-
-`QTDP:N:ADDR:ENA:STEP:PASS[:FFLEN][:XLEN,BYTES][-]'
- Create a new tracepoint, number N, at ADDR. If ENA is `E', then
- the tracepoint is enabled; if it is `D', then the tracepoint is
- disabled. STEP is the tracepoint's step count, and PASS is its
- pass count. If an `F' is present, then the tracepoint is to be a
- fast tracepoint, and the FLEN is the number of bytes that the
- target should copy elsewhere to make room for the tracepoint. If
- an `X' is present, it introduces a tracepoint condition, which
- consists of a hexadecimal length, followed by a comma and
- hex-encoded bytes, in a manner similar to action encodings as
- described below. If the trailing `-' is present, further `QTDP'
- packets will follow to specify this tracepoint's actions.
-
- Replies:
- `OK'
- The packet was understood and carried out.
-
- `qRelocInsn'
- *Note Relocate instruction reply packet: Tracepoint Packets.
-
- `'
- The packet was not recognized.
-
-`QTDP:-N:ADDR:[S]ACTION...[-]'
- Define actions to be taken when a tracepoint is hit. N and ADDR
- must be the same as in the initial `QTDP' packet for this
- tracepoint. This packet may only be sent immediately after
- another `QTDP' packet that ended with a `-'. If the trailing `-'
- is present, further `QTDP' packets will follow, specifying more
- actions for this tracepoint.
-
- In the series of action packets for a given tracepoint, at most one
- can have an `S' before its first ACTION. If such a packet is
- sent, it and the following packets define "while-stepping"
- actions. Any prior packets define ordinary actions -- that is,
- those taken when the tracepoint is first hit. If no action packet
- has an `S', then all the packets in the series specify ordinary
- tracepoint actions.
-
- The `ACTION...' portion of the packet is a series of actions,
- concatenated without separators. Each action has one of the
- following forms:
-
- `R MASK'
- Collect the registers whose bits are set in MASK. MASK is a
- hexadecimal number whose I'th bit is set if register number I
- should be collected. (The least significant bit is numbered
- zero.) Note that MASK may be any number of digits long; it
- may not fit in a 32-bit word.
-
- `M BASEREG,OFFSET,LEN'
- Collect LEN bytes of memory starting at the address in
- register number BASEREG, plus OFFSET. If BASEREG is `-1',
- then the range has a fixed address: OFFSET is the address of
- the lowest byte to collect. The BASEREG, OFFSET, and LEN
- parameters are all unsigned hexadecimal values (the `-1'
- value for BASEREG is a special case).
-
- `X LEN,EXPR'
- Evaluate EXPR, whose length is LEN, and collect memory as it
- directs. EXPR is an agent expression, as described in *note
- Agent Expressions::. Each byte of the expression is encoded
- as a two-digit hex number in the packet; LEN is the number of
- bytes in the expression (and thus one-half the number of hex
- digits in the packet).
-
-
- Any number of actions may be packed together in a single `QTDP'
- packet, as long as the packet does not exceed the maximum packet
- length (400 bytes, for many stubs). There may be only one `R'
- action per tracepoint, and it must precede any `M' or `X' actions.
- Any registers referred to by `M' and `X' actions must be collected
- by a preceding `R' action. (The "while-stepping" actions are
- treated as if they were attached to a separate tracepoint, as far
- as these restrictions are concerned.)
-
- Replies:
- `OK'
- The packet was understood and carried out.
-
- `qRelocInsn'
- *Note Relocate instruction reply packet: Tracepoint Packets.
-
- `'
- The packet was not recognized.
-
-`QTDPsrc:N:ADDR:TYPE:START:SLEN:BYTES'
- Specify a source string of tracepoint N at address ADDR. This is
- useful to get accurate reproduction of the tracepoints originally
- downloaded at the beginning of the trace run. TYPE is the name of
- the tracepoint part, such as `cond' for the tracepoint's
- conditional expression (see below for a list of types), while
- BYTES is the string, encoded in hexadecimal.
-
- START is the offset of the BYTES within the overall source string,
- while SLEN is the total length of the source string. This is
- intended for handling source strings that are longer than will fit
- in a single packet.
-
- The available string types are `at' for the location, `cond' for
- the conditional, and `cmd' for an action command. GDB sends a
- separate packet for each command in the action list, in the same
- order in which the commands are stored in the list.
-
- The target does not need to do anything with source strings except
- report them back as part of the replies to the `qTfP'/`qTsP' query
- packets.
-
- Although this packet is optional, and GDB will only send it if the
- target replies with `TracepointSource' *Note General Query
- Packets::, it makes both disconnected tracing and trace files much
- easier to use. Otherwise the user must be careful that the
- tracepoints in effect while looking at trace frames are identical
- to the ones in effect during the trace run; even a small
- discrepancy could cause `tdump' not to work, or a particular trace
- frame not be found.
-
-`QTDV:N:VALUE'
- Create a new trace state variable, number N, with an initial value
- of VALUE, which is a 64-bit signed integer. Both N and VALUE are
- encoded as hexadecimal values. GDB has the option of not using
- this packet for initial values of zero; the target should simply
- create the trace state variables as they are mentioned in
- expressions.
-
-`QTFrame:N'
- Select the N'th tracepoint frame from the buffer, and use the
- register and memory contents recorded there to answer subsequent
- request packets from GDB.
-
- A successful reply from the stub indicates that the stub has found
- the requested frame. The response is a series of parts,
- concatenated without separators, describing the frame we selected.
- Each part has one of the following forms:
-
- `F F'
- The selected frame is number N in the trace frame buffer; F
- is a hexadecimal number. If F is `-1', then there was no
- frame matching the criteria in the request packet.
-
- `T T'
- The selected trace frame records a hit of tracepoint number T;
- T is a hexadecimal number.
-
-
-`QTFrame:pc:ADDR'
- Like `QTFrame:N', but select the first tracepoint frame after the
- currently selected frame whose PC is ADDR; ADDR is a hexadecimal
- number.
-
-`QTFrame:tdp:T'
- Like `QTFrame:N', but select the first tracepoint frame after the
- currently selected frame that is a hit of tracepoint T; T is a
- hexadecimal number.
-
-`QTFrame:range:START:END'
- Like `QTFrame:N', but select the first tracepoint frame after the
- currently selected frame whose PC is between START (inclusive) and
- END (inclusive); START and END are hexadecimal numbers.
-
-`QTFrame:outside:START:END'
- Like `QTFrame:range:START:END', but select the first frame
- _outside_ the given range of addresses (exclusive).
-
-`QTStart'
- Begin the tracepoint experiment. Begin collecting data from
- tracepoint hits in the trace frame buffer. This packet supports
- the `qRelocInsn' reply (*note Relocate instruction reply packet:
- Tracepoint Packets.).
-
-`QTStop'
- End the tracepoint experiment. Stop collecting trace frames.
-
-`QTinit'
- Clear the table of tracepoints, and empty the trace frame buffer.
-
-`QTro:START1,END1:START2,END2:...'
- Establish the given ranges of memory as "transparent". The stub
- will answer requests for these ranges from memory's current
- contents, if they were not collected as part of the tracepoint hit.
-
- GDB uses this to mark read-only regions of memory, like those
- containing program code. Since these areas never change, they
- should still have the same contents they did when the tracepoint
- was hit, so there's no reason for the stub to refuse to provide
- their contents.
-
-`QTDisconnected:VALUE'
- Set the choice to what to do with the tracing run when GDB
- disconnects from the target. A VALUE of 1 directs the target to
- continue the tracing run, while 0 tells the target to stop tracing
- if GDB is no longer in the picture.
-
-`qTStatus'
- Ask the stub if there is a trace experiment running right now.
-
- The reply has the form:
-
- `TRUNNING[;FIELD]...'
- RUNNING is a single digit `1' if the trace is presently
- running, or `0' if not. It is followed by semicolon-separated
- optional fields that an agent may use to report additional
- status.
-
-
- If the trace is not running, the agent may report any of several
- explanations as one of the optional fields:
-
- `tnotrun:0'
- No trace has been run yet.
-
- `tstop:0'
- The trace was stopped by a user-originated stop command.
-
- `tfull:0'
- The trace stopped because the trace buffer filled up.
-
- `tdisconnected:0'
- The trace stopped because GDB disconnected from the target.
-
- `tpasscount:TPNUM'
- The trace stopped because tracepoint TPNUM exceeded its pass
- count.
-
- `terror:TEXT:TPNUM'
- The trace stopped because tracepoint TPNUM had an error. The
- string TEXT is available to describe the nature of the error
- (for instance, a divide by zero in the condition expression).
- TEXT is hex encoded.
-
- `tunknown:0'
- The trace stopped for some other reason.
-
-
- Additional optional fields supply statistical and other
- information. Although not required, they are extremely useful for
- users monitoring the progress of a trace run. If a trace has
- stopped, and these numbers are reported, they must reflect the
- state of the just-stopped trace.
-
- `tframes:N'
- The number of trace frames in the buffer.
-
- `tcreated:N'
- The total number of trace frames created during the run. This
- may be larger than the trace frame count, if the buffer is
- circular.
-
- `tsize:N'
- The total size of the trace buffer, in bytes.
-
- `tfree:N'
- The number of bytes still unused in the buffer.
-
- `circular:N'
- The value of the circular trace buffer flag. `1' means that
- the trace buffer is circular and old trace frames will be
- discarded if necessary to make room, `0' means that the trace
- buffer is linear and may fill up.
-
- `disconn:N'
- The value of the disconnected tracing flag. `1' means that
- tracing will continue after GDB disconnects, `0' means that
- the trace run will stop.
-
-
-`qTV:VAR'
- Ask the stub for the value of the trace state variable number VAR.
-
- Replies:
- `VVALUE'
- The value of the variable is VALUE. This will be the current
- value of the variable if the user is examining a running
- target, or a saved value if the variable was collected in the
- trace frame that the user is looking at. Note that multiple
- requests may result in different reply values, such as when
- requesting values while the program is running.
-
- `U'
- The value of the variable is unknown. This would occur, for
- example, if the user is examining a trace frame in which the
- requested variable was not collected.
-
-`qTfP'
-`qTsP'
- These packets request data about tracepoints that are being used by
- the target. GDB sends `qTfP' to get the first piece of data, and
- multiple `qTsP' to get additional pieces. Replies to these
- packets generally take the form of the `QTDP' packets that define
- tracepoints. (FIXME add detailed syntax)
-
-`qTfV'
-`qTsV'
- These packets request data about trace state variables that are on
- the target. GDB sends `qTfV' to get the first vari of data, and
- multiple `qTsV' to get additional variables. Replies to these
- packets follow the syntax of the `QTDV' packets that define trace
- state variables.
-
-`qTfSTM'
-`qTsSTM'
- These packets request data about static tracepoint markers that
- exist in the target program. GDB sends `qTfSTM' to get the first
- piece of data, and multiple `qTsSTM' to get additional pieces.
- Replies to these packets take the following form:
-
- Reply:
- `m ADDRESS:ID:EXTRA'
- A single marker
-
- `m ADDRESS:ID:EXTRA,ADDRESS:ID:EXTRA...'
- a comma-separated list of markers
-
- `l'
- (lower case letter `L') denotes end of list.
-
- `E NN'
- An error occurred. NN are hex digits.
-
- `'
- An empty reply indicates that the request is not supported by
- the stub.
-
- ADDRESS is encoded in hex. ID and EXTRA are strings encoded in
- hex.
-
- In response to each query, the target will reply with a list of
- one or more markers, separated by commas. GDB will respond to each
- reply with a request for more markers (using the `qs' form of the
- query), until the target responds with `l' (lower-case ell, for
- "last").
-
-`qTSTMat:ADDRESS'
- This packets requests data about static tracepoint markers in the
- target program at ADDRESS. Replies to this packet follow the
- syntax of the `qTfSTM' and `qTsSTM' packets that list static
- tracepoint markers.
-
-`QTSave:FILENAME'
- This packet directs the target to save trace data to the file name
- FILENAME in the target's filesystem. FILENAME is encoded as a hex
- string; the interpretation of the file name (relative vs absolute,
- wild cards, etc) is up to the target.
-
-`qTBuffer:OFFSET,LEN'
- Return up to LEN bytes of the current contents of trace buffer,
- starting at OFFSET. The trace buffer is treated as if it were a
- contiguous collection of traceframes, as per the trace file format.
- The reply consists as many hex-encoded bytes as the target can
- deliver in a packet; it is not an error to return fewer than were
- asked for. A reply consisting of just `l' indicates that no bytes
- are available.
-
-`QTBuffer:circular:VALUE'
- This packet directs the target to use a circular trace buffer if
- VALUE is 1, or a linear buffer if the value is 0.
-
-
-E.6.1 Relocate instruction reply packet
----------------------------------------
-
-When installing fast tracepoints in memory, the target may need to
-relocate the instruction currently at the tracepoint address to a
-different address in memory. For most instructions, a simple copy is
-enough, but, for example, call instructions that implicitly push the
-return address on the stack, and relative branches or other PC-relative
-instructions require offset adjustment, so that the effect of executing
-the instruction at a different address is the same as if it had
-executed in the original location.
-
- In response to several of the tracepoint packets, the target may also
-respond with a number of intermediate `qRelocInsn' request packets
-before the final result packet, to have GDB handle this relocation
-operation. If a packet supports this mechanism, its documentation will
-explicitly say so. See for example the above descriptions for the
-`QTStart' and `QTDP' packets. The format of the request is:
-
-`qRelocInsn:FROM;TO'
- This requests GDB to copy instruction at address FROM to address
- TO, possibly adjusted so that executing the instruction at TO has
- the same effect as executing it at FROM. GDB writes the adjusted
- instruction to target memory starting at TO.
-
- Replies:
-`qRelocInsn:ADJUSTED_SIZE'
- Informs the stub the relocation is complete. ADJUSTED_SIZE is the
- length in bytes of resulting relocated instruction sequence.
-
-`E NN'
- A badly formed request was detected, or an error was encountered
- while relocating the instruction.
-
-
-File: gdb.info, Node: Host I/O Packets, Next: Interrupts, Prev: Tracepoint Packets, Up: Remote Protocol
-
-E.7 Host I/O Packets
-====================
-
-The "Host I/O" packets allow GDB to perform I/O operations on the far
-side of a remote link. For example, Host I/O is used to upload and
-download files to a remote target with its own filesystem. Host I/O
-uses the same constant values and data structure layout as the
-target-initiated File-I/O protocol. However, the Host I/O packets are
-structured differently. The target-initiated protocol relies on target
-memory to store parameters and buffers. Host I/O requests are
-initiated by GDB, and the target's memory is not involved. *Note
-File-I/O Remote Protocol Extension::, for more details on the
-target-initiated protocol.
-
- The Host I/O request packets all encode a single operation along with
-its arguments. They have this format:
-
-`vFile:OPERATION: PARAMETER...'
- OPERATION is the name of the particular request; the target should
- compare the entire packet name up to the second colon when checking
- for a supported operation. The format of PARAMETER depends on the
- operation. Numbers are always passed in hexadecimal. Negative
- numbers have an explicit minus sign (i.e. two's complement is not
- used). Strings (e.g. filenames) are encoded as a series of
- hexadecimal bytes. The last argument to a system call may be a
- buffer of escaped binary data (*note Binary Data::).
-
-
- The valid responses to Host I/O packets are:
-
-`F RESULT [, ERRNO] [; ATTACHMENT]'
- RESULT is the integer value returned by this operation, usually
- non-negative for success and -1 for errors. If an error has
- occured, ERRNO will be included in the result. ERRNO will have a
- value defined by the File-I/O protocol (*note Errno Values::). For
- operations which return data, ATTACHMENT supplies the data as a
- binary buffer. Binary buffers in response packets are escaped in
- the normal way (*note Binary Data::). See the individual packet
- documentation for the interpretation of RESULT and ATTACHMENT.
-
-`'
- An empty response indicates that this operation is not recognized.
-
-
- These are the supported Host I/O operations:
-
-`vFile:open: PATHNAME, FLAGS, MODE'
- Open a file at PATHNAME and return a file descriptor for it, or
- return -1 if an error occurs. PATHNAME is a string, FLAGS is an
- integer indicating a mask of open flags (*note Open Flags::), and
- MODE is an integer indicating a mask of mode bits to use if the
- file is created (*note mode_t Values::). *Note open::, for
- details of the open flags and mode values.
-
-`vFile:close: FD'
- Close the open file corresponding to FD and return 0, or -1 if an
- error occurs.
-
-`vFile:pread: FD, COUNT, OFFSET'
- Read data from the open file corresponding to FD. Up to COUNT
- bytes will be read from the file, starting at OFFSET relative to
- the start of the file. The target may read fewer bytes; common
- reasons include packet size limits and an end-of-file condition.
- The number of bytes read is returned. Zero should only be
- returned for a successful read at the end of the file, or if COUNT
- was zero.
-
- The data read should be returned as a binary attachment on success.
- If zero bytes were read, the response should include an empty
- binary attachment (i.e. a trailing semicolon). The return value
- is the number of target bytes read; the binary attachment may be
- longer if some characters were escaped.
-
-`vFile:pwrite: FD, OFFSET, DATA'
- Write DATA (a binary buffer) to the open file corresponding to FD.
- Start the write at OFFSET from the start of the file. Unlike many
- `write' system calls, there is no separate COUNT argument; the
- length of DATA in the packet is used. `vFile:write' returns the
- number of bytes written, which may be shorter than the length of
- DATA, or -1 if an error occurred.
-
-`vFile:unlink: PATHNAME'
- Delete the file at PATHNAME on the target. Return 0, or -1 if an
- error occurs. PATHNAME is a string.
-
-
-
-File: gdb.info, Node: Interrupts, Next: Notification Packets, Prev: Host I/O Packets, Up: Remote Protocol
-
-E.8 Interrupts
-==============
-
-When a program on the remote target is running, GDB may attempt to
-interrupt it by sending a `Ctrl-C', `BREAK' or a `BREAK' followed by
-`g', control of which is specified via GDB's `interrupt-sequence'.
-
- The precise meaning of `BREAK' is defined by the transport mechanism
-and may, in fact, be undefined. GDB does not currently define a
-`BREAK' mechanism for any of the network interfaces except for TCP, in
-which case GDB sends the `telnet' BREAK sequence.
-
- `Ctrl-C', on the other hand, is defined and implemented for all
-transport mechanisms. It is represented by sending the single byte
-`0x03' without any of the usual packet overhead described in the
-Overview section (*note Overview::). When a `0x03' byte is transmitted
-as part of a packet, it is considered to be packet data and does _not_
-represent an interrupt. E.g., an `X' packet (*note X packet::), used
-for binary downloads, may include an unescaped `0x03' as part of its
-packet.
-
- `BREAK' followed by `g' is also known as Magic SysRq g. When Linux
-kernel receives this sequence from serial port, it stops execution and
-connects to gdb.
-
- Stubs are not required to recognize these interrupt mechanisms and
-the precise meaning associated with receipt of the interrupt is
-implementation defined. If the target supports debugging of multiple
-threads and/or processes, it should attempt to interrupt all
-currently-executing threads and processes. If the stub is successful
-at interrupting the running program, it should send one of the stop
-reply packets (*note Stop Reply Packets::) to GDB as a result of
-successfully stopping the program in all-stop mode, and a stop reply
-for each stopped thread in non-stop mode. Interrupts received while the
-program is stopped are discarded.
-
-
-File: gdb.info, Node: Notification Packets, Next: Remote Non-Stop, Prev: Interrupts, Up: Remote Protocol
-
-E.9 Notification Packets
-========================
-
-The GDB remote serial protocol includes "notifications", packets that
-require no acknowledgment. Both the GDB and the stub may send
-notifications (although the only notifications defined at present are
-sent by the stub). Notifications carry information without incurring
-the round-trip latency of an acknowledgment, and so are useful for
-low-impact communications where occasional packet loss is not a problem.
-
- A notification packet has the form `% DATA # CHECKSUM', where DATA
-is the content of the notification, and CHECKSUM is a checksum of DATA,
-computed and formatted as for ordinary GDB packets. A notification's
-DATA never contains `$', `%' or `#' characters. Upon receiving a
-notification, the recipient sends no `+' or `-' to acknowledge the
-notification's receipt or to report its corruption.
-
- Every notification's DATA begins with a name, which contains no
-colon characters, followed by a colon character.
-
- Recipients should silently ignore corrupted notifications and
-notifications they do not understand. Recipients should restart
-timeout periods on receipt of a well-formed notification, whether or
-not they understand it.
-
- Senders should only send the notifications described here when this
-protocol description specifies that they are permitted. In the future,
-we may extend the protocol to permit existing notifications in new
-contexts; this rule helps older senders avoid confusing newer
-recipients.
-
- (Older versions of GDB ignore bytes received until they see the `$'
-byte that begins an ordinary packet, so new stubs may transmit
-notifications without fear of confusing older clients. There are no
-notifications defined for GDB to send at the moment, but we assume that
-most older stubs would ignore them, as well.)
-
- The following notification packets from the stub to GDB are defined:
-
-`Stop: REPLY'
- Report an asynchronous stop event in non-stop mode. The REPLY has
- the form of a stop reply, as described in *note Stop Reply
- Packets::. Refer to *note Remote Non-Stop::, for information on
- how these notifications are acknowledged by GDB.
-
-
-File: gdb.info, Node: Remote Non-Stop, Next: Packet Acknowledgment, Prev: Notification Packets, Up: Remote Protocol
-
-E.10 Remote Protocol Support for Non-Stop Mode
-==============================================
-
-GDB's remote protocol supports non-stop debugging of multi-threaded
-programs, as described in *note Non-Stop Mode::. If the stub supports
-non-stop mode, it should report that to GDB by including `QNonStop+' in
-its `qSupported' response (*note qSupported::).
-
- GDB typically sends a `QNonStop' packet only when establishing a new
-connection with the stub. Entering non-stop mode does not alter the
-state of any currently-running threads, but targets must stop all
-threads in any already-attached processes when entering all-stop mode.
-GDB uses the `?' packet as necessary to probe the target state after a
-mode change.
-
- In non-stop mode, when an attached process encounters an event that
-would otherwise be reported with a stop reply, it uses the asynchronous
-notification mechanism (*note Notification Packets::) to inform GDB.
-In contrast to all-stop mode, where all threads in all processes are
-stopped when a stop reply is sent, in non-stop mode only the thread
-reporting the stop event is stopped. That is, when reporting a `S' or
-`T' response to indicate completion of a step operation, hitting a
-breakpoint, or a fault, only the affected thread is stopped; any other
-still-running threads continue to run. When reporting a `W' or `X'
-response, all running threads belonging to other attached processes
-continue to run.
-
- Only one stop reply notification at a time may be pending; if
-additional stop events occur before GDB has acknowledged the previous
-notification, they must be queued by the stub for later synchronous
-transmission in response to `vStopped' packets from GDB. Because the
-notification mechanism is unreliable, the stub is permitted to resend a
-stop reply notification if it believes GDB may not have received it.
-GDB ignores additional stop reply notifications received before it has
-finished processing a previous notification and the stub has completed
-sending any queued stop events.
-
- Otherwise, GDB must be prepared to receive a stop reply notification
-at any time. Specifically, they may appear when GDB is not otherwise
-reading input from the stub, or when GDB is expecting to read a normal
-synchronous response or a `+'/`-' acknowledgment to a packet it has
-sent. Notification packets are distinct from any other communication
-from the stub so there is no ambiguity.
-
- After receiving a stop reply notification, GDB shall acknowledge it
-by sending a `vStopped' packet (*note vStopped packet::) as a regular,
-synchronous request to the stub. Such acknowledgment is not required
-to happen immediately, as GDB is permitted to send other, unrelated
-packets to the stub first, which the stub should process normally.
-
- Upon receiving a `vStopped' packet, if the stub has other queued
-stop events to report to GDB, it shall respond by sending a normal stop
-reply response. GDB shall then send another `vStopped' packet to
-solicit further responses; again, it is permitted to send other,
-unrelated packets as well which the stub should process normally.
-
- If the stub receives a `vStopped' packet and there are no additional
-stop events to report, the stub shall return an `OK' response. At this
-point, if further stop events occur, the stub shall send a new stop
-reply notification, GDB shall accept the notification, and the process
-shall be repeated.
-
- In non-stop mode, the target shall respond to the `?' packet as
-follows. First, any incomplete stop reply notification/`vStopped'
-sequence in progress is abandoned. The target must begin a new
-sequence reporting stop events for all stopped threads, whether or not
-it has previously reported those events to GDB. The first stop reply
-is sent as a synchronous reply to the `?' packet, and subsequent stop
-replies are sent as responses to `vStopped' packets using the mechanism
-described above. The target must not send asynchronous stop reply
-notifications until the sequence is complete. If all threads are
-running when the target receives the `?' packet, or if the target is
-not attached to any process, it shall respond `OK'.
-
-
-File: gdb.info, Node: Packet Acknowledgment, Next: Examples, Prev: Remote Non-Stop, Up: Remote Protocol
-
-E.11 Packet Acknowledgment
-==========================
-
-By default, when either the host or the target machine receives a
-packet, the first response expected is an acknowledgment: either `+'
-(to indicate the package was received correctly) or `-' (to request
-retransmission). This mechanism allows the GDB remote protocol to
-operate over unreliable transport mechanisms, such as a serial line.
-
- In cases where the transport mechanism is itself reliable (such as a
-pipe or TCP connection), the `+'/`-' acknowledgments are redundant. It
-may be desirable to disable them in that case to reduce communication
-overhead, or for other reasons. This can be accomplished by means of
-the `QStartNoAckMode' packet; *note QStartNoAckMode::.
-
- When in no-acknowledgment mode, neither the stub nor GDB shall send
-or expect `+'/`-' protocol acknowledgments. The packet and response
-format still includes the normal checksum, as described in *note
-Overview::, but the checksum may be ignored by the receiver.
-
- If the stub supports `QStartNoAckMode' and prefers to operate in
-no-acknowledgment mode, it should report that to GDB by including
-`QStartNoAckMode+' in its response to `qSupported'; *note qSupported::.
-If GDB also supports `QStartNoAckMode' and it has not been disabled via
-the `set remote noack-packet off' command (*note Remote
-Configuration::), GDB may then send a `QStartNoAckMode' packet to the
-stub. Only then may the stub actually turn off packet acknowledgments.
-GDB sends a final `+' acknowledgment of the stub's `OK' response, which
-can be safely ignored by the stub.
-
- Note that `set remote noack-packet' command only affects negotiation
-between GDB and the stub when subsequent connections are made; it does
-not affect the protocol acknowledgment state for any current connection.
-Since `+'/`-' acknowledgments are enabled by default when a new
-connection is established, there is also no protocol request to
-re-enable the acknowledgments for the current connection, once disabled.
-
-
-File: gdb.info, Node: Examples, Next: File-I/O Remote Protocol Extension, Prev: Packet Acknowledgment, Up: Remote Protocol
-
-E.12 Examples
-=============
-
-Example sequence of a target being re-started. Notice how the restart
-does not get any direct output:
-
- -> `R00'
- <- `+'
- _target restarts_
- -> `?'
- <- `+'
- <- `T001:1234123412341234'
- -> `+'
-
- Example sequence of a target being stepped by a single instruction:
-
- -> `G1445...'
- <- `+'
- -> `s'
- <- `+'
- _time passes_
- <- `T001:1234123412341234'
- -> `+'
- -> `g'
- <- `+'
- <- `1455...'
- -> `+'
-
-
-File: gdb.info, Node: File-I/O Remote Protocol Extension, Next: Library List Format, Prev: Examples, Up: Remote Protocol
-
-E.13 File-I/O Remote Protocol Extension
-=======================================
-
-* Menu:
-
-* File-I/O Overview::
-* Protocol Basics::
-* The F Request Packet::
-* The F Reply Packet::
-* The Ctrl-C Message::
-* Console I/O::
-* List of Supported Calls::
-* Protocol-specific Representation of Datatypes::
-* Constants::
-* File-I/O Examples::
-
-
-File: gdb.info, Node: File-I/O Overview, Next: Protocol Basics, Up: File-I/O Remote Protocol Extension
-
-E.13.1 File-I/O Overview
-------------------------
-
-The "File I/O remote protocol extension" (short: File-I/O) allows the
-target to use the host's file system and console I/O to perform various
-system calls. System calls on the target system are translated into a
-remote protocol packet to the host system, which then performs the
-needed actions and returns a response packet to the target system.
-This simulates file system operations even on targets that lack file
-systems.
-
- The protocol is defined to be independent of both the host and
-target systems. It uses its own internal representation of datatypes
-and values. Both GDB and the target's GDB stub are responsible for
-translating the system-dependent value representations into the internal
-protocol representations when data is transmitted.
-
- The communication is synchronous. A system call is possible only
-when GDB is waiting for a response from the `C', `c', `S' or `s'
-packets. While GDB handles the request for a system call, the target
-is stopped to allow deterministic access to the target's memory.
-Therefore File-I/O is not interruptible by target signals. On the
-other hand, it is possible to interrupt File-I/O by a user interrupt
-(`Ctrl-C') within GDB.
-
- The target's request to perform a host system call does not finish
-the latest `C', `c', `S' or `s' action. That means, after finishing
-the system call, the target returns to continuing the previous activity
-(continue, step). No additional continue or step request from GDB is
-required.
-
- (gdb) continue
- <- target requests 'system call X'
- target is stopped, GDB executes system call
- -> GDB returns result
- ... target continues, GDB returns to wait for the target
- <- target hits breakpoint and sends a Txx packet
-
- The protocol only supports I/O on the console and to regular files on
-the host file system. Character or block special devices, pipes, named
-pipes, sockets or any other communication method on the host system are
-not supported by this protocol.
-
- File I/O is not supported in non-stop mode.
-
-
-File: gdb.info, Node: Protocol Basics, Next: The F Request Packet, Prev: File-I/O Overview, Up: File-I/O Remote Protocol Extension
-
-E.13.2 Protocol Basics
-----------------------
-
-The File-I/O protocol uses the `F' packet as the request as well as
-reply packet. Since a File-I/O system call can only occur when GDB is
-waiting for a response from the continuing or stepping target, the
-File-I/O request is a reply that GDB has to expect as a result of a
-previous `C', `c', `S' or `s' packet. This `F' packet contains all
-information needed to allow GDB to call the appropriate host system
-call:
-
- * A unique identifier for the requested system call.
-
- * All parameters to the system call. Pointers are given as addresses
- in the target memory address space. Pointers to strings are given
- as pointer/length pair. Numerical values are given as they are.
- Numerical control flags are given in a protocol-specific
- representation.
-
-
- At this point, GDB has to perform the following actions.
-
- * If the parameters include pointer values to data needed as input
- to a system call, GDB requests this data from the target with a
- standard `m' packet request. This additional communication has to
- be expected by the target implementation and is handled as any
- other `m' packet.
-
- * GDB translates all value from protocol representation to host
- representation as needed. Datatypes are coerced into the host
- types.
-
- * GDB calls the system call.
-
- * It then coerces datatypes back to protocol representation.
-
- * If the system call is expected to return data in buffer space
- specified by pointer parameters to the call, the data is
- transmitted to the target using a `M' or `X' packet. This packet
- has to be expected by the target implementation and is handled as
- any other `M' or `X' packet.
-
-
- Eventually GDB replies with another `F' packet which contains all
-necessary information for the target to continue. This at least
-contains
-
- * Return value.
-
- * `errno', if has been changed by the system call.
-
- * "Ctrl-C" flag.
-
-
- After having done the needed type and value coercion, the target
-continues the latest continue or step action.
-
-
-File: gdb.info, Node: The F Request Packet, Next: The F Reply Packet, Prev: Protocol Basics, Up: File-I/O Remote Protocol Extension
-
-E.13.3 The `F' Request Packet
------------------------------
-
-The `F' request packet has the following format:
-
-`FCALL-ID,PARAMETER...'
- CALL-ID is the identifier to indicate the host system call to be
- called. This is just the name of the function.
-
- PARAMETER... are the parameters to the system call. Parameters
- are hexadecimal integer values, either the actual values in case
- of scalar datatypes, pointers to target buffer space in case of
- compound datatypes and unspecified memory areas, or pointer/length
- pairs in case of string parameters. These are appended to the
- CALL-ID as a comma-delimited list. All values are transmitted in
- ASCII string representation, pointer/length pairs separated by a
- slash.
-
-
-
-File: gdb.info, Node: The F Reply Packet, Next: The Ctrl-C Message, Prev: The F Request Packet, Up: File-I/O Remote Protocol Extension
-
-E.13.4 The `F' Reply Packet
----------------------------
-
-The `F' reply packet has the following format:
-
-`FRETCODE,ERRNO,CTRL-C FLAG;CALL-SPECIFIC ATTACHMENT'
- RETCODE is the return code of the system call as hexadecimal value.
-
- ERRNO is the `errno' set by the call, in protocol-specific
- representation. This parameter can be omitted if the call was
- successful.
-
- CTRL-C FLAG is only sent if the user requested a break. In this
- case, ERRNO must be sent as well, even if the call was successful.
- The CTRL-C FLAG itself consists of the character `C':
-
- F0,0,C
-
- or, if the call was interrupted before the host call has been
- performed:
-
- F-1,4,C
-
- assuming 4 is the protocol-specific representation of `EINTR'.
-
-
-
-File: gdb.info, Node: The Ctrl-C Message, Next: Console I/O, Prev: The F Reply Packet, Up: File-I/O Remote Protocol Extension
-
-E.13.5 The `Ctrl-C' Message
----------------------------
-
-If the `Ctrl-C' flag is set in the GDB reply packet (*note The F Reply
-Packet::), the target should behave as if it had gotten a break
-message. The meaning for the target is "system call interrupted by
-`SIGINT'". Consequentially, the target should actually stop (as with a
-break message) and return to GDB with a `T02' packet.
-
- It's important for the target to know in which state the system call
-was interrupted. There are two possible cases:
-
- * The system call hasn't been performed on the host yet.
-
- * The system call on the host has been finished.
-
-
- These two states can be distinguished by the target by the value of
-the returned `errno'. If it's the protocol representation of `EINTR',
-the system call hasn't been performed. This is equivalent to the
-`EINTR' handling on POSIX systems. In any other case, the target may
-presume that the system call has been finished -- successfully or not
--- and should behave as if the break message arrived right after the
-system call.
-
- GDB must behave reliably. If the system call has not been called
-yet, GDB may send the `F' reply immediately, setting `EINTR' as `errno'
-in the packet. If the system call on the host has been finished before
-the user requests a break, the full action must be finished by GDB.
-This requires sending `M' or `X' packets as necessary. The `F' packet
-may only be sent when either nothing has happened or the full action
-has been completed.
-
-
-File: gdb.info, Node: Console I/O, Next: List of Supported Calls, Prev: The Ctrl-C Message, Up: File-I/O Remote Protocol Extension
-
-E.13.6 Console I/O
-------------------
-
-By default and if not explicitly closed by the target system, the file
-descriptors 0, 1 and 2 are connected to the GDB console. Output on the
-GDB console is handled as any other file output operation (`write(1,
-...)' or `write(2, ...)'). Console input is handled by GDB so that
-after the target read request from file descriptor 0 all following
-typing is buffered until either one of the following conditions is met:
-
- * The user types `Ctrl-c'. The behaviour is as explained above, and
- the `read' system call is treated as finished.
-
- * The user presses <RET>. This is treated as end of input with a
- trailing newline.
-
- * The user types `Ctrl-d'. This is treated as end of input. No
- trailing character (neither newline nor `Ctrl-D') is appended to
- the input.
-
-
- If the user has typed more characters than fit in the buffer given to
-the `read' call, the trailing characters are buffered in GDB until
-either another `read(0, ...)' is requested by the target, or debugging
-is stopped at the user's request.
-
-
-File: gdb.info, Node: List of Supported Calls, Next: Protocol-specific Representation of Datatypes, Prev: Console I/O, Up: File-I/O Remote Protocol Extension
-
-E.13.7 List of Supported Calls
-------------------------------
-
-* Menu:
-
-* open::
-* close::
-* read::
-* write::
-* lseek::
-* rename::
-* unlink::
-* stat/fstat::
-* gettimeofday::
-* isatty::
-* system::
-
-
-File: gdb.info, Node: open, Next: close, Up: List of Supported Calls
-
-open
-....
-
-Synopsis:
- int open(const char *pathname, int flags);
- int open(const char *pathname, int flags, mode_t mode);
-
-Request:
- `Fopen,PATHPTR/LEN,FLAGS,MODE'
-
- FLAGS is the bitwise `OR' of the following values:
-
- `O_CREAT'
- If the file does not exist it will be created. The host
- rules apply as far as file ownership and time stamps are
- concerned.
-
- `O_EXCL'
- When used with `O_CREAT', if the file already exists it is an
- error and open() fails.
-
- `O_TRUNC'
- If the file already exists and the open mode allows writing
- (`O_RDWR' or `O_WRONLY' is given) it will be truncated to
- zero length.
-
- `O_APPEND'
- The file is opened in append mode.
-
- `O_RDONLY'
- The file is opened for reading only.
-
- `O_WRONLY'
- The file is opened for writing only.
-
- `O_RDWR'
- The file is opened for reading and writing.
-
- Other bits are silently ignored.
-
- MODE is the bitwise `OR' of the following values:
-
- `S_IRUSR'
- User has read permission.
-
- `S_IWUSR'
- User has write permission.
-
- `S_IRGRP'
- Group has read permission.
-
- `S_IWGRP'
- Group has write permission.
-
- `S_IROTH'
- Others have read permission.
-
- `S_IWOTH'
- Others have write permission.
-
- Other bits are silently ignored.
-
-Return value:
- `open' returns the new file descriptor or -1 if an error occurred.
-
-Errors:
-
- `EEXIST'
- PATHNAME already exists and `O_CREAT' and `O_EXCL' were used.
-
- `EISDIR'
- PATHNAME refers to a directory.
-
- `EACCES'
- The requested access is not allowed.
-
- `ENAMETOOLONG'
- PATHNAME was too long.
-
- `ENOENT'
- A directory component in PATHNAME does not exist.
-
- `ENODEV'
- PATHNAME refers to a device, pipe, named pipe or socket.
-
- `EROFS'
- PATHNAME refers to a file on a read-only filesystem and write
- access was requested.
-
- `EFAULT'
- PATHNAME is an invalid pointer value.
-
- `ENOSPC'
- No space on device to create the file.
-
- `EMFILE'
- The process already has the maximum number of files open.
-
- `ENFILE'
- The limit on the total number of files open on the system has
- been reached.
-
- `EINTR'
- The call was interrupted by the user.
-
-
-
-File: gdb.info, Node: close, Next: read, Prev: open, Up: List of Supported Calls
-
-close
-.....
-
-Synopsis:
- int close(int fd);
-
-Request:
- `Fclose,FD'
-
-Return value:
- `close' returns zero on success, or -1 if an error occurred.
-
-Errors:
-
- `EBADF'
- FD isn't a valid open file descriptor.
-
- `EINTR'
- The call was interrupted by the user.
-
-
-
-File: gdb.info, Node: read, Next: write, Prev: close, Up: List of Supported Calls
-
-read
-....
-
-Synopsis:
- int read(int fd, void *buf, unsigned int count);
-
-Request:
- `Fread,FD,BUFPTR,COUNT'
-
-Return value:
- On success, the number of bytes read is returned. Zero indicates
- end of file. If count is zero, read returns zero as well. On
- error, -1 is returned.
-
-Errors:
-
- `EBADF'
- FD is not a valid file descriptor or is not open for reading.
-
- `EFAULT'
- BUFPTR is an invalid pointer value.
-
- `EINTR'
- The call was interrupted by the user.
-
-
-
-File: gdb.info, Node: write, Next: lseek, Prev: read, Up: List of Supported Calls
-
-write
-.....
-
-Synopsis:
- int write(int fd, const void *buf, unsigned int count);
-
-Request:
- `Fwrite,FD,BUFPTR,COUNT'
-
-Return value:
- On success, the number of bytes written are returned. Zero
- indicates nothing was written. On error, -1 is returned.
-
-Errors:
-
- `EBADF'
- FD is not a valid file descriptor or is not open for writing.
-
- `EFAULT'
- BUFPTR is an invalid pointer value.
-
- `EFBIG'
- An attempt was made to write a file that exceeds the
- host-specific maximum file size allowed.
-
- `ENOSPC'
- No space on device to write the data.
-
- `EINTR'
- The call was interrupted by the user.
-
-
-
-File: gdb.info, Node: lseek, Next: rename, Prev: write, Up: List of Supported Calls
-
-lseek
-.....
-
-Synopsis:
- long lseek (int fd, long offset, int flag);
-
-Request:
- `Flseek,FD,OFFSET,FLAG'
-
- FLAG is one of:
-
- `SEEK_SET'
- The offset is set to OFFSET bytes.
-
- `SEEK_CUR'
- The offset is set to its current location plus OFFSET bytes.
-
- `SEEK_END'
- The offset is set to the size of the file plus OFFSET bytes.
-
-Return value:
- On success, the resulting unsigned offset in bytes from the
- beginning of the file is returned. Otherwise, a value of -1 is
- returned.
-
-Errors:
-
- `EBADF'
- FD is not a valid open file descriptor.
-
- `ESPIPE'
- FD is associated with the GDB console.
-
- `EINVAL'
- FLAG is not a proper value.
-
- `EINTR'
- The call was interrupted by the user.
-
-
-
-File: gdb.info, Node: rename, Next: unlink, Prev: lseek, Up: List of Supported Calls
-
-rename
-......
-
-Synopsis:
- int rename(const char *oldpath, const char *newpath);
-
-Request:
- `Frename,OLDPATHPTR/LEN,NEWPATHPTR/LEN'
-
-Return value:
- On success, zero is returned. On error, -1 is returned.
-
-Errors:
-
- `EISDIR'
- NEWPATH is an existing directory, but OLDPATH is not a
- directory.
-
- `EEXIST'
- NEWPATH is a non-empty directory.
-
- `EBUSY'
- OLDPATH or NEWPATH is a directory that is in use by some
- process.
-
- `EINVAL'
- An attempt was made to make a directory a subdirectory of
- itself.
-
- `ENOTDIR'
- A component used as a directory in OLDPATH or new path is
- not a directory. Or OLDPATH is a directory and NEWPATH
- exists but is not a directory.
-
- `EFAULT'
- OLDPATHPTR or NEWPATHPTR are invalid pointer values.
-
- `EACCES'
- No access to the file or the path of the file.
-
- `ENAMETOOLONG'
- OLDPATH or NEWPATH was too long.
-
- `ENOENT'
- A directory component in OLDPATH or NEWPATH does not exist.
-
- `EROFS'
- The file is on a read-only filesystem.
-
- `ENOSPC'
- The device containing the file has no room for the new
- directory entry.
-
- `EINTR'
- The call was interrupted by the user.
-
-
-
-File: gdb.info, Node: unlink, Next: stat/fstat, Prev: rename, Up: List of Supported Calls
-
-unlink
-......
-
-Synopsis:
- int unlink(const char *pathname);
-
-Request:
- `Funlink,PATHNAMEPTR/LEN'
-
-Return value:
- On success, zero is returned. On error, -1 is returned.
-
-Errors:
-
- `EACCES'
- No access to the file or the path of the file.
-
- `EPERM'
- The system does not allow unlinking of directories.
-
- `EBUSY'
- The file PATHNAME cannot be unlinked because it's being used
- by another process.
-
- `EFAULT'
- PATHNAMEPTR is an invalid pointer value.
-
- `ENAMETOOLONG'
- PATHNAME was too long.
-
- `ENOENT'
- A directory component in PATHNAME does not exist.
-
- `ENOTDIR'
- A component of the path is not a directory.
-
- `EROFS'
- The file is on a read-only filesystem.
-
- `EINTR'
- The call was interrupted by the user.
-
-
-
-File: gdb.info, Node: stat/fstat, Next: gettimeofday, Prev: unlink, Up: List of Supported Calls
-
-stat/fstat
-..........
-
-Synopsis:
- int stat(const char *pathname, struct stat *buf);
- int fstat(int fd, struct stat *buf);
-
-Request:
- `Fstat,PATHNAMEPTR/LEN,BUFPTR'
- `Ffstat,FD,BUFPTR'
-
-Return value:
- On success, zero is returned. On error, -1 is returned.
-
-Errors:
-
- `EBADF'
- FD is not a valid open file.
-
- `ENOENT'
- A directory component in PATHNAME does not exist or the path
- is an empty string.
-
- `ENOTDIR'
- A component of the path is not a directory.
-
- `EFAULT'
- PATHNAMEPTR is an invalid pointer value.
-
- `EACCES'
- No access to the file or the path of the file.
-
- `ENAMETOOLONG'
- PATHNAME was too long.
-
- `EINTR'
- The call was interrupted by the user.
-
-
-
-File: gdb.info, Node: gettimeofday, Next: isatty, Prev: stat/fstat, Up: List of Supported Calls
-
-gettimeofday
-............
-
-Synopsis:
- int gettimeofday(struct timeval *tv, void *tz);
-
-Request:
- `Fgettimeofday,TVPTR,TZPTR'
-
-Return value:
- On success, 0 is returned, -1 otherwise.
-
-Errors:
-
- `EINVAL'
- TZ is a non-NULL pointer.
-
- `EFAULT'
- TVPTR and/or TZPTR is an invalid pointer value.
-
-
-
-File: gdb.info, Node: isatty, Next: system, Prev: gettimeofday, Up: List of Supported Calls
-
-isatty
-......
-
-Synopsis:
- int isatty(int fd);
-
-Request:
- `Fisatty,FD'
-
-Return value:
- Returns 1 if FD refers to the GDB console, 0 otherwise.
-
-Errors:
-
- `EINTR'
- The call was interrupted by the user.
-
-
- Note that the `isatty' call is treated as a special case: it returns
-1 to the target if the file descriptor is attached to the GDB console,
-0 otherwise. Implementing through system calls would require
-implementing `ioctl' and would be more complex than needed.
-
-
-File: gdb.info, Node: system, Prev: isatty, Up: List of Supported Calls
-
-system
-......
-
-Synopsis:
- int system(const char *command);
-
-Request:
- `Fsystem,COMMANDPTR/LEN'
-
-Return value:
- If LEN is zero, the return value indicates whether a shell is
- available. A zero return value indicates a shell is not available.
- For non-zero LEN, the value returned is -1 on error and the return
- status of the command otherwise. Only the exit status of the
- command is returned, which is extracted from the host's `system'
- return value by calling `WEXITSTATUS(retval)'. In case `/bin/sh'
- could not be executed, 127 is returned.
-
-Errors:
-
- `EINTR'
- The call was interrupted by the user.
-
-
- GDB takes over the full task of calling the necessary host calls to
-perform the `system' call. The return value of `system' on the host is
-simplified before it's returned to the target. Any termination signal
-information from the child process is discarded, and the return value
-consists entirely of the exit status of the called command.
-
- Due to security concerns, the `system' call is by default refused by
-GDB. The user has to allow this call explicitly with the `set remote
-system-call-allowed 1' command.
-
-`set remote system-call-allowed'
- Control whether to allow the `system' calls in the File I/O
- protocol for the remote target. The default is zero (disabled).
-
-`show remote system-call-allowed'
- Show whether the `system' calls are allowed in the File I/O
- protocol.
-
-
-File: gdb.info, Node: Protocol-specific Representation of Datatypes, Next: Constants, Prev: List of Supported Calls, Up: File-I/O Remote Protocol Extension
-
-E.13.8 Protocol-specific Representation of Datatypes
-----------------------------------------------------
-
-* Menu:
-
-* Integral Datatypes::
-* Pointer Values::
-* Memory Transfer::
-* struct stat::
-* struct timeval::
-
-
-File: gdb.info, Node: Integral Datatypes, Next: Pointer Values, Up: Protocol-specific Representation of Datatypes
-
-Integral Datatypes
-..................
-
-The integral datatypes used in the system calls are `int', `unsigned
-int', `long', `unsigned long', `mode_t', and `time_t'.
-
- `int', `unsigned int', `mode_t' and `time_t' are implemented as 32
-bit values in this protocol.
-
- `long' and `unsigned long' are implemented as 64 bit types.
-
- *Note Limits::, for corresponding MIN and MAX values (similar to
-those in `limits.h') to allow range checking on host and target.
-
- `time_t' datatypes are defined as seconds since the Epoch.
-
- All integral datatypes transferred as part of a memory read or write
-of a structured datatype e.g. a `struct stat' have to be given in big
-endian byte order.
-
-
-File: gdb.info, Node: Pointer Values, Next: Memory Transfer, Prev: Integral Datatypes, Up: Protocol-specific Representation of Datatypes
-
-Pointer Values
-..............
-
-Pointers to target data are transmitted as they are. An exception is
-made for pointers to buffers for which the length isn't transmitted as
-part of the function call, namely strings. Strings are transmitted as
-a pointer/length pair, both as hex values, e.g.
-
- `1aaf/12'
-
-which is a pointer to data of length 18 bytes at position 0x1aaf. The
-length is defined as the full string length in bytes, including the
-trailing null byte. For example, the string `"hello world"' at address
-0x123456 is transmitted as
-
- `123456/d'
-
-
-File: gdb.info, Node: Memory Transfer, Next: struct stat, Prev: Pointer Values, Up: Protocol-specific Representation of Datatypes
-
-Memory Transfer
-...............
-
-Structured data which is transferred using a memory read or write (for
-example, a `struct stat') is expected to be in a protocol-specific
-format with all scalar multibyte datatypes being big endian.
-Translation to this representation needs to be done both by the target
-before the `F' packet is sent, and by GDB before it transfers memory to
-the target. Transferred pointers to structured data should point to
-the already-coerced data at any time.
-
-
-File: gdb.info, Node: struct stat, Next: struct timeval, Prev: Memory Transfer, Up: Protocol-specific Representation of Datatypes
-
-struct stat
-...........
-
-The buffer of type `struct stat' used by the target and GDB is defined
-as follows:
-
- struct stat {
- unsigned int st_dev; /* device */
- unsigned int st_ino; /* inode */
- mode_t st_mode; /* protection */
- unsigned int st_nlink; /* number of hard links */
- unsigned int st_uid; /* user ID of owner */
- unsigned int st_gid; /* group ID of owner */
- unsigned int st_rdev; /* device type (if inode device) */
- unsigned long st_size; /* total size, in bytes */
- unsigned long st_blksize; /* blocksize for filesystem I/O */
- unsigned long st_blocks; /* number of blocks allocated */
- time_t st_atime; /* time of last access */
- time_t st_mtime; /* time of last modification */
- time_t st_ctime; /* time of last change */
- };
-
- The integral datatypes conform to the definitions given in the
-appropriate section (see *note Integral Datatypes::, for details) so
-this structure is of size 64 bytes.
-
- The values of several fields have a restricted meaning and/or range
-of values.
-
-`st_dev'
- A value of 0 represents a file, 1 the console.
-
-`st_ino'
- No valid meaning for the target. Transmitted unchanged.
-
-`st_mode'
- Valid mode bits are described in *note Constants::. Any other
- bits have currently no meaning for the target.
-
-`st_uid'
-`st_gid'
-`st_rdev'
- No valid meaning for the target. Transmitted unchanged.
-
-`st_atime'
-`st_mtime'
-`st_ctime'
- These values have a host and file system dependent accuracy.
- Especially on Windows hosts, the file system may not support exact
- timing values.
-
- The target gets a `struct stat' of the above representation and is
-responsible for coercing it to the target representation before
-continuing.
-
- Note that due to size differences between the host, target, and
-protocol representations of `struct stat' members, these members could
-eventually get truncated on the target.
-
-
-File: gdb.info, Node: struct timeval, Prev: struct stat, Up: Protocol-specific Representation of Datatypes
-
-struct timeval
-..............
-
-The buffer of type `struct timeval' used by the File-I/O protocol is
-defined as follows:
-
- struct timeval {
- time_t tv_sec; /* second */
- long tv_usec; /* microsecond */
- };
-
- The integral datatypes conform to the definitions given in the
-appropriate section (see *note Integral Datatypes::, for details) so
-this structure is of size 8 bytes.
-
-
-File: gdb.info, Node: Constants, Next: File-I/O Examples, Prev: Protocol-specific Representation of Datatypes, Up: File-I/O Remote Protocol Extension
-
-E.13.9 Constants
-----------------
-
-The following values are used for the constants inside of the protocol.
-GDB and target are responsible for translating these values before and
-after the call as needed.
-
-* Menu:
-
-* Open Flags::
-* mode_t Values::
-* Errno Values::
-* Lseek Flags::
-* Limits::
-
-
-File: gdb.info, Node: Open Flags, Next: mode_t Values, Up: Constants
-
-Open Flags
-..........
-
-All values are given in hexadecimal representation.
-
- O_RDONLY 0x0
- O_WRONLY 0x1
- O_RDWR 0x2
- O_APPEND 0x8
- O_CREAT 0x200
- O_TRUNC 0x400
- O_EXCL 0x800
-
-
-File: gdb.info, Node: mode_t Values, Next: Errno Values, Prev: Open Flags, Up: Constants
-
-mode_t Values
-.............
-
-All values are given in octal representation.
-
- S_IFREG 0100000
- S_IFDIR 040000
- S_IRUSR 0400
- S_IWUSR 0200
- S_IXUSR 0100
- S_IRGRP 040
- S_IWGRP 020
- S_IXGRP 010
- S_IROTH 04
- S_IWOTH 02
- S_IXOTH 01
-
-
-File: gdb.info, Node: Errno Values, Next: Lseek Flags, Prev: mode_t Values, Up: Constants
-
-Errno Values
-............
-
-All values are given in decimal representation.
-
- EPERM 1
- ENOENT 2
- EINTR 4
- EBADF 9
- EACCES 13
- EFAULT 14
- EBUSY 16
- EEXIST 17
- ENODEV 19
- ENOTDIR 20
- EISDIR 21
- EINVAL 22
- ENFILE 23
- EMFILE 24
- EFBIG 27
- ENOSPC 28
- ESPIPE 29
- EROFS 30
- ENAMETOOLONG 91
- EUNKNOWN 9999
-
- `EUNKNOWN' is used as a fallback error value if a host system returns
- any error value not in the list of supported error numbers.
-
-
-File: gdb.info, Node: Lseek Flags, Next: Limits, Prev: Errno Values, Up: Constants
-
-Lseek Flags
-...........
-
- SEEK_SET 0
- SEEK_CUR 1
- SEEK_END 2
-
-
-File: gdb.info, Node: Limits, Prev: Lseek Flags, Up: Constants
-
-Limits
-......
-
-All values are given in decimal representation.
-
- INT_MIN -2147483648
- INT_MAX 2147483647
- UINT_MAX 4294967295
- LONG_MIN -9223372036854775808
- LONG_MAX 9223372036854775807
- ULONG_MAX 18446744073709551615
-
-
-File: gdb.info, Node: File-I/O Examples, Prev: Constants, Up: File-I/O Remote Protocol Extension
-
-E.13.10 File-I/O Examples
--------------------------
-
-Example sequence of a write call, file descriptor 3, buffer is at target
-address 0x1234, 6 bytes should be written:
-
- <- `Fwrite,3,1234,6'
- _request memory read from target_
- -> `m1234,6'
- <- XXXXXX
- _return "6 bytes written"_
- -> `F6'
-
- Example sequence of a read call, file descriptor 3, buffer is at
-target address 0x1234, 6 bytes should be read:
-
- <- `Fread,3,1234,6'
- _request memory write to target_
- -> `X1234,6:XXXXXX'
- _return "6 bytes read"_
- -> `F6'
-
- Example sequence of a read call, call fails on the host due to
-invalid file descriptor (`EBADF'):
-
- <- `Fread,3,1234,6'
- -> `F-1,9'
-
- Example sequence of a read call, user presses `Ctrl-c' before
-syscall on host is called:
-
- <- `Fread,3,1234,6'
- -> `F-1,4,C'
- <- `T02'
-
- Example sequence of a read call, user presses `Ctrl-c' after syscall
-on host is called:
-
- <- `Fread,3,1234,6'
- -> `X1234,6:XXXXXX'
- <- `T02'
-
-
-File: gdb.info, Node: Library List Format, Next: Memory Map Format, Prev: File-I/O Remote Protocol Extension, Up: Remote Protocol
-
-E.14 Library List Format
-========================
-
-On some platforms, a dynamic loader (e.g. `ld.so') runs in the same
-process as your application to manage libraries. In this case, GDB can
-use the loader's symbol table and normal memory operations to maintain
-a list of shared libraries. On other platforms, the operating system
-manages loaded libraries. GDB can not retrieve the list of currently
-loaded libraries through memory operations, so it uses the
-`qXfer:libraries:read' packet (*note qXfer library list read::)
-instead. The remote stub queries the target's operating system and
-reports which libraries are loaded.
-
- The `qXfer:libraries:read' packet returns an XML document which
-lists loaded libraries and their offsets. Each library has an
-associated name and one or more segment or section base addresses,
-which report where the library was loaded in memory.
-
- For the common case of libraries that are fully linked binaries, the
-library should have a list of segments. If the target supports dynamic
-linking of a relocatable object file, its library XML element should
-instead include a list of allocated sections. The segment or section
-bases are start addresses, not relocation offsets; they do not depend
-on the library's link-time base addresses.
-
- GDB must be linked with the Expat library to support XML library
-lists. *Note Expat::.
-
- A simple memory map, with one loaded library relocated by a single
-offset, looks like this:
-
- <library-list>
- <library name="/lib/libc.so.6">
- <segment address="0x10000000"/>
- </library>
- </library-list>
-
- Another simple memory map, with one loaded library with three
-allocated sections (.text, .data, .bss), looks like this:
-
- <library-list>
- <library name="sharedlib.o">
- <section address="0x10000000"/>
- <section address="0x20000000"/>
- <section address="0x30000000"/>
- </library>
- </library-list>
-
- The format of a library list is described by this DTD:
-
- <!-- library-list: Root element with versioning -->
- <!ELEMENT library-list (library)*>
- <!ATTLIST library-list version CDATA #FIXED "1.0">
- <!ELEMENT library (segment*, section*)>
- <!ATTLIST library name CDATA #REQUIRED>
- <!ELEMENT segment EMPTY>
- <!ATTLIST segment address CDATA #REQUIRED>
- <!ELEMENT section EMPTY>
- <!ATTLIST section address CDATA #REQUIRED>
-
- In addition, segments and section descriptors cannot be mixed within
-a single library element, and you must supply at least one segment or
-section for each library.
-
-
-File: gdb.info, Node: Memory Map Format, Next: Thread List Format, Prev: Library List Format, Up: Remote Protocol
-
-E.15 Memory Map Format
-======================
-
-To be able to write into flash memory, GDB needs to obtain a memory map
-from the target. This section describes the format of the memory map.
-
- The memory map is obtained using the `qXfer:memory-map:read' (*note
-qXfer memory map read::) packet and is an XML document that lists
-memory regions.
-
- GDB must be linked with the Expat library to support XML memory
-maps. *Note Expat::.
-
- The top-level structure of the document is shown below:
-
- <?xml version="1.0"?>
- <!DOCTYPE memory-map
- PUBLIC "+//IDN gnu.org//DTD GDB Memory Map V1.0//EN"
- "http://sourceware.org/gdb/gdb-memory-map.dtd">
- <memory-map>
- region...
- </memory-map>
-
- Each region can be either:
-
- * A region of RAM starting at ADDR and extending for LENGTH bytes
- from there:
-
- <memory type="ram" start="ADDR" length="LENGTH"/>
-
- * A region of read-only memory:
-
- <memory type="rom" start="ADDR" length="LENGTH"/>
-
- * A region of flash memory, with erasure blocks BLOCKSIZE bytes in
- length:
-
- <memory type="flash" start="ADDR" length="LENGTH">
- <property name="blocksize">BLOCKSIZE</property>
- </memory>
-
-
- Regions must not overlap. GDB assumes that areas of memory not
-covered by the memory map are RAM, and uses the ordinary `M' and `X'
-packets to write to addresses in such ranges.
-
- The formal DTD for memory map format is given below:
-
- <!-- ................................................... -->
- <!-- Memory Map XML DTD ................................ -->
- <!-- File: memory-map.dtd .............................. -->
- <!-- .................................... .............. -->
- <!-- memory-map.dtd -->
- <!-- memory-map: Root element with versioning -->
- <!ELEMENT memory-map (memory | property)>
- <!ATTLIST memory-map version CDATA #FIXED "1.0.0">
- <!ELEMENT memory (property)>
- <!-- memory: Specifies a memory region,
- and its type, or device. -->
- <!ATTLIST memory type CDATA #REQUIRED
- start CDATA #REQUIRED
- length CDATA #REQUIRED
- device CDATA #IMPLIED>
- <!-- property: Generic attribute tag -->
- <!ELEMENT property (#PCDATA | property)*>
- <!ATTLIST property name CDATA #REQUIRED>
-
-
-File: gdb.info, Node: Thread List Format, Next: Traceframe Info Format, Prev: Memory Map Format, Up: Remote Protocol
-
-E.16 Thread List Format
-=======================
-
-To efficiently update the list of threads and their attributes, GDB
-issues the `qXfer:threads:read' packet (*note qXfer threads read::) and
-obtains the XML document with the following structure:
-
- <?xml version="1.0"?>
- <threads>
- <thread id="id" core="0">
- ... description ...
- </thread>
- </threads>
-
- Each `thread' element must have the `id' attribute that identifies
-the thread (*note thread-id syntax::). The `core' attribute, if
-present, specifies which processor core the thread was last executing
-on. The content of the of `thread' element is interpreted as
-human-readable auxilliary information.
-
-
-File: gdb.info, Node: Traceframe Info Format, Prev: Thread List Format, Up: Remote Protocol
-
-E.17 Traceframe Info Format
-===========================
-
-To be able to know which objects in the inferior can be examined when
-inspecting a tracepoint hit, GDB needs to obtain the list of memory
-ranges, registers and trace state variables that have been collected in
-a traceframe.
-
- This list is obtained using the `qXfer:traceframe-info:read' (*note
-qXfer traceframe info read::) packet and is an XML document.
-
- GDB must be linked with the Expat library to support XML traceframe
-info discovery. *Note Expat::.
-
- The top-level structure of the document is shown below:
-
- <?xml version="1.0"?>
- <!DOCTYPE traceframe-info
- PUBLIC "+//IDN gnu.org//DTD GDB Memory Map V1.0//EN"
- "http://sourceware.org/gdb/gdb-traceframe-info.dtd">
- <traceframe-info>
- block...
- </traceframe-info>
-
- Each traceframe block can be either:
-
- * A region of collected memory starting at ADDR and extending for
- LENGTH bytes from there:
-
- <memory start="ADDR" length="LENGTH"/>
-
-
- The formal DTD for the traceframe info format is given below:
-
- <!ELEMENT traceframe-info (memory)* >
- <!ATTLIST traceframe-info version CDATA #FIXED "1.0">
-
- <!ELEMENT memory EMPTY>
- <!ATTLIST memory start CDATA #REQUIRED
- length CDATA #REQUIRED>
-
-
-File: gdb.info, Node: Agent Expressions, Next: Target Descriptions, Prev: Remote Protocol, Up: Top
-
-Appendix F The GDB Agent Expression Mechanism
-*********************************************
-
-In some applications, it is not feasible for the debugger to interrupt
-the program's execution long enough for the developer to learn anything
-helpful about its behavior. If the program's correctness depends on its
-real-time behavior, delays introduced by a debugger might cause the
-program to fail, even when the code itself is correct. It is useful to
-be able to observe the program's behavior without interrupting it.
-
- Using GDB's `trace' and `collect' commands, the user can specify
-locations in the program, and arbitrary expressions to evaluate when
-those locations are reached. Later, using the `tfind' command, she can
-examine the values those expressions had when the program hit the trace
-points. The expressions may also denote objects in memory --
-structures or arrays, for example -- whose values GDB should record;
-while visiting a particular tracepoint, the user may inspect those
-objects as if they were in memory at that moment. However, because GDB
-records these values without interacting with the user, it can do so
-quickly and unobtrusively, hopefully not disturbing the program's
-behavior.
-
- When GDB is debugging a remote target, the GDB "agent" code running
-on the target computes the values of the expressions itself. To avoid
-having a full symbolic expression evaluator on the agent, GDB translates
-expressions in the source language into a simpler bytecode language, and
-then sends the bytecode to the agent; the agent then executes the
-bytecode, and records the values for GDB to retrieve later.
-
- The bytecode language is simple; there are forty-odd opcodes, the
-bulk of which are the usual vocabulary of C operands (addition,
-subtraction, shifts, and so on) and various sizes of literals and
-memory reference operations. The bytecode interpreter operates
-strictly on machine-level values -- various sizes of integers and
-floating point numbers -- and requires no information about types or
-symbols; thus, the interpreter's internal data structures are simple,
-and each bytecode requires only a few native machine instructions to
-implement it. The interpreter is small, and strict limits on the
-memory and time required to evaluate an expression are easy to
-determine, making it suitable for use by the debugging agent in
-real-time applications.
-
-* Menu:
-
-* General Bytecode Design:: Overview of the interpreter.
-* Bytecode Descriptions:: What each one does.
-* Using Agent Expressions:: How agent expressions fit into the big picture.
-* Varying Target Capabilities:: How to discover what the target can do.
-* Rationale:: Why we did it this way.
-
-
-File: gdb.info, Node: General Bytecode Design, Next: Bytecode Descriptions, Up: Agent Expressions
-
-F.1 General Bytecode Design
-===========================
-
-The agent represents bytecode expressions as an array of bytes. Each
-instruction is one byte long (thus the term "bytecode"). Some
-instructions are followed by operand bytes; for example, the `goto'
-instruction is followed by a destination for the jump.
-
- The bytecode interpreter is a stack-based machine; most instructions
-pop their operands off the stack, perform some operation, and push the
-result back on the stack for the next instruction to consume. Each
-element of the stack may contain either a integer or a floating point
-value; these values are as many bits wide as the largest integer that
-can be directly manipulated in the source language. Stack elements
-carry no record of their type; bytecode could push a value as an
-integer, then pop it as a floating point value. However, GDB will not
-generate code which does this. In C, one might define the type of a
-stack element as follows:
- union agent_val {
- LONGEST l;
- DOUBLEST d;
- };
- where `LONGEST' and `DOUBLEST' are `typedef' names for the largest
-integer and floating point types on the machine.
-
- By the time the bytecode interpreter reaches the end of the
-expression, the value of the expression should be the only value left
-on the stack. For tracing applications, `trace' bytecodes in the
-expression will have recorded the necessary data, and the value on the
-stack may be discarded. For other applications, like conditional
-breakpoints, the value may be useful.
-
- Separate from the stack, the interpreter has two registers:
-`pc'
- The address of the next bytecode to execute.
-
-`start'
- The address of the start of the bytecode expression, necessary for
- interpreting the `goto' and `if_goto' instructions.
-
- Neither of these registers is directly visible to the bytecode
-language itself, but they are useful for defining the meanings of the
-bytecode operations.
-
- There are no instructions to perform side effects on the running
-program, or call the program's functions; we assume that these
-expressions are only used for unobtrusive debugging, not for patching
-the running code.
-
- Most bytecode instructions do not distinguish between the various
-sizes of values, and operate on full-width values; the upper bits of the
-values are simply ignored, since they do not usually make a difference
-to the value computed. The exceptions to this rule are:
-memory reference instructions (`ref'N)
- There are distinct instructions to fetch different word sizes from
- memory. Once on the stack, however, the values are treated as
- full-size integers. They may need to be sign-extended; the `ext'
- instruction exists for this purpose.
-
-the sign-extension instruction (`ext' N)
- These clearly need to know which portion of their operand is to be
- extended to occupy the full length of the word.
-
-
- If the interpreter is unable to evaluate an expression completely for
-some reason (a memory location is inaccessible, or a divisor is zero,
-for example), we say that interpretation "terminates with an error".
-This means that the problem is reported back to the interpreter's caller
-in some helpful way. In general, code using agent expressions should
-assume that they may attempt to divide by zero, fetch arbitrary memory
-locations, and misbehave in other ways.
-
- Even complicated C expressions compile to a few bytecode
-instructions; for example, the expression `x + y * z' would typically
-produce code like the following, assuming that `x' and `y' live in
-registers, and `z' is a global variable holding a 32-bit `int':
- reg 1
- reg 2
- const32 address of z
- ref32
- ext 32
- mul
- add
- end
-
- In detail, these mean:
-`reg 1'
- Push the value of register 1 (presumably holding `x') onto the
- stack.
-
-`reg 2'
- Push the value of register 2 (holding `y').
-
-`const32 address of z'
- Push the address of `z' onto the stack.
-
-`ref32'
- Fetch a 32-bit word from the address at the top of the stack;
- replace the address on the stack with the value. Thus, we replace
- the address of `z' with `z''s value.
-
-`ext 32'
- Sign-extend the value on the top of the stack from 32 bits to full
- length. This is necessary because `z' is a signed integer.
-
-`mul'
- Pop the top two numbers on the stack, multiply them, and push their
- product. Now the top of the stack contains the value of the
- expression `y * z'.
-
-`add'
- Pop the top two numbers, add them, and push the sum. Now the top
- of the stack contains the value of `x + y * z'.
-
-`end'
- Stop executing; the value left on the stack top is the value to be
- recorded.
-
-
-
-File: gdb.info, Node: Bytecode Descriptions, Next: Using Agent Expressions, Prev: General Bytecode Design, Up: Agent Expressions
-
-F.2 Bytecode Descriptions
-=========================
-
-Each bytecode description has the following form:
-
-`add' (0x02): A B => A+B
- Pop the top two stack items, A and B, as integers; push their sum,
- as an integer.
-
-
- In this example, `add' is the name of the bytecode, and `(0x02)' is
-the one-byte value used to encode the bytecode, in hexadecimal. The
-phrase "A B => A+B" shows the stack before and after the bytecode
-executes. Beforehand, the stack must contain at least two values, A
-and B; since the top of the stack is to the right, B is on the top of
-the stack, and A is underneath it. After execution, the bytecode will
-have popped A and B from the stack, and replaced them with a single
-value, A+B. There may be other values on the stack below those shown,
-but the bytecode affects only those shown.
-
- Here is another example:
-
-`const8' (0x22) N: => N
- Push the 8-bit integer constant N on the stack, without sign
- extension.
-
-
- In this example, the bytecode `const8' takes an operand N directly
-from the bytecode stream; the operand follows the `const8' bytecode
-itself. We write any such operands immediately after the name of the
-bytecode, before the colon, and describe the exact encoding of the
-operand in the bytecode stream in the body of the bytecode description.
-
- For the `const8' bytecode, there are no stack items given before the
-=>; this simply means that the bytecode consumes no values from the
-stack. If a bytecode consumes no values, or produces no values, the
-list on either side of the => may be empty.
-
- If a value is written as A, B, or N, then the bytecode treats it as
-an integer. If a value is written is ADDR, then the bytecode treats it
-as an address.
-
- We do not fully describe the floating point operations here; although
-this design can be extended in a clean way to handle floating point
-values, they are not of immediate interest to the customer, so we avoid
-describing them, to save time.
-
-`float' (0x01): =>
- Prefix for floating-point bytecodes. Not implemented yet.
-
-`add' (0x02): A B => A+B
- Pop two integers from the stack, and push their sum, as an integer.
-
-`sub' (0x03): A B => A-B
- Pop two integers from the stack, subtract the top value from the
- next-to-top value, and push the difference.
-
-`mul' (0x04): A B => A*B
- Pop two integers from the stack, multiply them, and push the
- product on the stack. Note that, when one multiplies two N-bit
- numbers yielding another N-bit number, it is irrelevant whether the
- numbers are signed or not; the results are the same.
-
-`div_signed' (0x05): A B => A/B
- Pop two signed integers from the stack; divide the next-to-top
- value by the top value, and push the quotient. If the divisor is
- zero, terminate with an error.
-
-`div_unsigned' (0x06): A B => A/B
- Pop two unsigned integers from the stack; divide the next-to-top
- value by the top value, and push the quotient. If the divisor is
- zero, terminate with an error.
-
-`rem_signed' (0x07): A B => A MODULO B
- Pop two signed integers from the stack; divide the next-to-top
- value by the top value, and push the remainder. If the divisor is
- zero, terminate with an error.
-
-`rem_unsigned' (0x08): A B => A MODULO B
- Pop two unsigned integers from the stack; divide the next-to-top
- value by the top value, and push the remainder. If the divisor is
- zero, terminate with an error.
-
-`lsh' (0x09): A B => A<<B
- Pop two integers from the stack; let A be the next-to-top value,
- and B be the top value. Shift A left by B bits, and push the
- result.
-
-`rsh_signed' (0x0a): A B => `(signed)'A>>B
- Pop two integers from the stack; let A be the next-to-top value,
- and B be the top value. Shift A right by B bits, inserting copies
- of the top bit at the high end, and push the result.
-
-`rsh_unsigned' (0x0b): A B => A>>B
- Pop two integers from the stack; let A be the next-to-top value,
- and B be the top value. Shift A right by B bits, inserting zero
- bits at the high end, and push the result.
-
-`log_not' (0x0e): A => !A
- Pop an integer from the stack; if it is zero, push the value one;
- otherwise, push the value zero.
-
-`bit_and' (0x0f): A B => A&B
- Pop two integers from the stack, and push their bitwise `and'.
-
-`bit_or' (0x10): A B => A|B
- Pop two integers from the stack, and push their bitwise `or'.
-
-`bit_xor' (0x11): A B => A^B
- Pop two integers from the stack, and push their bitwise
- exclusive-`or'.
-
-`bit_not' (0x12): A => ~A
- Pop an integer from the stack, and push its bitwise complement.
-
-`equal' (0x13): A B => A=B
- Pop two integers from the stack; if they are equal, push the value
- one; otherwise, push the value zero.
-
-`less_signed' (0x14): A B => A<B
- Pop two signed integers from the stack; if the next-to-top value
- is less than the top value, push the value one; otherwise, push
- the value zero.
-
-`less_unsigned' (0x15): A B => A<B
- Pop two unsigned integers from the stack; if the next-to-top value
- is less than the top value, push the value one; otherwise, push
- the value zero.
-
-`ext' (0x16) N: A => A, sign-extended from N bits
- Pop an unsigned value from the stack; treating it as an N-bit
- twos-complement value, extend it to full length. This means that
- all bits to the left of bit N-1 (where the least significant bit
- is bit 0) are set to the value of bit N-1. Note that N may be
- larger than or equal to the width of the stack elements of the
- bytecode engine; in this case, the bytecode should have no effect.
-
- The number of source bits to preserve, N, is encoded as a single
- byte unsigned integer following the `ext' bytecode.
-
-`zero_ext' (0x2a) N: A => A, zero-extended from N bits
- Pop an unsigned value from the stack; zero all but the bottom N
- bits. This means that all bits to the left of bit N-1 (where the
- least significant bit is bit 0) are set to the value of bit N-1.
-
- The number of source bits to preserve, N, is encoded as a single
- byte unsigned integer following the `zero_ext' bytecode.
-
-`ref8' (0x17): ADDR => A
-`ref16' (0x18): ADDR => A
-`ref32' (0x19): ADDR => A
-`ref64' (0x1a): ADDR => A
- Pop an address ADDR from the stack. For bytecode `ref'N, fetch an
- N-bit value from ADDR, using the natural target endianness. Push
- the fetched value as an unsigned integer.
-
- Note that ADDR may not be aligned in any particular way; the
- `refN' bytecodes should operate correctly for any address.
-
- If attempting to access memory at ADDR would cause a processor
- exception of some sort, terminate with an error.
-
-`ref_float' (0x1b): ADDR => D
-`ref_double' (0x1c): ADDR => D
-`ref_long_double' (0x1d): ADDR => D
-`l_to_d' (0x1e): A => D
-`d_to_l' (0x1f): D => A
- Not implemented yet.
-
-`dup' (0x28): A => A A
- Push another copy of the stack's top element.
-
-`swap' (0x2b): A B => B A
- Exchange the top two items on the stack.
-
-`pop' (0x29): A =>
- Discard the top value on the stack.
-
-`pick' (0x32) N: A ... B => A ... B A
- Duplicate an item from the stack and push it on the top of the
- stack. N, a single byte, indicates the stack item to copy. If N
- is zero, this is the same as `dup'; if N is one, it copies the
- item under the top item, etc. If N exceeds the number of items on
- the stack, terminate with an error.
-
-`rot' (0x33): A B C => C B A
- Rotate the top three items on the stack.
-
-`if_goto' (0x20) OFFSET: A =>
- Pop an integer off the stack; if it is non-zero, branch to the
- given offset in the bytecode string. Otherwise, continue to the
- next instruction in the bytecode stream. In other words, if A is
- non-zero, set the `pc' register to `start' + OFFSET. Thus, an
- offset of zero denotes the beginning of the expression.
-
- The OFFSET is stored as a sixteen-bit unsigned value, stored
- immediately following the `if_goto' bytecode. It is always stored
- most significant byte first, regardless of the target's normal
- endianness. The offset is not guaranteed to fall at any particular
- alignment within the bytecode stream; thus, on machines where
- fetching a 16-bit on an unaligned address raises an exception, you
- should fetch the offset one byte at a time.
-
-`goto' (0x21) OFFSET: =>
- Branch unconditionally to OFFSET; in other words, set the `pc'
- register to `start' + OFFSET.
-
- The offset is stored in the same way as for the `if_goto' bytecode.
-
-`const8' (0x22) N: => N
-`const16' (0x23) N: => N
-`const32' (0x24) N: => N
-`const64' (0x25) N: => N
- Push the integer constant N on the stack, without sign extension.
- To produce a small negative value, push a small twos-complement
- value, and then sign-extend it using the `ext' bytecode.
-
- The constant N is stored in the appropriate number of bytes
- following the `const'B bytecode. The constant N is always stored
- most significant byte first, regardless of the target's normal
- endianness. The constant is not guaranteed to fall at any
- particular alignment within the bytecode stream; thus, on machines
- where fetching a 16-bit on an unaligned address raises an
- exception, you should fetch N one byte at a time.
-
-`reg' (0x26) N: => A
- Push the value of register number N, without sign extension. The
- registers are numbered following GDB's conventions.
-
- The register number N is encoded as a 16-bit unsigned integer
- immediately following the `reg' bytecode. It is always stored most
- significant byte first, regardless of the target's normal
- endianness. The register number is not guaranteed to fall at any
- particular alignment within the bytecode stream; thus, on machines
- where fetching a 16-bit on an unaligned address raises an
- exception, you should fetch the register number one byte at a time.
-
-`getv' (0x2c) N: => V
- Push the value of trace state variable number N, without sign
- extension.
-
- The variable number N is encoded as a 16-bit unsigned integer
- immediately following the `getv' bytecode. It is always stored
- most significant byte first, regardless of the target's normal
- endianness. The variable number is not guaranteed to fall at any
- particular alignment within the bytecode stream; thus, on machines
- where fetching a 16-bit on an unaligned address raises an
- exception, you should fetch the register number one byte at a time.
-
-`setv' (0x2d) N: => V
- Set trace state variable number N to the value found on the top of
- the stack. The stack is unchanged, so that the value is readily
- available if the assignment is part of a larger expression. The
- handling of N is as described for `getv'.
-
-`trace' (0x0c): ADDR SIZE =>
- Record the contents of the SIZE bytes at ADDR in a trace buffer,
- for later retrieval by GDB.
-
-`trace_quick' (0x0d) SIZE: ADDR => ADDR
- Record the contents of the SIZE bytes at ADDR in a trace buffer,
- for later retrieval by GDB. SIZE is a single byte unsigned
- integer following the `trace' opcode.
-
- This bytecode is equivalent to the sequence `dup const8 SIZE
- trace', but we provide it anyway to save space in bytecode strings.
-
-`trace16' (0x30) SIZE: ADDR => ADDR
- Identical to trace_quick, except that SIZE is a 16-bit big-endian
- unsigned integer, not a single byte. This should probably have
- been named `trace_quick16', for consistency.
-
-`tracev' (0x2e) N: => A
- Record the value of trace state variable number N in the trace
- buffer. The handling of N is as described for `getv'.
-
-`end' (0x27): =>
- Stop executing bytecode; the result should be the top element of
- the stack. If the purpose of the expression was to compute an
- lvalue or a range of memory, then the next-to-top of the stack is
- the lvalue's address, and the top of the stack is the lvalue's
- size, in bytes.
-
-
-
-File: gdb.info, Node: Using Agent Expressions, Next: Varying Target Capabilities, Prev: Bytecode Descriptions, Up: Agent Expressions
-
-F.3 Using Agent Expressions
-===========================
-
-Agent expressions can be used in several different ways by GDB, and the
-debugger can generate different bytecode sequences as appropriate.
-
- One possibility is to do expression evaluation on the target rather
-than the host, such as for the conditional of a conditional tracepoint.
-In such a case, GDB compiles the source expression into a bytecode
-sequence that simply gets values from registers or memory, does
-arithmetic, and returns a result.
-
- Another way to use agent expressions is for tracepoint data
-collection. GDB generates a different bytecode sequence for
-collection; in addition to bytecodes that do the calculation, GDB adds
-`trace' bytecodes to save the pieces of memory that were used.
-
- * The user selects trace points in the program's code at which GDB
- should collect data.
-
- * The user specifies expressions to evaluate at each trace point.
- These expressions may denote objects in memory, in which case
- those objects' contents are recorded as the program runs, or
- computed values, in which case the values themselves are recorded.
-
- * GDB transmits the tracepoints and their associated expressions to
- the GDB agent, running on the debugging target.
-
- * The agent arranges to be notified when a trace point is hit.
-
- * When execution on the target reaches a trace point, the agent
- evaluates the expressions associated with that trace point, and
- records the resulting values and memory ranges.
-
- * Later, when the user selects a given trace event and inspects the
- objects and expression values recorded, GDB talks to the agent to
- retrieve recorded data as necessary to meet the user's requests.
- If the user asks to see an object whose contents have not been
- recorded, GDB reports an error.
-
-
-
-File: gdb.info, Node: Varying Target Capabilities, Next: Rationale, Prev: Using Agent Expressions, Up: Agent Expressions
-
-F.4 Varying Target Capabilities
-===============================
-
-Some targets don't support floating-point, and some would rather not
-have to deal with `long long' operations. Also, different targets will
-have different stack sizes, and different bytecode buffer lengths.
-
- Thus, GDB needs a way to ask the target about itself. We haven't
-worked out the details yet, but in general, GDB should be able to send
-the target a packet asking it to describe itself. The reply should be a
-packet whose length is explicit, so we can add new information to the
-packet in future revisions of the agent, without confusing old versions
-of GDB, and it should contain a version number. It should contain at
-least the following information:
-
- * whether floating point is supported
-
- * whether `long long' is supported
-
- * maximum acceptable size of bytecode stack
-
- * maximum acceptable length of bytecode expressions
-
- * which registers are actually available for collection
-
- * whether the target supports disabled tracepoints
-
-
-
-File: gdb.info, Node: Rationale, Prev: Varying Target Capabilities, Up: Agent Expressions
-
-F.5 Rationale
-=============
-
-Some of the design decisions apparent above are arguable.
-
-What about stack overflow/underflow?
- GDB should be able to query the target to discover its stack size.
- Given that information, GDB can determine at translation time
- whether a given expression will overflow the stack. But this spec
- isn't about what kinds of error-checking GDB ought to do.
-
-Why are you doing everything in LONGEST?
- Speed isn't important, but agent code size is; using LONGEST
- brings in a bunch of support code to do things like division, etc.
- So this is a serious concern.
-
- First, note that you don't need different bytecodes for different
- operand sizes. You can generate code without _knowing_ how big the
- stack elements actually are on the target. If the target only
- supports 32-bit ints, and you don't send any 64-bit bytecodes,
- everything just works. The observation here is that the MIPS and
- the Alpha have only fixed-size registers, and you can still get
- C's semantics even though most instructions only operate on
- full-sized words. You just need to make sure everything is
- properly sign-extended at the right times. So there is no need
- for 32- and 64-bit variants of the bytecodes. Just implement
- everything using the largest size you support.
-
- GDB should certainly check to see what sizes the target supports,
- so the user can get an error earlier, rather than later. But this
- information is not necessary for correctness.
-
-Why don't you have `>' or `<=' operators?
- I want to keep the interpreter small, and we don't need them. We
- can combine the `less_' opcodes with `log_not', and swap the order
- of the operands, yielding all four asymmetrical comparison
- operators. For example, `(x <= y)' is `! (x > y)', which is `! (y
- < x)'.
-
-Why do you have `log_not'?
-Why do you have `ext'?
-Why do you have `zero_ext'?
- These are all easily synthesized from other instructions, but I
- expect them to be used frequently, and they're simple, so I
- include them to keep bytecode strings short.
-
- `log_not' is equivalent to `const8 0 equal'; it's used in half the
- relational operators.
-
- `ext N' is equivalent to `const8 S-N lsh const8 S-N rsh_signed',
- where S is the size of the stack elements; it follows `refM' and
- REG bytecodes when the value should be signed. See the next
- bulleted item.
-
- `zero_ext N' is equivalent to `constM MASK log_and'; it's used
- whenever we push the value of a register, because we can't assume
- the upper bits of the register aren't garbage.
-
-Why not have sign-extending variants of the `ref' operators?
- Because that would double the number of `ref' operators, and we
- need the `ext' bytecode anyway for accessing bitfields.
-
-Why not have constant-address variants of the `ref' operators?
- Because that would double the number of `ref' operators again, and
- `const32 ADDRESS ref32' is only one byte longer.
-
-Why do the `refN' operators have to support unaligned fetches?
- GDB will generate bytecode that fetches multi-byte values at
- unaligned addresses whenever the executable's debugging
- information tells it to. Furthermore, GDB does not know the value
- the pointer will have when GDB generates the bytecode, so it
- cannot determine whether a particular fetch will be aligned or not.
-
- In particular, structure bitfields may be several bytes long, but
- follow no alignment rules; members of packed structures are not
- necessarily aligned either.
-
- In general, there are many cases where unaligned references occur
- in correct C code, either at the programmer's explicit request, or
- at the compiler's discretion. Thus, it is simpler to make the GDB
- agent bytecodes work correctly in all circumstances than to make
- GDB guess in each case whether the compiler did the usual thing.
-
-Why are there no side-effecting operators?
- Because our current client doesn't want them? That's a cheap
- answer. I think the real answer is that I'm afraid of
- implementing function calls. We should re-visit this issue after
- the present contract is delivered.
-
-Why aren't the `goto' ops PC-relative?
- The interpreter has the base address around anyway for PC bounds
- checking, and it seemed simpler.
-
-Why is there only one offset size for the `goto' ops?
- Offsets are currently sixteen bits. I'm not happy with this
- situation either:
-
- Suppose we have multiple branch ops with different offset sizes.
- As I generate code left-to-right, all my jumps are forward jumps
- (there are no loops in expressions), so I never know the target
- when I emit the jump opcode. Thus, I have to either always assume
- the largest offset size, or do jump relaxation on the code after I
- generate it, which seems like a big waste of time.
-
- I can imagine a reasonable expression being longer than 256 bytes.
- I can't imagine one being longer than 64k. Thus, we need 16-bit
- offsets. This kind of reasoning is so bogus, but relaxation is
- pathetic.
-
- The other approach would be to generate code right-to-left. Then
- I'd always know my offset size. That might be fun.
-
-Where is the function call bytecode?
- When we add side-effects, we should add this.
-
-Why does the `reg' bytecode take a 16-bit register number?
- Intel's IA-64 architecture has 128 general-purpose registers, and
- 128 floating-point registers, and I'm sure it has some random
- control registers.
-
-Why do we need `trace' and `trace_quick'?
- Because GDB needs to record all the memory contents and registers
- an expression touches. If the user wants to evaluate an expression
- `x->y->z', the agent must record the values of `x' and `x->y' as
- well as the value of `x->y->z'.
-
-Don't the `trace' bytecodes make the interpreter less general?
- They do mean that the interpreter contains special-purpose code,
- but that doesn't mean the interpreter can only be used for that
- purpose. If an expression doesn't use the `trace' bytecodes, they
- don't get in its way.
-
-Why doesn't `trace_quick' consume its arguments the way everything else does?
- In general, you do want your operators to consume their arguments;
- it's consistent, and generally reduces the amount of stack
- rearrangement necessary. However, `trace_quick' is a kludge to
- save space; it only exists so we needn't write `dup const8 SIZE
- trace' before every memory reference. Therefore, it's okay for it
- not to consume its arguments; it's meant for a specific context in
- which we know exactly what it should do with the stack. If we're
- going to have a kludge, it should be an effective kludge.
-
-Why does `trace16' exist?
- That opcode was added by the customer that contracted Cygnus for
- the data tracing work. I personally think it is unnecessary;
- objects that large will be quite rare, so it is okay to use `dup
- const16 SIZE trace' in those cases.
-
- Whatever we decide to do with `trace16', we should at least leave
- opcode 0x30 reserved, to remain compatible with the customer who
- added it.
-
-
-
-File: gdb.info, Node: Target Descriptions, Next: Operating System Information, Prev: Agent Expressions, Up: Top
-
-Appendix G Target Descriptions
-******************************
-
-*Warning:* target descriptions are still under active development, and
-the contents and format may change between GDB releases. The format is
-expected to stabilize in the future.
-
- One of the challenges of using GDB to debug embedded systems is that
-there are so many minor variants of each processor architecture in use.
-It is common practice for vendors to start with a standard processor
-core -- ARM, PowerPC, or MIPS, for example -- and then make changes to
-adapt it to a particular market niche. Some architectures have
-hundreds of variants, available from dozens of vendors. This leads to
-a number of problems:
-
- * With so many different customized processors, it is difficult for
- the GDB maintainers to keep up with the changes.
-
- * Since individual variants may have short lifetimes or limited
- audiences, it may not be worthwhile to carry information about
- every variant in the GDB source tree.
-
- * When GDB does support the architecture of the embedded system at
- hand, the task of finding the correct architecture name to give the
- `set architecture' command can be error-prone.
-
- To address these problems, the GDB remote protocol allows a target
-system to not only identify itself to GDB, but to actually describe its
-own features. This lets GDB support processor variants it has never
-seen before -- to the extent that the descriptions are accurate, and
-that GDB understands them.
-
- GDB must be linked with the Expat library to support XML target
-descriptions. *Note Expat::.
-
-* Menu:
-
-* Retrieving Descriptions:: How descriptions are fetched from a target.
-* Target Description Format:: The contents of a target description.
-* Predefined Target Types:: Standard types available for target
- descriptions.
-* Standard Target Features:: Features GDB knows about.
-
-
-File: gdb.info, Node: Retrieving Descriptions, Next: Target Description Format, Up: Target Descriptions
-
-G.1 Retrieving Descriptions
-===========================
-
-Target descriptions can be read from the target automatically, or
-specified by the user manually. The default behavior is to read the
-description from the target. GDB retrieves it via the remote protocol
-using `qXfer' requests (*note qXfer: General Query Packets.). The
-ANNEX in the `qXfer' packet will be `target.xml'. The contents of the
-`target.xml' annex are an XML document, of the form described in *note
-Target Description Format::.
-
- Alternatively, you can specify a file to read for the target
-description. If a file is set, the target will not be queried. The
-commands to specify a file are:
-
-`set tdesc filename PATH'
- Read the target description from PATH.
-
-`unset tdesc filename'
- Do not read the XML target description from a file. GDB will use
- the description supplied by the current target.
-
-`show tdesc filename'
- Show the filename to read for a target description, if any.
-
-
-File: gdb.info, Node: Target Description Format, Next: Predefined Target Types, Prev: Retrieving Descriptions, Up: Target Descriptions
-
-G.2 Target Description Format
-=============================
-
-A target description annex is an XML (http://www.w3.org/XML/) document
-which complies with the Document Type Definition provided in the GDB
-sources in `gdb/features/gdb-target.dtd'. This means you can use
-generally available tools like `xmllint' to check that your feature
-descriptions are well-formed and valid. However, to help people
-unfamiliar with XML write descriptions for their targets, we also
-describe the grammar here.
-
- Target descriptions can identify the architecture of the remote
-target and (for some architectures) provide information about custom
-register sets. They can also identify the OS ABI of the remote target.
-GDB can use this information to autoconfigure for your target, or to
-warn you if you connect to an unsupported target.
-
- Here is a simple target description:
-
- <target version="1.0">
- <architecture>i386:x86-64</architecture>
- </target>
-
-This minimal description only says that the target uses the x86-64
-architecture.
-
- A target description has the following overall form, with [ ] marking
-optional elements and ... marking repeatable elements. The elements
-are explained further below.
-
- <?xml version="1.0"?>
- <!DOCTYPE target SYSTEM "gdb-target.dtd">
- <target version="1.0">
- [ARCHITECTURE]
- [OSABI]
- [COMPATIBLE]
- [FEATURE...]
- </target>
-
-The description is generally insensitive to whitespace and line breaks,
-under the usual common-sense rules. The XML version declaration and
-document type declaration can generally be omitted (GDB does not
-require them), but specifying them may be useful for XML validation
-tools. The `version' attribute for `<target>' may also be omitted, but
-we recommend including it; if future versions of GDB use an incompatible
-revision of `gdb-target.dtd', they will detect and report the version
-mismatch.
-
-G.2.1 Inclusion
----------------
-
-It can sometimes be valuable to split a target description up into
-several different annexes, either for organizational purposes, or to
-share files between different possible target descriptions. You can
-divide a description into multiple files by replacing any element of
-the target description with an inclusion directive of the form:
-
- <xi:include href="DOCUMENT"/>
-
-When GDB encounters an element of this form, it will retrieve the named
-XML DOCUMENT, and replace the inclusion directive with the contents of
-that document. If the current description was read using `qXfer', then
-so will be the included document; DOCUMENT will be interpreted as the
-name of an annex. If the current description was read from a file, GDB
-will look for DOCUMENT as a file in the same directory where it found
-the original description.
-
-G.2.2 Architecture
-------------------
-
-An `<architecture>' element has this form:
-
- <architecture>ARCH</architecture>
-
- ARCH is one of the architectures from the set accepted by `set
-architecture' (*note Specifying a Debugging Target: Targets.).
-
-G.2.3 OS ABI
-------------
-
-This optional field was introduced in GDB version 7.0. Previous
-versions of GDB ignore it.
-
- An `<osabi>' element has this form:
-
- <osabi>ABI-NAME</osabi>
-
- ABI-NAME is an OS ABI name from the same selection accepted by
-`set osabi' (*note Configuring the Current ABI: ABI.).
-
-G.2.4 Compatible Architecture
------------------------------
-
-This optional field was introduced in GDB version 7.0. Previous
-versions of GDB ignore it.
-
- A `<compatible>' element has this form:
-
- <compatible>ARCH</compatible>
-
- ARCH is one of the architectures from the set accepted by `set
-architecture' (*note Specifying a Debugging Target: Targets.).
-
- A `<compatible>' element is used to specify that the target is able
-to run binaries in some other than the main target architecture given
-by the `<architecture>' element. For example, on the Cell Broadband
-Engine, the main architecture is `powerpc:common' or
-`powerpc:common64', but the system is able to run binaries in the `spu'
-architecture as well. The way to describe this capability with
-`<compatible>' is as follows:
-
- <architecture>powerpc:common</architecture>
- <compatible>spu</compatible>
-
-G.2.5 Features
---------------
-
-Each `<feature>' describes some logical portion of the target system.
-Features are currently used to describe available CPU registers and the
-types of their contents. A `<feature>' element has this form:
-
- <feature name="NAME">
- [TYPE...]
- REG...
- </feature>
-
-Each feature's name should be unique within the description. The name
-of a feature does not matter unless GDB has some special knowledge of
-the contents of that feature; if it does, the feature should have its
-standard name. *Note Standard Target Features::.
-
-G.2.6 Types
------------
-
-Any register's value is a collection of bits which GDB must interpret.
-The default interpretation is a two's complement integer, but other
-types can be requested by name in the register description. Some
-predefined types are provided by GDB (*note Predefined Target Types::),
-and the description can define additional composite types.
-
- Each type element must have an `id' attribute, which gives a unique
-(within the containing `<feature>') name to the type. Types must be
-defined before they are used.
-
- Some targets offer vector registers, which can be treated as arrays
-of scalar elements. These types are written as `<vector>' elements,
-specifying the array element type, TYPE, and the number of elements,
-COUNT:
-
- <vector id="ID" type="TYPE" count="COUNT"/>
-
- If a register's value is usefully viewed in multiple ways, define it
-with a union type containing the useful representations. The `<union>'
-element contains one or more `<field>' elements, each of which has a
-NAME and a TYPE:
-
- <union id="ID">
- <field name="NAME" type="TYPE"/>
- ...
- </union>
-
- If a register's value is composed from several separate values,
-define it with a structure type. There are two forms of the `<struct>'
-element; a `<struct>' element must either contain only bitfields or
-contain no bitfields. If the structure contains only bitfields, its
-total size in bytes must be specified, each bitfield must have an
-explicit start and end, and bitfields are automatically assigned an
-integer type. The field's START should be less than or equal to its
-END, and zero represents the least significant bit.
-
- <struct id="ID" size="SIZE">
- <field name="NAME" start="START" end="END"/>
- ...
- </struct>
-
- If the structure contains no bitfields, then each field has an
-explicit type, and no implicit padding is added.
-
- <struct id="ID">
- <field name="NAME" type="TYPE"/>
- ...
- </struct>
-
- If a register's value is a series of single-bit flags, define it with
-a flags type. The `<flags>' element has an explicit SIZE and contains
-one or more `<field>' elements. Each field has a NAME, a START, and an
-END. Only single-bit flags are supported.
-
- <flags id="ID" size="SIZE">
- <field name="NAME" start="START" end="END"/>
- ...
- </flags>
-
-G.2.7 Registers
----------------
-
-Each register is represented as an element with this form:
-
- <reg name="NAME"
- bitsize="SIZE"
- [regnum="NUM"]
- [save-restore="SAVE-RESTORE"]
- [type="TYPE"]
- [group="GROUP"]/>
-
-The components are as follows:
-
-NAME
- The register's name; it must be unique within the target
- description.
-
-BITSIZE
- The register's size, in bits.
-
-REGNUM
- The register's number. If omitted, a register's number is one
- greater than that of the previous register (either in the current
- feature or in a preceeding feature); the first register in the
- target description defaults to zero. This register number is used
- to read or write the register; e.g. it is used in the remote `p'
- and `P' packets, and registers appear in the `g' and `G' packets
- in order of increasing register number.
-
-SAVE-RESTORE
- Whether the register should be preserved across inferior function
- calls; this must be either `yes' or `no'. The default is `yes',
- which is appropriate for most registers except for some system
- control registers; this is not related to the target's ABI.
-
-TYPE
- The type of the register. TYPE may be a predefined type, a type
- defined in the current feature, or one of the special types `int'
- and `float'. `int' is an integer type of the correct size for
- BITSIZE, and `float' is a floating point type (in the
- architecture's normal floating point format) of the correct size
- for BITSIZE. The default is `int'.
-
-GROUP
- The register group to which this register belongs. GROUP must be
- either `general', `float', or `vector'. If no GROUP is specified,
- GDB will not display the register in `info registers'.
-
-
-
-File: gdb.info, Node: Predefined Target Types, Next: Standard Target Features, Prev: Target Description Format, Up: Target Descriptions
-
-G.3 Predefined Target Types
-===========================
-
-Type definitions in the self-description can build up composite types
-from basic building blocks, but can not define fundamental types.
-Instead, standard identifiers are provided by GDB for the fundamental
-types. The currently supported types are:
-
-`int8'
-`int16'
-`int32'
-`int64'
-`int128'
- Signed integer types holding the specified number of bits.
-
-`uint8'
-`uint16'
-`uint32'
-`uint64'
-`uint128'
- Unsigned integer types holding the specified number of bits.
-
-`code_ptr'
-`data_ptr'
- Pointers to unspecified code and data. The program counter and
- any dedicated return address register may be marked as code
- pointers; printing a code pointer converts it into a symbolic
- address. The stack pointer and any dedicated address registers
- may be marked as data pointers.
-
-`ieee_single'
- Single precision IEEE floating point.
-
-`ieee_double'
- Double precision IEEE floating point.
-
-`arm_fpa_ext'
- The 12-byte extended precision format used by ARM FPA registers.
-
-`i387_ext'
- The 10-byte extended precision format used by x87 registers.
-
-`i386_eflags'
- 32bit EFLAGS register used by x86.
-
-`i386_mxcsr'
- 32bit MXCSR register used by x86.
-
-
-
-File: gdb.info, Node: Standard Target Features, Prev: Predefined Target Types, Up: Target Descriptions
-
-G.4 Standard Target Features
-============================
-
-A target description must contain either no registers or all the
-target's registers. If the description contains no registers, then GDB
-will assume a default register layout, selected based on the
-architecture. If the description contains any registers, the default
-layout will not be used; the standard registers must be described in
-the target description, in such a way that GDB can recognize them.
-
- This is accomplished by giving specific names to feature elements
-which contain standard registers. GDB will look for features with
-those names and verify that they contain the expected registers; if any
-known feature is missing required registers, or if any required feature
-is missing, GDB will reject the target description. You can add
-additional registers to any of the standard features -- GDB will
-display them just as if they were added to an unrecognized feature.
-
- This section lists the known features and their expected contents.
-Sample XML documents for these features are included in the GDB source
-tree, in the directory `gdb/features'.
-
- Names recognized by GDB should include the name of the company or
-organization which selected the name, and the overall architecture to
-which the feature applies; so e.g. the feature containing ARM core
-registers is named `org.gnu.gdb.arm.core'.
-
- The names of registers are not case sensitive for the purpose of
-recognizing standard features, but GDB will only display registers
-using the capitalization used in the description.
-
-* Menu:
-
-* ARM Features::
-* i386 Features::
-* MIPS Features::
-* M68K Features::
-* PowerPC Features::
-
-
-File: gdb.info, Node: ARM Features, Next: i386 Features, Up: Standard Target Features
-
-G.4.1 ARM Features
-------------------
-
-The `org.gnu.gdb.arm.core' feature is required for non-M-profile ARM
-targets. It should contain registers `r0' through `r13', `sp', `lr',
-`pc', and `cpsr'.
-
- For M-profile targets (e.g. Cortex-M3), the `org.gnu.gdb.arm.core'
-feature is replaced by `org.gnu.gdb.arm.m-profile'. It should contain
-registers `r0' through `r13', `sp', `lr', `pc', and `xpsr'.
-
- The `org.gnu.gdb.arm.fpa' feature is optional. If present, it
-should contain registers `f0' through `f7' and `fps'.
-
- The `org.gnu.gdb.xscale.iwmmxt' feature is optional. If present, it
-should contain at least registers `wR0' through `wR15' and `wCGR0'
-through `wCGR3'. The `wCID', `wCon', `wCSSF', and `wCASF' registers
-are optional.
-
- The `org.gnu.gdb.arm.vfp' feature is optional. If present, it
-should contain at least registers `d0' through `d15'. If they are
-present, `d16' through `d31' should also be included. GDB will
-synthesize the single-precision registers from halves of the
-double-precision registers.
-
- The `org.gnu.gdb.arm.neon' feature is optional. It does not need to
-contain registers; it instructs GDB to display the VFP double-precision
-registers as vectors and to synthesize the quad-precision registers
-from pairs of double-precision registers. If this feature is present,
-`org.gnu.gdb.arm.vfp' must also be present and include 32
-double-precision registers.
-
-
-File: gdb.info, Node: i386 Features, Next: MIPS Features, Prev: ARM Features, Up: Standard Target Features
-
-G.4.2 i386 Features
--------------------
-
-The `org.gnu.gdb.i386.core' feature is required for i386/amd64 targets.
-It should describe the following registers:
-
- - `eax' through `edi' plus `eip' for i386
-
- - `rax' through `r15' plus `rip' for amd64
-
- - `eflags', `cs', `ss', `ds', `es', `fs', `gs'
-
- - `st0' through `st7'
-
- - `fctrl', `fstat', `ftag', `fiseg', `fioff', `foseg', `fooff' and
- `fop'
-
- The register sets may be different, depending on the target.
-
- The `org.gnu.gdb.i386.sse' feature is optional. It should describe
-registers:
-
- - `xmm0' through `xmm7' for i386
-
- - `xmm0' through `xmm15' for amd64
-
- - `mxcsr'
-
- The `org.gnu.gdb.i386.avx' feature is optional and requires the
-`org.gnu.gdb.i386.sse' feature. It should describe the upper 128 bits
-of YMM registers:
-
- - `ymm0h' through `ymm7h' for i386
-
- - `ymm0h' through `ymm15h' for amd64
-
- The `org.gnu.gdb.i386.linux' feature is optional. It should
-describe a single register, `orig_eax'.
-
-
-File: gdb.info, Node: MIPS Features, Next: M68K Features, Prev: i386 Features, Up: Standard Target Features
-
-G.4.3 MIPS Features
--------------------
-
-The `org.gnu.gdb.mips.cpu' feature is required for MIPS targets. It
-should contain registers `r0' through `r31', `lo', `hi', and `pc'.
-They may be 32-bit or 64-bit depending on the target.
-
- The `org.gnu.gdb.mips.cp0' feature is also required. It should
-contain at least the `status', `badvaddr', and `cause' registers. They
-may be 32-bit or 64-bit depending on the target.
-
- The `org.gnu.gdb.mips.fpu' feature is currently required, though it
-may be optional in a future version of GDB. It should contain
-registers `f0' through `f31', `fcsr', and `fir'. They may be 32-bit or
-64-bit depending on the target.
-
- The `org.gnu.gdb.mips.linux' feature is optional. It should contain
-a single register, `restart', which is used by the Linux kernel to
-control restartable syscalls.
-
-
-File: gdb.info, Node: M68K Features, Next: PowerPC Features, Prev: MIPS Features, Up: Standard Target Features
-
-G.4.4 M68K Features
--------------------
-
-``org.gnu.gdb.m68k.core''
-``org.gnu.gdb.coldfire.core''
-``org.gnu.gdb.fido.core''
- One of those features must be always present. The feature that is
- present determines which flavor of m68k is used. The feature that
- is present should contain registers `d0' through `d7', `a0'
- through `a5', `fp', `sp', `ps' and `pc'.
-
-``org.gnu.gdb.coldfire.fp''
- This feature is optional. If present, it should contain registers
- `fp0' through `fp7', `fpcontrol', `fpstatus' and `fpiaddr'.
-
-
-File: gdb.info, Node: PowerPC Features, Prev: M68K Features, Up: Standard Target Features
-
-G.4.5 PowerPC Features
-----------------------
-
-The `org.gnu.gdb.power.core' feature is required for PowerPC targets.
-It should contain registers `r0' through `r31', `pc', `msr', `cr',
-`lr', `ctr', and `xer'. They may be 32-bit or 64-bit depending on the
-target.
-
- The `org.gnu.gdb.power.fpu' feature is optional. It should contain
-registers `f0' through `f31' and `fpscr'.
-
- The `org.gnu.gdb.power.altivec' feature is optional. It should
-contain registers `vr0' through `vr31', `vscr', and `vrsave'.
-
- The `org.gnu.gdb.power.vsx' feature is optional. It should contain
-registers `vs0h' through `vs31h'. GDB will combine these registers
-with the floating point registers (`f0' through `f31') and the altivec
-registers (`vr0' through `vr31') to present the 128-bit wide registers
-`vs0' through `vs63', the set of vector registers for POWER7.
-
- The `org.gnu.gdb.power.spe' feature is optional. It should contain
-registers `ev0h' through `ev31h', `acc', and `spefscr'. SPE targets
-should provide 32-bit registers in `org.gnu.gdb.power.core' and provide
-the upper halves in `ev0h' through `ev31h'. GDB will combine these to
-present registers `ev0' through `ev31' to the user.
-
-
-File: gdb.info, Node: Operating System Information, Next: Trace File Format, Prev: Target Descriptions, Up: Top
-
-Appendix H Operating System Information
-***************************************
-
-* Menu:
-
-* Process list::
-
- Users of GDB often wish to obtain information about the state of the
-operating system running on the target--for example the list of
-processes, or the list of open files. This section describes the
-mechanism that makes it possible. This mechanism is similar to the
-target features mechanism (*note Target Descriptions::), but focuses on
-a different aspect of target.
-
- Operating system information is retrived from the target via the
-remote protocol, using `qXfer' requests (*note qXfer osdata read::).
-The object name in the request should be `osdata', and the ANNEX
-identifies the data to be fetched.
-
-
-File: gdb.info, Node: Process list, Up: Operating System Information
-
-H.1 Process list
-================
-
-When requesting the process list, the ANNEX field in the `qXfer'
-request should be `processes'. The returned data is an XML document.
-The formal syntax of this document is defined in
-`gdb/features/osdata.dtd'.
-
- An example document is:
-
- <?xml version="1.0"?>
- <!DOCTYPE target SYSTEM "osdata.dtd">
- <osdata type="processes">
- <item>
- <column name="pid">1</column>
- <column name="user">root</column>
- <column name="command">/sbin/init</column>
- <column name="cores">1,2,3</column>
- </item>
- </osdata>
-
- Each item should include a column whose name is `pid'. The value of
-that column should identify the process on the target. The `user' and
-`command' columns are optional, and will be displayed by GDB. The
-`cores' column, if present, should contain a comma-separated list of
-cores that this process is running on. Target may provide additional
-columns, which GDB currently ignores.
-
-
-File: gdb.info, Node: Trace File Format, Next: Copying, Prev: Operating System Information, Up: Top
-
-Appendix I Trace File Format
-****************************
-
-The trace file comes in three parts: a header, a textual description
-section, and a trace frame section with binary data.
-
- The header has the form `\x7fTRACE0\n'. The first byte is `0x7f' so
-as to indicate that the file contains binary data, while the `0' is a
-version number that may have different values in the future.
-
- The description section consists of multiple lines of ASCII text
-separated by newline characters (`0xa'). The lines may include a
-variety of optional descriptive or context-setting information, such as
-tracepoint definitions or register set size. GDB will ignore any line
-that it does not recognize. An empty line marks the end of this
-section.
-
- The trace frame section consists of a number of consecutive frames.
-Each frame begins with a two-byte tracepoint number, followed by a
-four-byte size giving the amount of data in the frame. The data in the
-frame consists of a number of blocks, each introduced by a character
-indicating its type (at least register, memory, and trace state
-variable). The data in this section is raw binary, not a hexadecimal
-or other encoding; its endianness matches the target's endianness.
-
-`R BYTES'
- Register block. The number and ordering of bytes matches that of a
- `g' packet in the remote protocol. Note that these are the actual
- bytes, in target order and GDB register order, not a hexadecimal
- encoding.
-
-`M ADDRESS LENGTH BYTES...'
- Memory block. This is a contiguous block of memory, at the 8-byte
- address ADDRESS, with a 2-byte length LENGTH, followed by LENGTH
- bytes.
-
-`V NUMBER VALUE'
- Trace state variable block. This records the 8-byte signed value
- VALUE of trace state variable numbered NUMBER.
-
-
- Future enhancements of the trace file format may include additional
-types of blocks.
-
-
-File: gdb.info, Node: Copying, Next: GNU Free Documentation License, Prev: Trace File Format, Up: Top
-
-Appendix J GNU GENERAL PUBLIC LICENSE
-*************************************
-
- Version 3, 29 June 2007
-
- Copyright (C) 2007 Free Software Foundation, Inc. `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies of this
- license document, but changing it is not allowed.
-
-Preamble
-========
-
-The GNU General Public License is a free, copyleft license for software
-and other kinds of works.
-
- The licenses for most software and other practical works are designed
-to take away your freedom to share and change the works. By contrast,
-the GNU General Public License is intended to guarantee your freedom to
-share and change all versions of a program--to make sure it remains
-free software for all its users. We, the Free Software Foundation, use
-the GNU General Public License for most of our software; it applies
-also to any other work released this way by its authors. You can apply
-it to your programs, too.
-
- When we speak of free software, we are referring to freedom, not
-price. Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-them if you wish), that you receive source code or can get it if you
-want it, that you can change the software or use pieces of it in new
-free programs, and that you know you can do these things.
-
- To protect your rights, we need to prevent others from denying you
-these rights or asking you to surrender the rights. Therefore, you
-have certain responsibilities if you distribute copies of the software,
-or if you modify it: responsibilities to respect the freedom of others.
-
- For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must pass on to the recipients the same
-freedoms that you received. You must make sure that they, too, receive
-or can get the source code. And you must show them these terms so they
-know their rights.
-
- Developers that use the GNU GPL protect your rights with two steps:
-(1) assert copyright on the software, and (2) offer you this License
-giving you legal permission to copy, distribute and/or modify it.
-
- For the developers' and authors' protection, the GPL clearly explains
-that there is no warranty for this free software. For both users' and
-authors' sake, the GPL requires that modified versions be marked as
-changed, so that their problems will not be attributed erroneously to
-authors of previous versions.
-
- Some devices are designed to deny users access to install or run
-modified versions of the software inside them, although the
-manufacturer can do so. This is fundamentally incompatible with the
-aim of protecting users' freedom to change the software. The
-systematic pattern of such abuse occurs in the area of products for
-individuals to use, which is precisely where it is most unacceptable.
-Therefore, we have designed this version of the GPL to prohibit the
-practice for those products. If such problems arise substantially in
-other domains, we stand ready to extend this provision to those domains
-in future versions of the GPL, as needed to protect the freedom of
-users.
-
- Finally, every program is threatened constantly by software patents.
-States should not allow patents to restrict development and use of
-software on general-purpose computers, but in those that do, we wish to
-avoid the special danger that patents applied to a free program could
-make it effectively proprietary. To prevent this, the GPL assures that
-patents cannot be used to render the program non-free.
-
- The precise terms and conditions for copying, distribution and
-modification follow.
-
-TERMS AND CONDITIONS
-====================
-
- 0. Definitions.
-
- "This License" refers to version 3 of the GNU General Public
- License.
-
- "Copyright" also means copyright-like laws that apply to other
- kinds of works, such as semiconductor masks.
-
- "The Program" refers to any copyrightable work licensed under this
- License. Each licensee is addressed as "you". "Licensees" and
- "recipients" may be individuals or organizations.
-
- To "modify" a work means to copy from or adapt all or part of the
- work in a fashion requiring copyright permission, other than the
- making of an exact copy. The resulting work is called a "modified
- version" of the earlier work or a work "based on" the earlier work.
-
- A "covered work" means either the unmodified Program or a work
- based on the Program.
-
- To "propagate" a work means to do anything with it that, without
- permission, would make you directly or secondarily liable for
- infringement under applicable copyright law, except executing it
- on a computer or modifying a private copy. Propagation includes
- copying, distribution (with or without modification), making
- available to the public, and in some countries other activities as
- well.
-
- To "convey" a work means any kind of propagation that enables other
- parties to make or receive copies. Mere interaction with a user
- through a computer network, with no transfer of a copy, is not
- conveying.
-
- An interactive user interface displays "Appropriate Legal Notices"
- to the extent that it includes a convenient and prominently visible
- feature that (1) displays an appropriate copyright notice, and (2)
- tells the user that there is no warranty for the work (except to
- the extent that warranties are provided), that licensees may
- convey the work under this License, and how to view a copy of this
- License. If the interface presents a list of user commands or
- options, such as a menu, a prominent item in the list meets this
- criterion.
-
- 1. Source Code.
-
- The "source code" for a work means the preferred form of the work
- for making modifications to it. "Object code" means any
- non-source form of a work.
-
- A "Standard Interface" means an interface that either is an
- official standard defined by a recognized standards body, or, in
- the case of interfaces specified for a particular programming
- language, one that is widely used among developers working in that
- language.
-
- The "System Libraries" of an executable work include anything,
- other than the work as a whole, that (a) is included in the normal
- form of packaging a Major Component, but which is not part of that
- Major Component, and (b) serves only to enable use of the work
- with that Major Component, or to implement a Standard Interface
- for which an implementation is available to the public in source
- code form. A "Major Component", in this context, means a major
- essential component (kernel, window system, and so on) of the
- specific operating system (if any) on which the executable work
- runs, or a compiler used to produce the work, or an object code
- interpreter used to run it.
-
- The "Corresponding Source" for a work in object code form means all
- the source code needed to generate, install, and (for an executable
- work) run the object code and to modify the work, including
- scripts to control those activities. However, it does not include
- the work's System Libraries, or general-purpose tools or generally
- available free programs which are used unmodified in performing
- those activities but which are not part of the work. For example,
- Corresponding Source includes interface definition files
- associated with source files for the work, and the source code for
- shared libraries and dynamically linked subprograms that the work
- is specifically designed to require, such as by intimate data
- communication or control flow between those subprograms and other
- parts of the work.
-
- The Corresponding Source need not include anything that users can
- regenerate automatically from other parts of the Corresponding
- Source.
-
- The Corresponding Source for a work in source code form is that
- same work.
-
- 2. Basic Permissions.
-
- All rights granted under this License are granted for the term of
- copyright on the Program, and are irrevocable provided the stated
- conditions are met. This License explicitly affirms your unlimited
- permission to run the unmodified Program. The output from running
- a covered work is covered by this License only if the output,
- given its content, constitutes a covered work. This License
- acknowledges your rights of fair use or other equivalent, as
- provided by copyright law.
-
- You may make, run and propagate covered works that you do not
- convey, without conditions so long as your license otherwise
- remains in force. You may convey covered works to others for the
- sole purpose of having them make modifications exclusively for
- you, or provide you with facilities for running those works,
- provided that you comply with the terms of this License in
- conveying all material for which you do not control copyright.
- Those thus making or running the covered works for you must do so
- exclusively on your behalf, under your direction and control, on
- terms that prohibit them from making any copies of your
- copyrighted material outside their relationship with you.
-
- Conveying under any other circumstances is permitted solely under
- the conditions stated below. Sublicensing is not allowed; section
- 10 makes it unnecessary.
-
- 3. Protecting Users' Legal Rights From Anti-Circumvention Law.
-
- No covered work shall be deemed part of an effective technological
- measure under any applicable law fulfilling obligations under
- article 11 of the WIPO copyright treaty adopted on 20 December
- 1996, or similar laws prohibiting or restricting circumvention of
- such measures.
-
- When you convey a covered work, you waive any legal power to forbid
- circumvention of technological measures to the extent such
- circumvention is effected by exercising rights under this License
- with respect to the covered work, and you disclaim any intention
- to limit operation or modification of the work as a means of
- enforcing, against the work's users, your or third parties' legal
- rights to forbid circumvention of technological measures.
-
- 4. Conveying Verbatim Copies.
-
- You may convey verbatim copies of the Program's source code as you
- receive it, in any medium, provided that you conspicuously and
- appropriately publish on each copy an appropriate copyright notice;
- keep intact all notices stating that this License and any
- non-permissive terms added in accord with section 7 apply to the
- code; keep intact all notices of the absence of any warranty; and
- give all recipients a copy of this License along with the Program.
-
- You may charge any price or no price for each copy that you convey,
- and you may offer support or warranty protection for a fee.
-
- 5. Conveying Modified Source Versions.
-
- You may convey a work based on the Program, or the modifications to
- produce it from the Program, in the form of source code under the
- terms of section 4, provided that you also meet all of these
- conditions:
-
- a. The work must carry prominent notices stating that you
- modified it, and giving a relevant date.
-
- b. The work must carry prominent notices stating that it is
- released under this License and any conditions added under
- section 7. This requirement modifies the requirement in
- section 4 to "keep intact all notices".
-
- c. You must license the entire work, as a whole, under this
- License to anyone who comes into possession of a copy. This
- License will therefore apply, along with any applicable
- section 7 additional terms, to the whole of the work, and all
- its parts, regardless of how they are packaged. This License
- gives no permission to license the work in any other way, but
- it does not invalidate such permission if you have separately
- received it.
-
- d. If the work has interactive user interfaces, each must display
- Appropriate Legal Notices; however, if the Program has
- interactive interfaces that do not display Appropriate Legal
- Notices, your work need not make them do so.
-
- A compilation of a covered work with other separate and independent
- works, which are not by their nature extensions of the covered
- work, and which are not combined with it such as to form a larger
- program, in or on a volume of a storage or distribution medium, is
- called an "aggregate" if the compilation and its resulting
- copyright are not used to limit the access or legal rights of the
- compilation's users beyond what the individual works permit.
- Inclusion of a covered work in an aggregate does not cause this
- License to apply to the other parts of the aggregate.
-
- 6. Conveying Non-Source Forms.
-
- You may convey a covered work in object code form under the terms
- of sections 4 and 5, provided that you also convey the
- machine-readable Corresponding Source under the terms of this
- License, in one of these ways:
-
- a. Convey the object code in, or embodied in, a physical product
- (including a physical distribution medium), accompanied by the
- Corresponding Source fixed on a durable physical medium
- customarily used for software interchange.
-
- b. Convey the object code in, or embodied in, a physical product
- (including a physical distribution medium), accompanied by a
- written offer, valid for at least three years and valid for
- as long as you offer spare parts or customer support for that
- product model, to give anyone who possesses the object code
- either (1) a copy of the Corresponding Source for all the
- software in the product that is covered by this License, on a
- durable physical medium customarily used for software
- interchange, for a price no more than your reasonable cost of
- physically performing this conveying of source, or (2) access
- to copy the Corresponding Source from a network server at no
- charge.
-
- c. Convey individual copies of the object code with a copy of
- the written offer to provide the Corresponding Source. This
- alternative is allowed only occasionally and noncommercially,
- and only if you received the object code with such an offer,
- in accord with subsection 6b.
-
- d. Convey the object code by offering access from a designated
- place (gratis or for a charge), and offer equivalent access
- to the Corresponding Source in the same way through the same
- place at no further charge. You need not require recipients
- to copy the Corresponding Source along with the object code.
- If the place to copy the object code is a network server, the
- Corresponding Source may be on a different server (operated
- by you or a third party) that supports equivalent copying
- facilities, provided you maintain clear directions next to
- the object code saying where to find the Corresponding Source.
- Regardless of what server hosts the Corresponding Source, you
- remain obligated to ensure that it is available for as long
- as needed to satisfy these requirements.
-
- e. Convey the object code using peer-to-peer transmission,
- provided you inform other peers where the object code and
- Corresponding Source of the work are being offered to the
- general public at no charge under subsection 6d.
-
-
- A separable portion of the object code, whose source code is
- excluded from the Corresponding Source as a System Library, need
- not be included in conveying the object code work.
-
- A "User Product" is either (1) a "consumer product", which means
- any tangible personal property which is normally used for personal,
- family, or household purposes, or (2) anything designed or sold for
- incorporation into a dwelling. In determining whether a product
- is a consumer product, doubtful cases shall be resolved in favor of
- coverage. For a particular product received by a particular user,
- "normally used" refers to a typical or common use of that class of
- product, regardless of the status of the particular user or of the
- way in which the particular user actually uses, or expects or is
- expected to use, the product. A product is a consumer product
- regardless of whether the product has substantial commercial,
- industrial or non-consumer uses, unless such uses represent the
- only significant mode of use of the product.
-
- "Installation Information" for a User Product means any methods,
- procedures, authorization keys, or other information required to
- install and execute modified versions of a covered work in that
- User Product from a modified version of its Corresponding Source.
- The information must suffice to ensure that the continued
- functioning of the modified object code is in no case prevented or
- interfered with solely because modification has been made.
-
- If you convey an object code work under this section in, or with,
- or specifically for use in, a User Product, and the conveying
- occurs as part of a transaction in which the right of possession
- and use of the User Product is transferred to the recipient in
- perpetuity or for a fixed term (regardless of how the transaction
- is characterized), the Corresponding Source conveyed under this
- section must be accompanied by the Installation Information. But
- this requirement does not apply if neither you nor any third party
- retains the ability to install modified object code on the User
- Product (for example, the work has been installed in ROM).
-
- The requirement to provide Installation Information does not
- include a requirement to continue to provide support service,
- warranty, or updates for a work that has been modified or
- installed by the recipient, or for the User Product in which it
- has been modified or installed. Access to a network may be denied
- when the modification itself materially and adversely affects the
- operation of the network or violates the rules and protocols for
- communication across the network.
-
- Corresponding Source conveyed, and Installation Information
- provided, in accord with this section must be in a format that is
- publicly documented (and with an implementation available to the
- public in source code form), and must require no special password
- or key for unpacking, reading or copying.
-
- 7. Additional Terms.
-
- "Additional permissions" are terms that supplement the terms of
- this License by making exceptions from one or more of its
- conditions. Additional permissions that are applicable to the
- entire Program shall be treated as though they were included in
- this License, to the extent that they are valid under applicable
- law. If additional permissions apply only to part of the Program,
- that part may be used separately under those permissions, but the
- entire Program remains governed by this License without regard to
- the additional permissions.
-
- When you convey a copy of a covered work, you may at your option
- remove any additional permissions from that copy, or from any part
- of it. (Additional permissions may be written to require their own
- removal in certain cases when you modify the work.) You may place
- additional permissions on material, added by you to a covered work,
- for which you have or can give appropriate copyright permission.
-
- Notwithstanding any other provision of this License, for material
- you add to a covered work, you may (if authorized by the copyright
- holders of that material) supplement the terms of this License
- with terms:
-
- a. Disclaiming warranty or limiting liability differently from
- the terms of sections 15 and 16 of this License; or
-
- b. Requiring preservation of specified reasonable legal notices
- or author attributions in that material or in the Appropriate
- Legal Notices displayed by works containing it; or
-
- c. Prohibiting misrepresentation of the origin of that material,
- or requiring that modified versions of such material be
- marked in reasonable ways as different from the original
- version; or
-
- d. Limiting the use for publicity purposes of names of licensors
- or authors of the material; or
-
- e. Declining to grant rights under trademark law for use of some
- trade names, trademarks, or service marks; or
-
- f. Requiring indemnification of licensors and authors of that
- material by anyone who conveys the material (or modified
- versions of it) with contractual assumptions of liability to
- the recipient, for any liability that these contractual
- assumptions directly impose on those licensors and authors.
-
- All other non-permissive additional terms are considered "further
- restrictions" within the meaning of section 10. If the Program as
- you received it, or any part of it, contains a notice stating that
- it is governed by this License along with a term that is a further
- restriction, you may remove that term. If a license document
- contains a further restriction but permits relicensing or
- conveying under this License, you may add to a covered work
- material governed by the terms of that license document, provided
- that the further restriction does not survive such relicensing or
- conveying.
-
- If you add terms to a covered work in accord with this section, you
- must place, in the relevant source files, a statement of the
- additional terms that apply to those files, or a notice indicating
- where to find the applicable terms.
-
- Additional terms, permissive or non-permissive, may be stated in
- the form of a separately written license, or stated as exceptions;
- the above requirements apply either way.
-
- 8. Termination.
-
- You may not propagate or modify a covered work except as expressly
- provided under this License. Any attempt otherwise to propagate or
- modify it is void, and will automatically terminate your rights
- under this License (including any patent licenses granted under
- the third paragraph of section 11).
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, you do not qualify to receive new
- licenses for the same material under section 10.
-
- 9. Acceptance Not Required for Having Copies.
-
- You are not required to accept this License in order to receive or
- run a copy of the Program. Ancillary propagation of a covered work
- occurring solely as a consequence of using peer-to-peer
- transmission to receive a copy likewise does not require
- acceptance. However, nothing other than this License grants you
- permission to propagate or modify any covered work. These actions
- infringe copyright if you do not accept this License. Therefore,
- by modifying or propagating a covered work, you indicate your
- acceptance of this License to do so.
-
- 10. Automatic Licensing of Downstream Recipients.
-
- Each time you convey a covered work, the recipient automatically
- receives a license from the original licensors, to run, modify and
- propagate that work, subject to this License. You are not
- responsible for enforcing compliance by third parties with this
- License.
-
- An "entity transaction" is a transaction transferring control of an
- organization, or substantially all assets of one, or subdividing an
- organization, or merging organizations. If propagation of a
- covered work results from an entity transaction, each party to that
- transaction who receives a copy of the work also receives whatever
- licenses to the work the party's predecessor in interest had or
- could give under the previous paragraph, plus a right to
- possession of the Corresponding Source of the work from the
- predecessor in interest, if the predecessor has it or can get it
- with reasonable efforts.
-
- You may not impose any further restrictions on the exercise of the
- rights granted or affirmed under this License. For example, you
- may not impose a license fee, royalty, or other charge for
- exercise of rights granted under this License, and you may not
- initiate litigation (including a cross-claim or counterclaim in a
- lawsuit) alleging that any patent claim is infringed by making,
- using, selling, offering for sale, or importing the Program or any
- portion of it.
-
- 11. Patents.
-
- A "contributor" is a copyright holder who authorizes use under this
- License of the Program or a work on which the Program is based.
- The work thus licensed is called the contributor's "contributor
- version".
-
- A contributor's "essential patent claims" are all patent claims
- owned or controlled by the contributor, whether already acquired or
- hereafter acquired, that would be infringed by some manner,
- permitted by this License, of making, using, or selling its
- contributor version, but do not include claims that would be
- infringed only as a consequence of further modification of the
- contributor version. For purposes of this definition, "control"
- includes the right to grant patent sublicenses in a manner
- consistent with the requirements of this License.
-
- Each contributor grants you a non-exclusive, worldwide,
- royalty-free patent license under the contributor's essential
- patent claims, to make, use, sell, offer for sale, import and
- otherwise run, modify and propagate the contents of its
- contributor version.
-
- In the following three paragraphs, a "patent license" is any
- express agreement or commitment, however denominated, not to
- enforce a patent (such as an express permission to practice a
- patent or covenant not to sue for patent infringement). To
- "grant" such a patent license to a party means to make such an
- agreement or commitment not to enforce a patent against the party.
-
- If you convey a covered work, knowingly relying on a patent
- license, and the Corresponding Source of the work is not available
- for anyone to copy, free of charge and under the terms of this
- License, through a publicly available network server or other
- readily accessible means, then you must either (1) cause the
- Corresponding Source to be so available, or (2) arrange to deprive
- yourself of the benefit of the patent license for this particular
- work, or (3) arrange, in a manner consistent with the requirements
- of this License, to extend the patent license to downstream
- recipients. "Knowingly relying" means you have actual knowledge
- that, but for the patent license, your conveying the covered work
- in a country, or your recipient's use of the covered work in a
- country, would infringe one or more identifiable patents in that
- country that you have reason to believe are valid.
-
- If, pursuant to or in connection with a single transaction or
- arrangement, you convey, or propagate by procuring conveyance of, a
- covered work, and grant a patent license to some of the parties
- receiving the covered work authorizing them to use, propagate,
- modify or convey a specific copy of the covered work, then the
- patent license you grant is automatically extended to all
- recipients of the covered work and works based on it.
-
- A patent license is "discriminatory" if it does not include within
- the scope of its coverage, prohibits the exercise of, or is
- conditioned on the non-exercise of one or more of the rights that
- are specifically granted under this License. You may not convey a
- covered work if you are a party to an arrangement with a third
- party that is in the business of distributing software, under
- which you make payment to the third party based on the extent of
- your activity of conveying the work, and under which the third
- party grants, to any of the parties who would receive the covered
- work from you, a discriminatory patent license (a) in connection
- with copies of the covered work conveyed by you (or copies made
- from those copies), or (b) primarily for and in connection with
- specific products or compilations that contain the covered work,
- unless you entered into that arrangement, or that patent license
- was granted, prior to 28 March 2007.
-
- Nothing in this License shall be construed as excluding or limiting
- any implied license or other defenses to infringement that may
- otherwise be available to you under applicable patent law.
-
- 12. No Surrender of Others' Freedom.
-
- If conditions are imposed on you (whether by court order,
- agreement or otherwise) that contradict the conditions of this
- License, they do not excuse you from the conditions of this
- License. If you cannot convey a covered work so as to satisfy
- simultaneously your obligations under this License and any other
- pertinent obligations, then as a consequence you may not convey it
- at all. For example, if you agree to terms that obligate you to
- collect a royalty for further conveying from those to whom you
- convey the Program, the only way you could satisfy both those
- terms and this License would be to refrain entirely from conveying
- the Program.
-
- 13. Use with the GNU Affero General Public License.
-
- Notwithstanding any other provision of this License, you have
- permission to link or combine any covered work with a work licensed
- under version 3 of the GNU Affero General Public License into a
- single combined work, and to convey the resulting work. The terms
- of this License will continue to apply to the part which is the
- covered work, but the special requirements of the GNU Affero
- General Public License, section 13, concerning interaction through
- a network will apply to the combination as such.
-
- 14. Revised Versions of this License.
-
- The Free Software Foundation may publish revised and/or new
- versions of the GNU General Public License from time to time.
- Such new versions will be similar in spirit to the present
- version, but may differ in detail to address new problems or
- concerns.
-
- Each version is given a distinguishing version number. If the
- Program specifies that a certain numbered version of the GNU
- General Public License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that numbered version or of any later version published by the
- Free Software Foundation. If the Program does not specify a
- version number of the GNU General Public License, you may choose
- any version ever published by the Free Software Foundation.
-
- If the Program specifies that a proxy can decide which future
- versions of the GNU General Public License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Program.
-
- Later license versions may give you additional or different
- permissions. However, no additional obligations are imposed on any
- author or copyright holder as a result of your choosing to follow a
- later version.
-
- 15. Disclaimer of Warranty.
-
- THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
- APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
- COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
- WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
- INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE
- RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.
- SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
- NECESSARY SERVICING, REPAIR OR CORRECTION.
-
- 16. Limitation of Liability.
-
- IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
- WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
- AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
- FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
- CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
- THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
- BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
- PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
- PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
- THE POSSIBILITY OF SUCH DAMAGES.
-
- 17. Interpretation of Sections 15 and 16.
-
- If the disclaimer of warranty and limitation of liability provided
- above cannot be given local legal effect according to their terms,
- reviewing courts shall apply local law that most closely
- approximates an absolute waiver of all civil liability in
- connection with the Program, unless a warranty or assumption of
- liability accompanies a copy of the Program in return for a fee.
-
-
-END OF TERMS AND CONDITIONS
-===========================
-
-How to Apply These Terms to Your New Programs
-=============================================
-
-If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these
-terms.
-
- To do so, attach the following notices to the program. It is safest
-to attach them to the start of each source file to most effectively
-state the exclusion of warranty; and each file should have at least the
-"copyright" line and a pointer to where the full notice is found.
-
- ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
- Copyright (C) YEAR NAME OF AUTHOR
-
- This program is free software: you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation, either version 3 of the License, or (at
- your option) any later version.
-
- This program is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program. If not, see `http://www.gnu.org/licenses/'.
-
- Also add information on how to contact you by electronic and paper
-mail.
-
- If the program does terminal interaction, make it output a short
-notice like this when it starts in an interactive mode:
-
- PROGRAM Copyright (C) YEAR NAME OF AUTHOR
- This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
- This is free software, and you are welcome to redistribute it
- under certain conditions; type `show c' for details.
-
- The hypothetical commands `show w' and `show c' should show the
-appropriate parts of the General Public License. Of course, your
-program's commands might be different; for a GUI interface, you would
-use an "about box".
-
- You should also get your employer (if you work as a programmer) or
-school, if any, to sign a "copyright disclaimer" for the program, if
-necessary. For more information on this, and how to apply and follow
-the GNU GPL, see `http://www.gnu.org/licenses/'.
-
- The GNU General Public License does not permit incorporating your
-program into proprietary programs. If your program is a subroutine
-library, you may consider it more useful to permit linking proprietary
-applications with the library. If this is what you want to do, use the
-GNU Lesser General Public License instead of this License. But first,
-please read `http://www.gnu.org/philosophy/why-not-lgpl.html'.
-
-
-File: gdb.info, Node: GNU Free Documentation License, Next: Index, Prev: Copying, Up: Top
-
-Appendix K GNU Free Documentation License
-*****************************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: gdb.info, Node: Index, Prev: GNU Free Documentation License, Up: Top
-
-Index
-*****
-
-
-* Menu:
-
-* ! packet: Packets. (line 49)
-* "No symbol "foo" in current context": Variables. (line 74)
-* # (a comment): Command Syntax. (line 38)
-* # in Modula-2: GDB/M2. (line 18)
-* $: Value History. (line 13)
-* $$: Value History. (line 13)
-* $_ and info breakpoints: Set Breaks. (line 128)
-* $_ and info line: Machine Code. (line 30)
-* $_, $__, and value history: Memory. (line 109)
-* $_, convenience variable: Convenience Vars. (line 64)
-* $__, convenience variable: Convenience Vars. (line 73)
-* $_exitcode, convenience variable: Convenience Vars. (line 79)
-* $_sdata, collect: Tracepoint Actions. (line 65)
-* $_sdata, inspect, convenience variable: Convenience Vars. (line 83)
-* $_siginfo, convenience variable: Convenience Vars. (line 89)
-* $_thread, convenience variable: Threads. (line 116)
-* $_tlb, convenience variable: Convenience Vars. (line 95)
-* $bpnum, convenience variable: Set Breaks. (line 6)
-* $cdir, convenience variable: Source Path. (line 108)
-* $cwd, convenience variable: Source Path. (line 108)
-* $tpnum: Create and Delete Tracepoints.
- (line 98)
-* $trace_file: Tracepoint Variables.
- (line 16)
-* $trace_frame: Tracepoint Variables.
- (line 6)
-* $trace_func: Tracepoint Variables.
- (line 19)
-* $trace_line: Tracepoint Variables.
- (line 13)
-* $tracepoint: Tracepoint Variables.
- (line 10)
-* --annotate: Mode Options. (line 107)
-* --args: Mode Options. (line 120)
-* --batch: Mode Options. (line 23)
-* --batch-silent: Mode Options. (line 41)
-* --baud: Mode Options. (line 126)
-* --cd: Mode Options. (line 82)
-* --command: File Options. (line 51)
-* --core: File Options. (line 43)
-* --data-directory: Mode Options. (line 86)
-* --directory: File Options. (line 67)
-* --disable-gdb-index: Mode Options. (line 172)
-* --epoch: Mode Options. (line 102)
-* --eval-command: File Options. (line 57)
-* --exec: File Options. (line 35)
-* --fullname: Mode Options. (line 91)
-* --interpreter: Mode Options. (line 147)
-* --nowindows: Mode Options. (line 72)
-* --nx: Mode Options. (line 11)
-* --pid: File Options. (line 47)
-* --quiet: Mode Options. (line 19)
-* --readnow: File Options. (line 71)
-* --return-child-result: Mode Options. (line 53)
-* --se: File Options. (line 39)
-* --silent: Mode Options. (line 19)
-* --statistics: Mode Options. (line 164)
-* --symbols: File Options. (line 31)
-* --tty: Mode Options. (line 135)
-* --tui: Mode Options. (line 138)
-* --version: Mode Options. (line 168)
-* --windows: Mode Options. (line 78)
-* --with-gdb-datadir: Data Files. (line 19)
-* --with-relocated-sources: Source Path. (line 89)
-* --with-sysroot: Files. (line 434)
-* --write: Mode Options. (line 159)
-* -add-inferior: GDB/MI Miscellaneous Commands.
- (line 288)
-* -b: Mode Options. (line 126)
-* -break-after: GDB/MI Breakpoint Commands.
- (line 11)
-* -break-commands: GDB/MI Breakpoint Commands.
- (line 55)
-* -break-condition: GDB/MI Breakpoint Commands.
- (line 88)
-* -break-delete: GDB/MI Breakpoint Commands.
- (line 125)
-* -break-disable: GDB/MI Breakpoint Commands.
- (line 159)
-* -break-enable: GDB/MI Breakpoint Commands.
- (line 195)
-* -break-info: GDB/MI Breakpoint Commands.
- (line 230)
-* -break-insert: GDB/MI Breakpoint Commands.
- (line 250)
-* -break-list: GDB/MI Breakpoint Commands.
- (line 355)
-* -break-passcount: GDB/MI Breakpoint Commands.
- (line 430)
-* -break-watch: GDB/MI Breakpoint Commands.
- (line 442)
-* -c: File Options. (line 43)
-* -d: File Options. (line 67)
-* -data-disassemble: GDB/MI Data Manipulation.
- (line 12)
-* -data-evaluate-expression: GDB/MI Data Manipulation.
- (line 141)
-* -data-list-changed-registers: GDB/MI Data Manipulation.
- (line 179)
-* -data-list-register-names: GDB/MI Data Manipulation.
- (line 215)
-* -data-list-register-values: GDB/MI Data Manipulation.
- (line 255)
-* -data-read-memory: GDB/MI Data Manipulation.
- (line 345)
-* -data-read-memory-bytes: GDB/MI Data Manipulation.
- (line 452)
-* -data-write-memory-bytes: GDB/MI Data Manipulation.
- (line 527)
-* -e: File Options. (line 35)
-* -enable-pretty-printing: GDB/MI Variable Objects.
- (line 116)
-* -enable-timings: GDB/MI Miscellaneous Commands.
- (line 384)
-* -environment-cd: GDB/MI Program Context.
- (line 33)
-* -environment-directory: GDB/MI Program Context.
- (line 56)
-* -environment-path: GDB/MI Program Context.
- (line 100)
-* -environment-pwd: GDB/MI Program Context.
- (line 141)
-* -ex: File Options. (line 57)
-* -exec-arguments: GDB/MI Program Context.
- (line 9)
-* -exec-continue: GDB/MI Program Execution.
- (line 13)
-* -exec-finish: GDB/MI Program Execution.
- (line 56)
-* -exec-interrupt: GDB/MI Program Execution.
- (line 99)
-* -exec-jump: GDB/MI Program Execution.
- (line 149)
-* -exec-next: GDB/MI Program Execution.
- (line 173)
-* -exec-next-instruction: GDB/MI Program Execution.
- (line 204)
-* -exec-return: GDB/MI Program Execution.
- (line 240)
-* -exec-run: GDB/MI Program Execution.
- (line 283)
-* -exec-step: GDB/MI Program Execution.
- (line 348)
-* -exec-step-instruction: GDB/MI Program Execution.
- (line 390)
-* -exec-until: GDB/MI Program Execution.
- (line 431)
-* -f: Mode Options. (line 91)
-* -file-exec-and-symbols: GDB/MI File Commands.
- (line 12)
-* -file-exec-file: GDB/MI File Commands.
- (line 40)
-* -file-list-exec-source-file: GDB/MI File Commands.
- (line 67)
-* -file-list-exec-source-files: GDB/MI File Commands.
- (line 93)
-* -file-symbol-file: GDB/MI File Commands.
- (line 123)
-* -gdb-exit: GDB/MI Miscellaneous Commands.
- (line 9)
-* -gdb-set: GDB/MI Miscellaneous Commands.
- (line 31)
-* -gdb-show: GDB/MI Miscellaneous Commands.
- (line 54)
-* -gdb-version: GDB/MI Miscellaneous Commands.
- (line 77)
-* -inferior-tty-set: GDB/MI Miscellaneous Commands.
- (line 335)
-* -inferior-tty-show: GDB/MI Miscellaneous Commands.
- (line 358)
-* -interpreter-exec: GDB/MI Miscellaneous Commands.
- (line 310)
-* -l: Mode Options. (line 130)
-* -list-features: GDB/MI Miscellaneous Commands.
- (line 111)
-* -list-target-features: GDB/MI Miscellaneous Commands.
- (line 154)
-* -list-thread-groups: GDB/MI Miscellaneous Commands.
- (line 180)
-* -n: Mode Options. (line 11)
-* -nw: Mode Options. (line 72)
-* -p: File Options. (line 47)
-* -q: Mode Options. (line 19)
-* -r: File Options. (line 71)
-* -s: File Options. (line 31)
-* -stack-info-depth: GDB/MI Stack Manipulation.
- (line 35)
-* -stack-info-frame: GDB/MI Stack Manipulation.
- (line 9)
-* -stack-list-arguments: GDB/MI Stack Manipulation.
- (line 73)
-* -stack-list-frames: GDB/MI Stack Manipulation.
- (line 162)
-* -stack-list-locals: GDB/MI Stack Manipulation.
- (line 265)
-* -stack-list-variables: GDB/MI Stack Manipulation.
- (line 305)
-* -stack-select-frame: GDB/MI Stack Manipulation.
- (line 328)
-* -symbol-list-lines: GDB/MI Symbol Query. (line 9)
-* -t: Mode Options. (line 135)
-* -target-attach: GDB/MI Target Manipulation.
- (line 9)
-* -target-detach: GDB/MI Target Manipulation.
- (line 36)
-* -target-disconnect: GDB/MI Target Manipulation.
- (line 61)
-* -target-download: GDB/MI Target Manipulation.
- (line 85)
-* -target-file-delete: GDB/MI File Transfer Commands.
- (line 57)
-* -target-file-get: GDB/MI File Transfer Commands.
- (line 33)
-* -target-file-put: GDB/MI File Transfer Commands.
- (line 9)
-* -target-select: GDB/MI Target Manipulation.
- (line 198)
-* -thread-info: GDB/MI Thread Commands.
- (line 9)
-* -thread-list-ids: GDB/MI Thread Commands.
- (line 90)
-* -thread-select: GDB/MI Thread Commands.
- (line 118)
-* -trace-define-variable: GDB/MI Tracepoint Commands.
- (line 83)
-* -trace-find: GDB/MI Tracepoint Commands.
- (line 12)
-* -trace-list-variables: GDB/MI Tracepoint Commands.
- (line 100)
-* -trace-save: GDB/MI Tracepoint Commands.
- (line 143)
-* -trace-start: GDB/MI Tracepoint Commands.
- (line 160)
-* -trace-status: GDB/MI Tracepoint Commands.
- (line 176)
-* -trace-stop: GDB/MI Tracepoint Commands.
- (line 244)
-* -var-assign: GDB/MI Variable Objects.
- (line 474)
-* -var-create: GDB/MI Variable Objects.
- (line 134)
-* -var-delete: GDB/MI Variable Objects.
- (line 220)
-* -var-evaluate-expression: GDB/MI Variable Objects.
- (line 453)
-* -var-info-expression: GDB/MI Variable Objects.
- (line 391)
-* -var-info-num-children: GDB/MI Variable Objects.
- (line 269)
-* -var-info-path-expression: GDB/MI Variable Objects.
- (line 415)
-* -var-info-type: GDB/MI Variable Objects.
- (line 378)
-* -var-list-children: GDB/MI Variable Objects.
- (line 285)
-* -var-set-format: GDB/MI Variable Objects.
- (line 233)
-* -var-set-frozen: GDB/MI Variable Objects.
- (line 612)
-* -var-set-update-range: GDB/MI Variable Objects.
- (line 638)
-* -var-set-visualizer: GDB/MI Variable Objects.
- (line 661)
-* -var-show-attributes: GDB/MI Variable Objects.
- (line 439)
-* -var-show-format: GDB/MI Variable Objects.
- (line 256)
-* -var-update: GDB/MI Variable Objects.
- (line 498)
-* -w: Mode Options. (line 78)
-* -x: File Options. (line 51)
-* ., Modula-2 scope operator: M2 Scope. (line 6)
-* .build-id directory: Separate Debug Files.
- (line 6)
-* .debug subdirectories: Separate Debug Files.
- (line 6)
-* .debug_gdb_scripts section: .debug_gdb_scripts section.
- (line 6)
-* .gdb_index section: Index Files. (line 6)
-* .gdbinit: Startup. (line 60)
-* .gnu_debuglink sections: Separate Debug Files.
- (line 78)
-* .note.gnu.build-id sections: Separate Debug Files.
- (line 96)
-* .o files, reading symbols from: Files. (line 132)
-* /proc: SVR4 Process Information.
- (line 6)
-* <architecture>: Target Description Format.
- (line 73)
-* <compatible>: Target Description Format.
- (line 96)
-* <feature>: Target Description Format.
- (line 120)
-* <flags>: Target Description Format.
- (line 186)
-* <osabi>: Target Description Format.
- (line 83)
-* <reg>: Target Description Format.
- (line 199)
-* <struct>: Target Description Format.
- (line 164)
-* <union>: Target Description Format.
- (line 154)
-* <vector>: Target Description Format.
- (line 147)
-* ? packet: Packets. (line 58)
-* @, referencing memory as an array: Arrays. (line 6)
-* ^connected: GDB/MI Result Records.
- (line 22)
-* ^done: GDB/MI Result Records.
- (line 9)
-* ^error: GDB/MI Result Records.
- (line 25)
-* ^exit: GDB/MI Result Records.
- (line 29)
-* ^running: GDB/MI Result Records.
- (line 14)
-* __init__ on Breakpoint: Breakpoints In Python.
- (line 9)
-* __init__ on Command: Commands In Python. (line 12)
-* __init__ on Function: Functions In Python. (line 11)
-* __init__ on Parameter: Parameters In Python.
- (line 20)
-* __init__ on Value: Values From Inferior.
- (line 76)
-* _NSPrintForDebugger, and printing Objective-C objects: The Print Command with Objective-C.
- (line 11)
-* A packet: Packets. (line 65)
-* abbreviation: Command Syntax. (line 13)
-* abort (C-g): Miscellaneous Commands.
- (line 10)
-* accept-line (Newline or Return): Commands For History.
- (line 6)
-* acknowledgment, for GDB remote: Packet Acknowledgment.
- (line 6)
-* actions: Tracepoint Actions. (line 6)
-* active targets: Active Targets. (line 6)
-* Ada: Ada. (line 6)
-* Ada exception catching: Set Catchpoints. (line 19)
-* Ada mode, general: Ada Mode Intro. (line 6)
-* Ada task switching: Ada Tasks. (line 115)
-* Ada tasking and core file debugging: Ada Tasks and Core Files.
- (line 6)
-* Ada, deviations from: Additions to Ada. (line 6)
-* Ada, omissions from: Omissions from Ada. (line 6)
-* Ada, problems: Ada Glitches. (line 6)
-* Ada, tasking: Ada Tasks. (line 6)
-* add new commands for external monitor: Connecting. (line 105)
-* add-inferior: Inferiors and Programs.
- (line 60)
-* add-shared-symbol-files: Files. (line 172)
-* add-symbol-file: Files. (line 113)
-* add-symbol-file-from-memory: Files. (line 162)
-* addr_class: Symbols In Python. (line 71)
-* address <1>: Lazy Strings In Python.
- (line 27)
-* address: Values From Inferior.
- (line 45)
-* address of a symbol: Symbols. (line 44)
-* address size for remote targets: Remote Configuration.
- (line 12)
-* ADP (Angel Debugger Protocol) logging: ARM. (line 89)
-* advance LOCATION: Continuing and Stepping.
- (line 181)
-* aggregates (Ada): Omissions from Ada. (line 44)
-* AIX threads: Debugging Output. (line 28)
-* alignment of remote memory accesses: Packets. (line 228)
-* all-stop mode: All-Stop Mode. (line 6)
-* Alpha stack: MIPS. (line 6)
-* ambiguous expressions: Ambiguous Expressions.
- (line 6)
-* AMD 29K register stack: A29K. (line 6)
-* annotations: Annotations Overview.
- (line 6)
-* annotations for errors, warnings and interrupts: Errors. (line 6)
-* annotations for invalidation messages: Invalidation. (line 6)
-* annotations for prompts: Prompting. (line 6)
-* annotations for running programs: Annotations for Running.
- (line 6)
-* annotations for source display: Source Annotations. (line 6)
-* append: Dump/Restore Files. (line 35)
-* append data to a file: Dump/Restore Files. (line 6)
-* apply command to several threads: Threads. (line 122)
-* apropos: Help. (line 62)
-* architecture debugging info: Debugging Output. (line 18)
-* argument count in user-defined commands: Define. (line 25)
-* arguments (to your program): Arguments. (line 6)
-* arguments, to gdbserver: Server. (line 34)
-* arguments, to user-defined commands: Define. (line 6)
-* ARM 32-bit mode: ARM. (line 25)
-* ARM RDI: ARM. (line 6)
-* array aggregates (Ada): Omissions from Ada. (line 44)
-* array on Type: Types In Python. (line 82)
-* arrays: Arrays. (line 6)
-* arrays in expressions: Expressions. (line 14)
-* artificial array: Arrays. (line 6)
-* assembly instructions: Machine Code. (line 36)
-* assf: Files. (line 172)
-* assignment: Assignment. (line 6)
-* async output in GDB/MI: GDB/MI Output Syntax.
- (line 98)
-* async records in GDB/MI: GDB/MI Async Records.
- (line 6)
-* asynchronous execution: Background Execution.
- (line 6)
-* asynchronous execution, and process record and replay: Process Record and Replay.
- (line 52)
-* AT&T disassembly flavor: Machine Code. (line 127)
-* attach: Attach. (line 6)
-* attach to a program by name: Server. (line 79)
-* attach&: Background Execution.
- (line 38)
-* auto-loading, Python: Auto-loading. (line 6)
-* auto-retry, for remote TCP target: Remote Configuration.
- (line 108)
-* automatic display: Auto Display. (line 6)
-* automatic hardware breakpoints: Set Breaks. (line 284)
-* automatic overlay debugging: Automatic Overlay Debugging.
- (line 6)
-* automatic thread selection: All-Stop Mode. (line 28)
-* auxiliary vector: OS Information. (line 21)
-* AVR: AVR. (line 6)
-* awatch: Set Watchpoints. (line 68)
-* b (break): Set Breaks. (line 6)
-* B packet: Packets. (line 92)
-* b packet: Packets. (line 77)
-* background execution: Background Execution.
- (line 6)
-* backtrace: Backtrace. (line 11)
-* backtrace beyond main function: Backtrace. (line 93)
-* backtrace limit: Backtrace. (line 129)
-* backward-char (C-b): Commands For Moving. (line 15)
-* backward-delete-char (Rubout): Commands For Text. (line 11)
-* backward-kill-line (C-x Rubout): Commands For Killing.
- (line 9)
-* backward-kill-word (M-<DEL>): Commands For Killing.
- (line 24)
-* backward-word (M-b): Commands For Moving. (line 22)
-* base name differences: Files. (line 501)
-* baud rate for remote targets: Remote Configuration.
- (line 21)
-* bc packet: Packets. (line 97)
-* bcache statistics: Maintenance Commands.
- (line 223)
-* beginning-of-history (M-<): Commands For History.
- (line 19)
-* beginning-of-line (C-a): Commands For Moving. (line 6)
-* bell-style: Readline Init File Syntax.
- (line 35)
-* bind-tty-special-chars: Readline Init File Syntax.
- (line 42)
-* bits in remote address: Remote Configuration.
- (line 12)
-* block on Frame: Frames In Python. (line 83)
-* block_for_pc: Blocks In Python. (line 17)
-* blocks in python: Blocks In Python. (line 6)
-* bookmark: Checkpoint/Restart. (line 6)
-* BP_ACCESS_WATCHPOINT: Breakpoints In Python.
- (line 131)
-* BP_BREAKPOINT: Breakpoints In Python.
- (line 119)
-* BP_HARDWARE_WATCHPOINT: Breakpoints In Python.
- (line 125)
-* BP_READ_WATCHPOINT: Breakpoints In Python.
- (line 128)
-* BP_WATCHPOINT: Breakpoints In Python.
- (line 122)
-* break: Set Breaks. (line 6)
-* break ... task TASKNO (Ada): Ada Tasks. (line 135)
-* break ... thread THREADNO: Thread-Specific Breakpoints.
- (line 10)
-* break in overloaded functions: Debugging C Plus Plus.
- (line 9)
-* break on a system call.: Set Catchpoints. (line 48)
-* break on fork/exec: Set Catchpoints. (line 43)
-* BREAK signal instead of Ctrl-C: Remote Configuration.
- (line 29)
-* break, and Objective-C: Method Names in Commands.
- (line 9)
-* break-range: PowerPC Embedded. (line 38)
-* breakpoint: Events In Python. (line 102)
-* breakpoint address adjusted: Breakpoint-related Warnings.
- (line 6)
-* breakpoint annotation: Annotations for Running.
- (line 47)
-* breakpoint commands: Break Commands. (line 6)
-* breakpoint commands for GDB/MI: GDB/MI Breakpoint Commands.
- (line 6)
-* breakpoint conditions: Conditions. (line 6)
-* breakpoint numbers: Breakpoints. (line 41)
-* breakpoint on events: Breakpoints. (line 33)
-* breakpoint on memory address: Breakpoints. (line 20)
-* breakpoint on variable modification: Breakpoints. (line 20)
-* breakpoint ranges: Breakpoints. (line 48)
-* breakpoint subroutine, remote: Stub Contents. (line 31)
-* breakpointing Ada elaboration code: Stopping Before Main Program.
- (line 6)
-* breakpoints <1>: Basic Python. (line 32)
-* breakpoints: Breakpoints. (line 6)
-* breakpoints and tasks, in Ada: Ada Tasks. (line 135)
-* breakpoints and threads: Thread-Specific Breakpoints.
- (line 10)
-* breakpoints at functions matching a regexp: Set Breaks. (line 92)
-* breakpoints in overlays: Overlay Commands. (line 93)
-* breakpoints in python: Breakpoints In Python.
- (line 6)
-* breakpoints, multiple locations: Set Breaks. (line 190)
-* breakpoints-invalid annotation: Invalidation. (line 13)
-* bs packet: Packets. (line 103)
-* bt (backtrace): Backtrace. (line 11)
-* bug criteria: Bug Criteria. (line 6)
-* bug reports: Bug Reporting. (line 6)
-* bugs in GDB: GDB Bugs. (line 6)
-* build ID sections: Separate Debug Files.
- (line 96)
-* build ID, and separate debugging files: Separate Debug Files.
- (line 6)
-* building GDB, requirements for: Requirements. (line 6)
-* built-in simulator target: Target Commands. (line 73)
-* c (continue): Continuing and Stepping.
- (line 15)
-* c (SingleKey TUI key): TUI Single Key Mode. (line 10)
-* C and C++: C. (line 6)
-* C and C++ checks: C Checks. (line 6)
-* C and C++ constants: C Constants. (line 6)
-* C and C++ defaults: C Defaults. (line 6)
-* C and C++ operators: C Operators. (line 6)
-* C packet: Packets. (line 116)
-* c packet: Packets. (line 110)
-* C++: C. (line 10)
-* C++ compilers: C Plus Plus Expressions.
- (line 8)
-* C++ exception handling: Debugging C Plus Plus.
- (line 20)
-* C++ overload debugging info: Debugging Output. (line 125)
-* C++ scope resolution: Variables. (line 54)
-* C++ symbol decoding style: Print Settings. (line 296)
-* C++ symbol display: Debugging C Plus Plus.
- (line 29)
-* C-L: TUI Keys. (line 65)
-* C-x 1: TUI Keys. (line 19)
-* C-x 2: TUI Keys. (line 26)
-* C-x a: TUI Keys. (line 11)
-* C-x A: TUI Keys. (line 12)
-* C-x C-a: TUI Keys. (line 10)
-* C-x o: TUI Keys. (line 34)
-* C-x s: TUI Keys. (line 41)
-* caching data of remote targets: Caching Remote Data. (line 6)
-* call: Calling. (line 10)
-* call dummy stack unwinding: Calling. (line 35)
-* call dummy stack unwinding on unhandled exception.: Calling.
- (line 46)
-* call overloaded functions: C Plus Plus Expressions.
- (line 27)
-* call stack: Stack. (line 9)
-* call stack traces: Backtrace. (line 6)
-* call-last-kbd-macro (C-x e): Keyboard Macros. (line 13)
-* calling functions: Calling. (line 6)
-* calling make: Shell Commands. (line 19)
-* capitalize-word (M-c): Commands For Text. (line 49)
-* case sensitivity in symbol names: Symbols. (line 27)
-* case-insensitive symbol names: Symbols. (line 27)
-* cast on Value: Values From Inferior.
- (line 109)
-* casts, in expressions: Expressions. (line 28)
-* casts, to view memory: Expressions. (line 43)
-* catch: Set Catchpoints. (line 10)
-* catch Ada exceptions: Set Catchpoints. (line 19)
-* catch exceptions, list active handlers: Frame Info. (line 60)
-* catchpoints: Breakpoints. (line 33)
-* catchpoints, setting: Set Catchpoints. (line 6)
-* cd: Working Directory. (line 16)
-* cdir: Source Path. (line 108)
-* Cell Broadband Engine: SPU. (line 6)
-* change working directory: Working Directory. (line 16)
-* character sets: Character Sets. (line 6)
-* character-search (C-]): Miscellaneous Commands.
- (line 41)
-* character-search-backward (M-C-]): Miscellaneous Commands.
- (line 46)
-* charset: Character Sets. (line 6)
-* checkpoint: Checkpoint/Restart. (line 6)
-* checkpoints and process id: Checkpoint/Restart. (line 80)
-* checks, range: Type Checking. (line 65)
-* checks, type: Checks. (line 31)
-* checksum, for GDB remote: Overview. (line 20)
-* children on pretty printer: Pretty Printing API. (line 12)
-* choosing target byte order: Byte Order. (line 6)
-* circular trace buffer: Starting and Stopping Trace Experiments.
- (line 74)
-* clear: Delete Breaks. (line 21)
-* clear, and Objective-C: Method Names in Commands.
- (line 9)
-* clear-screen (C-l): Commands For Moving. (line 26)
-* clearing breakpoints, watchpoints, catchpoints: Delete Breaks.
- (line 6)
-* clone-inferior: Inferiors and Programs.
- (line 67)
-* close, file-i/o system call: close. (line 6)
-* closest symbol and offset for an address: Symbols. (line 54)
-* code: Types In Python. (line 24)
-* code address and its source line: Machine Code. (line 25)
-* collect (tracepoints): Tracepoint Actions. (line 49)
-* collected data discarded: Starting and Stopping Trace Experiments.
- (line 6)
-* colon, doubled as scope operator: M2 Scope. (line 6)
-* colon-colon, context for variables/functions: Variables. (line 44)
-* colon-colon, in Modula-2: M2 Scope. (line 6)
-* command editing: Readline Bare Essentials.
- (line 6)
-* command files: Command Files. (line 6)
-* command history: Command History. (line 6)
-* command hooks: Hooks. (line 6)
-* command interpreters: Interpreters. (line 6)
-* command line editing: Editing. (line 6)
-* command scripts, debugging: Messages/Warnings. (line 67)
-* command tracing: Messages/Warnings. (line 62)
-* COMMAND_BREAKPOINTS: Commands In Python. (line 145)
-* COMMAND_DATA: Commands In Python. (line 115)
-* COMMAND_FILES: Commands In Python. (line 126)
-* COMMAND_MAINTENANCE: Commands In Python. (line 163)
-* COMMAND_NONE: Commands In Python. (line 105)
-* COMMAND_OBSCURE: Commands In Python. (line 157)
-* COMMAND_RUNNING: Commands In Python. (line 109)
-* COMMAND_STACK: Commands In Python. (line 120)
-* COMMAND_STATUS: Commands In Python. (line 139)
-* COMMAND_SUPPORT: Commands In Python. (line 132)
-* COMMAND_TRACEPOINTS: Commands In Python. (line 151)
-* commands <1>: Breakpoints In Python.
- (line 157)
-* commands: Break Commands. (line 11)
-* commands annotation: Prompting. (line 27)
-* commands for C++: Debugging C Plus Plus.
- (line 6)
-* commands in python: Commands In Python. (line 6)
-* commands to access python: Python Commands. (line 6)
-* comment: Command Syntax. (line 38)
-* comment-begin: Readline Init File Syntax.
- (line 47)
-* COMMON blocks, Fortran: Special Fortran Commands.
- (line 9)
-* common targets: Target Commands. (line 46)
-* compare-sections: Memory. (line 129)
-* compatibility, GDB/MI and CLI: GDB/MI Compatibility with CLI.
- (line 6)
-* compilation directory: Source Path. (line 108)
-* compiling, on Sparclet: Sparclet. (line 16)
-* complete: Help. (line 76)
-* complete (<TAB>): Commands For Completion.
- (line 6)
-* complete on Command: Commands In Python. (line 73)
-* COMPLETE_COMMAND: Commands In Python. (line 184)
-* COMPLETE_FILENAME: Commands In Python. (line 177)
-* COMPLETE_LOCATION: Commands In Python. (line 180)
-* COMPLETE_NONE: Commands In Python. (line 174)
-* COMPLETE_SYMBOL: Commands In Python. (line 188)
-* completion: Completion. (line 6)
-* completion of Python commands: Commands In Python. (line 72)
-* completion of quoted strings: Completion. (line 57)
-* completion of structure field names: Completion. (line 96)
-* completion of union field names: Completion. (line 96)
-* completion-query-items: Readline Init File Syntax.
- (line 57)
-* compressed debug sections: Requirements. (line 41)
-* condition <1>: Breakpoints In Python.
- (line 152)
-* condition: Conditions. (line 45)
-* conditional breakpoints: Conditions. (line 6)
-* conditional tracepoints: Tracepoint Conditions.
- (line 6)
-* configuring GDB: Running Configure. (line 6)
-* confirmation: Messages/Warnings. (line 50)
-* connect on EventRegistry: Events In Python. (line 20)
-* connection timeout, for remote TCP target: Remote Configuration.
- (line 123)
-* console i/o as part of file-i/o: Console I/O. (line 6)
-* console interpreter: Interpreters. (line 21)
-* console output in GDB/MI: GDB/MI Output Syntax.
- (line 106)
-* const on Type: Types In Python. (line 91)
-* constants, in file-i/o protocol: Constants. (line 6)
-* continue: Continuing and Stepping.
- (line 15)
-* continue&: Background Execution.
- (line 53)
-* continuing: Continuing and Stepping.
- (line 6)
-* continuing threads: Thread Stops. (line 6)
-* control C, and remote debugging: Bootstrapping. (line 25)
-* controlling terminal: Input/Output. (line 23)
-* convenience functions: Convenience Vars. (line 106)
-* convenience functions in python: Functions In Python. (line 6)
-* convenience variables: Convenience Vars. (line 6)
-* convenience variables for tracepoints: Tracepoint Variables.
- (line 6)
-* convenience variables, and trace state variables: Trace State Variables.
- (line 17)
-* convenience variables, initializing: Convenience Vars. (line 41)
-* convert-meta: Readline Init File Syntax.
- (line 67)
-* copy-backward-word (): Commands For Killing.
- (line 49)
-* copy-forward-word (): Commands For Killing.
- (line 54)
-* copy-region-as-kill (): Commands For Killing.
- (line 45)
-* core dump file: Files. (line 6)
-* core dump file target: Target Commands. (line 54)
-* core-file: Files. (line 97)
-* crash of debugger: Bug Criteria. (line 9)
-* CRC algorithm definition: Separate Debug Files.
- (line 140)
-* CRC of memory block, remote request: General Query Packets.
- (line 63)
-* CRIS: CRIS. (line 6)
-* CRIS mode: CRIS. (line 26)
-* CRIS version: CRIS. (line 10)
-* Ctrl-BREAK, MS-Windows: Cygwin Native. (line 9)
-* ctrl-c message, in file-i/o protocol: The Ctrl-C Message. (line 6)
-* Ctrl-o (operate-and-get-next): Command Syntax. (line 42)
-* current Ada task ID: Ada Tasks. (line 105)
-* current directory: Source Path. (line 108)
-* current stack frame: Frames. (line 45)
-* current thread: Threads. (line 45)
-* current thread, remote request: General Query Packets.
- (line 52)
-* current_objfile: Objfiles In Python. (line 16)
-* current_progspace: Progspaces In Python.
- (line 15)
-* cwd: Source Path. (line 108)
-* Cygwin DLL, debugging: Cygwin Native. (line 42)
-* Cygwin-specific commands: Cygwin Native. (line 6)
-* D: D. (line 6)
-* d (delete): Delete Breaks. (line 41)
-* d (SingleKey TUI key): TUI Single Key Mode. (line 13)
-* d packet: Packets. (line 122)
-* D packet: Packets. (line 129)
-* Darwin: Darwin. (line 6)
-* data breakpoints: Breakpoints. (line 20)
-* data manipulation, in GDB/MI: GDB/MI Data Manipulation.
- (line 6)
-* dcache line-size: Caching Remote Data. (line 48)
-* dcache size: Caching Remote Data. (line 45)
-* dead names, GNU Hurd: Hurd Native. (line 85)
-* debug expression parser: Debugging Output. (line 131)
-* debug formats and C++: C Plus Plus Expressions.
- (line 8)
-* debug link sections: Separate Debug Files.
- (line 78)
-* debug remote protocol: Debugging Output. (line 140)
-* debug_chaos: M32R/D. (line 50)
-* debugger crash: Bug Criteria. (line 9)
-* debugging C++ programs: C Plus Plus Expressions.
- (line 8)
-* debugging information directory, global: Separate Debug Files.
- (line 6)
-* debugging information in separate files: Separate Debug Files.
- (line 6)
-* debugging libthread_db: Threads. (line 212)
-* debugging multiple processes: Forks. (line 52)
-* debugging optimized code: Optimized Code. (line 6)
-* debugging stub, example: Remote Stub. (line 6)
-* debugging target: Targets. (line 6)
-* debugging the Cygwin DLL: Cygwin Native. (line 42)
-* decimal floating point format: Decimal Floating Point.
- (line 6)
-* decode_line: Basic Python. (line 158)
-* default collection action: Tracepoint Actions. (line 114)
-* default data directory: Data Files. (line 19)
-* default source path substitution: Source Path. (line 89)
-* default system root: Files. (line 434)
-* default_visualizer: Pretty Printing API. (line 86)
-* define: Define. (line 37)
-* define trace state variable, remote request: Tracepoint Packets.
- (line 127)
-* defining macros interactively: Macros. (line 52)
-* definition, showing a macro's: Macros. (line 47)
-* delete: Delete Breaks. (line 41)
-* delete breakpoints: Delete Breaks. (line 41)
-* delete checkpoint CHECKPOINT-ID: Checkpoint/Restart. (line 56)
-* delete display: Auto Display. (line 45)
-* delete mem: Memory Region Attributes.
- (line 34)
-* delete on Breakpoint: Breakpoints In Python.
- (line 70)
-* delete tracepoint: Create and Delete Tracepoints.
- (line 101)
-* delete tvariable: Trace State Variables.
- (line 42)
-* delete-char (C-d): Commands For Text. (line 6)
-* delete-char-or-list (): Commands For Completion.
- (line 30)
-* delete-horizontal-space (): Commands For Killing.
- (line 37)
-* deleting breakpoints, watchpoints, catchpoints: Delete Breaks.
- (line 6)
-* deliver a signal to a program: Signaling. (line 6)
-* demangling C++ names: Print Settings. (line 277)
-* deprecated commands: Maintenance Commands.
- (line 90)
-* dereference on Value: Values From Inferior.
- (line 115)
-* derived type of an object, printing: Print Settings. (line 329)
-* descriptor tables display: DJGPP Native. (line 24)
-* detach: Attach. (line 36)
-* detach (remote): Connecting. (line 91)
-* detach from task, GNU Hurd: Hurd Native. (line 60)
-* detach from thread, GNU Hurd: Hurd Native. (line 110)
-* detach inferiors INFNO...: Inferiors and Programs.
- (line 97)
-* digit-argument (M-0, M-1, ... M--): Numeric Arguments. (line 6)
-* dir: Source Path. (line 39)
-* direct memory access (DMA) on MS-DOS: DJGPP Native. (line 75)
-* directories for source files: Source Path. (line 6)
-* directory: Source Path. (line 39)
-* directory, compilation: Source Path. (line 108)
-* directory, current: Source Path. (line 108)
-* dis (disable): Disabling. (line 38)
-* disable: Disabling. (line 38)
-* disable display: Auto Display. (line 56)
-* disable mem: Memory Region Attributes.
- (line 38)
-* disable pretty-printer: Pretty-Printer Commands.
- (line 20)
-* disable tracepoint: Enable and Disable Tracepoints.
- (line 9)
-* disable-completion: Readline Init File Syntax.
- (line 73)
-* disassemble: Machine Code. (line 36)
-* disconnect: Connecting. (line 98)
-* disconnect on EventRegistry: Events In Python. (line 25)
-* disconnected tracing: Starting and Stopping Trace Experiments.
- (line 38)
-* displaced stepping debugging info: Debugging Output. (line 53)
-* displaced stepping support: Maintenance Commands.
- (line 56)
-* displaced stepping, and process record and replay: Process Record and Replay.
- (line 47)
-* display: Auto Display. (line 23)
-* display command history: Command History. (line 78)
-* display derived types: Print Settings. (line 329)
-* display disabled out of scope: Auto Display. (line 86)
-* display GDB copyright: Help. (line 136)
-* display of expressions: Auto Display. (line 6)
-* display remote monitor communications: Target Commands. (line 108)
-* display remote packets: Debugging Output. (line 140)
-* display_hint on pretty printer: Pretty Printing API. (line 25)
-* DJGPP debugging: DJGPP Native. (line 6)
-* dll-symbols: Cygwin Native. (line 38)
-* DLLs with no debugging symbols: Non-debug DLL Symbols.
- (line 6)
-* do (down): Selection. (line 40)
-* do not print frame argument values: Print Settings. (line 135)
-* do-uppercase-version (M-a, M-b, M-X, ...): Miscellaneous Commands.
- (line 14)
-* document: Define. (line 49)
-* documentation: Formatting Documentation.
- (line 22)
-* don't repeat command: Define. (line 61)
-* don't repeat Python command: Commands In Python. (line 43)
-* dont-repeat: Define. (line 61)
-* dont_repeat on Command: Commands In Python. (line 44)
-* DOS file-name semantics of file names.: Files. (line 457)
-* DOS serial data link, remote debugging: DJGPP Native. (line 121)
-* DOS serial port status: DJGPP Native. (line 142)
-* down: Selection. (line 40)
-* Down: TUI Keys. (line 56)
-* down-silently: Selection. (line 64)
-* downcase-word (M-l): Commands For Text. (line 45)
-* download server address (M32R): M32R/D. (line 27)
-* download to Sparclet: Sparclet Download. (line 6)
-* download to VxWorks: VxWorks Download. (line 6)
-* DPMI: DJGPP Native. (line 6)
-* dump: Dump/Restore Files. (line 13)
-* dump all data collected at tracepoint: tdump. (line 6)
-* dump core from inferior: Core File Generation.
- (line 6)
-* dump data to a file: Dump/Restore Files. (line 6)
-* dump-functions (): Miscellaneous Commands.
- (line 61)
-* dump-macros (): Miscellaneous Commands.
- (line 73)
-* dump-variables (): Miscellaneous Commands.
- (line 67)
-* dump/restore files: Dump/Restore Files. (line 6)
-* DVC register: PowerPC Embedded. (line 6)
-* DWARF 2 compilation units cache: Maintenance Commands.
- (line 281)
-* DWARF-2 CFI and CRIS: CRIS. (line 18)
-* DWARF2 DIEs: Debugging Output. (line 46)
-* dynamic linking: Files. (line 113)
-* dynamic varobj: GDB/MI Variable Objects.
- (line 164)
-* dynamic_cast on Value: Values From Inferior.
- (line 131)
-* dynamic_type: Values From Inferior.
- (line 59)
-* e (edit): Edit. (line 6)
-* echo: Output. (line 12)
-* edit: Edit. (line 6)
-* editing: Editing. (line 15)
-* editing command lines: Readline Bare Essentials.
- (line 6)
-* editing source files: Edit. (line 6)
-* editing-mode: Readline Init File Syntax.
- (line 78)
-* eight-bit characters in strings: Print Settings. (line 222)
-* elaboration phase: Starting. (line 90)
-* else: Command Files. (line 75)
-* Emacs: Emacs. (line 6)
-* empty response, for unsupported packets: Overview. (line 96)
-* enable: Disabling. (line 45)
-* enable display: Auto Display. (line 65)
-* enable mem: Memory Region Attributes.
- (line 42)
-* enable pretty-printer: Pretty-Printer Commands.
- (line 25)
-* enable tracepoint: Enable and Disable Tracepoints.
- (line 15)
-* enable-keypad: Readline Init File Syntax.
- (line 84)
-* enable/disable a breakpoint: Disabling. (line 6)
-* enabled: Breakpoints In Python.
- (line 75)
-* encoding: Lazy Strings In Python.
- (line 37)
-* end: Blocks In Python. (line 40)
-* end (breakpoint commands): Break Commands. (line 11)
-* end (if/else/while commands): Command Files. (line 104)
-* end (user-defined commands): Define. (line 49)
-* end-kbd-macro (C-x )): Keyboard Macros. (line 9)
-* end-of-history (M->): Commands For History.
- (line 22)
-* end-of-line (C-e): Commands For Moving. (line 9)
-* entering numbers: Numbers. (line 6)
-* environment (of your program): Environment. (line 6)
-* errno values, in file-i/o protocol: Errno Values. (line 6)
-* error annotation: Errors. (line 10)
-* error on valid input: Bug Criteria. (line 12)
-* error-begin annotation: Errors. (line 22)
-* eval: Output. (line 117)
-* event debugging info: Debugging Output. (line 61)
-* event designators: Event Designators. (line 6)
-* event handling: Set Catchpoints. (line 6)
-* examine process image: SVR4 Process Information.
- (line 6)
-* examining data: Data. (line 6)
-* examining memory: Memory. (line 9)
-* exception handlers: Set Catchpoints. (line 6)
-* exception handlers, how to list: Frame Info. (line 60)
-* exceptionHandler: Bootstrapping. (line 38)
-* exceptions, python: Exception Handling. (line 6)
-* exchange-point-and-mark (C-x C-x): Miscellaneous Commands.
- (line 36)
-* exec-file: Files. (line 39)
-* executable file: Files. (line 16)
-* executable file target: Target Commands. (line 50)
-* executable file, for remote target: Remote Configuration.
- (line 79)
-* execute: Basic Python. (line 15)
-* execute commands from a file: Command Files. (line 17)
-* execute forward or backward in time: Reverse Execution. (line 87)
-* execute remote command, remote request: General Query Packets.
- (line 268)
-* execution, foreground, background and asynchronous: Background Execution.
- (line 6)
-* exit_code: Events In Python. (line 72)
-* exited annotation: Annotations for Running.
- (line 18)
-* exiting GDB: Quitting GDB. (line 6)
-* expand macro once: Macros. (line 38)
-* expand-tilde: Readline Init File Syntax.
- (line 89)
-* expanding preprocessor macros: Macros. (line 29)
-* expression: Breakpoints In Python.
- (line 146)
-* expression debugging info: Debugging Output. (line 68)
-* expression parser, debugging info: Debugging Output. (line 131)
-* expressions: Expressions. (line 6)
-* expressions in Ada: Ada. (line 11)
-* expressions in C or C++: C. (line 6)
-* expressions in C++: C Plus Plus Expressions.
- (line 6)
-* expressions in Modula-2: Modula-2. (line 12)
-* extend GDB for remote targets: Connecting. (line 105)
-* extending GDB: Extending GDB. (line 6)
-* extra signal information: Signals. (line 102)
-* f (frame): Selection. (line 11)
-* f (SingleKey TUI key): TUI Single Key Mode. (line 16)
-* F packet: Packets. (line 146)
-* F reply packet: The F Reply Packet. (line 6)
-* F request packet: The F Request Packet.
- (line 6)
-* fast tracepoints: Set Tracepoints. (line 24)
-* fast tracepoints, setting: Create and Delete Tracepoints.
- (line 40)
-* fatal signal: Bug Criteria. (line 9)
-* fatal signals: Signals. (line 15)
-* features of the remote protocol: General Query Packets.
- (line 328)
-* fg (resume foreground execution): Continuing and Stepping.
- (line 15)
-* fields on Type: Types In Python. (line 41)
-* file: Files. (line 16)
-* file name canonicalization: Files. (line 501)
-* file transfer: File Transfer. (line 6)
-* file transfer, remote protocol: Host I/O Packets. (line 6)
-* file-i/o examples: File-I/O Examples. (line 6)
-* file-i/o overview: File-I/O Overview. (line 6)
-* File-I/O remote protocol extension: File-I/O Remote Protocol Extension.
- (line 6)
-* file-i/o reply packet: The F Reply Packet. (line 6)
-* file-i/o request packet: The F Request Packet.
- (line 6)
-* filename <1>: Symbol Tables In Python.
- (line 41)
-* filename <2>: Progspaces In Python.
- (line 25)
-* filename: Objfiles In Python. (line 29)
-* fin (finish): Continuing and Stepping.
- (line 110)
-* find: Searching Memory. (line 9)
-* find downloadable SREC files (M32R): M32R/D. (line 15)
-* find trace snapshot: tfind. (line 6)
-* find_sal on Frame: Frames In Python. (line 96)
-* finish: Continuing and Stepping.
- (line 110)
-* finish&: Background Execution.
- (line 56)
-* flinching: Messages/Warnings. (line 50)
-* float promotion: ABI. (line 29)
-* floating point: Floating Point Hardware.
- (line 6)
-* floating point registers: Registers. (line 15)
-* floating point, MIPS remote: MIPS Embedded. (line 60)
-* flush: Basic Python. (line 122)
-* flush_i_cache: Bootstrapping. (line 60)
-* flushregs: Maintenance Commands.
- (line 208)
-* focus: TUI Commands. (line 40)
-* focus of debugging: Threads. (line 45)
-* foo: Symbol Errors. (line 50)
-* foreground execution: Background Execution.
- (line 6)
-* fork, debugging programs which call: Forks. (line 6)
-* format options: Print Settings. (line 6)
-* formatted output: Output Formats. (line 6)
-* Fortran: Summary. (line 40)
-* Fortran Defaults: Fortran Defaults. (line 6)
-* Fortran operators and expressions: Fortran Operators. (line 6)
-* Fortran-specific support in GDB: Fortran. (line 6)
-* forward-backward-delete-char (): Commands For Text. (line 15)
-* forward-char (C-f): Commands For Moving. (line 12)
-* forward-search: Search. (line 9)
-* forward-search-history (C-s): Commands For History.
- (line 30)
-* forward-word (M-f): Commands For Moving. (line 18)
-* FR-V shared-library debugging: Debugging Output. (line 158)
-* frame debugging info: Debugging Output. (line 76)
-* frame number: Frames. (line 28)
-* frame pointer: Frames. (line 21)
-* frame pointer register: Registers. (line 26)
-* frame, command: Frames. (line 45)
-* frame, definition: Frames. (line 6)
-* frame, selecting: Selection. (line 11)
-* frame_stop_reason_string: Frames In Python. (line 30)
-* frameless execution: Frames. (line 34)
-* frames in python: Frames In Python. (line 6)
-* frames-invalid annotation: Invalidation. (line 9)
-* free memory information (MS-DOS): DJGPP Native. (line 19)
-* fstat, file-i/o system call: stat/fstat. (line 6)
-* ftrace: Create and Delete Tracepoints.
- (line 40)
-* Fujitsu: Remote Stub. (line 69)
-* full symbol tables, listing GDB's internal: Symbols. (line 291)
-* fullname on Symtab: Symbol Tables In Python.
- (line 58)
-* Function: Functions In Python. (line 6)
-* function: Blocks In Python. (line 43)
-* function call arguments, optimized out: Backtrace. (line 71)
-* function entry/exit, wrong values of variables: Variables. (line 58)
-* function on Frame: Frames In Python. (line 86)
-* functions without line info, and stepping: Continuing and Stepping.
- (line 93)
-* G packet: Packets. (line 180)
-* g packet: Packets. (line 151)
-* g++, GNU C++ compiler: C. (line 10)
-* garbled pointers: DJGPP Native. (line 42)
-* GCC and C++: C Plus Plus Expressions.
- (line 8)
-* gcore: Core File Generation.
- (line 18)
-* GDB bugs, reporting: Bug Reporting. (line 6)
-* GDB internal error: Maintenance Commands.
- (line 124)
-* gdb module: Basic Python. (line 6)
-* GDB reference card: Formatting Documentation.
- (line 6)
-* GDB startup: Startup. (line 6)
-* GDB version number: Help. (line 126)
-* gdb.Block: Blocks In Python. (line 6)
-* gdb.block_for_pc: Blocks In Python. (line 16)
-* gdb.BP_ACCESS_WATCHPOINT: Breakpoints In Python.
- (line 131)
-* gdb.BP_BREAKPOINT: Breakpoints In Python.
- (line 119)
-* gdb.BP_HARDWARE_WATCHPOINT: Breakpoints In Python.
- (line 125)
-* gdb.BP_READ_WATCHPOINT: Breakpoints In Python.
- (line 128)
-* gdb.BP_WATCHPOINT: Breakpoints In Python.
- (line 122)
-* gdb.Breakpoint: Breakpoints In Python.
- (line 6)
-* gdb.breakpoints: Basic Python. (line 31)
-* gdb.COMMAND_BREAKPOINTS: Commands In Python. (line 145)
-* gdb.COMMAND_DATA: Commands In Python. (line 115)
-* gdb.COMMAND_FILES: Commands In Python. (line 126)
-* gdb.COMMAND_MAINTENANCE: Commands In Python. (line 163)
-* gdb.COMMAND_NONE: Commands In Python. (line 105)
-* gdb.COMMAND_OBSCURE: Commands In Python. (line 157)
-* gdb.COMMAND_RUNNING: Commands In Python. (line 109)
-* gdb.COMMAND_STACK: Commands In Python. (line 120)
-* gdb.COMMAND_STATUS: Commands In Python. (line 139)
-* gdb.COMMAND_SUPPORT: Commands In Python. (line 132)
-* gdb.COMMAND_TRACEPOINTS: Commands In Python. (line 151)
-* gdb.COMPLETE_COMMAND: Commands In Python. (line 184)
-* gdb.COMPLETE_FILENAME: Commands In Python. (line 177)
-* gdb.COMPLETE_LOCATION: Commands In Python. (line 180)
-* gdb.COMPLETE_NONE: Commands In Python. (line 174)
-* gdb.COMPLETE_SYMBOL: Commands In Python. (line 188)
-* gdb.current_objfile: Objfiles In Python. (line 15)
-* gdb.current_progspace: Progspaces In Python.
- (line 14)
-* gdb.decode_line: Basic Python. (line 157)
-* gdb.default_visualizer: Pretty Printing API. (line 85)
-* gdb.error: Exception Handling. (line 22)
-* gdb.execute: Basic Python. (line 14)
-* gdb.flush: Basic Python. (line 121)
-* gdb.Function: Functions In Python. (line 6)
-* gdb.GdbError: Exception Handling. (line 42)
-* gdb.history: Basic Python. (line 46)
-* gdb.Inferior: Inferiors In Python. (line 6)
-* gdb.InferiorThread: Threads In Python. (line 6)
-* gdb.ini: Startup. (line 60)
-* gdb.LazyString: Lazy Strings In Python.
- (line 6)
-* gdb.lookup_global_symbol: Symbols In Python. (line 33)
-* gdb.lookup_symbol: Symbols In Python. (line 13)
-* gdb.lookup_type: Types In Python. (line 11)
-* gdb.MemoryError: Exception Handling. (line 30)
-* gdb.newest_frame: Frames In Python. (line 26)
-* gdb.Objfile: Objfiles In Python. (line 6)
-* gdb.objfiles: Objfiles In Python. (line 21)
-* gdb.PARAM_AUTO_BOOLEAN: Parameters In Python.
- (line 93)
-* gdb.PARAM_BOOLEAN: Parameters In Python.
- (line 89)
-* gdb.PARAM_ENUM: Parameters In Python.
- (line 127)
-* gdb.PARAM_FILENAME: Parameters In Python.
- (line 119)
-* gdb.PARAM_INTEGER: Parameters In Python.
- (line 102)
-* gdb.PARAM_OPTIONAL_FILENAME: Parameters In Python.
- (line 116)
-* gdb.PARAM_STRING: Parameters In Python.
- (line 106)
-* gdb.PARAM_STRING_NOESCAPE: Parameters In Python.
- (line 112)
-* gdb.PARAM_UINTEGER: Parameters In Python.
- (line 98)
-* gdb.PARAM_ZINTEGER: Parameters In Python.
- (line 123)
-* gdb.parameter: Basic Python. (line 35)
-* gdb.Parameter: Parameters In Python.
- (line 6)
-* gdb.parse_and_eval: Basic Python. (line 58)
-* gdb.post_event: Basic Python. (line 69)
-* gdb.printing: gdb.printing. (line 6)
-* gdb.Progspace: Progspaces In Python.
- (line 6)
-* gdb.progspaces: Progspaces In Python.
- (line 18)
-* gdb.PYTHONDIR: Basic Python. (line 11)
-* gdb.read_memory: Inferiors In Python. (line 44)
-* gdb.search_memory: Inferiors In Python. (line 57)
-* gdb.selected_frame: Frames In Python. (line 22)
-* gdb.selected_thread: Threads In Python. (line 13)
-* gdb.solib_name: Basic Python. (line 153)
-* gdb.STDERR: Basic Python. (line 111)
-* gdb.STDLOG: Basic Python. (line 135)
-* gdb.STDOUT: Basic Python. (line 129)
-* gdb.string_to_argv: Commands In Python. (line 62)
-* gdb.Symbol: Symbols In Python. (line 6)
-* gdb.SYMBOL_FUNCTIONS_DOMAIN: Symbols In Python. (line 117)
-* gdb.SYMBOL_LABEL_DOMAIN: Symbols In Python. (line 110)
-* gdb.SYMBOL_LOC_ARG: Symbols In Python. (line 139)
-* gdb.SYMBOL_LOC_BLOCK: Symbols In Python. (line 160)
-* gdb.SYMBOL_LOC_COMPUTED: Symbols In Python. (line 174)
-* gdb.SYMBOL_LOC_CONST: Symbols In Python. (line 130)
-* gdb.SYMBOL_LOC_CONST_BYTES: Symbols In Python. (line 163)
-* gdb.SYMBOL_LOC_LOCAL: Symbols In Python. (line 153)
-* gdb.SYMBOL_LOC_OPTIMIZED_OUT: Symbols In Python. (line 171)
-* gdb.SYMBOL_LOC_REF_ARG: Symbols In Python. (line 143)
-* gdb.SYMBOL_LOC_REGISTER: Symbols In Python. (line 136)
-* gdb.SYMBOL_LOC_REGPARM_ADDR: Symbols In Python. (line 148)
-* gdb.SYMBOL_LOC_STATIC: Symbols In Python. (line 133)
-* gdb.SYMBOL_LOC_TYPEDEF: Symbols In Python. (line 156)
-* gdb.SYMBOL_LOC_UNDEF: Symbols In Python. (line 128)
-* gdb.SYMBOL_LOC_UNRESOLVED: Symbols In Python. (line 166)
-* gdb.SYMBOL_STRUCT_DOMAIN: Symbols In Python. (line 107)
-* gdb.SYMBOL_TYPES_DOMAIN: Symbols In Python. (line 120)
-* gdb.SYMBOL_UNDEF_DOMAIN: Symbols In Python. (line 100)
-* gdb.SYMBOL_VAR_DOMAIN: Symbols In Python. (line 103)
-* gdb.SYMBOL_VARIABLES_DOMAIN: Symbols In Python. (line 113)
-* gdb.Symtab: Symbol Tables In Python.
- (line 6)
-* gdb.Symtab_and_line: Symbol Tables In Python.
- (line 6)
-* gdb.target_charset: Basic Python. (line 142)
-* gdb.target_wide_charset: Basic Python. (line 147)
-* gdb.Type: Types In Python. (line 6)
-* gdb.TYPE_CODE_ARRAY: Types In Python. (line 155)
-* gdb.TYPE_CODE_BITSTRING: Types In Python. (line 193)
-* gdb.TYPE_CODE_BOOL: Types In Python. (line 214)
-* gdb.TYPE_CODE_CHAR: Types In Python. (line 211)
-* gdb.TYPE_CODE_COMPLEX: Types In Python. (line 217)
-* gdb.TYPE_CODE_DECFLOAT: Types In Python. (line 226)
-* gdb.TYPE_CODE_ENUM: Types In Python. (line 164)
-* gdb.TYPE_CODE_ERROR: Types In Python. (line 196)
-* gdb.TYPE_CODE_FLAGS: Types In Python. (line 167)
-* gdb.TYPE_CODE_FLT: Types In Python. (line 176)
-* gdb.TYPE_CODE_FUNC: Types In Python. (line 170)
-* gdb.TYPE_CODE_INT: Types In Python. (line 173)
-* gdb.TYPE_CODE_INTERNAL_FUNCTION: Types In Python. (line 229)
-* gdb.TYPE_CODE_MEMBERPTR: Types In Python. (line 205)
-* gdb.TYPE_CODE_METHOD: Types In Python. (line 199)
-* gdb.TYPE_CODE_METHODPTR: Types In Python. (line 202)
-* gdb.TYPE_CODE_NAMESPACE: Types In Python. (line 223)
-* gdb.TYPE_CODE_PTR: Types In Python. (line 152)
-* gdb.TYPE_CODE_RANGE: Types In Python. (line 185)
-* gdb.TYPE_CODE_REF: Types In Python. (line 208)
-* gdb.TYPE_CODE_SET: Types In Python. (line 182)
-* gdb.TYPE_CODE_STRING: Types In Python. (line 188)
-* gdb.TYPE_CODE_STRUCT: Types In Python. (line 158)
-* gdb.TYPE_CODE_TYPEDEF: Types In Python. (line 220)
-* gdb.TYPE_CODE_UNION: Types In Python. (line 161)
-* gdb.TYPE_CODE_VOID: Types In Python. (line 179)
-* gdb.types: gdb.types. (line 6)
-* gdb.Value: Values From Inferior.
- (line 6)
-* gdb.WP_ACCESS: Breakpoints In Python.
- (line 58)
-* gdb.WP_READ: Breakpoints In Python.
- (line 52)
-* gdb.WP_WRITE: Breakpoints In Python.
- (line 55)
-* gdb.write: Basic Python. (line 103)
-* gdb.write_memory: Inferiors In Python. (line 50)
-* GDB/MI development: GDB/MI Development and Front Ends.
- (line 6)
-* GDB/MI General Design: GDB/MI General Design.
- (line 6)
-* GDB/MI, async records: GDB/MI Async Records.
- (line 6)
-* GDB/MI, breakpoint commands: GDB/MI Breakpoint Commands.
- (line 6)
-* GDB/MI, compatibility with CLI: GDB/MI Compatibility with CLI.
- (line 6)
-* GDB/MI, data manipulation: GDB/MI Data Manipulation.
- (line 6)
-* GDB/MI, input syntax: GDB/MI Input Syntax. (line 6)
-* GDB/MI, its purpose: GDB/MI. (line 9)
-* GDB/MI, output syntax: GDB/MI Output Syntax.
- (line 6)
-* GDB/MI, result records: GDB/MI Result Records.
- (line 6)
-* GDB/MI, simple examples: GDB/MI Simple Examples.
- (line 6)
-* GDB/MI, stream records: GDB/MI Stream Records.
- (line 6)
-* gdbarch debugging info: Debugging Output. (line 18)
-* GDBHISTFILE, environment variable: Command History. (line 26)
-* gdbserver: Server. (line 6)
-* gdbserver, multiple processes: Server. (line 91)
-* gdbserver, search path for libthread_db: Server. (line 188)
-* GDT: DJGPP Native. (line 24)
-* generate-core-file: Core File Generation.
- (line 18)
-* get thread information block address: General Query Packets.
- (line 143)
-* get thread-local storage address, remote request: General Query Packets.
- (line 112)
-* get_set_string on parameter: Parameters In Python.
- (line 74)
-* get_show_string on parameter: Parameters In Python.
- (line 80)
-* getDebugChar: Bootstrapping. (line 14)
-* gettimeofday, file-i/o system call: gettimeofday. (line 6)
-* global debugging information directory: Separate Debug Files.
- (line 6)
-* GNU C++: C. (line 10)
-* GNU Emacs: Emacs. (line 6)
-* GNU Hurd debugging: Hurd Native. (line 6)
-* GNU/Hurd debug messages: Debugging Output. (line 83)
-* GNU/Linux LWP async debug messages: Debugging Output. (line 111)
-* GNU/Linux LWP debug messages: Debugging Output. (line 104)
-* gnu_debuglink_crc32: Separate Debug Files.
- (line 164)
-* h (help): Help. (line 9)
-* H packet: Packets. (line 191)
-* handle: Signals. (line 45)
-* handle_exception: Stub Contents. (line 15)
-* handling signals: Signals. (line 27)
-* hardware breakpoints: Set Breaks. (line 62)
-* hardware debug registers: Maintenance Commands.
- (line 307)
-* hardware watchpoints: Set Watchpoints. (line 31)
-* hash mark while downloading: Target Commands. (line 99)
-* hbreak: Set Breaks. (line 62)
-* help: Help. (line 6)
-* help function: Convenience Vars. (line 112)
-* help target: Target Commands. (line 19)
-* help user-defined: Define. (line 66)
-* heuristic-fence-post (Alpha, MIPS): MIPS. (line 14)
-* history: Basic Python. (line 47)
-* history events: Event Designators. (line 7)
-* history expansion: History Interaction. (line 6)
-* history expansion, turn on/off: Command History. (line 53)
-* history file: Command History. (line 26)
-* history number: Value History. (line 13)
-* history of values printed by GDB: Value History. (line 6)
-* history size: Command History. (line 45)
-* history substitution: Command History. (line 26)
-* history-preserve-point: Readline Init File Syntax.
- (line 93)
-* history-search-backward (): Commands For History.
- (line 50)
-* history-search-forward (): Commands For History.
- (line 45)
-* HISTSIZE, environment variable: Command History. (line 45)
-* hit_count: Breakpoints In Python.
- (line 135)
-* hook: Hooks. (line 6)
-* hookpost: Hooks. (line 11)
-* hooks, for commands: Hooks. (line 6)
-* hooks, post-command: Hooks. (line 11)
-* hooks, pre-command: Hooks. (line 6)
-* horizontal-scroll-mode: Readline Init File Syntax.
- (line 98)
-* host character set: Character Sets. (line 6)
-* Host I/O, remote protocol: Host I/O Packets. (line 6)
-* how many arguments (user-defined commands): Define. (line 25)
-* HPPA support: HPPA. (line 6)
-* htrace: OpenRISC 1000. (line 69)
-* hwatch: OpenRISC 1000. (line 59)
-* i (info): Help. (line 99)
-* i packet: Packets. (line 205)
-* I packet: Packets. (line 210)
-* i/o: Input/Output. (line 6)
-* I/O registers (Atmel AVR): AVR. (line 10)
-* i386: Remote Stub. (line 57)
-* i386-stub.c: Remote Stub. (line 57)
-* IDT: DJGPP Native. (line 24)
-* if: Command Files. (line 75)
-* ignore: Conditions. (line 77)
-* ignore count (of breakpoint): Conditions. (line 66)
-* ignore_count: Breakpoints In Python.
- (line 98)
-* INCLUDE_RDB: VxWorks. (line 33)
-* incomplete type: Symbols. (line 107)
-* indentation in structure display: Print Settings. (line 198)
-* index files: Index Files. (line 6)
-* inferior: Inferiors and Programs.
- (line 13)
-* inferior debugging info: Debugging Output. (line 89)
-* inferior events in Python: Events In Python. (line 6)
-* inferior functions, calling: Calling. (line 6)
-* inferior INFNO: Inferiors and Programs.
- (line 49)
-* inferior tty: Input/Output. (line 44)
-* inferior_thread: Events In Python. (line 57)
-* inferiors: Inferiors In Python. (line 15)
-* inferiors in Python: Inferiors In Python. (line 6)
-* infinite recursion in user-defined commands: Define. (line 76)
-* info: Help. (line 99)
-* info address: Symbols. (line 44)
-* info all-registers: Registers. (line 15)
-* info args: Frame Info. (line 51)
-* info auto-load-scripts: Auto-loading. (line 29)
-* info auxv: OS Information. (line 33)
-* info breakpoints: Set Breaks. (line 128)
-* info catch: Frame Info. (line 60)
-* info checkpoints: Checkpoint/Restart. (line 31)
-* info classes: Symbols. (line 205)
-* info common: Special Fortran Commands.
- (line 9)
-* info copying: Help. (line 136)
-* info dcache: Caching Remote Data. (line 34)
-* info display: Auto Display. (line 78)
-* info dll: Cygwin Native. (line 35)
-* info dos: DJGPP Native. (line 15)
-* info extensions: Show. (line 34)
-* info f (info frame): Frame Info. (line 17)
-* info files: Files. (line 191)
-* info float: Floating Point Hardware.
- (line 9)
-* info for known .debug_gdb_scripts-loaded scripts: Maintenance Commands.
- (line 216)
-* info for known object files: Maintenance Commands.
- (line 211)
-* info frame: Frame Info. (line 17)
-* info frame, show the source language: Show. (line 15)
-* info functions: Symbols. (line 184)
-* info handle: Signals. (line 33)
-* info inferiors: Inferiors and Programs.
- (line 25)
-* info io_registers, AVR: AVR. (line 10)
-* info line: Machine Code. (line 14)
-* info line, and Objective-C: Method Names in Commands.
- (line 9)
-* info locals: Frame Info. (line 55)
-* info macro: Macros. (line 47)
-* info mem: Memory Region Attributes.
- (line 45)
-* info meminfo: SVR4 Process Information.
- (line 78)
-* info or1k spr: OpenRISC 1000. (line 20)
-* info os: OS Information. (line 47)
-* info os processes: OS Information. (line 52)
-* info pidlist: SVR4 Process Information.
- (line 74)
-* info pretty-printer: Pretty-Printer Commands.
- (line 6)
-* info proc: SVR4 Process Information.
- (line 16)
-* info program: Stopping. (line 18)
-* info record: Process Record and Replay.
- (line 137)
-* info registers: Registers. (line 11)
-* info scope: Symbols. (line 138)
-* info selectors: Symbols. (line 211)
-* info serial: DJGPP Native. (line 142)
-* info set: Help. (line 119)
-* info share: Files. (line 326)
-* info sharedlibrary: Files. (line 326)
-* info signals: Signals. (line 33)
-* info source: Symbols. (line 159)
-* info source, show the source language: Show. (line 21)
-* info sources: Symbols. (line 178)
-* info spu: SPU. (line 10)
-* info stack: Backtrace. (line 34)
-* info static-tracepoint-markers: Listing Static Tracepoint Markers.
- (line 6)
-* info symbol: Symbols. (line 54)
-* info target: Files. (line 191)
-* info task TASKNO: Ada Tasks. (line 89)
-* info tasks: Ada Tasks. (line 9)
-* info terminal: Input/Output. (line 12)
-* info threads: Threads. (line 66)
-* info tp [N...]: Listing Tracepoints. (line 6)
-* info tracepoints [N...]: Listing Tracepoints. (line 6)
-* info tvariables: Trace State Variables.
- (line 37)
-* info types: Symbols. (line 124)
-* info udot: OS Information. (line 16)
-* info variables: Symbols. (line 196)
-* info vector: Vector Unit. (line 9)
-* info w32: Cygwin Native. (line 19)
-* info warranty: Help. (line 140)
-* info watchpoints [N...]: Set Watchpoints. (line 72)
-* info win: TUI Commands. (line 18)
-* information about static tracepoint markers: Listing Static Tracepoint Markers.
- (line 6)
-* information about tracepoints: Listing Tracepoints. (line 6)
-* inheritance: Debugging C Plus Plus.
- (line 25)
-* init file: Startup. (line 11)
-* init file name: Startup. (line 60)
-* init-if-undefined: Convenience Vars. (line 41)
-* initial frame: Frames. (line 12)
-* initialization file, readline: Readline Init File. (line 6)
-* inline functions, debugging: Inline Functions. (line 6)
-* innermost frame: Frames. (line 12)
-* input syntax for GDB/MI: GDB/MI Input Syntax. (line 6)
-* input-meta: Readline Init File Syntax.
- (line 105)
-* insert-comment (M-#): Miscellaneous Commands.
- (line 51)
-* insert-completions (M-*): Commands For Completion.
- (line 14)
-* inspect: Data. (line 6)
-* installation: Installing GDB. (line 6)
-* instructions, assembly: Machine Code. (line 36)
-* integral datatypes, in file-i/o protocol: Integral Datatypes.
- (line 6)
-* Intel: Remote Stub. (line 57)
-* Intel disassembly flavor: Machine Code. (line 127)
-* interaction, readline: Readline Interaction.
- (line 6)
-* internal commands: Maintenance Commands.
- (line 6)
-* internal errors, control of GDB behavior: Maintenance Commands.
- (line 124)
-* internal GDB breakpoints: Set Breaks. (line 333)
-* interpreter-exec: Interpreters. (line 43)
-* interrupt <1>: Quitting GDB. (line 13)
-* interrupt: Background Execution.
- (line 73)
-* interrupt debuggee on MS-Windows: Cygwin Native. (line 9)
-* interrupt remote programs: Remote Configuration.
- (line 85)
-* interrupting remote programs: Connecting. (line 78)
-* interrupting remote targets: Bootstrapping. (line 25)
-* interrupts (remote protocol): Interrupts. (line 6)
-* invalid input: Bug Criteria. (line 16)
-* invoke another interpreter: Interpreters. (line 37)
-* invoke on Command: Commands In Python. (line 50)
-* invoke on Function: Functions In Python. (line 21)
-* is_argument: Symbols In Python. (line 77)
-* is_constant: Symbols In Python. (line 80)
-* is_exited on InferiorThread: Threads In Python. (line 61)
-* is_function: Symbols In Python. (line 83)
-* is_optimized_out: Values From Inferior.
- (line 50)
-* is_running on InferiorThread: Threads In Python. (line 58)
-* is_stopped on InferiorThread: Threads In Python. (line 55)
-* is_valid on Block: Blocks In Python. (line 24)
-* is_valid on Breakpoint: Breakpoints In Python.
- (line 62)
-* is_valid on Frame: Frames In Python. (line 37)
-* is_valid on Inferior: Inferiors In Python. (line 33)
-* is_valid on InferiorThread: Threads In Python. (line 43)
-* is_valid on Objfile: Objfiles In Python. (line 42)
-* is_valid on Symbol: Symbols In Python. (line 91)
-* is_valid on Symtab: Symbol Tables In Python.
- (line 51)
-* is_valid on Symtab_and_line: Symbol Tables In Python.
- (line 31)
-* is_variable: Symbols In Python. (line 86)
-* isatty, file-i/o system call: isatty. (line 6)
-* isearch-terminators: Readline Init File Syntax.
- (line 112)
-* JIT compilation interface: JIT Interface. (line 6)
-* jump: Jumping. (line 10)
-* jump, and Objective-C: Method Names in Commands.
- (line 9)
-* just-in-time compilation: JIT Interface. (line 6)
-* just-in-time compilation, debugging messages: Debugging Output.
- (line 98)
-* k packet: Packets. (line 214)
-* kernel crash dump: BSD libkvm Interface.
- (line 6)
-* kernel memory image: BSD libkvm Interface.
- (line 6)
-* KeyboardInterrupt: Exception Handling. (line 34)
-* keymap: Readline Init File Syntax.
- (line 119)
-* kill: Kill Process. (line 6)
-* kill inferiors INFNO...: Inferiors and Programs.
- (line 103)
-* kill ring: Readline Killing Commands.
- (line 19)
-* kill-line (C-k): Commands For Killing.
- (line 6)
-* kill-region (): Commands For Killing.
- (line 41)
-* kill-whole-line (): Commands For Killing.
- (line 15)
-* kill-word (M-d): Commands For Killing.
- (line 19)
-* killing text: Readline Killing Commands.
- (line 6)
-* kvm: BSD libkvm Interface.
- (line 24)
-* l (list): List. (line 6)
-* languages: Languages. (line 6)
-* last tracepoint number: Create and Delete Tracepoints.
- (line 98)
-* latest breakpoint: Set Breaks. (line 6)
-* layout: TUI Commands. (line 21)
-* lazy strings in python: Lazy Strings In Python.
- (line 6)
-* lazy_string on Value: Values From Inferior.
- (line 172)
-* LDT: DJGPP Native. (line 24)
-* leaving GDB: Quitting GDB. (line 6)
-* Left: TUI Keys. (line 59)
-* length: Lazy Strings In Python.
- (line 31)
-* libkvm: BSD libkvm Interface.
- (line 6)
-* library list format, remote protocol: Library List Format. (line 6)
-* limit hardware breakpoints and watchpoints: Remote Configuration.
- (line 72)
-* limit on number of printed array elements: Print Settings. (line 123)
-* limits, in file-i/o protocol: Limits. (line 6)
-* line: Symbol Tables In Python.
- (line 25)
-* linespec: Specify Location. (line 6)
-* linkage_name: Symbols In Python. (line 62)
-* Linux lightweight processes: Debugging Output. (line 111)
-* list: List. (line 6)
-* list active threads, remote request: General Query Packets.
- (line 84)
-* list of supported file-i/o calls: List of Supported Calls.
- (line 6)
-* list output in GDB/MI: GDB/MI Output Syntax.
- (line 117)
-* list, and Objective-C: Method Names in Commands.
- (line 9)
-* list, how many lines to display: List. (line 30)
-* listing GDB's internal symbol tables: Symbols. (line 291)
-* listing machine instructions: Machine Code. (line 36)
-* listing mapped overlays: Overlay Commands. (line 60)
-* load address, overlay's: How Overlays Work. (line 6)
-* load FILENAME: Target Commands. (line 115)
-* load shared library: Files. (line 323)
-* load symbols from memory: Files. (line 162)
-* local variables: Symbols. (line 138)
-* locate address: Output Formats. (line 35)
-* location: Breakpoints In Python.
- (line 140)
-* lock scheduler: All-Stop Mode. (line 37)
-* log output in GDB/MI: GDB/MI Output Syntax.
- (line 113)
-* logging file name: Logging Output. (line 13)
-* logging GDB output: Logging Output. (line 6)
-* lookup_global_symbol: Symbols In Python. (line 34)
-* lookup_symbol: Symbols In Python. (line 14)
-* lookup_type: Types In Python. (line 12)
-* loop_break: Command Files. (line 94)
-* loop_continue: Command Files. (line 98)
-* lseek flags, in file-i/o protocol: Lseek Flags. (line 6)
-* lseek, file-i/o system call: lseek. (line 6)
-* M packet: Packets. (line 241)
-* m packet: Packets. (line 221)
-* M32-EVA target board address: M32R/D. (line 21)
-* M32R/Chaos debugging: M32R/D. (line 50)
-* m680x0: Remote Stub. (line 60)
-* m68k-stub.c: Remote Stub. (line 60)
-* machine instructions: Machine Code. (line 36)
-* macro define: Macros. (line 52)
-* macro definition, showing: Macros. (line 47)
-* macro exp1: Macros. (line 36)
-* macro expand: Macros. (line 29)
-* macro expansion, showing the results of preprocessor: Macros.
- (line 29)
-* macro list: Macros. (line 73)
-* macro undef: Macros. (line 67)
-* macros, example of debugging with: Macros. (line 76)
-* macros, user-defined: Macros. (line 52)
-* mailing lists: GDB/MI Development and Front Ends.
- (line 35)
-* maint agent: Maintenance Commands.
- (line 12)
-* maint agent-eval: Maintenance Commands.
- (line 12)
-* maint check-symtabs: Maintenance Commands.
- (line 78)
-* maint cplus first_component: Maintenance Commands.
- (line 81)
-* maint cplus namespace: Maintenance Commands.
- (line 84)
-* maint demangle: Maintenance Commands.
- (line 87)
-* maint deprecate: Maintenance Commands.
- (line 90)
-* maint dump-me: Maintenance Commands.
- (line 98)
-* maint info breakpoints: Maintenance Commands.
- (line 25)
-* maint info program-spaces: Inferiors and Programs.
- (line 138)
-* maint info psymtabs: Symbols. (line 291)
-* maint info sections: Files. (line 200)
-* maint info sol-threads: Threads. (line 98)
-* maint info symtabs: Symbols. (line 291)
-* maint internal-error: Maintenance Commands.
- (line 103)
-* maint internal-warning: Maintenance Commands.
- (line 103)
-* maint packet: Maintenance Commands.
- (line 143)
-* maint print architecture: Maintenance Commands.
- (line 149)
-* maint print c-tdesc: Maintenance Commands.
- (line 153)
-* maint print cooked-registers: Maintenance Commands.
- (line 176)
-* maint print dummy-frames: Maintenance Commands.
- (line 158)
-* maint print objfiles: Maintenance Commands.
- (line 211)
-* maint print psymbols: Symbols. (line 272)
-* maint print raw-registers: Maintenance Commands.
- (line 176)
-* maint print reggroups: Maintenance Commands.
- (line 192)
-* maint print register-groups: Maintenance Commands.
- (line 176)
-* maint print registers: Maintenance Commands.
- (line 176)
-* maint print section-scripts: Maintenance Commands.
- (line 216)
-* maint print statistics: Maintenance Commands.
- (line 223)
-* maint print symbols: Symbols. (line 272)
-* maint print target-stack: Maintenance Commands.
- (line 236)
-* maint print type: Maintenance Commands.
- (line 248)
-* maint print unwind, HPPA: HPPA. (line 17)
-* maint set dwarf2 always-disassemble: Maintenance Commands.
- (line 255)
-* maint set dwarf2 max-cache-age: Maintenance Commands.
- (line 277)
-* maint set internal-error: Maintenance Commands.
- (line 124)
-* maint set internal-warning: Maintenance Commands.
- (line 124)
-* maint set profile: Maintenance Commands.
- (line 291)
-* maint set python print-stack: Python Commands. (line 31)
-* maint set show-all-tib: Maintenance Commands.
- (line 315)
-* maint set show-debug-regs: Maintenance Commands.
- (line 307)
-* maint show dwarf2 always-disassemble: Maintenance Commands.
- (line 255)
-* maint show dwarf2 max-cache-age: Maintenance Commands.
- (line 277)
-* maint show internal-error: Maintenance Commands.
- (line 124)
-* maint show internal-warning: Maintenance Commands.
- (line 124)
-* maint show profile: Maintenance Commands.
- (line 291)
-* maint show show-all-tib: Maintenance Commands.
- (line 315)
-* maint show show-debug-regs: Maintenance Commands.
- (line 307)
-* maint space: Maintenance Commands.
- (line 321)
-* maint time: Maintenance Commands.
- (line 328)
-* maint translate-address: Maintenance Commands.
- (line 339)
-* maint undeprecate: Maintenance Commands.
- (line 90)
-* maintenance commands: Maintenance Commands.
- (line 6)
-* make: Shell Commands. (line 19)
-* manual overlay debugging: Overlay Commands. (line 23)
-* map an overlay: Overlay Commands. (line 30)
-* mapinfo list, QNX Neutrino: SVR4 Process Information.
- (line 78)
-* mapped address: How Overlays Work. (line 6)
-* mapped overlays: How Overlays Work. (line 6)
-* mark-modified-lines: Readline Init File Syntax.
- (line 132)
-* mark-symlinked-directories: Readline Init File Syntax.
- (line 137)
-* markers, static tracepoints: Set Tracepoints. (line 28)
-* match-hidden-files: Readline Init File Syntax.
- (line 142)
-* maximum value for offset of closest symbol: Print Settings. (line 70)
-* may-insert-breakpoints: Observer Mode. (line 50)
-* may-insert-fast-tracepoints: Observer Mode. (line 69)
-* may-insert-tracepoints: Observer Mode. (line 59)
-* may-interrupt: Observer Mode. (line 79)
-* may-write-memory: Observer Mode. (line 41)
-* may-write-registers: Observer Mode. (line 32)
-* mem: Memory Region Attributes.
- (line 22)
-* member functions: C Plus Plus Expressions.
- (line 18)
-* memory address space mappings: SVR4 Process Information.
- (line 32)
-* memory map format: Memory Map Format. (line 6)
-* memory region attributes: Memory Region Attributes.
- (line 6)
-* memory tracing: Breakpoints. (line 20)
-* memory transfer, in file-i/o protocol: Memory Transfer. (line 6)
-* memory used by commands: Maintenance Commands.
- (line 321)
-* memory used for symbol tables: Files. (line 311)
-* memory, alignment and size of remote accesses: Packets. (line 228)
-* memory, viewing as typed object: Expressions. (line 43)
-* memset: Bootstrapping. (line 70)
-* menu-complete (): Commands For Completion.
- (line 18)
-* meta-flag: Readline Init File Syntax.
- (line 105)
-* mi interpreter: Interpreters. (line 26)
-* mi1 interpreter: Interpreters. (line 34)
-* mi2 interpreter: Interpreters. (line 31)
-* minimal language: Unsupported Languages.
- (line 6)
-* Minimal symbols and DLLs: Non-debug DLL Symbols.
- (line 6)
-* MIPS addresses, masking: MIPS. (line 61)
-* MIPS boards: MIPS Embedded. (line 6)
-* MIPS remote floating point: MIPS Embedded. (line 60)
-* MIPS stack: MIPS. (line 6)
-* miscellaneous settings: Other Misc Settings. (line 6)
-* MMX registers (x86): Registers. (line 71)
-* mode_t values, in file-i/o protocol: mode_t Values. (line 6)
-* Modula-2: Summary. (line 29)
-* Modula-2 built-ins: Built-In Func/Proc. (line 6)
-* Modula-2 checks: M2 Checks. (line 6)
-* Modula-2 constants: Built-In Func/Proc. (line 112)
-* Modula-2 defaults: M2 Defaults. (line 6)
-* Modula-2 operators: M2 Operators. (line 6)
-* Modula-2 types: M2 Types. (line 6)
-* Modula-2, deviations from: Deviations. (line 6)
-* Modula-2, GDB support: Modula-2. (line 6)
-* monitor: Connecting. (line 105)
-* monitor commands, for gdbserver: Server. (line 171)
-* Motorola 680x0: Remote Stub. (line 60)
-* MS Windows debugging: Cygwin Native. (line 6)
-* MS-DOS system info: DJGPP Native. (line 19)
-* MS-DOS-specific commands: DJGPP Native. (line 6)
-* multiple locations, breakpoints: Set Breaks. (line 190)
-* multiple processes: Forks. (line 6)
-* multiple processes with gdbserver: Server. (line 91)
-* multiple targets: Active Targets. (line 6)
-* multiple threads: Threads. (line 6)
-* multiple threads, backtrace: Backtrace. (line 37)
-* multiple-symbols menu: Ambiguous Expressions.
- (line 51)
-* multiprocess extensions, in remote protocol: General Query Packets.
- (line 527)
-* n (next): Continuing and Stepping.
- (line 78)
-* n (SingleKey TUI key): TUI Single Key Mode. (line 19)
-* name <1>: Threads In Python. (line 20)
-* name: Symbols In Python. (line 58)
-* name a thread: Threads. (line 131)
-* name on Frame: Frames In Python. (line 44)
-* names of symbols: Symbols. (line 14)
-* namespace in C++: C Plus Plus Expressions.
- (line 22)
-* native Cygwin debugging: Cygwin Native. (line 6)
-* native DJGPP debugging: DJGPP Native. (line 6)
-* negative breakpoint numbers: Set Breaks. (line 333)
-* NetROM ROM emulator target: Target Commands. (line 88)
-* New SYSTAG message: Threads. (line 51)
-* newer on Frame: Frames In Python. (line 93)
-* newest_frame: Frames In Python. (line 27)
-* next: Continuing and Stepping.
- (line 78)
-* next&: Background Execution.
- (line 47)
-* next-history (C-n): Commands For History.
- (line 16)
-* nexti: Continuing and Stepping.
- (line 203)
-* nexti&: Background Execution.
- (line 50)
-* ni (nexti): Continuing and Stepping.
- (line 203)
-* non-incremental-forward-search-history (M-n): Commands For History.
- (line 40)
-* non-incremental-reverse-search-history (M-p): Commands For History.
- (line 35)
-* non-member C++ functions, set breakpoint in: Set Breaks. (line 108)
-* non-stop mode: Non-Stop Mode. (line 6)
-* non-stop mode, and breakpoint always-inserted: Set Breaks. (line 326)
-* non-stop mode, and process record and replay: Process Record and Replay.
- (line 52)
-* non-stop mode, and set displaced-stepping: Maintenance Commands.
- (line 73)
-* non-stop mode, remote request: General Query Packets.
- (line 220)
-* noninvasive task options: Hurd Native. (line 73)
-* nosharedlibrary: Files. (line 341)
-* notation, readline: Readline Bare Essentials.
- (line 6)
-* notational conventions, for GDB/MI: GDB/MI. (line 25)
-* notification packets: Notification Packets.
- (line 6)
-* notify output in GDB/MI: GDB/MI Output Syntax.
- (line 102)
-* NULL elements in arrays: Print Settings. (line 189)
-* num <1>: Threads In Python. (line 30)
-* num: Inferiors In Python. (line 20)
-* number: Breakpoints In Python.
- (line 102)
-* number of array elements to print: Print Settings. (line 123)
-* number representation: Numbers. (line 6)
-* numbers for breakpoints: Breakpoints. (line 41)
-* object files, relocatable, reading symbols from: Files. (line 132)
-* Objective-C: Objective-C. (line 6)
-* Objective-C, classes and selectors: Symbols. (line 205)
-* Objective-C, print objects: The Print Command with Objective-C.
- (line 6)
-* objfile: Symbol Tables In Python.
- (line 45)
-* Objfile: Objfiles In Python. (line 6)
-* OBJFILE-gdb.py: objfile-gdb.py file. (line 6)
-* objfiles: Objfiles In Python. (line 22)
-* objfiles in python: Objfiles In Python. (line 6)
-* observer: Observer Mode. (line 22)
-* observer debugging info: Debugging Output. (line 118)
-* octal escapes in strings: Print Settings. (line 222)
-* older on Frame: Frames In Python. (line 90)
-* online documentation: Help. (line 6)
-* opaque data types: Symbols. (line 241)
-* open flags, in file-i/o protocol: Open Flags. (line 6)
-* open, file-i/o system call: open. (line 6)
-* OpenCL C: OpenCL C. (line 6)
-* OpenCL C Datatypes: OpenCL C Datatypes. (line 6)
-* OpenCL C Expressions: OpenCL C Expressions.
- (line 6)
-* OpenCL C Operators: OpenCL C Operators. (line 6)
-* OpenRISC 1000: OpenRISC 1000. (line 6)
-* OpenRISC 1000 htrace: OpenRISC 1000. (line 58)
-* operating system information: Operating System Information.
- (line 6)
-* operating system information, process list: Process list. (line 6)
-* optimized code, debugging: Optimized Code. (line 6)
-* optimized code, wrong values of variables: Variables. (line 58)
-* optimized out value in Python: Values From Inferior.
- (line 49)
-* optimized out, in backtrace: Backtrace. (line 71)
-* optional debugging messages: Debugging Output. (line 6)
-* optional warnings: Messages/Warnings. (line 6)
-* or1k boards: OpenRISC 1000. (line 6)
-* or1ksim: OpenRISC 1000. (line 16)
-* OS ABI: ABI. (line 11)
-* OS information: OS Information. (line 6)
-* out-of-line single-stepping: Maintenance Commands.
- (line 56)
-* outermost frame: Frames. (line 12)
-* output: Output. (line 35)
-* output formats: Output Formats. (line 6)
-* output syntax of GDB/MI: GDB/MI Output Syntax.
- (line 6)
-* output-meta: Readline Init File Syntax.
- (line 149)
-* overlay: Overlay Commands. (line 17)
-* overlay area: How Overlays Work. (line 6)
-* overlay example program: Overlay Sample Program.
- (line 6)
-* overlays: Overlays. (line 6)
-* overlays, setting breakpoints in: Overlay Commands. (line 93)
-* overload-choice annotation: Prompting. (line 32)
-* overloaded functions, calling: C Plus Plus Expressions.
- (line 27)
-* overloaded functions, overload resolution: Debugging C Plus Plus.
- (line 48)
-* overloading in C++: Debugging C Plus Plus.
- (line 15)
-* overwrite-mode (): Commands For Text. (line 53)
-* p packet: Packets. (line 254)
-* P packet: Packets. (line 269)
-* packet acknowledgment, for GDB remote: Packet Acknowledgment.
- (line 6)
-* packet size, remote protocol: General Query Packets.
- (line 458)
-* packets, notification: Notification Packets.
- (line 6)
-* packets, reporting on stdout: Debugging Output. (line 140)
-* packets, tracepoint: Tracepoint Packets. (line 6)
-* page tables display (MS-DOS): DJGPP Native. (line 56)
-* page-completions: Readline Init File Syntax.
- (line 154)
-* PARAM_AUTO_BOOLEAN: Parameters In Python.
- (line 93)
-* PARAM_BOOLEAN: Parameters In Python.
- (line 89)
-* PARAM_ENUM: Parameters In Python.
- (line 127)
-* PARAM_FILENAME: Parameters In Python.
- (line 119)
-* PARAM_INTEGER: Parameters In Python.
- (line 102)
-* PARAM_OPTIONAL_FILENAME: Parameters In Python.
- (line 116)
-* PARAM_STRING: Parameters In Python.
- (line 106)
-* PARAM_STRING_NOESCAPE: Parameters In Python.
- (line 112)
-* PARAM_UINTEGER: Parameters In Python.
- (line 98)
-* PARAM_ZINTEGER: Parameters In Python.
- (line 123)
-* Parameter: Parameters In Python.
- (line 6)
-* parameter: Basic Python. (line 36)
-* parameters in python: Parameters In Python.
- (line 6)
-* parse_and_eval: Basic Python. (line 59)
-* partial symbol dump: Symbols. (line 272)
-* partial symbol tables, listing GDB's internal: Symbols. (line 291)
-* Pascal: Summary. (line 35)
-* Pascal objects, static members display: Print Settings. (line 353)
-* Pascal support in GDB, limitations: Pascal. (line 6)
-* pass signals to inferior, remote request: General Query Packets.
- (line 240)
-* passcount: Tracepoint Passcounts.
- (line 6)
-* patching binaries: Patching. (line 6)
-* patching object files: Files. (line 26)
-* path: Environment. (line 14)
-* pause current task (GNU Hurd): Hurd Native. (line 49)
-* pause current thread (GNU Hurd): Hurd Native. (line 91)
-* pauses in output: Screen Size. (line 6)
-* pc: Symbol Tables In Python.
- (line 21)
-* pc on Frame: Frames In Python. (line 80)
-* pending breakpoints: Set Breaks. (line 232)
-* PgDn: TUI Keys. (line 50)
-* PgUp: TUI Keys. (line 47)
-* physical address from linear address: DJGPP Native. (line 81)
-* physname: Debugging Output. (line 35)
-* pid: Inferiors In Python. (line 23)
-* pipe, target remote to: Connecting. (line 60)
-* pipes: Starting. (line 62)
-* pmon, MIPS remote: MIPS Embedded. (line 132)
-* po (print-object): The Print Command with Objective-C.
- (line 6)
-* pointer on Type: Types In Python. (line 114)
-* pointer values, in file-i/o protocol: Pointer Values. (line 6)
-* pointer, finding referent: Print Settings. (line 79)
-* port rights, GNU Hurd: Hurd Native. (line 85)
-* port sets, GNU Hurd: Hurd Native. (line 85)
-* possible-completions (M-?): Commands For Completion.
- (line 11)
-* post-commands annotation: Prompting. (line 27)
-* post-overload-choice annotation: Prompting. (line 32)
-* post-prompt annotation: Prompting. (line 24)
-* post-prompt-for-continue annotation: Prompting. (line 40)
-* post-query annotation: Prompting. (line 36)
-* post_event: Basic Python. (line 70)
-* PowerPC architecture: PowerPC. (line 6)
-* pre-commands annotation: Prompting. (line 27)
-* pre-overload-choice annotation: Prompting. (line 32)
-* pre-prompt annotation: Prompting. (line 24)
-* pre-prompt-for-continue annotation: Prompting. (line 40)
-* pre-query annotation: Prompting. (line 36)
-* prefix for data files: Data Files. (line 6)
-* prefix for shared library file names: Files. (line 374)
-* prefix-meta (<ESC>): Miscellaneous Commands.
- (line 18)
-* premature return from system calls: Interrupted System Calls.
- (line 6)
-* preprocessor macro expansion, showing the results of: Macros.
- (line 29)
-* pretty print arrays: Print Settings. (line 98)
-* pretty print C++ virtual function tables: Print Settings. (line 364)
-* pretty-printer commands: Pretty-Printer Commands.
- (line 6)
-* pretty_printers <1>: Objfiles In Python. (line 32)
-* pretty_printers: Progspaces In Python.
- (line 28)
-* previous-history (C-p): Commands For History.
- (line 12)
-* print: Data. (line 6)
-* print all frame argument values: Print Settings. (line 135)
-* print an Objective-C object description: The Print Command with Objective-C.
- (line 11)
-* print array indexes: Print Settings. (line 108)
-* print frame argument values for scalars only: Print Settings.
- (line 135)
-* print list of auto-loaded scripts: Auto-loading. (line 29)
-* print messages on inferior start and exit: Inferiors and Programs.
- (line 117)
-* print messages on thread start and exit: Threads. (line 156)
-* print messages when symbols are loaded: Symbols. (line 259)
-* print settings: Print Settings. (line 6)
-* print structures in indented form: Print Settings. (line 198)
-* print-object: The Print Command with Objective-C.
- (line 6)
-* print/don't print memory addresses: Print Settings. (line 13)
-* print_name: Symbols In Python. (line 66)
-* printf: Output. (line 46)
-* printing byte arrays: Output Formats. (line 60)
-* printing data: Data. (line 6)
-* printing frame argument values: Print Settings. (line 135)
-* printing strings: Output Formats. (line 60)
-* probe static tracepoint marker: Create and Delete Tracepoints.
- (line 51)
-* probing markers, static tracepoints: Set Tracepoints. (line 28)
-* proc-trace-entry: SVR4 Process Information.
- (line 70)
-* proc-trace-exit: SVR4 Process Information.
- (line 70)
-* proc-untrace-entry: SVR4 Process Information.
- (line 70)
-* proc-untrace-exit: SVR4 Process Information.
- (line 70)
-* process detailed status information: SVR4 Process Information.
- (line 40)
-* process ID: SVR4 Process Information.
- (line 16)
-* process info via /proc: SVR4 Process Information.
- (line 6)
-* process list, QNX Neutrino: SVR4 Process Information.
- (line 74)
-* process record and replay: Process Record and Replay.
- (line 6)
-* process status register: Registers. (line 26)
-* processes, multiple: Forks. (line 6)
-* procfs API calls: SVR4 Process Information.
- (line 53)
-* profiling GDB: Maintenance Commands.
- (line 291)
-* program counter register: Registers. (line 26)
-* program entry point: Backtrace. (line 93)
-* programming in python: Python API. (line 6)
-* Progspace: Progspaces In Python.
- (line 6)
-* progspaces: Progspaces In Python.
- (line 19)
-* progspaces in python: Progspaces In Python.
- (line 6)
-* prompt: Prompt. (line 6)
-* prompt annotation: Prompting. (line 24)
-* prompt-for-continue annotation: Prompting. (line 40)
-* protocol basics, file-i/o: Protocol Basics. (line 6)
-* protocol, GDB remote serial: Overview. (line 14)
-* protocol-specific representation of datatypes, in file-i/o protocol: Protocol-specific Representation of Datatypes.
- (line 6)
-* ptid: Threads In Python. (line 33)
-* ptrace system call: OS Information. (line 9)
-* ptype: Symbols. (line 85)
-* putDebugChar: Bootstrapping. (line 20)
-* pwd: Working Directory. (line 19)
-* python: Python Commands. (line 9)
-* python api: Python API. (line 6)
-* python commands <1>: Commands In Python. (line 6)
-* python commands: Python Commands. (line 6)
-* python convenience functions: Functions In Python. (line 6)
-* python directory: Python. (line 10)
-* python exceptions: Exception Handling. (line 6)
-* python functions: Basic Python. (line 6)
-* python module: Basic Python. (line 6)
-* python modules: Python modules. (line 6)
-* python pagination: Python API. (line 6)
-* python parameters: Parameters In Python.
- (line 6)
-* python scripting: Python. (line 6)
-* python stdout: Python API. (line 6)
-* Python, working with types: Types In Python. (line 6)
-* python, working with values from inferior: Values From Inferior.
- (line 6)
-* PYTHONDIR: Basic Python. (line 12)
-* q (quit): Quitting GDB. (line 6)
-* q (SingleKey TUI key): TUI Single Key Mode. (line 22)
-* q packet: Packets. (line 282)
-* Q packet: Packets. (line 282)
-* QAllow packet: General Query Packets.
- (line 41)
-* qAttached packet: General Query Packets.
- (line 835)
-* qC packet: General Query Packets.
- (line 52)
-* qCRC packet: General Query Packets.
- (line 63)
-* qfThreadInfo packet: General Query Packets.
- (line 84)
-* qGetTIBAddr packet: General Query Packets.
- (line 143)
-* qGetTLSAddr packet: General Query Packets.
- (line 112)
-* QNonStop packet: General Query Packets.
- (line 220)
-* QNX Neutrino: Neutrino. (line 6)
-* qOffsets packet: General Query Packets.
- (line 182)
-* qP packet: General Query Packets.
- (line 209)
-* QPassSignals packet: General Query Packets.
- (line 240)
-* qRcmd packet: General Query Packets.
- (line 268)
-* qSearch:memory packet: General Query Packets.
- (line 293)
-* QStartNoAckMode packet: General Query Packets.
- (line 313)
-* qsThreadInfo packet: General Query Packets.
- (line 84)
-* qSupported packet: General Query Packets.
- (line 328)
-* qSymbol packet: General Query Packets.
- (line 567)
-* QTDPsrc packet: Tracepoint Packets. (line 96)
-* QTDV packet: Tracepoint Packets. (line 127)
-* qThreadExtraInfo packet: General Query Packets.
- (line 612)
-* qTV packet: Tracepoint Packets. (line 276)
-* query annotation: Prompting. (line 36)
-* query attached, remote request: General Query Packets.
- (line 835)
-* quit [EXPRESSION]: Quitting GDB. (line 6)
-* quit annotation: Errors. (line 6)
-* quoted-insert (C-q or C-v): Commands For Text. (line 20)
-* quotes in commands: Completion. (line 57)
-* quoting Ada internal identifiers: Additions to Ada. (line 76)
-* quoting names: Symbols. (line 14)
-* qXfer packet: General Query Packets.
- (line 648)
-* r (run): Starting. (line 6)
-* r (SingleKey TUI key): TUI Single Key Mode. (line 25)
-* r packet: Packets. (line 286)
-* R packet: Packets. (line 291)
-* raise exceptions: Set Catchpoints. (line 197)
-* range checking: Type Checking. (line 65)
-* range on Type: Types In Python. (line 104)
-* ranged breakpoint: PowerPC Embedded. (line 30)
-* ranges of breakpoints: Breakpoints. (line 48)
-* Ravenscar Profile: Ravenscar Profile. (line 6)
-* raw printing: Output Formats. (line 70)
-* rbreak: Set Breaks. (line 92)
-* rc (reverse-continue): Reverse Execution. (line 30)
-* RDI heartbeat: ARM. (line 112)
-* rdilogenable: ARM. (line 95)
-* rdilogfile: ARM. (line 89)
-* re-read-init-file (C-x C-r): Miscellaneous Commands.
- (line 6)
-* read special object, remote request: General Query Packets.
- (line 648)
-* read, file-i/o system call: read. (line 6)
-* read-only sections: Files. (line 258)
-* read_memory on Inferior: Inferiors In Python. (line 45)
-* read_var on Frame: Frames In Python. (line 100)
-* reading symbols from relocatable object files: Files. (line 132)
-* reading symbols immediately: Files. (line 90)
-* readline: Editing. (line 6)
-* readnow: Files. (line 90)
-* rec: Process Record and Replay.
- (line 38)
-* rec del: Process Record and Replay.
- (line 155)
-* rec s: Process Record and Replay.
- (line 57)
-* receive rights, GNU Hurd: Hurd Native. (line 85)
-* recent tracepoint number: Create and Delete Tracepoints.
- (line 98)
-* record: Process Record and Replay.
- (line 38)
-* record aggregates (Ada): Omissions from Ada. (line 44)
-* record delete: Process Record and Replay.
- (line 155)
-* record mode: Process Record and Replay.
- (line 19)
-* record restore: Process Record and Replay.
- (line 85)
-* record save: Process Record and Replay.
- (line 80)
-* record serial communications on file: Remote Configuration.
- (line 57)
-* record stop: Process Record and Replay.
- (line 57)
-* recording a session script: Bug Reporting. (line 104)
-* recording inferior's execution and replaying it: Process Record and Replay.
- (line 6)
-* redirection: Input/Output. (line 6)
-* redraw-current-line (): Commands For Moving. (line 30)
-* reference card: Formatting Documentation.
- (line 6)
-* reference declarations: C Plus Plus Expressions.
- (line 51)
-* reference on Type: Types In Python. (line 110)
-* refresh: TUI Commands. (line 58)
-* register stack, AMD29K: A29K. (line 6)
-* registers: Registers. (line 6)
-* regs, Super-H: Super-H. (line 9)
-* regular expression: Set Breaks. (line 92)
-* reinterpret_cast on Value: Values From Inferior.
- (line 135)
-* reloading symbols: Symbols. (line 217)
-* reloading the overlay table: Overlay Commands. (line 52)
-* relocatable object files, reading symbols from: Files. (line 132)
-* remote connection without stubs: Server. (line 6)
-* remote debugging: Remote Debugging. (line 6)
-* remote delete: File Transfer. (line 23)
-* remote get: File Transfer. (line 19)
-* remote memory comparison: Memory. (line 123)
-* remote monitor prompt: MIPS Embedded. (line 107)
-* remote packets, enabling and disabling: Remote Configuration.
- (line 132)
-* remote programs, interrupting: Connecting. (line 78)
-* remote protocol debugging: Debugging Output. (line 140)
-* remote protocol, binary data: Overview. (line 61)
-* remote protocol, field separator: Overview. (line 53)
-* remote put: File Transfer. (line 15)
-* remote query requests: General Query Packets.
- (line 6)
-* remote serial debugging summary: Debug Session. (line 6)
-* remote serial debugging, overview: Remote Stub. (line 14)
-* remote serial protocol: Overview. (line 14)
-* remote serial stub: Stub Contents. (line 6)
-* remote serial stub list: Remote Stub. (line 54)
-* remote serial stub, initialization: Stub Contents. (line 10)
-* remote serial stub, main routine: Stub Contents. (line 15)
-* remote stub, example: Remote Stub. (line 6)
-* remote stub, support routines: Bootstrapping. (line 6)
-* remote target: Target Commands. (line 58)
-* remote target, file transfer: File Transfer. (line 6)
-* remote target, limit break- and watchpoints: Remote Configuration.
- (line 72)
-* remote timeout: Remote Configuration.
- (line 65)
-* remotetimeout: Sparclet. (line 12)
-* remove actions from a tracepoint: Tracepoint Actions. (line 21)
-* remove-inferiors: Inferiors and Programs.
- (line 86)
-* rename, file-i/o system call: rename. (line 6)
-* Renesas: Remote Stub. (line 63)
-* repeated array elements: Print Settings. (line 176)
-* repeating command sequences: Command Syntax. (line 42)
-* repeating commands: Command Syntax. (line 21)
-* replay log events, remote reply: Stop Reply Packets. (line 61)
-* replay mode: Process Record and Replay.
- (line 10)
-* reporting bugs in GDB: GDB Bugs. (line 6)
-* reprint the last value: Data. (line 23)
-* reset SDI connection, M32R: M32R/D. (line 44)
-* response time, MIPS debugging: MIPS. (line 10)
-* restart: Checkpoint/Restart. (line 6)
-* restart CHECKPOINT-ID: Checkpoint/Restart. (line 44)
-* restore: Dump/Restore Files. (line 41)
-* restore data from a file: Dump/Restore Files. (line 6)
-* result records in GDB/MI: GDB/MI Result Records.
- (line 6)
-* resume threads of multiple processes simultaneously: All-Stop Mode.
- (line 53)
-* resuming execution: Continuing and Stepping.
- (line 6)
-* RET (repeat last command): Command Syntax. (line 21)
-* retransmit-timeout, MIPS protocol: MIPS Embedded. (line 83)
-* return: Returning. (line 6)
-* returning from a function: Returning. (line 6)
-* reverse execution: Reverse Execution. (line 6)
-* reverse-continue: Reverse Execution. (line 30)
-* reverse-finish: Reverse Execution. (line 77)
-* reverse-next: Reverse Execution. (line 60)
-* reverse-nexti: Reverse Execution. (line 69)
-* reverse-search: Search. (line 16)
-* reverse-search-history (C-r): Commands For History.
- (line 26)
-* reverse-step: Reverse Execution. (line 37)
-* reverse-stepi: Reverse Execution. (line 52)
-* revert-line (M-r): Miscellaneous Commands.
- (line 25)
-* rewind program state: Checkpoint/Restart. (line 6)
-* Right: TUI Keys. (line 62)
-* rn (reverse-next): Reverse Execution. (line 60)
-* rni (reverse-nexti): Reverse Execution. (line 69)
-* ROM at zero address, RDI: ARM. (line 102)
-* rs (step): Reverse Execution. (line 37)
-* rsi (reverse-stepi): Reverse Execution. (line 52)
-* run: Starting. (line 6)
-* run to main procedure: Starting. (line 79)
-* run until specified location: Continuing and Stepping.
- (line 118)
-* run&: Background Execution.
- (line 34)
-* running: Starting. (line 6)
-* running and debugging Sparclet programs: Sparclet Execution.
- (line 6)
-* running programs backward: Reverse Execution. (line 6)
-* running VxWorks tasks: VxWorks Attach. (line 6)
-* running, on Sparclet: Sparclet. (line 28)
-* rwatch: Set Watchpoints. (line 64)
-* s (SingleKey TUI key): TUI Single Key Mode. (line 28)
-* s (step): Continuing and Stepping.
- (line 46)
-* S packet: Packets. (line 304)
-* s packet: Packets. (line 298)
-* save breakpoints: Save Breakpoints. (line 9)
-* save breakpoints to a file for future sessions: Save Breakpoints.
- (line 9)
-* save command history: Command History. (line 36)
-* save GDB output to a file: Logging Output. (line 6)
-* save gdb-index: Index Files. (line 19)
-* save tracepoints: save tracepoints. (line 6)
-* save tracepoints for future sessions: save tracepoints. (line 6)
-* save-tracepoints: save tracepoints. (line 6)
-* scheduler locking mode: All-Stop Mode. (line 37)
-* scope: M2 Scope. (line 6)
-* scripting commands: Command Files. (line 6)
-* scripting with python: Python. (line 6)
-* sdireset: M32R/D. (line 44)
-* sdistatus: M32R/D. (line 47)
-* SDS protocol: PowerPC Embedded. (line 80)
-* sds, a command: PowerPC Embedded. (line 91)
-* search: Search. (line 9)
-* search for a thread: Threads. (line 142)
-* search path for libthread_db: Threads. (line 177)
-* search_memory on Inferior: Inferiors In Python. (line 58)
-* searching memory: Searching Memory. (line 6)
-* searching memory, in remote debugging: General Query Packets.
- (line 293)
-* searching source files: Search. (line 6)
-* section: Files. (line 182)
-* section offsets, remote request: General Query Packets.
- (line 182)
-* segment descriptor tables: DJGPP Native. (line 24)
-* select Ctrl-C, BREAK or BREAK-g: Remote Configuration.
- (line 85)
-* select on Frame: Frames In Python. (line 108)
-* select trace snapshot: tfind. (line 6)
-* select-frame: Frames. (line 51)
-* selected frame: Stack. (line 19)
-* selected_frame: Frames In Python. (line 23)
-* selected_thread: Threads In Python. (line 14)
-* selecting frame silently: Frames. (line 51)
-* self-insert (a, b, A, 1, !, ...): Commands For Text. (line 27)
-* send command to remote monitor: Connecting. (line 105)
-* send command to simulator: Embedded Processors. (line 9)
-* send interrupt-sequence on start: Remote Configuration.
- (line 98)
-* send PMON command: MIPS Embedded. (line 132)
-* send rights, GNU Hurd: Hurd Native. (line 85)
-* sending files to remote systems: File Transfer. (line 6)
-* separate debugging information files: Separate Debug Files.
- (line 6)
-* sequence-id, for GDB remote: Overview. (line 29)
-* serial connections, debugging: Debugging Output. (line 140)
-* serial line, target remote: Connecting. (line 18)
-* serial protocol, GDB remote: Overview. (line 14)
-* server prefix: Server Prefix. (line 6)
-* server, command prefix: Command History. (line 20)
-* set: Help. (line 107)
-* set ABI for MIPS: MIPS. (line 32)
-* set ada trust-PAD-over-XVS: Ada Glitches. (line 43)
-* set annotate: Annotations Overview.
- (line 29)
-* set architecture: Targets. (line 21)
-* set args: Arguments. (line 21)
-* set arm: ARM. (line 18)
-* set auto-load-scripts: Auto-loading. (line 23)
-* set auto-solib-add: Files. (line 303)
-* set backtrace: Backtrace. (line 104)
-* set basenames-may-differ: Files. (line 517)
-* set board-address: M32R/D. (line 21)
-* set breakpoint always-inserted: Set Breaks. (line 314)
-* set breakpoint auto-hw: Set Breaks. (line 294)
-* set breakpoint pending: Set Breaks. (line 263)
-* set breakpoints in many functions: Set Breaks. (line 92)
-* set breakpoints on all functions: Set Breaks. (line 112)
-* set can-use-hw-watchpoints: Set Watchpoints. (line 101)
-* set case-sensitive: Symbols. (line 27)
-* set charset: Character Sets. (line 46)
-* set check range: Range Checking. (line 34)
-* set check type: Type Checking. (line 42)
-* set circular-trace-buffer: Starting and Stopping Trace Experiments.
- (line 87)
-* set coerce-float-to-double: ABI. (line 41)
-* set com1base: DJGPP Native. (line 125)
-* set com1irq: DJGPP Native. (line 125)
-* set com2base: DJGPP Native. (line 125)
-* set com2irq: DJGPP Native. (line 125)
-* set com3base: DJGPP Native. (line 125)
-* set com3irq: DJGPP Native. (line 125)
-* set com4base: DJGPP Native. (line 125)
-* set com4irq: DJGPP Native. (line 125)
-* set complaints: Messages/Warnings. (line 29)
-* set confirm: Messages/Warnings. (line 50)
-* set cp-abi: ABI. (line 53)
-* set cygwin-exceptions: Cygwin Native. (line 42)
-* set data-directory: Data Files. (line 12)
-* set dcache line-size: Caching Remote Data. (line 48)
-* set dcache size: Caching Remote Data. (line 45)
-* set debug: Debugging Output. (line 18)
-* set debug darwin: Darwin. (line 9)
-* set debug hppa: HPPA. (line 10)
-* set debug libthread-db: Threads. (line 212)
-* set debug mach-o: Darwin. (line 16)
-* set debug mips: MIPS. (line 81)
-* set debug monitor: Target Commands. (line 108)
-* set debug nto-debug: Neutrino. (line 9)
-* set debug-file-directory: Separate Debug Files.
- (line 68)
-* set debugevents: Cygwin Native. (line 71)
-* set debugexceptions: Cygwin Native. (line 82)
-* set debugexec: Cygwin Native. (line 78)
-* set debugmemory: Cygwin Native. (line 86)
-* set default-collect: Tracepoint Actions. (line 114)
-* set demangle-style: Print Settings. (line 296)
-* set detach-on-fork: Forks. (line 55)
-* set directories: Source Path. (line 120)
-* set disable-randomization: Starting. (line 136)
-* set disassemble-next-line: Machine Code. (line 139)
-* set disassembly-flavor: Machine Code. (line 127)
-* set disconnected-tracing: Starting and Stopping Trace Experiments.
- (line 48)
-* set displaced-stepping: Maintenance Commands.
- (line 56)
-* set download-path: M32R/D. (line 15)
-* set editing: Editing. (line 15)
-* set endian: Byte Order. (line 13)
-* set environment: Environment. (line 39)
-* set exceptions, Hurd command: Hurd Native. (line 40)
-* set exec-direction: Reverse Execution. (line 83)
-* set exec-done-display: Debugging Output. (line 11)
-* set exec-wrapper: Starting. (line 111)
-* set extension-language: Show. (line 30)
-* set fast tracepoint: Create and Delete Tracepoints.
- (line 40)
-* set follow-exec-mode: Forks. (line 101)
-* set follow-fork-mode: Forks. (line 35)
-* set gnutarget: Target Commands. (line 28)
-* set hash, for remote monitors: Target Commands. (line 99)
-* set height: Screen Size. (line 21)
-* set history expansion: Command History. (line 65)
-* set history filename: Command History. (line 26)
-* set history save: Command History. (line 36)
-* set history size: Command History. (line 45)
-* set host-charset: Character Sets. (line 33)
-* set inferior controlling terminal: Input/Output. (line 44)
-* set inferior-tty: Input/Output. (line 49)
-* set input-radix: Numbers. (line 14)
-* set interactive-mode: Other Misc Settings. (line 6)
-* set language: Manually. (line 9)
-* set libthread-db-search-path: Threads. (line 177)
-* set listsize: List. (line 33)
-* set logging: Logging Output. (line 9)
-* set mach-exceptions: Darwin. (line 27)
-* set max-user-call-depth: Define. (line 76)
-* set mem inaccessible-by-default: Memory Region Attributes.
- (line 130)
-* set mips abi: MIPS. (line 32)
-* set mips mask-address: MIPS. (line 61)
-* set mipsfpu: MIPS Embedded. (line 60)
-* set monitor-prompt, MIPS remote: MIPS Embedded. (line 107)
-* set monitor-warnings, MIPS remote: MIPS Embedded. (line 123)
-* set multiple-symbols: Ambiguous Expressions.
- (line 50)
-* set new-console: Cygwin Native. (line 54)
-* set new-group: Cygwin Native. (line 63)
-* set non-stop: Non-Stop Mode. (line 38)
-* set opaque-type-resolution: Symbols. (line 241)
-* set osabi: ABI. (line 11)
-* set output-radix: Numbers. (line 31)
-* set overload-resolution: Debugging C Plus Plus.
- (line 48)
-* set pagination: Screen Size. (line 38)
-* set powerpc: PowerPC Embedded. (line 48)
-* set print: Print Settings. (line 11)
-* set print frame-arguments: Print Settings. (line 135)
-* set print inferior-events: Inferiors and Programs.
- (line 117)
-* set print symbol-loading: Symbols. (line 259)
-* set print thread-events: Threads. (line 156)
-* set processor: Targets. (line 31)
-* set procfs-file: SVR4 Process Information.
- (line 59)
-* set procfs-trace: SVR4 Process Information.
- (line 53)
-* set prompt: Prompt. (line 16)
-* set radix: Numbers. (line 44)
-* set ravenscar task-switching off: Ravenscar Profile. (line 14)
-* set ravenscar task-switching on: Ravenscar Profile. (line 10)
-* set rdiheartbeat: ARM. (line 112)
-* set rdiromatzero: ARM. (line 102)
-* set record insn-number-max: Process Record and Replay.
- (line 89)
-* set record memory-query: Process Record and Replay.
- (line 123)
-* set record stop-at-limit: Process Record and Replay.
- (line 109)
-* set remote: Remote Configuration.
- (line 6)
-* set remote system-call-allowed: system. (line 38)
-* set remote-mips64-transfers-32bit-regs: MIPS. (line 71)
-* set remotecache: Caching Remote Data. (line 18)
-* set remoteflow: Remote Configuration.
- (line 41)
-* set retransmit-timeout: MIPS Embedded. (line 83)
-* set rstack_high_address: A29K. (line 6)
-* set schedule-multiple: All-Stop Mode. (line 66)
-* set script-extension: Extending GDB. (line 19)
-* set sdstimeout: PowerPC Embedded. (line 84)
-* set server-address: M32R/D. (line 27)
-* set sh calling-convention: Super-H. (line 12)
-* set shell: Cygwin Native. (line 90)
-* set signal-thread: Hurd Native. (line 21)
-* set signals, Hurd command: Hurd Native. (line 11)
-* set sigs, Hurd command: Hurd Native. (line 11)
-* set sigthread: Hurd Native. (line 21)
-* set solib-absolute-prefix: Files. (line 374)
-* set solib-search-path: Files. (line 443)
-* set spu: SPU. (line 39)
-* set stack-cache: Caching Remote Data. (line 26)
-* set static tracepoint: Create and Delete Tracepoints.
- (line 51)
-* set step-mode: Continuing and Stepping.
- (line 92)
-* set stop-on-solib-events: Files. (line 351)
-* set stopped, Hurd command: Hurd Native. (line 32)
-* set struct-convention: i386. (line 7)
-* set substitute-path: Source Path. (line 127)
-* set symbol-reloading: Symbols. (line 224)
-* set syn-garbage-limit, MIPS remote: MIPS Embedded. (line 98)
-* set sysroot: Files. (line 374)
-* set target-async: Background Execution.
- (line 17)
-* set target-charset: Character Sets. (line 28)
-* set target-file-system-kind (unix|dos-based|auto): Files. (line 457)
-* set target-wide-charset: Character Sets. (line 61)
-* set task, Hurd commands: Hurd Native. (line 49)
-* set tcp: Remote Configuration.
- (line 107)
-* set tdesc filename: Retrieving Descriptions.
- (line 18)
-* set thread, Hurd command: Hurd Native. (line 91)
-* set timeout: MIPS Embedded. (line 83)
-* set trace-commands: Messages/Warnings. (line 67)
-* set tracepoint: Create and Delete Tracepoints.
- (line 6)
-* set trust-readonly-sections: Files. (line 258)
-* set tui active-border-mode: TUI Configuration. (line 24)
-* set tui border-kind: TUI Configuration. (line 9)
-* set tui border-mode: TUI Configuration. (line 23)
-* set unwind-on-terminating-exception: Calling. (line 46)
-* set unwindonsignal: Calling. (line 35)
-* set variable: Assignment. (line 16)
-* set verbose: Messages/Warnings. (line 15)
-* set watchdog: Maintenance Commands.
- (line 357)
-* set width: Screen Size. (line 21)
-* set write: Patching. (line 15)
-* set-mark (C-@): Miscellaneous Commands.
- (line 32)
-* set_debug_traps: Stub Contents. (line 10)
-* set_doc: Parameters In Python.
- (line 54)
-* setting variables: Assignment. (line 6)
-* setting watchpoints: Set Watchpoints. (line 6)
-* SH: Remote Stub. (line 63)
-* sh-stub.c: Remote Stub. (line 63)
-* share: Files. (line 332)
-* shared libraries: Files. (line 281)
-* shared library events, remote reply: Stop Reply Packets. (line 56)
-* sharedlibrary: Files. (line 332)
-* shell: Shell Commands. (line 10)
-* shell escape: Shell Commands. (line 10)
-* show: Help. (line 112)
-* show ada trust-PAD-over-XVS: Ada Glitches. (line 43)
-* show all convenience functions: Convenience Vars. (line 112)
-* show all user variables: Convenience Vars. (line 37)
-* show annotate: Annotations Overview.
- (line 34)
-* show architecture: Targets. (line 21)
-* show args: Arguments. (line 28)
-* show arm: ARM. (line 22)
-* show auto-load-scripts: Auto-loading. (line 26)
-* show auto-solib-add: Files. (line 320)
-* show backtrace: Backtrace. (line 111)
-* show basenames-may-differ: Files. (line 520)
-* show board-address: M32R/D. (line 24)
-* show breakpoint always-inserted: Set Breaks. (line 314)
-* show breakpoint auto-hw: Set Breaks. (line 294)
-* show breakpoint pending: Set Breaks. (line 263)
-* show can-use-hw-watchpoints: Set Watchpoints. (line 104)
-* show case-sensitive: Symbols. (line 40)
-* show charset: Character Sets. (line 52)
-* show check range: Range Checking. (line 34)
-* show check type: Type Checking. (line 42)
-* show circular-trace-buffer: Starting and Stopping Trace Experiments.
- (line 94)
-* show coerce-float-to-double: ABI. (line 50)
-* show com1base: DJGPP Native. (line 137)
-* show com1irq: DJGPP Native. (line 137)
-* show com2base: DJGPP Native. (line 137)
-* show com2irq: DJGPP Native. (line 137)
-* show com3base: DJGPP Native. (line 137)
-* show com3irq: DJGPP Native. (line 137)
-* show com4base: DJGPP Native. (line 137)
-* show com4irq: DJGPP Native. (line 137)
-* show commands: Command History. (line 78)
-* show complaints: Messages/Warnings. (line 35)
-* show confirm: Messages/Warnings. (line 58)
-* show convenience: Convenience Vars. (line 37)
-* show copying: Help. (line 136)
-* show cp-abi: ABI. (line 53)
-* show cygwin-exceptions: Cygwin Native. (line 50)
-* show data-directory: Data Files. (line 16)
-* show dcache line-size: Caching Remote Data. (line 56)
-* show dcache size: Caching Remote Data. (line 52)
-* show debug: Debugging Output. (line 22)
-* show debug darwin: Darwin. (line 13)
-* show debug libthread-db: Threads. (line 212)
-* show debug mach-o: Darwin. (line 23)
-* show debug mips: MIPS. (line 85)
-* show debug monitor: Target Commands. (line 112)
-* show debug nto-debug: Neutrino. (line 13)
-* show debug-file-directory: Separate Debug Files.
- (line 73)
-* show default-collect: Tracepoint Actions. (line 123)
-* show detach-on-fork: Forks. (line 71)
-* show directories: Source Path. (line 124)
-* show disassemble-next-line: Machine Code. (line 139)
-* show disassembly-flavor: Machine Code. (line 136)
-* show disconnected-tracing: Starting and Stopping Trace Experiments.
- (line 55)
-* show displaced-stepping: Maintenance Commands.
- (line 56)
-* show download-path: M32R/D. (line 18)
-* show editing: Editing. (line 22)
-* show environment: Environment. (line 33)
-* show exceptions, Hurd command: Hurd Native. (line 46)
-* show exec-done-display: Debugging Output. (line 14)
-* show follow-fork-mode: Forks. (line 49)
-* show gnutarget: Target Commands. (line 40)
-* show hash, for remote monitors: Target Commands. (line 105)
-* show height: Screen Size. (line 21)
-* show history: Command History. (line 70)
-* show host-charset: Character Sets. (line 55)
-* show inferior-tty: Input/Output. (line 52)
-* show input-radix: Numbers. (line 36)
-* show interactive-mode: Other Misc Settings. (line 21)
-* show language: Show. (line 10)
-* show last commands: Command History. (line 78)
-* show libthread-db-search-path: Threads. (line 209)
-* show listsize: List. (line 37)
-* show logging: Logging Output. (line 26)
-* show mach-exceptions: Darwin. (line 34)
-* show max-user-call-depth: Define. (line 76)
-* show mem inaccessible-by-default: Memory Region Attributes.
- (line 136)
-* show mips abi: MIPS. (line 54)
-* show mips mask-address: MIPS. (line 67)
-* show mipsfpu: MIPS Embedded. (line 60)
-* show monitor-prompt, MIPS remote: MIPS Embedded. (line 119)
-* show monitor-warnings, MIPS remote: MIPS Embedded. (line 129)
-* show multiple-symbols: Ambiguous Expressions.
- (line 70)
-* show new-console: Cygwin Native. (line 59)
-* show new-group: Cygwin Native. (line 68)
-* show non-stop: Non-Stop Mode. (line 42)
-* show opaque-type-resolution: Symbols. (line 256)
-* show osabi: ABI. (line 11)
-* show output-radix: Numbers. (line 39)
-* show overload-resolution: Debugging C Plus Plus.
- (line 65)
-* show pagination: Screen Size. (line 44)
-* show paths: Environment. (line 29)
-* show print: Print Settings. (line 39)
-* show print inferior-events: Inferiors and Programs.
- (line 125)
-* show print symbol-loading: Symbols. (line 269)
-* show print thread-events: Threads. (line 166)
-* show processor: Targets. (line 31)
-* show procfs-file: SVR4 Process Information.
- (line 64)
-* show procfs-trace: SVR4 Process Information.
- (line 56)
-* show prompt: Prompt. (line 19)
-* show radix: Numbers. (line 44)
-* show ravenscar task-switching: Ravenscar Profile. (line 22)
-* show rdiheartbeat: ARM. (line 117)
-* show rdiromatzero: ARM. (line 109)
-* show record insn-number-max: Process Record and Replay.
- (line 106)
-* show record memory-query: Process Record and Replay.
- (line 134)
-* show record stop-at-limit: Process Record and Replay.
- (line 120)
-* show remote: Remote Configuration.
- (line 6)
-* show remote system-call-allowed: system. (line 42)
-* show remote-mips64-transfers-32bit-regs: MIPS. (line 77)
-* show remotecache: Caching Remote Data. (line 23)
-* show remoteflow: Remote Configuration.
- (line 45)
-* show retransmit-timeout: MIPS Embedded. (line 83)
-* show rstack_high_address: A29K. (line 17)
-* show script-extension: Extending GDB. (line 19)
-* show sdstimeout: PowerPC Embedded. (line 88)
-* show server-address: M32R/D. (line 31)
-* show sh calling-convention: Super-H. (line 25)
-* show shell: Cygwin Native. (line 94)
-* show signal-thread: Hurd Native. (line 28)
-* show signals, Hurd command: Hurd Native. (line 17)
-* show sigs, Hurd command: Hurd Native. (line 17)
-* show sigthread: Hurd Native. (line 28)
-* show solib-search-path: Files. (line 454)
-* show spu: SPU. (line 44)
-* show stack-cache: Caching Remote Data. (line 31)
-* show stop-on-solib-events: Files. (line 357)
-* show stopped, Hurd command: Hurd Native. (line 37)
-* show struct-convention: i386. (line 15)
-* show substitute-path: Source Path. (line 164)
-* show symbol-reloading: Symbols. (line 238)
-* show syn-garbage-limit, MIPS remote: MIPS Embedded. (line 103)
-* show sysroot: Files. (line 440)
-* show target-async: Background Execution.
- (line 21)
-* show target-charset: Character Sets. (line 58)
-* show target-file-system-kind: Files. (line 457)
-* show target-wide-charset: Character Sets. (line 67)
-* show task, Hurd commands: Hurd Native. (line 57)
-* show tcp: Remote Configuration.
- (line 107)
-* show tdesc filename: Retrieving Descriptions.
- (line 25)
-* show thread, Hurd command: Hurd Native. (line 101)
-* show timeout: MIPS Embedded. (line 83)
-* show unwind-on-terminating-exception: Calling. (line 54)
-* show unwindonsignal: Calling. (line 42)
-* show user: Define. (line 70)
-* show values: Value History. (line 47)
-* show verbose: Messages/Warnings. (line 21)
-* show version: Help. (line 126)
-* show warranty: Help. (line 140)
-* show width: Screen Size. (line 21)
-* show write: Patching. (line 26)
-* show-all-if-ambiguous: Readline Init File Syntax.
- (line 164)
-* show-all-if-unmodified: Readline Init File Syntax.
- (line 170)
-* show_doc: Parameters In Python.
- (line 60)
-* si (stepi): Continuing and Stepping.
- (line 190)
-* signal: Signaling. (line 6)
-* signal annotation: Annotations for Running.
- (line 42)
-* signal-name annotation: Annotations for Running.
- (line 22)
-* signal-name-end annotation: Annotations for Running.
- (line 22)
-* signal-string annotation: Annotations for Running.
- (line 22)
-* signal-string-end annotation: Annotations for Running.
- (line 22)
-* signalled annotation: Annotations for Running.
- (line 22)
-* signals: Signals. (line 6)
-* SIGQUIT signal, dump core of GDB: Maintenance Commands.
- (line 99)
-* silent <1>: Break Commands. (line 43)
-* silent: Breakpoints In Python.
- (line 79)
-* sim: Z8000. (line 15)
-* sim, a command: Embedded Processors. (line 13)
-* simulator, Z8000: Z8000. (line 6)
-* size of remote memory accesses: Packets. (line 228)
-* size of screen: Screen Size. (line 6)
-* sizeof: Types In Python. (line 28)
-* snapshot of a process: Checkpoint/Restart. (line 6)
-* software watchpoints: Set Watchpoints. (line 31)
-* solib_name: Basic Python. (line 154)
-* source: Command Files. (line 17)
-* source annotation: Source Annotations. (line 6)
-* source file and line of a symbol: Print Settings. (line 51)
-* source line and its code address: Machine Code. (line 6)
-* source path: Source Path. (line 6)
-* Sparc: Remote Stub. (line 66)
-* sparc-stub.c: Remote Stub. (line 66)
-* sparcl-stub.c: Remote Stub. (line 69)
-* Sparclet: Sparclet. (line 6)
-* SparcLite: Remote Stub. (line 69)
-* Special Fortran commands: Special Fortran Commands.
- (line 6)
-* specifying location: Specify Location. (line 6)
-* spr: OpenRISC 1000. (line 33)
-* SPU: SPU. (line 6)
-* SSE registers (x86): Registers. (line 71)
-* stack frame: Frames. (line 6)
-* stack on Alpha: MIPS. (line 6)
-* stack on MIPS: MIPS. (line 6)
-* stack pointer register: Registers. (line 26)
-* stacking targets: Active Targets. (line 6)
-* standard registers: Registers. (line 26)
-* start <1>: Blocks In Python. (line 36)
-* start: Starting. (line 78)
-* start a new trace experiment: Starting and Stopping Trace Experiments.
- (line 6)
-* start-kbd-macro (C-x (): Keyboard Macros. (line 6)
-* starting: Starting. (line 6)
-* starting annotation: Annotations for Running.
- (line 6)
-* startup code, and backtrace: Backtrace. (line 93)
-* stat, file-i/o system call: stat/fstat. (line 6)
-* static members of C++ objects: Print Settings. (line 342)
-* static members of Pascal objects: Print Settings. (line 353)
-* static tracepoints: Set Tracepoints. (line 28)
-* static tracepoints, in remote protocol: General Query Packets.
- (line 563)
-* static tracepoints, setting: Create and Delete Tracepoints.
- (line 51)
-* status of trace data collection: Starting and Stopping Trace Experiments.
- (line 20)
-* status output in GDB/MI: GDB/MI Output Syntax.
- (line 94)
-* STDERR: Basic Python. (line 132)
-* STDLOG: Basic Python. (line 114)
-* STDOUT: Basic Python. (line 129)
-* step: Continuing and Stepping.
- (line 46)
-* step&: Background Execution.
- (line 41)
-* stepi: Continuing and Stepping.
- (line 190)
-* stepi&: Background Execution.
- (line 44)
-* stepping: Continuing and Stepping.
- (line 6)
-* stepping into functions with no line info: Continuing and Stepping.
- (line 93)
-* stop a running trace experiment: Starting and Stopping Trace Experiments.
- (line 12)
-* stop on C++ exceptions: Set Catchpoints. (line 13)
-* stop on gdb.Breakpoint: Breakpoints In Python.
- (line 25)
-* stop reply packets: Stop Reply Packets. (line 6)
-* stop, a pseudo-command: Hooks. (line 21)
-* stop_signal: Events In Python. (line 91)
-* stopped threads: Thread Stops. (line 6)
-* stopping annotation: Annotations for Running.
- (line 6)
-* strace: Create and Delete Tracepoints.
- (line 51)
-* stream records in GDB/MI: GDB/MI Stream Records.
- (line 6)
-* string on Value: Values From Inferior.
- (line 139)
-* strip_typedefs on Type: Types In Python. (line 118)
-* struct return convention: i386. (line 7)
-* struct stat, in file-i/o protocol: struct stat. (line 6)
-* struct timeval, in file-i/o protocol: struct timeval. (line 6)
-* struct user contents: OS Information. (line 9)
-* struct/union returned in registers: i386. (line 7)
-* structure field name completion: Completion. (line 96)
-* stub example, remote debugging: Remote Stub. (line 6)
-* stupid questions: Messages/Warnings. (line 50)
-* Super-H: Super-H. (line 6)
-* superblock: Blocks In Python. (line 48)
-* supported packets, remote query: General Query Packets.
- (line 328)
-* switch on InferiorThread: Threads In Python. (line 51)
-* switching threads: Threads. (line 6)
-* switching threads automatically: All-Stop Mode. (line 28)
-* symbol decoding style, C++: Print Settings. (line 296)
-* symbol dump: Symbols. (line 272)
-* symbol from address: Symbols. (line 54)
-* symbol lookup, remote request: General Query Packets.
- (line 567)
-* symbol names: Symbols. (line 14)
-* symbol table: Files. (line 6)
-* symbol tables in python: Symbol Tables In Python.
- (line 6)
-* symbol tables, listing GDB's internal: Symbols. (line 291)
-* symbol, source file and line: Print Settings. (line 51)
-* symbol-file: Files. (line 45)
-* SYMBOL_FUNCTIONS_DOMAIN: Symbols In Python. (line 117)
-* SYMBOL_LABEL_DOMAIN: Symbols In Python. (line 110)
-* SYMBOL_LOC_ARG: Symbols In Python. (line 139)
-* SYMBOL_LOC_BLOCK: Symbols In Python. (line 160)
-* SYMBOL_LOC_COMPUTED: Symbols In Python. (line 174)
-* SYMBOL_LOC_CONST: Symbols In Python. (line 130)
-* SYMBOL_LOC_CONST_BYTES: Symbols In Python. (line 163)
-* SYMBOL_LOC_LOCAL: Symbols In Python. (line 153)
-* SYMBOL_LOC_OPTIMIZED_OUT: Symbols In Python. (line 171)
-* SYMBOL_LOC_REF_ARG: Symbols In Python. (line 143)
-* SYMBOL_LOC_REGISTER: Symbols In Python. (line 136)
-* SYMBOL_LOC_REGPARM_ADDR: Symbols In Python. (line 148)
-* SYMBOL_LOC_STATIC: Symbols In Python. (line 133)
-* SYMBOL_LOC_TYPEDEF: Symbols In Python. (line 156)
-* SYMBOL_LOC_UNDEF: Symbols In Python. (line 128)
-* SYMBOL_LOC_UNRESOLVED: Symbols In Python. (line 166)
-* SYMBOL_STRUCT_DOMAIN: Symbols In Python. (line 107)
-* SYMBOL_TYPES_DOMAIN: Symbols In Python. (line 120)
-* SYMBOL_UNDEF_DOMAIN: Symbols In Python. (line 100)
-* SYMBOL_VAR_DOMAIN: Symbols In Python. (line 103)
-* SYMBOL_VARIABLES_DOMAIN: Symbols In Python. (line 113)
-* symbols in python: Symbols In Python. (line 6)
-* symbols, reading from relocatable object files: Files. (line 132)
-* symbols, reading immediately: Files. (line 90)
-* symtab <1>: Symbols In Python. (line 53)
-* symtab: Symbol Tables In Python.
- (line 17)
-* synchronize with remote MIPS target: MIPS Embedded. (line 98)
-* syscall DSO: Files. (line 162)
-* sysinfo: DJGPP Native. (line 19)
-* system calls and thread breakpoints: Interrupted System Calls.
- (line 6)
-* system root, alternate: Files. (line 374)
-* system, file-i/o system call: system. (line 6)
-* system-wide init file: System-wide configuration.
- (line 6)
-* T packet: Packets. (line 316)
-* t packet: Packets. (line 311)
-* T packet reply: Stop Reply Packets. (line 22)
-* tabset: TUI Commands. (line 84)
-* tag: Types In Python. (line 33)
-* target: Target Commands. (line 49)
-* target architecture: Targets. (line 17)
-* target array: MIPS Embedded. (line 49)
-* target byte order: Byte Order. (line 6)
-* target character set: Character Sets. (line 6)
-* target dbug: M68K. (line 9)
-* target ddb PORT: MIPS Embedded. (line 41)
-* target debugging info: Debugging Output. (line 165)
-* target descriptions: Target Descriptions. (line 6)
-* target descriptions, ARM features: ARM Features. (line 6)
-* target descriptions, i386 features: i386 Features. (line 6)
-* target descriptions, inclusion: Target Description Format.
- (line 54)
-* target descriptions, M68K features: M68K Features. (line 6)
-* target descriptions, MIPS features: MIPS Features. (line 6)
-* target descriptions, PowerPC features: PowerPC Features. (line 6)
-* target descriptions, predefined types: Predefined Target Types.
- (line 6)
-* target descriptions, standard features: Standard Target Features.
- (line 6)
-* target descriptions, XML format: Target Description Format.
- (line 6)
-* target dink32: PowerPC Embedded. (line 69)
-* target jtag: OpenRISC 1000. (line 9)
-* target lsi PORT: MIPS Embedded. (line 44)
-* target m32r: M32R/D. (line 6)
-* target m32rsdi: M32R/D. (line 9)
-* target mips PORT: MIPS Embedded. (line 14)
-* target on Type: Types In Python. (line 122)
-* target op50n: PA. (line 6)
-* target output in GDB/MI: GDB/MI Output Syntax.
- (line 110)
-* target pmon PORT: MIPS Embedded. (line 38)
-* target ppcbug: PowerPC Embedded. (line 72)
-* target ppcbug1: PowerPC Embedded. (line 73)
-* target r3900: MIPS Embedded. (line 46)
-* target rdi: ARM. (line 6)
-* target rdp: ARM. (line 11)
-* target record: Process Record and Replay.
- (line 38)
-* target remote: Connecting. (line 11)
-* target sds: PowerPC Embedded. (line 77)
-* target sim, with Z8000: Z8000. (line 15)
-* target sparclite: Sparclite. (line 6)
-* target stack description: Maintenance Commands.
- (line 236)
-* target tfile: Trace Files. (line 22)
-* target vxworks: VxWorks. (line 6)
-* target w89k: PA. (line 9)
-* target_charset: Basic Python. (line 143)
-* target_wide_charset: Basic Python. (line 148)
-* task: Breakpoints In Python.
- (line 92)
-* task (Ada): Ada Tasks. (line 105)
-* task attributes (GNU Hurd): Hurd Native. (line 49)
-* task breakpoints, in Ada: Ada Tasks. (line 135)
-* task exception port, GNU Hurd: Hurd Native. (line 68)
-* task suspend count: Hurd Native. (line 60)
-* task switching with program using Ravenscar Profile: Ravenscar Profile.
- (line 10)
-* tbreak: Set Breaks. (line 55)
-* TCP port, target remote: Connecting. (line 29)
-* tdump: tdump. (line 6)
-* template_argument on Type: Types In Python. (line 137)
-* terminal: Input/Output. (line 6)
-* teval (tracepoints): Tracepoint Actions. (line 89)
-* Text User Interface: TUI. (line 6)
-* tfile: Trace Files. (line 22)
-* tfind: tfind. (line 6)
-* thbreak: Set Breaks. (line 82)
-* this, inside C++ member functions: C Plus Plus Expressions.
- (line 22)
-* thread: Breakpoints In Python.
- (line 87)
-* thread apply: Threads. (line 122)
-* thread attributes info, remote request: General Query Packets.
- (line 612)
-* thread breakpoints: Thread-Specific Breakpoints.
- (line 10)
-* thread breakpoints and system calls: Interrupted System Calls.
- (line 6)
-* thread default settings, GNU Hurd: Hurd Native. (line 131)
-* thread find: Threads. (line 142)
-* thread identifier (GDB): Threads. (line 63)
-* thread identifier (system): Threads. (line 51)
-* thread info (Solaris): Threads. (line 98)
-* thread information, remote request: General Query Packets.
- (line 209)
-* thread list format: Thread List Format. (line 6)
-* thread name: Threads. (line 131)
-* thread number: Threads. (line 63)
-* thread properties, GNU Hurd: Hurd Native. (line 91)
-* thread suspend count, GNU Hurd: Hurd Native. (line 110)
-* thread THREADNO: Threads. (line 100)
-* THREAD-ID, in remote protocol: Packets. (line 20)
-* threads and watchpoints: Set Watchpoints. (line 165)
-* threads in python: Threads In Python. (line 6)
-* threads of execution: Threads. (line 6)
-* threads on Inferior: Inferiors In Python. (line 40)
-* threads, automatic switching: All-Stop Mode. (line 28)
-* threads, continuing: Thread Stops. (line 6)
-* threads, stopped: Thread Stops. (line 6)
-* time of command execution: Maintenance Commands.
- (line 328)
-* timeout for commands: Maintenance Commands.
- (line 357)
-* timeout for serial communications: Remote Configuration.
- (line 65)
-* timeout, for remote target connection: Remote Configuration.
- (line 123)
-* timeout, MIPS protocol: MIPS Embedded. (line 83)
-* timestampping debugging info: Debugging Output. (line 176)
-* tload, M32R: M32R/D. (line 39)
-* to_string on pretty printer: Pretty Printing API. (line 54)
-* trace: Create and Delete Tracepoints.
- (line 6)
-* trace experiment, status of: Starting and Stopping Trace Experiments.
- (line 20)
-* trace file format: Trace File Format. (line 6)
-* trace files: Trace Files. (line 6)
-* trace state variable value, remote request: Tracepoint Packets.
- (line 276)
-* trace state variables: Trace State Variables.
- (line 6)
-* traceback: Backtrace. (line 6)
-* traceframe info format: Traceframe Info Format.
- (line 6)
-* tracepoint actions: Tracepoint Actions. (line 6)
-* tracepoint conditions: Tracepoint Conditions.
- (line 6)
-* tracepoint data, display: tdump. (line 6)
-* tracepoint deletion: Create and Delete Tracepoints.
- (line 101)
-* tracepoint number: Create and Delete Tracepoints.
- (line 98)
-* tracepoint packets: Tracepoint Packets. (line 6)
-* tracepoint pass count: Tracepoint Passcounts.
- (line 6)
-* tracepoint restrictions: Tracepoint Restrictions.
- (line 6)
-* tracepoint variables: Tracepoint Variables.
- (line 6)
-* tracepoints: Tracepoints. (line 6)
-* tracepoints support in gdbserver: Server. (line 207)
-* trailing underscore, in Fortran symbols: Fortran. (line 9)
-* translating between character sets: Character Sets. (line 6)
-* transpose-chars (C-t): Commands For Text. (line 30)
-* transpose-words (M-t): Commands For Text. (line 36)
-* tsave: Trace Files. (line 12)
-* tstart: Starting and Stopping Trace Experiments.
- (line 6)
-* tstatus: Starting and Stopping Trace Experiments.
- (line 20)
-* tstop: Starting and Stopping Trace Experiments.
- (line 12)
-* tty: Input/Output. (line 23)
-* TUI: TUI. (line 6)
-* TUI commands: TUI Commands. (line 6)
-* TUI configuration variables: TUI Configuration. (line 6)
-* TUI key bindings: TUI Keys. (line 6)
-* tui reg: TUI Commands. (line 61)
-* TUI single key mode: TUI Single Key Mode. (line 6)
-* tvariable: Trace State Variables.
- (line 26)
-* type <1>: Symbols In Python. (line 48)
-* type <2>: Values From Inferior.
- (line 55)
-* type <3>: Lazy Strings In Python.
- (line 44)
-* type: Breakpoints In Python.
- (line 107)
-* type casting memory: Expressions. (line 43)
-* type chain of a data type: Maintenance Commands.
- (line 248)
-* type checking: Checks. (line 31)
-* type conversions in C++: C Plus Plus Expressions.
- (line 27)
-* type on Frame: Frames In Python. (line 48)
-* TYPE_CODE_ARRAY: Types In Python. (line 155)
-* TYPE_CODE_BITSTRING: Types In Python. (line 193)
-* TYPE_CODE_BOOL: Types In Python. (line 214)
-* TYPE_CODE_CHAR: Types In Python. (line 211)
-* TYPE_CODE_COMPLEX: Types In Python. (line 217)
-* TYPE_CODE_DECFLOAT: Types In Python. (line 226)
-* TYPE_CODE_ENUM: Types In Python. (line 164)
-* TYPE_CODE_ERROR: Types In Python. (line 196)
-* TYPE_CODE_FLAGS: Types In Python. (line 167)
-* TYPE_CODE_FLT: Types In Python. (line 176)
-* TYPE_CODE_FUNC: Types In Python. (line 170)
-* TYPE_CODE_INT: Types In Python. (line 173)
-* TYPE_CODE_INTERNAL_FUNCTION: Types In Python. (line 229)
-* TYPE_CODE_MEMBERPTR: Types In Python. (line 205)
-* TYPE_CODE_METHOD: Types In Python. (line 199)
-* TYPE_CODE_METHODPTR: Types In Python. (line 202)
-* TYPE_CODE_NAMESPACE: Types In Python. (line 223)
-* TYPE_CODE_PTR: Types In Python. (line 152)
-* TYPE_CODE_RANGE: Types In Python. (line 185)
-* TYPE_CODE_REF: Types In Python. (line 208)
-* TYPE_CODE_SET: Types In Python. (line 182)
-* TYPE_CODE_STRING: Types In Python. (line 188)
-* TYPE_CODE_STRUCT: Types In Python. (line 158)
-* TYPE_CODE_TYPEDEF: Types In Python. (line 220)
-* TYPE_CODE_UNION: Types In Python. (line 161)
-* TYPE_CODE_VOID: Types In Python. (line 179)
-* types in Python: Types In Python. (line 6)
-* u (SingleKey TUI key): TUI Single Key Mode. (line 31)
-* u (until): Continuing and Stepping.
- (line 118)
-* UDP port, target remote: Connecting. (line 49)
-* undisplay: Auto Display. (line 45)
-* undo (C-_ or C-x C-u): Miscellaneous Commands.
- (line 22)
-* union field name completion: Completion. (line 96)
-* unions in structures, printing: Print Settings. (line 236)
-* universal-argument (): Numeric Arguments. (line 10)
-* unix-filename-rubout (): Commands For Killing.
- (line 32)
-* unix-line-discard (C-u): Commands For Killing.
- (line 12)
-* unix-word-rubout (C-w): Commands For Killing.
- (line 28)
-* unknown address, locating: Output Formats. (line 35)
-* unlink, file-i/o system call: unlink. (line 6)
-* unlinked object files: Files. (line 26)
-* unload symbols from shared libraries: Files. (line 341)
-* unmap an overlay: Overlay Commands. (line 39)
-* unmapped overlays: How Overlays Work. (line 6)
-* unqualified on Type: Types In Python. (line 99)
-* unset environment: Environment. (line 55)
-* unset substitute-path: Source Path. (line 156)
-* unset tdesc filename: Retrieving Descriptions.
- (line 21)
-* unsupported languages: Unsupported Languages.
- (line 6)
-* until: Continuing and Stepping.
- (line 118)
-* until&: Background Execution.
- (line 59)
-* unwind stack in called functions: Calling. (line 35)
-* unwind stack in called functions with unhandled exceptions: Calling.
- (line 46)
-* unwind_stop_reason on Frame: Frames In Python. (line 74)
-* up: Selection. (line 35)
-* Up: TUI Keys. (line 53)
-* up-silently: Selection. (line 64)
-* upcase-word (M-u): Commands For Text. (line 41)
-* update: TUI Commands. (line 76)
-* upload, M32R: M32R/D. (line 34)
-* use only software watchpoints: Set Watchpoints. (line 93)
-* use_dbt_break: M32R/D. (line 64)
-* use_debug_dma: M32R/D. (line 53)
-* use_ib_break: M32R/D. (line 61)
-* use_mon_code: M32R/D. (line 57)
-* user-defined command: Define. (line 6)
-* user-defined macros: Macros. (line 52)
-* user-defined variables: Convenience Vars. (line 6)
-* v (SingleKey TUI key): TUI Single Key Mode. (line 34)
-* value: Parameters In Python.
- (line 66)
-* value history: Value History. (line 6)
-* value on LazyString: Lazy Strings In Python.
- (line 21)
-* values from inferior, with Python: Values From Inferior.
- (line 6)
-* variable name conflict: Variables. (line 36)
-* variable object debugging info: Debugging Output. (line 185)
-* variable objects in GDB/MI: GDB/MI Variable Objects.
- (line 9)
-* variable values, wrong: Variables. (line 58)
-* variables, readline: Readline Init File Syntax.
- (line 34)
-* variables, setting: Assignment. (line 16)
-* vAttach packet: Packets. (line 331)
-* vCont packet: Packets. (line 351)
-* vCont? packet: Packets. (line 393)
-* vector unit: Vector Unit. (line 6)
-* vector, auxiliary: OS Information. (line 21)
-* verbose operation: Messages/Warnings. (line 6)
-* verify remote memory image: Memory. (line 123)
-* vFile packet: Packets. (line 404)
-* vFlashDone packet: Packets. (line 452)
-* vFlashErase packet: Packets. (line 408)
-* vFlashWrite packet: Packets. (line 430)
-* virtual functions (C++) display: Print Settings. (line 364)
-* visible: Breakpoints In Python.
- (line 112)
-* visible-stats: Readline Init File Syntax.
- (line 179)
-* vKill packet: Packets. (line 460)
-* volatile on Type: Types In Python. (line 95)
-* vRun packet: Packets. (line 473)
-* vStopped packet: Packets. (line 490)
-* VTBL display: Print Settings. (line 364)
-* VxWorks: VxWorks. (line 6)
-* vxworks-timeout: VxWorks. (line 23)
-* w (SingleKey TUI key): TUI Single Key Mode. (line 37)
-* was_attached: Inferiors In Python. (line 27)
-* watch: Set Watchpoints. (line 42)
-* watchdog timer: Maintenance Commands.
- (line 357)
-* watchpoint annotation: Annotations for Running.
- (line 50)
-* watchpoints: Breakpoints. (line 20)
-* watchpoints and threads: Set Watchpoints. (line 165)
-* weak alias functions: Calling. (line 58)
-* whatis: Symbols. (line 74)
-* where: Backtrace. (line 34)
-* where to look for shared libraries: Files. (line 369)
-* while: Command Files. (line 86)
-* while-stepping (tracepoints): Tracepoint Actions. (line 97)
-* wild pointer, interpreting: Print Settings. (line 79)
-* winheight: TUI Commands. (line 80)
-* word completion: Completion. (line 6)
-* working directory: Source Path. (line 108)
-* working directory (of your program): Working Directory. (line 6)
-* working language: Languages. (line 13)
-* WP_ACCESS: Breakpoints In Python.
- (line 58)
-* WP_READ: Breakpoints In Python.
- (line 52)
-* WP_WRITE: Breakpoints In Python.
- (line 55)
-* write: Basic Python. (line 104)
-* write data into object, remote request: General Query Packets.
- (line 781)
-* write, file-i/o system call: write. (line 6)
-* write_memory on Inferior: Inferiors In Python. (line 51)
-* writing a pretty-printer: Writing a Pretty-Printer.
- (line 6)
-* writing convenience functions: Functions In Python. (line 6)
-* writing into corefiles: Patching. (line 6)
-* writing into executables: Patching. (line 6)
-* wrong values: Variables. (line 58)
-* x (examine memory): Memory. (line 9)
-* x command, default address: Machine Code. (line 30)
-* X packet: Packets. (line 502)
-* x(examine), and info line: Machine Code. (line 30)
-* Xilinx MicroBlaze: MicroBlaze. (line 6)
-* XInclude: Target Description Format.
- (line 54)
-* XMD, Xilinx Microprocessor Debugger: MicroBlaze. (line 6)
-* XML parser debugging: Debugging Output. (line 193)
-* yank (C-y): Commands For Killing.
- (line 59)
-* yank-last-arg (M-. or M-_): Commands For History.
- (line 64)
-* yank-nth-arg (M-C-y): Commands For History.
- (line 55)
-* yank-pop (M-y): Commands For Killing.
- (line 62)
-* yanking text: Readline Killing Commands.
- (line 6)
-* z packet: Packets. (line 515)
-* Z packets: Packets. (line 515)
-* Z0 packet: Packets. (line 530)
-* z0 packet: Packets. (line 530)
-* Z1 packet: Packets. (line 558)
-* z1 packet: Packets. (line 558)
-* Z2 packet: Packets. (line 580)
-* z2 packet: Packets. (line 580)
-* z3 packet: Packets. (line 595)
-* Z3 packet: Packets. (line 595)
-* Z4 packet: Packets. (line 610)
-* z4 packet: Packets. (line 610)
-* Z8000: Z8000. (line 6)
-* Zilog Z8000 simulator: Z8000. (line 6)
-* {TYPE}: Expressions. (line 43)
-
-
-
-Tag Table:
-Node: Top1966
-Node: Summary5144
-Node: Free Software6946
-Node: Contributors12514
-Node: Sample Session20603
-Node: Invocation27445
-Node: Invoking GDB27989
-Node: File Options30302
-Node: Mode Options33039
-Node: Startup40151
-Ref: Startup-Footnote-142930
-Node: Quitting GDB43039
-Node: Shell Commands43936
-Node: Logging Output44778
-Node: Commands45624
-Node: Command Syntax46262
-Node: Completion48428
-Ref: Completion-Footnote-153634
-Node: Help53794
-Node: Running59035
-Node: Compilation60264
-Node: Starting62241
-Node: Arguments71131
-Node: Environment72401
-Node: Working Directory75669
-Node: Input/Output76777
-Node: Attach78748
-Node: Kill Process81215
-Node: Inferiors and Programs82196
-Node: Threads89441
-Node: Forks98604
-Node: Checkpoint/Restart104914
-Ref: Checkpoint/Restart-Footnote-1109443
-Node: Stopping109478
-Node: Breakpoints110637
-Node: Set Breaks114073
-Ref: Set Breaks-Footnote-1130385
-Node: Set Watchpoints130633
-Node: Set Catchpoints139162
-Node: Delete Breaks148358
-Node: Disabling150294
-Node: Conditions153147
-Node: Break Commands158096
-Node: Save Breakpoints161320
-Node: Error in Breakpoints162496
-Node: Breakpoint-related Warnings163227
-Node: Continuing and Stepping165554
-Node: Signals174914
-Ref: extra signal information179186
-Node: Thread Stops180689
-Node: All-Stop Mode181788
-Node: Non-Stop Mode185686
-Node: Background Execution189163
-Node: Thread-Specific Breakpoints191732
-Node: Interrupted System Calls193054
-Node: Observer Mode194568
-Node: Reverse Execution198007
-Ref: Reverse Execution-Footnote-1202634
-Ref: Reverse Execution-Footnote-2203261
-Node: Process Record and Replay203311
-Node: Stack210558
-Node: Frames212051
-Node: Backtrace214803
-Ref: Backtrace-Footnote-1220016
-Node: Selection220204
-Node: Frame Info223068
-Node: Source225399
-Node: List226465
-Node: Specify Location229078
-Node: Edit232724
-Ref: Edit-Footnote-1234199
-Node: Search234434
-Node: Source Path235242
-Ref: set substitute-path241609
-Node: Machine Code243830
-Node: Data250504
-Node: Expressions253174
-Node: Ambiguous Expressions255266
-Node: Variables258500
-Node: Arrays263003
-Node: Output Formats265534
-Ref: Output Formats-Footnote-1268722
-Node: Memory268879
-Node: Auto Display275033
-Node: Print Settings279575
-Node: Pretty Printing293179
-Node: Pretty-Printer Introduction293692
-Node: Pretty-Printer Example295447
-Node: Pretty-Printer Commands296225
-Node: Value History298649
-Node: Convenience Vars301070
-Node: Registers305805
-Ref: Registers-Footnote-1310482
-Node: Floating Point Hardware310877
-Node: Vector Unit311409
-Node: OS Information311796
-Node: Memory Region Attributes314441
-Node: Dump/Restore Files319111
-Node: Core File Generation321416
-Node: Character Sets322650
-Node: Caching Remote Data329015
-Ref: Caching Remote Data-Footnote-1331280
-Node: Searching Memory331518
-Node: Optimized Code334395
-Node: Inline Functions336005
-Node: Macros338975
-Node: Tracepoints346078
-Node: Set Tracepoints348139
-Node: Create and Delete Tracepoints351077
-Node: Enable and Disable Tracepoints355965
-Node: Tracepoint Passcounts356749
-Node: Tracepoint Conditions358176
-Node: Trace State Variables359870
-Node: Tracepoint Actions362060
-Node: Listing Tracepoints367400
-Node: Listing Static Tracepoint Markers368521
-Node: Starting and Stopping Trace Experiments370367
-Node: Tracepoint Restrictions374781
-Node: Analyze Collected Data378534
-Node: tfind379839
-Node: tdump384261
-Node: save tracepoints386776
-Node: Tracepoint Variables387272
-Node: Trace Files388400
-Node: Overlays389858
-Node: How Overlays Work390578
-Ref: A code overlay393138
-Node: Overlay Commands396576
-Node: Automatic Overlay Debugging400766
-Node: Overlay Sample Program402907
-Node: Languages404667
-Node: Setting405830
-Node: Filenames407532
-Node: Manually408343
-Node: Automatically409552
-Node: Show410613
-Node: Checks411935
-Node: Type Checking413325
-Node: Range Checking416058
-Node: Supported Languages418459
-Node: C419720
-Node: C Operators421011
-Node: C Constants425330
-Node: C Plus Plus Expressions427734
-Node: C Defaults431277
-Node: C Checks431960
-Node: Debugging C432683
-Node: Debugging C Plus Plus433167
-Node: Decimal Floating Point436354
-Node: D437613
-Node: Objective-C437879
-Node: Method Names in Commands438341
-Node: The Print Command with Objective-C440036
-Node: OpenCL C440687
-Node: OpenCL C Datatypes440962
-Node: OpenCL C Expressions441337
-Node: OpenCL C Operators441694
-Node: Fortran441926
-Node: Fortran Operators442648
-Node: Fortran Defaults443504
-Node: Special Fortran Commands443889
-Node: Pascal444395
-Node: Modula-2444910
-Node: M2 Operators445885
-Node: Built-In Func/Proc448884
-Node: M2 Constants451745
-Node: M2 Types453346
-Node: M2 Defaults456565
-Node: Deviations457165
-Node: M2 Checks458266
-Node: M2 Scope459084
-Node: GDB/M2460108
-Node: Ada461020
-Node: Ada Mode Intro462083
-Node: Omissions from Ada463993
-Node: Additions to Ada468347
-Node: Stopping Before Main Program472277
-Node: Ada Tasks472806
-Node: Ada Tasks and Core Files479219
-Node: Ravenscar Profile480137
-Node: Ada Glitches481207
-Node: Unsupported Languages484001
-Node: Symbols484691
-Node: Altering499089
-Node: Assignment500058
-Node: Jumping503163
-Node: Signaling505298
-Node: Returning506429
-Node: Calling509781
-Node: Patching512808
-Node: GDB Files513885
-Node: Files514530
-Ref: Shared Libraries527365
-Ref: Files-Footnote-1538718
-Node: Separate Debug Files538893
-Node: Index Files550463
-Node: Symbol Errors551806
-Node: Data Files555419
-Node: Targets556375
-Node: Active Targets557855
-Node: Target Commands558929
-Ref: load563202
-Node: Byte Order564183
-Node: Remote Debugging565160
-Node: Connecting566422
-Node: File Transfer571362
-Node: Server572302
-Ref: Monitor Commands for gdbserver579952
-Ref: Server-Footnote-1584606
-Node: Remote Configuration584726
-Ref: set remotebreak585750
-Ref: set remote hardware-watchpoint-limit587214
-Ref: set remote hardware-breakpoint-limit587214
-Ref: set remote exec-file587496
-Node: Remote Stub593764
-Node: Stub Contents596661
-Node: Bootstrapping598772
-Node: Debug Session602581
-Node: Configurations604141
-Node: Native604910
-Node: HP-UX605545
-Node: BSD libkvm Interface605834
-Node: SVR4 Process Information606905
-Node: DJGPP Native610335
-Node: Cygwin Native616915
-Node: Non-debug DLL Symbols620864
-Node: Hurd Native625412
-Node: Neutrino630675
-Node: Darwin631065
-Node: Embedded OS632323
-Node: VxWorks632799
-Node: VxWorks Connection635016
-Node: VxWorks Download635950
-Node: VxWorks Attach637685
-Node: Embedded Processors638083
-Node: ARM639262
-Node: M32R/D643383
-Node: M68K645085
-Node: MicroBlaze645378
-Node: MIPS Embedded646828
-Node: OpenRISC 1000651778
-Node: PowerPC Embedded654633
-Node: PA658261
-Node: Sparclet658550
-Node: Sparclet File660034
-Node: Sparclet Connection660914
-Node: Sparclet Download661392
-Node: Sparclet Execution662441
-Node: Sparclite663032
-Node: Z8000663407
-Node: AVR664791
-Node: CRIS665154
-Node: Super-H666132
-Node: Architectures667247
-Node: i386667669
-Node: A29K668351
-Node: Alpha669190
-Node: MIPS669323
-Node: HPPA671947
-Node: SPU672466
-Node: PowerPC674654
-Node: Controlling GDB675372
-Node: Prompt676198
-Node: Editing676977
-Node: Command History677920
-Node: Screen Size681324
-Node: Numbers683158
-Node: ABI685135
-Node: Messages/Warnings688064
-Ref: confirmation requests689490
-Node: Debugging Output690697
-Node: Other Misc Settings697255
-Node: Extending GDB698282
-Node: Sequences699773
-Node: Define700368
-Node: Hooks703981
-Node: Command Files706348
-Node: Output711418
-Node: Python716351
-Node: Python Commands717270
-Node: Python API718945
-Node: Basic Python720753
-Node: Exception Handling727724
-Node: Values From Inferior730223
-Node: Types In Python738733
-Node: Pretty Printing API746823
-Node: Selecting Pretty-Printers750722
-Node: Writing a Pretty-Printer753055
-Node: Inferiors In Python758369
-Node: Events In Python761285
-Node: Threads In Python765736
-Node: Commands In Python768367
-Node: Parameters In Python777183
-Node: Functions In Python782638
-Node: Progspaces In Python784751
-Node: Objfiles In Python786113
-Node: Frames In Python788045
-Node: Blocks In Python792273
-Node: Symbols In Python794477
-Node: Symbol Tables In Python801197
-Node: Breakpoints In Python803734
-Node: Lazy Strings In Python810585
-Node: Auto-loading812859
-Node: objfile-gdb.py file814755
-Node: .debug_gdb_scripts section816010
-Node: Which flavor to choose?817387
-Node: Python modules819204
-Node: gdb.printing819512
-Node: gdb.types820587
-Node: Interpreters821574
-Node: TUI823673
-Node: TUI Overview824640
-Node: TUI Keys827073
-Node: TUI Single Key Mode829377
-Node: TUI Commands830252
-Node: TUI Configuration832636
-Node: Emacs833932
-Node: GDB/MI839409
-Node: GDB/MI General Design841257
-Node: Context management843780
-Node: Asynchronous and non-stop modes846915
-Node: Thread groups848907
-Node: GDB/MI Command Syntax851185
-Node: GDB/MI Input Syntax851428
-Node: GDB/MI Output Syntax852982
-Node: GDB/MI Compatibility with CLI856554
-Node: GDB/MI Development and Front Ends857291
-Node: GDB/MI Output Records858948
-Node: GDB/MI Result Records859320
-Node: GDB/MI Stream Records860326
-Node: GDB/MI Async Records861591
-Node: GDB/MI Frame Information867888
-Node: GDB/MI Thread Information868966
-Node: GDB/MI Ada Exception Information869945
-Node: GDB/MI Simple Examples870368
-Node: GDB/MI Command Description Format872545
-Node: GDB/MI Breakpoint Commands873425
-Node: GDB/MI Program Context891421
-Node: GDB/MI Thread Commands895689
-Node: GDB/MI Program Execution899642
-Node: GDB/MI Stack Manipulation911423
-Node: GDB/MI Variable Objects922325
-Ref: -var-set-format932057
-Ref: -var-list-children933175
-Ref: -var-update941352
-Ref: -var-set-frozen944049
-Ref: -var-set-update-range944845
-Ref: -var-set-visualizer945375
-Node: GDB/MI Data Manipulation946872
-Node: GDB/MI Tracepoint Commands964457
-Node: GDB/MI Symbol Query971786
-Node: GDB/MI File Commands972475
-Node: GDB/MI Target Manipulation975812
-Node: GDB/MI File Transfer Commands982034
-Node: GDB/MI Miscellaneous Commands983356
-Ref: -interpreter-exec992888
-Node: Annotations995197
-Node: Annotations Overview996116
-Node: Server Prefix998579
-Node: Prompting999313
-Node: Errors1000830
-Node: Invalidation1001726
-Node: Annotations for Running1002203
-Node: Source Annotations1003723
-Node: JIT Interface1004648
-Node: Declarations1006366
-Node: Registering Code1007753
-Node: Unregistering Code1008725
-Node: GDB Bugs1009326
-Node: Bug Criteria1010055
-Node: Bug Reporting1010932
-Node: Command Line Editing1018555
-Node: Introduction and Notation1019207
-Node: Readline Interaction1020827
-Node: Readline Bare Essentials1022016
-Node: Readline Movement Commands1023803
-Node: Readline Killing Commands1024766
-Node: Readline Arguments1026684
-Node: Searching1027726
-Node: Readline Init File1029875
-Node: Readline Init File Syntax1030938
-Node: Conditional Init Constructs1042870
-Node: Sample Init File1045401
-Node: Bindable Readline Commands1048516
-Node: Commands For Moving1049571
-Node: Commands For History1050430
-Node: Commands For Text1053552
-Node: Commands For Killing1056276
-Node: Numeric Arguments1058416
-Node: Commands For Completion1059553
-Node: Keyboard Macros1061095
-Node: Miscellaneous Commands1061664
-Node: Readline vi Mode1065023
-Node: Using History Interactively1065940
-Node: History Interaction1066442
-Node: Event Designators1067864
-Node: Word Designators1068797
-Node: Modifiers1070434
-Node: In Memoriam1071659
-Node: Formatting Documentation1072542
-Ref: Formatting Documentation-Footnote-11075879
-Node: Installing GDB1075955
-Node: Requirements1076527
-Ref: Expat1077096
-Node: Running Configure1079541
-Node: Separate Objdir1083170
-Node: Config Names1086090
-Node: Configure Options1087547
-Node: System-wide configuration1089917
-Node: Maintenance Commands1091212
-Ref: maint info breakpoints1092396
-Node: Remote Protocol1106431
-Node: Overview1107020
-Ref: Binary Data1109582
-Node: Packets1111841
-Ref: thread-id syntax1112741
-Ref: extended mode1114186
-Ref: bc1115907
-Ref: bs1116117
-Ref: read registers packet1117543
-Ref: cycle step packet1119387
-Ref: write register packet1121263
-Ref: step with signal packet1122170
-Ref: vStopped packet1128451
-Ref: X packet1128794
-Ref: insert breakpoint or watchpoint packet1129080
-Node: Stop Reply Packets1131842
-Node: General Query Packets1136582
-Ref: QNonStop1145522
-Ref: QPassSignals1146146
-Ref: qSearch memory1148223
-Ref: QStartNoAckMode1148721
-Ref: qSupported1149251
-Ref: multiprocess extensions1158193
-Ref: qXfer read1162023
-Ref: qXfer auxiliary vector read1162517
-Ref: qXfer target description read1162866
-Ref: qXfer library list read1163310
-Ref: qXfer memory map read1163956
-Ref: qXfer sdata read1164342
-Ref: qXfer siginfo read1164806
-Ref: qXfer spu read1165202
-Ref: qXfer threads read1165725
-Ref: qXfer traceframe info read1166127
-Ref: qXfer osdata read1166544
-Ref: qXfer write1167746
-Ref: qXfer siginfo write1168303
-Ref: qXfer spu write1168699
-Ref: General Query Packets-Footnote-11170786
-Node: Architecture-Specific Protocol Details1171113
-Node: Tracepoint Packets1172626
-Node: Host I/O Packets1189073
-Node: Interrupts1193215
-Node: Notification Packets1195118
-Node: Remote Non-Stop1197389
-Node: Packet Acknowledgment1201648
-Node: Examples1203763
-Node: File-I/O Remote Protocol Extension1204389
-Node: File-I/O Overview1204851
-Node: Protocol Basics1207048
-Node: The F Request Packet1209280
-Node: The F Reply Packet1210181
-Node: The Ctrl-C Message1211099
-Node: Console I/O1212728
-Node: List of Supported Calls1213945
-Node: open1214307
-Node: close1216801
-Node: read1217183
-Node: write1217790
-Node: lseek1218557
-Node: rename1219435
-Node: unlink1220831
-Node: stat/fstat1221770
-Node: gettimeofday1222657
-Node: isatty1223092
-Node: system1223688
-Node: Protocol-specific Representation of Datatypes1225230
-Node: Integral Datatypes1225607
-Node: Pointer Values1226414
-Node: Memory Transfer1227122
-Node: struct stat1227742
-Node: struct timeval1229944
-Node: Constants1230461
-Node: Open Flags1230910
-Node: mode_t Values1231251
-Node: Errno Values1231743
-Node: Lseek Flags1232554
-Node: Limits1232739
-Node: File-I/O Examples1233099
-Node: Library List Format1234215
-Node: Memory Map Format1236979
-Node: Thread List Format1239539
-Node: Traceframe Info Format1240357
-Node: Agent Expressions1241814
-Node: General Bytecode Design1244635
-Node: Bytecode Descriptions1249435
-Node: Using Agent Expressions1261581
-Node: Varying Target Capabilities1263559
-Node: Rationale1264721
-Node: Target Descriptions1272107
-Node: Retrieving Descriptions1274167
-Node: Target Description Format1275252
-Node: Predefined Target Types1284302
-Node: Standard Target Features1285687
-Node: ARM Features1287458
-Node: i386 Features1288950
-Node: MIPS Features1290054
-Node: M68K Features1290999
-Node: PowerPC Features1291662
-Node: Operating System Information1292946
-Node: Process list1293784
-Node: Trace File Format1294846
-Node: Copying1296827
-Node: GNU Free Documentation License1334414
-Node: Index1359572
-
-End Tag Table
diff --git a/share/info/gdbint.info b/share/info/gdbint.info
deleted file mode 100644
index fc4a25a..0000000
--- a/share/info/gdbint.info
+++ /dev/null
@@ -1,8855 +0,0 @@
-This is gdbint.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gdb/gdb-7.3.x/gdb/doc/gdbint.texinfo.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* Gdb-Internals: (gdbint). The GNU debugger's internals.
-END-INFO-DIR-ENTRY
-
- Copyright (C) 1990, 1991, 1992, 1993, 1994, 1996, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2008, 2009, 2010, 2011 Free
-Software Foundation, Inc. Contributed by Cygnus Solutions. Written by
-John Gilmore. Second Edition by Stan Shebs.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
- This file documents the internals of the GNU debugger GDB.
-
- Copyright (C) 1990, 1991, 1992, 1993, 1994, 1996, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2008, 2009, 2010, 2011 Free
-Software Foundation, Inc. Contributed by Cygnus Solutions. Written by
-John Gilmore. Second Edition by Stan Shebs.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
-
-File: gdbint.info, Node: Top, Next: Summary, Up: (dir)
-
-Scope of this Document
-**********************
-
-This document documents the internals of the GNU debugger, GDB. It
-includes description of GDB's key algorithms and operations, as well as
-the mechanisms that adapt GDB to specific hosts and targets.
-
-* Menu:
-
-* Summary::
-* Overall Structure::
-* Algorithms::
-* User Interface::
-* libgdb::
-* Values::
-* Stack Frames::
-* Symbol Handling::
-* Language Support::
-* Host Definition::
-* Target Architecture Definition::
-* Target Descriptions::
-* Target Vector Definition::
-* Native Debugging::
-* Support Libraries::
-* Coding Standards::
-* Misc Guidelines::
-* Porting GDB::
-* Versions and Branches::
-* Start of New Year Procedure::
-* Releasing GDB::
-* Testsuite::
-* Hints::
-
-* GDB Observers:: GDB Currently available observers
-* GNU Free Documentation License:: The license for this documentation
-* Index::
-
-
-File: gdbint.info, Node: Summary, Next: Overall Structure, Prev: Top, Up: Top
-
-1 Summary
-*********
-
-* Menu:
-
-* Requirements::
-* Contributors::
-
-
-File: gdbint.info, Node: Requirements, Next: Contributors, Up: Summary
-
-1.1 Requirements
-================
-
-Before diving into the internals, you should understand the formal
-requirements and other expectations for GDB. Although some of these
-may seem obvious, there have been proposals for GDB that have run
-counter to these requirements.
-
- First of all, GDB is a debugger. It's not designed to be a front
-panel for embedded systems. It's not a text editor. It's not a shell.
-It's not a programming environment.
-
- GDB is an interactive tool. Although a batch mode is available,
-GDB's primary role is to interact with a human programmer.
-
- GDB should be responsive to the user. A programmer hot on the trail
-of a nasty bug, and operating under a looming deadline, is going to be
-very impatient of everything, including the response time to debugger
-commands.
-
- GDB should be relatively permissive, such as for expressions. While
-the compiler should be picky (or have the option to be made picky),
-since source code lives for a long time usually, the programmer doing
-debugging shouldn't be spending time figuring out to mollify the
-debugger.
-
- GDB will be called upon to deal with really large programs.
-Executable sizes of 50 to 100 megabytes occur regularly, and we've
-heard reports of programs approaching 1 gigabyte in size.
-
- GDB should be able to run everywhere. No other debugger is
-available for even half as many configurations as GDB supports.
-
-
-File: gdbint.info, Node: Contributors, Prev: Requirements, Up: Summary
-
-1.2 Contributors
-================
-
-The first edition of this document was written by John Gilmore of
-Cygnus Solutions. The current second edition was written by Stan Shebs
-of Cygnus Solutions, who continues to update the manual.
-
- Over the years, many others have made additions and changes to this
-document. This section attempts to record the significant contributors
-to that effort. One of the virtues of free software is that everyone is
-free to contribute to it; with regret, we cannot actually acknowledge
-everyone here.
-
- _Plea:_ This section has only been added relatively recently (four
- years after publication of the second edition). Additions to this
- section are particularly welcome. If you or your friends (or
- enemies, to be evenhanded) have been unfairly omitted from this
- list, we would like to add your names!
-
- A document such as this relies on being kept up to date by numerous
-small updates by contributing engineers as they make changes to the
-code base. The file `ChangeLog' in the GDB distribution approximates a
-blow-by-blow account. The most prolific contributors to this important,
-but low profile task are Andrew Cagney (responsible for over half the
-entries), Daniel Jacobowitz, Mark Kettenis, Jim Blandy and Eli
-Zaretskii.
-
- Eli Zaretskii and Daniel Jacobowitz wrote the sections documenting
-watchpoints.
-
- Jeremy Bennett updated the sections on initializing a new
-architecture and register representation, and added the section on
-Frame Interpretation.
-
-
-File: gdbint.info, Node: Overall Structure, Next: Algorithms, Prev: Summary, Up: Top
-
-2 Overall Structure
-*******************
-
-GDB consists of three major subsystems: user interface, symbol handling
-(the "symbol side"), and target system handling (the "target side").
-
- The user interface consists of several actual interfaces, plus
-supporting code.
-
- The symbol side consists of object file readers, debugging info
-interpreters, symbol table management, source language expression
-parsing, type and value printing.
-
- The target side consists of execution control, stack frame analysis,
-and physical target manipulation.
-
- The target side/symbol side division is not formal, and there are a
-number of exceptions. For instance, core file support involves symbolic
-elements (the basic core file reader is in BFD) and target elements (it
-supplies the contents of memory and the values of registers). Instead,
-this division is useful for understanding how the minor subsystems
-should fit together.
-
-2.1 The Symbol Side
-===================
-
-The symbolic side of GDB can be thought of as "everything you can do in
-GDB without having a live program running". For instance, you can look
-at the types of variables, and evaluate many kinds of expressions.
-
-2.2 The Target Side
-===================
-
-The target side of GDB is the "bits and bytes manipulator". Although
-it may make reference to symbolic info here and there, most of the
-target side will run with only a stripped executable available--or even
-no executable at all, in remote debugging cases.
-
- Operations such as disassembly, stack frame crawls, and register
-display, are able to work with no symbolic info at all. In some cases,
-such as disassembly, GDB will use symbolic info to present addresses
-relative to symbols rather than as raw numbers, but it will work either
-way.
-
-2.3 Configurations
-==================
-
-"Host" refers to attributes of the system where GDB runs. "Target"
-refers to the system where the program being debugged executes. In
-most cases they are the same machine, in which case a third type of
-"Native" attributes come into play.
-
- Defines and include files needed to build on the host are host
-support. Examples are tty support, system defined types, host byte
-order, host float format. These are all calculated by `autoconf' when
-the debugger is built.
-
- Defines and information needed to handle the target format are target
-dependent. Examples are the stack frame format, instruction set,
-breakpoint instruction, registers, and how to set up and tear down the
-stack to call a function.
-
- Information that is only needed when the host and target are the
-same, is native dependent. One example is Unix child process support;
-if the host and target are not the same, calling `fork' to start the
-target process is a bad idea. The various macros needed for finding the
-registers in the `upage', running `ptrace', and such are all in the
-native-dependent files.
-
- Another example of native-dependent code is support for features that
-are really part of the target environment, but which require `#include'
-files that are only available on the host system. Core file handling
-and `setjmp' handling are two common cases.
-
- When you want to make GDB work as the traditional native debugger on
-a system, you will need to supply both target and native information.
-
-2.4 Source Tree Structure
-=========================
-
-The GDB source directory has a mostly flat structure--there are only a
-few subdirectories. A file's name usually gives a hint as to what it
-does; for example, `stabsread.c' reads stabs, `dwarf2read.c' reads
-DWARF 2, etc.
-
- Files that are related to some common task have names that share
-common substrings. For example, `*-thread.c' files deal with debugging
-threads on various platforms; `*read.c' files deal with reading various
-kinds of symbol and object files; `inf*.c' files deal with direct
-control of the "inferior program" (GDB parlance for the program being
-debugged).
-
- There are several dozens of files in the `*-tdep.c' family. `tdep'
-stands for "target-dependent code"--each of these files implements
-debug support for a specific target architecture (sparc, mips, etc).
-Usually, only one of these will be used in a specific GDB configuration
-(sometimes two, closely related).
-
- Similarly, there are many `*-nat.c' files, each one for native
-debugging on a specific system (e.g., `sparc-linux-nat.c' is for native
-debugging of Sparc machines running the Linux kernel).
-
- The few subdirectories of the source tree are:
-
-`cli'
- Code that implements "CLI", the GDB Command-Line Interpreter.
- *Note Command Interpreter: User Interface.
-
-`gdbserver'
- Code for the GDB remote server.
-
-`gdbtk'
- Code for Insight, the GDB TK-based GUI front-end.
-
-`mi'
- The "GDB/MI", the GDB Machine Interface interpreter.
-
-`signals'
- Target signal translation code.
-
-`tui'
- Code for "TUI", the GDB Text-mode full-screen User Interface.
- *Note TUI: User Interface.
-
-
-File: gdbint.info, Node: Algorithms, Next: User Interface, Prev: Overall Structure, Up: Top
-
-3 Algorithms
-************
-
-GDB uses a number of debugging-specific algorithms. They are often not
-very complicated, but get lost in the thicket of special cases and
-real-world issues. This chapter describes the basic algorithms and
-mentions some of the specific target definitions that they use.
-
-3.1 Prologue Analysis
-=====================
-
-To produce a backtrace and allow the user to manipulate older frames'
-variables and arguments, GDB needs to find the base addresses of older
-frames, and discover where those frames' registers have been saved.
-Since a frame's "callee-saves" registers get saved by younger frames if
-and when they're reused, a frame's registers may be scattered
-unpredictably across younger frames. This means that changing the
-value of a register-allocated variable in an older frame may actually
-entail writing to a save slot in some younger frame.
-
- Modern versions of GCC emit Dwarf call frame information ("CFI"),
-which describes how to find frame base addresses and saved registers.
-But CFI is not always available, so as a fallback GDB uses a technique
-called "prologue analysis" to find frame sizes and saved registers. A
-prologue analyzer disassembles the function's machine code starting
-from its entry point, and looks for instructions that allocate frame
-space, save the stack pointer in a frame pointer register, save
-registers, and so on. Obviously, this can't be done accurately in
-general, but it's tractable to do well enough to be very helpful.
-Prologue analysis predates the GNU toolchain's support for CFI; at one
-time, prologue analysis was the only mechanism GDB used for stack
-unwinding at all, when the function calling conventions didn't specify
-a fixed frame layout.
-
- In the olden days, function prologues were generated by hand-written,
-target-specific code in GCC, and treated as opaque and untouchable by
-optimizers. Looking at this code, it was usually straightforward to
-write a prologue analyzer for GDB that would accurately understand all
-the prologues GCC would generate. However, over time GCC became more
-aggressive about instruction scheduling, and began to understand more
-about the semantics of the prologue instructions themselves; in
-response, GDB's analyzers became more complex and fragile. Keeping the
-prologue analyzers working as GCC (and the instruction sets themselves)
-evolved became a substantial task.
-
- To try to address this problem, the code in `prologue-value.h' and
-`prologue-value.c' provides a general framework for writing prologue
-analyzers that are simpler and more robust than ad-hoc analyzers. When
-we analyze a prologue using the prologue-value framework, we're really
-doing "abstract interpretation" or "pseudo-evaluation": running the
-function's code in simulation, but using conservative approximations of
-the values registers and memory would hold when the code actually runs.
-For example, if our function starts with the instruction:
-
- addi r1, 42 # add 42 to r1
- we don't know exactly what value will be in `r1' after executing
-this instruction, but we do know it'll be 42 greater than its original
-value.
-
- If we then see an instruction like:
-
- addi r1, 22 # add 22 to r1
- we still don't know what `r1's' value is, but again, we can say it
-is now 64 greater than its original value.
-
- If the next instruction were:
-
- mov r2, r1 # set r2 to r1's value
- then we can say that `r2's' value is now the original value of `r1'
-plus 64.
-
- It's common for prologues to save registers on the stack, so we'll
-need to track the values of stack frame slots, as well as the
-registers. So after an instruction like this:
-
- mov (fp+4), r2
- then we'd know that the stack slot four bytes above the frame pointer
-holds the original value of `r1' plus 64.
-
- And so on.
-
- Of course, this can only go so far before it gets unreasonable. If
-we wanted to be able to say anything about the value of `r1' after the
-instruction:
-
- xor r1, r3 # exclusive-or r1 and r3, place result in r1
- then things would get pretty complex. But remember, we're just doing
-a conservative approximation; if exclusive-or instructions aren't
-relevant to prologues, we can just say `r1''s value is now "unknown".
-We can ignore things that are too complex, if that loss of information
-is acceptable for our application.
-
- So when we say "conservative approximation" here, what we mean is an
-approximation that is either accurate, or marked "unknown", but never
-inaccurate.
-
- Using this framework, a prologue analyzer is simply an interpreter
-for machine code, but one that uses conservative approximations for the
-contents of registers and memory instead of actual values. Starting
-from the function's entry point, you simulate instructions up to the
-current PC, or an instruction that you don't know how to simulate. Now
-you can examine the state of the registers and stack slots you've kept
-track of.
-
- * To see how large your stack frame is, just check the value of the
- stack pointer register; if it's the original value of the SP minus
- a constant, then that constant is the stack frame's size. If the
- SP's value has been marked as "unknown", then that means the
- prologue has done something too complex for us to track, and we
- don't know the frame size.
-
- * To see where we've saved the previous frame's registers, we just
- search the values we've tracked -- stack slots, usually, but
- registers, too, if you want -- for something equal to the
- register's original value. If the calling conventions suggest a
- standard place to save a given register, then we can check there
- first, but really, anything that will get us back the original
- value will probably work.
-
- This does take some work. But prologue analyzers aren't
-quick-and-simple pattern patching to recognize a few fixed prologue
-forms any more; they're big, hairy functions. Along with inferior
-function calls, prologue analysis accounts for a substantial portion of
-the time needed to stabilize a GDB port. So it's worthwhile to look
-for an approach that will be easier to understand and maintain. In the
-approach described above:
-
- * It's easier to see that the analyzer is correct: you just see
- whether the analyzer properly (albeit conservatively) simulates
- the effect of each instruction.
-
- * It's easier to extend the analyzer: you can add support for new
- instructions, and know that you haven't broken anything that
- wasn't already broken before.
-
- * It's orthogonal: to gather new information, you don't need to
- complicate the code for each instruction. As long as your domain
- of conservative values is already detailed enough to tell you what
- you need, then all the existing instruction simulations are
- already gathering the right data for you.
-
-
- The file `prologue-value.h' contains detailed comments explaining
-the framework and how to use it.
-
-3.2 Breakpoint Handling
-=======================
-
-In general, a breakpoint is a user-designated location in the program
-where the user wants to regain control if program execution ever reaches
-that location.
-
- There are two main ways to implement breakpoints; either as
-"hardware" breakpoints or as "software" breakpoints.
-
- Hardware breakpoints are sometimes available as a builtin debugging
-features with some chips. Typically these work by having dedicated
-register into which the breakpoint address may be stored. If the PC
-(shorthand for "program counter") ever matches a value in a breakpoint
-registers, the CPU raises an exception and reports it to GDB.
-
- Another possibility is when an emulator is in use; many emulators
-include circuitry that watches the address lines coming out from the
-processor, and force it to stop if the address matches a breakpoint's
-address.
-
- A third possibility is that the target already has the ability to do
-breakpoints somehow; for instance, a ROM monitor may do its own
-software breakpoints. So although these are not literally "hardware
-breakpoints", from GDB's point of view they work the same; GDB need not
-do anything more than set the breakpoint and wait for something to
-happen.
-
- Since they depend on hardware resources, hardware breakpoints may be
-limited in number; when the user asks for more, GDB will start trying
-to set software breakpoints. (On some architectures, notably the
-32-bit x86 platforms, GDB cannot always know whether there's enough
-hardware resources to insert all the hardware breakpoints and
-watchpoints. On those platforms, GDB prints an error message only when
-the program being debugged is continued.)
-
- Software breakpoints require GDB to do somewhat more work. The
-basic theory is that GDB will replace a program instruction with a
-trap, illegal divide, or some other instruction that will cause an
-exception, and then when it's encountered, GDB will take the exception
-and stop the program. When the user says to continue, GDB will restore
-the original instruction, single-step, re-insert the trap, and continue
-on.
-
- Since it literally overwrites the program being tested, the program
-area must be writable, so this technique won't work on programs in ROM.
-It can also distort the behavior of programs that examine themselves,
-although such a situation would be highly unusual.
-
- Also, the software breakpoint instruction should be the smallest
-size of instruction, so it doesn't overwrite an instruction that might
-be a jump target, and cause disaster when the program jumps into the
-middle of the breakpoint instruction. (Strictly speaking, the
-breakpoint must be no larger than the smallest interval between
-instructions that may be jump targets; perhaps there is an architecture
-where only even-numbered instructions may jumped to.) Note that it's
-possible for an instruction set not to have any instructions usable for
-a software breakpoint, although in practice only the ARC has failed to
-define such an instruction.
-
- Basic breakpoint object handling is in `breakpoint.c'. However,
-much of the interesting breakpoint action is in `infrun.c'.
-
-`target_remove_breakpoint (BP_TGT)'
-`target_insert_breakpoint (BP_TGT)'
- Insert or remove a software breakpoint at address
- `BP_TGT->placed_address'. Returns zero for success, non-zero for
- failure. On input, BP_TGT contains the address of the breakpoint,
- and is otherwise initialized to zero. The fields of the `struct
- bp_target_info' pointed to by BP_TGT are updated to contain other
- information about the breakpoint on output. The field
- `placed_address' may be updated if the breakpoint was placed at a
- related address; the field `shadow_contents' contains the real
- contents of the bytes where the breakpoint has been inserted, if
- reading memory would return the breakpoint instead of the
- underlying memory; the field `shadow_len' is the length of memory
- cached in `shadow_contents', if any; and the field `placed_size'
- is optionally set and used by the target, if it could differ from
- `shadow_len'.
-
- For example, the remote target `Z0' packet does not require
- shadowing memory, so `shadow_len' is left at zero. However, the
- length reported by `gdbarch_breakpoint_from_pc' is cached in
- `placed_size', so that a matching `z0' packet can be used to
- remove the breakpoint.
-
-`target_remove_hw_breakpoint (BP_TGT)'
-`target_insert_hw_breakpoint (BP_TGT)'
- Insert or remove a hardware-assisted breakpoint at address
- `BP_TGT->placed_address'. Returns zero for success, non-zero for
- failure. See `target_insert_breakpoint' for a description of the
- `struct bp_target_info' pointed to by BP_TGT; the
- `shadow_contents' and `shadow_len' members are not used for
- hardware breakpoints, but `placed_size' may be.
-
-3.3 Single Stepping
-===================
-
-3.4 Signal Handling
-===================
-
-3.5 Thread Handling
-===================
-
-3.6 Inferior Function Calls
-===========================
-
-3.7 Longjmp Support
-===================
-
-GDB has support for figuring out that the target is doing a `longjmp'
-and for stopping at the target of the jump, if we are stepping. This
-is done with a few specialized internal breakpoints, which are visible
-in the output of the `maint info breakpoint' command.
-
- To make this work, you need to define a function called
-`gdbarch_get_longjmp_target', which will examine the `jmp_buf'
-structure and extract the `longjmp' target address. Since `jmp_buf' is
-target specific and typically defined in a target header not available
-to GDB, you will need to determine the offset of the PC manually and
-return that; many targets define a `jb_pc_offset' field in the tdep
-structure to save the value once calculated.
-
-3.8 Watchpoints
-===============
-
-Watchpoints are a special kind of breakpoints (*note breakpoints:
-Algorithms.) which break when data is accessed rather than when some
-instruction is executed. When you have data which changes without your
-knowing what code does that, watchpoints are the silver bullet to hunt
-down and kill such bugs.
-
- Watchpoints can be either hardware-assisted or not; the latter type
-is known as "software watchpoints." GDB always uses hardware-assisted
-watchpoints if they are available, and falls back on software
-watchpoints otherwise. Typical situations where GDB will use software
-watchpoints are:
-
- * The watched memory region is too large for the underlying hardware
- watchpoint support. For example, each x86 debug register can
- watch up to 4 bytes of memory, so trying to watch data structures
- whose size is more than 16 bytes will cause GDB to use software
- watchpoints.
-
- * The value of the expression to be watched depends on data held in
- registers (as opposed to memory).
-
- * Too many different watchpoints requested. (On some architectures,
- this situation is impossible to detect until the debugged program
- is resumed.) Note that x86 debug registers are used both for
- hardware breakpoints and for watchpoints, so setting too many
- hardware breakpoints might cause watchpoint insertion to fail.
-
- * No hardware-assisted watchpoints provided by the target
- implementation.
-
- Software watchpoints are very slow, since GDB needs to single-step
-the program being debugged and test the value of the watched
-expression(s) after each instruction. The rest of this section is
-mostly irrelevant for software watchpoints.
-
- When the inferior stops, GDB tries to establish, among other
-possible reasons, whether it stopped due to a watchpoint being hit. It
-first uses `STOPPED_BY_WATCHPOINT' to see if any watchpoint was hit.
-If not, all watchpoint checking is skipped.
-
- Then GDB calls `target_stopped_data_address' exactly once. This
-method returns the address of the watchpoint which triggered, if the
-target can determine it. If the triggered address is available, GDB
-compares the address returned by this method with each watched memory
-address in each active watchpoint. For data-read and data-access
-watchpoints, GDB announces every watchpoint that watches the triggered
-address as being hit. For this reason, data-read and data-access
-watchpoints _require_ that the triggered address be available; if not,
-read and access watchpoints will never be considered hit. For
-data-write watchpoints, if the triggered address is available, GDB
-considers only those watchpoints which match that address; otherwise,
-GDB considers all data-write watchpoints. For each data-write
-watchpoint that GDB considers, it evaluates the expression whose value
-is being watched, and tests whether the watched value has changed.
-Watchpoints whose watched values have changed are announced as hit.
-
- GDB uses several macros and primitives to support hardware
-watchpoints:
-
-`TARGET_CAN_USE_HARDWARE_WATCHPOINT (TYPE, COUNT, OTHER)'
- Return the number of hardware watchpoints of type TYPE that are
- possible to be set. The value is positive if COUNT watchpoints of
- this type can be set, zero if setting watchpoints of this type is
- not supported, and negative if COUNT is more than the maximum
- number of watchpoints of type TYPE that can be set. OTHER is
- non-zero if other types of watchpoints are currently enabled (there
- are architectures which cannot set watchpoints of different types
- at the same time).
-
-`TARGET_REGION_OK_FOR_HW_WATCHPOINT (ADDR, LEN)'
- Return non-zero if hardware watchpoints can be used to watch a
- region whose address is ADDR and whose length in bytes is LEN.
-
-`target_insert_watchpoint (ADDR, LEN, TYPE)'
-`target_remove_watchpoint (ADDR, LEN, TYPE)'
- Insert or remove a hardware watchpoint starting at ADDR, for LEN
- bytes. TYPE is the watchpoint type, one of the possible values of
- the enumerated data type `target_hw_bp_type', defined by
- `breakpoint.h' as follows:
-
- enum target_hw_bp_type
- {
- hw_write = 0, /* Common (write) HW watchpoint */
- hw_read = 1, /* Read HW watchpoint */
- hw_access = 2, /* Access (read or write) HW watchpoint */
- hw_execute = 3 /* Execute HW breakpoint */
- };
-
- These two macros should return 0 for success, non-zero for failure.
-
-`target_stopped_data_address (ADDR_P)'
- If the inferior has some watchpoint that triggered, place the
- address associated with the watchpoint at the location pointed to
- by ADDR_P and return non-zero. Otherwise, return zero. This is
- required for data-read and data-access watchpoints. It is not
- required for data-write watchpoints, but GDB uses it to improve
- handling of those also.
-
- GDB will only call this method once per watchpoint stop,
- immediately after calling `STOPPED_BY_WATCHPOINT'. If the
- target's watchpoint indication is sticky, i.e., stays set after
- resuming, this method should clear it. For instance, the x86 debug
- control register has sticky triggered flags.
-
-`target_watchpoint_addr_within_range (TARGET, ADDR, START, LENGTH)'
- Check whether ADDR (as returned by `target_stopped_data_address')
- lies within the hardware-defined watchpoint region described by
- START and LENGTH. This only needs to be provided if the
- granularity of a watchpoint is greater than one byte, i.e., if the
- watchpoint can also trigger on nearby addresses outside of the
- watched region.
-
-`HAVE_STEPPABLE_WATCHPOINT'
- If defined to a non-zero value, it is not necessary to disable a
- watchpoint to step over it. Like
- `gdbarch_have_nonsteppable_watchpoint', this is usually set when
- watchpoints trigger at the instruction which will perform an
- interesting read or write. It should be set if there is a
- temporary disable bit which allows the processor to step over the
- interesting instruction without raising the watchpoint exception
- again.
-
-`int gdbarch_have_nonsteppable_watchpoint (GDBARCH)'
- If it returns a non-zero value, GDB should disable a watchpoint to
- step the inferior over it. This is usually set when watchpoints
- trigger at the instruction which will perform an interesting read
- or write.
-
-`HAVE_CONTINUABLE_WATCHPOINT'
- If defined to a non-zero value, it is possible to continue the
- inferior after a watchpoint has been hit. This is usually set
- when watchpoints trigger at the instruction following an
- interesting read or write.
-
-`STOPPED_BY_WATCHPOINT (WAIT_STATUS)'
- Return non-zero if stopped by a watchpoint. WAIT_STATUS is of the
- type `struct target_waitstatus', defined by `target.h'. Normally,
- this macro is defined to invoke the function pointed to by the
- `to_stopped_by_watchpoint' member of the structure (of the type
- `target_ops', defined on `target.h') that describes the
- target-specific operations; `to_stopped_by_watchpoint' ignores the
- WAIT_STATUS argument.
-
- GDB does not require the non-zero value returned by
- `STOPPED_BY_WATCHPOINT' to be 100% correct, so if a target cannot
- determine for sure whether the inferior stopped due to a
- watchpoint, it could return non-zero "just in case".
-
-3.8.1 Watchpoints and Threads
------------------------------
-
-GDB only supports process-wide watchpoints, which trigger in all
-threads. GDB uses the thread ID to make watchpoints act as if they
-were thread-specific, but it cannot set hardware watchpoints that only
-trigger in a specific thread. Therefore, even if the target supports
-threads, per-thread debug registers, and watchpoints which only affect
-a single thread, it should set the per-thread debug registers for all
-threads to the same value. On GNU/Linux native targets, this is
-accomplished by using `ALL_LWPS' in `target_insert_watchpoint' and
-`target_remove_watchpoint' and by using `linux_set_new_thread' to
-register a handler for newly created threads.
-
- GDB's GNU/Linux support only reports a single event at a time,
-although multiple events can trigger simultaneously for multi-threaded
-programs. When multiple events occur, `linux-nat.c' queues subsequent
-events and returns them the next time the program is resumed. This
-means that `STOPPED_BY_WATCHPOINT' and `target_stopped_data_address'
-only need to consult the current thread's state--the thread indicated
-by `inferior_ptid'. If two threads have hit watchpoints
-simultaneously, those routines will be called a second time for the
-second thread.
-
-3.8.2 x86 Watchpoints
----------------------
-
-The 32-bit Intel x86 (a.k.a. ia32) processors feature special debug
-registers designed to facilitate debugging. GDB provides a generic
-library of functions that x86-based ports can use to implement support
-for watchpoints and hardware-assisted breakpoints. This subsection
-documents the x86 watchpoint facilities in GDB.
-
- (At present, the library functions read and write debug registers
-directly, and are thus only available for native configurations.)
-
- To use the generic x86 watchpoint support, a port should do the
-following:
-
- * Define the macro `I386_USE_GENERIC_WATCHPOINTS' somewhere in the
- target-dependent headers.
-
- * Include the `config/i386/nm-i386.h' header file _after_ defining
- `I386_USE_GENERIC_WATCHPOINTS'.
-
- * Add `i386-nat.o' to the value of the Make variable `NATDEPFILES'
- (*note NATDEPFILES: Native Debugging.).
-
- * Provide implementations for the `I386_DR_LOW_*' macros described
- below. Typically, each macro should call a target-specific
- function which does the real work.
-
- The x86 watchpoint support works by maintaining mirror images of the
-debug registers. Values are copied between the mirror images and the
-real debug registers via a set of macros which each target needs to
-provide:
-
-`I386_DR_LOW_SET_CONTROL (VAL)'
- Set the Debug Control (DR7) register to the value VAL.
-
-`I386_DR_LOW_SET_ADDR (IDX, ADDR)'
- Put the address ADDR into the debug register number IDX.
-
-`I386_DR_LOW_RESET_ADDR (IDX)'
- Reset (i.e. zero out) the address stored in the debug register
- number IDX.
-
-`I386_DR_LOW_GET_STATUS'
- Return the value of the Debug Status (DR6) register. This value is
- used immediately after it is returned by `I386_DR_LOW_GET_STATUS',
- so as to support per-thread status register values.
-
- For each one of the 4 debug registers (whose indices are from 0 to 3)
-that store addresses, a reference count is maintained by GDB, to allow
-sharing of debug registers by several watchpoints. This allows users
-to define several watchpoints that watch the same expression, but with
-different conditions and/or commands, without wasting debug registers
-which are in short supply. GDB maintains the reference counts
-internally, targets don't have to do anything to use this feature.
-
- The x86 debug registers can each watch a region that is 1, 2, or 4
-bytes long. The ia32 architecture requires that each watched region be
-appropriately aligned: 2-byte region on 2-byte boundary, 4-byte region
-on 4-byte boundary. However, the x86 watchpoint support in GDB can
-watch unaligned regions and regions larger than 4 bytes (up to 16
-bytes) by allocating several debug registers to watch a single region.
-This allocation of several registers per a watched region is also done
-automatically without target code intervention.
-
- The generic x86 watchpoint support provides the following API for the
-GDB's application code:
-
-`i386_region_ok_for_watchpoint (ADDR, LEN)'
- The macro `TARGET_REGION_OK_FOR_HW_WATCHPOINT' is set to call this
- function. It counts the number of debug registers required to
- watch a given region, and returns a non-zero value if that number
- is less than 4, the number of debug registers available to x86
- processors.
-
-`i386_stopped_data_address (ADDR_P)'
- The target function `target_stopped_data_address' is set to call
- this function. This function examines the breakpoint condition
- bits in the DR6 Debug Status register, as returned by the
- `I386_DR_LOW_GET_STATUS' macro, and returns the address associated
- with the first bit that is set in DR6.
-
-`i386_stopped_by_watchpoint (void)'
- The macro `STOPPED_BY_WATCHPOINT' is set to call this function.
- The argument passed to `STOPPED_BY_WATCHPOINT' is ignored. This
- function examines the breakpoint condition bits in the DR6 Debug
- Status register, as returned by the `I386_DR_LOW_GET_STATUS'
- macro, and returns true if any bit is set. Otherwise, false is
- returned.
-
-`i386_insert_watchpoint (ADDR, LEN, TYPE)'
-`i386_remove_watchpoint (ADDR, LEN, TYPE)'
- Insert or remove a watchpoint. The macros
- `target_insert_watchpoint' and `target_remove_watchpoint' are set
- to call these functions. `i386_insert_watchpoint' first looks for
- a debug register which is already set to watch the same region for
- the same access types; if found, it just increments the reference
- count of that debug register, thus implementing debug register
- sharing between watchpoints. If no such register is found, the
- function looks for a vacant debug register, sets its mirrored
- value to ADDR, sets the mirrored value of DR7 Debug Control
- register as appropriate for the LEN and TYPE parameters, and then
- passes the new values of the debug register and DR7 to the
- inferior by calling `I386_DR_LOW_SET_ADDR' and
- `I386_DR_LOW_SET_CONTROL'. If more than one debug register is
- required to cover the given region, the above process is repeated
- for each debug register.
-
- `i386_remove_watchpoint' does the opposite: it resets the address
- in the mirrored value of the debug register and its read/write and
- length bits in the mirrored value of DR7, then passes these new
- values to the inferior via `I386_DR_LOW_RESET_ADDR' and
- `I386_DR_LOW_SET_CONTROL'. If a register is shared by several
- watchpoints, each time a `i386_remove_watchpoint' is called, it
- decrements the reference count, and only calls
- `I386_DR_LOW_RESET_ADDR' and `I386_DR_LOW_SET_CONTROL' when the
- count goes to zero.
-
-`i386_insert_hw_breakpoint (BP_TGT)'
-`i386_remove_hw_breakpoint (BP_TGT)'
- These functions insert and remove hardware-assisted breakpoints.
- The macros `target_insert_hw_breakpoint' and
- `target_remove_hw_breakpoint' are set to call these functions.
- The argument is a `struct bp_target_info *', as described in the
- documentation for `target_insert_breakpoint'. These functions
- work like `i386_insert_watchpoint' and `i386_remove_watchpoint',
- respectively, except that they set up the debug registers to watch
- instruction execution, and each hardware-assisted breakpoint
- always requires exactly one debug register.
-
-`i386_cleanup_dregs (void)'
- This function clears all the reference counts, addresses, and
- control bits in the mirror images of the debug registers. It
- doesn't affect the actual debug registers in the inferior process.
-
-*Notes:*
- 1. x86 processors support setting watchpoints on I/O reads or writes.
- However, since no target supports this (as of March 2001), and
- since `enum target_hw_bp_type' doesn't even have an enumeration
- for I/O watchpoints, this feature is not yet available to GDB
- running on x86.
-
- 2. x86 processors can enable watchpoints locally, for the current task
- only, or globally, for all the tasks. For each debug register,
- there's a bit in the DR7 Debug Control register that determines
- whether the associated address is watched locally or globally. The
- current implementation of x86 watchpoint support in GDB always
- sets watchpoints to be locally enabled, since global watchpoints
- might interfere with the underlying OS and are probably
- unavailable in many platforms.
-
-3.9 Checkpoints
-===============
-
-In the abstract, a checkpoint is a point in the execution history of
-the program, which the user may wish to return to at some later time.
-
- Internally, a checkpoint is a saved copy of the program state,
-including whatever information is required in order to restore the
-program to that state at a later time. This can be expected to include
-the state of registers and memory, and may include external state such
-as the state of open files and devices.
-
- There are a number of ways in which checkpoints may be implemented
-in gdb, e.g. as corefiles, as forked processes, and as some opaque
-method implemented on the target side.
-
- A corefile can be used to save an image of target memory and register
-state, which can in principle be restored later -- but corefiles do not
-typically include information about external entities such as open
-files. Currently this method is not implemented in gdb.
-
- A forked process can save the state of user memory and registers, as
-well as some subset of external (kernel) state. This method is used to
-implement checkpoints on Linux, and in principle might be used on other
-systems.
-
- Some targets, e.g. simulators, might have their own built-in method
-for saving checkpoints, and gdb might be able to take advantage of that
-capability without necessarily knowing any details of how it is done.
-
-3.10 Observing changes in GDB internals
-=======================================
-
-In order to function properly, several modules need to be notified when
-some changes occur in the GDB internals. Traditionally, these modules
-have relied on several paradigms, the most common ones being hooks and
-gdb-events. Unfortunately, none of these paradigms was versatile
-enough to become the standard notification mechanism in GDB. The fact
-that they only supported one "client" was also a strong limitation.
-
- A new paradigm, based on the Observer pattern of the `Design
-Patterns' book, has therefore been implemented. The goal was to provide
-a new interface overcoming the issues with the notification mechanisms
-previously available. This new interface needed to be strongly typed,
-easy to extend, and versatile enough to be used as the standard
-interface when adding new notifications.
-
- See *note GDB Observers:: for a brief description of the observers
-currently implemented in GDB. The rationale for the current
-implementation is also briefly discussed.
-
-
-File: gdbint.info, Node: User Interface, Next: libgdb, Prev: Algorithms, Up: Top
-
-4 User Interface
-****************
-
-GDB has several user interfaces, of which the traditional command-line
-interface is perhaps the most familiar.
-
-4.1 Command Interpreter
-=======================
-
-The command interpreter in GDB is fairly simple. It is designed to
-allow for the set of commands to be augmented dynamically, and also has
-a recursive subcommand capability, where the first argument to a
-command may itself direct a lookup on a different command list.
-
- For instance, the `set' command just starts a lookup on the
-`setlist' command list, while `set thread' recurses to the
-`set_thread_cmd_list'.
-
- To add commands in general, use `add_cmd'. `add_com' adds to the
-main command list, and should be used for those commands. The usual
-place to add commands is in the `_initialize_XYZ' routines at the ends
-of most source files.
-
- To add paired `set' and `show' commands, use `add_setshow_cmd' or
-`add_setshow_cmd_full'. The former is a slightly simpler interface
-which is useful when you don't need to further modify the new command
-structures, while the latter returns the new command structures for
-manipulation.
-
- Before removing commands from the command set it is a good idea to
-deprecate them for some time. Use `deprecate_cmd' on commands or
-aliases to set the deprecated flag. `deprecate_cmd' takes a `struct
-cmd_list_element' as it's first argument. You can use the return value
-from `add_com' or `add_cmd' to deprecate the command immediately after
-it is created.
-
- The first time a command is used the user will be warned and offered
-a replacement (if one exists). Note that the replacement string passed
-to `deprecate_cmd' should be the full name of the command, i.e., the
-entire string the user should type at the command line.
-
-4.2 UI-Independent Output--the `ui_out' Functions
-=================================================
-
-The `ui_out' functions present an abstraction level for the GDB output
-code. They hide the specifics of different user interfaces supported
-by GDB, and thus free the programmer from the need to write several
-versions of the same code, one each for every UI, to produce output.
-
-4.2.1 Overview and Terminology
-------------------------------
-
-In general, execution of each GDB command produces some sort of output,
-and can even generate an input request.
-
- Output can be generated for the following purposes:
-
- * to display a _result_ of an operation;
-
- * to convey _info_ or produce side-effects of a requested operation;
-
- * to provide a _notification_ of an asynchronous event (including
- progress indication of a prolonged asynchronous operation);
-
- * to display _error messages_ (including warnings);
-
- * to show _debug data_;
-
- * to _query_ or prompt a user for input (a special case).
-
-This section mainly concentrates on how to build result output,
-although some of it also applies to other kinds of output.
-
- Generation of output that displays the results of an operation
-involves one or more of the following:
-
- * output of the actual data
-
- * formatting the output as appropriate for console output, to make it
- easily readable by humans
-
- * machine oriented formatting-a more terse formatting to allow for
- easy parsing by programs which read GDB's output
-
- * annotation, whose purpose is to help legacy GUIs to identify
- interesting parts in the output
-
- The `ui_out' routines take care of the first three aspects.
-Annotations are provided by separate annotation routines. Note that use
-of annotations for an interface between a GUI and GDB is deprecated.
-
- Output can be in the form of a single item, which we call a "field";
-a "list" consisting of identical fields; a "tuple" consisting of
-non-identical fields; or a "table", which is a tuple consisting of a
-header and a body. In a BNF-like form:
-
-`<table> ==>'
- `<header> <body>'
-
-`<header> ==>'
- `{ <column> }'
-
-`<column> ==>'
- `<width> <alignment> <title>'
-
-`<body> ==>'
- `{<row>}'
-
-4.2.2 General Conventions
--------------------------
-
-Most `ui_out' routines are of type `void', the exceptions are
-`ui_out_stream_new' (which returns a pointer to the newly created
-object) and the `make_cleanup' routines.
-
- The first parameter is always the `ui_out' vector object, a pointer
-to a `struct ui_out'.
-
- The FORMAT parameter is like in `printf' family of functions. When
-it is present, there must also be a variable list of arguments
-sufficient used to satisfy the `%' specifiers in the supplied format.
-
- When a character string argument is not used in a `ui_out' function
-call, a `NULL' pointer has to be supplied instead.
-
-4.2.3 Table, Tuple and List Functions
--------------------------------------
-
-This section introduces `ui_out' routines for building lists, tuples
-and tables. The routines to output the actual data items (fields) are
-presented in the next section.
-
- To recap: A "tuple" is a sequence of "fields", each field containing
-information about an object; a "list" is a sequence of fields where
-each field describes an identical object.
-
- Use the "table" functions when your output consists of a list of
-rows (tuples) and the console output should include a heading. Use this
-even when you are listing just one object but you still want the header.
-
- Tables can not be nested. Tuples and lists can be nested up to a
-maximum of five levels.
-
- The overall structure of the table output code is something like
-this:
-
- ui_out_table_begin
- ui_out_table_header
- ...
- ui_out_table_body
- ui_out_tuple_begin
- ui_out_field_*
- ...
- ui_out_tuple_end
- ...
- ui_out_table_end
-
- Here is the description of table-, tuple- and list-related `ui_out'
-functions:
-
- -- Function: void ui_out_table_begin (struct ui_out *UIOUT, int
- NBROFCOLS, int NR_ROWS, const char *TBLID)
- The function `ui_out_table_begin' marks the beginning of the output
- of a table. It should always be called before any other `ui_out'
- function for a given table. NBROFCOLS is the number of columns in
- the table. NR_ROWS is the number of rows in the table. TBLID is
- an optional string identifying the table. The string pointed to
- by TBLID is copied by the implementation of `ui_out_table_begin',
- so the application can free the string if it was `malloc'ed.
-
- The companion function `ui_out_table_end', described below, marks
- the end of the table's output.
-
- -- Function: void ui_out_table_header (struct ui_out *UIOUT, int
- WIDTH, enum ui_align ALIGNMENT, const char *COLHDR)
- `ui_out_table_header' provides the header information for a single
- table column. You call this function several times, one each for
- every column of the table, after `ui_out_table_begin', but before
- `ui_out_table_body'.
-
- The value of WIDTH gives the column width in characters. The
- value of ALIGNMENT is one of `left', `center', and `right', and it
- specifies how to align the header: left-justify, center, or
- right-justify it. COLHDR points to a string that specifies the
- column header; the implementation copies that string, so column
- header strings in `malloc'ed storage can be freed after the call.
-
- -- Function: void ui_out_table_body (struct ui_out *UIOUT)
- This function delimits the table header from the table body.
-
- -- Function: void ui_out_table_end (struct ui_out *UIOUT)
- This function signals the end of a table's output. It should be
- called after the table body has been produced by the list and
- field output functions.
-
- There should be exactly one call to `ui_out_table_end' for each
- call to `ui_out_table_begin', otherwise the `ui_out' functions
- will signal an internal error.
-
- The output of the tuples that represent the table rows must follow
-the call to `ui_out_table_body' and precede the call to
-`ui_out_table_end'. You build a tuple by calling `ui_out_tuple_begin'
-and `ui_out_tuple_end', with suitable calls to functions which actually
-output fields between them.
-
- -- Function: void ui_out_tuple_begin (struct ui_out *UIOUT, const char
- *ID)
- This function marks the beginning of a tuple output. ID points to
- an optional string that identifies the tuple; it is copied by the
- implementation, and so strings in `malloc'ed storage can be freed
- after the call.
-
- -- Function: void ui_out_tuple_end (struct ui_out *UIOUT)
- This function signals an end of a tuple output. There should be
- exactly one call to `ui_out_tuple_end' for each call to
- `ui_out_tuple_begin', otherwise an internal GDB error will be
- signaled.
-
- -- Function: struct cleanup * make_cleanup_ui_out_tuple_begin_end
- (struct ui_out *UIOUT, const char *ID)
- This function first opens the tuple and then establishes a cleanup
- (*note Cleanups: Misc Guidelines.) to close the tuple. It
- provides a convenient and correct implementation of the
- non-portable(1) code sequence:
- struct cleanup *old_cleanup;
- ui_out_tuple_begin (uiout, "...");
- old_cleanup = make_cleanup ((void(*)(void *)) ui_out_tuple_end,
- uiout);
-
- -- Function: void ui_out_list_begin (struct ui_out *UIOUT, const char
- *ID)
- This function marks the beginning of a list output. ID points to
- an optional string that identifies the list; it is copied by the
- implementation, and so strings in `malloc'ed storage can be freed
- after the call.
-
- -- Function: void ui_out_list_end (struct ui_out *UIOUT)
- This function signals an end of a list output. There should be
- exactly one call to `ui_out_list_end' for each call to
- `ui_out_list_begin', otherwise an internal GDB error will be
- signaled.
-
- -- Function: struct cleanup * make_cleanup_ui_out_list_begin_end
- (struct ui_out *UIOUT, const char *ID)
- Similar to `make_cleanup_ui_out_tuple_begin_end', this function
- opens a list and then establishes cleanup (*note Cleanups: Misc
- Guidelines.) that will close the list.
-
-4.2.4 Item Output Functions
----------------------------
-
-The functions described below produce output for the actual data items,
-or fields, which contain information about the object.
-
- Choose the appropriate function accordingly to your particular needs.
-
- -- Function: void ui_out_field_fmt (struct ui_out *UIOUT, char
- *FLDNAME, char *FORMAT, ...)
- This is the most general output function. It produces the
- representation of the data in the variable-length argument list
- according to formatting specifications in FORMAT, a `printf'-like
- format string. The optional argument FLDNAME supplies the name of
- the field. The data items themselves are supplied as additional
- arguments after FORMAT.
-
- This generic function should be used only when it is not possible
- to use one of the specialized versions (see below).
-
- -- Function: void ui_out_field_int (struct ui_out *UIOUT, const char
- *FLDNAME, int VALUE)
- This function outputs a value of an `int' variable. It uses the
- `"%d"' output conversion specification. FLDNAME specifies the
- name of the field.
-
- -- Function: void ui_out_field_fmt_int (struct ui_out *UIOUT, int
- WIDTH, enum ui_align ALIGNMENT, const char *FLDNAME, int
- VALUE)
- This function outputs a value of an `int' variable. It differs
- from `ui_out_field_int' in that the caller specifies the desired
- WIDTH and ALIGNMENT of the output. FLDNAME specifies the name of
- the field.
-
- -- Function: void ui_out_field_core_addr (struct ui_out *UIOUT, const
- char *FLDNAME, struct gdbarch *GDBARCH, CORE_ADDR ADDRESS)
- This function outputs an address as appropriate for GDBARCH.
-
- -- Function: void ui_out_field_string (struct ui_out *UIOUT, const
- char *FLDNAME, const char *STRING)
- This function outputs a string using the `"%s"' conversion
- specification.
-
- Sometimes, there's a need to compose your output piece by piece using
-functions that operate on a stream, such as `value_print' or
-`fprintf_symbol_filtered'. These functions accept an argument of the
-type `struct ui_file *', a pointer to a `ui_file' object used to store
-the data stream used for the output. When you use one of these
-functions, you need a way to pass their results stored in a `ui_file'
-object to the `ui_out' functions. To this end, you first create a
-`ui_stream' object by calling `ui_out_stream_new', pass the `stream'
-member of that `ui_stream' object to `value_print' and similar
-functions, and finally call `ui_out_field_stream' to output the field
-you constructed. When the `ui_stream' object is no longer needed, you
-should destroy it and free its memory by calling `ui_out_stream_delete'.
-
- -- Function: struct ui_stream * ui_out_stream_new (struct ui_out
- *UIOUT)
- This function creates a new `ui_stream' object which uses the same
- output methods as the `ui_out' object whose pointer is passed in
- UIOUT. It returns a pointer to the newly created `ui_stream'
- object.
-
- -- Function: void ui_out_stream_delete (struct ui_stream *STREAMBUF)
- This functions destroys a `ui_stream' object specified by
- STREAMBUF.
-
- -- Function: void ui_out_field_stream (struct ui_out *UIOUT, const
- char *FIELDNAME, struct ui_stream *STREAMBUF)
- This function consumes all the data accumulated in
- `streambuf->stream' and outputs it like `ui_out_field_string'
- does. After a call to `ui_out_field_stream', the accumulated data
- no longer exists, but the stream is still valid and may be used
- for producing more fields.
-
- *Important:* If there is any chance that your code could bail out
-before completing output generation and reaching the point where
-`ui_out_stream_delete' is called, it is necessary to set up a cleanup,
-to avoid leaking memory and other resources. Here's a skeleton code to
-do that:
-
- struct ui_stream *mybuf = ui_out_stream_new (uiout);
- struct cleanup *old = make_cleanup (ui_out_stream_delete, mybuf);
- ...
- do_cleanups (old);
-
- If the function already has the old cleanup chain set (for other
-kinds of cleanups), you just have to add your cleanup to it:
-
- mybuf = ui_out_stream_new (uiout);
- make_cleanup (ui_out_stream_delete, mybuf);
-
- Note that with cleanups in place, you should not call
-`ui_out_stream_delete' directly, or you would attempt to free the same
-buffer twice.
-
-4.2.5 Utility Output Functions
-------------------------------
-
- -- Function: void ui_out_field_skip (struct ui_out *UIOUT, const char
- *FLDNAME)
- This function skips a field in a table. Use it if you have to
- leave an empty field without disrupting the table alignment. The
- argument FLDNAME specifies a name for the (missing) filed.
-
- -- Function: void ui_out_text (struct ui_out *UIOUT, const char
- *STRING)
- This function outputs the text in STRING in a way that makes it
- easy to be read by humans. For example, the console
- implementation of this method filters the text through a built-in
- pager, to prevent it from scrolling off the visible portion of the
- screen.
-
- Use this function for printing relatively long chunks of text
- around the actual field data: the text it produces is not aligned
- according to the table's format. Use `ui_out_field_string' to
- output a string field, and use `ui_out_message', described below,
- to output short messages.
-
- -- Function: void ui_out_spaces (struct ui_out *UIOUT, int NSPACES)
- This function outputs NSPACES spaces. It is handy to align the
- text produced by `ui_out_text' with the rest of the table or list.
-
- -- Function: void ui_out_message (struct ui_out *UIOUT, int VERBOSITY,
- const char *FORMAT, ...)
- This function produces a formatted message, provided that the
- current verbosity level is at least as large as given by
- VERBOSITY. The current verbosity level is specified by the user
- with the `set verbositylevel' command.(2)
-
- -- Function: void ui_out_wrap_hint (struct ui_out *UIOUT, char *INDENT)
- This function gives the console output filter (a paging filter) a
- hint of where to break lines which are too long. Ignored for all
- other output consumers. INDENT, if non-`NULL', is the string to
- be printed to indent the wrapped text on the next line; it must
- remain accessible until the next call to `ui_out_wrap_hint', or
- until an explicit newline is produced by one of the other
- functions. If INDENT is `NULL', the wrapped text will not be
- indented.
-
- -- Function: void ui_out_flush (struct ui_out *UIOUT)
- This function flushes whatever output has been accumulated so far,
- if the UI buffers output.
-
-4.2.6 Examples of Use of `ui_out' functions
--------------------------------------------
-
-This section gives some practical examples of using the `ui_out'
-functions to generalize the old console-oriented code in GDB. The
-examples all come from functions defined on the `breakpoints.c' file.
-
- This example, from the `breakpoint_1' function, shows how to produce
-a table.
-
- The original code was:
-
- if (!found_a_breakpoint++)
- {
- annotate_breakpoints_headers ();
-
- annotate_field (0);
- printf_filtered ("Num ");
- annotate_field (1);
- printf_filtered ("Type ");
- annotate_field (2);
- printf_filtered ("Disp ");
- annotate_field (3);
- printf_filtered ("Enb ");
- if (addressprint)
- {
- annotate_field (4);
- printf_filtered ("Address ");
- }
- annotate_field (5);
- printf_filtered ("What\n");
-
- annotate_breakpoints_table ();
- }
-
- Here's the new version:
-
- nr_printable_breakpoints = ...;
-
- if (addressprint)
- ui_out_table_begin (ui, 6, nr_printable_breakpoints, "BreakpointTable");
- else
- ui_out_table_begin (ui, 5, nr_printable_breakpoints, "BreakpointTable");
-
- if (nr_printable_breakpoints > 0)
- annotate_breakpoints_headers ();
- if (nr_printable_breakpoints > 0)
- annotate_field (0);
- ui_out_table_header (uiout, 3, ui_left, "number", "Num"); /* 1 */
- if (nr_printable_breakpoints > 0)
- annotate_field (1);
- ui_out_table_header (uiout, 14, ui_left, "type", "Type"); /* 2 */
- if (nr_printable_breakpoints > 0)
- annotate_field (2);
- ui_out_table_header (uiout, 4, ui_left, "disp", "Disp"); /* 3 */
- if (nr_printable_breakpoints > 0)
- annotate_field (3);
- ui_out_table_header (uiout, 3, ui_left, "enabled", "Enb"); /* 4 */
- if (addressprint)
- {
- if (nr_printable_breakpoints > 0)
- annotate_field (4);
- if (print_address_bits <= 32)
- ui_out_table_header (uiout, 10, ui_left, "addr", "Address");/* 5 */
- else
- ui_out_table_header (uiout, 18, ui_left, "addr", "Address");/* 5 */
- }
- if (nr_printable_breakpoints > 0)
- annotate_field (5);
- ui_out_table_header (uiout, 40, ui_noalign, "what", "What"); /* 6 */
- ui_out_table_body (uiout);
- if (nr_printable_breakpoints > 0)
- annotate_breakpoints_table ();
-
- This example, from the `print_one_breakpoint' function, shows how to
-produce the actual data for the table whose structure was defined in
-the above example. The original code was:
-
- annotate_record ();
- annotate_field (0);
- printf_filtered ("%-3d ", b->number);
- annotate_field (1);
- if ((int)b->type > (sizeof(bptypes)/sizeof(bptypes[0]))
- || ((int) b->type != bptypes[(int) b->type].type))
- internal_error ("bptypes table does not describe type #%d.",
- (int)b->type);
- printf_filtered ("%-14s ", bptypes[(int)b->type].description);
- annotate_field (2);
- printf_filtered ("%-4s ", bpdisps[(int)b->disposition]);
- annotate_field (3);
- printf_filtered ("%-3c ", bpenables[(int)b->enable]);
- ...
-
- This is the new version:
-
- annotate_record ();
- ui_out_tuple_begin (uiout, "bkpt");
- annotate_field (0);
- ui_out_field_int (uiout, "number", b->number);
- annotate_field (1);
- if (((int) b->type > (sizeof (bptypes) / sizeof (bptypes[0])))
- || ((int) b->type != bptypes[(int) b->type].type))
- internal_error ("bptypes table does not describe type #%d.",
- (int) b->type);
- ui_out_field_string (uiout, "type", bptypes[(int)b->type].description);
- annotate_field (2);
- ui_out_field_string (uiout, "disp", bpdisps[(int)b->disposition]);
- annotate_field (3);
- ui_out_field_fmt (uiout, "enabled", "%c", bpenables[(int)b->enable]);
- ...
-
- This example, also from `print_one_breakpoint', shows how to produce
-a complicated output field using the `print_expression' functions which
-requires a stream to be passed. It also shows how to automate stream
-destruction with cleanups. The original code was:
-
- annotate_field (5);
- print_expression (b->exp, gdb_stdout);
-
- The new version is:
-
- struct ui_stream *stb = ui_out_stream_new (uiout);
- struct cleanup *old_chain = make_cleanup_ui_out_stream_delete (stb);
- ...
- annotate_field (5);
- print_expression (b->exp, stb->stream);
- ui_out_field_stream (uiout, "what", local_stream);
-
- This example, also from `print_one_breakpoint', shows how to use
-`ui_out_text' and `ui_out_field_string'. The original code was:
-
- annotate_field (5);
- if (b->dll_pathname == NULL)
- printf_filtered ("<any library> ");
- else
- printf_filtered ("library \"%s\" ", b->dll_pathname);
-
- It became:
-
- annotate_field (5);
- if (b->dll_pathname == NULL)
- {
- ui_out_field_string (uiout, "what", "<any library>");
- ui_out_spaces (uiout, 1);
- }
- else
- {
- ui_out_text (uiout, "library \"");
- ui_out_field_string (uiout, "what", b->dll_pathname);
- ui_out_text (uiout, "\" ");
- }
-
- The following example from `print_one_breakpoint' shows how to use
-`ui_out_field_int' and `ui_out_spaces'. The original code was:
-
- annotate_field (5);
- if (b->forked_inferior_pid != 0)
- printf_filtered ("process %d ", b->forked_inferior_pid);
-
- It became:
-
- annotate_field (5);
- if (b->forked_inferior_pid != 0)
- {
- ui_out_text (uiout, "process ");
- ui_out_field_int (uiout, "what", b->forked_inferior_pid);
- ui_out_spaces (uiout, 1);
- }
-
- Here's an example of using `ui_out_field_string'. The original code
-was:
-
- annotate_field (5);
- if (b->exec_pathname != NULL)
- printf_filtered ("program \"%s\" ", b->exec_pathname);
-
- It became:
-
- annotate_field (5);
- if (b->exec_pathname != NULL)
- {
- ui_out_text (uiout, "program \"");
- ui_out_field_string (uiout, "what", b->exec_pathname);
- ui_out_text (uiout, "\" ");
- }
-
- Finally, here's an example of printing an address. The original
-code:
-
- annotate_field (4);
- printf_filtered ("%s ",
- hex_string_custom ((unsigned long) b->address, 8));
-
- It became:
-
- annotate_field (4);
- ui_out_field_core_addr (uiout, "Address", b->address);
-
-4.3 Console Printing
-====================
-
-4.4 TUI
-=======
-
----------- Footnotes ----------
-
- (1) The function cast is not portable ISO C.
-
- (2) As of this writing (April 2001), setting verbosity level is not
-yet implemented, and is always returned as zero. So calling
-`ui_out_message' with a VERBOSITY argument more than zero will cause
-the message to never be printed.
-
-
-File: gdbint.info, Node: libgdb, Next: Values, Prev: User Interface, Up: Top
-
-5 libgdb
-********
-
-5.1 libgdb 1.0
-==============
-
-`libgdb' 1.0 was an abortive project of years ago. The theory was to
-provide an API to GDB's functionality.
-
-5.2 libgdb 2.0
-==============
-
-`libgdb' 2.0 is an ongoing effort to update GDB so that is better able
-to support graphical and other environments.
-
- Since `libgdb' development is on-going, its architecture is still
-evolving. The following components have so far been identified:
-
- * Observer - `gdb-events.h'.
-
- * Builder - `ui-out.h'
-
- * Event Loop - `event-loop.h'
-
- * Library - `gdb.h'
-
- The model that ties these components together is described below.
-
-5.3 The `libgdb' Model
-======================
-
-A client of `libgdb' interacts with the library in two ways.
-
- * As an observer (using `gdb-events') receiving notifications from
- `libgdb' of any internal state changes (break point changes, run
- state, etc).
-
- * As a client querying `libgdb' (using the `ui-out' builder) to
- obtain various status values from GDB.
-
- Since `libgdb' could have multiple clients (e.g., a GUI supporting
-the existing GDB CLI), those clients must co-operate when controlling
-`libgdb'. In particular, a client must ensure that `libgdb' is idle
-(i.e. no other client is using `libgdb') before responding to a
-`gdb-event' by making a query.
-
-5.4 CLI support
-===============
-
-At present GDB's CLI is very much entangled in with the core of
-`libgdb'. Consequently, a client wishing to include the CLI in their
-interface needs to carefully co-ordinate its own and the CLI's
-requirements.
-
- It is suggested that the client set `libgdb' up to be bi-modal
-(alternate between CLI and client query modes). The notes below sketch
-out the theory:
-
- * The client registers itself as an observer of `libgdb'.
-
- * The client create and install `cli-out' builder using its own
- versions of the `ui-file' `gdb_stderr', `gdb_stdtarg' and
- `gdb_stdout' streams.
-
- * The client creates a separate custom `ui-out' builder that is only
- used while making direct queries to `libgdb'.
-
- When the client receives input intended for the CLI, it simply
-passes it along. Since the `cli-out' builder is installed by default,
-all the CLI output in response to that command is routed (pronounced
-rooted) through to the client controlled `gdb_stdout' et. al. streams.
-At the same time, the client is kept abreast of internal changes by
-virtue of being a `libgdb' observer.
-
- The only restriction on the client is that it must wait until
-`libgdb' becomes idle before initiating any queries (using the client's
-custom builder).
-
-5.5 `libgdb' components
-=======================
-
-Observer - `gdb-events.h'
--------------------------
-
-`gdb-events' provides the client with a very raw mechanism that can be
-used to implement an observer. At present it only allows for one
-observer and that observer must, internally, handle the need to delay
-the processing of any event notifications until after `libgdb' has
-finished the current command.
-
-Builder - `ui-out.h'
---------------------
-
-`ui-out' provides the infrastructure necessary for a client to create a
-builder. That builder is then passed down to `libgdb' when doing any
-queries.
-
-Event Loop - `event-loop.h'
----------------------------
-
-`event-loop', currently non-re-entrant, provides a simple event loop.
-A client would need to either plug its self into this loop or,
-implement a new event-loop that GDB would use.
-
- The event-loop will eventually be made re-entrant. This is so that
-GDB can better handle the problem of some commands blocking instead of
-returning.
-
-Library - `gdb.h'
------------------
-
-`libgdb' is the most obvious component of this system. It provides the
-query interface. Each function is parameterized by a `ui-out' builder.
-The result of the query is constructed using that builder before the
-query function returns.
-
-
-File: gdbint.info, Node: Values, Next: Stack Frames, Prev: libgdb, Up: Top
-
-6 Values
-********
-
-6.1 Values
-==========
-
-GDB uses `struct value', or "values", as an internal abstraction for
-the representation of a variety of inferior objects and GDB convenience
-objects.
-
- Values have an associated `struct type', that describes a virtual
-view of the raw data or object stored in or accessed through the value.
-
- A value is in addition discriminated by its lvalue-ness, given its
-`enum lval_type' enumeration type:
-
-``not_lval''
- This value is not an lval. It can't be assigned to.
-
-``lval_memory''
- This value represents an object in memory.
-
-``lval_register''
- This value represents an object that lives in a register.
-
-``lval_internalvar''
- Represents the value of an internal variable.
-
-``lval_internalvar_component''
- Represents part of a GDB internal variable. E.g., a structure
- field.
-
-``lval_computed''
- These are "computed" values. They allow creating specialized value
- objects for specific purposes, all abstracted away from the core
- value support code. The creator of such a value writes specialized
- functions to handle the reading and writing to/from the value's
- backend data, and optionally, a "copy operator" and a "destructor".
-
- Pointers to these functions are stored in a `struct lval_funcs'
- instance (declared in `value.h'), and passed to the
- `allocate_computed_value' function, as in the example below.
-
- static void
- nil_value_read (struct value *v)
- {
- /* This callback reads data from some backend, and stores it in V.
- In this case, we always read null data. You'll want to fill in
- something more interesting. */
-
- memset (value_contents_all_raw (v),
- value_offset (v),
- TYPE_LENGTH (value_type (v)));
- }
-
- static void
- nil_value_write (struct value *v, struct value *fromval)
- {
- /* Takes the data from FROMVAL and stores it in the backend of V. */
-
- to_oblivion (value_contents_all_raw (fromval),
- value_offset (v),
- TYPE_LENGTH (value_type (fromval)));
- }
-
- static struct lval_funcs nil_value_funcs =
- {
- nil_value_read,
- nil_value_write
- };
-
- struct value *
- make_nil_value (void)
- {
- struct type *type;
- struct value *v;
-
- type = make_nils_type ();
- v = allocate_computed_value (type, &nil_value_funcs, NULL);
-
- return v;
- }
-
- See the implementation of the `$_siginfo' convenience variable in
- `infrun.c' as a real example use of lval_computed.
-
-
-
-File: gdbint.info, Node: Stack Frames, Next: Symbol Handling, Prev: Values, Up: Top
-
-7 Stack Frames
-**************
-
-A frame is a construct that GDB uses to keep track of calling and
-called functions.
-
- GDB's frame model, a fresh design, was implemented with the need to
-support DWARF's Call Frame Information in mind. In fact, the term
-"unwind" is taken directly from that specification. Developers wishing
-to learn more about unwinders, are encouraged to read the DWARF
-specification, available from `http://www.dwarfstd.org'.
-
- GDB's model is that you find a frame's registers by "unwinding" them
-from the next younger frame. That is, `get_frame_register' which
-returns the value of a register in frame #1 (the next-to-youngest
-frame), is implemented by calling frame #0's `frame_register_unwind'
-(the youngest frame). But then the obvious question is: how do you
-access the registers of the youngest frame itself?
-
- To answer this question, GDB has the "sentinel" frame, the "-1st"
-frame. Unwinding registers from the sentinel frame gives you the
-current values of the youngest real frame's registers. If F is a
-sentinel frame, then `get_frame_type (F) == SENTINEL_FRAME'.
-
-7.1 Selecting an Unwinder
-=========================
-
-The architecture registers a list of frame unwinders (`struct
-frame_unwind'), using the functions `frame_unwind_prepend_unwinder' and
-`frame_unwind_append_unwinder'. Each unwinder includes a sniffer.
-Whenever GDB needs to unwind a frame (to fetch the previous frame's
-registers or the current frame's ID), it calls registered sniffers in
-order to find one which recognizes the frame. The first time a sniffer
-returns non-zero, the corresponding unwinder is assigned to the frame.
-
-7.2 Unwinding the Frame ID
-==========================
-
-Every frame has an associated ID, of type `struct frame_id'. The ID
-includes the stack base and function start address for the frame. The
-ID persists through the entire life of the frame, including while other
-called frames are running; it is used to locate an appropriate `struct
-frame_info' from the cache.
-
- Every time the inferior stops, and at various other times, the frame
-cache is flushed. Because of this, parts of GDB which need to keep
-track of individual frames cannot use pointers to `struct frame_info'.
-A frame ID provides a stable reference to a frame, even when the
-unwinder must be run again to generate a new `struct frame_info' for
-the same frame.
-
- The frame's unwinder's `this_id' method is called to find the ID.
-Note that this is different from register unwinding, where the next
-frame's `prev_register' is called to unwind this frame's registers.
-
- Both stack base and function address are required to identify the
-frame, because a recursive function has the same function address for
-two consecutive frames and a leaf function may have the same stack
-address as its caller. On some platforms, a third address is part of
-the ID to further disambiguate frames--for instance, on IA-64 the
-separate register stack address is included in the ID.
-
- An invalid frame ID (`outer_frame_id') returned from the `this_id'
-method means to stop unwinding after this frame.
-
- `null_frame_id' is another invalid frame ID which should be used
-when there is no frame. For instance, certain breakpoints are attached
-to a specific frame, and that frame is identified through its frame ID
-(we use this to implement the "finish" command). Using `null_frame_id'
-as the frame ID for a given breakpoint means that the breakpoint is not
-specific to any frame. The `this_id' method should never return
-`null_frame_id'.
-
-7.3 Unwinding Registers
-=======================
-
-Each unwinder includes a `prev_register' method. This method takes a
-frame, an associated cache pointer, and a register number. It returns
-a `struct value *' describing the requested register, as saved by this
-frame. This is the value of the register that is current in this
-frame's caller.
-
- The returned value must have the same type as the register. It may
-have any lvalue type. In most circumstances one of these routines will
-generate the appropriate value:
-
-`frame_unwind_got_optimized'
- This register was not saved.
-
-`frame_unwind_got_register'
- This register was copied into another register in this frame. This
- is also used for unchanged registers; they are "copied" into the
- same register.
-
-`frame_unwind_got_memory'
- This register was saved in memory.
-
-`frame_unwind_got_constant'
- This register was not saved, but the unwinder can compute the
- previous value some other way.
-
-`frame_unwind_got_address'
- Same as `frame_unwind_got_constant', except that the value is a
- target address. This is frequently used for the stack pointer,
- which is not explicitly saved but has a known offset from this
- frame's stack pointer. For architectures with a flat unified
- address space, this is generally the same as
- `frame_unwind_got_constant'.
-
-
-File: gdbint.info, Node: Symbol Handling, Next: Language Support, Prev: Stack Frames, Up: Top
-
-8 Symbol Handling
-*****************
-
-Symbols are a key part of GDB's operation. Symbols include variables,
-functions, and types.
-
- Symbol information for a large program can be truly massive, and
-reading of symbol information is one of the major performance
-bottlenecks in GDB; it can take many minutes to process it all.
-Studies have shown that nearly all the time spent is computational,
-rather than file reading.
-
- One of the ways for GDB to provide a good user experience is to
-start up quickly, taking no more than a few seconds. It is simply not
-possible to process all of a program's debugging info in that time, and
-so we attempt to handle symbols incrementally. For instance, we create
-"partial symbol tables" consisting of only selected symbols, and only
-expand them to full symbol tables when necessary.
-
-8.1 Symbol Reading
-==================
-
-GDB reads symbols from "symbol files". The usual symbol file is the
-file containing the program which GDB is debugging. GDB can be
-directed to use a different file for symbols (with the `symbol-file'
-command), and it can also read more symbols via the `add-file' and
-`load' commands. In addition, it may bring in more symbols while
-loading shared libraries.
-
- Symbol files are initially opened by code in `symfile.c' using the
-BFD library (*note Support Libraries::). BFD identifies the type of
-the file by examining its header. `find_sym_fns' then uses this
-identification to locate a set of symbol-reading functions.
-
- Symbol-reading modules identify themselves to GDB by calling
-`add_symtab_fns' during their module initialization. The argument to
-`add_symtab_fns' is a `struct sym_fns' which contains the name (or name
-prefix) of the symbol format, the length of the prefix, and pointers to
-four functions. These functions are called at various times to process
-symbol files whose identification matches the specified prefix.
-
- The functions supplied by each module are:
-
-`XYZ_symfile_init(struct sym_fns *sf)'
- Called from `symbol_file_add' when we are about to read a new
- symbol file. This function should clean up any internal state
- (possibly resulting from half-read previous files, for example)
- and prepare to read a new symbol file. Note that the symbol file
- which we are reading might be a new "main" symbol file, or might
- be a secondary symbol file whose symbols are being added to the
- existing symbol table.
-
- The argument to `XYZ_symfile_init' is a newly allocated `struct
- sym_fns' whose `bfd' field contains the BFD for the new symbol
- file being read. Its `private' field has been zeroed, and can be
- modified as desired. Typically, a struct of private information
- will be `malloc''d, and a pointer to it will be placed in the
- `private' field.
-
- There is no result from `XYZ_symfile_init', but it can call
- `error' if it detects an unavoidable problem.
-
-`XYZ_new_init()'
- Called from `symbol_file_add' when discarding existing symbols.
- This function needs only handle the symbol-reading module's
- internal state; the symbol table data structures visible to the
- rest of GDB will be discarded by `symbol_file_add'. It has no
- arguments and no result. It may be called after
- `XYZ_symfile_init', if a new symbol table is being read, or may be
- called alone if all symbols are simply being discarded.
-
-`XYZ_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline)'
- Called from `symbol_file_add' to actually read the symbols from a
- symbol-file into a set of psymtabs or symtabs.
-
- `sf' points to the `struct sym_fns' originally passed to
- `XYZ_sym_init' for possible initialization. `addr' is the offset
- between the file's specified start address and its true address in
- memory. `mainline' is 1 if this is the main symbol table being
- read, and 0 if a secondary symbol file (e.g., shared library or
- dynamically loaded file) is being read.
-
- In addition, if a symbol-reading module creates psymtabs when
-XYZ_symfile_read is called, these psymtabs will contain a pointer to a
-function `XYZ_psymtab_to_symtab', which can be called from any point in
-the GDB symbol-handling code.
-
-`XYZ_psymtab_to_symtab (struct partial_symtab *pst)'
- Called from `psymtab_to_symtab' (or the `PSYMTAB_TO_SYMTAB' macro)
- if the psymtab has not already been read in and had its
- `pst->symtab' pointer set. The argument is the psymtab to be
- fleshed-out into a symtab. Upon return, `pst->readin' should have
- been set to 1, and `pst->symtab' should contain a pointer to the
- new corresponding symtab, or zero if there were no symbols in that
- part of the symbol file.
-
-8.2 Partial Symbol Tables
-=========================
-
-GDB has three types of symbol tables:
-
- * Full symbol tables ("symtabs"). These contain the main
- information about symbols and addresses.
-
- * Partial symbol tables ("psymtabs"). These contain enough
- information to know when to read the corresponding part of the full
- symbol table.
-
- * Minimal symbol tables ("msymtabs"). These contain information
- gleaned from non-debugging symbols.
-
- This section describes partial symbol tables.
-
- A psymtab is constructed by doing a very quick pass over an
-executable file's debugging information. Small amounts of information
-are extracted--enough to identify which parts of the symbol table will
-need to be re-read and fully digested later, when the user needs the
-information. The speed of this pass causes GDB to start up very
-quickly. Later, as the detailed rereading occurs, it occurs in small
-pieces, at various times, and the delay therefrom is mostly invisible to
-the user.
-
- The symbols that show up in a file's psymtab should be, roughly,
-those visible to the debugger's user when the program is not running
-code from that file. These include external symbols and types, static
-symbols and types, and `enum' values declared at file scope.
-
- The psymtab also contains the range of instruction addresses that the
-full symbol table would represent.
-
- The idea is that there are only two ways for the user (or much of the
-code in the debugger) to reference a symbol:
-
- * By its address (e.g., execution stops at some address which is
- inside a function in this file). The address will be noticed to
- be in the range of this psymtab, and the full symtab will be read
- in. `find_pc_function', `find_pc_line', and other `find_pc_...'
- functions handle this.
-
- * By its name (e.g., the user asks to print a variable, or set a
- breakpoint on a function). Global names and file-scope names will
- be found in the psymtab, which will cause the symtab to be pulled
- in. Local names will have to be qualified by a global name, or a
- file-scope name, in which case we will have already read in the
- symtab as we evaluated the qualifier. Or, a local symbol can be
- referenced when we are "in" a local scope, in which case the first
- case applies. `lookup_symbol' does most of the work here.
-
- The only reason that psymtabs exist is to cause a symtab to be read
-in at the right moment. Any symbol that can be elided from a psymtab,
-while still causing that to happen, should not appear in it. Since
-psymtabs don't have the idea of scope, you can't put local symbols in
-them anyway. Psymtabs don't have the idea of the type of a symbol,
-either, so types need not appear, unless they will be referenced by
-name.
-
- It is a bug for GDB to behave one way when only a psymtab has been
-read, and another way if the corresponding symtab has been read in.
-Such bugs are typically caused by a psymtab that does not contain all
-the visible symbols, or which has the wrong instruction address ranges.
-
- The psymtab for a particular section of a symbol file (objfile)
-could be thrown away after the symtab has been read in. The symtab
-should always be searched before the psymtab, so the psymtab will never
-be used (in a bug-free environment). Currently, psymtabs are allocated
-on an obstack, and all the psymbols themselves are allocated in a pair
-of large arrays on an obstack, so there is little to be gained by
-trying to free them unless you want to do a lot more work.
-
- Whether or not psymtabs are created depends on the objfile's symbol
-reader. The core of GDB hides the details of partial symbols and
-partial symbol tables behind a set of function pointers known as the
-"quick symbol functions". These are documented in `symfile.h'.
-
-8.3 Types
-=========
-
-Fundamental Types (e.g., `FT_VOID', `FT_BOOLEAN').
---------------------------------------------------
-
-These are the fundamental types that GDB uses internally. Fundamental
-types from the various debugging formats (stabs, ELF, etc) are mapped
-into one of these. They are basically a union of all fundamental types
-that GDB knows about for all the languages that GDB knows about.
-
-Type Codes (e.g., `TYPE_CODE_PTR', `TYPE_CODE_ARRAY').
-------------------------------------------------------
-
-Each time GDB builds an internal type, it marks it with one of these
-types. The type may be a fundamental type, such as `TYPE_CODE_INT', or
-a derived type, such as `TYPE_CODE_PTR' which is a pointer to another
-type. Typically, several `FT_*' types map to one `TYPE_CODE_*' type,
-and are distinguished by other members of the type struct, such as
-whether the type is signed or unsigned, and how many bits it uses.
-
-Builtin Types (e.g., `builtin_type_void', `builtin_type_char').
----------------------------------------------------------------
-
-These are instances of type structs that roughly correspond to
-fundamental types and are created as global types for GDB to use for
-various ugly historical reasons. We eventually want to eliminate
-these. Note for example that `builtin_type_int' initialized in
-`gdbtypes.c' is basically the same as a `TYPE_CODE_INT' type that is
-initialized in `c-lang.c' for an `FT_INTEGER' fundamental type. The
-difference is that the `builtin_type' is not associated with any
-particular objfile, and only one instance exists, while `c-lang.c'
-builds as many `TYPE_CODE_INT' types as needed, with each one
-associated with some particular objfile.
-
-8.4 Object File Formats
-=======================
-
-8.4.1 a.out
------------
-
-The `a.out' format is the original file format for Unix. It consists
-of three sections: `text', `data', and `bss', which are for program
-code, initialized data, and uninitialized data, respectively.
-
- The `a.out' format is so simple that it doesn't have any reserved
-place for debugging information. (Hey, the original Unix hackers used
-`adb', which is a machine-language debugger!) The only debugging
-format for `a.out' is stabs, which is encoded as a set of normal
-symbols with distinctive attributes.
-
- The basic `a.out' reader is in `dbxread.c'.
-
-8.4.2 COFF
-----------
-
-The COFF format was introduced with System V Release 3 (SVR3) Unix.
-COFF files may have multiple sections, each prefixed by a header. The
-number of sections is limited.
-
- The COFF specification includes support for debugging. Although this
-was a step forward, the debugging information was woefully limited.
-For instance, it was not possible to represent code that came from an
-included file. GNU's COFF-using configs often use stabs-type info,
-encapsulated in special sections.
-
- The COFF reader is in `coffread.c'.
-
-8.4.3 ECOFF
------------
-
-ECOFF is an extended COFF originally introduced for Mips and Alpha
-workstations.
-
- The basic ECOFF reader is in `mipsread.c'.
-
-8.4.4 XCOFF
------------
-
-The IBM RS/6000 running AIX uses an object file format called XCOFF.
-The COFF sections, symbols, and line numbers are used, but debugging
-symbols are `dbx'-style stabs whose strings are located in the `.debug'
-section (rather than the string table). For more information, see
-*note Top: (stabs)Top.
-
- The shared library scheme has a clean interface for figuring out what
-shared libraries are in use, but the catch is that everything which
-refers to addresses (symbol tables and breakpoints at least) needs to be
-relocated for both shared libraries and the main executable. At least
-using the standard mechanism this can only be done once the program has
-been run (or the core file has been read).
-
-8.4.5 PE
---------
-
-Windows 95 and NT use the PE ("Portable Executable") format for their
-executables. PE is basically COFF with additional headers.
-
- While BFD includes special PE support, GDB needs only the basic COFF
-reader.
-
-8.4.6 ELF
----------
-
-The ELF format came with System V Release 4 (SVR4) Unix. ELF is
-similar to COFF in being organized into a number of sections, but it
-removes many of COFF's limitations. Debugging info may be either stabs
-encapsulated in ELF sections, or more commonly these days, DWARF.
-
- The basic ELF reader is in `elfread.c'.
-
-8.4.7 SOM
----------
-
-SOM is HP's object file and debug format (not to be confused with IBM's
-SOM, which is a cross-language ABI).
-
- The SOM reader is in `somread.c'.
-
-8.5 Debugging File Formats
-==========================
-
-This section describes characteristics of debugging information that
-are independent of the object file format.
-
-8.5.1 stabs
------------
-
-`stabs' started out as special symbols within the `a.out' format.
-Since then, it has been encapsulated into other file formats, such as
-COFF and ELF.
-
- While `dbxread.c' does some of the basic stab processing, including
-for encapsulated versions, `stabsread.c' does the real work.
-
-8.5.2 COFF
-----------
-
-The basic COFF definition includes debugging information. The level of
-support is minimal and non-extensible, and is not often used.
-
-8.5.3 Mips debug (Third Eye)
-----------------------------
-
-ECOFF includes a definition of a special debug format.
-
- The file `mdebugread.c' implements reading for this format.
-
-8.5.4 DWARF 2
--------------
-
-DWARF 2 is an improved but incompatible version of DWARF 1.
-
- The DWARF 2 reader is in `dwarf2read.c'.
-
-8.5.5 Compressed DWARF 2
-------------------------
-
-Compressed DWARF 2 is not technically a separate debugging format, but
-merely DWARF 2 debug information that has been compressed. In this
-format, every object-file section holding DWARF 2 debugging information
-is compressed and prepended with a header. (The section is also
-typically renamed, so a section called `.debug_info' in a DWARF 2
-binary would be called `.zdebug_info' in a compressed DWARF 2 binary.)
-The header is 12 bytes long:
-
- * 4 bytes: the literal string "ZLIB"
-
- * 8 bytes: the uncompressed size of the section, in big-endian byte
- order.
-
- The same reader is used for both compressed an normal DWARF 2 info.
-Section decompression is done in `zlib_decompress_section' in
-`dwarf2read.c'.
-
-8.5.6 DWARF 3
--------------
-
-DWARF 3 is an improved version of DWARF 2.
-
-8.5.7 SOM
----------
-
-Like COFF, the SOM definition includes debugging information.
-
-8.6 Adding a New Symbol Reader to GDB
-=====================================
-
-If you are using an existing object file format (`a.out', COFF, ELF,
-etc), there is probably little to be done.
-
- If you need to add a new object file format, you must first add it to
-BFD. This is beyond the scope of this document.
-
- You must then arrange for the BFD code to provide access to the
-debugging symbols. Generally GDB will have to call swapping routines
-from BFD and a few other BFD internal routines to locate the debugging
-information. As much as possible, GDB should not depend on the BFD
-internal data structures.
-
- For some targets (e.g., COFF), there is a special transfer vector
-used to call swapping routines, since the external data structures on
-various platforms have different sizes and layouts. Specialized
-routines that will only ever be implemented by one object file format
-may be called directly. This interface should be described in a file
-`bfd/libXYZ.h', which is included by GDB.
-
-8.7 Memory Management for Symbol Files
-======================================
-
-Most memory associated with a loaded symbol file is stored on its
-`objfile_obstack'. This includes symbols, types, namespace data, and
-other information produced by the symbol readers.
-
- Because this data lives on the objfile's obstack, it is automatically
-released when the objfile is unloaded or reloaded. Therefore one
-objfile must not reference symbol or type data from another objfile;
-they could be unloaded at different times.
-
- User convenience variables, et cetera, have associated types.
-Normally these types live in the associated objfile. However, when the
-objfile is unloaded, those types are deep copied to global memory, so
-that the values of the user variables and history items are not lost.
-
-
-File: gdbint.info, Node: Language Support, Next: Host Definition, Prev: Symbol Handling, Up: Top
-
-9 Language Support
-******************
-
-GDB's language support is mainly driven by the symbol reader, although
-it is possible for the user to set the source language manually.
-
- GDB chooses the source language by looking at the extension of the
-file recorded in the debug info; `.c' means C, `.f' means Fortran, etc.
-It may also use a special-purpose language identifier if the debug
-format supports it, like with DWARF.
-
-9.1 Adding a Source Language to GDB
-===================================
-
-To add other languages to GDB's expression parser, follow the following
-steps:
-
-_Create the expression parser._
- This should reside in a file `LANG-exp.y'. Routines for building
- parsed expressions into a `union exp_element' list are in
- `parse.c'.
-
- Since we can't depend upon everyone having Bison, and YACC produces
- parsers that define a bunch of global names, the following lines
- *must* be included at the top of the YACC parser, to prevent the
- various parsers from defining the same global names:
-
- #define yyparse LANG_parse
- #define yylex LANG_lex
- #define yyerror LANG_error
- #define yylval LANG_lval
- #define yychar LANG_char
- #define yydebug LANG_debug
- #define yypact LANG_pact
- #define yyr1 LANG_r1
- #define yyr2 LANG_r2
- #define yydef LANG_def
- #define yychk LANG_chk
- #define yypgo LANG_pgo
- #define yyact LANG_act
- #define yyexca LANG_exca
- #define yyerrflag LANG_errflag
- #define yynerrs LANG_nerrs
-
- At the bottom of your parser, define a `struct language_defn' and
- initialize it with the right values for your language. Define an
- `initialize_LANG' routine and have it call
- `add_language(LANG_language_defn)' to tell the rest of GDB that
- your language exists. You'll need some other supporting variables
- and functions, which will be used via pointers from your
- `LANG_language_defn'. See the declaration of `struct
- language_defn' in `language.h', and the other `*-exp.y' files, for
- more information.
-
-_Add any evaluation routines, if necessary_
- If you need new opcodes (that represent the operations of the
- language), add them to the enumerated type in `expression.h'. Add
- support code for these operations in the `evaluate_subexp' function
- defined in the file `eval.c'. Add cases for new opcodes in two
- functions from `parse.c': `prefixify_subexp' and
- `length_of_subexp'. These compute the number of `exp_element's
- that a given operation takes up.
-
-_Update some existing code_
- Add an enumerated identifier for your language to the enumerated
- type `enum language' in `defs.h'.
-
- Update the routines in `language.c' so your language is included.
- These routines include type predicates and such, which (in some
- cases) are language dependent. If your language does not appear
- in the switch statement, an error is reported.
-
- Also included in `language.c' is the code that updates the variable
- `current_language', and the routines that translate the
- `language_LANG' enumerated identifier into a printable string.
-
- Update the function `_initialize_language' to include your
- language. This function picks the default language upon startup,
- so is dependent upon which languages that GDB is built for.
-
- Update `allocate_symtab' in `symfile.c' and/or symbol-reading code
- so that the language of each symtab (source file) is set properly.
- This is used to determine the language to use at each stack frame
- level. Currently, the language is set based upon the extension of
- the source file. If the language can be better inferred from the
- symbol information, please set the language of the symtab in the
- symbol-reading code.
-
- Add helper code to `print_subexp' (in `expprint.c') to handle any
- new expression opcodes you have added to `expression.h'. Also,
- add the printed representations of your operators to
- `op_print_tab'.
-
-_Add a place of call_
- Add a call to `LANG_parse()' and `LANG_error' in `parse_exp_1'
- (defined in `parse.c').
-
-_Edit `Makefile.in'_
- Add dependencies in `Makefile.in'. Make sure you update the macro
- variables such as `HFILES' and `OBJS', otherwise your code may not
- get linked in, or, worse yet, it may not get `tar'red into the
- distribution!
-
-
-File: gdbint.info, Node: Host Definition, Next: Target Architecture Definition, Prev: Language Support, Up: Top
-
-10 Host Definition
-******************
-
-With the advent of Autoconf, it's rarely necessary to have host
-definition machinery anymore. The following information is provided,
-mainly, as an historical reference.
-
-10.1 Adding a New Host
-======================
-
-GDB's host configuration support normally happens via Autoconf. New
-host-specific definitions should not be needed. Older hosts GDB still
-use the host-specific definitions and files listed below, but these
-mostly exist for historical reasons, and will eventually disappear.
-
-`gdb/config/ARCH/XYZ.mh'
- This file is a Makefile fragment that once contained both host and
- native configuration information (*note Native Debugging::) for the
- machine XYZ. The host configuration information is now handled by
- Autoconf.
-
- Host configuration information included definitions for `CC',
- `SYSV_DEFINE', `XM_CFLAGS', `XM_ADD_FILES', `XM_CLIBS',
- `XM_CDEPS', etc.; see `Makefile.in'.
-
- New host-only configurations do not need this file.
-
-
- (Files named `gdb/config/ARCH/xm-XYZ.h' were once used to define
-host-specific macros, but were no longer needed and have all been
-removed.)
-
-Generic Host Support Files
---------------------------
-
-There are some "generic" versions of routines that can be used by
-various systems.
-
-`ser-unix.c'
- This contains serial line support for Unix systems. It is
- included by default on all Unix-like hosts.
-
-`ser-pipe.c'
- This contains serial pipe support for Unix systems. It is
- included by default on all Unix-like hosts.
-
-`ser-mingw.c'
- This contains serial line support for 32-bit programs running under
- Windows using MinGW.
-
-`ser-go32.c'
- This contains serial line support for 32-bit programs running
- under DOS, using the DJGPP (a.k.a. GO32) execution environment.
-
-`ser-tcp.c'
- This contains generic TCP support using sockets. It is included by
- default on all Unix-like hosts and with MinGW.
-
-10.2 Host Conditionals
-======================
-
-When GDB is configured and compiled, various macros are defined or left
-undefined, to control compilation based on the attributes of the host
-system. While formerly they could be set in host-specific header
-files, at present they can be changed only by setting `CFLAGS' when
-building, or by editing the source code.
-
- These macros and their meanings (or if the meaning is not documented
-here, then one of the source files where they are used is indicated)
-are:
-
-`GDBINIT_FILENAME'
- The default name of GDB's initialization file (normally
- `.gdbinit').
-
-`SIGWINCH_HANDLER'
- If your host defines `SIGWINCH', you can define this to be the name
- of a function to be called if `SIGWINCH' is received.
-
-`SIGWINCH_HANDLER_BODY'
- Define this to expand into code that will define the function
- named by the expansion of `SIGWINCH_HANDLER'.
-
-`CRLF_SOURCE_FILES'
- Define this if host files use `\r\n' rather than `\n' as a line
- terminator. This will cause source file listings to omit `\r'
- characters when printing and it will allow `\r\n' line endings of
- files which are "sourced" by gdb. It must be possible to open
- files in binary mode using `O_BINARY' or, for fopen, `"rb"'.
-
-`DEFAULT_PROMPT'
- The default value of the prompt string (normally `"(gdb) "').
-
-`DEV_TTY'
- The name of the generic TTY device, defaults to `"/dev/tty"'.
-
-`ISATTY'
- Substitute for isatty, if not available.
-
-`FOPEN_RB'
- Define this if binary files are opened the same way as text files.
-
-`CC_HAS_LONG_LONG'
- Define this if the host C compiler supports `long long'. This is
- set by the `configure' script.
-
-`PRINTF_HAS_LONG_LONG'
- Define this if the host can handle printing of long long integers
- via the printf format conversion specifier `ll'. This is set by
- the `configure' script.
-
-`LSEEK_NOT_LINEAR'
- Define this if `lseek (n)' does not necessarily move to byte number
- `n' in the file. This is only used when reading source files. It
- is normally faster to define `CRLF_SOURCE_FILES' when possible.
-
-`lint'
- Define this to help placate `lint' in some situations.
-
-`volatile'
- Define this to override the defaults of `__volatile__' or `/**/'.
-
-
-File: gdbint.info, Node: Target Architecture Definition, Next: Target Descriptions, Prev: Host Definition, Up: Top
-
-11 Target Architecture Definition
-*********************************
-
-GDB's target architecture defines what sort of machine-language
-programs GDB can work with, and how it works with them.
-
- The target architecture object is implemented as the C structure
-`struct gdbarch *'. The structure, and its methods, are generated
-using the Bourne shell script `gdbarch.sh'.
-
-* Menu:
-
-* OS ABI Variant Handling::
-* Initialize New Architecture::
-* Registers and Memory::
-* Pointers and Addresses::
-* Address Classes::
-* Register Representation::
-* Frame Interpretation::
-* Inferior Call Setup::
-* Adding support for debugging core files::
-* Defining Other Architecture Features::
-* Adding a New Target::
-
-
-File: gdbint.info, Node: OS ABI Variant Handling, Next: Initialize New Architecture, Up: Target Architecture Definition
-
-11.1 Operating System ABI Variant Handling
-==========================================
-
-GDB provides a mechanism for handling variations in OS ABIs. An OS ABI
-variant may have influence over any number of variables in the target
-architecture definition. There are two major components in the OS ABI
-mechanism: sniffers and handlers.
-
- A "sniffer" examines a file matching a BFD architecture/flavour pair
-(the architecture may be wildcarded) in an attempt to determine the OS
-ABI of that file. Sniffers with a wildcarded architecture are
-considered to be "generic", while sniffers for a specific architecture
-are considered to be "specific". A match from a specific sniffer
-overrides a match from a generic sniffer. Multiple sniffers for an
-architecture/flavour may exist, in order to differentiate between two
-different operating systems which use the same basic file format. The
-OS ABI framework provides a generic sniffer for ELF-format files which
-examines the `EI_OSABI' field of the ELF header, as well as note
-sections known to be used by several operating systems.
-
- A "handler" is used to fine-tune the `gdbarch' structure for the
-selected OS ABI. There may be only one handler for a given OS ABI for
-each BFD architecture.
-
- The following OS ABI variants are defined in `defs.h':
-
-`GDB_OSABI_UNINITIALIZED'
- Used for struct gdbarch_info if ABI is still uninitialized.
-
-`GDB_OSABI_UNKNOWN'
- The ABI of the inferior is unknown. The default `gdbarch'
- settings for the architecture will be used.
-
-`GDB_OSABI_SVR4'
- UNIX System V Release 4.
-
-`GDB_OSABI_HURD'
- GNU using the Hurd kernel.
-
-`GDB_OSABI_SOLARIS'
- Sun Solaris.
-
-`GDB_OSABI_OSF1'
- OSF/1, including Digital UNIX and Compaq Tru64 UNIX.
-
-`GDB_OSABI_LINUX'
- GNU using the Linux kernel.
-
-`GDB_OSABI_FREEBSD_AOUT'
- FreeBSD using the `a.out' executable format.
-
-`GDB_OSABI_FREEBSD_ELF'
- FreeBSD using the ELF executable format.
-
-`GDB_OSABI_NETBSD_AOUT'
- NetBSD using the `a.out' executable format.
-
-`GDB_OSABI_NETBSD_ELF'
- NetBSD using the ELF executable format.
-
-`GDB_OSABI_OPENBSD_ELF'
- OpenBSD using the ELF executable format.
-
-`GDB_OSABI_WINCE'
- Windows CE.
-
-`GDB_OSABI_GO32'
- DJGPP.
-
-`GDB_OSABI_IRIX'
- Irix.
-
-`GDB_OSABI_INTERIX'
- Interix (Posix layer for MS-Windows systems).
-
-`GDB_OSABI_HPUX_ELF'
- HP/UX using the ELF executable format.
-
-`GDB_OSABI_HPUX_SOM'
- HP/UX using the SOM executable format.
-
-`GDB_OSABI_QNXNTO'
- QNX Neutrino.
-
-`GDB_OSABI_CYGWIN'
- Cygwin.
-
-`GDB_OSABI_AIX'
- AIX.
-
-
- Here are the functions that make up the OS ABI framework:
-
- -- Function: const char * gdbarch_osabi_name (enum gdb_osabi OSABI)
- Return the name of the OS ABI corresponding to OSABI.
-
- -- Function: void gdbarch_register_osabi (enum bfd_architecture ARCH,
- unsigned long MACHINE, enum gdb_osabi OSABI, void
- (*INIT_OSABI)(struct gdbarch_info INFO, struct gdbarch
- *GDBARCH))
- Register the OS ABI handler specified by INIT_OSABI for the
- architecture, machine type and OS ABI specified by ARCH, MACHINE
- and OSABI. In most cases, a value of zero for the machine type,
- which implies the architecture's default machine type, will
- suffice.
-
- -- Function: void gdbarch_register_osabi_sniffer (enum
- bfd_architecture ARCH, enum bfd_flavour FLAVOUR, enum
- gdb_osabi (*SNIFFER)(bfd *ABFD))
- Register the OS ABI file sniffer specified by SNIFFER for the BFD
- architecture/flavour pair specified by ARCH and FLAVOUR. If ARCH
- is `bfd_arch_unknown', the sniffer is considered to be generic,
- and is allowed to examine FLAVOUR-flavoured files for any
- architecture.
-
- -- Function: enum gdb_osabi gdbarch_lookup_osabi (bfd *ABFD)
- Examine the file described by ABFD to determine its OS ABI. The
- value `GDB_OSABI_UNKNOWN' is returned if the OS ABI cannot be
- determined.
-
- -- Function: void gdbarch_init_osabi (struct gdbarch info INFO, struct
- gdbarch *GDBARCH, enum gdb_osabi OSABI)
- Invoke the OS ABI handler corresponding to OSABI to fine-tune the
- `gdbarch' structure specified by GDBARCH. If a handler
- corresponding to OSABI has not been registered for GDBARCH's
- architecture, a warning will be issued and the debugging session
- will continue with the defaults already established for GDBARCH.
-
- -- Function: void generic_elf_osabi_sniff_abi_tag_sections (bfd *ABFD,
- asection *SECT, void *OBJ)
- Helper routine for ELF file sniffers. Examine the file described
- by ABFD and look at ABI tag note sections to determine the OS ABI
- from the note. This function should be called via
- `bfd_map_over_sections'.
-
-
-File: gdbint.info, Node: Initialize New Architecture, Next: Registers and Memory, Prev: OS ABI Variant Handling, Up: Target Architecture Definition
-
-11.2 Initializing a New Architecture
-====================================
-
-* Menu:
-
-* How an Architecture is Represented::
-* Looking Up an Existing Architecture::
-* Creating a New Architecture::
-
-
-File: gdbint.info, Node: How an Architecture is Represented, Next: Looking Up an Existing Architecture, Up: Initialize New Architecture
-
-11.2.1 How an Architecture is Represented
------------------------------------------
-
-Each `gdbarch' is associated with a single BFD architecture, via a
-`bfd_arch_ARCH' in the `bfd_architecture' enumeration. The `gdbarch'
-is registered by a call to `register_gdbarch_init', usually from the
-file's `_initialize_FILENAME' routine, which will be automatically
-called during GDB startup. The arguments are a BFD architecture
-constant and an initialization function.
-
- A GDB description for a new architecture, ARCH is created by
-defining a global function `_initialize_ARCH_tdep', by convention in
-the source file `ARCH-tdep.c'. For example, in the case of the
-OpenRISC 1000, this function is called `_initialize_or1k_tdep' and is
-found in the file `or1k-tdep.c'.
-
- The resulting object files containing the implementation of the
-`_initialize_ARCH_tdep' function are specified in the GDB
-`configure.tgt' file, which includes a large case statement pattern
-matching against the `--target' option of the `configure' script. The
-new `struct gdbarch' is created within the `_initialize_ARCH_tdep'
-function by calling `gdbarch_register':
-
- void gdbarch_register (enum bfd_architecture ARCHITECTURE,
- gdbarch_init_ftype *INIT_FUNC,
- gdbarch_dump_tdep_ftype *TDEP_DUMP_FUNC);
-
- The ARCHITECTURE will identify the unique BFD to be associated with
-this `gdbarch'. The INIT_FUNC funciton is called to create and return
-the new `struct gdbarch'. The TDEP_DUMP_FUNC function will dump the
-target specific details associated with this architecture.
-
- For example the function `_initialize_or1k_tdep' creates its
-architecture for 32-bit OpenRISC 1000 architectures by calling:
-
- gdbarch_register (bfd_arch_or32, or1k_gdbarch_init, or1k_dump_tdep);
-
-
-File: gdbint.info, Node: Looking Up an Existing Architecture, Next: Creating a New Architecture, Prev: How an Architecture is Represented, Up: Initialize New Architecture
-
-11.2.2 Looking Up an Existing Architecture
-------------------------------------------
-
-The initialization function has this prototype:
-
- static struct gdbarch *
- ARCH_gdbarch_init (struct gdbarch_info INFO,
- struct gdbarch_list *ARCHES)
-
- The INFO argument contains parameters used to select the correct
-architecture, and ARCHES is a list of architectures which have already
-been created with the same `bfd_arch_ARCH' value.
-
- The initialization function should first make sure that INFO is
-acceptable, and return `NULL' if it is not. Then, it should search
-through ARCHES for an exact match to INFO, and return one if found.
-Lastly, if no exact match was found, it should create a new
-architecture based on INFO and return it.
-
- The lookup is done using `gdbarch_list_lookup_by_info'. It is
-passed the list of existing architectures, ARCHES, and the `struct
-gdbarch_info', INFO, and returns the first matching architecture it
-finds, or `NULL' if none are found. If an architecture is found it can
-be returned as the result from the initialization function, otherwise a
-new `struct gdbach' will need to be created.
-
- The struct gdbarch_info has the following components:
-
- struct gdbarch_info
- {
- const struct bfd_arch_info *bfd_arch_info;
- int byte_order;
- bfd *abfd;
- struct gdbarch_tdep_info *tdep_info;
- enum gdb_osabi osabi;
- const struct target_desc *target_desc;
- };
-
- The `bfd_arch_info' member holds the key details about the
-architecture. The `byte_order' member is a value in an enumeration
-indicating the endianism. The `abfd' member is a pointer to the full
-BFD, the `tdep_info' member is additional custom target specific
-information, `osabi' identifies which (if any) of a number of operating
-specific ABIs are used by this architecture and the `target_desc'
-member is a set of name-value pairs with information about register
-usage in this target.
-
- When the `struct gdbarch' initialization function is called, not all
-the fields are provided--only those which can be deduced from the BFD.
-The `struct gdbarch_info', INFO is used as a look-up key with the list
-of existing architectures, ARCHES to see if a suitable architecture
-already exists. The TDEP_INFO, OSABI and TARGET_DESC fields may be
-added before this lookup to refine the search.
-
- Only information in INFO should be used to choose the new
-architecture. Historically, INFO could be sparse, and defaults would
-be collected from the first element on ARCHES. However, GDB now fills
-in INFO more thoroughly, so new `gdbarch' initialization functions
-should not take defaults from ARCHES.
-
-
-File: gdbint.info, Node: Creating a New Architecture, Prev: Looking Up an Existing Architecture, Up: Initialize New Architecture
-
-11.2.3 Creating a New Architecture
-----------------------------------
-
-If no architecture is found, then a new architecture must be created,
-by calling `gdbarch_alloc' using the supplied `struct gdbarch_info' and
-any additional custom target specific information in a `struct
-gdbarch_tdep'. The prototype for `gdbarch_alloc' is:
-
- struct gdbarch *gdbarch_alloc (const struct gdbarch_info *INFO,
- struct gdbarch_tdep *TDEP);
-
- The newly created struct gdbarch must then be populated. Although
-there are default values, in most cases they are not what is required.
-
- For each element, X, there is are a pair of corresponding accessor
-functions, one to set the value of that element, `set_gdbarch_X', the
-second to either get the value of an element (if it is a variable) or
-to apply the element (if it is a function), `gdbarch_X'. Note that
-both accessor functions take a pointer to the `struct gdbarch' as first
-argument. Populating the new `gdbarch' should use the `set_gdbarch'
-functions.
-
- The following sections identify the main elements that should be set
-in this way. This is not the complete list, but represents the
-functions and elements that must commonly be specified for a new
-architecture. Many of the functions and variables are described in the
-header file `gdbarch.h'.
-
- This is the main work in defining a new architecture. Implementing
-the set of functions to populate the `struct gdbarch'.
-
- `struct gdbarch_tdep' is not defined within GDB--it is up to the
-user to define this struct if it is needed to hold custom target
-information that is not covered by the standard `struct gdbarch'. For
-example with the OpenRISC 1000 architecture it is used to hold the
-number of matchpoints available in the target (along with other
-information).
-
- If there is no additional target specific information, it can be set
-to `NULL'.
-
-
-File: gdbint.info, Node: Registers and Memory, Next: Pointers and Addresses, Prev: Initialize New Architecture, Up: Target Architecture Definition
-
-11.3 Registers and Memory
-=========================
-
-GDB's model of the target machine is rather simple. GDB assumes the
-machine includes a bank of registers and a block of memory. Each
-register may have a different size.
-
- GDB does not have a magical way to match up with the compiler's idea
-of which registers are which; however, it is critical that they do
-match up accurately. The only way to make this work is to get accurate
-information about the order that the compiler uses, and to reflect that
-in the `gdbarch_register_name' and related functions.
-
- GDB can handle big-endian, little-endian, and bi-endian
-architectures.
-
-
-File: gdbint.info, Node: Pointers and Addresses, Next: Address Classes, Prev: Registers and Memory, Up: Target Architecture Definition
-
-11.4 Pointers Are Not Always Addresses
-======================================
-
-On almost all 32-bit architectures, the representation of a pointer is
-indistinguishable from the representation of some fixed-length number
-whose value is the byte address of the object pointed to. On such
-machines, the words "pointer" and "address" can be used interchangeably.
-However, architectures with smaller word sizes are often cramped for
-address space, so they may choose a pointer representation that breaks
-this identity, and allows a larger code address space.
-
- For example, the Renesas D10V is a 16-bit VLIW processor whose
-instructions are 32 bits long(1). If the D10V used ordinary byte
-addresses to refer to code locations, then the processor would only be
-able to address 64kb of instructions. However, since instructions must
-be aligned on four-byte boundaries, the low two bits of any valid
-instruction's byte address are always zero--byte addresses waste two
-bits. So instead of byte addresses, the D10V uses word addresses--byte
-addresses shifted right two bits--to refer to code. Thus, the D10V can
-use 16-bit words to address 256kb of code space.
-
- However, this means that code pointers and data pointers have
-different forms on the D10V. The 16-bit word `0xC020' refers to byte
-address `0xC020' when used as a data address, but refers to byte address
-`0x30080' when used as a code address.
-
- (The D10V also uses separate code and data address spaces, which also
-affects the correspondence between pointers and addresses, but we're
-going to ignore that here; this example is already too long.)
-
- To cope with architectures like this--the D10V is not the only
-one!--GDB tries to distinguish between "addresses", which are byte
-numbers, and "pointers", which are the target's representation of an
-address of a particular type of data. In the example above, `0xC020'
-is the pointer, which refers to one of the addresses `0xC020' or
-`0x30080', depending on the type imposed upon it. GDB provides
-functions for turning a pointer into an address and vice versa, in the
-appropriate way for the current architecture.
-
- Unfortunately, since addresses and pointers are identical on almost
-all processors, this distinction tends to bit-rot pretty quickly. Thus,
-each time you port GDB to an architecture which does distinguish
-between pointers and addresses, you'll probably need to clean up some
-architecture-independent code.
-
- Here are functions which convert between pointers and addresses:
-
- -- Function: CORE_ADDR extract_typed_address (void *BUF, struct type
- *TYPE)
- Treat the bytes at BUF as a pointer or reference of type TYPE, and
- return the address it represents, in a manner appropriate for the
- current architecture. This yields an address GDB can use to read
- target memory, disassemble, etc. Note that BUF refers to a buffer
- in GDB's memory, not the inferior's.
-
- For example, if the current architecture is the Intel x86, this
- function extracts a little-endian integer of the appropriate
- length from BUF and returns it. However, if the current
- architecture is the D10V, this function will return a 16-bit
- integer extracted from BUF, multiplied by four if TYPE is a
- pointer to a function.
-
- If TYPE is not a pointer or reference type, then this function
- will signal an internal error.
-
- -- Function: CORE_ADDR store_typed_address (void *BUF, struct type
- *TYPE, CORE_ADDR ADDR)
- Store the address ADDR in BUF, in the proper format for a pointer
- of type TYPE in the current architecture. Note that BUF refers to
- a buffer in GDB's memory, not the inferior's.
-
- For example, if the current architecture is the Intel x86, this
- function stores ADDR unmodified as a little-endian integer of the
- appropriate length in BUF. However, if the current architecture
- is the D10V, this function divides ADDR by four if TYPE is a
- pointer to a function, and then stores it in BUF.
-
- If TYPE is not a pointer or reference type, then this function
- will signal an internal error.
-
- -- Function: CORE_ADDR value_as_address (struct value *VAL)
- Assuming that VAL is a pointer, return the address it represents,
- as appropriate for the current architecture.
-
- This function actually works on integral values, as well as
- pointers. For pointers, it performs architecture-specific
- conversions as described above for `extract_typed_address'.
-
- -- Function: CORE_ADDR value_from_pointer (struct type *TYPE,
- CORE_ADDR ADDR)
- Create and return a value representing a pointer of type TYPE to
- the address ADDR, as appropriate for the current architecture.
- This function performs architecture-specific conversions as
- described above for `store_typed_address'.
-
- Here are two functions which architectures can define to indicate the
-relationship between pointers and addresses. These have default
-definitions, appropriate for architectures on which all pointers are
-simple unsigned byte addresses.
-
- -- Function: CORE_ADDR gdbarch_pointer_to_address (struct gdbarch
- *GDBARCH, struct type *TYPE, char *BUF)
- Assume that BUF holds a pointer of type TYPE, in the appropriate
- format for the current architecture. Return the byte address the
- pointer refers to.
-
- This function may safely assume that TYPE is either a pointer or a
- C++ reference type.
-
- -- Function: void gdbarch_address_to_pointer (struct gdbarch *GDBARCH,
- struct type *TYPE, char *BUF, CORE_ADDR ADDR)
- Store in BUF a pointer of type TYPE representing the address ADDR,
- in the appropriate format for the current architecture.
-
- This function may safely assume that TYPE is either a pointer or a
- C++ reference type.
-
- ---------- Footnotes ----------
-
- (1) Some D10V instructions are actually pairs of 16-bit
-sub-instructions. However, since you can't jump into the middle of
-such a pair, code addresses can only refer to full 32 bit instructions,
-which is what matters in this explanation.
-
-
-File: gdbint.info, Node: Address Classes, Next: Register Representation, Prev: Pointers and Addresses, Up: Target Architecture Definition
-
-11.5 Address Classes
-====================
-
-Sometimes information about different kinds of addresses is available
-via the debug information. For example, some programming environments
-define addresses of several different sizes. If the debug information
-distinguishes these kinds of address classes through either the size
-info (e.g, `DW_AT_byte_size' in DWARF 2) or through an explicit address
-class attribute (e.g, `DW_AT_address_class' in DWARF 2), the following
-macros should be defined in order to disambiguate these types within
-GDB as well as provide the added information to a GDB user when
-printing type expressions.
-
- -- Function: int gdbarch_address_class_type_flags (struct gdbarch
- *GDBARCH, int BYTE_SIZE, int DWARF2_ADDR_CLASS)
- Returns the type flags needed to construct a pointer type whose
- size is BYTE_SIZE and whose address class is DWARF2_ADDR_CLASS.
- This function is normally called from within a symbol reader. See
- `dwarf2read.c'.
-
- -- Function: char * gdbarch_address_class_type_flags_to_name (struct
- gdbarch *GDBARCH, int TYPE_FLAGS)
- Given the type flags representing an address class qualifier,
- return its name.
-
- -- Function: int gdbarch_address_class_name_to_type_flags (struct
- gdbarch *GDBARCH, int NAME, int *TYPE_FLAGS_PTR)
- Given an address qualifier name, set the `int' referenced by
- TYPE_FLAGS_PTR to the type flags for that address class qualifier.
-
- Since the need for address classes is rather rare, none of the
-address class functions are defined by default. Predicate functions
-are provided to detect when they are defined.
-
- Consider a hypothetical architecture in which addresses are normally
-32-bits wide, but 16-bit addresses are also supported. Furthermore,
-suppose that the DWARF 2 information for this architecture simply uses
-a `DW_AT_byte_size' value of 2 to indicate the use of one of these
-"short" pointers. The following functions could be defined to
-implement the address class functions:
-
- somearch_address_class_type_flags (int byte_size,
- int dwarf2_addr_class)
- {
- if (byte_size == 2)
- return TYPE_FLAG_ADDRESS_CLASS_1;
- else
- return 0;
- }
-
- static char *
- somearch_address_class_type_flags_to_name (int type_flags)
- {
- if (type_flags & TYPE_FLAG_ADDRESS_CLASS_1)
- return "short";
- else
- return NULL;
- }
-
- int
- somearch_address_class_name_to_type_flags (char *name,
- int *type_flags_ptr)
- {
- if (strcmp (name, "short") == 0)
- {
- *type_flags_ptr = TYPE_FLAG_ADDRESS_CLASS_1;
- return 1;
- }
- else
- return 0;
- }
-
- The qualifier `@short' is used in GDB's type expressions to indicate
-the presence of one of these "short" pointers. For example if the
-debug information indicates that `short_ptr_var' is one of these short
-pointers, GDB might show the following behavior:
-
- (gdb) ptype short_ptr_var
- type = int * @short
-
-
-File: gdbint.info, Node: Register Representation, Next: Frame Interpretation, Prev: Address Classes, Up: Target Architecture Definition
-
-11.6 Register Representation
-============================
-
-* Menu:
-
-* Raw and Cooked Registers::
-* Register Architecture Functions & Variables::
-* Register Information Functions::
-* Register and Memory Data::
-* Register Caching::
-
-
-File: gdbint.info, Node: Raw and Cooked Registers, Next: Register Architecture Functions & Variables, Up: Register Representation
-
-11.6.1 Raw and Cooked Registers
--------------------------------
-
-GDB considers registers to be a set with members numbered linearly from
-0 upwards. The first part of that set corresponds to real physical
-registers, the second part to any "pseudo-registers". Pseudo-registers
-have no independent physical existence, but are useful representations
-of information within the architecture. For example the OpenRISC 1000
-architecture has up to 32 general purpose registers, which are
-typically represented as 32-bit (or 64-bit) integers. However the GPRs
-are also used as operands to the floating point operations, and it
-could be convenient to define a set of pseudo-registers, to show the
-GPRs represented as floating point values.
-
- For any architecture, the implementer will decide on a mapping from
-hardware to GDB register numbers. The registers corresponding to real
-hardware are referred to as "raw" registers, the remaining registers are
-"pseudo-registers". The total register set (raw and pseudo) is called
-the "cooked" register set.
-
-
-File: gdbint.info, Node: Register Architecture Functions & Variables, Next: Register Information Functions, Prev: Raw and Cooked Registers, Up: Register Representation
-
-11.6.2 Functions and Variables Specifying the Register Architecture
--------------------------------------------------------------------
-
-These `struct gdbarch' functions and variables specify the number and
-type of registers in the architecture.
-
- -- Architecture Function: CORE_ADDR read_pc (struct regcache *REGCACHE)
-
- -- Architecture Function: void write_pc (struct regcache *REGCACHE,
- CORE_ADDR VAL)
- Read or write the program counter. The default value of both
- functions is `NULL' (no function available). If the program
- counter is just an ordinary register, it can be specified in
- `struct gdbarch' instead (see `pc_regnum' below) and it will be
- read or written using the standard routines to access registers.
- This function need only be specified if the program counter is not
- an ordinary register.
-
- Any register information can be obtained using the supplied
- register cache, REGCACHE. *Note Register Caching: Register
- Caching.
-
-
- -- Architecture Function: void pseudo_register_read (struct gdbarch
- *GDBARCH, struct regcache *REGCACHE, int REGNUM, const
- gdb_byte *BUF)
-
- -- Architecture Function: void pseudo_register_write (struct gdbarch
- *GDBARCH, struct regcache *REGCACHE, int REGNUM, const
- gdb_byte *BUF)
- These functions should be defined if there are any
- pseudo-registers. The default value is `NULL'. REGNUM is the
- number of the register to read or write (which will be a "cooked"
- register number) and BUF is the buffer where the value read will be
- placed, or from which the value to be written will be taken. The
- value in the buffer may be converted to or from a signed or
- unsigned integral value using one of the utility functions (*note
- Using Different Register and Memory Data Representations: Register
- and Memory Data.).
-
- The access should be for the specified architecture, GDBARCH. Any
- register information can be obtained using the supplied register
- cache, REGCACHE. *Note Register Caching: Register Caching.
-
-
- -- Architecture Variable: int sp_regnum
- This specifies the register holding the stack pointer, which may
- be a raw or pseudo-register. It defaults to -1 (not defined), but
- it is an error for it not to be defined.
-
- The value of the stack pointer register can be accessed withing
- GDB as the variable `$sp'.
-
-
- -- Architecture Variable: int pc_regnum
- This specifies the register holding the program counter, which may
- be a raw or pseudo-register. It defaults to -1 (not defined). If
- `pc_regnum' is not defined, then the functions `read_pc' and
- `write_pc' (see above) must be defined.
-
- The value of the program counter (whether defined as a register, or
- through `read_pc' and `write_pc') can be accessed withing GDB as
- the variable `$pc'.
-
-
- -- Architecture Variable: int ps_regnum
- This specifies the register holding the processor status (often
- called the status register), which may be a raw or
- pseudo-register. It defaults to -1 (not defined).
-
- If defined, the value of this register can be accessed withing GDB
- as the variable `$ps'.
-
-
- -- Architecture Variable: int fp0_regnum
- This specifies the first floating point register. It defaults to
- 0. `fp0_regnum' is not needed unless the target offers support
- for floating point.
-
-
-
-File: gdbint.info, Node: Register Information Functions, Next: Register and Memory Data, Prev: Register Architecture Functions & Variables, Up: Register Representation
-
-11.6.3 Functions Giving Register Information
---------------------------------------------
-
-These functions return information about registers.
-
- -- Architecture Function: const char * register_name (struct gdbarch
- *GDBARCH, int REGNUM)
- This function should convert a register number (raw or pseudo) to a
- register name (as a C `const char *'). This is used both to
- determine the name of a register for output and to work out the
- meaning of any register names used as input. The function may
- also return `NULL', to indicate that REGNUM is not a valid
- register.
-
- For example with the OpenRISC 1000, GDB registers 0-31 are the
- General Purpose Registers, register 32 is the program counter and
- register 33 is the supervision register (i.e. the processor status
- register), which map to the strings `"gpr00"' through `"gpr31"',
- `"pc"' and `"sr"' respectively. This means that the GDB command
- `print $gpr5' should print the value of the OR1K general purpose
- register 5(1).
-
- The default value for this function is `NULL', meaning undefined.
- It should always be defined.
-
- The access should be for the specified architecture, GDBARCH.
-
-
- -- Architecture Function: struct type * register_type (struct gdbarch
- *GDBARCH, int REGNUM)
- Given a register number, this function identifies the type of data
- it may be holding, specified as a `struct type'. GDB allows
- creation of arbitrary types, but a number of built in types are
- provided (`builtin_type_void', `builtin_type_int32' etc), together
- with functions to derive types from these.
-
- Typically the program counter will have a type of "pointer to
- function" (it points to code), the frame pointer and stack pointer
- will have types of "pointer to void" (they point to data on the
- stack) and all other integer registers will have a type of 32-bit
- integer or 64-bit integer.
-
- This information guides the formatting when displaying register
- information. The default value is `NULL' meaning no information is
- available to guide formatting when displaying registers.
-
-
- -- Architecture Function: void print_registers_info (struct gdbarch
- *GDBARCH, struct ui_file *FILE, struct frame_info *FRAME, int
- REGNUM, int ALL)
- Define this function to print out one or all of the registers for
- the GDB `info registers' command. The default value is the
- function `default_print_registers_info', which uses the register
- type information (see `register_type' above) to determine how each
- register should be printed. Define a custom version of this
- function for fuller control over how the registers are displayed.
-
- The access should be for the specified architecture, GDBARCH, with
- output to the the file specified by the User Interface Independent
- Output file handle, FILE (*note UI-Independent Output--the
- `ui_out' Functions: UI-Independent Output.).
-
- The registers should show their values in the frame specified by
- FRAME. If REGNUM is -1 and ALL is zero, then all the
- "significant" registers should be shown (the implementer should
- decide which registers are "significant"). Otherwise only the
- value of the register specified by REGNUM should be output. If
- REGNUM is -1 and ALL is non-zero (true), then the value of all
- registers should be shown.
-
- By default `default_print_registers_info' prints one register per
- line, and if ALL is zero omits floating-point registers.
-
-
- -- Architecture Function: void print_float_info (struct gdbarch
- *GDBARCH, struct ui_file *FILE, struct frame_info *FRAME,
- const char *ARGS)
- Define this function to provide output about the floating point
- unit and registers for the GDB `info float' command respectively.
- The default value is `NULL' (not defined), meaning no information
- will be provided.
-
- The GDBARCH and FILE and FRAME arguments have the same meaning as
- in the `print_registers_info' function above. The string ARGS
- contains any supplementary arguments to the `info float' command.
-
- Define this function if the target supports floating point
- operations.
-
-
- -- Architecture Function: void print_vector_info (struct gdbarch
- *GDBARCH, struct ui_file *FILE, struct frame_info *FRAME,
- const char *ARGS)
- Define this function to provide output about the vector unit and
- registers for the GDB `info vector' command respectively. The
- default value is `NULL' (not defined), meaning no information will
- be provided.
-
- The GDBARCH, FILE and FRAME arguments have the same meaning as in
- the `print_registers_info' function above. The string ARGS
- contains any supplementary arguments to the `info vector' command.
-
- Define this function if the target supports vector operations.
-
-
- -- Architecture Function: int register_reggroup_p (struct gdbarch
- *GDBARCH, int REGNUM, struct reggroup *GROUP)
- GDB groups registers into different categories (general, vector,
- floating point etc). This function, given a register, REGNUM, and
- group, GROUP, returns 1 (true) if the register is in the group and
- 0 (false) otherwise.
-
- The information should be for the specified architecture, GDBARCH
-
- The default value is the function `default_register_reggroup_p'
- which will do a reasonable job based on the type of the register
- (see the function `register_type' above), with groups for general
- purpose registers, floating point registers, vector registers and
- raw (i.e not pseudo) registers.
-
-
- ---------- Footnotes ----------
-
- (1) Historically, GDB always had a concept of a frame pointer
-register, which could be accessed via the GDB variable, `$fp'. That
-concept is now deprecated, recognizing that not all architectures have
-a frame pointer. However if an architecture does have a frame pointer
-register, and defines a register or pseudo-register with the name
-`"fp"', then that register will be used as the value of the `$fp'
-variable.
-
-
-File: gdbint.info, Node: Register and Memory Data, Next: Register Caching, Prev: Register Information Functions, Up: Register Representation
-
-11.6.4 Using Different Register and Memory Data Representations
----------------------------------------------------------------
-
-Some architectures have different representations of data objects,
-depending whether the object is held in a register or memory. For
-example:
-
- * The Alpha architecture can represent 32 bit integer values in
- floating-point registers.
-
- * The x86 architecture supports 80-bit floating-point registers. The
- `long double' data type occupies 96 bits in memory but only 80
- bits when stored in a register.
-
-
- In general, the register representation of a data type is determined
-by the architecture, or GDB's interface to the architecture, while the
-memory representation is determined by the Application Binary Interface.
-
- For almost all data types on almost all architectures, the two
-representations are identical, and no special handling is needed.
-However, they do occasionally differ. An architecture may define the
-following `struct gdbarch' functions to request conversions between the
-register and memory representations of a data type:
-
- -- Architecture Function: int gdbarch_convert_register_p (struct
- gdbarch *GDBARCH, int REG)
- Return non-zero (true) if the representation of a data value
- stored in this register may be different to the representation of
- that same data value when stored in memory. The default value is
- `NULL' (undefined).
-
- If this function is defined and returns non-zero, the `struct
- gdbarch' functions `gdbarch_register_to_value' and
- `gdbarch_value_to_register' (see below) should be used to perform
- any necessary conversion.
-
- If defined, this function should return zero for the register's
- native type, when no conversion is necessary.
-
- -- Architecture Function: void gdbarch_register_to_value (struct
- gdbarch *GDBARCH, int REG, struct type *TYPE, char *FROM,
- char *TO)
- Convert the value of register number REG to a data object of type
- TYPE. The buffer at FROM holds the register's value in raw
- format; the converted value should be placed in the buffer at TO.
-
- _Note:_ `gdbarch_register_to_value' and
- `gdbarch_value_to_register' take their REG and TYPE arguments
- in different orders.
-
- `gdbarch_register_to_value' should only be used with registers for
- which the `gdbarch_convert_register_p' function returns a non-zero
- value.
-
-
- -- Architecture Function: void gdbarch_value_to_register (struct
- gdbarch *GDBARCH, struct type *TYPE, int REG, char *FROM,
- char *TO)
- Convert a data value of type TYPE to register number REG' raw
- format.
-
- _Note:_ `gdbarch_register_to_value' and
- `gdbarch_value_to_register' take their REG and TYPE arguments
- in different orders.
-
- `gdbarch_value_to_register' should only be used with registers for
- which the `gdbarch_convert_register_p' function returns a non-zero
- value.
-
-
-
-File: gdbint.info, Node: Register Caching, Prev: Register and Memory Data, Up: Register Representation
-
-11.6.5 Register Caching
------------------------
-
-Caching of registers is used, so that the target does not need to be
-accessed and reanalyzed multiple times for each register in
-circumstances where the register value cannot have changed.
-
- GDB provides `struct regcache', associated with a particular `struct
-gdbarch' to hold the cached values of the raw registers. A set of
-functions is provided to access both the raw registers (with `raw' in
-their name) and the full set of cooked registers (with `cooked' in
-their name). Functions are provided to ensure the register cache is
-kept synchronized with the values of the actual registers in the target.
-
- Accessing registers through the `struct regcache' routines will
-ensure that the appropriate `struct gdbarch' functions are called when
-necessary to access the underlying target architecture. In general
-users should use the "cooked" functions, since these will map to the
-"raw" functions automatically as appropriate.
-
- The two key functions are `regcache_cooked_read' and
-`regcache_cooked_write' which read or write a register from or to a
-byte buffer (type `gdb_byte *'). For convenience the wrapper functions
-`regcache_cooked_read_signed', `regcache_cooked_read_unsigned',
-`regcache_cooked_write_signed' and `regcache_cooked_write_unsigned' are
-provided, which read or write the value using the buffer and convert to
-or from an integral value as appropriate.
-
-
-File: gdbint.info, Node: Frame Interpretation, Next: Inferior Call Setup, Prev: Register Representation, Up: Target Architecture Definition
-
-11.7 Frame Interpretation
-=========================
-
-* Menu:
-
-* All About Stack Frames::
-* Frame Handling Terminology::
-* Prologue Caches::
-* Functions and Variable to Analyze Frames::
-* Functions to Access Frame Data::
-* Analyzing Stacks---Frame Sniffers::
-
-
-File: gdbint.info, Node: All About Stack Frames, Next: Frame Handling Terminology, Up: Frame Interpretation
-
-11.7.1 All About Stack Frames
------------------------------
-
-GDB needs to understand the stack on which local (automatic) variables
-are stored. The area of the stack containing all the local variables
-for a function invocation is known as the "stack frame" for that
-function (or colloquially just as the "frame"). In turn the function
-that called the function will have its stack frame, and so on back
-through the chain of functions that have been called.
-
- Almost all architectures have one register dedicated to point to the
-end of the stack (the "stack pointer"). Many have a second register
-which points to the start of the currently active stack frame (the
-"frame pointer"). The specific arrangements for an architecture are a
-key part of the ABI.
-
- A diagram helps to explain this. Here is a simple program to compute
-factorials:
-
- #include <stdio.h>
- int fact (int n)
- {
- if (0 == n)
- {
- return 1;
- }
- else
- {
- return n * fact (n - 1);
- }
- }
-
- main ()
- {
- int i;
-
- for (i = 0; i < 10; i++)
- {
- int f = fact (i);
- printf ("%d! = %d\n", i, f);
- }
- }
-
- Consider the state of the stack when the code reaches line 6 after
-the main program has called `fact (3)'. The chain of function calls
-will be `main ()', `fact (3)', `fact (2)', `fact (1)' and `fact (0)'.
-
- In this illustration the stack is falling (as used for example by the
-OpenRISC 1000 ABI). The stack pointer (SP) is at the end of the stack
-(lowest address) and the frame pointer (FP) is at the highest address
-in the current stack frame. The following diagram shows how the stack
-looks.
-
- ^ ->| |
-Frame | | | |
-Number - | | |============| int fact (int n)
- | | | | i = 3 | {
- | | | |------------| if (0 == n) {
- | | | | f = ? | return 1; <-------- PC
- #4 main() < | | |------------| }
- | | | | | else {
- | | -+->|------------| ---> return n * fact (n - 1);
- | -+-+--+-----o | | }
- = | | |============| | }
- | | | | n = 3 | |
- | | | |------------| | main ()
- #3 fact (3) < | | | o---------+- {
- | -+-+->|------------| | | int i;
- | | | --+-----o | | |
- = | | |============| | | for (i = 0; i < 10; i++) {
- | | | | n = 2 | | -> int f = fact (i);
- | | | |------------| | printf ("%d! = %d\n", i , f);
- #2 fact (2) < | | | o------+--| }
- | | | ->|------------| | }
- | | -+--+-----o | |
- = | | |============| |
- | | | | n = 1 | |
- | | | |------------| |
- #1 fact (1) < | | | o------+--|
- | | | |------------| |
- | ---|--+-----o |<-+------- FP
- = | |============| | |
- | | | n = 0 | | |
- | | |------------| | |
- #0 fact (0) < | | o--------- |
- | | |------------| |
- | --+-----o |<--------- SP |
- = |============| |
- | | Red Zone | v
- | \/\/\/\/\/\/\/ Direction of
- #-1 < \/\/\/\/\/\/\/ stack growth
- | | |
-
-In each stack frame, offset 0 from the stack pointer is the frame
-pointer of the previous frame and offset 4 (this is illustrating a
-32-bit architecture) from the stack pointer is the return address.
-Local variables are indexed from the frame pointer, with negative
-indexes. In the function `fact', offset -4 from the frame pointer is
-the argument N. In the `main' function, offset -4 from the frame
-pointer is the local variable I and offset -8 from the frame pointer is
-the local variable F(1).
-
- It is very easy to get confused when examining stacks. GDB has
-terminology it uses rigorously throughout. The stack frame of the
-function currently executing, or where execution stopped is numbered
-zero. In this example frame #0 is the stack frame of the call to
-`fact (0)'. The stack frame of its calling function (`fact (1)' in
-this case) is numbered #1 and so on back through the chain of calls.
-
- The main GDB data structure describing frames is
-`struct frame_info'. It is not used directly, but only via its
-accessor functions. `frame_info' includes information about the
-registers in the frame and a pointer to the code of the function with
-which the frame is associated. The entire stack is represented as a
-linked list of `frame_info' structs.
-
- ---------- Footnotes ----------
-
- (1) This is a simplified example for illustrative purposes only.
-Good optimizing compilers would not put anything on the stack for such
-simple functions. Indeed they might eliminate the recursion and use of
-the stack entirely!
-
-
-File: gdbint.info, Node: Frame Handling Terminology, Next: Prologue Caches, Prev: All About Stack Frames, Up: Frame Interpretation
-
-11.7.2 Frame Handling Terminology
----------------------------------
-
-It is easy to get confused when referencing stack frames. GDB uses
-some precise terminology.
-
- * "THIS" frame is the frame currently under consideration.
-
- * The "NEXT" frame, also sometimes called the inner or newer frame
- is the frame of the function called by the function of THIS frame.
-
- * The "PREVIOUS" frame, also sometimes called the outer or older
- frame is the frame of the function which called the function of
- THIS frame.
-
-
- So in the example in the previous section (*note All About Stack
-Frames: All About Stack Frames.), if THIS frame is #3 (the call to
-`fact (3)'), the NEXT frame is frame #2 (the call to `fact (2)') and
-the PREVIOUS frame is frame #4 (the call to `main ()').
-
- The "innermost" frame is the frame of the current executing
-function, or where the program stopped, in this example, in the middle
-of the call to `fact (0))'. It is always numbered frame #0.
-
- The "base" of a frame is the address immediately before the start of
-the NEXT frame. For a stack which grows down in memory (a "falling"
-stack) this will be the lowest address and for a stack which grows up
-in memory (a "rising" stack) this will be the highest address in the
-frame.
-
- GDB functions to analyze the stack are typically given a pointer to
-the NEXT frame to determine information about THIS frame. Information
-about THIS frame includes data on where the registers of the PREVIOUS
-frame are stored in this stack frame. In this example the frame
-pointer of the PREVIOUS frame is stored at offset 0 from the stack
-pointer of THIS frame.
-
- The process whereby a function is given a pointer to the NEXT frame
-to work out information about THIS frame is referred to as "unwinding".
-The GDB functions involved in this typically include unwind in their
-name.
-
- The process of analyzing a target to determine the information that
-should go in struct frame_info is called "sniffing". The functions
-that carry this out are called sniffers and typically include sniffer
-in their name. More than one sniffer may be required to extract all
-the information for a particular frame.
-
- Because so many functions work using the NEXT frame, there is an
-issue about addressing the innermost frame--it has no NEXT frame. To
-solve this GDB creates a dummy frame #-1, known as the "sentinel" frame.
-
-
-File: gdbint.info, Node: Prologue Caches, Next: Functions and Variable to Analyze Frames, Prev: Frame Handling Terminology, Up: Frame Interpretation
-
-11.7.3 Prologue Caches
-----------------------
-
-All the frame sniffing functions typically examine the code at the
-start of the corresponding function, to determine the state of
-registers. The ABI will save old values and set new values of key
-registers at the start of each function in what is known as the
-function "prologue".
-
- For any particular stack frame this data does not change, so all the
-standard unwinding functions, in addition to receiving a pointer to the
-NEXT frame as their first argument, receive a pointer to a "prologue
-cache" as their second argument. This can be used to store values
-associated with a particular frame, for reuse on subsequent calls
-involving the same frame.
-
- It is up to the user to define the structure used (it is a `void *'
-pointer) and arrange allocation and deallocation of storage. However
-for general use, GDB provides `struct trad_frame_cache', with a set of
-accessor routines. This structure holds the stack and code address of
-THIS frame, the base address of the frame, a pointer to the struct
-`frame_info' for the NEXT frame and details of where the registers of
-the PREVIOUS frame may be found in THIS frame.
-
- Typically the first time any sniffer function is called with NEXT
-frame, the prologue sniffer for THIS frame will be `NULL'. The sniffer
-will analyze the frame, allocate a prologue cache structure and
-populate it. Subsequent calls using the same NEXT frame will pass in
-this prologue cache, so the data can be returned with no additional
-analysis.
-
-
-File: gdbint.info, Node: Functions and Variable to Analyze Frames, Next: Functions to Access Frame Data, Prev: Prologue Caches, Up: Frame Interpretation
-
-11.7.4 Functions and Variable to Analyze Frames
------------------------------------------------
-
-These struct `gdbarch' functions and variable should be defined to
-provide analysis of the stack frame and allow it to be adjusted as
-required.
-
- -- Architecture Function: CORE_ADDR skip_prologue (struct gdbarch
- *GDBARCH, CORE_ADDR PC)
- The prologue of a function is the code at the beginning of the
- function which sets up the stack frame, saves the return address
- etc. The code representing the behavior of the function starts
- after the prologue.
-
- This function skips past the prologue of a function if the program
- counter, PC, is within the prologue of a function. The result is
- the program counter immediately after the prologue. With modern
- optimizing compilers, this may be a far from trivial exercise.
- However the required information may be within the binary as
- DWARF2 debugging information, making the job much easier.
-
- The default value is `NULL' (not defined). This function should
- always be provided, but can take advantage of DWARF2 debugging
- information, if that is available.
-
-
- -- Architecture Function: int inner_than (CORE_ADDR LHS, CORE_ADDR RHS)
- Given two frame or stack pointers, return non-zero (true) if the
- first represents the "inner" stack frame and 0 (false) otherwise.
- This is used to determine whether the target has a stack which
- grows up in memory (rising stack) or grows down in memory (falling
- stack). *Note All About Stack Frames: All About Stack Frames, for
- an explanation of "inner" frames.
-
- The default value of this function is `NULL' and it should always
- be defined. However for almost all architectures one of the
- built-in functions can be used: `core_addr_lessthan' (for stacks
- growing down in memory) or `core_addr_greaterthan' (for stacks
- growing up in memory).
-
-
- -- Architecture Function: CORE_ADDR frame_align (struct gdbarch
- *GDBARCH, CORE_ADDR ADDRESS)
- The architecture may have constraints on how its frames are
- aligned. For example the OpenRISC 1000 ABI requires stack frames
- to be double-word aligned, but 32-bit versions of the architecture
- allocate single-word values to the stack. Thus extra padding may
- be needed at the end of a stack frame.
-
- Given a proposed address for the stack pointer, this function
- returns a suitably aligned address (by expanding the stack frame).
-
- The default value is `NULL' (undefined). This function should be
- defined for any architecture where it is possible the stack could
- become misaligned. The utility functions `align_down' (for falling
- stacks) and `align_up' (for rising stacks) will facilitate the
- implementation of this function.
-
-
- -- Architecture Variable: int frame_red_zone_size
- Some ABIs reserve space beyond the end of the stack for use by leaf
- functions without prologue or epilogue or by exception handlers
- (for example the OpenRISC 1000).
-
- This is known as a "red zone" (AMD terminology). The AMD64 (nee
- x86-64) ABI documentation refers to the "red zone" when describing
- this scratch area.
-
- The default value is 0. Set this field if the architecture has
- such a red zone. The value must be aligned as required by the ABI
- (see `frame_align' above for an explanation of stack frame
- alignment).
-
-
-
-File: gdbint.info, Node: Functions to Access Frame Data, Next: Analyzing Stacks---Frame Sniffers, Prev: Functions and Variable to Analyze Frames, Up: Frame Interpretation
-
-11.7.5 Functions to Access Frame Data
--------------------------------------
-
-These functions provide access to key registers and arguments in the
-stack frame.
-
- -- Architecture Function: CORE_ADDR unwind_pc (struct gdbarch
- *GDBARCH, struct frame_info *NEXT_FRAME)
- This function is given a pointer to the NEXT stack frame (*note
- All About Stack Frames: All About Stack Frames, for how frames are
- represented) and returns the value of the program counter in the
- PREVIOUS frame (i.e. the frame of the function that called THIS
- one). This is commonly referred to as the "return address".
-
- The implementation, which must be frame agnostic (work with any
- frame), is typically no more than:
-
- ULONGEST pc;
- pc = frame_unwind_register_unsigned (next_frame, ARCH_PC_REGNUM);
- return gdbarch_addr_bits_remove (gdbarch, pc);
-
-
- -- Architecture Function: CORE_ADDR unwind_sp (struct gdbarch
- *GDBARCH, struct frame_info *NEXT_FRAME)
- This function is given a pointer to the NEXT stack frame (*note
- All About Stack Frames: All About Stack Frames. for how frames are
- represented) and returns the value of the stack pointer in the
- PREVIOUS frame (i.e. the frame of the function that called THIS
- one).
-
- The implementation, which must be frame agnostic (work with any
- frame), is typically no more than:
-
- ULONGEST sp;
- sp = frame_unwind_register_unsigned (next_frame, ARCH_SP_REGNUM);
- return gdbarch_addr_bits_remove (gdbarch, sp);
-
-
- -- Architecture Function: int frame_num_args (struct gdbarch *GDBARCH,
- struct frame_info *THIS_FRAME)
- This function is given a pointer to THIS stack frame (*note All
- About Stack Frames: All About Stack Frames. for how frames are
- represented), and returns the number of arguments that are being
- passed, or -1 if not known.
-
- The default value is `NULL' (undefined), in which case the number
- of arguments passed on any stack frame is always unknown. For many
- architectures this will be a suitable default.
-
-
-
-File: gdbint.info, Node: Analyzing Stacks---Frame Sniffers, Prev: Functions to Access Frame Data, Up: Frame Interpretation
-
-11.7.6 Analyzing Stacks--Frame Sniffers
----------------------------------------
-
-When a program stops, GDB needs to construct the chain of struct
-`frame_info' representing the state of the stack using appropriate
-"sniffers".
-
- Each architecture requires appropriate sniffers, but they do not form
-entries in `struct gdbarch', since more than one sniffer may be
-required and a sniffer may be suitable for more than one
-`struct gdbarch'. Instead sniffers are associated with architectures
-using the following functions.
-
- * `frame_unwind_append_sniffer' is used to add a new sniffer to
- analyze THIS frame when given a pointer to the NEXT frame.
-
- * `frame_base_append_sniffer' is used to add a new sniffer which can
- determine information about the base of a stack frame.
-
- * `frame_base_set_default' is used to specify the default base
- sniffer.
-
-
- These functions all take a reference to `struct gdbarch', so they
-are associated with a specific architecture. They are usually called
-in the `gdbarch' initialization function, after the `gdbarch' struct
-has been set up. Unless a default has been set, the most recently
-appended sniffer will be tried first.
-
- The main frame unwinding sniffer (as set by
-`frame_unwind_append_sniffer)' returns a structure specifying a set of
-sniffing functions:
-
- struct frame_unwind
- {
- enum frame_type type;
- frame_this_id_ftype *this_id;
- frame_prev_register_ftype *prev_register;
- const struct frame_data *unwind_data;
- frame_sniffer_ftype *sniffer;
- frame_prev_pc_ftype *prev_pc;
- frame_dealloc_cache_ftype *dealloc_cache;
- };
-
- The `type' field indicates the type of frame this sniffer can
-handle: normal, dummy (*note Functions Creating Dummy Frames: Functions
-Creating Dummy Frames.), signal handler or sentinel. Signal handlers
-sometimes have their own simplified stack structure for efficiency, so
-may need their own handlers.
-
- The `unwind_data' field holds additional information which may be
-relevant to particular types of frame. For example it may hold
-additional information for signal handler frames.
-
- The remaining fields define functions that yield different types of
-information when given a pointer to the NEXT stack frame. Not all
-functions need be provided. If an entry is `NULL', the next sniffer
-will be tried instead.
-
- * `this_id' determines the stack pointer and function (code entry
- point) for THIS stack frame.
-
- * `prev_register' determines where the values of registers for the
- PREVIOUS stack frame are stored in THIS stack frame.
-
- * `sniffer' takes a look at THIS frame's registers to determine if
- this is the appropriate unwinder.
-
- * `prev_pc' determines the program counter for THIS frame. Only
- needed if the program counter is not an ordinary register (*note
- Functions and Variables Specifying the Register Architecture:
- Register Architecture Functions & Variables.).
-
- * `dealloc_cache' frees any additional memory associated with the
- prologue cache for this frame (*note Prologue Caches: Prologue
- Caches.).
-
-
- In general it is only the `this_id' and `prev_register' fields that
-need be defined for custom sniffers.
-
- The frame base sniffer is much simpler. It is a
-`struct frame_base', which refers to the corresponding `frame_unwind'
-struct and whose fields refer to functions yielding various addresses
-within the frame.
-
- struct frame_base
- {
- const struct frame_unwind *unwind;
- frame_this_base_ftype *this_base;
- frame_this_locals_ftype *this_locals;
- frame_this_args_ftype *this_args;
- };
-
- All the functions referred to take a pointer to the NEXT frame as
-argument. The function referred to by `this_base' returns the base
-address of THIS frame, the function referred to by `this_locals'
-returns the base address of local variables in THIS frame and the
-function referred to by `this_args' returns the base address of the
-function arguments in this frame.
-
- As described above, the base address of a frame is the address
-immediately before the start of the NEXT frame. For a falling stack,
-this is the lowest address in the frame and for a rising stack it is
-the highest address in the frame. For most architectures the same
-address is also the base address for local variables and arguments, in
-which case the same function can be used for all three entries(1).
-
- ---------- Footnotes ----------
-
- (1) It is worth noting that if it cannot be determined in any other
-way (for example by there being a register with the name `"fp"'), then
-the result of the `this_base' function will be used as the value of the
-frame pointer variable `$fp' in GDB. This is very often not correct
-(for example with the OpenRISC 1000, this value is the stack pointer,
-`$sp'). In this case a register (raw or pseudo) with the name `"fp"'
-should be defined. It will be used in preference as the value of `$fp'.
-
-
-File: gdbint.info, Node: Inferior Call Setup, Next: Adding support for debugging core files, Prev: Frame Interpretation, Up: Target Architecture Definition
-
-11.8 Inferior Call Setup
-========================
-
-* Menu:
-
-* About Dummy Frames::
-* Functions Creating Dummy Frames::
-
-
-File: gdbint.info, Node: About Dummy Frames, Next: Functions Creating Dummy Frames, Up: Inferior Call Setup
-
-11.8.1 About Dummy Frames
--------------------------
-
-GDB can call functions in the target code (for example by using the
-`call' or `print' commands). These functions may be breakpointed, and
-it is essential that if a function does hit a breakpoint, commands like
-`backtrace' work correctly.
-
- This is achieved by making the stack look as though the function had
-been called from the point where GDB had previously stopped. This
-requires that GDB can set up stack frames appropriate for such function
-calls.
-
-
-File: gdbint.info, Node: Functions Creating Dummy Frames, Prev: About Dummy Frames, Up: Inferior Call Setup
-
-11.8.2 Functions Creating Dummy Frames
---------------------------------------
-
-The following functions provide the functionality to set up such
-"dummy" stack frames.
-
- -- Architecture Function: CORE_ADDR push_dummy_call (struct gdbarch
- *GDBARCH, struct value *FUNCTION, struct regcache *REGCACHE,
- CORE_ADDR BP_ADDR, int NARGS, struct value **ARGS, CORE_ADDR
- SP, int STRUCT_RETURN, CORE_ADDR STRUCT_ADDR)
- This function sets up a dummy stack frame for the function about
- to be called. `push_dummy_call' is given the arguments to be
- passed and must copy them into registers or push them on to the
- stack as appropriate for the ABI.
-
- FUNCTION is a pointer to the function that will be called and
- REGCACHE the register cache from which values should be obtained.
- BP_ADDR is the address to which the function should return (which
- is breakpointed, so GDB can regain control, hence the name).
- NARGS is the number of arguments to pass and ARGS an array
- containing the argument values. STRUCT_RETURN is non-zero (true)
- if the function returns a structure, and if so STRUCT_ADDR is the
- address in which the structure should be returned.
-
- After calling this function, GDB will pass control to the target
- at the address of the function, which will find the stack and
- registers set up just as expected.
-
- The default value of this function is `NULL' (undefined). If the
- function is not defined, then GDB will not allow the user to call
- functions within the target being debugged.
-
-
- -- Architecture Function: struct frame_id unwind_dummy_id (struct
- gdbarch *GDBARCH, struct frame_info *NEXT_FRAME)
- This is the inverse of `push_dummy_call' which restores the stack
- pointer and program counter after a call to evaluate a function
- using a dummy stack frame. The result is a `struct frame_id',
- which contains the value of the stack pointer and program counter
- to be used.
-
- The NEXT frame pointer is provided as argument, NEXT_FRAME. THIS
- frame is the frame of the dummy function, which can be unwound, to
- yield the required stack pointer and program counter from the
- PREVIOUS frame.
-
- The default value is `NULL' (undefined). If `push_dummy_call' is
- defined, then this function should also be defined.
-
-
- -- Architecture Function: CORE_ADDR push_dummy_code (struct gdbarch
- *GDBARCH, CORE_ADDR SP, CORE_ADDR FUNADDR, struct value
- **ARGS, int NARGS, struct type *VALUE_TYPE, CORE_ADDR
- *REAL_PC, CORE_ADDR *BP_ADDR, struct regcache *REGCACHE)
- If this function is not defined (its default value is `NULL'), a
- dummy call will use the entry point of the currently loaded code
- on the target as its return address. A temporary breakpoint will
- be set there, so the location must be writable and have room for a
- breakpoint.
-
- It is possible that this default is not suitable. It might not be
- writable (in ROM possibly), or the ABI might require code to be
- executed on return from a call to unwind the stack before the
- breakpoint is encountered.
-
- If either of these is the case, then push_dummy_code should be
- defined to push an instruction sequence onto the end of the stack
- to which the dummy call should return.
-
- The arguments are essentially the same as those to
- `push_dummy_call'. However the function is provided with the type
- of the function result, VALUE_TYPE, BP_ADDR is used to return a
- value (the address at which the breakpoint instruction should be
- inserted) and REAL PC is used to specify the resume address when
- starting the call sequence. The function should return the
- updated innermost stack address.
-
- _Note:_ This does require that code in the stack can be
- executed. Some Harvard architectures may not allow this.
-
-
-
-File: gdbint.info, Node: Adding support for debugging core files, Next: Defining Other Architecture Features, Prev: Inferior Call Setup, Up: Target Architecture Definition
-
-11.9 Adding support for debugging core files
-============================================
-
-The prerequisite for adding core file support in GDB is to have core
-file support in BFD.
-
- Once BFD support is available, writing the apropriate
-`regset_from_core_section' architecture function should be all that is
-needed in order to add support for core files in GDB.
-
-
-File: gdbint.info, Node: Defining Other Architecture Features, Next: Adding a New Target, Prev: Adding support for debugging core files, Up: Target Architecture Definition
-
-11.10 Defining Other Architecture Features
-==========================================
-
-This section describes other functions and values in `gdbarch',
-together with some useful macros, that you can use to define the target
-architecture.
-
-`CORE_ADDR gdbarch_addr_bits_remove (GDBARCH, ADDR)'
- If a raw machine instruction address includes any bits that are not
- really part of the address, then this function is used to zero
- those bits in ADDR. This is only used for addresses of
- instructions, and even then not in all contexts.
-
- For example, the two low-order bits of the PC on the
- Hewlett-Packard PA 2.0 architecture contain the privilege level of
- the corresponding instruction. Since instructions must always be
- aligned on four-byte boundaries, the processor masks out these
- bits to generate the actual address of the instruction.
- `gdbarch_addr_bits_remove' would then for example look like that:
- arch_addr_bits_remove (CORE_ADDR addr)
- {
- return (addr &= ~0x3);
- }
-
-`int address_class_name_to_type_flags (GDBARCH, NAME, TYPE_FLAGS_PTR)'
- If NAME is a valid address class qualifier name, set the `int'
- referenced by TYPE_FLAGS_PTR to the mask representing the qualifier
- and return 1. If NAME is not a valid address class qualifier name,
- return 0.
-
- The value for TYPE_FLAGS_PTR should be one of
- `TYPE_FLAG_ADDRESS_CLASS_1', `TYPE_FLAG_ADDRESS_CLASS_2', or
- possibly some combination of these values or'd together. *Note
- Address Classes: Target Architecture Definition.
-
-`int address_class_name_to_type_flags_p (GDBARCH)'
- Predicate which indicates whether
- `address_class_name_to_type_flags' has been defined.
-
-`int gdbarch_address_class_type_flags (GDBARCH, BYTE_SIZE, DWARF2_ADDR_CLASS)'
- Given a pointers byte size (as described by the debug information)
- and the possible `DW_AT_address_class' value, return the type flags
- used by GDB to represent this address class. The value returned
- should be one of `TYPE_FLAG_ADDRESS_CLASS_1',
- `TYPE_FLAG_ADDRESS_CLASS_2', or possibly some combination of these
- values or'd together. *Note Address Classes: Target Architecture
- Definition.
-
-`int gdbarch_address_class_type_flags_p (GDBARCH)'
- Predicate which indicates whether
- `gdbarch_address_class_type_flags_p' has been defined.
-
-`const char *gdbarch_address_class_type_flags_to_name (GDBARCH, TYPE_FLAGS)'
- Return the name of the address class qualifier associated with the
- type flags given by TYPE_FLAGS.
-
-`int gdbarch_address_class_type_flags_to_name_p (GDBARCH)'
- Predicate which indicates whether
- `gdbarch_address_class_type_flags_to_name' has been defined.
- *Note Address Classes: Target Architecture Definition.
-
-`void gdbarch_address_to_pointer (GDBARCH, TYPE, BUF, ADDR)'
- Store in BUF a pointer of type TYPE representing the address ADDR,
- in the appropriate format for the current architecture. This
- function may safely assume that TYPE is either a pointer or a C++
- reference type. *Note Pointers Are Not Always Addresses: Target
- Architecture Definition.
-
-`int gdbarch_believe_pcc_promotion (GDBARCH)'
- Used to notify if the compiler promotes a `short' or `char'
- parameter to an `int', but still reports the parameter as its
- original type, rather than the promoted type.
-
-`gdbarch_bits_big_endian (GDBARCH)'
- This is used if the numbering of bits in the targets does *not*
- match the endianism of the target byte order. A value of 1 means
- that the bits are numbered in a big-endian bit order, 0 means
- little-endian.
-
-`set_gdbarch_bits_big_endian (GDBARCH, BITS_BIG_ENDIAN)'
- Calling set_gdbarch_bits_big_endian with a value of 1 indicates
- that the bits in the target are numbered in a big-endian bit
- order, 0 indicates little-endian.
-
-`BREAKPOINT'
- This is the character array initializer for the bit pattern to put
- into memory where a breakpoint is set. Although it's common to
- use a trap instruction for a breakpoint, it's not required; for
- instance, the bit pattern could be an invalid instruction. The
- breakpoint must be no longer than the shortest instruction of the
- architecture.
-
- `BREAKPOINT' has been deprecated in favor of
- `gdbarch_breakpoint_from_pc'.
-
-`BIG_BREAKPOINT'
-`LITTLE_BREAKPOINT'
- Similar to BREAKPOINT, but used for bi-endian targets.
-
- `BIG_BREAKPOINT' and `LITTLE_BREAKPOINT' have been deprecated in
- favor of `gdbarch_breakpoint_from_pc'.
-
-`const gdb_byte *gdbarch_breakpoint_from_pc (GDBARCH, PCPTR, LENPTR)'
- Use the program counter to determine the contents and size of a
- breakpoint instruction. It returns a pointer to a static string
- of bytes that encode a breakpoint instruction, stores the length
- of the string to `*LENPTR', and adjusts the program counter (if
- necessary) to point to the actual memory location where the
- breakpoint should be inserted. May return `NULL' to indicate that
- software breakpoints are not supported.
-
- Although it is common to use a trap instruction for a breakpoint,
- it's not required; for instance, the bit pattern could be an
- invalid instruction. The breakpoint must be no longer than the
- shortest instruction of the architecture.
-
- Provided breakpoint bytes can be also used by
- `bp_loc_is_permanent' to detect permanent breakpoints.
- `gdbarch_breakpoint_from_pc' should return an unchanged memory
- copy if it was called for a location with permanent breakpoint as
- some architectures use breakpoint instructions containing
- arbitrary parameter value.
-
- Replaces all the other BREAKPOINT macros.
-
-`int gdbarch_memory_insert_breakpoint (GDBARCH, BP_TGT)'
-`gdbarch_memory_remove_breakpoint (GDBARCH, BP_TGT)'
- Insert or remove memory based breakpoints. Reasonable defaults
- (`default_memory_insert_breakpoint' and
- `default_memory_remove_breakpoint' respectively) have been
- provided so that it is not necessary to set these for most
- architectures. Architectures which may want to set
- `gdbarch_memory_insert_breakpoint' and
- `gdbarch_memory_remove_breakpoint' will likely have instructions
- that are oddly sized or are not stored in a conventional manner.
-
- It may also be desirable (from an efficiency standpoint) to define
- custom breakpoint insertion and removal routines if
- `gdbarch_breakpoint_from_pc' needs to read the target's memory for
- some reason.
-
-`CORE_ADDR gdbarch_adjust_breakpoint_address (GDBARCH, BPADDR)'
- Given an address at which a breakpoint is desired, return a
- breakpoint address adjusted to account for architectural
- constraints on breakpoint placement. This method is not needed by
- most targets.
-
- The FR-V target (see `frv-tdep.c') requires this method. The FR-V
- is a VLIW architecture in which a number of RISC-like instructions
- are grouped (packed) together into an aggregate instruction or
- instruction bundle. When the processor executes one of these
- bundles, the component instructions are executed in parallel.
-
- In the course of optimization, the compiler may group instructions
- from distinct source statements into the same bundle. The line
- number information associated with one of the latter statements
- will likely refer to some instruction other than the first one in
- the bundle. So, if the user attempts to place a breakpoint on one
- of these latter statements, GDB must be careful to _not_ place the
- break instruction on any instruction other than the first one in
- the bundle. (Remember though that the instructions within a
- bundle execute in parallel, so the _first_ instruction is the
- instruction at the lowest address and has nothing to do with
- execution order.)
-
- The FR-V's `gdbarch_adjust_breakpoint_address' method will adjust a
- breakpoint's address by scanning backwards for the beginning of
- the bundle, returning the address of the bundle.
-
- Since the adjustment of a breakpoint may significantly alter a
- user's expectation, GDB prints a warning when an adjusted
- breakpoint is initially set and each time that that breakpoint is
- hit.
-
-`int gdbarch_call_dummy_location (GDBARCH)'
- See the file `inferior.h'.
-
- This method has been replaced by `gdbarch_push_dummy_code' (*note
- gdbarch_push_dummy_code::).
-
-`int gdbarch_cannot_fetch_register (GDBARCH, REGUM)'
- This function should return nonzero if REGNO cannot be fetched
- from an inferior process.
-
-`int gdbarch_cannot_store_register (GDBARCH, REGNUM)'
- This function should return nonzero if REGNO should not be written
- to the target. This is often the case for program counters,
- status words, and other special registers. This function returns
- 0 as default so that GDB will assume that all registers may be
- written.
-
-`int gdbarch_convert_register_p (GDBARCH, REGNUM, struct type *TYPE)'
- Return non-zero if register REGNUM represents data values of type
- TYPE in a non-standard form. *Note Using Different Register and
- Memory Data Representations: Target Architecture Definition.
-
-`int gdbarch_fp0_regnum (GDBARCH)'
- This function returns the number of the first floating point
- register, if the machine has such registers. Otherwise, it
- returns -1.
-
-`CORE_ADDR gdbarch_decr_pc_after_break (GDBARCH)'
- This function shall return the amount by which to decrement the PC
- after the program encounters a breakpoint. This is often the
- number of bytes in `BREAKPOINT', though not always. For most
- targets this value will be 0.
-
-`DISABLE_UNSETTABLE_BREAK (ADDR)'
- If defined, this should evaluate to 1 if ADDR is in a shared
- library in which breakpoints cannot be set and so should be
- disabled.
-
-`int gdbarch_dwarf2_reg_to_regnum (GDBARCH, DWARF2_REGNR)'
- Convert DWARF2 register number DWARF2_REGNR into GDB regnum. If
- not defined, no conversion will be performed.
-
-`int gdbarch_ecoff_reg_to_regnum (GDBARCH, ECOFF_REGNR)'
- Convert ECOFF register number ECOFF_REGNR into GDB regnum. If
- not defined, no conversion will be performed.
-
-`GCC_COMPILED_FLAG_SYMBOL'
-`GCC2_COMPILED_FLAG_SYMBOL'
- If defined, these are the names of the symbols that GDB will look
- for to detect that GCC compiled the file. The default symbols are
- `gcc_compiled.' and `gcc2_compiled.', respectively. (Currently
- only defined for the Delta 68.)
-
-`gdbarch_get_longjmp_target'
- This function determines the target PC address that `longjmp' will
- jump to, assuming that we have just stopped at a `longjmp'
- breakpoint. It takes a `CORE_ADDR *' as argument, and stores the
- target PC value through this pointer. It examines the current
- state of the machine as needed, typically by using a
- manually-determined offset into the `jmp_buf'. (While we might
- like to get the offset from the target's `jmpbuf.h', that header
- file cannot be assumed to be available when building a
- cross-debugger.)
-
-`DEPRECATED_IBM6000_TARGET'
- Shows that we are configured for an IBM RS/6000 system. This
- conditional should be eliminated (FIXME) and replaced by
- feature-specific macros. It was introduced in haste and we are
- repenting at leisure.
-
-`I386_USE_GENERIC_WATCHPOINTS'
- An x86-based target can define this to use the generic x86
- watchpoint support; see *note I386_USE_GENERIC_WATCHPOINTS:
- Algorithms.
-
-`gdbarch_in_function_epilogue_p (GDBARCH, ADDR)'
- Returns non-zero if the given ADDR is in the epilogue of a
- function. The epilogue of a function is defined as the part of a
- function where the stack frame of the function already has been
- destroyed up to the final `return from function call' instruction.
-
-`int gdbarch_in_solib_return_trampoline (GDBARCH, PC, NAME)'
- Define this function to return nonzero if the program is stopped
- in the trampoline that returns from a shared library.
-
-`target_so_ops.in_dynsym_resolve_code (PC)'
- Define this to return nonzero if the program is stopped in the
- dynamic linker.
-
-`SKIP_SOLIB_RESOLVER (PC)'
- Define this to evaluate to the (nonzero) address at which execution
- should continue to get past the dynamic linker's symbol resolution
- function. A zero value indicates that it is not important or
- necessary to set a breakpoint to get through the dynamic linker
- and that single stepping will suffice.
-
-`CORE_ADDR gdbarch_integer_to_address (GDBARCH, TYPE, BUF)'
- Define this when the architecture needs to handle non-pointer to
- address conversions specially. Converts that value to an address
- according to the current architectures conventions.
-
- _Pragmatics: When the user copies a well defined expression from
- their source code and passes it, as a parameter, to GDB's `print'
- command, they should get the same value as would have been
- computed by the target program. Any deviation from this rule can
- cause major confusion and annoyance, and needs to be justified
- carefully. In other words, GDB doesn't really have the freedom to
- do these conversions in clever and useful ways. It has, however,
- been pointed out that users aren't complaining about how GDB casts
- integers to pointers; they are complaining that they can't take an
- address from a disassembly listing and give it to `x/i'. Adding
- an architecture method like `gdbarch_integer_to_address' certainly
- makes it possible for GDB to "get it right" in all circumstances._
-
- *Note Pointers Are Not Always Addresses: Target Architecture
- Definition.
-
-`CORE_ADDR gdbarch_pointer_to_address (GDBARCH, TYPE, BUF)'
- Assume that BUF holds a pointer of type TYPE, in the appropriate
- format for the current architecture. Return the byte address the
- pointer refers to. *Note Pointers Are Not Always Addresses:
- Target Architecture Definition.
-
-`void gdbarch_register_to_value(GDBARCH, FRAME, REGNUM, TYPE, FUR)'
- Convert the raw contents of register REGNUM into a value of type
- TYPE. *Note Using Different Register and Memory Data
- Representations: Target Architecture Definition.
-
-`REGISTER_CONVERT_TO_VIRTUAL(REG, TYPE, FROM, TO)'
- Convert the value of register REG from its raw form to its virtual
- form. *Note Raw and Virtual Register Representations: Target
- Architecture Definition.
-
-`REGISTER_CONVERT_TO_RAW(TYPE, REG, FROM, TO)'
- Convert the value of register REG from its virtual form to its raw
- form. *Note Raw and Virtual Register Representations: Target
- Architecture Definition.
-
-`const struct regset *regset_from_core_section (struct gdbarch * GDBARCH, const char * SECT_NAME, size_t SECT_SIZE)'
- Return the appropriate register set for a core file section with
- name SECT_NAME and size SECT_SIZE.
-
-`SOFTWARE_SINGLE_STEP_P()'
- Define this as 1 if the target does not have a hardware single-step
- mechanism. The macro `SOFTWARE_SINGLE_STEP' must also be defined.
-
-`SOFTWARE_SINGLE_STEP(SIGNAL, INSERT_BREAKPOINTS_P)'
- A function that inserts or removes (depending on
- INSERT_BREAKPOINTS_P) breakpoints at each possible destinations of
- the next instruction. See `sparc-tdep.c' and `rs6000-tdep.c' for
- examples.
-
-`set_gdbarch_sofun_address_maybe_missing (GDBARCH, SET)'
- Somebody clever observed that, the more actual addresses you have
- in the debug information, the more time the linker has to spend
- relocating them. So whenever there's some other way the debugger
- could find the address it needs, you should omit it from the debug
- info, to make linking faster.
-
- Calling `set_gdbarch_sofun_address_maybe_missing' with a non-zero
- argument SET indicates that a particular set of hacks of this sort
- are in use, affecting `N_SO' and `N_FUN' entries in stabs-format
- debugging information. `N_SO' stabs mark the beginning and ending
- addresses of compilation units in the text segment. `N_FUN' stabs
- mark the starts and ends of functions.
-
- In this case, GDB assumes two things:
-
- * `N_FUN' stabs have an address of zero. Instead of using those
- addresses, you should find the address where the function
- starts by taking the function name from the stab, and then
- looking that up in the minsyms (the linker/assembler symbol
- table). In other words, the stab has the name, and the
- linker/assembler symbol table is the only place that carries
- the address.
-
- * `N_SO' stabs have an address of zero, too. You just look at
- the `N_FUN' stabs that appear before and after the `N_SO'
- stab, and guess the starting and ending addresses of the
- compilation unit from them.
-
-`int gdbarch_stabs_argument_has_addr (GDBARCH, TYPE)'
- Define this function to return nonzero if a function argument of
- type TYPE is passed by reference instead of value.
-
-`CORE_ADDR gdbarch_push_dummy_call (GDBARCH, FUNCTION, REGCACHE, BP_ADDR, NARGS, ARGS, SP, STRUCT_RETURN, STRUCT_ADDR)'
- Define this to push the dummy frame's call to the inferior
- function onto the stack. In addition to pushing NARGS, the code
- should push STRUCT_ADDR (when STRUCT_RETURN is non-zero), and the
- return address (BP_ADDR).
-
- FUNCTION is a pointer to a `struct value'; on architectures that
- use function descriptors, this contains the function descriptor
- value.
-
- Returns the updated top-of-stack pointer.
-
-`CORE_ADDR gdbarch_push_dummy_code (GDBARCH, SP, FUNADDR, USING_GCC, ARGS, NARGS, VALUE_TYPE, REAL_PC, BP_ADDR, REGCACHE)'
- Given a stack based call dummy, push the instruction sequence
- (including space for a breakpoint) to which the called function
- should return.
-
- Set BP_ADDR to the address at which the breakpoint instruction
- should be inserted, REAL_PC to the resume address when starting
- the call sequence, and return the updated inner-most stack address.
-
- By default, the stack is grown sufficient to hold a frame-aligned
- (*note frame_align::) breakpoint, BP_ADDR is set to the address
- reserved for that breakpoint, and REAL_PC set to FUNADDR.
-
- This method replaces `gdbarch_call_dummy_location (GDBARCH)'.
-
-`int gdbarch_sdb_reg_to_regnum (GDBARCH, SDB_REGNR)'
- Use this function to convert sdb register SDB_REGNR into GDB
- regnum. If not defined, no conversion will be done.
-
-`enum return_value_convention gdbarch_return_value (struct gdbarch *GDBARCH, struct type *VALTYPE, struct regcache *REGCACHE, void *READBUF, const void *WRITEBUF)'
- Given a function with a return-value of type RETTYPE, return which
- return-value convention that function would use.
-
- GDB currently recognizes two function return-value conventions:
- `RETURN_VALUE_REGISTER_CONVENTION' where the return value is found
- in registers; and `RETURN_VALUE_STRUCT_CONVENTION' where the return
- value is found in memory and the address of that memory location is
- passed in as the function's first parameter.
-
- If the register convention is being used, and WRITEBUF is
- non-`NULL', also copy the return-value in WRITEBUF into REGCACHE.
-
- If the register convention is being used, and READBUF is
- non-`NULL', also copy the return value from REGCACHE into READBUF
- (REGCACHE contains a copy of the registers from the just returned
- function).
-
- _Maintainer note: This method replaces separate predicate, extract,
- store methods. By having only one method, the logic needed to
- determine the return-value convention need only be implemented in
- one place. If GDB were written in an OO language, this method
- would instead return an object that knew how to perform the
- register return-value extract and store._
-
- _Maintainer note: This method does not take a GCC_P parameter, and
- such a parameter should not be added. If an architecture that
- requires per-compiler or per-function information be identified,
- then the replacement of RETTYPE with `struct value' FUNCTION
- should be pursued._
-
- _Maintainer note: The REGCACHE parameter limits this methods to
- the inner most frame. While replacing REGCACHE with a `struct
- frame_info' FRAME parameter would remove that limitation there has
- yet to be a demonstrated need for such a change._
-
-`void gdbarch_skip_permanent_breakpoint (GDBARCH, REGCACHE)'
- Advance the inferior's PC past a permanent breakpoint. GDB
- normally steps over a breakpoint by removing it, stepping one
- instruction, and re-inserting the breakpoint. However, permanent
- breakpoints are hardwired into the inferior, and can't be removed,
- so this strategy doesn't work. Calling
- `gdbarch_skip_permanent_breakpoint' adjusts the processor's state
- so that execution will resume just after the breakpoint. This
- function does the right thing even when the breakpoint is in the
- delay slot of a branch or jump.
-
-`CORE_ADDR gdbarch_skip_trampoline_code (GDBARCH, FRAME, PC)'
- If the target machine has trampoline code that sits between
- callers and the functions being called, then define this function
- to return a new PC that is at the start of the real function.
-
-`int gdbarch_deprecated_fp_regnum (GDBARCH)'
- If the frame pointer is in a register, use this function to return
- the number of that register.
-
-`int gdbarch_stab_reg_to_regnum (GDBARCH, STAB_REGNR)'
- Use this function to convert stab register STAB_REGNR into GDB
- regnum. If not defined, no conversion will be done.
-
-`SYMBOL_RELOADING_DEFAULT'
- The default value of the "symbol-reloading" variable. (Never
- defined in current sources.)
-
-`TARGET_CHAR_BIT'
- Number of bits in a char; defaults to 8.
-
-`int gdbarch_char_signed (GDBARCH)'
- Non-zero if `char' is normally signed on this architecture; zero if
- it should be unsigned.
-
- The ISO C standard requires the compiler to treat `char' as
- equivalent to either `signed char' or `unsigned char'; any
- character in the standard execution set is supposed to be positive.
- Most compilers treat `char' as signed, but `char' is unsigned on
- the IBM S/390, RS6000, and PowerPC targets.
-
-`int gdbarch_double_bit (GDBARCH)'
- Number of bits in a double float; defaults to
- `8 * TARGET_CHAR_BIT'.
-
-`int gdbarch_float_bit (GDBARCH)'
- Number of bits in a float; defaults to `4 * TARGET_CHAR_BIT'.
-
-`int gdbarch_int_bit (GDBARCH)'
- Number of bits in an integer; defaults to `4 * TARGET_CHAR_BIT'.
-
-`int gdbarch_long_bit (GDBARCH)'
- Number of bits in a long integer; defaults to
- `4 * TARGET_CHAR_BIT'.
-
-`int gdbarch_long_double_bit (GDBARCH)'
- Number of bits in a long double float; defaults to
- `2 * gdbarch_double_bit (GDBARCH)'.
-
-`int gdbarch_long_long_bit (GDBARCH)'
- Number of bits in a long long integer; defaults to
- `2 * gdbarch_long_bit (GDBARCH)'.
-
-`int gdbarch_ptr_bit (GDBARCH)'
- Number of bits in a pointer; defaults to
- `gdbarch_int_bit (GDBARCH)'.
-
-`int gdbarch_short_bit (GDBARCH)'
- Number of bits in a short integer; defaults to
- `2 * TARGET_CHAR_BIT'.
-
-`void gdbarch_virtual_frame_pointer (GDBARCH, PC, FRAME_REGNUM, FRAME_OFFSET)'
- Returns a `(REGISTER, OFFSET)' pair representing the virtual frame
- pointer in use at the code address PC. If virtual frame pointers
- are not used, a default definition simply returns
- `gdbarch_deprecated_fp_regnum' (or `gdbarch_sp_regnum', if no
- frame pointer is defined), with an offset of zero.
-
-`TARGET_HAS_HARDWARE_WATCHPOINTS'
- If non-zero, the target has support for hardware-assisted
- watchpoints. *Note watchpoints: Algorithms, for more details and
- other related macros.
-
-`int gdbarch_print_insn (GDBARCH, VMA, INFO)'
- This is the function used by GDB to print an assembly instruction.
- It prints the instruction at address VMA in debugged memory and
- returns the length of the instruction, in bytes. This usually
- points to a function in the `opcodes' library (*note Opcodes:
- Support Libraries.). INFO is a structure (of type
- `disassemble_info') defined in the header file
- `include/dis-asm.h', and used to pass information to the
- instruction decoding routine.
-
-`frame_id gdbarch_dummy_id (GDBARCH, FRAME)'
- Given FRAME return a `struct frame_id' that uniquely identifies an
- inferior function call's dummy frame. The value returned must
- match the dummy frame stack value previously saved by
- `call_function_by_hand'.
-
-`void gdbarch_value_to_register (GDBARCH, FRAME, TYPE, BUF)'
- Convert a value of type TYPE into the raw contents of a register.
- *Note Using Different Register and Memory Data Representations:
- Target Architecture Definition.
-
-
- Motorola M68K target conditionals.
-
-`BPT_VECTOR'
- Define this to be the 4-bit location of the breakpoint trap
- vector. If not defined, it will default to `0xf'.
-
-`REMOTE_BPT_VECTOR'
- Defaults to `1'.
-
-
-
-File: gdbint.info, Node: Adding a New Target, Prev: Defining Other Architecture Features, Up: Target Architecture Definition
-
-11.11 Adding a New Target
-=========================
-
-The following files add a target to GDB:
-
-`gdb/TTT-tdep.c'
- Contains any miscellaneous code required for this target machine.
- On some machines it doesn't exist at all.
-
-`gdb/ARCH-tdep.c'
-`gdb/ARCH-tdep.h'
- This is required to describe the basic layout of the target
- machine's processor chip (registers, stack, etc.). It can be
- shared among many targets that use the same processor architecture.
-
-
- (Target header files such as `gdb/config/ARCH/tm-TTT.h',
-`gdb/config/ARCH/tm-ARCH.h', and `config/tm-OS.h' are no longer used.)
-
- A GDB description for a new architecture, arch is created by
-defining a global function `_initialize_ARCH_tdep', by convention in
-the source file `ARCH-tdep.c'. For example, in the case of the
-OpenRISC 1000, this function is called `_initialize_or1k_tdep' and is
-found in the file `or1k-tdep.c'.
-
- The object file resulting from compiling this source file, which will
-contain the implementation of the `_initialize_ARCH_tdep' function is
-specified in the GDB `configure.tgt' file, which includes a large case
-statement pattern matching against the `--target' option of the
-`configure' script.
-
- _Note:_ If the architecture requires multiple source files, the
- corresponding binaries should be included in `configure.tgt'.
- However if there are header files, the dependencies on these will
- not be picked up from the entries in `configure.tgt'. The
- `Makefile.in' file will need extending to show these dependencies.
-
- A new struct gdbarch, defining the new architecture, is created
-within the `_initialize_ARCH_tdep' function by calling
-`gdbarch_register':
-
- void gdbarch_register (enum bfd_architecture architecture,
- gdbarch_init_ftype *init_func,
- gdbarch_dump_tdep_ftype *tdep_dump_func);
-
- This function has been described fully in an earlier section. *Note
-How an Architecture is Represented: How an Architecture is Represented.
-
- The new `struct gdbarch' should contain implementations of the
-necessary functions (described in the previous sections) to describe
-the basic layout of the target machine's processor chip (registers,
-stack, etc.). It can be shared among many targets that use the same
-processor architecture.
-
-
-File: gdbint.info, Node: Target Descriptions, Next: Target Vector Definition, Prev: Target Architecture Definition, Up: Top
-
-12 Target Descriptions
-**********************
-
-The target architecture definition (*note Target Architecture
-Definition::) contains GDB's hard-coded knowledge about an
-architecture. For some platforms, it is handy to have more flexible
-knowledge about a specific instance of the architecture--for instance,
-a processor or development board. "Target descriptions" provide a
-mechanism for the user to tell GDB more about what their target
-supports, or for the target to tell GDB directly.
-
- For details on writing, automatically supplying, and manually
-selecting target descriptions, see *note Target Descriptions:
-(gdb)Target Descriptions. This section will cover some related topics
-about the GDB internals.
-
-* Menu:
-
-* Target Descriptions Implementation::
-* Adding Target Described Register Support::
-
-
-File: gdbint.info, Node: Target Descriptions Implementation, Next: Adding Target Described Register Support, Up: Target Descriptions
-
-12.1 Target Descriptions Implementation
-=======================================
-
-Before GDB connects to a new target, or runs a new program on an
-existing target, it discards any existing target description and
-reverts to a default gdbarch. Then, after connecting, it looks for a
-new target description by calling `target_find_description'.
-
- A description may come from a user specified file (XML), the remote
-`qXfer:features:read' packet (also XML), or from any custom
-`to_read_description' routine in the target vector. For instance, the
-remote target supports guessing whether a MIPS target is 32-bit or
-64-bit based on the size of the `g' packet.
-
- If any target description is found, GDB creates a new gdbarch
-incorporating the description by calling `gdbarch_update_p'. Any
-`<architecture>' element is handled first, to determine which
-architecture's gdbarch initialization routine is called to create the
-new architecture. Then the initialization routine is called, and has a
-chance to adjust the constructed architecture based on the contents of
-the target description. For instance, it can recognize any properties
-set by a `to_read_description' routine. Also see *note Adding Target
-Described Register Support::.
-
-
-File: gdbint.info, Node: Adding Target Described Register Support, Prev: Target Descriptions Implementation, Up: Target Descriptions
-
-12.2 Adding Target Described Register Support
-=============================================
-
-Target descriptions can report additional registers specific to an
-instance of the target. But it takes a little work in the architecture
-specific routines to support this.
-
- A target description must either have no registers or a complete
-set--this avoids complexity in trying to merge standard registers with
-the target defined registers. It is the architecture's responsibility
-to validate that a description with registers has everything it needs.
-To keep architecture code simple, the same mechanism is used to assign
-fixed internal register numbers to standard registers.
-
- If `tdesc_has_registers' returns 1, the description contains
-registers. The architecture's `gdbarch_init' routine should:
-
- * Call `tdesc_data_alloc' to allocate storage, early, before
- searching for a matching gdbarch or allocating a new one.
-
- * Use `tdesc_find_feature' to locate standard features by name.
-
- * Use `tdesc_numbered_register' and `tdesc_numbered_register_choices'
- to locate the expected registers in the standard features.
-
- * Return `NULL' if a required feature is missing, or if any standard
- feature is missing expected registers. This will produce a
- warning that the description was incomplete.
-
- * Free the allocated data before returning, unless
- `tdesc_use_registers' is called.
-
- * Call `set_gdbarch_num_regs' as usual, with a number higher than any
- fixed number passed to `tdesc_numbered_register'.
-
- * Call `tdesc_use_registers' after creating a new gdbarch, before
- returning it.
-
-
- After `tdesc_use_registers' has been called, the architecture's
-`register_name', `register_type', and `register_reggroup_p' routines
-will not be called; that information will be taken from the target
-description. `num_regs' may be increased to account for any additional
-registers in the description.
-
- Pseudo-registers require some extra care:
-
- * Using `tdesc_numbered_register' allows the architecture to give
- constant register numbers to standard architectural registers, e.g.
- as an `enum' in `ARCH-tdep.h'. But because pseudo-registers are
- always numbered above `num_regs', which may be increased by the
- description, constant numbers can not be used for pseudos. They
- must be numbered relative to `num_regs' instead.
-
- * The description will not describe pseudo-registers, so the
- architecture must call `set_tdesc_pseudo_register_name',
- `set_tdesc_pseudo_register_type', and
- `set_tdesc_pseudo_register_reggroup_p' to supply routines
- describing pseudo registers. These routines will be passed
- internal register numbers, so the same routines used for the
- gdbarch equivalents are usually suitable.
-
-
-
-File: gdbint.info, Node: Target Vector Definition, Next: Native Debugging, Prev: Target Descriptions, Up: Top
-
-13 Target Vector Definition
-***************************
-
-The target vector defines the interface between GDB's abstract handling
-of target systems, and the nitty-gritty code that actually exercises
-control over a process or a serial port. GDB includes some 30-40
-different target vectors; however, each configuration of GDB includes
-only a few of them.
-
-* Menu:
-
-* Managing Execution State::
-* Existing Targets::
-
-
-File: gdbint.info, Node: Managing Execution State, Next: Existing Targets, Up: Target Vector Definition
-
-13.1 Managing Execution State
-=============================
-
-A target vector can be completely inactive (not pushed on the target
-stack), active but not running (pushed, but not connected to a fully
-manifested inferior), or completely active (pushed, with an accessible
-inferior). Most targets are only completely inactive or completely
-active, but some support persistent connections to a target even when
-the target has exited or not yet started.
-
- For example, connecting to the simulator using `target sim' does not
-create a running program. Neither registers nor memory are accessible
-until `run'. Similarly, after `kill', the program can not continue
-executing. But in both cases GDB remains connected to the simulator,
-and target-specific commands are directed to the simulator.
-
- A target which only supports complete activation should push itself
-onto the stack in its `to_open' routine (by calling `push_target'), and
-unpush itself from the stack in its `to_mourn_inferior' routine (by
-calling `unpush_target').
-
- A target which supports both partial and complete activation should
-still call `push_target' in `to_open', but not call `unpush_target' in
-`to_mourn_inferior'. Instead, it should call either
-`target_mark_running' or `target_mark_exited' in its `to_open',
-depending on whether the target is fully active after connection. It
-should also call `target_mark_running' any time the inferior becomes
-fully active (e.g. in `to_create_inferior' and `to_attach'), and
-`target_mark_exited' when the inferior becomes inactive (in
-`to_mourn_inferior'). The target should also make sure to call
-`target_mourn_inferior' from its `to_kill', to return the target to
-inactive state.
-
-
-File: gdbint.info, Node: Existing Targets, Prev: Managing Execution State, Up: Target Vector Definition
-
-13.2 Existing Targets
-=====================
-
-13.2.1 File Targets
--------------------
-
-Both executables and core files have target vectors.
-
-13.2.2 Standard Protocol and Remote Stubs
------------------------------------------
-
-GDB's file `remote.c' talks a serial protocol to code that runs in the
-target system. GDB provides several sample "stubs" that can be
-integrated into target programs or operating systems for this purpose;
-they are named `CPU-stub.c'. Many operating systems, embedded targets,
-emulators, and simulators already have a GDB stub built into them, and
-maintenance of the remote protocol must be careful to preserve
-compatibility.
-
- The GDB user's manual describes how to put such a stub into your
-target code. What follows is a discussion of integrating the SPARC
-stub into a complicated operating system (rather than a simple
-program), by Stu Grossman, the author of this stub.
-
- The trap handling code in the stub assumes the following upon entry
-to `trap_low':
-
- 1. %l1 and %l2 contain pc and npc respectively at the time of the
- trap;
-
- 2. traps are disabled;
-
- 3. you are in the correct trap window.
-
- As long as your trap handler can guarantee those conditions, then
-there is no reason why you shouldn't be able to "share" traps with the
-stub. The stub has no requirement that it be jumped to directly from
-the hardware trap vector. That is why it calls `exceptionHandler()',
-which is provided by the external environment. For instance, this could
-set up the hardware traps to actually execute code which calls the stub
-first, and then transfers to its own trap handler.
-
- For the most point, there probably won't be much of an issue with
-"sharing" traps, as the traps we use are usually not used by the kernel,
-and often indicate unrecoverable error conditions. Anyway, this is all
-controlled by a table, and is trivial to modify. The most important
-trap for us is for `ta 1'. Without that, we can't single step or do
-breakpoints. Everything else is unnecessary for the proper operation
-of the debugger/stub.
-
- From reading the stub, it's probably not obvious how breakpoints
-work. They are simply done by deposit/examine operations from GDB.
-
-13.2.3 ROM Monitor Interface
-----------------------------
-
-13.2.4 Custom Protocols
------------------------
-
-13.2.5 Transport Layer
-----------------------
-
-13.2.6 Builtin Simulator
-------------------------
-
-
-File: gdbint.info, Node: Native Debugging, Next: Support Libraries, Prev: Target Vector Definition, Up: Top
-
-14 Native Debugging
-*******************
-
-Several files control GDB's configuration for native support:
-
-`gdb/config/ARCH/XYZ.mh'
- Specifies Makefile fragments needed by a _native_ configuration on
- machine XYZ. In particular, this lists the required
- native-dependent object files, by defining `NATDEPFILES=...'.
- Also specifies the header file which describes native support on
- XYZ, by defining `NAT_FILE= nm-XYZ.h'. You can also define
- `NAT_CFLAGS', `NAT_ADD_FILES', `NAT_CLIBS', `NAT_CDEPS',
- `NAT_GENERATED_FILES', etc.; see `Makefile.in'.
-
- _Maintainer's note: The `.mh' suffix is because this file
- originally contained `Makefile' fragments for hosting GDB on
- machine XYZ. While the file is no longer used for this purpose,
- the `.mh' suffix remains. Perhaps someone will eventually rename
- these fragments so that they have a `.mn' suffix._
-
-`gdb/config/ARCH/nm-XYZ.h'
- (`nm.h' is a link to this file, created by `configure'). Contains
- C macro definitions describing the native system environment, such
- as child process control and core file support.
-
-`gdb/XYZ-nat.c'
- Contains any miscellaneous C code required for this native support
- of this machine. On some machines it doesn't exist at all.
-
- There are some "generic" versions of routines that can be used by
-various systems. These can be customized in various ways by macros
-defined in your `nm-XYZ.h' file. If these routines work for the XYZ
-host, you can just include the generic file's name (with `.o', not
-`.c') in `NATDEPFILES'.
-
- Otherwise, if your machine needs custom support routines, you will
-need to write routines that perform the same functions as the generic
-file. Put them into `XYZ-nat.c', and put `XYZ-nat.o' into
-`NATDEPFILES'.
-
-`inftarg.c'
- This contains the _target_ops vector_ that supports Unix child
- processes on systems which use ptrace and wait to control the
- child.
-
-`procfs.c'
- This contains the _target_ops vector_ that supports Unix child
- processes on systems which use /proc to control the child.
-
-`fork-child.c'
- This does the low-level grunge that uses Unix system calls to do a
- "fork and exec" to start up a child process.
-
-`infptrace.c'
- This is the low level interface to inferior processes for systems
- using the Unix `ptrace' call in a vanilla way.
-
-14.1 ptrace
-===========
-
-14.2 /proc
-==========
-
-14.3 win32
-==========
-
-14.4 shared libraries
-=====================
-
-14.5 Native Conditionals
-========================
-
-When GDB is configured and compiled, various macros are defined or left
-undefined, to control compilation when the host and target systems are
-the same. These macros should be defined (or left undefined) in
-`nm-SYSTEM.h'.
-
-`I386_USE_GENERIC_WATCHPOINTS'
- An x86-based machine can define this to use the generic x86
- watchpoint support; see *note I386_USE_GENERIC_WATCHPOINTS:
- Algorithms.
-
-`SOLIB_ADD (FILENAME, FROM_TTY, TARG, READSYMS)'
- Define this to expand into an expression that will cause the
- symbols in FILENAME to be added to GDB's symbol table. If
- READSYMS is zero symbols are not read but any necessary low level
- processing for FILENAME is still done.
-
-`SOLIB_CREATE_INFERIOR_HOOK'
- Define this to expand into any shared-library-relocation code that
- you want to be run just after the child process has been forked.
-
-`START_INFERIOR_TRAPS_EXPECTED'
- When starting an inferior, GDB normally expects to trap twice;
- once when the shell execs, and once when the program itself execs.
- If the actual number of traps is something other than 2, then
- define this macro to expand into the number expected.
-
-
-
-File: gdbint.info, Node: Support Libraries, Next: Coding Standards, Prev: Native Debugging, Up: Top
-
-15 Support Libraries
-********************
-
-15.1 BFD
-========
-
-BFD provides support for GDB in several ways:
-
-_identifying executable and core files_
- BFD will identify a variety of file types, including a.out, coff,
- and several variants thereof, as well as several kinds of core
- files.
-
-_access to sections of files_
- BFD parses the file headers to determine the names, virtual
- addresses, sizes, and file locations of all the various named
- sections in files (such as the text section or the data section).
- GDB simply calls BFD to read or write section X at byte offset Y
- for length Z.
-
-_specialized core file support_
- BFD provides routines to determine the failing command name stored
- in a core file, the signal with which the program failed, and
- whether a core file matches (i.e. could be a core dump of) a
- particular executable file.
-
-_locating the symbol information_
- GDB uses an internal interface of BFD to determine where to find
- the symbol information in an executable file or symbol-file. GDB
- itself handles the reading of symbols, since BFD does not
- "understand" debug symbols, but GDB uses BFD's cached information
- to find the symbols, string table, etc.
-
-15.2 opcodes
-============
-
-The opcodes library provides GDB's disassembler. (It's a separate
-library because it's also used in binutils, for `objdump').
-
-15.3 readline
-=============
-
-The `readline' library provides a set of functions for use by
-applications that allow users to edit command lines as they are typed
-in.
-
-15.4 libiberty
-==============
-
-The `libiberty' library provides a set of functions and features that
-integrate and improve on functionality found in modern operating
-systems. Broadly speaking, such features can be divided into three
-groups: supplemental functions (functions that may be missing in some
-environments and operating systems), replacement functions (providing a
-uniform and easier to use interface for commonly used standard
-functions), and extensions (which provide additional functionality
-beyond standard functions).
-
- GDB uses various features provided by the `libiberty' library, for
-instance the C++ demangler, the IEEE floating format support functions,
-the input options parser `getopt', the `obstack' extension, and other
-functions.
-
-15.4.1 `obstacks' in GDB
-------------------------
-
-The obstack mechanism provides a convenient way to allocate and free
-chunks of memory. Each obstack is a pool of memory that is managed
-like a stack. Objects (of any nature, size and alignment) are
-allocated and freed in a LIFO fashion on an obstack (see `libiberty''s
-documentation for a more detailed explanation of `obstacks').
-
- The most noticeable use of the `obstacks' in GDB is in object files.
-There is an obstack associated with each internal representation of an
-object file. Lots of things get allocated on these `obstacks':
-dictionary entries, blocks, blockvectors, symbols, minimal symbols,
-types, vectors of fundamental types, class fields of types, object
-files section lists, object files section offset lists, line tables,
-symbol tables, partial symbol tables, string tables, symbol table
-private data, macros tables, debug information sections and entries,
-import and export lists (som), unwind information (hppa), dwarf2
-location expressions data. Plus various strings such as directory
-names strings, debug format strings, names of types.
-
- An essential and convenient property of all data on `obstacks' is
-that memory for it gets allocated (with `obstack_alloc') at various
-times during a debugging session, but it is released all at once using
-the `obstack_free' function. The `obstack_free' function takes a
-pointer to where in the stack it must start the deletion from (much
-like the cleanup chains have a pointer to where to start the cleanups).
-Because of the stack like structure of the `obstacks', this allows to
-free only a top portion of the obstack. There are a few instances in
-GDB where such thing happens. Calls to `obstack_free' are done after
-some local data is allocated to the obstack. Only the local data is
-deleted from the obstack. Of course this assumes that nothing between
-the `obstack_alloc' and the `obstack_free' allocates anything else on
-the same obstack. For this reason it is best and safest to use
-temporary `obstacks'.
-
- Releasing the whole obstack is also not safe per se. It is safe only
-under the condition that we know the `obstacks' memory is no longer
-needed. In GDB we get rid of the `obstacks' only when we get rid of
-the whole objfile(s), for instance upon reading a new symbol file.
-
-15.5 gnu-regex
-==============
-
-Regex conditionals.
-
-`C_ALLOCA'
-
-`NFAILURES'
-
-`RE_NREGS'
-
-`SIGN_EXTEND_CHAR'
-
-`SWITCH_ENUM_BUG'
-
-`SYNTAX_TABLE'
-
-`Sword'
-
-`sparc'
-
-15.6 Array Containers
-=====================
-
-Often it is necessary to manipulate a dynamic array of a set of
-objects. C forces some bookkeeping on this, which can get cumbersome
-and repetitive. The `vec.h' file contains macros for defining and
-using a typesafe vector type. The functions defined will be inlined
-when compiling, and so the abstraction cost should be zero. Domain
-checks are added to detect programming errors.
-
- An example use would be an array of symbols or section information.
-The array can be grown as symbols are read in (or preallocated), and
-the accessor macros provided keep care of all the necessary
-bookkeeping. Because the arrays are type safe, there is no danger of
-accidentally mixing up the contents. Think of these as C++ templates,
-but implemented in C.
-
- Because of the different behavior of structure objects, scalar
-objects and of pointers, there are three flavors of vector, one for
-each of these variants. Both the structure object and pointer variants
-pass pointers to objects around -- in the former case the pointers are
-stored into the vector and in the latter case the pointers are
-dereferenced and the objects copied into the vector. The scalar object
-variant is suitable for `int'-like objects, and the vector elements are
-returned by value.
-
- There are both `index' and `iterate' accessors. The iterator
-returns a boolean iteration condition and updates the iteration
-variable passed by reference. Because the iterator will be inlined,
-the address-of can be optimized away.
-
- The vectors are implemented using the trailing array idiom, thus they
-are not resizeable without changing the address of the vector object
-itself. This means you cannot have variables or fields of vector type
--- always use a pointer to a vector. The one exception is the final
-field of a structure, which could be a vector type. You will have to
-use the `embedded_size' & `embedded_init' calls to create such objects,
-and they will probably not be resizeable (so don't use the "safe"
-allocation variants). The trailing array idiom is used (rather than a
-pointer to an array of data), because, if we allow `NULL' to also
-represent an empty vector, empty vectors occupy minimal space in the
-structure containing them.
-
- Each operation that increases the number of active elements is
-available in "quick" and "safe" variants. The former presumes that
-there is sufficient allocated space for the operation to succeed (it
-dies if there is not). The latter will reallocate the vector, if
-needed. Reallocation causes an exponential increase in vector size.
-If you know you will be adding N elements, it would be more efficient
-to use the reserve operation before adding the elements with the
-"quick" operation. This will ensure there are at least as many
-elements as you ask for, it will exponentially increase if there are
-too few spare slots. If you want reserve a specific number of slots,
-but do not want the exponential increase (for instance, you know this
-is the last allocation), use a negative number for reservation. You
-can also create a vector of a specific size from the get go.
-
- You should prefer the push and pop operations, as they append and
-remove from the end of the vector. If you need to remove several items
-in one go, use the truncate operation. The insert and remove
-operations allow you to change elements in the middle of the vector.
-There are two remove operations, one which preserves the element
-ordering `ordered_remove', and one which does not `unordered_remove'.
-The latter function copies the end element into the removed slot,
-rather than invoke a memmove operation. The `lower_bound' function
-will determine where to place an item in the array using insert that
-will maintain sorted order.
-
- If you need to directly manipulate a vector, then the `address'
-accessor will return the address of the start of the vector. Also the
-`space' predicate will tell you whether there is spare capacity in the
-vector. You will not normally need to use these two functions.
-
- Vector types are defined using a `DEF_VEC_{O,P,I}(TYPENAME)' macro.
-Variables of vector type are declared using a `VEC(TYPENAME)' macro.
-The characters `O', `P' and `I' indicate whether TYPENAME is an object
-(`O'), pointer (`P') or integral (`I') type. Be careful to pick the
-correct one, as you'll get an awkward and inefficient API if you use
-the wrong one. There is a check, which results in a compile-time
-warning, for the `P' and `I' versions, but there is no check for the
-`O' versions, as that is not possible in plain C.
-
- An example of their use would be,
-
- DEF_VEC_P(tree); // non-managed tree vector.
-
- struct my_struct {
- VEC(tree) *v; // A (pointer to) a vector of tree pointers.
- };
-
- struct my_struct *s;
-
- if (VEC_length(tree, s->v)) { we have some contents }
- VEC_safe_push(tree, s->v, decl); // append some decl onto the end
- for (ix = 0; VEC_iterate(tree, s->v, ix, elt); ix++)
- { do something with elt }
-
- The `vec.h' file provides details on how to invoke the various
-accessors provided. They are enumerated here:
-
-`VEC_length'
- Return the number of items in the array,
-
-`VEC_empty'
- Return true if the array has no elements.
-
-`VEC_last'
-`VEC_index'
- Return the last or arbitrary item in the array.
-
-`VEC_iterate'
- Access an array element and indicate whether the array has been
- traversed.
-
-`VEC_alloc'
-`VEC_free'
- Create and destroy an array.
-
-`VEC_embedded_size'
-`VEC_embedded_init'
- Helpers for embedding an array as the final element of another
- struct.
-
-`VEC_copy'
- Duplicate an array.
-
-`VEC_space'
- Return the amount of free space in an array.
-
-`VEC_reserve'
- Ensure a certain amount of free space.
-
-`VEC_quick_push'
-`VEC_safe_push'
- Append to an array, either assuming the space is available, or
- making sure that it is.
-
-`VEC_pop'
- Remove the last item from an array.
-
-`VEC_truncate'
- Remove several items from the end of an array.
-
-`VEC_safe_grow'
- Add several items to the end of an array.
-
-`VEC_replace'
- Overwrite an item in the array.
-
-`VEC_quick_insert'
-`VEC_safe_insert'
- Insert an item into the middle of the array. Either the space must
- already exist, or the space is created.
-
-`VEC_ordered_remove'
-`VEC_unordered_remove'
- Remove an item from the array, preserving order or not.
-
-`VEC_block_remove'
- Remove a set of items from the array.
-
-`VEC_address'
- Provide the address of the first element.
-
-`VEC_lower_bound'
- Binary search the array.
-
-
-15.7 include
-============
-
-
-File: gdbint.info, Node: Coding Standards, Next: Misc Guidelines, Prev: Support Libraries, Up: Top
-
-16 Coding Standards
-*******************
-
-16.1 GDB C Coding Standards
-===========================
-
-GDB follows the GNU coding standards, as described in
-`etc/standards.texi'. This file is also available for anonymous FTP
-from GNU archive sites. GDB takes a strict interpretation of the
-standard; in general, when the GNU standard recommends a practice but
-does not require it, GDB requires it.
-
- GDB follows an additional set of coding standards specific to GDB,
-as described in the following sections.
-
-16.1.1 ISO C
-------------
-
-GDB assumes an ISO/IEC 9899:1990 (a.k.a. ISO C90) compliant compiler.
-
- GDB does not assume an ISO C or POSIX compliant C library.
-
-16.1.2 Formatting
------------------
-
-The standard GNU recommendations for formatting must be followed
-strictly. Any GDB-specific deviation from GNU recomendations is
-described below.
-
- A function declaration should not have its name in column zero. A
-function definition should have its name in column zero.
-
- /* Declaration */
- static void foo (void);
- /* Definition */
- void
- foo (void)
- {
- }
-
- _Pragmatics: This simplifies scripting. Function definitions can be
-found using `^function-name'._
-
- There must be a space between a function or macro name and the
-opening parenthesis of its argument list (except for macro definitions,
-as required by C). There must not be a space after an open
-paren/bracket or before a close paren/bracket.
-
- While additional whitespace is generally helpful for reading, do not
-use more than one blank line to separate blocks, and avoid adding
-whitespace after the end of a program line (as of 1/99, some 600 lines
-had whitespace after the semicolon). Excess whitespace causes
-difficulties for `diff' and `patch' utilities.
-
- Pointers are declared using the traditional K&R C style:
-
- void *foo;
-
-and not:
-
- void * foo;
- void* foo;
-
- In addition, whitespace around casts and unary operators should
-follow the following guidelines:
-
-Use... ...instead of
-`!x' `! x'
-`~x' `~ x'
-`-x' `- x' (unary minus)
-`(foo) x' `(foo)x' (cast)
-`*x' `* x' (pointer dereference)
-
-16.1.3 Comments
----------------
-
-The standard GNU requirements on comments must be followed strictly.
-
- Block comments must appear in the following form, with no `/*'- or
-`*/'-only lines, and no leading `*':
-
- /* Wait for control to return from inferior to debugger. If inferior
- gets a signal, we may decide to start it up again instead of
- returning. That is why there is a loop in this function. When
- this function actually returns it means the inferior should be left
- stopped and GDB should read more commands. */
-
- (Note that this format is encouraged by Emacs; tabbing for a
-multi-line comment works correctly, and `M-q' fills the block
-consistently.)
-
- Put a blank line between the block comments preceding function or
-variable definitions, and the definition itself.
-
- In general, put function-body comments on lines by themselves, rather
-than trying to fit them into the 20 characters left at the end of a
-line, since either the comment or the code will inevitably get longer
-than will fit, and then somebody will have to move it anyhow.
-
-16.1.4 C Usage
---------------
-
-Code must not depend on the sizes of C data types, the format of the
-host's floating point numbers, the alignment of anything, or the order
-of evaluation of expressions.
-
- Use functions freely. There are only a handful of compute-bound
-areas in GDB that might be affected by the overhead of a function call,
-mainly in symbol reading. Most of GDB's performance is limited by the
-target interface (whether serial line or system call).
-
- However, use functions with moderation. A thousand one-line
-functions are just as hard to understand as a single thousand-line
-function.
-
- _Macros are bad, M'kay._ (But if you have to use a macro, make sure
-that the macro arguments are protected with parentheses.)
-
- Declarations like `struct foo *' should be used in preference to
-declarations like `typedef struct foo { ... } *foo_ptr'.
-
-16.1.5 Function Prototypes
---------------------------
-
-Prototypes must be used when both _declaring_ and _defining_ a
-function. Prototypes for GDB functions must include both the argument
-type and name, with the name matching that used in the actual function
-definition.
-
- All external functions should have a declaration in a header file
-that callers include, except for `_initialize_*' functions, which must
-be external so that `init.c' construction works, but shouldn't be
-visible to random source files.
-
- Where a source file needs a forward declaration of a static function,
-that declaration must appear in a block near the top of the source file.
-
-16.1.6 File Names
------------------
-
-Any file used when building the core of GDB must be in lower case. Any
-file used when building the core of GDB must be 8.3 unique. These
-requirements apply to both source and generated files.
-
- _Pragmatics: The core of GDB must be buildable on many platforms
-including DJGPP and MacOS/HFS. Every time an unfriendly file is
-introduced to the build process both `Makefile.in' and `configure.in'
-need to be modified accordingly. Compare the convoluted conversion
-process needed to transform `COPYING' into `copying.c' with the
-conversion needed to transform `version.in' into `version.c'._
-
- Any file non 8.3 compliant file (that is not used when building the
-core of GDB) must be added to `gdb/config/djgpp/fnchange.lst'.
-
- _Pragmatics: This is clearly a compromise._
-
- When GDB has a local version of a system header file (ex `string.h')
-the file name based on the POSIX header prefixed with `gdb_'
-(`gdb_string.h'). These headers should be relatively independent: they
-should use only macros defined by `configure', the compiler, or the
-host; they should include only system headers; they should refer only
-to system types. They may be shared between multiple programs, e.g.
-GDB and GDBSERVER.
-
- For other files `-' is used as the separator.
-
-16.1.7 Include Files
---------------------
-
-A `.c' file should include `defs.h' first.
-
- A `.c' file should directly include the `.h' file of every
-declaration and/or definition it directly refers to. It cannot rely on
-indirect inclusion.
-
- A `.h' file should directly include the `.h' file of every
-declaration and/or definition it directly refers to. It cannot rely on
-indirect inclusion. Exception: The file `defs.h' does not need to be
-directly included.
-
- An external declaration should only appear in one include file.
-
- An external declaration should never appear in a `.c' file.
-Exception: a declaration for the `_initialize' function that pacifies
-`-Wmissing-declaration'.
-
- A `typedef' definition should only appear in one include file.
-
- An opaque `struct' declaration can appear in multiple `.h' files.
-Where possible, a `.h' file should use an opaque `struct' declaration
-instead of an include.
-
- All `.h' files should be wrapped in:
-
- #ifndef INCLUDE_FILE_NAME_H
- #define INCLUDE_FILE_NAME_H
- header body
- #endif
-
-16.2 GDB Python Coding Standards
-================================
-
-GDB follows the published `Python' coding standards in `PEP008'
-(http://www.python.org/dev/peps/pep-0008/).
-
- In addition, the guidelines in the Google Python Style Guide
-(http://google-styleguide.googlecode.com/svn/trunk/pyguide.html) are
-also followed where they do not conflict with `PEP008'.
-
-16.2.1 GDB-specific exceptions
-------------------------------
-
-There are a few exceptions to the published standards. They exist
-mainly for consistency with the `C' standards.
-
- * Use `FIXME' instead of `TODO'.
-
-
-
-File: gdbint.info, Node: Misc Guidelines, Next: Porting GDB, Prev: Coding Standards, Up: Top
-
-17 Misc Guidelines
-******************
-
-This chapter covers topics that are lower-level than the major
-algorithms of GDB.
-
-17.1 Cleanups
-=============
-
-Cleanups are a structured way to deal with things that need to be done
-later.
-
- When your code does something (e.g., `xmalloc' some memory, or
-`open' a file) that needs to be undone later (e.g., `xfree' the memory
-or `close' the file), it can make a cleanup. The cleanup will be done
-at some future point: when the command is finished and control returns
-to the top level; when an error occurs and the stack is unwound; or
-when your code decides it's time to explicitly perform cleanups.
-Alternatively you can elect to discard the cleanups you created.
-
- Syntax:
-
-`struct cleanup *OLD_CHAIN;'
- Declare a variable which will hold a cleanup chain handle.
-
-`OLD_CHAIN = make_cleanup (FUNCTION, ARG);'
- Make a cleanup which will cause FUNCTION to be called with ARG (a
- `char *') later. The result, OLD_CHAIN, is a handle that can
- later be passed to `do_cleanups' or `discard_cleanups'. Unless
- you are going to call `do_cleanups' or `discard_cleanups', you can
- ignore the result from `make_cleanup'.
-
-`do_cleanups (OLD_CHAIN);'
- Do all cleanups added to the chain since the corresponding
- `make_cleanup' call was made.
-
-`discard_cleanups (OLD_CHAIN);'
- Same as `do_cleanups' except that it just removes the cleanups from
- the chain and does not call the specified functions.
-
- Cleanups are implemented as a chain. The handle returned by
-`make_cleanups' includes the cleanup passed to the call and any later
-cleanups appended to the chain (but not yet discarded or performed).
-E.g.:
-
- make_cleanup (a, 0);
- {
- struct cleanup *old = make_cleanup (b, 0);
- make_cleanup (c, 0)
- ...
- do_cleanups (old);
- }
-
-will call `c()' and `b()' but will not call `a()'. The cleanup that
-calls `a()' will remain in the cleanup chain, and will be done later
-unless otherwise discarded.
-
- Your function should explicitly do or discard the cleanups it
-creates. Failing to do this leads to non-deterministic behavior since
-the caller will arbitrarily do or discard your functions cleanups.
-This need leads to two common cleanup styles.
-
- The first style is try/finally. Before it exits, your code-block
-calls `do_cleanups' with the old cleanup chain and thus ensures that
-your code-block's cleanups are always performed. For instance, the
-following code-segment avoids a memory leak problem (even when `error'
-is called and a forced stack unwind occurs) by ensuring that the
-`xfree' will always be called:
-
- struct cleanup *old = make_cleanup (null_cleanup, 0);
- data = xmalloc (sizeof blah);
- make_cleanup (xfree, data);
- ... blah blah ...
- do_cleanups (old);
-
- The second style is try/except. Before it exits, your code-block
-calls `discard_cleanups' with the old cleanup chain and thus ensures
-that any created cleanups are not performed. For instance, the
-following code segment, ensures that the file will be closed but only
-if there is an error:
-
- FILE *file = fopen ("afile", "r");
- struct cleanup *old = make_cleanup (close_file, file);
- ... blah blah ...
- discard_cleanups (old);
- return file;
-
- Some functions, e.g., `fputs_filtered()' or `error()', specify that
-they "should not be called when cleanups are not in place". This means
-that any actions you need to reverse in the case of an error or
-interruption must be on the cleanup chain before you call these
-functions, since they might never return to your code (they `longjmp'
-instead).
-
-17.2 Per-architecture module data
-=================================
-
-The multi-arch framework includes a mechanism for adding module
-specific per-architecture data-pointers to the `struct gdbarch'
-architecture object.
-
- A module registers one or more per-architecture data-pointers using:
-
- -- Architecture Function: struct gdbarch_data *
-gdbarch_data_register_pre_init (gdbarch_data_pre_init_ftype *PRE_INIT)
- PRE_INIT is used to, on-demand, allocate an initial value for a
- per-architecture data-pointer using the architecture's obstack
- (passed in as a parameter). Since PRE_INIT can be called during
- architecture creation, it is not parameterized with the
- architecture. and must not call modules that use per-architecture
- data.
-
- -- Architecture Function: struct gdbarch_data *
-gdbarch_data_register_post_init (gdbarch_data_post_init_ftype
- *POST_INIT)
- POST_INIT is used to obtain an initial value for a
- per-architecture data-pointer _after_. Since POST_INIT is always
- called after architecture creation, it both receives the fully
- initialized architecture and is free to call modules that use
- per-architecture data (care needs to be taken to ensure that those
- other modules do not try to call back to this module as that will
- create in cycles in the initialization call graph).
-
- These functions return a `struct gdbarch_data' that is used to
-identify the per-architecture data-pointer added for that module.
-
- The per-architecture data-pointer is accessed using the function:
-
- -- Architecture Function: void * gdbarch_data (struct gdbarch
- *GDBARCH, struct gdbarch_data *DATA_HANDLE)
- Given the architecture ARCH and module data handle DATA_HANDLE
- (returned by `gdbarch_data_register_pre_init' or
- `gdbarch_data_register_post_init'), this function returns the
- current value of the per-architecture data-pointer. If the data
- pointer is `NULL', it is first initialized by calling the
- corresponding PRE_INIT or POST_INIT method.
-
- The examples below assume the following definitions:
-
- struct nozel { int total; };
- static struct gdbarch_data *nozel_handle;
-
- A module can extend the architecture vector, adding additional
-per-architecture data, using the PRE_INIT method. The module's
-per-architecture data is then initialized during architecture creation.
-
- In the below, the module's per-architecture _nozel_ is added. An
-architecture can specify its nozel by calling `set_gdbarch_nozel' from
-`gdbarch_init'.
-
- static void *
- nozel_pre_init (struct obstack *obstack)
- {
- struct nozel *data = OBSTACK_ZALLOC (obstack, struct nozel);
- return data;
- }
-
- extern void
- set_gdbarch_nozel (struct gdbarch *gdbarch, int total)
- {
- struct nozel *data = gdbarch_data (gdbarch, nozel_handle);
- data->total = nozel;
- }
-
- A module can on-demand create architecture dependent data structures
-using `post_init'.
-
- In the below, the nozel's total is computed on-demand by
-`nozel_post_init' using information obtained from the architecture.
-
- static void *
- nozel_post_init (struct gdbarch *gdbarch)
- {
- struct nozel *data = GDBARCH_OBSTACK_ZALLOC (gdbarch, struct nozel);
- nozel->total = gdbarch... (gdbarch);
- return data;
- }
-
- extern int
- nozel_total (struct gdbarch *gdbarch)
- {
- struct nozel *data = gdbarch_data (gdbarch, nozel_handle);
- return data->total;
- }
-
-17.3 Wrapping Output Lines
-==========================
-
-Output that goes through `printf_filtered' or `fputs_filtered' or
-`fputs_demangled' needs only to have calls to `wrap_here' added in
-places that would be good breaking points. The utility routines will
-take care of actually wrapping if the line width is exceeded.
-
- The argument to `wrap_here' is an indentation string which is
-printed _only_ if the line breaks there. This argument is saved away
-and used later. It must remain valid until the next call to
-`wrap_here' or until a newline has been printed through the
-`*_filtered' functions. Don't pass in a local variable and then return!
-
- It is usually best to call `wrap_here' after printing a comma or
-space. If you call it before printing a space, make sure that your
-indentation properly accounts for the leading space that will print if
-the line wraps there.
-
- Any function or set of functions that produce filtered output must
-finish by printing a newline, to flush the wrap buffer, before switching
-to unfiltered (`printf') output. Symbol reading routines that print
-warnings are a good example.
-
-17.4 Memory Management
-======================
-
-GDB does not use the functions `malloc', `realloc', `calloc', `free'
-and `asprintf'.
-
- GDB uses the functions `xmalloc', `xrealloc' and `xcalloc' when
-allocating memory. Unlike `malloc' et.al. these functions do not
-return when the memory pool is empty. Instead, they unwind the stack
-using cleanups. These functions return `NULL' when requested to
-allocate a chunk of memory of size zero.
-
- _Pragmatics: By using these functions, the need to check every
-memory allocation is removed. These functions provide portable
-behavior._
-
- GDB does not use the function `free'.
-
- GDB uses the function `xfree' to return memory to the memory pool.
-Consistent with ISO-C, this function ignores a request to free a `NULL'
-pointer.
-
- _Pragmatics: On some systems `free' fails when passed a `NULL'
-pointer._
-
- GDB can use the non-portable function `alloca' for the allocation of
-small temporary values (such as strings).
-
- _Pragmatics: This function is very non-portable. Some systems
-restrict the memory being allocated to no more than a few kilobytes._
-
- GDB uses the string function `xstrdup' and the print function
-`xstrprintf'.
-
- _Pragmatics: `asprintf' and `strdup' can fail. Print functions such
-as `sprintf' are very prone to buffer overflow errors._
-
-17.5 Compiler Warnings
-======================
-
-With few exceptions, developers should avoid the configuration option
-`--disable-werror' when building GDB. The exceptions are listed in the
-file `gdb/MAINTAINERS'. The default, when building with GCC, is
-`--enable-werror'.
-
- This option causes GDB (when built using GCC) to be compiled with a
-carefully selected list of compiler warning flags. Any warnings from
-those flags are treated as errors.
-
- The current list of warning flags includes:
-
-`-Wall'
- Recommended GCC warnings.
-
-`-Wdeclaration-after-statement'
- GCC 3.x (and later) and C99 allow declarations mixed with code,
- but GCC 2.x and C89 do not.
-
-`-Wpointer-arith'
-
-`-Wformat-nonliteral'
- Non-literal format strings, with a few exceptions, are bugs - they
- might contain unintended user-supplied format specifiers. Since
- GDB uses the `format printf' attribute on all `printf' like
- functions this checks not just `printf' calls but also calls to
- functions such as `fprintf_unfiltered'.
-
-`-Wno-pointer-sign'
- In version 4.0, GCC began warning about pointer argument passing or
- assignment even when the source and destination differed only in
- signedness. However, most GDB code doesn't distinguish carefully
- between `char' and `unsigned char'. In early 2006 the GDB
- developers decided correcting these warnings wasn't worth the time
- it would take.
-
-`-Wno-unused-parameter'
- Due to the way that GDB is implemented many functions have unused
- parameters. Consequently this warning is avoided. The macro
- `ATTRIBUTE_UNUSED' is not used as it leads to false negatives --
- it is not an error to have `ATTRIBUTE_UNUSED' on a parameter that
- is being used.
-
-`-Wno-unused'
-`-Wno-switch'
-`-Wno-char-subscripts'
- These are warnings which might be useful for GDB, but are
- currently too noisy to enable with `-Werror'.
-
-
-17.6 Internal Error Recovery
-============================
-
-During its execution, GDB can encounter two types of errors. User
-errors and internal errors. User errors include not only a user
-entering an incorrect command but also problems arising from corrupt
-object files and system errors when interacting with the target.
-Internal errors include situations where GDB has detected, at run time,
-a corrupt or erroneous situation.
-
- When reporting an internal error, GDB uses `internal_error' and
-`gdb_assert'.
-
- GDB must not call `abort' or `assert'.
-
- _Pragmatics: There is no `internal_warning' function. Either the
-code detected a user error, recovered from it and issued a `warning' or
-the code failed to correctly recover from the user error and issued an
-`internal_error'._
-
-17.7 Command Names
-==================
-
-GDB U/I commands are written `foo-bar', not `foo_bar'.
-
-17.8 Clean Design and Portable Implementation
-=============================================
-
-In addition to getting the syntax right, there's the little question of
-semantics. Some things are done in certain ways in GDB because long
-experience has shown that the more obvious ways caused various kinds of
-trouble.
-
- You can't assume the byte order of anything that comes from a target
-(including VALUEs, object files, and instructions). Such things must
-be byte-swapped using `SWAP_TARGET_AND_HOST' in GDB, or one of the swap
-routines defined in `bfd.h', such as `bfd_get_32'.
-
- You can't assume that you know what interface is being used to talk
-to the target system. All references to the target must go through the
-current `target_ops' vector.
-
- You can't assume that the host and target machines are the same
-machine (except in the "native" support modules). In particular, you
-can't assume that the target machine's header files will be available
-on the host machine. Target code must bring along its own header files
-- written from scratch or explicitly donated by their owner, to avoid
-copyright problems.
-
- Insertion of new `#ifdef''s will be frowned upon. It's much better
-to write the code portably than to conditionalize it for various
-systems.
-
- New `#ifdef''s which test for specific compilers or manufacturers or
-operating systems are unacceptable. All `#ifdef''s should test for
-features. The information about which configurations contain which
-features should be segregated into the configuration files. Experience
-has proven far too often that a feature unique to one particular system
-often creeps into other systems; and that a conditional based on some
-predefined macro for your current system will become worthless over
-time, as new versions of your system come out that behave differently
-with regard to this feature.
-
- Adding code that handles specific architectures, operating systems,
-target interfaces, or hosts, is not acceptable in generic code.
-
- One particularly notorious area where system dependencies tend to
-creep in is handling of file names. The mainline GDB code assumes
-Posix semantics of file names: absolute file names begin with a forward
-slash `/', slashes are used to separate leading directories,
-case-sensitive file names. These assumptions are not necessarily true
-on non-Posix systems such as MS-Windows. To avoid system-dependent
-code where you need to take apart or construct a file name, use the
-following portable macros:
-
-`HAVE_DOS_BASED_FILE_SYSTEM'
- This preprocessing symbol is defined to a non-zero value on hosts
- whose filesystems belong to the MS-DOS/MS-Windows family. Use this
- symbol to write conditional code which should only be compiled for
- such hosts.
-
-`IS_DIR_SEPARATOR (C)'
- Evaluates to a non-zero value if C is a directory separator
- character. On Unix and GNU/Linux systems, only a slash `/' is
- such a character, but on Windows, both `/' and `\' will pass.
-
-`IS_ABSOLUTE_PATH (FILE)'
- Evaluates to a non-zero value if FILE is an absolute file name.
- For Unix and GNU/Linux hosts, a name which begins with a slash `/'
- is absolute. On DOS and Windows, `d:/foo' and `x:\bar' are also
- absolute file names.
-
-`FILENAME_CMP (F1, F2)'
- Calls a function which compares file names F1 and F2 as
- appropriate for the underlying host filesystem. For Posix systems,
- this simply calls `strcmp'; on case-insensitive filesystems it
- will call `strcasecmp' instead.
-
-`DIRNAME_SEPARATOR'
- Evaluates to a character which separates directories in
- `PATH'-style lists, typically held in environment variables. This
- character is `:' on Unix, `;' on DOS and Windows.
-
-`SLASH_STRING'
- This evaluates to a constant string you should use to produce an
- absolute filename from leading directories and the file's basename.
- `SLASH_STRING' is `"/"' on most systems, but might be `"\\"' for
- some Windows-based ports.
-
- In addition to using these macros, be sure to use portable library
-functions whenever possible. For example, to extract a directory or a
-basename part from a file name, use the `dirname' and `basename'
-library functions (available in `libiberty' for platforms which don't
-provide them), instead of searching for a slash with `strrchr'.
-
- Another way to generalize GDB along a particular interface is with an
-attribute struct. For example, GDB has been generalized to handle
-multiple kinds of remote interfaces--not by `#ifdef's everywhere, but
-by defining the `target_ops' structure and having a current target (as
-well as a stack of targets below it, for memory references). Whenever
-something needs to be done that depends on which remote interface we are
-using, a flag in the current target_ops structure is tested (e.g.,
-`target_has_stack'), or a function is called through a pointer in the
-current target_ops structure. In this way, when a new remote interface
-is added, only one module needs to be touched--the one that actually
-implements the new remote interface. Other examples of
-attribute-structs are BFD access to multiple kinds of object file
-formats, or GDB's access to multiple source languages.
-
- Please avoid duplicating code. For example, in GDB 3.x all the code
-interfacing between `ptrace' and the rest of GDB was duplicated in
-`*-dep.c', and so changing something was very painful. In GDB 4.x,
-these have all been consolidated into `infptrace.c'. `infptrace.c' can
-deal with variations between systems the same way any system-independent
-file would (hooks, `#if defined', etc.), and machines which are
-radically different don't need to use `infptrace.c' at all.
-
- All debugging code must be controllable using the `set debug MODULE'
-command. Do not use `printf' to print trace messages. Use
-`fprintf_unfiltered(gdb_stdlog, ...'. Do not use `#ifdef DEBUG'.
-
-
-File: gdbint.info, Node: Porting GDB, Next: Versions and Branches, Prev: Misc Guidelines, Up: Top
-
-18 Porting GDB
-**************
-
-Most of the work in making GDB compile on a new machine is in
-specifying the configuration of the machine. Porting a new
-architecture to GDB can be broken into a number of steps.
-
- * Ensure a BFD exists for executables of the target architecture in
- the `bfd' directory. If one does not exist, create one by
- modifying an existing similar one.
-
- * Implement a disassembler for the target architecture in the
- `opcodes' directory.
-
- * Define the target architecture in the `gdb' directory (*note
- Adding a New Target: Adding a New Target.). Add the pattern for
- the new target to `configure.tgt' with the names of the files that
- contain the code. By convention the target architecture
- definition for an architecture ARCH is placed in `ARCH-tdep.c'.
-
- Within `ARCH-tdep.c' define the function `_initialize_ARCH_tdep'
- which calls `gdbarch_register' to create the new `struct gdbarch'
- for the architecture.
-
- * If a new remote target is needed, consider adding a new remote
- target by defining a function `_initialize_remote_ARCH'. However
- if at all possible use the GDB _Remote Serial Protocol_ for this
- and implement the server side protocol independently with the
- target.
-
- * If desired implement a simulator in the `sim' directory. This
- should create the library `libsim.a' implementing the interface in
- `remote-sim.h' (found in the `include' directory).
-
- * Build and test. If desired, lobby the GDB steering group to have
- the new port included in the main distribution!
-
- * Add a description of the new architecture to the main GDB user
- guide (*note Configuration Specific Information:
- (gdb)Configuration Specific Information.).
-
-
-
-File: gdbint.info, Node: Versions and Branches, Next: Start of New Year Procedure, Prev: Porting GDB, Up: Top
-
-19 Versions and Branches
-************************
-
-19.1 Versions
-=============
-
-GDB's version is determined by the file `gdb/version.in' and takes one
-of the following forms:
-
-MAJOR.MINOR
-MAJOR.MINOR.PATCHLEVEL
- an official release (e.g., 6.2 or 6.2.1)
-
-MAJOR.MINOR.PATCHLEVEL.YYYYMMDD
- a snapshot taken at YYYY-MM-DD-gmt (e.g., 6.1.50.20020302,
- 6.1.90.20020304, or 6.1.0.20020308)
-
-MAJOR.MINOR.PATCHLEVEL.YYYYMMDD-cvs
- a CVS check out drawn on YYYY-MM-DD (e.g., 6.1.50.20020302-cvs,
- 6.1.90.20020304-cvs, or 6.1.0.20020308-cvs)
-
-MAJOR.MINOR.PATCHLEVEL.YYYYMMDD (VENDOR)
- a vendor specific release of GDB, that while based on
- MAJOR.MINOR.PATCHLEVEL.YYYYMMDD, may include additional changes
-
- GDB's mainline uses the MAJOR and MINOR version numbers from the
-most recent release branch, with a PATCHLEVEL of 50. At the time each
-new release branch is created, the mainline's MAJOR and MINOR version
-numbers are updated.
-
- GDB's release branch is similar. When the branch is cut, the
-PATCHLEVEL is changed from 50 to 90. As draft releases are drawn from
-the branch, the PATCHLEVEL is incremented. Once the first release
-(MAJOR.MINOR) has been made, the PATCHLEVEL is set to 0 and updates
-have an incremented PATCHLEVEL.
-
- For snapshots, and CVS check outs, it is also possible to identify
-the CVS origin:
-
-MAJOR.MINOR.50.YYYYMMDD
- drawn from the HEAD of mainline CVS (e.g., 6.1.50.20020302)
-
-MAJOR.MINOR.90.YYYYMMDD
-MAJOR.MINOR.91.YYYYMMDD ...
- drawn from a release branch prior to the release (e.g.,
- 6.1.90.20020304)
-
-MAJOR.MINOR.0.YYYYMMDD
-MAJOR.MINOR.1.YYYYMMDD ...
- drawn from a release branch after the release (e.g.,
- 6.2.0.20020308)
-
- If the previous GDB version is 6.1 and the current version is 6.2,
-then, substituting 6 for MAJOR and 1 or 2 for MINOR, here's an
-illustration of a typical sequence:
-
- <HEAD>
- |
- 6.1.50.20020302-cvs
- |
- +--------------------------.
- | <gdb_6_2-branch>
- | |
- 6.2.50.20020303-cvs 6.1.90 (draft #1)
- | |
- 6.2.50.20020304-cvs 6.1.90.20020304-cvs
- | |
- 6.2.50.20020305-cvs 6.1.91 (draft #2)
- | |
- 6.2.50.20020306-cvs 6.1.91.20020306-cvs
- | |
- 6.2.50.20020307-cvs 6.2 (release)
- | |
- 6.2.50.20020308-cvs 6.2.0.20020308-cvs
- | |
- 6.2.50.20020309-cvs 6.2.1 (update)
- | |
- 6.2.50.20020310-cvs <branch closed>
- |
- 6.2.50.20020311-cvs
- |
- +--------------------------.
- | <gdb_6_3-branch>
- | |
- 6.3.50.20020312-cvs 6.2.90 (draft #1)
- | |
-
-19.2 Release Branches
-=====================
-
-GDB draws a release series (6.2, 6.2.1, ...) from a single release
-branch, and identifies that branch using the CVS branch tags:
-
- gdb_MAJOR_MINOR-YYYYMMDD-branchpoint
- gdb_MAJOR_MINOR-branch
- gdb_MAJOR_MINOR-YYYYMMDD-release
-
- _Pragmatics: To help identify the date at which a branch or release
-is made, both the branchpoint and release tags include the date that
-they are cut (YYYYMMDD) in the tag. The branch tag, denoting the head
-of the branch, does not need this._
-
-19.3 Vendor Branches
-====================
-
-To avoid version conflicts, vendors are expected to modify the file
-`gdb/version.in' to include a vendor unique alphabetic identifier (an
-official GDB release never uses alphabetic characters in its version
-identifier). E.g., `6.2widgit2', or `6.2 (Widgit Inc Patch 2)'.
-
-19.4 Experimental Branches
-==========================
-
-19.4.1 Guidelines
------------------
-
-GDB permits the creation of branches, cut from the CVS repository, for
-experimental development. Branches make it possible for developers to
-share preliminary work, and maintainers to examine significant new
-developments.
-
- The following are a set of guidelines for creating such branches:
-
-_a branch has an owner_
- The owner can set further policy for a branch, but may not change
- the ground rules. In particular, they can set a policy for
- commits (be it adding more reviewers or deciding who can commit).
-
-_all commits are posted_
- All changes committed to a branch shall also be posted to the GDB
- patches mailing list <gdb-patches@sourceware.org>. While
- commentary on such changes are encouraged, people should remember
- that the changes only apply to a branch.
-
-_all commits are covered by an assignment_
- This ensures that all changes belong to the Free Software
- Foundation, and avoids the possibility that the branch may become
- contaminated.
-
-_a branch is focused_
- A focused branch has a single objective or goal, and does not
- contain unnecessary or irrelevant changes. Cleanups, where
- identified, being be pushed into the mainline as soon as possible.
-
-_a branch tracks mainline_
- This keeps the level of divergence under control. It also keeps
- the pressure on developers to push cleanups and other stuff into
- the mainline.
-
-_a branch shall contain the entire GDB module_
- The GDB module `gdb' should be specified when creating a branch
- (branches of individual files should be avoided). *Note Tags::.
-
-_a branch shall be branded using `version.in'_
- The file `gdb/version.in' shall be modified so that it identifies
- the branch OWNER and branch NAME, e.g.,
- `6.2.50.20030303_owner_name' or `6.2 (Owner Name)'.
-
-
-19.4.2 Tags
------------
-
-To simplify the identification of GDB branches, the following branch
-tagging convention is strongly recommended:
-
-`OWNER_NAME-YYYYMMDD-branchpoint'
-`OWNER_NAME-YYYYMMDD-branch'
- The branch point and corresponding branch tag. YYYYMMDD is the
- date that the branch was created. A branch is created using the
- sequence:
- cvs rtag OWNER_NAME-YYYYMMDD-branchpoint gdb
- cvs rtag -b -r OWNER_NAME-YYYYMMDD-branchpoint \
- OWNER_NAME-YYYYMMDD-branch gdb
-
-`OWNER_NAME-YYYYMMDD-mergepoint'
- The tagged point, on the mainline, that was used when merging the
- branch on YYYYMMDD. To merge in all changes since the branch was
- cut, use a command sequence like:
- cvs rtag OWNER_NAME-YYYYMMDD-mergepoint gdb
- cvs update \
- -jOWNER_NAME-YYYYMMDD-branchpoint
- -jOWNER_NAME-YYYYMMDD-mergepoint
- Similar sequences can be used to just merge in changes since the
- last merge.
-
-
-For further information on CVS, see Concurrent Versions System
-(http://www.gnu.org/software/cvs/).
-
-
-File: gdbint.info, Node: Start of New Year Procedure, Next: Releasing GDB, Prev: Versions and Branches, Up: Top
-
-20 Start of New Year Procedure
-******************************
-
-At the start of each new year, the following actions should be
-performed:
-
- * Rotate the ChangeLog file
-
- The current `ChangeLog' file should be renamed into
- `ChangeLog-YYYY' where YYYY is the year that has just passed. A
- new `ChangeLog' file should be created, and its contents should
- contain a reference to the previous ChangeLog. The following
- should also be preserved at the end of the new ChangeLog, in order
- to provide the appropriate settings when editing this file with
- Emacs:
- Local Variables:
- mode: change-log
- left-margin: 8
- fill-column: 74
- version-control: never
- coding: utf-8
- End:
-
- * Add an entry for the newly created ChangeLog file
- (`ChangeLog-YYYY') in `gdb/config/djgpp/fnchange.lst'.
-
- * Update the copyright year in the startup message
-
- Update the copyright year in:
- * file `top.c', function `print_gdb_version'
-
- * file `gdbserver/server.c', function `gdbserver_version'
-
- * file `gdbserver/gdbreplay.c', function `gdbreplay_version'
-
- * Run the `copyright.sh' script to add the new year in the copyright
- notices of most source files. This script requires Emacs 22 or
- later to be installed.
-
- * The new year also needs to be added manually in all other files
- that are not already taken care of by the `copyright.sh' script:
- * `*.s'
-
- * `*.f'
-
- * `*.f90'
-
- * `*.igen'
-
- * `*.ac'
-
- * `*.texi'
-
- * `*.texinfo'
-
- * `*.tex'
-
- * `*.defs'
-
- * `*.1'
-
-
-
-File: gdbint.info, Node: Releasing GDB, Next: Testsuite, Prev: Start of New Year Procedure, Up: Top
-
-21 Releasing GDB
-****************
-
-21.1 Branch Commit Policy
-=========================
-
-The branch commit policy is pretty slack. GDB releases 5.0, 5.1 and
-5.2 all used the below:
-
- * The `gdb/MAINTAINERS' file still holds.
-
- * Don't fix something on the branch unless/until it is also fixed in
- the trunk. If this isn't possible, mentioning it in the
- `gdb/PROBLEMS' file is better than committing a hack.
-
- * When considering a patch for the branch, suggested criteria
- include: Does it fix a build? Does it fix the sequence `break
- main; run' when debugging a static binary?
-
- * The further a change is from the core of GDB, the less likely the
- change will worry anyone (e.g., target specific code).
-
- * Only post a proposal to change the core of GDB after you've sent
- individual bribes to all the people listed in the `MAINTAINERS'
- file ;-)
-
- _Pragmatics: Provided updates are restricted to non-core
-functionality there is little chance that a broken change will be fatal.
-This means that changes such as adding a new architectures or (within
-reason) support for a new host are considered acceptable._
-
-21.2 Obsoleting code
-====================
-
-Before anything else, poke the other developers (and around the source
-code) to see if there is anything that can be removed from GDB (an old
-target, an unused file).
-
- Obsolete code is identified by adding an `OBSOLETE' prefix to every
-line. Doing this means that it is easy to identify something that has
-been obsoleted when greping through the sources.
-
- The process is done in stages -- this is mainly to ensure that the
-wider GDB community has a reasonable opportunity to respond. Remember,
-everything on the Internet takes a week.
-
- 1. Post the proposal on the GDB mailing list <gdb@sourceware.org>
- Creating a bug report to track the task's state, is also highly
- recommended.
-
- 2. Wait a week or so.
-
- 3. Post the proposal on the GDB Announcement mailing list
- <gdb-announce@sourceware.org>.
-
- 4. Wait a week or so.
-
- 5. Go through and edit all relevant files and lines so that they are
- prefixed with the word `OBSOLETE'.
-
- 6. Wait until the next GDB version, containing this obsolete code,
- has been released.
-
- 7. Remove the obsolete code.
-
-_Maintainer note: While removing old code is regrettable it is
-hopefully better for GDB's long term development. Firstly it helps the
-developers by removing code that is either no longer relevant or simply
-wrong. Secondly since it removes any history associated with the file
-(effectively clearing the slate) the developer has a much freer hand
-when it comes to fixing broken files._
-
-21.3 Before the Branch
-======================
-
-The most important objective at this stage is to find and fix simple
-changes that become a pain to track once the branch is created. For
-instance, configuration problems that stop GDB from even building. If
-you can't get the problem fixed, document it in the `gdb/PROBLEMS' file.
-
-Prompt for `gdb/NEWS'
----------------------
-
-People always forget. Send a post reminding them but also if you know
-something interesting happened add it yourself. The `schedule' script
-will mention this in its e-mail.
-
-Review `gdb/README'
--------------------
-
-Grab one of the nightly snapshots and then walk through the
-`gdb/README' looking for anything that can be improved. The `schedule'
-script will mention this in its e-mail.
-
-Refresh any imported files.
----------------------------
-
-A number of files are taken from external repositories. They include:
-
- * `texinfo/texinfo.tex'
-
- * `config.guess' et. al. (see the top-level `MAINTAINERS' file)
-
- * `etc/standards.texi', `etc/make-stds.texi'
-
-Check the ARI
--------------
-
-A.R.I. is an `awk' script (Awk Regression Index ;-) that checks for a
-number of errors and coding conventions. The checks include things
-like using `malloc' instead of `xmalloc' and file naming problems.
-There shouldn't be any regressions.
-
-21.3.1 Review the bug data base
--------------------------------
-
-Close anything obviously fixed.
-
-21.3.2 Check all cross targets build
-------------------------------------
-
-The targets are listed in `gdb/MAINTAINERS'.
-
-21.4 Cut the Branch
-===================
-
-Create the branch
------------------
-
- $ u=5.1
- $ v=5.2
- $ V=`echo $v | sed 's/\./_/g'`
- $ D=`date -u +%Y-%m-%d`
- $ echo $u $V $D
- 5.1 5_2 2002-03-03
- $ echo cvs -f -d :ext:sourceware.org:/cvs/src rtag \
- -D $D-gmt gdb_$V-$D-branchpoint insight
- cvs -f -d :ext:sourceware.org:/cvs/src rtag
- -D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight
- $ ^echo ^^
- ...
- $ echo cvs -f -d :ext:sourceware.org:/cvs/src rtag \
- -b -r gdb_$V-$D-branchpoint gdb_$V-branch insight
- cvs -f -d :ext:sourceware.org:/cvs/src rtag \
- -b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight
- $ ^echo ^^
- ...
- $
-
- * By using `-D YYYY-MM-DD-gmt', the branch is forced to an exact
- date/time.
-
- * The trunk is first tagged so that the branch point can easily be
- found.
-
- * Insight, which includes GDB, is tagged at the same time.
-
- * `version.in' gets bumped to avoid version number conflicts.
-
- * The reading of `.cvsrc' is disabled using `-f'.
-
-Update `version.in'
--------------------
-
- $ u=5.1
- $ v=5.2
- $ V=`echo $v | sed 's/\./_/g'`
- $ echo $u $v$V
- 5.1 5_2
- $ cd /tmp
- $ echo cvs -f -d :ext:sourceware.org:/cvs/src co \
- -r gdb_$V-branch src/gdb/version.in
- cvs -f -d :ext:sourceware.org:/cvs/src co
- -r gdb_5_2-branch src/gdb/version.in
- $ ^echo ^^
- U src/gdb/version.in
- $ cd src/gdb
- $ echo $u.90-0000-00-00-cvs > version.in
- $ cat version.in
- 5.1.90-0000-00-00-cvs
- $ cvs -f commit version.in
-
- * `0000-00-00' is used as a date to pump prime the version.in update
- mechanism.
-
- * `.90' and the previous branch version are used as fairly arbitrary
- initial branch version number.
-
-Update the web and news pages
------------------------------
-
-Something?
-
-Tweak cron to track the new branch
-----------------------------------
-
-The file `gdbadmin/cron/crontab' contains gdbadmin's cron table. This
-file needs to be updated so that:
-
- * A daily timestamp is added to the file `version.in'.
-
- * The new branch is included in the snapshot process.
-
-See the file `gdbadmin/cron/README' for how to install the updated cron
-table.
-
- The file `gdbadmin/ss/README' should also be reviewed to reflect any
-changes. That file is copied to both the branch/ and current/ snapshot
-directories.
-
-Update the NEWS and README files
---------------------------------
-
-The `NEWS' file needs to be updated so that on the branch it refers to
-_changes in the current release_ while on the trunk it also refers to
-_changes since the current release_.
-
- The `README' file needs to be updated so that it refers to the
-current release.
-
-Post the branch info
---------------------
-
-Send an announcement to the mailing lists:
-
- * GDB Announcement mailing list <gdb-announce@sourceware.org>
-
- * GDB Discussion mailing list <gdb@sourceware.org> and GDB Testers
- mailing list <gdb-testers@sourceware.org>
-
- _Pragmatics: The branch creation is sent to the announce list to
-ensure that people people not subscribed to the higher volume discussion
-list are alerted._
-
- The announcement should include:
-
- * The branch tag.
-
- * How to check out the branch using CVS.
-
- * The date/number of weeks until the release.
-
- * The branch commit policy still holds.
-
-21.5 Stabilize the branch
-=========================
-
-Something goes here.
-
-21.6 Create a Release
-=====================
-
-The process of creating and then making available a release is broken
-down into a number of stages. The first part addresses the technical
-process of creating a releasable tar ball. The later stages address the
-process of releasing that tar ball.
-
- When making a release candidate just the first section is needed.
-
-21.6.1 Create a release candidate
----------------------------------
-
-The objective at this stage is to create a set of tar balls that can be
-made available as a formal release (or as a less formal release
-candidate).
-
-Freeze the branch
-.................
-
-Send out an e-mail notifying everyone that the branch is frozen to
-<gdb-patches@sourceware.org>.
-
-Establish a few defaults.
-.........................
-
- $ b=gdb_5_2-branch
- $ v=5.2
- $ t=/sourceware/snapshot-tmp/gdbadmin-tmp
- $ echo $t/$b/$v
- /sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2
- $ mkdir -p $t/$b/$v
- $ cd $t/$b/$v
- $ pwd
- /sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2
- $ which autoconf
- /home/gdbadmin/bin/autoconf
- $
-
-Notes:
-
- * Check the `autoconf' version carefully. You want to be using the
- version documented in the toplevel `README-maintainer-mode' file.
- It is very unlikely that the version of `autoconf' installed in
- system directories (e.g., `/usr/bin/autoconf') is correct.
-
-Check out the relevant modules:
-...............................
-
- $ for m in gdb insight
- do
- ( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
- done
- $
-
-Note:
-
- * The reading of `.cvsrc' is disabled (`-f') so that there isn't any
- confusion between what is written here and what your local `cvs'
- really does.
-
-Update relevant files.
-......................
-
-`gdb/NEWS'
- Major releases get their comments added as part of the mainline.
- Minor releases should probably mention any significant bugs that
- were fixed.
-
- Don't forget to include the `ChangeLog' entry.
-
- $ emacs gdb/src/gdb/NEWS
- ...
- c-x 4 a
- ...
- c-x c-s c-x c-c
- $ cp gdb/src/gdb/NEWS insight/src/gdb/NEWS
- $ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog
-
-`gdb/README'
- You'll need to update:
-
- * The version.
-
- * The update date.
-
- * Who did it.
-
- $ emacs gdb/src/gdb/README
- ...
- c-x 4 a
- ...
- c-x c-s c-x c-c
- $ cp gdb/src/gdb/README insight/src/gdb/README
- $ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog
-
- _Maintainer note: Hopefully the `README' file was reviewed before
- the initial branch was cut so just a simple substitute is needed
- to get it updated._
-
- _Maintainer note: Other projects generate `README' and `INSTALL'
- from the core documentation. This might be worth pursuing._
-
-`gdb/version.in'
- $ echo $v > gdb/src/gdb/version.in
- $ cat gdb/src/gdb/version.in
- 5.2
- $ emacs gdb/src/gdb/version.in
- ...
- c-x 4 a
- ... Bump to version ...
- c-x c-s c-x c-c
- $ cp gdb/src/gdb/version.in insight/src/gdb/version.in
- $ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog
-
-
-Do the dirty work
-.................
-
-This is identical to the process used to create the daily snapshot.
-
- $ for m in gdb insight
- do
- ( cd $m/src && gmake -f src-release $m.tar )
- done
-
- If the top level source directory does not have `src-release' (GDB
-version 5.3.1 or earlier), try these commands instead:
-
- $ for m in gdb insight
- do
- ( cd $m/src && gmake -f Makefile.in $m.tar )
- done
-
-Check the source files
-......................
-
-You're looking for files that have mysteriously disappeared.
-`distclean' has the habit of deleting files it shouldn't. Watch out
-for the `version.in' update `cronjob'.
-
- $ ( cd gdb/src && cvs -f -q -n update )
- M djunpack.bat
- ? gdb-5.1.91.tar
- ? proto-toplev
- ... lots of generated files ...
- M gdb/ChangeLog
- M gdb/NEWS
- M gdb/README
- M gdb/version.in
- ... lots of generated files ...
- $
-
-_Don't worry about the `gdb.info-??' or `gdb/p-exp.tab.c'. They were
-generated (and yes `gdb.info-1' was also generated only something
-strange with CVS means that they didn't get suppressed). Fixing it
-would be nice though._
-
-Create compressed versions of the release
-.........................................
-
- $ cp */src/*.tar .
- $ cp */src/*.bz2 .
- $ ls -F
- gdb/ gdb-5.2.tar insight/ insight-5.2.tar
- $ for m in gdb insight
- do
- bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2
- gzip -v -9 -c $m-$v.tar > $m-$v.tar.gz
- done
- $
-
-Note:
-
- * A pipe such as `bunzip2 < xxx.bz2 | gzip -9 > xxx.gz' is not since,
- in that mode, `gzip' does not know the name of the file and, hence,
- can not include it in the compressed file. This is also why the
- release process runs `tar' and `bzip2' as separate passes.
-
-21.6.2 Sanity check the tar ball
---------------------------------
-
-Pick a popular machine (Solaris/PPC?) and try the build on that.
-
- $ bunzip2 < gdb-5.2.tar.bz2 | tar xpf -
- $ cd gdb-5.2
- $ ./configure
- $ make
- ...
- $ ./gdb/gdb ./gdb/gdb
- GNU gdb 5.2
- ...
- (gdb) b main
- Breakpoint 1 at 0x80732bc: file main.c, line 734.
- (gdb) run
- Starting program: /tmp/gdb-5.2/gdb/gdb
-
- Breakpoint 1, main (argc=1, argv=0xbffff8b4) at main.c:734
- 734 catch_errors (captured_main, &args, "", RETURN_MASK_ALL);
- (gdb) print args
- $1 = {argc = 136426532, argv = 0x821b7f0}
- (gdb)
-
-21.6.3 Make a release candidate available
------------------------------------------
-
-If this is a release candidate then the only remaining steps are:
-
- 1. Commit `version.in' and `ChangeLog'
-
- 2. Tweak `version.in' (and `ChangeLog' to read L.M.N-0000-00-00-cvs
- so that the version update process can restart.
-
- 3. Make the release candidate available in
- `ftp://sourceware.org/pub/gdb/snapshots/branch'
-
- 4. Notify the relevant mailing lists ( <gdb@sourceware.org> and
- <gdb-testers@sourceware.org> that the candidate is available.
-
-21.6.4 Make a formal release available
---------------------------------------
-
-(And you thought all that was required was to post an e-mail.)
-
-Install on sware
-................
-
-Copy the new files to both the release and the old release directory:
-
- $ cp *.bz2 *.gz ~ftp/pub/gdb/old-releases/
- $ cp *.bz2 *.gz ~ftp/pub/gdb/releases
-
-Clean up the releases directory so that only the most recent releases
-are available (e.g. keep 5.2 and 5.2.1 but remove 5.1):
-
- $ cd ~ftp/pub/gdb/releases
- $ rm ...
-
-Update the file `README' and `.message' in the releases directory:
-
- $ vi README
- ...
- $ rm -f .message
- $ ln README .message
-
-Update the web pages.
-.....................
-
-`htdocs/download/ANNOUNCEMENT'
- This file, which is posted as the official announcement, includes:
- * General announcement.
-
- * News. If making an M.N.1 release, retain the news from
- earlier M.N release.
-
- * Errata.
-
-`htdocs/index.html'
-`htdocs/news/index.html'
-`htdocs/download/index.html'
- These files include:
- * Announcement of the most recent release.
-
- * News entry (remember to update both the top level and the
- news directory).
- These pages also need to be regenerate using `index.sh'.
-
-`download/onlinedocs/'
- You need to find the magic command that is used to generate the
- online docs from the `.tar.bz2'. The best way is to look in the
- output from one of the nightly `cron' jobs and then just edit
- accordingly. Something like:
-
- $ ~/ss/update-web-docs \
- ~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \
- $PWD/www \
- /www/sourceware/htdocs/gdb/download/onlinedocs \
- gdb
-
-`download/ari/'
- Just like the online documentation. Something like:
-
- $ /bin/sh ~/ss/update-web-ari \
- ~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \
- $PWD/www \
- /www/sourceware/htdocs/gdb/download/ari \
- gdb
-
-
-Shadow the pages onto gnu
-.........................
-
-Something goes here.
-
-Install the GDB tar ball on GNU
-...............................
-
-At the time of writing, the GNU machine was `gnudist.gnu.org' in
-`~ftp/gnu/gdb'.
-
-Make the `ANNOUNCEMENT'
-.......................
-
-Post the `ANNOUNCEMENT' file you created above to:
-
- * GDB Announcement mailing list <gdb-announce@sourceware.org>
-
- * General GNU Announcement list <info-gnu@gnu.org> (but delay it a
- day or so to let things get out)
-
- * GDB Bug Report mailing list <bug-gdb@gnu.org>
-
-21.6.5 Cleanup
---------------
-
-The release is out but you're still not finished.
-
-Commit outstanding changes
-..........................
-
-In particular you'll need to commit any changes to:
-
- * `gdb/ChangeLog'
-
- * `gdb/version.in'
-
- * `gdb/NEWS'
-
- * `gdb/README'
-
-Tag the release
-...............
-
-Something like:
-
- $ d=`date -u +%Y-%m-%d`
- $ echo $d
- 2002-01-24
- $ ( cd insight/src/gdb && cvs -f -q update )
- $ ( cd insight/src && cvs -f -q tag gdb_5_2-$d-release )
-
- Insight is used since that contains more of the release than GDB.
-
-Mention the release on the trunk
-................................
-
-Just put something in the `ChangeLog' so that the trunk also indicates
-when the release was made.
-
-Restart `gdb/version.in'
-........................
-
-If `gdb/version.in' does not contain an ISO date such as `2002-01-24'
-then the daily `cronjob' won't update it. Having committed all the
-release changes it can be set to `5.2.0_0000-00-00-cvs' which will
-restart things (yes the `_' is important - it affects the snapshot
-process).
-
- Don't forget the `ChangeLog'.
-
-Merge into trunk
-................
-
-The files committed to the branch may also need changes merged into the
-trunk.
-
-Revise the release schedule
-...........................
-
-Post a revised release schedule to GDB Discussion List
-<gdb@sourceware.org> with an updated announcement. The schedule can be
-generated by running:
-
- $ ~/ss/schedule `date +%s` schedule
-
-The first parameter is approximate date/time in seconds (from the epoch)
-of the most recent release.
-
- Also update the schedule `cronjob'.
-
-21.7 Post release
-=================
-
-Remove any `OBSOLETE' code.
-
-
-File: gdbint.info, Node: Testsuite, Next: Hints, Prev: Releasing GDB, Up: Top
-
-22 Testsuite
-************
-
-The testsuite is an important component of the GDB package. While it
-is always worthwhile to encourage user testing, in practice this is
-rarely sufficient; users typically use only a small subset of the
-available commands, and it has proven all too common for a change to
-cause a significant regression that went unnoticed for some time.
-
- The GDB testsuite uses the DejaGNU testing framework. The tests
-themselves are calls to various `Tcl' procs; the framework runs all the
-procs and summarizes the passes and fails.
-
-22.1 Using the Testsuite
-========================
-
-To run the testsuite, simply go to the GDB object directory (or to the
-testsuite's objdir) and type `make check'. This just sets up some
-environment variables and invokes DejaGNU's `runtest' script. While
-the testsuite is running, you'll get mentions of which test file is in
-use, and a mention of any unexpected passes or fails. When the
-testsuite is finished, you'll get a summary that looks like this:
-
- === gdb Summary ===
-
- # of expected passes 6016
- # of unexpected failures 58
- # of unexpected successes 5
- # of expected failures 183
- # of unresolved testcases 3
- # of untested testcases 5
-
- To run a specific test script, type:
- make check RUNTESTFLAGS='TESTS'
- where TESTS is a list of test script file names, separated by spaces.
-
- If you use GNU make, you can use its `-j' option to run the
-testsuite in parallel. This can greatly reduce the amount of time it
-takes for the testsuite to run. In this case, if you set
-`RUNTESTFLAGS' then, by default, the tests will be run serially even
-under `-j'. You can override this and force a parallel run by setting
-the `make' variable `FORCE_PARALLEL' to any non-empty value. Note that
-the parallel `make check' assumes that you want to run the entire
-testsuite, so it is not compatible with some dejagnu options, like
-`--directory'.
-
- The ideal test run consists of expected passes only; however, reality
-conspires to keep us from this ideal. Unexpected failures indicate
-real problems, whether in GDB or in the testsuite. Expected failures
-are still failures, but ones which have been decided are too hard to
-deal with at the time; for instance, a test case might work everywhere
-except on AIX, and there is no prospect of the AIX case being fixed in
-the near future. Expected failures should not be added lightly, since
-you may be masking serious bugs in GDB. Unexpected successes are
-expected fails that are passing for some reason, while unresolved and
-untested cases often indicate some minor catastrophe, such as the
-compiler being unable to deal with a test program.
-
- When making any significant change to GDB, you should run the
-testsuite before and after the change, to confirm that there are no
-regressions. Note that truly complete testing would require that you
-run the testsuite with all supported configurations and a variety of
-compilers; however this is more than really necessary. In many cases
-testing with a single configuration is sufficient. Other useful
-options are to test one big-endian (Sparc) and one little-endian (x86)
-host, a cross config with a builtin simulator (powerpc-eabi, mips-elf),
-or a 64-bit host (Alpha).
-
- If you add new functionality to GDB, please consider adding tests
-for it as well; this way future GDB hackers can detect and fix their
-changes that break the functionality you added. Similarly, if you fix
-a bug that was not previously reported as a test failure, please add a
-test case for it. Some cases are extremely difficult to test, such as
-code that handles host OS failures or bugs in particular versions of
-compilers, and it's OK not to try to write tests for all of those.
-
- DejaGNU supports separate build, host, and target machines. However,
-some GDB test scripts do not work if the build machine and the host
-machine are not the same. In such an environment, these scripts will
-give a result of "UNRESOLVED", like this:
-
- UNRESOLVED: gdb.base/example.exp: This test script does not work on a remote host.
-
-22.2 Testsuite Parameters
-=========================
-
-Several variables exist to modify the behavior of the testsuite.
-
- * `TRANSCRIPT'
-
- Sometimes it is convenient to get a transcript of the commands
- which the testsuite sends to GDB. For example, if GDB crashes
- during testing, a transcript can be used to more easily
- reconstruct the failure when running GDB under GDB.
-
- You can instruct the GDB testsuite to write transcripts by setting
- the DejaGNU variable `TRANSCRIPT' (to any value) before invoking
- `runtest' or `make check'. The transcripts will be written into
- DejaGNU's output directory. One transcript will be made for each
- invocation of GDB; they will be named `transcript.N', where N is
- an integer. The first line of the transcript file will show how
- GDB was invoked; each subsequent line is a command sent as input
- to GDB.
-
- make check RUNTESTFLAGS=TRANSCRIPT=y
-
- Note that the transcript is not always complete. In particular,
- tests of completion can yield partial command lines.
-
- * `GDB'
-
- Sometimes one wishes to test a different GDB than the one in the
- build directory. For example, one may wish to run the testsuite on
- `/usr/bin/gdb'.
-
- make check RUNTESTFLAGS=GDB=/usr/bin/gdb
-
- * `GDBSERVER'
-
- When testing a different GDB, it is often useful to also test a
- different gdbserver.
-
- make check RUNTESTFLAGS="GDB=/usr/bin/gdb GDBSERVER=/usr/bin/gdbserver"
-
- * `INTERNAL_GDBFLAGS'
-
- When running the testsuite normally one doesn't want whatever is in
- `~/.gdbinit' to interfere with the tests, therefore the test
- harness passes `-nx' to GDB. One also doesn't want any windowed
- version of GDB, e.g., `gdbtui', to run. This is achieved via
- `INTERNAL_GDBFLAGS'.
-
- set INTERNAL_GDBFLAGS "-nw -nx"
-
- This is all well and good, except when testing an installed GDB
- that has been configured with `--with-system-gdbinit'. Here one
- does not want `~/.gdbinit' loaded but one may want the system
- `.gdbinit' file loaded. This can be achieved by pointing `$HOME'
- at a directory without a `.gdbinit' and by overriding
- `INTERNAL_GDBFLAGS' and removing `-nx'.
-
- cd testsuite
- HOME=`pwd` runtest \
- GDB=/usr/bin/gdb \
- GDBSERVER=/usr/bin/gdbserver \
- INTERNAL_GDBFLAGS=-nw
-
-
- There are two ways to run the testsuite and pass additional
-parameters to DejaGnu. The first is with `make check' and specifying
-the makefile variable `RUNTESTFLAGS'.
-
- make check RUNTESTFLAGS=TRANSCRIPT=y
-
- The second is to cd to the `testsuite' directory and invoke the
-DejaGnu `runtest' command directly.
-
- cd testsuite
- make site.exp
- runtest TRANSCRIPT=y
-
-22.3 Testsuite Configuration
-============================
-
-It is possible to adjust the behavior of the testsuite by defining the
-global variables listed below, either in a `site.exp' file, or in a
-board file.
-
- * `gdb_test_timeout'
-
- Defining this variable changes the default timeout duration used
- during communication with GDB. More specifically, the global
- variable used during testing is `timeout', but this variable gets
- reset to `gdb_test_timeout' at the beginning of each testcase,
- making sure that any local change to `timeout' in a testcase does
- not affect subsequent testcases.
-
- This global variable comes in handy when the debugger is slower
- than normal due to the testing environment, triggering unexpected
- `TIMEOUT' test failures. Examples include when testing on a
- remote machine, or against a system where communications are slow.
-
- If not specifically defined, this variable gets automatically
- defined to the same value as `timeout' during the testsuite
- initialization. The default value of the timeout is defined in
- the file `gdb/testsuite/config/unix.exp' that is part of the GDB
- test suite(1).
-
-
-22.4 Testsuite Organization
-===========================
-
-The testsuite is entirely contained in `gdb/testsuite'. While the
-testsuite includes some makefiles and configury, these are very minimal,
-and used for little besides cleaning up, since the tests themselves
-handle the compilation of the programs that GDB will run. The file
-`testsuite/lib/gdb.exp' contains common utility procs useful for all
-GDB tests, while the directory `testsuite/config' contains
-configuration-specific files, typically used for special-purpose
-definitions of procs like `gdb_load' and `gdb_start'.
-
- The tests themselves are to be found in `testsuite/gdb.*' and
-subdirectories of those. The names of the test files must always end
-with `.exp'. DejaGNU collects the test files by wildcarding in the
-test directories, so both subdirectories and individual files get
-chosen and run in alphabetical order.
-
- The following table lists the main types of subdirectories and what
-they are for. Since DejaGNU finds test files no matter where they are
-located, and since each test file sets up its own compilation and
-execution environment, this organization is simply for convenience and
-intelligibility.
-
-`gdb.base'
- This is the base testsuite. The tests in it should apply to all
- configurations of GDB (but generic native-only tests may live
- here). The test programs should be in the subset of C that is
- valid K&R, ANSI/ISO, and C++ (`#ifdef's are allowed if necessary,
- for instance for prototypes).
-
-`gdb.LANG'
- Language-specific tests for any language LANG besides C. Examples
- are `gdb.cp' and `gdb.java'.
-
-`gdb.PLATFORM'
- Non-portable tests. The tests are specific to a specific
- configuration (host or target), such as HP-UX or eCos. Example is
- `gdb.hp', for HP-UX.
-
-`gdb.COMPILER'
- Tests specific to a particular compiler. As of this writing (June
- 1999), there aren't currently any groups of tests in this category
- that couldn't just as sensibly be made platform-specific, but one
- could imagine a `gdb.gcc', for tests of GDB's handling of GCC
- extensions.
-
-`gdb.SUBSYSTEM'
- Tests that exercise a specific GDB subsystem in more depth. For
- instance, `gdb.disasm' exercises various disassemblers, while
- `gdb.stabs' tests pathways through the stabs symbol reader.
-
-22.5 Writing Tests
-==================
-
-In many areas, the GDB tests are already quite comprehensive; you
-should be able to copy existing tests to handle new cases.
-
- You should try to use `gdb_test' whenever possible, since it
-includes cases to handle all the unexpected errors that might happen.
-However, it doesn't cost anything to add new test procedures; for
-instance, `gdb.base/exprs.exp' defines a `test_expr' that calls
-`gdb_test' multiple times.
-
- Only use `send_gdb' and `gdb_expect' when absolutely necessary.
-Even if GDB has several valid responses to a command, you can use
-`gdb_test_multiple'. Like `gdb_test', `gdb_test_multiple' recognizes
-internal errors and unexpected prompts.
-
- Do not write tests which expect a literal tab character from GDB.
-On some operating systems (e.g. OpenBSD) the TTY layer expands tabs to
-spaces, so by the time GDB's output reaches expect the tab is gone.
-
- The source language programs do _not_ need to be in a consistent
-style. Since GDB is used to debug programs written in many different
-styles, it's worth having a mix of styles in the testsuite; for
-instance, some GDB bugs involving the display of source lines would
-never manifest themselves if the programs used GNU coding style
-uniformly.
-
- ---------- Footnotes ----------
-
- (1) If you are using a board file, it could override the test-suite
-default; search the board file for "timeout".
-
-
-File: gdbint.info, Node: Hints, Next: GDB Observers, Prev: Testsuite, Up: Top
-
-23 Hints
-********
-
-Check the `README' file, it often has useful information that does not
-appear anywhere else in the directory.
-
-* Menu:
-
-* Getting Started:: Getting started working on GDB
-* Debugging GDB:: Debugging GDB with itself
-
-
-File: gdbint.info, Node: Getting Started, Next: Debugging GDB, Up: Hints
-
-23.1 Getting Started
-====================
-
-GDB is a large and complicated program, and if you first starting to
-work on it, it can be hard to know where to start. Fortunately, if you
-know how to go about it, there are ways to figure out what is going on.
-
- This manual, the GDB Internals manual, has information which applies
-generally to many parts of GDB.
-
- Information about particular functions or data structures are
-located in comments with those functions or data structures. If you
-run across a function or a global variable which does not have a
-comment correctly explaining what is does, this can be thought of as a
-bug in GDB; feel free to submit a bug report, with a suggested comment
-if you can figure out what the comment should say. If you find a
-comment which is actually wrong, be especially sure to report that.
-
- Comments explaining the function of macros defined in host, target,
-or native dependent files can be in several places. Sometimes they are
-repeated every place the macro is defined. Sometimes they are where the
-macro is used. Sometimes there is a header file which supplies a
-default definition of the macro, and the comment is there. This manual
-also documents all the available macros.
-
- Start with the header files. Once you have some idea of how GDB's
-internal symbol tables are stored (see `symtab.h', `gdbtypes.h'), you
-will find it much easier to understand the code which uses and creates
-those symbol tables.
-
- You may wish to process the information you are getting somehow, to
-enhance your understanding of it. Summarize it, translate it to another
-language, add some (perhaps trivial or non-useful) feature to GDB, use
-the code to predict what a test case would do and write the test case
-and verify your prediction, etc. If you are reading code and your eyes
-are starting to glaze over, this is a sign you need to use a more active
-approach.
-
- Once you have a part of GDB to start with, you can find more
-specifically the part you are looking for by stepping through each
-function with the `next' command. Do not use `step' or you will
-quickly get distracted; when the function you are stepping through
-calls another function try only to get a big-picture understanding
-(perhaps using the comment at the beginning of the function being
-called) of what it does. This way you can identify which of the
-functions being called by the function you are stepping through is the
-one which you are interested in. You may need to examine the data
-structures generated at each stage, with reference to the comments in
-the header files explaining what the data structures are supposed to
-look like.
-
- Of course, this same technique can be used if you are just reading
-the code, rather than actually stepping through it. The same general
-principle applies--when the code you are looking at calls something
-else, just try to understand generally what the code being called does,
-rather than worrying about all its details.
-
- A good place to start when tracking down some particular area is with
-a command which invokes that feature. Suppose you want to know how
-single-stepping works. As a GDB user, you know that the `step' command
-invokes single-stepping. The command is invoked via command tables
-(see `command.h'); by convention the function which actually performs
-the command is formed by taking the name of the command and adding
-`_command', or in the case of an `info' subcommand, `_info'. For
-example, the `step' command invokes the `step_command' function and the
-`info display' command invokes `display_info'. When this convention is
-not followed, you might have to use `grep' or `M-x tags-search' in
-emacs, or run GDB on itself and set a breakpoint in `execute_command'.
-
- If all of the above fail, it may be appropriate to ask for
-information on `bug-gdb'. But _never_ post a generic question like "I
-was wondering if anyone could give me some tips about understanding
-GDB"--if we had some magic secret we would put it in this manual.
-Suggestions for improving the manual are always welcome, of course.
-
-
-File: gdbint.info, Node: Debugging GDB, Prev: Getting Started, Up: Hints
-
-23.2 Debugging GDB with itself
-==============================
-
-If GDB is limping on your machine, this is the preferred way to get it
-fully functional. Be warned that in some ancient Unix systems, like
-Ultrix 4.2, a program can't be running in one process while it is being
-debugged in another. Rather than typing the command `./gdb ./gdb',
-which works on Suns and such, you can copy `gdb' to `gdb2' and then
-type `./gdb ./gdb2'.
-
- When you run GDB in the GDB source directory, it will read a
-`.gdbinit' file that sets up some simple things to make debugging gdb
-easier. The `info' command, when executed without a subcommand in a
-GDB being debugged by gdb, will pop you back up to the top level gdb.
-See `.gdbinit' for details.
-
- If you use emacs, you will probably want to do a `make TAGS' after
-you configure your distribution; this will put the machine dependent
-routines for your local machine where they will be accessed first by
-`M-.'
-
- Also, make sure that you've either compiled GDB with your local cc,
-or have run `fixincludes' if you are compiling with gcc.
-
-23.3 Submitting Patches
-=======================
-
-Thanks for thinking of offering your changes back to the community of
-GDB users. In general we like to get well designed enhancements.
-Thanks also for checking in advance about the best way to transfer the
-changes.
-
- The GDB maintainers will only install "cleanly designed" patches.
-This manual summarizes what we believe to be clean design for GDB.
-
- If the maintainers don't have time to put the patch in when it
-arrives, or if there is any question about a patch, it goes into a
-large queue with everyone else's patches and bug reports.
-
- The legal issue is that to incorporate substantial changes requires a
-copyright assignment from you and/or your employer, granting ownership
-of the changes to the Free Software Foundation. You can get the
-standard documents for doing this by sending mail to `gnu@gnu.org' and
-asking for it. We recommend that people write in "All programs owned
-by the Free Software Foundation" as "NAME OF PROGRAM", so that changes
-in many programs (not just GDB, but GAS, Emacs, GCC, etc) can be
-contributed with only one piece of legalese pushed through the
-bureaucracy and filed with the FSF. We can't start merging changes
-until this paperwork is received by the FSF (their rules, which we
-follow since we maintain it for them).
-
- Technically, the easiest way to receive changes is to receive each
-feature as a small context diff or unidiff, suitable for `patch'. Each
-message sent to me should include the changes to C code and header
-files for a single feature, plus `ChangeLog' entries for each directory
-where files were modified, and diffs for any changes needed to the
-manuals (`gdb/doc/gdb.texinfo' or `gdb/doc/gdbint.texinfo'). If there
-are a lot of changes for a single feature, they can be split down into
-multiple messages.
-
- In this way, if we read and like the feature, we can add it to the
-sources with a single patch command, do some testing, and check it in.
-If you leave out the `ChangeLog', we have to write one. If you leave
-out the doc, we have to puzzle out what needs documenting. Etc., etc.
-
- The reason to send each change in a separate message is that we will
-not install some of the changes. They'll be returned to you with
-questions or comments. If we're doing our job correctly, the message
-back to you will say what you have to fix in order to make the change
-acceptable. The reason to have separate messages for separate features
-is so that the acceptable changes can be installed while one or more
-changes are being reworked. If multiple features are sent in a single
-message, we tend to not put in the effort to sort out the acceptable
-changes from the unacceptable, so none of the features get installed
-until all are acceptable.
-
- If this sounds painful or authoritarian, well, it is. But we get a
-lot of bug reports and a lot of patches, and many of them don't get
-installed because we don't have the time to finish the job that the bug
-reporter or the contributor could have done. Patches that arrive
-complete, working, and well designed, tend to get installed on the day
-they arrive. The others go into a queue and get installed as time
-permits, which, since the maintainers have many demands to meet, may not
-be for quite some time.
-
- Please send patches directly to the GDB maintainers
-<gdb-patches@sourceware.org>.
-
-23.4 Build Script
-=================
-
-The script `gdb_buildall.sh' builds GDB with flag
-`--enable-targets=all' set. This builds GDB with all supported targets
-activated. This helps testing GDB when doing changes that affect more
-than one architecture and is much faster than using `gdb_mbuild.sh'.
-
- After building GDB the script checks which architectures are
-supported and then switches the current architecture to each of those
-to get information about the architecture. The test results are stored
-in log files in the directory the script was called from.
-
-
-File: gdbint.info, Node: GDB Observers, Next: GNU Free Documentation License, Prev: Hints, Up: Top
-
-Appendix A GDB Currently available observers
-********************************************
-
-A.1 Implementation rationale
-============================
-
-An "observer" is an entity which is interested in being notified when
-GDB reaches certain states, or certain events occur in GDB. The entity
-being observed is called the "subject". To receive notifications, the
-observer attaches a callback to the subject. One subject can have
-several observers.
-
- `observer.c' implements an internal generic low-level event
-notification mechanism. This generic event notification mechanism is
-then re-used to implement the exported high-level notification
-management routines for all possible notifications.
-
- The current implementation of the generic observer provides support
-for contextual data. This contextual data is given to the subject when
-attaching the callback. In return, the subject will provide this
-contextual data back to the observer as a parameter of the callback.
-
- Note that the current support for the contextual data is only
-partial, as it lacks a mechanism that would deallocate this data when
-the callback is detached. This is not a problem so far, as this
-contextual data is only used internally to hold a function pointer.
-Later on, if a certain observer needs to provide support for user-level
-contextual data, then the generic notification mechanism will need to be
-enhanced to allow the observer to provide a routine to deallocate the
-data when attaching the callback.
-
- The observer implementation is also currently not reentrant. In
-particular, it is therefore not possible to call the attach or detach
-routines during a notification.
-
-A.2 Debugging
-=============
-
-Observer notifications can be traced using the command `set debug
-observer 1' (*note Optional messages about internal happenings:
-(gdb)Debugging Output.).
-
-A.3 `normal_stop' Notifications
-===============================
-
-GDB notifies all `normal_stop' observers when the inferior execution
-has just stopped, the associated messages and annotations have been
-printed, and the control is about to be returned to the user.
-
- Note that the `normal_stop' notification is not emitted when the
-execution stops due to a breakpoint, and this breakpoint has a
-condition that is not met. If the breakpoint has any associated
-commands list, the commands are executed after the notification is
-emitted.
-
- The following interfaces are available to manage observers:
-
- -- Function: extern struct observer *observer_attach_EVENT
- (observer_EVENT_ftype *F)
- Using the function F, create an observer that is notified when
- ever EVENT occurs, return the observer.
-
- -- Function: extern void observer_detach_EVENT (struct observer
- *OBSERVER);
- Remove OBSERVER from the list of observers to be notified when
- EVENT occurs.
-
- -- Function: extern void observer_notify_EVENT (void);
- Send a notification to all EVENT observers.
-
- The following observable events are defined:
-
- -- Function: void normal_stop (struct bpstats *BS, int PRINT_FRAME)
- The inferior has stopped for real. The BS argument describes the
- breakpoints were are stopped at, if any. Second argument
- PRINT_FRAME non-zero means display the location where the inferior
- has stopped.
-
- -- Function: void target_changed (struct target_ops *TARGET)
- The target's register contents have changed.
-
- -- Function: void executable_changed (void)
- The executable being debugged by GDB has changed: The user decided
- to debug a different program, or the program he was debugging has
- been modified since being loaded by the debugger (by being
- recompiled, for instance).
-
- -- Function: void inferior_created (struct target_ops *OBJFILE, int
- FROM_TTY)
- GDB has just connected to an inferior. For `run', GDB calls this
- observer while the inferior is still stopped at the entry-point
- instruction. For `attach' and `core', GDB calls this observer
- immediately after connecting to the inferior, and before any
- information on the inferior has been printed.
-
- -- Function: void solib_loaded (struct so_list *SOLIB)
- The shared library specified by SOLIB has been loaded. Note that
- when GDB calls this observer, the library's symbols probably
- haven't been loaded yet.
-
- -- Function: void solib_unloaded (struct so_list *SOLIB)
- The shared library specified by SOLIB has been unloaded. Note
- that when GDB calls this observer, the library's symbols have not
- been unloaded yet, and thus are still available.
-
- -- Function: void new_objfile (struct objfile *OBJFILE)
- The symbol file specified by OBJFILE has been loaded. Called with
- OBJFILE equal to `NULL' to indicate previously loaded symbol table
- data has now been invalidated.
-
- -- Function: void new_thread (struct thread_info *T)
- The thread specified by T has been created.
-
- -- Function: void thread_exit (struct thread_info *T, int SILENT)
- The thread specified by T has exited. The SILENT argument
- indicates that GDB is removing the thread from its tables without
- wanting to notify the user about it.
-
- -- Function: void thread_stop_requested (ptid_t PTID)
- An explicit stop request was issued to PTID. If PTID equals
- MINUS_ONE_PTID, the request applied to all threads. If
- `ptid_is_pid(ptid)' returns true, the request applied to all
- threads of the process pointed at by PTID. Otherwise, the request
- applied to the single thread pointed at by PTID.
-
- -- Function: void target_resumed (ptid_t PTID)
- The target was resumed. The PTID parameter specifies which thread
- was resume, and may be RESUME_ALL if all threads are resumed.
-
- -- Function: void about_to_proceed (void)
- The target is about to be proceeded.
-
- -- Function: void breakpoint_created (int BPNUM)
- A new breakpoint has been created. The argument BPNUM is the
- number of the newly-created breakpoint.
-
- -- Function: void breakpoint_deleted (int BPNUM)
- A breakpoint has been destroyed. The argument BPNUM is the number
- of the newly-destroyed breakpoint.
-
- -- Function: void breakpoint_modified (int BPNUM)
- A breakpoint has been modified in some way. The argument BPNUM is
- the number of the modified breakpoint.
-
- -- Function: void tracepoint_created (int TPNUM)
- A new tracepoint has been created. The argument TPNUM is the
- number of the newly-created tracepoint.
-
- -- Function: void tracepoint_deleted (int TPNUM)
- A tracepoint has been destroyed. The argument TPNUM is the number
- of the newly-destroyed tracepoint.
-
- -- Function: void tracepoint_modified (int TPNUM)
- A tracepoint has been modified in some way. The argument TPNUM is
- the number of the modified tracepoint.
-
- -- Function: void architecture_changed (struct gdbarch *NEWARCH)
- The current architecture has changed. The argument NEWARCH is a
- pointer to the new architecture.
-
- -- Function: void thread_ptid_changed (ptid_t OLD_PTID, ptid_t
- NEW_PTID)
- The thread's ptid has changed. The OLD_PTID parameter specifies
- the old value, and NEW_PTID specifies the new value.
-
- -- Function: void inferior_added (struct inferior *INF)
- The inferior INF has been added to the list of inferiors. At this
- point, it might not be associated with any process.
-
- -- Function: void inferior_appeared (struct inferior *INF)
- The inferior identified by INF has been attached to a process.
-
- -- Function: void inferior_exit (struct inferior *INF)
- Either the inferior associated with INF has been detached from the
- process, or the process has exited.
-
- -- Function: void inferior_removed (struct inferior *INF)
- The inferior INF has been removed from the list of inferiors.
- This method is called immediately before freeing INF.
-
- -- Function: void memory_changed (CORE_ADDR ADDR, int LEN, const
- bfd_byte *DATA)
- Bytes from DATA to DATA + LEN have been written to the current
- inferior at ADDR.
-
- -- Function: void test_notification (int SOMEARG)
- This observer is used for internal testing. Do not use. See
- testsuite/gdb.gdb/observer.exp.
-
-
-File: gdbint.info, Node: GNU Free Documentation License, Next: Index, Prev: GDB Observers, Up: Top
-
-Appendix B GNU Free Documentation License
-*****************************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: gdbint.info, Node: Index, Prev: GNU Free Documentation License, Up: Top
-
-Index
-*****
-
-
-* Menu:
-
-* $fp: Register Information Functions.
- (line 126)
-* $pc: Register Architecture Functions & Variables.
- (line 58)
-* $ps: Register Architecture Functions & Variables.
- (line 69)
-* $sp: Register Architecture Functions & Variables.
- (line 49)
-* _initialize_ARCH_tdep <1>: How an Architecture is Represented.
- (line 13)
-* _initialize_ARCH_tdep: Adding a New Target. (line 22)
-* _initialize_language: Language Support. (line 79)
-* a.out format: Symbol Handling. (line 218)
-* about_to_proceed: GDB Observers. (line 133)
-* abstract interpretation of function prologues: Algorithms. (line 48)
-* add_cmd: User Interface. (line 21)
-* add_com: User Interface. (line 21)
-* add_setshow_cmd: User Interface. (line 26)
-* add_setshow_cmd_full: User Interface. (line 26)
-* add_symtab_fns: Symbol Handling. (line 37)
-* adding a new host: Host Definition. (line 13)
-* adding a symbol-reading module: Symbol Handling. (line 37)
-* adding a target: Adding a New Target. (line 6)
-* adding debugging info reader: Symbol Handling. (line 365)
-* adding source language: Language Support. (line 17)
-* address classes: Address Classes. (line 6)
-* address representation: Pointers and Addresses.
- (line 6)
-* address spaces, separate data and code: Pointers and Addresses.
- (line 6)
-* address_class_name_to_type_flags: Defining Other Architecture Features.
- (line 28)
-* address_class_name_to_type_flags_p: Defining Other Architecture Features.
- (line 39)
-* algorithms: Algorithms. (line 6)
-* align_down: Functions and Variable to Analyze Frames.
- (line 46)
-* align_up: Functions and Variable to Analyze Frames.
- (line 46)
-* allocate_symtab: Language Support. (line 83)
-* ARCH-tdep.c: How an Architecture is Represented.
- (line 13)
-* architecture representation: How an Architecture is Represented.
- (line 6)
-* architecture_changed: GDB Observers. (line 160)
-* Array Containers: Support Libraries. (line 131)
-* assumptions about targets: Misc Guidelines. (line 334)
-* base of a frame: Frame Handling Terminology.
- (line 28)
-* BFD library: Support Libraries. (line 9)
-* bfd_arch_info: Looking Up an Existing Architecture.
- (line 41)
-* BIG_BREAKPOINT: Defining Other Architecture Features.
- (line 100)
-* BPT_VECTOR: Defining Other Architecture Features.
- (line 536)
-* BREAKPOINT: Defining Other Architecture Features.
- (line 88)
-* breakpoint address adjusted: Defining Other Architecture Features.
- (line 145)
-* breakpoint_created: GDB Observers. (line 136)
-* breakpoint_deleted: GDB Observers. (line 140)
-* breakpoint_modified: GDB Observers. (line 144)
-* breakpoints: Algorithms. (line 151)
-* bug-gdb mailing list: Getting Started. (line 72)
-* build script: Debugging GDB. (line 94)
-* C data types: Coding Standards. (line 105)
-* call frame information: Algorithms. (line 14)
-* call stack frame: Stack Frames. (line 6)
-* calls to the inferior: Inferior Call Setup. (line 6)
-* CC_HAS_LONG_LONG: Host Definition. (line 105)
-* CFI (call frame information): Algorithms. (line 14)
-* checkpoints: Algorithms. (line 600)
-* cleanups: Misc Guidelines. (line 12)
-* CLI: User Interface. (line 12)
-* code pointers, word-addressed: Pointers and Addresses.
- (line 6)
-* coding standards: Coding Standards. (line 6)
-* COFF debugging info: Symbol Handling. (line 315)
-* COFF format: Symbol Handling. (line 233)
-* command implementation: Getting Started. (line 60)
-* command interpreter: User Interface. (line 12)
-* comment formatting: Coding Standards. (line 79)
-* compiler warnings: Misc Guidelines. (line 252)
-* Compressed DWARF 2 debugging info: Symbol Handling. (line 335)
-* computed values: Values. (line 35)
-* configure.tgt: How an Architecture is Represented.
- (line 19)
-* converting between pointers and addresses: Pointers and Addresses.
- (line 6)
-* converting integers to addresses: Defining Other Architecture Features.
- (line 274)
-* cooked register representation: Raw and Cooked Registers.
- (line 6)
-* core files: Adding support for debugging core files.
- (line 6)
-* core_addr_greaterthan: Functions and Variable to Analyze Frames.
- (line 30)
-* core_addr_lessthan: Functions and Variable to Analyze Frames.
- (line 30)
-* CRLF_SOURCE_FILES: Host Definition. (line 86)
-* current_language: Language Support. (line 75)
-* D10V addresses: Pointers and Addresses.
- (line 6)
-* data output: User Interface. (line 254)
-* data-pointer, per-architecture/per-module: Misc Guidelines. (line 100)
-* debugging GDB: Debugging GDB. (line 6)
-* DEFAULT_PROMPT: Host Definition. (line 93)
-* deprecate_cmd: User Interface. (line 32)
-* DEPRECATED_IBM6000_TARGET: Defining Other Architecture Features.
- (line 242)
-* deprecating commands: User Interface. (line 32)
-* design: Misc Guidelines. (line 329)
-* DEV_TTY: Host Definition. (line 96)
-* DIRNAME_SEPARATOR: Misc Guidelines. (line 399)
-* DISABLE_UNSETTABLE_BREAK: Defining Other Architecture Features.
- (line 211)
-* discard_cleanups: Misc Guidelines. (line 39)
-* do_cleanups: Misc Guidelines. (line 35)
-* DOS text files: Host Definition. (line 87)
-* dummy frames: About Dummy Frames. (line 6)
-* DW_AT_address_class: Address Classes. (line 6)
-* DW_AT_byte_size: Address Classes. (line 6)
-* DWARF 2 debugging info: Symbol Handling. (line 328)
-* DWARF 3 debugging info: Symbol Handling. (line 355)
-* ECOFF debugging info: Symbol Handling. (line 321)
-* ECOFF format: Symbol Handling. (line 248)
-* ELF format: Symbol Handling. (line 281)
-* evaluate_subexp: Language Support. (line 58)
-* executable_changed: GDB Observers. (line 85)
-* execution state: Managing Execution State.
- (line 6)
-* experimental branches: Versions and Branches.
- (line 116)
-* expression evaluation routines: Language Support. (line 58)
-* expression parser: Language Support. (line 21)
-* extract_typed_address: Pointers and Addresses.
- (line 52)
-* field output functions: User Interface. (line 254)
-* file names, portability: Misc Guidelines. (line 367)
-* FILENAME_CMP: Misc Guidelines. (line 393)
-* find_pc_function: Symbol Handling. (line 136)
-* find_pc_line: Symbol Handling. (line 136)
-* find_sym_fns: Symbol Handling. (line 32)
-* finding a symbol: Symbol Handling. (line 133)
-* fine-tuning gdbarch structure: OS ABI Variant Handling.
- (line 23)
-* first floating point register: Register Architecture Functions & Variables.
- (line 78)
-* FOPEN_RB: Host Definition. (line 102)
-* fp0_regnum: Register Architecture Functions & Variables.
- (line 78)
-* frame: Stack Frames. (line 6)
-* frame ID: Stack Frames. (line 41)
-* frame pointer: Register Information Functions.
- (line 126)
-* frame, definition of base of a frame: Frame Handling Terminology.
- (line 28)
-* frame, definition of innermost frame: Frame Handling Terminology.
- (line 24)
-* frame, definition of NEXT frame: Frame Handling Terminology.
- (line 11)
-* frame, definition of PREVIOUS frame: Frame Handling Terminology.
- (line 14)
-* frame, definition of sentinel frame: Frame Handling Terminology.
- (line 52)
-* frame, definition of sniffing: Frame Handling Terminology.
- (line 46)
-* frame, definition of THIS frame: Frame Handling Terminology.
- (line 9)
-* frame, definition of unwinding: Frame Handling Terminology.
- (line 41)
-* frame_align: Functions and Variable to Analyze Frames.
- (line 46)
-* frame_base: Analyzing Stacks---Frame Sniffers.
- (line 89)
-* frame_base_append_sniffer: Analyzing Stacks---Frame Sniffers.
- (line 19)
-* frame_base_set_default: Analyzing Stacks---Frame Sniffers.
- (line 22)
-* frame_num_args: Functions to Access Frame Data.
- (line 43)
-* frame_red_zone_size: Functions and Variable to Analyze Frames.
- (line 63)
-* frame_register_unwind: Stack Frames. (line 15)
-* frame_unwind: Analyzing Stacks---Frame Sniffers.
- (line 36)
-* frame_unwind_append_sniffer: Analyzing Stacks---Frame Sniffers.
- (line 16)
-* frame_unwind_append_unwinder: Stack Frames. (line 30)
-* frame_unwind_got_address: Stack Frames. (line 105)
-* frame_unwind_got_constant: Stack Frames. (line 101)
-* frame_unwind_got_memory: Stack Frames. (line 98)
-* frame_unwind_got_optimized: Stack Frames. (line 90)
-* frame_unwind_got_register: Stack Frames. (line 93)
-* frame_unwind_prepend_unwinder: Stack Frames. (line 30)
-* full symbol table: Symbol Handling. (line 104)
-* function prologue: Prologue Caches. (line 6)
-* function prototypes: Coding Standards. (line 127)
-* function usage: Coding Standards. (line 109)
-* fundamental types: Symbol Handling. (line 183)
-* GCC2_COMPILED_FLAG_SYMBOL: Defining Other Architecture Features.
- (line 225)
-* GCC_COMPILED_FLAG_SYMBOL: Defining Other Architecture Features.
- (line 225)
-* GDB source tree structure: Overall Structure. (line 83)
-* gdb_byte: Register Caching. (line 23)
-* GDB_OSABI_AIX: OS ABI Variant Handling.
- (line 90)
-* GDB_OSABI_CYGWIN: OS ABI Variant Handling.
- (line 87)
-* GDB_OSABI_FREEBSD_AOUT: OS ABI Variant Handling.
- (line 51)
-* GDB_OSABI_FREEBSD_ELF: OS ABI Variant Handling.
- (line 54)
-* GDB_OSABI_GO32: OS ABI Variant Handling.
- (line 69)
-* GDB_OSABI_HPUX_ELF: OS ABI Variant Handling.
- (line 78)
-* GDB_OSABI_HPUX_SOM: OS ABI Variant Handling.
- (line 81)
-* GDB_OSABI_HURD: OS ABI Variant Handling.
- (line 39)
-* GDB_OSABI_INTERIX: OS ABI Variant Handling.
- (line 75)
-* GDB_OSABI_IRIX: OS ABI Variant Handling.
- (line 72)
-* GDB_OSABI_LINUX: OS ABI Variant Handling.
- (line 48)
-* GDB_OSABI_NETBSD_AOUT: OS ABI Variant Handling.
- (line 57)
-* GDB_OSABI_NETBSD_ELF: OS ABI Variant Handling.
- (line 60)
-* GDB_OSABI_OPENBSD_ELF: OS ABI Variant Handling.
- (line 63)
-* GDB_OSABI_OSF1: OS ABI Variant Handling.
- (line 45)
-* GDB_OSABI_QNXNTO: OS ABI Variant Handling.
- (line 84)
-* GDB_OSABI_SOLARIS: OS ABI Variant Handling.
- (line 42)
-* GDB_OSABI_SVR4: OS ABI Variant Handling.
- (line 36)
-* GDB_OSABI_UNINITIALIZED: OS ABI Variant Handling.
- (line 29)
-* GDB_OSABI_UNKNOWN: OS ABI Variant Handling.
- (line 32)
-* GDB_OSABI_WINCE: OS ABI Variant Handling.
- (line 66)
-* gdbarch: How an Architecture is Represented.
- (line 19)
-* gdbarch accessor functions: Creating a New Architecture.
- (line 14)
-* gdbarch lookup: Looking Up an Existing Architecture.
- (line 6)
-* gdbarch register architecture functions: Register Architecture Functions & Variables.
- (line 6)
-* gdbarch register information functions: Register Information Functions.
- (line 6)
-* gdbarch_addr_bits_remove: Defining Other Architecture Features.
- (line 11)
-* gdbarch_address_class_name_to_type_flags: Address Classes. (line 30)
-* gdbarch_address_class_type_flags <1>: Defining Other Architecture Features.
- (line 43)
-* gdbarch_address_class_type_flags: Address Classes. (line 18)
-* gdbarch_address_class_type_flags_p: Defining Other Architecture Features.
- (line 52)
-* gdbarch_address_class_type_flags_to_name <1>: Defining Other Architecture Features.
- (line 56)
-* gdbarch_address_class_type_flags_to_name: Address Classes. (line 25)
-* gdbarch_address_class_type_flags_to_name_p: Defining Other Architecture Features.
- (line 60)
-* gdbarch_address_to_pointer <1>: Pointers and Addresses.
- (line 114)
-* gdbarch_address_to_pointer: Defining Other Architecture Features.
- (line 65)
-* gdbarch_adjust_breakpoint_address: Defining Other Architecture Features.
- (line 145)
-* gdbarch_alloc: Creating a New Architecture.
- (line 6)
-* gdbarch_believe_pcc_promotion: Defining Other Architecture Features.
- (line 72)
-* gdbarch_bits_big_endian: Defining Other Architecture Features.
- (line 77)
-* gdbarch_breakpoint_from_pc: Defining Other Architecture Features.
- (line 106)
-* gdbarch_call_dummy_location: Defining Other Architecture Features.
- (line 178)
-* gdbarch_cannot_fetch_register: Defining Other Architecture Features.
- (line 184)
-* gdbarch_cannot_store_register: Defining Other Architecture Features.
- (line 188)
-* gdbarch_char_signed: Defining Other Architecture Features.
- (line 461)
-* gdbarch_convert_register_p <1>: Register and Memory Data.
- (line 30)
-* gdbarch_convert_register_p: Defining Other Architecture Features.
- (line 195)
-* gdbarch_data: Misc Guidelines. (line 133)
-* gdbarch_data_register_post_init: Misc Guidelines. (line 118)
-* gdbarch_data_register_pre_init: Misc Guidelines. (line 108)
-* gdbarch_decr_pc_after_break: Defining Other Architecture Features.
- (line 205)
-* gdbarch_deprecated_fp_regnum: Defining Other Architecture Features.
- (line 446)
-* gdbarch_double_bit: Defining Other Architecture Features.
- (line 471)
-* gdbarch_dummy_id: Defining Other Architecture Features.
- (line 523)
-* gdbarch_dwarf2_reg_to_regnum: Defining Other Architecture Features.
- (line 216)
-* gdbarch_ecoff_reg_to_regnum: Defining Other Architecture Features.
- (line 220)
-* gdbarch_float_bit: Defining Other Architecture Features.
- (line 475)
-* gdbarch_fp0_regnum: Defining Other Architecture Features.
- (line 200)
-* gdbarch_get_longjmp_target <1>: Defining Other Architecture Features.
- (line 231)
-* gdbarch_get_longjmp_target: Algorithms. (line 263)
-* gdbarch_have_nonsteppable_watchpoint: Algorithms. (line 396)
-* gdbarch_in_function_epilogue_p: Defining Other Architecture Features.
- (line 253)
-* gdbarch_in_solib_return_trampoline: Defining Other Architecture Features.
- (line 259)
-* gdbarch_info: Looking Up an Existing Architecture.
- (line 22)
-* gdbarch_init_osabi: OS ABI Variant Handling.
- (line 125)
-* gdbarch_int_bit: Defining Other Architecture Features.
- (line 478)
-* gdbarch_integer_to_address: Defining Other Architecture Features.
- (line 274)
-* gdbarch_list_lookup_by_info: Looking Up an Existing Architecture.
- (line 22)
-* gdbarch_long_bit: Defining Other Architecture Features.
- (line 481)
-* gdbarch_long_double_bit: Defining Other Architecture Features.
- (line 485)
-* gdbarch_long_long_bit: Defining Other Architecture Features.
- (line 489)
-* gdbarch_lookup_osabi: OS ABI Variant Handling.
- (line 119)
-* gdbarch_memory_insert_breakpoint: Defining Other Architecture Features.
- (line 130)
-* gdbarch_memory_remove_breakpoint: Defining Other Architecture Features.
- (line 130)
-* gdbarch_osabi_name: OS ABI Variant Handling.
- (line 97)
-* gdbarch_pointer_to_address <1>: Pointers and Addresses.
- (line 105)
-* gdbarch_pointer_to_address: Defining Other Architecture Features.
- (line 295)
-* gdbarch_print_insn: Defining Other Architecture Features.
- (line 513)
-* gdbarch_ptr_bit: Defining Other Architecture Features.
- (line 493)
-* gdbarch_push_dummy_call: Defining Other Architecture Features.
- (line 363)
-* gdbarch_push_dummy_code: Defining Other Architecture Features.
- (line 375)
-* gdbarch_register <1>: Adding a New Target. (line 40)
-* gdbarch_register: How an Architecture is Represented.
- (line 19)
-* gdbarch_register_osabi: OS ABI Variant Handling.
- (line 103)
-* gdbarch_register_osabi_sniffer: OS ABI Variant Handling.
- (line 112)
-* gdbarch_register_to_value <1>: Register and Memory Data.
- (line 46)
-* gdbarch_register_to_value: Defining Other Architecture Features.
- (line 301)
-* gdbarch_return_value: Defining Other Architecture Features.
- (line 394)
-* gdbarch_sdb_reg_to_regnum: Defining Other Architecture Features.
- (line 390)
-* gdbarch_short_bit: Defining Other Architecture Features.
- (line 497)
-* gdbarch_skip_permanent_breakpoint: Defining Other Architecture Features.
- (line 430)
-* gdbarch_skip_trampoline_code: Defining Other Architecture Features.
- (line 441)
-* gdbarch_stab_reg_to_regnum: Defining Other Architecture Features.
- (line 450)
-* gdbarch_stabs_argument_has_addr: Defining Other Architecture Features.
- (line 359)
-* gdbarch_tdep definition: Creating a New Architecture.
- (line 34)
-* gdbarch_tdep when allocating new gdbarch: Creating a New Architecture.
- (line 6)
-* gdbarch_value_to_register <1>: Register and Memory Data.
- (line 62)
-* gdbarch_value_to_register: Defining Other Architecture Features.
- (line 529)
-* gdbarch_virtual_frame_pointer: Defining Other Architecture Features.
- (line 501)
-* GDBINIT_FILENAME: Host Definition. (line 74)
-* generic host support: Host Definition. (line 38)
-* generic_elf_osabi_sniff_abi_tag_sections: OS ABI Variant Handling.
- (line 133)
-* get_frame_register: Stack Frames. (line 15)
-* get_frame_type: Stack Frames. (line 22)
-* hardware breakpoints: Algorithms. (line 158)
-* hardware watchpoints: Algorithms. (line 280)
-* HAVE_CONTINUABLE_WATCHPOINT: Algorithms. (line 402)
-* HAVE_DOS_BASED_FILE_SYSTEM: Misc Guidelines. (line 376)
-* HAVE_STEPPABLE_WATCHPOINT: Algorithms. (line 386)
-* host: Overall Structure. (line 50)
-* host, adding: Host Definition. (line 13)
-* i386_cleanup_dregs: Algorithms. (line 576)
-* I386_DR_LOW_GET_STATUS: Algorithms. (line 489)
-* I386_DR_LOW_RESET_ADDR: Algorithms. (line 485)
-* I386_DR_LOW_SET_ADDR: Algorithms. (line 482)
-* I386_DR_LOW_SET_CONTROL: Algorithms. (line 479)
-* i386_insert_hw_breakpoint: Algorithms. (line 564)
-* i386_insert_watchpoint: Algorithms. (line 536)
-* i386_region_ok_for_watchpoint: Algorithms. (line 514)
-* i386_remove_hw_breakpoint: Algorithms. (line 564)
-* i386_remove_watchpoint: Algorithms. (line 536)
-* i386_stopped_by_watchpoint: Algorithms. (line 528)
-* i386_stopped_data_address: Algorithms. (line 521)
-* I386_USE_GENERIC_WATCHPOINTS: Algorithms. (line 461)
-* in_dynsym_resolve_code: Defining Other Architecture Features.
- (line 263)
-* inferior_added: GDB Observers. (line 169)
-* inferior_appeared: GDB Observers. (line 173)
-* inferior_created: GDB Observers. (line 92)
-* inferior_exit: GDB Observers. (line 176)
-* inferior_removed: GDB Observers. (line 180)
-* inner_than: Functions and Variable to Analyze Frames.
- (line 30)
-* innermost frame: Frame Handling Terminology.
- (line 24)
-* insert or remove hardware breakpoint: Algorithms. (line 234)
-* insert or remove hardware watchpoint: Algorithms. (line 347)
-* insert or remove software breakpoint: Algorithms. (line 211)
-* IS_ABSOLUTE_PATH: Misc Guidelines. (line 387)
-* IS_DIR_SEPARATOR: Misc Guidelines. (line 382)
-* ISATTY: Host Definition. (line 99)
-* item output functions: User Interface. (line 254)
-* language parser: Language Support. (line 25)
-* language support: Language Support. (line 6)
-* legal papers for code contributions: Debugging GDB. (line 42)
-* length_of_subexp: Language Support. (line 58)
-* libgdb: libgdb. (line 15)
-* libiberty library: Support Libraries. (line 52)
-* line wrap in output: Misc Guidelines. (line 191)
-* lint: Host Definition. (line 119)
-* list output functions: User Interface. (line 131)
-* LITTLE_BREAKPOINT: Defining Other Architecture Features.
- (line 100)
-* long long data type: Host Definition. (line 106)
-* longjmp debugging: Algorithms. (line 258)
-* lookup_symbol: Symbol Handling. (line 142)
-* LSEEK_NOT_LINEAR: Host Definition. (line 114)
-* lval_type enumeration, for values.: Values. (line 19)
-* make_cleanup: Misc Guidelines. (line 28)
-* make_cleanup_ui_out_list_begin_end: User Interface. (line 247)
-* make_cleanup_ui_out_tuple_begin_end: User Interface. (line 223)
-* making a new release of gdb: Releasing GDB. (line 6)
-* memory representation: Register and Memory Data.
- (line 6)
-* memory_changed: GDB Observers. (line 185)
-* minimal symbol table: Symbol Handling. (line 111)
-* minsymtabs: Symbol Handling. (line 111)
-* multi-arch data: Misc Guidelines. (line 100)
-* NATDEPFILES: Native Debugging. (line 8)
-* native conditionals: Native Debugging. (line 75)
-* native debugging: Native Debugging. (line 6)
-* nesting level in ui_out functions: User Interface. (line 143)
-* new year procedure: Start of New Year Procedure.
- (line 6)
-* new_objfile: GDB Observers. (line 109)
-* new_thread: GDB Observers. (line 114)
-* NEXT frame: Frame Handling Terminology.
- (line 11)
-* normal_stop: GDB Observers. (line 76)
-* normal_stop observer: GDB Observers. (line 48)
-* notification about inferior execution stop: GDB Observers. (line 48)
-* notifications about changes in internals: Algorithms. (line 630)
-* object file formats: Symbol Handling. (line 215)
-* observer pattern interface: Algorithms. (line 630)
-* observers implementation rationale: GDB Observers. (line 9)
-* obstacks: Support Libraries. (line 69)
-* op_print_tab: Language Support. (line 91)
-* opcodes library: Support Libraries. (line 39)
-* OS ABI variants: OS ABI Variant Handling.
- (line 6)
-* parse_exp_1: Language Support. (line 97)
-* partial symbol table: Symbol Handling. (line 114)
-* pc_regnum: Register Architecture Functions & Variables.
- (line 58)
-* PE-COFF format: Symbol Handling. (line 272)
-* per-architecture module data: Misc Guidelines. (line 100)
-* pointer representation: Pointers and Addresses.
- (line 6)
-* portability: Misc Guidelines. (line 350)
-* portable file name handling: Misc Guidelines. (line 367)
-* porting to new machines: Porting GDB. (line 6)
-* prefixify_subexp: Language Support. (line 58)
-* PREVIOUS frame: Frame Handling Terminology.
- (line 14)
-* print_float_info: Register Information Functions.
- (line 80)
-* print_registers_info: Register Information Functions.
- (line 53)
-* print_subexp: Language Support. (line 91)
-* print_vector_info: Register Information Functions.
- (line 96)
-* PRINTF_HAS_LONG_LONG: Host Definition. (line 109)
-* processor status register: Register Architecture Functions & Variables.
- (line 69)
-* program counter <1>: Register Architecture Functions & Variables.
- (line 58)
-* program counter: Algorithms. (line 158)
-* prologue analysis: Algorithms. (line 14)
-* prologue cache: Prologue Caches. (line 12)
-* prologue of a function: Prologue Caches. (line 6)
-* prologue-value.c: Algorithms. (line 48)
-* prompt: Host Definition. (line 94)
-* ps_regnum: Register Architecture Functions & Variables.
- (line 69)
-* pseudo-evaluation of function prologues: Algorithms. (line 48)
-* pseudo_register_read: Register Architecture Functions & Variables.
- (line 29)
-* pseudo_register_write: Register Architecture Functions & Variables.
- (line 33)
-* psymtabs: Symbol Handling. (line 107)
-* push_dummy_call: Functions Creating Dummy Frames.
- (line 13)
-* push_dummy_code: Functions Creating Dummy Frames.
- (line 57)
-* raw register representation: Raw and Cooked Registers.
- (line 6)
-* read_pc: Register Architecture Functions & Variables.
- (line 10)
-* reading of symbols: Symbol Handling. (line 25)
-* readline library: Support Libraries. (line 45)
-* regcache_cooked_read: Register Caching. (line 23)
-* regcache_cooked_read_signed: Register Caching. (line 23)
-* regcache_cooked_read_unsigned: Register Caching. (line 23)
-* regcache_cooked_write: Register Caching. (line 23)
-* regcache_cooked_write_signed: Register Caching. (line 23)
-* regcache_cooked_write_unsigned: Register Caching. (line 23)
-* register caching: Register Caching. (line 6)
-* register data formats, converting: Register and Memory Data.
- (line 6)
-* register representation: Register and Memory Data.
- (line 6)
-* REGISTER_CONVERT_TO_RAW: Defining Other Architecture Features.
- (line 311)
-* REGISTER_CONVERT_TO_VIRTUAL: Defining Other Architecture Features.
- (line 306)
-* register_name: Register Information Functions.
- (line 10)
-* register_reggroup_p: Register Information Functions.
- (line 110)
-* register_type: Register Information Functions.
- (line 33)
-* regset_from_core_section: Defining Other Architecture Features.
- (line 316)
-* regular expressions library: Support Libraries. (line 110)
-* Release Branches: Versions and Branches.
- (line 93)
-* remote debugging support: Host Definition. (line 41)
-* REMOTE_BPT_VECTOR: Defining Other Architecture Features.
- (line 540)
-* representation of architecture: How an Architecture is Represented.
- (line 6)
-* representations, raw and cooked registers: Raw and Cooked Registers.
- (line 6)
-* representations, register and memory: Register and Memory Data.
- (line 6)
-* requirements for GDB: Requirements. (line 6)
-* restart: Algorithms. (line 600)
-* running the test suite: Testsuite. (line 19)
-* secondary symbol file: Symbol Handling. (line 47)
-* sentinel frame <1>: Stack Frames. (line 22)
-* sentinel frame: Frame Handling Terminology.
- (line 52)
-* SENTINEL_FRAME: Stack Frames. (line 22)
-* separate data and code address spaces: Pointers and Addresses.
- (line 6)
-* serial line support: Host Definition. (line 41)
-* set_gdbarch functions: Creating a New Architecture.
- (line 14)
-* set_gdbarch_bits_big_endian: Defining Other Architecture Features.
- (line 83)
-* set_gdbarch_sofun_address_maybe_missing: Defining Other Architecture Features.
- (line 330)
-* SIGWINCH_HANDLER: Host Definition. (line 78)
-* SIGWINCH_HANDLER_BODY: Host Definition. (line 82)
-* skip_prologue: Functions and Variable to Analyze Frames.
- (line 12)
-* SKIP_SOLIB_RESOLVER: Defining Other Architecture Features.
- (line 267)
-* SLASH_STRING: Misc Guidelines. (line 404)
-* sniffing: Frame Handling Terminology.
- (line 46)
-* software breakpoints: Algorithms. (line 184)
-* software watchpoints: Algorithms. (line 280)
-* SOFTWARE_SINGLE_STEP: Defining Other Architecture Features.
- (line 324)
-* SOFTWARE_SINGLE_STEP_P: Defining Other Architecture Features.
- (line 320)
-* SOLIB_ADD: Native Debugging. (line 86)
-* SOLIB_CREATE_INFERIOR_HOOK: Native Debugging. (line 92)
-* solib_loaded: GDB Observers. (line 99)
-* solib_unloaded: GDB Observers. (line 104)
-* SOM debugging info: Symbol Handling. (line 360)
-* SOM format: Symbol Handling. (line 291)
-* source code formatting: Coding Standards. (line 28)
-* sp_regnum: Register Architecture Functions & Variables.
- (line 49)
-* spaces, separate data and code address: Pointers and Addresses.
- (line 6)
-* stabs debugging info: Symbol Handling. (line 305)
-* stack frame, definition of base of a frame: Frame Handling Terminology.
- (line 28)
-* stack frame, definition of innermost frame: Frame Handling Terminology.
- (line 24)
-* stack frame, definition of NEXT frame: Frame Handling Terminology.
- (line 11)
-* stack frame, definition of PREVIOUS frame: Frame Handling Terminology.
- (line 14)
-* stack frame, definition of sentinel frame: Frame Handling Terminology.
- (line 52)
-* stack frame, definition of sniffing: Frame Handling Terminology.
- (line 46)
-* stack frame, definition of THIS frame: Frame Handling Terminology.
- (line 9)
-* stack frame, definition of unwinding: Frame Handling Terminology.
- (line 41)
-* stack pointer: Register Architecture Functions & Variables.
- (line 49)
-* START_INFERIOR_TRAPS_EXPECTED: Native Debugging. (line 96)
-* status register: Register Architecture Functions & Variables.
- (line 69)
-* STOPPED_BY_WATCHPOINT: Algorithms. (line 408)
-* store_typed_address: Pointers and Addresses.
- (line 70)
-* struct: GDB Observers. (line 62)
-* struct gdbarch creation: Creating a New Architecture.
- (line 6)
-* struct regcache: Register Caching. (line 10)
-* struct value, converting register contents to: Register and Memory Data.
- (line 6)
-* submitting patches: Debugging GDB. (line 30)
-* sym_fns structure: Symbol Handling. (line 37)
-* symbol files: Symbol Handling. (line 25)
-* symbol lookup: Symbol Handling. (line 133)
-* symbol reading: Symbol Handling. (line 25)
-* SYMBOL_RELOADING_DEFAULT: Defining Other Architecture Features.
- (line 454)
-* symtabs: Symbol Handling. (line 104)
-* system dependencies: Misc Guidelines. (line 354)
-* table output functions: User Interface. (line 131)
-* target: Overall Structure. (line 50)
-* target architecture definition: Target Architecture Definition.
- (line 6)
-* target dependent files: Adding a New Target. (line 8)
-* target descriptions: Target Descriptions. (line 6)
-* target descriptions, adding register support: Adding Target Described Register Support.
- (line 6)
-* target descriptions, implementation: Target Descriptions Implementation.
- (line 6)
-* target vector: Target Vector Definition.
- (line 6)
-* TARGET_CAN_USE_HARDWARE_WATCHPOINT: Algorithms. (line 333)
-* target_changed: GDB Observers. (line 82)
-* TARGET_CHAR_BIT: Defining Other Architecture Features.
- (line 458)
-* target_insert_breakpoint: Algorithms. (line 211)
-* target_insert_hw_breakpoint: Algorithms. (line 234)
-* target_insert_watchpoint: Algorithms. (line 347)
-* TARGET_REGION_OK_FOR_HW_WATCHPOINT: Algorithms. (line 343)
-* target_remove_breakpoint: Algorithms. (line 211)
-* target_remove_hw_breakpoint: Algorithms. (line 234)
-* target_remove_watchpoint: Algorithms. (line 347)
-* target_resumed: GDB Observers. (line 129)
-* target_stopped_data_address: Algorithms. (line 364)
-* target_watchpoint_addr_within_range: Algorithms. (line 378)
-* targets: Existing Targets. (line 6)
-* TCP remote support: Host Definition. (line 57)
-* terminal device: Host Definition. (line 97)
-* test suite: Testsuite. (line 6)
-* test suite organization: Testsuite. (line 195)
-* test_notification: GDB Observers. (line 189)
-* Testsuite Configuration: Testsuite. (line 167)
-* THIS frame: Frame Handling Terminology.
- (line 9)
-* thread_exit: GDB Observers. (line 117)
-* thread_ptid_changed: GDB Observers. (line 165)
-* thread_stop_requested: GDB Observers. (line 122)
-* tracepoint_created: GDB Observers. (line 148)
-* tracepoint_deleted: GDB Observers. (line 152)
-* tracepoint_modified: GDB Observers. (line 156)
-* tuple output functions: User Interface. (line 131)
-* type codes: Symbol Handling. (line 191)
-* types: Coding Standards. (line 121)
-* ui_out functions: User Interface. (line 47)
-* ui_out functions, usage examples: User Interface. (line 398)
-* ui_out_field_core_addr: User Interface. (line 287)
-* ui_out_field_fmt: User Interface. (line 261)
-* ui_out_field_fmt_int: User Interface. (line 280)
-* ui_out_field_int: User Interface. (line 273)
-* ui_out_field_skip: User Interface. (line 352)
-* ui_out_field_stream: User Interface. (line 320)
-* ui_out_field_string: User Interface. (line 291)
-* ui_out_flush: User Interface. (line 392)
-* ui_out_list_begin: User Interface. (line 234)
-* ui_out_list_end: User Interface. (line 240)
-* ui_out_message: User Interface. (line 376)
-* ui_out_spaces: User Interface. (line 371)
-* ui_out_stream_delete: User Interface. (line 315)
-* ui_out_stream_new: User Interface. (line 309)
-* ui_out_table_begin: User Interface. (line 165)
-* ui_out_table_body: User Interface. (line 191)
-* ui_out_table_end: User Interface. (line 194)
-* ui_out_table_header: User Interface. (line 178)
-* ui_out_text: User Interface. (line 358)
-* ui_out_tuple_begin: User Interface. (line 210)
-* ui_out_tuple_end: User Interface. (line 216)
-* ui_out_wrap_hint: User Interface. (line 382)
-* unwind frame: Stack Frames. (line 9)
-* unwind_dummy_id: Functions Creating Dummy Frames.
- (line 38)
-* unwind_pc: Functions to Access Frame Data.
- (line 11)
-* unwind_sp: Functions to Access Frame Data.
- (line 27)
-* unwinding: Frame Handling Terminology.
- (line 41)
-* using ui_out functions: User Interface. (line 398)
-* value structure: Values. (line 9)
-* value_as_address: Pointers and Addresses.
- (line 84)
-* value_from_pointer: Pointers and Addresses.
- (line 93)
-* values: Values. (line 9)
-* VEC: Support Libraries. (line 131)
-* vendor branches: Versions and Branches.
- (line 108)
-* void: GDB Observers. (line 71)
-* volatile: Host Definition. (line 122)
-* watchpoints: Algorithms. (line 274)
-* watchpoints, on x86: Algorithms. (line 449)
-* watchpoints, with threads: Algorithms. (line 425)
-* word-addressed machines: Pointers and Addresses.
- (line 6)
-* wrap_here: Misc Guidelines. (line 191)
-* write_pc: Register Architecture Functions & Variables.
- (line 13)
-* writing tests: Testsuite. (line 247)
-* x86 debug registers: Algorithms. (line 449)
-* XCOFF format: Symbol Handling. (line 256)
-
-
-
-Tag Table:
-Node: Top1621
-Node: Summary2532
-Node: Requirements2682
-Node: Contributors4161
-Node: Overall Structure5754
-Node: Algorithms10777
-Node: User Interface42219
-Ref: UI-Independent Output44074
-Ref: User Interface-Footnote-166064
-Ref: User Interface-Footnote-266113
-Node: libgdb66348
-Node: Values70299
-Node: Stack Frames73143
-Node: Symbol Handling78125
-Node: Language Support94930
-Node: Host Definition99656
-Node: Target Architecture Definition104015
-Node: OS ABI Variant Handling104835
-Node: Initialize New Architecture109680
-Node: How an Architecture is Represented110031
-Node: Looking Up an Existing Architecture111988
-Node: Creating a New Architecture114907
-Node: Registers and Memory116945
-Node: Pointers and Addresses117737
-Ref: Pointers and Addresses-Footnote-1123738
-Node: Address Classes123981
-Node: Register Representation127226
-Node: Raw and Cooked Registers127600
-Node: Register Architecture Functions & Variables128784
-Node: Register Information Functions132393
-Ref: Register Information Functions-Footnote-1138299
-Node: Register and Memory Data138718
-Node: Register Caching141867
-Node: Frame Interpretation143403
-Node: All About Stack Frames143809
-Ref: All About Stack Frames-Footnote-1149101
-Node: Frame Handling Terminology149333
-Node: Prologue Caches151860
-Node: Functions and Variable to Analyze Frames153541
-Ref: frame_align155639
-Node: Functions to Access Frame Data157153
-Node: Analyzing Stacks---Frame Sniffers159444
-Ref: Analyzing Stacks---Frame Sniffers-Footnote-1164094
-Node: Inferior Call Setup164591
-Node: About Dummy Frames164874
-Node: Functions Creating Dummy Frames165500
-Node: Adding support for debugging core files169557
-Node: Defining Other Architecture Features170101
-Ref: gdbarch_breakpoint_from_pc174948
-Ref: gdbarch_stabs_argument_has_addr187342
-Ref: gdbarch_push_dummy_call187589
-Ref: gdbarch_push_dummy_code188149
-Ref: gdbarch_return_value189131
-Ref: gdbarch_dummy_id194897
-Node: Adding a New Target195585
-Node: Target Descriptions198052
-Node: Target Descriptions Implementation198991
-Node: Adding Target Described Register Support200365
-Node: Target Vector Definition203311
-Node: Managing Execution State203843
-Node: Existing Targets205656
-Node: Native Debugging208171
-Node: Support Libraries211999
-Node: Coding Standards223524
-Node: Misc Guidelines231404
-Node: Porting GDB249767
-Node: Versions and Branches251645
-Ref: Tags257601
-Ref: experimental branch tags257932
-Node: Start of New Year Procedure258664
-Node: Releasing GDB260470
-Node: Testsuite278702
-Ref: Testsuite-Footnote-1290567
-Node: Hints290685
-Node: Getting Started291007
-Node: Debugging GDB295172
-Node: GDB Observers300261
-Node: GNU Free Documentation License308569
-Node: Index333736
-
-End Tag Table
diff --git a/share/info/gprof.info b/share/info/gprof.info
deleted file mode 100644
index cc14286..0000000
--- a/share/info/gprof.info
+++ /dev/null
@@ -1,2475 +0,0 @@
-This is gprof.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../binutils/binutils-2.21/gprof/gprof.texi.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* gprof: (gprof). Profiling your program's execution
-END-INFO-DIR-ENTRY
-
- This file documents the gprof profiler of the GNU system.
-
- Copyright (C) 1988, 1992, 1997, 1998, 1999, 2000, 2001, 2003, 2007,
-2008, 2009 Free Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
-
-File: gprof.info, Node: Top, Next: Introduction, Up: (dir)
-
-Profiling a Program: Where Does It Spend Its Time?
-**************************************************
-
-This manual describes the GNU profiler, `gprof', and how you can use it
-to determine which parts of a program are taking most of the execution
-time. We assume that you know how to write, compile, and execute
-programs. GNU `gprof' was written by Jay Fenlason.
-
- This manual is for `gprof' (GNU Binutils) version 2.21.
-
- This document is distributed under the terms of the GNU Free
-Documentation License version 1.3. A copy of the license is included
-in the section entitled "GNU Free Documentation License".
-
-* Menu:
-
-* Introduction:: What profiling means, and why it is useful.
-
-* Compiling:: How to compile your program for profiling.
-* Executing:: Executing your program to generate profile data
-* Invoking:: How to run `gprof', and its options
-
-* Output:: Interpreting `gprof''s output
-
-* Inaccuracy:: Potential problems you should be aware of
-* How do I?:: Answers to common questions
-* Incompatibilities:: (between GNU `gprof' and Unix `gprof'.)
-* Details:: Details of how profiling is done
-* GNU Free Documentation License:: GNU Free Documentation License
-
-
-File: gprof.info, Node: Introduction, Next: Compiling, Prev: Top, Up: Top
-
-1 Introduction to Profiling
-***************************
-
-Profiling allows you to learn where your program spent its time and
-which functions called which other functions while it was executing.
-This information can show you which pieces of your program are slower
-than you expected, and might be candidates for rewriting to make your
-program execute faster. It can also tell you which functions are being
-called more or less often than you expected. This may help you spot
-bugs that had otherwise been unnoticed.
-
- Since the profiler uses information collected during the actual
-execution of your program, it can be used on programs that are too
-large or too complex to analyze by reading the source. However, how
-your program is run will affect the information that shows up in the
-profile data. If you don't use some feature of your program while it
-is being profiled, no profile information will be generated for that
-feature.
-
- Profiling has several steps:
-
- * You must compile and link your program with profiling enabled.
- *Note Compiling a Program for Profiling: Compiling.
-
- * You must execute your program to generate a profile data file.
- *Note Executing the Program: Executing.
-
- * You must run `gprof' to analyze the profile data. *Note `gprof'
- Command Summary: Invoking.
-
- The next three chapters explain these steps in greater detail.
-
- Several forms of output are available from the analysis.
-
- The "flat profile" shows how much time your program spent in each
-function, and how many times that function was called. If you simply
-want to know which functions burn most of the cycles, it is stated
-concisely here. *Note The Flat Profile: Flat Profile.
-
- The "call graph" shows, for each function, which functions called
-it, which other functions it called, and how many times. There is also
-an estimate of how much time was spent in the subroutines of each
-function. This can suggest places where you might try to eliminate
-function calls that use a lot of time. *Note The Call Graph: Call
-Graph.
-
- The "annotated source" listing is a copy of the program's source
-code, labeled with the number of times each line of the program was
-executed. *Note The Annotated Source Listing: Annotated Source.
-
- To better understand how profiling works, you may wish to read a
-description of its implementation. *Note Implementation of Profiling:
-Implementation.
-
-
-File: gprof.info, Node: Compiling, Next: Executing, Prev: Introduction, Up: Top
-
-2 Compiling a Program for Profiling
-***********************************
-
-The first step in generating profile information for your program is to
-compile and link it with profiling enabled.
-
- To compile a source file for profiling, specify the `-pg' option when
-you run the compiler. (This is in addition to the options you normally
-use.)
-
- To link the program for profiling, if you use a compiler such as `cc'
-to do the linking, simply specify `-pg' in addition to your usual
-options. The same option, `-pg', alters either compilation or linking
-to do what is necessary for profiling. Here are examples:
-
- cc -g -c myprog.c utils.c -pg
- cc -o myprog myprog.o utils.o -pg
-
- The `-pg' option also works with a command that both compiles and
-links:
-
- cc -o myprog myprog.c utils.c -g -pg
-
- Note: The `-pg' option must be part of your compilation options as
-well as your link options. If it is not then no call-graph data will
-be gathered and when you run `gprof' you will get an error message like
-this:
-
- gprof: gmon.out file is missing call-graph data
-
- If you add the `-Q' switch to suppress the printing of the call
-graph data you will still be able to see the time samples:
-
- Flat profile:
-
- Each sample counts as 0.01 seconds.
- % cumulative self self total
- time seconds seconds calls Ts/call Ts/call name
- 44.12 0.07 0.07 zazLoop
- 35.29 0.14 0.06 main
- 20.59 0.17 0.04 bazMillion
-
- If you run the linker `ld' directly instead of through a compiler
-such as `cc', you may have to specify a profiling startup file
-`gcrt0.o' as the first input file instead of the usual startup file
-`crt0.o'. In addition, you would probably want to specify the
-profiling C library, `libc_p.a', by writing `-lc_p' instead of the
-usual `-lc'. This is not absolutely necessary, but doing this gives
-you number-of-calls information for standard library functions such as
-`read' and `open'. For example:
-
- ld -o myprog /lib/gcrt0.o myprog.o utils.o -lc_p
-
- If you are running the program on a system which supports shared
-libraries you may run into problems with the profiling support code in
-a shared library being called before that library has been fully
-initialised. This is usually detected by the program encountering a
-segmentation fault as soon as it is run. The solution is to link
-against a static version of the library containing the profiling
-support code, which for `gcc' users can be done via the `-static' or
-`-static-libgcc' command line option. For example:
-
- gcc -g -pg -static-libgcc myprog.c utils.c -o myprog
-
- If you compile only some of the modules of the program with `-pg',
-you can still profile the program, but you won't get complete
-information about the modules that were compiled without `-pg'. The
-only information you get for the functions in those modules is the
-total time spent in them; there is no record of how many times they
-were called, or from where. This will not affect the flat profile
-(except that the `calls' field for the functions will be blank), but
-will greatly reduce the usefulness of the call graph.
-
- If you wish to perform line-by-line profiling you should use the
-`gcov' tool instead of `gprof'. See that tool's manual or info pages
-for more details of how to do this.
-
- Note, older versions of `gcc' produce line-by-line profiling
-information that works with `gprof' rather than `gcov' so there is
-still support for displaying this kind of information in `gprof'. *Note
-Line-by-line Profiling: Line-by-line.
-
- It also worth noting that `gcc' implements a
-`-finstrument-functions' command line option which will insert calls to
-special user supplied instrumentation routines at the entry and exit of
-every function in their program. This can be used to implement an
-alternative profiling scheme.
-
-
-File: gprof.info, Node: Executing, Next: Invoking, Prev: Compiling, Up: Top
-
-3 Executing the Program
-***********************
-
-Once the program is compiled for profiling, you must run it in order to
-generate the information that `gprof' needs. Simply run the program as
-usual, using the normal arguments, file names, etc. The program should
-run normally, producing the same output as usual. It will, however, run
-somewhat slower than normal because of the time spent collecting and
-writing the profile data.
-
- The way you run the program--the arguments and input that you give
-it--may have a dramatic effect on what the profile information shows.
-The profile data will describe the parts of the program that were
-activated for the particular input you use. For example, if the first
-command you give to your program is to quit, the profile data will show
-the time used in initialization and in cleanup, but not much else.
-
- Your program will write the profile data into a file called
-`gmon.out' just before exiting. If there is already a file called
-`gmon.out', its contents are overwritten. There is currently no way to
-tell the program to write the profile data under a different name, but
-you can rename the file afterwards if you are concerned that it may be
-overwritten.
-
- In order to write the `gmon.out' file properly, your program must
-exit normally: by returning from `main' or by calling `exit'. Calling
-the low-level function `_exit' does not write the profile data, and
-neither does abnormal termination due to an unhandled signal.
-
- The `gmon.out' file is written in the program's _current working
-directory_ at the time it exits. This means that if your program calls
-`chdir', the `gmon.out' file will be left in the last directory your
-program `chdir''d to. If you don't have permission to write in this
-directory, the file is not written, and you will get an error message.
-
- Older versions of the GNU profiling library may also write a file
-called `bb.out'. This file, if present, contains an human-readable
-listing of the basic-block execution counts. Unfortunately, the
-appearance of a human-readable `bb.out' means the basic-block counts
-didn't get written into `gmon.out'. The Perl script `bbconv.pl',
-included with the `gprof' source distribution, will convert a `bb.out'
-file into a format readable by `gprof'. Invoke it like this:
-
- bbconv.pl < bb.out > BH-DATA
-
- This translates the information in `bb.out' into a form that `gprof'
-can understand. But you still need to tell `gprof' about the existence
-of this translated information. To do that, include BB-DATA on the
-`gprof' command line, _along with `gmon.out'_, like this:
-
- gprof OPTIONS EXECUTABLE-FILE gmon.out BB-DATA [YET-MORE-PROFILE-DATA-FILES...] [> OUTFILE]
-
-
-File: gprof.info, Node: Invoking, Next: Output, Prev: Executing, Up: Top
-
-4 `gprof' Command Summary
-*************************
-
-After you have a profile data file `gmon.out', you can run `gprof' to
-interpret the information in it. The `gprof' program prints a flat
-profile and a call graph on standard output. Typically you would
-redirect the output of `gprof' into a file with `>'.
-
- You run `gprof' like this:
-
- gprof OPTIONS [EXECUTABLE-FILE [PROFILE-DATA-FILES...]] [> OUTFILE]
-
-Here square-brackets indicate optional arguments.
-
- If you omit the executable file name, the file `a.out' is used. If
-you give no profile data file name, the file `gmon.out' is used. If
-any file is not in the proper format, or if the profile data file does
-not appear to belong to the executable file, an error message is
-printed.
-
- You can give more than one profile data file by entering all their
-names after the executable file name; then the statistics in all the
-data files are summed together.
-
- The order of these options does not matter.
-
-* Menu:
-
-* Output Options:: Controlling `gprof''s output style
-* Analysis Options:: Controlling how `gprof' analyzes its data
-* Miscellaneous Options::
-* Deprecated Options:: Options you no longer need to use, but which
- have been retained for compatibility
-* Symspecs:: Specifying functions to include or exclude
-
-
-File: gprof.info, Node: Output Options, Next: Analysis Options, Up: Invoking
-
-4.1 Output Options
-==================
-
-These options specify which of several output formats `gprof' should
-produce.
-
- Many of these options take an optional "symspec" to specify
-functions to be included or excluded. These options can be specified
-multiple times, with different symspecs, to include or exclude sets of
-symbols. *Note Symspecs: Symspecs.
-
- Specifying any of these options overrides the default (`-p -q'),
-which prints a flat profile and call graph analysis for all functions.
-
-`-A[SYMSPEC]'
-`--annotated-source[=SYMSPEC]'
- The `-A' option causes `gprof' to print annotated source code. If
- SYMSPEC is specified, print output only for matching symbols.
- *Note The Annotated Source Listing: Annotated Source.
-
-`-b'
-`--brief'
- If the `-b' option is given, `gprof' doesn't print the verbose
- blurbs that try to explain the meaning of all of the fields in the
- tables. This is useful if you intend to print out the output, or
- are tired of seeing the blurbs.
-
-`-C[SYMSPEC]'
-`--exec-counts[=SYMSPEC]'
- The `-C' option causes `gprof' to print a tally of functions and
- the number of times each was called. If SYMSPEC is specified,
- print tally only for matching symbols.
-
- If the profile data file contains basic-block count records,
- specifying the `-l' option, along with `-C', will cause basic-block
- execution counts to be tallied and displayed.
-
-`-i'
-`--file-info'
- The `-i' option causes `gprof' to display summary information
- about the profile data file(s) and then exit. The number of
- histogram, call graph, and basic-block count records is displayed.
-
-`-I DIRS'
-`--directory-path=DIRS'
- The `-I' option specifies a list of search directories in which to
- find source files. Environment variable GPROF_PATH can also be
- used to convey this information. Used mostly for annotated source
- output.
-
-`-J[SYMSPEC]'
-`--no-annotated-source[=SYMSPEC]'
- The `-J' option causes `gprof' not to print annotated source code.
- If SYMSPEC is specified, `gprof' prints annotated source, but
- excludes matching symbols.
-
-`-L'
-`--print-path'
- Normally, source filenames are printed with the path component
- suppressed. The `-L' option causes `gprof' to print the full
- pathname of source filenames, which is determined from symbolic
- debugging information in the image file and is relative to the
- directory in which the compiler was invoked.
-
-`-p[SYMSPEC]'
-`--flat-profile[=SYMSPEC]'
- The `-p' option causes `gprof' to print a flat profile. If
- SYMSPEC is specified, print flat profile only for matching symbols.
- *Note The Flat Profile: Flat Profile.
-
-`-P[SYMSPEC]'
-`--no-flat-profile[=SYMSPEC]'
- The `-P' option causes `gprof' to suppress printing a flat profile.
- If SYMSPEC is specified, `gprof' prints a flat profile, but
- excludes matching symbols.
-
-`-q[SYMSPEC]'
-`--graph[=SYMSPEC]'
- The `-q' option causes `gprof' to print the call graph analysis.
- If SYMSPEC is specified, print call graph only for matching symbols
- and their children. *Note The Call Graph: Call Graph.
-
-`-Q[SYMSPEC]'
-`--no-graph[=SYMSPEC]'
- The `-Q' option causes `gprof' to suppress printing the call graph.
- If SYMSPEC is specified, `gprof' prints a call graph, but excludes
- matching symbols.
-
-`-t'
-`--table-length=NUM'
- The `-t' option causes the NUM most active source lines in each
- source file to be listed when source annotation is enabled. The
- default is 10.
-
-`-y'
-`--separate-files'
- This option affects annotated source output only. Normally,
- `gprof' prints annotated source files to standard-output. If this
- option is specified, annotated source for a file named
- `path/FILENAME' is generated in the file `FILENAME-ann'. If the
- underlying file system would truncate `FILENAME-ann' so that it
- overwrites the original `FILENAME', `gprof' generates annotated
- source in the file `FILENAME.ann' instead (if the original file
- name has an extension, that extension is _replaced_ with `.ann').
-
-`-Z[SYMSPEC]'
-`--no-exec-counts[=SYMSPEC]'
- The `-Z' option causes `gprof' not to print a tally of functions
- and the number of times each was called. If SYMSPEC is specified,
- print tally, but exclude matching symbols.
-
-`-r'
-`--function-ordering'
- The `--function-ordering' option causes `gprof' to print a
- suggested function ordering for the program based on profiling
- data. This option suggests an ordering which may improve paging,
- tlb and cache behavior for the program on systems which support
- arbitrary ordering of functions in an executable.
-
- The exact details of how to force the linker to place functions in
- a particular order is system dependent and out of the scope of this
- manual.
-
-`-R MAP_FILE'
-`--file-ordering MAP_FILE'
- The `--file-ordering' option causes `gprof' to print a suggested
- .o link line ordering for the program based on profiling data.
- This option suggests an ordering which may improve paging, tlb and
- cache behavior for the program on systems which do not support
- arbitrary ordering of functions in an executable.
-
- Use of the `-a' argument is highly recommended with this option.
-
- The MAP_FILE argument is a pathname to a file which provides
- function name to object file mappings. The format of the file is
- similar to the output of the program `nm'.
-
- c-parse.o:00000000 T yyparse
- c-parse.o:00000004 C yyerrflag
- c-lang.o:00000000 T maybe_objc_method_name
- c-lang.o:00000000 T print_lang_statistics
- c-lang.o:00000000 T recognize_objc_keyword
- c-decl.o:00000000 T print_lang_identifier
- c-decl.o:00000000 T print_lang_type
- ...
-
- To create a MAP_FILE with GNU `nm', type a command like `nm
- --extern-only --defined-only -v --print-file-name program-name'.
-
-`-T'
-`--traditional'
- The `-T' option causes `gprof' to print its output in
- "traditional" BSD style.
-
-`-w WIDTH'
-`--width=WIDTH'
- Sets width of output lines to WIDTH. Currently only used when
- printing the function index at the bottom of the call graph.
-
-`-x'
-`--all-lines'
- This option affects annotated source output only. By default,
- only the lines at the beginning of a basic-block are annotated.
- If this option is specified, every line in a basic-block is
- annotated by repeating the annotation for the first line. This
- behavior is similar to `tcov''s `-a'.
-
-`--demangle[=STYLE]'
-`--no-demangle'
- These options control whether C++ symbol names should be demangled
- when printing output. The default is to demangle symbols. The
- `--no-demangle' option may be used to turn off demangling.
- Different compilers have different mangling styles. The optional
- demangling style argument can be used to choose an appropriate
- demangling style for your compiler.
-
-
-File: gprof.info, Node: Analysis Options, Next: Miscellaneous Options, Prev: Output Options, Up: Invoking
-
-4.2 Analysis Options
-====================
-
-`-a'
-`--no-static'
- The `-a' option causes `gprof' to suppress the printing of
- statically declared (private) functions. (These are functions
- whose names are not listed as global, and which are not visible
- outside the file/function/block where they were defined.) Time
- spent in these functions, calls to/from them, etc., will all be
- attributed to the function that was loaded directly before it in
- the executable file. This option affects both the flat profile
- and the call graph.
-
-`-c'
-`--static-call-graph'
- The `-c' option causes the call graph of the program to be
- augmented by a heuristic which examines the text space of the
- object file and identifies function calls in the binary machine
- code. Since normal call graph records are only generated when
- functions are entered, this option identifies children that could
- have been called, but never were. Calls to functions that were
- not compiled with profiling enabled are also identified, but only
- if symbol table entries are present for them. Calls to dynamic
- library routines are typically _not_ found by this option.
- Parents or children identified via this heuristic are indicated in
- the call graph with call counts of `0'.
-
-`-D'
-`--ignore-non-functions'
- The `-D' option causes `gprof' to ignore symbols which are not
- known to be functions. This option will give more accurate
- profile data on systems where it is supported (Solaris and HPUX for
- example).
-
-`-k FROM/TO'
- The `-k' option allows you to delete from the call graph any arcs
- from symbols matching symspec FROM to those matching symspec TO.
-
-`-l'
-`--line'
- The `-l' option enables line-by-line profiling, which causes
- histogram hits to be charged to individual source code lines,
- instead of functions. This feature only works with programs
- compiled by older versions of the `gcc' compiler. Newer versions
- of `gcc' are designed to work with the `gcov' tool instead.
-
- If the program was compiled with basic-block counting enabled,
- this option will also identify how many times each line of code
- was executed. While line-by-line profiling can help isolate where
- in a large function a program is spending its time, it also
- significantly increases the running time of `gprof', and magnifies
- statistical inaccuracies. *Note Statistical Sampling Error:
- Sampling Error.
-
-`-m NUM'
-`--min-count=NUM'
- This option affects execution count output only. Symbols that are
- executed less than NUM times are suppressed.
-
-`-nSYMSPEC'
-`--time=SYMSPEC'
- The `-n' option causes `gprof', in its call graph analysis, to
- only propagate times for symbols matching SYMSPEC.
-
-`-NSYMSPEC'
-`--no-time=SYMSPEC'
- The `-n' option causes `gprof', in its call graph analysis, not to
- propagate times for symbols matching SYMSPEC.
-
-`-SFILENAME'
-`--external-symbol-table=FILENAME'
- The `-S' option causes `gprof' to read an external symbol table
- file, such as `/proc/kallsyms', rather than read the symbol table
- from the given object file (the default is `a.out'). This is useful
- for profiling kernel modules.
-
-`-z'
-`--display-unused-functions'
- If you give the `-z' option, `gprof' will mention all functions in
- the flat profile, even those that were never called, and that had
- no time spent in them. This is useful in conjunction with the
- `-c' option for discovering which routines were never called.
-
-
-
-File: gprof.info, Node: Miscellaneous Options, Next: Deprecated Options, Prev: Analysis Options, Up: Invoking
-
-4.3 Miscellaneous Options
-=========================
-
-`-d[NUM]'
-`--debug[=NUM]'
- The `-d NUM' option specifies debugging options. If NUM is not
- specified, enable all debugging. *Note Debugging `gprof':
- Debugging.
-
-`-h'
-`--help'
- The `-h' option prints command line usage.
-
-`-ONAME'
-`--file-format=NAME'
- Selects the format of the profile data files. Recognized formats
- are `auto' (the default), `bsd', `4.4bsd', `magic', and `prof'
- (not yet supported).
-
-`-s'
-`--sum'
- The `-s' option causes `gprof' to summarize the information in the
- profile data files it read in, and write out a profile data file
- called `gmon.sum', which contains all the information from the
- profile data files that `gprof' read in. The file `gmon.sum' may
- be one of the specified input files; the effect of this is to
- merge the data in the other input files into `gmon.sum'.
-
- Eventually you can run `gprof' again without `-s' to analyze the
- cumulative data in the file `gmon.sum'.
-
-`-v'
-`--version'
- The `-v' flag causes `gprof' to print the current version number,
- and then exit.
-
-
-
-File: gprof.info, Node: Deprecated Options, Next: Symspecs, Prev: Miscellaneous Options, Up: Invoking
-
-4.4 Deprecated Options
-======================
-
-These options have been replaced with newer versions that use symspecs.
-
-`-e FUNCTION_NAME'
- The `-e FUNCTION' option tells `gprof' to not print information
- about the function FUNCTION_NAME (and its children...) in the call
- graph. The function will still be listed as a child of any
- functions that call it, but its index number will be shown as
- `[not printed]'. More than one `-e' option may be given; only one
- FUNCTION_NAME may be indicated with each `-e' option.
-
-`-E FUNCTION_NAME'
- The `-E FUNCTION' option works like the `-e' option, but time
- spent in the function (and children who were not called from
- anywhere else), will not be used to compute the
- percentages-of-time for the call graph. More than one `-E' option
- may be given; only one FUNCTION_NAME may be indicated with each
- `-E' option.
-
-`-f FUNCTION_NAME'
- The `-f FUNCTION' option causes `gprof' to limit the call graph to
- the function FUNCTION_NAME and its children (and their
- children...). More than one `-f' option may be given; only one
- FUNCTION_NAME may be indicated with each `-f' option.
-
-`-F FUNCTION_NAME'
- The `-F FUNCTION' option works like the `-f' option, but only time
- spent in the function and its children (and their children...)
- will be used to determine total-time and percentages-of-time for
- the call graph. More than one `-F' option may be given; only one
- FUNCTION_NAME may be indicated with each `-F' option. The `-F'
- option overrides the `-E' option.
-
-
- Note that only one function can be specified with each `-e', `-E',
-`-f' or `-F' option. To specify more than one function, use multiple
-options. For example, this command:
-
- gprof -e boring -f foo -f bar myprogram > gprof.output
-
-lists in the call graph all functions that were reached from either
-`foo' or `bar' and were not reachable from `boring'.
-
-
-File: gprof.info, Node: Symspecs, Prev: Deprecated Options, Up: Invoking
-
-4.5 Symspecs
-============
-
-Many of the output options allow functions to be included or excluded
-using "symspecs" (symbol specifications), which observe the following
-syntax:
-
- filename_containing_a_dot
- | funcname_not_containing_a_dot
- | linenumber
- | ( [ any_filename ] `:' ( any_funcname | linenumber ) )
-
- Here are some sample symspecs:
-
-`main.c'
- Selects everything in file `main.c'--the dot in the string tells
- `gprof' to interpret the string as a filename, rather than as a
- function name. To select a file whose name does not contain a
- dot, a trailing colon should be specified. For example, `odd:' is
- interpreted as the file named `odd'.
-
-`main'
- Selects all functions named `main'.
-
- Note that there may be multiple instances of the same function name
- because some of the definitions may be local (i.e., static).
- Unless a function name is unique in a program, you must use the
- colon notation explained below to specify a function from a
- specific source file.
-
- Sometimes, function names contain dots. In such cases, it is
- necessary to add a leading colon to the name. For example,
- `:.mul' selects function `.mul'.
-
- In some object file formats, symbols have a leading underscore.
- `gprof' will normally not print these underscores. When you name a
- symbol in a symspec, you should type it exactly as `gprof' prints
- it in its output. For example, if the compiler produces a symbol
- `_main' from your `main' function, `gprof' still prints it as
- `main' in its output, so you should use `main' in symspecs.
-
-`main.c:main'
- Selects function `main' in file `main.c'.
-
-`main.c:134'
- Selects line 134 in file `main.c'.
-
-
-File: gprof.info, Node: Output, Next: Inaccuracy, Prev: Invoking, Up: Top
-
-5 Interpreting `gprof''s Output
-*******************************
-
-`gprof' can produce several different output styles, the most important
-of which are described below. The simplest output styles (file
-information, execution count, and function and file ordering) are not
-described here, but are documented with the respective options that
-trigger them. *Note Output Options: Output Options.
-
-* Menu:
-
-* Flat Profile:: The flat profile shows how much time was spent
- executing directly in each function.
-* Call Graph:: The call graph shows which functions called which
- others, and how much time each function used
- when its subroutine calls are included.
-* Line-by-line:: `gprof' can analyze individual source code lines
-* Annotated Source:: The annotated source listing displays source code
- labeled with execution counts
-
-
-File: gprof.info, Node: Flat Profile, Next: Call Graph, Up: Output
-
-5.1 The Flat Profile
-====================
-
-The "flat profile" shows the total amount of time your program spent
-executing each function. Unless the `-z' option is given, functions
-with no apparent time spent in them, and no apparent calls to them, are
-not mentioned. Note that if a function was not compiled for profiling,
-and didn't run long enough to show up on the program counter histogram,
-it will be indistinguishable from a function that was never called.
-
- This is part of a flat profile for a small program:
-
- Flat profile:
-
- Each sample counts as 0.01 seconds.
- % cumulative self self total
- time seconds seconds calls ms/call ms/call name
- 33.34 0.02 0.02 7208 0.00 0.00 open
- 16.67 0.03 0.01 244 0.04 0.12 offtime
- 16.67 0.04 0.01 8 1.25 1.25 memccpy
- 16.67 0.05 0.01 7 1.43 1.43 write
- 16.67 0.06 0.01 mcount
- 0.00 0.06 0.00 236 0.00 0.00 tzset
- 0.00 0.06 0.00 192 0.00 0.00 tolower
- 0.00 0.06 0.00 47 0.00 0.00 strlen
- 0.00 0.06 0.00 45 0.00 0.00 strchr
- 0.00 0.06 0.00 1 0.00 50.00 main
- 0.00 0.06 0.00 1 0.00 0.00 memcpy
- 0.00 0.06 0.00 1 0.00 10.11 print
- 0.00 0.06 0.00 1 0.00 0.00 profil
- 0.00 0.06 0.00 1 0.00 50.00 report
- ...
-
-The functions are sorted first by decreasing run-time spent in them,
-then by decreasing number of calls, then alphabetically by name. The
-functions `mcount' and `profil' are part of the profiling apparatus and
-appear in every flat profile; their time gives a measure of the amount
-of overhead due to profiling.
-
- Just before the column headers, a statement appears indicating how
-much time each sample counted as. This "sampling period" estimates the
-margin of error in each of the time figures. A time figure that is not
-much larger than this is not reliable. In this example, each sample
-counted as 0.01 seconds, suggesting a 100 Hz sampling rate. The
-program's total execution time was 0.06 seconds, as indicated by the
-`cumulative seconds' field. Since each sample counted for 0.01
-seconds, this means only six samples were taken during the run. Two of
-the samples occurred while the program was in the `open' function, as
-indicated by the `self seconds' field. Each of the other four samples
-occurred one each in `offtime', `memccpy', `write', and `mcount'.
-Since only six samples were taken, none of these values can be regarded
-as particularly reliable. In another run, the `self seconds' field for
-`mcount' might well be `0.00' or `0.02'. *Note Statistical Sampling
-Error: Sampling Error, for a complete discussion.
-
- The remaining functions in the listing (those whose `self seconds'
-field is `0.00') didn't appear in the histogram samples at all.
-However, the call graph indicated that they were called, so therefore
-they are listed, sorted in decreasing order by the `calls' field.
-Clearly some time was spent executing these functions, but the paucity
-of histogram samples prevents any determination of how much time each
-took.
-
- Here is what the fields in each line mean:
-
-`% time'
- This is the percentage of the total execution time your program
- spent in this function. These should all add up to 100%.
-
-`cumulative seconds'
- This is the cumulative total number of seconds the computer spent
- executing this functions, plus the time spent in all the functions
- above this one in this table.
-
-`self seconds'
- This is the number of seconds accounted for by this function alone.
- The flat profile listing is sorted first by this number.
-
-`calls'
- This is the total number of times the function was called. If the
- function was never called, or the number of times it was called
- cannot be determined (probably because the function was not
- compiled with profiling enabled), the "calls" field is blank.
-
-`self ms/call'
- This represents the average number of milliseconds spent in this
- function per call, if this function is profiled. Otherwise, this
- field is blank for this function.
-
-`total ms/call'
- This represents the average number of milliseconds spent in this
- function and its descendants per call, if this function is
- profiled. Otherwise, this field is blank for this function. This
- is the only field in the flat profile that uses call graph
- analysis.
-
-`name'
- This is the name of the function. The flat profile is sorted by
- this field alphabetically after the "self seconds" and "calls"
- fields are sorted.
-
-
-File: gprof.info, Node: Call Graph, Next: Line-by-line, Prev: Flat Profile, Up: Output
-
-5.2 The Call Graph
-==================
-
-The "call graph" shows how much time was spent in each function and its
-children. From this information, you can find functions that, while
-they themselves may not have used much time, called other functions
-that did use unusual amounts of time.
-
- Here is a sample call from a small program. This call came from the
-same `gprof' run as the flat profile example in the previous section.
-
- granularity: each sample hit covers 2 byte(s) for 20.00% of 0.05 seconds
-
- index % time self children called name
- <spontaneous>
- [1] 100.0 0.00 0.05 start [1]
- 0.00 0.05 1/1 main [2]
- 0.00 0.00 1/2 on_exit [28]
- 0.00 0.00 1/1 exit [59]
- -----------------------------------------------
- 0.00 0.05 1/1 start [1]
- [2] 100.0 0.00 0.05 1 main [2]
- 0.00 0.05 1/1 report [3]
- -----------------------------------------------
- 0.00 0.05 1/1 main [2]
- [3] 100.0 0.00 0.05 1 report [3]
- 0.00 0.03 8/8 timelocal [6]
- 0.00 0.01 1/1 print [9]
- 0.00 0.01 9/9 fgets [12]
- 0.00 0.00 12/34 strncmp <cycle 1> [40]
- 0.00 0.00 8/8 lookup [20]
- 0.00 0.00 1/1 fopen [21]
- 0.00 0.00 8/8 chewtime [24]
- 0.00 0.00 8/16 skipspace [44]
- -----------------------------------------------
- [4] 59.8 0.01 0.02 8+472 <cycle 2 as a whole> [4]
- 0.01 0.02 244+260 offtime <cycle 2> [7]
- 0.00 0.00 236+1 tzset <cycle 2> [26]
- -----------------------------------------------
-
- The lines full of dashes divide this table into "entries", one for
-each function. Each entry has one or more lines.
-
- In each entry, the primary line is the one that starts with an index
-number in square brackets. The end of this line says which function
-the entry is for. The preceding lines in the entry describe the
-callers of this function and the following lines describe its
-subroutines (also called "children" when we speak of the call graph).
-
- The entries are sorted by time spent in the function and its
-subroutines.
-
- The internal profiling function `mcount' (*note The Flat Profile:
-Flat Profile.) is never mentioned in the call graph.
-
-* Menu:
-
-* Primary:: Details of the primary line's contents.
-* Callers:: Details of caller-lines' contents.
-* Subroutines:: Details of subroutine-lines' contents.
-* Cycles:: When there are cycles of recursion,
- such as `a' calls `b' calls `a'...
-
-
-File: gprof.info, Node: Primary, Next: Callers, Up: Call Graph
-
-5.2.1 The Primary Line
-----------------------
-
-The "primary line" in a call graph entry is the line that describes the
-function which the entry is about and gives the overall statistics for
-this function.
-
- For reference, we repeat the primary line from the entry for function
-`report' in our main example, together with the heading line that shows
-the names of the fields:
-
- index % time self children called name
- ...
- [3] 100.0 0.00 0.05 1 report [3]
-
- Here is what the fields in the primary line mean:
-
-`index'
- Entries are numbered with consecutive integers. Each function
- therefore has an index number, which appears at the beginning of
- its primary line.
-
- Each cross-reference to a function, as a caller or subroutine of
- another, gives its index number as well as its name. The index
- number guides you if you wish to look for the entry for that
- function.
-
-`% time'
- This is the percentage of the total time that was spent in this
- function, including time spent in subroutines called from this
- function.
-
- The time spent in this function is counted again for the callers of
- this function. Therefore, adding up these percentages is
- meaningless.
-
-`self'
- This is the total amount of time spent in this function. This
- should be identical to the number printed in the `seconds' field
- for this function in the flat profile.
-
-`children'
- This is the total amount of time spent in the subroutine calls
- made by this function. This should be equal to the sum of all the
- `self' and `children' entries of the children listed directly
- below this function.
-
-`called'
- This is the number of times the function was called.
-
- If the function called itself recursively, there are two numbers,
- separated by a `+'. The first number counts non-recursive calls,
- and the second counts recursive calls.
-
- In the example above, the function `report' was called once from
- `main'.
-
-`name'
- This is the name of the current function. The index number is
- repeated after it.
-
- If the function is part of a cycle of recursion, the cycle number
- is printed between the function's name and the index number (*note
- How Mutually Recursive Functions Are Described: Cycles.). For
- example, if function `gnurr' is part of cycle number one, and has
- index number twelve, its primary line would be end like this:
-
- gnurr <cycle 1> [12]
-
-
-File: gprof.info, Node: Callers, Next: Subroutines, Prev: Primary, Up: Call Graph
-
-5.2.2 Lines for a Function's Callers
-------------------------------------
-
-A function's entry has a line for each function it was called by.
-These lines' fields correspond to the fields of the primary line, but
-their meanings are different because of the difference in context.
-
- For reference, we repeat two lines from the entry for the function
-`report', the primary line and one caller-line preceding it, together
-with the heading line that shows the names of the fields:
-
- index % time self children called name
- ...
- 0.00 0.05 1/1 main [2]
- [3] 100.0 0.00 0.05 1 report [3]
-
- Here are the meanings of the fields in the caller-line for `report'
-called from `main':
-
-`self'
- An estimate of the amount of time spent in `report' itself when it
- was called from `main'.
-
-`children'
- An estimate of the amount of time spent in subroutines of `report'
- when `report' was called from `main'.
-
- The sum of the `self' and `children' fields is an estimate of the
- amount of time spent within calls to `report' from `main'.
-
-`called'
- Two numbers: the number of times `report' was called from `main',
- followed by the total number of non-recursive calls to `report'
- from all its callers.
-
-`name and index number'
- The name of the caller of `report' to which this line applies,
- followed by the caller's index number.
-
- Not all functions have entries in the call graph; some options to
- `gprof' request the omission of certain functions. When a caller
- has no entry of its own, it still has caller-lines in the entries
- of the functions it calls.
-
- If the caller is part of a recursion cycle, the cycle number is
- printed between the name and the index number.
-
- If the identity of the callers of a function cannot be determined, a
-dummy caller-line is printed which has `<spontaneous>' as the "caller's
-name" and all other fields blank. This can happen for signal handlers.
-
-
-File: gprof.info, Node: Subroutines, Next: Cycles, Prev: Callers, Up: Call Graph
-
-5.2.3 Lines for a Function's Subroutines
-----------------------------------------
-
-A function's entry has a line for each of its subroutines--in other
-words, a line for each other function that it called. These lines'
-fields correspond to the fields of the primary line, but their meanings
-are different because of the difference in context.
-
- For reference, we repeat two lines from the entry for the function
-`main', the primary line and a line for a subroutine, together with the
-heading line that shows the names of the fields:
-
- index % time self children called name
- ...
- [2] 100.0 0.00 0.05 1 main [2]
- 0.00 0.05 1/1 report [3]
-
- Here are the meanings of the fields in the subroutine-line for `main'
-calling `report':
-
-`self'
- An estimate of the amount of time spent directly within `report'
- when `report' was called from `main'.
-
-`children'
- An estimate of the amount of time spent in subroutines of `report'
- when `report' was called from `main'.
-
- The sum of the `self' and `children' fields is an estimate of the
- total time spent in calls to `report' from `main'.
-
-`called'
- Two numbers, the number of calls to `report' from `main' followed
- by the total number of non-recursive calls to `report'. This
- ratio is used to determine how much of `report''s `self' and
- `children' time gets credited to `main'. *Note Estimating
- `children' Times: Assumptions.
-
-`name'
- The name of the subroutine of `main' to which this line applies,
- followed by the subroutine's index number.
-
- If the caller is part of a recursion cycle, the cycle number is
- printed between the name and the index number.
-
-
-File: gprof.info, Node: Cycles, Prev: Subroutines, Up: Call Graph
-
-5.2.4 How Mutually Recursive Functions Are Described
-----------------------------------------------------
-
-The graph may be complicated by the presence of "cycles of recursion"
-in the call graph. A cycle exists if a function calls another function
-that (directly or indirectly) calls (or appears to call) the original
-function. For example: if `a' calls `b', and `b' calls `a', then `a'
-and `b' form a cycle.
-
- Whenever there are call paths both ways between a pair of functions,
-they belong to the same cycle. If `a' and `b' call each other and `b'
-and `c' call each other, all three make one cycle. Note that even if
-`b' only calls `a' if it was not called from `a', `gprof' cannot
-determine this, so `a' and `b' are still considered a cycle.
-
- The cycles are numbered with consecutive integers. When a function
-belongs to a cycle, each time the function name appears in the call
-graph it is followed by `<cycle NUMBER>'.
-
- The reason cycles matter is that they make the time values in the
-call graph paradoxical. The "time spent in children" of `a' should
-include the time spent in its subroutine `b' and in `b''s
-subroutines--but one of `b''s subroutines is `a'! How much of `a''s
-time should be included in the children of `a', when `a' is indirectly
-recursive?
-
- The way `gprof' resolves this paradox is by creating a single entry
-for the cycle as a whole. The primary line of this entry describes the
-total time spent directly in the functions of the cycle. The
-"subroutines" of the cycle are the individual functions of the cycle,
-and all other functions that were called directly by them. The
-"callers" of the cycle are the functions, outside the cycle, that
-called functions in the cycle.
-
- Here is an example portion of a call graph which shows a cycle
-containing functions `a' and `b'. The cycle was entered by a call to
-`a' from `main'; both `a' and `b' called `c'.
-
- index % time self children called name
- ----------------------------------------
- 1.77 0 1/1 main [2]
- [3] 91.71 1.77 0 1+5 <cycle 1 as a whole> [3]
- 1.02 0 3 b <cycle 1> [4]
- 0.75 0 2 a <cycle 1> [5]
- ----------------------------------------
- 3 a <cycle 1> [5]
- [4] 52.85 1.02 0 0 b <cycle 1> [4]
- 2 a <cycle 1> [5]
- 0 0 3/6 c [6]
- ----------------------------------------
- 1.77 0 1/1 main [2]
- 2 b <cycle 1> [4]
- [5] 38.86 0.75 0 1 a <cycle 1> [5]
- 3 b <cycle 1> [4]
- 0 0 3/6 c [6]
- ----------------------------------------
-
-(The entire call graph for this program contains in addition an entry
-for `main', which calls `a', and an entry for `c', with callers `a' and
-`b'.)
-
- index % time self children called name
- <spontaneous>
- [1] 100.00 0 1.93 0 start [1]
- 0.16 1.77 1/1 main [2]
- ----------------------------------------
- 0.16 1.77 1/1 start [1]
- [2] 100.00 0.16 1.77 1 main [2]
- 1.77 0 1/1 a <cycle 1> [5]
- ----------------------------------------
- 1.77 0 1/1 main [2]
- [3] 91.71 1.77 0 1+5 <cycle 1 as a whole> [3]
- 1.02 0 3 b <cycle 1> [4]
- 0.75 0 2 a <cycle 1> [5]
- 0 0 6/6 c [6]
- ----------------------------------------
- 3 a <cycle 1> [5]
- [4] 52.85 1.02 0 0 b <cycle 1> [4]
- 2 a <cycle 1> [5]
- 0 0 3/6 c [6]
- ----------------------------------------
- 1.77 0 1/1 main [2]
- 2 b <cycle 1> [4]
- [5] 38.86 0.75 0 1 a <cycle 1> [5]
- 3 b <cycle 1> [4]
- 0 0 3/6 c [6]
- ----------------------------------------
- 0 0 3/6 b <cycle 1> [4]
- 0 0 3/6 a <cycle 1> [5]
- [6] 0.00 0 0 6 c [6]
- ----------------------------------------
-
- The `self' field of the cycle's primary line is the total time spent
-in all the functions of the cycle. It equals the sum of the `self'
-fields for the individual functions in the cycle, found in the entry in
-the subroutine lines for these functions.
-
- The `children' fields of the cycle's primary line and subroutine
-lines count only subroutines outside the cycle. Even though `a' calls
-`b', the time spent in those calls to `b' is not counted in `a''s
-`children' time. Thus, we do not encounter the problem of what to do
-when the time in those calls to `b' includes indirect recursive calls
-back to `a'.
-
- The `children' field of a caller-line in the cycle's entry estimates
-the amount of time spent _in the whole cycle_, and its other
-subroutines, on the times when that caller called a function in the
-cycle.
-
- The `called' field in the primary line for the cycle has two numbers:
-first, the number of times functions in the cycle were called by
-functions outside the cycle; second, the number of times they were
-called by functions in the cycle (including times when a function in
-the cycle calls itself). This is a generalization of the usual split
-into non-recursive and recursive calls.
-
- The `called' field of a subroutine-line for a cycle member in the
-cycle's entry says how many time that function was called from
-functions in the cycle. The total of all these is the second number in
-the primary line's `called' field.
-
- In the individual entry for a function in a cycle, the other
-functions in the same cycle can appear as subroutines and as callers.
-These lines show how many times each function in the cycle called or
-was called from each other function in the cycle. The `self' and
-`children' fields in these lines are blank because of the difficulty of
-defining meanings for them when recursion is going on.
-
-
-File: gprof.info, Node: Line-by-line, Next: Annotated Source, Prev: Call Graph, Up: Output
-
-5.3 Line-by-line Profiling
-==========================
-
-`gprof''s `-l' option causes the program to perform "line-by-line"
-profiling. In this mode, histogram samples are assigned not to
-functions, but to individual lines of source code. This only works
-with programs compiled with older versions of the `gcc' compiler.
-Newer versions of `gcc' use a different program - `gcov' - to display
-line-by-line profiling information.
-
- With the older versions of `gcc' the program usually has to be
-compiled with a `-g' option, in addition to `-pg', in order to generate
-debugging symbols for tracking source code lines. Note, in much older
-versions of `gcc' the program had to be compiled with the `-a' command
-line option as well.
-
- The flat profile is the most useful output table in line-by-line
-mode. The call graph isn't as useful as normal, since the current
-version of `gprof' does not propagate call graph arcs from source code
-lines to the enclosing function. The call graph does, however, show
-each line of code that called each function, along with a count.
-
- Here is a section of `gprof''s output, without line-by-line
-profiling. Note that `ct_init' accounted for four histogram hits, and
-13327 calls to `init_block'.
-
- Flat profile:
-
- Each sample counts as 0.01 seconds.
- % cumulative self self total
- time seconds seconds calls us/call us/call name
- 30.77 0.13 0.04 6335 6.31 6.31 ct_init
-
-
- Call graph (explanation follows)
-
-
- granularity: each sample hit covers 4 byte(s) for 7.69% of 0.13 seconds
-
- index % time self children called name
-
- 0.00 0.00 1/13496 name_too_long
- 0.00 0.00 40/13496 deflate
- 0.00 0.00 128/13496 deflate_fast
- 0.00 0.00 13327/13496 ct_init
- [7] 0.0 0.00 0.00 13496 init_block
-
- Now let's look at some of `gprof''s output from the same program run,
-this time with line-by-line profiling enabled. Note that `ct_init''s
-four histogram hits are broken down into four lines of source code--one
-hit occurred on each of lines 349, 351, 382 and 385. In the call graph,
-note how `ct_init''s 13327 calls to `init_block' are broken down into
-one call from line 396, 3071 calls from line 384, 3730 calls from line
-385, and 6525 calls from 387.
-
- Flat profile:
-
- Each sample counts as 0.01 seconds.
- % cumulative self
- time seconds seconds calls name
- 7.69 0.10 0.01 ct_init (trees.c:349)
- 7.69 0.11 0.01 ct_init (trees.c:351)
- 7.69 0.12 0.01 ct_init (trees.c:382)
- 7.69 0.13 0.01 ct_init (trees.c:385)
-
-
- Call graph (explanation follows)
-
-
- granularity: each sample hit covers 4 byte(s) for 7.69% of 0.13 seconds
-
- % time self children called name
-
- 0.00 0.00 1/13496 name_too_long (gzip.c:1440)
- 0.00 0.00 1/13496 deflate (deflate.c:763)
- 0.00 0.00 1/13496 ct_init (trees.c:396)
- 0.00 0.00 2/13496 deflate (deflate.c:727)
- 0.00 0.00 4/13496 deflate (deflate.c:686)
- 0.00 0.00 5/13496 deflate (deflate.c:675)
- 0.00 0.00 12/13496 deflate (deflate.c:679)
- 0.00 0.00 16/13496 deflate (deflate.c:730)
- 0.00 0.00 128/13496 deflate_fast (deflate.c:654)
- 0.00 0.00 3071/13496 ct_init (trees.c:384)
- 0.00 0.00 3730/13496 ct_init (trees.c:385)
- 0.00 0.00 6525/13496 ct_init (trees.c:387)
- [6] 0.0 0.00 0.00 13496 init_block (trees.c:408)
-
-
-File: gprof.info, Node: Annotated Source, Prev: Line-by-line, Up: Output
-
-5.4 The Annotated Source Listing
-================================
-
-`gprof''s `-A' option triggers an annotated source listing, which lists
-the program's source code, each function labeled with the number of
-times it was called. You may also need to specify the `-I' option, if
-`gprof' can't find the source code files.
-
- With older versions of `gcc' compiling with `gcc ... -g -pg -a'
-augments your program with basic-block counting code, in addition to
-function counting code. This enables `gprof' to determine how many
-times each line of code was executed. With newer versions of `gcc'
-support for displaying basic-block counts is provided by the `gcov'
-program.
-
- For example, consider the following function, taken from gzip, with
-line numbers added:
-
- 1 ulg updcrc(s, n)
- 2 uch *s;
- 3 unsigned n;
- 4 {
- 5 register ulg c;
- 6
- 7 static ulg crc = (ulg)0xffffffffL;
- 8
- 9 if (s == NULL) {
- 10 c = 0xffffffffL;
- 11 } else {
- 12 c = crc;
- 13 if (n) do {
- 14 c = crc_32_tab[...];
- 15 } while (--n);
- 16 }
- 17 crc = c;
- 18 return c ^ 0xffffffffL;
- 19 }
-
- `updcrc' has at least five basic-blocks. One is the function
-itself. The `if' statement on line 9 generates two more basic-blocks,
-one for each branch of the `if'. A fourth basic-block results from the
-`if' on line 13, and the contents of the `do' loop form the fifth
-basic-block. The compiler may also generate additional basic-blocks to
-handle various special cases.
-
- A program augmented for basic-block counting can be analyzed with
-`gprof -l -A'. The `-x' option is also helpful, to ensure that each
-line of code is labeled at least once. Here is `updcrc''s annotated
-source listing for a sample `gzip' run:
-
- ulg updcrc(s, n)
- uch *s;
- unsigned n;
- 2 ->{
- register ulg c;
-
- static ulg crc = (ulg)0xffffffffL;
-
- 2 -> if (s == NULL) {
- 1 -> c = 0xffffffffL;
- 1 -> } else {
- 1 -> c = crc;
- 1 -> if (n) do {
- 26312 -> c = crc_32_tab[...];
- 26312,1,26311 -> } while (--n);
- }
- 2 -> crc = c;
- 2 -> return c ^ 0xffffffffL;
- 2 ->}
-
- In this example, the function was called twice, passing once through
-each branch of the `if' statement. The body of the `do' loop was
-executed a total of 26312 times. Note how the `while' statement is
-annotated. It began execution 26312 times, once for each iteration
-through the loop. One of those times (the last time) it exited, while
-it branched back to the beginning of the loop 26311 times.
-
-
-File: gprof.info, Node: Inaccuracy, Next: How do I?, Prev: Output, Up: Top
-
-6 Inaccuracy of `gprof' Output
-******************************
-
-* Menu:
-
-* Sampling Error:: Statistical margins of error
-* Assumptions:: Estimating children times
-
-
-File: gprof.info, Node: Sampling Error, Next: Assumptions, Up: Inaccuracy
-
-6.1 Statistical Sampling Error
-==============================
-
-The run-time figures that `gprof' gives you are based on a sampling
-process, so they are subject to statistical inaccuracy. If a function
-runs only a small amount of time, so that on the average the sampling
-process ought to catch that function in the act only once, there is a
-pretty good chance it will actually find that function zero times, or
-twice.
-
- By contrast, the number-of-calls and basic-block figures are derived
-by counting, not sampling. They are completely accurate and will not
-vary from run to run if your program is deterministic and single
-threaded. In multi-threaded applications, or single threaded
-applications that link with multi-threaded libraries, the counts are
-only deterministic if the counting function is thread-safe. (Note:
-beware that the mcount counting function in glibc is _not_
-thread-safe). *Note Implementation of Profiling: Implementation.
-
- The "sampling period" that is printed at the beginning of the flat
-profile says how often samples are taken. The rule of thumb is that a
-run-time figure is accurate if it is considerably bigger than the
-sampling period.
-
- The actual amount of error can be predicted. For N samples, the
-_expected_ error is the square-root of N. For example, if the sampling
-period is 0.01 seconds and `foo''s run-time is 1 second, N is 100
-samples (1 second/0.01 seconds), sqrt(N) is 10 samples, so the expected
-error in `foo''s run-time is 0.1 seconds (10*0.01 seconds), or ten
-percent of the observed value. Again, if the sampling period is 0.01
-seconds and `bar''s run-time is 100 seconds, N is 10000 samples,
-sqrt(N) is 100 samples, so the expected error in `bar''s run-time is 1
-second, or one percent of the observed value. It is likely to vary
-this much _on the average_ from one profiling run to the next.
-(_Sometimes_ it will vary more.)
-
- This does not mean that a small run-time figure is devoid of
-information. If the program's _total_ run-time is large, a small
-run-time for one function does tell you that that function used an
-insignificant fraction of the whole program's time. Usually this means
-it is not worth optimizing.
-
- One way to get more accuracy is to give your program more (but
-similar) input data so it will take longer. Another way is to combine
-the data from several runs, using the `-s' option of `gprof'. Here is
-how:
-
- 1. Run your program once.
-
- 2. Issue the command `mv gmon.out gmon.sum'.
-
- 3. Run your program again, the same as before.
-
- 4. Merge the new data in `gmon.out' into `gmon.sum' with this command:
-
- gprof -s EXECUTABLE-FILE gmon.out gmon.sum
-
- 5. Repeat the last two steps as often as you wish.
-
- 6. Analyze the cumulative data using this command:
-
- gprof EXECUTABLE-FILE gmon.sum > OUTPUT-FILE
-
-
-File: gprof.info, Node: Assumptions, Prev: Sampling Error, Up: Inaccuracy
-
-6.2 Estimating `children' Times
-===============================
-
-Some of the figures in the call graph are estimates--for example, the
-`children' time values and all the time figures in caller and
-subroutine lines.
-
- There is no direct information about these measurements in the
-profile data itself. Instead, `gprof' estimates them by making an
-assumption about your program that might or might not be true.
-
- The assumption made is that the average time spent in each call to
-any function `foo' is not correlated with who called `foo'. If `foo'
-used 5 seconds in all, and 2/5 of the calls to `foo' came from `a',
-then `foo' contributes 2 seconds to `a''s `children' time, by
-assumption.
-
- This assumption is usually true enough, but for some programs it is
-far from true. Suppose that `foo' returns very quickly when its
-argument is zero; suppose that `a' always passes zero as an argument,
-while other callers of `foo' pass other arguments. In this program,
-all the time spent in `foo' is in the calls from callers other than `a'.
-But `gprof' has no way of knowing this; it will blindly and incorrectly
-charge 2 seconds of time in `foo' to the children of `a'.
-
- We hope some day to put more complete data into `gmon.out', so that
-this assumption is no longer needed, if we can figure out how. For the
-novice, the estimated figures are usually more useful than misleading.
-
-
-File: gprof.info, Node: How do I?, Next: Incompatibilities, Prev: Inaccuracy, Up: Top
-
-7 Answers to Common Questions
-*****************************
-
-How can I get more exact information about hot spots in my program?
- Looking at the per-line call counts only tells part of the story.
- Because `gprof' can only report call times and counts by function,
- the best way to get finer-grained information on where the program
- is spending its time is to re-factor large functions into sequences
- of calls to smaller ones. Beware however that this can introduce
- artificial hot spots since compiling with `-pg' adds a significant
- overhead to function calls. An alternative solution is to use a
- non-intrusive profiler, e.g. oprofile.
-
-How do I find which lines in my program were executed the most times?
- Use the `gcov' program.
-
-How do I find which lines in my program called a particular function?
- Use `gprof -l' and lookup the function in the call graph. The
- callers will be broken down by function and line number.
-
-How do I analyze a program that runs for less than a second?
- Try using a shell script like this one:
-
- for i in `seq 1 100`; do
- fastprog
- mv gmon.out gmon.out.$i
- done
-
- gprof -s fastprog gmon.out.*
-
- gprof fastprog gmon.sum
-
- If your program is completely deterministic, all the call counts
- will be simple multiples of 100 (i.e., a function called once in
- each run will appear with a call count of 100).
-
-
-
-File: gprof.info, Node: Incompatibilities, Next: Details, Prev: How do I?, Up: Top
-
-8 Incompatibilities with Unix `gprof'
-*************************************
-
-GNU `gprof' and Berkeley Unix `gprof' use the same data file
-`gmon.out', and provide essentially the same information. But there
-are a few differences.
-
- * GNU `gprof' uses a new, generalized file format with support for
- basic-block execution counts and non-realtime histograms. A magic
- cookie and version number allows `gprof' to easily identify new
- style files. Old BSD-style files can still be read. *Note
- Profiling Data File Format: File Format.
-
- * For a recursive function, Unix `gprof' lists the function as a
- parent and as a child, with a `calls' field that lists the number
- of recursive calls. GNU `gprof' omits these lines and puts the
- number of recursive calls in the primary line.
-
- * When a function is suppressed from the call graph with `-e', GNU
- `gprof' still lists it as a subroutine of functions that call it.
-
- * GNU `gprof' accepts the `-k' with its argument in the form
- `from/to', instead of `from to'.
-
- * In the annotated source listing, if there are multiple basic
- blocks on the same line, GNU `gprof' prints all of their counts,
- separated by commas.
-
- * The blurbs, field widths, and output formats are different. GNU
- `gprof' prints blurbs after the tables, so that you can see the
- tables without skipping the blurbs.
-
-
-File: gprof.info, Node: Details, Next: GNU Free Documentation License, Prev: Incompatibilities, Up: Top
-
-9 Details of Profiling
-**********************
-
-* Menu:
-
-* Implementation:: How a program collects profiling information
-* File Format:: Format of `gmon.out' files
-* Internals:: `gprof''s internal operation
-* Debugging:: Using `gprof''s `-d' option
-
-
-File: gprof.info, Node: Implementation, Next: File Format, Up: Details
-
-9.1 Implementation of Profiling
-===============================
-
-Profiling works by changing how every function in your program is
-compiled so that when it is called, it will stash away some information
-about where it was called from. From this, the profiler can figure out
-what function called it, and can count how many times it was called.
-This change is made by the compiler when your program is compiled with
-the `-pg' option, which causes every function to call `mcount' (or
-`_mcount', or `__mcount', depending on the OS and compiler) as one of
-its first operations.
-
- The `mcount' routine, included in the profiling library, is
-responsible for recording in an in-memory call graph table both its
-parent routine (the child) and its parent's parent. This is typically
-done by examining the stack frame to find both the address of the
-child, and the return address in the original parent. Since this is a
-very machine-dependent operation, `mcount' itself is typically a short
-assembly-language stub routine that extracts the required information,
-and then calls `__mcount_internal' (a normal C function) with two
-arguments--`frompc' and `selfpc'. `__mcount_internal' is responsible
-for maintaining the in-memory call graph, which records `frompc',
-`selfpc', and the number of times each of these call arcs was traversed.
-
- GCC Version 2 provides a magical function
-(`__builtin_return_address'), which allows a generic `mcount' function
-to extract the required information from the stack frame. However, on
-some architectures, most notably the SPARC, using this builtin can be
-very computationally expensive, and an assembly language version of
-`mcount' is used for performance reasons.
-
- Number-of-calls information for library routines is collected by
-using a special version of the C library. The programs in it are the
-same as in the usual C library, but they were compiled with `-pg'. If
-you link your program with `gcc ... -pg', it automatically uses the
-profiling version of the library.
-
- Profiling also involves watching your program as it runs, and
-keeping a histogram of where the program counter happens to be every
-now and then. Typically the program counter is looked at around 100
-times per second of run time, but the exact frequency may vary from
-system to system.
-
- This is done is one of two ways. Most UNIX-like operating systems
-provide a `profil()' system call, which registers a memory array with
-the kernel, along with a scale factor that determines how the program's
-address space maps into the array. Typical scaling values cause every
-2 to 8 bytes of address space to map into a single array slot. On
-every tick of the system clock (assuming the profiled program is
-running), the value of the program counter is examined and the
-corresponding slot in the memory array is incremented. Since this is
-done in the kernel, which had to interrupt the process anyway to handle
-the clock interrupt, very little additional system overhead is required.
-
- However, some operating systems, most notably Linux 2.0 (and
-earlier), do not provide a `profil()' system call. On such a system,
-arrangements are made for the kernel to periodically deliver a signal
-to the process (typically via `setitimer()'), which then performs the
-same operation of examining the program counter and incrementing a slot
-in the memory array. Since this method requires a signal to be
-delivered to user space every time a sample is taken, it uses
-considerably more overhead than kernel-based profiling. Also, due to
-the added delay required to deliver the signal, this method is less
-accurate as well.
-
- A special startup routine allocates memory for the histogram and
-either calls `profil()' or sets up a clock signal handler. This
-routine (`monstartup') can be invoked in several ways. On Linux
-systems, a special profiling startup file `gcrt0.o', which invokes
-`monstartup' before `main', is used instead of the default `crt0.o'.
-Use of this special startup file is one of the effects of using `gcc
-... -pg' to link. On SPARC systems, no special startup files are used.
-Rather, the `mcount' routine, when it is invoked for the first time
-(typically when `main' is called), calls `monstartup'.
-
- If the compiler's `-a' option was used, basic-block counting is also
-enabled. Each object file is then compiled with a static array of
-counts, initially zero. In the executable code, every time a new
-basic-block begins (i.e., when an `if' statement appears), an extra
-instruction is inserted to increment the corresponding count in the
-array. At compile time, a paired array was constructed that recorded
-the starting address of each basic-block. Taken together, the two
-arrays record the starting address of every basic-block, along with the
-number of times it was executed.
-
- The profiling library also includes a function (`mcleanup') which is
-typically registered using `atexit()' to be called as the program
-exits, and is responsible for writing the file `gmon.out'. Profiling
-is turned off, various headers are output, and the histogram is
-written, followed by the call-graph arcs and the basic-block counts.
-
- The output from `gprof' gives no indication of parts of your program
-that are limited by I/O or swapping bandwidth. This is because samples
-of the program counter are taken at fixed intervals of the program's
-run time. Therefore, the time measurements in `gprof' output say
-nothing about time that your program was not running. For example, a
-part of the program that creates so much data that it cannot all fit in
-physical memory at once may run very slowly due to thrashing, but
-`gprof' will say it uses little time. On the other hand, sampling by
-run time has the advantage that the amount of load due to other users
-won't directly affect the output you get.
-
-
-File: gprof.info, Node: File Format, Next: Internals, Prev: Implementation, Up: Details
-
-9.2 Profiling Data File Format
-==============================
-
-The old BSD-derived file format used for profile data does not contain a
-magic cookie that allows to check whether a data file really is a
-`gprof' file. Furthermore, it does not provide a version number, thus
-rendering changes to the file format almost impossible. GNU `gprof'
-uses a new file format that provides these features. For backward
-compatibility, GNU `gprof' continues to support the old BSD-derived
-format, but not all features are supported with it. For example,
-basic-block execution counts cannot be accommodated by the old file
-format.
-
- The new file format is defined in header file `gmon_out.h'. It
-consists of a header containing the magic cookie and a version number,
-as well as some spare bytes available for future extensions. All data
-in a profile data file is in the native format of the target for which
-the profile was collected. GNU `gprof' adapts automatically to the
-byte-order in use.
-
- In the new file format, the header is followed by a sequence of
-records. Currently, there are three different record types: histogram
-records, call-graph arc records, and basic-block execution count
-records. Each file can contain any number of each record type. When
-reading a file, GNU `gprof' will ensure records of the same type are
-compatible with each other and compute the union of all records. For
-example, for basic-block execution counts, the union is simply the sum
-of all execution counts for each basic-block.
-
-9.2.1 Histogram Records
------------------------
-
-Histogram records consist of a header that is followed by an array of
-bins. The header contains the text-segment range that the histogram
-spans, the size of the histogram in bytes (unlike in the old BSD
-format, this does not include the size of the header), the rate of the
-profiling clock, and the physical dimension that the bin counts
-represent after being scaled by the profiling clock rate. The physical
-dimension is specified in two parts: a long name of up to 15 characters
-and a single character abbreviation. For example, a histogram
-representing real-time would specify the long name as "seconds" and the
-abbreviation as "s". This feature is useful for architectures that
-support performance monitor hardware (which, fortunately, is becoming
-increasingly common). For example, under DEC OSF/1, the "uprofile"
-command can be used to produce a histogram of, say, instruction cache
-misses. In this case, the dimension in the histogram header could be
-set to "i-cache misses" and the abbreviation could be set to "1"
-(because it is simply a count, not a physical dimension). Also, the
-profiling rate would have to be set to 1 in this case.
-
- Histogram bins are 16-bit numbers and each bin represent an equal
-amount of text-space. For example, if the text-segment is one thousand
-bytes long and if there are ten bins in the histogram, each bin
-represents one hundred bytes.
-
-9.2.2 Call-Graph Records
-------------------------
-
-Call-graph records have a format that is identical to the one used in
-the BSD-derived file format. It consists of an arc in the call graph
-and a count indicating the number of times the arc was traversed during
-program execution. Arcs are specified by a pair of addresses: the
-first must be within caller's function and the second must be within
-the callee's function. When performing profiling at the function
-level, these addresses can point anywhere within the respective
-function. However, when profiling at the line-level, it is better if
-the addresses are as close to the call-site/entry-point as possible.
-This will ensure that the line-level call-graph is able to identify
-exactly which line of source code performed calls to a function.
-
-9.2.3 Basic-Block Execution Count Records
------------------------------------------
-
-Basic-block execution count records consist of a header followed by a
-sequence of address/count pairs. The header simply specifies the
-length of the sequence. In an address/count pair, the address
-identifies a basic-block and the count specifies the number of times
-that basic-block was executed. Any address within the basic-address can
-be used.
-
-
-File: gprof.info, Node: Internals, Next: Debugging, Prev: File Format, Up: Details
-
-9.3 `gprof''s Internal Operation
-================================
-
-Like most programs, `gprof' begins by processing its options. During
-this stage, it may building its symspec list (`sym_ids.c:sym_id_add'),
-if options are specified which use symspecs. `gprof' maintains a
-single linked list of symspecs, which will eventually get turned into
-12 symbol tables, organized into six include/exclude pairs--one pair
-each for the flat profile (INCL_FLAT/EXCL_FLAT), the call graph arcs
-(INCL_ARCS/EXCL_ARCS), printing in the call graph
-(INCL_GRAPH/EXCL_GRAPH), timing propagation in the call graph
-(INCL_TIME/EXCL_TIME), the annotated source listing
-(INCL_ANNO/EXCL_ANNO), and the execution count listing
-(INCL_EXEC/EXCL_EXEC).
-
- After option processing, `gprof' finishes building the symspec list
-by adding all the symspecs in `default_excluded_list' to the exclude
-lists EXCL_TIME and EXCL_GRAPH, and if line-by-line profiling is
-specified, EXCL_FLAT as well. These default excludes are not added to
-EXCL_ANNO, EXCL_ARCS, and EXCL_EXEC.
-
- Next, the BFD library is called to open the object file, verify that
-it is an object file, and read its symbol table (`core.c:core_init'),
-using `bfd_canonicalize_symtab' after mallocing an appropriately sized
-array of symbols. At this point, function mappings are read (if the
-`--file-ordering' option has been specified), and the core text space
-is read into memory (if the `-c' option was given).
-
- `gprof''s own symbol table, an array of Sym structures, is now built.
-This is done in one of two ways, by one of two routines, depending on
-whether line-by-line profiling (`-l' option) has been enabled. For
-normal profiling, the BFD canonical symbol table is scanned. For
-line-by-line profiling, every text space address is examined, and a new
-symbol table entry gets created every time the line number changes. In
-either case, two passes are made through the symbol table--one to count
-the size of the symbol table required, and the other to actually read
-the symbols. In between the two passes, a single array of type `Sym'
-is created of the appropriate length. Finally,
-`symtab.c:symtab_finalize' is called to sort the symbol table and
-remove duplicate entries (entries with the same memory address).
-
- The symbol table must be a contiguous array for two reasons. First,
-the `qsort' library function (which sorts an array) will be used to
-sort the symbol table. Also, the symbol lookup routine
-(`symtab.c:sym_lookup'), which finds symbols based on memory address,
-uses a binary search algorithm which requires the symbol table to be a
-sorted array. Function symbols are indicated with an `is_func' flag.
-Line number symbols have no special flags set. Additionally, a symbol
-can have an `is_static' flag to indicate that it is a local symbol.
-
- With the symbol table read, the symspecs can now be translated into
-Syms (`sym_ids.c:sym_id_parse'). Remember that a single symspec can
-match multiple symbols. An array of symbol tables (`syms') is created,
-each entry of which is a symbol table of Syms to be included or
-excluded from a particular listing. The master symbol table and the
-symspecs are examined by nested loops, and every symbol that matches a
-symspec is inserted into the appropriate syms table. This is done
-twice, once to count the size of each required symbol table, and again
-to build the tables, which have been malloced between passes. From now
-on, to determine whether a symbol is on an include or exclude symspec
-list, `gprof' simply uses its standard symbol lookup routine on the
-appropriate table in the `syms' array.
-
- Now the profile data file(s) themselves are read
-(`gmon_io.c:gmon_out_read'), first by checking for a new-style
-`gmon.out' header, then assuming this is an old-style BSD `gmon.out' if
-the magic number test failed.
-
- New-style histogram records are read by `hist.c:hist_read_rec'. For
-the first histogram record, allocate a memory array to hold all the
-bins, and read them in. When multiple profile data files (or files
-with multiple histogram records) are read, the memory ranges of each
-pair of histogram records must be either equal, or non-overlapping.
-For each pair of histogram records, the resolution (memory region size
-divided by the number of bins) must be the same. The time unit must be
-the same for all histogram records. If the above containts are met, all
-histograms for the same memory range are merged.
-
- As each call graph record is read (`call_graph.c:cg_read_rec'), the
-parent and child addresses are matched to symbol table entries, and a
-call graph arc is created by `cg_arcs.c:arc_add', unless the arc fails
-a symspec check against INCL_ARCS/EXCL_ARCS. As each arc is added, a
-linked list is maintained of the parent's child arcs, and of the child's
-parent arcs. Both the child's call count and the arc's call count are
-incremented by the record's call count.
-
- Basic-block records are read (`basic_blocks.c:bb_read_rec'), but
-only if line-by-line profiling has been selected. Each basic-block
-address is matched to a corresponding line symbol in the symbol table,
-and an entry made in the symbol's bb_addr and bb_calls arrays. Again,
-if multiple basic-block records are present for the same address, the
-call counts are cumulative.
-
- A gmon.sum file is dumped, if requested (`gmon_io.c:gmon_out_write').
-
- If histograms were present in the data files, assign them to symbols
-(`hist.c:hist_assign_samples') by iterating over all the sample bins
-and assigning them to symbols. Since the symbol table is sorted in
-order of ascending memory addresses, we can simple follow along in the
-symbol table as we make our pass over the sample bins. This step
-includes a symspec check against INCL_FLAT/EXCL_FLAT. Depending on the
-histogram scale factor, a sample bin may span multiple symbols, in
-which case a fraction of the sample count is allocated to each symbol,
-proportional to the degree of overlap. This effect is rare for normal
-profiling, but overlaps are more common during line-by-line profiling,
-and can cause each of two adjacent lines to be credited with half a
-hit, for example.
-
- If call graph data is present, `cg_arcs.c:cg_assemble' is called.
-First, if `-c' was specified, a machine-dependent routine (`find_call')
-scans through each symbol's machine code, looking for subroutine call
-instructions, and adding them to the call graph with a zero call count.
-A topological sort is performed by depth-first numbering all the
-symbols (`cg_dfn.c:cg_dfn'), so that children are always numbered less
-than their parents, then making a array of pointers into the symbol
-table and sorting it into numerical order, which is reverse topological
-order (children appear before parents). Cycles are also detected at
-this point, all members of which are assigned the same topological
-number. Two passes are now made through this sorted array of symbol
-pointers. The first pass, from end to beginning (parents to children),
-computes the fraction of child time to propagate to each parent and a
-print flag. The print flag reflects symspec handling of
-INCL_GRAPH/EXCL_GRAPH, with a parent's include or exclude (print or no
-print) property being propagated to its children, unless they
-themselves explicitly appear in INCL_GRAPH or EXCL_GRAPH. A second
-pass, from beginning to end (children to parents) actually propagates
-the timings along the call graph, subject to a check against
-INCL_TIME/EXCL_TIME. With the print flag, fractions, and timings now
-stored in the symbol structures, the topological sort array is now
-discarded, and a new array of pointers is assembled, this time sorted
-by propagated time.
-
- Finally, print the various outputs the user requested, which is now
-fairly straightforward. The call graph (`cg_print.c:cg_print') and
-flat profile (`hist.c:hist_print') are regurgitations of values already
-computed. The annotated source listing
-(`basic_blocks.c:print_annotated_source') uses basic-block information,
-if present, to label each line of code with call counts, otherwise only
-the function call counts are presented.
-
- The function ordering code is marginally well documented in the
-source code itself (`cg_print.c'). Basically, the functions with the
-most use and the most parents are placed first, followed by other
-functions with the most use, followed by lower use functions, followed
-by unused functions at the end.
-
-
-File: gprof.info, Node: Debugging, Prev: Internals, Up: Details
-
-9.4 Debugging `gprof'
-=====================
-
-If `gprof' was compiled with debugging enabled, the `-d' option
-triggers debugging output (to stdout) which can be helpful in
-understanding its operation. The debugging number specified is
-interpreted as a sum of the following options:
-
-2 - Topological sort
- Monitor depth-first numbering of symbols during call graph analysis
-
-4 - Cycles
- Shows symbols as they are identified as cycle heads
-
-16 - Tallying
- As the call graph arcs are read, show each arc and how the total
- calls to each function are tallied
-
-32 - Call graph arc sorting
- Details sorting individual parents/children within each call graph
- entry
-
-64 - Reading histogram and call graph records
- Shows address ranges of histograms as they are read, and each call
- graph arc
-
-128 - Symbol table
- Reading, classifying, and sorting the symbol table from the object
- file. For line-by-line profiling (`-l' option), also shows line
- numbers being assigned to memory addresses.
-
-256 - Static call graph
- Trace operation of `-c' option
-
-512 - Symbol table and arc table lookups
- Detail operation of lookup routines
-
-1024 - Call graph propagation
- Shows how function times are propagated along the call graph
-
-2048 - Basic-blocks
- Shows basic-block records as they are read from profile data (only
- meaningful with `-l' option)
-
-4096 - Symspecs
- Shows symspec-to-symbol pattern matching operation
-
-8192 - Annotate source
- Tracks operation of `-A' option
-
-
-File: gprof.info, Node: GNU Free Documentation License, Prev: Details, Up: Top
-
-Appendix A GNU Free Documentation License
-*****************************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-
-Tag Table:
-Node: Top858
-Node: Introduction2181
-Node: Compiling4673
-Node: Executing8729
-Node: Invoking11517
-Node: Output Options12932
-Node: Analysis Options20021
-Node: Miscellaneous Options23719
-Node: Deprecated Options24974
-Node: Symspecs27043
-Node: Output28869
-Node: Flat Profile29909
-Node: Call Graph34862
-Node: Primary38094
-Node: Callers40682
-Node: Subroutines42799
-Node: Cycles44640
-Node: Line-by-line51417
-Node: Annotated Source55490
-Node: Inaccuracy58489
-Node: Sampling Error58747
-Node: Assumptions61651
-Node: How do I?63121
-Node: Incompatibilities64675
-Node: Details66169
-Node: Implementation66562
-Node: File Format72459
-Node: Internals76749
-Node: Debugging85244
-Node: GNU Free Documentation License86845
-
-End Tag Table
diff --git a/share/info/ld.info b/share/info/ld.info
deleted file mode 100644
index 5e1991e..0000000
--- a/share/info/ld.info
+++ /dev/null
@@ -1,7877 +0,0 @@
-This is ld.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../binutils/binutils-2.21/ld/ld.texinfo.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* Ld: (ld). The GNU linker.
-END-INFO-DIR-ENTRY
-
- This file documents the GNU linker LD (GNU Binutils) version 2.21.
-
- Copyright (C) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free
-Software Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
-
-File: ld.info, Node: Top, Next: Overview, Up: (dir)
-
-LD
-**
-
-This file documents the GNU linker ld (GNU Binutils) version 2.21.
-
- This document is distributed under the terms of the GNU Free
-Documentation License version 1.3. A copy of the license is included
-in the section entitled "GNU Free Documentation License".
-
-* Menu:
-
-* Overview:: Overview
-* Invocation:: Invocation
-* Scripts:: Linker Scripts
-
-* Machine Dependent:: Machine Dependent Features
-
-* BFD:: BFD
-
-* Reporting Bugs:: Reporting Bugs
-* MRI:: MRI Compatible Script Files
-* GNU Free Documentation License:: GNU Free Documentation License
-* LD Index:: LD Index
-
-
-File: ld.info, Node: Overview, Next: Invocation, Prev: Top, Up: Top
-
-1 Overview
-**********
-
-`ld' combines a number of object and archive files, relocates their
-data and ties up symbol references. Usually the last step in compiling
-a program is to run `ld'.
-
- `ld' accepts Linker Command Language files written in a superset of
-AT&T's Link Editor Command Language syntax, to provide explicit and
-total control over the linking process.
-
- This version of `ld' uses the general purpose BFD libraries to
-operate on object files. This allows `ld' to read, combine, and write
-object files in many different formats--for example, COFF or `a.out'.
-Different formats may be linked together to produce any available kind
-of object file. *Note BFD::, for more information.
-
- Aside from its flexibility, the GNU linker is more helpful than other
-linkers in providing diagnostic information. Many linkers abandon
-execution immediately upon encountering an error; whenever possible,
-`ld' continues executing, allowing you to identify other errors (or, in
-some cases, to get an output file in spite of the error).
-
-
-File: ld.info, Node: Invocation, Next: Scripts, Prev: Overview, Up: Top
-
-2 Invocation
-************
-
-The GNU linker `ld' is meant to cover a broad range of situations, and
-to be as compatible as possible with other linkers. As a result, you
-have many choices to control its behavior.
-
-* Menu:
-
-* Options:: Command Line Options
-* Environment:: Environment Variables
-
-
-File: ld.info, Node: Options, Next: Environment, Up: Invocation
-
-2.1 Command Line Options
-========================
-
- The linker supports a plethora of command-line options, but in actual
-practice few of them are used in any particular context. For instance,
-a frequent use of `ld' is to link standard Unix object files on a
-standard, supported Unix system. On such a system, to link a file
-`hello.o':
-
- ld -o OUTPUT /lib/crt0.o hello.o -lc
-
- This tells `ld' to produce a file called OUTPUT as the result of
-linking the file `/lib/crt0.o' with `hello.o' and the library `libc.a',
-which will come from the standard search directories. (See the
-discussion of the `-l' option below.)
-
- Some of the command-line options to `ld' may be specified at any
-point in the command line. However, options which refer to files, such
-as `-l' or `-T', cause the file to be read at the point at which the
-option appears in the command line, relative to the object files and
-other file options. Repeating non-file options with a different
-argument will either have no further effect, or override prior
-occurrences (those further to the left on the command line) of that
-option. Options which may be meaningfully specified more than once are
-noted in the descriptions below.
-
- Non-option arguments are object files or archives which are to be
-linked together. They may follow, precede, or be mixed in with
-command-line options, except that an object file argument may not be
-placed between an option and its argument.
-
- Usually the linker is invoked with at least one object file, but you
-can specify other forms of binary input files using `-l', `-R', and the
-script command language. If _no_ binary input files at all are
-specified, the linker does not produce any output, and issues the
-message `No input files'.
-
- If the linker cannot recognize the format of an object file, it will
-assume that it is a linker script. A script specified in this way
-augments the main linker script used for the link (either the default
-linker script or the one specified by using `-T'). This feature
-permits the linker to link against a file which appears to be an object
-or an archive, but actually merely defines some symbol values, or uses
-`INPUT' or `GROUP' to load other objects. Specifying a script in this
-way merely augments the main linker script, with the extra commands
-placed after the main script; use the `-T' option to replace the
-default linker script entirely, but note the effect of the `INSERT'
-command. *Note Scripts::.
-
- For options whose names are a single letter, option arguments must
-either follow the option letter without intervening whitespace, or be
-given as separate arguments immediately following the option that
-requires them.
-
- For options whose names are multiple letters, either one dash or two
-can precede the option name; for example, `-trace-symbol' and
-`--trace-symbol' are equivalent. Note--there is one exception to this
-rule. Multiple letter options that start with a lower case 'o' can
-only be preceded by two dashes. This is to reduce confusion with the
-`-o' option. So for example `-omagic' sets the output file name to
-`magic' whereas `--omagic' sets the NMAGIC flag on the output.
-
- Arguments to multiple-letter options must either be separated from
-the option name by an equals sign, or be given as separate arguments
-immediately following the option that requires them. For example,
-`--trace-symbol foo' and `--trace-symbol=foo' are equivalent. Unique
-abbreviations of the names of multiple-letter options are accepted.
-
- Note--if the linker is being invoked indirectly, via a compiler
-driver (e.g. `gcc') then all the linker command line options should be
-prefixed by `-Wl,' (or whatever is appropriate for the particular
-compiler driver) like this:
-
- gcc -Wl,--start-group foo.o bar.o -Wl,--end-group
-
- This is important, because otherwise the compiler driver program may
-silently drop the linker options, resulting in a bad link. Confusion
-may also arise when passing options that require values through a
-driver, as the use of a space between option and argument acts as a
-separator, and causes the driver to pass only the option to the linker
-and the argument to the compiler. In this case, it is simplest to use
-the joined forms of both single- and multiple-letter options, such as:
-
- gcc foo.o bar.o -Wl,-eENTRY -Wl,-Map=a.map
-
- Here is a table of the generic command line switches accepted by the
-GNU linker:
-
-`@FILE'
- Read command-line options from FILE. The options read are
- inserted in place of the original @FILE option. If FILE does not
- exist, or cannot be read, then the option will be treated
- literally, and not removed.
-
- Options in FILE are separated by whitespace. A whitespace
- character may be included in an option by surrounding the entire
- option in either single or double quotes. Any character
- (including a backslash) may be included by prefixing the character
- to be included with a backslash. The FILE may itself contain
- additional @FILE options; any such options will be processed
- recursively.
-
-`-a KEYWORD'
- This option is supported for HP/UX compatibility. The KEYWORD
- argument must be one of the strings `archive', `shared', or
- `default'. `-aarchive' is functionally equivalent to `-Bstatic',
- and the other two keywords are functionally equivalent to
- `-Bdynamic'. This option may be used any number of times.
-
-`--audit AUDITLIB'
- Adds AUDITLIB to the `DT_AUDIT' entry of the dynamic section.
- AUDITLIB is not checked for existence, nor will it use the
- DT_SONAME specified in the library. If specified multiple times
- `DT_AUDIT' will contain a colon separated list of audit interfaces
- to use. If the linker finds an object with an audit entry while
- searching for shared libraries, it will add a corresponding
- `DT_DEPAUDIT' entry in the output file. This option is only
- meaningful on ELF platforms supporting the rtld-audit interface.
-
-`-A ARCHITECTURE'
-`--architecture=ARCHITECTURE'
- In the current release of `ld', this option is useful only for the
- Intel 960 family of architectures. In that `ld' configuration, the
- ARCHITECTURE argument identifies the particular architecture in
- the 960 family, enabling some safeguards and modifying the
- archive-library search path. *Note `ld' and the Intel 960 family:
- i960, for details.
-
- Future releases of `ld' may support similar functionality for
- other architecture families.
-
-`-b INPUT-FORMAT'
-`--format=INPUT-FORMAT'
- `ld' may be configured to support more than one kind of object
- file. If your `ld' is configured this way, you can use the `-b'
- option to specify the binary format for input object files that
- follow this option on the command line. Even when `ld' is
- configured to support alternative object formats, you don't
- usually need to specify this, as `ld' should be configured to
- expect as a default input format the most usual format on each
- machine. INPUT-FORMAT is a text string, the name of a particular
- format supported by the BFD libraries. (You can list the
- available binary formats with `objdump -i'.) *Note BFD::.
-
- You may want to use this option if you are linking files with an
- unusual binary format. You can also use `-b' to switch formats
- explicitly (when linking object files of different formats), by
- including `-b INPUT-FORMAT' before each group of object files in a
- particular format.
-
- The default format is taken from the environment variable
- `GNUTARGET'. *Note Environment::. You can also define the input
- format from a script, using the command `TARGET'; see *note Format
- Commands::.
-
-`-c MRI-COMMANDFILE'
-`--mri-script=MRI-COMMANDFILE'
- For compatibility with linkers produced by MRI, `ld' accepts script
- files written in an alternate, restricted command language,
- described in *note MRI Compatible Script Files: MRI. Introduce
- MRI script files with the option `-c'; use the `-T' option to run
- linker scripts written in the general-purpose `ld' scripting
- language. If MRI-CMDFILE does not exist, `ld' looks for it in the
- directories specified by any `-L' options.
-
-`-d'
-`-dc'
-`-dp'
- These three options are equivalent; multiple forms are supported
- for compatibility with other linkers. They assign space to common
- symbols even if a relocatable output file is specified (with
- `-r'). The script command `FORCE_COMMON_ALLOCATION' has the same
- effect. *Note Miscellaneous Commands::.
-
-`--depaudit AUDITLIB'
-`-P AUDITLIB'
- Adds AUDITLIB to the `DT_DEPAUDIT' entry of the dynamic section.
- AUDITLIB is not checked for existence, nor will it use the
- DT_SONAME specified in the library. If specified multiple times
- `DT_DEPAUDIT' will contain a colon separated list of audit
- interfaces to use. This option is only meaningful on ELF
- platforms supporting the rtld-audit interface. The -P option is
- provided for Solaris compatibility.
-
-`-e ENTRY'
-`--entry=ENTRY'
- Use ENTRY as the explicit symbol for beginning execution of your
- program, rather than the default entry point. If there is no
- symbol named ENTRY, the linker will try to parse ENTRY as a number,
- and use that as the entry address (the number will be interpreted
- in base 10; you may use a leading `0x' for base 16, or a leading
- `0' for base 8). *Note Entry Point::, for a discussion of defaults
- and other ways of specifying the entry point.
-
-`--exclude-libs LIB,LIB,...'
- Specifies a list of archive libraries from which symbols should
- not be automatically exported. The library names may be delimited
- by commas or colons. Specifying `--exclude-libs ALL' excludes
- symbols in all archive libraries from automatic export. This
- option is available only for the i386 PE targeted port of the
- linker and for ELF targeted ports. For i386 PE, symbols
- explicitly listed in a .def file are still exported, regardless of
- this option. For ELF targeted ports, symbols affected by this
- option will be treated as hidden.
-
-`--exclude-modules-for-implib MODULE,MODULE,...'
- Specifies a list of object files or archive members, from which
- symbols should not be automatically exported, but which should be
- copied wholesale into the import library being generated during
- the link. The module names may be delimited by commas or colons,
- and must match exactly the filenames used by `ld' to open the
- files; for archive members, this is simply the member name, but
- for object files the name listed must include and match precisely
- any path used to specify the input file on the linker's
- command-line. This option is available only for the i386 PE
- targeted port of the linker. Symbols explicitly listed in a .def
- file are still exported, regardless of this option.
-
-`-E'
-`--export-dynamic'
-`--no-export-dynamic'
- When creating a dynamically linked executable, using the `-E'
- option or the `--export-dynamic' option causes the linker to add
- all symbols to the dynamic symbol table. The dynamic symbol table
- is the set of symbols which are visible from dynamic objects at
- run time.
-
- If you do not use either of these options (or use the
- `--no-export-dynamic' option to restore the default behavior), the
- dynamic symbol table will normally contain only those symbols
- which are referenced by some dynamic object mentioned in the link.
-
- If you use `dlopen' to load a dynamic object which needs to refer
- back to the symbols defined by the program, rather than some other
- dynamic object, then you will probably need to use this option when
- linking the program itself.
-
- You can also use the dynamic list to control what symbols should
- be added to the dynamic symbol table if the output format supports
- it. See the description of `--dynamic-list'.
-
- Note that this option is specific to ELF targeted ports. PE
- targets support a similar function to export all symbols from a
- DLL or EXE; see the description of `--export-all-symbols' below.
-
-`-EB'
- Link big-endian objects. This affects the default output format.
-
-`-EL'
- Link little-endian objects. This affects the default output
- format.
-
-`-f NAME'
-`--auxiliary=NAME'
- When creating an ELF shared object, set the internal DT_AUXILIARY
- field to the specified name. This tells the dynamic linker that
- the symbol table of the shared object should be used as an
- auxiliary filter on the symbol table of the shared object NAME.
-
- If you later link a program against this filter object, then, when
- you run the program, the dynamic linker will see the DT_AUXILIARY
- field. If the dynamic linker resolves any symbols from the filter
- object, it will first check whether there is a definition in the
- shared object NAME. If there is one, it will be used instead of
- the definition in the filter object. The shared object NAME need
- not exist. Thus the shared object NAME may be used to provide an
- alternative implementation of certain functions, perhaps for
- debugging or for machine specific performance.
-
- This option may be specified more than once. The DT_AUXILIARY
- entries will be created in the order in which they appear on the
- command line.
-
-`-F NAME'
-`--filter=NAME'
- When creating an ELF shared object, set the internal DT_FILTER
- field to the specified name. This tells the dynamic linker that
- the symbol table of the shared object which is being created
- should be used as a filter on the symbol table of the shared
- object NAME.
-
- If you later link a program against this filter object, then, when
- you run the program, the dynamic linker will see the DT_FILTER
- field. The dynamic linker will resolve symbols according to the
- symbol table of the filter object as usual, but it will actually
- link to the definitions found in the shared object NAME. Thus the
- filter object can be used to select a subset of the symbols
- provided by the object NAME.
-
- Some older linkers used the `-F' option throughout a compilation
- toolchain for specifying object-file format for both input and
- output object files. The GNU linker uses other mechanisms for
- this purpose: the `-b', `--format', `--oformat' options, the
- `TARGET' command in linker scripts, and the `GNUTARGET'
- environment variable. The GNU linker will ignore the `-F' option
- when not creating an ELF shared object.
-
-`-fini=NAME'
- When creating an ELF executable or shared object, call NAME when
- the executable or shared object is unloaded, by setting DT_FINI to
- the address of the function. By default, the linker uses `_fini'
- as the function to call.
-
-`-g'
- Ignored. Provided for compatibility with other tools.
-
-`-G VALUE'
-`--gpsize=VALUE'
- Set the maximum size of objects to be optimized using the GP
- register to SIZE. This is only meaningful for object file formats
- such as MIPS ECOFF which supports putting large and small objects
- into different sections. This is ignored for other object file
- formats.
-
-`-h NAME'
-`-soname=NAME'
- When creating an ELF shared object, set the internal DT_SONAME
- field to the specified name. When an executable is linked with a
- shared object which has a DT_SONAME field, then when the
- executable is run the dynamic linker will attempt to load the
- shared object specified by the DT_SONAME field rather than the
- using the file name given to the linker.
-
-`-i'
- Perform an incremental link (same as option `-r').
-
-`-init=NAME'
- When creating an ELF executable or shared object, call NAME when
- the executable or shared object is loaded, by setting DT_INIT to
- the address of the function. By default, the linker uses `_init'
- as the function to call.
-
-`-l NAMESPEC'
-`--library=NAMESPEC'
- Add the archive or object file specified by NAMESPEC to the list
- of files to link. This option may be used any number of times.
- If NAMESPEC is of the form `:FILENAME', `ld' will search the
- library path for a file called FILENAME, otherwise it will search
- the library path for a file called `libNAMESPEC.a'.
-
- On systems which support shared libraries, `ld' may also search for
- files other than `libNAMESPEC.a'. Specifically, on ELF and SunOS
- systems, `ld' will search a directory for a library called
- `libNAMESPEC.so' before searching for one called `libNAMESPEC.a'.
- (By convention, a `.so' extension indicates a shared library.)
- Note that this behavior does not apply to `:FILENAME', which
- always specifies a file called FILENAME.
-
- The linker will search an archive only once, at the location where
- it is specified on the command line. If the archive defines a
- symbol which was undefined in some object which appeared before
- the archive on the command line, the linker will include the
- appropriate file(s) from the archive. However, an undefined
- symbol in an object appearing later on the command line will not
- cause the linker to search the archive again.
-
- See the `-(' option for a way to force the linker to search
- archives multiple times.
-
- You may list the same archive multiple times on the command line.
-
- This type of archive searching is standard for Unix linkers.
- However, if you are using `ld' on AIX, note that it is different
- from the behaviour of the AIX linker.
-
-`-L SEARCHDIR'
-`--library-path=SEARCHDIR'
- Add path SEARCHDIR to the list of paths that `ld' will search for
- archive libraries and `ld' control scripts. You may use this
- option any number of times. The directories are searched in the
- order in which they are specified on the command line.
- Directories specified on the command line are searched before the
- default directories. All `-L' options apply to all `-l' options,
- regardless of the order in which the options appear. `-L' options
- do not affect how `ld' searches for a linker script unless `-T'
- option is specified.
-
- If SEARCHDIR begins with `=', then the `=' will be replaced by the
- "sysroot prefix", a path specified when the linker is configured.
-
- The default set of paths searched (without being specified with
- `-L') depends on which emulation mode `ld' is using, and in some
- cases also on how it was configured. *Note Environment::.
-
- The paths can also be specified in a link script with the
- `SEARCH_DIR' command. Directories specified this way are searched
- at the point in which the linker script appears in the command
- line.
-
-`-m EMULATION'
- Emulate the EMULATION linker. You can list the available
- emulations with the `--verbose' or `-V' options.
-
- If the `-m' option is not used, the emulation is taken from the
- `LDEMULATION' environment variable, if that is defined.
-
- Otherwise, the default emulation depends upon how the linker was
- configured.
-
-`-M'
-`--print-map'
- Print a link map to the standard output. A link map provides
- information about the link, including the following:
-
- * Where object files are mapped into memory.
-
- * How common symbols are allocated.
-
- * All archive members included in the link, with a mention of
- the symbol which caused the archive member to be brought in.
-
- * The values assigned to symbols.
-
- Note - symbols whose values are computed by an expression
- which involves a reference to a previous value of the same
- symbol may not have correct result displayed in the link map.
- This is because the linker discards intermediate results and
- only retains the final value of an expression. Under such
- circumstances the linker will display the final value
- enclosed by square brackets. Thus for example a linker
- script containing:
-
- foo = 1
- foo = foo * 4
- foo = foo + 8
-
- will produce the following output in the link map if the `-M'
- option is used:
-
- 0x00000001 foo = 0x1
- [0x0000000c] foo = (foo * 0x4)
- [0x0000000c] foo = (foo + 0x8)
-
- See *note Expressions:: for more information about
- expressions in linker scripts.
-
-`-n'
-`--nmagic'
- Turn off page alignment of sections, and disable linking against
- shared libraries. If the output format supports Unix style magic
- numbers, mark the output as `NMAGIC'.
-
-`-N'
-`--omagic'
- Set the text and data sections to be readable and writable. Also,
- do not page-align the data segment, and disable linking against
- shared libraries. If the output format supports Unix style magic
- numbers, mark the output as `OMAGIC'. Note: Although a writable
- text section is allowed for PE-COFF targets, it does not conform
- to the format specification published by Microsoft.
-
-`--no-omagic'
- This option negates most of the effects of the `-N' option. It
- sets the text section to be read-only, and forces the data segment
- to be page-aligned. Note - this option does not enable linking
- against shared libraries. Use `-Bdynamic' for this.
-
-`-o OUTPUT'
-`--output=OUTPUT'
- Use OUTPUT as the name for the program produced by `ld'; if this
- option is not specified, the name `a.out' is used by default. The
- script command `OUTPUT' can also specify the output file name.
-
-`-O LEVEL'
- If LEVEL is a numeric values greater than zero `ld' optimizes the
- output. This might take significantly longer and therefore
- probably should only be enabled for the final binary. At the
- moment this option only affects ELF shared library generation.
- Future releases of the linker may make more use of this option.
- Also currently there is no difference in the linker's behaviour
- for different non-zero values of this option. Again this may
- change with future releases.
-
-`-q'
-`--emit-relocs'
- Leave relocation sections and contents in fully linked executables.
- Post link analysis and optimization tools may need this
- information in order to perform correct modifications of
- executables. This results in larger executables.
-
- This option is currently only supported on ELF platforms.
-
-`--force-dynamic'
- Force the output file to have dynamic sections. This option is
- specific to VxWorks targets.
-
-`-r'
-`--relocatable'
- Generate relocatable output--i.e., generate an output file that
- can in turn serve as input to `ld'. This is often called "partial
- linking". As a side effect, in environments that support standard
- Unix magic numbers, this option also sets the output file's magic
- number to `OMAGIC'. If this option is not specified, an absolute
- file is produced. When linking C++ programs, this option _will
- not_ resolve references to constructors; to do that, use `-Ur'.
-
- When an input file does not have the same format as the output
- file, partial linking is only supported if that input file does
- not contain any relocations. Different output formats can have
- further restrictions; for example some `a.out'-based formats do
- not support partial linking with input files in other formats at
- all.
-
- This option does the same thing as `-i'.
-
-`-R FILENAME'
-`--just-symbols=FILENAME'
- Read symbol names and their addresses from FILENAME, but do not
- relocate it or include it in the output. This allows your output
- file to refer symbolically to absolute locations of memory defined
- in other programs. You may use this option more than once.
-
- For compatibility with other ELF linkers, if the `-R' option is
- followed by a directory name, rather than a file name, it is
- treated as the `-rpath' option.
-
-`-s'
-`--strip-all'
- Omit all symbol information from the output file.
-
-`-S'
-`--strip-debug'
- Omit debugger symbol information (but not all symbols) from the
- output file.
-
-`-t'
-`--trace'
- Print the names of the input files as `ld' processes them.
-
-`-T SCRIPTFILE'
-`--script=SCRIPTFILE'
- Use SCRIPTFILE as the linker script. This script replaces `ld''s
- default linker script (rather than adding to it), so COMMANDFILE
- must specify everything necessary to describe the output file.
- *Note Scripts::. If SCRIPTFILE does not exist in the current
- directory, `ld' looks for it in the directories specified by any
- preceding `-L' options. Multiple `-T' options accumulate.
-
-`-dT SCRIPTFILE'
-`--default-script=SCRIPTFILE'
- Use SCRIPTFILE as the default linker script. *Note Scripts::.
-
- This option is similar to the `--script' option except that
- processing of the script is delayed until after the rest of the
- command line has been processed. This allows options placed after
- the `--default-script' option on the command line to affect the
- behaviour of the linker script, which can be important when the
- linker command line cannot be directly controlled by the user.
- (eg because the command line is being constructed by another tool,
- such as `gcc').
-
-`-u SYMBOL'
-`--undefined=SYMBOL'
- Force SYMBOL to be entered in the output file as an undefined
- symbol. Doing this may, for example, trigger linking of additional
- modules from standard libraries. `-u' may be repeated with
- different option arguments to enter additional undefined symbols.
- This option is equivalent to the `EXTERN' linker script command.
-
-`-Ur'
- For anything other than C++ programs, this option is equivalent to
- `-r': it generates relocatable output--i.e., an output file that
- can in turn serve as input to `ld'. When linking C++ programs,
- `-Ur' _does_ resolve references to constructors, unlike `-r'. It
- does not work to use `-Ur' on files that were themselves linked
- with `-Ur'; once the constructor table has been built, it cannot
- be added to. Use `-Ur' only for the last partial link, and `-r'
- for the others.
-
-`--unique[=SECTION]'
- Creates a separate output section for every input section matching
- SECTION, or if the optional wildcard SECTION argument is missing,
- for every orphan input section. An orphan section is one not
- specifically mentioned in a linker script. You may use this option
- multiple times on the command line; It prevents the normal
- merging of input sections with the same name, overriding output
- section assignments in a linker script.
-
-`-v'
-`--version'
-`-V'
- Display the version number for `ld'. The `-V' option also lists
- the supported emulations.
-
-`-x'
-`--discard-all'
- Delete all local symbols.
-
-`-X'
-`--discard-locals'
- Delete all temporary local symbols. (These symbols start with
- system-specific local label prefixes, typically `.L' for ELF
- systems or `L' for traditional a.out systems.)
-
-`-y SYMBOL'
-`--trace-symbol=SYMBOL'
- Print the name of each linked file in which SYMBOL appears. This
- option may be given any number of times. On many systems it is
- necessary to prepend an underscore.
-
- This option is useful when you have an undefined symbol in your
- link but don't know where the reference is coming from.
-
-`-Y PATH'
- Add PATH to the default library search path. This option exists
- for Solaris compatibility.
-
-`-z KEYWORD'
- The recognized keywords are:
- `combreloc'
- Combines multiple reloc sections and sorts them to make
- dynamic symbol lookup caching possible.
-
- `defs'
- Disallows undefined symbols in object files. Undefined
- symbols in shared libraries are still allowed.
-
- `execstack'
- Marks the object as requiring executable stack.
-
- `initfirst'
- This option is only meaningful when building a shared object.
- It marks the object so that its runtime initialization will
- occur before the runtime initialization of any other objects
- brought into the process at the same time. Similarly the
- runtime finalization of the object will occur after the
- runtime finalization of any other objects.
-
- `interpose'
- Marks the object that its symbol table interposes before all
- symbols but the primary executable.
-
- `lazy'
- When generating an executable or shared library, mark it to
- tell the dynamic linker to defer function call resolution to
- the point when the function is called (lazy binding), rather
- than at load time. Lazy binding is the default.
-
- `loadfltr'
- Marks the object that its filters be processed immediately at
- runtime.
-
- `muldefs'
- Allows multiple definitions.
-
- `nocombreloc'
- Disables multiple reloc sections combining.
-
- `nocopyreloc'
- Disables production of copy relocs.
-
- `nodefaultlib'
- Marks the object that the search for dependencies of this
- object will ignore any default library search paths.
-
- `nodelete'
- Marks the object shouldn't be unloaded at runtime.
-
- `nodlopen'
- Marks the object not available to `dlopen'.
-
- `nodump'
- Marks the object can not be dumped by `dldump'.
-
- `noexecstack'
- Marks the object as not requiring executable stack.
-
- `norelro'
- Don't create an ELF `PT_GNU_RELRO' segment header in the
- object.
-
- `now'
- When generating an executable or shared library, mark it to
- tell the dynamic linker to resolve all symbols when the
- program is started, or when the shared library is linked to
- using dlopen, instead of deferring function call resolution
- to the point when the function is first called.
-
- `origin'
- Marks the object may contain $ORIGIN.
-
- `relro'
- Create an ELF `PT_GNU_RELRO' segment header in the object.
-
- `max-page-size=VALUE'
- Set the emulation maximum page size to VALUE.
-
- `common-page-size=VALUE'
- Set the emulation common page size to VALUE.
-
-
- Other keywords are ignored for Solaris compatibility.
-
-`-( ARCHIVES -)'
-`--start-group ARCHIVES --end-group'
- The ARCHIVES should be a list of archive files. They may be
- either explicit file names, or `-l' options.
-
- The specified archives are searched repeatedly until no new
- undefined references are created. Normally, an archive is
- searched only once in the order that it is specified on the
- command line. If a symbol in that archive is needed to resolve an
- undefined symbol referred to by an object in an archive that
- appears later on the command line, the linker would not be able to
- resolve that reference. By grouping the archives, they all be
- searched repeatedly until all possible references are resolved.
-
- Using this option has a significant performance cost. It is best
- to use it only when there are unavoidable circular references
- between two or more archives.
-
-`--accept-unknown-input-arch'
-`--no-accept-unknown-input-arch'
- Tells the linker to accept input files whose architecture cannot be
- recognised. The assumption is that the user knows what they are
- doing and deliberately wants to link in these unknown input files.
- This was the default behaviour of the linker, before release 2.14.
- The default behaviour from release 2.14 onwards is to reject such
- input files, and so the `--accept-unknown-input-arch' option has
- been added to restore the old behaviour.
-
-`--as-needed'
-`--no-as-needed'
- This option affects ELF DT_NEEDED tags for dynamic libraries
- mentioned on the command line after the `--as-needed' option.
- Normally the linker will add a DT_NEEDED tag for each dynamic
- library mentioned on the command line, regardless of whether the
- library is actually needed or not. `--as-needed' causes a
- DT_NEEDED tag to only be emitted for a library that satisfies an
- undefined symbol reference from a regular object file or, if the
- library is not found in the DT_NEEDED lists of other libraries
- linked up to that point, an undefined symbol reference from
- another dynamic library. `--no-as-needed' restores the default
- behaviour.
-
-`--add-needed'
-`--no-add-needed'
- These two options have been deprecated because of the similarity of
- their names to the `--as-needed' and `--no-as-needed' options.
- They have been replaced by `--copy-dt-needed-entries' and
- `--no-copy-dt-needed-entries'.
-
-`-assert KEYWORD'
- This option is ignored for SunOS compatibility.
-
-`-Bdynamic'
-`-dy'
-`-call_shared'
- Link against dynamic libraries. This is only meaningful on
- platforms for which shared libraries are supported. This option
- is normally the default on such platforms. The different variants
- of this option are for compatibility with various systems. You
- may use this option multiple times on the command line: it affects
- library searching for `-l' options which follow it.
-
-`-Bgroup'
- Set the `DF_1_GROUP' flag in the `DT_FLAGS_1' entry in the dynamic
- section. This causes the runtime linker to handle lookups in this
- object and its dependencies to be performed only inside the group.
- `--unresolved-symbols=report-all' is implied. This option is only
- meaningful on ELF platforms which support shared libraries.
-
-`-Bstatic'
-`-dn'
-`-non_shared'
-`-static'
- Do not link against shared libraries. This is only meaningful on
- platforms for which shared libraries are supported. The different
- variants of this option are for compatibility with various
- systems. You may use this option multiple times on the command
- line: it affects library searching for `-l' options which follow
- it. This option also implies `--unresolved-symbols=report-all'.
- This option can be used with `-shared'. Doing so means that a
- shared library is being created but that all of the library's
- external references must be resolved by pulling in entries from
- static libraries.
-
-`-Bsymbolic'
- When creating a shared library, bind references to global symbols
- to the definition within the shared library, if any. Normally, it
- is possible for a program linked against a shared library to
- override the definition within the shared library. This option is
- only meaningful on ELF platforms which support shared libraries.
-
-`-Bsymbolic-functions'
- When creating a shared library, bind references to global function
- symbols to the definition within the shared library, if any. This
- option is only meaningful on ELF platforms which support shared
- libraries.
-
-`--dynamic-list=DYNAMIC-LIST-FILE'
- Specify the name of a dynamic list file to the linker. This is
- typically used when creating shared libraries to specify a list of
- global symbols whose references shouldn't be bound to the
- definition within the shared library, or creating dynamically
- linked executables to specify a list of symbols which should be
- added to the symbol table in the executable. This option is only
- meaningful on ELF platforms which support shared libraries.
-
- The format of the dynamic list is the same as the version node
- without scope and node name. See *note VERSION:: for more
- information.
-
-`--dynamic-list-data'
- Include all global data symbols to the dynamic list.
-
-`--dynamic-list-cpp-new'
- Provide the builtin dynamic list for C++ operator new and delete.
- It is mainly useful for building shared libstdc++.
-
-`--dynamic-list-cpp-typeinfo'
- Provide the builtin dynamic list for C++ runtime type
- identification.
-
-`--check-sections'
-`--no-check-sections'
- Asks the linker _not_ to check section addresses after they have
- been assigned to see if there are any overlaps. Normally the
- linker will perform this check, and if it finds any overlaps it
- will produce suitable error messages. The linker does know about,
- and does make allowances for sections in overlays. The default
- behaviour can be restored by using the command line switch
- `--check-sections'. Section overlap is not usually checked for
- relocatable links. You can force checking in that case by using
- the `--check-sections' option.
-
-`--copy-dt-needed-entries'
-`--no-copy-dt-needed-entries'
- This option affects the treatment of dynamic libraries referred to
- by DT_NEEDED tags _inside_ ELF dynamic libraries mentioned on the
- command line. Normally the linker will add a DT_NEEDED tag to the
- output binary for each library mentioned in a DT_NEEDED tag in an
- input dynamic library. With `--no-copy-dt-needed-entries'
- specified on the command line however any dynamic libraries that
- follow it will have their DT_NEEDED entries ignored. The default
- behaviour can be restored with `--copy-dt-needed-entries'.
-
- This option also has an effect on the resolution of symbols in
- dynamic libraries. With the default setting dynamic libraries
- mentioned on the command line will be recursively searched,
- following their DT_NEEDED tags to other libraries, in order to
- resolve symbols required by the output binary. With
- `--no-copy-dt-needed-entries' specified however the searching of
- dynamic libraries that follow it will stop with the dynamic
- library itself. No DT_NEEDED links will be traversed to resolve
- symbols.
-
-`--cref'
- Output a cross reference table. If a linker map file is being
- generated, the cross reference table is printed to the map file.
- Otherwise, it is printed on the standard output.
-
- The format of the table is intentionally simple, so that it may be
- easily processed by a script if necessary. The symbols are
- printed out, sorted by name. For each symbol, a list of file
- names is given. If the symbol is defined, the first file listed
- is the location of the definition. The remaining files contain
- references to the symbol.
-
-`--no-define-common'
- This option inhibits the assignment of addresses to common symbols.
- The script command `INHIBIT_COMMON_ALLOCATION' has the same effect.
- *Note Miscellaneous Commands::.
-
- The `--no-define-common' option allows decoupling the decision to
- assign addresses to Common symbols from the choice of the output
- file type; otherwise a non-Relocatable output type forces
- assigning addresses to Common symbols. Using `--no-define-common'
- allows Common symbols that are referenced from a shared library to
- be assigned addresses only in the main program. This eliminates
- the unused duplicate space in the shared library, and also
- prevents any possible confusion over resolving to the wrong
- duplicate when there are many dynamic modules with specialized
- search paths for runtime symbol resolution.
-
-`--defsym=SYMBOL=EXPRESSION'
- Create a global symbol in the output file, containing the absolute
- address given by EXPRESSION. You may use this option as many
- times as necessary to define multiple symbols in the command line.
- A limited form of arithmetic is supported for the EXPRESSION in
- this context: you may give a hexadecimal constant or the name of
- an existing symbol, or use `+' and `-' to add or subtract
- hexadecimal constants or symbols. If you need more elaborate
- expressions, consider using the linker command language from a
- script (*note Assignment: Symbol Definitions: Assignments.).
- _Note:_ there should be no white space between SYMBOL, the equals
- sign ("<=>"), and EXPRESSION.
-
-`--demangle[=STYLE]'
-`--no-demangle'
- These options control whether to demangle symbol names in error
- messages and other output. When the linker is told to demangle,
- it tries to present symbol names in a readable fashion: it strips
- leading underscores if they are used by the object file format,
- and converts C++ mangled symbol names into user readable names.
- Different compilers have different mangling styles. The optional
- demangling style argument can be used to choose an appropriate
- demangling style for your compiler. The linker will demangle by
- default unless the environment variable `COLLECT_NO_DEMANGLE' is
- set. These options may be used to override the default.
-
-`-IFILE'
-`--dynamic-linker=FILE'
- Set the name of the dynamic linker. This is only meaningful when
- generating dynamically linked ELF executables. The default dynamic
- linker is normally correct; don't use this unless you know what
- you are doing.
-
-`--fatal-warnings'
-`--no-fatal-warnings'
- Treat all warnings as errors. The default behaviour can be
- restored with the option `--no-fatal-warnings'.
-
-`--force-exe-suffix'
- Make sure that an output file has a .exe suffix.
-
- If a successfully built fully linked output file does not have a
- `.exe' or `.dll' suffix, this option forces the linker to copy the
- output file to one of the same name with a `.exe' suffix. This
- option is useful when using unmodified Unix makefiles on a
- Microsoft Windows host, since some versions of Windows won't run
- an image unless it ends in a `.exe' suffix.
-
-`--gc-sections'
-`--no-gc-sections'
- Enable garbage collection of unused input sections. It is ignored
- on targets that do not support this option. The default behaviour
- (of not performing this garbage collection) can be restored by
- specifying `--no-gc-sections' on the command line.
-
- `--gc-sections' decides which input sections are used by examining
- symbols and relocations. The section containing the entry symbol
- and all sections containing symbols undefined on the command-line
- will be kept, as will sections containing symbols referenced by
- dynamic objects. Note that when building shared libraries, the
- linker must assume that any visible symbol is referenced. Once
- this initial set of sections has been determined, the linker
- recursively marks as used any section referenced by their
- relocations. See `--entry' and `--undefined'.
-
- This option can be set when doing a partial link (enabled with
- option `-r'). In this case the root of symbols kept must be
- explicitly specified either by an `--entry' or `--undefined'
- option or by a `ENTRY' command in the linker script.
-
-`--print-gc-sections'
-`--no-print-gc-sections'
- List all sections removed by garbage collection. The listing is
- printed on stderr. This option is only effective if garbage
- collection has been enabled via the `--gc-sections') option. The
- default behaviour (of not listing the sections that are removed)
- can be restored by specifying `--no-print-gc-sections' on the
- command line.
-
-`--help'
- Print a summary of the command-line options on the standard output
- and exit.
-
-`--target-help'
- Print a summary of all target specific options on the standard
- output and exit.
-
-`-Map=MAPFILE'
- Print a link map to the file MAPFILE. See the description of the
- `-M' option, above.
-
-`--no-keep-memory'
- `ld' normally optimizes for speed over memory usage by caching the
- symbol tables of input files in memory. This option tells `ld' to
- instead optimize for memory usage, by rereading the symbol tables
- as necessary. This may be required if `ld' runs out of memory
- space while linking a large executable.
-
-`--no-undefined'
-`-z defs'
- Report unresolved symbol references from regular object files.
- This is done even if the linker is creating a non-symbolic shared
- library. The switch `--[no-]allow-shlib-undefined' controls the
- behaviour for reporting unresolved references found in shared
- libraries being linked in.
-
-`--allow-multiple-definition'
-`-z muldefs'
- Normally when a symbol is defined multiple times, the linker will
- report a fatal error. These options allow multiple definitions and
- the first definition will be used.
-
-`--allow-shlib-undefined'
-`--no-allow-shlib-undefined'
- Allows or disallows undefined symbols in shared libraries. This
- switch is similar to `--no-undefined' except that it determines
- the behaviour when the undefined symbols are in a shared library
- rather than a regular object file. It does not affect how
- undefined symbols in regular object files are handled.
-
- The default behaviour is to report errors for any undefined symbols
- referenced in shared libraries if the linker is being used to
- create an executable, but to allow them if the linker is being
- used to create a shared library.
-
- The reasons for allowing undefined symbol references in shared
- libraries specified at link time are that:
-
- * A shared library specified at link time may not be the same
- as the one that is available at load time, so the symbol
- might actually be resolvable at load time.
-
- * There are some operating systems, eg BeOS and HPPA, where
- undefined symbols in shared libraries are normal.
-
- The BeOS kernel for example patches shared libraries at load
- time to select whichever function is most appropriate for the
- current architecture. This is used, for example, to
- dynamically select an appropriate memset function.
-
-`--no-undefined-version'
- Normally when a symbol has an undefined version, the linker will
- ignore it. This option disallows symbols with undefined version
- and a fatal error will be issued instead.
-
-`--default-symver'
- Create and use a default symbol version (the soname) for
- unversioned exported symbols.
-
-`--default-imported-symver'
- Create and use a default symbol version (the soname) for
- unversioned imported symbols.
-
-`--no-warn-mismatch'
- Normally `ld' will give an error if you try to link together input
- files that are mismatched for some reason, perhaps because they
- have been compiled for different processors or for different
- endiannesses. This option tells `ld' that it should silently
- permit such possible errors. This option should only be used with
- care, in cases when you have taken some special action that
- ensures that the linker errors are inappropriate.
-
-`--no-warn-search-mismatch'
- Normally `ld' will give a warning if it finds an incompatible
- library during a library search. This option silences the warning.
-
-`--no-whole-archive'
- Turn off the effect of the `--whole-archive' option for subsequent
- archive files.
-
-`--noinhibit-exec'
- Retain the executable output file whenever it is still usable.
- Normally, the linker will not produce an output file if it
- encounters errors during the link process; it exits without
- writing an output file when it issues any error whatsoever.
-
-`-nostdlib'
- Only search library directories explicitly specified on the
- command line. Library directories specified in linker scripts
- (including linker scripts specified on the command line) are
- ignored.
-
-`--oformat=OUTPUT-FORMAT'
- `ld' may be configured to support more than one kind of object
- file. If your `ld' is configured this way, you can use the
- `--oformat' option to specify the binary format for the output
- object file. Even when `ld' is configured to support alternative
- object formats, you don't usually need to specify this, as `ld'
- should be configured to produce as a default output format the most
- usual format on each machine. OUTPUT-FORMAT is a text string, the
- name of a particular format supported by the BFD libraries. (You
- can list the available binary formats with `objdump -i'.) The
- script command `OUTPUT_FORMAT' can also specify the output format,
- but this option overrides it. *Note BFD::.
-
-`-pie'
-`--pic-executable'
- Create a position independent executable. This is currently only
- supported on ELF platforms. Position independent executables are
- similar to shared libraries in that they are relocated by the
- dynamic linker to the virtual address the OS chooses for them
- (which can vary between invocations). Like normal dynamically
- linked executables they can be executed and symbols defined in the
- executable cannot be overridden by shared libraries.
-
-`-qmagic'
- This option is ignored for Linux compatibility.
-
-`-Qy'
- This option is ignored for SVR4 compatibility.
-
-`--relax'
-`--no-relax'
- An option with machine dependent effects. This option is only
- supported on a few targets. *Note `ld' and the H8/300: H8/300.
- *Note `ld' and the Intel 960 family: i960. *Note `ld' and Xtensa
- Processors: Xtensa. *Note `ld' and the 68HC11 and 68HC12:
- M68HC11/68HC12. *Note `ld' and PowerPC 32-bit ELF Support:
- PowerPC ELF32.
-
- On some platforms the `--relax' option performs target specific,
- global optimizations that become possible when the linker resolves
- addressing in the program, such as relaxing address modes,
- synthesizing new instructions, selecting shorter version of current
- instructions, and combinig constant values.
-
- On some platforms these link time global optimizations may make
- symbolic debugging of the resulting executable impossible. This
- is known to be the case for the Matsushita MN10200 and MN10300
- family of processors.
-
- On platforms where this is not supported, `--relax' is accepted,
- but ignored.
-
- On platforms where `--relax' is accepted the option `--no-relax'
- can be used to disable the feature.
-
-`--retain-symbols-file=FILENAME'
- Retain _only_ the symbols listed in the file FILENAME, discarding
- all others. FILENAME is simply a flat file, with one symbol name
- per line. This option is especially useful in environments (such
- as VxWorks) where a large global symbol table is accumulated
- gradually, to conserve run-time memory.
-
- `--retain-symbols-file' does _not_ discard undefined symbols, or
- symbols needed for relocations.
-
- You may only specify `--retain-symbols-file' once in the command
- line. It overrides `-s' and `-S'.
-
-`-rpath=DIR'
- Add a directory to the runtime library search path. This is used
- when linking an ELF executable with shared objects. All `-rpath'
- arguments are concatenated and passed to the runtime linker, which
- uses them to locate shared objects at runtime. The `-rpath'
- option is also used when locating shared objects which are needed
- by shared objects explicitly included in the link; see the
- description of the `-rpath-link' option. If `-rpath' is not used
- when linking an ELF executable, the contents of the environment
- variable `LD_RUN_PATH' will be used if it is defined.
-
- The `-rpath' option may also be used on SunOS. By default, on
- SunOS, the linker will form a runtime search patch out of all the
- `-L' options it is given. If a `-rpath' option is used, the
- runtime search path will be formed exclusively using the `-rpath'
- options, ignoring the `-L' options. This can be useful when using
- gcc, which adds many `-L' options which may be on NFS mounted file
- systems.
-
- For compatibility with other ELF linkers, if the `-R' option is
- followed by a directory name, rather than a file name, it is
- treated as the `-rpath' option.
-
-`-rpath-link=DIR'
- When using ELF or SunOS, one shared library may require another.
- This happens when an `ld -shared' link includes a shared library
- as one of the input files.
-
- When the linker encounters such a dependency when doing a
- non-shared, non-relocatable link, it will automatically try to
- locate the required shared library and include it in the link, if
- it is not included explicitly. In such a case, the `-rpath-link'
- option specifies the first set of directories to search. The
- `-rpath-link' option may specify a sequence of directory names
- either by specifying a list of names separated by colons, or by
- appearing multiple times.
-
- This option should be used with caution as it overrides the search
- path that may have been hard compiled into a shared library. In
- such a case it is possible to use unintentionally a different
- search path than the runtime linker would do.
-
- The linker uses the following search paths to locate required
- shared libraries:
- 1. Any directories specified by `-rpath-link' options.
-
- 2. Any directories specified by `-rpath' options. The difference
- between `-rpath' and `-rpath-link' is that directories
- specified by `-rpath' options are included in the executable
- and used at runtime, whereas the `-rpath-link' option is only
- effective at link time. Searching `-rpath' in this way is
- only supported by native linkers and cross linkers which have
- been configured with the `--with-sysroot' option.
-
- 3. On an ELF system, for native linkers, if the `-rpath' and
- `-rpath-link' options were not used, search the contents of
- the environment variable `LD_RUN_PATH'.
-
- 4. On SunOS, if the `-rpath' option was not used, search any
- directories specified using `-L' options.
-
- 5. For a native linker, the search the contents of the
- environment variable `LD_LIBRARY_PATH'.
-
- 6. For a native ELF linker, the directories in `DT_RUNPATH' or
- `DT_RPATH' of a shared library are searched for shared
- libraries needed by it. The `DT_RPATH' entries are ignored if
- `DT_RUNPATH' entries exist.
-
- 7. The default directories, normally `/lib' and `/usr/lib'.
-
- 8. For a native linker on an ELF system, if the file
- `/etc/ld.so.conf' exists, the list of directories found in
- that file.
-
- If the required shared library is not found, the linker will issue
- a warning and continue with the link.
-
-`-shared'
-`-Bshareable'
- Create a shared library. This is currently only supported on ELF,
- XCOFF and SunOS platforms. On SunOS, the linker will
- automatically create a shared library if the `-e' option is not
- used and there are undefined symbols in the link.
-
-`--sort-common'
-`--sort-common=ascending'
-`--sort-common=descending'
- This option tells `ld' to sort the common symbols by alignment in
- ascending or descending order when it places them in the
- appropriate output sections. The symbol alignments considered are
- sixteen-byte or larger, eight-byte, four-byte, two-byte, and
- one-byte. This is to prevent gaps between symbols due to alignment
- constraints. If no sorting order is specified, then descending
- order is assumed.
-
-`--sort-section=name'
- This option will apply `SORT_BY_NAME' to all wildcard section
- patterns in the linker script.
-
-`--sort-section=alignment'
- This option will apply `SORT_BY_ALIGNMENT' to all wildcard section
- patterns in the linker script.
-
-`--split-by-file[=SIZE]'
- Similar to `--split-by-reloc' but creates a new output section for
- each input file when SIZE is reached. SIZE defaults to a size of
- 1 if not given.
-
-`--split-by-reloc[=COUNT]'
- Tries to creates extra sections in the output file so that no
- single output section in the file contains more than COUNT
- relocations. This is useful when generating huge relocatable
- files for downloading into certain real time kernels with the COFF
- object file format; since COFF cannot represent more than 65535
- relocations in a single section. Note that this will fail to work
- with object file formats which do not support arbitrary sections.
- The linker will not split up individual input sections for
- redistribution, so if a single input section contains more than
- COUNT relocations one output section will contain that many
- relocations. COUNT defaults to a value of 32768.
-
-`--stats'
- Compute and display statistics about the operation of the linker,
- such as execution time and memory usage.
-
-`--sysroot=DIRECTORY'
- Use DIRECTORY as the location of the sysroot, overriding the
- configure-time default. This option is only supported by linkers
- that were configured using `--with-sysroot'.
-
-`--traditional-format'
- For some targets, the output of `ld' is different in some ways from
- the output of some existing linker. This switch requests `ld' to
- use the traditional format instead.
-
- For example, on SunOS, `ld' combines duplicate entries in the
- symbol string table. This can reduce the size of an output file
- with full debugging information by over 30 percent.
- Unfortunately, the SunOS `dbx' program can not read the resulting
- program (`gdb' has no trouble). The `--traditional-format' switch
- tells `ld' to not combine duplicate entries.
-
-`--section-start=SECTIONNAME=ORG'
- Locate a section in the output file at the absolute address given
- by ORG. You may use this option as many times as necessary to
- locate multiple sections in the command line. ORG must be a
- single hexadecimal integer; for compatibility with other linkers,
- you may omit the leading `0x' usually associated with hexadecimal
- values. _Note:_ there should be no white space between
- SECTIONNAME, the equals sign ("<=>"), and ORG.
-
-`-Tbss=ORG'
-`-Tdata=ORG'
-`-Ttext=ORG'
- Same as `--section-start', with `.bss', `.data' or `.text' as the
- SECTIONNAME.
-
-`-Ttext-segment=ORG'
- When creating an ELF executable or shared object, it will set the
- address of the first byte of the text segment.
-
-`--unresolved-symbols=METHOD'
- Determine how to handle unresolved symbols. There are four
- possible values for `method':
-
- `ignore-all'
- Do not report any unresolved symbols.
-
- `report-all'
- Report all unresolved symbols. This is the default.
-
- `ignore-in-object-files'
- Report unresolved symbols that are contained in shared
- libraries, but ignore them if they come from regular object
- files.
-
- `ignore-in-shared-libs'
- Report unresolved symbols that come from regular object
- files, but ignore them if they come from shared libraries.
- This can be useful when creating a dynamic binary and it is
- known that all the shared libraries that it should be
- referencing are included on the linker's command line.
-
- The behaviour for shared libraries on their own can also be
- controlled by the `--[no-]allow-shlib-undefined' option.
-
- Normally the linker will generate an error message for each
- reported unresolved symbol but the option
- `--warn-unresolved-symbols' can change this to a warning.
-
-`--dll-verbose'
-`--verbose'
- Display the version number for `ld' and list the linker emulations
- supported. Display which input files can and cannot be opened.
- Display the linker script being used by the linker.
-
-`--version-script=VERSION-SCRIPTFILE'
- Specify the name of a version script to the linker. This is
- typically used when creating shared libraries to specify
- additional information about the version hierarchy for the library
- being created. This option is only fully supported on ELF
- platforms which support shared libraries; see *note VERSION::. It
- is partially supported on PE platforms, which can use version
- scripts to filter symbol visibility in auto-export mode: any
- symbols marked `local' in the version script will not be exported.
- *Note WIN32::.
-
-`--warn-common'
- Warn when a common symbol is combined with another common symbol
- or with a symbol definition. Unix linkers allow this somewhat
- sloppy practise, but linkers on some other operating systems do
- not. This option allows you to find potential problems from
- combining global symbols. Unfortunately, some C libraries use
- this practise, so you may get some warnings about symbols in the
- libraries as well as in your programs.
-
- There are three kinds of global symbols, illustrated here by C
- examples:
-
- `int i = 1;'
- A definition, which goes in the initialized data section of
- the output file.
-
- `extern int i;'
- An undefined reference, which does not allocate space. There
- must be either a definition or a common symbol for the
- variable somewhere.
-
- `int i;'
- A common symbol. If there are only (one or more) common
- symbols for a variable, it goes in the uninitialized data
- area of the output file. The linker merges multiple common
- symbols for the same variable into a single symbol. If they
- are of different sizes, it picks the largest size. The
- linker turns a common symbol into a declaration, if there is
- a definition of the same variable.
-
- The `--warn-common' option can produce five kinds of warnings.
- Each warning consists of a pair of lines: the first describes the
- symbol just encountered, and the second describes the previous
- symbol encountered with the same name. One or both of the two
- symbols will be a common symbol.
-
- 1. Turning a common symbol into a reference, because there is
- already a definition for the symbol.
- FILE(SECTION): warning: common of `SYMBOL'
- overridden by definition
- FILE(SECTION): warning: defined here
-
- 2. Turning a common symbol into a reference, because a later
- definition for the symbol is encountered. This is the same
- as the previous case, except that the symbols are encountered
- in a different order.
- FILE(SECTION): warning: definition of `SYMBOL'
- overriding common
- FILE(SECTION): warning: common is here
-
- 3. Merging a common symbol with a previous same-sized common
- symbol.
- FILE(SECTION): warning: multiple common
- of `SYMBOL'
- FILE(SECTION): warning: previous common is here
-
- 4. Merging a common symbol with a previous larger common symbol.
- FILE(SECTION): warning: common of `SYMBOL'
- overridden by larger common
- FILE(SECTION): warning: larger common is here
-
- 5. Merging a common symbol with a previous smaller common
- symbol. This is the same as the previous case, except that
- the symbols are encountered in a different order.
- FILE(SECTION): warning: common of `SYMBOL'
- overriding smaller common
- FILE(SECTION): warning: smaller common is here
-
-`--warn-constructors'
- Warn if any global constructors are used. This is only useful for
- a few object file formats. For formats like COFF or ELF, the
- linker can not detect the use of global constructors.
-
-`--warn-multiple-gp'
- Warn if multiple global pointer values are required in the output
- file. This is only meaningful for certain processors, such as the
- Alpha. Specifically, some processors put large-valued constants
- in a special section. A special register (the global pointer)
- points into the middle of this section, so that constants can be
- loaded efficiently via a base-register relative addressing mode.
- Since the offset in base-register relative mode is fixed and
- relatively small (e.g., 16 bits), this limits the maximum size of
- the constant pool. Thus, in large programs, it is often necessary
- to use multiple global pointer values in order to be able to
- address all possible constants. This option causes a warning to
- be issued whenever this case occurs.
-
-`--warn-once'
- Only warn once for each undefined symbol, rather than once per
- module which refers to it.
-
-`--warn-section-align'
- Warn if the address of an output section is changed because of
- alignment. Typically, the alignment will be set by an input
- section. The address will only be changed if it not explicitly
- specified; that is, if the `SECTIONS' command does not specify a
- start address for the section (*note SECTIONS::).
-
-`--warn-shared-textrel'
- Warn if the linker adds a DT_TEXTREL to a shared object.
-
-`--warn-alternate-em'
- Warn if an object has alternate ELF machine code.
-
-`--warn-unresolved-symbols'
- If the linker is going to report an unresolved symbol (see the
- option `--unresolved-symbols') it will normally generate an error.
- This option makes it generate a warning instead.
-
-`--error-unresolved-symbols'
- This restores the linker's default behaviour of generating errors
- when it is reporting unresolved symbols.
-
-`--whole-archive'
- For each archive mentioned on the command line after the
- `--whole-archive' option, include every object file in the archive
- in the link, rather than searching the archive for the required
- object files. This is normally used to turn an archive file into
- a shared library, forcing every object to be included in the
- resulting shared library. This option may be used more than once.
-
- Two notes when using this option from gcc: First, gcc doesn't know
- about this option, so you have to use `-Wl,-whole-archive'.
- Second, don't forget to use `-Wl,-no-whole-archive' after your
- list of archives, because gcc will add its own list of archives to
- your link and you may not want this flag to affect those as well.
-
-`--wrap=SYMBOL'
- Use a wrapper function for SYMBOL. Any undefined reference to
- SYMBOL will be resolved to `__wrap_SYMBOL'. Any undefined
- reference to `__real_SYMBOL' will be resolved to SYMBOL.
-
- This can be used to provide a wrapper for a system function. The
- wrapper function should be called `__wrap_SYMBOL'. If it wishes
- to call the system function, it should call `__real_SYMBOL'.
-
- Here is a trivial example:
-
- void *
- __wrap_malloc (size_t c)
- {
- printf ("malloc called with %zu\n", c);
- return __real_malloc (c);
- }
-
- If you link other code with this file using `--wrap malloc', then
- all calls to `malloc' will call the function `__wrap_malloc'
- instead. The call to `__real_malloc' in `__wrap_malloc' will call
- the real `malloc' function.
-
- You may wish to provide a `__real_malloc' function as well, so that
- links without the `--wrap' option will succeed. If you do this,
- you should not put the definition of `__real_malloc' in the same
- file as `__wrap_malloc'; if you do, the assembler may resolve the
- call before the linker has a chance to wrap it to `malloc'.
-
-`--eh-frame-hdr'
- Request creation of `.eh_frame_hdr' section and ELF
- `PT_GNU_EH_FRAME' segment header.
-
-`--enable-new-dtags'
-`--disable-new-dtags'
- This linker can create the new dynamic tags in ELF. But the older
- ELF systems may not understand them. If you specify
- `--enable-new-dtags', the dynamic tags will be created as needed.
- If you specify `--disable-new-dtags', no new dynamic tags will be
- created. By default, the new dynamic tags are not created. Note
- that those options are only available for ELF systems.
-
-`--hash-size=NUMBER'
- Set the default size of the linker's hash tables to a prime number
- close to NUMBER. Increasing this value can reduce the length of
- time it takes the linker to perform its tasks, at the expense of
- increasing the linker's memory requirements. Similarly reducing
- this value can reduce the memory requirements at the expense of
- speed.
-
-`--hash-style=STYLE'
- Set the type of linker's hash table(s). STYLE can be either
- `sysv' for classic ELF `.hash' section, `gnu' for new style GNU
- `.gnu.hash' section or `both' for both the classic ELF `.hash' and
- new style GNU `.gnu.hash' hash tables. The default is `sysv'.
-
-`--reduce-memory-overheads'
- This option reduces memory requirements at ld runtime, at the
- expense of linking speed. This was introduced to select the old
- O(n^2) algorithm for link map file generation, rather than the new
- O(n) algorithm which uses about 40% more memory for symbol storage.
-
- Another effect of the switch is to set the default hash table size
- to 1021, which again saves memory at the cost of lengthening the
- linker's run time. This is not done however if the `--hash-size'
- switch has been used.
-
- The `--reduce-memory-overheads' switch may be also be used to
- enable other tradeoffs in future versions of the linker.
-
-`--build-id'
-`--build-id=STYLE'
- Request creation of `.note.gnu.build-id' ELF note section. The
- contents of the note are unique bits identifying this linked file.
- STYLE can be `uuid' to use 128 random bits, `sha1' to use a
- 160-bit SHA1 hash on the normative parts of the output contents,
- `md5' to use a 128-bit MD5 hash on the normative parts of the
- output contents, or `0xHEXSTRING' to use a chosen bit string
- specified as an even number of hexadecimal digits (`-' and `:'
- characters between digit pairs are ignored). If STYLE is omitted,
- `sha1' is used.
-
- The `md5' and `sha1' styles produces an identifier that is always
- the same in an identical output file, but will be unique among all
- nonidentical output files. It is not intended to be compared as a
- checksum for the file's contents. A linked file may be changed
- later by other tools, but the build ID bit string identifying the
- original linked file does not change.
-
- Passing `none' for STYLE disables the setting from any
- `--build-id' options earlier on the command line.
-
-2.1.1 Options Specific to i386 PE Targets
------------------------------------------
-
-The i386 PE linker supports the `-shared' option, which causes the
-output to be a dynamically linked library (DLL) instead of a normal
-executable. You should name the output `*.dll' when you use this
-option. In addition, the linker fully supports the standard `*.def'
-files, which may be specified on the linker command line like an object
-file (in fact, it should precede archives it exports symbols from, to
-ensure that they get linked in, just like a normal object file).
-
- In addition to the options common to all targets, the i386 PE linker
-support additional command line options that are specific to the i386
-PE target. Options that take values may be separated from their values
-by either a space or an equals sign.
-
-`--add-stdcall-alias'
- If given, symbols with a stdcall suffix (@NN) will be exported
- as-is and also with the suffix stripped. [This option is specific
- to the i386 PE targeted port of the linker]
-
-`--base-file FILE'
- Use FILE as the name of a file in which to save the base addresses
- of all the relocations needed for generating DLLs with `dlltool'.
- [This is an i386 PE specific option]
-
-`--dll'
- Create a DLL instead of a regular executable. You may also use
- `-shared' or specify a `LIBRARY' in a given `.def' file. [This
- option is specific to the i386 PE targeted port of the linker]
-
-`--enable-long-section-names'
-`--disable-long-section-names'
- The PE variants of the Coff object format add an extension that
- permits the use of section names longer than eight characters, the
- normal limit for Coff. By default, these names are only allowed
- in object files, as fully-linked executable images do not carry
- the Coff string table required to support the longer names. As a
- GNU extension, it is possible to allow their use in executable
- images as well, or to (probably pointlessly!) disallow it in
- object files, by using these two options. Executable images
- generated with these long section names are slightly non-standard,
- carrying as they do a string table, and may generate confusing
- output when examined with non-GNU PE-aware tools, such as file
- viewers and dumpers. However, GDB relies on the use of PE long
- section names to find Dwarf-2 debug information sections in an
- executable image at runtime, and so if neither option is specified
- on the command-line, `ld' will enable long section names,
- overriding the default and technically correct behaviour, when it
- finds the presence of debug information while linking an executable
- image and not stripping symbols. [This option is valid for all PE
- targeted ports of the linker]
-
-`--enable-stdcall-fixup'
-`--disable-stdcall-fixup'
- If the link finds a symbol that it cannot resolve, it will attempt
- to do "fuzzy linking" by looking for another defined symbol that
- differs only in the format of the symbol name (cdecl vs stdcall)
- and will resolve that symbol by linking to the match. For
- example, the undefined symbol `_foo' might be linked to the
- function `_foo@12', or the undefined symbol `_bar@16' might be
- linked to the function `_bar'. When the linker does this, it
- prints a warning, since it normally should have failed to link,
- but sometimes import libraries generated from third-party dlls may
- need this feature to be usable. If you specify
- `--enable-stdcall-fixup', this feature is fully enabled and
- warnings are not printed. If you specify
- `--disable-stdcall-fixup', this feature is disabled and such
- mismatches are considered to be errors. [This option is specific
- to the i386 PE targeted port of the linker]
-
-`--leading-underscore'
-`--no-leading-underscore'
- For most targets default symbol-prefix is an underscore and is
- defined in target's description. By this option it is possible to
- disable/enable the default underscore symbol-prefix.
-
-`--export-all-symbols'
- If given, all global symbols in the objects used to build a DLL
- will be exported by the DLL. Note that this is the default if
- there otherwise wouldn't be any exported symbols. When symbols are
- explicitly exported via DEF files or implicitly exported via
- function attributes, the default is to not export anything else
- unless this option is given. Note that the symbols `DllMain@12',
- `DllEntryPoint@0', `DllMainCRTStartup@12', and `impure_ptr' will
- not be automatically exported. Also, symbols imported from other
- DLLs will not be re-exported, nor will symbols specifying the
- DLL's internal layout such as those beginning with `_head_' or
- ending with `_iname'. In addition, no symbols from `libgcc',
- `libstd++', `libmingw32', or `crtX.o' will be exported. Symbols
- whose names begin with `__rtti_' or `__builtin_' will not be
- exported, to help with C++ DLLs. Finally, there is an extensive
- list of cygwin-private symbols that are not exported (obviously,
- this applies on when building DLLs for cygwin targets). These
- cygwin-excludes are: `_cygwin_dll_entry@12',
- `_cygwin_crt0_common@8', `_cygwin_noncygwin_dll_entry@12',
- `_fmode', `_impure_ptr', `cygwin_attach_dll', `cygwin_premain0',
- `cygwin_premain1', `cygwin_premain2', `cygwin_premain3', and
- `environ'. [This option is specific to the i386 PE targeted port
- of the linker]
-
-`--exclude-symbols SYMBOL,SYMBOL,...'
- Specifies a list of symbols which should not be automatically
- exported. The symbol names may be delimited by commas or colons.
- [This option is specific to the i386 PE targeted port of the
- linker]
-
-`--exclude-all-symbols'
- Specifies no symbols should be automatically exported. [This
- option is specific to the i386 PE targeted port of the linker]
-
-`--file-alignment'
- Specify the file alignment. Sections in the file will always
- begin at file offsets which are multiples of this number. This
- defaults to 512. [This option is specific to the i386 PE targeted
- port of the linker]
-
-`--heap RESERVE'
-`--heap RESERVE,COMMIT'
- Specify the number of bytes of memory to reserve (and optionally
- commit) to be used as heap for this program. The default is 1Mb
- reserved, 4K committed. [This option is specific to the i386 PE
- targeted port of the linker]
-
-`--image-base VALUE'
- Use VALUE as the base address of your program or dll. This is the
- lowest memory location that will be used when your program or dll
- is loaded. To reduce the need to relocate and improve performance
- of your dlls, each should have a unique base address and not
- overlap any other dlls. The default is 0x400000 for executables,
- and 0x10000000 for dlls. [This option is specific to the i386 PE
- targeted port of the linker]
-
-`--kill-at'
- If given, the stdcall suffixes (@NN) will be stripped from symbols
- before they are exported. [This option is specific to the i386 PE
- targeted port of the linker]
-
-`--large-address-aware'
- If given, the appropriate bit in the "Characteristics" field of
- the COFF header is set to indicate that this executable supports
- virtual addresses greater than 2 gigabytes. This should be used
- in conjunction with the /3GB or /USERVA=VALUE megabytes switch in
- the "[operating systems]" section of the BOOT.INI. Otherwise,
- this bit has no effect. [This option is specific to PE targeted
- ports of the linker]
-
-`--major-image-version VALUE'
- Sets the major number of the "image version". Defaults to 1.
- [This option is specific to the i386 PE targeted port of the
- linker]
-
-`--major-os-version VALUE'
- Sets the major number of the "os version". Defaults to 4. [This
- option is specific to the i386 PE targeted port of the linker]
-
-`--major-subsystem-version VALUE'
- Sets the major number of the "subsystem version". Defaults to 4.
- [This option is specific to the i386 PE targeted port of the
- linker]
-
-`--minor-image-version VALUE'
- Sets the minor number of the "image version". Defaults to 0.
- [This option is specific to the i386 PE targeted port of the
- linker]
-
-`--minor-os-version VALUE'
- Sets the minor number of the "os version". Defaults to 0. [This
- option is specific to the i386 PE targeted port of the linker]
-
-`--minor-subsystem-version VALUE'
- Sets the minor number of the "subsystem version". Defaults to 0.
- [This option is specific to the i386 PE targeted port of the
- linker]
-
-`--output-def FILE'
- The linker will create the file FILE which will contain a DEF file
- corresponding to the DLL the linker is generating. This DEF file
- (which should be called `*.def') may be used to create an import
- library with `dlltool' or may be used as a reference to
- automatically or implicitly exported symbols. [This option is
- specific to the i386 PE targeted port of the linker]
-
-`--out-implib FILE'
- The linker will create the file FILE which will contain an import
- lib corresponding to the DLL the linker is generating. This import
- lib (which should be called `*.dll.a' or `*.a' may be used to link
- clients against the generated DLL; this behaviour makes it
- possible to skip a separate `dlltool' import library creation step.
- [This option is specific to the i386 PE targeted port of the
- linker]
-
-`--enable-auto-image-base'
- Automatically choose the image base for DLLs, unless one is
- specified using the `--image-base' argument. By using a hash
- generated from the dllname to create unique image bases for each
- DLL, in-memory collisions and relocations which can delay program
- execution are avoided. [This option is specific to the i386 PE
- targeted port of the linker]
-
-`--disable-auto-image-base'
- Do not automatically generate a unique image base. If there is no
- user-specified image base (`--image-base') then use the platform
- default. [This option is specific to the i386 PE targeted port of
- the linker]
-
-`--dll-search-prefix STRING'
- When linking dynamically to a dll without an import library,
- search for `<string><basename>.dll' in preference to
- `lib<basename>.dll'. This behaviour allows easy distinction
- between DLLs built for the various "subplatforms": native, cygwin,
- uwin, pw, etc. For instance, cygwin DLLs typically use
- `--dll-search-prefix=cyg'. [This option is specific to the i386
- PE targeted port of the linker]
-
-`--enable-auto-import'
- Do sophisticated linking of `_symbol' to `__imp__symbol' for DATA
- imports from DLLs, and create the necessary thunking symbols when
- building the import libraries with those DATA exports. Note: Use
- of the 'auto-import' extension will cause the text section of the
- image file to be made writable. This does not conform to the
- PE-COFF format specification published by Microsoft.
-
- Note - use of the 'auto-import' extension will also cause read only
- data which would normally be placed into the .rdata section to be
- placed into the .data section instead. This is in order to work
- around a problem with consts that is described here:
- http://www.cygwin.com/ml/cygwin/2004-09/msg01101.html
-
- Using 'auto-import' generally will 'just work' - but sometimes you
- may see this message:
-
- "variable '<var>' can't be auto-imported. Please read the
- documentation for ld's `--enable-auto-import' for details."
-
- This message occurs when some (sub)expression accesses an address
- ultimately given by the sum of two constants (Win32 import tables
- only allow one). Instances where this may occur include accesses
- to member fields of struct variables imported from a DLL, as well
- as using a constant index into an array variable imported from a
- DLL. Any multiword variable (arrays, structs, long long, etc) may
- trigger this error condition. However, regardless of the exact
- data type of the offending exported variable, ld will always
- detect it, issue the warning, and exit.
-
- There are several ways to address this difficulty, regardless of
- the data type of the exported variable:
-
- One way is to use -enable-runtime-pseudo-reloc switch. This leaves
- the task of adjusting references in your client code for runtime
- environment, so this method works only when runtime environment
- supports this feature.
-
- A second solution is to force one of the 'constants' to be a
- variable - that is, unknown and un-optimizable at compile time.
- For arrays, there are two possibilities: a) make the indexee (the
- array's address) a variable, or b) make the 'constant' index a
- variable. Thus:
-
- extern type extern_array[];
- extern_array[1] -->
- { volatile type *t=extern_array; t[1] }
-
- or
-
- extern type extern_array[];
- extern_array[1] -->
- { volatile int t=1; extern_array[t] }
-
- For structs (and most other multiword data types) the only option
- is to make the struct itself (or the long long, or the ...)
- variable:
-
- extern struct s extern_struct;
- extern_struct.field -->
- { volatile struct s *t=&extern_struct; t->field }
-
- or
-
- extern long long extern_ll;
- extern_ll -->
- { volatile long long * local_ll=&extern_ll; *local_ll }
-
- A third method of dealing with this difficulty is to abandon
- 'auto-import' for the offending symbol and mark it with
- `__declspec(dllimport)'. However, in practise that requires using
- compile-time #defines to indicate whether you are building a DLL,
- building client code that will link to the DLL, or merely
- building/linking to a static library. In making the choice
- between the various methods of resolving the 'direct address with
- constant offset' problem, you should consider typical real-world
- usage:
-
- Original:
- --foo.h
- extern int arr[];
- --foo.c
- #include "foo.h"
- void main(int argc, char **argv){
- printf("%d\n",arr[1]);
- }
-
- Solution 1:
- --foo.h
- extern int arr[];
- --foo.c
- #include "foo.h"
- void main(int argc, char **argv){
- /* This workaround is for win32 and cygwin; do not "optimize" */
- volatile int *parr = arr;
- printf("%d\n",parr[1]);
- }
-
- Solution 2:
- --foo.h
- /* Note: auto-export is assumed (no __declspec(dllexport)) */
- #if (defined(_WIN32) || defined(__CYGWIN__)) && \
- !(defined(FOO_BUILD_DLL) || defined(FOO_STATIC))
- #define FOO_IMPORT __declspec(dllimport)
- #else
- #define FOO_IMPORT
- #endif
- extern FOO_IMPORT int arr[];
- --foo.c
- #include "foo.h"
- void main(int argc, char **argv){
- printf("%d\n",arr[1]);
- }
-
- A fourth way to avoid this problem is to re-code your library to
- use a functional interface rather than a data interface for the
- offending variables (e.g. set_foo() and get_foo() accessor
- functions). [This option is specific to the i386 PE targeted port
- of the linker]
-
-`--disable-auto-import'
- Do not attempt to do sophisticated linking of `_symbol' to
- `__imp__symbol' for DATA imports from DLLs. [This option is
- specific to the i386 PE targeted port of the linker]
-
-`--enable-runtime-pseudo-reloc'
- If your code contains expressions described in -enable-auto-import
- section, that is, DATA imports from DLL with non-zero offset, this
- switch will create a vector of 'runtime pseudo relocations' which
- can be used by runtime environment to adjust references to such
- data in your client code. [This option is specific to the i386 PE
- targeted port of the linker]
-
-`--disable-runtime-pseudo-reloc'
- Do not create pseudo relocations for non-zero offset DATA imports
- from DLLs. This is the default. [This option is specific to the
- i386 PE targeted port of the linker]
-
-`--enable-extra-pe-debug'
- Show additional debug info related to auto-import symbol thunking.
- [This option is specific to the i386 PE targeted port of the
- linker]
-
-`--section-alignment'
- Sets the section alignment. Sections in memory will always begin
- at addresses which are a multiple of this number. Defaults to
- 0x1000. [This option is specific to the i386 PE targeted port of
- the linker]
-
-`--stack RESERVE'
-`--stack RESERVE,COMMIT'
- Specify the number of bytes of memory to reserve (and optionally
- commit) to be used as stack for this program. The default is 2Mb
- reserved, 4K committed. [This option is specific to the i386 PE
- targeted port of the linker]
-
-`--subsystem WHICH'
-`--subsystem WHICH:MAJOR'
-`--subsystem WHICH:MAJOR.MINOR'
- Specifies the subsystem under which your program will execute. The
- legal values for WHICH are `native', `windows', `console',
- `posix', and `xbox'. You may optionally set the subsystem version
- also. Numeric values are also accepted for WHICH. [This option
- is specific to the i386 PE targeted port of the linker]
-
- The following options set flags in the `DllCharacteristics' field
- of the PE file header: [These options are specific to PE targeted
- ports of the linker]
-
-`--dynamicbase'
- The image base address may be relocated using address space layout
- randomization (ASLR). This feature was introduced with MS Windows
- Vista for i386 PE targets.
-
-`--forceinteg'
- Code integrity checks are enforced.
-
-`--nxcompat'
- The image is compatible with the Data Execution Prevention. This
- feature was introduced with MS Windows XP SP2 for i386 PE targets.
-
-`--no-isolation'
- Although the image understands isolation, do not isolate the image.
-
-`--no-seh'
- The image does not use SEH. No SE handler may be called from this
- image.
-
-`--no-bind'
- Do not bind this image.
-
-`--wdmdriver'
- The driver uses the MS Windows Driver Model.
-
-`--tsaware'
- The image is Terminal Server aware.
-
-
-2.1.2 Options specific to Motorola 68HC11 and 68HC12 targets
-------------------------------------------------------------
-
-The 68HC11 and 68HC12 linkers support specific options to control the
-memory bank switching mapping and trampoline code generation.
-
-`--no-trampoline'
- This option disables the generation of trampoline. By default a
- trampoline is generated for each far function which is called
- using a `jsr' instruction (this happens when a pointer to a far
- function is taken).
-
-`--bank-window NAME'
- This option indicates to the linker the name of the memory region
- in the `MEMORY' specification that describes the memory bank
- window. The definition of such region is then used by the linker
- to compute paging and addresses within the memory window.
-
-
-2.1.3 Options specific to Motorola 68K target
----------------------------------------------
-
-The following options are supported to control handling of GOT
-generation when linking for 68K targets.
-
-`--got=TYPE'
- This option tells the linker which GOT generation scheme to use.
- TYPE should be one of `single', `negative', `multigot' or
- `target'. For more information refer to the Info entry for `ld'.
-
-
-
-File: ld.info, Node: Environment, Prev: Options, Up: Invocation
-
-2.2 Environment Variables
-=========================
-
-You can change the behaviour of `ld' with the environment variables
-`GNUTARGET', `LDEMULATION' and `COLLECT_NO_DEMANGLE'.
-
- `GNUTARGET' determines the input-file object format if you don't use
-`-b' (or its synonym `--format'). Its value should be one of the BFD
-names for an input format (*note BFD::). If there is no `GNUTARGET' in
-the environment, `ld' uses the natural format of the target. If
-`GNUTARGET' is set to `default' then BFD attempts to discover the input
-format by examining binary input files; this method often succeeds, but
-there are potential ambiguities, since there is no method of ensuring
-that the magic number used to specify object-file formats is unique.
-However, the configuration procedure for BFD on each system places the
-conventional format for that system first in the search-list, so
-ambiguities are resolved in favor of convention.
-
- `LDEMULATION' determines the default emulation if you don't use the
-`-m' option. The emulation can affect various aspects of linker
-behaviour, particularly the default linker script. You can list the
-available emulations with the `--verbose' or `-V' options. If the `-m'
-option is not used, and the `LDEMULATION' environment variable is not
-defined, the default emulation depends upon how the linker was
-configured.
-
- Normally, the linker will default to demangling symbols. However, if
-`COLLECT_NO_DEMANGLE' is set in the environment, then it will default
-to not demangling symbols. This environment variable is used in a
-similar fashion by the `gcc' linker wrapper program. The default may
-be overridden by the `--demangle' and `--no-demangle' options.
-
-
-File: ld.info, Node: Scripts, Next: Machine Dependent, Prev: Invocation, Up: Top
-
-3 Linker Scripts
-****************
-
-Every link is controlled by a "linker script". This script is written
-in the linker command language.
-
- The main purpose of the linker script is to describe how the
-sections in the input files should be mapped into the output file, and
-to control the memory layout of the output file. Most linker scripts
-do nothing more than this. However, when necessary, the linker script
-can also direct the linker to perform many other operations, using the
-commands described below.
-
- The linker always uses a linker script. If you do not supply one
-yourself, the linker will use a default script that is compiled into the
-linker executable. You can use the `--verbose' command line option to
-display the default linker script. Certain command line options, such
-as `-r' or `-N', will affect the default linker script.
-
- You may supply your own linker script by using the `-T' command line
-option. When you do this, your linker script will replace the default
-linker script.
-
- You may also use linker scripts implicitly by naming them as input
-files to the linker, as though they were files to be linked. *Note
-Implicit Linker Scripts::.
-
-* Menu:
-
-* Basic Script Concepts:: Basic Linker Script Concepts
-* Script Format:: Linker Script Format
-* Simple Example:: Simple Linker Script Example
-* Simple Commands:: Simple Linker Script Commands
-* Assignments:: Assigning Values to Symbols
-* SECTIONS:: SECTIONS Command
-* MEMORY:: MEMORY Command
-* PHDRS:: PHDRS Command
-* VERSION:: VERSION Command
-* Expressions:: Expressions in Linker Scripts
-* Implicit Linker Scripts:: Implicit Linker Scripts
-
-
-File: ld.info, Node: Basic Script Concepts, Next: Script Format, Up: Scripts
-
-3.1 Basic Linker Script Concepts
-================================
-
-We need to define some basic concepts and vocabulary in order to
-describe the linker script language.
-
- The linker combines input files into a single output file. The
-output file and each input file are in a special data format known as an
-"object file format". Each file is called an "object file". The
-output file is often called an "executable", but for our purposes we
-will also call it an object file. Each object file has, among other
-things, a list of "sections". We sometimes refer to a section in an
-input file as an "input section"; similarly, a section in the output
-file is an "output section".
-
- Each section in an object file has a name and a size. Most sections
-also have an associated block of data, known as the "section contents".
-A section may be marked as "loadable", which mean that the contents
-should be loaded into memory when the output file is run. A section
-with no contents may be "allocatable", which means that an area in
-memory should be set aside, but nothing in particular should be loaded
-there (in some cases this memory must be zeroed out). A section which
-is neither loadable nor allocatable typically contains some sort of
-debugging information.
-
- Every loadable or allocatable output section has two addresses. The
-first is the "VMA", or virtual memory address. This is the address the
-section will have when the output file is run. The second is the
-"LMA", or load memory address. This is the address at which the
-section will be loaded. In most cases the two addresses will be the
-same. An example of when they might be different is when a data section
-is loaded into ROM, and then copied into RAM when the program starts up
-(this technique is often used to initialize global variables in a ROM
-based system). In this case the ROM address would be the LMA, and the
-RAM address would be the VMA.
-
- You can see the sections in an object file by using the `objdump'
-program with the `-h' option.
-
- Every object file also has a list of "symbols", known as the "symbol
-table". A symbol may be defined or undefined. Each symbol has a name,
-and each defined symbol has an address, among other information. If
-you compile a C or C++ program into an object file, you will get a
-defined symbol for every defined function and global or static
-variable. Every undefined function or global variable which is
-referenced in the input file will become an undefined symbol.
-
- You can see the symbols in an object file by using the `nm' program,
-or by using the `objdump' program with the `-t' option.
-
-
-File: ld.info, Node: Script Format, Next: Simple Example, Prev: Basic Script Concepts, Up: Scripts
-
-3.2 Linker Script Format
-========================
-
-Linker scripts are text files.
-
- You write a linker script as a series of commands. Each command is
-either a keyword, possibly followed by arguments, or an assignment to a
-symbol. You may separate commands using semicolons. Whitespace is
-generally ignored.
-
- Strings such as file or format names can normally be entered
-directly. If the file name contains a character such as a comma which
-would otherwise serve to separate file names, you may put the file name
-in double quotes. There is no way to use a double quote character in a
-file name.
-
- You may include comments in linker scripts just as in C, delimited by
-`/*' and `*/'. As in C, comments are syntactically equivalent to
-whitespace.
-
-
-File: ld.info, Node: Simple Example, Next: Simple Commands, Prev: Script Format, Up: Scripts
-
-3.3 Simple Linker Script Example
-================================
-
-Many linker scripts are fairly simple.
-
- The simplest possible linker script has just one command:
-`SECTIONS'. You use the `SECTIONS' command to describe the memory
-layout of the output file.
-
- The `SECTIONS' command is a powerful command. Here we will describe
-a simple use of it. Let's assume your program consists only of code,
-initialized data, and uninitialized data. These will be in the
-`.text', `.data', and `.bss' sections, respectively. Let's assume
-further that these are the only sections which appear in your input
-files.
-
- For this example, let's say that the code should be loaded at address
-0x10000, and that the data should start at address 0x8000000. Here is a
-linker script which will do that:
- SECTIONS
- {
- . = 0x10000;
- .text : { *(.text) }
- . = 0x8000000;
- .data : { *(.data) }
- .bss : { *(.bss) }
- }
-
- You write the `SECTIONS' command as the keyword `SECTIONS', followed
-by a series of symbol assignments and output section descriptions
-enclosed in curly braces.
-
- The first line inside the `SECTIONS' command of the above example
-sets the value of the special symbol `.', which is the location
-counter. If you do not specify the address of an output section in some
-other way (other ways are described later), the address is set from the
-current value of the location counter. The location counter is then
-incremented by the size of the output section. At the start of the
-`SECTIONS' command, the location counter has the value `0'.
-
- The second line defines an output section, `.text'. The colon is
-required syntax which may be ignored for now. Within the curly braces
-after the output section name, you list the names of the input sections
-which should be placed into this output section. The `*' is a wildcard
-which matches any file name. The expression `*(.text)' means all
-`.text' input sections in all input files.
-
- Since the location counter is `0x10000' when the output section
-`.text' is defined, the linker will set the address of the `.text'
-section in the output file to be `0x10000'.
-
- The remaining lines define the `.data' and `.bss' sections in the
-output file. The linker will place the `.data' output section at
-address `0x8000000'. After the linker places the `.data' output
-section, the value of the location counter will be `0x8000000' plus the
-size of the `.data' output section. The effect is that the linker will
-place the `.bss' output section immediately after the `.data' output
-section in memory.
-
- The linker will ensure that each output section has the required
-alignment, by increasing the location counter if necessary. In this
-example, the specified addresses for the `.text' and `.data' sections
-will probably satisfy any alignment constraints, but the linker may
-have to create a small gap between the `.data' and `.bss' sections.
-
- That's it! That's a simple and complete linker script.
-
-
-File: ld.info, Node: Simple Commands, Next: Assignments, Prev: Simple Example, Up: Scripts
-
-3.4 Simple Linker Script Commands
-=================================
-
-In this section we describe the simple linker script commands.
-
-* Menu:
-
-* Entry Point:: Setting the entry point
-* File Commands:: Commands dealing with files
-
-* Format Commands:: Commands dealing with object file formats
-
-* REGION_ALIAS:: Assign alias names to memory regions
-* Miscellaneous Commands:: Other linker script commands
-
-
-File: ld.info, Node: Entry Point, Next: File Commands, Up: Simple Commands
-
-3.4.1 Setting the Entry Point
------------------------------
-
-The first instruction to execute in a program is called the "entry
-point". You can use the `ENTRY' linker script command to set the entry
-point. The argument is a symbol name:
- ENTRY(SYMBOL)
-
- There are several ways to set the entry point. The linker will set
-the entry point by trying each of the following methods in order, and
-stopping when one of them succeeds:
- * the `-e' ENTRY command-line option;
-
- * the `ENTRY(SYMBOL)' command in a linker script;
-
- * the value of a target specific symbol, if it is defined; For many
- targets this is `start', but PE and BeOS based systems for example
- check a list of possible entry symbols, matching the first one
- found.
-
- * the address of the first byte of the `.text' section, if present;
-
- * The address `0'.
-
-
-File: ld.info, Node: File Commands, Next: Format Commands, Prev: Entry Point, Up: Simple Commands
-
-3.4.2 Commands Dealing with Files
----------------------------------
-
-Several linker script commands deal with files.
-
-`INCLUDE FILENAME'
- Include the linker script FILENAME at this point. The file will
- be searched for in the current directory, and in any directory
- specified with the `-L' option. You can nest calls to `INCLUDE'
- up to 10 levels deep.
-
- You can place `INCLUDE' directives at the top level, in `MEMORY' or
- `SECTIONS' commands, or in output section descriptions.
-
-`INPUT(FILE, FILE, ...)'
-`INPUT(FILE FILE ...)'
- The `INPUT' command directs the linker to include the named files
- in the link, as though they were named on the command line.
-
- For example, if you always want to include `subr.o' any time you do
- a link, but you can't be bothered to put it on every link command
- line, then you can put `INPUT (subr.o)' in your linker script.
-
- In fact, if you like, you can list all of your input files in the
- linker script, and then invoke the linker with nothing but a `-T'
- option.
-
- In case a "sysroot prefix" is configured, and the filename starts
- with the `/' character, and the script being processed was located
- inside the "sysroot prefix", the filename will be looked for in
- the "sysroot prefix". Otherwise, the linker will try to open the
- file in the current directory. If it is not found, the linker
- will search through the archive library search path. See the
- description of `-L' in *note Command Line Options: Options.
-
- If you use `INPUT (-lFILE)', `ld' will transform the name to
- `libFILE.a', as with the command line argument `-l'.
-
- When you use the `INPUT' command in an implicit linker script, the
- files will be included in the link at the point at which the linker
- script file is included. This can affect archive searching.
-
-`GROUP(FILE, FILE, ...)'
-`GROUP(FILE FILE ...)'
- The `GROUP' command is like `INPUT', except that the named files
- should all be archives, and they are searched repeatedly until no
- new undefined references are created. See the description of `-('
- in *note Command Line Options: Options.
-
-`AS_NEEDED(FILE, FILE, ...)'
-`AS_NEEDED(FILE FILE ...)'
- This construct can appear only inside of the `INPUT' or `GROUP'
- commands, among other filenames. The files listed will be handled
- as if they appear directly in the `INPUT' or `GROUP' commands,
- with the exception of ELF shared libraries, that will be added only
- when they are actually needed. This construct essentially enables
- `--as-needed' option for all the files listed inside of it and
- restores previous `--as-needed' resp. `--no-as-needed' setting
- afterwards.
-
-`OUTPUT(FILENAME)'
- The `OUTPUT' command names the output file. Using
- `OUTPUT(FILENAME)' in the linker script is exactly like using `-o
- FILENAME' on the command line (*note Command Line Options:
- Options.). If both are used, the command line option takes
- precedence.
-
- You can use the `OUTPUT' command to define a default name for the
- output file other than the usual default of `a.out'.
-
-`SEARCH_DIR(PATH)'
- The `SEARCH_DIR' command adds PATH to the list of paths where `ld'
- looks for archive libraries. Using `SEARCH_DIR(PATH)' is exactly
- like using `-L PATH' on the command line (*note Command Line
- Options: Options.). If both are used, then the linker will search
- both paths. Paths specified using the command line option are
- searched first.
-
-`STARTUP(FILENAME)'
- The `STARTUP' command is just like the `INPUT' command, except
- that FILENAME will become the first input file to be linked, as
- though it were specified first on the command line. This may be
- useful when using a system in which the entry point is always the
- start of the first file.
-
-
-File: ld.info, Node: Format Commands, Next: REGION_ALIAS, Prev: File Commands, Up: Simple Commands
-
-3.4.3 Commands Dealing with Object File Formats
------------------------------------------------
-
-A couple of linker script commands deal with object file formats.
-
-`OUTPUT_FORMAT(BFDNAME)'
-`OUTPUT_FORMAT(DEFAULT, BIG, LITTLE)'
- The `OUTPUT_FORMAT' command names the BFD format to use for the
- output file (*note BFD::). Using `OUTPUT_FORMAT(BFDNAME)' is
- exactly like using `--oformat BFDNAME' on the command line (*note
- Command Line Options: Options.). If both are used, the command
- line option takes precedence.
-
- You can use `OUTPUT_FORMAT' with three arguments to use different
- formats based on the `-EB' and `-EL' command line options. This
- permits the linker script to set the output format based on the
- desired endianness.
-
- If neither `-EB' nor `-EL' are used, then the output format will
- be the first argument, DEFAULT. If `-EB' is used, the output
- format will be the second argument, BIG. If `-EL' is used, the
- output format will be the third argument, LITTLE.
-
- For example, the default linker script for the MIPS ELF target
- uses this command:
- OUTPUT_FORMAT(elf32-bigmips, elf32-bigmips, elf32-littlemips)
- This says that the default format for the output file is
- `elf32-bigmips', but if the user uses the `-EL' command line
- option, the output file will be created in the `elf32-littlemips'
- format.
-
-`TARGET(BFDNAME)'
- The `TARGET' command names the BFD format to use when reading input
- files. It affects subsequent `INPUT' and `GROUP' commands. This
- command is like using `-b BFDNAME' on the command line (*note
- Command Line Options: Options.). If the `TARGET' command is used
- but `OUTPUT_FORMAT' is not, then the last `TARGET' command is also
- used to set the format for the output file. *Note BFD::.
-
-
-File: ld.info, Node: REGION_ALIAS, Next: Miscellaneous Commands, Prev: Format Commands, Up: Simple Commands
-
-3.4.4 Assign alias names to memory regions
-------------------------------------------
-
-Alias names can be added to existing memory regions created with the
-*note MEMORY:: command. Each name corresponds to at most one memory
-region.
-
- REGION_ALIAS(ALIAS, REGION)
-
- The `REGION_ALIAS' function creates an alias name ALIAS for the
-memory region REGION. This allows a flexible mapping of output sections
-to memory regions. An example follows.
-
- Suppose we have an application for embedded systems which come with
-various memory storage devices. All have a general purpose, volatile
-memory `RAM' that allows code execution or data storage. Some may have
-a read-only, non-volatile memory `ROM' that allows code execution and
-read-only data access. The last variant is a read-only, non-volatile
-memory `ROM2' with read-only data access and no code execution
-capability. We have four output sections:
-
- * `.text' program code;
-
- * `.rodata' read-only data;
-
- * `.data' read-write initialized data;
-
- * `.bss' read-write zero initialized data.
-
- The goal is to provide a linker command file that contains a system
-independent part defining the output sections and a system dependent
-part mapping the output sections to the memory regions available on the
-system. Our embedded systems come with three different memory setups
-`A', `B' and `C':
-Section Variant A Variant B Variant C
-.text RAM ROM ROM
-.rodata RAM ROM ROM2
-.data RAM RAM/ROM RAM/ROM2
-.bss RAM RAM RAM
- The notation `RAM/ROM' or `RAM/ROM2' means that this section is
-loaded into region `ROM' or `ROM2' respectively. Please note that the
-load address of the `.data' section starts in all three variants at the
-end of the `.rodata' section.
-
- The base linker script that deals with the output sections follows.
-It includes the system dependent `linkcmds.memory' file that describes
-the memory layout:
- INCLUDE linkcmds.memory
-
- SECTIONS
- {
- .text :
- {
- *(.text)
- } > REGION_TEXT
- .rodata :
- {
- *(.rodata)
- rodata_end = .;
- } > REGION_RODATA
- .data : AT (rodata_end)
- {
- data_start = .;
- *(.data)
- } > REGION_DATA
- data_size = SIZEOF(.data);
- data_load_start = LOADADDR(.data);
- .bss :
- {
- *(.bss)
- } > REGION_BSS
- }
-
- Now we need three different `linkcmds.memory' files to define memory
-regions and alias names. The content of `linkcmds.memory' for the three
-variants `A', `B' and `C':
-`A'
- Here everything goes into the `RAM'.
- MEMORY
- {
- RAM : ORIGIN = 0, LENGTH = 4M
- }
-
- REGION_ALIAS("REGION_TEXT", RAM);
- REGION_ALIAS("REGION_RODATA", RAM);
- REGION_ALIAS("REGION_DATA", RAM);
- REGION_ALIAS("REGION_BSS", RAM);
-
-`B'
- Program code and read-only data go into the `ROM'. Read-write
- data goes into the `RAM'. An image of the initialized data is
- loaded into the `ROM' and will be copied during system start into
- the `RAM'.
- MEMORY
- {
- ROM : ORIGIN = 0, LENGTH = 3M
- RAM : ORIGIN = 0x10000000, LENGTH = 1M
- }
-
- REGION_ALIAS("REGION_TEXT", ROM);
- REGION_ALIAS("REGION_RODATA", ROM);
- REGION_ALIAS("REGION_DATA", RAM);
- REGION_ALIAS("REGION_BSS", RAM);
-
-`C'
- Program code goes into the `ROM'. Read-only data goes into the
- `ROM2'. Read-write data goes into the `RAM'. An image of the
- initialized data is loaded into the `ROM2' and will be copied
- during system start into the `RAM'.
- MEMORY
- {
- ROM : ORIGIN = 0, LENGTH = 2M
- ROM2 : ORIGIN = 0x10000000, LENGTH = 1M
- RAM : ORIGIN = 0x20000000, LENGTH = 1M
- }
-
- REGION_ALIAS("REGION_TEXT", ROM);
- REGION_ALIAS("REGION_RODATA", ROM2);
- REGION_ALIAS("REGION_DATA", RAM);
- REGION_ALIAS("REGION_BSS", RAM);
-
- It is possible to write a common system initialization routine to
-copy the `.data' section from `ROM' or `ROM2' into the `RAM' if
-necessary:
- #include <string.h>
-
- extern char data_start [];
- extern char data_size [];
- extern char data_load_start [];
-
- void copy_data(void)
- {
- if (data_start != data_load_start)
- {
- memcpy(data_start, data_load_start, (size_t) data_size);
- }
- }
-
-
-File: ld.info, Node: Miscellaneous Commands, Prev: REGION_ALIAS, Up: Simple Commands
-
-3.4.5 Other Linker Script Commands
-----------------------------------
-
-There are a few other linker scripts commands.
-
-`ASSERT(EXP, MESSAGE)'
- Ensure that EXP is non-zero. If it is zero, then exit the linker
- with an error code, and print MESSAGE.
-
-`EXTERN(SYMBOL SYMBOL ...)'
- Force SYMBOL to be entered in the output file as an undefined
- symbol. Doing this may, for example, trigger linking of additional
- modules from standard libraries. You may list several SYMBOLs for
- each `EXTERN', and you may use `EXTERN' multiple times. This
- command has the same effect as the `-u' command-line option.
-
-`FORCE_COMMON_ALLOCATION'
- This command has the same effect as the `-d' command-line option:
- to make `ld' assign space to common symbols even if a relocatable
- output file is specified (`-r').
-
-`INHIBIT_COMMON_ALLOCATION'
- This command has the same effect as the `--no-define-common'
- command-line option: to make `ld' omit the assignment of addresses
- to common symbols even for a non-relocatable output file.
-
-`INSERT [ AFTER | BEFORE ] OUTPUT_SECTION'
- This command is typically used in a script specified by `-T' to
- augment the default `SECTIONS' with, for example, overlays. It
- inserts all prior linker script statements after (or before)
- OUTPUT_SECTION, and also causes `-T' to not override the default
- linker script. The exact insertion point is as for orphan
- sections. *Note Location Counter::. The insertion happens after
- the linker has mapped input sections to output sections. Prior to
- the insertion, since `-T' scripts are parsed before the default
- linker script, statements in the `-T' script occur before the
- default linker script statements in the internal linker
- representation of the script. In particular, input section
- assignments will be made to `-T' output sections before those in
- the default script. Here is an example of how a `-T' script using
- `INSERT' might look:
-
- SECTIONS
- {
- OVERLAY :
- {
- .ov1 { ov1*(.text) }
- .ov2 { ov2*(.text) }
- }
- }
- INSERT AFTER .text;
-
-`NOCROSSREFS(SECTION SECTION ...)'
- This command may be used to tell `ld' to issue an error about any
- references among certain output sections.
-
- In certain types of programs, particularly on embedded systems when
- using overlays, when one section is loaded into memory, another
- section will not be. Any direct references between the two
- sections would be errors. For example, it would be an error if
- code in one section called a function defined in the other section.
-
- The `NOCROSSREFS' command takes a list of output section names. If
- `ld' detects any cross references between the sections, it reports
- an error and returns a non-zero exit status. Note that the
- `NOCROSSREFS' command uses output section names, not input section
- names.
-
-`OUTPUT_ARCH(BFDARCH)'
- Specify a particular output machine architecture. The argument is
- one of the names used by the BFD library (*note BFD::). You can
- see the architecture of an object file by using the `objdump'
- program with the `-f' option.
-
-
-File: ld.info, Node: Assignments, Next: SECTIONS, Prev: Simple Commands, Up: Scripts
-
-3.5 Assigning Values to Symbols
-===============================
-
-You may assign a value to a symbol in a linker script. This will define
-the symbol and place it into the symbol table with a global scope.
-
-* Menu:
-
-* Simple Assignments:: Simple Assignments
-* PROVIDE:: PROVIDE
-* PROVIDE_HIDDEN:: PROVIDE_HIDDEN
-* Source Code Reference:: How to use a linker script defined symbol in source code
-
-
-File: ld.info, Node: Simple Assignments, Next: PROVIDE, Up: Assignments
-
-3.5.1 Simple Assignments
-------------------------
-
-You may assign to a symbol using any of the C assignment operators:
-
-`SYMBOL = EXPRESSION ;'
-`SYMBOL += EXPRESSION ;'
-`SYMBOL -= EXPRESSION ;'
-`SYMBOL *= EXPRESSION ;'
-`SYMBOL /= EXPRESSION ;'
-`SYMBOL <<= EXPRESSION ;'
-`SYMBOL >>= EXPRESSION ;'
-`SYMBOL &= EXPRESSION ;'
-`SYMBOL |= EXPRESSION ;'
-
- The first case will define SYMBOL to the value of EXPRESSION. In
-the other cases, SYMBOL must already be defined, and the value will be
-adjusted accordingly.
-
- The special symbol name `.' indicates the location counter. You may
-only use this within a `SECTIONS' command. *Note Location Counter::.
-
- The semicolon after EXPRESSION is required.
-
- Expressions are defined below; see *note Expressions::.
-
- You may write symbol assignments as commands in their own right, or
-as statements within a `SECTIONS' command, or as part of an output
-section description in a `SECTIONS' command.
-
- The section of the symbol will be set from the section of the
-expression; for more information, see *note Expression Section::.
-
- Here is an example showing the three different places that symbol
-assignments may be used:
-
- floating_point = 0;
- SECTIONS
- {
- .text :
- {
- *(.text)
- _etext = .;
- }
- _bdata = (. + 3) & ~ 3;
- .data : { *(.data) }
- }
- In this example, the symbol `floating_point' will be defined as
-zero. The symbol `_etext' will be defined as the address following the
-last `.text' input section. The symbol `_bdata' will be defined as the
-address following the `.text' output section aligned upward to a 4 byte
-boundary.
-
-
-File: ld.info, Node: PROVIDE, Next: PROVIDE_HIDDEN, Prev: Simple Assignments, Up: Assignments
-
-3.5.2 PROVIDE
--------------
-
-In some cases, it is desirable for a linker script to define a symbol
-only if it is referenced and is not defined by any object included in
-the link. For example, traditional linkers defined the symbol `etext'.
-However, ANSI C requires that the user be able to use `etext' as a
-function name without encountering an error. The `PROVIDE' keyword may
-be used to define a symbol, such as `etext', only if it is referenced
-but not defined. The syntax is `PROVIDE(SYMBOL = EXPRESSION)'.
-
- Here is an example of using `PROVIDE' to define `etext':
- SECTIONS
- {
- .text :
- {
- *(.text)
- _etext = .;
- PROVIDE(etext = .);
- }
- }
-
- In this example, if the program defines `_etext' (with a leading
-underscore), the linker will give a multiple definition error. If, on
-the other hand, the program defines `etext' (with no leading
-underscore), the linker will silently use the definition in the program.
-If the program references `etext' but does not define it, the linker
-will use the definition in the linker script.
-
-
-File: ld.info, Node: PROVIDE_HIDDEN, Next: Source Code Reference, Prev: PROVIDE, Up: Assignments
-
-3.5.3 PROVIDE_HIDDEN
---------------------
-
-Similar to `PROVIDE'. For ELF targeted ports, the symbol will be
-hidden and won't be exported.
-
-
-File: ld.info, Node: Source Code Reference, Prev: PROVIDE_HIDDEN, Up: Assignments
-
-3.5.4 Source Code Reference
----------------------------
-
-Accessing a linker script defined variable from source code is not
-intuitive. In particular a linker script symbol is not equivalent to a
-variable declaration in a high level language, it is instead a symbol
-that does not have a value.
-
- Before going further, it is important to note that compilers often
-transform names in the source code into different names when they are
-stored in the symbol table. For example, Fortran compilers commonly
-prepend or append an underscore, and C++ performs extensive `name
-mangling'. Therefore there might be a discrepancy between the name of
-a variable as it is used in source code and the name of the same
-variable as it is defined in a linker script. For example in C a
-linker script variable might be referred to as:
-
- extern int foo;
-
- But in the linker script it might be defined as:
-
- _foo = 1000;
-
- In the remaining examples however it is assumed that no name
-transformation has taken place.
-
- When a symbol is declared in a high level language such as C, two
-things happen. The first is that the compiler reserves enough space in
-the program's memory to hold the _value_ of the symbol. The second is
-that the compiler creates an entry in the program's symbol table which
-holds the symbol's _address_. ie the symbol table contains the address
-of the block of memory holding the symbol's value. So for example the
-following C declaration, at file scope:
-
- int foo = 1000;
-
- creates a entry called `foo' in the symbol table. This entry holds
-the address of an `int' sized block of memory where the number 1000 is
-initially stored.
-
- When a program references a symbol the compiler generates code that
-first accesses the symbol table to find the address of the symbol's
-memory block and then code to read the value from that memory block.
-So:
-
- foo = 1;
-
- looks up the symbol `foo' in the symbol table, gets the address
-associated with this symbol and then writes the value 1 into that
-address. Whereas:
-
- int * a = & foo;
-
- looks up the symbol `foo' in the symbol table, gets it address and
-then copies this address into the block of memory associated with the
-variable `a'.
-
- Linker scripts symbol declarations, by contrast, create an entry in
-the symbol table but do not assign any memory to them. Thus they are
-an address without a value. So for example the linker script
-definition:
-
- foo = 1000;
-
- creates an entry in the symbol table called `foo' which holds the
-address of memory location 1000, but nothing special is stored at
-address 1000. This means that you cannot access the _value_ of a
-linker script defined symbol - it has no value - all you can do is
-access the _address_ of a linker script defined symbol.
-
- Hence when you are using a linker script defined symbol in source
-code you should always take the address of the symbol, and never
-attempt to use its value. For example suppose you want to copy the
-contents of a section of memory called .ROM into a section called
-.FLASH and the linker script contains these declarations:
-
- start_of_ROM = .ROM;
- end_of_ROM = .ROM + sizeof (.ROM) - 1;
- start_of_FLASH = .FLASH;
-
- Then the C source code to perform the copy would be:
-
- extern char start_of_ROM, end_of_ROM, start_of_FLASH;
-
- memcpy (& start_of_FLASH, & start_of_ROM, & end_of_ROM - & start_of_ROM);
-
- Note the use of the `&' operators. These are correct.
-
-
-File: ld.info, Node: SECTIONS, Next: MEMORY, Prev: Assignments, Up: Scripts
-
-3.6 SECTIONS Command
-====================
-
-The `SECTIONS' command tells the linker how to map input sections into
-output sections, and how to place the output sections in memory.
-
- The format of the `SECTIONS' command is:
- SECTIONS
- {
- SECTIONS-COMMAND
- SECTIONS-COMMAND
- ...
- }
-
- Each SECTIONS-COMMAND may of be one of the following:
-
- * an `ENTRY' command (*note Entry command: Entry Point.)
-
- * a symbol assignment (*note Assignments::)
-
- * an output section description
-
- * an overlay description
-
- The `ENTRY' command and symbol assignments are permitted inside the
-`SECTIONS' command for convenience in using the location counter in
-those commands. This can also make the linker script easier to
-understand because you can use those commands at meaningful points in
-the layout of the output file.
-
- Output section descriptions and overlay descriptions are described
-below.
-
- If you do not use a `SECTIONS' command in your linker script, the
-linker will place each input section into an identically named output
-section in the order that the sections are first encountered in the
-input files. If all input sections are present in the first file, for
-example, the order of sections in the output file will match the order
-in the first input file. The first section will be at address zero.
-
-* Menu:
-
-* Output Section Description:: Output section description
-* Output Section Name:: Output section name
-* Output Section Address:: Output section address
-* Input Section:: Input section description
-* Output Section Data:: Output section data
-* Output Section Keywords:: Output section keywords
-* Output Section Discarding:: Output section discarding
-* Output Section Attributes:: Output section attributes
-* Overlay Description:: Overlay description
-
-
-File: ld.info, Node: Output Section Description, Next: Output Section Name, Up: SECTIONS
-
-3.6.1 Output Section Description
---------------------------------
-
-The full description of an output section looks like this:
- SECTION [ADDRESS] [(TYPE)] :
- [AT(LMA)]
- [ALIGN(SECTION_ALIGN)]
- [SUBALIGN(SUBSECTION_ALIGN)]
- [CONSTRAINT]
- {
- OUTPUT-SECTION-COMMAND
- OUTPUT-SECTION-COMMAND
- ...
- } [>REGION] [AT>LMA_REGION] [:PHDR :PHDR ...] [=FILLEXP]
-
- Most output sections do not use most of the optional section
-attributes.
-
- The whitespace around SECTION is required, so that the section name
-is unambiguous. The colon and the curly braces are also required. The
-line breaks and other white space are optional.
-
- Each OUTPUT-SECTION-COMMAND may be one of the following:
-
- * a symbol assignment (*note Assignments::)
-
- * an input section description (*note Input Section::)
-
- * data values to include directly (*note Output Section Data::)
-
- * a special output section keyword (*note Output Section Keywords::)
-
-
-File: ld.info, Node: Output Section Name, Next: Output Section Address, Prev: Output Section Description, Up: SECTIONS
-
-3.6.2 Output Section Name
--------------------------
-
-The name of the output section is SECTION. SECTION must meet the
-constraints of your output format. In formats which only support a
-limited number of sections, such as `a.out', the name must be one of
-the names supported by the format (`a.out', for example, allows only
-`.text', `.data' or `.bss'). If the output format supports any number
-of sections, but with numbers and not names (as is the case for Oasys),
-the name should be supplied as a quoted numeric string. A section name
-may consist of any sequence of characters, but a name which contains
-any unusual characters such as commas must be quoted.
-
- The output section name `/DISCARD/' is special; *note Output Section
-Discarding::.
-
-
-File: ld.info, Node: Output Section Address, Next: Input Section, Prev: Output Section Name, Up: SECTIONS
-
-3.6.3 Output Section Address
-----------------------------
-
-The ADDRESS is an expression for the VMA (the virtual memory address)
-of the output section. This address is optional, but if it is provided
-then the output address will be set exactly as specified.
-
- If the output address is not specified then one will be chosen for
-the section, based on the heuristic below. This address will be
-adjusted to fit the alignment requirement of the output section. The
-alignment requirement is the strictest alignment of any input section
-contained within the output section.
-
- The output section address heuristic is as follows:
-
- * If an output memory REGION is set for the section then it is added
- to this region and its address will be the next free address in
- that region.
-
- * If the MEMORY command has been used to create a list of memory
- regions then the first region which has attributes compatible with
- the section is selected to contain it. The section's output
- address will be the next free address in that region; *note
- MEMORY::.
-
- * If no memory regions were specified, or none match the section then
- the output address will be based on the current value of the
- location counter.
-
-For example:
-
- .text . : { *(.text) }
-
-and
-
- .text : { *(.text) }
-
-are subtly different. The first will set the address of the `.text'
-output section to the current value of the location counter. The
-second will set it to the current value of the location counter aligned
-to the strictest alignment of any of the `.text' input sections.
-
- The ADDRESS may be an arbitrary expression; *note Expressions::.
-For example, if you want to align the section on a 0x10 byte boundary,
-so that the lowest four bits of the section address are zero, you could
-do something like this:
- .text ALIGN(0x10) : { *(.text) }
- This works because `ALIGN' returns the current location counter
-aligned upward to the specified value.
-
- Specifying ADDRESS for a section will change the value of the
-location counter, provided that the section is non-empty. (Empty
-sections are ignored).
-
-
-File: ld.info, Node: Input Section, Next: Output Section Data, Prev: Output Section Address, Up: SECTIONS
-
-3.6.4 Input Section Description
--------------------------------
-
-The most common output section command is an input section description.
-
- The input section description is the most basic linker script
-operation. You use output sections to tell the linker how to lay out
-your program in memory. You use input section descriptions to tell the
-linker how to map the input files into your memory layout.
-
-* Menu:
-
-* Input Section Basics:: Input section basics
-* Input Section Wildcards:: Input section wildcard patterns
-* Input Section Common:: Input section for common symbols
-* Input Section Keep:: Input section and garbage collection
-* Input Section Example:: Input section example
-
-
-File: ld.info, Node: Input Section Basics, Next: Input Section Wildcards, Up: Input Section
-
-3.6.4.1 Input Section Basics
-............................
-
-An input section description consists of a file name optionally followed
-by a list of section names in parentheses.
-
- The file name and the section name may be wildcard patterns, which we
-describe further below (*note Input Section Wildcards::).
-
- The most common input section description is to include all input
-sections with a particular name in the output section. For example, to
-include all input `.text' sections, you would write:
- *(.text)
- Here the `*' is a wildcard which matches any file name. To exclude
-a list of files from matching the file name wildcard, EXCLUDE_FILE may
-be used to match all files except the ones specified in the
-EXCLUDE_FILE list. For example:
- *(EXCLUDE_FILE (*crtend.o *otherfile.o) .ctors)
- will cause all .ctors sections from all files except `crtend.o' and
-`otherfile.o' to be included.
-
- There are two ways to include more than one section:
- *(.text .rdata)
- *(.text) *(.rdata)
- The difference between these is the order in which the `.text' and
-`.rdata' input sections will appear in the output section. In the
-first example, they will be intermingled, appearing in the same order as
-they are found in the linker input. In the second example, all `.text'
-input sections will appear first, followed by all `.rdata' input
-sections.
-
- You can specify a file name to include sections from a particular
-file. You would do this if one or more of your files contain special
-data that needs to be at a particular location in memory. For example:
- data.o(.data)
-
- You can also specify files within archives by writing a pattern
-matching the archive, a colon, then the pattern matching the file, with
-no whitespace around the colon.
-
-`archive:file'
- matches file within archive
-
-`archive:'
- matches the whole archive
-
-`:file'
- matches file but not one in an archive
-
- Either one or both of `archive' and `file' can contain shell
-wildcards. On DOS based file systems, the linker will assume that a
-single letter followed by a colon is a drive specifier, so `c:myfile.o'
-is a simple file specification, not `myfile.o' within an archive called
-`c'. `archive:file' filespecs may also be used within an
-`EXCLUDE_FILE' list, but may not appear in other linker script
-contexts. For instance, you cannot extract a file from an archive by
-using `archive:file' in an `INPUT' command.
-
- If you use a file name without a list of sections, then all sections
-in the input file will be included in the output section. This is not
-commonly done, but it may by useful on occasion. For example:
- data.o
-
- When you use a file name which is not an `archive:file' specifier
-and does not contain any wild card characters, the linker will first
-see if you also specified the file name on the linker command line or
-in an `INPUT' command. If you did not, the linker will attempt to open
-the file as an input file, as though it appeared on the command line.
-Note that this differs from an `INPUT' command, because the linker will
-not search for the file in the archive search path.
-
-
-File: ld.info, Node: Input Section Wildcards, Next: Input Section Common, Prev: Input Section Basics, Up: Input Section
-
-3.6.4.2 Input Section Wildcard Patterns
-.......................................
-
-In an input section description, either the file name or the section
-name or both may be wildcard patterns.
-
- The file name of `*' seen in many examples is a simple wildcard
-pattern for the file name.
-
- The wildcard patterns are like those used by the Unix shell.
-
-`*'
- matches any number of characters
-
-`?'
- matches any single character
-
-`[CHARS]'
- matches a single instance of any of the CHARS; the `-' character
- may be used to specify a range of characters, as in `[a-z]' to
- match any lower case letter
-
-`\'
- quotes the following character
-
- When a file name is matched with a wildcard, the wildcard characters
-will not match a `/' character (used to separate directory names on
-Unix). A pattern consisting of a single `*' character is an exception;
-it will always match any file name, whether it contains a `/' or not.
-In a section name, the wildcard characters will match a `/' character.
-
- File name wildcard patterns only match files which are explicitly
-specified on the command line or in an `INPUT' command. The linker
-does not search directories to expand wildcards.
-
- If a file name matches more than one wildcard pattern, or if a file
-name appears explicitly and is also matched by a wildcard pattern, the
-linker will use the first match in the linker script. For example, this
-sequence of input section descriptions is probably in error, because the
-`data.o' rule will not be used:
- .data : { *(.data) }
- .data1 : { data.o(.data) }
-
- Normally, the linker will place files and sections matched by
-wildcards in the order in which they are seen during the link. You can
-change this by using the `SORT_BY_NAME' keyword, which appears before a
-wildcard pattern in parentheses (e.g., `SORT_BY_NAME(.text*)'). When
-the `SORT_BY_NAME' keyword is used, the linker will sort the files or
-sections into ascending order by name before placing them in the output
-file.
-
- `SORT_BY_ALIGNMENT' is very similar to `SORT_BY_NAME'. The
-difference is `SORT_BY_ALIGNMENT' will sort sections into ascending
-order by alignment before placing them in the output file.
-
- `SORT' is an alias for `SORT_BY_NAME'.
-
- When there are nested section sorting commands in linker script,
-there can be at most 1 level of nesting for section sorting commands.
-
- 1. `SORT_BY_NAME' (`SORT_BY_ALIGNMENT' (wildcard section pattern)).
- It will sort the input sections by name first, then by alignment
- if 2 sections have the same name.
-
- 2. `SORT_BY_ALIGNMENT' (`SORT_BY_NAME' (wildcard section pattern)).
- It will sort the input sections by alignment first, then by name
- if 2 sections have the same alignment.
-
- 3. `SORT_BY_NAME' (`SORT_BY_NAME' (wildcard section pattern)) is
- treated the same as `SORT_BY_NAME' (wildcard section pattern).
-
- 4. `SORT_BY_ALIGNMENT' (`SORT_BY_ALIGNMENT' (wildcard section
- pattern)) is treated the same as `SORT_BY_ALIGNMENT' (wildcard
- section pattern).
-
- 5. All other nested section sorting commands are invalid.
-
- When both command line section sorting option and linker script
-section sorting command are used, section sorting command always takes
-precedence over the command line option.
-
- If the section sorting command in linker script isn't nested, the
-command line option will make the section sorting command to be treated
-as nested sorting command.
-
- 1. `SORT_BY_NAME' (wildcard section pattern ) with `--sort-sections
- alignment' is equivalent to `SORT_BY_NAME' (`SORT_BY_ALIGNMENT'
- (wildcard section pattern)).
-
- 2. `SORT_BY_ALIGNMENT' (wildcard section pattern) with
- `--sort-section name' is equivalent to `SORT_BY_ALIGNMENT'
- (`SORT_BY_NAME' (wildcard section pattern)).
-
- If the section sorting command in linker script is nested, the
-command line option will be ignored.
-
- If you ever get confused about where input sections are going, use
-the `-M' linker option to generate a map file. The map file shows
-precisely how input sections are mapped to output sections.
-
- This example shows how wildcard patterns might be used to partition
-files. This linker script directs the linker to place all `.text'
-sections in `.text' and all `.bss' sections in `.bss'. The linker will
-place the `.data' section from all files beginning with an upper case
-character in `.DATA'; for all other files, the linker will place the
-`.data' section in `.data'.
- SECTIONS {
- .text : { *(.text) }
- .DATA : { [A-Z]*(.data) }
- .data : { *(.data) }
- .bss : { *(.bss) }
- }
-
-
-File: ld.info, Node: Input Section Common, Next: Input Section Keep, Prev: Input Section Wildcards, Up: Input Section
-
-3.6.4.3 Input Section for Common Symbols
-........................................
-
-A special notation is needed for common symbols, because in many object
-file formats common symbols do not have a particular input section. The
-linker treats common symbols as though they are in an input section
-named `COMMON'.
-
- You may use file names with the `COMMON' section just as with any
-other input sections. You can use this to place common symbols from a
-particular input file in one section while common symbols from other
-input files are placed in another section.
-
- In most cases, common symbols in input files will be placed in the
-`.bss' section in the output file. For example:
- .bss { *(.bss) *(COMMON) }
-
- Some object file formats have more than one type of common symbol.
-For example, the MIPS ELF object file format distinguishes standard
-common symbols and small common symbols. In this case, the linker will
-use a different special section name for other types of common symbols.
-In the case of MIPS ELF, the linker uses `COMMON' for standard common
-symbols and `.scommon' for small common symbols. This permits you to
-map the different types of common symbols into memory at different
-locations.
-
- You will sometimes see `[COMMON]' in old linker scripts. This
-notation is now considered obsolete. It is equivalent to `*(COMMON)'.
-
-
-File: ld.info, Node: Input Section Keep, Next: Input Section Example, Prev: Input Section Common, Up: Input Section
-
-3.6.4.4 Input Section and Garbage Collection
-............................................
-
-When link-time garbage collection is in use (`--gc-sections'), it is
-often useful to mark sections that should not be eliminated. This is
-accomplished by surrounding an input section's wildcard entry with
-`KEEP()', as in `KEEP(*(.init))' or `KEEP(SORT_BY_NAME(*)(.ctors))'.
-
-
-File: ld.info, Node: Input Section Example, Prev: Input Section Keep, Up: Input Section
-
-3.6.4.5 Input Section Example
-.............................
-
-The following example is a complete linker script. It tells the linker
-to read all of the sections from file `all.o' and place them at the
-start of output section `outputa' which starts at location `0x10000'.
-All of section `.input1' from file `foo.o' follows immediately, in the
-same output section. All of section `.input2' from `foo.o' goes into
-output section `outputb', followed by section `.input1' from `foo1.o'.
-All of the remaining `.input1' and `.input2' sections from any files
-are written to output section `outputc'.
-
- SECTIONS {
- outputa 0x10000 :
- {
- all.o
- foo.o (.input1)
- }
- outputb :
- {
- foo.o (.input2)
- foo1.o (.input1)
- }
- outputc :
- {
- *(.input1)
- *(.input2)
- }
- }
-
-
-File: ld.info, Node: Output Section Data, Next: Output Section Keywords, Prev: Input Section, Up: SECTIONS
-
-3.6.5 Output Section Data
--------------------------
-
-You can include explicit bytes of data in an output section by using
-`BYTE', `SHORT', `LONG', `QUAD', or `SQUAD' as an output section
-command. Each keyword is followed by an expression in parentheses
-providing the value to store (*note Expressions::). The value of the
-expression is stored at the current value of the location counter.
-
- The `BYTE', `SHORT', `LONG', and `QUAD' commands store one, two,
-four, and eight bytes (respectively). After storing the bytes, the
-location counter is incremented by the number of bytes stored.
-
- For example, this will store the byte 1 followed by the four byte
-value of the symbol `addr':
- BYTE(1)
- LONG(addr)
-
- When using a 64 bit host or target, `QUAD' and `SQUAD' are the same;
-they both store an 8 byte, or 64 bit, value. When both host and target
-are 32 bits, an expression is computed as 32 bits. In this case `QUAD'
-stores a 32 bit value zero extended to 64 bits, and `SQUAD' stores a 32
-bit value sign extended to 64 bits.
-
- If the object file format of the output file has an explicit
-endianness, which is the normal case, the value will be stored in that
-endianness. When the object file format does not have an explicit
-endianness, as is true of, for example, S-records, the value will be
-stored in the endianness of the first input object file.
-
- Note--these commands only work inside a section description and not
-between them, so the following will produce an error from the linker:
- SECTIONS { .text : { *(.text) } LONG(1) .data : { *(.data) } }
- whereas this will work:
- SECTIONS { .text : { *(.text) ; LONG(1) } .data : { *(.data) } }
-
- You may use the `FILL' command to set the fill pattern for the
-current section. It is followed by an expression in parentheses. Any
-otherwise unspecified regions of memory within the section (for example,
-gaps left due to the required alignment of input sections) are filled
-with the value of the expression, repeated as necessary. A `FILL'
-statement covers memory locations after the point at which it occurs in
-the section definition; by including more than one `FILL' statement,
-you can have different fill patterns in different parts of an output
-section.
-
- This example shows how to fill unspecified regions of memory with the
-value `0x90':
- FILL(0x90909090)
-
- The `FILL' command is similar to the `=FILLEXP' output section
-attribute, but it only affects the part of the section following the
-`FILL' command, rather than the entire section. If both are used, the
-`FILL' command takes precedence. *Note Output Section Fill::, for
-details on the fill expression.
-
-
-File: ld.info, Node: Output Section Keywords, Next: Output Section Discarding, Prev: Output Section Data, Up: SECTIONS
-
-3.6.6 Output Section Keywords
------------------------------
-
-There are a couple of keywords which can appear as output section
-commands.
-
-`CREATE_OBJECT_SYMBOLS'
- The command tells the linker to create a symbol for each input
- file. The name of each symbol will be the name of the
- corresponding input file. The section of each symbol will be the
- output section in which the `CREATE_OBJECT_SYMBOLS' command
- appears.
-
- This is conventional for the a.out object file format. It is not
- normally used for any other object file format.
-
-`CONSTRUCTORS'
- When linking using the a.out object file format, the linker uses an
- unusual set construct to support C++ global constructors and
- destructors. When linking object file formats which do not support
- arbitrary sections, such as ECOFF and XCOFF, the linker will
- automatically recognize C++ global constructors and destructors by
- name. For these object file formats, the `CONSTRUCTORS' command
- tells the linker to place constructor information in the output
- section where the `CONSTRUCTORS' command appears. The
- `CONSTRUCTORS' command is ignored for other object file formats.
-
- The symbol `__CTOR_LIST__' marks the start of the global
- constructors, and the symbol `__CTOR_END__' marks the end.
- Similarly, `__DTOR_LIST__' and `__DTOR_END__' mark the start and
- end of the global destructors. The first word in the list is the
- number of entries, followed by the address of each constructor or
- destructor, followed by a zero word. The compiler must arrange to
- actually run the code. For these object file formats GNU C++
- normally calls constructors from a subroutine `__main'; a call to
- `__main' is automatically inserted into the startup code for
- `main'. GNU C++ normally runs destructors either by using
- `atexit', or directly from the function `exit'.
-
- For object file formats such as `COFF' or `ELF' which support
- arbitrary section names, GNU C++ will normally arrange to put the
- addresses of global constructors and destructors into the `.ctors'
- and `.dtors' sections. Placing the following sequence into your
- linker script will build the sort of table which the GNU C++
- runtime code expects to see.
-
- __CTOR_LIST__ = .;
- LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
- *(.ctors)
- LONG(0)
- __CTOR_END__ = .;
- __DTOR_LIST__ = .;
- LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
- *(.dtors)
- LONG(0)
- __DTOR_END__ = .;
-
- If you are using the GNU C++ support for initialization priority,
- which provides some control over the order in which global
- constructors are run, you must sort the constructors at link time
- to ensure that they are executed in the correct order. When using
- the `CONSTRUCTORS' command, use `SORT_BY_NAME(CONSTRUCTORS)'
- instead. When using the `.ctors' and `.dtors' sections, use
- `*(SORT_BY_NAME(.ctors))' and `*(SORT_BY_NAME(.dtors))' instead of
- just `*(.ctors)' and `*(.dtors)'.
-
- Normally the compiler and linker will handle these issues
- automatically, and you will not need to concern yourself with
- them. However, you may need to consider this if you are using C++
- and writing your own linker scripts.
-
-
-
-File: ld.info, Node: Output Section Discarding, Next: Output Section Attributes, Prev: Output Section Keywords, Up: SECTIONS
-
-3.6.7 Output Section Discarding
--------------------------------
-
-The linker will not create output sections with no contents. This is
-for convenience when referring to input sections that may or may not be
-present in any of the input files. For example:
- .foo : { *(.foo) }
- will only create a `.foo' section in the output file if there is a
-`.foo' section in at least one input file, and if the input sections
-are not all empty. Other link script directives that allocate space in
-an output section will also create the output section.
-
- The linker will ignore address assignments (*note Output Section
-Address::) on discarded output sections, except when the linker script
-defines symbols in the output section. In that case the linker will
-obey the address assignments, possibly advancing dot even though the
-section is discarded.
-
- The special output section name `/DISCARD/' may be used to discard
-input sections. Any input sections which are assigned to an output
-section named `/DISCARD/' are not included in the output file.
-
-
-File: ld.info, Node: Output Section Attributes, Next: Overlay Description, Prev: Output Section Discarding, Up: SECTIONS
-
-3.6.8 Output Section Attributes
--------------------------------
-
-We showed above that the full description of an output section looked
-like this:
-
- SECTION [ADDRESS] [(TYPE)] :
- [AT(LMA)]
- [ALIGN(SECTION_ALIGN)]
- [SUBALIGN(SUBSECTION_ALIGN)]
- [CONSTRAINT]
- {
- OUTPUT-SECTION-COMMAND
- OUTPUT-SECTION-COMMAND
- ...
- } [>REGION] [AT>LMA_REGION] [:PHDR :PHDR ...] [=FILLEXP]
-
- We've already described SECTION, ADDRESS, and
-OUTPUT-SECTION-COMMAND. In this section we will describe the remaining
-section attributes.
-
-* Menu:
-
-* Output Section Type:: Output section type
-* Output Section LMA:: Output section LMA
-* Forced Output Alignment:: Forced Output Alignment
-* Forced Input Alignment:: Forced Input Alignment
-* Output Section Constraint:: Output section constraint
-* Output Section Region:: Output section region
-* Output Section Phdr:: Output section phdr
-* Output Section Fill:: Output section fill
-
-
-File: ld.info, Node: Output Section Type, Next: Output Section LMA, Up: Output Section Attributes
-
-3.6.8.1 Output Section Type
-...........................
-
-Each output section may have a type. The type is a keyword in
-parentheses. The following types are defined:
-
-`NOLOAD'
- The section should be marked as not loadable, so that it will not
- be loaded into memory when the program is run.
-
-`DSECT'
-`COPY'
-`INFO'
-`OVERLAY'
- These type names are supported for backward compatibility, and are
- rarely used. They all have the same effect: the section should be
- marked as not allocatable, so that no memory is allocated for the
- section when the program is run.
-
- The linker normally sets the attributes of an output section based on
-the input sections which map into it. You can override this by using
-the section type. For example, in the script sample below, the `ROM'
-section is addressed at memory location `0' and does not need to be
-loaded when the program is run.
- SECTIONS {
- ROM 0 (NOLOAD) : { ... }
- ...
- }
-
-
-File: ld.info, Node: Output Section LMA, Next: Forced Output Alignment, Prev: Output Section Type, Up: Output Section Attributes
-
-3.6.8.2 Output Section LMA
-..........................
-
-Every section has a virtual address (VMA) and a load address (LMA); see
-*note Basic Script Concepts::. The virtual address is specified by the
-*note Output Section Address:: described earlier. The load address is
-specified by the `AT' or `AT>' keywords. Specifying a load address is
-optional.
-
- The `AT' keyword takes an expression as an argument. This specifies
-the exact load address of the section. The `AT>' keyword takes the
-name of a memory region as an argument. *Note MEMORY::. The load
-address of the section is set to the next free address in the region,
-aligned to the section's alignment requirements.
-
- If neither `AT' nor `AT>' is specified for an allocatable section,
-the linker will use the following heuristic to determine the load
-address:
-
- * If the section has a specific VMA address, then this is used as
- the LMA address as well.
-
- * If the section is not allocatable then its LMA is set to its VMA.
-
- * Otherwise if a memory region can be found that is compatible with
- the current section, and this region contains at least one
- section, then the LMA is set so the difference between the VMA and
- LMA is the same as the difference between the VMA and LMA of the
- last section in the located region.
-
- * If no memory regions have been declared then a default region that
- covers the entire address space is used in the previous step.
-
- * If no suitable region could be found, or there was no previous
- section then the LMA is set equal to the VMA.
-
- This feature is designed to make it easy to build a ROM image. For
-example, the following linker script creates three output sections: one
-called `.text', which starts at `0x1000', one called `.mdata', which is
-loaded at the end of the `.text' section even though its VMA is
-`0x2000', and one called `.bss' to hold uninitialized data at address
-`0x3000'. The symbol `_data' is defined with the value `0x2000', which
-shows that the location counter holds the VMA value, not the LMA value.
-
- SECTIONS
- {
- .text 0x1000 : { *(.text) _etext = . ; }
- .mdata 0x2000 :
- AT ( ADDR (.text) + SIZEOF (.text) )
- { _data = . ; *(.data); _edata = . ; }
- .bss 0x3000 :
- { _bstart = . ; *(.bss) *(COMMON) ; _bend = . ;}
- }
-
- The run-time initialization code for use with a program generated
-with this linker script would include something like the following, to
-copy the initialized data from the ROM image to its runtime address.
-Notice how this code takes advantage of the symbols defined by the
-linker script.
-
- extern char _etext, _data, _edata, _bstart, _bend;
- char *src = &_etext;
- char *dst = &_data;
-
- /* ROM has data at end of text; copy it. */
- while (dst < &_edata)
- *dst++ = *src++;
-
- /* Zero bss. */
- for (dst = &_bstart; dst< &_bend; dst++)
- *dst = 0;
-
-
-File: ld.info, Node: Forced Output Alignment, Next: Forced Input Alignment, Prev: Output Section LMA, Up: Output Section Attributes
-
-3.6.8.3 Forced Output Alignment
-...............................
-
-You can increase an output section's alignment by using ALIGN.
-
-
-File: ld.info, Node: Forced Input Alignment, Next: Output Section Constraint, Prev: Forced Output Alignment, Up: Output Section Attributes
-
-3.6.8.4 Forced Input Alignment
-..............................
-
-You can force input section alignment within an output section by using
-SUBALIGN. The value specified overrides any alignment given by input
-sections, whether larger or smaller.
-
-
-File: ld.info, Node: Output Section Constraint, Next: Output Section Region, Prev: Forced Input Alignment, Up: Output Section Attributes
-
-3.6.8.5 Output Section Constraint
-.................................
-
-You can specify that an output section should only be created if all of
-its input sections are read-only or all of its input sections are
-read-write by using the keyword `ONLY_IF_RO' and `ONLY_IF_RW'
-respectively.
-
-
-File: ld.info, Node: Output Section Region, Next: Output Section Phdr, Prev: Output Section Constraint, Up: Output Section Attributes
-
-3.6.8.6 Output Section Region
-.............................
-
-You can assign a section to a previously defined region of memory by
-using `>REGION'. *Note MEMORY::.
-
- Here is a simple example:
- MEMORY { rom : ORIGIN = 0x1000, LENGTH = 0x1000 }
- SECTIONS { ROM : { *(.text) } >rom }
-
-
-File: ld.info, Node: Output Section Phdr, Next: Output Section Fill, Prev: Output Section Region, Up: Output Section Attributes
-
-3.6.8.7 Output Section Phdr
-...........................
-
-You can assign a section to a previously defined program segment by
-using `:PHDR'. *Note PHDRS::. If a section is assigned to one or more
-segments, then all subsequent allocated sections will be assigned to
-those segments as well, unless they use an explicitly `:PHDR' modifier.
-You can use `:NONE' to tell the linker to not put the section in any
-segment at all.
-
- Here is a simple example:
- PHDRS { text PT_LOAD ; }
- SECTIONS { .text : { *(.text) } :text }
-
-
-File: ld.info, Node: Output Section Fill, Prev: Output Section Phdr, Up: Output Section Attributes
-
-3.6.8.8 Output Section Fill
-...........................
-
-You can set the fill pattern for an entire section by using `=FILLEXP'.
-FILLEXP is an expression (*note Expressions::). Any otherwise
-unspecified regions of memory within the output section (for example,
-gaps left due to the required alignment of input sections) will be
-filled with the value, repeated as necessary. If the fill expression
-is a simple hex number, ie. a string of hex digit starting with `0x'
-and without a trailing `k' or `M', then an arbitrarily long sequence of
-hex digits can be used to specify the fill pattern; Leading zeros
-become part of the pattern too. For all other cases, including extra
-parentheses or a unary `+', the fill pattern is the four least
-significant bytes of the value of the expression. In all cases, the
-number is big-endian.
-
- You can also change the fill value with a `FILL' command in the
-output section commands; (*note Output Section Data::).
-
- Here is a simple example:
- SECTIONS { .text : { *(.text) } =0x90909090 }
-
-
-File: ld.info, Node: Overlay Description, Prev: Output Section Attributes, Up: SECTIONS
-
-3.6.9 Overlay Description
--------------------------
-
-An overlay description provides an easy way to describe sections which
-are to be loaded as part of a single memory image but are to be run at
-the same memory address. At run time, some sort of overlay manager will
-copy the overlaid sections in and out of the runtime memory address as
-required, perhaps by simply manipulating addressing bits. This approach
-can be useful, for example, when a certain region of memory is faster
-than another.
-
- Overlays are described using the `OVERLAY' command. The `OVERLAY'
-command is used within a `SECTIONS' command, like an output section
-description. The full syntax of the `OVERLAY' command is as follows:
- OVERLAY [START] : [NOCROSSREFS] [AT ( LDADDR )]
- {
- SECNAME1
- {
- OUTPUT-SECTION-COMMAND
- OUTPUT-SECTION-COMMAND
- ...
- } [:PHDR...] [=FILL]
- SECNAME2
- {
- OUTPUT-SECTION-COMMAND
- OUTPUT-SECTION-COMMAND
- ...
- } [:PHDR...] [=FILL]
- ...
- } [>REGION] [:PHDR...] [=FILL]
-
- Everything is optional except `OVERLAY' (a keyword), and each
-section must have a name (SECNAME1 and SECNAME2 above). The section
-definitions within the `OVERLAY' construct are identical to those
-within the general `SECTIONS' contruct (*note SECTIONS::), except that
-no addresses and no memory regions may be defined for sections within
-an `OVERLAY'.
-
- The sections are all defined with the same starting address. The
-load addresses of the sections are arranged such that they are
-consecutive in memory starting at the load address used for the
-`OVERLAY' as a whole (as with normal section definitions, the load
-address is optional, and defaults to the start address; the start
-address is also optional, and defaults to the current value of the
-location counter).
-
- If the `NOCROSSREFS' keyword is used, and there any references among
-the sections, the linker will report an error. Since the sections all
-run at the same address, it normally does not make sense for one
-section to refer directly to another. *Note NOCROSSREFS: Miscellaneous
-Commands.
-
- For each section within the `OVERLAY', the linker automatically
-provides two symbols. The symbol `__load_start_SECNAME' is defined as
-the starting load address of the section. The symbol
-`__load_stop_SECNAME' is defined as the final load address of the
-section. Any characters within SECNAME which are not legal within C
-identifiers are removed. C (or assembler) code may use these symbols
-to move the overlaid sections around as necessary.
-
- At the end of the overlay, the value of the location counter is set
-to the start address of the overlay plus the size of the largest
-section.
-
- Here is an example. Remember that this would appear inside a
-`SECTIONS' construct.
- OVERLAY 0x1000 : AT (0x4000)
- {
- .text0 { o1/*.o(.text) }
- .text1 { o2/*.o(.text) }
- }
-This will define both `.text0' and `.text1' to start at address 0x1000.
-`.text0' will be loaded at address 0x4000, and `.text1' will be loaded
-immediately after `.text0'. The following symbols will be defined if
-referenced: `__load_start_text0', `__load_stop_text0',
-`__load_start_text1', `__load_stop_text1'.
-
- C code to copy overlay `.text1' into the overlay area might look
-like the following.
-
- extern char __load_start_text1, __load_stop_text1;
- memcpy ((char *) 0x1000, &__load_start_text1,
- &__load_stop_text1 - &__load_start_text1);
-
- Note that the `OVERLAY' command is just syntactic sugar, since
-everything it does can be done using the more basic commands. The above
-example could have been written identically as follows.
-
- .text0 0x1000 : AT (0x4000) { o1/*.o(.text) }
- PROVIDE (__load_start_text0 = LOADADDR (.text0));
- PROVIDE (__load_stop_text0 = LOADADDR (.text0) + SIZEOF (.text0));
- .text1 0x1000 : AT (0x4000 + SIZEOF (.text0)) { o2/*.o(.text) }
- PROVIDE (__load_start_text1 = LOADADDR (.text1));
- PROVIDE (__load_stop_text1 = LOADADDR (.text1) + SIZEOF (.text1));
- . = 0x1000 + MAX (SIZEOF (.text0), SIZEOF (.text1));
-
-
-File: ld.info, Node: MEMORY, Next: PHDRS, Prev: SECTIONS, Up: Scripts
-
-3.7 MEMORY Command
-==================
-
-The linker's default configuration permits allocation of all available
-memory. You can override this by using the `MEMORY' command.
-
- The `MEMORY' command describes the location and size of blocks of
-memory in the target. You can use it to describe which memory regions
-may be used by the linker, and which memory regions it must avoid. You
-can then assign sections to particular memory regions. The linker will
-set section addresses based on the memory regions, and will warn about
-regions that become too full. The linker will not shuffle sections
-around to fit into the available regions.
-
- A linker script may contain at most one use of the `MEMORY' command.
-However, you can define as many blocks of memory within it as you wish.
-The syntax is:
- MEMORY
- {
- NAME [(ATTR)] : ORIGIN = ORIGIN, LENGTH = LEN
- ...
- }
-
- The NAME is a name used in the linker script to refer to the region.
-The region name has no meaning outside of the linker script. Region
-names are stored in a separate name space, and will not conflict with
-symbol names, file names, or section names. Each memory region must
-have a distinct name within the `MEMORY' command. However you can add
-later alias names to existing memory regions with the *note
-REGION_ALIAS:: command.
-
- The ATTR string is an optional list of attributes that specify
-whether to use a particular memory region for an input section which is
-not explicitly mapped in the linker script. As described in *note
-SECTIONS::, if you do not specify an output section for some input
-section, the linker will create an output section with the same name as
-the input section. If you define region attributes, the linker will use
-them to select the memory region for the output section that it creates.
-
- The ATTR string must consist only of the following characters:
-`R'
- Read-only section
-
-`W'
- Read/write section
-
-`X'
- Executable section
-
-`A'
- Allocatable section
-
-`I'
- Initialized section
-
-`L'
- Same as `I'
-
-`!'
- Invert the sense of any of the attributes that follow
-
- If a unmapped section matches any of the listed attributes other than
-`!', it will be placed in the memory region. The `!' attribute
-reverses this test, so that an unmapped section will be placed in the
-memory region only if it does not match any of the listed attributes.
-
- The ORIGIN is an numerical expression for the start address of the
-memory region. The expression must evaluate to a constant and it
-cannot involve any symbols. The keyword `ORIGIN' may be abbreviated to
-`org' or `o' (but not, for example, `ORG').
-
- The LEN is an expression for the size in bytes of the memory region.
-As with the ORIGIN expression, the expression must be numerical only
-and must evaluate to a constant. The keyword `LENGTH' may be
-abbreviated to `len' or `l'.
-
- In the following example, we specify that there are two memory
-regions available for allocation: one starting at `0' for 256 kilobytes,
-and the other starting at `0x40000000' for four megabytes. The linker
-will place into the `rom' memory region every section which is not
-explicitly mapped into a memory region, and is either read-only or
-executable. The linker will place other sections which are not
-explicitly mapped into a memory region into the `ram' memory region.
-
- MEMORY
- {
- rom (rx) : ORIGIN = 0, LENGTH = 256K
- ram (!rx) : org = 0x40000000, l = 4M
- }
-
- Once you define a memory region, you can direct the linker to place
-specific output sections into that memory region by using the `>REGION'
-output section attribute. For example, if you have a memory region
-named `mem', you would use `>mem' in the output section definition.
-*Note Output Section Region::. If no address was specified for the
-output section, the linker will set the address to the next available
-address within the memory region. If the combined output sections
-directed to a memory region are too large for the region, the linker
-will issue an error message.
-
- It is possible to access the origin and length of a memory in an
-expression via the `ORIGIN(MEMORY)' and `LENGTH(MEMORY)' functions:
-
- _fstack = ORIGIN(ram) + LENGTH(ram) - 4;
-
-
-File: ld.info, Node: PHDRS, Next: VERSION, Prev: MEMORY, Up: Scripts
-
-3.8 PHDRS Command
-=================
-
-The ELF object file format uses "program headers", also knows as
-"segments". The program headers describe how the program should be
-loaded into memory. You can print them out by using the `objdump'
-program with the `-p' option.
-
- When you run an ELF program on a native ELF system, the system loader
-reads the program headers in order to figure out how to load the
-program. This will only work if the program headers are set correctly.
-This manual does not describe the details of how the system loader
-interprets program headers; for more information, see the ELF ABI.
-
- The linker will create reasonable program headers by default.
-However, in some cases, you may need to specify the program headers more
-precisely. You may use the `PHDRS' command for this purpose. When the
-linker sees the `PHDRS' command in the linker script, it will not
-create any program headers other than the ones specified.
-
- The linker only pays attention to the `PHDRS' command when
-generating an ELF output file. In other cases, the linker will simply
-ignore `PHDRS'.
-
- This is the syntax of the `PHDRS' command. The words `PHDRS',
-`FILEHDR', `AT', and `FLAGS' are keywords.
-
- PHDRS
- {
- NAME TYPE [ FILEHDR ] [ PHDRS ] [ AT ( ADDRESS ) ]
- [ FLAGS ( FLAGS ) ] ;
- }
-
- The NAME is used only for reference in the `SECTIONS' command of the
-linker script. It is not put into the output file. Program header
-names are stored in a separate name space, and will not conflict with
-symbol names, file names, or section names. Each program header must
-have a distinct name. The headers are processed in order and it is
-usual for them to map to sections in ascending load address order.
-
- Certain program header types describe segments of memory which the
-system loader will load from the file. In the linker script, you
-specify the contents of these segments by placing allocatable output
-sections in the segments. You use the `:PHDR' output section attribute
-to place a section in a particular segment. *Note Output Section
-Phdr::.
-
- It is normal to put certain sections in more than one segment. This
-merely implies that one segment of memory contains another. You may
-repeat `:PHDR', using it once for each segment which should contain the
-section.
-
- If you place a section in one or more segments using `:PHDR', then
-the linker will place all subsequent allocatable sections which do not
-specify `:PHDR' in the same segments. This is for convenience, since
-generally a whole set of contiguous sections will be placed in a single
-segment. You can use `:NONE' to override the default segment and tell
-the linker to not put the section in any segment at all.
-
- You may use the `FILEHDR' and `PHDRS' keywords after the program
-header type to further describe the contents of the segment. The
-`FILEHDR' keyword means that the segment should include the ELF file
-header. The `PHDRS' keyword means that the segment should include the
-ELF program headers themselves. If applied to a loadable segment
-(`PT_LOAD'), all prior loadable segments must have one of these
-keywords.
-
- The TYPE may be one of the following. The numbers indicate the
-value of the keyword.
-
-`PT_NULL' (0)
- Indicates an unused program header.
-
-`PT_LOAD' (1)
- Indicates that this program header describes a segment to be
- loaded from the file.
-
-`PT_DYNAMIC' (2)
- Indicates a segment where dynamic linking information can be found.
-
-`PT_INTERP' (3)
- Indicates a segment where the name of the program interpreter may
- be found.
-
-`PT_NOTE' (4)
- Indicates a segment holding note information.
-
-`PT_SHLIB' (5)
- A reserved program header type, defined but not specified by the
- ELF ABI.
-
-`PT_PHDR' (6)
- Indicates a segment where the program headers may be found.
-
-EXPRESSION
- An expression giving the numeric type of the program header. This
- may be used for types not defined above.
-
- You can specify that a segment should be loaded at a particular
-address in memory by using an `AT' expression. This is identical to the
-`AT' command used as an output section attribute (*note Output Section
-LMA::). The `AT' command for a program header overrides the output
-section attribute.
-
- The linker will normally set the segment flags based on the sections
-which comprise the segment. You may use the `FLAGS' keyword to
-explicitly specify the segment flags. The value of FLAGS must be an
-integer. It is used to set the `p_flags' field of the program header.
-
- Here is an example of `PHDRS'. This shows a typical set of program
-headers used on a native ELF system.
-
- PHDRS
- {
- headers PT_PHDR PHDRS ;
- interp PT_INTERP ;
- text PT_LOAD FILEHDR PHDRS ;
- data PT_LOAD ;
- dynamic PT_DYNAMIC ;
- }
-
- SECTIONS
- {
- . = SIZEOF_HEADERS;
- .interp : { *(.interp) } :text :interp
- .text : { *(.text) } :text
- .rodata : { *(.rodata) } /* defaults to :text */
- ...
- . = . + 0x1000; /* move to a new page in memory */
- .data : { *(.data) } :data
- .dynamic : { *(.dynamic) } :data :dynamic
- ...
- }
-
-
-File: ld.info, Node: VERSION, Next: Expressions, Prev: PHDRS, Up: Scripts
-
-3.9 VERSION Command
-===================
-
-The linker supports symbol versions when using ELF. Symbol versions are
-only useful when using shared libraries. The dynamic linker can use
-symbol versions to select a specific version of a function when it runs
-a program that may have been linked against an earlier version of the
-shared library.
-
- You can include a version script directly in the main linker script,
-or you can supply the version script as an implicit linker script. You
-can also use the `--version-script' linker option.
-
- The syntax of the `VERSION' command is simply
- VERSION { version-script-commands }
-
- The format of the version script commands is identical to that used
-by Sun's linker in Solaris 2.5. The version script defines a tree of
-version nodes. You specify the node names and interdependencies in the
-version script. You can specify which symbols are bound to which
-version nodes, and you can reduce a specified set of symbols to local
-scope so that they are not globally visible outside of the shared
-library.
-
- The easiest way to demonstrate the version script language is with a
-few examples.
-
- VERS_1.1 {
- global:
- foo1;
- local:
- old*;
- original*;
- new*;
- };
-
- VERS_1.2 {
- foo2;
- } VERS_1.1;
-
- VERS_2.0 {
- bar1; bar2;
- extern "C++" {
- ns::*;
- "f(int, double)";
- };
- } VERS_1.2;
-
- This example version script defines three version nodes. The first
-version node defined is `VERS_1.1'; it has no other dependencies. The
-script binds the symbol `foo1' to `VERS_1.1'. It reduces a number of
-symbols to local scope so that they are not visible outside of the
-shared library; this is done using wildcard patterns, so that any
-symbol whose name begins with `old', `original', or `new' is matched.
-The wildcard patterns available are the same as those used in the shell
-when matching filenames (also known as "globbing"). However, if you
-specify the symbol name inside double quotes, then the name is treated
-as literal, rather than as a glob pattern.
-
- Next, the version script defines node `VERS_1.2'. This node depends
-upon `VERS_1.1'. The script binds the symbol `foo2' to the version
-node `VERS_1.2'.
-
- Finally, the version script defines node `VERS_2.0'. This node
-depends upon `VERS_1.2'. The scripts binds the symbols `bar1' and
-`bar2' are bound to the version node `VERS_2.0'.
-
- When the linker finds a symbol defined in a library which is not
-specifically bound to a version node, it will effectively bind it to an
-unspecified base version of the library. You can bind all otherwise
-unspecified symbols to a given version node by using `global: *;'
-somewhere in the version script. Note that it's slightly crazy to use
-wildcards in a global spec except on the last version node. Global
-wildcards elsewhere run the risk of accidentally adding symbols to the
-set exported for an old version. That's wrong since older versions
-ought to have a fixed set of symbols.
-
- The names of the version nodes have no specific meaning other than
-what they might suggest to the person reading them. The `2.0' version
-could just as well have appeared in between `1.1' and `1.2'. However,
-this would be a confusing way to write a version script.
-
- Node name can be omitted, provided it is the only version node in
-the version script. Such version script doesn't assign any versions to
-symbols, only selects which symbols will be globally visible out and
-which won't.
-
- { global: foo; bar; local: *; };
-
- When you link an application against a shared library that has
-versioned symbols, the application itself knows which version of each
-symbol it requires, and it also knows which version nodes it needs from
-each shared library it is linked against. Thus at runtime, the dynamic
-loader can make a quick check to make sure that the libraries you have
-linked against do in fact supply all of the version nodes that the
-application will need to resolve all of the dynamic symbols. In this
-way it is possible for the dynamic linker to know with certainty that
-all external symbols that it needs will be resolvable without having to
-search for each symbol reference.
-
- The symbol versioning is in effect a much more sophisticated way of
-doing minor version checking that SunOS does. The fundamental problem
-that is being addressed here is that typically references to external
-functions are bound on an as-needed basis, and are not all bound when
-the application starts up. If a shared library is out of date, a
-required interface may be missing; when the application tries to use
-that interface, it may suddenly and unexpectedly fail. With symbol
-versioning, the user will get a warning when they start their program if
-the libraries being used with the application are too old.
-
- There are several GNU extensions to Sun's versioning approach. The
-first of these is the ability to bind a symbol to a version node in the
-source file where the symbol is defined instead of in the versioning
-script. This was done mainly to reduce the burden on the library
-maintainer. You can do this by putting something like:
- __asm__(".symver original_foo,foo@VERS_1.1");
- in the C source file. This renames the function `original_foo' to
-be an alias for `foo' bound to the version node `VERS_1.1'. The
-`local:' directive can be used to prevent the symbol `original_foo'
-from being exported. A `.symver' directive takes precedence over a
-version script.
-
- The second GNU extension is to allow multiple versions of the same
-function to appear in a given shared library. In this way you can make
-an incompatible change to an interface without increasing the major
-version number of the shared library, while still allowing applications
-linked against the old interface to continue to function.
-
- To do this, you must use multiple `.symver' directives in the source
-file. Here is an example:
-
- __asm__(".symver original_foo,foo@");
- __asm__(".symver old_foo,foo@VERS_1.1");
- __asm__(".symver old_foo1,foo@VERS_1.2");
- __asm__(".symver new_foo,foo@@VERS_2.0");
-
- In this example, `foo@' represents the symbol `foo' bound to the
-unspecified base version of the symbol. The source file that contains
-this example would define 4 C functions: `original_foo', `old_foo',
-`old_foo1', and `new_foo'.
-
- When you have multiple definitions of a given symbol, there needs to
-be some way to specify a default version to which external references to
-this symbol will be bound. You can do this with the `foo@@VERS_2.0'
-type of `.symver' directive. You can only declare one version of a
-symbol as the default in this manner; otherwise you would effectively
-have multiple definitions of the same symbol.
-
- If you wish to bind a reference to a specific version of the symbol
-within the shared library, you can use the aliases of convenience
-(i.e., `old_foo'), or you can use the `.symver' directive to
-specifically bind to an external version of the function in question.
-
- You can also specify the language in the version script:
-
- VERSION extern "lang" { version-script-commands }
-
- The supported `lang's are `C', `C++', and `Java'. The linker will
-iterate over the list of symbols at the link time and demangle them
-according to `lang' before matching them to the patterns specified in
-`version-script-commands'. The default `lang' is `C'.
-
- Demangled names may contains spaces and other special characters. As
-described above, you can use a glob pattern to match demangled names,
-or you can use a double-quoted string to match the string exactly. In
-the latter case, be aware that minor differences (such as differing
-whitespace) between the version script and the demangler output will
-cause a mismatch. As the exact string generated by the demangler might
-change in the future, even if the mangled name does not, you should
-check that all of your version directives are behaving as you expect
-when you upgrade.
-
-
-File: ld.info, Node: Expressions, Next: Implicit Linker Scripts, Prev: VERSION, Up: Scripts
-
-3.10 Expressions in Linker Scripts
-==================================
-
-The syntax for expressions in the linker script language is identical to
-that of C expressions. All expressions are evaluated as integers. All
-expressions are evaluated in the same size, which is 32 bits if both the
-host and target are 32 bits, and is otherwise 64 bits.
-
- You can use and set symbol values in expressions.
-
- The linker defines several special purpose builtin functions for use
-in expressions.
-
-* Menu:
-
-* Constants:: Constants
-* Symbolic Constants:: Symbolic constants
-* Symbols:: Symbol Names
-* Orphan Sections:: Orphan Sections
-* Location Counter:: The Location Counter
-* Operators:: Operators
-* Evaluation:: Evaluation
-* Expression Section:: The Section of an Expression
-* Builtin Functions:: Builtin Functions
-
-
-File: ld.info, Node: Constants, Next: Symbolic Constants, Up: Expressions
-
-3.10.1 Constants
-----------------
-
-All constants are integers.
-
- As in C, the linker considers an integer beginning with `0' to be
-octal, and an integer beginning with `0x' or `0X' to be hexadecimal.
-Alternatively the linker accepts suffixes of `h' or `H' for
-hexadeciaml, `o' or `O' for octal, `b' or `B' for binary and `d' or `D'
-for decimal. Any integer value without a prefix or a suffix is
-considered to be decimal.
-
- In addition, you can use the suffixes `K' and `M' to scale a
-constant by `1024' or `1024*1024' respectively. For example, the
-following all refer to the same quantity:
-
- _fourk_1 = 4K;
- _fourk_2 = 4096;
- _fourk_3 = 0x1000;
- _fourk_4 = 10000o;
-
- Note - the `K' and `M' suffixes cannot be used in conjunction with
-the base suffixes mentioned above.
-
-
-File: ld.info, Node: Symbolic Constants, Next: Symbols, Prev: Constants, Up: Expressions
-
-3.10.2 Symbolic Constants
--------------------------
-
-It is possible to refer to target specific constants via the use of the
-`CONSTANT(NAME)' operator, where NAME is one of:
-
-`MAXPAGESIZE'
- The target's maximum page size.
-
-`COMMONPAGESIZE'
- The target's default page size.
-
- So for example:
-
- .text ALIGN (CONSTANT (MAXPAGESIZE)) : { *(.text) }
-
- will create a text section aligned to the largest page boundary
-supported by the target.
-
-
-File: ld.info, Node: Symbols, Next: Orphan Sections, Prev: Symbolic Constants, Up: Expressions
-
-3.10.3 Symbol Names
--------------------
-
-Unless quoted, symbol names start with a letter, underscore, or period
-and may include letters, digits, underscores, periods, and hyphens.
-Unquoted symbol names must not conflict with any keywords. You can
-specify a symbol which contains odd characters or has the same name as a
-keyword by surrounding the symbol name in double quotes:
- "SECTION" = 9;
- "with a space" = "also with a space" + 10;
-
- Since symbols can contain many non-alphabetic characters, it is
-safest to delimit symbols with spaces. For example, `A-B' is one
-symbol, whereas `A - B' is an expression involving subtraction.
-
-
-File: ld.info, Node: Orphan Sections, Next: Location Counter, Prev: Symbols, Up: Expressions
-
-3.10.4 Orphan Sections
-----------------------
-
-Orphan sections are sections present in the input files which are not
-explicitly placed into the output file by the linker script. The
-linker will still copy these sections into the output file, but it has
-to guess as to where they should be placed. The linker uses a simple
-heuristic to do this. It attempts to place orphan sections after
-non-orphan sections of the same attribute, such as code vs data,
-loadable vs non-loadable, etc. If there is not enough room to do this
-then it places at the end of the file.
-
- For ELF targets, the attribute of the section includes section type
-as well as section flag.
-
- If an orphaned section's name is representable as a C identifier then
-the linker will automatically *note PROVIDE:: two symbols:
-__start_SECNAME and __end_SECNAME, where SECNAME is the name of the
-section. These indicate the start address and end address of the
-orphaned section respectively. Note: most section names are not
-representable as C identifiers because they contain a `.' character.
-
-
-File: ld.info, Node: Location Counter, Next: Operators, Prev: Orphan Sections, Up: Expressions
-
-3.10.5 The Location Counter
----------------------------
-
-The special linker variable "dot" `.' always contains the current
-output location counter. Since the `.' always refers to a location in
-an output section, it may only appear in an expression within a
-`SECTIONS' command. The `.' symbol may appear anywhere that an
-ordinary symbol is allowed in an expression.
-
- Assigning a value to `.' will cause the location counter to be
-moved. This may be used to create holes in the output section. The
-location counter may not be moved backwards inside an output section,
-and may not be moved backwards outside of an output section if so doing
-creates areas with overlapping LMAs.
-
- SECTIONS
- {
- output :
- {
- file1(.text)
- . = . + 1000;
- file2(.text)
- . += 1000;
- file3(.text)
- } = 0x12345678;
- }
- In the previous example, the `.text' section from `file1' is located
-at the beginning of the output section `output'. It is followed by a
-1000 byte gap. Then the `.text' section from `file2' appears, also
-with a 1000 byte gap following before the `.text' section from `file3'.
-The notation `= 0x12345678' specifies what data to write in the gaps
-(*note Output Section Fill::).
-
- Note: `.' actually refers to the byte offset from the start of the
-current containing object. Normally this is the `SECTIONS' statement,
-whose start address is 0, hence `.' can be used as an absolute address.
-If `.' is used inside a section description however, it refers to the
-byte offset from the start of that section, not an absolute address.
-Thus in a script like this:
-
- SECTIONS
- {
- . = 0x100
- .text: {
- *(.text)
- . = 0x200
- }
- . = 0x500
- .data: {
- *(.data)
- . += 0x600
- }
- }
-
- The `.text' section will be assigned a starting address of 0x100 and
-a size of exactly 0x200 bytes, even if there is not enough data in the
-`.text' input sections to fill this area. (If there is too much data,
-an error will be produced because this would be an attempt to move `.'
-backwards). The `.data' section will start at 0x500 and it will have
-an extra 0x600 bytes worth of space after the end of the values from
-the `.data' input sections and before the end of the `.data' output
-section itself.
-
- Setting symbols to the value of the location counter outside of an
-output section statement can result in unexpected values if the linker
-needs to place orphan sections. For example, given the following:
-
- SECTIONS
- {
- start_of_text = . ;
- .text: { *(.text) }
- end_of_text = . ;
-
- start_of_data = . ;
- .data: { *(.data) }
- end_of_data = . ;
- }
-
- If the linker needs to place some input section, e.g. `.rodata', not
-mentioned in the script, it might choose to place that section between
-`.text' and `.data'. You might think the linker should place `.rodata'
-on the blank line in the above script, but blank lines are of no
-particular significance to the linker. As well, the linker doesn't
-associate the above symbol names with their sections. Instead, it
-assumes that all assignments or other statements belong to the previous
-output section, except for the special case of an assignment to `.'.
-I.e., the linker will place the orphan `.rodata' section as if the
-script was written as follows:
-
- SECTIONS
- {
- start_of_text = . ;
- .text: { *(.text) }
- end_of_text = . ;
-
- start_of_data = . ;
- .rodata: { *(.rodata) }
- .data: { *(.data) }
- end_of_data = . ;
- }
-
- This may or may not be the script author's intention for the value of
-`start_of_data'. One way to influence the orphan section placement is
-to assign the location counter to itself, as the linker assumes that an
-assignment to `.' is setting the start address of a following output
-section and thus should be grouped with that section. So you could
-write:
-
- SECTIONS
- {
- start_of_text = . ;
- .text: { *(.text) }
- end_of_text = . ;
-
- . = . ;
- start_of_data = . ;
- .data: { *(.data) }
- end_of_data = . ;
- }
-
- Now, the orphan `.rodata' section will be placed between
-`end_of_text' and `start_of_data'.
-
-
-File: ld.info, Node: Operators, Next: Evaluation, Prev: Location Counter, Up: Expressions
-
-3.10.6 Operators
-----------------
-
-The linker recognizes the standard C set of arithmetic operators, with
-the standard bindings and precedence levels:
- precedence associativity Operators Notes
- (highest)
- 1 left ! - ~ (1)
- 2 left * / %
- 3 left + -
- 4 left >> <<
- 5 left == != > < <= >=
- 6 left &
- 7 left |
- 8 left &&
- 9 left ||
- 10 right ? :
- 11 right &= += -= *= /= (2)
- (lowest)
- Notes: (1) Prefix operators (2) *Note Assignments::.
-
-
-File: ld.info, Node: Evaluation, Next: Expression Section, Prev: Operators, Up: Expressions
-
-3.10.7 Evaluation
------------------
-
-The linker evaluates expressions lazily. It only computes the value of
-an expression when absolutely necessary.
-
- The linker needs some information, such as the value of the start
-address of the first section, and the origins and lengths of memory
-regions, in order to do any linking at all. These values are computed
-as soon as possible when the linker reads in the linker script.
-
- However, other values (such as symbol values) are not known or needed
-until after storage allocation. Such values are evaluated later, when
-other information (such as the sizes of output sections) is available
-for use in the symbol assignment expression.
-
- The sizes of sections cannot be known until after allocation, so
-assignments dependent upon these are not performed until after
-allocation.
-
- Some expressions, such as those depending upon the location counter
-`.', must be evaluated during section allocation.
-
- If the result of an expression is required, but the value is not
-available, then an error results. For example, a script like the
-following
- SECTIONS
- {
- .text 9+this_isnt_constant :
- { *(.text) }
- }
-will cause the error message `non constant expression for initial
-address'.
-
-
-File: ld.info, Node: Expression Section, Next: Builtin Functions, Prev: Evaluation, Up: Expressions
-
-3.10.8 The Section of an Expression
------------------------------------
-
-Addresses and symbols may be section relative, or absolute. A section
-relative symbol is relocatable. If you request relocatable output
-using the `-r' option, a further link operation may change the value of
-a section relative symbol. On the other hand, an absolute symbol will
-retain the same value throughout any further link operations.
-
- Some terms in linker expressions are addresses. This is true of
-section relative symbols and for builtin functions that return an
-address, such as `ADDR', `LOADADDR', `ORIGIN' and `SEGMENT_START'.
-Other terms are simply numbers, or are builtin functions that return a
-non-address value, such as `LENGTH'.
-
- When the linker evaluates an expression, the result depends on where
-the expression is located in a linker script. Expressions appearing
-outside an output section definitions are evaluated with all terms
-first being converted to absolute addresses before applying operators,
-and evaluate to an absolute address result. Expressions appearing
-inside an output section definition are evaluated with more complex
-rules, but the aim is to treat terms as relative addresses and produce
-a relative address result. In particular, an assignment of a number to
-a symbol results in a symbol relative to the output section with an
-offset given by the number. So, in the following simple example,
-
- SECTIONS
- {
- . = 0x100;
- __executable_start = 0x100;
- .data :
- {
- . = 0x10;
- __data_start = 0x10;
- *(.data)
- }
- ...
- }
-
- both `.' and `__executable_start' are set to the absolute address
-0x100 in the first two assignments, then both `.' and `__data_start'
-are set to 0x10 relative to the `.data' section in the second two
-assignments.
-
- For expressions appearing inside an output section definition
-involving numbers, relative addresses and absolute addresses, ld
-follows these rules to evaluate terms:
-
- * Unary operations on a relative address, and binary operations on
- two relative addresses in the same section or between one relative
- address and a number, apply the operator to the offset part of the
- address(es).
-
- * Unary operations on an absolute address, and binary operations on
- one or more absolute addresses or on two relative addresses not in
- the same section, first convert any non-absolute term to an
- absolute address before applying the operator.
-
- The result section of each sub-expression is as follows:
-
- * An operation involving only numbers results in a number.
-
- * The result of comparisons, `&&' and `||' is also a number.
-
- * The result of other operations on relative addresses (after above
- conversions) is a relative address in the same section as the
- operand(s).
-
- * The result of other operations on absolute addresses (after above
- conversions) is an absolute address.
-
- You can use the builtin function `ABSOLUTE' to force an expression
-to be absolute when it would otherwise be relative. For example, to
-create an absolute symbol set to the address of the end of the output
-section `.data':
- SECTIONS
- {
- .data : { *(.data) _edata = ABSOLUTE(.); }
- }
- If `ABSOLUTE' were not used, `_edata' would be relative to the
-`.data' section.
-
- Using `LOADADDR' also forces an expression absolute, since this
-particular builtin function returns an absolute address.
-
-
-File: ld.info, Node: Builtin Functions, Prev: Expression Section, Up: Expressions
-
-3.10.9 Builtin Functions
-------------------------
-
-The linker script language includes a number of builtin functions for
-use in linker script expressions.
-
-`ABSOLUTE(EXP)'
- Return the absolute (non-relocatable, as opposed to non-negative)
- value of the expression EXP. Primarily useful to assign an
- absolute value to a symbol within a section definition, where
- symbol values are normally section relative. *Note Expression
- Section::.
-
-`ADDR(SECTION)'
- Return the address (VMA) of the named SECTION. Your script must
- previously have defined the location of that section. In the
- following example, `start_of_output_1', `symbol_1' and `symbol_2'
- are assigned equivalent values, except that `symbol_1' will be
- relative to the `.output1' section while the other two will be
- absolute:
- SECTIONS { ...
- .output1 :
- {
- start_of_output_1 = ABSOLUTE(.);
- ...
- }
- .output :
- {
- symbol_1 = ADDR(.output1);
- symbol_2 = start_of_output_1;
- }
- ... }
-
-`ALIGN(ALIGN)'
-`ALIGN(EXP,ALIGN)'
- Return the location counter (`.') or arbitrary expression aligned
- to the next ALIGN boundary. The single operand `ALIGN' doesn't
- change the value of the location counter--it just does arithmetic
- on it. The two operand `ALIGN' allows an arbitrary expression to
- be aligned upwards (`ALIGN(ALIGN)' is equivalent to `ALIGN(.,
- ALIGN)').
-
- Here is an example which aligns the output `.data' section to the
- next `0x2000' byte boundary after the preceding section and sets a
- variable within the section to the next `0x8000' boundary after the
- input sections:
- SECTIONS { ...
- .data ALIGN(0x2000): {
- *(.data)
- variable = ALIGN(0x8000);
- }
- ... }
- The first use of `ALIGN' in this example specifies the location of
- a section because it is used as the optional ADDRESS attribute of
- a section definition (*note Output Section Address::). The second
- use of `ALIGN' is used to defines the value of a symbol.
-
- The builtin function `NEXT' is closely related to `ALIGN'.
-
-`ALIGNOF(SECTION)'
- Return the alignment in bytes of the named SECTION, if that
- section has been allocated. If the section has not been allocated
- when this is evaluated, the linker will report an error. In the
- following example, the alignment of the `.output' section is
- stored as the first value in that section.
- SECTIONS{ ...
- .output {
- LONG (ALIGNOF (.output))
- ...
- }
- ... }
-
-`BLOCK(EXP)'
- This is a synonym for `ALIGN', for compatibility with older linker
- scripts. It is most often seen when setting the address of an
- output section.
-
-`DATA_SEGMENT_ALIGN(MAXPAGESIZE, COMMONPAGESIZE)'
- This is equivalent to either
- (ALIGN(MAXPAGESIZE) + (. & (MAXPAGESIZE - 1)))
- or
- (ALIGN(MAXPAGESIZE) + (. & (MAXPAGESIZE - COMMONPAGESIZE)))
- depending on whether the latter uses fewer COMMONPAGESIZE sized
- pages for the data segment (area between the result of this
- expression and `DATA_SEGMENT_END') than the former or not. If the
- latter form is used, it means COMMONPAGESIZE bytes of runtime
- memory will be saved at the expense of up to COMMONPAGESIZE wasted
- bytes in the on-disk file.
-
- This expression can only be used directly in `SECTIONS' commands,
- not in any output section descriptions and only once in the linker
- script. COMMONPAGESIZE should be less or equal to MAXPAGESIZE and
- should be the system page size the object wants to be optimized
- for (while still working on system page sizes up to MAXPAGESIZE).
-
- Example:
- . = DATA_SEGMENT_ALIGN(0x10000, 0x2000);
-
-`DATA_SEGMENT_END(EXP)'
- This defines the end of data segment for `DATA_SEGMENT_ALIGN'
- evaluation purposes.
-
- . = DATA_SEGMENT_END(.);
-
-`DATA_SEGMENT_RELRO_END(OFFSET, EXP)'
- This defines the end of the `PT_GNU_RELRO' segment when `-z relro'
- option is used. Second argument is returned. When `-z relro'
- option is not present, `DATA_SEGMENT_RELRO_END' does nothing,
- otherwise `DATA_SEGMENT_ALIGN' is padded so that EXP + OFFSET is
- aligned to the most commonly used page boundary for particular
- target. If present in the linker script, it must always come in
- between `DATA_SEGMENT_ALIGN' and `DATA_SEGMENT_END'.
-
- . = DATA_SEGMENT_RELRO_END(24, .);
-
-`DEFINED(SYMBOL)'
- Return 1 if SYMBOL is in the linker global symbol table and is
- defined before the statement using DEFINED in the script, otherwise
- return 0. You can use this function to provide default values for
- symbols. For example, the following script fragment shows how to
- set a global symbol `begin' to the first location in the `.text'
- section--but if a symbol called `begin' already existed, its value
- is preserved:
-
- SECTIONS { ...
- .text : {
- begin = DEFINED(begin) ? begin : . ;
- ...
- }
- ...
- }
-
-`LENGTH(MEMORY)'
- Return the length of the memory region named MEMORY.
-
-`LOADADDR(SECTION)'
- Return the absolute LMA of the named SECTION. (*note Output
- Section LMA::).
-
-`MAX(EXP1, EXP2)'
- Returns the maximum of EXP1 and EXP2.
-
-`MIN(EXP1, EXP2)'
- Returns the minimum of EXP1 and EXP2.
-
-`NEXT(EXP)'
- Return the next unallocated address that is a multiple of EXP.
- This function is closely related to `ALIGN(EXP)'; unless you use
- the `MEMORY' command to define discontinuous memory for the output
- file, the two functions are equivalent.
-
-`ORIGIN(MEMORY)'
- Return the origin of the memory region named MEMORY.
-
-`SEGMENT_START(SEGMENT, DEFAULT)'
- Return the base address of the named SEGMENT. If an explicit
- value has been given for this segment (with a command-line `-T'
- option) that value will be returned; otherwise the value will be
- DEFAULT. At present, the `-T' command-line option can only be
- used to set the base address for the "text", "data", and "bss"
- sections, but you can use `SEGMENT_START' with any segment name.
-
-`SIZEOF(SECTION)'
- Return the size in bytes of the named SECTION, if that section has
- been allocated. If the section has not been allocated when this is
- evaluated, the linker will report an error. In the following
- example, `symbol_1' and `symbol_2' are assigned identical values:
- SECTIONS{ ...
- .output {
- .start = . ;
- ...
- .end = . ;
- }
- symbol_1 = .end - .start ;
- symbol_2 = SIZEOF(.output);
- ... }
-
-`SIZEOF_HEADERS'
-`sizeof_headers'
- Return the size in bytes of the output file's headers. This is
- information which appears at the start of the output file. You
- can use this number when setting the start address of the first
- section, if you choose, to facilitate paging.
-
- When producing an ELF output file, if the linker script uses the
- `SIZEOF_HEADERS' builtin function, the linker must compute the
- number of program headers before it has determined all the section
- addresses and sizes. If the linker later discovers that it needs
- additional program headers, it will report an error `not enough
- room for program headers'. To avoid this error, you must avoid
- using the `SIZEOF_HEADERS' function, or you must rework your linker
- script to avoid forcing the linker to use additional program
- headers, or you must define the program headers yourself using the
- `PHDRS' command (*note PHDRS::).
-
-
-File: ld.info, Node: Implicit Linker Scripts, Prev: Expressions, Up: Scripts
-
-3.11 Implicit Linker Scripts
-============================
-
-If you specify a linker input file which the linker can not recognize as
-an object file or an archive file, it will try to read the file as a
-linker script. If the file can not be parsed as a linker script, the
-linker will report an error.
-
- An implicit linker script will not replace the default linker script.
-
- Typically an implicit linker script would contain only symbol
-assignments, or the `INPUT', `GROUP', or `VERSION' commands.
-
- Any input files read because of an implicit linker script will be
-read at the position in the command line where the implicit linker
-script was read. This can affect archive searching.
-
-
-File: ld.info, Node: Machine Dependent, Next: BFD, Prev: Scripts, Up: Top
-
-4 Machine Dependent Features
-****************************
-
-`ld' has additional features on some platforms; the following sections
-describe them. Machines where `ld' has no additional functionality are
-not listed.
-
-* Menu:
-
-
-* H8/300:: `ld' and the H8/300
-
-* i960:: `ld' and the Intel 960 family
-
-* ARM:: `ld' and the ARM family
-
-* HPPA ELF32:: `ld' and HPPA 32-bit ELF
-
-* M68K:: `ld' and the Motorola 68K family
-
-* MMIX:: `ld' and MMIX
-
-* MSP430:: `ld' and MSP430
-
-* M68HC11/68HC12:: `ld' and the Motorola 68HC11 and 68HC12 families
-
-* PowerPC ELF32:: `ld' and PowerPC 32-bit ELF Support
-
-* PowerPC64 ELF64:: `ld' and PowerPC64 64-bit ELF Support
-
-* SPU ELF:: `ld' and SPU ELF Support
-
-* TI COFF:: `ld' and TI COFF
-
-* WIN32:: `ld' and WIN32 (cygwin/mingw)
-
-* Xtensa:: `ld' and Xtensa Processors
-
-
-File: ld.info, Node: H8/300, Next: i960, Up: Machine Dependent
-
-4.1 `ld' and the H8/300
-=======================
-
-For the H8/300, `ld' can perform these global optimizations when you
-specify the `--relax' command-line option.
-
-_relaxing address modes_
- `ld' finds all `jsr' and `jmp' instructions whose targets are
- within eight bits, and turns them into eight-bit program-counter
- relative `bsr' and `bra' instructions, respectively.
-
-_synthesizing instructions_
- `ld' finds all `mov.b' instructions which use the sixteen-bit
- absolute address form, but refer to the top page of memory, and
- changes them to use the eight-bit address form. (That is: the
- linker turns `mov.b `@'AA:16' into `mov.b `@'AA:8' whenever the
- address AA is in the top page of memory).
-
-_bit manipulation instructions_
- `ld' finds all bit manipulation instructions like `band, bclr,
- biand, bild, bior, bist, bixor, bld, bnot, bor, bset, bst, btst,
- bxor' which use 32 bit and 16 bit absolute address form, but refer
- to the top page of memory, and changes them to use the 8 bit
- address form. (That is: the linker turns `bset #xx:3,`@'AA:32'
- into `bset #xx:3,`@'AA:8' whenever the address AA is in the top
- page of memory).
-
-_system control instructions_
- `ld' finds all `ldc.w, stc.w' instructions which use the 32 bit
- absolute address form, but refer to the top page of memory, and
- changes them to use 16 bit address form. (That is: the linker
- turns `ldc.w `@'AA:32,ccr' into `ldc.w `@'AA:16,ccr' whenever the
- address AA is in the top page of memory).
-
-
-File: ld.info, Node: i960, Next: ARM, Prev: H8/300, Up: Machine Dependent
-
-4.2 `ld' and the Intel 960 Family
-=================================
-
-You can use the `-AARCHITECTURE' command line option to specify one of
-the two-letter names identifying members of the 960 family; the option
-specifies the desired output target, and warns of any incompatible
-instructions in the input files. It also modifies the linker's search
-strategy for archive libraries, to support the use of libraries
-specific to each particular architecture, by including in the search
-loop names suffixed with the string identifying the architecture.
-
- For example, if your `ld' command line included `-ACA' as well as
-`-ltry', the linker would look (in its built-in search paths, and in
-any paths you specify with `-L') for a library with the names
-
- try
- libtry.a
- tryca
- libtryca.a
-
-The first two possibilities would be considered in any event; the last
-two are due to the use of `-ACA'.
-
- You can meaningfully use `-A' more than once on a command line, since
-the 960 architecture family allows combination of target architectures;
-each use will add another pair of name variants to search for when `-l'
-specifies a library.
-
- `ld' supports the `--relax' option for the i960 family. If you
-specify `--relax', `ld' finds all `balx' and `calx' instructions whose
-targets are within 24 bits, and turns them into 24-bit program-counter
-relative `bal' and `cal' instructions, respectively. `ld' also turns
-`cal' instructions into `bal' instructions when it determines that the
-target subroutine is a leaf routine (that is, the target subroutine does
-not itself call any subroutines).
-
- The `--fix-cortex-a8' switch enables a link-time workaround for an
-erratum in certain Cortex-A8 processors. The workaround is enabled by
-default if you are targeting the ARM v7-A architecture profile. It can
-be enabled otherwise by specifying `--fix-cortex-a8', or disabled
-unconditionally by specifying `--no-fix-cortex-a8'.
-
- The erratum only affects Thumb-2 code. Please contact ARM for
-further details.
-
- The `--no-merge-exidx-entries' switch disables the merging of
-adjacent exidx entries in debuginfo.
-
-
-File: ld.info, Node: M68HC11/68HC12, Next: PowerPC ELF32, Prev: MSP430, Up: Machine Dependent
-
-4.3 `ld' and the Motorola 68HC11 and 68HC12 families
-====================================================
-
-4.3.1 Linker Relaxation
------------------------
-
-For the Motorola 68HC11, `ld' can perform these global optimizations
-when you specify the `--relax' command-line option.
-
-_relaxing address modes_
- `ld' finds all `jsr' and `jmp' instructions whose targets are
- within eight bits, and turns them into eight-bit program-counter
- relative `bsr' and `bra' instructions, respectively.
-
- `ld' also looks at all 16-bit extended addressing modes and
- transforms them in a direct addressing mode when the address is in
- page 0 (between 0 and 0x0ff).
-
-_relaxing gcc instruction group_
- When `gcc' is called with `-mrelax', it can emit group of
- instructions that the linker can optimize to use a 68HC11 direct
- addressing mode. These instructions consists of `bclr' or `bset'
- instructions.
-
-
-4.3.2 Trampoline Generation
----------------------------
-
-For 68HC11 and 68HC12, `ld' can generate trampoline code to call a far
-function using a normal `jsr' instruction. The linker will also change
-the relocation to some far function to use the trampoline address
-instead of the function address. This is typically the case when a
-pointer to a function is taken. The pointer will in fact point to the
-function trampoline.
-
-
-File: ld.info, Node: ARM, Next: HPPA ELF32, Prev: i960, Up: Machine Dependent
-
-4.4 `ld' and the ARM family
-===========================
-
-For the ARM, `ld' will generate code stubs to allow functions calls
-between ARM and Thumb code. These stubs only work with code that has
-been compiled and assembled with the `-mthumb-interwork' command line
-option. If it is necessary to link with old ARM object files or
-libraries, which have not been compiled with the -mthumb-interwork
-option then the `--support-old-code' command line switch should be
-given to the linker. This will make it generate larger stub functions
-which will work with non-interworking aware ARM code. Note, however,
-the linker does not support generating stubs for function calls to
-non-interworking aware Thumb code.
-
- The `--thumb-entry' switch is a duplicate of the generic `--entry'
-switch, in that it sets the program's starting address. But it also
-sets the bottom bit of the address, so that it can be branched to using
-a BX instruction, and the program will start executing in Thumb mode
-straight away.
-
- The `--use-nul-prefixed-import-tables' switch is specifying, that
-the import tables idata4 and idata5 have to be generated with a zero
-elememt prefix for import libraries. This is the old style to generate
-import tables. By default this option is turned off.
-
- The `--be8' switch instructs `ld' to generate BE8 format
-executables. This option is only valid when linking big-endian objects.
-The resulting image will contain big-endian data and little-endian code.
-
- The `R_ARM_TARGET1' relocation is typically used for entries in the
-`.init_array' section. It is interpreted as either `R_ARM_REL32' or
-`R_ARM_ABS32', depending on the target. The `--target1-rel' and
-`--target1-abs' switches override the default.
-
- The `--target2=type' switch overrides the default definition of the
-`R_ARM_TARGET2' relocation. Valid values for `type', their meanings,
-and target defaults are as follows:
-`rel'
- `R_ARM_REL32' (arm*-*-elf, arm*-*-eabi)
-
-`abs'
- `R_ARM_ABS32' (arm*-*-symbianelf)
-
-`got-rel'
- `R_ARM_GOT_PREL' (arm*-*-linux, arm*-*-*bsd)
-
- The `R_ARM_V4BX' relocation (defined by the ARM AAELF specification)
-enables objects compiled for the ARMv4 architecture to be
-interworking-safe when linked with other objects compiled for ARMv4t,
-but also allows pure ARMv4 binaries to be built from the same ARMv4
-objects.
-
- In the latter case, the switch `--fix-v4bx' must be passed to the
-linker, which causes v4t `BX rM' instructions to be rewritten as `MOV
-PC,rM', since v4 processors do not have a `BX' instruction.
-
- In the former case, the switch should not be used, and `R_ARM_V4BX'
-relocations are ignored.
-
- Replace `BX rM' instructions identified by `R_ARM_V4BX' relocations
-with a branch to the following veneer:
-
- TST rM, #1
- MOVEQ PC, rM
- BX Rn
-
- This allows generation of libraries/applications that work on ARMv4
-cores and are still interworking safe. Note that the above veneer
-clobbers the condition flags, so may cause incorrect progrm behavior in
-rare cases.
-
- The `--use-blx' switch enables the linker to use ARM/Thumb BLX
-instructions (available on ARMv5t and above) in various situations.
-Currently it is used to perform calls via the PLT from Thumb code using
-BLX rather than using BX and a mode-switching stub before each PLT
-entry. This should lead to such calls executing slightly faster.
-
- This option is enabled implicitly for SymbianOS, so there is no need
-to specify it if you are using that target.
-
- The `--vfp11-denorm-fix' switch enables a link-time workaround for a
-bug in certain VFP11 coprocessor hardware, which sometimes allows
-instructions with denorm operands (which must be handled by support
-code) to have those operands overwritten by subsequent instructions
-before the support code can read the intended values.
-
- The bug may be avoided in scalar mode if you allow at least one
-intervening instruction between a VFP11 instruction which uses a
-register and another instruction which writes to the same register, or
-at least two intervening instructions if vector mode is in use. The bug
-only affects full-compliance floating-point mode: you do not need this
-workaround if you are using "runfast" mode. Please contact ARM for
-further details.
-
- If you know you are using buggy VFP11 hardware, you can enable this
-workaround by specifying the linker option `--vfp-denorm-fix=scalar' if
-you are using the VFP11 scalar mode only, or `--vfp-denorm-fix=vector'
-if you are using vector mode (the latter also works for scalar code).
-The default is `--vfp-denorm-fix=none'.
-
- If the workaround is enabled, instructions are scanned for
-potentially-troublesome sequences, and a veneer is created for each
-such sequence which may trigger the erratum. The veneer consists of the
-first instruction of the sequence and a branch back to the subsequent
-instruction. The original instruction is then replaced with a branch to
-the veneer. The extra cycles required to call and return from the veneer
-are sufficient to avoid the erratum in both the scalar and vector cases.
-
- The `--no-enum-size-warning' switch prevents the linker from warning
-when linking object files that specify incompatible EABI enumeration
-size attributes. For example, with this switch enabled, linking of an
-object file using 32-bit enumeration values with another using
-enumeration values fitted into the smallest possible space will not be
-diagnosed.
-
- The `--no-wchar-size-warning' switch prevents the linker from
-warning when linking object files that specify incompatible EABI
-`wchar_t' size attributes. For example, with this switch enabled,
-linking of an object file using 32-bit `wchar_t' values with another
-using 16-bit `wchar_t' values will not be diagnosed.
-
- The `--pic-veneer' switch makes the linker use PIC sequences for
-ARM/Thumb interworking veneers, even if the rest of the binary is not
-PIC. This avoids problems on uClinux targets where `--emit-relocs' is
-used to generate relocatable binaries.
-
- The linker will automatically generate and insert small sequences of
-code into a linked ARM ELF executable whenever an attempt is made to
-perform a function call to a symbol that is too far away. The
-placement of these sequences of instructions - called stubs - is
-controlled by the command line option `--stub-group-size=N'. The
-placement is important because a poor choice can create a need for
-duplicate stubs, increasing the code sizw. The linker will try to
-group stubs together in order to reduce interruptions to the flow of
-code, but it needs guidance as to how big these groups should be and
-where they should be placed.
-
- The value of `N', the parameter to the `--stub-group-size=' option
-controls where the stub groups are placed. If it is negative then all
-stubs are placed after the first branch that needs them. If it is
-positive then the stubs can be placed either before or after the
-branches that need them. If the value of `N' is 1 (either +1 or -1)
-then the linker will choose exactly where to place groups of stubs,
-using its built in heuristics. A value of `N' greater than 1 (or
-smaller than -1) tells the linker that a single group of stubs can
-service at most `N' bytes from the input sections.
-
- The default, if `--stub-group-size=' is not specified, is `N = +1'.
-
- Farcalls stubs insertion is fully supported for the ARM-EABI target
-only, because it relies on object files properties not present
-otherwise.
-
-
-File: ld.info, Node: HPPA ELF32, Next: M68K, Prev: ARM, Up: Machine Dependent
-
-4.5 `ld' and HPPA 32-bit ELF Support
-====================================
-
-When generating a shared library, `ld' will by default generate import
-stubs suitable for use with a single sub-space application. The
-`--multi-subspace' switch causes `ld' to generate export stubs, and
-different (larger) import stubs suitable for use with multiple
-sub-spaces.
-
- Long branch stubs and import/export stubs are placed by `ld' in stub
-sections located between groups of input sections. `--stub-group-size'
-specifies the maximum size of a group of input sections handled by one
-stub section. Since branch offsets are signed, a stub section may
-serve two groups of input sections, one group before the stub section,
-and one group after it. However, when using conditional branches that
-require stubs, it may be better (for branch prediction) that stub
-sections only serve one group of input sections. A negative value for
-`N' chooses this scheme, ensuring that branches to stubs always use a
-negative offset. Two special values of `N' are recognized, `1' and
-`-1'. These both instruct `ld' to automatically size input section
-groups for the branch types detected, with the same behaviour regarding
-stub placement as other positive or negative values of `N' respectively.
-
- Note that `--stub-group-size' does not split input sections. A
-single input section larger than the group size specified will of course
-create a larger group (of one section). If input sections are too
-large, it may not be possible for a branch to reach its stub.
-
-
-File: ld.info, Node: M68K, Next: MMIX, Prev: HPPA ELF32, Up: Machine Dependent
-
-4.6 `ld' and the Motorola 68K family
-====================================
-
-The `--got=TYPE' option lets you choose the GOT generation scheme. The
-choices are `single', `negative', `multigot' and `target'. When
-`target' is selected the linker chooses the default GOT generation
-scheme for the current target. `single' tells the linker to generate a
-single GOT with entries only at non-negative offsets. `negative'
-instructs the linker to generate a single GOT with entries at both
-negative and positive offsets. Not all environments support such GOTs.
-`multigot' allows the linker to generate several GOTs in the output
-file. All GOT references from a single input object file access the
-same GOT, but references from different input object files might access
-different GOTs. Not all environments support such GOTs.
-
-
-File: ld.info, Node: MMIX, Next: MSP430, Prev: M68K, Up: Machine Dependent
-
-4.7 `ld' and MMIX
-=================
-
-For MMIX, there is a choice of generating `ELF' object files or `mmo'
-object files when linking. The simulator `mmix' understands the `mmo'
-format. The binutils `objcopy' utility can translate between the two
-formats.
-
- There is one special section, the `.MMIX.reg_contents' section.
-Contents in this section is assumed to correspond to that of global
-registers, and symbols referring to it are translated to special
-symbols, equal to registers. In a final link, the start address of the
-`.MMIX.reg_contents' section corresponds to the first allocated global
-register multiplied by 8. Register `$255' is not included in this
-section; it is always set to the program entry, which is at the symbol
-`Main' for `mmo' files.
-
- Global symbols with the prefix `__.MMIX.start.', for example
-`__.MMIX.start..text' and `__.MMIX.start..data' are special. The
-default linker script uses these to set the default start address of a
-section.
-
- Initial and trailing multiples of zero-valued 32-bit words in a
-section, are left out from an mmo file.
-
-
-File: ld.info, Node: MSP430, Next: M68HC11/68HC12, Prev: MMIX, Up: Machine Dependent
-
-4.8 `ld' and MSP430
-===================
-
-For the MSP430 it is possible to select the MPU architecture. The flag
-`-m [mpu type]' will select an appropriate linker script for selected
-MPU type. (To get a list of known MPUs just pass `-m help' option to
-the linker).
-
- The linker will recognize some extra sections which are MSP430
-specific:
-
-``.vectors''
- Defines a portion of ROM where interrupt vectors located.
-
-``.bootloader''
- Defines the bootloader portion of the ROM (if applicable). Any
- code in this section will be uploaded to the MPU.
-
-``.infomem''
- Defines an information memory section (if applicable). Any code in
- this section will be uploaded to the MPU.
-
-``.infomemnobits''
- This is the same as the `.infomem' section except that any code in
- this section will not be uploaded to the MPU.
-
-``.noinit''
- Denotes a portion of RAM located above `.bss' section.
-
- The last two sections are used by gcc.
-
-
-File: ld.info, Node: PowerPC ELF32, Next: PowerPC64 ELF64, Prev: M68HC11/68HC12, Up: Machine Dependent
-
-4.9 `ld' and PowerPC 32-bit ELF Support
-=======================================
-
-Branches on PowerPC processors are limited to a signed 26-bit
-displacement, which may result in `ld' giving `relocation truncated to
-fit' errors with very large programs. `--relax' enables the generation
-of trampolines that can access the entire 32-bit address space. These
-trampolines are inserted at section boundaries, so may not themselves
-be reachable if an input section exceeds 33M in size. You may combine
-`-r' and `--relax' to add trampolines in a partial link. In that case
-both branches to undefined symbols and inter-section branches are also
-considered potentially out of range, and trampolines inserted.
-
-`--bss-plt'
- Current PowerPC GCC accepts a `-msecure-plt' option that generates
- code capable of using a newer PLT and GOT layout that has the
- security advantage of no executable section ever needing to be
- writable and no writable section ever being executable. PowerPC
- `ld' will generate this layout, including stubs to access the PLT,
- if all input files (including startup and static libraries) were
- compiled with `-msecure-plt'. `--bss-plt' forces the old BSS PLT
- (and GOT layout) which can give slightly better performance.
-
-`--secure-plt'
- `ld' will use the new PLT and GOT layout if it is linking new
- `-fpic' or `-fPIC' code, but does not do so automatically when
- linking non-PIC code. This option requests the new PLT and GOT
- layout. A warning will be given if some object file requires the
- old style BSS PLT.
-
-`--sdata-got'
- The new secure PLT and GOT are placed differently relative to other
- sections compared to older BSS PLT and GOT placement. The
- location of `.plt' must change because the new secure PLT is an
- initialized section while the old PLT is uninitialized. The
- reason for the `.got' change is more subtle: The new placement
- allows `.got' to be read-only in applications linked with `-z
- relro -z now'. However, this placement means that `.sdata' cannot
- always be used in shared libraries, because the PowerPC ABI
- accesses `.sdata' in shared libraries from the GOT pointer.
- `--sdata-got' forces the old GOT placement. PowerPC GCC doesn't
- use `.sdata' in shared libraries, so this option is really only
- useful for other compilers that may do so.
-
-`--emit-stub-syms'
- This option causes `ld' to label linker stubs with a local symbol
- that encodes the stub type and destination.
-
-`--no-tls-optimize'
- PowerPC `ld' normally performs some optimization of code sequences
- used to access Thread-Local Storage. Use this option to disable
- the optimization.
-
-
-File: ld.info, Node: PowerPC64 ELF64, Next: SPU ELF, Prev: PowerPC ELF32, Up: Machine Dependent
-
-4.10 `ld' and PowerPC64 64-bit ELF Support
-==========================================
-
-`--stub-group-size'
- Long branch stubs, PLT call stubs and TOC adjusting stubs are
- placed by `ld' in stub sections located between groups of input
- sections. `--stub-group-size' specifies the maximum size of a
- group of input sections handled by one stub section. Since branch
- offsets are signed, a stub section may serve two groups of input
- sections, one group before the stub section, and one group after
- it. However, when using conditional branches that require stubs,
- it may be better (for branch prediction) that stub sections only
- serve one group of input sections. A negative value for `N'
- chooses this scheme, ensuring that branches to stubs always use a
- negative offset. Two special values of `N' are recognized, `1'
- and `-1'. These both instruct `ld' to automatically size input
- section groups for the branch types detected, with the same
- behaviour regarding stub placement as other positive or negative
- values of `N' respectively.
-
- Note that `--stub-group-size' does not split input sections. A
- single input section larger than the group size specified will of
- course create a larger group (of one section). If input sections
- are too large, it may not be possible for a branch to reach its
- stub.
-
-`--emit-stub-syms'
- This option causes `ld' to label linker stubs with a local symbol
- that encodes the stub type and destination.
-
-`--dotsyms, --no-dotsyms'
- These two options control how `ld' interprets version patterns in
- a version script. Older PowerPC64 compilers emitted both a
- function descriptor symbol with the same name as the function, and
- a code entry symbol with the name prefixed by a dot (`.'). To
- properly version a function `foo', the version script thus needs
- to control both `foo' and `.foo'. The option `--dotsyms', on by
- default, automatically adds the required dot-prefixed patterns.
- Use `--no-dotsyms' to disable this feature.
-
-`--no-tls-optimize'
- PowerPC64 `ld' normally performs some optimization of code
- sequences used to access Thread-Local Storage. Use this option to
- disable the optimization.
-
-`--no-opd-optimize'
- PowerPC64 `ld' normally removes `.opd' section entries
- corresponding to deleted link-once functions, or functions removed
- by the action of `--gc-sections' or linker script `/DISCARD/'.
- Use this option to disable `.opd' optimization.
-
-`--non-overlapping-opd'
- Some PowerPC64 compilers have an option to generate compressed
- `.opd' entries spaced 16 bytes apart, overlapping the third word,
- the static chain pointer (unused in C) with the first word of the
- next entry. This option expands such entries to the full 24 bytes.
-
-`--no-toc-optimize'
- PowerPC64 `ld' normally removes unused `.toc' section entries.
- Such entries are detected by examining relocations that reference
- the TOC in code sections. A reloc in a deleted code section marks
- a TOC word as unneeded, while a reloc in a kept code section marks
- a TOC word as needed. Since the TOC may reference itself, TOC
- relocs are also examined. TOC words marked as both needed and
- unneeded will of course be kept. TOC words without any referencing
- reloc are assumed to be part of a multi-word entry, and are kept or
- discarded as per the nearest marked preceding word. This works
- reliably for compiler generated code, but may be incorrect if
- assembly code is used to insert TOC entries. Use this option to
- disable the optimization.
-
-`--no-multi-toc'
- By default, PowerPC64 GCC generates code for a TOC model where TOC
- entries are accessed with a 16-bit offset from r2. This limits the
- total TOC size to 64K. PowerPC64 `ld' extends this limit by
- grouping code sections such that each group uses less than 64K for
- its TOC entries, then inserts r2 adjusting stubs between
- inter-group calls. `ld' does not split apart input sections, so
- cannot help if a single input file has a `.toc' section that
- exceeds 64K, most likely from linking multiple files with `ld -r'.
- Use this option to turn off this feature.
-
-
-File: ld.info, Node: SPU ELF, Next: TI COFF, Prev: PowerPC64 ELF64, Up: Machine Dependent
-
-4.11 `ld' and SPU ELF Support
-=============================
-
-`--plugin'
- This option marks an executable as a PIC plugin module.
-
-`--no-overlays'
- Normally, `ld' recognizes calls to functions within overlay
- regions, and redirects such calls to an overlay manager via a stub.
- `ld' also provides a built-in overlay manager. This option turns
- off all this special overlay handling.
-
-`--emit-stub-syms'
- This option causes `ld' to label overlay stubs with a local symbol
- that encodes the stub type and destination.
-
-`--extra-overlay-stubs'
- This option causes `ld' to add overlay call stubs on all function
- calls out of overlay regions. Normally stubs are not added on
- calls to non-overlay regions.
-
-`--local-store=lo:hi'
- `ld' usually checks that a final executable for SPU fits in the
- address range 0 to 256k. This option may be used to change the
- range. Disable the check entirely with `--local-store=0:0'.
-
-`--stack-analysis'
- SPU local store space is limited. Over-allocation of stack space
- unnecessarily limits space available for code and data, while
- under-allocation results in runtime failures. If given this
- option, `ld' will provide an estimate of maximum stack usage.
- `ld' does this by examining symbols in code sections to determine
- the extents of functions, and looking at function prologues for
- stack adjusting instructions. A call-graph is created by looking
- for relocations on branch instructions. The graph is then searched
- for the maximum stack usage path. Note that this analysis does not
- find calls made via function pointers, and does not handle
- recursion and other cycles in the call graph. Stack usage may be
- under-estimated if your code makes such calls. Also, stack usage
- for dynamic allocation, e.g. alloca, will not be detected. If a
- link map is requested, detailed information about each function's
- stack usage and calls will be given.
-
-`--emit-stack-syms'
- This option, if given along with `--stack-analysis' will result in
- `ld' emitting stack sizing symbols for each function. These take
- the form `__stack_<function_name>' for global functions, and
- `__stack_<number>_<function_name>' for static functions.
- `<number>' is the section id in hex. The value of such symbols is
- the stack requirement for the corresponding function. The symbol
- size will be zero, type `STT_NOTYPE', binding `STB_LOCAL', and
- section `SHN_ABS'.
-
-
-File: ld.info, Node: TI COFF, Next: WIN32, Prev: SPU ELF, Up: Machine Dependent
-
-4.12 `ld''s Support for Various TI COFF Versions
-================================================
-
-The `--format' switch allows selection of one of the various TI COFF
-versions. The latest of this writing is 2; versions 0 and 1 are also
-supported. The TI COFF versions also vary in header byte-order format;
-`ld' will read any version or byte order, but the output header format
-depends on the default specified by the specific target.
-
-
-File: ld.info, Node: WIN32, Next: Xtensa, Prev: TI COFF, Up: Machine Dependent
-
-4.13 `ld' and WIN32 (cygwin/mingw)
-==================================
-
-This section describes some of the win32 specific `ld' issues. See
-*note Command Line Options: Options. for detailed description of the
-command line options mentioned here.
-
-_import libraries_
- The standard Windows linker creates and uses so-called import
- libraries, which contains information for linking to dll's. They
- are regular static archives and are handled as any other static
- archive. The cygwin and mingw ports of `ld' have specific support
- for creating such libraries provided with the `--out-implib'
- command line option.
-
-_exporting DLL symbols_
- The cygwin/mingw `ld' has several ways to export symbols for dll's.
-
- _using auto-export functionality_
- By default `ld' exports symbols with the auto-export
- functionality, which is controlled by the following command
- line options:
-
- * -export-all-symbols [This is the default]
-
- * -exclude-symbols
-
- * -exclude-libs
-
- * -exclude-modules-for-implib
-
- * -version-script
-
- When auto-export is in operation, `ld' will export all the
- non-local (global and common) symbols it finds in a DLL, with
- the exception of a few symbols known to belong to the
- system's runtime and libraries. As it will often not be
- desirable to export all of a DLL's symbols, which may include
- private functions that are not part of any public interface,
- the command-line options listed above may be used to filter
- symbols out from the list for exporting. The `--output-def'
- option can be used in order to see the final list of exported
- symbols with all exclusions taken into effect.
-
- If `--export-all-symbols' is not given explicitly on the
- command line, then the default auto-export behavior will be
- _disabled_ if either of the following are true:
-
- * A DEF file is used.
-
- * Any symbol in any object file was marked with the
- __declspec(dllexport) attribute.
-
- _using a DEF file_
- Another way of exporting symbols is using a DEF file. A DEF
- file is an ASCII file containing definitions of symbols which
- should be exported when a dll is created. Usually it is
- named `<dll name>.def' and is added as any other object file
- to the linker's command line. The file's name must end in
- `.def' or `.DEF'.
-
- gcc -o <output> <objectfiles> <dll name>.def
-
- Using a DEF file turns off the normal auto-export behavior,
- unless the `--export-all-symbols' option is also used.
-
- Here is an example of a DEF file for a shared library called
- `xyz.dll':
-
- LIBRARY "xyz.dll" BASE=0x20000000
-
- EXPORTS
- foo
- bar
- _bar = bar
- another_foo = abc.dll.afoo
- var1 DATA
- doo = foo == foo2
- eoo DATA == var1
-
- This example defines a DLL with a non-default base address
- and seven symbols in the export table. The third exported
- symbol `_bar' is an alias for the second. The fourth symbol,
- `another_foo' is resolved by "forwarding" to another module
- and treating it as an alias for `afoo' exported from the DLL
- `abc.dll'. The final symbol `var1' is declared to be a data
- object. The `doo' symbol in export library is an alias of
- `foo', which gets the string name in export table `foo2'. The
- `eoo' symbol is an data export symbol, which gets in export
- table the name `var1'.
-
- The optional `LIBRARY <name>' command indicates the _internal_
- name of the output DLL. If `<name>' does not include a suffix,
- the default library suffix, `.DLL' is appended.
-
- When the .DEF file is used to build an application, rather
- than a library, the `NAME <name>' command should be used
- instead of `LIBRARY'. If `<name>' does not include a suffix,
- the default executable suffix, `.EXE' is appended.
-
- With either `LIBRARY <name>' or `NAME <name>' the optional
- specification `BASE = <number>' may be used to specify a
- non-default base address for the image.
-
- If neither `LIBRARY <name>' nor `NAME <name>' is specified,
- or they specify an empty string, the internal name is the
- same as the filename specified on the command line.
-
- The complete specification of an export symbol is:
-
- EXPORTS
- ( ( ( <name1> [ = <name2> ] )
- | ( <name1> = <module-name> . <external-name>))
- [ @ <integer> ] [NONAME] [DATA] [CONSTANT] [PRIVATE] [== <name3>] ) *
-
- Declares `<name1>' as an exported symbol from the DLL, or
- declares `<name1>' as an exported alias for `<name2>'; or
- declares `<name1>' as a "forward" alias for the symbol
- `<external-name>' in the DLL `<module-name>'. Optionally,
- the symbol may be exported by the specified ordinal
- `<integer>' alias. The optional `<name3>' is the to be used
- string in import/export table for the symbol.
-
- The optional keywords that follow the declaration indicate:
-
- `NONAME': Do not put the symbol name in the DLL's export
- table. It will still be exported by its ordinal alias
- (either the value specified by the .def specification or,
- otherwise, the value assigned by the linker). The symbol
- name, however, does remain visible in the import library (if
- any), unless `PRIVATE' is also specified.
-
- `DATA': The symbol is a variable or object, rather than a
- function. The import lib will export only an indirect
- reference to `foo' as the symbol `_imp__foo' (ie, `foo' must
- be resolved as `*_imp__foo').
-
- `CONSTANT': Like `DATA', but put the undecorated `foo' as
- well as `_imp__foo' into the import library. Both refer to the
- read-only import address table's pointer to the variable, not
- to the variable itself. This can be dangerous. If the user
- code fails to add the `dllimport' attribute and also fails to
- explicitly add the extra indirection that the use of the
- attribute enforces, the application will behave unexpectedly.
-
- `PRIVATE': Put the symbol in the DLL's export table, but do
- not put it into the static import library used to resolve
- imports at link time. The symbol can still be imported using
- the `LoadLibrary/GetProcAddress' API at runtime or by by
- using the GNU ld extension of linking directly to the DLL
- without an import library.
-
- See ld/deffilep.y in the binutils sources for the full
- specification of other DEF file statements
-
- While linking a shared dll, `ld' is able to create a DEF file
- with the `--output-def <file>' command line option.
-
- _Using decorations_
- Another way of marking symbols for export is to modify the
- source code itself, so that when building the DLL each symbol
- to be exported is declared as:
-
- __declspec(dllexport) int a_variable
- __declspec(dllexport) void a_function(int with_args)
-
- All such symbols will be exported from the DLL. If, however,
- any of the object files in the DLL contain symbols decorated
- in this way, then the normal auto-export behavior is
- disabled, unless the `--export-all-symbols' option is also
- used.
-
- Note that object files that wish to access these symbols must
- _not_ decorate them with dllexport. Instead, they should use
- dllimport, instead:
-
- __declspec(dllimport) int a_variable
- __declspec(dllimport) void a_function(int with_args)
-
- This complicates the structure of library header files,
- because when included by the library itself the header must
- declare the variables and functions as dllexport, but when
- included by client code the header must declare them as
- dllimport. There are a number of idioms that are typically
- used to do this; often client code can omit the __declspec()
- declaration completely. See `--enable-auto-import' and
- `automatic data imports' for more information.
-
-_automatic data imports_
- The standard Windows dll format supports data imports from dlls
- only by adding special decorations (dllimport/dllexport), which
- let the compiler produce specific assembler instructions to deal
- with this issue. This increases the effort necessary to port
- existing Un*x code to these platforms, especially for large c++
- libraries and applications. The auto-import feature, which was
- initially provided by Paul Sokolovsky, allows one to omit the
- decorations to achieve a behavior that conforms to that on
- POSIX/Un*x platforms. This feature is enabled with the
- `--enable-auto-import' command-line option, although it is enabled
- by default on cygwin/mingw. The `--enable-auto-import' option
- itself now serves mainly to suppress any warnings that are
- ordinarily emitted when linked objects trigger the feature's use.
-
- auto-import of variables does not always work flawlessly without
- additional assistance. Sometimes, you will see this message
-
- "variable '<var>' can't be auto-imported. Please read the
- documentation for ld's `--enable-auto-import' for details."
-
- The `--enable-auto-import' documentation explains why this error
- occurs, and several methods that can be used to overcome this
- difficulty. One of these methods is the _runtime pseudo-relocs_
- feature, described below.
-
- For complex variables imported from DLLs (such as structs or
- classes), object files typically contain a base address for the
- variable and an offset (_addend_) within the variable-to specify a
- particular field or public member, for instance. Unfortunately,
- the runtime loader used in win32 environments is incapable of
- fixing these references at runtime without the additional
- information supplied by dllimport/dllexport decorations. The
- standard auto-import feature described above is unable to resolve
- these references.
-
- The `--enable-runtime-pseudo-relocs' switch allows these
- references to be resolved without error, while leaving the task of
- adjusting the references themselves (with their non-zero addends)
- to specialized code provided by the runtime environment. Recent
- versions of the cygwin and mingw environments and compilers
- provide this runtime support; older versions do not. However, the
- support is only necessary on the developer's platform; the
- compiled result will run without error on an older system.
-
- `--enable-runtime-pseudo-relocs' is not the default; it must be
- explicitly enabled as needed.
-
-_direct linking to a dll_
- The cygwin/mingw ports of `ld' support the direct linking,
- including data symbols, to a dll without the usage of any import
- libraries. This is much faster and uses much less memory than
- does the traditional import library method, especially when
- linking large libraries or applications. When `ld' creates an
- import lib, each function or variable exported from the dll is
- stored in its own bfd, even though a single bfd could contain many
- exports. The overhead involved in storing, loading, and
- processing so many bfd's is quite large, and explains the
- tremendous time, memory, and storage needed to link against
- particularly large or complex libraries when using import libs.
-
- Linking directly to a dll uses no extra command-line switches
- other than `-L' and `-l', because `ld' already searches for a
- number of names to match each library. All that is needed from
- the developer's perspective is an understanding of this search, in
- order to force ld to select the dll instead of an import library.
-
- For instance, when ld is called with the argument `-lxxx' it will
- attempt to find, in the first directory of its search path,
-
- libxxx.dll.a
- xxx.dll.a
- libxxx.a
- xxx.lib
- cygxxx.dll (*)
- libxxx.dll
- xxx.dll
-
- before moving on to the next directory in the search path.
-
- (*) Actually, this is not `cygxxx.dll' but in fact is
- `<prefix>xxx.dll', where `<prefix>' is set by the `ld' option
- `--dll-search-prefix=<prefix>'. In the case of cygwin, the
- standard gcc spec file includes `--dll-search-prefix=cyg', so in
- effect we actually search for `cygxxx.dll'.
-
- Other win32-based unix environments, such as mingw or pw32, may
- use other `<prefix>'es, although at present only cygwin makes use
- of this feature. It was originally intended to help avoid name
- conflicts among dll's built for the various win32/un*x
- environments, so that (for example) two versions of a zlib dll
- could coexist on the same machine.
-
- The generic cygwin/mingw path layout uses a `bin' directory for
- applications and dll's and a `lib' directory for the import
- libraries (using cygwin nomenclature):
-
- bin/
- cygxxx.dll
- lib/
- libxxx.dll.a (in case of dll's)
- libxxx.a (in case of static archive)
-
- Linking directly to a dll without using the import library can be
- done two ways:
-
- 1. Use the dll directly by adding the `bin' path to the link line
- gcc -Wl,-verbose -o a.exe -L../bin/ -lxxx
-
- However, as the dll's often have version numbers appended to their
- names (`cygncurses-5.dll') this will often fail, unless one
- specifies `-L../bin -lncurses-5' to include the version. Import
- libs are generally not versioned, and do not have this difficulty.
-
- 2. Create a symbolic link from the dll to a file in the `lib'
- directory according to the above mentioned search pattern. This
- should be used to avoid unwanted changes in the tools needed for
- making the app/dll.
-
- ln -s bin/cygxxx.dll lib/[cyg|lib|]xxx.dll[.a]
-
- Then you can link without any make environment changes.
-
- gcc -Wl,-verbose -o a.exe -L../lib/ -lxxx
-
- This technique also avoids the version number problems, because
- the following is perfectly legal
-
- bin/
- cygxxx-5.dll
- lib/
- libxxx.dll.a -> ../bin/cygxxx-5.dll
-
- Linking directly to a dll without using an import lib will work
- even when auto-import features are exercised, and even when
- `--enable-runtime-pseudo-relocs' is used.
-
- Given the improvements in speed and memory usage, one might
- justifiably wonder why import libraries are used at all. There
- are three reasons:
-
- 1. Until recently, the link-directly-to-dll functionality did _not_
- work with auto-imported data.
-
- 2. Sometimes it is necessary to include pure static objects within
- the import library (which otherwise contains only bfd's for
- indirection symbols that point to the exports of a dll). Again,
- the import lib for the cygwin kernel makes use of this ability,
- and it is not possible to do this without an import lib.
-
- 3. Symbol aliases can only be resolved using an import lib. This
- is critical when linking against OS-supplied dll's (eg, the win32
- API) in which symbols are usually exported as undecorated aliases
- of their stdcall-decorated assembly names.
-
- So, import libs are not going away. But the ability to replace
- true import libs with a simple symbolic link to (or a copy of) a
- dll, in many cases, is a useful addition to the suite of tools
- binutils makes available to the win32 developer. Given the
- massive improvements in memory requirements during linking, storage
- requirements, and linking speed, we expect that many developers
- will soon begin to use this feature whenever possible.
-
-_symbol aliasing_
-
- _adding additional names_
- Sometimes, it is useful to export symbols with additional
- names. A symbol `foo' will be exported as `foo', but it can
- also be exported as `_foo' by using special directives in the
- DEF file when creating the dll. This will affect also the
- optional created import library. Consider the following DEF
- file:
-
- LIBRARY "xyz.dll" BASE=0x61000000
-
- EXPORTS
- foo
- _foo = foo
-
- The line `_foo = foo' maps the symbol `foo' to `_foo'.
-
- Another method for creating a symbol alias is to create it in
- the source code using the "weak" attribute:
-
- void foo () { /* Do something. */; }
- void _foo () __attribute__ ((weak, alias ("foo")));
-
- See the gcc manual for more information about attributes and
- weak symbols.
-
- _renaming symbols_
- Sometimes it is useful to rename exports. For instance, the
- cygwin kernel does this regularly. A symbol `_foo' can be
- exported as `foo' but not as `_foo' by using special
- directives in the DEF file. (This will also affect the import
- library, if it is created). In the following example:
-
- LIBRARY "xyz.dll" BASE=0x61000000
-
- EXPORTS
- _foo = foo
-
- The line `_foo = foo' maps the exported symbol `foo' to
- `_foo'.
-
- Note: using a DEF file disables the default auto-export behavior,
- unless the `--export-all-symbols' command line option is used.
- If, however, you are trying to rename symbols, then you should list
- _all_ desired exports in the DEF file, including the symbols that
- are not being renamed, and do _not_ use the `--export-all-symbols'
- option. If you list only the renamed symbols in the DEF file, and
- use `--export-all-symbols' to handle the other symbols, then the
- both the new names _and_ the original names for the renamed
- symbols will be exported. In effect, you'd be aliasing those
- symbols, not renaming them, which is probably not what you wanted.
-
-_weak externals_
- The Windows object format, PE, specifies a form of weak symbols
- called weak externals. When a weak symbol is linked and the
- symbol is not defined, the weak symbol becomes an alias for some
- other symbol. There are three variants of weak externals:
- * Definition is searched for in objects and libraries,
- historically called lazy externals.
-
- * Definition is searched for only in other objects, not in
- libraries. This form is not presently implemented.
-
- * No search; the symbol is an alias. This form is not presently
- implemented.
- As a GNU extension, weak symbols that do not specify an alternate
- symbol are supported. If the symbol is undefined when linking,
- the symbol uses a default value.
-
-_aligned common symbols_
- As a GNU extension to the PE file format, it is possible to
- specify the desired alignment for a common symbol. This
- information is conveyed from the assembler or compiler to the
- linker by means of GNU-specific commands carried in the object
- file's `.drectve' section, which are recognized by `ld' and
- respected when laying out the common symbols. Native tools will
- be able to process object files employing this GNU extension, but
- will fail to respect the alignment instructions, and may issue
- noisy warnings about unknown linker directives.
-
-
-File: ld.info, Node: Xtensa, Prev: WIN32, Up: Machine Dependent
-
-4.14 `ld' and Xtensa Processors
-===============================
-
-The default `ld' behavior for Xtensa processors is to interpret
-`SECTIONS' commands so that lists of explicitly named sections in a
-specification with a wildcard file will be interleaved when necessary to
-keep literal pools within the range of PC-relative load offsets. For
-example, with the command:
-
- SECTIONS
- {
- .text : {
- *(.literal .text)
- }
- }
-
-`ld' may interleave some of the `.literal' and `.text' sections from
-different object files to ensure that the literal pools are within the
-range of PC-relative load offsets. A valid interleaving might place
-the `.literal' sections from an initial group of files followed by the
-`.text' sections of that group of files. Then, the `.literal' sections
-from the rest of the files and the `.text' sections from the rest of
-the files would follow.
-
- Relaxation is enabled by default for the Xtensa version of `ld' and
-provides two important link-time optimizations. The first optimization
-is to combine identical literal values to reduce code size. A redundant
-literal will be removed and all the `L32R' instructions that use it
-will be changed to reference an identical literal, as long as the
-location of the replacement literal is within the offset range of all
-the `L32R' instructions. The second optimization is to remove
-unnecessary overhead from assembler-generated "longcall" sequences of
-`L32R'/`CALLXN' when the target functions are within range of direct
-`CALLN' instructions.
-
- For each of these cases where an indirect call sequence can be
-optimized to a direct call, the linker will change the `CALLXN'
-instruction to a `CALLN' instruction, remove the `L32R' instruction,
-and remove the literal referenced by the `L32R' instruction if it is
-not used for anything else. Removing the `L32R' instruction always
-reduces code size but can potentially hurt performance by changing the
-alignment of subsequent branch targets. By default, the linker will
-always preserve alignments, either by switching some instructions
-between 24-bit encodings and the equivalent density instructions or by
-inserting a no-op in place of the `L32R' instruction that was removed.
-If code size is more important than performance, the `--size-opt'
-option can be used to prevent the linker from widening density
-instructions or inserting no-ops, except in a few cases where no-ops
-are required for correctness.
-
- The following Xtensa-specific command-line options can be used to
-control the linker:
-
-`--size-opt'
- When optimizing indirect calls to direct calls, optimize for code
- size more than performance. With this option, the linker will not
- insert no-ops or widen density instructions to preserve branch
- target alignment. There may still be some cases where no-ops are
- required to preserve the correctness of the code.
-
-
-File: ld.info, Node: BFD, Next: Reporting Bugs, Prev: Machine Dependent, Up: Top
-
-5 BFD
-*****
-
-The linker accesses object and archive files using the BFD libraries.
-These libraries allow the linker to use the same routines to operate on
-object files whatever the object file format. A different object file
-format can be supported simply by creating a new BFD back end and adding
-it to the library. To conserve runtime memory, however, the linker and
-associated tools are usually configured to support only a subset of the
-object file formats available. You can use `objdump -i' (*note
-objdump: (binutils.info)objdump.) to list all the formats available for
-your configuration.
-
- As with most implementations, BFD is a compromise between several
-conflicting requirements. The major factor influencing BFD design was
-efficiency: any time used converting between formats is time which
-would not have been spent had BFD not been involved. This is partly
-offset by abstraction payback; since BFD simplifies applications and
-back ends, more time and care may be spent optimizing algorithms for a
-greater speed.
-
- One minor artifact of the BFD solution which you should bear in mind
-is the potential for information loss. There are two places where
-useful information can be lost using the BFD mechanism: during
-conversion and during output. *Note BFD information loss::.
-
-* Menu:
-
-* BFD outline:: How it works: an outline of BFD
-
-
-File: ld.info, Node: BFD outline, Up: BFD
-
-5.1 How It Works: An Outline of BFD
-===================================
-
-When an object file is opened, BFD subroutines automatically determine
-the format of the input object file. They then build a descriptor in
-memory with pointers to routines that will be used to access elements of
-the object file's data structures.
-
- As different information from the object files is required, BFD
-reads from different sections of the file and processes them. For
-example, a very common operation for the linker is processing symbol
-tables. Each BFD back end provides a routine for converting between
-the object file's representation of symbols and an internal canonical
-format. When the linker asks for the symbol table of an object file, it
-calls through a memory pointer to the routine from the relevant BFD
-back end which reads and converts the table into a canonical form. The
-linker then operates upon the canonical form. When the link is finished
-and the linker writes the output file's symbol table, another BFD back
-end routine is called to take the newly created symbol table and
-convert it into the chosen output format.
-
-* Menu:
-
-* BFD information loss:: Information Loss
-* Canonical format:: The BFD canonical object-file format
-
-
-File: ld.info, Node: BFD information loss, Next: Canonical format, Up: BFD outline
-
-5.1.1 Information Loss
-----------------------
-
-_Information can be lost during output._ The output formats supported
-by BFD do not provide identical facilities, and information which can
-be described in one form has nowhere to go in another format. One
-example of this is alignment information in `b.out'. There is nowhere
-in an `a.out' format file to store alignment information on the
-contained data, so when a file is linked from `b.out' and an `a.out'
-image is produced, alignment information will not propagate to the
-output file. (The linker will still use the alignment information
-internally, so the link is performed correctly).
-
- Another example is COFF section names. COFF files may contain an
-unlimited number of sections, each one with a textual section name. If
-the target of the link is a format which does not have many sections
-(e.g., `a.out') or has sections without names (e.g., the Oasys format),
-the link cannot be done simply. You can circumvent this problem by
-describing the desired input-to-output section mapping with the linker
-command language.
-
- _Information can be lost during canonicalization._ The BFD internal
-canonical form of the external formats is not exhaustive; there are
-structures in input formats for which there is no direct representation
-internally. This means that the BFD back ends cannot maintain all
-possible data richness through the transformation between external to
-internal and back to external formats.
-
- This limitation is only a problem when an application reads one
-format and writes another. Each BFD back end is responsible for
-maintaining as much data as possible, and the internal BFD canonical
-form has structures which are opaque to the BFD core, and exported only
-to the back ends. When a file is read in one format, the canonical form
-is generated for BFD and the application. At the same time, the back
-end saves away any information which may otherwise be lost. If the data
-is then written back in the same format, the back end routine will be
-able to use the canonical form provided by the BFD core as well as the
-information it prepared earlier. Since there is a great deal of
-commonality between back ends, there is no information lost when
-linking or copying big endian COFF to little endian COFF, or `a.out' to
-`b.out'. When a mixture of formats is linked, the information is only
-lost from the files whose format differs from the destination.
-
-
-File: ld.info, Node: Canonical format, Prev: BFD information loss, Up: BFD outline
-
-5.1.2 The BFD canonical object-file format
-------------------------------------------
-
-The greatest potential for loss of information occurs when there is the
-least overlap between the information provided by the source format,
-that stored by the canonical format, and that needed by the destination
-format. A brief description of the canonical form may help you
-understand which kinds of data you can count on preserving across
-conversions.
-
-_files_
- Information stored on a per-file basis includes target machine
- architecture, particular implementation format type, a demand
- pageable bit, and a write protected bit. Information like Unix
- magic numbers is not stored here--only the magic numbers' meaning,
- so a `ZMAGIC' file would have both the demand pageable bit and the
- write protected text bit set. The byte order of the target is
- stored on a per-file basis, so that big- and little-endian object
- files may be used with one another.
-
-_sections_
- Each section in the input file contains the name of the section,
- the section's original address in the object file, size and
- alignment information, various flags, and pointers into other BFD
- data structures.
-
-_symbols_
- Each symbol contains a pointer to the information for the object
- file which originally defined it, its name, its value, and various
- flag bits. When a BFD back end reads in a symbol table, it
- relocates all symbols to make them relative to the base of the
- section where they were defined. Doing this ensures that each
- symbol points to its containing section. Each symbol also has a
- varying amount of hidden private data for the BFD back end. Since
- the symbol points to the original file, the private data format
- for that symbol is accessible. `ld' can operate on a collection
- of symbols of wildly different formats without problems.
-
- Normal global and simple local symbols are maintained on output,
- so an output file (no matter its format) will retain symbols
- pointing to functions and to global, static, and common variables.
- Some symbol information is not worth retaining; in `a.out', type
- information is stored in the symbol table as long symbol names.
- This information would be useless to most COFF debuggers; the
- linker has command line switches to allow users to throw it away.
-
- There is one word of type information within the symbol, so if the
- format supports symbol type information within symbols (for
- example, COFF, IEEE, Oasys) and the type is simple enough to fit
- within one word (nearly everything but aggregates), the
- information will be preserved.
-
-_relocation level_
- Each canonical BFD relocation record contains a pointer to the
- symbol to relocate to, the offset of the data to relocate, the
- section the data is in, and a pointer to a relocation type
- descriptor. Relocation is performed by passing messages through
- the relocation type descriptor and the symbol pointer. Therefore,
- relocations can be performed on output data using a relocation
- method that is only available in one of the input formats. For
- instance, Oasys provides a byte relocation format. A relocation
- record requesting this relocation type would point indirectly to a
- routine to perform this, so the relocation may be performed on a
- byte being written to a 68k COFF file, even though 68k COFF has no
- such relocation type.
-
-_line numbers_
- Object formats can contain, for debugging purposes, some form of
- mapping between symbols, source line numbers, and addresses in the
- output file. These addresses have to be relocated along with the
- symbol information. Each symbol with an associated list of line
- number records points to the first record of the list. The head
- of a line number list consists of a pointer to the symbol, which
- allows finding out the address of the function whose line number
- is being described. The rest of the list is made up of pairs:
- offsets into the section and line numbers. Any format which can
- simply derive this information can pass it successfully between
- formats (COFF, IEEE and Oasys).
-
-
-File: ld.info, Node: Reporting Bugs, Next: MRI, Prev: BFD, Up: Top
-
-6 Reporting Bugs
-****************
-
-Your bug reports play an essential role in making `ld' 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 `ld' work
-better. Bug reports are your contribution to the maintenance of `ld'.
-
- 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
-
-
-File: ld.info, Node: Bug Criteria, Next: Bug Reporting, Up: Reporting Bugs
-
-6.1 Have You Found a Bug?
-=========================
-
-If you are not sure whether you have found a bug, here are some
-guidelines:
-
- * If the linker gets a fatal signal, for any input whatever, that is
- a `ld' bug. Reliable linkers never crash.
-
- * If `ld' produces an error message for valid input, that is a bug.
-
- * If `ld' does not produce an error message for invalid input, that
- may be a bug. In the general case, the linker can not verify that
- object files are correct.
-
- * If you are an experienced user of linkers, your suggestions for
- improvement of `ld' are welcome in any case.
-
-
-File: ld.info, Node: Bug Reporting, Prev: Bug Criteria, Up: Reporting Bugs
-
-6.2 How to Report Bugs
-======================
-
-A number of companies and individuals offer support for GNU products.
-If you obtained `ld' 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 `etc/SERVICE' in the GNU Emacs distribution.
-
- Otherwise, send bug reports for `ld' to
-`http://www.sourceware.org/bugzilla/'.
-
- The fundamental principle of reporting bugs usefully is this:
-*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 linker 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?" This cannot help us fix a bug, so it is basically useless. We
-respond by asking for enough details to enable us to investigate. You
-might as well expedite matters by sending them to begin with.
-
- To enable us to fix the bug, you should include all these things:
-
- * The version of `ld'. `ld' announces it if you start it with the
- `--version' argument.
-
- Without this, we will not know whether there is any point in
- looking for the bug in the current version of `ld'.
-
- * Any patches you may have applied to the `ld' source, including any
- patches made to the `BFD' library.
-
- * The type of machine you are using, and the operating system name
- and version number.
-
- * What compiler (and its version) was used to compile `ld'--e.g.
- "`gcc-2.7'".
-
- * The command arguments you gave the linker to link 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.
-
- * A complete input file, or set of input files, that will reproduce
- the bug. It is generally most helpful to send the actual object
- files provided that they are reasonably small. Say no more than
- 10K. For bigger files you can either make them available by FTP
- or HTTP or else state that you are willing to send the object
- file(s) to whomever requests them. (Note - your email will be
- going to a mailing list, so we do not want to clog it up with
- large attachments). But small attachments are best.
-
- If the source files were assembled using `gas' or compiled using
- `gcc', then it may be OK to send the source files rather than the
- object files. In this case, be sure to say exactly what version of
- `gas' or `gcc' was used to produce the object files. Also say how
- `gas' or `gcc' were configured.
-
- * 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 `ld' 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 `ld' is out of sync, 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.
-
- * If you wish to suggest changes to the `ld' source, send us context
- diffs, as generated by `diff' with the `-u', `-c', or `-p' option.
- Always send diffs from the old file to the new file. If you even
- discuss something in the `ld' 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.
-
- Here are some things that are not necessary:
-
- * 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 _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.
-
- * 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 `ld' 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.
-
- * 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.
-
-
-File: ld.info, Node: MRI, Next: GNU Free Documentation License, Prev: Reporting Bugs, Up: Top
-
-Appendix A MRI Compatible Script Files
-**************************************
-
-To aid users making the transition to GNU `ld' from the MRI linker,
-`ld' can use MRI compatible linker scripts as an alternative to the
-more general-purpose linker scripting language described in *note
-Scripts::. MRI compatible linker scripts have a much simpler command
-set than the scripting language otherwise used with `ld'. GNU `ld'
-supports the most commonly used MRI linker commands; these commands are
-described here.
-
- In general, MRI scripts aren't of much use with the `a.out' object
-file format, since it only has three sections and MRI scripts lack some
-features to make use of them.
-
- You can specify a file containing an MRI-compatible script using the
-`-c' command-line option.
-
- Each command in an MRI-compatible script occupies its own line; each
-command line starts with the keyword that identifies the command (though
-blank lines are also allowed for punctuation). If a line of an
-MRI-compatible script begins with an unrecognized keyword, `ld' issues
-a warning message, but continues processing the script.
-
- Lines beginning with `*' are comments.
-
- You can write these commands using all upper-case letters, or all
-lower case; for example, `chip' is the same as `CHIP'. The following
-list shows only the upper-case form of each command.
-
-`ABSOLUTE SECNAME'
-`ABSOLUTE SECNAME, SECNAME, ... SECNAME'
- Normally, `ld' includes in the output file all sections from all
- the input files. However, in an MRI-compatible script, you can
- use the `ABSOLUTE' command to restrict the sections that will be
- present in your output program. If the `ABSOLUTE' command is used
- at all in a script, then only the sections named explicitly in
- `ABSOLUTE' commands will appear in the linker output. You can
- still use other input sections (whatever you select on the command
- line, or using `LOAD') to resolve addresses in the output file.
-
-`ALIAS OUT-SECNAME, IN-SECNAME'
- Use this command to place the data from input section IN-SECNAME
- in a section called OUT-SECNAME in the linker output file.
-
- IN-SECNAME may be an integer.
-
-`ALIGN SECNAME = EXPRESSION'
- Align the section called SECNAME to EXPRESSION. The EXPRESSION
- should be a power of two.
-
-`BASE EXPRESSION'
- Use the value of EXPRESSION as the lowest address (other than
- absolute addresses) in the output file.
-
-`CHIP EXPRESSION'
-`CHIP EXPRESSION, EXPRESSION'
- This command does nothing; it is accepted only for compatibility.
-
-`END'
- This command does nothing whatever; it's only accepted for
- compatibility.
-
-`FORMAT OUTPUT-FORMAT'
- Similar to the `OUTPUT_FORMAT' command in the more general linker
- language, but restricted to one of these output formats:
-
- 1. S-records, if OUTPUT-FORMAT is `S'
-
- 2. IEEE, if OUTPUT-FORMAT is `IEEE'
-
- 3. COFF (the `coff-m68k' variant in BFD), if OUTPUT-FORMAT is
- `COFF'
-
-`LIST ANYTHING...'
- Print (to the standard output file) a link map, as produced by the
- `ld' command-line option `-M'.
-
- The keyword `LIST' may be followed by anything on the same line,
- with no change in its effect.
-
-`LOAD FILENAME'
-`LOAD FILENAME, FILENAME, ... FILENAME'
- Include one or more object file FILENAME in the link; this has the
- same effect as specifying FILENAME directly on the `ld' command
- line.
-
-`NAME OUTPUT-NAME'
- OUTPUT-NAME is the name for the program produced by `ld'; the
- MRI-compatible command `NAME' is equivalent to the command-line
- option `-o' or the general script language command `OUTPUT'.
-
-`ORDER SECNAME, SECNAME, ... SECNAME'
-`ORDER SECNAME SECNAME SECNAME'
- Normally, `ld' orders the sections in its output file in the order
- in which they first appear in the input files. In an
- MRI-compatible script, you can override this ordering with the
- `ORDER' command. The sections you list with `ORDER' will appear
- first in your output file, in the order specified.
-
-`PUBLIC NAME=EXPRESSION'
-`PUBLIC NAME,EXPRESSION'
-`PUBLIC NAME EXPRESSION'
- Supply a value (EXPRESSION) for external symbol NAME used in the
- linker input files.
-
-`SECT SECNAME, EXPRESSION'
-`SECT SECNAME=EXPRESSION'
-`SECT SECNAME EXPRESSION'
- You can use any of these three forms of the `SECT' command to
- specify the start address (EXPRESSION) for section SECNAME. If
- you have more than one `SECT' statement for the same SECNAME, only
- the _first_ sets the start address.
-
-
-File: ld.info, Node: GNU Free Documentation License, Next: LD Index, Prev: MRI, Up: Top
-
-Appendix B GNU Free Documentation License
-*****************************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: ld.info, Node: LD Index, Prev: GNU Free Documentation License, Up: Top
-
-LD Index
-********
-
-
-* Menu:
-
-* ": Symbols. (line 6)
-* -(: Options. (line 696)
-* --accept-unknown-input-arch: Options. (line 714)
-* --add-needed: Options. (line 738)
-* --add-stdcall-alias: Options. (line 1571)
-* --allow-multiple-definition: Options. (line 984)
-* --allow-shlib-undefined: Options. (line 990)
-* --architecture=ARCH: Options. (line 123)
-* --as-needed: Options. (line 724)
-* --audit AUDITLIB: Options. (line 112)
-* --auxiliary=NAME: Options. (line 255)
-* --bank-window: Options. (line 1980)
-* --base-file: Options. (line 1576)
-* --be8: ARM. (line 28)
-* --bss-plt: PowerPC ELF32. (line 16)
-* --build-id: Options. (line 1533)
-* --build-id=STYLE: Options. (line 1533)
-* --check-sections: Options. (line 817)
-* --copy-dt-needed-entries: Options. (line 829)
-* --cref: Options. (line 850)
-* --default-imported-symver: Options. (line 1027)
-* --default-script=SCRIPT: Options. (line 541)
-* --default-symver: Options. (line 1023)
-* --defsym=SYMBOL=EXP: Options. (line 878)
-* --demangle[=STYLE]: Options. (line 891)
-* --depaudit AUDITLIB: Options. (line 177)
-* --disable-auto-image-base: Options. (line 1755)
-* --disable-auto-import: Options. (line 1890)
-* --disable-long-section-names: Options. (line 1586)
-* --disable-new-dtags: Options. (line 1496)
-* --disable-runtime-pseudo-reloc: Options. (line 1903)
-* --disable-stdcall-fixup: Options. (line 1608)
-* --discard-all: Options. (line 587)
-* --discard-locals: Options. (line 591)
-* --dll: Options. (line 1581)
-* --dll-search-prefix: Options. (line 1761)
-* --dotsyms: PowerPC64 ELF64. (line 33)
-* --dynamic-linker=FILE: Options. (line 904)
-* --dynamic-list-cpp-new: Options. (line 809)
-* --dynamic-list-cpp-typeinfo: Options. (line 813)
-* --dynamic-list-data: Options. (line 806)
-* --dynamic-list=DYNAMIC-LIST-FILE: Options. (line 793)
-* --dynamicbase: Options. (line 1939)
-* --eh-frame-hdr: Options. (line 1492)
-* --emit-relocs: Options. (line 476)
-* --emit-stack-syms: SPU ELF. (line 46)
-* --emit-stub-syms <1>: SPU ELF. (line 15)
-* --emit-stub-syms <2>: PowerPC ELF32. (line 47)
-* --emit-stub-syms: PowerPC64 ELF64. (line 29)
-* --enable-auto-image-base: Options. (line 1747)
-* --enable-auto-import: Options. (line 1770)
-* --enable-extra-pe-debug: Options. (line 1908)
-* --enable-long-section-names: Options. (line 1586)
-* --enable-new-dtags: Options. (line 1496)
-* --enable-runtime-pseudo-reloc: Options. (line 1895)
-* --enable-stdcall-fixup: Options. (line 1608)
-* --entry=ENTRY: Options. (line 187)
-* --error-unresolved-symbols: Options. (line 1445)
-* --exclude-all-symbols: Options. (line 1662)
-* --exclude-libs: Options. (line 197)
-* --exclude-modules-for-implib: Options. (line 208)
-* --exclude-symbols: Options. (line 1656)
-* --export-all-symbols: Options. (line 1632)
-* --export-dynamic: Options. (line 221)
-* --extra-overlay-stubs: SPU ELF. (line 19)
-* --fatal-warnings: Options. (line 911)
-* --file-alignment: Options. (line 1666)
-* --filter=NAME: Options. (line 276)
-* --fix-cortex-a8: i960. (line 39)
-* --fix-v4bx: ARM. (line 49)
-* --fix-v4bx-interworking: ARM. (line 62)
-* --force-dynamic: Options. (line 485)
-* --force-exe-suffix: Options. (line 916)
-* --forceinteg: Options. (line 1944)
-* --format=FORMAT: Options. (line 134)
-* --format=VERSION: TI COFF. (line 6)
-* --gc-sections: Options. (line 926)
-* --got: Options. (line 1993)
-* --got=TYPE: M68K. (line 6)
-* --gpsize=VALUE: Options. (line 309)
-* --hash-size=NUMBER: Options. (line 1505)
-* --hash-style=STYLE: Options. (line 1513)
-* --heap: Options. (line 1672)
-* --help: Options. (line 957)
-* --image-base: Options. (line 1679)
-* --just-symbols=FILE: Options. (line 508)
-* --kill-at: Options. (line 1688)
-* --large-address-aware: Options. (line 1693)
-* --leading-underscore: Options. (line 1626)
-* --library-path=DIR: Options. (line 368)
-* --library=NAMESPEC: Options. (line 335)
-* --local-store=lo:hi: SPU ELF. (line 24)
-* --major-image-version: Options. (line 1702)
-* --major-os-version: Options. (line 1707)
-* --major-subsystem-version: Options. (line 1711)
-* --merge-exidx-entries: i960. (line 48)
-* --minor-image-version: Options. (line 1716)
-* --minor-os-version: Options. (line 1721)
-* --minor-subsystem-version: Options. (line 1725)
-* --mri-script=MRI-CMDFILE: Options. (line 158)
-* --multi-subspace: HPPA ELF32. (line 6)
-* --nmagic: Options. (line 439)
-* --no-accept-unknown-input-arch: Options. (line 714)
-* --no-add-needed: Options. (line 738)
-* --no-allow-shlib-undefined: Options. (line 990)
-* --no-as-needed: Options. (line 724)
-* --no-bind: Options. (line 1958)
-* --no-check-sections: Options. (line 817)
-* --no-copy-dt-needed-entries: Options. (line 829)
-* --no-define-common: Options. (line 862)
-* --no-demangle: Options. (line 891)
-* --no-dotsyms: PowerPC64 ELF64. (line 33)
-* --no-enum-size-warning: ARM. (line 111)
-* --no-export-dynamic: Options. (line 221)
-* --no-fatal-warnings: Options. (line 911)
-* --no-fix-cortex-a8: i960. (line 39)
-* --no-gc-sections: Options. (line 926)
-* --no-isolation: Options. (line 1951)
-* --no-keep-memory: Options. (line 969)
-* --no-leading-underscore: Options. (line 1626)
-* --no-merge-exidx-entries: i960. (line 48)
-* --no-multi-toc: PowerPC64 ELF64. (line 74)
-* --no-omagic: Options. (line 454)
-* --no-opd-optimize: PowerPC64 ELF64. (line 48)
-* --no-overlays: SPU ELF. (line 9)
-* --no-print-gc-sections: Options. (line 948)
-* --no-seh: Options. (line 1954)
-* --no-tls-optimize <1>: PowerPC ELF32. (line 51)
-* --no-tls-optimize: PowerPC64 ELF64. (line 43)
-* --no-toc-optimize: PowerPC64 ELF64. (line 60)
-* --no-trampoline: Options. (line 1974)
-* --no-undefined: Options. (line 976)
-* --no-undefined-version: Options. (line 1018)
-* --no-warn-mismatch: Options. (line 1031)
-* --no-warn-search-mismatch: Options. (line 1040)
-* --no-wchar-size-warning: ARM. (line 118)
-* --no-whole-archive: Options. (line 1044)
-* --noinhibit-exec: Options. (line 1048)
-* --non-overlapping-opd: PowerPC64 ELF64. (line 54)
-* --nxcompat: Options. (line 1947)
-* --oformat=OUTPUT-FORMAT: Options. (line 1060)
-* --omagic: Options. (line 445)
-* --out-implib: Options. (line 1738)
-* --output-def: Options. (line 1730)
-* --output=OUTPUT: Options. (line 460)
-* --pic-executable: Options. (line 1073)
-* --pic-veneer: ARM. (line 124)
-* --plugin: SPU ELF. (line 6)
-* --print-gc-sections: Options. (line 948)
-* --print-map: Options. (line 402)
-* --reduce-memory-overheads: Options. (line 1519)
-* --relax: Options. (line 1089)
-* --relax on i960: i960. (line 31)
-* --relax on PowerPC: PowerPC ELF32. (line 6)
-* --relax on Xtensa: Xtensa. (line 27)
-* --relocatable: Options. (line 489)
-* --retain-symbols-file=FILENAME: Options. (line 1115)
-* --script=SCRIPT: Options. (line 532)
-* --sdata-got: PowerPC ELF32. (line 33)
-* --section-alignment: Options. (line 1913)
-* --section-start=SECTIONNAME=ORG: Options. (line 1271)
-* --secure-plt: PowerPC ELF32. (line 26)
-* --sort-common: Options. (line 1213)
-* --sort-section=alignment: Options. (line 1228)
-* --sort-section=name: Options. (line 1224)
-* --split-by-file: Options. (line 1232)
-* --split-by-reloc: Options. (line 1237)
-* --stack: Options. (line 1919)
-* --stack-analysis: SPU ELF. (line 29)
-* --stats: Options. (line 1250)
-* --strip-all: Options. (line 519)
-* --strip-debug: Options. (line 523)
-* --stub-group-size: PowerPC64 ELF64. (line 6)
-* --stub-group-size=N <1>: ARM. (line 129)
-* --stub-group-size=N: HPPA ELF32. (line 12)
-* --subsystem: Options. (line 1926)
-* --support-old-code: ARM. (line 6)
-* --sysroot=DIRECTORY: Options. (line 1254)
-* --target-help: Options. (line 961)
-* --target1-abs: ARM. (line 32)
-* --target1-rel: ARM. (line 32)
-* --target2=TYPE: ARM. (line 37)
-* --thumb-entry=ENTRY: ARM. (line 17)
-* --trace: Options. (line 528)
-* --trace-symbol=SYMBOL: Options. (line 597)
-* --traditional-format: Options. (line 1259)
-* --tsaware: Options. (line 1964)
-* --undefined=SYMBOL: Options. (line 554)
-* --unique[=SECTION]: Options. (line 572)
-* --unresolved-symbols: Options. (line 1290)
-* --use-blx: ARM. (line 74)
-* --use-nul-prefixed-import-tables: ARM. (line 23)
-* --verbose: Options. (line 1319)
-* --version: Options. (line 581)
-* --version-script=VERSION-SCRIPTFILE: Options. (line 1325)
-* --vfp11-denorm-fix: ARM. (line 83)
-* --warn-alternate-em: Options. (line 1437)
-* --warn-common: Options. (line 1336)
-* --warn-constructors: Options. (line 1404)
-* --warn-multiple-gp: Options. (line 1409)
-* --warn-once: Options. (line 1423)
-* --warn-section-align: Options. (line 1427)
-* --warn-shared-textrel: Options. (line 1434)
-* --warn-unresolved-symbols: Options. (line 1440)
-* --wdmdriver: Options. (line 1961)
-* --whole-archive: Options. (line 1449)
-* --wrap=SYMBOL: Options. (line 1463)
-* -A ARCH: Options. (line 122)
-* -a KEYWORD: Options. (line 105)
-* -assert KEYWORD: Options. (line 745)
-* -b FORMAT: Options. (line 134)
-* -Bdynamic: Options. (line 748)
-* -Bgroup: Options. (line 758)
-* -Bshareable: Options. (line 1206)
-* -Bstatic: Options. (line 765)
-* -Bsymbolic: Options. (line 780)
-* -Bsymbolic-functions: Options. (line 787)
-* -c MRI-CMDFILE: Options. (line 158)
-* -call_shared: Options. (line 748)
-* -d: Options. (line 168)
-* -dc: Options. (line 168)
-* -dn: Options. (line 765)
-* -dp: Options. (line 168)
-* -dT SCRIPT: Options. (line 541)
-* -dy: Options. (line 748)
-* -E: Options. (line 221)
-* -e ENTRY: Options. (line 187)
-* -EB: Options. (line 248)
-* -EL: Options. (line 251)
-* -F NAME: Options. (line 276)
-* -f NAME: Options. (line 255)
-* -fini=NAME: Options. (line 300)
-* -g: Options. (line 306)
-* -G VALUE: Options. (line 309)
-* -h NAME: Options. (line 317)
-* -i: Options. (line 326)
-* -IFILE: Options. (line 904)
-* -init=NAME: Options. (line 329)
-* -L DIR: Options. (line 368)
-* -l NAMESPEC: Options. (line 335)
-* -M: Options. (line 402)
-* -m EMULATION: Options. (line 392)
-* -Map=MAPFILE: Options. (line 965)
-* -N: Options. (line 445)
-* -n: Options. (line 439)
-* -no-relax: Options. (line 1089)
-* -non_shared: Options. (line 765)
-* -nostdlib: Options. (line 1054)
-* -O LEVEL: Options. (line 466)
-* -o OUTPUT: Options. (line 460)
-* -P AUDITLIB: Options. (line 177)
-* -pie: Options. (line 1073)
-* -q: Options. (line 476)
-* -qmagic: Options. (line 1083)
-* -Qy: Options. (line 1086)
-* -r: Options. (line 489)
-* -R FILE: Options. (line 508)
-* -rpath-link=DIR: Options. (line 1151)
-* -rpath=DIR: Options. (line 1129)
-* -s: Options. (line 519)
-* -S: Options. (line 523)
-* -shared: Options. (line 1206)
-* -soname=NAME: Options. (line 317)
-* -static: Options. (line 765)
-* -t: Options. (line 528)
-* -T SCRIPT: Options. (line 532)
-* -Tbss=ORG: Options. (line 1280)
-* -Tdata=ORG: Options. (line 1280)
-* -Ttext-segment=ORG: Options. (line 1286)
-* -Ttext=ORG: Options. (line 1280)
-* -u SYMBOL: Options. (line 554)
-* -Ur: Options. (line 562)
-* -V: Options. (line 581)
-* -v: Options. (line 581)
-* -X: Options. (line 591)
-* -x: Options. (line 587)
-* -Y PATH: Options. (line 606)
-* -y SYMBOL: Options. (line 597)
-* -z defs: Options. (line 976)
-* -z KEYWORD: Options. (line 610)
-* -z muldefs: Options. (line 984)
-* .: Location Counter. (line 6)
-* /DISCARD/: Output Section Discarding.
- (line 21)
-* :PHDR: Output Section Phdr.
- (line 6)
-* =FILLEXP: Output Section Fill.
- (line 6)
-* >REGION: Output Section Region.
- (line 6)
-* [COMMON]: Input Section Common.
- (line 29)
-* ABSOLUTE (MRI): MRI. (line 33)
-* absolute and relocatable symbols: Expression Section. (line 6)
-* absolute expressions: Expression Section. (line 6)
-* ABSOLUTE(EXP): Builtin Functions. (line 10)
-* ADDR(SECTION): Builtin Functions. (line 17)
-* address, section: Output Section Address.
- (line 6)
-* ALIAS (MRI): MRI. (line 44)
-* ALIGN (MRI): MRI. (line 50)
-* align expression: Builtin Functions. (line 38)
-* align location counter: Builtin Functions. (line 38)
-* ALIGN(ALIGN): Builtin Functions. (line 38)
-* ALIGN(EXP,ALIGN): Builtin Functions. (line 38)
-* ALIGN(SECTION_ALIGN): Forced Output Alignment.
- (line 6)
-* aligned common symbols: WIN32. (line 424)
-* ALIGNOF(SECTION): Builtin Functions. (line 63)
-* allocating memory: MEMORY. (line 6)
-* architecture: Miscellaneous Commands.
- (line 72)
-* architectures: Options. (line 122)
-* archive files, from cmd line: Options. (line 335)
-* archive search path in linker script: File Commands. (line 74)
-* arithmetic: Expressions. (line 6)
-* arithmetic operators: Operators. (line 6)
-* ARM interworking support: ARM. (line 6)
-* AS_NEEDED(FILES): File Commands. (line 54)
-* ASSERT: Miscellaneous Commands.
- (line 9)
-* assertion in linker script: Miscellaneous Commands.
- (line 9)
-* assignment in scripts: Assignments. (line 6)
-* AT(LMA): Output Section LMA. (line 6)
-* AT>LMA_REGION: Output Section LMA. (line 6)
-* automatic data imports: WIN32. (line 191)
-* back end: BFD. (line 6)
-* BASE (MRI): MRI. (line 54)
-* BE8: ARM. (line 28)
-* BFD canonical format: Canonical format. (line 11)
-* BFD requirements: BFD. (line 16)
-* big-endian objects: Options. (line 248)
-* binary input format: Options. (line 134)
-* BLOCK(EXP): Builtin Functions. (line 76)
-* bug criteria: Bug Criteria. (line 6)
-* bug reports: Bug Reporting. (line 6)
-* bugs in ld: Reporting Bugs. (line 6)
-* BYTE(EXPRESSION): Output Section Data.
- (line 6)
-* C++ constructors, arranging in link: Output Section Keywords.
- (line 19)
-* CHIP (MRI): MRI. (line 58)
-* COLLECT_NO_DEMANGLE: Environment. (line 29)
-* combining symbols, warnings on: Options. (line 1336)
-* command files: Scripts. (line 6)
-* command line: Options. (line 6)
-* common allocation: Options. (line 862)
-* common allocation in linker script: Miscellaneous Commands.
- (line 25)
-* common symbol placement: Input Section Common.
- (line 6)
-* COMMONPAGESIZE: Symbolic Constants. (line 13)
-* compatibility, MRI: Options. (line 158)
-* CONSTANT: Symbolic Constants. (line 6)
-* constants in linker scripts: Constants. (line 6)
-* constraints on output sections: Output Section Constraint.
- (line 6)
-* CONSTRUCTORS: Output Section Keywords.
- (line 19)
-* constructors: Options. (line 562)
-* constructors, arranging in link: Output Section Keywords.
- (line 19)
-* Cortex-A8 erratum workaround: i960. (line 39)
-* crash of linker: Bug Criteria. (line 9)
-* CREATE_OBJECT_SYMBOLS: Output Section Keywords.
- (line 9)
-* creating a DEF file: WIN32. (line 158)
-* cross reference table: Options. (line 850)
-* cross references: Miscellaneous Commands.
- (line 56)
-* current output location: Location Counter. (line 6)
-* data: Output Section Data.
- (line 6)
-* DATA_SEGMENT_ALIGN(MAXPAGESIZE, COMMONPAGESIZE): Builtin Functions.
- (line 81)
-* DATA_SEGMENT_END(EXP): Builtin Functions. (line 102)
-* DATA_SEGMENT_RELRO_END(OFFSET, EXP): Builtin Functions. (line 108)
-* dbx: Options. (line 1264)
-* DEF files, creating: Options. (line 1730)
-* default emulation: Environment. (line 21)
-* default input format: Environment. (line 9)
-* DEFINED(SYMBOL): Builtin Functions. (line 119)
-* deleting local symbols: Options. (line 587)
-* demangling, default: Environment. (line 29)
-* demangling, from command line: Options. (line 891)
-* direct linking to a dll: WIN32. (line 239)
-* discarding sections: Output Section Discarding.
- (line 6)
-* discontinuous memory: MEMORY. (line 6)
-* DLLs, creating: Options. (line 1738)
-* DLLs, linking to: Options. (line 1761)
-* dot: Location Counter. (line 6)
-* dot inside sections: Location Counter. (line 36)
-* dot outside sections: Location Counter. (line 66)
-* dynamic linker, from command line: Options. (line 904)
-* dynamic symbol table: Options. (line 221)
-* ELF program headers: PHDRS. (line 6)
-* emulation: Options. (line 392)
-* emulation, default: Environment. (line 21)
-* END (MRI): MRI. (line 62)
-* endianness: Options. (line 248)
-* entry point: Entry Point. (line 6)
-* entry point, from command line: Options. (line 187)
-* entry point, thumb: ARM. (line 17)
-* ENTRY(SYMBOL): Entry Point. (line 6)
-* error on valid input: Bug Criteria. (line 12)
-* example of linker script: Simple Example. (line 6)
-* exporting DLL symbols: WIN32. (line 19)
-* expression evaluation order: Evaluation. (line 6)
-* expression sections: Expression Section. (line 6)
-* expression, absolute: Builtin Functions. (line 10)
-* expressions: Expressions. (line 6)
-* EXTERN: Miscellaneous Commands.
- (line 13)
-* fatal signal: Bug Criteria. (line 9)
-* file name wildcard patterns: Input Section Wildcards.
- (line 6)
-* FILEHDR: PHDRS. (line 62)
-* filename symbols: Output Section Keywords.
- (line 9)
-* fill pattern, entire section: Output Section Fill.
- (line 6)
-* FILL(EXPRESSION): Output Section Data.
- (line 39)
-* finalization function: Options. (line 300)
-* first input file: File Commands. (line 82)
-* first instruction: Entry Point. (line 6)
-* FIX_V4BX: ARM. (line 49)
-* FIX_V4BX_INTERWORKING: ARM. (line 62)
-* FORCE_COMMON_ALLOCATION: Miscellaneous Commands.
- (line 20)
-* forcing input section alignment: Forced Input Alignment.
- (line 6)
-* forcing output section alignment: Forced Output Alignment.
- (line 6)
-* forcing the creation of dynamic sections: Options. (line 485)
-* FORMAT (MRI): MRI. (line 66)
-* functions in expressions: Builtin Functions. (line 6)
-* garbage collection <1>: Input Section Keep. (line 6)
-* garbage collection: Options. (line 948)
-* generating optimized output: Options. (line 466)
-* GNU linker: Overview. (line 6)
-* GNUTARGET: Environment. (line 9)
-* GROUP(FILES): File Commands. (line 47)
-* grouping input files: File Commands. (line 47)
-* groups of archives: Options. (line 696)
-* H8/300 support: H8/300. (line 6)
-* header size: Builtin Functions. (line 182)
-* heap size: Options. (line 1672)
-* help: Options. (line 957)
-* holes: Location Counter. (line 12)
-* holes, filling: Output Section Data.
- (line 39)
-* HPPA multiple sub-space stubs: HPPA ELF32. (line 6)
-* HPPA stub grouping: HPPA ELF32. (line 12)
-* i960 support: i960. (line 6)
-* image base: Options. (line 1679)
-* implicit linker scripts: Implicit Linker Scripts.
- (line 6)
-* import libraries: WIN32. (line 10)
-* INCLUDE FILENAME: File Commands. (line 9)
-* including a linker script: File Commands. (line 9)
-* including an entire archive: Options. (line 1449)
-* incremental link: Options. (line 326)
-* INHIBIT_COMMON_ALLOCATION: Miscellaneous Commands.
- (line 25)
-* initialization function: Options. (line 329)
-* initialized data in ROM: Output Section LMA. (line 39)
-* input file format in linker script: Format Commands. (line 35)
-* input filename symbols: Output Section Keywords.
- (line 9)
-* input files in linker scripts: File Commands. (line 19)
-* input files, displaying: Options. (line 528)
-* input format: Options. (line 134)
-* input object files in linker scripts: File Commands. (line 19)
-* input section alignment: Forced Input Alignment.
- (line 6)
-* input section basics: Input Section Basics.
- (line 6)
-* input section wildcards: Input Section Wildcards.
- (line 6)
-* input sections: Input Section. (line 6)
-* INPUT(FILES): File Commands. (line 19)
-* INSERT: Miscellaneous Commands.
- (line 30)
-* insert user script into default script: Miscellaneous Commands.
- (line 30)
-* integer notation: Constants. (line 6)
-* integer suffixes: Constants. (line 15)
-* internal object-file format: Canonical format. (line 11)
-* invalid input: Bug Criteria. (line 14)
-* K and M integer suffixes: Constants. (line 15)
-* KEEP: Input Section Keep. (line 6)
-* l =: MEMORY. (line 74)
-* lazy evaluation: Evaluation. (line 6)
-* ld bugs, reporting: Bug Reporting. (line 6)
-* LDEMULATION: Environment. (line 21)
-* len =: MEMORY. (line 74)
-* LENGTH =: MEMORY. (line 74)
-* LENGTH(MEMORY): Builtin Functions. (line 136)
-* library search path in linker script: File Commands. (line 74)
-* link map: Options. (line 402)
-* link-time runtime library search path: Options. (line 1151)
-* linker crash: Bug Criteria. (line 9)
-* linker script concepts: Basic Script Concepts.
- (line 6)
-* linker script example: Simple Example. (line 6)
-* linker script file commands: File Commands. (line 6)
-* linker script format: Script Format. (line 6)
-* linker script input object files: File Commands. (line 19)
-* linker script simple commands: Simple Commands. (line 6)
-* linker scripts: Scripts. (line 6)
-* LIST (MRI): MRI. (line 77)
-* little-endian objects: Options. (line 251)
-* LOAD (MRI): MRI. (line 84)
-* load address: Output Section LMA. (line 6)
-* LOADADDR(SECTION): Builtin Functions. (line 139)
-* loading, preventing: Output Section Type.
- (line 22)
-* local symbols, deleting: Options. (line 591)
-* location counter: Location Counter. (line 6)
-* LONG(EXPRESSION): Output Section Data.
- (line 6)
-* M and K integer suffixes: Constants. (line 15)
-* M68HC11 and 68HC12 support: M68HC11/68HC12. (line 6)
-* machine architecture: Miscellaneous Commands.
- (line 72)
-* machine dependencies: Machine Dependent. (line 6)
-* mapping input sections to output sections: Input Section. (line 6)
-* MAX: Builtin Functions. (line 142)
-* MAXPAGESIZE: Symbolic Constants. (line 10)
-* MEMORY: MEMORY. (line 6)
-* memory region attributes: MEMORY. (line 34)
-* memory regions: MEMORY. (line 6)
-* memory regions and sections: Output Section Region.
- (line 6)
-* memory usage: Options. (line 969)
-* MIN: Builtin Functions. (line 145)
-* Motorola 68K GOT generation: M68K. (line 6)
-* MRI compatibility: MRI. (line 6)
-* MSP430 extra sections: MSP430. (line 11)
-* NAME (MRI): MRI. (line 90)
-* name, section: Output Section Name.
- (line 6)
-* names: Symbols. (line 6)
-* naming the output file: Options. (line 460)
-* NEXT(EXP): Builtin Functions. (line 149)
-* NMAGIC: Options. (line 439)
-* NO_ENUM_SIZE_WARNING: ARM. (line 111)
-* NO_WCHAR_SIZE_WARNING: ARM. (line 118)
-* NOCROSSREFS(SECTIONS): Miscellaneous Commands.
- (line 56)
-* NOLOAD: Output Section Type.
- (line 22)
-* not enough room for program headers: Builtin Functions. (line 187)
-* o =: MEMORY. (line 69)
-* objdump -i: BFD. (line 6)
-* object file management: BFD. (line 6)
-* object files: Options. (line 29)
-* object formats available: BFD. (line 6)
-* object size: Options. (line 309)
-* OMAGIC: Options. (line 454)
-* ONLY_IF_RO: Output Section Constraint.
- (line 6)
-* ONLY_IF_RW: Output Section Constraint.
- (line 6)
-* opening object files: BFD outline. (line 6)
-* operators for arithmetic: Operators. (line 6)
-* options: Options. (line 6)
-* ORDER (MRI): MRI. (line 95)
-* org =: MEMORY. (line 69)
-* ORIGIN =: MEMORY. (line 69)
-* ORIGIN(MEMORY): Builtin Functions. (line 155)
-* orphan: Orphan Sections. (line 6)
-* output file after errors: Options. (line 1048)
-* output file format in linker script: Format Commands. (line 10)
-* output file name in linker script: File Commands. (line 64)
-* output section alignment: Forced Output Alignment.
- (line 6)
-* output section attributes: Output Section Attributes.
- (line 6)
-* output section data: Output Section Data.
- (line 6)
-* OUTPUT(FILENAME): File Commands. (line 64)
-* OUTPUT_ARCH(BFDARCH): Miscellaneous Commands.
- (line 72)
-* OUTPUT_FORMAT(BFDNAME): Format Commands. (line 10)
-* OVERLAY: Overlay Description.
- (line 6)
-* overlays: Overlay Description.
- (line 6)
-* partial link: Options. (line 489)
-* PE import table prefixing: ARM. (line 23)
-* PHDRS: PHDRS. (line 62)
-* PIC_VENEER: ARM. (line 124)
-* position independent executables: Options. (line 1075)
-* PowerPC ELF32 options: PowerPC ELF32. (line 16)
-* PowerPC GOT: PowerPC ELF32. (line 33)
-* PowerPC long branches: PowerPC ELF32. (line 6)
-* PowerPC PLT: PowerPC ELF32. (line 16)
-* PowerPC stub symbols: PowerPC ELF32. (line 47)
-* PowerPC TLS optimization: PowerPC ELF32. (line 51)
-* PowerPC64 dot symbols: PowerPC64 ELF64. (line 33)
-* PowerPC64 ELF64 options: PowerPC64 ELF64. (line 6)
-* PowerPC64 multi-TOC: PowerPC64 ELF64. (line 74)
-* PowerPC64 OPD optimization: PowerPC64 ELF64. (line 48)
-* PowerPC64 OPD spacing: PowerPC64 ELF64. (line 54)
-* PowerPC64 stub grouping: PowerPC64 ELF64. (line 6)
-* PowerPC64 stub symbols: PowerPC64 ELF64. (line 29)
-* PowerPC64 TLS optimization: PowerPC64 ELF64. (line 43)
-* PowerPC64 TOC optimization: PowerPC64 ELF64. (line 60)
-* precedence in expressions: Operators. (line 6)
-* prevent unnecessary loading: Output Section Type.
- (line 22)
-* program headers: PHDRS. (line 6)
-* program headers and sections: Output Section Phdr.
- (line 6)
-* program headers, not enough room: Builtin Functions. (line 187)
-* program segments: PHDRS. (line 6)
-* PROVIDE: PROVIDE. (line 6)
-* PROVIDE_HIDDEN: PROVIDE_HIDDEN. (line 6)
-* PUBLIC (MRI): MRI. (line 103)
-* QUAD(EXPRESSION): Output Section Data.
- (line 6)
-* quoted symbol names: Symbols. (line 6)
-* read-only text: Options. (line 439)
-* read/write from cmd line: Options. (line 445)
-* region alias: REGION_ALIAS. (line 6)
-* region names: REGION_ALIAS. (line 6)
-* REGION_ALIAS(ALIAS, REGION): REGION_ALIAS. (line 6)
-* regions of memory: MEMORY. (line 6)
-* relative expressions: Expression Section. (line 6)
-* relaxing addressing modes: Options. (line 1089)
-* relaxing on H8/300: H8/300. (line 9)
-* relaxing on i960: i960. (line 31)
-* relaxing on M68HC11: M68HC11/68HC12. (line 12)
-* relaxing on Xtensa: Xtensa. (line 27)
-* relocatable and absolute symbols: Expression Section. (line 6)
-* relocatable output: Options. (line 489)
-* removing sections: Output Section Discarding.
- (line 6)
-* reporting bugs in ld: Reporting Bugs. (line 6)
-* requirements for BFD: BFD. (line 16)
-* retain relocations in final executable: Options. (line 476)
-* retaining specified symbols: Options. (line 1115)
-* ROM initialized data: Output Section LMA. (line 39)
-* round up expression: Builtin Functions. (line 38)
-* round up location counter: Builtin Functions. (line 38)
-* runtime library name: Options. (line 317)
-* runtime library search path: Options. (line 1129)
-* runtime pseudo-relocation: WIN32. (line 217)
-* scaled integers: Constants. (line 15)
-* scommon section: Input Section Common.
- (line 20)
-* script files: Options. (line 532)
-* scripts: Scripts. (line 6)
-* search directory, from cmd line: Options. (line 368)
-* search path in linker script: File Commands. (line 74)
-* SEARCH_DIR(PATH): File Commands. (line 74)
-* SECT (MRI): MRI. (line 109)
-* section address: Output Section Address.
- (line 6)
-* section address in expression: Builtin Functions. (line 17)
-* section alignment: Builtin Functions. (line 63)
-* section alignment, warnings on: Options. (line 1427)
-* section data: Output Section Data.
- (line 6)
-* section fill pattern: Output Section Fill.
- (line 6)
-* section load address: Output Section LMA. (line 6)
-* section load address in expression: Builtin Functions. (line 139)
-* section name: Output Section Name.
- (line 6)
-* section name wildcard patterns: Input Section Wildcards.
- (line 6)
-* section size: Builtin Functions. (line 166)
-* section, assigning to memory region: Output Section Region.
- (line 6)
-* section, assigning to program header: Output Section Phdr.
- (line 6)
-* SECTIONS: SECTIONS. (line 6)
-* sections, discarding: Output Section Discarding.
- (line 6)
-* segment origins, cmd line: Options. (line 1280)
-* SEGMENT_START(SEGMENT, DEFAULT): Builtin Functions. (line 158)
-* segments, ELF: PHDRS. (line 6)
-* shared libraries: Options. (line 1208)
-* SHORT(EXPRESSION): Output Section Data.
- (line 6)
-* SIZEOF(SECTION): Builtin Functions. (line 166)
-* SIZEOF_HEADERS: Builtin Functions. (line 182)
-* small common symbols: Input Section Common.
- (line 20)
-* SORT: Input Section Wildcards.
- (line 58)
-* SORT_BY_ALIGNMENT: Input Section Wildcards.
- (line 54)
-* SORT_BY_NAME: Input Section Wildcards.
- (line 46)
-* SPU: SPU ELF. (line 46)
-* SPU ELF options: SPU ELF. (line 6)
-* SPU extra overlay stubs: SPU ELF. (line 19)
-* SPU local store size: SPU ELF. (line 24)
-* SPU overlay stub symbols: SPU ELF. (line 15)
-* SPU overlays: SPU ELF. (line 9)
-* SPU plugins: SPU ELF. (line 6)
-* SQUAD(EXPRESSION): Output Section Data.
- (line 6)
-* stack size: Options. (line 1919)
-* standard Unix system: Options. (line 7)
-* start of execution: Entry Point. (line 6)
-* STARTUP(FILENAME): File Commands. (line 82)
-* strip all symbols: Options. (line 519)
-* strip debugger symbols: Options. (line 523)
-* stripping all but some symbols: Options. (line 1115)
-* STUB_GROUP_SIZE: ARM. (line 129)
-* SUBALIGN(SUBSECTION_ALIGN): Forced Input Alignment.
- (line 6)
-* suffixes for integers: Constants. (line 15)
-* symbol defaults: Builtin Functions. (line 119)
-* symbol definition, scripts: Assignments. (line 6)
-* symbol names: Symbols. (line 6)
-* symbol tracing: Options. (line 597)
-* symbol versions: VERSION. (line 6)
-* symbol-only input: Options. (line 508)
-* symbolic constants: Symbolic Constants. (line 6)
-* symbols, from command line: Options. (line 878)
-* symbols, relocatable and absolute: Expression Section. (line 6)
-* symbols, retaining selectively: Options. (line 1115)
-* synthesizing linker: Options. (line 1089)
-* synthesizing on H8/300: H8/300. (line 14)
-* TARGET(BFDNAME): Format Commands. (line 35)
-* TARGET1: ARM. (line 32)
-* TARGET2: ARM. (line 37)
-* text segment origin, cmd line: Options. (line 1287)
-* thumb entry point: ARM. (line 17)
-* TI COFF versions: TI COFF. (line 6)
-* traditional format: Options. (line 1259)
-* trampoline generation on M68HC11: M68HC11/68HC12. (line 31)
-* trampoline generation on M68HC12: M68HC11/68HC12. (line 31)
-* unallocated address, next: Builtin Functions. (line 149)
-* undefined symbol: Options. (line 554)
-* undefined symbol in linker script: Miscellaneous Commands.
- (line 13)
-* undefined symbols, warnings on: Options. (line 1423)
-* uninitialized data placement: Input Section Common.
- (line 6)
-* unspecified memory: Output Section Data.
- (line 39)
-* usage: Options. (line 957)
-* USE_BLX: ARM. (line 74)
-* using a DEF file: WIN32. (line 57)
-* using auto-export functionality: WIN32. (line 22)
-* Using decorations: WIN32. (line 162)
-* variables, defining: Assignments. (line 6)
-* verbose: Options. (line 1319)
-* version: Options. (line 581)
-* version script: VERSION. (line 6)
-* version script, symbol versions: Options. (line 1325)
-* VERSION {script text}: VERSION. (line 6)
-* versions of symbols: VERSION. (line 6)
-* VFP11_DENORM_FIX: ARM. (line 83)
-* warnings, on combining symbols: Options. (line 1336)
-* warnings, on section alignment: Options. (line 1427)
-* warnings, on undefined symbols: Options. (line 1423)
-* weak externals: WIN32. (line 407)
-* what is this?: Overview. (line 6)
-* wildcard file name patterns: Input Section Wildcards.
- (line 6)
-* Xtensa options: Xtensa. (line 56)
-* Xtensa processors: Xtensa. (line 6)
-
-
-
-Tag Table:
-Node: Top891
-Node: Overview1674
-Node: Invocation2788
-Node: Options3196
-Node: Environment93412
-Node: Scripts95172
-Node: Basic Script Concepts96906
-Node: Script Format99613
-Node: Simple Example100476
-Node: Simple Commands103572
-Node: Entry Point104078
-Node: File Commands105011
-Node: Format Commands109012
-Node: REGION_ALIAS110968
-Node: Miscellaneous Commands115800
-Node: Assignments119176
-Node: Simple Assignments119667
-Node: PROVIDE121403
-Node: PROVIDE_HIDDEN122608
-Node: Source Code Reference122852
-Node: SECTIONS126432
-Node: Output Section Description128323
-Node: Output Section Name129410
-Node: Output Section Address130286
-Node: Input Section132521
-Node: Input Section Basics133322
-Node: Input Section Wildcards136540
-Node: Input Section Common141273
-Node: Input Section Keep142755
-Node: Input Section Example143245
-Node: Output Section Data144213
-Node: Output Section Keywords146990
-Node: Output Section Discarding150559
-Node: Output Section Attributes151740
-Node: Output Section Type152841
-Node: Output Section LMA153912
-Node: Forced Output Alignment156983
-Node: Forced Input Alignment157251
-Node: Output Section Constraint157640
-Node: Output Section Region158068
-Node: Output Section Phdr158501
-Node: Output Section Fill159165
-Node: Overlay Description160307
-Node: MEMORY164609
-Node: PHDRS168943
-Node: VERSION174197
-Node: Expressions182290
-Node: Constants183219
-Node: Symbolic Constants184094
-Node: Symbols184645
-Node: Orphan Sections185392
-Node: Location Counter186556
-Node: Operators190992
-Node: Evaluation191914
-Node: Expression Section193278
-Node: Builtin Functions196879
-Node: Implicit Linker Scripts204835
-Node: Machine Dependent205610
-Node: H8/300206626
-Node: i960208251
-Node: M68HC11/68HC12210455
-Node: ARM211909
-Node: HPPA ELF32219421
-Node: M68K221044
-Node: MMIX221953
-Node: MSP430223118
-Node: PowerPC ELF32224167
-Node: PowerPC64 ELF64227003
-Node: SPU ELF231419
-Node: TI COFF234051
-Node: WIN32234577
-Node: Xtensa254702
-Node: BFD257667
-Node: BFD outline259122
-Node: BFD information loss260408
-Node: Canonical format262925
-Node: Reporting Bugs267282
-Node: Bug Criteria267976
-Node: Bug Reporting268675
-Node: MRI275714
-Node: GNU Free Documentation License280357
-Node: LD Index305513
-
-End Tag Table
diff --git a/share/info/stabs.info b/share/info/stabs.info
deleted file mode 100644
index ca91d22..0000000
--- a/share/info/stabs.info
+++ /dev/null
@@ -1,4590 +0,0 @@
-This is stabs.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gdb/gdb-7.3.x/gdb/doc/stabs.texinfo.
-
-INFO-DIR-SECTION Software development
-START-INFO-DIR-ENTRY
-* Stabs: (stabs). The "stabs" debugging information format.
-END-INFO-DIR-ENTRY
-
- Copyright (C) 1992, 1993, 1994, 1995, 1997, 1998, 2000, 2001, 2002,
-2003, 2004, 2005, 2006, 2007, 2009, 2010, 2011 Free Software
-Foundation, Inc. Contributed by Cygnus Support. Written by Julia
-Menapace, Jim Kingdon, and David MacKenzie.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
- This document describes the stabs debugging symbol tables.
-
- Copyright (C) 1992, 1993, 1994, 1995, 1997, 1998, 2000, 2001, 2002,
-2003, 2004, 2005, 2006, 2007, 2009, 2010, 2011 Free Software
-Foundation, Inc. Contributed by Cygnus Support. Written by Julia
-Menapace, Jim Kingdon, and David MacKenzie.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
-
-File: stabs.info, Node: Top, Next: Overview, Up: (dir)
-
-The "stabs" representation of debugging information
-***************************************************
-
-This document describes the stabs debugging format.
-
-* Menu:
-
-* Overview:: Overview of stabs
-* Program Structure:: Encoding of the structure of the program
-* Constants:: Constants
-* Variables::
-* Types:: Type definitions
-* Macro define and undefine:: Representation of #define and #undef
-* Symbol Tables:: Symbol information in symbol tables
-* Cplusplus:: Stabs specific to C++
-* Stab Types:: Symbol types in a.out files
-* Symbol Descriptors:: Table of symbol descriptors
-* Type Descriptors:: Table of type descriptors
-* Expanded Reference:: Reference information by stab type
-* Questions:: Questions and anomalies
-* Stab Sections:: In some object file formats, stabs are
- in sections.
-* Symbol Types Index:: Index of symbolic stab symbol type names.
-* GNU Free Documentation License:: The license for this documentation
-
-
-File: stabs.info, Node: Overview, Next: Program Structure, Prev: Top, Up: Top
-
-1 Overview of Stabs
-*******************
-
-"Stabs" refers to a format for information that describes a program to
-a debugger. This format was apparently invented by Peter Kessler at
-the University of California at Berkeley, for the `pdx' Pascal
-debugger; the format has spread widely since then.
-
- This document is one of the few published sources of documentation on
-stabs. It is believed to be comprehensive for stabs used by C. The
-lists of symbol descriptors (*note Symbol Descriptors::) and type
-descriptors (*note Type Descriptors::) are believed to be completely
-comprehensive. Stabs for COBOL-specific features and for variant
-records (used by Pascal and Modula-2) are poorly documented here.
-
- Other sources of information on stabs are `Dbx and Dbxtool
-Interfaces', 2nd edition, by Sun, 1988, and `AIX Version 3.2 Files
-Reference', Fourth Edition, September 1992, "dbx Stabstring Grammar" in
-the a.out section, page 2-31. This document is believed to incorporate
-the information from those two sources except where it explicitly
-directs you to them for more information.
-
-* Menu:
-
-* Flow:: Overview of debugging information flow
-* Stabs Format:: Overview of stab format
-* String Field:: The string field
-* C Example:: A simple example in C source
-* Assembly Code:: The simple example at the assembly level
-
-
-File: stabs.info, Node: Flow, Next: Stabs Format, Up: Overview
-
-1.1 Overview of Debugging Information Flow
-==========================================
-
-The GNU C compiler compiles C source in a `.c' file into assembly
-language in a `.s' file, which the assembler translates into a `.o'
-file, which the linker combines with other `.o' files and libraries to
-produce an executable file.
-
- With the `-g' option, GCC puts in the `.s' file additional debugging
-information, which is slightly transformed by the assembler and linker,
-and carried through into the final executable. This debugging
-information describes features of the source file like line numbers,
-the types and scopes of variables, and function names, parameters, and
-scopes.
-
- For some object file formats, the debugging information is
-encapsulated in assembler directives known collectively as "stab"
-(symbol table) directives, which are interspersed with the generated
-code. Stabs are the native format for debugging information in the
-a.out and XCOFF object file formats. The GNU tools can also emit stabs
-in the COFF and ECOFF object file formats.
-
- The assembler adds the information from stabs to the symbol
-information it places by default in the symbol table and the string
-table of the `.o' file it is building. The linker consolidates the `.o'
-files into one executable file, with one symbol table and one string
-table. Debuggers use the symbol and string tables in the executable as
-a source of debugging information about the program.
-
-
-File: stabs.info, Node: Stabs Format, Next: String Field, Prev: Flow, Up: Overview
-
-1.2 Overview of Stab Format
-===========================
-
-There are three overall formats for stab assembler directives,
-differentiated by the first word of the stab. The name of the directive
-describes which combination of four possible data fields follows. It is
-either `.stabs' (string), `.stabn' (number), or `.stabd' (dot). IBM's
-XCOFF assembler uses `.stabx' (and some other directives such as
-`.file' and `.bi') instead of `.stabs', `.stabn' or `.stabd'.
-
- The overall format of each class of stab is:
-
- .stabs "STRING",TYPE,OTHER,DESC,VALUE
- .stabn TYPE,OTHER,DESC,VALUE
- .stabd TYPE,OTHER,DESC
- .stabx "STRING",VALUE,TYPE,SDB-TYPE
-
- For `.stabn' and `.stabd', there is no STRING (the `n_strx' field is
-zero; see *note Symbol Tables::). For `.stabd', the VALUE field is
-implicit and has the value of the current file location. For `.stabx',
-the SDB-TYPE field is unused for stabs and can always be set to zero.
-The OTHER field is almost always unused and can be set to zero.
-
- The number in the TYPE field gives some basic information about
-which type of stab this is (or whether it _is_ a stab, as opposed to an
-ordinary symbol). Each valid type number defines a different stab
-type; further, the stab type defines the exact interpretation of, and
-possible values for, any remaining STRING, DESC, or VALUE fields
-present in the stab. *Note Stab Types::, for a list in numeric order
-of the valid TYPE field values for stab directives.
-
-
-File: stabs.info, Node: String Field, Next: C Example, Prev: Stabs Format, Up: Overview
-
-1.3 The String Field
-====================
-
-For most stabs the string field holds the meat of the debugging
-information. The flexible nature of this field is what makes stabs
-extensible. For some stab types the string field contains only a name.
-For other stab types the contents can be a great deal more complex.
-
- The overall format of the string field for most stab types is:
-
- "NAME:SYMBOL-DESCRIPTOR TYPE-INFORMATION"
-
- NAME is the name of the symbol represented by the stab; it can
-contain a pair of colons (*note Nested Symbols::). NAME can be
-omitted, which means the stab represents an unnamed object. For
-example, `:t10=*2' defines type 10 as a pointer to type 2, but does not
-give the type a name. Omitting the NAME field is supported by AIX dbx
-and GDB after about version 4.8, but not other debuggers. GCC
-sometimes uses a single space as the name instead of omitting the name
-altogether; apparently that is supported by most debuggers.
-
- The SYMBOL-DESCRIPTOR following the `:' is an alphabetic character
-that tells more specifically what kind of symbol the stab represents.
-If the SYMBOL-DESCRIPTOR is omitted, but type information follows, then
-the stab represents a local variable. For a list of symbol
-descriptors, see *note Symbol Descriptors::. The `c' symbol descriptor
-is an exception in that it is not followed by type information. *Note
-Constants::.
-
- TYPE-INFORMATION is either a TYPE-NUMBER, or `TYPE-NUMBER='. A
-TYPE-NUMBER alone is a type reference, referring directly to a type
-that has already been defined.
-
- The `TYPE-NUMBER=' form is a type definition, where the number
-represents a new type which is about to be defined. The type
-definition may refer to other types by number, and those type numbers
-may be followed by `=' and nested definitions. Also, the Lucid
-compiler will repeat `TYPE-NUMBER=' more than once if it wants to
-define several type numbers at once.
-
- In a type definition, if the character that follows the equals sign
-is non-numeric then it is a TYPE-DESCRIPTOR, and tells what kind of
-type is about to be defined. Any other values following the
-TYPE-DESCRIPTOR vary, depending on the TYPE-DESCRIPTOR. *Note Type
-Descriptors::, for a list of TYPE-DESCRIPTOR values. If a number
-follows the `=' then the number is a TYPE-REFERENCE. For a full
-description of types, *note Types::.
-
- A TYPE-NUMBER is often a single number. The GNU and Sun tools
-additionally permit a TYPE-NUMBER to be a pair
-(FILE-NUMBER,FILETYPE-NUMBER) (the parentheses appear in the string,
-and serve to distinguish the two cases). The FILE-NUMBER is 0 for the
-base source file, 1 for the first included file, 2 for the next, and so
-on. The FILETYPE-NUMBER is a number starting with 1 which is
-incremented for each new type defined in the file. (Separating the
-file number and the type number permits the `N_BINCL' optimization to
-succeed more often; see *note Include Files::).
-
- There is an AIX extension for type attributes. Following the `='
-are any number of type attributes. Each one starts with `@' and ends
-with `;'. Debuggers, including AIX's dbx and GDB 4.10, skip any type
-attributes they do not recognize. GDB 4.9 and other versions of dbx
-may not do this. Because of a conflict with C++ (*note Cplusplus::),
-new attributes should not be defined which begin with a digit, `(', or
-`-'; GDB may be unable to distinguish those from the C++ type
-descriptor `@'. The attributes are:
-
-`aBOUNDARY'
- BOUNDARY is an integer specifying the alignment. I assume it
- applies to all variables of this type.
-
-`pINTEGER'
- Pointer class (for checking). Not sure what this means, or how
- INTEGER is interpreted.
-
-`P'
- Indicate this is a packed type, meaning that structure fields or
- array elements are placed more closely in memory, to save memory
- at the expense of speed.
-
-`sSIZE'
- Size in bits of a variable of this type. This is fully supported
- by GDB 4.11 and later.
-
-`S'
- Indicate that this type is a string instead of an array of
- characters, or a bitstring instead of a set. It doesn't change
- the layout of the data being represented, but does enable the
- debugger to know which type it is.
-
-`V'
- Indicate that this type is a vector instead of an array. The only
- major difference between vectors and arrays is that vectors are
- passed by value instead of by reference (vector coprocessor
- extension).
-
-
- All of this can make the string field quite long. All versions of
-GDB, and some versions of dbx, can handle arbitrarily long strings.
-But many versions of dbx (or assemblers or linkers, I'm not sure which)
-cretinously limit the strings to about 80 characters, so compilers which
-must work with such systems need to split the `.stabs' directive into
-several `.stabs' directives. Each stab duplicates every field except
-the string field. The string field of every stab except the last is
-marked as continued with a backslash at the end (in the assembly code
-this may be written as a double backslash, depending on the assembler).
-Removing the backslashes and concatenating the string fields of each
-stab produces the original, long string. Just to be incompatible (or so
-they don't have to worry about what the assembler does with
-backslashes), AIX can use `?' instead of backslash.
-
-
-File: stabs.info, Node: C Example, Next: Assembly Code, Prev: String Field, Up: Overview
-
-1.4 A Simple Example in C Source
-================================
-
-To get the flavor of how stabs describe source information for a C
-program, let's look at the simple program:
-
- main()
- {
- printf("Hello world");
- }
-
- When compiled with `-g', the program above yields the following `.s'
-file. Line numbers have been added to make it easier to refer to parts
-of the `.s' file in the description of the stabs that follows.
-
-
-File: stabs.info, Node: Assembly Code, Prev: C Example, Up: Overview
-
-1.5 The Simple Example at the Assembly Level
-============================================
-
-This simple "hello world" example demonstrates several of the stab
-types used to describe C language source files.
-
- 1 gcc2_compiled.:
- 2 .stabs "/cygint/s1/users/jcm/play/",100,0,0,Ltext0
- 3 .stabs "hello.c",100,0,0,Ltext0
- 4 .text
- 5 Ltext0:
- 6 .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0
- 7 .stabs "char:t2=r2;0;127;",128,0,0,0
- 8 .stabs "long int:t3=r1;-2147483648;2147483647;",128,0,0,0
- 9 .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0
- 10 .stabs "long unsigned int:t5=r1;0;-1;",128,0,0,0
- 11 .stabs "short int:t6=r1;-32768;32767;",128,0,0,0
- 12 .stabs "long long int:t7=r1;0;-1;",128,0,0,0
- 13 .stabs "short unsigned int:t8=r1;0;65535;",128,0,0,0
- 14 .stabs "long long unsigned int:t9=r1;0;-1;",128,0,0,0
- 15 .stabs "signed char:t10=r1;-128;127;",128,0,0,0
- 16 .stabs "unsigned char:t11=r1;0;255;",128,0,0,0
- 17 .stabs "float:t12=r1;4;0;",128,0,0,0
- 18 .stabs "double:t13=r1;8;0;",128,0,0,0
- 19 .stabs "long double:t14=r1;8;0;",128,0,0,0
- 20 .stabs "void:t15=15",128,0,0,0
- 21 .align 4
- 22 LC0:
- 23 .ascii "Hello, world!\12\0"
- 24 .align 4
- 25 .global _main
- 26 .proc 1
- 27 _main:
- 28 .stabn 68,0,4,LM1
- 29 LM1:
- 30 !#PROLOGUE# 0
- 31 save %sp,-136,%sp
- 32 !#PROLOGUE# 1
- 33 call ___main,0
- 34 nop
- 35 .stabn 68,0,5,LM2
- 36 LM2:
- 37 LBB2:
- 38 sethi %hi(LC0),%o1
- 39 or %o1,%lo(LC0),%o0
- 40 call _printf,0
- 41 nop
- 42 .stabn 68,0,6,LM3
- 43 LM3:
- 44 LBE2:
- 45 .stabn 68,0,6,LM4
- 46 LM4:
- 47 L1:
- 48 ret
- 49 restore
- 50 .stabs "main:F1",36,0,0,_main
- 51 .stabn 192,0,0,LBB2
- 52 .stabn 224,0,0,LBE2
-
-
-File: stabs.info, Node: Program Structure, Next: Constants, Prev: Overview, Up: Top
-
-2 Encoding the Structure of the Program
-***************************************
-
-The elements of the program structure that stabs encode include the name
-of the main function, the names of the source and include files, the
-line numbers, procedure names and types, and the beginnings and ends of
-blocks of code.
-
-* Menu:
-
-* Main Program:: Indicate what the main program is
-* Source Files:: The path and name of the source file
-* Include Files:: Names of include files
-* Line Numbers::
-* Procedures::
-* Nested Procedures::
-* Block Structure::
-* Alternate Entry Points:: Entering procedures except at the beginning.
-
-
-File: stabs.info, Node: Main Program, Next: Source Files, Up: Program Structure
-
-2.1 Main Program
-================
-
-Most languages allow the main program to have any name. The `N_MAIN'
-stab type tells the debugger the name that is used in this program.
-Only the string field is significant; it is the name of a function
-which is the main program. Most C compilers do not use this stab (they
-expect the debugger to assume that the name is `main'), but some C
-compilers emit an `N_MAIN' stab for the `main' function. I'm not sure
-how XCOFF handles this.
-
-
-File: stabs.info, Node: Source Files, Next: Include Files, Prev: Main Program, Up: Program Structure
-
-2.2 Paths and Names of the Source Files
-=======================================
-
-Before any other stabs occur, there must be a stab specifying the source
-file. This information is contained in a symbol of stab type `N_SO';
-the string field contains the name of the file. The value of the
-symbol is the start address of the portion of the text section
-corresponding to that file.
-
- Some compilers use the desc field to indicate the language of the
-source file. Sun's compilers started this usage, and the first
-constants are derived from their documentation. Languages added by
-gcc/gdb start at 0x32 to avoid conflict with languages Sun may add in
-the future. A desc field with a value 0 indicates that no language has
-been specified via this mechanism.
-
-`N_SO_AS' (0x1)
- Assembly language
-
-`N_SO_C' (0x2)
- K&R traditional C
-
-`N_SO_ANSI_C' (0x3)
- ANSI C
-
-`N_SO_CC' (0x4)
- C++
-
-`N_SO_FORTRAN' (0x5)
- Fortran
-
-`N_SO_PASCAL' (0x6)
- Pascal
-
-`N_SO_FORTRAN90' (0x7)
- Fortran90
-
-`N_SO_OBJC' (0x32)
- Objective-C
-
-`N_SO_OBJCPLUS' (0x33)
- Objective-C++
-
- Some compilers (for example, GCC2 and SunOS4 `/bin/cc') also include
-the directory in which the source was compiled, in a second `N_SO'
-symbol preceding the one containing the file name. This symbol can be
-distinguished by the fact that it ends in a slash. Code from the
-`cfront' C++ compiler can have additional `N_SO' symbols for
-nonexistent source files after the `N_SO' for the real source file;
-these are believed to contain no useful information.
-
- For example:
-
- .stabs "/cygint/s1/users/jcm/play/",100,0,0,Ltext0 # 100 is N_SO
- .stabs "hello.c",100,0,0,Ltext0
- .text
- Ltext0:
-
- Instead of `N_SO' symbols, XCOFF uses a `.file' assembler directive
-which assembles to a `C_FILE' symbol; explaining this in detail is
-outside the scope of this document.
-
- If it is useful to indicate the end of a source file, this is done
-with an `N_SO' symbol with an empty string for the name. The value is
-the address of the end of the text section for the file. For some
-systems, there is no indication of the end of a source file, and you
-just need to figure it ended when you see an `N_SO' for a different
-source file, or a symbol ending in `.o' (which at least some linkers
-insert to mark the start of a new `.o' file).
-
-
-File: stabs.info, Node: Include Files, Next: Line Numbers, Prev: Source Files, Up: Program Structure
-
-2.3 Names of Include Files
-==========================
-
-There are several schemes for dealing with include files: the
-traditional `N_SOL' approach, Sun's `N_BINCL' approach, and the XCOFF
-`C_BINCL' approach (which despite the similar name has little in common
-with `N_BINCL').
-
- An `N_SOL' symbol specifies which include file subsequent symbols
-refer to. The string field is the name of the file and the value is the
-text address corresponding to the end of the previous include file and
-the start of this one. To specify the main source file again, use an
-`N_SOL' symbol with the name of the main source file.
-
- The `N_BINCL' approach works as follows. An `N_BINCL' symbol
-specifies the start of an include file. In an object file, only the
-string is significant; the linker puts data into some of the other
-fields. The end of the include file is marked by an `N_EINCL' symbol
-(which has no string field). In an object file, there is no
-significant data in the `N_EINCL' symbol. `N_BINCL' and `N_EINCL' can
-be nested.
-
- If the linker detects that two source files have identical stabs
-between an `N_BINCL' and `N_EINCL' pair (as will generally be the case
-for a header file), then it only puts out the stabs once. Each
-additional occurrence is replaced by an `N_EXCL' symbol. I believe the
-GNU linker and the Sun (both SunOS4 and Solaris) linker are the only
-ones which supports this feature.
-
- A linker which supports this feature will set the value of a
-`N_BINCL' symbol to the total of all the characters in the stabs
-strings included in the header file, omitting any file numbers. The
-value of an `N_EXCL' symbol is the same as the value of the `N_BINCL'
-symbol it replaces. This information can be used to match up `N_EXCL'
-and `N_BINCL' symbols which have the same filename. The `N_EINCL'
-value, and the values of the other and description fields for all
-three, appear to always be zero.
-
- For the start of an include file in XCOFF, use the `.bi' assembler
-directive, which generates a `C_BINCL' symbol. A `.ei' directive,
-which generates a `C_EINCL' symbol, denotes the end of the include
-file. Both directives are followed by the name of the source file in
-quotes, which becomes the string for the symbol. The value of each
-symbol, produced automatically by the assembler and linker, is the
-offset into the executable of the beginning (inclusive, as you'd
-expect) or end (inclusive, as you would not expect) of the portion of
-the COFF line table that corresponds to this include file. `C_BINCL'
-and `C_EINCL' do not nest.
-
-
-File: stabs.info, Node: Line Numbers, Next: Procedures, Prev: Include Files, Up: Program Structure
-
-2.4 Line Numbers
-================
-
-An `N_SLINE' symbol represents the start of a source line. The desc
-field contains the line number and the value contains the code address
-for the start of that source line. On most machines the address is
-absolute; for stabs in sections (*note Stab Sections::), it is relative
-to the function in which the `N_SLINE' symbol occurs.
-
- GNU documents `N_DSLINE' and `N_BSLINE' symbols for line numbers in
-the data or bss segments, respectively. They are identical to
-`N_SLINE' but are relocated differently by the linker. They were
-intended to be used to describe the source location of a variable
-declaration, but I believe that GCC2 actually puts the line number in
-the desc field of the stab for the variable itself. GDB has been
-ignoring these symbols (unless they contain a string field) since at
-least GDB 3.5.
-
- For single source lines that generate discontiguous code, such as
-flow of control statements, there may be more than one line number
-entry for the same source line. In this case there is a line number
-entry at the start of each code range, each with the same line number.
-
- XCOFF does not use stabs for line numbers. Instead, it uses COFF
-line numbers (which are outside the scope of this document). Standard
-COFF line numbers cannot deal with include files, but in XCOFF this is
-fixed with the `C_BINCL' method of marking include files (*note Include
-Files::).
-
-
-File: stabs.info, Node: Procedures, Next: Nested Procedures, Prev: Line Numbers, Up: Program Structure
-
-2.5 Procedures
-==============
-
-All of the following stabs normally use the `N_FUN' symbol type.
-However, Sun's `acc' compiler on SunOS4 uses `N_GSYM' and `N_STSYM',
-which means that the value of the stab for the function is useless and
-the debugger must get the address of the function from the non-stab
-symbols instead. On systems where non-stab symbols have leading
-underscores, the stabs will lack underscores and the debugger needs to
-know about the leading underscore to match up the stab and the non-stab
-symbol. BSD Fortran is said to use `N_FNAME' with the same
-restriction; the value of the symbol is not useful (I'm not sure it
-really does use this, because GDB doesn't handle this and no one has
-complained).
-
- A function is represented by an `F' symbol descriptor for a global
-(extern) function, and `f' for a static (local) function. For a.out,
-the value of the symbol is the address of the start of the function; it
-is already relocated. For stabs in ELF, the SunPRO compiler version
-2.0.1 and GCC put out an address which gets relocated by the linker.
-In a future release SunPRO is planning to put out zero, in which case
-the address can be found from the ELF (non-stab) symbol. Because
-looking things up in the ELF symbols would probably be slow, I'm not
-sure how to find which symbol of that name is the right one, and this
-doesn't provide any way to deal with nested functions, it would
-probably be better to make the value of the stab an address relative to
-the start of the file, or just absolute. See *note ELF Linker
-Relocation:: for more information on linker relocation of stabs in ELF
-files. For XCOFF, the stab uses the `C_FUN' storage class and the
-value of the stab is meaningless; the address of the function can be
-found from the csect symbol (XTY_LD/XMC_PR).
-
- The type information of the stab represents the return type of the
-function; thus `foo:f5' means that foo is a function returning type 5.
-There is no need to try to get the line number of the start of the
-function from the stab for the function; it is in the next `N_SLINE'
-symbol.
-
- Some compilers (such as Sun's Solaris compiler) support an extension
-for specifying the types of the arguments. I suspect this extension is
-not used for old (non-prototyped) function definitions in C. If the
-extension is in use, the type information of the stab for the function
-is followed by type information for each argument, with each argument
-preceded by `;'. An argument type of 0 means that additional arguments
-are being passed, whose types and number may vary (`...' in ANSI C).
-GDB has tolerated this extension (parsed the syntax, if not necessarily
-used the information) since at least version 4.8; I don't know whether
-all versions of dbx tolerate it. The argument types given here are not
-redundant with the symbols for the formal parameters (*note
-Parameters::); they are the types of the arguments as they are passed,
-before any conversions might take place. For example, if a C function
-which is declared without a prototype takes a `float' argument, the
-value is passed as a `double' but then converted to a `float'.
-Debuggers need to use the types given in the arguments when printing
-values, but when calling the function they need to use the types given
-in the symbol defining the function.
-
- If the return type and types of arguments of a function which is
-defined in another source file are specified (i.e., a function
-prototype in ANSI C), traditionally compilers emit no stab; the only
-way for the debugger to find the information is if the source file
-where the function is defined was also compiled with debugging symbols.
-As an extension the Solaris compiler uses symbol descriptor `P'
-followed by the return type of the function, followed by the arguments,
-each preceded by `;', as in a stab with symbol descriptor `f' or `F'.
-This use of symbol descriptor `P' can be distinguished from its use for
-register parameters (*note Register Parameters::) by the fact that it
-has symbol type `N_FUN'.
-
- The AIX documentation also defines symbol descriptor `J' as an
-internal function. I assume this means a function nested within another
-function. It also says symbol descriptor `m' is a module in Modula-2
-or extended Pascal.
-
- Procedures (functions which do not return values) are represented as
-functions returning the `void' type in C. I don't see why this couldn't
-be used for all languages (inventing a `void' type for this purpose if
-necessary), but the AIX documentation defines `I', `P', and `Q' for
-internal, global, and static procedures, respectively. These symbol
-descriptors are unusual in that they are not followed by type
-information.
-
- The following example shows a stab for a function `main' which
-returns type number `1'. The `_main' specified for the value is a
-reference to an assembler label which is used to fill in the start
-address of the function.
-
- .stabs "main:F1",36,0,0,_main # 36 is N_FUN
-
- The stab representing a procedure is located immediately following
-the code of the procedure. This stab is in turn directly followed by a
-group of other stabs describing elements of the procedure. These other
-stabs describe the procedure's parameters, its block local variables,
-and its block structure.
-
- If functions can appear in different sections, then the debugger may
-not be able to find the end of a function. Recent versions of GCC will
-mark the end of a function with an `N_FUN' symbol with an empty string
-for the name. The value is the address of the end of the current
-function. Without such a symbol, there is no indication of the address
-of the end of a function, and you must assume that it ended at the
-starting address of the next function or at the end of the text section
-for the program.
-
-
-File: stabs.info, Node: Nested Procedures, Next: Block Structure, Prev: Procedures, Up: Program Structure
-
-2.6 Nested Procedures
-=====================
-
-For any of the symbol descriptors representing procedures, after the
-symbol descriptor and the type information is optionally a scope
-specifier. This consists of a comma, the name of the procedure, another
-comma, and the name of the enclosing procedure. The first name is local
-to the scope specified, and seems to be redundant with the name of the
-symbol (before the `:'). This feature is used by GCC, and presumably
-Pascal, Modula-2, etc., compilers, for nested functions.
-
- If procedures are nested more than one level deep, only the
-immediately containing scope is specified. For example, this code:
-
- int
- foo (int x)
- {
- int bar (int y)
- {
- int baz (int z)
- {
- return x + y + z;
- }
- return baz (x + 2 * y);
- }
- return x + bar (3 * x);
- }
-
-produces the stabs:
-
- .stabs "baz:f1,baz,bar",36,0,0,_baz.15 # 36 is N_FUN
- .stabs "bar:f1,bar,foo",36,0,0,_bar.12
- .stabs "foo:F1",36,0,0,_foo
-
-
-File: stabs.info, Node: Block Structure, Next: Alternate Entry Points, Prev: Nested Procedures, Up: Program Structure
-
-2.7 Block Structure
-===================
-
-The program's block structure is represented by the `N_LBRAC' (left
-brace) and the `N_RBRAC' (right brace) stab types. The variables
-defined inside a block precede the `N_LBRAC' symbol for most compilers,
-including GCC. Other compilers, such as the Convex, Acorn RISC
-machine, and Sun `acc' compilers, put the variables after the `N_LBRAC'
-symbol. The values of the `N_LBRAC' and `N_RBRAC' symbols are the
-start and end addresses of the code of the block, respectively. For
-most machines, they are relative to the starting address of this source
-file. For the Gould NP1, they are absolute. For stabs in sections
-(*note Stab Sections::), they are relative to the function in which
-they occur.
-
- The `N_LBRAC' and `N_RBRAC' stabs that describe the block scope of a
-procedure are located after the `N_FUN' stab that represents the
-procedure itself.
-
- Sun documents the desc field of `N_LBRAC' and `N_RBRAC' symbols as
-containing the nesting level of the block. However, dbx seems to not
-care, and GCC always sets desc to zero.
-
- For XCOFF, block scope is indicated with `C_BLOCK' symbols. If the
-name of the symbol is `.bb', then it is the beginning of the block; if
-the name of the symbol is `.be'; it is the end of the block.
-
-
-File: stabs.info, Node: Alternate Entry Points, Prev: Block Structure, Up: Program Structure
-
-2.8 Alternate Entry Points
-==========================
-
-Some languages, like Fortran, have the ability to enter procedures at
-some place other than the beginning. One can declare an alternate entry
-point. The `N_ENTRY' stab is for this; however, the Sun FORTRAN
-compiler doesn't use it. According to AIX documentation, only the name
-of a `C_ENTRY' stab is significant; the address of the alternate entry
-point comes from the corresponding external symbol. A previous
-revision of this document said that the value of an `N_ENTRY' stab was
-the address of the alternate entry point, but I don't know the source
-for that information.
-
-
-File: stabs.info, Node: Constants, Next: Variables, Prev: Program Structure, Up: Top
-
-3 Constants
-***********
-
-The `c' symbol descriptor indicates that this stab represents a
-constant. This symbol descriptor is an exception to the general rule
-that symbol descriptors are followed by type information. Instead, it
-is followed by `=' and one of the following:
-
-`b VALUE'
- Boolean constant. VALUE is a numeric value; I assume it is 0 for
- false or 1 for true.
-
-`c VALUE'
- Character constant. VALUE is the numeric value of the constant.
-
-`e TYPE-INFORMATION , VALUE'
- Constant whose value can be represented as integral.
- TYPE-INFORMATION is the type of the constant, as it would appear
- after a symbol descriptor (*note String Field::). VALUE is the
- numeric value of the constant. GDB 4.9 does not actually get the
- right value if VALUE does not fit in a host `int', but it does not
- do anything violent, and future debuggers could be extended to
- accept integers of any size (whether unsigned or not). This
- constant type is usually documented as being only for enumeration
- constants, but GDB has never imposed that restriction; I don't
- know about other debuggers.
-
-`i VALUE'
- Integer constant. VALUE is the numeric value. The type is some
- sort of generic integer type (for GDB, a host `int'); to specify
- the type explicitly, use `e' instead.
-
-`r VALUE'
- Real constant. VALUE is the real value, which can be `INF'
- (optionally preceded by a sign) for infinity, `QNAN' for a quiet
- NaN (not-a-number), or `SNAN' for a signalling NaN. If it is a
- normal number the format is that accepted by the C library function
- `atof'.
-
-`s STRING'
- String constant. STRING is a string enclosed in either `'' (in
- which case `'' characters within the string are represented as
- `\'' or `"' (in which case `"' characters within the string are
- represented as `\"').
-
-`S TYPE-INFORMATION , ELEMENTS , BITS , PATTERN'
- Set constant. TYPE-INFORMATION is the type of the constant, as it
- would appear after a symbol descriptor (*note String Field::).
- ELEMENTS is the number of elements in the set (does this means how
- many bits of PATTERN are actually used, which would be redundant
- with the type, or perhaps the number of bits set in PATTERN? I
- don't get it), BITS is the number of bits in the constant (meaning
- it specifies the length of PATTERN, I think), and PATTERN is a
- hexadecimal representation of the set. AIX documentation refers
- to a limit of 32 bytes, but I see no reason why this limit should
- exist. This form could probably be used for arbitrary constants,
- not just sets; the only catch is that PATTERN should be understood
- to be target, not host, byte order and format.
-
- The boolean, character, string, and set constants are not supported
-by GDB 4.9, but it ignores them. GDB 4.8 and earlier gave an error
-message and refused to read symbols from the file containing the
-constants.
-
- The above information is followed by `;'.
-
-
-File: stabs.info, Node: Variables, Next: Types, Prev: Constants, Up: Top
-
-4 Variables
-***********
-
-Different types of stabs describe the various ways that variables can be
-allocated: on the stack, globally, in registers, in common blocks,
-statically, or as arguments to a function.
-
-* Menu:
-
-* Stack Variables:: Variables allocated on the stack.
-* Global Variables:: Variables used by more than one source file.
-* Register Variables:: Variables in registers.
-* Common Blocks:: Variables statically allocated together.
-* Statics:: Variables local to one source file.
-* Based Variables:: Fortran pointer based variables.
-* Parameters:: Variables for arguments to functions.
-
-
-File: stabs.info, Node: Stack Variables, Next: Global Variables, Up: Variables
-
-4.1 Automatic Variables Allocated on the Stack
-==============================================
-
-If a variable's scope is local to a function and its lifetime is only as
-long as that function executes (C calls such variables "automatic"), it
-can be allocated in a register (*note Register Variables::) or on the
-stack.
-
- Each variable allocated on the stack has a stab with the symbol
-descriptor omitted. Since type information should begin with a digit,
-`-', or `(', only those characters precluded from being used for symbol
-descriptors. However, the Acorn RISC machine (ARM) is said to get this
-wrong: it puts out a mere type definition here, without the preceding
-`TYPE-NUMBER='. This is a bad idea; there is no guarantee that type
-descriptors are distinct from symbol descriptors. Stabs for stack
-variables use the `N_LSYM' stab type, or `C_LSYM' for XCOFF.
-
- The value of the stab is the offset of the variable within the local
-variables. On most machines this is an offset from the frame pointer
-and is negative. The location of the stab specifies which block it is
-defined in; see *note Block Structure::.
-
- For example, the following C code:
-
- int
- main ()
- {
- int x;
- }
-
- produces the following stabs:
-
- .stabs "main:F1",36,0,0,_main # 36 is N_FUN
- .stabs "x:1",128,0,0,-12 # 128 is N_LSYM
- .stabn 192,0,0,LBB2 # 192 is N_LBRAC
- .stabn 224,0,0,LBE2 # 224 is N_RBRAC
-
- See *note Procedures:: for more information on the `N_FUN' stab, and
-*note Block Structure:: for more information on the `N_LBRAC' and
-`N_RBRAC' stabs.
-
-
-File: stabs.info, Node: Global Variables, Next: Register Variables, Prev: Stack Variables, Up: Variables
-
-4.2 Global Variables
-====================
-
-A variable whose scope is not specific to just one source file is
-represented by the `G' symbol descriptor. These stabs use the `N_GSYM'
-stab type (C_GSYM for XCOFF). The type information for the stab (*note
-String Field::) gives the type of the variable.
-
- For example, the following source code:
-
- char g_foo = 'c';
-
-yields the following assembly code:
-
- .stabs "g_foo:G2",32,0,0,0 # 32 is N_GSYM
- .global _g_foo
- .data
- _g_foo:
- .byte 99
-
- The address of the variable represented by the `N_GSYM' is not
-contained in the `N_GSYM' stab. The debugger gets this information
-from the external symbol for the global variable. In the example above,
-the `.global _g_foo' and `_g_foo:' lines tell the assembler to produce
-an external symbol.
-
- Some compilers, like GCC, output `N_GSYM' stabs only once, where the
-variable is defined. Other compilers, like SunOS4 /bin/cc, output a
-`N_GSYM' stab for each compilation unit which references the variable.
-
-
-File: stabs.info, Node: Register Variables, Next: Common Blocks, Prev: Global Variables, Up: Variables
-
-4.3 Register Variables
-======================
-
-Register variables have their own stab type, `N_RSYM' (`C_RSYM' for
-XCOFF), and their own symbol descriptor, `r'. The stab's value is the
-number of the register where the variable data will be stored.
-
- AIX defines a separate symbol descriptor `d' for floating point
-registers. This seems unnecessary; why not just just give floating
-point registers different register numbers? I have not verified whether
-the compiler actually uses `d'.
-
- If the register is explicitly allocated to a global variable, but not
-initialized, as in:
-
- register int g_bar asm ("%g5");
-
-then the stab may be emitted at the end of the object file, with the
-other bss symbols.
-
-
-File: stabs.info, Node: Common Blocks, Next: Statics, Prev: Register Variables, Up: Variables
-
-4.4 Common Blocks
-=================
-
-A common block is a statically allocated section of memory which can be
-referred to by several source files. It may contain several variables.
-I believe Fortran is the only language with this feature.
-
- A `N_BCOMM' stab begins a common block and an `N_ECOMM' stab ends
-it. The only field that is significant in these two stabs is the
-string, which names a normal (non-debugging) symbol that gives the
-address of the common block. According to IBM documentation, only the
-`N_BCOMM' has the name of the common block (even though their compiler
-actually puts it both places).
-
- The stabs for the members of the common block are between the
-`N_BCOMM' and the `N_ECOMM'; the value of each stab is the offset
-within the common block of that variable. IBM uses the `C_ECOML' stab
-type, and there is a corresponding `N_ECOML' stab type, but Sun's
-Fortran compiler uses `N_GSYM' instead. The variables within a common
-block use the `V' symbol descriptor (I believe this is true of all
-Fortran variables). Other stabs (at least type declarations using
-`C_DECL') can also be between the `N_BCOMM' and the `N_ECOMM'.
-
-
-File: stabs.info, Node: Statics, Next: Based Variables, Prev: Common Blocks, Up: Variables
-
-4.5 Static Variables
-====================
-
-Initialized static variables are represented by the `S' and `V' symbol
-descriptors. `S' means file scope static, and `V' means procedure
-scope static. One exception: in XCOFF, IBM's xlc compiler always uses
-`V', and whether it is file scope or not is distinguished by whether
-the stab is located within a function.
-
- In a.out files, `N_STSYM' means the data section, `N_FUN' means the
-text section, and `N_LCSYM' means the bss section. For those systems
-with a read-only data section separate from the text section (Solaris),
-`N_ROSYM' means the read-only data section.
-
- For example, the source lines:
-
- static const int var_const = 5;
- static int var_init = 2;
- static int var_noinit;
-
-yield the following stabs:
-
- .stabs "var_const:S1",36,0,0,_var_const # 36 is N_FUN
- ...
- .stabs "var_init:S1",38,0,0,_var_init # 38 is N_STSYM
- ...
- .stabs "var_noinit:S1",40,0,0,_var_noinit # 40 is N_LCSYM
-
- In XCOFF files, the stab type need not indicate the section;
-`C_STSYM' can be used for all statics. Also, each static variable is
-enclosed in a static block. A `C_BSTAT' (emitted with a `.bs'
-assembler directive) symbol begins the static block; its value is the
-symbol number of the csect symbol whose value is the address of the
-static block, its section is the section of the variables in that
-static block, and its name is `.bs'. A `C_ESTAT' (emitted with a `.es'
-assembler directive) symbol ends the static block; its name is `.es'
-and its value and section are ignored.
-
- In ECOFF files, the storage class is used to specify the section, so
-the stab type need not indicate the section.
-
- In ELF files, for the SunPRO compiler version 2.0.1, symbol
-descriptor `S' means that the address is absolute (the linker relocates
-it) and symbol descriptor `V' means that the address is relative to the
-start of the relevant section for that compilation unit. SunPRO has
-plans to have the linker stop relocating stabs; I suspect that their the
-debugger gets the address from the corresponding ELF (not stab) symbol.
-I'm not sure how to find which symbol of that name is the right one.
-The clean way to do all this would be to have the value of a symbol
-descriptor `S' symbol be an offset relative to the start of the file,
-just like everything else, but that introduces obvious compatibility
-problems. For more information on linker stab relocation, *Note ELF
-Linker Relocation::.
-
-
-File: stabs.info, Node: Based Variables, Next: Parameters, Prev: Statics, Up: Variables
-
-4.6 Fortran Based Variables
-===========================
-
-Fortran (at least, the Sun and SGI dialects of FORTRAN-77) has a feature
-which allows allocating arrays with `malloc', but which avoids blurring
-the line between arrays and pointers the way that C does. In stabs
-such a variable uses the `b' symbol descriptor.
-
- For example, the Fortran declarations
-
- real foo, foo10(10), foo10_5(10,5)
- pointer (foop, foo)
- pointer (foo10p, foo10)
- pointer (foo105p, foo10_5)
-
- produce the stabs
-
- foo:b6
- foo10:bar3;1;10;6
- foo10_5:bar3;1;5;ar3;1;10;6
-
- In this example, `real' is type 6 and type 3 is an integral type
-which is the type of the subscripts of the array (probably `integer').
-
- The `b' symbol descriptor is like `V' in that it denotes a
-statically allocated symbol whose scope is local to a function; see
-*Note Statics::. The value of the symbol, instead of being the address
-of the variable itself, is the address of a pointer to that variable.
-So in the above example, the value of the `foo' stab is the address of
-a pointer to a real, the value of the `foo10' stab is the address of a
-pointer to a 10-element array of reals, and the value of the `foo10_5'
-stab is the address of a pointer to a 5-element array of 10-element
-arrays of reals.
-
-
-File: stabs.info, Node: Parameters, Prev: Based Variables, Up: Variables
-
-4.7 Parameters
-==============
-
-Formal parameters to a function are represented by a stab (or sometimes
-two; see below) for each parameter. The stabs are in the order in which
-the debugger should print the parameters (i.e., the order in which the
-parameters are declared in the source file). The exact form of the stab
-depends on how the parameter is being passed.
-
- Parameters passed on the stack use the symbol descriptor `p' and the
-`N_PSYM' symbol type (or `C_PSYM' for XCOFF). The value of the symbol
-is an offset used to locate the parameter on the stack; its exact
-meaning is machine-dependent, but on most machines it is an offset from
-the frame pointer.
-
- As a simple example, the code:
-
- main (argc, argv)
- int argc;
- char **argv;
-
- produces the stabs:
-
- .stabs "main:F1",36,0,0,_main # 36 is N_FUN
- .stabs "argc:p1",160,0,0,68 # 160 is N_PSYM
- .stabs "argv:p20=*21=*2",160,0,0,72
-
- The type definition of `argv' is interesting because it contains
-several type definitions. Type 21 is pointer to type 2 (char) and
-`argv' (type 20) is pointer to type 21.
-
- The following symbol descriptors are also said to go with `N_PSYM'.
-The value of the symbol is said to be an offset from the argument
-pointer (I'm not sure whether this is true or not).
-
- pP (<<??>>)
- pF Fortran function parameter
- X (function result variable)
-
-* Menu:
-
-* Register Parameters::
-* Local Variable Parameters::
-* Reference Parameters::
-* Conformant Arrays::
-
-
-File: stabs.info, Node: Register Parameters, Next: Local Variable Parameters, Up: Parameters
-
-4.7.1 Passing Parameters in Registers
--------------------------------------
-
-If the parameter is passed in a register, then traditionally there are
-two symbols for each argument:
-
- .stabs "arg:p1" . . . ; N_PSYM
- .stabs "arg:r1" . . . ; N_RSYM
-
- Debuggers use the second one to find the value, and the first one to
-know that it is an argument.
-
- Because that approach is kind of ugly, some compilers use symbol
-descriptor `P' or `R' to indicate an argument which is in a register.
-Symbol type `C_RPSYM' is used in XCOFF and `N_RSYM' is used otherwise.
-The symbol's value is the register number. `P' and `R' mean the same
-thing; the difference is that `P' is a GNU invention and `R' is an IBM
-(XCOFF) invention. As of version 4.9, GDB should handle either one.
-
- There is at least one case where GCC uses a `p' and `r' pair rather
-than `P'; this is where the argument is passed in the argument list and
-then loaded into a register.
-
- According to the AIX documentation, symbol descriptor `D' is for a
-parameter passed in a floating point register. This seems
-unnecessary--why not just use `R' with a register number which
-indicates that it's a floating point register? I haven't verified
-whether the system actually does what the documentation indicates.
-
- On the sparc and hppa, for a `P' symbol whose type is a structure or
-union, the register contains the address of the structure. On the
-sparc, this is also true of a `p' and `r' pair (using Sun `cc') or a
-`p' symbol. However, if a (small) structure is really in a register,
-`r' is used. And, to top it all off, on the hppa it might be a
-structure which was passed on the stack and loaded into a register and
-for which there is a `p' and `r' pair! I believe that symbol
-descriptor `i' is supposed to deal with this case (it is said to mean
-"value parameter by reference, indirect access"; I don't know the
-source for this information), but I don't know details or what
-compilers or debuggers use it, if any (not GDB or GCC). It is not
-clear to me whether this case needs to be dealt with differently than
-parameters passed by reference (*note Reference Parameters::).
-
-
-File: stabs.info, Node: Local Variable Parameters, Next: Reference Parameters, Prev: Register Parameters, Up: Parameters
-
-4.7.2 Storing Parameters as Local Variables
--------------------------------------------
-
-There is a case similar to an argument in a register, which is an
-argument that is actually stored as a local variable. Sometimes this
-happens when the argument was passed in a register and then the compiler
-stores it as a local variable. If possible, the compiler should claim
-that it's in a register, but this isn't always done.
-
- If a parameter is passed as one type and converted to a smaller type
-by the prologue (for example, the parameter is declared as a `float',
-but the calling conventions specify that it is passed as a `double'),
-then GCC2 (sometimes) uses a pair of symbols. The first symbol uses
-symbol descriptor `p' and the type which is passed. The second symbol
-has the type and location which the parameter actually has after the
-prologue. For example, suppose the following C code appears with no
-prototypes involved:
-
- void
- subr (f)
- float f;
- {
-
- if `f' is passed as a double at stack offset 8, and the prologue
-converts it to a float in register number 0, then the stabs look like:
-
- .stabs "f:p13",160,0,3,8 # 160 is `N_PSYM', here 13 is `double'
- .stabs "f:r12",64,0,3,0 # 64 is `N_RSYM', here 12 is `float'
-
- In both stabs 3 is the line number where `f' is declared (*note Line
-Numbers::).
-
- GCC, at least on the 960, has another solution to the same problem.
-It uses a single `p' symbol descriptor for an argument which is stored
-as a local variable but uses `N_LSYM' instead of `N_PSYM'. In this
-case, the value of the symbol is an offset relative to the local
-variables for that function, not relative to the arguments; on some
-machines those are the same thing, but not on all.
-
- On the VAX or on other machines in which the calling convention
-includes the number of words of arguments actually passed, the debugger
-(GDB at least) uses the parameter symbols to keep track of whether it
-needs to print nameless arguments in addition to the formal parameters
-which it has printed because each one has a stab. For example, in
-
- extern int fprintf (FILE *stream, char *format, ...);
- ...
- fprintf (stdout, "%d\n", x);
-
- there are stabs for `stream' and `format'. On most machines, the
-debugger can only print those two arguments (because it has no way of
-knowing that additional arguments were passed), but on the VAX or other
-machines with a calling convention which indicates the number of words
-of arguments, the debugger can print all three arguments. To do so,
-the parameter symbol (symbol descriptor `p') (not necessarily `r' or
-symbol descriptor omitted symbols) needs to contain the actual type as
-passed (for example, `double' not `float' if it is passed as a double
-and converted to a float).
-
-
-File: stabs.info, Node: Reference Parameters, Next: Conformant Arrays, Prev: Local Variable Parameters, Up: Parameters
-
-4.7.3 Passing Parameters by Reference
--------------------------------------
-
-If the parameter is passed by reference (e.g., Pascal `VAR'
-parameters), then the symbol descriptor is `v' if it is in the argument
-list, or `a' if it in a register. Other than the fact that these
-contain the address of the parameter rather than the parameter itself,
-they are identical to `p' and `R', respectively. I believe `a' is an
-AIX invention; `v' is supported by all stabs-using systems as far as I
-know.
-
-
-File: stabs.info, Node: Conformant Arrays, Prev: Reference Parameters, Up: Parameters
-
-4.7.4 Passing Conformant Array Parameters
------------------------------------------
-
-Conformant arrays are a feature of Modula-2, and perhaps other
-languages, in which the size of an array parameter is not known to the
-called function until run-time. Such parameters have two stabs: a `x'
-for the array itself, and a `C', which represents the size of the
-array. The value of the `x' stab is the offset in the argument list
-where the address of the array is stored (it this right? it is a
-guess); the value of the `C' stab is the offset in the argument list
-where the size of the array (in elements? in bytes?) is stored.
-
-
-File: stabs.info, Node: Types, Next: Macro define and undefine, Prev: Variables, Up: Top
-
-5 Defining Types
-****************
-
-The examples so far have described types as references to previously
-defined types, or defined in terms of subranges of or pointers to
-previously defined types. This chapter describes the other type
-descriptors that may follow the `=' in a type definition.
-
-* Menu:
-
-* Builtin Types:: Integers, floating point, void, etc.
-* Miscellaneous Types:: Pointers, sets, files, etc.
-* Cross-References:: Referring to a type not yet defined.
-* Subranges:: A type with a specific range.
-* Arrays:: An aggregate type of same-typed elements.
-* Strings:: Like an array but also has a length.
-* Enumerations:: Like an integer but the values have names.
-* Structures:: An aggregate type of different-typed elements.
-* Typedefs:: Giving a type a name.
-* Unions:: Different types sharing storage.
-* Function Types::
-
-
-File: stabs.info, Node: Builtin Types, Next: Miscellaneous Types, Up: Types
-
-5.1 Builtin Types
-=================
-
-Certain types are built in (`int', `short', `void', `float', etc.); the
-debugger recognizes these types and knows how to handle them. Thus,
-don't be surprised if some of the following ways of specifying builtin
-types do not specify everything that a debugger would need to know
-about the type--in some cases they merely specify enough information to
-distinguish the type from other types.
-
- The traditional way to define builtin types is convoluted, so new
-ways have been invented to describe them. Sun's `acc' uses special
-builtin type descriptors (`b' and `R'), and IBM uses negative type
-numbers. GDB accepts all three ways, as of version 4.8; dbx just
-accepts the traditional builtin types and perhaps one of the other two
-formats. The following sections describe each of these formats.
-
-* Menu:
-
-* Traditional Builtin Types:: Put on your seat belts and prepare for kludgery
-* Builtin Type Descriptors:: Builtin types with special type descriptors
-* Negative Type Numbers:: Builtin types using negative type numbers
-
-
-File: stabs.info, Node: Traditional Builtin Types, Next: Builtin Type Descriptors, Up: Builtin Types
-
-5.1.1 Traditional Builtin Types
--------------------------------
-
-This is the traditional, convoluted method for defining builtin types.
-There are several classes of such type definitions: integer, floating
-point, and `void'.
-
-* Menu:
-
-* Traditional Integer Types::
-* Traditional Other Types::
-
-
-File: stabs.info, Node: Traditional Integer Types, Next: Traditional Other Types, Up: Traditional Builtin Types
-
-5.1.1.1 Traditional Integer Types
-.................................
-
-Often types are defined as subranges of themselves. If the bounding
-values fit within an `int', then they are given normally. For example:
-
- .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0 # 128 is N_LSYM
- .stabs "char:t2=r2;0;127;",128,0,0,0
-
- Builtin types can also be described as subranges of `int':
-
- .stabs "unsigned short:t6=r1;0;65535;",128,0,0,0
-
- If the lower bound of a subrange is 0 and the upper bound is -1, the
-type is an unsigned integral type whose bounds are too big to describe
-in an `int'. Traditionally this is only used for `unsigned int' and
-`unsigned long':
-
- .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0
-
- For larger types, GCC 2.4.5 puts out bounds in octal, with one or
-more leading zeroes. In this case a negative bound consists of a number
-which is a 1 bit (for the sign bit) followed by a 0 bit for each bit in
-the number (except the sign bit), and a positive bound is one which is a
-1 bit for each bit in the number (except possibly the sign bit). All
-known versions of dbx and GDB version 4 accept this (at least in the
-sense of not refusing to process the file), but GDB 3.5 refuses to read
-the whole file containing such symbols. So GCC 2.3.3 did not output the
-proper size for these types. As an example of octal bounds, the string
-fields of the stabs for 64 bit integer types look like:
-
- long int:t3=r1;001000000000000000000000;000777777777777777777777;
- long unsigned int:t5=r1;000000000000000000000000;001777777777777777777777;
-
- If the lower bound of a subrange is 0 and the upper bound is
-negative, the type is an unsigned integral type whose size in bytes is
-the absolute value of the upper bound. I believe this is a Convex
-convention for `unsigned long long'.
-
- If the lower bound of a subrange is negative and the upper bound is
-0, the type is a signed integral type whose size in bytes is the
-absolute value of the lower bound. I believe this is a Convex
-convention for `long long'. To distinguish this from a legitimate
-subrange, the type should be a subrange of itself. I'm not sure whether
-this is the case for Convex.
-
-
-File: stabs.info, Node: Traditional Other Types, Prev: Traditional Integer Types, Up: Traditional Builtin Types
-
-5.1.1.2 Traditional Other Types
-...............................
-
-If the upper bound of a subrange is 0 and the lower bound is positive,
-the type is a floating point type, and the lower bound of the subrange
-indicates the number of bytes in the type:
-
- .stabs "float:t12=r1;4;0;",128,0,0,0
- .stabs "double:t13=r1;8;0;",128,0,0,0
-
- However, GCC writes `long double' the same way it writes `double',
-so there is no way to distinguish.
-
- .stabs "long double:t14=r1;8;0;",128,0,0,0
-
- Complex types are defined the same way as floating-point types;
-there is no way to distinguish a single-precision complex from a
-double-precision floating-point type.
-
- The C `void' type is defined as itself:
-
- .stabs "void:t15=15",128,0,0,0
-
- I'm not sure how a boolean type is represented.
-
-
-File: stabs.info, Node: Builtin Type Descriptors, Next: Negative Type Numbers, Prev: Traditional Builtin Types, Up: Builtin Types
-
-5.1.2 Defining Builtin Types Using Builtin Type Descriptors
------------------------------------------------------------
-
-This is the method used by Sun's `acc' for defining builtin types.
-These are the type descriptors to define builtin types:
-
-`b SIGNED CHAR-FLAG WIDTH ; OFFSET ; NBITS ;'
- Define an integral type. SIGNED is `u' for unsigned or `s' for
- signed. CHAR-FLAG is `c' which indicates this is a character
- type, or is omitted. I assume this is to distinguish an integral
- type from a character type of the same size, for example it might
- make sense to set it for the C type `wchar_t' so the debugger can
- print such variables differently (Solaris does not do this). Sun
- sets it on the C types `signed char' and `unsigned char' which
- arguably is wrong. WIDTH and OFFSET appear to be for small
- objects stored in larger ones, for example a `short' in an `int'
- register. WIDTH is normally the number of bytes in the type.
- OFFSET seems to always be zero. NBITS is the number of bits in
- the type.
-
- Note that type descriptor `b' used for builtin types conflicts with
- its use for Pascal space types (*note Miscellaneous Types::); they
- can be distinguished because the character following the type
- descriptor will be a digit, `(', or `-' for a Pascal space type, or
- `u' or `s' for a builtin type.
-
-`w'
- Documented by AIX to define a wide character type, but their
- compiler actually uses negative type numbers (*note Negative Type
- Numbers::).
-
-`R FP-TYPE ; BYTES ;'
- Define a floating point type. FP-TYPE has one of the following
- values:
-
- `1 (NF_SINGLE)'
- IEEE 32-bit (single precision) floating point format.
-
- `2 (NF_DOUBLE)'
- IEEE 64-bit (double precision) floating point format.
-
- `3 (NF_COMPLEX)'
-
- `4 (NF_COMPLEX16)'
-
- `5 (NF_COMPLEX32)'
- These are for complex numbers. A comment in the GDB source
- describes them as Fortran `complex', `double complex', and
- `complex*16', respectively, but what does that mean? (i.e.,
- Single precision? Double precision?).
-
- `6 (NF_LDOUBLE)'
- Long double. This should probably only be used for Sun format
- `long double', and new codes should be used for other floating
- point formats (`NF_DOUBLE' can be used if a `long double' is
- really just an IEEE double, of course).
-
- BYTES is the number of bytes occupied by the type. This allows a
- debugger to perform some operations with the type even if it
- doesn't understand FP-TYPE.
-
-`g TYPE-INFORMATION ; NBITS'
- Documented by AIX to define a floating type, but their compiler
- actually uses negative type numbers (*note Negative Type
- Numbers::).
-
-`c TYPE-INFORMATION ; NBITS'
- Documented by AIX to define a complex type, but their compiler
- actually uses negative type numbers (*note Negative Type
- Numbers::).
-
- The C `void' type is defined as a signed integral type 0 bits long:
- .stabs "void:t19=bs0;0;0",128,0,0,0
- The Solaris compiler seems to omit the trailing semicolon in this
-case. Getting sloppy in this way is not a swift move because if a type
-is embedded in a more complex expression it is necessary to be able to
-tell where it ends.
-
- I'm not sure how a boolean type is represented.
-
-
-File: stabs.info, Node: Negative Type Numbers, Prev: Builtin Type Descriptors, Up: Builtin Types
-
-5.1.3 Negative Type Numbers
----------------------------
-
-This is the method used in XCOFF for defining builtin types. Since the
-debugger knows about the builtin types anyway, the idea of negative
-type numbers is simply to give a special type number which indicates
-the builtin type. There is no stab defining these types.
-
- There are several subtle issues with negative type numbers.
-
- One is the size of the type. A builtin type (for example the C types
-`int' or `long') might have different sizes depending on compiler
-options, the target architecture, the ABI, etc. This issue doesn't
-come up for IBM tools since (so far) they just target the RS/6000; the
-sizes indicated below for each size are what the IBM RS/6000 tools use.
-To deal with differing sizes, either define separate negative type
-numbers for each size (which works but requires changing the debugger,
-and, unless you get both AIX dbx and GDB to accept the change,
-introduces an incompatibility), or use a type attribute (*note String
-Field::) to define a new type with the appropriate size (which merely
-requires a debugger which understands type attributes, like AIX dbx or
-GDB). For example,
-
- .stabs "boolean:t10=@s8;-16",128,0,0,0
-
- defines an 8-bit boolean type, and
-
- .stabs "boolean:t10=@s64;-16",128,0,0,0
-
- defines a 64-bit boolean type.
-
- A similar issue is the format of the type. This comes up most often
-for floating-point types, which could have various formats (particularly
-extended doubles, which vary quite a bit even among IEEE systems).
-Again, it is best to define a new negative type number for each
-different format; changing the format based on the target system has
-various problems. One such problem is that the Alpha has both VAX and
-IEEE floating types. One can easily imagine one library using the VAX
-types and another library in the same executable using the IEEE types.
-Another example is that the interpretation of whether a boolean is true
-or false can be based on the least significant bit, most significant
-bit, whether it is zero, etc., and different compilers (or different
-options to the same compiler) might provide different kinds of boolean.
-
- The last major issue is the names of the types. The name of a given
-type depends _only_ on the negative type number given; these do not
-vary depending on the language, the target system, or anything else.
-One can always define separate type numbers--in the following list you
-will see for example separate `int' and `integer*4' types which are
-identical except for the name. But compatibility can be maintained by
-not inventing new negative type numbers and instead just defining a new
-type with a new name. For example:
-
- .stabs "CARDINAL:t10=-8",128,0,0,0
-
- Here is the list of negative type numbers. The phrase "integral
-type" is used to mean twos-complement (I strongly suspect that all
-machines which use stabs use twos-complement; most machines use
-twos-complement these days).
-
-`-1'
- `int', 32 bit signed integral type.
-
-`-2'
- `char', 8 bit type holding a character. Both GDB and dbx on AIX
- treat this as signed. GCC uses this type whether `char' is signed
- or not, which seems like a bad idea. The AIX compiler (`xlc')
- seems to avoid this type; it uses -5 instead for `char'.
-
-`-3'
- `short', 16 bit signed integral type.
-
-`-4'
- `long', 32 bit signed integral type.
-
-`-5'
- `unsigned char', 8 bit unsigned integral type.
-
-`-6'
- `signed char', 8 bit signed integral type.
-
-`-7'
- `unsigned short', 16 bit unsigned integral type.
-
-`-8'
- `unsigned int', 32 bit unsigned integral type.
-
-`-9'
- `unsigned', 32 bit unsigned integral type.
-
-`-10'
- `unsigned long', 32 bit unsigned integral type.
-
-`-11'
- `void', type indicating the lack of a value.
-
-`-12'
- `float', IEEE single precision.
-
-`-13'
- `double', IEEE double precision.
-
-`-14'
- `long double', IEEE double precision. The compiler claims the size
- will increase in a future release, and for binary compatibility
- you have to avoid using `long double'. I hope when they increase
- it they use a new negative type number.
-
-`-15'
- `integer'. 32 bit signed integral type.
-
-`-16'
- `boolean'. 32 bit type. GDB and GCC assume that zero is false,
- one is true, and other values have unspecified meaning. I hope
- this agrees with how the IBM tools use the type.
-
-`-17'
- `short real'. IEEE single precision.
-
-`-18'
- `real'. IEEE double precision.
-
-`-19'
- `stringptr'. *Note Strings::.
-
-`-20'
- `character', 8 bit unsigned character type.
-
-`-21'
- `logical*1', 8 bit type. This Fortran type has a split
- personality in that it is used for boolean variables, but can also
- be used for unsigned integers. 0 is false, 1 is true, and other
- values are non-boolean.
-
-`-22'
- `logical*2', 16 bit type. This Fortran type has a split
- personality in that it is used for boolean variables, but can also
- be used for unsigned integers. 0 is false, 1 is true, and other
- values are non-boolean.
-
-`-23'
- `logical*4', 32 bit type. This Fortran type has a split
- personality in that it is used for boolean variables, but can also
- be used for unsigned integers. 0 is false, 1 is true, and other
- values are non-boolean.
-
-`-24'
- `logical', 32 bit type. This Fortran type has a split personality
- in that it is used for boolean variables, but can also be used for
- unsigned integers. 0 is false, 1 is true, and other values are
- non-boolean.
-
-`-25'
- `complex'. A complex type consisting of two IEEE single-precision
- floating point values.
-
-`-26'
- `complex'. A complex type consisting of two IEEE double-precision
- floating point values.
-
-`-27'
- `integer*1', 8 bit signed integral type.
-
-`-28'
- `integer*2', 16 bit signed integral type.
-
-`-29'
- `integer*4', 32 bit signed integral type.
-
-`-30'
- `wchar'. Wide character, 16 bits wide, unsigned (what format?
- Unicode?).
-
-`-31'
- `long long', 64 bit signed integral type.
-
-`-32'
- `unsigned long long', 64 bit unsigned integral type.
-
-`-33'
- `logical*8', 64 bit unsigned integral type.
-
-`-34'
- `integer*8', 64 bit signed integral type.
-
-
-File: stabs.info, Node: Miscellaneous Types, Next: Cross-References, Prev: Builtin Types, Up: Types
-
-5.2 Miscellaneous Types
-=======================
-
-`b TYPE-INFORMATION ; BYTES'
- Pascal space type. This is documented by IBM; what does it mean?
-
- This use of the `b' type descriptor can be distinguished from its
- use for builtin integral types (*note Builtin Type Descriptors::)
- because the character following the type descriptor is always a
- digit, `(', or `-'.
-
-`B TYPE-INFORMATION'
- A volatile-qualified version of TYPE-INFORMATION. This is a Sun
- extension. References and stores to a variable with a
- volatile-qualified type must not be optimized or cached; they must
- occur as the user specifies them.
-
-`d TYPE-INFORMATION'
- File of type TYPE-INFORMATION. As far as I know this is only used
- by Pascal.
-
-`k TYPE-INFORMATION'
- A const-qualified version of TYPE-INFORMATION. This is a Sun
- extension. A variable with a const-qualified type cannot be
- modified.
-
-`M TYPE-INFORMATION ; LENGTH'
- Multiple instance type. The type seems to composed of LENGTH
- repetitions of TYPE-INFORMATION, for example `character*3' is
- represented by `M-2;3', where `-2' is a reference to a character
- type (*note Negative Type Numbers::). I'm not sure how this
- differs from an array. This appears to be a Fortran feature.
- LENGTH is a bound, like those in range types; see *note
- Subranges::.
-
-`S TYPE-INFORMATION'
- Pascal set type. TYPE-INFORMATION must be a small type such as an
- enumeration or a subrange, and the type is a bitmask whose length
- is specified by the number of elements in TYPE-INFORMATION.
-
- In CHILL, if it is a bitstring instead of a set, also use the `S'
- type attribute (*note String Field::).
-
-`* TYPE-INFORMATION'
- Pointer to TYPE-INFORMATION.
-
-
-File: stabs.info, Node: Cross-References, Next: Subranges, Prev: Miscellaneous Types, Up: Types
-
-5.3 Cross-References to Other Types
-===================================
-
-A type can be used before it is defined; one common way to deal with
-that situation is just to use a type reference to a type which has not
-yet been defined.
-
- Another way is with the `x' type descriptor, which is followed by
-`s' for a structure tag, `u' for a union tag, or `e' for a enumerator
-tag, followed by the name of the tag, followed by `:'. If the name
-contains `::' between a `<' and `>' pair (for C++ templates), such a
-`::' does not end the name--only a single `:' ends the name; see *note
-Nested Symbols::.
-
- For example, the following C declarations:
-
- struct foo;
- struct foo *bar;
-
-produce:
-
- .stabs "bar:G16=*17=xsfoo:",32,0,0,0
-
- Not all debuggers support the `x' type descriptor, so on some
-machines GCC does not use it. I believe that for the above example it
-would just emit a reference to type 17 and never define it, but I
-haven't verified that.
-
- Modula-2 imported types, at least on AIX, use the `i' type
-descriptor, which is followed by the name of the module from which the
-type is imported, followed by `:', followed by the name of the type.
-There is then optionally a comma followed by type information for the
-type. This differs from merely naming the type (*note Typedefs::) in
-that it identifies the module; I don't understand whether the name of
-the type given here is always just the same as the name we are giving
-it, or whether this type descriptor is used with a nameless stab (*note
-String Field::), or what. The symbol ends with `;'.
-
-
-File: stabs.info, Node: Subranges, Next: Arrays, Prev: Cross-References, Up: Types
-
-5.4 Subrange Types
-==================
-
-The `r' type descriptor defines a type as a subrange of another type.
-It is followed by type information for the type of which it is a
-subrange, a semicolon, an integral lower bound, a semicolon, an
-integral upper bound, and a semicolon. The AIX documentation does not
-specify the trailing semicolon, in an effort to specify array indexes
-more cleanly, but a subrange which is not an array index has always
-included a trailing semicolon (*note Arrays::).
-
- Instead of an integer, either bound can be one of the following:
-
-`A OFFSET'
- The bound is passed by reference on the stack at offset OFFSET
- from the argument list. *Note Parameters::, for more information
- on such offsets.
-
-`T OFFSET'
- The bound is passed by value on the stack at offset OFFSET from
- the argument list.
-
-`a REGISTER-NUMBER'
- The bound is passed by reference in register number
- REGISTER-NUMBER.
-
-`t REGISTER-NUMBER'
- The bound is passed by value in register number REGISTER-NUMBER.
-
-`J'
- There is no bound.
-
- Subranges are also used for builtin types; see *note Traditional
-Builtin Types::.
-
-
-File: stabs.info, Node: Arrays, Next: Strings, Prev: Subranges, Up: Types
-
-5.5 Array Types
-===============
-
-Arrays use the `a' type descriptor. Following the type descriptor is
-the type of the index and the type of the array elements. If the index
-type is a range type, it ends in a semicolon; otherwise (for example,
-if it is a type reference), there does not appear to be any way to tell
-where the types are separated. In an effort to clean up this mess, IBM
-documents the two types as being separated by a semicolon, and a range
-type as not ending in a semicolon (but this is not right for range
-types which are not array indexes, *note Subranges::). I think
-probably the best solution is to specify that a semicolon ends a range
-type, and that the index type and element type of an array are
-separated by a semicolon, but that if the index type is a range type,
-the extra semicolon can be omitted. GDB (at least through version 4.9)
-doesn't support any kind of index type other than a range anyway; I'm
-not sure about dbx.
-
- It is well established, and widely used, that the type of the index,
-unlike most types found in the stabs, is merely a type definition, not
-type information (*note String Field::) (that is, it need not start with
-`TYPE-NUMBER=' if it is defining a new type). According to a comment
-in GDB, this is also true of the type of the array elements; it gives
-`ar1;1;10;ar1;1;10;4' as a legitimate way to express a two dimensional
-array. According to AIX documentation, the element type must be type
-information. GDB accepts either.
-
- The type of the index is often a range type, expressed as the type
-descriptor `r' and some parameters. It defines the size of the array.
-In the example below, the range `r1;0;2;' defines an index type which
-is a subrange of type 1 (integer), with a lower bound of 0 and an upper
-bound of 2. This defines the valid range of subscripts of a
-three-element C array.
-
- For example, the definition:
-
- char char_vec[3] = {'a','b','c'};
-
-produces the output:
-
- .stabs "char_vec:G19=ar1;0;2;2",32,0,0,0
- .global _char_vec
- .align 4
- _char_vec:
- .byte 97
- .byte 98
- .byte 99
-
- If an array is "packed", the elements are spaced more closely than
-normal, saving memory at the expense of speed. For example, an array
-of 3-byte objects might, if unpacked, have each element aligned on a
-4-byte boundary, but if packed, have no padding. One way to specify
-that something is packed is with type attributes (*note String
-Field::). In the case of arrays, another is to use the `P' type
-descriptor instead of `a'. Other than specifying a packed array, `P'
-is identical to `a'.
-
- An open array is represented by the `A' type descriptor followed by
-type information specifying the type of the array elements.
-
- An N-dimensional dynamic array is represented by
-
- D DIMENSIONS ; TYPE-INFORMATION
-
- DIMENSIONS is the number of dimensions; TYPE-INFORMATION specifies
-the type of the array elements.
-
- A subarray of an N-dimensional array is represented by
-
- E DIMENSIONS ; TYPE-INFORMATION
-
- DIMENSIONS is the number of dimensions; TYPE-INFORMATION specifies
-the type of the array elements.
-
-
-File: stabs.info, Node: Strings, Next: Enumerations, Prev: Arrays, Up: Types
-
-5.6 Strings
-===========
-
-Some languages, like C or the original Pascal, do not have string types,
-they just have related things like arrays of characters. But most
-Pascals and various other languages have string types, which are
-indicated as follows:
-
-`n TYPE-INFORMATION ; BYTES'
- BYTES is the maximum length. I'm not sure what TYPE-INFORMATION
- is; I suspect that it means that this is a string of
- TYPE-INFORMATION (thus allowing a string of integers, a string of
- wide characters, etc., as well as a string of characters). Not
- sure what the format of this type is. This is an AIX feature.
-
-`z TYPE-INFORMATION ; BYTES'
- Just like `n' except that this is a gstring, not an ordinary
- string. I don't know the difference.
-
-`N'
- Pascal Stringptr. What is this? This is an AIX feature.
-
- Languages, such as CHILL which have a string type which is basically
-just an array of characters use the `S' type attribute (*note String
-Field::).
-
-
-File: stabs.info, Node: Enumerations, Next: Structures, Prev: Strings, Up: Types
-
-5.7 Enumerations
-================
-
-Enumerations are defined with the `e' type descriptor.
-
- The source line below declares an enumeration type at file scope.
-The type definition is located after the `N_RBRAC' that marks the end of
-the previous procedure's block scope, and before the `N_FUN' that marks
-the beginning of the next procedure's block scope. Therefore it does
-not describe a block local symbol, but a file local one.
-
- The source line:
-
- enum e_places {first,second=3,last};
-
-generates the following stab:
-
- .stabs "e_places:T22=efirst:0,second:3,last:4,;",128,0,0,0
-
- The symbol descriptor (`T') says that the stab describes a
-structure, enumeration, or union tag. The type descriptor `e',
-following the `22=' of the type definition narrows it down to an
-enumeration type. Following the `e' is a list of the elements of the
-enumeration. The format is `NAME:VALUE,'. The list of elements ends
-with `;'. The fact that VALUE is specified as an integer can cause
-problems if the value is large. GCC 2.5.2 tries to output it in octal
-in that case with a leading zero, which is probably a good thing,
-although GDB 4.11 supports octal only in cases where decimal is
-perfectly good. Negative decimal values are supported by both GDB and
-dbx.
-
- There is no standard way to specify the size of an enumeration type;
-it is determined by the architecture (normally all enumerations types
-are 32 bits). Type attributes can be used to specify an enumeration
-type of another size for debuggers which support them; see *note String
-Field::.
-
- Enumeration types are unusual in that they define symbols for the
-enumeration values (`first', `second', and `third' in the above
-example), and even though these symbols are visible in the file as a
-whole (rather than being in a more local namespace like structure
-member names), they are defined in the type definition for the
-enumeration type rather than each having their own symbol. In order to
-be fast, GDB will only get symbols from such types (in its initial scan
-of the stabs) if the type is the first thing defined after a `T' or `t'
-symbol descriptor (the above example fulfills this requirement). If
-the type does not have a name, the compiler should emit it in a
-nameless stab (*note String Field::); GCC does this.
-
-
-File: stabs.info, Node: Structures, Next: Typedefs, Prev: Enumerations, Up: Types
-
-5.8 Structures
-==============
-
-The encoding of structures in stabs can be shown with an example.
-
- The following source code declares a structure tag and defines an
-instance of the structure in global scope. Then a `typedef' equates the
-structure tag with a new type. Separate stabs are generated for the
-structure tag, the structure `typedef', and the structure instance. The
-stabs for the tag and the `typedef' are emitted when the definitions are
-encountered. Since the structure elements are not initialized, the
-stab and code for the structure variable itself is located at the end
-of the program in the bss section.
-
- struct s_tag {
- int s_int;
- float s_float;
- char s_char_vec[8];
- struct s_tag* s_next;
- } g_an_s;
-
- typedef struct s_tag s_typedef;
-
- The structure tag has an `N_LSYM' stab type because, like the
-enumeration, the symbol has file scope. Like the enumeration, the
-symbol descriptor is `T', for enumeration, structure, or tag type. The
-type descriptor `s' following the `16=' of the type definition narrows
-the symbol type to structure.
-
- Following the `s' type descriptor is the number of bytes the
-structure occupies, followed by a description of each structure element.
-The structure element descriptions are of the form `NAME:TYPE, BIT
-OFFSET FROM THE START OF THE STRUCT, NUMBER OF BITS IN THE ELEMENT'.
-
- # 128 is N_LSYM
- .stabs "s_tag:T16=s20s_int:1,0,32;s_float:12,32,32;
- s_char_vec:17=ar1;0;7;2,64,64;s_next:18=*16,128,32;;",128,0,0,0
-
- In this example, the first two structure elements are previously
-defined types. For these, the type following the `NAME:' part of the
-element description is a simple type reference. The other two structure
-elements are new types. In this case there is a type definition
-embedded after the `NAME:'. The type definition for the array element
-looks just like a type definition for a stand-alone array. The
-`s_next' field is a pointer to the same kind of structure that the
-field is an element of. So the definition of structure type 16
-contains a type definition for an element which is a pointer to type 16.
-
- If a field is a static member (this is a C++ feature in which a
-single variable appears to be a field of every structure of a given
-type) it still starts out with the field name, a colon, and the type,
-but then instead of a comma, bit position, comma, and bit size, there
-is a colon followed by the name of the variable which each such field
-refers to.
-
- If the structure has methods (a C++ feature), they follow the
-non-method fields; see *note Cplusplus::.
-
-
-File: stabs.info, Node: Typedefs, Next: Unions, Prev: Structures, Up: Types
-
-5.9 Giving a Type a Name
-========================
-
-To give a type a name, use the `t' symbol descriptor. The type is
-specified by the type information (*note String Field::) for the stab.
-For example,
-
- .stabs "s_typedef:t16",128,0,0,0 # 128 is N_LSYM
-
- specifies that `s_typedef' refers to type number 16. Such stabs
-have symbol type `N_LSYM' (or `C_DECL' for XCOFF). (The Sun
-documentation mentions using `N_GSYM' in some cases).
-
- If you are specifying the tag name for a structure, union, or
-enumeration, use the `T' symbol descriptor instead. I believe C is the
-only language with this feature.
-
- If the type is an opaque type (I believe this is a Modula-2 feature),
-AIX provides a type descriptor to specify it. The type descriptor is
-`o' and is followed by a name. I don't know what the name means--is it
-always the same as the name of the type, or is this type descriptor
-used with a nameless stab (*note String Field::)? There optionally
-follows a comma followed by type information which defines the type of
-this type. If omitted, a semicolon is used in place of the comma and
-the type information, and the type is much like a generic pointer
-type--it has a known size but little else about it is specified.
-
-
-File: stabs.info, Node: Unions, Next: Function Types, Prev: Typedefs, Up: Types
-
-5.10 Unions
-===========
-
- union u_tag {
- int u_int;
- float u_float;
- char* u_char;
- } an_u;
-
- This code generates a stab for a union tag and a stab for a union
-variable. Both use the `N_LSYM' stab type. If a union variable is
-scoped locally to the procedure in which it is defined, its stab is
-located immediately preceding the `N_LBRAC' for the procedure's block
-start.
-
- The stab for the union tag, however, is located preceding the code
-for the procedure in which it is defined. The stab type is `N_LSYM'.
-This would seem to imply that the union type is file scope, like the
-struct type `s_tag'. This is not true. The contents and position of
-the stab for `u_type' do not convey any information about its procedure
-local scope.
-
- # 128 is N_LSYM
- .stabs "u_tag:T23=u4u_int:1,0,32;u_float:12,0,32;u_char:21,0,32;;",
- 128,0,0,0
-
- The symbol descriptor `T', following the `name:' means that the stab
-describes an enumeration, structure, or union tag. The type descriptor
-`u', following the `23=' of the type definition, narrows it down to a
-union type definition. Following the `u' is the number of bytes in the
-union. After that is a list of union element descriptions. Their
-format is `NAME:TYPE, BIT OFFSET INTO THE UNION, NUMBER OF BYTES FOR
-THE ELEMENT;'.
-
- The stab for the union variable is:
-
- .stabs "an_u:23",128,0,0,-20 # 128 is N_LSYM
-
- `-20' specifies where the variable is stored (*note Stack
-Variables::).
-
-
-File: stabs.info, Node: Function Types, Prev: Unions, Up: Types
-
-5.11 Function Types
-===================
-
-Various types can be defined for function variables. These types are
-not used in defining functions (*note Procedures::); they are used for
-things like pointers to functions.
-
- The simple, traditional, type is type descriptor `f' is followed by
-type information for the return type of the function, followed by a
-semicolon.
-
- This does not deal with functions for which the number and types of
-the parameters are part of the type, as in Modula-2 or ANSI C. AIX
-provides extensions to specify these, using the `f', `F', `p', and `R'
-type descriptors.
-
- First comes the type descriptor. If it is `f' or `F', this type
-involves a function rather than a procedure, and the type information
-for the return type of the function follows, followed by a comma. Then
-comes the number of parameters to the function and a semicolon. Then,
-for each parameter, there is the name of the parameter followed by a
-colon (this is only present for type descriptors `R' and `F' which
-represent Pascal function or procedure parameters), type information
-for the parameter, a comma, 0 if passed by reference or 1 if passed by
-value, and a semicolon. The type definition ends with a semicolon.
-
- For example, this variable definition:
-
- int (*g_pf)();
-
-generates the following code:
-
- .stabs "g_pf:G24=*25=f1",32,0,0,0
- .common _g_pf,4,"bss"
-
- The variable defines a new type, 24, which is a pointer to another
-new type, 25, which is a function returning `int'.
-
-
-File: stabs.info, Node: Macro define and undefine, Next: Symbol Tables, Prev: Types, Up: Top
-
-6 Representation of #define and #undef
-**************************************
-
-This section describes the stabs support for macro define and undefine
-information, supported on some systems. (e.g., with `-g3' `-gstabs'
-when using GCC).
-
- A `#define MACRO-NAME MACRO-BODY' is represented with an
-`N_MAC_DEFINE' stab with a string field of `MACRO-NAME MACRO-BODY'.
-
- An `#undef MACRO-NAME' is represented with an `N_MAC_UNDEF' stabs
-with a string field of simply `MACRO-NAME'.
-
- For both `N_MAC_DEFINE' and `N_MAC_UNDEF', the desc field is the
-line number within the file where the corresponding `#define' or
-`#undef' occurred.
-
- For example, the following C code:
-
- #define NONE 42
- #define TWO(a, b) (a + (a) + 2 * b)
- #define ONE(c) (c + 19)
-
- main(int argc, char *argv[])
- {
- func(NONE, TWO(10, 11));
- func(NONE, ONE(23));
-
- #undef ONE
- #define ONE(c) (c + 23)
-
- func(NONE, ONE(-23));
-
- return (0);
- }
-
- int global;
-
- func(int arg1, int arg2)
- {
- global = arg1 + arg2;
- }
-
-produces the following stabs (as well as many others):
-
- .stabs "NONE 42",54,0,1,0
- .stabs "TWO(a,b) (a + (a) + 2 * b)",54,0,2,0
- .stabs "ONE(c) (c + 19)",54,0,3,0
- .stabs "ONE",58,0,10,0
- .stabs "ONE(c) (c + 23)",54,0,11,0
-
-NOTE: In the above example, `54' is `N_MAC_DEFINE' and `58' is
-`N_MAC_UNDEF'.
-
-
-File: stabs.info, Node: Symbol Tables, Next: Cplusplus, Prev: Macro define and undefine, Up: Top
-
-7 Symbol Information in Symbol Tables
-*************************************
-
-This chapter describes the format of symbol table entries and how stab
-assembler directives map to them. It also describes the
-transformations that the assembler and linker make on data from stabs.
-
-* Menu:
-
-* Symbol Table Format::
-* Transformations On Symbol Tables::
-
-
-File: stabs.info, Node: Symbol Table Format, Next: Transformations On Symbol Tables, Up: Symbol Tables
-
-7.1 Symbol Table Format
-=======================
-
-Each time the assembler encounters a stab directive, it puts each field
-of the stab into a corresponding field in a symbol table entry of its
-output file. If the stab contains a string field, the symbol table
-entry for that stab points to a string table entry containing the
-string data from the stab. Assembler labels become relocatable
-addresses. Symbol table entries in a.out have the format:
-
- struct internal_nlist {
- unsigned long n_strx; /* index into string table of name */
- unsigned char n_type; /* type of symbol */
- unsigned char n_other; /* misc info (usually empty) */
- unsigned short n_desc; /* description field */
- bfd_vma n_value; /* value of symbol */
- };
-
- If the stab has a string, the `n_strx' field holds the offset in
-bytes of the string within the string table. The string is terminated
-by a NUL character. If the stab lacks a string (for example, it was
-produced by a `.stabn' or `.stabd' directive), the `n_strx' field is
-zero.
-
- Symbol table entries with `n_type' field values greater than 0x1f
-originated as stabs generated by the compiler (with one random
-exception). The other entries were placed in the symbol table of the
-executable by the assembler or the linker.
-
-
-File: stabs.info, Node: Transformations On Symbol Tables, Prev: Symbol Table Format, Up: Symbol Tables
-
-7.2 Transformations on Symbol Tables
-====================================
-
-The linker concatenates object files and does fixups of externally
-defined symbols.
-
- You can see the transformations made on stab data by the assembler
-and linker by examining the symbol table after each pass of the build.
-To do this, use `nm -ap', which dumps the symbol table, including
-debugging information, unsorted. For stab entries the columns are:
-VALUE, OTHER, DESC, TYPE, STRING. For assembler and linker symbols,
-the columns are: VALUE, TYPE, STRING.
-
- The low 5 bits of the stab type tell the linker how to relocate the
-value of the stab. Thus for stab types like `N_RSYM' and `N_LSYM',
-where the value is an offset or a register number, the low 5 bits are
-`N_ABS', which tells the linker not to relocate the value.
-
- Where the value of a stab contains an assembly language label, it is
-transformed by each build step. The assembler turns it into a
-relocatable address and the linker turns it into an absolute address.
-
-* Menu:
-
-* Transformations On Static Variables::
-* Transformations On Global Variables::
-* Stab Section Transformations:: For some object file formats,
- things are a bit different.
-
-
-File: stabs.info, Node: Transformations On Static Variables, Next: Transformations On Global Variables, Up: Transformations On Symbol Tables
-
-7.2.1 Transformations on Static Variables
------------------------------------------
-
-This source line defines a static variable at file scope:
-
- static int s_g_repeat
-
-The following stab describes the symbol:
-
- .stabs "s_g_repeat:S1",38,0,0,_s_g_repeat
-
-The assembler transforms the stab into this symbol table entry in the
-`.o' file. The location is expressed as a data segment offset.
-
- 00000084 - 00 0000 STSYM s_g_repeat:S1
-
-In the symbol table entry from the executable, the linker has made the
-relocatable address absolute.
-
- 0000e00c - 00 0000 STSYM s_g_repeat:S1
-
-
-File: stabs.info, Node: Transformations On Global Variables, Next: Stab Section Transformations, Prev: Transformations On Static Variables, Up: Transformations On Symbol Tables
-
-7.2.2 Transformations on Global Variables
------------------------------------------
-
-Stabs for global variables do not contain location information. In this
-case, the debugger finds location information in the assembler or
-linker symbol table entry describing the variable. The source line:
-
- char g_foo = 'c';
-
-generates the stab:
-
- .stabs "g_foo:G2",32,0,0,0
-
- The variable is represented by two symbol table entries in the object
-file (see below). The first one originated as a stab. The second one
-is an external symbol. The upper case `D' signifies that the `n_type'
-field of the symbol table contains 7, `N_DATA' with local linkage. The
-stab's value is zero since the value is not used for `N_GSYM' stabs.
-The value of the linker symbol is the relocatable address corresponding
-to the variable.
-
- 00000000 - 00 0000 GSYM g_foo:G2
- 00000080 D _g_foo
-
-These entries as transformed by the linker. The linker symbol table
-entry now holds an absolute address:
-
- 00000000 - 00 0000 GSYM g_foo:G2
- ...
- 0000e008 D _g_foo
-
-
-File: stabs.info, Node: Stab Section Transformations, Prev: Transformations On Global Variables, Up: Transformations On Symbol Tables
-
-7.2.3 Transformations of Stabs in separate sections
----------------------------------------------------
-
-For object file formats using stabs in separate sections (*note Stab
-Sections::), use `objdump --stabs' instead of `nm' to show the stabs in
-an object or executable file. `objdump' is a GNU utility; Sun does not
-provide any equivalent.
-
- The following example is for a stab whose value is an address is
-relative to the compilation unit (*note ELF Linker Relocation::). For
-example, if the source line
-
- static int ld = 5;
-
- appears within a function, then the assembly language output from the
-compiler contains:
-
- .Ddata.data:
- ...
- .stabs "ld:V(0,3)",0x26,0,4,.L18-Ddata.data # 0x26 is N_STSYM
- ...
- .L18:
- .align 4
- .word 0x5
-
- Because the value is formed by subtracting one symbol from another,
-the value is absolute, not relocatable, and so the object file contains
-
- Symnum n_type n_othr n_desc n_value n_strx String
- 31 STSYM 0 4 00000004 680 ld:V(0,3)
-
- without any relocations, and the executable file also contains
-
- Symnum n_type n_othr n_desc n_value n_strx String
- 31 STSYM 0 4 00000004 680 ld:V(0,3)
-
-
-File: stabs.info, Node: Cplusplus, Next: Stab Types, Prev: Symbol Tables, Up: Top
-
-8 GNU C++ Stabs
-***************
-
-* Menu:
-
-* Class Names:: C++ class names are both tags and typedefs.
-* Nested Symbols:: C++ symbol names can be within other types.
-* Basic Cplusplus Types::
-* Simple Classes::
-* Class Instance::
-* Methods:: Method definition
-* Method Type Descriptor:: The `#' type descriptor
-* Member Type Descriptor:: The `@' type descriptor
-* Protections::
-* Method Modifiers::
-* Virtual Methods::
-* Inheritance::
-* Virtual Base Classes::
-* Static Members::
-
-
-File: stabs.info, Node: Class Names, Next: Nested Symbols, Up: Cplusplus
-
-8.1 C++ Class Names
-===================
-
-In C++, a class name which is declared with `class', `struct', or
-`union', is not only a tag, as in C, but also a type name. Thus there
-should be stabs with both `t' and `T' symbol descriptors (*note
-Typedefs::).
-
- To save space, there is a special abbreviation for this case. If the
-`T' symbol descriptor is followed by `t', then the stab defines both a
-type name and a tag.
-
- For example, the C++ code
-
- struct foo {int x;};
-
- can be represented as either
-
- .stabs "foo:T19=s4x:1,0,32;;",128,0,0,0 # 128 is N_LSYM
- .stabs "foo:t19",128,0,0,0
-
- or
-
- .stabs "foo:Tt19=s4x:1,0,32;;",128,0,0,0
-
-
-File: stabs.info, Node: Nested Symbols, Next: Basic Cplusplus Types, Prev: Class Names, Up: Cplusplus
-
-8.2 Defining a Symbol Within Another Type
-=========================================
-
-In C++, a symbol (such as a type name) can be defined within another
-type.
-
- In stabs, this is sometimes represented by making the name of a
-symbol which contains `::'. Such a pair of colons does not end the name
-of the symbol, the way a single colon would (*note String Field::). I'm
-not sure how consistently used or well thought out this mechanism is.
-So that a pair of colons in this position always has this meaning, `:'
-cannot be used as a symbol descriptor.
-
- For example, if the string for a stab is `foo::bar::baz:t5=*6', then
-`foo::bar::baz' is the name of the symbol, `t' is the symbol
-descriptor, and `5=*6' is the type information.
-
-
-File: stabs.info, Node: Basic Cplusplus Types, Next: Simple Classes, Prev: Nested Symbols, Up: Cplusplus
-
-8.3 Basic Types For C++
-=======================
-
-<< the examples that follow are based on a01.C >>
-
- C++ adds two more builtin types to the set defined for C. These are
-the unknown type and the vtable record type. The unknown type, type
-16, is defined in terms of itself like the void type.
-
- The vtable record type, type 17, is defined as a structure type and
-then as a structure tag. The structure has four fields: delta, index,
-pfn, and delta2. pfn is the function pointer.
-
- << In boilerplate $vtbl_ptr_type, what are the fields delta, index,
-and delta2 used for? >>
-
- This basic type is present in all C++ programs even if there are no
-virtual methods defined.
-
- .stabs "struct_name:sym_desc(type)type_def(17)=type_desc(struct)struct_bytes(8)
- elem_name(delta):type_ref(short int),bit_offset(0),field_bits(16);
- elem_name(index):type_ref(short int),bit_offset(16),field_bits(16);
- elem_name(pfn):type_def(18)=type_desc(ptr to)type_ref(void),
- bit_offset(32),field_bits(32);
- elem_name(delta2):type_def(short int);bit_offset(32),field_bits(16);;"
- N_LSYM, NIL, NIL
-
- .stabs "$vtbl_ptr_type:t17=s8
- delta:6,0,16;index:6,16,16;pfn:18=*15,32,32;delta2:6,32,16;;"
- ,128,0,0,0
-
- .stabs "name:sym_dec(struct tag)type_ref($vtbl_ptr_type)",N_LSYM,NIL,NIL,NIL
-
- .stabs "$vtbl_ptr_type:T17",128,0,0,0
-
-
-File: stabs.info, Node: Simple Classes, Next: Class Instance, Prev: Basic Cplusplus Types, Up: Cplusplus
-
-8.4 Simple Class Definition
-===========================
-
-The stabs describing C++ language features are an extension of the
-stabs describing C. Stabs representing C++ class types elaborate
-extensively on the stab format used to describe structure types in C.
-Stabs representing class type variables look just like stabs
-representing C language variables.
-
- Consider the following very simple class definition.
-
- class baseA {
- public:
- int Adat;
- int Ameth(int in, char other);
- };
-
- The class `baseA' is represented by two stabs. The first stab
-describes the class as a structure type. The second stab describes a
-structure tag of the class type. Both stabs are of stab type `N_LSYM'.
-Since the stab is not located between an `N_FUN' and an `N_LBRAC' stab
-this indicates that the class is defined at file scope. If it were,
-then the `N_LSYM' would signify a local variable.
-
- A stab describing a C++ class type is similar in format to a stab
-describing a C struct, with each class member shown as a field in the
-structure. The part of the struct format describing fields is expanded
-to include extra information relevant to C++ class members. In
-addition, if the class has multiple base classes or virtual functions
-the struct format outside of the field parts is also augmented.
-
- In this simple example the field part of the C++ class stab
-representing member data looks just like the field part of a C struct
-stab. The section on protections describes how its format is sometimes
-extended for member data.
-
- The field part of a C++ class stab representing a member function
-differs substantially from the field part of a C struct stab. It still
-begins with `name:' but then goes on to define a new type number for
-the member function, describe its return type, its argument types, its
-protection level, any qualifiers applied to the method definition, and
-whether the method is virtual or not. If the method is virtual then
-the method description goes on to give the vtable index of the method,
-and the type number of the first base class defining the method.
-
- When the field name is a method name it is followed by two colons
-rather than one. This is followed by a new type definition for the
-method. This is a number followed by an equal sign and the type of the
-method. Normally this will be a type declared using the `#' type
-descriptor; see *note Method Type Descriptor::; static member functions
-are declared using the `f' type descriptor instead; see *note Function
-Types::.
-
- The format of an overloaded operator method name differs from that of
-other methods. It is `op$::OPERATOR-NAME.' where OPERATOR-NAME is the
-operator name such as `+' or `+='. The name ends with a period, and
-any characters except the period can occur in the OPERATOR-NAME string.
-
- The next part of the method description represents the arguments to
-the method, preceded by a colon and ending with a semi-colon. The
-types of the arguments are expressed in the same way argument types are
-expressed in C++ name mangling. In this example an `int' and a `char'
-map to `ic'.
-
- This is followed by a number, a letter, and an asterisk or period,
-followed by another semicolon. The number indicates the protections
-that apply to the member function. Here the 2 means public. The
-letter encodes any qualifier applied to the method definition. In this
-case, `A' means that it is a normal function definition. The dot shows
-that the method is not virtual. The sections that follow elaborate
-further on these fields and describe the additional information present
-for virtual methods.
-
- .stabs "class_name:sym_desc(type)type_def(20)=type_desc(struct)struct_bytes(4)
- field_name(Adat):type(int),bit_offset(0),field_bits(32);
-
- method_name(Ameth)::type_def(21)=type_desc(method)return_type(int);
- :arg_types(int char);
- protection(public)qualifier(normal)virtual(no);;"
- N_LSYM,NIL,NIL,NIL
-
- .stabs "baseA:t20=s4Adat:1,0,32;Ameth::21=##1;:ic;2A.;;",128,0,0,0
-
- .stabs "class_name:sym_desc(struct tag)",N_LSYM,NIL,NIL,NIL
-
- .stabs "baseA:T20",128,0,0,0
-
-
-File: stabs.info, Node: Class Instance, Next: Methods, Prev: Simple Classes, Up: Cplusplus
-
-8.5 Class Instance
-==================
-
-As shown above, describing even a simple C++ class definition is
-accomplished by massively extending the stab format used in C to
-describe structure types. However, once the class is defined, C stabs
-with no modifications can be used to describe class instances. The
-following source:
-
- main () {
- baseA AbaseA;
- }
-
-yields the following stab describing the class instance. It looks no
-different from a standard C stab describing a local variable.
-
- .stabs "name:type_ref(baseA)", N_LSYM, NIL, NIL, frame_ptr_offset
-
- .stabs "AbaseA:20",128,0,0,-20
-
-
-File: stabs.info, Node: Methods, Next: Method Type Descriptor, Prev: Class Instance, Up: Cplusplus
-
-8.6 Method Definition
-=====================
-
-The class definition shown above declares Ameth. The C++ source below
-defines Ameth:
-
- int
- baseA::Ameth(int in, char other)
- {
- return in;
- };
-
- This method definition yields three stabs following the code of the
-method. One stab describes the method itself and following two describe
-its parameters. Although there is only one formal argument all methods
-have an implicit argument which is the `this' pointer. The `this'
-pointer is a pointer to the object on which the method was called. Note
-that the method name is mangled to encode the class name and argument
-types. Name mangling is described in the ARM (`The Annotated C++
-Reference Manual', by Ellis and Stroustrup, ISBN 0-201-51459-1);
-`gpcompare.texi' in Cygnus GCC distributions describes the differences
-between GNU mangling and ARM mangling.
-
- .stabs "name:symbol_descriptor(global function)return_type(int)",
- N_FUN, NIL, NIL, code_addr_of_method_start
-
- .stabs "Ameth__5baseAic:F1",36,0,0,_Ameth__5baseAic
-
- Here is the stab for the `this' pointer implicit argument. The name
-of the `this' pointer is always `this'. Type 19, the `this' pointer is
-defined as a pointer to type 20, `baseA', but a stab defining `baseA'
-has not yet been emitted. Since the compiler knows it will be emitted
-shortly, here it just outputs a cross reference to the undefined
-symbol, by prefixing the symbol name with `xs'.
-
- .stabs "name:sym_desc(register param)type_def(19)=
- type_desc(ptr to)type_ref(baseA)=
- type_desc(cross-reference to)baseA:",N_RSYM,NIL,NIL,register_number
-
- .stabs "this:P19=*20=xsbaseA:",64,0,0,8
-
- The stab for the explicit integer argument looks just like a
-parameter to a C function. The last field of the stab is the offset
-from the argument pointer, which in most systems is the same as the
-frame pointer.
-
- .stabs "name:sym_desc(value parameter)type_ref(int)",
- N_PSYM,NIL,NIL,offset_from_arg_ptr
-
- .stabs "in:p1",160,0,0,72
-
- << The examples that follow are based on A1.C >>
-
-
-File: stabs.info, Node: Method Type Descriptor, Next: Member Type Descriptor, Prev: Methods, Up: Cplusplus
-
-8.7 The `#' Type Descriptor
-===========================
-
-This is used to describe a class method. This is a function which takes
-an extra argument as its first argument, for the `this' pointer.
-
- If the `#' is immediately followed by another `#', the second one
-will be followed by the return type and a semicolon. The class and
-argument types are not specified, and must be determined by demangling
-the name of the method if it is available.
-
- Otherwise, the single `#' is followed by the class type, a comma,
-the return type, a comma, and zero or more parameter types separated by
-commas. The list of arguments is terminated by a semicolon. In the
-debugging output generated by gcc, a final argument type of `void'
-indicates a method which does not take a variable number of arguments.
-If the final argument type of `void' does not appear, the method was
-declared with an ellipsis.
-
- Note that although such a type will normally be used to describe
-fields in structures, unions, or classes, for at least some versions of
-the compiler it can also be used in other contexts.
-
-
-File: stabs.info, Node: Member Type Descriptor, Next: Protections, Prev: Method Type Descriptor, Up: Cplusplus
-
-8.8 The `@' Type Descriptor
-===========================
-
-The `@' type descriptor is used for a pointer-to-non-static-member-data
-type. It is followed by type information for the class (or union), a
-comma, and type information for the member data.
-
- The following C++ source:
-
- typedef int A::*int_in_a;
-
- generates the following stab:
-
- .stabs "int_in_a:t20=21=@19,1",128,0,0,0
-
- Note that there is a conflict between this and type attributes
-(*note String Field::); both use type descriptor `@'. Fortunately, the
-`@' type descriptor used in this C++ sense always will be followed by a
-digit, `(', or `-', and type attributes never start with those things.
-
-
-File: stabs.info, Node: Protections, Next: Method Modifiers, Prev: Member Type Descriptor, Up: Cplusplus
-
-8.9 Protections
-===============
-
-In the simple class definition shown above all member data and
-functions were publicly accessible. The example that follows contrasts
-public, protected and privately accessible fields and shows how these
-protections are encoded in C++ stabs.
-
- If the character following the `FIELD-NAME:' part of the string is
-`/', then the next character is the visibility. `0' means private, `1'
-means protected, and `2' means public. Debuggers should ignore
-visibility characters they do not recognize, and assume a reasonable
-default (such as public) (GDB 4.11 does not, but this should be fixed
-in the next GDB release). If no visibility is specified the field is
-public. The visibility `9' means that the field has been optimized out
-and is public (there is no way to specify an optimized out field with a
-private or protected visibility). Visibility `9' is not supported by
-GDB 4.11; this should be fixed in the next GDB release.
-
- The following C++ source:
-
- class vis {
- private:
- int priv;
- protected:
- char prot;
- public:
- float pub;
- };
-
-generates the following stab:
-
- # 128 is N_LSYM
- .stabs "vis:T19=s12priv:/01,0,32;prot:/12,32,8;pub:12,64,32;;",128,0,0,0
-
- `vis:T19=s12' indicates that type number 19 is a 12 byte structure
-named `vis' The `priv' field has public visibility (`/0'), type int
-(`1'), and offset and size `,0,32;'. The `prot' field has protected
-visibility (`/1'), type char (`2') and offset and size `,32,8;'. The
-`pub' field has type float (`12'), and offset and size `,64,32;'.
-
- Protections for member functions are signified by one digit embedded
-in the field part of the stab describing the method. The digit is 0 if
-private, 1 if protected and 2 if public. Consider the C++ class
-definition below:
-
- class all_methods {
- private:
- int priv_meth(int in){return in;};
- protected:
- char protMeth(char in){return in;};
- public:
- float pubMeth(float in){return in;};
- };
-
- It generates the following stab. The digit in question is to the
-left of an `A' in each case. Notice also that in this case two symbol
-descriptors apply to the class name struct tag and struct type.
-
- .stabs "class_name:sym_desc(struct tag&type)type_def(21)=
- sym_desc(struct)struct_bytes(1)
- meth_name::type_def(22)=sym_desc(method)returning(int);
- :args(int);protection(private)modifier(normal)virtual(no);
- meth_name::type_def(23)=sym_desc(method)returning(char);
- :args(char);protection(protected)modifier(normal)virtual(no);
- meth_name::type_def(24)=sym_desc(method)returning(float);
- :args(float);protection(public)modifier(normal)virtual(no);;",
- N_LSYM,NIL,NIL,NIL
-
- .stabs "all_methods:Tt21=s1priv_meth::22=##1;:i;0A.;protMeth::23=##2;:c;1A.;
- pubMeth::24=##12;:f;2A.;;",128,0,0,0
-
-
-File: stabs.info, Node: Method Modifiers, Next: Virtual Methods, Prev: Protections, Up: Cplusplus
-
-8.10 Method Modifiers (`const', `volatile', `const volatile')
-=============================================================
-
-<< based on a6.C >>
-
- In the class example described above all the methods have the normal
-modifier. This method modifier information is located just after the
-protection information for the method. This field has four possible
-character values. Normal methods use `A', const methods use `B',
-volatile methods use `C', and const volatile methods use `D'. Consider
-the class definition below:
-
- class A {
- public:
- int ConstMeth (int arg) const { return arg; };
- char VolatileMeth (char arg) volatile { return arg; };
- float ConstVolMeth (float arg) const volatile {return arg; };
- };
-
- This class is described by the following stab:
-
- .stabs "class(A):sym_desc(struct)type_def(20)=type_desc(struct)struct_bytes(1)
- meth_name(ConstMeth)::type_def(21)sym_desc(method)
- returning(int);:arg(int);protection(public)modifier(const)virtual(no);
- meth_name(VolatileMeth)::type_def(22)=sym_desc(method)
- returning(char);:arg(char);protection(public)modifier(volatile)virt(no)
- meth_name(ConstVolMeth)::type_def(23)=sym_desc(method)
- returning(float);:arg(float);protection(public)modifier(const volatile)
- virtual(no);;", ...
-
- .stabs "A:T20=s1ConstMeth::21=##1;:i;2B.;VolatileMeth::22=##2;:c;2C.;
- ConstVolMeth::23=##12;:f;2D.;;",128,0,0,0
-
-
-File: stabs.info, Node: Virtual Methods, Next: Inheritance, Prev: Method Modifiers, Up: Cplusplus
-
-8.11 Virtual Methods
-====================
-
-<< The following examples are based on a4.C >>
-
- The presence of virtual methods in a class definition adds additional
-data to the class description. The extra data is appended to the
-description of the virtual method and to the end of the class
-description. Consider the class definition below:
-
- class A {
- public:
- int Adat;
- virtual int A_virt (int arg) { return arg; };
- };
-
- This results in the stab below describing class A. It defines a new
-type (20) which is an 8 byte structure. The first field of the class
-struct is `Adat', an integer, starting at structure offset 0 and
-occupying 32 bits.
-
- The second field in the class struct is not explicitly defined by the
-C++ class definition but is implied by the fact that the class contains
-a virtual method. This field is the vtable pointer. The name of the
-vtable pointer field starts with `$vf' and continues with a type
-reference to the class it is part of. In this example the type
-reference for class A is 20 so the name of its vtable pointer field is
-`$vf20', followed by the usual colon.
-
- Next there is a type definition for the vtable pointer type (21).
-This is in turn defined as a pointer to another new type (22).
-
- Type 22 is the vtable itself, which is defined as an array, indexed
-by a range of integers between 0 and 1, and whose elements are of type
-17. Type 17 was the vtable record type defined by the boilerplate C++
-type definitions, as shown earlier.
-
- The bit offset of the vtable pointer field is 32. The number of bits
-in the field are not specified when the field is a vtable pointer.
-
- Next is the method definition for the virtual member function
-`A_virt'. Its description starts out using the same format as the
-non-virtual member functions described above, except instead of a dot
-after the `A' there is an asterisk, indicating that the function is
-virtual. Since is is virtual some addition information is appended to
-the end of the method description.
-
- The first number represents the vtable index of the method. This is
-a 32 bit unsigned number with the high bit set, followed by a
-semi-colon.
-
- The second number is a type reference to the first base class in the
-inheritance hierarchy defining the virtual member function. In this
-case the class stab describes a base class so the virtual function is
-not overriding any other definition of the method. Therefore the
-reference is to the type number of the class that the stab is
-describing (20).
-
- This is followed by three semi-colons. One marks the end of the
-current sub-section, one marks the end of the method field, and the
-third marks the end of the struct definition.
-
- For classes containing virtual functions the very last section of the
-string part of the stab holds a type reference to the first base class.
-This is preceded by `~%' and followed by a final semi-colon.
-
- .stabs "class_name(A):type_def(20)=sym_desc(struct)struct_bytes(8)
- field_name(Adat):type_ref(int),bit_offset(0),field_bits(32);
- field_name(A virt func ptr):type_def(21)=type_desc(ptr to)type_def(22)=
- sym_desc(array)index_type_ref(range of int from 0 to 1);
- elem_type_ref(vtbl elem type),
- bit_offset(32);
- meth_name(A_virt)::typedef(23)=sym_desc(method)returning(int);
- :arg_type(int),protection(public)normal(yes)virtual(yes)
- vtable_index(1);class_first_defining(A);;;~%first_base(A);",
- N_LSYM,NIL,NIL,NIL
-
- .stabs "A:t20=s8Adat:1,0,32;$vf20:21=*22=ar1;0;1;17,32;
- A_virt::23=##1;:i;2A*-2147483647;20;;;~%20;",128,0,0,0
-
-
-File: stabs.info, Node: Inheritance, Next: Virtual Base Classes, Prev: Virtual Methods, Up: Cplusplus
-
-8.12 Inheritance
-================
-
-Stabs describing C++ derived classes include additional sections that
-describe the inheritance hierarchy of the class. A derived class stab
-also encodes the number of base classes. For each base class it tells
-if the base class is virtual or not, and if the inheritance is private
-or public. It also gives the offset into the object of the portion of
-the object corresponding to each base class.
-
- This additional information is embedded in the class stab following
-the number of bytes in the struct. First the number of base classes
-appears bracketed by an exclamation point and a comma.
-
- Then for each base type there repeats a series: a virtual character,
-a visibility character, a number, a comma, another number, and a
-semi-colon.
-
- The virtual character is `1' if the base class is virtual and `0' if
-not. The visibility character is `2' if the derivation is public, `1'
-if it is protected, and `0' if it is private. Debuggers should ignore
-virtual or visibility characters they do not recognize, and assume a
-reasonable default (such as public and non-virtual) (GDB 4.11 does not,
-but this should be fixed in the next GDB release).
-
- The number following the virtual and visibility characters is the
-offset from the start of the object to the part of the object
-pertaining to the base class.
-
- After the comma, the second number is a type_descriptor for the base
-type. Finally a semi-colon ends the series, which repeats for each
-base class.
-
- The source below defines three base classes `A', `B', and `C' and
-the derived class `D'.
-
- class A {
- public:
- int Adat;
- virtual int A_virt (int arg) { return arg; };
- };
-
- class B {
- public:
- int B_dat;
- virtual int B_virt (int arg) {return arg; };
- };
-
- class C {
- public:
- int Cdat;
- virtual int C_virt (int arg) {return arg; };
- };
-
- class D : A, virtual B, public C {
- public:
- int Ddat;
- virtual int A_virt (int arg ) { return arg+1; };
- virtual int B_virt (int arg) { return arg+2; };
- virtual int C_virt (int arg) { return arg+3; };
- virtual int D_virt (int arg) { return arg; };
- };
-
- Class stabs similar to the ones described earlier are generated for
-each base class.
-
- .stabs "A:T20=s8Adat:1,0,32;$vf20:21=*22=ar1;0;1;17,32;
- A_virt::23=##1;:i;2A*-2147483647;20;;;~%20;",128,0,0,0
-
- .stabs "B:Tt25=s8Bdat:1,0,32;$vf25:21,32;B_virt::26=##1;
- :i;2A*-2147483647;25;;;~%25;",128,0,0,0
-
- .stabs "C:Tt28=s8Cdat:1,0,32;$vf28:21,32;C_virt::29=##1;
- :i;2A*-2147483647;28;;;~%28;",128,0,0,0
-
- In the stab describing derived class `D' below, the information about
-the derivation of this class is encoded as follows.
-
- .stabs "derived_class_name:symbol_descriptors(struct tag&type)=
- type_descriptor(struct)struct_bytes(32)!num_bases(3),
- base_virtual(no)inheritance_public(no)base_offset(0),
- base_class_type_ref(A);
- base_virtual(yes)inheritance_public(no)base_offset(NIL),
- base_class_type_ref(B);
- base_virtual(no)inheritance_public(yes)base_offset(64),
- base_class_type_ref(C); ...
-
- .stabs "D:Tt31=s32!3,000,20;100,25;0264,28;$vb25:24,128;Ddat:
- 1,160,32;A_virt::32=##1;:i;2A*-2147483647;20;;B_virt:
- :32:i;2A*-2147483647;25;;C_virt::32:i;2A*-2147483647;
- 28;;D_virt::32:i;2A*-2147483646;31;;;~%20;",128,0,0,0
-
-
-File: stabs.info, Node: Virtual Base Classes, Next: Static Members, Prev: Inheritance, Up: Cplusplus
-
-8.13 Virtual Base Classes
-=========================
-
-A derived class object consists of a concatenation in memory of the data
-areas defined by each base class, starting with the leftmost and ending
-with the rightmost in the list of base classes. The exception to this
-rule is for virtual inheritance. In the example above, class `D'
-inherits virtually from base class `B'. This means that an instance of
-a `D' object will not contain its own `B' part but merely a pointer to
-a `B' part, known as a virtual base pointer.
-
- In a derived class stab, the base offset part of the derivation
-information, described above, shows how the base class parts are
-ordered. The base offset for a virtual base class is always given as 0.
-Notice that the base offset for `B' is given as 0 even though `B' is
-not the first base class. The first base class `A' starts at offset 0.
-
- The field information part of the stab for class `D' describes the
-field which is the pointer to the virtual base class `B'. The vbase
-pointer name is `$vb' followed by a type reference to the virtual base
-class. Since the type id for `B' in this example is 25, the vbase
-pointer name is `$vb25'.
-
- .stabs "D:Tt31=s32!3,000,20;100,25;0264,28;$vb25:24,128;Ddat:1,
- 160,32;A_virt::32=##1;:i;2A*-2147483647;20;;B_virt::32:i;
- 2A*-2147483647;25;;C_virt::32:i;2A*-2147483647;28;;D_virt:
- :32:i;2A*-2147483646;31;;;~%20;",128,0,0,0
-
- Following the name and a semicolon is a type reference describing the
-type of the virtual base class pointer, in this case 24. Type 24 was
-defined earlier as the type of the `B' class `this' pointer. The
-`this' pointer for a class is a pointer to the class type.
-
- .stabs "this:P24=*25=xsB:",64,0,0,8
-
- Finally the field offset part of the vbase pointer field description
-shows that the vbase pointer is the first field in the `D' object,
-before any data fields defined by the class. The layout of a `D' class
-object is a follows, `Adat' at 0, the vtable pointer for `A' at 32,
-`Cdat' at 64, the vtable pointer for C at 96, the virtual base pointer
-for `B' at 128, and `Ddat' at 160.
-
-
-File: stabs.info, Node: Static Members, Prev: Virtual Base Classes, Up: Cplusplus
-
-8.14 Static Members
-===================
-
-The data area for a class is a concatenation of the space used by the
-data members of the class. If the class has virtual methods, a vtable
-pointer follows the class data. The field offset part of each field
-description in the class stab shows this ordering.
-
- << How is this reflected in stabs? See Cygnus bug #677 for some
-info. >>
-
-
-File: stabs.info, Node: Stab Types, Next: Symbol Descriptors, Prev: Cplusplus, Up: Top
-
-Appendix A Table of Stab Types
-******************************
-
-The following are all the possible values for the stab type field, for
-a.out files, in numeric order. This does not apply to XCOFF, but it
-does apply to stabs in sections (*note Stab Sections::). Stabs in
-ECOFF use these values but add 0x8f300 to distinguish them from non-stab
-symbols.
-
- The symbolic names are defined in the file `include/aout/stabs.def'.
-
-* Menu:
-
-* Non-Stab Symbol Types:: Types from 0 to 0x1f
-* Stab Symbol Types:: Types from 0x20 to 0xff
-
-
-File: stabs.info, Node: Non-Stab Symbol Types, Next: Stab Symbol Types, Up: Stab Types
-
-A.1 Non-Stab Symbol Types
-=========================
-
-The following types are used by the linker and assembler, not by stab
-directives. Since this document does not attempt to describe aspects of
-object file format other than the debugging format, no details are
-given.
-
-`0x0 N_UNDF'
- Undefined symbol
-
-`0x2 N_ABS'
- File scope absolute symbol
-
-`0x3 N_ABS | N_EXT'
- External absolute symbol
-
-`0x4 N_TEXT'
- File scope text symbol
-
-`0x5 N_TEXT | N_EXT'
- External text symbol
-
-`0x6 N_DATA'
- File scope data symbol
-
-`0x7 N_DATA | N_EXT'
- External data symbol
-
-`0x8 N_BSS'
- File scope BSS symbol
-
-`0x9 N_BSS | N_EXT'
- External BSS symbol
-
-`0x0c N_FN_SEQ'
- Same as `N_FN', for Sequent compilers
-
-`0x0a N_INDR'
- Symbol is indirected to another symbol
-
-`0x12 N_COMM'
- Common--visible after shared library dynamic link
-
-`0x14 N_SETA'
-`0x15 N_SETA | N_EXT'
- Absolute set element
-
-`0x16 N_SETT'
-`0x17 N_SETT | N_EXT'
- Text segment set element
-
-`0x18 N_SETD'
-`0x19 N_SETD | N_EXT'
- Data segment set element
-
-`0x1a N_SETB'
-`0x1b N_SETB | N_EXT'
- BSS segment set element
-
-`0x1c N_SETV'
-`0x1d N_SETV | N_EXT'
- Pointer to set vector
-
-`0x1e N_WARNING'
- Print a warning message during linking
-
-`0x1f N_FN'
- File name of a `.o' file
-
-
-File: stabs.info, Node: Stab Symbol Types, Prev: Non-Stab Symbol Types, Up: Stab Types
-
-A.2 Stab Symbol Types
-=====================
-
-The following symbol types indicate that this is a stab. This is the
-full list of stab numbers, including stab types that are used in
-languages other than C.
-
-`0x20 N_GSYM'
- Global symbol; see *note Global Variables::.
-
-`0x22 N_FNAME'
- Function name (for BSD Fortran); see *note Procedures::.
-
-`0x24 N_FUN'
- Function name (*note Procedures::) or text segment variable (*note
- Statics::).
-
-`0x26 N_STSYM'
- Data segment file-scope variable; see *note Statics::.
-
-`0x28 N_LCSYM'
- BSS segment file-scope variable; see *note Statics::.
-
-`0x2a N_MAIN'
- Name of main routine; see *note Main Program::.
-
-`0x2c N_ROSYM'
- Variable in `.rodata' section; see *note Statics::.
-
-`0x30 N_PC'
- Global symbol (for Pascal); see *note N_PC::.
-
-`0x32 N_NSYMS'
- Number of symbols (according to Ultrix V4.0); see *note N_NSYMS::.
-
-`0x34 N_NOMAP'
- No DST map; see *note N_NOMAP::.
-
-`0x36 N_MAC_DEFINE'
- Name and body of a `#define'd macro; see *note Macro define and
- undefine::.
-
-`0x38 N_OBJ'
- Object file (Solaris2).
-
-`0x3a N_MAC_UNDEF'
- Name of an `#undef'ed macro; see *note Macro define and undefine::.
-
-`0x3c N_OPT'
- Debugger options (Solaris2).
-
-`0x40 N_RSYM'
- Register variable; see *note Register Variables::.
-
-`0x42 N_M2C'
- Modula-2 compilation unit; see *note N_M2C::.
-
-`0x44 N_SLINE'
- Line number in text segment; see *note Line Numbers::.
-
-`0x46 N_DSLINE'
- Line number in data segment; see *note Line Numbers::.
-
-`0x48 N_BSLINE'
- Line number in bss segment; see *note Line Numbers::.
-
-`0x48 N_BROWS'
- Sun source code browser, path to `.cb' file; see *note N_BROWS::.
-
-`0x4a N_DEFD'
- GNU Modula2 definition module dependency; see *note N_DEFD::.
-
-`0x4c N_FLINE'
- Function start/body/end line numbers (Solaris2).
-
-`0x50 N_EHDECL'
- GNU C++ exception variable; see *note N_EHDECL::.
-
-`0x50 N_MOD2'
- Modula2 info "for imc" (according to Ultrix V4.0); see *note
- N_MOD2::.
-
-`0x54 N_CATCH'
- GNU C++ `catch' clause; see *note N_CATCH::.
-
-`0x60 N_SSYM'
- Structure of union element; see *note N_SSYM::.
-
-`0x62 N_ENDM'
- Last stab for module (Solaris2).
-
-`0x64 N_SO'
- Path and name of source file; see *note Source Files::.
-
-`0x80 N_LSYM'
- Stack variable (*note Stack Variables::) or type (*note
- Typedefs::).
-
-`0x82 N_BINCL'
- Beginning of an include file (Sun only); see *note Include Files::.
-
-`0x84 N_SOL'
- Name of include file; see *note Include Files::.
-
-`0xa0 N_PSYM'
- Parameter variable; see *note Parameters::.
-
-`0xa2 N_EINCL'
- End of an include file; see *note Include Files::.
-
-`0xa4 N_ENTRY'
- Alternate entry point; see *note Alternate Entry Points::.
-
-`0xc0 N_LBRAC'
- Beginning of a lexical block; see *note Block Structure::.
-
-`0xc2 N_EXCL'
- Place holder for a deleted include file; see *note Include Files::.
-
-`0xc4 N_SCOPE'
- Modula2 scope information (Sun linker); see *note N_SCOPE::.
-
-`0xe0 N_RBRAC'
- End of a lexical block; see *note Block Structure::.
-
-`0xe2 N_BCOMM'
- Begin named common block; see *note Common Blocks::.
-
-`0xe4 N_ECOMM'
- End named common block; see *note Common Blocks::.
-
-`0xe8 N_ECOML'
- Member of a common block; see *note Common Blocks::.
-
-`0xea N_WITH'
- Pascal `with' statement: type,,0,0,offset (Solaris2).
-
-`0xf0 N_NBTEXT'
- Gould non-base registers; see *note Gould::.
-
-`0xf2 N_NBDATA'
- Gould non-base registers; see *note Gould::.
-
-`0xf4 N_NBBSS'
- Gould non-base registers; see *note Gould::.
-
-`0xf6 N_NBSTS'
- Gould non-base registers; see *note Gould::.
-
-`0xf8 N_NBLCS'
- Gould non-base registers; see *note Gould::.
-
-
-File: stabs.info, Node: Symbol Descriptors, Next: Type Descriptors, Prev: Stab Types, Up: Top
-
-Appendix B Table of Symbol Descriptors
-**************************************
-
-The symbol descriptor is the character which follows the colon in many
-stabs, and which tells what kind of stab it is. *Note String Field::,
-for more information about their use.
-
-`DIGIT'
-`('
-`-'
- Variable on the stack; see *note Stack Variables::.
-
-`:'
- C++ nested symbol; see *Note Nested Symbols::.
-
-`a'
- Parameter passed by reference in register; see *note Reference
- Parameters::.
-
-`b'
- Based variable; see *note Based Variables::.
-
-`c'
- Constant; see *note Constants::.
-
-`C'
- Conformant array bound (Pascal, maybe other languages); *note
- Conformant Arrays::. Name of a caught exception (GNU C++). These
- can be distinguished because the latter uses `N_CATCH' and the
- former uses another symbol type.
-
-`d'
- Floating point register variable; see *note Register Variables::.
-
-`D'
- Parameter in floating point register; see *note Register
- Parameters::.
-
-`f'
- File scope function; see *note Procedures::.
-
-`F'
- Global function; see *note Procedures::.
-
-`G'
- Global variable; see *note Global Variables::.
-
-`i'
- *Note Register Parameters::.
-
-`I'
- Internal (nested) procedure; see *note Nested Procedures::.
-
-`J'
- Internal (nested) function; see *note Nested Procedures::.
-
-`L'
- Label name (documented by AIX, no further information known).
-
-`m'
- Module; see *note Procedures::.
-
-`p'
- Argument list parameter; see *note Parameters::.
-
-`pP'
- *Note Parameters::.
-
-`pF'
- Fortran Function parameter; see *note Parameters::.
-
-`P'
- Unfortunately, three separate meanings have been independently
- invented for this symbol descriptor. At least the GNU and Sun
- uses can be distinguished by the symbol type. Global Procedure
- (AIX) (symbol type used unknown); see *note Procedures::.
- Register parameter (GNU) (symbol type `N_PSYM'); see *note
- Parameters::. Prototype of function referenced by this file (Sun
- `acc') (symbol type `N_FUN').
-
-`Q'
- Static Procedure; see *note Procedures::.
-
-`R'
- Register parameter; see *note Register Parameters::.
-
-`r'
- Register variable; see *note Register Variables::.
-
-`S'
- File scope variable; see *note Statics::.
-
-`s'
- Local variable (OS9000).
-
-`t'
- Type name; see *note Typedefs::.
-
-`T'
- Enumeration, structure, or union tag; see *note Typedefs::.
-
-`v'
- Parameter passed by reference; see *note Reference Parameters::.
-
-`V'
- Procedure scope static variable; see *note Statics::.
-
-`x'
- Conformant array; see *note Conformant Arrays::.
-
-`X'
- Function return variable; see *note Parameters::.
-
-
-File: stabs.info, Node: Type Descriptors, Next: Expanded Reference, Prev: Symbol Descriptors, Up: Top
-
-Appendix C Table of Type Descriptors
-************************************
-
-The type descriptor is the character which follows the type number and
-an equals sign. It specifies what kind of type is being defined.
-*Note String Field::, for more information about their use.
-
-`DIGIT'
-`('
- Type reference; see *note String Field::.
-
-`-'
- Reference to builtin type; see *note Negative Type Numbers::.
-
-`#'
- Method (C++); see *note Method Type Descriptor::.
-
-`*'
- Pointer; see *note Miscellaneous Types::.
-
-`&'
- Reference (C++).
-
-`@'
- Type Attributes (AIX); see *note String Field::. Member (class
- and variable) type (GNU C++); see *note Member Type Descriptor::.
-
-`a'
- Array; see *note Arrays::.
-
-`A'
- Open array; see *note Arrays::.
-
-`b'
- Pascal space type (AIX); see *note Miscellaneous Types::. Builtin
- integer type (Sun); see *note Builtin Type Descriptors::. Const
- and volatile qualified type (OS9000).
-
-`B'
- Volatile-qualified type; see *note Miscellaneous Types::.
-
-`c'
- Complex builtin type (AIX); see *note Builtin Type Descriptors::.
- Const-qualified type (OS9000).
-
-`C'
- COBOL Picture type. See AIX documentation for details.
-
-`d'
- File type; see *note Miscellaneous Types::.
-
-`D'
- N-dimensional dynamic array; see *note Arrays::.
-
-`e'
- Enumeration type; see *note Enumerations::.
-
-`E'
- N-dimensional subarray; see *note Arrays::.
-
-`f'
- Function type; see *note Function Types::.
-
-`F'
- Pascal function parameter; see *note Function Types::
-
-`g'
- Builtin floating point type; see *note Builtin Type Descriptors::.
-
-`G'
- COBOL Group. See AIX documentation for details.
-
-`i'
- Imported type (AIX); see *note Cross-References::.
- Volatile-qualified type (OS9000).
-
-`k'
- Const-qualified type; see *note Miscellaneous Types::.
-
-`K'
- COBOL File Descriptor. See AIX documentation for details.
-
-`M'
- Multiple instance type; see *note Miscellaneous Types::.
-
-`n'
- String type; see *note Strings::.
-
-`N'
- Stringptr; see *note Strings::.
-
-`o'
- Opaque type; see *note Typedefs::.
-
-`p'
- Procedure; see *note Function Types::.
-
-`P'
- Packed array; see *note Arrays::.
-
-`r'
- Range type; see *note Subranges::.
-
-`R'
- Builtin floating type; see *note Builtin Type Descriptors:: (Sun).
- Pascal subroutine parameter; see *note Function Types:: (AIX).
- Detecting this conflict is possible with careful parsing (hint: a
- Pascal subroutine parameter type will always contain a comma, and
- a builtin type descriptor never will).
-
-`s'
- Structure type; see *note Structures::.
-
-`S'
- Set type; see *note Miscellaneous Types::.
-
-`u'
- Union; see *note Unions::.
-
-`v'
- Variant record. This is a Pascal and Modula-2 feature which is
- like a union within a struct in C. See AIX documentation for
- details.
-
-`w'
- Wide character; see *note Builtin Type Descriptors::.
-
-`x'
- Cross-reference; see *note Cross-References::.
-
-`Y'
- Used by IBM's xlC C++ compiler (for structures, I think).
-
-`z'
- gstring; see *note Strings::.
-
-
-File: stabs.info, Node: Expanded Reference, Next: Questions, Prev: Type Descriptors, Up: Top
-
-Appendix D Expanded Reference by Stab Type
-******************************************
-
-For a full list of stab types, and cross-references to where they are
-described, see *note Stab Types::. This appendix just covers certain
-stabs which are not yet described in the main body of this document;
-eventually the information will all be in one place.
-
- Format of an entry:
-
- The first line is the symbol type (see `include/aout/stab.def').
-
- The second line describes the language constructs the symbol type
-represents.
-
- The third line is the stab format with the significant stab fields
-named and the rest NIL.
-
- Subsequent lines expand upon the meaning and possible values for each
-significant stab field.
-
- Finally, any further information.
-
-* Menu:
-
-* N_PC:: Pascal global symbol
-* N_NSYMS:: Number of symbols
-* N_NOMAP:: No DST map
-* N_M2C:: Modula-2 compilation unit
-* N_BROWS:: Path to .cb file for Sun source code browser
-* N_DEFD:: GNU Modula2 definition module dependency
-* N_EHDECL:: GNU C++ exception variable
-* N_MOD2:: Modula2 information "for imc"
-* N_CATCH:: GNU C++ "catch" clause
-* N_SSYM:: Structure or union element
-* N_SCOPE:: Modula2 scope information (Sun only)
-* Gould:: non-base register symbols used on Gould systems
-* N_LENG:: Length of preceding entry
-
-
-File: stabs.info, Node: N_PC, Next: N_NSYMS, Up: Expanded Reference
-
-D.1 N_PC
-========
-
- -- `.stabs': N_PC
- Global symbol (for Pascal).
-
- "name" -> "symbol_name" <<?>>
- value -> supposedly the line number (stab.def is skeptical)
-
- `stabdump.c' says:
-
- global pascal symbol: name,,0,subtype,line
- << subtype? >>
-
-
-File: stabs.info, Node: N_NSYMS, Next: N_NOMAP, Prev: N_PC, Up: Expanded Reference
-
-D.2 N_NSYMS
-===========
-
- -- `.stabn': N_NSYMS
- Number of symbols (according to Ultrix V4.0).
-
- 0, files,,funcs,lines (stab.def)
-
-
-File: stabs.info, Node: N_NOMAP, Next: N_M2C, Prev: N_NSYMS, Up: Expanded Reference
-
-D.3 N_NOMAP
-===========
-
- -- `.stabs': N_NOMAP
- No DST map for symbol (according to Ultrix V4.0). I think this
- means a variable has been optimized out.
-
- name, ,0,type,ignored (stab.def)
-
-
-File: stabs.info, Node: N_M2C, Next: N_BROWS, Prev: N_NOMAP, Up: Expanded Reference
-
-D.4 N_M2C
-=========
-
- -- `.stabs': N_M2C
- Modula-2 compilation unit.
-
- "string" -> "unit_name,unit_time_stamp[,code_time_stamp]"
- desc -> unit_number
- value -> 0 (main unit)
- 1 (any other unit)
-
- See `Dbx and Dbxtool Interfaces', 2nd edition, by Sun, 1988, for
- more information.
-
-
-
-File: stabs.info, Node: N_BROWS, Next: N_DEFD, Prev: N_M2C, Up: Expanded Reference
-
-D.5 N_BROWS
-===========
-
- -- `.stabs': N_BROWS
- Sun source code browser, path to `.cb' file
-
- <<?>> "path to associated `.cb' file"
-
- Note: N_BROWS has the same value as N_BSLINE.
-
-
-File: stabs.info, Node: N_DEFD, Next: N_EHDECL, Prev: N_BROWS, Up: Expanded Reference
-
-D.6 N_DEFD
-==========
-
- -- `.stabn': N_DEFD
- GNU Modula2 definition module dependency.
-
- GNU Modula-2 definition module dependency. The value is the
- modification time of the definition file. The other field is
- non-zero if it is imported with the GNU M2 keyword `%INITIALIZE'.
- Perhaps `N_M2C' can be used if there are enough empty fields?
-
-
-File: stabs.info, Node: N_EHDECL, Next: N_MOD2, Prev: N_DEFD, Up: Expanded Reference
-
-D.7 N_EHDECL
-============
-
- -- `.stabs': N_EHDECL
- GNU C++ exception variable <<?>>.
-
- "STRING is variable name"
-
- Note: conflicts with `N_MOD2'.
-
-
-File: stabs.info, Node: N_MOD2, Next: N_CATCH, Prev: N_EHDECL, Up: Expanded Reference
-
-D.8 N_MOD2
-==========
-
- -- `.stab?': N_MOD2
- Modula2 info "for imc" (according to Ultrix V4.0)
-
- Note: conflicts with `N_EHDECL' <<?>>
-
-
-File: stabs.info, Node: N_CATCH, Next: N_SSYM, Prev: N_MOD2, Up: Expanded Reference
-
-D.9 N_CATCH
-===========
-
- -- `.stabn': N_CATCH
- GNU C++ `catch' clause
-
- GNU C++ `catch' clause. The value is its address. The desc field
- is nonzero if this entry is immediately followed by a `CAUGHT' stab
- saying what exception was caught. Multiple `CAUGHT' stabs means
- that multiple exceptions can be caught here. If desc is 0, it
- means all exceptions are caught here.
-
-
-File: stabs.info, Node: N_SSYM, Next: N_SCOPE, Prev: N_CATCH, Up: Expanded Reference
-
-D.10 N_SSYM
-===========
-
- -- `.stabn': N_SSYM
- Structure or union element.
-
- The value is the offset in the structure.
-
- <<?looking at structs and unions in C I didn't see these>>
-
-
-File: stabs.info, Node: N_SCOPE, Next: Gould, Prev: N_SSYM, Up: Expanded Reference
-
-D.11 N_SCOPE
-============
-
- -- `.stab?': N_SCOPE
- Modula2 scope information (Sun linker) <<?>>
-
-
-File: stabs.info, Node: Gould, Next: N_LENG, Prev: N_SCOPE, Up: Expanded Reference
-
-D.12 Non-base registers on Gould systems
-========================================
-
- -- `.stab?': N_NBTEXT
- -- `.stab?': N_NBDATA
- -- `.stab?': N_NBBSS
- -- `.stab?': N_NBSTS
- -- `.stab?': N_NBLCS
- These are used on Gould systems for non-base registers syms.
-
- However, the following values are not the values used by Gould;
- they are the values which GNU has been documenting for these
- values for a long time, without actually checking what Gould uses.
- I include these values only because perhaps some someone actually
- did something with the GNU information (I hope not, why GNU
- knowingly assigned wrong values to these in the header file is a
- complete mystery to me).
-
- 240 0xf0 N_NBTEXT ??
- 242 0xf2 N_NBDATA ??
- 244 0xf4 N_NBBSS ??
- 246 0xf6 N_NBSTS ??
- 248 0xf8 N_NBLCS ??
-
-
-File: stabs.info, Node: N_LENG, Prev: Gould, Up: Expanded Reference
-
-D.13 N_LENG
-===========
-
- -- `.stabn': N_LENG
- Second symbol entry containing a length-value for the preceding
- entry. The value is the length.
-
-
-File: stabs.info, Node: Questions, Next: Stab Sections, Prev: Expanded Reference, Up: Top
-
-Appendix E Questions and Anomalies
-**********************************
-
- * For GNU C stabs defining local and global variables (`N_LSYM' and
- `N_GSYM'), the desc field is supposed to contain the source line
- number on which the variable is defined. In reality the desc
- field is always 0. (This behavior is defined in `dbxout.c' and
- putting a line number in desc is controlled by `#ifdef
- WINNING_GDB', which defaults to false). GDB supposedly uses this
- information if you say `list VAR'. In reality, VAR can be a
- variable defined in the program and GDB says `function VAR not
- defined'.
-
- * In GNU C stabs, there seems to be no way to differentiate tag
- types: structures, unions, and enums (symbol descriptor `T') and
- typedefs (symbol descriptor `t') defined at file scope from types
- defined locally to a procedure or other more local scope. They
- all use the `N_LSYM' stab type. Types defined at procedure scope
- are emitted after the `N_RBRAC' of the preceding function and
- before the code of the procedure in which they are defined. This
- is exactly the same as types defined in the source file between
- the two procedure bodies. GDB over-compensates by placing all
- types in block #1, the block for symbols of file scope. This is
- true for default, `-ansi' and `-traditional' compiler options.
- (Bugs gcc/1063, gdb/1066.)
-
- * What ends the procedure scope? Is it the proc block's `N_RBRAC'
- or the next `N_FUN'? (I believe its the first.)
-
-
-File: stabs.info, Node: Stab Sections, Next: Symbol Types Index, Prev: Questions, Up: Top
-
-Appendix F Using Stabs in Their Own Sections
-********************************************
-
-Many object file formats allow tools to create object files with custom
-sections containing any arbitrary data. For any such object file
-format, stabs can be embedded in special sections. This is how stabs
-are used with ELF and SOM, and aside from ECOFF and XCOFF, is how stabs
-are used with COFF.
-
-* Menu:
-
-* Stab Section Basics:: How to embed stabs in sections
-* ELF Linker Relocation:: Sun ELF hacks
-
-
-File: stabs.info, Node: Stab Section Basics, Next: ELF Linker Relocation, Up: Stab Sections
-
-F.1 How to Embed Stabs in Sections
-==================================
-
-The assembler creates two custom sections, a section named `.stab'
-which contains an array of fixed length structures, one struct per stab,
-and a section named `.stabstr' containing all the variable length
-strings that are referenced by stabs in the `.stab' section. The byte
-order of the stabs binary data depends on the object file format. For
-ELF, it matches the byte order of the ELF file itself, as determined
-from the `EI_DATA' field in the `e_ident' member of the ELF header.
-For SOM, it is always big-endian (is this true??? FIXME). For COFF, it
-matches the byte order of the COFF headers. The meaning of the fields
-is the same as for a.out (*note Symbol Table Format::), except that the
-`n_strx' field is relative to the strings for the current compilation
-unit (which can be found using the synthetic N_UNDF stab described
-below), rather than the entire string table.
-
- The first stab in the `.stab' section for each compilation unit is
-synthetic, generated entirely by the assembler, with no corresponding
-`.stab' directive as input to the assembler. This stab contains the
-following fields:
-
-`n_strx'
- Offset in the `.stabstr' section to the source filename.
-
-`n_type'
- `N_UNDF'.
-
-`n_other'
- Unused field, always zero. This may eventually be used to hold
- overflows from the count in the `n_desc' field.
-
-`n_desc'
- Count of upcoming symbols, i.e., the number of remaining stabs for
- this source file.
-
-`n_value'
- Size of the string table fragment associated with this source
- file, in bytes.
-
- The `.stabstr' section always starts with a null byte (so that string
-offsets of zero reference a null string), followed by random length
-strings, each of which is null byte terminated.
-
- The ELF section header for the `.stab' section has its `sh_link'
-member set to the section number of the `.stabstr' section, and the
-`.stabstr' section has its ELF section header `sh_type' member set to
-`SHT_STRTAB' to mark it as a string table. SOM and COFF have no way of
-linking the sections together or marking them as string tables.
-
- For COFF, the `.stab' and `.stabstr' sections may be simply
-concatenated by the linker. GDB then uses the `n_desc' fields to
-figure out the extent of the original sections. Similarly, the
-`n_value' fields of the header symbols are added together in order to
-get the actual position of the strings in a desired `.stabstr' section.
-Although this design obviates any need for the linker to relocate or
-otherwise manipulate `.stab' and `.stabstr' sections, it also requires
-some care to ensure that the offsets are calculated correctly. For
-instance, if the linker were to pad in between the `.stabstr' sections
-before concatenating, then the offsets to strings in the middle of the
-executable's `.stabstr' section would be wrong.
-
- The GNU linker is able to optimize stabs information by merging
-duplicate strings and removing duplicate header file information (*note
-Include Files::). When some versions of the GNU linker optimize stabs
-in sections, they remove the leading `N_UNDF' symbol and arranges for
-all the `n_strx' fields to be relative to the start of the `.stabstr'
-section.
-
-
-File: stabs.info, Node: ELF Linker Relocation, Prev: Stab Section Basics, Up: Stab Sections
-
-F.2 Having the Linker Relocate Stabs in ELF
-===========================================
-
-This section describes some Sun hacks for Stabs in ELF; it does not
-apply to COFF or SOM.
-
- To keep linking fast, you don't want the linker to have to relocate
-very many stabs. Making sure this is done for `N_SLINE', `N_RBRAC',
-and `N_LBRAC' stabs is the most important thing (see the descriptions
-of those stabs for more information). But Sun's stabs in ELF has taken
-this further, to make all addresses in the `n_value' field (functions
-and static variables) relative to the source file. For the `N_SO'
-symbol itself, Sun simply omits the address. To find the address of
-each section corresponding to a given source file, the compiler puts
-out symbols giving the address of each section for a given source file.
-Since these are ELF (not stab) symbols, the linker relocates them
-correctly without having to touch the stabs section. They are named
-`Bbss.bss' for the bss section, `Ddata.data' for the data section, and
-`Drodata.rodata' for the rodata section. For the text section, there
-is no such symbol (but there should be, see below). For an example of
-how these symbols work, *Note Stab Section Transformations::. GCC does
-not provide these symbols; it instead relies on the stabs getting
-relocated. Thus addresses which would normally be relative to
-`Bbss.bss', etc., are already relocated. The Sun linker provided with
-Solaris 2.2 and earlier relocates stabs using normal ELF relocation
-information, as it would do for any section. Sun has been threatening
-to kludge their linker to not do this (to speed up linking), even
-though the correct way to avoid having the linker do these relocations
-is to have the compiler no longer output relocatable values. Last I
-heard they had been talked out of the linker kludge. See Sun point
-patch 101052-01 and Sun bug 1142109. With the Sun compiler this
-affects `S' symbol descriptor stabs (*note Statics::) and functions
-(*note Procedures::). In the latter case, to adopt the clean solution
-(making the value of the stab relative to the start of the compilation
-unit), it would be necessary to invent a `Ttext.text' symbol, analogous
-to the `Bbss.bss', etc., symbols. I recommend this rather than using a
-zero value and getting the address from the ELF symbols.
-
- Finding the correct `Bbss.bss', etc., symbol is difficult, because
-the linker simply concatenates the `.stab' sections from each `.o' file
-without including any information about which part of a `.stab' section
-comes from which `.o' file. The way GDB does this is to look for an
-ELF `STT_FILE' symbol which has the same name as the last component of
-the file name from the `N_SO' symbol in the stabs (for example, if the
-file name is `../../gdb/main.c', it looks for an ELF `STT_FILE' symbol
-named `main.c'). This loses if different files have the same name
-(they could be in different directories, a library could have been
-copied from one system to another, etc.). It would be much cleaner to
-have the `Bbss.bss' symbols in the stabs themselves. Having the linker
-relocate them there is no more work than having the linker relocate ELF
-symbols, and it solves the problem of having to associate the ELF and
-stab symbols. However, no one has yet designed or implemented such a
-scheme.
-
-
-File: stabs.info, Node: GNU Free Documentation License, Prev: Symbol Types Index, Up: Top
-
-Appendix G GNU Free Documentation License
-*****************************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: stabs.info, Node: Symbol Types Index, Next: GNU Free Documentation License, Prev: Stab Sections, Up: Top
-
-Symbol Types Index
-******************
-
-
-* Menu:
-
-* .bb: Block Structure. (line 26)
-* .be: Block Structure. (line 26)
-* C_BCOMM: Common Blocks. (line 10)
-* C_BINCL: Include Files. (line 41)
-* C_BLOCK: Block Structure. (line 26)
-* C_BSTAT: Statics. (line 31)
-* C_DECL, for types: Typedefs. (line 6)
-* C_ECOML: Common Blocks. (line 17)
-* C_ECOMM: Common Blocks. (line 10)
-* C_EINCL: Include Files. (line 41)
-* C_ENTRY: Alternate Entry Points.
- (line 6)
-* C_ESTAT: Statics. (line 31)
-* C_FILE: Source Files. (line 61)
-* C_FUN: Procedures. (line 18)
-* C_GSYM: Global Variables. (line 6)
-* C_LSYM: Stack Variables. (line 11)
-* C_PSYM: Parameters. (line 12)
-* C_RPSYM: Register Parameters. (line 15)
-* C_RSYM: Register Variables. (line 6)
-* C_STSYM: Statics. (line 31)
-* N_BCOMM: Common Blocks. (line 10)
-* N_BINCL: Include Files. (line 17)
-* N_BROWS: N_BROWS. (line 7)
-* N_BSLINE: Line Numbers. (line 12)
-* N_CATCH: N_CATCH. (line 7)
-* N_DEFD: N_DEFD. (line 7)
-* N_DSLINE: Line Numbers. (line 12)
-* N_ECOML: Common Blocks. (line 17)
-* N_ECOMM: Common Blocks. (line 10)
-* N_EHDECL: N_EHDECL. (line 7)
-* N_EINCL: Include Files. (line 17)
-* N_ENTRY: Alternate Entry Points.
- (line 6)
-* N_EXCL: Include Files. (line 17)
-* N_FNAME: Procedures. (line 6)
-* N_FUN, for functions: Procedures. (line 6)
-* N_FUN, for variables: Statics. (line 12)
-* N_GSYM: Global Variables. (line 6)
-* N_GSYM, for functions (Sun acc): Procedures. (line 6)
-* N_LBRAC: Block Structure. (line 6)
-* N_LCSYM: Statics. (line 12)
-* N_LENG: N_LENG. (line 7)
-* N_LSYM, for parameter: Local Variable Parameters.
- (line 35)
-* N_LSYM, for stack variables: Stack Variables. (line 11)
-* N_LSYM, for types: Typedefs. (line 6)
-* N_M2C: N_M2C. (line 7)
-* N_MAC_DEFINE: Macro define and undefine.
- (line 11)
-* N_MAC_UNDEF: Macro define and undefine.
- (line 14)
-* N_MAIN: Main Program. (line 6)
-* N_MOD2: N_MOD2. (line 7)
-* N_NBBSS: Gould. (line 9)
-* N_NBDATA: Gould. (line 8)
-* N_NBLCS: Gould. (line 11)
-* N_NBSTS: Gould. (line 10)
-* N_NBTEXT: Gould. (line 7)
-* N_NOMAP: N_NOMAP. (line 7)
-* N_NSYMS: N_NSYMS. (line 7)
-* N_PC: N_PC. (line 7)
-* N_PSYM: Parameters. (line 12)
-* N_RBRAC: Block Structure. (line 6)
-* N_ROSYM: Statics. (line 12)
-* N_RSYM: Register Variables. (line 6)
-* N_RSYM, for parameters: Register Parameters. (line 15)
-* N_SCOPE: N_SCOPE. (line 7)
-* N_SLINE: Line Numbers. (line 6)
-* N_SO: Source Files. (line 6)
-* N_SOL: Include Files. (line 11)
-* N_SSYM: N_SSYM. (line 7)
-* N_STSYM: Statics. (line 12)
-* N_STSYM, for functions (Sun acc): Procedures. (line 6)
-
-
-
-Tag Table:
-Node: Top1620
-Node: Overview2667
-Node: Flow4082
-Node: Stabs Format5608
-Node: String Field7170
-Node: C Example12601
-Node: Assembly Code13146
-Node: Program Structure15117
-Node: Main Program15843
-Node: Source Files16404
-Node: Include Files18856
-Node: Line Numbers21521
-Node: Procedures23055
-Node: Nested Procedures28945
-Node: Block Structure30121
-Node: Alternate Entry Points31527
-Node: Constants32260
-Node: Variables35372
-Node: Stack Variables36060
-Node: Global Variables37761
-Node: Register Variables38917
-Node: Common Blocks39739
-Node: Statics40993
-Node: Based Variables43572
-Node: Parameters44957
-Node: Register Parameters46569
-Node: Local Variable Parameters48830
-Node: Reference Parameters51745
-Node: Conformant Arrays52365
-Node: Types53082
-Node: Builtin Types54029
-Node: Traditional Builtin Types55175
-Node: Traditional Integer Types55576
-Node: Traditional Other Types57884
-Node: Builtin Type Descriptors58798
-Node: Negative Type Numbers62298
-Node: Miscellaneous Types68653
-Node: Cross-References70539
-Node: Subranges72214
-Node: Arrays73453
-Node: Strings76678
-Node: Enumerations77740
-Node: Structures80125
-Node: Typedefs82832
-Node: Unions84156
-Node: Function Types85737
-Node: Macro define and undefine87319
-Node: Symbol Tables88896
-Node: Symbol Table Format89348
-Node: Transformations On Symbol Tables90796
-Node: Transformations On Static Variables92150
-Node: Transformations On Global Variables92886
-Node: Stab Section Transformations94129
-Node: Cplusplus95512
-Node: Class Names96095
-Node: Nested Symbols96840
-Node: Basic Cplusplus Types97686
-Node: Simple Classes99246
-Node: Class Instance103540
-Node: Methods104257
-Node: Method Type Descriptor106476
-Node: Member Type Descriptor107676
-Node: Protections108468
-Node: Method Modifiers111558
-Node: Virtual Methods113186
-Node: Inheritance116987
-Node: Virtual Base Classes120683
-Node: Static Members122927
-Node: Stab Types123397
-Node: Non-Stab Symbol Types124021
-Node: Stab Symbol Types125452
-Node: Symbol Descriptors129383
-Node: Type Descriptors132162
-Node: Expanded Reference135374
-Node: N_PC136792
-Node: N_NSYMS137160
-Node: N_NOMAP137401
-Node: N_M2C137707
-Node: N_BROWS138141
-Node: N_DEFD138424
-Node: N_EHDECL138881
-Node: N_MOD2139132
-Node: N_CATCH139370
-Node: N_SSYM139864
-Node: N_SCOPE140149
-Node: Gould140339
-Node: N_LENG141331
-Node: Questions141559
-Node: Stab Sections143203
-Node: Stab Section Basics143801
-Node: ELF Linker Relocation147142
-Node: GNU Free Documentation License150552
-Node: Symbol Types Index175709
-
-End Tag Table
diff --git a/share/info/standards.info b/share/info/standards.info
deleted file mode 100644
index 7bf77fe..0000000
--- a/share/info/standards.info
+++ /dev/null
@@ -1,5744 +0,0 @@
-This is standards.info, produced by makeinfo version 4.13 from
-/Volumes/androidtc/androidtoolchain/./src/build/../gdb/gdb-7.3.x/etc/standards.texi.
-
-INFO-DIR-SECTION GNU organization
-START-INFO-DIR-ENTRY
-* Standards: (standards). GNU coding standards.
-END-INFO-DIR-ENTRY
-
- The GNU coding standards, last updated April 12, 2010.
-
- Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
-Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
-
-File: standards.info, Node: Top, Next: Preface, Prev: (dir), Up: (dir)
-
-Version
-*******
-
-The GNU coding standards, last updated April 12, 2010.
-
- Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
-Foundation, Inc.
-
- Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled "GNU
-Free Documentation License".
-
-* Menu:
-
-* Preface:: About the GNU Coding Standards.
-* Legal Issues:: Keeping free software free.
-* Design Advice:: General program design.
-* Program Behavior:: Program behavior for all programs
-* Writing C:: Making the best use of C.
-* Documentation:: Documenting programs.
-* Managing Releases:: The release process.
-* References:: Mentioning non-free software or documentation.
-* GNU Free Documentation License:: Copying and sharing this manual.
-* Index::
-
-
-File: standards.info, Node: Preface, Next: Legal Issues, Prev: Top, Up: Top
-
-1 About the GNU Coding Standards
-********************************
-
-The GNU Coding Standards were written by Richard Stallman and other GNU
-Project volunteers. Their purpose is to make the GNU system clean,
-consistent, and easy to install. This document can also be read as a
-guide to writing portable, robust and reliable programs. It focuses on
-programs written in C, but many of the rules and principles are useful
-even if you write in another programming language. The rules often
-state reasons for writing in a certain way.
-
- If you did not obtain this file directly from the GNU project and
-recently, please check for a newer version. You can get the GNU Coding
-Standards from the GNU web server in many different formats, including
-the Texinfo source, PDF, HTML, DVI, plain text, and more, at:
-`http://www.gnu.org/prep/standards/'.
-
- If you are maintaining an official GNU package, in addition to this
-document, please read and follow the GNU maintainer information (*note
-Contents: (maintain)Top.).
-
- If you want to receive diffs for every change to these GNU documents,
-join the mailing list `gnustandards-commit@gnu.org', via the web
-interface at
-`http://lists.gnu.org/mailman/listinfo/gnustandards-commit'. Archives
-are also available there.
-
- Please send corrections or suggestions for this document to
-<bug-standards@gnu.org>. If you make a suggestion, please include a
-suggested new wording for it, to help us consider the suggestion
-efficiently. We prefer a context diff to the Texinfo source, but if
-that's difficult for you, you can make a context diff for some other
-version of this document, or propose it in any way that makes it clear.
-The source repository for this document can be found at
-`http://savannah.gnu.org/projects/gnustandards'.
-
- These standards cover the minimum of what is important when writing a
-GNU package. Likely, the need for additional standards will come up.
-Sometimes, you might suggest that such standards be added to this
-document. If you think your standards would be generally useful, please
-do suggest them.
-
- You should also set standards for your package on many questions not
-addressed or not firmly specified here. The most important point is to
-be self-consistent--try to stick to the conventions you pick, and try
-to document them as much as possible. That way, your program will be
-more maintainable by others.
-
- The GNU Hello program serves as an example of how to follow the GNU
-coding standards for a trivial program.
-`http://www.gnu.org/software/hello/hello.html'.
-
- This release of the GNU Coding Standards was last updated April 12,
-2010.
-
-
-File: standards.info, Node: Legal Issues, Next: Design Advice, Prev: Preface, Up: Top
-
-2 Keeping Free Software Free
-****************************
-
-This chapter discusses how you can make sure that GNU software avoids
-legal difficulties, and other related issues.
-
-* Menu:
-
-* Reading Non-Free Code:: Referring to proprietary programs.
-* Contributions:: Accepting contributions.
-* Trademarks:: How we deal with trademark issues.
-
-
-File: standards.info, Node: Reading Non-Free Code, Next: Contributions, Up: Legal Issues
-
-2.1 Referring to Proprietary Programs
-=====================================
-
-Don't in any circumstances refer to Unix source code for or during your
-work on GNU! (Or to any other proprietary programs.)
-
- If you have a vague recollection of the internals of a Unix program,
-this does not absolutely mean you can't write an imitation of it, but
-do try to organize the imitation internally along different lines,
-because this is likely to make the details of the Unix version
-irrelevant and dissimilar to your results.
-
- For example, Unix utilities were generally optimized to minimize
-memory use; if you go for speed instead, your program will be very
-different. You could keep the entire input file in memory and scan it
-there instead of using stdio. Use a smarter algorithm discovered more
-recently than the Unix program. Eliminate use of temporary files. Do
-it in one pass instead of two (we did this in the assembler).
-
- Or, on the contrary, emphasize simplicity instead of speed. For some
-applications, the speed of today's computers makes simpler algorithms
-adequate.
-
- Or go for generality. For example, Unix programs often have static
-tables or fixed-size strings, which make for arbitrary limits; use
-dynamic allocation instead. Make sure your program handles NULs and
-other funny characters in the input files. Add a programming language
-for extensibility and write part of the program in that language.
-
- Or turn some parts of the program into independently usable
-libraries. Or use a simple garbage collector instead of tracking
-precisely when to free memory, or use a new GNU facility such as
-obstacks.
-
-
-File: standards.info, Node: Contributions, Next: Trademarks, Prev: Reading Non-Free Code, Up: Legal Issues
-
-2.2 Accepting Contributions
-===========================
-
-If the program you are working on is copyrighted by the Free Software
-Foundation, then when someone else sends you a piece of code to add to
-the program, we need legal papers to use it--just as we asked you to
-sign papers initially. _Each_ person who makes a nontrivial
-contribution to a program must sign some sort of legal papers in order
-for us to have clear title to the program; the main author alone is not
-enough.
-
- So, before adding in any contributions from other people, please tell
-us, so we can arrange to get the papers. Then wait until we tell you
-that we have received the signed papers, before you actually use the
-contribution.
-
- This applies both before you release the program and afterward. If
-you receive diffs to fix a bug, and they make significant changes, we
-need legal papers for that change.
-
- This also applies to comments and documentation files. For copyright
-law, comments and code are just text. Copyright applies to all kinds of
-text, so we need legal papers for all kinds.
-
- We know it is frustrating to ask for legal papers; it's frustrating
-for us as well. But if you don't wait, you are going out on a limb--for
-example, what if the contributor's employer won't sign a disclaimer?
-You might have to take that code out again!
-
- You don't need papers for changes of a few lines here or there, since
-they are not significant for copyright purposes. Also, you don't need
-papers if all you get from the suggestion is some ideas, not actual code
-which you use. For example, if someone sent you one implementation, but
-you write a different implementation of the same idea, you don't need to
-get papers.
-
- The very worst thing is if you forget to tell us about the other
-contributor. We could be very embarrassed in court some day as a
-result.
-
- We have more detailed advice for maintainers of programs; if you have
-reached the stage of actually maintaining a program for GNU (whether
-released or not), please ask us for a copy. It is also available
-online for your perusal: `http://www.gnu.org/prep/maintain/'.
-
-
-File: standards.info, Node: Trademarks, Prev: Contributions, Up: Legal Issues
-
-2.3 Trademarks
-==============
-
-Please do not include any trademark acknowledgements in GNU software
-packages or documentation.
-
- Trademark acknowledgements are the statements that such-and-such is a
-trademark of so-and-so. The GNU Project has no objection to the basic
-idea of trademarks, but these acknowledgements feel like kowtowing, and
-there is no legal requirement for them, so we don't use them.
-
- What is legally required, as regards other people's trademarks, is to
-avoid using them in ways which a reader might reasonably understand as
-naming or labeling our own programs or activities. For example, since
-"Objective C" is (or at least was) a trademark, we made sure to say
-that we provide a "compiler for the Objective C language" rather than
-an "Objective C compiler". The latter would have been meant as a
-shorter way of saying the former, but it does not explicitly state the
-relationship, so it could be misinterpreted as using "Objective C" as a
-label for the compiler rather than for the language.
-
- Please don't use "win" as an abbreviation for Microsoft Windows in
-GNU software or documentation. In hacker terminology, calling
-something a "win" is a form of praise. If you wish to praise Microsoft
-Windows when speaking on your own, by all means do so, but not in GNU
-software. Usually we write the name "Windows" in full, but when
-brevity is very important (as in file names and sometimes symbol
-names), we abbreviate it to "w". For instance, the files and functions
-in Emacs that deal with Windows start with `w32'.
-
-
-File: standards.info, Node: Design Advice, Next: Program Behavior, Prev: Legal Issues, Up: Top
-
-3 General Program Design
-************************
-
-This chapter discusses some of the issues you should take into account
-when designing your program.
-
-* Menu:
-
-* Source Language:: Which languages to use.
-* Compatibility:: Compatibility with other implementations.
-* Using Extensions:: Using non-standard features.
-* Standard C:: Using standard C features.
-* Conditional Compilation:: Compiling code only if a conditional is true.
-
-
-File: standards.info, Node: Source Language, Next: Compatibility, Up: Design Advice
-
-3.1 Which Languages to Use
-==========================
-
-When you want to use a language that gets compiled and runs at high
-speed, the best language to use is C. Using another language is like
-using a non-standard feature: it will cause trouble for users. Even if
-GCC supports the other language, users may find it inconvenient to have
-to install the compiler for that other language in order to build your
-program. For example, if you write your program in C++, people will
-have to install the GNU C++ compiler in order to compile your program.
-
- C has one other advantage over C++ and other compiled languages: more
-people know C, so more people will find it easy to read and modify the
-program if it is written in C.
-
- So in general it is much better to use C, rather than the comparable
-alternatives.
-
- But there are two exceptions to that conclusion:
-
- * It is no problem to use another language to write a tool
- specifically intended for use with that language. That is because
- the only people who want to build the tool will be those who have
- installed the other language anyway.
-
- * If an application is of interest only to a narrow part of the
- community, then the question of which language it is written in
- has less effect on other people, so you may as well please
- yourself.
-
- Many programs are designed to be extensible: they include an
-interpreter for a language that is higher level than C. Often much of
-the program is written in that language, too. The Emacs editor
-pioneered this technique.
-
- The standard extensibility interpreter for GNU software is Guile
-(`http://www.gnu.org/software/guile/'), which implements the language
-Scheme (an especially clean and simple dialect of Lisp). Guile also
-includes bindings for GTK+/GNOME, making it practical to write modern
-GUI functionality within Guile. We don't reject programs written in
-other "scripting languages" such as Perl and Python, but using Guile is
-very important for the overall consistency of the GNU system.
-
-
-File: standards.info, Node: Compatibility, Next: Using Extensions, Prev: Source Language, Up: Design Advice
-
-3.2 Compatibility with Other Implementations
-============================================
-
-With occasional exceptions, utility programs and libraries for GNU
-should be upward compatible with those in Berkeley Unix, and upward
-compatible with Standard C if Standard C specifies their behavior, and
-upward compatible with POSIX if POSIX specifies their behavior.
-
- When these standards conflict, it is useful to offer compatibility
-modes for each of them.
-
- Standard C and POSIX prohibit many kinds of extensions. Feel free
-to make the extensions anyway, and include a `--ansi', `--posix', or
-`--compatible' option to turn them off. However, if the extension has
-a significant chance of breaking any real programs or scripts, then it
-is not really upward compatible. So you should try to redesign its
-interface to make it upward compatible.
-
- Many GNU programs suppress extensions that conflict with POSIX if the
-environment variable `POSIXLY_CORRECT' is defined (even if it is
-defined with a null value). Please make your program recognize this
-variable if appropriate.
-
- When a feature is used only by users (not by programs or command
-files), and it is done poorly in Unix, feel free to replace it
-completely with something totally different and better. (For example,
-`vi' is replaced with Emacs.) But it is nice to offer a compatible
-feature as well. (There is a free `vi' clone, so we offer it.)
-
- Additional useful features are welcome regardless of whether there
-is any precedent for them.
-
-
-File: standards.info, Node: Using Extensions, Next: Standard C, Prev: Compatibility, Up: Design Advice
-
-3.3 Using Non-standard Features
-===============================
-
-Many GNU facilities that already exist support a number of convenient
-extensions over the comparable Unix facilities. Whether to use these
-extensions in implementing your program is a difficult question.
-
- On the one hand, using the extensions can make a cleaner program.
-On the other hand, people will not be able to build the program unless
-the other GNU tools are available. This might cause the program to
-work on fewer kinds of machines.
-
- With some extensions, it might be easy to provide both alternatives.
-For example, you can define functions with a "keyword" `INLINE' and
-define that as a macro to expand into either `inline' or nothing,
-depending on the compiler.
-
- In general, perhaps it is best not to use the extensions if you can
-straightforwardly do without them, but to use the extensions if they
-are a big improvement.
-
- An exception to this rule are the large, established programs (such
-as Emacs) which run on a great variety of systems. Using GNU
-extensions in such programs would make many users unhappy, so we don't
-do that.
-
- Another exception is for programs that are used as part of
-compilation: anything that must be compiled with other compilers in
-order to bootstrap the GNU compilation facilities. If these require
-the GNU compiler, then no one can compile them without having them
-installed already. That would be extremely troublesome in certain
-cases.
-
-
-File: standards.info, Node: Standard C, Next: Conditional Compilation, Prev: Using Extensions, Up: Design Advice
-
-3.4 Standard C and Pre-Standard C
-=================================
-
-1989 Standard C is widespread enough now that it is ok to use its
-features in new programs. There is one exception: do not ever use the
-"trigraph" feature of Standard C.
-
- 1999 Standard C is not widespread yet, so please do not require its
-features in programs. It is ok to use its features if they are present.
-
- However, it is easy to support pre-standard compilers in most
-programs, so if you know how to do that, feel free. If a program you
-are maintaining has such support, you should try to keep it working.
-
- To support pre-standard C, instead of writing function definitions in
-standard prototype form,
-
- int
- foo (int x, int y)
- ...
-
-write the definition in pre-standard style like this,
-
- int
- foo (x, y)
- int x, y;
- ...
-
-and use a separate declaration to specify the argument prototype:
-
- int foo (int, int);
-
- You need such a declaration anyway, in a header file, to get the
-benefit of prototypes in all the files where the function is called.
-And once you have the declaration, you normally lose nothing by writing
-the function definition in the pre-standard style.
-
- This technique does not work for integer types narrower than `int'.
-If you think of an argument as being of a type narrower than `int',
-declare it as `int' instead.
-
- There are a few special cases where this technique is hard to use.
-For example, if a function argument needs to hold the system type
-`dev_t', you run into trouble, because `dev_t' is shorter than `int' on
-some machines; but you cannot use `int' instead, because `dev_t' is
-wider than `int' on some machines. There is no type you can safely use
-on all machines in a non-standard definition. The only way to support
-non-standard C and pass such an argument is to check the width of
-`dev_t' using Autoconf and choose the argument type accordingly. This
-may not be worth the trouble.
-
- In order to support pre-standard compilers that do not recognize
-prototypes, you may want to use a preprocessor macro like this:
-
- /* Declare the prototype for a general external function. */
- #if defined (__STDC__) || defined (WINDOWSNT)
- #define P_(proto) proto
- #else
- #define P_(proto) ()
- #endif
-
-
-File: standards.info, Node: Conditional Compilation, Prev: Standard C, Up: Design Advice
-
-3.5 Conditional Compilation
-===========================
-
-When supporting configuration options already known when building your
-program we prefer using `if (... )' over conditional compilation, as in
-the former case the compiler is able to perform more extensive checking
-of all possible code paths.
-
- For example, please write
-
- if (HAS_FOO)
- ...
- else
- ...
-
-instead of:
-
- #ifdef HAS_FOO
- ...
- #else
- ...
- #endif
-
- A modern compiler such as GCC will generate exactly the same code in
-both cases, and we have been using similar techniques with good success
-in several projects. Of course, the former method assumes that
-`HAS_FOO' is defined as either 0 or 1.
-
- While this is not a silver bullet solving all portability problems,
-and is not always appropriate, following this policy would have saved
-GCC developers many hours, or even days, per year.
-
- In the case of function-like macros like `REVERSIBLE_CC_MODE' in GCC
-which cannot be simply used in `if (...)' statements, there is an easy
-workaround. Simply introduce another macro `HAS_REVERSIBLE_CC_MODE' as
-in the following example:
-
- #ifdef REVERSIBLE_CC_MODE
- #define HAS_REVERSIBLE_CC_MODE 1
- #else
- #define HAS_REVERSIBLE_CC_MODE 0
- #endif
-
-
-File: standards.info, Node: Program Behavior, Next: Writing C, Prev: Design Advice, Up: Top
-
-4 Program Behavior for All Programs
-***********************************
-
-This chapter describes conventions for writing robust software. It
-also describes general standards for error messages, the command line
-interface, and how libraries should behave.
-
-* Menu:
-
-* Non-GNU Standards:: We consider standards such as POSIX;
- we don't "obey" them.
-* Semantics:: Writing robust programs.
-* Libraries:: Library behavior.
-* Errors:: Formatting error messages.
-* User Interfaces:: Standards about interfaces generally.
-* Graphical Interfaces:: Standards for graphical interfaces.
-* Command-Line Interfaces:: Standards for command line interfaces.
-* Option Table:: Table of long options.
-* OID Allocations:: Table of OID slots for GNU.
-* Memory Usage:: When and how to care about memory needs.
-* File Usage:: Which files to use, and where.
-
-
-File: standards.info, Node: Non-GNU Standards, Next: Semantics, Up: Program Behavior
-
-4.1 Non-GNU Standards
-=====================
-
-The GNU Project regards standards published by other organizations as
-suggestions, not orders. We consider those standards, but we do not
-"obey" them. In developing a GNU program, you should implement an
-outside standard's specifications when that makes the GNU system better
-overall in an objective sense. When it doesn't, you shouldn't.
-
- In most cases, following published standards is convenient for
-users--it means that their programs or scripts will work more portably.
-For instance, GCC implements nearly all the features of Standard C as
-specified by that standard. C program developers would be unhappy if
-it did not. And GNU utilities mostly follow specifications of POSIX.2;
-shell script writers and users would be unhappy if our programs were
-incompatible.
-
- But we do not follow either of these specifications rigidly, and
-there are specific points on which we decided not to follow them, so as
-to make the GNU system better for users.
-
- For instance, Standard C says that nearly all extensions to C are
-prohibited. How silly! GCC implements many extensions, some of which
-were later adopted as part of the standard. If you want these
-constructs to give an error message as "required" by the standard, you
-must specify `--pedantic', which was implemented only so that we can
-say "GCC is a 100% implementation of the standard," not because there
-is any reason to actually use it.
-
- POSIX.2 specifies that `df' and `du' must output sizes by default in
-units of 512 bytes. What users want is units of 1k, so that is what we
-do by default. If you want the ridiculous behavior "required" by
-POSIX, you must set the environment variable `POSIXLY_CORRECT' (which
-was originally going to be named `POSIX_ME_HARDER').
-
- GNU utilities also depart from the letter of the POSIX.2
-specification when they support long-named command-line options, and
-intermixing options with ordinary arguments. This minor
-incompatibility with POSIX is never a problem in practice, and it is
-very useful.
-
- In particular, don't reject a new feature, or remove an old one,
-merely because a standard says it is "forbidden" or "deprecated."
-
-
-File: standards.info, Node: Semantics, Next: Libraries, Prev: Non-GNU Standards, Up: Program Behavior
-
-4.2 Writing Robust Programs
-===========================
-
-Avoid arbitrary limits on the length or number of _any_ data structure,
-including file names, lines, files, and symbols, by allocating all data
-structures dynamically. In most Unix utilities, "long lines are
-silently truncated". This is not acceptable in a GNU utility.
-
- Utilities reading files should not drop NUL characters, or any other
-nonprinting characters _including those with codes above 0177_. The
-only sensible exceptions would be utilities specifically intended for
-interface to certain types of terminals or printers that can't handle
-those characters. Whenever possible, try to make programs work
-properly with sequences of bytes that represent multibyte characters,
-using encodings such as UTF-8 and others.
-
- Check every system call for an error return, unless you know you
-wish to ignore errors. Include the system error text (from `perror' or
-equivalent) in _every_ error message resulting from a failing system
-call, as well as the name of the file if any and the name of the
-utility. Just "cannot open foo.c" or "stat failed" is not sufficient.
-
- Check every call to `malloc' or `realloc' to see if it returned
-zero. Check `realloc' even if you are making the block smaller; in a
-system that rounds block sizes to a power of 2, `realloc' may get a
-different block if you ask for less space.
-
- In Unix, `realloc' can destroy the storage block if it returns zero.
-GNU `realloc' does not have this bug: if it fails, the original block
-is unchanged. Feel free to assume the bug is fixed. If you wish to
-run your program on Unix, and wish to avoid lossage in this case, you
-can use the GNU `malloc'.
-
- You must expect `free' to alter the contents of the block that was
-freed. Anything you want to fetch from the block, you must fetch before
-calling `free'.
-
- If `malloc' fails in a noninteractive program, make that a fatal
-error. In an interactive program (one that reads commands from the
-user), it is better to abort the command and return to the command
-reader loop. This allows the user to kill other processes to free up
-virtual memory, and then try the command again.
-
- Use `getopt_long' to decode arguments, unless the argument syntax
-makes this unreasonable.
-
- When static storage is to be written in during program execution, use
-explicit C code to initialize it. Reserve C initialized declarations
-for data that will not be changed.
-
- Try to avoid low-level interfaces to obscure Unix data structures
-(such as file directories, utmp, or the layout of kernel memory), since
-these are less likely to work compatibly. If you need to find all the
-files in a directory, use `readdir' or some other high-level interface.
-These are supported compatibly by GNU.
-
- The preferred signal handling facilities are the BSD variant of
-`signal', and the POSIX `sigaction' function; the alternative USG
-`signal' interface is an inferior design.
-
- Nowadays, using the POSIX signal functions may be the easiest way to
-make a program portable. If you use `signal', then on GNU/Linux
-systems running GNU libc version 1, you should include `bsd/signal.h'
-instead of `signal.h', so as to get BSD behavior. It is up to you
-whether to support systems where `signal' has only the USG behavior, or
-give up on them.
-
- In error checks that detect "impossible" conditions, just abort.
-There is usually no point in printing any message. These checks
-indicate the existence of bugs. Whoever wants to fix the bugs will have
-to read the source code and run a debugger. So explain the problem with
-comments in the source. The relevant data will be in variables, which
-are easy to examine with the debugger, so there is no point moving them
-elsewhere.
-
- Do not use a count of errors as the exit status for a program.
-_That does not work_, because exit status values are limited to 8 bits
-(0 through 255). A single run of the program might have 256 errors; if
-you try to return 256 as the exit status, the parent process will see 0
-as the status, and it will appear that the program succeeded.
-
- If you make temporary files, check the `TMPDIR' environment
-variable; if that variable is defined, use the specified directory
-instead of `/tmp'.
-
- In addition, be aware that there is a possible security problem when
-creating temporary files in world-writable directories. In C, you can
-avoid this problem by creating temporary files in this manner:
-
- fd = open (filename, O_WRONLY | O_CREAT | O_EXCL, 0600);
-
-or by using the `mkstemps' function from libiberty.
-
- In bash, use `set -C' to avoid this problem.
-
-
-File: standards.info, Node: Libraries, Next: Errors, Prev: Semantics, Up: Program Behavior
-
-4.3 Library Behavior
-====================
-
-Try to make library functions reentrant. If they need to do dynamic
-storage allocation, at least try to avoid any nonreentrancy aside from
-that of `malloc' itself.
-
- Here are certain name conventions for libraries, to avoid name
-conflicts.
-
- Choose a name prefix for the library, more than two characters long.
-All external function and variable names should start with this prefix.
-In addition, there should only be one of these in any given library
-member. This usually means putting each one in a separate source file.
-
- An exception can be made when two external symbols are always used
-together, so that no reasonable program could use one without the
-other; then they can both go in the same file.
-
- External symbols that are not documented entry points for the user
-should have names beginning with `_'. The `_' should be followed by
-the chosen name prefix for the library, to prevent collisions with
-other libraries. These can go in the same files with user entry points
-if you like.
-
- Static functions and variables can be used as you like and need not
-fit any naming convention.
-
-
-File: standards.info, Node: Errors, Next: User Interfaces, Prev: Libraries, Up: Program Behavior
-
-4.4 Formatting Error Messages
-=============================
-
-Error messages from compilers should look like this:
-
- SOURCE-FILE-NAME:LINENO: MESSAGE
-
-If you want to mention the column number, use one of these formats:
-
- SOURCE-FILE-NAME:LINENO:COLUMN: MESSAGE
- SOURCE-FILE-NAME:LINENO.COLUMN: MESSAGE
-
-Line numbers should start from 1 at the beginning of the file, and
-column numbers should start from 1 at the beginning of the line. (Both
-of these conventions are chosen for compatibility.) Calculate column
-numbers assuming that space and all ASCII printing characters have
-equal width, and assuming tab stops every 8 columns.
-
- The error message can also give both the starting and ending
-positions of the erroneous text. There are several formats so that you
-can avoid redundant information such as a duplicate line number. Here
-are the possible formats:
-
- SOURCE-FILE-NAME:LINENO-1.COLUMN-1-LINENO-2.COLUMN-2: MESSAGE
- SOURCE-FILE-NAME:LINENO-1.COLUMN-1-COLUMN-2: MESSAGE
- SOURCE-FILE-NAME:LINENO-1-LINENO-2: MESSAGE
-
-When an error is spread over several files, you can use this format:
-
- FILE-1:LINENO-1.COLUMN-1-FILE-2:LINENO-2.COLUMN-2: MESSAGE
-
- Error messages from other noninteractive programs should look like
-this:
-
- PROGRAM:SOURCE-FILE-NAME:LINENO: MESSAGE
-
-when there is an appropriate source file, or like this:
-
- PROGRAM: MESSAGE
-
-when there is no relevant source file.
-
- If you want to mention the column number, use this format:
-
- PROGRAM:SOURCE-FILE-NAME:LINENO:COLUMN: MESSAGE
-
- In an interactive program (one that is reading commands from a
-terminal), it is better not to include the program name in an error
-message. The place to indicate which program is running is in the
-prompt or with the screen layout. (When the same program runs with
-input from a source other than a terminal, it is not interactive and
-would do best to print error messages using the noninteractive style.)
-
- The string MESSAGE should not begin with a capital letter when it
-follows a program name and/or file name, because that isn't the
-beginning of a sentence. (The sentence conceptually starts at the
-beginning of the line.) Also, it should not end with a period.
-
- Error messages from interactive programs, and other messages such as
-usage messages, should start with a capital letter. But they should not
-end with a period.
-
-
-File: standards.info, Node: User Interfaces, Next: Graphical Interfaces, Prev: Errors, Up: Program Behavior
-
-4.5 Standards for Interfaces Generally
-======================================
-
-Please don't make the behavior of a utility depend on the name used to
-invoke it. It is useful sometimes to make a link to a utility with a
-different name, and that should not change what it does.
-
- Instead, use a run time option or a compilation switch or both to
-select among the alternate behaviors.
-
- Likewise, please don't make the behavior of the program depend on the
-type of output device it is used with. Device independence is an
-important principle of the system's design; do not compromise it merely
-to save someone from typing an option now and then. (Variation in error
-message syntax when using a terminal is ok, because that is a side issue
-that people do not depend on.)
-
- If you think one behavior is most useful when the output is to a
-terminal, and another is most useful when the output is a file or a
-pipe, then it is usually best to make the default behavior the one that
-is useful with output to a terminal, and have an option for the other
-behavior.
-
- Compatibility requires certain programs to depend on the type of
-output device. It would be disastrous if `ls' or `sh' did not do so in
-the way all users expect. In some of these cases, we supplement the
-program with a preferred alternate version that does not depend on the
-output device type. For example, we provide a `dir' program much like
-`ls' except that its default output format is always multi-column
-format.
-
-
-File: standards.info, Node: Graphical Interfaces, Next: Command-Line Interfaces, Prev: User Interfaces, Up: Program Behavior
-
-4.6 Standards for Graphical Interfaces
-======================================
-
-When you write a program that provides a graphical user interface,
-please make it work with the X Window System and the GTK+ toolkit
-unless the functionality specifically requires some alternative (for
-example, "displaying jpeg images while in console mode").
-
- In addition, please provide a command-line interface to control the
-functionality. (In many cases, the graphical user interface can be a
-separate program which invokes the command-line program.) This is so
-that the same jobs can be done from scripts.
-
- Please also consider providing a D-bus interface for use from other
-running programs, such as within GNOME. (GNOME used to use CORBA for
-this, but that is being phased out.) In addition, consider providing a
-library interface (for use from C), and perhaps a keyboard-driven
-console interface (for use by users from console mode). Once you are
-doing the work to provide the functionality and the graphical
-interface, these won't be much extra work.
-
-
-File: standards.info, Node: Command-Line Interfaces, Next: Option Table, Prev: Graphical Interfaces, Up: Program Behavior
-
-4.7 Standards for Command Line Interfaces
-=========================================
-
-It is a good idea to follow the POSIX guidelines for the command-line
-options of a program. The easiest way to do this is to use `getopt' to
-parse them. Note that the GNU version of `getopt' will normally permit
-options anywhere among the arguments unless the special argument `--'
-is used. This is not what POSIX specifies; it is a GNU extension.
-
- Please define long-named options that are equivalent to the
-single-letter Unix-style options. We hope to make GNU more user
-friendly this way. This is easy to do with the GNU function
-`getopt_long'.
-
- One of the advantages of long-named options is that they can be
-consistent from program to program. For example, users should be able
-to expect the "verbose" option of any GNU program which has one, to be
-spelled precisely `--verbose'. To achieve this uniformity, look at the
-table of common long-option names when you choose the option names for
-your program (*note Option Table::).
-
- It is usually a good idea for file names given as ordinary arguments
-to be input files only; any output files would be specified using
-options (preferably `-o' or `--output'). Even if you allow an output
-file name as an ordinary argument for compatibility, try to provide an
-option as another way to specify it. This will lead to more consistency
-among GNU utilities, and fewer idiosyncrasies for users to remember.
-
- All programs should support two standard options: `--version' and
-`--help'. CGI programs should accept these as command-line options,
-and also if given as the `PATH_INFO'; for instance, visiting
-`http://example.org/p.cgi/--help' in a browser should output the same
-information as invoking `p.cgi --help' from the command line.
-
-* Menu:
-
-* --version:: The standard output for --version.
-* --help:: The standard output for --help.
-
-
-File: standards.info, Node: --version, Next: --help, Up: Command-Line Interfaces
-
-4.7.1 `--version'
------------------
-
-The standard `--version' option should direct the program to print
-information about its name, version, origin and legal status, all on
-standard output, and then exit successfully. Other options and
-arguments should be ignored once this is seen, and the program should
-not perform its normal function.
-
- The first line is meant to be easy for a program to parse; the
-version number proper starts after the last space. In addition, it
-contains the canonical name for this program, in this format:
-
- GNU Emacs 19.30
-
-The program's name should be a constant string; _don't_ compute it from
-`argv[0]'. The idea is to state the standard or canonical name for the
-program, not its file name. There are other ways to find out the
-precise file name where a command is found in `PATH'.
-
- If the program is a subsidiary part of a larger package, mention the
-package name in parentheses, like this:
-
- emacsserver (GNU Emacs) 19.30
-
-If the package has a version number which is different from this
-program's version number, you can mention the package version number
-just before the close-parenthesis.
-
- If you _need_ to mention the version numbers of libraries which are
-distributed separately from the package which contains this program,
-you can do so by printing an additional line of version info for each
-library you want to mention. Use the same format for these lines as for
-the first line.
-
- Please do not mention all of the libraries that the program uses
-"just for completeness"--that would produce a lot of unhelpful clutter.
-Please mention library version numbers only if you find in practice that
-they are very important to you in debugging.
-
- The following line, after the version number line or lines, should
-be a copyright notice. If more than one copyright notice is called
-for, put each on a separate line.
-
- Next should follow a line stating the license, preferably using one
-of abbrevations below, and a brief statement that the program is free
-software, and that users are free to copy and change it. Also mention
-that there is no warranty, to the extent permitted by law. See
-recommended wording below.
-
- It is ok to finish the output with a list of the major authors of the
-program, as a way of giving credit.
-
- Here's an example of output that follows these rules:
-
- GNU hello 2.3
- Copyright (C) 2007 Free Software Foundation, Inc.
- License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
- This is free software: you are free to change and redistribute it.
- There is NO WARRANTY, to the extent permitted by law.
-
- You should adapt this to your program, of course, filling in the
-proper year, copyright holder, name of program, and the references to
-distribution terms, and changing the rest of the wording as necessary.
-
- This copyright notice only needs to mention the most recent year in
-which changes were made--there's no need to list the years for previous
-versions' changes. You don't have to mention the name of the program in
-these notices, if that is inconvenient, since it appeared in the first
-line. (The rules are different for copyright notices in source files;
-*note Copyright Notices: (maintain)Copyright Notices.)
-
- Translations of the above lines must preserve the validity of the
-copyright notices (*note Internationalization::). If the translation's
-character set supports it, the `(C)' should be replaced with the
-copyright symbol, as follows:
-
- (the official copyright symbol, which is the letter C in a circle);
-
- Write the word "Copyright" exactly like that, in English. Do not
-translate it into another language. International treaties recognize
-the English word "Copyright"; translations into other languages do not
-have legal significance.
-
- Finally, here is the table of our suggested license abbreviations.
-Any abbreviation can be followed by `vVERSION[+]', meaning that
-particular version, or later versions with the `+', as shown above.
-
- In the case of exceptions for extra permissions with the GPL, we use
-`/' for a separator; the version number can follow the license
-abbreviation as usual, as in the examples below.
-
-GPL
- GNU General Public License, `http://www.gnu.org/licenses/gpl.html'.
-
-LGPL
- GNU Lesser General Public License,
- `http://www.gnu.org/licenses/lgpl.html'.
-
-GPL/Ada
- GNU GPL with the exception for Ada.
-
-Apache
- The Apache Software Foundation license,
- `http://www.apache.org/licenses'.
-
-Artistic
- The Artistic license used for Perl,
- `http://www.perlfoundation.org/legal'.
-
-Expat
- The Expat license, `http://www.jclark.com/xml/copying.txt'.
-
-MPL
- The Mozilla Public License, `http://www.mozilla.org/MPL/'.
-
-OBSD
- The original (4-clause) BSD license, incompatible with the GNU GPL
- `http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6'.
-
-PHP
- The license used for PHP, `http://www.php.net/license/'.
-
-public domain
- The non-license that is being in the public domain,
- `http://www.gnu.org/licenses/license-list.html#PublicDomain'.
-
-Python
- The license for Python, `http://www.python.org/2.0.1/license.html'.
-
-RBSD
- The revised (3-clause) BSD, compatible with the GNU GPL,
- `http://www.xfree86.org/3.3.6/COPYRIGHT2.html#5'.
-
-X11
- The simple non-copyleft license used for most versions of the X
- Window System, `http://www.xfree86.org/3.3.6/COPYRIGHT2.html#3'.
-
-Zlib
- The license for Zlib, `http://www.gzip.org/zlib/zlib_license.html'.
-
-
- More information about these licenses and many more are on the GNU
-licensing web pages, `http://www.gnu.org/licenses/license-list.html'.
-
-
-File: standards.info, Node: --help, Prev: --version, Up: Command-Line Interfaces
-
-4.7.2 `--help'
---------------
-
-The standard `--help' option should output brief documentation for how
-to invoke the program, on standard output, then exit successfully.
-Other options and arguments should be ignored once this is seen, and
-the program should not perform its normal function.
-
- Near the end of the `--help' option's output, please place lines
-giving the email address for bug reports, the package's home page
-(normally <http://www.gnu.org/software/PKG>, and the general page for
-help using GNU programs. The format should be like this:
-
- Report bugs to: MAILING-ADDRESS
- PKG home page: <http://www.gnu.org/software/PKG/>
- General help using GNU software: <http://www.gnu.org/gethelp/>
-
- It is ok to mention other appropriate mailing lists and web pages.
-
-
-File: standards.info, Node: Option Table, Next: OID Allocations, Prev: Command-Line Interfaces, Up: Program Behavior
-
-4.8 Table of Long Options
-=========================
-
-Here is a table of long options used by GNU programs. It is surely
-incomplete, but we aim to list all the options that a new program might
-want to be compatible with. If you use names not already in the table,
-please send <bug-standards@gnu.org> a list of them, with their
-meanings, so we can update the table.
-
-`after-date'
- `-N' in `tar'.
-
-`all'
- `-a' in `du', `ls', `nm', `stty', `uname', and `unexpand'.
-
-`all-text'
- `-a' in `diff'.
-
-`almost-all'
- `-A' in `ls'.
-
-`append'
- `-a' in `etags', `tee', `time'; `-r' in `tar'.
-
-`archive'
- `-a' in `cp'.
-
-`archive-name'
- `-n' in `shar'.
-
-`arglength'
- `-l' in `m4'.
-
-`ascii'
- `-a' in `diff'.
-
-`assign'
- `-v' in `gawk'.
-
-`assume-new'
- `-W' in `make'.
-
-`assume-old'
- `-o' in `make'.
-
-`auto-check'
- `-a' in `recode'.
-
-`auto-pager'
- `-a' in `wdiff'.
-
-`auto-reference'
- `-A' in `ptx'.
-
-`avoid-wraps'
- `-n' in `wdiff'.
-
-`background'
- For server programs, run in the background.
-
-`backward-search'
- `-B' in `ctags'.
-
-`basename'
- `-f' in `shar'.
-
-`batch'
- Used in GDB.
-
-`baud'
- Used in GDB.
-
-`before'
- `-b' in `tac'.
-
-`binary'
- `-b' in `cpio' and `diff'.
-
-`bits-per-code'
- `-b' in `shar'.
-
-`block-size'
- Used in `cpio' and `tar'.
-
-`blocks'
- `-b' in `head' and `tail'.
-
-`break-file'
- `-b' in `ptx'.
-
-`brief'
- Used in various programs to make output shorter.
-
-`bytes'
- `-c' in `head', `split', and `tail'.
-
-`c++'
- `-C' in `etags'.
-
-`catenate'
- `-A' in `tar'.
-
-`cd'
- Used in various programs to specify the directory to use.
-
-`changes'
- `-c' in `chgrp' and `chown'.
-
-`classify'
- `-F' in `ls'.
-
-`colons'
- `-c' in `recode'.
-
-`command'
- `-c' in `su'; `-x' in GDB.
-
-`compare'
- `-d' in `tar'.
-
-`compat'
- Used in `gawk'.
-
-`compress'
- `-Z' in `tar' and `shar'.
-
-`concatenate'
- `-A' in `tar'.
-
-`confirmation'
- `-w' in `tar'.
-
-`context'
- Used in `diff'.
-
-`copyleft'
- `-W copyleft' in `gawk'.
-
-`copyright'
- `-C' in `ptx', `recode', and `wdiff'; `-W copyright' in `gawk'.
-
-`core'
- Used in GDB.
-
-`count'
- `-q' in `who'.
-
-`count-links'
- `-l' in `du'.
-
-`create'
- Used in `tar' and `cpio'.
-
-`cut-mark'
- `-c' in `shar'.
-
-`cxref'
- `-x' in `ctags'.
-
-`date'
- `-d' in `touch'.
-
-`debug'
- `-d' in `make' and `m4'; `-t' in Bison.
-
-`define'
- `-D' in `m4'.
-
-`defines'
- `-d' in Bison and `ctags'.
-
-`delete'
- `-D' in `tar'.
-
-`dereference'
- `-L' in `chgrp', `chown', `cpio', `du', `ls', and `tar'.
-
-`dereference-args'
- `-D' in `du'.
-
-`device'
- Specify an I/O device (special file name).
-
-`diacritics'
- `-d' in `recode'.
-
-`dictionary-order'
- `-d' in `look'.
-
-`diff'
- `-d' in `tar'.
-
-`digits'
- `-n' in `csplit'.
-
-`directory'
- Specify the directory to use, in various programs. In `ls', it
- means to show directories themselves rather than their contents.
- In `rm' and `ln', it means to not treat links to directories
- specially.
-
-`discard-all'
- `-x' in `strip'.
-
-`discard-locals'
- `-X' in `strip'.
-
-`dry-run'
- `-n' in `make'.
-
-`ed'
- `-e' in `diff'.
-
-`elide-empty-files'
- `-z' in `csplit'.
-
-`end-delete'
- `-x' in `wdiff'.
-
-`end-insert'
- `-z' in `wdiff'.
-
-`entire-new-file'
- `-N' in `diff'.
-
-`environment-overrides'
- `-e' in `make'.
-
-`eof'
- `-e' in `xargs'.
-
-`epoch'
- Used in GDB.
-
-`error-limit'
- Used in `makeinfo'.
-
-`error-output'
- `-o' in `m4'.
-
-`escape'
- `-b' in `ls'.
-
-`exclude-from'
- `-X' in `tar'.
-
-`exec'
- Used in GDB.
-
-`exit'
- `-x' in `xargs'.
-
-`exit-0'
- `-e' in `unshar'.
-
-`expand-tabs'
- `-t' in `diff'.
-
-`expression'
- `-e' in `sed'.
-
-`extern-only'
- `-g' in `nm'.
-
-`extract'
- `-i' in `cpio'; `-x' in `tar'.
-
-`faces'
- `-f' in `finger'.
-
-`fast'
- `-f' in `su'.
-
-`fatal-warnings'
- `-E' in `m4'.
-
-`file'
- `-f' in `gawk', `info', `make', `mt', `sed', and `tar'.
-
-`field-separator'
- `-F' in `gawk'.
-
-`file-prefix'
- `-b' in Bison.
-
-`file-type'
- `-F' in `ls'.
-
-`files-from'
- `-T' in `tar'.
-
-`fill-column'
- Used in `makeinfo'.
-
-`flag-truncation'
- `-F' in `ptx'.
-
-`fixed-output-files'
- `-y' in Bison.
-
-`follow'
- `-f' in `tail'.
-
-`footnote-style'
- Used in `makeinfo'.
-
-`force'
- `-f' in `cp', `ln', `mv', and `rm'.
-
-`force-prefix'
- `-F' in `shar'.
-
-`foreground'
- For server programs, run in the foreground; in other words, don't
- do anything special to run the server in the background.
-
-`format'
- Used in `ls', `time', and `ptx'.
-
-`freeze-state'
- `-F' in `m4'.
-
-`fullname'
- Used in GDB.
-
-`gap-size'
- `-g' in `ptx'.
-
-`get'
- `-x' in `tar'.
-
-`graphic'
- `-i' in `ul'.
-
-`graphics'
- `-g' in `recode'.
-
-`group'
- `-g' in `install'.
-
-`gzip'
- `-z' in `tar' and `shar'.
-
-`hashsize'
- `-H' in `m4'.
-
-`header'
- `-h' in `objdump' and `recode'
-
-`heading'
- `-H' in `who'.
-
-`help'
- Used to ask for brief usage information.
-
-`here-delimiter'
- `-d' in `shar'.
-
-`hide-control-chars'
- `-q' in `ls'.
-
-`html'
- In `makeinfo', output HTML.
-
-`idle'
- `-u' in `who'.
-
-`ifdef'
- `-D' in `diff'.
-
-`ignore'
- `-I' in `ls'; `-x' in `recode'.
-
-`ignore-all-space'
- `-w' in `diff'.
-
-`ignore-backups'
- `-B' in `ls'.
-
-`ignore-blank-lines'
- `-B' in `diff'.
-
-`ignore-case'
- `-f' in `look' and `ptx'; `-i' in `diff' and `wdiff'.
-
-`ignore-errors'
- `-i' in `make'.
-
-`ignore-file'
- `-i' in `ptx'.
-
-`ignore-indentation'
- `-I' in `etags'.
-
-`ignore-init-file'
- `-f' in Oleo.
-
-`ignore-interrupts'
- `-i' in `tee'.
-
-`ignore-matching-lines'
- `-I' in `diff'.
-
-`ignore-space-change'
- `-b' in `diff'.
-
-`ignore-zeros'
- `-i' in `tar'.
-
-`include'
- `-i' in `etags'; `-I' in `m4'.
-
-`include-dir'
- `-I' in `make'.
-
-`incremental'
- `-G' in `tar'.
-
-`info'
- `-i', `-l', and `-m' in Finger.
-
-`init-file'
- In some programs, specify the name of the file to read as the
- user's init file.
-
-`initial'
- `-i' in `expand'.
-
-`initial-tab'
- `-T' in `diff'.
-
-`inode'
- `-i' in `ls'.
-
-`interactive'
- `-i' in `cp', `ln', `mv', `rm'; `-e' in `m4'; `-p' in `xargs';
- `-w' in `tar'.
-
-`intermix-type'
- `-p' in `shar'.
-
-`iso-8601'
- Used in `date'
-
-`jobs'
- `-j' in `make'.
-
-`just-print'
- `-n' in `make'.
-
-`keep-going'
- `-k' in `make'.
-
-`keep-files'
- `-k' in `csplit'.
-
-`kilobytes'
- `-k' in `du' and `ls'.
-
-`language'
- `-l' in `etags'.
-
-`less-mode'
- `-l' in `wdiff'.
-
-`level-for-gzip'
- `-g' in `shar'.
-
-`line-bytes'
- `-C' in `split'.
-
-`lines'
- Used in `split', `head', and `tail'.
-
-`link'
- `-l' in `cpio'.
-
-`lint'
-`lint-old'
- Used in `gawk'.
-
-`list'
- `-t' in `cpio'; `-l' in `recode'.
-
-`list'
- `-t' in `tar'.
-
-`literal'
- `-N' in `ls'.
-
-`load-average'
- `-l' in `make'.
-
-`login'
- Used in `su'.
-
-`machine'
- Used in `uname'.
-
-`macro-name'
- `-M' in `ptx'.
-
-`mail'
- `-m' in `hello' and `uname'.
-
-`make-directories'
- `-d' in `cpio'.
-
-`makefile'
- `-f' in `make'.
-
-`mapped'
- Used in GDB.
-
-`max-args'
- `-n' in `xargs'.
-
-`max-chars'
- `-n' in `xargs'.
-
-`max-lines'
- `-l' in `xargs'.
-
-`max-load'
- `-l' in `make'.
-
-`max-procs'
- `-P' in `xargs'.
-
-`mesg'
- `-T' in `who'.
-
-`message'
- `-T' in `who'.
-
-`minimal'
- `-d' in `diff'.
-
-`mixed-uuencode'
- `-M' in `shar'.
-
-`mode'
- `-m' in `install', `mkdir', and `mkfifo'.
-
-`modification-time'
- `-m' in `tar'.
-
-`multi-volume'
- `-M' in `tar'.
-
-`name-prefix'
- `-a' in Bison.
-
-`nesting-limit'
- `-L' in `m4'.
-
-`net-headers'
- `-a' in `shar'.
-
-`new-file'
- `-W' in `make'.
-
-`no-builtin-rules'
- `-r' in `make'.
-
-`no-character-count'
- `-w' in `shar'.
-
-`no-check-existing'
- `-x' in `shar'.
-
-`no-common'
- `-3' in `wdiff'.
-
-`no-create'
- `-c' in `touch'.
-
-`no-defines'
- `-D' in `etags'.
-
-`no-deleted'
- `-1' in `wdiff'.
-
-`no-dereference'
- `-d' in `cp'.
-
-`no-inserted'
- `-2' in `wdiff'.
-
-`no-keep-going'
- `-S' in `make'.
-
-`no-lines'
- `-l' in Bison.
-
-`no-piping'
- `-P' in `shar'.
-
-`no-prof'
- `-e' in `gprof'.
-
-`no-regex'
- `-R' in `etags'.
-
-`no-sort'
- `-p' in `nm'.
-
-`no-splash'
- Don't print a startup splash screen.
-
-`no-split'
- Used in `makeinfo'.
-
-`no-static'
- `-a' in `gprof'.
-
-`no-time'
- `-E' in `gprof'.
-
-`no-timestamp'
- `-m' in `shar'.
-
-`no-validate'
- Used in `makeinfo'.
-
-`no-wait'
- Used in `emacsclient'.
-
-`no-warn'
- Used in various programs to inhibit warnings.
-
-`node'
- `-n' in `info'.
-
-`nodename'
- `-n' in `uname'.
-
-`nonmatching'
- `-f' in `cpio'.
-
-`nstuff'
- `-n' in `objdump'.
-
-`null'
- `-0' in `xargs'.
-
-`number'
- `-n' in `cat'.
-
-`number-nonblank'
- `-b' in `cat'.
-
-`numeric-sort'
- `-n' in `nm'.
-
-`numeric-uid-gid'
- `-n' in `cpio' and `ls'.
-
-`nx'
- Used in GDB.
-
-`old-archive'
- `-o' in `tar'.
-
-`old-file'
- `-o' in `make'.
-
-`one-file-system'
- `-l' in `tar', `cp', and `du'.
-
-`only-file'
- `-o' in `ptx'.
-
-`only-prof'
- `-f' in `gprof'.
-
-`only-time'
- `-F' in `gprof'.
-
-`options'
- `-o' in `getopt', `fdlist', `fdmount', `fdmountd', and `fdumount'.
-
-`output'
- In various programs, specify the output file name.
-
-`output-prefix'
- `-o' in `shar'.
-
-`override'
- `-o' in `rm'.
-
-`overwrite'
- `-c' in `unshar'.
-
-`owner'
- `-o' in `install'.
-
-`paginate'
- `-l' in `diff'.
-
-`paragraph-indent'
- Used in `makeinfo'.
-
-`parents'
- `-p' in `mkdir' and `rmdir'.
-
-`pass-all'
- `-p' in `ul'.
-
-`pass-through'
- `-p' in `cpio'.
-
-`port'
- `-P' in `finger'.
-
-`portability'
- `-c' in `cpio' and `tar'.
-
-`posix'
- Used in `gawk'.
-
-`prefix-builtins'
- `-P' in `m4'.
-
-`prefix'
- `-f' in `csplit'.
-
-`preserve'
- Used in `tar' and `cp'.
-
-`preserve-environment'
- `-p' in `su'.
-
-`preserve-modification-time'
- `-m' in `cpio'.
-
-`preserve-order'
- `-s' in `tar'.
-
-`preserve-permissions'
- `-p' in `tar'.
-
-`print'
- `-l' in `diff'.
-
-`print-chars'
- `-L' in `cmp'.
-
-`print-data-base'
- `-p' in `make'.
-
-`print-directory'
- `-w' in `make'.
-
-`print-file-name'
- `-o' in `nm'.
-
-`print-symdefs'
- `-s' in `nm'.
-
-`printer'
- `-p' in `wdiff'.
-
-`prompt'
- `-p' in `ed'.
-
-`proxy'
- Specify an HTTP proxy.
-
-`query-user'
- `-X' in `shar'.
-
-`question'
- `-q' in `make'.
-
-`quiet'
- Used in many programs to inhibit the usual output. Every program
- accepting `--quiet' should accept `--silent' as a synonym.
-
-`quiet-unshar'
- `-Q' in `shar'
-
-`quote-name'
- `-Q' in `ls'.
-
-`rcs'
- `-n' in `diff'.
-
-`re-interval'
- Used in `gawk'.
-
-`read-full-blocks'
- `-B' in `tar'.
-
-`readnow'
- Used in GDB.
-
-`recon'
- `-n' in `make'.
-
-`record-number'
- `-R' in `tar'.
-
-`recursive'
- Used in `chgrp', `chown', `cp', `ls', `diff', and `rm'.
-
-`reference'
- `-r' in `touch'.
-
-`references'
- `-r' in `ptx'.
-
-`regex'
- `-r' in `tac' and `etags'.
-
-`release'
- `-r' in `uname'.
-
-`reload-state'
- `-R' in `m4'.
-
-`relocation'
- `-r' in `objdump'.
-
-`rename'
- `-r' in `cpio'.
-
-`replace'
- `-i' in `xargs'.
-
-`report-identical-files'
- `-s' in `diff'.
-
-`reset-access-time'
- `-a' in `cpio'.
-
-`reverse'
- `-r' in `ls' and `nm'.
-
-`reversed-ed'
- `-f' in `diff'.
-
-`right-side-defs'
- `-R' in `ptx'.
-
-`same-order'
- `-s' in `tar'.
-
-`same-permissions'
- `-p' in `tar'.
-
-`save'
- `-g' in `stty'.
-
-`se'
- Used in GDB.
-
-`sentence-regexp'
- `-S' in `ptx'.
-
-`separate-dirs'
- `-S' in `du'.
-
-`separator'
- `-s' in `tac'.
-
-`sequence'
- Used by `recode' to chose files or pipes for sequencing passes.
-
-`shell'
- `-s' in `su'.
-
-`show-all'
- `-A' in `cat'.
-
-`show-c-function'
- `-p' in `diff'.
-
-`show-ends'
- `-E' in `cat'.
-
-`show-function-line'
- `-F' in `diff'.
-
-`show-tabs'
- `-T' in `cat'.
-
-`silent'
- Used in many programs to inhibit the usual output. Every program
- accepting `--silent' should accept `--quiet' as a synonym.
-
-`size'
- `-s' in `ls'.
-
-`socket'
- Specify a file descriptor for a network server to use for its
- socket, instead of opening and binding a new socket. This
- provides a way to run, in a non-privileged process, a server that
- normally needs a reserved port number.
-
-`sort'
- Used in `ls'.
-
-`source'
- `-W source' in `gawk'.
-
-`sparse'
- `-S' in `tar'.
-
-`speed-large-files'
- `-H' in `diff'.
-
-`split-at'
- `-E' in `unshar'.
-
-`split-size-limit'
- `-L' in `shar'.
-
-`squeeze-blank'
- `-s' in `cat'.
-
-`start-delete'
- `-w' in `wdiff'.
-
-`start-insert'
- `-y' in `wdiff'.
-
-`starting-file'
- Used in `tar' and `diff' to specify which file within a directory
- to start processing with.
-
-`statistics'
- `-s' in `wdiff'.
-
-`stdin-file-list'
- `-S' in `shar'.
-
-`stop'
- `-S' in `make'.
-
-`strict'
- `-s' in `recode'.
-
-`strip'
- `-s' in `install'.
-
-`strip-all'
- `-s' in `strip'.
-
-`strip-debug'
- `-S' in `strip'.
-
-`submitter'
- `-s' in `shar'.
-
-`suffix'
- `-S' in `cp', `ln', `mv'.
-
-`suffix-format'
- `-b' in `csplit'.
-
-`sum'
- `-s' in `gprof'.
-
-`summarize'
- `-s' in `du'.
-
-`symbolic'
- `-s' in `ln'.
-
-`symbols'
- Used in GDB and `objdump'.
-
-`synclines'
- `-s' in `m4'.
-
-`sysname'
- `-s' in `uname'.
-
-`tabs'
- `-t' in `expand' and `unexpand'.
-
-`tabsize'
- `-T' in `ls'.
-
-`terminal'
- `-T' in `tput' and `ul'. `-t' in `wdiff'.
-
-`text'
- `-a' in `diff'.
-
-`text-files'
- `-T' in `shar'.
-
-`time'
- Used in `ls' and `touch'.
-
-`timeout'
- Specify how long to wait before giving up on some operation.
-
-`to-stdout'
- `-O' in `tar'.
-
-`total'
- `-c' in `du'.
-
-`touch'
- `-t' in `make', `ranlib', and `recode'.
-
-`trace'
- `-t' in `m4'.
-
-`traditional'
- `-t' in `hello'; `-W traditional' in `gawk'; `-G' in `ed', `m4',
- and `ptx'.
-
-`tty'
- Used in GDB.
-
-`typedefs'
- `-t' in `ctags'.
-
-`typedefs-and-c++'
- `-T' in `ctags'.
-
-`typeset-mode'
- `-t' in `ptx'.
-
-`uncompress'
- `-z' in `tar'.
-
-`unconditional'
- `-u' in `cpio'.
-
-`undefine'
- `-U' in `m4'.
-
-`undefined-only'
- `-u' in `nm'.
-
-`update'
- `-u' in `cp', `ctags', `mv', `tar'.
-
-`usage'
- Used in `gawk'; same as `--help'.
-
-`uuencode'
- `-B' in `shar'.
-
-`vanilla-operation'
- `-V' in `shar'.
-
-`verbose'
- Print more information about progress. Many programs support this.
-
-`verify'
- `-W' in `tar'.
-
-`version'
- Print the version number.
-
-`version-control'
- `-V' in `cp', `ln', `mv'.
-
-`vgrind'
- `-v' in `ctags'.
-
-`volume'
- `-V' in `tar'.
-
-`what-if'
- `-W' in `make'.
-
-`whole-size-limit'
- `-l' in `shar'.
-
-`width'
- `-w' in `ls' and `ptx'.
-
-`word-regexp'
- `-W' in `ptx'.
-
-`writable'
- `-T' in `who'.
-
-`zeros'
- `-z' in `gprof'.
-
-
-File: standards.info, Node: OID Allocations, Next: Memory Usage, Prev: Option Table, Up: Program Behavior
-
-4.9 OID Allocations
-===================
-
-The OID (object identifier) 1.3.6.1.4.1.11591 has been assigned to the
-GNU Project (thanks to Werner Koch). These are used for SNMP, LDAP,
-X.509 certificates, and so on. The web site
-`http://www.alvestrand.no/objectid' has a (voluntary) listing of many
-OID assignments.
-
- If you need a new slot for your GNU package, write
-<maintainers@gnu.org>. Here is a list of arcs currently assigned:
-
-
- 1.3.6.1.4.1.11591 GNU
-
- 1.3.6.1.4.1.11591.1 GNU Radius
-
- 1.3.6.1.4.1.11591.2 GnuPG
- 1.3.6.1.4.1.11591.2.1 notation
- 1.3.6.1.4.1.11591.2.1.1 pkaAddress
-
- 1.3.6.1.4.1.11591.3 GNU Radar
-
- 1.3.6.1.4.1.11591.4 GNU GSS
-
- 1.3.6.1.4.1.11591.5 GNU Mailutils
-
- 1.3.6.1.4.1.11591.6 GNU Shishi
-
- 1.3.6.1.4.1.11591.7 GNU Radio
-
- 1.3.6.1.4.1.11591.12 digestAlgorithm
- 1.3.6.1.4.1.11591.12.2 TIGER/192
- 1.3.6.1.4.1.11591.13 encryptionAlgorithm
- 1.3.6.1.4.1.11591.13.2 Serpent
- 1.3.6.1.4.1.11591.13.2.1 Serpent-128-ECB
- 1.3.6.1.4.1.11591.13.2.2 Serpent-128-CBC
- 1.3.6.1.4.1.11591.13.2.3 Serpent-128-OFB
- 1.3.6.1.4.1.11591.13.2.4 Serpent-128-CFB
- 1.3.6.1.4.1.11591.13.2.21 Serpent-192-ECB
- 1.3.6.1.4.1.11591.13.2.22 Serpent-192-CBC
- 1.3.6.1.4.1.11591.13.2.23 Serpent-192-OFB
- 1.3.6.1.4.1.11591.13.2.24 Serpent-192-CFB
- 1.3.6.1.4.1.11591.13.2.41 Serpent-256-ECB
- 1.3.6.1.4.1.11591.13.2.42 Serpent-256-CBC
- 1.3.6.1.4.1.11591.13.2.43 Serpent-256-OFB
- 1.3.6.1.4.1.11591.13.2.44 Serpent-256-CFB
- 1.3.6.1.4.1.11591.14 CRC algorithms
- 1.3.6.1.4.1.11591.14.1 CRC 32
-
-
-File: standards.info, Node: Memory Usage, Next: File Usage, Prev: OID Allocations, Up: Program Behavior
-
-4.10 Memory Usage
-=================
-
-If a program typically uses just a few meg of memory, don't bother
-making any effort to reduce memory usage. For example, if it is
-impractical for other reasons to operate on files more than a few meg
-long, it is reasonable to read entire input files into memory to
-operate on them.
-
- However, for programs such as `cat' or `tail', that can usefully
-operate on very large files, it is important to avoid using a technique
-that would artificially limit the size of files it can handle. If a
-program works by lines and could be applied to arbitrary user-supplied
-input files, it should keep only a line in memory, because this is not
-very hard and users will want to be able to operate on input files that
-are bigger than will fit in memory all at once.
-
- If your program creates complicated data structures, just make them
-in memory and give a fatal error if `malloc' returns zero.
-
-
-File: standards.info, Node: File Usage, Prev: Memory Usage, Up: Program Behavior
-
-4.11 File Usage
-===============
-
-Programs should be prepared to operate when `/usr' and `/etc' are
-read-only file systems. Thus, if the program manages log files, lock
-files, backup files, score files, or any other files which are modified
-for internal purposes, these files should not be stored in `/usr' or
-`/etc'.
-
- There are two exceptions. `/etc' is used to store system
-configuration information; it is reasonable for a program to modify
-files in `/etc' when its job is to update the system configuration.
-Also, if the user explicitly asks to modify one file in a directory, it
-is reasonable for the program to store other files in the same
-directory.
-
-
-File: standards.info, Node: Writing C, Next: Documentation, Prev: Program Behavior, Up: Top
-
-5 Making The Best Use of C
-**************************
-
-This chapter provides advice on how best to use the C language when
-writing GNU software.
-
-* Menu:
-
-* Formatting:: Formatting your source code.
-* Comments:: Commenting your work.
-* Syntactic Conventions:: Clean use of C constructs.
-* Names:: Naming variables, functions, and files.
-* System Portability:: Portability among different operating systems.
-* CPU Portability:: Supporting the range of CPU types.
-* System Functions:: Portability and ``standard'' library functions.
-* Internationalization:: Techniques for internationalization.
-* Character Set:: Use ASCII by default.
-* Quote Characters:: Use `...' in the C locale.
-* Mmap:: How you can safely use `mmap'.
-
-
-File: standards.info, Node: Formatting, Next: Comments, Up: Writing C
-
-5.1 Formatting Your Source Code
-===============================
-
-It is important to put the open-brace that starts the body of a C
-function in column one, so that they will start a defun. Several tools
-look for open-braces in column one to find the beginnings of C
-functions. These tools will not work on code not formatted that way.
-
- Avoid putting open-brace, open-parenthesis or open-bracket in column
-one when they are inside a function, so that they won't start a defun.
-The open-brace that starts a `struct' body can go in column one if you
-find it useful to treat that definition as a defun.
-
- It is also important for function definitions to start the name of
-the function in column one. This helps people to search for function
-definitions, and may also help certain tools recognize them. Thus,
-using Standard C syntax, the format is this:
-
- static char *
- concat (char *s1, char *s2)
- {
- ...
- }
-
-or, if you want to use traditional C syntax, format the definition like
-this:
-
- static char *
- concat (s1, s2) /* Name starts in column one here */
- char *s1, *s2;
- { /* Open brace in column one here */
- ...
- }
-
- In Standard C, if the arguments don't fit nicely on one line, split
-it like this:
-
- int
- lots_of_args (int an_integer, long a_long, short a_short,
- double a_double, float a_float)
- ...
-
- The rest of this section gives our recommendations for other aspects
-of C formatting style, which is also the default style of the `indent'
-program in version 1.2 and newer. It corresponds to the options
-
- -nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 -cs -di2
- -ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -psl -nsc -nsob
-
- We don't think of these recommendations as requirements, because it
-causes no problems for users if two different programs have different
-formatting styles.
-
- But whatever style you use, please use it consistently, since a
-mixture of styles within one program tends to look ugly. If you are
-contributing changes to an existing program, please follow the style of
-that program.
-
- For the body of the function, our recommended style looks like this:
-
- if (x < foo (y, z))
- haha = bar[4] + 5;
- else
- {
- while (z)
- {
- haha += foo (z, z);
- z--;
- }
- return ++x + bar ();
- }
-
- We find it easier to read a program when it has spaces before the
-open-parentheses and after the commas. Especially after the commas.
-
- When you split an expression into multiple lines, split it before an
-operator, not after one. Here is the right way:
-
- if (foo_this_is_long && bar > win (x, y, z)
- && remaining_condition)
-
- Try to avoid having two operators of different precedence at the same
-level of indentation. For example, don't write this:
-
- mode = (inmode[j] == VOIDmode
- || GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j])
- ? outmode[j] : inmode[j]);
-
- Instead, use extra parentheses so that the indentation shows the
-nesting:
-
- mode = ((inmode[j] == VOIDmode
- || (GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j])))
- ? outmode[j] : inmode[j]);
-
- Insert extra parentheses so that Emacs will indent the code properly.
-For example, the following indentation looks nice if you do it by hand,
-
- v = rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
- + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000;
-
-but Emacs would alter it. Adding a set of parentheses produces
-something that looks equally nice, and which Emacs will preserve:
-
- v = (rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
- + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000);
-
- Format do-while statements like this:
-
- do
- {
- a = foo (a);
- }
- while (a > 0);
-
- Please use formfeed characters (control-L) to divide the program into
-pages at logical places (but not within a function). It does not matter
-just how long the pages are, since they do not have to fit on a printed
-page. The formfeeds should appear alone on lines by themselves.
-
-
-File: standards.info, Node: Comments, Next: Syntactic Conventions, Prev: Formatting, Up: Writing C
-
-5.2 Commenting Your Work
-========================
-
-Every program should start with a comment saying briefly what it is for.
-Example: `fmt - filter for simple filling of text'. This comment
-should be at the top of the source file containing the `main' function
-of the program.
-
- Also, please write a brief comment at the start of each source file,
-with the file name and a line or two about the overall purpose of the
-file.
-
- Please write the comments in a GNU program in English, because
-English is the one language that nearly all programmers in all
-countries can read. If you do not write English well, please write
-comments in English as well as you can, then ask other people to help
-rewrite them. If you can't write comments in English, please find
-someone to work with you and translate your comments into English.
-
- Please put a comment on each function saying what the function does,
-what sorts of arguments it gets, and what the possible values of
-arguments mean and are used for. It is not necessary to duplicate in
-words the meaning of the C argument declarations, if a C type is being
-used in its customary fashion. If there is anything nonstandard about
-its use (such as an argument of type `char *' which is really the
-address of the second character of a string, not the first), or any
-possible values that would not work the way one would expect (such as,
-that strings containing newlines are not guaranteed to work), be sure
-to say so.
-
- Also explain the significance of the return value, if there is one.
-
- Please put two spaces after the end of a sentence in your comments,
-so that the Emacs sentence commands will work. Also, please write
-complete sentences and capitalize the first word. If a lower-case
-identifier comes at the beginning of a sentence, don't capitalize it!
-Changing the spelling makes it a different identifier. If you don't
-like starting a sentence with a lower case letter, write the sentence
-differently (e.g., "The identifier lower-case is ...").
-
- The comment on a function is much clearer if you use the argument
-names to speak about the argument values. The variable name itself
-should be lower case, but write it in upper case when you are speaking
-about the value rather than the variable itself. Thus, "the inode
-number NODE_NUM" rather than "an inode".
-
- There is usually no purpose in restating the name of the function in
-the comment before it, because the reader can see that for himself.
-There might be an exception when the comment is so long that the
-function itself would be off the bottom of the screen.
-
- There should be a comment on each static variable as well, like this:
-
- /* Nonzero means truncate lines in the display;
- zero means continue them. */
- int truncate_lines;
-
- Every `#endif' should have a comment, except in the case of short
-conditionals (just a few lines) that are not nested. The comment should
-state the condition of the conditional that is ending, _including its
-sense_. `#else' should have a comment describing the condition _and
-sense_ of the code that follows. For example:
-
- #ifdef foo
- ...
- #else /* not foo */
- ...
- #endif /* not foo */
- #ifdef foo
- ...
- #endif /* foo */
-
-but, by contrast, write the comments this way for a `#ifndef':
-
- #ifndef foo
- ...
- #else /* foo */
- ...
- #endif /* foo */
- #ifndef foo
- ...
- #endif /* not foo */
-
-
-File: standards.info, Node: Syntactic Conventions, Next: Names, Prev: Comments, Up: Writing C
-
-5.3 Clean Use of C Constructs
-=============================
-
-Please explicitly declare the types of all objects. For example, you
-should explicitly declare all arguments to functions, and you should
-declare functions to return `int' rather than omitting the `int'.
-
- Some programmers like to use the GCC `-Wall' option, and change the
-code whenever it issues a warning. If you want to do this, then do.
-Other programmers prefer not to use `-Wall', because it gives warnings
-for valid and legitimate code which they do not want to change. If you
-want to do this, then do. The compiler should be your servant, not
-your master.
-
- Declarations of external functions and functions to appear later in
-the source file should all go in one place near the beginning of the
-file (somewhere before the first function definition in the file), or
-else should go in a header file. Don't put `extern' declarations inside
-functions.
-
- It used to be common practice to use the same local variables (with
-names like `tem') over and over for different values within one
-function. Instead of doing this, it is better to declare a separate
-local variable for each distinct purpose, and give it a name which is
-meaningful. This not only makes programs easier to understand, it also
-facilitates optimization by good compilers. You can also move the
-declaration of each local variable into the smallest scope that includes
-all its uses. This makes the program even cleaner.
-
- Don't use local variables or parameters that shadow global
-identifiers.
-
- Don't declare multiple variables in one declaration that spans lines.
-Start a new declaration on each line, instead. For example, instead of
-this:
-
- int foo,
- bar;
-
-write either this:
-
- int foo, bar;
-
-or this:
-
- int foo;
- int bar;
-
-(If they are global variables, each should have a comment preceding it
-anyway.)
-
- When you have an `if'-`else' statement nested in another `if'
-statement, always put braces around the `if'-`else'. Thus, never write
-like this:
-
- if (foo)
- if (bar)
- win ();
- else
- lose ();
-
-always like this:
-
- if (foo)
- {
- if (bar)
- win ();
- else
- lose ();
- }
-
- If you have an `if' statement nested inside of an `else' statement,
-either write `else if' on one line, like this,
-
- if (foo)
- ...
- else if (bar)
- ...
-
-with its `then'-part indented like the preceding `then'-part, or write
-the nested `if' within braces like this:
-
- if (foo)
- ...
- else
- {
- if (bar)
- ...
- }
-
- Don't declare both a structure tag and variables or typedefs in the
-same declaration. Instead, declare the structure tag separately and
-then use it to declare the variables or typedefs.
-
- Try to avoid assignments inside `if'-conditions (assignments inside
-`while'-conditions are ok). For example, don't write this:
-
- if ((foo = (char *) malloc (sizeof *foo)) == 0)
- fatal ("virtual memory exhausted");
-
-instead, write this:
-
- foo = (char *) malloc (sizeof *foo);
- if (foo == 0)
- fatal ("virtual memory exhausted");
-
- Don't make the program ugly to placate `lint'. Please don't insert
-any casts to `void'. Zero without a cast is perfectly fine as a null
-pointer constant, except when calling a varargs function.
-
-
-File: standards.info, Node: Names, Next: System Portability, Prev: Syntactic Conventions, Up: Writing C
-
-5.4 Naming Variables, Functions, and Files
-==========================================
-
-The names of global variables and functions in a program serve as
-comments of a sort. So don't choose terse names--instead, look for
-names that give useful information about the meaning of the variable or
-function. In a GNU program, names should be English, like other
-comments.
-
- Local variable names can be shorter, because they are used only
-within one context, where (presumably) comments explain their purpose.
-
- Try to limit your use of abbreviations in symbol names. It is ok to
-make a few abbreviations, explain what they mean, and then use them
-frequently, but don't use lots of obscure abbreviations.
-
- Please use underscores to separate words in a name, so that the Emacs
-word commands can be useful within them. Stick to lower case; reserve
-upper case for macros and `enum' constants, and for name-prefixes that
-follow a uniform convention.
-
- For example, you should use names like `ignore_space_change_flag';
-don't use names like `iCantReadThis'.
-
- Variables that indicate whether command-line options have been
-specified should be named after the meaning of the option, not after
-the option-letter. A comment should state both the exact meaning of
-the option and its letter. For example,
-
- /* Ignore changes in horizontal whitespace (-b). */
- int ignore_space_change_flag;
-
- When you want to define names with constant integer values, use
-`enum' rather than `#define'. GDB knows about enumeration constants.
-
- You might want to make sure that none of the file names would
-conflict if the files were loaded onto an MS-DOS file system which
-shortens the names. You can use the program `doschk' to test for this.
-
- Some GNU programs were designed to limit themselves to file names of
-14 characters or less, to avoid file name conflicts if they are read
-into older System V systems. Please preserve this feature in the
-existing GNU programs that have it, but there is no need to do this in
-new GNU programs. `doschk' also reports file names longer than 14
-characters.
-
-
-File: standards.info, Node: System Portability, Next: CPU Portability, Prev: Names, Up: Writing C
-
-5.5 Portability between System Types
-====================================
-
-In the Unix world, "portability" refers to porting to different Unix
-versions. For a GNU program, this kind of portability is desirable, but
-not paramount.
-
- The primary purpose of GNU software is to run on top of the GNU
-kernel, compiled with the GNU C compiler, on various types of CPU. So
-the kinds of portability that are absolutely necessary are quite
-limited. But it is important to support Linux-based GNU systems, since
-they are the form of GNU that is popular.
-
- Beyond that, it is good to support the other free operating systems
-(*BSD), and it is nice to support other Unix-like systems if you want
-to. Supporting a variety of Unix-like systems is desirable, although
-not paramount. It is usually not too hard, so you may as well do it.
-But you don't have to consider it an obligation, if it does turn out to
-be hard.
-
- The easiest way to achieve portability to most Unix-like systems is
-to use Autoconf. It's unlikely that your program needs to know more
-information about the host platform than Autoconf can provide, simply
-because most of the programs that need such knowledge have already been
-written.
-
- Avoid using the format of semi-internal data bases (e.g.,
-directories) when there is a higher-level alternative (`readdir').
-
- As for systems that are not like Unix, such as MSDOS, Windows, VMS,
-MVS, and older Macintosh systems, supporting them is often a lot of
-work. When that is the case, it is better to spend your time adding
-features that will be useful on GNU and GNU/Linux, rather than on
-supporting other incompatible systems.
-
- If you do support Windows, please do not abbreviate it as "win". In
-hacker terminology, calling something a "win" is a form of praise.
-You're free to praise Microsoft Windows on your own if you want, but
-please don't do this in GNU packages. Instead of abbreviating
-"Windows" to "win", you can write it in full or abbreviate it to "woe"
-or "w". In GNU Emacs, for instance, we use `w32' in file names of
-Windows-specific files, but the macro for Windows conditionals is
-called `WINDOWSNT'.
-
- It is a good idea to define the "feature test macro" `_GNU_SOURCE'
-when compiling your C files. When you compile on GNU or GNU/Linux,
-this will enable the declarations of GNU library extension functions,
-and that will usually give you a compiler error message if you define
-the same function names in some other way in your program. (You don't
-have to actually _use_ these functions, if you prefer to make the
-program more portable to other systems.)
-
- But whether or not you use these GNU extensions, you should avoid
-using their names for any other meanings. Doing so would make it hard
-to move your code into other GNU programs.
-
-
-File: standards.info, Node: CPU Portability, Next: System Functions, Prev: System Portability, Up: Writing C
-
-5.6 Portability between CPUs
-============================
-
-Even GNU systems will differ because of differences among CPU
-types--for example, difference in byte ordering and alignment
-requirements. It is absolutely essential to handle these differences.
-However, don't make any effort to cater to the possibility that an
-`int' will be less than 32 bits. We don't support 16-bit machines in
-GNU.
-
- Similarly, don't make any effort to cater to the possibility that
-`long' will be smaller than predefined types like `size_t'. For
-example, the following code is ok:
-
- printf ("size = %lu\n", (unsigned long) sizeof array);
- printf ("diff = %ld\n", (long) (pointer2 - pointer1));
-
- 1989 Standard C requires this to work, and we know of only one
-counterexample: 64-bit programs on Microsoft Windows. We will leave it
-to those who want to port GNU programs to that environment to figure
-out how to do it.
-
- Predefined file-size types like `off_t' are an exception: they are
-longer than `long' on many platforms, so code like the above won't work
-with them. One way to print an `off_t' value portably is to print its
-digits yourself, one by one.
-
- Don't assume that the address of an `int' object is also the address
-of its least-significant byte. This is false on big-endian machines.
-Thus, don't make the following mistake:
-
- int c;
- ...
- while ((c = getchar ()) != EOF)
- write (file_descriptor, &c, 1);
-
-Instead, use `unsigned char' as follows. (The `unsigned' is for
-portability to unusual systems where `char' is signed and where there
-is integer overflow checking.)
-
- int c;
- while ((c = getchar ()) != EOF)
- {
- unsigned char u = c;
- write (file_descriptor, &u, 1);
- }
-
- It used to be ok to not worry about the difference between pointers
-and integers when passing arguments to functions. However, on most
-modern 64-bit machines pointers are wider than `int'. Conversely,
-integer types like `long long int' and `off_t' are wider than pointers
-on most modern 32-bit machines. Hence it's often better nowadays to
-use prototypes to define functions whose argument types are not trivial.
-
- In particular, if functions accept varying argument counts or types
-they should be declared using prototypes containing `...' and defined
-using `stdarg.h'. For an example of this, please see the Gnulib
-(http://www.gnu.org/software/gnulib/) error module, which declares and
-defines the following function:
-
- /* Print a message with `fprintf (stderr, FORMAT, ...)';
- if ERRNUM is nonzero, follow it with ": " and strerror (ERRNUM).
- If STATUS is nonzero, terminate the program with `exit (STATUS)'. */
-
- void error (int status, int errnum, const char *format, ...);
-
- A simple way to use the Gnulib error module is to obtain the two
-source files `error.c' and `error.h' from the Gnulib library source
-code repository at `http://git.savannah.gnu.org/gitweb/?p=gnulib.git'.
-Here's a sample use:
-
- #include "error.h"
- #include <errno.h>
- #include <stdio.h>
-
- char *program_name = "myprogram";
-
- FILE *
- xfopen (char const *name)
- {
- FILE *fp = fopen (name, "r");
- if (! fp)
- error (1, errno, "cannot read %s", name);
- return fp;
- }
-
- Avoid casting pointers to integers if you can. Such casts greatly
-reduce portability, and in most programs they are easy to avoid. In the
-cases where casting pointers to integers is essential--such as, a Lisp
-interpreter which stores type information as well as an address in one
-word--you'll have to make explicit provisions to handle different word
-sizes. You will also need to make provision for systems in which the
-normal range of addresses you can get from `malloc' starts far away
-from zero.
-
-
-File: standards.info, Node: System Functions, Next: Internationalization, Prev: CPU Portability, Up: Writing C
-
-5.7 Calling System Functions
-============================
-
-C implementations differ substantially. Standard C reduces but does
-not eliminate the incompatibilities; meanwhile, many GNU packages still
-support pre-standard compilers because this is not hard to do. This
-chapter gives recommendations for how to use the more-or-less standard C
-library functions to avoid unnecessary loss of portability.
-
- * Don't use the return value of `sprintf'. It returns the number of
- characters written on some systems, but not on all systems.
-
- * Be aware that `vfprintf' is not always available.
-
- * `main' should be declared to return type `int'. It should
- terminate either by calling `exit' or by returning the integer
- status code; make sure it cannot ever return an undefined value.
-
- * Don't declare system functions explicitly.
-
- Almost any declaration for a system function is wrong on some
- system. To minimize conflicts, leave it to the system header
- files to declare system functions. If the headers don't declare a
- function, let it remain undeclared.
-
- While it may seem unclean to use a function without declaring it,
- in practice this works fine for most system library functions on
- the systems where this really happens; thus, the disadvantage is
- only theoretical. By contrast, actual declarations have
- frequently caused actual conflicts.
-
- * If you must declare a system function, don't specify the argument
- types. Use an old-style declaration, not a Standard C prototype.
- The more you specify about the function, the more likely a
- conflict.
-
- * In particular, don't unconditionally declare `malloc' or `realloc'.
-
- Most GNU programs use those functions just once, in functions
- conventionally named `xmalloc' and `xrealloc'. These functions
- call `malloc' and `realloc', respectively, and check the results.
-
- Because `xmalloc' and `xrealloc' are defined in your program, you
- can declare them in other files without any risk of type conflict.
-
- On most systems, `int' is the same length as a pointer; thus, the
- calls to `malloc' and `realloc' work fine. For the few
- exceptional systems (mostly 64-bit machines), you can use
- *conditionalized* declarations of `malloc' and `realloc'--or put
- these declarations in configuration files specific to those
- systems.
-
- * The string functions require special treatment. Some Unix systems
- have a header file `string.h'; others have `strings.h'. Neither
- file name is portable. There are two things you can do: use
- Autoconf to figure out which file to include, or don't include
- either file.
-
- * If you don't include either strings file, you can't get
- declarations for the string functions from the header file in the
- usual way.
-
- That causes less of a problem than you might think. The newer
- standard string functions should be avoided anyway because many
- systems still don't support them. The string functions you can
- use are these:
-
- strcpy strncpy strcat strncat
- strlen strcmp strncmp
- strchr strrchr
-
- The copy and concatenate functions work fine without a declaration
- as long as you don't use their values. Using their values without
- a declaration fails on systems where the width of a pointer
- differs from the width of `int', and perhaps in other cases. It
- is trivial to avoid using their values, so do that.
-
- The compare functions and `strlen' work fine without a declaration
- on most systems, possibly all the ones that GNU software runs on.
- You may find it necessary to declare them *conditionally* on a few
- systems.
-
- The search functions must be declared to return `char *'. Luckily,
- there is no variation in the data type they return. But there is
- variation in their names. Some systems give these functions the
- names `index' and `rindex'; other systems use the names `strchr'
- and `strrchr'. Some systems support both pairs of names, but
- neither pair works on all systems.
-
- You should pick a single pair of names and use it throughout your
- program. (Nowadays, it is better to choose `strchr' and `strrchr'
- for new programs, since those are the standard names.) Declare
- both of those names as functions returning `char *'. On systems
- which don't support those names, define them as macros in terms of
- the other pair. For example, here is what to put at the beginning
- of your file (or in a header) if you want to use the names
- `strchr' and `strrchr' throughout:
-
- #ifndef HAVE_STRCHR
- #define strchr index
- #endif
- #ifndef HAVE_STRRCHR
- #define strrchr rindex
- #endif
-
- char *strchr ();
- char *strrchr ();
-
- Here we assume that `HAVE_STRCHR' and `HAVE_STRRCHR' are macros
-defined in systems where the corresponding functions exist. One way to
-get them properly defined is to use Autoconf.
-
-
-File: standards.info, Node: Internationalization, Next: Character Set, Prev: System Functions, Up: Writing C
-
-5.8 Internationalization
-========================
-
-GNU has a library called GNU gettext that makes it easy to translate the
-messages in a program into various languages. You should use this
-library in every program. Use English for the messages as they appear
-in the program, and let gettext provide the way to translate them into
-other languages.
-
- Using GNU gettext involves putting a call to the `gettext' macro
-around each string that might need translation--like this:
-
- printf (gettext ("Processing file `%s'..."));
-
-This permits GNU gettext to replace the string `"Processing file
-`%s'..."' with a translated version.
-
- Once a program uses gettext, please make a point of writing calls to
-`gettext' when you add new strings that call for translation.
-
- Using GNU gettext in a package involves specifying a "text domain
-name" for the package. The text domain name is used to separate the
-translations for this package from the translations for other packages.
-Normally, the text domain name should be the same as the name of the
-package--for example, `coreutils' for the GNU core utilities.
-
- To enable gettext to work well, avoid writing code that makes
-assumptions about the structure of words or sentences. When you want
-the precise text of a sentence to vary depending on the data, use two or
-more alternative string constants each containing a complete sentences,
-rather than inserting conditionalized words or phrases into a single
-sentence framework.
-
- Here is an example of what not to do:
-
- printf ("%s is full", capacity > 5000000 ? "disk" : "floppy disk");
-
- If you apply gettext to all strings, like this,
-
- printf (gettext ("%s is full"),
- capacity > 5000000 ? gettext ("disk") : gettext ("floppy disk"));
-
-the translator will hardly know that "disk" and "floppy disk" are meant
-to be substituted in the other string. Worse, in some languages (like
-French) the construction will not work: the translation of the word
-"full" depends on the gender of the first part of the sentence; it
-happens to be not the same for "disk" as for "floppy disk".
-
- Complete sentences can be translated without problems:
-
- printf (capacity > 5000000 ? gettext ("disk is full")
- : gettext ("floppy disk is full"));
-
- A similar problem appears at the level of sentence structure with
-this code:
-
- printf ("# Implicit rule search has%s been done.\n",
- f->tried_implicit ? "" : " not");
-
-Adding `gettext' calls to this code cannot give correct results for all
-languages, because negation in some languages requires adding words at
-more than one place in the sentence. By contrast, adding `gettext'
-calls does the job straightforwardly if the code starts out like this:
-
- printf (f->tried_implicit
- ? "# Implicit rule search has been done.\n",
- : "# Implicit rule search has not been done.\n");
-
- Another example is this one:
-
- printf ("%d file%s processed", nfiles,
- nfiles != 1 ? "s" : "");
-
-The problem with this example is that it assumes that plurals are made
-by adding `s'. If you apply gettext to the format string, like this,
-
- printf (gettext ("%d file%s processed"), nfiles,
- nfiles != 1 ? "s" : "");
-
-the message can use different words, but it will still be forced to use
-`s' for the plural. Here is a better way, with gettext being applied to
-the two strings independently:
-
- printf ((nfiles != 1 ? gettext ("%d files processed")
- : gettext ("%d file processed")),
- nfiles);
-
-But this still doesn't work for languages like Polish, which has three
-plural forms: one for nfiles == 1, one for nfiles == 2, 3, 4, 22, 23,
-24, ... and one for the rest. The GNU `ngettext' function solves this
-problem:
-
- printf (ngettext ("%d files processed", "%d file processed", nfiles),
- nfiles);
-
-
-File: standards.info, Node: Character Set, Next: Quote Characters, Prev: Internationalization, Up: Writing C
-
-5.9 Character Set
-=================
-
-Sticking to the ASCII character set (plain text, 7-bit characters) is
-preferred in GNU source code comments, text documents, and other
-contexts, unless there is good reason to do something else because of
-the application domain. For example, if source code deals with the
-French Revolutionary calendar, it is OK if its literal strings contain
-accented characters in month names like "Flore'al". Also, it is OK to
-use non-ASCII characters to represent proper names of contributors in
-change logs (*note Change Logs::).
-
- If you need to use non-ASCII characters, you should normally stick
-with one encoding, as one cannot in general mix encodings reliably.
-
-
-File: standards.info, Node: Quote Characters, Next: Mmap, Prev: Character Set, Up: Writing C
-
-5.10 Quote Characters
-=====================
-
-In the C locale, GNU programs should stick to plain ASCII for quotation
-characters in messages to users: preferably 0x60 (``') for left quotes
-and 0x27 (`'') for right quotes. It is ok, but not required, to use
-locale-specific quotes in other locales.
-
- The Gnulib (http://www.gnu.org/software/gnulib/) `quote' and
-`quotearg' modules provide a reasonably straightforward way to support
-locale-specific quote characters, as well as taking care of other
-issues, such as quoting a filename that itself contains a quote
-character. See the Gnulib documentation for usage details.
-
- In any case, the documentation for your program should clearly
-specify how it does quoting, if different than the preferred method of
-``' and `''. This is especially important if the output of your
-program is ever likely to be parsed by another program.
-
- Quotation characters are a difficult area in the computing world at
-this time: there are no true left or right quote characters in Latin1;
-the ``' character we use was standardized there as a grave accent.
-Moreover, Latin1 is still not universally usable.
-
- Unicode contains the unambiguous quote characters required, and its
-common encoding UTF-8 is upward compatible with Latin1. However,
-Unicode and UTF-8 are not universally well-supported, either.
-
- This may change over the next few years, and then we will revisit
-this.
-
-
-File: standards.info, Node: Mmap, Prev: Quote Characters, Up: Writing C
-
-5.11 Mmap
-=========
-
-Don't assume that `mmap' either works on all files or fails for all
-files. It may work on some files and fail on others.
-
- The proper way to use `mmap' is to try it on the specific file for
-which you want to use it--and if `mmap' doesn't work, fall back on
-doing the job in another way using `read' and `write'.
-
- The reason this precaution is needed is that the GNU kernel (the
-HURD) provides a user-extensible file system, in which there can be many
-different kinds of "ordinary files." Many of them support `mmap', but
-some do not. It is important to make programs handle all these kinds
-of files.
-
-
-File: standards.info, Node: Documentation, Next: Managing Releases, Prev: Writing C, Up: Top
-
-6 Documenting Programs
-**********************
-
-A GNU program should ideally come with full free documentation, adequate
-for both reference and tutorial purposes. If the package can be
-programmed or extended, the documentation should cover programming or
-extending it, as well as just using it.
-
-* Menu:
-
-* GNU Manuals:: Writing proper manuals.
-* Doc Strings and Manuals:: Compiling doc strings doesn't make a manual.
-* Manual Structure Details:: Specific structure conventions.
-* License for Manuals:: Writing the distribution terms for a manual.
-* Manual Credits:: Giving credit to documentation contributors.
-* Printed Manuals:: Mentioning the printed manual.
-* NEWS File:: NEWS files supplement manuals.
-* Change Logs:: Recording changes.
-* Man Pages:: Man pages are secondary.
-* Reading other Manuals:: How far you can go in learning
- from other manuals.
-
-
-File: standards.info, Node: GNU Manuals, Next: Doc Strings and Manuals, Up: Documentation
-
-6.1 GNU Manuals
-===============
-
-The preferred document format for the GNU system is the Texinfo
-formatting language. Every GNU package should (ideally) have
-documentation in Texinfo both for reference and for learners. Texinfo
-makes it possible to produce a good quality formatted book, using TeX,
-and to generate an Info file. It is also possible to generate HTML
-output from Texinfo source. See the Texinfo manual, either the
-hardcopy, or the on-line version available through `info' or the Emacs
-Info subsystem (`C-h i').
-
- Nowadays some other formats such as Docbook and Sgmltexi can be
-converted automatically into Texinfo. It is ok to produce the Texinfo
-documentation by conversion this way, as long as it gives good results.
-
- Make sure your manual is clear to a reader who knows nothing about
-the topic and reads it straight through. This means covering basic
-topics at the beginning, and advanced topics only later. This also
-means defining every specialized term when it is first used.
-
- Programmers tend to carry over the structure of the program as the
-structure for its documentation. But this structure is not necessarily
-good for explaining how to use the program; it may be irrelevant and
-confusing for a user.
-
- Instead, the right way to structure documentation is according to the
-concepts and questions that a user will have in mind when reading it.
-This principle applies at every level, from the lowest (ordering
-sentences in a paragraph) to the highest (ordering of chapter topics
-within the manual). Sometimes this structure of ideas matches the
-structure of the implementation of the software being documented--but
-often they are different. An important part of learning to write good
-documentation is to learn to notice when you have unthinkingly
-structured the documentation like the implementation, stop yourself,
-and look for better alternatives.
-
- For example, each program in the GNU system probably ought to be
-documented in one manual; but this does not mean each program should
-have its own manual. That would be following the structure of the
-implementation, rather than the structure that helps the user
-understand.
-
- Instead, each manual should cover a coherent _topic_. For example,
-instead of a manual for `diff' and a manual for `diff3', we have one
-manual for "comparison of files" which covers both of those programs,
-as well as `cmp'. By documenting these programs together, we can make
-the whole subject clearer.
-
- The manual which discusses a program should certainly document all of
-the program's command-line options and all of its commands. It should
-give examples of their use. But don't organize the manual as a list of
-features. Instead, organize it logically, by subtopics. Address the
-questions that a user will ask when thinking about the job that the
-program does. Don't just tell the reader what each feature can do--say
-what jobs it is good for, and show how to use it for those jobs.
-Explain what is recommended usage, and what kinds of usage users should
-avoid.
-
- In general, a GNU manual should serve both as tutorial and reference.
-It should be set up for convenient access to each topic through Info,
-and for reading straight through (appendixes aside). A GNU manual
-should give a good introduction to a beginner reading through from the
-start, and should also provide all the details that hackers want. The
-Bison manual is a good example of this--please take a look at it to see
-what we mean.
-
- That is not as hard as it first sounds. Arrange each chapter as a
-logical breakdown of its topic, but order the sections, and write their
-text, so that reading the chapter straight through makes sense. Do
-likewise when structuring the book into chapters, and when structuring a
-section into paragraphs. The watchword is, _at each point, address the
-most fundamental and important issue raised by the preceding text._
-
- If necessary, add extra chapters at the beginning of the manual which
-are purely tutorial and cover the basics of the subject. These provide
-the framework for a beginner to understand the rest of the manual. The
-Bison manual provides a good example of how to do this.
-
- To serve as a reference, a manual should have an Index that list all
-the functions, variables, options, and important concepts that are part
-of the program. One combined Index should do for a short manual, but
-sometimes for a complex package it is better to use multiple indices.
-The Texinfo manual includes advice on preparing good index entries, see
-*note Making Index Entries: (texinfo)Index Entries, and see *note
-Defining the Entries of an Index: (texinfo)Indexing Commands.
-
- Don't use Unix man pages as a model for how to write GNU
-documentation; most of them are terse, badly structured, and give
-inadequate explanation of the underlying concepts. (There are, of
-course, some exceptions.) Also, Unix man pages use a particular format
-which is different from what we use in GNU manuals.
-
- Please include an email address in the manual for where to report
-bugs _in the text of the manual_.
-
- Please do not use the term "pathname" that is used in Unix
-documentation; use "file name" (two words) instead. We use the term
-"path" only for search paths, which are lists of directory names.
-
- Please do not use the term "illegal" to refer to erroneous input to
-a computer program. Please use "invalid" for this, and reserve the
-term "illegal" for activities prohibited by law.
-
- Please do not write `()' after a function name just to indicate it
-is a function. `foo ()' is not a function, it is a function call with
-no arguments.
-
-
-File: standards.info, Node: Doc Strings and Manuals, Next: Manual Structure Details, Prev: GNU Manuals, Up: Documentation
-
-6.2 Doc Strings and Manuals
-===========================
-
-Some programming systems, such as Emacs, provide a documentation string
-for each function, command or variable. You may be tempted to write a
-reference manual by compiling the documentation strings and writing a
-little additional text to go around them--but you must not do it. That
-approach is a fundamental mistake. The text of well-written
-documentation strings will be entirely wrong for a manual.
-
- A documentation string needs to stand alone--when it appears on the
-screen, there will be no other text to introduce or explain it.
-Meanwhile, it can be rather informal in style.
-
- The text describing a function or variable in a manual must not stand
-alone; it appears in the context of a section or subsection. Other text
-at the beginning of the section should explain some of the concepts, and
-should often make some general points that apply to several functions or
-variables. The previous descriptions of functions and variables in the
-section will also have given information about the topic. A description
-written to stand alone would repeat some of that information; this
-redundancy looks bad. Meanwhile, the informality that is acceptable in
-a documentation string is totally unacceptable in a manual.
-
- The only good way to use documentation strings in writing a good
-manual is to use them as a source of information for writing good text.
-
-
-File: standards.info, Node: Manual Structure Details, Next: License for Manuals, Prev: Doc Strings and Manuals, Up: Documentation
-
-6.3 Manual Structure Details
-============================
-
-The title page of the manual should state the version of the programs or
-packages documented in the manual. The Top node of the manual should
-also contain this information. If the manual is changing more
-frequently than or independent of the program, also state a version
-number for the manual in both of these places.
-
- Each program documented in the manual should have a node named
-`PROGRAM Invocation' or `Invoking PROGRAM'. This node (together with
-its subnodes, if any) should describe the program's command line
-arguments and how to run it (the sort of information people would look
-for in a man page). Start with an `@example' containing a template for
-all the options and arguments that the program uses.
-
- Alternatively, put a menu item in some menu whose item name fits one
-of the above patterns. This identifies the node which that item points
-to as the node for this purpose, regardless of the node's actual name.
-
- The `--usage' feature of the Info reader looks for such a node or
-menu item in order to find the relevant text, so it is essential for
-every Texinfo file to have one.
-
- If one manual describes several programs, it should have such a node
-for each program described in the manual.
-
-
-File: standards.info, Node: License for Manuals, Next: Manual Credits, Prev: Manual Structure Details, Up: Documentation
-
-6.4 License for Manuals
-=======================
-
-Please use the GNU Free Documentation License for all GNU manuals that
-are more than a few pages long. Likewise for a collection of short
-documents--you only need one copy of the GNU FDL for the whole
-collection. For a single short document, you can use a very permissive
-non-copyleft license, to avoid taking up space with a long license.
-
- See `http://www.gnu.org/copyleft/fdl-howto.html' for more explanation
-of how to employ the GFDL.
-
- Note that it is not obligatory to include a copy of the GNU GPL or
-GNU LGPL in a manual whose license is neither the GPL nor the LGPL. It
-can be a good idea to include the program's license in a large manual;
-in a short manual, whose size would be increased considerably by
-including the program's license, it is probably better not to include
-it.
-
-
-File: standards.info, Node: Manual Credits, Next: Printed Manuals, Prev: License for Manuals, Up: Documentation
-
-6.5 Manual Credits
-==================
-
-Please credit the principal human writers of the manual as the authors,
-on the title page of the manual. If a company sponsored the work, thank
-the company in a suitable place in the manual, but do not cite the
-company as an author.
-
-
-File: standards.info, Node: Printed Manuals, Next: NEWS File, Prev: Manual Credits, Up: Documentation
-
-6.6 Printed Manuals
-===================
-
-The FSF publishes some GNU manuals in printed form. To encourage sales
-of these manuals, the on-line versions of the manual should mention at
-the very start that the printed manual is available and should point at
-information for getting it--for instance, with a link to the page
-`http://www.gnu.org/order/order.html'. This should not be included in
-the printed manual, though, because there it is redundant.
-
- It is also useful to explain in the on-line forms of the manual how
-the user can print out the manual from the sources.
-
-
-File: standards.info, Node: NEWS File, Next: Change Logs, Prev: Printed Manuals, Up: Documentation
-
-6.7 The NEWS File
-=================
-
-In addition to its manual, the package should have a file named `NEWS'
-which contains a list of user-visible changes worth mentioning. In
-each new release, add items to the front of the file and identify the
-version they pertain to. Don't discard old items; leave them in the
-file after the newer items. This way, a user upgrading from any
-previous version can see what is new.
-
- If the `NEWS' file gets very long, move some of the older items into
-a file named `ONEWS' and put a note at the end referring the user to
-that file.
-
-
-File: standards.info, Node: Change Logs, Next: Man Pages, Prev: NEWS File, Up: Documentation
-
-6.8 Change Logs
-===============
-
-Keep a change log to describe all the changes made to program source
-files. The purpose of this is so that people investigating bugs in the
-future will know about the changes that might have introduced the bug.
-Often a new bug can be found by looking at what was recently changed.
-More importantly, change logs can help you eliminate conceptual
-inconsistencies between different parts of a program, by giving you a
-history of how the conflicting concepts arose and who they came from.
-
-* Menu:
-
-* Change Log Concepts::
-* Style of Change Logs::
-* Simple Changes::
-* Conditional Changes::
-* Indicating the Part Changed::
-
-
-File: standards.info, Node: Change Log Concepts, Next: Style of Change Logs, Up: Change Logs
-
-6.8.1 Change Log Concepts
--------------------------
-
-You can think of the change log as a conceptual "undo list" which
-explains how earlier versions were different from the current version.
-People can see the current version; they don't need the change log to
-tell them what is in it. What they want from a change log is a clear
-explanation of how the earlier version differed.
-
- The change log file is normally called `ChangeLog' and covers an
-entire directory. Each directory can have its own change log, or a
-directory can use the change log of its parent directory--it's up to
-you.
-
- Another alternative is to record change log information with a
-version control system such as RCS or CVS. This can be converted
-automatically to a `ChangeLog' file using `rcs2log'; in Emacs, the
-command `C-x v a' (`vc-update-change-log') does the job.
-
- There's no need to describe the full purpose of the changes or how
-they work together. However, sometimes it is useful to write one line
-to describe the overall purpose of a change or a batch of changes. If
-you think that a change calls for explanation, you're probably right.
-Please do explain it--but please put the full explanation in comments
-in the code, where people will see it whenever they see the code. For
-example, "New function" is enough for the change log when you add a
-function, because there should be a comment before the function
-definition to explain what it does.
-
- In the past, we recommended not mentioning changes in non-software
-files (manuals, help files, etc.) in change logs. However, we've been
-advised that it is a good idea to include them, for the sake of
-copyright records.
-
- The easiest way to add an entry to `ChangeLog' is with the Emacs
-command `M-x add-change-log-entry'. An entry should have an asterisk,
-the name of the changed file, and then in parentheses the name of the
-changed functions, variables or whatever, followed by a colon. Then
-describe the changes you made to that function or variable.
-
-
-File: standards.info, Node: Style of Change Logs, Next: Simple Changes, Prev: Change Log Concepts, Up: Change Logs
-
-6.8.2 Style of Change Logs
---------------------------
-
-Here are some simple examples of change log entries, starting with the
-header line that says who made the change and when it was installed,
-followed by descriptions of specific changes. (These examples are
-drawn from Emacs and GCC.)
-
- 1998-08-17 Richard Stallman <rms@gnu.org>
-
- * register.el (insert-register): Return nil.
- (jump-to-register): Likewise.
-
- * sort.el (sort-subr): Return nil.
-
- * tex-mode.el (tex-bibtex-file, tex-file, tex-region):
- Restart the tex shell if process is gone or stopped.
- (tex-shell-running): New function.
-
- * expr.c (store_one_arg): Round size up for move_block_to_reg.
- (expand_call): Round up when emitting USE insns.
- * stmt.c (assign_parms): Round size up for move_block_from_reg.
-
- It's important to name the changed function or variable in full.
-Don't abbreviate function or variable names, and don't combine them.
-Subsequent maintainers will often search for a function name to find all
-the change log entries that pertain to it; if you abbreviate the name,
-they won't find it when they search.
-
- For example, some people are tempted to abbreviate groups of function
-names by writing `* register.el ({insert,jump-to}-register)'; this is
-not a good idea, since searching for `jump-to-register' or
-`insert-register' would not find that entry.
-
- Separate unrelated change log entries with blank lines. When two
-entries represent parts of the same change, so that they work together,
-then don't put blank lines between them. Then you can omit the file
-name and the asterisk when successive entries are in the same file.
-
- Break long lists of function names by closing continued lines with
-`)', rather than `,', and opening the continuation with `(' as in this
-example:
-
- * keyboard.c (menu_bar_items, tool_bar_items)
- (Fexecute_extended_command): Deal with `keymap' property.
-
- When you install someone else's changes, put the contributor's name
-in the change log entry rather than in the text of the entry. In other
-words, write this:
-
- 2002-07-14 John Doe <jdoe@gnu.org>
-
- * sewing.c: Make it sew.
-
-rather than this:
-
- 2002-07-14 Usual Maintainer <usual@gnu.org>
-
- * sewing.c: Make it sew. Patch by jdoe@gnu.org.
-
- As for the date, that should be the date you applied the change.
-
-
-File: standards.info, Node: Simple Changes, Next: Conditional Changes, Prev: Style of Change Logs, Up: Change Logs
-
-6.8.3 Simple Changes
---------------------
-
-Certain simple kinds of changes don't need much detail in the change
-log.
-
- When you change the calling sequence of a function in a simple
-fashion, and you change all the callers of the function to use the new
-calling sequence, there is no need to make individual entries for all
-the callers that you changed. Just write in the entry for the function
-being called, "All callers changed"--like this:
-
- * keyboard.c (Fcommand_execute): New arg SPECIAL.
- All callers changed.
-
- When you change just comments or doc strings, it is enough to write
-an entry for the file, without mentioning the functions. Just "Doc
-fixes" is enough for the change log.
-
- There's no technical need to make change log entries for
-documentation files. This is because documentation is not susceptible
-to bugs that are hard to fix. Documentation does not consist of parts
-that must interact in a precisely engineered fashion. To correct an
-error, you need not know the history of the erroneous passage; it is
-enough to compare what the documentation says with the way the program
-actually works.
-
- However, you should keep change logs for documentation files when the
-project gets copyright assignments from its contributors, so as to make
-the records of authorship more accurate.
-
-
-File: standards.info, Node: Conditional Changes, Next: Indicating the Part Changed, Prev: Simple Changes, Up: Change Logs
-
-6.8.4 Conditional Changes
--------------------------
-
-C programs often contain compile-time `#if' conditionals. Many changes
-are conditional; sometimes you add a new definition which is entirely
-contained in a conditional. It is very useful to indicate in the
-change log the conditions for which the change applies.
-
- Our convention for indicating conditional changes is to use square
-brackets around the name of the condition.
-
- Here is a simple example, describing a change which is conditional
-but does not have a function or entity name associated with it:
-
- * xterm.c [SOLARIS2]: Include string.h.
-
- Here is an entry describing a new definition which is entirely
-conditional. This new definition for the macro `FRAME_WINDOW_P' is
-used only when `HAVE_X_WINDOWS' is defined:
-
- * frame.h [HAVE_X_WINDOWS] (FRAME_WINDOW_P): Macro defined.
-
- Here is an entry for a change within the function `init_display',
-whose definition as a whole is unconditional, but the changes themselves
-are contained in a `#ifdef HAVE_LIBNCURSES' conditional:
-
- * dispnew.c (init_display) [HAVE_LIBNCURSES]: If X, call tgetent.
-
- Here is an entry for a change that takes affect only when a certain
-macro is _not_ defined:
-
- (gethostname) [!HAVE_SOCKETS]: Replace with winsock version.
-
-
-File: standards.info, Node: Indicating the Part Changed, Prev: Conditional Changes, Up: Change Logs
-
-6.8.5 Indicating the Part Changed
----------------------------------
-
-Indicate the part of a function which changed by using angle brackets
-enclosing an indication of what the changed part does. Here is an entry
-for a change in the part of the function `sh-while-getopts' that deals
-with `sh' commands:
-
- * progmodes/sh-script.el (sh-while-getopts) <sh>: Handle case that
- user-specified option string is empty.
-
-
-File: standards.info, Node: Man Pages, Next: Reading other Manuals, Prev: Change Logs, Up: Documentation
-
-6.9 Man Pages
-=============
-
-In the GNU project, man pages are secondary. It is not necessary or
-expected for every GNU program to have a man page, but some of them do.
-It's your choice whether to include a man page in your program.
-
- When you make this decision, consider that supporting a man page
-requires continual effort each time the program is changed. The time
-you spend on the man page is time taken away from more useful work.
-
- For a simple program which changes little, updating the man page may
-be a small job. Then there is little reason not to include a man page,
-if you have one.
-
- For a large program that changes a great deal, updating a man page
-may be a substantial burden. If a user offers to donate a man page,
-you may find this gift costly to accept. It may be better to refuse
-the man page unless the same person agrees to take full responsibility
-for maintaining it--so that you can wash your hands of it entirely. If
-this volunteer later ceases to do the job, then don't feel obliged to
-pick it up yourself; it may be better to withdraw the man page from the
-distribution until someone else agrees to update it.
-
- When a program changes only a little, you may feel that the
-discrepancies are small enough that the man page remains useful without
-updating. If so, put a prominent note near the beginning of the man
-page explaining that you don't maintain it and that the Texinfo manual
-is more authoritative. The note should say how to access the Texinfo
-documentation.
-
- Be sure that man pages include a copyright statement and free
-license. The simple all-permissive license is appropriate for simple
-man pages (*note License Notices for Other Files: (maintain)License
-Notices for Other Files.).
-
- For long man pages, with enough explanation and documentation that
-they can be considered true manuals, use the GFDL (*note License for
-Manuals::).
-
- Finally, the GNU help2man program
-(`http://www.gnu.org/software/help2man/') is one way to automate
-generation of a man page, in this case from `--help' output. This is
-sufficient in many cases.
-
-
-File: standards.info, Node: Reading other Manuals, Prev: Man Pages, Up: Documentation
-
-6.10 Reading other Manuals
-==========================
-
-There may be non-free books or documentation files that describe the
-program you are documenting.
-
- It is ok to use these documents for reference, just as the author of
-a new algebra textbook can read other books on algebra. A large portion
-of any non-fiction book consists of facts, in this case facts about how
-a certain program works, and these facts are necessarily the same for
-everyone who writes about the subject. But be careful not to copy your
-outline structure, wording, tables or examples from preexisting non-free
-documentation. Copying from free documentation may be ok; please check
-with the FSF about the individual case.
-
-
-File: standards.info, Node: Managing Releases, Next: References, Prev: Documentation, Up: Top
-
-7 The Release Process
-*********************
-
-Making a release is more than just bundling up your source files in a
-tar file and putting it up for FTP. You should set up your software so
-that it can be configured to run on a variety of systems. Your Makefile
-should conform to the GNU standards described below, and your directory
-layout should also conform to the standards discussed below. Doing so
-makes it easy to include your package into the larger framework of all
-GNU software.
-
-* Menu:
-
-* Configuration:: How configuration of GNU packages should work.
-* Makefile Conventions:: Makefile conventions.
-* Releases:: Making releases
-
-
-File: standards.info, Node: Configuration, Next: Makefile Conventions, Up: Managing Releases
-
-7.1 How Configuration Should Work
-=================================
-
-Each GNU distribution should come with a shell script named
-`configure'. This script is given arguments which describe the kind of
-machine and system you want to compile the program for. The
-`configure' script must record the configuration options so that they
-affect compilation.
-
- The description here is the specification of the interface for the
-`configure' script in GNU packages. Many packages implement it using
-GNU Autoconf (*note Introduction: (autoconf)Top.) and/or GNU Automake
-(*note Introduction: (automake)Top.), but you do not have to use these
-tools. You can implement it any way you like; for instance, by making
-`configure' be a wrapper around a completely different configuration
-system.
-
- Another way for the `configure' script to operate is to make a link
-from a standard name such as `config.h' to the proper configuration
-file for the chosen system. If you use this technique, the
-distribution should _not_ contain a file named `config.h'. This is so
-that people won't be able to build the program without configuring it
-first.
-
- Another thing that `configure' can do is to edit the Makefile. If
-you do this, the distribution should _not_ contain a file named
-`Makefile'. Instead, it should include a file `Makefile.in' which
-contains the input used for editing. Once again, this is so that people
-won't be able to build the program without configuring it first.
-
- If `configure' does write the `Makefile', then `Makefile' should
-have a target named `Makefile' which causes `configure' to be rerun,
-setting up the same configuration that was set up last time. The files
-that `configure' reads should be listed as dependencies of `Makefile'.
-
- All the files which are output from the `configure' script should
-have comments at the beginning explaining that they were generated
-automatically using `configure'. This is so that users won't think of
-trying to edit them by hand.
-
- The `configure' script should write a file named `config.status'
-which describes which configuration options were specified when the
-program was last configured. This file should be a shell script which,
-if run, will recreate the same configuration.
-
- The `configure' script should accept an option of the form
-`--srcdir=DIRNAME' to specify the directory where sources are found (if
-it is not the current directory). This makes it possible to build the
-program in a separate directory, so that the actual source directory is
-not modified.
-
- If the user does not specify `--srcdir', then `configure' should
-check both `.' and `..' to see if it can find the sources. If it finds
-the sources in one of these places, it should use them from there.
-Otherwise, it should report that it cannot find the sources, and should
-exit with nonzero status.
-
- Usually the easy way to support `--srcdir' is by editing a
-definition of `VPATH' into the Makefile. Some rules may need to refer
-explicitly to the specified source directory. To make this possible,
-`configure' can add to the Makefile a variable named `srcdir' whose
-value is precisely the specified directory.
-
- In addition, the `configure' script should take options
-corresponding to most of the standard directory variables (*note
-Directory Variables::). Here is the list:
-
- --prefix --exec-prefix --bindir --sbindir --libexecdir --sysconfdir
- --sharedstatedir --localstatedir --libdir --includedir --oldincludedir
- --datarootdir --datadir --infodir --localedir --mandir --docdir
- --htmldir --dvidir --pdfdir --psdir
-
- The `configure' script should also take an argument which specifies
-the type of system to build the program for. This argument should look
-like this:
-
- CPU-COMPANY-SYSTEM
-
- For example, an Athlon-based GNU/Linux system might be
-`i686-pc-linux-gnu'.
-
- The `configure' script needs to be able to decode all plausible
-alternatives for how to describe a machine. Thus,
-`athlon-pc-gnu/linux' would be a valid alias. There is a shell script
-called `config.sub'
-(http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD)
-that you can use as a subroutine to validate system types and
-canonicalize aliases.
-
- The `configure' script should also take the option
-`--build=BUILDTYPE', which should be equivalent to a plain BUILDTYPE
-argument. For example, `configure --build=i686-pc-linux-gnu' is
-equivalent to `configure i686-pc-linux-gnu'. When the build type is
-not specified by an option or argument, the `configure' script should
-normally guess it using the shell script `config.guess'
-(http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD).
-
- Other options are permitted to specify in more detail the software
-or hardware present on the machine, to include or exclude optional parts
-of the package, or to adjust the name of some tools or arguments to
-them:
-
-`--enable-FEATURE[=PARAMETER]'
- Configure the package to build and install an optional user-level
- facility called FEATURE. This allows users to choose which
- optional features to include. Giving an optional PARAMETER of
- `no' should omit FEATURE, if it is built by default.
-
- No `--enable' option should *ever* cause one feature to replace
- another. No `--enable' option should ever substitute one useful
- behavior for another useful behavior. The only proper use for
- `--enable' is for questions of whether to build part of the program
- or exclude it.
-
-`--with-PACKAGE'
- The package PACKAGE will be installed, so configure this package
- to work with PACKAGE.
-
- Possible values of PACKAGE include `gnu-as' (or `gas'), `gnu-ld',
- `gnu-libc', `gdb', `x', and `x-toolkit'.
-
- Do not use a `--with' option to specify the file name to use to
- find certain files. That is outside the scope of what `--with'
- options are for.
-
-`VARIABLE=VALUE'
- Set the value of the variable VARIABLE to VALUE. This is used to
- override the default values of commands or arguments in the build
- process. For example, the user could issue `configure CFLAGS=-g
- CXXFLAGS=-g' to build with debugging information and without the
- default optimization.
-
- Specifying variables as arguments to `configure', like this:
- ./configure CC=gcc
- is preferable to setting them in environment variables:
- CC=gcc ./configure
- as it helps to recreate the same configuration later with
- `config.status'. However, both methods should be supported.
-
- All `configure' scripts should accept all of the "detail" options
-and the variable settings, whether or not they make any difference to
-the particular package at hand. In particular, they should accept any
-option that starts with `--with-' or `--enable-'. This is so users
-will be able to configure an entire GNU source tree at once with a
-single set of options.
-
- You will note that the categories `--with-' and `--enable-' are
-narrow: they *do not* provide a place for any sort of option you might
-think of. That is deliberate. We want to limit the possible
-configuration options in GNU software. We do not want GNU programs to
-have idiosyncratic configuration options.
-
- Packages that perform part of the compilation process may support
-cross-compilation. In such a case, the host and target machines for the
-program may be different.
-
- The `configure' script should normally treat the specified type of
-system as both the host and the target, thus producing a program which
-works for the same type of machine that it runs on.
-
- To compile a program to run on a host type that differs from the
-build type, use the configure option `--host=HOSTTYPE', where HOSTTYPE
-uses the same syntax as BUILDTYPE. The host type normally defaults to
-the build type.
-
- To configure a cross-compiler, cross-assembler, or what have you, you
-should specify a target different from the host, using the configure
-option `--target=TARGETTYPE'. The syntax for TARGETTYPE is the same as
-for the host type. So the command would look like this:
-
- ./configure --host=HOSTTYPE --target=TARGETTYPE
-
- The target type normally defaults to the host type. Programs for
-which cross-operation is not meaningful need not accept the `--target'
-option, because configuring an entire operating system for
-cross-operation is not a meaningful operation.
-
- Some programs have ways of configuring themselves automatically. If
-your program is set up to do this, your `configure' script can simply
-ignore most of its arguments.
-
-
-File: standards.info, Node: Makefile Conventions, Next: Releases, Prev: Configuration, Up: Managing Releases
-
-7.2 Makefile Conventions
-========================
-
-This node describes conventions for writing the Makefiles for GNU
-programs. Using Automake will help you write a Makefile that follows
-these conventions.
-
-* Menu:
-
-* Makefile Basics:: General conventions for Makefiles.
-* Utilities in Makefiles:: Utilities to be used in Makefiles.
-* Command Variables:: Variables for specifying commands.
-* DESTDIR:: Supporting staged installs.
-* Directory Variables:: Variables for installation directories.
-* Standard Targets:: Standard targets for users.
-* Install Command Categories:: Three categories of commands in the `install'
- rule: normal, pre-install and post-install.
-
-
-File: standards.info, Node: Makefile Basics, Next: Utilities in Makefiles, Up: Makefile Conventions
-
-7.2.1 General Conventions for Makefiles
----------------------------------------
-
-Every Makefile should contain this line:
-
- SHELL = /bin/sh
-
-to avoid trouble on systems where the `SHELL' variable might be
-inherited from the environment. (This is never a problem with GNU
-`make'.)
-
- Different `make' programs have incompatible suffix lists and
-implicit rules, and this sometimes creates confusion or misbehavior. So
-it is a good idea to set the suffix list explicitly using only the
-suffixes you need in the particular Makefile, like this:
-
- .SUFFIXES:
- .SUFFIXES: .c .o
-
-The first line clears out the suffix list, the second introduces all
-suffixes which may be subject to implicit rules in this Makefile.
-
- Don't assume that `.' is in the path for command execution. When
-you need to run programs that are a part of your package during the
-make, please make sure that it uses `./' if the program is built as
-part of the make or `$(srcdir)/' if the file is an unchanging part of
-the source code. Without one of these prefixes, the current search
-path is used.
-
- The distinction between `./' (the "build directory") and
-`$(srcdir)/' (the "source directory") is important because users can
-build in a separate directory using the `--srcdir' option to
-`configure'. A rule of the form:
-
- foo.1 : foo.man sedscript
- sed -e sedscript foo.man > foo.1
-
-will fail when the build directory is not the source directory, because
-`foo.man' and `sedscript' are in the source directory.
-
- When using GNU `make', relying on `VPATH' to find the source file
-will work in the case where there is a single dependency file, since
-the `make' automatic variable `$<' will represent the source file
-wherever it is. (Many versions of `make' set `$<' only in implicit
-rules.) A Makefile target like
-
- foo.o : bar.c
- $(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o
-
-should instead be written as
-
- foo.o : bar.c
- $(CC) -I. -I$(srcdir) $(CFLAGS) -c $< -o $@
-
-in order to allow `VPATH' to work correctly. When the target has
-multiple dependencies, using an explicit `$(srcdir)' is the easiest way
-to make the rule work well. For example, the target above for `foo.1'
-is best written as:
-
- foo.1 : foo.man sedscript
- sed -e $(srcdir)/sedscript $(srcdir)/foo.man > $@
-
- GNU distributions usually contain some files which are not source
-files--for example, Info files, and the output from Autoconf, Automake,
-Bison or Flex. Since these files normally appear in the source
-directory, they should always appear in the source directory, not in the
-build directory. So Makefile rules to update them should put the
-updated files in the source directory.
-
- However, if a file does not appear in the distribution, then the
-Makefile should not put it in the source directory, because building a
-program in ordinary circumstances should not modify the source directory
-in any way.
-
- Try to make the build and installation targets, at least (and all
-their subtargets) work correctly with a parallel `make'.
-
-
-File: standards.info, Node: Utilities in Makefiles, Next: Command Variables, Prev: Makefile Basics, Up: Makefile Conventions
-
-7.2.2 Utilities in Makefiles
-----------------------------
-
-Write the Makefile commands (and any shell scripts, such as
-`configure') to run in `sh', not in `csh'. Don't use any special
-features of `ksh' or `bash'.
-
- The `configure' script and the Makefile rules for building and
-installation should not use any utilities directly except these:
-
- cat cmp cp diff echo egrep expr false grep install-info
- ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true
-
- The compression program `gzip' can be used in the `dist' rule.
-
- Stick to the generally supported options for these programs. For
-example, don't use `mkdir -p', convenient as it may be, because most
-systems don't support it.
-
- It is a good idea to avoid creating symbolic links in makefiles,
-since a few systems don't support them.
-
- The Makefile rules for building and installation can also use
-compilers and related programs, but should do so via `make' variables
-so that the user can substitute alternatives. Here are some of the
-programs we mean:
-
- ar bison cc flex install ld ldconfig lex
- make makeinfo ranlib texi2dvi yacc
-
- Use the following `make' variables to run those programs:
-
- $(AR) $(BISON) $(CC) $(FLEX) $(INSTALL) $(LD) $(LDCONFIG) $(LEX)
- $(MAKE) $(MAKEINFO) $(RANLIB) $(TEXI2DVI) $(YACC)
-
- When you use `ranlib' or `ldconfig', you should make sure nothing
-bad happens if the system does not have the program in question.
-Arrange to ignore an error from that command, and print a message before
-the command to tell the user that failure of this command does not mean
-a problem. (The Autoconf `AC_PROG_RANLIB' macro can help with this.)
-
- If you use symbolic links, you should implement a fallback for
-systems that don't have symbolic links.
-
- Additional utilities that can be used via Make variables are:
-
- chgrp chmod chown mknod
-
- It is ok to use other utilities in Makefile portions (or scripts)
-intended only for particular systems where you know those utilities
-exist.
-
-
-File: standards.info, Node: Command Variables, Next: DESTDIR, Prev: Utilities in Makefiles, Up: Makefile Conventions
-
-7.2.3 Variables for Specifying Commands
----------------------------------------
-
-Makefiles should provide variables for overriding certain commands,
-options, and so on.
-
- In particular, you should run most utility programs via variables.
-Thus, if you use Bison, have a variable named `BISON' whose default
-value is set with `BISON = bison', and refer to it with `$(BISON)'
-whenever you need to use Bison.
-
- File management utilities such as `ln', `rm', `mv', and so on, need
-not be referred to through variables in this way, since users don't
-need to replace them with other programs.
-
- Each program-name variable should come with an options variable that
-is used to supply options to the program. Append `FLAGS' to the
-program-name variable name to get the options variable name--for
-example, `BISONFLAGS'. (The names `CFLAGS' for the C compiler,
-`YFLAGS' for yacc, and `LFLAGS' for lex, are exceptions to this rule,
-but we keep them because they are standard.) Use `CPPFLAGS' in any
-compilation command that runs the preprocessor, and use `LDFLAGS' in
-any compilation command that does linking as well as in any direct use
-of `ld'.
-
- If there are C compiler options that _must_ be used for proper
-compilation of certain files, do not include them in `CFLAGS'. Users
-expect to be able to specify `CFLAGS' freely themselves. Instead,
-arrange to pass the necessary options to the C compiler independently
-of `CFLAGS', by writing them explicitly in the compilation commands or
-by defining an implicit rule, like this:
-
- CFLAGS = -g
- ALL_CFLAGS = -I. $(CFLAGS)
- .c.o:
- $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
-
- Do include the `-g' option in `CFLAGS', because that is not
-_required_ for proper compilation. You can consider it a default that
-is only recommended. If the package is set up so that it is compiled
-with GCC by default, then you might as well include `-O' in the default
-value of `CFLAGS' as well.
-
- Put `CFLAGS' last in the compilation command, after other variables
-containing compiler options, so the user can use `CFLAGS' to override
-the others.
-
- `CFLAGS' should be used in every invocation of the C compiler, both
-those which do compilation and those which do linking.
-
- Every Makefile should define the variable `INSTALL', which is the
-basic command for installing a file into the system.
-
- Every Makefile should also define the variables `INSTALL_PROGRAM'
-and `INSTALL_DATA'. (The default for `INSTALL_PROGRAM' should be
-`$(INSTALL)'; the default for `INSTALL_DATA' should be `${INSTALL} -m
-644'.) Then it should use those variables as the commands for actual
-installation, for executables and non-executables respectively.
-Minimal use of these variables is as follows:
-
- $(INSTALL_PROGRAM) foo $(bindir)/foo
- $(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a
-
- However, it is preferable to support a `DESTDIR' prefix on the
-target files, as explained in the next section.
-
-Always use a file name, not a directory name, as the second argument of
-the installation commands. Use a separate command for each file to be
-installed.
-
-
-File: standards.info, Node: DESTDIR, Next: Directory Variables, Prev: Command Variables, Up: Makefile Conventions
-
-7.2.4 `DESTDIR': support for staged installs
---------------------------------------------
-
-`DESTDIR' is a variable prepended to each installed target file, like
-this:
-
- $(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo
- $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a
-
- The `DESTDIR' variable is specified by the user on the `make'
-command line. For example:
-
- make DESTDIR=/tmp/stage install
-
-`DESTDIR' should be supported only in the `install*' and `uninstall*'
-targets, as those are the only targets where it is useful.
-
- If your installation step would normally install
-`/usr/local/bin/foo' and `/usr/local/lib/libfoo.a', then an
-installation invoked as in the example above would install
-`/tmp/stage/usr/local/bin/foo' and `/tmp/stage/usr/local/lib/libfoo.a'
-instead.
-
- Prepending the variable `DESTDIR' to each target in this way
-provides for "staged installs", where the installed files are not
-placed directly into their expected location but are instead copied
-into a temporary location (`DESTDIR'). However, installed files
-maintain their relative directory structure and any embedded file names
-will not be modified.
-
- You should not set the value of `DESTDIR' in your `Makefile' at all;
-then the files are installed into their expected locations by default.
-Also, specifying `DESTDIR' should not change the operation of the
-software in any way, so its value should not be included in any file
-contents.
-
- `DESTDIR' support is commonly used in package creation. It is also
-helpful to users who want to understand what a given package will
-install where, and to allow users who don't normally have permissions
-to install into protected areas to build and install before gaining
-those permissions. Finally, it can be useful with tools such as
-`stow', where code is installed in one place but made to appear to be
-installed somewhere else using symbolic links or special mount
-operations. So, we strongly recommend GNU packages support `DESTDIR',
-though it is not an absolute requirement.
-
-
-File: standards.info, Node: Directory Variables, Next: Standard Targets, Prev: DESTDIR, Up: Makefile Conventions
-
-7.2.5 Variables for Installation Directories
---------------------------------------------
-
-Installation directories should always be named by variables, so it is
-easy to install in a nonstandard place. The standard names for these
-variables and the values they should have in GNU packages are described
-below. They are based on a standard file system layout; variants of it
-are used in GNU/Linux and other modern operating systems.
-
- Installers are expected to override these values when calling `make'
-(e.g., `make prefix=/usr install' or `configure' (e.g., `configure
---prefix=/usr'). GNU packages should not try to guess which value
-should be appropriate for these variables on the system they are being
-installed onto: use the default settings specified here so that all GNU
-packages behave identically, allowing the installer to achieve any
-desired layout.
-
- These first two variables set the root for the installation. All the
-other installation directories should be subdirectories of one of these
-two, and nothing should be directly installed into these two
-directories.
-
-`prefix'
- A prefix used in constructing the default values of the variables
- listed below. The default value of `prefix' should be
- `/usr/local'. When building the complete GNU system, the prefix
- will be empty and `/usr' will be a symbolic link to `/'. (If you
- are using Autoconf, write it as `@prefix@'.)
-
- Running `make install' with a different value of `prefix' from the
- one used to build the program should _not_ recompile the program.
-
-`exec_prefix'
- A prefix used in constructing the default values of some of the
- variables listed below. The default value of `exec_prefix' should
- be `$(prefix)'. (If you are using Autoconf, write it as
- `@exec_prefix@'.)
-
- Generally, `$(exec_prefix)' is used for directories that contain
- machine-specific files (such as executables and subroutine
- libraries), while `$(prefix)' is used directly for other
- directories.
-
- Running `make install' with a different value of `exec_prefix'
- from the one used to build the program should _not_ recompile the
- program.
-
- Executable programs are installed in one of the following
-directories.
-
-`bindir'
- The directory for installing executable programs that users can
- run. This should normally be `/usr/local/bin', but write it as
- `$(exec_prefix)/bin'. (If you are using Autoconf, write it as
- `@bindir@'.)
-
-`sbindir'
- The directory for installing executable programs that can be run
- from the shell, but are only generally useful to system
- administrators. This should normally be `/usr/local/sbin', but
- write it as `$(exec_prefix)/sbin'. (If you are using Autoconf,
- write it as `@sbindir@'.)
-
-`libexecdir'
- The directory for installing executable programs to be run by other
- programs rather than by users. This directory should normally be
- `/usr/local/libexec', but write it as `$(exec_prefix)/libexec'.
- (If you are using Autoconf, write it as `@libexecdir@'.)
-
- The definition of `libexecdir' is the same for all packages, so
- you should install your data in a subdirectory thereof. Most
- packages install their data under `$(libexecdir)/PACKAGE-NAME/',
- possibly within additional subdirectories thereof, such as
- `$(libexecdir)/PACKAGE-NAME/MACHINE/VERSION'.
-
- Data files used by the program during its execution are divided into
-categories in two ways.
-
- * Some files are normally modified by programs; others are never
- normally modified (though users may edit some of these).
-
- * Some files are architecture-independent and can be shared by all
- machines at a site; some are architecture-dependent and can be
- shared only by machines of the same kind and operating system;
- others may never be shared between two machines.
-
- This makes for six different possibilities. However, we want to
-discourage the use of architecture-dependent files, aside from object
-files and libraries. It is much cleaner to make other data files
-architecture-independent, and it is generally not hard.
-
- Here are the variables Makefiles should use to specify directories
-to put these various kinds of files in:
-
-`datarootdir'
- The root of the directory tree for read-only
- architecture-independent data files. This should normally be
- `/usr/local/share', but write it as `$(prefix)/share'. (If you
- are using Autoconf, write it as `@datarootdir@'.) `datadir''s
- default value is based on this variable; so are `infodir',
- `mandir', and others.
-
-`datadir'
- The directory for installing idiosyncratic read-only
- architecture-independent data files for this program. This is
- usually the same place as `datarootdir', but we use the two
- separate variables so that you can move these program-specific
- files without altering the location for Info files, man pages, etc.
-
- This should normally be `/usr/local/share', but write it as
- `$(datarootdir)'. (If you are using Autoconf, write it as
- `@datadir@'.)
-
- The definition of `datadir' is the same for all packages, so you
- should install your data in a subdirectory thereof. Most packages
- install their data under `$(datadir)/PACKAGE-NAME/'.
-
-`sysconfdir'
- The directory for installing read-only data files that pertain to a
- single machine-that is to say, files for configuring a host.
- Mailer and network configuration files, `/etc/passwd', and so
- forth belong here. All the files in this directory should be
- ordinary ASCII text files. This directory should normally be
- `/usr/local/etc', but write it as `$(prefix)/etc'. (If you are
- using Autoconf, write it as `@sysconfdir@'.)
-
- Do not install executables here in this directory (they probably
- belong in `$(libexecdir)' or `$(sbindir)'). Also do not install
- files that are modified in the normal course of their use (programs
- whose purpose is to change the configuration of the system
- excluded). Those probably belong in `$(localstatedir)'.
-
-`sharedstatedir'
- The directory for installing architecture-independent data files
- which the programs modify while they run. This should normally be
- `/usr/local/com', but write it as `$(prefix)/com'. (If you are
- using Autoconf, write it as `@sharedstatedir@'.)
-
-`localstatedir'
- The directory for installing data files which the programs modify
- while they run, and that pertain to one specific machine. Users
- should never need to modify files in this directory to configure
- the package's operation; put such configuration information in
- separate files that go in `$(datadir)' or `$(sysconfdir)'.
- `$(localstatedir)' should normally be `/usr/local/var', but write
- it as `$(prefix)/var'. (If you are using Autoconf, write it as
- `@localstatedir@'.)
-
- These variables specify the directory for installing certain specific
-types of files, if your program has them. Every GNU package should
-have Info files, so every program needs `infodir', but not all need
-`libdir' or `lispdir'.
-
-`includedir'
- The directory for installing header files to be included by user
- programs with the C `#include' preprocessor directive. This
- should normally be `/usr/local/include', but write it as
- `$(prefix)/include'. (If you are using Autoconf, write it as
- `@includedir@'.)
-
- Most compilers other than GCC do not look for header files in
- directory `/usr/local/include'. So installing the header files
- this way is only useful with GCC. Sometimes this is not a problem
- because some libraries are only really intended to work with GCC.
- But some libraries are intended to work with other compilers.
- They should install their header files in two places, one
- specified by `includedir' and one specified by `oldincludedir'.
-
-`oldincludedir'
- The directory for installing `#include' header files for use with
- compilers other than GCC. This should normally be `/usr/include'.
- (If you are using Autoconf, you can write it as `@oldincludedir@'.)
-
- The Makefile commands should check whether the value of
- `oldincludedir' is empty. If it is, they should not try to use
- it; they should cancel the second installation of the header files.
-
- A package should not replace an existing header in this directory
- unless the header came from the same package. Thus, if your Foo
- package provides a header file `foo.h', then it should install the
- header file in the `oldincludedir' directory if either (1) there
- is no `foo.h' there or (2) the `foo.h' that exists came from the
- Foo package.
-
- To tell whether `foo.h' came from the Foo package, put a magic
- string in the file--part of a comment--and `grep' for that string.
-
-`docdir'
- The directory for installing documentation files (other than Info)
- for this package. By default, it should be
- `/usr/local/share/doc/YOURPKG', but it should be written as
- `$(datarootdir)/doc/YOURPKG'. (If you are using Autoconf, write
- it as `@docdir@'.) The YOURPKG subdirectory, which may include a
- version number, prevents collisions among files with common names,
- such as `README'.
-
-`infodir'
- The directory for installing the Info files for this package. By
- default, it should be `/usr/local/share/info', but it should be
- written as `$(datarootdir)/info'. (If you are using Autoconf,
- write it as `@infodir@'.) `infodir' is separate from `docdir' for
- compatibility with existing practice.
-
-`htmldir'
-`dvidir'
-`pdfdir'
-`psdir'
- Directories for installing documentation files in the particular
- format. They should all be set to `$(docdir)' by default. (If
- you are using Autoconf, write them as `@htmldir@', `@dvidir@',
- etc.) Packages which supply several translations of their
- documentation should install them in `$(htmldir)/'LL,
- `$(pdfdir)/'LL, etc. where LL is a locale abbreviation such as
- `en' or `pt_BR'.
-
-`libdir'
- The directory for object files and libraries of object code. Do
- not install executables here, they probably ought to go in
- `$(libexecdir)' instead. The value of `libdir' should normally be
- `/usr/local/lib', but write it as `$(exec_prefix)/lib'. (If you
- are using Autoconf, write it as `@libdir@'.)
-
-`lispdir'
- The directory for installing any Emacs Lisp files in this package.
- By default, it should be `/usr/local/share/emacs/site-lisp', but it
- should be written as `$(datarootdir)/emacs/site-lisp'.
-
- If you are using Autoconf, write the default as `@lispdir@'. In
- order to make `@lispdir@' work, you need the following lines in
- your `configure.in' file:
-
- lispdir='${datarootdir}/emacs/site-lisp'
- AC_SUBST(lispdir)
-
-`localedir'
- The directory for installing locale-specific message catalogs for
- this package. By default, it should be `/usr/local/share/locale',
- but it should be written as `$(datarootdir)/locale'. (If you are
- using Autoconf, write it as `@localedir@'.) This directory
- usually has a subdirectory per locale.
-
- Unix-style man pages are installed in one of the following:
-
-`mandir'
- The top-level directory for installing the man pages (if any) for
- this package. It will normally be `/usr/local/share/man', but you
- should write it as `$(datarootdir)/man'. (If you are using
- Autoconf, write it as `@mandir@'.)
-
-`man1dir'
- The directory for installing section 1 man pages. Write it as
- `$(mandir)/man1'.
-
-`man2dir'
- The directory for installing section 2 man pages. Write it as
- `$(mandir)/man2'
-
-`...'
- *Don't make the primary documentation for any GNU software be a
- man page. Write a manual in Texinfo instead. Man pages are just
- for the sake of people running GNU software on Unix, which is a
- secondary application only.*
-
-`manext'
- The file name extension for the installed man page. This should
- contain a period followed by the appropriate digit; it should
- normally be `.1'.
-
-`man1ext'
- The file name extension for installed section 1 man pages.
-
-`man2ext'
- The file name extension for installed section 2 man pages.
-
-`...'
- Use these names instead of `manext' if the package needs to
- install man pages in more than one section of the manual.
-
- And finally, you should set the following variable:
-
-`srcdir'
- The directory for the sources being compiled. The value of this
- variable is normally inserted by the `configure' shell script.
- (If you are using Autoconf, use `srcdir = @srcdir@'.)
-
- For example:
-
- # Common prefix for installation directories.
- # NOTE: This directory must exist when you start the install.
- prefix = /usr/local
- datarootdir = $(prefix)/share
- datadir = $(datarootdir)
- exec_prefix = $(prefix)
- # Where to put the executable for the command `gcc'.
- bindir = $(exec_prefix)/bin
- # Where to put the directories used by the compiler.
- libexecdir = $(exec_prefix)/libexec
- # Where to put the Info files.
- infodir = $(datarootdir)/info
-
- If your program installs a large number of files into one of the
-standard user-specified directories, it might be useful to group them
-into a subdirectory particular to that program. If you do this, you
-should write the `install' rule to create these subdirectories.
-
- Do not expect the user to include the subdirectory name in the value
-of any of the variables listed above. The idea of having a uniform set
-of variable names for installation directories is to enable the user to
-specify the exact same values for several different GNU packages. In
-order for this to be useful, all the packages must be designed so that
-they will work sensibly when the user does so.
-
- At times, not all of these variables may be implemented in the
-current release of Autoconf and/or Automake; but as of Autoconf 2.60, we
-believe all of them are. When any are missing, the descriptions here
-serve as specifications for what Autoconf will implement. As a
-programmer, you can either use a development version of Autoconf or
-avoid using these variables until a stable release is made which
-supports them.
-
-
-File: standards.info, Node: Standard Targets, Next: Install Command Categories, Prev: Directory Variables, Up: Makefile Conventions
-
-7.2.6 Standard Targets for Users
---------------------------------
-
-All GNU programs should have the following targets in their Makefiles:
-
-`all'
- Compile the entire program. This should be the default target.
- This target need not rebuild any documentation files; Info files
- should normally be included in the distribution, and DVI (and other
- documentation format) files should be made only when explicitly
- asked for.
-
- By default, the Make rules should compile and link with `-g', so
- that executable programs have debugging symbols. Users who don't
- mind being helpless can strip the executables later if they wish.
-
-`install'
- Compile the program and copy the executables, libraries, and so on
- to the file names where they should reside for actual use. If
- there is a simple test to verify that a program is properly
- installed, this target should run that test.
-
- Do not strip executables when installing them. Devil-may-care
- users can use the `install-strip' target to do that.
-
- If possible, write the `install' target rule so that it does not
- modify anything in the directory where the program was built,
- provided `make all' has just been done. This is convenient for
- building the program under one user name and installing it under
- another.
-
- The commands should create all the directories in which files are
- to be installed, if they don't already exist. This includes the
- directories specified as the values of the variables `prefix' and
- `exec_prefix', as well as all subdirectories that are needed. One
- way to do this is by means of an `installdirs' target as described
- below.
-
- Use `-' before any command for installing a man page, so that
- `make' will ignore any errors. This is in case there are systems
- that don't have the Unix man page documentation system installed.
-
- The way to install Info files is to copy them into `$(infodir)'
- with `$(INSTALL_DATA)' (*note Command Variables::), and then run
- the `install-info' program if it is present. `install-info' is a
- program that edits the Info `dir' file to add or update the menu
- entry for the given Info file; it is part of the Texinfo package.
- Here is a sample rule to install an Info file:
-
- $(DESTDIR)$(infodir)/foo.info: foo.info
- $(POST_INSTALL)
- # There may be a newer info file in . than in srcdir.
- -if test -f foo.info; then d=.; \
- else d=$(srcdir); fi; \
- $(INSTALL_DATA) $$d/foo.info $(DESTDIR)$@; \
- # Run install-info only if it exists.
- # Use `if' instead of just prepending `-' to the
- # line so we notice real errors from install-info.
- # We use `$(SHELL) -c' because some shells do not
- # fail gracefully when there is an unknown command.
- if $(SHELL) -c 'install-info --version' \
- >/dev/null 2>&1; then \
- install-info --dir-file=$(DESTDIR)$(infodir)/dir \
- $(DESTDIR)$(infodir)/foo.info; \
- else true; fi
-
- When writing the `install' target, you must classify all the
- commands into three categories: normal ones, "pre-installation"
- commands and "post-installation" commands. *Note Install Command
- Categories::.
-
-`install-html'
-`install-dvi'
-`install-pdf'
-`install-ps'
- These targets install documentation in formats other than Info;
- they're intended to be called explicitly by the person installing
- the package, if that format is desired. GNU prefers Info files,
- so these must be installed by the `install' target.
-
- When you have many documentation files to install, we recommend
- that you avoid collisions and clutter by arranging for these
- targets to install in subdirectories of the appropriate
- installation directory, such as `htmldir'. As one example, if
- your package has multiple manuals, and you wish to install HTML
- documentation with many files (such as the "split" mode output by
- `makeinfo --html'), you'll certainly want to use subdirectories,
- or two nodes with the same name in different manuals will
- overwrite each other.
-
- Please make these `install-FORMAT' targets invoke the commands for
- the FORMAT target, for example, by making FORMAT a dependency.
-
-`uninstall'
- Delete all the installed files--the copies that the `install' and
- `install-*' targets create.
-
- This rule should not modify the directories where compilation is
- done, only the directories where files are installed.
-
- The uninstallation commands are divided into three categories,
- just like the installation commands. *Note Install Command
- Categories::.
-
-`install-strip'
- Like `install', but strip the executable files while installing
- them. In simple cases, this target can use the `install' target in
- a simple way:
-
- install-strip:
- $(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
- install
-
- But if the package installs scripts as well as real executables,
- the `install-strip' target can't just refer to the `install'
- target; it has to strip the executables but not the scripts.
-
- `install-strip' should not strip the executables in the build
- directory which are being copied for installation. It should only
- strip the copies that are installed.
-
- Normally we do not recommend stripping an executable unless you
- are sure the program has no bugs. However, it can be reasonable
- to install a stripped executable for actual execution while saving
- the unstripped executable elsewhere in case there is a bug.
-
-`clean'
- Delete all files in the current directory that are normally
- created by building the program. Also delete files in other
- directories if they are created by this makefile. However, don't
- delete the files that record the configuration. Also preserve
- files that could be made by building, but normally aren't because
- the distribution comes with them. There is no need to delete
- parent directories that were created with `mkdir -p', since they
- could have existed anyway.
-
- Delete `.dvi' files here if they are not part of the distribution.
-
-`distclean'
- Delete all files in the current directory (or created by this
- makefile) that are created by configuring or building the program.
- If you have unpacked the source and built the program without
- creating any other files, `make distclean' should leave only the
- files that were in the distribution. However, there is no need to
- delete parent directories that were created with `mkdir -p', since
- they could have existed anyway.
-
-`mostlyclean'
- Like `clean', but may refrain from deleting a few files that people
- normally don't want to recompile. For example, the `mostlyclean'
- target for GCC does not delete `libgcc.a', because recompiling it
- is rarely necessary and takes a lot of time.
-
-`maintainer-clean'
- Delete almost everything that can be reconstructed with this
- Makefile. This typically includes everything deleted by
- `distclean', plus more: C source files produced by Bison, tags
- tables, Info files, and so on.
-
- The reason we say "almost everything" is that running the command
- `make maintainer-clean' should not delete `configure' even if
- `configure' can be remade using a rule in the Makefile. More
- generally, `make maintainer-clean' should not delete anything that
- needs to exist in order to run `configure' and then begin to build
- the program. Also, there is no need to delete parent directories
- that were created with `mkdir -p', since they could have existed
- anyway. These are the only exceptions; `maintainer-clean' should
- delete everything else that can be rebuilt.
-
- The `maintainer-clean' target is intended to be used by a
- maintainer of the package, not by ordinary users. You may need
- special tools to reconstruct some of the files that `make
- maintainer-clean' deletes. Since these files are normally
- included in the distribution, we don't take care to make them easy
- to reconstruct. If you find you need to unpack the full
- distribution again, don't blame us.
-
- To help make users aware of this, the commands for the special
- `maintainer-clean' target should start with these two:
-
- @echo 'This command is intended for maintainers to use; it'
- @echo 'deletes files that may need special tools to rebuild.'
-
-`TAGS'
- Update a tags table for this program.
-
-`info'
- Generate any Info files needed. The best way to write the rules
- is as follows:
-
- info: foo.info
-
- foo.info: foo.texi chap1.texi chap2.texi
- $(MAKEINFO) $(srcdir)/foo.texi
-
- You must define the variable `MAKEINFO' in the Makefile. It should
- run the `makeinfo' program, which is part of the Texinfo
- distribution.
-
- Normally a GNU distribution comes with Info files, and that means
- the Info files are present in the source directory. Therefore,
- the Make rule for an info file should update it in the source
- directory. When users build the package, ordinarily Make will not
- update the Info files because they will already be up to date.
-
-`dvi'
-`html'
-`pdf'
-`ps'
- Generate documentation files in the given format. These targets
- should always exist, but any or all can be a no-op if the given
- output format cannot be generated. These targets should not be
- dependencies of the `all' target; the user must manually invoke
- them.
-
- Here's an example rule for generating DVI files from Texinfo:
-
- dvi: foo.dvi
-
- foo.dvi: foo.texi chap1.texi chap2.texi
- $(TEXI2DVI) $(srcdir)/foo.texi
-
- You must define the variable `TEXI2DVI' in the Makefile. It should
- run the program `texi2dvi', which is part of the Texinfo
- distribution.(1) Alternatively, write just the dependencies, and
- allow GNU `make' to provide the command.
-
- Here's another example, this one for generating HTML from Texinfo:
-
- html: foo.html
-
- foo.html: foo.texi chap1.texi chap2.texi
- $(TEXI2HTML) $(srcdir)/foo.texi
-
- Again, you would define the variable `TEXI2HTML' in the Makefile;
- for example, it might run `makeinfo --no-split --html' (`makeinfo'
- is part of the Texinfo distribution).
-
-`dist'
- Create a distribution tar file for this program. The tar file
- should be set up so that the file names in the tar file start with
- a subdirectory name which is the name of the package it is a
- distribution for. This name can include the version number.
-
- For example, the distribution tar file of GCC version 1.40 unpacks
- into a subdirectory named `gcc-1.40'.
-
- The easiest way to do this is to create a subdirectory
- appropriately named, use `ln' or `cp' to install the proper files
- in it, and then `tar' that subdirectory.
-
- Compress the tar file with `gzip'. For example, the actual
- distribution file for GCC version 1.40 is called `gcc-1.40.tar.gz'.
-
- The `dist' target should explicitly depend on all non-source files
- that are in the distribution, to make sure they are up to date in
- the distribution. *Note Making Releases: Releases.
-
-`check'
- Perform self-tests (if any). The user must build the program
- before running the tests, but need not install the program; you
- should write the self-tests so that they work when the program is
- built but not installed.
-
- The following targets are suggested as conventional names, for
-programs in which they are useful.
-
-`installcheck'
- Perform installation tests (if any). The user must build and
- install the program before running the tests. You should not
- assume that `$(bindir)' is in the search path.
-
-`installdirs'
- It's useful to add a target named `installdirs' to create the
- directories where files are installed, and their parent
- directories. There is a script called `mkinstalldirs' which is
- convenient for this; you can find it in the Texinfo package. You
- can use a rule like this:
-
- # Make sure all installation directories (e.g. $(bindir))
- # actually exist by making them if necessary.
- installdirs: mkinstalldirs
- $(srcdir)/mkinstalldirs $(bindir) $(datadir) \
- $(libdir) $(infodir) \
- $(mandir)
-
- or, if you wish to support `DESTDIR',
-
- # Make sure all installation directories (e.g. $(bindir))
- # actually exist by making them if necessary.
- installdirs: mkinstalldirs
- $(srcdir)/mkinstalldirs \
- $(DESTDIR)$(bindir) $(DESTDIR)$(datadir) \
- $(DESTDIR)$(libdir) $(DESTDIR)$(infodir) \
- $(DESTDIR)$(mandir)
-
- This rule should not modify the directories where compilation is
- done. It should do nothing but create installation directories.
-
- ---------- Footnotes ----------
-
- (1) `texi2dvi' uses TeX to do the real work of formatting. TeX is
-not distributed with Texinfo.
-
-
-File: standards.info, Node: Install Command Categories, Prev: Standard Targets, Up: Makefile Conventions
-
-7.2.7 Install Command Categories
---------------------------------
-
-When writing the `install' target, you must classify all the commands
-into three categories: normal ones, "pre-installation" commands and
-"post-installation" commands.
-
- Normal commands move files into their proper places, and set their
-modes. They may not alter any files except the ones that come entirely
-from the package they belong to.
-
- Pre-installation and post-installation commands may alter other
-files; in particular, they can edit global configuration files or data
-bases.
-
- Pre-installation commands are typically executed before the normal
-commands, and post-installation commands are typically run after the
-normal commands.
-
- The most common use for a post-installation command is to run
-`install-info'. This cannot be done with a normal command, since it
-alters a file (the Info directory) which does not come entirely and
-solely from the package being installed. It is a post-installation
-command because it needs to be done after the normal command which
-installs the package's Info files.
-
- Most programs don't need any pre-installation commands, but we have
-the feature just in case it is needed.
-
- To classify the commands in the `install' rule into these three
-categories, insert "category lines" among them. A category line
-specifies the category for the commands that follow.
-
- A category line consists of a tab and a reference to a special Make
-variable, plus an optional comment at the end. There are three
-variables you can use, one for each category; the variable name
-specifies the category. Category lines are no-ops in ordinary execution
-because these three Make variables are normally undefined (and you
-_should not_ define them in the makefile).
-
- Here are the three possible category lines, each with a comment that
-explains what it means:
-
- $(PRE_INSTALL) # Pre-install commands follow.
- $(POST_INSTALL) # Post-install commands follow.
- $(NORMAL_INSTALL) # Normal commands follow.
-
- If you don't use a category line at the beginning of the `install'
-rule, all the commands are classified as normal until the first category
-line. If you don't use any category lines, all the commands are
-classified as normal.
-
- These are the category lines for `uninstall':
-
- $(PRE_UNINSTALL) # Pre-uninstall commands follow.
- $(POST_UNINSTALL) # Post-uninstall commands follow.
- $(NORMAL_UNINSTALL) # Normal commands follow.
-
- Typically, a pre-uninstall command would be used for deleting entries
-from the Info directory.
-
- If the `install' or `uninstall' target has any dependencies which
-act as subroutines of installation, then you should start _each_
-dependency's commands with a category line, and start the main target's
-commands with a category line also. This way, you can ensure that each
-command is placed in the right category regardless of which of the
-dependencies actually run.
-
- Pre-installation and post-installation commands should not run any
-programs except for these:
-
- [ basename bash cat chgrp chmod chown cmp cp dd diff echo
- egrep expand expr false fgrep find getopt grep gunzip gzip
- hostname install install-info kill ldconfig ln ls md5sum
- mkdir mkfifo mknod mv printenv pwd rm rmdir sed sort tee
- test touch true uname xargs yes
-
- The reason for distinguishing the commands in this way is for the
-sake of making binary packages. Typically a binary package contains
-all the executables and other files that need to be installed, and has
-its own method of installing them--so it does not need to run the normal
-installation commands. But installing the binary package does need to
-execute the pre-installation and post-installation commands.
-
- Programs to build binary packages work by extracting the
-pre-installation and post-installation commands. Here is one way of
-extracting the pre-installation commands (the `-s' option to `make' is
-needed to silence messages about entering subdirectories):
-
- make -s -n install -o all \
- PRE_INSTALL=pre-install \
- POST_INSTALL=post-install \
- NORMAL_INSTALL=normal-install \
- | gawk -f pre-install.awk
-
-where the file `pre-install.awk' could contain this:
-
- $0 ~ /^(normal-install|post-install)[ \t]*$/ {on = 0}
- on {print $0}
- $0 ~ /^pre-install[ \t]*$/ {on = 1}
-
-
-File: standards.info, Node: Releases, Prev: Makefile Conventions, Up: Managing Releases
-
-7.3 Making Releases
-===================
-
-You should identify each release with a pair of version numbers, a
-major version and a minor. We have no objection to using more than two
-numbers, but it is very unlikely that you really need them.
-
- Package the distribution of `Foo version 69.96' up in a gzipped tar
-file with the name `foo-69.96.tar.gz'. It should unpack into a
-subdirectory named `foo-69.96'.
-
- Building and installing the program should never modify any of the
-files contained in the distribution. This means that all the files
-that form part of the program in any way must be classified into "source
-files" and "non-source files". Source files are written by humans and
-never changed automatically; non-source files are produced from source
-files by programs under the control of the Makefile.
-
- The distribution should contain a file named `README' which gives
-the name of the package, and a general description of what it does. It
-is also good to explain the purpose of each of the first-level
-subdirectories in the package, if there are any. The `README' file
-should either state the version number of the package, or refer to where
-in the package it can be found.
-
- The `README' file should refer to the file `INSTALL', which should
-contain an explanation of the installation procedure.
-
- The `README' file should also refer to the file which contains the
-copying conditions. The GNU GPL, if used, should be in a file called
-`COPYING'. If the GNU LGPL is used, it should be in a file called
-`COPYING.LESSER'.
-
- Naturally, all the source files must be in the distribution. It is
-okay to include non-source files in the distribution, provided they are
-up-to-date and machine-independent, so that building the distribution
-normally will never modify them. We commonly include non-source files
-produced by Bison, `lex', TeX, and `makeinfo'; this helps avoid
-unnecessary dependencies between our distributions, so that users can
-install whichever packages they want to install.
-
- Non-source files that might actually be modified by building and
-installing the program should *never* be included in the distribution.
-So if you do distribute non-source files, always make sure they are up
-to date when you make a new distribution.
-
- Make sure that all the files in the distribution are world-readable,
-and that directories are world-readable and world-searchable (octal
-mode 755). We used to recommend that all directories in the
-distribution also be world-writable (octal mode 777), because ancient
-versions of `tar' would otherwise not cope when extracting the archive
-as an unprivileged user. That can easily lead to security issues when
-creating the archive, however, so now we recommend against that.
-
- Don't include any symbolic links in the distribution itself. If the
-tar file contains symbolic links, then people cannot even unpack it on
-systems that don't support symbolic links. Also, don't use multiple
-names for one file in different directories, because certain file
-systems cannot handle this and that prevents unpacking the distribution.
-
- Try to make sure that all the file names will be unique on MS-DOS. A
-name on MS-DOS consists of up to 8 characters, optionally followed by a
-period and up to three characters. MS-DOS will truncate extra
-characters both before and after the period. Thus, `foobarhacker.c'
-and `foobarhacker.o' are not ambiguous; they are truncated to
-`foobarha.c' and `foobarha.o', which are distinct.
-
- Include in your distribution a copy of the `texinfo.tex' you used to
-test print any `*.texinfo' or `*.texi' files.
-
- Likewise, if your program uses small GNU software packages like
-regex, getopt, obstack, or termcap, include them in the distribution
-file. Leaving them out would make the distribution file a little
-smaller at the expense of possible inconvenience to a user who doesn't
-know what other files to get.
-
-
-File: standards.info, Node: References, Next: GNU Free Documentation License, Prev: Managing Releases, Up: Top
-
-8 References to Non-Free Software and Documentation
-***************************************************
-
-A GNU program should not recommend, promote, or grant legitimacy to the
-use of any non-free program. Proprietary software is a social and
-ethical problem, and our aim is to put an end to that problem. We
-can't stop some people from writing proprietary programs, or stop other
-people from using them, but we can and should refuse to advertise them
-to new potential customers, or to give the public the idea that their
-existence is ethical.
-
- The GNU definition of free software is found on the GNU web site at
-`http://www.gnu.org/philosophy/free-sw.html', and the definition of
-free documentation is found at
-`http://www.gnu.org/philosophy/free-doc.html'. The terms "free" and
-"non-free", used in this document, refer to those definitions.
-
- A list of important licenses and whether they qualify as free is in
-`http://www.gnu.org/licenses/license-list.html'. If it is not clear
-whether a license qualifies as free, please ask the GNU Project by
-writing to <licensing@gnu.org>. We will answer, and if the license is
-an important one, we will add it to the list.
-
- When a non-free program or system is well known, you can mention it
-in passing--that is harmless, since users who might want to use it
-probably already know about it. For instance, it is fine to explain
-how to build your package on top of some widely used non-free operating
-system, or how to use it together with some widely used non-free
-program.
-
- However, you should give only the necessary information to help those
-who already use the non-free program to use your program with it--don't
-give, or refer to, any further information about the proprietary
-program, and don't imply that the proprietary program enhances your
-program, or that its existence is in any way a good thing. The goal
-should be that people already using the proprietary program will get
-the advice they need about how to use your free program with it, while
-people who don't already use the proprietary program will not see
-anything likely to lead them to take an interest in it.
-
- If a non-free program or system is obscure in your program's domain,
-your program should not mention or support it at all, since doing so
-would tend to popularize the non-free program more than it popularizes
-your program. (You cannot hope to find many additional users for your
-program among the users of Foobar, if the existence of Foobar is not
-generally known among people who might want to use your program.)
-
- Sometimes a program is free software in itself but depends on a
-non-free platform in order to run. For instance, many Java programs
-depend on some non-free Java libraries. To recommend or promote such a
-program is to promote the other programs it needs. This is why we are
-careful about listing Java programs in the Free Software Directory: we
-don't want to promote the non-free Java libraries.
-
- We hope this particular problem with Java will be gone by and by, as
-we replace the remaining non-free standard Java libraries with free
-software, but the general principle will remain the same: don't
-recommend, promote or legitimize programs that depend on non-free
-software to run.
-
- Some free programs strongly encourage the use of non-free software.
-A typical example is `mplayer'. It is free software in itself, and the
-free code can handle some kinds of files. However, `mplayer'
-recommends use of non-free codecs for other kinds of files, and users
-that install `mplayer' are very likely to install those codecs along
-with it. To recommend `mplayer' is, in effect, to promote use of the
-non-free codecs.
-
- Thus, you should not recommend programs that strongly encourage the
-use of non-free software. This is why we do not list `mplayer' in the
-Free Software Directory.
-
- A GNU package should not refer the user to any non-free documentation
-for free software. Free documentation that can be included in free
-operating systems is essential for completing the GNU system, or any
-free operating system, so encouraging it is a priority; to recommend
-use of documentation that we are not allowed to include undermines the
-impetus for the community to produce documentation that we can include.
-So GNU packages should never recommend non-free documentation.
-
- By contrast, it is ok to refer to journal articles and textbooks in
-the comments of a program for explanation of how it functions, even
-though they are non-free. This is because we don't include such things
-in the GNU system even they are free--they are outside the scope of
-what a software distribution needs to include.
-
- Referring to a web site that describes or recommends a non-free
-program is promoting that program, so please do not make links (or
-mention by name) web sites that contain such material. This policy is
-relevant particularly for the web pages for a GNU package.
-
- Following links from nearly any web site can lead eventually to
-non-free software; this is inherent in the nature of the web. So it
-makes no sense to criticize a site for having such links. As long as
-the site does not itself recommend a non-free program, there is no need
-to consider the question of the sites that it links to for other
-reasons.
-
- Thus, for example, you should not refer to AT&T's web site if that
-recommends AT&T's non-free software packages; you should not refer to a
-site that links to AT&T's site presenting it as a place to get some
-non-free program, because that link recommends and legitimizes the
-non-free program. However, that a site contains a link to AT&T's web
-site for some other purpose (such as long-distance telephone service)
-is not an objection against it.
-
-
-File: standards.info, Node: GNU Free Documentation License, Next: Index, Prev: References, Up: Top
-
-Appendix A GNU Free Documentation License
-*****************************************
-
- Version 1.3, 3 November 2008
-
- Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
- `http://fsf.org/'
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- 0. PREAMBLE
-
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to
- assure everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while not
- being considered responsible for modifications made by others.
-
- This License is a kind of "copyleft", which means that derivative
- works of the document must themselves be free in the same sense.
- It complements the GNU General Public License, which is a copyleft
- license designed for free software.
-
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same freedoms
- that the software does. But this License is not limited to
- software manuals; it can be used for any textual work, regardless
- of subject matter or whether it is published as a printed book.
- We recommend this License principally for works whose purpose is
- instruction or reference.
-
- 1. APPLICABILITY AND DEFINITIONS
-
- This License applies to any manual or other work, in any medium,
- that contains a notice placed by the copyright holder saying it
- can be distributed under the terms of this License. Such a notice
- grants a world-wide, royalty-free license, unlimited in duration,
- to use that work under the conditions stated herein. The
- "Document", below, refers to any such manual or work. Any member
- of the public is a licensee, and is addressed as "you". You
- accept the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with
- modifications and/or translated into another language.
-
- A "Secondary Section" is a named appendix or a front-matter section
- of the Document that deals exclusively with the relationship of the
- publishers or authors of the Document to the Document's overall
- subject (or to related matters) and contains nothing that could
- fall directly within that overall subject. (Thus, if the Document
- is in part a textbook of mathematics, a Secondary Section may not
- explain any mathematics.) The relationship could be a matter of
- historical connection with the subject or with related matters, or
- of legal, commercial, philosophical, ethical or political position
- regarding them.
-
- The "Invariant Sections" are certain Secondary Sections whose
- titles are designated, as being those of Invariant Sections, in
- the notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as Invariant.
- The Document may contain zero Invariant Sections. If the Document
- does not identify any Invariant Sections then there are none.
-
- The "Cover Texts" are certain short passages of text that are
- listed, as Front-Cover Texts or Back-Cover Texts, in the notice
- that says that the Document is released under this License. A
- Front-Cover Text may be at most 5 words, and a Back-Cover Text may
- be at most 25 words.
-
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the
- general public, that is suitable for revising the document
- straightforwardly with generic text editors or (for images
- composed of pixels) generic paint programs or (for drawings) some
- widely available drawing editor, and that is suitable for input to
- text formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in an
- otherwise Transparent file format whose markup, or absence of
- markup, has been arranged to thwart or discourage subsequent
- modification by readers is not Transparent. An image format is
- not Transparent if used for any substantial amount of text. A
- copy that is not "Transparent" is called "Opaque".
-
- Examples of suitable formats for Transparent copies include plain
- ASCII without markup, Texinfo input format, LaTeX input format,
- SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML, PostScript or PDF designed for
- human modification. Examples of transparent image formats include
- PNG, XCF and JPG. Opaque formats include proprietary formats that
- can be read and edited only by proprietary word processors, SGML or
- XML for which the DTD and/or processing tools are not generally
- available, and the machine-generated HTML, PostScript or PDF
- produced by some word processors for output purposes only.
-
- The "Title Page" means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page. For
- works in formats which do not have any title page as such, "Title
- Page" means the text near the most prominent appearance of the
- work's title, preceding the beginning of the body of the text.
-
- The "publisher" means any person or entity that distributes copies
- of the Document to the public.
-
- A section "Entitled XYZ" means a named subunit of the Document
- whose title either is precisely XYZ or contains XYZ in parentheses
- following text that translates XYZ in another language. (Here XYZ
- stands for a specific section name mentioned below, such as
- "Acknowledgements", "Dedications", "Endorsements", or "History".)
- To "Preserve the Title" of such a section when you modify the
- Document means that it remains a section "Entitled XYZ" according
- to this definition.
-
- The Document may include Warranty Disclaimers next to the notice
- which states that this License applies to the Document. These
- Warranty Disclaimers are considered to be included by reference in
- this License, but only as regards disclaiming warranties: any other
- implication that these Warranty Disclaimers may have is void and
- has no effect on the meaning of this License.
-
- 2. VERBATIM COPYING
-
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that you
- add no other conditions whatsoever to those of this License. You
- may not use technical measures to obstruct or control the reading
- or further copying of the copies you make or distribute. However,
- you may accept compensation in exchange for copies. If you
- distribute a large enough number of copies you must also follow
- the conditions in section 3.
-
- You may also lend copies, under the same conditions stated above,
- and you may publicly display copies.
-
- 3. COPYING IN QUANTITY
-
- If you publish printed copies (or copies in media that commonly
- have printed covers) of the Document, numbering more than 100, and
- the Document's license notice requires Cover Texts, you must
- enclose the copies in covers that carry, clearly and legibly, all
- these Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also clearly
- and legibly identify you as the publisher of these copies. The
- front cover must present the full title with all words of the
- title equally prominent and visible. You may add other material
- on the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying in
- other respects.
-
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
-
- If you publish or distribute Opaque copies of the Document
- numbering more than 100, you must either include a
- machine-readable Transparent copy along with each Opaque copy, or
- state in or with each Opaque copy a computer-network location from
- which the general network-using public has access to download
- using public-standard network protocols a complete Transparent
- copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you
- begin distribution of Opaque copies in quantity, to ensure that
- this Transparent copy will remain thus accessible at the stated
- location until at least one year after the last time you
- distribute an Opaque copy (directly or through your agents or
- retailers) of that edition to the public.
-
- It is requested, but not required, that you contact the authors of
- the Document well before redistributing any large number of
- copies, to give them a chance to provide you with an updated
- version of the Document.
-
- 4. MODIFICATIONS
-
- You may copy and distribute a Modified Version of the Document
- under the conditions of sections 2 and 3 above, provided that you
- release the Modified Version under precisely this License, with
- the Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version to
- whoever possesses a copy of it. In addition, you must do these
- things in the Modified Version:
-
- A. Use in the Title Page (and on the covers, if any) a title
- distinct from that of the Document, and from those of
- previous versions (which should, if there were any, be listed
- in the History section of the Document). You may use the
- same title as a previous version if the original publisher of
- that version gives permission.
-
- B. List on the Title Page, as authors, one or more persons or
- entities responsible for authorship of the modifications in
- the Modified Version, together with at least five of the
- principal authors of the Document (all of its principal
- authors, if it has fewer than five), unless they release you
- from this requirement.
-
- C. State on the Title page the name of the publisher of the
- Modified Version, as the publisher.
-
- D. Preserve all the copyright notices of the Document.
-
- E. Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
-
- F. Include, immediately after the copyright notices, a license
- notice giving the public permission to use the Modified
- Version under the terms of this License, in the form shown in
- the Addendum below.
-
- G. Preserve in that license notice the full lists of Invariant
- Sections and required Cover Texts given in the Document's
- license notice.
-
- H. Include an unaltered copy of this License.
-
- I. Preserve the section Entitled "History", Preserve its Title,
- and add to it an item stating at least the title, year, new
- authors, and publisher of the Modified Version as given on
- the Title Page. If there is no section Entitled "History" in
- the Document, create one stating the title, year, authors,
- and publisher of the Document as given on its Title Page,
- then add an item describing the Modified Version as stated in
- the previous sentence.
-
- J. Preserve the network location, if any, given in the Document
- for public access to a Transparent copy of the Document, and
- likewise the network locations given in the Document for
- previous versions it was based on. These may be placed in
- the "History" section. You may omit a network location for a
- work that was published at least four years before the
- Document itself, or if the original publisher of the version
- it refers to gives permission.
-
- K. For any section Entitled "Acknowledgements" or "Dedications",
- Preserve the Title of the section, and preserve in the
- section all the substance and tone of each of the contributor
- acknowledgements and/or dedications given therein.
-
- L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers
- or the equivalent are not considered part of the section
- titles.
-
- M. Delete any section Entitled "Endorsements". Such a section
- may not be included in the Modified Version.
-
- N. Do not retitle any existing section to be Entitled
- "Endorsements" or to conflict in title with any Invariant
- Section.
-
- O. Preserve any Warranty Disclaimers.
-
- If the Modified Version includes new front-matter sections or
- appendices that qualify as Secondary Sections and contain no
- material copied from the Document, you may at your option
- designate some or all of these sections as invariant. To do this,
- add their titles to the list of Invariant Sections in the Modified
- Version's license notice. These titles must be distinct from any
- other section titles.
-
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
-
- You may add a passage of up to five words as a Front-Cover Text,
- and a passage of up to 25 words as a Back-Cover Text, to the end
- of the list of Cover Texts in the Modified Version. Only one
- passage of Front-Cover Text and one of Back-Cover Text may be
- added by (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same entity
- you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by this
- License give permission to use their names for publicity for or to
- assert or imply endorsement of any Modified Version.
-
- 5. COMBINING DOCUMENTS
-
- You may combine the Document with other documents released under
- this License, under the terms defined in section 4 above for
- modified versions, provided that you include in the combination
- all of the Invariant Sections of all of the original documents,
- unmodified, and list them all as Invariant Sections of your
- combined work in its license notice, and that you preserve all
- their Warranty Disclaimers.
-
- The combined work need only contain one copy of this License, and
- multiple identical Invariant Sections may be replaced with a single
- copy. If there are multiple Invariant Sections with the same name
- but different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else a
- unique number. Make the same adjustment to the section titles in
- the list of Invariant Sections in the license notice of the
- combined work.
-
- In the combination, you must combine any sections Entitled
- "History" in the various original documents, forming one section
- Entitled "History"; likewise combine any sections Entitled
- "Acknowledgements", and any sections Entitled "Dedications". You
- must delete all sections Entitled "Endorsements."
-
- 6. COLLECTIONS OF DOCUMENTS
-
- You may make a collection consisting of the Document and other
- documents released under this License, and replace the individual
- copies of this License in the various documents with a single copy
- that is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
-
- You may extract a single document from such a collection, and
- distribute it individually under this License, provided you insert
- a copy of this License into the extracted document, and follow
- this License in all other respects regarding verbatim copying of
- that document.
-
- 7. AGGREGATION WITH INDEPENDENT WORKS
-
- A compilation of the Document or its derivatives with other
- separate and independent documents or works, in or on a volume of
- a storage or distribution medium, is called an "aggregate" if the
- copyright resulting from the compilation is not used to limit the
- legal rights of the compilation's users beyond what the individual
- works permit. When the Document is included in an aggregate, this
- License does not apply to the other works in the aggregate which
- are not themselves derivative works of the Document.
-
- If the Cover Text requirement of section 3 is applicable to these
- copies of the Document, then if the Document is less than one half
- of the entire aggregate, the Document's Cover Texts may be placed
- on covers that bracket the Document within the aggregate, or the
- electronic equivalent of covers if the Document is in electronic
- form. Otherwise they must appear on printed covers that bracket
- the whole aggregate.
-
- 8. TRANSLATION
-
- Translation is considered a kind of modification, so you may
- distribute translations of the Document under the terms of section
- 4. Replacing Invariant Sections with translations requires special
- permission from their copyright holders, but you may include
- translations of some or all Invariant Sections in addition to the
- original versions of these Invariant Sections. You may include a
- translation of this License, and all the license notices in the
- Document, and any Warranty Disclaimers, provided that you also
- include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of
- this License or a notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to
- Preserve its Title (section 1) will typically require changing the
- actual title.
-
- 9. TERMINATION
-
- You may not copy, modify, sublicense, or distribute the Document
- except as expressly provided under this License. Any attempt
- otherwise to copy, modify, sublicense, or distribute it is void,
- and will automatically terminate your rights under this License.
-
- However, if you cease all violation of this License, then your
- license from a particular copyright holder is reinstated (a)
- provisionally, unless and until the copyright holder explicitly
- and finally terminates your license, and (b) permanently, if the
- copyright holder fails to notify you of the violation by some
- reasonable means prior to 60 days after the cessation.
-
- Moreover, your license from a particular copyright holder is
- reinstated permanently if the copyright holder notifies you of the
- violation by some reasonable means, this is the first time you have
- received notice of violation of this License (for any work) from
- that copyright holder, and you cure the violation prior to 30 days
- after your receipt of the notice.
-
- Termination of your rights under this section does not terminate
- the licenses of parties who have received copies or rights from
- you under this License. If your rights have been terminated and
- not permanently reinstated, receipt of a copy of some or all of
- the same material does not give you any rights to use it.
-
- 10. FUTURE REVISIONS OF THIS LICENSE
-
- The Free Software Foundation may publish new, revised versions of
- the GNU Free Documentation License from time to time. Such new
- versions will be similar in spirit to the present version, but may
- differ in detail to address new problems or concerns. See
- `http://www.gnu.org/copyleft/'.
-
- Each version of the License is given a distinguishing version
- number. If the Document specifies that a particular numbered
- version of this License "or any later version" applies to it, you
- have the option of following the terms and conditions either of
- that specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by the
- Free Software Foundation. If the Document specifies that a proxy
- can decide which future versions of this License can be used, that
- proxy's public statement of acceptance of a version permanently
- authorizes you to choose that version for the Document.
-
- 11. RELICENSING
-
- "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
- World Wide Web server that publishes copyrightable works and also
- provides prominent facilities for anybody to edit those works. A
- public wiki that anybody can edit is an example of such a server.
- A "Massive Multiauthor Collaboration" (or "MMC") contained in the
- site means any set of copyrightable works thus published on the MMC
- site.
-
- "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
- license published by Creative Commons Corporation, a not-for-profit
- corporation with a principal place of business in San Francisco,
- California, as well as future copyleft versions of that license
- published by that same organization.
-
- "Incorporate" means to publish or republish a Document, in whole or
- in part, as part of another Document.
-
- An MMC is "eligible for relicensing" if it is licensed under this
- License, and if all works that were first published under this
- License somewhere other than this MMC, and subsequently
- incorporated in whole or in part into the MMC, (1) had no cover
- texts or invariant sections, and (2) were thus incorporated prior
- to November 1, 2008.
-
- The operator of an MMC Site may republish an MMC contained in the
- site under CC-BY-SA on the same site at any time before August 1,
- 2009, provided the MMC is eligible for relicensing.
-
-
-ADDENDUM: How to use this License for your documents
-====================================================
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and license
-notices just after the title page:
-
- Copyright (C) YEAR YOUR NAME.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-
- If you have Invariant Sections, Front-Cover Texts and Back-Cover
-Texts, replace the "with...Texts." line with this:
-
- with the Invariant Sections being LIST THEIR TITLES, with
- the Front-Cover Texts being LIST, and with the Back-Cover Texts
- being LIST.
-
- If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
- If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License, to
-permit their use in free software.
-
-
-File: standards.info, Node: Index, Prev: GNU Free Documentation License, Up: Top
-
-Index
-*****
-
-
-* Menu:
-
-* #endif, commenting: Comments. (line 60)
-* --help output: --help. (line 6)
-* --version output: --version. (line 6)
-* -Wall compiler option: Syntactic Conventions.
- (line 10)
-* accepting contributions: Contributions. (line 6)
-* address for bug reports: --help. (line 11)
-* ANSI C standard: Standard C. (line 6)
-* arbitrary limits on data: Semantics. (line 6)
-* ASCII characters: Character Set. (line 6)
-* autoconf: System Portability. (line 23)
-* avoiding proprietary code: Reading Non-Free Code.
- (line 6)
-* behavior, dependent on program's name: User Interfaces. (line 6)
-* binary packages: Install Command Categories.
- (line 80)
-* bindir: Directory Variables. (line 54)
-* braces, in C source: Formatting. (line 6)
-* bug reports: --help. (line 11)
-* bug-standards@gnu.org email address: Preface. (line 30)
-* canonical name of a program: --version. (line 12)
-* casting pointers to integers: CPU Portability. (line 89)
-* CGI programs, standard options for: Command-Line Interfaces.
- (line 31)
-* change logs: Change Logs. (line 6)
-* change logs, conditional changes: Conditional Changes. (line 6)
-* change logs, style: Style of Change Logs.
- (line 6)
-* character set: Character Set. (line 6)
-* command-line arguments, decoding: Semantics. (line 46)
-* command-line interface: Command-Line Interfaces.
- (line 6)
-* commenting: Comments. (line 6)
-* compatibility with C and POSIX standards: Compatibility. (line 6)
-* compiler warnings: Syntactic Conventions.
- (line 10)
-* conditional changes, and change logs: Conditional Changes. (line 6)
-* conditionals, comments for: Comments. (line 60)
-* configure: Configuration. (line 6)
-* control-L: Formatting. (line 118)
-* conventions for makefiles: Makefile Conventions.
- (line 6)
-* CORBA: Graphical Interfaces.
- (line 16)
-* credits for manuals: Manual Credits. (line 6)
-* D-bus: Graphical Interfaces.
- (line 16)
-* data types, and portability: CPU Portability. (line 6)
-* declaration for system functions: System Functions. (line 21)
-* DESTDIR: DESTDIR. (line 6)
-* documentation: Documentation. (line 6)
-* doschk: Names. (line 38)
-* downloading this manual: Preface. (line 14)
-* encodings: Character Set. (line 6)
-* error messages: Semantics. (line 19)
-* error messages, formatting: Errors. (line 6)
-* exec_prefix: Directory Variables. (line 36)
-* expressions, splitting: Formatting. (line 81)
-* FDL, GNU Free Documentation License: GNU Free Documentation License.
- (line 6)
-* file usage: File Usage. (line 6)
-* file-name limitations: Names. (line 38)
-* formatting error messages: Errors. (line 6)
-* formatting source code: Formatting. (line 6)
-* formfeed: Formatting. (line 118)
-* function argument, declaring: Syntactic Conventions.
- (line 6)
-* function prototypes: Standard C. (line 17)
-* getopt: Command-Line Interfaces.
- (line 6)
-* gettext: Internationalization.
- (line 6)
-* GNOME: Graphical Interfaces.
- (line 16)
-* GNOME and Guile: Source Language. (line 38)
-* gnustandards project repository: Preface. (line 30)
-* gnustandards-commit@gnu.org mailing list: Preface. (line 24)
-* graphical user interface: Graphical Interfaces.
- (line 6)
-* grave accent: Quote Characters. (line 6)
-* GTK+: Graphical Interfaces.
- (line 6)
-* Guile: Source Language. (line 38)
-* implicit int: Syntactic Conventions.
- (line 6)
-* impossible conditions: Semantics. (line 70)
-* installations, staged: DESTDIR. (line 6)
-* interface styles: Graphical Interfaces.
- (line 6)
-* internationalization: Internationalization.
- (line 6)
-* keyboard interface: Graphical Interfaces.
- (line 16)
-* LDAP: OID Allocations. (line 6)
-* left quote: Quote Characters. (line 6)
-* legal aspects: Legal Issues. (line 6)
-* legal papers: Contributions. (line 6)
-* libexecdir: Directory Variables. (line 67)
-* libraries: Libraries. (line 6)
-* library functions, and portability: System Functions. (line 6)
-* library interface: Graphical Interfaces.
- (line 16)
-* license for manuals: License for Manuals. (line 6)
-* lint: Syntactic Conventions.
- (line 109)
-* locale-specific quote characters: Quote Characters. (line 6)
-* long option names: Option Table. (line 6)
-* long-named options: Command-Line Interfaces.
- (line 12)
-* makefile, conventions for: Makefile Conventions.
- (line 6)
-* malloc return value: Semantics. (line 25)
-* man pages: Man Pages. (line 6)
-* manual structure: Manual Structure Details.
- (line 6)
-* memory allocation failure: Semantics. (line 25)
-* memory usage: Memory Usage. (line 6)
-* message text, and internationalization: Internationalization.
- (line 29)
-* mmap: Mmap. (line 6)
-* multiple variables in a line: Syntactic Conventions.
- (line 35)
-* names of variables, functions, and files: Names. (line 6)
-* NEWS file: NEWS File. (line 6)
-* non-ASCII characters: Character Set. (line 6)
-* non-POSIX systems, and portability: System Portability. (line 32)
-* non-standard extensions: Using Extensions. (line 6)
-* NUL characters: Semantics. (line 11)
-* OID allocations for GNU: OID Allocations. (line 6)
-* open brace: Formatting. (line 6)
-* optional features, configure-time: Configuration. (line 100)
-* options for compatibility: Compatibility. (line 14)
-* options, standard command-line: Command-Line Interfaces.
- (line 31)
-* output device and program's behavior: User Interfaces. (line 13)
-* packaging: Releases. (line 6)
-* PATH_INFO, specifying standard options as: Command-Line Interfaces.
- (line 31)
-* portability, and data types: CPU Portability. (line 6)
-* portability, and library functions: System Functions. (line 6)
-* portability, between system types: System Portability. (line 6)
-* POSIX compatibility: Compatibility. (line 6)
-* POSIXLY_CORRECT, environment variable: Compatibility. (line 21)
-* post-installation commands: Install Command Categories.
- (line 6)
-* pre-installation commands: Install Command Categories.
- (line 6)
-* prefix: Directory Variables. (line 26)
-* program configuration: Configuration. (line 6)
-* program design: Design Advice. (line 6)
-* program name and its behavior: User Interfaces. (line 6)
-* program's canonical name: --version. (line 12)
-* programming languages: Source Language. (line 6)
-* proprietary programs: Reading Non-Free Code.
- (line 6)
-* quote characters: Quote Characters. (line 6)
-* README file: Releases. (line 21)
-* references to non-free material: References. (line 6)
-* releasing: Managing Releases. (line 6)
-* Savannah repository for gnustandards: Preface. (line 30)
-* sbindir: Directory Variables. (line 60)
-* signal handling: Semantics. (line 59)
-* SNMP: OID Allocations. (line 6)
-* spaces before open-paren: Formatting. (line 75)
-* staged installs: DESTDIR. (line 6)
-* standard command-line options: Command-Line Interfaces.
- (line 31)
-* standards for makefiles: Makefile Conventions.
- (line 6)
-* string library functions: System Functions. (line 55)
-* syntactic conventions: Syntactic Conventions.
- (line 6)
-* table of long options: Option Table. (line 6)
-* temporary files: Semantics. (line 84)
-* temporary variables: Syntactic Conventions.
- (line 23)
-* texinfo.tex, in a distribution: Releases. (line 70)
-* TMPDIR environment variable: Semantics. (line 84)
-* trademarks: Trademarks. (line 6)
-* user interface styles: Graphical Interfaces.
- (line 6)
-* where to obtain standards.texi: Preface. (line 14)
-* X.509: OID Allocations. (line 6)
-
-
-
-Tag Table:
-Node: Top882
-Node: Preface2157
-Node: Legal Issues4870
-Node: Reading Non-Free Code5340
-Node: Contributions7070
-Node: Trademarks9308
-Node: Design Advice10943
-Node: Source Language11535
-Node: Compatibility13661
-Node: Using Extensions15289
-Node: Standard C16865
-Node: Conditional Compilation19268
-Node: Program Behavior20666
-Node: Non-GNU Standards21782
-Node: Semantics24063
-Node: Libraries28783
-Node: Errors30028
-Node: User Interfaces32521
-Node: Graphical Interfaces34126
-Node: Command-Line Interfaces35310
-Node: --version37342
-Node: --help43079
-Node: Option Table43952
-Node: OID Allocations58907
-Node: Memory Usage60704
-Node: File Usage61740
-Node: Writing C62490
-Node: Formatting63462
-Node: Comments67751
-Node: Syntactic Conventions71303
-Node: Names74765
-Node: System Portability76977
-Node: CPU Portability79868
-Node: System Functions83769
-Node: Internationalization88966
-Node: Character Set92960
-Node: Quote Characters93773
-Node: Mmap95293
-Node: Documentation96001
-Node: GNU Manuals97107
-Node: Doc Strings and Manuals102845
-Node: Manual Structure Details104398
-Node: License for Manuals105816
-Node: Manual Credits106790
-Node: Printed Manuals107183
-Node: NEWS File107869
-Node: Change Logs108547
-Node: Change Log Concepts109301
-Node: Style of Change Logs111404
-Node: Simple Changes113904
-Node: Conditional Changes115346
-Node: Indicating the Part Changed116768
-Node: Man Pages117295
-Node: Reading other Manuals119501
-Node: Managing Releases120292
-Node: Configuration121073
-Node: Makefile Conventions129738
-Node: Makefile Basics130620
-Node: Utilities in Makefiles133794
-Node: Command Variables135939
-Node: DESTDIR139161
-Node: Directory Variables141310
-Node: Standard Targets155803
-Ref: Standard Targets-Footnote-1169318
-Node: Install Command Categories169418
-Node: Releases173951
-Node: References177956
-Node: GNU Free Documentation License183803
-Node: Index208970
-
-End Tag Table
diff --git a/share/locale/bg/LC_MESSAGES/binutils.mo b/share/locale/bg/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 91c86a5..0000000
--- a/share/locale/bg/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/bg/LC_MESSAGES/gprof.mo b/share/locale/bg/LC_MESSAGES/gprof.mo
deleted file mode 100644
index 668ad6b..0000000
--- a/share/locale/bg/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/bg/LC_MESSAGES/ld.mo b/share/locale/bg/LC_MESSAGES/ld.mo
deleted file mode 100644
index 7562e74..0000000
--- a/share/locale/bg/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/da/LC_MESSAGES/bfd.mo b/share/locale/da/LC_MESSAGES/bfd.mo
deleted file mode 100644
index 944a11c..0000000
--- a/share/locale/da/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/da/LC_MESSAGES/binutils.mo b/share/locale/da/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 92a2025..0000000
--- a/share/locale/da/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/da/LC_MESSAGES/gprof.mo b/share/locale/da/LC_MESSAGES/gprof.mo
deleted file mode 100644
index d2bfe78..0000000
--- a/share/locale/da/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/da/LC_MESSAGES/ld.mo b/share/locale/da/LC_MESSAGES/ld.mo
deleted file mode 100644
index 495c603..0000000
--- a/share/locale/da/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/da/LC_MESSAGES/opcodes.mo b/share/locale/da/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index 42d668d..0000000
--- a/share/locale/da/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/de/LC_MESSAGES/gprof.mo b/share/locale/de/LC_MESSAGES/gprof.mo
deleted file mode 100644
index 2f4dd2c..0000000
--- a/share/locale/de/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/de/LC_MESSAGES/opcodes.mo b/share/locale/de/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index acd983f..0000000
--- a/share/locale/de/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/es/LC_MESSAGES/bfd.mo b/share/locale/es/LC_MESSAGES/bfd.mo
deleted file mode 100644
index b0bdade..0000000
--- a/share/locale/es/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/es/LC_MESSAGES/binutils.mo b/share/locale/es/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 368874b..0000000
--- a/share/locale/es/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/es/LC_MESSAGES/gas.mo b/share/locale/es/LC_MESSAGES/gas.mo
deleted file mode 100644
index 052fb43..0000000
--- a/share/locale/es/LC_MESSAGES/gas.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/es/LC_MESSAGES/gprof.mo b/share/locale/es/LC_MESSAGES/gprof.mo
deleted file mode 100644
index c253981..0000000
--- a/share/locale/es/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/es/LC_MESSAGES/ld.mo b/share/locale/es/LC_MESSAGES/ld.mo
deleted file mode 100644
index 8dedeeb..0000000
--- a/share/locale/es/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/es/LC_MESSAGES/opcodes.mo b/share/locale/es/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index 82b773a..0000000
--- a/share/locale/es/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/fi/LC_MESSAGES/bfd.mo b/share/locale/fi/LC_MESSAGES/bfd.mo
deleted file mode 100644
index 44bca56..0000000
--- a/share/locale/fi/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/fi/LC_MESSAGES/binutils.mo b/share/locale/fi/LC_MESSAGES/binutils.mo
deleted file mode 100644
index ba5d444..0000000
--- a/share/locale/fi/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/fi/LC_MESSAGES/gprof.mo b/share/locale/fi/LC_MESSAGES/gprof.mo
deleted file mode 100644
index 082672a..0000000
--- a/share/locale/fi/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/fi/LC_MESSAGES/ld.mo b/share/locale/fi/LC_MESSAGES/ld.mo
deleted file mode 100644
index 1d4f6d6..0000000
--- a/share/locale/fi/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/fi/LC_MESSAGES/opcodes.mo b/share/locale/fi/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index e797314..0000000
--- a/share/locale/fi/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/fr/LC_MESSAGES/bfd.mo b/share/locale/fr/LC_MESSAGES/bfd.mo
deleted file mode 100644
index 2a73a53..0000000
--- a/share/locale/fr/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/fr/LC_MESSAGES/binutils.mo b/share/locale/fr/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 91a5c86..0000000
--- a/share/locale/fr/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/fr/LC_MESSAGES/gas.mo b/share/locale/fr/LC_MESSAGES/gas.mo
deleted file mode 100644
index 97616ef..0000000
--- a/share/locale/fr/LC_MESSAGES/gas.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/fr/LC_MESSAGES/gprof.mo b/share/locale/fr/LC_MESSAGES/gprof.mo
deleted file mode 100644
index c99db5a..0000000
--- a/share/locale/fr/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/fr/LC_MESSAGES/ld.mo b/share/locale/fr/LC_MESSAGES/ld.mo
deleted file mode 100644
index 24c9ae1..0000000
--- a/share/locale/fr/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/fr/LC_MESSAGES/opcodes.mo b/share/locale/fr/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index 8d61223..0000000
--- a/share/locale/fr/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ga/LC_MESSAGES/gprof.mo b/share/locale/ga/LC_MESSAGES/gprof.mo
deleted file mode 100644
index 5942da3..0000000
--- a/share/locale/ga/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ga/LC_MESSAGES/ld.mo b/share/locale/ga/LC_MESSAGES/ld.mo
deleted file mode 100644
index b308044..0000000
--- a/share/locale/ga/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ga/LC_MESSAGES/opcodes.mo b/share/locale/ga/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index fef6710..0000000
--- a/share/locale/ga/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/id/LC_MESSAGES/bfd.mo b/share/locale/id/LC_MESSAGES/bfd.mo
deleted file mode 100644
index 46b2f30..0000000
--- a/share/locale/id/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/id/LC_MESSAGES/binutils.mo b/share/locale/id/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 50db7fd..0000000
--- a/share/locale/id/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/id/LC_MESSAGES/gas.mo b/share/locale/id/LC_MESSAGES/gas.mo
deleted file mode 100644
index 2ecf194..0000000
--- a/share/locale/id/LC_MESSAGES/gas.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/id/LC_MESSAGES/gprof.mo b/share/locale/id/LC_MESSAGES/gprof.mo
deleted file mode 100644
index e9c4293..0000000
--- a/share/locale/id/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/id/LC_MESSAGES/ld.mo b/share/locale/id/LC_MESSAGES/ld.mo
deleted file mode 100644
index 155f607..0000000
--- a/share/locale/id/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/id/LC_MESSAGES/opcodes.mo b/share/locale/id/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index 4ad3764..0000000
--- a/share/locale/id/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ja/LC_MESSAGES/bfd.mo b/share/locale/ja/LC_MESSAGES/bfd.mo
deleted file mode 100644
index d887a71..0000000
--- a/share/locale/ja/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ja/LC_MESSAGES/binutils.mo b/share/locale/ja/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 9b84feb..0000000
--- a/share/locale/ja/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ja/LC_MESSAGES/ld.mo b/share/locale/ja/LC_MESSAGES/ld.mo
deleted file mode 100644
index bfbd0c9..0000000
--- a/share/locale/ja/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ms/LC_MESSAGES/gprof.mo b/share/locale/ms/LC_MESSAGES/gprof.mo
deleted file mode 100644
index 7677687..0000000
--- a/share/locale/ms/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/nl/LC_MESSAGES/gprof.mo b/share/locale/nl/LC_MESSAGES/gprof.mo
deleted file mode 100644
index 32cf7de..0000000
--- a/share/locale/nl/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/nl/LC_MESSAGES/opcodes.mo b/share/locale/nl/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index 8e26600..0000000
--- a/share/locale/nl/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/pt_BR/LC_MESSAGES/gprof.mo b/share/locale/pt_BR/LC_MESSAGES/gprof.mo
deleted file mode 100644
index 32876f7..0000000
--- a/share/locale/pt_BR/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/pt_BR/LC_MESSAGES/opcodes.mo b/share/locale/pt_BR/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index 083e8f4..0000000
--- a/share/locale/pt_BR/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ro/LC_MESSAGES/bfd.mo b/share/locale/ro/LC_MESSAGES/bfd.mo
deleted file mode 100644
index 8621928..0000000
--- a/share/locale/ro/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ro/LC_MESSAGES/binutils.mo b/share/locale/ro/LC_MESSAGES/binutils.mo
deleted file mode 100644
index f1c1e0e..0000000
--- a/share/locale/ro/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ro/LC_MESSAGES/gprof.mo b/share/locale/ro/LC_MESSAGES/gprof.mo
deleted file mode 100644
index 2b3e606..0000000
--- a/share/locale/ro/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ro/LC_MESSAGES/opcodes.mo b/share/locale/ro/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index 6125448..0000000
--- a/share/locale/ro/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ru/LC_MESSAGES/bfd.mo b/share/locale/ru/LC_MESSAGES/bfd.mo
deleted file mode 100644
index 2086367..0000000
--- a/share/locale/ru/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ru/LC_MESSAGES/binutils.mo b/share/locale/ru/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 839e8c0..0000000
--- a/share/locale/ru/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ru/LC_MESSAGES/gas.mo b/share/locale/ru/LC_MESSAGES/gas.mo
deleted file mode 100644
index 87734f2..0000000
--- a/share/locale/ru/LC_MESSAGES/gas.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/ru/LC_MESSAGES/gprof.mo b/share/locale/ru/LC_MESSAGES/gprof.mo
deleted file mode 100644
index b4ee126..0000000
--- a/share/locale/ru/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/rw/LC_MESSAGES/bfd.mo b/share/locale/rw/LC_MESSAGES/bfd.mo
deleted file mode 100644
index 49d9e2f..0000000
--- a/share/locale/rw/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/rw/LC_MESSAGES/binutils.mo b/share/locale/rw/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 6d5d7b9..0000000
--- a/share/locale/rw/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/rw/LC_MESSAGES/gas.mo b/share/locale/rw/LC_MESSAGES/gas.mo
deleted file mode 100644
index 8879b0e..0000000
--- a/share/locale/rw/LC_MESSAGES/gas.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/rw/LC_MESSAGES/gprof.mo b/share/locale/rw/LC_MESSAGES/gprof.mo
deleted file mode 100644
index a7a1d90..0000000
--- a/share/locale/rw/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/sk/LC_MESSAGES/binutils.mo b/share/locale/sk/LC_MESSAGES/binutils.mo
deleted file mode 100644
index df4639a..0000000
--- a/share/locale/sk/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/sv/LC_MESSAGES/bfd.mo b/share/locale/sv/LC_MESSAGES/bfd.mo
deleted file mode 100644
index e746ec0..0000000
--- a/share/locale/sv/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/sv/LC_MESSAGES/binutils.mo b/share/locale/sv/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 0efae30..0000000
--- a/share/locale/sv/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/sv/LC_MESSAGES/gprof.mo b/share/locale/sv/LC_MESSAGES/gprof.mo
deleted file mode 100644
index 6af90c7..0000000
--- a/share/locale/sv/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/sv/LC_MESSAGES/ld.mo b/share/locale/sv/LC_MESSAGES/ld.mo
deleted file mode 100644
index f7038a8..0000000
--- a/share/locale/sv/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/sv/LC_MESSAGES/opcodes.mo b/share/locale/sv/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index 2347bdc..0000000
--- a/share/locale/sv/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/tr/LC_MESSAGES/bfd.mo b/share/locale/tr/LC_MESSAGES/bfd.mo
deleted file mode 100644
index 74c0ea8..0000000
--- a/share/locale/tr/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/tr/LC_MESSAGES/binutils.mo b/share/locale/tr/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 7190446..0000000
--- a/share/locale/tr/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/tr/LC_MESSAGES/gas.mo b/share/locale/tr/LC_MESSAGES/gas.mo
deleted file mode 100644
index bf7736d..0000000
--- a/share/locale/tr/LC_MESSAGES/gas.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/tr/LC_MESSAGES/gprof.mo b/share/locale/tr/LC_MESSAGES/gprof.mo
deleted file mode 100644
index 82735ab..0000000
--- a/share/locale/tr/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/tr/LC_MESSAGES/ld.mo b/share/locale/tr/LC_MESSAGES/ld.mo
deleted file mode 100644
index 96d567b..0000000
--- a/share/locale/tr/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/tr/LC_MESSAGES/opcodes.mo b/share/locale/tr/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index 98b9df1..0000000
--- a/share/locale/tr/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/uk/LC_MESSAGES/binutils.mo b/share/locale/uk/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 6cd6aa1..0000000
--- a/share/locale/uk/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/vi/LC_MESSAGES/bfd.mo b/share/locale/vi/LC_MESSAGES/bfd.mo
deleted file mode 100644
index 0c9ed17..0000000
--- a/share/locale/vi/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/vi/LC_MESSAGES/binutils.mo b/share/locale/vi/LC_MESSAGES/binutils.mo
deleted file mode 100644
index 17df7d8..0000000
--- a/share/locale/vi/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/vi/LC_MESSAGES/gprof.mo b/share/locale/vi/LC_MESSAGES/gprof.mo
deleted file mode 100644
index 91530d6..0000000
--- a/share/locale/vi/LC_MESSAGES/gprof.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/vi/LC_MESSAGES/ld.mo b/share/locale/vi/LC_MESSAGES/ld.mo
deleted file mode 100644
index 831bb46..0000000
--- a/share/locale/vi/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/vi/LC_MESSAGES/opcodes.mo b/share/locale/vi/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index 28974e4..0000000
--- a/share/locale/vi/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/zh_CN/LC_MESSAGES/bfd.mo b/share/locale/zh_CN/LC_MESSAGES/bfd.mo
deleted file mode 100644
index 6599886..0000000
--- a/share/locale/zh_CN/LC_MESSAGES/bfd.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/zh_CN/LC_MESSAGES/binutils.mo b/share/locale/zh_CN/LC_MESSAGES/binutils.mo
deleted file mode 100644
index b4448b1..0000000
--- a/share/locale/zh_CN/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/zh_CN/LC_MESSAGES/ld.mo b/share/locale/zh_CN/LC_MESSAGES/ld.mo
deleted file mode 100644
index 39d1794..0000000
--- a/share/locale/zh_CN/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/zh_CN/LC_MESSAGES/opcodes.mo b/share/locale/zh_CN/LC_MESSAGES/opcodes.mo
deleted file mode 100644
index 2bf6751..0000000
--- a/share/locale/zh_CN/LC_MESSAGES/opcodes.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/zh_TW/LC_MESSAGES/binutils.mo b/share/locale/zh_TW/LC_MESSAGES/binutils.mo
deleted file mode 100644
index b02a71e..0000000
--- a/share/locale/zh_TW/LC_MESSAGES/binutils.mo
+++ /dev/null
Binary files differ
diff --git a/share/locale/zh_TW/LC_MESSAGES/ld.mo b/share/locale/zh_TW/LC_MESSAGES/ld.mo
deleted file mode 100644
index 23277b1..0000000
--- a/share/locale/zh_TW/LC_MESSAGES/ld.mo
+++ /dev/null
Binary files differ
diff --git a/share/man/man1/arm-eabi-addr2line.1 b/share/man/man1/arm-eabi-addr2line.1
deleted file mode 100644
index c25f729..0000000
--- a/share/man/man1/arm-eabi-addr2line.1
+++ /dev/null
@@ -1,287 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "ADDR2LINE 1"
-.TH ADDR2LINE 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-addr2line \- convert addresses into file names and line numbers.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-addr2line [\fB\-a\fR|\fB\-\-addresses\fR]
- [\fB\-b\fR \fIbfdname\fR|\fB\-\-target=\fR\fIbfdname\fR]
- [\fB\-C\fR|\fB\-\-demangle\fR[=\fIstyle\fR]]
- [\fB\-e\fR \fIfilename\fR|\fB\-\-exe=\fR\fIfilename\fR]
- [\fB\-f\fR|\fB\-\-functions\fR] [\fB\-s\fR|\fB\-\-basename\fR]
- [\fB\-i\fR|\fB\-\-inlines\fR]
- [\fB\-p\fR|\fB\-\-pretty\-print\fR]
- [\fB\-j\fR|\fB\-\-section=\fR\fIname\fR]
- [\fB\-H\fR|\fB\-\-help\fR] [\fB\-V\fR|\fB\-\-version\fR]
- [addr addr ...]
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\fBaddr2line\fR translates addresses into file names and line numbers.
-Given an address in an executable or an offset in a section of a relocatable
-object, it uses the debugging information to figure out which file name and
-line number are associated with it.
-.PP
-The executable or relocatable object to use is specified with the \fB\-e\fR
-option. The default is the file \fIa.out\fR. The section in the relocatable
-object to use is specified with the \fB\-j\fR option.
-.PP
-\&\fBaddr2line\fR has two modes of operation.
-.PP
-In the first, hexadecimal addresses are specified on the command line,
-and \fBaddr2line\fR displays the file name and line number for each
-address.
-.PP
-In the second, \fBaddr2line\fR reads hexadecimal addresses from
-standard input, and prints the file name and line number for each
-address on standard output. In this mode, \fBaddr2line\fR may be used
-in a pipe to convert dynamically chosen addresses.
-.PP
-The format of the output is \fB\s-1FILENAME:LINENO\s0\fR. The file name and
-line number for each address is printed on a separate line. If the
-\&\fB\-f\fR option is used, then each \fB\s-1FILENAME:LINENO\s0\fR line is
-preceded by a \fB\s-1FUNCTIONNAME\s0\fR line which is the name of the function
-containing the address. If the \fB\-a\fR option is used, then the
-address read is first printed.
-.PP
-If the file name or function name can not be determined,
-\&\fBaddr2line\fR will print two question marks in their place. If the
-line number can not be determined, \fBaddr2line\fR will print 0.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-The long and short forms of options, shown here as alternatives, are
-equivalent.
-.IP "\fB\-a\fR" 4
-.IX Item "-a"
-.PD 0
-.IP "\fB\-\-addresses\fR" 4
-.IX Item "--addresses"
-.PD
-Display address before function names or file and line number
-information. The address is printed with a \fB0x\fR prefix to easily
-identify it.
-.IP "\fB\-b\fR \fIbfdname\fR" 4
-.IX Item "-b bfdname"
-.PD 0
-.IP "\fB\-\-target=\fR\fIbfdname\fR" 4
-.IX Item "--target=bfdname"
-.PD
-Specify that the object-code format for the object files is
-\&\fIbfdname\fR.
-.IP "\fB\-C\fR" 4
-.IX Item "-C"
-.PD 0
-.IP "\fB\-\-demangle[=\fR\fIstyle\fR\fB]\fR" 4
-.IX Item "--demangle[=style]"
-.PD
-Decode (\fIdemangle\fR) low-level symbol names into user-level names.
-Besides removing any initial underscore prepended by the system, this
-makes \*(C+ function names readable. Different compilers have different
-mangling styles. The optional demangling style argument can be used to
-choose an appropriate demangling style for your compiler.
-.IP "\fB\-e\fR \fIfilename\fR" 4
-.IX Item "-e filename"
-.PD 0
-.IP "\fB\-\-exe=\fR\fIfilename\fR" 4
-.IX Item "--exe=filename"
-.PD
-Specify the name of the executable for which addresses should be
-translated. The default file is \fIa.out\fR.
-.IP "\fB\-f\fR" 4
-.IX Item "-f"
-.PD 0
-.IP "\fB\-\-functions\fR" 4
-.IX Item "--functions"
-.PD
-Display function names as well as file and line number information.
-.IP "\fB\-s\fR" 4
-.IX Item "-s"
-.PD 0
-.IP "\fB\-\-basenames\fR" 4
-.IX Item "--basenames"
-.PD
-Display only the base of each file name.
-.IP "\fB\-i\fR" 4
-.IX Item "-i"
-.PD 0
-.IP "\fB\-\-inlines\fR" 4
-.IX Item "--inlines"
-.PD
-If the address belongs to a function that was inlined, the source
-information for all enclosing scopes back to the first non-inlined
-function will also be printed. For example, if \f(CW\*(C`main\*(C'\fR inlines
-\&\f(CW\*(C`callee1\*(C'\fR which inlines \f(CW\*(C`callee2\*(C'\fR, and address is from
-\&\f(CW\*(C`callee2\*(C'\fR, the source information for \f(CW\*(C`callee1\*(C'\fR and \f(CW\*(C`main\*(C'\fR
-will also be printed.
-.IP "\fB\-j\fR" 4
-.IX Item "-j"
-.PD 0
-.IP "\fB\-\-section\fR" 4
-.IX Item "--section"
-.PD
-Read offsets relative to the specified section instead of absolute addresses.
-.IP "\fB\-p\fR" 4
-.IX Item "-p"
-.PD 0
-.IP "\fB\-\-pretty\-print\fR" 4
-.IX Item "--pretty-print"
-.PD
-Make the output more human friendly: each location are printed on one line.
-If option \fB\-i\fR is specified, lines for all enclosing scopes are
-prefixed with \fB(inlined by)\fR.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-ar.1 b/share/man/man1/arm-eabi-ar.1
deleted file mode 100644
index f93bb5c..0000000
--- a/share/man/man1/arm-eabi-ar.1
+++ /dev/null
@@ -1,428 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "AR 1"
-.TH AR 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-ar \- create, modify, and extract from archives
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-ar [\fB\-\-plugin\fR \fIname\fR] [\fB\-X32_64\fR] [\fB\-\fR]\fIp\fR[\fImod\fR [\fIrelpos\fR] [\fIcount\fR]] \fIarchive\fR [\fImember\fR...]
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-The \s-1GNU\s0 \fBar\fR program creates, modifies, and extracts from
-archives. An \fIarchive\fR is a single file holding a collection of
-other files in a structure that makes it possible to retrieve
-the original individual files (called \fImembers\fR of the archive).
-.PP
-The original files' contents, mode (permissions), timestamp, owner, and
-group are preserved in the archive, and can be restored on
-extraction.
-.PP
-\&\s-1GNU\s0 \fBar\fR can maintain archives whose members have names of any
-length; however, depending on how \fBar\fR is configured on your
-system, a limit on member-name length may be imposed for compatibility
-with archive formats maintained with other tools. If it exists, the
-limit is often 15 characters (typical of formats related to a.out) or 16
-characters (typical of formats related to coff).
-.PP
-\&\fBar\fR is considered a binary utility because archives of this sort
-are most often used as \fIlibraries\fR holding commonly needed
-subroutines.
-.PP
-\&\fBar\fR creates an index to the symbols defined in relocatable
-object modules in the archive when you specify the modifier \fBs\fR.
-Once created, this index is updated in the archive whenever \fBar\fR
-makes a change to its contents (save for the \fBq\fR update operation).
-An archive with such an index speeds up linking to the library, and
-allows routines in the library to call each other without regard to
-their placement in the archive.
-.PP
-You may use \fBnm \-s\fR or \fBnm \-\-print\-armap\fR to list this index
-table. If an archive lacks the table, another form of \fBar\fR called
-\&\fBranlib\fR can be used to add just the table.
-.PP
-\&\s-1GNU\s0 \fBar\fR can optionally create a \fIthin\fR archive,
-which contains a symbol index and references to the original copies
-of the member files of the archives. Such an archive is useful
-for building libraries for use within a local build, where the
-relocatable objects are expected to remain available, and copying the
-contents of each object would only waste time and space. Thin archives
-are also \fIflattened\fR, so that adding one or more archives to a
-thin archive will add the elements of the nested archive individually.
-The paths to the elements of the archive are stored relative to the
-archive itself.
-.PP
-\&\s-1GNU\s0 \fBar\fR is designed to be compatible with two different
-facilities. You can control its activity using command-line options,
-like the different varieties of \fBar\fR on Unix systems; or, if you
-specify the single command-line option \fB\-M\fR, you can control it
-with a script supplied via standard input, like the \s-1MRI\s0 \*(L"librarian\*(R"
-program.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-\&\s-1GNU\s0 \fBar\fR allows you to mix the operation code \fIp\fR and modifier
-flags \fImod\fR in any order, within the first command-line argument.
-.PP
-If you wish, you may begin the first command-line argument with a
-dash.
-.PP
-The \fIp\fR keyletter specifies what operation to execute; it may be
-any of the following, but you must specify only one of them:
-.IP "\fBd\fR" 4
-.IX Item "d"
-\&\fIDelete\fR modules from the archive. Specify the names of modules to
-be deleted as \fImember\fR...; the archive is untouched if you
-specify no files to delete.
-.Sp
-If you specify the \fBv\fR modifier, \fBar\fR lists each module
-as it is deleted.
-.IP "\fBm\fR" 4
-.IX Item "m"
-Use this operation to \fImove\fR members in an archive.
-.Sp
-The ordering of members in an archive can make a difference in how
-programs are linked using the library, if a symbol is defined in more
-than one member.
-.Sp
-If no modifiers are used with \f(CW\*(C`m\*(C'\fR, any members you name in the
-\&\fImember\fR arguments are moved to the \fIend\fR of the archive;
-you can use the \fBa\fR, \fBb\fR, or \fBi\fR modifiers to move them to a
-specified place instead.
-.IP "\fBp\fR" 4
-.IX Item "p"
-\&\fIPrint\fR the specified members of the archive, to the standard
-output file. If the \fBv\fR modifier is specified, show the member
-name before copying its contents to standard output.
-.Sp
-If you specify no \fImember\fR arguments, all the files in the archive are
-printed.
-.IP "\fBq\fR" 4
-.IX Item "q"
-\&\fIQuick append\fR; Historically, add the files \fImember\fR... to the end of
-\&\fIarchive\fR, without checking for replacement.
-.Sp
-The modifiers \fBa\fR, \fBb\fR, and \fBi\fR do \fInot\fR affect this
-operation; new members are always placed at the end of the archive.
-.Sp
-The modifier \fBv\fR makes \fBar\fR list each file as it is appended.
-.Sp
-Since the point of this operation is speed, the archive's symbol table
-index is not updated, even if it already existed; you can use \fBar s\fR or
-\&\fBranlib\fR explicitly to update the symbol table index.
-.Sp
-However, too many different systems assume quick append rebuilds the
-index, so \s-1GNU\s0 \fBar\fR implements \fBq\fR as a synonym for \fBr\fR.
-.IP "\fBr\fR" 4
-.IX Item "r"
-Insert the files \fImember\fR... into \fIarchive\fR (with
-\&\fIreplacement\fR). This operation differs from \fBq\fR in that any
-previously existing members are deleted if their names match those being
-added.
-.Sp
-If one of the files named in \fImember\fR... does not exist, \fBar\fR
-displays an error message, and leaves undisturbed any existing members
-of the archive matching that name.
-.Sp
-By default, new members are added at the end of the file; but you may
-use one of the modifiers \fBa\fR, \fBb\fR, or \fBi\fR to request
-placement relative to some existing member.
-.Sp
-The modifier \fBv\fR used with this operation elicits a line of
-output for each file inserted, along with one of the letters \fBa\fR or
-\&\fBr\fR to indicate whether the file was appended (no old member
-deleted) or replaced.
-.IP "\fBs\fR" 4
-.IX Item "s"
-Add an index to the archive, or update it if it already exists. Note
-this command is an exception to the rule that there can only be one
-command letter, as it is possible to use it as either a command or a
-modifier. In either case it does the same thing.
-.IP "\fBt\fR" 4
-.IX Item "t"
-Display a \fItable\fR listing the contents of \fIarchive\fR, or those
-of the files listed in \fImember\fR... that are present in the
-archive. Normally only the member name is shown; if you also want to
-see the modes (permissions), timestamp, owner, group, and size, you can
-request that by also specifying the \fBv\fR modifier.
-.Sp
-If you do not specify a \fImember\fR, all files in the archive
-are listed.
-.Sp
-If there is more than one file with the same name (say, \fBfie\fR) in
-an archive (say \fBb.a\fR), \fBar t b.a fie\fR lists only the
-first instance; to see them all, you must ask for a complete
-listing\-\-\-in our example, \fBar t b.a\fR.
-.IP "\fBx\fR" 4
-.IX Item "x"
-\&\fIExtract\fR members (named \fImember\fR) from the archive. You can
-use the \fBv\fR modifier with this operation, to request that
-\&\fBar\fR list each name as it extracts it.
-.Sp
-If you do not specify a \fImember\fR, all files in the archive
-are extracted.
-.Sp
-Files cannot be extracted from a thin archive.
-.PP
-A number of modifiers (\fImod\fR) may immediately follow the \fIp\fR
-keyletter, to specify variations on an operation's behavior:
-.IP "\fBa\fR" 4
-.IX Item "a"
-Add new files \fIafter\fR an existing member of the
-archive. If you use the modifier \fBa\fR, the name of an existing archive
-member must be present as the \fIrelpos\fR argument, before the
-\&\fIarchive\fR specification.
-.IP "\fBb\fR" 4
-.IX Item "b"
-Add new files \fIbefore\fR an existing member of the
-archive. If you use the modifier \fBb\fR, the name of an existing archive
-member must be present as the \fIrelpos\fR argument, before the
-\&\fIarchive\fR specification. (same as \fBi\fR).
-.IP "\fBc\fR" 4
-.IX Item "c"
-\&\fICreate\fR the archive. The specified \fIarchive\fR is always
-created if it did not exist, when you request an update. But a warning is
-issued unless you specify in advance that you expect to create it, by
-using this modifier.
-.IP "\fBD\fR" 4
-.IX Item "D"
-Operate in \fIdeterministic\fR mode. When adding files and the archive
-index use zero for UIDs, GIDs, timestamps, and use consistent file modes
-for all files. When this option is used, if \fBar\fR is used with
-identical options and identical input files, multiple runs will create
-identical output files regardless of the input files' owners, groups,
-file modes, or modification times.
-.IP "\fBf\fR" 4
-.IX Item "f"
-Truncate names in the archive. \s-1GNU\s0 \fBar\fR will normally permit file
-names of any length. This will cause it to create archives which are
-not compatible with the native \fBar\fR program on some systems. If
-this is a concern, the \fBf\fR modifier may be used to truncate file
-names when putting them in the archive.
-.IP "\fBi\fR" 4
-.IX Item "i"
-Insert new files \fIbefore\fR an existing member of the
-archive. If you use the modifier \fBi\fR, the name of an existing archive
-member must be present as the \fIrelpos\fR argument, before the
-\&\fIarchive\fR specification. (same as \fBb\fR).
-.IP "\fBl\fR" 4
-.IX Item "l"
-This modifier is accepted but not used.
-.IP "\fBN\fR" 4
-.IX Item "N"
-Uses the \fIcount\fR parameter. This is used if there are multiple
-entries in the archive with the same name. Extract or delete instance
-\&\fIcount\fR of the given name from the archive.
-.IP "\fBo\fR" 4
-.IX Item "o"
-Preserve the \fIoriginal\fR dates of members when extracting them. If
-you do not specify this modifier, files extracted from the archive
-are stamped with the time of extraction.
-.IP "\fBP\fR" 4
-.IX Item "P"
-Use the full path name when matching names in the archive. \s-1GNU\s0
-\&\fBar\fR can not create an archive with a full path name (such archives
-are not \s-1POSIX\s0 complaint), but other archive creators can. This option
-will cause \s-1GNU\s0 \fBar\fR to match file names using a complete path
-name, which can be convenient when extracting a single file from an
-archive created by another tool.
-.IP "\fBs\fR" 4
-.IX Item "s"
-Write an object-file index into the archive, or update an existing one,
-even if no other change is made to the archive. You may use this modifier
-flag either with any operation, or alone. Running \fBar s\fR on an
-archive is equivalent to running \fBranlib\fR on it.
-.IP "\fBS\fR" 4
-.IX Item "S"
-Do not generate an archive symbol table. This can speed up building a
-large library in several steps. The resulting archive can not be used
-with the linker. In order to build a symbol table, you must omit the
-\&\fBS\fR modifier on the last execution of \fBar\fR, or you must run
-\&\fBranlib\fR on the archive.
-.IP "\fBT\fR" 4
-.IX Item "T"
-Make the specified \fIarchive\fR a \fIthin\fR archive. If it already
-exists and is a regular archive, the existing members must be present
-in the same directory as \fIarchive\fR.
-.IP "\fBu\fR" 4
-.IX Item "u"
-Normally, \fBar r\fR... inserts all files
-listed into the archive. If you would like to insert \fIonly\fR those
-of the files you list that are newer than existing members of the same
-names, use this modifier. The \fBu\fR modifier is allowed only for the
-operation \fBr\fR (replace). In particular, the combination \fBqu\fR is
-not allowed, since checking the timestamps would lose any speed
-advantage from the operation \fBq\fR.
-.IP "\fBv\fR" 4
-.IX Item "v"
-This modifier requests the \fIverbose\fR version of an operation. Many
-operations display additional information, such as filenames processed,
-when the modifier \fBv\fR is appended.
-.IP "\fBV\fR" 4
-.IX Item "V"
-This modifier shows the version number of \fBar\fR.
-.PP
-\&\fBar\fR ignores an initial option spelt \fB\-X32_64\fR, for
-compatibility with \s-1AIX\s0. The behaviour produced by this option is the
-default for \s-1GNU\s0 \fBar\fR. \fBar\fR does not support any of the other
-\&\fB\-X\fR options; in particular, it does not support \fB\-X32\fR
-which is the default for \s-1AIX\s0 \fBar\fR.
-.PP
-The optional command line switch \fB\-\-plugin\fR \fIname\fR causes
-\&\fBar\fR to load the plugin called \fIname\fR which adds support
-for more file formats. This option is only available if the toolchain
-has been built with plugin support enabled.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fInm\fR\|(1), \fIranlib\fR\|(1), and the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-as.1 b/share/man/man1/arm-eabi-as.1
deleted file mode 100644
index 3223590..0000000
--- a/share/man/man1/arm-eabi-as.1
+++ /dev/null
@@ -1,1321 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "AS 1"
-.TH AS 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-AS \- the portable GNU assembler.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-as [\fB\-a\fR[\fBcdghlns\fR][=\fIfile\fR]] [\fB\-\-alternate\fR] [\fB\-D\fR]
- [\fB\-\-compress\-debug\-sections\fR] [\fB\-\-nocompress\-debug\-sections\fR]
- [\fB\-\-debug\-prefix\-map\fR \fIold\fR=\fInew\fR]
- [\fB\-\-defsym\fR \fIsym\fR=\fIval\fR] [\fB\-f\fR] [\fB\-g\fR] [\fB\-\-gstabs\fR]
- [\fB\-\-gstabs+\fR] [\fB\-\-gdwarf\-2\fR] [\fB\-\-help\fR] [\fB\-I\fR \fIdir\fR] [\fB\-J\fR]
- [\fB\-K\fR] [\fB\-L\fR] [\fB\-\-listing\-lhs\-width\fR=\fI\s-1NUM\s0\fR]
- [\fB\-\-listing\-lhs\-width2\fR=\fI\s-1NUM\s0\fR] [\fB\-\-listing\-rhs\-width\fR=\fI\s-1NUM\s0\fR]
- [\fB\-\-listing\-cont\-lines\fR=\fI\s-1NUM\s0\fR] [\fB\-\-keep\-locals\fR] [\fB\-o\fR
- \fIobjfile\fR] [\fB\-R\fR] [\fB\-\-reduce\-memory\-overheads\fR] [\fB\-\-statistics\fR]
- [\fB\-v\fR] [\fB\-version\fR] [\fB\-\-version\fR] [\fB\-W\fR] [\fB\-\-warn\fR]
- [\fB\-\-fatal\-warnings\fR] [\fB\-w\fR] [\fB\-x\fR] [\fB\-Z\fR] [\fB@\fR\fI\s-1FILE\s0\fR]
- [\fB\-\-target\-help\fR] [\fItarget-options\fR]
- [\fB\-\-\fR|\fIfiles\fR ...]
-.PP
-\&\fITarget Alpha options:\fR
- [\fB\-m\fR\fIcpu\fR]
- [\fB\-mdebug\fR | \fB\-no\-mdebug\fR]
- [\fB\-replace\fR | \fB\-noreplace\fR]
- [\fB\-relax\fR] [\fB\-g\fR] [\fB\-G\fR\fIsize\fR]
- [\fB\-F\fR] [\fB\-32addr\fR]
-.PP
-\&\fITarget \s-1ARC\s0 options:\fR
- [\fB\-marc[5|6|7|8]\fR]
- [\fB\-EB\fR|\fB\-EL\fR]
-.PP
-\&\fITarget \s-1ARM\s0 options:\fR
- [\fB\-mcpu\fR=\fIprocessor\fR[+\fIextension\fR...]]
- [\fB\-march\fR=\fIarchitecture\fR[+\fIextension\fR...]]
- [\fB\-mfpu\fR=\fIfloating-point-format\fR]
- [\fB\-mfloat\-abi\fR=\fIabi\fR]
- [\fB\-meabi\fR=\fIver\fR]
- [\fB\-mthumb\fR]
- [\fB\-EB\fR|\fB\-EL\fR]
- [\fB\-mapcs\-32\fR|\fB\-mapcs\-26\fR|\fB\-mapcs\-float\fR|
- \fB\-mapcs\-reentrant\fR]
- [\fB\-mthumb\-interwork\fR] [\fB\-k\fR]
-.PP
-\&\fITarget Blackfin options:\fR
- [\fB\-mcpu\fR=\fIprocessor\fR[\-\fIsirevision\fR]]
- [\fB\-mfdpic\fR]
- [\fB\-mno\-fdpic\fR]
- [\fB\-mnopic\fR]
-.PP
-\&\fITarget \s-1CRIS\s0 options:\fR
- [\fB\-\-underscore\fR | \fB\-\-no\-underscore\fR]
- [\fB\-\-pic\fR] [\fB\-N\fR]
- [\fB\-\-emulation=criself\fR | \fB\-\-emulation=crisaout\fR]
- [\fB\-\-march=v0_v10\fR | \fB\-\-march=v10\fR | \fB\-\-march=v32\fR | \fB\-\-march=common_v10_v32\fR]
-.PP
-\&\fITarget D10V options:\fR
- [\fB\-O\fR]
-.PP
-\&\fITarget D30V options:\fR
- [\fB\-O\fR|\fB\-n\fR|\fB\-N\fR]
-.PP
-\&\fITarget H8/300 options:\fR
- [\-h\-tick\-hex]
-.PP
-\&\fITarget i386 options:\fR
- [\fB\-\-32\fR|\fB\-\-64\fR] [\fB\-n\fR]
- [\fB\-march\fR=\fI\s-1CPU\s0\fR[+\fI\s-1EXTENSION\s0\fR...]] [\fB\-mtune\fR=\fI\s-1CPU\s0\fR]
-.PP
-\&\fITarget i960 options:\fR
- [\fB\-ACA\fR|\fB\-ACA_A\fR|\fB\-ACB\fR|\fB\-ACC\fR|\fB\-AKA\fR|\fB\-AKB\fR|
- \fB\-AKC\fR|\fB\-AMC\fR]
- [\fB\-b\fR] [\fB\-no\-relax\fR]
-.PP
-\&\fITarget \s-1IA\-64\s0 options:\fR
- [\fB\-mconstant\-gp\fR|\fB\-mauto\-pic\fR]
- [\fB\-milp32\fR|\fB\-milp64\fR|\fB\-mlp64\fR|\fB\-mp64\fR]
- [\fB\-mle\fR|\fBmbe\fR]
- [\fB\-mtune=itanium1\fR|\fB\-mtune=itanium2\fR]
- [\fB\-munwind\-check=warning\fR|\fB\-munwind\-check=error\fR]
- [\fB\-mhint.b=ok\fR|\fB\-mhint.b=warning\fR|\fB\-mhint.b=error\fR]
- [\fB\-x\fR|\fB\-xexplicit\fR] [\fB\-xauto\fR] [\fB\-xdebug\fR]
-.PP
-\&\fITarget \s-1IP2K\s0 options:\fR
- [\fB\-mip2022\fR|\fB\-mip2022ext\fR]
-.PP
-\&\fITarget M32C options:\fR
- [\fB\-m32c\fR|\fB\-m16c\fR] [\-relax] [\-h\-tick\-hex]
-.PP
-\&\fITarget M32R options:\fR
- [\fB\-\-m32rx\fR|\fB\-\-[no\-]warn\-explicit\-parallel\-conflicts\fR|
- \fB\-\-W[n]p\fR]
-.PP
-\&\fITarget M680X0 options:\fR
- [\fB\-l\fR] [\fB\-m68000\fR|\fB\-m68010\fR|\fB\-m68020\fR|...]
-.PP
-\&\fITarget M68HC11 options:\fR
- [\fB\-m68hc11\fR|\fB\-m68hc12\fR|\fB\-m68hcs12\fR]
- [\fB\-mshort\fR|\fB\-mlong\fR]
- [\fB\-mshort\-double\fR|\fB\-mlong\-double\fR]
- [\fB\-\-force\-long\-branches\fR] [\fB\-\-short\-branches\fR]
- [\fB\-\-strict\-direct\-mode\fR] [\fB\-\-print\-insn\-syntax\fR]
- [\fB\-\-print\-opcodes\fR] [\fB\-\-generate\-example\fR]
-.PP
-\&\fITarget \s-1MCORE\s0 options:\fR
- [\fB\-jsri2bsr\fR] [\fB\-sifilter\fR] [\fB\-relax\fR]
- [\fB\-mcpu=[210|340]\fR]
-\&\fITarget \s-1MICROBLAZE\s0 options:\fR
-.PP
-\&\fITarget \s-1MIPS\s0 options:\fR
- [\fB\-nocpp\fR] [\fB\-EL\fR] [\fB\-EB\fR] [\fB\-O\fR[\fIoptimization level\fR]]
- [\fB\-g\fR[\fIdebug level\fR]] [\fB\-G\fR \fInum\fR] [\fB\-KPIC\fR] [\fB\-call_shared\fR]
- [\fB\-non_shared\fR] [\fB\-xgot\fR [\fB\-mvxworks\-pic\fR]
- [\fB\-mabi\fR=\fI\s-1ABI\s0\fR] [\fB\-32\fR] [\fB\-n32\fR] [\fB\-64\fR] [\fB\-mfp32\fR] [\fB\-mgp32\fR]
- [\fB\-march\fR=\fI\s-1CPU\s0\fR] [\fB\-mtune\fR=\fI\s-1CPU\s0\fR] [\fB\-mips1\fR] [\fB\-mips2\fR]
- [\fB\-mips3\fR] [\fB\-mips4\fR] [\fB\-mips5\fR] [\fB\-mips32\fR] [\fB\-mips32r2\fR]
- [\fB\-mips64\fR] [\fB\-mips64r2\fR]
- [\fB\-construct\-floats\fR] [\fB\-no\-construct\-floats\fR]
- [\fB\-trap\fR] [\fB\-no\-break\fR] [\fB\-break\fR] [\fB\-no\-trap\fR]
- [\fB\-mips16\fR] [\fB\-no\-mips16\fR]
- [\fB\-msmartmips\fR] [\fB\-mno\-smartmips\fR]
- [\fB\-mips3d\fR] [\fB\-no\-mips3d\fR]
- [\fB\-mdmx\fR] [\fB\-no\-mdmx\fR]
- [\fB\-mdsp\fR] [\fB\-mno\-dsp\fR]
- [\fB\-mdspr2\fR] [\fB\-mno\-dspr2\fR]
- [\fB\-mmt\fR] [\fB\-mno\-mt\fR]
- [\fB\-mfix7000\fR] [\fB\-mno\-fix7000\fR]
- [\fB\-mfix\-vr4120\fR] [\fB\-mno\-fix\-vr4120\fR]
- [\fB\-mfix\-vr4130\fR] [\fB\-mno\-fix\-vr4130\fR]
- [\fB\-mdebug\fR] [\fB\-no\-mdebug\fR]
- [\fB\-mpdr\fR] [\fB\-mno\-pdr\fR]
-.PP
-\&\fITarget \s-1MMIX\s0 options:\fR
- [\fB\-\-fixed\-special\-register\-names\fR] [\fB\-\-globalize\-symbols\fR]
- [\fB\-\-gnu\-syntax\fR] [\fB\-\-relax\fR] [\fB\-\-no\-predefined\-symbols\fR]
- [\fB\-\-no\-expand\fR] [\fB\-\-no\-merge\-gregs\fR] [\fB\-x\fR]
- [\fB\-\-linker\-allocated\-gregs\fR]
-.PP
-\&\fITarget \s-1PDP11\s0 options:\fR
- [\fB\-mpic\fR|\fB\-mno\-pic\fR] [\fB\-mall\fR] [\fB\-mno\-extensions\fR]
- [\fB\-m\fR\fIextension\fR|\fB\-mno\-\fR\fIextension\fR]
- [\fB\-m\fR\fIcpu\fR] [\fB\-m\fR\fImachine\fR]
-.PP
-\&\fITarget picoJava options:\fR
- [\fB\-mb\fR|\fB\-me\fR]
-.PP
-\&\fITarget PowerPC options:\fR
- [\fB\-mpwrx\fR|\fB\-mpwr2\fR|\fB\-mpwr\fR|\fB\-m601\fR|\fB\-mppc\fR|\fB\-mppc32\fR|\fB\-m603\fR|\fB\-m604\fR|
- \fB\-m403\fR|\fB\-m405\fR|\fB\-mppc64\fR|\fB\-m620\fR|\fB\-mppc64bridge\fR|\fB\-mbooke\fR]
- [\fB\-mcom\fR|\fB\-many\fR|\fB\-maltivec\fR|\fB\-mvsx\fR] [\fB\-memb\fR]
- [\fB\-mregnames\fR|\fB\-mno\-regnames\fR]
- [\fB\-mrelocatable\fR|\fB\-mrelocatable\-lib\fR]
- [\fB\-mlittle\fR|\fB\-mlittle\-endian\fR|\fB\-mbig\fR|\fB\-mbig\-endian\fR]
- [\fB\-msolaris\fR|\fB\-mno\-solaris\fR]
-.PP
-\&\fITarget \s-1RX\s0 options:\fR
- [\fB\-mlittle\-endian\fR|\fB\-mbig\-endian\fR]
- [\fB\-m32bit\-ints\fR|\fB\-m16bit\-ints\fR]
- [\fB\-m32bit\-doubles\fR|\fB\-m64bit\-doubles\fR]
-.PP
-\&\fITarget s390 options:\fR
- [\fB\-m31\fR|\fB\-m64\fR] [\fB\-mesa\fR|\fB\-mzarch\fR] [\fB\-march\fR=\fI\s-1CPU\s0\fR]
- [\fB\-mregnames\fR|\fB\-mno\-regnames\fR]
- [\fB\-mwarn\-areg\-zero\fR]
-.PP
-\&\fITarget \s-1SCORE\s0 options:\fR
- [\fB\-EB\fR][\fB\-EL\fR][\fB\-FIXDD\fR][\fB\-NWARN\fR]
- [\fB\-SCORE5\fR][\fB\-SCORE5U\fR][\fB\-SCORE7\fR][\fB\-SCORE3\fR]
- [\fB\-march=score7\fR][\fB\-march=score3\fR]
- [\fB\-USE_R1\fR][\fB\-KPIC\fR][\fB\-O0\fR][\fB\-G\fR \fInum\fR][\fB\-V\fR]
-.PP
-\&\fITarget \s-1SPARC\s0 options:\fR
- [\fB\-Av6\fR|\fB\-Av7\fR|\fB\-Av8\fR|\fB\-Asparclet\fR|\fB\-Asparclite\fR
- \fB\-Av8plus\fR|\fB\-Av8plusa\fR|\fB\-Av9\fR|\fB\-Av9a\fR]
- [\fB\-xarch=v8plus\fR|\fB\-xarch=v8plusa\fR] [\fB\-bump\fR]
- [\fB\-32\fR|\fB\-64\fR]
-.PP
-\&\fITarget \s-1TIC54X\s0 options:\fR
- [\fB\-mcpu=54[123589]\fR|\fB\-mcpu=54[56]lp\fR] [\fB\-mfar\-mode\fR|\fB\-mf\fR]
- [\fB\-merrors\-to\-file\fR \fI<filename>\fR|\fB\-me\fR \fI<filename>\fR]
-.PP
-\&\fITarget \s-1TIC6X\s0 options:\fR
- [\fB\-march=\fR\fIarch\fR] [\fB\-matomic\fR|\fB\-mno\-atomic\fR]
- [\fB\-mbig\-endian\fR|\fB\-mlittle\-endian\fR] [\fB\-mdsbt\fR|\fB\-mno\-dsbt\fR]
- [\fB\-mpid=no\fR|\fB\-mpid=near\fR|\fB\-mpid=far\fR] [\fB\-mpic\fR|\fB\-mno\-pic\fR]
-.PP
-\&\fITarget Z80 options:\fR
- [\fB\-z80\fR] [\fB\-r800\fR]
- [ \fB\-ignore\-undocumented\-instructions\fR] [\fB\-Wnud\fR]
- [ \fB\-ignore\-unportable\-instructions\fR] [\fB\-Wnup\fR]
- [ \fB\-warn\-undocumented\-instructions\fR] [\fB\-Wud\fR]
- [ \fB\-warn\-unportable\-instructions\fR] [\fB\-Wup\fR]
- [ \fB\-forbid\-undocumented\-instructions\fR] [\fB\-Fud\fR]
- [ \fB\-forbid\-unportable\-instructions\fR] [\fB\-Fup\fR]
-.PP
-\&\fITarget Xtensa options:\fR
- [\fB\-\-[no\-]text\-section\-literals\fR] [\fB\-\-[no\-]absolute\-literals\fR]
- [\fB\-\-[no\-]target\-align\fR] [\fB\-\-[no\-]longcalls\fR]
- [\fB\-\-[no\-]transform\fR]
- [\fB\-\-rename\-section\fR \fIoldname\fR=\fInewname\fR]
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\s-1GNU\s0 \fBas\fR is really a family of assemblers.
-If you use (or have used) the \s-1GNU\s0 assembler on one architecture, you
-should find a fairly similar environment when you use it on another
-architecture. Each version has much in common with the others,
-including object file formats, most assembler directives (often called
-\&\fIpseudo-ops\fR) and assembler syntax.
-.PP
-\&\fBas\fR is primarily intended to assemble the output of the
-\&\s-1GNU\s0 C compiler \f(CW\*(C`gcc\*(C'\fR for use by the linker
-\&\f(CW\*(C`ld\*(C'\fR. Nevertheless, we've tried to make \fBas\fR
-assemble correctly everything that other assemblers for the same
-machine would assemble.
-Any exceptions are documented explicitly.
-This doesn't mean \fBas\fR always uses the same syntax as another
-assembler for the same architecture; for example, we know of several
-incompatible versions of 680x0 assembly language syntax.
-.PP
-Each time you run \fBas\fR it assembles exactly one source
-program. The source program is made up of one or more files.
-(The standard input is also a file.)
-.PP
-You give \fBas\fR a command line that has zero or more input file
-names. The input files are read (from left file name to right). A
-command line argument (in any position) that has no special meaning
-is taken to be an input file name.
-.PP
-If you give \fBas\fR no file names it attempts to read one input file
-from the \fBas\fR standard input, which is normally your terminal. You
-may have to type \fBctl-D\fR to tell \fBas\fR there is no more program
-to assemble.
-.PP
-Use \fB\-\-\fR if you need to explicitly name the standard input file
-in your command line.
-.PP
-If the source is empty, \fBas\fR produces a small, empty object
-file.
-.PP
-\&\fBas\fR may write warnings and error messages to the standard error
-file (usually your terminal). This should not happen when a compiler
-runs \fBas\fR automatically. Warnings report an assumption made so
-that \fBas\fR could keep assembling a flawed program; errors report a
-grave problem that stops the assembly.
-.PP
-If you are invoking \fBas\fR via the \s-1GNU\s0 C compiler,
-you can use the \fB\-Wa\fR option to pass arguments through to the assembler.
-The assembler arguments must be separated from each other (and the \fB\-Wa\fR)
-by commas. For example:
-.PP
-.Vb 1
-\& gcc \-c \-g \-O \-Wa,\-alh,\-L file.c
-.Ve
-.PP
-This passes two options to the assembler: \fB\-alh\fR (emit a listing to
-standard output with high-level and assembly source) and \fB\-L\fR (retain
-local symbols in the symbol table).
-.PP
-Usually you do not need to use this \fB\-Wa\fR mechanism, since many compiler
-command-line options are automatically passed to the assembler by the compiler.
-(You can call the \s-1GNU\s0 compiler driver with the \fB\-v\fR option to see
-precisely what options it passes to each compilation pass, including the
-assembler.)
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.IP "\fB\-a[cdghlmns]\fR" 4
-.IX Item "-a[cdghlmns]"
-Turn on listings, in any of a variety of ways:
-.RS 4
-.IP "\fB\-ac\fR" 4
-.IX Item "-ac"
-omit false conditionals
-.IP "\fB\-ad\fR" 4
-.IX Item "-ad"
-omit debugging directives
-.IP "\fB\-ag\fR" 4
-.IX Item "-ag"
-include general information, like as version and options passed
-.IP "\fB\-ah\fR" 4
-.IX Item "-ah"
-include high-level source
-.IP "\fB\-al\fR" 4
-.IX Item "-al"
-include assembly
-.IP "\fB\-am\fR" 4
-.IX Item "-am"
-include macro expansions
-.IP "\fB\-an\fR" 4
-.IX Item "-an"
-omit forms processing
-.IP "\fB\-as\fR" 4
-.IX Item "-as"
-include symbols
-.IP "\fB=file\fR" 4
-.IX Item "=file"
-set the name of the listing file
-.RE
-.RS 4
-.Sp
-You may combine these options; for example, use \fB\-aln\fR for assembly
-listing without forms processing. The \fB=file\fR option, if used, must be
-the last one. By itself, \fB\-a\fR defaults to \fB\-ahls\fR.
-.RE
-.IP "\fB\-\-alternate\fR" 4
-.IX Item "--alternate"
-Begin in alternate macro mode.
-.IP "\fB\-\-compress\-debug\-sections\fR" 4
-.IX Item "--compress-debug-sections"
-Compress \s-1DWARF\s0 debug sections using zlib. The debug sections are renamed
-to begin with \fB.zdebug\fR, and the resulting object file may not be
-compatible with older linkers and object file utilities.
-.IP "\fB\-\-nocompress\-debug\-sections\fR" 4
-.IX Item "--nocompress-debug-sections"
-Do not compress \s-1DWARF\s0 debug sections. This is the default.
-.IP "\fB\-D\fR" 4
-.IX Item "-D"
-Ignored. This option is accepted for script compatibility with calls to
-other assemblers.
-.IP "\fB\-\-debug\-prefix\-map\fR \fIold\fR\fB=\fR\fInew\fR" 4
-.IX Item "--debug-prefix-map old=new"
-When assembling files in directory \fI\fIold\fI\fR, record debugging
-information describing them as in \fI\fInew\fI\fR instead.
-.IP "\fB\-\-defsym\fR \fIsym\fR\fB=\fR\fIvalue\fR" 4
-.IX Item "--defsym sym=value"
-Define the symbol \fIsym\fR to be \fIvalue\fR before assembling the input file.
-\&\fIvalue\fR must be an integer constant. As in C, a leading \fB0x\fR
-indicates a hexadecimal value, and a leading \fB0\fR indicates an octal
-value. The value of the symbol can be overridden inside a source file via the
-use of a \f(CW\*(C`.set\*(C'\fR pseudo-op.
-.IP "\fB\-f\fR" 4
-.IX Item "-f"
-\&\*(L"fast\*(R"\-\-\-skip whitespace and comment preprocessing (assume source is
-compiler output).
-.IP "\fB\-g\fR" 4
-.IX Item "-g"
-.PD 0
-.IP "\fB\-\-gen\-debug\fR" 4
-.IX Item "--gen-debug"
-.PD
-Generate debugging information for each assembler source line using whichever
-debug format is preferred by the target. This currently means either \s-1STABS\s0,
-\&\s-1ECOFF\s0 or \s-1DWARF2\s0.
-.IP "\fB\-\-gstabs\fR" 4
-.IX Item "--gstabs"
-Generate stabs debugging information for each assembler line. This
-may help debugging assembler code, if the debugger can handle it.
-.IP "\fB\-\-gstabs+\fR" 4
-.IX Item "--gstabs+"
-Generate stabs debugging information for each assembler line, with \s-1GNU\s0
-extensions that probably only gdb can handle, and that could make other
-debuggers crash or refuse to read your program. This
-may help debugging assembler code. Currently the only \s-1GNU\s0 extension is
-the location of the current working directory at assembling time.
-.IP "\fB\-\-gdwarf\-2\fR" 4
-.IX Item "--gdwarf-2"
-Generate \s-1DWARF2\s0 debugging information for each assembler line. This
-may help debugging assembler code, if the debugger can handle it. Note\-\-\-this
-option is only supported by some targets, not all of them.
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-Print a summary of the command line options and exit.
-.IP "\fB\-\-target\-help\fR" 4
-.IX Item "--target-help"
-Print a summary of all target specific options and exit.
-.IP "\fB\-I\fR \fIdir\fR" 4
-.IX Item "-I dir"
-Add directory \fIdir\fR to the search list for \f(CW\*(C`.include\*(C'\fR directives.
-.IP "\fB\-J\fR" 4
-.IX Item "-J"
-Don't warn about signed overflow.
-.IP "\fB\-K\fR" 4
-.IX Item "-K"
-Issue warnings when difference tables altered for long displacements.
-.IP "\fB\-L\fR" 4
-.IX Item "-L"
-.PD 0
-.IP "\fB\-\-keep\-locals\fR" 4
-.IX Item "--keep-locals"
-.PD
-Keep (in the symbol table) local symbols. These symbols start with
-system-specific local label prefixes, typically \fB.L\fR for \s-1ELF\s0 systems
-or \fBL\fR for traditional a.out systems.
-.IP "\fB\-\-listing\-lhs\-width=\fR\fInumber\fR" 4
-.IX Item "--listing-lhs-width=number"
-Set the maximum width, in words, of the output data column for an assembler
-listing to \fInumber\fR.
-.IP "\fB\-\-listing\-lhs\-width2=\fR\fInumber\fR" 4
-.IX Item "--listing-lhs-width2=number"
-Set the maximum width, in words, of the output data column for continuation
-lines in an assembler listing to \fInumber\fR.
-.IP "\fB\-\-listing\-rhs\-width=\fR\fInumber\fR" 4
-.IX Item "--listing-rhs-width=number"
-Set the maximum width of an input source line, as displayed in a listing, to
-\&\fInumber\fR bytes.
-.IP "\fB\-\-listing\-cont\-lines=\fR\fInumber\fR" 4
-.IX Item "--listing-cont-lines=number"
-Set the maximum number of lines printed in a listing for a single line of input
-to \fInumber\fR + 1.
-.IP "\fB\-o\fR \fIobjfile\fR" 4
-.IX Item "-o objfile"
-Name the object-file output from \fBas\fR \fIobjfile\fR.
-.IP "\fB\-R\fR" 4
-.IX Item "-R"
-Fold the data section into the text section.
-.Sp
-Set the default size of \s-1GAS\s0's hash tables to a prime number close to
-\&\fInumber\fR. Increasing this value can reduce the length of time it takes the
-assembler to perform its tasks, at the expense of increasing the assembler's
-memory requirements. Similarly reducing this value can reduce the memory
-requirements at the expense of speed.
-.IP "\fB\-\-reduce\-memory\-overheads\fR" 4
-.IX Item "--reduce-memory-overheads"
-This option reduces \s-1GAS\s0's memory requirements, at the expense of making the
-assembly processes slower. Currently this switch is a synonym for
-\&\fB\-\-hash\-size=4051\fR, but in the future it may have other effects as well.
-.IP "\fB\-\-statistics\fR" 4
-.IX Item "--statistics"
-Print the maximum space (in bytes) and total time (in seconds) used by
-assembly.
-.IP "\fB\-\-strip\-local\-absolute\fR" 4
-.IX Item "--strip-local-absolute"
-Remove local absolute symbols from the outgoing symbol table.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.IP "\fB\-version\fR" 4
-.IX Item "-version"
-.PD
-Print the \fBas\fR version.
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-Print the \fBas\fR version and exit.
-.IP "\fB\-W\fR" 4
-.IX Item "-W"
-.PD 0
-.IP "\fB\-\-no\-warn\fR" 4
-.IX Item "--no-warn"
-.PD
-Suppress warning messages.
-.IP "\fB\-\-fatal\-warnings\fR" 4
-.IX Item "--fatal-warnings"
-Treat warnings as errors.
-.IP "\fB\-\-warn\fR" 4
-.IX Item "--warn"
-Don't suppress warning messages or treat them as errors.
-.IP "\fB\-w\fR" 4
-.IX Item "-w"
-Ignored.
-.IP "\fB\-x\fR" 4
-.IX Item "-x"
-Ignored.
-.IP "\fB\-Z\fR" 4
-.IX Item "-Z"
-Generate an object file even after errors.
-.IP "\fB\-\- |\fR \fIfiles\fR \fB...\fR" 4
-.IX Item "-- | files ..."
-Standard input, or source files to assemble.
-.PP
-The following options are available when as is configured for
-an \s-1ARC\s0 processor.
-.IP "\fB\-marc[5|6|7|8]\fR" 4
-.IX Item "-marc[5|6|7|8]"
-This option selects the core processor variant.
-.IP "\fB\-EB | \-EL\fR" 4
-.IX Item "-EB | -EL"
-Select either big-endian (\-EB) or little-endian (\-EL) output.
-.PP
-The following options are available when as is configured for the \s-1ARM\s0
-processor family.
-.IP "\fB\-mcpu=\fR\fIprocessor\fR\fB[+\fR\fIextension\fR\fB...]\fR" 4
-.IX Item "-mcpu=processor[+extension...]"
-Specify which \s-1ARM\s0 processor variant is the target.
-.IP "\fB\-march=\fR\fIarchitecture\fR\fB[+\fR\fIextension\fR\fB...]\fR" 4
-.IX Item "-march=architecture[+extension...]"
-Specify which \s-1ARM\s0 architecture variant is used by the target.
-.IP "\fB\-mfpu=\fR\fIfloating-point-format\fR" 4
-.IX Item "-mfpu=floating-point-format"
-Select which Floating Point architecture is the target.
-.IP "\fB\-mfloat\-abi=\fR\fIabi\fR" 4
-.IX Item "-mfloat-abi=abi"
-Select which floating point \s-1ABI\s0 is in use.
-.IP "\fB\-mthumb\fR" 4
-.IX Item "-mthumb"
-Enable Thumb only instruction decoding.
-.IP "\fB\-mapcs\-32 | \-mapcs\-26 | \-mapcs\-float | \-mapcs\-reentrant\fR" 4
-.IX Item "-mapcs-32 | -mapcs-26 | -mapcs-float | -mapcs-reentrant"
-Select which procedure calling convention is in use.
-.IP "\fB\-EB | \-EL\fR" 4
-.IX Item "-EB | -EL"
-Select either big-endian (\-EB) or little-endian (\-EL) output.
-.IP "\fB\-mthumb\-interwork\fR" 4
-.IX Item "-mthumb-interwork"
-Specify that the code has been generated with interworking between Thumb and
-\&\s-1ARM\s0 code in mind.
-.IP "\fB\-k\fR" 4
-.IX Item "-k"
-Specify that \s-1PIC\s0 code has been generated.
-.PP
-The following options are available when as is configured for
-the Blackfin processor family.
-.IP "\fB\-mcpu=\fR\fIprocessor\fR[\fB\-\fR\fIsirevision\fR]" 4
-.IX Item "-mcpu=processor[-sirevision]"
-This option specifies the target processor. The optional \fIsirevision\fR
-is not used in assembler.
-.IP "\fB\-mfdpic\fR" 4
-.IX Item "-mfdpic"
-Assemble for the \s-1FDPIC\s0 \s-1ABI\s0.
-.IP "\fB\-mno\-fdpic\fR" 4
-.IX Item "-mno-fdpic"
-.PD 0
-.IP "\fB\-mnopic\fR" 4
-.IX Item "-mnopic"
-.PD
-Disable \-mfdpic.
-.PP
-See the info pages for documentation of the CRIS-specific options.
-.PP
-The following options are available when as is configured for
-a D10V processor.
-.IP "\fB\-O\fR" 4
-.IX Item "-O"
-Optimize output by parallelizing instructions.
-.PP
-The following options are available when as is configured for a D30V
-processor.
-.IP "\fB\-O\fR" 4
-.IX Item "-O"
-Optimize output by parallelizing instructions.
-.IP "\fB\-n\fR" 4
-.IX Item "-n"
-Warn when nops are generated.
-.IP "\fB\-N\fR" 4
-.IX Item "-N"
-Warn when a nop after a 32\-bit multiply instruction is generated.
-.PP
-The following options are available when as is configured for the
-Intel 80960 processor.
-.IP "\fB\-ACA | \-ACA_A | \-ACB | \-ACC | \-AKA | \-AKB | \-AKC | \-AMC\fR" 4
-.IX Item "-ACA | -ACA_A | -ACB | -ACC | -AKA | -AKB | -AKC | -AMC"
-Specify which variant of the 960 architecture is the target.
-.IP "\fB\-b\fR" 4
-.IX Item "-b"
-Add code to collect statistics about branches taken.
-.IP "\fB\-no\-relax\fR" 4
-.IX Item "-no-relax"
-Do not alter compare-and-branch instructions for long displacements;
-error if necessary.
-.PP
-The following options are available when as is configured for the
-Ubicom \s-1IP2K\s0 series.
-.IP "\fB\-mip2022ext\fR" 4
-.IX Item "-mip2022ext"
-Specifies that the extended \s-1IP2022\s0 instructions are allowed.
-.IP "\fB\-mip2022\fR" 4
-.IX Item "-mip2022"
-Restores the default behaviour, which restricts the permitted instructions to
-just the basic \s-1IP2022\s0 ones.
-.PP
-The following options are available when as is configured for the
-Renesas M32C and M16C processors.
-.IP "\fB\-m32c\fR" 4
-.IX Item "-m32c"
-Assemble M32C instructions.
-.IP "\fB\-m16c\fR" 4
-.IX Item "-m16c"
-Assemble M16C instructions (the default).
-.IP "\fB\-relax\fR" 4
-.IX Item "-relax"
-Enable support for link-time relaxations.
-.IP "\fB\-h\-tick\-hex\fR" 4
-.IX Item "-h-tick-hex"
-Support H'00 style hex constants in addition to 0x00 style.
-.PP
-The following options are available when as is configured for the
-Renesas M32R (formerly Mitsubishi M32R) series.
-.IP "\fB\-\-m32rx\fR" 4
-.IX Item "--m32rx"
-Specify which processor in the M32R family is the target. The default
-is normally the M32R, but this option changes it to the M32RX.
-.IP "\fB\-\-warn\-explicit\-parallel\-conflicts or \-\-Wp\fR" 4
-.IX Item "--warn-explicit-parallel-conflicts or --Wp"
-Produce warning messages when questionable parallel constructs are
-encountered.
-.IP "\fB\-\-no\-warn\-explicit\-parallel\-conflicts or \-\-Wnp\fR" 4
-.IX Item "--no-warn-explicit-parallel-conflicts or --Wnp"
-Do not produce warning messages when questionable parallel constructs are
-encountered.
-.PP
-The following options are available when as is configured for the
-Motorola 68000 series.
-.IP "\fB\-l\fR" 4
-.IX Item "-l"
-Shorten references to undefined symbols, to one word instead of two.
-.IP "\fB\-m68000 | \-m68008 | \-m68010 | \-m68020 | \-m68030\fR" 4
-.IX Item "-m68000 | -m68008 | -m68010 | -m68020 | -m68030"
-.PD 0
-.IP "\fB| \-m68040 | \-m68060 | \-m68302 | \-m68331 | \-m68332\fR" 4
-.IX Item "| -m68040 | -m68060 | -m68302 | -m68331 | -m68332"
-.IP "\fB| \-m68333 | \-m68340 | \-mcpu32 | \-m5200\fR" 4
-.IX Item "| -m68333 | -m68340 | -mcpu32 | -m5200"
-.PD
-Specify what processor in the 68000 family is the target. The default
-is normally the 68020, but this can be changed at configuration time.
-.IP "\fB\-m68881 | \-m68882 | \-mno\-68881 | \-mno\-68882\fR" 4
-.IX Item "-m68881 | -m68882 | -mno-68881 | -mno-68882"
-The target machine does (or does not) have a floating-point coprocessor.
-The default is to assume a coprocessor for 68020, 68030, and cpu32. Although
-the basic 68000 is not compatible with the 68881, a combination of the
-two can be specified, since it's possible to do emulation of the
-coprocessor instructions with the main processor.
-.IP "\fB\-m68851 | \-mno\-68851\fR" 4
-.IX Item "-m68851 | -mno-68851"
-The target machine does (or does not) have a memory-management
-unit coprocessor. The default is to assume an \s-1MMU\s0 for 68020 and up.
-.PP
-For details about the \s-1PDP\-11\s0 machine dependent features options,
-see \fBPDP\-11\-Options\fR.
-.IP "\fB\-mpic | \-mno\-pic\fR" 4
-.IX Item "-mpic | -mno-pic"
-Generate position-independent (or position-dependent) code. The
-default is \fB\-mpic\fR.
-.IP "\fB\-mall\fR" 4
-.IX Item "-mall"
-.PD 0
-.IP "\fB\-mall\-extensions\fR" 4
-.IX Item "-mall-extensions"
-.PD
-Enable all instruction set extensions. This is the default.
-.IP "\fB\-mno\-extensions\fR" 4
-.IX Item "-mno-extensions"
-Disable all instruction set extensions.
-.IP "\fB\-m\fR\fIextension\fR \fB| \-mno\-\fR\fIextension\fR" 4
-.IX Item "-mextension | -mno-extension"
-Enable (or disable) a particular instruction set extension.
-.IP "\fB\-m\fR\fIcpu\fR" 4
-.IX Item "-mcpu"
-Enable the instruction set extensions supported by a particular \s-1CPU\s0, and
-disable all other extensions.
-.IP "\fB\-m\fR\fImachine\fR" 4
-.IX Item "-mmachine"
-Enable the instruction set extensions supported by a particular machine
-model, and disable all other extensions.
-.PP
-The following options are available when as is configured for
-a picoJava processor.
-.IP "\fB\-mb\fR" 4
-.IX Item "-mb"
-Generate \*(L"big endian\*(R" format output.
-.IP "\fB\-ml\fR" 4
-.IX Item "-ml"
-Generate \*(L"little endian\*(R" format output.
-.PP
-The following options are available when as is configured for the
-Motorola 68HC11 or 68HC12 series.
-.IP "\fB\-m68hc11 | \-m68hc12 | \-m68hcs12\fR" 4
-.IX Item "-m68hc11 | -m68hc12 | -m68hcs12"
-Specify what processor is the target. The default is
-defined by the configuration option when building the assembler.
-.IP "\fB\-mshort\fR" 4
-.IX Item "-mshort"
-Specify to use the 16\-bit integer \s-1ABI\s0.
-.IP "\fB\-mlong\fR" 4
-.IX Item "-mlong"
-Specify to use the 32\-bit integer \s-1ABI\s0.
-.IP "\fB\-mshort\-double\fR" 4
-.IX Item "-mshort-double"
-Specify to use the 32\-bit double \s-1ABI\s0.
-.IP "\fB\-mlong\-double\fR" 4
-.IX Item "-mlong-double"
-Specify to use the 64\-bit double \s-1ABI\s0.
-.IP "\fB\-\-force\-long\-branches\fR" 4
-.IX Item "--force-long-branches"
-Relative branches are turned into absolute ones. This concerns
-conditional branches, unconditional branches and branches to a
-sub routine.
-.IP "\fB\-S | \-\-short\-branches\fR" 4
-.IX Item "-S | --short-branches"
-Do not turn relative branches into absolute ones
-when the offset is out of range.
-.IP "\fB\-\-strict\-direct\-mode\fR" 4
-.IX Item "--strict-direct-mode"
-Do not turn the direct addressing mode into extended addressing mode
-when the instruction does not support direct addressing mode.
-.IP "\fB\-\-print\-insn\-syntax\fR" 4
-.IX Item "--print-insn-syntax"
-Print the syntax of instruction in case of error.
-.IP "\fB\-\-print\-opcodes\fR" 4
-.IX Item "--print-opcodes"
-print the list of instructions with syntax and then exit.
-.IP "\fB\-\-generate\-example\fR" 4
-.IX Item "--generate-example"
-print an example of instruction for each possible instruction and then exit.
-This option is only useful for testing \fBas\fR.
-.PP
-The following options are available when \fBas\fR is configured
-for the \s-1SPARC\s0 architecture:
-.IP "\fB\-Av6 | \-Av7 | \-Av8 | \-Asparclet | \-Asparclite\fR" 4
-.IX Item "-Av6 | -Av7 | -Av8 | -Asparclet | -Asparclite"
-.PD 0
-.IP "\fB\-Av8plus | \-Av8plusa | \-Av9 | \-Av9a\fR" 4
-.IX Item "-Av8plus | -Av8plusa | -Av9 | -Av9a"
-.PD
-Explicitly select a variant of the \s-1SPARC\s0 architecture.
-.Sp
-\&\fB\-Av8plus\fR and \fB\-Av8plusa\fR select a 32 bit environment.
-\&\fB\-Av9\fR and \fB\-Av9a\fR select a 64 bit environment.
-.Sp
-\&\fB\-Av8plusa\fR and \fB\-Av9a\fR enable the \s-1SPARC\s0 V9 instruction set with
-UltraSPARC extensions.
-.IP "\fB\-xarch=v8plus | \-xarch=v8plusa\fR" 4
-.IX Item "-xarch=v8plus | -xarch=v8plusa"
-For compatibility with the Solaris v9 assembler. These options are
-equivalent to \-Av8plus and \-Av8plusa, respectively.
-.IP "\fB\-bump\fR" 4
-.IX Item "-bump"
-Warn when the assembler switches to another architecture.
-.PP
-The following options are available when as is configured for the 'c54x
-architecture.
-.IP "\fB\-mfar\-mode\fR" 4
-.IX Item "-mfar-mode"
-Enable extended addressing mode. All addresses and relocations will assume
-extended addressing (usually 23 bits).
-.IP "\fB\-mcpu=\fR\fI\s-1CPU_VERSION\s0\fR" 4
-.IX Item "-mcpu=CPU_VERSION"
-Sets the \s-1CPU\s0 version being compiled for.
-.IP "\fB\-merrors\-to\-file\fR \fI\s-1FILENAME\s0\fR" 4
-.IX Item "-merrors-to-file FILENAME"
-Redirect error output to a file, for broken systems which don't support such
-behaviour in the shell.
-.PP
-The following options are available when as is configured for
-a \s-1MIPS\s0 processor.
-.IP "\fB\-G\fR \fInum\fR" 4
-.IX Item "-G num"
-This option sets the largest size of an object that can be referenced
-implicitly with the \f(CW\*(C`gp\*(C'\fR register. It is only accepted for targets that
-use \s-1ECOFF\s0 format, such as a DECstation running Ultrix. The default value is 8.
-.IP "\fB\-EB\fR" 4
-.IX Item "-EB"
-Generate \*(L"big endian\*(R" format output.
-.IP "\fB\-EL\fR" 4
-.IX Item "-EL"
-Generate \*(L"little endian\*(R" format output.
-.IP "\fB\-mips1\fR" 4
-.IX Item "-mips1"
-.PD 0
-.IP "\fB\-mips2\fR" 4
-.IX Item "-mips2"
-.IP "\fB\-mips3\fR" 4
-.IX Item "-mips3"
-.IP "\fB\-mips4\fR" 4
-.IX Item "-mips4"
-.IP "\fB\-mips5\fR" 4
-.IX Item "-mips5"
-.IP "\fB\-mips32\fR" 4
-.IX Item "-mips32"
-.IP "\fB\-mips32r2\fR" 4
-.IX Item "-mips32r2"
-.IP "\fB\-mips64\fR" 4
-.IX Item "-mips64"
-.IP "\fB\-mips64r2\fR" 4
-.IX Item "-mips64r2"
-.PD
-Generate code for a particular \s-1MIPS\s0 Instruction Set Architecture level.
-\&\fB\-mips1\fR is an alias for \fB\-march=r3000\fR, \fB\-mips2\fR is an
-alias for \fB\-march=r6000\fR, \fB\-mips3\fR is an alias for
-\&\fB\-march=r4000\fR and \fB\-mips4\fR is an alias for \fB\-march=r8000\fR.
-\&\fB\-mips5\fR, \fB\-mips32\fR, \fB\-mips32r2\fR, \fB\-mips64\fR, and
-\&\fB\-mips64r2\fR
-correspond to generic
-\&\fB\s-1MIPS\s0 V\fR, \fB\s-1MIPS32\s0\fR, \fB\s-1MIPS32\s0 Release 2\fR, \fB\s-1MIPS64\s0\fR,
-and \fB\s-1MIPS64\s0 Release 2\fR
-\&\s-1ISA\s0 processors, respectively.
-.IP "\fB\-march=\fR\fI\s-1CPU\s0\fR" 4
-.IX Item "-march=CPU"
-Generate code for a particular \s-1MIPS\s0 cpu.
-.IP "\fB\-mtune=\fR\fIcpu\fR" 4
-.IX Item "-mtune=cpu"
-Schedule and tune for a particular \s-1MIPS\s0 cpu.
-.IP "\fB\-mfix7000\fR" 4
-.IX Item "-mfix7000"
-.PD 0
-.IP "\fB\-mno\-fix7000\fR" 4
-.IX Item "-mno-fix7000"
-.PD
-Cause nops to be inserted if the read of the destination register
-of an mfhi or mflo instruction occurs in the following two instructions.
-.IP "\fB\-mdebug\fR" 4
-.IX Item "-mdebug"
-.PD 0
-.IP "\fB\-no\-mdebug\fR" 4
-.IX Item "-no-mdebug"
-.PD
-Cause stabs-style debugging output to go into an ECOFF-style .mdebug
-section instead of the standard \s-1ELF\s0 .stabs sections.
-.IP "\fB\-mpdr\fR" 4
-.IX Item "-mpdr"
-.PD 0
-.IP "\fB\-mno\-pdr\fR" 4
-.IX Item "-mno-pdr"
-.PD
-Control generation of \f(CW\*(C`.pdr\*(C'\fR sections.
-.IP "\fB\-mgp32\fR" 4
-.IX Item "-mgp32"
-.PD 0
-.IP "\fB\-mfp32\fR" 4
-.IX Item "-mfp32"
-.PD
-The register sizes are normally inferred from the \s-1ISA\s0 and \s-1ABI\s0, but these
-flags force a certain group of registers to be treated as 32 bits wide at
-all times. \fB\-mgp32\fR controls the size of general-purpose registers
-and \fB\-mfp32\fR controls the size of floating-point registers.
-.IP "\fB\-mips16\fR" 4
-.IX Item "-mips16"
-.PD 0
-.IP "\fB\-no\-mips16\fR" 4
-.IX Item "-no-mips16"
-.PD
-Generate code for the \s-1MIPS\s0 16 processor. This is equivalent to putting
-\&\f(CW\*(C`.set mips16\*(C'\fR at the start of the assembly file. \fB\-no\-mips16\fR
-turns off this option.
-.IP "\fB\-msmartmips\fR" 4
-.IX Item "-msmartmips"
-.PD 0
-.IP "\fB\-mno\-smartmips\fR" 4
-.IX Item "-mno-smartmips"
-.PD
-Enables the SmartMIPS extension to the \s-1MIPS32\s0 instruction set. This is
-equivalent to putting \f(CW\*(C`.set smartmips\*(C'\fR at the start of the assembly file.
-\&\fB\-mno\-smartmips\fR turns off this option.
-.IP "\fB\-mips3d\fR" 4
-.IX Item "-mips3d"
-.PD 0
-.IP "\fB\-no\-mips3d\fR" 4
-.IX Item "-no-mips3d"
-.PD
-Generate code for the \s-1MIPS\-3D\s0 Application Specific Extension.
-This tells the assembler to accept \s-1MIPS\-3D\s0 instructions.
-\&\fB\-no\-mips3d\fR turns off this option.
-.IP "\fB\-mdmx\fR" 4
-.IX Item "-mdmx"
-.PD 0
-.IP "\fB\-no\-mdmx\fR" 4
-.IX Item "-no-mdmx"
-.PD
-Generate code for the \s-1MDMX\s0 Application Specific Extension.
-This tells the assembler to accept \s-1MDMX\s0 instructions.
-\&\fB\-no\-mdmx\fR turns off this option.
-.IP "\fB\-mdsp\fR" 4
-.IX Item "-mdsp"
-.PD 0
-.IP "\fB\-mno\-dsp\fR" 4
-.IX Item "-mno-dsp"
-.PD
-Generate code for the \s-1DSP\s0 Release 1 Application Specific Extension.
-This tells the assembler to accept \s-1DSP\s0 Release 1 instructions.
-\&\fB\-mno\-dsp\fR turns off this option.
-.IP "\fB\-mdspr2\fR" 4
-.IX Item "-mdspr2"
-.PD 0
-.IP "\fB\-mno\-dspr2\fR" 4
-.IX Item "-mno-dspr2"
-.PD
-Generate code for the \s-1DSP\s0 Release 2 Application Specific Extension.
-This option implies \-mdsp.
-This tells the assembler to accept \s-1DSP\s0 Release 2 instructions.
-\&\fB\-mno\-dspr2\fR turns off this option.
-.IP "\fB\-mmt\fR" 4
-.IX Item "-mmt"
-.PD 0
-.IP "\fB\-mno\-mt\fR" 4
-.IX Item "-mno-mt"
-.PD
-Generate code for the \s-1MT\s0 Application Specific Extension.
-This tells the assembler to accept \s-1MT\s0 instructions.
-\&\fB\-mno\-mt\fR turns off this option.
-.IP "\fB\-\-construct\-floats\fR" 4
-.IX Item "--construct-floats"
-.PD 0
-.IP "\fB\-\-no\-construct\-floats\fR" 4
-.IX Item "--no-construct-floats"
-.PD
-The \fB\-\-no\-construct\-floats\fR option disables the construction of
-double width floating point constants by loading the two halves of the
-value into the two single width floating point registers that make up
-the double width register. By default \fB\-\-construct\-floats\fR is
-selected, allowing construction of these floating point constants.
-.IP "\fB\-\-emulation=\fR\fIname\fR" 4
-.IX Item "--emulation=name"
-This option causes \fBas\fR to emulate \fBas\fR configured
-for some other target, in all respects, including output format (choosing
-between \s-1ELF\s0 and \s-1ECOFF\s0 only), handling of pseudo-opcodes which may generate
-debugging information or store symbol table information, and default
-endianness. The available configuration names are: \fBmipsecoff\fR,
-\&\fBmipself\fR, \fBmipslecoff\fR, \fBmipsbecoff\fR, \fBmipslelf\fR,
-\&\fBmipsbelf\fR. The first two do not alter the default endianness from that
-of the primary target for which the assembler was configured; the others change
-the default to little\- or big-endian as indicated by the \fBb\fR or \fBl\fR
-in the name. Using \fB\-EB\fR or \fB\-EL\fR will override the endianness
-selection in any case.
-.Sp
-This option is currently supported only when the primary target
-\&\fBas\fR is configured for is a \s-1MIPS\s0 \s-1ELF\s0 or \s-1ECOFF\s0 target.
-Furthermore, the primary target or others specified with
-\&\fB\-\-enable\-targets=...\fR at configuration time must include support for
-the other format, if both are to be available. For example, the Irix 5
-configuration includes support for both.
-.Sp
-Eventually, this option will support more configurations, with more
-fine-grained control over the assembler's behavior, and will be supported for
-more processors.
-.IP "\fB\-nocpp\fR" 4
-.IX Item "-nocpp"
-\&\fBas\fR ignores this option. It is accepted for compatibility with
-the native tools.
-.IP "\fB\-\-trap\fR" 4
-.IX Item "--trap"
-.PD 0
-.IP "\fB\-\-no\-trap\fR" 4
-.IX Item "--no-trap"
-.IP "\fB\-\-break\fR" 4
-.IX Item "--break"
-.IP "\fB\-\-no\-break\fR" 4
-.IX Item "--no-break"
-.PD
-Control how to deal with multiplication overflow and division by zero.
-\&\fB\-\-trap\fR or \fB\-\-no\-break\fR (which are synonyms) take a trap exception
-(and only work for Instruction Set Architecture level 2 and higher);
-\&\fB\-\-break\fR or \fB\-\-no\-trap\fR (also synonyms, and the default) take a
-break exception.
-.IP "\fB\-n\fR" 4
-.IX Item "-n"
-When this option is used, \fBas\fR will issue a warning every
-time it generates a nop instruction from a macro.
-.PP
-The following options are available when as is configured for
-an MCore processor.
-.IP "\fB\-jsri2bsr\fR" 4
-.IX Item "-jsri2bsr"
-.PD 0
-.IP "\fB\-nojsri2bsr\fR" 4
-.IX Item "-nojsri2bsr"
-.PD
-Enable or disable the \s-1JSRI\s0 to \s-1BSR\s0 transformation. By default this is enabled.
-The command line option \fB\-nojsri2bsr\fR can be used to disable it.
-.IP "\fB\-sifilter\fR" 4
-.IX Item "-sifilter"
-.PD 0
-.IP "\fB\-nosifilter\fR" 4
-.IX Item "-nosifilter"
-.PD
-Enable or disable the silicon filter behaviour. By default this is disabled.
-The default can be overridden by the \fB\-sifilter\fR command line option.
-.IP "\fB\-relax\fR" 4
-.IX Item "-relax"
-Alter jump instructions for long displacements.
-.IP "\fB\-mcpu=[210|340]\fR" 4
-.IX Item "-mcpu=[210|340]"
-Select the cpu type on the target hardware. This controls which instructions
-can be assembled.
-.IP "\fB\-EB\fR" 4
-.IX Item "-EB"
-Assemble for a big endian target.
-.IP "\fB\-EL\fR" 4
-.IX Item "-EL"
-Assemble for a little endian target.
-.PP
-See the info pages for documentation of the MMIX-specific options.
-.PP
-See the info pages for documentation of the RX-specific options.
-.PP
-The following options are available when as is configured for the s390
-processor family.
-.IP "\fB\-m31\fR" 4
-.IX Item "-m31"
-.PD 0
-.IP "\fB\-m64\fR" 4
-.IX Item "-m64"
-.PD
-Select the word size, either 31/32 bits or 64 bits.
-.IP "\fB\-mesa\fR" 4
-.IX Item "-mesa"
-.PD 0
-.IP "\fB\-mzarch\fR" 4
-.IX Item "-mzarch"
-.PD
-Select the architecture mode, either the Enterprise System
-Architecture (esa) or the z/Architecture mode (zarch).
-.IP "\fB\-march=\fR\fIprocessor\fR" 4
-.IX Item "-march=processor"
-Specify which s390 processor variant is the target, \fBg6\fR, \fBg6\fR,
-\&\fBz900\fR, \fBz990\fR, \fBz9\-109\fR, \fBz9\-ec\fR, or \fBz10\fR.
-.IP "\fB\-mregnames\fR" 4
-.IX Item "-mregnames"
-.PD 0
-.IP "\fB\-mno\-regnames\fR" 4
-.IX Item "-mno-regnames"
-.PD
-Allow or disallow symbolic names for registers.
-.IP "\fB\-mwarn\-areg\-zero\fR" 4
-.IX Item "-mwarn-areg-zero"
-Warn whenever the operand for a base or index register has been specified
-but evaluates to zero.
-.PP
-The following options are available when as is configured for a
-\&\s-1TMS320C6000\s0 processor.
-.IP "\fB\-march=\fR\fIarch\fR" 4
-.IX Item "-march=arch"
-Enable (only) instructions from architecture \fIarch\fR. By default,
-all instructions are permitted.
-.Sp
-The following values of \fIarch\fR are accepted: \f(CW\*(C`c62x\*(C'\fR,
-\&\f(CW\*(C`c64x\*(C'\fR, \f(CW\*(C`c64x+\*(C'\fR, \f(CW\*(C`c67x\*(C'\fR, \f(CW\*(C`c67x+\*(C'\fR, \f(CW\*(C`c674x\*(C'\fR.
-.IP "\fB\-matomic\fR" 4
-.IX Item "-matomic"
-.PD 0
-.IP "\fB\-mno\-atomic\fR" 4
-.IX Item "-mno-atomic"
-.PD
-Enable or disable the optional C64x+ atomic operation instructions.
-By default, they are enabled if no \fB\-march\fR option is given, or
-if an architecture is specified with \fB\-march\fR that implies
-these instructions are present (currently, there are no such
-architectures); they are disabled if an architecture is specified with
-\&\fB\-march\fR on which the instructions are optional or not
-present. This option overrides such a default from the architecture,
-independent of the order in which the \fB\-march\fR or
-\&\fB\-matomic\fR or \fB\-mno\-atomic\fR options are passed.
-.IP "\fB\-mdsbt\fR" 4
-.IX Item "-mdsbt"
-.PD 0
-.IP "\fB\-mno\-dsbt\fR" 4
-.IX Item "-mno-dsbt"
-.PD
-The \fB\-mdsbt\fR option causes the assembler to generate the
-\&\f(CW\*(C`Tag_ABI_DSBT\*(C'\fR attribute with a value of 1, indicating that the
-code is using \s-1DSBT\s0 addressing. The \fB\-mno\-dsbt\fR option, the
-default, causes the tag to have a value of 0, indicating that the code
-does not use \s-1DSBT\s0 addressing. The linker will emit a warning if
-objects of different type (\s-1DSBT\s0 and non-DSBT) are linked together.
-.IP "\fB\-mpid=no\fR" 4
-.IX Item "-mpid=no"
-.PD 0
-.IP "\fB\-mpid=near\fR" 4
-.IX Item "-mpid=near"
-.IP "\fB\-mpid=far\fR" 4
-.IX Item "-mpid=far"
-.PD
-The \fB\-mpid=\fR option causes the assembler to generate the
-\&\f(CW\*(C`Tag_ABI_PID\*(C'\fR attribute with a value indicating the form of data
-addressing used by the code. \fB\-mpid=no\fR, the default,
-indicates position-dependent data addressing, \fB\-mpid=near\fR
-indicates position-independent addressing with \s-1GOT\s0 accesses using near
-\&\s-1DP\s0 addressing, and \fB\-mpid=far\fR indicates position-independent
-addressing with \s-1GOT\s0 accesses using far \s-1DP\s0 addressing. The linker will
-emit a warning if objects built with different settings of this option
-are linked together.
-.IP "\fB\-mpic\fR" 4
-.IX Item "-mpic"
-.PD 0
-.IP "\fB\-mno\-pic\fR" 4
-.IX Item "-mno-pic"
-.PD
-The \fB\-mpic\fR option causes the assembler to generate the
-\&\f(CW\*(C`Tag_ABI_PIC\*(C'\fR attribute with a value of 1, indicating that the
-code is using position-independent code addressing, The
-\&\f(CW\*(C`\-mno\-pic\*(C'\fR option, the default, causes the tag to have a value of
-0, indicating position-dependent code addressing. The linker will
-emit a warning if objects of different type (position-dependent and
-position-independent) are linked together.
-.IP "\fB\-mbig\-endian\fR" 4
-.IX Item "-mbig-endian"
-.PD 0
-.IP "\fB\-mlittle\-endian\fR" 4
-.IX Item "-mlittle-endian"
-.PD
-Generate code for the specified endianness. The default is
-little-endian.
-.PP
-The following options are available when as is configured for
-an Xtensa processor.
-.IP "\fB\-\-text\-section\-literals | \-\-no\-text\-section\-literals\fR" 4
-.IX Item "--text-section-literals | --no-text-section-literals"
-With \fB\-\-text\-section\-literals\fR, literal pools are interspersed
-in the text section. The default is
-\&\fB\-\-no\-text\-section\-literals\fR, which places literals in a
-separate section in the output file. These options only affect literals
-referenced via PC-relative \f(CW\*(C`L32R\*(C'\fR instructions; literals for
-absolute mode \f(CW\*(C`L32R\*(C'\fR instructions are handled separately.
-.IP "\fB\-\-absolute\-literals | \-\-no\-absolute\-literals\fR" 4
-.IX Item "--absolute-literals | --no-absolute-literals"
-Indicate to the assembler whether \f(CW\*(C`L32R\*(C'\fR instructions use absolute
-or PC-relative addressing. The default is to assume absolute addressing
-if the Xtensa processor includes the absolute \f(CW\*(C`L32R\*(C'\fR addressing
-option. Otherwise, only the PC-relative \f(CW\*(C`L32R\*(C'\fR mode can be used.
-.IP "\fB\-\-target\-align | \-\-no\-target\-align\fR" 4
-.IX Item "--target-align | --no-target-align"
-Enable or disable automatic alignment to reduce branch penalties at the
-expense of some code density. The default is \fB\-\-target\-align\fR.
-.IP "\fB\-\-longcalls | \-\-no\-longcalls\fR" 4
-.IX Item "--longcalls | --no-longcalls"
-Enable or disable transformation of call instructions to allow calls
-across a greater range of addresses. The default is
-\&\fB\-\-no\-longcalls\fR.
-.IP "\fB\-\-transform | \-\-no\-transform\fR" 4
-.IX Item "--transform | --no-transform"
-Enable or disable all assembler transformations of Xtensa instructions.
-The default is \fB\-\-transform\fR;
-\&\fB\-\-no\-transform\fR should be used only in the rare cases when the
-instructions must be exactly as specified in the assembly source.
-.IP "\fB\-\-rename\-section\fR \fIoldname\fR\fB=\fR\fInewname\fR" 4
-.IX Item "--rename-section oldname=newname"
-When generating output sections, rename the \fIoldname\fR section to
-\&\fInewname\fR.
-.PP
-The following options are available when as is configured for
-a Z80 family processor.
-.IP "\fB\-z80\fR" 4
-.IX Item "-z80"
-Assemble for Z80 processor.
-.IP "\fB\-r800\fR" 4
-.IX Item "-r800"
-Assemble for R800 processor.
-.IP "\fB\-ignore\-undocumented\-instructions\fR" 4
-.IX Item "-ignore-undocumented-instructions"
-.PD 0
-.IP "\fB\-Wnud\fR" 4
-.IX Item "-Wnud"
-.PD
-Assemble undocumented Z80 instructions that also work on R800 without warning.
-.IP "\fB\-ignore\-unportable\-instructions\fR" 4
-.IX Item "-ignore-unportable-instructions"
-.PD 0
-.IP "\fB\-Wnup\fR" 4
-.IX Item "-Wnup"
-.PD
-Assemble all undocumented Z80 instructions without warning.
-.IP "\fB\-warn\-undocumented\-instructions\fR" 4
-.IX Item "-warn-undocumented-instructions"
-.PD 0
-.IP "\fB\-Wud\fR" 4
-.IX Item "-Wud"
-.PD
-Issue a warning for undocumented Z80 instructions that also work on R800.
-.IP "\fB\-warn\-unportable\-instructions\fR" 4
-.IX Item "-warn-unportable-instructions"
-.PD 0
-.IP "\fB\-Wup\fR" 4
-.IX Item "-Wup"
-.PD
-Issue a warning for undocumented Z80 instructions that do not work on R800.
-.IP "\fB\-forbid\-undocumented\-instructions\fR" 4
-.IX Item "-forbid-undocumented-instructions"
-.PD 0
-.IP "\fB\-Fud\fR" 4
-.IX Item "-Fud"
-.PD
-Treat all undocumented instructions as errors.
-.IP "\fB\-forbid\-unportable\-instructions\fR" 4
-.IX Item "-forbid-unportable-instructions"
-.PD 0
-.IP "\fB\-Fup\fR" 4
-.IX Item "-Fup"
-.PD
-Treat undocumented Z80 instructions that do not work on R800 as errors.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIgcc\fR\|(1), \fIld\fR\|(1), and the Info entries for \fIbinutils\fR and \fIld\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-c++filt.1 b/share/man/man1/arm-eabi-c++filt.1
deleted file mode 100644
index c228449..0000000
--- a/share/man/man1/arm-eabi-c++filt.1
+++ /dev/null
@@ -1,346 +0,0 @@
-.\" Automatically generated by Pod::Man 2.16 (Pod::Simple 3.05)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sh \" Subsection heading
-.br
-.if t .Sp
-.ne 5
-.PP
-\fB\\$1\fR
-.PP
-..
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "C++FILT 1"
-.TH C++FILT 1 "2010-12-08" "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-c++filt \- Demangle C++ and Java symbols.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-c++filt [\fB\-_\fR|\fB\-\-strip\-underscores\fR]
- [\fB\-n\fR|\fB\-\-no\-strip\-underscores\fR]
- [\fB\-p\fR|\fB\-\-no\-params\fR]
- [\fB\-t\fR|\fB\-\-types\fR]
- [\fB\-i\fR|\fB\-\-no\-verbose\fR]
- [\fB\-s\fR \fIformat\fR|\fB\-\-format=\fR\fIformat\fR]
- [\fB\-\-help\fR] [\fB\-\-version\fR] [\fIsymbol\fR...]
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-The \*(C+ and Java languages provide function overloading, which means
-that you can write many functions with the same name, providing that
-each function takes parameters of different types. In order to be
-able to distinguish these similarly named functions \*(C+ and Java
-encode them into a low-level assembler name which uniquely identifies
-each different version. This process is known as \fImangling\fR. The
-\&\fBc++filt\fR
-[1]
-program does the inverse mapping: it decodes (\fIdemangles\fR) low-level
-names into user-level names so that they can be read.
-.PP
-Every alphanumeric word (consisting of letters, digits, underscores,
-dollars, or periods) seen in the input is a potential mangled name.
-If the name decodes into a \*(C+ name, the \*(C+ name replaces the
-low-level name in the output, otherwise the original word is output.
-In this way you can pass an entire assembler source file, containing
-mangled names, through \fBc++filt\fR and see the same source file
-containing demangled names.
-.PP
-You can also use \fBc++filt\fR to decipher individual symbols by
-passing them on the command line:
-.PP
-.Vb 1
-\& c++filt <symbol>
-.Ve
-.PP
-If no \fIsymbol\fR arguments are given, \fBc++filt\fR reads symbol
-names from the standard input instead. All the results are printed on
-the standard output. The difference between reading names from the
-command line versus reading names from the standard input is that
-command line arguments are expected to be just mangled names and no
-checking is performed to separate them from surrounding text. Thus
-for example:
-.PP
-.Vb 1
-\& c++filt \-n _Z1fv
-.Ve
-.PP
-will work and demangle the name to \*(L"f()\*(R" whereas:
-.PP
-.Vb 1
-\& c++filt \-n _Z1fv,
-.Ve
-.PP
-will not work. (Note the extra comma at the end of the mangled
-name which makes it invalid). This command however will work:
-.PP
-.Vb 1
-\& echo _Z1fv, | c++filt \-n
-.Ve
-.PP
-and will display \*(L"f(),\*(R", i.e., the demangled name followed by a
-trailing comma. This behaviour is because when the names are read
-from the standard input it is expected that they might be part of an
-assembler source file where there might be extra, extraneous
-characters trailing after a mangled name. For example:
-.PP
-.Vb 1
-\& .type _Z1fv, @function
-.Ve
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.IP "\fB\-_\fR" 4
-.IX Item "-_"
-.PD 0
-.IP "\fB\-\-strip\-underscores\fR" 4
-.IX Item "--strip-underscores"
-.PD
-On some systems, both the C and \*(C+ compilers put an underscore in front
-of every name. For example, the C name \f(CW\*(C`foo\*(C'\fR gets the low-level
-name \f(CW\*(C`_foo\*(C'\fR. This option removes the initial underscore. Whether
-\&\fBc++filt\fR removes the underscore by default is target dependent.
-.IP "\fB\-n\fR" 4
-.IX Item "-n"
-.PD 0
-.IP "\fB\-\-no\-strip\-underscores\fR" 4
-.IX Item "--no-strip-underscores"
-.PD
-Do not remove the initial underscore.
-.IP "\fB\-p\fR" 4
-.IX Item "-p"
-.PD 0
-.IP "\fB\-\-no\-params\fR" 4
-.IX Item "--no-params"
-.PD
-When demangling the name of a function, do not display the types of
-the function's parameters.
-.IP "\fB\-t\fR" 4
-.IX Item "-t"
-.PD 0
-.IP "\fB\-\-types\fR" 4
-.IX Item "--types"
-.PD
-Attempt to demangle types as well as function names. This is disabled
-by default since mangled types are normally only used internally in
-the compiler, and they can be confused with non-mangled names. For example,
-a function called \*(L"a\*(R" treated as a mangled type name would be
-demangled to \*(L"signed char\*(R".
-.IP "\fB\-i\fR" 4
-.IX Item "-i"
-.PD 0
-.IP "\fB\-\-no\-verbose\fR" 4
-.IX Item "--no-verbose"
-.PD
-Do not include implementation details (if any) in the demangled
-output.
-.IP "\fB\-s\fR \fIformat\fR" 4
-.IX Item "-s format"
-.PD 0
-.IP "\fB\-\-format=\fR\fIformat\fR" 4
-.IX Item "--format=format"
-.PD
-\&\fBc++filt\fR can decode various methods of mangling, used by
-different compilers. The argument to this option selects which
-method it uses:
-.RS 4
-.ie n .IP """auto""" 4
-.el .IP "\f(CWauto\fR" 4
-.IX Item "auto"
-Automatic selection based on executable (the default method)
-.ie n .IP """gnu""" 4
-.el .IP "\f(CWgnu\fR" 4
-.IX Item "gnu"
-the one used by the \s-1GNU\s0 \*(C+ compiler (g++)
-.ie n .IP """lucid""" 4
-.el .IP "\f(CWlucid\fR" 4
-.IX Item "lucid"
-the one used by the Lucid compiler (lcc)
-.ie n .IP """arm""" 4
-.el .IP "\f(CWarm\fR" 4
-.IX Item "arm"
-the one specified by the \*(C+ Annotated Reference Manual
-.ie n .IP """hp""" 4
-.el .IP "\f(CWhp\fR" 4
-.IX Item "hp"
-the one used by the \s-1HP\s0 compiler (aCC)
-.ie n .IP """edg""" 4
-.el .IP "\f(CWedg\fR" 4
-.IX Item "edg"
-the one used by the \s-1EDG\s0 compiler
-.ie n .IP """gnu\-v3""" 4
-.el .IP "\f(CWgnu\-v3\fR" 4
-.IX Item "gnu-v3"
-the one used by the \s-1GNU\s0 \*(C+ compiler (g++) with the V3 \s-1ABI\s0.
-.ie n .IP """java""" 4
-.el .IP "\f(CWjava\fR" 4
-.IX Item "java"
-the one used by the \s-1GNU\s0 Java compiler (gcj)
-.ie n .IP """gnat""" 4
-.el .IP "\f(CWgnat\fR" 4
-.IX Item "gnat"
-the one used by the \s-1GNU\s0 Ada compiler (\s-1GNAT\s0).
-.RE
-.RS 4
-.RE
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-Print a summary of the options to \fBc++filt\fR and exit.
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-Print the version number of \fBc++filt\fR and exit.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "FOOTNOTES"
-.IX Header "FOOTNOTES"
-.IP "1." 4
-MS-DOS does not allow \f(CW\*(C`+\*(C'\fR characters in file names, so on
-MS-DOS this program is named \fB\s-1CXXFILT\s0\fR.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-cpp.1 b/share/man/man1/arm-eabi-cpp.1
deleted file mode 100644
index 41af757..0000000
--- a/share/man/man1/arm-eabi-cpp.1
+++ /dev/null
@@ -1,992 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "CPP 1"
-.TH CPP 1 "2012-01-06" "gcc-4.6.x-google" "GNU"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-cpp \- The C Preprocessor
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-cpp [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
- [\fB\-I\fR\fIdir\fR...] [\fB\-iquote\fR\fIdir\fR...]
- [\fB\-W\fR\fIwarn\fR...]
- [\fB\-M\fR|\fB\-MM\fR] [\fB\-MG\fR] [\fB\-MF\fR \fIfilename\fR]
- [\fB\-MP\fR] [\fB\-MQ\fR \fItarget\fR...]
- [\fB\-MT\fR \fItarget\fR...]
- [\fB\-P\fR] [\fB\-fno\-working\-directory\fR]
- [\fB\-x\fR \fIlanguage\fR] [\fB\-std=\fR\fIstandard\fR]
- \fIinfile\fR \fIoutfile\fR
-.PP
-Only the most useful options are listed here; see below for the remainder.
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-The C preprocessor, often known as \fIcpp\fR, is a \fImacro processor\fR
-that is used automatically by the C compiler to transform your program
-before compilation. It is called a macro processor because it allows
-you to define \fImacros\fR, which are brief abbreviations for longer
-constructs.
-.PP
-The C preprocessor is intended to be used only with C, \*(C+, and
-Objective-C source code. In the past, it has been abused as a general
-text processor. It will choke on input which does not obey C's lexical
-rules. For example, apostrophes will be interpreted as the beginning of
-character constants, and cause errors. Also, you cannot rely on it
-preserving characteristics of the input which are not significant to
-C\-family languages. If a Makefile is preprocessed, all the hard tabs
-will be removed, and the Makefile will not work.
-.PP
-Having said that, you can often get away with using cpp on things which
-are not C. Other Algol-ish programming languages are often safe
-(Pascal, Ada, etc.) So is assembly, with caution. \fB\-traditional\-cpp\fR
-mode preserves more white space, and is otherwise more permissive. Many
-of the problems can be avoided by writing C or \*(C+ style comments
-instead of native language comments, and keeping macros simple.
-.PP
-Wherever possible, you should use a preprocessor geared to the language
-you are writing in. Modern versions of the \s-1GNU\s0 assembler have macro
-facilities. Most high level programming languages have their own
-conditional compilation and inclusion mechanism. If all else fails,
-try a true general text processor, such as \s-1GNU\s0 M4.
-.PP
-C preprocessors vary in some details. This manual discusses the \s-1GNU\s0 C
-preprocessor, which provides a small superset of the features of \s-1ISO\s0
-Standard C. In its default mode, the \s-1GNU\s0 C preprocessor does not do a
-few things required by the standard. These are features which are
-rarely, if ever, used, and may cause surprising changes to the meaning
-of a program which does not expect them. To get strict \s-1ISO\s0 Standard C,
-you should use the \fB\-std=c90\fR, \fB\-std=c99\fR or
-\&\fB\-std=c1x\fR options, depending
-on which version of the standard you want. To get all the mandatory
-diagnostics, you must also use \fB\-pedantic\fR.
-.PP
-This manual describes the behavior of the \s-1ISO\s0 preprocessor. To
-minimize gratuitous differences, where the \s-1ISO\s0 preprocessor's
-behavior does not conflict with traditional semantics, the
-traditional preprocessor should behave the same way. The various
-differences that do exist are detailed in the section \fBTraditional
-Mode\fR.
-.PP
-For clarity, unless noted otherwise, references to \fB\s-1CPP\s0\fR in this
-manual refer to \s-1GNU\s0 \s-1CPP\s0.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-The C preprocessor expects two file names as arguments, \fIinfile\fR and
-\&\fIoutfile\fR. The preprocessor reads \fIinfile\fR together with any
-other files it specifies with \fB#include\fR. All the output generated
-by the combined input files is written in \fIoutfile\fR.
-.PP
-Either \fIinfile\fR or \fIoutfile\fR may be \fB\-\fR, which as
-\&\fIinfile\fR means to read from standard input and as \fIoutfile\fR
-means to write to standard output. Also, if either file is omitted, it
-means the same as if \fB\-\fR had been specified for that file.
-.PP
-Unless otherwise noted, or the option ends in \fB=\fR, all options
-which take an argument may have that argument appear either immediately
-after the option, or with a space between option and argument:
-\&\fB\-Ifoo\fR and \fB\-I foo\fR have the same effect.
-.PP
-Many options have multi-letter names; therefore multiple single-letter
-options may \fInot\fR be grouped: \fB\-dM\fR is very different from
-\&\fB\-d\ \-M\fR.
-.IP "\fB\-D\fR \fIname\fR" 4
-.IX Item "-D name"
-Predefine \fIname\fR as a macro, with definition \f(CW1\fR.
-.IP "\fB\-D\fR \fIname\fR\fB=\fR\fIdefinition\fR" 4
-.IX Item "-D name=definition"
-The contents of \fIdefinition\fR are tokenized and processed as if
-they appeared during translation phase three in a \fB#define\fR
-directive. In particular, the definition will be truncated by
-embedded newline characters.
-.Sp
-If you are invoking the preprocessor from a shell or shell-like
-program you may need to use the shell's quoting syntax to protect
-characters such as spaces that have a meaning in the shell syntax.
-.Sp
-If you wish to define a function-like macro on the command line, write
-its argument list with surrounding parentheses before the equals sign
-(if any). Parentheses are meaningful to most shells, so you will need
-to quote the option. With \fBsh\fR and \fBcsh\fR,
-\&\fB\-D'\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB'\fR works.
-.Sp
-\&\fB\-D\fR and \fB\-U\fR options are processed in the order they
-are given on the command line. All \fB\-imacros\fR \fIfile\fR and
-\&\fB\-include\fR \fIfile\fR options are processed after all
-\&\fB\-D\fR and \fB\-U\fR options.
-.IP "\fB\-U\fR \fIname\fR" 4
-.IX Item "-U name"
-Cancel any previous definition of \fIname\fR, either built in or
-provided with a \fB\-D\fR option.
-.IP "\fB\-undef\fR" 4
-.IX Item "-undef"
-Do not predefine any system-specific or GCC-specific macros. The
-standard predefined macros remain defined.
-.IP "\fB\-I\fR \fIdir\fR" 4
-.IX Item "-I dir"
-Add the directory \fIdir\fR to the list of directories to be searched
-for header files.
-.Sp
-Directories named by \fB\-I\fR are searched before the standard
-system include directories. If the directory \fIdir\fR is a standard
-system include directory, the option is ignored to ensure that the
-default search order for system directories and the special treatment
-of system headers are not defeated
-\&.
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-o\fR \fIfile\fR" 4
-.IX Item "-o file"
-Write output to \fIfile\fR. This is the same as specifying \fIfile\fR
-as the second non-option argument to \fBcpp\fR. \fBgcc\fR has a
-different interpretation of a second non-option argument, so you must
-use \fB\-o\fR to specify the output file.
-.IP "\fB\-Wall\fR" 4
-.IX Item "-Wall"
-Turns on all optional warnings which are desirable for normal code.
-At present this is \fB\-Wcomment\fR, \fB\-Wtrigraphs\fR,
-\&\fB\-Wmultichar\fR and a warning about integer promotion causing a
-change of sign in \f(CW\*(C`#if\*(C'\fR expressions. Note that many of the
-preprocessor's warnings are on by default and have no options to
-control them.
-.IP "\fB\-Wcomment\fR" 4
-.IX Item "-Wcomment"
-.PD 0
-.IP "\fB\-Wcomments\fR" 4
-.IX Item "-Wcomments"
-.PD
-Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
-comment, or whenever a backslash-newline appears in a \fB//\fR comment.
-(Both forms have the same effect.)
-.IP "\fB\-Wtrigraphs\fR" 4
-.IX Item "-Wtrigraphs"
-Most trigraphs in comments cannot affect the meaning of the program.
-However, a trigraph that would form an escaped newline (\fB??/\fR at
-the end of a line) can, by changing where the comment begins or ends.
-Therefore, only trigraphs that would form escaped newlines produce
-warnings inside a comment.
-.Sp
-This option is implied by \fB\-Wall\fR. If \fB\-Wall\fR is not
-given, this option is still enabled unless trigraphs are enabled. To
-get trigraph conversion without warnings, but get the other
-\&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
-.IP "\fB\-Wtraditional\fR" 4
-.IX Item "-Wtraditional"
-Warn about certain constructs that behave differently in traditional and
-\&\s-1ISO\s0 C. Also warn about \s-1ISO\s0 C constructs that have no traditional C
-equivalent, and problematic constructs which should be avoided.
-.IP "\fB\-Wundef\fR" 4
-.IX Item "-Wundef"
-Warn whenever an identifier which is not a macro is encountered in an
-\&\fB#if\fR directive, outside of \fBdefined\fR. Such identifiers are
-replaced with zero.
-.IP "\fB\-Wunused\-macros\fR" 4
-.IX Item "-Wunused-macros"
-Warn about macros defined in the main file that are unused. A macro
-is \fIused\fR if it is expanded or tested for existence at least once.
-The preprocessor will also warn if the macro has not been used at the
-time it is redefined or undefined.
-.Sp
-Built-in macros, macros defined on the command line, and macros
-defined in include files are not warned about.
-.Sp
-\&\fINote:\fR If a macro is actually used, but only used in skipped
-conditional blocks, then \s-1CPP\s0 will report it as unused. To avoid the
-warning in such a case, you might improve the scope of the macro's
-definition by, for example, moving it into the first skipped block.
-Alternatively, you could provide a dummy use with something like:
-.Sp
-.Vb 2
-\& #if defined the_macro_causing_the_warning
-\& #endif
-.Ve
-.IP "\fB\-Wendif\-labels\fR" 4
-.IX Item "-Wendif-labels"
-Warn whenever an \fB#else\fR or an \fB#endif\fR are followed by text.
-This usually happens in code of the form
-.Sp
-.Vb 5
-\& #if FOO
-\& ...
-\& #else FOO
-\& ...
-\& #endif FOO
-.Ve
-.Sp
-The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments, but often are not
-in older programs. This warning is on by default.
-.IP "\fB\-Werror\fR" 4
-.IX Item "-Werror"
-Make all warnings into hard errors. Source code which triggers warnings
-will be rejected.
-.IP "\fB\-Wsystem\-headers\fR" 4
-.IX Item "-Wsystem-headers"
-Issue warnings for code in system headers. These are normally unhelpful
-in finding bugs in your own code, therefore suppressed. If you are
-responsible for the system library, you may want to see them.
-.IP "\fB\-w\fR" 4
-.IX Item "-w"
-Suppress all warnings, including those which \s-1GNU\s0 \s-1CPP\s0 issues by default.
-.IP "\fB\-pedantic\fR" 4
-.IX Item "-pedantic"
-Issue all the mandatory diagnostics listed in the C standard. Some of
-them are left out by default, since they trigger frequently on harmless
-code.
-.IP "\fB\-pedantic\-errors\fR" 4
-.IX Item "-pedantic-errors"
-Issue all the mandatory diagnostics, and make all mandatory diagnostics
-into errors. This includes mandatory diagnostics that \s-1GCC\s0 issues
-without \fB\-pedantic\fR but treats as warnings.
-.IP "\fB\-M\fR" 4
-.IX Item "-M"
-Instead of outputting the result of preprocessing, output a rule
-suitable for \fBmake\fR describing the dependencies of the main
-source file. The preprocessor outputs one \fBmake\fR rule containing
-the object file name for that source file, a colon, and the names of all
-the included files, including those coming from \fB\-include\fR or
-\&\fB\-imacros\fR command line options.
-.Sp
-Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
-object file name consists of the name of the source file with any
-suffix replaced with object file suffix and with any leading directory
-parts removed. If there are many included files then the rule is
-split into several lines using \fB\e\fR\-newline. The rule has no
-commands.
-.Sp
-This option does not suppress the preprocessor's debug output, such as
-\&\fB\-dM\fR. To avoid mixing such debug output with the dependency
-rules you should explicitly specify the dependency output file with
-\&\fB\-MF\fR, or use an environment variable like
-\&\fB\s-1DEPENDENCIES_OUTPUT\s0\fR. Debug output
-will still be sent to the regular output stream as normal.
-.Sp
-Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
-warnings with an implicit \fB\-w\fR.
-.IP "\fB\-MM\fR" 4
-.IX Item "-MM"
-Like \fB\-M\fR but do not mention header files that are found in
-system header directories, nor header files that are included,
-directly or indirectly, from such a header.
-.Sp
-This implies that the choice of angle brackets or double quotes in an
-\&\fB#include\fR directive does not in itself determine whether that
-header will appear in \fB\-MM\fR dependency output. This is a
-slight change in semantics from \s-1GCC\s0 versions 3.0 and earlier.
-.IP "\fB\-MF\fR \fIfile\fR" 4
-.IX Item "-MF file"
-When used with \fB\-M\fR or \fB\-MM\fR, specifies a
-file to write the dependencies to. If no \fB\-MF\fR switch is given
-the preprocessor sends the rules to the same place it would have sent
-preprocessed output.
-.Sp
-When used with the driver options \fB\-MD\fR or \fB\-MMD\fR,
-\&\fB\-MF\fR overrides the default dependency output file.
-.IP "\fB\-MG\fR" 4
-.IX Item "-MG"
-In conjunction with an option such as \fB\-M\fR requesting
-dependency generation, \fB\-MG\fR assumes missing header files are
-generated files and adds them to the dependency list without raising
-an error. The dependency filename is taken directly from the
-\&\f(CW\*(C`#include\*(C'\fR directive without prepending any path. \fB\-MG\fR
-also suppresses preprocessed output, as a missing header file renders
-this useless.
-.Sp
-This feature is used in automatic updating of makefiles.
-.IP "\fB\-MP\fR" 4
-.IX Item "-MP"
-This option instructs \s-1CPP\s0 to add a phony target for each dependency
-other than the main file, causing each to depend on nothing. These
-dummy rules work around errors \fBmake\fR gives if you remove header
-files without updating the \fIMakefile\fR to match.
-.Sp
-This is typical output:
-.Sp
-.Vb 1
-\& test.o: test.c test.h
-\&
-\& test.h:
-.Ve
-.IP "\fB\-MT\fR \fItarget\fR" 4
-.IX Item "-MT target"
-Change the target of the rule emitted by dependency generation. By
-default \s-1CPP\s0 takes the name of the main input file, deletes any
-directory components and any file suffix such as \fB.c\fR, and
-appends the platform's usual object suffix. The result is the target.
-.Sp
-An \fB\-MT\fR option will set the target to be exactly the string you
-specify. If you want multiple targets, you can specify them as a single
-argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
-.Sp
-For example, \fB\-MT\ '$(objpfx)foo.o'\fR might give
-.Sp
-.Vb 1
-\& $(objpfx)foo.o: foo.c
-.Ve
-.IP "\fB\-MQ\fR \fItarget\fR" 4
-.IX Item "-MQ target"
-Same as \fB\-MT\fR, but it quotes any characters which are special to
-Make. \fB\-MQ\ '$(objpfx)foo.o'\fR gives
-.Sp
-.Vb 1
-\& $$(objpfx)foo.o: foo.c
-.Ve
-.Sp
-The default target is automatically quoted, as if it were given with
-\&\fB\-MQ\fR.
-.IP "\fB\-MD\fR" 4
-.IX Item "-MD"
-\&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
-\&\fB\-E\fR is not implied. The driver determines \fIfile\fR based on
-whether an \fB\-o\fR option is given. If it is, the driver uses its
-argument but with a suffix of \fI.d\fR, otherwise it takes the name
-of the input file, removes any directory components and suffix, and
-applies a \fI.d\fR suffix.
-.Sp
-If \fB\-MD\fR is used in conjunction with \fB\-E\fR, any
-\&\fB\-o\fR switch is understood to specify the dependency output file, but if used without \fB\-E\fR, each \fB\-o\fR
-is understood to specify a target object file.
-.Sp
-Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
-a dependency output file as a side-effect of the compilation process.
-.IP "\fB\-MMD\fR" 4
-.IX Item "-MMD"
-Like \fB\-MD\fR except mention only user header files, not system
-header files.
-.IP "\fB\-x c\fR" 4
-.IX Item "-x c"
-.PD 0
-.IP "\fB\-x c++\fR" 4
-.IX Item "-x c++"
-.IP "\fB\-x objective-c\fR" 4
-.IX Item "-x objective-c"
-.IP "\fB\-x assembler-with-cpp\fR" 4
-.IX Item "-x assembler-with-cpp"
-.PD
-Specify the source language: C, \*(C+, Objective-C, or assembly. This has
-nothing to do with standards conformance or extensions; it merely
-selects which base syntax to expect. If you give none of these options,
-cpp will deduce the language from the extension of the source file:
-\&\fB.c\fR, \fB.cc\fR, \fB.m\fR, or \fB.S\fR. Some other common
-extensions for \*(C+ and assembly are also recognized. If cpp does not
-recognize the extension, it will treat the file as C; this is the most
-generic mode.
-.Sp
-\&\fINote:\fR Previous versions of cpp accepted a \fB\-lang\fR option
-which selected both the language and the standards conformance level.
-This option has been removed, because it conflicts with the \fB\-l\fR
-option.
-.IP "\fB\-std=\fR\fIstandard\fR" 4
-.IX Item "-std=standard"
-.PD 0
-.IP "\fB\-ansi\fR" 4
-.IX Item "-ansi"
-.PD
-Specify the standard to which the code should conform. Currently \s-1CPP\s0
-knows about C and \*(C+ standards; others may be added in the future.
-.Sp
-\&\fIstandard\fR
-may be one of:
-.RS 4
-.ie n .IP """c90""" 4
-.el .IP "\f(CWc90\fR" 4
-.IX Item "c90"
-.PD 0
-.ie n .IP """c89""" 4
-.el .IP "\f(CWc89\fR" 4
-.IX Item "c89"
-.ie n .IP """iso9899:1990""" 4
-.el .IP "\f(CWiso9899:1990\fR" 4
-.IX Item "iso9899:1990"
-.PD
-The \s-1ISO\s0 C standard from 1990. \fBc90\fR is the customary shorthand for
-this version of the standard.
-.Sp
-The \fB\-ansi\fR option is equivalent to \fB\-std=c90\fR.
-.ie n .IP """iso9899:199409""" 4
-.el .IP "\f(CWiso9899:199409\fR" 4
-.IX Item "iso9899:199409"
-The 1990 C standard, as amended in 1994.
-.ie n .IP """iso9899:1999""" 4
-.el .IP "\f(CWiso9899:1999\fR" 4
-.IX Item "iso9899:1999"
-.PD 0
-.ie n .IP """c99""" 4
-.el .IP "\f(CWc99\fR" 4
-.IX Item "c99"
-.ie n .IP """iso9899:199x""" 4
-.el .IP "\f(CWiso9899:199x\fR" 4
-.IX Item "iso9899:199x"
-.ie n .IP """c9x""" 4
-.el .IP "\f(CWc9x\fR" 4
-.IX Item "c9x"
-.PD
-The revised \s-1ISO\s0 C standard, published in December 1999. Before
-publication, this was known as C9X.
-.ie n .IP """c1x""" 4
-.el .IP "\f(CWc1x\fR" 4
-.IX Item "c1x"
-The next version of the \s-1ISO\s0 C standard, still under development.
-.ie n .IP """gnu90""" 4
-.el .IP "\f(CWgnu90\fR" 4
-.IX Item "gnu90"
-.PD 0
-.ie n .IP """gnu89""" 4
-.el .IP "\f(CWgnu89\fR" 4
-.IX Item "gnu89"
-.PD
-The 1990 C standard plus \s-1GNU\s0 extensions. This is the default.
-.ie n .IP """gnu99""" 4
-.el .IP "\f(CWgnu99\fR" 4
-.IX Item "gnu99"
-.PD 0
-.ie n .IP """gnu9x""" 4
-.el .IP "\f(CWgnu9x\fR" 4
-.IX Item "gnu9x"
-.PD
-The 1999 C standard plus \s-1GNU\s0 extensions.
-.ie n .IP """gnu1x""" 4
-.el .IP "\f(CWgnu1x\fR" 4
-.IX Item "gnu1x"
-The next version of the \s-1ISO\s0 C standard, still under development, plus
-\&\s-1GNU\s0 extensions.
-.ie n .IP """c++98""" 4
-.el .IP "\f(CWc++98\fR" 4
-.IX Item "c++98"
-The 1998 \s-1ISO\s0 \*(C+ standard plus amendments.
-.ie n .IP """gnu++98""" 4
-.el .IP "\f(CWgnu++98\fR" 4
-.IX Item "gnu++98"
-The same as \fB\-std=c++98\fR plus \s-1GNU\s0 extensions. This is the
-default for \*(C+ code.
-.RE
-.RS 4
-.RE
-.IP "\fB\-I\-\fR" 4
-.IX Item "-I-"
-Split the include path. Any directories specified with \fB\-I\fR
-options before \fB\-I\-\fR are searched only for headers requested with
-\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
-\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR. If additional directories are
-specified with \fB\-I\fR options after the \fB\-I\-\fR, those
-directories are searched for all \fB#include\fR directives.
-.Sp
-In addition, \fB\-I\-\fR inhibits the use of the directory of the current
-file directory as the first search directory for \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.
-.Sp
-This option has been deprecated.
-.IP "\fB\-nostdinc\fR" 4
-.IX Item "-nostdinc"
-Do not search the standard system directories for header files.
-Only the directories you have specified with \fB\-I\fR options
-(and the directory of the current file, if appropriate) are searched.
-.IP "\fB\-nostdinc++\fR" 4
-.IX Item "-nostdinc++"
-Do not search for header files in the \*(C+\-specific standard directories,
-but do still search the other standard directories. (This option is
-used when building the \*(C+ library.)
-.IP "\fB\-include\fR \fIfile\fR" 4
-.IX Item "-include file"
-Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
-line of the primary source file. However, the first directory searched
-for \fIfile\fR is the preprocessor's working directory \fIinstead of\fR
-the directory containing the main source file. If not found there, it
-is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
-chain as normal.
-.Sp
-If multiple \fB\-include\fR options are given, the files are included
-in the order they appear on the command line.
-.IP "\fB\-imacros\fR \fIfile\fR" 4
-.IX Item "-imacros file"
-Exactly like \fB\-include\fR, except that any output produced by
-scanning \fIfile\fR is thrown away. Macros it defines remain defined.
-This allows you to acquire all the macros from a header without also
-processing its declarations.
-.Sp
-All files specified by \fB\-imacros\fR are processed before all files
-specified by \fB\-include\fR.
-.IP "\fB\-idirafter\fR \fIdir\fR" 4
-.IX Item "-idirafter dir"
-Search \fIdir\fR for header files, but do it \fIafter\fR all
-directories specified with \fB\-I\fR and the standard system directories
-have been exhausted. \fIdir\fR is treated as a system include directory.
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-iprefix\fR \fIprefix\fR" 4
-.IX Item "-iprefix prefix"
-Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
-options. If the prefix represents a directory, you should include the
-final \fB/\fR.
-.IP "\fB\-iwithprefix\fR \fIdir\fR" 4
-.IX Item "-iwithprefix dir"
-.PD 0
-.IP "\fB\-iwithprefixbefore\fR \fIdir\fR" 4
-.IX Item "-iwithprefixbefore dir"
-.PD
-Append \fIdir\fR to the prefix specified previously with
-\&\fB\-iprefix\fR, and add the resulting directory to the include search
-path. \fB\-iwithprefixbefore\fR puts it in the same place \fB\-I\fR
-would; \fB\-iwithprefix\fR puts it where \fB\-idirafter\fR would.
-.IP "\fB\-isysroot\fR \fIdir\fR" 4
-.IX Item "-isysroot dir"
-This option is like the \fB\-\-sysroot\fR option, but applies only to
-header files (except for Darwin targets, where it applies to both header
-files and libraries). See the \fB\-\-sysroot\fR option for more
-information.
-.IP "\fB\-imultilib\fR \fIdir\fR" 4
-.IX Item "-imultilib dir"
-Use \fIdir\fR as a subdirectory of the directory containing
-target-specific \*(C+ headers.
-.IP "\fB\-isystem\fR \fIdir\fR" 4
-.IX Item "-isystem dir"
-Search \fIdir\fR for header files, after all directories specified by
-\&\fB\-I\fR but before the standard system directories. Mark it
-as a system directory, so that it gets the same special treatment as
-is applied to the standard system directories.
-.Sp
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-iquote\fR \fIdir\fR" 4
-.IX Item "-iquote dir"
-Search \fIdir\fR only for header files requested with
-\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
-\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR, before all directories specified by
-\&\fB\-I\fR and before the standard system directories.
-.Sp
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-fdirectives\-only\fR" 4
-.IX Item "-fdirectives-only"
-When preprocessing, handle directives, but do not expand macros.
-.Sp
-The option's behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
-options.
-.Sp
-With \fB\-E\fR, preprocessing is limited to the handling of directives
-such as \f(CW\*(C`#define\*(C'\fR, \f(CW\*(C`#ifdef\*(C'\fR, and \f(CW\*(C`#error\*(C'\fR. Other
-preprocessor operations, such as macro expansion and trigraph
-conversion are not performed. In addition, the \fB\-dD\fR option is
-implicitly enabled.
-.Sp
-With \fB\-fpreprocessed\fR, predefinition of command line and most
-builtin macros is disabled. Macros such as \f(CW\*(C`_\|_LINE_\|_\*(C'\fR, which are
-contextually dependent, are handled normally. This enables compilation of
-files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
-.Sp
-With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
-\&\fB\-fpreprocessed\fR take precedence. This enables full preprocessing of
-files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
-.IP "\fB\-fdollars\-in\-identifiers\fR" 4
-.IX Item "-fdollars-in-identifiers"
-Accept \fB$\fR in identifiers.
-.IP "\fB\-fextended\-identifiers\fR" 4
-.IX Item "-fextended-identifiers"
-Accept universal character names in identifiers. This option is
-experimental; in a future version of \s-1GCC\s0, it will be enabled by
-default for C99 and \*(C+.
-.IP "\fB\-fpreprocessed\fR" 4
-.IX Item "-fpreprocessed"
-Indicate to the preprocessor that the input file has already been
-preprocessed. This suppresses things like macro expansion, trigraph
-conversion, escaped newline splicing, and processing of most directives.
-The preprocessor still recognizes and removes comments, so that you can
-pass a file preprocessed with \fB\-C\fR to the compiler without
-problems. In this mode the integrated preprocessor is little more than
-a tokenizer for the front ends.
-.Sp
-\&\fB\-fpreprocessed\fR is implicit if the input file has one of the
-extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR. These are the
-extensions that \s-1GCC\s0 uses for preprocessed files created by
-\&\fB\-save\-temps\fR.
-.IP "\fB\-ftabstop=\fR\fIwidth\fR" 4
-.IX Item "-ftabstop=width"
-Set the distance between tab stops. This helps the preprocessor report
-correct column numbers in warnings or errors, even if tabs appear on the
-line. If the value is less than 1 or greater than 100, the option is
-ignored. The default is 8.
-.IP "\fB\-fexec\-charset=\fR\fIcharset\fR" 4
-.IX Item "-fexec-charset=charset"
-Set the execution character set, used for string and character
-constants. The default is \s-1UTF\-8\s0. \fIcharset\fR can be any encoding
-supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
-.IP "\fB\-fwide\-exec\-charset=\fR\fIcharset\fR" 4
-.IX Item "-fwide-exec-charset=charset"
-Set the wide execution character set, used for wide string and
-character constants. The default is \s-1UTF\-32\s0 or \s-1UTF\-16\s0, whichever
-corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR. As with
-\&\fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
-by the system's \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
-problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
-.IP "\fB\-finput\-charset=\fR\fIcharset\fR" 4
-.IX Item "-finput-charset=charset"
-Set the input character set, used for translation from the character
-set of the input file to the source character set used by \s-1GCC\s0. If the
-locale does not specify, or \s-1GCC\s0 cannot get this information from the
-locale, the default is \s-1UTF\-8\s0. This can be overridden by either the locale
-or this command line option. Currently the command line option takes
-precedence if there's a conflict. \fIcharset\fR can be any encoding
-supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
-.IP "\fB\-fworking\-directory\fR" 4
-.IX Item "-fworking-directory"
-Enable generation of linemarkers in the preprocessor output that will
-let the compiler know the current working directory at the time of
-preprocessing. When this option is enabled, the preprocessor will
-emit, after the initial linemarker, a second linemarker with the
-current working directory followed by two slashes. \s-1GCC\s0 will use this
-directory, when it's present in the preprocessed input, as the
-directory emitted as the current working directory in some debugging
-information formats. This option is implicitly enabled if debugging
-information is enabled, but this can be inhibited with the negated
-form \fB\-fno\-working\-directory\fR. If the \fB\-P\fR flag is
-present in the command line, this option has no effect, since no
-\&\f(CW\*(C`#line\*(C'\fR directives are emitted whatsoever.
-.IP "\fB\-fno\-show\-column\fR" 4
-.IX Item "-fno-show-column"
-Do not print column numbers in diagnostics. This may be necessary if
-diagnostics are being scanned by a program that does not understand the
-column numbers, such as \fBdejagnu\fR.
-.IP "\fB\-A\fR \fIpredicate\fR\fB=\fR\fIanswer\fR" 4
-.IX Item "-A predicate=answer"
-Make an assertion with the predicate \fIpredicate\fR and answer
-\&\fIanswer\fR. This form is preferred to the older form \fB\-A\fR
-\&\fIpredicate\fR\fB(\fR\fIanswer\fR\fB)\fR, which is still supported, because
-it does not use shell special characters.
-.IP "\fB\-A \-\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4
-.IX Item "-A -predicate=answer"
-Cancel an assertion with the predicate \fIpredicate\fR and answer
-\&\fIanswer\fR.
-.IP "\fB\-dCHARS\fR" 4
-.IX Item "-dCHARS"
-\&\fI\s-1CHARS\s0\fR is a sequence of one or more of the following characters,
-and must not be preceded by a space. Other characters are interpreted
-by the compiler proper, or reserved for future versions of \s-1GCC\s0, and so
-are silently ignored. If you specify characters whose behavior
-conflicts, the result is undefined.
-.RS 4
-.IP "\fBM\fR" 4
-.IX Item "M"
-Instead of the normal output, generate a list of \fB#define\fR
-directives for all the macros defined during the execution of the
-preprocessor, including predefined macros. This gives you a way of
-finding out what is predefined in your version of the preprocessor.
-Assuming you have no file \fIfoo.h\fR, the command
-.Sp
-.Vb 1
-\& touch foo.h; cpp \-dM foo.h
-.Ve
-.Sp
-will show all the predefined macros.
-.Sp
-If you use \fB\-dM\fR without the \fB\-E\fR option, \fB\-dM\fR is
-interpreted as a synonym for \fB\-fdump\-rtl\-mach\fR.
-.IP "\fBD\fR" 4
-.IX Item "D"
-Like \fBM\fR except in two respects: it does \fInot\fR include the
-predefined macros, and it outputs \fIboth\fR the \fB#define\fR
-directives and the result of preprocessing. Both kinds of output go to
-the standard output file.
-.IP "\fBN\fR" 4
-.IX Item "N"
-Like \fBD\fR, but emit only the macro names, not their expansions.
-.IP "\fBI\fR" 4
-.IX Item "I"
-Output \fB#include\fR directives in addition to the result of
-preprocessing.
-.IP "\fBU\fR" 4
-.IX Item "U"
-Like \fBD\fR except that only macros that are expanded, or whose
-definedness is tested in preprocessor directives, are output; the
-output is delayed until the use or test of the macro; and
-\&\fB#undef\fR directives are also output for macros tested but
-undefined at the time.
-.RE
-.RS 4
-.RE
-.IP "\fB\-P\fR" 4
-.IX Item "-P"
-Inhibit generation of linemarkers in the output from the preprocessor.
-This might be useful when running the preprocessor on something that is
-not C code, and will be sent to a program which might be confused by the
-linemarkers.
-.IP "\fB\-C\fR" 4
-.IX Item "-C"
-Do not discard comments. All comments are passed through to the output
-file, except for comments in processed directives, which are deleted
-along with the directive.
-.Sp
-You should be prepared for side effects when using \fB\-C\fR; it
-causes the preprocessor to treat comments as tokens in their own right.
-For example, comments appearing at the start of what would be a
-directive line have the effect of turning that line into an ordinary
-source line, since the first token on the line is no longer a \fB#\fR.
-.IP "\fB\-CC\fR" 4
-.IX Item "-CC"
-Do not discard comments, including during macro expansion. This is
-like \fB\-C\fR, except that comments contained within macros are
-also passed through to the output file where the macro is expanded.
-.Sp
-In addition to the side-effects of the \fB\-C\fR option, the
-\&\fB\-CC\fR option causes all \*(C+\-style comments inside a macro
-to be converted to C\-style comments. This is to prevent later use
-of that macro from inadvertently commenting out the remainder of
-the source line.
-.Sp
-The \fB\-CC\fR option is generally used to support lint comments.
-.IP "\fB\-traditional\-cpp\fR" 4
-.IX Item "-traditional-cpp"
-Try to imitate the behavior of old-fashioned C preprocessors, as
-opposed to \s-1ISO\s0 C preprocessors.
-.IP "\fB\-trigraphs\fR" 4
-.IX Item "-trigraphs"
-Process trigraph sequences.
-.IP "\fB\-remap\fR" 4
-.IX Item "-remap"
-Enable special code to work around file systems which only permit very
-short file names, such as MS-DOS.
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-.PD 0
-.IP "\fB\-\-target\-help\fR" 4
-.IX Item "--target-help"
-.PD
-Print text describing all the command line options instead of
-preprocessing anything.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-Verbose mode. Print out \s-1GNU\s0 \s-1CPP\s0's version number at the beginning of
-execution, and report the final form of the include path.
-.IP "\fB\-H\fR" 4
-.IX Item "-H"
-Print the name of each header file used, in addition to other normal
-activities. Each name is indented to show how deep in the
-\&\fB#include\fR stack it is. Precompiled header files are also
-printed, even if they are found to be invalid; an invalid precompiled
-header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
-.IP "\fB\-version\fR" 4
-.IX Item "-version"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Print out \s-1GNU\s0 \s-1CPP\s0's version number. With one dash, proceed to
-preprocess as normal. With two dashes, exit immediately.
-.SH "ENVIRONMENT"
-.IX Header "ENVIRONMENT"
-This section describes the environment variables that affect how \s-1CPP\s0
-operates. You can use them to specify directories or prefixes to use
-when searching for include files, or to control dependency output.
-.PP
-Note that you can also specify places to search using options such as
-\&\fB\-I\fR, and control dependency output with options like
-\&\fB\-M\fR. These take precedence over
-environment variables, which in turn take precedence over the
-configuration of \s-1GCC\s0.
-.IP "\fB\s-1CPATH\s0\fR" 4
-.IX Item "CPATH"
-.PD 0
-.IP "\fBC_INCLUDE_PATH\fR" 4
-.IX Item "C_INCLUDE_PATH"
-.IP "\fB\s-1CPLUS_INCLUDE_PATH\s0\fR" 4
-.IX Item "CPLUS_INCLUDE_PATH"
-.IP "\fB\s-1OBJC_INCLUDE_PATH\s0\fR" 4
-.IX Item "OBJC_INCLUDE_PATH"
-.PD
-Each variable's value is a list of directories separated by a special
-character, much like \fB\s-1PATH\s0\fR, in which to look for header files.
-The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, is target-dependent and
-determined at \s-1GCC\s0 build time. For Microsoft Windows-based targets it is a
-semicolon, and for almost all other targets it is a colon.
-.Sp
-\&\fB\s-1CPATH\s0\fR specifies a list of directories to be searched as if
-specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
-options on the command line. This environment variable is used
-regardless of which language is being preprocessed.
-.Sp
-The remaining environment variables apply only when preprocessing the
-particular language indicated. Each specifies a list of directories
-to be searched as if specified with \fB\-isystem\fR, but after any
-paths given with \fB\-isystem\fR options on the command line.
-.Sp
-In all these variables, an empty element instructs the compiler to
-search its current working directory. Empty elements can appear at the
-beginning or end of a path. For instance, if the value of
-\&\fB\s-1CPATH\s0\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
-effect as \fB\-I.\ \-I/special/include\fR.
-.IP "\fB\s-1DEPENDENCIES_OUTPUT\s0\fR" 4
-.IX Item "DEPENDENCIES_OUTPUT"
-If this variable is set, its value specifies how to output
-dependencies for Make based on the non-system header files processed
-by the compiler. System header files are ignored in the dependency
-output.
-.Sp
-The value of \fB\s-1DEPENDENCIES_OUTPUT\s0\fR can be just a file name, in
-which case the Make rules are written to that file, guessing the target
-name from the source file name. Or the value can have the form
-\&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
-file \fIfile\fR using \fItarget\fR as the target name.
-.Sp
-In other words, this environment variable is equivalent to combining
-the options \fB\-MM\fR and \fB\-MF\fR,
-with an optional \fB\-MT\fR switch too.
-.IP "\fB\s-1SUNPRO_DEPENDENCIES\s0\fR" 4
-.IX Item "SUNPRO_DEPENDENCIES"
-This variable is the same as \fB\s-1DEPENDENCIES_OUTPUT\s0\fR (see above),
-except that system header files are not ignored, so it implies
-\&\fB\-M\fR rather than \fB\-MM\fR. However, the dependence on the
-main input file is omitted.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7),
-\&\fIgcc\fR\|(1), \fIas\fR\|(1), \fIld\fR\|(1), and the Info entries for \fIcpp\fR, \fIgcc\fR, and
-\&\fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1996,
-1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
-2008, 2009, 2010, 2011
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation. A copy of
-the license is included in the
-man page \fIgfdl\fR\|(7).
-This manual contains no Invariant Sections. The Front-Cover Texts are
-(a) (see below), and the Back-Cover Texts are (b) (see below).
-.PP
-(a) The \s-1FSF\s0's Front-Cover Text is:
-.PP
-.Vb 1
-\& A GNU Manual
-.Ve
-.PP
-(b) The \s-1FSF\s0's Back-Cover Text is:
-.PP
-.Vb 3
-\& You have freedom to copy and modify this GNU Manual, like GNU
-\& software. Copies published by the Free Software Foundation raise
-\& funds for GNU development.
-.Ve
diff --git a/share/man/man1/arm-eabi-dlltool.1 b/share/man/man1/arm-eabi-dlltool.1
deleted file mode 100644
index 37d7cf2..0000000
--- a/share/man/man1/arm-eabi-dlltool.1
+++ /dev/null
@@ -1,531 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "DLLTOOL 1"
-.TH DLLTOOL 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-dlltool \- Create files needed to build and use DLLs.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-dlltool [\fB\-d\fR|\fB\-\-input\-def\fR \fIdef-file-name\fR]
- [\fB\-b\fR|\fB\-\-base\-file\fR \fIbase-file-name\fR]
- [\fB\-e\fR|\fB\-\-output\-exp\fR \fIexports-file-name\fR]
- [\fB\-z\fR|\fB\-\-output\-def\fR \fIdef-file-name\fR]
- [\fB\-l\fR|\fB\-\-output\-lib\fR \fIlibrary-file-name\fR]
- [\fB\-y\fR|\fB\-\-output\-delaylib\fR \fIlibrary-file-name\fR]
- [\fB\-\-export\-all\-symbols\fR] [\fB\-\-no\-export\-all\-symbols\fR]
- [\fB\-\-exclude\-symbols\fR \fIlist\fR]
- [\fB\-\-no\-default\-excludes\fR]
- [\fB\-S\fR|\fB\-\-as\fR \fIpath-to-assembler\fR] [\fB\-f\fR|\fB\-\-as\-flags\fR \fIoptions\fR]
- [\fB\-D\fR|\fB\-\-dllname\fR \fIname\fR] [\fB\-m\fR|\fB\-\-machine\fR \fImachine\fR]
- [\fB\-a\fR|\fB\-\-add\-indirect\fR]
- [\fB\-U\fR|\fB\-\-add\-underscore\fR] [\fB\-\-add\-stdcall\-underscore\fR]
- [\fB\-k\fR|\fB\-\-kill\-at\fR] [\fB\-A\fR|\fB\-\-add\-stdcall\-alias\fR]
- [\fB\-p\fR|\fB\-\-ext\-prefix\-alias\fR \fIprefix\fR]
- [\fB\-x\fR|\fB\-\-no\-idata4\fR] [\fB\-c\fR|\fB\-\-no\-idata5\fR]
- [\fB\-\-use\-nul\-prefixed\-import\-tables\fR]
- [\fB\-I\fR|\fB\-\-identify\fR \fIlibrary-file-name\fR] [\fB\-\-identify\-strict\fR]
- [\fB\-i\fR|\fB\-\-interwork\fR]
- [\fB\-n\fR|\fB\-\-nodelete\fR] [\fB\-t\fR|\fB\-\-temp\-prefix\fR \fIprefix\fR]
- [\fB\-v\fR|\fB\-\-verbose\fR]
- [\fB\-h\fR|\fB\-\-help\fR] [\fB\-V\fR|\fB\-\-version\fR]
- [\fB\-\-no\-leading\-underscore\fR] [\fB\-\-leading\-underscore\fR]
- [object\-file ...]
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\fBdlltool\fR reads its inputs, which can come from the \fB\-d\fR and
-\&\fB\-b\fR options as well as object files specified on the command
-line. It then processes these inputs and if the \fB\-e\fR option has
-been specified it creates a exports file. If the \fB\-l\fR option
-has been specified it creates a library file and if the \fB\-z\fR option
-has been specified it creates a def file. Any or all of the \fB\-e\fR,
-\&\fB\-l\fR and \fB\-z\fR options can be present in one invocation of
-dlltool.
-.PP
-When creating a \s-1DLL\s0, along with the source for the \s-1DLL\s0, it is necessary
-to have three other files. \fBdlltool\fR can help with the creation of
-these files.
-.PP
-The first file is a \fI.def\fR file which specifies which functions are
-exported from the \s-1DLL\s0, which functions the \s-1DLL\s0 imports, and so on. This
-is a text file and can be created by hand, or \fBdlltool\fR can be used
-to create it using the \fB\-z\fR option. In this case \fBdlltool\fR
-will scan the object files specified on its command line looking for
-those functions which have been specially marked as being exported and
-put entries for them in the \fI.def\fR file it creates.
-.PP
-In order to mark a function as being exported from a \s-1DLL\s0, it needs to
-have an \fB\-export:<name_of_function>\fR entry in the \fB.drectve\fR
-section of the object file. This can be done in C by using the
-\&\fIasm()\fR operator:
-.PP
-.Vb 2
-\& asm (".section .drectve");
-\& asm (".ascii \e"\-export:my_func\e"");
-\&
-\& int my_func (void) { ... }
-.Ve
-.PP
-The second file needed for \s-1DLL\s0 creation is an exports file. This file
-is linked with the object files that make up the body of the \s-1DLL\s0 and it
-handles the interface between the \s-1DLL\s0 and the outside world. This is a
-binary file and it can be created by giving the \fB\-e\fR option to
-\&\fBdlltool\fR when it is creating or reading in a \fI.def\fR file.
-.PP
-The third file needed for \s-1DLL\s0 creation is the library file that programs
-will link with in order to access the functions in the \s-1DLL\s0 (an `import
-library'). This file can be created by giving the \fB\-l\fR option to
-dlltool when it is creating or reading in a \fI.def\fR file.
-.PP
-If the \fB\-y\fR option is specified, dlltool generates a delay-import
-library that can be used instead of the normal import library to allow
-a program to link to the dll only as soon as an imported function is
-called for the first time. The resulting executable will need to be
-linked to the static delayimp library containing _\|\fI_delayLoadHelper2()\fR,
-which in turn will import LoadLibraryA and GetProcAddress from kernel32.
-.PP
-\&\fBdlltool\fR builds the library file by hand, but it builds the
-exports file by creating temporary files containing assembler statements
-and then assembling these. The \fB\-S\fR command line option can be
-used to specify the path to the assembler that dlltool will use,
-and the \fB\-f\fR option can be used to pass specific flags to that
-assembler. The \fB\-n\fR can be used to prevent dlltool from deleting
-these temporary assembler files when it is done, and if \fB\-n\fR is
-specified twice then this will prevent dlltool from deleting the
-temporary object files it used to build the library.
-.PP
-Here is an example of creating a \s-1DLL\s0 from a source file \fBdll.c\fR and
-also creating a program (from an object file called \fBprogram.o\fR)
-that uses that \s-1DLL:\s0
-.PP
-.Vb 4
-\& gcc \-c dll.c
-\& dlltool \-e exports.o \-l dll.lib dll.o
-\& gcc dll.o exports.o \-o dll.dll
-\& gcc program.o dll.lib \-o program
-.Ve
-.PP
-\&\fBdlltool\fR may also be used to query an existing import library
-to determine the name of the \s-1DLL\s0 to which it is associated. See the
-description of the \fB\-I\fR or \fB\-\-identify\fR option.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-The command line options have the following meanings:
-.IP "\fB\-d\fR \fIfilename\fR" 4
-.IX Item "-d filename"
-.PD 0
-.IP "\fB\-\-input\-def\fR \fIfilename\fR" 4
-.IX Item "--input-def filename"
-.PD
-Specifies the name of a \fI.def\fR file to be read in and processed.
-.IP "\fB\-b\fR \fIfilename\fR" 4
-.IX Item "-b filename"
-.PD 0
-.IP "\fB\-\-base\-file\fR \fIfilename\fR" 4
-.IX Item "--base-file filename"
-.PD
-Specifies the name of a base file to be read in and processed. The
-contents of this file will be added to the relocation section in the
-exports file generated by dlltool.
-.IP "\fB\-e\fR \fIfilename\fR" 4
-.IX Item "-e filename"
-.PD 0
-.IP "\fB\-\-output\-exp\fR \fIfilename\fR" 4
-.IX Item "--output-exp filename"
-.PD
-Specifies the name of the export file to be created by dlltool.
-.IP "\fB\-z\fR \fIfilename\fR" 4
-.IX Item "-z filename"
-.PD 0
-.IP "\fB\-\-output\-def\fR \fIfilename\fR" 4
-.IX Item "--output-def filename"
-.PD
-Specifies the name of the \fI.def\fR file to be created by dlltool.
-.IP "\fB\-l\fR \fIfilename\fR" 4
-.IX Item "-l filename"
-.PD 0
-.IP "\fB\-\-output\-lib\fR \fIfilename\fR" 4
-.IX Item "--output-lib filename"
-.PD
-Specifies the name of the library file to be created by dlltool.
-.IP "\fB\-y\fR \fIfilename\fR" 4
-.IX Item "-y filename"
-.PD 0
-.IP "\fB\-\-output\-delaylib\fR \fIfilename\fR" 4
-.IX Item "--output-delaylib filename"
-.PD
-Specifies the name of the delay-import library file to be created by dlltool.
-.IP "\fB\-\-export\-all\-symbols\fR" 4
-.IX Item "--export-all-symbols"
-Treat all global and weak defined symbols found in the input object
-files as symbols to be exported. There is a small list of symbols which
-are not exported by default; see the \fB\-\-no\-default\-excludes\fR
-option. You may add to the list of symbols to not export by using the
-\&\fB\-\-exclude\-symbols\fR option.
-.IP "\fB\-\-no\-export\-all\-symbols\fR" 4
-.IX Item "--no-export-all-symbols"
-Only export symbols explicitly listed in an input \fI.def\fR file or in
-\&\fB.drectve\fR sections in the input object files. This is the default
-behaviour. The \fB.drectve\fR sections are created by \fBdllexport\fR
-attributes in the source code.
-.IP "\fB\-\-exclude\-symbols\fR \fIlist\fR" 4
-.IX Item "--exclude-symbols list"
-Do not export the symbols in \fIlist\fR. This is a list of symbol names
-separated by comma or colon characters. The symbol names should not
-contain a leading underscore. This is only meaningful when
-\&\fB\-\-export\-all\-symbols\fR is used.
-.IP "\fB\-\-no\-default\-excludes\fR" 4
-.IX Item "--no-default-excludes"
-When \fB\-\-export\-all\-symbols\fR is used, it will by default avoid
-exporting certain special symbols. The current list of symbols to avoid
-exporting is \fBDllMain@12\fR, \fBDllEntryPoint@0\fR,
-\&\fBimpure_ptr\fR. You may use the \fB\-\-no\-default\-excludes\fR option
-to go ahead and export these special symbols. This is only meaningful
-when \fB\-\-export\-all\-symbols\fR is used.
-.IP "\fB\-S\fR \fIpath\fR" 4
-.IX Item "-S path"
-.PD 0
-.IP "\fB\-\-as\fR \fIpath\fR" 4
-.IX Item "--as path"
-.PD
-Specifies the path, including the filename, of the assembler to be used
-to create the exports file.
-.IP "\fB\-f\fR \fIoptions\fR" 4
-.IX Item "-f options"
-.PD 0
-.IP "\fB\-\-as\-flags\fR \fIoptions\fR" 4
-.IX Item "--as-flags options"
-.PD
-Specifies any specific command line options to be passed to the
-assembler when building the exports file. This option will work even if
-the \fB\-S\fR option is not used. This option only takes one argument,
-and if it occurs more than once on the command line, then later
-occurrences will override earlier occurrences. So if it is necessary to
-pass multiple options to the assembler they should be enclosed in
-double quotes.
-.IP "\fB\-D\fR \fIname\fR" 4
-.IX Item "-D name"
-.PD 0
-.IP "\fB\-\-dll\-name\fR \fIname\fR" 4
-.IX Item "--dll-name name"
-.PD
-Specifies the name to be stored in the \fI.def\fR file as the name of
-the \s-1DLL\s0 when the \fB\-e\fR option is used. If this option is not
-present, then the filename given to the \fB\-e\fR option will be
-used as the name of the \s-1DLL\s0.
-.IP "\fB\-m\fR \fImachine\fR" 4
-.IX Item "-m machine"
-.PD 0
-.IP "\fB\-machine\fR \fImachine\fR" 4
-.IX Item "-machine machine"
-.PD
-Specifies the type of machine for which the library file should be
-built. \fBdlltool\fR has a built in default type, depending upon how
-it was created, but this option can be used to override that. This is
-normally only useful when creating DLLs for an \s-1ARM\s0 processor, when the
-contents of the \s-1DLL\s0 are actually encode using Thumb instructions.
-.IP "\fB\-a\fR" 4
-.IX Item "-a"
-.PD 0
-.IP "\fB\-\-add\-indirect\fR" 4
-.IX Item "--add-indirect"
-.PD
-Specifies that when \fBdlltool\fR is creating the exports file it
-should add a section which allows the exported functions to be
-referenced without using the import library. Whatever the hell that
-means!
-.IP "\fB\-U\fR" 4
-.IX Item "-U"
-.PD 0
-.IP "\fB\-\-add\-underscore\fR" 4
-.IX Item "--add-underscore"
-.PD
-Specifies that when \fBdlltool\fR is creating the exports file it
-should prepend an underscore to the names of \fIall\fR exported symbols.
-.IP "\fB\-\-no\-leading\-underscore\fR" 4
-.IX Item "--no-leading-underscore"
-.PD 0
-.IP "\fB\-\-leading\-underscore\fR" 4
-.IX Item "--leading-underscore"
-.PD
-Specifies whether standard symbol should be forced to be prefixed, or
-not.
-.IP "\fB\-\-add\-stdcall\-underscore\fR" 4
-.IX Item "--add-stdcall-underscore"
-Specifies that when \fBdlltool\fR is creating the exports file it
-should prepend an underscore to the names of exported \fIstdcall\fR
-functions. Variable names and non-stdcall function names are not modified.
-This option is useful when creating GNU-compatible import libs for third
-party DLLs that were built with MS-Windows tools.
-.IP "\fB\-k\fR" 4
-.IX Item "-k"
-.PD 0
-.IP "\fB\-\-kill\-at\fR" 4
-.IX Item "--kill-at"
-.PD
-Specifies that when \fBdlltool\fR is creating the exports file it
-should not append the string \fB@ <number>\fR. These numbers are
-called ordinal numbers and they represent another way of accessing the
-function in a \s-1DLL\s0, other than by name.
-.IP "\fB\-A\fR" 4
-.IX Item "-A"
-.PD 0
-.IP "\fB\-\-add\-stdcall\-alias\fR" 4
-.IX Item "--add-stdcall-alias"
-.PD
-Specifies that when \fBdlltool\fR is creating the exports file it
-should add aliases for stdcall symbols without \fB@ <number>\fR
-in addition to the symbols with \fB@ <number>\fR.
-.IP "\fB\-p\fR" 4
-.IX Item "-p"
-.PD 0
-.IP "\fB\-\-ext\-prefix\-alias\fR \fIprefix\fR" 4
-.IX Item "--ext-prefix-alias prefix"
-.PD
-Causes \fBdlltool\fR to create external aliases for all \s-1DLL\s0
-imports with the specified prefix. The aliases are created for both
-external and import symbols with no leading underscore.
-.IP "\fB\-x\fR" 4
-.IX Item "-x"
-.PD 0
-.IP "\fB\-\-no\-idata4\fR" 4
-.IX Item "--no-idata4"
-.PD
-Specifies that when \fBdlltool\fR is creating the exports and library
-files it should omit the \f(CW\*(C`.idata4\*(C'\fR section. This is for compatibility
-with certain operating systems.
-.IP "\fB\-\-use\-nul\-prefixed\-import\-tables\fR" 4
-.IX Item "--use-nul-prefixed-import-tables"
-Specifies that when \fBdlltool\fR is creating the exports and library
-files it should prefix the \f(CW\*(C`.idata4\*(C'\fR and \f(CW\*(C`.idata5\*(C'\fR by zero an
-element. This emulates old gnu import library generation of
-\&\f(CW\*(C`dlltool\*(C'\fR. By default this option is turned off.
-.IP "\fB\-c\fR" 4
-.IX Item "-c"
-.PD 0
-.IP "\fB\-\-no\-idata5\fR" 4
-.IX Item "--no-idata5"
-.PD
-Specifies that when \fBdlltool\fR is creating the exports and library
-files it should omit the \f(CW\*(C`.idata5\*(C'\fR section. This is for compatibility
-with certain operating systems.
-.IP "\fB\-I\fR \fIfilename\fR" 4
-.IX Item "-I filename"
-.PD 0
-.IP "\fB\-\-identify\fR \fIfilename\fR" 4
-.IX Item "--identify filename"
-.PD
-Specifies that \fBdlltool\fR should inspect the import library
-indicated by \fIfilename\fR and report, on \f(CW\*(C`stdout\*(C'\fR, the name(s)
-of the associated \s-1DLL\s0(s). This can be performed in addition to any
-other operations indicated by the other options and arguments.
-\&\fBdlltool\fR fails if the import library does not exist or is not
-actually an import library. See also \fB\-\-identify\-strict\fR.
-.IP "\fB\-\-identify\-strict\fR" 4
-.IX Item "--identify-strict"
-Modifies the behavior of the \fB\-\-identify\fR option, such
-that an error is reported if \fIfilename\fR is associated with
-more than one \s-1DLL\s0.
-.IP "\fB\-i\fR" 4
-.IX Item "-i"
-.PD 0
-.IP "\fB\-\-interwork\fR" 4
-.IX Item "--interwork"
-.PD
-Specifies that \fBdlltool\fR should mark the objects in the library
-file and exports file that it produces as supporting interworking
-between \s-1ARM\s0 and Thumb code.
-.IP "\fB\-n\fR" 4
-.IX Item "-n"
-.PD 0
-.IP "\fB\-\-nodelete\fR" 4
-.IX Item "--nodelete"
-.PD
-Makes \fBdlltool\fR preserve the temporary assembler files it used to
-create the exports file. If this option is repeated then dlltool will
-also preserve the temporary object files it uses to create the library
-file.
-.IP "\fB\-t\fR \fIprefix\fR" 4
-.IX Item "-t prefix"
-.PD 0
-.IP "\fB\-\-temp\-prefix\fR \fIprefix\fR" 4
-.IX Item "--temp-prefix prefix"
-.PD
-Makes \fBdlltool\fR use \fIprefix\fR when constructing the names of
-temporary assembler and object files. By default, the temp file prefix
-is generated from the pid.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.IP "\fB\-\-verbose\fR" 4
-.IX Item "--verbose"
-.PD
-Make dlltool describe what it is doing.
-.IP "\fB\-h\fR" 4
-.IX Item "-h"
-.PD 0
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-.PD
-Displays a list of command line options and then exits.
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Displays dlltool's version number and then exits.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-The Info pages for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-elfedit.1 b/share/man/man1/arm-eabi-elfedit.1
deleted file mode 100644
index dc21437..0000000
--- a/share/man/man1/arm-eabi-elfedit.1
+++ /dev/null
@@ -1,233 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "ELFEDIT 1"
-.TH ELFEDIT 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-elfedit \- Update the ELF header of ELF files.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-elfedit [\fB\-\-input\-mach=\fR\fImachine\fR]
- [\fB\-\-input\-type=\fR\fItype\fR]
- [\fB\-\-input\-osabi=\fR\fIosbi\fR]
- \fB\-\-output\-mach=\fR\fImachine\fR
- \fB\-\-output\-type=\fR\fItype\fR
- \fB\-\-output\-osabi=\fR\fIosbi\fR
- [\fB\-v\fR|\fB\-\-version\fR]
- [\fB\-h\fR|\fB\-\-help\fR]
- \fIelffile\fR...
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\fBelfedit\fR updates the \s-1ELF\s0 header of \s-1ELF\s0 files which have
-the matching \s-1ELF\s0 machine and file types. The options control how and
-which fields in the \s-1ELF\s0 header should be updated.
-.PP
-\&\fIelffile\fR... are the \s-1ELF\s0 files to be updated. 32\-bit and
-64\-bit \s-1ELF\s0 files are supported, as are archives containing \s-1ELF\s0 files.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-The long and short forms of options, shown here as alternatives, are
-equivalent. At least one of the \fB\-\-output\-mach\fR,
-\&\fB\-\-output\-type\fR and \fB\-\-output\-osabi\fR options must be given.
-.IP "\fB\-\-input\-mach=\fR\fImachine\fR" 4
-.IX Item "--input-mach=machine"
-Set the matching input \s-1ELF\s0 machine type to \fImachine\fR. If
-\&\fB\-\-input\-mach\fR isn't specified, it will match any \s-1ELF\s0
-machine types.
-.Sp
-The supported \s-1ELF\s0 machine types are, \fIL1OM\fR and \fIx86\-64\fR.
-.IP "\fB\-\-output\-mach=\fR\fImachine\fR" 4
-.IX Item "--output-mach=machine"
-Change the \s-1ELF\s0 machine type in the \s-1ELF\s0 header to \fImachine\fR. The
-supported \s-1ELF\s0 machine types are the same as \fB\-\-input\-mach\fR.
-.IP "\fB\-\-input\-type=\fR\fItype\fR" 4
-.IX Item "--input-type=type"
-Set the matching input \s-1ELF\s0 file type to \fItype\fR. If
-\&\fB\-\-input\-type\fR isn't specified, it will match any \s-1ELF\s0 file types.
-.Sp
-The supported \s-1ELF\s0 file types are, \fIrel\fR, \fIexec\fR and \fIdyn\fR.
-.IP "\fB\-\-output\-type=\fR\fItype\fR" 4
-.IX Item "--output-type=type"
-Change the \s-1ELF\s0 file type in the \s-1ELF\s0 header to \fItype\fR. The
-supported \s-1ELF\s0 types are the same as \fB\-\-input\-type\fR.
-.IP "\fB\-\-input\-osabi=\fR\fIosabi\fR" 4
-.IX Item "--input-osabi=osabi"
-Set the matching input \s-1ELF\s0 file \s-1OSABI\s0 to \fIosbi\fR. If
-\&\fB\-\-input\-osabi\fR isn't specified, it will match any \s-1ELF\s0 OSABIs.
-.Sp
-The supported \s-1ELF\s0 OSABIs are, \fInone\fR, \fI\s-1HPUX\s0\fR, \fINetBSD\fR,
-\&\fILinux\fR, \fIHurd\fR, \fISolaris\fR, \fI\s-1AIX\s0\fR, \fIIrix\fR,
-\&\fIFreeBSD\fR, \fI\s-1TRU64\s0\fR, \fIModesto\fR, \fIOpenBSD\fR, \fIOpenVMS\fR,
-\&\fI\s-1NSK\s0\fR, \fI\s-1AROS\s0\fR and \fIFenixOS\fR.
-.IP "\fB\-\-output\-osabi=\fR\fIosabi\fR" 4
-.IX Item "--output-osabi=osabi"
-Change the \s-1ELF\s0 \s-1OSABI\s0 in the \s-1ELF\s0 header to \fItype\fR. The
-supported \s-1ELF\s0 \s-1OSABI\s0 are the same as \fB\-\-input\-osabi\fR.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Display the version number of \fBelfedit\fR.
-.IP "\fB\-h\fR" 4
-.IX Item "-h"
-.PD 0
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-.PD
-Display the command line options understood by \fBelfedit\fR.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIreadelf\fR\|(1), and the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-g++.1 b/share/man/man1/arm-eabi-g++.1
deleted file mode 100644
index d08d4ac..0000000
--- a/share/man/man1/arm-eabi-g++.1
+++ /dev/null
@@ -1,17818 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "GCC 1"
-.TH GCC 1 "2012-01-06" "gcc-4.6.x-google" "GNU"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-gcc \- GNU project C and C++ compiler
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-gcc [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR] [\fB\-std=\fR\fIstandard\fR]
- [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
- [\fB\-W\fR\fIwarn\fR...] [\fB\-pedantic\fR]
- [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
- [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
- [\fB\-f\fR\fIoption\fR...] [\fB\-m\fR\fImachine-option\fR...]
- [\fB\-o\fR \fIoutfile\fR] [@\fIfile\fR] \fIinfile\fR...
-.PP
-Only the most useful options are listed here; see below for the
-remainder. \fBg++\fR accepts mostly the same options as \fBgcc\fR.
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-When you invoke \s-1GCC\s0, it normally does preprocessing, compilation,
-assembly and linking. The \*(L"overall options\*(R" allow you to stop this
-process at an intermediate stage. For example, the \fB\-c\fR option
-says not to run the linker. Then the output consists of object files
-output by the assembler.
-.PP
-Other options are passed on to one stage of processing. Some options
-control the preprocessor and others the compiler itself. Yet other
-options control the assembler and linker; most of these are not
-documented here, since you rarely need to use any of them.
-.PP
-Most of the command line options that you can use with \s-1GCC\s0 are useful
-for C programs; when an option is only useful with another language
-(usually \*(C+), the explanation says so explicitly. If the description
-for a particular option does not mention a source language, you can use
-that option with all supported languages.
-.PP
-The \fBgcc\fR program accepts options and file names as operands. Many
-options have multi-letter names; therefore multiple single-letter options
-may \fInot\fR be grouped: \fB\-dv\fR is very different from \fB\-d\ \-v\fR.
-.PP
-You can mix options and other arguments. For the most part, the order
-you use doesn't matter. Order does matter when you use several
-options of the same kind; for example, if you specify \fB\-L\fR more
-than once, the directories are searched in the order specified. Also,
-the placement of the \fB\-l\fR option is significant.
-.PP
-Many options have long names starting with \fB\-f\fR or with
-\&\fB\-W\fR\-\-\-for example,
-\&\fB\-fmove\-loop\-invariants\fR, \fB\-Wformat\fR and so on. Most of
-these have both positive and negative forms; the negative form of
-\&\fB\-ffoo\fR would be \fB\-fno\-foo\fR. This manual documents
-only one of these two forms, whichever one is not the default.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.SS "Option Summary"
-.IX Subsection "Option Summary"
-Here is a summary of all the options, grouped by type. Explanations are
-in the following sections.
-.IP "\fIOverall Options\fR" 4
-.IX Item "Overall Options"
-\&\fB\-c \-S \-E \-o\fR \fIfile\fR \fB\-no\-canonical\-prefixes
-\&\-pipe \-pass\-exit\-codes
-\&\-x\fR \fIlanguage\fR \fB\-v \-### \-\-help\fR[\fB=\fR\fIclass\fR[\fB,...\fR]] \fB\-\-target\-help
-\&\-\-version \-wrapper @\fR\fIfile\fR \fB\-fplugin=\fR\fIfile\fR \fB\-fplugin\-arg\-\fR\fIname\fR\fB=\fR\fIarg\fR
-\&\fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] \-fdump\-go\-spec=\fIfile\fR
-.IP "\fIC Language Options\fR" 4
-.IX Item "C Language Options"
-\&\fB\-ansi \-std=\fR\fIstandard\fR \fB\-fgnu89\-inline
-\&\-aux\-info\fR \fIfilename\fR
-\&\fB\-fno\-asm \-fno\-builtin \-fno\-builtin\-\fR\fIfunction\fR
-\&\fB\-fhosted \-ffreestanding \-fopenmp \-fms\-extensions \-fplan9\-extensions
-\&\-trigraphs \-no\-integrated\-cpp \-traditional \-traditional\-cpp
-\&\-fallow\-single\-precision \-fcond\-mismatch \-flax\-vector\-conversions
-\&\-fsigned\-bitfields \-fsigned\-char
-\&\-funsigned\-bitfields \-funsigned\-char\fR
-.IP "\fI\*(C+ Language Options\fR" 4
-.IX Item " Language Options"
-\&\fB\-fabi\-version=\fR\fIn\fR \fB\-fno\-access\-control \-fcheck\-new
-\&\-fconserve\-space \-fconstexpr\-depth=\fR\fIn\fR \fB\-ffriend\-injection
-\&\-fno\-elide\-constructors
-\&\-fno\-enforce\-eh\-specs
-\&\-ffor\-scope \-fno\-for\-scope \-fno\-gnu\-keywords
-\&\-fno\-implicit\-templates
-\&\-fno\-implicit\-inline\-templates
-\&\-fno\-implement\-inlines \-fms\-extensions
-\&\-fno\-nonansi\-builtins \-fnothrow\-opt \-fno\-operator\-names
-\&\-fno\-optional\-diags \-fpermissive
-\&\-fno\-pretty\-templates
-\&\-frepo \-fno\-rtti \-fstats \-ftemplate\-depth=\fR\fIn\fR
-\&\fB\-fno\-threadsafe\-statics \-fuse\-cxa\-atexit \-fno\-weak \-nostdinc++
-\&\-fno\-default\-inline \-fvisibility\-inlines\-hidden
-\&\-fvisibility\-ms\-compat
-\&\-Wabi \-Wconversion\-null \-Wctor\-dtor\-privacy
-\&\-Wnoexcept \-Wnon\-virtual\-dtor \-Wreorder
-\&\-Weffc++ \-Wstrict\-null\-sentinel
-\&\-Wno\-non\-template\-friend \-Wold\-style\-cast
-\&\-Woverloaded\-virtual \-Wno\-pmf\-conversions
-\&\-Wsign\-promo\fR
-.IP "\fIObjective-C and Objective\-\*(C+ Language Options\fR" 4
-.IX Item "Objective-C and Objective- Language Options"
-\&\fB\-fconstant\-string\-class=\fR\fIclass-name\fR
-\&\fB\-fgnu\-runtime \-fnext\-runtime
-\&\-fno\-nil\-receivers
-\&\-fobjc\-abi\-version=\fR\fIn\fR
-\&\fB\-fobjc\-call\-cxx\-cdtors
-\&\-fobjc\-direct\-dispatch
-\&\-fobjc\-exceptions
-\&\-fobjc\-gc
-\&\-fobjc\-nilcheck
-\&\-fobjc\-std=objc1
-\&\-freplace\-objc\-classes
-\&\-fzero\-link
-\&\-gen\-decls
-\&\-Wassign\-intercept
-\&\-Wno\-protocol \-Wselector
-\&\-Wstrict\-selector\-match
-\&\-Wundeclared\-selector\fR
-.IP "\fILanguage Independent Options\fR" 4
-.IX Item "Language Independent Options"
-\&\fB\-fmessage\-length=\fR\fIn\fR
-\&\fB\-fdiagnostics\-show\-location=\fR[\fBonce\fR|\fBevery-line\fR]
-\&\fB\-fno\-diagnostics\-show\-option\fR
-.IP "\fIWarning Options\fR" 4
-.IX Item "Warning Options"
-\&\fB\-fsyntax\-only \-fmax\-errors=\fR\fIn\fR \fB\-pedantic
-\&\-pedantic\-errors
-\&\-w \-Wextra \-Wall \-Waddress \-Waggregate\-return \-Warray\-bounds
-\&\-Wno\-attributes \-Wno\-builtin\-macro\-redefined
-\&\-Wc++\-compat \-Wc++0x\-compat \-Wcast\-align \-Wcast\-qual
-\&\-Wchar\-subscripts \-Wclobbered \-Wcomment
-\&\-Wconversion \-Wcoverage\-mismatch \-Wno\-cpp \-Wno\-deprecated
-\&\-Wno\-deprecated\-declarations \-Wdisabled\-optimization
-\&\-Wno\-div\-by\-zero \-Wdouble\-promotion \-Wempty\-body \-Wenum\-compare
-\&\-Wno\-endif\-labels \-Werror \-Werror=*
-\&\-Wfatal\-errors \-Wfloat\-equal \-Wformat \-Wformat=2
-\&\-Wno\-format\-contains\-nul \-Wno\-format\-extra\-args \-Wformat\-nonliteral
-\&\-Wformat\-security \-Wformat\-y2k
-\&\-Wframe\-larger\-than=\fR\fIlen\fR \fB\-Wjump\-misses\-init \-Wignored\-qualifiers
-\&\-Wimplicit \-Wimplicit\-function\-declaration \-Wimplicit\-int
-\&\-Winit\-self \-Winline \-Wmaybe\-uninitialized
-\&\-Wno\-int\-to\-pointer\-cast \-Wno\-invalid\-offsetof
-\&\-Winvalid\-pch \-Wlarger\-than=\fR\fIlen\fR \fB\-Wunsafe\-loop\-optimizations
-\&\-Wlogical\-op \-Wlong\-long
-\&\-Wmain \-Wmaybe\-uninitialized \-Wmissing\-braces \-Wmissing\-field\-initializers
-\&\-Wmissing\-format\-attribute \-Wmissing\-include\-dirs
-\&\-Wno\-mudflap
-\&\-Wno\-multichar \-Wnonnull \-Wno\-overflow
-\&\-Woverlength\-strings \-Wpacked \-Wpacked\-bitfield\-compat \-Wpadded
-\&\-Wparentheses \-Wpedantic\-ms\-format \-Wno\-pedantic\-ms\-format
-\&\-Wpointer\-arith \-Wno\-pointer\-to\-int\-cast
-\&\-Wreal\-conversion \-Wredundant\-decls \-Wreturn\-type \-Wripa\-opt\-mismatch
-\&\-Wself\-assign \-Wself\-assign\-non\-pod \-Wsequence\-point \-Wshadow
-\&\-Wshadow\-compatible\-local \-Wshadow\-local
-\&\-Wsign\-compare \-Wsign\-conversion \-Wstack\-protector
-\&\-Wstrict\-aliasing \-Wstrict\-aliasing=n
-\&\-Wstrict\-overflow \-Wstrict\-overflow=\fR\fIn\fR
-\&\fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR]
-\&\fB\-Wswitch \-Wswitch\-default \-Wswitch\-enum \-Wsync\-nand
-\&\-Wsystem\-headers \-Wthread\-safety \-Wthread\-unguarded\-var
-\&\-Wthread\-unguarded\-func \-Wthread\-mismatched\-lock\-order
-\&\-Wthread\-mismatched\-lock\-acq\-rel \-Wthread\-reentrant\-lock
-\&\-Wthread\-unsupported\-lock\-name \-Wthread\-attr\-bind\-param
-\&\-Wtrampolines \-Wtrigraphs \-Wtype\-limits \-Wundef
-\&\-Wuninitialized \-Wunknown\-pragmas \-Wno\-pragmas
-\&\-Wunsuffixed\-float\-constants \-Wunused \-Wunused\-function
-\&\-Wunused\-label \-Wunused\-parameter \-Wno\-unused\-result \-Wunused\-value
-\&\-Wunused\-variable \-Wunused\-but\-set\-parameter \-Wunused\-but\-set\-variable
-\&\-Wvariadic\-macros \-Wvla \-Wvolatile\-register\-var \-Wwrite\-strings\fR
-.IP "\fIC and Objective-C-only Warning Options\fR" 4
-.IX Item "C and Objective-C-only Warning Options"
-\&\fB\-Wbad\-function\-cast \-Wmissing\-declarations
-\&\-Wmissing\-parameter\-type \-Wmissing\-prototypes \-Wnested\-externs
-\&\-Wold\-style\-declaration \-Wold\-style\-definition
-\&\-Wstrict\-prototypes \-Wtraditional \-Wtraditional\-conversion
-\&\-Wdeclaration\-after\-statement \-Wpointer\-sign\fR
-.IP "\fIDebugging Options\fR" 4
-.IX Item "Debugging Options"
-\&\fB\-d\fR\fIletters\fR \fB\-dumpspecs \-dumpmachine \-dumpversion
-\&\-fdbg\-cnt\-list \-fdbg\-cnt=\fR\fIcounter-value-list\fR
-\&\fB\-fdisable\-ipa\-\fR\fIpass_name\fR
-\&\fB\-fdisable\-rtl\-\fR\fIpass_name\fR
-\&\fB\-fdisable\-rtl\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR
-\&\fB\-fdisable\-tree\-\fR\fIpass_name\fR
-\&\fB\-fdisable\-tree\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR
-\&\fB\-fdump\-noaddr \-fdump\-unnumbered \-fdump\-unnumbered\-links
-\&\-fdump\-translation\-unit\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-class\-hierarchy\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-ipa\-all \-fdump\-ipa\-cgraph \-fdump\-ipa\-inline
-\&\-fdump\-passes
-\&\-fdump\-statistics
-\&\-fdump\-tree\-all
-\&\-fdump\-tree\-original\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-optimized\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-cfg \-fdump\-tree\-vcg \-fdump\-tree\-alias
-\&\-fdump\-tree\-ch
-\&\-fdump\-tree\-ssa\fR[\fB\-\fR\fIn\fR] \fB\-fdump\-tree\-pre\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-ccp\fR[\fB\-\fR\fIn\fR] \fB\-fdump\-tree\-dce\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-gimple\fR[\fB\-raw\fR] \fB\-fdump\-tree\-mudflap\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-dom\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-dse\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-phiprop\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-phiopt\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-forwprop\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-copyrename\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-nrv \-fdump\-tree\-vect
-\&\-fdump\-tree\-sink
-\&\-fdump\-tree\-sra\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-forwprop\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-fre\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-vrp\fR[\fB\-\fR\fIn\fR]
-\&\fB\-ftree\-vectorizer\-verbose=\fR\fIn\fR
-\&\fB\-fdump\-tree\-storeccp\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-final\-insns=\fR\fIfile\fR
-\&\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR] \fB\-fcompare\-debug\-second
-\&\-feliminate\-dwarf2\-dups \-feliminate\-unused\-debug\-types
-\&\-feliminate\-unused\-debug\-symbols \-femit\-class\-debug\-always
-\&\-fenable\-icf\-debug
-\&\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR
-\&\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR
-\&\fB\-fdebug\-types\-section
-\&\-fmem\-report \-fpre\-ipa\-mem\-report \-fpost\-ipa\-mem\-report \-fprofile\-arcs
-\&\-frandom\-seed=\fR\fIstring\fR \fB\-fsched\-verbose=\fR\fIn\fR
-\&\fB\-fsel\-sched\-verbose \-fsel\-sched\-dump\-cfg \-fsel\-sched\-pipelining\-verbose
-\&\-fstack\-usage \-ftest\-coverage \-ftime\-report \-fvar\-tracking
-\&\-fvar\-tracking\-assignments \-fvar\-tracking\-assignments\-toggle
-\&\-g \-g\fR\fIlevel\fR \fB\-gtoggle \-gcoff \-gdwarf\-\fR\fIversion\fR
-\&\fB\-ggdb \-gmlt \-gstabs \-gstabs+ \-gstrict\-dwarf \-gno\-strict\-dwarf
-\&\-gvms \-gxcoff \-gxcoff+
-\&\-fno\-merge\-debug\-strings \-fno\-dwarf2\-cfi\-asm
-\&\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR
-\&\fB\-femit\-struct\-debug\-baseonly \-femit\-struct\-debug\-reduced
-\&\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR]
-\&\fB\-p \-pg \-print\-file\-name=\fR\fIlibrary\fR \fB\-print\-libgcc\-file\-name
-\&\-print\-multi\-directory \-print\-multi\-lib \-print\-multi\-os\-directory
-\&\-print\-prog\-name=\fR\fIprogram\fR \fB\-print\-search\-dirs \-Q
-\&\-print\-sysroot \-print\-sysroot\-headers\-suffix
-\&\-save\-temps \-save\-temps=cwd \-save\-temps=obj \-time\fR[\fB=\fR\fIfile\fR]
-.IP "\fIOptimization Options\fR" 4
-.IX Item "Optimization Options"
-\&\fB\-falign\-functions[=\fR\fIn\fR\fB] \-falign\-jumps[=\fR\fIn\fR\fB]
-\&\-falign\-labels[=\fR\fIn\fR\fB] \-falign\-loops[=\fR\fIn\fR\fB] \-fassociative\-math
-\&\-fauto\-inc\-dec \-fbranch\-probabilities \-fbranch\-target\-load\-optimize
-\&\-fbranch\-target\-load\-optimize2 \-fbtr\-bb\-exclusive \-fcaller\-saves
-\&\-fcallgraph\-profiles\-sections \-fcheck\-data\-deps \-fclone\-hot\-version\-paths
-\&\-fcombine\-stack\-adjustments \-fconserve\-stack
-\&\-fcompare\-elim \-fcprop\-registers \-fcrossjumping
-\&\-fcse\-follow\-jumps \-fcse\-skip\-blocks \-fcx\-fortran\-rules
-\&\-fcx\-limited\-range
-\&\-fdata\-sections \-fdce \-fdce \-fdelayed\-branch
-\&\-fdelete\-null\-pointer\-checks \-fdse \-fdevirtualize \-fdse
-\&\-fearly\-inlining \-fipa\-sra \-fexpensive\-optimizations \-ffast\-math
-\&\-ffinite\-math\-only \-ffloat\-store \-fexcess\-precision=\fR\fIstyle\fR
-\&\fB\-fforward\-propagate \-ffp\-contract=\fR\fIstyle\fR \fB\-ffunction\-sections
-\&\-fgcse \-fgcse\-after\-reload \-fgcse\-las \-fgcse\-lm \-fgraphite\-identity
-\&\-fgcse\-sm \-fif\-conversion \-fif\-conversion2 \-findirect\-inlining
-\&\-finline\-functions \-finline\-functions\-called\-once \-finline\-limit=\fR\fIn\fR
-\&\fB\-finline\-small\-functions \-fipa\-cp \-fipa\-cp\-clone \-fipa\-matrix\-reorg
-\&\-fipa\-pta \-fipa\-profile \-fipa\-pure\-const \-fipa\-reference
-\&\-fipa\-struct\-reorg \-fira\-algorithm=\fR\fIalgorithm\fR
-\&\fB\-fira\-region=\fR\fIregion\fR
-\&\fB\-fira\-loop\-pressure \-fno\-ira\-share\-save\-slots
-\&\-fno\-ira\-share\-spill\-slots \-fira\-verbose=\fR\fIn\fR
-\&\fB\-fivopts \-fkeep\-inline\-functions \-fkeep\-static\-consts
-\&\-floop\-block \-floop\-flatten \-floop\-interchange \-floop\-strip\-mine
-\&\-floop\-parallelize\-all \-flto \-flto\-compression\-level
-\&\-flto\-partition=\fR\fIalg\fR \fB\-flto\-report \-fmerge\-all\-constants
-\&\-fmerge\-constants \-fmodulo\-sched \-fmodulo\-sched\-allow\-regmoves
-\&\-fmove\-loop\-invariants fmudflap \-fmudflapir \-fmudflapth \-fno\-branch\-count\-reg
-\&\-fno\-default\-inline
-\&\-fno\-defer\-pop \-fno\-function\-cse \-fno\-guess\-branch\-probability
-\&\-fno\-inline \-fno\-math\-errno \-fno\-peephole \-fno\-peephole2
-\&\-fno\-sched\-interblock \-fno\-sched\-spec \-fno\-signed\-zeros
-\&\-fno\-toplevel\-reorder \-fno\-trapping\-math \-fno\-zero\-initialized\-in\-bss
-\&\-fomit\-frame\-pointer \-foptimize\-register\-move \-foptimize\-sibling\-calls
-\&\-fpartial\-inlining \-fpeel\-loops \-fpredictive\-commoning
-\&\-fprefetch\-loop\-arrays
-\&\-fprofile\-correction \-fprofile\-dir=\fR\fIpath\fR \fB\-fprofile\-generate
-\&\-fprofile\-generate=\fR\fIpath\fR \fB\-fprofile\-generate\-sampling
-\&\-fprofile\-use \-fprofile\-use=\fR\fIpath\fR \fB\-fprofile\-values
-\&\-fpmu\-profile\-generate=\fR\fIpmuoption\fR
-\&\fB\-fpmu\-profile\-use=\fR\fIpmuoption\fR
-\&\fB\-freciprocal\-math \-fregmove \-frename\-registers \-freorder\-blocks
-\&\-frecord\-gcc\-switches\-in\-elf
-\&\-freorder\-blocks\-and\-partition \-freorder\-functions
-\&\-frerun\-cse\-after\-loop \-freschedule\-modulo\-scheduled\-loops
-\&\-fripa \-fripa\-disallow\-asm\-modules \-fripa\-disallow\-opt\-mismatch
-\&\-fripa\-no\-promote\-always\-inline\-func \-fripa\-verbose
-\&\-fripa\-peel\-size\-limit \-fripa\-unroll\-size\-limit \-frounding\-math
-\&\-fsched2\-use\-superblocks \-fsched\-pressure
-\&\-fsched\-spec\-load \-fsched\-spec\-load\-dangerous
-\&\-fsched\-stalled\-insns\-dep[=\fR\fIn\fR\fB] \-fsched\-stalled\-insns[=\fR\fIn\fR\fB]
-\&\-fsched\-group\-heuristic \-fsched\-critical\-path\-heuristic
-\&\-fsched\-spec\-insn\-heuristic \-fsched\-rank\-heuristic
-\&\-fsched\-last\-insn\-heuristic \-fsched\-dep\-count\-heuristic
-\&\-fschedule\-insns \-fschedule\-insns2 \-fsection\-anchors
-\&\-fselective\-scheduling \-fselective\-scheduling2
-\&\-fsel\-sched\-pipelining \-fsel\-sched\-pipelining\-outer\-loops
-\&\-fsignaling\-nans \-fsingle\-precision\-constant \-fsplit\-ivs\-in\-unroller
-\&\-fsplit\-wide\-types \-fstack\-protector \-fstack\-protector\-all
-\&\-fstack\-protector\-strong \-fstrict\-aliasing \-fstrict\-overflow
-\&\-fthread\-jumps \-ftracer \-ftree\-bit\-ccp
-\&\-ftree\-builtin\-call\-dce \-ftree\-ccp \-ftree\-ch \-ftree\-copy\-prop
-\&\-ftree\-copyrename \-ftree\-dce \-ftree\-dominator\-opts \-ftree\-dse
-\&\-ftree\-forwprop \-ftree\-fre \-ftree\-loop\-if\-convert
-\&\-ftree\-loop\-if\-convert\-stores \-ftree\-loop\-im
-\&\-ftree\-phiprop \-ftree\-loop\-distribution \-ftree\-loop\-distribute\-patterns
-\&\-ftree\-loop\-ivcanon \-ftree\-loop\-linear \-ftree\-loop\-optimize
-\&\-ftree\-parallelize\-loops=\fR\fIn\fR \fB\-ftree\-pre \-ftree\-pta \-ftree\-reassoc
-\&\-ftree\-sink \-ftree\-sra \-ftree\-switch\-conversion
-\&\-ftree\-ter \-ftree\-vect\-loop\-version \-ftree\-vectorize \-ftree\-vrp
-\&\-funit\-at\-a\-time \-funroll\-all\-loops \-funroll\-loops
-\&\-funsafe\-loop\-optimizations \-funsafe\-math\-optimizations \-funswitch\-loops
-\&\-fvariable\-expansion\-in\-unroller \-fvect\-cost\-model \-fvpt \-fweb
-\&\-fwhole\-program \-fwpa \-fuse\-ld \-fuse\-linker\-plugin
-\&\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR
-\&\fB\-O \-O0 \-O1 \-O2 \-O3 \-Os \-Ofast\fR
-.IP "\fIPreprocessor Options\fR" 4
-.IX Item "Preprocessor Options"
-\&\fB\-A\fR\fIquestion\fR\fB=\fR\fIanswer\fR
-\&\fB\-A\-\fR\fIquestion\fR[\fB=\fR\fIanswer\fR]
-\&\fB\-C \-dD \-dI \-dM \-dN
-\&\-D\fR\fImacro\fR[\fB=\fR\fIdefn\fR] \fB\-E \-H
-\&\-idirafter\fR \fIdir\fR
-\&\fB\-include\fR \fIfile\fR \fB\-imacros\fR \fIfile\fR
-\&\fB\-iprefix\fR \fIfile\fR \fB\-iwithprefix\fR \fIdir\fR
-\&\fB\-iwithprefixbefore\fR \fIdir\fR \fB\-isystem\fR \fIdir\fR
-\&\fB\-imultilib\fR \fIdir\fR \fB\-isysroot\fR \fIdir\fR
-\&\fB\-M \-MM \-MF \-MG \-MP \-MQ \-MT \-nostdinc
-\&\-P \-fworking\-directory \-remap
-\&\-trigraphs \-undef \-U\fR\fImacro\fR \fB\-Wp,\fR\fIoption\fR
-\&\fB\-Xpreprocessor\fR \fIoption\fR
-.IP "\fIAssembler Option\fR" 4
-.IX Item "Assembler Option"
-\&\fB\-Wa,\fR\fIoption\fR \fB\-Xassembler\fR \fIoption\fR
-.IP "\fILinker Options\fR" 4
-.IX Item "Linker Options"
-\&\fIobject-file-name\fR \fB\-l\fR\fIlibrary\fR
-\&\fB\-nostartfiles \-nodefaultlibs \-nostdlib \-pie \-rdynamic
-\&\-s \-static \-static\-libgcc \-static\-libstdc++ \-shared
-\&\-shared\-libgcc \-symbolic
-\&\-T\fR \fIscript\fR \fB\-Wl,\fR\fIoption\fR \fB\-Xlinker\fR \fIoption\fR
-\&\fB\-u\fR \fIsymbol\fR
-.IP "\fIDirectory Options\fR" 4
-.IX Item "Directory Options"
-\&\fB\-B\fR\fIprefix\fR \fB\-I\fR\fIdir\fR \fB\-iplugindir=\fR\fIdir\fR
-\&\-iquote\fIdir\fR \-L\fIdir\fR \-specs=\fIfile\fR \-I\-
-\&\-\-sysroot=\fIdir\fR
-.IP "\fIMachine Dependent Options\fR" 4
-.IX Item "Machine Dependent Options"
-\&\fI\s-1ARC\s0 Options\fR
-\&\fB\-EB \-EL
-\&\-mmangle\-cpu \-mcpu=\fR\fIcpu\fR \fB\-mtext=\fR\fItext-section\fR
-\&\fB\-mdata=\fR\fIdata-section\fR \fB\-mrodata=\fR\fIreadonly-data-section\fR
-.Sp
-\&\fI\s-1ARM\s0 Options\fR
-\&\fB\-mapcs\-frame \-mno\-apcs\-frame
-\&\-mabi=\fR\fIname\fR
-\&\fB\-mapcs\-stack\-check \-mno\-apcs\-stack\-check
-\&\-mapcs\-float \-mno\-apcs\-float
-\&\-mapcs\-reentrant \-mno\-apcs\-reentrant
-\&\-msched\-prolog \-mno\-sched\-prolog
-\&\-mlittle\-endian \-mbig\-endian \-mwords\-little\-endian
-\&\-mfloat\-abi=\fR\fIname\fR \fB\-msoft\-float \-mhard\-float \-mfpe
-\&\-mfp16\-format=\fR\fIname\fR
-\&\fB\-mthumb\-interwork \-mno\-thumb\-interwork
-\&\-mcpu=\fR\fIname\fR \fB\-march=\fR\fIname\fR \fB\-mfpu=\fR\fIname\fR
-\&\fB\-mstructure\-size\-boundary=\fR\fIn\fR
-\&\fB\-mabort\-on\-noreturn
-\&\-mlong\-calls \-mno\-long\-calls
-\&\-msingle\-pic\-base \-mno\-single\-pic\-base
-\&\-mpic\-register=\fR\fIreg\fR
-\&\fB\-mnop\-fun\-dllimport
-\&\-mcirrus\-fix\-invalid\-insns \-mno\-cirrus\-fix\-invalid\-insns
-\&\-mpoke\-function\-name
-\&\-mthumb \-marm
-\&\-mtpcs\-frame \-mtpcs\-leaf\-frame
-\&\-mcaller\-super\-interworking \-mcallee\-super\-interworking
-\&\-mtp=\fR\fIname\fR
-\&\fB\-mword\-relocations
-\&\-mfix\-cortex\-m3\-ldrd\fR
-.Sp
-\&\fI\s-1AVR\s0 Options\fR
-\&\fB\-mmcu=\fR\fImcu\fR \fB\-mno\-interrupts
-\&\-mcall\-prologues \-mtiny\-stack \-mint8\fR
-.Sp
-\&\fIBlackfin Options\fR
-\&\fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR]
-\&\fB\-msim \-momit\-leaf\-frame\-pointer \-mno\-omit\-leaf\-frame\-pointer
-\&\-mspecld\-anomaly \-mno\-specld\-anomaly \-mcsync\-anomaly \-mno\-csync\-anomaly
-\&\-mlow\-64k \-mno\-low64k \-mstack\-check\-l1 \-mid\-shared\-library
-\&\-mno\-id\-shared\-library \-mshared\-library\-id=\fR\fIn\fR
-\&\fB\-mleaf\-id\-shared\-library \-mno\-leaf\-id\-shared\-library
-\&\-msep\-data \-mno\-sep\-data \-mlong\-calls \-mno\-long\-calls
-\&\-mfast\-fp \-minline\-plt \-mmulticore \-mcorea \-mcoreb \-msdram
-\&\-micplb\fR
-.Sp
-\&\fI\s-1CRIS\s0 Options\fR
-\&\fB\-mcpu=\fR\fIcpu\fR \fB\-march=\fR\fIcpu\fR \fB\-mtune=\fR\fIcpu\fR
-\&\fB\-mmax\-stack\-frame=\fR\fIn\fR \fB\-melinux\-stacksize=\fR\fIn\fR
-\&\fB\-metrax4 \-metrax100 \-mpdebug \-mcc\-init \-mno\-side\-effects
-\&\-mstack\-align \-mdata\-align \-mconst\-align
-\&\-m32\-bit \-m16\-bit \-m8\-bit \-mno\-prologue\-epilogue \-mno\-gotplt
-\&\-melf \-maout \-melinux \-mlinux \-sim \-sim2
-\&\-mmul\-bug\-workaround \-mno\-mul\-bug\-workaround\fR
-.Sp
-\&\fI\s-1CRX\s0 Options\fR
-\&\fB\-mmac \-mpush\-args\fR
-.Sp
-\&\fIDarwin Options\fR
-\&\fB\-all_load \-allowable_client \-arch \-arch_errors_fatal
-\&\-arch_only \-bind_at_load \-bundle \-bundle_loader
-\&\-client_name \-compatibility_version \-current_version
-\&\-dead_strip
-\&\-dependency\-file \-dylib_file \-dylinker_install_name
-\&\-dynamic \-dynamiclib \-exported_symbols_list
-\&\-filelist \-flat_namespace \-force_cpusubtype_ALL
-\&\-force_flat_namespace \-headerpad_max_install_names
-\&\-iframework
-\&\-image_base \-init \-install_name \-keep_private_externs
-\&\-multi_module \-multiply_defined \-multiply_defined_unused
-\&\-noall_load \-no_dead_strip_inits_and_terms
-\&\-nofixprebinding \-nomultidefs \-noprebind \-noseglinkedit
-\&\-pagezero_size \-prebind \-prebind_all_twolevel_modules
-\&\-private_bundle \-read_only_relocs \-sectalign
-\&\-sectobjectsymbols \-whyload \-seg1addr
-\&\-sectcreate \-sectobjectsymbols \-sectorder
-\&\-segaddr \-segs_read_only_addr \-segs_read_write_addr
-\&\-seg_addr_table \-seg_addr_table_filename \-seglinkedit
-\&\-segprot \-segs_read_only_addr \-segs_read_write_addr
-\&\-single_module \-static \-sub_library \-sub_umbrella
-\&\-twolevel_namespace \-umbrella \-undefined
-\&\-unexported_symbols_list \-weak_reference_mismatches
-\&\-whatsloaded \-F \-gused \-gfull \-mmacosx\-version\-min=\fR\fIversion\fR
-\&\fB\-mkernel \-mone\-byte\-bool\fR
-.Sp
-\&\fI\s-1DEC\s0 Alpha Options\fR
-\&\fB\-mno\-fp\-regs \-msoft\-float \-malpha\-as \-mgas
-\&\-mieee \-mieee\-with\-inexact \-mieee\-conformant
-\&\-mfp\-trap\-mode=\fR\fImode\fR \fB\-mfp\-rounding\-mode=\fR\fImode\fR
-\&\fB\-mtrap\-precision=\fR\fImode\fR \fB\-mbuild\-constants
-\&\-mcpu=\fR\fIcpu-type\fR \fB\-mtune=\fR\fIcpu-type\fR
-\&\fB\-mbwx \-mmax \-mfix \-mcix
-\&\-mfloat\-vax \-mfloat\-ieee
-\&\-mexplicit\-relocs \-msmall\-data \-mlarge\-data
-\&\-msmall\-text \-mlarge\-text
-\&\-mmemory\-latency=\fR\fItime\fR
-.Sp
-\&\fI\s-1DEC\s0 Alpha/VMS Options\fR
-\&\fB\-mvms\-return\-codes \-mdebug\-main=\fR\fIprefix\fR \fB\-mmalloc64\fR
-.Sp
-\&\fI\s-1FR30\s0 Options\fR
-\&\fB\-msmall\-model \-mno\-lsim\fR
-.Sp
-\&\fI\s-1FRV\s0 Options\fR
-\&\fB\-mgpr\-32 \-mgpr\-64 \-mfpr\-32 \-mfpr\-64
-\&\-mhard\-float \-msoft\-float
-\&\-malloc\-cc \-mfixed\-cc \-mdword \-mno\-dword
-\&\-mdouble \-mno\-double
-\&\-mmedia \-mno\-media \-mmuladd \-mno\-muladd
-\&\-mfdpic \-minline\-plt \-mgprel\-ro \-multilib\-library\-pic
-\&\-mlinked\-fp \-mlong\-calls \-malign\-labels
-\&\-mlibrary\-pic \-macc\-4 \-macc\-8
-\&\-mpack \-mno\-pack \-mno\-eflags \-mcond\-move \-mno\-cond\-move
-\&\-moptimize\-membar \-mno\-optimize\-membar
-\&\-mscc \-mno\-scc \-mcond\-exec \-mno\-cond\-exec
-\&\-mvliw\-branch \-mno\-vliw\-branch
-\&\-mmulti\-cond\-exec \-mno\-multi\-cond\-exec \-mnested\-cond\-exec
-\&\-mno\-nested\-cond\-exec \-mtomcat\-stats
-\&\-mTLS \-mtls
-\&\-mcpu=\fR\fIcpu\fR
-.Sp
-\&\fIGNU/Linux Options\fR
-\&\fB\-mglibc \-muclibc \-mbionic \-mandroid
-\&\-tno\-android\-cc \-tno\-android\-ld\fR
-.Sp
-\&\fIH8/300 Options\fR
-\&\fB\-mrelax \-mh \-ms \-mn \-mint32 \-malign\-300\fR
-.Sp
-\&\fI\s-1HPPA\s0 Options\fR
-\&\fB\-march=\fR\fIarchitecture-type\fR
-\&\fB\-mbig\-switch \-mdisable\-fpregs \-mdisable\-indexing
-\&\-mfast\-indirect\-calls \-mgas \-mgnu\-ld \-mhp\-ld
-\&\-mfixed\-range=\fR\fIregister-range\fR
-\&\fB\-mjump\-in\-delay \-mlinker\-opt \-mlong\-calls
-\&\-mlong\-load\-store \-mno\-big\-switch \-mno\-disable\-fpregs
-\&\-mno\-disable\-indexing \-mno\-fast\-indirect\-calls \-mno\-gas
-\&\-mno\-jump\-in\-delay \-mno\-long\-load\-store
-\&\-mno\-portable\-runtime \-mno\-soft\-float
-\&\-mno\-space\-regs \-msoft\-float \-mpa\-risc\-1\-0
-\&\-mpa\-risc\-1\-1 \-mpa\-risc\-2\-0 \-mportable\-runtime
-\&\-mschedule=\fR\fIcpu-type\fR \fB\-mspace\-regs \-msio \-mwsio
-\&\-munix=\fR\fIunix-std\fR \fB\-nolibdld \-static \-threads\fR
-.Sp
-\&\fIi386 and x86\-64 Options\fR
-\&\fB\-mtune=\fR\fIcpu-type\fR \fB\-march=\fR\fIcpu-type\fR
-\&\fB\-mfpmath=\fR\fIunit\fR
-\&\fB\-masm=\fR\fIdialect\fR \fB\-mno\-fancy\-math\-387
-\&\-mno\-fp\-ret\-in\-387 \-msoft\-float
-\&\-mno\-wide\-multiply \-mrtd \-malign\-double
-\&\-mpreferred\-stack\-boundary=\fR\fInum\fR
-\&\fB\-mincoming\-stack\-boundary=\fR\fInum\fR
-\&\fB\-mcld \-mcx16 \-msahf \-mmovbe \-mcrc32 \-mrecip \-mvzeroupper
-\&\-mmmx \-msse \-msse2 \-msse3 \-mssse3 \-msse4.1 \-msse4.2 \-msse4 \-mavx
-\&\-maes \-mpclmul \-mfsgsbase \-mrdrnd \-mf16c \-mfused\-madd
-\&\-msse4a \-m3dnow \-mpopcnt \-mabm \-mbmi \-mtbm \-mfma4 \-mxop \-mlwp
-\&\-mthreads \-mno\-align\-stringops \-minline\-all\-stringops
-\&\-minline\-stringops\-dynamically \-mstringop\-strategy=\fR\fIalg\fR
-\&\fB\-mpush\-args \-maccumulate\-outgoing\-args \-m128bit\-long\-double
-\&\-m96bit\-long\-double \-mregparm=\fR\fInum\fR \fB\-msseregparm
-\&\-mveclibabi=\fR\fItype\fR \fB\-mvect8\-ret\-in\-mem
-\&\-mpc32 \-mpc64 \-mpc80 \-mstackrealign
-\&\-momit\-leaf\-frame\-pointer \-mno\-red\-zone \-mno\-tls\-direct\-seg\-refs
-\&\-mcmodel=\fR\fIcode-model\fR \fB\-mabi=\fR\fIname\fR
-\&\fB\-m32 \-m64 \-mlarge\-data\-threshold=\fR\fInum\fR
-\&\fB\-msse2avx \-mfentry \-m8bit\-idiv
-\&\-mavx256\-split\-unaligned\-load \-mavx256\-split\-unaligned\-store\fR
-.Sp
-\&\fIi386 and x86\-64 Windows Options\fR
-\&\fB\-mconsole \-mcygwin \-mno\-cygwin \-mdll
-\&\-mnop\-fun\-dllimport \-mthread
-\&\-municode \-mwin32 \-mwindows \-fno\-set\-stack\-executable\fR
-.Sp
-\&\fI\s-1IA\-64\s0 Options\fR
-\&\fB\-mbig\-endian \-mlittle\-endian \-mgnu\-as \-mgnu\-ld \-mno\-pic
-\&\-mvolatile\-asm\-stop \-mregister\-names \-msdata \-mno\-sdata
-\&\-mconstant\-gp \-mauto\-pic \-mfused\-madd
-\&\-minline\-float\-divide\-min\-latency
-\&\-minline\-float\-divide\-max\-throughput
-\&\-mno\-inline\-float\-divide
-\&\-minline\-int\-divide\-min\-latency
-\&\-minline\-int\-divide\-max\-throughput
-\&\-mno\-inline\-int\-divide
-\&\-minline\-sqrt\-min\-latency \-minline\-sqrt\-max\-throughput
-\&\-mno\-inline\-sqrt
-\&\-mdwarf2\-asm \-mearly\-stop\-bits
-\&\-mfixed\-range=\fR\fIregister-range\fR \fB\-mtls\-size=\fR\fItls-size\fR
-\&\fB\-mtune=\fR\fIcpu-type\fR \fB\-milp32 \-mlp64
-\&\-msched\-br\-data\-spec \-msched\-ar\-data\-spec \-msched\-control\-spec
-\&\-msched\-br\-in\-data\-spec \-msched\-ar\-in\-data\-spec \-msched\-in\-control\-spec
-\&\-msched\-spec\-ldc \-msched\-spec\-control\-ldc
-\&\-msched\-prefer\-non\-data\-spec\-insns \-msched\-prefer\-non\-control\-spec\-insns
-\&\-msched\-stop\-bits\-after\-every\-cycle \-msched\-count\-spec\-in\-critical\-path
-\&\-msel\-sched\-dont\-check\-control\-spec \-msched\-fp\-mem\-deps\-zero\-cost
-\&\-msched\-max\-memory\-insns\-hard\-limit \-msched\-max\-memory\-insns=\fR\fImax-insns\fR
-.Sp
-\&\fI\s-1IA\-64/VMS\s0 Options\fR
-\&\fB\-mvms\-return\-codes \-mdebug\-main=\fR\fIprefix\fR \fB\-mmalloc64\fR
-.Sp
-\&\fI\s-1LM32\s0 Options\fR
-\&\fB\-mbarrel\-shift\-enabled \-mdivide\-enabled \-mmultiply\-enabled
-\&\-msign\-extend\-enabled \-muser\-enabled\fR
-.Sp
-\&\fIM32R/D Options\fR
-\&\fB\-m32r2 \-m32rx \-m32r
-\&\-mdebug
-\&\-malign\-loops \-mno\-align\-loops
-\&\-missue\-rate=\fR\fInumber\fR
-\&\fB\-mbranch\-cost=\fR\fInumber\fR
-\&\fB\-mmodel=\fR\fIcode-size-model-type\fR
-\&\fB\-msdata=\fR\fIsdata-type\fR
-\&\fB\-mno\-flush\-func \-mflush\-func=\fR\fIname\fR
-\&\fB\-mno\-flush\-trap \-mflush\-trap=\fR\fInumber\fR
-\&\fB\-G\fR \fInum\fR
-.Sp
-\&\fIM32C Options\fR
-\&\fB\-mcpu=\fR\fIcpu\fR \fB\-msim \-memregs=\fR\fInumber\fR
-.Sp
-\&\fIM680x0 Options\fR
-\&\fB\-march=\fR\fIarch\fR \fB\-mcpu=\fR\fIcpu\fR \fB\-mtune=\fR\fItune\fR
-\&\fB\-m68000 \-m68020 \-m68020\-40 \-m68020\-60 \-m68030 \-m68040
-\&\-m68060 \-mcpu32 \-m5200 \-m5206e \-m528x \-m5307 \-m5407
-\&\-mcfv4e \-mbitfield \-mno\-bitfield \-mc68000 \-mc68020
-\&\-mnobitfield \-mrtd \-mno\-rtd \-mdiv \-mno\-div \-mshort
-\&\-mno\-short \-mhard\-float \-m68881 \-msoft\-float \-mpcrel
-\&\-malign\-int \-mstrict\-align \-msep\-data \-mno\-sep\-data
-\&\-mshared\-library\-id=n \-mid\-shared\-library \-mno\-id\-shared\-library
-\&\-mxgot \-mno\-xgot\fR
-.Sp
-\&\fIM68hc1x Options\fR
-\&\fB\-m6811 \-m6812 \-m68hc11 \-m68hc12 \-m68hcs12
-\&\-mauto\-incdec \-minmax \-mlong\-calls \-mshort
-\&\-msoft\-reg\-count=\fR\fIcount\fR
-.Sp
-\&\fIMCore Options\fR
-\&\fB\-mhardlit \-mno\-hardlit \-mdiv \-mno\-div \-mrelax\-immediates
-\&\-mno\-relax\-immediates \-mwide\-bitfields \-mno\-wide\-bitfields
-\&\-m4byte\-functions \-mno\-4byte\-functions \-mcallgraph\-data
-\&\-mno\-callgraph\-data \-mslow\-bytes \-mno\-slow\-bytes \-mno\-lsim
-\&\-mlittle\-endian \-mbig\-endian \-m210 \-m340 \-mstack\-increment\fR
-.Sp
-\&\fIMeP Options\fR
-\&\fB\-mabsdiff \-mall\-opts \-maverage \-mbased=\fR\fIn\fR \fB\-mbitops
-\&\-mc=\fR\fIn\fR \fB\-mclip \-mconfig=\fR\fIname\fR \fB\-mcop \-mcop32 \-mcop64 \-mivc2
-\&\-mdc \-mdiv \-meb \-mel \-mio\-volatile \-ml \-mleadz \-mm \-mminmax
-\&\-mmult \-mno\-opts \-mrepeat \-ms \-msatur \-msdram \-msim \-msimnovec \-mtf
-\&\-mtiny=\fR\fIn\fR
-.Sp
-\&\fIMicroBlaze Options\fR
-\&\fB\-msoft\-float \-mhard\-float \-msmall\-divides \-mcpu=\fR\fIcpu\fR
-\&\fB\-mmemcpy \-mxl\-soft\-mul \-mxl\-soft\-div \-mxl\-barrel\-shift
-\&\-mxl\-pattern\-compare \-mxl\-stack\-check \-mxl\-gp\-opt \-mno\-clearbss
-\&\-mxl\-multiply\-high \-mxl\-float\-convert \-mxl\-float\-sqrt
-\&\-mxl\-mode\-\fR\fIapp-model\fR
-.Sp
-\&\fI\s-1MIPS\s0 Options\fR
-\&\fB\-EL \-EB \-march=\fR\fIarch\fR \fB\-mtune=\fR\fIarch\fR
-\&\fB\-mips1 \-mips2 \-mips3 \-mips4 \-mips32 \-mips32r2
-\&\-mips64 \-mips64r2
-\&\-mips16 \-mno\-mips16 \-mflip\-mips16
-\&\-minterlink\-mips16 \-mno\-interlink\-mips16
-\&\-mabi=\fR\fIabi\fR \fB\-mabicalls \-mno\-abicalls
-\&\-mshared \-mno\-shared \-mplt \-mno\-plt \-mxgot \-mno\-xgot
-\&\-mgp32 \-mgp64 \-mfp32 \-mfp64 \-mhard\-float \-msoft\-float
-\&\-msingle\-float \-mdouble\-float \-mdsp \-mno\-dsp \-mdspr2 \-mno\-dspr2
-\&\-mfpu=\fR\fIfpu-type\fR
-\&\fB\-msmartmips \-mno\-smartmips
-\&\-mpaired\-single \-mno\-paired\-single \-mdmx \-mno\-mdmx
-\&\-mips3d \-mno\-mips3d \-mmt \-mno\-mt \-mllsc \-mno\-llsc
-\&\-mlong64 \-mlong32 \-msym32 \-mno\-sym32
-\&\-G\fR\fInum\fR \fB\-mlocal\-sdata \-mno\-local\-sdata
-\&\-mextern\-sdata \-mno\-extern\-sdata \-mgpopt \-mno\-gopt
-\&\-membedded\-data \-mno\-embedded\-data
-\&\-muninit\-const\-in\-rodata \-mno\-uninit\-const\-in\-rodata
-\&\-mcode\-readable=\fR\fIsetting\fR
-\&\fB\-msplit\-addresses \-mno\-split\-addresses
-\&\-mexplicit\-relocs \-mno\-explicit\-relocs
-\&\-mcheck\-zero\-division \-mno\-check\-zero\-division
-\&\-mdivide\-traps \-mdivide\-breaks
-\&\-mmemcpy \-mno\-memcpy \-mlong\-calls \-mno\-long\-calls
-\&\-mmad \-mno\-mad \-mfused\-madd \-mno\-fused\-madd \-nocpp
-\&\-mfix\-r4000 \-mno\-fix\-r4000 \-mfix\-r4400 \-mno\-fix\-r4400
-\&\-mfix\-r10000 \-mno\-fix\-r10000 \-mfix\-vr4120 \-mno\-fix\-vr4120
-\&\-mfix\-vr4130 \-mno\-fix\-vr4130 \-mfix\-sb1 \-mno\-fix\-sb1
-\&\-mflush\-func=\fR\fIfunc\fR \fB\-mno\-flush\-func
-\&\-mbranch\-cost=\fR\fInum\fR \fB\-mbranch\-likely \-mno\-branch\-likely
-\&\-mfp\-exceptions \-mno\-fp\-exceptions
-\&\-mvr4130\-align \-mno\-vr4130\-align \-msynci \-mno\-synci
-\&\-mrelax\-pic\-calls \-mno\-relax\-pic\-calls \-mmcount\-ra\-address\fR
-.Sp
-\&\fI\s-1MMIX\s0 Options\fR
-\&\fB\-mlibfuncs \-mno\-libfuncs \-mepsilon \-mno\-epsilon \-mabi=gnu
-\&\-mabi=mmixware \-mzero\-extend \-mknuthdiv \-mtoplevel\-symbols
-\&\-melf \-mbranch\-predict \-mno\-branch\-predict \-mbase\-addresses
-\&\-mno\-base\-addresses \-msingle\-exit \-mno\-single\-exit\fR
-.Sp
-\&\fI\s-1MN10300\s0 Options\fR
-\&\fB\-mmult\-bug \-mno\-mult\-bug
-\&\-mno\-am33 \-mam33 \-mam33\-2 \-mam34
-\&\-mtune=\fR\fIcpu-type\fR
-\&\fB\-mreturn\-pointer\-on\-d0
-\&\-mno\-crt0 \-mrelax \-mliw\fR
-.Sp
-\&\fI\s-1PDP\-11\s0 Options\fR
-\&\fB\-mfpu \-msoft\-float \-mac0 \-mno\-ac0 \-m40 \-m45 \-m10
-\&\-mbcopy \-mbcopy\-builtin \-mint32 \-mno\-int16
-\&\-mint16 \-mno\-int32 \-mfloat32 \-mno\-float64
-\&\-mfloat64 \-mno\-float32 \-mabshi \-mno\-abshi
-\&\-mbranch\-expensive \-mbranch\-cheap
-\&\-munix\-asm \-mdec\-asm\fR
-.Sp
-\&\fIpicoChip Options\fR
-\&\fB\-mae=\fR\fIae_type\fR \fB\-mvliw\-lookahead=\fR\fIN\fR
-\&\fB\-msymbol\-as\-address \-mno\-inefficient\-warnings\fR
-.Sp
-\&\fIPowerPC Options\fR
-See \s-1RS/6000\s0 and PowerPC Options.
-.Sp
-\&\fI\s-1RS/6000\s0 and PowerPC Options\fR
-\&\fB\-mcpu=\fR\fIcpu-type\fR
-\&\fB\-mtune=\fR\fIcpu-type\fR
-\&\fB\-mcmodel=\fR\fIcode-model\fR
-\&\fB\-mpower \-mno\-power \-mpower2 \-mno\-power2
-\&\-mpowerpc \-mpowerpc64 \-mno\-powerpc
-\&\-maltivec \-mno\-altivec
-\&\-mpowerpc\-gpopt \-mno\-powerpc\-gpopt
-\&\-mpowerpc\-gfxopt \-mno\-powerpc\-gfxopt
-\&\-mmfcrf \-mno\-mfcrf \-mpopcntb \-mno\-popcntb \-mpopcntd \-mno\-popcntd
-\&\-mfprnd \-mno\-fprnd
-\&\-mcmpb \-mno\-cmpb \-mmfpgpr \-mno\-mfpgpr \-mhard\-dfp \-mno\-hard\-dfp
-\&\-mnew\-mnemonics \-mold\-mnemonics
-\&\-mfull\-toc \-mminimal\-toc \-mno\-fp\-in\-toc \-mno\-sum\-in\-toc
-\&\-m64 \-m32 \-mxl\-compat \-mno\-xl\-compat \-mpe
-\&\-malign\-power \-malign\-natural
-\&\-msoft\-float \-mhard\-float \-mmultiple \-mno\-multiple
-\&\-msingle\-float \-mdouble\-float \-msimple\-fpu
-\&\-mstring \-mno\-string \-mupdate \-mno\-update
-\&\-mavoid\-indexed\-addresses \-mno\-avoid\-indexed\-addresses
-\&\-mfused\-madd \-mno\-fused\-madd \-mbit\-align \-mno\-bit\-align
-\&\-mstrict\-align \-mno\-strict\-align \-mrelocatable
-\&\-mno\-relocatable \-mrelocatable\-lib \-mno\-relocatable\-lib
-\&\-mtoc \-mno\-toc \-mlittle \-mlittle\-endian \-mbig \-mbig\-endian
-\&\-mdynamic\-no\-pic \-maltivec \-mswdiv \-msingle\-pic\-base
-\&\-mprioritize\-restricted\-insns=\fR\fIpriority\fR
-\&\fB\-msched\-costly\-dep=\fR\fIdependence_type\fR
-\&\fB\-minsert\-sched\-nops=\fR\fIscheme\fR
-\&\fB\-mcall\-sysv \-mcall\-netbsd
-\&\-maix\-struct\-return \-msvr4\-struct\-return
-\&\-mabi=\fR\fIabi-type\fR \fB\-msecure\-plt \-mbss\-plt
-\&\-mblock\-move\-inline\-limit=\fR\fInum\fR
-\&\fB\-misel \-mno\-isel
-\&\-misel=yes \-misel=no
-\&\-mspe \-mno\-spe
-\&\-mspe=yes \-mspe=no
-\&\-mpaired
-\&\-mgen\-cell\-microcode \-mwarn\-cell\-microcode
-\&\-mvrsave \-mno\-vrsave
-\&\-mmulhw \-mno\-mulhw
-\&\-mdlmzb \-mno\-dlmzb
-\&\-mfloat\-gprs=yes \-mfloat\-gprs=no \-mfloat\-gprs=single \-mfloat\-gprs=double
-\&\-mprototype \-mno\-prototype
-\&\-msim \-mmvme \-mads \-myellowknife \-memb \-msdata
-\&\-msdata=\fR\fIopt\fR \fB\-mvxworks \-G\fR \fInum\fR \fB\-pthread
-\&\-mrecip \-mrecip=\fR\fIopt\fR \fB\-mno\-recip \-mrecip\-precision
-\&\-mno\-recip\-precision
-\&\-mveclibabi=\fR\fItype\fR \fB\-mfriz \-mno\-friz\fR
-.Sp
-\&\fI\s-1RX\s0 Options\fR
-\&\fB\-m64bit\-doubles \-m32bit\-doubles \-fpu \-nofpu
-\&\-mcpu=
-\&\-mbig\-endian\-data \-mlittle\-endian\-data
-\&\-msmall\-data
-\&\-msim \-mno\-sim
-\&\-mas100\-syntax \-mno\-as100\-syntax
-\&\-mrelax
-\&\-mmax\-constant\-size=
-\&\-mint\-register=
-\&\-msave\-acc\-in\-interrupts\fR
-.Sp
-\&\fIS/390 and zSeries Options\fR
-\&\fB\-mtune=\fR\fIcpu-type\fR \fB\-march=\fR\fIcpu-type\fR
-\&\fB\-mhard\-float \-msoft\-float \-mhard\-dfp \-mno\-hard\-dfp
-\&\-mlong\-double\-64 \-mlong\-double\-128
-\&\-mbackchain \-mno\-backchain \-mpacked\-stack \-mno\-packed\-stack
-\&\-msmall\-exec \-mno\-small\-exec \-mmvcle \-mno\-mvcle
-\&\-m64 \-m31 \-mdebug \-mno\-debug \-mesa \-mzarch
-\&\-mtpf\-trace \-mno\-tpf\-trace \-mfused\-madd \-mno\-fused\-madd
-\&\-mwarn\-framesize \-mwarn\-dynamicstack \-mstack\-size \-mstack\-guard\fR
-.Sp
-\&\fIScore Options\fR
-\&\fB\-meb \-mel
-\&\-mnhwloop
-\&\-muls
-\&\-mmac
-\&\-mscore5 \-mscore5u \-mscore7 \-mscore7d\fR
-.Sp
-\&\fI\s-1SH\s0 Options\fR
-\&\fB\-m1 \-m2 \-m2e
-\&\-m2a\-nofpu \-m2a\-single\-only \-m2a\-single \-m2a
-\&\-m3 \-m3e
-\&\-m4\-nofpu \-m4\-single\-only \-m4\-single \-m4
-\&\-m4a\-nofpu \-m4a\-single\-only \-m4a\-single \-m4a \-m4al
-\&\-m5\-64media \-m5\-64media\-nofpu
-\&\-m5\-32media \-m5\-32media\-nofpu
-\&\-m5\-compact \-m5\-compact\-nofpu
-\&\-mb \-ml \-mdalign \-mrelax
-\&\-mbigtable \-mfmovd \-mhitachi \-mrenesas \-mno\-renesas \-mnomacsave
-\&\-mieee \-mbitops \-misize \-minline\-ic_invalidate \-mpadstruct \-mspace
-\&\-mprefergot \-musermode \-multcost=\fR\fInumber\fR \fB\-mdiv=\fR\fIstrategy\fR
-\&\fB\-mdivsi3_libfunc=\fR\fIname\fR \fB\-mfixed\-range=\fR\fIregister-range\fR
-\&\fB\-madjust\-unroll \-mindexed\-addressing \-mgettrcost=\fR\fInumber\fR \fB\-mpt\-fixed
-\&\-maccumulate\-outgoing\-args \-minvalid\-symbols\fR
-.Sp
-\&\fISolaris 2 Options\fR
-\&\fB\-mimpure\-text \-mno\-impure\-text
-\&\-threads \-pthreads \-pthread\fR
-.Sp
-\&\fI\s-1SPARC\s0 Options\fR
-\&\fB\-mcpu=\fR\fIcpu-type\fR
-\&\fB\-mtune=\fR\fIcpu-type\fR
-\&\fB\-mcmodel=\fR\fIcode-model\fR
-\&\fB\-m32 \-m64 \-mapp\-regs \-mno\-app\-regs
-\&\-mfaster\-structs \-mno\-faster\-structs
-\&\-mfpu \-mno\-fpu \-mhard\-float \-msoft\-float
-\&\-mhard\-quad\-float \-msoft\-quad\-float
-\&\-mlittle\-endian
-\&\-mstack\-bias \-mno\-stack\-bias
-\&\-munaligned\-doubles \-mno\-unaligned\-doubles
-\&\-mv8plus \-mno\-v8plus \-mvis \-mno\-vis
-\&\-mfix\-at697f\fR
-.Sp
-\&\fI\s-1SPU\s0 Options\fR
-\&\fB\-mwarn\-reloc \-merror\-reloc
-\&\-msafe\-dma \-munsafe\-dma
-\&\-mbranch\-hints
-\&\-msmall\-mem \-mlarge\-mem \-mstdmain
-\&\-mfixed\-range=\fR\fIregister-range\fR
-\&\fB\-mea32 \-mea64
-\&\-maddress\-space\-conversion \-mno\-address\-space\-conversion
-\&\-mcache\-size=\fR\fIcache-size\fR
-\&\fB\-matomic\-updates \-mno\-atomic\-updates\fR
-.Sp
-\&\fISystem V Options\fR
-\&\fB\-Qy \-Qn \-YP,\fR\fIpaths\fR \fB\-Ym,\fR\fIdir\fR
-.Sp
-\&\fIV850 Options\fR
-\&\fB\-mlong\-calls \-mno\-long\-calls \-mep \-mno\-ep
-\&\-mprolog\-function \-mno\-prolog\-function \-mspace
-\&\-mtda=\fR\fIn\fR \fB\-msda=\fR\fIn\fR \fB\-mzda=\fR\fIn\fR
-\&\fB\-mapp\-regs \-mno\-app\-regs
-\&\-mdisable\-callt \-mno\-disable\-callt
-\&\-mv850e2v3
-\&\-mv850e2
-\&\-mv850e1 \-mv850es
-\&\-mv850e
-\&\-mv850 \-mbig\-switch\fR
-.Sp
-\&\fI\s-1VAX\s0 Options\fR
-\&\fB\-mg \-mgnu \-munix\fR
-.Sp
-\&\fIVxWorks Options\fR
-\&\fB\-mrtp \-non\-static \-Bstatic \-Bdynamic
-\&\-Xbind\-lazy \-Xbind\-now\fR
-.Sp
-\&\fIx86\-64 Options\fR
-See i386 and x86\-64 Options.
-.Sp
-\&\fIXstormy16 Options\fR
-\&\fB\-msim\fR
-.Sp
-\&\fIXtensa Options\fR
-\&\fB\-mconst16 \-mno\-const16
-\&\-mfused\-madd \-mno\-fused\-madd
-\&\-mforce\-no\-pic
-\&\-mserialize\-volatile \-mno\-serialize\-volatile
-\&\-mtext\-section\-literals \-mno\-text\-section\-literals
-\&\-mtarget\-align \-mno\-target\-align
-\&\-mlongcalls \-mno\-longcalls\fR
-.Sp
-\&\fIzSeries Options\fR
-See S/390 and zSeries Options.
-.IP "\fICode Generation Options\fR" 4
-.IX Item "Code Generation Options"
-\&\fB\-fcall\-saved\-\fR\fIreg\fR \fB\-fcall\-used\-\fR\fIreg\fR
-\&\fB\-ffixed\-\fR\fIreg\fR \fB\-fexceptions
-\&\-fnon\-call\-exceptions \-funwind\-tables
-\&\-fasynchronous\-unwind\-tables
-\&\-finhibit\-size\-directive \-finstrument\-functions
-\&\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,...
-\&\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,...
-\&\-fno\-common \-fno\-ident
-\&\-fpcc\-struct\-return \-fpic \-fPIC \-fpie \-fPIE
-\&\-fno\-jump\-tables
-\&\-frecord\-gcc\-switches
-\&\-freg\-struct\-return \-fshort\-enums
-\&\-fshort\-double \-fshort\-wchar
-\&\-fverbose\-asm \-fpack\-struct[=\fR\fIn\fR\fB] \-fstack\-check
-\&\-fstack\-limit\-register=\fR\fIreg\fR \fB\-fstack\-limit\-symbol=\fR\fIsym\fR
-\&\fB\-fno\-stack\-limit \-fsplit\-stack
-\&\-fleading\-underscore \-ftls\-model=\fR\fImodel\fR
-\&\fB\-ftrapv \-fwrapv \-fbounds\-check
-\&\-fvisibility \-fstrict\-volatile\-bitfields\fR
-.SS "Options Controlling the Kind of Output"
-.IX Subsection "Options Controlling the Kind of Output"
-Compilation can involve up to four stages: preprocessing, compilation
-proper, assembly and linking, always in that order. \s-1GCC\s0 is capable of
-preprocessing and compiling several files either into several
-assembler input files, or into one assembler input file; then each
-assembler input file produces an object file, and linking combines all
-the object files (those newly compiled, and those specified as input)
-into an executable file.
-.PP
-For any given input file, the file name suffix determines what kind of
-compilation is done:
-.IP "\fIfile\fR\fB.c\fR" 4
-.IX Item "file.c"
-C source code which must be preprocessed.
-.IP "\fIfile\fR\fB.i\fR" 4
-.IX Item "file.i"
-C source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.ii\fR" 4
-.IX Item "file.ii"
-\&\*(C+ source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.m\fR" 4
-.IX Item "file.m"
-Objective-C source code. Note that you must link with the \fIlibobjc\fR
-library to make an Objective-C program work.
-.IP "\fIfile\fR\fB.mi\fR" 4
-.IX Item "file.mi"
-Objective-C source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.mm\fR" 4
-.IX Item "file.mm"
-.PD 0
-.IP "\fIfile\fR\fB.M\fR" 4
-.IX Item "file.M"
-.PD
-Objective\-\*(C+ source code. Note that you must link with the \fIlibobjc\fR
-library to make an Objective\-\*(C+ program work. Note that \fB.M\fR refers
-to a literal capital M.
-.IP "\fIfile\fR\fB.mii\fR" 4
-.IX Item "file.mii"
-Objective\-\*(C+ source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.h\fR" 4
-.IX Item "file.h"
-C, \*(C+, Objective-C or Objective\-\*(C+ header file to be turned into a
-precompiled header (default), or C, \*(C+ header file to be turned into an
-Ada spec (via the \fB\-fdump\-ada\-spec\fR switch).
-.IP "\fIfile\fR\fB.cc\fR" 4
-.IX Item "file.cc"
-.PD 0
-.IP "\fIfile\fR\fB.cp\fR" 4
-.IX Item "file.cp"
-.IP "\fIfile\fR\fB.cxx\fR" 4
-.IX Item "file.cxx"
-.IP "\fIfile\fR\fB.cpp\fR" 4
-.IX Item "file.cpp"
-.IP "\fIfile\fR\fB.CPP\fR" 4
-.IX Item "file.CPP"
-.IP "\fIfile\fR\fB.c++\fR" 4
-.IX Item "file.c++"
-.IP "\fIfile\fR\fB.C\fR" 4
-.IX Item "file.C"
-.PD
-\&\*(C+ source code which must be preprocessed. Note that in \fB.cxx\fR,
-the last two letters must both be literally \fBx\fR. Likewise,
-\&\fB.C\fR refers to a literal capital C.
-.IP "\fIfile\fR\fB.mm\fR" 4
-.IX Item "file.mm"
-.PD 0
-.IP "\fIfile\fR\fB.M\fR" 4
-.IX Item "file.M"
-.PD
-Objective\-\*(C+ source code which must be preprocessed.
-.IP "\fIfile\fR\fB.mii\fR" 4
-.IX Item "file.mii"
-Objective\-\*(C+ source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.hh\fR" 4
-.IX Item "file.hh"
-.PD 0
-.IP "\fIfile\fR\fB.H\fR" 4
-.IX Item "file.H"
-.IP "\fIfile\fR\fB.hp\fR" 4
-.IX Item "file.hp"
-.IP "\fIfile\fR\fB.hxx\fR" 4
-.IX Item "file.hxx"
-.IP "\fIfile\fR\fB.hpp\fR" 4
-.IX Item "file.hpp"
-.IP "\fIfile\fR\fB.HPP\fR" 4
-.IX Item "file.HPP"
-.IP "\fIfile\fR\fB.h++\fR" 4
-.IX Item "file.h++"
-.IP "\fIfile\fR\fB.tcc\fR" 4
-.IX Item "file.tcc"
-.PD
-\&\*(C+ header file to be turned into a precompiled header or Ada spec.
-.IP "\fIfile\fR\fB.f\fR" 4
-.IX Item "file.f"
-.PD 0
-.IP "\fIfile\fR\fB.for\fR" 4
-.IX Item "file.for"
-.IP "\fIfile\fR\fB.ftn\fR" 4
-.IX Item "file.ftn"
-.PD
-Fixed form Fortran source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.F\fR" 4
-.IX Item "file.F"
-.PD 0
-.IP "\fIfile\fR\fB.FOR\fR" 4
-.IX Item "file.FOR"
-.IP "\fIfile\fR\fB.fpp\fR" 4
-.IX Item "file.fpp"
-.IP "\fIfile\fR\fB.FPP\fR" 4
-.IX Item "file.FPP"
-.IP "\fIfile\fR\fB.FTN\fR" 4
-.IX Item "file.FTN"
-.PD
-Fixed form Fortran source code which must be preprocessed (with the traditional
-preprocessor).
-.IP "\fIfile\fR\fB.f90\fR" 4
-.IX Item "file.f90"
-.PD 0
-.IP "\fIfile\fR\fB.f95\fR" 4
-.IX Item "file.f95"
-.IP "\fIfile\fR\fB.f03\fR" 4
-.IX Item "file.f03"
-.IP "\fIfile\fR\fB.f08\fR" 4
-.IX Item "file.f08"
-.PD
-Free form Fortran source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.F90\fR" 4
-.IX Item "file.F90"
-.PD 0
-.IP "\fIfile\fR\fB.F95\fR" 4
-.IX Item "file.F95"
-.IP "\fIfile\fR\fB.F03\fR" 4
-.IX Item "file.F03"
-.IP "\fIfile\fR\fB.F08\fR" 4
-.IX Item "file.F08"
-.PD
-Free form Fortran source code which must be preprocessed (with the
-traditional preprocessor).
-.IP "\fIfile\fR\fB.go\fR" 4
-.IX Item "file.go"
-Go source code.
-.IP "\fIfile\fR\fB.ads\fR" 4
-.IX Item "file.ads"
-Ada source code file which contains a library unit declaration (a
-declaration of a package, subprogram, or generic, or a generic
-instantiation), or a library unit renaming declaration (a package,
-generic, or subprogram renaming declaration). Such files are also
-called \fIspecs\fR.
-.IP "\fIfile\fR\fB.adb\fR" 4
-.IX Item "file.adb"
-Ada source code file containing a library unit body (a subprogram or
-package body). Such files are also called \fIbodies\fR.
-.IP "\fIfile\fR\fB.s\fR" 4
-.IX Item "file.s"
-Assembler code.
-.IP "\fIfile\fR\fB.S\fR" 4
-.IX Item "file.S"
-.PD 0
-.IP "\fIfile\fR\fB.sx\fR" 4
-.IX Item "file.sx"
-.PD
-Assembler code which must be preprocessed.
-.IP "\fIother\fR" 4
-.IX Item "other"
-An object file to be fed straight into linking.
-Any file name with no recognized suffix is treated this way.
-.PP
-You can specify the input language explicitly with the \fB\-x\fR option:
-.IP "\fB\-x\fR \fIlanguage\fR" 4
-.IX Item "-x language"
-Specify explicitly the \fIlanguage\fR for the following input files
-(rather than letting the compiler choose a default based on the file
-name suffix). This option applies to all following input files until
-the next \fB\-x\fR option. Possible values for \fIlanguage\fR are:
-.Sp
-.Vb 9
-\& c c\-header cpp\-output
-\& c++ c++\-header c++\-cpp\-output
-\& objective\-c objective\-c\-header objective\-c\-cpp\-output
-\& objective\-c++ objective\-c++\-header objective\-c++\-cpp\-output
-\& assembler assembler\-with\-cpp
-\& ada
-\& f77 f77\-cpp\-input f95 f95\-cpp\-input
-\& go
-\& java
-.Ve
-.IP "\fB\-x none\fR" 4
-.IX Item "-x none"
-Turn off any specification of a language, so that subsequent files are
-handled according to their file name suffixes (as they are if \fB\-x\fR
-has not been used at all).
-.IP "\fB\-pass\-exit\-codes\fR" 4
-.IX Item "-pass-exit-codes"
-Normally the \fBgcc\fR program will exit with the code of 1 if any
-phase of the compiler returns a non-success return code. If you specify
-\&\fB\-pass\-exit\-codes\fR, the \fBgcc\fR program will instead return with
-numerically highest error produced by any phase that returned an error
-indication. The C, \*(C+, and Fortran frontends return 4, if an internal
-compiler error is encountered.
-.PP
-If you only want some of the stages of compilation, you can use
-\&\fB\-x\fR (or filename suffixes) to tell \fBgcc\fR where to start, and
-one of the options \fB\-c\fR, \fB\-S\fR, or \fB\-E\fR to say where
-\&\fBgcc\fR is to stop. Note that some combinations (for example,
-\&\fB\-x cpp-output \-E\fR) instruct \fBgcc\fR to do nothing at all.
-.IP "\fB\-c\fR" 4
-.IX Item "-c"
-Compile or assemble the source files, but do not link. The linking
-stage simply is not done. The ultimate output is in the form of an
-object file for each source file.
-.Sp
-By default, the object file name for a source file is made by replacing
-the suffix \fB.c\fR, \fB.i\fR, \fB.s\fR, etc., with \fB.o\fR.
-.Sp
-Unrecognized input files, not requiring compilation or assembly, are
-ignored.
-.IP "\fB\-S\fR" 4
-.IX Item "-S"
-Stop after the stage of compilation proper; do not assemble. The output
-is in the form of an assembler code file for each non-assembler input
-file specified.
-.Sp
-By default, the assembler file name for a source file is made by
-replacing the suffix \fB.c\fR, \fB.i\fR, etc., with \fB.s\fR.
-.Sp
-Input files that don't require compilation are ignored.
-.IP "\fB\-E\fR" 4
-.IX Item "-E"
-Stop after the preprocessing stage; do not run the compiler proper. The
-output is in the form of preprocessed source code, which is sent to the
-standard output.
-.Sp
-Input files which don't require preprocessing are ignored.
-.IP "\fB\-o\fR \fIfile\fR" 4
-.IX Item "-o file"
-Place output in file \fIfile\fR. This applies regardless to whatever
-sort of output is being produced, whether it be an executable file,
-an object file, an assembler file or preprocessed C code.
-.Sp
-If \fB\-o\fR is not specified, the default is to put an executable
-file in \fIa.out\fR, the object file for
-\&\fI\fIsource\fI.\fIsuffix\fI\fR in \fI\fIsource\fI.o\fR, its
-assembler file in \fI\fIsource\fI.s\fR, a precompiled header file in
-\&\fI\fIsource\fI.\fIsuffix\fI.gch\fR, and all preprocessed C source on
-standard output.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-Print (on standard error output) the commands executed to run the stages
-of compilation. Also print the version number of the compiler driver
-program and of the preprocessor and the compiler proper.
-.IP "\fB\-###\fR" 4
-.IX Item "-###"
-Like \fB\-v\fR except the commands are not executed and arguments
-are quoted unless they contain only alphanumeric characters or \f(CW\*(C`./\-_\*(C'\fR.
-This is useful for shell scripts to capture the driver-generated command lines.
-.IP "\fB\-pipe\fR" 4
-.IX Item "-pipe"
-Use pipes rather than temporary files for communication between the
-various stages of compilation. This fails to work on some systems where
-the assembler is unable to read from a pipe; but the \s-1GNU\s0 assembler has
-no trouble.
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-Print (on the standard output) a description of the command line options
-understood by \fBgcc\fR. If the \fB\-v\fR option is also specified
-then \fB\-\-help\fR will also be passed on to the various processes
-invoked by \fBgcc\fR, so that they can display the command line options
-they accept. If the \fB\-Wextra\fR option has also been specified
-(prior to the \fB\-\-help\fR option), then command line options which
-have no documentation associated with them will also be displayed.
-.IP "\fB\-\-target\-help\fR" 4
-.IX Item "--target-help"
-Print (on the standard output) a description of target-specific command
-line options for each tool. For some targets extra target-specific
-information may also be printed.
-.IP "\fB\-\-help={\fR\fIclass\fR|[\fB^\fR]\fIqualifier\fR\fB}\fR[\fB,...\fR]" 4
-.IX Item "--help={class|[^]qualifier}[,...]"
-Print (on the standard output) a description of the command line
-options understood by the compiler that fit into all specified classes
-and qualifiers. These are the supported classes:
-.RS 4
-.IP "\fBoptimizers\fR" 4
-.IX Item "optimizers"
-This will display all of the optimization options supported by the
-compiler.
-.IP "\fBwarnings\fR" 4
-.IX Item "warnings"
-This will display all of the options controlling warning messages
-produced by the compiler.
-.IP "\fBtarget\fR" 4
-.IX Item "target"
-This will display target-specific options. Unlike the
-\&\fB\-\-target\-help\fR option however, target-specific options of the
-linker and assembler will not be displayed. This is because those
-tools do not currently support the extended \fB\-\-help=\fR syntax.
-.IP "\fBparams\fR" 4
-.IX Item "params"
-This will display the values recognized by the \fB\-\-param\fR
-option.
-.IP "\fIlanguage\fR" 4
-.IX Item "language"
-This will display the options supported for \fIlanguage\fR, where
-\&\fIlanguage\fR is the name of one of the languages supported in this
-version of \s-1GCC\s0.
-.IP "\fBcommon\fR" 4
-.IX Item "common"
-This will display the options that are common to all languages.
-.RE
-.RS 4
-.Sp
-These are the supported qualifiers:
-.IP "\fBundocumented\fR" 4
-.IX Item "undocumented"
-Display only those options which are undocumented.
-.IP "\fBjoined\fR" 4
-.IX Item "joined"
-Display options which take an argument that appears after an equal
-sign in the same continuous piece of text, such as:
-\&\fB\-\-help=target\fR.
-.IP "\fBseparate\fR" 4
-.IX Item "separate"
-Display options which take an argument that appears as a separate word
-following the original option, such as: \fB\-o output-file\fR.
-.RE
-.RS 4
-.Sp
-Thus for example to display all the undocumented target-specific
-switches supported by the compiler the following can be used:
-.Sp
-.Vb 1
-\& \-\-help=target,undocumented
-.Ve
-.Sp
-The sense of a qualifier can be inverted by prefixing it with the
-\&\fB^\fR character, so for example to display all binary warning
-options (i.e., ones that are either on or off and that do not take an
-argument), which have a description the following can be used:
-.Sp
-.Vb 1
-\& \-\-help=warnings,^joined,^undocumented
-.Ve
-.Sp
-The argument to \fB\-\-help=\fR should not consist solely of inverted
-qualifiers.
-.Sp
-Combining several classes is possible, although this usually
-restricts the output by so much that there is nothing to display. One
-case where it does work however is when one of the classes is
-\&\fItarget\fR. So for example to display all the target-specific
-optimization options the following can be used:
-.Sp
-.Vb 1
-\& \-\-help=target,optimizers
-.Ve
-.Sp
-The \fB\-\-help=\fR option can be repeated on the command line. Each
-successive use will display its requested class of options, skipping
-those that have already been displayed.
-.Sp
-If the \fB\-Q\fR option appears on the command line before the
-\&\fB\-\-help=\fR option, then the descriptive text displayed by
-\&\fB\-\-help=\fR is changed. Instead of describing the displayed
-options, an indication is given as to whether the option is enabled,
-disabled or set to a specific value (assuming that the compiler
-knows this at the point where the \fB\-\-help=\fR option is used).
-.Sp
-Here is a truncated example from the \s-1ARM\s0 port of \fBgcc\fR:
-.Sp
-.Vb 5
-\& % gcc \-Q \-mabi=2 \-\-help=target \-c
-\& The following options are target specific:
-\& \-mabi= 2
-\& \-mabort\-on\-noreturn [disabled]
-\& \-mapcs [disabled]
-.Ve
-.Sp
-The output is sensitive to the effects of previous command line
-options, so for example it is possible to find out which optimizations
-are enabled at \fB\-O2\fR by using:
-.Sp
-.Vb 1
-\& \-Q \-O2 \-\-help=optimizers
-.Ve
-.Sp
-Alternatively you can discover which binary optimizations are enabled
-by \fB\-O3\fR by using:
-.Sp
-.Vb 3
-\& gcc \-c \-Q \-O3 \-\-help=optimizers > /tmp/O3\-opts
-\& gcc \-c \-Q \-O2 \-\-help=optimizers > /tmp/O2\-opts
-\& diff /tmp/O2\-opts /tmp/O3\-opts | grep enabled
-.Ve
-.RE
-.IP "\fB\-canonical\-prefixes\fR" 4
-.IX Item "-canonical-prefixes"
-Always expand any symbolic links, resolve references to \fB/../\fR
-or \fB/./\fR, and make the path absolute when generating a relative
-prefix.
-.IP "\fB\-no\-canonical\-prefixes\fR" 4
-.IX Item "-no-canonical-prefixes"
-Never expand any symbolic links, resolve references to \fB/../\fR
-or \fB/./\fR, or make the path absolute when generating a relative
-prefix. If neither \fB\-canonical\-prefixes\fR nor
-\&\fB\-nocanonical\-prefixes\fR is given, \s-1GCC\s0 tries to set an appropriate
-default by looking for a target-specific subdirectory alongside the
-directory containing the compiler driver.
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-Display the version number and copyrights of the invoked \s-1GCC\s0.
-.IP "\fB\-wrapper\fR" 4
-.IX Item "-wrapper"
-Invoke all subcommands under a wrapper program. The name of the
-wrapper program and its parameters are passed as a comma separated
-list.
-.Sp
-.Vb 1
-\& gcc \-c t.c \-wrapper gdb,\-\-args
-.Ve
-.Sp
-This will invoke all subprograms of \fBgcc\fR under
-\&\fBgdb \-\-args\fR, thus the invocation of \fBcc1\fR will be
-\&\fBgdb \-\-args cc1 ...\fR.
-.IP "\fB\-fplugin=\fR\fIname\fR\fB.so\fR" 4
-.IX Item "-fplugin=name.so"
-Load the plugin code in file \fIname\fR.so, assumed to be a
-shared object to be dlopen'd by the compiler. The base name of
-the shared object file is used to identify the plugin for the
-purposes of argument parsing (See
-\&\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR below).
-Each plugin should define the callback functions specified in the
-Plugins \s-1API\s0.
-.IP "\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR" 4
-.IX Item "-fplugin-arg-name-key=value"
-Define an argument called \fIkey\fR with a value of \fIvalue\fR
-for the plugin called \fIname\fR.
-.IP "\fB\-fdump\-ada\-spec\fR[\fB\-slim\fR]" 4
-.IX Item "-fdump-ada-spec[-slim]"
-For C and \*(C+ source and include files, generate corresponding Ada
-specs.
-.IP "\fB\-fdump\-go\-spec=\fR\fIfile\fR" 4
-.IX Item "-fdump-go-spec=file"
-For input files in any language, generate corresponding Go
-declarations in \fIfile\fR. This generates Go \f(CW\*(C`const\*(C'\fR,
-\&\f(CW\*(C`type\*(C'\fR, \f(CW\*(C`var\*(C'\fR, and \f(CW\*(C`func\*(C'\fR declarations which may be a
-useful way to start writing a Go interface to code written in some
-other language.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SS "Compiling \*(C+ Programs"
-.IX Subsection "Compiling Programs"
-\&\*(C+ source files conventionally use one of the suffixes \fB.C\fR,
-\&\fB.cc\fR, \fB.cpp\fR, \fB.CPP\fR, \fB.c++\fR, \fB.cp\fR, or
-\&\fB.cxx\fR; \*(C+ header files often use \fB.hh\fR, \fB.hpp\fR,
-\&\fB.H\fR, or (for shared template code) \fB.tcc\fR; and
-preprocessed \*(C+ files use the suffix \fB.ii\fR. \s-1GCC\s0 recognizes
-files with these names and compiles them as \*(C+ programs even if you
-call the compiler the same way as for compiling C programs (usually
-with the name \fBgcc\fR).
-.PP
-However, the use of \fBgcc\fR does not add the \*(C+ library.
-\&\fBg++\fR is a program that calls \s-1GCC\s0 and treats \fB.c\fR,
-\&\fB.h\fR and \fB.i\fR files as \*(C+ source files instead of C source
-files unless \fB\-x\fR is used, and automatically specifies linking
-against the \*(C+ library. This program is also useful when
-precompiling a C header file with a \fB.h\fR extension for use in \*(C+
-compilations. On many systems, \fBg++\fR is also installed with
-the name \fBc++\fR.
-.PP
-When you compile \*(C+ programs, you may specify many of the same
-command-line options that you use for compiling programs in any
-language; or command-line options meaningful for C and related
-languages; or options that are meaningful only for \*(C+ programs.
-.SS "Options Controlling C Dialect"
-.IX Subsection "Options Controlling C Dialect"
-The following options control the dialect of C (or languages derived
-from C, such as \*(C+, Objective-C and Objective\-\*(C+) that the compiler
-accepts:
-.IP "\fB\-ansi\fR" 4
-.IX Item "-ansi"
-In C mode, this is equivalent to \fB\-std=c90\fR. In \*(C+ mode, it is
-equivalent to \fB\-std=c++98\fR.
-.Sp
-This turns off certain features of \s-1GCC\s0 that are incompatible with \s-1ISO\s0
-C90 (when compiling C code), or of standard \*(C+ (when compiling \*(C+ code),
-such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, and
-predefined macros such as \f(CW\*(C`unix\*(C'\fR and \f(CW\*(C`vax\*(C'\fR that identify the
-type of system you are using. It also enables the undesirable and
-rarely used \s-1ISO\s0 trigraph feature. For the C compiler,
-it disables recognition of \*(C+ style \fB//\fR comments as well as
-the \f(CW\*(C`inline\*(C'\fR keyword.
-.Sp
-The alternate keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_extension_\|_\*(C'\fR,
-\&\f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR continue to work despite
-\&\fB\-ansi\fR. You would not want to use them in an \s-1ISO\s0 C program, of
-course, but it is useful to put them in header files that might be included
-in compilations done with \fB\-ansi\fR. Alternate predefined macros
-such as \f(CW\*(C`_\|_unix_\|_\*(C'\fR and \f(CW\*(C`_\|_vax_\|_\*(C'\fR are also available, with or
-without \fB\-ansi\fR.
-.Sp
-The \fB\-ansi\fR option does not cause non-ISO programs to be
-rejected gratuitously. For that, \fB\-pedantic\fR is required in
-addition to \fB\-ansi\fR.
-.Sp
-The macro \f(CW\*(C`_\|_STRICT_ANSI_\|_\*(C'\fR is predefined when the \fB\-ansi\fR
-option is used. Some header files may notice this macro and refrain
-from declaring certain functions or defining certain macros that the
-\&\s-1ISO\s0 standard doesn't call for; this is to avoid interfering with any
-programs that might use these names for other things.
-.Sp
-Functions that would normally be built in but do not have semantics
-defined by \s-1ISO\s0 C (such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not built-in
-functions when \fB\-ansi\fR is used.
-.IP "\fB\-std=\fR" 4
-.IX Item "-std="
-Determine the language standard. This option
-is currently only supported when compiling C or \*(C+.
-.Sp
-The compiler can accept several base standards, such as \fBc90\fR or
-\&\fBc++98\fR, and \s-1GNU\s0 dialects of those standards, such as
-\&\fBgnu90\fR or \fBgnu++98\fR. By specifying a base standard, the
-compiler will accept all programs following that standard and those
-using \s-1GNU\s0 extensions that do not contradict it. For example,
-\&\fB\-std=c90\fR turns off certain features of \s-1GCC\s0 that are
-incompatible with \s-1ISO\s0 C90, such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR
-keywords, but not other \s-1GNU\s0 extensions that do not have a meaning in
-\&\s-1ISO\s0 C90, such as omitting the middle term of a \f(CW\*(C`?:\*(C'\fR
-expression. On the other hand, by specifying a \s-1GNU\s0 dialect of a
-standard, all features the compiler support are enabled, even when
-those features change the meaning of the base standard and some
-strict-conforming programs may be rejected. The particular standard
-is used by \fB\-pedantic\fR to identify which features are \s-1GNU\s0
-extensions given that version of the standard. For example
-\&\fB\-std=gnu90 \-pedantic\fR would warn about \*(C+ style \fB//\fR
-comments, while \fB\-std=gnu99 \-pedantic\fR would not.
-.Sp
-A value for this option must be provided; possible values are
-.RS 4
-.IP "\fBc90\fR" 4
-.IX Item "c90"
-.PD 0
-.IP "\fBc89\fR" 4
-.IX Item "c89"
-.IP "\fBiso9899:1990\fR" 4
-.IX Item "iso9899:1990"
-.PD
-Support all \s-1ISO\s0 C90 programs (certain \s-1GNU\s0 extensions that conflict
-with \s-1ISO\s0 C90 are disabled). Same as \fB\-ansi\fR for C code.
-.IP "\fBiso9899:199409\fR" 4
-.IX Item "iso9899:199409"
-\&\s-1ISO\s0 C90 as modified in amendment 1.
-.IP "\fBc99\fR" 4
-.IX Item "c99"
-.PD 0
-.IP "\fBc9x\fR" 4
-.IX Item "c9x"
-.IP "\fBiso9899:1999\fR" 4
-.IX Item "iso9899:1999"
-.IP "\fBiso9899:199x\fR" 4
-.IX Item "iso9899:199x"
-.PD
-\&\s-1ISO\s0 C99. Note that this standard is not yet fully supported; see
-<\fBhttp://gcc.gnu.org/gcc\-4.6/c99status.html\fR> for more information. The
-names \fBc9x\fR and \fBiso9899:199x\fR are deprecated.
-.IP "\fBc1x\fR" 4
-.IX Item "c1x"
-\&\s-1ISO\s0 C1X, the draft of the next revision of the \s-1ISO\s0 C standard.
-Support is limited and experimental and features enabled by this
-option may be changed or removed if changed in or removed from the
-standard draft.
-.IP "\fBgnu90\fR" 4
-.IX Item "gnu90"
-.PD 0
-.IP "\fBgnu89\fR" 4
-.IX Item "gnu89"
-.PD
-\&\s-1GNU\s0 dialect of \s-1ISO\s0 C90 (including some C99 features). This
-is the default for C code.
-.IP "\fBgnu99\fR" 4
-.IX Item "gnu99"
-.PD 0
-.IP "\fBgnu9x\fR" 4
-.IX Item "gnu9x"
-.PD
-\&\s-1GNU\s0 dialect of \s-1ISO\s0 C99. When \s-1ISO\s0 C99 is fully implemented in \s-1GCC\s0,
-this will become the default. The name \fBgnu9x\fR is deprecated.
-.IP "\fBgnu1x\fR" 4
-.IX Item "gnu1x"
-\&\s-1GNU\s0 dialect of \s-1ISO\s0 C1X. Support is limited and experimental and
-features enabled by this option may be changed or removed if changed
-in or removed from the standard draft.
-.IP "\fBc++98\fR" 4
-.IX Item "c++98"
-The 1998 \s-1ISO\s0 \*(C+ standard plus amendments. Same as \fB\-ansi\fR for
-\&\*(C+ code.
-.IP "\fBgnu++98\fR" 4
-.IX Item "gnu++98"
-\&\s-1GNU\s0 dialect of \fB\-std=c++98\fR. This is the default for
-\&\*(C+ code.
-.IP "\fBc++0x\fR" 4
-.IX Item "c++0x"
-The working draft of the upcoming \s-1ISO\s0 \*(C+0x standard. This option
-enables experimental features that are likely to be included in
-\&\*(C+0x. The working draft is constantly changing, and any feature that is
-enabled by this flag may be removed from future versions of \s-1GCC\s0 if it is
-not part of the \*(C+0x standard.
-.IP "\fBgnu++0x\fR" 4
-.IX Item "gnu++0x"
-\&\s-1GNU\s0 dialect of \fB\-std=c++0x\fR. This option enables
-experimental features that may be removed in future versions of \s-1GCC\s0.
-.RE
-.RS 4
-.RE
-.IP "\fB\-fgnu89\-inline\fR" 4
-.IX Item "-fgnu89-inline"
-The option \fB\-fgnu89\-inline\fR tells \s-1GCC\s0 to use the traditional
-\&\s-1GNU\s0 semantics for \f(CW\*(C`inline\*(C'\fR functions when in C99 mode.
- This option
-is accepted and ignored by \s-1GCC\s0 versions 4.1.3 up to but not including
-4.3. In \s-1GCC\s0 versions 4.3 and later it changes the behavior of \s-1GCC\s0 in
-C99 mode. Using this option is roughly equivalent to adding the
-\&\f(CW\*(C`gnu_inline\*(C'\fR function attribute to all inline functions.
-.Sp
-The option \fB\-fno\-gnu89\-inline\fR explicitly tells \s-1GCC\s0 to use the
-C99 semantics for \f(CW\*(C`inline\*(C'\fR when in C99 or gnu99 mode (i.e., it
-specifies the default behavior). This option was first supported in
-\&\s-1GCC\s0 4.3. This option is not supported in \fB\-std=c90\fR or
-\&\fB\-std=gnu90\fR mode.
-.Sp
-The preprocessor macros \f(CW\*(C`_\|_GNUC_GNU_INLINE_\|_\*(C'\fR and
-\&\f(CW\*(C`_\|_GNUC_STDC_INLINE_\|_\*(C'\fR may be used to check which semantics are
-in effect for \f(CW\*(C`inline\*(C'\fR functions.
-.IP "\fB\-aux\-info\fR \fIfilename\fR" 4
-.IX Item "-aux-info filename"
-Output to the given filename prototyped declarations for all functions
-declared and/or defined in a translation unit, including those in header
-files. This option is silently ignored in any language other than C.
-.Sp
-Besides declarations, the file indicates, in comments, the origin of
-each declaration (source file and line), whether the declaration was
-implicit, prototyped or unprototyped (\fBI\fR, \fBN\fR for new or
-\&\fBO\fR for old, respectively, in the first character after the line
-number and the colon), and whether it came from a declaration or a
-definition (\fBC\fR or \fBF\fR, respectively, in the following
-character). In the case of function definitions, a K&R\-style list of
-arguments followed by their declarations is also provided, inside
-comments, after the declaration.
-.IP "\fB\-fno\-asm\fR" 4
-.IX Item "-fno-asm"
-Do not recognize \f(CW\*(C`asm\*(C'\fR, \f(CW\*(C`inline\*(C'\fR or \f(CW\*(C`typeof\*(C'\fR as a
-keyword, so that code can use these words as identifiers. You can use
-the keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR
-instead. \fB\-ansi\fR implies \fB\-fno\-asm\fR.
-.Sp
-In \*(C+, this switch only affects the \f(CW\*(C`typeof\*(C'\fR keyword, since
-\&\f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`inline\*(C'\fR are standard keywords. You may want to
-use the \fB\-fno\-gnu\-keywords\fR flag instead, which has the same
-effect. In C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR), this
-switch only affects the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, since
-\&\f(CW\*(C`inline\*(C'\fR is a standard keyword in \s-1ISO\s0 C99.
-.IP "\fB\-fno\-builtin\fR" 4
-.IX Item "-fno-builtin"
-.PD 0
-.IP "\fB\-fno\-builtin\-\fR\fIfunction\fR" 4
-.IX Item "-fno-builtin-function"
-.PD
-Don't recognize built-in functions that do not begin with
-\&\fB_\|_builtin_\fR as prefix.
-.Sp
-\&\s-1GCC\s0 normally generates special code to handle certain built-in functions
-more efficiently; for instance, calls to \f(CW\*(C`alloca\*(C'\fR may become single
-instructions that adjust the stack directly, and calls to \f(CW\*(C`memcpy\*(C'\fR
-may become inline copy loops. The resulting code is often both smaller
-and faster, but since the function calls no longer appear as such, you
-cannot set a breakpoint on those calls, nor can you change the behavior
-of the functions by linking with a different library. In addition,
-when a function is recognized as a built-in function, \s-1GCC\s0 may use
-information about that function to warn about problems with calls to
-that function, or to generate more efficient code, even if the
-resulting code still contains calls to that function. For example,
-warnings are given with \fB\-Wformat\fR for bad calls to
-\&\f(CW\*(C`printf\*(C'\fR, when \f(CW\*(C`printf\*(C'\fR is built in, and \f(CW\*(C`strlen\*(C'\fR is
-known not to modify global memory.
-.Sp
-With the \fB\-fno\-builtin\-\fR\fIfunction\fR option
-only the built-in function \fIfunction\fR is
-disabled. \fIfunction\fR must not begin with \fB_\|_builtin_\fR. If a
-function is named that is not built-in in this version of \s-1GCC\s0, this
-option is ignored. There is no corresponding
-\&\fB\-fbuiltin\-\fR\fIfunction\fR option; if you wish to enable
-built-in functions selectively when using \fB\-fno\-builtin\fR or
-\&\fB\-ffreestanding\fR, you may define macros such as:
-.Sp
-.Vb 2
-\& #define abs(n) _\|_builtin_abs ((n))
-\& #define strcpy(d, s) _\|_builtin_strcpy ((d), (s))
-.Ve
-.IP "\fB\-fhosted\fR" 4
-.IX Item "-fhosted"
-Assert that compilation takes place in a hosted environment. This implies
-\&\fB\-fbuiltin\fR. A hosted environment is one in which the
-entire standard library is available, and in which \f(CW\*(C`main\*(C'\fR has a return
-type of \f(CW\*(C`int\*(C'\fR. Examples are nearly everything except a kernel.
-This is equivalent to \fB\-fno\-freestanding\fR.
-.IP "\fB\-ffreestanding\fR" 4
-.IX Item "-ffreestanding"
-Assert that compilation takes place in a freestanding environment. This
-implies \fB\-fno\-builtin\fR. A freestanding environment
-is one in which the standard library may not exist, and program startup may
-not necessarily be at \f(CW\*(C`main\*(C'\fR. The most obvious example is an \s-1OS\s0 kernel.
-This is equivalent to \fB\-fno\-hosted\fR.
-.IP "\fB\-fopenmp\fR" 4
-.IX Item "-fopenmp"
-Enable handling of OpenMP directives \f(CW\*(C`#pragma omp\*(C'\fR in C/\*(C+ and
-\&\f(CW\*(C`!$omp\*(C'\fR in Fortran. When \fB\-fopenmp\fR is specified, the
-compiler generates parallel code according to the OpenMP Application
-Program Interface v3.0 <\fBhttp://www.openmp.org/\fR>. This option
-implies \fB\-pthread\fR, and thus is only supported on targets that
-have support for \fB\-pthread\fR.
-.IP "\fB\-fms\-extensions\fR" 4
-.IX Item "-fms-extensions"
-Accept some non-standard constructs used in Microsoft header files.
-.Sp
-In \*(C+ code, this allows member names in structures to be similar
-to previous types declarations.
-.Sp
-.Vb 4
-\& typedef int UOW;
-\& struct ABC {
-\& UOW UOW;
-\& };
-.Ve
-.Sp
-Some cases of unnamed fields in structures and unions are only
-accepted with this option.
-.IP "\fB\-fplan9\-extensions\fR" 4
-.IX Item "-fplan9-extensions"
-Accept some non-standard constructs used in Plan 9 code.
-.Sp
-This enables \fB\-fms\-extensions\fR, permits passing pointers to
-structures with anonymous fields to functions which expect pointers to
-elements of the type of the field, and permits referring to anonymous
-fields declared using a typedef. This is only
-supported for C, not \*(C+.
-.IP "\fB\-trigraphs\fR" 4
-.IX Item "-trigraphs"
-Support \s-1ISO\s0 C trigraphs. The \fB\-ansi\fR option (and \fB\-std\fR
-options for strict \s-1ISO\s0 C conformance) implies \fB\-trigraphs\fR.
-.IP "\fB\-no\-integrated\-cpp\fR" 4
-.IX Item "-no-integrated-cpp"
-Performs a compilation in two passes: preprocessing and compiling. This
-option allows a user supplied \*(L"cc1\*(R", \*(L"cc1plus\*(R", or \*(L"cc1obj\*(R" via the
-\&\fB\-B\fR option. The user supplied compilation step can then add in
-an additional preprocessing step after normal preprocessing but before
-compiling. The default is to use the integrated cpp (internal cpp)
-.Sp
-The semantics of this option will change if \*(L"cc1\*(R", \*(L"cc1plus\*(R", and
-\&\*(L"cc1obj\*(R" are merged.
-.IP "\fB\-traditional\fR" 4
-.IX Item "-traditional"
-.PD 0
-.IP "\fB\-traditional\-cpp\fR" 4
-.IX Item "-traditional-cpp"
-.PD
-Formerly, these options caused \s-1GCC\s0 to attempt to emulate a pre-standard
-C compiler. They are now only supported with the \fB\-E\fR switch.
-The preprocessor continues to support a pre-standard mode. See the \s-1GNU\s0
-\&\s-1CPP\s0 manual for details.
-.IP "\fB\-fcond\-mismatch\fR" 4
-.IX Item "-fcond-mismatch"
-Allow conditional expressions with mismatched types in the second and
-third arguments. The value of such an expression is void. This option
-is not supported for \*(C+.
-.IP "\fB\-flax\-vector\-conversions\fR" 4
-.IX Item "-flax-vector-conversions"
-Allow implicit conversions between vectors with differing numbers of
-elements and/or incompatible element types. This option should not be
-used for new code.
-.IP "\fB\-funsigned\-char\fR" 4
-.IX Item "-funsigned-char"
-Let the type \f(CW\*(C`char\*(C'\fR be unsigned, like \f(CW\*(C`unsigned char\*(C'\fR.
-.Sp
-Each kind of machine has a default for what \f(CW\*(C`char\*(C'\fR should
-be. It is either like \f(CW\*(C`unsigned char\*(C'\fR by default or like
-\&\f(CW\*(C`signed char\*(C'\fR by default.
-.Sp
-Ideally, a portable program should always use \f(CW\*(C`signed char\*(C'\fR or
-\&\f(CW\*(C`unsigned char\*(C'\fR when it depends on the signedness of an object.
-But many programs have been written to use plain \f(CW\*(C`char\*(C'\fR and
-expect it to be signed, or expect it to be unsigned, depending on the
-machines they were written for. This option, and its inverse, let you
-make such a program work with the opposite default.
-.Sp
-The type \f(CW\*(C`char\*(C'\fR is always a distinct type from each of
-\&\f(CW\*(C`signed char\*(C'\fR or \f(CW\*(C`unsigned char\*(C'\fR, even though its behavior
-is always just like one of those two.
-.IP "\fB\-fsigned\-char\fR" 4
-.IX Item "-fsigned-char"
-Let the type \f(CW\*(C`char\*(C'\fR be signed, like \f(CW\*(C`signed char\*(C'\fR.
-.Sp
-Note that this is equivalent to \fB\-fno\-unsigned\-char\fR, which is
-the negative form of \fB\-funsigned\-char\fR. Likewise, the option
-\&\fB\-fno\-signed\-char\fR is equivalent to \fB\-funsigned\-char\fR.
-.IP "\fB\-fsigned\-bitfields\fR" 4
-.IX Item "-fsigned-bitfields"
-.PD 0
-.IP "\fB\-funsigned\-bitfields\fR" 4
-.IX Item "-funsigned-bitfields"
-.IP "\fB\-fno\-signed\-bitfields\fR" 4
-.IX Item "-fno-signed-bitfields"
-.IP "\fB\-fno\-unsigned\-bitfields\fR" 4
-.IX Item "-fno-unsigned-bitfields"
-.PD
-These options control whether a bit-field is signed or unsigned, when the
-declaration does not use either \f(CW\*(C`signed\*(C'\fR or \f(CW\*(C`unsigned\*(C'\fR. By
-default, such a bit-field is signed, because this is consistent: the
-basic integer types such as \f(CW\*(C`int\*(C'\fR are signed types.
-.SS "Options Controlling \*(C+ Dialect"
-.IX Subsection "Options Controlling Dialect"
-This section describes the command-line options that are only meaningful
-for \*(C+ programs; but you can also use most of the \s-1GNU\s0 compiler options
-regardless of what language your program is in. For example, you
-might compile a file \f(CW\*(C`firstClass.C\*(C'\fR like this:
-.PP
-.Vb 1
-\& g++ \-g \-frepo \-O \-c firstClass.C
-.Ve
-.PP
-In this example, only \fB\-frepo\fR is an option meant
-only for \*(C+ programs; you can use the other options with any
-language supported by \s-1GCC\s0.
-.PP
-Here is a list of options that are \fIonly\fR for compiling \*(C+ programs:
-.IP "\fB\-fabi\-version=\fR\fIn\fR" 4
-.IX Item "-fabi-version=n"
-Use version \fIn\fR of the \*(C+ \s-1ABI\s0. Version 2 is the version of the
-\&\*(C+ \s-1ABI\s0 that first appeared in G++ 3.4. Version 1 is the version of
-the \*(C+ \s-1ABI\s0 that first appeared in G++ 3.2. Version 0 will always be
-the version that conforms most closely to the \*(C+ \s-1ABI\s0 specification.
-Therefore, the \s-1ABI\s0 obtained using version 0 will change as \s-1ABI\s0 bugs
-are fixed.
-.Sp
-The default is version 2.
-.Sp
-Version 3 corrects an error in mangling a constant address as a
-template argument.
-.Sp
-Version 4 implements a standard mangling for vector types.
-.Sp
-Version 5 corrects the mangling of attribute const/volatile on
-function pointer types, decltype of a plain decl, and use of a
-function parameter in the declaration of another parameter.
-.Sp
-See also \fB\-Wabi\fR.
-.IP "\fB\-fno\-access\-control\fR" 4
-.IX Item "-fno-access-control"
-Turn off all access checking. This switch is mainly useful for working
-around bugs in the access control code.
-.IP "\fB\-fcheck\-new\fR" 4
-.IX Item "-fcheck-new"
-Check that the pointer returned by \f(CW\*(C`operator new\*(C'\fR is non-null
-before attempting to modify the storage allocated. This check is
-normally unnecessary because the \*(C+ standard specifies that
-\&\f(CW\*(C`operator new\*(C'\fR will only return \f(CW0\fR if it is declared
-\&\fB\f(BIthrow()\fB\fR, in which case the compiler will always check the
-return value even without this option. In all other cases, when
-\&\f(CW\*(C`operator new\*(C'\fR has a non-empty exception specification, memory
-exhaustion is signalled by throwing \f(CW\*(C`std::bad_alloc\*(C'\fR. See also
-\&\fBnew (nothrow)\fR.
-.IP "\fB\-fconserve\-space\fR" 4
-.IX Item "-fconserve-space"
-Put uninitialized or runtime-initialized global variables into the
-common segment, as C does. This saves space in the executable at the
-cost of not diagnosing duplicate definitions. If you compile with this
-flag and your program mysteriously crashes after \f(CW\*(C`main()\*(C'\fR has
-completed, you may have an object that is being destroyed twice because
-two definitions were merged.
-.Sp
-This option is no longer useful on most targets, now that support has
-been added for putting variables into \s-1BSS\s0 without making them common.
-.IP "\fB\-fconstexpr\-depth=\fR\fIn\fR" 4
-.IX Item "-fconstexpr-depth=n"
-Set the maximum nested evaluation depth for \*(C+0x constexpr functions
-to \fIn\fR. A limit is needed to detect endless recursion during
-constant expression evaluation. The minimum specified by the standard
-is 512.
-.IP "\fB\-fno\-deduce\-init\-list\fR" 4
-.IX Item "-fno-deduce-init-list"
-Disable deduction of a template type parameter as
-std::initializer_list from a brace-enclosed initializer list, i.e.
-.Sp
-.Vb 4
-\& template <class T> auto forward(T t) \-> decltype (realfn (t))
-\& {
-\& return realfn (t);
-\& }
-\&
-\& void f()
-\& {
-\& forward({1,2}); // call forward<std::initializer_list<int>>
-\& }
-.Ve
-.Sp
-This option is present because this deduction is an extension to the
-current specification in the \*(C+0x working draft, and there was
-some concern about potential overload resolution problems.
-.IP "\fB\-ffriend\-injection\fR" 4
-.IX Item "-ffriend-injection"
-Inject friend functions into the enclosing namespace, so that they are
-visible outside the scope of the class in which they are declared.
-Friend functions were documented to work this way in the old Annotated
-\&\*(C+ Reference Manual, and versions of G++ before 4.1 always worked
-that way. However, in \s-1ISO\s0 \*(C+ a friend function which is not declared
-in an enclosing scope can only be found using argument dependent
-lookup. This option causes friends to be injected as they were in
-earlier releases.
-.Sp
-This option is for compatibility, and may be removed in a future
-release of G++.
-.IP "\fB\-fno\-elide\-constructors\fR" 4
-.IX Item "-fno-elide-constructors"
-The \*(C+ standard allows an implementation to omit creating a temporary
-which is only used to initialize another object of the same type.
-Specifying this option disables that optimization, and forces G++ to
-call the copy constructor in all cases.
-.IP "\fB\-fno\-enforce\-eh\-specs\fR" 4
-.IX Item "-fno-enforce-eh-specs"
-Don't generate code to check for violation of exception specifications
-at runtime. This option violates the \*(C+ standard, but may be useful
-for reducing code size in production builds, much like defining
-\&\fB\s-1NDEBUG\s0\fR. This does not give user code permission to throw
-exceptions in violation of the exception specifications; the compiler
-will still optimize based on the specifications, so throwing an
-unexpected exception will result in undefined behavior.
-.IP "\fB\-ffor\-scope\fR" 4
-.IX Item "-ffor-scope"
-.PD 0
-.IP "\fB\-fno\-for\-scope\fR" 4
-.IX Item "-fno-for-scope"
-.PD
-If \fB\-ffor\-scope\fR is specified, the scope of variables declared in
-a \fIfor-init-statement\fR is limited to the \fBfor\fR loop itself,
-as specified by the \*(C+ standard.
-If \fB\-fno\-for\-scope\fR is specified, the scope of variables declared in
-a \fIfor-init-statement\fR extends to the end of the enclosing scope,
-as was the case in old versions of G++, and other (traditional)
-implementations of \*(C+.
-.Sp
-The default if neither flag is given to follow the standard,
-but to allow and give a warning for old-style code that would
-otherwise be invalid, or have different behavior.
-.IP "\fB\-fno\-gnu\-keywords\fR" 4
-.IX Item "-fno-gnu-keywords"
-Do not recognize \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use this
-word as an identifier. You can use the keyword \f(CW\*(C`_\|_typeof_\|_\*(C'\fR instead.
-\&\fB\-ansi\fR implies \fB\-fno\-gnu\-keywords\fR.
-.IP "\fB\-fno\-implicit\-templates\fR" 4
-.IX Item "-fno-implicit-templates"
-Never emit code for non-inline templates which are instantiated
-implicitly (i.e. by use); only emit code for explicit instantiations.
-.IP "\fB\-fno\-implicit\-inline\-templates\fR" 4
-.IX Item "-fno-implicit-inline-templates"
-Don't emit code for implicit instantiations of inline templates, either.
-The default is to handle inlines differently so that compiles with and
-without optimization will need the same set of explicit instantiations.
-.IP "\fB\-fno\-implement\-inlines\fR" 4
-.IX Item "-fno-implement-inlines"
-To save space, do not emit out-of-line copies of inline functions
-controlled by \fB#pragma implementation\fR. This will cause linker
-errors if these functions are not inlined everywhere they are called.
-.IP "\fB\-fms\-extensions\fR" 4
-.IX Item "-fms-extensions"
-Disable pedantic warnings about constructs used in \s-1MFC\s0, such as implicit
-int and getting a pointer to member function via non-standard syntax.
-.IP "\fB\-fno\-nonansi\-builtins\fR" 4
-.IX Item "-fno-nonansi-builtins"
-Disable built-in declarations of functions that are not mandated by
-\&\s-1ANSI/ISO\s0 C. These include \f(CW\*(C`ffs\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`_exit\*(C'\fR,
-\&\f(CW\*(C`index\*(C'\fR, \f(CW\*(C`bzero\*(C'\fR, \f(CW\*(C`conjf\*(C'\fR, and other related functions.
-.IP "\fB\-fnothrow\-opt\fR" 4
-.IX Item "-fnothrow-opt"
-Treat a \f(CW\*(C`throw()\*(C'\fR exception specification as though it were a
-\&\f(CW\*(C`noexcept\*(C'\fR specification to reduce or eliminate the text size
-overhead relative to a function with no exception specification. If
-the function has local variables of types with non-trivial
-destructors, the exception specification will actually make the
-function smaller because the \s-1EH\s0 cleanups for those variables can be
-optimized away. The semantic effect is that an exception thrown out of
-a function with such an exception specification will result in a call
-to \f(CW\*(C`terminate\*(C'\fR rather than \f(CW\*(C`unexpected\*(C'\fR.
-.IP "\fB\-fno\-operator\-names\fR" 4
-.IX Item "-fno-operator-names"
-Do not treat the operator name keywords \f(CW\*(C`and\*(C'\fR, \f(CW\*(C`bitand\*(C'\fR,
-\&\f(CW\*(C`bitor\*(C'\fR, \f(CW\*(C`compl\*(C'\fR, \f(CW\*(C`not\*(C'\fR, \f(CW\*(C`or\*(C'\fR and \f(CW\*(C`xor\*(C'\fR as
-synonyms as keywords.
-.IP "\fB\-fno\-optional\-diags\fR" 4
-.IX Item "-fno-optional-diags"
-Disable diagnostics that the standard says a compiler does not need to
-issue. Currently, the only such diagnostic issued by G++ is the one for
-a name having multiple meanings within a class.
-.IP "\fB\-fpermissive\fR" 4
-.IX Item "-fpermissive"
-Downgrade some diagnostics about nonconformant code from errors to
-warnings. Thus, using \fB\-fpermissive\fR will allow some
-nonconforming code to compile.
-.IP "\fB\-fno\-pretty\-templates\fR" 4
-.IX Item "-fno-pretty-templates"
-When an error message refers to a specialization of a function
-template, the compiler will normally print the signature of the
-template followed by the template arguments and any typedefs or
-typenames in the signature (e.g. \f(CW\*(C`void f(T) [with T = int]\*(C'\fR
-rather than \f(CW\*(C`void f(int)\*(C'\fR) so that it's clear which template is
-involved. When an error message refers to a specialization of a class
-template, the compiler will omit any template arguments which match
-the default template arguments for that template. If either of these
-behaviors make it harder to understand the error message rather than
-easier, using \fB\-fno\-pretty\-templates\fR will disable them.
-.IP "\fB\-frepo\fR" 4
-.IX Item "-frepo"
-Enable automatic template instantiation at link time. This option also
-implies \fB\-fno\-implicit\-templates\fR.
-.IP "\fB\-fno\-rtti\fR" 4
-.IX Item "-fno-rtti"
-Disable generation of information about every class with virtual
-functions for use by the \*(C+ runtime type identification features
-(\fBdynamic_cast\fR and \fBtypeid\fR). If you don't use those parts
-of the language, you can save some space by using this flag. Note that
-exception handling uses the same information, but it will generate it as
-needed. The \fBdynamic_cast\fR operator can still be used for casts that
-do not require runtime type information, i.e. casts to \f(CW\*(C`void *\*(C'\fR or to
-unambiguous base classes.
-.IP "\fB\-fstats\fR" 4
-.IX Item "-fstats"
-Emit statistics about front-end processing at the end of the compilation.
-This information is generally only useful to the G++ development team.
-.IP "\fB\-fstrict\-enums\fR" 4
-.IX Item "-fstrict-enums"
-Allow the compiler to optimize using the assumption that a value of
-enumeration type can only be one of the values of the enumeration (as
-defined in the \*(C+ standard; basically, a value which can be
-represented in the minimum number of bits needed to represent all the
-enumerators). This assumption may not be valid if the program uses a
-cast to convert an arbitrary integer value to the enumeration type.
-.IP "\fB\-ftemplate\-depth=\fR\fIn\fR" 4
-.IX Item "-ftemplate-depth=n"
-Set the maximum instantiation depth for template classes to \fIn\fR.
-A limit on the template instantiation depth is needed to detect
-endless recursions during template class instantiation. \s-1ANSI/ISO\s0 \*(C+
-conforming programs must not rely on a maximum depth greater than 17
-(changed to 1024 in \*(C+0x).
-.IP "\fB\-fno\-threadsafe\-statics\fR" 4
-.IX Item "-fno-threadsafe-statics"
-Do not emit the extra code to use the routines specified in the \*(C+
-\&\s-1ABI\s0 for thread-safe initialization of local statics. You can use this
-option to reduce code size slightly in code that doesn't need to be
-thread-safe.
-.IP "\fB\-fuse\-cxa\-atexit\fR" 4
-.IX Item "-fuse-cxa-atexit"
-Register destructors for objects with static storage duration with the
-\&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR function rather than the \f(CW\*(C`atexit\*(C'\fR function.
-This option is required for fully standards-compliant handling of static
-destructors, but will only work if your C library supports
-\&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR.
-.IP "\fB\-fno\-use\-cxa\-get\-exception\-ptr\fR" 4
-.IX Item "-fno-use-cxa-get-exception-ptr"
-Don't use the \f(CW\*(C`_\|_cxa_get_exception_ptr\*(C'\fR runtime routine. This
-will cause \f(CW\*(C`std::uncaught_exception\*(C'\fR to be incorrect, but is necessary
-if the runtime routine is not available.
-.IP "\fB\-fvisibility\-inlines\-hidden\fR" 4
-.IX Item "-fvisibility-inlines-hidden"
-This switch declares that the user does not attempt to compare
-pointers to inline methods where the addresses of the two functions
-were taken in different shared objects.
-.Sp
-The effect of this is that \s-1GCC\s0 may, effectively, mark inline methods with
-\&\f(CW\*(C`_\|_attribute_\|_ ((visibility ("hidden")))\*(C'\fR so that they do not
-appear in the export table of a \s-1DSO\s0 and do not require a \s-1PLT\s0 indirection
-when used within the \s-1DSO\s0. Enabling this option can have a dramatic effect
-on load and link times of a \s-1DSO\s0 as it massively reduces the size of the
-dynamic export table when the library makes heavy use of templates.
-.Sp
-The behavior of this switch is not quite the same as marking the
-methods as hidden directly, because it does not affect static variables
-local to the function or cause the compiler to deduce that
-the function is defined in only one shared object.
-.Sp
-You may mark a method as having a visibility explicitly to negate the
-effect of the switch for that method. For example, if you do want to
-compare pointers to a particular inline method, you might mark it as
-having default visibility. Marking the enclosing class with explicit
-visibility will have no effect.
-.Sp
-Explicitly instantiated inline methods are unaffected by this option
-as their linkage might otherwise cross a shared library boundary.
-.IP "\fB\-fvisibility\-ms\-compat\fR" 4
-.IX Item "-fvisibility-ms-compat"
-This flag attempts to use visibility settings to make \s-1GCC\s0's \*(C+
-linkage model compatible with that of Microsoft Visual Studio.
-.Sp
-The flag makes these changes to \s-1GCC\s0's linkage model:
-.RS 4
-.IP "1." 4
-It sets the default visibility to \f(CW\*(C`hidden\*(C'\fR, like
-\&\fB\-fvisibility=hidden\fR.
-.IP "2." 4
-Types, but not their members, are not hidden by default.
-.IP "3." 4
-The One Definition Rule is relaxed for types without explicit
-visibility specifications which are defined in more than one different
-shared object: those declarations are permitted if they would have
-been permitted when this option was not used.
-.RE
-.RS 4
-.Sp
-In new code it is better to use \fB\-fvisibility=hidden\fR and
-export those classes which are intended to be externally visible.
-Unfortunately it is possible for code to rely, perhaps accidentally,
-on the Visual Studio behavior.
-.Sp
-Among the consequences of these changes are that static data members
-of the same type with the same name but defined in different shared
-objects will be different, so changing one will not change the other;
-and that pointers to function members defined in different shared
-objects may not compare equal. When this flag is given, it is a
-violation of the \s-1ODR\s0 to define types with the same name differently.
-.RE
-.IP "\fB\-fno\-weak\fR" 4
-.IX Item "-fno-weak"
-Do not use weak symbol support, even if it is provided by the linker.
-By default, G++ will use weak symbols if they are available. This
-option exists only for testing, and should not be used by end-users;
-it will result in inferior code and has no benefits. This option may
-be removed in a future release of G++.
-.IP "\fB\-nostdinc++\fR" 4
-.IX Item "-nostdinc++"
-Do not search for header files in the standard directories specific to
-\&\*(C+, but do still search the other standard directories. (This option
-is used when building the \*(C+ library.)
-.PP
-In addition, these optimization, warning, and code generation options
-have meanings only for \*(C+ programs:
-.IP "\fB\-fno\-default\-inline\fR" 4
-.IX Item "-fno-default-inline"
-Do not assume \fBinline\fR for functions defined inside a class scope.
- Note that these
-functions will have linkage like inline functions; they just won't be
-inlined by default.
-.IP "\fB\-Wabi\fR (C, Objective-C, \*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wabi (C, Objective-C, and Objective- only)"
-Warn when G++ generates code that is probably not compatible with the
-vendor-neutral \*(C+ \s-1ABI\s0. Although an effort has been made to warn about
-all such cases, there are probably some cases that are not warned about,
-even though G++ is generating incompatible code. There may also be
-cases where warnings are emitted even though the code that is generated
-will be compatible.
-.Sp
-You should rewrite your code to avoid these warnings if you are
-concerned about the fact that code generated by G++ may not be binary
-compatible with code generated by other compilers.
-.Sp
-The known incompatibilities in \fB\-fabi\-version=2\fR (the default) include:
-.RS 4
-.IP "\(bu" 4
-A template with a non-type template parameter of reference type is
-mangled incorrectly:
-.Sp
-.Vb 3
-\& extern int N;
-\& template <int &> struct S {};
-\& void n (S<N>) {2}
-.Ve
-.Sp
-This is fixed in \fB\-fabi\-version=3\fR.
-.IP "\(bu" 4
-\&\s-1SIMD\s0 vector types declared using \f(CW\*(C`_\|_attribute ((vector_size))\*(C'\fR are
-mangled in a non-standard way that does not allow for overloading of
-functions taking vectors of different sizes.
-.Sp
-The mangling is changed in \fB\-fabi\-version=4\fR.
-.RE
-.RS 4
-.Sp
-The known incompatibilities in \fB\-fabi\-version=1\fR include:
-.IP "\(bu" 4
-Incorrect handling of tail-padding for bit-fields. G++ may attempt to
-pack data into the same byte as a base class. For example:
-.Sp
-.Vb 2
-\& struct A { virtual void f(); int f1 : 1; };
-\& struct B : public A { int f2 : 1; };
-.Ve
-.Sp
-In this case, G++ will place \f(CW\*(C`B::f2\*(C'\fR into the same byte
-as\f(CW\*(C`A::f1\*(C'\fR; other compilers will not. You can avoid this problem
-by explicitly padding \f(CW\*(C`A\*(C'\fR so that its size is a multiple of the
-byte size on your platform; that will cause G++ and other compilers to
-layout \f(CW\*(C`B\*(C'\fR identically.
-.IP "\(bu" 4
-Incorrect handling of tail-padding for virtual bases. G++ does not use
-tail padding when laying out virtual bases. For example:
-.Sp
-.Vb 3
-\& struct A { virtual void f(); char c1; };
-\& struct B { B(); char c2; };
-\& struct C : public A, public virtual B {};
-.Ve
-.Sp
-In this case, G++ will not place \f(CW\*(C`B\*(C'\fR into the tail-padding for
-\&\f(CW\*(C`A\*(C'\fR; other compilers will. You can avoid this problem by
-explicitly padding \f(CW\*(C`A\*(C'\fR so that its size is a multiple of its
-alignment (ignoring virtual base classes); that will cause G++ and other
-compilers to layout \f(CW\*(C`C\*(C'\fR identically.
-.IP "\(bu" 4
-Incorrect handling of bit-fields with declared widths greater than that
-of their underlying types, when the bit-fields appear in a union. For
-example:
-.Sp
-.Vb 1
-\& union U { int i : 4096; };
-.Ve
-.Sp
-Assuming that an \f(CW\*(C`int\*(C'\fR does not have 4096 bits, G++ will make the
-union too small by the number of bits in an \f(CW\*(C`int\*(C'\fR.
-.IP "\(bu" 4
-Empty classes can be placed at incorrect offsets. For example:
-.Sp
-.Vb 1
-\& struct A {};
-\&
-\& struct B {
-\& A a;
-\& virtual void f ();
-\& };
-\&
-\& struct C : public B, public A {};
-.Ve
-.Sp
-G++ will place the \f(CW\*(C`A\*(C'\fR base class of \f(CW\*(C`C\*(C'\fR at a nonzero offset;
-it should be placed at offset zero. G++ mistakenly believes that the
-\&\f(CW\*(C`A\*(C'\fR data member of \f(CW\*(C`B\*(C'\fR is already at offset zero.
-.IP "\(bu" 4
-Names of template functions whose types involve \f(CW\*(C`typename\*(C'\fR or
-template template parameters can be mangled incorrectly.
-.Sp
-.Vb 2
-\& template <typename Q>
-\& void f(typename Q::X) {}
-\&
-\& template <template <typename> class Q>
-\& void f(typename Q<int>::X) {}
-.Ve
-.Sp
-Instantiations of these templates may be mangled incorrectly.
-.RE
-.RS 4
-.Sp
-It also warns psABI related changes. The known psABI changes at this
-point include:
-.IP "\(bu" 4
-For SYSV/x86\-64, when passing union with long double, it is changed to
-pass in memory as specified in psABI. For example:
-.Sp
-.Vb 4
-\& union U {
-\& long double ld;
-\& int i;
-\& };
-.Ve
-.Sp
-\&\f(CW\*(C`union U\*(C'\fR will always be passed in memory.
-.RE
-.RS 4
-.RE
-.IP "\fB\-Wctor\-dtor\-privacy\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wctor-dtor-privacy ( and Objective- only)"
-Warn when a class seems unusable because all the constructors or
-destructors in that class are private, and it has neither friends nor
-public static member functions.
-.IP "\fB\-Wnoexcept\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wnoexcept ( and Objective- only)"
-Warn when a noexcept-expression evaluates to false because of a call
-to a function that does not have a non-throwing exception
-specification (i.e. \fB\f(BIthrow()\fB\fR or \fBnoexcept\fR) but is known by
-the compiler to never throw an exception.
-.IP "\fB\-Wnon\-virtual\-dtor\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wnon-virtual-dtor ( and Objective- only)"
-Warn when a class has virtual functions and accessible non-virtual
-destructor, in which case it would be possible but unsafe to delete
-an instance of a derived class through a pointer to the base class.
-This warning is also enabled if \-Weffc++ is specified.
-.IP "\fB\-Wreorder\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wreorder ( and Objective- only)"
-Warn when the order of member initializers given in the code does not
-match the order in which they must be executed. For instance:
-.Sp
-.Vb 5
-\& struct A {
-\& int i;
-\& int j;
-\& A(): j (0), i (1) { }
-\& };
-.Ve
-.Sp
-The compiler will rearrange the member initializers for \fBi\fR
-and \fBj\fR to match the declaration order of the members, emitting
-a warning to that effect. This warning is enabled by \fB\-Wall\fR.
-.PP
-The following \fB\-W...\fR options are not affected by \fB\-Wall\fR.
-.IP "\fB\-Weffc++\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Weffc++ ( and Objective- only)"
-Warn about violations of the following style guidelines from Scott Meyers'
-\&\fIEffective \*(C+\fR book:
-.RS 4
-.IP "\(bu" 4
-Item 11: Define a copy constructor and an assignment operator for classes
-with dynamically allocated memory.
-.IP "\(bu" 4
-Item 12: Prefer initialization to assignment in constructors.
-.IP "\(bu" 4
-Item 14: Make destructors virtual in base classes.
-.IP "\(bu" 4
-Item 15: Have \f(CW\*(C`operator=\*(C'\fR return a reference to \f(CW*this\fR.
-.IP "\(bu" 4
-Item 23: Don't try to return a reference when you must return an object.
-.RE
-.RS 4
-.Sp
-Also warn about violations of the following style guidelines from
-Scott Meyers' \fIMore Effective \*(C+\fR book:
-.IP "\(bu" 4
-Item 6: Distinguish between prefix and postfix forms of increment and
-decrement operators.
-.IP "\(bu" 4
-Item 7: Never overload \f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, or \f(CW\*(C`,\*(C'\fR.
-.RE
-.RS 4
-.Sp
-When selecting this option, be aware that the standard library
-headers do not obey all of these guidelines; use \fBgrep \-v\fR
-to filter out those warnings.
-.RE
-.IP "\fB\-Wstrict\-null\-sentinel\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wstrict-null-sentinel ( and Objective- only)"
-Warn also about the use of an uncasted \f(CW\*(C`NULL\*(C'\fR as sentinel. When
-compiling only with \s-1GCC\s0 this is a valid sentinel, as \f(CW\*(C`NULL\*(C'\fR is defined
-to \f(CW\*(C`_\|_null\*(C'\fR. Although it is a null pointer constant not a null pointer,
-it is guaranteed to be of the same size as a pointer. But this use is
-not portable across different compilers.
-.IP "\fB\-Wno\-non\-template\-friend\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wno-non-template-friend ( and Objective- only)"
-Disable warnings when non-templatized friend functions are declared
-within a template. Since the advent of explicit template specification
-support in G++, if the name of the friend is an unqualified-id (i.e.,
-\&\fBfriend foo(int)\fR), the \*(C+ language specification demands that the
-friend declare or define an ordinary, nontemplate function. (Section
-14.5.3). Before G++ implemented explicit specification, unqualified-ids
-could be interpreted as a particular specialization of a templatized
-function. Because this non-conforming behavior is no longer the default
-behavior for G++, \fB\-Wnon\-template\-friend\fR allows the compiler to
-check existing code for potential trouble spots and is on by default.
-This new compiler behavior can be turned off with
-\&\fB\-Wno\-non\-template\-friend\fR which keeps the conformant compiler code
-but disables the helpful warning.
-.IP "\fB\-Wold\-style\-cast\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wold-style-cast ( and Objective- only)"
-Warn if an old-style (C\-style) cast to a non-void type is used within
-a \*(C+ program. The new-style casts (\fBdynamic_cast\fR,
-\&\fBstatic_cast\fR, \fBreinterpret_cast\fR, and \fBconst_cast\fR) are
-less vulnerable to unintended effects and much easier to search for.
-.IP "\fB\-Woverloaded\-virtual\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Woverloaded-virtual ( and Objective- only)"
-Warn when a function declaration hides virtual functions from a
-base class. For example, in:
-.Sp
-.Vb 3
-\& struct A {
-\& virtual void f();
-\& };
-\&
-\& struct B: public A {
-\& void f(int);
-\& };
-.Ve
-.Sp
-the \f(CW\*(C`A\*(C'\fR class version of \f(CW\*(C`f\*(C'\fR is hidden in \f(CW\*(C`B\*(C'\fR, and code
-like:
-.Sp
-.Vb 2
-\& B* b;
-\& b\->f();
-.Ve
-.Sp
-will fail to compile.
-.IP "\fB\-Wno\-pmf\-conversions\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wno-pmf-conversions ( and Objective- only)"
-Disable the diagnostic for converting a bound pointer to member function
-to a plain pointer.
-.IP "\fB\-Wsign\-promo\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wsign-promo ( and Objective- only)"
-Warn when overload resolution chooses a promotion from unsigned or
-enumerated type to a signed type, over a conversion to an unsigned type of
-the same size. Previous versions of G++ would try to preserve
-unsignedness, but the standard mandates the current behavior.
-.Sp
-.Vb 4
-\& struct A {
-\& operator int ();
-\& A& operator = (int);
-\& };
-\&
-\& main ()
-\& {
-\& A a,b;
-\& a = b;
-\& }
-.Ve
-.Sp
-In this example, G++ will synthesize a default \fBA& operator =
-(const A&);\fR, while cfront will use the user-defined \fBoperator =\fR.
-.SS "Options Controlling Objective-C and Objective\-\*(C+ Dialects"
-.IX Subsection "Options Controlling Objective-C and Objective- Dialects"
-(\s-1NOTE:\s0 This manual does not describe the Objective-C and Objective\-\*(C+
-languages themselves.
-.PP
-This section describes the command-line options that are only meaningful
-for Objective-C and Objective\-\*(C+ programs, but you can also use most of
-the language-independent \s-1GNU\s0 compiler options.
-For example, you might compile a file \f(CW\*(C`some_class.m\*(C'\fR like this:
-.PP
-.Vb 1
-\& gcc \-g \-fgnu\-runtime \-O \-c some_class.m
-.Ve
-.PP
-In this example, \fB\-fgnu\-runtime\fR is an option meant only for
-Objective-C and Objective\-\*(C+ programs; you can use the other options with
-any language supported by \s-1GCC\s0.
-.PP
-Note that since Objective-C is an extension of the C language, Objective-C
-compilations may also use options specific to the C front-end (e.g.,
-\&\fB\-Wtraditional\fR). Similarly, Objective\-\*(C+ compilations may use
-\&\*(C+\-specific options (e.g., \fB\-Wabi\fR).
-.PP
-Here is a list of options that are \fIonly\fR for compiling Objective-C
-and Objective\-\*(C+ programs:
-.IP "\fB\-fconstant\-string\-class=\fR\fIclass-name\fR" 4
-.IX Item "-fconstant-string-class=class-name"
-Use \fIclass-name\fR as the name of the class to instantiate for each
-literal string specified with the syntax \f(CW\*(C`@"..."\*(C'\fR. The default
-class name is \f(CW\*(C`NXConstantString\*(C'\fR if the \s-1GNU\s0 runtime is being used, and
-\&\f(CW\*(C`NSConstantString\*(C'\fR if the NeXT runtime is being used (see below). The
-\&\fB\-fconstant\-cfstrings\fR option, if also present, will override the
-\&\fB\-fconstant\-string\-class\fR setting and cause \f(CW\*(C`@"..."\*(C'\fR literals
-to be laid out as constant CoreFoundation strings.
-.IP "\fB\-fgnu\-runtime\fR" 4
-.IX Item "-fgnu-runtime"
-Generate object code compatible with the standard \s-1GNU\s0 Objective-C
-runtime. This is the default for most types of systems.
-.IP "\fB\-fnext\-runtime\fR" 4
-.IX Item "-fnext-runtime"
-Generate output compatible with the NeXT runtime. This is the default
-for NeXT-based systems, including Darwin and Mac \s-1OS\s0 X. The macro
-\&\f(CW\*(C`_\|_NEXT_RUNTIME_\|_\*(C'\fR is predefined if (and only if) this option is
-used.
-.IP "\fB\-fno\-nil\-receivers\fR" 4
-.IX Item "-fno-nil-receivers"
-Assume that all Objective-C message dispatches (\f(CW\*(C`[receiver
-message:arg]\*(C'\fR) in this translation unit ensure that the receiver is
-not \f(CW\*(C`nil\*(C'\fR. This allows for more efficient entry points in the
-runtime to be used. This option is only available in conjunction with
-the NeXT runtime and \s-1ABI\s0 version 0 or 1.
-.IP "\fB\-fobjc\-abi\-version=\fR\fIn\fR" 4
-.IX Item "-fobjc-abi-version=n"
-Use version \fIn\fR of the Objective-C \s-1ABI\s0 for the selected runtime.
-This option is currently supported only for the NeXT runtime. In that
-case, Version 0 is the traditional (32\-bit) \s-1ABI\s0 without support for
-properties and other Objective-C 2.0 additions. Version 1 is the
-traditional (32\-bit) \s-1ABI\s0 with support for properties and other
-Objective-C 2.0 additions. Version 2 is the modern (64\-bit) \s-1ABI\s0. If
-nothing is specified, the default is Version 0 on 32\-bit target
-machines, and Version 2 on 64\-bit target machines.
-.IP "\fB\-fobjc\-call\-cxx\-cdtors\fR" 4
-.IX Item "-fobjc-call-cxx-cdtors"
-For each Objective-C class, check if any of its instance variables is a
-\&\*(C+ object with a non-trivial default constructor. If so, synthesize a
-special \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR instance method that will run
-non-trivial default constructors on any such instance variables, in order,
-and then return \f(CW\*(C`self\*(C'\fR. Similarly, check if any instance variable
-is a \*(C+ object with a non-trivial destructor, and if so, synthesize a
-special \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR method that will run
-all such default destructors, in reverse order.
-.Sp
-The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR
-methods thusly generated will only operate on instance variables
-declared in the current Objective-C class, and not those inherited
-from superclasses. It is the responsibility of the Objective-C
-runtime to invoke all such methods in an object's inheritance
-hierarchy. The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR methods will be invoked
-by the runtime immediately after a new object instance is allocated;
-the \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods will be invoked immediately
-before the runtime deallocates an object instance.
-.Sp
-As of this writing, only the NeXT runtime on Mac \s-1OS\s0 X 10.4 and later has
-support for invoking the \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and
-\&\f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods.
-.IP "\fB\-fobjc\-direct\-dispatch\fR" 4
-.IX Item "-fobjc-direct-dispatch"
-Allow fast jumps to the message dispatcher. On Darwin this is
-accomplished via the comm page.
-.IP "\fB\-fobjc\-exceptions\fR" 4
-.IX Item "-fobjc-exceptions"
-Enable syntactic support for structured exception handling in
-Objective-C, similar to what is offered by \*(C+ and Java. This option
-is required to use the Objective-C keywords \f(CW@try\fR,
-\&\f(CW@throw\fR, \f(CW@catch\fR, \f(CW@finally\fR and
-\&\f(CW@synchronized\fR. This option is available with both the \s-1GNU\s0
-runtime and the NeXT runtime (but not available in conjunction with
-the NeXT runtime on Mac \s-1OS\s0 X 10.2 and earlier).
-.IP "\fB\-fobjc\-gc\fR" 4
-.IX Item "-fobjc-gc"
-Enable garbage collection (\s-1GC\s0) in Objective-C and Objective\-\*(C+
-programs. This option is only available with the NeXT runtime; the
-\&\s-1GNU\s0 runtime has a different garbage collection implementation that
-does not require special compiler flags.
-.IP "\fB\-fobjc\-nilcheck\fR" 4
-.IX Item "-fobjc-nilcheck"
-For the NeXT runtime with version 2 of the \s-1ABI\s0, check for a nil
-receiver in method invocations before doing the actual method call.
-This is the default and can be disabled using
-\&\fB\-fno\-objc\-nilcheck\fR. Class methods and super calls are never
-checked for nil in this way no matter what this flag is set to.
-Currently this flag does nothing when the \s-1GNU\s0 runtime, or an older
-version of the NeXT runtime \s-1ABI\s0, is used.
-.IP "\fB\-fobjc\-std=objc1\fR" 4
-.IX Item "-fobjc-std=objc1"
-Conform to the language syntax of Objective-C 1.0, the language
-recognized by \s-1GCC\s0 4.0. This only affects the Objective-C additions to
-the C/\*(C+ language; it does not affect conformance to C/\*(C+ standards,
-which is controlled by the separate C/\*(C+ dialect option flags. When
-this option is used with the Objective-C or Objective\-\*(C+ compiler,
-any Objective-C syntax that is not recognized by \s-1GCC\s0 4.0 is rejected.
-This is useful if you need to make sure that your Objective-C code can
-be compiled with older versions of \s-1GCC\s0.
-.IP "\fB\-freplace\-objc\-classes\fR" 4
-.IX Item "-freplace-objc-classes"
-Emit a special marker instructing \fB\f(BIld\fB\|(1)\fR not to statically link in
-the resulting object file, and allow \fB\f(BIdyld\fB\|(1)\fR to load it in at
-run time instead. This is used in conjunction with the Fix-and-Continue
-debugging mode, where the object file in question may be recompiled and
-dynamically reloaded in the course of program execution, without the need
-to restart the program itself. Currently, Fix-and-Continue functionality
-is only available in conjunction with the NeXT runtime on Mac \s-1OS\s0 X 10.3
-and later.
-.IP "\fB\-fzero\-link\fR" 4
-.IX Item "-fzero-link"
-When compiling for the NeXT runtime, the compiler ordinarily replaces calls
-to \f(CW\*(C`objc_getClass("...")\*(C'\fR (when the name of the class is known at
-compile time) with static class references that get initialized at load time,
-which improves run-time performance. Specifying the \fB\-fzero\-link\fR flag
-suppresses this behavior and causes calls to \f(CW\*(C`objc_getClass("...")\*(C'\fR
-to be retained. This is useful in Zero-Link debugging mode, since it allows
-for individual class implementations to be modified during program execution.
-The \s-1GNU\s0 runtime currently always retains calls to \f(CW\*(C`objc_get_class("...")\*(C'\fR
-regardless of command line options.
-.IP "\fB\-gen\-decls\fR" 4
-.IX Item "-gen-decls"
-Dump interface declarations for all classes seen in the source file to a
-file named \fI\fIsourcename\fI.decl\fR.
-.IP "\fB\-Wassign\-intercept\fR (Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wassign-intercept (Objective-C and Objective- only)"
-Warn whenever an Objective-C assignment is being intercepted by the
-garbage collector.
-.IP "\fB\-Wno\-protocol\fR (Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wno-protocol (Objective-C and Objective- only)"
-If a class is declared to implement a protocol, a warning is issued for
-every method in the protocol that is not implemented by the class. The
-default behavior is to issue a warning for every method not explicitly
-implemented in the class, even if a method implementation is inherited
-from the superclass. If you use the \fB\-Wno\-protocol\fR option, then
-methods inherited from the superclass are considered to be implemented,
-and no warning is issued for them.
-.IP "\fB\-Wselector\fR (Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wselector (Objective-C and Objective- only)"
-Warn if multiple methods of different types for the same selector are
-found during compilation. The check is performed on the list of methods
-in the final stage of compilation. Additionally, a check is performed
-for each selector appearing in a \f(CW\*(C`@selector(...)\*(C'\fR
-expression, and a corresponding method for that selector has been found
-during compilation. Because these checks scan the method table only at
-the end of compilation, these warnings are not produced if the final
-stage of compilation is not reached, for example because an error is
-found during compilation, or because the \fB\-fsyntax\-only\fR option is
-being used.
-.IP "\fB\-Wstrict\-selector\-match\fR (Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wstrict-selector-match (Objective-C and Objective- only)"
-Warn if multiple methods with differing argument and/or return types are
-found for a given selector when attempting to send a message using this
-selector to a receiver of type \f(CW\*(C`id\*(C'\fR or \f(CW\*(C`Class\*(C'\fR. When this flag
-is off (which is the default behavior), the compiler will omit such warnings
-if any differences found are confined to types which share the same size
-and alignment.
-.IP "\fB\-Wundeclared\-selector\fR (Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wundeclared-selector (Objective-C and Objective- only)"
-Warn if a \f(CW\*(C`@selector(...)\*(C'\fR expression referring to an
-undeclared selector is found. A selector is considered undeclared if no
-method with that name has been declared before the
-\&\f(CW\*(C`@selector(...)\*(C'\fR expression, either explicitly in an
-\&\f(CW@interface\fR or \f(CW@protocol\fR declaration, or implicitly in
-an \f(CW@implementation\fR section. This option always performs its
-checks as soon as a \f(CW\*(C`@selector(...)\*(C'\fR expression is found,
-while \fB\-Wselector\fR only performs its checks in the final stage of
-compilation. This also enforces the coding style convention
-that methods and selectors must be declared before being used.
-.IP "\fB\-print\-objc\-runtime\-info\fR" 4
-.IX Item "-print-objc-runtime-info"
-Generate C header describing the largest structure that is passed by
-value, if any.
-.SS "Options to Control Diagnostic Messages Formatting"
-.IX Subsection "Options to Control Diagnostic Messages Formatting"
-Traditionally, diagnostic messages have been formatted irrespective of
-the output device's aspect (e.g. its width, ...). The options described
-below can be used to control the diagnostic messages formatting
-algorithm, e.g. how many characters per line, how often source location
-information should be reported. Right now, only the \*(C+ front end can
-honor these options. However it is expected, in the near future, that
-the remaining front ends would be able to digest them correctly.
-.IP "\fB\-fmessage\-length=\fR\fIn\fR" 4
-.IX Item "-fmessage-length=n"
-Try to format error messages so that they fit on lines of about \fIn\fR
-characters. The default is 72 characters for \fBg++\fR and 0 for the rest of
-the front ends supported by \s-1GCC\s0. If \fIn\fR is zero, then no
-line-wrapping will be done; each error message will appear on a single
-line.
-.IP "\fB\-fdiagnostics\-show\-location=once\fR" 4
-.IX Item "-fdiagnostics-show-location=once"
-Only meaningful in line-wrapping mode. Instructs the diagnostic messages
-reporter to emit \fIonce\fR source location information; that is, in
-case the message is too long to fit on a single physical line and has to
-be wrapped, the source location won't be emitted (as prefix) again,
-over and over, in subsequent continuation lines. This is the default
-behavior.
-.IP "\fB\-fdiagnostics\-show\-location=every\-line\fR" 4
-.IX Item "-fdiagnostics-show-location=every-line"
-Only meaningful in line-wrapping mode. Instructs the diagnostic
-messages reporter to emit the same source location information (as
-prefix) for physical lines that result from the process of breaking
-a message which is too long to fit on a single line.
-.IP "\fB\-fno\-diagnostics\-show\-option\fR" 4
-.IX Item "-fno-diagnostics-show-option"
-By default, each diagnostic emitted includes text which indicates the
-command line option that directly controls the diagnostic (if such an
-option is known to the diagnostic machinery). Specifying the
-\&\fB\-fno\-diagnostics\-show\-option\fR flag suppresses that behavior.
-.IP "\fB\-Wcoverage\-mismatch\fR" 4
-.IX Item "-Wcoverage-mismatch"
-Warn if feedback profiles do not match when using the
-\&\fB\-fprofile\-use\fR option.
-If a source file was changed between \fB\-fprofile\-gen\fR and
-\&\fB\-fprofile\-use\fR, the files with the profile feedback can fail
-to match the source file and \s-1GCC\s0 can not use the profile feedback
-information. By default, this warning is enabled and is treated as an
-error. \fB\-Wno\-coverage\-mismatch\fR can be used to disable the
-warning or \fB\-Wno\-error=coverage\-mismatch\fR can be used to
-disable the error. Disable the error for this warning can result in
-poorly optimized code, so disabling the error is useful only in the
-case of very minor changes such as bug fixes to an existing code-base.
-Completely disabling the warning is not recommended.
-.SS "Options to Request or Suppress Warnings"
-.IX Subsection "Options to Request or Suppress Warnings"
-Warnings are diagnostic messages that report constructions which
-are not inherently erroneous but which are risky or suggest there
-may have been an error.
-.PP
-The following language-independent options do not enable specific
-warnings but control the kinds of diagnostics produced by \s-1GCC\s0.
-.IP "\fB\-fsyntax\-only\fR" 4
-.IX Item "-fsyntax-only"
-Check the code for syntax errors, but don't do anything beyond that.
-.IP "\fB\-fmax\-errors=\fR\fIn\fR" 4
-.IX Item "-fmax-errors=n"
-Limits the maximum number of error messages to \fIn\fR, at which point
-\&\s-1GCC\s0 bails out rather than attempting to continue processing the source
-code. If \fIn\fR is 0 (the default), there is no limit on the number
-of error messages produced. If \fB\-Wfatal\-errors\fR is also
-specified, then \fB\-Wfatal\-errors\fR takes precedence over this
-option.
-.IP "\fB\-w\fR" 4
-.IX Item "-w"
-Inhibit all warning messages.
-.IP "\fB\-Werror\fR" 4
-.IX Item "-Werror"
-Make all warnings into errors.
-.IP "\fB\-Werror=\fR" 4
-.IX Item "-Werror="
-Make the specified warning into an error. The specifier for a warning
-is appended, for example \fB\-Werror=switch\fR turns the warnings
-controlled by \fB\-Wswitch\fR into errors. This switch takes a
-negative form, to be used to negate \fB\-Werror\fR for specific
-warnings, for example \fB\-Wno\-error=switch\fR makes
-\&\fB\-Wswitch\fR warnings not be errors, even when \fB\-Werror\fR
-is in effect.
-.Sp
-The warning message for each controllable warning includes the
-option which controls the warning. That option can then be used with
-\&\fB\-Werror=\fR and \fB\-Wno\-error=\fR as described above.
-(Printing of the option in the warning message can be disabled using the
-\&\fB\-fno\-diagnostics\-show\-option\fR flag.)
-.Sp
-Note that specifying \fB\-Werror=\fR\fIfoo\fR automatically implies
-\&\fB\-W\fR\fIfoo\fR. However, \fB\-Wno\-error=\fR\fIfoo\fR does not
-imply anything.
-.IP "\fB\-Wfatal\-errors\fR" 4
-.IX Item "-Wfatal-errors"
-This option causes the compiler to abort compilation on the first error
-occurred rather than trying to keep going and printing further error
-messages.
-.PP
-You can request many specific warnings with options beginning
-\&\fB\-W\fR, for example \fB\-Wimplicit\fR to request warnings on
-implicit declarations. Each of these specific warning options also
-has a negative form beginning \fB\-Wno\-\fR to turn off warnings; for
-example, \fB\-Wno\-implicit\fR. This manual lists only one of the
-two forms, whichever is not the default. For further,
-language-specific options also refer to \fB\*(C+ Dialect Options\fR and
-\&\fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
-.PP
-When an unrecognized warning option is requested (e.g.,
-\&\fB\-Wunknown\-warning\fR), \s-1GCC\s0 will emit a diagnostic stating
-that the option is not recognized. However, if the \fB\-Wno\-\fR form
-is used, the behavior is slightly different: No diagnostic will be
-produced for \fB\-Wno\-unknown\-warning\fR unless other diagnostics
-are being produced. This allows the use of new \fB\-Wno\-\fR options
-with old compilers, but if something goes wrong, the compiler will
-warn that an unrecognized option was used.
-.IP "\fB\-pedantic\fR" 4
-.IX Item "-pedantic"
-Issue all the warnings demanded by strict \s-1ISO\s0 C and \s-1ISO\s0 \*(C+;
-reject all programs that use forbidden extensions, and some other
-programs that do not follow \s-1ISO\s0 C and \s-1ISO\s0 \*(C+. For \s-1ISO\s0 C, follows the
-version of the \s-1ISO\s0 C standard specified by any \fB\-std\fR option used.
-.Sp
-Valid \s-1ISO\s0 C and \s-1ISO\s0 \*(C+ programs should compile properly with or without
-this option (though a rare few will require \fB\-ansi\fR or a
-\&\fB\-std\fR option specifying the required version of \s-1ISO\s0 C). However,
-without this option, certain \s-1GNU\s0 extensions and traditional C and \*(C+
-features are supported as well. With this option, they are rejected.
-.Sp
-\&\fB\-pedantic\fR does not cause warning messages for use of the
-alternate keywords whose names begin and end with \fB_\|_\fR. Pedantic
-warnings are also disabled in the expression that follows
-\&\f(CW\*(C`_\|_extension_\|_\*(C'\fR. However, only system header files should use
-these escape routes; application programs should avoid them.
-.Sp
-Some users try to use \fB\-pedantic\fR to check programs for strict \s-1ISO\s0
-C conformance. They soon find that it does not do quite what they want:
-it finds some non-ISO practices, but not all\-\-\-only those for which
-\&\s-1ISO\s0 C \fIrequires\fR a diagnostic, and some others for which
-diagnostics have been added.
-.Sp
-A feature to report any failure to conform to \s-1ISO\s0 C might be useful in
-some instances, but would require considerable additional work and would
-be quite different from \fB\-pedantic\fR. We don't have plans to
-support such a feature in the near future.
-.Sp
-Where the standard specified with \fB\-std\fR represents a \s-1GNU\s0
-extended dialect of C, such as \fBgnu90\fR or \fBgnu99\fR, there is a
-corresponding \fIbase standard\fR, the version of \s-1ISO\s0 C on which the \s-1GNU\s0
-extended dialect is based. Warnings from \fB\-pedantic\fR are given
-where they are required by the base standard. (It would not make sense
-for such warnings to be given only for features not in the specified \s-1GNU\s0
-C dialect, since by definition the \s-1GNU\s0 dialects of C include all
-features the compiler supports with the given option, and there would be
-nothing to warn about.)
-.IP "\fB\-pedantic\-errors\fR" 4
-.IX Item "-pedantic-errors"
-Like \fB\-pedantic\fR, except that errors are produced rather than
-warnings.
-.IP "\fB\-Wall\fR" 4
-.IX Item "-Wall"
-This enables all the warnings about constructions that some users
-consider questionable, and that are easy to avoid (or modify to
-prevent the warning), even in conjunction with macros. This also
-enables some language-specific warnings described in \fB\*(C+ Dialect
-Options\fR and \fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
-.Sp
-\&\fB\-Wall\fR turns on the following warning flags:
-.Sp
-\&\fB\-Waddress
-\&\-Warray\-bounds\fR (only with\fB \fR\fB\-O2\fR)
-\&\fB\-Wc++0x\-compat
-\&\-Wchar\-subscripts
-\&\-Wenum\-compare\fR (in C/Objc; this is on by default in \*(C+)
-\&\fB\-Wimplicit\-int\fR (C and Objective-C only)
-\&\fB\-Wimplicit\-function\-declaration\fR (C and Objective-C only)
-\&\fB\-Wcomment
-\&\-Wformat
-\&\-Wmain\fR (only for C/ObjC and unless\fB \fR\fB\-ffreestanding\fR)
-\&\fB\-Wmaybe\-uninitialized
-\&\-Wmissing\-braces
-\&\-Wnonnull
-\&\-Wparentheses
-\&\-Wpointer\-sign
-\&\-Wreorder
-\&\-Wreturn\-type
-\&\-Wripa\-opt\-mismatch
-\&\-Wsequence\-point
-\&\-Wsign\-compare\fR (only in \*(C+)
-\&\fB\-Wstrict\-aliasing
-\&\-Wstrict\-overflow=1
-\&\-Wswitch
-\&\-Wtrigraphs
-\&\-Wuninitialized
-\&\-Wunknown\-pragmas
-\&\-Wunused\-function
-\&\-Wunused\-label
-\&\-Wunused\-value
-\&\-Wunused\-variable
-\&\-Wvolatile\-register\-var\fR
-.Sp
-Note that some warning flags are not implied by \fB\-Wall\fR. Some of
-them warn about constructions that users generally do not consider
-questionable, but which occasionally you might wish to check for;
-others warn about constructions that are necessary or hard to avoid in
-some cases, and there is no simple way to modify the code to suppress
-the warning. Some of them are enabled by \fB\-Wextra\fR but many of
-them must be enabled individually.
-.IP "\fB\-Wextra\fR" 4
-.IX Item "-Wextra"
-This enables some extra warning flags that are not enabled by
-\&\fB\-Wall\fR. (This option used to be called \fB\-W\fR. The older
-name is still supported, but the newer name is more descriptive.)
-.Sp
-\&\fB\-Wclobbered
-\&\-Wempty\-body
-\&\-Wignored\-qualifiers
-\&\-Wmissing\-field\-initializers
-\&\-Wmissing\-parameter\-type\fR (C only)
-\&\fB\-Wold\-style\-declaration\fR (C only)
-\&\fB\-Woverride\-init
-\&\-Wsign\-compare
-\&\-Wtype\-limits
-\&\-Wuninitialized
-\&\-Wunused\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)
-\&\fB\-Wunused\-but\-set\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR) \fB \fR
-.Sp
-The option \fB\-Wextra\fR also prints warning messages for the
-following cases:
-.RS 4
-.IP "\(bu" 4
-A pointer is compared against integer zero with \fB<\fR, \fB<=\fR,
-\&\fB>\fR, or \fB>=\fR.
-.IP "\(bu" 4
-(\*(C+ only) An enumerator and a non-enumerator both appear in a
-conditional expression.
-.IP "\(bu" 4
-(\*(C+ only) Ambiguous virtual bases.
-.IP "\(bu" 4
-(\*(C+ only) Subscripting an array which has been declared \fBregister\fR.
-.IP "\(bu" 4
-(\*(C+ only) Taking the address of a variable which has been declared
-\&\fBregister\fR.
-.IP "\(bu" 4
-(\*(C+ only) A base class is not initialized in a derived class' copy
-constructor.
-.RE
-.RS 4
-.RE
-.IP "\fB\-Wchar\-subscripts\fR" 4
-.IX Item "-Wchar-subscripts"
-Warn if an array subscript has type \f(CW\*(C`char\*(C'\fR. This is a common cause
-of error, as programmers often forget that this type is signed on some
-machines.
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wcomment\fR" 4
-.IX Item "-Wcomment"
-Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
-comment, or whenever a Backslash-Newline appears in a \fB//\fR comment.
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wno\-cpp\fR" 4
-.IX Item "-Wno-cpp"
-(C, Objective-C, \*(C+, Objective\-\*(C+ and Fortran only)
-.Sp
-Suppress warning messages emitted by \f(CW\*(C`#warning\*(C'\fR directives.
-.IP "\fB\-Wdouble\-promotion\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wdouble-promotion (C, , Objective-C and Objective- only)"
-Give a warning when a value of type \f(CW\*(C`float\*(C'\fR is implicitly
-promoted to \f(CW\*(C`double\*(C'\fR. CPUs with a 32\-bit \*(L"single-precision\*(R"
-floating-point unit implement \f(CW\*(C`float\*(C'\fR in hardware, but emulate
-\&\f(CW\*(C`double\*(C'\fR in software. On such a machine, doing computations
-using \f(CW\*(C`double\*(C'\fR values is much more expensive because of the
-overhead required for software emulation.
-.Sp
-It is easy to accidentally do computations with \f(CW\*(C`double\*(C'\fR because
-floating-point literals are implicitly of type \f(CW\*(C`double\*(C'\fR. For
-example, in:
-.Sp
-.Vb 4
-\& float area(float radius)
-\& {
-\& return 3.14159 * radius * radius;
-\& }
-.Ve
-.Sp
-the compiler will perform the entire computation with \f(CW\*(C`double\*(C'\fR
-because the floating-point literal is a \f(CW\*(C`double\*(C'\fR.
-.IP "\fB\-Wformat\fR" 4
-.IX Item "-Wformat"
-Check calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR, etc., to make sure that
-the arguments supplied have types appropriate to the format string
-specified, and that the conversions specified in the format string make
-sense. This includes standard functions, and others specified by format
-attributes, in the \f(CW\*(C`printf\*(C'\fR,
-\&\f(CW\*(C`scanf\*(C'\fR, \f(CW\*(C`strftime\*(C'\fR and \f(CW\*(C`strfmon\*(C'\fR (an X/Open extension,
-not in the C standard) families (or other target-specific families).
-Which functions are checked without format attributes having been
-specified depends on the standard version selected, and such checks of
-functions without the attribute specified are disabled by
-\&\fB\-ffreestanding\fR or \fB\-fno\-builtin\fR.
-.Sp
-The formats are checked against the format features supported by \s-1GNU\s0
-libc version 2.2. These include all \s-1ISO\s0 C90 and C99 features, as well
-as features from the Single Unix Specification and some \s-1BSD\s0 and \s-1GNU\s0
-extensions. Other library implementations may not support all these
-features; \s-1GCC\s0 does not support warning about features that go beyond a
-particular library's limitations. However, if \fB\-pedantic\fR is used
-with \fB\-Wformat\fR, warnings will be given about format features not
-in the selected standard version (but not for \f(CW\*(C`strfmon\*(C'\fR formats,
-since those are not in any version of the C standard).
-.Sp
-Since \fB\-Wformat\fR also checks for null format arguments for
-several functions, \fB\-Wformat\fR also implies \fB\-Wnonnull\fR.
-.Sp
-\&\fB\-Wformat\fR is included in \fB\-Wall\fR. For more control over some
-aspects of format checking, the options \fB\-Wformat\-y2k\fR,
-\&\fB\-Wno\-format\-extra\-args\fR, \fB\-Wno\-format\-zero\-length\fR,
-\&\fB\-Wformat\-nonliteral\fR, \fB\-Wformat\-security\fR, and
-\&\fB\-Wformat=2\fR are available, but are not included in \fB\-Wall\fR.
-.IP "\fB\-Wformat\-y2k\fR" 4
-.IX Item "-Wformat-y2k"
-If \fB\-Wformat\fR is specified, also warn about \f(CW\*(C`strftime\*(C'\fR
-formats which may yield only a two-digit year.
-.IP "\fB\-Wno\-format\-contains\-nul\fR" 4
-.IX Item "-Wno-format-contains-nul"
-If \fB\-Wformat\fR is specified, do not warn about format strings that
-contain \s-1NUL\s0 bytes.
-.IP "\fB\-Wno\-format\-extra\-args\fR" 4
-.IX Item "-Wno-format-extra-args"
-If \fB\-Wformat\fR is specified, do not warn about excess arguments to a
-\&\f(CW\*(C`printf\*(C'\fR or \f(CW\*(C`scanf\*(C'\fR format function. The C standard specifies
-that such arguments are ignored.
-.Sp
-Where the unused arguments lie between used arguments that are
-specified with \fB$\fR operand number specifications, normally
-warnings are still given, since the implementation could not know what
-type to pass to \f(CW\*(C`va_arg\*(C'\fR to skip the unused arguments. However,
-in the case of \f(CW\*(C`scanf\*(C'\fR formats, this option will suppress the
-warning if the unused arguments are all pointers, since the Single
-Unix Specification says that such unused arguments are allowed.
-.IP "\fB\-Wno\-format\-zero\-length\fR (C and Objective-C only)" 4
-.IX Item "-Wno-format-zero-length (C and Objective-C only)"
-If \fB\-Wformat\fR is specified, do not warn about zero-length formats.
-The C standard specifies that zero-length formats are allowed.
-.IP "\fB\-Wformat\-nonliteral\fR" 4
-.IX Item "-Wformat-nonliteral"
-If \fB\-Wformat\fR is specified, also warn if the format string is not a
-string literal and so cannot be checked, unless the format function
-takes its format arguments as a \f(CW\*(C`va_list\*(C'\fR.
-.IP "\fB\-Wformat\-security\fR" 4
-.IX Item "-Wformat-security"
-If \fB\-Wformat\fR is specified, also warn about uses of format
-functions that represent possible security problems. At present, this
-warns about calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR functions where the
-format string is not a string literal and there are no format arguments,
-as in \f(CW\*(C`printf (foo);\*(C'\fR. This may be a security hole if the format
-string came from untrusted input and contains \fB\f(CB%n\fB\fR. (This is
-currently a subset of what \fB\-Wformat\-nonliteral\fR warns about, but
-in future warnings may be added to \fB\-Wformat\-security\fR that are not
-included in \fB\-Wformat\-nonliteral\fR.)
-.IP "\fB\-Wformat=2\fR" 4
-.IX Item "-Wformat=2"
-Enable \fB\-Wformat\fR plus format checks not included in
-\&\fB\-Wformat\fR. Currently equivalent to \fB\-Wformat
-\&\-Wformat\-nonliteral \-Wformat\-security \-Wformat\-y2k\fR.
-.IP "\fB\-Wnonnull\fR (C, \*(C+, Objective-C, and Objective\-\*(C+ only)" 4
-.IX Item "-Wnonnull (C, , Objective-C, and Objective- only)"
-Warn about passing a null pointer for arguments marked as
-requiring a non-null value by the \f(CW\*(C`nonnull\*(C'\fR function attribute.
-.Sp
-\&\fB\-Wnonnull\fR is included in \fB\-Wall\fR and \fB\-Wformat\fR. It
-can be disabled with the \fB\-Wno\-nonnull\fR option.
-.IP "\fB\-Winit\-self\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Winit-self (C, , Objective-C and Objective- only)"
-Warn about uninitialized variables which are initialized with themselves.
-Note this option can only be used with the \fB\-Wuninitialized\fR option.
-.Sp
-For example, \s-1GCC\s0 will warn about \f(CW\*(C`i\*(C'\fR being uninitialized in the
-following snippet only when \fB\-Winit\-self\fR has been specified:
-.Sp
-.Vb 5
-\& int f()
-\& {
-\& int i = i;
-\& return i;
-\& }
-.Ve
-.IP "\fB\-Wimplicit\-int\fR (C and Objective-C only)" 4
-.IX Item "-Wimplicit-int (C and Objective-C only)"
-Warn when a declaration does not specify a type.
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wimplicit\-function\-declaration\fR (C and Objective-C only)" 4
-.IX Item "-Wimplicit-function-declaration (C and Objective-C only)"
-Give a warning whenever a function is used before being declared. In
-C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR), this warning is
-enabled by default and it is made into an error by
-\&\fB\-pedantic\-errors\fR. This warning is also enabled by
-\&\fB\-Wall\fR.
-.IP "\fB\-Wimplicit\fR (C and Objective-C only)" 4
-.IX Item "-Wimplicit (C and Objective-C only)"
-Same as \fB\-Wimplicit\-int\fR and \fB\-Wimplicit\-function\-declaration\fR.
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wignored\-qualifiers\fR (C and \*(C+ only)" 4
-.IX Item "-Wignored-qualifiers (C and only)"
-Warn if the return type of a function has a type qualifier
-such as \f(CW\*(C`const\*(C'\fR. For \s-1ISO\s0 C such a type qualifier has no effect,
-since the value returned by a function is not an lvalue.
-For \*(C+, the warning is only emitted for scalar types or \f(CW\*(C`void\*(C'\fR.
-\&\s-1ISO\s0 C prohibits qualified \f(CW\*(C`void\*(C'\fR return types on function
-definitions, so such return types always receive a warning
-even without this option.
-.Sp
-This warning is also enabled by \fB\-Wextra\fR.
-.IP "\fB\-Wmain\fR" 4
-.IX Item "-Wmain"
-Warn if the type of \fBmain\fR is suspicious. \fBmain\fR should be
-a function with external linkage, returning int, taking either zero
-arguments, two, or three arguments of appropriate types. This warning
-is enabled by default in \*(C+ and is enabled by either \fB\-Wall\fR
-or \fB\-pedantic\fR.
-.IP "\fB\-Wmissing\-braces\fR" 4
-.IX Item "-Wmissing-braces"
-Warn if an aggregate or union initializer is not fully bracketed. In
-the following example, the initializer for \fBa\fR is not fully
-bracketed, but that for \fBb\fR is fully bracketed.
-.Sp
-.Vb 2
-\& int a[2][2] = { 0, 1, 2, 3 };
-\& int b[2][2] = { { 0, 1 }, { 2, 3 } };
-.Ve
-.Sp
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wmissing\-include\-dirs\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wmissing-include-dirs (C, , Objective-C and Objective- only)"
-Warn if a user-supplied include directory does not exist.
-.IP "\fB\-Wparentheses\fR" 4
-.IX Item "-Wparentheses"
-Warn if parentheses are omitted in certain contexts, such
-as when there is an assignment in a context where a truth value
-is expected, or when operators are nested whose precedence people
-often get confused about.
-.Sp
-Also warn if a comparison like \fBx<=y<=z\fR appears; this is
-equivalent to \fB(x<=y ? 1 : 0) <= z\fR, which is a different
-interpretation from that of ordinary mathematical notation.
-.Sp
-Also warn about constructions where there may be confusion to which
-\&\f(CW\*(C`if\*(C'\fR statement an \f(CW\*(C`else\*(C'\fR branch belongs. Here is an example of
-such a case:
-.Sp
-.Vb 7
-\& {
-\& if (a)
-\& if (b)
-\& foo ();
-\& else
-\& bar ();
-\& }
-.Ve
-.Sp
-In C/\*(C+, every \f(CW\*(C`else\*(C'\fR branch belongs to the innermost possible
-\&\f(CW\*(C`if\*(C'\fR statement, which in this example is \f(CW\*(C`if (b)\*(C'\fR. This is
-often not what the programmer expected, as illustrated in the above
-example by indentation the programmer chose. When there is the
-potential for this confusion, \s-1GCC\s0 will issue a warning when this flag
-is specified. To eliminate the warning, add explicit braces around
-the innermost \f(CW\*(C`if\*(C'\fR statement so there is no way the \f(CW\*(C`else\*(C'\fR
-could belong to the enclosing \f(CW\*(C`if\*(C'\fR. The resulting code would
-look like this:
-.Sp
-.Vb 9
-\& {
-\& if (a)
-\& {
-\& if (b)
-\& foo ();
-\& else
-\& bar ();
-\& }
-\& }
-.Ve
-.Sp
-Also warn for dangerous uses of the
-?: with omitted middle operand \s-1GNU\s0 extension. When the condition
-in the ?: operator is a boolean expression the omitted value will
-be always 1. Often the user expects it to be a value computed
-inside the conditional expression instead.
-.Sp
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wsequence\-point\fR" 4
-.IX Item "-Wsequence-point"
-Warn about code that may have undefined semantics because of violations
-of sequence point rules in the C and \*(C+ standards.
-.Sp
-The C and \*(C+ standards defines the order in which expressions in a C/\*(C+
-program are evaluated in terms of \fIsequence points\fR, which represent
-a partial ordering between the execution of parts of the program: those
-executed before the sequence point, and those executed after it. These
-occur after the evaluation of a full expression (one which is not part
-of a larger expression), after the evaluation of the first operand of a
-\&\f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, \f(CW\*(C`? :\*(C'\fR or \f(CW\*(C`,\*(C'\fR (comma) operator, before a
-function is called (but after the evaluation of its arguments and the
-expression denoting the called function), and in certain other places.
-Other than as expressed by the sequence point rules, the order of
-evaluation of subexpressions of an expression is not specified. All
-these rules describe only a partial order rather than a total order,
-since, for example, if two functions are called within one expression
-with no sequence point between them, the order in which the functions
-are called is not specified. However, the standards committee have
-ruled that function calls do not overlap.
-.Sp
-It is not specified when between sequence points modifications to the
-values of objects take effect. Programs whose behavior depends on this
-have undefined behavior; the C and \*(C+ standards specify that \*(L"Between
-the previous and next sequence point an object shall have its stored
-value modified at most once by the evaluation of an expression.
-Furthermore, the prior value shall be read only to determine the value
-to be stored.\*(R". If a program breaks these rules, the results on any
-particular implementation are entirely unpredictable.
-.Sp
-Examples of code with undefined behavior are \f(CW\*(C`a = a++;\*(C'\fR, \f(CW\*(C`a[n]
-= b[n++]\*(C'\fR and \f(CW\*(C`a[i++] = i;\*(C'\fR. Some more complicated cases are not
-diagnosed by this option, and it may give an occasional false positive
-result, but in general it has been found fairly effective at detecting
-this sort of problem in programs.
-.Sp
-The standard is worded confusingly, therefore there is some debate
-over the precise meaning of the sequence point rules in subtle cases.
-Links to discussions of the problem, including proposed formal
-definitions, may be found on the \s-1GCC\s0 readings page, at
-<\fBhttp://gcc.gnu.org/readings.html\fR>.
-.Sp
-This warning is enabled by \fB\-Wall\fR for C and \*(C+.
-.IP "\fB\-Wself\-assign\fR" 4
-.IX Item "-Wself-assign"
-Warn about self-assignment and self-initialization. This warning is intended
-for detecting accidental self-assignment due to typos, and therefore does
-not warn on a statement that is semantically a self-assignment after
-constant folding. Here is an example of what will trigger a self-assign
-warning and what will not:
-.Sp
-.Vb 6
-\& void func()
-\& {
-\& int i = 2;
-\& int x = x; /* warn */
-\& float f = 5.0;
-\& double a[3];
-\&
-\& i = i + 0; /* not warn */
-\& f = f / 1; /* not warn */
-\& a[1] = a[1]; /* warn */
-\& i += 0; /* not warn */
-\& }
-.Ve
-.Sp
-In \*(C+ it will not warn on self-assignment of non-POD variables unless
-\&\fB\-Wself\-assign\-non\-pod\fR is also enabled.
-.IP "\fB\-Wself\-assign\-non\-pod\fR" 4
-.IX Item "-Wself-assign-non-pod"
-Warn about self-assignment of non-POD variables. This is a \*(C+\-specific
-warning and only effective when \fB\-Wself\-assign\fR is enabled.
-.Sp
-There are cases where self-assignment might be intentional. For example,
-a \*(C+ programmer might write code to test whether an overloaded
-\&\f(CW\*(C`operator=\*(C'\fR works when the same object is assigned to itself.
-One way to work around the self-assign warning in such cases when this flag
-is enabled is using the functional form \f(CW\*(C`object.operator=(object)\*(C'\fR
-instead of the assignment form \f(CW\*(C`object = object\*(C'\fR, as shown in the
-following example.
-.Sp
-.Vb 3
-\& void test_func()
-\& {
-\& MyType t;
-\&
-\& t.operator=(t); // not warn
-\& t = t; // warn
-\& }
-.Ve
-.IP "\fB\-Wreturn\-type\fR" 4
-.IX Item "-Wreturn-type"
-Warn whenever a function is defined with a return-type that defaults
-to \f(CW\*(C`int\*(C'\fR. Also warn about any \f(CW\*(C`return\*(C'\fR statement with no
-return-value in a function whose return-type is not \f(CW\*(C`void\*(C'\fR
-(falling off the end of the function body is considered returning
-without a value), and about a \f(CW\*(C`return\*(C'\fR statement with an
-expression in a function whose return-type is \f(CW\*(C`void\*(C'\fR.
-.Sp
-For \*(C+, a function without return type always produces a diagnostic
-message, even when \fB\-Wno\-return\-type\fR is specified. The only
-exceptions are \fBmain\fR and functions defined in system headers.
-.Sp
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wripa\-opt\-mismatch\fR" 4
-.IX Item "-Wripa-opt-mismatch"
-When doing an \s-1FDO\s0 build with \fB\-fprofile\-use\fR and \fB\-fripa\fR,
-warn if importing an axuiliary module that was built with a different
-\&\s-1GCC\s0 command line during the profile-generate phase than the primary
-module.
-.Sp
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wswitch\fR" 4
-.IX Item "-Wswitch"
-Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
-and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
-enumeration. (The presence of a \f(CW\*(C`default\*(C'\fR label prevents this
-warning.) \f(CW\*(C`case\*(C'\fR labels outside the enumeration range also
-provoke warnings when this option is used (even if there is a
-\&\f(CW\*(C`default\*(C'\fR label).
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wswitch\-default\fR" 4
-.IX Item "-Wswitch-default"
-Warn whenever a \f(CW\*(C`switch\*(C'\fR statement does not have a \f(CW\*(C`default\*(C'\fR
-case.
-.IP "\fB\-Wswitch\-enum\fR" 4
-.IX Item "-Wswitch-enum"
-Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
-and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
-enumeration. \f(CW\*(C`case\*(C'\fR labels outside the enumeration range also
-provoke warnings when this option is used. The only difference
-between \fB\-Wswitch\fR and this option is that this option gives a
-warning about an omitted enumeration code even if there is a
-\&\f(CW\*(C`default\*(C'\fR label.
-.IP "\fB\-Wsync\-nand\fR (C and \*(C+ only)" 4
-.IX Item "-Wsync-nand (C and only)"
-Warn when \f(CW\*(C`_\|_sync_fetch_and_nand\*(C'\fR and \f(CW\*(C`_\|_sync_nand_and_fetch\*(C'\fR
-built-in functions are used. These functions changed semantics in \s-1GCC\s0 4.4.
-.IP "\fB\-Wthread\-safety\fR" 4
-.IX Item "-Wthread-safety"
-Warn about potential thread safety issues when the code is annotated with
-thread safety attributes.
-.IP "\fBWthread-unguarded-var\fR" 4
-.IX Item "Wthread-unguarded-var"
-Warn about shared variables not properly protected by locks specified in the
-attributes. This flag is effective only with \fB\-Wthread\-safety\fR and
-enabled by default.
-.IP "\fBWthread-unguarded-func\fR" 4
-.IX Item "Wthread-unguarded-func"
-Warn about function calls not properly protected by locks specified in the
-attributes. This flag is effective only with \fB\-Wthread\-safety\fR and
-enabled by default.
-.IP "\fBWthread-mismatched-lock-order\fR" 4
-.IX Item "Wthread-mismatched-lock-order"
-Warn about lock acquisition order inconsistent with what specified in the
-attributes. This flag is effective only with \fB\-Wthread\-safety\fR and
-enabled by default.
-.IP "\fBWthread-mismatched-lock-acq-rel\fR" 4
-.IX Item "Wthread-mismatched-lock-acq-rel"
-Warn about mismatched lock acquisition and release. This flag is effective only
-with \fB\-Wthread\-safety\fR and enabled by default.
-.IP "\fBWthread-reentrant-lock\fR" 4
-.IX Item "Wthread-reentrant-lock"
-Warn about a lock being acquired recursively. This flag is effective only
-with \fB\-Wthread\-safety\fR and enabled by default.
-.IP "\fBWthread-unsupported-lock-name\fR" 4
-.IX Item "Wthread-unsupported-lock-name"
-Warn about uses of unsupported lock names in attributes. This flag is effective
-only with \fB\-Wthread\-safety\fR and disabled by default.
-.IP "\fBWthread-attr-bind-param\fR" 4
-.IX Item "Wthread-attr-bind-param"
-Make the thread safety analysis try to bind the function parameters used in
-the attributes. This flag is effective only with \fB\-Wthread\-safety\fR
-and enabled by default.
-.IP "\fB\-Wtrigraphs\fR" 4
-.IX Item "-Wtrigraphs"
-Warn if any trigraphs are encountered that might change the meaning of
-the program (trigraphs within comments are not warned about).
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wunused\-but\-set\-parameter\fR" 4
-.IX Item "-Wunused-but-set-parameter"
-Warn whenever a function parameter is assigned to, but otherwise unused
-(aside from its declaration).
-.Sp
-To suppress this warning use the \fBunused\fR attribute.
-.Sp
-This warning is also enabled by \fB\-Wunused\fR together with
-\&\fB\-Wextra\fR.
-.IP "\fB\-Wunused\-but\-set\-variable\fR" 4
-.IX Item "-Wunused-but-set-variable"
-Warn whenever a local variable is assigned to, but otherwise unused
-(aside from its declaration).
-This warning is enabled by \fB\-Wall\fR.
-.Sp
-To suppress this warning use the \fBunused\fR attribute.
-.Sp
-This warning is also enabled by \fB\-Wunused\fR, which is enabled
-by \fB\-Wall\fR.
-.IP "\fB\-Wunused\-function\fR" 4
-.IX Item "-Wunused-function"
-Warn whenever a static function is declared but not defined or a
-non-inline static function is unused.
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wunused\-label\fR" 4
-.IX Item "-Wunused-label"
-Warn whenever a label is declared but not used.
-This warning is enabled by \fB\-Wall\fR.
-.Sp
-To suppress this warning use the \fBunused\fR attribute.
-.IP "\fB\-Wunused\-parameter\fR" 4
-.IX Item "-Wunused-parameter"
-Warn whenever a function parameter is unused aside from its declaration.
-.Sp
-To suppress this warning use the \fBunused\fR attribute.
-.IP "\fB\-Wno\-unused\-result\fR" 4
-.IX Item "-Wno-unused-result"
-Do not warn if a caller of a function marked with attribute
-\&\f(CW\*(C`warn_unused_result\*(C'\fR does not use
-its return value. The default is \fB\-Wunused\-result\fR.
-.IP "\fB\-Wunused\-variable\fR" 4
-.IX Item "-Wunused-variable"
-Warn whenever a local variable or non-constant static variable is unused
-aside from its declaration.
-This warning is enabled by \fB\-Wall\fR.
-.Sp
-To suppress this warning use the \fBunused\fR attribute.
-.Sp
-Note that a classic way to avoid \fB\-Wunused\-variable\fR warning is
-using \f(CW\*(C`x = x\*(C'\fR, but that does not work with \fB\-Wself\-assign\fR.
-Use \f(CW\*(C`(void) x\*(C'\fR or \f(CW\*(C`static_cast<void>(x)\*(C'\fR instead.
-.IP "\fB\-Wunused\-value\fR" 4
-.IX Item "-Wunused-value"
-Warn whenever a statement computes a result that is explicitly not
-used. To suppress this warning cast the unused expression to
-\&\fBvoid\fR. This includes an expression-statement or the left-hand
-side of a comma expression that contains no side effects. For example,
-an expression such as \fBx[i,j]\fR will cause a warning, while
-\&\fBx[(void)i,j]\fR will not.
-.Sp
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wunused\fR" 4
-.IX Item "-Wunused"
-All the above \fB\-Wunused\fR options combined.
-.Sp
-In order to get a warning about an unused function parameter, you must
-either specify \fB\-Wextra \-Wunused\fR (note that \fB\-Wall\fR implies
-\&\fB\-Wunused\fR), or separately specify \fB\-Wunused\-parameter\fR.
-.IP "\fB\-Wuninitialized\fR" 4
-.IX Item "-Wuninitialized"
-Warn if an automatic variable is used without first being initialized
-or if a variable may be clobbered by a \f(CW\*(C`setjmp\*(C'\fR call. In \*(C+,
-warn if a non-static reference or non-static \fBconst\fR member
-appears in a class without constructors.
-.Sp
-If you want to warn about code which uses the uninitialized value of the
-variable in its own initializer, use the \fB\-Winit\-self\fR option.
-.Sp
-These warnings occur for individual uninitialized or clobbered
-elements of structure, union or array variables as well as for
-variables which are uninitialized or clobbered as a whole. They do
-not occur for variables or elements declared \f(CW\*(C`volatile\*(C'\fR. Because
-these warnings depend on optimization, the exact variables or elements
-for which there are warnings will depend on the precise optimization
-options and version of \s-1GCC\s0 used.
-.Sp
-Note that there may be no warning about a variable that is used only
-to compute a value that itself is never used, because such
-computations may be deleted by data flow analysis before the warnings
-are printed.
-.IP "\fB\-Wmaybe\-uninitialized\fR" 4
-.IX Item "-Wmaybe-uninitialized"
-For an automatic variable, if there exists a path from the function
-entry to a use of the variable that is initialized, but there exist
-some other paths the variable is not initialized, the compiler will
-emit a warning if it can not prove the uninitialized paths do not
-happen at runtime. These warnings are made optional because \s-1GCC\s0 is
-not smart enough to see all the reasons why the code might be correct
-despite appearing to have an error. Here is one example of how
-this can happen:
-.Sp
-.Vb 12
-\& {
-\& int x;
-\& switch (y)
-\& {
-\& case 1: x = 1;
-\& break;
-\& case 2: x = 4;
-\& break;
-\& case 3: x = 5;
-\& }
-\& foo (x);
-\& }
-.Ve
-.Sp
-If the value of \f(CW\*(C`y\*(C'\fR is always 1, 2 or 3, then \f(CW\*(C`x\*(C'\fR is
-always initialized, but \s-1GCC\s0 doesn't know this. To suppress the
-warning, the user needs to provide a default case with \fIassert\fR\|(0) or
-similar code.
-.Sp
-This option also warns when a non-volatile automatic variable might be
-changed by a call to \f(CW\*(C`longjmp\*(C'\fR. These warnings as well are possible
-only in optimizing compilation.
-.Sp
-The compiler sees only the calls to \f(CW\*(C`setjmp\*(C'\fR. It cannot know
-where \f(CW\*(C`longjmp\*(C'\fR will be called; in fact, a signal handler could
-call it at any point in the code. As a result, you may get a warning
-even when there is in fact no problem because \f(CW\*(C`longjmp\*(C'\fR cannot
-in fact be called at the place which would cause a problem.
-.Sp
-Some spurious warnings can be avoided if you declare all the functions
-you use that never return as \f(CW\*(C`noreturn\*(C'\fR.
-.Sp
-This warning is enabled by \fB\-Wall\fR or \fB\-Wextra\fR.
-.IP "\fB\-Wunknown\-pragmas\fR" 4
-.IX Item "-Wunknown-pragmas"
-Warn when a #pragma directive is encountered which is not understood by
-\&\s-1GCC\s0. If this command line option is used, warnings will even be issued
-for unknown pragmas in system header files. This is not the case if
-the warnings were only enabled by the \fB\-Wall\fR command line option.
-.IP "\fB\-Wno\-pragmas\fR" 4
-.IX Item "-Wno-pragmas"
-Do not warn about misuses of pragmas, such as incorrect parameters,
-invalid syntax, or conflicts between pragmas. See also
-\&\fB\-Wunknown\-pragmas\fR.
-.IP "\fB\-Wstrict\-aliasing\fR" 4
-.IX Item "-Wstrict-aliasing"
-This option is only active when \fB\-fstrict\-aliasing\fR is active.
-It warns about code which might break the strict aliasing rules that the
-compiler is using for optimization. The warning does not catch all
-cases, but does attempt to catch the more common pitfalls. It is
-included in \fB\-Wall\fR.
-It is equivalent to \fB\-Wstrict\-aliasing=3\fR
-.IP "\fB\-Wstrict\-aliasing=n\fR" 4
-.IX Item "-Wstrict-aliasing=n"
-This option is only active when \fB\-fstrict\-aliasing\fR is active.
-It warns about code which might break the strict aliasing rules that the
-compiler is using for optimization.
-Higher levels correspond to higher accuracy (fewer false positives).
-Higher levels also correspond to more effort, similar to the way \-O works.
-\&\fB\-Wstrict\-aliasing\fR is equivalent to \fB\-Wstrict\-aliasing=n\fR,
-with n=3.
-.Sp
-Level 1: Most aggressive, quick, least accurate.
-Possibly useful when higher levels
-do not warn but \-fstrict\-aliasing still breaks the code, as it has very few
-false negatives. However, it has many false positives.
-Warns for all pointer conversions between possibly incompatible types,
-even if never dereferenced. Runs in the frontend only.
-.Sp
-Level 2: Aggressive, quick, not too precise.
-May still have many false positives (not as many as level 1 though),
-and few false negatives (but possibly more than level 1).
-Unlike level 1, it only warns when an address is taken. Warns about
-incomplete types. Runs in the frontend only.
-.Sp
-Level 3 (default for \fB\-Wstrict\-aliasing\fR):
-Should have very few false positives and few false
-negatives. Slightly slower than levels 1 or 2 when optimization is enabled.
-Takes care of the common pun+dereference pattern in the frontend:
-\&\f(CW\*(C`*(int*)&some_float\*(C'\fR.
-If optimization is enabled, it also runs in the backend, where it deals
-with multiple statement cases using flow-sensitive points-to information.
-Only warns when the converted pointer is dereferenced.
-Does not warn about incomplete types.
-.IP "\fB\-Wstrict\-overflow\fR" 4
-.IX Item "-Wstrict-overflow"
-.PD 0
-.IP "\fB\-Wstrict\-overflow=\fR\fIn\fR" 4
-.IX Item "-Wstrict-overflow=n"
-.PD
-This option is only active when \fB\-fstrict\-overflow\fR is active.
-It warns about cases where the compiler optimizes based on the
-assumption that signed overflow does not occur. Note that it does not
-warn about all cases where the code might overflow: it only warns
-about cases where the compiler implements some optimization. Thus
-this warning depends on the optimization level.
-.Sp
-An optimization which assumes that signed overflow does not occur is
-perfectly safe if the values of the variables involved are such that
-overflow never does, in fact, occur. Therefore this warning can
-easily give a false positive: a warning about code which is not
-actually a problem. To help focus on important issues, several
-warning levels are defined. No warnings are issued for the use of
-undefined signed overflow when estimating how many iterations a loop
-will require, in particular when determining whether a loop will be
-executed at all.
-.RS 4
-.IP "\fB\-Wstrict\-overflow=1\fR" 4
-.IX Item "-Wstrict-overflow=1"
-Warn about cases which are both questionable and easy to avoid. For
-example: \f(CW\*(C`x + 1 > x\*(C'\fR; with \fB\-fstrict\-overflow\fR, the
-compiler will simplify this to \f(CW1\fR. This level of
-\&\fB\-Wstrict\-overflow\fR is enabled by \fB\-Wall\fR; higher levels
-are not, and must be explicitly requested.
-.IP "\fB\-Wstrict\-overflow=2\fR" 4
-.IX Item "-Wstrict-overflow=2"
-Also warn about other cases where a comparison is simplified to a
-constant. For example: \f(CW\*(C`abs (x) >= 0\*(C'\fR. This can only be
-simplified when \fB\-fstrict\-overflow\fR is in effect, because
-\&\f(CW\*(C`abs (INT_MIN)\*(C'\fR overflows to \f(CW\*(C`INT_MIN\*(C'\fR, which is less than
-zero. \fB\-Wstrict\-overflow\fR (with no level) is the same as
-\&\fB\-Wstrict\-overflow=2\fR.
-.IP "\fB\-Wstrict\-overflow=3\fR" 4
-.IX Item "-Wstrict-overflow=3"
-Also warn about other cases where a comparison is simplified. For
-example: \f(CW\*(C`x + 1 > 1\*(C'\fR will be simplified to \f(CW\*(C`x > 0\*(C'\fR.
-.IP "\fB\-Wstrict\-overflow=4\fR" 4
-.IX Item "-Wstrict-overflow=4"
-Also warn about other simplifications not covered by the above cases.
-For example: \f(CW\*(C`(x * 10) / 5\*(C'\fR will be simplified to \f(CW\*(C`x * 2\*(C'\fR.
-.IP "\fB\-Wstrict\-overflow=5\fR" 4
-.IX Item "-Wstrict-overflow=5"
-Also warn about cases where the compiler reduces the magnitude of a
-constant involved in a comparison. For example: \f(CW\*(C`x + 2 > y\*(C'\fR will
-be simplified to \f(CW\*(C`x + 1 >= y\*(C'\fR. This is reported only at the
-highest warning level because this simplification applies to many
-comparisons, so this warning level will give a very large number of
-false positives.
-.RE
-.RS 4
-.RE
-.IP "\fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR]" 4
-.IX Item "-Wsuggest-attribute=[pure|const|noreturn]"
-Warn for cases where adding an attribute may be beneficial. The
-attributes currently supported are listed below.
-.RS 4
-.IP "\fB\-Wsuggest\-attribute=pure\fR" 4
-.IX Item "-Wsuggest-attribute=pure"
-.PD 0
-.IP "\fB\-Wsuggest\-attribute=const\fR" 4
-.IX Item "-Wsuggest-attribute=const"
-.IP "\fB\-Wsuggest\-attribute=noreturn\fR" 4
-.IX Item "-Wsuggest-attribute=noreturn"
-.PD
-Warn about functions which might be candidates for attributes
-\&\f(CW\*(C`pure\*(C'\fR, \f(CW\*(C`const\*(C'\fR or \f(CW\*(C`noreturn\*(C'\fR. The compiler only warns for
-functions visible in other compilation units or (in the case of \f(CW\*(C`pure\*(C'\fR and
-\&\f(CW\*(C`const\*(C'\fR) if it cannot prove that the function returns normally. A function
-returns normally if it doesn't contain an infinite loop nor returns abnormally
-by throwing, calling \f(CW\*(C`abort()\*(C'\fR or trapping. This analysis requires option
-\&\fB\-fipa\-pure\-const\fR, which is enabled by default at \fB\-O\fR and
-higher. Higher optimization levels improve the accuracy of the analysis.
-.RE
-.RS 4
-.RE
-.IP "\fB\-Warray\-bounds\fR" 4
-.IX Item "-Warray-bounds"
-This option is only active when \fB\-ftree\-vrp\fR is active
-(default for \fB\-O2\fR and above). It warns about subscripts to arrays
-that are always out of bounds. This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wno\-div\-by\-zero\fR" 4
-.IX Item "-Wno-div-by-zero"
-Do not warn about compile-time integer division by zero. Floating point
-division by zero is not warned about, as it can be a legitimate way of
-obtaining infinities and NaNs.
-.IP "\fB\-Wsystem\-headers\fR" 4
-.IX Item "-Wsystem-headers"
-Print warning messages for constructs found in system header files.
-Warnings from system headers are normally suppressed, on the assumption
-that they usually do not indicate real problems and would only make the
-compiler output harder to read. Using this command line option tells
-\&\s-1GCC\s0 to emit warnings from system headers as if they occurred in user
-code. However, note that using \fB\-Wall\fR in conjunction with this
-option will \fInot\fR warn about unknown pragmas in system
-headers\-\-\-for that, \fB\-Wunknown\-pragmas\fR must also be used.
-.IP "\fB\-Wtrampolines\fR" 4
-.IX Item "-Wtrampolines"
-.Vb 1
-\& Warn about trampolines generated for pointers to nested functions.
-\&
-\& A trampoline is a small piece of data or code that is created at run
-\& time on the stack when the address of a nested function is taken, and
-\& is used to call the nested function indirectly. For some targets, it
-\& is made up of data only and thus requires no special treatment. But,
-\& for most targets, it is made up of code and thus requires the stack
-\& to be made executable in order for the program to work properly.
-.Ve
-.IP "\fB\-Wfloat\-equal\fR" 4
-.IX Item "-Wfloat-equal"
-Warn if floating point values are used in equality comparisons.
-.Sp
-The idea behind this is that sometimes it is convenient (for the
-programmer) to consider floating-point values as approximations to
-infinitely precise real numbers. If you are doing this, then you need
-to compute (by analyzing the code, or in some other way) the maximum or
-likely maximum error that the computation introduces, and allow for it
-when performing comparisons (and when producing output, but that's a
-different problem). In particular, instead of testing for equality, you
-would check to see whether the two values have ranges that overlap; and
-this is done with the relational operators, so equality comparisons are
-probably mistaken.
-.IP "\fB\-Wtraditional\fR (C and Objective-C only)" 4
-.IX Item "-Wtraditional (C and Objective-C only)"
-Warn about certain constructs that behave differently in traditional and
-\&\s-1ISO\s0 C. Also warn about \s-1ISO\s0 C constructs that have no traditional C
-equivalent, and/or problematic constructs which should be avoided.
-.RS 4
-.IP "\(bu" 4
-Macro parameters that appear within string literals in the macro body.
-In traditional C macro replacement takes place within string literals,
-but does not in \s-1ISO\s0 C.
-.IP "\(bu" 4
-In traditional C, some preprocessor directives did not exist.
-Traditional preprocessors would only consider a line to be a directive
-if the \fB#\fR appeared in column 1 on the line. Therefore
-\&\fB\-Wtraditional\fR warns about directives that traditional C
-understands but would ignore because the \fB#\fR does not appear as the
-first character on the line. It also suggests you hide directives like
-\&\fB#pragma\fR not understood by traditional C by indenting them. Some
-traditional implementations would not recognize \fB#elif\fR, so it
-suggests avoiding it altogether.
-.IP "\(bu" 4
-A function-like macro that appears without arguments.
-.IP "\(bu" 4
-The unary plus operator.
-.IP "\(bu" 4
-The \fBU\fR integer constant suffix, or the \fBF\fR or \fBL\fR floating point
-constant suffixes. (Traditional C does support the \fBL\fR suffix on integer
-constants.) Note, these suffixes appear in macros defined in the system
-headers of most modern systems, e.g. the \fB_MIN\fR/\fB_MAX\fR macros in \f(CW\*(C`<limits.h>\*(C'\fR.
-Use of these macros in user code might normally lead to spurious
-warnings, however \s-1GCC\s0's integrated preprocessor has enough context to
-avoid warning in these cases.
-.IP "\(bu" 4
-A function declared external in one block and then used after the end of
-the block.
-.IP "\(bu" 4
-A \f(CW\*(C`switch\*(C'\fR statement has an operand of type \f(CW\*(C`long\*(C'\fR.
-.IP "\(bu" 4
-A non\-\f(CW\*(C`static\*(C'\fR function declaration follows a \f(CW\*(C`static\*(C'\fR one.
-This construct is not accepted by some traditional C compilers.
-.IP "\(bu" 4
-The \s-1ISO\s0 type of an integer constant has a different width or
-signedness from its traditional type. This warning is only issued if
-the base of the constant is ten. I.e. hexadecimal or octal values, which
-typically represent bit patterns, are not warned about.
-.IP "\(bu" 4
-Usage of \s-1ISO\s0 string concatenation is detected.
-.IP "\(bu" 4
-Initialization of automatic aggregates.
-.IP "\(bu" 4
-Identifier conflicts with labels. Traditional C lacks a separate
-namespace for labels.
-.IP "\(bu" 4
-Initialization of unions. If the initializer is zero, the warning is
-omitted. This is done under the assumption that the zero initializer in
-user code appears conditioned on e.g. \f(CW\*(C`_\|_STDC_\|_\*(C'\fR to avoid missing
-initializer warnings and relies on default initialization to zero in the
-traditional C case.
-.IP "\(bu" 4
-Conversions by prototypes between fixed/floating point values and vice
-versa. The absence of these prototypes when compiling with traditional
-C would cause serious problems. This is a subset of the possible
-conversion warnings, for the full set use \fB\-Wtraditional\-conversion\fR.
-.IP "\(bu" 4
-Use of \s-1ISO\s0 C style function definitions. This warning intentionally is
-\&\fInot\fR issued for prototype declarations or variadic functions
-because these \s-1ISO\s0 C features will appear in your code when using
-libiberty's traditional C compatibility macros, \f(CW\*(C`PARAMS\*(C'\fR and
-\&\f(CW\*(C`VPARAMS\*(C'\fR. This warning is also bypassed for nested functions
-because that feature is already a \s-1GCC\s0 extension and thus not relevant to
-traditional C compatibility.
-.RE
-.RS 4
-.RE
-.IP "\fB\-Wtraditional\-conversion\fR (C and Objective-C only)" 4
-.IX Item "-Wtraditional-conversion (C and Objective-C only)"
-Warn if a prototype causes a type conversion that is different from what
-would happen to the same argument in the absence of a prototype. This
-includes conversions of fixed point to floating and vice versa, and
-conversions changing the width or signedness of a fixed point argument
-except when the same as the default promotion.
-.IP "\fB\-Wdeclaration\-after\-statement\fR (C and Objective-C only)" 4
-.IX Item "-Wdeclaration-after-statement (C and Objective-C only)"
-Warn when a declaration is found after a statement in a block. This
-construct, known from \*(C+, was introduced with \s-1ISO\s0 C99 and is by default
-allowed in \s-1GCC\s0. It is not supported by \s-1ISO\s0 C90 and was not supported by
-\&\s-1GCC\s0 versions before \s-1GCC\s0 3.0.
-.IP "\fB\-Wundef\fR" 4
-.IX Item "-Wundef"
-Warn if an undefined identifier is evaluated in an \fB#if\fR directive.
-.IP "\fB\-Wno\-endif\-labels\fR" 4
-.IX Item "-Wno-endif-labels"
-Do not warn whenever an \fB#else\fR or an \fB#endif\fR are followed by text.
-.IP "\fB\-Wshadow\fR" 4
-.IX Item "-Wshadow"
-Warn whenever a local variable or type declaration shadows another variable,
-parameter, type, or class member (in \*(C+), or whenever a built-in function
-is shadowed. Note that in \*(C+, the compiler will not warn if a local variable
-shadows a struct/class/enum, but will warn if it shadows an explicit typedef.
-.IP "\fB\-Wshadow\-local\fR" 4
-.IX Item "-Wshadow-local"
-Warn when a local variable shadows another local variable or parameter.
-.IP "\fB\-Wshadow\-compatible\-local\fR" 4
-.IX Item "-Wshadow-compatible-local"
-Warn when a local variable shadows another local variable or parameter
-whose type is compatible with that of the shadowing variable. In \*(C+,
-type compatibility here means the type of the shadowing variable can be
-converted to that of the shadowed variable. The creation of this flag
-(in addition to \fB\-Wshadow\-local\fR) is based on the idea that when
-a local variable shadows another one of incompatible type, it is most
-likely intentional, not a bug or typo, as shown in the following example:
-.Sp
-.Vb 8
-\& for (SomeIterator i = SomeObj.begin(); i != SomeObj.end(); ++i)
-\& {
-\& for (int i = 0; i < N; ++i)
-\& {
-\& ...
-\& }
-\& ...
-\& }
-.Ve
-.Sp
-Since the two variable \f(CW\*(C`i\*(C'\fR in the example above have incompatible types,
-enabling only \fB\-Wshadow\-compatible\-local\fR will not emit a warning.
-Because their types are incompatible, if a programmer accidentally uses one
-in place of the other, type checking will catch that and emit an error or
-warning. So not warning (about shadowing) in this case will not lead to
-undetected bugs. Use of this flag instead of \fB\-Wshadow\-local\fR can
-possibly reduce the number of warnings triggered by intentional shadowing.
-.IP "\fB\-Wlarger\-than=\fR\fIlen\fR" 4
-.IX Item "-Wlarger-than=len"
-Warn whenever an object of larger than \fIlen\fR bytes is defined.
-.IP "\fB\-Wframe\-larger\-than=\fR\fIlen\fR" 4
-.IX Item "-Wframe-larger-than=len"
-Warn if the size of a function frame is larger than \fIlen\fR bytes.
-The computation done to determine the stack frame size is approximate
-and not conservative.
-The actual requirements may be somewhat greater than \fIlen\fR
-even if you do not get a warning. In addition, any space allocated
-via \f(CW\*(C`alloca\*(C'\fR, variable-length arrays, or related constructs
-is not included by the compiler when determining
-whether or not to issue a warning.
-.IP "\fB\-Wunsafe\-loop\-optimizations\fR" 4
-.IX Item "-Wunsafe-loop-optimizations"
-Warn if the loop cannot be optimized because the compiler could not
-assume anything on the bounds of the loop indices. With
-\&\fB\-funsafe\-loop\-optimizations\fR warn if the compiler made
-such assumptions.
-.IP "\fB\-Wno\-pedantic\-ms\-format\fR (MinGW targets only)" 4
-.IX Item "-Wno-pedantic-ms-format (MinGW targets only)"
-Disables the warnings about non-ISO \f(CW\*(C`printf\*(C'\fR / \f(CW\*(C`scanf\*(C'\fR format
-width specifiers \f(CW\*(C`I32\*(C'\fR, \f(CW\*(C`I64\*(C'\fR, and \f(CW\*(C`I\*(C'\fR used on Windows targets
-depending on the \s-1MS\s0 runtime, when you are using the options \fB\-Wformat\fR
-and \fB\-pedantic\fR without gnu-extensions.
-.IP "\fB\-Wpointer\-arith\fR" 4
-.IX Item "-Wpointer-arith"
-Warn about anything that depends on the \*(L"size of\*(R" a function type or
-of \f(CW\*(C`void\*(C'\fR. \s-1GNU\s0 C assigns these types a size of 1, for
-convenience in calculations with \f(CW\*(C`void *\*(C'\fR pointers and pointers
-to functions. In \*(C+, warn also when an arithmetic operation involves
-\&\f(CW\*(C`NULL\*(C'\fR. This warning is also enabled by \fB\-pedantic\fR.
-.IP "\fB\-Wtype\-limits\fR" 4
-.IX Item "-Wtype-limits"
-Warn if a comparison is always true or always false due to the limited
-range of the data type, but do not warn for constant expressions. For
-example, warn if an unsigned variable is compared against zero with
-\&\fB<\fR or \fB>=\fR. This warning is also enabled by
-\&\fB\-Wextra\fR.
-.IP "\fB\-Wbad\-function\-cast\fR (C and Objective-C only)" 4
-.IX Item "-Wbad-function-cast (C and Objective-C only)"
-Warn whenever a function call is cast to a non-matching type.
-For example, warn if \f(CW\*(C`int malloc()\*(C'\fR is cast to \f(CW\*(C`anything *\*(C'\fR.
-.IP "\fB\-Wc++\-compat\fR (C and Objective-C only)" 4
-.IX Item "-Wc++-compat (C and Objective-C only)"
-Warn about \s-1ISO\s0 C constructs that are outside of the common subset of
-\&\s-1ISO\s0 C and \s-1ISO\s0 \*(C+, e.g. request for implicit conversion from
-\&\f(CW\*(C`void *\*(C'\fR to a pointer to non\-\f(CW\*(C`void\*(C'\fR type.
-.IP "\fB\-Wc++0x\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wc++0x-compat ( and Objective- only)"
-Warn about \*(C+ constructs whose meaning differs between \s-1ISO\s0 \*(C+ 1998 and
-\&\s-1ISO\s0 \*(C+ 200x, e.g., identifiers in \s-1ISO\s0 \*(C+ 1998 that will become keywords
-in \s-1ISO\s0 \*(C+ 200x. This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wcast\-qual\fR" 4
-.IX Item "-Wcast-qual"
-Warn whenever a pointer is cast so as to remove a type qualifier from
-the target type. For example, warn if a \f(CW\*(C`const char *\*(C'\fR is cast
-to an ordinary \f(CW\*(C`char *\*(C'\fR.
-.Sp
-Also warn when making a cast which introduces a type qualifier in an
-unsafe way. For example, casting \f(CW\*(C`char **\*(C'\fR to \f(CW\*(C`const char **\*(C'\fR
-is unsafe, as in this example:
-.Sp
-.Vb 6
-\& /* p is char ** value. */
-\& const char **q = (const char **) p;
-\& /* Assignment of readonly string to const char * is OK. */
-\& *q = "string";
-\& /* Now char** pointer points to read\-only memory. */
-\& **p = \*(Aqb\*(Aq;
-.Ve
-.IP "\fB\-Wcast\-align\fR" 4
-.IX Item "-Wcast-align"
-Warn whenever a pointer is cast such that the required alignment of the
-target is increased. For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
-an \f(CW\*(C`int *\*(C'\fR on machines where integers can only be accessed at
-two\- or four-byte boundaries.
-.IP "\fB\-Wwrite\-strings\fR" 4
-.IX Item "-Wwrite-strings"
-When compiling C, give string constants the type \f(CW\*(C`const
-char[\f(CIlength\f(CW]\*(C'\fR so that copying the address of one into a
-non\-\f(CW\*(C`const\*(C'\fR \f(CW\*(C`char *\*(C'\fR pointer will get a warning. These
-warnings will help you find at compile time code that can try to write
-into a string constant, but only if you have been very careful about
-using \f(CW\*(C`const\*(C'\fR in declarations and prototypes. Otherwise, it will
-just be a nuisance. This is why we did not make \fB\-Wall\fR request
-these warnings.
-.Sp
-When compiling \*(C+, warn about the deprecated conversion from string
-literals to \f(CW\*(C`char *\*(C'\fR. This warning is enabled by default for \*(C+
-programs.
-.IP "\fB\-Wclobbered\fR" 4
-.IX Item "-Wclobbered"
-Warn for variables that might be changed by \fBlongjmp\fR or
-\&\fBvfork\fR. This warning is also enabled by \fB\-Wextra\fR.
-.IP "\fB\-Wconversion\fR" 4
-.IX Item "-Wconversion"
-Warn for implicit conversions that may alter a value. This includes
-conversions between real and integer, like \f(CW\*(C`abs (x)\*(C'\fR when
-\&\f(CW\*(C`x\*(C'\fR is \f(CW\*(C`double\*(C'\fR; conversions between signed and unsigned,
-like \f(CW\*(C`unsigned ui = \-1\*(C'\fR; and conversions to smaller types, like
-\&\f(CW\*(C`sqrtf (M_PI)\*(C'\fR. Do not warn for explicit casts like \f(CW\*(C`abs
-((int) x)\*(C'\fR and \f(CW\*(C`ui = (unsigned) \-1\*(C'\fR, or if the value is not
-changed by the conversion like in \f(CW\*(C`abs (2.0)\*(C'\fR. Warnings about
-conversions between signed and unsigned integers can be disabled by
-using \fB\-Wno\-sign\-conversion\fR.
-.Sp
-For \*(C+, also warn for confusing overload resolution for user-defined
-conversions; and conversions that will never use a type conversion
-operator: conversions to \f(CW\*(C`void\*(C'\fR, the same type, a base class or a
-reference to them. Warnings about conversions between signed and
-unsigned integers are disabled by default in \*(C+ unless
-\&\fB\-Wsign\-conversion\fR is explicitly enabled.
-.IP "\fB\-Wno\-conversion\-null\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wno-conversion-null ( and Objective- only)"
-Do not warn for conversions between \f(CW\*(C`NULL\*(C'\fR and non-pointer
-types. \fB\-Wconversion\-null\fR is enabled by default.
-.IP "\fB\-Wreal\-conversion\fR" 4
-.IX Item "-Wreal-conversion"
-Warn for implicit type conversions from real (\f(CW\*(C`double\*(C'\fR or \f(CW\*(C`float\*(C'\fR)
-to integral values.
-.IP "\fB\-Wempty\-body\fR" 4
-.IX Item "-Wempty-body"
-Warn if an empty body occurs in an \fBif\fR, \fBelse\fR or \fBdo
-while\fR statement. This warning is also enabled by \fB\-Wextra\fR.
-.IP "\fB\-Wenum\-compare\fR" 4
-.IX Item "-Wenum-compare"
-Warn about a comparison between values of different enum types. In \*(C+
-this warning is enabled by default. In C this warning is enabled by
-\&\fB\-Wall\fR.
-.IP "\fB\-Wjump\-misses\-init\fR (C, Objective-C only)" 4
-.IX Item "-Wjump-misses-init (C, Objective-C only)"
-Warn if a \f(CW\*(C`goto\*(C'\fR statement or a \f(CW\*(C`switch\*(C'\fR statement jumps
-forward across the initialization of a variable, or jumps backward to a
-label after the variable has been initialized. This only warns about
-variables which are initialized when they are declared. This warning is
-only supported for C and Objective C; in \*(C+ this sort of branch is an
-error in any case.
-.Sp
-\&\fB\-Wjump\-misses\-init\fR is included in \fB\-Wc++\-compat\fR. It
-can be disabled with the \fB\-Wno\-jump\-misses\-init\fR option.
-.IP "\fB\-Wsign\-compare\fR" 4
-.IX Item "-Wsign-compare"
-Warn when a comparison between signed and unsigned values could produce
-an incorrect result when the signed value is converted to unsigned.
-This warning is also enabled by \fB\-Wextra\fR; to get the other warnings
-of \fB\-Wextra\fR without this warning, use \fB\-Wextra \-Wno\-sign\-compare\fR.
-.IP "\fB\-Wsign\-conversion\fR" 4
-.IX Item "-Wsign-conversion"
-Warn for implicit conversions that may change the sign of an integer
-value, like assigning a signed integer expression to an unsigned
-integer variable. An explicit cast silences the warning. In C, this
-option is enabled also by \fB\-Wconversion\fR.
-.IP "\fB\-Waddress\fR" 4
-.IX Item "-Waddress"
-Warn about suspicious uses of memory addresses. These include using
-the address of a function in a conditional expression, such as
-\&\f(CW\*(C`void func(void); if (func)\*(C'\fR, and comparisons against the memory
-address of a string literal, such as \f(CW\*(C`if (x == "abc")\*(C'\fR. Such
-uses typically indicate a programmer error: the address of a function
-always evaluates to true, so their use in a conditional usually
-indicate that the programmer forgot the parentheses in a function
-call; and comparisons against string literals result in unspecified
-behavior and are not portable in C, so they usually indicate that the
-programmer intended to use \f(CW\*(C`strcmp\*(C'\fR. This warning is enabled by
-\&\fB\-Wall\fR.
-.IP "\fB\-Wlogical\-op\fR" 4
-.IX Item "-Wlogical-op"
-Warn about suspicious uses of logical operators in expressions.
-This includes using logical operators in contexts where a
-bit-wise operator is likely to be expected.
-.IP "\fB\-Waggregate\-return\fR" 4
-.IX Item "-Waggregate-return"
-Warn if any functions that return structures or unions are defined or
-called. (In languages where you can return an array, this also elicits
-a warning.)
-.IP "\fB\-Wno\-attributes\fR" 4
-.IX Item "-Wno-attributes"
-Do not warn if an unexpected \f(CW\*(C`_\|_attribute_\|_\*(C'\fR is used, such as
-unrecognized attributes, function attributes applied to variables,
-etc. This will not stop errors for incorrect use of supported
-attributes.
-.IP "\fB\-Wno\-builtin\-macro\-redefined\fR" 4
-.IX Item "-Wno-builtin-macro-redefined"
-Do not warn if certain built-in macros are redefined. This suppresses
-warnings for redefinition of \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR, \f(CW\*(C`_\|_TIME_\|_\*(C'\fR,
-\&\f(CW\*(C`_\|_DATE_\|_\*(C'\fR, \f(CW\*(C`_\|_FILE_\|_\*(C'\fR, and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR.
-.IP "\fB\-Wstrict\-prototypes\fR (C and Objective-C only)" 4
-.IX Item "-Wstrict-prototypes (C and Objective-C only)"
-Warn if a function is declared or defined without specifying the
-argument types. (An old-style function definition is permitted without
-a warning if preceded by a declaration which specifies the argument
-types.)
-.IP "\fB\-Wold\-style\-declaration\fR (C and Objective-C only)" 4
-.IX Item "-Wold-style-declaration (C and Objective-C only)"
-Warn for obsolescent usages, according to the C Standard, in a
-declaration. For example, warn if storage-class specifiers like
-\&\f(CW\*(C`static\*(C'\fR are not the first things in a declaration. This warning
-is also enabled by \fB\-Wextra\fR.
-.IP "\fB\-Wold\-style\-definition\fR (C and Objective-C only)" 4
-.IX Item "-Wold-style-definition (C and Objective-C only)"
-Warn if an old-style function definition is used. A warning is given
-even if there is a previous prototype.
-.IP "\fB\-Wmissing\-parameter\-type\fR (C and Objective-C only)" 4
-.IX Item "-Wmissing-parameter-type (C and Objective-C only)"
-A function parameter is declared without a type specifier in K&R\-style
-functions:
-.Sp
-.Vb 1
-\& void foo(bar) { }
-.Ve
-.Sp
-This warning is also enabled by \fB\-Wextra\fR.
-.IP "\fB\-Wmissing\-prototypes\fR (C and Objective-C only)" 4
-.IX Item "-Wmissing-prototypes (C and Objective-C only)"
-Warn if a global function is defined without a previous prototype
-declaration. This warning is issued even if the definition itself
-provides a prototype. The aim is to detect global functions that fail
-to be declared in header files.
-.IP "\fB\-Wmissing\-declarations\fR" 4
-.IX Item "-Wmissing-declarations"
-Warn if a global function is defined without a previous declaration.
-Do so even if the definition itself provides a prototype.
-Use this option to detect global functions that are not declared in
-header files. In \*(C+, no warnings are issued for function templates,
-or for inline functions, or for functions in anonymous namespaces.
-.IP "\fB\-Wmissing\-field\-initializers\fR" 4
-.IX Item "-Wmissing-field-initializers"
-Warn if a structure's initializer has some fields missing. For
-example, the following code would cause such a warning, because
-\&\f(CW\*(C`x.h\*(C'\fR is implicitly zero:
-.Sp
-.Vb 2
-\& struct s { int f, g, h; };
-\& struct s x = { 3, 4 };
-.Ve
-.Sp
-This option does not warn about designated initializers, so the following
-modification would not trigger a warning:
-.Sp
-.Vb 2
-\& struct s { int f, g, h; };
-\& struct s x = { .f = 3, .g = 4 };
-.Ve
-.Sp
-This warning is included in \fB\-Wextra\fR. To get other \fB\-Wextra\fR
-warnings without this one, use \fB\-Wextra \-Wno\-missing\-field\-initializers\fR.
-.IP "\fB\-Wmissing\-format\-attribute\fR" 4
-.IX Item "-Wmissing-format-attribute"
-Warn about function pointers which might be candidates for \f(CW\*(C`format\*(C'\fR
-attributes. Note these are only possible candidates, not absolute ones.
-\&\s-1GCC\s0 will guess that function pointers with \f(CW\*(C`format\*(C'\fR attributes that
-are used in assignment, initialization, parameter passing or return
-statements should have a corresponding \f(CW\*(C`format\*(C'\fR attribute in the
-resulting type. I.e. the left-hand side of the assignment or
-initialization, the type of the parameter variable, or the return type
-of the containing function respectively should also have a \f(CW\*(C`format\*(C'\fR
-attribute to avoid the warning.
-.Sp
-\&\s-1GCC\s0 will also warn about function definitions which might be
-candidates for \f(CW\*(C`format\*(C'\fR attributes. Again, these are only
-possible candidates. \s-1GCC\s0 will guess that \f(CW\*(C`format\*(C'\fR attributes
-might be appropriate for any function that calls a function like
-\&\f(CW\*(C`vprintf\*(C'\fR or \f(CW\*(C`vscanf\*(C'\fR, but this might not always be the
-case, and some functions for which \f(CW\*(C`format\*(C'\fR attributes are
-appropriate may not be detected.
-.IP "\fB\-Wno\-multichar\fR" 4
-.IX Item "-Wno-multichar"
-Do not warn if a multicharacter constant (\fB'\s-1FOOF\s0'\fR) is used.
-Usually they indicate a typo in the user's code, as they have
-implementation-defined values, and should not be used in portable code.
-.IP "\fB\-Wnormalized=<none|id|nfc|nfkc>\fR" 4
-.IX Item "-Wnormalized=<none|id|nfc|nfkc>"
-In \s-1ISO\s0 C and \s-1ISO\s0 \*(C+, two identifiers are different if they are
-different sequences of characters. However, sometimes when characters
-outside the basic \s-1ASCII\s0 character set are used, you can have two
-different character sequences that look the same. To avoid confusion,
-the \s-1ISO\s0 10646 standard sets out some \fInormalization rules\fR which
-when applied ensure that two sequences that look the same are turned into
-the same sequence. \s-1GCC\s0 can warn you if you are using identifiers which
-have not been normalized; this option controls that warning.
-.Sp
-There are four levels of warning that \s-1GCC\s0 supports. The default is
-\&\fB\-Wnormalized=nfc\fR, which warns about any identifier which is
-not in the \s-1ISO\s0 10646 \*(L"C\*(R" normalized form, \fI\s-1NFC\s0\fR. \s-1NFC\s0 is the
-recommended form for most uses.
-.Sp
-Unfortunately, there are some characters which \s-1ISO\s0 C and \s-1ISO\s0 \*(C+ allow
-in identifiers that when turned into \s-1NFC\s0 aren't allowable as
-identifiers. That is, there's no way to use these symbols in portable
-\&\s-1ISO\s0 C or \*(C+ and have all your identifiers in \s-1NFC\s0.
-\&\fB\-Wnormalized=id\fR suppresses the warning for these characters.
-It is hoped that future versions of the standards involved will correct
-this, which is why this option is not the default.
-.Sp
-You can switch the warning off for all characters by writing
-\&\fB\-Wnormalized=none\fR. You would only want to do this if you
-were using some other normalization scheme (like \*(L"D\*(R"), because
-otherwise you can easily create bugs that are literally impossible to see.
-.Sp
-Some characters in \s-1ISO\s0 10646 have distinct meanings but look identical
-in some fonts or display methodologies, especially once formatting has
-been applied. For instance \f(CW\*(C`\eu207F\*(C'\fR, \*(L"\s-1SUPERSCRIPT\s0 \s-1LATIN\s0 \s-1SMALL\s0
-\&\s-1LETTER\s0 N\*(R", will display just like a regular \f(CW\*(C`n\*(C'\fR which has been
-placed in a superscript. \s-1ISO\s0 10646 defines the \fI\s-1NFKC\s0\fR
-normalization scheme to convert all these into a standard form as
-well, and \s-1GCC\s0 will warn if your code is not in \s-1NFKC\s0 if you use
-\&\fB\-Wnormalized=nfkc\fR. This warning is comparable to warning
-about every identifier that contains the letter O because it might be
-confused with the digit 0, and so is not the default, but may be
-useful as a local coding convention if the programming environment is
-unable to be fixed to display these characters distinctly.
-.IP "\fB\-Wno\-deprecated\fR" 4
-.IX Item "-Wno-deprecated"
-Do not warn about usage of deprecated features.
-.IP "\fB\-Wno\-deprecated\-declarations\fR" 4
-.IX Item "-Wno-deprecated-declarations"
-Do not warn about uses of functions,
-variables, and types marked as deprecated by using the \f(CW\*(C`deprecated\*(C'\fR
-attribute.
-.IP "\fB\-Wno\-overflow\fR" 4
-.IX Item "-Wno-overflow"
-Do not warn about compile-time overflow in constant expressions.
-.IP "\fB\-Woverride\-init\fR (C and Objective-C only)" 4
-.IX Item "-Woverride-init (C and Objective-C only)"
-Warn if an initialized field without side effects is overridden when
-using designated initializers.
-.Sp
-This warning is included in \fB\-Wextra\fR. To get other
-\&\fB\-Wextra\fR warnings without this one, use \fB\-Wextra
-\&\-Wno\-override\-init\fR.
-.IP "\fB\-Wpacked\fR" 4
-.IX Item "-Wpacked"
-Warn if a structure is given the packed attribute, but the packed
-attribute has no effect on the layout or size of the structure.
-Such structures may be mis-aligned for little benefit. For
-instance, in this code, the variable \f(CW\*(C`f.x\*(C'\fR in \f(CW\*(C`struct bar\*(C'\fR
-will be misaligned even though \f(CW\*(C`struct bar\*(C'\fR does not itself
-have the packed attribute:
-.Sp
-.Vb 8
-\& struct foo {
-\& int x;
-\& char a, b, c, d;
-\& } _\|_attribute_\|_((packed));
-\& struct bar {
-\& char z;
-\& struct foo f;
-\& };
-.Ve
-.IP "\fB\-Wpacked\-bitfield\-compat\fR" 4
-.IX Item "-Wpacked-bitfield-compat"
-The 4.1, 4.2 and 4.3 series of \s-1GCC\s0 ignore the \f(CW\*(C`packed\*(C'\fR attribute
-on bit-fields of type \f(CW\*(C`char\*(C'\fR. This has been fixed in \s-1GCC\s0 4.4 but
-the change can lead to differences in the structure layout. \s-1GCC\s0
-informs you when the offset of such a field has changed in \s-1GCC\s0 4.4.
-For example there is no longer a 4\-bit padding between field \f(CW\*(C`a\*(C'\fR
-and \f(CW\*(C`b\*(C'\fR in this structure:
-.Sp
-.Vb 5
-\& struct foo
-\& {
-\& char a:4;
-\& char b:8;
-\& } _\|_attribute_\|_ ((packed));
-.Ve
-.Sp
-This warning is enabled by default. Use
-\&\fB\-Wno\-packed\-bitfield\-compat\fR to disable this warning.
-.IP "\fB\-Wpadded\fR" 4
-.IX Item "-Wpadded"
-Warn if padding is included in a structure, either to align an element
-of the structure or to align the whole structure. Sometimes when this
-happens it is possible to rearrange the fields of the structure to
-reduce the padding and so make the structure smaller.
-.IP "\fB\-Wredundant\-decls\fR" 4
-.IX Item "-Wredundant-decls"
-Warn if anything is declared more than once in the same scope, even in
-cases where multiple declaration is valid and changes nothing.
-.IP "\fB\-Wnested\-externs\fR (C and Objective-C only)" 4
-.IX Item "-Wnested-externs (C and Objective-C only)"
-Warn if an \f(CW\*(C`extern\*(C'\fR declaration is encountered within a function.
-.IP "\fB\-Winline\fR" 4
-.IX Item "-Winline"
-Warn if a function can not be inlined and it was declared as inline.
-Even with this option, the compiler will not warn about failures to
-inline functions declared in system headers.
-.Sp
-The compiler uses a variety of heuristics to determine whether or not
-to inline a function. For example, the compiler takes into account
-the size of the function being inlined and the amount of inlining
-that has already been done in the current function. Therefore,
-seemingly insignificant changes in the source program can cause the
-warnings produced by \fB\-Winline\fR to appear or disappear.
-.IP "\fB\-Wno\-invalid\-offsetof\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wno-invalid-offsetof ( and Objective- only)"
-Suppress warnings from applying the \fBoffsetof\fR macro to a non-POD
-type. According to the 1998 \s-1ISO\s0 \*(C+ standard, applying \fBoffsetof\fR
-to a non-POD type is undefined. In existing \*(C+ implementations,
-however, \fBoffsetof\fR typically gives meaningful results even when
-applied to certain kinds of non-POD types. (Such as a simple
-\&\fBstruct\fR that fails to be a \s-1POD\s0 type only by virtue of having a
-constructor.) This flag is for users who are aware that they are
-writing nonportable code and who have deliberately chosen to ignore the
-warning about it.
-.Sp
-The restrictions on \fBoffsetof\fR may be relaxed in a future version
-of the \*(C+ standard.
-.IP "\fB\-Wno\-int\-to\-pointer\-cast\fR" 4
-.IX Item "-Wno-int-to-pointer-cast"
-Suppress warnings from casts to pointer type of an integer of a
-different size. In \*(C+, casting to a pointer type of smaller size is
-an error. \fBWint-to-pointer-cast\fR is enabled by default.
-.IP "\fBmax-lipo-mem\fR" 4
-.IX Item "max-lipo-mem"
-When importing auxiliary modules during profile-use, check current
-memory consumption after parsing each auxiliary module. If it exceeds
-this limit (specified in kb), don't import any more auxiliary modules.
-Specifying a value of 0 means don't enforce this limit. This parameter
-is only useful when using \fB\-fprofile\-use\fR and \fB\-fripa\fR.
-.IP "\fB\-Wno\-pointer\-to\-int\-cast\fR (C and Objective-C only)" 4
-.IX Item "-Wno-pointer-to-int-cast (C and Objective-C only)"
-Suppress warnings from casts from a pointer to an integer type of a
-different size.
-.IP "\fB\-Winvalid\-pch\fR" 4
-.IX Item "-Winvalid-pch"
-Warn if a precompiled header is found in
-the search path but can't be used.
-.IP "\fB\-Wlong\-long\fR" 4
-.IX Item "-Wlong-long"
-Warn if \fBlong long\fR type is used. This is enabled by either
-\&\fB\-pedantic\fR or \fB\-Wtraditional\fR in \s-1ISO\s0 C90 and \*(C+98
-modes. To inhibit the warning messages, use \fB\-Wno\-long\-long\fR.
-.IP "\fB\-Wvariadic\-macros\fR" 4
-.IX Item "-Wvariadic-macros"
-Warn if variadic macros are used in pedantic \s-1ISO\s0 C90 mode, or the \s-1GNU\s0
-alternate syntax when in pedantic \s-1ISO\s0 C99 mode. This is default.
-To inhibit the warning messages, use \fB\-Wno\-variadic\-macros\fR.
-.IP "\fB\-Wvla\fR" 4
-.IX Item "-Wvla"
-Warn if variable length array is used in the code.
-\&\fB\-Wno\-vla\fR will prevent the \fB\-pedantic\fR warning of
-the variable length array.
-.IP "\fB\-Wvolatile\-register\-var\fR" 4
-.IX Item "-Wvolatile-register-var"
-Warn if a register variable is declared volatile. The volatile
-modifier does not inhibit all optimizations that may eliminate reads
-and/or writes to register variables. This warning is enabled by
-\&\fB\-Wall\fR.
-.IP "\fB\-Wdisabled\-optimization\fR" 4
-.IX Item "-Wdisabled-optimization"
-Warn if a requested optimization pass is disabled. This warning does
-not generally indicate that there is anything wrong with your code; it
-merely indicates that \s-1GCC\s0's optimizers were unable to handle the code
-effectively. Often, the problem is that your code is too big or too
-complex; \s-1GCC\s0 will refuse to optimize programs when the optimization
-itself is likely to take inordinate amounts of time.
-.IP "\fB\-Wpointer\-sign\fR (C and Objective-C only)" 4
-.IX Item "-Wpointer-sign (C and Objective-C only)"
-Warn for pointer argument passing or assignment with different signedness.
-This option is only supported for C and Objective-C. It is implied by
-\&\fB\-Wall\fR and by \fB\-pedantic\fR, which can be disabled with
-\&\fB\-Wno\-pointer\-sign\fR.
-.IP "\fB\-Wstack\-protector\fR" 4
-.IX Item "-Wstack-protector"
-This option is only active when \fB\-fstack\-protector\fR is active. It
-warns about functions that will not be protected against stack smashing.
-.IP "\fB\-Wno\-mudflap\fR" 4
-.IX Item "-Wno-mudflap"
-Suppress warnings about constructs that cannot be instrumented by
-\&\fB\-fmudflap\fR.
-.IP "\fB\-Woverlength\-strings\fR" 4
-.IX Item "-Woverlength-strings"
-Warn about string constants which are longer than the \*(L"minimum
-maximum\*(R" length specified in the C standard. Modern compilers
-generally allow string constants which are much longer than the
-standard's minimum limit, but very portable programs should avoid
-using longer strings.
-.Sp
-The limit applies \fIafter\fR string constant concatenation, and does
-not count the trailing \s-1NUL\s0. In C90, the limit was 509 characters; in
-C99, it was raised to 4095. \*(C+98 does not specify a normative
-minimum maximum, so we do not diagnose overlength strings in \*(C+.
-.Sp
-This option is implied by \fB\-pedantic\fR, and can be disabled with
-\&\fB\-Wno\-overlength\-strings\fR.
-.IP "\fB\-Wunsuffixed\-float\-constants\fR (C and Objective-C only)" 4
-.IX Item "-Wunsuffixed-float-constants (C and Objective-C only)"
-\&\s-1GCC\s0 will issue a warning for any floating constant that does not have
-a suffix. When used together with \fB\-Wsystem\-headers\fR it will
-warn about such constants in system header files. This can be useful
-when preparing code to use with the \f(CW\*(C`FLOAT_CONST_DECIMAL64\*(C'\fR pragma
-from the decimal floating-point extension to C99.
-.SS "Options for Debugging Your Program or \s-1GCC\s0"
-.IX Subsection "Options for Debugging Your Program or GCC"
-\&\s-1GCC\s0 has various special options that are used for debugging
-either your program or \s-1GCC:\s0
-.IP "\fB\-g\fR" 4
-.IX Item "-g"
-Produce debugging information in the operating system's native format
-(stabs, \s-1COFF\s0, \s-1XCOFF\s0, or \s-1DWARF\s0 2). \s-1GDB\s0 can work with this debugging
-information.
-.Sp
-On most systems that use stabs format, \fB\-g\fR enables use of extra
-debugging information that only \s-1GDB\s0 can use; this extra information
-makes debugging work better in \s-1GDB\s0 but will probably make other debuggers
-crash or
-refuse to read the program. If you want to control for certain whether
-to generate the extra information, use \fB\-gstabs+\fR, \fB\-gstabs\fR,
-\&\fB\-gxcoff+\fR, \fB\-gxcoff\fR, or \fB\-gvms\fR (see below).
-.Sp
-\&\s-1GCC\s0 allows you to use \fB\-g\fR with
-\&\fB\-O\fR. The shortcuts taken by optimized code may occasionally
-produce surprising results: some variables you declared may not exist
-at all; flow of control may briefly move where you did not expect it;
-some statements may not be executed because they compute constant
-results or their values were already at hand; some statements may
-execute in different places because they were moved out of loops.
-.Sp
-Nevertheless it proves possible to debug optimized output. This makes
-it reasonable to use the optimizer for programs that might have bugs.
-.Sp
-The following options are useful when \s-1GCC\s0 is generated with the
-capability for more than one debugging format.
-.IP "\fB\-ggdb\fR" 4
-.IX Item "-ggdb"
-Produce debugging information for use by \s-1GDB\s0. This means to use the
-most expressive format available (\s-1DWARF\s0 2, stabs, or the native format
-if neither of those are supported), including \s-1GDB\s0 extensions if at all
-possible.
-.IP "\fB\-gstabs\fR" 4
-.IX Item "-gstabs"
-Produce debugging information in stabs format (if that is supported),
-without \s-1GDB\s0 extensions. This is the format used by \s-1DBX\s0 on most \s-1BSD\s0
-systems. On \s-1MIPS\s0, Alpha and System V Release 4 systems this option
-produces stabs debugging output which is not understood by \s-1DBX\s0 or \s-1SDB\s0.
-On System V Release 4 systems this option requires the \s-1GNU\s0 assembler.
-.IP "\fB\-feliminate\-unused\-debug\-symbols\fR" 4
-.IX Item "-feliminate-unused-debug-symbols"
-Produce debugging information in stabs format (if that is supported),
-for only symbols that are actually used.
-.IP "\fB\-femit\-class\-debug\-always\fR" 4
-.IX Item "-femit-class-debug-always"
-Instead of emitting debugging information for a \*(C+ class in only one
-object file, emit it in all object files using the class. This option
-should be used only with debuggers that are unable to handle the way \s-1GCC\s0
-normally emits debugging information for classes because using this
-option will increase the size of debugging information by as much as a
-factor of two.
-.IP "\fB\-gstabs+\fR" 4
-.IX Item "-gstabs+"
-Produce debugging information in stabs format (if that is supported),
-using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0). The
-use of these extensions is likely to make other debuggers crash or
-refuse to read the program.
-.IP "\fB\-gcoff\fR" 4
-.IX Item "-gcoff"
-Produce debugging information in \s-1COFF\s0 format (if that is supported).
-This is the format used by \s-1SDB\s0 on most System V systems prior to
-System V Release 4.
-.IP "\fB\-gxcoff\fR" 4
-.IX Item "-gxcoff"
-Produce debugging information in \s-1XCOFF\s0 format (if that is supported).
-This is the format used by the \s-1DBX\s0 debugger on \s-1IBM\s0 \s-1RS/6000\s0 systems.
-.IP "\fB\-gxcoff+\fR" 4
-.IX Item "-gxcoff+"
-Produce debugging information in \s-1XCOFF\s0 format (if that is supported),
-using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0). The
-use of these extensions is likely to make other debuggers crash or
-refuse to read the program, and may cause assemblers other than the \s-1GNU\s0
-assembler (\s-1GAS\s0) to fail with an error.
-.IP "\fB\-gdwarf\-\fR\fIversion\fR" 4
-.IX Item "-gdwarf-version"
-Produce debugging information in \s-1DWARF\s0 format (if that is
-supported). This is the format used by \s-1DBX\s0 on \s-1IRIX\s0 6. The value
-of \fIversion\fR may be either 2, 3 or 4; the default version is 2.
-.Sp
-Note that with \s-1DWARF\s0 version 2 some ports require, and will always
-use, some non-conflicting \s-1DWARF\s0 3 extensions in the unwind tables.
-.Sp
-Version 4 may require \s-1GDB\s0 7.0 and \fB\-fvar\-tracking\-assignments\fR
-for maximum benefit.
-.IP "\fB\-gstrict\-dwarf\fR" 4
-.IX Item "-gstrict-dwarf"
-Disallow using extensions of later \s-1DWARF\s0 standard version than selected
-with \fB\-gdwarf\-\fR\fIversion\fR. On most targets using non-conflicting
-\&\s-1DWARF\s0 extensions from later standard versions is allowed.
-.IP "\fB\-gno\-strict\-dwarf\fR" 4
-.IX Item "-gno-strict-dwarf"
-Allow using extensions of later \s-1DWARF\s0 standard version than selected with
-\&\fB\-gdwarf\-\fR\fIversion\fR.
-.IP "\fB\-gvms\fR" 4
-.IX Item "-gvms"
-Produce debugging information in \s-1VMS\s0 debug format (if that is
-supported). This is the format used by \s-1DEBUG\s0 on \s-1VMS\s0 systems.
-.IP "\fB\-g\fR\fIlevel\fR" 4
-.IX Item "-glevel"
-.PD 0
-.IP "\fB\-ggdb\fR\fIlevel\fR" 4
-.IX Item "-ggdblevel"
-.IP "\fB\-gstabs\fR\fIlevel\fR" 4
-.IX Item "-gstabslevel"
-.IP "\fB\-gcoff\fR\fIlevel\fR" 4
-.IX Item "-gcofflevel"
-.IP "\fB\-gxcoff\fR\fIlevel\fR" 4
-.IX Item "-gxcofflevel"
-.IP "\fB\-gvms\fR\fIlevel\fR" 4
-.IX Item "-gvmslevel"
-.PD
-Request debugging information and also use \fIlevel\fR to specify how
-much information. The default level is 2.
-.Sp
-Level 0 produces no debug information at all. Thus, \fB\-g0\fR negates
-\&\fB\-g\fR.
-.Sp
-Level 1 produces minimal information, enough for making backtraces in
-parts of the program that you don't plan to debug. This includes
-descriptions of functions and external variables, but no information
-about local variables and no line numbers.
-.Sp
-Level 3 includes extra information, such as all the macro definitions
-present in the program. Some debuggers support macro expansion when
-you use \fB\-g3\fR.
-.Sp
-\&\fB\-gdwarf\-2\fR does not accept a concatenated debug level, because
-\&\s-1GCC\s0 used to support an option \fB\-gdwarf\fR that meant to generate
-debug information in version 1 of the \s-1DWARF\s0 format (which is very
-different from version 2), and it would have been too confusing. That
-debug format is long obsolete, but the option cannot be changed now.
-Instead use an additional \fB\-g\fR\fIlevel\fR option to change the
-debug level for \s-1DWARF\s0.
-.IP "\fB\-gmlt\fR" 4
-.IX Item "-gmlt"
-Produce a minimal line table, with level 1 debugging information plus
-information about inlined functions and line numbers.
-.IP "\fB\-gtoggle\fR" 4
-.IX Item "-gtoggle"
-Turn off generation of debug info, if leaving out this option would have
-generated it, or turn it on at level 2 otherwise. The position of this
-argument in the command line does not matter, it takes effect after all
-other options are processed, and it does so only once, no matter how
-many times it is given. This is mainly intended to be used with
-\&\fB\-fcompare\-debug\fR.
-.IP "\fB\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR]" 4
-.IX Item "-fdump-final-insns[=file]"
-Dump the final internal representation (\s-1RTL\s0) to \fIfile\fR. If the
-optional argument is omitted (or if \fIfile\fR is \f(CW\*(C`.\*(C'\fR), the name
-of the dump file will be determined by appending \f(CW\*(C`.gkd\*(C'\fR to the
-compilation output file name.
-.IP "\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]" 4
-.IX Item "-fcompare-debug[=opts]"
-If no error occurs during compilation, run the compiler a second time,
-adding \fIopts\fR and \fB\-fcompare\-debug\-second\fR to the arguments
-passed to the second compilation. Dump the final internal
-representation in both compilations, and print an error if they differ.
-.Sp
-If the equal sign is omitted, the default \fB\-gtoggle\fR is used.
-.Sp
-The environment variable \fB\s-1GCC_COMPARE_DEBUG\s0\fR, if defined, non-empty
-and nonzero, implicitly enables \fB\-fcompare\-debug\fR. If
-\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR is defined to a string starting with a dash,
-then it is used for \fIopts\fR, otherwise the default \fB\-gtoggle\fR
-is used.
-.Sp
-\&\fB\-fcompare\-debug=\fR, with the equal sign but without \fIopts\fR,
-is equivalent to \fB\-fno\-compare\-debug\fR, which disables the dumping
-of the final representation and the second compilation, preventing even
-\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR from taking effect.
-.Sp
-To verify full coverage during \fB\-fcompare\-debug\fR testing, set
-\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR to say \fB\-fcompare\-debug\-not\-overridden\fR,
-which \s-1GCC\s0 will reject as an invalid option in any actual compilation
-(rather than preprocessing, assembly or linking). To get just a
-warning, setting \fB\s-1GCC_COMPARE_DEBUG\s0\fR to \fB\-w%n\-fcompare\-debug
-not overridden\fR will do.
-.IP "\fB\-fcompare\-debug\-second\fR" 4
-.IX Item "-fcompare-debug-second"
-This option is implicitly passed to the compiler for the second
-compilation requested by \fB\-fcompare\-debug\fR, along with options to
-silence warnings, and omitting other options that would cause
-side-effect compiler outputs to files or to the standard output. Dump
-files and preserved temporary files are renamed so as to contain the
-\&\f(CW\*(C`.gk\*(C'\fR additional extension during the second compilation, to avoid
-overwriting those generated by the first.
-.Sp
-When this option is passed to the compiler driver, it causes the
-\&\fIfirst\fR compilation to be skipped, which makes it useful for little
-other than debugging the compiler proper.
-.IP "\fB\-feliminate\-dwarf2\-dups\fR" 4
-.IX Item "-feliminate-dwarf2-dups"
-Compress \s-1DWARF2\s0 debugging information by eliminating duplicated
-information about each symbol. This option only makes sense when
-generating \s-1DWARF2\s0 debugging information with \fB\-gdwarf\-2\fR.
-.IP "\fB\-femit\-struct\-debug\-baseonly\fR" 4
-.IX Item "-femit-struct-debug-baseonly"
-Emit debug information for struct-like types
-only when the base name of the compilation source file
-matches the base name of file in which the struct was defined.
-.Sp
-This option substantially reduces the size of debugging information,
-but at significant potential loss in type information to the debugger.
-See \fB\-femit\-struct\-debug\-reduced\fR for a less aggressive option.
-See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
-.Sp
-This option works only with \s-1DWARF\s0 2.
-.IP "\fB\-femit\-struct\-debug\-reduced\fR" 4
-.IX Item "-femit-struct-debug-reduced"
-Emit debug information for struct-like types
-only when the base name of the compilation source file
-matches the base name of file in which the type was defined,
-unless the struct is a template or defined in a system header.
-.Sp
-This option significantly reduces the size of debugging information,
-with some potential loss in type information to the debugger.
-See \fB\-femit\-struct\-debug\-baseonly\fR for a more aggressive option.
-See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
-.Sp
-This option works only with \s-1DWARF\s0 2.
-.IP "\fB\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR]" 4
-.IX Item "-femit-struct-debug-detailed[=spec-list]"
-Specify the struct-like types
-for which the compiler will generate debug information.
-The intent is to reduce duplicate struct debug information
-between different object files within the same program.
-.Sp
-This option is a detailed version of
-\&\fB\-femit\-struct\-debug\-reduced\fR and \fB\-femit\-struct\-debug\-baseonly\fR,
-which will serve for most needs.
-.Sp
-A specification has the syntax[\fBdir:\fR|\fBind:\fR][\fBord:\fR|\fBgen:\fR](\fBany\fR|\fBsys\fR|\fBbase\fR|\fBnone\fR)
-.Sp
-The optional first word limits the specification to
-structs that are used directly (\fBdir:\fR) or used indirectly (\fBind:\fR).
-A struct type is used directly when it is the type of a variable, member.
-Indirect uses arise through pointers to structs.
-That is, when use of an incomplete struct would be legal, the use is indirect.
-An example is
-\&\fBstruct one direct; struct two * indirect;\fR.
-.Sp
-The optional second word limits the specification to
-ordinary structs (\fBord:\fR) or generic structs (\fBgen:\fR).
-Generic structs are a bit complicated to explain.
-For \*(C+, these are non-explicit specializations of template classes,
-or non-template classes within the above.
-Other programming languages have generics,
-but \fB\-femit\-struct\-debug\-detailed\fR does not yet implement them.
-.Sp
-The third word specifies the source files for those
-structs for which the compiler will emit debug information.
-The values \fBnone\fR and \fBany\fR have the normal meaning.
-The value \fBbase\fR means that
-the base of name of the file in which the type declaration appears
-must match the base of the name of the main compilation file.
-In practice, this means that
-types declared in \fIfoo.c\fR and \fIfoo.h\fR will have debug information,
-but types declared in other header will not.
-The value \fBsys\fR means those types satisfying \fBbase\fR
-or declared in system or compiler headers.
-.Sp
-You may need to experiment to determine the best settings for your application.
-.Sp
-The default is \fB\-femit\-struct\-debug\-detailed=all\fR.
-.Sp
-This option works only with \s-1DWARF\s0 2.
-.IP "\fB\-fenable\-icf\-debug\fR" 4
-.IX Item "-fenable-icf-debug"
-Generate additional debug information to support identical code folding (\s-1ICF\s0).
-This option only works with \s-1DWARF\s0 version 2 or higher.
-.IP "\fB\-fno\-merge\-debug\-strings\fR" 4
-.IX Item "-fno-merge-debug-strings"
-Direct the linker to not merge together strings in the debugging
-information which are identical in different object files. Merging is
-not supported by all assemblers or linkers. Merging decreases the size
-of the debug information in the output file at the cost of increasing
-link processing time. Merging is enabled by default.
-.IP "\fB\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
-.IX Item "-fdebug-prefix-map=old=new"
-When compiling files in directory \fI\fIold\fI\fR, record debugging
-information describing them as in \fI\fInew\fI\fR instead.
-.IP "\fB\-fno\-dwarf2\-cfi\-asm\fR" 4
-.IX Item "-fno-dwarf2-cfi-asm"
-Emit \s-1DWARF\s0 2 unwind info as compiler generated \f(CW\*(C`.eh_frame\*(C'\fR section
-instead of using \s-1GAS\s0 \f(CW\*(C`.cfi_*\*(C'\fR directives.
-.IP "\fB\-p\fR" 4
-.IX Item "-p"
-Generate extra code to write profile information suitable for the
-analysis program \fBprof\fR. You must use this option when compiling
-the source files you want data about, and you must also use it when
-linking.
-.IP "\fB\-pg\fR" 4
-.IX Item "-pg"
-Generate extra code to write profile information suitable for the
-analysis program \fBgprof\fR. You must use this option when compiling
-the source files you want data about, and you must also use it when
-linking.
-.IP "\fB\-Q\fR" 4
-.IX Item "-Q"
-Makes the compiler print out each function name as it is compiled, and
-print some statistics about each pass when it finishes.
-.IP "\fB\-ftime\-report\fR" 4
-.IX Item "-ftime-report"
-Makes the compiler print some statistics about the time consumed by each
-pass when it finishes.
-.IP "\fB\-fmem\-report\fR" 4
-.IX Item "-fmem-report"
-Makes the compiler print some statistics about permanent memory
-allocation when it finishes.
-.IP "\fB\-fpre\-ipa\-mem\-report\fR" 4
-.IX Item "-fpre-ipa-mem-report"
-.PD 0
-.IP "\fB\-fpost\-ipa\-mem\-report\fR" 4
-.IX Item "-fpost-ipa-mem-report"
-.PD
-Makes the compiler print some statistics about permanent memory
-allocation before or after interprocedural optimization.
-.IP "\fB\-fstack\-usage\fR" 4
-.IX Item "-fstack-usage"
-Makes the compiler output stack usage information for the program, on a
-per-function basis. The filename for the dump is made by appending
-\&\fI.su\fR to the \fIauxname\fR. \fIauxname\fR is generated from the name of
-the output file, if explicitly specified and it is not an executable,
-otherwise it is the basename of the source file. An entry is made up
-of three fields:
-.RS 4
-.IP "\(bu" 4
-The name of the function.
-.IP "\(bu" 4
-A number of bytes.
-.IP "\(bu" 4
-One or more qualifiers: \f(CW\*(C`static\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR, \f(CW\*(C`bounded\*(C'\fR.
-.RE
-.RS 4
-.Sp
-The qualifier \f(CW\*(C`static\*(C'\fR means that the function manipulates the stack
-statically: a fixed number of bytes are allocated for the frame on function
-entry and released on function exit; no stack adjustments are otherwise made
-in the function. The second field is this fixed number of bytes.
-.Sp
-The qualifier \f(CW\*(C`dynamic\*(C'\fR means that the function manipulates the stack
-dynamically: in addition to the static allocation described above, stack
-adjustments are made in the body of the function, for example to push/pop
-arguments around function calls. If the qualifier \f(CW\*(C`bounded\*(C'\fR is also
-present, the amount of these adjustments is bounded at compile-time and
-the second field is an upper bound of the total amount of stack used by
-the function. If it is not present, the amount of these adjustments is
-not bounded at compile-time and the second field only represents the
-bounded part.
-.RE
-.IP "\fB\-fprofile\-arcs\fR" 4
-.IX Item "-fprofile-arcs"
-Add code so that program flow \fIarcs\fR are instrumented. During
-execution the program records how many times each branch and call is
-executed and how many times it is taken or returns. When the compiled
-program exits it saves this data to a file called
-\&\fI\fIauxname\fI.gcda\fR for each source file. The data may be used for
-profile-directed optimizations (\fB\-fbranch\-probabilities\fR), or for
-test coverage analysis (\fB\-ftest\-coverage\fR). Each object file's
-\&\fIauxname\fR is generated from the name of the output file, if
-explicitly specified and it is not the final executable, otherwise it is
-the basename of the source file. In both cases any suffix is removed
-(e.g. \fIfoo.gcda\fR for input file \fIdir/foo.c\fR, or
-\&\fIdir/foo.gcda\fR for output file specified as \fB\-o dir/foo.o\fR).
-.IP "\fB\-\-coverage\fR" 4
-.IX Item "--coverage"
-This option is used to compile and link code instrumented for coverage
-analysis. The option is a synonym for \fB\-fprofile\-arcs\fR
-\&\fB\-ftest\-coverage\fR (when compiling) and \fB\-lgcov\fR (when
-linking). See the documentation for those options for more details.
-.RS 4
-.IP "\(bu" 4
-Compile the source files with \fB\-fprofile\-arcs\fR plus optimization
-and code generation options. For test coverage analysis, use the
-additional \fB\-ftest\-coverage\fR option. You do not need to profile
-every source file in a program.
-.IP "\(bu" 4
-Link your object files with \fB\-lgcov\fR or \fB\-fprofile\-arcs\fR
-(the latter implies the former).
-.IP "\(bu" 4
-Run the program on a representative workload to generate the arc profile
-information. This may be repeated any number of times. You can run
-concurrent instances of your program, and provided that the file system
-supports locking, the data files will be correctly updated. Also
-\&\f(CW\*(C`fork\*(C'\fR calls are detected and correctly handled (double counting
-will not happen).
-.IP "\(bu" 4
-For profile-directed optimizations, compile the source files again with
-the same optimization and code generation options plus
-\&\fB\-fbranch\-probabilities\fR.
-.IP "\(bu" 4
-For test coverage analysis, use \fBgcov\fR to produce human readable
-information from the \fI.gcno\fR and \fI.gcda\fR files. Refer to the
-\&\fBgcov\fR documentation for further information.
-.RE
-.RS 4
-.Sp
-With \fB\-fprofile\-arcs\fR, for each function of your program \s-1GCC\s0
-creates a program flow graph, then finds a spanning tree for the graph.
-Only arcs that are not on the spanning tree have to be instrumented: the
-compiler adds code to count the number of times that these arcs are
-executed. When an arc is the only exit or only entrance to a block, the
-instrumentation code can be added to the block; otherwise, a new basic
-block must be created to hold the instrumentation code.
-.RE
-.IP "\fB\-ftest\-coverage\fR" 4
-.IX Item "-ftest-coverage"
-Produce a notes file that the \fBgcov\fR code-coverage utility can use to
-show program coverage. Each source file's note file is called
-\&\fI\fIauxname\fI.gcno\fR. Refer to the \fB\-fprofile\-arcs\fR option
-above for a description of \fIauxname\fR and instructions on how to
-generate test coverage data. Coverage data will match the source files
-more closely, if you do not optimize.
-.IP "\fB\-fdbg\-cnt\-list\fR" 4
-.IX Item "-fdbg-cnt-list"
-Print the name and the counter upper bound for all debug counters.
-.IP "\fB\-fdbg\-cnt=\fR\fIcounter-value-list\fR" 4
-.IX Item "-fdbg-cnt=counter-value-list"
-Set the internal debug counter upper bound. \fIcounter-value-list\fR
-is a comma-separated list of \fIname\fR:\fIvalue\fR pairs
-which sets the upper bound of each debug counter \fIname\fR to \fIvalue\fR.
-All debug counters have the initial upper bound of \fI\s-1UINT_MAX\s0\fR,
-thus \fIdbg_cnt()\fR returns true always unless the upper bound is set by this option.
-e.g. With \-fdbg\-cnt=dce:10,tail_call:0
-dbg_cnt(dce) will return true only for first 10 invocations
-.IP "\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR" 4
-.IX Item "-fenable-kind-pass"
-.PD 0
-.IP "\fB\-fdisable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
-.IX Item "-fdisable-kind-pass=range-list"
-.PD
-This is a set of debugging options that are used to explicitly disable/enable
-optimization passes. For compiler users, regular options for enabling/disabling
-passes should be used instead.
-.RS 4
-.IP "*<\-fdisable\-ipa\-\fIpass\fR>" 4
-.IX Item "*<-fdisable-ipa-pass>"
-Disable ipa pass \fIpass\fR. \fIpass\fR is the pass name. If the same pass is
-statically invoked in the compiler multiple times, the pass name should be
-appended with a sequential number starting from 1.
-.IP "*<\-fdisable\-rtl\-\fIpass\fR>" 4
-.IX Item "*<-fdisable-rtl-pass>"
-.PD 0
-.IP "*<\-fdisable\-rtl\-\fIpass\fR=\fIrange-list\fR>" 4
-.IX Item "*<-fdisable-rtl-pass=range-list>"
-.PD
-Disable rtl pass \fIpass\fR. \fIpass\fR is the pass name. If the same pass is
-statically invoked in the compiler multiple times, the pass name should be
-appended with a sequential number starting from 1. \fIrange-list\fR is a comma
-seperated list of function ranges or assembler names. Each range is a number
-pair seperated by a colon. The range is inclusive in both ends. If the range
-is trivial, the number pair can be simplified as a single number. If the
-function's cgraph node's \fIuid\fR is falling within one of the specified ranges,
-the \fIpass\fR is disabled for that function. The \fIuid\fR is shown in the
-function header of a dump file, and the pass names can be dumped by using
-option \fB\-fdump\-passes\fR.
-.IP "*<\-fdisable\-tree\-\fIpass\fR>" 4
-.IX Item "*<-fdisable-tree-pass>"
-.PD 0
-.IP "*<\-fdisable\-tree\-\fIpass\fR=\fIrange-list\fR>" 4
-.IX Item "*<-fdisable-tree-pass=range-list>"
-.PD
-Disable tree pass \fIpass\fR. See \fB\-fdisable\-rtl\fR for the description of
-option arguments.
-.IP "*<\-fenable\-ipa\-\fIpass\fR>" 4
-.IX Item "*<-fenable-ipa-pass>"
-Enable ipa pass \fIpass\fR. \fIpass\fR is the pass name. If the same pass is
-statically invoked in the compiler multiple times, the pass name should be
-appended with a sequential number starting from 1.
-.IP "*<\-fenable\-rtl\-\fIpass\fR>" 4
-.IX Item "*<-fenable-rtl-pass>"
-.PD 0
-.IP "*<\-fenable\-rtl\-\fIpass\fR=\fIrange-list\fR>" 4
-.IX Item "*<-fenable-rtl-pass=range-list>"
-.PD
-Enable rtl pass \fIpass\fR. See \fB\-fdisable\-rtl\fR for option argument
-description and examples.
-.IP "*<\-fenable\-tree\-\fIpass\fR>" 4
-.IX Item "*<-fenable-tree-pass>"
-.PD 0
-.IP "*<\-fenable\-tree\-\fIpass\fR=\fIrange-list\fR>" 4
-.IX Item "*<-fenable-tree-pass=range-list>"
-.PD
-Enable tree pass \fIpass\fR. See \fB\-fdisable\-rtl\fR for the description
-of option arguments.
-.Sp
-.Vb 10
-\& # disable ccp1 for all functions
-\& \-fdisable\-tree\-ccp1
-\& # disable complete unroll for function whose cgraph node uid is 1
-\& \-fenable\-tree\-cunroll=1
-\& # disable gcse2 for functions at the following ranges [1,1],
-\& # [300,400], and [400,1000]
-\& # disable gcse2 for functions foo and foo2
-\& \-fdisable\-rtl\-gcse2=foo,foo2
-\& # disable early inlining
-\& \-fdisable\-tree\-einline
-\& # disable ipa inlining
-\& \-fdisable\-ipa\-inline
-\& # enable tree full unroll
-\& \-fenable\-tree\-unroll
-.Ve
-.RE
-.RS 4
-.RE
-.IP "\fB\-d\fR\fIletters\fR" 4
-.IX Item "-dletters"
-.PD 0
-.IP "\fB\-fdump\-rtl\-\fR\fIpass\fR" 4
-.IX Item "-fdump-rtl-pass"
-.PD
-Says to make debugging dumps during compilation at times specified by
-\&\fIletters\fR. This is used for debugging the RTL-based passes of the
-compiler. The file names for most of the dumps are made by appending
-a pass number and a word to the \fIdumpname\fR, and the files are
-created in the directory of the output file. Note that the pass
-number is computed statically as passes get registered into the pass
-manager. Thus the numbering is not related to the dynamic order of
-execution of passes. In particular, a pass installed by a plugin
-could have a number over 200 even if it executed quite early.
-\&\fIdumpname\fR is generated from the name of the output file, if
-explicitly specified and it is not an executable, otherwise it is the
-basename of the source file. These switches may have different effects
-when \fB\-E\fR is used for preprocessing.
-.Sp
-Debug dumps can be enabled with a \fB\-fdump\-rtl\fR switch or some
-\&\fB\-d\fR option \fIletters\fR. Here are the possible
-letters for use in \fIpass\fR and \fIletters\fR, and their meanings:
-.RS 4
-.IP "\fB\-fdump\-rtl\-alignments\fR" 4
-.IX Item "-fdump-rtl-alignments"
-Dump after branch alignments have been computed.
-.IP "\fB\-fdump\-rtl\-asmcons\fR" 4
-.IX Item "-fdump-rtl-asmcons"
-Dump after fixing rtl statements that have unsatisfied in/out constraints.
-.IP "\fB\-fdump\-rtl\-auto_inc_dec\fR" 4
-.IX Item "-fdump-rtl-auto_inc_dec"
-Dump after auto-inc-dec discovery. This pass is only run on
-architectures that have auto inc or auto dec instructions.
-.IP "\fB\-fdump\-rtl\-barriers\fR" 4
-.IX Item "-fdump-rtl-barriers"
-Dump after cleaning up the barrier instructions.
-.IP "\fB\-fdump\-rtl\-bbpart\fR" 4
-.IX Item "-fdump-rtl-bbpart"
-Dump after partitioning hot and cold basic blocks.
-.IP "\fB\-fdump\-rtl\-bbro\fR" 4
-.IX Item "-fdump-rtl-bbro"
-Dump after block reordering.
-.IP "\fB\-fdump\-rtl\-btl1\fR" 4
-.IX Item "-fdump-rtl-btl1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-btl2\fR" 4
-.IX Item "-fdump-rtl-btl2"
-.PD
-\&\fB\-fdump\-rtl\-btl1\fR and \fB\-fdump\-rtl\-btl2\fR enable dumping
-after the two branch
-target load optimization passes.
-.IP "\fB\-fdump\-rtl\-bypass\fR" 4
-.IX Item "-fdump-rtl-bypass"
-Dump after jump bypassing and control flow optimizations.
-.IP "\fB\-fdump\-rtl\-combine\fR" 4
-.IX Item "-fdump-rtl-combine"
-Dump after the \s-1RTL\s0 instruction combination pass.
-.IP "\fB\-fdump\-rtl\-compgotos\fR" 4
-.IX Item "-fdump-rtl-compgotos"
-Dump after duplicating the computed gotos.
-.IP "\fB\-fdump\-rtl\-ce1\fR" 4
-.IX Item "-fdump-rtl-ce1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-ce2\fR" 4
-.IX Item "-fdump-rtl-ce2"
-.IP "\fB\-fdump\-rtl\-ce3\fR" 4
-.IX Item "-fdump-rtl-ce3"
-.PD
-\&\fB\-fdump\-rtl\-ce1\fR, \fB\-fdump\-rtl\-ce2\fR, and
-\&\fB\-fdump\-rtl\-ce3\fR enable dumping after the three
-if conversion passes.
-.IP "\fB\-fdump\-rtl\-cprop_hardreg\fR" 4
-.IX Item "-fdump-rtl-cprop_hardreg"
-Dump after hard register copy propagation.
-.IP "\fB\-fdump\-rtl\-csa\fR" 4
-.IX Item "-fdump-rtl-csa"
-Dump after combining stack adjustments.
-.IP "\fB\-fdump\-rtl\-cse1\fR" 4
-.IX Item "-fdump-rtl-cse1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-cse2\fR" 4
-.IX Item "-fdump-rtl-cse2"
-.PD
-\&\fB\-fdump\-rtl\-cse1\fR and \fB\-fdump\-rtl\-cse2\fR enable dumping after
-the two common sub-expression elimination passes.
-.IP "\fB\-fdump\-rtl\-dce\fR" 4
-.IX Item "-fdump-rtl-dce"
-Dump after the standalone dead code elimination passes.
-.IP "\fB\-fdump\-rtl\-dbr\fR" 4
-.IX Item "-fdump-rtl-dbr"
-Dump after delayed branch scheduling.
-.IP "\fB\-fdump\-rtl\-dce1\fR" 4
-.IX Item "-fdump-rtl-dce1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-dce2\fR" 4
-.IX Item "-fdump-rtl-dce2"
-.PD
-\&\fB\-fdump\-rtl\-dce1\fR and \fB\-fdump\-rtl\-dce2\fR enable dumping after
-the two dead store elimination passes.
-.IP "\fB\-fdump\-rtl\-eh\fR" 4
-.IX Item "-fdump-rtl-eh"
-Dump after finalization of \s-1EH\s0 handling code.
-.IP "\fB\-fdump\-rtl\-eh_ranges\fR" 4
-.IX Item "-fdump-rtl-eh_ranges"
-Dump after conversion of \s-1EH\s0 handling range regions.
-.IP "\fB\-fdump\-rtl\-expand\fR" 4
-.IX Item "-fdump-rtl-expand"
-Dump after \s-1RTL\s0 generation.
-.IP "\fB\-fdump\-rtl\-fwprop1\fR" 4
-.IX Item "-fdump-rtl-fwprop1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-fwprop2\fR" 4
-.IX Item "-fdump-rtl-fwprop2"
-.PD
-\&\fB\-fdump\-rtl\-fwprop1\fR and \fB\-fdump\-rtl\-fwprop2\fR enable
-dumping after the two forward propagation passes.
-.IP "\fB\-fdump\-rtl\-gcse1\fR" 4
-.IX Item "-fdump-rtl-gcse1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-gcse2\fR" 4
-.IX Item "-fdump-rtl-gcse2"
-.PD
-\&\fB\-fdump\-rtl\-gcse1\fR and \fB\-fdump\-rtl\-gcse2\fR enable dumping
-after global common subexpression elimination.
-.IP "\fB\-fdump\-rtl\-init\-regs\fR" 4
-.IX Item "-fdump-rtl-init-regs"
-Dump after the initialization of the registers.
-.IP "\fB\-fdump\-rtl\-initvals\fR" 4
-.IX Item "-fdump-rtl-initvals"
-Dump after the computation of the initial value sets.
-.IP "\fB\-fdump\-rtl\-into_cfglayout\fR" 4
-.IX Item "-fdump-rtl-into_cfglayout"
-Dump after converting to cfglayout mode.
-.IP "\fB\-fdump\-rtl\-ira\fR" 4
-.IX Item "-fdump-rtl-ira"
-Dump after iterated register allocation.
-.IP "\fB\-fdump\-rtl\-jump\fR" 4
-.IX Item "-fdump-rtl-jump"
-Dump after the second jump optimization.
-.IP "\fB\-fdump\-rtl\-loop2\fR" 4
-.IX Item "-fdump-rtl-loop2"
-\&\fB\-fdump\-rtl\-loop2\fR enables dumping after the rtl
-loop optimization passes.
-.IP "\fB\-fdump\-rtl\-mach\fR" 4
-.IX Item "-fdump-rtl-mach"
-Dump after performing the machine dependent reorganization pass, if that
-pass exists.
-.IP "\fB\-fdump\-rtl\-mode_sw\fR" 4
-.IX Item "-fdump-rtl-mode_sw"
-Dump after removing redundant mode switches.
-.IP "\fB\-fdump\-rtl\-rnreg\fR" 4
-.IX Item "-fdump-rtl-rnreg"
-Dump after register renumbering.
-.IP "\fB\-fdump\-rtl\-outof_cfglayout\fR" 4
-.IX Item "-fdump-rtl-outof_cfglayout"
-Dump after converting from cfglayout mode.
-.IP "\fB\-fdump\-rtl\-peephole2\fR" 4
-.IX Item "-fdump-rtl-peephole2"
-Dump after the peephole pass.
-.IP "\fB\-fdump\-rtl\-postreload\fR" 4
-.IX Item "-fdump-rtl-postreload"
-Dump after post-reload optimizations.
-.IP "\fB\-fdump\-rtl\-pro_and_epilogue\fR" 4
-.IX Item "-fdump-rtl-pro_and_epilogue"
-Dump after generating the function pro and epilogues.
-.IP "\fB\-fdump\-rtl\-regmove\fR" 4
-.IX Item "-fdump-rtl-regmove"
-Dump after the register move pass.
-.IP "\fB\-fdump\-rtl\-sched1\fR" 4
-.IX Item "-fdump-rtl-sched1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-sched2\fR" 4
-.IX Item "-fdump-rtl-sched2"
-.PD
-\&\fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR enable dumping
-after the basic block scheduling passes.
-.IP "\fB\-fdump\-rtl\-see\fR" 4
-.IX Item "-fdump-rtl-see"
-Dump after sign extension elimination.
-.IP "\fB\-fdump\-rtl\-seqabstr\fR" 4
-.IX Item "-fdump-rtl-seqabstr"
-Dump after common sequence discovery.
-.IP "\fB\-fdump\-rtl\-shorten\fR" 4
-.IX Item "-fdump-rtl-shorten"
-Dump after shortening branches.
-.IP "\fB\-fdump\-rtl\-sibling\fR" 4
-.IX Item "-fdump-rtl-sibling"
-Dump after sibling call optimizations.
-.IP "\fB\-fdump\-rtl\-split1\fR" 4
-.IX Item "-fdump-rtl-split1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-split2\fR" 4
-.IX Item "-fdump-rtl-split2"
-.IP "\fB\-fdump\-rtl\-split3\fR" 4
-.IX Item "-fdump-rtl-split3"
-.IP "\fB\-fdump\-rtl\-split4\fR" 4
-.IX Item "-fdump-rtl-split4"
-.IP "\fB\-fdump\-rtl\-split5\fR" 4
-.IX Item "-fdump-rtl-split5"
-.PD
-\&\fB\-fdump\-rtl\-split1\fR, \fB\-fdump\-rtl\-split2\fR,
-\&\fB\-fdump\-rtl\-split3\fR, \fB\-fdump\-rtl\-split4\fR and
-\&\fB\-fdump\-rtl\-split5\fR enable dumping after five rounds of
-instruction splitting.
-.IP "\fB\-fdump\-rtl\-sms\fR" 4
-.IX Item "-fdump-rtl-sms"
-Dump after modulo scheduling. This pass is only run on some
-architectures.
-.IP "\fB\-fdump\-rtl\-stack\fR" 4
-.IX Item "-fdump-rtl-stack"
-Dump after conversion from \s-1GCC\s0's \*(L"flat register file\*(R" registers to the
-x87's stack-like registers. This pass is only run on x86 variants.
-.IP "\fB\-fdump\-rtl\-subreg1\fR" 4
-.IX Item "-fdump-rtl-subreg1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-subreg2\fR" 4
-.IX Item "-fdump-rtl-subreg2"
-.PD
-\&\fB\-fdump\-rtl\-subreg1\fR and \fB\-fdump\-rtl\-subreg2\fR enable dumping after
-the two subreg expansion passes.
-.IP "\fB\-fdump\-rtl\-unshare\fR" 4
-.IX Item "-fdump-rtl-unshare"
-Dump after all rtl has been unshared.
-.IP "\fB\-fdump\-rtl\-vartrack\fR" 4
-.IX Item "-fdump-rtl-vartrack"
-Dump after variable tracking.
-.IP "\fB\-fdump\-rtl\-vregs\fR" 4
-.IX Item "-fdump-rtl-vregs"
-Dump after converting virtual registers to hard registers.
-.IP "\fB\-fdump\-rtl\-web\fR" 4
-.IX Item "-fdump-rtl-web"
-Dump after live range splitting.
-.IP "\fB\-fdump\-rtl\-regclass\fR" 4
-.IX Item "-fdump-rtl-regclass"
-.PD 0
-.IP "\fB\-fdump\-rtl\-subregs_of_mode_init\fR" 4
-.IX Item "-fdump-rtl-subregs_of_mode_init"
-.IP "\fB\-fdump\-rtl\-subregs_of_mode_finish\fR" 4
-.IX Item "-fdump-rtl-subregs_of_mode_finish"
-.IP "\fB\-fdump\-rtl\-dfinit\fR" 4
-.IX Item "-fdump-rtl-dfinit"
-.IP "\fB\-fdump\-rtl\-dfinish\fR" 4
-.IX Item "-fdump-rtl-dfinish"
-.PD
-These dumps are defined but always produce empty files.
-.IP "\fB\-fdump\-rtl\-all\fR" 4
-.IX Item "-fdump-rtl-all"
-Produce all the dumps listed above.
-.IP "\fB\-dA\fR" 4
-.IX Item "-dA"
-Annotate the assembler output with miscellaneous debugging information.
-.IP "\fB\-dD\fR" 4
-.IX Item "-dD"
-Dump all macro definitions, at the end of preprocessing, in addition to
-normal output.
-.IP "\fB\-dH\fR" 4
-.IX Item "-dH"
-Produce a core dump whenever an error occurs.
-.IP "\fB\-dm\fR" 4
-.IX Item "-dm"
-Print statistics on memory usage, at the end of the run, to
-standard error.
-.IP "\fB\-dp\fR" 4
-.IX Item "-dp"
-Annotate the assembler output with a comment indicating which
-pattern and alternative was used. The length of each instruction is
-also printed.
-.IP "\fB\-dP\fR" 4
-.IX Item "-dP"
-Dump the \s-1RTL\s0 in the assembler output as a comment before each instruction.
-Also turns on \fB\-dp\fR annotation.
-.IP "\fB\-dv\fR" 4
-.IX Item "-dv"
-For each of the other indicated dump files (\fB\-fdump\-rtl\-\fR\fIpass\fR),
-dump a representation of the control flow graph suitable for viewing with \s-1VCG\s0
-to \fI\fIfile\fI.\fIpass\fI.vcg\fR.
-.IP "\fB\-dx\fR" 4
-.IX Item "-dx"
-Just generate \s-1RTL\s0 for a function instead of compiling it. Usually used
-with \fB\-fdump\-rtl\-expand\fR.
-.RE
-.RS 4
-.RE
-.IP "\fB\-fdump\-noaddr\fR" 4
-.IX Item "-fdump-noaddr"
-When doing debugging dumps, suppress address output. This makes it more
-feasible to use diff on debugging dumps for compiler invocations with
-different compiler binaries and/or different
-text / bss / data / heap / stack / dso start locations.
-.IP "\fB\-fdump\-unnumbered\fR" 4
-.IX Item "-fdump-unnumbered"
-When doing debugging dumps, suppress instruction numbers and address output.
-This makes it more feasible to use diff on debugging dumps for compiler
-invocations with different options, in particular with and without
-\&\fB\-g\fR.
-.IP "\fB\-fdump\-unnumbered\-links\fR" 4
-.IX Item "-fdump-unnumbered-links"
-When doing debugging dumps (see \fB\-d\fR option above), suppress
-instruction numbers for the links to the previous and next instructions
-in a sequence.
-.IP "\fB\-fdump\-translation\-unit\fR (\*(C+ only)" 4
-.IX Item "-fdump-translation-unit ( only)"
-.PD 0
-.IP "\fB\-fdump\-translation\-unit\-\fR\fIoptions\fR\fB \fR(\*(C+ only)" 4
-.IX Item "-fdump-translation-unit-options ( only)"
-.PD
-Dump a representation of the tree structure for the entire translation
-unit to a file. The file name is made by appending \fI.tu\fR to the
-source file name, and the file is created in the same directory as the
-output file. If the \fB\-\fR\fIoptions\fR form is used, \fIoptions\fR
-controls the details of the dump as described for the
-\&\fB\-fdump\-tree\fR options.
-.IP "\fB\-fdump\-class\-hierarchy\fR (\*(C+ only)" 4
-.IX Item "-fdump-class-hierarchy ( only)"
-.PD 0
-.IP "\fB\-fdump\-class\-hierarchy\-\fR\fIoptions\fR\fB \fR(\*(C+ only)" 4
-.IX Item "-fdump-class-hierarchy-options ( only)"
-.PD
-Dump a representation of each class's hierarchy and virtual function
-table layout to a file. The file name is made by appending
-\&\fI.class\fR to the source file name, and the file is created in the
-same directory as the output file. If the \fB\-\fR\fIoptions\fR form
-is used, \fIoptions\fR controls the details of the dump as described
-for the \fB\-fdump\-tree\fR options.
-.IP "\fB\-fdump\-ipa\-\fR\fIswitch\fR" 4
-.IX Item "-fdump-ipa-switch"
-Control the dumping at various stages of inter-procedural analysis
-language tree to a file. The file name is generated by appending a
-switch specific suffix to the source file name, and the file is created
-in the same directory as the output file. The following dumps are
-possible:
-.RS 4
-.IP "\fBall\fR" 4
-.IX Item "all"
-Enables all inter-procedural analysis dumps.
-.IP "\fBcgraph\fR" 4
-.IX Item "cgraph"
-Dumps information about call-graph optimization, unused function removal,
-and inlining decisions.
-.IP "\fBinline\fR" 4
-.IX Item "inline"
-Dump after function inlining.
-.RE
-.RS 4
-.RE
-.IP "\fB\-fdump\-passes\fR" 4
-.IX Item "-fdump-passes"
-Dump the list of optimization passes that are turned on and off by
-the current command line options.
-.IP "\fB\-fdump\-statistics\-\fR\fIoption\fR" 4
-.IX Item "-fdump-statistics-option"
-Enable and control dumping of pass statistics in a separate file. The
-file name is generated by appending a suffix ending in
-\&\fB.statistics\fR to the source file name, and the file is created in
-the same directory as the output file. If the \fB\-\fR\fIoption\fR
-form is used, \fB\-stats\fR will cause counters to be summed over the
-whole compilation unit while \fB\-details\fR will dump every event as
-the passes generate them. The default with no option is to sum
-counters for each function compiled.
-.IP "\fB\-fdump\-tree\-\fR\fIswitch\fR" 4
-.IX Item "-fdump-tree-switch"
-.PD 0
-.IP "\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR" 4
-.IX Item "-fdump-tree-switch-options"
-.PD
-Control the dumping at various stages of processing the intermediate
-language tree to a file. The file name is generated by appending a
-switch specific suffix to the source file name, and the file is
-created in the same directory as the output file. If the
-\&\fB\-\fR\fIoptions\fR form is used, \fIoptions\fR is a list of
-\&\fB\-\fR separated options that control the details of the dump. Not
-all options are applicable to all dumps, those which are not
-meaningful will be ignored. The following options are available
-.RS 4
-.IP "\fBaddress\fR" 4
-.IX Item "address"
-Print the address of each node. Usually this is not meaningful as it
-changes according to the environment and source file. Its primary use
-is for tying up a dump file with a debug environment.
-.IP "\fBasmname\fR" 4
-.IX Item "asmname"
-If \f(CW\*(C`DECL_ASSEMBLER_NAME\*(C'\fR has been set for a given decl, use that
-in the dump instead of \f(CW\*(C`DECL_NAME\*(C'\fR. Its primary use is ease of
-use working backward from mangled names in the assembly file.
-.IP "\fBslim\fR" 4
-.IX Item "slim"
-Inhibit dumping of members of a scope or body of a function merely
-because that scope has been reached. Only dump such items when they
-are directly reachable by some other path. When dumping pretty-printed
-trees, this option inhibits dumping the bodies of control structures.
-.IP "\fBraw\fR" 4
-.IX Item "raw"
-Print a raw representation of the tree. By default, trees are
-pretty-printed into a C\-like representation.
-.IP "\fBdetails\fR" 4
-.IX Item "details"
-Enable more detailed dumps (not honored by every dump option).
-.IP "\fBstats\fR" 4
-.IX Item "stats"
-Enable dumping various statistics about the pass (not honored by every dump
-option).
-.IP "\fBblocks\fR" 4
-.IX Item "blocks"
-Enable showing basic block boundaries (disabled in raw dumps).
-.IP "\fBvops\fR" 4
-.IX Item "vops"
-Enable showing virtual operands for every statement.
-.IP "\fBlineno\fR" 4
-.IX Item "lineno"
-Enable showing line numbers for statements.
-.IP "\fBuid\fR" 4
-.IX Item "uid"
-Enable showing the unique \s-1ID\s0 (\f(CW\*(C`DECL_UID\*(C'\fR) for each variable.
-.IP "\fBverbose\fR" 4
-.IX Item "verbose"
-Enable showing the tree dump for each statement.
-.IP "\fBeh\fR" 4
-.IX Item "eh"
-Enable showing the \s-1EH\s0 region number holding each statement.
-.IP "\fBall\fR" 4
-.IX Item "all"
-Turn on all options, except \fBraw\fR, \fBslim\fR, \fBverbose\fR
-and \fBlineno\fR.
-.RE
-.RS 4
-.Sp
-The following tree dumps are possible:
-.IP "\fBoriginal\fR" 4
-.IX Item "original"
-Dump before any tree based optimization, to \fI\fIfile\fI.original\fR.
-.IP "\fBoptimized\fR" 4
-.IX Item "optimized"
-Dump after all tree based optimization, to \fI\fIfile\fI.optimized\fR.
-.IP "\fBgimple\fR" 4
-.IX Item "gimple"
-Dump each function before and after the gimplification pass to a file. The
-file name is made by appending \fI.gimple\fR to the source file name.
-.IP "\fBcfg\fR" 4
-.IX Item "cfg"
-Dump the control flow graph of each function to a file. The file name is
-made by appending \fI.cfg\fR to the source file name.
-.IP "\fBvcg\fR" 4
-.IX Item "vcg"
-Dump the control flow graph of each function to a file in \s-1VCG\s0 format. The
-file name is made by appending \fI.vcg\fR to the source file name. Note
-that if the file contains more than one function, the generated file cannot
-be used directly by \s-1VCG\s0. You will need to cut and paste each function's
-graph into its own separate file first.
-.IP "\fBch\fR" 4
-.IX Item "ch"
-Dump each function after copying loop headers. The file name is made by
-appending \fI.ch\fR to the source file name.
-.IP "\fBssa\fR" 4
-.IX Item "ssa"
-Dump \s-1SSA\s0 related information to a file. The file name is made by appending
-\&\fI.ssa\fR to the source file name.
-.IP "\fBalias\fR" 4
-.IX Item "alias"
-Dump aliasing information for each function. The file name is made by
-appending \fI.alias\fR to the source file name.
-.IP "\fBccp\fR" 4
-.IX Item "ccp"
-Dump each function after \s-1CCP\s0. The file name is made by appending
-\&\fI.ccp\fR to the source file name.
-.IP "\fBstoreccp\fR" 4
-.IX Item "storeccp"
-Dump each function after STORE-CCP. The file name is made by appending
-\&\fI.storeccp\fR to the source file name.
-.IP "\fBpre\fR" 4
-.IX Item "pre"
-Dump trees after partial redundancy elimination. The file name is made
-by appending \fI.pre\fR to the source file name.
-.IP "\fBfre\fR" 4
-.IX Item "fre"
-Dump trees after full redundancy elimination. The file name is made
-by appending \fI.fre\fR to the source file name.
-.IP "\fBcopyprop\fR" 4
-.IX Item "copyprop"
-Dump trees after copy propagation. The file name is made
-by appending \fI.copyprop\fR to the source file name.
-.IP "\fBstore_copyprop\fR" 4
-.IX Item "store_copyprop"
-Dump trees after store copy-propagation. The file name is made
-by appending \fI.store_copyprop\fR to the source file name.
-.IP "\fBdce\fR" 4
-.IX Item "dce"
-Dump each function after dead code elimination. The file name is made by
-appending \fI.dce\fR to the source file name.
-.IP "\fBmudflap\fR" 4
-.IX Item "mudflap"
-Dump each function after adding mudflap instrumentation. The file name is
-made by appending \fI.mudflap\fR to the source file name.
-.IP "\fBsra\fR" 4
-.IX Item "sra"
-Dump each function after performing scalar replacement of aggregates. The
-file name is made by appending \fI.sra\fR to the source file name.
-.IP "\fBsink\fR" 4
-.IX Item "sink"
-Dump each function after performing code sinking. The file name is made
-by appending \fI.sink\fR to the source file name.
-.IP "\fBdom\fR" 4
-.IX Item "dom"
-Dump each function after applying dominator tree optimizations. The file
-name is made by appending \fI.dom\fR to the source file name.
-.IP "\fBdse\fR" 4
-.IX Item "dse"
-Dump each function after applying dead store elimination. The file
-name is made by appending \fI.dse\fR to the source file name.
-.IP "\fBphiopt\fR" 4
-.IX Item "phiopt"
-Dump each function after optimizing \s-1PHI\s0 nodes into straightline code. The file
-name is made by appending \fI.phiopt\fR to the source file name.
-.IP "\fBforwprop\fR" 4
-.IX Item "forwprop"
-Dump each function after forward propagating single use variables. The file
-name is made by appending \fI.forwprop\fR to the source file name.
-.IP "\fBcopyrename\fR" 4
-.IX Item "copyrename"
-Dump each function after applying the copy rename optimization. The file
-name is made by appending \fI.copyrename\fR to the source file name.
-.IP "\fBnrv\fR" 4
-.IX Item "nrv"
-Dump each function after applying the named return value optimization on
-generic trees. The file name is made by appending \fI.nrv\fR to the source
-file name.
-.IP "\fBvect\fR" 4
-.IX Item "vect"
-Dump each function after applying vectorization of loops. The file name is
-made by appending \fI.vect\fR to the source file name.
-.IP "\fBslp\fR" 4
-.IX Item "slp"
-Dump each function after applying vectorization of basic blocks. The file name
-is made by appending \fI.slp\fR to the source file name.
-.IP "\fBvrp\fR" 4
-.IX Item "vrp"
-Dump each function after Value Range Propagation (\s-1VRP\s0). The file name
-is made by appending \fI.vrp\fR to the source file name.
-.IP "\fBall\fR" 4
-.IX Item "all"
-Enable all the available tree dumps with the flags provided in this option.
-.RE
-.RS 4
-.RE
-.IP "\fB\-ftree\-vectorizer\-verbose=\fR\fIn\fR" 4
-.IX Item "-ftree-vectorizer-verbose=n"
-This option controls the amount of debugging output the vectorizer prints.
-This information is written to standard error, unless
-\&\fB\-fdump\-tree\-all\fR or \fB\-fdump\-tree\-vect\fR is specified,
-in which case it is output to the usual dump listing file, \fI.vect\fR.
-For \fIn\fR=0 no diagnostic information is reported.
-If \fIn\fR=1 the vectorizer reports each loop that got vectorized,
-and the total number of loops that got vectorized.
-If \fIn\fR=2 the vectorizer also reports non-vectorized loops that passed
-the first analysis phase (vect_analyze_loop_form) \- i.e. countable,
-inner-most, single-bb, single\-entry/exit loops. This is the same verbosity
-level that \fB\-fdump\-tree\-vect\-stats\fR uses.
-Higher verbosity levels mean either more information dumped for each
-reported loop, or same amount of information reported for more loops:
-if \fIn\fR=3, vectorizer cost model information is reported.
-If \fIn\fR=4, alignment related information is added to the reports.
-If \fIn\fR=5, data-references related information (e.g. memory dependences,
-memory access-patterns) is added to the reports.
-If \fIn\fR=6, the vectorizer reports also non-vectorized inner-most loops
-that did not pass the first analysis phase (i.e., may not be countable, or
-may have complicated control-flow).
-If \fIn\fR=7, the vectorizer reports also non-vectorized nested loops.
-If \fIn\fR=8, \s-1SLP\s0 related information is added to the reports.
-For \fIn\fR=9, all the information the vectorizer generates during its
-analysis and transformation is reported. This is the same verbosity level
-that \fB\-fdump\-tree\-vect\-details\fR uses.
-.IP "\fB\-frandom\-seed=\fR\fIstring\fR" 4
-.IX Item "-frandom-seed=string"
-This option provides a seed that \s-1GCC\s0 uses when it would otherwise use
-random numbers. It is used to generate certain symbol names
-that have to be different in every compiled file. It is also used to
-place unique stamps in coverage data files and the object files that
-produce them. You can use the \fB\-frandom\-seed\fR option to produce
-reproducibly identical object files.
-.Sp
-The \fIstring\fR should be different for every file you compile.
-.IP "\fB\-fsched\-verbose=\fR\fIn\fR" 4
-.IX Item "-fsched-verbose=n"
-On targets that use instruction scheduling, this option controls the
-amount of debugging output the scheduler prints. This information is
-written to standard error, unless \fB\-fdump\-rtl\-sched1\fR or
-\&\fB\-fdump\-rtl\-sched2\fR is specified, in which case it is output
-to the usual dump listing file, \fI.sched1\fR or \fI.sched2\fR
-respectively. However for \fIn\fR greater than nine, the output is
-always printed to standard error.
-.Sp
-For \fIn\fR greater than zero, \fB\-fsched\-verbose\fR outputs the
-same information as \fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR.
-For \fIn\fR greater than one, it also output basic block probabilities,
-detailed ready list information and unit/insn info. For \fIn\fR greater
-than two, it includes \s-1RTL\s0 at abort point, control-flow and regions info.
-And for \fIn\fR over four, \fB\-fsched\-verbose\fR also includes
-dependence info.
-.IP "\fB\-save\-temps\fR" 4
-.IX Item "-save-temps"
-.PD 0
-.IP "\fB\-save\-temps=cwd\fR" 4
-.IX Item "-save-temps=cwd"
-.PD
-Store the usual \*(L"temporary\*(R" intermediate files permanently; place them
-in the current directory and name them based on the source file. Thus,
-compiling \fIfoo.c\fR with \fB\-c \-save\-temps\fR would produce files
-\&\fIfoo.i\fR and \fIfoo.s\fR, as well as \fIfoo.o\fR. This creates a
-preprocessed \fIfoo.i\fR output file even though the compiler now
-normally uses an integrated preprocessor.
-.Sp
-When used in combination with the \fB\-x\fR command line option,
-\&\fB\-save\-temps\fR is sensible enough to avoid over writing an
-input source file with the same extension as an intermediate file.
-The corresponding intermediate file may be obtained by renaming the
-source file before using \fB\-save\-temps\fR.
-.Sp
-If you invoke \s-1GCC\s0 in parallel, compiling several different source
-files that share a common base name in different subdirectories or the
-same source file compiled for multiple output destinations, it is
-likely that the different parallel compilers will interfere with each
-other, and overwrite the temporary files. For instance:
-.Sp
-.Vb 2
-\& gcc \-save\-temps \-o outdir1/foo.o indir1/foo.c&
-\& gcc \-save\-temps \-o outdir2/foo.o indir2/foo.c&
-.Ve
-.Sp
-may result in \fIfoo.i\fR and \fIfoo.o\fR being written to
-simultaneously by both compilers.
-.IP "\fB\-save\-temps=obj\fR" 4
-.IX Item "-save-temps=obj"
-Store the usual \*(L"temporary\*(R" intermediate files permanently. If the
-\&\fB\-o\fR option is used, the temporary files are based on the
-object file. If the \fB\-o\fR option is not used, the
-\&\fB\-save\-temps=obj\fR switch behaves like \fB\-save\-temps\fR.
-.Sp
-For example:
-.Sp
-.Vb 3
-\& gcc \-save\-temps=obj \-c foo.c
-\& gcc \-save\-temps=obj \-c bar.c \-o dir/xbar.o
-\& gcc \-save\-temps=obj foobar.c \-o dir2/yfoobar
-.Ve
-.Sp
-would create \fIfoo.i\fR, \fIfoo.s\fR, \fIdir/xbar.i\fR,
-\&\fIdir/xbar.s\fR, \fIdir2/yfoobar.i\fR, \fIdir2/yfoobar.s\fR, and
-\&\fIdir2/yfoobar.o\fR.
-.IP "\fB\-time\fR[\fB=\fR\fIfile\fR]" 4
-.IX Item "-time[=file]"
-Report the \s-1CPU\s0 time taken by each subprocess in the compilation
-sequence. For C source files, this is the compiler proper and assembler
-(plus the linker if linking is done).
-.Sp
-Without the specification of an output file, the output looks like this:
-.Sp
-.Vb 2
-\& # cc1 0.12 0.01
-\& # as 0.00 0.01
-.Ve
-.Sp
-The first number on each line is the \*(L"user time\*(R", that is time spent
-executing the program itself. The second number is \*(L"system time\*(R",
-time spent executing operating system routines on behalf of the program.
-Both numbers are in seconds.
-.Sp
-With the specification of an output file, the output is appended to the
-named file, and it looks like this:
-.Sp
-.Vb 2
-\& 0.12 0.01 cc1 <options>
-\& 0.00 0.01 as <options>
-.Ve
-.Sp
-The \*(L"user time\*(R" and the \*(L"system time\*(R" are moved before the program
-name, and the options passed to the program are displayed, so that one
-can later tell what file was being compiled, and with which options.
-.IP "\fB\-fvar\-tracking\fR" 4
-.IX Item "-fvar-tracking"
-Run variable tracking pass. It computes where variables are stored at each
-position in code. Better debugging information is then generated
-(if the debugging information format supports this information).
-.Sp
-It is enabled by default when compiling with optimization (\fB\-Os\fR,
-\&\fB\-O\fR, \fB\-O2\fR, ...), debugging information (\fB\-g\fR) and
-the debug info format supports it.
-.IP "\fB\-fvar\-tracking\-assignments\fR" 4
-.IX Item "-fvar-tracking-assignments"
-Annotate assignments to user variables early in the compilation and
-attempt to carry the annotations over throughout the compilation all the
-way to the end, in an attempt to improve debug information while
-optimizing. Use of \fB\-gdwarf\-4\fR is recommended along with it.
-.Sp
-It can be enabled even if var-tracking is disabled, in which case
-annotations will be created and maintained, but discarded at the end.
-.IP "\fB\-fvar\-tracking\-assignments\-toggle\fR" 4
-.IX Item "-fvar-tracking-assignments-toggle"
-Toggle \fB\-fvar\-tracking\-assignments\fR, in the same way that
-\&\fB\-gtoggle\fR toggles \fB\-g\fR.
-.IP "\fB\-print\-file\-name=\fR\fIlibrary\fR" 4
-.IX Item "-print-file-name=library"
-Print the full absolute name of the library file \fIlibrary\fR that
-would be used when linking\-\-\-and don't do anything else. With this
-option, \s-1GCC\s0 does not compile or link anything; it just prints the
-file name.
-.IP "\fB\-print\-multi\-directory\fR" 4
-.IX Item "-print-multi-directory"
-Print the directory name corresponding to the multilib selected by any
-other switches present in the command line. This directory is supposed
-to exist in \fB\s-1GCC_EXEC_PREFIX\s0\fR.
-.IP "\fB\-print\-multi\-lib\fR" 4
-.IX Item "-print-multi-lib"
-Print the mapping from multilib directory names to compiler switches
-that enable them. The directory name is separated from the switches by
-\&\fB;\fR, and each switch starts with an \fB@\fR instead of the
-\&\fB\-\fR, without spaces between multiple switches. This is supposed to
-ease shell-processing.
-.IP "\fB\-print\-multi\-os\-directory\fR" 4
-.IX Item "-print-multi-os-directory"
-Print the path to \s-1OS\s0 libraries for the selected
-multilib, relative to some \fIlib\fR subdirectory. If \s-1OS\s0 libraries are
-present in the \fIlib\fR subdirectory and no multilibs are used, this is
-usually just \fI.\fR, if \s-1OS\s0 libraries are present in \fIlib\fIsuffix\fI\fR
-sibling directories this prints e.g. \fI../lib64\fR, \fI../lib\fR or
-\&\fI../lib32\fR, or if \s-1OS\s0 libraries are present in \fIlib/\fIsubdir\fI\fR
-subdirectories it prints e.g. \fIamd64\fR, \fIsparcv9\fR or \fIev6\fR.
-.IP "\fB\-print\-prog\-name=\fR\fIprogram\fR" 4
-.IX Item "-print-prog-name=program"
-Like \fB\-print\-file\-name\fR, but searches for a program such as \fBcpp\fR.
-.IP "\fB\-print\-libgcc\-file\-name\fR" 4
-.IX Item "-print-libgcc-file-name"
-Same as \fB\-print\-file\-name=libgcc.a\fR.
-.Sp
-This is useful when you use \fB\-nostdlib\fR or \fB\-nodefaultlibs\fR
-but you do want to link with \fIlibgcc.a\fR. You can do
-.Sp
-.Vb 1
-\& gcc \-nostdlib <files>... \`gcc \-print\-libgcc\-file\-name\`
-.Ve
-.IP "\fB\-print\-search\-dirs\fR" 4
-.IX Item "-print-search-dirs"
-Print the name of the configured installation directory and a list of
-program and library directories \fBgcc\fR will search\-\-\-and don't do anything else.
-.Sp
-This is useful when \fBgcc\fR prints the error message
-\&\fBinstallation problem, cannot exec cpp0: No such file or directory\fR.
-To resolve this you either need to put \fIcpp0\fR and the other compiler
-components where \fBgcc\fR expects to find them, or you can set the environment
-variable \fB\s-1GCC_EXEC_PREFIX\s0\fR to the directory where you installed them.
-Don't forget the trailing \fB/\fR.
-.IP "\fB\-print\-sysroot\fR" 4
-.IX Item "-print-sysroot"
-Print the target sysroot directory that will be used during
-compilation. This is the target sysroot specified either at configure
-time or using the \fB\-\-sysroot\fR option, possibly with an extra
-suffix that depends on compilation options. If no target sysroot is
-specified, the option prints nothing.
-.IP "\fB\-print\-sysroot\-headers\-suffix\fR" 4
-.IX Item "-print-sysroot-headers-suffix"
-Print the suffix added to the target sysroot when searching for
-headers, or give an error if the compiler is not configured with such
-a suffix\-\-\-and don't do anything else.
-.IP "\fB\-dumpmachine\fR" 4
-.IX Item "-dumpmachine"
-Print the compiler's target machine (for example,
-\&\fBi686\-pc\-linux\-gnu\fR)\-\-\-and don't do anything else.
-.IP "\fB\-dumpversion\fR" 4
-.IX Item "-dumpversion"
-Print the compiler version (for example, \fB3.0\fR)\-\-\-and don't do
-anything else.
-.IP "\fB\-dumpspecs\fR" 4
-.IX Item "-dumpspecs"
-Print the compiler's built-in specs\-\-\-and don't do anything else. (This
-is used when \s-1GCC\s0 itself is being built.)
-.IP "\fB\-feliminate\-unused\-debug\-types\fR" 4
-.IX Item "-feliminate-unused-debug-types"
-Normally, when producing \s-1DWARF2\s0 output, \s-1GCC\s0 will emit debugging
-information for all types declared in a compilation
-unit, regardless of whether or not they are actually used
-in that compilation unit. Sometimes this is useful, such as
-if, in the debugger, you want to cast a value to a type that is
-not actually used in your program (but is declared). More often,
-however, this results in a significant amount of wasted space.
-With this option, \s-1GCC\s0 will avoid producing debug symbol output
-for types that are nowhere used in the source file being compiled.
-.SS "Options That Control Optimization"
-.IX Subsection "Options That Control Optimization"
-These options control various sorts of optimizations.
-.PP
-Without any optimization option, the compiler's goal is to reduce the
-cost of compilation and to make debugging produce the expected
-results. Statements are independent: if you stop the program with a
-breakpoint between statements, you can then assign a new value to any
-variable or change the program counter to any other statement in the
-function and get exactly the results you would expect from the source
-code.
-.PP
-Turning on optimization flags makes the compiler attempt to improve
-the performance and/or code size at the expense of compilation time
-and possibly the ability to debug the program.
-.PP
-The compiler performs optimization based on the knowledge it has of the
-program. Compiling multiple files at once to a single output file mode allows
-the compiler to use information gained from all of the files when compiling
-each of them.
-.PP
-Not all optimizations are controlled directly by a flag. Only
-optimizations that have a flag are listed in this section.
-.PP
-Most optimizations are only enabled if an \fB\-O\fR level is set on
-the command line. Otherwise they are disabled, even if individual
-optimization flags are specified.
-.PP
-Depending on the target and how \s-1GCC\s0 was configured, a slightly different
-set of optimizations may be enabled at each \fB\-O\fR level than
-those listed here. You can invoke \s-1GCC\s0 with \fB\-Q \-\-help=optimizers\fR
-to find out the exact set of optimizations that are enabled at each level.
-.IP "\fB\-O\fR" 4
-.IX Item "-O"
-.PD 0
-.IP "\fB\-O1\fR" 4
-.IX Item "-O1"
-.PD
-Optimize. Optimizing compilation takes somewhat more time, and a lot
-more memory for a large function.
-.Sp
-With \fB\-O\fR, the compiler tries to reduce code size and execution
-time, without performing any optimizations that take a great deal of
-compilation time.
-.Sp
-\&\fB\-O\fR turns on the following optimization flags:
-.Sp
-\&\fB\-fauto\-inc\-dec
-\&\-fcompare\-elim
-\&\-fcprop\-registers
-\&\-fdce
-\&\-fdefer\-pop
-\&\-fdelayed\-branch
-\&\-fdse
-\&\-fguess\-branch\-probability
-\&\-fif\-conversion2
-\&\-fif\-conversion
-\&\-fipa\-pure\-const
-\&\-fipa\-profile
-\&\-fipa\-reference
-\&\-fmerge\-constants
-\&\-fsplit\-wide\-types
-\&\-ftree\-bit\-ccp
-\&\-ftree\-builtin\-call\-dce
-\&\-ftree\-ccp
-\&\-ftree\-ch
-\&\-ftree\-copyrename
-\&\-ftree\-dce
-\&\-ftree\-dominator\-opts
-\&\-ftree\-dse
-\&\-ftree\-forwprop
-\&\-ftree\-fre
-\&\-ftree\-phiprop
-\&\-ftree\-sra
-\&\-ftree\-pta
-\&\-ftree\-ter
-\&\-funit\-at\-a\-time\fR
-.Sp
-\&\fB\-O\fR also turns on \fB\-fomit\-frame\-pointer\fR on machines
-where doing so does not interfere with debugging.
-.IP "\fB\-O2\fR" 4
-.IX Item "-O2"
-Optimize even more. \s-1GCC\s0 performs nearly all supported optimizations
-that do not involve a space-speed tradeoff.
-As compared to \fB\-O\fR, this option increases both compilation time
-and the performance of the generated code.
-.Sp
-\&\fB\-O2\fR turns on all optimization flags specified by \fB\-O\fR. It
-also turns on the following optimization flags:
-\&\fB\-fthread\-jumps
-\&\-falign\-functions \-falign\-jumps
-\&\-falign\-loops \-falign\-labels
-\&\-fcaller\-saves
-\&\-fcrossjumping
-\&\-fcse\-follow\-jumps \-fcse\-skip\-blocks
-\&\-fdelete\-null\-pointer\-checks
-\&\-fdevirtualize
-\&\-fexpensive\-optimizations
-\&\-fgcse \-fgcse\-lm
-\&\-finline\-small\-functions
-\&\-findirect\-inlining
-\&\-fipa\-sra
-\&\-foptimize\-sibling\-calls
-\&\-fpartial\-inlining
-\&\-fpeephole2
-\&\-fregmove
-\&\-freorder\-blocks \-freorder\-functions
-\&\-frerun\-cse\-after\-loop
-\&\-fsched\-interblock \-fsched\-spec
-\&\-fschedule\-insns \-fschedule\-insns2
-\&\-fstrict\-aliasing \-fstrict\-overflow
-\&\-ftree\-switch\-conversion
-\&\-ftree\-pre
-\&\-ftree\-vrp\fR
-.Sp
-Please note the warning under \fB\-fgcse\fR about
-invoking \fB\-O2\fR on programs that use computed gotos.
-.IP "\fB\-O3\fR" 4
-.IX Item "-O3"
-Optimize yet more. \fB\-O3\fR turns on all optimizations specified
-by \fB\-O2\fR and also turns on the \fB\-finline\-functions\fR,
-\&\fB\-funswitch\-loops\fR, \fB\-fpredictive\-commoning\fR,
-\&\fB\-fgcse\-after\-reload\fR, \fB\-ftree\-vectorize\fR and
-\&\fB\-fipa\-cp\-clone\fR options.
-.IP "\fB\-O0\fR" 4
-.IX Item "-O0"
-Reduce compilation time and make debugging produce the expected
-results. This is the default.
-.IP "\fB\-Os\fR" 4
-.IX Item "-Os"
-Optimize for size. \fB\-Os\fR enables all \fB\-O2\fR optimizations that
-do not typically increase code size. It also performs further
-optimizations designed to reduce code size.
-.Sp
-\&\fB\-Os\fR disables the following optimization flags:
-\&\fB\-falign\-functions \-falign\-jumps \-falign\-loops
-\&\-falign\-labels \-freorder\-blocks \-freorder\-blocks\-and\-partition
-\&\-fprefetch\-loop\-arrays \-ftree\-vect\-loop\-version\fR
-.IP "\fB\-Ofast\fR" 4
-.IX Item "-Ofast"
-Disregard strict standards compliance. \fB\-Ofast\fR enables all
-\&\fB\-O3\fR optimizations. It also enables optimizations that are not
-valid for all standard compliant programs.
-It turns on \fB\-ffast\-math\fR.
-.Sp
-If you use multiple \fB\-O\fR options, with or without level numbers,
-the last such option is the one that is effective.
-.PP
-Options of the form \fB\-f\fR\fIflag\fR specify machine-independent
-flags. Most flags have both positive and negative forms; the negative
-form of \fB\-ffoo\fR would be \fB\-fno\-foo\fR. In the table
-below, only one of the forms is listed\-\-\-the one you typically will
-use. You can figure out the other form by either removing \fBno\-\fR
-or adding it.
-.PP
-The following options control specific optimizations. They are either
-activated by \fB\-O\fR options or are related to ones that are. You
-can use the following flags in the rare cases when \*(L"fine-tuning\*(R" of
-optimizations to be performed is desired.
-.IP "\fB\-fno\-default\-inline\fR" 4
-.IX Item "-fno-default-inline"
-Do not make member functions inline by default merely because they are
-defined inside the class scope (\*(C+ only). Otherwise, when you specify
-\&\fB\-O\fR, member functions defined inside class scope are compiled
-inline by default; i.e., you don't need to add \fBinline\fR in front of
-the member function name.
-.IP "\fB\-fno\-defer\-pop\fR" 4
-.IX Item "-fno-defer-pop"
-Always pop the arguments to each function call as soon as that function
-returns. For machines which must pop arguments after a function call,
-the compiler normally lets arguments accumulate on the stack for several
-function calls and pops them all at once.
-.Sp
-Disabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fforward\-propagate\fR" 4
-.IX Item "-fforward-propagate"
-Perform a forward propagation pass on \s-1RTL\s0. The pass tries to combine two
-instructions and checks if the result can be simplified. If loop unrolling
-is active, two passes are performed and the second is scheduled after
-loop unrolling.
-.Sp
-This option is enabled by default at optimization levels \fB\-O\fR,
-\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-ffp\-contract=\fR\fIstyle\fR" 4
-.IX Item "-ffp-contract=style"
-\&\fB\-ffp\-contract=off\fR disables floating-point expression contraction.
-\&\fB\-ffp\-contract=fast\fR enables floating-point expression contraction
-such as forming of fused multiply-add operations if the target has
-native support for them.
-\&\fB\-ffp\-contract=on\fR enables floating-point expression contraction
-if allowed by the language standard. This is currently not implemented
-and treated equal to \fB\-ffp\-contract=off\fR.
-.Sp
-The default is \fB\-ffp\-contract=fast\fR.
-.IP "\fB\-fomit\-frame\-pointer\fR" 4
-.IX Item "-fomit-frame-pointer"
-Don't keep the frame pointer in a register for functions that
-don't need one. This avoids the instructions to save, set up and
-restore frame pointers; it also makes an extra register available
-in many functions. \fBIt also makes debugging impossible on
-some machines.\fR
-.Sp
-On some machines, such as the \s-1VAX\s0, this flag has no effect, because
-the standard calling sequence automatically handles the frame pointer
-and nothing is saved by pretending it doesn't exist. The
-machine-description macro \f(CW\*(C`FRAME_POINTER_REQUIRED\*(C'\fR controls
-whether a target machine supports this flag.
-.Sp
-Starting with \s-1GCC\s0 version 4.6, the default setting (when not optimizing for
-size) for 32\-bit Linux x86 and 32\-bit Darwin x86 targets has been changed to
-\&\fB\-fomit\-frame\-pointer\fR. The default can be reverted to
-\&\fB\-fno\-omit\-frame\-pointer\fR by configuring \s-1GCC\s0 with the
-\&\fB\-\-enable\-frame\-pointer\fR configure option.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-foptimize\-sibling\-calls\fR" 4
-.IX Item "-foptimize-sibling-calls"
-Optimize sibling and tail recursive calls.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fno\-inline\fR" 4
-.IX Item "-fno-inline"
-Don't pay attention to the \f(CW\*(C`inline\*(C'\fR keyword. Normally this option
-is used to keep the compiler from expanding any functions inline.
-Note that if you are not optimizing, no functions can be expanded inline.
-.IP "\fB\-finline\-small\-functions\fR" 4
-.IX Item "-finline-small-functions"
-Integrate functions into their callers when their body is smaller than expected
-function call code (so overall size of program gets smaller). The compiler
-heuristically decides which functions are simple enough to be worth integrating
-in this way.
-.Sp
-Enabled at level \fB\-O2\fR.
-.IP "\fB\-findirect\-inlining\fR" 4
-.IX Item "-findirect-inlining"
-Inline also indirect calls that are discovered to be known at compile
-time thanks to previous inlining. This option has any effect only
-when inlining itself is turned on by the \fB\-finline\-functions\fR
-or \fB\-finline\-small\-functions\fR options.
-.Sp
-Enabled at level \fB\-O2\fR.
-.IP "\fB\-finline\-functions\fR" 4
-.IX Item "-finline-functions"
-Integrate all simple functions into their callers. The compiler
-heuristically decides which functions are simple enough to be worth
-integrating in this way.
-.Sp
-If all calls to a given function are integrated, and the function is
-declared \f(CW\*(C`static\*(C'\fR, then the function is normally not output as
-assembler code in its own right.
-.Sp
-Enabled at level \fB\-O3\fR.
-.IP "\fB\-finline\-functions\-called\-once\fR" 4
-.IX Item "-finline-functions-called-once"
-Consider all \f(CW\*(C`static\*(C'\fR functions called once for inlining into their
-caller even if they are not marked \f(CW\*(C`inline\*(C'\fR. If a call to a given
-function is integrated, then the function is not output as assembler code
-in its own right.
-.Sp
-Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
-.IP "\fB\-fearly\-inlining\fR" 4
-.IX Item "-fearly-inlining"
-Inline functions marked by \f(CW\*(C`always_inline\*(C'\fR and functions whose body seems
-smaller than the function call overhead early before doing
-\&\fB\-fprofile\-generate\fR instrumentation and real inlining pass. Doing so
-makes profiling significantly cheaper and usually inlining faster on programs
-having large chains of nested wrapper functions.
-.Sp
-Enabled by default.
-.IP "\fB\-fipa\-sra\fR" 4
-.IX Item "-fipa-sra"
-Perform interprocedural scalar replacement of aggregates, removal of
-unused parameters and replacement of parameters passed by reference
-by parameters passed by value.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
-.IP "\fB\-finline\-limit=\fR\fIn\fR" 4
-.IX Item "-finline-limit=n"
-By default, \s-1GCC\s0 limits the size of functions that can be inlined. This flag
-allows coarse control of this limit. \fIn\fR is the size of functions that
-can be inlined in number of pseudo instructions.
-.Sp
-Inlining is actually controlled by a number of parameters, which may be
-specified individually by using \fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR.
-The \fB\-finline\-limit=\fR\fIn\fR option sets some of these parameters
-as follows:
-.RS 4
-.IP "\fBmax-inline-insns-single\fR" 4
-.IX Item "max-inline-insns-single"
-is set to \fIn\fR/2.
-.IP "\fBmax-inline-insns-auto\fR" 4
-.IX Item "max-inline-insns-auto"
-is set to \fIn\fR/2.
-.RE
-.RS 4
-.Sp
-See below for a documentation of the individual
-parameters controlling inlining and for the defaults of these parameters.
-.Sp
-\&\fINote:\fR there may be no value to \fB\-finline\-limit\fR that results
-in default behavior.
-.Sp
-\&\fINote:\fR pseudo instruction represents, in this particular context, an
-abstract measurement of function's size. In no way does it represent a count
-of assembly instructions and as such its exact meaning might change from one
-release to an another.
-.RE
-.IP "\fB\-fno\-keep\-inline\-dllexport\fR" 4
-.IX Item "-fno-keep-inline-dllexport"
-This is a more fine-grained version of \fB\-fkeep\-inline\-functions\fR,
-which applies only to functions that are declared using the \f(CW\*(C`dllexport\*(C'\fR
-attribute or declspec
-.IP "\fB\-fkeep\-inline\-functions\fR" 4
-.IX Item "-fkeep-inline-functions"
-In C, emit \f(CW\*(C`static\*(C'\fR functions that are declared \f(CW\*(C`inline\*(C'\fR
-into the object file, even if the function has been inlined into all
-of its callers. This switch does not affect functions using the
-\&\f(CW\*(C`extern inline\*(C'\fR extension in \s-1GNU\s0 C90. In \*(C+, emit any and all
-inline functions into the object file.
-.IP "\fB\-fkeep\-static\-consts\fR" 4
-.IX Item "-fkeep-static-consts"
-Emit variables declared \f(CW\*(C`static const\*(C'\fR when optimization isn't turned
-on, even if the variables aren't referenced.
-.Sp
-\&\s-1GCC\s0 enables this option by default. If you want to force the compiler to
-check if the variable was referenced, regardless of whether or not
-optimization is turned on, use the \fB\-fno\-keep\-static\-consts\fR option.
-.IP "\fB\-fmerge\-constants\fR" 4
-.IX Item "-fmerge-constants"
-Attempt to merge identical constants (string constants and floating point
-constants) across compilation units.
-.Sp
-This option is the default for optimized compilation if the assembler and
-linker support it. Use \fB\-fno\-merge\-constants\fR to inhibit this
-behavior.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fmerge\-all\-constants\fR" 4
-.IX Item "-fmerge-all-constants"
-Attempt to merge identical constants and identical variables.
-.Sp
-This option implies \fB\-fmerge\-constants\fR. In addition to
-\&\fB\-fmerge\-constants\fR this considers e.g. even constant initialized
-arrays or initialized constant variables with integral or floating point
-types. Languages like C or \*(C+ require each variable, including multiple
-instances of the same variable in recursive calls, to have distinct locations,
-so using this option will result in non-conforming
-behavior.
-.IP "\fB\-fmodulo\-sched\fR" 4
-.IX Item "-fmodulo-sched"
-Perform swing modulo scheduling immediately before the first scheduling
-pass. This pass looks at innermost loops and reorders their
-instructions by overlapping different iterations.
-.IP "\fB\-fmodulo\-sched\-allow\-regmoves\fR" 4
-.IX Item "-fmodulo-sched-allow-regmoves"
-Perform more aggressive \s-1SMS\s0 based modulo scheduling with register moves
-allowed. By setting this flag certain anti-dependences edges will be
-deleted which will trigger the generation of reg-moves based on the
-life-range analysis. This option is effective only with
-\&\fB\-fmodulo\-sched\fR enabled.
-.IP "\fB\-fno\-branch\-count\-reg\fR" 4
-.IX Item "-fno-branch-count-reg"
-Do not use \*(L"decrement and branch\*(R" instructions on a count register,
-but instead generate a sequence of instructions that decrement a
-register, compare it against zero, then branch based upon the result.
-This option is only meaningful on architectures that support such
-instructions, which include x86, PowerPC, \s-1IA\-64\s0 and S/390.
-.Sp
-The default is \fB\-fbranch\-count\-reg\fR.
-.IP "\fB\-fno\-function\-cse\fR" 4
-.IX Item "-fno-function-cse"
-Do not put function addresses in registers; make each instruction that
-calls a constant function contain the function's address explicitly.
-.Sp
-This option results in less efficient code, but some strange hacks
-that alter the assembler output may be confused by the optimizations
-performed when this option is not used.
-.Sp
-The default is \fB\-ffunction\-cse\fR
-.IP "\fB\-fno\-zero\-initialized\-in\-bss\fR" 4
-.IX Item "-fno-zero-initialized-in-bss"
-If the target supports a \s-1BSS\s0 section, \s-1GCC\s0 by default puts variables that
-are initialized to zero into \s-1BSS\s0. This can save space in the resulting
-code.
-.Sp
-This option turns off this behavior because some programs explicitly
-rely on variables going to the data section. E.g., so that the
-resulting executable can find the beginning of that section and/or make
-assumptions based on that.
-.Sp
-The default is \fB\-fzero\-initialized\-in\-bss\fR.
-.IP "\fB\-fmudflap \-fmudflapth \-fmudflapir\fR" 4
-.IX Item "-fmudflap -fmudflapth -fmudflapir"
-For front-ends that support it (C and \*(C+), instrument all risky
-pointer/array dereferencing operations, some standard library
-string/heap functions, and some other associated constructs with
-range/validity tests. Modules so instrumented should be immune to
-buffer overflows, invalid heap use, and some other classes of C/\*(C+
-programming errors. The instrumentation relies on a separate runtime
-library (\fIlibmudflap\fR), which will be linked into a program if
-\&\fB\-fmudflap\fR is given at link time. Run-time behavior of the
-instrumented program is controlled by the \fB\s-1MUDFLAP_OPTIONS\s0\fR
-environment variable. See \f(CW\*(C`env MUDFLAP_OPTIONS=\-help a.out\*(C'\fR
-for its options.
-.Sp
-Use \fB\-fmudflapth\fR instead of \fB\-fmudflap\fR to compile and to
-link if your program is multi-threaded. Use \fB\-fmudflapir\fR, in
-addition to \fB\-fmudflap\fR or \fB\-fmudflapth\fR, if
-instrumentation should ignore pointer reads. This produces less
-instrumentation (and therefore faster execution) and still provides
-some protection against outright memory corrupting writes, but allows
-erroneously read data to propagate within a program.
-.IP "\fB\-fthread\-jumps\fR" 4
-.IX Item "-fthread-jumps"
-Perform optimizations where we check to see if a jump branches to a
-location where another comparison subsumed by the first is found. If
-so, the first branch is redirected to either the destination of the
-second branch or a point immediately following it, depending on whether
-the condition is known to be true or false.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fsplit\-wide\-types\fR" 4
-.IX Item "-fsplit-wide-types"
-When using a type that occupies multiple registers, such as \f(CW\*(C`long
-long\*(C'\fR on a 32\-bit system, split the registers apart and allocate them
-independently. This normally generates better code for those types,
-but may make debugging more difficult.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR,
-\&\fB\-Os\fR.
-.IP "\fB\-fcse\-follow\-jumps\fR" 4
-.IX Item "-fcse-follow-jumps"
-In common subexpression elimination (\s-1CSE\s0), scan through jump instructions
-when the target of the jump is not reached by any other path. For
-example, when \s-1CSE\s0 encounters an \f(CW\*(C`if\*(C'\fR statement with an
-\&\f(CW\*(C`else\*(C'\fR clause, \s-1CSE\s0 will follow the jump when the condition
-tested is false.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fcse\-skip\-blocks\fR" 4
-.IX Item "-fcse-skip-blocks"
-This is similar to \fB\-fcse\-follow\-jumps\fR, but causes \s-1CSE\s0 to
-follow jumps which conditionally skip over blocks. When \s-1CSE\s0
-encounters a simple \f(CW\*(C`if\*(C'\fR statement with no else clause,
-\&\fB\-fcse\-skip\-blocks\fR causes \s-1CSE\s0 to follow the jump around the
-body of the \f(CW\*(C`if\*(C'\fR.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-frerun\-cse\-after\-loop\fR" 4
-.IX Item "-frerun-cse-after-loop"
-Re-run common subexpression elimination after loop optimizations has been
-performed.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fgcse\fR" 4
-.IX Item "-fgcse"
-Perform a global common subexpression elimination pass.
-This pass also performs global constant and copy propagation.
-.Sp
-\&\fINote:\fR When compiling a program using computed gotos, a \s-1GCC\s0
-extension, you may get better runtime performance if you disable
-the global common subexpression elimination pass by adding
-\&\fB\-fno\-gcse\fR to the command line.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fgcse\-lm\fR" 4
-.IX Item "-fgcse-lm"
-When \fB\-fgcse\-lm\fR is enabled, global common subexpression elimination will
-attempt to move loads which are only killed by stores into themselves. This
-allows a loop containing a load/store sequence to be changed to a load outside
-the loop, and a copy/store within the loop.
-.Sp
-Enabled by default when gcse is enabled.
-.IP "\fB\-fgcse\-sm\fR" 4
-.IX Item "-fgcse-sm"
-When \fB\-fgcse\-sm\fR is enabled, a store motion pass is run after
-global common subexpression elimination. This pass will attempt to move
-stores out of loops. When used in conjunction with \fB\-fgcse\-lm\fR,
-loops containing a load/store sequence can be changed to a load before
-the loop and a store after the loop.
-.Sp
-Not enabled at any optimization level.
-.IP "\fB\-fgcse\-las\fR" 4
-.IX Item "-fgcse-las"
-When \fB\-fgcse\-las\fR is enabled, the global common subexpression
-elimination pass eliminates redundant loads that come after stores to the
-same memory location (both partial and full redundancies).
-.Sp
-Not enabled at any optimization level.
-.IP "\fB\-fgcse\-after\-reload\fR" 4
-.IX Item "-fgcse-after-reload"
-When \fB\-fgcse\-after\-reload\fR is enabled, a redundant load elimination
-pass is performed after reload. The purpose of this pass is to cleanup
-redundant spilling.
-.IP "\fB\-funsafe\-loop\-optimizations\fR" 4
-.IX Item "-funsafe-loop-optimizations"
-If given, the loop optimizer will assume that loop indices do not
-overflow, and that the loops with nontrivial exit condition are not
-infinite. This enables a wider range of loop optimizations even if
-the loop optimizer itself cannot prove that these assumptions are valid.
-Using \fB\-Wunsafe\-loop\-optimizations\fR, the compiler will warn you
-if it finds this kind of loop.
-.IP "\fB\-fcrossjumping\fR" 4
-.IX Item "-fcrossjumping"
-Perform cross-jumping transformation. This transformation unifies equivalent code and save code size. The
-resulting code may or may not perform better than without cross-jumping.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fauto\-inc\-dec\fR" 4
-.IX Item "-fauto-inc-dec"
-Combine increments or decrements of addresses with memory accesses.
-This pass is always skipped on architectures that do not have
-instructions to support this. Enabled by default at \fB\-O\fR and
-higher on architectures that support this.
-.IP "\fB\-fdce\fR" 4
-.IX Item "-fdce"
-Perform dead code elimination (\s-1DCE\s0) on \s-1RTL\s0.
-Enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-fdse\fR" 4
-.IX Item "-fdse"
-Perform dead store elimination (\s-1DSE\s0) on \s-1RTL\s0.
-Enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-fif\-conversion\fR" 4
-.IX Item "-fif-conversion"
-Attempt to transform conditional jumps into branch-less equivalents. This
-include use of conditional moves, min, max, set flags and abs instructions, and
-some tricks doable by standard arithmetics. The use of conditional execution
-on chips where it is available is controlled by \f(CW\*(C`if\-conversion2\*(C'\fR.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fif\-conversion2\fR" 4
-.IX Item "-fif-conversion2"
-Use conditional execution (where available) to transform conditional jumps into
-branch-less equivalents.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fdelete\-null\-pointer\-checks\fR" 4
-.IX Item "-fdelete-null-pointer-checks"
-Assume that programs cannot safely dereference null pointers, and that
-no code or data element resides there. This enables simple constant
-folding optimizations at all optimization levels. In addition, other
-optimization passes in \s-1GCC\s0 use this flag to control global dataflow
-analyses that eliminate useless checks for null pointers; these assume
-that if a pointer is checked after it has already been dereferenced,
-it cannot be null.
-.Sp
-Note however that in some environments this assumption is not true.
-Use \fB\-fno\-delete\-null\-pointer\-checks\fR to disable this optimization
-for programs which depend on that behavior.
-.Sp
-Some targets, especially embedded ones, disable this option at all levels.
-Otherwise it is enabled at all levels: \fB\-O0\fR, \fB\-O1\fR,
-\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR. Passes that use the information
-are enabled independently at different optimization levels.
-.IP "\fB\-fdevirtualize\fR" 4
-.IX Item "-fdevirtualize"
-Attempt to convert calls to virtual functions to direct calls. This
-is done both within a procedure and interprocedurally as part of
-indirect inlining (\f(CW\*(C`\-findirect\-inlining\*(C'\fR) and interprocedural constant
-propagation (\fB\-fipa\-cp\fR).
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fexpensive\-optimizations\fR" 4
-.IX Item "-fexpensive-optimizations"
-Perform a number of minor optimizations that are relatively expensive.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-foptimize\-register\-move\fR" 4
-.IX Item "-foptimize-register-move"
-.PD 0
-.IP "\fB\-fregmove\fR" 4
-.IX Item "-fregmove"
-.PD
-Attempt to reassign register numbers in move instructions and as
-operands of other simple instructions in order to maximize the amount of
-register tying. This is especially helpful on machines with two-operand
-instructions.
-.Sp
-Note \fB\-fregmove\fR and \fB\-foptimize\-register\-move\fR are the same
-optimization.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fira\-algorithm=\fR\fIalgorithm\fR" 4
-.IX Item "-fira-algorithm=algorithm"
-Use specified coloring algorithm for the integrated register
-allocator. The \fIalgorithm\fR argument should be \f(CW\*(C`priority\*(C'\fR or
-\&\f(CW\*(C`CB\*(C'\fR. The first algorithm specifies Chow's priority coloring,
-the second one specifies Chaitin-Briggs coloring. The second
-algorithm can be unimplemented for some architectures. If it is
-implemented, it is the default because Chaitin-Briggs coloring as a
-rule generates a better code.
-.IP "\fB\-fira\-region=\fR\fIregion\fR" 4
-.IX Item "-fira-region=region"
-Use specified regions for the integrated register allocator. The
-\&\fIregion\fR argument should be one of \f(CW\*(C`all\*(C'\fR, \f(CW\*(C`mixed\*(C'\fR, or
-\&\f(CW\*(C`one\*(C'\fR. The first value means using all loops as register
-allocation regions, the second value which is the default means using
-all loops except for loops with small register pressure as the
-regions, and third one means using all function as a single region.
-The first value can give best result for machines with small size and
-irregular register set, the third one results in faster and generates
-decent code and the smallest size code, and the default value usually
-give the best results in most cases and for most architectures.
-.IP "\fB\-fira\-loop\-pressure\fR" 4
-.IX Item "-fira-loop-pressure"
-Use \s-1IRA\s0 to evaluate register pressure in loops for decision to move
-loop invariants. Usage of this option usually results in generation
-of faster and smaller code on machines with big register files (>= 32
-registers) but it can slow compiler down.
-.Sp
-This option is enabled at level \fB\-O3\fR for some targets.
-.IP "\fB\-fno\-ira\-share\-save\-slots\fR" 4
-.IX Item "-fno-ira-share-save-slots"
-Switch off sharing stack slots used for saving call used hard
-registers living through a call. Each hard register will get a
-separate stack slot and as a result function stack frame will be
-bigger.
-.IP "\fB\-fno\-ira\-share\-spill\-slots\fR" 4
-.IX Item "-fno-ira-share-spill-slots"
-Switch off sharing stack slots allocated for pseudo-registers. Each
-pseudo-register which did not get a hard register will get a separate
-stack slot and as a result function stack frame will be bigger.
-.IP "\fB\-fira\-verbose=\fR\fIn\fR" 4
-.IX Item "-fira-verbose=n"
-Set up how verbose dump file for the integrated register allocator
-will be. Default value is 5. If the value is greater or equal to 10,
-the dump file will be stderr as if the value were \fIn\fR minus 10.
-.IP "\fB\-fdelayed\-branch\fR" 4
-.IX Item "-fdelayed-branch"
-If supported for the target machine, attempt to reorder instructions
-to exploit instruction slots available after delayed branch
-instructions.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fschedule\-insns\fR" 4
-.IX Item "-fschedule-insns"
-If supported for the target machine, attempt to reorder instructions to
-eliminate execution stalls due to required data being unavailable. This
-helps machines that have slow floating point or memory load instructions
-by allowing other instructions to be issued until the result of the load
-or floating point instruction is required.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-fschedule\-insns2\fR" 4
-.IX Item "-fschedule-insns2"
-Similar to \fB\-fschedule\-insns\fR, but requests an additional pass of
-instruction scheduling after register allocation has been done. This is
-especially useful on machines with a relatively small number of
-registers and where memory load instructions take more than one cycle.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fno\-sched\-interblock\fR" 4
-.IX Item "-fno-sched-interblock"
-Don't schedule instructions across basic blocks. This is normally
-enabled by default when scheduling before register allocation, i.e.
-with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fno\-sched\-spec\fR" 4
-.IX Item "-fno-sched-spec"
-Don't allow speculative motion of non-load instructions. This is normally
-enabled by default when scheduling before register allocation, i.e.
-with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-pressure\fR" 4
-.IX Item "-fsched-pressure"
-Enable register pressure sensitive insn scheduling before the register
-allocation. This only makes sense when scheduling before register
-allocation is enabled, i.e. with \fB\-fschedule\-insns\fR or at
-\&\fB\-O2\fR or higher. Usage of this option can improve the
-generated code and decrease its size by preventing register pressure
-increase above the number of available hard registers and as a
-consequence register spills in the register allocation.
-.IP "\fB\-fsched\-spec\-load\fR" 4
-.IX Item "-fsched-spec-load"
-Allow speculative motion of some load instructions. This only makes
-sense when scheduling before register allocation, i.e. with
-\&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-spec\-load\-dangerous\fR" 4
-.IX Item "-fsched-spec-load-dangerous"
-Allow speculative motion of more load instructions. This only makes
-sense when scheduling before register allocation, i.e. with
-\&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-stalled\-insns\fR" 4
-.IX Item "-fsched-stalled-insns"
-.PD 0
-.IP "\fB\-fsched\-stalled\-insns=\fR\fIn\fR" 4
-.IX Item "-fsched-stalled-insns=n"
-.PD
-Define how many insns (if any) can be moved prematurely from the queue
-of stalled insns into the ready list, during the second scheduling pass.
-\&\fB\-fno\-sched\-stalled\-insns\fR means that no insns will be moved
-prematurely, \fB\-fsched\-stalled\-insns=0\fR means there is no limit
-on how many queued insns can be moved prematurely.
-\&\fB\-fsched\-stalled\-insns\fR without a value is equivalent to
-\&\fB\-fsched\-stalled\-insns=1\fR.
-.IP "\fB\-fsched\-stalled\-insns\-dep\fR" 4
-.IX Item "-fsched-stalled-insns-dep"
-.PD 0
-.IP "\fB\-fsched\-stalled\-insns\-dep=\fR\fIn\fR" 4
-.IX Item "-fsched-stalled-insns-dep=n"
-.PD
-Define how many insn groups (cycles) will be examined for a dependency
-on a stalled insn that is candidate for premature removal from the queue
-of stalled insns. This has an effect only during the second scheduling pass,
-and only if \fB\-fsched\-stalled\-insns\fR is used.
-\&\fB\-fno\-sched\-stalled\-insns\-dep\fR is equivalent to
-\&\fB\-fsched\-stalled\-insns\-dep=0\fR.
-\&\fB\-fsched\-stalled\-insns\-dep\fR without a value is equivalent to
-\&\fB\-fsched\-stalled\-insns\-dep=1\fR.
-.IP "\fB\-fsched2\-use\-superblocks\fR" 4
-.IX Item "-fsched2-use-superblocks"
-When scheduling after register allocation, do use superblock scheduling
-algorithm. Superblock scheduling allows motion across basic block boundaries
-resulting on faster schedules. This option is experimental, as not all machine
-descriptions used by \s-1GCC\s0 model the \s-1CPU\s0 closely enough to avoid unreliable
-results from the algorithm.
-.Sp
-This only makes sense when scheduling after register allocation, i.e. with
-\&\fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-group\-heuristic\fR" 4
-.IX Item "-fsched-group-heuristic"
-Enable the group heuristic in the scheduler. This heuristic favors
-the instruction that belongs to a schedule group. This is enabled
-by default when scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
-or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-critical\-path\-heuristic\fR" 4
-.IX Item "-fsched-critical-path-heuristic"
-Enable the critical-path heuristic in the scheduler. This heuristic favors
-instructions on the critical path. This is enabled by default when
-scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
-or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-spec\-insn\-heuristic\fR" 4
-.IX Item "-fsched-spec-insn-heuristic"
-Enable the speculative instruction heuristic in the scheduler. This
-heuristic favors speculative instructions with greater dependency weakness.
-This is enabled by default when scheduling is enabled, i.e.
-with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR
-or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-rank\-heuristic\fR" 4
-.IX Item "-fsched-rank-heuristic"
-Enable the rank heuristic in the scheduler. This heuristic favors
-the instruction belonging to a basic block with greater size or frequency.
-This is enabled by default when scheduling is enabled, i.e.
-with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
-at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-last\-insn\-heuristic\fR" 4
-.IX Item "-fsched-last-insn-heuristic"
-Enable the last-instruction heuristic in the scheduler. This heuristic
-favors the instruction that is less dependent on the last instruction
-scheduled. This is enabled by default when scheduling is enabled,
-i.e. with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
-at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-dep\-count\-heuristic\fR" 4
-.IX Item "-fsched-dep-count-heuristic"
-Enable the dependent-count heuristic in the scheduler. This heuristic
-favors the instruction that has more instructions depending on it.
-This is enabled by default when scheduling is enabled, i.e.
-with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
-at \fB\-O2\fR or higher.
-.IP "\fB\-freschedule\-modulo\-scheduled\-loops\fR" 4
-.IX Item "-freschedule-modulo-scheduled-loops"
-The modulo scheduling comes before the traditional scheduling, if a loop
-was modulo scheduled we may want to prevent the later scheduling passes
-from changing its schedule, we use this option to control that.
-.IP "\fB\-fselective\-scheduling\fR" 4
-.IX Item "-fselective-scheduling"
-Schedule instructions using selective scheduling algorithm. Selective
-scheduling runs instead of the first scheduler pass.
-.IP "\fB\-fselective\-scheduling2\fR" 4
-.IX Item "-fselective-scheduling2"
-Schedule instructions using selective scheduling algorithm. Selective
-scheduling runs instead of the second scheduler pass.
-.IP "\fB\-fsel\-sched\-pipelining\fR" 4
-.IX Item "-fsel-sched-pipelining"
-Enable software pipelining of innermost loops during selective scheduling.
-This option has no effect until one of \fB\-fselective\-scheduling\fR or
-\&\fB\-fselective\-scheduling2\fR is turned on.
-.IP "\fB\-fsel\-sched\-pipelining\-outer\-loops\fR" 4
-.IX Item "-fsel-sched-pipelining-outer-loops"
-When pipelining loops during selective scheduling, also pipeline outer loops.
-This option has no effect until \fB\-fsel\-sched\-pipelining\fR is turned on.
-.IP "\fB\-fcaller\-saves\fR" 4
-.IX Item "-fcaller-saves"
-Enable values to be allocated in registers that will be clobbered by
-function calls, by emitting extra instructions to save and restore the
-registers around such calls. Such allocation is done only when it
-seems to result in better code than would otherwise be produced.
-.Sp
-This option is always enabled by default on certain machines, usually
-those which have no call-preserved registers to use instead.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fcombine\-stack\-adjustments\fR" 4
-.IX Item "-fcombine-stack-adjustments"
-Tracks stack adjustments (pushes and pops) and stack memory references
-and then tries to find ways to combine them.
-.Sp
-Enabled by default at \fB\-O1\fR and higher.
-.IP "\fB\-fconserve\-stack\fR" 4
-.IX Item "-fconserve-stack"
-Attempt to minimize stack usage. The compiler will attempt to use less
-stack space, even if that makes the program slower. This option
-implies setting the \fBlarge-stack-frame\fR parameter to 100
-and the \fBlarge-stack-frame-growth\fR parameter to 400.
-.IP "\fB\-ftree\-reassoc\fR" 4
-.IX Item "-ftree-reassoc"
-Perform reassociation on trees. This flag is enabled by default
-at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-pre\fR" 4
-.IX Item "-ftree-pre"
-Perform partial redundancy elimination (\s-1PRE\s0) on trees. This flag is
-enabled by default at \fB\-O2\fR and \fB\-O3\fR.
-.IP "\fB\-ftree\-forwprop\fR" 4
-.IX Item "-ftree-forwprop"
-Perform forward propagation on trees. This flag is enabled by default
-at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-fre\fR" 4
-.IX Item "-ftree-fre"
-Perform full redundancy elimination (\s-1FRE\s0) on trees. The difference
-between \s-1FRE\s0 and \s-1PRE\s0 is that \s-1FRE\s0 only considers expressions
-that are computed on all paths leading to the redundant computation.
-This analysis is faster than \s-1PRE\s0, though it exposes fewer redundancies.
-This flag is enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-phiprop\fR" 4
-.IX Item "-ftree-phiprop"
-Perform hoisting of loads from conditional pointers on trees. This
-pass is enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-copy\-prop\fR" 4
-.IX Item "-ftree-copy-prop"
-Perform copy propagation on trees. This pass eliminates unnecessary
-copy operations. This flag is enabled by default at \fB\-O\fR and
-higher.
-.IP "\fB\-fipa\-pure\-const\fR" 4
-.IX Item "-fipa-pure-const"
-Discover which functions are pure or constant.
-Enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-fipa\-reference\fR" 4
-.IX Item "-fipa-reference"
-Discover which static variables do not escape cannot escape the
-compilation unit.
-Enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-fipa\-struct\-reorg\fR" 4
-.IX Item "-fipa-struct-reorg"
-Perform structure reorganization optimization, that change C\-like structures
-layout in order to better utilize spatial locality. This transformation is
-affective for programs containing arrays of structures. Available in two
-compilation modes: profile-based (enabled with \fB\-fprofile\-generate\fR)
-or static (which uses built-in heuristics). It works only in whole program
-mode, so it requires \fB\-fwhole\-program\fR to be
-enabled. Structures considered \fBcold\fR by this transformation are not
-affected (see \fB\-\-param struct\-reorg\-cold\-struct\-ratio=\fR\fIvalue\fR).
-.Sp
-With this flag, the program debug info reflects a new structure layout.
-.IP "\fB\-fipa\-pta\fR" 4
-.IX Item "-fipa-pta"
-Perform interprocedural pointer analysis and interprocedural modification
-and reference analysis. This option can cause excessive memory and
-compile-time usage on large compilation units. It is not enabled by
-default at any optimization level.
-.IP "\fB\-fipa\-profile\fR" 4
-.IX Item "-fipa-profile"
-Perform interprocedural profile propagation. The functions called only from
-cold functions are marked as cold. Also functions executed once (such as
-\&\f(CW\*(C`cold\*(C'\fR, \f(CW\*(C`noreturn\*(C'\fR, static constructors or destructors) are identified. Cold
-functions and loop less parts of functions executed once are then optimized for
-size.
-Enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-fipa\-cp\fR" 4
-.IX Item "-fipa-cp"
-Perform interprocedural constant propagation.
-This optimization analyzes the program to determine when values passed
-to functions are constants and then optimizes accordingly.
-This optimization can substantially increase performance
-if the application has constants passed to functions.
-This flag is enabled by default at \fB\-O2\fR, \fB\-Os\fR and \fB\-O3\fR.
-.IP "\fB\-fipa\-cp\-clone\fR" 4
-.IX Item "-fipa-cp-clone"
-Perform function cloning to make interprocedural constant propagation stronger.
-When enabled, interprocedural constant propagation will perform function cloning
-when externally visible function can be called with constant arguments.
-Because this optimization can create multiple copies of functions,
-it may significantly increase code size
-(see \fB\-\-param ipcp\-unit\-growth=\fR\fIvalue\fR).
-This flag is enabled by default at \fB\-O3\fR.
-.IP "\fB\-fipa\-matrix\-reorg\fR" 4
-.IX Item "-fipa-matrix-reorg"
-Perform matrix flattening and transposing.
-Matrix flattening tries to replace an m\-dimensional matrix
-with its equivalent n\-dimensional matrix, where n < m.
-This reduces the level of indirection needed for accessing the elements
-of the matrix. The second optimization is matrix transposing that
-attempts to change the order of the matrix's dimensions in order to
-improve cache locality.
-Both optimizations need the \fB\-fwhole\-program\fR flag.
-Transposing is enabled only if profiling information is available.
-.IP "\fB\-ftree\-sink\fR" 4
-.IX Item "-ftree-sink"
-Perform forward store motion on trees. This flag is
-enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-bit\-ccp\fR" 4
-.IX Item "-ftree-bit-ccp"
-Perform sparse conditional bit constant propagation on trees and propagate
-pointer alignment information.
-This pass only operates on local scalar variables and is enabled by default
-at \fB\-O\fR and higher. It requires that \fB\-ftree\-ccp\fR is enabled.
-.IP "\fB\-ftree\-ccp\fR" 4
-.IX Item "-ftree-ccp"
-Perform sparse conditional constant propagation (\s-1CCP\s0) on trees. This
-pass only operates on local scalar variables and is enabled by default
-at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-switch\-conversion\fR" 4
-.IX Item "-ftree-switch-conversion"
-Perform conversion of simple initializations in a switch to
-initializations from a scalar array. This flag is enabled by default
-at \fB\-O2\fR and higher.
-.IP "\fB\-ftree\-dce\fR" 4
-.IX Item "-ftree-dce"
-Perform dead code elimination (\s-1DCE\s0) on trees. This flag is enabled by
-default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-builtin\-call\-dce\fR" 4
-.IX Item "-ftree-builtin-call-dce"
-Perform conditional dead code elimination (\s-1DCE\s0) for calls to builtin functions
-that may set \f(CW\*(C`errno\*(C'\fR but are otherwise side-effect free. This flag is
-enabled by default at \fB\-O2\fR and higher if \fB\-Os\fR is not also
-specified.
-.IP "\fB\-ftree\-dominator\-opts\fR" 4
-.IX Item "-ftree-dominator-opts"
-Perform a variety of simple scalar cleanups (constant/copy
-propagation, redundancy elimination, range propagation and expression
-simplification) based on a dominator tree traversal. This also
-performs jump threading (to reduce jumps to jumps). This flag is
-enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-dse\fR" 4
-.IX Item "-ftree-dse"
-Perform dead store elimination (\s-1DSE\s0) on trees. A dead store is a store into
-a memory location which will later be overwritten by another store without
-any intervening loads. In this case the earlier store can be deleted. This
-flag is enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-ch\fR" 4
-.IX Item "-ftree-ch"
-Perform loop header copying on trees. This is beneficial since it increases
-effectiveness of code motion optimizations. It also saves one jump. This flag
-is enabled by default at \fB\-O\fR and higher. It is not enabled
-for \fB\-Os\fR, since it usually increases code size.
-.IP "\fB\-ftree\-loop\-optimize\fR" 4
-.IX Item "-ftree-loop-optimize"
-Perform loop optimizations on trees. This flag is enabled by default
-at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-loop\-linear\fR" 4
-.IX Item "-ftree-loop-linear"
-Perform loop interchange transformations on tree. Same as
-\&\fB\-floop\-interchange\fR. To use this code transformation, \s-1GCC\s0 has
-to be configured with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to
-enable the Graphite loop transformation infrastructure.
-.IP "\fB\-floop\-interchange\fR" 4
-.IX Item "-floop-interchange"
-Perform loop interchange transformations on loops. Interchanging two
-nested loops switches the inner and outer loops. For example, given a
-loop like:
-.Sp
-.Vb 5
-\& DO J = 1, M
-\& DO I = 1, N
-\& A(J, I) = A(J, I) * C
-\& ENDDO
-\& ENDDO
-.Ve
-.Sp
-loop interchange will transform the loop as if the user had written:
-.Sp
-.Vb 5
-\& DO I = 1, N
-\& DO J = 1, M
-\& A(J, I) = A(J, I) * C
-\& ENDDO
-\& ENDDO
-.Ve
-.Sp
-which can be beneficial when \f(CW\*(C`N\*(C'\fR is larger than the caches,
-because in Fortran, the elements of an array are stored in memory
-contiguously by column, and the original loop iterates over rows,
-potentially creating at each access a cache miss. This optimization
-applies to all the languages supported by \s-1GCC\s0 and is not limited to
-Fortran. To use this code transformation, \s-1GCC\s0 has to be configured
-with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to enable the
-Graphite loop transformation infrastructure.
-.IP "\fB\-floop\-strip\-mine\fR" 4
-.IX Item "-floop-strip-mine"
-Perform loop strip mining transformations on loops. Strip mining
-splits a loop into two nested loops. The outer loop has strides
-equal to the strip size and the inner loop has strides of the
-original loop within a strip. The strip length can be changed
-using the \fBloop-block-tile-size\fR parameter. For example,
-given a loop like:
-.Sp
-.Vb 3
-\& DO I = 1, N
-\& A(I) = A(I) + C
-\& ENDDO
-.Ve
-.Sp
-loop strip mining will transform the loop as if the user had written:
-.Sp
-.Vb 5
-\& DO II = 1, N, 51
-\& DO I = II, min (II + 50, N)
-\& A(I) = A(I) + C
-\& ENDDO
-\& ENDDO
-.Ve
-.Sp
-This optimization applies to all the languages supported by \s-1GCC\s0 and is
-not limited to Fortran. To use this code transformation, \s-1GCC\s0 has to
-be configured with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to
-enable the Graphite loop transformation infrastructure.
-.IP "\fB\-floop\-block\fR" 4
-.IX Item "-floop-block"
-Perform loop blocking transformations on loops. Blocking strip mines
-each loop in the loop nest such that the memory accesses of the
-element loops fit inside caches. The strip length can be changed
-using the \fBloop-block-tile-size\fR parameter. For example, given
-a loop like:
-.Sp
-.Vb 5
-\& DO I = 1, N
-\& DO J = 1, M
-\& A(J, I) = B(I) + C(J)
-\& ENDDO
-\& ENDDO
-.Ve
-.Sp
-loop blocking will transform the loop as if the user had written:
-.Sp
-.Vb 9
-\& DO II = 1, N, 51
-\& DO JJ = 1, M, 51
-\& DO I = II, min (II + 50, N)
-\& DO J = JJ, min (JJ + 50, M)
-\& A(J, I) = B(I) + C(J)
-\& ENDDO
-\& ENDDO
-\& ENDDO
-\& ENDDO
-.Ve
-.Sp
-which can be beneficial when \f(CW\*(C`M\*(C'\fR is larger than the caches,
-because the innermost loop will iterate over a smaller amount of data
-that can be kept in the caches. This optimization applies to all the
-languages supported by \s-1GCC\s0 and is not limited to Fortran. To use this
-code transformation, \s-1GCC\s0 has to be configured with \fB\-\-with\-ppl\fR
-and \fB\-\-with\-cloog\fR to enable the Graphite loop transformation
-infrastructure.
-.IP "\fB\-fgraphite\-identity\fR" 4
-.IX Item "-fgraphite-identity"
-Enable the identity transformation for graphite. For every SCoP we generate
-the polyhedral representation and transform it back to gimple. Using
-\&\fB\-fgraphite\-identity\fR we can check the costs or benefits of the
-\&\s-1GIMPLE\s0 \-> \s-1GRAPHITE\s0 \-> \s-1GIMPLE\s0 transformation. Some minimal optimizations
-are also performed by the code generator CLooG, like index splitting and
-dead code elimination in loops.
-.IP "\fB\-floop\-flatten\fR" 4
-.IX Item "-floop-flatten"
-Removes the loop nesting structure: transforms the loop nest into a
-single loop. This transformation can be useful to vectorize all the
-levels of the loop nest.
-.IP "\fB\-floop\-parallelize\-all\fR" 4
-.IX Item "-floop-parallelize-all"
-Use the Graphite data dependence analysis to identify loops that can
-be parallelized. Parallelize all the loops that can be analyzed to
-not contain loop carried dependences without checking that it is
-profitable to parallelize the loops.
-.IP "\fB\-fcheck\-data\-deps\fR" 4
-.IX Item "-fcheck-data-deps"
-Compare the results of several data dependence analyzers. This option
-is used for debugging the data dependence analyzers.
-.IP "\fB\-ftree\-loop\-if\-convert\fR" 4
-.IX Item "-ftree-loop-if-convert"
-Attempt to transform conditional jumps in the innermost loops to
-branch-less equivalents. The intent is to remove control-flow from
-the innermost loops in order to improve the ability of the
-vectorization pass to handle these loops. This is enabled by default
-if vectorization is enabled.
-.IP "\fB\-ftree\-loop\-if\-convert\-stores\fR" 4
-.IX Item "-ftree-loop-if-convert-stores"
-Attempt to also if-convert conditional jumps containing memory writes.
-This transformation can be unsafe for multi-threaded programs as it
-transforms conditional memory writes into unconditional memory writes.
-For example,
-.Sp
-.Vb 3
-\& for (i = 0; i < N; i++)
-\& if (cond)
-\& A[i] = expr;
-.Ve
-.Sp
-would be transformed to
-.Sp
-.Vb 2
-\& for (i = 0; i < N; i++)
-\& A[i] = cond ? expr : A[i];
-.Ve
-.Sp
-potentially producing data races.
-.IP "\fB\-ftree\-loop\-distribution\fR" 4
-.IX Item "-ftree-loop-distribution"
-Perform loop distribution. This flag can improve cache performance on
-big loop bodies and allow further loop optimizations, like
-parallelization or vectorization, to take place. For example, the loop
-.Sp
-.Vb 4
-\& DO I = 1, N
-\& A(I) = B(I) + C
-\& D(I) = E(I) * F
-\& ENDDO
-.Ve
-.Sp
-is transformed to
-.Sp
-.Vb 6
-\& DO I = 1, N
-\& A(I) = B(I) + C
-\& ENDDO
-\& DO I = 1, N
-\& D(I) = E(I) * F
-\& ENDDO
-.Ve
-.IP "\fB\-ftree\-loop\-distribute\-patterns\fR" 4
-.IX Item "-ftree-loop-distribute-patterns"
-Perform loop distribution of patterns that can be code generated with
-calls to a library. This flag is enabled by default at \fB\-O3\fR.
-.Sp
-This pass distributes the initialization loops and generates a call to
-memset zero. For example, the loop
-.Sp
-.Vb 4
-\& DO I = 1, N
-\& A(I) = 0
-\& B(I) = A(I) + I
-\& ENDDO
-.Ve
-.Sp
-is transformed to
-.Sp
-.Vb 6
-\& DO I = 1, N
-\& A(I) = 0
-\& ENDDO
-\& DO I = 1, N
-\& B(I) = A(I) + I
-\& ENDDO
-.Ve
-.Sp
-and the initialization loop is transformed into a call to memset zero.
-.IP "\fB\-ftree\-loop\-im\fR" 4
-.IX Item "-ftree-loop-im"
-Perform loop invariant motion on trees. This pass moves only invariants that
-would be hard to handle at \s-1RTL\s0 level (function calls, operations that expand to
-nontrivial sequences of insns). With \fB\-funswitch\-loops\fR it also moves
-operands of conditions that are invariant out of the loop, so that we can use
-just trivial invariantness analysis in loop unswitching. The pass also includes
-store motion.
-.IP "\fB\-ftree\-loop\-ivcanon\fR" 4
-.IX Item "-ftree-loop-ivcanon"
-Create a canonical counter for number of iterations in the loop for that
-determining number of iterations requires complicated analysis. Later
-optimizations then may determine the number easily. Useful especially
-in connection with unrolling.
-.IP "\fB\-fivopts\fR" 4
-.IX Item "-fivopts"
-Perform induction variable optimizations (strength reduction, induction
-variable merging and induction variable elimination) on trees.
-.IP "\fB\-ftree\-parallelize\-loops=n\fR" 4
-.IX Item "-ftree-parallelize-loops=n"
-Parallelize loops, i.e., split their iteration space to run in n threads.
-This is only possible for loops whose iterations are independent
-and can be arbitrarily reordered. The optimization is only
-profitable on multiprocessor machines, for loops that are CPU-intensive,
-rather than constrained e.g. by memory bandwidth. This option
-implies \fB\-pthread\fR, and thus is only supported on targets
-that have support for \fB\-pthread\fR.
-.IP "\fB\-ftree\-pta\fR" 4
-.IX Item "-ftree-pta"
-Perform function-local points-to analysis on trees. This flag is
-enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-sra\fR" 4
-.IX Item "-ftree-sra"
-Perform scalar replacement of aggregates. This pass replaces structure
-references with scalars to prevent committing structures to memory too
-early. This flag is enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-copyrename\fR" 4
-.IX Item "-ftree-copyrename"
-Perform copy renaming on trees. This pass attempts to rename compiler
-temporaries to other variables at copy locations, usually resulting in
-variable names which more closely resemble the original variables. This flag
-is enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-ter\fR" 4
-.IX Item "-ftree-ter"
-Perform temporary expression replacement during the \s-1SSA\-\s0>normal phase. Single
-use/single def temporaries are replaced at their use location with their
-defining expression. This results in non-GIMPLE code, but gives the expanders
-much more complex trees to work on resulting in better \s-1RTL\s0 generation. This is
-enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-vectorize\fR" 4
-.IX Item "-ftree-vectorize"
-Perform loop vectorization on trees. This flag is enabled by default at
-\&\fB\-O3\fR.
-.IP "\fB\-ftree\-slp\-vectorize\fR" 4
-.IX Item "-ftree-slp-vectorize"
-Perform basic block vectorization on trees. This flag is enabled by default at
-\&\fB\-O3\fR and when \fB\-ftree\-vectorize\fR is enabled.
-.IP "\fB\-ftree\-vect\-loop\-version\fR" 4
-.IX Item "-ftree-vect-loop-version"
-Perform loop versioning when doing loop vectorization on trees. When a loop
-appears to be vectorizable except that data alignment or data dependence cannot
-be determined at compile time then vectorized and non-vectorized versions of
-the loop are generated along with runtime checks for alignment or dependence
-to control which version is executed. This option is enabled by default
-except at level \fB\-Os\fR where it is disabled.
-.IP "\fB\-fvect\-cost\-model\fR" 4
-.IX Item "-fvect-cost-model"
-Enable cost model for vectorization.
-.IP "\fB\-ftree\-vrp\fR" 4
-.IX Item "-ftree-vrp"
-Perform Value Range Propagation on trees. This is similar to the
-constant propagation pass, but instead of values, ranges of values are
-propagated. This allows the optimizers to remove unnecessary range
-checks like array bound checks and null pointer checks. This is
-enabled by default at \fB\-O2\fR and higher. Null pointer check
-elimination is only done if \fB\-fdelete\-null\-pointer\-checks\fR is
-enabled.
-.IP "\fB\-ftracer\fR" 4
-.IX Item "-ftracer"
-Perform tail duplication to enlarge superblock size. This transformation
-simplifies the control flow of the function allowing other optimizations to do
-better job.
-.IP "\fB\-funroll\-loops\fR" 4
-.IX Item "-funroll-loops"
-Unroll loops whose number of iterations can be determined at compile
-time or upon entry to the loop. \fB\-funroll\-loops\fR implies
-\&\fB\-frerun\-cse\-after\-loop\fR. This option makes code larger,
-and may or may not make it run faster.
-.IP "\fB\-funroll\-all\-loops\fR" 4
-.IX Item "-funroll-all-loops"
-Unroll all loops, even if their number of iterations is uncertain when
-the loop is entered. This usually makes programs run more slowly.
-\&\fB\-funroll\-all\-loops\fR implies the same options as
-\&\fB\-funroll\-loops\fR,
-.IP "\fB\-fsplit\-ivs\-in\-unroller\fR" 4
-.IX Item "-fsplit-ivs-in-unroller"
-Enables expressing of values of induction variables in later iterations
-of the unrolled loop using the value in the first iteration. This breaks
-long dependency chains, thus improving efficiency of the scheduling passes.
-.Sp
-Combination of \fB\-fweb\fR and \s-1CSE\s0 is often sufficient to obtain the
-same effect. However in cases the loop body is more complicated than
-a single basic block, this is not reliable. It also does not work at all
-on some of the architectures due to restrictions in the \s-1CSE\s0 pass.
-.Sp
-This optimization is enabled by default.
-.IP "\fB\-fvariable\-expansion\-in\-unroller\fR" 4
-.IX Item "-fvariable-expansion-in-unroller"
-With this option, the compiler will create multiple copies of some
-local variables when unrolling a loop which can result in superior code.
-.IP "\fB\-fpartial\-inlining\fR" 4
-.IX Item "-fpartial-inlining"
-Inline parts of functions. This option has any effect only
-when inlining itself is turned on by the \fB\-finline\-functions\fR
-or \fB\-finline\-small\-functions\fR options.
-.Sp
-Enabled at level \fB\-O2\fR.
-.IP "\fB\-fpredictive\-commoning\fR" 4
-.IX Item "-fpredictive-commoning"
-Perform predictive commoning optimization, i.e., reusing computations
-(especially memory loads and stores) performed in previous
-iterations of loops.
-.Sp
-This option is enabled at level \fB\-O3\fR.
-.IP "\fB\-fprefetch\-loop\-arrays\fR" 4
-.IX Item "-fprefetch-loop-arrays"
-If supported by the target machine, generate instructions to prefetch
-memory to improve the performance of loops that access large arrays.
-.Sp
-This option may generate better or worse code; results are highly
-dependent on the structure of loops within the source code.
-.Sp
-Disabled at level \fB\-Os\fR.
-.IP "\fB\-fno\-peephole\fR" 4
-.IX Item "-fno-peephole"
-.PD 0
-.IP "\fB\-fno\-peephole2\fR" 4
-.IX Item "-fno-peephole2"
-.PD
-Disable any machine-specific peephole optimizations. The difference
-between \fB\-fno\-peephole\fR and \fB\-fno\-peephole2\fR is in how they
-are implemented in the compiler; some targets use one, some use the
-other, a few use both.
-.Sp
-\&\fB\-fpeephole\fR is enabled by default.
-\&\fB\-fpeephole2\fR enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fno\-guess\-branch\-probability\fR" 4
-.IX Item "-fno-guess-branch-probability"
-Do not guess branch probabilities using heuristics.
-.Sp
-\&\s-1GCC\s0 will use heuristics to guess branch probabilities if they are
-not provided by profiling feedback (\fB\-fprofile\-arcs\fR). These
-heuristics are based on the control flow graph. If some branch probabilities
-are specified by \fB_\|_builtin_expect\fR, then the heuristics will be
-used to guess branch probabilities for the rest of the control flow graph,
-taking the \fB_\|_builtin_expect\fR info into account. The interactions
-between the heuristics and \fB_\|_builtin_expect\fR can be complex, and in
-some cases, it may be useful to disable the heuristics so that the effects
-of \fB_\|_builtin_expect\fR are easier to understand.
-.Sp
-The default is \fB\-fguess\-branch\-probability\fR at levels
-\&\fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-freorder\-blocks\fR" 4
-.IX Item "-freorder-blocks"
-Reorder basic blocks in the compiled function in order to reduce number of
-taken branches and improve code locality.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-freorder\-blocks\-and\-partition\fR" 4
-.IX Item "-freorder-blocks-and-partition"
-In addition to reordering basic blocks in the compiled function, in order
-to reduce number of taken branches, partitions hot and cold basic blocks
-into separate sections of the assembly and .o files, to improve
-paging and cache locality performance.
-.Sp
-This optimization is automatically turned off in the presence of
-exception handling, for linkonce sections, for functions with a user-defined
-section attribute and on any architecture that does not support named
-sections.
-.IP "\fB\-freorder\-functions\fR" 4
-.IX Item "-freorder-functions"
-Reorder functions in the object file in order to
-improve code locality. This is implemented by using special
-subsections \f(CW\*(C`.text.hot\*(C'\fR for most frequently executed functions and
-\&\f(CW\*(C`.text.unlikely\*(C'\fR for unlikely executed functions. Reordering is done by
-the linker so object file format must support named sections and linker must
-place them in a reasonable way.
-.Sp
-Also profile feedback must be available in to make this option effective. See
-\&\fB\-fprofile\-arcs\fR for details.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fstrict\-aliasing\fR" 4
-.IX Item "-fstrict-aliasing"
-Allow the compiler to assume the strictest aliasing rules applicable to
-the language being compiled. For C (and \*(C+), this activates
-optimizations based on the type of expressions. In particular, an
-object of one type is assumed never to reside at the same address as an
-object of a different type, unless the types are almost the same. For
-example, an \f(CW\*(C`unsigned int\*(C'\fR can alias an \f(CW\*(C`int\*(C'\fR, but not a
-\&\f(CW\*(C`void*\*(C'\fR or a \f(CW\*(C`double\*(C'\fR. A character type may alias any other
-type.
-.Sp
-Pay special attention to code like this:
-.Sp
-.Vb 4
-\& union a_union {
-\& int i;
-\& double d;
-\& };
-\&
-\& int f() {
-\& union a_union t;
-\& t.d = 3.0;
-\& return t.i;
-\& }
-.Ve
-.Sp
-The practice of reading from a different union member than the one most
-recently written to (called \*(L"type-punning\*(R") is common. Even with
-\&\fB\-fstrict\-aliasing\fR, type-punning is allowed, provided the memory
-is accessed through the union type. So, the code above will work as
-expected. However, this code might not:
-.Sp
-.Vb 7
-\& int f() {
-\& union a_union t;
-\& int* ip;
-\& t.d = 3.0;
-\& ip = &t.i;
-\& return *ip;
-\& }
-.Ve
-.Sp
-Similarly, access by taking the address, casting the resulting pointer
-and dereferencing the result has undefined behavior, even if the cast
-uses a union type, e.g.:
-.Sp
-.Vb 4
-\& int f() {
-\& double d = 3.0;
-\& return ((union a_union *) &d)\->i;
-\& }
-.Ve
-.Sp
-The \fB\-fstrict\-aliasing\fR option is enabled at levels
-\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fstrict\-overflow\fR" 4
-.IX Item "-fstrict-overflow"
-Allow the compiler to assume strict signed overflow rules, depending
-on the language being compiled. For C (and \*(C+) this means that
-overflow when doing arithmetic with signed numbers is undefined, which
-means that the compiler may assume that it will not happen. This
-permits various optimizations. For example, the compiler will assume
-that an expression like \f(CW\*(C`i + 10 > i\*(C'\fR will always be true for
-signed \f(CW\*(C`i\*(C'\fR. This assumption is only valid if signed overflow is
-undefined, as the expression is false if \f(CW\*(C`i + 10\*(C'\fR overflows when
-using twos complement arithmetic. When this option is in effect any
-attempt to determine whether an operation on signed numbers will
-overflow must be written carefully to not actually involve overflow.
-.Sp
-This option also allows the compiler to assume strict pointer
-semantics: given a pointer to an object, if adding an offset to that
-pointer does not produce a pointer to the same object, the addition is
-undefined. This permits the compiler to conclude that \f(CW\*(C`p + u >
-p\*(C'\fR is always true for a pointer \f(CW\*(C`p\*(C'\fR and unsigned integer
-\&\f(CW\*(C`u\*(C'\fR. This assumption is only valid because pointer wraparound is
-undefined, as the expression is false if \f(CW\*(C`p + u\*(C'\fR overflows using
-twos complement arithmetic.
-.Sp
-See also the \fB\-fwrapv\fR option. Using \fB\-fwrapv\fR means
-that integer signed overflow is fully defined: it wraps. When
-\&\fB\-fwrapv\fR is used, there is no difference between
-\&\fB\-fstrict\-overflow\fR and \fB\-fno\-strict\-overflow\fR for
-integers. With \fB\-fwrapv\fR certain types of overflow are
-permitted. For example, if the compiler gets an overflow when doing
-arithmetic on constants, the overflowed value can still be used with
-\&\fB\-fwrapv\fR, but not otherwise.
-.Sp
-The \fB\-fstrict\-overflow\fR option is enabled at levels
-\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-falign\-functions\fR" 4
-.IX Item "-falign-functions"
-.PD 0
-.IP "\fB\-falign\-functions=\fR\fIn\fR" 4
-.IX Item "-falign-functions=n"
-.PD
-Align the start of functions to the next power-of-two greater than
-\&\fIn\fR, skipping up to \fIn\fR bytes. For instance,
-\&\fB\-falign\-functions=32\fR aligns functions to the next 32\-byte
-boundary, but \fB\-falign\-functions=24\fR would align to the next
-32\-byte boundary only if this can be done by skipping 23 bytes or less.
-.Sp
-\&\fB\-fno\-align\-functions\fR and \fB\-falign\-functions=1\fR are
-equivalent and mean that functions will not be aligned.
-.Sp
-Some assemblers only support this flag when \fIn\fR is a power of two;
-in that case, it is rounded up.
-.Sp
-If \fIn\fR is not specified or is zero, use a machine-dependent default.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-falign\-labels\fR" 4
-.IX Item "-falign-labels"
-.PD 0
-.IP "\fB\-falign\-labels=\fR\fIn\fR" 4
-.IX Item "-falign-labels=n"
-.PD
-Align all branch targets to a power-of-two boundary, skipping up to
-\&\fIn\fR bytes like \fB\-falign\-functions\fR. This option can easily
-make code slower, because it must insert dummy operations for when the
-branch target is reached in the usual flow of the code.
-.Sp
-\&\fB\-fno\-align\-labels\fR and \fB\-falign\-labels=1\fR are
-equivalent and mean that labels will not be aligned.
-.Sp
-If \fB\-falign\-loops\fR or \fB\-falign\-jumps\fR are applicable and
-are greater than this value, then their values are used instead.
-.Sp
-If \fIn\fR is not specified or is zero, use a machine-dependent default
-which is very likely to be \fB1\fR, meaning no alignment.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-falign\-loops\fR" 4
-.IX Item "-falign-loops"
-.PD 0
-.IP "\fB\-falign\-loops=\fR\fIn\fR" 4
-.IX Item "-falign-loops=n"
-.PD
-Align loops to a power-of-two boundary, skipping up to \fIn\fR bytes
-like \fB\-falign\-functions\fR. The hope is that the loop will be
-executed many times, which will make up for any execution of the dummy
-operations.
-.Sp
-\&\fB\-fno\-align\-loops\fR and \fB\-falign\-loops=1\fR are
-equivalent and mean that loops will not be aligned.
-.Sp
-If \fIn\fR is not specified or is zero, use a machine-dependent default.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-falign\-jumps\fR" 4
-.IX Item "-falign-jumps"
-.PD 0
-.IP "\fB\-falign\-jumps=\fR\fIn\fR" 4
-.IX Item "-falign-jumps=n"
-.PD
-Align branch targets to a power-of-two boundary, for branch targets
-where the targets can only be reached by jumping, skipping up to \fIn\fR
-bytes like \fB\-falign\-functions\fR. In this case, no dummy operations
-need be executed.
-.Sp
-\&\fB\-fno\-align\-jumps\fR and \fB\-falign\-jumps=1\fR are
-equivalent and mean that loops will not be aligned.
-.Sp
-If \fIn\fR is not specified or is zero, use a machine-dependent default.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-funit\-at\-a\-time\fR" 4
-.IX Item "-funit-at-a-time"
-This option is left for compatibility reasons. \fB\-funit\-at\-a\-time\fR
-has no effect, while \fB\-fno\-unit\-at\-a\-time\fR implies
-\&\fB\-fno\-toplevel\-reorder\fR and \fB\-fno\-section\-anchors\fR.
-.Sp
-Enabled by default.
-.IP "\fB\-fno\-toplevel\-reorder\fR" 4
-.IX Item "-fno-toplevel-reorder"
-Do not reorder top-level functions, variables, and \f(CW\*(C`asm\*(C'\fR
-statements. Output them in the same order that they appear in the
-input file. When this option is used, unreferenced static variables
-will not be removed. This option is intended to support existing code
-which relies on a particular ordering. For new code, it is better to
-use attributes.
-.Sp
-Enabled at level \fB\-O0\fR. When disabled explicitly, it also imply
-\&\fB\-fno\-section\-anchors\fR that is otherwise enabled at \fB\-O0\fR on some
-targets.
-.IP "\fB\-fweb\fR" 4
-.IX Item "-fweb"
-Constructs webs as commonly used for register allocation purposes and assign
-each web individual pseudo register. This allows the register allocation pass
-to operate on pseudos directly, but also strengthens several other optimization
-passes, such as \s-1CSE\s0, loop optimizer and trivial dead code remover. It can,
-however, make debugging impossible, since variables will no longer stay in a
-\&\*(L"home register\*(R".
-.Sp
-Enabled by default with \fB\-funroll\-loops\fR.
-.IP "\fB\-fwhole\-program\fR" 4
-.IX Item "-fwhole-program"
-Assume that the current compilation unit represents the whole program being
-compiled. All public functions and variables with the exception of \f(CW\*(C`main\*(C'\fR
-and those merged by attribute \f(CW\*(C`externally_visible\*(C'\fR become static functions
-and in effect are optimized more aggressively by interprocedural optimizers. If \fBgold\fR is used as the linker plugin, \f(CW\*(C`externally_visible\*(C'\fR attributes are automatically added to functions (not variable yet due to a current \fBgold\fR issue) that are accessed outside of \s-1LTO\s0 objects according to resolution file produced by \fBgold\fR. For other linkers that cannot generate resolution file, explicit \f(CW\*(C`externally_visible\*(C'\fR attributes are still necessary.
-While this option is equivalent to proper use of the \f(CW\*(C`static\*(C'\fR keyword for
-programs consisting of a single file, in combination with option
-\&\fB\-flto\fR this flag can be used to
-compile many smaller scale programs since the functions and variables become
-local for the whole combined compilation unit, not for the single source file
-itself.
-.Sp
-This option implies \fB\-fwhole\-file\fR for Fortran programs.
-.IP "\fB\-flto[=\fR\fIn\fR\fB]\fR" 4
-.IX Item "-flto[=n]"
-This option runs the standard link-time optimizer. When invoked
-with source code, it generates \s-1GIMPLE\s0 (one of \s-1GCC\s0's internal
-representations) and writes it to special \s-1ELF\s0 sections in the object
-file. When the object files are linked together, all the function
-bodies are read from these \s-1ELF\s0 sections and instantiated as if they
-had been part of the same translation unit.
-.Sp
-To use the link-time optimizer, \fB\-flto\fR needs to be specified at
-compile time and during the final link. For example:
-.Sp
-.Vb 3
-\& gcc \-c \-O2 \-flto foo.c
-\& gcc \-c \-O2 \-flto bar.c
-\& gcc \-o myprog \-flto \-O2 foo.o bar.o
-.Ve
-.Sp
-The first two invocations to \s-1GCC\s0 save a bytecode representation
-of \s-1GIMPLE\s0 into special \s-1ELF\s0 sections inside \fIfoo.o\fR and
-\&\fIbar.o\fR. The final invocation reads the \s-1GIMPLE\s0 bytecode from
-\&\fIfoo.o\fR and \fIbar.o\fR, merges the two files into a single
-internal image, and compiles the result as usual. Since both
-\&\fIfoo.o\fR and \fIbar.o\fR are merged into a single image, this
-causes all the interprocedural analyses and optimizations in \s-1GCC\s0 to
-work across the two files as if they were a single one. This means,
-for example, that the inliner is able to inline functions in
-\&\fIbar.o\fR into functions in \fIfoo.o\fR and vice-versa.
-.Sp
-Another (simpler) way to enable link-time optimization is:
-.Sp
-.Vb 1
-\& gcc \-o myprog \-flto \-O2 foo.c bar.c
-.Ve
-.Sp
-The above generates bytecode for \fIfoo.c\fR and \fIbar.c\fR,
-merges them together into a single \s-1GIMPLE\s0 representation and optimizes
-them as usual to produce \fImyprog\fR.
-.Sp
-The only important thing to keep in mind is that to enable link-time
-optimizations the \fB\-flto\fR flag needs to be passed to both the
-compile and the link commands.
-.Sp
-To make whole program optimization effective, it is necessary to make
-certain whole program assumptions. The compiler needs to know
-what functions and variables can be accessed by libraries and runtime
-outside of the link-time optimized unit. When supported by the linker,
-the linker plugin (see \fB\-fuse\-linker\-plugin\fR) passes information
-to the compiler about used and externally visible symbols. When
-the linker plugin is not available, \fB\-fwhole\-program\fR should be
-used to allow the compiler to make these assumptions, which leads
-to more aggressive optimization decisions.
-.Sp
-Note that when a file is compiled with \fB\-flto\fR, the generated
-object file is larger than a regular object file because it
-contains \s-1GIMPLE\s0 bytecodes and the usual final code. This means that
-object files with \s-1LTO\s0 information can be linked as normal object
-files; if \fB\-flto\fR is not passed to the linker, no
-interprocedural optimizations are applied.
-.Sp
-Additionally, the optimization flags used to compile individual files
-are not necessarily related to those used at link time. For instance,
-.Sp
-.Vb 3
-\& gcc \-c \-O0 \-flto foo.c
-\& gcc \-c \-O0 \-flto bar.c
-\& gcc \-o myprog \-flto \-O3 foo.o bar.o
-.Ve
-.Sp
-This produces individual object files with unoptimized assembler
-code, but the resulting binary \fImyprog\fR is optimized at
-\&\fB\-O3\fR. If, instead, the final binary is generated without
-\&\fB\-flto\fR, then \fImyprog\fR is not optimized.
-.Sp
-When producing the final binary with \fB\-flto\fR, \s-1GCC\s0 only
-applies link-time optimizations to those files that contain bytecode.
-Therefore, you can mix and match object files and libraries with
-\&\s-1GIMPLE\s0 bytecodes and final object code. \s-1GCC\s0 automatically selects
-which files to optimize in \s-1LTO\s0 mode and which files to link without
-further processing.
-.Sp
-There are some code generation flags that \s-1GCC\s0 preserves when
-generating bytecodes, as they need to be used during the final link
-stage. Currently, the following options are saved into the \s-1GIMPLE\s0
-bytecode files: \fB\-fPIC\fR, \fB\-fcommon\fR and all the
-\&\fB\-m\fR target flags.
-.Sp
-At link time, these options are read in and reapplied. Note that the
-current implementation makes no attempt to recognize conflicting
-values for these options. If different files have conflicting option
-values (e.g., one file is compiled with \fB\-fPIC\fR and another
-isn't), the compiler simply uses the last value read from the
-bytecode files. It is recommended, then, that you compile all the files
-participating in the same link with the same options.
-.Sp
-If \s-1LTO\s0 encounters objects with C linkage declared with incompatible
-types in separate translation units to be linked together (undefined
-behavior according to \s-1ISO\s0 C99 6.2.7), a non-fatal diagnostic may be
-issued. The behavior is still undefined at runtime.
-.Sp
-Another feature of \s-1LTO\s0 is that it is possible to apply interprocedural
-optimizations on files written in different languages. This requires
-support in the language front end. Currently, the C, \*(C+ and
-Fortran front ends are capable of emitting \s-1GIMPLE\s0 bytecodes, so
-something like this should work:
-.Sp
-.Vb 4
-\& gcc \-c \-flto foo.c
-\& g++ \-c \-flto bar.cc
-\& gfortran \-c \-flto baz.f90
-\& g++ \-o myprog \-flto \-O3 foo.o bar.o baz.o \-lgfortran
-.Ve
-.Sp
-Notice that the final link is done with \fBg++\fR to get the \*(C+
-runtime libraries and \fB\-lgfortran\fR is added to get the Fortran
-runtime libraries. In general, when mixing languages in \s-1LTO\s0 mode, you
-should use the same link command options as when mixing languages in a
-regular (non-LTO) compilation; all you need to add is \fB\-flto\fR to
-all the compile and link commands.
-.Sp
-If object files containing \s-1GIMPLE\s0 bytecode are stored in a library archive, say
-\&\fIlibfoo.a\fR, it is possible to extract and use them in an \s-1LTO\s0 link if you
-are using a linker with plugin support. To enable this feature, use
-the flag \fB\-fuse\-linker\-plugin\fR at link time:
-.Sp
-.Vb 1
-\& gcc \-o myprog \-O2 \-flto \-fuse\-linker\-plugin a.o b.o \-lfoo
-.Ve
-.Sp
-With the linker plugin enabled, the linker extracts the needed
-\&\s-1GIMPLE\s0 files from \fIlibfoo.a\fR and passes them on to the running \s-1GCC\s0
-to make them part of the aggregated \s-1GIMPLE\s0 image to be optimized.
-.Sp
-If you are not using a linker with plugin support and/or do not
-enable the linker plugin, then the objects inside \fIlibfoo.a\fR
-are extracted and linked as usual, but they do not participate
-in the \s-1LTO\s0 optimization process.
-.Sp
-Link-time optimizations do not require the presence of the whole program to
-operate. If the program does not require any symbols to be exported, it is
-possible to combine \fB\-flto\fR and \fB\-fwhole\-program\fR to allow
-the interprocedural optimizers to use more aggressive assumptions which may
-lead to improved optimization opportunities.
-Use of \fB\-fwhole\-program\fR is not needed when linker plugin is
-active (see \fB\-fuse\-linker\-plugin\fR).
-.Sp
-The current implementation of \s-1LTO\s0 makes no
-attempt to generate bytecode that is portable between different
-types of hosts. The bytecode files are versioned and there is a
-strict version check, so bytecode files generated in one version of
-\&\s-1GCC\s0 will not work with an older/newer version of \s-1GCC\s0.
-.Sp
-Link-time optimization does not work well with generation of debugging
-information. Combining \fB\-flto\fR with
-\&\fB\-g\fR is currently experimental and expected to produce wrong
-results.
-.Sp
-If you specify the optional \fIn\fR, the optimization and code
-generation done at link time is executed in parallel using \fIn\fR
-parallel jobs by utilizing an installed \fBmake\fR program. The
-environment variable \fB\s-1MAKE\s0\fR may be used to override the program
-used. The default value for \fIn\fR is 1.
-.Sp
-You can also specify \fB\-flto=jobserver\fR to use \s-1GNU\s0 make's
-job server mode to determine the number of parallel jobs. This
-is useful when the Makefile calling \s-1GCC\s0 is already executing in parallel.
-You must prepend a \fB+\fR to the command recipe in the parent Makefile
-for this to work. This option likely only works if \fB\s-1MAKE\s0\fR is
-\&\s-1GNU\s0 make.
-.Sp
-This option is disabled by default.
-.IP "\fB\-flto\-partition=\fR\fIalg\fR" 4
-.IX Item "-flto-partition=alg"
-Specify the partitioning algorithm used by the link-time optimizer.
-The value is either \f(CW\*(C`1to1\*(C'\fR to specify a partitioning mirroring
-the original source files or \f(CW\*(C`balanced\*(C'\fR to specify partitioning
-into equally sized chunks (whenever possible). Specifying \f(CW\*(C`none\*(C'\fR
-as an algorithm disables partitioning and streaming completely. The
-default value is \f(CW\*(C`balanced\*(C'\fR.
-.IP "\fB\-flto\-compression\-level=\fR\fIn\fR" 4
-.IX Item "-flto-compression-level=n"
-This option specifies the level of compression used for intermediate
-language written to \s-1LTO\s0 object files, and is only meaningful in
-conjunction with \s-1LTO\s0 mode (\fB\-flto\fR). Valid
-values are 0 (no compression) to 9 (maximum compression). Values
-outside this range are clamped to either 0 or 9. If the option is not
-given, a default balanced compression setting is used.
-.IP "\fB\-flto\-report\fR" 4
-.IX Item "-flto-report"
-Prints a report with internal details on the workings of the link-time
-optimizer. The contents of this report vary from version to version.
-It is meant to be useful to \s-1GCC\s0 developers when processing object
-files in \s-1LTO\s0 mode (via \fB\-flto\fR).
-.Sp
-Disabled by default.
-.IP "\fB\-fuse\-linker\-plugin\fR" 4
-.IX Item "-fuse-linker-plugin"
-Enables the use of a linker plugin during link-time optimization. This
-option relies on the linker plugin support in linker that is available in gold
-or in \s-1GNU\s0 ld 2.21 or newer.
-.Sp
-This option enables the extraction of object files with \s-1GIMPLE\s0 bytecode out
-of library archives. This improves the quality of optimization by exposing
-more code to the link-time optimizer. This information specifies what
-symbols can be accessed externally (by non-LTO object or during dynamic
-linking). Resulting code quality improvements on binaries (and shared
-libraries that use hidden visibility) are similar to \f(CW\*(C`\-fwhole\-program\*(C'\fR.
-See \fB\-flto\fR for a description of the effect of this flag and how to
-use it.
-.Sp
-This option is enabled by default when \s-1LTO\s0 support in \s-1GCC\s0 is enabled
-and \s-1GCC\s0 was configured for use with
-a linker supporting plugins (\s-1GNU\s0 ld 2.21 or newer or gold).
-.IP "\fB\-fcompare\-elim\fR" 4
-.IX Item "-fcompare-elim"
-After register allocation and post-register allocation instruction splitting,
-identify arithmetic instructions that compute processor flags similar to a
-comparison operation based on that arithmetic. If possible, eliminate the
-explicit comparison operation.
-.Sp
-This pass only applies to certain targets that cannot explicitly represent
-the comparison operation before register allocation is complete.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fuse\-ld=gold\fR" 4
-.IX Item "-fuse-ld=gold"
-Use the \fBgold\fR linker instead of the default linker.
-This option is only necessary if \s-1GCC\s0 has been configured with
-\&\fB\-\-enable\-gold\fR and \fB\-\-enable\-ld=default\fR.
-.IP "\fB\-fuse\-ld=bfd\fR" 4
-.IX Item "-fuse-ld=bfd"
-Use the \fBld.bfd\fR linker instead of the default linker.
-This option is only necessary if \s-1GCC\s0 has been configured with
-\&\fB\-\-enable\-gold\fR and \fB\-\-enable\-ld\fR.
-.IP "\fB\-fcprop\-registers\fR" 4
-.IX Item "-fcprop-registers"
-After register allocation and post-register allocation instruction splitting,
-we perform a copy-propagation pass to try to reduce scheduling dependencies
-and occasionally eliminate the copy.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fprofile\-correction\fR" 4
-.IX Item "-fprofile-correction"
-Profiles collected using an instrumented binary for multi-threaded programs may
-be inconsistent due to missed counter updates. When this option is specified,
-\&\s-1GCC\s0 will use heuristics to correct or smooth out such inconsistencies. By
-default, \s-1GCC\s0 will emit an error message when an inconsistent profile is detected.
-.IP "\fB\-fprofile\-dir=\fR\fIpath\fR" 4
-.IX Item "-fprofile-dir=path"
-Set the directory to search for the profile data files in to \fIpath\fR.
-This option affects only the profile data generated by
-\&\fB\-fprofile\-generate\fR, \fB\-ftest\-coverage\fR, \fB\-fprofile\-arcs\fR
-and used by \fB\-fprofile\-use\fR and \fB\-fbranch\-probabilities\fR
-and its related options. Both absolute and relative paths can be used.
-By default, \s-1GCC\s0 will use the current directory as \fIpath\fR, thus the
-profile data file will appear in the same directory as the object file.
-.IP "\fB\-fprofile\-generate\fR" 4
-.IX Item "-fprofile-generate"
-.PD 0
-.IP "\fB\-fprofile\-generate=\fR\fIpath\fR" 4
-.IX Item "-fprofile-generate=path"
-.PD
-Enable options usually used for instrumenting application to produce
-profile useful for later recompilation with profile feedback based
-optimization. You must use \fB\-fprofile\-generate\fR both when
-compiling and when linking your program.
-.Sp
-The following options are enabled: \f(CW\*(C`\-fprofile\-arcs\*(C'\fR, \f(CW\*(C`\-fprofile\-values\*(C'\fR, \f(CW\*(C`\-fvpt\*(C'\fR.
-.Sp
-If \fIpath\fR is specified, \s-1GCC\s0 will look at the \fIpath\fR to find
-the profile feedback data files. See \fB\-fprofile\-dir\fR.
-.IP "\fB\-fprofile\-generate\-sampling\fR" 4
-.IX Item "-fprofile-generate-sampling"
-Enable sampling for instrumented binaries. Instead of recording every event,
-record only every N\-th event, where N (the sampling rate) can be set either
-at compile time using
-\&\fB\-\-param profile\-generate\-sampling\-rate=\fR\fIvalue\fR, or
-at execution start time through environment variable \fB\s-1GCOV_SAMPLING_RATE\s0\fR.
-.Sp
-At this time sampling applies only to branch counters. A sampling rate of 100
-decreases instrumentated binary slowdown from up to 20x for heavily threaded
-applications down to around 2x. \fB\-fprofile\-correction\fR is always
-needed with sampling.
-.IP "\fB\-fprofile\-use\fR" 4
-.IX Item "-fprofile-use"
-.PD 0
-.IP "\fB\-fprofile\-use=\fR\fIpath\fR" 4
-.IX Item "-fprofile-use=path"
-.PD
-Enable profile feedback directed optimizations, and optimizations
-generally profitable only with profile feedback available.
-.Sp
-The following options are enabled: \f(CW\*(C`\-fbranch\-probabilities\*(C'\fR, \f(CW\*(C`\-fvpt\*(C'\fR,
-\&\f(CW\*(C`\-funroll\-loops\*(C'\fR, \f(CW\*(C`\-fpeel\-loops\*(C'\fR.
-.Sp
-By default, \s-1GCC\s0 emits an error message if the feedback profiles do not
-match the source code. This error can be turned into a warning by using
-\&\fB\-Wcoverage\-mismatch\fR. Note this may result in poorly optimized
-code.
-.Sp
-If \fIpath\fR is specified, \s-1GCC\s0 will look at the \fIpath\fR to find
-the profile feedback data files. See \fB\-fprofile\-dir\fR.
-.IP "\fB\-fpmu\-profile\-generate=\fR\fIpmuoption\fR" 4
-.IX Item "-fpmu-profile-generate=pmuoption"
-Enable performance monitoring unit (\s-1PMU\s0) profiling. This collects
-hardware counter data corresponding to \fIpmuoption\fR. Currently
-only \fIload-latency\fR and \fIbranch-mispredict\fR are supported
-using pfmon tool. You must use \fB\-fpmu\-profile\-generate\fR both
-when compiling and when linking your program. This \s-1PMU\s0 profile data
-may later be used by the compiler during optimizations as well can be
-displayed using coverage tool gcov. The params variable
-\&\*(L"pmu_profile_n_addresses\*(R" can be used to restrict \s-1PMU\s0 data collection
-to only this many addresses.
-.IP "\fB\-fpmu\-profile\-use=\fR\fIpmuoption\fR" 4
-.IX Item "-fpmu-profile-use=pmuoption"
-Enable performance monitoring unit (\s-1PMU\s0) profiling based
-optimizations. Currently only \fIload-latency\fR and
-\&\fIbranch-mispredict\fR are supported.
-.IP "\fB\-fripa\fR" 4
-.IX Item "-fripa"
-Perform dynamic inter-procedural analysis. This is used in conjunction with
-the \fB\-fprofile\-generate\fR and \fB\-fprofile\-use\fR options.
-During the \fB\-fprofile\-generate\fR phase, this flag turns on some additional
-instrumentation code that enables dynamic call-graph analysis.
-During the \fB\-fprofile\-use\fR phase, this flag enables cross-module
-optimizations such as inlining.
-.IP "\fB\-fripa\-disallow\-asm\-modules\fR" 4
-.IX Item "-fripa-disallow-asm-modules"
-During profile-gen, if this flag is enabled, and the module has asm statements,
-arrange so that a bit recording this information will be set in the profile
-feedback data file.
-During profile-use, if this flag is enabled, and the same bit in auxiliary
-module's profile feedback data is set, don't import this auxiliary module.
-If this is the primary module, don't export it.
-.IP "\fB\-fripa\-disallow\-opt\-mismatch\fR" 4
-.IX Item "-fripa-disallow-opt-mismatch"
-Don't import an auxiliary module, if the \s-1GCC\s0 command line options used for this
-auxiliary module during the profile-generate stage were different from those used
-for the primary module. Note that any mismatches in warning-related options are
-ignored for this comparison.
-.IP "\fB\-fripa\-no\-promote\-always\-inline\-func\fR" 4
-.IX Item "-fripa-no-promote-always-inline-func"
-Do not promote static functions with always inline attribute in \s-1LIPO\s0 compilation.
-.IP "\fB\-fripa\-verbose\fR" 4
-.IX Item "-fripa-verbose"
-Enable printing of verbose information about dynamic inter-procedural optimizations.
-This is used in conjunction with the \fB\-fripa\fR.
-.IP "\fB\-fripa\-peel\-size\-limit\fR" 4
-.IX Item "-fripa-peel-size-limit"
-Limit loop peeling of non-const non-FP loops in a \s-1LIPO\s0 compilation under estimates
-of a large code footprint. Enabled by default under \fB\-fripa\fR. Code size
-estimation and thresholds are controlled by the \fBcodesize-hotness-threshold\fR
-and \fBunrollpeel-codesize-threshold\fR parameters.
-.IP "\fB\-fripa\-unroll\-size\-limit\fR" 4
-.IX Item "-fripa-unroll-size-limit"
-Limit loop unrolling of non-const non-FP loops in a \s-1LIPO\s0 compilation under estimates
-of a large code footprint. Enabled by default under \fB\-fripa\fR. Code size
-estimation and thresholds are controlled by the \fBcodesize-hotness-threshold\fR
-and \fBunrollpeel-codesize-threshold\fR parameters.
-.IP "\fB\-fcallgraph\-profiles\-sections\fR" 4
-.IX Item "-fcallgraph-profiles-sections"
-Emit call graph edge profile counts in .note.callgraph.text sections. This is
-used in conjunction with \fB\-fprofile\-use\fR. A new .note.callgraph.text
-section is created for each function. This section lists every callee and the
-number of times it is called. The params variable
-\&\*(L"note-cgraph-section-edge-threshold\*(R" can be used to only list edges above a
-certain threshold.
-.IP "\fB\-frecord\-gcc\-switches\-in\-elf\fR" 4
-.IX Item "-frecord-gcc-switches-in-elf"
-Record the command line options in the .gnu.switches.text elf section for sample
-based \s-1LIPO\s0 to do module grouping.
-.PP
-The following options control compiler behavior regarding floating
-point arithmetic. These options trade off between speed and
-correctness. All must be specifically enabled.
-.IP "\fB\-ffloat\-store\fR" 4
-.IX Item "-ffloat-store"
-Do not store floating point variables in registers, and inhibit other
-options that might change whether a floating point value is taken from a
-register or memory.
-.Sp
-This option prevents undesirable excess precision on machines such as
-the 68000 where the floating registers (of the 68881) keep more
-precision than a \f(CW\*(C`double\*(C'\fR is supposed to have. Similarly for the
-x86 architecture. For most programs, the excess precision does only
-good, but a few programs rely on the precise definition of \s-1IEEE\s0 floating
-point. Use \fB\-ffloat\-store\fR for such programs, after modifying
-them to store all pertinent intermediate computations into variables.
-.IP "\fB\-fexcess\-precision=\fR\fIstyle\fR" 4
-.IX Item "-fexcess-precision=style"
-This option allows further control over excess precision on machines
-where floating-point registers have more precision than the \s-1IEEE\s0
-\&\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR types and the processor does not
-support operations rounding to those types. By default,
-\&\fB\-fexcess\-precision=fast\fR is in effect; this means that
-operations are carried out in the precision of the registers and that
-it is unpredictable when rounding to the types specified in the source
-code takes place. When compiling C, if
-\&\fB\-fexcess\-precision=standard\fR is specified then excess
-precision will follow the rules specified in \s-1ISO\s0 C99; in particular,
-both casts and assignments cause values to be rounded to their
-semantic types (whereas \fB\-ffloat\-store\fR only affects
-assignments). This option is enabled by default for C if a strict
-conformance option such as \fB\-std=c99\fR is used.
-.Sp
-\&\fB\-fexcess\-precision=standard\fR is not implemented for languages
-other than C, and has no effect if
-\&\fB\-funsafe\-math\-optimizations\fR or \fB\-ffast\-math\fR is
-specified. On the x86, it also has no effect if \fB\-mfpmath=sse\fR
-or \fB\-mfpmath=sse+387\fR is specified; in the former case, \s-1IEEE\s0
-semantics apply without excess precision, and in the latter, rounding
-is unpredictable.
-.IP "\fB\-ffast\-math\fR" 4
-.IX Item "-ffast-math"
-Sets \fB\-fno\-math\-errno\fR, \fB\-funsafe\-math\-optimizations\fR,
-\&\fB\-ffinite\-math\-only\fR, \fB\-fno\-rounding\-math\fR,
-\&\fB\-fno\-signaling\-nans\fR and \fB\-fcx\-limited\-range\fR.
-.Sp
-This option causes the preprocessor macro \f(CW\*(C`_\|_FAST_MATH_\|_\*(C'\fR to be defined.
-.Sp
-This option is not turned on by any \fB\-O\fR option besides
-\&\fB\-Ofast\fR since it can result in incorrect output for programs
-which depend on an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications
-for math functions. It may, however, yield faster code for programs
-that do not require the guarantees of these specifications.
-.IP "\fB\-fno\-math\-errno\fR" 4
-.IX Item "-fno-math-errno"
-Do not set \s-1ERRNO\s0 after calling math functions that are executed
-with a single instruction, e.g., sqrt. A program that relies on
-\&\s-1IEEE\s0 exceptions for math error handling may want to use this flag
-for speed while maintaining \s-1IEEE\s0 arithmetic compatibility.
-.Sp
-This option is not turned on by any \fB\-O\fR option since
-it can result in incorrect output for programs which depend on
-an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
-math functions. It may, however, yield faster code for programs
-that do not require the guarantees of these specifications.
-.Sp
-The default is \fB\-fmath\-errno\fR.
-.Sp
-On Darwin systems, the math library never sets \f(CW\*(C`errno\*(C'\fR. There is
-therefore no reason for the compiler to consider the possibility that
-it might, and \fB\-fno\-math\-errno\fR is the default.
-.IP "\fB\-funsafe\-math\-optimizations\fR" 4
-.IX Item "-funsafe-math-optimizations"
-Allow optimizations for floating-point arithmetic that (a) assume
-that arguments and results are valid and (b) may violate \s-1IEEE\s0 or
-\&\s-1ANSI\s0 standards. When used at link-time, it may include libraries
-or startup files that change the default \s-1FPU\s0 control word or other
-similar optimizations.
-.Sp
-This option is not turned on by any \fB\-O\fR option since
-it can result in incorrect output for programs which depend on
-an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
-math functions. It may, however, yield faster code for programs
-that do not require the guarantees of these specifications.
-Enables \fB\-fno\-signed\-zeros\fR, \fB\-fno\-trapping\-math\fR,
-\&\fB\-fassociative\-math\fR and \fB\-freciprocal\-math\fR.
-.Sp
-The default is \fB\-fno\-unsafe\-math\-optimizations\fR.
-.IP "\fB\-fassociative\-math\fR" 4
-.IX Item "-fassociative-math"
-Allow re-association of operands in series of floating-point operations.
-This violates the \s-1ISO\s0 C and \*(C+ language standard by possibly changing
-computation result. \s-1NOTE:\s0 re-ordering may change the sign of zero as
-well as ignore NaNs and inhibit or create underflow or overflow (and
-thus cannot be used on a code which relies on rounding behavior like
-\&\f(CW\*(C`(x + 2**52) \- 2**52)\*(C'\fR. May also reorder floating-point comparisons
-and thus may not be used when ordered comparisons are required.
-This option requires that both \fB\-fno\-signed\-zeros\fR and
-\&\fB\-fno\-trapping\-math\fR be in effect. Moreover, it doesn't make
-much sense with \fB\-frounding\-math\fR. For Fortran the option
-is automatically enabled when both \fB\-fno\-signed\-zeros\fR and
-\&\fB\-fno\-trapping\-math\fR are in effect.
-.Sp
-The default is \fB\-fno\-associative\-math\fR.
-.IP "\fB\-freciprocal\-math\fR" 4
-.IX Item "-freciprocal-math"
-Allow the reciprocal of a value to be used instead of dividing by
-the value if this enables optimizations. For example \f(CW\*(C`x / y\*(C'\fR
-can be replaced with \f(CW\*(C`x * (1/y)\*(C'\fR which is useful if \f(CW\*(C`(1/y)\*(C'\fR
-is subject to common subexpression elimination. Note that this loses
-precision and increases the number of flops operating on the value.
-.Sp
-The default is \fB\-fno\-reciprocal\-math\fR.
-.IP "\fB\-ffinite\-math\-only\fR" 4
-.IX Item "-ffinite-math-only"
-Allow optimizations for floating-point arithmetic that assume
-that arguments and results are not NaNs or +\-Infs.
-.Sp
-This option is not turned on by any \fB\-O\fR option since
-it can result in incorrect output for programs which depend on
-an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
-math functions. It may, however, yield faster code for programs
-that do not require the guarantees of these specifications.
-.Sp
-The default is \fB\-fno\-finite\-math\-only\fR.
-.IP "\fB\-fno\-signed\-zeros\fR" 4
-.IX Item "-fno-signed-zeros"
-Allow optimizations for floating point arithmetic that ignore the
-signedness of zero. \s-1IEEE\s0 arithmetic specifies the behavior of
-distinct +0.0 and \-0.0 values, which then prohibits simplification
-of expressions such as x+0.0 or 0.0*x (even with \fB\-ffinite\-math\-only\fR).
-This option implies that the sign of a zero result isn't significant.
-.Sp
-The default is \fB\-fsigned\-zeros\fR.
-.IP "\fB\-fno\-trapping\-math\fR" 4
-.IX Item "-fno-trapping-math"
-Compile code assuming that floating-point operations cannot generate
-user-visible traps. These traps include division by zero, overflow,
-underflow, inexact result and invalid operation. This option requires
-that \fB\-fno\-signaling\-nans\fR be in effect. Setting this option may
-allow faster code if one relies on \*(L"non-stop\*(R" \s-1IEEE\s0 arithmetic, for example.
-.Sp
-This option should never be turned on by any \fB\-O\fR option since
-it can result in incorrect output for programs which depend on
-an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
-math functions.
-.Sp
-The default is \fB\-ftrapping\-math\fR.
-.IP "\fB\-frounding\-math\fR" 4
-.IX Item "-frounding-math"
-Disable transformations and optimizations that assume default floating
-point rounding behavior. This is round-to-zero for all floating point
-to integer conversions, and round-to-nearest for all other arithmetic
-truncations. This option should be specified for programs that change
-the \s-1FP\s0 rounding mode dynamically, or that may be executed with a
-non-default rounding mode. This option disables constant folding of
-floating point expressions at compile-time (which may be affected by
-rounding mode) and arithmetic transformations that are unsafe in the
-presence of sign-dependent rounding modes.
-.Sp
-The default is \fB\-fno\-rounding\-math\fR.
-.Sp
-This option is experimental and does not currently guarantee to
-disable all \s-1GCC\s0 optimizations that are affected by rounding mode.
-Future versions of \s-1GCC\s0 may provide finer control of this setting
-using C99's \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma. This command line option
-will be used to specify the default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
-.IP "\fB\-fsignaling\-nans\fR" 4
-.IX Item "-fsignaling-nans"
-Compile code assuming that \s-1IEEE\s0 signaling NaNs may generate user-visible
-traps during floating-point operations. Setting this option disables
-optimizations that may change the number of exceptions visible with
-signaling NaNs. This option implies \fB\-ftrapping\-math\fR.
-.Sp
-This option causes the preprocessor macro \f(CW\*(C`_\|_SUPPORT_SNAN_\|_\*(C'\fR to
-be defined.
-.Sp
-The default is \fB\-fno\-signaling\-nans\fR.
-.Sp
-This option is experimental and does not currently guarantee to
-disable all \s-1GCC\s0 optimizations that affect signaling NaN behavior.
-.IP "\fB\-fsingle\-precision\-constant\fR" 4
-.IX Item "-fsingle-precision-constant"
-Treat floating point constant as single precision constant instead of
-implicitly converting it to double precision constant.
-.IP "\fB\-fcx\-limited\-range\fR" 4
-.IX Item "-fcx-limited-range"
-When enabled, this option states that a range reduction step is not
-needed when performing complex division. Also, there is no checking
-whether the result of a complex multiplication or division is \f(CW\*(C`NaN
-+ I*NaN\*(C'\fR, with an attempt to rescue the situation in that case. The
-default is \fB\-fno\-cx\-limited\-range\fR, but is enabled by
-\&\fB\-ffast\-math\fR.
-.Sp
-This option controls the default setting of the \s-1ISO\s0 C99
-\&\f(CW\*(C`CX_LIMITED_RANGE\*(C'\fR pragma. Nevertheless, the option applies to
-all languages.
-.IP "\fB\-fcx\-fortran\-rules\fR" 4
-.IX Item "-fcx-fortran-rules"
-Complex multiplication and division follow Fortran rules. Range
-reduction is done as part of complex division, but there is no checking
-whether the result of a complex multiplication or division is \f(CW\*(C`NaN
-+ I*NaN\*(C'\fR, with an attempt to rescue the situation in that case.
-.Sp
-The default is \fB\-fno\-cx\-fortran\-rules\fR.
-.IP "\fBmin-mcf-cancel-iters\fR" 4
-.IX Item "min-mcf-cancel-iters"
-The minimum number of iterations of negative cycle cancellation during
-\&\s-1MCF\s0 profile correction before early termination. This parameter is
-only useful when using \fB\-fprofile\-correction\fR.
-.PP
-The following options control optimizations that may improve
-performance, but are not enabled by any \fB\-O\fR options. This
-section includes experimental options that may produce broken code.
-.IP "\fB\-fbranch\-probabilities\fR" 4
-.IX Item "-fbranch-probabilities"
-After running a program compiled with \fB\-fprofile\-arcs\fR, you can compile it a second time using
-\&\fB\-fbranch\-probabilities\fR, to improve optimizations based on
-the number of times each branch was taken. When the program
-compiled with \fB\-fprofile\-arcs\fR exits it saves arc execution
-counts to a file called \fI\fIsourcename\fI.gcda\fR for each source
-file. The information in this data file is very dependent on the
-structure of the generated code, so you must use the same source code
-and the same optimization options for both compilations.
-.Sp
-With \fB\-fbranch\-probabilities\fR, \s-1GCC\s0 puts a
-\&\fB\s-1REG_BR_PROB\s0\fR note on each \fB\s-1JUMP_INSN\s0\fR and \fB\s-1CALL_INSN\s0\fR.
-These can be used to improve optimization. Currently, they are only
-used in one place: in \fIreorg.c\fR, instead of guessing which path a
-branch is most likely to take, the \fB\s-1REG_BR_PROB\s0\fR values are used to
-exactly determine which path is taken more often.
-.IP "\fB\-fclone\-hot\-version\-paths\fR" 4
-.IX Item "-fclone-hot-version-paths"
-When multi-version calls are made using \fB_\|_builtin_dispatch\fR, this flag
-enables cloning and hoisting of hot multiversioned paths.
-.IP "\fB\-fprofile\-values\fR" 4
-.IX Item "-fprofile-values"
-If combined with \fB\-fprofile\-arcs\fR, it adds code so that some
-data about values of expressions in the program is gathered.
-.Sp
-With \fB\-fbranch\-probabilities\fR, it reads back the data gathered
-from profiling values of expressions for usage in optimizations.
-.Sp
-Enabled with \fB\-fprofile\-generate\fR and \fB\-fprofile\-use\fR.
-.IP "\fB\-fvpt\fR" 4
-.IX Item "-fvpt"
-If combined with \fB\-fprofile\-arcs\fR, it instructs the compiler to add
-a code to gather information about values of expressions.
-.Sp
-With \fB\-fbranch\-probabilities\fR, it reads back the data gathered
-and actually performs the optimizations based on them.
-Currently the optimizations include specialization of division operation
-using the knowledge about the value of the denominator.
-.IP "\fB\-frename\-registers\fR" 4
-.IX Item "-frename-registers"
-Attempt to avoid false dependencies in scheduled code by making use
-of registers left over after register allocation. This optimization
-will most benefit processors with lots of registers. Depending on the
-debug information format adopted by the target, however, it can
-make debugging impossible, since variables will no longer stay in
-a \*(L"home register\*(R".
-.Sp
-Enabled by default with \fB\-funroll\-loops\fR and \fB\-fpeel\-loops\fR.
-.IP "\fB\-ftracer\fR" 4
-.IX Item "-ftracer"
-Perform tail duplication to enlarge superblock size. This transformation
-simplifies the control flow of the function allowing other optimizations to do
-better job.
-.Sp
-Enabled with \fB\-fprofile\-use\fR.
-.IP "\fB\-funroll\-loops\fR" 4
-.IX Item "-funroll-loops"
-Unroll loops whose number of iterations can be determined at compile time or
-upon entry to the loop. \fB\-funroll\-loops\fR implies
-\&\fB\-frerun\-cse\-after\-loop\fR, \fB\-fweb\fR and \fB\-frename\-registers\fR.
-It also turns on complete loop peeling (i.e. complete removal of loops with
-small constant number of iterations). This option makes code larger, and may
-or may not make it run faster.
-.Sp
-Enabled with \fB\-fprofile\-use\fR.
-.IP "\fB\-funroll\-all\-loops\fR" 4
-.IX Item "-funroll-all-loops"
-Unroll all loops, even if their number of iterations is uncertain when
-the loop is entered. This usually makes programs run more slowly.
-\&\fB\-funroll\-all\-loops\fR implies the same options as
-\&\fB\-funroll\-loops\fR.
-.IP "\fB\-fpeel\-loops\fR" 4
-.IX Item "-fpeel-loops"
-Peels the loops for that there is enough information that they do not
-roll much (from profile feedback). It also turns on complete loop peeling
-(i.e. complete removal of loops with small constant number of iterations).
-.Sp
-Enabled with \fB\-fprofile\-use\fR.
-.IP "\fB\-fmove\-loop\-invariants\fR" 4
-.IX Item "-fmove-loop-invariants"
-Enables the loop invariant motion pass in the \s-1RTL\s0 loop optimizer. Enabled
-at level \fB\-O1\fR
-.IP "\fB\-funswitch\-loops\fR" 4
-.IX Item "-funswitch-loops"
-Move branches with loop invariant conditions out of the loop, with duplicates
-of the loop on both branches (modified according to result of the condition).
-.IP "\fB\-ffunction\-sections\fR" 4
-.IX Item "-ffunction-sections"
-.PD 0
-.IP "\fB\-fdata\-sections\fR" 4
-.IX Item "-fdata-sections"
-.PD
-Place each function or data item into its own section in the output
-file if the target supports arbitrary sections. The name of the
-function or the name of the data item determines the section's name
-in the output file.
-.Sp
-Use these options on systems where the linker can perform optimizations
-to improve locality of reference in the instruction space. Most systems
-using the \s-1ELF\s0 object format and \s-1SPARC\s0 processors running Solaris 2 have
-linkers with such optimizations. \s-1AIX\s0 may have these optimizations in
-the future.
-.Sp
-Only use these options when there are significant benefits from doing
-so. When you specify these options, the assembler and linker will
-create larger object and executable files and will also be slower.
-You will not be able to use \f(CW\*(C`gprof\*(C'\fR on all systems if you
-specify this option and you may have problems with debugging if
-you specify both this option and \fB\-g\fR.
-.IP "\fB\-fbranch\-target\-load\-optimize\fR" 4
-.IX Item "-fbranch-target-load-optimize"
-Perform branch target register load optimization before prologue / epilogue
-threading.
-The use of target registers can typically be exposed only during reload,
-thus hoisting loads out of loops and doing inter-block scheduling needs
-a separate optimization pass.
-.IP "\fB\-fbranch\-target\-load\-optimize2\fR" 4
-.IX Item "-fbranch-target-load-optimize2"
-Perform branch target register load optimization after prologue / epilogue
-threading.
-.IP "\fB\-fbtr\-bb\-exclusive\fR" 4
-.IX Item "-fbtr-bb-exclusive"
-When performing branch target register load optimization, don't reuse
-branch target registers in within any basic block.
-.IP "\fB\-fstack\-protector\fR" 4
-.IX Item "-fstack-protector"
-Emit extra code to check for buffer overflows, such as stack smashing
-attacks. This is done by adding a guard variable to functions with
-vulnerable objects. This includes functions that call alloca, and
-functions with buffers larger than 8 bytes. The guards are initialized
-when a function is entered and then checked when the function exits.
-If a guard check fails, an error message is printed and the program exits.
-.IP "\fB\-fstack\-protector\-all\fR" 4
-.IX Item "-fstack-protector-all"
-Like \fB\-fstack\-protector\fR except that all functions are protected.
-.IP "\fB\-fstack\-protector\-strong\fR" 4
-.IX Item "-fstack-protector-strong"
-Like \fB\-fstack\-protector\fR but includes additional functions to be
-protected \- those that have local array definitions, or have references to
-local frame addresses.
-.IP "\fB\-fsection\-anchors\fR" 4
-.IX Item "-fsection-anchors"
-Try to reduce the number of symbolic address calculations by using
-shared \*(L"anchor\*(R" symbols to address nearby objects. This transformation
-can help to reduce the number of \s-1GOT\s0 entries and \s-1GOT\s0 accesses on some
-targets.
-.Sp
-For example, the implementation of the following function \f(CW\*(C`foo\*(C'\fR:
-.Sp
-.Vb 2
-\& static int a, b, c;
-\& int foo (void) { return a + b + c; }
-.Ve
-.Sp
-would usually calculate the addresses of all three variables, but if you
-compile it with \fB\-fsection\-anchors\fR, it will access the variables
-from a common anchor point instead. The effect is similar to the
-following pseudocode (which isn't valid C):
-.Sp
-.Vb 5
-\& int foo (void)
-\& {
-\& register int *xr = &x;
-\& return xr[&a \- &x] + xr[&b \- &x] + xr[&c \- &x];
-\& }
-.Ve
-.Sp
-Not all targets support this option.
-.IP "\fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR" 4
-.IX Item "--param name=value"
-In some places, \s-1GCC\s0 uses various constants to control the amount of
-optimization that is done. For example, \s-1GCC\s0 will not inline functions
-that contain more that a certain number of instructions. You can
-control some of these constants on the command-line using the
-\&\fB\-\-param\fR option.
-.Sp
-The names of specific parameters, and the meaning of the values, are
-tied to the internals of the compiler, and are subject to change
-without notice in future releases.
-.Sp
-In each case, the \fIvalue\fR is an integer. The allowable choices for
-\&\fIname\fR are given in the following table:
-.RS 4
-.IP "\fBstruct-reorg-cold-struct-ratio\fR" 4
-.IX Item "struct-reorg-cold-struct-ratio"
-The threshold ratio (as a percentage) between a structure frequency
-and the frequency of the hottest structure in the program. This parameter
-is used by struct-reorg optimization enabled by \fB\-fipa\-struct\-reorg\fR.
-We say that if the ratio of a structure frequency, calculated by profiling,
-to the hottest structure frequency in the program is less than this
-parameter, then structure reorganization is not applied to this structure.
-The default is 10.
-.IP "\fBpredictable-branch-outcome\fR" 4
-.IX Item "predictable-branch-outcome"
-When branch is predicted to be taken with probability lower than this threshold
-(in percent), then it is considered well predictable. The default is 10.
-.IP "\fBmax-crossjump-edges\fR" 4
-.IX Item "max-crossjump-edges"
-The maximum number of incoming edges to consider for crossjumping.
-The algorithm used by \fB\-fcrossjumping\fR is O(N^2) in
-the number of edges incoming to each block. Increasing values mean
-more aggressive optimization, making the compile time increase with
-probably small improvement in executable size.
-.IP "\fBmin-crossjump-insns\fR" 4
-.IX Item "min-crossjump-insns"
-The minimum number of instructions which must be matched at the end
-of two blocks before crossjumping will be performed on them. This
-value is ignored in the case where all instructions in the block being
-crossjumped from are matched. The default value is 5.
-.IP "\fBmax-grow-copy-bb-insns\fR" 4
-.IX Item "max-grow-copy-bb-insns"
-The maximum code size expansion factor when copying basic blocks
-instead of jumping. The expansion is relative to a jump instruction.
-The default value is 8.
-.IP "\fBmax-goto-duplication-insns\fR" 4
-.IX Item "max-goto-duplication-insns"
-The maximum number of instructions to duplicate to a block that jumps
-to a computed goto. To avoid O(N^2) behavior in a number of
-passes, \s-1GCC\s0 factors computed gotos early in the compilation process,
-and unfactors them as late as possible. Only computed jumps at the
-end of a basic blocks with no more than max-goto-duplication-insns are
-unfactored. The default value is 8.
-.IP "\fBmax-delay-slot-insn-search\fR" 4
-.IX Item "max-delay-slot-insn-search"
-The maximum number of instructions to consider when looking for an
-instruction to fill a delay slot. If more than this arbitrary number of
-instructions is searched, the time savings from filling the delay slot
-will be minimal so stop searching. Increasing values mean more
-aggressive optimization, making the compile time increase with probably
-small improvement in executable run time.
-.IP "\fBmax-delay-slot-live-search\fR" 4
-.IX Item "max-delay-slot-live-search"
-When trying to fill delay slots, the maximum number of instructions to
-consider when searching for a block with valid live register
-information. Increasing this arbitrarily chosen value means more
-aggressive optimization, increasing the compile time. This parameter
-should be removed when the delay slot code is rewritten to maintain the
-control-flow graph.
-.IP "\fBmax-gcse-memory\fR" 4
-.IX Item "max-gcse-memory"
-The approximate maximum amount of memory that will be allocated in
-order to perform the global common subexpression elimination
-optimization. If more memory than specified is required, the
-optimization will not be done.
-.IP "\fBmax-gcse-insertion-ratio\fR" 4
-.IX Item "max-gcse-insertion-ratio"
-If the ratio of expression insertions to deletions is larger than this value
-for any expression, then \s-1RTL\s0 \s-1PRE\s0 will insert or remove the expression and thus
-leave partially redundant computations in the instruction stream. The default value is 20.
-.IP "\fBmax-pending-list-length\fR" 4
-.IX Item "max-pending-list-length"
-The maximum number of pending dependencies scheduling will allow
-before flushing the current state and starting over. Large functions
-with few branches or calls can create excessively large lists which
-needlessly consume memory and resources.
-.IP "\fBmax-inline-insns-single\fR" 4
-.IX Item "max-inline-insns-single"
-Several parameters control the tree inliner used in gcc.
-This number sets the maximum number of instructions (counted in \s-1GCC\s0's
-internal representation) in a single function that the tree inliner
-will consider for inlining. This only affects functions declared
-inline and methods implemented in a class declaration (\*(C+).
-The default value is 400.
-.IP "\fBmax-inline-insns-auto\fR" 4
-.IX Item "max-inline-insns-auto"
-When you use \fB\-finline\-functions\fR (included in \fB\-O3\fR),
-a lot of functions that would otherwise not be considered for inlining
-by the compiler will be investigated. To those functions, a different
-(more restrictive) limit compared to functions declared inline can
-be applied.
-The default value is 40.
-.IP "\fBmversn-clone-depth\fR" 4
-.IX Item "mversn-clone-depth"
-When using \fB\-fclone\-hot\-version\-paths\fR, hot function paths are multi\-
-versioned via cloning. This parameter specifies the maximum length of the
-call graph path that can be cloned. The default value is 2.
-.IP "\fBnum-mversn-clones\fR" 4
-.IX Item "num-mversn-clones"
-When using \fB\-fclone\-hot\-version\-paths\fR, hot function paths are multi\-
-versioned via cloning. This parameter specifies the maximum number of
-functions that can be cloned. The default value is 10.
-.IP "\fBlarge-function-insns\fR" 4
-.IX Item "large-function-insns"
-The limit specifying really large functions. For functions larger than this
-limit after inlining, inlining is constrained by
-\&\fB\-\-param large-function-growth\fR. This parameter is useful primarily
-to avoid extreme compilation time caused by non-linear algorithms used by the
-backend.
-The default value is 2700.
-.IP "\fBlarge-function-growth\fR" 4
-.IX Item "large-function-growth"
-Specifies maximal growth of large function caused by inlining in percents.
-The default value is 100 which limits large function growth to 2.0 times
-the original size.
-.IP "\fBlarge-unit-insns\fR" 4
-.IX Item "large-unit-insns"
-The limit specifying large translation unit. Growth caused by inlining of
-units larger than this limit is limited by \fB\-\-param inline-unit-growth\fR.
-For small units this might be too tight (consider unit consisting of function A
-that is inline and B that just calls A three time. If B is small relative to
-A, the growth of unit is 300\e% and yet such inlining is very sane. For very
-large units consisting of small inlineable functions however the overall unit
-growth limit is needed to avoid exponential explosion of code size. Thus for
-smaller units, the size is increased to \fB\-\-param large-unit-insns\fR
-before applying \fB\-\-param inline-unit-growth\fR. The default is 10000
-.IP "\fBinline-unit-growth\fR" 4
-.IX Item "inline-unit-growth"
-Specifies maximal overall growth of the compilation unit caused by inlining.
-The default value is 30 which limits unit growth to 1.3 times the original
-size.
-.IP "\fBipcp-unit-growth\fR" 4
-.IX Item "ipcp-unit-growth"
-Specifies maximal overall growth of the compilation unit caused by
-interprocedural constant propagation. The default value is 10 which limits
-unit growth to 1.1 times the original size.
-.IP "\fBlarge-stack-frame\fR" 4
-.IX Item "large-stack-frame"
-The limit specifying large stack frames. While inlining the algorithm is trying
-to not grow past this limit too much. Default value is 256 bytes.
-.IP "\fBlarge-stack-frame-growth\fR" 4
-.IX Item "large-stack-frame-growth"
-Specifies maximal growth of large stack frames caused by inlining in percents.
-The default value is 1000 which limits large stack frame growth to 11 times
-the original size.
-.IP "\fBmax-inline-insns-recursive\fR" 4
-.IX Item "max-inline-insns-recursive"
-.PD 0
-.IP "\fBmax-inline-insns-recursive-auto\fR" 4
-.IX Item "max-inline-insns-recursive-auto"
-.PD
-Specifies maximum number of instructions out-of-line copy of self recursive inline
-function can grow into by performing recursive inlining.
-.Sp
-For functions declared inline \fB\-\-param max-inline-insns-recursive\fR is
-taken into account. For function not declared inline, recursive inlining
-happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
-enabled and \fB\-\-param max-inline-insns-recursive-auto\fR is used. The
-default value is 450.
-.IP "\fBmax-inline-recursive-depth\fR" 4
-.IX Item "max-inline-recursive-depth"
-.PD 0
-.IP "\fBmax-inline-recursive-depth-auto\fR" 4
-.IX Item "max-inline-recursive-depth-auto"
-.PD
-Specifies maximum recursion depth used by the recursive inlining.
-.Sp
-For functions declared inline \fB\-\-param max-inline-recursive-depth\fR is
-taken into account. For function not declared inline, recursive inlining
-happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
-enabled and \fB\-\-param max-inline-recursive-depth-auto\fR is used. The
-default value is 8.
-.IP "\fBmin-inline-recursive-probability\fR" 4
-.IX Item "min-inline-recursive-probability"
-Recursive inlining is profitable only for function having deep recursion
-in average and can hurt for function having little recursion depth by
-increasing the prologue size or complexity of function body to other
-optimizers.
-.Sp
-When profile feedback is available (see \fB\-fprofile\-generate\fR) the actual
-recursion depth can be guessed from probability that function will recurse via
-given call expression. This parameter limits inlining only to call expression
-whose probability exceeds given threshold (in percents). The default value is
-10.
-.IP "\fBearly-inlining-insns\fR" 4
-.IX Item "early-inlining-insns"
-Specify growth that early inliner can make. In effect it increases amount of
-inlining for code having large abstraction penalty. The default value is 10.
-.IP "\fBmax-early-inliner-iterations\fR" 4
-.IX Item "max-early-inliner-iterations"
-.PD 0
-.IP "\fBmax-early-inliner-iterations\fR" 4
-.IX Item "max-early-inliner-iterations"
-.PD
-Limit of iterations of early inliner. This basically bounds number of nested
-indirect calls early inliner can resolve. Deeper chains are still handled by
-late inlining.
-.IP "\fBcomdat-sharing-probability\fR" 4
-.IX Item "comdat-sharing-probability"
-.PD 0
-.IP "\fBcomdat-sharing-probability\fR" 4
-.IX Item "comdat-sharing-probability"
-.PD
-Probability (in percent) that \*(C+ inline function with comdat visibility
-will be shared across multiple compilation units. The default value is 20.
-.IP "\fBmin-vect-loop-bound\fR" 4
-.IX Item "min-vect-loop-bound"
-The minimum number of iterations under which a loop will not get vectorized
-when \fB\-ftree\-vectorize\fR is used. The number of iterations after
-vectorization needs to be greater than the value specified by this option
-to allow vectorization. The default value is 0.
-.IP "\fBgcse-cost-distance-ratio\fR" 4
-.IX Item "gcse-cost-distance-ratio"
-Scaling factor in calculation of maximum distance an expression
-can be moved by \s-1GCSE\s0 optimizations. This is currently supported only in the
-code hoisting pass. The bigger the ratio, the more aggressive code hoisting
-will be with simple expressions, i.e., the expressions which have cost
-less than \fBgcse-unrestricted-cost\fR. Specifying 0 will disable
-hoisting of simple expressions. The default value is 10.
-.IP "\fBgcse-unrestricted-cost\fR" 4
-.IX Item "gcse-unrestricted-cost"
-Cost, roughly measured as the cost of a single typical machine
-instruction, at which \s-1GCSE\s0 optimizations will not constrain
-the distance an expression can travel. This is currently
-supported only in the code hoisting pass. The lesser the cost,
-the more aggressive code hoisting will be. Specifying 0 will
-allow all expressions to travel unrestricted distances.
-The default value is 3.
-.IP "\fBmax-hoist-depth\fR" 4
-.IX Item "max-hoist-depth"
-The depth of search in the dominator tree for expressions to hoist.
-This is used to avoid quadratic behavior in hoisting algorithm.
-The value of 0 will avoid limiting the search, but may slow down compilation
-of huge functions. The default value is 30.
-.IP "\fBmax-unrolled-insns\fR" 4
-.IX Item "max-unrolled-insns"
-The maximum number of instructions that a loop should have if that loop
-is unrolled, and if the loop is unrolled, it determines how many times
-the loop code is unrolled.
-.IP "\fBmax-average-unrolled-insns\fR" 4
-.IX Item "max-average-unrolled-insns"
-The maximum number of instructions biased by probabilities of their execution
-that a loop should have if that loop is unrolled, and if the loop is unrolled,
-it determines how many times the loop code is unrolled.
-.IP "\fBmax-unroll-times\fR" 4
-.IX Item "max-unroll-times"
-The maximum number of unrollings of a single loop.
-.IP "\fBmax-peeled-insns\fR" 4
-.IX Item "max-peeled-insns"
-The maximum number of instructions that a loop should have if that loop
-is peeled, and if the loop is peeled, it determines how many times
-the loop code is peeled.
-.IP "\fBmax-peel-times\fR" 4
-.IX Item "max-peel-times"
-The maximum number of peelings of a single loop.
-.IP "\fBmax-completely-peeled-insns\fR" 4
-.IX Item "max-completely-peeled-insns"
-The maximum number of insns of a completely peeled loop.
-.IP "\fBmax-completely-peeled-insns-feedback\fR" 4
-.IX Item "max-completely-peeled-insns-feedback"
-The maximum number of insns of a completely peeled loop when profile
-feedback is available and the loop is hot. Because of the real
-profiles, this value may set to be larger for hot loops. Its default
-value is 600.
-.IP "\fBmax-once-peeled-insns\fR" 4
-.IX Item "max-once-peeled-insns"
-The maximum number of insns of a peeled loop that rolls only once.
-.IP "\fBmax-once-peeled-insns-feedback\fR" 4
-.IX Item "max-once-peeled-insns-feedback"
-The maximum number of insns of a peeled loop when profile feedback is
-available and the loop is hot. Because of the real profiles, this
-value may set to be larger for hot loops. The default value is 600.
-.IP "\fBmax-completely-peel-times\fR" 4
-.IX Item "max-completely-peel-times"
-The maximum number of iterations of a loop to be suitable for complete peeling.
-.IP "\fBmax-completely-peel-times-feedback\fR" 4
-.IX Item "max-completely-peel-times-feedback"
-The maximum number of iterations of a loop to be suitable for complete
-peeling when profile feedback is available and the loop is
-hot. Because of the real profiles, this value may set to be larger for
-hot loops. Its default value is 16.
-.IP "\fBmax-completely-peel-loop-nest-depth\fR" 4
-.IX Item "max-completely-peel-loop-nest-depth"
-The maximum depth of a loop nest suitable for complete peeling.
-.IP "\fBcodesize-hotness-threshold\fR" 4
-.IX Item "codesize-hotness-threshold"
-The minimum profile count of basic blocks to look at when estimating
-the code size footprint of the call graph in a \s-1LIPO\s0 compile.
-.IP "\fBunrollpeel-codesize-threshold\fR" 4
-.IX Item "unrollpeel-codesize-threshold"
-Maximum \s-1LIPO\s0 code size footprint estimate for loop unrolling and peeling.
-.IP "\fBmax-unswitch-insns\fR" 4
-.IX Item "max-unswitch-insns"
-The maximum number of insns of an unswitched loop.
-.IP "\fBmax-unswitch-level\fR" 4
-.IX Item "max-unswitch-level"
-The maximum number of branches unswitched in a single loop.
-.IP "\fBlim-expensive\fR" 4
-.IX Item "lim-expensive"
-The minimum cost of an expensive expression in the loop invariant motion.
-.IP "\fBiv-consider-all-candidates-bound\fR" 4
-.IX Item "iv-consider-all-candidates-bound"
-Bound on number of candidates for induction variables below that
-all candidates are considered for each use in induction variable
-optimizations. Only the most relevant candidates are considered
-if there are more candidates, to avoid quadratic time complexity.
-.IP "\fBiv-max-considered-uses\fR" 4
-.IX Item "iv-max-considered-uses"
-The induction variable optimizations give up on loops that contain more
-induction variable uses.
-.IP "\fBiv-always-prune-cand-set-bound\fR" 4
-.IX Item "iv-always-prune-cand-set-bound"
-If number of candidates in the set is smaller than this value,
-we always try to remove unnecessary ivs from the set during its
-optimization when a new iv is added to the set.
-.IP "\fBscev-max-expr-size\fR" 4
-.IX Item "scev-max-expr-size"
-Bound on size of expressions used in the scalar evolutions analyzer.
-Large expressions slow the analyzer.
-.IP "\fBscev-max-expr-complexity\fR" 4
-.IX Item "scev-max-expr-complexity"
-Bound on the complexity of the expressions in the scalar evolutions analyzer.
-Complex expressions slow the analyzer.
-.IP "\fBomega-max-vars\fR" 4
-.IX Item "omega-max-vars"
-The maximum number of variables in an Omega constraint system.
-The default value is 128.
-.IP "\fBomega-max-geqs\fR" 4
-.IX Item "omega-max-geqs"
-The maximum number of inequalities in an Omega constraint system.
-The default value is 256.
-.IP "\fBomega-max-eqs\fR" 4
-.IX Item "omega-max-eqs"
-The maximum number of equalities in an Omega constraint system.
-The default value is 128.
-.IP "\fBomega-max-wild-cards\fR" 4
-.IX Item "omega-max-wild-cards"
-The maximum number of wildcard variables that the Omega solver will
-be able to insert. The default value is 18.
-.IP "\fBomega-hash-table-size\fR" 4
-.IX Item "omega-hash-table-size"
-The size of the hash table in the Omega solver. The default value is
-550.
-.IP "\fBomega-max-keys\fR" 4
-.IX Item "omega-max-keys"
-The maximal number of keys used by the Omega solver. The default
-value is 500.
-.IP "\fBomega-eliminate-redundant-constraints\fR" 4
-.IX Item "omega-eliminate-redundant-constraints"
-When set to 1, use expensive methods to eliminate all redundant
-constraints. The default value is 0.
-.IP "\fBvect-max-version-for-alignment-checks\fR" 4
-.IX Item "vect-max-version-for-alignment-checks"
-The maximum number of runtime checks that can be performed when
-doing loop versioning for alignment in the vectorizer. See option
-ftree-vect-loop-version for more information.
-.IP "\fBvect-max-version-for-alias-checks\fR" 4
-.IX Item "vect-max-version-for-alias-checks"
-The maximum number of runtime checks that can be performed when
-doing loop versioning for alias in the vectorizer. See option
-ftree-vect-loop-version for more information.
-.IP "\fBmax-iterations-to-track\fR" 4
-.IX Item "max-iterations-to-track"
-The maximum number of iterations of a loop the brute force algorithm
-for analysis of # of iterations of the loop tries to evaluate.
-.IP "\fBhot-bb-count-fraction\fR" 4
-.IX Item "hot-bb-count-fraction"
-Select fraction of the maximal count of repetitions of basic block in program
-given basic block needs to have to be considered hot.
-.IP "\fBhot-bb-frequency-fraction\fR" 4
-.IX Item "hot-bb-frequency-fraction"
-Select fraction of the entry block frequency of executions of basic block in
-function given basic block needs to have to be considered hot
-.IP "\fBmax-predicted-iterations\fR" 4
-.IX Item "max-predicted-iterations"
-The maximum number of loop iterations we predict statically. This is useful
-in cases where function contain single loop with known bound and other loop
-with unknown. We predict the known number of iterations correctly, while
-the unknown number of iterations average to roughly 10. This means that the
-loop without bounds would appear artificially cold relative to the other one.
-.IP "\fBalign-threshold\fR" 4
-.IX Item "align-threshold"
-Select fraction of the maximal frequency of executions of basic block in
-function given basic block will get aligned.
-.IP "\fBalign-loop-iterations\fR" 4
-.IX Item "align-loop-iterations"
-A loop expected to iterate at lest the selected number of iterations will get
-aligned.
-.IP "\fBtracer-dynamic-coverage\fR" 4
-.IX Item "tracer-dynamic-coverage"
-.PD 0
-.IP "\fBtracer-dynamic-coverage-feedback\fR" 4
-.IX Item "tracer-dynamic-coverage-feedback"
-.PD
-This value is used to limit superblock formation once the given percentage of
-executed instructions is covered. This limits unnecessary code size
-expansion.
-.Sp
-The \fBtracer-dynamic-coverage-feedback\fR is used only when profile
-feedback is available. The real profiles (as opposed to statically estimated
-ones) are much less balanced allowing the threshold to be larger value.
-.IP "\fBtracer-max-code-growth\fR" 4
-.IX Item "tracer-max-code-growth"
-Stop tail duplication once code growth has reached given percentage. This is
-rather hokey argument, as most of the duplicates will be eliminated later in
-cross jumping, so it may be set to much higher values than is the desired code
-growth.
-.IP "\fBtracer-min-branch-ratio\fR" 4
-.IX Item "tracer-min-branch-ratio"
-Stop reverse growth when the reverse probability of best edge is less than this
-threshold (in percent).
-.IP "\fBtracer-min-branch-ratio\fR" 4
-.IX Item "tracer-min-branch-ratio"
-.PD 0
-.IP "\fBtracer-min-branch-ratio-feedback\fR" 4
-.IX Item "tracer-min-branch-ratio-feedback"
-.PD
-Stop forward growth if the best edge do have probability lower than this
-threshold.
-.Sp
-Similarly to \fBtracer-dynamic-coverage\fR two values are present, one for
-compilation for profile feedback and one for compilation without. The value
-for compilation with profile feedback needs to be more conservative (higher) in
-order to make tracer effective.
-.IP "\fBmax-cse-path-length\fR" 4
-.IX Item "max-cse-path-length"
-Maximum number of basic blocks on path that cse considers. The default is 10.
-.IP "\fBmax-cse-insns\fR" 4
-.IX Item "max-cse-insns"
-The maximum instructions \s-1CSE\s0 process before flushing. The default is 1000.
-.IP "\fBggc-min-expand\fR" 4
-.IX Item "ggc-min-expand"
-\&\s-1GCC\s0 uses a garbage collector to manage its own memory allocation. This
-parameter specifies the minimum percentage by which the garbage
-collector's heap should be allowed to expand between collections.
-Tuning this may improve compilation speed; it has no effect on code
-generation.
-.Sp
-The default is 30% + 70% * (\s-1RAM/1GB\s0) with an upper bound of 100% when
-\&\s-1RAM\s0 >= 1GB. If \f(CW\*(C`getrlimit\*(C'\fR is available, the notion of \*(L"\s-1RAM\s0\*(R" is
-the smallest of actual \s-1RAM\s0 and \f(CW\*(C`RLIMIT_DATA\*(C'\fR or \f(CW\*(C`RLIMIT_AS\*(C'\fR. If
-\&\s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a particular platform, the lower
-bound of 30% is used. Setting this parameter and
-\&\fBggc-min-heapsize\fR to zero causes a full collection to occur at
-every opportunity. This is extremely slow, but can be useful for
-debugging.
-.IP "\fBggc-min-heapsize\fR" 4
-.IX Item "ggc-min-heapsize"
-Minimum size of the garbage collector's heap before it begins bothering
-to collect garbage. The first collection occurs after the heap expands
-by \fBggc-min-expand\fR% beyond \fBggc-min-heapsize\fR. Again,
-tuning this may improve compilation speed, and has no effect on code
-generation.
-.Sp
-The default is the smaller of \s-1RAM/8\s0, \s-1RLIMIT_RSS\s0, or a limit which
-tries to ensure that \s-1RLIMIT_DATA\s0 or \s-1RLIMIT_AS\s0 are not exceeded, but
-with a lower bound of 4096 (four megabytes) and an upper bound of
-131072 (128 megabytes). If \s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a
-particular platform, the lower bound is used. Setting this parameter
-very large effectively disables garbage collection. Setting this
-parameter and \fBggc-min-expand\fR to zero causes a full collection
-to occur at every opportunity.
-.IP "\fBmax-reload-search-insns\fR" 4
-.IX Item "max-reload-search-insns"
-The maximum number of instruction reload should look backward for equivalent
-register. Increasing values mean more aggressive optimization, making the
-compile time increase with probably slightly better performance. The default
-value is 100.
-.IP "\fBmax-cselib-memory-locations\fR" 4
-.IX Item "max-cselib-memory-locations"
-The maximum number of memory locations cselib should take into account.
-Increasing values mean more aggressive optimization, making the compile time
-increase with probably slightly better performance. The default value is 500.
-.IP "\fBreorder-blocks-duplicate\fR" 4
-.IX Item "reorder-blocks-duplicate"
-.PD 0
-.IP "\fBreorder-blocks-duplicate-feedback\fR" 4
-.IX Item "reorder-blocks-duplicate-feedback"
-.PD
-Used by basic block reordering pass to decide whether to use unconditional
-branch or duplicate the code on its destination. Code is duplicated when its
-estimated size is smaller than this value multiplied by the estimated size of
-unconditional jump in the hot spots of the program.
-.Sp
-The \fBreorder-block-duplicate-feedback\fR is used only when profile
-feedback is available and may be set to higher values than
-\&\fBreorder-block-duplicate\fR since information about the hot spots is more
-accurate.
-.IP "\fBmax-sched-ready-insns\fR" 4
-.IX Item "max-sched-ready-insns"
-The maximum number of instructions ready to be issued the scheduler should
-consider at any given time during the first scheduling pass. Increasing
-values mean more thorough searches, making the compilation time increase
-with probably little benefit. The default value is 100.
-.IP "\fBmax-sched-region-blocks\fR" 4
-.IX Item "max-sched-region-blocks"
-The maximum number of blocks in a region to be considered for
-interblock scheduling. The default value is 10.
-.IP "\fBmax-pipeline-region-blocks\fR" 4
-.IX Item "max-pipeline-region-blocks"
-The maximum number of blocks in a region to be considered for
-pipelining in the selective scheduler. The default value is 15.
-.IP "\fBmax-sched-region-insns\fR" 4
-.IX Item "max-sched-region-insns"
-The maximum number of insns in a region to be considered for
-interblock scheduling. The default value is 100.
-.IP "\fBmax-pipeline-region-insns\fR" 4
-.IX Item "max-pipeline-region-insns"
-The maximum number of insns in a region to be considered for
-pipelining in the selective scheduler. The default value is 200.
-.IP "\fBmin-spec-prob\fR" 4
-.IX Item "min-spec-prob"
-The minimum probability (in percents) of reaching a source block
-for interblock speculative scheduling. The default value is 40.
-.IP "\fBmax-sched-extend-regions-iters\fR" 4
-.IX Item "max-sched-extend-regions-iters"
-The maximum number of iterations through \s-1CFG\s0 to extend regions.
-0 \- disable region extension,
-N \- do at most N iterations.
-The default value is 0.
-.IP "\fBmax-sched-insn-conflict-delay\fR" 4
-.IX Item "max-sched-insn-conflict-delay"
-The maximum conflict delay for an insn to be considered for speculative motion.
-The default value is 3.
-.IP "\fBsched-spec-prob-cutoff\fR" 4
-.IX Item "sched-spec-prob-cutoff"
-The minimal probability of speculation success (in percents), so that
-speculative insn will be scheduled.
-The default value is 40.
-.IP "\fBsched-mem-true-dep-cost\fR" 4
-.IX Item "sched-mem-true-dep-cost"
-Minimal distance (in \s-1CPU\s0 cycles) between store and load targeting same
-memory locations. The default value is 1.
-.IP "\fBselsched-max-lookahead\fR" 4
-.IX Item "selsched-max-lookahead"
-The maximum size of the lookahead window of selective scheduling. It is a
-depth of search for available instructions.
-The default value is 50.
-.IP "\fBselsched-max-sched-times\fR" 4
-.IX Item "selsched-max-sched-times"
-The maximum number of times that an instruction will be scheduled during
-selective scheduling. This is the limit on the number of iterations
-through which the instruction may be pipelined. The default value is 2.
-.IP "\fBselsched-max-insns-to-rename\fR" 4
-.IX Item "selsched-max-insns-to-rename"
-The maximum number of best instructions in the ready list that are considered
-for renaming in the selective scheduler. The default value is 2.
-.IP "\fBmax-last-value-rtl\fR" 4
-.IX Item "max-last-value-rtl"
-The maximum size measured as number of RTLs that can be recorded in an expression
-in combiner for a pseudo register as last known value of that register. The default
-is 10000.
-.IP "\fBinteger-share-limit\fR" 4
-.IX Item "integer-share-limit"
-Small integer constants can use a shared data structure, reducing the
-compiler's memory usage and increasing its speed. This sets the maximum
-value of a shared integer constant. The default value is 256.
-.IP "\fBmin-virtual-mappings\fR" 4
-.IX Item "min-virtual-mappings"
-Specifies the minimum number of virtual mappings in the incremental
-\&\s-1SSA\s0 updater that should be registered to trigger the virtual mappings
-heuristic defined by virtual-mappings-ratio. The default value is
-100.
-.IP "\fBvirtual-mappings-ratio\fR" 4
-.IX Item "virtual-mappings-ratio"
-If the number of virtual mappings is virtual-mappings-ratio bigger
-than the number of virtual symbols to be updated, then the incremental
-\&\s-1SSA\s0 updater switches to a full update for those symbols. The default
-ratio is 3.
-.IP "\fBssp-buffer-size\fR" 4
-.IX Item "ssp-buffer-size"
-The minimum size of buffers (i.e. arrays) that will receive stack smashing
-protection when \fB\-fstack\-protection\fR is used.
-.IP "\fBmax-jump-thread-duplication-stmts\fR" 4
-.IX Item "max-jump-thread-duplication-stmts"
-Maximum number of statements allowed in a block that needs to be
-duplicated when threading jumps.
-.IP "\fBmax-fields-for-field-sensitive\fR" 4
-.IX Item "max-fields-for-field-sensitive"
-Maximum number of fields in a structure we will treat in
-a field sensitive manner during pointer analysis. The default is zero
-for \-O0, and \-O1 and 100 for \-Os, \-O2, and \-O3.
-.IP "\fBprefetch-latency\fR" 4
-.IX Item "prefetch-latency"
-Estimate on average number of instructions that are executed before
-prefetch finishes. The distance we prefetch ahead is proportional
-to this constant. Increasing this number may also lead to less
-streams being prefetched (see \fBsimultaneous-prefetches\fR).
-.IP "\fBsimultaneous-prefetches\fR" 4
-.IX Item "simultaneous-prefetches"
-Maximum number of prefetches that can run at the same time.
-.IP "\fBl1\-cache\-line\-size\fR" 4
-.IX Item "l1-cache-line-size"
-The size of cache line in L1 cache, in bytes.
-.IP "\fBl1\-cache\-size\fR" 4
-.IX Item "l1-cache-size"
-The size of L1 cache, in kilobytes.
-.IP "\fBl2\-cache\-size\fR" 4
-.IX Item "l2-cache-size"
-The size of L2 cache, in kilobytes.
-.IP "\fBmin-insn-to-prefetch-ratio\fR" 4
-.IX Item "min-insn-to-prefetch-ratio"
-The minimum ratio between the number of instructions and the
-number of prefetches to enable prefetching in a loop.
-.IP "\fBprefetch-min-insn-to-mem-ratio\fR" 4
-.IX Item "prefetch-min-insn-to-mem-ratio"
-The minimum ratio between the number of instructions and the
-number of memory references to enable prefetching in a loop.
-.IP "\fBuse-canonical-types\fR" 4
-.IX Item "use-canonical-types"
-Whether the compiler should use the \*(L"canonical\*(R" type system. By
-default, this should always be 1, which uses a more efficient internal
-mechanism for comparing types in \*(C+ and Objective\-\*(C+. However, if
-bugs in the canonical type system are causing compilation failures,
-set this value to 0 to disable canonical types.
-.IP "\fBswitch-conversion-max-branch-ratio\fR" 4
-.IX Item "switch-conversion-max-branch-ratio"
-Switch initialization conversion will refuse to create arrays that are
-bigger than \fBswitch-conversion-max-branch-ratio\fR times the number of
-branches in the switch.
-.IP "\fBmax-partial-antic-length\fR" 4
-.IX Item "max-partial-antic-length"
-Maximum length of the partial antic set computed during the tree
-partial redundancy elimination optimization (\fB\-ftree\-pre\fR) when
-optimizing at \fB\-O3\fR and above. For some sorts of source code
-the enhanced partial redundancy elimination optimization can run away,
-consuming all of the memory available on the host machine. This
-parameter sets a limit on the length of the sets that are computed,
-which prevents the runaway behavior. Setting a value of 0 for
-this parameter will allow an unlimited set length.
-.IP "\fBsccvn-max-scc-size\fR" 4
-.IX Item "sccvn-max-scc-size"
-Maximum size of a strongly connected component (\s-1SCC\s0) during \s-1SCCVN\s0
-processing. If this limit is hit, \s-1SCCVN\s0 processing for the whole
-function will not be done and optimizations depending on it will
-be disabled. The default maximum \s-1SCC\s0 size is 10000.
-.IP "\fBira-max-loops-num\fR" 4
-.IX Item "ira-max-loops-num"
-\&\s-1IRA\s0 uses a regional register allocation by default. If a function
-contains loops more than number given by the parameter, only at most
-given number of the most frequently executed loops will form regions
-for the regional register allocation. The default value of the
-parameter is 100.
-.IP "\fBira-max-conflict-table-size\fR" 4
-.IX Item "ira-max-conflict-table-size"
-Although \s-1IRA\s0 uses a sophisticated algorithm of compression conflict
-table, the table can be still big for huge functions. If the conflict
-table for a function could be more than size in \s-1MB\s0 given by the
-parameter, the conflict table is not built and faster, simpler, and
-lower quality register allocation algorithm will be used. The
-algorithm do not use pseudo-register conflicts. The default value of
-the parameter is 2000.
-.IP "\fBira-loop-reserved-regs\fR" 4
-.IX Item "ira-loop-reserved-regs"
-\&\s-1IRA\s0 can be used to evaluate more accurate register pressure in loops
-for decision to move loop invariants (see \fB\-O3\fR). The number
-of available registers reserved for some other purposes is described
-by this parameter. The default value of the parameter is 2 which is
-minimal number of registers needed for execution of typical
-instruction. This value is the best found from numerous experiments.
-.IP "\fBloop-invariant-max-bbs-in-loop\fR" 4
-.IX Item "loop-invariant-max-bbs-in-loop"
-Loop invariant motion can be very expensive, both in compile time and
-in amount of needed compile time memory, with very large loops. Loops
-with more basic blocks than this parameter won't have loop invariant
-motion optimization performed on them. The default value of the
-parameter is 1000 for \-O1 and 10000 for \-O2 and above.
-.IP "\fBmax-vartrack-size\fR" 4
-.IX Item "max-vartrack-size"
-Sets a maximum number of hash table slots to use during variable
-tracking dataflow analysis of any function. If this limit is exceeded
-with variable tracking at assignments enabled, analysis for that
-function is retried without it, after removing all debug insns from
-the function. If the limit is exceeded even without debug insns, var
-tracking analysis is completely disabled for the function. Setting
-the parameter to zero makes it unlimited.
-.IP "\fBmin-nondebug-insn-uid\fR" 4
-.IX Item "min-nondebug-insn-uid"
-Use uids starting at this parameter for nondebug insns. The range below
-the parameter is reserved exclusively for debug insns created by
-\&\fB\-fvar\-tracking\-assignments\fR, but debug insns may get
-(non-overlapping) uids above it if the reserved range is exhausted.
-.IP "\fBipa-sra-ptr-growth-factor\fR" 4
-.IX Item "ipa-sra-ptr-growth-factor"
-IPA-SRA will replace a pointer to an aggregate with one or more new
-parameters only when their cumulative size is less or equal to
-\&\fBipa-sra-ptr-growth-factor\fR times the size of the original
-pointer parameter.
-.IP "\fBgraphite-max-nb-scop-params\fR" 4
-.IX Item "graphite-max-nb-scop-params"
-To avoid exponential effects in the Graphite loop transforms, the
-number of parameters in a Static Control Part (SCoP) is bounded. The
-default value is 10 parameters. A variable whose value is unknown at
-compile time and defined outside a SCoP is a parameter of the SCoP.
-.IP "\fBgraphite-max-bbs-per-function\fR" 4
-.IX Item "graphite-max-bbs-per-function"
-To avoid exponential effects in the detection of SCoPs, the size of
-the functions analyzed by Graphite is bounded. The default value is
-100 basic blocks.
-.IP "\fBloop-block-tile-size\fR" 4
-.IX Item "loop-block-tile-size"
-Loop blocking or strip mining transforms, enabled with
-\&\fB\-floop\-block\fR or \fB\-floop\-strip\-mine\fR, strip mine each
-loop in the loop nest by a given number of iterations. The strip
-length can be changed using the \fBloop-block-tile-size\fR
-parameter. The default value is 51 iterations.
-.IP "\fBdevirt-type-list-size\fR" 4
-.IX Item "devirt-type-list-size"
-IPA-CP attempts to track all possible types passed to a function's
-parameter in order to perform devirtualization.
-\&\fBdevirt-type-list-size\fR is the maximum number of types it
-stores per a single formal parameter of a function.
-.IP "\fBlto-partitions\fR" 4
-.IX Item "lto-partitions"
-Specify desired number of partitions produced during \s-1WHOPR\s0 compilation.
-The number of partitions should exceed the number of CPUs used for compilation.
-The default value is 32.
-.IP "\fBlto-minpartition\fR" 4
-.IX Item "lto-minpartition"
-Size of minimal partition for \s-1WHOPR\s0 (in estimated instructions).
-This prevents expenses of splitting very small programs into too many
-partitions.
-.IP "\fBcxx-max-namespaces-for-diagnostic-help\fR" 4
-.IX Item "cxx-max-namespaces-for-diagnostic-help"
-The maximum number of namespaces to consult for suggestions when \*(C+
-name lookup fails for an identifier. The default is 1000.
-.RE
-.RS 4
-.RE
-.SS "Options Controlling the Preprocessor"
-.IX Subsection "Options Controlling the Preprocessor"
-These options control the C preprocessor, which is run on each C source
-file before actual compilation.
-.PP
-If you use the \fB\-E\fR option, nothing is done except preprocessing.
-Some of these options make sense only together with \fB\-E\fR because
-they cause the preprocessor output to be unsuitable for actual
-compilation.
-.IP "\fB\-Wp,\fR\fIoption\fR" 4
-.IX Item "-Wp,option"
-You can use \fB\-Wp,\fR\fIoption\fR to bypass the compiler driver
-and pass \fIoption\fR directly through to the preprocessor. If
-\&\fIoption\fR contains commas, it is split into multiple options at the
-commas. However, many options are modified, translated or interpreted
-by the compiler driver before being passed to the preprocessor, and
-\&\fB\-Wp\fR forcibly bypasses this phase. The preprocessor's direct
-interface is undocumented and subject to change, so whenever possible
-you should avoid using \fB\-Wp\fR and let the driver handle the
-options instead.
-.IP "\fB\-Xpreprocessor\fR \fIoption\fR" 4
-.IX Item "-Xpreprocessor option"
-Pass \fIoption\fR as an option to the preprocessor. You can use this to
-supply system-specific preprocessor options which \s-1GCC\s0 does not know how to
-recognize.
-.Sp
-If you want to pass an option that takes an argument, you must use
-\&\fB\-Xpreprocessor\fR twice, once for the option and once for the argument.
-.IP "\fB\-D\fR \fIname\fR" 4
-.IX Item "-D name"
-Predefine \fIname\fR as a macro, with definition \f(CW1\fR.
-.IP "\fB\-D\fR \fIname\fR\fB=\fR\fIdefinition\fR" 4
-.IX Item "-D name=definition"
-The contents of \fIdefinition\fR are tokenized and processed as if
-they appeared during translation phase three in a \fB#define\fR
-directive. In particular, the definition will be truncated by
-embedded newline characters.
-.Sp
-If you are invoking the preprocessor from a shell or shell-like
-program you may need to use the shell's quoting syntax to protect
-characters such as spaces that have a meaning in the shell syntax.
-.Sp
-If you wish to define a function-like macro on the command line, write
-its argument list with surrounding parentheses before the equals sign
-(if any). Parentheses are meaningful to most shells, so you will need
-to quote the option. With \fBsh\fR and \fBcsh\fR,
-\&\fB\-D'\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB'\fR works.
-.Sp
-\&\fB\-D\fR and \fB\-U\fR options are processed in the order they
-are given on the command line. All \fB\-imacros\fR \fIfile\fR and
-\&\fB\-include\fR \fIfile\fR options are processed after all
-\&\fB\-D\fR and \fB\-U\fR options.
-.IP "\fB\-U\fR \fIname\fR" 4
-.IX Item "-U name"
-Cancel any previous definition of \fIname\fR, either built in or
-provided with a \fB\-D\fR option.
-.IP "\fB\-undef\fR" 4
-.IX Item "-undef"
-Do not predefine any system-specific or GCC-specific macros. The
-standard predefined macros remain defined.
-.IP "\fB\-I\fR \fIdir\fR" 4
-.IX Item "-I dir"
-Add the directory \fIdir\fR to the list of directories to be searched
-for header files.
-Directories named by \fB\-I\fR are searched before the standard
-system include directories. If the directory \fIdir\fR is a standard
-system include directory, the option is ignored to ensure that the
-default search order for system directories and the special treatment
-of system headers are not defeated
-\&.
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-o\fR \fIfile\fR" 4
-.IX Item "-o file"
-Write output to \fIfile\fR. This is the same as specifying \fIfile\fR
-as the second non-option argument to \fBcpp\fR. \fBgcc\fR has a
-different interpretation of a second non-option argument, so you must
-use \fB\-o\fR to specify the output file.
-.IP "\fB\-Wall\fR" 4
-.IX Item "-Wall"
-Turns on all optional warnings which are desirable for normal code.
-At present this is \fB\-Wcomment\fR, \fB\-Wtrigraphs\fR,
-\&\fB\-Wmultichar\fR and a warning about integer promotion causing a
-change of sign in \f(CW\*(C`#if\*(C'\fR expressions. Note that many of the
-preprocessor's warnings are on by default and have no options to
-control them.
-.IP "\fB\-Wcomment\fR" 4
-.IX Item "-Wcomment"
-.PD 0
-.IP "\fB\-Wcomments\fR" 4
-.IX Item "-Wcomments"
-.PD
-Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
-comment, or whenever a backslash-newline appears in a \fB//\fR comment.
-(Both forms have the same effect.)
-.IP "\fB\-Wtrigraphs\fR" 4
-.IX Item "-Wtrigraphs"
-Most trigraphs in comments cannot affect the meaning of the program.
-However, a trigraph that would form an escaped newline (\fB??/\fR at
-the end of a line) can, by changing where the comment begins or ends.
-Therefore, only trigraphs that would form escaped newlines produce
-warnings inside a comment.
-.Sp
-This option is implied by \fB\-Wall\fR. If \fB\-Wall\fR is not
-given, this option is still enabled unless trigraphs are enabled. To
-get trigraph conversion without warnings, but get the other
-\&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
-.IP "\fB\-Wtraditional\fR" 4
-.IX Item "-Wtraditional"
-Warn about certain constructs that behave differently in traditional and
-\&\s-1ISO\s0 C. Also warn about \s-1ISO\s0 C constructs that have no traditional C
-equivalent, and problematic constructs which should be avoided.
-.IP "\fB\-Wundef\fR" 4
-.IX Item "-Wundef"
-Warn whenever an identifier which is not a macro is encountered in an
-\&\fB#if\fR directive, outside of \fBdefined\fR. Such identifiers are
-replaced with zero.
-.IP "\fB\-Wunused\-macros\fR" 4
-.IX Item "-Wunused-macros"
-Warn about macros defined in the main file that are unused. A macro
-is \fIused\fR if it is expanded or tested for existence at least once.
-The preprocessor will also warn if the macro has not been used at the
-time it is redefined or undefined.
-.Sp
-Built-in macros, macros defined on the command line, and macros
-defined in include files are not warned about.
-.Sp
-\&\fINote:\fR If a macro is actually used, but only used in skipped
-conditional blocks, then \s-1CPP\s0 will report it as unused. To avoid the
-warning in such a case, you might improve the scope of the macro's
-definition by, for example, moving it into the first skipped block.
-Alternatively, you could provide a dummy use with something like:
-.Sp
-.Vb 2
-\& #if defined the_macro_causing_the_warning
-\& #endif
-.Ve
-.IP "\fB\-Wendif\-labels\fR" 4
-.IX Item "-Wendif-labels"
-Warn whenever an \fB#else\fR or an \fB#endif\fR are followed by text.
-This usually happens in code of the form
-.Sp
-.Vb 5
-\& #if FOO
-\& ...
-\& #else FOO
-\& ...
-\& #endif FOO
-.Ve
-.Sp
-The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments, but often are not
-in older programs. This warning is on by default.
-.IP "\fB\-Werror\fR" 4
-.IX Item "-Werror"
-Make all warnings into hard errors. Source code which triggers warnings
-will be rejected.
-.IP "\fB\-Wsystem\-headers\fR" 4
-.IX Item "-Wsystem-headers"
-Issue warnings for code in system headers. These are normally unhelpful
-in finding bugs in your own code, therefore suppressed. If you are
-responsible for the system library, you may want to see them.
-.IP "\fB\-w\fR" 4
-.IX Item "-w"
-Suppress all warnings, including those which \s-1GNU\s0 \s-1CPP\s0 issues by default.
-.IP "\fB\-pedantic\fR" 4
-.IX Item "-pedantic"
-Issue all the mandatory diagnostics listed in the C standard. Some of
-them are left out by default, since they trigger frequently on harmless
-code.
-.IP "\fB\-pedantic\-errors\fR" 4
-.IX Item "-pedantic-errors"
-Issue all the mandatory diagnostics, and make all mandatory diagnostics
-into errors. This includes mandatory diagnostics that \s-1GCC\s0 issues
-without \fB\-pedantic\fR but treats as warnings.
-.IP "\fB\-M\fR" 4
-.IX Item "-M"
-Instead of outputting the result of preprocessing, output a rule
-suitable for \fBmake\fR describing the dependencies of the main
-source file. The preprocessor outputs one \fBmake\fR rule containing
-the object file name for that source file, a colon, and the names of all
-the included files, including those coming from \fB\-include\fR or
-\&\fB\-imacros\fR command line options.
-.Sp
-Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
-object file name consists of the name of the source file with any
-suffix replaced with object file suffix and with any leading directory
-parts removed. If there are many included files then the rule is
-split into several lines using \fB\e\fR\-newline. The rule has no
-commands.
-.Sp
-This option does not suppress the preprocessor's debug output, such as
-\&\fB\-dM\fR. To avoid mixing such debug output with the dependency
-rules you should explicitly specify the dependency output file with
-\&\fB\-MF\fR, or use an environment variable like
-\&\fB\s-1DEPENDENCIES_OUTPUT\s0\fR. Debug output
-will still be sent to the regular output stream as normal.
-.Sp
-Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
-warnings with an implicit \fB\-w\fR.
-.IP "\fB\-MM\fR" 4
-.IX Item "-MM"
-Like \fB\-M\fR but do not mention header files that are found in
-system header directories, nor header files that are included,
-directly or indirectly, from such a header.
-.Sp
-This implies that the choice of angle brackets or double quotes in an
-\&\fB#include\fR directive does not in itself determine whether that
-header will appear in \fB\-MM\fR dependency output. This is a
-slight change in semantics from \s-1GCC\s0 versions 3.0 and earlier.
-.IP "\fB\-MF\fR \fIfile\fR" 4
-.IX Item "-MF file"
-When used with \fB\-M\fR or \fB\-MM\fR, specifies a
-file to write the dependencies to. If no \fB\-MF\fR switch is given
-the preprocessor sends the rules to the same place it would have sent
-preprocessed output.
-.Sp
-When used with the driver options \fB\-MD\fR or \fB\-MMD\fR,
-\&\fB\-MF\fR overrides the default dependency output file.
-.IP "\fB\-MG\fR" 4
-.IX Item "-MG"
-In conjunction with an option such as \fB\-M\fR requesting
-dependency generation, \fB\-MG\fR assumes missing header files are
-generated files and adds them to the dependency list without raising
-an error. The dependency filename is taken directly from the
-\&\f(CW\*(C`#include\*(C'\fR directive without prepending any path. \fB\-MG\fR
-also suppresses preprocessed output, as a missing header file renders
-this useless.
-.Sp
-This feature is used in automatic updating of makefiles.
-.IP "\fB\-MP\fR" 4
-.IX Item "-MP"
-This option instructs \s-1CPP\s0 to add a phony target for each dependency
-other than the main file, causing each to depend on nothing. These
-dummy rules work around errors \fBmake\fR gives if you remove header
-files without updating the \fIMakefile\fR to match.
-.Sp
-This is typical output:
-.Sp
-.Vb 1
-\& test.o: test.c test.h
-\&
-\& test.h:
-.Ve
-.IP "\fB\-MT\fR \fItarget\fR" 4
-.IX Item "-MT target"
-Change the target of the rule emitted by dependency generation. By
-default \s-1CPP\s0 takes the name of the main input file, deletes any
-directory components and any file suffix such as \fB.c\fR, and
-appends the platform's usual object suffix. The result is the target.
-.Sp
-An \fB\-MT\fR option will set the target to be exactly the string you
-specify. If you want multiple targets, you can specify them as a single
-argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
-.Sp
-For example, \fB\-MT\ '$(objpfx)foo.o'\fR might give
-.Sp
-.Vb 1
-\& $(objpfx)foo.o: foo.c
-.Ve
-.IP "\fB\-MQ\fR \fItarget\fR" 4
-.IX Item "-MQ target"
-Same as \fB\-MT\fR, but it quotes any characters which are special to
-Make. \fB\-MQ\ '$(objpfx)foo.o'\fR gives
-.Sp
-.Vb 1
-\& $$(objpfx)foo.o: foo.c
-.Ve
-.Sp
-The default target is automatically quoted, as if it were given with
-\&\fB\-MQ\fR.
-.IP "\fB\-MD\fR" 4
-.IX Item "-MD"
-\&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
-\&\fB\-E\fR is not implied. The driver determines \fIfile\fR based on
-whether an \fB\-o\fR option is given. If it is, the driver uses its
-argument but with a suffix of \fI.d\fR, otherwise it takes the name
-of the input file, removes any directory components and suffix, and
-applies a \fI.d\fR suffix.
-.Sp
-If \fB\-MD\fR is used in conjunction with \fB\-E\fR, any
-\&\fB\-o\fR switch is understood to specify the dependency output file, but if used without \fB\-E\fR, each \fB\-o\fR
-is understood to specify a target object file.
-.Sp
-Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
-a dependency output file as a side-effect of the compilation process.
-.IP "\fB\-MMD\fR" 4
-.IX Item "-MMD"
-Like \fB\-MD\fR except mention only user header files, not system
-header files.
-.IP "\fB\-fpch\-deps\fR" 4
-.IX Item "-fpch-deps"
-When using precompiled headers, this flag
-will cause the dependency-output flags to also list the files from the
-precompiled header's dependencies. If not specified only the
-precompiled header would be listed and not the files that were used to
-create it because those files are not consulted when a precompiled
-header is used.
-.IP "\fB\-fpch\-preprocess\fR" 4
-.IX Item "-fpch-preprocess"
-This option allows use of a precompiled header together with \fB\-E\fR. It inserts a special \f(CW\*(C`#pragma\*(C'\fR,
-\&\f(CW\*(C`#pragma GCC pch_preprocess "\f(CIfilename\f(CW"\*(C'\fR in the output to mark
-the place where the precompiled header was found, and its \fIfilename\fR.
-When \fB\-fpreprocessed\fR is in use, \s-1GCC\s0 recognizes this \f(CW\*(C`#pragma\*(C'\fR
-and loads the \s-1PCH\s0.
-.Sp
-This option is off by default, because the resulting preprocessed output
-is only really suitable as input to \s-1GCC\s0. It is switched on by
-\&\fB\-save\-temps\fR.
-.Sp
-You should not write this \f(CW\*(C`#pragma\*(C'\fR in your own code, but it is
-safe to edit the filename if the \s-1PCH\s0 file is available in a different
-location. The filename may be absolute or it may be relative to \s-1GCC\s0's
-current directory.
-.IP "\fB\-x c\fR" 4
-.IX Item "-x c"
-.PD 0
-.IP "\fB\-x c++\fR" 4
-.IX Item "-x c++"
-.IP "\fB\-x objective-c\fR" 4
-.IX Item "-x objective-c"
-.IP "\fB\-x assembler-with-cpp\fR" 4
-.IX Item "-x assembler-with-cpp"
-.PD
-Specify the source language: C, \*(C+, Objective-C, or assembly. This has
-nothing to do with standards conformance or extensions; it merely
-selects which base syntax to expect. If you give none of these options,
-cpp will deduce the language from the extension of the source file:
-\&\fB.c\fR, \fB.cc\fR, \fB.m\fR, or \fB.S\fR. Some other common
-extensions for \*(C+ and assembly are also recognized. If cpp does not
-recognize the extension, it will treat the file as C; this is the most
-generic mode.
-.Sp
-\&\fINote:\fR Previous versions of cpp accepted a \fB\-lang\fR option
-which selected both the language and the standards conformance level.
-This option has been removed, because it conflicts with the \fB\-l\fR
-option.
-.IP "\fB\-std=\fR\fIstandard\fR" 4
-.IX Item "-std=standard"
-.PD 0
-.IP "\fB\-ansi\fR" 4
-.IX Item "-ansi"
-.PD
-Specify the standard to which the code should conform. Currently \s-1CPP\s0
-knows about C and \*(C+ standards; others may be added in the future.
-.Sp
-\&\fIstandard\fR
-may be one of:
-.RS 4
-.ie n .IP """c90""" 4
-.el .IP "\f(CWc90\fR" 4
-.IX Item "c90"
-.PD 0
-.ie n .IP """c89""" 4
-.el .IP "\f(CWc89\fR" 4
-.IX Item "c89"
-.ie n .IP """iso9899:1990""" 4
-.el .IP "\f(CWiso9899:1990\fR" 4
-.IX Item "iso9899:1990"
-.PD
-The \s-1ISO\s0 C standard from 1990. \fBc90\fR is the customary shorthand for
-this version of the standard.
-.Sp
-The \fB\-ansi\fR option is equivalent to \fB\-std=c90\fR.
-.ie n .IP """iso9899:199409""" 4
-.el .IP "\f(CWiso9899:199409\fR" 4
-.IX Item "iso9899:199409"
-The 1990 C standard, as amended in 1994.
-.ie n .IP """iso9899:1999""" 4
-.el .IP "\f(CWiso9899:1999\fR" 4
-.IX Item "iso9899:1999"
-.PD 0
-.ie n .IP """c99""" 4
-.el .IP "\f(CWc99\fR" 4
-.IX Item "c99"
-.ie n .IP """iso9899:199x""" 4
-.el .IP "\f(CWiso9899:199x\fR" 4
-.IX Item "iso9899:199x"
-.ie n .IP """c9x""" 4
-.el .IP "\f(CWc9x\fR" 4
-.IX Item "c9x"
-.PD
-The revised \s-1ISO\s0 C standard, published in December 1999. Before
-publication, this was known as C9X.
-.ie n .IP """c1x""" 4
-.el .IP "\f(CWc1x\fR" 4
-.IX Item "c1x"
-The next version of the \s-1ISO\s0 C standard, still under development.
-.ie n .IP """gnu90""" 4
-.el .IP "\f(CWgnu90\fR" 4
-.IX Item "gnu90"
-.PD 0
-.ie n .IP """gnu89""" 4
-.el .IP "\f(CWgnu89\fR" 4
-.IX Item "gnu89"
-.PD
-The 1990 C standard plus \s-1GNU\s0 extensions. This is the default.
-.ie n .IP """gnu99""" 4
-.el .IP "\f(CWgnu99\fR" 4
-.IX Item "gnu99"
-.PD 0
-.ie n .IP """gnu9x""" 4
-.el .IP "\f(CWgnu9x\fR" 4
-.IX Item "gnu9x"
-.PD
-The 1999 C standard plus \s-1GNU\s0 extensions.
-.ie n .IP """gnu1x""" 4
-.el .IP "\f(CWgnu1x\fR" 4
-.IX Item "gnu1x"
-The next version of the \s-1ISO\s0 C standard, still under development, plus
-\&\s-1GNU\s0 extensions.
-.ie n .IP """c++98""" 4
-.el .IP "\f(CWc++98\fR" 4
-.IX Item "c++98"
-The 1998 \s-1ISO\s0 \*(C+ standard plus amendments.
-.ie n .IP """gnu++98""" 4
-.el .IP "\f(CWgnu++98\fR" 4
-.IX Item "gnu++98"
-The same as \fB\-std=c++98\fR plus \s-1GNU\s0 extensions. This is the
-default for \*(C+ code.
-.RE
-.RS 4
-.RE
-.IP "\fB\-I\-\fR" 4
-.IX Item "-I-"
-Split the include path. Any directories specified with \fB\-I\fR
-options before \fB\-I\-\fR are searched only for headers requested with
-\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
-\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR. If additional directories are
-specified with \fB\-I\fR options after the \fB\-I\-\fR, those
-directories are searched for all \fB#include\fR directives.
-.Sp
-In addition, \fB\-I\-\fR inhibits the use of the directory of the current
-file directory as the first search directory for \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.
-This option has been deprecated.
-.IP "\fB\-nostdinc\fR" 4
-.IX Item "-nostdinc"
-Do not search the standard system directories for header files.
-Only the directories you have specified with \fB\-I\fR options
-(and the directory of the current file, if appropriate) are searched.
-.IP "\fB\-nostdinc++\fR" 4
-.IX Item "-nostdinc++"
-Do not search for header files in the \*(C+\-specific standard directories,
-but do still search the other standard directories. (This option is
-used when building the \*(C+ library.)
-.IP "\fB\-include\fR \fIfile\fR" 4
-.IX Item "-include file"
-Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
-line of the primary source file. However, the first directory searched
-for \fIfile\fR is the preprocessor's working directory \fIinstead of\fR
-the directory containing the main source file. If not found there, it
-is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
-chain as normal.
-.Sp
-If multiple \fB\-include\fR options are given, the files are included
-in the order they appear on the command line.
-.IP "\fB\-imacros\fR \fIfile\fR" 4
-.IX Item "-imacros file"
-Exactly like \fB\-include\fR, except that any output produced by
-scanning \fIfile\fR is thrown away. Macros it defines remain defined.
-This allows you to acquire all the macros from a header without also
-processing its declarations.
-.Sp
-All files specified by \fB\-imacros\fR are processed before all files
-specified by \fB\-include\fR.
-.IP "\fB\-idirafter\fR \fIdir\fR" 4
-.IX Item "-idirafter dir"
-Search \fIdir\fR for header files, but do it \fIafter\fR all
-directories specified with \fB\-I\fR and the standard system directories
-have been exhausted. \fIdir\fR is treated as a system include directory.
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-iprefix\fR \fIprefix\fR" 4
-.IX Item "-iprefix prefix"
-Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
-options. If the prefix represents a directory, you should include the
-final \fB/\fR.
-.IP "\fB\-iwithprefix\fR \fIdir\fR" 4
-.IX Item "-iwithprefix dir"
-.PD 0
-.IP "\fB\-iwithprefixbefore\fR \fIdir\fR" 4
-.IX Item "-iwithprefixbefore dir"
-.PD
-Append \fIdir\fR to the prefix specified previously with
-\&\fB\-iprefix\fR, and add the resulting directory to the include search
-path. \fB\-iwithprefixbefore\fR puts it in the same place \fB\-I\fR
-would; \fB\-iwithprefix\fR puts it where \fB\-idirafter\fR would.
-.IP "\fB\-isysroot\fR \fIdir\fR" 4
-.IX Item "-isysroot dir"
-This option is like the \fB\-\-sysroot\fR option, but applies only to
-header files (except for Darwin targets, where it applies to both header
-files and libraries). See the \fB\-\-sysroot\fR option for more
-information.
-.IP "\fB\-imultilib\fR \fIdir\fR" 4
-.IX Item "-imultilib dir"
-Use \fIdir\fR as a subdirectory of the directory containing
-target-specific \*(C+ headers.
-.IP "\fB\-isystem\fR \fIdir\fR" 4
-.IX Item "-isystem dir"
-Search \fIdir\fR for header files, after all directories specified by
-\&\fB\-I\fR but before the standard system directories. Mark it
-as a system directory, so that it gets the same special treatment as
-is applied to the standard system directories.
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-iquote\fR \fIdir\fR" 4
-.IX Item "-iquote dir"
-Search \fIdir\fR only for header files requested with
-\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
-\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR, before all directories specified by
-\&\fB\-I\fR and before the standard system directories.
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-fdirectives\-only\fR" 4
-.IX Item "-fdirectives-only"
-When preprocessing, handle directives, but do not expand macros.
-.Sp
-The option's behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
-options.
-.Sp
-With \fB\-E\fR, preprocessing is limited to the handling of directives
-such as \f(CW\*(C`#define\*(C'\fR, \f(CW\*(C`#ifdef\*(C'\fR, and \f(CW\*(C`#error\*(C'\fR. Other
-preprocessor operations, such as macro expansion and trigraph
-conversion are not performed. In addition, the \fB\-dD\fR option is
-implicitly enabled.
-.Sp
-With \fB\-fpreprocessed\fR, predefinition of command line and most
-builtin macros is disabled. Macros such as \f(CW\*(C`_\|_LINE_\|_\*(C'\fR, which are
-contextually dependent, are handled normally. This enables compilation of
-files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
-.Sp
-With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
-\&\fB\-fpreprocessed\fR take precedence. This enables full preprocessing of
-files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
-.IP "\fB\-fdollars\-in\-identifiers\fR" 4
-.IX Item "-fdollars-in-identifiers"
-Accept \fB$\fR in identifiers.
-.IP "\fB\-fextended\-identifiers\fR" 4
-.IX Item "-fextended-identifiers"
-Accept universal character names in identifiers. This option is
-experimental; in a future version of \s-1GCC\s0, it will be enabled by
-default for C99 and \*(C+.
-.IP "\fB\-fpreprocessed\fR" 4
-.IX Item "-fpreprocessed"
-Indicate to the preprocessor that the input file has already been
-preprocessed. This suppresses things like macro expansion, trigraph
-conversion, escaped newline splicing, and processing of most directives.
-The preprocessor still recognizes and removes comments, so that you can
-pass a file preprocessed with \fB\-C\fR to the compiler without
-problems. In this mode the integrated preprocessor is little more than
-a tokenizer for the front ends.
-.Sp
-\&\fB\-fpreprocessed\fR is implicit if the input file has one of the
-extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR. These are the
-extensions that \s-1GCC\s0 uses for preprocessed files created by
-\&\fB\-save\-temps\fR.
-.IP "\fB\-ftabstop=\fR\fIwidth\fR" 4
-.IX Item "-ftabstop=width"
-Set the distance between tab stops. This helps the preprocessor report
-correct column numbers in warnings or errors, even if tabs appear on the
-line. If the value is less than 1 or greater than 100, the option is
-ignored. The default is 8.
-.IP "\fB\-fexec\-charset=\fR\fIcharset\fR" 4
-.IX Item "-fexec-charset=charset"
-Set the execution character set, used for string and character
-constants. The default is \s-1UTF\-8\s0. \fIcharset\fR can be any encoding
-supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
-.IP "\fB\-fwide\-exec\-charset=\fR\fIcharset\fR" 4
-.IX Item "-fwide-exec-charset=charset"
-Set the wide execution character set, used for wide string and
-character constants. The default is \s-1UTF\-32\s0 or \s-1UTF\-16\s0, whichever
-corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR. As with
-\&\fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
-by the system's \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
-problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
-.IP "\fB\-finput\-charset=\fR\fIcharset\fR" 4
-.IX Item "-finput-charset=charset"
-Set the input character set, used for translation from the character
-set of the input file to the source character set used by \s-1GCC\s0. If the
-locale does not specify, or \s-1GCC\s0 cannot get this information from the
-locale, the default is \s-1UTF\-8\s0. This can be overridden by either the locale
-or this command line option. Currently the command line option takes
-precedence if there's a conflict. \fIcharset\fR can be any encoding
-supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
-.IP "\fB\-fworking\-directory\fR" 4
-.IX Item "-fworking-directory"
-Enable generation of linemarkers in the preprocessor output that will
-let the compiler know the current working directory at the time of
-preprocessing. When this option is enabled, the preprocessor will
-emit, after the initial linemarker, a second linemarker with the
-current working directory followed by two slashes. \s-1GCC\s0 will use this
-directory, when it's present in the preprocessed input, as the
-directory emitted as the current working directory in some debugging
-information formats. This option is implicitly enabled if debugging
-information is enabled, but this can be inhibited with the negated
-form \fB\-fno\-working\-directory\fR. If the \fB\-P\fR flag is
-present in the command line, this option has no effect, since no
-\&\f(CW\*(C`#line\*(C'\fR directives are emitted whatsoever.
-.IP "\fB\-fno\-show\-column\fR" 4
-.IX Item "-fno-show-column"
-Do not print column numbers in diagnostics. This may be necessary if
-diagnostics are being scanned by a program that does not understand the
-column numbers, such as \fBdejagnu\fR.
-.IP "\fB\-A\fR \fIpredicate\fR\fB=\fR\fIanswer\fR" 4
-.IX Item "-A predicate=answer"
-Make an assertion with the predicate \fIpredicate\fR and answer
-\&\fIanswer\fR. This form is preferred to the older form \fB\-A\fR
-\&\fIpredicate\fR\fB(\fR\fIanswer\fR\fB)\fR, which is still supported, because
-it does not use shell special characters.
-.IP "\fB\-A \-\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4
-.IX Item "-A -predicate=answer"
-Cancel an assertion with the predicate \fIpredicate\fR and answer
-\&\fIanswer\fR.
-.IP "\fB\-dCHARS\fR" 4
-.IX Item "-dCHARS"
-\&\fI\s-1CHARS\s0\fR is a sequence of one or more of the following characters,
-and must not be preceded by a space. Other characters are interpreted
-by the compiler proper, or reserved for future versions of \s-1GCC\s0, and so
-are silently ignored. If you specify characters whose behavior
-conflicts, the result is undefined.
-.RS 4
-.IP "\fBM\fR" 4
-.IX Item "M"
-Instead of the normal output, generate a list of \fB#define\fR
-directives for all the macros defined during the execution of the
-preprocessor, including predefined macros. This gives you a way of
-finding out what is predefined in your version of the preprocessor.
-Assuming you have no file \fIfoo.h\fR, the command
-.Sp
-.Vb 1
-\& touch foo.h; cpp \-dM foo.h
-.Ve
-.Sp
-will show all the predefined macros.
-.Sp
-If you use \fB\-dM\fR without the \fB\-E\fR option, \fB\-dM\fR is
-interpreted as a synonym for \fB\-fdump\-rtl\-mach\fR.
-.IP "\fBD\fR" 4
-.IX Item "D"
-Like \fBM\fR except in two respects: it does \fInot\fR include the
-predefined macros, and it outputs \fIboth\fR the \fB#define\fR
-directives and the result of preprocessing. Both kinds of output go to
-the standard output file.
-.IP "\fBN\fR" 4
-.IX Item "N"
-Like \fBD\fR, but emit only the macro names, not their expansions.
-.IP "\fBI\fR" 4
-.IX Item "I"
-Output \fB#include\fR directives in addition to the result of
-preprocessing.
-.IP "\fBU\fR" 4
-.IX Item "U"
-Like \fBD\fR except that only macros that are expanded, or whose
-definedness is tested in preprocessor directives, are output; the
-output is delayed until the use or test of the macro; and
-\&\fB#undef\fR directives are also output for macros tested but
-undefined at the time.
-.RE
-.RS 4
-.RE
-.IP "\fB\-P\fR" 4
-.IX Item "-P"
-Inhibit generation of linemarkers in the output from the preprocessor.
-This might be useful when running the preprocessor on something that is
-not C code, and will be sent to a program which might be confused by the
-linemarkers.
-.IP "\fB\-C\fR" 4
-.IX Item "-C"
-Do not discard comments. All comments are passed through to the output
-file, except for comments in processed directives, which are deleted
-along with the directive.
-.Sp
-You should be prepared for side effects when using \fB\-C\fR; it
-causes the preprocessor to treat comments as tokens in their own right.
-For example, comments appearing at the start of what would be a
-directive line have the effect of turning that line into an ordinary
-source line, since the first token on the line is no longer a \fB#\fR.
-.IP "\fB\-CC\fR" 4
-.IX Item "-CC"
-Do not discard comments, including during macro expansion. This is
-like \fB\-C\fR, except that comments contained within macros are
-also passed through to the output file where the macro is expanded.
-.Sp
-In addition to the side-effects of the \fB\-C\fR option, the
-\&\fB\-CC\fR option causes all \*(C+\-style comments inside a macro
-to be converted to C\-style comments. This is to prevent later use
-of that macro from inadvertently commenting out the remainder of
-the source line.
-.Sp
-The \fB\-CC\fR option is generally used to support lint comments.
-.IP "\fB\-traditional\-cpp\fR" 4
-.IX Item "-traditional-cpp"
-Try to imitate the behavior of old-fashioned C preprocessors, as
-opposed to \s-1ISO\s0 C preprocessors.
-.IP "\fB\-trigraphs\fR" 4
-.IX Item "-trigraphs"
-Process trigraph sequences.
-These are three-character sequences, all starting with \fB??\fR, that
-are defined by \s-1ISO\s0 C to stand for single characters. For example,
-\&\fB??/\fR stands for \fB\e\fR, so \fB'??/n'\fR is a character
-constant for a newline. By default, \s-1GCC\s0 ignores trigraphs, but in
-standard-conforming modes it converts them. See the \fB\-std\fR and
-\&\fB\-ansi\fR options.
-.Sp
-The nine trigraphs and their replacements are
-.Sp
-.Vb 2
-\& Trigraph: ??( ??) ??< ??> ??= ??/ ??\*(Aq ??! ??\-
-\& Replacement: [ ] { } # \e ^ | ~
-.Ve
-.IP "\fB\-remap\fR" 4
-.IX Item "-remap"
-Enable special code to work around file systems which only permit very
-short file names, such as MS-DOS.
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-.PD 0
-.IP "\fB\-\-target\-help\fR" 4
-.IX Item "--target-help"
-.PD
-Print text describing all the command line options instead of
-preprocessing anything.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-Verbose mode. Print out \s-1GNU\s0 \s-1CPP\s0's version number at the beginning of
-execution, and report the final form of the include path.
-.IP "\fB\-H\fR" 4
-.IX Item "-H"
-Print the name of each header file used, in addition to other normal
-activities. Each name is indented to show how deep in the
-\&\fB#include\fR stack it is. Precompiled header files are also
-printed, even if they are found to be invalid; an invalid precompiled
-header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
-.IP "\fB\-version\fR" 4
-.IX Item "-version"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Print out \s-1GNU\s0 \s-1CPP\s0's version number. With one dash, proceed to
-preprocess as normal. With two dashes, exit immediately.
-.SS "Passing Options to the Assembler"
-.IX Subsection "Passing Options to the Assembler"
-You can pass options to the assembler.
-.IP "\fB\-Wa,\fR\fIoption\fR" 4
-.IX Item "-Wa,option"
-Pass \fIoption\fR as an option to the assembler. If \fIoption\fR
-contains commas, it is split into multiple options at the commas.
-.IP "\fB\-Xassembler\fR \fIoption\fR" 4
-.IX Item "-Xassembler option"
-Pass \fIoption\fR as an option to the assembler. You can use this to
-supply system-specific assembler options which \s-1GCC\s0 does not know how to
-recognize.
-.Sp
-If you want to pass an option that takes an argument, you must use
-\&\fB\-Xassembler\fR twice, once for the option and once for the argument.
-.IP "\fBprofile-generate-sampling-rate\fR" 4
-.IX Item "profile-generate-sampling-rate"
-Set the sampling rate with \fB\-fprofile\-generate\-sampling\fR.
-.SS "Options for Linking"
-.IX Subsection "Options for Linking"
-These options come into play when the compiler links object files into
-an executable output file. They are meaningless if the compiler is
-not doing a link step.
-.IP "\fIobject-file-name\fR" 4
-.IX Item "object-file-name"
-A file name that does not end in a special recognized suffix is
-considered to name an object file or library. (Object files are
-distinguished from libraries by the linker according to the file
-contents.) If linking is done, these object files are used as input
-to the linker.
-.IP "\fB\-c\fR" 4
-.IX Item "-c"
-.PD 0
-.IP "\fB\-S\fR" 4
-.IX Item "-S"
-.IP "\fB\-E\fR" 4
-.IX Item "-E"
-.PD
-If any of these options is used, then the linker is not run, and
-object file names should not be used as arguments.
-.IP "\fB\-l\fR\fIlibrary\fR" 4
-.IX Item "-llibrary"
-.PD 0
-.IP "\fB\-l\fR \fIlibrary\fR" 4
-.IX Item "-l library"
-.PD
-Search the library named \fIlibrary\fR when linking. (The second
-alternative with the library as a separate argument is only for
-\&\s-1POSIX\s0 compliance and is not recommended.)
-.Sp
-It makes a difference where in the command you write this option; the
-linker searches and processes libraries and object files in the order they
-are specified. Thus, \fBfoo.o \-lz bar.o\fR searches library \fBz\fR
-after file \fIfoo.o\fR but before \fIbar.o\fR. If \fIbar.o\fR refers
-to functions in \fBz\fR, those functions may not be loaded.
-.Sp
-The linker searches a standard list of directories for the library,
-which is actually a file named \fIlib\fIlibrary\fI.a\fR. The linker
-then uses this file as if it had been specified precisely by name.
-.Sp
-The directories searched include several standard system directories
-plus any that you specify with \fB\-L\fR.
-.Sp
-Normally the files found this way are library files\-\-\-archive files
-whose members are object files. The linker handles an archive file by
-scanning through it for members which define symbols that have so far
-been referenced but not defined. But if the file that is found is an
-ordinary object file, it is linked in the usual fashion. The only
-difference between using an \fB\-l\fR option and specifying a file name
-is that \fB\-l\fR surrounds \fIlibrary\fR with \fBlib\fR and \fB.a\fR
-and searches several directories.
-.IP "\fB\-lobjc\fR" 4
-.IX Item "-lobjc"
-You need this special case of the \fB\-l\fR option in order to
-link an Objective-C or Objective\-\*(C+ program.
-.IP "\fB\-nostartfiles\fR" 4
-.IX Item "-nostartfiles"
-Do not use the standard system startup files when linking.
-The standard system libraries are used normally, unless \fB\-nostdlib\fR
-or \fB\-nodefaultlibs\fR is used.
-.IP "\fB\-nodefaultlibs\fR" 4
-.IX Item "-nodefaultlibs"
-Do not use the standard system libraries when linking.
-Only the libraries you specify will be passed to the linker, options
-specifying linkage of the system libraries, such as \f(CW\*(C`\-static\-libgcc\*(C'\fR
-or \f(CW\*(C`\-shared\-libgcc\*(C'\fR, will be ignored.
-The standard startup files are used normally, unless \fB\-nostartfiles\fR
-is used. The compiler may generate calls to \f(CW\*(C`memcmp\*(C'\fR,
-\&\f(CW\*(C`memset\*(C'\fR, \f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR.
-These entries are usually resolved by entries in
-libc. These entry points should be supplied through some other
-mechanism when this option is specified.
-.IP "\fB\-nostdlib\fR" 4
-.IX Item "-nostdlib"
-Do not use the standard system startup files or libraries when linking.
-No startup files and only the libraries you specify will be passed to
-the linker, options specifying linkage of the system libraries, such as
-\&\f(CW\*(C`\-static\-libgcc\*(C'\fR or \f(CW\*(C`\-shared\-libgcc\*(C'\fR, will be ignored.
-The compiler may generate calls to \f(CW\*(C`memcmp\*(C'\fR, \f(CW\*(C`memset\*(C'\fR,
-\&\f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR.
-These entries are usually resolved by entries in
-libc. These entry points should be supplied through some other
-mechanism when this option is specified.
-.Sp
-One of the standard libraries bypassed by \fB\-nostdlib\fR and
-\&\fB\-nodefaultlibs\fR is \fIlibgcc.a\fR, a library of internal subroutines
-that \s-1GCC\s0 uses to overcome shortcomings of particular machines, or special
-needs for some languages.
-.Sp
-In most cases, you need \fIlibgcc.a\fR even when you want to avoid
-other standard libraries. In other words, when you specify \fB\-nostdlib\fR
-or \fB\-nodefaultlibs\fR you should usually specify \fB\-lgcc\fR as well.
-This ensures that you have no unresolved references to internal \s-1GCC\s0
-library subroutines. (For example, \fB_\|_main\fR, used to ensure \*(C+
-constructors will be called.)
-.IP "\fB\-pie\fR" 4
-.IX Item "-pie"
-Produce a position independent executable on targets which support it.
-For predictable results, you must also specify the same set of options
-that were used to generate code (\fB\-fpie\fR, \fB\-fPIE\fR,
-or model suboptions) when you specify this option.
-.IP "\fB\-rdynamic\fR" 4
-.IX Item "-rdynamic"
-Pass the flag \fB\-export\-dynamic\fR to the \s-1ELF\s0 linker, on targets
-that support it. This instructs the linker to add all symbols, not
-only used ones, to the dynamic symbol table. This option is needed
-for some uses of \f(CW\*(C`dlopen\*(C'\fR or to allow obtaining backtraces
-from within a program.
-.IP "\fB\-s\fR" 4
-.IX Item "-s"
-Remove all symbol table and relocation information from the executable.
-.IP "\fB\-static\fR" 4
-.IX Item "-static"
-On systems that support dynamic linking, this prevents linking with the shared
-libraries. On other systems, this option has no effect.
-.IP "\fB\-shared\fR" 4
-.IX Item "-shared"
-Produce a shared object which can then be linked with other objects to
-form an executable. Not all systems support this option. For predictable
-results, you must also specify the same set of options that were used to
-generate code (\fB\-fpic\fR, \fB\-fPIC\fR, or model suboptions)
-when you specify this option.[1]
-.IP "\fB\-shared\-libgcc\fR" 4
-.IX Item "-shared-libgcc"
-.PD 0
-.IP "\fB\-static\-libgcc\fR" 4
-.IX Item "-static-libgcc"
-.PD
-On systems that provide \fIlibgcc\fR as a shared library, these options
-force the use of either the shared or static version respectively.
-If no shared version of \fIlibgcc\fR was built when the compiler was
-configured, these options have no effect.
-.Sp
-There are several situations in which an application should use the
-shared \fIlibgcc\fR instead of the static version. The most common
-of these is when the application wishes to throw and catch exceptions
-across different shared libraries. In that case, each of the libraries
-as well as the application itself should use the shared \fIlibgcc\fR.
-.Sp
-Therefore, the G++ and \s-1GCJ\s0 drivers automatically add
-\&\fB\-shared\-libgcc\fR whenever you build a shared library or a main
-executable, because \*(C+ and Java programs typically use exceptions, so
-this is the right thing to do.
-.Sp
-If, instead, you use the \s-1GCC\s0 driver to create shared libraries, you may
-find that they will not always be linked with the shared \fIlibgcc\fR.
-If \s-1GCC\s0 finds, at its configuration time, that you have a non-GNU linker
-or a \s-1GNU\s0 linker that does not support option \fB\-\-eh\-frame\-hdr\fR,
-it will link the shared version of \fIlibgcc\fR into shared libraries
-by default. Otherwise, it will take advantage of the linker and optimize
-away the linking with the shared version of \fIlibgcc\fR, linking with
-the static version of libgcc by default. This allows exceptions to
-propagate through such shared libraries, without incurring relocation
-costs at library load time.
-.Sp
-However, if a library or main executable is supposed to throw or catch
-exceptions, you must link it using the G++ or \s-1GCJ\s0 driver, as appropriate
-for the languages used in the program, or using the option
-\&\fB\-shared\-libgcc\fR, such that it is linked with the shared
-\&\fIlibgcc\fR.
-.IP "\fB\-static\-libstdc++\fR" 4
-.IX Item "-static-libstdc++"
-When the \fBg++\fR program is used to link a \*(C+ program, it will
-normally automatically link against \fBlibstdc++\fR. If
-\&\fIlibstdc++\fR is available as a shared library, and the
-\&\fB\-static\fR option is not used, then this will link against the
-shared version of \fIlibstdc++\fR. That is normally fine. However, it
-is sometimes useful to freeze the version of \fIlibstdc++\fR used by
-the program without going all the way to a fully static link. The
-\&\fB\-static\-libstdc++\fR option directs the \fBg++\fR driver to
-link \fIlibstdc++\fR statically, without necessarily linking other
-libraries statically.
-.IP "\fB\-symbolic\fR" 4
-.IX Item "-symbolic"
-Bind references to global symbols when building a shared object. Warn
-about any unresolved references (unless overridden by the link editor
-option \fB\-Xlinker \-z \-Xlinker defs\fR). Only a few systems support
-this option.
-.IP "\fB\-T\fR \fIscript\fR" 4
-.IX Item "-T script"
-Use \fIscript\fR as the linker script. This option is supported by most
-systems using the \s-1GNU\s0 linker. On some targets, such as bare-board
-targets without an operating system, the \fB\-T\fR option may be required
-when linking to avoid references to undefined symbols.
-.IP "\fB\-Xlinker\fR \fIoption\fR" 4
-.IX Item "-Xlinker option"
-Pass \fIoption\fR as an option to the linker. You can use this to
-supply system-specific linker options which \s-1GCC\s0 does not know how to
-recognize.
-.Sp
-If you want to pass an option that takes a separate argument, you must use
-\&\fB\-Xlinker\fR twice, once for the option and once for the argument.
-For example, to pass \fB\-assert definitions\fR, you must write
-\&\fB\-Xlinker \-assert \-Xlinker definitions\fR. It does not work to write
-\&\fB\-Xlinker \*(L"\-assert definitions\*(R"\fR, because this passes the entire
-string as a single argument, which is not what the linker expects.
-.Sp
-When using the \s-1GNU\s0 linker, it is usually more convenient to pass
-arguments to linker options using the \fIoption\fR\fB=\fR\fIvalue\fR
-syntax than as separate arguments. For example, you can specify
-\&\fB\-Xlinker \-Map=output.map\fR rather than
-\&\fB\-Xlinker \-Map \-Xlinker output.map\fR. Other linkers may not support
-this syntax for command-line options.
-.IP "\fB\-Wl,\fR\fIoption\fR" 4
-.IX Item "-Wl,option"
-Pass \fIoption\fR as an option to the linker. If \fIoption\fR contains
-commas, it is split into multiple options at the commas. You can use this
-syntax to pass an argument to the option.
-For example, \fB\-Wl,\-Map,output.map\fR passes \fB\-Map output.map\fR to the
-linker. When using the \s-1GNU\s0 linker, you can also get the same effect with
-\&\fB\-Wl,\-Map=output.map\fR.
-.IP "\fB\-u\fR \fIsymbol\fR" 4
-.IX Item "-u symbol"
-Pretend the symbol \fIsymbol\fR is undefined, to force linking of
-library modules to define it. You can use \fB\-u\fR multiple times with
-different symbols to force loading of additional library modules.
-.SS "Options for Directory Search"
-.IX Subsection "Options for Directory Search"
-These options specify directories to search for header files, for
-libraries and for parts of the compiler:
-.IP "\fB\-I\fR\fIdir\fR" 4
-.IX Item "-Idir"
-Add the directory \fIdir\fR to the head of the list of directories to be
-searched for header files. This can be used to override a system header
-file, substituting your own version, since these directories are
-searched before the system header file directories. However, you should
-not use this option to add directories that contain vendor-supplied
-system header files (use \fB\-isystem\fR for that). If you use more than
-one \fB\-I\fR option, the directories are scanned in left-to-right
-order; the standard system directories come after.
-.Sp
-If a standard system include directory, or a directory specified with
-\&\fB\-isystem\fR, is also specified with \fB\-I\fR, the \fB\-I\fR
-option will be ignored. The directory will still be searched but as a
-system directory at its normal position in the system include chain.
-This is to ensure that \s-1GCC\s0's procedure to fix buggy system headers and
-the ordering for the include_next directive are not inadvertently changed.
-If you really need to change the search order for system directories,
-use the \fB\-nostdinc\fR and/or \fB\-isystem\fR options.
-.IP "\fB\-iplugindir=\fR\fIdir\fR" 4
-.IX Item "-iplugindir=dir"
-Set the directory to search for plugins which are passed
-by \fB\-fplugin=\fR\fIname\fR instead of
-\&\fB\-fplugin=\fR\fIpath\fR\fB/\fR\fIname\fR\fB.so\fR. This option is not meant
-to be used by the user, but only passed by the driver.
-.IP "\fB\-iquote\fR\fIdir\fR" 4
-.IX Item "-iquotedir"
-Add the directory \fIdir\fR to the head of the list of directories to
-be searched for header files only for the case of \fB#include
-"\fR\fIfile\fR\fB"\fR; they are not searched for \fB#include <\fR\fIfile\fR\fB>\fR,
-otherwise just like \fB\-I\fR.
-.IP "\fB\-L\fR\fIdir\fR" 4
-.IX Item "-Ldir"
-Add directory \fIdir\fR to the list of directories to be searched
-for \fB\-l\fR.
-.IP "\fB\-B\fR\fIprefix\fR" 4
-.IX Item "-Bprefix"
-This option specifies where to find the executables, libraries,
-include files, and data files of the compiler itself.
-.Sp
-The compiler driver program runs one or more of the subprograms
-\&\fIcpp\fR, \fIcc1\fR, \fIas\fR and \fIld\fR. It tries
-\&\fIprefix\fR as a prefix for each program it tries to run, both with and
-without \fImachine\fR\fB/\fR\fIversion\fR\fB/\fR.
-.Sp
-For each subprogram to be run, the compiler driver first tries the
-\&\fB\-B\fR prefix, if any. If that name is not found, or if \fB\-B\fR
-was not specified, the driver tries two standard prefixes, which are
-\&\fI/usr/lib/gcc/\fR and \fI/usr/local/lib/gcc/\fR. If neither of
-those results in a file name that is found, the unmodified program
-name is searched for using the directories specified in your
-\&\fB\s-1PATH\s0\fR environment variable.
-.Sp
-The compiler will check to see if the path provided by the \fB\-B\fR
-refers to a directory, and if necessary it will add a directory
-separator character at the end of the path.
-.Sp
-\&\fB\-B\fR prefixes that effectively specify directory names also apply
-to libraries in the linker, because the compiler translates these
-options into \fB\-L\fR options for the linker. They also apply to
-includes files in the preprocessor, because the compiler translates these
-options into \fB\-isystem\fR options for the preprocessor. In this case,
-the compiler appends \fBinclude\fR to the prefix.
-.Sp
-The run-time support file \fIlibgcc.a\fR can also be searched for using
-the \fB\-B\fR prefix, if needed. If it is not found there, the two
-standard prefixes above are tried, and that is all. The file is left
-out of the link if it is not found by those means.
-.Sp
-Another way to specify a prefix much like the \fB\-B\fR prefix is to use
-the environment variable \fB\s-1GCC_EXEC_PREFIX\s0\fR.
-.Sp
-As a special kludge, if the path provided by \fB\-B\fR is
-\&\fI[dir/]stage\fIN\fI/\fR, where \fIN\fR is a number in the range 0 to
-9, then it will be replaced by \fI[dir/]include\fR. This is to help
-with boot-strapping the compiler.
-.IP "\fB\-specs=\fR\fIfile\fR" 4
-.IX Item "-specs=file"
-Process \fIfile\fR after the compiler reads in the standard \fIspecs\fR
-file, in order to override the defaults that the \fIgcc\fR driver
-program uses when determining what switches to pass to \fIcc1\fR,
-\&\fIcc1plus\fR, \fIas\fR, \fIld\fR, etc. More than one
-\&\fB\-specs=\fR\fIfile\fR can be specified on the command line, and they
-are processed in order, from left to right.
-.IP "\fB\-\-sysroot=\fR\fIdir\fR" 4
-.IX Item "--sysroot=dir"
-Use \fIdir\fR as the logical root directory for headers and libraries.
-For example, if the compiler would normally search for headers in
-\&\fI/usr/include\fR and libraries in \fI/usr/lib\fR, it will instead
-search \fI\fIdir\fI/usr/include\fR and \fI\fIdir\fI/usr/lib\fR.
-.Sp
-If you use both this option and the \fB\-isysroot\fR option, then
-the \fB\-\-sysroot\fR option will apply to libraries, but the
-\&\fB\-isysroot\fR option will apply to header files.
-.Sp
-The \s-1GNU\s0 linker (beginning with version 2.16) has the necessary support
-for this option. If your linker does not support this option, the
-header file aspect of \fB\-\-sysroot\fR will still work, but the
-library aspect will not.
-.IP "\fB\-I\-\fR" 4
-.IX Item "-I-"
-This option has been deprecated. Please use \fB\-iquote\fR instead for
-\&\fB\-I\fR directories before the \fB\-I\-\fR and remove the \fB\-I\-\fR.
-Any directories you specify with \fB\-I\fR options before the \fB\-I\-\fR
-option are searched only for the case of \fB#include "\fR\fIfile\fR\fB"\fR;
-they are not searched for \fB#include <\fR\fIfile\fR\fB>\fR.
-.Sp
-If additional directories are specified with \fB\-I\fR options after
-the \fB\-I\-\fR, these directories are searched for all \fB#include\fR
-directives. (Ordinarily \fIall\fR \fB\-I\fR directories are used
-this way.)
-.Sp
-In addition, the \fB\-I\-\fR option inhibits the use of the current
-directory (where the current input file came from) as the first search
-directory for \fB#include "\fR\fIfile\fR\fB"\fR. There is no way to
-override this effect of \fB\-I\-\fR. With \fB\-I.\fR you can specify
-searching the directory which was current when the compiler was
-invoked. That is not exactly the same as what the preprocessor does
-by default, but it is often satisfactory.
-.Sp
-\&\fB\-I\-\fR does not inhibit the use of the standard system directories
-for header files. Thus, \fB\-I\-\fR and \fB\-nostdinc\fR are
-independent.
-.SS "Specifying Target Machine and Compiler Version"
-.IX Subsection "Specifying Target Machine and Compiler Version"
-The usual way to run \s-1GCC\s0 is to run the executable called \fBgcc\fR, or
-\&\fImachine\fR\fB\-gcc\fR when cross-compiling, or
-\&\fImachine\fR\fB\-gcc\-\fR\fIversion\fR to run a version other than the
-one that was installed last.
-.SS "Hardware Models and Configurations"
-.IX Subsection "Hardware Models and Configurations"
-Each target machine types can have its own
-special options, starting with \fB\-m\fR, to choose among various
-hardware models or configurations\-\-\-for example, 68010 vs 68020,
-floating coprocessor or none. A single installed version of the
-compiler can compile for any model or configuration, according to the
-options specified.
-.PP
-Some configurations of the compiler also support additional special
-options, usually for compatibility with other compilers on the same
-platform.
-.PP
-\fI\s-1ARC\s0 Options\fR
-.IX Subsection "ARC Options"
-.PP
-These options are defined for \s-1ARC\s0 implementations:
-.IP "\fB\-EL\fR" 4
-.IX Item "-EL"
-Compile code for little endian mode. This is the default.
-.IP "\fB\-EB\fR" 4
-.IX Item "-EB"
-Compile code for big endian mode.
-.IP "\fB\-mmangle\-cpu\fR" 4
-.IX Item "-mmangle-cpu"
-Prepend the name of the \s-1CPU\s0 to all public symbol names.
-In multiple-processor systems, there are many \s-1ARC\s0 variants with different
-instruction and register set characteristics. This flag prevents code
-compiled for one \s-1CPU\s0 to be linked with code compiled for another.
-No facility exists for handling variants that are \*(L"almost identical\*(R".
-This is an all or nothing option.
-.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
-.IX Item "-mcpu=cpu"
-Compile code for \s-1ARC\s0 variant \fIcpu\fR.
-Which variants are supported depend on the configuration.
-All variants support \fB\-mcpu=base\fR, this is the default.
-.IP "\fB\-mtext=\fR\fItext-section\fR" 4
-.IX Item "-mtext=text-section"
-.PD 0
-.IP "\fB\-mdata=\fR\fIdata-section\fR" 4
-.IX Item "-mdata=data-section"
-.IP "\fB\-mrodata=\fR\fIreadonly-data-section\fR" 4
-.IX Item "-mrodata=readonly-data-section"
-.PD
-Put functions, data, and readonly data in \fItext-section\fR,
-\&\fIdata-section\fR, and \fIreadonly-data-section\fR respectively
-by default. This can be overridden with the \f(CW\*(C`section\*(C'\fR attribute.
-.PP
-\fI\s-1ARM\s0 Options\fR
-.IX Subsection "ARM Options"
-.PP
-These \fB\-m\fR options are defined for Advanced \s-1RISC\s0 Machines (\s-1ARM\s0)
-architectures:
-.IP "\fB\-mabi=\fR\fIname\fR" 4
-.IX Item "-mabi=name"
-Generate code for the specified \s-1ABI\s0. Permissible values are: \fBapcs-gnu\fR,
-\&\fBatpcs\fR, \fBaapcs\fR, \fBaapcs-linux\fR and \fBiwmmxt\fR.
-.IP "\fB\-mapcs\-frame\fR" 4
-.IX Item "-mapcs-frame"
-Generate a stack frame that is compliant with the \s-1ARM\s0 Procedure Call
-Standard for all functions, even if this is not strictly necessary for
-correct execution of the code. Specifying \fB\-fomit\-frame\-pointer\fR
-with this option will cause the stack frames not to be generated for
-leaf functions. The default is \fB\-mno\-apcs\-frame\fR.
-.IP "\fB\-mapcs\fR" 4
-.IX Item "-mapcs"
-This is a synonym for \fB\-mapcs\-frame\fR.
-.IP "\fB\-mthumb\-interwork\fR" 4
-.IX Item "-mthumb-interwork"
-Generate code which supports calling between the \s-1ARM\s0 and Thumb
-instruction sets. Without this option the two instruction sets cannot
-be reliably used inside one program. The default is
-\&\fB\-mno\-thumb\-interwork\fR, since slightly larger code is generated
-when \fB\-mthumb\-interwork\fR is specified.
-.IP "\fB\-mno\-sched\-prolog\fR" 4
-.IX Item "-mno-sched-prolog"
-Prevent the reordering of instructions in the function prolog, or the
-merging of those instruction with the instructions in the function's
-body. This means that all functions will start with a recognizable set
-of instructions (or in fact one of a choice from a small set of
-different function prologues), and this information can be used to
-locate the start if functions inside an executable piece of code. The
-default is \fB\-msched\-prolog\fR.
-.IP "\fB\-mfloat\-abi=\fR\fIname\fR" 4
-.IX Item "-mfloat-abi=name"
-Specifies which floating-point \s-1ABI\s0 to use. Permissible values
-are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
-.Sp
-Specifying \fBsoft\fR causes \s-1GCC\s0 to generate output containing
-library calls for floating-point operations.
-\&\fBsoftfp\fR allows the generation of code using hardware floating-point
-instructions, but still uses the soft-float calling conventions.
-\&\fBhard\fR allows generation of floating-point instructions
-and uses FPU-specific calling conventions.
-.Sp
-The default depends on the specific target configuration. Note that
-the hard-float and soft-float ABIs are not link-compatible; you must
-compile your entire program with the same \s-1ABI\s0, and link with a
-compatible set of libraries.
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-Equivalent to \fB\-mfloat\-abi=hard\fR.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Equivalent to \fB\-mfloat\-abi=soft\fR.
-.IP "\fB\-mlittle\-endian\fR" 4
-.IX Item "-mlittle-endian"
-Generate code for a processor running in little-endian mode. This is
-the default for all standard configurations.
-.IP "\fB\-mbig\-endian\fR" 4
-.IX Item "-mbig-endian"
-Generate code for a processor running in big-endian mode; the default is
-to compile code for a little-endian processor.
-.IP "\fB\-mwords\-little\-endian\fR" 4
-.IX Item "-mwords-little-endian"
-This option only applies when generating code for big-endian processors.
-Generate code for a little-endian word order but a big-endian byte
-order. That is, a byte order of the form \fB32107654\fR. Note: this
-option should only be used if you require compatibility with code for
-big-endian \s-1ARM\s0 processors generated by versions of the compiler prior to
-2.8.
-.IP "\fB\-mcpu=\fR\fIname\fR" 4
-.IX Item "-mcpu=name"
-This specifies the name of the target \s-1ARM\s0 processor. \s-1GCC\s0 uses this name
-to determine what kind of instructions it can emit when generating
-assembly code. Permissible names are: \fBarm2\fR, \fBarm250\fR,
-\&\fBarm3\fR, \fBarm6\fR, \fBarm60\fR, \fBarm600\fR, \fBarm610\fR,
-\&\fBarm620\fR, \fBarm7\fR, \fBarm7m\fR, \fBarm7d\fR, \fBarm7dm\fR,
-\&\fBarm7di\fR, \fBarm7dmi\fR, \fBarm70\fR, \fBarm700\fR,
-\&\fBarm700i\fR, \fBarm710\fR, \fBarm710c\fR, \fBarm7100\fR,
-\&\fBarm720\fR,
-\&\fBarm7500\fR, \fBarm7500fe\fR, \fBarm7tdmi\fR, \fBarm7tdmi\-s\fR,
-\&\fBarm710t\fR, \fBarm720t\fR, \fBarm740t\fR,
-\&\fBstrongarm\fR, \fBstrongarm110\fR, \fBstrongarm1100\fR,
-\&\fBstrongarm1110\fR,
-\&\fBarm8\fR, \fBarm810\fR, \fBarm9\fR, \fBarm9e\fR, \fBarm920\fR,
-\&\fBarm920t\fR, \fBarm922t\fR, \fBarm946e\-s\fR, \fBarm966e\-s\fR,
-\&\fBarm968e\-s\fR, \fBarm926ej\-s\fR, \fBarm940t\fR, \fBarm9tdmi\fR,
-\&\fBarm10tdmi\fR, \fBarm1020t\fR, \fBarm1026ej\-s\fR,
-\&\fBarm10e\fR, \fBarm1020e\fR, \fBarm1022e\fR,
-\&\fBarm1136j\-s\fR, \fBarm1136jf\-s\fR, \fBmpcore\fR, \fBmpcorenovfp\fR,
-\&\fBarm1156t2\-s\fR, \fBarm1156t2f\-s\fR, \fBarm1176jz\-s\fR, \fBarm1176jzf\-s\fR,
-\&\fBcortex\-a5\fR, \fBcortex\-a8\fR, \fBcortex\-a9\fR, \fBcortex\-a15\fR,
-\&\fBcortex\-r4\fR, \fBcortex\-r4f\fR, \fBcortex\-m4\fR, \fBcortex\-m3\fR,
-\&\fBcortex\-m1\fR,
-\&\fBcortex\-m0\fR,
-\&\fBxscale\fR, \fBiwmmxt\fR, \fBiwmmxt2\fR, \fBep9312\fR.
-.IP "\fB\-mtune=\fR\fIname\fR" 4
-.IX Item "-mtune=name"
-This option is very similar to the \fB\-mcpu=\fR option, except that
-instead of specifying the actual target processor type, and hence
-restricting which instructions can be used, it specifies that \s-1GCC\s0 should
-tune the performance of the code as if the target were of the type
-specified in this option, but still choosing the instructions that it
-will generate based on the \s-1CPU\s0 specified by a \fB\-mcpu=\fR option.
-For some \s-1ARM\s0 implementations better performance can be obtained by using
-this option.
-.IP "\fB\-march=\fR\fIname\fR" 4
-.IX Item "-march=name"
-This specifies the name of the target \s-1ARM\s0 architecture. \s-1GCC\s0 uses this
-name to determine what kind of instructions it can emit when generating
-assembly code. This option can be used in conjunction with or instead
-of the \fB\-mcpu=\fR option. Permissible names are: \fBarmv2\fR,
-\&\fBarmv2a\fR, \fBarmv3\fR, \fBarmv3m\fR, \fBarmv4\fR, \fBarmv4t\fR,
-\&\fBarmv5\fR, \fBarmv5t\fR, \fBarmv5e\fR, \fBarmv5te\fR,
-\&\fBarmv6\fR, \fBarmv6j\fR,
-\&\fBarmv6t2\fR, \fBarmv6z\fR, \fBarmv6zk\fR, \fBarmv6\-m\fR,
-\&\fBarmv7\fR, \fBarmv7\-a\fR, \fBarmv7\-r\fR, \fBarmv7\-m\fR,
-\&\fBiwmmxt\fR, \fBiwmmxt2\fR, \fBep9312\fR.
-.IP "\fB\-mfpu=\fR\fIname\fR" 4
-.IX Item "-mfpu=name"
-.PD 0
-.IP "\fB\-mfpe=\fR\fInumber\fR" 4
-.IX Item "-mfpe=number"
-.IP "\fB\-mfp=\fR\fInumber\fR" 4
-.IX Item "-mfp=number"
-.PD
-This specifies what floating point hardware (or hardware emulation) is
-available on the target. Permissible names are: \fBfpa\fR, \fBfpe2\fR,
-\&\fBfpe3\fR, \fBmaverick\fR, \fBvfp\fR, \fBvfpv3\fR, \fBvfpv3\-fp16\fR,
-\&\fBvfpv3\-d16\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3xd\fR, \fBvfpv3xd\-fp16\fR,
-\&\fBneon\fR, \fBneon\-fp16\fR, \fBvfpv4\fR, \fBvfpv4\-d16\fR,
-\&\fBfpv4\-sp\-d16\fR and \fBneon\-vfpv4\fR.
-\&\fB\-mfp\fR and \fB\-mfpe\fR are synonyms for
-\&\fB\-mfpu\fR=\fBfpe\fR\fInumber\fR, for compatibility with older versions
-of \s-1GCC\s0.
-.Sp
-If \fB\-msoft\-float\fR is specified this specifies the format of
-floating point values.
-.Sp
-If the selected floating-point hardware includes the \s-1NEON\s0 extension
-(e.g. \fB\-mfpu\fR=\fBneon\fR), note that floating-point
-operations will not be used by \s-1GCC\s0's auto-vectorization pass unless
-\&\fB\-funsafe\-math\-optimizations\fR is also specified. This is
-because \s-1NEON\s0 hardware does not fully implement the \s-1IEEE\s0 754 standard for
-floating-point arithmetic (in particular denormal values are treated as
-zero), so the use of \s-1NEON\s0 instructions may lead to a loss of precision.
-.IP "\fB\-mfp16\-format=\fR\fIname\fR" 4
-.IX Item "-mfp16-format=name"
-Specify the format of the \f(CW\*(C`_\|_fp16\*(C'\fR half-precision floating-point type.
-Permissible names are \fBnone\fR, \fBieee\fR, and \fBalternative\fR;
-the default is \fBnone\fR, in which case the \f(CW\*(C`_\|_fp16\*(C'\fR type is not
-defined.
-.IP "\fB\-mstructure\-size\-boundary=\fR\fIn\fR" 4
-.IX Item "-mstructure-size-boundary=n"
-The size of all structures and unions will be rounded up to a multiple
-of the number of bits set by this option. Permissible values are 8, 32
-and 64. The default value varies for different toolchains. For the \s-1COFF\s0
-targeted toolchain the default value is 8. A value of 64 is only allowed
-if the underlying \s-1ABI\s0 supports it.
-.Sp
-Specifying the larger number can produce faster, more efficient code, but
-can also increase the size of the program. Different values are potentially
-incompatible. Code compiled with one value cannot necessarily expect to
-work with code or libraries compiled with another value, if they exchange
-information using structures or unions.
-.IP "\fB\-mabort\-on\-noreturn\fR" 4
-.IX Item "-mabort-on-noreturn"
-Generate a call to the function \f(CW\*(C`abort\*(C'\fR at the end of a
-\&\f(CW\*(C`noreturn\*(C'\fR function. It will be executed if the function tries to
-return.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-.PD 0
-.IP "\fB\-mno\-long\-calls\fR" 4
-.IX Item "-mno-long-calls"
-.PD
-Tells the compiler to perform function calls by first loading the
-address of the function into a register and then performing a subroutine
-call on this register. This switch is needed if the target function
-will lie outside of the 64 megabyte addressing range of the offset based
-version of subroutine call instruction.
-.Sp
-Even if this switch is enabled, not all function calls will be turned
-into long calls. The heuristic is that static functions, functions
-which have the \fBshort-call\fR attribute, functions that are inside
-the scope of a \fB#pragma no_long_calls\fR directive and functions whose
-definitions have already been compiled within the current compilation
-unit, will not be turned into long calls. The exception to this rule is
-that weak function definitions, functions with the \fBlong-call\fR
-attribute or the \fBsection\fR attribute, and functions that are within
-the scope of a \fB#pragma long_calls\fR directive, will always be
-turned into long calls.
-.Sp
-This feature is not enabled by default. Specifying
-\&\fB\-mno\-long\-calls\fR will restore the default behavior, as will
-placing the function calls within the scope of a \fB#pragma
-long_calls_off\fR directive. Note these switches have no effect on how
-the compiler generates code to handle function calls via function
-pointers.
-.IP "\fB\-msingle\-pic\-base\fR" 4
-.IX Item "-msingle-pic-base"
-Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
-loading it in the prologue for each function. The run-time system is
-responsible for initializing this register with an appropriate value
-before execution begins.
-.IP "\fB\-mpic\-register=\fR\fIreg\fR" 4
-.IX Item "-mpic-register=reg"
-Specify the register to be used for \s-1PIC\s0 addressing. The default is R10
-unless stack-checking is enabled, when R9 is used.
-.IP "\fB\-mcirrus\-fix\-invalid\-insns\fR" 4
-.IX Item "-mcirrus-fix-invalid-insns"
-Insert NOPs into the instruction stream to in order to work around
-problems with invalid Maverick instruction combinations. This option
-is only valid if the \fB\-mcpu=ep9312\fR option has been used to
-enable generation of instructions for the Cirrus Maverick floating
-point co-processor. This option is not enabled by default, since the
-problem is only present in older Maverick implementations. The default
-can be re-enabled by use of the \fB\-mno\-cirrus\-fix\-invalid\-insns\fR
-switch.
-.IP "\fB\-mpoke\-function\-name\fR" 4
-.IX Item "-mpoke-function-name"
-Write the name of each function into the text section, directly
-preceding the function prologue. The generated code is similar to this:
-.Sp
-.Vb 9
-\& t0
-\& .ascii "arm_poke_function_name", 0
-\& .align
-\& t1
-\& .word 0xff000000 + (t1 \- t0)
-\& arm_poke_function_name
-\& mov ip, sp
-\& stmfd sp!, {fp, ip, lr, pc}
-\& sub fp, ip, #4
-.Ve
-.Sp
-When performing a stack backtrace, code can inspect the value of
-\&\f(CW\*(C`pc\*(C'\fR stored at \f(CW\*(C`fp + 0\*(C'\fR. If the trace function then looks at
-location \f(CW\*(C`pc \- 12\*(C'\fR and the top 8 bits are set, then we know that
-there is a function name embedded immediately preceding this location
-and has length \f(CW\*(C`((pc[\-3]) & 0xff000000)\*(C'\fR.
-.IP "\fB\-mthumb\fR" 4
-.IX Item "-mthumb"
-Generate code for the Thumb instruction set. The default is to
-use the 32\-bit \s-1ARM\s0 instruction set.
-This option automatically enables either 16\-bit Thumb\-1 or
-mixed 16/32\-bit Thumb\-2 instructions based on the \fB\-mcpu=\fR\fIname\fR
-and \fB\-march=\fR\fIname\fR options. This option is not passed to the
-assembler. If you want to force assembler files to be interpreted as Thumb code,
-either add a \fB.thumb\fR directive to the source or pass the \fB\-mthumb\fR
-option directly to the assembler by prefixing it with \fB\-Wa\fR.
-.IP "\fB\-mtpcs\-frame\fR" 4
-.IX Item "-mtpcs-frame"
-Generate a stack frame that is compliant with the Thumb Procedure Call
-Standard for all non-leaf functions. (A leaf function is one that does
-not call any other functions.) The default is \fB\-mno\-tpcs\-frame\fR.
-.IP "\fB\-mtpcs\-leaf\-frame\fR" 4
-.IX Item "-mtpcs-leaf-frame"
-Generate a stack frame that is compliant with the Thumb Procedure Call
-Standard for all leaf functions. (A leaf function is one that does
-not call any other functions.) The default is \fB\-mno\-apcs\-leaf\-frame\fR.
-.IP "\fB\-mcallee\-super\-interworking\fR" 4
-.IX Item "-mcallee-super-interworking"
-Gives all externally visible functions in the file being compiled an \s-1ARM\s0
-instruction set header which switches to Thumb mode before executing the
-rest of the function. This allows these functions to be called from
-non-interworking code. This option is not valid in \s-1AAPCS\s0 configurations
-because interworking is enabled by default.
-.IP "\fB\-mcaller\-super\-interworking\fR" 4
-.IX Item "-mcaller-super-interworking"
-Allows calls via function pointers (including virtual functions) to
-execute correctly regardless of whether the target code has been
-compiled for interworking or not. There is a small overhead in the cost
-of executing a function pointer if this option is enabled. This option
-is not valid in \s-1AAPCS\s0 configurations because interworking is enabled
-by default.
-.IP "\fB\-mtp=\fR\fIname\fR" 4
-.IX Item "-mtp=name"
-Specify the access model for the thread local storage pointer. The valid
-models are \fBsoft\fR, which generates calls to \f(CW\*(C`_\|_aeabi_read_tp\*(C'\fR,
-\&\fBcp15\fR, which fetches the thread pointer from \f(CW\*(C`cp15\*(C'\fR directly
-(supported in the arm6k architecture), and \fBauto\fR, which uses the
-best available method for the selected processor. The default setting is
-\&\fBauto\fR.
-.IP "\fB\-mword\-relocations\fR" 4
-.IX Item "-mword-relocations"
-Only generate absolute relocations on word sized values (i.e. R_ARM_ABS32).
-This is enabled by default on targets (uClinux, SymbianOS) where the runtime
-loader imposes this restriction, and when \fB\-fpic\fR or \fB\-fPIC\fR
-is specified.
-.IP "\fB\-mfix\-cortex\-m3\-ldrd\fR" 4
-.IX Item "-mfix-cortex-m3-ldrd"
-Some Cortex\-M3 cores can cause data corruption when \f(CW\*(C`ldrd\*(C'\fR instructions
-with overlapping destination and base registers are used. This option avoids
-generating these instructions. This option is enabled by default when
-\&\fB\-mcpu=cortex\-m3\fR is specified.
-.PP
-\fI\s-1AVR\s0 Options\fR
-.IX Subsection "AVR Options"
-.PP
-These options are defined for \s-1AVR\s0 implementations:
-.IP "\fB\-mmcu=\fR\fImcu\fR" 4
-.IX Item "-mmcu=mcu"
-Specify \s-1ATMEL\s0 \s-1AVR\s0 instruction set or \s-1MCU\s0 type.
-.Sp
-Instruction set avr1 is for the minimal \s-1AVR\s0 core, not supported by the C
-compiler, only for assembler programs (\s-1MCU\s0 types: at90s1200, attiny10,
-attiny11, attiny12, attiny15, attiny28).
-.Sp
-Instruction set avr2 (default) is for the classic \s-1AVR\s0 core with up to
-8K program memory space (\s-1MCU\s0 types: at90s2313, at90s2323, attiny22,
-at90s2333, at90s2343, at90s4414, at90s4433, at90s4434, at90s8515,
-at90c8534, at90s8535).
-.Sp
-Instruction set avr3 is for the classic \s-1AVR\s0 core with up to 128K program
-memory space (\s-1MCU\s0 types: atmega103, atmega603, at43usb320, at76c711).
-.Sp
-Instruction set avr4 is for the enhanced \s-1AVR\s0 core with up to 8K program
-memory space (\s-1MCU\s0 types: atmega8, atmega83, atmega85).
-.Sp
-Instruction set avr5 is for the enhanced \s-1AVR\s0 core with up to 128K program
-memory space (\s-1MCU\s0 types: atmega16, atmega161, atmega163, atmega32, atmega323,
-atmega64, atmega128, at43usb355, at94k).
-.IP "\fB\-mno\-interrupts\fR" 4
-.IX Item "-mno-interrupts"
-Generated code is not compatible with hardware interrupts.
-Code size will be smaller.
-.IP "\fB\-mcall\-prologues\fR" 4
-.IX Item "-mcall-prologues"
-Functions prologues/epilogues expanded as call to appropriate
-subroutines. Code size will be smaller.
-.IP "\fB\-mtiny\-stack\fR" 4
-.IX Item "-mtiny-stack"
-Change only the low 8 bits of the stack pointer.
-.IP "\fB\-mint8\fR" 4
-.IX Item "-mint8"
-Assume int to be 8 bit integer. This affects the sizes of all types: A
-char will be 1 byte, an int will be 1 byte, a long will be 2 bytes
-and long long will be 4 bytes. Please note that this option does not
-comply to the C standards, but it will provide you with smaller code
-size.
-.PP
-\f(CW\*(C`EIND\*(C'\fR and Devices with more than 128k Bytes of Flash
-.IX Subsection "EIND and Devices with more than 128k Bytes of Flash"
-.PP
-Pointers in the implementation are 16 bits wide.
-The address of a function or label is represented as word address so
-that indirect jumps and calls can address any code address in the
-range of 64k words.
-.PP
-In order to faciliate indirect jump on devices with more than 128k
-bytes of program memory space, there is a special function register called
-\&\f(CW\*(C`EIND\*(C'\fR that serves as most significant part of the target address
-when \f(CW\*(C`EICALL\*(C'\fR or \f(CW\*(C`EIJMP\*(C'\fR instructions are used.
-.PP
-Indirect jumps and calls on these devices are handled as follows and
-are subject to some limitations:
-.IP "\(bu" 4
-The compiler never sets \f(CW\*(C`EIND\*(C'\fR.
-.IP "\(bu" 4
-The startup code from libgcc never sets \f(CW\*(C`EIND\*(C'\fR.
-Notice that startup code is a blend of code from libgcc and avr-libc.
-For the impact of avr-libc on \f(CW\*(C`EIND\*(C'\fR, see the
-avr-libc\ user\ manual (\f(CW\*(C`http://nongnu.org/avr\-libc/user\-manual\*(C'\fR).
-.IP "\(bu" 4
-The compiler uses \f(CW\*(C`EIND\*(C'\fR implicitely in \f(CW\*(C`EICALL\*(C'\fR/\f(CW\*(C`EIJMP\*(C'\fR
-instructions or might read \f(CW\*(C`EIND\*(C'\fR directly.
-.IP "\(bu" 4
-The compiler assumes that \f(CW\*(C`EIND\*(C'\fR never changes during the startup
-code or run of the application. In particular, \f(CW\*(C`EIND\*(C'\fR is not
-saved/restored in function or interrupt service routine
-prologue/epilogue.
-.IP "\(bu" 4
-It is legitimate for user-specific startup code to set up \f(CW\*(C`EIND\*(C'\fR
-early, for example by means of initialization code located in
-section \f(CW\*(C`.init3\*(C'\fR, and thus prior to general startup code that
-initializes \s-1RAM\s0 and calls constructors.
-.IP "\(bu" 4
-For indirect calls to functions and computed goto, the linker will
-generate \fIstubs\fR. Stubs are jump pads sometimes also called
-\&\fItrampolines\fR. Thus, the indirect call/jump will jump to such a stub.
-The stub contains a direct jump to the desired address.
-.IP "\(bu" 4
-Stubs will be generated automatically by the linker if
-the following two conditions are met:
-.RS 4
-.ie n .IP "\-<The address of a label is taken by means of the ""gs"" modifier>" 4
-.el .IP "\-<The address of a label is taken by means of the \f(CWgs\fR modifier>" 4
-.IX Item "-<The address of a label is taken by means of the gs modifier>"
-(short for \fIgenerate stubs\fR) like so:
-.Sp
-.Vb 2
-\& LDI r24, lo8(gs(<func>))
-\& LDI r25, hi8(gs(<func>))
-.Ve
-.IP "\-<The final location of that label is in a code segment>" 4
-.IX Item "-<The final location of that label is in a code segment>"
-\&\fIoutside\fR the segment where the stubs are located.
-.RE
-.RS 4
-.RE
-.IP "\(bu" 4
-The compiler will emit such \f(CW\*(C`gs\*(C'\fR modifiers for code labels in the
-following situations:
-.RS 4
-.IP "\-<Taking address of a function or code label.>" 4
-.IX Item "-<Taking address of a function or code label.>"
-.PD 0
-.IP "\-<Computed goto.>" 4
-.IX Item "-<Computed goto.>"
-.IP "\-<If prologue-save function is used, see \fB\-mcall\-prologues\fR>" 4
-.IX Item "-<If prologue-save function is used, see -mcall-prologues>"
-.PD
-command line option.
-.IP "\-<Switch/case dispatch tables. If you do not want such dispatch>" 4
-.IX Item "-<Switch/case dispatch tables. If you do not want such dispatch>"
-tables you can specify the \fB\-fno\-jump\-tables\fR command line option.
-.IP "\-<C and \*(C+ constructors/destructors called during startup/shutdown.>" 4
-.IX Item "-<C and constructors/destructors called during startup/shutdown.>"
-.PD 0
-.ie n .IP "\-<If the tools hit a ""gs()"" modifier explained above.>" 4
-.el .IP "\-<If the tools hit a \f(CWgs()\fR modifier explained above.>" 4
-.IX Item "-<If the tools hit a gs() modifier explained above.>"
-.RE
-.RS 4
-.RE
-.IP "\(bu" 4
-.PD
-The default linker script is arranged for code with \f(CW\*(C`EIND = 0\*(C'\fR.
-If code is supposed to work for a setup with \f(CW\*(C`EIND != 0\*(C'\fR, a custom
-linker script has to be used in order to place the sections whose
-name start with \f(CW\*(C`.trampolines\*(C'\fR into the segment where \f(CW\*(C`EIND\*(C'\fR
-points to.
-.IP "\(bu" 4
-Jumping to non-symbolic addresses like so is \fInot\fR supported:
-.Sp
-.Vb 5
-\& int main (void)
-\& {
-\& /* Call function at word address 0x2 */
-\& return ((int(*)(void)) 0x2)();
-\& }
-.Ve
-.Sp
-Instead, a stub has to be set up:
-.Sp
-.Vb 3
-\& int main (void)
-\& {
-\& extern int func_4 (void);
-\&
-\& /* Call function at byte address 0x4 */
-\& return func_4();
-\& }
-.Ve
-.Sp
-and the application be linked with \f(CW\*(C`\-Wl,\-\-defsym,func_4=0x4\*(C'\fR.
-Alternatively, \f(CW\*(C`func_4\*(C'\fR can be defined in the linker script.
-.PP
-\fIBlackfin Options\fR
-.IX Subsection "Blackfin Options"
-.IP "\fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR]" 4
-.IX Item "-mcpu=cpu[-sirevision]"
-Specifies the name of the target Blackfin processor. Currently, \fIcpu\fR
-can be one of \fBbf512\fR, \fBbf514\fR, \fBbf516\fR, \fBbf518\fR,
-\&\fBbf522\fR, \fBbf523\fR, \fBbf524\fR, \fBbf525\fR, \fBbf526\fR,
-\&\fBbf527\fR, \fBbf531\fR, \fBbf532\fR, \fBbf533\fR,
-\&\fBbf534\fR, \fBbf536\fR, \fBbf537\fR, \fBbf538\fR, \fBbf539\fR,
-\&\fBbf542\fR, \fBbf544\fR, \fBbf547\fR, \fBbf548\fR, \fBbf549\fR,
-\&\fBbf542m\fR, \fBbf544m\fR, \fBbf547m\fR, \fBbf548m\fR, \fBbf549m\fR,
-\&\fBbf561\fR.
-The optional \fIsirevision\fR specifies the silicon revision of the target
-Blackfin processor. Any workarounds available for the targeted silicon revision
-will be enabled. If \fIsirevision\fR is \fBnone\fR, no workarounds are enabled.
-If \fIsirevision\fR is \fBany\fR, all workarounds for the targeted processor
-will be enabled. The \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR macro is defined to two
-hexadecimal digits representing the major and minor numbers in the silicon
-revision. If \fIsirevision\fR is \fBnone\fR, the \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR
-is not defined. If \fIsirevision\fR is \fBany\fR, the
-\&\f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR is defined to be \f(CW0xffff\fR.
-If this optional \fIsirevision\fR is not used, \s-1GCC\s0 assumes the latest known
-silicon revision of the targeted Blackfin processor.
-.Sp
-Support for \fBbf561\fR is incomplete. For \fBbf561\fR,
-Only the processor macro is defined.
-Without this option, \fBbf532\fR is used as the processor by default.
-The corresponding predefined processor macros for \fIcpu\fR is to
-be defined. And for \fBbfin-elf\fR toolchain, this causes the hardware \s-1BSP\s0
-provided by libgloss to be linked in if \fB\-msim\fR is not given.
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-Specifies that the program will be run on the simulator. This causes
-the simulator \s-1BSP\s0 provided by libgloss to be linked in. This option
-has effect only for \fBbfin-elf\fR toolchain.
-Certain other options, such as \fB\-mid\-shared\-library\fR and
-\&\fB\-mfdpic\fR, imply \fB\-msim\fR.
-.IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
-.IX Item "-momit-leaf-frame-pointer"
-Don't keep the frame pointer in a register for leaf functions. This
-avoids the instructions to save, set up and restore frame pointers and
-makes an extra register available in leaf functions. The option
-\&\fB\-fomit\-frame\-pointer\fR removes the frame pointer for all functions
-which might make debugging harder.
-.IP "\fB\-mspecld\-anomaly\fR" 4
-.IX Item "-mspecld-anomaly"
-When enabled, the compiler will ensure that the generated code does not
-contain speculative loads after jump instructions. If this option is used,
-\&\f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_LOADS\*(C'\fR is defined.
-.IP "\fB\-mno\-specld\-anomaly\fR" 4
-.IX Item "-mno-specld-anomaly"
-Don't generate extra code to prevent speculative loads from occurring.
-.IP "\fB\-mcsync\-anomaly\fR" 4
-.IX Item "-mcsync-anomaly"
-When enabled, the compiler will ensure that the generated code does not
-contain \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions too soon after conditional branches.
-If this option is used, \f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_SYNCS\*(C'\fR is defined.
-.IP "\fB\-mno\-csync\-anomaly\fR" 4
-.IX Item "-mno-csync-anomaly"
-Don't generate extra code to prevent \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions from
-occurring too soon after a conditional branch.
-.IP "\fB\-mlow\-64k\fR" 4
-.IX Item "-mlow-64k"
-When enabled, the compiler is free to take advantage of the knowledge that
-the entire program fits into the low 64k of memory.
-.IP "\fB\-mno\-low\-64k\fR" 4
-.IX Item "-mno-low-64k"
-Assume that the program is arbitrarily large. This is the default.
-.IP "\fB\-mstack\-check\-l1\fR" 4
-.IX Item "-mstack-check-l1"
-Do stack checking using information placed into L1 scratchpad memory by the
-uClinux kernel.
-.IP "\fB\-mid\-shared\-library\fR" 4
-.IX Item "-mid-shared-library"
-Generate code that supports shared libraries via the library \s-1ID\s0 method.
-This allows for execute in place and shared libraries in an environment
-without virtual memory management. This option implies \fB\-fPIC\fR.
-With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
-.IP "\fB\-mno\-id\-shared\-library\fR" 4
-.IX Item "-mno-id-shared-library"
-Generate code that doesn't assume \s-1ID\s0 based shared libraries are being used.
-This is the default.
-.IP "\fB\-mleaf\-id\-shared\-library\fR" 4
-.IX Item "-mleaf-id-shared-library"
-Generate code that supports shared libraries via the library \s-1ID\s0 method,
-but assumes that this library or executable won't link against any other
-\&\s-1ID\s0 shared libraries. That allows the compiler to use faster code for jumps
-and calls.
-.IP "\fB\-mno\-leaf\-id\-shared\-library\fR" 4
-.IX Item "-mno-leaf-id-shared-library"
-Do not assume that the code being compiled won't link against any \s-1ID\s0 shared
-libraries. Slower code will be generated for jump and call insns.
-.IP "\fB\-mshared\-library\-id=n\fR" 4
-.IX Item "-mshared-library-id=n"
-Specified the identification number of the \s-1ID\s0 based shared library being
-compiled. Specifying a value of 0 will generate more compact code, specifying
-other values will force the allocation of that number to the current
-library but is no more space or time efficient than omitting this option.
-.IP "\fB\-msep\-data\fR" 4
-.IX Item "-msep-data"
-Generate code that allows the data segment to be located in a different
-area of memory from the text segment. This allows for execute in place in
-an environment without virtual memory management by eliminating relocations
-against the text section.
-.IP "\fB\-mno\-sep\-data\fR" 4
-.IX Item "-mno-sep-data"
-Generate code that assumes that the data segment follows the text segment.
-This is the default.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-.PD 0
-.IP "\fB\-mno\-long\-calls\fR" 4
-.IX Item "-mno-long-calls"
-.PD
-Tells the compiler to perform function calls by first loading the
-address of the function into a register and then performing a subroutine
-call on this register. This switch is needed if the target function
-will lie outside of the 24 bit addressing range of the offset based
-version of subroutine call instruction.
-.Sp
-This feature is not enabled by default. Specifying
-\&\fB\-mno\-long\-calls\fR will restore the default behavior. Note these
-switches have no effect on how the compiler generates code to handle
-function calls via function pointers.
-.IP "\fB\-mfast\-fp\fR" 4
-.IX Item "-mfast-fp"
-Link with the fast floating-point library. This library relaxes some of
-the \s-1IEEE\s0 floating-point standard's rules for checking inputs against
-Not-a-Number (\s-1NAN\s0), in the interest of performance.
-.IP "\fB\-minline\-plt\fR" 4
-.IX Item "-minline-plt"
-Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
-not known to bind locally. It has no effect without \fB\-mfdpic\fR.
-.IP "\fB\-mmulticore\fR" 4
-.IX Item "-mmulticore"
-Build standalone application for multicore Blackfin processor. Proper
-start files and link scripts will be used to support multicore.
-This option defines \f(CW\*(C`_\|_BFIN_MULTICORE\*(C'\fR. It can only be used with
-\&\fB\-mcpu=bf561\fR[\fB\-\fR\fIsirevision\fR]. It can be used with
-\&\fB\-mcorea\fR or \fB\-mcoreb\fR. If it's used without
-\&\fB\-mcorea\fR or \fB\-mcoreb\fR, single application/dual core
-programming model is used. In this model, the main function of Core B
-should be named as coreb_main. If it's used with \fB\-mcorea\fR or
-\&\fB\-mcoreb\fR, one application per core programming model is used.
-If this option is not used, single core application programming
-model is used.
-.IP "\fB\-mcorea\fR" 4
-.IX Item "-mcorea"
-Build standalone application for Core A of \s-1BF561\s0 when using
-one application per core programming model. Proper start files
-and link scripts will be used to support Core A. This option
-defines \f(CW\*(C`_\|_BFIN_COREA\*(C'\fR. It must be used with \fB\-mmulticore\fR.
-.IP "\fB\-mcoreb\fR" 4
-.IX Item "-mcoreb"
-Build standalone application for Core B of \s-1BF561\s0 when using
-one application per core programming model. Proper start files
-and link scripts will be used to support Core B. This option
-defines \f(CW\*(C`_\|_BFIN_COREB\*(C'\fR. When this option is used, coreb_main
-should be used instead of main. It must be used with
-\&\fB\-mmulticore\fR.
-.IP "\fB\-msdram\fR" 4
-.IX Item "-msdram"
-Build standalone application for \s-1SDRAM\s0. Proper start files and
-link scripts will be used to put the application into \s-1SDRAM\s0.
-Loader should initialize \s-1SDRAM\s0 before loading the application
-into \s-1SDRAM\s0. This option defines \f(CW\*(C`_\|_BFIN_SDRAM\*(C'\fR.
-.IP "\fB\-micplb\fR" 4
-.IX Item "-micplb"
-Assume that ICPLBs are enabled at runtime. This has an effect on certain
-anomaly workarounds. For Linux targets, the default is to assume ICPLBs
-are enabled; for standalone applications the default is off.
-.PP
-\fI\s-1CRIS\s0 Options\fR
-.IX Subsection "CRIS Options"
-.PP
-These options are defined specifically for the \s-1CRIS\s0 ports.
-.IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
-.IX Item "-march=architecture-type"
-.PD 0
-.IP "\fB\-mcpu=\fR\fIarchitecture-type\fR" 4
-.IX Item "-mcpu=architecture-type"
-.PD
-Generate code for the specified architecture. The choices for
-\&\fIarchitecture-type\fR are \fBv3\fR, \fBv8\fR and \fBv10\fR for
-respectively \s-1ETRAX\s0\ 4, \s-1ETRAX\s0\ 100, and \s-1ETRAX\s0\ 100\ \s-1LX\s0.
-Default is \fBv0\fR except for cris-axis-linux-gnu, where the default is
-\&\fBv10\fR.
-.IP "\fB\-mtune=\fR\fIarchitecture-type\fR" 4
-.IX Item "-mtune=architecture-type"
-Tune to \fIarchitecture-type\fR everything applicable about the generated
-code, except for the \s-1ABI\s0 and the set of available instructions. The
-choices for \fIarchitecture-type\fR are the same as for
-\&\fB\-march=\fR\fIarchitecture-type\fR.
-.IP "\fB\-mmax\-stack\-frame=\fR\fIn\fR" 4
-.IX Item "-mmax-stack-frame=n"
-Warn when the stack frame of a function exceeds \fIn\fR bytes.
-.IP "\fB\-metrax4\fR" 4
-.IX Item "-metrax4"
-.PD 0
-.IP "\fB\-metrax100\fR" 4
-.IX Item "-metrax100"
-.PD
-The options \fB\-metrax4\fR and \fB\-metrax100\fR are synonyms for
-\&\fB\-march=v3\fR and \fB\-march=v8\fR respectively.
-.IP "\fB\-mmul\-bug\-workaround\fR" 4
-.IX Item "-mmul-bug-workaround"
-.PD 0
-.IP "\fB\-mno\-mul\-bug\-workaround\fR" 4
-.IX Item "-mno-mul-bug-workaround"
-.PD
-Work around a bug in the \f(CW\*(C`muls\*(C'\fR and \f(CW\*(C`mulu\*(C'\fR instructions for \s-1CPU\s0
-models where it applies. This option is active by default.
-.IP "\fB\-mpdebug\fR" 4
-.IX Item "-mpdebug"
-Enable CRIS-specific verbose debug-related information in the assembly
-code. This option also has the effect to turn off the \fB#NO_APP\fR
-formatted-code indicator to the assembler at the beginning of the
-assembly file.
-.IP "\fB\-mcc\-init\fR" 4
-.IX Item "-mcc-init"
-Do not use condition-code results from previous instruction; always emit
-compare and test instructions before use of condition codes.
-.IP "\fB\-mno\-side\-effects\fR" 4
-.IX Item "-mno-side-effects"
-Do not emit instructions with side-effects in addressing modes other than
-post-increment.
-.IP "\fB\-mstack\-align\fR" 4
-.IX Item "-mstack-align"
-.PD 0
-.IP "\fB\-mno\-stack\-align\fR" 4
-.IX Item "-mno-stack-align"
-.IP "\fB\-mdata\-align\fR" 4
-.IX Item "-mdata-align"
-.IP "\fB\-mno\-data\-align\fR" 4
-.IX Item "-mno-data-align"
-.IP "\fB\-mconst\-align\fR" 4
-.IX Item "-mconst-align"
-.IP "\fB\-mno\-const\-align\fR" 4
-.IX Item "-mno-const-align"
-.PD
-These options (no-options) arranges (eliminate arrangements) for the
-stack-frame, individual data and constants to be aligned for the maximum
-single data access size for the chosen \s-1CPU\s0 model. The default is to
-arrange for 32\-bit alignment. \s-1ABI\s0 details such as structure layout are
-not affected by these options.
-.IP "\fB\-m32\-bit\fR" 4
-.IX Item "-m32-bit"
-.PD 0
-.IP "\fB\-m16\-bit\fR" 4
-.IX Item "-m16-bit"
-.IP "\fB\-m8\-bit\fR" 4
-.IX Item "-m8-bit"
-.PD
-Similar to the stack\- data\- and const-align options above, these options
-arrange for stack-frame, writable data and constants to all be 32\-bit,
-16\-bit or 8\-bit aligned. The default is 32\-bit alignment.
-.IP "\fB\-mno\-prologue\-epilogue\fR" 4
-.IX Item "-mno-prologue-epilogue"
-.PD 0
-.IP "\fB\-mprologue\-epilogue\fR" 4
-.IX Item "-mprologue-epilogue"
-.PD
-With \fB\-mno\-prologue\-epilogue\fR, the normal function prologue and
-epilogue that sets up the stack-frame are omitted and no return
-instructions or return sequences are generated in the code. Use this
-option only together with visual inspection of the compiled code: no
-warnings or errors are generated when call-saved registers must be saved,
-or storage for local variable needs to be allocated.
-.IP "\fB\-mno\-gotplt\fR" 4
-.IX Item "-mno-gotplt"
-.PD 0
-.IP "\fB\-mgotplt\fR" 4
-.IX Item "-mgotplt"
-.PD
-With \fB\-fpic\fR and \fB\-fPIC\fR, don't generate (do generate)
-instruction sequences that load addresses for functions from the \s-1PLT\s0 part
-of the \s-1GOT\s0 rather than (traditional on other architectures) calls to the
-\&\s-1PLT\s0. The default is \fB\-mgotplt\fR.
-.IP "\fB\-melf\fR" 4
-.IX Item "-melf"
-Legacy no-op option only recognized with the cris-axis-elf and
-cris-axis-linux-gnu targets.
-.IP "\fB\-mlinux\fR" 4
-.IX Item "-mlinux"
-Legacy no-op option only recognized with the cris-axis-linux-gnu target.
-.IP "\fB\-sim\fR" 4
-.IX Item "-sim"
-This option, recognized for the cris-axis-elf arranges
-to link with input-output functions from a simulator library. Code,
-initialized data and zero-initialized data are allocated consecutively.
-.IP "\fB\-sim2\fR" 4
-.IX Item "-sim2"
-Like \fB\-sim\fR, but pass linker options to locate initialized data at
-0x40000000 and zero-initialized data at 0x80000000.
-.PP
-\fI\s-1CRX\s0 Options\fR
-.IX Subsection "CRX Options"
-.PP
-These options are defined specifically for the \s-1CRX\s0 ports.
-.IP "\fB\-mmac\fR" 4
-.IX Item "-mmac"
-Enable the use of multiply-accumulate instructions. Disabled by default.
-.IP "\fB\-mpush\-args\fR" 4
-.IX Item "-mpush-args"
-Push instructions will be used to pass outgoing arguments when functions
-are called. Enabled by default.
-.PP
-\fIDarwin Options\fR
-.IX Subsection "Darwin Options"
-.PP
-These options are defined for all architectures running the Darwin operating
-system.
-.PP
-\&\s-1FSF\s0 \s-1GCC\s0 on Darwin does not create \*(L"fat\*(R" object files; it will create
-an object file for the single architecture that it was built to
-target. Apple's \s-1GCC\s0 on Darwin does create \*(L"fat\*(R" files if multiple
-\&\fB\-arch\fR options are used; it does so by running the compiler or
-linker multiple times and joining the results together with
-\&\fIlipo\fR.
-.PP
-The subtype of the file created (like \fBppc7400\fR or \fBppc970\fR or
-\&\fBi686\fR) is determined by the flags that specify the \s-1ISA\s0
-that \s-1GCC\s0 is targetting, like \fB\-mcpu\fR or \fB\-march\fR. The
-\&\fB\-force_cpusubtype_ALL\fR option can be used to override this.
-.PP
-The Darwin tools vary in their behavior when presented with an \s-1ISA\s0
-mismatch. The assembler, \fIas\fR, will only permit instructions to
-be used that are valid for the subtype of the file it is generating,
-so you cannot put 64\-bit instructions in a \fBppc750\fR object file.
-The linker for shared libraries, \fI/usr/bin/libtool\fR, will fail
-and print an error if asked to create a shared library with a less
-restrictive subtype than its input files (for instance, trying to put
-a \fBppc970\fR object file in a \fBppc7400\fR library). The linker
-for executables, \fIld\fR, will quietly give the executable the most
-restrictive subtype of any of its input files.
-.IP "\fB\-F\fR\fIdir\fR" 4
-.IX Item "-Fdir"
-Add the framework directory \fIdir\fR to the head of the list of
-directories to be searched for header files. These directories are
-interleaved with those specified by \fB\-I\fR options and are
-scanned in a left-to-right order.
-.Sp
-A framework directory is a directory with frameworks in it. A
-framework is a directory with a \fB\*(L"Headers\*(R"\fR and/or
-\&\fB\*(L"PrivateHeaders\*(R"\fR directory contained directly in it that ends
-in \fB\*(L".framework\*(R"\fR. The name of a framework is the name of this
-directory excluding the \fB\*(L".framework\*(R"\fR. Headers associated with
-the framework are found in one of those two directories, with
-\&\fB\*(L"Headers\*(R"\fR being searched first. A subframework is a framework
-directory that is in a framework's \fB\*(L"Frameworks\*(R"\fR directory.
-Includes of subframework headers can only appear in a header of a
-framework that contains the subframework, or in a sibling subframework
-header. Two subframeworks are siblings if they occur in the same
-framework. A subframework should not have the same name as a
-framework, a warning will be issued if this is violated. Currently a
-subframework cannot have subframeworks, in the future, the mechanism
-may be extended to support this. The standard frameworks can be found
-in \fB\*(L"/System/Library/Frameworks\*(R"\fR and
-\&\fB\*(L"/Library/Frameworks\*(R"\fR. An example include looks like
-\&\f(CW\*(C`#include <Framework/header.h>\*(C'\fR, where \fBFramework\fR denotes
-the name of the framework and header.h is found in the
-\&\fB\*(L"PrivateHeaders\*(R"\fR or \fB\*(L"Headers\*(R"\fR directory.
-.IP "\fB\-iframework\fR\fIdir\fR" 4
-.IX Item "-iframeworkdir"
-Like \fB\-F\fR except the directory is a treated as a system
-directory. The main difference between this \fB\-iframework\fR and
-\&\fB\-F\fR is that with \fB\-iframework\fR the compiler does not
-warn about constructs contained within header files found via
-\&\fIdir\fR. This option is valid only for the C family of languages.
-.IP "\fB\-gused\fR" 4
-.IX Item "-gused"
-Emit debugging information for symbols that are used. For \s-1STABS\s0
-debugging format, this enables \fB\-feliminate\-unused\-debug\-symbols\fR.
-This is by default \s-1ON\s0.
-.IP "\fB\-gfull\fR" 4
-.IX Item "-gfull"
-Emit debugging information for all symbols and types.
-.IP "\fB\-mmacosx\-version\-min=\fR\fIversion\fR" 4
-.IX Item "-mmacosx-version-min=version"
-The earliest version of MacOS X that this executable will run on
-is \fIversion\fR. Typical values of \fIversion\fR include \f(CW10.1\fR,
-\&\f(CW10.2\fR, and \f(CW10.3.9\fR.
-.Sp
-If the compiler was built to use the system's headers by default,
-then the default for this option is the system version on which the
-compiler is running, otherwise the default is to make choices which
-are compatible with as many systems and code bases as possible.
-.IP "\fB\-mkernel\fR" 4
-.IX Item "-mkernel"
-Enable kernel development mode. The \fB\-mkernel\fR option sets
-\&\fB\-static\fR, \fB\-fno\-common\fR, \fB\-fno\-cxa\-atexit\fR,
-\&\fB\-fno\-exceptions\fR, \fB\-fno\-non\-call\-exceptions\fR,
-\&\fB\-fapple\-kext\fR, \fB\-fno\-weak\fR and \fB\-fno\-rtti\fR where
-applicable. This mode also sets \fB\-mno\-altivec\fR,
-\&\fB\-msoft\-float\fR, \fB\-fno\-builtin\fR and
-\&\fB\-mlong\-branch\fR for PowerPC targets.
-.IP "\fB\-mone\-byte\-bool\fR" 4
-.IX Item "-mone-byte-bool"
-Override the defaults for \fBbool\fR so that \fBsizeof(bool)==1\fR.
-By default \fBsizeof(bool)\fR is \fB4\fR when compiling for
-Darwin/PowerPC and \fB1\fR when compiling for Darwin/x86, so this
-option has no effect on x86.
-.Sp
-\&\fBWarning:\fR The \fB\-mone\-byte\-bool\fR switch causes \s-1GCC\s0
-to generate code that is not binary compatible with code generated
-without that switch. Using this switch may require recompiling all
-other modules in a program, including system libraries. Use this
-switch to conform to a non-default data model.
-.IP "\fB\-mfix\-and\-continue\fR" 4
-.IX Item "-mfix-and-continue"
-.PD 0
-.IP "\fB\-ffix\-and\-continue\fR" 4
-.IX Item "-ffix-and-continue"
-.IP "\fB\-findirect\-data\fR" 4
-.IX Item "-findirect-data"
-.PD
-Generate code suitable for fast turn around development. Needed to
-enable gdb to dynamically load \f(CW\*(C`.o\*(C'\fR files into already running
-programs. \fB\-findirect\-data\fR and \fB\-ffix\-and\-continue\fR
-are provided for backwards compatibility.
-.IP "\fB\-all_load\fR" 4
-.IX Item "-all_load"
-Loads all members of static archive libraries.
-See man \fIld\fR\|(1) for more information.
-.IP "\fB\-arch_errors_fatal\fR" 4
-.IX Item "-arch_errors_fatal"
-Cause the errors having to do with files that have the wrong architecture
-to be fatal.
-.IP "\fB\-bind_at_load\fR" 4
-.IX Item "-bind_at_load"
-Causes the output file to be marked such that the dynamic linker will
-bind all undefined references when the file is loaded or launched.
-.IP "\fB\-bundle\fR" 4
-.IX Item "-bundle"
-Produce a Mach-o bundle format file.
-See man \fIld\fR\|(1) for more information.
-.IP "\fB\-bundle_loader\fR \fIexecutable\fR" 4
-.IX Item "-bundle_loader executable"
-This option specifies the \fIexecutable\fR that will be loading the build
-output file being linked. See man \fIld\fR\|(1) for more information.
-.IP "\fB\-dynamiclib\fR" 4
-.IX Item "-dynamiclib"
-When passed this option, \s-1GCC\s0 will produce a dynamic library instead of
-an executable when linking, using the Darwin \fIlibtool\fR command.
-.IP "\fB\-force_cpusubtype_ALL\fR" 4
-.IX Item "-force_cpusubtype_ALL"
-This causes \s-1GCC\s0's output file to have the \fI\s-1ALL\s0\fR subtype, instead of
-one controlled by the \fB\-mcpu\fR or \fB\-march\fR option.
-.IP "\fB\-allowable_client\fR \fIclient_name\fR" 4
-.IX Item "-allowable_client client_name"
-.PD 0
-.IP "\fB\-client_name\fR" 4
-.IX Item "-client_name"
-.IP "\fB\-compatibility_version\fR" 4
-.IX Item "-compatibility_version"
-.IP "\fB\-current_version\fR" 4
-.IX Item "-current_version"
-.IP "\fB\-dead_strip\fR" 4
-.IX Item "-dead_strip"
-.IP "\fB\-dependency\-file\fR" 4
-.IX Item "-dependency-file"
-.IP "\fB\-dylib_file\fR" 4
-.IX Item "-dylib_file"
-.IP "\fB\-dylinker_install_name\fR" 4
-.IX Item "-dylinker_install_name"
-.IP "\fB\-dynamic\fR" 4
-.IX Item "-dynamic"
-.IP "\fB\-exported_symbols_list\fR" 4
-.IX Item "-exported_symbols_list"
-.IP "\fB\-filelist\fR" 4
-.IX Item "-filelist"
-.IP "\fB\-flat_namespace\fR" 4
-.IX Item "-flat_namespace"
-.IP "\fB\-force_flat_namespace\fR" 4
-.IX Item "-force_flat_namespace"
-.IP "\fB\-headerpad_max_install_names\fR" 4
-.IX Item "-headerpad_max_install_names"
-.IP "\fB\-image_base\fR" 4
-.IX Item "-image_base"
-.IP "\fB\-init\fR" 4
-.IX Item "-init"
-.IP "\fB\-install_name\fR" 4
-.IX Item "-install_name"
-.IP "\fB\-keep_private_externs\fR" 4
-.IX Item "-keep_private_externs"
-.IP "\fB\-multi_module\fR" 4
-.IX Item "-multi_module"
-.IP "\fB\-multiply_defined\fR" 4
-.IX Item "-multiply_defined"
-.IP "\fB\-multiply_defined_unused\fR" 4
-.IX Item "-multiply_defined_unused"
-.IP "\fB\-noall_load\fR" 4
-.IX Item "-noall_load"
-.IP "\fB\-no_dead_strip_inits_and_terms\fR" 4
-.IX Item "-no_dead_strip_inits_and_terms"
-.IP "\fB\-nofixprebinding\fR" 4
-.IX Item "-nofixprebinding"
-.IP "\fB\-nomultidefs\fR" 4
-.IX Item "-nomultidefs"
-.IP "\fB\-noprebind\fR" 4
-.IX Item "-noprebind"
-.IP "\fB\-noseglinkedit\fR" 4
-.IX Item "-noseglinkedit"
-.IP "\fB\-pagezero_size\fR" 4
-.IX Item "-pagezero_size"
-.IP "\fB\-prebind\fR" 4
-.IX Item "-prebind"
-.IP "\fB\-prebind_all_twolevel_modules\fR" 4
-.IX Item "-prebind_all_twolevel_modules"
-.IP "\fB\-private_bundle\fR" 4
-.IX Item "-private_bundle"
-.IP "\fB\-read_only_relocs\fR" 4
-.IX Item "-read_only_relocs"
-.IP "\fB\-sectalign\fR" 4
-.IX Item "-sectalign"
-.IP "\fB\-sectobjectsymbols\fR" 4
-.IX Item "-sectobjectsymbols"
-.IP "\fB\-whyload\fR" 4
-.IX Item "-whyload"
-.IP "\fB\-seg1addr\fR" 4
-.IX Item "-seg1addr"
-.IP "\fB\-sectcreate\fR" 4
-.IX Item "-sectcreate"
-.IP "\fB\-sectobjectsymbols\fR" 4
-.IX Item "-sectobjectsymbols"
-.IP "\fB\-sectorder\fR" 4
-.IX Item "-sectorder"
-.IP "\fB\-segaddr\fR" 4
-.IX Item "-segaddr"
-.IP "\fB\-segs_read_only_addr\fR" 4
-.IX Item "-segs_read_only_addr"
-.IP "\fB\-segs_read_write_addr\fR" 4
-.IX Item "-segs_read_write_addr"
-.IP "\fB\-seg_addr_table\fR" 4
-.IX Item "-seg_addr_table"
-.IP "\fB\-seg_addr_table_filename\fR" 4
-.IX Item "-seg_addr_table_filename"
-.IP "\fB\-seglinkedit\fR" 4
-.IX Item "-seglinkedit"
-.IP "\fB\-segprot\fR" 4
-.IX Item "-segprot"
-.IP "\fB\-segs_read_only_addr\fR" 4
-.IX Item "-segs_read_only_addr"
-.IP "\fB\-segs_read_write_addr\fR" 4
-.IX Item "-segs_read_write_addr"
-.IP "\fB\-single_module\fR" 4
-.IX Item "-single_module"
-.IP "\fB\-static\fR" 4
-.IX Item "-static"
-.IP "\fB\-sub_library\fR" 4
-.IX Item "-sub_library"
-.IP "\fB\-sub_umbrella\fR" 4
-.IX Item "-sub_umbrella"
-.IP "\fB\-twolevel_namespace\fR" 4
-.IX Item "-twolevel_namespace"
-.IP "\fB\-umbrella\fR" 4
-.IX Item "-umbrella"
-.IP "\fB\-undefined\fR" 4
-.IX Item "-undefined"
-.IP "\fB\-unexported_symbols_list\fR" 4
-.IX Item "-unexported_symbols_list"
-.IP "\fB\-weak_reference_mismatches\fR" 4
-.IX Item "-weak_reference_mismatches"
-.IP "\fB\-whatsloaded\fR" 4
-.IX Item "-whatsloaded"
-.PD
-These options are passed to the Darwin linker. The Darwin linker man page
-describes them in detail.
-.PP
-\fI\s-1DEC\s0 Alpha Options\fR
-.IX Subsection "DEC Alpha Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1DEC\s0 Alpha implementations:
-.IP "\fB\-mno\-soft\-float\fR" 4
-.IX Item "-mno-soft-float"
-.PD 0
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-.PD
-Use (do not use) the hardware floating-point instructions for
-floating-point operations. When \fB\-msoft\-float\fR is specified,
-functions in \fIlibgcc.a\fR will be used to perform floating-point
-operations. Unless they are replaced by routines that emulate the
-floating-point operations, or compiled in such a way as to call such
-emulations routines, these routines will issue floating-point
-operations. If you are compiling for an Alpha without floating-point
-operations, you must ensure that the library is built so as not to call
-them.
-.Sp
-Note that Alpha implementations without floating-point operations are
-required to have floating-point registers.
-.IP "\fB\-mfp\-reg\fR" 4
-.IX Item "-mfp-reg"
-.PD 0
-.IP "\fB\-mno\-fp\-regs\fR" 4
-.IX Item "-mno-fp-regs"
-.PD
-Generate code that uses (does not use) the floating-point register set.
-\&\fB\-mno\-fp\-regs\fR implies \fB\-msoft\-float\fR. If the floating-point
-register set is not used, floating point operands are passed in integer
-registers as if they were integers and floating-point results are passed
-in \f(CW$0\fR instead of \f(CW$f0\fR. This is a non-standard calling sequence,
-so any function with a floating-point argument or return value called by code
-compiled with \fB\-mno\-fp\-regs\fR must also be compiled with that
-option.
-.Sp
-A typical use of this option is building a kernel that does not use,
-and hence need not save and restore, any floating-point registers.
-.IP "\fB\-mieee\fR" 4
-.IX Item "-mieee"
-The Alpha architecture implements floating-point hardware optimized for
-maximum performance. It is mostly compliant with the \s-1IEEE\s0 floating
-point standard. However, for full compliance, software assistance is
-required. This option generates code fully \s-1IEEE\s0 compliant code
-\&\fIexcept\fR that the \fIinexact-flag\fR is not maintained (see below).
-If this option is turned on, the preprocessor macro \f(CW\*(C`_IEEE_FP\*(C'\fR is
-defined during compilation. The resulting code is less efficient but is
-able to correctly support denormalized numbers and exceptional \s-1IEEE\s0
-values such as not-a-number and plus/minus infinity. Other Alpha
-compilers call this option \fB\-ieee_with_no_inexact\fR.
-.IP "\fB\-mieee\-with\-inexact\fR" 4
-.IX Item "-mieee-with-inexact"
-This is like \fB\-mieee\fR except the generated code also maintains
-the \s-1IEEE\s0 \fIinexact-flag\fR. Turning on this option causes the
-generated code to implement fully-compliant \s-1IEEE\s0 math. In addition to
-\&\f(CW\*(C`_IEEE_FP\*(C'\fR, \f(CW\*(C`_IEEE_FP_EXACT\*(C'\fR is defined as a preprocessor
-macro. On some Alpha implementations the resulting code may execute
-significantly slower than the code generated by default. Since there is
-very little code that depends on the \fIinexact-flag\fR, you should
-normally not specify this option. Other Alpha compilers call this
-option \fB\-ieee_with_inexact\fR.
-.IP "\fB\-mfp\-trap\-mode=\fR\fItrap-mode\fR" 4
-.IX Item "-mfp-trap-mode=trap-mode"
-This option controls what floating-point related traps are enabled.
-Other Alpha compilers call this option \fB\-fptm\fR \fItrap-mode\fR.
-The trap mode can be set to one of four values:
-.RS 4
-.IP "\fBn\fR" 4
-.IX Item "n"
-This is the default (normal) setting. The only traps that are enabled
-are the ones that cannot be disabled in software (e.g., division by zero
-trap).
-.IP "\fBu\fR" 4
-.IX Item "u"
-In addition to the traps enabled by \fBn\fR, underflow traps are enabled
-as well.
-.IP "\fBsu\fR" 4
-.IX Item "su"
-Like \fBu\fR, but the instructions are marked to be safe for software
-completion (see Alpha architecture manual for details).
-.IP "\fBsui\fR" 4
-.IX Item "sui"
-Like \fBsu\fR, but inexact traps are enabled as well.
-.RE
-.RS 4
-.RE
-.IP "\fB\-mfp\-rounding\-mode=\fR\fIrounding-mode\fR" 4
-.IX Item "-mfp-rounding-mode=rounding-mode"
-Selects the \s-1IEEE\s0 rounding mode. Other Alpha compilers call this option
-\&\fB\-fprm\fR \fIrounding-mode\fR. The \fIrounding-mode\fR can be one
-of:
-.RS 4
-.IP "\fBn\fR" 4
-.IX Item "n"
-Normal \s-1IEEE\s0 rounding mode. Floating point numbers are rounded towards
-the nearest machine number or towards the even machine number in case
-of a tie.
-.IP "\fBm\fR" 4
-.IX Item "m"
-Round towards minus infinity.
-.IP "\fBc\fR" 4
-.IX Item "c"
-Chopped rounding mode. Floating point numbers are rounded towards zero.
-.IP "\fBd\fR" 4
-.IX Item "d"
-Dynamic rounding mode. A field in the floating point control register
-(\fIfpcr\fR, see Alpha architecture reference manual) controls the
-rounding mode in effect. The C library initializes this register for
-rounding towards plus infinity. Thus, unless your program modifies the
-\&\fIfpcr\fR, \fBd\fR corresponds to round towards plus infinity.
-.RE
-.RS 4
-.RE
-.IP "\fB\-mtrap\-precision=\fR\fItrap-precision\fR" 4
-.IX Item "-mtrap-precision=trap-precision"
-In the Alpha architecture, floating point traps are imprecise. This
-means without software assistance it is impossible to recover from a
-floating trap and program execution normally needs to be terminated.
-\&\s-1GCC\s0 can generate code that can assist operating system trap handlers
-in determining the exact location that caused a floating point trap.
-Depending on the requirements of an application, different levels of
-precisions can be selected:
-.RS 4
-.IP "\fBp\fR" 4
-.IX Item "p"
-Program precision. This option is the default and means a trap handler
-can only identify which program caused a floating point exception.
-.IP "\fBf\fR" 4
-.IX Item "f"
-Function precision. The trap handler can determine the function that
-caused a floating point exception.
-.IP "\fBi\fR" 4
-.IX Item "i"
-Instruction precision. The trap handler can determine the exact
-instruction that caused a floating point exception.
-.RE
-.RS 4
-.Sp
-Other Alpha compilers provide the equivalent options called
-\&\fB\-scope_safe\fR and \fB\-resumption_safe\fR.
-.RE
-.IP "\fB\-mieee\-conformant\fR" 4
-.IX Item "-mieee-conformant"
-This option marks the generated code as \s-1IEEE\s0 conformant. You must not
-use this option unless you also specify \fB\-mtrap\-precision=i\fR and either
-\&\fB\-mfp\-trap\-mode=su\fR or \fB\-mfp\-trap\-mode=sui\fR. Its only effect
-is to emit the line \fB.eflag 48\fR in the function prologue of the
-generated assembly file. Under \s-1DEC\s0 Unix, this has the effect that
-IEEE-conformant math library routines will be linked in.
-.IP "\fB\-mbuild\-constants\fR" 4
-.IX Item "-mbuild-constants"
-Normally \s-1GCC\s0 examines a 32\- or 64\-bit integer constant to
-see if it can construct it from smaller constants in two or three
-instructions. If it cannot, it will output the constant as a literal and
-generate code to load it from the data segment at runtime.
-.Sp
-Use this option to require \s-1GCC\s0 to construct \fIall\fR integer constants
-using code, even if it takes more instructions (the maximum is six).
-.Sp
-You would typically use this option to build a shared library dynamic
-loader. Itself a shared library, it must relocate itself in memory
-before it can find the variables and constants in its own data segment.
-.IP "\fB\-malpha\-as\fR" 4
-.IX Item "-malpha-as"
-.PD 0
-.IP "\fB\-mgas\fR" 4
-.IX Item "-mgas"
-.PD
-Select whether to generate code to be assembled by the vendor-supplied
-assembler (\fB\-malpha\-as\fR) or by the \s-1GNU\s0 assembler \fB\-mgas\fR.
-.IP "\fB\-mbwx\fR" 4
-.IX Item "-mbwx"
-.PD 0
-.IP "\fB\-mno\-bwx\fR" 4
-.IX Item "-mno-bwx"
-.IP "\fB\-mcix\fR" 4
-.IX Item "-mcix"
-.IP "\fB\-mno\-cix\fR" 4
-.IX Item "-mno-cix"
-.IP "\fB\-mfix\fR" 4
-.IX Item "-mfix"
-.IP "\fB\-mno\-fix\fR" 4
-.IX Item "-mno-fix"
-.IP "\fB\-mmax\fR" 4
-.IX Item "-mmax"
-.IP "\fB\-mno\-max\fR" 4
-.IX Item "-mno-max"
-.PD
-Indicate whether \s-1GCC\s0 should generate code to use the optional \s-1BWX\s0,
-\&\s-1CIX\s0, \s-1FIX\s0 and \s-1MAX\s0 instruction sets. The default is to use the instruction
-sets supported by the \s-1CPU\s0 type specified via \fB\-mcpu=\fR option or that
-of the \s-1CPU\s0 on which \s-1GCC\s0 was built if none was specified.
-.IP "\fB\-mfloat\-vax\fR" 4
-.IX Item "-mfloat-vax"
-.PD 0
-.IP "\fB\-mfloat\-ieee\fR" 4
-.IX Item "-mfloat-ieee"
-.PD
-Generate code that uses (does not use) \s-1VAX\s0 F and G floating point
-arithmetic instead of \s-1IEEE\s0 single and double precision.
-.IP "\fB\-mexplicit\-relocs\fR" 4
-.IX Item "-mexplicit-relocs"
-.PD 0
-.IP "\fB\-mno\-explicit\-relocs\fR" 4
-.IX Item "-mno-explicit-relocs"
-.PD
-Older Alpha assemblers provided no way to generate symbol relocations
-except via assembler macros. Use of these macros does not allow
-optimal instruction scheduling. \s-1GNU\s0 binutils as of version 2.12
-supports a new syntax that allows the compiler to explicitly mark
-which relocations should apply to which instructions. This option
-is mostly useful for debugging, as \s-1GCC\s0 detects the capabilities of
-the assembler when it is built and sets the default accordingly.
-.IP "\fB\-msmall\-data\fR" 4
-.IX Item "-msmall-data"
-.PD 0
-.IP "\fB\-mlarge\-data\fR" 4
-.IX Item "-mlarge-data"
-.PD
-When \fB\-mexplicit\-relocs\fR is in effect, static data is
-accessed via \fIgp-relative\fR relocations. When \fB\-msmall\-data\fR
-is used, objects 8 bytes long or smaller are placed in a \fIsmall data area\fR
-(the \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR sections) and are accessed via
-16\-bit relocations off of the \f(CW$gp\fR register. This limits the
-size of the small data area to 64KB, but allows the variables to be
-directly accessed via a single instruction.
-.Sp
-The default is \fB\-mlarge\-data\fR. With this option the data area
-is limited to just below 2GB. Programs that require more than 2GB of
-data must use \f(CW\*(C`malloc\*(C'\fR or \f(CW\*(C`mmap\*(C'\fR to allocate the data in the
-heap instead of in the program's data segment.
-.Sp
-When generating code for shared libraries, \fB\-fpic\fR implies
-\&\fB\-msmall\-data\fR and \fB\-fPIC\fR implies \fB\-mlarge\-data\fR.
-.IP "\fB\-msmall\-text\fR" 4
-.IX Item "-msmall-text"
-.PD 0
-.IP "\fB\-mlarge\-text\fR" 4
-.IX Item "-mlarge-text"
-.PD
-When \fB\-msmall\-text\fR is used, the compiler assumes that the
-code of the entire program (or shared library) fits in 4MB, and is
-thus reachable with a branch instruction. When \fB\-msmall\-data\fR
-is used, the compiler can assume that all local symbols share the
-same \f(CW$gp\fR value, and thus reduce the number of instructions
-required for a function call from 4 to 1.
-.Sp
-The default is \fB\-mlarge\-text\fR.
-.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
-.IX Item "-mcpu=cpu_type"
-Set the instruction set and instruction scheduling parameters for
-machine type \fIcpu_type\fR. You can specify either the \fB\s-1EV\s0\fR
-style name or the corresponding chip number. \s-1GCC\s0 supports scheduling
-parameters for the \s-1EV4\s0, \s-1EV5\s0 and \s-1EV6\s0 family of processors and will
-choose the default values for the instruction set from the processor
-you specify. If you do not specify a processor type, \s-1GCC\s0 will default
-to the processor on which the compiler was built.
-.Sp
-Supported values for \fIcpu_type\fR are
-.RS 4
-.IP "\fBev4\fR" 4
-.IX Item "ev4"
-.PD 0
-.IP "\fBev45\fR" 4
-.IX Item "ev45"
-.IP "\fB21064\fR" 4
-.IX Item "21064"
-.PD
-Schedules as an \s-1EV4\s0 and has no instruction set extensions.
-.IP "\fBev5\fR" 4
-.IX Item "ev5"
-.PD 0
-.IP "\fB21164\fR" 4
-.IX Item "21164"
-.PD
-Schedules as an \s-1EV5\s0 and has no instruction set extensions.
-.IP "\fBev56\fR" 4
-.IX Item "ev56"
-.PD 0
-.IP "\fB21164a\fR" 4
-.IX Item "21164a"
-.PD
-Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 extension.
-.IP "\fBpca56\fR" 4
-.IX Item "pca56"
-.PD 0
-.IP "\fB21164pc\fR" 4
-.IX Item "21164pc"
-.IP "\fB21164PC\fR" 4
-.IX Item "21164PC"
-.PD
-Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 and \s-1MAX\s0 extensions.
-.IP "\fBev6\fR" 4
-.IX Item "ev6"
-.PD 0
-.IP "\fB21264\fR" 4
-.IX Item "21264"
-.PD
-Schedules as an \s-1EV6\s0 and supports the \s-1BWX\s0, \s-1FIX\s0, and \s-1MAX\s0 extensions.
-.IP "\fBev67\fR" 4
-.IX Item "ev67"
-.PD 0
-.IP "\fB21264a\fR" 4
-.IX Item "21264a"
-.PD
-Schedules as an \s-1EV6\s0 and supports the \s-1BWX\s0, \s-1CIX\s0, \s-1FIX\s0, and \s-1MAX\s0 extensions.
-.RE
-.RS 4
-.Sp
-Native Linux/GNU toolchains also support the value \fBnative\fR,
-which selects the best architecture option for the host processor.
-\&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize
-the processor.
-.RE
-.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
-.IX Item "-mtune=cpu_type"
-Set only the instruction scheduling parameters for machine type
-\&\fIcpu_type\fR. The instruction set is not changed.
-.Sp
-Native Linux/GNU toolchains also support the value \fBnative\fR,
-which selects the best architecture option for the host processor.
-\&\fB\-mtune=native\fR has no effect if \s-1GCC\s0 does not recognize
-the processor.
-.IP "\fB\-mmemory\-latency=\fR\fItime\fR" 4
-.IX Item "-mmemory-latency=time"
-Sets the latency the scheduler should assume for typical memory
-references as seen by the application. This number is highly
-dependent on the memory access patterns used by the application
-and the size of the external cache on the machine.
-.Sp
-Valid options for \fItime\fR are
-.RS 4
-.IP "\fInumber\fR" 4
-.IX Item "number"
-A decimal number representing clock cycles.
-.IP "\fBL1\fR" 4
-.IX Item "L1"
-.PD 0
-.IP "\fBL2\fR" 4
-.IX Item "L2"
-.IP "\fBL3\fR" 4
-.IX Item "L3"
-.IP "\fBmain\fR" 4
-.IX Item "main"
-.PD
-The compiler contains estimates of the number of clock cycles for
-\&\*(L"typical\*(R" \s-1EV4\s0 & \s-1EV5\s0 hardware for the Level 1, 2 & 3 caches
-(also called Dcache, Scache, and Bcache), as well as to main memory.
-Note that L3 is only valid for \s-1EV5\s0.
-.RE
-.RS 4
-.RE
-.PP
-\fI\s-1DEC\s0 Alpha/VMS Options\fR
-.IX Subsection "DEC Alpha/VMS Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1DEC\s0 Alpha/VMS implementations:
-.IP "\fB\-mvms\-return\-codes\fR" 4
-.IX Item "-mvms-return-codes"
-Return \s-1VMS\s0 condition codes from main. The default is to return \s-1POSIX\s0
-style condition (e.g. error) codes.
-.IP "\fB\-mdebug\-main=\fR\fIprefix\fR" 4
-.IX Item "-mdebug-main=prefix"
-Flag the first routine whose name starts with \fIprefix\fR as the main
-routine for the debugger.
-.IP "\fB\-mmalloc64\fR" 4
-.IX Item "-mmalloc64"
-Default to 64bit memory allocation routines.
-.PP
-\fI\s-1FR30\s0 Options\fR
-.IX Subsection "FR30 Options"
-.PP
-These options are defined specifically for the \s-1FR30\s0 port.
-.IP "\fB\-msmall\-model\fR" 4
-.IX Item "-msmall-model"
-Use the small address space model. This can produce smaller code, but
-it does assume that all symbolic values and addresses will fit into a
-20\-bit range.
-.IP "\fB\-mno\-lsim\fR" 4
-.IX Item "-mno-lsim"
-Assume that run-time support has been provided and so there is no need
-to include the simulator library (\fIlibsim.a\fR) on the linker
-command line.
-.PP
-\fI\s-1FRV\s0 Options\fR
-.IX Subsection "FRV Options"
-.IP "\fB\-mgpr\-32\fR" 4
-.IX Item "-mgpr-32"
-Only use the first 32 general purpose registers.
-.IP "\fB\-mgpr\-64\fR" 4
-.IX Item "-mgpr-64"
-Use all 64 general purpose registers.
-.IP "\fB\-mfpr\-32\fR" 4
-.IX Item "-mfpr-32"
-Use only the first 32 floating point registers.
-.IP "\fB\-mfpr\-64\fR" 4
-.IX Item "-mfpr-64"
-Use all 64 floating point registers
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-Use hardware instructions for floating point operations.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Use library routines for floating point operations.
-.IP "\fB\-malloc\-cc\fR" 4
-.IX Item "-malloc-cc"
-Dynamically allocate condition code registers.
-.IP "\fB\-mfixed\-cc\fR" 4
-.IX Item "-mfixed-cc"
-Do not try to dynamically allocate condition code registers, only
-use \f(CW\*(C`icc0\*(C'\fR and \f(CW\*(C`fcc0\*(C'\fR.
-.IP "\fB\-mdword\fR" 4
-.IX Item "-mdword"
-Change \s-1ABI\s0 to use double word insns.
-.IP "\fB\-mno\-dword\fR" 4
-.IX Item "-mno-dword"
-Do not use double word instructions.
-.IP "\fB\-mdouble\fR" 4
-.IX Item "-mdouble"
-Use floating point double instructions.
-.IP "\fB\-mno\-double\fR" 4
-.IX Item "-mno-double"
-Do not use floating point double instructions.
-.IP "\fB\-mmedia\fR" 4
-.IX Item "-mmedia"
-Use media instructions.
-.IP "\fB\-mno\-media\fR" 4
-.IX Item "-mno-media"
-Do not use media instructions.
-.IP "\fB\-mmuladd\fR" 4
-.IX Item "-mmuladd"
-Use multiply and add/subtract instructions.
-.IP "\fB\-mno\-muladd\fR" 4
-.IX Item "-mno-muladd"
-Do not use multiply and add/subtract instructions.
-.IP "\fB\-mfdpic\fR" 4
-.IX Item "-mfdpic"
-Select the \s-1FDPIC\s0 \s-1ABI\s0, that uses function descriptors to represent
-pointers to functions. Without any PIC/PIE\-related options, it
-implies \fB\-fPIE\fR. With \fB\-fpic\fR or \fB\-fpie\fR, it
-assumes \s-1GOT\s0 entries and small data are within a 12\-bit range from the
-\&\s-1GOT\s0 base address; with \fB\-fPIC\fR or \fB\-fPIE\fR, \s-1GOT\s0 offsets
-are computed with 32 bits.
-With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
-.IP "\fB\-minline\-plt\fR" 4
-.IX Item "-minline-plt"
-Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
-not known to bind locally. It has no effect without \fB\-mfdpic\fR.
-It's enabled by default if optimizing for speed and compiling for
-shared libraries (i.e., \fB\-fPIC\fR or \fB\-fpic\fR), or when an
-optimization option such as \fB\-O3\fR or above is present in the
-command line.
-.IP "\fB\-mTLS\fR" 4
-.IX Item "-mTLS"
-Assume a large \s-1TLS\s0 segment when generating thread-local code.
-.IP "\fB\-mtls\fR" 4
-.IX Item "-mtls"
-Do not assume a large \s-1TLS\s0 segment when generating thread-local code.
-.IP "\fB\-mgprel\-ro\fR" 4
-.IX Item "-mgprel-ro"
-Enable the use of \f(CW\*(C`GPREL\*(C'\fR relocations in the \s-1FDPIC\s0 \s-1ABI\s0 for data
-that is known to be in read-only sections. It's enabled by default,
-except for \fB\-fpic\fR or \fB\-fpie\fR: even though it may help
-make the global offset table smaller, it trades 1 instruction for 4.
-With \fB\-fPIC\fR or \fB\-fPIE\fR, it trades 3 instructions for 4,
-one of which may be shared by multiple symbols, and it avoids the need
-for a \s-1GOT\s0 entry for the referenced symbol, so it's more likely to be a
-win. If it is not, \fB\-mno\-gprel\-ro\fR can be used to disable it.
-.IP "\fB\-multilib\-library\-pic\fR" 4
-.IX Item "-multilib-library-pic"
-Link with the (library, not \s-1FD\s0) pic libraries. It's implied by
-\&\fB\-mlibrary\-pic\fR, as well as by \fB\-fPIC\fR and
-\&\fB\-fpic\fR without \fB\-mfdpic\fR. You should never have to use
-it explicitly.
-.IP "\fB\-mlinked\-fp\fR" 4
-.IX Item "-mlinked-fp"
-Follow the \s-1EABI\s0 requirement of always creating a frame pointer whenever
-a stack frame is allocated. This option is enabled by default and can
-be disabled with \fB\-mno\-linked\-fp\fR.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-Use indirect addressing to call functions outside the current
-compilation unit. This allows the functions to be placed anywhere
-within the 32\-bit address space.
-.IP "\fB\-malign\-labels\fR" 4
-.IX Item "-malign-labels"
-Try to align labels to an 8\-byte boundary by inserting nops into the
-previous packet. This option only has an effect when \s-1VLIW\s0 packing
-is enabled. It doesn't create new packets; it merely adds nops to
-existing ones.
-.IP "\fB\-mlibrary\-pic\fR" 4
-.IX Item "-mlibrary-pic"
-Generate position-independent \s-1EABI\s0 code.
-.IP "\fB\-macc\-4\fR" 4
-.IX Item "-macc-4"
-Use only the first four media accumulator registers.
-.IP "\fB\-macc\-8\fR" 4
-.IX Item "-macc-8"
-Use all eight media accumulator registers.
-.IP "\fB\-mpack\fR" 4
-.IX Item "-mpack"
-Pack \s-1VLIW\s0 instructions.
-.IP "\fB\-mno\-pack\fR" 4
-.IX Item "-mno-pack"
-Do not pack \s-1VLIW\s0 instructions.
-.IP "\fB\-mno\-eflags\fR" 4
-.IX Item "-mno-eflags"
-Do not mark \s-1ABI\s0 switches in e_flags.
-.IP "\fB\-mcond\-move\fR" 4
-.IX Item "-mcond-move"
-Enable the use of conditional-move instructions (default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-cond\-move\fR" 4
-.IX Item "-mno-cond-move"
-Disable the use of conditional-move instructions.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mscc\fR" 4
-.IX Item "-mscc"
-Enable the use of conditional set instructions (default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-scc\fR" 4
-.IX Item "-mno-scc"
-Disable the use of conditional set instructions.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mcond\-exec\fR" 4
-.IX Item "-mcond-exec"
-Enable the use of conditional execution (default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-cond\-exec\fR" 4
-.IX Item "-mno-cond-exec"
-Disable the use of conditional execution.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mvliw\-branch\fR" 4
-.IX Item "-mvliw-branch"
-Run a pass to pack branches into \s-1VLIW\s0 instructions (default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-vliw\-branch\fR" 4
-.IX Item "-mno-vliw-branch"
-Do not run a pass to pack branches into \s-1VLIW\s0 instructions.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mmulti\-cond\-exec\fR" 4
-.IX Item "-mmulti-cond-exec"
-Enable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution
-(default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-multi\-cond\-exec\fR" 4
-.IX Item "-mno-multi-cond-exec"
-Disable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mnested\-cond\-exec\fR" 4
-.IX Item "-mnested-cond-exec"
-Enable nested conditional execution optimizations (default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-nested\-cond\-exec\fR" 4
-.IX Item "-mno-nested-cond-exec"
-Disable nested conditional execution optimizations.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-moptimize\-membar\fR" 4
-.IX Item "-moptimize-membar"
-This switch removes redundant \f(CW\*(C`membar\*(C'\fR instructions from the
-compiler generated code. It is enabled by default.
-.IP "\fB\-mno\-optimize\-membar\fR" 4
-.IX Item "-mno-optimize-membar"
-This switch disables the automatic removal of redundant \f(CW\*(C`membar\*(C'\fR
-instructions from the generated code.
-.IP "\fB\-mtomcat\-stats\fR" 4
-.IX Item "-mtomcat-stats"
-Cause gas to print out tomcat statistics.
-.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
-.IX Item "-mcpu=cpu"
-Select the processor type for which to generate code. Possible values are
-\&\fBfrv\fR, \fBfr550\fR, \fBtomcat\fR, \fBfr500\fR, \fBfr450\fR,
-\&\fBfr405\fR, \fBfr400\fR, \fBfr300\fR and \fBsimple\fR.
-.PP
-\fIGNU/Linux Options\fR
-.IX Subsection "GNU/Linux Options"
-.PP
-These \fB\-m\fR options are defined for GNU/Linux targets:
-.IP "\fB\-mglibc\fR" 4
-.IX Item "-mglibc"
-Use the \s-1GNU\s0 C library. This is the default except
-on \fB*\-*\-linux\-*uclibc*\fR and \fB*\-*\-linux\-*android*\fR targets.
-.IP "\fB\-muclibc\fR" 4
-.IX Item "-muclibc"
-Use uClibc C library. This is the default on
-\&\fB*\-*\-linux\-*uclibc*\fR targets.
-.IP "\fB\-mbionic\fR" 4
-.IX Item "-mbionic"
-Use Bionic C library. This is the default on
-\&\fB*\-*\-linux\-*android*\fR targets.
-.IP "\fB\-mandroid\fR" 4
-.IX Item "-mandroid"
-Compile code compatible with Android platform. This is the default on
-\&\fB*\-*\-linux\-*android*\fR targets.
-.Sp
-When compiling, this option enables \fB\-mbionic\fR, \fB\-fPIC\fR,
-\&\fB\-fno\-exceptions\fR and \fB\-fno\-rtti\fR by default. When linking,
-this option makes the \s-1GCC\s0 driver pass Android-specific options to the linker.
-Finally, this option causes the preprocessor macro \f(CW\*(C`_\|_ANDROID_\|_\*(C'\fR
-to be defined.
-.IP "\fB\-tno\-android\-cc\fR" 4
-.IX Item "-tno-android-cc"
-Disable compilation effects of \fB\-mandroid\fR, i.e., do not enable
-\&\fB\-mbionic\fR, \fB\-fPIC\fR, \fB\-fno\-exceptions\fR and
-\&\fB\-fno\-rtti\fR by default.
-.IP "\fB\-tno\-android\-ld\fR" 4
-.IX Item "-tno-android-ld"
-Disable linking effects of \fB\-mandroid\fR, i.e., pass standard Linux
-linking options to the linker.
-.PP
-\fIH8/300 Options\fR
-.IX Subsection "H8/300 Options"
-.PP
-These \fB\-m\fR options are defined for the H8/300 implementations:
-.IP "\fB\-mrelax\fR" 4
-.IX Item "-mrelax"
-Shorten some address references at link time, when possible; uses the
-linker option \fB\-relax\fR.
-.IP "\fB\-mh\fR" 4
-.IX Item "-mh"
-Generate code for the H8/300H.
-.IP "\fB\-ms\fR" 4
-.IX Item "-ms"
-Generate code for the H8S.
-.IP "\fB\-mn\fR" 4
-.IX Item "-mn"
-Generate code for the H8S and H8/300H in the normal mode. This switch
-must be used either with \fB\-mh\fR or \fB\-ms\fR.
-.IP "\fB\-ms2600\fR" 4
-.IX Item "-ms2600"
-Generate code for the H8S/2600. This switch must be used with \fB\-ms\fR.
-.IP "\fB\-mint32\fR" 4
-.IX Item "-mint32"
-Make \f(CW\*(C`int\*(C'\fR data 32 bits by default.
-.IP "\fB\-malign\-300\fR" 4
-.IX Item "-malign-300"
-On the H8/300H and H8S, use the same alignment rules as for the H8/300.
-The default for the H8/300H and H8S is to align longs and floats on 4
-byte boundaries.
-\&\fB\-malign\-300\fR causes them to be aligned on 2 byte boundaries.
-This option has no effect on the H8/300.
-.PP
-\fI\s-1HPPA\s0 Options\fR
-.IX Subsection "HPPA Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1HPPA\s0 family of computers:
-.IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
-.IX Item "-march=architecture-type"
-Generate code for the specified architecture. The choices for
-\&\fIarchitecture-type\fR are \fB1.0\fR for \s-1PA\s0 1.0, \fB1.1\fR for \s-1PA\s0
-1.1, and \fB2.0\fR for \s-1PA\s0 2.0 processors. Refer to
-\&\fI/usr/lib/sched.models\fR on an HP-UX system to determine the proper
-architecture option for your machine. Code compiled for lower numbered
-architectures will run on higher numbered architectures, but not the
-other way around.
-.IP "\fB\-mpa\-risc\-1\-0\fR" 4
-.IX Item "-mpa-risc-1-0"
-.PD 0
-.IP "\fB\-mpa\-risc\-1\-1\fR" 4
-.IX Item "-mpa-risc-1-1"
-.IP "\fB\-mpa\-risc\-2\-0\fR" 4
-.IX Item "-mpa-risc-2-0"
-.PD
-Synonyms for \fB\-march=1.0\fR, \fB\-march=1.1\fR, and \fB\-march=2.0\fR respectively.
-.IP "\fB\-mbig\-switch\fR" 4
-.IX Item "-mbig-switch"
-Generate code suitable for big switch tables. Use this option only if
-the assembler/linker complain about out of range branches within a switch
-table.
-.IP "\fB\-mjump\-in\-delay\fR" 4
-.IX Item "-mjump-in-delay"
-Fill delay slots of function calls with unconditional jump instructions
-by modifying the return pointer for the function call to be the target
-of the conditional jump.
-.IP "\fB\-mdisable\-fpregs\fR" 4
-.IX Item "-mdisable-fpregs"
-Prevent floating point registers from being used in any manner. This is
-necessary for compiling kernels which perform lazy context switching of
-floating point registers. If you use this option and attempt to perform
-floating point operations, the compiler will abort.
-.IP "\fB\-mdisable\-indexing\fR" 4
-.IX Item "-mdisable-indexing"
-Prevent the compiler from using indexing address modes. This avoids some
-rather obscure problems when compiling \s-1MIG\s0 generated code under \s-1MACH\s0.
-.IP "\fB\-mno\-space\-regs\fR" 4
-.IX Item "-mno-space-regs"
-Generate code that assumes the target has no space registers. This allows
-\&\s-1GCC\s0 to generate faster indirect calls and use unscaled index address modes.
-.Sp
-Such code is suitable for level 0 \s-1PA\s0 systems and kernels.
-.IP "\fB\-mfast\-indirect\-calls\fR" 4
-.IX Item "-mfast-indirect-calls"
-Generate code that assumes calls never cross space boundaries. This
-allows \s-1GCC\s0 to emit code which performs faster indirect calls.
-.Sp
-This option will not work in the presence of shared libraries or nested
-functions.
-.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
-.IX Item "-mfixed-range=register-range"
-Generate code treating the given register range as fixed registers.
-A fixed register is one that the register allocator can not use. This is
-useful when compiling kernel code. A register range is specified as
-two registers separated by a dash. Multiple register ranges can be
-specified separated by a comma.
-.IP "\fB\-mlong\-load\-store\fR" 4
-.IX Item "-mlong-load-store"
-Generate 3\-instruction load and store sequences as sometimes required by
-the HP-UX 10 linker. This is equivalent to the \fB+k\fR option to
-the \s-1HP\s0 compilers.
-.IP "\fB\-mportable\-runtime\fR" 4
-.IX Item "-mportable-runtime"
-Use the portable calling conventions proposed by \s-1HP\s0 for \s-1ELF\s0 systems.
-.IP "\fB\-mgas\fR" 4
-.IX Item "-mgas"
-Enable the use of assembler directives only \s-1GAS\s0 understands.
-.IP "\fB\-mschedule=\fR\fIcpu-type\fR" 4
-.IX Item "-mschedule=cpu-type"
-Schedule code according to the constraints for the machine type
-\&\fIcpu-type\fR. The choices for \fIcpu-type\fR are \fB700\fR
-\&\fB7100\fR, \fB7100LC\fR, \fB7200\fR, \fB7300\fR and \fB8000\fR. Refer
-to \fI/usr/lib/sched.models\fR on an HP-UX system to determine the
-proper scheduling option for your machine. The default scheduling is
-\&\fB8000\fR.
-.IP "\fB\-mlinker\-opt\fR" 4
-.IX Item "-mlinker-opt"
-Enable the optimization pass in the HP-UX linker. Note this makes symbolic
-debugging impossible. It also triggers a bug in the HP-UX 8 and HP-UX 9
-linkers in which they give bogus error messages when linking some programs.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Generate output containing library calls for floating point.
-\&\fBWarning:\fR the requisite libraries are not available for all \s-1HPPA\s0
-targets. Normally the facilities of the machine's usual C compiler are
-used, but this cannot be done directly in cross-compilation. You must make
-your own arrangements to provide suitable library functions for
-cross-compilation.
-.Sp
-\&\fB\-msoft\-float\fR changes the calling convention in the output file;
-therefore, it is only useful if you compile \fIall\fR of a program with
-this option. In particular, you need to compile \fIlibgcc.a\fR, the
-library that comes with \s-1GCC\s0, with \fB\-msoft\-float\fR in order for
-this to work.
-.IP "\fB\-msio\fR" 4
-.IX Item "-msio"
-Generate the predefine, \f(CW\*(C`_SIO\*(C'\fR, for server \s-1IO\s0. The default is
-\&\fB\-mwsio\fR. This generates the predefines, \f(CW\*(C`_\|_hp9000s700\*(C'\fR,
-\&\f(CW\*(C`_\|_hp9000s700_\|_\*(C'\fR and \f(CW\*(C`_WSIO\*(C'\fR, for workstation \s-1IO\s0. These
-options are available under HP-UX and HI-UX.
-.IP "\fB\-mgnu\-ld\fR" 4
-.IX Item "-mgnu-ld"
-Use \s-1GNU\s0 ld specific options. This passes \fB\-shared\fR to ld when
-building a shared library. It is the default when \s-1GCC\s0 is configured,
-explicitly or implicitly, with the \s-1GNU\s0 linker. This option does not
-have any affect on which ld is called, it only changes what parameters
-are passed to that ld. The ld that is called is determined by the
-\&\fB\-\-with\-ld\fR configure option, \s-1GCC\s0's program search path, and
-finally by the user's \fB\s-1PATH\s0\fR. The linker used by \s-1GCC\s0 can be printed
-using \fBwhich `gcc \-print\-prog\-name=ld`\fR. This option is only available
-on the 64 bit HP-UX \s-1GCC\s0, i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
-.IP "\fB\-mhp\-ld\fR" 4
-.IX Item "-mhp-ld"
-Use \s-1HP\s0 ld specific options. This passes \fB\-b\fR to ld when building
-a shared library and passes \fB+Accept TypeMismatch\fR to ld on all
-links. It is the default when \s-1GCC\s0 is configured, explicitly or
-implicitly, with the \s-1HP\s0 linker. This option does not have any affect on
-which ld is called, it only changes what parameters are passed to that
-ld. The ld that is called is determined by the \fB\-\-with\-ld\fR
-configure option, \s-1GCC\s0's program search path, and finally by the user's
-\&\fB\s-1PATH\s0\fR. The linker used by \s-1GCC\s0 can be printed using \fBwhich
-`gcc \-print\-prog\-name=ld`\fR. This option is only available on the 64 bit
-HP-UX \s-1GCC\s0, i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-Generate code that uses long call sequences. This ensures that a call
-is always able to reach linker generated stubs. The default is to generate
-long calls only when the distance from the call site to the beginning
-of the function or translation unit, as the case may be, exceeds a
-predefined limit set by the branch type being used. The limits for
-normal calls are 7,600,000 and 240,000 bytes, respectively for the
-\&\s-1PA\s0 2.0 and \s-1PA\s0 1.X architectures. Sibcalls are always limited at
-240,000 bytes.
-.Sp
-Distances are measured from the beginning of functions when using the
-\&\fB\-ffunction\-sections\fR option, or when using the \fB\-mgas\fR
-and \fB\-mno\-portable\-runtime\fR options together under HP-UX with
-the \s-1SOM\s0 linker.
-.Sp
-It is normally not desirable to use this option as it will degrade
-performance. However, it may be useful in large applications,
-particularly when partial linking is used to build the application.
-.Sp
-The types of long calls used depends on the capabilities of the
-assembler and linker, and the type of code being generated. The
-impact on systems that support long absolute calls, and long pic
-symbol-difference or pc-relative calls should be relatively small.
-However, an indirect call is used on 32\-bit \s-1ELF\s0 systems in pic code
-and it is quite long.
-.IP "\fB\-munix=\fR\fIunix-std\fR" 4
-.IX Item "-munix=unix-std"
-Generate compiler predefines and select a startfile for the specified
-\&\s-1UNIX\s0 standard. The choices for \fIunix-std\fR are \fB93\fR, \fB95\fR
-and \fB98\fR. \fB93\fR is supported on all HP-UX versions. \fB95\fR
-is available on HP-UX 10.10 and later. \fB98\fR is available on HP-UX
-11.11 and later. The default values are \fB93\fR for HP-UX 10.00,
-\&\fB95\fR for HP-UX 10.10 though to 11.00, and \fB98\fR for HP-UX 11.11
-and later.
-.Sp
-\&\fB\-munix=93\fR provides the same predefines as \s-1GCC\s0 3.3 and 3.4.
-\&\fB\-munix=95\fR provides additional predefines for \f(CW\*(C`XOPEN_UNIX\*(C'\fR
-and \f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, and the startfile \fIunix95.o\fR.
-\&\fB\-munix=98\fR provides additional predefines for \f(CW\*(C`_XOPEN_UNIX\*(C'\fR,
-\&\f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, \f(CW\*(C`_INCLUDE_\|_STDC_A1_SOURCE\*(C'\fR and
-\&\f(CW\*(C`_INCLUDE_XOPEN_SOURCE_500\*(C'\fR, and the startfile \fIunix98.o\fR.
-.Sp
-It is \fIimportant\fR to note that this option changes the interfaces
-for various library routines. It also affects the operational behavior
-of the C library. Thus, \fIextreme\fR care is needed in using this
-option.
-.Sp
-Library code that is intended to operate with more than one \s-1UNIX\s0
-standard must test, set and restore the variable \fI_\|_xpg4_extended_mask\fR
-as appropriate. Most \s-1GNU\s0 software doesn't provide this capability.
-.IP "\fB\-nolibdld\fR" 4
-.IX Item "-nolibdld"
-Suppress the generation of link options to search libdld.sl when the
-\&\fB\-static\fR option is specified on HP-UX 10 and later.
-.IP "\fB\-static\fR" 4
-.IX Item "-static"
-The HP-UX implementation of setlocale in libc has a dependency on
-libdld.sl. There isn't an archive version of libdld.sl. Thus,
-when the \fB\-static\fR option is specified, special link options
-are needed to resolve this dependency.
-.Sp
-On HP-UX 10 and later, the \s-1GCC\s0 driver adds the necessary options to
-link with libdld.sl when the \fB\-static\fR option is specified.
-This causes the resulting binary to be dynamic. On the 64\-bit port,
-the linkers generate dynamic binaries by default in any case. The
-\&\fB\-nolibdld\fR option can be used to prevent the \s-1GCC\s0 driver from
-adding these link options.
-.IP "\fB\-threads\fR" 4
-.IX Item "-threads"
-Add support for multithreading with the \fIdce thread\fR library
-under HP-UX. This option sets flags for both the preprocessor and
-linker.
-.PP
-\fIIntel 386 and \s-1AMD\s0 x86\-64 Options\fR
-.IX Subsection "Intel 386 and AMD x86-64 Options"
-.PP
-These \fB\-m\fR options are defined for the i386 and x86\-64 family of
-computers:
-.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
-.IX Item "-mtune=cpu-type"
-Tune to \fIcpu-type\fR everything applicable about the generated code, except
-for the \s-1ABI\s0 and the set of available instructions. The choices for
-\&\fIcpu-type\fR are:
-.RS 4
-.IP "\fIgeneric\fR" 4
-.IX Item "generic"
-Produce code optimized for the most common \s-1IA32/AMD64/EM64T\s0 processors.
-If you know the \s-1CPU\s0 on which your code will run, then you should use
-the corresponding \fB\-mtune\fR option instead of
-\&\fB\-mtune=generic\fR. But, if you do not know exactly what \s-1CPU\s0 users
-of your application will have, then you should use this option.
-.Sp
-As new processors are deployed in the marketplace, the behavior of this
-option will change. Therefore, if you upgrade to a newer version of
-\&\s-1GCC\s0, the code generated option will change to reflect the processors
-that were most common when that version of \s-1GCC\s0 was released.
-.Sp
-There is no \fB\-march=generic\fR option because \fB\-march\fR
-indicates the instruction set the compiler can use, and there is no
-generic instruction set applicable to all processors. In contrast,
-\&\fB\-mtune\fR indicates the processor (or, in this case, collection of
-processors) for which the code is optimized.
-.IP "\fInative\fR" 4
-.IX Item "native"
-This selects the \s-1CPU\s0 to tune for at compilation time by determining
-the processor type of the compiling machine. Using \fB\-mtune=native\fR
-will produce code optimized for the local machine under the constraints
-of the selected instruction set. Using \fB\-march=native\fR will
-enable all instruction subsets supported by the local machine (hence
-the result might not run on different machines).
-.IP "\fIi386\fR" 4
-.IX Item "i386"
-Original Intel's i386 \s-1CPU\s0.
-.IP "\fIi486\fR" 4
-.IX Item "i486"
-Intel's i486 \s-1CPU\s0. (No scheduling is implemented for this chip.)
-.IP "\fIi586, pentium\fR" 4
-.IX Item "i586, pentium"
-Intel Pentium \s-1CPU\s0 with no \s-1MMX\s0 support.
-.IP "\fIpentium-mmx\fR" 4
-.IX Item "pentium-mmx"
-Intel PentiumMMX \s-1CPU\s0 based on Pentium core with \s-1MMX\s0 instruction set support.
-.IP "\fIpentiumpro\fR" 4
-.IX Item "pentiumpro"
-Intel PentiumPro \s-1CPU\s0.
-.IP "\fIi686\fR" 4
-.IX Item "i686"
-Same as \f(CW\*(C`generic\*(C'\fR, but when used as \f(CW\*(C`march\*(C'\fR option, PentiumPro
-instruction set will be used, so the code will run on all i686 family chips.
-.IP "\fIpentium2\fR" 4
-.IX Item "pentium2"
-Intel Pentium2 \s-1CPU\s0 based on PentiumPro core with \s-1MMX\s0 instruction set support.
-.IP "\fIpentium3, pentium3m\fR" 4
-.IX Item "pentium3, pentium3m"
-Intel Pentium3 \s-1CPU\s0 based on PentiumPro core with \s-1MMX\s0 and \s-1SSE\s0 instruction set
-support.
-.IP "\fIpentium-m\fR" 4
-.IX Item "pentium-m"
-Low power version of Intel Pentium3 \s-1CPU\s0 with \s-1MMX\s0, \s-1SSE\s0 and \s-1SSE2\s0 instruction set
-support. Used by Centrino notebooks.
-.IP "\fIpentium4, pentium4m\fR" 4
-.IX Item "pentium4, pentium4m"
-Intel Pentium4 \s-1CPU\s0 with \s-1MMX\s0, \s-1SSE\s0 and \s-1SSE2\s0 instruction set support.
-.IP "\fIprescott\fR" 4
-.IX Item "prescott"
-Improved version of Intel Pentium4 \s-1CPU\s0 with \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0 and \s-1SSE3\s0 instruction
-set support.
-.IP "\fInocona\fR" 4
-.IX Item "nocona"
-Improved version of Intel Pentium4 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0,
-\&\s-1SSE2\s0 and \s-1SSE3\s0 instruction set support.
-.IP "\fIcore2\fR" 4
-.IX Item "core2"
-Intel Core2 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0 and \s-1SSSE3\s0
-instruction set support.
-.IP "\fIcorei7\fR" 4
-.IX Item "corei7"
-Intel Core i7 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0, \s-1SSSE3\s0, \s-1SSE4\s0.1
-and \s-1SSE4\s0.2 instruction set support.
-.IP "\fIcorei7\-avx\fR" 4
-.IX Item "corei7-avx"
-Intel Core i7 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0, \s-1SSSE3\s0,
-\&\s-1SSE4\s0.1, \s-1SSE4\s0.2, \s-1AVX\s0, \s-1AES\s0 and \s-1PCLMUL\s0 instruction set support.
-.IP "\fIcore-avx-i\fR" 4
-.IX Item "core-avx-i"
-Intel Core \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0, \s-1SSSE3\s0,
-\&\s-1SSE4\s0.1, \s-1SSE4\s0.2, \s-1AVX\s0, \s-1AES\s0, \s-1PCLMUL\s0, \s-1FSGSBASE\s0, \s-1RDRND\s0 and F16C instruction
-set support.
-.IP "\fIatom\fR" 4
-.IX Item "atom"
-Intel Atom \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0 and \s-1SSSE3\s0
-instruction set support.
-.IP "\fIk6\fR" 4
-.IX Item "k6"
-\&\s-1AMD\s0 K6 \s-1CPU\s0 with \s-1MMX\s0 instruction set support.
-.IP "\fIk6\-2, k6\-3\fR" 4
-.IX Item "k6-2, k6-3"
-Improved versions of \s-1AMD\s0 K6 \s-1CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
-.IP "\fIathlon, athlon-tbird\fR" 4
-.IX Item "athlon, athlon-tbird"
-\&\s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX\s0, 3dNOW!, enhanced 3DNow! and \s-1SSE\s0 prefetch instructions
-support.
-.IP "\fIathlon\-4, athlon-xp, athlon-mp\fR" 4
-.IX Item "athlon-4, athlon-xp, athlon-mp"
-Improved \s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX\s0, 3DNow!, enhanced 3DNow! and full \s-1SSE\s0
-instruction set support.
-.IP "\fIk8, opteron, athlon64, athlon-fx\fR" 4
-.IX Item "k8, opteron, athlon64, athlon-fx"
-\&\s-1AMD\s0 K8 core based CPUs with x86\-64 instruction set support. (This supersets
-\&\s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, 3DNow!, enhanced 3DNow! and 64\-bit instruction set extensions.)
-.IP "\fIk8\-sse3, opteron\-sse3, athlon64\-sse3\fR" 4
-.IX Item "k8-sse3, opteron-sse3, athlon64-sse3"
-Improved versions of k8, opteron and athlon64 with \s-1SSE3\s0 instruction set support.
-.IP "\fIamdfam10, barcelona\fR" 4
-.IX Item "amdfam10, barcelona"
-\&\s-1AMD\s0 Family 10h core based CPUs with x86\-64 instruction set support. (This
-supersets \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0, \s-1SSE4A\s0, 3DNow!, enhanced 3DNow!, \s-1ABM\s0 and 64\-bit
-instruction set extensions.)
-.IP "\fIwinchip\-c6\fR" 4
-.IX Item "winchip-c6"
-\&\s-1IDT\s0 Winchip C6 \s-1CPU\s0, dealt in same way as i486 with additional \s-1MMX\s0 instruction
-set support.
-.IP "\fIwinchip2\fR" 4
-.IX Item "winchip2"
-\&\s-1IDT\s0 Winchip2 \s-1CPU\s0, dealt in same way as i486 with additional \s-1MMX\s0 and 3DNow!
-instruction set support.
-.IP "\fIc3\fR" 4
-.IX Item "c3"
-Via C3 \s-1CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support. (No scheduling is
-implemented for this chip.)
-.IP "\fIc3\-2\fR" 4
-.IX Item "c3-2"
-Via C3\-2 \s-1CPU\s0 with \s-1MMX\s0 and \s-1SSE\s0 instruction set support. (No scheduling is
-implemented for this chip.)
-.IP "\fIgeode\fR" 4
-.IX Item "geode"
-Embedded \s-1AMD\s0 \s-1CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
-.RE
-.RS 4
-.Sp
-While picking a specific \fIcpu-type\fR will schedule things appropriately
-for that particular chip, the compiler will not generate any code that
-does not run on the i386 without the \fB\-march=\fR\fIcpu-type\fR option
-being used.
-.RE
-.IP "\fB\-march=\fR\fIcpu-type\fR" 4
-.IX Item "-march=cpu-type"
-Generate instructions for the machine type \fIcpu-type\fR. The choices
-for \fIcpu-type\fR are the same as for \fB\-mtune\fR. Moreover,
-specifying \fB\-march=\fR\fIcpu-type\fR implies \fB\-mtune=\fR\fIcpu-type\fR.
-.IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
-.IX Item "-mcpu=cpu-type"
-A deprecated synonym for \fB\-mtune\fR.
-.IP "\fB\-mfpmath=\fR\fIunit\fR" 4
-.IX Item "-mfpmath=unit"
-Generate floating point arithmetics for selected unit \fIunit\fR. The choices
-for \fIunit\fR are:
-.RS 4
-.IP "\fB387\fR" 4
-.IX Item "387"
-Use the standard 387 floating point coprocessor present majority of chips and
-emulated otherwise. Code compiled with this option will run almost everywhere.
-The temporary results are computed in 80bit precision instead of precision
-specified by the type resulting in slightly different results compared to most
-of other chips. See \fB\-ffloat\-store\fR for more detailed description.
-.Sp
-This is the default choice for i386 compiler.
-.IP "\fBsse\fR" 4
-.IX Item "sse"
-Use scalar floating point instructions present in the \s-1SSE\s0 instruction set.
-This instruction set is supported by Pentium3 and newer chips, in the \s-1AMD\s0 line
-by Athlon\-4, Athlon-xp and Athlon-mp chips. The earlier version of \s-1SSE\s0
-instruction set supports only single precision arithmetics, thus the double and
-extended precision arithmetics is still done using 387. Later version, present
-only in Pentium4 and the future \s-1AMD\s0 x86\-64 chips supports double precision
-arithmetics too.
-.Sp
-For the i386 compiler, you need to use \fB\-march=\fR\fIcpu-type\fR, \fB\-msse\fR
-or \fB\-msse2\fR switches to enable \s-1SSE\s0 extensions and make this option
-effective. For the x86\-64 compiler, these extensions are enabled by default.
-.Sp
-The resulting code should be considerably faster in the majority of cases and avoid
-the numerical instability problems of 387 code, but may break some existing
-code that expects temporaries to be 80bit.
-.Sp
-This is the default choice for the x86\-64 compiler.
-.IP "\fBsse,387\fR" 4
-.IX Item "sse,387"
-.PD 0
-.IP "\fBsse+387\fR" 4
-.IX Item "sse+387"
-.IP "\fBboth\fR" 4
-.IX Item "both"
-.PD
-Attempt to utilize both instruction sets at once. This effectively double the
-amount of available registers and on chips with separate execution units for
-387 and \s-1SSE\s0 the execution resources too. Use this option with care, as it is
-still experimental, because the \s-1GCC\s0 register allocator does not model separate
-functional units well resulting in instable performance.
-.RE
-.RS 4
-.RE
-.IP "\fB\-masm=\fR\fIdialect\fR" 4
-.IX Item "-masm=dialect"
-Output asm instructions using selected \fIdialect\fR. Supported
-choices are \fBintel\fR or \fBatt\fR (the default one). Darwin does
-not support \fBintel\fR.
-.IP "\fB\-mieee\-fp\fR" 4
-.IX Item "-mieee-fp"
-.PD 0
-.IP "\fB\-mno\-ieee\-fp\fR" 4
-.IX Item "-mno-ieee-fp"
-.PD
-Control whether or not the compiler uses \s-1IEEE\s0 floating point
-comparisons. These handle correctly the case where the result of a
-comparison is unordered.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Generate output containing library calls for floating point.
-\&\fBWarning:\fR the requisite libraries are not part of \s-1GCC\s0.
-Normally the facilities of the machine's usual C compiler are used, but
-this can't be done directly in cross-compilation. You must make your
-own arrangements to provide suitable library functions for
-cross-compilation.
-.Sp
-On machines where a function returns floating point results in the 80387
-register stack, some floating point opcodes may be emitted even if
-\&\fB\-msoft\-float\fR is used.
-.IP "\fB\-mno\-fp\-ret\-in\-387\fR" 4
-.IX Item "-mno-fp-ret-in-387"
-Do not use the \s-1FPU\s0 registers for return values of functions.
-.Sp
-The usual calling convention has functions return values of types
-\&\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR in an \s-1FPU\s0 register, even if there
-is no \s-1FPU\s0. The idea is that the operating system should emulate
-an \s-1FPU\s0.
-.Sp
-The option \fB\-mno\-fp\-ret\-in\-387\fR causes such values to be returned
-in ordinary \s-1CPU\s0 registers instead.
-.IP "\fB\-mno\-fancy\-math\-387\fR" 4
-.IX Item "-mno-fancy-math-387"
-Some 387 emulators do not support the \f(CW\*(C`sin\*(C'\fR, \f(CW\*(C`cos\*(C'\fR and
-\&\f(CW\*(C`sqrt\*(C'\fR instructions for the 387. Specify this option to avoid
-generating those instructions. This option is the default on FreeBSD,
-OpenBSD and NetBSD. This option is overridden when \fB\-march\fR
-indicates that the target \s-1CPU\s0 will always have an \s-1FPU\s0 and so the
-instruction will not need emulation. As of revision 2.6.1, these
-instructions are not generated unless you also use the
-\&\fB\-funsafe\-math\-optimizations\fR switch.
-.IP "\fB\-malign\-double\fR" 4
-.IX Item "-malign-double"
-.PD 0
-.IP "\fB\-mno\-align\-double\fR" 4
-.IX Item "-mno-align-double"
-.PD
-Control whether \s-1GCC\s0 aligns \f(CW\*(C`double\*(C'\fR, \f(CW\*(C`long double\*(C'\fR, and
-\&\f(CW\*(C`long long\*(C'\fR variables on a two word boundary or a one word
-boundary. Aligning \f(CW\*(C`double\*(C'\fR variables on a two word boundary will
-produce code that runs somewhat faster on a \fBPentium\fR at the
-expense of more memory.
-.Sp
-On x86\-64, \fB\-malign\-double\fR is enabled by default.
-.Sp
-\&\fBWarning:\fR if you use the \fB\-malign\-double\fR switch,
-structures containing the above types will be aligned differently than
-the published application binary interface specifications for the 386
-and will not be binary compatible with structures in code compiled
-without that switch.
-.IP "\fB\-m96bit\-long\-double\fR" 4
-.IX Item "-m96bit-long-double"
-.PD 0
-.IP "\fB\-m128bit\-long\-double\fR" 4
-.IX Item "-m128bit-long-double"
-.PD
-These switches control the size of \f(CW\*(C`long double\*(C'\fR type. The i386
-application binary interface specifies the size to be 96 bits,
-so \fB\-m96bit\-long\-double\fR is the default in 32 bit mode.
-.Sp
-Modern architectures (Pentium and newer) would prefer \f(CW\*(C`long double\*(C'\fR
-to be aligned to an 8 or 16 byte boundary. In arrays or structures
-conforming to the \s-1ABI\s0, this would not be possible. So specifying a
-\&\fB\-m128bit\-long\-double\fR will align \f(CW\*(C`long double\*(C'\fR
-to a 16 byte boundary by padding the \f(CW\*(C`long double\*(C'\fR with an additional
-32 bit zero.
-.Sp
-In the x86\-64 compiler, \fB\-m128bit\-long\-double\fR is the default choice as
-its \s-1ABI\s0 specifies that \f(CW\*(C`long double\*(C'\fR is to be aligned on 16 byte boundary.
-.Sp
-Notice that neither of these options enable any extra precision over the x87
-standard of 80 bits for a \f(CW\*(C`long double\*(C'\fR.
-.Sp
-\&\fBWarning:\fR if you override the default value for your target \s-1ABI\s0, the
-structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables will change
-their size as well as function calling convention for function taking
-\&\f(CW\*(C`long double\*(C'\fR will be modified. Hence they will not be binary
-compatible with arrays or structures in code compiled without that switch.
-.IP "\fB\-mlarge\-data\-threshold=\fR\fInumber\fR" 4
-.IX Item "-mlarge-data-threshold=number"
-When \fB\-mcmodel=medium\fR is specified, the data greater than
-\&\fIthreshold\fR are placed in large data section. This value must be the
-same across all object linked into the binary and defaults to 65535.
-.IP "\fB\-mrtd\fR" 4
-.IX Item "-mrtd"
-Use a different function-calling convention, in which functions that
-take a fixed number of arguments return with the \f(CW\*(C`ret\*(C'\fR \fInum\fR
-instruction, which pops their arguments while returning. This saves one
-instruction in the caller since there is no need to pop the arguments
-there.
-.Sp
-You can specify that an individual function is called with this calling
-sequence with the function attribute \fBstdcall\fR. You can also
-override the \fB\-mrtd\fR option by using the function attribute
-\&\fBcdecl\fR.
-.Sp
-\&\fBWarning:\fR this calling convention is incompatible with the one
-normally used on Unix, so you cannot use it if you need to call
-libraries compiled with the Unix compiler.
-.Sp
-Also, you must provide function prototypes for all functions that
-take variable numbers of arguments (including \f(CW\*(C`printf\*(C'\fR);
-otherwise incorrect code will be generated for calls to those
-functions.
-.Sp
-In addition, seriously incorrect code will result if you call a
-function with too many arguments. (Normally, extra arguments are
-harmlessly ignored.)
-.IP "\fB\-mregparm=\fR\fInum\fR" 4
-.IX Item "-mregparm=num"
-Control how many registers are used to pass integer arguments. By
-default, no registers are used to pass arguments, and at most 3
-registers can be used. You can control this behavior for a specific
-function by using the function attribute \fBregparm\fR.
-.Sp
-\&\fBWarning:\fR if you use this switch, and
-\&\fInum\fR is nonzero, then you must build all modules with the same
-value, including any libraries. This includes the system libraries and
-startup modules.
-.IP "\fB\-msseregparm\fR" 4
-.IX Item "-msseregparm"
-Use \s-1SSE\s0 register passing conventions for float and double arguments
-and return values. You can control this behavior for a specific
-function by using the function attribute \fBsseregparm\fR.
-.Sp
-\&\fBWarning:\fR if you use this switch then you must build all
-modules with the same value, including any libraries. This includes
-the system libraries and startup modules.
-.IP "\fB\-mvect8\-ret\-in\-mem\fR" 4
-.IX Item "-mvect8-ret-in-mem"
-Return 8\-byte vectors in memory instead of \s-1MMX\s0 registers. This is the
-default on Solaris@tie{}8 and 9 and VxWorks to match the \s-1ABI\s0 of the Sun
-Studio compilers until version 12. Later compiler versions (starting
-with Studio 12 Update@tie{}1) follow the \s-1ABI\s0 used by other x86 targets, which
-is the default on Solaris@tie{}10 and later. \fIOnly\fR use this option if
-you need to remain compatible with existing code produced by those
-previous compiler versions or older versions of \s-1GCC\s0.
-.IP "\fB\-mpc32\fR" 4
-.IX Item "-mpc32"
-.PD 0
-.IP "\fB\-mpc64\fR" 4
-.IX Item "-mpc64"
-.IP "\fB\-mpc80\fR" 4
-.IX Item "-mpc80"
-.PD
-Set 80387 floating-point precision to 32, 64 or 80 bits. When \fB\-mpc32\fR
-is specified, the significands of results of floating-point operations are
-rounded to 24 bits (single precision); \fB\-mpc64\fR rounds the
-significands of results of floating-point operations to 53 bits (double
-precision) and \fB\-mpc80\fR rounds the significands of results of
-floating-point operations to 64 bits (extended double precision), which is
-the default. When this option is used, floating-point operations in higher
-precisions are not available to the programmer without setting the \s-1FPU\s0
-control word explicitly.
-.Sp
-Setting the rounding of floating-point operations to less than the default
-80 bits can speed some programs by 2% or more. Note that some mathematical
-libraries assume that extended precision (80 bit) floating-point operations
-are enabled by default; routines in such libraries could suffer significant
-loss of accuracy, typically through so-called \*(L"catastrophic cancellation\*(R",
-when this option is used to set the precision to less than extended precision.
-.IP "\fB\-mstackrealign\fR" 4
-.IX Item "-mstackrealign"
-Realign the stack at entry. On the Intel x86, the \fB\-mstackrealign\fR
-option will generate an alternate prologue and epilogue that realigns the
-runtime stack if necessary. This supports mixing legacy codes that keep
-a 4\-byte aligned stack with modern codes that keep a 16\-byte stack for
-\&\s-1SSE\s0 compatibility. See also the attribute \f(CW\*(C`force_align_arg_pointer\*(C'\fR,
-applicable to individual functions.
-.IP "\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR" 4
-.IX Item "-mpreferred-stack-boundary=num"
-Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
-byte boundary. If \fB\-mpreferred\-stack\-boundary\fR is not specified,
-the default is 4 (16 bytes or 128 bits).
-.IP "\fB\-mincoming\-stack\-boundary=\fR\fInum\fR" 4
-.IX Item "-mincoming-stack-boundary=num"
-Assume the incoming stack is aligned to a 2 raised to \fInum\fR byte
-boundary. If \fB\-mincoming\-stack\-boundary\fR is not specified,
-the one specified by \fB\-mpreferred\-stack\-boundary\fR will be used.
-.Sp
-On Pentium and PentiumPro, \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long double\*(C'\fR values
-should be aligned to an 8 byte boundary (see \fB\-malign\-double\fR) or
-suffer significant run time performance penalties. On Pentium \s-1III\s0, the
-Streaming \s-1SIMD\s0 Extension (\s-1SSE\s0) data type \f(CW\*(C`_\|_m128\*(C'\fR may not work
-properly if it is not 16 byte aligned.
-.Sp
-To ensure proper alignment of this values on the stack, the stack boundary
-must be as aligned as that required by any value stored on the stack.
-Further, every function must be generated such that it keeps the stack
-aligned. Thus calling a function compiled with a higher preferred
-stack boundary from a function compiled with a lower preferred stack
-boundary will most likely misalign the stack. It is recommended that
-libraries that use callbacks always use the default setting.
-.Sp
-This extra alignment does consume extra stack space, and generally
-increases code size. Code that is sensitive to stack space usage, such
-as embedded systems and operating system kernels, may want to reduce the
-preferred alignment to \fB\-mpreferred\-stack\-boundary=2\fR.
-.IP "\fB\-mmmx\fR" 4
-.IX Item "-mmmx"
-.PD 0
-.IP "\fB\-mno\-mmx\fR" 4
-.IX Item "-mno-mmx"
-.IP "\fB\-msse\fR" 4
-.IX Item "-msse"
-.IP "\fB\-mno\-sse\fR" 4
-.IX Item "-mno-sse"
-.IP "\fB\-msse2\fR" 4
-.IX Item "-msse2"
-.IP "\fB\-mno\-sse2\fR" 4
-.IX Item "-mno-sse2"
-.IP "\fB\-msse3\fR" 4
-.IX Item "-msse3"
-.IP "\fB\-mno\-sse3\fR" 4
-.IX Item "-mno-sse3"
-.IP "\fB\-mssse3\fR" 4
-.IX Item "-mssse3"
-.IP "\fB\-mno\-ssse3\fR" 4
-.IX Item "-mno-ssse3"
-.IP "\fB\-msse4.1\fR" 4
-.IX Item "-msse4.1"
-.IP "\fB\-mno\-sse4.1\fR" 4
-.IX Item "-mno-sse4.1"
-.IP "\fB\-msse4.2\fR" 4
-.IX Item "-msse4.2"
-.IP "\fB\-mno\-sse4.2\fR" 4
-.IX Item "-mno-sse4.2"
-.IP "\fB\-msse4\fR" 4
-.IX Item "-msse4"
-.IP "\fB\-mno\-sse4\fR" 4
-.IX Item "-mno-sse4"
-.IP "\fB\-mavx\fR" 4
-.IX Item "-mavx"
-.IP "\fB\-mno\-avx\fR" 4
-.IX Item "-mno-avx"
-.IP "\fB\-maes\fR" 4
-.IX Item "-maes"
-.IP "\fB\-mno\-aes\fR" 4
-.IX Item "-mno-aes"
-.IP "\fB\-mpclmul\fR" 4
-.IX Item "-mpclmul"
-.IP "\fB\-mno\-pclmul\fR" 4
-.IX Item "-mno-pclmul"
-.IP "\fB\-mfsgsbase\fR" 4
-.IX Item "-mfsgsbase"
-.IP "\fB\-mno\-fsgsbase\fR" 4
-.IX Item "-mno-fsgsbase"
-.IP "\fB\-mrdrnd\fR" 4
-.IX Item "-mrdrnd"
-.IP "\fB\-mno\-rdrnd\fR" 4
-.IX Item "-mno-rdrnd"
-.IP "\fB\-mf16c\fR" 4
-.IX Item "-mf16c"
-.IP "\fB\-mno\-f16c\fR" 4
-.IX Item "-mno-f16c"
-.IP "\fB\-msse4a\fR" 4
-.IX Item "-msse4a"
-.IP "\fB\-mno\-sse4a\fR" 4
-.IX Item "-mno-sse4a"
-.IP "\fB\-mfma4\fR" 4
-.IX Item "-mfma4"
-.IP "\fB\-mno\-fma4\fR" 4
-.IX Item "-mno-fma4"
-.IP "\fB\-mxop\fR" 4
-.IX Item "-mxop"
-.IP "\fB\-mno\-xop\fR" 4
-.IX Item "-mno-xop"
-.IP "\fB\-mlwp\fR" 4
-.IX Item "-mlwp"
-.IP "\fB\-mno\-lwp\fR" 4
-.IX Item "-mno-lwp"
-.IP "\fB\-m3dnow\fR" 4
-.IX Item "-m3dnow"
-.IP "\fB\-mno\-3dnow\fR" 4
-.IX Item "-mno-3dnow"
-.IP "\fB\-mpopcnt\fR" 4
-.IX Item "-mpopcnt"
-.IP "\fB\-mno\-popcnt\fR" 4
-.IX Item "-mno-popcnt"
-.IP "\fB\-mabm\fR" 4
-.IX Item "-mabm"
-.IP "\fB\-mno\-abm\fR" 4
-.IX Item "-mno-abm"
-.IP "\fB\-mbmi\fR" 4
-.IX Item "-mbmi"
-.IP "\fB\-mno\-bmi\fR" 4
-.IX Item "-mno-bmi"
-.IP "\fB\-mtbm\fR" 4
-.IX Item "-mtbm"
-.IP "\fB\-mno\-tbm\fR" 4
-.IX Item "-mno-tbm"
-.PD
-These switches enable or disable the use of instructions in the \s-1MMX\s0,
-\&\s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0, \s-1SSSE3\s0, \s-1SSE4\s0.1, \s-1AVX\s0, \s-1AES\s0, \s-1PCLMUL\s0, \s-1FSGSBASE\s0, \s-1RDRND\s0,
-F16C, \s-1SSE4A\s0, \s-1FMA4\s0, \s-1XOP\s0, \s-1LWP\s0, \s-1ABM\s0, \s-1BMI\s0, or 3DNow! extended instruction sets.
-These extensions are also available as built-in functions: see
-\&\fBX86 Built-in Functions\fR, for details of the functions enabled and
-disabled by these switches.
-.Sp
-To have \s-1SSE/SSE2\s0 instructions generated automatically from floating-point
-code (as opposed to 387 instructions), see \fB\-mfpmath=sse\fR.
-.Sp
-\&\s-1GCC\s0 depresses SSEx instructions when \fB\-mavx\fR is used. Instead, it
-generates new \s-1AVX\s0 instructions or \s-1AVX\s0 equivalence for all SSEx instructions
-when needed.
-.Sp
-These options will enable \s-1GCC\s0 to use these extended instructions in
-generated code, even without \fB\-mfpmath=sse\fR. Applications which
-perform runtime \s-1CPU\s0 detection must compile separate files for each
-supported architecture, using the appropriate flags. In particular,
-the file containing the \s-1CPU\s0 detection code should be compiled without
-these options.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Do (don't) generate code that uses the fused multiply/add or multiply/subtract
-instructions. The default is to use these instructions.
-.IP "\fB\-mcld\fR" 4
-.IX Item "-mcld"
-This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`cld\*(C'\fR instruction in the prologue
-of functions that use string instructions. String instructions depend on
-the \s-1DF\s0 flag to select between autoincrement or autodecrement mode. While the
-\&\s-1ABI\s0 specifies the \s-1DF\s0 flag to be cleared on function entry, some operating
-systems violate this specification by not clearing the \s-1DF\s0 flag in their
-exception dispatchers. The exception handler can be invoked with the \s-1DF\s0 flag
-set which leads to wrong direction mode, when string instructions are used.
-This option can be enabled by default on 32\-bit x86 targets by configuring
-\&\s-1GCC\s0 with the \fB\-\-enable\-cld\fR configure option. Generation of \f(CW\*(C`cld\*(C'\fR
-instructions can be suppressed with the \fB\-mno\-cld\fR compiler option
-in this case.
-.IP "\fB\-mvzeroupper\fR" 4
-.IX Item "-mvzeroupper"
-This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`vzeroupper\*(C'\fR instruction
-before a transfer of control flow out of the function to minimize
-\&\s-1AVX\s0 to \s-1SSE\s0 transition penalty as well as remove unnecessary zeroupper
-intrinsics.
-.IP "\fB\-mcx16\fR" 4
-.IX Item "-mcx16"
-This option will enable \s-1GCC\s0 to use \s-1CMPXCHG16B\s0 instruction in generated code.
-\&\s-1CMPXCHG16B\s0 allows for atomic operations on 128\-bit double quadword (or oword)
-data types. This is useful for high resolution counters that could be updated
-by multiple processors (or cores). This instruction is generated as part of
-atomic built-in functions: see \fBAtomic Builtins\fR for details.
-.IP "\fB\-msahf\fR" 4
-.IX Item "-msahf"
-This option will enable \s-1GCC\s0 to use \s-1SAHF\s0 instruction in generated 64\-bit code.
-Early Intel CPUs with Intel 64 lacked \s-1LAHF\s0 and \s-1SAHF\s0 instructions supported
-by \s-1AMD64\s0 until introduction of Pentium 4 G1 step in December 2005. \s-1LAHF\s0 and
-\&\s-1SAHF\s0 are load and store instructions, respectively, for certain status flags.
-In 64\-bit mode, \s-1SAHF\s0 instruction is used to optimize \f(CW\*(C`fmod\*(C'\fR, \f(CW\*(C`drem\*(C'\fR
-or \f(CW\*(C`remainder\*(C'\fR built-in functions: see \fBOther Builtins\fR for details.
-.IP "\fB\-mmovbe\fR" 4
-.IX Item "-mmovbe"
-This option will enable \s-1GCC\s0 to use movbe instruction to implement
-\&\f(CW\*(C`_\|_builtin_bswap32\*(C'\fR and \f(CW\*(C`_\|_builtin_bswap64\*(C'\fR.
-.IP "\fB\-mcrc32\fR" 4
-.IX Item "-mcrc32"
-This option will enable built-in functions, \f(CW\*(C`_\|_builtin_ia32_crc32qi\*(C'\fR,
-\&\f(CW\*(C`_\|_builtin_ia32_crc32hi\*(C'\fR. \f(CW\*(C`_\|_builtin_ia32_crc32si\*(C'\fR and
-\&\f(CW\*(C`_\|_builtin_ia32_crc32di\*(C'\fR to generate the crc32 machine instruction.
-.IP "\fB\-mrecip\fR" 4
-.IX Item "-mrecip"
-This option will enable \s-1GCC\s0 to use \s-1RCPSS\s0 and \s-1RSQRTSS\s0 instructions (and their
-vectorized variants \s-1RCPPS\s0 and \s-1RSQRTPS\s0) with an additional Newton-Raphson step
-to increase precision instead of \s-1DIVSS\s0 and \s-1SQRTSS\s0 (and their vectorized
-variants) for single precision floating point arguments. These instructions
-are generated only when \fB\-funsafe\-math\-optimizations\fR is enabled
-together with \fB\-finite\-math\-only\fR and \fB\-fno\-trapping\-math\fR.
-Note that while the throughput of the sequence is higher than the throughput
-of the non-reciprocal instruction, the precision of the sequence can be
-decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.99999994).
-.Sp
-Note that \s-1GCC\s0 implements 1.0f/sqrtf(x) in terms of \s-1RSQRTSS\s0 (or \s-1RSQRTPS\s0)
-already with \fB\-ffast\-math\fR (or the above option combination), and
-doesn't need \fB\-mrecip\fR.
-.IP "\fB\-mveclibabi=\fR\fItype\fR" 4
-.IX Item "-mveclibabi=type"
-Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
-external library. Supported types are \f(CW\*(C`svml\*(C'\fR for the Intel short
-vector math library and \f(CW\*(C`acml\*(C'\fR for the \s-1AMD\s0 math core library style
-of interfacing. \s-1GCC\s0 will currently emit calls to \f(CW\*(C`vmldExp2\*(C'\fR,
-\&\f(CW\*(C`vmldLn2\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldPow2\*(C'\fR,
-\&\f(CW\*(C`vmldTanh2\*(C'\fR, \f(CW\*(C`vmldTan2\*(C'\fR, \f(CW\*(C`vmldAtan2\*(C'\fR, \f(CW\*(C`vmldAtanh2\*(C'\fR,
-\&\f(CW\*(C`vmldCbrt2\*(C'\fR, \f(CW\*(C`vmldSinh2\*(C'\fR, \f(CW\*(C`vmldSin2\*(C'\fR, \f(CW\*(C`vmldAsinh2\*(C'\fR,
-\&\f(CW\*(C`vmldAsin2\*(C'\fR, \f(CW\*(C`vmldCosh2\*(C'\fR, \f(CW\*(C`vmldCos2\*(C'\fR, \f(CW\*(C`vmldAcosh2\*(C'\fR,
-\&\f(CW\*(C`vmldAcos2\*(C'\fR, \f(CW\*(C`vmlsExp4\*(C'\fR, \f(CW\*(C`vmlsLn4\*(C'\fR, \f(CW\*(C`vmlsLog104\*(C'\fR,
-\&\f(CW\*(C`vmlsLog104\*(C'\fR, \f(CW\*(C`vmlsPow4\*(C'\fR, \f(CW\*(C`vmlsTanh4\*(C'\fR, \f(CW\*(C`vmlsTan4\*(C'\fR,
-\&\f(CW\*(C`vmlsAtan4\*(C'\fR, \f(CW\*(C`vmlsAtanh4\*(C'\fR, \f(CW\*(C`vmlsCbrt4\*(C'\fR, \f(CW\*(C`vmlsSinh4\*(C'\fR,
-\&\f(CW\*(C`vmlsSin4\*(C'\fR, \f(CW\*(C`vmlsAsinh4\*(C'\fR, \f(CW\*(C`vmlsAsin4\*(C'\fR, \f(CW\*(C`vmlsCosh4\*(C'\fR,
-\&\f(CW\*(C`vmlsCos4\*(C'\fR, \f(CW\*(C`vmlsAcosh4\*(C'\fR and \f(CW\*(C`vmlsAcos4\*(C'\fR for corresponding
-function type when \fB\-mveclibabi=svml\fR is used and \f(CW\*(C`_\|_vrd2_sin\*(C'\fR,
-\&\f(CW\*(C`_\|_vrd2_cos\*(C'\fR, \f(CW\*(C`_\|_vrd2_exp\*(C'\fR, \f(CW\*(C`_\|_vrd2_log\*(C'\fR, \f(CW\*(C`_\|_vrd2_log2\*(C'\fR,
-\&\f(CW\*(C`_\|_vrd2_log10\*(C'\fR, \f(CW\*(C`_\|_vrs4_sinf\*(C'\fR, \f(CW\*(C`_\|_vrs4_cosf\*(C'\fR,
-\&\f(CW\*(C`_\|_vrs4_expf\*(C'\fR, \f(CW\*(C`_\|_vrs4_logf\*(C'\fR, \f(CW\*(C`_\|_vrs4_log2f\*(C'\fR,
-\&\f(CW\*(C`_\|_vrs4_log10f\*(C'\fR and \f(CW\*(C`_\|_vrs4_powf\*(C'\fR for corresponding function type
-when \fB\-mveclibabi=acml\fR is used. Both \fB\-ftree\-vectorize\fR and
-\&\fB\-funsafe\-math\-optimizations\fR have to be enabled. A \s-1SVML\s0 or \s-1ACML\s0 \s-1ABI\s0
-compatible library will have to be specified at link time.
-.IP "\fB\-mabi=\fR\fIname\fR" 4
-.IX Item "-mabi=name"
-Generate code for the specified calling convention. Permissible values
-are: \fBsysv\fR for the \s-1ABI\s0 used on GNU/Linux and other systems and
-\&\fBms\fR for the Microsoft \s-1ABI\s0. The default is to use the Microsoft
-\&\s-1ABI\s0 when targeting Windows. On all other systems, the default is the
-\&\s-1SYSV\s0 \s-1ABI\s0. You can control this behavior for a specific function by
-using the function attribute \fBms_abi\fR/\fBsysv_abi\fR.
-.IP "\fB\-mpush\-args\fR" 4
-.IX Item "-mpush-args"
-.PD 0
-.IP "\fB\-mno\-push\-args\fR" 4
-.IX Item "-mno-push-args"
-.PD
-Use \s-1PUSH\s0 operations to store outgoing parameters. This method is shorter
-and usually equally fast as method using \s-1SUB/MOV\s0 operations and is enabled
-by default. In some cases disabling it may improve performance because of
-improved scheduling and reduced dependencies.
-.IP "\fB\-maccumulate\-outgoing\-args\fR" 4
-.IX Item "-maccumulate-outgoing-args"
-If enabled, the maximum amount of space required for outgoing arguments will be
-computed in the function prologue. This is faster on most modern CPUs
-because of reduced dependencies, improved scheduling and reduced stack usage
-when preferred stack boundary is not equal to 2. The drawback is a notable
-increase in code size. This switch implies \fB\-mno\-push\-args\fR.
-.IP "\fB\-mthreads\fR" 4
-.IX Item "-mthreads"
-Support thread-safe exception handling on \fBMingw32\fR. Code that relies
-on thread-safe exception handling must compile and link all code with the
-\&\fB\-mthreads\fR option. When compiling, \fB\-mthreads\fR defines
-\&\fB\-D_MT\fR; when linking, it links in a special thread helper library
-\&\fB\-lmingwthrd\fR which cleans up per thread exception handling data.
-.IP "\fB\-mno\-align\-stringops\fR" 4
-.IX Item "-mno-align-stringops"
-Do not align destination of inlined string operations. This switch reduces
-code size and improves performance in case the destination is already aligned,
-but \s-1GCC\s0 doesn't know about it.
-.IP "\fB\-minline\-all\-stringops\fR" 4
-.IX Item "-minline-all-stringops"
-By default \s-1GCC\s0 inlines string operations only when destination is known to be
-aligned at least to 4 byte boundary. This enables more inlining, increase code
-size, but may improve performance of code that depends on fast memcpy, strlen
-and memset for short lengths.
-.IP "\fB\-minline\-stringops\-dynamically\fR" 4
-.IX Item "-minline-stringops-dynamically"
-For string operation of unknown size, inline runtime checks so for small
-blocks inline code is used, while for large blocks library call is used.
-.IP "\fB\-mstringop\-strategy=\fR\fIalg\fR" 4
-.IX Item "-mstringop-strategy=alg"
-Overwrite internal decision heuristic about particular algorithm to inline
-string operation with. The allowed values are \f(CW\*(C`rep_byte\*(C'\fR,
-\&\f(CW\*(C`rep_4byte\*(C'\fR, \f(CW\*(C`rep_8byte\*(C'\fR for expanding using i386 \f(CW\*(C`rep\*(C'\fR prefix
-of specified size, \f(CW\*(C`byte_loop\*(C'\fR, \f(CW\*(C`loop\*(C'\fR, \f(CW\*(C`unrolled_loop\*(C'\fR for
-expanding inline loop, \f(CW\*(C`libcall\*(C'\fR for always expanding library call.
-.IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
-.IX Item "-momit-leaf-frame-pointer"
-Don't keep the frame pointer in a register for leaf functions. This
-avoids the instructions to save, set up and restore frame pointers and
-makes an extra register available in leaf functions. The option
-\&\fB\-fomit\-frame\-pointer\fR removes the frame pointer for all functions
-which might make debugging harder.
-.IP "\fB\-mtls\-direct\-seg\-refs\fR" 4
-.IX Item "-mtls-direct-seg-refs"
-.PD 0
-.IP "\fB\-mno\-tls\-direct\-seg\-refs\fR" 4
-.IX Item "-mno-tls-direct-seg-refs"
-.PD
-Controls whether \s-1TLS\s0 variables may be accessed with offsets from the
-\&\s-1TLS\s0 segment register (\f(CW%gs\fR for 32\-bit, \f(CW%fs\fR for 64\-bit),
-or whether the thread base pointer must be added. Whether or not this
-is legal depends on the operating system, and whether it maps the
-segment to cover the entire \s-1TLS\s0 area.
-.Sp
-For systems that use \s-1GNU\s0 libc, the default is on.
-.IP "\fB\-msse2avx\fR" 4
-.IX Item "-msse2avx"
-.PD 0
-.IP "\fB\-mno\-sse2avx\fR" 4
-.IX Item "-mno-sse2avx"
-.PD
-Specify that the assembler should encode \s-1SSE\s0 instructions with \s-1VEX\s0
-prefix. The option \fB\-mavx\fR turns this on by default.
-.IP "\fB\-mfentry\fR" 4
-.IX Item "-mfentry"
-.PD 0
-.IP "\fB\-mno\-fentry\fR" 4
-.IX Item "-mno-fentry"
-.PD
-If profiling is active \fB\-pg\fR put the profiling
-counter call before prologue.
-Note: On x86 architectures the attribute \f(CW\*(C`ms_hook_prologue\*(C'\fR
-isn't possible at the moment for \fB\-mfentry\fR and \fB\-pg\fR.
-.IP "\fB\-m8bit\-idiv\fR" 4
-.IX Item "-m8bit-idiv"
-.PD 0
-.IP "\fB\-mno\-8bit\-idiv\fR" 4
-.IX Item "-mno-8bit-idiv"
-.PD
-On some processors, like Intel Atom, 8bit unsigned integer divide is
-much faster than 32bit/64bit integer divide. This option will generate a
-runt-time check. If both dividend and divisor are within range of 0
-to 255, 8bit unsigned integer divide will be used instead of
-32bit/64bit integer divide.
-.IP "\fB\-mavx256\-split\-unaligned\-load\fR" 4
-.IX Item "-mavx256-split-unaligned-load"
-.PD 0
-.IP "\fB\-mavx256\-split\-unaligned\-store\fR" 4
-.IX Item "-mavx256-split-unaligned-store"
-.PD
-Split 32\-byte \s-1AVX\s0 unaligned load and store.
-.PP
-These \fB\-m\fR switches are supported in addition to the above
-on \s-1AMD\s0 x86\-64 processors in 64\-bit environments.
-.IP "\fB\-m32\fR" 4
-.IX Item "-m32"
-.PD 0
-.IP "\fB\-m64\fR" 4
-.IX Item "-m64"
-.PD
-Generate code for a 32\-bit or 64\-bit environment.
-The 32\-bit environment sets int, long and pointer to 32 bits and
-generates code that runs on any i386 system.
-The 64\-bit environment sets int to 32 bits and long and pointer
-to 64 bits and generates code for \s-1AMD\s0's x86\-64 architecture. For
-darwin only the \-m64 option turns off the \fB\-fno\-pic\fR and
-\&\fB\-mdynamic\-no\-pic\fR options.
-.IP "\fB\-mno\-red\-zone\fR" 4
-.IX Item "-mno-red-zone"
-Do not use a so called red zone for x86\-64 code. The red zone is mandated
-by the x86\-64 \s-1ABI\s0, it is a 128\-byte area beyond the location of the
-stack pointer that will not be modified by signal or interrupt handlers
-and therefore can be used for temporary data without adjusting the stack
-pointer. The flag \fB\-mno\-red\-zone\fR disables this red zone.
-.IP "\fB\-mcmodel=small\fR" 4
-.IX Item "-mcmodel=small"
-Generate code for the small code model: the program and its symbols must
-be linked in the lower 2 \s-1GB\s0 of the address space. Pointers are 64 bits.
-Programs can be statically or dynamically linked. This is the default
-code model.
-.IP "\fB\-mcmodel=kernel\fR" 4
-.IX Item "-mcmodel=kernel"
-Generate code for the kernel code model. The kernel runs in the
-negative 2 \s-1GB\s0 of the address space.
-This model has to be used for Linux kernel code.
-.IP "\fB\-mcmodel=medium\fR" 4
-.IX Item "-mcmodel=medium"
-Generate code for the medium model: The program is linked in the lower 2
-\&\s-1GB\s0 of the address space. Small symbols are also placed there. Symbols
-with sizes larger than \fB\-mlarge\-data\-threshold\fR are put into
-large data or bss sections and can be located above 2GB. Programs can
-be statically or dynamically linked.
-.IP "\fB\-mcmodel=large\fR" 4
-.IX Item "-mcmodel=large"
-Generate code for the large model: This model makes no assumptions
-about addresses and sizes of sections.
-.PP
-\fIi386 and x86\-64 Windows Options\fR
-.IX Subsection "i386 and x86-64 Windows Options"
-.PP
-These additional options are available for Windows targets:
-.IP "\fB\-mconsole\fR" 4
-.IX Item "-mconsole"
-This option is available for Cygwin and MinGW targets. It
-specifies that a console application is to be generated, by
-instructing the linker to set the \s-1PE\s0 header subsystem type
-required for console applications.
-This is the default behavior for Cygwin and MinGW targets.
-.IP "\fB\-mdll\fR" 4
-.IX Item "-mdll"
-This option is available for Cygwin and MinGW targets. It
-specifies that a \s-1DLL\s0 \- a dynamic link library \- is to be
-generated, enabling the selection of the required runtime
-startup object and entry point.
-.IP "\fB\-mnop\-fun\-dllimport\fR" 4
-.IX Item "-mnop-fun-dllimport"
-This option is available for Cygwin and MinGW targets. It
-specifies that the dllimport attribute should be ignored.
-.IP "\fB\-mthread\fR" 4
-.IX Item "-mthread"
-This option is available for MinGW targets. It specifies
-that MinGW-specific thread support is to be used.
-.IP "\fB\-municode\fR" 4
-.IX Item "-municode"
-This option is available for mingw\-w64 targets. It specifies
-that the \s-1UNICODE\s0 macro is getting pre-defined and that the
-unicode capable runtime startup code is chosen.
-.IP "\fB\-mwin32\fR" 4
-.IX Item "-mwin32"
-This option is available for Cygwin and MinGW targets. It
-specifies that the typical Windows pre-defined macros are to
-be set in the pre-processor, but does not influence the choice
-of runtime library/startup code.
-.IP "\fB\-mwindows\fR" 4
-.IX Item "-mwindows"
-This option is available for Cygwin and MinGW targets. It
-specifies that a \s-1GUI\s0 application is to be generated by
-instructing the linker to set the \s-1PE\s0 header subsystem type
-appropriately.
-.IP "\fB\-fno\-set\-stack\-executable\fR" 4
-.IX Item "-fno-set-stack-executable"
-This option is available for MinGW targets. It specifies that
-the executable flag for stack used by nested functions isn't
-set. This is necessary for binaries running in kernel mode of
-Windows, as there the user32 \s-1API\s0, which is used to set executable
-privileges, isn't available.
-.IP "\fB\-mpe\-aligned\-commons\fR" 4
-.IX Item "-mpe-aligned-commons"
-This option is available for Cygwin and MinGW targets. It
-specifies that the \s-1GNU\s0 extension to the \s-1PE\s0 file format that
-permits the correct alignment of \s-1COMMON\s0 variables should be
-used when generating code. It will be enabled by default if
-\&\s-1GCC\s0 detects that the target assembler found during configuration
-supports the feature.
-.PP
-See also under \fBi386 and x86\-64 Options\fR for standard options.
-.PP
-\fI\s-1IA\-64\s0 Options\fR
-.IX Subsection "IA-64 Options"
-.PP
-These are the \fB\-m\fR options defined for the Intel \s-1IA\-64\s0 architecture.
-.IP "\fB\-mbig\-endian\fR" 4
-.IX Item "-mbig-endian"
-Generate code for a big endian target. This is the default for HP-UX.
-.IP "\fB\-mlittle\-endian\fR" 4
-.IX Item "-mlittle-endian"
-Generate code for a little endian target. This is the default for \s-1AIX5\s0
-and GNU/Linux.
-.IP "\fB\-mgnu\-as\fR" 4
-.IX Item "-mgnu-as"
-.PD 0
-.IP "\fB\-mno\-gnu\-as\fR" 4
-.IX Item "-mno-gnu-as"
-.PD
-Generate (or don't) code for the \s-1GNU\s0 assembler. This is the default.
-.IP "\fB\-mgnu\-ld\fR" 4
-.IX Item "-mgnu-ld"
-.PD 0
-.IP "\fB\-mno\-gnu\-ld\fR" 4
-.IX Item "-mno-gnu-ld"
-.PD
-Generate (or don't) code for the \s-1GNU\s0 linker. This is the default.
-.IP "\fB\-mno\-pic\fR" 4
-.IX Item "-mno-pic"
-Generate code that does not use a global pointer register. The result
-is not position independent code, and violates the \s-1IA\-64\s0 \s-1ABI\s0.
-.IP "\fB\-mvolatile\-asm\-stop\fR" 4
-.IX Item "-mvolatile-asm-stop"
-.PD 0
-.IP "\fB\-mno\-volatile\-asm\-stop\fR" 4
-.IX Item "-mno-volatile-asm-stop"
-.PD
-Generate (or don't) a stop bit immediately before and after volatile asm
-statements.
-.IP "\fB\-mregister\-names\fR" 4
-.IX Item "-mregister-names"
-.PD 0
-.IP "\fB\-mno\-register\-names\fR" 4
-.IX Item "-mno-register-names"
-.PD
-Generate (or don't) \fBin\fR, \fBloc\fR, and \fBout\fR register names for
-the stacked registers. This may make assembler output more readable.
-.IP "\fB\-mno\-sdata\fR" 4
-.IX Item "-mno-sdata"
-.PD 0
-.IP "\fB\-msdata\fR" 4
-.IX Item "-msdata"
-.PD
-Disable (or enable) optimizations that use the small data section. This may
-be useful for working around optimizer bugs.
-.IP "\fB\-mconstant\-gp\fR" 4
-.IX Item "-mconstant-gp"
-Generate code that uses a single constant global pointer value. This is
-useful when compiling kernel code.
-.IP "\fB\-mauto\-pic\fR" 4
-.IX Item "-mauto-pic"
-Generate code that is self-relocatable. This implies \fB\-mconstant\-gp\fR.
-This is useful when compiling firmware code.
-.IP "\fB\-minline\-float\-divide\-min\-latency\fR" 4
-.IX Item "-minline-float-divide-min-latency"
-Generate code for inline divides of floating point values
-using the minimum latency algorithm.
-.IP "\fB\-minline\-float\-divide\-max\-throughput\fR" 4
-.IX Item "-minline-float-divide-max-throughput"
-Generate code for inline divides of floating point values
-using the maximum throughput algorithm.
-.IP "\fB\-mno\-inline\-float\-divide\fR" 4
-.IX Item "-mno-inline-float-divide"
-Do not generate inline code for divides of floating point values.
-.IP "\fB\-minline\-int\-divide\-min\-latency\fR" 4
-.IX Item "-minline-int-divide-min-latency"
-Generate code for inline divides of integer values
-using the minimum latency algorithm.
-.IP "\fB\-minline\-int\-divide\-max\-throughput\fR" 4
-.IX Item "-minline-int-divide-max-throughput"
-Generate code for inline divides of integer values
-using the maximum throughput algorithm.
-.IP "\fB\-mno\-inline\-int\-divide\fR" 4
-.IX Item "-mno-inline-int-divide"
-Do not generate inline code for divides of integer values.
-.IP "\fB\-minline\-sqrt\-min\-latency\fR" 4
-.IX Item "-minline-sqrt-min-latency"
-Generate code for inline square roots
-using the minimum latency algorithm.
-.IP "\fB\-minline\-sqrt\-max\-throughput\fR" 4
-.IX Item "-minline-sqrt-max-throughput"
-Generate code for inline square roots
-using the maximum throughput algorithm.
-.IP "\fB\-mno\-inline\-sqrt\fR" 4
-.IX Item "-mno-inline-sqrt"
-Do not generate inline code for sqrt.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Do (don't) generate code that uses the fused multiply/add or multiply/subtract
-instructions. The default is to use these instructions.
-.IP "\fB\-mno\-dwarf2\-asm\fR" 4
-.IX Item "-mno-dwarf2-asm"
-.PD 0
-.IP "\fB\-mdwarf2\-asm\fR" 4
-.IX Item "-mdwarf2-asm"
-.PD
-Don't (or do) generate assembler code for the \s-1DWARF2\s0 line number debugging
-info. This may be useful when not using the \s-1GNU\s0 assembler.
-.IP "\fB\-mearly\-stop\-bits\fR" 4
-.IX Item "-mearly-stop-bits"
-.PD 0
-.IP "\fB\-mno\-early\-stop\-bits\fR" 4
-.IX Item "-mno-early-stop-bits"
-.PD
-Allow stop bits to be placed earlier than immediately preceding the
-instruction that triggered the stop bit. This can improve instruction
-scheduling, but does not always do so.
-.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
-.IX Item "-mfixed-range=register-range"
-Generate code treating the given register range as fixed registers.
-A fixed register is one that the register allocator can not use. This is
-useful when compiling kernel code. A register range is specified as
-two registers separated by a dash. Multiple register ranges can be
-specified separated by a comma.
-.IP "\fB\-mtls\-size=\fR\fItls-size\fR" 4
-.IX Item "-mtls-size=tls-size"
-Specify bit size of immediate \s-1TLS\s0 offsets. Valid values are 14, 22, and
-64.
-.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
-.IX Item "-mtune=cpu-type"
-Tune the instruction scheduling for a particular \s-1CPU\s0, Valid values are
-itanium, itanium1, merced, itanium2, and mckinley.
-.IP "\fB\-milp32\fR" 4
-.IX Item "-milp32"
-.PD 0
-.IP "\fB\-mlp64\fR" 4
-.IX Item "-mlp64"
-.PD
-Generate code for a 32\-bit or 64\-bit environment.
-The 32\-bit environment sets int, long and pointer to 32 bits.
-The 64\-bit environment sets int to 32 bits and long and pointer
-to 64 bits. These are HP-UX specific flags.
-.IP "\fB\-mno\-sched\-br\-data\-spec\fR" 4
-.IX Item "-mno-sched-br-data-spec"
-.PD 0
-.IP "\fB\-msched\-br\-data\-spec\fR" 4
-.IX Item "-msched-br-data-spec"
-.PD
-(Dis/En)able data speculative scheduling before reload.
-This will result in generation of the ld.a instructions and
-the corresponding check instructions (ld.c / chk.a).
-The default is 'disable'.
-.IP "\fB\-msched\-ar\-data\-spec\fR" 4
-.IX Item "-msched-ar-data-spec"
-.PD 0
-.IP "\fB\-mno\-sched\-ar\-data\-spec\fR" 4
-.IX Item "-mno-sched-ar-data-spec"
-.PD
-(En/Dis)able data speculative scheduling after reload.
-This will result in generation of the ld.a instructions and
-the corresponding check instructions (ld.c / chk.a).
-The default is 'enable'.
-.IP "\fB\-mno\-sched\-control\-spec\fR" 4
-.IX Item "-mno-sched-control-spec"
-.PD 0
-.IP "\fB\-msched\-control\-spec\fR" 4
-.IX Item "-msched-control-spec"
-.PD
-(Dis/En)able control speculative scheduling. This feature is
-available only during region scheduling (i.e. before reload).
-This will result in generation of the ld.s instructions and
-the corresponding check instructions chk.s .
-The default is 'disable'.
-.IP "\fB\-msched\-br\-in\-data\-spec\fR" 4
-.IX Item "-msched-br-in-data-spec"
-.PD 0
-.IP "\fB\-mno\-sched\-br\-in\-data\-spec\fR" 4
-.IX Item "-mno-sched-br-in-data-spec"
-.PD
-(En/Dis)able speculative scheduling of the instructions that
-are dependent on the data speculative loads before reload.
-This is effective only with \fB\-msched\-br\-data\-spec\fR enabled.
-The default is 'enable'.
-.IP "\fB\-msched\-ar\-in\-data\-spec\fR" 4
-.IX Item "-msched-ar-in-data-spec"
-.PD 0
-.IP "\fB\-mno\-sched\-ar\-in\-data\-spec\fR" 4
-.IX Item "-mno-sched-ar-in-data-spec"
-.PD
-(En/Dis)able speculative scheduling of the instructions that
-are dependent on the data speculative loads after reload.
-This is effective only with \fB\-msched\-ar\-data\-spec\fR enabled.
-The default is 'enable'.
-.IP "\fB\-msched\-in\-control\-spec\fR" 4
-.IX Item "-msched-in-control-spec"
-.PD 0
-.IP "\fB\-mno\-sched\-in\-control\-spec\fR" 4
-.IX Item "-mno-sched-in-control-spec"
-.PD
-(En/Dis)able speculative scheduling of the instructions that
-are dependent on the control speculative loads.
-This is effective only with \fB\-msched\-control\-spec\fR enabled.
-The default is 'enable'.
-.IP "\fB\-mno\-sched\-prefer\-non\-data\-spec\-insns\fR" 4
-.IX Item "-mno-sched-prefer-non-data-spec-insns"
-.PD 0
-.IP "\fB\-msched\-prefer\-non\-data\-spec\-insns\fR" 4
-.IX Item "-msched-prefer-non-data-spec-insns"
-.PD
-If enabled, data speculative instructions will be chosen for schedule
-only if there are no other choices at the moment. This will make
-the use of the data speculation much more conservative.
-The default is 'disable'.
-.IP "\fB\-mno\-sched\-prefer\-non\-control\-spec\-insns\fR" 4
-.IX Item "-mno-sched-prefer-non-control-spec-insns"
-.PD 0
-.IP "\fB\-msched\-prefer\-non\-control\-spec\-insns\fR" 4
-.IX Item "-msched-prefer-non-control-spec-insns"
-.PD
-If enabled, control speculative instructions will be chosen for schedule
-only if there are no other choices at the moment. This will make
-the use of the control speculation much more conservative.
-The default is 'disable'.
-.IP "\fB\-mno\-sched\-count\-spec\-in\-critical\-path\fR" 4
-.IX Item "-mno-sched-count-spec-in-critical-path"
-.PD 0
-.IP "\fB\-msched\-count\-spec\-in\-critical\-path\fR" 4
-.IX Item "-msched-count-spec-in-critical-path"
-.PD
-If enabled, speculative dependencies will be considered during
-computation of the instructions priorities. This will make the use of the
-speculation a bit more conservative.
-The default is 'disable'.
-.IP "\fB\-msched\-spec\-ldc\fR" 4
-.IX Item "-msched-spec-ldc"
-Use a simple data speculation check. This option is on by default.
-.IP "\fB\-msched\-control\-spec\-ldc\fR" 4
-.IX Item "-msched-control-spec-ldc"
-Use a simple check for control speculation. This option is on by default.
-.IP "\fB\-msched\-stop\-bits\-after\-every\-cycle\fR" 4
-.IX Item "-msched-stop-bits-after-every-cycle"
-Place a stop bit after every cycle when scheduling. This option is on
-by default.
-.IP "\fB\-msched\-fp\-mem\-deps\-zero\-cost\fR" 4
-.IX Item "-msched-fp-mem-deps-zero-cost"
-Assume that floating-point stores and loads are not likely to cause a conflict
-when placed into the same instruction group. This option is disabled by
-default.
-.IP "\fB\-msel\-sched\-dont\-check\-control\-spec\fR" 4
-.IX Item "-msel-sched-dont-check-control-spec"
-Generate checks for control speculation in selective scheduling.
-This flag is disabled by default.
-.IP "\fB\-msched\-max\-memory\-insns=\fR\fImax-insns\fR" 4
-.IX Item "-msched-max-memory-insns=max-insns"
-Limit on the number of memory insns per instruction group, giving lower
-priority to subsequent memory insns attempting to schedule in the same
-instruction group. Frequently useful to prevent cache bank conflicts.
-The default value is 1.
-.IP "\fB\-msched\-max\-memory\-insns\-hard\-limit\fR" 4
-.IX Item "-msched-max-memory-insns-hard-limit"
-Disallow more than `msched\-max\-memory\-insns' in instruction group.
-Otherwise, limit is `soft' meaning that we would prefer non-memory operations
-when limit is reached but may still schedule memory operations.
-.PP
-\fI\s-1IA\-64/VMS\s0 Options\fR
-.IX Subsection "IA-64/VMS Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1IA\-64/VMS\s0 implementations:
-.IP "\fB\-mvms\-return\-codes\fR" 4
-.IX Item "-mvms-return-codes"
-Return \s-1VMS\s0 condition codes from main. The default is to return \s-1POSIX\s0
-style condition (e.g. error) codes.
-.IP "\fB\-mdebug\-main=\fR\fIprefix\fR" 4
-.IX Item "-mdebug-main=prefix"
-Flag the first routine whose name starts with \fIprefix\fR as the main
-routine for the debugger.
-.IP "\fB\-mmalloc64\fR" 4
-.IX Item "-mmalloc64"
-Default to 64bit memory allocation routines.
-.PP
-\fI\s-1LM32\s0 Options\fR
-.IX Subsection "LM32 Options"
-.PP
-These \fB\-m\fR options are defined for the Lattice Mico32 architecture:
-.IP "\fB\-mbarrel\-shift\-enabled\fR" 4
-.IX Item "-mbarrel-shift-enabled"
-Enable barrel-shift instructions.
-.IP "\fB\-mdivide\-enabled\fR" 4
-.IX Item "-mdivide-enabled"
-Enable divide and modulus instructions.
-.IP "\fB\-mmultiply\-enabled\fR" 4
-.IX Item "-mmultiply-enabled"
-Enable multiply instructions.
-.IP "\fB\-msign\-extend\-enabled\fR" 4
-.IX Item "-msign-extend-enabled"
-Enable sign extend instructions.
-.IP "\fB\-muser\-enabled\fR" 4
-.IX Item "-muser-enabled"
-Enable user-defined instructions.
-.PP
-\fIM32C Options\fR
-.IX Subsection "M32C Options"
-.IP "\fB\-mcpu=\fR\fIname\fR" 4
-.IX Item "-mcpu=name"
-Select the \s-1CPU\s0 for which code is generated. \fIname\fR may be one of
-\&\fBr8c\fR for the R8C/Tiny series, \fBm16c\fR for the M16C (up to
-/60) series, \fBm32cm\fR for the M16C/80 series, or \fBm32c\fR for
-the M32C/80 series.
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-Specifies that the program will be run on the simulator. This causes
-an alternate runtime library to be linked in which supports, for
-example, file I/O. You must not use this option when generating
-programs that will run on real hardware; you must provide your own
-runtime library for whatever I/O functions are needed.
-.IP "\fB\-memregs=\fR\fInumber\fR" 4
-.IX Item "-memregs=number"
-Specifies the number of memory-based pseudo-registers \s-1GCC\s0 will use
-during code generation. These pseudo-registers will be used like real
-registers, so there is a tradeoff between \s-1GCC\s0's ability to fit the
-code into available registers, and the performance penalty of using
-memory instead of registers. Note that all modules in a program must
-be compiled with the same value for this option. Because of that, you
-must not use this option with the default runtime libraries gcc
-builds.
-.PP
-\fIM32R/D Options\fR
-.IX Subsection "M32R/D Options"
-.PP
-These \fB\-m\fR options are defined for Renesas M32R/D architectures:
-.IP "\fB\-m32r2\fR" 4
-.IX Item "-m32r2"
-Generate code for the M32R/2.
-.IP "\fB\-m32rx\fR" 4
-.IX Item "-m32rx"
-Generate code for the M32R/X.
-.IP "\fB\-m32r\fR" 4
-.IX Item "-m32r"
-Generate code for the M32R. This is the default.
-.IP "\fB\-mmodel=small\fR" 4
-.IX Item "-mmodel=small"
-Assume all objects live in the lower 16MB of memory (so that their addresses
-can be loaded with the \f(CW\*(C`ld24\*(C'\fR instruction), and assume all subroutines
-are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
-This is the default.
-.Sp
-The addressability of a particular object can be set with the
-\&\f(CW\*(C`model\*(C'\fR attribute.
-.IP "\fB\-mmodel=medium\fR" 4
-.IX Item "-mmodel=medium"
-Assume objects may be anywhere in the 32\-bit address space (the compiler
-will generate \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
-assume all subroutines are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
-.IP "\fB\-mmodel=large\fR" 4
-.IX Item "-mmodel=large"
-Assume objects may be anywhere in the 32\-bit address space (the compiler
-will generate \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
-assume subroutines may not be reachable with the \f(CW\*(C`bl\*(C'\fR instruction
-(the compiler will generate the much slower \f(CW\*(C`seth/add3/jl\*(C'\fR
-instruction sequence).
-.IP "\fB\-msdata=none\fR" 4
-.IX Item "-msdata=none"
-Disable use of the small data area. Variables will be put into
-one of \fB.data\fR, \fBbss\fR, or \fB.rodata\fR (unless the
-\&\f(CW\*(C`section\*(C'\fR attribute has been specified).
-This is the default.
-.Sp
-The small data area consists of sections \fB.sdata\fR and \fB.sbss\fR.
-Objects may be explicitly put in the small data area with the
-\&\f(CW\*(C`section\*(C'\fR attribute using one of these sections.
-.IP "\fB\-msdata=sdata\fR" 4
-.IX Item "-msdata=sdata"
-Put small global and static data in the small data area, but do not
-generate special code to reference them.
-.IP "\fB\-msdata=use\fR" 4
-.IX Item "-msdata=use"
-Put small global and static data in the small data area, and generate
-special instructions to reference them.
-.IP "\fB\-G\fR \fInum\fR" 4
-.IX Item "-G num"
-Put global and static objects less than or equal to \fInum\fR bytes
-into the small data or bss sections instead of the normal data or bss
-sections. The default value of \fInum\fR is 8.
-The \fB\-msdata\fR option must be set to one of \fBsdata\fR or \fBuse\fR
-for this option to have any effect.
-.Sp
-All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
-Compiling with different values of \fInum\fR may or may not work; if it
-doesn't the linker will give an error message\-\-\-incorrect code will not be
-generated.
-.IP "\fB\-mdebug\fR" 4
-.IX Item "-mdebug"
-Makes the M32R specific code in the compiler display some statistics
-that might help in debugging programs.
-.IP "\fB\-malign\-loops\fR" 4
-.IX Item "-malign-loops"
-Align all loops to a 32\-byte boundary.
-.IP "\fB\-mno\-align\-loops\fR" 4
-.IX Item "-mno-align-loops"
-Do not enforce a 32\-byte alignment for loops. This is the default.
-.IP "\fB\-missue\-rate=\fR\fInumber\fR" 4
-.IX Item "-missue-rate=number"
-Issue \fInumber\fR instructions per cycle. \fInumber\fR can only be 1
-or 2.
-.IP "\fB\-mbranch\-cost=\fR\fInumber\fR" 4
-.IX Item "-mbranch-cost=number"
-\&\fInumber\fR can only be 1 or 2. If it is 1 then branches will be
-preferred over conditional code, if it is 2, then the opposite will
-apply.
-.IP "\fB\-mflush\-trap=\fR\fInumber\fR" 4
-.IX Item "-mflush-trap=number"
-Specifies the trap number to use to flush the cache. The default is
-12. Valid numbers are between 0 and 15 inclusive.
-.IP "\fB\-mno\-flush\-trap\fR" 4
-.IX Item "-mno-flush-trap"
-Specifies that the cache cannot be flushed by using a trap.
-.IP "\fB\-mflush\-func=\fR\fIname\fR" 4
-.IX Item "-mflush-func=name"
-Specifies the name of the operating system function to call to flush
-the cache. The default is \fI_flush_cache\fR, but a function call
-will only be used if a trap is not available.
-.IP "\fB\-mno\-flush\-func\fR" 4
-.IX Item "-mno-flush-func"
-Indicates that there is no \s-1OS\s0 function for flushing the cache.
-.PP
-\fIM680x0 Options\fR
-.IX Subsection "M680x0 Options"
-.PP
-These are the \fB\-m\fR options defined for M680x0 and ColdFire processors.
-The default settings depend on which architecture was selected when
-the compiler was configured; the defaults for the most common choices
-are given below.
-.IP "\fB\-march=\fR\fIarch\fR" 4
-.IX Item "-march=arch"
-Generate code for a specific M680x0 or ColdFire instruction set
-architecture. Permissible values of \fIarch\fR for M680x0
-architectures are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
-\&\fB68030\fR, \fB68040\fR, \fB68060\fR and \fBcpu32\fR. ColdFire
-architectures are selected according to Freescale's \s-1ISA\s0 classification
-and the permissible values are: \fBisaa\fR, \fBisaaplus\fR,
-\&\fBisab\fR and \fBisac\fR.
-.Sp
-gcc defines a macro \fB_\|_mcf\fR\fIarch\fR\fB_\|_\fR whenever it is generating
-code for a ColdFire target. The \fIarch\fR in this macro is one of the
-\&\fB\-march\fR arguments given above.
-.Sp
-When used together, \fB\-march\fR and \fB\-mtune\fR select code
-that runs on a family of similar processors but that is optimized
-for a particular microarchitecture.
-.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
-.IX Item "-mcpu=cpu"
-Generate code for a specific M680x0 or ColdFire processor.
-The M680x0 \fIcpu\fRs are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
-\&\fB68030\fR, \fB68040\fR, \fB68060\fR, \fB68302\fR, \fB68332\fR
-and \fBcpu32\fR. The ColdFire \fIcpu\fRs are given by the table
-below, which also classifies the CPUs into families:
-.RS 4
-.IP "Family : \fB\-mcpu\fR arguments" 4
-.IX Item "Family : -mcpu arguments"
-.PD 0
-.IP "\fB51\fR : \fB51\fR \fB51ac\fR \fB51cn\fR \fB51em\fR \fB51qe\fR" 4
-.IX Item "51 : 51 51ac 51cn 51em 51qe"
-.IP "\fB5206\fR : \fB5202\fR \fB5204\fR \fB5206\fR" 4
-.IX Item "5206 : 5202 5204 5206"
-.IP "\fB5206e\fR : \fB5206e\fR" 4
-.IX Item "5206e : 5206e"
-.IP "\fB5208\fR : \fB5207\fR \fB5208\fR" 4
-.IX Item "5208 : 5207 5208"
-.IP "\fB5211a\fR : \fB5210a\fR \fB5211a\fR" 4
-.IX Item "5211a : 5210a 5211a"
-.IP "\fB5213\fR : \fB5211\fR \fB5212\fR \fB5213\fR" 4
-.IX Item "5213 : 5211 5212 5213"
-.IP "\fB5216\fR : \fB5214\fR \fB5216\fR" 4
-.IX Item "5216 : 5214 5216"
-.IP "\fB52235\fR : \fB52230\fR \fB52231\fR \fB52232\fR \fB52233\fR \fB52234\fR \fB52235\fR" 4
-.IX Item "52235 : 52230 52231 52232 52233 52234 52235"
-.IP "\fB5225\fR : \fB5224\fR \fB5225\fR" 4
-.IX Item "5225 : 5224 5225"
-.IP "\fB52259\fR : \fB52252\fR \fB52254\fR \fB52255\fR \fB52256\fR \fB52258\fR \fB52259\fR" 4
-.IX Item "52259 : 52252 52254 52255 52256 52258 52259"
-.IP "\fB5235\fR : \fB5232\fR \fB5233\fR \fB5234\fR \fB5235\fR \fB523x\fR" 4
-.IX Item "5235 : 5232 5233 5234 5235 523x"
-.IP "\fB5249\fR : \fB5249\fR" 4
-.IX Item "5249 : 5249"
-.IP "\fB5250\fR : \fB5250\fR" 4
-.IX Item "5250 : 5250"
-.IP "\fB5271\fR : \fB5270\fR \fB5271\fR" 4
-.IX Item "5271 : 5270 5271"
-.IP "\fB5272\fR : \fB5272\fR" 4
-.IX Item "5272 : 5272"
-.IP "\fB5275\fR : \fB5274\fR \fB5275\fR" 4
-.IX Item "5275 : 5274 5275"
-.IP "\fB5282\fR : \fB5280\fR \fB5281\fR \fB5282\fR \fB528x\fR" 4
-.IX Item "5282 : 5280 5281 5282 528x"
-.IP "\fB53017\fR : \fB53011\fR \fB53012\fR \fB53013\fR \fB53014\fR \fB53015\fR \fB53016\fR \fB53017\fR" 4
-.IX Item "53017 : 53011 53012 53013 53014 53015 53016 53017"
-.IP "\fB5307\fR : \fB5307\fR" 4
-.IX Item "5307 : 5307"
-.IP "\fB5329\fR : \fB5327\fR \fB5328\fR \fB5329\fR \fB532x\fR" 4
-.IX Item "5329 : 5327 5328 5329 532x"
-.IP "\fB5373\fR : \fB5372\fR \fB5373\fR \fB537x\fR" 4
-.IX Item "5373 : 5372 5373 537x"
-.IP "\fB5407\fR : \fB5407\fR" 4
-.IX Item "5407 : 5407"
-.IP "\fB5475\fR : \fB5470\fR \fB5471\fR \fB5472\fR \fB5473\fR \fB5474\fR \fB5475\fR \fB547x\fR \fB5480\fR \fB5481\fR \fB5482\fR \fB5483\fR \fB5484\fR \fB5485\fR" 4
-.IX Item "5475 : 5470 5471 5472 5473 5474 5475 547x 5480 5481 5482 5483 5484 5485"
-.RE
-.RS 4
-.PD
-.Sp
-\&\fB\-mcpu=\fR\fIcpu\fR overrides \fB\-march=\fR\fIarch\fR if
-\&\fIarch\fR is compatible with \fIcpu\fR. Other combinations of
-\&\fB\-mcpu\fR and \fB\-march\fR are rejected.
-.Sp
-gcc defines the macro \fB_\|_mcf_cpu_\fR\fIcpu\fR when ColdFire target
-\&\fIcpu\fR is selected. It also defines \fB_\|_mcf_family_\fR\fIfamily\fR,
-where the value of \fIfamily\fR is given by the table above.
-.RE
-.IP "\fB\-mtune=\fR\fItune\fR" 4
-.IX Item "-mtune=tune"
-Tune the code for a particular microarchitecture, within the
-constraints set by \fB\-march\fR and \fB\-mcpu\fR.
-The M680x0 microarchitectures are: \fB68000\fR, \fB68010\fR,
-\&\fB68020\fR, \fB68030\fR, \fB68040\fR, \fB68060\fR
-and \fBcpu32\fR. The ColdFire microarchitectures
-are: \fBcfv1\fR, \fBcfv2\fR, \fBcfv3\fR, \fBcfv4\fR and \fBcfv4e\fR.
-.Sp
-You can also use \fB\-mtune=68020\-40\fR for code that needs
-to run relatively well on 68020, 68030 and 68040 targets.
-\&\fB\-mtune=68020\-60\fR is similar but includes 68060 targets
-as well. These two options select the same tuning decisions as
-\&\fB\-m68020\-40\fR and \fB\-m68020\-60\fR respectively.
-.Sp
-gcc defines the macros \fB_\|_mc\fR\fIarch\fR and \fB_\|_mc\fR\fIarch\fR\fB_\|_\fR
-when tuning for 680x0 architecture \fIarch\fR. It also defines
-\&\fBmc\fR\fIarch\fR unless either \fB\-ansi\fR or a non-GNU \fB\-std\fR
-option is used. If gcc is tuning for a range of architectures,
-as selected by \fB\-mtune=68020\-40\fR or \fB\-mtune=68020\-60\fR,
-it defines the macros for every architecture in the range.
-.Sp
-gcc also defines the macro \fB_\|_m\fR\fIuarch\fR\fB_\|_\fR when tuning for
-ColdFire microarchitecture \fIuarch\fR, where \fIuarch\fR is one
-of the arguments given above.
-.IP "\fB\-m68000\fR" 4
-.IX Item "-m68000"
-.PD 0
-.IP "\fB\-mc68000\fR" 4
-.IX Item "-mc68000"
-.PD
-Generate output for a 68000. This is the default
-when the compiler is configured for 68000\-based systems.
-It is equivalent to \fB\-march=68000\fR.
-.Sp
-Use this option for microcontrollers with a 68000 or \s-1EC000\s0 core,
-including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
-.IP "\fB\-m68010\fR" 4
-.IX Item "-m68010"
-Generate output for a 68010. This is the default
-when the compiler is configured for 68010\-based systems.
-It is equivalent to \fB\-march=68010\fR.
-.IP "\fB\-m68020\fR" 4
-.IX Item "-m68020"
-.PD 0
-.IP "\fB\-mc68020\fR" 4
-.IX Item "-mc68020"
-.PD
-Generate output for a 68020. This is the default
-when the compiler is configured for 68020\-based systems.
-It is equivalent to \fB\-march=68020\fR.
-.IP "\fB\-m68030\fR" 4
-.IX Item "-m68030"
-Generate output for a 68030. This is the default when the compiler is
-configured for 68030\-based systems. It is equivalent to
-\&\fB\-march=68030\fR.
-.IP "\fB\-m68040\fR" 4
-.IX Item "-m68040"
-Generate output for a 68040. This is the default when the compiler is
-configured for 68040\-based systems. It is equivalent to
-\&\fB\-march=68040\fR.
-.Sp
-This option inhibits the use of 68881/68882 instructions that have to be
-emulated by software on the 68040. Use this option if your 68040 does not
-have code to emulate those instructions.
-.IP "\fB\-m68060\fR" 4
-.IX Item "-m68060"
-Generate output for a 68060. This is the default when the compiler is
-configured for 68060\-based systems. It is equivalent to
-\&\fB\-march=68060\fR.
-.Sp
-This option inhibits the use of 68020 and 68881/68882 instructions that
-have to be emulated by software on the 68060. Use this option if your 68060
-does not have code to emulate those instructions.
-.IP "\fB\-mcpu32\fR" 4
-.IX Item "-mcpu32"
-Generate output for a \s-1CPU32\s0. This is the default
-when the compiler is configured for CPU32\-based systems.
-It is equivalent to \fB\-march=cpu32\fR.
-.Sp
-Use this option for microcontrollers with a
-\&\s-1CPU32\s0 or \s-1CPU32+\s0 core, including the 68330, 68331, 68332, 68333, 68334,
-68336, 68340, 68341, 68349 and 68360.
-.IP "\fB\-m5200\fR" 4
-.IX Item "-m5200"
-Generate output for a 520X ColdFire \s-1CPU\s0. This is the default
-when the compiler is configured for 520X\-based systems.
-It is equivalent to \fB\-mcpu=5206\fR, and is now deprecated
-in favor of that option.
-.Sp
-Use this option for microcontroller with a 5200 core, including
-the \s-1MCF5202\s0, \s-1MCF5203\s0, \s-1MCF5204\s0 and \s-1MCF5206\s0.
-.IP "\fB\-m5206e\fR" 4
-.IX Item "-m5206e"
-Generate output for a 5206e ColdFire \s-1CPU\s0. The option is now
-deprecated in favor of the equivalent \fB\-mcpu=5206e\fR.
-.IP "\fB\-m528x\fR" 4
-.IX Item "-m528x"
-Generate output for a member of the ColdFire 528X family.
-The option is now deprecated in favor of the equivalent
-\&\fB\-mcpu=528x\fR.
-.IP "\fB\-m5307\fR" 4
-.IX Item "-m5307"
-Generate output for a ColdFire 5307 \s-1CPU\s0. The option is now deprecated
-in favor of the equivalent \fB\-mcpu=5307\fR.
-.IP "\fB\-m5407\fR" 4
-.IX Item "-m5407"
-Generate output for a ColdFire 5407 \s-1CPU\s0. The option is now deprecated
-in favor of the equivalent \fB\-mcpu=5407\fR.
-.IP "\fB\-mcfv4e\fR" 4
-.IX Item "-mcfv4e"
-Generate output for a ColdFire V4e family \s-1CPU\s0 (e.g. 547x/548x).
-This includes use of hardware floating point instructions.
-The option is equivalent to \fB\-mcpu=547x\fR, and is now
-deprecated in favor of that option.
-.IP "\fB\-m68020\-40\fR" 4
-.IX Item "-m68020-40"
-Generate output for a 68040, without using any of the new instructions.
-This results in code which can run relatively efficiently on either a
-68020/68881 or a 68030 or a 68040. The generated code does use the
-68881 instructions that are emulated on the 68040.
-.Sp
-The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-40\fR.
-.IP "\fB\-m68020\-60\fR" 4
-.IX Item "-m68020-60"
-Generate output for a 68060, without using any of the new instructions.
-This results in code which can run relatively efficiently on either a
-68020/68881 or a 68030 or a 68040. The generated code does use the
-68881 instructions that are emulated on the 68060.
-.Sp
-The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-60\fR.
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-.PD 0
-.IP "\fB\-m68881\fR" 4
-.IX Item "-m68881"
-.PD
-Generate floating-point instructions. This is the default for 68020
-and above, and for ColdFire devices that have an \s-1FPU\s0. It defines the
-macro \fB_\|_HAVE_68881_\|_\fR on M680x0 targets and \fB_\|_mcffpu_\|_\fR
-on ColdFire targets.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Do not generate floating-point instructions; use library calls instead.
-This is the default for 68000, 68010, and 68832 targets. It is also
-the default for ColdFire devices that have no \s-1FPU\s0.
-.IP "\fB\-mdiv\fR" 4
-.IX Item "-mdiv"
-.PD 0
-.IP "\fB\-mno\-div\fR" 4
-.IX Item "-mno-div"
-.PD
-Generate (do not generate) ColdFire hardware divide and remainder
-instructions. If \fB\-march\fR is used without \fB\-mcpu\fR,
-the default is \*(L"on\*(R" for ColdFire architectures and \*(L"off\*(R" for M680x0
-architectures. Otherwise, the default is taken from the target \s-1CPU\s0
-(either the default \s-1CPU\s0, or the one specified by \fB\-mcpu\fR). For
-example, the default is \*(L"off\*(R" for \fB\-mcpu=5206\fR and \*(L"on\*(R" for
-\&\fB\-mcpu=5206e\fR.
-.Sp
-gcc defines the macro \fB_\|_mcfhwdiv_\|_\fR when this option is enabled.
-.IP "\fB\-mshort\fR" 4
-.IX Item "-mshort"
-Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR.
-Additionally, parameters passed on the stack are also aligned to a
-16\-bit boundary even on targets whose \s-1API\s0 mandates promotion to 32\-bit.
-.IP "\fB\-mno\-short\fR" 4
-.IX Item "-mno-short"
-Do not consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide. This is the default.
-.IP "\fB\-mnobitfield\fR" 4
-.IX Item "-mnobitfield"
-.PD 0
-.IP "\fB\-mno\-bitfield\fR" 4
-.IX Item "-mno-bitfield"
-.PD
-Do not use the bit-field instructions. The \fB\-m68000\fR, \fB\-mcpu32\fR
-and \fB\-m5200\fR options imply \fB\-mnobitfield\fR.
-.IP "\fB\-mbitfield\fR" 4
-.IX Item "-mbitfield"
-Do use the bit-field instructions. The \fB\-m68020\fR option implies
-\&\fB\-mbitfield\fR. This is the default if you use a configuration
-designed for a 68020.
-.IP "\fB\-mrtd\fR" 4
-.IX Item "-mrtd"
-Use a different function-calling convention, in which functions
-that take a fixed number of arguments return with the \f(CW\*(C`rtd\*(C'\fR
-instruction, which pops their arguments while returning. This
-saves one instruction in the caller since there is no need to pop
-the arguments there.
-.Sp
-This calling convention is incompatible with the one normally
-used on Unix, so you cannot use it if you need to call libraries
-compiled with the Unix compiler.
-.Sp
-Also, you must provide function prototypes for all functions that
-take variable numbers of arguments (including \f(CW\*(C`printf\*(C'\fR);
-otherwise incorrect code will be generated for calls to those
-functions.
-.Sp
-In addition, seriously incorrect code will result if you call a
-function with too many arguments. (Normally, extra arguments are
-harmlessly ignored.)
-.Sp
-The \f(CW\*(C`rtd\*(C'\fR instruction is supported by the 68010, 68020, 68030,
-68040, 68060 and \s-1CPU32\s0 processors, but not by the 68000 or 5200.
-.IP "\fB\-mno\-rtd\fR" 4
-.IX Item "-mno-rtd"
-Do not use the calling conventions selected by \fB\-mrtd\fR.
-This is the default.
-.IP "\fB\-malign\-int\fR" 4
-.IX Item "-malign-int"
-.PD 0
-.IP "\fB\-mno\-align\-int\fR" 4
-.IX Item "-mno-align-int"
-.PD
-Control whether \s-1GCC\s0 aligns \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`long long\*(C'\fR,
-\&\f(CW\*(C`float\*(C'\fR, \f(CW\*(C`double\*(C'\fR, and \f(CW\*(C`long double\*(C'\fR variables on a 32\-bit
-boundary (\fB\-malign\-int\fR) or a 16\-bit boundary (\fB\-mno\-align\-int\fR).
-Aligning variables on 32\-bit boundaries produces code that runs somewhat
-faster on processors with 32\-bit busses at the expense of more memory.
-.Sp
-\&\fBWarning:\fR if you use the \fB\-malign\-int\fR switch, \s-1GCC\s0 will
-align structures containing the above types differently than
-most published application binary interface specifications for the m68k.
-.IP "\fB\-mpcrel\fR" 4
-.IX Item "-mpcrel"
-Use the pc-relative addressing mode of the 68000 directly, instead of
-using a global offset table. At present, this option implies \fB\-fpic\fR,
-allowing at most a 16\-bit offset for pc-relative addressing. \fB\-fPIC\fR is
-not presently supported with \fB\-mpcrel\fR, though this could be supported for
-68020 and higher processors.
-.IP "\fB\-mno\-strict\-align\fR" 4
-.IX Item "-mno-strict-align"
-.PD 0
-.IP "\fB\-mstrict\-align\fR" 4
-.IX Item "-mstrict-align"
-.PD
-Do not (do) assume that unaligned memory references will be handled by
-the system.
-.IP "\fB\-msep\-data\fR" 4
-.IX Item "-msep-data"
-Generate code that allows the data segment to be located in a different
-area of memory from the text segment. This allows for execute in place in
-an environment without virtual memory management. This option implies
-\&\fB\-fPIC\fR.
-.IP "\fB\-mno\-sep\-data\fR" 4
-.IX Item "-mno-sep-data"
-Generate code that assumes that the data segment follows the text segment.
-This is the default.
-.IP "\fB\-mid\-shared\-library\fR" 4
-.IX Item "-mid-shared-library"
-Generate code that supports shared libraries via the library \s-1ID\s0 method.
-This allows for execute in place and shared libraries in an environment
-without virtual memory management. This option implies \fB\-fPIC\fR.
-.IP "\fB\-mno\-id\-shared\-library\fR" 4
-.IX Item "-mno-id-shared-library"
-Generate code that doesn't assume \s-1ID\s0 based shared libraries are being used.
-This is the default.
-.IP "\fB\-mshared\-library\-id=n\fR" 4
-.IX Item "-mshared-library-id=n"
-Specified the identification number of the \s-1ID\s0 based shared library being
-compiled. Specifying a value of 0 will generate more compact code, specifying
-other values will force the allocation of that number to the current
-library but is no more space or time efficient than omitting this option.
-.IP "\fB\-mxgot\fR" 4
-.IX Item "-mxgot"
-.PD 0
-.IP "\fB\-mno\-xgot\fR" 4
-.IX Item "-mno-xgot"
-.PD
-When generating position-independent code for ColdFire, generate code
-that works if the \s-1GOT\s0 has more than 8192 entries. This code is
-larger and slower than code generated without this option. On M680x0
-processors, this option is not needed; \fB\-fPIC\fR suffices.
-.Sp
-\&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT\s0.
-While this is relatively efficient, it only works if the \s-1GOT\s0
-is smaller than about 64k. Anything larger causes the linker
-to report an error such as:
-.Sp
-.Vb 1
-\& relocation truncated to fit: R_68K_GOT16O foobar
-.Ve
-.Sp
-If this happens, you should recompile your code with \fB\-mxgot\fR.
-It should then work with very large GOTs. However, code generated with
-\&\fB\-mxgot\fR is less efficient, since it takes 4 instructions to fetch
-the value of a global symbol.
-.Sp
-Note that some linkers, including newer versions of the \s-1GNU\s0 linker,
-can create multiple GOTs and sort \s-1GOT\s0 entries. If you have such a linker,
-you should only need to use \fB\-mxgot\fR when compiling a single
-object file that accesses more than 8192 \s-1GOT\s0 entries. Very few do.
-.Sp
-These options have no effect unless \s-1GCC\s0 is generating
-position-independent code.
-.PP
-\fIM68hc1x Options\fR
-.IX Subsection "M68hc1x Options"
-.PP
-These are the \fB\-m\fR options defined for the 68hc11 and 68hc12
-microcontrollers. The default values for these options depends on
-which style of microcontroller was selected when the compiler was configured;
-the defaults for the most common choices are given below.
-.IP "\fB\-m6811\fR" 4
-.IX Item "-m6811"
-.PD 0
-.IP "\fB\-m68hc11\fR" 4
-.IX Item "-m68hc11"
-.PD
-Generate output for a 68HC11. This is the default
-when the compiler is configured for 68HC11\-based systems.
-.IP "\fB\-m6812\fR" 4
-.IX Item "-m6812"
-.PD 0
-.IP "\fB\-m68hc12\fR" 4
-.IX Item "-m68hc12"
-.PD
-Generate output for a 68HC12. This is the default
-when the compiler is configured for 68HC12\-based systems.
-.IP "\fB\-m68S12\fR" 4
-.IX Item "-m68S12"
-.PD 0
-.IP "\fB\-m68hcs12\fR" 4
-.IX Item "-m68hcs12"
-.PD
-Generate output for a 68HCS12.
-.IP "\fB\-mauto\-incdec\fR" 4
-.IX Item "-mauto-incdec"
-Enable the use of 68HC12 pre and post auto-increment and auto-decrement
-addressing modes.
-.IP "\fB\-minmax\fR" 4
-.IX Item "-minmax"
-.PD 0
-.IP "\fB\-mnominmax\fR" 4
-.IX Item "-mnominmax"
-.PD
-Enable the use of 68HC12 min and max instructions.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-.PD 0
-.IP "\fB\-mno\-long\-calls\fR" 4
-.IX Item "-mno-long-calls"
-.PD
-Treat all calls as being far away (near). If calls are assumed to be
-far away, the compiler will use the \f(CW\*(C`call\*(C'\fR instruction to
-call a function and the \f(CW\*(C`rtc\*(C'\fR instruction for returning.
-.IP "\fB\-mshort\fR" 4
-.IX Item "-mshort"
-Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR.
-.IP "\fB\-msoft\-reg\-count=\fR\fIcount\fR" 4
-.IX Item "-msoft-reg-count=count"
-Specify the number of pseudo-soft registers which are used for the
-code generation. The maximum number is 32. Using more pseudo-soft
-register may or may not result in better code depending on the program.
-The default is 4 for 68HC11 and 2 for 68HC12.
-.PP
-\fIMCore Options\fR
-.IX Subsection "MCore Options"
-.PP
-These are the \fB\-m\fR options defined for the Motorola M*Core
-processors.
-.IP "\fB\-mhardlit\fR" 4
-.IX Item "-mhardlit"
-.PD 0
-.IP "\fB\-mno\-hardlit\fR" 4
-.IX Item "-mno-hardlit"
-.PD
-Inline constants into the code stream if it can be done in two
-instructions or less.
-.IP "\fB\-mdiv\fR" 4
-.IX Item "-mdiv"
-.PD 0
-.IP "\fB\-mno\-div\fR" 4
-.IX Item "-mno-div"
-.PD
-Use the divide instruction. (Enabled by default).
-.IP "\fB\-mrelax\-immediate\fR" 4
-.IX Item "-mrelax-immediate"
-.PD 0
-.IP "\fB\-mno\-relax\-immediate\fR" 4
-.IX Item "-mno-relax-immediate"
-.PD
-Allow arbitrary sized immediates in bit operations.
-.IP "\fB\-mwide\-bitfields\fR" 4
-.IX Item "-mwide-bitfields"
-.PD 0
-.IP "\fB\-mno\-wide\-bitfields\fR" 4
-.IX Item "-mno-wide-bitfields"
-.PD
-Always treat bit-fields as int-sized.
-.IP "\fB\-m4byte\-functions\fR" 4
-.IX Item "-m4byte-functions"
-.PD 0
-.IP "\fB\-mno\-4byte\-functions\fR" 4
-.IX Item "-mno-4byte-functions"
-.PD
-Force all functions to be aligned to a four byte boundary.
-.IP "\fB\-mcallgraph\-data\fR" 4
-.IX Item "-mcallgraph-data"
-.PD 0
-.IP "\fB\-mno\-callgraph\-data\fR" 4
-.IX Item "-mno-callgraph-data"
-.PD
-Emit callgraph information.
-.IP "\fB\-mslow\-bytes\fR" 4
-.IX Item "-mslow-bytes"
-.PD 0
-.IP "\fB\-mno\-slow\-bytes\fR" 4
-.IX Item "-mno-slow-bytes"
-.PD
-Prefer word access when reading byte quantities.
-.IP "\fB\-mlittle\-endian\fR" 4
-.IX Item "-mlittle-endian"
-.PD 0
-.IP "\fB\-mbig\-endian\fR" 4
-.IX Item "-mbig-endian"
-.PD
-Generate code for a little endian target.
-.IP "\fB\-m210\fR" 4
-.IX Item "-m210"
-.PD 0
-.IP "\fB\-m340\fR" 4
-.IX Item "-m340"
-.PD
-Generate code for the 210 processor.
-.IP "\fB\-mno\-lsim\fR" 4
-.IX Item "-mno-lsim"
-Assume that run-time support has been provided and so omit the
-simulator library (\fIlibsim.a)\fR from the linker command line.
-.IP "\fB\-mstack\-increment=\fR\fIsize\fR" 4
-.IX Item "-mstack-increment=size"
-Set the maximum amount for a single stack increment operation. Large
-values can increase the speed of programs which contain functions
-that need a large amount of stack space, but they can also trigger a
-segmentation fault if the stack is extended too much. The default
-value is 0x1000.
-.PP
-\fIMeP Options\fR
-.IX Subsection "MeP Options"
-.IP "\fB\-mabsdiff\fR" 4
-.IX Item "-mabsdiff"
-Enables the \f(CW\*(C`abs\*(C'\fR instruction, which is the absolute difference
-between two registers.
-.IP "\fB\-mall\-opts\fR" 4
-.IX Item "-mall-opts"
-Enables all the optional instructions \- average, multiply, divide, bit
-operations, leading zero, absolute difference, min/max, clip, and
-saturation.
-.IP "\fB\-maverage\fR" 4
-.IX Item "-maverage"
-Enables the \f(CW\*(C`ave\*(C'\fR instruction, which computes the average of two
-registers.
-.IP "\fB\-mbased=\fR\fIn\fR" 4
-.IX Item "-mbased=n"
-Variables of size \fIn\fR bytes or smaller will be placed in the
-\&\f(CW\*(C`.based\*(C'\fR section by default. Based variables use the \f(CW$tp\fR
-register as a base register, and there is a 128 byte limit to the
-\&\f(CW\*(C`.based\*(C'\fR section.
-.IP "\fB\-mbitops\fR" 4
-.IX Item "-mbitops"
-Enables the bit operation instructions \- bit test (\f(CW\*(C`btstm\*(C'\fR), set
-(\f(CW\*(C`bsetm\*(C'\fR), clear (\f(CW\*(C`bclrm\*(C'\fR), invert (\f(CW\*(C`bnotm\*(C'\fR), and
-test-and-set (\f(CW\*(C`tas\*(C'\fR).
-.IP "\fB\-mc=\fR\fIname\fR" 4
-.IX Item "-mc=name"
-Selects which section constant data will be placed in. \fIname\fR may
-be \f(CW\*(C`tiny\*(C'\fR, \f(CW\*(C`near\*(C'\fR, or \f(CW\*(C`far\*(C'\fR.
-.IP "\fB\-mclip\fR" 4
-.IX Item "-mclip"
-Enables the \f(CW\*(C`clip\*(C'\fR instruction. Note that \f(CW\*(C`\-mclip\*(C'\fR is not
-useful unless you also provide \f(CW\*(C`\-mminmax\*(C'\fR.
-.IP "\fB\-mconfig=\fR\fIname\fR" 4
-.IX Item "-mconfig=name"
-Selects one of the build-in core configurations. Each MeP chip has
-one or more modules in it; each module has a core \s-1CPU\s0 and a variety of
-coprocessors, optional instructions, and peripherals. The
-\&\f(CW\*(C`MeP\-Integrator\*(C'\fR tool, not part of \s-1GCC\s0, provides these
-configurations through this option; using this option is the same as
-using all the corresponding command line options. The default
-configuration is \f(CW\*(C`default\*(C'\fR.
-.IP "\fB\-mcop\fR" 4
-.IX Item "-mcop"
-Enables the coprocessor instructions. By default, this is a 32\-bit
-coprocessor. Note that the coprocessor is normally enabled via the
-\&\f(CW\*(C`\-mconfig=\*(C'\fR option.
-.IP "\fB\-mcop32\fR" 4
-.IX Item "-mcop32"
-Enables the 32\-bit coprocessor's instructions.
-.IP "\fB\-mcop64\fR" 4
-.IX Item "-mcop64"
-Enables the 64\-bit coprocessor's instructions.
-.IP "\fB\-mivc2\fR" 4
-.IX Item "-mivc2"
-Enables \s-1IVC2\s0 scheduling. \s-1IVC2\s0 is a 64\-bit \s-1VLIW\s0 coprocessor.
-.IP "\fB\-mdc\fR" 4
-.IX Item "-mdc"
-Causes constant variables to be placed in the \f(CW\*(C`.near\*(C'\fR section.
-.IP "\fB\-mdiv\fR" 4
-.IX Item "-mdiv"
-Enables the \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`divu\*(C'\fR instructions.
-.IP "\fB\-meb\fR" 4
-.IX Item "-meb"
-Generate big-endian code.
-.IP "\fB\-mel\fR" 4
-.IX Item "-mel"
-Generate little-endian code.
-.IP "\fB\-mio\-volatile\fR" 4
-.IX Item "-mio-volatile"
-Tells the compiler that any variable marked with the \f(CW\*(C`io\*(C'\fR
-attribute is to be considered volatile.
-.IP "\fB\-ml\fR" 4
-.IX Item "-ml"
-Causes variables to be assigned to the \f(CW\*(C`.far\*(C'\fR section by default.
-.IP "\fB\-mleadz\fR" 4
-.IX Item "-mleadz"
-Enables the \f(CW\*(C`leadz\*(C'\fR (leading zero) instruction.
-.IP "\fB\-mm\fR" 4
-.IX Item "-mm"
-Causes variables to be assigned to the \f(CW\*(C`.near\*(C'\fR section by default.
-.IP "\fB\-mminmax\fR" 4
-.IX Item "-mminmax"
-Enables the \f(CW\*(C`min\*(C'\fR and \f(CW\*(C`max\*(C'\fR instructions.
-.IP "\fB\-mmult\fR" 4
-.IX Item "-mmult"
-Enables the multiplication and multiply-accumulate instructions.
-.IP "\fB\-mno\-opts\fR" 4
-.IX Item "-mno-opts"
-Disables all the optional instructions enabled by \f(CW\*(C`\-mall\-opts\*(C'\fR.
-.IP "\fB\-mrepeat\fR" 4
-.IX Item "-mrepeat"
-Enables the \f(CW\*(C`repeat\*(C'\fR and \f(CW\*(C`erepeat\*(C'\fR instructions, used for
-low-overhead looping.
-.IP "\fB\-ms\fR" 4
-.IX Item "-ms"
-Causes all variables to default to the \f(CW\*(C`.tiny\*(C'\fR section. Note
-that there is a 65536 byte limit to this section. Accesses to these
-variables use the \f(CW%gp\fR base register.
-.IP "\fB\-msatur\fR" 4
-.IX Item "-msatur"
-Enables the saturation instructions. Note that the compiler does not
-currently generate these itself, but this option is included for
-compatibility with other tools, like \f(CW\*(C`as\*(C'\fR.
-.IP "\fB\-msdram\fR" 4
-.IX Item "-msdram"
-Link the SDRAM-based runtime instead of the default ROM-based runtime.
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-Link the simulator runtime libraries.
-.IP "\fB\-msimnovec\fR" 4
-.IX Item "-msimnovec"
-Link the simulator runtime libraries, excluding built-in support
-for reset and exception vectors and tables.
-.IP "\fB\-mtf\fR" 4
-.IX Item "-mtf"
-Causes all functions to default to the \f(CW\*(C`.far\*(C'\fR section. Without
-this option, functions default to the \f(CW\*(C`.near\*(C'\fR section.
-.IP "\fB\-mtiny=\fR\fIn\fR" 4
-.IX Item "-mtiny=n"
-Variables that are \fIn\fR bytes or smaller will be allocated to the
-\&\f(CW\*(C`.tiny\*(C'\fR section. These variables use the \f(CW$gp\fR base
-register. The default for this option is 4, but note that there's a
-65536 byte limit to the \f(CW\*(C`.tiny\*(C'\fR section.
-.PP
-\fIMicroBlaze Options\fR
-.IX Subsection "MicroBlaze Options"
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Use software emulation for floating point (default).
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-Use hardware floating point instructions.
-.IP "\fB\-mmemcpy\fR" 4
-.IX Item "-mmemcpy"
-Do not optimize block moves, use \f(CW\*(C`memcpy\*(C'\fR.
-.IP "\fB\-mno\-clearbss\fR" 4
-.IX Item "-mno-clearbss"
-This option is deprecated. Use \fB\-fno\-zero\-initialized\-in\-bss\fR instead.
-.IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
-.IX Item "-mcpu=cpu-type"
-Use features of and schedule code for given \s-1CPU\s0.
-Supported values are in the format \fBv\fR\fIX\fR\fB.\fR\fI\s-1YY\s0\fR\fB.\fR\fIZ\fR,
-where \fIX\fR is a major version, \fI\s-1YY\s0\fR is the minor version, and
-\&\fIZ\fR is compatibility code. Example values are \fBv3.00.a\fR,
-\&\fBv4.00.b\fR, \fBv5.00.a\fR, \fBv5.00.b\fR, \fBv5.00.b\fR, \fBv6.00.a\fR.
-.IP "\fB\-mxl\-soft\-mul\fR" 4
-.IX Item "-mxl-soft-mul"
-Use software multiply emulation (default).
-.IP "\fB\-mxl\-soft\-div\fR" 4
-.IX Item "-mxl-soft-div"
-Use software emulation for divides (default).
-.IP "\fB\-mxl\-barrel\-shift\fR" 4
-.IX Item "-mxl-barrel-shift"
-Use the hardware barrel shifter.
-.IP "\fB\-mxl\-pattern\-compare\fR" 4
-.IX Item "-mxl-pattern-compare"
-Use pattern compare instructions.
-.IP "\fB\-msmall\-divides\fR" 4
-.IX Item "-msmall-divides"
-Use table lookup optimization for small signed integer divisions.
-.IP "\fB\-mxl\-stack\-check\fR" 4
-.IX Item "-mxl-stack-check"
-This option is deprecated. Use \-fstack\-check instead.
-.IP "\fB\-mxl\-gp\-opt\fR" 4
-.IX Item "-mxl-gp-opt"
-Use \s-1GP\s0 relative sdata/sbss sections.
-.IP "\fB\-mxl\-multiply\-high\fR" 4
-.IX Item "-mxl-multiply-high"
-Use multiply high instructions for high part of 32x32 multiply.
-.IP "\fB\-mxl\-float\-convert\fR" 4
-.IX Item "-mxl-float-convert"
-Use hardware floating point conversion instructions.
-.IP "\fB\-mxl\-float\-sqrt\fR" 4
-.IX Item "-mxl-float-sqrt"
-Use hardware floating point square root instruction.
-.IP "\fB\-mxl\-mode\-\fR\fIapp-model\fR" 4
-.IX Item "-mxl-mode-app-model"
-Select application model \fIapp-model\fR. Valid models are
-.RS 4
-.IP "\fBexecutable\fR" 4
-.IX Item "executable"
-normal executable (default), uses startup code \fIcrt0.o\fR.
-.IP "\fBxmdstub\fR" 4
-.IX Item "xmdstub"
-for use with Xilinx Microprocessor Debugger (\s-1XMD\s0) based
-software intrusive debug agent called xmdstub. This uses startup file
-\&\fIcrt1.o\fR and sets the start address of the program to be 0x800.
-.IP "\fBbootstrap\fR" 4
-.IX Item "bootstrap"
-for applications that are loaded using a bootloader.
-This model uses startup file \fIcrt2.o\fR which does not contain a processor
-reset vector handler. This is suitable for transferring control on a
-processor reset to the bootloader rather than the application.
-.IP "\fBnovectors\fR" 4
-.IX Item "novectors"
-for applications that do not require any of the
-MicroBlaze vectors. This option may be useful for applications running
-within a monitoring application. This model uses \fIcrt3.o\fR as a startup file.
-.RE
-.RS 4
-.Sp
-Option \fB\-xl\-mode\-\fR\fIapp-model\fR is a deprecated alias for
-\&\fB\-mxl\-mode\-\fR\fIapp-model\fR.
-.RE
-.PP
-\fI\s-1MIPS\s0 Options\fR
-.IX Subsection "MIPS Options"
-.IP "\fB\-EB\fR" 4
-.IX Item "-EB"
-Generate big-endian code.
-.IP "\fB\-EL\fR" 4
-.IX Item "-EL"
-Generate little-endian code. This is the default for \fBmips*el\-*\-*\fR
-configurations.
-.IP "\fB\-march=\fR\fIarch\fR" 4
-.IX Item "-march=arch"
-Generate code that will run on \fIarch\fR, which can be the name of a
-generic \s-1MIPS\s0 \s-1ISA\s0, or the name of a particular processor.
-The \s-1ISA\s0 names are:
-\&\fBmips1\fR, \fBmips2\fR, \fBmips3\fR, \fBmips4\fR,
-\&\fBmips32\fR, \fBmips32r2\fR, \fBmips64\fR and \fBmips64r2\fR.
-The processor names are:
-\&\fB4kc\fR, \fB4km\fR, \fB4kp\fR, \fB4ksc\fR,
-\&\fB4kec\fR, \fB4kem\fR, \fB4kep\fR, \fB4ksd\fR,
-\&\fB5kc\fR, \fB5kf\fR,
-\&\fB20kc\fR,
-\&\fB24kc\fR, \fB24kf2_1\fR, \fB24kf1_1\fR,
-\&\fB24kec\fR, \fB24kef2_1\fR, \fB24kef1_1\fR,
-\&\fB34kc\fR, \fB34kf2_1\fR, \fB34kf1_1\fR,
-\&\fB74kc\fR, \fB74kf2_1\fR, \fB74kf1_1\fR, \fB74kf3_2\fR,
-\&\fB1004kc\fR, \fB1004kf2_1\fR, \fB1004kf1_1\fR,
-\&\fBloongson2e\fR, \fBloongson2f\fR, \fBloongson3a\fR,
-\&\fBm4k\fR,
-\&\fBocteon\fR,
-\&\fBorion\fR,
-\&\fBr2000\fR, \fBr3000\fR, \fBr3900\fR, \fBr4000\fR, \fBr4400\fR,
-\&\fBr4600\fR, \fBr4650\fR, \fBr6000\fR, \fBr8000\fR,
-\&\fBrm7000\fR, \fBrm9000\fR,
-\&\fBr10000\fR, \fBr12000\fR, \fBr14000\fR, \fBr16000\fR,
-\&\fBsb1\fR,
-\&\fBsr71000\fR,
-\&\fBvr4100\fR, \fBvr4111\fR, \fBvr4120\fR, \fBvr4130\fR, \fBvr4300\fR,
-\&\fBvr5000\fR, \fBvr5400\fR, \fBvr5500\fR
-and \fBxlr\fR.
-The special value \fBfrom-abi\fR selects the
-most compatible architecture for the selected \s-1ABI\s0 (that is,
-\&\fBmips1\fR for 32\-bit ABIs and \fBmips3\fR for 64\-bit ABIs).
-.Sp
-Native Linux/GNU toolchains also support the value \fBnative\fR,
-which selects the best architecture option for the host processor.
-\&\fB\-march=native\fR has no effect if \s-1GCC\s0 does not recognize
-the processor.
-.Sp
-In processor names, a final \fB000\fR can be abbreviated as \fBk\fR
-(for example, \fB\-march=r2k\fR). Prefixes are optional, and
-\&\fBvr\fR may be written \fBr\fR.
-.Sp
-Names of the form \fIn\fR\fBf2_1\fR refer to processors with
-FPUs clocked at half the rate of the core, names of the form
-\&\fIn\fR\fBf1_1\fR refer to processors with FPUs clocked at the same
-rate as the core, and names of the form \fIn\fR\fBf3_2\fR refer to
-processors with FPUs clocked a ratio of 3:2 with respect to the core.
-For compatibility reasons, \fIn\fR\fBf\fR is accepted as a synonym
-for \fIn\fR\fBf2_1\fR while \fIn\fR\fBx\fR and \fIb\fR\fBfx\fR are
-accepted as synonyms for \fIn\fR\fBf1_1\fR.
-.Sp
-\&\s-1GCC\s0 defines two macros based on the value of this option. The first
-is \fB_MIPS_ARCH\fR, which gives the name of target architecture, as
-a string. The second has the form \fB_MIPS_ARCH_\fR\fIfoo\fR,
-where \fIfoo\fR is the capitalized value of \fB_MIPS_ARCH\fR.
-For example, \fB\-march=r2000\fR will set \fB_MIPS_ARCH\fR
-to \fB\*(L"r2000\*(R"\fR and define the macro \fB_MIPS_ARCH_R2000\fR.
-.Sp
-Note that the \fB_MIPS_ARCH\fR macro uses the processor names given
-above. In other words, it will have the full prefix and will not
-abbreviate \fB000\fR as \fBk\fR. In the case of \fBfrom-abi\fR,
-the macro names the resolved architecture (either \fB\*(L"mips1\*(R"\fR or
-\&\fB\*(L"mips3\*(R"\fR). It names the default architecture when no
-\&\fB\-march\fR option is given.
-.IP "\fB\-mtune=\fR\fIarch\fR" 4
-.IX Item "-mtune=arch"
-Optimize for \fIarch\fR. Among other things, this option controls
-the way instructions are scheduled, and the perceived cost of arithmetic
-operations. The list of \fIarch\fR values is the same as for
-\&\fB\-march\fR.
-.Sp
-When this option is not used, \s-1GCC\s0 will optimize for the processor
-specified by \fB\-march\fR. By using \fB\-march\fR and
-\&\fB\-mtune\fR together, it is possible to generate code that will
-run on a family of processors, but optimize the code for one
-particular member of that family.
-.Sp
-\&\fB\-mtune\fR defines the macros \fB_MIPS_TUNE\fR and
-\&\fB_MIPS_TUNE_\fR\fIfoo\fR, which work in the same way as the
-\&\fB\-march\fR ones described above.
-.IP "\fB\-mips1\fR" 4
-.IX Item "-mips1"
-Equivalent to \fB\-march=mips1\fR.
-.IP "\fB\-mips2\fR" 4
-.IX Item "-mips2"
-Equivalent to \fB\-march=mips2\fR.
-.IP "\fB\-mips3\fR" 4
-.IX Item "-mips3"
-Equivalent to \fB\-march=mips3\fR.
-.IP "\fB\-mips4\fR" 4
-.IX Item "-mips4"
-Equivalent to \fB\-march=mips4\fR.
-.IP "\fB\-mips32\fR" 4
-.IX Item "-mips32"
-Equivalent to \fB\-march=mips32\fR.
-.IP "\fB\-mips32r2\fR" 4
-.IX Item "-mips32r2"
-Equivalent to \fB\-march=mips32r2\fR.
-.IP "\fB\-mips64\fR" 4
-.IX Item "-mips64"
-Equivalent to \fB\-march=mips64\fR.
-.IP "\fB\-mips64r2\fR" 4
-.IX Item "-mips64r2"
-Equivalent to \fB\-march=mips64r2\fR.
-.IP "\fB\-mips16\fR" 4
-.IX Item "-mips16"
-.PD 0
-.IP "\fB\-mno\-mips16\fR" 4
-.IX Item "-mno-mips16"
-.PD
-Generate (do not generate) \s-1MIPS16\s0 code. If \s-1GCC\s0 is targetting a
-\&\s-1MIPS32\s0 or \s-1MIPS64\s0 architecture, it will make use of the MIPS16e \s-1ASE\s0.
-.Sp
-\&\s-1MIPS16\s0 code generation can also be controlled on a per-function basis
-by means of \f(CW\*(C`mips16\*(C'\fR and \f(CW\*(C`nomips16\*(C'\fR attributes.
-.IP "\fB\-mflip\-mips16\fR" 4
-.IX Item "-mflip-mips16"
-Generate \s-1MIPS16\s0 code on alternating functions. This option is provided
-for regression testing of mixed MIPS16/non\-MIPS16 code generation, and is
-not intended for ordinary use in compiling user code.
-.IP "\fB\-minterlink\-mips16\fR" 4
-.IX Item "-minterlink-mips16"
-.PD 0
-.IP "\fB\-mno\-interlink\-mips16\fR" 4
-.IX Item "-mno-interlink-mips16"
-.PD
-Require (do not require) that non\-MIPS16 code be link-compatible with
-\&\s-1MIPS16\s0 code.
-.Sp
-For example, non\-MIPS16 code cannot jump directly to \s-1MIPS16\s0 code;
-it must either use a call or an indirect jump. \fB\-minterlink\-mips16\fR
-therefore disables direct jumps unless \s-1GCC\s0 knows that the target of the
-jump is not \s-1MIPS16\s0.
-.IP "\fB\-mabi=32\fR" 4
-.IX Item "-mabi=32"
-.PD 0
-.IP "\fB\-mabi=o64\fR" 4
-.IX Item "-mabi=o64"
-.IP "\fB\-mabi=n32\fR" 4
-.IX Item "-mabi=n32"
-.IP "\fB\-mabi=64\fR" 4
-.IX Item "-mabi=64"
-.IP "\fB\-mabi=eabi\fR" 4
-.IX Item "-mabi=eabi"
-.PD
-Generate code for the given \s-1ABI\s0.
-.Sp
-Note that the \s-1EABI\s0 has a 32\-bit and a 64\-bit variant. \s-1GCC\s0 normally
-generates 64\-bit code when you select a 64\-bit architecture, but you
-can use \fB\-mgp32\fR to get 32\-bit code instead.
-.Sp
-For information about the O64 \s-1ABI\s0, see
-<\fBhttp://gcc.gnu.org/projects/mipso64\-abi.html\fR>.
-.Sp
-\&\s-1GCC\s0 supports a variant of the o32 \s-1ABI\s0 in which floating-point registers
-are 64 rather than 32 bits wide. You can select this combination with
-\&\fB\-mabi=32\fR \fB\-mfp64\fR. This \s-1ABI\s0 relies on the \fBmthc1\fR
-and \fBmfhc1\fR instructions and is therefore only supported for
-\&\s-1MIPS32R2\s0 processors.
-.Sp
-The register assignments for arguments and return values remain the
-same, but each scalar value is passed in a single 64\-bit register
-rather than a pair of 32\-bit registers. For example, scalar
-floating-point values are returned in \fB\f(CB$f0\fB\fR only, not a
-\&\fB\f(CB$f0\fB\fR/\fB\f(CB$f1\fB\fR pair. The set of call-saved registers also
-remains the same, but all 64 bits are saved.
-.IP "\fB\-mabicalls\fR" 4
-.IX Item "-mabicalls"
-.PD 0
-.IP "\fB\-mno\-abicalls\fR" 4
-.IX Item "-mno-abicalls"
-.PD
-Generate (do not generate) code that is suitable for SVR4\-style
-dynamic objects. \fB\-mabicalls\fR is the default for SVR4\-based
-systems.
-.IP "\fB\-mshared\fR" 4
-.IX Item "-mshared"
-.PD 0
-.IP "\fB\-mno\-shared\fR" 4
-.IX Item "-mno-shared"
-.PD
-Generate (do not generate) code that is fully position-independent,
-and that can therefore be linked into shared libraries. This option
-only affects \fB\-mabicalls\fR.
-.Sp
-All \fB\-mabicalls\fR code has traditionally been position-independent,
-regardless of options like \fB\-fPIC\fR and \fB\-fpic\fR. However,
-as an extension, the \s-1GNU\s0 toolchain allows executables to use absolute
-accesses for locally-binding symbols. It can also use shorter \s-1GP\s0
-initialization sequences and generate direct calls to locally-defined
-functions. This mode is selected by \fB\-mno\-shared\fR.
-.Sp
-\&\fB\-mno\-shared\fR depends on binutils 2.16 or higher and generates
-objects that can only be linked by the \s-1GNU\s0 linker. However, the option
-does not affect the \s-1ABI\s0 of the final executable; it only affects the \s-1ABI\s0
-of relocatable objects. Using \fB\-mno\-shared\fR will generally make
-executables both smaller and quicker.
-.Sp
-\&\fB\-mshared\fR is the default.
-.IP "\fB\-mplt\fR" 4
-.IX Item "-mplt"
-.PD 0
-.IP "\fB\-mno\-plt\fR" 4
-.IX Item "-mno-plt"
-.PD
-Assume (do not assume) that the static and dynamic linkers
-support PLTs and copy relocations. This option only affects
-\&\fB\-mno\-shared \-mabicalls\fR. For the n64 \s-1ABI\s0, this option
-has no effect without \fB\-msym32\fR.
-.Sp
-You can make \fB\-mplt\fR the default by configuring
-\&\s-1GCC\s0 with \fB\-\-with\-mips\-plt\fR. The default is
-\&\fB\-mno\-plt\fR otherwise.
-.IP "\fB\-mxgot\fR" 4
-.IX Item "-mxgot"
-.PD 0
-.IP "\fB\-mno\-xgot\fR" 4
-.IX Item "-mno-xgot"
-.PD
-Lift (do not lift) the usual restrictions on the size of the global
-offset table.
-.Sp
-\&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT\s0.
-While this is relatively efficient, it will only work if the \s-1GOT\s0
-is smaller than about 64k. Anything larger will cause the linker
-to report an error such as:
-.Sp
-.Vb 1
-\& relocation truncated to fit: R_MIPS_GOT16 foobar
-.Ve
-.Sp
-If this happens, you should recompile your code with \fB\-mxgot\fR.
-It should then work with very large GOTs, although it will also be
-less efficient, since it will take three instructions to fetch the
-value of a global symbol.
-.Sp
-Note that some linkers can create multiple GOTs. If you have such a
-linker, you should only need to use \fB\-mxgot\fR when a single object
-file accesses more than 64k's worth of \s-1GOT\s0 entries. Very few do.
-.Sp
-These options have no effect unless \s-1GCC\s0 is generating position
-independent code.
-.IP "\fB\-mgp32\fR" 4
-.IX Item "-mgp32"
-Assume that general-purpose registers are 32 bits wide.
-.IP "\fB\-mgp64\fR" 4
-.IX Item "-mgp64"
-Assume that general-purpose registers are 64 bits wide.
-.IP "\fB\-mfp32\fR" 4
-.IX Item "-mfp32"
-Assume that floating-point registers are 32 bits wide.
-.IP "\fB\-mfp64\fR" 4
-.IX Item "-mfp64"
-Assume that floating-point registers are 64 bits wide.
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-Use floating-point coprocessor instructions.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Do not use floating-point coprocessor instructions. Implement
-floating-point calculations using library calls instead.
-.IP "\fB\-msingle\-float\fR" 4
-.IX Item "-msingle-float"
-Assume that the floating-point coprocessor only supports single-precision
-operations.
-.IP "\fB\-mdouble\-float\fR" 4
-.IX Item "-mdouble-float"
-Assume that the floating-point coprocessor supports double-precision
-operations. This is the default.
-.IP "\fB\-mllsc\fR" 4
-.IX Item "-mllsc"
-.PD 0
-.IP "\fB\-mno\-llsc\fR" 4
-.IX Item "-mno-llsc"
-.PD
-Use (do not use) \fBll\fR, \fBsc\fR, and \fBsync\fR instructions to
-implement atomic memory built-in functions. When neither option is
-specified, \s-1GCC\s0 will use the instructions if the target architecture
-supports them.
-.Sp
-\&\fB\-mllsc\fR is useful if the runtime environment can emulate the
-instructions and \fB\-mno\-llsc\fR can be useful when compiling for
-nonstandard ISAs. You can make either option the default by
-configuring \s-1GCC\s0 with \fB\-\-with\-llsc\fR and \fB\-\-without\-llsc\fR
-respectively. \fB\-\-with\-llsc\fR is the default for some
-configurations; see the installation documentation for details.
-.IP "\fB\-mdsp\fR" 4
-.IX Item "-mdsp"
-.PD 0
-.IP "\fB\-mno\-dsp\fR" 4
-.IX Item "-mno-dsp"
-.PD
-Use (do not use) revision 1 of the \s-1MIPS\s0 \s-1DSP\s0 \s-1ASE\s0.
- This option defines the
-preprocessor macro \fB_\|_mips_dsp\fR. It also defines
-\&\fB_\|_mips_dsp_rev\fR to 1.
-.IP "\fB\-mdspr2\fR" 4
-.IX Item "-mdspr2"
-.PD 0
-.IP "\fB\-mno\-dspr2\fR" 4
-.IX Item "-mno-dspr2"
-.PD
-Use (do not use) revision 2 of the \s-1MIPS\s0 \s-1DSP\s0 \s-1ASE\s0.
- This option defines the
-preprocessor macros \fB_\|_mips_dsp\fR and \fB_\|_mips_dspr2\fR.
-It also defines \fB_\|_mips_dsp_rev\fR to 2.
-.IP "\fB\-msmartmips\fR" 4
-.IX Item "-msmartmips"
-.PD 0
-.IP "\fB\-mno\-smartmips\fR" 4
-.IX Item "-mno-smartmips"
-.PD
-Use (do not use) the \s-1MIPS\s0 SmartMIPS \s-1ASE\s0.
-.IP "\fB\-mpaired\-single\fR" 4
-.IX Item "-mpaired-single"
-.PD 0
-.IP "\fB\-mno\-paired\-single\fR" 4
-.IX Item "-mno-paired-single"
-.PD
-Use (do not use) paired-single floating-point instructions.
- This option requires
-hardware floating-point support to be enabled.
-.IP "\fB\-mdmx\fR" 4
-.IX Item "-mdmx"
-.PD 0
-.IP "\fB\-mno\-mdmx\fR" 4
-.IX Item "-mno-mdmx"
-.PD
-Use (do not use) \s-1MIPS\s0 Digital Media Extension instructions.
-This option can only be used when generating 64\-bit code and requires
-hardware floating-point support to be enabled.
-.IP "\fB\-mips3d\fR" 4
-.IX Item "-mips3d"
-.PD 0
-.IP "\fB\-mno\-mips3d\fR" 4
-.IX Item "-mno-mips3d"
-.PD
-Use (do not use) the \s-1MIPS\-3D\s0 \s-1ASE\s0.
-The option \fB\-mips3d\fR implies \fB\-mpaired\-single\fR.
-.IP "\fB\-mmt\fR" 4
-.IX Item "-mmt"
-.PD 0
-.IP "\fB\-mno\-mt\fR" 4
-.IX Item "-mno-mt"
-.PD
-Use (do not use) \s-1MT\s0 Multithreading instructions.
-.IP "\fB\-mlong64\fR" 4
-.IX Item "-mlong64"
-Force \f(CW\*(C`long\*(C'\fR types to be 64 bits wide. See \fB\-mlong32\fR for
-an explanation of the default and the way that the pointer size is
-determined.
-.IP "\fB\-mlong32\fR" 4
-.IX Item "-mlong32"
-Force \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`int\*(C'\fR, and pointer types to be 32 bits wide.
-.Sp
-The default size of \f(CW\*(C`int\*(C'\fRs, \f(CW\*(C`long\*(C'\fRs and pointers depends on
-the \s-1ABI\s0. All the supported ABIs use 32\-bit \f(CW\*(C`int\*(C'\fRs. The n64 \s-1ABI\s0
-uses 64\-bit \f(CW\*(C`long\*(C'\fRs, as does the 64\-bit \s-1EABI\s0; the others use
-32\-bit \f(CW\*(C`long\*(C'\fRs. Pointers are the same size as \f(CW\*(C`long\*(C'\fRs,
-or the same size as integer registers, whichever is smaller.
-.IP "\fB\-msym32\fR" 4
-.IX Item "-msym32"
-.PD 0
-.IP "\fB\-mno\-sym32\fR" 4
-.IX Item "-mno-sym32"
-.PD
-Assume (do not assume) that all symbols have 32\-bit values, regardless
-of the selected \s-1ABI\s0. This option is useful in combination with
-\&\fB\-mabi=64\fR and \fB\-mno\-abicalls\fR because it allows \s-1GCC\s0
-to generate shorter and faster references to symbolic addresses.
-.IP "\fB\-G\fR \fInum\fR" 4
-.IX Item "-G num"
-Put definitions of externally-visible data in a small data section
-if that data is no bigger than \fInum\fR bytes. \s-1GCC\s0 can then access
-the data more efficiently; see \fB\-mgpopt\fR for details.
-.Sp
-The default \fB\-G\fR option depends on the configuration.
-.IP "\fB\-mlocal\-sdata\fR" 4
-.IX Item "-mlocal-sdata"
-.PD 0
-.IP "\fB\-mno\-local\-sdata\fR" 4
-.IX Item "-mno-local-sdata"
-.PD
-Extend (do not extend) the \fB\-G\fR behavior to local data too,
-such as to static variables in C. \fB\-mlocal\-sdata\fR is the
-default for all configurations.
-.Sp
-If the linker complains that an application is using too much small data,
-you might want to try rebuilding the less performance-critical parts with
-\&\fB\-mno\-local\-sdata\fR. You might also want to build large
-libraries with \fB\-mno\-local\-sdata\fR, so that the libraries leave
-more room for the main program.
-.IP "\fB\-mextern\-sdata\fR" 4
-.IX Item "-mextern-sdata"
-.PD 0
-.IP "\fB\-mno\-extern\-sdata\fR" 4
-.IX Item "-mno-extern-sdata"
-.PD
-Assume (do not assume) that externally-defined data will be in
-a small data section if that data is within the \fB\-G\fR limit.
-\&\fB\-mextern\-sdata\fR is the default for all configurations.
-.Sp
-If you compile a module \fIMod\fR with \fB\-mextern\-sdata\fR \fB\-G\fR
-\&\fInum\fR \fB\-mgpopt\fR, and \fIMod\fR references a variable \fIVar\fR
-that is no bigger than \fInum\fR bytes, you must make sure that \fIVar\fR
-is placed in a small data section. If \fIVar\fR is defined by another
-module, you must either compile that module with a high-enough
-\&\fB\-G\fR setting or attach a \f(CW\*(C`section\*(C'\fR attribute to \fIVar\fR's
-definition. If \fIVar\fR is common, you must link the application
-with a high-enough \fB\-G\fR setting.
-.Sp
-The easiest way of satisfying these restrictions is to compile
-and link every module with the same \fB\-G\fR option. However,
-you may wish to build a library that supports several different
-small data limits. You can do this by compiling the library with
-the highest supported \fB\-G\fR setting and additionally using
-\&\fB\-mno\-extern\-sdata\fR to stop the library from making assumptions
-about externally-defined data.
-.IP "\fB\-mgpopt\fR" 4
-.IX Item "-mgpopt"
-.PD 0
-.IP "\fB\-mno\-gpopt\fR" 4
-.IX Item "-mno-gpopt"
-.PD
-Use (do not use) GP-relative accesses for symbols that are known to be
-in a small data section; see \fB\-G\fR, \fB\-mlocal\-sdata\fR and
-\&\fB\-mextern\-sdata\fR. \fB\-mgpopt\fR is the default for all
-configurations.
-.Sp
-\&\fB\-mno\-gpopt\fR is useful for cases where the \f(CW$gp\fR register
-might not hold the value of \f(CW\*(C`_gp\*(C'\fR. For example, if the code is
-part of a library that might be used in a boot monitor, programs that
-call boot monitor routines will pass an unknown value in \f(CW$gp\fR.
-(In such situations, the boot monitor itself would usually be compiled
-with \fB\-G0\fR.)
-.Sp
-\&\fB\-mno\-gpopt\fR implies \fB\-mno\-local\-sdata\fR and
-\&\fB\-mno\-extern\-sdata\fR.
-.IP "\fB\-membedded\-data\fR" 4
-.IX Item "-membedded-data"
-.PD 0
-.IP "\fB\-mno\-embedded\-data\fR" 4
-.IX Item "-mno-embedded-data"
-.PD
-Allocate variables to the read-only data section first if possible, then
-next in the small data section if possible, otherwise in data. This gives
-slightly slower code than the default, but reduces the amount of \s-1RAM\s0 required
-when executing, and thus may be preferred for some embedded systems.
-.IP "\fB\-muninit\-const\-in\-rodata\fR" 4
-.IX Item "-muninit-const-in-rodata"
-.PD 0
-.IP "\fB\-mno\-uninit\-const\-in\-rodata\fR" 4
-.IX Item "-mno-uninit-const-in-rodata"
-.PD
-Put uninitialized \f(CW\*(C`const\*(C'\fR variables in the read-only data section.
-This option is only meaningful in conjunction with \fB\-membedded\-data\fR.
-.IP "\fB\-mcode\-readable=\fR\fIsetting\fR" 4
-.IX Item "-mcode-readable=setting"
-Specify whether \s-1GCC\s0 may generate code that reads from executable sections.
-There are three possible settings:
-.RS 4
-.IP "\fB\-mcode\-readable=yes\fR" 4
-.IX Item "-mcode-readable=yes"
-Instructions may freely access executable sections. This is the
-default setting.
-.IP "\fB\-mcode\-readable=pcrel\fR" 4
-.IX Item "-mcode-readable=pcrel"
-\&\s-1MIPS16\s0 PC-relative load instructions can access executable sections,
-but other instructions must not do so. This option is useful on 4KSc
-and 4KSd processors when the code TLBs have the Read Inhibit bit set.
-It is also useful on processors that can be configured to have a dual
-instruction/data \s-1SRAM\s0 interface and that, like the M4K, automatically
-redirect PC-relative loads to the instruction \s-1RAM\s0.
-.IP "\fB\-mcode\-readable=no\fR" 4
-.IX Item "-mcode-readable=no"
-Instructions must not access executable sections. This option can be
-useful on targets that are configured to have a dual instruction/data
-\&\s-1SRAM\s0 interface but that (unlike the M4K) do not automatically redirect
-PC-relative loads to the instruction \s-1RAM\s0.
-.RE
-.RS 4
-.RE
-.IP "\fB\-msplit\-addresses\fR" 4
-.IX Item "-msplit-addresses"
-.PD 0
-.IP "\fB\-mno\-split\-addresses\fR" 4
-.IX Item "-mno-split-addresses"
-.PD
-Enable (disable) use of the \f(CW\*(C`%hi()\*(C'\fR and \f(CW\*(C`%lo()\*(C'\fR assembler
-relocation operators. This option has been superseded by
-\&\fB\-mexplicit\-relocs\fR but is retained for backwards compatibility.
-.IP "\fB\-mexplicit\-relocs\fR" 4
-.IX Item "-mexplicit-relocs"
-.PD 0
-.IP "\fB\-mno\-explicit\-relocs\fR" 4
-.IX Item "-mno-explicit-relocs"
-.PD
-Use (do not use) assembler relocation operators when dealing with symbolic
-addresses. The alternative, selected by \fB\-mno\-explicit\-relocs\fR,
-is to use assembler macros instead.
-.Sp
-\&\fB\-mexplicit\-relocs\fR is the default if \s-1GCC\s0 was configured
-to use an assembler that supports relocation operators.
-.IP "\fB\-mcheck\-zero\-division\fR" 4
-.IX Item "-mcheck-zero-division"
-.PD 0
-.IP "\fB\-mno\-check\-zero\-division\fR" 4
-.IX Item "-mno-check-zero-division"
-.PD
-Trap (do not trap) on integer division by zero.
-.Sp
-The default is \fB\-mcheck\-zero\-division\fR.
-.IP "\fB\-mdivide\-traps\fR" 4
-.IX Item "-mdivide-traps"
-.PD 0
-.IP "\fB\-mdivide\-breaks\fR" 4
-.IX Item "-mdivide-breaks"
-.PD
-\&\s-1MIPS\s0 systems check for division by zero by generating either a
-conditional trap or a break instruction. Using traps results in
-smaller code, but is only supported on \s-1MIPS\s0 \s-1II\s0 and later. Also, some
-versions of the Linux kernel have a bug that prevents trap from
-generating the proper signal (\f(CW\*(C`SIGFPE\*(C'\fR). Use \fB\-mdivide\-traps\fR to
-allow conditional traps on architectures that support them and
-\&\fB\-mdivide\-breaks\fR to force the use of breaks.
-.Sp
-The default is usually \fB\-mdivide\-traps\fR, but this can be
-overridden at configure time using \fB\-\-with\-divide=breaks\fR.
-Divide-by-zero checks can be completely disabled using
-\&\fB\-mno\-check\-zero\-division\fR.
-.IP "\fB\-mmemcpy\fR" 4
-.IX Item "-mmemcpy"
-.PD 0
-.IP "\fB\-mno\-memcpy\fR" 4
-.IX Item "-mno-memcpy"
-.PD
-Force (do not force) the use of \f(CW\*(C`memcpy()\*(C'\fR for non-trivial block
-moves. The default is \fB\-mno\-memcpy\fR, which allows \s-1GCC\s0 to inline
-most constant-sized copies.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-.PD 0
-.IP "\fB\-mno\-long\-calls\fR" 4
-.IX Item "-mno-long-calls"
-.PD
-Disable (do not disable) use of the \f(CW\*(C`jal\*(C'\fR instruction. Calling
-functions using \f(CW\*(C`jal\*(C'\fR is more efficient but requires the caller
-and callee to be in the same 256 megabyte segment.
-.Sp
-This option has no effect on abicalls code. The default is
-\&\fB\-mno\-long\-calls\fR.
-.IP "\fB\-mmad\fR" 4
-.IX Item "-mmad"
-.PD 0
-.IP "\fB\-mno\-mad\fR" 4
-.IX Item "-mno-mad"
-.PD
-Enable (disable) use of the \f(CW\*(C`mad\*(C'\fR, \f(CW\*(C`madu\*(C'\fR and \f(CW\*(C`mul\*(C'\fR
-instructions, as provided by the R4650 \s-1ISA\s0.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Enable (disable) use of the floating point multiply-accumulate
-instructions, when they are available. The default is
-\&\fB\-mfused\-madd\fR.
-.Sp
-When multiply-accumulate instructions are used, the intermediate
-product is calculated to infinite precision and is not subject to
-the \s-1FCSR\s0 Flush to Zero bit. This may be undesirable in some
-circumstances.
-.IP "\fB\-nocpp\fR" 4
-.IX Item "-nocpp"
-Tell the \s-1MIPS\s0 assembler to not run its preprocessor over user
-assembler files (with a \fB.s\fR suffix) when assembling them.
-.IP "\fB\-mfix\-r4000\fR" 4
-.IX Item "-mfix-r4000"
-.PD 0
-.IP "\fB\-mno\-fix\-r4000\fR" 4
-.IX Item "-mno-fix-r4000"
-.PD
-Work around certain R4000 \s-1CPU\s0 errata:
-.RS 4
-.IP "\-" 4
-A double-word or a variable shift may give an incorrect result if executed
-immediately after starting an integer division.
-.IP "\-" 4
-A double-word or a variable shift may give an incorrect result if executed
-while an integer multiplication is in progress.
-.IP "\-" 4
-An integer division may give an incorrect result if started in a delay slot
-of a taken branch or a jump.
-.RE
-.RS 4
-.RE
-.IP "\fB\-mfix\-r4400\fR" 4
-.IX Item "-mfix-r4400"
-.PD 0
-.IP "\fB\-mno\-fix\-r4400\fR" 4
-.IX Item "-mno-fix-r4400"
-.PD
-Work around certain R4400 \s-1CPU\s0 errata:
-.RS 4
-.IP "\-" 4
-A double-word or a variable shift may give an incorrect result if executed
-immediately after starting an integer division.
-.RE
-.RS 4
-.RE
-.IP "\fB\-mfix\-r10000\fR" 4
-.IX Item "-mfix-r10000"
-.PD 0
-.IP "\fB\-mno\-fix\-r10000\fR" 4
-.IX Item "-mno-fix-r10000"
-.PD
-Work around certain R10000 errata:
-.RS 4
-.IP "\-" 4
-\&\f(CW\*(C`ll\*(C'\fR/\f(CW\*(C`sc\*(C'\fR sequences may not behave atomically on revisions
-prior to 3.0. They may deadlock on revisions 2.6 and earlier.
-.RE
-.RS 4
-.Sp
-This option can only be used if the target architecture supports
-branch-likely instructions. \fB\-mfix\-r10000\fR is the default when
-\&\fB\-march=r10000\fR is used; \fB\-mno\-fix\-r10000\fR is the default
-otherwise.
-.RE
-.IP "\fB\-mfix\-vr4120\fR" 4
-.IX Item "-mfix-vr4120"
-.PD 0
-.IP "\fB\-mno\-fix\-vr4120\fR" 4
-.IX Item "-mno-fix-vr4120"
-.PD
-Work around certain \s-1VR4120\s0 errata:
-.RS 4
-.IP "\-" 4
-\&\f(CW\*(C`dmultu\*(C'\fR does not always produce the correct result.
-.IP "\-" 4
-\&\f(CW\*(C`div\*(C'\fR and \f(CW\*(C`ddiv\*(C'\fR do not always produce the correct result if one
-of the operands is negative.
-.RE
-.RS 4
-.Sp
-The workarounds for the division errata rely on special functions in
-\&\fIlibgcc.a\fR. At present, these functions are only provided by
-the \f(CW\*(C`mips64vr*\-elf\*(C'\fR configurations.
-.Sp
-Other \s-1VR4120\s0 errata require a nop to be inserted between certain pairs of
-instructions. These errata are handled by the assembler, not by \s-1GCC\s0 itself.
-.RE
-.IP "\fB\-mfix\-vr4130\fR" 4
-.IX Item "-mfix-vr4130"
-Work around the \s-1VR4130\s0 \f(CW\*(C`mflo\*(C'\fR/\f(CW\*(C`mfhi\*(C'\fR errata. The
-workarounds are implemented by the assembler rather than by \s-1GCC\s0,
-although \s-1GCC\s0 will avoid using \f(CW\*(C`mflo\*(C'\fR and \f(CW\*(C`mfhi\*(C'\fR if the
-\&\s-1VR4130\s0 \f(CW\*(C`macc\*(C'\fR, \f(CW\*(C`macchi\*(C'\fR, \f(CW\*(C`dmacc\*(C'\fR and \f(CW\*(C`dmacchi\*(C'\fR
-instructions are available instead.
-.IP "\fB\-mfix\-sb1\fR" 4
-.IX Item "-mfix-sb1"
-.PD 0
-.IP "\fB\-mno\-fix\-sb1\fR" 4
-.IX Item "-mno-fix-sb1"
-.PD
-Work around certain \s-1SB\-1\s0 \s-1CPU\s0 core errata.
-(This flag currently works around the \s-1SB\-1\s0 revision 2
-\&\*(L"F1\*(R" and \*(L"F2\*(R" floating point errata.)
-.IP "\fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR" 4
-.IX Item "-mr10k-cache-barrier=setting"
-Specify whether \s-1GCC\s0 should insert cache barriers to avoid the
-side-effects of speculation on R10K processors.
-.Sp
-In common with many processors, the R10K tries to predict the outcome
-of a conditional branch and speculatively executes instructions from
-the \*(L"taken\*(R" branch. It later aborts these instructions if the
-predicted outcome was wrong. However, on the R10K, even aborted
-instructions can have side effects.
-.Sp
-This problem only affects kernel stores and, depending on the system,
-kernel loads. As an example, a speculatively-executed store may load
-the target memory into cache and mark the cache line as dirty, even if
-the store itself is later aborted. If a \s-1DMA\s0 operation writes to the
-same area of memory before the \*(L"dirty\*(R" line is flushed, the cached
-data will overwrite the DMA-ed data. See the R10K processor manual
-for a full description, including other potential problems.
-.Sp
-One workaround is to insert cache barrier instructions before every memory
-access that might be speculatively executed and that might have side
-effects even if aborted. \fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR
-controls \s-1GCC\s0's implementation of this workaround. It assumes that
-aborted accesses to any byte in the following regions will not have
-side effects:
-.RS 4
-.IP "1." 4
-the memory occupied by the current function's stack frame;
-.IP "2." 4
-the memory occupied by an incoming stack argument;
-.IP "3." 4
-the memory occupied by an object with a link-time-constant address.
-.RE
-.RS 4
-.Sp
-It is the kernel's responsibility to ensure that speculative
-accesses to these regions are indeed safe.
-.Sp
-If the input program contains a function declaration such as:
-.Sp
-.Vb 1
-\& void foo (void);
-.Ve
-.Sp
-then the implementation of \f(CW\*(C`foo\*(C'\fR must allow \f(CW\*(C`j foo\*(C'\fR and
-\&\f(CW\*(C`jal foo\*(C'\fR to be executed speculatively. \s-1GCC\s0 honors this
-restriction for functions it compiles itself. It expects non-GCC
-functions (such as hand-written assembly code) to do the same.
-.Sp
-The option has three forms:
-.IP "\fB\-mr10k\-cache\-barrier=load\-store\fR" 4
-.IX Item "-mr10k-cache-barrier=load-store"
-Insert a cache barrier before a load or store that might be
-speculatively executed and that might have side effects even
-if aborted.
-.IP "\fB\-mr10k\-cache\-barrier=store\fR" 4
-.IX Item "-mr10k-cache-barrier=store"
-Insert a cache barrier before a store that might be speculatively
-executed and that might have side effects even if aborted.
-.IP "\fB\-mr10k\-cache\-barrier=none\fR" 4
-.IX Item "-mr10k-cache-barrier=none"
-Disable the insertion of cache barriers. This is the default setting.
-.RE
-.RS 4
-.RE
-.IP "\fB\-mflush\-func=\fR\fIfunc\fR" 4
-.IX Item "-mflush-func=func"
-.PD 0
-.IP "\fB\-mno\-flush\-func\fR" 4
-.IX Item "-mno-flush-func"
-.PD
-Specifies the function to call to flush the I and D caches, or to not
-call any such function. If called, the function must take the same
-arguments as the common \f(CW\*(C`_flush_func()\*(C'\fR, that is, the address of the
-memory range for which the cache is being flushed, the size of the
-memory range, and the number 3 (to flush both caches). The default
-depends on the target \s-1GCC\s0 was configured for, but commonly is either
-\&\fB_flush_func\fR or \fB_\|_cpu_flush\fR.
-.IP "\fBmbranch\-cost=\fR\fInum\fR" 4
-.IX Item "mbranch-cost=num"
-Set the cost of branches to roughly \fInum\fR \*(L"simple\*(R" instructions.
-This cost is only a heuristic and is not guaranteed to produce
-consistent results across releases. A zero cost redundantly selects
-the default, which is based on the \fB\-mtune\fR setting.
-.IP "\fB\-mbranch\-likely\fR" 4
-.IX Item "-mbranch-likely"
-.PD 0
-.IP "\fB\-mno\-branch\-likely\fR" 4
-.IX Item "-mno-branch-likely"
-.PD
-Enable or disable use of Branch Likely instructions, regardless of the
-default for the selected architecture. By default, Branch Likely
-instructions may be generated if they are supported by the selected
-architecture. An exception is for the \s-1MIPS32\s0 and \s-1MIPS64\s0 architectures
-and processors which implement those architectures; for those, Branch
-Likely instructions will not be generated by default because the \s-1MIPS32\s0
-and \s-1MIPS64\s0 architectures specifically deprecate their use.
-.IP "\fB\-mfp\-exceptions\fR" 4
-.IX Item "-mfp-exceptions"
-.PD 0
-.IP "\fB\-mno\-fp\-exceptions\fR" 4
-.IX Item "-mno-fp-exceptions"
-.PD
-Specifies whether \s-1FP\s0 exceptions are enabled. This affects how we schedule
-\&\s-1FP\s0 instructions for some processors. The default is that \s-1FP\s0 exceptions are
-enabled.
-.Sp
-For instance, on the \s-1SB\-1\s0, if \s-1FP\s0 exceptions are disabled, and we are emitting
-64\-bit code, then we can use both \s-1FP\s0 pipes. Otherwise, we can only use one
-\&\s-1FP\s0 pipe.
-.IP "\fB\-mvr4130\-align\fR" 4
-.IX Item "-mvr4130-align"
-.PD 0
-.IP "\fB\-mno\-vr4130\-align\fR" 4
-.IX Item "-mno-vr4130-align"
-.PD
-The \s-1VR4130\s0 pipeline is two-way superscalar, but can only issue two
-instructions together if the first one is 8\-byte aligned. When this
-option is enabled, \s-1GCC\s0 will align pairs of instructions that it
-thinks should execute in parallel.
-.Sp
-This option only has an effect when optimizing for the \s-1VR4130\s0.
-It normally makes code faster, but at the expense of making it bigger.
-It is enabled by default at optimization level \fB\-O3\fR.
-.IP "\fB\-msynci\fR" 4
-.IX Item "-msynci"
-.PD 0
-.IP "\fB\-mno\-synci\fR" 4
-.IX Item "-mno-synci"
-.PD
-Enable (disable) generation of \f(CW\*(C`synci\*(C'\fR instructions on
-architectures that support it. The \f(CW\*(C`synci\*(C'\fR instructions (if
-enabled) will be generated when \f(CW\*(C`_\|_builtin_\|_\|_clear_cache()\*(C'\fR is
-compiled.
-.Sp
-This option defaults to \f(CW\*(C`\-mno\-synci\*(C'\fR, but the default can be
-overridden by configuring with \f(CW\*(C`\-\-with\-synci\*(C'\fR.
-.Sp
-When compiling code for single processor systems, it is generally safe
-to use \f(CW\*(C`synci\*(C'\fR. However, on many multi-core (\s-1SMP\s0) systems, it
-will not invalidate the instruction caches on all cores and may lead
-to undefined behavior.
-.IP "\fB\-mrelax\-pic\-calls\fR" 4
-.IX Item "-mrelax-pic-calls"
-.PD 0
-.IP "\fB\-mno\-relax\-pic\-calls\fR" 4
-.IX Item "-mno-relax-pic-calls"
-.PD
-Try to turn \s-1PIC\s0 calls that are normally dispatched via register
-\&\f(CW$25\fR into direct calls. This is only possible if the linker can
-resolve the destination at link-time and if the destination is within
-range for a direct call.
-.Sp
-\&\fB\-mrelax\-pic\-calls\fR is the default if \s-1GCC\s0 was configured to use
-an assembler and a linker that supports the \f(CW\*(C`.reloc\*(C'\fR assembly
-directive and \f(CW\*(C`\-mexplicit\-relocs\*(C'\fR is in effect. With
-\&\f(CW\*(C`\-mno\-explicit\-relocs\*(C'\fR, this optimization can be performed by the
-assembler and the linker alone without help from the compiler.
-.IP "\fB\-mmcount\-ra\-address\fR" 4
-.IX Item "-mmcount-ra-address"
-.PD 0
-.IP "\fB\-mno\-mcount\-ra\-address\fR" 4
-.IX Item "-mno-mcount-ra-address"
-.PD
-Emit (do not emit) code that allows \f(CW\*(C`_mcount\*(C'\fR to modify the
-calling function's return address. When enabled, this option extends
-the usual \f(CW\*(C`_mcount\*(C'\fR interface with a new \fIra-address\fR
-parameter, which has type \f(CW\*(C`intptr_t *\*(C'\fR and is passed in register
-\&\f(CW$12\fR. \f(CW\*(C`_mcount\*(C'\fR can then modify the return address by
-doing both of the following:
-.RS 4
-.IP "\(bu" 4
-Returning the new address in register \f(CW$31\fR.
-.IP "\(bu" 4
-Storing the new address in \f(CW\*(C`*\f(CIra\-address\f(CW\*(C'\fR,
-if \fIra-address\fR is nonnull.
-.RE
-.RS 4
-.Sp
-The default is \fB\-mno\-mcount\-ra\-address\fR.
-.RE
-.PP
-\fI\s-1MMIX\s0 Options\fR
-.IX Subsection "MMIX Options"
-.PP
-These options are defined for the \s-1MMIX:\s0
-.IP "\fB\-mlibfuncs\fR" 4
-.IX Item "-mlibfuncs"
-.PD 0
-.IP "\fB\-mno\-libfuncs\fR" 4
-.IX Item "-mno-libfuncs"
-.PD
-Specify that intrinsic library functions are being compiled, passing all
-values in registers, no matter the size.
-.IP "\fB\-mepsilon\fR" 4
-.IX Item "-mepsilon"
-.PD 0
-.IP "\fB\-mno\-epsilon\fR" 4
-.IX Item "-mno-epsilon"
-.PD
-Generate floating-point comparison instructions that compare with respect
-to the \f(CW\*(C`rE\*(C'\fR epsilon register.
-.IP "\fB\-mabi=mmixware\fR" 4
-.IX Item "-mabi=mmixware"
-.PD 0
-.IP "\fB\-mabi=gnu\fR" 4
-.IX Item "-mabi=gnu"
-.PD
-Generate code that passes function parameters and return values that (in
-the called function) are seen as registers \f(CW$0\fR and up, as opposed to
-the \s-1GNU\s0 \s-1ABI\s0 which uses global registers \f(CW$231\fR and up.
-.IP "\fB\-mzero\-extend\fR" 4
-.IX Item "-mzero-extend"
-.PD 0
-.IP "\fB\-mno\-zero\-extend\fR" 4
-.IX Item "-mno-zero-extend"
-.PD
-When reading data from memory in sizes shorter than 64 bits, use (do not
-use) zero-extending load instructions by default, rather than
-sign-extending ones.
-.IP "\fB\-mknuthdiv\fR" 4
-.IX Item "-mknuthdiv"
-.PD 0
-.IP "\fB\-mno\-knuthdiv\fR" 4
-.IX Item "-mno-knuthdiv"
-.PD
-Make the result of a division yielding a remainder have the same sign as
-the divisor. With the default, \fB\-mno\-knuthdiv\fR, the sign of the
-remainder follows the sign of the dividend. Both methods are
-arithmetically valid, the latter being almost exclusively used.
-.IP "\fB\-mtoplevel\-symbols\fR" 4
-.IX Item "-mtoplevel-symbols"
-.PD 0
-.IP "\fB\-mno\-toplevel\-symbols\fR" 4
-.IX Item "-mno-toplevel-symbols"
-.PD
-Prepend (do not prepend) a \fB:\fR to all global symbols, so the assembly
-code can be used with the \f(CW\*(C`PREFIX\*(C'\fR assembly directive.
-.IP "\fB\-melf\fR" 4
-.IX Item "-melf"
-Generate an executable in the \s-1ELF\s0 format, rather than the default
-\&\fBmmo\fR format used by the \fBmmix\fR simulator.
-.IP "\fB\-mbranch\-predict\fR" 4
-.IX Item "-mbranch-predict"
-.PD 0
-.IP "\fB\-mno\-branch\-predict\fR" 4
-.IX Item "-mno-branch-predict"
-.PD
-Use (do not use) the probable-branch instructions, when static branch
-prediction indicates a probable branch.
-.IP "\fB\-mbase\-addresses\fR" 4
-.IX Item "-mbase-addresses"
-.PD 0
-.IP "\fB\-mno\-base\-addresses\fR" 4
-.IX Item "-mno-base-addresses"
-.PD
-Generate (do not generate) code that uses \fIbase addresses\fR. Using a
-base address automatically generates a request (handled by the assembler
-and the linker) for a constant to be set up in a global register. The
-register is used for one or more base address requests within the range 0
-to 255 from the value held in the register. The generally leads to short
-and fast code, but the number of different data items that can be
-addressed is limited. This means that a program that uses lots of static
-data may require \fB\-mno\-base\-addresses\fR.
-.IP "\fB\-msingle\-exit\fR" 4
-.IX Item "-msingle-exit"
-.PD 0
-.IP "\fB\-mno\-single\-exit\fR" 4
-.IX Item "-mno-single-exit"
-.PD
-Force (do not force) generated code to have a single exit point in each
-function.
-.PP
-\fI\s-1MN10300\s0 Options\fR
-.IX Subsection "MN10300 Options"
-.PP
-These \fB\-m\fR options are defined for Matsushita \s-1MN10300\s0 architectures:
-.IP "\fB\-mmult\-bug\fR" 4
-.IX Item "-mmult-bug"
-Generate code to avoid bugs in the multiply instructions for the \s-1MN10300\s0
-processors. This is the default.
-.IP "\fB\-mno\-mult\-bug\fR" 4
-.IX Item "-mno-mult-bug"
-Do not generate code to avoid bugs in the multiply instructions for the
-\&\s-1MN10300\s0 processors.
-.IP "\fB\-mam33\fR" 4
-.IX Item "-mam33"
-Generate code which uses features specific to the \s-1AM33\s0 processor.
-.IP "\fB\-mno\-am33\fR" 4
-.IX Item "-mno-am33"
-Do not generate code which uses features specific to the \s-1AM33\s0 processor. This
-is the default.
-.IP "\fB\-mam33\-2\fR" 4
-.IX Item "-mam33-2"
-Generate code which uses features specific to the \s-1AM33/2\s0.0 processor.
-.IP "\fB\-mam34\fR" 4
-.IX Item "-mam34"
-Generate code which uses features specific to the \s-1AM34\s0 processor.
-.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
-.IX Item "-mtune=cpu-type"
-Use the timing characteristics of the indicated \s-1CPU\s0 type when
-scheduling instructions. This does not change the targeted processor
-type. The \s-1CPU\s0 type must be one of \fBmn10300\fR, \fBam33\fR,
-\&\fBam33\-2\fR or \fBam34\fR.
-.IP "\fB\-mreturn\-pointer\-on\-d0\fR" 4
-.IX Item "-mreturn-pointer-on-d0"
-When generating a function which returns a pointer, return the pointer
-in both \f(CW\*(C`a0\*(C'\fR and \f(CW\*(C`d0\*(C'\fR. Otherwise, the pointer is returned
-only in a0, and attempts to call such functions without a prototype
-would result in errors. Note that this option is on by default; use
-\&\fB\-mno\-return\-pointer\-on\-d0\fR to disable it.
-.IP "\fB\-mno\-crt0\fR" 4
-.IX Item "-mno-crt0"
-Do not link in the C run-time initialization object file.
-.IP "\fB\-mrelax\fR" 4
-.IX Item "-mrelax"
-Indicate to the linker that it should perform a relaxation optimization pass
-to shorten branches, calls and absolute memory addresses. This option only
-has an effect when used on the command line for the final link step.
-.Sp
-This option makes symbolic debugging impossible.
-.IP "\fB\-mliw\fR" 4
-.IX Item "-mliw"
-Allow the compiler to generate \fILong Instruction Word\fR
-instructions if the target is the \fB\s-1AM33\s0\fR or later. This is the
-default. This option defines the preprocessor macro \fB_\|_LIW_\|_\fR.
-.IP "\fB\-mnoliw\fR" 4
-.IX Item "-mnoliw"
-Do not allow the compiler to generate \fILong Instruction Word\fR
-instructions. This option defines the preprocessor macro
-\&\fB_\|_NO_LIW_\|_\fR.
-.PP
-\fI\s-1PDP\-11\s0 Options\fR
-.IX Subsection "PDP-11 Options"
-.PP
-These options are defined for the \s-1PDP\-11:\s0
-.IP "\fB\-mfpu\fR" 4
-.IX Item "-mfpu"
-Use hardware \s-1FPP\s0 floating point. This is the default. (\s-1FIS\s0 floating
-point on the \s-1PDP\-11/40\s0 is not supported.)
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Do not use hardware floating point.
-.IP "\fB\-mac0\fR" 4
-.IX Item "-mac0"
-Return floating-point results in ac0 (fr0 in Unix assembler syntax).
-.IP "\fB\-mno\-ac0\fR" 4
-.IX Item "-mno-ac0"
-Return floating-point results in memory. This is the default.
-.IP "\fB\-m40\fR" 4
-.IX Item "-m40"
-Generate code for a \s-1PDP\-11/40\s0.
-.IP "\fB\-m45\fR" 4
-.IX Item "-m45"
-Generate code for a \s-1PDP\-11/45\s0. This is the default.
-.IP "\fB\-m10\fR" 4
-.IX Item "-m10"
-Generate code for a \s-1PDP\-11/10\s0.
-.IP "\fB\-mbcopy\-builtin\fR" 4
-.IX Item "-mbcopy-builtin"
-Use inline \f(CW\*(C`movmemhi\*(C'\fR patterns for copying memory. This is the
-default.
-.IP "\fB\-mbcopy\fR" 4
-.IX Item "-mbcopy"
-Do not use inline \f(CW\*(C`movmemhi\*(C'\fR patterns for copying memory.
-.IP "\fB\-mint16\fR" 4
-.IX Item "-mint16"
-.PD 0
-.IP "\fB\-mno\-int32\fR" 4
-.IX Item "-mno-int32"
-.PD
-Use 16\-bit \f(CW\*(C`int\*(C'\fR. This is the default.
-.IP "\fB\-mint32\fR" 4
-.IX Item "-mint32"
-.PD 0
-.IP "\fB\-mno\-int16\fR" 4
-.IX Item "-mno-int16"
-.PD
-Use 32\-bit \f(CW\*(C`int\*(C'\fR.
-.IP "\fB\-mfloat64\fR" 4
-.IX Item "-mfloat64"
-.PD 0
-.IP "\fB\-mno\-float32\fR" 4
-.IX Item "-mno-float32"
-.PD
-Use 64\-bit \f(CW\*(C`float\*(C'\fR. This is the default.
-.IP "\fB\-mfloat32\fR" 4
-.IX Item "-mfloat32"
-.PD 0
-.IP "\fB\-mno\-float64\fR" 4
-.IX Item "-mno-float64"
-.PD
-Use 32\-bit \f(CW\*(C`float\*(C'\fR.
-.IP "\fB\-mabshi\fR" 4
-.IX Item "-mabshi"
-Use \f(CW\*(C`abshi2\*(C'\fR pattern. This is the default.
-.IP "\fB\-mno\-abshi\fR" 4
-.IX Item "-mno-abshi"
-Do not use \f(CW\*(C`abshi2\*(C'\fR pattern.
-.IP "\fB\-mbranch\-expensive\fR" 4
-.IX Item "-mbranch-expensive"
-Pretend that branches are expensive. This is for experimenting with
-code generation only.
-.IP "\fB\-mbranch\-cheap\fR" 4
-.IX Item "-mbranch-cheap"
-Do not pretend that branches are expensive. This is the default.
-.IP "\fB\-munix\-asm\fR" 4
-.IX Item "-munix-asm"
-Use Unix assembler syntax. This is the default when configured for
-\&\fBpdp11\-*\-bsd\fR.
-.IP "\fB\-mdec\-asm\fR" 4
-.IX Item "-mdec-asm"
-Use \s-1DEC\s0 assembler syntax. This is the default when configured for any
-\&\s-1PDP\-11\s0 target other than \fBpdp11\-*\-bsd\fR.
-.PP
-\fIpicoChip Options\fR
-.IX Subsection "picoChip Options"
-.PP
-These \fB\-m\fR options are defined for picoChip implementations:
-.IP "\fB\-mae=\fR\fIae_type\fR" 4
-.IX Item "-mae=ae_type"
-Set the instruction set, register set, and instruction scheduling
-parameters for array element type \fIae_type\fR. Supported values
-for \fIae_type\fR are \fB\s-1ANY\s0\fR, \fB\s-1MUL\s0\fR, and \fB\s-1MAC\s0\fR.
-.Sp
-\&\fB\-mae=ANY\fR selects a completely generic \s-1AE\s0 type. Code
-generated with this option will run on any of the other \s-1AE\s0 types. The
-code will not be as efficient as it would be if compiled for a specific
-\&\s-1AE\s0 type, and some types of operation (e.g., multiplication) will not
-work properly on all types of \s-1AE\s0.
-.Sp
-\&\fB\-mae=MUL\fR selects a \s-1MUL\s0 \s-1AE\s0 type. This is the most useful \s-1AE\s0 type
-for compiled code, and is the default.
-.Sp
-\&\fB\-mae=MAC\fR selects a DSP-style \s-1MAC\s0 \s-1AE\s0. Code compiled with this
-option may suffer from poor performance of byte (char) manipulation,
-since the \s-1DSP\s0 \s-1AE\s0 does not provide hardware support for byte load/stores.
-.IP "\fB\-msymbol\-as\-address\fR" 4
-.IX Item "-msymbol-as-address"
-Enable the compiler to directly use a symbol name as an address in a
-load/store instruction, without first loading it into a
-register. Typically, the use of this option will generate larger
-programs, which run faster than when the option isn't used. However, the
-results vary from program to program, so it is left as a user option,
-rather than being permanently enabled.
-.IP "\fB\-mno\-inefficient\-warnings\fR" 4
-.IX Item "-mno-inefficient-warnings"
-Disables warnings about the generation of inefficient code. These
-warnings can be generated, for example, when compiling code which
-performs byte-level memory operations on the \s-1MAC\s0 \s-1AE\s0 type. The \s-1MAC\s0 \s-1AE\s0 has
-no hardware support for byte-level memory operations, so all byte
-load/stores must be synthesized from word load/store operations. This is
-inefficient and a warning will be generated indicating to the programmer
-that they should rewrite the code to avoid byte operations, or to target
-an \s-1AE\s0 type which has the necessary hardware support. This option enables
-the warning to be turned off.
-.PP
-\fIPowerPC Options\fR
-.IX Subsection "PowerPC Options"
-.PP
-These are listed under
-.PP
-\fI\s-1IBM\s0 \s-1RS/6000\s0 and PowerPC Options\fR
-.IX Subsection "IBM RS/6000 and PowerPC Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1IBM\s0 \s-1RS/6000\s0 and PowerPC:
-.IP "\fB\-mpower\fR" 4
-.IX Item "-mpower"
-.PD 0
-.IP "\fB\-mno\-power\fR" 4
-.IX Item "-mno-power"
-.IP "\fB\-mpower2\fR" 4
-.IX Item "-mpower2"
-.IP "\fB\-mno\-power2\fR" 4
-.IX Item "-mno-power2"
-.IP "\fB\-mpowerpc\fR" 4
-.IX Item "-mpowerpc"
-.IP "\fB\-mno\-powerpc\fR" 4
-.IX Item "-mno-powerpc"
-.IP "\fB\-mpowerpc\-gpopt\fR" 4
-.IX Item "-mpowerpc-gpopt"
-.IP "\fB\-mno\-powerpc\-gpopt\fR" 4
-.IX Item "-mno-powerpc-gpopt"
-.IP "\fB\-mpowerpc\-gfxopt\fR" 4
-.IX Item "-mpowerpc-gfxopt"
-.IP "\fB\-mno\-powerpc\-gfxopt\fR" 4
-.IX Item "-mno-powerpc-gfxopt"
-.IP "\fB\-mpowerpc64\fR" 4
-.IX Item "-mpowerpc64"
-.IP "\fB\-mno\-powerpc64\fR" 4
-.IX Item "-mno-powerpc64"
-.IP "\fB\-mmfcrf\fR" 4
-.IX Item "-mmfcrf"
-.IP "\fB\-mno\-mfcrf\fR" 4
-.IX Item "-mno-mfcrf"
-.IP "\fB\-mpopcntb\fR" 4
-.IX Item "-mpopcntb"
-.IP "\fB\-mno\-popcntb\fR" 4
-.IX Item "-mno-popcntb"
-.IP "\fB\-mpopcntd\fR" 4
-.IX Item "-mpopcntd"
-.IP "\fB\-mno\-popcntd\fR" 4
-.IX Item "-mno-popcntd"
-.IP "\fB\-mfprnd\fR" 4
-.IX Item "-mfprnd"
-.IP "\fB\-mno\-fprnd\fR" 4
-.IX Item "-mno-fprnd"
-.IP "\fB\-mcmpb\fR" 4
-.IX Item "-mcmpb"
-.IP "\fB\-mno\-cmpb\fR" 4
-.IX Item "-mno-cmpb"
-.IP "\fB\-mmfpgpr\fR" 4
-.IX Item "-mmfpgpr"
-.IP "\fB\-mno\-mfpgpr\fR" 4
-.IX Item "-mno-mfpgpr"
-.IP "\fB\-mhard\-dfp\fR" 4
-.IX Item "-mhard-dfp"
-.IP "\fB\-mno\-hard\-dfp\fR" 4
-.IX Item "-mno-hard-dfp"
-.PD
-\&\s-1GCC\s0 supports two related instruction set architectures for the
-\&\s-1RS/6000\s0 and PowerPC. The \fI\s-1POWER\s0\fR instruction set are those
-instructions supported by the \fBrios\fR chip set used in the original
-\&\s-1RS/6000\s0 systems and the \fIPowerPC\fR instruction set is the
-architecture of the Freescale MPC5xx, MPC6xx, MPC8xx microprocessors, and
-the \s-1IBM\s0 4xx, 6xx, and follow-on microprocessors.
-.Sp
-Neither architecture is a subset of the other. However there is a
-large common subset of instructions supported by both. An \s-1MQ\s0
-register is included in processors supporting the \s-1POWER\s0 architecture.
-.Sp
-You use these options to specify which instructions are available on the
-processor you are using. The default value of these options is
-determined when configuring \s-1GCC\s0. Specifying the
-\&\fB\-mcpu=\fR\fIcpu_type\fR overrides the specification of these
-options. We recommend you use the \fB\-mcpu=\fR\fIcpu_type\fR option
-rather than the options listed above.
-.Sp
-The \fB\-mpower\fR option allows \s-1GCC\s0 to generate instructions that
-are found only in the \s-1POWER\s0 architecture and to use the \s-1MQ\s0 register.
-Specifying \fB\-mpower2\fR implies \fB\-power\fR and also allows \s-1GCC\s0
-to generate instructions that are present in the \s-1POWER2\s0 architecture but
-not the original \s-1POWER\s0 architecture.
-.Sp
-The \fB\-mpowerpc\fR option allows \s-1GCC\s0 to generate instructions that
-are found only in the 32\-bit subset of the PowerPC architecture.
-Specifying \fB\-mpowerpc\-gpopt\fR implies \fB\-mpowerpc\fR and also allows
-\&\s-1GCC\s0 to use the optional PowerPC architecture instructions in the
-General Purpose group, including floating-point square root. Specifying
-\&\fB\-mpowerpc\-gfxopt\fR implies \fB\-mpowerpc\fR and also allows \s-1GCC\s0 to
-use the optional PowerPC architecture instructions in the Graphics
-group, including floating-point select.
-.Sp
-The \fB\-mmfcrf\fR option allows \s-1GCC\s0 to generate the move from
-condition register field instruction implemented on the \s-1POWER4\s0
-processor and other processors that support the PowerPC V2.01
-architecture.
-The \fB\-mpopcntb\fR option allows \s-1GCC\s0 to generate the popcount and
-double precision \s-1FP\s0 reciprocal estimate instruction implemented on the
-\&\s-1POWER5\s0 processor and other processors that support the PowerPC V2.02
-architecture.
-The \fB\-mpopcntd\fR option allows \s-1GCC\s0 to generate the popcount
-instruction implemented on the \s-1POWER7\s0 processor and other processors
-that support the PowerPC V2.06 architecture.
-The \fB\-mfprnd\fR option allows \s-1GCC\s0 to generate the \s-1FP\s0 round to
-integer instructions implemented on the \s-1POWER5+\s0 processor and other
-processors that support the PowerPC V2.03 architecture.
-The \fB\-mcmpb\fR option allows \s-1GCC\s0 to generate the compare bytes
-instruction implemented on the \s-1POWER6\s0 processor and other processors
-that support the PowerPC V2.05 architecture.
-The \fB\-mmfpgpr\fR option allows \s-1GCC\s0 to generate the \s-1FP\s0 move to/from
-general purpose register instructions implemented on the \s-1POWER6X\s0
-processor and other processors that support the extended PowerPC V2.05
-architecture.
-The \fB\-mhard\-dfp\fR option allows \s-1GCC\s0 to generate the decimal floating
-point instructions implemented on some \s-1POWER\s0 processors.
-.Sp
-The \fB\-mpowerpc64\fR option allows \s-1GCC\s0 to generate the additional
-64\-bit instructions that are found in the full PowerPC64 architecture
-and to treat GPRs as 64\-bit, doubleword quantities. \s-1GCC\s0 defaults to
-\&\fB\-mno\-powerpc64\fR.
-.Sp
-If you specify both \fB\-mno\-power\fR and \fB\-mno\-powerpc\fR, \s-1GCC\s0
-will use only the instructions in the common subset of both
-architectures plus some special \s-1AIX\s0 common-mode calls, and will not use
-the \s-1MQ\s0 register. Specifying both \fB\-mpower\fR and \fB\-mpowerpc\fR
-permits \s-1GCC\s0 to use any instruction from either architecture and to
-allow use of the \s-1MQ\s0 register; specify this for the Motorola \s-1MPC601\s0.
-.IP "\fB\-mnew\-mnemonics\fR" 4
-.IX Item "-mnew-mnemonics"
-.PD 0
-.IP "\fB\-mold\-mnemonics\fR" 4
-.IX Item "-mold-mnemonics"
-.PD
-Select which mnemonics to use in the generated assembler code. With
-\&\fB\-mnew\-mnemonics\fR, \s-1GCC\s0 uses the assembler mnemonics defined for
-the PowerPC architecture. With \fB\-mold\-mnemonics\fR it uses the
-assembler mnemonics defined for the \s-1POWER\s0 architecture. Instructions
-defined in only one architecture have only one mnemonic; \s-1GCC\s0 uses that
-mnemonic irrespective of which of these options is specified.
-.Sp
-\&\s-1GCC\s0 defaults to the mnemonics appropriate for the architecture in
-use. Specifying \fB\-mcpu=\fR\fIcpu_type\fR sometimes overrides the
-value of these option. Unless you are building a cross-compiler, you
-should normally not specify either \fB\-mnew\-mnemonics\fR or
-\&\fB\-mold\-mnemonics\fR, but should instead accept the default.
-.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
-.IX Item "-mcpu=cpu_type"
-Set architecture type, register usage, choice of mnemonics, and
-instruction scheduling parameters for machine type \fIcpu_type\fR.
-Supported values for \fIcpu_type\fR are \fB401\fR, \fB403\fR,
-\&\fB405\fR, \fB405fp\fR, \fB440\fR, \fB440fp\fR, \fB464\fR, \fB464fp\fR,
-\&\fB476\fR, \fB476fp\fR, \fB505\fR, \fB601\fR, \fB602\fR, \fB603\fR,
-\&\fB603e\fR, \fB604\fR, \fB604e\fR, \fB620\fR, \fB630\fR, \fB740\fR,
-\&\fB7400\fR, \fB7450\fR, \fB750\fR, \fB801\fR, \fB821\fR, \fB823\fR,
-\&\fB860\fR, \fB970\fR, \fB8540\fR, \fBa2\fR, \fBe300c2\fR,
-\&\fBe300c3\fR, \fBe500mc\fR, \fBe500mc64\fR, \fBec603e\fR, \fBG3\fR,
-\&\fBG4\fR, \fBG5\fR, \fBtitan\fR, \fBpower\fR, \fBpower2\fR, \fBpower3\fR,
-\&\fBpower4\fR, \fBpower5\fR, \fBpower5+\fR, \fBpower6\fR, \fBpower6x\fR,
-\&\fBpower7\fR, \fBcommon\fR, \fBpowerpc\fR, \fBpowerpc64\fR, \fBrios\fR,
-\&\fBrios1\fR, \fBrios2\fR, \fBrsc\fR, and \fBrs64\fR.
-.Sp
-\&\fB\-mcpu=common\fR selects a completely generic processor. Code
-generated under this option will run on any \s-1POWER\s0 or PowerPC processor.
-\&\s-1GCC\s0 will use only the instructions in the common subset of both
-architectures, and will not use the \s-1MQ\s0 register. \s-1GCC\s0 assumes a generic
-processor model for scheduling purposes.
-.Sp
-\&\fB\-mcpu=power\fR, \fB\-mcpu=power2\fR, \fB\-mcpu=powerpc\fR, and
-\&\fB\-mcpu=powerpc64\fR specify generic \s-1POWER\s0, \s-1POWER2\s0, pure 32\-bit
-PowerPC (i.e., not \s-1MPC601\s0), and 64\-bit PowerPC architecture machine
-types, with an appropriate, generic processor model assumed for
-scheduling purposes.
-.Sp
-The other options specify a specific processor. Code generated under
-those options will run best on that processor, and may not run at all on
-others.
-.Sp
-The \fB\-mcpu\fR options automatically enable or disable the
-following options:
-.Sp
-\&\fB\-maltivec \-mfprnd \-mhard\-float \-mmfcrf \-mmultiple
-\&\-mnew\-mnemonics \-mpopcntb \-mpopcntd \-mpower \-mpower2 \-mpowerpc64
-\&\-mpowerpc\-gpopt \-mpowerpc\-gfxopt \-msingle\-float \-mdouble\-float
-\&\-msimple\-fpu \-mstring \-mmulhw \-mdlmzb \-mmfpgpr \-mvsx\fR
-.Sp
-The particular options set for any particular \s-1CPU\s0 will vary between
-compiler versions, depending on what setting seems to produce optimal
-code for that \s-1CPU\s0; it doesn't necessarily reflect the actual hardware's
-capabilities. If you wish to set an individual option to a particular
-value, you may specify it after the \fB\-mcpu\fR option, like
-\&\fB\-mcpu=970 \-mno\-altivec\fR.
-.Sp
-On \s-1AIX\s0, the \fB\-maltivec\fR and \fB\-mpowerpc64\fR options are
-not enabled or disabled by the \fB\-mcpu\fR option at present because
-\&\s-1AIX\s0 does not have full support for these options. You may still
-enable or disable them individually if you're sure it'll work in your
-environment.
-.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
-.IX Item "-mtune=cpu_type"
-Set the instruction scheduling parameters for machine type
-\&\fIcpu_type\fR, but do not set the architecture type, register usage, or
-choice of mnemonics, as \fB\-mcpu=\fR\fIcpu_type\fR would. The same
-values for \fIcpu_type\fR are used for \fB\-mtune\fR as for
-\&\fB\-mcpu\fR. If both are specified, the code generated will use the
-architecture, registers, and mnemonics set by \fB\-mcpu\fR, but the
-scheduling parameters set by \fB\-mtune\fR.
-.IP "\fB\-mcmodel=small\fR" 4
-.IX Item "-mcmodel=small"
-Generate PowerPC64 code for the small model: The \s-1TOC\s0 is limited to
-64k.
-.IP "\fB\-mcmodel=medium\fR" 4
-.IX Item "-mcmodel=medium"
-Generate PowerPC64 code for the medium model: The \s-1TOC\s0 and other static
-data may be up to a total of 4G in size.
-.IP "\fB\-mcmodel=large\fR" 4
-.IX Item "-mcmodel=large"
-Generate PowerPC64 code for the large model: The \s-1TOC\s0 may be up to 4G
-in size. Other data and code is only limited by the 64\-bit address
-space.
-.IP "\fB\-maltivec\fR" 4
-.IX Item "-maltivec"
-.PD 0
-.IP "\fB\-mno\-altivec\fR" 4
-.IX Item "-mno-altivec"
-.PD
-Generate code that uses (does not use) AltiVec instructions, and also
-enable the use of built-in functions that allow more direct access to
-the AltiVec instruction set. You may also need to set
-\&\fB\-mabi=altivec\fR to adjust the current \s-1ABI\s0 with AltiVec \s-1ABI\s0
-enhancements.
-.IP "\fB\-mvrsave\fR" 4
-.IX Item "-mvrsave"
-.PD 0
-.IP "\fB\-mno\-vrsave\fR" 4
-.IX Item "-mno-vrsave"
-.PD
-Generate \s-1VRSAVE\s0 instructions when generating AltiVec code.
-.IP "\fB\-mgen\-cell\-microcode\fR" 4
-.IX Item "-mgen-cell-microcode"
-Generate Cell microcode instructions
-.IP "\fB\-mwarn\-cell\-microcode\fR" 4
-.IX Item "-mwarn-cell-microcode"
-Warning when a Cell microcode instruction is going to emitted. An example
-of a Cell microcode instruction is a variable shift.
-.IP "\fB\-msecure\-plt\fR" 4
-.IX Item "-msecure-plt"
-Generate code that allows ld and ld.so to build executables and shared
-libraries with non-exec .plt and .got sections. This is a PowerPC
-32\-bit \s-1SYSV\s0 \s-1ABI\s0 option.
-.IP "\fB\-mbss\-plt\fR" 4
-.IX Item "-mbss-plt"
-Generate code that uses a \s-1BSS\s0 .plt section that ld.so fills in, and
-requires .plt and .got sections that are both writable and executable.
-This is a PowerPC 32\-bit \s-1SYSV\s0 \s-1ABI\s0 option.
-.IP "\fB\-misel\fR" 4
-.IX Item "-misel"
-.PD 0
-.IP "\fB\-mno\-isel\fR" 4
-.IX Item "-mno-isel"
-.PD
-This switch enables or disables the generation of \s-1ISEL\s0 instructions.
-.IP "\fB\-misel=\fR\fIyes/no\fR" 4
-.IX Item "-misel=yes/no"
-This switch has been deprecated. Use \fB\-misel\fR and
-\&\fB\-mno\-isel\fR instead.
-.IP "\fB\-mspe\fR" 4
-.IX Item "-mspe"
-.PD 0
-.IP "\fB\-mno\-spe\fR" 4
-.IX Item "-mno-spe"
-.PD
-This switch enables or disables the generation of \s-1SPE\s0 simd
-instructions.
-.IP "\fB\-mpaired\fR" 4
-.IX Item "-mpaired"
-.PD 0
-.IP "\fB\-mno\-paired\fR" 4
-.IX Item "-mno-paired"
-.PD
-This switch enables or disables the generation of \s-1PAIRED\s0 simd
-instructions.
-.IP "\fB\-mspe=\fR\fIyes/no\fR" 4
-.IX Item "-mspe=yes/no"
-This option has been deprecated. Use \fB\-mspe\fR and
-\&\fB\-mno\-spe\fR instead.
-.IP "\fB\-mvsx\fR" 4
-.IX Item "-mvsx"
-.PD 0
-.IP "\fB\-mno\-vsx\fR" 4
-.IX Item "-mno-vsx"
-.PD
-Generate code that uses (does not use) vector/scalar (\s-1VSX\s0)
-instructions, and also enable the use of built-in functions that allow
-more direct access to the \s-1VSX\s0 instruction set.
-.IP "\fB\-mfloat\-gprs=\fR\fIyes/single/double/no\fR" 4
-.IX Item "-mfloat-gprs=yes/single/double/no"
-.PD 0
-.IP "\fB\-mfloat\-gprs\fR" 4
-.IX Item "-mfloat-gprs"
-.PD
-This switch enables or disables the generation of floating point
-operations on the general purpose registers for architectures that
-support it.
-.Sp
-The argument \fIyes\fR or \fIsingle\fR enables the use of
-single-precision floating point operations.
-.Sp
-The argument \fIdouble\fR enables the use of single and
-double-precision floating point operations.
-.Sp
-The argument \fIno\fR disables floating point operations on the
-general purpose registers.
-.Sp
-This option is currently only available on the MPC854x.
-.IP "\fB\-m32\fR" 4
-.IX Item "-m32"
-.PD 0
-.IP "\fB\-m64\fR" 4
-.IX Item "-m64"
-.PD
-Generate code for 32\-bit or 64\-bit environments of Darwin and \s-1SVR4\s0
-targets (including GNU/Linux). The 32\-bit environment sets int, long
-and pointer to 32 bits and generates code that runs on any PowerPC
-variant. The 64\-bit environment sets int to 32 bits and long and
-pointer to 64 bits, and generates code for PowerPC64, as for
-\&\fB\-mpowerpc64\fR.
-.IP "\fB\-mfull\-toc\fR" 4
-.IX Item "-mfull-toc"
-.PD 0
-.IP "\fB\-mno\-fp\-in\-toc\fR" 4
-.IX Item "-mno-fp-in-toc"
-.IP "\fB\-mno\-sum\-in\-toc\fR" 4
-.IX Item "-mno-sum-in-toc"
-.IP "\fB\-mminimal\-toc\fR" 4
-.IX Item "-mminimal-toc"
-.PD
-Modify generation of the \s-1TOC\s0 (Table Of Contents), which is created for
-every executable file. The \fB\-mfull\-toc\fR option is selected by
-default. In that case, \s-1GCC\s0 will allocate at least one \s-1TOC\s0 entry for
-each unique non-automatic variable reference in your program. \s-1GCC\s0
-will also place floating-point constants in the \s-1TOC\s0. However, only
-16,384 entries are available in the \s-1TOC\s0.
-.Sp
-If you receive a linker error message that saying you have overflowed
-the available \s-1TOC\s0 space, you can reduce the amount of \s-1TOC\s0 space used
-with the \fB\-mno\-fp\-in\-toc\fR and \fB\-mno\-sum\-in\-toc\fR options.
-\&\fB\-mno\-fp\-in\-toc\fR prevents \s-1GCC\s0 from putting floating-point
-constants in the \s-1TOC\s0 and \fB\-mno\-sum\-in\-toc\fR forces \s-1GCC\s0 to
-generate code to calculate the sum of an address and a constant at
-run-time instead of putting that sum into the \s-1TOC\s0. You may specify one
-or both of these options. Each causes \s-1GCC\s0 to produce very slightly
-slower and larger code at the expense of conserving \s-1TOC\s0 space.
-.Sp
-If you still run out of space in the \s-1TOC\s0 even when you specify both of
-these options, specify \fB\-mminimal\-toc\fR instead. This option causes
-\&\s-1GCC\s0 to make only one \s-1TOC\s0 entry for every file. When you specify this
-option, \s-1GCC\s0 will produce code that is slower and larger but which
-uses extremely little \s-1TOC\s0 space. You may wish to use this option
-only on files that contain less frequently executed code.
-.IP "\fB\-maix64\fR" 4
-.IX Item "-maix64"
-.PD 0
-.IP "\fB\-maix32\fR" 4
-.IX Item "-maix32"
-.PD
-Enable 64\-bit \s-1AIX\s0 \s-1ABI\s0 and calling convention: 64\-bit pointers, 64\-bit
-\&\f(CW\*(C`long\*(C'\fR type, and the infrastructure needed to support them.
-Specifying \fB\-maix64\fR implies \fB\-mpowerpc64\fR and
-\&\fB\-mpowerpc\fR, while \fB\-maix32\fR disables the 64\-bit \s-1ABI\s0 and
-implies \fB\-mno\-powerpc64\fR. \s-1GCC\s0 defaults to \fB\-maix32\fR.
-.IP "\fB\-mxl\-compat\fR" 4
-.IX Item "-mxl-compat"
-.PD 0
-.IP "\fB\-mno\-xl\-compat\fR" 4
-.IX Item "-mno-xl-compat"
-.PD
-Produce code that conforms more closely to \s-1IBM\s0 \s-1XL\s0 compiler semantics
-when using AIX-compatible \s-1ABI\s0. Pass floating-point arguments to
-prototyped functions beyond the register save area (\s-1RSA\s0) on the stack
-in addition to argument FPRs. Do not assume that most significant
-double in 128\-bit long double value is properly rounded when comparing
-values and converting to double. Use \s-1XL\s0 symbol names for long double
-support routines.
-.Sp
-The \s-1AIX\s0 calling convention was extended but not initially documented to
-handle an obscure K&R C case of calling a function that takes the
-address of its arguments with fewer arguments than declared. \s-1IBM\s0 \s-1XL\s0
-compilers access floating point arguments which do not fit in the
-\&\s-1RSA\s0 from the stack when a subroutine is compiled without
-optimization. Because always storing floating-point arguments on the
-stack is inefficient and rarely needed, this option is not enabled by
-default and only is necessary when calling subroutines compiled by \s-1IBM\s0
-\&\s-1XL\s0 compilers without optimization.
-.IP "\fB\-mpe\fR" 4
-.IX Item "-mpe"
-Support \fI\s-1IBM\s0 \s-1RS/6000\s0 \s-1SP\s0\fR \fIParallel Environment\fR (\s-1PE\s0). Link an
-application written to use message passing with special startup code to
-enable the application to run. The system must have \s-1PE\s0 installed in the
-standard location (\fI/usr/lpp/ppe.poe/\fR), or the \fIspecs\fR file
-must be overridden with the \fB\-specs=\fR option to specify the
-appropriate directory location. The Parallel Environment does not
-support threads, so the \fB\-mpe\fR option and the \fB\-pthread\fR
-option are incompatible.
-.IP "\fB\-malign\-natural\fR" 4
-.IX Item "-malign-natural"
-.PD 0
-.IP "\fB\-malign\-power\fR" 4
-.IX Item "-malign-power"
-.PD
-On \s-1AIX\s0, 32\-bit Darwin, and 64\-bit PowerPC GNU/Linux, the option
-\&\fB\-malign\-natural\fR overrides the ABI-defined alignment of larger
-types, such as floating-point doubles, on their natural size-based boundary.
-The option \fB\-malign\-power\fR instructs \s-1GCC\s0 to follow the ABI-specified
-alignment rules. \s-1GCC\s0 defaults to the standard alignment defined in the \s-1ABI\s0.
-.Sp
-On 64\-bit Darwin, natural alignment is the default, and \fB\-malign\-power\fR
-is not supported.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-.PD 0
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-.PD
-Generate code that does not use (uses) the floating-point register set.
-Software floating point emulation is provided if you use the
-\&\fB\-msoft\-float\fR option, and pass the option to \s-1GCC\s0 when linking.
-.IP "\fB\-msingle\-float\fR" 4
-.IX Item "-msingle-float"
-.PD 0
-.IP "\fB\-mdouble\-float\fR" 4
-.IX Item "-mdouble-float"
-.PD
-Generate code for single or double-precision floating point operations.
-\&\fB\-mdouble\-float\fR implies \fB\-msingle\-float\fR.
-.IP "\fB\-msimple\-fpu\fR" 4
-.IX Item "-msimple-fpu"
-Do not generate sqrt and div instructions for hardware floating point unit.
-.IP "\fB\-mfpu\fR" 4
-.IX Item "-mfpu"
-Specify type of floating point unit. Valid values are \fIsp_lite\fR
-(equivalent to \-msingle\-float \-msimple\-fpu), \fIdp_lite\fR (equivalent
-to \-mdouble\-float \-msimple\-fpu), \fIsp_full\fR (equivalent to \-msingle\-float),
-and \fIdp_full\fR (equivalent to \-mdouble\-float).
-.IP "\fB\-mxilinx\-fpu\fR" 4
-.IX Item "-mxilinx-fpu"
-Perform optimizations for floating point unit on Xilinx \s-1PPC\s0 405/440.
-.IP "\fB\-mmultiple\fR" 4
-.IX Item "-mmultiple"
-.PD 0
-.IP "\fB\-mno\-multiple\fR" 4
-.IX Item "-mno-multiple"
-.PD
-Generate code that uses (does not use) the load multiple word
-instructions and the store multiple word instructions. These
-instructions are generated by default on \s-1POWER\s0 systems, and not
-generated on PowerPC systems. Do not use \fB\-mmultiple\fR on little
-endian PowerPC systems, since those instructions do not work when the
-processor is in little endian mode. The exceptions are \s-1PPC740\s0 and
-\&\s-1PPC750\s0 which permit the instructions usage in little endian mode.
-.IP "\fB\-mstring\fR" 4
-.IX Item "-mstring"
-.PD 0
-.IP "\fB\-mno\-string\fR" 4
-.IX Item "-mno-string"
-.PD
-Generate code that uses (does not use) the load string instructions
-and the store string word instructions to save multiple registers and
-do small block moves. These instructions are generated by default on
-\&\s-1POWER\s0 systems, and not generated on PowerPC systems. Do not use
-\&\fB\-mstring\fR on little endian PowerPC systems, since those
-instructions do not work when the processor is in little endian mode.
-The exceptions are \s-1PPC740\s0 and \s-1PPC750\s0 which permit the instructions
-usage in little endian mode.
-.IP "\fB\-mupdate\fR" 4
-.IX Item "-mupdate"
-.PD 0
-.IP "\fB\-mno\-update\fR" 4
-.IX Item "-mno-update"
-.PD
-Generate code that uses (does not use) the load or store instructions
-that update the base register to the address of the calculated memory
-location. These instructions are generated by default. If you use
-\&\fB\-mno\-update\fR, there is a small window between the time that the
-stack pointer is updated and the address of the previous frame is
-stored, which means code that walks the stack frame across interrupts or
-signals may get corrupted data.
-.IP "\fB\-mavoid\-indexed\-addresses\fR" 4
-.IX Item "-mavoid-indexed-addresses"
-.PD 0
-.IP "\fB\-mno\-avoid\-indexed\-addresses\fR" 4
-.IX Item "-mno-avoid-indexed-addresses"
-.PD
-Generate code that tries to avoid (not avoid) the use of indexed load
-or store instructions. These instructions can incur a performance
-penalty on Power6 processors in certain situations, such as when
-stepping through large arrays that cross a 16M boundary. This option
-is enabled by default when targetting Power6 and disabled otherwise.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Generate code that uses (does not use) the floating point multiply and
-accumulate instructions. These instructions are generated by default
-if hardware floating point is used. The machine dependent
-\&\fB\-mfused\-madd\fR option is now mapped to the machine independent
-\&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
-mapped to \fB\-ffp\-contract=off\fR.
-.IP "\fB\-mmulhw\fR" 4
-.IX Item "-mmulhw"
-.PD 0
-.IP "\fB\-mno\-mulhw\fR" 4
-.IX Item "-mno-mulhw"
-.PD
-Generate code that uses (does not use) the half-word multiply and
-multiply-accumulate instructions on the \s-1IBM\s0 405, 440, 464 and 476 processors.
-These instructions are generated by default when targetting those
-processors.
-.IP "\fB\-mdlmzb\fR" 4
-.IX Item "-mdlmzb"
-.PD 0
-.IP "\fB\-mno\-dlmzb\fR" 4
-.IX Item "-mno-dlmzb"
-.PD
-Generate code that uses (does not use) the string-search \fBdlmzb\fR
-instruction on the \s-1IBM\s0 405, 440, 464 and 476 processors. This instruction is
-generated by default when targetting those processors.
-.IP "\fB\-mno\-bit\-align\fR" 4
-.IX Item "-mno-bit-align"
-.PD 0
-.IP "\fB\-mbit\-align\fR" 4
-.IX Item "-mbit-align"
-.PD
-On System V.4 and embedded PowerPC systems do not (do) force structures
-and unions that contain bit-fields to be aligned to the base type of the
-bit-field.
-.Sp
-For example, by default a structure containing nothing but 8
-\&\f(CW\*(C`unsigned\*(C'\fR bit-fields of length 1 would be aligned to a 4 byte
-boundary and have a size of 4 bytes. By using \fB\-mno\-bit\-align\fR,
-the structure would be aligned to a 1 byte boundary and be one byte in
-size.
-.IP "\fB\-mno\-strict\-align\fR" 4
-.IX Item "-mno-strict-align"
-.PD 0
-.IP "\fB\-mstrict\-align\fR" 4
-.IX Item "-mstrict-align"
-.PD
-On System V.4 and embedded PowerPC systems do not (do) assume that
-unaligned memory references will be handled by the system.
-.IP "\fB\-mrelocatable\fR" 4
-.IX Item "-mrelocatable"
-.PD 0
-.IP "\fB\-mno\-relocatable\fR" 4
-.IX Item "-mno-relocatable"
-.PD
-Generate code that allows (does not allow) a static executable to be
-relocated to a different address at runtime. A simple embedded
-PowerPC system loader should relocate the entire contents of
-\&\f(CW\*(C`.got2\*(C'\fR and 4\-byte locations listed in the \f(CW\*(C`.fixup\*(C'\fR section,
-a table of 32\-bit addresses generated by this option. For this to
-work, all objects linked together must be compiled with
-\&\fB\-mrelocatable\fR or \fB\-mrelocatable\-lib\fR.
-\&\fB\-mrelocatable\fR code aligns the stack to an 8 byte boundary.
-.IP "\fB\-mrelocatable\-lib\fR" 4
-.IX Item "-mrelocatable-lib"
-.PD 0
-.IP "\fB\-mno\-relocatable\-lib\fR" 4
-.IX Item "-mno-relocatable-lib"
-.PD
-Like \fB\-mrelocatable\fR, \fB\-mrelocatable\-lib\fR generates a
-\&\f(CW\*(C`.fixup\*(C'\fR section to allow static executables to be relocated at
-runtime, but \fB\-mrelocatable\-lib\fR does not use the smaller stack
-alignment of \fB\-mrelocatable\fR. Objects compiled with
-\&\fB\-mrelocatable\-lib\fR may be linked with objects compiled with
-any combination of the \fB\-mrelocatable\fR options.
-.IP "\fB\-mno\-toc\fR" 4
-.IX Item "-mno-toc"
-.PD 0
-.IP "\fB\-mtoc\fR" 4
-.IX Item "-mtoc"
-.PD
-On System V.4 and embedded PowerPC systems do not (do) assume that
-register 2 contains a pointer to a global area pointing to the addresses
-used in the program.
-.IP "\fB\-mlittle\fR" 4
-.IX Item "-mlittle"
-.PD 0
-.IP "\fB\-mlittle\-endian\fR" 4
-.IX Item "-mlittle-endian"
-.PD
-On System V.4 and embedded PowerPC systems compile code for the
-processor in little endian mode. The \fB\-mlittle\-endian\fR option is
-the same as \fB\-mlittle\fR.
-.IP "\fB\-mbig\fR" 4
-.IX Item "-mbig"
-.PD 0
-.IP "\fB\-mbig\-endian\fR" 4
-.IX Item "-mbig-endian"
-.PD
-On System V.4 and embedded PowerPC systems compile code for the
-processor in big endian mode. The \fB\-mbig\-endian\fR option is
-the same as \fB\-mbig\fR.
-.IP "\fB\-mdynamic\-no\-pic\fR" 4
-.IX Item "-mdynamic-no-pic"
-On Darwin and Mac \s-1OS\s0 X systems, compile code so that it is not
-relocatable, but that its external references are relocatable. The
-resulting code is suitable for applications, but not shared
-libraries.
-.IP "\fB\-msingle\-pic\-base\fR" 4
-.IX Item "-msingle-pic-base"
-Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
-loading it in the prologue for each function. The run-time system is
-responsible for initializing this register with an appropriate value
-before execution begins.
-.IP "\fB\-mprioritize\-restricted\-insns=\fR\fIpriority\fR" 4
-.IX Item "-mprioritize-restricted-insns=priority"
-This option controls the priority that is assigned to
-dispatch-slot restricted instructions during the second scheduling
-pass. The argument \fIpriority\fR takes the value \fI0/1/2\fR to assign
-\&\fIno/highest/second\-highest\fR priority to dispatch slot restricted
-instructions.
-.IP "\fB\-msched\-costly\-dep=\fR\fIdependence_type\fR" 4
-.IX Item "-msched-costly-dep=dependence_type"
-This option controls which dependences are considered costly
-by the target during instruction scheduling. The argument
-\&\fIdependence_type\fR takes one of the following values:
-\&\fIno\fR: no dependence is costly,
-\&\fIall\fR: all dependences are costly,
-\&\fItrue_store_to_load\fR: a true dependence from store to load is costly,
-\&\fIstore_to_load\fR: any dependence from store to load is costly,
-\&\fInumber\fR: any dependence which latency >= \fInumber\fR is costly.
-.IP "\fB\-minsert\-sched\-nops=\fR\fIscheme\fR" 4
-.IX Item "-minsert-sched-nops=scheme"
-This option controls which nop insertion scheme will be used during
-the second scheduling pass. The argument \fIscheme\fR takes one of the
-following values:
-\&\fIno\fR: Don't insert nops.
-\&\fIpad\fR: Pad with nops any dispatch group which has vacant issue slots,
-according to the scheduler's grouping.
-\&\fIregroup_exact\fR: Insert nops to force costly dependent insns into
-separate groups. Insert exactly as many nops as needed to force an insn
-to a new group, according to the estimated processor grouping.
-\&\fInumber\fR: Insert nops to force costly dependent insns into
-separate groups. Insert \fInumber\fR nops to force an insn to a new group.
-.IP "\fB\-mcall\-sysv\fR" 4
-.IX Item "-mcall-sysv"
-On System V.4 and embedded PowerPC systems compile code using calling
-conventions that adheres to the March 1995 draft of the System V
-Application Binary Interface, PowerPC processor supplement. This is the
-default unless you configured \s-1GCC\s0 using \fBpowerpc\-*\-eabiaix\fR.
-.IP "\fB\-mcall\-sysv\-eabi\fR" 4
-.IX Item "-mcall-sysv-eabi"
-.PD 0
-.IP "\fB\-mcall\-eabi\fR" 4
-.IX Item "-mcall-eabi"
-.PD
-Specify both \fB\-mcall\-sysv\fR and \fB\-meabi\fR options.
-.IP "\fB\-mcall\-sysv\-noeabi\fR" 4
-.IX Item "-mcall-sysv-noeabi"
-Specify both \fB\-mcall\-sysv\fR and \fB\-mno\-eabi\fR options.
-.IP "\fB\-mcall\-aixdesc\fR" 4
-.IX Item "-mcall-aixdesc"
-On System V.4 and embedded PowerPC systems compile code for the \s-1AIX\s0
-operating system.
-.IP "\fB\-mcall\-linux\fR" 4
-.IX Item "-mcall-linux"
-On System V.4 and embedded PowerPC systems compile code for the
-Linux-based \s-1GNU\s0 system.
-.IP "\fB\-mcall\-gnu\fR" 4
-.IX Item "-mcall-gnu"
-On System V.4 and embedded PowerPC systems compile code for the
-Hurd-based \s-1GNU\s0 system.
-.IP "\fB\-mcall\-freebsd\fR" 4
-.IX Item "-mcall-freebsd"
-On System V.4 and embedded PowerPC systems compile code for the
-FreeBSD operating system.
-.IP "\fB\-mcall\-netbsd\fR" 4
-.IX Item "-mcall-netbsd"
-On System V.4 and embedded PowerPC systems compile code for the
-NetBSD operating system.
-.IP "\fB\-mcall\-openbsd\fR" 4
-.IX Item "-mcall-openbsd"
-On System V.4 and embedded PowerPC systems compile code for the
-OpenBSD operating system.
-.IP "\fB\-maix\-struct\-return\fR" 4
-.IX Item "-maix-struct-return"
-Return all structures in memory (as specified by the \s-1AIX\s0 \s-1ABI\s0).
-.IP "\fB\-msvr4\-struct\-return\fR" 4
-.IX Item "-msvr4-struct-return"
-Return structures smaller than 8 bytes in registers (as specified by the
-\&\s-1SVR4\s0 \s-1ABI\s0).
-.IP "\fB\-mabi=\fR\fIabi-type\fR" 4
-.IX Item "-mabi=abi-type"
-Extend the current \s-1ABI\s0 with a particular extension, or remove such extension.
-Valid values are \fIaltivec\fR, \fIno-altivec\fR, \fIspe\fR,
-\&\fIno-spe\fR, \fIibmlongdouble\fR, \fIieeelongdouble\fR.
-.IP "\fB\-mabi=spe\fR" 4
-.IX Item "-mabi=spe"
-Extend the current \s-1ABI\s0 with \s-1SPE\s0 \s-1ABI\s0 extensions. This does not change
-the default \s-1ABI\s0, instead it adds the \s-1SPE\s0 \s-1ABI\s0 extensions to the current
-\&\s-1ABI\s0.
-.IP "\fB\-mabi=no\-spe\fR" 4
-.IX Item "-mabi=no-spe"
-Disable Booke \s-1SPE\s0 \s-1ABI\s0 extensions for the current \s-1ABI\s0.
-.IP "\fB\-mabi=ibmlongdouble\fR" 4
-.IX Item "-mabi=ibmlongdouble"
-Change the current \s-1ABI\s0 to use \s-1IBM\s0 extended precision long double.
-This is a PowerPC 32\-bit \s-1SYSV\s0 \s-1ABI\s0 option.
-.IP "\fB\-mabi=ieeelongdouble\fR" 4
-.IX Item "-mabi=ieeelongdouble"
-Change the current \s-1ABI\s0 to use \s-1IEEE\s0 extended precision long double.
-This is a PowerPC 32\-bit Linux \s-1ABI\s0 option.
-.IP "\fB\-mprototype\fR" 4
-.IX Item "-mprototype"
-.PD 0
-.IP "\fB\-mno\-prototype\fR" 4
-.IX Item "-mno-prototype"
-.PD
-On System V.4 and embedded PowerPC systems assume that all calls to
-variable argument functions are properly prototyped. Otherwise, the
-compiler must insert an instruction before every non prototyped call to
-set or clear bit 6 of the condition code register (\fI\s-1CR\s0\fR) to
-indicate whether floating point values were passed in the floating point
-registers in case the function takes a variable arguments. With
-\&\fB\-mprototype\fR, only calls to prototyped variable argument functions
-will set or clear the bit.
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-On embedded PowerPC systems, assume that the startup module is called
-\&\fIsim\-crt0.o\fR and that the standard C libraries are \fIlibsim.a\fR and
-\&\fIlibc.a\fR. This is the default for \fBpowerpc\-*\-eabisim\fR
-configurations.
-.IP "\fB\-mmvme\fR" 4
-.IX Item "-mmvme"
-On embedded PowerPC systems, assume that the startup module is called
-\&\fIcrt0.o\fR and the standard C libraries are \fIlibmvme.a\fR and
-\&\fIlibc.a\fR.
-.IP "\fB\-mads\fR" 4
-.IX Item "-mads"
-On embedded PowerPC systems, assume that the startup module is called
-\&\fIcrt0.o\fR and the standard C libraries are \fIlibads.a\fR and
-\&\fIlibc.a\fR.
-.IP "\fB\-myellowknife\fR" 4
-.IX Item "-myellowknife"
-On embedded PowerPC systems, assume that the startup module is called
-\&\fIcrt0.o\fR and the standard C libraries are \fIlibyk.a\fR and
-\&\fIlibc.a\fR.
-.IP "\fB\-mvxworks\fR" 4
-.IX Item "-mvxworks"
-On System V.4 and embedded PowerPC systems, specify that you are
-compiling for a VxWorks system.
-.IP "\fB\-memb\fR" 4
-.IX Item "-memb"
-On embedded PowerPC systems, set the \fI\s-1PPC_EMB\s0\fR bit in the \s-1ELF\s0 flags
-header to indicate that \fBeabi\fR extended relocations are used.
-.IP "\fB\-meabi\fR" 4
-.IX Item "-meabi"
-.PD 0
-.IP "\fB\-mno\-eabi\fR" 4
-.IX Item "-mno-eabi"
-.PD
-On System V.4 and embedded PowerPC systems do (do not) adhere to the
-Embedded Applications Binary Interface (eabi) which is a set of
-modifications to the System V.4 specifications. Selecting \fB\-meabi\fR
-means that the stack is aligned to an 8 byte boundary, a function
-\&\f(CW\*(C`_\|_eabi\*(C'\fR is called to from \f(CW\*(C`main\*(C'\fR to set up the eabi
-environment, and the \fB\-msdata\fR option can use both \f(CW\*(C`r2\*(C'\fR and
-\&\f(CW\*(C`r13\*(C'\fR to point to two separate small data areas. Selecting
-\&\fB\-mno\-eabi\fR means that the stack is aligned to a 16 byte boundary,
-do not call an initialization function from \f(CW\*(C`main\*(C'\fR, and the
-\&\fB\-msdata\fR option will only use \f(CW\*(C`r13\*(C'\fR to point to a single
-small data area. The \fB\-meabi\fR option is on by default if you
-configured \s-1GCC\s0 using one of the \fBpowerpc*\-*\-eabi*\fR options.
-.IP "\fB\-msdata=eabi\fR" 4
-.IX Item "-msdata=eabi"
-On System V.4 and embedded PowerPC systems, put small initialized
-\&\f(CW\*(C`const\*(C'\fR global and static data in the \fB.sdata2\fR section, which
-is pointed to by register \f(CW\*(C`r2\*(C'\fR. Put small initialized
-non\-\f(CW\*(C`const\*(C'\fR global and static data in the \fB.sdata\fR section,
-which is pointed to by register \f(CW\*(C`r13\*(C'\fR. Put small uninitialized
-global and static data in the \fB.sbss\fR section, which is adjacent to
-the \fB.sdata\fR section. The \fB\-msdata=eabi\fR option is
-incompatible with the \fB\-mrelocatable\fR option. The
-\&\fB\-msdata=eabi\fR option also sets the \fB\-memb\fR option.
-.IP "\fB\-msdata=sysv\fR" 4
-.IX Item "-msdata=sysv"
-On System V.4 and embedded PowerPC systems, put small global and static
-data in the \fB.sdata\fR section, which is pointed to by register
-\&\f(CW\*(C`r13\*(C'\fR. Put small uninitialized global and static data in the
-\&\fB.sbss\fR section, which is adjacent to the \fB.sdata\fR section.
-The \fB\-msdata=sysv\fR option is incompatible with the
-\&\fB\-mrelocatable\fR option.
-.IP "\fB\-msdata=default\fR" 4
-.IX Item "-msdata=default"
-.PD 0
-.IP "\fB\-msdata\fR" 4
-.IX Item "-msdata"
-.PD
-On System V.4 and embedded PowerPC systems, if \fB\-meabi\fR is used,
-compile code the same as \fB\-msdata=eabi\fR, otherwise compile code the
-same as \fB\-msdata=sysv\fR.
-.IP "\fB\-msdata=data\fR" 4
-.IX Item "-msdata=data"
-On System V.4 and embedded PowerPC systems, put small global
-data in the \fB.sdata\fR section. Put small uninitialized global
-data in the \fB.sbss\fR section. Do not use register \f(CW\*(C`r13\*(C'\fR
-to address small data however. This is the default behavior unless
-other \fB\-msdata\fR options are used.
-.IP "\fB\-msdata=none\fR" 4
-.IX Item "-msdata=none"
-.PD 0
-.IP "\fB\-mno\-sdata\fR" 4
-.IX Item "-mno-sdata"
-.PD
-On embedded PowerPC systems, put all initialized global and static data
-in the \fB.data\fR section, and all uninitialized data in the
-\&\fB.bss\fR section.
-.IP "\fB\-mblock\-move\-inline\-limit=\fR\fInum\fR" 4
-.IX Item "-mblock-move-inline-limit=num"
-Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure
-copies) less than or equal to \fInum\fR bytes. The minimum value for
-\&\fInum\fR is 32 bytes on 32\-bit targets and 64 bytes on 64\-bit
-targets. The default value is target-specific.
-.IP "\fB\-G\fR \fInum\fR" 4
-.IX Item "-G num"
-On embedded PowerPC systems, put global and static items less than or
-equal to \fInum\fR bytes into the small data or bss sections instead of
-the normal data or bss section. By default, \fInum\fR is 8. The
-\&\fB\-G\fR \fInum\fR switch is also passed to the linker.
-All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
-.IP "\fB\-mregnames\fR" 4
-.IX Item "-mregnames"
-.PD 0
-.IP "\fB\-mno\-regnames\fR" 4
-.IX Item "-mno-regnames"
-.PD
-On System V.4 and embedded PowerPC systems do (do not) emit register
-names in the assembly language output using symbolic forms.
-.IP "\fB\-mlongcall\fR" 4
-.IX Item "-mlongcall"
-.PD 0
-.IP "\fB\-mno\-longcall\fR" 4
-.IX Item "-mno-longcall"
-.PD
-By default assume that all calls are far away so that a longer more
-expensive calling sequence is required. This is required for calls
-further than 32 megabytes (33,554,432 bytes) from the current location.
-A short call will be generated if the compiler knows
-the call cannot be that far away. This setting can be overridden by
-the \f(CW\*(C`shortcall\*(C'\fR function attribute, or by \f(CW\*(C`#pragma
-longcall(0)\*(C'\fR.
-.Sp
-Some linkers are capable of detecting out-of-range calls and generating
-glue code on the fly. On these systems, long calls are unnecessary and
-generate slower code. As of this writing, the \s-1AIX\s0 linker can do this,
-as can the \s-1GNU\s0 linker for PowerPC/64. It is planned to add this feature
-to the \s-1GNU\s0 linker for 32\-bit PowerPC systems as well.
-.Sp
-On Darwin/PPC systems, \f(CW\*(C`#pragma longcall\*(C'\fR will generate \*(L"jbsr
-callee, L42\*(R", plus a \*(L"branch island\*(R" (glue code). The two target
-addresses represent the callee and the \*(L"branch island\*(R". The
-Darwin/PPC linker will prefer the first address and generate a \*(L"bl
-callee\*(R" if the \s-1PPC\s0 \*(L"bl\*(R" instruction will reach the callee directly;
-otherwise, the linker will generate \*(L"bl L42\*(R" to call the \*(L"branch
-island\*(R". The \*(L"branch island\*(R" is appended to the body of the
-calling function; it computes the full 32\-bit address of the callee
-and jumps to it.
-.Sp
-On Mach-O (Darwin) systems, this option directs the compiler emit to
-the glue for every direct call, and the Darwin linker decides whether
-to use or discard it.
-.Sp
-In the future, we may cause \s-1GCC\s0 to ignore all longcall specifications
-when the linker is known to generate glue.
-.IP "\fB\-mtls\-markers\fR" 4
-.IX Item "-mtls-markers"
-.PD 0
-.IP "\fB\-mno\-tls\-markers\fR" 4
-.IX Item "-mno-tls-markers"
-.PD
-Mark (do not mark) calls to \f(CW\*(C`_\|_tls_get_addr\*(C'\fR with a relocation
-specifying the function argument. The relocation allows ld to
-reliably associate function call with argument setup instructions for
-\&\s-1TLS\s0 optimization, which in turn allows gcc to better schedule the
-sequence.
-.IP "\fB\-pthread\fR" 4
-.IX Item "-pthread"
-Adds support for multithreading with the \fIpthreads\fR library.
-This option sets flags for both the preprocessor and linker.
-.IP "\fB\-mrecip\fR" 4
-.IX Item "-mrecip"
-.PD 0
-.IP "\fB\-mno\-recip\fR" 4
-.IX Item "-mno-recip"
-.PD
-This option will enable \s-1GCC\s0 to use the reciprocal estimate and
-reciprocal square root estimate instructions with additional
-Newton-Raphson steps to increase precision instead of doing a divide or
-square root and divide for floating point arguments. You should use
-the \fB\-ffast\-math\fR option when using \fB\-mrecip\fR (or at
-least \fB\-funsafe\-math\-optimizations\fR,
-\&\fB\-finite\-math\-only\fR, \fB\-freciprocal\-math\fR and
-\&\fB\-fno\-trapping\-math\fR). Note that while the throughput of the
-sequence is generally higher than the throughput of the non-reciprocal
-instruction, the precision of the sequence can be decreased by up to 2
-ulp (i.e. the inverse of 1.0 equals 0.99999994) for reciprocal square
-roots.
-.IP "\fB\-mrecip=\fR\fIopt\fR" 4
-.IX Item "-mrecip=opt"
-This option allows to control which reciprocal estimate instructions
-may be used. \fIopt\fR is a comma separated list of options, that may
-be preceded by a \f(CW\*(C`!\*(C'\fR to invert the option:
-\&\f(CW\*(C`all\*(C'\fR: enable all estimate instructions,
-\&\f(CW\*(C`default\*(C'\fR: enable the default instructions, equivalent to \fB\-mrecip\fR,
-\&\f(CW\*(C`none\*(C'\fR: disable all estimate instructions, equivalent to \fB\-mno\-recip\fR;
-\&\f(CW\*(C`div\*(C'\fR: enable the reciprocal approximation instructions for both single and double precision;
-\&\f(CW\*(C`divf\*(C'\fR: enable the single precision reciprocal approximation instructions;
-\&\f(CW\*(C`divd\*(C'\fR: enable the double precision reciprocal approximation instructions;
-\&\f(CW\*(C`rsqrt\*(C'\fR: enable the reciprocal square root approximation instructions for both single and double precision;
-\&\f(CW\*(C`rsqrtf\*(C'\fR: enable the single precision reciprocal square root approximation instructions;
-\&\f(CW\*(C`rsqrtd\*(C'\fR: enable the double precision reciprocal square root approximation instructions;
-.Sp
-So for example, \fB\-mrecip=all,!rsqrtd\fR would enable the
-all of the reciprocal estimate instructions, except for the
-\&\f(CW\*(C`FRSQRTE\*(C'\fR, \f(CW\*(C`XSRSQRTEDP\*(C'\fR, and \f(CW\*(C`XVRSQRTEDP\*(C'\fR instructions
-which handle the double precision reciprocal square root calculations.
-.IP "\fB\-mrecip\-precision\fR" 4
-.IX Item "-mrecip-precision"
-.PD 0
-.IP "\fB\-mno\-recip\-precision\fR" 4
-.IX Item "-mno-recip-precision"
-.PD
-Assume (do not assume) that the reciprocal estimate instructions
-provide higher precision estimates than is mandated by the powerpc
-\&\s-1ABI\s0. Selecting \fB\-mcpu=power6\fR or \fB\-mcpu=power7\fR
-automatically selects \fB\-mrecip\-precision\fR. The double
-precision square root estimate instructions are not generated by
-default on low precision machines, since they do not provide an
-estimate that converges after three steps.
-.IP "\fB\-mveclibabi=\fR\fItype\fR" 4
-.IX Item "-mveclibabi=type"
-Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
-external library. The only type supported at present is \f(CW\*(C`mass\*(C'\fR,
-which specifies to use \s-1IBM\s0's Mathematical Acceleration Subsystem
-(\s-1MASS\s0) libraries for vectorizing intrinsics using external libraries.
-\&\s-1GCC\s0 will currently emit calls to \f(CW\*(C`acosd2\*(C'\fR, \f(CW\*(C`acosf4\*(C'\fR,
-\&\f(CW\*(C`acoshd2\*(C'\fR, \f(CW\*(C`acoshf4\*(C'\fR, \f(CW\*(C`asind2\*(C'\fR, \f(CW\*(C`asinf4\*(C'\fR,
-\&\f(CW\*(C`asinhd2\*(C'\fR, \f(CW\*(C`asinhf4\*(C'\fR, \f(CW\*(C`atan2d2\*(C'\fR, \f(CW\*(C`atan2f4\*(C'\fR,
-\&\f(CW\*(C`atand2\*(C'\fR, \f(CW\*(C`atanf4\*(C'\fR, \f(CW\*(C`atanhd2\*(C'\fR, \f(CW\*(C`atanhf4\*(C'\fR,
-\&\f(CW\*(C`cbrtd2\*(C'\fR, \f(CW\*(C`cbrtf4\*(C'\fR, \f(CW\*(C`cosd2\*(C'\fR, \f(CW\*(C`cosf4\*(C'\fR,
-\&\f(CW\*(C`coshd2\*(C'\fR, \f(CW\*(C`coshf4\*(C'\fR, \f(CW\*(C`erfcd2\*(C'\fR, \f(CW\*(C`erfcf4\*(C'\fR,
-\&\f(CW\*(C`erfd2\*(C'\fR, \f(CW\*(C`erff4\*(C'\fR, \f(CW\*(C`exp2d2\*(C'\fR, \f(CW\*(C`exp2f4\*(C'\fR,
-\&\f(CW\*(C`expd2\*(C'\fR, \f(CW\*(C`expf4\*(C'\fR, \f(CW\*(C`expm1d2\*(C'\fR, \f(CW\*(C`expm1f4\*(C'\fR,
-\&\f(CW\*(C`hypotd2\*(C'\fR, \f(CW\*(C`hypotf4\*(C'\fR, \f(CW\*(C`lgammad2\*(C'\fR, \f(CW\*(C`lgammaf4\*(C'\fR,
-\&\f(CW\*(C`log10d2\*(C'\fR, \f(CW\*(C`log10f4\*(C'\fR, \f(CW\*(C`log1pd2\*(C'\fR, \f(CW\*(C`log1pf4\*(C'\fR,
-\&\f(CW\*(C`log2d2\*(C'\fR, \f(CW\*(C`log2f4\*(C'\fR, \f(CW\*(C`logd2\*(C'\fR, \f(CW\*(C`logf4\*(C'\fR,
-\&\f(CW\*(C`powd2\*(C'\fR, \f(CW\*(C`powf4\*(C'\fR, \f(CW\*(C`sind2\*(C'\fR, \f(CW\*(C`sinf4\*(C'\fR, \f(CW\*(C`sinhd2\*(C'\fR,
-\&\f(CW\*(C`sinhf4\*(C'\fR, \f(CW\*(C`sqrtd2\*(C'\fR, \f(CW\*(C`sqrtf4\*(C'\fR, \f(CW\*(C`tand2\*(C'\fR,
-\&\f(CW\*(C`tanf4\*(C'\fR, \f(CW\*(C`tanhd2\*(C'\fR, and \f(CW\*(C`tanhf4\*(C'\fR when generating code
-for power7. Both \fB\-ftree\-vectorize\fR and
-\&\fB\-funsafe\-math\-optimizations\fR have to be enabled. The \s-1MASS\s0
-libraries will have to be specified at link time.
-.IP "\fB\-mfriz\fR" 4
-.IX Item "-mfriz"
-.PD 0
-.IP "\fB\-mno\-friz\fR" 4
-.IX Item "-mno-friz"
-.PD
-Generate (do not generate) the \f(CW\*(C`friz\*(C'\fR instruction when the
-\&\fB\-funsafe\-math\-optimizations\fR option is used to optimize
-rounding a floating point value to 64\-bit integer and back to floating
-point. The \f(CW\*(C`friz\*(C'\fR instruction does not return the same value if
-the floating point number is too large to fit in an integer.
-.PP
-\fI\s-1RX\s0 Options\fR
-.IX Subsection "RX Options"
-.PP
-These command line options are defined for \s-1RX\s0 targets:
-.IP "\fB\-m64bit\-doubles\fR" 4
-.IX Item "-m64bit-doubles"
-.PD 0
-.IP "\fB\-m32bit\-doubles\fR" 4
-.IX Item "-m32bit-doubles"
-.PD
-Make the \f(CW\*(C`double\*(C'\fR data type be 64\-bits (\fB\-m64bit\-doubles\fR)
-or 32\-bits (\fB\-m32bit\-doubles\fR) in size. The default is
-\&\fB\-m32bit\-doubles\fR. \fINote\fR \s-1RX\s0 floating point hardware only
-works on 32\-bit values, which is why the default is
-\&\fB\-m32bit\-doubles\fR.
-.IP "\fB\-fpu\fR" 4
-.IX Item "-fpu"
-.PD 0
-.IP "\fB\-nofpu\fR" 4
-.IX Item "-nofpu"
-.PD
-Enables (\fB\-fpu\fR) or disables (\fB\-nofpu\fR) the use of \s-1RX\s0
-floating point hardware. The default is enabled for the \fI\s-1RX600\s0\fR
-series and disabled for the \fI\s-1RX200\s0\fR series.
-.Sp
-Floating point instructions will only be generated for 32\-bit floating
-point values however, so if the \fB\-m64bit\-doubles\fR option is in
-use then the \s-1FPU\s0 hardware will not be used for doubles.
-.Sp
-\&\fINote\fR If the \fB\-fpu\fR option is enabled then
-\&\fB\-funsafe\-math\-optimizations\fR is also enabled automatically.
-This is because the \s-1RX\s0 \s-1FPU\s0 instructions are themselves unsafe.
-.IP "\fB\-mcpu=\fR\fIname\fR" 4
-.IX Item "-mcpu=name"
-Selects the type of \s-1RX\s0 \s-1CPU\s0 to be targeted. Currently three types are
-supported, the generic \fI\s-1RX600\s0\fR and \fI\s-1RX200\s0\fR series hardware and
-the specific \fI\s-1RX610\s0\fR \s-1CPU\s0. The default is \fI\s-1RX600\s0\fR.
-.Sp
-The only difference between \fI\s-1RX600\s0\fR and \fI\s-1RX610\s0\fR is that the
-\&\fI\s-1RX610\s0\fR does not support the \f(CW\*(C`MVTIPL\*(C'\fR instruction.
-.Sp
-The \fI\s-1RX200\s0\fR series does not have a hardware floating point unit
-and so \fB\-nofpu\fR is enabled by default when this type is
-selected.
-.IP "\fB\-mbig\-endian\-data\fR" 4
-.IX Item "-mbig-endian-data"
-.PD 0
-.IP "\fB\-mlittle\-endian\-data\fR" 4
-.IX Item "-mlittle-endian-data"
-.PD
-Store data (but not code) in the big-endian format. The default is
-\&\fB\-mlittle\-endian\-data\fR, i.e. to store data in the little endian
-format.
-.IP "\fB\-msmall\-data\-limit=\fR\fIN\fR" 4
-.IX Item "-msmall-data-limit=N"
-Specifies the maximum size in bytes of global and static variables
-which can be placed into the small data area. Using the small data
-area can lead to smaller and faster code, but the size of area is
-limited and it is up to the programmer to ensure that the area does
-not overflow. Also when the small data area is used one of the \s-1RX\s0's
-registers (\f(CW\*(C`r13\*(C'\fR) is reserved for use pointing to this area, so
-it is no longer available for use by the compiler. This could result
-in slower and/or larger code if variables which once could have been
-held in \f(CW\*(C`r13\*(C'\fR are now pushed onto the stack.
-.Sp
-Note, common variables (variables which have not been initialised) and
-constants are not placed into the small data area as they are assigned
-to other sections in the output executable.
-.Sp
-The default value is zero, which disables this feature. Note, this
-feature is not enabled by default with higher optimization levels
-(\fB\-O2\fR etc) because of the potentially detrimental effects of
-reserving register \f(CW\*(C`r13\*(C'\fR. It is up to the programmer to
-experiment and discover whether this feature is of benefit to their
-program.
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-.PD 0
-.IP "\fB\-mno\-sim\fR" 4
-.IX Item "-mno-sim"
-.PD
-Use the simulator runtime. The default is to use the libgloss board
-specific runtime.
-.IP "\fB\-mas100\-syntax\fR" 4
-.IX Item "-mas100-syntax"
-.PD 0
-.IP "\fB\-mno\-as100\-syntax\fR" 4
-.IX Item "-mno-as100-syntax"
-.PD
-When generating assembler output use a syntax that is compatible with
-Renesas's \s-1AS100\s0 assembler. This syntax can also be handled by the \s-1GAS\s0
-assembler but it has some restrictions so generating it is not the
-default option.
-.IP "\fB\-mmax\-constant\-size=\fR\fIN\fR" 4
-.IX Item "-mmax-constant-size=N"
-Specifies the maximum size, in bytes, of a constant that can be used as
-an operand in a \s-1RX\s0 instruction. Although the \s-1RX\s0 instruction set does
-allow constants of up to 4 bytes in length to be used in instructions,
-a longer value equates to a longer instruction. Thus in some
-circumstances it can be beneficial to restrict the size of constants
-that are used in instructions. Constants that are too big are instead
-placed into a constant pool and referenced via register indirection.
-.Sp
-The value \fIN\fR can be between 0 and 4. A value of 0 (the default)
-or 4 means that constants of any size are allowed.
-.IP "\fB\-mrelax\fR" 4
-.IX Item "-mrelax"
-Enable linker relaxation. Linker relaxation is a process whereby the
-linker will attempt to reduce the size of a program by finding shorter
-versions of various instructions. Disabled by default.
-.IP "\fB\-mint\-register=\fR\fIN\fR" 4
-.IX Item "-mint-register=N"
-Specify the number of registers to reserve for fast interrupt handler
-functions. The value \fIN\fR can be between 0 and 4. A value of 1
-means that register \f(CW\*(C`r13\*(C'\fR will be reserved for the exclusive use
-of fast interrupt handlers. A value of 2 reserves \f(CW\*(C`r13\*(C'\fR and
-\&\f(CW\*(C`r12\*(C'\fR. A value of 3 reserves \f(CW\*(C`r13\*(C'\fR, \f(CW\*(C`r12\*(C'\fR and
-\&\f(CW\*(C`r11\*(C'\fR, and a value of 4 reserves \f(CW\*(C`r13\*(C'\fR through \f(CW\*(C`r10\*(C'\fR.
-A value of 0, the default, does not reserve any registers.
-.IP "\fB\-msave\-acc\-in\-interrupts\fR" 4
-.IX Item "-msave-acc-in-interrupts"
-Specifies that interrupt handler functions should preserve the
-accumulator register. This is only necessary if normal code might use
-the accumulator register, for example because it performs 64\-bit
-multiplications. The default is to ignore the accumulator as this
-makes the interrupt handlers faster.
-.PP
-\&\fINote:\fR The generic \s-1GCC\s0 command line \fB\-ffixed\-\fR\fIreg\fR
-has special significance to the \s-1RX\s0 port when used with the
-\&\f(CW\*(C`interrupt\*(C'\fR function attribute. This attribute indicates a
-function intended to process fast interrupts. \s-1GCC\s0 will will ensure
-that it only uses the registers \f(CW\*(C`r10\*(C'\fR, \f(CW\*(C`r11\*(C'\fR, \f(CW\*(C`r12\*(C'\fR
-and/or \f(CW\*(C`r13\*(C'\fR and only provided that the normal use of the
-corresponding registers have been restricted via the
-\&\fB\-ffixed\-\fR\fIreg\fR or \fB\-mint\-register\fR command line
-options.
-.PP
-\fIS/390 and zSeries Options\fR
-.IX Subsection "S/390 and zSeries Options"
-.PP
-These are the \fB\-m\fR options defined for the S/390 and zSeries architecture.
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-.PD 0
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-.PD
-Use (do not use) the hardware floating-point instructions and registers
-for floating-point operations. When \fB\-msoft\-float\fR is specified,
-functions in \fIlibgcc.a\fR will be used to perform floating-point
-operations. When \fB\-mhard\-float\fR is specified, the compiler
-generates \s-1IEEE\s0 floating-point instructions. This is the default.
-.IP "\fB\-mhard\-dfp\fR" 4
-.IX Item "-mhard-dfp"
-.PD 0
-.IP "\fB\-mno\-hard\-dfp\fR" 4
-.IX Item "-mno-hard-dfp"
-.PD
-Use (do not use) the hardware decimal-floating-point instructions for
-decimal-floating-point operations. When \fB\-mno\-hard\-dfp\fR is
-specified, functions in \fIlibgcc.a\fR will be used to perform
-decimal-floating-point operations. When \fB\-mhard\-dfp\fR is
-specified, the compiler generates decimal-floating-point hardware
-instructions. This is the default for \fB\-march=z9\-ec\fR or higher.
-.IP "\fB\-mlong\-double\-64\fR" 4
-.IX Item "-mlong-double-64"
-.PD 0
-.IP "\fB\-mlong\-double\-128\fR" 4
-.IX Item "-mlong-double-128"
-.PD
-These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
-of 64bit makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the \f(CW\*(C`double\*(C'\fR
-type. This is the default.
-.IP "\fB\-mbackchain\fR" 4
-.IX Item "-mbackchain"
-.PD 0
-.IP "\fB\-mno\-backchain\fR" 4
-.IX Item "-mno-backchain"
-.PD
-Store (do not store) the address of the caller's frame as backchain pointer
-into the callee's stack frame.
-A backchain may be needed to allow debugging using tools that do not understand
-\&\s-1DWARF\-2\s0 call frame information.
-When \fB\-mno\-packed\-stack\fR is in effect, the backchain pointer is stored
-at the bottom of the stack frame; when \fB\-mpacked\-stack\fR is in effect,
-the backchain is placed into the topmost word of the 96/160 byte register
-save area.
-.Sp
-In general, code compiled with \fB\-mbackchain\fR is call-compatible with
-code compiled with \fB\-mmo\-backchain\fR; however, use of the backchain
-for debugging purposes usually requires that the whole binary is built with
-\&\fB\-mbackchain\fR. Note that the combination of \fB\-mbackchain\fR,
-\&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported. In order
-to build a linux kernel use \fB\-msoft\-float\fR.
-.Sp
-The default is to not maintain the backchain.
-.IP "\fB\-mpacked\-stack\fR" 4
-.IX Item "-mpacked-stack"
-.PD 0
-.IP "\fB\-mno\-packed\-stack\fR" 4
-.IX Item "-mno-packed-stack"
-.PD
-Use (do not use) the packed stack layout. When \fB\-mno\-packed\-stack\fR is
-specified, the compiler uses the all fields of the 96/160 byte register save
-area only for their default purpose; unused fields still take up stack space.
-When \fB\-mpacked\-stack\fR is specified, register save slots are densely
-packed at the top of the register save area; unused space is reused for other
-purposes, allowing for more efficient use of the available stack space.
-However, when \fB\-mbackchain\fR is also in effect, the topmost word of
-the save area is always used to store the backchain, and the return address
-register is always saved two words below the backchain.
-.Sp
-As long as the stack frame backchain is not used, code generated with
-\&\fB\-mpacked\-stack\fR is call-compatible with code generated with
-\&\fB\-mno\-packed\-stack\fR. Note that some non-FSF releases of \s-1GCC\s0 2.95 for
-S/390 or zSeries generated code that uses the stack frame backchain at run
-time, not just for debugging purposes. Such code is not call-compatible
-with code compiled with \fB\-mpacked\-stack\fR. Also, note that the
-combination of \fB\-mbackchain\fR,
-\&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported. In order
-to build a linux kernel use \fB\-msoft\-float\fR.
-.Sp
-The default is to not use the packed stack layout.
-.IP "\fB\-msmall\-exec\fR" 4
-.IX Item "-msmall-exec"
-.PD 0
-.IP "\fB\-mno\-small\-exec\fR" 4
-.IX Item "-mno-small-exec"
-.PD
-Generate (or do not generate) code using the \f(CW\*(C`bras\*(C'\fR instruction
-to do subroutine calls.
-This only works reliably if the total executable size does not
-exceed 64k. The default is to use the \f(CW\*(C`basr\*(C'\fR instruction instead,
-which does not have this limitation.
-.IP "\fB\-m64\fR" 4
-.IX Item "-m64"
-.PD 0
-.IP "\fB\-m31\fR" 4
-.IX Item "-m31"
-.PD
-When \fB\-m31\fR is specified, generate code compliant to the
-GNU/Linux for S/390 \s-1ABI\s0. When \fB\-m64\fR is specified, generate
-code compliant to the GNU/Linux for zSeries \s-1ABI\s0. This allows \s-1GCC\s0 in
-particular to generate 64\-bit instructions. For the \fBs390\fR
-targets, the default is \fB\-m31\fR, while the \fBs390x\fR
-targets default to \fB\-m64\fR.
-.IP "\fB\-mzarch\fR" 4
-.IX Item "-mzarch"
-.PD 0
-.IP "\fB\-mesa\fR" 4
-.IX Item "-mesa"
-.PD
-When \fB\-mzarch\fR is specified, generate code using the
-instructions available on z/Architecture.
-When \fB\-mesa\fR is specified, generate code using the
-instructions available on \s-1ESA/390\s0. Note that \fB\-mesa\fR is
-not possible with \fB\-m64\fR.
-When generating code compliant to the GNU/Linux for S/390 \s-1ABI\s0,
-the default is \fB\-mesa\fR. When generating code compliant
-to the GNU/Linux for zSeries \s-1ABI\s0, the default is \fB\-mzarch\fR.
-.IP "\fB\-mmvcle\fR" 4
-.IX Item "-mmvcle"
-.PD 0
-.IP "\fB\-mno\-mvcle\fR" 4
-.IX Item "-mno-mvcle"
-.PD
-Generate (or do not generate) code using the \f(CW\*(C`mvcle\*(C'\fR instruction
-to perform block moves. When \fB\-mno\-mvcle\fR is specified,
-use a \f(CW\*(C`mvc\*(C'\fR loop instead. This is the default unless optimizing for
-size.
-.IP "\fB\-mdebug\fR" 4
-.IX Item "-mdebug"
-.PD 0
-.IP "\fB\-mno\-debug\fR" 4
-.IX Item "-mno-debug"
-.PD
-Print (or do not print) additional debug information when compiling.
-The default is to not print debug information.
-.IP "\fB\-march=\fR\fIcpu-type\fR" 4
-.IX Item "-march=cpu-type"
-Generate code that will run on \fIcpu-type\fR, which is the name of a system
-representing a certain processor type. Possible values for
-\&\fIcpu-type\fR are \fBg5\fR, \fBg6\fR, \fBz900\fR, \fBz990\fR,
-\&\fBz9\-109\fR, \fBz9\-ec\fR and \fBz10\fR.
-When generating code using the instructions available on z/Architecture,
-the default is \fB\-march=z900\fR. Otherwise, the default is
-\&\fB\-march=g5\fR.
-.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
-.IX Item "-mtune=cpu-type"
-Tune to \fIcpu-type\fR everything applicable about the generated code,
-except for the \s-1ABI\s0 and the set of available instructions.
-The list of \fIcpu-type\fR values is the same as for \fB\-march\fR.
-The default is the value used for \fB\-march\fR.
-.IP "\fB\-mtpf\-trace\fR" 4
-.IX Item "-mtpf-trace"
-.PD 0
-.IP "\fB\-mno\-tpf\-trace\fR" 4
-.IX Item "-mno-tpf-trace"
-.PD
-Generate code that adds (does not add) in \s-1TPF\s0 \s-1OS\s0 specific branches to trace
-routines in the operating system. This option is off by default, even
-when compiling for the \s-1TPF\s0 \s-1OS\s0.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Generate code that uses (does not use) the floating point multiply and
-accumulate instructions. These instructions are generated by default if
-hardware floating point is used.
-.IP "\fB\-mwarn\-framesize=\fR\fIframesize\fR" 4
-.IX Item "-mwarn-framesize=framesize"
-Emit a warning if the current function exceeds the given frame size. Because
-this is a compile time check it doesn't need to be a real problem when the program
-runs. It is intended to identify functions which most probably cause
-a stack overflow. It is useful to be used in an environment with limited stack
-size e.g. the linux kernel.
-.IP "\fB\-mwarn\-dynamicstack\fR" 4
-.IX Item "-mwarn-dynamicstack"
-Emit a warning if the function calls alloca or uses dynamically
-sized arrays. This is generally a bad idea with a limited stack size.
-.IP "\fB\-mstack\-guard=\fR\fIstack-guard\fR" 4
-.IX Item "-mstack-guard=stack-guard"
-.PD 0
-.IP "\fB\-mstack\-size=\fR\fIstack-size\fR" 4
-.IX Item "-mstack-size=stack-size"
-.PD
-If these options are provided the s390 back end emits additional instructions in
-the function prologue which trigger a trap if the stack size is \fIstack-guard\fR
-bytes above the \fIstack-size\fR (remember that the stack on s390 grows downward).
-If the \fIstack-guard\fR option is omitted the smallest power of 2 larger than
-the frame size of the compiled function is chosen.
-These options are intended to be used to help debugging stack overflow problems.
-The additionally emitted code causes only little overhead and hence can also be
-used in production like systems without greater performance degradation. The given
-values have to be exact powers of 2 and \fIstack-size\fR has to be greater than
-\&\fIstack-guard\fR without exceeding 64k.
-In order to be efficient the extra code makes the assumption that the stack starts
-at an address aligned to the value given by \fIstack-size\fR.
-The \fIstack-guard\fR option can only be used in conjunction with \fIstack-size\fR.
-.PP
-\fIScore Options\fR
-.IX Subsection "Score Options"
-.PP
-These options are defined for Score implementations:
-.IP "\fB\-meb\fR" 4
-.IX Item "-meb"
-Compile code for big endian mode. This is the default.
-.IP "\fB\-mel\fR" 4
-.IX Item "-mel"
-Compile code for little endian mode.
-.IP "\fB\-mnhwloop\fR" 4
-.IX Item "-mnhwloop"
-Disable generate bcnz instruction.
-.IP "\fB\-muls\fR" 4
-.IX Item "-muls"
-Enable generate unaligned load and store instruction.
-.IP "\fB\-mmac\fR" 4
-.IX Item "-mmac"
-Enable the use of multiply-accumulate instructions. Disabled by default.
-.IP "\fB\-mscore5\fR" 4
-.IX Item "-mscore5"
-Specify the \s-1SCORE5\s0 as the target architecture.
-.IP "\fB\-mscore5u\fR" 4
-.IX Item "-mscore5u"
-Specify the \s-1SCORE5U\s0 of the target architecture.
-.IP "\fB\-mscore7\fR" 4
-.IX Item "-mscore7"
-Specify the \s-1SCORE7\s0 as the target architecture. This is the default.
-.IP "\fB\-mscore7d\fR" 4
-.IX Item "-mscore7d"
-Specify the \s-1SCORE7D\s0 as the target architecture.
-.PP
-\fI\s-1SH\s0 Options\fR
-.IX Subsection "SH Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1SH\s0 implementations:
-.IP "\fB\-m1\fR" 4
-.IX Item "-m1"
-Generate code for the \s-1SH1\s0.
-.IP "\fB\-m2\fR" 4
-.IX Item "-m2"
-Generate code for the \s-1SH2\s0.
-.IP "\fB\-m2e\fR" 4
-.IX Item "-m2e"
-Generate code for the SH2e.
-.IP "\fB\-m2a\-nofpu\fR" 4
-.IX Item "-m2a-nofpu"
-Generate code for the SH2a without \s-1FPU\s0, or for a SH2a\-FPU in such a way
-that the floating-point unit is not used.
-.IP "\fB\-m2a\-single\-only\fR" 4
-.IX Item "-m2a-single-only"
-Generate code for the SH2a\-FPU, in such a way that no double-precision
-floating point operations are used.
-.IP "\fB\-m2a\-single\fR" 4
-.IX Item "-m2a-single"
-Generate code for the SH2a\-FPU assuming the floating-point unit is in
-single-precision mode by default.
-.IP "\fB\-m2a\fR" 4
-.IX Item "-m2a"
-Generate code for the SH2a\-FPU assuming the floating-point unit is in
-double-precision mode by default.
-.IP "\fB\-m3\fR" 4
-.IX Item "-m3"
-Generate code for the \s-1SH3\s0.
-.IP "\fB\-m3e\fR" 4
-.IX Item "-m3e"
-Generate code for the SH3e.
-.IP "\fB\-m4\-nofpu\fR" 4
-.IX Item "-m4-nofpu"
-Generate code for the \s-1SH4\s0 without a floating-point unit.
-.IP "\fB\-m4\-single\-only\fR" 4
-.IX Item "-m4-single-only"
-Generate code for the \s-1SH4\s0 with a floating-point unit that only
-supports single-precision arithmetic.
-.IP "\fB\-m4\-single\fR" 4
-.IX Item "-m4-single"
-Generate code for the \s-1SH4\s0 assuming the floating-point unit is in
-single-precision mode by default.
-.IP "\fB\-m4\fR" 4
-.IX Item "-m4"
-Generate code for the \s-1SH4\s0.
-.IP "\fB\-m4a\-nofpu\fR" 4
-.IX Item "-m4a-nofpu"
-Generate code for the SH4al\-dsp, or for a SH4a in such a way that the
-floating-point unit is not used.
-.IP "\fB\-m4a\-single\-only\fR" 4
-.IX Item "-m4a-single-only"
-Generate code for the SH4a, in such a way that no double-precision
-floating point operations are used.
-.IP "\fB\-m4a\-single\fR" 4
-.IX Item "-m4a-single"
-Generate code for the SH4a assuming the floating-point unit is in
-single-precision mode by default.
-.IP "\fB\-m4a\fR" 4
-.IX Item "-m4a"
-Generate code for the SH4a.
-.IP "\fB\-m4al\fR" 4
-.IX Item "-m4al"
-Same as \fB\-m4a\-nofpu\fR, except that it implicitly passes
-\&\fB\-dsp\fR to the assembler. \s-1GCC\s0 doesn't generate any \s-1DSP\s0
-instructions at the moment.
-.IP "\fB\-mb\fR" 4
-.IX Item "-mb"
-Compile code for the processor in big endian mode.
-.IP "\fB\-ml\fR" 4
-.IX Item "-ml"
-Compile code for the processor in little endian mode.
-.IP "\fB\-mdalign\fR" 4
-.IX Item "-mdalign"
-Align doubles at 64\-bit boundaries. Note that this changes the calling
-conventions, and thus some functions from the standard C library will
-not work unless you recompile it first with \fB\-mdalign\fR.
-.IP "\fB\-mrelax\fR" 4
-.IX Item "-mrelax"
-Shorten some address references at link time, when possible; uses the
-linker option \fB\-relax\fR.
-.IP "\fB\-mbigtable\fR" 4
-.IX Item "-mbigtable"
-Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables. The default is to use
-16\-bit offsets.
-.IP "\fB\-mbitops\fR" 4
-.IX Item "-mbitops"
-Enable the use of bit manipulation instructions on \s-1SH2A\s0.
-.IP "\fB\-mfmovd\fR" 4
-.IX Item "-mfmovd"
-Enable the use of the instruction \f(CW\*(C`fmovd\*(C'\fR. Check \fB\-mdalign\fR for
-alignment constraints.
-.IP "\fB\-mhitachi\fR" 4
-.IX Item "-mhitachi"
-Comply with the calling conventions defined by Renesas.
-.IP "\fB\-mrenesas\fR" 4
-.IX Item "-mrenesas"
-Comply with the calling conventions defined by Renesas.
-.IP "\fB\-mno\-renesas\fR" 4
-.IX Item "-mno-renesas"
-Comply with the calling conventions defined for \s-1GCC\s0 before the Renesas
-conventions were available. This option is the default for all
-targets of the \s-1SH\s0 toolchain except for \fBsh-symbianelf\fR.
-.IP "\fB\-mnomacsave\fR" 4
-.IX Item "-mnomacsave"
-Mark the \f(CW\*(C`MAC\*(C'\fR register as call-clobbered, even if
-\&\fB\-mhitachi\fR is given.
-.IP "\fB\-mieee\fR" 4
-.IX Item "-mieee"
-Increase IEEE-compliance of floating-point code.
-At the moment, this is equivalent to \fB\-fno\-finite\-math\-only\fR.
-When generating 16 bit \s-1SH\s0 opcodes, getting IEEE-conforming results for
-comparisons of NANs / infinities incurs extra overhead in every
-floating point comparison, therefore the default is set to
-\&\fB\-ffinite\-math\-only\fR.
-.IP "\fB\-minline\-ic_invalidate\fR" 4
-.IX Item "-minline-ic_invalidate"
-Inline code to invalidate instruction cache entries after setting up
-nested function trampolines.
-This option has no effect if \-musermode is in effect and the selected
-code generation option (e.g. \-m4) does not allow the use of the icbi
-instruction.
-If the selected code generation option does not allow the use of the icbi
-instruction, and \-musermode is not in effect, the inlined code will
-manipulate the instruction cache address array directly with an associative
-write. This not only requires privileged mode, but it will also
-fail if the cache line had been mapped via the \s-1TLB\s0 and has become unmapped.
-.IP "\fB\-misize\fR" 4
-.IX Item "-misize"
-Dump instruction size and location in the assembly code.
-.IP "\fB\-mpadstruct\fR" 4
-.IX Item "-mpadstruct"
-This option is deprecated. It pads structures to multiple of 4 bytes,
-which is incompatible with the \s-1SH\s0 \s-1ABI\s0.
-.IP "\fB\-mspace\fR" 4
-.IX Item "-mspace"
-Optimize for space instead of speed. Implied by \fB\-Os\fR.
-.IP "\fB\-mprefergot\fR" 4
-.IX Item "-mprefergot"
-When generating position-independent code, emit function calls using
-the Global Offset Table instead of the Procedure Linkage Table.
-.IP "\fB\-musermode\fR" 4
-.IX Item "-musermode"
-Don't generate privileged mode only code; implies \-mno\-inline\-ic_invalidate
-if the inlined code would not work in user mode.
-This is the default when the target is \f(CW\*(C`sh\-*\-linux*\*(C'\fR.
-.IP "\fB\-multcost=\fR\fInumber\fR" 4
-.IX Item "-multcost=number"
-Set the cost to assume for a multiply insn.
-.IP "\fB\-mdiv=\fR\fIstrategy\fR" 4
-.IX Item "-mdiv=strategy"
-Set the division strategy to use for SHmedia code. \fIstrategy\fR must be
-one of: call, call2, fp, inv, inv:minlat, inv20u, inv20l, inv:call,
-inv:call2, inv:fp .
-\&\*(L"fp\*(R" performs the operation in floating point. This has a very high latency,
-but needs only a few instructions, so it might be a good choice if
-your code has enough easily exploitable \s-1ILP\s0 to allow the compiler to
-schedule the floating point instructions together with other instructions.
-Division by zero causes a floating point exception.
-\&\*(L"inv\*(R" uses integer operations to calculate the inverse of the divisor,
-and then multiplies the dividend with the inverse. This strategy allows
-cse and hoisting of the inverse calculation. Division by zero calculates
-an unspecified result, but does not trap.
-\&\*(L"inv:minlat\*(R" is a variant of \*(L"inv\*(R" where if no cse / hoisting opportunities
-have been found, or if the entire operation has been hoisted to the same
-place, the last stages of the inverse calculation are intertwined with the
-final multiply to reduce the overall latency, at the expense of using a few
-more instructions, and thus offering fewer scheduling opportunities with
-other code.
-\&\*(L"call\*(R" calls a library function that usually implements the inv:minlat
-strategy.
-This gives high code density for m5\-*media\-nofpu compilations.
-\&\*(L"call2\*(R" uses a different entry point of the same library function, where it
-assumes that a pointer to a lookup table has already been set up, which
-exposes the pointer load to cse / code hoisting optimizations.
-\&\*(L"inv:call\*(R", \*(L"inv:call2\*(R" and \*(L"inv:fp\*(R" all use the \*(L"inv\*(R" algorithm for initial
-code generation, but if the code stays unoptimized, revert to the \*(L"call\*(R",
-\&\*(L"call2\*(R", or \*(L"fp\*(R" strategies, respectively. Note that the
-potentially-trapping side effect of division by zero is carried by a
-separate instruction, so it is possible that all the integer instructions
-are hoisted out, but the marker for the side effect stays where it is.
-A recombination to fp operations or a call is not possible in that case.
-\&\*(L"inv20u\*(R" and \*(L"inv20l\*(R" are variants of the \*(L"inv:minlat\*(R" strategy. In the case
-that the inverse calculation was nor separated from the multiply, they speed
-up division where the dividend fits into 20 bits (plus sign where applicable),
-by inserting a test to skip a number of operations in this case; this test
-slows down the case of larger dividends. inv20u assumes the case of a such
-a small dividend to be unlikely, and inv20l assumes it to be likely.
-.IP "\fB\-maccumulate\-outgoing\-args\fR" 4
-.IX Item "-maccumulate-outgoing-args"
-Reserve space once for outgoing arguments in the function prologue rather
-than around each call. Generally beneficial for performance and size. Also
-needed for unwinding to avoid changing the stack frame around conditional code.
-.IP "\fB\-mdivsi3_libfunc=\fR\fIname\fR" 4
-.IX Item "-mdivsi3_libfunc=name"
-Set the name of the library function used for 32 bit signed division to
-\&\fIname\fR. This only affect the name used in the call and inv:call
-division strategies, and the compiler will still expect the same
-sets of input/output/clobbered registers as if this option was not present.
-.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
-.IX Item "-mfixed-range=register-range"
-Generate code treating the given register range as fixed registers.
-A fixed register is one that the register allocator can not use. This is
-useful when compiling kernel code. A register range is specified as
-two registers separated by a dash. Multiple register ranges can be
-specified separated by a comma.
-.IP "\fB\-madjust\-unroll\fR" 4
-.IX Item "-madjust-unroll"
-Throttle unrolling to avoid thrashing target registers.
-This option only has an effect if the gcc code base supports the
-\&\s-1TARGET_ADJUST_UNROLL_MAX\s0 target hook.
-.IP "\fB\-mindexed\-addressing\fR" 4
-.IX Item "-mindexed-addressing"
-Enable the use of the indexed addressing mode for SHmedia32/SHcompact.
-This is only safe if the hardware and/or \s-1OS\s0 implement 32 bit wrap-around
-semantics for the indexed addressing mode. The architecture allows the
-implementation of processors with 64 bit \s-1MMU\s0, which the \s-1OS\s0 could use to
-get 32 bit addressing, but since no current hardware implementation supports
-this or any other way to make the indexed addressing mode safe to use in
-the 32 bit \s-1ABI\s0, the default is \-mno\-indexed\-addressing.
-.IP "\fB\-mgettrcost=\fR\fInumber\fR" 4
-.IX Item "-mgettrcost=number"
-Set the cost assumed for the gettr instruction to \fInumber\fR.
-The default is 2 if \fB\-mpt\-fixed\fR is in effect, 100 otherwise.
-.IP "\fB\-mpt\-fixed\fR" 4
-.IX Item "-mpt-fixed"
-Assume pt* instructions won't trap. This will generally generate better
-scheduled code, but is unsafe on current hardware. The current architecture
-definition says that ptabs and ptrel trap when the target anded with 3 is 3.
-This has the unintentional effect of making it unsafe to schedule ptabs /
-ptrel before a branch, or hoist it out of a loop. For example,
-_\|_do_global_ctors, a part of libgcc that runs constructors at program
-startup, calls functions in a list which is delimited by \-1. With the
-\&\-mpt\-fixed option, the ptabs will be done before testing against \-1.
-That means that all the constructors will be run a bit quicker, but when
-the loop comes to the end of the list, the program crashes because ptabs
-loads \-1 into a target register. Since this option is unsafe for any
-hardware implementing the current architecture specification, the default
-is \-mno\-pt\-fixed. Unless the user specifies a specific cost with
-\&\fB\-mgettrcost\fR, \-mno\-pt\-fixed also implies \fB\-mgettrcost=100\fR;
-this deters register allocation using target registers for storing
-ordinary integers.
-.IP "\fB\-minvalid\-symbols\fR" 4
-.IX Item "-minvalid-symbols"
-Assume symbols might be invalid. Ordinary function symbols generated by
-the compiler will always be valid to load with movi/shori/ptabs or
-movi/shori/ptrel, but with assembler and/or linker tricks it is possible
-to generate symbols that will cause ptabs / ptrel to trap.
-This option is only meaningful when \fB\-mno\-pt\-fixed\fR is in effect.
-It will then prevent cross-basic-block cse, hoisting and most scheduling
-of symbol loads. The default is \fB\-mno\-invalid\-symbols\fR.
-.PP
-\fISolaris 2 Options\fR
-.IX Subsection "Solaris 2 Options"
-.PP
-These \fB\-m\fR options are supported on Solaris 2:
-.IP "\fB\-mimpure\-text\fR" 4
-.IX Item "-mimpure-text"
-\&\fB\-mimpure\-text\fR, used in addition to \fB\-shared\fR, tells
-the compiler to not pass \fB\-z text\fR to the linker when linking a
-shared object. Using this option, you can link position-dependent
-code into a shared object.
-.Sp
-\&\fB\-mimpure\-text\fR suppresses the \*(L"relocations remain against
-allocatable but non-writable sections\*(R" linker error message.
-However, the necessary relocations will trigger copy-on-write, and the
-shared object is not actually shared across processes. Instead of
-using \fB\-mimpure\-text\fR, you should compile all source code with
-\&\fB\-fpic\fR or \fB\-fPIC\fR.
-.PP
-These switches are supported in addition to the above on Solaris 2:
-.IP "\fB\-threads\fR" 4
-.IX Item "-threads"
-Add support for multithreading using the Solaris threads library. This
-option sets flags for both the preprocessor and linker. This option does
-not affect the thread safety of object code produced by the compiler or
-that of libraries supplied with it.
-.IP "\fB\-pthreads\fR" 4
-.IX Item "-pthreads"
-Add support for multithreading using the \s-1POSIX\s0 threads library. This
-option sets flags for both the preprocessor and linker. This option does
-not affect the thread safety of object code produced by the compiler or
-that of libraries supplied with it.
-.IP "\fB\-pthread\fR" 4
-.IX Item "-pthread"
-This is a synonym for \fB\-pthreads\fR.
-.PP
-\fI\s-1SPARC\s0 Options\fR
-.IX Subsection "SPARC Options"
-.PP
-These \fB\-m\fR options are supported on the \s-1SPARC:\s0
-.IP "\fB\-mno\-app\-regs\fR" 4
-.IX Item "-mno-app-regs"
-.PD 0
-.IP "\fB\-mapp\-regs\fR" 4
-.IX Item "-mapp-regs"
-.PD
-Specify \fB\-mapp\-regs\fR to generate output using the global registers
-2 through 4, which the \s-1SPARC\s0 \s-1SVR4\s0 \s-1ABI\s0 reserves for applications. This
-is the default.
-.Sp
-To be fully \s-1SVR4\s0 \s-1ABI\s0 compliant at the cost of some performance loss,
-specify \fB\-mno\-app\-regs\fR. You should compile libraries and system
-software with this option.
-.IP "\fB\-mfpu\fR" 4
-.IX Item "-mfpu"
-.PD 0
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-.PD
-Generate output containing floating point instructions. This is the
-default.
-.IP "\fB\-mno\-fpu\fR" 4
-.IX Item "-mno-fpu"
-.PD 0
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-.PD
-Generate output containing library calls for floating point.
-\&\fBWarning:\fR the requisite libraries are not available for all \s-1SPARC\s0
-targets. Normally the facilities of the machine's usual C compiler are
-used, but this cannot be done directly in cross-compilation. You must make
-your own arrangements to provide suitable library functions for
-cross-compilation. The embedded targets \fBsparc\-*\-aout\fR and
-\&\fBsparclite\-*\-*\fR do provide software floating point support.
-.Sp
-\&\fB\-msoft\-float\fR changes the calling convention in the output file;
-therefore, it is only useful if you compile \fIall\fR of a program with
-this option. In particular, you need to compile \fIlibgcc.a\fR, the
-library that comes with \s-1GCC\s0, with \fB\-msoft\-float\fR in order for
-this to work.
-.IP "\fB\-mhard\-quad\-float\fR" 4
-.IX Item "-mhard-quad-float"
-Generate output containing quad-word (long double) floating point
-instructions.
-.IP "\fB\-msoft\-quad\-float\fR" 4
-.IX Item "-msoft-quad-float"
-Generate output containing library calls for quad-word (long double)
-floating point instructions. The functions called are those specified
-in the \s-1SPARC\s0 \s-1ABI\s0. This is the default.
-.Sp
-As of this writing, there are no \s-1SPARC\s0 implementations that have hardware
-support for the quad-word floating point instructions. They all invoke
-a trap handler for one of these instructions, and then the trap handler
-emulates the effect of the instruction. Because of the trap handler overhead,
-this is much slower than calling the \s-1ABI\s0 library routines. Thus the
-\&\fB\-msoft\-quad\-float\fR option is the default.
-.IP "\fB\-mno\-unaligned\-doubles\fR" 4
-.IX Item "-mno-unaligned-doubles"
-.PD 0
-.IP "\fB\-munaligned\-doubles\fR" 4
-.IX Item "-munaligned-doubles"
-.PD
-Assume that doubles have 8 byte alignment. This is the default.
-.Sp
-With \fB\-munaligned\-doubles\fR, \s-1GCC\s0 assumes that doubles have 8 byte
-alignment only if they are contained in another type, or if they have an
-absolute address. Otherwise, it assumes they have 4 byte alignment.
-Specifying this option avoids some rare compatibility problems with code
-generated by other compilers. It is not the default because it results
-in a performance loss, especially for floating point code.
-.IP "\fB\-mno\-faster\-structs\fR" 4
-.IX Item "-mno-faster-structs"
-.PD 0
-.IP "\fB\-mfaster\-structs\fR" 4
-.IX Item "-mfaster-structs"
-.PD
-With \fB\-mfaster\-structs\fR, the compiler assumes that structures
-should have 8 byte alignment. This enables the use of pairs of
-\&\f(CW\*(C`ldd\*(C'\fR and \f(CW\*(C`std\*(C'\fR instructions for copies in structure
-assignment, in place of twice as many \f(CW\*(C`ld\*(C'\fR and \f(CW\*(C`st\*(C'\fR pairs.
-However, the use of this changed alignment directly violates the \s-1SPARC\s0
-\&\s-1ABI\s0. Thus, it's intended only for use on targets where the developer
-acknowledges that their resulting code will not be directly in line with
-the rules of the \s-1ABI\s0.
-.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
-.IX Item "-mcpu=cpu_type"
-Set the instruction set, register set, and instruction scheduling parameters
-for machine type \fIcpu_type\fR. Supported values for \fIcpu_type\fR are
-\&\fBv7\fR, \fBcypress\fR, \fBv8\fR, \fBsupersparc\fR, \fBhypersparc\fR,
-\&\fBleon\fR, \fBsparclite\fR, \fBf930\fR, \fBf934\fR, \fBsparclite86x\fR,
-\&\fBsparclet\fR, \fBtsc701\fR, \fBv9\fR, \fBultrasparc\fR,
-\&\fBultrasparc3\fR, \fBniagara\fR and \fBniagara2\fR.
-.Sp
-Default instruction scheduling parameters are used for values that select
-an architecture and not an implementation. These are \fBv7\fR, \fBv8\fR,
-\&\fBsparclite\fR, \fBsparclet\fR, \fBv9\fR.
-.Sp
-Here is a list of each supported architecture and their supported
-implementations.
-.Sp
-.Vb 5
-\& v7: cypress
-\& v8: supersparc, hypersparc, leon
-\& sparclite: f930, f934, sparclite86x
-\& sparclet: tsc701
-\& v9: ultrasparc, ultrasparc3, niagara, niagara2
-.Ve
-.Sp
-By default (unless configured otherwise), \s-1GCC\s0 generates code for the V7
-variant of the \s-1SPARC\s0 architecture. With \fB\-mcpu=cypress\fR, the compiler
-additionally optimizes it for the Cypress \s-1CY7C602\s0 chip, as used in the
-SPARCStation/SPARCServer 3xx series. This is also appropriate for the older
-SPARCStation 1, 2, \s-1IPX\s0 etc.
-.Sp
-With \fB\-mcpu=v8\fR, \s-1GCC\s0 generates code for the V8 variant of the \s-1SPARC\s0
-architecture. The only difference from V7 code is that the compiler emits
-the integer multiply and integer divide instructions which exist in \s-1SPARC\-V8\s0
-but not in \s-1SPARC\-V7\s0. With \fB\-mcpu=supersparc\fR, the compiler additionally
-optimizes it for the SuperSPARC chip, as used in the SPARCStation 10, 1000 and
-2000 series.
-.Sp
-With \fB\-mcpu=sparclite\fR, \s-1GCC\s0 generates code for the SPARClite variant of
-the \s-1SPARC\s0 architecture. This adds the integer multiply, integer divide step
-and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClite but not in \s-1SPARC\-V7\s0.
-With \fB\-mcpu=f930\fR, the compiler additionally optimizes it for the
-Fujitsu \s-1MB86930\s0 chip, which is the original SPARClite, with no \s-1FPU\s0. With
-\&\fB\-mcpu=f934\fR, the compiler additionally optimizes it for the Fujitsu
-\&\s-1MB86934\s0 chip, which is the more recent SPARClite with \s-1FPU\s0.
-.Sp
-With \fB\-mcpu=sparclet\fR, \s-1GCC\s0 generates code for the SPARClet variant of
-the \s-1SPARC\s0 architecture. This adds the integer multiply, multiply/accumulate,
-integer divide step and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClet
-but not in \s-1SPARC\-V7\s0. With \fB\-mcpu=tsc701\fR, the compiler additionally
-optimizes it for the \s-1TEMIC\s0 SPARClet chip.
-.Sp
-With \fB\-mcpu=v9\fR, \s-1GCC\s0 generates code for the V9 variant of the \s-1SPARC\s0
-architecture. This adds 64\-bit integer and floating-point move instructions,
-3 additional floating-point condition code registers and conditional move
-instructions. With \fB\-mcpu=ultrasparc\fR, the compiler additionally
-optimizes it for the Sun UltraSPARC I/II/IIi chips. With
-\&\fB\-mcpu=ultrasparc3\fR, the compiler additionally optimizes it for the
-Sun UltraSPARC III/III+/IIIi/IIIi+/IV/IV+ chips. With
-\&\fB\-mcpu=niagara\fR, the compiler additionally optimizes it for
-Sun UltraSPARC T1 chips. With \fB\-mcpu=niagara2\fR, the compiler
-additionally optimizes it for Sun UltraSPARC T2 chips.
-.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
-.IX Item "-mtune=cpu_type"
-Set the instruction scheduling parameters for machine type
-\&\fIcpu_type\fR, but do not set the instruction set or register set that the
-option \fB\-mcpu=\fR\fIcpu_type\fR would.
-.Sp
-The same values for \fB\-mcpu=\fR\fIcpu_type\fR can be used for
-\&\fB\-mtune=\fR\fIcpu_type\fR, but the only useful values are those
-that select a particular \s-1CPU\s0 implementation. Those are \fBcypress\fR,
-\&\fBsupersparc\fR, \fBhypersparc\fR, \fBleon\fR, \fBf930\fR, \fBf934\fR,
-\&\fBsparclite86x\fR, \fBtsc701\fR, \fBultrasparc\fR, \fBultrasparc3\fR,
-\&\fBniagara\fR, and \fBniagara2\fR.
-.IP "\fB\-mv8plus\fR" 4
-.IX Item "-mv8plus"
-.PD 0
-.IP "\fB\-mno\-v8plus\fR" 4
-.IX Item "-mno-v8plus"
-.PD
-With \fB\-mv8plus\fR, \s-1GCC\s0 generates code for the \s-1SPARC\-V8+\s0 \s-1ABI\s0. The
-difference from the V8 \s-1ABI\s0 is that the global and out registers are
-considered 64\-bit wide. This is enabled by default on Solaris in 32\-bit
-mode for all \s-1SPARC\-V9\s0 processors.
-.IP "\fB\-mvis\fR" 4
-.IX Item "-mvis"
-.PD 0
-.IP "\fB\-mno\-vis\fR" 4
-.IX Item "-mno-vis"
-.PD
-With \fB\-mvis\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
-Visual Instruction Set extensions. The default is \fB\-mno\-vis\fR.
-.IP "\fB\-mfix\-at697f\fR" 4
-.IX Item "-mfix-at697f"
-Enable the documented workaround for the single erratum of the Atmel \s-1AT697F\s0
-processor (which corresponds to erratum #13 of the \s-1AT697E\s0 processor).
-.PP
-These \fB\-m\fR options are supported in addition to the above
-on \s-1SPARC\-V9\s0 processors in 64\-bit environments:
-.IP "\fB\-mlittle\-endian\fR" 4
-.IX Item "-mlittle-endian"
-Generate code for a processor running in little-endian mode. It is only
-available for a few configurations and most notably not on Solaris and Linux.
-.IP "\fB\-m32\fR" 4
-.IX Item "-m32"
-.PD 0
-.IP "\fB\-m64\fR" 4
-.IX Item "-m64"
-.PD
-Generate code for a 32\-bit or 64\-bit environment.
-The 32\-bit environment sets int, long and pointer to 32 bits.
-The 64\-bit environment sets int to 32 bits and long and pointer
-to 64 bits.
-.IP "\fB\-mcmodel=medlow\fR" 4
-.IX Item "-mcmodel=medlow"
-Generate code for the Medium/Low code model: 64\-bit addresses, programs
-must be linked in the low 32 bits of memory. Programs can be statically
-or dynamically linked.
-.IP "\fB\-mcmodel=medmid\fR" 4
-.IX Item "-mcmodel=medmid"
-Generate code for the Medium/Middle code model: 64\-bit addresses, programs
-must be linked in the low 44 bits of memory, the text and data segments must
-be less than 2GB in size and the data segment must be located within 2GB of
-the text segment.
-.IP "\fB\-mcmodel=medany\fR" 4
-.IX Item "-mcmodel=medany"
-Generate code for the Medium/Anywhere code model: 64\-bit addresses, programs
-may be linked anywhere in memory, the text and data segments must be less
-than 2GB in size and the data segment must be located within 2GB of the
-text segment.
-.IP "\fB\-mcmodel=embmedany\fR" 4
-.IX Item "-mcmodel=embmedany"
-Generate code for the Medium/Anywhere code model for embedded systems:
-64\-bit addresses, the text and data segments must be less than 2GB in
-size, both starting anywhere in memory (determined at link time). The
-global register \f(CW%g4\fR points to the base of the data segment. Programs
-are statically linked and \s-1PIC\s0 is not supported.
-.IP "\fB\-mstack\-bias\fR" 4
-.IX Item "-mstack-bias"
-.PD 0
-.IP "\fB\-mno\-stack\-bias\fR" 4
-.IX Item "-mno-stack-bias"
-.PD
-With \fB\-mstack\-bias\fR, \s-1GCC\s0 assumes that the stack pointer, and
-frame pointer if present, are offset by \-2047 which must be added back
-when making stack frame references. This is the default in 64\-bit mode.
-Otherwise, assume no such offset is present.
-.PP
-\fI\s-1SPU\s0 Options\fR
-.IX Subsection "SPU Options"
-.PP
-These \fB\-m\fR options are supported on the \s-1SPU:\s0
-.IP "\fB\-mwarn\-reloc\fR" 4
-.IX Item "-mwarn-reloc"
-.PD 0
-.IP "\fB\-merror\-reloc\fR" 4
-.IX Item "-merror-reloc"
-.PD
-The loader for \s-1SPU\s0 does not handle dynamic relocations. By default, \s-1GCC\s0
-will give an error when it generates code that requires a dynamic
-relocation. \fB\-mno\-error\-reloc\fR disables the error,
-\&\fB\-mwarn\-reloc\fR will generate a warning instead.
-.IP "\fB\-msafe\-dma\fR" 4
-.IX Item "-msafe-dma"
-.PD 0
-.IP "\fB\-munsafe\-dma\fR" 4
-.IX Item "-munsafe-dma"
-.PD
-Instructions which initiate or test completion of \s-1DMA\s0 must not be
-reordered with respect to loads and stores of the memory which is being
-accessed. Users typically address this problem using the volatile
-keyword, but that can lead to inefficient code in places where the
-memory is known to not change. Rather than mark the memory as volatile
-we treat the \s-1DMA\s0 instructions as potentially effecting all memory. With
-\&\fB\-munsafe\-dma\fR users must use the volatile keyword to protect
-memory accesses.
-.IP "\fB\-mbranch\-hints\fR" 4
-.IX Item "-mbranch-hints"
-By default, \s-1GCC\s0 will generate a branch hint instruction to avoid
-pipeline stalls for always taken or probably taken branches. A hint
-will not be generated closer than 8 instructions away from its branch.
-There is little reason to disable them, except for debugging purposes,
-or to make an object a little bit smaller.
-.IP "\fB\-msmall\-mem\fR" 4
-.IX Item "-msmall-mem"
-.PD 0
-.IP "\fB\-mlarge\-mem\fR" 4
-.IX Item "-mlarge-mem"
-.PD
-By default, \s-1GCC\s0 generates code assuming that addresses are never larger
-than 18 bits. With \fB\-mlarge\-mem\fR code is generated that assumes
-a full 32 bit address.
-.IP "\fB\-mstdmain\fR" 4
-.IX Item "-mstdmain"
-By default, \s-1GCC\s0 links against startup code that assumes the SPU-style
-main function interface (which has an unconventional parameter list).
-With \fB\-mstdmain\fR, \s-1GCC\s0 will link your program against startup
-code that assumes a C99\-style interface to \f(CW\*(C`main\*(C'\fR, including a
-local copy of \f(CW\*(C`argv\*(C'\fR strings.
-.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
-.IX Item "-mfixed-range=register-range"
-Generate code treating the given register range as fixed registers.
-A fixed register is one that the register allocator can not use. This is
-useful when compiling kernel code. A register range is specified as
-two registers separated by a dash. Multiple register ranges can be
-specified separated by a comma.
-.IP "\fB\-mea32\fR" 4
-.IX Item "-mea32"
-.PD 0
-.IP "\fB\-mea64\fR" 4
-.IX Item "-mea64"
-.PD
-Compile code assuming that pointers to the \s-1PPU\s0 address space accessed
-via the \f(CW\*(C`_\|_ea\*(C'\fR named address space qualifier are either 32 or 64
-bits wide. The default is 32 bits. As this is an \s-1ABI\s0 changing option,
-all object code in an executable must be compiled with the same setting.
-.IP "\fB\-maddress\-space\-conversion\fR" 4
-.IX Item "-maddress-space-conversion"
-.PD 0
-.IP "\fB\-mno\-address\-space\-conversion\fR" 4
-.IX Item "-mno-address-space-conversion"
-.PD
-Allow/disallow treating the \f(CW\*(C`_\|_ea\*(C'\fR address space as superset
-of the generic address space. This enables explicit type casts
-between \f(CW\*(C`_\|_ea\*(C'\fR and generic pointer as well as implicit
-conversions of generic pointers to \f(CW\*(C`_\|_ea\*(C'\fR pointers. The
-default is to allow address space pointer conversions.
-.IP "\fB\-mcache\-size=\fR\fIcache-size\fR" 4
-.IX Item "-mcache-size=cache-size"
-This option controls the version of libgcc that the compiler links to an
-executable and selects a software-managed cache for accessing variables
-in the \f(CW\*(C`_\|_ea\*(C'\fR address space with a particular cache size. Possible
-options for \fIcache-size\fR are \fB8\fR, \fB16\fR, \fB32\fR, \fB64\fR
-and \fB128\fR. The default cache size is 64KB.
-.IP "\fB\-matomic\-updates\fR" 4
-.IX Item "-matomic-updates"
-.PD 0
-.IP "\fB\-mno\-atomic\-updates\fR" 4
-.IX Item "-mno-atomic-updates"
-.PD
-This option controls the version of libgcc that the compiler links to an
-executable and selects whether atomic updates to the software-managed
-cache of PPU-side variables are used. If you use atomic updates, changes
-to a \s-1PPU\s0 variable from \s-1SPU\s0 code using the \f(CW\*(C`_\|_ea\*(C'\fR named address space
-qualifier will not interfere with changes to other \s-1PPU\s0 variables residing
-in the same cache line from \s-1PPU\s0 code. If you do not use atomic updates,
-such interference may occur; however, writing back cache lines will be
-more efficient. The default behavior is to use atomic updates.
-.IP "\fB\-mdual\-nops\fR" 4
-.IX Item "-mdual-nops"
-.PD 0
-.IP "\fB\-mdual\-nops=\fR\fIn\fR" 4
-.IX Item "-mdual-nops=n"
-.PD
-By default, \s-1GCC\s0 will insert nops to increase dual issue when it expects
-it to increase performance. \fIn\fR can be a value from 0 to 10. A
-smaller \fIn\fR will insert fewer nops. 10 is the default, 0 is the
-same as \fB\-mno\-dual\-nops\fR. Disabled with \fB\-Os\fR.
-.IP "\fB\-mhint\-max\-nops=\fR\fIn\fR" 4
-.IX Item "-mhint-max-nops=n"
-Maximum number of nops to insert for a branch hint. A branch hint must
-be at least 8 instructions away from the branch it is effecting. \s-1GCC\s0
-will insert up to \fIn\fR nops to enforce this, otherwise it will not
-generate the branch hint.
-.IP "\fB\-mhint\-max\-distance=\fR\fIn\fR" 4
-.IX Item "-mhint-max-distance=n"
-The encoding of the branch hint instruction limits the hint to be within
-256 instructions of the branch it is effecting. By default, \s-1GCC\s0 makes
-sure it is within 125.
-.IP "\fB\-msafe\-hints\fR" 4
-.IX Item "-msafe-hints"
-Work around a hardware bug which causes the \s-1SPU\s0 to stall indefinitely.
-By default, \s-1GCC\s0 will insert the \f(CW\*(C`hbrp\*(C'\fR instruction to make sure
-this stall won't happen.
-.PP
-\fIOptions for System V\fR
-.IX Subsection "Options for System V"
-.PP
-These additional options are available on System V Release 4 for
-compatibility with other compilers on those systems:
-.IP "\fB\-G\fR" 4
-.IX Item "-G"
-Create a shared object.
-It is recommended that \fB\-symbolic\fR or \fB\-shared\fR be used instead.
-.IP "\fB\-Qy\fR" 4
-.IX Item "-Qy"
-Identify the versions of each tool used by the compiler, in a
-\&\f(CW\*(C`.ident\*(C'\fR assembler directive in the output.
-.IP "\fB\-Qn\fR" 4
-.IX Item "-Qn"
-Refrain from adding \f(CW\*(C`.ident\*(C'\fR directives to the output file (this is
-the default).
-.IP "\fB\-YP,\fR\fIdirs\fR" 4
-.IX Item "-YP,dirs"
-Search the directories \fIdirs\fR, and no others, for libraries
-specified with \fB\-l\fR.
-.IP "\fB\-Ym,\fR\fIdir\fR" 4
-.IX Item "-Ym,dir"
-Look in the directory \fIdir\fR to find the M4 preprocessor.
-The assembler uses this option.
-.PP
-\fIV850 Options\fR
-.IX Subsection "V850 Options"
-.PP
-These \fB\-m\fR options are defined for V850 implementations:
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-.PD 0
-.IP "\fB\-mno\-long\-calls\fR" 4
-.IX Item "-mno-long-calls"
-.PD
-Treat all calls as being far away (near). If calls are assumed to be
-far away, the compiler will always load the functions address up into a
-register, and call indirect through the pointer.
-.IP "\fB\-mno\-ep\fR" 4
-.IX Item "-mno-ep"
-.PD 0
-.IP "\fB\-mep\fR" 4
-.IX Item "-mep"
-.PD
-Do not optimize (do optimize) basic blocks that use the same index
-pointer 4 or more times to copy pointer into the \f(CW\*(C`ep\*(C'\fR register, and
-use the shorter \f(CW\*(C`sld\*(C'\fR and \f(CW\*(C`sst\*(C'\fR instructions. The \fB\-mep\fR
-option is on by default if you optimize.
-.IP "\fB\-mno\-prolog\-function\fR" 4
-.IX Item "-mno-prolog-function"
-.PD 0
-.IP "\fB\-mprolog\-function\fR" 4
-.IX Item "-mprolog-function"
-.PD
-Do not use (do use) external functions to save and restore registers
-at the prologue and epilogue of a function. The external functions
-are slower, but use less code space if more than one function saves
-the same number of registers. The \fB\-mprolog\-function\fR option
-is on by default if you optimize.
-.IP "\fB\-mspace\fR" 4
-.IX Item "-mspace"
-Try to make the code as small as possible. At present, this just turns
-on the \fB\-mep\fR and \fB\-mprolog\-function\fR options.
-.IP "\fB\-mtda=\fR\fIn\fR" 4
-.IX Item "-mtda=n"
-Put static or global variables whose size is \fIn\fR bytes or less into
-the tiny data area that register \f(CW\*(C`ep\*(C'\fR points to. The tiny data
-area can hold up to 256 bytes in total (128 bytes for byte references).
-.IP "\fB\-msda=\fR\fIn\fR" 4
-.IX Item "-msda=n"
-Put static or global variables whose size is \fIn\fR bytes or less into
-the small data area that register \f(CW\*(C`gp\*(C'\fR points to. The small data
-area can hold up to 64 kilobytes.
-.IP "\fB\-mzda=\fR\fIn\fR" 4
-.IX Item "-mzda=n"
-Put static or global variables whose size is \fIn\fR bytes or less into
-the first 32 kilobytes of memory.
-.IP "\fB\-mv850\fR" 4
-.IX Item "-mv850"
-Specify that the target processor is the V850.
-.IP "\fB\-mbig\-switch\fR" 4
-.IX Item "-mbig-switch"
-Generate code suitable for big switch tables. Use this option only if
-the assembler/linker complain about out of range branches within a switch
-table.
-.IP "\fB\-mapp\-regs\fR" 4
-.IX Item "-mapp-regs"
-This option will cause r2 and r5 to be used in the code generated by
-the compiler. This setting is the default.
-.IP "\fB\-mno\-app\-regs\fR" 4
-.IX Item "-mno-app-regs"
-This option will cause r2 and r5 to be treated as fixed registers.
-.IP "\fB\-mv850e2v3\fR" 4
-.IX Item "-mv850e2v3"
-Specify that the target processor is the V850E2V3. The preprocessor
-constants \fB_\|_v850e2v3_\|_\fR will be defined if
-this option is used.
-.IP "\fB\-mv850e2\fR" 4
-.IX Item "-mv850e2"
-Specify that the target processor is the V850E2. The preprocessor
-constants \fB_\|_v850e2_\|_\fR will be defined if
-.IP "\fB\-mv850e1\fR" 4
-.IX Item "-mv850e1"
-Specify that the target processor is the V850E1. The preprocessor
-constants \fB_\|_v850e1_\|_\fR and \fB_\|_v850e_\|_\fR will be defined if
-.IP "\fB\-mv850es\fR" 4
-.IX Item "-mv850es"
-Specify that the target processor is the V850ES. This is an alias for
-the \fB\-mv850e1\fR option.
-.IP "\fB\-mv850e\fR" 4
-.IX Item "-mv850e"
-Specify that the target processor is the V850E. The preprocessor
-constant \fB_\|_v850e_\|_\fR will be defined if this option is used.
-.Sp
-If neither \fB\-mv850\fR nor \fB\-mv850e\fR nor \fB\-mv850e1\fR
-nor \fB\-mv850e2\fR nor \fB\-mv850e2v3\fR
-are defined then a default target processor will be chosen and the
-relevant \fB_\|_v850*_\|_\fR preprocessor constant will be defined.
-.Sp
-The preprocessor constants \fB_\|_v850\fR and \fB_\|_v851_\|_\fR are always
-defined, regardless of which processor variant is the target.
-.IP "\fB\-mdisable\-callt\fR" 4
-.IX Item "-mdisable-callt"
-This option will suppress generation of the \s-1CALLT\s0 instruction for the
-v850e, v850e1, v850e2 and v850e2v3 flavors of the v850 architecture. The default is
-\&\fB\-mno\-disable\-callt\fR which allows the \s-1CALLT\s0 instruction to be used.
-.PP
-\fI\s-1VAX\s0 Options\fR
-.IX Subsection "VAX Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1VAX:\s0
-.IP "\fB\-munix\fR" 4
-.IX Item "-munix"
-Do not output certain jump instructions (\f(CW\*(C`aobleq\*(C'\fR and so on)
-that the Unix assembler for the \s-1VAX\s0 cannot handle across long
-ranges.
-.IP "\fB\-mgnu\fR" 4
-.IX Item "-mgnu"
-Do output those jump instructions, on the assumption that you
-will assemble with the \s-1GNU\s0 assembler.
-.IP "\fB\-mg\fR" 4
-.IX Item "-mg"
-Output code for g\-format floating point numbers instead of d\-format.
-.PP
-\fIVxWorks Options\fR
-.IX Subsection "VxWorks Options"
-.PP
-The options in this section are defined for all VxWorks targets.
-Options specific to the target hardware are listed with the other
-options for that target.
-.IP "\fB\-mrtp\fR" 4
-.IX Item "-mrtp"
-\&\s-1GCC\s0 can generate code for both VxWorks kernels and real time processes
-(RTPs). This option switches from the former to the latter. It also
-defines the preprocessor macro \f(CW\*(C`_\|_RTP_\|_\*(C'\fR.
-.IP "\fB\-non\-static\fR" 4
-.IX Item "-non-static"
-Link an \s-1RTP\s0 executable against shared libraries rather than static
-libraries. The options \fB\-static\fR and \fB\-shared\fR can
-also be used for RTPs; \fB\-static\fR
-is the default.
-.IP "\fB\-Bstatic\fR" 4
-.IX Item "-Bstatic"
-.PD 0
-.IP "\fB\-Bdynamic\fR" 4
-.IX Item "-Bdynamic"
-.PD
-These options are passed down to the linker. They are defined for
-compatibility with Diab.
-.IP "\fB\-Xbind\-lazy\fR" 4
-.IX Item "-Xbind-lazy"
-Enable lazy binding of function calls. This option is equivalent to
-\&\fB\-Wl,\-z,now\fR and is defined for compatibility with Diab.
-.IP "\fB\-Xbind\-now\fR" 4
-.IX Item "-Xbind-now"
-Disable lazy binding of function calls. This option is the default and
-is defined for compatibility with Diab.
-.PP
-\fIx86\-64 Options\fR
-.IX Subsection "x86-64 Options"
-.PP
-These are listed under
-.PP
-\fIXstormy16 Options\fR
-.IX Subsection "Xstormy16 Options"
-.PP
-These options are defined for Xstormy16:
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-Choose startup files and linker script suitable for the simulator.
-.PP
-\fIXtensa Options\fR
-.IX Subsection "Xtensa Options"
-.PP
-These options are supported for Xtensa targets:
-.IP "\fB\-mconst16\fR" 4
-.IX Item "-mconst16"
-.PD 0
-.IP "\fB\-mno\-const16\fR" 4
-.IX Item "-mno-const16"
-.PD
-Enable or disable use of \f(CW\*(C`CONST16\*(C'\fR instructions for loading
-constant values. The \f(CW\*(C`CONST16\*(C'\fR instruction is currently not a
-standard option from Tensilica. When enabled, \f(CW\*(C`CONST16\*(C'\fR
-instructions are always used in place of the standard \f(CW\*(C`L32R\*(C'\fR
-instructions. The use of \f(CW\*(C`CONST16\*(C'\fR is enabled by default only if
-the \f(CW\*(C`L32R\*(C'\fR instruction is not available.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Enable or disable use of fused multiply/add and multiply/subtract
-instructions in the floating-point option. This has no effect if the
-floating-point option is not also enabled. Disabling fused multiply/add
-and multiply/subtract instructions forces the compiler to use separate
-instructions for the multiply and add/subtract operations. This may be
-desirable in some cases where strict \s-1IEEE\s0 754\-compliant results are
-required: the fused multiply add/subtract instructions do not round the
-intermediate result, thereby producing results with \fImore\fR bits of
-precision than specified by the \s-1IEEE\s0 standard. Disabling fused multiply
-add/subtract instructions also ensures that the program output is not
-sensitive to the compiler's ability to combine multiply and add/subtract
-operations.
-.IP "\fB\-mserialize\-volatile\fR" 4
-.IX Item "-mserialize-volatile"
-.PD 0
-.IP "\fB\-mno\-serialize\-volatile\fR" 4
-.IX Item "-mno-serialize-volatile"
-.PD
-When this option is enabled, \s-1GCC\s0 inserts \f(CW\*(C`MEMW\*(C'\fR instructions before
-\&\f(CW\*(C`volatile\*(C'\fR memory references to guarantee sequential consistency.
-The default is \fB\-mserialize\-volatile\fR. Use
-\&\fB\-mno\-serialize\-volatile\fR to omit the \f(CW\*(C`MEMW\*(C'\fR instructions.
-.IP "\fB\-mforce\-no\-pic\fR" 4
-.IX Item "-mforce-no-pic"
-For targets, like GNU/Linux, where all user-mode Xtensa code must be
-position-independent code (\s-1PIC\s0), this option disables \s-1PIC\s0 for compiling
-kernel code.
-.IP "\fB\-mtext\-section\-literals\fR" 4
-.IX Item "-mtext-section-literals"
-.PD 0
-.IP "\fB\-mno\-text\-section\-literals\fR" 4
-.IX Item "-mno-text-section-literals"
-.PD
-Control the treatment of literal pools. The default is
-\&\fB\-mno\-text\-section\-literals\fR, which places literals in a separate
-section in the output file. This allows the literal pool to be placed
-in a data \s-1RAM/ROM\s0, and it also allows the linker to combine literal
-pools from separate object files to remove redundant literals and
-improve code size. With \fB\-mtext\-section\-literals\fR, the literals
-are interspersed in the text section in order to keep them as close as
-possible to their references. This may be necessary for large assembly
-files.
-.IP "\fB\-mtarget\-align\fR" 4
-.IX Item "-mtarget-align"
-.PD 0
-.IP "\fB\-mno\-target\-align\fR" 4
-.IX Item "-mno-target-align"
-.PD
-When this option is enabled, \s-1GCC\s0 instructs the assembler to
-automatically align instructions to reduce branch penalties at the
-expense of some code density. The assembler attempts to widen density
-instructions to align branch targets and the instructions following call
-instructions. If there are not enough preceding safe density
-instructions to align a target, no widening will be performed. The
-default is \fB\-mtarget\-align\fR. These options do not affect the
-treatment of auto-aligned instructions like \f(CW\*(C`LOOP\*(C'\fR, which the
-assembler will always align, either by widening density instructions or
-by inserting no-op instructions.
-.IP "\fB\-mlongcalls\fR" 4
-.IX Item "-mlongcalls"
-.PD 0
-.IP "\fB\-mno\-longcalls\fR" 4
-.IX Item "-mno-longcalls"
-.PD
-When this option is enabled, \s-1GCC\s0 instructs the assembler to translate
-direct calls to indirect calls unless it can determine that the target
-of a direct call is in the range allowed by the call instruction. This
-translation typically occurs for calls to functions in other source
-files. Specifically, the assembler translates a direct \f(CW\*(C`CALL\*(C'\fR
-instruction into an \f(CW\*(C`L32R\*(C'\fR followed by a \f(CW\*(C`CALLX\*(C'\fR instruction.
-The default is \fB\-mno\-longcalls\fR. This option should be used in
-programs where the call target can potentially be out of range. This
-option is implemented in the assembler, not the compiler, so the
-assembly code generated by \s-1GCC\s0 will still show direct call
-instructions\-\-\-look at the disassembled object code to see the actual
-instructions. Note that the assembler will use an indirect call for
-every cross-file call, not just those that really will be out of range.
-.PP
-\fIzSeries Options\fR
-.IX Subsection "zSeries Options"
-.PP
-These are listed under
-.SS "Options for Code Generation Conventions"
-.IX Subsection "Options for Code Generation Conventions"
-These machine-independent options control the interface conventions
-used in code generation.
-.PP
-Most of them have both positive and negative forms; the negative form
-of \fB\-ffoo\fR would be \fB\-fno\-foo\fR. In the table below, only
-one of the forms is listed\-\-\-the one which is not the default. You
-can figure out the other form by either removing \fBno\-\fR or adding
-it.
-.IP "\fB\-fbounds\-check\fR" 4
-.IX Item "-fbounds-check"
-For front-ends that support it, generate additional code to check that
-indices used to access arrays are within the declared range. This is
-currently only supported by the Java and Fortran front-ends, where
-this option defaults to true and false respectively.
-.IP "\fB\-ftrapv\fR" 4
-.IX Item "-ftrapv"
-This option generates traps for signed overflow on addition, subtraction,
-multiplication operations.
-.IP "\fB\-fwrapv\fR" 4
-.IX Item "-fwrapv"
-This option instructs the compiler to assume that signed arithmetic
-overflow of addition, subtraction and multiplication wraps around
-using twos-complement representation. This flag enables some optimizations
-and disables others. This option is enabled by default for the Java
-front-end, as required by the Java language specification.
-.IP "\fB\-fexceptions\fR" 4
-.IX Item "-fexceptions"
-Enable exception handling. Generates extra code needed to propagate
-exceptions. For some targets, this implies \s-1GCC\s0 will generate frame
-unwind information for all functions, which can produce significant data
-size overhead, although it does not affect execution. If you do not
-specify this option, \s-1GCC\s0 will enable it by default for languages like
-\&\*(C+ which normally require exception handling, and disable it for
-languages like C that do not normally require it. However, you may need
-to enable this option when compiling C code that needs to interoperate
-properly with exception handlers written in \*(C+. You may also wish to
-disable this option if you are compiling older \*(C+ programs that don't
-use exception handling.
-.IP "\fB\-fnon\-call\-exceptions\fR" 4
-.IX Item "-fnon-call-exceptions"
-Generate code that allows trapping instructions to throw exceptions.
-Note that this requires platform-specific runtime support that does
-not exist everywhere. Moreover, it only allows \fItrapping\fR
-instructions to throw exceptions, i.e. memory references or floating
-point instructions. It does not allow exceptions to be thrown from
-arbitrary signal handlers such as \f(CW\*(C`SIGALRM\*(C'\fR.
-.IP "\fB\-funwind\-tables\fR" 4
-.IX Item "-funwind-tables"
-Similar to \fB\-fexceptions\fR, except that it will just generate any needed
-static data, but will not affect the generated code in any other way.
-You will normally not enable this option; instead, a language processor
-that needs this handling would enable it on your behalf.
-.IP "\fB\-fasynchronous\-unwind\-tables\fR" 4
-.IX Item "-fasynchronous-unwind-tables"
-Generate unwind table in dwarf2 format, if supported by target machine. The
-table is exact at each instruction boundary, so it can be used for stack
-unwinding from asynchronous events (such as debugger or garbage collector).
-.IP "\fB\-fpcc\-struct\-return\fR" 4
-.IX Item "-fpcc-struct-return"
-Return \*(L"short\*(R" \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in memory like
-longer ones, rather than in registers. This convention is less
-efficient, but it has the advantage of allowing intercallability between
-GCC-compiled files and files compiled with other compilers, particularly
-the Portable C Compiler (pcc).
-.Sp
-The precise convention for returning structures in memory depends
-on the target configuration macros.
-.Sp
-Short structures and unions are those whose size and alignment match
-that of some integer type.
-.Sp
-\&\fBWarning:\fR code compiled with the \fB\-fpcc\-struct\-return\fR
-switch is not binary compatible with code compiled with the
-\&\fB\-freg\-struct\-return\fR switch.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-freg\-struct\-return\fR" 4
-.IX Item "-freg-struct-return"
-Return \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in registers when possible.
-This is more efficient for small structures than
-\&\fB\-fpcc\-struct\-return\fR.
-.Sp
-If you specify neither \fB\-fpcc\-struct\-return\fR nor
-\&\fB\-freg\-struct\-return\fR, \s-1GCC\s0 defaults to whichever convention is
-standard for the target. If there is no standard convention, \s-1GCC\s0
-defaults to \fB\-fpcc\-struct\-return\fR, except on targets where \s-1GCC\s0 is
-the principal compiler. In those cases, we can choose the standard, and
-we chose the more efficient register return alternative.
-.Sp
-\&\fBWarning:\fR code compiled with the \fB\-freg\-struct\-return\fR
-switch is not binary compatible with code compiled with the
-\&\fB\-fpcc\-struct\-return\fR switch.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-fshort\-enums\fR" 4
-.IX Item "-fshort-enums"
-Allocate to an \f(CW\*(C`enum\*(C'\fR type only as many bytes as it needs for the
-declared range of possible values. Specifically, the \f(CW\*(C`enum\*(C'\fR type
-will be equivalent to the smallest integer type which has enough room.
-.Sp
-\&\fBWarning:\fR the \fB\-fshort\-enums\fR switch causes \s-1GCC\s0 to generate
-code that is not binary compatible with code generated without that switch.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-fshort\-double\fR" 4
-.IX Item "-fshort-double"
-Use the same size for \f(CW\*(C`double\*(C'\fR as for \f(CW\*(C`float\*(C'\fR.
-.Sp
-\&\fBWarning:\fR the \fB\-fshort\-double\fR switch causes \s-1GCC\s0 to generate
-code that is not binary compatible with code generated without that switch.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-fshort\-wchar\fR" 4
-.IX Item "-fshort-wchar"
-Override the underlying type for \fBwchar_t\fR to be \fBshort
-unsigned int\fR instead of the default for the target. This option is
-useful for building programs to run under \s-1WINE\s0.
-.Sp
-\&\fBWarning:\fR the \fB\-fshort\-wchar\fR switch causes \s-1GCC\s0 to generate
-code that is not binary compatible with code generated without that switch.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-fno\-common\fR" 4
-.IX Item "-fno-common"
-In C code, controls the placement of uninitialized global variables.
-Unix C compilers have traditionally permitted multiple definitions of
-such variables in different compilation units by placing the variables
-in a common block.
-This is the behavior specified by \fB\-fcommon\fR, and is the default
-for \s-1GCC\s0 on most targets.
-On the other hand, this behavior is not required by \s-1ISO\s0 C, and on some
-targets may carry a speed or code size penalty on variable references.
-The \fB\-fno\-common\fR option specifies that the compiler should place
-uninitialized global variables in the data section of the object file,
-rather than generating them as common blocks.
-This has the effect that if the same variable is declared
-(without \f(CW\*(C`extern\*(C'\fR) in two different compilations,
-you will get a multiple-definition error when you link them.
-In this case, you must compile with \fB\-fcommon\fR instead.
-Compiling with \fB\-fno\-common\fR is useful on targets for which
-it provides better performance, or if you wish to verify that the
-program will work on other systems which always treat uninitialized
-variable declarations this way.
-.IP "\fB\-fno\-ident\fR" 4
-.IX Item "-fno-ident"
-Ignore the \fB#ident\fR directive.
-.IP "\fB\-finhibit\-size\-directive\fR" 4
-.IX Item "-finhibit-size-directive"
-Don't output a \f(CW\*(C`.size\*(C'\fR assembler directive, or anything else that
-would cause trouble if the function is split in the middle, and the
-two halves are placed at locations far apart in memory. This option is
-used when compiling \fIcrtstuff.c\fR; you should not need to use it
-for anything else.
-.IP "\fB\-fverbose\-asm\fR" 4
-.IX Item "-fverbose-asm"
-Put extra commentary information in the generated assembly code to
-make it more readable. This option is generally only of use to those
-who actually need to read the generated assembly code (perhaps while
-debugging the compiler itself).
-.Sp
-\&\fB\-fno\-verbose\-asm\fR, the default, causes the
-extra information to be omitted and is useful when comparing two assembler
-files.
-.IP "\fB\-frecord\-gcc\-switches\fR" 4
-.IX Item "-frecord-gcc-switches"
-This switch causes the command line that was used to invoke the
-compiler to be recorded into the object file that is being created.
-This switch is only implemented on some targets and the exact format
-of the recording is target and binary file format dependent, but it
-usually takes the form of a section containing \s-1ASCII\s0 text. This
-switch is related to the \fB\-fverbose\-asm\fR switch, but that
-switch only records information in the assembler output file as
-comments, so it never reaches the object file.
-.IP "\fB\-fpic\fR" 4
-.IX Item "-fpic"
-Generate position-independent code (\s-1PIC\s0) suitable for use in a shared
-library, if supported for the target machine. Such code accesses all
-constant addresses through a global offset table (\s-1GOT\s0). The dynamic
-loader resolves the \s-1GOT\s0 entries when the program starts (the dynamic
-loader is not part of \s-1GCC\s0; it is part of the operating system). If
-the \s-1GOT\s0 size for the linked executable exceeds a machine-specific
-maximum size, you get an error message from the linker indicating that
-\&\fB\-fpic\fR does not work; in that case, recompile with \fB\-fPIC\fR
-instead. (These maximums are 8k on the \s-1SPARC\s0 and 32k
-on the m68k and \s-1RS/6000\s0. The 386 has no such limit.)
-.Sp
-Position-independent code requires special support, and therefore works
-only on certain machines. For the 386, \s-1GCC\s0 supports \s-1PIC\s0 for System V
-but not for the Sun 386i. Code generated for the \s-1IBM\s0 \s-1RS/6000\s0 is always
-position-independent.
-.Sp
-When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
-are defined to 1.
-.IP "\fB\-fPIC\fR" 4
-.IX Item "-fPIC"
-If supported for the target machine, emit position-independent code,
-suitable for dynamic linking and avoiding any limit on the size of the
-global offset table. This option makes a difference on the m68k,
-PowerPC and \s-1SPARC\s0.
-.Sp
-Position-independent code requires special support, and therefore works
-only on certain machines.
-.Sp
-When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
-are defined to 2.
-.IP "\fB\-fpie\fR" 4
-.IX Item "-fpie"
-.PD 0
-.IP "\fB\-fPIE\fR" 4
-.IX Item "-fPIE"
-.PD
-These options are similar to \fB\-fpic\fR and \fB\-fPIC\fR, but
-generated position independent code can be only linked into executables.
-Usually these options are used when \fB\-pie\fR \s-1GCC\s0 option will be
-used during linking.
-.Sp
-\&\fB\-fpie\fR and \fB\-fPIE\fR both define the macros
-\&\f(CW\*(C`_\|_pie_\|_\*(C'\fR and \f(CW\*(C`_\|_PIE_\|_\*(C'\fR. The macros have the value 1
-for \fB\-fpie\fR and 2 for \fB\-fPIE\fR.
-.IP "\fB\-fno\-jump\-tables\fR" 4
-.IX Item "-fno-jump-tables"
-Do not use jump tables for switch statements even where it would be
-more efficient than other code generation strategies. This option is
-of use in conjunction with \fB\-fpic\fR or \fB\-fPIC\fR for
-building code which forms part of a dynamic linker and cannot
-reference the address of a jump table. On some targets, jump tables
-do not require a \s-1GOT\s0 and this option is not needed.
-.IP "\fB\-ffixed\-\fR\fIreg\fR" 4
-.IX Item "-ffixed-reg"
-Treat the register named \fIreg\fR as a fixed register; generated code
-should never refer to it (except perhaps as a stack pointer, frame
-pointer or in some other fixed role).
-.Sp
-\&\fIreg\fR must be the name of a register. The register names accepted
-are machine-specific and are defined in the \f(CW\*(C`REGISTER_NAMES\*(C'\fR
-macro in the machine description macro file.
-.Sp
-This flag does not have a negative form, because it specifies a
-three-way choice.
-.IP "\fB\-fcall\-used\-\fR\fIreg\fR" 4
-.IX Item "-fcall-used-reg"
-Treat the register named \fIreg\fR as an allocable register that is
-clobbered by function calls. It may be allocated for temporaries or
-variables that do not live across a call. Functions compiled this way
-will not save and restore the register \fIreg\fR.
-.Sp
-It is an error to used this flag with the frame pointer or stack pointer.
-Use of this flag for other registers that have fixed pervasive roles in
-the machine's execution model will produce disastrous results.
-.Sp
-This flag does not have a negative form, because it specifies a
-three-way choice.
-.IP "\fB\-fcall\-saved\-\fR\fIreg\fR" 4
-.IX Item "-fcall-saved-reg"
-Treat the register named \fIreg\fR as an allocable register saved by
-functions. It may be allocated even for temporaries or variables that
-live across a call. Functions compiled this way will save and restore
-the register \fIreg\fR if they use it.
-.Sp
-It is an error to used this flag with the frame pointer or stack pointer.
-Use of this flag for other registers that have fixed pervasive roles in
-the machine's execution model will produce disastrous results.
-.Sp
-A different sort of disaster will result from the use of this flag for
-a register in which function values may be returned.
-.Sp
-This flag does not have a negative form, because it specifies a
-three-way choice.
-.IP "\fB\-fpack\-struct[=\fR\fIn\fR\fB]\fR" 4
-.IX Item "-fpack-struct[=n]"
-Without a value specified, pack all structure members together without
-holes. When a value is specified (which must be a small power of two), pack
-structure members according to this value, representing the maximum
-alignment (that is, objects with default alignment requirements larger than
-this will be output potentially unaligned at the next fitting location.
-.Sp
-\&\fBWarning:\fR the \fB\-fpack\-struct\fR switch causes \s-1GCC\s0 to generate
-code that is not binary compatible with code generated without that switch.
-Additionally, it makes the code suboptimal.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-finstrument\-functions\fR" 4
-.IX Item "-finstrument-functions"
-Generate instrumentation calls for entry and exit to functions. Just
-after function entry and just before function exit, the following
-profiling functions will be called with the address of the current
-function and its call site. (On some platforms,
-\&\f(CW\*(C`_\|_builtin_return_address\*(C'\fR does not work beyond the current
-function, so the call site information may not be available to the
-profiling functions otherwise.)
-.Sp
-.Vb 4
-\& void _\|_cyg_profile_func_enter (void *this_fn,
-\& void *call_site);
-\& void _\|_cyg_profile_func_exit (void *this_fn,
-\& void *call_site);
-.Ve
-.Sp
-The first argument is the address of the start of the current function,
-which may be looked up exactly in the symbol table.
-.Sp
-This instrumentation is also done for functions expanded inline in other
-functions. The profiling calls will indicate where, conceptually, the
-inline function is entered and exited. This means that addressable
-versions of such functions must be available. If all your uses of a
-function are expanded inline, this may mean an additional expansion of
-code size. If you use \fBextern inline\fR in your C code, an
-addressable version of such functions must be provided. (This is
-normally the case anyways, but if you get lucky and the optimizer always
-expands the functions inline, you might have gotten away without
-providing static copies.)
-.Sp
-A function may be given the attribute \f(CW\*(C`no_instrument_function\*(C'\fR, in
-which case this instrumentation will not be done. This can be used, for
-example, for the profiling functions listed above, high-priority
-interrupt routines, and any functions from which the profiling functions
-cannot safely be called (perhaps signal handlers, if the profiling
-routines generate output or allocate memory).
-.IP "\fB\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,...\fR" 4
-.IX Item "-finstrument-functions-exclude-file-list=file,file,..."
-Set the list of functions that are excluded from instrumentation (see
-the description of \f(CW\*(C`\-finstrument\-functions\*(C'\fR). If the file that
-contains a function definition matches with one of \fIfile\fR, then
-that function is not instrumented. The match is done on substrings:
-if the \fIfile\fR parameter is a substring of the file name, it is
-considered to be a match.
-.Sp
-For example:
-.Sp
-.Vb 1
-\& \-finstrument\-functions\-exclude\-file\-list=/bits/stl,include/sys
-.Ve
-.Sp
-will exclude any inline function defined in files whose pathnames
-contain \f(CW\*(C`/bits/stl\*(C'\fR or \f(CW\*(C`include/sys\*(C'\fR.
-.Sp
-If, for some reason, you want to include letter \f(CW\*(Aq,\*(Aq\fR in one of
-\&\fIsym\fR, write \f(CW\*(Aq,\*(Aq\fR. For example,
-\&\f(CW\*(C`\-finstrument\-functions\-exclude\-file\-list=\*(Aq,,tmp\*(Aq\*(C'\fR
-(note the single quote surrounding the option).
-.IP "\fB\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,...\fR" 4
-.IX Item "-finstrument-functions-exclude-function-list=sym,sym,..."
-This is similar to \f(CW\*(C`\-finstrument\-functions\-exclude\-file\-list\*(C'\fR,
-but this option sets the list of function names to be excluded from
-instrumentation. The function name to be matched is its user-visible
-name, such as \f(CW\*(C`vector<int> blah(const vector<int> &)\*(C'\fR, not the
-internal mangled name (e.g., \f(CW\*(C`_Z4blahRSt6vectorIiSaIiEE\*(C'\fR). The
-match is done on substrings: if the \fIsym\fR parameter is a substring
-of the function name, it is considered to be a match. For C99 and \*(C+
-extended identifiers, the function name must be given in \s-1UTF\-8\s0, not
-using universal character names.
-.IP "\fB\-fstack\-check\fR" 4
-.IX Item "-fstack-check"
-Generate code to verify that you do not go beyond the boundary of the
-stack. You should specify this flag if you are running in an
-environment with multiple threads, but only rarely need to specify it in
-a single-threaded environment since stack overflow is automatically
-detected on nearly all systems if there is only one stack.
-.Sp
-Note that this switch does not actually cause checking to be done; the
-operating system or the language runtime must do that. The switch causes
-generation of code to ensure that they see the stack being extended.
-.Sp
-You can additionally specify a string parameter: \f(CW\*(C`no\*(C'\fR means no
-checking, \f(CW\*(C`generic\*(C'\fR means force the use of old-style checking,
-\&\f(CW\*(C`specific\*(C'\fR means use the best checking method and is equivalent
-to bare \fB\-fstack\-check\fR.
-.Sp
-Old-style checking is a generic mechanism that requires no specific
-target support in the compiler but comes with the following drawbacks:
-.RS 4
-.IP "1." 4
-Modified allocation strategy for large objects: they will always be
-allocated dynamically if their size exceeds a fixed threshold.
-.IP "2." 4
-Fixed limit on the size of the static frame of functions: when it is
-topped by a particular function, stack checking is not reliable and
-a warning is issued by the compiler.
-.IP "3." 4
-Inefficiency: because of both the modified allocation strategy and the
-generic implementation, the performances of the code are hampered.
-.RE
-.RS 4
-.Sp
-Note that old-style stack checking is also the fallback method for
-\&\f(CW\*(C`specific\*(C'\fR if no target support has been added in the compiler.
-.RE
-.IP "\fB\-fstack\-limit\-register=\fR\fIreg\fR" 4
-.IX Item "-fstack-limit-register=reg"
-.PD 0
-.IP "\fB\-fstack\-limit\-symbol=\fR\fIsym\fR" 4
-.IX Item "-fstack-limit-symbol=sym"
-.IP "\fB\-fno\-stack\-limit\fR" 4
-.IX Item "-fno-stack-limit"
-.PD
-Generate code to ensure that the stack does not grow beyond a certain value,
-either the value of a register or the address of a symbol. If the stack
-would grow beyond the value, a signal is raised. For most targets,
-the signal is raised before the stack overruns the boundary, so
-it is possible to catch the signal without taking special precautions.
-.Sp
-For instance, if the stack starts at absolute address \fB0x80000000\fR
-and grows downwards, you can use the flags
-\&\fB\-fstack\-limit\-symbol=_\|_stack_limit\fR and
-\&\fB\-Wl,\-\-defsym,_\|_stack_limit=0x7ffe0000\fR to enforce a stack limit
-of 128KB. Note that this may only work with the \s-1GNU\s0 linker.
-.IP "\fB\-fsplit\-stack\fR" 4
-.IX Item "-fsplit-stack"
-Generate code to automatically split the stack before it overflows.
-The resulting program has a discontiguous stack which can only
-overflow if the program is unable to allocate any more memory. This
-is most useful when running threaded programs, as it is no longer
-necessary to calculate a good stack size to use for each thread. This
-is currently only implemented for the i386 and x86_64 backends running
-GNU/Linux.
-.Sp
-When code compiled with \fB\-fsplit\-stack\fR calls code compiled
-without \fB\-fsplit\-stack\fR, there may not be much stack space
-available for the latter code to run. If compiling all code,
-including library code, with \fB\-fsplit\-stack\fR is not an option,
-then the linker can fix up these calls so that the code compiled
-without \fB\-fsplit\-stack\fR always has a large stack. Support for
-this is implemented in the gold linker in \s-1GNU\s0 binutils release 2.21
-and later.
-.IP "\fB\-fleading\-underscore\fR" 4
-.IX Item "-fleading-underscore"
-This option and its counterpart, \fB\-fno\-leading\-underscore\fR, forcibly
-change the way C symbols are represented in the object file. One use
-is to help link with legacy assembly code.
-.Sp
-\&\fBWarning:\fR the \fB\-fleading\-underscore\fR switch causes \s-1GCC\s0 to
-generate code that is not binary compatible with code generated without that
-switch. Use it to conform to a non-default application binary interface.
-Not all targets provide complete support for this switch.
-.IP "\fB\-ftls\-model=\fR\fImodel\fR" 4
-.IX Item "-ftls-model=model"
-Alter the thread-local storage model to be used.
-The \fImodel\fR argument should be one of \f(CW\*(C`global\-dynamic\*(C'\fR,
-\&\f(CW\*(C`local\-dynamic\*(C'\fR, \f(CW\*(C`initial\-exec\*(C'\fR or \f(CW\*(C`local\-exec\*(C'\fR.
-.Sp
-The default without \fB\-fpic\fR is \f(CW\*(C`initial\-exec\*(C'\fR; with
-\&\fB\-fpic\fR the default is \f(CW\*(C`global\-dynamic\*(C'\fR.
-.IP "\fB\-fvisibility=\fR\fIdefault|internal|hidden|protected\fR" 4
-.IX Item "-fvisibility=default|internal|hidden|protected"
-Set the default \s-1ELF\s0 image symbol visibility to the specified option\-\-\-all
-symbols will be marked with this unless overridden within the code.
-Using this feature can very substantially improve linking and
-load times of shared object libraries, produce more optimized
-code, provide near-perfect \s-1API\s0 export and prevent symbol clashes.
-It is \fBstrongly\fR recommended that you use this in any shared objects
-you distribute.
-.Sp
-Despite the nomenclature, \f(CW\*(C`default\*(C'\fR always means public; i.e.,
-available to be linked against from outside the shared object.
-\&\f(CW\*(C`protected\*(C'\fR and \f(CW\*(C`internal\*(C'\fR are pretty useless in real-world
-usage so the only other commonly used option will be \f(CW\*(C`hidden\*(C'\fR.
-The default if \fB\-fvisibility\fR isn't specified is
-\&\f(CW\*(C`default\*(C'\fR, i.e., make every
-symbol public\-\-\-this causes the same behavior as previous versions of
-\&\s-1GCC\s0.
-.Sp
-A good explanation of the benefits offered by ensuring \s-1ELF\s0
-symbols have the correct visibility is given by \*(L"How To Write
-Shared Libraries\*(R" by Ulrich Drepper (which can be found at
-<\fBhttp://people.redhat.com/~drepper/\fR>)\-\-\-however a superior
-solution made possible by this option to marking things hidden when
-the default is public is to make the default hidden and mark things
-public. This is the norm with \s-1DLL\s0's on Windows and with \fB\-fvisibility=hidden\fR
-and \f(CW\*(C`_\|_attribute_\|_ ((visibility("default")))\*(C'\fR instead of
-\&\f(CW\*(C`_\|_declspec(dllexport)\*(C'\fR you get almost identical semantics with
-identical syntax. This is a great boon to those working with
-cross-platform projects.
-.Sp
-For those adding visibility support to existing code, you may find
-\&\fB#pragma \s-1GCC\s0 visibility\fR of use. This works by you enclosing
-the declarations you wish to set visibility for with (for example)
-\&\fB#pragma \s-1GCC\s0 visibility push(hidden)\fR and
-\&\fB#pragma \s-1GCC\s0 visibility pop\fR.
-Bear in mind that symbol visibility should be viewed \fBas
-part of the \s-1API\s0 interface contract\fR and thus all new code should
-always specify visibility when it is not the default; i.e., declarations
-only for use within the local \s-1DSO\s0 should \fBalways\fR be marked explicitly
-as hidden as so to avoid \s-1PLT\s0 indirection overheads\-\-\-making this
-abundantly clear also aids readability and self-documentation of the code.
-Note that due to \s-1ISO\s0 \*(C+ specification requirements, operator new and
-operator delete must always be of default visibility.
-.Sp
-Be aware that headers from outside your project, in particular system
-headers and headers from any other library you use, may not be
-expecting to be compiled with visibility other than the default. You
-may need to explicitly say \fB#pragma \s-1GCC\s0 visibility push(default)\fR
-before including any such headers.
-.Sp
-\&\fBextern\fR declarations are not affected by \fB\-fvisibility\fR, so
-a lot of code can be recompiled with \fB\-fvisibility=hidden\fR with
-no modifications. However, this means that calls to \fBextern\fR
-functions with no explicit visibility will use the \s-1PLT\s0, so it is more
-effective to use \fB_\|_attribute ((visibility))\fR and/or
-\&\fB#pragma \s-1GCC\s0 visibility\fR to tell the compiler which \fBextern\fR
-declarations should be treated as hidden.
-.Sp
-Note that \fB\-fvisibility\fR does affect \*(C+ vague linkage
-entities. This means that, for instance, an exception class that will
-be thrown between DSOs must be explicitly marked with default
-visibility so that the \fBtype_info\fR nodes will be unified between
-the DSOs.
-.Sp
-An overview of these techniques, their benefits and how to use them
-is at <\fBhttp://gcc.gnu.org/wiki/Visibility\fR>.
-.IP "\fB\-fstrict\-volatile\-bitfields\fR" 4
-.IX Item "-fstrict-volatile-bitfields"
-This option should be used if accesses to volatile bitfields (or other
-structure fields, although the compiler usually honors those types
-anyway) should use a single access of the width of the
-field's type, aligned to a natural alignment if possible. For
-example, targets with memory-mapped peripheral registers might require
-all such accesses to be 16 bits wide; with this flag the user could
-declare all peripheral bitfields as \*(L"unsigned short\*(R" (assuming short
-is 16 bits on these targets) to force \s-1GCC\s0 to use 16 bit accesses
-instead of, perhaps, a more efficient 32 bit access.
-.Sp
-If this option is disabled, the compiler will use the most efficient
-instruction. In the previous example, that might be a 32\-bit load
-instruction, even though that will access bytes that do not contain
-any portion of the bitfield, or memory-mapped registers unrelated to
-the one being updated.
-.Sp
-If the target requires strict alignment, and honoring the field
-type would require violating this alignment, a warning is issued.
-If the field has \f(CW\*(C`packed\*(C'\fR attribute, the access is done without
-honoring the field type. If the field doesn't have \f(CW\*(C`packed\*(C'\fR
-attribute, the access is done honoring the field type. In both cases,
-\&\s-1GCC\s0 assumes that the user knows something about the target hardware
-that it is unaware of.
-.Sp
-The default value of this option is determined by the application binary
-interface for the target processor.
-.SH "ENVIRONMENT"
-.IX Header "ENVIRONMENT"
-This section describes several environment variables that affect how \s-1GCC\s0
-operates. Some of them work by specifying directories or prefixes to use
-when searching for various kinds of files. Some are used to specify other
-aspects of the compilation environment.
-.PP
-Note that you can also specify places to search using options such as
-\&\fB\-B\fR, \fB\-I\fR and \fB\-L\fR. These
-take precedence over places specified using environment variables, which
-in turn take precedence over those specified by the configuration of \s-1GCC\s0.
-.IP "\fB\s-1LANG\s0\fR" 4
-.IX Item "LANG"
-.PD 0
-.IP "\fB\s-1LC_CTYPE\s0\fR" 4
-.IX Item "LC_CTYPE"
-.IP "\fB\s-1LC_MESSAGES\s0\fR" 4
-.IX Item "LC_MESSAGES"
-.IP "\fB\s-1LC_ALL\s0\fR" 4
-.IX Item "LC_ALL"
-.PD
-These environment variables control the way that \s-1GCC\s0 uses
-localization information that allow \s-1GCC\s0 to work with different
-national conventions. \s-1GCC\s0 inspects the locale categories
-\&\fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR if it has been configured to do
-so. These locale categories can be set to any value supported by your
-installation. A typical value is \fBen_GB.UTF\-8\fR for English in the United
-Kingdom encoded in \s-1UTF\-8\s0.
-.Sp
-The \fB\s-1LC_CTYPE\s0\fR environment variable specifies character
-classification. \s-1GCC\s0 uses it to determine the character boundaries in
-a string; this is needed for some multibyte encodings that contain quote
-and escape characters that would otherwise be interpreted as a string
-end or escape.
-.Sp
-The \fB\s-1LC_MESSAGES\s0\fR environment variable specifies the language to
-use in diagnostic messages.
-.Sp
-If the \fB\s-1LC_ALL\s0\fR environment variable is set, it overrides the value
-of \fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR; otherwise, \fB\s-1LC_CTYPE\s0\fR
-and \fB\s-1LC_MESSAGES\s0\fR default to the value of the \fB\s-1LANG\s0\fR
-environment variable. If none of these variables are set, \s-1GCC\s0
-defaults to traditional C English behavior.
-.IP "\fB\s-1TMPDIR\s0\fR" 4
-.IX Item "TMPDIR"
-If \fB\s-1TMPDIR\s0\fR is set, it specifies the directory to use for temporary
-files. \s-1GCC\s0 uses temporary files to hold the output of one stage of
-compilation which is to be used as input to the next stage: for example,
-the output of the preprocessor, which is the input to the compiler
-proper.
-.IP "\fB\s-1GCC_EXEC_PREFIX\s0\fR" 4
-.IX Item "GCC_EXEC_PREFIX"
-If \fB\s-1GCC_EXEC_PREFIX\s0\fR is set, it specifies a prefix to use in the
-names of the subprograms executed by the compiler. No slash is added
-when this prefix is combined with the name of a subprogram, but you can
-specify a prefix that ends with a slash if you wish.
-.Sp
-If \fB\s-1GCC_EXEC_PREFIX\s0\fR is not set, \s-1GCC\s0 will attempt to figure out
-an appropriate prefix to use based on the pathname it was invoked with.
-.Sp
-If \s-1GCC\s0 cannot find the subprogram using the specified prefix, it
-tries looking in the usual places for the subprogram.
-.Sp
-The default value of \fB\s-1GCC_EXEC_PREFIX\s0\fR is
-\&\fI\fIprefix\fI/lib/gcc/\fR where \fIprefix\fR is the prefix to
-the installed compiler. In many cases \fIprefix\fR is the value
-of \f(CW\*(C`prefix\*(C'\fR when you ran the \fIconfigure\fR script.
-.Sp
-Other prefixes specified with \fB\-B\fR take precedence over this prefix.
-.Sp
-This prefix is also used for finding files such as \fIcrt0.o\fR that are
-used for linking.
-.Sp
-In addition, the prefix is used in an unusual way in finding the
-directories to search for header files. For each of the standard
-directories whose name normally begins with \fB/usr/local/lib/gcc\fR
-(more precisely, with the value of \fB\s-1GCC_INCLUDE_DIR\s0\fR), \s-1GCC\s0 tries
-replacing that beginning with the specified prefix to produce an
-alternate directory name. Thus, with \fB\-Bfoo/\fR, \s-1GCC\s0 will search
-\&\fIfoo/bar\fR where it would normally search \fI/usr/local/lib/bar\fR.
-These alternate directories are searched first; the standard directories
-come next. If a standard directory begins with the configured
-\&\fIprefix\fR then the value of \fIprefix\fR is replaced by
-\&\fB\s-1GCC_EXEC_PREFIX\s0\fR when looking for header files.
-.IP "\fB\s-1COMPILER_PATH\s0\fR" 4
-.IX Item "COMPILER_PATH"
-The value of \fB\s-1COMPILER_PATH\s0\fR is a colon-separated list of
-directories, much like \fB\s-1PATH\s0\fR. \s-1GCC\s0 tries the directories thus
-specified when searching for subprograms, if it can't find the
-subprograms using \fB\s-1GCC_EXEC_PREFIX\s0\fR.
-.IP "\fB\s-1LIBRARY_PATH\s0\fR" 4
-.IX Item "LIBRARY_PATH"
-The value of \fB\s-1LIBRARY_PATH\s0\fR is a colon-separated list of
-directories, much like \fB\s-1PATH\s0\fR. When configured as a native compiler,
-\&\s-1GCC\s0 tries the directories thus specified when searching for special
-linker files, if it can't find them using \fB\s-1GCC_EXEC_PREFIX\s0\fR. Linking
-using \s-1GCC\s0 also uses these directories when searching for ordinary
-libraries for the \fB\-l\fR option (but directories specified with
-\&\fB\-L\fR come first).
-.IP "\fB\s-1LANG\s0\fR" 4
-.IX Item "LANG"
-This variable is used to pass locale information to the compiler. One way in
-which this information is used is to determine the character set to be used
-when character literals, string literals and comments are parsed in C and \*(C+.
-When the compiler is configured to allow multibyte characters,
-the following values for \fB\s-1LANG\s0\fR are recognized:
-.RS 4
-.IP "\fBC\-JIS\fR" 4
-.IX Item "C-JIS"
-Recognize \s-1JIS\s0 characters.
-.IP "\fBC\-SJIS\fR" 4
-.IX Item "C-SJIS"
-Recognize \s-1SJIS\s0 characters.
-.IP "\fBC\-EUCJP\fR" 4
-.IX Item "C-EUCJP"
-Recognize \s-1EUCJP\s0 characters.
-.RE
-.RS 4
-.Sp
-If \fB\s-1LANG\s0\fR is not defined, or if it has some other value, then the
-compiler will use mblen and mbtowc as defined by the default locale to
-recognize and translate multibyte characters.
-.RE
-.PP
-Some additional environments variables affect the behavior of the
-preprocessor.
-.IP "\fB\s-1CPATH\s0\fR" 4
-.IX Item "CPATH"
-.PD 0
-.IP "\fBC_INCLUDE_PATH\fR" 4
-.IX Item "C_INCLUDE_PATH"
-.IP "\fB\s-1CPLUS_INCLUDE_PATH\s0\fR" 4
-.IX Item "CPLUS_INCLUDE_PATH"
-.IP "\fB\s-1OBJC_INCLUDE_PATH\s0\fR" 4
-.IX Item "OBJC_INCLUDE_PATH"
-.PD
-Each variable's value is a list of directories separated by a special
-character, much like \fB\s-1PATH\s0\fR, in which to look for header files.
-The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, is target-dependent and
-determined at \s-1GCC\s0 build time. For Microsoft Windows-based targets it is a
-semicolon, and for almost all other targets it is a colon.
-.Sp
-\&\fB\s-1CPATH\s0\fR specifies a list of directories to be searched as if
-specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
-options on the command line. This environment variable is used
-regardless of which language is being preprocessed.
-.Sp
-The remaining environment variables apply only when preprocessing the
-particular language indicated. Each specifies a list of directories
-to be searched as if specified with \fB\-isystem\fR, but after any
-paths given with \fB\-isystem\fR options on the command line.
-.Sp
-In all these variables, an empty element instructs the compiler to
-search its current working directory. Empty elements can appear at the
-beginning or end of a path. For instance, if the value of
-\&\fB\s-1CPATH\s0\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
-effect as \fB\-I.\ \-I/special/include\fR.
-.IP "\fB\s-1DEPENDENCIES_OUTPUT\s0\fR" 4
-.IX Item "DEPENDENCIES_OUTPUT"
-If this variable is set, its value specifies how to output
-dependencies for Make based on the non-system header files processed
-by the compiler. System header files are ignored in the dependency
-output.
-.Sp
-The value of \fB\s-1DEPENDENCIES_OUTPUT\s0\fR can be just a file name, in
-which case the Make rules are written to that file, guessing the target
-name from the source file name. Or the value can have the form
-\&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
-file \fIfile\fR using \fItarget\fR as the target name.
-.Sp
-In other words, this environment variable is equivalent to combining
-the options \fB\-MM\fR and \fB\-MF\fR,
-with an optional \fB\-MT\fR switch too.
-.IP "\fB\s-1SUNPRO_DEPENDENCIES\s0\fR" 4
-.IX Item "SUNPRO_DEPENDENCIES"
-This variable is the same as \fB\s-1DEPENDENCIES_OUTPUT\s0\fR (see above),
-except that system header files are not ignored, so it implies
-\&\fB\-M\fR rather than \fB\-MM\fR. However, the dependence on the
-main input file is omitted.
-.SH "BUGS"
-.IX Header "BUGS"
-For instructions on reporting bugs, see
-<\fBhttp://gcc.gnu.org/bugs.html\fR>.
-.SH "FOOTNOTES"
-.IX Header "FOOTNOTES"
-.IP "1." 4
-On some systems, \fBgcc \-shared\fR
-needs to build supplementary stub code for constructors to work. On
-multi-libbed systems, \fBgcc \-shared\fR must select the correct support
-libraries to link against. Failing to supply the correct flags may lead
-to subtle defects. Supplying them in cases where they are not necessary
-is innocuous.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7),
-\&\fIcpp\fR\|(1), \fIgcov\fR\|(1), \fIas\fR\|(1), \fIld\fR\|(1), \fIgdb\fR\|(1), \fIadb\fR\|(1), \fIdbx\fR\|(1), \fIsdb\fR\|(1)
-and the Info entries for \fIgcc\fR, \fIcpp\fR, \fIas\fR,
-\&\fIld\fR, \fIbinutils\fR and \fIgdb\fR.
-.SH "AUTHOR"
-.IX Header "AUTHOR"
-See the Info entry for \fBgcc\fR, or
-<\fBhttp://gcc.gnu.org/onlinedocs/gcc/Contributors.html\fR>,
-for contributors to \s-1GCC\s0.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with the
-Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
-Free Software\*(R", the Front-Cover texts being (a) (see below), and with
-the Back-Cover Texts being (b) (see below). A copy of the license is
-included in the \fIgfdl\fR\|(7) man page.
-.PP
-(a) The \s-1FSF\s0's Front-Cover Text is:
-.PP
-.Vb 1
-\& A GNU Manual
-.Ve
-.PP
-(b) The \s-1FSF\s0's Back-Cover Text is:
-.PP
-.Vb 3
-\& You have freedom to copy and modify this GNU Manual, like GNU
-\& software. Copies published by the Free Software Foundation raise
-\& funds for GNU development.
-.Ve
diff --git a/share/man/man1/arm-eabi-gcc.1 b/share/man/man1/arm-eabi-gcc.1
deleted file mode 100644
index d08d4ac..0000000
--- a/share/man/man1/arm-eabi-gcc.1
+++ /dev/null
@@ -1,17818 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "GCC 1"
-.TH GCC 1 "2012-01-06" "gcc-4.6.x-google" "GNU"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-gcc \- GNU project C and C++ compiler
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-gcc [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR] [\fB\-std=\fR\fIstandard\fR]
- [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
- [\fB\-W\fR\fIwarn\fR...] [\fB\-pedantic\fR]
- [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
- [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
- [\fB\-f\fR\fIoption\fR...] [\fB\-m\fR\fImachine-option\fR...]
- [\fB\-o\fR \fIoutfile\fR] [@\fIfile\fR] \fIinfile\fR...
-.PP
-Only the most useful options are listed here; see below for the
-remainder. \fBg++\fR accepts mostly the same options as \fBgcc\fR.
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-When you invoke \s-1GCC\s0, it normally does preprocessing, compilation,
-assembly and linking. The \*(L"overall options\*(R" allow you to stop this
-process at an intermediate stage. For example, the \fB\-c\fR option
-says not to run the linker. Then the output consists of object files
-output by the assembler.
-.PP
-Other options are passed on to one stage of processing. Some options
-control the preprocessor and others the compiler itself. Yet other
-options control the assembler and linker; most of these are not
-documented here, since you rarely need to use any of them.
-.PP
-Most of the command line options that you can use with \s-1GCC\s0 are useful
-for C programs; when an option is only useful with another language
-(usually \*(C+), the explanation says so explicitly. If the description
-for a particular option does not mention a source language, you can use
-that option with all supported languages.
-.PP
-The \fBgcc\fR program accepts options and file names as operands. Many
-options have multi-letter names; therefore multiple single-letter options
-may \fInot\fR be grouped: \fB\-dv\fR is very different from \fB\-d\ \-v\fR.
-.PP
-You can mix options and other arguments. For the most part, the order
-you use doesn't matter. Order does matter when you use several
-options of the same kind; for example, if you specify \fB\-L\fR more
-than once, the directories are searched in the order specified. Also,
-the placement of the \fB\-l\fR option is significant.
-.PP
-Many options have long names starting with \fB\-f\fR or with
-\&\fB\-W\fR\-\-\-for example,
-\&\fB\-fmove\-loop\-invariants\fR, \fB\-Wformat\fR and so on. Most of
-these have both positive and negative forms; the negative form of
-\&\fB\-ffoo\fR would be \fB\-fno\-foo\fR. This manual documents
-only one of these two forms, whichever one is not the default.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.SS "Option Summary"
-.IX Subsection "Option Summary"
-Here is a summary of all the options, grouped by type. Explanations are
-in the following sections.
-.IP "\fIOverall Options\fR" 4
-.IX Item "Overall Options"
-\&\fB\-c \-S \-E \-o\fR \fIfile\fR \fB\-no\-canonical\-prefixes
-\&\-pipe \-pass\-exit\-codes
-\&\-x\fR \fIlanguage\fR \fB\-v \-### \-\-help\fR[\fB=\fR\fIclass\fR[\fB,...\fR]] \fB\-\-target\-help
-\&\-\-version \-wrapper @\fR\fIfile\fR \fB\-fplugin=\fR\fIfile\fR \fB\-fplugin\-arg\-\fR\fIname\fR\fB=\fR\fIarg\fR
-\&\fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] \-fdump\-go\-spec=\fIfile\fR
-.IP "\fIC Language Options\fR" 4
-.IX Item "C Language Options"
-\&\fB\-ansi \-std=\fR\fIstandard\fR \fB\-fgnu89\-inline
-\&\-aux\-info\fR \fIfilename\fR
-\&\fB\-fno\-asm \-fno\-builtin \-fno\-builtin\-\fR\fIfunction\fR
-\&\fB\-fhosted \-ffreestanding \-fopenmp \-fms\-extensions \-fplan9\-extensions
-\&\-trigraphs \-no\-integrated\-cpp \-traditional \-traditional\-cpp
-\&\-fallow\-single\-precision \-fcond\-mismatch \-flax\-vector\-conversions
-\&\-fsigned\-bitfields \-fsigned\-char
-\&\-funsigned\-bitfields \-funsigned\-char\fR
-.IP "\fI\*(C+ Language Options\fR" 4
-.IX Item " Language Options"
-\&\fB\-fabi\-version=\fR\fIn\fR \fB\-fno\-access\-control \-fcheck\-new
-\&\-fconserve\-space \-fconstexpr\-depth=\fR\fIn\fR \fB\-ffriend\-injection
-\&\-fno\-elide\-constructors
-\&\-fno\-enforce\-eh\-specs
-\&\-ffor\-scope \-fno\-for\-scope \-fno\-gnu\-keywords
-\&\-fno\-implicit\-templates
-\&\-fno\-implicit\-inline\-templates
-\&\-fno\-implement\-inlines \-fms\-extensions
-\&\-fno\-nonansi\-builtins \-fnothrow\-opt \-fno\-operator\-names
-\&\-fno\-optional\-diags \-fpermissive
-\&\-fno\-pretty\-templates
-\&\-frepo \-fno\-rtti \-fstats \-ftemplate\-depth=\fR\fIn\fR
-\&\fB\-fno\-threadsafe\-statics \-fuse\-cxa\-atexit \-fno\-weak \-nostdinc++
-\&\-fno\-default\-inline \-fvisibility\-inlines\-hidden
-\&\-fvisibility\-ms\-compat
-\&\-Wabi \-Wconversion\-null \-Wctor\-dtor\-privacy
-\&\-Wnoexcept \-Wnon\-virtual\-dtor \-Wreorder
-\&\-Weffc++ \-Wstrict\-null\-sentinel
-\&\-Wno\-non\-template\-friend \-Wold\-style\-cast
-\&\-Woverloaded\-virtual \-Wno\-pmf\-conversions
-\&\-Wsign\-promo\fR
-.IP "\fIObjective-C and Objective\-\*(C+ Language Options\fR" 4
-.IX Item "Objective-C and Objective- Language Options"
-\&\fB\-fconstant\-string\-class=\fR\fIclass-name\fR
-\&\fB\-fgnu\-runtime \-fnext\-runtime
-\&\-fno\-nil\-receivers
-\&\-fobjc\-abi\-version=\fR\fIn\fR
-\&\fB\-fobjc\-call\-cxx\-cdtors
-\&\-fobjc\-direct\-dispatch
-\&\-fobjc\-exceptions
-\&\-fobjc\-gc
-\&\-fobjc\-nilcheck
-\&\-fobjc\-std=objc1
-\&\-freplace\-objc\-classes
-\&\-fzero\-link
-\&\-gen\-decls
-\&\-Wassign\-intercept
-\&\-Wno\-protocol \-Wselector
-\&\-Wstrict\-selector\-match
-\&\-Wundeclared\-selector\fR
-.IP "\fILanguage Independent Options\fR" 4
-.IX Item "Language Independent Options"
-\&\fB\-fmessage\-length=\fR\fIn\fR
-\&\fB\-fdiagnostics\-show\-location=\fR[\fBonce\fR|\fBevery-line\fR]
-\&\fB\-fno\-diagnostics\-show\-option\fR
-.IP "\fIWarning Options\fR" 4
-.IX Item "Warning Options"
-\&\fB\-fsyntax\-only \-fmax\-errors=\fR\fIn\fR \fB\-pedantic
-\&\-pedantic\-errors
-\&\-w \-Wextra \-Wall \-Waddress \-Waggregate\-return \-Warray\-bounds
-\&\-Wno\-attributes \-Wno\-builtin\-macro\-redefined
-\&\-Wc++\-compat \-Wc++0x\-compat \-Wcast\-align \-Wcast\-qual
-\&\-Wchar\-subscripts \-Wclobbered \-Wcomment
-\&\-Wconversion \-Wcoverage\-mismatch \-Wno\-cpp \-Wno\-deprecated
-\&\-Wno\-deprecated\-declarations \-Wdisabled\-optimization
-\&\-Wno\-div\-by\-zero \-Wdouble\-promotion \-Wempty\-body \-Wenum\-compare
-\&\-Wno\-endif\-labels \-Werror \-Werror=*
-\&\-Wfatal\-errors \-Wfloat\-equal \-Wformat \-Wformat=2
-\&\-Wno\-format\-contains\-nul \-Wno\-format\-extra\-args \-Wformat\-nonliteral
-\&\-Wformat\-security \-Wformat\-y2k
-\&\-Wframe\-larger\-than=\fR\fIlen\fR \fB\-Wjump\-misses\-init \-Wignored\-qualifiers
-\&\-Wimplicit \-Wimplicit\-function\-declaration \-Wimplicit\-int
-\&\-Winit\-self \-Winline \-Wmaybe\-uninitialized
-\&\-Wno\-int\-to\-pointer\-cast \-Wno\-invalid\-offsetof
-\&\-Winvalid\-pch \-Wlarger\-than=\fR\fIlen\fR \fB\-Wunsafe\-loop\-optimizations
-\&\-Wlogical\-op \-Wlong\-long
-\&\-Wmain \-Wmaybe\-uninitialized \-Wmissing\-braces \-Wmissing\-field\-initializers
-\&\-Wmissing\-format\-attribute \-Wmissing\-include\-dirs
-\&\-Wno\-mudflap
-\&\-Wno\-multichar \-Wnonnull \-Wno\-overflow
-\&\-Woverlength\-strings \-Wpacked \-Wpacked\-bitfield\-compat \-Wpadded
-\&\-Wparentheses \-Wpedantic\-ms\-format \-Wno\-pedantic\-ms\-format
-\&\-Wpointer\-arith \-Wno\-pointer\-to\-int\-cast
-\&\-Wreal\-conversion \-Wredundant\-decls \-Wreturn\-type \-Wripa\-opt\-mismatch
-\&\-Wself\-assign \-Wself\-assign\-non\-pod \-Wsequence\-point \-Wshadow
-\&\-Wshadow\-compatible\-local \-Wshadow\-local
-\&\-Wsign\-compare \-Wsign\-conversion \-Wstack\-protector
-\&\-Wstrict\-aliasing \-Wstrict\-aliasing=n
-\&\-Wstrict\-overflow \-Wstrict\-overflow=\fR\fIn\fR
-\&\fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR]
-\&\fB\-Wswitch \-Wswitch\-default \-Wswitch\-enum \-Wsync\-nand
-\&\-Wsystem\-headers \-Wthread\-safety \-Wthread\-unguarded\-var
-\&\-Wthread\-unguarded\-func \-Wthread\-mismatched\-lock\-order
-\&\-Wthread\-mismatched\-lock\-acq\-rel \-Wthread\-reentrant\-lock
-\&\-Wthread\-unsupported\-lock\-name \-Wthread\-attr\-bind\-param
-\&\-Wtrampolines \-Wtrigraphs \-Wtype\-limits \-Wundef
-\&\-Wuninitialized \-Wunknown\-pragmas \-Wno\-pragmas
-\&\-Wunsuffixed\-float\-constants \-Wunused \-Wunused\-function
-\&\-Wunused\-label \-Wunused\-parameter \-Wno\-unused\-result \-Wunused\-value
-\&\-Wunused\-variable \-Wunused\-but\-set\-parameter \-Wunused\-but\-set\-variable
-\&\-Wvariadic\-macros \-Wvla \-Wvolatile\-register\-var \-Wwrite\-strings\fR
-.IP "\fIC and Objective-C-only Warning Options\fR" 4
-.IX Item "C and Objective-C-only Warning Options"
-\&\fB\-Wbad\-function\-cast \-Wmissing\-declarations
-\&\-Wmissing\-parameter\-type \-Wmissing\-prototypes \-Wnested\-externs
-\&\-Wold\-style\-declaration \-Wold\-style\-definition
-\&\-Wstrict\-prototypes \-Wtraditional \-Wtraditional\-conversion
-\&\-Wdeclaration\-after\-statement \-Wpointer\-sign\fR
-.IP "\fIDebugging Options\fR" 4
-.IX Item "Debugging Options"
-\&\fB\-d\fR\fIletters\fR \fB\-dumpspecs \-dumpmachine \-dumpversion
-\&\-fdbg\-cnt\-list \-fdbg\-cnt=\fR\fIcounter-value-list\fR
-\&\fB\-fdisable\-ipa\-\fR\fIpass_name\fR
-\&\fB\-fdisable\-rtl\-\fR\fIpass_name\fR
-\&\fB\-fdisable\-rtl\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR
-\&\fB\-fdisable\-tree\-\fR\fIpass_name\fR
-\&\fB\-fdisable\-tree\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR
-\&\fB\-fdump\-noaddr \-fdump\-unnumbered \-fdump\-unnumbered\-links
-\&\-fdump\-translation\-unit\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-class\-hierarchy\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-ipa\-all \-fdump\-ipa\-cgraph \-fdump\-ipa\-inline
-\&\-fdump\-passes
-\&\-fdump\-statistics
-\&\-fdump\-tree\-all
-\&\-fdump\-tree\-original\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-optimized\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-cfg \-fdump\-tree\-vcg \-fdump\-tree\-alias
-\&\-fdump\-tree\-ch
-\&\-fdump\-tree\-ssa\fR[\fB\-\fR\fIn\fR] \fB\-fdump\-tree\-pre\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-ccp\fR[\fB\-\fR\fIn\fR] \fB\-fdump\-tree\-dce\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-gimple\fR[\fB\-raw\fR] \fB\-fdump\-tree\-mudflap\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-dom\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-dse\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-phiprop\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-phiopt\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-forwprop\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-copyrename\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-nrv \-fdump\-tree\-vect
-\&\-fdump\-tree\-sink
-\&\-fdump\-tree\-sra\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-forwprop\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-fre\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-tree\-vrp\fR[\fB\-\fR\fIn\fR]
-\&\fB\-ftree\-vectorizer\-verbose=\fR\fIn\fR
-\&\fB\-fdump\-tree\-storeccp\fR[\fB\-\fR\fIn\fR]
-\&\fB\-fdump\-final\-insns=\fR\fIfile\fR
-\&\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR] \fB\-fcompare\-debug\-second
-\&\-feliminate\-dwarf2\-dups \-feliminate\-unused\-debug\-types
-\&\-feliminate\-unused\-debug\-symbols \-femit\-class\-debug\-always
-\&\-fenable\-icf\-debug
-\&\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR
-\&\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR
-\&\fB\-fdebug\-types\-section
-\&\-fmem\-report \-fpre\-ipa\-mem\-report \-fpost\-ipa\-mem\-report \-fprofile\-arcs
-\&\-frandom\-seed=\fR\fIstring\fR \fB\-fsched\-verbose=\fR\fIn\fR
-\&\fB\-fsel\-sched\-verbose \-fsel\-sched\-dump\-cfg \-fsel\-sched\-pipelining\-verbose
-\&\-fstack\-usage \-ftest\-coverage \-ftime\-report \-fvar\-tracking
-\&\-fvar\-tracking\-assignments \-fvar\-tracking\-assignments\-toggle
-\&\-g \-g\fR\fIlevel\fR \fB\-gtoggle \-gcoff \-gdwarf\-\fR\fIversion\fR
-\&\fB\-ggdb \-gmlt \-gstabs \-gstabs+ \-gstrict\-dwarf \-gno\-strict\-dwarf
-\&\-gvms \-gxcoff \-gxcoff+
-\&\-fno\-merge\-debug\-strings \-fno\-dwarf2\-cfi\-asm
-\&\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR
-\&\fB\-femit\-struct\-debug\-baseonly \-femit\-struct\-debug\-reduced
-\&\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR]
-\&\fB\-p \-pg \-print\-file\-name=\fR\fIlibrary\fR \fB\-print\-libgcc\-file\-name
-\&\-print\-multi\-directory \-print\-multi\-lib \-print\-multi\-os\-directory
-\&\-print\-prog\-name=\fR\fIprogram\fR \fB\-print\-search\-dirs \-Q
-\&\-print\-sysroot \-print\-sysroot\-headers\-suffix
-\&\-save\-temps \-save\-temps=cwd \-save\-temps=obj \-time\fR[\fB=\fR\fIfile\fR]
-.IP "\fIOptimization Options\fR" 4
-.IX Item "Optimization Options"
-\&\fB\-falign\-functions[=\fR\fIn\fR\fB] \-falign\-jumps[=\fR\fIn\fR\fB]
-\&\-falign\-labels[=\fR\fIn\fR\fB] \-falign\-loops[=\fR\fIn\fR\fB] \-fassociative\-math
-\&\-fauto\-inc\-dec \-fbranch\-probabilities \-fbranch\-target\-load\-optimize
-\&\-fbranch\-target\-load\-optimize2 \-fbtr\-bb\-exclusive \-fcaller\-saves
-\&\-fcallgraph\-profiles\-sections \-fcheck\-data\-deps \-fclone\-hot\-version\-paths
-\&\-fcombine\-stack\-adjustments \-fconserve\-stack
-\&\-fcompare\-elim \-fcprop\-registers \-fcrossjumping
-\&\-fcse\-follow\-jumps \-fcse\-skip\-blocks \-fcx\-fortran\-rules
-\&\-fcx\-limited\-range
-\&\-fdata\-sections \-fdce \-fdce \-fdelayed\-branch
-\&\-fdelete\-null\-pointer\-checks \-fdse \-fdevirtualize \-fdse
-\&\-fearly\-inlining \-fipa\-sra \-fexpensive\-optimizations \-ffast\-math
-\&\-ffinite\-math\-only \-ffloat\-store \-fexcess\-precision=\fR\fIstyle\fR
-\&\fB\-fforward\-propagate \-ffp\-contract=\fR\fIstyle\fR \fB\-ffunction\-sections
-\&\-fgcse \-fgcse\-after\-reload \-fgcse\-las \-fgcse\-lm \-fgraphite\-identity
-\&\-fgcse\-sm \-fif\-conversion \-fif\-conversion2 \-findirect\-inlining
-\&\-finline\-functions \-finline\-functions\-called\-once \-finline\-limit=\fR\fIn\fR
-\&\fB\-finline\-small\-functions \-fipa\-cp \-fipa\-cp\-clone \-fipa\-matrix\-reorg
-\&\-fipa\-pta \-fipa\-profile \-fipa\-pure\-const \-fipa\-reference
-\&\-fipa\-struct\-reorg \-fira\-algorithm=\fR\fIalgorithm\fR
-\&\fB\-fira\-region=\fR\fIregion\fR
-\&\fB\-fira\-loop\-pressure \-fno\-ira\-share\-save\-slots
-\&\-fno\-ira\-share\-spill\-slots \-fira\-verbose=\fR\fIn\fR
-\&\fB\-fivopts \-fkeep\-inline\-functions \-fkeep\-static\-consts
-\&\-floop\-block \-floop\-flatten \-floop\-interchange \-floop\-strip\-mine
-\&\-floop\-parallelize\-all \-flto \-flto\-compression\-level
-\&\-flto\-partition=\fR\fIalg\fR \fB\-flto\-report \-fmerge\-all\-constants
-\&\-fmerge\-constants \-fmodulo\-sched \-fmodulo\-sched\-allow\-regmoves
-\&\-fmove\-loop\-invariants fmudflap \-fmudflapir \-fmudflapth \-fno\-branch\-count\-reg
-\&\-fno\-default\-inline
-\&\-fno\-defer\-pop \-fno\-function\-cse \-fno\-guess\-branch\-probability
-\&\-fno\-inline \-fno\-math\-errno \-fno\-peephole \-fno\-peephole2
-\&\-fno\-sched\-interblock \-fno\-sched\-spec \-fno\-signed\-zeros
-\&\-fno\-toplevel\-reorder \-fno\-trapping\-math \-fno\-zero\-initialized\-in\-bss
-\&\-fomit\-frame\-pointer \-foptimize\-register\-move \-foptimize\-sibling\-calls
-\&\-fpartial\-inlining \-fpeel\-loops \-fpredictive\-commoning
-\&\-fprefetch\-loop\-arrays
-\&\-fprofile\-correction \-fprofile\-dir=\fR\fIpath\fR \fB\-fprofile\-generate
-\&\-fprofile\-generate=\fR\fIpath\fR \fB\-fprofile\-generate\-sampling
-\&\-fprofile\-use \-fprofile\-use=\fR\fIpath\fR \fB\-fprofile\-values
-\&\-fpmu\-profile\-generate=\fR\fIpmuoption\fR
-\&\fB\-fpmu\-profile\-use=\fR\fIpmuoption\fR
-\&\fB\-freciprocal\-math \-fregmove \-frename\-registers \-freorder\-blocks
-\&\-frecord\-gcc\-switches\-in\-elf
-\&\-freorder\-blocks\-and\-partition \-freorder\-functions
-\&\-frerun\-cse\-after\-loop \-freschedule\-modulo\-scheduled\-loops
-\&\-fripa \-fripa\-disallow\-asm\-modules \-fripa\-disallow\-opt\-mismatch
-\&\-fripa\-no\-promote\-always\-inline\-func \-fripa\-verbose
-\&\-fripa\-peel\-size\-limit \-fripa\-unroll\-size\-limit \-frounding\-math
-\&\-fsched2\-use\-superblocks \-fsched\-pressure
-\&\-fsched\-spec\-load \-fsched\-spec\-load\-dangerous
-\&\-fsched\-stalled\-insns\-dep[=\fR\fIn\fR\fB] \-fsched\-stalled\-insns[=\fR\fIn\fR\fB]
-\&\-fsched\-group\-heuristic \-fsched\-critical\-path\-heuristic
-\&\-fsched\-spec\-insn\-heuristic \-fsched\-rank\-heuristic
-\&\-fsched\-last\-insn\-heuristic \-fsched\-dep\-count\-heuristic
-\&\-fschedule\-insns \-fschedule\-insns2 \-fsection\-anchors
-\&\-fselective\-scheduling \-fselective\-scheduling2
-\&\-fsel\-sched\-pipelining \-fsel\-sched\-pipelining\-outer\-loops
-\&\-fsignaling\-nans \-fsingle\-precision\-constant \-fsplit\-ivs\-in\-unroller
-\&\-fsplit\-wide\-types \-fstack\-protector \-fstack\-protector\-all
-\&\-fstack\-protector\-strong \-fstrict\-aliasing \-fstrict\-overflow
-\&\-fthread\-jumps \-ftracer \-ftree\-bit\-ccp
-\&\-ftree\-builtin\-call\-dce \-ftree\-ccp \-ftree\-ch \-ftree\-copy\-prop
-\&\-ftree\-copyrename \-ftree\-dce \-ftree\-dominator\-opts \-ftree\-dse
-\&\-ftree\-forwprop \-ftree\-fre \-ftree\-loop\-if\-convert
-\&\-ftree\-loop\-if\-convert\-stores \-ftree\-loop\-im
-\&\-ftree\-phiprop \-ftree\-loop\-distribution \-ftree\-loop\-distribute\-patterns
-\&\-ftree\-loop\-ivcanon \-ftree\-loop\-linear \-ftree\-loop\-optimize
-\&\-ftree\-parallelize\-loops=\fR\fIn\fR \fB\-ftree\-pre \-ftree\-pta \-ftree\-reassoc
-\&\-ftree\-sink \-ftree\-sra \-ftree\-switch\-conversion
-\&\-ftree\-ter \-ftree\-vect\-loop\-version \-ftree\-vectorize \-ftree\-vrp
-\&\-funit\-at\-a\-time \-funroll\-all\-loops \-funroll\-loops
-\&\-funsafe\-loop\-optimizations \-funsafe\-math\-optimizations \-funswitch\-loops
-\&\-fvariable\-expansion\-in\-unroller \-fvect\-cost\-model \-fvpt \-fweb
-\&\-fwhole\-program \-fwpa \-fuse\-ld \-fuse\-linker\-plugin
-\&\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR
-\&\fB\-O \-O0 \-O1 \-O2 \-O3 \-Os \-Ofast\fR
-.IP "\fIPreprocessor Options\fR" 4
-.IX Item "Preprocessor Options"
-\&\fB\-A\fR\fIquestion\fR\fB=\fR\fIanswer\fR
-\&\fB\-A\-\fR\fIquestion\fR[\fB=\fR\fIanswer\fR]
-\&\fB\-C \-dD \-dI \-dM \-dN
-\&\-D\fR\fImacro\fR[\fB=\fR\fIdefn\fR] \fB\-E \-H
-\&\-idirafter\fR \fIdir\fR
-\&\fB\-include\fR \fIfile\fR \fB\-imacros\fR \fIfile\fR
-\&\fB\-iprefix\fR \fIfile\fR \fB\-iwithprefix\fR \fIdir\fR
-\&\fB\-iwithprefixbefore\fR \fIdir\fR \fB\-isystem\fR \fIdir\fR
-\&\fB\-imultilib\fR \fIdir\fR \fB\-isysroot\fR \fIdir\fR
-\&\fB\-M \-MM \-MF \-MG \-MP \-MQ \-MT \-nostdinc
-\&\-P \-fworking\-directory \-remap
-\&\-trigraphs \-undef \-U\fR\fImacro\fR \fB\-Wp,\fR\fIoption\fR
-\&\fB\-Xpreprocessor\fR \fIoption\fR
-.IP "\fIAssembler Option\fR" 4
-.IX Item "Assembler Option"
-\&\fB\-Wa,\fR\fIoption\fR \fB\-Xassembler\fR \fIoption\fR
-.IP "\fILinker Options\fR" 4
-.IX Item "Linker Options"
-\&\fIobject-file-name\fR \fB\-l\fR\fIlibrary\fR
-\&\fB\-nostartfiles \-nodefaultlibs \-nostdlib \-pie \-rdynamic
-\&\-s \-static \-static\-libgcc \-static\-libstdc++ \-shared
-\&\-shared\-libgcc \-symbolic
-\&\-T\fR \fIscript\fR \fB\-Wl,\fR\fIoption\fR \fB\-Xlinker\fR \fIoption\fR
-\&\fB\-u\fR \fIsymbol\fR
-.IP "\fIDirectory Options\fR" 4
-.IX Item "Directory Options"
-\&\fB\-B\fR\fIprefix\fR \fB\-I\fR\fIdir\fR \fB\-iplugindir=\fR\fIdir\fR
-\&\-iquote\fIdir\fR \-L\fIdir\fR \-specs=\fIfile\fR \-I\-
-\&\-\-sysroot=\fIdir\fR
-.IP "\fIMachine Dependent Options\fR" 4
-.IX Item "Machine Dependent Options"
-\&\fI\s-1ARC\s0 Options\fR
-\&\fB\-EB \-EL
-\&\-mmangle\-cpu \-mcpu=\fR\fIcpu\fR \fB\-mtext=\fR\fItext-section\fR
-\&\fB\-mdata=\fR\fIdata-section\fR \fB\-mrodata=\fR\fIreadonly-data-section\fR
-.Sp
-\&\fI\s-1ARM\s0 Options\fR
-\&\fB\-mapcs\-frame \-mno\-apcs\-frame
-\&\-mabi=\fR\fIname\fR
-\&\fB\-mapcs\-stack\-check \-mno\-apcs\-stack\-check
-\&\-mapcs\-float \-mno\-apcs\-float
-\&\-mapcs\-reentrant \-mno\-apcs\-reentrant
-\&\-msched\-prolog \-mno\-sched\-prolog
-\&\-mlittle\-endian \-mbig\-endian \-mwords\-little\-endian
-\&\-mfloat\-abi=\fR\fIname\fR \fB\-msoft\-float \-mhard\-float \-mfpe
-\&\-mfp16\-format=\fR\fIname\fR
-\&\fB\-mthumb\-interwork \-mno\-thumb\-interwork
-\&\-mcpu=\fR\fIname\fR \fB\-march=\fR\fIname\fR \fB\-mfpu=\fR\fIname\fR
-\&\fB\-mstructure\-size\-boundary=\fR\fIn\fR
-\&\fB\-mabort\-on\-noreturn
-\&\-mlong\-calls \-mno\-long\-calls
-\&\-msingle\-pic\-base \-mno\-single\-pic\-base
-\&\-mpic\-register=\fR\fIreg\fR
-\&\fB\-mnop\-fun\-dllimport
-\&\-mcirrus\-fix\-invalid\-insns \-mno\-cirrus\-fix\-invalid\-insns
-\&\-mpoke\-function\-name
-\&\-mthumb \-marm
-\&\-mtpcs\-frame \-mtpcs\-leaf\-frame
-\&\-mcaller\-super\-interworking \-mcallee\-super\-interworking
-\&\-mtp=\fR\fIname\fR
-\&\fB\-mword\-relocations
-\&\-mfix\-cortex\-m3\-ldrd\fR
-.Sp
-\&\fI\s-1AVR\s0 Options\fR
-\&\fB\-mmcu=\fR\fImcu\fR \fB\-mno\-interrupts
-\&\-mcall\-prologues \-mtiny\-stack \-mint8\fR
-.Sp
-\&\fIBlackfin Options\fR
-\&\fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR]
-\&\fB\-msim \-momit\-leaf\-frame\-pointer \-mno\-omit\-leaf\-frame\-pointer
-\&\-mspecld\-anomaly \-mno\-specld\-anomaly \-mcsync\-anomaly \-mno\-csync\-anomaly
-\&\-mlow\-64k \-mno\-low64k \-mstack\-check\-l1 \-mid\-shared\-library
-\&\-mno\-id\-shared\-library \-mshared\-library\-id=\fR\fIn\fR
-\&\fB\-mleaf\-id\-shared\-library \-mno\-leaf\-id\-shared\-library
-\&\-msep\-data \-mno\-sep\-data \-mlong\-calls \-mno\-long\-calls
-\&\-mfast\-fp \-minline\-plt \-mmulticore \-mcorea \-mcoreb \-msdram
-\&\-micplb\fR
-.Sp
-\&\fI\s-1CRIS\s0 Options\fR
-\&\fB\-mcpu=\fR\fIcpu\fR \fB\-march=\fR\fIcpu\fR \fB\-mtune=\fR\fIcpu\fR
-\&\fB\-mmax\-stack\-frame=\fR\fIn\fR \fB\-melinux\-stacksize=\fR\fIn\fR
-\&\fB\-metrax4 \-metrax100 \-mpdebug \-mcc\-init \-mno\-side\-effects
-\&\-mstack\-align \-mdata\-align \-mconst\-align
-\&\-m32\-bit \-m16\-bit \-m8\-bit \-mno\-prologue\-epilogue \-mno\-gotplt
-\&\-melf \-maout \-melinux \-mlinux \-sim \-sim2
-\&\-mmul\-bug\-workaround \-mno\-mul\-bug\-workaround\fR
-.Sp
-\&\fI\s-1CRX\s0 Options\fR
-\&\fB\-mmac \-mpush\-args\fR
-.Sp
-\&\fIDarwin Options\fR
-\&\fB\-all_load \-allowable_client \-arch \-arch_errors_fatal
-\&\-arch_only \-bind_at_load \-bundle \-bundle_loader
-\&\-client_name \-compatibility_version \-current_version
-\&\-dead_strip
-\&\-dependency\-file \-dylib_file \-dylinker_install_name
-\&\-dynamic \-dynamiclib \-exported_symbols_list
-\&\-filelist \-flat_namespace \-force_cpusubtype_ALL
-\&\-force_flat_namespace \-headerpad_max_install_names
-\&\-iframework
-\&\-image_base \-init \-install_name \-keep_private_externs
-\&\-multi_module \-multiply_defined \-multiply_defined_unused
-\&\-noall_load \-no_dead_strip_inits_and_terms
-\&\-nofixprebinding \-nomultidefs \-noprebind \-noseglinkedit
-\&\-pagezero_size \-prebind \-prebind_all_twolevel_modules
-\&\-private_bundle \-read_only_relocs \-sectalign
-\&\-sectobjectsymbols \-whyload \-seg1addr
-\&\-sectcreate \-sectobjectsymbols \-sectorder
-\&\-segaddr \-segs_read_only_addr \-segs_read_write_addr
-\&\-seg_addr_table \-seg_addr_table_filename \-seglinkedit
-\&\-segprot \-segs_read_only_addr \-segs_read_write_addr
-\&\-single_module \-static \-sub_library \-sub_umbrella
-\&\-twolevel_namespace \-umbrella \-undefined
-\&\-unexported_symbols_list \-weak_reference_mismatches
-\&\-whatsloaded \-F \-gused \-gfull \-mmacosx\-version\-min=\fR\fIversion\fR
-\&\fB\-mkernel \-mone\-byte\-bool\fR
-.Sp
-\&\fI\s-1DEC\s0 Alpha Options\fR
-\&\fB\-mno\-fp\-regs \-msoft\-float \-malpha\-as \-mgas
-\&\-mieee \-mieee\-with\-inexact \-mieee\-conformant
-\&\-mfp\-trap\-mode=\fR\fImode\fR \fB\-mfp\-rounding\-mode=\fR\fImode\fR
-\&\fB\-mtrap\-precision=\fR\fImode\fR \fB\-mbuild\-constants
-\&\-mcpu=\fR\fIcpu-type\fR \fB\-mtune=\fR\fIcpu-type\fR
-\&\fB\-mbwx \-mmax \-mfix \-mcix
-\&\-mfloat\-vax \-mfloat\-ieee
-\&\-mexplicit\-relocs \-msmall\-data \-mlarge\-data
-\&\-msmall\-text \-mlarge\-text
-\&\-mmemory\-latency=\fR\fItime\fR
-.Sp
-\&\fI\s-1DEC\s0 Alpha/VMS Options\fR
-\&\fB\-mvms\-return\-codes \-mdebug\-main=\fR\fIprefix\fR \fB\-mmalloc64\fR
-.Sp
-\&\fI\s-1FR30\s0 Options\fR
-\&\fB\-msmall\-model \-mno\-lsim\fR
-.Sp
-\&\fI\s-1FRV\s0 Options\fR
-\&\fB\-mgpr\-32 \-mgpr\-64 \-mfpr\-32 \-mfpr\-64
-\&\-mhard\-float \-msoft\-float
-\&\-malloc\-cc \-mfixed\-cc \-mdword \-mno\-dword
-\&\-mdouble \-mno\-double
-\&\-mmedia \-mno\-media \-mmuladd \-mno\-muladd
-\&\-mfdpic \-minline\-plt \-mgprel\-ro \-multilib\-library\-pic
-\&\-mlinked\-fp \-mlong\-calls \-malign\-labels
-\&\-mlibrary\-pic \-macc\-4 \-macc\-8
-\&\-mpack \-mno\-pack \-mno\-eflags \-mcond\-move \-mno\-cond\-move
-\&\-moptimize\-membar \-mno\-optimize\-membar
-\&\-mscc \-mno\-scc \-mcond\-exec \-mno\-cond\-exec
-\&\-mvliw\-branch \-mno\-vliw\-branch
-\&\-mmulti\-cond\-exec \-mno\-multi\-cond\-exec \-mnested\-cond\-exec
-\&\-mno\-nested\-cond\-exec \-mtomcat\-stats
-\&\-mTLS \-mtls
-\&\-mcpu=\fR\fIcpu\fR
-.Sp
-\&\fIGNU/Linux Options\fR
-\&\fB\-mglibc \-muclibc \-mbionic \-mandroid
-\&\-tno\-android\-cc \-tno\-android\-ld\fR
-.Sp
-\&\fIH8/300 Options\fR
-\&\fB\-mrelax \-mh \-ms \-mn \-mint32 \-malign\-300\fR
-.Sp
-\&\fI\s-1HPPA\s0 Options\fR
-\&\fB\-march=\fR\fIarchitecture-type\fR
-\&\fB\-mbig\-switch \-mdisable\-fpregs \-mdisable\-indexing
-\&\-mfast\-indirect\-calls \-mgas \-mgnu\-ld \-mhp\-ld
-\&\-mfixed\-range=\fR\fIregister-range\fR
-\&\fB\-mjump\-in\-delay \-mlinker\-opt \-mlong\-calls
-\&\-mlong\-load\-store \-mno\-big\-switch \-mno\-disable\-fpregs
-\&\-mno\-disable\-indexing \-mno\-fast\-indirect\-calls \-mno\-gas
-\&\-mno\-jump\-in\-delay \-mno\-long\-load\-store
-\&\-mno\-portable\-runtime \-mno\-soft\-float
-\&\-mno\-space\-regs \-msoft\-float \-mpa\-risc\-1\-0
-\&\-mpa\-risc\-1\-1 \-mpa\-risc\-2\-0 \-mportable\-runtime
-\&\-mschedule=\fR\fIcpu-type\fR \fB\-mspace\-regs \-msio \-mwsio
-\&\-munix=\fR\fIunix-std\fR \fB\-nolibdld \-static \-threads\fR
-.Sp
-\&\fIi386 and x86\-64 Options\fR
-\&\fB\-mtune=\fR\fIcpu-type\fR \fB\-march=\fR\fIcpu-type\fR
-\&\fB\-mfpmath=\fR\fIunit\fR
-\&\fB\-masm=\fR\fIdialect\fR \fB\-mno\-fancy\-math\-387
-\&\-mno\-fp\-ret\-in\-387 \-msoft\-float
-\&\-mno\-wide\-multiply \-mrtd \-malign\-double
-\&\-mpreferred\-stack\-boundary=\fR\fInum\fR
-\&\fB\-mincoming\-stack\-boundary=\fR\fInum\fR
-\&\fB\-mcld \-mcx16 \-msahf \-mmovbe \-mcrc32 \-mrecip \-mvzeroupper
-\&\-mmmx \-msse \-msse2 \-msse3 \-mssse3 \-msse4.1 \-msse4.2 \-msse4 \-mavx
-\&\-maes \-mpclmul \-mfsgsbase \-mrdrnd \-mf16c \-mfused\-madd
-\&\-msse4a \-m3dnow \-mpopcnt \-mabm \-mbmi \-mtbm \-mfma4 \-mxop \-mlwp
-\&\-mthreads \-mno\-align\-stringops \-minline\-all\-stringops
-\&\-minline\-stringops\-dynamically \-mstringop\-strategy=\fR\fIalg\fR
-\&\fB\-mpush\-args \-maccumulate\-outgoing\-args \-m128bit\-long\-double
-\&\-m96bit\-long\-double \-mregparm=\fR\fInum\fR \fB\-msseregparm
-\&\-mveclibabi=\fR\fItype\fR \fB\-mvect8\-ret\-in\-mem
-\&\-mpc32 \-mpc64 \-mpc80 \-mstackrealign
-\&\-momit\-leaf\-frame\-pointer \-mno\-red\-zone \-mno\-tls\-direct\-seg\-refs
-\&\-mcmodel=\fR\fIcode-model\fR \fB\-mabi=\fR\fIname\fR
-\&\fB\-m32 \-m64 \-mlarge\-data\-threshold=\fR\fInum\fR
-\&\fB\-msse2avx \-mfentry \-m8bit\-idiv
-\&\-mavx256\-split\-unaligned\-load \-mavx256\-split\-unaligned\-store\fR
-.Sp
-\&\fIi386 and x86\-64 Windows Options\fR
-\&\fB\-mconsole \-mcygwin \-mno\-cygwin \-mdll
-\&\-mnop\-fun\-dllimport \-mthread
-\&\-municode \-mwin32 \-mwindows \-fno\-set\-stack\-executable\fR
-.Sp
-\&\fI\s-1IA\-64\s0 Options\fR
-\&\fB\-mbig\-endian \-mlittle\-endian \-mgnu\-as \-mgnu\-ld \-mno\-pic
-\&\-mvolatile\-asm\-stop \-mregister\-names \-msdata \-mno\-sdata
-\&\-mconstant\-gp \-mauto\-pic \-mfused\-madd
-\&\-minline\-float\-divide\-min\-latency
-\&\-minline\-float\-divide\-max\-throughput
-\&\-mno\-inline\-float\-divide
-\&\-minline\-int\-divide\-min\-latency
-\&\-minline\-int\-divide\-max\-throughput
-\&\-mno\-inline\-int\-divide
-\&\-minline\-sqrt\-min\-latency \-minline\-sqrt\-max\-throughput
-\&\-mno\-inline\-sqrt
-\&\-mdwarf2\-asm \-mearly\-stop\-bits
-\&\-mfixed\-range=\fR\fIregister-range\fR \fB\-mtls\-size=\fR\fItls-size\fR
-\&\fB\-mtune=\fR\fIcpu-type\fR \fB\-milp32 \-mlp64
-\&\-msched\-br\-data\-spec \-msched\-ar\-data\-spec \-msched\-control\-spec
-\&\-msched\-br\-in\-data\-spec \-msched\-ar\-in\-data\-spec \-msched\-in\-control\-spec
-\&\-msched\-spec\-ldc \-msched\-spec\-control\-ldc
-\&\-msched\-prefer\-non\-data\-spec\-insns \-msched\-prefer\-non\-control\-spec\-insns
-\&\-msched\-stop\-bits\-after\-every\-cycle \-msched\-count\-spec\-in\-critical\-path
-\&\-msel\-sched\-dont\-check\-control\-spec \-msched\-fp\-mem\-deps\-zero\-cost
-\&\-msched\-max\-memory\-insns\-hard\-limit \-msched\-max\-memory\-insns=\fR\fImax-insns\fR
-.Sp
-\&\fI\s-1IA\-64/VMS\s0 Options\fR
-\&\fB\-mvms\-return\-codes \-mdebug\-main=\fR\fIprefix\fR \fB\-mmalloc64\fR
-.Sp
-\&\fI\s-1LM32\s0 Options\fR
-\&\fB\-mbarrel\-shift\-enabled \-mdivide\-enabled \-mmultiply\-enabled
-\&\-msign\-extend\-enabled \-muser\-enabled\fR
-.Sp
-\&\fIM32R/D Options\fR
-\&\fB\-m32r2 \-m32rx \-m32r
-\&\-mdebug
-\&\-malign\-loops \-mno\-align\-loops
-\&\-missue\-rate=\fR\fInumber\fR
-\&\fB\-mbranch\-cost=\fR\fInumber\fR
-\&\fB\-mmodel=\fR\fIcode-size-model-type\fR
-\&\fB\-msdata=\fR\fIsdata-type\fR
-\&\fB\-mno\-flush\-func \-mflush\-func=\fR\fIname\fR
-\&\fB\-mno\-flush\-trap \-mflush\-trap=\fR\fInumber\fR
-\&\fB\-G\fR \fInum\fR
-.Sp
-\&\fIM32C Options\fR
-\&\fB\-mcpu=\fR\fIcpu\fR \fB\-msim \-memregs=\fR\fInumber\fR
-.Sp
-\&\fIM680x0 Options\fR
-\&\fB\-march=\fR\fIarch\fR \fB\-mcpu=\fR\fIcpu\fR \fB\-mtune=\fR\fItune\fR
-\&\fB\-m68000 \-m68020 \-m68020\-40 \-m68020\-60 \-m68030 \-m68040
-\&\-m68060 \-mcpu32 \-m5200 \-m5206e \-m528x \-m5307 \-m5407
-\&\-mcfv4e \-mbitfield \-mno\-bitfield \-mc68000 \-mc68020
-\&\-mnobitfield \-mrtd \-mno\-rtd \-mdiv \-mno\-div \-mshort
-\&\-mno\-short \-mhard\-float \-m68881 \-msoft\-float \-mpcrel
-\&\-malign\-int \-mstrict\-align \-msep\-data \-mno\-sep\-data
-\&\-mshared\-library\-id=n \-mid\-shared\-library \-mno\-id\-shared\-library
-\&\-mxgot \-mno\-xgot\fR
-.Sp
-\&\fIM68hc1x Options\fR
-\&\fB\-m6811 \-m6812 \-m68hc11 \-m68hc12 \-m68hcs12
-\&\-mauto\-incdec \-minmax \-mlong\-calls \-mshort
-\&\-msoft\-reg\-count=\fR\fIcount\fR
-.Sp
-\&\fIMCore Options\fR
-\&\fB\-mhardlit \-mno\-hardlit \-mdiv \-mno\-div \-mrelax\-immediates
-\&\-mno\-relax\-immediates \-mwide\-bitfields \-mno\-wide\-bitfields
-\&\-m4byte\-functions \-mno\-4byte\-functions \-mcallgraph\-data
-\&\-mno\-callgraph\-data \-mslow\-bytes \-mno\-slow\-bytes \-mno\-lsim
-\&\-mlittle\-endian \-mbig\-endian \-m210 \-m340 \-mstack\-increment\fR
-.Sp
-\&\fIMeP Options\fR
-\&\fB\-mabsdiff \-mall\-opts \-maverage \-mbased=\fR\fIn\fR \fB\-mbitops
-\&\-mc=\fR\fIn\fR \fB\-mclip \-mconfig=\fR\fIname\fR \fB\-mcop \-mcop32 \-mcop64 \-mivc2
-\&\-mdc \-mdiv \-meb \-mel \-mio\-volatile \-ml \-mleadz \-mm \-mminmax
-\&\-mmult \-mno\-opts \-mrepeat \-ms \-msatur \-msdram \-msim \-msimnovec \-mtf
-\&\-mtiny=\fR\fIn\fR
-.Sp
-\&\fIMicroBlaze Options\fR
-\&\fB\-msoft\-float \-mhard\-float \-msmall\-divides \-mcpu=\fR\fIcpu\fR
-\&\fB\-mmemcpy \-mxl\-soft\-mul \-mxl\-soft\-div \-mxl\-barrel\-shift
-\&\-mxl\-pattern\-compare \-mxl\-stack\-check \-mxl\-gp\-opt \-mno\-clearbss
-\&\-mxl\-multiply\-high \-mxl\-float\-convert \-mxl\-float\-sqrt
-\&\-mxl\-mode\-\fR\fIapp-model\fR
-.Sp
-\&\fI\s-1MIPS\s0 Options\fR
-\&\fB\-EL \-EB \-march=\fR\fIarch\fR \fB\-mtune=\fR\fIarch\fR
-\&\fB\-mips1 \-mips2 \-mips3 \-mips4 \-mips32 \-mips32r2
-\&\-mips64 \-mips64r2
-\&\-mips16 \-mno\-mips16 \-mflip\-mips16
-\&\-minterlink\-mips16 \-mno\-interlink\-mips16
-\&\-mabi=\fR\fIabi\fR \fB\-mabicalls \-mno\-abicalls
-\&\-mshared \-mno\-shared \-mplt \-mno\-plt \-mxgot \-mno\-xgot
-\&\-mgp32 \-mgp64 \-mfp32 \-mfp64 \-mhard\-float \-msoft\-float
-\&\-msingle\-float \-mdouble\-float \-mdsp \-mno\-dsp \-mdspr2 \-mno\-dspr2
-\&\-mfpu=\fR\fIfpu-type\fR
-\&\fB\-msmartmips \-mno\-smartmips
-\&\-mpaired\-single \-mno\-paired\-single \-mdmx \-mno\-mdmx
-\&\-mips3d \-mno\-mips3d \-mmt \-mno\-mt \-mllsc \-mno\-llsc
-\&\-mlong64 \-mlong32 \-msym32 \-mno\-sym32
-\&\-G\fR\fInum\fR \fB\-mlocal\-sdata \-mno\-local\-sdata
-\&\-mextern\-sdata \-mno\-extern\-sdata \-mgpopt \-mno\-gopt
-\&\-membedded\-data \-mno\-embedded\-data
-\&\-muninit\-const\-in\-rodata \-mno\-uninit\-const\-in\-rodata
-\&\-mcode\-readable=\fR\fIsetting\fR
-\&\fB\-msplit\-addresses \-mno\-split\-addresses
-\&\-mexplicit\-relocs \-mno\-explicit\-relocs
-\&\-mcheck\-zero\-division \-mno\-check\-zero\-division
-\&\-mdivide\-traps \-mdivide\-breaks
-\&\-mmemcpy \-mno\-memcpy \-mlong\-calls \-mno\-long\-calls
-\&\-mmad \-mno\-mad \-mfused\-madd \-mno\-fused\-madd \-nocpp
-\&\-mfix\-r4000 \-mno\-fix\-r4000 \-mfix\-r4400 \-mno\-fix\-r4400
-\&\-mfix\-r10000 \-mno\-fix\-r10000 \-mfix\-vr4120 \-mno\-fix\-vr4120
-\&\-mfix\-vr4130 \-mno\-fix\-vr4130 \-mfix\-sb1 \-mno\-fix\-sb1
-\&\-mflush\-func=\fR\fIfunc\fR \fB\-mno\-flush\-func
-\&\-mbranch\-cost=\fR\fInum\fR \fB\-mbranch\-likely \-mno\-branch\-likely
-\&\-mfp\-exceptions \-mno\-fp\-exceptions
-\&\-mvr4130\-align \-mno\-vr4130\-align \-msynci \-mno\-synci
-\&\-mrelax\-pic\-calls \-mno\-relax\-pic\-calls \-mmcount\-ra\-address\fR
-.Sp
-\&\fI\s-1MMIX\s0 Options\fR
-\&\fB\-mlibfuncs \-mno\-libfuncs \-mepsilon \-mno\-epsilon \-mabi=gnu
-\&\-mabi=mmixware \-mzero\-extend \-mknuthdiv \-mtoplevel\-symbols
-\&\-melf \-mbranch\-predict \-mno\-branch\-predict \-mbase\-addresses
-\&\-mno\-base\-addresses \-msingle\-exit \-mno\-single\-exit\fR
-.Sp
-\&\fI\s-1MN10300\s0 Options\fR
-\&\fB\-mmult\-bug \-mno\-mult\-bug
-\&\-mno\-am33 \-mam33 \-mam33\-2 \-mam34
-\&\-mtune=\fR\fIcpu-type\fR
-\&\fB\-mreturn\-pointer\-on\-d0
-\&\-mno\-crt0 \-mrelax \-mliw\fR
-.Sp
-\&\fI\s-1PDP\-11\s0 Options\fR
-\&\fB\-mfpu \-msoft\-float \-mac0 \-mno\-ac0 \-m40 \-m45 \-m10
-\&\-mbcopy \-mbcopy\-builtin \-mint32 \-mno\-int16
-\&\-mint16 \-mno\-int32 \-mfloat32 \-mno\-float64
-\&\-mfloat64 \-mno\-float32 \-mabshi \-mno\-abshi
-\&\-mbranch\-expensive \-mbranch\-cheap
-\&\-munix\-asm \-mdec\-asm\fR
-.Sp
-\&\fIpicoChip Options\fR
-\&\fB\-mae=\fR\fIae_type\fR \fB\-mvliw\-lookahead=\fR\fIN\fR
-\&\fB\-msymbol\-as\-address \-mno\-inefficient\-warnings\fR
-.Sp
-\&\fIPowerPC Options\fR
-See \s-1RS/6000\s0 and PowerPC Options.
-.Sp
-\&\fI\s-1RS/6000\s0 and PowerPC Options\fR
-\&\fB\-mcpu=\fR\fIcpu-type\fR
-\&\fB\-mtune=\fR\fIcpu-type\fR
-\&\fB\-mcmodel=\fR\fIcode-model\fR
-\&\fB\-mpower \-mno\-power \-mpower2 \-mno\-power2
-\&\-mpowerpc \-mpowerpc64 \-mno\-powerpc
-\&\-maltivec \-mno\-altivec
-\&\-mpowerpc\-gpopt \-mno\-powerpc\-gpopt
-\&\-mpowerpc\-gfxopt \-mno\-powerpc\-gfxopt
-\&\-mmfcrf \-mno\-mfcrf \-mpopcntb \-mno\-popcntb \-mpopcntd \-mno\-popcntd
-\&\-mfprnd \-mno\-fprnd
-\&\-mcmpb \-mno\-cmpb \-mmfpgpr \-mno\-mfpgpr \-mhard\-dfp \-mno\-hard\-dfp
-\&\-mnew\-mnemonics \-mold\-mnemonics
-\&\-mfull\-toc \-mminimal\-toc \-mno\-fp\-in\-toc \-mno\-sum\-in\-toc
-\&\-m64 \-m32 \-mxl\-compat \-mno\-xl\-compat \-mpe
-\&\-malign\-power \-malign\-natural
-\&\-msoft\-float \-mhard\-float \-mmultiple \-mno\-multiple
-\&\-msingle\-float \-mdouble\-float \-msimple\-fpu
-\&\-mstring \-mno\-string \-mupdate \-mno\-update
-\&\-mavoid\-indexed\-addresses \-mno\-avoid\-indexed\-addresses
-\&\-mfused\-madd \-mno\-fused\-madd \-mbit\-align \-mno\-bit\-align
-\&\-mstrict\-align \-mno\-strict\-align \-mrelocatable
-\&\-mno\-relocatable \-mrelocatable\-lib \-mno\-relocatable\-lib
-\&\-mtoc \-mno\-toc \-mlittle \-mlittle\-endian \-mbig \-mbig\-endian
-\&\-mdynamic\-no\-pic \-maltivec \-mswdiv \-msingle\-pic\-base
-\&\-mprioritize\-restricted\-insns=\fR\fIpriority\fR
-\&\fB\-msched\-costly\-dep=\fR\fIdependence_type\fR
-\&\fB\-minsert\-sched\-nops=\fR\fIscheme\fR
-\&\fB\-mcall\-sysv \-mcall\-netbsd
-\&\-maix\-struct\-return \-msvr4\-struct\-return
-\&\-mabi=\fR\fIabi-type\fR \fB\-msecure\-plt \-mbss\-plt
-\&\-mblock\-move\-inline\-limit=\fR\fInum\fR
-\&\fB\-misel \-mno\-isel
-\&\-misel=yes \-misel=no
-\&\-mspe \-mno\-spe
-\&\-mspe=yes \-mspe=no
-\&\-mpaired
-\&\-mgen\-cell\-microcode \-mwarn\-cell\-microcode
-\&\-mvrsave \-mno\-vrsave
-\&\-mmulhw \-mno\-mulhw
-\&\-mdlmzb \-mno\-dlmzb
-\&\-mfloat\-gprs=yes \-mfloat\-gprs=no \-mfloat\-gprs=single \-mfloat\-gprs=double
-\&\-mprototype \-mno\-prototype
-\&\-msim \-mmvme \-mads \-myellowknife \-memb \-msdata
-\&\-msdata=\fR\fIopt\fR \fB\-mvxworks \-G\fR \fInum\fR \fB\-pthread
-\&\-mrecip \-mrecip=\fR\fIopt\fR \fB\-mno\-recip \-mrecip\-precision
-\&\-mno\-recip\-precision
-\&\-mveclibabi=\fR\fItype\fR \fB\-mfriz \-mno\-friz\fR
-.Sp
-\&\fI\s-1RX\s0 Options\fR
-\&\fB\-m64bit\-doubles \-m32bit\-doubles \-fpu \-nofpu
-\&\-mcpu=
-\&\-mbig\-endian\-data \-mlittle\-endian\-data
-\&\-msmall\-data
-\&\-msim \-mno\-sim
-\&\-mas100\-syntax \-mno\-as100\-syntax
-\&\-mrelax
-\&\-mmax\-constant\-size=
-\&\-mint\-register=
-\&\-msave\-acc\-in\-interrupts\fR
-.Sp
-\&\fIS/390 and zSeries Options\fR
-\&\fB\-mtune=\fR\fIcpu-type\fR \fB\-march=\fR\fIcpu-type\fR
-\&\fB\-mhard\-float \-msoft\-float \-mhard\-dfp \-mno\-hard\-dfp
-\&\-mlong\-double\-64 \-mlong\-double\-128
-\&\-mbackchain \-mno\-backchain \-mpacked\-stack \-mno\-packed\-stack
-\&\-msmall\-exec \-mno\-small\-exec \-mmvcle \-mno\-mvcle
-\&\-m64 \-m31 \-mdebug \-mno\-debug \-mesa \-mzarch
-\&\-mtpf\-trace \-mno\-tpf\-trace \-mfused\-madd \-mno\-fused\-madd
-\&\-mwarn\-framesize \-mwarn\-dynamicstack \-mstack\-size \-mstack\-guard\fR
-.Sp
-\&\fIScore Options\fR
-\&\fB\-meb \-mel
-\&\-mnhwloop
-\&\-muls
-\&\-mmac
-\&\-mscore5 \-mscore5u \-mscore7 \-mscore7d\fR
-.Sp
-\&\fI\s-1SH\s0 Options\fR
-\&\fB\-m1 \-m2 \-m2e
-\&\-m2a\-nofpu \-m2a\-single\-only \-m2a\-single \-m2a
-\&\-m3 \-m3e
-\&\-m4\-nofpu \-m4\-single\-only \-m4\-single \-m4
-\&\-m4a\-nofpu \-m4a\-single\-only \-m4a\-single \-m4a \-m4al
-\&\-m5\-64media \-m5\-64media\-nofpu
-\&\-m5\-32media \-m5\-32media\-nofpu
-\&\-m5\-compact \-m5\-compact\-nofpu
-\&\-mb \-ml \-mdalign \-mrelax
-\&\-mbigtable \-mfmovd \-mhitachi \-mrenesas \-mno\-renesas \-mnomacsave
-\&\-mieee \-mbitops \-misize \-minline\-ic_invalidate \-mpadstruct \-mspace
-\&\-mprefergot \-musermode \-multcost=\fR\fInumber\fR \fB\-mdiv=\fR\fIstrategy\fR
-\&\fB\-mdivsi3_libfunc=\fR\fIname\fR \fB\-mfixed\-range=\fR\fIregister-range\fR
-\&\fB\-madjust\-unroll \-mindexed\-addressing \-mgettrcost=\fR\fInumber\fR \fB\-mpt\-fixed
-\&\-maccumulate\-outgoing\-args \-minvalid\-symbols\fR
-.Sp
-\&\fISolaris 2 Options\fR
-\&\fB\-mimpure\-text \-mno\-impure\-text
-\&\-threads \-pthreads \-pthread\fR
-.Sp
-\&\fI\s-1SPARC\s0 Options\fR
-\&\fB\-mcpu=\fR\fIcpu-type\fR
-\&\fB\-mtune=\fR\fIcpu-type\fR
-\&\fB\-mcmodel=\fR\fIcode-model\fR
-\&\fB\-m32 \-m64 \-mapp\-regs \-mno\-app\-regs
-\&\-mfaster\-structs \-mno\-faster\-structs
-\&\-mfpu \-mno\-fpu \-mhard\-float \-msoft\-float
-\&\-mhard\-quad\-float \-msoft\-quad\-float
-\&\-mlittle\-endian
-\&\-mstack\-bias \-mno\-stack\-bias
-\&\-munaligned\-doubles \-mno\-unaligned\-doubles
-\&\-mv8plus \-mno\-v8plus \-mvis \-mno\-vis
-\&\-mfix\-at697f\fR
-.Sp
-\&\fI\s-1SPU\s0 Options\fR
-\&\fB\-mwarn\-reloc \-merror\-reloc
-\&\-msafe\-dma \-munsafe\-dma
-\&\-mbranch\-hints
-\&\-msmall\-mem \-mlarge\-mem \-mstdmain
-\&\-mfixed\-range=\fR\fIregister-range\fR
-\&\fB\-mea32 \-mea64
-\&\-maddress\-space\-conversion \-mno\-address\-space\-conversion
-\&\-mcache\-size=\fR\fIcache-size\fR
-\&\fB\-matomic\-updates \-mno\-atomic\-updates\fR
-.Sp
-\&\fISystem V Options\fR
-\&\fB\-Qy \-Qn \-YP,\fR\fIpaths\fR \fB\-Ym,\fR\fIdir\fR
-.Sp
-\&\fIV850 Options\fR
-\&\fB\-mlong\-calls \-mno\-long\-calls \-mep \-mno\-ep
-\&\-mprolog\-function \-mno\-prolog\-function \-mspace
-\&\-mtda=\fR\fIn\fR \fB\-msda=\fR\fIn\fR \fB\-mzda=\fR\fIn\fR
-\&\fB\-mapp\-regs \-mno\-app\-regs
-\&\-mdisable\-callt \-mno\-disable\-callt
-\&\-mv850e2v3
-\&\-mv850e2
-\&\-mv850e1 \-mv850es
-\&\-mv850e
-\&\-mv850 \-mbig\-switch\fR
-.Sp
-\&\fI\s-1VAX\s0 Options\fR
-\&\fB\-mg \-mgnu \-munix\fR
-.Sp
-\&\fIVxWorks Options\fR
-\&\fB\-mrtp \-non\-static \-Bstatic \-Bdynamic
-\&\-Xbind\-lazy \-Xbind\-now\fR
-.Sp
-\&\fIx86\-64 Options\fR
-See i386 and x86\-64 Options.
-.Sp
-\&\fIXstormy16 Options\fR
-\&\fB\-msim\fR
-.Sp
-\&\fIXtensa Options\fR
-\&\fB\-mconst16 \-mno\-const16
-\&\-mfused\-madd \-mno\-fused\-madd
-\&\-mforce\-no\-pic
-\&\-mserialize\-volatile \-mno\-serialize\-volatile
-\&\-mtext\-section\-literals \-mno\-text\-section\-literals
-\&\-mtarget\-align \-mno\-target\-align
-\&\-mlongcalls \-mno\-longcalls\fR
-.Sp
-\&\fIzSeries Options\fR
-See S/390 and zSeries Options.
-.IP "\fICode Generation Options\fR" 4
-.IX Item "Code Generation Options"
-\&\fB\-fcall\-saved\-\fR\fIreg\fR \fB\-fcall\-used\-\fR\fIreg\fR
-\&\fB\-ffixed\-\fR\fIreg\fR \fB\-fexceptions
-\&\-fnon\-call\-exceptions \-funwind\-tables
-\&\-fasynchronous\-unwind\-tables
-\&\-finhibit\-size\-directive \-finstrument\-functions
-\&\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,...
-\&\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,...
-\&\-fno\-common \-fno\-ident
-\&\-fpcc\-struct\-return \-fpic \-fPIC \-fpie \-fPIE
-\&\-fno\-jump\-tables
-\&\-frecord\-gcc\-switches
-\&\-freg\-struct\-return \-fshort\-enums
-\&\-fshort\-double \-fshort\-wchar
-\&\-fverbose\-asm \-fpack\-struct[=\fR\fIn\fR\fB] \-fstack\-check
-\&\-fstack\-limit\-register=\fR\fIreg\fR \fB\-fstack\-limit\-symbol=\fR\fIsym\fR
-\&\fB\-fno\-stack\-limit \-fsplit\-stack
-\&\-fleading\-underscore \-ftls\-model=\fR\fImodel\fR
-\&\fB\-ftrapv \-fwrapv \-fbounds\-check
-\&\-fvisibility \-fstrict\-volatile\-bitfields\fR
-.SS "Options Controlling the Kind of Output"
-.IX Subsection "Options Controlling the Kind of Output"
-Compilation can involve up to four stages: preprocessing, compilation
-proper, assembly and linking, always in that order. \s-1GCC\s0 is capable of
-preprocessing and compiling several files either into several
-assembler input files, or into one assembler input file; then each
-assembler input file produces an object file, and linking combines all
-the object files (those newly compiled, and those specified as input)
-into an executable file.
-.PP
-For any given input file, the file name suffix determines what kind of
-compilation is done:
-.IP "\fIfile\fR\fB.c\fR" 4
-.IX Item "file.c"
-C source code which must be preprocessed.
-.IP "\fIfile\fR\fB.i\fR" 4
-.IX Item "file.i"
-C source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.ii\fR" 4
-.IX Item "file.ii"
-\&\*(C+ source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.m\fR" 4
-.IX Item "file.m"
-Objective-C source code. Note that you must link with the \fIlibobjc\fR
-library to make an Objective-C program work.
-.IP "\fIfile\fR\fB.mi\fR" 4
-.IX Item "file.mi"
-Objective-C source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.mm\fR" 4
-.IX Item "file.mm"
-.PD 0
-.IP "\fIfile\fR\fB.M\fR" 4
-.IX Item "file.M"
-.PD
-Objective\-\*(C+ source code. Note that you must link with the \fIlibobjc\fR
-library to make an Objective\-\*(C+ program work. Note that \fB.M\fR refers
-to a literal capital M.
-.IP "\fIfile\fR\fB.mii\fR" 4
-.IX Item "file.mii"
-Objective\-\*(C+ source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.h\fR" 4
-.IX Item "file.h"
-C, \*(C+, Objective-C or Objective\-\*(C+ header file to be turned into a
-precompiled header (default), or C, \*(C+ header file to be turned into an
-Ada spec (via the \fB\-fdump\-ada\-spec\fR switch).
-.IP "\fIfile\fR\fB.cc\fR" 4
-.IX Item "file.cc"
-.PD 0
-.IP "\fIfile\fR\fB.cp\fR" 4
-.IX Item "file.cp"
-.IP "\fIfile\fR\fB.cxx\fR" 4
-.IX Item "file.cxx"
-.IP "\fIfile\fR\fB.cpp\fR" 4
-.IX Item "file.cpp"
-.IP "\fIfile\fR\fB.CPP\fR" 4
-.IX Item "file.CPP"
-.IP "\fIfile\fR\fB.c++\fR" 4
-.IX Item "file.c++"
-.IP "\fIfile\fR\fB.C\fR" 4
-.IX Item "file.C"
-.PD
-\&\*(C+ source code which must be preprocessed. Note that in \fB.cxx\fR,
-the last two letters must both be literally \fBx\fR. Likewise,
-\&\fB.C\fR refers to a literal capital C.
-.IP "\fIfile\fR\fB.mm\fR" 4
-.IX Item "file.mm"
-.PD 0
-.IP "\fIfile\fR\fB.M\fR" 4
-.IX Item "file.M"
-.PD
-Objective\-\*(C+ source code which must be preprocessed.
-.IP "\fIfile\fR\fB.mii\fR" 4
-.IX Item "file.mii"
-Objective\-\*(C+ source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.hh\fR" 4
-.IX Item "file.hh"
-.PD 0
-.IP "\fIfile\fR\fB.H\fR" 4
-.IX Item "file.H"
-.IP "\fIfile\fR\fB.hp\fR" 4
-.IX Item "file.hp"
-.IP "\fIfile\fR\fB.hxx\fR" 4
-.IX Item "file.hxx"
-.IP "\fIfile\fR\fB.hpp\fR" 4
-.IX Item "file.hpp"
-.IP "\fIfile\fR\fB.HPP\fR" 4
-.IX Item "file.HPP"
-.IP "\fIfile\fR\fB.h++\fR" 4
-.IX Item "file.h++"
-.IP "\fIfile\fR\fB.tcc\fR" 4
-.IX Item "file.tcc"
-.PD
-\&\*(C+ header file to be turned into a precompiled header or Ada spec.
-.IP "\fIfile\fR\fB.f\fR" 4
-.IX Item "file.f"
-.PD 0
-.IP "\fIfile\fR\fB.for\fR" 4
-.IX Item "file.for"
-.IP "\fIfile\fR\fB.ftn\fR" 4
-.IX Item "file.ftn"
-.PD
-Fixed form Fortran source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.F\fR" 4
-.IX Item "file.F"
-.PD 0
-.IP "\fIfile\fR\fB.FOR\fR" 4
-.IX Item "file.FOR"
-.IP "\fIfile\fR\fB.fpp\fR" 4
-.IX Item "file.fpp"
-.IP "\fIfile\fR\fB.FPP\fR" 4
-.IX Item "file.FPP"
-.IP "\fIfile\fR\fB.FTN\fR" 4
-.IX Item "file.FTN"
-.PD
-Fixed form Fortran source code which must be preprocessed (with the traditional
-preprocessor).
-.IP "\fIfile\fR\fB.f90\fR" 4
-.IX Item "file.f90"
-.PD 0
-.IP "\fIfile\fR\fB.f95\fR" 4
-.IX Item "file.f95"
-.IP "\fIfile\fR\fB.f03\fR" 4
-.IX Item "file.f03"
-.IP "\fIfile\fR\fB.f08\fR" 4
-.IX Item "file.f08"
-.PD
-Free form Fortran source code which should not be preprocessed.
-.IP "\fIfile\fR\fB.F90\fR" 4
-.IX Item "file.F90"
-.PD 0
-.IP "\fIfile\fR\fB.F95\fR" 4
-.IX Item "file.F95"
-.IP "\fIfile\fR\fB.F03\fR" 4
-.IX Item "file.F03"
-.IP "\fIfile\fR\fB.F08\fR" 4
-.IX Item "file.F08"
-.PD
-Free form Fortran source code which must be preprocessed (with the
-traditional preprocessor).
-.IP "\fIfile\fR\fB.go\fR" 4
-.IX Item "file.go"
-Go source code.
-.IP "\fIfile\fR\fB.ads\fR" 4
-.IX Item "file.ads"
-Ada source code file which contains a library unit declaration (a
-declaration of a package, subprogram, or generic, or a generic
-instantiation), or a library unit renaming declaration (a package,
-generic, or subprogram renaming declaration). Such files are also
-called \fIspecs\fR.
-.IP "\fIfile\fR\fB.adb\fR" 4
-.IX Item "file.adb"
-Ada source code file containing a library unit body (a subprogram or
-package body). Such files are also called \fIbodies\fR.
-.IP "\fIfile\fR\fB.s\fR" 4
-.IX Item "file.s"
-Assembler code.
-.IP "\fIfile\fR\fB.S\fR" 4
-.IX Item "file.S"
-.PD 0
-.IP "\fIfile\fR\fB.sx\fR" 4
-.IX Item "file.sx"
-.PD
-Assembler code which must be preprocessed.
-.IP "\fIother\fR" 4
-.IX Item "other"
-An object file to be fed straight into linking.
-Any file name with no recognized suffix is treated this way.
-.PP
-You can specify the input language explicitly with the \fB\-x\fR option:
-.IP "\fB\-x\fR \fIlanguage\fR" 4
-.IX Item "-x language"
-Specify explicitly the \fIlanguage\fR for the following input files
-(rather than letting the compiler choose a default based on the file
-name suffix). This option applies to all following input files until
-the next \fB\-x\fR option. Possible values for \fIlanguage\fR are:
-.Sp
-.Vb 9
-\& c c\-header cpp\-output
-\& c++ c++\-header c++\-cpp\-output
-\& objective\-c objective\-c\-header objective\-c\-cpp\-output
-\& objective\-c++ objective\-c++\-header objective\-c++\-cpp\-output
-\& assembler assembler\-with\-cpp
-\& ada
-\& f77 f77\-cpp\-input f95 f95\-cpp\-input
-\& go
-\& java
-.Ve
-.IP "\fB\-x none\fR" 4
-.IX Item "-x none"
-Turn off any specification of a language, so that subsequent files are
-handled according to their file name suffixes (as they are if \fB\-x\fR
-has not been used at all).
-.IP "\fB\-pass\-exit\-codes\fR" 4
-.IX Item "-pass-exit-codes"
-Normally the \fBgcc\fR program will exit with the code of 1 if any
-phase of the compiler returns a non-success return code. If you specify
-\&\fB\-pass\-exit\-codes\fR, the \fBgcc\fR program will instead return with
-numerically highest error produced by any phase that returned an error
-indication. The C, \*(C+, and Fortran frontends return 4, if an internal
-compiler error is encountered.
-.PP
-If you only want some of the stages of compilation, you can use
-\&\fB\-x\fR (or filename suffixes) to tell \fBgcc\fR where to start, and
-one of the options \fB\-c\fR, \fB\-S\fR, or \fB\-E\fR to say where
-\&\fBgcc\fR is to stop. Note that some combinations (for example,
-\&\fB\-x cpp-output \-E\fR) instruct \fBgcc\fR to do nothing at all.
-.IP "\fB\-c\fR" 4
-.IX Item "-c"
-Compile or assemble the source files, but do not link. The linking
-stage simply is not done. The ultimate output is in the form of an
-object file for each source file.
-.Sp
-By default, the object file name for a source file is made by replacing
-the suffix \fB.c\fR, \fB.i\fR, \fB.s\fR, etc., with \fB.o\fR.
-.Sp
-Unrecognized input files, not requiring compilation or assembly, are
-ignored.
-.IP "\fB\-S\fR" 4
-.IX Item "-S"
-Stop after the stage of compilation proper; do not assemble. The output
-is in the form of an assembler code file for each non-assembler input
-file specified.
-.Sp
-By default, the assembler file name for a source file is made by
-replacing the suffix \fB.c\fR, \fB.i\fR, etc., with \fB.s\fR.
-.Sp
-Input files that don't require compilation are ignored.
-.IP "\fB\-E\fR" 4
-.IX Item "-E"
-Stop after the preprocessing stage; do not run the compiler proper. The
-output is in the form of preprocessed source code, which is sent to the
-standard output.
-.Sp
-Input files which don't require preprocessing are ignored.
-.IP "\fB\-o\fR \fIfile\fR" 4
-.IX Item "-o file"
-Place output in file \fIfile\fR. This applies regardless to whatever
-sort of output is being produced, whether it be an executable file,
-an object file, an assembler file or preprocessed C code.
-.Sp
-If \fB\-o\fR is not specified, the default is to put an executable
-file in \fIa.out\fR, the object file for
-\&\fI\fIsource\fI.\fIsuffix\fI\fR in \fI\fIsource\fI.o\fR, its
-assembler file in \fI\fIsource\fI.s\fR, a precompiled header file in
-\&\fI\fIsource\fI.\fIsuffix\fI.gch\fR, and all preprocessed C source on
-standard output.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-Print (on standard error output) the commands executed to run the stages
-of compilation. Also print the version number of the compiler driver
-program and of the preprocessor and the compiler proper.
-.IP "\fB\-###\fR" 4
-.IX Item "-###"
-Like \fB\-v\fR except the commands are not executed and arguments
-are quoted unless they contain only alphanumeric characters or \f(CW\*(C`./\-_\*(C'\fR.
-This is useful for shell scripts to capture the driver-generated command lines.
-.IP "\fB\-pipe\fR" 4
-.IX Item "-pipe"
-Use pipes rather than temporary files for communication between the
-various stages of compilation. This fails to work on some systems where
-the assembler is unable to read from a pipe; but the \s-1GNU\s0 assembler has
-no trouble.
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-Print (on the standard output) a description of the command line options
-understood by \fBgcc\fR. If the \fB\-v\fR option is also specified
-then \fB\-\-help\fR will also be passed on to the various processes
-invoked by \fBgcc\fR, so that they can display the command line options
-they accept. If the \fB\-Wextra\fR option has also been specified
-(prior to the \fB\-\-help\fR option), then command line options which
-have no documentation associated with them will also be displayed.
-.IP "\fB\-\-target\-help\fR" 4
-.IX Item "--target-help"
-Print (on the standard output) a description of target-specific command
-line options for each tool. For some targets extra target-specific
-information may also be printed.
-.IP "\fB\-\-help={\fR\fIclass\fR|[\fB^\fR]\fIqualifier\fR\fB}\fR[\fB,...\fR]" 4
-.IX Item "--help={class|[^]qualifier}[,...]"
-Print (on the standard output) a description of the command line
-options understood by the compiler that fit into all specified classes
-and qualifiers. These are the supported classes:
-.RS 4
-.IP "\fBoptimizers\fR" 4
-.IX Item "optimizers"
-This will display all of the optimization options supported by the
-compiler.
-.IP "\fBwarnings\fR" 4
-.IX Item "warnings"
-This will display all of the options controlling warning messages
-produced by the compiler.
-.IP "\fBtarget\fR" 4
-.IX Item "target"
-This will display target-specific options. Unlike the
-\&\fB\-\-target\-help\fR option however, target-specific options of the
-linker and assembler will not be displayed. This is because those
-tools do not currently support the extended \fB\-\-help=\fR syntax.
-.IP "\fBparams\fR" 4
-.IX Item "params"
-This will display the values recognized by the \fB\-\-param\fR
-option.
-.IP "\fIlanguage\fR" 4
-.IX Item "language"
-This will display the options supported for \fIlanguage\fR, where
-\&\fIlanguage\fR is the name of one of the languages supported in this
-version of \s-1GCC\s0.
-.IP "\fBcommon\fR" 4
-.IX Item "common"
-This will display the options that are common to all languages.
-.RE
-.RS 4
-.Sp
-These are the supported qualifiers:
-.IP "\fBundocumented\fR" 4
-.IX Item "undocumented"
-Display only those options which are undocumented.
-.IP "\fBjoined\fR" 4
-.IX Item "joined"
-Display options which take an argument that appears after an equal
-sign in the same continuous piece of text, such as:
-\&\fB\-\-help=target\fR.
-.IP "\fBseparate\fR" 4
-.IX Item "separate"
-Display options which take an argument that appears as a separate word
-following the original option, such as: \fB\-o output-file\fR.
-.RE
-.RS 4
-.Sp
-Thus for example to display all the undocumented target-specific
-switches supported by the compiler the following can be used:
-.Sp
-.Vb 1
-\& \-\-help=target,undocumented
-.Ve
-.Sp
-The sense of a qualifier can be inverted by prefixing it with the
-\&\fB^\fR character, so for example to display all binary warning
-options (i.e., ones that are either on or off and that do not take an
-argument), which have a description the following can be used:
-.Sp
-.Vb 1
-\& \-\-help=warnings,^joined,^undocumented
-.Ve
-.Sp
-The argument to \fB\-\-help=\fR should not consist solely of inverted
-qualifiers.
-.Sp
-Combining several classes is possible, although this usually
-restricts the output by so much that there is nothing to display. One
-case where it does work however is when one of the classes is
-\&\fItarget\fR. So for example to display all the target-specific
-optimization options the following can be used:
-.Sp
-.Vb 1
-\& \-\-help=target,optimizers
-.Ve
-.Sp
-The \fB\-\-help=\fR option can be repeated on the command line. Each
-successive use will display its requested class of options, skipping
-those that have already been displayed.
-.Sp
-If the \fB\-Q\fR option appears on the command line before the
-\&\fB\-\-help=\fR option, then the descriptive text displayed by
-\&\fB\-\-help=\fR is changed. Instead of describing the displayed
-options, an indication is given as to whether the option is enabled,
-disabled or set to a specific value (assuming that the compiler
-knows this at the point where the \fB\-\-help=\fR option is used).
-.Sp
-Here is a truncated example from the \s-1ARM\s0 port of \fBgcc\fR:
-.Sp
-.Vb 5
-\& % gcc \-Q \-mabi=2 \-\-help=target \-c
-\& The following options are target specific:
-\& \-mabi= 2
-\& \-mabort\-on\-noreturn [disabled]
-\& \-mapcs [disabled]
-.Ve
-.Sp
-The output is sensitive to the effects of previous command line
-options, so for example it is possible to find out which optimizations
-are enabled at \fB\-O2\fR by using:
-.Sp
-.Vb 1
-\& \-Q \-O2 \-\-help=optimizers
-.Ve
-.Sp
-Alternatively you can discover which binary optimizations are enabled
-by \fB\-O3\fR by using:
-.Sp
-.Vb 3
-\& gcc \-c \-Q \-O3 \-\-help=optimizers > /tmp/O3\-opts
-\& gcc \-c \-Q \-O2 \-\-help=optimizers > /tmp/O2\-opts
-\& diff /tmp/O2\-opts /tmp/O3\-opts | grep enabled
-.Ve
-.RE
-.IP "\fB\-canonical\-prefixes\fR" 4
-.IX Item "-canonical-prefixes"
-Always expand any symbolic links, resolve references to \fB/../\fR
-or \fB/./\fR, and make the path absolute when generating a relative
-prefix.
-.IP "\fB\-no\-canonical\-prefixes\fR" 4
-.IX Item "-no-canonical-prefixes"
-Never expand any symbolic links, resolve references to \fB/../\fR
-or \fB/./\fR, or make the path absolute when generating a relative
-prefix. If neither \fB\-canonical\-prefixes\fR nor
-\&\fB\-nocanonical\-prefixes\fR is given, \s-1GCC\s0 tries to set an appropriate
-default by looking for a target-specific subdirectory alongside the
-directory containing the compiler driver.
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-Display the version number and copyrights of the invoked \s-1GCC\s0.
-.IP "\fB\-wrapper\fR" 4
-.IX Item "-wrapper"
-Invoke all subcommands under a wrapper program. The name of the
-wrapper program and its parameters are passed as a comma separated
-list.
-.Sp
-.Vb 1
-\& gcc \-c t.c \-wrapper gdb,\-\-args
-.Ve
-.Sp
-This will invoke all subprograms of \fBgcc\fR under
-\&\fBgdb \-\-args\fR, thus the invocation of \fBcc1\fR will be
-\&\fBgdb \-\-args cc1 ...\fR.
-.IP "\fB\-fplugin=\fR\fIname\fR\fB.so\fR" 4
-.IX Item "-fplugin=name.so"
-Load the plugin code in file \fIname\fR.so, assumed to be a
-shared object to be dlopen'd by the compiler. The base name of
-the shared object file is used to identify the plugin for the
-purposes of argument parsing (See
-\&\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR below).
-Each plugin should define the callback functions specified in the
-Plugins \s-1API\s0.
-.IP "\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR" 4
-.IX Item "-fplugin-arg-name-key=value"
-Define an argument called \fIkey\fR with a value of \fIvalue\fR
-for the plugin called \fIname\fR.
-.IP "\fB\-fdump\-ada\-spec\fR[\fB\-slim\fR]" 4
-.IX Item "-fdump-ada-spec[-slim]"
-For C and \*(C+ source and include files, generate corresponding Ada
-specs.
-.IP "\fB\-fdump\-go\-spec=\fR\fIfile\fR" 4
-.IX Item "-fdump-go-spec=file"
-For input files in any language, generate corresponding Go
-declarations in \fIfile\fR. This generates Go \f(CW\*(C`const\*(C'\fR,
-\&\f(CW\*(C`type\*(C'\fR, \f(CW\*(C`var\*(C'\fR, and \f(CW\*(C`func\*(C'\fR declarations which may be a
-useful way to start writing a Go interface to code written in some
-other language.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SS "Compiling \*(C+ Programs"
-.IX Subsection "Compiling Programs"
-\&\*(C+ source files conventionally use one of the suffixes \fB.C\fR,
-\&\fB.cc\fR, \fB.cpp\fR, \fB.CPP\fR, \fB.c++\fR, \fB.cp\fR, or
-\&\fB.cxx\fR; \*(C+ header files often use \fB.hh\fR, \fB.hpp\fR,
-\&\fB.H\fR, or (for shared template code) \fB.tcc\fR; and
-preprocessed \*(C+ files use the suffix \fB.ii\fR. \s-1GCC\s0 recognizes
-files with these names and compiles them as \*(C+ programs even if you
-call the compiler the same way as for compiling C programs (usually
-with the name \fBgcc\fR).
-.PP
-However, the use of \fBgcc\fR does not add the \*(C+ library.
-\&\fBg++\fR is a program that calls \s-1GCC\s0 and treats \fB.c\fR,
-\&\fB.h\fR and \fB.i\fR files as \*(C+ source files instead of C source
-files unless \fB\-x\fR is used, and automatically specifies linking
-against the \*(C+ library. This program is also useful when
-precompiling a C header file with a \fB.h\fR extension for use in \*(C+
-compilations. On many systems, \fBg++\fR is also installed with
-the name \fBc++\fR.
-.PP
-When you compile \*(C+ programs, you may specify many of the same
-command-line options that you use for compiling programs in any
-language; or command-line options meaningful for C and related
-languages; or options that are meaningful only for \*(C+ programs.
-.SS "Options Controlling C Dialect"
-.IX Subsection "Options Controlling C Dialect"
-The following options control the dialect of C (or languages derived
-from C, such as \*(C+, Objective-C and Objective\-\*(C+) that the compiler
-accepts:
-.IP "\fB\-ansi\fR" 4
-.IX Item "-ansi"
-In C mode, this is equivalent to \fB\-std=c90\fR. In \*(C+ mode, it is
-equivalent to \fB\-std=c++98\fR.
-.Sp
-This turns off certain features of \s-1GCC\s0 that are incompatible with \s-1ISO\s0
-C90 (when compiling C code), or of standard \*(C+ (when compiling \*(C+ code),
-such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, and
-predefined macros such as \f(CW\*(C`unix\*(C'\fR and \f(CW\*(C`vax\*(C'\fR that identify the
-type of system you are using. It also enables the undesirable and
-rarely used \s-1ISO\s0 trigraph feature. For the C compiler,
-it disables recognition of \*(C+ style \fB//\fR comments as well as
-the \f(CW\*(C`inline\*(C'\fR keyword.
-.Sp
-The alternate keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_extension_\|_\*(C'\fR,
-\&\f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR continue to work despite
-\&\fB\-ansi\fR. You would not want to use them in an \s-1ISO\s0 C program, of
-course, but it is useful to put them in header files that might be included
-in compilations done with \fB\-ansi\fR. Alternate predefined macros
-such as \f(CW\*(C`_\|_unix_\|_\*(C'\fR and \f(CW\*(C`_\|_vax_\|_\*(C'\fR are also available, with or
-without \fB\-ansi\fR.
-.Sp
-The \fB\-ansi\fR option does not cause non-ISO programs to be
-rejected gratuitously. For that, \fB\-pedantic\fR is required in
-addition to \fB\-ansi\fR.
-.Sp
-The macro \f(CW\*(C`_\|_STRICT_ANSI_\|_\*(C'\fR is predefined when the \fB\-ansi\fR
-option is used. Some header files may notice this macro and refrain
-from declaring certain functions or defining certain macros that the
-\&\s-1ISO\s0 standard doesn't call for; this is to avoid interfering with any
-programs that might use these names for other things.
-.Sp
-Functions that would normally be built in but do not have semantics
-defined by \s-1ISO\s0 C (such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not built-in
-functions when \fB\-ansi\fR is used.
-.IP "\fB\-std=\fR" 4
-.IX Item "-std="
-Determine the language standard. This option
-is currently only supported when compiling C or \*(C+.
-.Sp
-The compiler can accept several base standards, such as \fBc90\fR or
-\&\fBc++98\fR, and \s-1GNU\s0 dialects of those standards, such as
-\&\fBgnu90\fR or \fBgnu++98\fR. By specifying a base standard, the
-compiler will accept all programs following that standard and those
-using \s-1GNU\s0 extensions that do not contradict it. For example,
-\&\fB\-std=c90\fR turns off certain features of \s-1GCC\s0 that are
-incompatible with \s-1ISO\s0 C90, such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR
-keywords, but not other \s-1GNU\s0 extensions that do not have a meaning in
-\&\s-1ISO\s0 C90, such as omitting the middle term of a \f(CW\*(C`?:\*(C'\fR
-expression. On the other hand, by specifying a \s-1GNU\s0 dialect of a
-standard, all features the compiler support are enabled, even when
-those features change the meaning of the base standard and some
-strict-conforming programs may be rejected. The particular standard
-is used by \fB\-pedantic\fR to identify which features are \s-1GNU\s0
-extensions given that version of the standard. For example
-\&\fB\-std=gnu90 \-pedantic\fR would warn about \*(C+ style \fB//\fR
-comments, while \fB\-std=gnu99 \-pedantic\fR would not.
-.Sp
-A value for this option must be provided; possible values are
-.RS 4
-.IP "\fBc90\fR" 4
-.IX Item "c90"
-.PD 0
-.IP "\fBc89\fR" 4
-.IX Item "c89"
-.IP "\fBiso9899:1990\fR" 4
-.IX Item "iso9899:1990"
-.PD
-Support all \s-1ISO\s0 C90 programs (certain \s-1GNU\s0 extensions that conflict
-with \s-1ISO\s0 C90 are disabled). Same as \fB\-ansi\fR for C code.
-.IP "\fBiso9899:199409\fR" 4
-.IX Item "iso9899:199409"
-\&\s-1ISO\s0 C90 as modified in amendment 1.
-.IP "\fBc99\fR" 4
-.IX Item "c99"
-.PD 0
-.IP "\fBc9x\fR" 4
-.IX Item "c9x"
-.IP "\fBiso9899:1999\fR" 4
-.IX Item "iso9899:1999"
-.IP "\fBiso9899:199x\fR" 4
-.IX Item "iso9899:199x"
-.PD
-\&\s-1ISO\s0 C99. Note that this standard is not yet fully supported; see
-<\fBhttp://gcc.gnu.org/gcc\-4.6/c99status.html\fR> for more information. The
-names \fBc9x\fR and \fBiso9899:199x\fR are deprecated.
-.IP "\fBc1x\fR" 4
-.IX Item "c1x"
-\&\s-1ISO\s0 C1X, the draft of the next revision of the \s-1ISO\s0 C standard.
-Support is limited and experimental and features enabled by this
-option may be changed or removed if changed in or removed from the
-standard draft.
-.IP "\fBgnu90\fR" 4
-.IX Item "gnu90"
-.PD 0
-.IP "\fBgnu89\fR" 4
-.IX Item "gnu89"
-.PD
-\&\s-1GNU\s0 dialect of \s-1ISO\s0 C90 (including some C99 features). This
-is the default for C code.
-.IP "\fBgnu99\fR" 4
-.IX Item "gnu99"
-.PD 0
-.IP "\fBgnu9x\fR" 4
-.IX Item "gnu9x"
-.PD
-\&\s-1GNU\s0 dialect of \s-1ISO\s0 C99. When \s-1ISO\s0 C99 is fully implemented in \s-1GCC\s0,
-this will become the default. The name \fBgnu9x\fR is deprecated.
-.IP "\fBgnu1x\fR" 4
-.IX Item "gnu1x"
-\&\s-1GNU\s0 dialect of \s-1ISO\s0 C1X. Support is limited and experimental and
-features enabled by this option may be changed or removed if changed
-in or removed from the standard draft.
-.IP "\fBc++98\fR" 4
-.IX Item "c++98"
-The 1998 \s-1ISO\s0 \*(C+ standard plus amendments. Same as \fB\-ansi\fR for
-\&\*(C+ code.
-.IP "\fBgnu++98\fR" 4
-.IX Item "gnu++98"
-\&\s-1GNU\s0 dialect of \fB\-std=c++98\fR. This is the default for
-\&\*(C+ code.
-.IP "\fBc++0x\fR" 4
-.IX Item "c++0x"
-The working draft of the upcoming \s-1ISO\s0 \*(C+0x standard. This option
-enables experimental features that are likely to be included in
-\&\*(C+0x. The working draft is constantly changing, and any feature that is
-enabled by this flag may be removed from future versions of \s-1GCC\s0 if it is
-not part of the \*(C+0x standard.
-.IP "\fBgnu++0x\fR" 4
-.IX Item "gnu++0x"
-\&\s-1GNU\s0 dialect of \fB\-std=c++0x\fR. This option enables
-experimental features that may be removed in future versions of \s-1GCC\s0.
-.RE
-.RS 4
-.RE
-.IP "\fB\-fgnu89\-inline\fR" 4
-.IX Item "-fgnu89-inline"
-The option \fB\-fgnu89\-inline\fR tells \s-1GCC\s0 to use the traditional
-\&\s-1GNU\s0 semantics for \f(CW\*(C`inline\*(C'\fR functions when in C99 mode.
- This option
-is accepted and ignored by \s-1GCC\s0 versions 4.1.3 up to but not including
-4.3. In \s-1GCC\s0 versions 4.3 and later it changes the behavior of \s-1GCC\s0 in
-C99 mode. Using this option is roughly equivalent to adding the
-\&\f(CW\*(C`gnu_inline\*(C'\fR function attribute to all inline functions.
-.Sp
-The option \fB\-fno\-gnu89\-inline\fR explicitly tells \s-1GCC\s0 to use the
-C99 semantics for \f(CW\*(C`inline\*(C'\fR when in C99 or gnu99 mode (i.e., it
-specifies the default behavior). This option was first supported in
-\&\s-1GCC\s0 4.3. This option is not supported in \fB\-std=c90\fR or
-\&\fB\-std=gnu90\fR mode.
-.Sp
-The preprocessor macros \f(CW\*(C`_\|_GNUC_GNU_INLINE_\|_\*(C'\fR and
-\&\f(CW\*(C`_\|_GNUC_STDC_INLINE_\|_\*(C'\fR may be used to check which semantics are
-in effect for \f(CW\*(C`inline\*(C'\fR functions.
-.IP "\fB\-aux\-info\fR \fIfilename\fR" 4
-.IX Item "-aux-info filename"
-Output to the given filename prototyped declarations for all functions
-declared and/or defined in a translation unit, including those in header
-files. This option is silently ignored in any language other than C.
-.Sp
-Besides declarations, the file indicates, in comments, the origin of
-each declaration (source file and line), whether the declaration was
-implicit, prototyped or unprototyped (\fBI\fR, \fBN\fR for new or
-\&\fBO\fR for old, respectively, in the first character after the line
-number and the colon), and whether it came from a declaration or a
-definition (\fBC\fR or \fBF\fR, respectively, in the following
-character). In the case of function definitions, a K&R\-style list of
-arguments followed by their declarations is also provided, inside
-comments, after the declaration.
-.IP "\fB\-fno\-asm\fR" 4
-.IX Item "-fno-asm"
-Do not recognize \f(CW\*(C`asm\*(C'\fR, \f(CW\*(C`inline\*(C'\fR or \f(CW\*(C`typeof\*(C'\fR as a
-keyword, so that code can use these words as identifiers. You can use
-the keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR
-instead. \fB\-ansi\fR implies \fB\-fno\-asm\fR.
-.Sp
-In \*(C+, this switch only affects the \f(CW\*(C`typeof\*(C'\fR keyword, since
-\&\f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`inline\*(C'\fR are standard keywords. You may want to
-use the \fB\-fno\-gnu\-keywords\fR flag instead, which has the same
-effect. In C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR), this
-switch only affects the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, since
-\&\f(CW\*(C`inline\*(C'\fR is a standard keyword in \s-1ISO\s0 C99.
-.IP "\fB\-fno\-builtin\fR" 4
-.IX Item "-fno-builtin"
-.PD 0
-.IP "\fB\-fno\-builtin\-\fR\fIfunction\fR" 4
-.IX Item "-fno-builtin-function"
-.PD
-Don't recognize built-in functions that do not begin with
-\&\fB_\|_builtin_\fR as prefix.
-.Sp
-\&\s-1GCC\s0 normally generates special code to handle certain built-in functions
-more efficiently; for instance, calls to \f(CW\*(C`alloca\*(C'\fR may become single
-instructions that adjust the stack directly, and calls to \f(CW\*(C`memcpy\*(C'\fR
-may become inline copy loops. The resulting code is often both smaller
-and faster, but since the function calls no longer appear as such, you
-cannot set a breakpoint on those calls, nor can you change the behavior
-of the functions by linking with a different library. In addition,
-when a function is recognized as a built-in function, \s-1GCC\s0 may use
-information about that function to warn about problems with calls to
-that function, or to generate more efficient code, even if the
-resulting code still contains calls to that function. For example,
-warnings are given with \fB\-Wformat\fR for bad calls to
-\&\f(CW\*(C`printf\*(C'\fR, when \f(CW\*(C`printf\*(C'\fR is built in, and \f(CW\*(C`strlen\*(C'\fR is
-known not to modify global memory.
-.Sp
-With the \fB\-fno\-builtin\-\fR\fIfunction\fR option
-only the built-in function \fIfunction\fR is
-disabled. \fIfunction\fR must not begin with \fB_\|_builtin_\fR. If a
-function is named that is not built-in in this version of \s-1GCC\s0, this
-option is ignored. There is no corresponding
-\&\fB\-fbuiltin\-\fR\fIfunction\fR option; if you wish to enable
-built-in functions selectively when using \fB\-fno\-builtin\fR or
-\&\fB\-ffreestanding\fR, you may define macros such as:
-.Sp
-.Vb 2
-\& #define abs(n) _\|_builtin_abs ((n))
-\& #define strcpy(d, s) _\|_builtin_strcpy ((d), (s))
-.Ve
-.IP "\fB\-fhosted\fR" 4
-.IX Item "-fhosted"
-Assert that compilation takes place in a hosted environment. This implies
-\&\fB\-fbuiltin\fR. A hosted environment is one in which the
-entire standard library is available, and in which \f(CW\*(C`main\*(C'\fR has a return
-type of \f(CW\*(C`int\*(C'\fR. Examples are nearly everything except a kernel.
-This is equivalent to \fB\-fno\-freestanding\fR.
-.IP "\fB\-ffreestanding\fR" 4
-.IX Item "-ffreestanding"
-Assert that compilation takes place in a freestanding environment. This
-implies \fB\-fno\-builtin\fR. A freestanding environment
-is one in which the standard library may not exist, and program startup may
-not necessarily be at \f(CW\*(C`main\*(C'\fR. The most obvious example is an \s-1OS\s0 kernel.
-This is equivalent to \fB\-fno\-hosted\fR.
-.IP "\fB\-fopenmp\fR" 4
-.IX Item "-fopenmp"
-Enable handling of OpenMP directives \f(CW\*(C`#pragma omp\*(C'\fR in C/\*(C+ and
-\&\f(CW\*(C`!$omp\*(C'\fR in Fortran. When \fB\-fopenmp\fR is specified, the
-compiler generates parallel code according to the OpenMP Application
-Program Interface v3.0 <\fBhttp://www.openmp.org/\fR>. This option
-implies \fB\-pthread\fR, and thus is only supported on targets that
-have support for \fB\-pthread\fR.
-.IP "\fB\-fms\-extensions\fR" 4
-.IX Item "-fms-extensions"
-Accept some non-standard constructs used in Microsoft header files.
-.Sp
-In \*(C+ code, this allows member names in structures to be similar
-to previous types declarations.
-.Sp
-.Vb 4
-\& typedef int UOW;
-\& struct ABC {
-\& UOW UOW;
-\& };
-.Ve
-.Sp
-Some cases of unnamed fields in structures and unions are only
-accepted with this option.
-.IP "\fB\-fplan9\-extensions\fR" 4
-.IX Item "-fplan9-extensions"
-Accept some non-standard constructs used in Plan 9 code.
-.Sp
-This enables \fB\-fms\-extensions\fR, permits passing pointers to
-structures with anonymous fields to functions which expect pointers to
-elements of the type of the field, and permits referring to anonymous
-fields declared using a typedef. This is only
-supported for C, not \*(C+.
-.IP "\fB\-trigraphs\fR" 4
-.IX Item "-trigraphs"
-Support \s-1ISO\s0 C trigraphs. The \fB\-ansi\fR option (and \fB\-std\fR
-options for strict \s-1ISO\s0 C conformance) implies \fB\-trigraphs\fR.
-.IP "\fB\-no\-integrated\-cpp\fR" 4
-.IX Item "-no-integrated-cpp"
-Performs a compilation in two passes: preprocessing and compiling. This
-option allows a user supplied \*(L"cc1\*(R", \*(L"cc1plus\*(R", or \*(L"cc1obj\*(R" via the
-\&\fB\-B\fR option. The user supplied compilation step can then add in
-an additional preprocessing step after normal preprocessing but before
-compiling. The default is to use the integrated cpp (internal cpp)
-.Sp
-The semantics of this option will change if \*(L"cc1\*(R", \*(L"cc1plus\*(R", and
-\&\*(L"cc1obj\*(R" are merged.
-.IP "\fB\-traditional\fR" 4
-.IX Item "-traditional"
-.PD 0
-.IP "\fB\-traditional\-cpp\fR" 4
-.IX Item "-traditional-cpp"
-.PD
-Formerly, these options caused \s-1GCC\s0 to attempt to emulate a pre-standard
-C compiler. They are now only supported with the \fB\-E\fR switch.
-The preprocessor continues to support a pre-standard mode. See the \s-1GNU\s0
-\&\s-1CPP\s0 manual for details.
-.IP "\fB\-fcond\-mismatch\fR" 4
-.IX Item "-fcond-mismatch"
-Allow conditional expressions with mismatched types in the second and
-third arguments. The value of such an expression is void. This option
-is not supported for \*(C+.
-.IP "\fB\-flax\-vector\-conversions\fR" 4
-.IX Item "-flax-vector-conversions"
-Allow implicit conversions between vectors with differing numbers of
-elements and/or incompatible element types. This option should not be
-used for new code.
-.IP "\fB\-funsigned\-char\fR" 4
-.IX Item "-funsigned-char"
-Let the type \f(CW\*(C`char\*(C'\fR be unsigned, like \f(CW\*(C`unsigned char\*(C'\fR.
-.Sp
-Each kind of machine has a default for what \f(CW\*(C`char\*(C'\fR should
-be. It is either like \f(CW\*(C`unsigned char\*(C'\fR by default or like
-\&\f(CW\*(C`signed char\*(C'\fR by default.
-.Sp
-Ideally, a portable program should always use \f(CW\*(C`signed char\*(C'\fR or
-\&\f(CW\*(C`unsigned char\*(C'\fR when it depends on the signedness of an object.
-But many programs have been written to use plain \f(CW\*(C`char\*(C'\fR and
-expect it to be signed, or expect it to be unsigned, depending on the
-machines they were written for. This option, and its inverse, let you
-make such a program work with the opposite default.
-.Sp
-The type \f(CW\*(C`char\*(C'\fR is always a distinct type from each of
-\&\f(CW\*(C`signed char\*(C'\fR or \f(CW\*(C`unsigned char\*(C'\fR, even though its behavior
-is always just like one of those two.
-.IP "\fB\-fsigned\-char\fR" 4
-.IX Item "-fsigned-char"
-Let the type \f(CW\*(C`char\*(C'\fR be signed, like \f(CW\*(C`signed char\*(C'\fR.
-.Sp
-Note that this is equivalent to \fB\-fno\-unsigned\-char\fR, which is
-the negative form of \fB\-funsigned\-char\fR. Likewise, the option
-\&\fB\-fno\-signed\-char\fR is equivalent to \fB\-funsigned\-char\fR.
-.IP "\fB\-fsigned\-bitfields\fR" 4
-.IX Item "-fsigned-bitfields"
-.PD 0
-.IP "\fB\-funsigned\-bitfields\fR" 4
-.IX Item "-funsigned-bitfields"
-.IP "\fB\-fno\-signed\-bitfields\fR" 4
-.IX Item "-fno-signed-bitfields"
-.IP "\fB\-fno\-unsigned\-bitfields\fR" 4
-.IX Item "-fno-unsigned-bitfields"
-.PD
-These options control whether a bit-field is signed or unsigned, when the
-declaration does not use either \f(CW\*(C`signed\*(C'\fR or \f(CW\*(C`unsigned\*(C'\fR. By
-default, such a bit-field is signed, because this is consistent: the
-basic integer types such as \f(CW\*(C`int\*(C'\fR are signed types.
-.SS "Options Controlling \*(C+ Dialect"
-.IX Subsection "Options Controlling Dialect"
-This section describes the command-line options that are only meaningful
-for \*(C+ programs; but you can also use most of the \s-1GNU\s0 compiler options
-regardless of what language your program is in. For example, you
-might compile a file \f(CW\*(C`firstClass.C\*(C'\fR like this:
-.PP
-.Vb 1
-\& g++ \-g \-frepo \-O \-c firstClass.C
-.Ve
-.PP
-In this example, only \fB\-frepo\fR is an option meant
-only for \*(C+ programs; you can use the other options with any
-language supported by \s-1GCC\s0.
-.PP
-Here is a list of options that are \fIonly\fR for compiling \*(C+ programs:
-.IP "\fB\-fabi\-version=\fR\fIn\fR" 4
-.IX Item "-fabi-version=n"
-Use version \fIn\fR of the \*(C+ \s-1ABI\s0. Version 2 is the version of the
-\&\*(C+ \s-1ABI\s0 that first appeared in G++ 3.4. Version 1 is the version of
-the \*(C+ \s-1ABI\s0 that first appeared in G++ 3.2. Version 0 will always be
-the version that conforms most closely to the \*(C+ \s-1ABI\s0 specification.
-Therefore, the \s-1ABI\s0 obtained using version 0 will change as \s-1ABI\s0 bugs
-are fixed.
-.Sp
-The default is version 2.
-.Sp
-Version 3 corrects an error in mangling a constant address as a
-template argument.
-.Sp
-Version 4 implements a standard mangling for vector types.
-.Sp
-Version 5 corrects the mangling of attribute const/volatile on
-function pointer types, decltype of a plain decl, and use of a
-function parameter in the declaration of another parameter.
-.Sp
-See also \fB\-Wabi\fR.
-.IP "\fB\-fno\-access\-control\fR" 4
-.IX Item "-fno-access-control"
-Turn off all access checking. This switch is mainly useful for working
-around bugs in the access control code.
-.IP "\fB\-fcheck\-new\fR" 4
-.IX Item "-fcheck-new"
-Check that the pointer returned by \f(CW\*(C`operator new\*(C'\fR is non-null
-before attempting to modify the storage allocated. This check is
-normally unnecessary because the \*(C+ standard specifies that
-\&\f(CW\*(C`operator new\*(C'\fR will only return \f(CW0\fR if it is declared
-\&\fB\f(BIthrow()\fB\fR, in which case the compiler will always check the
-return value even without this option. In all other cases, when
-\&\f(CW\*(C`operator new\*(C'\fR has a non-empty exception specification, memory
-exhaustion is signalled by throwing \f(CW\*(C`std::bad_alloc\*(C'\fR. See also
-\&\fBnew (nothrow)\fR.
-.IP "\fB\-fconserve\-space\fR" 4
-.IX Item "-fconserve-space"
-Put uninitialized or runtime-initialized global variables into the
-common segment, as C does. This saves space in the executable at the
-cost of not diagnosing duplicate definitions. If you compile with this
-flag and your program mysteriously crashes after \f(CW\*(C`main()\*(C'\fR has
-completed, you may have an object that is being destroyed twice because
-two definitions were merged.
-.Sp
-This option is no longer useful on most targets, now that support has
-been added for putting variables into \s-1BSS\s0 without making them common.
-.IP "\fB\-fconstexpr\-depth=\fR\fIn\fR" 4
-.IX Item "-fconstexpr-depth=n"
-Set the maximum nested evaluation depth for \*(C+0x constexpr functions
-to \fIn\fR. A limit is needed to detect endless recursion during
-constant expression evaluation. The minimum specified by the standard
-is 512.
-.IP "\fB\-fno\-deduce\-init\-list\fR" 4
-.IX Item "-fno-deduce-init-list"
-Disable deduction of a template type parameter as
-std::initializer_list from a brace-enclosed initializer list, i.e.
-.Sp
-.Vb 4
-\& template <class T> auto forward(T t) \-> decltype (realfn (t))
-\& {
-\& return realfn (t);
-\& }
-\&
-\& void f()
-\& {
-\& forward({1,2}); // call forward<std::initializer_list<int>>
-\& }
-.Ve
-.Sp
-This option is present because this deduction is an extension to the
-current specification in the \*(C+0x working draft, and there was
-some concern about potential overload resolution problems.
-.IP "\fB\-ffriend\-injection\fR" 4
-.IX Item "-ffriend-injection"
-Inject friend functions into the enclosing namespace, so that they are
-visible outside the scope of the class in which they are declared.
-Friend functions were documented to work this way in the old Annotated
-\&\*(C+ Reference Manual, and versions of G++ before 4.1 always worked
-that way. However, in \s-1ISO\s0 \*(C+ a friend function which is not declared
-in an enclosing scope can only be found using argument dependent
-lookup. This option causes friends to be injected as they were in
-earlier releases.
-.Sp
-This option is for compatibility, and may be removed in a future
-release of G++.
-.IP "\fB\-fno\-elide\-constructors\fR" 4
-.IX Item "-fno-elide-constructors"
-The \*(C+ standard allows an implementation to omit creating a temporary
-which is only used to initialize another object of the same type.
-Specifying this option disables that optimization, and forces G++ to
-call the copy constructor in all cases.
-.IP "\fB\-fno\-enforce\-eh\-specs\fR" 4
-.IX Item "-fno-enforce-eh-specs"
-Don't generate code to check for violation of exception specifications
-at runtime. This option violates the \*(C+ standard, but may be useful
-for reducing code size in production builds, much like defining
-\&\fB\s-1NDEBUG\s0\fR. This does not give user code permission to throw
-exceptions in violation of the exception specifications; the compiler
-will still optimize based on the specifications, so throwing an
-unexpected exception will result in undefined behavior.
-.IP "\fB\-ffor\-scope\fR" 4
-.IX Item "-ffor-scope"
-.PD 0
-.IP "\fB\-fno\-for\-scope\fR" 4
-.IX Item "-fno-for-scope"
-.PD
-If \fB\-ffor\-scope\fR is specified, the scope of variables declared in
-a \fIfor-init-statement\fR is limited to the \fBfor\fR loop itself,
-as specified by the \*(C+ standard.
-If \fB\-fno\-for\-scope\fR is specified, the scope of variables declared in
-a \fIfor-init-statement\fR extends to the end of the enclosing scope,
-as was the case in old versions of G++, and other (traditional)
-implementations of \*(C+.
-.Sp
-The default if neither flag is given to follow the standard,
-but to allow and give a warning for old-style code that would
-otherwise be invalid, or have different behavior.
-.IP "\fB\-fno\-gnu\-keywords\fR" 4
-.IX Item "-fno-gnu-keywords"
-Do not recognize \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use this
-word as an identifier. You can use the keyword \f(CW\*(C`_\|_typeof_\|_\*(C'\fR instead.
-\&\fB\-ansi\fR implies \fB\-fno\-gnu\-keywords\fR.
-.IP "\fB\-fno\-implicit\-templates\fR" 4
-.IX Item "-fno-implicit-templates"
-Never emit code for non-inline templates which are instantiated
-implicitly (i.e. by use); only emit code for explicit instantiations.
-.IP "\fB\-fno\-implicit\-inline\-templates\fR" 4
-.IX Item "-fno-implicit-inline-templates"
-Don't emit code for implicit instantiations of inline templates, either.
-The default is to handle inlines differently so that compiles with and
-without optimization will need the same set of explicit instantiations.
-.IP "\fB\-fno\-implement\-inlines\fR" 4
-.IX Item "-fno-implement-inlines"
-To save space, do not emit out-of-line copies of inline functions
-controlled by \fB#pragma implementation\fR. This will cause linker
-errors if these functions are not inlined everywhere they are called.
-.IP "\fB\-fms\-extensions\fR" 4
-.IX Item "-fms-extensions"
-Disable pedantic warnings about constructs used in \s-1MFC\s0, such as implicit
-int and getting a pointer to member function via non-standard syntax.
-.IP "\fB\-fno\-nonansi\-builtins\fR" 4
-.IX Item "-fno-nonansi-builtins"
-Disable built-in declarations of functions that are not mandated by
-\&\s-1ANSI/ISO\s0 C. These include \f(CW\*(C`ffs\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`_exit\*(C'\fR,
-\&\f(CW\*(C`index\*(C'\fR, \f(CW\*(C`bzero\*(C'\fR, \f(CW\*(C`conjf\*(C'\fR, and other related functions.
-.IP "\fB\-fnothrow\-opt\fR" 4
-.IX Item "-fnothrow-opt"
-Treat a \f(CW\*(C`throw()\*(C'\fR exception specification as though it were a
-\&\f(CW\*(C`noexcept\*(C'\fR specification to reduce or eliminate the text size
-overhead relative to a function with no exception specification. If
-the function has local variables of types with non-trivial
-destructors, the exception specification will actually make the
-function smaller because the \s-1EH\s0 cleanups for those variables can be
-optimized away. The semantic effect is that an exception thrown out of
-a function with such an exception specification will result in a call
-to \f(CW\*(C`terminate\*(C'\fR rather than \f(CW\*(C`unexpected\*(C'\fR.
-.IP "\fB\-fno\-operator\-names\fR" 4
-.IX Item "-fno-operator-names"
-Do not treat the operator name keywords \f(CW\*(C`and\*(C'\fR, \f(CW\*(C`bitand\*(C'\fR,
-\&\f(CW\*(C`bitor\*(C'\fR, \f(CW\*(C`compl\*(C'\fR, \f(CW\*(C`not\*(C'\fR, \f(CW\*(C`or\*(C'\fR and \f(CW\*(C`xor\*(C'\fR as
-synonyms as keywords.
-.IP "\fB\-fno\-optional\-diags\fR" 4
-.IX Item "-fno-optional-diags"
-Disable diagnostics that the standard says a compiler does not need to
-issue. Currently, the only such diagnostic issued by G++ is the one for
-a name having multiple meanings within a class.
-.IP "\fB\-fpermissive\fR" 4
-.IX Item "-fpermissive"
-Downgrade some diagnostics about nonconformant code from errors to
-warnings. Thus, using \fB\-fpermissive\fR will allow some
-nonconforming code to compile.
-.IP "\fB\-fno\-pretty\-templates\fR" 4
-.IX Item "-fno-pretty-templates"
-When an error message refers to a specialization of a function
-template, the compiler will normally print the signature of the
-template followed by the template arguments and any typedefs or
-typenames in the signature (e.g. \f(CW\*(C`void f(T) [with T = int]\*(C'\fR
-rather than \f(CW\*(C`void f(int)\*(C'\fR) so that it's clear which template is
-involved. When an error message refers to a specialization of a class
-template, the compiler will omit any template arguments which match
-the default template arguments for that template. If either of these
-behaviors make it harder to understand the error message rather than
-easier, using \fB\-fno\-pretty\-templates\fR will disable them.
-.IP "\fB\-frepo\fR" 4
-.IX Item "-frepo"
-Enable automatic template instantiation at link time. This option also
-implies \fB\-fno\-implicit\-templates\fR.
-.IP "\fB\-fno\-rtti\fR" 4
-.IX Item "-fno-rtti"
-Disable generation of information about every class with virtual
-functions for use by the \*(C+ runtime type identification features
-(\fBdynamic_cast\fR and \fBtypeid\fR). If you don't use those parts
-of the language, you can save some space by using this flag. Note that
-exception handling uses the same information, but it will generate it as
-needed. The \fBdynamic_cast\fR operator can still be used for casts that
-do not require runtime type information, i.e. casts to \f(CW\*(C`void *\*(C'\fR or to
-unambiguous base classes.
-.IP "\fB\-fstats\fR" 4
-.IX Item "-fstats"
-Emit statistics about front-end processing at the end of the compilation.
-This information is generally only useful to the G++ development team.
-.IP "\fB\-fstrict\-enums\fR" 4
-.IX Item "-fstrict-enums"
-Allow the compiler to optimize using the assumption that a value of
-enumeration type can only be one of the values of the enumeration (as
-defined in the \*(C+ standard; basically, a value which can be
-represented in the minimum number of bits needed to represent all the
-enumerators). This assumption may not be valid if the program uses a
-cast to convert an arbitrary integer value to the enumeration type.
-.IP "\fB\-ftemplate\-depth=\fR\fIn\fR" 4
-.IX Item "-ftemplate-depth=n"
-Set the maximum instantiation depth for template classes to \fIn\fR.
-A limit on the template instantiation depth is needed to detect
-endless recursions during template class instantiation. \s-1ANSI/ISO\s0 \*(C+
-conforming programs must not rely on a maximum depth greater than 17
-(changed to 1024 in \*(C+0x).
-.IP "\fB\-fno\-threadsafe\-statics\fR" 4
-.IX Item "-fno-threadsafe-statics"
-Do not emit the extra code to use the routines specified in the \*(C+
-\&\s-1ABI\s0 for thread-safe initialization of local statics. You can use this
-option to reduce code size slightly in code that doesn't need to be
-thread-safe.
-.IP "\fB\-fuse\-cxa\-atexit\fR" 4
-.IX Item "-fuse-cxa-atexit"
-Register destructors for objects with static storage duration with the
-\&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR function rather than the \f(CW\*(C`atexit\*(C'\fR function.
-This option is required for fully standards-compliant handling of static
-destructors, but will only work if your C library supports
-\&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR.
-.IP "\fB\-fno\-use\-cxa\-get\-exception\-ptr\fR" 4
-.IX Item "-fno-use-cxa-get-exception-ptr"
-Don't use the \f(CW\*(C`_\|_cxa_get_exception_ptr\*(C'\fR runtime routine. This
-will cause \f(CW\*(C`std::uncaught_exception\*(C'\fR to be incorrect, but is necessary
-if the runtime routine is not available.
-.IP "\fB\-fvisibility\-inlines\-hidden\fR" 4
-.IX Item "-fvisibility-inlines-hidden"
-This switch declares that the user does not attempt to compare
-pointers to inline methods where the addresses of the two functions
-were taken in different shared objects.
-.Sp
-The effect of this is that \s-1GCC\s0 may, effectively, mark inline methods with
-\&\f(CW\*(C`_\|_attribute_\|_ ((visibility ("hidden")))\*(C'\fR so that they do not
-appear in the export table of a \s-1DSO\s0 and do not require a \s-1PLT\s0 indirection
-when used within the \s-1DSO\s0. Enabling this option can have a dramatic effect
-on load and link times of a \s-1DSO\s0 as it massively reduces the size of the
-dynamic export table when the library makes heavy use of templates.
-.Sp
-The behavior of this switch is not quite the same as marking the
-methods as hidden directly, because it does not affect static variables
-local to the function or cause the compiler to deduce that
-the function is defined in only one shared object.
-.Sp
-You may mark a method as having a visibility explicitly to negate the
-effect of the switch for that method. For example, if you do want to
-compare pointers to a particular inline method, you might mark it as
-having default visibility. Marking the enclosing class with explicit
-visibility will have no effect.
-.Sp
-Explicitly instantiated inline methods are unaffected by this option
-as their linkage might otherwise cross a shared library boundary.
-.IP "\fB\-fvisibility\-ms\-compat\fR" 4
-.IX Item "-fvisibility-ms-compat"
-This flag attempts to use visibility settings to make \s-1GCC\s0's \*(C+
-linkage model compatible with that of Microsoft Visual Studio.
-.Sp
-The flag makes these changes to \s-1GCC\s0's linkage model:
-.RS 4
-.IP "1." 4
-It sets the default visibility to \f(CW\*(C`hidden\*(C'\fR, like
-\&\fB\-fvisibility=hidden\fR.
-.IP "2." 4
-Types, but not their members, are not hidden by default.
-.IP "3." 4
-The One Definition Rule is relaxed for types without explicit
-visibility specifications which are defined in more than one different
-shared object: those declarations are permitted if they would have
-been permitted when this option was not used.
-.RE
-.RS 4
-.Sp
-In new code it is better to use \fB\-fvisibility=hidden\fR and
-export those classes which are intended to be externally visible.
-Unfortunately it is possible for code to rely, perhaps accidentally,
-on the Visual Studio behavior.
-.Sp
-Among the consequences of these changes are that static data members
-of the same type with the same name but defined in different shared
-objects will be different, so changing one will not change the other;
-and that pointers to function members defined in different shared
-objects may not compare equal. When this flag is given, it is a
-violation of the \s-1ODR\s0 to define types with the same name differently.
-.RE
-.IP "\fB\-fno\-weak\fR" 4
-.IX Item "-fno-weak"
-Do not use weak symbol support, even if it is provided by the linker.
-By default, G++ will use weak symbols if they are available. This
-option exists only for testing, and should not be used by end-users;
-it will result in inferior code and has no benefits. This option may
-be removed in a future release of G++.
-.IP "\fB\-nostdinc++\fR" 4
-.IX Item "-nostdinc++"
-Do not search for header files in the standard directories specific to
-\&\*(C+, but do still search the other standard directories. (This option
-is used when building the \*(C+ library.)
-.PP
-In addition, these optimization, warning, and code generation options
-have meanings only for \*(C+ programs:
-.IP "\fB\-fno\-default\-inline\fR" 4
-.IX Item "-fno-default-inline"
-Do not assume \fBinline\fR for functions defined inside a class scope.
- Note that these
-functions will have linkage like inline functions; they just won't be
-inlined by default.
-.IP "\fB\-Wabi\fR (C, Objective-C, \*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wabi (C, Objective-C, and Objective- only)"
-Warn when G++ generates code that is probably not compatible with the
-vendor-neutral \*(C+ \s-1ABI\s0. Although an effort has been made to warn about
-all such cases, there are probably some cases that are not warned about,
-even though G++ is generating incompatible code. There may also be
-cases where warnings are emitted even though the code that is generated
-will be compatible.
-.Sp
-You should rewrite your code to avoid these warnings if you are
-concerned about the fact that code generated by G++ may not be binary
-compatible with code generated by other compilers.
-.Sp
-The known incompatibilities in \fB\-fabi\-version=2\fR (the default) include:
-.RS 4
-.IP "\(bu" 4
-A template with a non-type template parameter of reference type is
-mangled incorrectly:
-.Sp
-.Vb 3
-\& extern int N;
-\& template <int &> struct S {};
-\& void n (S<N>) {2}
-.Ve
-.Sp
-This is fixed in \fB\-fabi\-version=3\fR.
-.IP "\(bu" 4
-\&\s-1SIMD\s0 vector types declared using \f(CW\*(C`_\|_attribute ((vector_size))\*(C'\fR are
-mangled in a non-standard way that does not allow for overloading of
-functions taking vectors of different sizes.
-.Sp
-The mangling is changed in \fB\-fabi\-version=4\fR.
-.RE
-.RS 4
-.Sp
-The known incompatibilities in \fB\-fabi\-version=1\fR include:
-.IP "\(bu" 4
-Incorrect handling of tail-padding for bit-fields. G++ may attempt to
-pack data into the same byte as a base class. For example:
-.Sp
-.Vb 2
-\& struct A { virtual void f(); int f1 : 1; };
-\& struct B : public A { int f2 : 1; };
-.Ve
-.Sp
-In this case, G++ will place \f(CW\*(C`B::f2\*(C'\fR into the same byte
-as\f(CW\*(C`A::f1\*(C'\fR; other compilers will not. You can avoid this problem
-by explicitly padding \f(CW\*(C`A\*(C'\fR so that its size is a multiple of the
-byte size on your platform; that will cause G++ and other compilers to
-layout \f(CW\*(C`B\*(C'\fR identically.
-.IP "\(bu" 4
-Incorrect handling of tail-padding for virtual bases. G++ does not use
-tail padding when laying out virtual bases. For example:
-.Sp
-.Vb 3
-\& struct A { virtual void f(); char c1; };
-\& struct B { B(); char c2; };
-\& struct C : public A, public virtual B {};
-.Ve
-.Sp
-In this case, G++ will not place \f(CW\*(C`B\*(C'\fR into the tail-padding for
-\&\f(CW\*(C`A\*(C'\fR; other compilers will. You can avoid this problem by
-explicitly padding \f(CW\*(C`A\*(C'\fR so that its size is a multiple of its
-alignment (ignoring virtual base classes); that will cause G++ and other
-compilers to layout \f(CW\*(C`C\*(C'\fR identically.
-.IP "\(bu" 4
-Incorrect handling of bit-fields with declared widths greater than that
-of their underlying types, when the bit-fields appear in a union. For
-example:
-.Sp
-.Vb 1
-\& union U { int i : 4096; };
-.Ve
-.Sp
-Assuming that an \f(CW\*(C`int\*(C'\fR does not have 4096 bits, G++ will make the
-union too small by the number of bits in an \f(CW\*(C`int\*(C'\fR.
-.IP "\(bu" 4
-Empty classes can be placed at incorrect offsets. For example:
-.Sp
-.Vb 1
-\& struct A {};
-\&
-\& struct B {
-\& A a;
-\& virtual void f ();
-\& };
-\&
-\& struct C : public B, public A {};
-.Ve
-.Sp
-G++ will place the \f(CW\*(C`A\*(C'\fR base class of \f(CW\*(C`C\*(C'\fR at a nonzero offset;
-it should be placed at offset zero. G++ mistakenly believes that the
-\&\f(CW\*(C`A\*(C'\fR data member of \f(CW\*(C`B\*(C'\fR is already at offset zero.
-.IP "\(bu" 4
-Names of template functions whose types involve \f(CW\*(C`typename\*(C'\fR or
-template template parameters can be mangled incorrectly.
-.Sp
-.Vb 2
-\& template <typename Q>
-\& void f(typename Q::X) {}
-\&
-\& template <template <typename> class Q>
-\& void f(typename Q<int>::X) {}
-.Ve
-.Sp
-Instantiations of these templates may be mangled incorrectly.
-.RE
-.RS 4
-.Sp
-It also warns psABI related changes. The known psABI changes at this
-point include:
-.IP "\(bu" 4
-For SYSV/x86\-64, when passing union with long double, it is changed to
-pass in memory as specified in psABI. For example:
-.Sp
-.Vb 4
-\& union U {
-\& long double ld;
-\& int i;
-\& };
-.Ve
-.Sp
-\&\f(CW\*(C`union U\*(C'\fR will always be passed in memory.
-.RE
-.RS 4
-.RE
-.IP "\fB\-Wctor\-dtor\-privacy\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wctor-dtor-privacy ( and Objective- only)"
-Warn when a class seems unusable because all the constructors or
-destructors in that class are private, and it has neither friends nor
-public static member functions.
-.IP "\fB\-Wnoexcept\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wnoexcept ( and Objective- only)"
-Warn when a noexcept-expression evaluates to false because of a call
-to a function that does not have a non-throwing exception
-specification (i.e. \fB\f(BIthrow()\fB\fR or \fBnoexcept\fR) but is known by
-the compiler to never throw an exception.
-.IP "\fB\-Wnon\-virtual\-dtor\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wnon-virtual-dtor ( and Objective- only)"
-Warn when a class has virtual functions and accessible non-virtual
-destructor, in which case it would be possible but unsafe to delete
-an instance of a derived class through a pointer to the base class.
-This warning is also enabled if \-Weffc++ is specified.
-.IP "\fB\-Wreorder\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wreorder ( and Objective- only)"
-Warn when the order of member initializers given in the code does not
-match the order in which they must be executed. For instance:
-.Sp
-.Vb 5
-\& struct A {
-\& int i;
-\& int j;
-\& A(): j (0), i (1) { }
-\& };
-.Ve
-.Sp
-The compiler will rearrange the member initializers for \fBi\fR
-and \fBj\fR to match the declaration order of the members, emitting
-a warning to that effect. This warning is enabled by \fB\-Wall\fR.
-.PP
-The following \fB\-W...\fR options are not affected by \fB\-Wall\fR.
-.IP "\fB\-Weffc++\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Weffc++ ( and Objective- only)"
-Warn about violations of the following style guidelines from Scott Meyers'
-\&\fIEffective \*(C+\fR book:
-.RS 4
-.IP "\(bu" 4
-Item 11: Define a copy constructor and an assignment operator for classes
-with dynamically allocated memory.
-.IP "\(bu" 4
-Item 12: Prefer initialization to assignment in constructors.
-.IP "\(bu" 4
-Item 14: Make destructors virtual in base classes.
-.IP "\(bu" 4
-Item 15: Have \f(CW\*(C`operator=\*(C'\fR return a reference to \f(CW*this\fR.
-.IP "\(bu" 4
-Item 23: Don't try to return a reference when you must return an object.
-.RE
-.RS 4
-.Sp
-Also warn about violations of the following style guidelines from
-Scott Meyers' \fIMore Effective \*(C+\fR book:
-.IP "\(bu" 4
-Item 6: Distinguish between prefix and postfix forms of increment and
-decrement operators.
-.IP "\(bu" 4
-Item 7: Never overload \f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, or \f(CW\*(C`,\*(C'\fR.
-.RE
-.RS 4
-.Sp
-When selecting this option, be aware that the standard library
-headers do not obey all of these guidelines; use \fBgrep \-v\fR
-to filter out those warnings.
-.RE
-.IP "\fB\-Wstrict\-null\-sentinel\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wstrict-null-sentinel ( and Objective- only)"
-Warn also about the use of an uncasted \f(CW\*(C`NULL\*(C'\fR as sentinel. When
-compiling only with \s-1GCC\s0 this is a valid sentinel, as \f(CW\*(C`NULL\*(C'\fR is defined
-to \f(CW\*(C`_\|_null\*(C'\fR. Although it is a null pointer constant not a null pointer,
-it is guaranteed to be of the same size as a pointer. But this use is
-not portable across different compilers.
-.IP "\fB\-Wno\-non\-template\-friend\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wno-non-template-friend ( and Objective- only)"
-Disable warnings when non-templatized friend functions are declared
-within a template. Since the advent of explicit template specification
-support in G++, if the name of the friend is an unqualified-id (i.e.,
-\&\fBfriend foo(int)\fR), the \*(C+ language specification demands that the
-friend declare or define an ordinary, nontemplate function. (Section
-14.5.3). Before G++ implemented explicit specification, unqualified-ids
-could be interpreted as a particular specialization of a templatized
-function. Because this non-conforming behavior is no longer the default
-behavior for G++, \fB\-Wnon\-template\-friend\fR allows the compiler to
-check existing code for potential trouble spots and is on by default.
-This new compiler behavior can be turned off with
-\&\fB\-Wno\-non\-template\-friend\fR which keeps the conformant compiler code
-but disables the helpful warning.
-.IP "\fB\-Wold\-style\-cast\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wold-style-cast ( and Objective- only)"
-Warn if an old-style (C\-style) cast to a non-void type is used within
-a \*(C+ program. The new-style casts (\fBdynamic_cast\fR,
-\&\fBstatic_cast\fR, \fBreinterpret_cast\fR, and \fBconst_cast\fR) are
-less vulnerable to unintended effects and much easier to search for.
-.IP "\fB\-Woverloaded\-virtual\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Woverloaded-virtual ( and Objective- only)"
-Warn when a function declaration hides virtual functions from a
-base class. For example, in:
-.Sp
-.Vb 3
-\& struct A {
-\& virtual void f();
-\& };
-\&
-\& struct B: public A {
-\& void f(int);
-\& };
-.Ve
-.Sp
-the \f(CW\*(C`A\*(C'\fR class version of \f(CW\*(C`f\*(C'\fR is hidden in \f(CW\*(C`B\*(C'\fR, and code
-like:
-.Sp
-.Vb 2
-\& B* b;
-\& b\->f();
-.Ve
-.Sp
-will fail to compile.
-.IP "\fB\-Wno\-pmf\-conversions\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wno-pmf-conversions ( and Objective- only)"
-Disable the diagnostic for converting a bound pointer to member function
-to a plain pointer.
-.IP "\fB\-Wsign\-promo\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wsign-promo ( and Objective- only)"
-Warn when overload resolution chooses a promotion from unsigned or
-enumerated type to a signed type, over a conversion to an unsigned type of
-the same size. Previous versions of G++ would try to preserve
-unsignedness, but the standard mandates the current behavior.
-.Sp
-.Vb 4
-\& struct A {
-\& operator int ();
-\& A& operator = (int);
-\& };
-\&
-\& main ()
-\& {
-\& A a,b;
-\& a = b;
-\& }
-.Ve
-.Sp
-In this example, G++ will synthesize a default \fBA& operator =
-(const A&);\fR, while cfront will use the user-defined \fBoperator =\fR.
-.SS "Options Controlling Objective-C and Objective\-\*(C+ Dialects"
-.IX Subsection "Options Controlling Objective-C and Objective- Dialects"
-(\s-1NOTE:\s0 This manual does not describe the Objective-C and Objective\-\*(C+
-languages themselves.
-.PP
-This section describes the command-line options that are only meaningful
-for Objective-C and Objective\-\*(C+ programs, but you can also use most of
-the language-independent \s-1GNU\s0 compiler options.
-For example, you might compile a file \f(CW\*(C`some_class.m\*(C'\fR like this:
-.PP
-.Vb 1
-\& gcc \-g \-fgnu\-runtime \-O \-c some_class.m
-.Ve
-.PP
-In this example, \fB\-fgnu\-runtime\fR is an option meant only for
-Objective-C and Objective\-\*(C+ programs; you can use the other options with
-any language supported by \s-1GCC\s0.
-.PP
-Note that since Objective-C is an extension of the C language, Objective-C
-compilations may also use options specific to the C front-end (e.g.,
-\&\fB\-Wtraditional\fR). Similarly, Objective\-\*(C+ compilations may use
-\&\*(C+\-specific options (e.g., \fB\-Wabi\fR).
-.PP
-Here is a list of options that are \fIonly\fR for compiling Objective-C
-and Objective\-\*(C+ programs:
-.IP "\fB\-fconstant\-string\-class=\fR\fIclass-name\fR" 4
-.IX Item "-fconstant-string-class=class-name"
-Use \fIclass-name\fR as the name of the class to instantiate for each
-literal string specified with the syntax \f(CW\*(C`@"..."\*(C'\fR. The default
-class name is \f(CW\*(C`NXConstantString\*(C'\fR if the \s-1GNU\s0 runtime is being used, and
-\&\f(CW\*(C`NSConstantString\*(C'\fR if the NeXT runtime is being used (see below). The
-\&\fB\-fconstant\-cfstrings\fR option, if also present, will override the
-\&\fB\-fconstant\-string\-class\fR setting and cause \f(CW\*(C`@"..."\*(C'\fR literals
-to be laid out as constant CoreFoundation strings.
-.IP "\fB\-fgnu\-runtime\fR" 4
-.IX Item "-fgnu-runtime"
-Generate object code compatible with the standard \s-1GNU\s0 Objective-C
-runtime. This is the default for most types of systems.
-.IP "\fB\-fnext\-runtime\fR" 4
-.IX Item "-fnext-runtime"
-Generate output compatible with the NeXT runtime. This is the default
-for NeXT-based systems, including Darwin and Mac \s-1OS\s0 X. The macro
-\&\f(CW\*(C`_\|_NEXT_RUNTIME_\|_\*(C'\fR is predefined if (and only if) this option is
-used.
-.IP "\fB\-fno\-nil\-receivers\fR" 4
-.IX Item "-fno-nil-receivers"
-Assume that all Objective-C message dispatches (\f(CW\*(C`[receiver
-message:arg]\*(C'\fR) in this translation unit ensure that the receiver is
-not \f(CW\*(C`nil\*(C'\fR. This allows for more efficient entry points in the
-runtime to be used. This option is only available in conjunction with
-the NeXT runtime and \s-1ABI\s0 version 0 or 1.
-.IP "\fB\-fobjc\-abi\-version=\fR\fIn\fR" 4
-.IX Item "-fobjc-abi-version=n"
-Use version \fIn\fR of the Objective-C \s-1ABI\s0 for the selected runtime.
-This option is currently supported only for the NeXT runtime. In that
-case, Version 0 is the traditional (32\-bit) \s-1ABI\s0 without support for
-properties and other Objective-C 2.0 additions. Version 1 is the
-traditional (32\-bit) \s-1ABI\s0 with support for properties and other
-Objective-C 2.0 additions. Version 2 is the modern (64\-bit) \s-1ABI\s0. If
-nothing is specified, the default is Version 0 on 32\-bit target
-machines, and Version 2 on 64\-bit target machines.
-.IP "\fB\-fobjc\-call\-cxx\-cdtors\fR" 4
-.IX Item "-fobjc-call-cxx-cdtors"
-For each Objective-C class, check if any of its instance variables is a
-\&\*(C+ object with a non-trivial default constructor. If so, synthesize a
-special \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR instance method that will run
-non-trivial default constructors on any such instance variables, in order,
-and then return \f(CW\*(C`self\*(C'\fR. Similarly, check if any instance variable
-is a \*(C+ object with a non-trivial destructor, and if so, synthesize a
-special \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR method that will run
-all such default destructors, in reverse order.
-.Sp
-The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR
-methods thusly generated will only operate on instance variables
-declared in the current Objective-C class, and not those inherited
-from superclasses. It is the responsibility of the Objective-C
-runtime to invoke all such methods in an object's inheritance
-hierarchy. The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR methods will be invoked
-by the runtime immediately after a new object instance is allocated;
-the \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods will be invoked immediately
-before the runtime deallocates an object instance.
-.Sp
-As of this writing, only the NeXT runtime on Mac \s-1OS\s0 X 10.4 and later has
-support for invoking the \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and
-\&\f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods.
-.IP "\fB\-fobjc\-direct\-dispatch\fR" 4
-.IX Item "-fobjc-direct-dispatch"
-Allow fast jumps to the message dispatcher. On Darwin this is
-accomplished via the comm page.
-.IP "\fB\-fobjc\-exceptions\fR" 4
-.IX Item "-fobjc-exceptions"
-Enable syntactic support for structured exception handling in
-Objective-C, similar to what is offered by \*(C+ and Java. This option
-is required to use the Objective-C keywords \f(CW@try\fR,
-\&\f(CW@throw\fR, \f(CW@catch\fR, \f(CW@finally\fR and
-\&\f(CW@synchronized\fR. This option is available with both the \s-1GNU\s0
-runtime and the NeXT runtime (but not available in conjunction with
-the NeXT runtime on Mac \s-1OS\s0 X 10.2 and earlier).
-.IP "\fB\-fobjc\-gc\fR" 4
-.IX Item "-fobjc-gc"
-Enable garbage collection (\s-1GC\s0) in Objective-C and Objective\-\*(C+
-programs. This option is only available with the NeXT runtime; the
-\&\s-1GNU\s0 runtime has a different garbage collection implementation that
-does not require special compiler flags.
-.IP "\fB\-fobjc\-nilcheck\fR" 4
-.IX Item "-fobjc-nilcheck"
-For the NeXT runtime with version 2 of the \s-1ABI\s0, check for a nil
-receiver in method invocations before doing the actual method call.
-This is the default and can be disabled using
-\&\fB\-fno\-objc\-nilcheck\fR. Class methods and super calls are never
-checked for nil in this way no matter what this flag is set to.
-Currently this flag does nothing when the \s-1GNU\s0 runtime, or an older
-version of the NeXT runtime \s-1ABI\s0, is used.
-.IP "\fB\-fobjc\-std=objc1\fR" 4
-.IX Item "-fobjc-std=objc1"
-Conform to the language syntax of Objective-C 1.0, the language
-recognized by \s-1GCC\s0 4.0. This only affects the Objective-C additions to
-the C/\*(C+ language; it does not affect conformance to C/\*(C+ standards,
-which is controlled by the separate C/\*(C+ dialect option flags. When
-this option is used with the Objective-C or Objective\-\*(C+ compiler,
-any Objective-C syntax that is not recognized by \s-1GCC\s0 4.0 is rejected.
-This is useful if you need to make sure that your Objective-C code can
-be compiled with older versions of \s-1GCC\s0.
-.IP "\fB\-freplace\-objc\-classes\fR" 4
-.IX Item "-freplace-objc-classes"
-Emit a special marker instructing \fB\f(BIld\fB\|(1)\fR not to statically link in
-the resulting object file, and allow \fB\f(BIdyld\fB\|(1)\fR to load it in at
-run time instead. This is used in conjunction with the Fix-and-Continue
-debugging mode, where the object file in question may be recompiled and
-dynamically reloaded in the course of program execution, without the need
-to restart the program itself. Currently, Fix-and-Continue functionality
-is only available in conjunction with the NeXT runtime on Mac \s-1OS\s0 X 10.3
-and later.
-.IP "\fB\-fzero\-link\fR" 4
-.IX Item "-fzero-link"
-When compiling for the NeXT runtime, the compiler ordinarily replaces calls
-to \f(CW\*(C`objc_getClass("...")\*(C'\fR (when the name of the class is known at
-compile time) with static class references that get initialized at load time,
-which improves run-time performance. Specifying the \fB\-fzero\-link\fR flag
-suppresses this behavior and causes calls to \f(CW\*(C`objc_getClass("...")\*(C'\fR
-to be retained. This is useful in Zero-Link debugging mode, since it allows
-for individual class implementations to be modified during program execution.
-The \s-1GNU\s0 runtime currently always retains calls to \f(CW\*(C`objc_get_class("...")\*(C'\fR
-regardless of command line options.
-.IP "\fB\-gen\-decls\fR" 4
-.IX Item "-gen-decls"
-Dump interface declarations for all classes seen in the source file to a
-file named \fI\fIsourcename\fI.decl\fR.
-.IP "\fB\-Wassign\-intercept\fR (Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wassign-intercept (Objective-C and Objective- only)"
-Warn whenever an Objective-C assignment is being intercepted by the
-garbage collector.
-.IP "\fB\-Wno\-protocol\fR (Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wno-protocol (Objective-C and Objective- only)"
-If a class is declared to implement a protocol, a warning is issued for
-every method in the protocol that is not implemented by the class. The
-default behavior is to issue a warning for every method not explicitly
-implemented in the class, even if a method implementation is inherited
-from the superclass. If you use the \fB\-Wno\-protocol\fR option, then
-methods inherited from the superclass are considered to be implemented,
-and no warning is issued for them.
-.IP "\fB\-Wselector\fR (Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wselector (Objective-C and Objective- only)"
-Warn if multiple methods of different types for the same selector are
-found during compilation. The check is performed on the list of methods
-in the final stage of compilation. Additionally, a check is performed
-for each selector appearing in a \f(CW\*(C`@selector(...)\*(C'\fR
-expression, and a corresponding method for that selector has been found
-during compilation. Because these checks scan the method table only at
-the end of compilation, these warnings are not produced if the final
-stage of compilation is not reached, for example because an error is
-found during compilation, or because the \fB\-fsyntax\-only\fR option is
-being used.
-.IP "\fB\-Wstrict\-selector\-match\fR (Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wstrict-selector-match (Objective-C and Objective- only)"
-Warn if multiple methods with differing argument and/or return types are
-found for a given selector when attempting to send a message using this
-selector to a receiver of type \f(CW\*(C`id\*(C'\fR or \f(CW\*(C`Class\*(C'\fR. When this flag
-is off (which is the default behavior), the compiler will omit such warnings
-if any differences found are confined to types which share the same size
-and alignment.
-.IP "\fB\-Wundeclared\-selector\fR (Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wundeclared-selector (Objective-C and Objective- only)"
-Warn if a \f(CW\*(C`@selector(...)\*(C'\fR expression referring to an
-undeclared selector is found. A selector is considered undeclared if no
-method with that name has been declared before the
-\&\f(CW\*(C`@selector(...)\*(C'\fR expression, either explicitly in an
-\&\f(CW@interface\fR or \f(CW@protocol\fR declaration, or implicitly in
-an \f(CW@implementation\fR section. This option always performs its
-checks as soon as a \f(CW\*(C`@selector(...)\*(C'\fR expression is found,
-while \fB\-Wselector\fR only performs its checks in the final stage of
-compilation. This also enforces the coding style convention
-that methods and selectors must be declared before being used.
-.IP "\fB\-print\-objc\-runtime\-info\fR" 4
-.IX Item "-print-objc-runtime-info"
-Generate C header describing the largest structure that is passed by
-value, if any.
-.SS "Options to Control Diagnostic Messages Formatting"
-.IX Subsection "Options to Control Diagnostic Messages Formatting"
-Traditionally, diagnostic messages have been formatted irrespective of
-the output device's aspect (e.g. its width, ...). The options described
-below can be used to control the diagnostic messages formatting
-algorithm, e.g. how many characters per line, how often source location
-information should be reported. Right now, only the \*(C+ front end can
-honor these options. However it is expected, in the near future, that
-the remaining front ends would be able to digest them correctly.
-.IP "\fB\-fmessage\-length=\fR\fIn\fR" 4
-.IX Item "-fmessage-length=n"
-Try to format error messages so that they fit on lines of about \fIn\fR
-characters. The default is 72 characters for \fBg++\fR and 0 for the rest of
-the front ends supported by \s-1GCC\s0. If \fIn\fR is zero, then no
-line-wrapping will be done; each error message will appear on a single
-line.
-.IP "\fB\-fdiagnostics\-show\-location=once\fR" 4
-.IX Item "-fdiagnostics-show-location=once"
-Only meaningful in line-wrapping mode. Instructs the diagnostic messages
-reporter to emit \fIonce\fR source location information; that is, in
-case the message is too long to fit on a single physical line and has to
-be wrapped, the source location won't be emitted (as prefix) again,
-over and over, in subsequent continuation lines. This is the default
-behavior.
-.IP "\fB\-fdiagnostics\-show\-location=every\-line\fR" 4
-.IX Item "-fdiagnostics-show-location=every-line"
-Only meaningful in line-wrapping mode. Instructs the diagnostic
-messages reporter to emit the same source location information (as
-prefix) for physical lines that result from the process of breaking
-a message which is too long to fit on a single line.
-.IP "\fB\-fno\-diagnostics\-show\-option\fR" 4
-.IX Item "-fno-diagnostics-show-option"
-By default, each diagnostic emitted includes text which indicates the
-command line option that directly controls the diagnostic (if such an
-option is known to the diagnostic machinery). Specifying the
-\&\fB\-fno\-diagnostics\-show\-option\fR flag suppresses that behavior.
-.IP "\fB\-Wcoverage\-mismatch\fR" 4
-.IX Item "-Wcoverage-mismatch"
-Warn if feedback profiles do not match when using the
-\&\fB\-fprofile\-use\fR option.
-If a source file was changed between \fB\-fprofile\-gen\fR and
-\&\fB\-fprofile\-use\fR, the files with the profile feedback can fail
-to match the source file and \s-1GCC\s0 can not use the profile feedback
-information. By default, this warning is enabled and is treated as an
-error. \fB\-Wno\-coverage\-mismatch\fR can be used to disable the
-warning or \fB\-Wno\-error=coverage\-mismatch\fR can be used to
-disable the error. Disable the error for this warning can result in
-poorly optimized code, so disabling the error is useful only in the
-case of very minor changes such as bug fixes to an existing code-base.
-Completely disabling the warning is not recommended.
-.SS "Options to Request or Suppress Warnings"
-.IX Subsection "Options to Request or Suppress Warnings"
-Warnings are diagnostic messages that report constructions which
-are not inherently erroneous but which are risky or suggest there
-may have been an error.
-.PP
-The following language-independent options do not enable specific
-warnings but control the kinds of diagnostics produced by \s-1GCC\s0.
-.IP "\fB\-fsyntax\-only\fR" 4
-.IX Item "-fsyntax-only"
-Check the code for syntax errors, but don't do anything beyond that.
-.IP "\fB\-fmax\-errors=\fR\fIn\fR" 4
-.IX Item "-fmax-errors=n"
-Limits the maximum number of error messages to \fIn\fR, at which point
-\&\s-1GCC\s0 bails out rather than attempting to continue processing the source
-code. If \fIn\fR is 0 (the default), there is no limit on the number
-of error messages produced. If \fB\-Wfatal\-errors\fR is also
-specified, then \fB\-Wfatal\-errors\fR takes precedence over this
-option.
-.IP "\fB\-w\fR" 4
-.IX Item "-w"
-Inhibit all warning messages.
-.IP "\fB\-Werror\fR" 4
-.IX Item "-Werror"
-Make all warnings into errors.
-.IP "\fB\-Werror=\fR" 4
-.IX Item "-Werror="
-Make the specified warning into an error. The specifier for a warning
-is appended, for example \fB\-Werror=switch\fR turns the warnings
-controlled by \fB\-Wswitch\fR into errors. This switch takes a
-negative form, to be used to negate \fB\-Werror\fR for specific
-warnings, for example \fB\-Wno\-error=switch\fR makes
-\&\fB\-Wswitch\fR warnings not be errors, even when \fB\-Werror\fR
-is in effect.
-.Sp
-The warning message for each controllable warning includes the
-option which controls the warning. That option can then be used with
-\&\fB\-Werror=\fR and \fB\-Wno\-error=\fR as described above.
-(Printing of the option in the warning message can be disabled using the
-\&\fB\-fno\-diagnostics\-show\-option\fR flag.)
-.Sp
-Note that specifying \fB\-Werror=\fR\fIfoo\fR automatically implies
-\&\fB\-W\fR\fIfoo\fR. However, \fB\-Wno\-error=\fR\fIfoo\fR does not
-imply anything.
-.IP "\fB\-Wfatal\-errors\fR" 4
-.IX Item "-Wfatal-errors"
-This option causes the compiler to abort compilation on the first error
-occurred rather than trying to keep going and printing further error
-messages.
-.PP
-You can request many specific warnings with options beginning
-\&\fB\-W\fR, for example \fB\-Wimplicit\fR to request warnings on
-implicit declarations. Each of these specific warning options also
-has a negative form beginning \fB\-Wno\-\fR to turn off warnings; for
-example, \fB\-Wno\-implicit\fR. This manual lists only one of the
-two forms, whichever is not the default. For further,
-language-specific options also refer to \fB\*(C+ Dialect Options\fR and
-\&\fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
-.PP
-When an unrecognized warning option is requested (e.g.,
-\&\fB\-Wunknown\-warning\fR), \s-1GCC\s0 will emit a diagnostic stating
-that the option is not recognized. However, if the \fB\-Wno\-\fR form
-is used, the behavior is slightly different: No diagnostic will be
-produced for \fB\-Wno\-unknown\-warning\fR unless other diagnostics
-are being produced. This allows the use of new \fB\-Wno\-\fR options
-with old compilers, but if something goes wrong, the compiler will
-warn that an unrecognized option was used.
-.IP "\fB\-pedantic\fR" 4
-.IX Item "-pedantic"
-Issue all the warnings demanded by strict \s-1ISO\s0 C and \s-1ISO\s0 \*(C+;
-reject all programs that use forbidden extensions, and some other
-programs that do not follow \s-1ISO\s0 C and \s-1ISO\s0 \*(C+. For \s-1ISO\s0 C, follows the
-version of the \s-1ISO\s0 C standard specified by any \fB\-std\fR option used.
-.Sp
-Valid \s-1ISO\s0 C and \s-1ISO\s0 \*(C+ programs should compile properly with or without
-this option (though a rare few will require \fB\-ansi\fR or a
-\&\fB\-std\fR option specifying the required version of \s-1ISO\s0 C). However,
-without this option, certain \s-1GNU\s0 extensions and traditional C and \*(C+
-features are supported as well. With this option, they are rejected.
-.Sp
-\&\fB\-pedantic\fR does not cause warning messages for use of the
-alternate keywords whose names begin and end with \fB_\|_\fR. Pedantic
-warnings are also disabled in the expression that follows
-\&\f(CW\*(C`_\|_extension_\|_\*(C'\fR. However, only system header files should use
-these escape routes; application programs should avoid them.
-.Sp
-Some users try to use \fB\-pedantic\fR to check programs for strict \s-1ISO\s0
-C conformance. They soon find that it does not do quite what they want:
-it finds some non-ISO practices, but not all\-\-\-only those for which
-\&\s-1ISO\s0 C \fIrequires\fR a diagnostic, and some others for which
-diagnostics have been added.
-.Sp
-A feature to report any failure to conform to \s-1ISO\s0 C might be useful in
-some instances, but would require considerable additional work and would
-be quite different from \fB\-pedantic\fR. We don't have plans to
-support such a feature in the near future.
-.Sp
-Where the standard specified with \fB\-std\fR represents a \s-1GNU\s0
-extended dialect of C, such as \fBgnu90\fR or \fBgnu99\fR, there is a
-corresponding \fIbase standard\fR, the version of \s-1ISO\s0 C on which the \s-1GNU\s0
-extended dialect is based. Warnings from \fB\-pedantic\fR are given
-where they are required by the base standard. (It would not make sense
-for such warnings to be given only for features not in the specified \s-1GNU\s0
-C dialect, since by definition the \s-1GNU\s0 dialects of C include all
-features the compiler supports with the given option, and there would be
-nothing to warn about.)
-.IP "\fB\-pedantic\-errors\fR" 4
-.IX Item "-pedantic-errors"
-Like \fB\-pedantic\fR, except that errors are produced rather than
-warnings.
-.IP "\fB\-Wall\fR" 4
-.IX Item "-Wall"
-This enables all the warnings about constructions that some users
-consider questionable, and that are easy to avoid (or modify to
-prevent the warning), even in conjunction with macros. This also
-enables some language-specific warnings described in \fB\*(C+ Dialect
-Options\fR and \fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
-.Sp
-\&\fB\-Wall\fR turns on the following warning flags:
-.Sp
-\&\fB\-Waddress
-\&\-Warray\-bounds\fR (only with\fB \fR\fB\-O2\fR)
-\&\fB\-Wc++0x\-compat
-\&\-Wchar\-subscripts
-\&\-Wenum\-compare\fR (in C/Objc; this is on by default in \*(C+)
-\&\fB\-Wimplicit\-int\fR (C and Objective-C only)
-\&\fB\-Wimplicit\-function\-declaration\fR (C and Objective-C only)
-\&\fB\-Wcomment
-\&\-Wformat
-\&\-Wmain\fR (only for C/ObjC and unless\fB \fR\fB\-ffreestanding\fR)
-\&\fB\-Wmaybe\-uninitialized
-\&\-Wmissing\-braces
-\&\-Wnonnull
-\&\-Wparentheses
-\&\-Wpointer\-sign
-\&\-Wreorder
-\&\-Wreturn\-type
-\&\-Wripa\-opt\-mismatch
-\&\-Wsequence\-point
-\&\-Wsign\-compare\fR (only in \*(C+)
-\&\fB\-Wstrict\-aliasing
-\&\-Wstrict\-overflow=1
-\&\-Wswitch
-\&\-Wtrigraphs
-\&\-Wuninitialized
-\&\-Wunknown\-pragmas
-\&\-Wunused\-function
-\&\-Wunused\-label
-\&\-Wunused\-value
-\&\-Wunused\-variable
-\&\-Wvolatile\-register\-var\fR
-.Sp
-Note that some warning flags are not implied by \fB\-Wall\fR. Some of
-them warn about constructions that users generally do not consider
-questionable, but which occasionally you might wish to check for;
-others warn about constructions that are necessary or hard to avoid in
-some cases, and there is no simple way to modify the code to suppress
-the warning. Some of them are enabled by \fB\-Wextra\fR but many of
-them must be enabled individually.
-.IP "\fB\-Wextra\fR" 4
-.IX Item "-Wextra"
-This enables some extra warning flags that are not enabled by
-\&\fB\-Wall\fR. (This option used to be called \fB\-W\fR. The older
-name is still supported, but the newer name is more descriptive.)
-.Sp
-\&\fB\-Wclobbered
-\&\-Wempty\-body
-\&\-Wignored\-qualifiers
-\&\-Wmissing\-field\-initializers
-\&\-Wmissing\-parameter\-type\fR (C only)
-\&\fB\-Wold\-style\-declaration\fR (C only)
-\&\fB\-Woverride\-init
-\&\-Wsign\-compare
-\&\-Wtype\-limits
-\&\-Wuninitialized
-\&\-Wunused\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)
-\&\fB\-Wunused\-but\-set\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR) \fB \fR
-.Sp
-The option \fB\-Wextra\fR also prints warning messages for the
-following cases:
-.RS 4
-.IP "\(bu" 4
-A pointer is compared against integer zero with \fB<\fR, \fB<=\fR,
-\&\fB>\fR, or \fB>=\fR.
-.IP "\(bu" 4
-(\*(C+ only) An enumerator and a non-enumerator both appear in a
-conditional expression.
-.IP "\(bu" 4
-(\*(C+ only) Ambiguous virtual bases.
-.IP "\(bu" 4
-(\*(C+ only) Subscripting an array which has been declared \fBregister\fR.
-.IP "\(bu" 4
-(\*(C+ only) Taking the address of a variable which has been declared
-\&\fBregister\fR.
-.IP "\(bu" 4
-(\*(C+ only) A base class is not initialized in a derived class' copy
-constructor.
-.RE
-.RS 4
-.RE
-.IP "\fB\-Wchar\-subscripts\fR" 4
-.IX Item "-Wchar-subscripts"
-Warn if an array subscript has type \f(CW\*(C`char\*(C'\fR. This is a common cause
-of error, as programmers often forget that this type is signed on some
-machines.
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wcomment\fR" 4
-.IX Item "-Wcomment"
-Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
-comment, or whenever a Backslash-Newline appears in a \fB//\fR comment.
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wno\-cpp\fR" 4
-.IX Item "-Wno-cpp"
-(C, Objective-C, \*(C+, Objective\-\*(C+ and Fortran only)
-.Sp
-Suppress warning messages emitted by \f(CW\*(C`#warning\*(C'\fR directives.
-.IP "\fB\-Wdouble\-promotion\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wdouble-promotion (C, , Objective-C and Objective- only)"
-Give a warning when a value of type \f(CW\*(C`float\*(C'\fR is implicitly
-promoted to \f(CW\*(C`double\*(C'\fR. CPUs with a 32\-bit \*(L"single-precision\*(R"
-floating-point unit implement \f(CW\*(C`float\*(C'\fR in hardware, but emulate
-\&\f(CW\*(C`double\*(C'\fR in software. On such a machine, doing computations
-using \f(CW\*(C`double\*(C'\fR values is much more expensive because of the
-overhead required for software emulation.
-.Sp
-It is easy to accidentally do computations with \f(CW\*(C`double\*(C'\fR because
-floating-point literals are implicitly of type \f(CW\*(C`double\*(C'\fR. For
-example, in:
-.Sp
-.Vb 4
-\& float area(float radius)
-\& {
-\& return 3.14159 * radius * radius;
-\& }
-.Ve
-.Sp
-the compiler will perform the entire computation with \f(CW\*(C`double\*(C'\fR
-because the floating-point literal is a \f(CW\*(C`double\*(C'\fR.
-.IP "\fB\-Wformat\fR" 4
-.IX Item "-Wformat"
-Check calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR, etc., to make sure that
-the arguments supplied have types appropriate to the format string
-specified, and that the conversions specified in the format string make
-sense. This includes standard functions, and others specified by format
-attributes, in the \f(CW\*(C`printf\*(C'\fR,
-\&\f(CW\*(C`scanf\*(C'\fR, \f(CW\*(C`strftime\*(C'\fR and \f(CW\*(C`strfmon\*(C'\fR (an X/Open extension,
-not in the C standard) families (or other target-specific families).
-Which functions are checked without format attributes having been
-specified depends on the standard version selected, and such checks of
-functions without the attribute specified are disabled by
-\&\fB\-ffreestanding\fR or \fB\-fno\-builtin\fR.
-.Sp
-The formats are checked against the format features supported by \s-1GNU\s0
-libc version 2.2. These include all \s-1ISO\s0 C90 and C99 features, as well
-as features from the Single Unix Specification and some \s-1BSD\s0 and \s-1GNU\s0
-extensions. Other library implementations may not support all these
-features; \s-1GCC\s0 does not support warning about features that go beyond a
-particular library's limitations. However, if \fB\-pedantic\fR is used
-with \fB\-Wformat\fR, warnings will be given about format features not
-in the selected standard version (but not for \f(CW\*(C`strfmon\*(C'\fR formats,
-since those are not in any version of the C standard).
-.Sp
-Since \fB\-Wformat\fR also checks for null format arguments for
-several functions, \fB\-Wformat\fR also implies \fB\-Wnonnull\fR.
-.Sp
-\&\fB\-Wformat\fR is included in \fB\-Wall\fR. For more control over some
-aspects of format checking, the options \fB\-Wformat\-y2k\fR,
-\&\fB\-Wno\-format\-extra\-args\fR, \fB\-Wno\-format\-zero\-length\fR,
-\&\fB\-Wformat\-nonliteral\fR, \fB\-Wformat\-security\fR, and
-\&\fB\-Wformat=2\fR are available, but are not included in \fB\-Wall\fR.
-.IP "\fB\-Wformat\-y2k\fR" 4
-.IX Item "-Wformat-y2k"
-If \fB\-Wformat\fR is specified, also warn about \f(CW\*(C`strftime\*(C'\fR
-formats which may yield only a two-digit year.
-.IP "\fB\-Wno\-format\-contains\-nul\fR" 4
-.IX Item "-Wno-format-contains-nul"
-If \fB\-Wformat\fR is specified, do not warn about format strings that
-contain \s-1NUL\s0 bytes.
-.IP "\fB\-Wno\-format\-extra\-args\fR" 4
-.IX Item "-Wno-format-extra-args"
-If \fB\-Wformat\fR is specified, do not warn about excess arguments to a
-\&\f(CW\*(C`printf\*(C'\fR or \f(CW\*(C`scanf\*(C'\fR format function. The C standard specifies
-that such arguments are ignored.
-.Sp
-Where the unused arguments lie between used arguments that are
-specified with \fB$\fR operand number specifications, normally
-warnings are still given, since the implementation could not know what
-type to pass to \f(CW\*(C`va_arg\*(C'\fR to skip the unused arguments. However,
-in the case of \f(CW\*(C`scanf\*(C'\fR formats, this option will suppress the
-warning if the unused arguments are all pointers, since the Single
-Unix Specification says that such unused arguments are allowed.
-.IP "\fB\-Wno\-format\-zero\-length\fR (C and Objective-C only)" 4
-.IX Item "-Wno-format-zero-length (C and Objective-C only)"
-If \fB\-Wformat\fR is specified, do not warn about zero-length formats.
-The C standard specifies that zero-length formats are allowed.
-.IP "\fB\-Wformat\-nonliteral\fR" 4
-.IX Item "-Wformat-nonliteral"
-If \fB\-Wformat\fR is specified, also warn if the format string is not a
-string literal and so cannot be checked, unless the format function
-takes its format arguments as a \f(CW\*(C`va_list\*(C'\fR.
-.IP "\fB\-Wformat\-security\fR" 4
-.IX Item "-Wformat-security"
-If \fB\-Wformat\fR is specified, also warn about uses of format
-functions that represent possible security problems. At present, this
-warns about calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR functions where the
-format string is not a string literal and there are no format arguments,
-as in \f(CW\*(C`printf (foo);\*(C'\fR. This may be a security hole if the format
-string came from untrusted input and contains \fB\f(CB%n\fB\fR. (This is
-currently a subset of what \fB\-Wformat\-nonliteral\fR warns about, but
-in future warnings may be added to \fB\-Wformat\-security\fR that are not
-included in \fB\-Wformat\-nonliteral\fR.)
-.IP "\fB\-Wformat=2\fR" 4
-.IX Item "-Wformat=2"
-Enable \fB\-Wformat\fR plus format checks not included in
-\&\fB\-Wformat\fR. Currently equivalent to \fB\-Wformat
-\&\-Wformat\-nonliteral \-Wformat\-security \-Wformat\-y2k\fR.
-.IP "\fB\-Wnonnull\fR (C, \*(C+, Objective-C, and Objective\-\*(C+ only)" 4
-.IX Item "-Wnonnull (C, , Objective-C, and Objective- only)"
-Warn about passing a null pointer for arguments marked as
-requiring a non-null value by the \f(CW\*(C`nonnull\*(C'\fR function attribute.
-.Sp
-\&\fB\-Wnonnull\fR is included in \fB\-Wall\fR and \fB\-Wformat\fR. It
-can be disabled with the \fB\-Wno\-nonnull\fR option.
-.IP "\fB\-Winit\-self\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Winit-self (C, , Objective-C and Objective- only)"
-Warn about uninitialized variables which are initialized with themselves.
-Note this option can only be used with the \fB\-Wuninitialized\fR option.
-.Sp
-For example, \s-1GCC\s0 will warn about \f(CW\*(C`i\*(C'\fR being uninitialized in the
-following snippet only when \fB\-Winit\-self\fR has been specified:
-.Sp
-.Vb 5
-\& int f()
-\& {
-\& int i = i;
-\& return i;
-\& }
-.Ve
-.IP "\fB\-Wimplicit\-int\fR (C and Objective-C only)" 4
-.IX Item "-Wimplicit-int (C and Objective-C only)"
-Warn when a declaration does not specify a type.
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wimplicit\-function\-declaration\fR (C and Objective-C only)" 4
-.IX Item "-Wimplicit-function-declaration (C and Objective-C only)"
-Give a warning whenever a function is used before being declared. In
-C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR), this warning is
-enabled by default and it is made into an error by
-\&\fB\-pedantic\-errors\fR. This warning is also enabled by
-\&\fB\-Wall\fR.
-.IP "\fB\-Wimplicit\fR (C and Objective-C only)" 4
-.IX Item "-Wimplicit (C and Objective-C only)"
-Same as \fB\-Wimplicit\-int\fR and \fB\-Wimplicit\-function\-declaration\fR.
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wignored\-qualifiers\fR (C and \*(C+ only)" 4
-.IX Item "-Wignored-qualifiers (C and only)"
-Warn if the return type of a function has a type qualifier
-such as \f(CW\*(C`const\*(C'\fR. For \s-1ISO\s0 C such a type qualifier has no effect,
-since the value returned by a function is not an lvalue.
-For \*(C+, the warning is only emitted for scalar types or \f(CW\*(C`void\*(C'\fR.
-\&\s-1ISO\s0 C prohibits qualified \f(CW\*(C`void\*(C'\fR return types on function
-definitions, so such return types always receive a warning
-even without this option.
-.Sp
-This warning is also enabled by \fB\-Wextra\fR.
-.IP "\fB\-Wmain\fR" 4
-.IX Item "-Wmain"
-Warn if the type of \fBmain\fR is suspicious. \fBmain\fR should be
-a function with external linkage, returning int, taking either zero
-arguments, two, or three arguments of appropriate types. This warning
-is enabled by default in \*(C+ and is enabled by either \fB\-Wall\fR
-or \fB\-pedantic\fR.
-.IP "\fB\-Wmissing\-braces\fR" 4
-.IX Item "-Wmissing-braces"
-Warn if an aggregate or union initializer is not fully bracketed. In
-the following example, the initializer for \fBa\fR is not fully
-bracketed, but that for \fBb\fR is fully bracketed.
-.Sp
-.Vb 2
-\& int a[2][2] = { 0, 1, 2, 3 };
-\& int b[2][2] = { { 0, 1 }, { 2, 3 } };
-.Ve
-.Sp
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wmissing\-include\-dirs\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
-.IX Item "-Wmissing-include-dirs (C, , Objective-C and Objective- only)"
-Warn if a user-supplied include directory does not exist.
-.IP "\fB\-Wparentheses\fR" 4
-.IX Item "-Wparentheses"
-Warn if parentheses are omitted in certain contexts, such
-as when there is an assignment in a context where a truth value
-is expected, or when operators are nested whose precedence people
-often get confused about.
-.Sp
-Also warn if a comparison like \fBx<=y<=z\fR appears; this is
-equivalent to \fB(x<=y ? 1 : 0) <= z\fR, which is a different
-interpretation from that of ordinary mathematical notation.
-.Sp
-Also warn about constructions where there may be confusion to which
-\&\f(CW\*(C`if\*(C'\fR statement an \f(CW\*(C`else\*(C'\fR branch belongs. Here is an example of
-such a case:
-.Sp
-.Vb 7
-\& {
-\& if (a)
-\& if (b)
-\& foo ();
-\& else
-\& bar ();
-\& }
-.Ve
-.Sp
-In C/\*(C+, every \f(CW\*(C`else\*(C'\fR branch belongs to the innermost possible
-\&\f(CW\*(C`if\*(C'\fR statement, which in this example is \f(CW\*(C`if (b)\*(C'\fR. This is
-often not what the programmer expected, as illustrated in the above
-example by indentation the programmer chose. When there is the
-potential for this confusion, \s-1GCC\s0 will issue a warning when this flag
-is specified. To eliminate the warning, add explicit braces around
-the innermost \f(CW\*(C`if\*(C'\fR statement so there is no way the \f(CW\*(C`else\*(C'\fR
-could belong to the enclosing \f(CW\*(C`if\*(C'\fR. The resulting code would
-look like this:
-.Sp
-.Vb 9
-\& {
-\& if (a)
-\& {
-\& if (b)
-\& foo ();
-\& else
-\& bar ();
-\& }
-\& }
-.Ve
-.Sp
-Also warn for dangerous uses of the
-?: with omitted middle operand \s-1GNU\s0 extension. When the condition
-in the ?: operator is a boolean expression the omitted value will
-be always 1. Often the user expects it to be a value computed
-inside the conditional expression instead.
-.Sp
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wsequence\-point\fR" 4
-.IX Item "-Wsequence-point"
-Warn about code that may have undefined semantics because of violations
-of sequence point rules in the C and \*(C+ standards.
-.Sp
-The C and \*(C+ standards defines the order in which expressions in a C/\*(C+
-program are evaluated in terms of \fIsequence points\fR, which represent
-a partial ordering between the execution of parts of the program: those
-executed before the sequence point, and those executed after it. These
-occur after the evaluation of a full expression (one which is not part
-of a larger expression), after the evaluation of the first operand of a
-\&\f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, \f(CW\*(C`? :\*(C'\fR or \f(CW\*(C`,\*(C'\fR (comma) operator, before a
-function is called (but after the evaluation of its arguments and the
-expression denoting the called function), and in certain other places.
-Other than as expressed by the sequence point rules, the order of
-evaluation of subexpressions of an expression is not specified. All
-these rules describe only a partial order rather than a total order,
-since, for example, if two functions are called within one expression
-with no sequence point between them, the order in which the functions
-are called is not specified. However, the standards committee have
-ruled that function calls do not overlap.
-.Sp
-It is not specified when between sequence points modifications to the
-values of objects take effect. Programs whose behavior depends on this
-have undefined behavior; the C and \*(C+ standards specify that \*(L"Between
-the previous and next sequence point an object shall have its stored
-value modified at most once by the evaluation of an expression.
-Furthermore, the prior value shall be read only to determine the value
-to be stored.\*(R". If a program breaks these rules, the results on any
-particular implementation are entirely unpredictable.
-.Sp
-Examples of code with undefined behavior are \f(CW\*(C`a = a++;\*(C'\fR, \f(CW\*(C`a[n]
-= b[n++]\*(C'\fR and \f(CW\*(C`a[i++] = i;\*(C'\fR. Some more complicated cases are not
-diagnosed by this option, and it may give an occasional false positive
-result, but in general it has been found fairly effective at detecting
-this sort of problem in programs.
-.Sp
-The standard is worded confusingly, therefore there is some debate
-over the precise meaning of the sequence point rules in subtle cases.
-Links to discussions of the problem, including proposed formal
-definitions, may be found on the \s-1GCC\s0 readings page, at
-<\fBhttp://gcc.gnu.org/readings.html\fR>.
-.Sp
-This warning is enabled by \fB\-Wall\fR for C and \*(C+.
-.IP "\fB\-Wself\-assign\fR" 4
-.IX Item "-Wself-assign"
-Warn about self-assignment and self-initialization. This warning is intended
-for detecting accidental self-assignment due to typos, and therefore does
-not warn on a statement that is semantically a self-assignment after
-constant folding. Here is an example of what will trigger a self-assign
-warning and what will not:
-.Sp
-.Vb 6
-\& void func()
-\& {
-\& int i = 2;
-\& int x = x; /* warn */
-\& float f = 5.0;
-\& double a[3];
-\&
-\& i = i + 0; /* not warn */
-\& f = f / 1; /* not warn */
-\& a[1] = a[1]; /* warn */
-\& i += 0; /* not warn */
-\& }
-.Ve
-.Sp
-In \*(C+ it will not warn on self-assignment of non-POD variables unless
-\&\fB\-Wself\-assign\-non\-pod\fR is also enabled.
-.IP "\fB\-Wself\-assign\-non\-pod\fR" 4
-.IX Item "-Wself-assign-non-pod"
-Warn about self-assignment of non-POD variables. This is a \*(C+\-specific
-warning and only effective when \fB\-Wself\-assign\fR is enabled.
-.Sp
-There are cases where self-assignment might be intentional. For example,
-a \*(C+ programmer might write code to test whether an overloaded
-\&\f(CW\*(C`operator=\*(C'\fR works when the same object is assigned to itself.
-One way to work around the self-assign warning in such cases when this flag
-is enabled is using the functional form \f(CW\*(C`object.operator=(object)\*(C'\fR
-instead of the assignment form \f(CW\*(C`object = object\*(C'\fR, as shown in the
-following example.
-.Sp
-.Vb 3
-\& void test_func()
-\& {
-\& MyType t;
-\&
-\& t.operator=(t); // not warn
-\& t = t; // warn
-\& }
-.Ve
-.IP "\fB\-Wreturn\-type\fR" 4
-.IX Item "-Wreturn-type"
-Warn whenever a function is defined with a return-type that defaults
-to \f(CW\*(C`int\*(C'\fR. Also warn about any \f(CW\*(C`return\*(C'\fR statement with no
-return-value in a function whose return-type is not \f(CW\*(C`void\*(C'\fR
-(falling off the end of the function body is considered returning
-without a value), and about a \f(CW\*(C`return\*(C'\fR statement with an
-expression in a function whose return-type is \f(CW\*(C`void\*(C'\fR.
-.Sp
-For \*(C+, a function without return type always produces a diagnostic
-message, even when \fB\-Wno\-return\-type\fR is specified. The only
-exceptions are \fBmain\fR and functions defined in system headers.
-.Sp
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wripa\-opt\-mismatch\fR" 4
-.IX Item "-Wripa-opt-mismatch"
-When doing an \s-1FDO\s0 build with \fB\-fprofile\-use\fR and \fB\-fripa\fR,
-warn if importing an axuiliary module that was built with a different
-\&\s-1GCC\s0 command line during the profile-generate phase than the primary
-module.
-.Sp
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wswitch\fR" 4
-.IX Item "-Wswitch"
-Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
-and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
-enumeration. (The presence of a \f(CW\*(C`default\*(C'\fR label prevents this
-warning.) \f(CW\*(C`case\*(C'\fR labels outside the enumeration range also
-provoke warnings when this option is used (even if there is a
-\&\f(CW\*(C`default\*(C'\fR label).
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wswitch\-default\fR" 4
-.IX Item "-Wswitch-default"
-Warn whenever a \f(CW\*(C`switch\*(C'\fR statement does not have a \f(CW\*(C`default\*(C'\fR
-case.
-.IP "\fB\-Wswitch\-enum\fR" 4
-.IX Item "-Wswitch-enum"
-Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
-and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
-enumeration. \f(CW\*(C`case\*(C'\fR labels outside the enumeration range also
-provoke warnings when this option is used. The only difference
-between \fB\-Wswitch\fR and this option is that this option gives a
-warning about an omitted enumeration code even if there is a
-\&\f(CW\*(C`default\*(C'\fR label.
-.IP "\fB\-Wsync\-nand\fR (C and \*(C+ only)" 4
-.IX Item "-Wsync-nand (C and only)"
-Warn when \f(CW\*(C`_\|_sync_fetch_and_nand\*(C'\fR and \f(CW\*(C`_\|_sync_nand_and_fetch\*(C'\fR
-built-in functions are used. These functions changed semantics in \s-1GCC\s0 4.4.
-.IP "\fB\-Wthread\-safety\fR" 4
-.IX Item "-Wthread-safety"
-Warn about potential thread safety issues when the code is annotated with
-thread safety attributes.
-.IP "\fBWthread-unguarded-var\fR" 4
-.IX Item "Wthread-unguarded-var"
-Warn about shared variables not properly protected by locks specified in the
-attributes. This flag is effective only with \fB\-Wthread\-safety\fR and
-enabled by default.
-.IP "\fBWthread-unguarded-func\fR" 4
-.IX Item "Wthread-unguarded-func"
-Warn about function calls not properly protected by locks specified in the
-attributes. This flag is effective only with \fB\-Wthread\-safety\fR and
-enabled by default.
-.IP "\fBWthread-mismatched-lock-order\fR" 4
-.IX Item "Wthread-mismatched-lock-order"
-Warn about lock acquisition order inconsistent with what specified in the
-attributes. This flag is effective only with \fB\-Wthread\-safety\fR and
-enabled by default.
-.IP "\fBWthread-mismatched-lock-acq-rel\fR" 4
-.IX Item "Wthread-mismatched-lock-acq-rel"
-Warn about mismatched lock acquisition and release. This flag is effective only
-with \fB\-Wthread\-safety\fR and enabled by default.
-.IP "\fBWthread-reentrant-lock\fR" 4
-.IX Item "Wthread-reentrant-lock"
-Warn about a lock being acquired recursively. This flag is effective only
-with \fB\-Wthread\-safety\fR and enabled by default.
-.IP "\fBWthread-unsupported-lock-name\fR" 4
-.IX Item "Wthread-unsupported-lock-name"
-Warn about uses of unsupported lock names in attributes. This flag is effective
-only with \fB\-Wthread\-safety\fR and disabled by default.
-.IP "\fBWthread-attr-bind-param\fR" 4
-.IX Item "Wthread-attr-bind-param"
-Make the thread safety analysis try to bind the function parameters used in
-the attributes. This flag is effective only with \fB\-Wthread\-safety\fR
-and enabled by default.
-.IP "\fB\-Wtrigraphs\fR" 4
-.IX Item "-Wtrigraphs"
-Warn if any trigraphs are encountered that might change the meaning of
-the program (trigraphs within comments are not warned about).
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wunused\-but\-set\-parameter\fR" 4
-.IX Item "-Wunused-but-set-parameter"
-Warn whenever a function parameter is assigned to, but otherwise unused
-(aside from its declaration).
-.Sp
-To suppress this warning use the \fBunused\fR attribute.
-.Sp
-This warning is also enabled by \fB\-Wunused\fR together with
-\&\fB\-Wextra\fR.
-.IP "\fB\-Wunused\-but\-set\-variable\fR" 4
-.IX Item "-Wunused-but-set-variable"
-Warn whenever a local variable is assigned to, but otherwise unused
-(aside from its declaration).
-This warning is enabled by \fB\-Wall\fR.
-.Sp
-To suppress this warning use the \fBunused\fR attribute.
-.Sp
-This warning is also enabled by \fB\-Wunused\fR, which is enabled
-by \fB\-Wall\fR.
-.IP "\fB\-Wunused\-function\fR" 4
-.IX Item "-Wunused-function"
-Warn whenever a static function is declared but not defined or a
-non-inline static function is unused.
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wunused\-label\fR" 4
-.IX Item "-Wunused-label"
-Warn whenever a label is declared but not used.
-This warning is enabled by \fB\-Wall\fR.
-.Sp
-To suppress this warning use the \fBunused\fR attribute.
-.IP "\fB\-Wunused\-parameter\fR" 4
-.IX Item "-Wunused-parameter"
-Warn whenever a function parameter is unused aside from its declaration.
-.Sp
-To suppress this warning use the \fBunused\fR attribute.
-.IP "\fB\-Wno\-unused\-result\fR" 4
-.IX Item "-Wno-unused-result"
-Do not warn if a caller of a function marked with attribute
-\&\f(CW\*(C`warn_unused_result\*(C'\fR does not use
-its return value. The default is \fB\-Wunused\-result\fR.
-.IP "\fB\-Wunused\-variable\fR" 4
-.IX Item "-Wunused-variable"
-Warn whenever a local variable or non-constant static variable is unused
-aside from its declaration.
-This warning is enabled by \fB\-Wall\fR.
-.Sp
-To suppress this warning use the \fBunused\fR attribute.
-.Sp
-Note that a classic way to avoid \fB\-Wunused\-variable\fR warning is
-using \f(CW\*(C`x = x\*(C'\fR, but that does not work with \fB\-Wself\-assign\fR.
-Use \f(CW\*(C`(void) x\*(C'\fR or \f(CW\*(C`static_cast<void>(x)\*(C'\fR instead.
-.IP "\fB\-Wunused\-value\fR" 4
-.IX Item "-Wunused-value"
-Warn whenever a statement computes a result that is explicitly not
-used. To suppress this warning cast the unused expression to
-\&\fBvoid\fR. This includes an expression-statement or the left-hand
-side of a comma expression that contains no side effects. For example,
-an expression such as \fBx[i,j]\fR will cause a warning, while
-\&\fBx[(void)i,j]\fR will not.
-.Sp
-This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wunused\fR" 4
-.IX Item "-Wunused"
-All the above \fB\-Wunused\fR options combined.
-.Sp
-In order to get a warning about an unused function parameter, you must
-either specify \fB\-Wextra \-Wunused\fR (note that \fB\-Wall\fR implies
-\&\fB\-Wunused\fR), or separately specify \fB\-Wunused\-parameter\fR.
-.IP "\fB\-Wuninitialized\fR" 4
-.IX Item "-Wuninitialized"
-Warn if an automatic variable is used without first being initialized
-or if a variable may be clobbered by a \f(CW\*(C`setjmp\*(C'\fR call. In \*(C+,
-warn if a non-static reference or non-static \fBconst\fR member
-appears in a class without constructors.
-.Sp
-If you want to warn about code which uses the uninitialized value of the
-variable in its own initializer, use the \fB\-Winit\-self\fR option.
-.Sp
-These warnings occur for individual uninitialized or clobbered
-elements of structure, union or array variables as well as for
-variables which are uninitialized or clobbered as a whole. They do
-not occur for variables or elements declared \f(CW\*(C`volatile\*(C'\fR. Because
-these warnings depend on optimization, the exact variables or elements
-for which there are warnings will depend on the precise optimization
-options and version of \s-1GCC\s0 used.
-.Sp
-Note that there may be no warning about a variable that is used only
-to compute a value that itself is never used, because such
-computations may be deleted by data flow analysis before the warnings
-are printed.
-.IP "\fB\-Wmaybe\-uninitialized\fR" 4
-.IX Item "-Wmaybe-uninitialized"
-For an automatic variable, if there exists a path from the function
-entry to a use of the variable that is initialized, but there exist
-some other paths the variable is not initialized, the compiler will
-emit a warning if it can not prove the uninitialized paths do not
-happen at runtime. These warnings are made optional because \s-1GCC\s0 is
-not smart enough to see all the reasons why the code might be correct
-despite appearing to have an error. Here is one example of how
-this can happen:
-.Sp
-.Vb 12
-\& {
-\& int x;
-\& switch (y)
-\& {
-\& case 1: x = 1;
-\& break;
-\& case 2: x = 4;
-\& break;
-\& case 3: x = 5;
-\& }
-\& foo (x);
-\& }
-.Ve
-.Sp
-If the value of \f(CW\*(C`y\*(C'\fR is always 1, 2 or 3, then \f(CW\*(C`x\*(C'\fR is
-always initialized, but \s-1GCC\s0 doesn't know this. To suppress the
-warning, the user needs to provide a default case with \fIassert\fR\|(0) or
-similar code.
-.Sp
-This option also warns when a non-volatile automatic variable might be
-changed by a call to \f(CW\*(C`longjmp\*(C'\fR. These warnings as well are possible
-only in optimizing compilation.
-.Sp
-The compiler sees only the calls to \f(CW\*(C`setjmp\*(C'\fR. It cannot know
-where \f(CW\*(C`longjmp\*(C'\fR will be called; in fact, a signal handler could
-call it at any point in the code. As a result, you may get a warning
-even when there is in fact no problem because \f(CW\*(C`longjmp\*(C'\fR cannot
-in fact be called at the place which would cause a problem.
-.Sp
-Some spurious warnings can be avoided if you declare all the functions
-you use that never return as \f(CW\*(C`noreturn\*(C'\fR.
-.Sp
-This warning is enabled by \fB\-Wall\fR or \fB\-Wextra\fR.
-.IP "\fB\-Wunknown\-pragmas\fR" 4
-.IX Item "-Wunknown-pragmas"
-Warn when a #pragma directive is encountered which is not understood by
-\&\s-1GCC\s0. If this command line option is used, warnings will even be issued
-for unknown pragmas in system header files. This is not the case if
-the warnings were only enabled by the \fB\-Wall\fR command line option.
-.IP "\fB\-Wno\-pragmas\fR" 4
-.IX Item "-Wno-pragmas"
-Do not warn about misuses of pragmas, such as incorrect parameters,
-invalid syntax, or conflicts between pragmas. See also
-\&\fB\-Wunknown\-pragmas\fR.
-.IP "\fB\-Wstrict\-aliasing\fR" 4
-.IX Item "-Wstrict-aliasing"
-This option is only active when \fB\-fstrict\-aliasing\fR is active.
-It warns about code which might break the strict aliasing rules that the
-compiler is using for optimization. The warning does not catch all
-cases, but does attempt to catch the more common pitfalls. It is
-included in \fB\-Wall\fR.
-It is equivalent to \fB\-Wstrict\-aliasing=3\fR
-.IP "\fB\-Wstrict\-aliasing=n\fR" 4
-.IX Item "-Wstrict-aliasing=n"
-This option is only active when \fB\-fstrict\-aliasing\fR is active.
-It warns about code which might break the strict aliasing rules that the
-compiler is using for optimization.
-Higher levels correspond to higher accuracy (fewer false positives).
-Higher levels also correspond to more effort, similar to the way \-O works.
-\&\fB\-Wstrict\-aliasing\fR is equivalent to \fB\-Wstrict\-aliasing=n\fR,
-with n=3.
-.Sp
-Level 1: Most aggressive, quick, least accurate.
-Possibly useful when higher levels
-do not warn but \-fstrict\-aliasing still breaks the code, as it has very few
-false negatives. However, it has many false positives.
-Warns for all pointer conversions between possibly incompatible types,
-even if never dereferenced. Runs in the frontend only.
-.Sp
-Level 2: Aggressive, quick, not too precise.
-May still have many false positives (not as many as level 1 though),
-and few false negatives (but possibly more than level 1).
-Unlike level 1, it only warns when an address is taken. Warns about
-incomplete types. Runs in the frontend only.
-.Sp
-Level 3 (default for \fB\-Wstrict\-aliasing\fR):
-Should have very few false positives and few false
-negatives. Slightly slower than levels 1 or 2 when optimization is enabled.
-Takes care of the common pun+dereference pattern in the frontend:
-\&\f(CW\*(C`*(int*)&some_float\*(C'\fR.
-If optimization is enabled, it also runs in the backend, where it deals
-with multiple statement cases using flow-sensitive points-to information.
-Only warns when the converted pointer is dereferenced.
-Does not warn about incomplete types.
-.IP "\fB\-Wstrict\-overflow\fR" 4
-.IX Item "-Wstrict-overflow"
-.PD 0
-.IP "\fB\-Wstrict\-overflow=\fR\fIn\fR" 4
-.IX Item "-Wstrict-overflow=n"
-.PD
-This option is only active when \fB\-fstrict\-overflow\fR is active.
-It warns about cases where the compiler optimizes based on the
-assumption that signed overflow does not occur. Note that it does not
-warn about all cases where the code might overflow: it only warns
-about cases where the compiler implements some optimization. Thus
-this warning depends on the optimization level.
-.Sp
-An optimization which assumes that signed overflow does not occur is
-perfectly safe if the values of the variables involved are such that
-overflow never does, in fact, occur. Therefore this warning can
-easily give a false positive: a warning about code which is not
-actually a problem. To help focus on important issues, several
-warning levels are defined. No warnings are issued for the use of
-undefined signed overflow when estimating how many iterations a loop
-will require, in particular when determining whether a loop will be
-executed at all.
-.RS 4
-.IP "\fB\-Wstrict\-overflow=1\fR" 4
-.IX Item "-Wstrict-overflow=1"
-Warn about cases which are both questionable and easy to avoid. For
-example: \f(CW\*(C`x + 1 > x\*(C'\fR; with \fB\-fstrict\-overflow\fR, the
-compiler will simplify this to \f(CW1\fR. This level of
-\&\fB\-Wstrict\-overflow\fR is enabled by \fB\-Wall\fR; higher levels
-are not, and must be explicitly requested.
-.IP "\fB\-Wstrict\-overflow=2\fR" 4
-.IX Item "-Wstrict-overflow=2"
-Also warn about other cases where a comparison is simplified to a
-constant. For example: \f(CW\*(C`abs (x) >= 0\*(C'\fR. This can only be
-simplified when \fB\-fstrict\-overflow\fR is in effect, because
-\&\f(CW\*(C`abs (INT_MIN)\*(C'\fR overflows to \f(CW\*(C`INT_MIN\*(C'\fR, which is less than
-zero. \fB\-Wstrict\-overflow\fR (with no level) is the same as
-\&\fB\-Wstrict\-overflow=2\fR.
-.IP "\fB\-Wstrict\-overflow=3\fR" 4
-.IX Item "-Wstrict-overflow=3"
-Also warn about other cases where a comparison is simplified. For
-example: \f(CW\*(C`x + 1 > 1\*(C'\fR will be simplified to \f(CW\*(C`x > 0\*(C'\fR.
-.IP "\fB\-Wstrict\-overflow=4\fR" 4
-.IX Item "-Wstrict-overflow=4"
-Also warn about other simplifications not covered by the above cases.
-For example: \f(CW\*(C`(x * 10) / 5\*(C'\fR will be simplified to \f(CW\*(C`x * 2\*(C'\fR.
-.IP "\fB\-Wstrict\-overflow=5\fR" 4
-.IX Item "-Wstrict-overflow=5"
-Also warn about cases where the compiler reduces the magnitude of a
-constant involved in a comparison. For example: \f(CW\*(C`x + 2 > y\*(C'\fR will
-be simplified to \f(CW\*(C`x + 1 >= y\*(C'\fR. This is reported only at the
-highest warning level because this simplification applies to many
-comparisons, so this warning level will give a very large number of
-false positives.
-.RE
-.RS 4
-.RE
-.IP "\fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR]" 4
-.IX Item "-Wsuggest-attribute=[pure|const|noreturn]"
-Warn for cases where adding an attribute may be beneficial. The
-attributes currently supported are listed below.
-.RS 4
-.IP "\fB\-Wsuggest\-attribute=pure\fR" 4
-.IX Item "-Wsuggest-attribute=pure"
-.PD 0
-.IP "\fB\-Wsuggest\-attribute=const\fR" 4
-.IX Item "-Wsuggest-attribute=const"
-.IP "\fB\-Wsuggest\-attribute=noreturn\fR" 4
-.IX Item "-Wsuggest-attribute=noreturn"
-.PD
-Warn about functions which might be candidates for attributes
-\&\f(CW\*(C`pure\*(C'\fR, \f(CW\*(C`const\*(C'\fR or \f(CW\*(C`noreturn\*(C'\fR. The compiler only warns for
-functions visible in other compilation units or (in the case of \f(CW\*(C`pure\*(C'\fR and
-\&\f(CW\*(C`const\*(C'\fR) if it cannot prove that the function returns normally. A function
-returns normally if it doesn't contain an infinite loop nor returns abnormally
-by throwing, calling \f(CW\*(C`abort()\*(C'\fR or trapping. This analysis requires option
-\&\fB\-fipa\-pure\-const\fR, which is enabled by default at \fB\-O\fR and
-higher. Higher optimization levels improve the accuracy of the analysis.
-.RE
-.RS 4
-.RE
-.IP "\fB\-Warray\-bounds\fR" 4
-.IX Item "-Warray-bounds"
-This option is only active when \fB\-ftree\-vrp\fR is active
-(default for \fB\-O2\fR and above). It warns about subscripts to arrays
-that are always out of bounds. This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wno\-div\-by\-zero\fR" 4
-.IX Item "-Wno-div-by-zero"
-Do not warn about compile-time integer division by zero. Floating point
-division by zero is not warned about, as it can be a legitimate way of
-obtaining infinities and NaNs.
-.IP "\fB\-Wsystem\-headers\fR" 4
-.IX Item "-Wsystem-headers"
-Print warning messages for constructs found in system header files.
-Warnings from system headers are normally suppressed, on the assumption
-that they usually do not indicate real problems and would only make the
-compiler output harder to read. Using this command line option tells
-\&\s-1GCC\s0 to emit warnings from system headers as if they occurred in user
-code. However, note that using \fB\-Wall\fR in conjunction with this
-option will \fInot\fR warn about unknown pragmas in system
-headers\-\-\-for that, \fB\-Wunknown\-pragmas\fR must also be used.
-.IP "\fB\-Wtrampolines\fR" 4
-.IX Item "-Wtrampolines"
-.Vb 1
-\& Warn about trampolines generated for pointers to nested functions.
-\&
-\& A trampoline is a small piece of data or code that is created at run
-\& time on the stack when the address of a nested function is taken, and
-\& is used to call the nested function indirectly. For some targets, it
-\& is made up of data only and thus requires no special treatment. But,
-\& for most targets, it is made up of code and thus requires the stack
-\& to be made executable in order for the program to work properly.
-.Ve
-.IP "\fB\-Wfloat\-equal\fR" 4
-.IX Item "-Wfloat-equal"
-Warn if floating point values are used in equality comparisons.
-.Sp
-The idea behind this is that sometimes it is convenient (for the
-programmer) to consider floating-point values as approximations to
-infinitely precise real numbers. If you are doing this, then you need
-to compute (by analyzing the code, or in some other way) the maximum or
-likely maximum error that the computation introduces, and allow for it
-when performing comparisons (and when producing output, but that's a
-different problem). In particular, instead of testing for equality, you
-would check to see whether the two values have ranges that overlap; and
-this is done with the relational operators, so equality comparisons are
-probably mistaken.
-.IP "\fB\-Wtraditional\fR (C and Objective-C only)" 4
-.IX Item "-Wtraditional (C and Objective-C only)"
-Warn about certain constructs that behave differently in traditional and
-\&\s-1ISO\s0 C. Also warn about \s-1ISO\s0 C constructs that have no traditional C
-equivalent, and/or problematic constructs which should be avoided.
-.RS 4
-.IP "\(bu" 4
-Macro parameters that appear within string literals in the macro body.
-In traditional C macro replacement takes place within string literals,
-but does not in \s-1ISO\s0 C.
-.IP "\(bu" 4
-In traditional C, some preprocessor directives did not exist.
-Traditional preprocessors would only consider a line to be a directive
-if the \fB#\fR appeared in column 1 on the line. Therefore
-\&\fB\-Wtraditional\fR warns about directives that traditional C
-understands but would ignore because the \fB#\fR does not appear as the
-first character on the line. It also suggests you hide directives like
-\&\fB#pragma\fR not understood by traditional C by indenting them. Some
-traditional implementations would not recognize \fB#elif\fR, so it
-suggests avoiding it altogether.
-.IP "\(bu" 4
-A function-like macro that appears without arguments.
-.IP "\(bu" 4
-The unary plus operator.
-.IP "\(bu" 4
-The \fBU\fR integer constant suffix, or the \fBF\fR or \fBL\fR floating point
-constant suffixes. (Traditional C does support the \fBL\fR suffix on integer
-constants.) Note, these suffixes appear in macros defined in the system
-headers of most modern systems, e.g. the \fB_MIN\fR/\fB_MAX\fR macros in \f(CW\*(C`<limits.h>\*(C'\fR.
-Use of these macros in user code might normally lead to spurious
-warnings, however \s-1GCC\s0's integrated preprocessor has enough context to
-avoid warning in these cases.
-.IP "\(bu" 4
-A function declared external in one block and then used after the end of
-the block.
-.IP "\(bu" 4
-A \f(CW\*(C`switch\*(C'\fR statement has an operand of type \f(CW\*(C`long\*(C'\fR.
-.IP "\(bu" 4
-A non\-\f(CW\*(C`static\*(C'\fR function declaration follows a \f(CW\*(C`static\*(C'\fR one.
-This construct is not accepted by some traditional C compilers.
-.IP "\(bu" 4
-The \s-1ISO\s0 type of an integer constant has a different width or
-signedness from its traditional type. This warning is only issued if
-the base of the constant is ten. I.e. hexadecimal or octal values, which
-typically represent bit patterns, are not warned about.
-.IP "\(bu" 4
-Usage of \s-1ISO\s0 string concatenation is detected.
-.IP "\(bu" 4
-Initialization of automatic aggregates.
-.IP "\(bu" 4
-Identifier conflicts with labels. Traditional C lacks a separate
-namespace for labels.
-.IP "\(bu" 4
-Initialization of unions. If the initializer is zero, the warning is
-omitted. This is done under the assumption that the zero initializer in
-user code appears conditioned on e.g. \f(CW\*(C`_\|_STDC_\|_\*(C'\fR to avoid missing
-initializer warnings and relies on default initialization to zero in the
-traditional C case.
-.IP "\(bu" 4
-Conversions by prototypes between fixed/floating point values and vice
-versa. The absence of these prototypes when compiling with traditional
-C would cause serious problems. This is a subset of the possible
-conversion warnings, for the full set use \fB\-Wtraditional\-conversion\fR.
-.IP "\(bu" 4
-Use of \s-1ISO\s0 C style function definitions. This warning intentionally is
-\&\fInot\fR issued for prototype declarations or variadic functions
-because these \s-1ISO\s0 C features will appear in your code when using
-libiberty's traditional C compatibility macros, \f(CW\*(C`PARAMS\*(C'\fR and
-\&\f(CW\*(C`VPARAMS\*(C'\fR. This warning is also bypassed for nested functions
-because that feature is already a \s-1GCC\s0 extension and thus not relevant to
-traditional C compatibility.
-.RE
-.RS 4
-.RE
-.IP "\fB\-Wtraditional\-conversion\fR (C and Objective-C only)" 4
-.IX Item "-Wtraditional-conversion (C and Objective-C only)"
-Warn if a prototype causes a type conversion that is different from what
-would happen to the same argument in the absence of a prototype. This
-includes conversions of fixed point to floating and vice versa, and
-conversions changing the width or signedness of a fixed point argument
-except when the same as the default promotion.
-.IP "\fB\-Wdeclaration\-after\-statement\fR (C and Objective-C only)" 4
-.IX Item "-Wdeclaration-after-statement (C and Objective-C only)"
-Warn when a declaration is found after a statement in a block. This
-construct, known from \*(C+, was introduced with \s-1ISO\s0 C99 and is by default
-allowed in \s-1GCC\s0. It is not supported by \s-1ISO\s0 C90 and was not supported by
-\&\s-1GCC\s0 versions before \s-1GCC\s0 3.0.
-.IP "\fB\-Wundef\fR" 4
-.IX Item "-Wundef"
-Warn if an undefined identifier is evaluated in an \fB#if\fR directive.
-.IP "\fB\-Wno\-endif\-labels\fR" 4
-.IX Item "-Wno-endif-labels"
-Do not warn whenever an \fB#else\fR or an \fB#endif\fR are followed by text.
-.IP "\fB\-Wshadow\fR" 4
-.IX Item "-Wshadow"
-Warn whenever a local variable or type declaration shadows another variable,
-parameter, type, or class member (in \*(C+), or whenever a built-in function
-is shadowed. Note that in \*(C+, the compiler will not warn if a local variable
-shadows a struct/class/enum, but will warn if it shadows an explicit typedef.
-.IP "\fB\-Wshadow\-local\fR" 4
-.IX Item "-Wshadow-local"
-Warn when a local variable shadows another local variable or parameter.
-.IP "\fB\-Wshadow\-compatible\-local\fR" 4
-.IX Item "-Wshadow-compatible-local"
-Warn when a local variable shadows another local variable or parameter
-whose type is compatible with that of the shadowing variable. In \*(C+,
-type compatibility here means the type of the shadowing variable can be
-converted to that of the shadowed variable. The creation of this flag
-(in addition to \fB\-Wshadow\-local\fR) is based on the idea that when
-a local variable shadows another one of incompatible type, it is most
-likely intentional, not a bug or typo, as shown in the following example:
-.Sp
-.Vb 8
-\& for (SomeIterator i = SomeObj.begin(); i != SomeObj.end(); ++i)
-\& {
-\& for (int i = 0; i < N; ++i)
-\& {
-\& ...
-\& }
-\& ...
-\& }
-.Ve
-.Sp
-Since the two variable \f(CW\*(C`i\*(C'\fR in the example above have incompatible types,
-enabling only \fB\-Wshadow\-compatible\-local\fR will not emit a warning.
-Because their types are incompatible, if a programmer accidentally uses one
-in place of the other, type checking will catch that and emit an error or
-warning. So not warning (about shadowing) in this case will not lead to
-undetected bugs. Use of this flag instead of \fB\-Wshadow\-local\fR can
-possibly reduce the number of warnings triggered by intentional shadowing.
-.IP "\fB\-Wlarger\-than=\fR\fIlen\fR" 4
-.IX Item "-Wlarger-than=len"
-Warn whenever an object of larger than \fIlen\fR bytes is defined.
-.IP "\fB\-Wframe\-larger\-than=\fR\fIlen\fR" 4
-.IX Item "-Wframe-larger-than=len"
-Warn if the size of a function frame is larger than \fIlen\fR bytes.
-The computation done to determine the stack frame size is approximate
-and not conservative.
-The actual requirements may be somewhat greater than \fIlen\fR
-even if you do not get a warning. In addition, any space allocated
-via \f(CW\*(C`alloca\*(C'\fR, variable-length arrays, or related constructs
-is not included by the compiler when determining
-whether or not to issue a warning.
-.IP "\fB\-Wunsafe\-loop\-optimizations\fR" 4
-.IX Item "-Wunsafe-loop-optimizations"
-Warn if the loop cannot be optimized because the compiler could not
-assume anything on the bounds of the loop indices. With
-\&\fB\-funsafe\-loop\-optimizations\fR warn if the compiler made
-such assumptions.
-.IP "\fB\-Wno\-pedantic\-ms\-format\fR (MinGW targets only)" 4
-.IX Item "-Wno-pedantic-ms-format (MinGW targets only)"
-Disables the warnings about non-ISO \f(CW\*(C`printf\*(C'\fR / \f(CW\*(C`scanf\*(C'\fR format
-width specifiers \f(CW\*(C`I32\*(C'\fR, \f(CW\*(C`I64\*(C'\fR, and \f(CW\*(C`I\*(C'\fR used on Windows targets
-depending on the \s-1MS\s0 runtime, when you are using the options \fB\-Wformat\fR
-and \fB\-pedantic\fR without gnu-extensions.
-.IP "\fB\-Wpointer\-arith\fR" 4
-.IX Item "-Wpointer-arith"
-Warn about anything that depends on the \*(L"size of\*(R" a function type or
-of \f(CW\*(C`void\*(C'\fR. \s-1GNU\s0 C assigns these types a size of 1, for
-convenience in calculations with \f(CW\*(C`void *\*(C'\fR pointers and pointers
-to functions. In \*(C+, warn also when an arithmetic operation involves
-\&\f(CW\*(C`NULL\*(C'\fR. This warning is also enabled by \fB\-pedantic\fR.
-.IP "\fB\-Wtype\-limits\fR" 4
-.IX Item "-Wtype-limits"
-Warn if a comparison is always true or always false due to the limited
-range of the data type, but do not warn for constant expressions. For
-example, warn if an unsigned variable is compared against zero with
-\&\fB<\fR or \fB>=\fR. This warning is also enabled by
-\&\fB\-Wextra\fR.
-.IP "\fB\-Wbad\-function\-cast\fR (C and Objective-C only)" 4
-.IX Item "-Wbad-function-cast (C and Objective-C only)"
-Warn whenever a function call is cast to a non-matching type.
-For example, warn if \f(CW\*(C`int malloc()\*(C'\fR is cast to \f(CW\*(C`anything *\*(C'\fR.
-.IP "\fB\-Wc++\-compat\fR (C and Objective-C only)" 4
-.IX Item "-Wc++-compat (C and Objective-C only)"
-Warn about \s-1ISO\s0 C constructs that are outside of the common subset of
-\&\s-1ISO\s0 C and \s-1ISO\s0 \*(C+, e.g. request for implicit conversion from
-\&\f(CW\*(C`void *\*(C'\fR to a pointer to non\-\f(CW\*(C`void\*(C'\fR type.
-.IP "\fB\-Wc++0x\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wc++0x-compat ( and Objective- only)"
-Warn about \*(C+ constructs whose meaning differs between \s-1ISO\s0 \*(C+ 1998 and
-\&\s-1ISO\s0 \*(C+ 200x, e.g., identifiers in \s-1ISO\s0 \*(C+ 1998 that will become keywords
-in \s-1ISO\s0 \*(C+ 200x. This warning is enabled by \fB\-Wall\fR.
-.IP "\fB\-Wcast\-qual\fR" 4
-.IX Item "-Wcast-qual"
-Warn whenever a pointer is cast so as to remove a type qualifier from
-the target type. For example, warn if a \f(CW\*(C`const char *\*(C'\fR is cast
-to an ordinary \f(CW\*(C`char *\*(C'\fR.
-.Sp
-Also warn when making a cast which introduces a type qualifier in an
-unsafe way. For example, casting \f(CW\*(C`char **\*(C'\fR to \f(CW\*(C`const char **\*(C'\fR
-is unsafe, as in this example:
-.Sp
-.Vb 6
-\& /* p is char ** value. */
-\& const char **q = (const char **) p;
-\& /* Assignment of readonly string to const char * is OK. */
-\& *q = "string";
-\& /* Now char** pointer points to read\-only memory. */
-\& **p = \*(Aqb\*(Aq;
-.Ve
-.IP "\fB\-Wcast\-align\fR" 4
-.IX Item "-Wcast-align"
-Warn whenever a pointer is cast such that the required alignment of the
-target is increased. For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
-an \f(CW\*(C`int *\*(C'\fR on machines where integers can only be accessed at
-two\- or four-byte boundaries.
-.IP "\fB\-Wwrite\-strings\fR" 4
-.IX Item "-Wwrite-strings"
-When compiling C, give string constants the type \f(CW\*(C`const
-char[\f(CIlength\f(CW]\*(C'\fR so that copying the address of one into a
-non\-\f(CW\*(C`const\*(C'\fR \f(CW\*(C`char *\*(C'\fR pointer will get a warning. These
-warnings will help you find at compile time code that can try to write
-into a string constant, but only if you have been very careful about
-using \f(CW\*(C`const\*(C'\fR in declarations and prototypes. Otherwise, it will
-just be a nuisance. This is why we did not make \fB\-Wall\fR request
-these warnings.
-.Sp
-When compiling \*(C+, warn about the deprecated conversion from string
-literals to \f(CW\*(C`char *\*(C'\fR. This warning is enabled by default for \*(C+
-programs.
-.IP "\fB\-Wclobbered\fR" 4
-.IX Item "-Wclobbered"
-Warn for variables that might be changed by \fBlongjmp\fR or
-\&\fBvfork\fR. This warning is also enabled by \fB\-Wextra\fR.
-.IP "\fB\-Wconversion\fR" 4
-.IX Item "-Wconversion"
-Warn for implicit conversions that may alter a value. This includes
-conversions between real and integer, like \f(CW\*(C`abs (x)\*(C'\fR when
-\&\f(CW\*(C`x\*(C'\fR is \f(CW\*(C`double\*(C'\fR; conversions between signed and unsigned,
-like \f(CW\*(C`unsigned ui = \-1\*(C'\fR; and conversions to smaller types, like
-\&\f(CW\*(C`sqrtf (M_PI)\*(C'\fR. Do not warn for explicit casts like \f(CW\*(C`abs
-((int) x)\*(C'\fR and \f(CW\*(C`ui = (unsigned) \-1\*(C'\fR, or if the value is not
-changed by the conversion like in \f(CW\*(C`abs (2.0)\*(C'\fR. Warnings about
-conversions between signed and unsigned integers can be disabled by
-using \fB\-Wno\-sign\-conversion\fR.
-.Sp
-For \*(C+, also warn for confusing overload resolution for user-defined
-conversions; and conversions that will never use a type conversion
-operator: conversions to \f(CW\*(C`void\*(C'\fR, the same type, a base class or a
-reference to them. Warnings about conversions between signed and
-unsigned integers are disabled by default in \*(C+ unless
-\&\fB\-Wsign\-conversion\fR is explicitly enabled.
-.IP "\fB\-Wno\-conversion\-null\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wno-conversion-null ( and Objective- only)"
-Do not warn for conversions between \f(CW\*(C`NULL\*(C'\fR and non-pointer
-types. \fB\-Wconversion\-null\fR is enabled by default.
-.IP "\fB\-Wreal\-conversion\fR" 4
-.IX Item "-Wreal-conversion"
-Warn for implicit type conversions from real (\f(CW\*(C`double\*(C'\fR or \f(CW\*(C`float\*(C'\fR)
-to integral values.
-.IP "\fB\-Wempty\-body\fR" 4
-.IX Item "-Wempty-body"
-Warn if an empty body occurs in an \fBif\fR, \fBelse\fR or \fBdo
-while\fR statement. This warning is also enabled by \fB\-Wextra\fR.
-.IP "\fB\-Wenum\-compare\fR" 4
-.IX Item "-Wenum-compare"
-Warn about a comparison between values of different enum types. In \*(C+
-this warning is enabled by default. In C this warning is enabled by
-\&\fB\-Wall\fR.
-.IP "\fB\-Wjump\-misses\-init\fR (C, Objective-C only)" 4
-.IX Item "-Wjump-misses-init (C, Objective-C only)"
-Warn if a \f(CW\*(C`goto\*(C'\fR statement or a \f(CW\*(C`switch\*(C'\fR statement jumps
-forward across the initialization of a variable, or jumps backward to a
-label after the variable has been initialized. This only warns about
-variables which are initialized when they are declared. This warning is
-only supported for C and Objective C; in \*(C+ this sort of branch is an
-error in any case.
-.Sp
-\&\fB\-Wjump\-misses\-init\fR is included in \fB\-Wc++\-compat\fR. It
-can be disabled with the \fB\-Wno\-jump\-misses\-init\fR option.
-.IP "\fB\-Wsign\-compare\fR" 4
-.IX Item "-Wsign-compare"
-Warn when a comparison between signed and unsigned values could produce
-an incorrect result when the signed value is converted to unsigned.
-This warning is also enabled by \fB\-Wextra\fR; to get the other warnings
-of \fB\-Wextra\fR without this warning, use \fB\-Wextra \-Wno\-sign\-compare\fR.
-.IP "\fB\-Wsign\-conversion\fR" 4
-.IX Item "-Wsign-conversion"
-Warn for implicit conversions that may change the sign of an integer
-value, like assigning a signed integer expression to an unsigned
-integer variable. An explicit cast silences the warning. In C, this
-option is enabled also by \fB\-Wconversion\fR.
-.IP "\fB\-Waddress\fR" 4
-.IX Item "-Waddress"
-Warn about suspicious uses of memory addresses. These include using
-the address of a function in a conditional expression, such as
-\&\f(CW\*(C`void func(void); if (func)\*(C'\fR, and comparisons against the memory
-address of a string literal, such as \f(CW\*(C`if (x == "abc")\*(C'\fR. Such
-uses typically indicate a programmer error: the address of a function
-always evaluates to true, so their use in a conditional usually
-indicate that the programmer forgot the parentheses in a function
-call; and comparisons against string literals result in unspecified
-behavior and are not portable in C, so they usually indicate that the
-programmer intended to use \f(CW\*(C`strcmp\*(C'\fR. This warning is enabled by
-\&\fB\-Wall\fR.
-.IP "\fB\-Wlogical\-op\fR" 4
-.IX Item "-Wlogical-op"
-Warn about suspicious uses of logical operators in expressions.
-This includes using logical operators in contexts where a
-bit-wise operator is likely to be expected.
-.IP "\fB\-Waggregate\-return\fR" 4
-.IX Item "-Waggregate-return"
-Warn if any functions that return structures or unions are defined or
-called. (In languages where you can return an array, this also elicits
-a warning.)
-.IP "\fB\-Wno\-attributes\fR" 4
-.IX Item "-Wno-attributes"
-Do not warn if an unexpected \f(CW\*(C`_\|_attribute_\|_\*(C'\fR is used, such as
-unrecognized attributes, function attributes applied to variables,
-etc. This will not stop errors for incorrect use of supported
-attributes.
-.IP "\fB\-Wno\-builtin\-macro\-redefined\fR" 4
-.IX Item "-Wno-builtin-macro-redefined"
-Do not warn if certain built-in macros are redefined. This suppresses
-warnings for redefinition of \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR, \f(CW\*(C`_\|_TIME_\|_\*(C'\fR,
-\&\f(CW\*(C`_\|_DATE_\|_\*(C'\fR, \f(CW\*(C`_\|_FILE_\|_\*(C'\fR, and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR.
-.IP "\fB\-Wstrict\-prototypes\fR (C and Objective-C only)" 4
-.IX Item "-Wstrict-prototypes (C and Objective-C only)"
-Warn if a function is declared or defined without specifying the
-argument types. (An old-style function definition is permitted without
-a warning if preceded by a declaration which specifies the argument
-types.)
-.IP "\fB\-Wold\-style\-declaration\fR (C and Objective-C only)" 4
-.IX Item "-Wold-style-declaration (C and Objective-C only)"
-Warn for obsolescent usages, according to the C Standard, in a
-declaration. For example, warn if storage-class specifiers like
-\&\f(CW\*(C`static\*(C'\fR are not the first things in a declaration. This warning
-is also enabled by \fB\-Wextra\fR.
-.IP "\fB\-Wold\-style\-definition\fR (C and Objective-C only)" 4
-.IX Item "-Wold-style-definition (C and Objective-C only)"
-Warn if an old-style function definition is used. A warning is given
-even if there is a previous prototype.
-.IP "\fB\-Wmissing\-parameter\-type\fR (C and Objective-C only)" 4
-.IX Item "-Wmissing-parameter-type (C and Objective-C only)"
-A function parameter is declared without a type specifier in K&R\-style
-functions:
-.Sp
-.Vb 1
-\& void foo(bar) { }
-.Ve
-.Sp
-This warning is also enabled by \fB\-Wextra\fR.
-.IP "\fB\-Wmissing\-prototypes\fR (C and Objective-C only)" 4
-.IX Item "-Wmissing-prototypes (C and Objective-C only)"
-Warn if a global function is defined without a previous prototype
-declaration. This warning is issued even if the definition itself
-provides a prototype. The aim is to detect global functions that fail
-to be declared in header files.
-.IP "\fB\-Wmissing\-declarations\fR" 4
-.IX Item "-Wmissing-declarations"
-Warn if a global function is defined without a previous declaration.
-Do so even if the definition itself provides a prototype.
-Use this option to detect global functions that are not declared in
-header files. In \*(C+, no warnings are issued for function templates,
-or for inline functions, or for functions in anonymous namespaces.
-.IP "\fB\-Wmissing\-field\-initializers\fR" 4
-.IX Item "-Wmissing-field-initializers"
-Warn if a structure's initializer has some fields missing. For
-example, the following code would cause such a warning, because
-\&\f(CW\*(C`x.h\*(C'\fR is implicitly zero:
-.Sp
-.Vb 2
-\& struct s { int f, g, h; };
-\& struct s x = { 3, 4 };
-.Ve
-.Sp
-This option does not warn about designated initializers, so the following
-modification would not trigger a warning:
-.Sp
-.Vb 2
-\& struct s { int f, g, h; };
-\& struct s x = { .f = 3, .g = 4 };
-.Ve
-.Sp
-This warning is included in \fB\-Wextra\fR. To get other \fB\-Wextra\fR
-warnings without this one, use \fB\-Wextra \-Wno\-missing\-field\-initializers\fR.
-.IP "\fB\-Wmissing\-format\-attribute\fR" 4
-.IX Item "-Wmissing-format-attribute"
-Warn about function pointers which might be candidates for \f(CW\*(C`format\*(C'\fR
-attributes. Note these are only possible candidates, not absolute ones.
-\&\s-1GCC\s0 will guess that function pointers with \f(CW\*(C`format\*(C'\fR attributes that
-are used in assignment, initialization, parameter passing or return
-statements should have a corresponding \f(CW\*(C`format\*(C'\fR attribute in the
-resulting type. I.e. the left-hand side of the assignment or
-initialization, the type of the parameter variable, or the return type
-of the containing function respectively should also have a \f(CW\*(C`format\*(C'\fR
-attribute to avoid the warning.
-.Sp
-\&\s-1GCC\s0 will also warn about function definitions which might be
-candidates for \f(CW\*(C`format\*(C'\fR attributes. Again, these are only
-possible candidates. \s-1GCC\s0 will guess that \f(CW\*(C`format\*(C'\fR attributes
-might be appropriate for any function that calls a function like
-\&\f(CW\*(C`vprintf\*(C'\fR or \f(CW\*(C`vscanf\*(C'\fR, but this might not always be the
-case, and some functions for which \f(CW\*(C`format\*(C'\fR attributes are
-appropriate may not be detected.
-.IP "\fB\-Wno\-multichar\fR" 4
-.IX Item "-Wno-multichar"
-Do not warn if a multicharacter constant (\fB'\s-1FOOF\s0'\fR) is used.
-Usually they indicate a typo in the user's code, as they have
-implementation-defined values, and should not be used in portable code.
-.IP "\fB\-Wnormalized=<none|id|nfc|nfkc>\fR" 4
-.IX Item "-Wnormalized=<none|id|nfc|nfkc>"
-In \s-1ISO\s0 C and \s-1ISO\s0 \*(C+, two identifiers are different if they are
-different sequences of characters. However, sometimes when characters
-outside the basic \s-1ASCII\s0 character set are used, you can have two
-different character sequences that look the same. To avoid confusion,
-the \s-1ISO\s0 10646 standard sets out some \fInormalization rules\fR which
-when applied ensure that two sequences that look the same are turned into
-the same sequence. \s-1GCC\s0 can warn you if you are using identifiers which
-have not been normalized; this option controls that warning.
-.Sp
-There are four levels of warning that \s-1GCC\s0 supports. The default is
-\&\fB\-Wnormalized=nfc\fR, which warns about any identifier which is
-not in the \s-1ISO\s0 10646 \*(L"C\*(R" normalized form, \fI\s-1NFC\s0\fR. \s-1NFC\s0 is the
-recommended form for most uses.
-.Sp
-Unfortunately, there are some characters which \s-1ISO\s0 C and \s-1ISO\s0 \*(C+ allow
-in identifiers that when turned into \s-1NFC\s0 aren't allowable as
-identifiers. That is, there's no way to use these symbols in portable
-\&\s-1ISO\s0 C or \*(C+ and have all your identifiers in \s-1NFC\s0.
-\&\fB\-Wnormalized=id\fR suppresses the warning for these characters.
-It is hoped that future versions of the standards involved will correct
-this, which is why this option is not the default.
-.Sp
-You can switch the warning off for all characters by writing
-\&\fB\-Wnormalized=none\fR. You would only want to do this if you
-were using some other normalization scheme (like \*(L"D\*(R"), because
-otherwise you can easily create bugs that are literally impossible to see.
-.Sp
-Some characters in \s-1ISO\s0 10646 have distinct meanings but look identical
-in some fonts or display methodologies, especially once formatting has
-been applied. For instance \f(CW\*(C`\eu207F\*(C'\fR, \*(L"\s-1SUPERSCRIPT\s0 \s-1LATIN\s0 \s-1SMALL\s0
-\&\s-1LETTER\s0 N\*(R", will display just like a regular \f(CW\*(C`n\*(C'\fR which has been
-placed in a superscript. \s-1ISO\s0 10646 defines the \fI\s-1NFKC\s0\fR
-normalization scheme to convert all these into a standard form as
-well, and \s-1GCC\s0 will warn if your code is not in \s-1NFKC\s0 if you use
-\&\fB\-Wnormalized=nfkc\fR. This warning is comparable to warning
-about every identifier that contains the letter O because it might be
-confused with the digit 0, and so is not the default, but may be
-useful as a local coding convention if the programming environment is
-unable to be fixed to display these characters distinctly.
-.IP "\fB\-Wno\-deprecated\fR" 4
-.IX Item "-Wno-deprecated"
-Do not warn about usage of deprecated features.
-.IP "\fB\-Wno\-deprecated\-declarations\fR" 4
-.IX Item "-Wno-deprecated-declarations"
-Do not warn about uses of functions,
-variables, and types marked as deprecated by using the \f(CW\*(C`deprecated\*(C'\fR
-attribute.
-.IP "\fB\-Wno\-overflow\fR" 4
-.IX Item "-Wno-overflow"
-Do not warn about compile-time overflow in constant expressions.
-.IP "\fB\-Woverride\-init\fR (C and Objective-C only)" 4
-.IX Item "-Woverride-init (C and Objective-C only)"
-Warn if an initialized field without side effects is overridden when
-using designated initializers.
-.Sp
-This warning is included in \fB\-Wextra\fR. To get other
-\&\fB\-Wextra\fR warnings without this one, use \fB\-Wextra
-\&\-Wno\-override\-init\fR.
-.IP "\fB\-Wpacked\fR" 4
-.IX Item "-Wpacked"
-Warn if a structure is given the packed attribute, but the packed
-attribute has no effect on the layout or size of the structure.
-Such structures may be mis-aligned for little benefit. For
-instance, in this code, the variable \f(CW\*(C`f.x\*(C'\fR in \f(CW\*(C`struct bar\*(C'\fR
-will be misaligned even though \f(CW\*(C`struct bar\*(C'\fR does not itself
-have the packed attribute:
-.Sp
-.Vb 8
-\& struct foo {
-\& int x;
-\& char a, b, c, d;
-\& } _\|_attribute_\|_((packed));
-\& struct bar {
-\& char z;
-\& struct foo f;
-\& };
-.Ve
-.IP "\fB\-Wpacked\-bitfield\-compat\fR" 4
-.IX Item "-Wpacked-bitfield-compat"
-The 4.1, 4.2 and 4.3 series of \s-1GCC\s0 ignore the \f(CW\*(C`packed\*(C'\fR attribute
-on bit-fields of type \f(CW\*(C`char\*(C'\fR. This has been fixed in \s-1GCC\s0 4.4 but
-the change can lead to differences in the structure layout. \s-1GCC\s0
-informs you when the offset of such a field has changed in \s-1GCC\s0 4.4.
-For example there is no longer a 4\-bit padding between field \f(CW\*(C`a\*(C'\fR
-and \f(CW\*(C`b\*(C'\fR in this structure:
-.Sp
-.Vb 5
-\& struct foo
-\& {
-\& char a:4;
-\& char b:8;
-\& } _\|_attribute_\|_ ((packed));
-.Ve
-.Sp
-This warning is enabled by default. Use
-\&\fB\-Wno\-packed\-bitfield\-compat\fR to disable this warning.
-.IP "\fB\-Wpadded\fR" 4
-.IX Item "-Wpadded"
-Warn if padding is included in a structure, either to align an element
-of the structure or to align the whole structure. Sometimes when this
-happens it is possible to rearrange the fields of the structure to
-reduce the padding and so make the structure smaller.
-.IP "\fB\-Wredundant\-decls\fR" 4
-.IX Item "-Wredundant-decls"
-Warn if anything is declared more than once in the same scope, even in
-cases where multiple declaration is valid and changes nothing.
-.IP "\fB\-Wnested\-externs\fR (C and Objective-C only)" 4
-.IX Item "-Wnested-externs (C and Objective-C only)"
-Warn if an \f(CW\*(C`extern\*(C'\fR declaration is encountered within a function.
-.IP "\fB\-Winline\fR" 4
-.IX Item "-Winline"
-Warn if a function can not be inlined and it was declared as inline.
-Even with this option, the compiler will not warn about failures to
-inline functions declared in system headers.
-.Sp
-The compiler uses a variety of heuristics to determine whether or not
-to inline a function. For example, the compiler takes into account
-the size of the function being inlined and the amount of inlining
-that has already been done in the current function. Therefore,
-seemingly insignificant changes in the source program can cause the
-warnings produced by \fB\-Winline\fR to appear or disappear.
-.IP "\fB\-Wno\-invalid\-offsetof\fR (\*(C+ and Objective\-\*(C+ only)" 4
-.IX Item "-Wno-invalid-offsetof ( and Objective- only)"
-Suppress warnings from applying the \fBoffsetof\fR macro to a non-POD
-type. According to the 1998 \s-1ISO\s0 \*(C+ standard, applying \fBoffsetof\fR
-to a non-POD type is undefined. In existing \*(C+ implementations,
-however, \fBoffsetof\fR typically gives meaningful results even when
-applied to certain kinds of non-POD types. (Such as a simple
-\&\fBstruct\fR that fails to be a \s-1POD\s0 type only by virtue of having a
-constructor.) This flag is for users who are aware that they are
-writing nonportable code and who have deliberately chosen to ignore the
-warning about it.
-.Sp
-The restrictions on \fBoffsetof\fR may be relaxed in a future version
-of the \*(C+ standard.
-.IP "\fB\-Wno\-int\-to\-pointer\-cast\fR" 4
-.IX Item "-Wno-int-to-pointer-cast"
-Suppress warnings from casts to pointer type of an integer of a
-different size. In \*(C+, casting to a pointer type of smaller size is
-an error. \fBWint-to-pointer-cast\fR is enabled by default.
-.IP "\fBmax-lipo-mem\fR" 4
-.IX Item "max-lipo-mem"
-When importing auxiliary modules during profile-use, check current
-memory consumption after parsing each auxiliary module. If it exceeds
-this limit (specified in kb), don't import any more auxiliary modules.
-Specifying a value of 0 means don't enforce this limit. This parameter
-is only useful when using \fB\-fprofile\-use\fR and \fB\-fripa\fR.
-.IP "\fB\-Wno\-pointer\-to\-int\-cast\fR (C and Objective-C only)" 4
-.IX Item "-Wno-pointer-to-int-cast (C and Objective-C only)"
-Suppress warnings from casts from a pointer to an integer type of a
-different size.
-.IP "\fB\-Winvalid\-pch\fR" 4
-.IX Item "-Winvalid-pch"
-Warn if a precompiled header is found in
-the search path but can't be used.
-.IP "\fB\-Wlong\-long\fR" 4
-.IX Item "-Wlong-long"
-Warn if \fBlong long\fR type is used. This is enabled by either
-\&\fB\-pedantic\fR or \fB\-Wtraditional\fR in \s-1ISO\s0 C90 and \*(C+98
-modes. To inhibit the warning messages, use \fB\-Wno\-long\-long\fR.
-.IP "\fB\-Wvariadic\-macros\fR" 4
-.IX Item "-Wvariadic-macros"
-Warn if variadic macros are used in pedantic \s-1ISO\s0 C90 mode, or the \s-1GNU\s0
-alternate syntax when in pedantic \s-1ISO\s0 C99 mode. This is default.
-To inhibit the warning messages, use \fB\-Wno\-variadic\-macros\fR.
-.IP "\fB\-Wvla\fR" 4
-.IX Item "-Wvla"
-Warn if variable length array is used in the code.
-\&\fB\-Wno\-vla\fR will prevent the \fB\-pedantic\fR warning of
-the variable length array.
-.IP "\fB\-Wvolatile\-register\-var\fR" 4
-.IX Item "-Wvolatile-register-var"
-Warn if a register variable is declared volatile. The volatile
-modifier does not inhibit all optimizations that may eliminate reads
-and/or writes to register variables. This warning is enabled by
-\&\fB\-Wall\fR.
-.IP "\fB\-Wdisabled\-optimization\fR" 4
-.IX Item "-Wdisabled-optimization"
-Warn if a requested optimization pass is disabled. This warning does
-not generally indicate that there is anything wrong with your code; it
-merely indicates that \s-1GCC\s0's optimizers were unable to handle the code
-effectively. Often, the problem is that your code is too big or too
-complex; \s-1GCC\s0 will refuse to optimize programs when the optimization
-itself is likely to take inordinate amounts of time.
-.IP "\fB\-Wpointer\-sign\fR (C and Objective-C only)" 4
-.IX Item "-Wpointer-sign (C and Objective-C only)"
-Warn for pointer argument passing or assignment with different signedness.
-This option is only supported for C and Objective-C. It is implied by
-\&\fB\-Wall\fR and by \fB\-pedantic\fR, which can be disabled with
-\&\fB\-Wno\-pointer\-sign\fR.
-.IP "\fB\-Wstack\-protector\fR" 4
-.IX Item "-Wstack-protector"
-This option is only active when \fB\-fstack\-protector\fR is active. It
-warns about functions that will not be protected against stack smashing.
-.IP "\fB\-Wno\-mudflap\fR" 4
-.IX Item "-Wno-mudflap"
-Suppress warnings about constructs that cannot be instrumented by
-\&\fB\-fmudflap\fR.
-.IP "\fB\-Woverlength\-strings\fR" 4
-.IX Item "-Woverlength-strings"
-Warn about string constants which are longer than the \*(L"minimum
-maximum\*(R" length specified in the C standard. Modern compilers
-generally allow string constants which are much longer than the
-standard's minimum limit, but very portable programs should avoid
-using longer strings.
-.Sp
-The limit applies \fIafter\fR string constant concatenation, and does
-not count the trailing \s-1NUL\s0. In C90, the limit was 509 characters; in
-C99, it was raised to 4095. \*(C+98 does not specify a normative
-minimum maximum, so we do not diagnose overlength strings in \*(C+.
-.Sp
-This option is implied by \fB\-pedantic\fR, and can be disabled with
-\&\fB\-Wno\-overlength\-strings\fR.
-.IP "\fB\-Wunsuffixed\-float\-constants\fR (C and Objective-C only)" 4
-.IX Item "-Wunsuffixed-float-constants (C and Objective-C only)"
-\&\s-1GCC\s0 will issue a warning for any floating constant that does not have
-a suffix. When used together with \fB\-Wsystem\-headers\fR it will
-warn about such constants in system header files. This can be useful
-when preparing code to use with the \f(CW\*(C`FLOAT_CONST_DECIMAL64\*(C'\fR pragma
-from the decimal floating-point extension to C99.
-.SS "Options for Debugging Your Program or \s-1GCC\s0"
-.IX Subsection "Options for Debugging Your Program or GCC"
-\&\s-1GCC\s0 has various special options that are used for debugging
-either your program or \s-1GCC:\s0
-.IP "\fB\-g\fR" 4
-.IX Item "-g"
-Produce debugging information in the operating system's native format
-(stabs, \s-1COFF\s0, \s-1XCOFF\s0, or \s-1DWARF\s0 2). \s-1GDB\s0 can work with this debugging
-information.
-.Sp
-On most systems that use stabs format, \fB\-g\fR enables use of extra
-debugging information that only \s-1GDB\s0 can use; this extra information
-makes debugging work better in \s-1GDB\s0 but will probably make other debuggers
-crash or
-refuse to read the program. If you want to control for certain whether
-to generate the extra information, use \fB\-gstabs+\fR, \fB\-gstabs\fR,
-\&\fB\-gxcoff+\fR, \fB\-gxcoff\fR, or \fB\-gvms\fR (see below).
-.Sp
-\&\s-1GCC\s0 allows you to use \fB\-g\fR with
-\&\fB\-O\fR. The shortcuts taken by optimized code may occasionally
-produce surprising results: some variables you declared may not exist
-at all; flow of control may briefly move where you did not expect it;
-some statements may not be executed because they compute constant
-results or their values were already at hand; some statements may
-execute in different places because they were moved out of loops.
-.Sp
-Nevertheless it proves possible to debug optimized output. This makes
-it reasonable to use the optimizer for programs that might have bugs.
-.Sp
-The following options are useful when \s-1GCC\s0 is generated with the
-capability for more than one debugging format.
-.IP "\fB\-ggdb\fR" 4
-.IX Item "-ggdb"
-Produce debugging information for use by \s-1GDB\s0. This means to use the
-most expressive format available (\s-1DWARF\s0 2, stabs, or the native format
-if neither of those are supported), including \s-1GDB\s0 extensions if at all
-possible.
-.IP "\fB\-gstabs\fR" 4
-.IX Item "-gstabs"
-Produce debugging information in stabs format (if that is supported),
-without \s-1GDB\s0 extensions. This is the format used by \s-1DBX\s0 on most \s-1BSD\s0
-systems. On \s-1MIPS\s0, Alpha and System V Release 4 systems this option
-produces stabs debugging output which is not understood by \s-1DBX\s0 or \s-1SDB\s0.
-On System V Release 4 systems this option requires the \s-1GNU\s0 assembler.
-.IP "\fB\-feliminate\-unused\-debug\-symbols\fR" 4
-.IX Item "-feliminate-unused-debug-symbols"
-Produce debugging information in stabs format (if that is supported),
-for only symbols that are actually used.
-.IP "\fB\-femit\-class\-debug\-always\fR" 4
-.IX Item "-femit-class-debug-always"
-Instead of emitting debugging information for a \*(C+ class in only one
-object file, emit it in all object files using the class. This option
-should be used only with debuggers that are unable to handle the way \s-1GCC\s0
-normally emits debugging information for classes because using this
-option will increase the size of debugging information by as much as a
-factor of two.
-.IP "\fB\-gstabs+\fR" 4
-.IX Item "-gstabs+"
-Produce debugging information in stabs format (if that is supported),
-using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0). The
-use of these extensions is likely to make other debuggers crash or
-refuse to read the program.
-.IP "\fB\-gcoff\fR" 4
-.IX Item "-gcoff"
-Produce debugging information in \s-1COFF\s0 format (if that is supported).
-This is the format used by \s-1SDB\s0 on most System V systems prior to
-System V Release 4.
-.IP "\fB\-gxcoff\fR" 4
-.IX Item "-gxcoff"
-Produce debugging information in \s-1XCOFF\s0 format (if that is supported).
-This is the format used by the \s-1DBX\s0 debugger on \s-1IBM\s0 \s-1RS/6000\s0 systems.
-.IP "\fB\-gxcoff+\fR" 4
-.IX Item "-gxcoff+"
-Produce debugging information in \s-1XCOFF\s0 format (if that is supported),
-using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0). The
-use of these extensions is likely to make other debuggers crash or
-refuse to read the program, and may cause assemblers other than the \s-1GNU\s0
-assembler (\s-1GAS\s0) to fail with an error.
-.IP "\fB\-gdwarf\-\fR\fIversion\fR" 4
-.IX Item "-gdwarf-version"
-Produce debugging information in \s-1DWARF\s0 format (if that is
-supported). This is the format used by \s-1DBX\s0 on \s-1IRIX\s0 6. The value
-of \fIversion\fR may be either 2, 3 or 4; the default version is 2.
-.Sp
-Note that with \s-1DWARF\s0 version 2 some ports require, and will always
-use, some non-conflicting \s-1DWARF\s0 3 extensions in the unwind tables.
-.Sp
-Version 4 may require \s-1GDB\s0 7.0 and \fB\-fvar\-tracking\-assignments\fR
-for maximum benefit.
-.IP "\fB\-gstrict\-dwarf\fR" 4
-.IX Item "-gstrict-dwarf"
-Disallow using extensions of later \s-1DWARF\s0 standard version than selected
-with \fB\-gdwarf\-\fR\fIversion\fR. On most targets using non-conflicting
-\&\s-1DWARF\s0 extensions from later standard versions is allowed.
-.IP "\fB\-gno\-strict\-dwarf\fR" 4
-.IX Item "-gno-strict-dwarf"
-Allow using extensions of later \s-1DWARF\s0 standard version than selected with
-\&\fB\-gdwarf\-\fR\fIversion\fR.
-.IP "\fB\-gvms\fR" 4
-.IX Item "-gvms"
-Produce debugging information in \s-1VMS\s0 debug format (if that is
-supported). This is the format used by \s-1DEBUG\s0 on \s-1VMS\s0 systems.
-.IP "\fB\-g\fR\fIlevel\fR" 4
-.IX Item "-glevel"
-.PD 0
-.IP "\fB\-ggdb\fR\fIlevel\fR" 4
-.IX Item "-ggdblevel"
-.IP "\fB\-gstabs\fR\fIlevel\fR" 4
-.IX Item "-gstabslevel"
-.IP "\fB\-gcoff\fR\fIlevel\fR" 4
-.IX Item "-gcofflevel"
-.IP "\fB\-gxcoff\fR\fIlevel\fR" 4
-.IX Item "-gxcofflevel"
-.IP "\fB\-gvms\fR\fIlevel\fR" 4
-.IX Item "-gvmslevel"
-.PD
-Request debugging information and also use \fIlevel\fR to specify how
-much information. The default level is 2.
-.Sp
-Level 0 produces no debug information at all. Thus, \fB\-g0\fR negates
-\&\fB\-g\fR.
-.Sp
-Level 1 produces minimal information, enough for making backtraces in
-parts of the program that you don't plan to debug. This includes
-descriptions of functions and external variables, but no information
-about local variables and no line numbers.
-.Sp
-Level 3 includes extra information, such as all the macro definitions
-present in the program. Some debuggers support macro expansion when
-you use \fB\-g3\fR.
-.Sp
-\&\fB\-gdwarf\-2\fR does not accept a concatenated debug level, because
-\&\s-1GCC\s0 used to support an option \fB\-gdwarf\fR that meant to generate
-debug information in version 1 of the \s-1DWARF\s0 format (which is very
-different from version 2), and it would have been too confusing. That
-debug format is long obsolete, but the option cannot be changed now.
-Instead use an additional \fB\-g\fR\fIlevel\fR option to change the
-debug level for \s-1DWARF\s0.
-.IP "\fB\-gmlt\fR" 4
-.IX Item "-gmlt"
-Produce a minimal line table, with level 1 debugging information plus
-information about inlined functions and line numbers.
-.IP "\fB\-gtoggle\fR" 4
-.IX Item "-gtoggle"
-Turn off generation of debug info, if leaving out this option would have
-generated it, or turn it on at level 2 otherwise. The position of this
-argument in the command line does not matter, it takes effect after all
-other options are processed, and it does so only once, no matter how
-many times it is given. This is mainly intended to be used with
-\&\fB\-fcompare\-debug\fR.
-.IP "\fB\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR]" 4
-.IX Item "-fdump-final-insns[=file]"
-Dump the final internal representation (\s-1RTL\s0) to \fIfile\fR. If the
-optional argument is omitted (or if \fIfile\fR is \f(CW\*(C`.\*(C'\fR), the name
-of the dump file will be determined by appending \f(CW\*(C`.gkd\*(C'\fR to the
-compilation output file name.
-.IP "\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]" 4
-.IX Item "-fcompare-debug[=opts]"
-If no error occurs during compilation, run the compiler a second time,
-adding \fIopts\fR and \fB\-fcompare\-debug\-second\fR to the arguments
-passed to the second compilation. Dump the final internal
-representation in both compilations, and print an error if they differ.
-.Sp
-If the equal sign is omitted, the default \fB\-gtoggle\fR is used.
-.Sp
-The environment variable \fB\s-1GCC_COMPARE_DEBUG\s0\fR, if defined, non-empty
-and nonzero, implicitly enables \fB\-fcompare\-debug\fR. If
-\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR is defined to a string starting with a dash,
-then it is used for \fIopts\fR, otherwise the default \fB\-gtoggle\fR
-is used.
-.Sp
-\&\fB\-fcompare\-debug=\fR, with the equal sign but without \fIopts\fR,
-is equivalent to \fB\-fno\-compare\-debug\fR, which disables the dumping
-of the final representation and the second compilation, preventing even
-\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR from taking effect.
-.Sp
-To verify full coverage during \fB\-fcompare\-debug\fR testing, set
-\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR to say \fB\-fcompare\-debug\-not\-overridden\fR,
-which \s-1GCC\s0 will reject as an invalid option in any actual compilation
-(rather than preprocessing, assembly or linking). To get just a
-warning, setting \fB\s-1GCC_COMPARE_DEBUG\s0\fR to \fB\-w%n\-fcompare\-debug
-not overridden\fR will do.
-.IP "\fB\-fcompare\-debug\-second\fR" 4
-.IX Item "-fcompare-debug-second"
-This option is implicitly passed to the compiler for the second
-compilation requested by \fB\-fcompare\-debug\fR, along with options to
-silence warnings, and omitting other options that would cause
-side-effect compiler outputs to files or to the standard output. Dump
-files and preserved temporary files are renamed so as to contain the
-\&\f(CW\*(C`.gk\*(C'\fR additional extension during the second compilation, to avoid
-overwriting those generated by the first.
-.Sp
-When this option is passed to the compiler driver, it causes the
-\&\fIfirst\fR compilation to be skipped, which makes it useful for little
-other than debugging the compiler proper.
-.IP "\fB\-feliminate\-dwarf2\-dups\fR" 4
-.IX Item "-feliminate-dwarf2-dups"
-Compress \s-1DWARF2\s0 debugging information by eliminating duplicated
-information about each symbol. This option only makes sense when
-generating \s-1DWARF2\s0 debugging information with \fB\-gdwarf\-2\fR.
-.IP "\fB\-femit\-struct\-debug\-baseonly\fR" 4
-.IX Item "-femit-struct-debug-baseonly"
-Emit debug information for struct-like types
-only when the base name of the compilation source file
-matches the base name of file in which the struct was defined.
-.Sp
-This option substantially reduces the size of debugging information,
-but at significant potential loss in type information to the debugger.
-See \fB\-femit\-struct\-debug\-reduced\fR for a less aggressive option.
-See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
-.Sp
-This option works only with \s-1DWARF\s0 2.
-.IP "\fB\-femit\-struct\-debug\-reduced\fR" 4
-.IX Item "-femit-struct-debug-reduced"
-Emit debug information for struct-like types
-only when the base name of the compilation source file
-matches the base name of file in which the type was defined,
-unless the struct is a template or defined in a system header.
-.Sp
-This option significantly reduces the size of debugging information,
-with some potential loss in type information to the debugger.
-See \fB\-femit\-struct\-debug\-baseonly\fR for a more aggressive option.
-See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
-.Sp
-This option works only with \s-1DWARF\s0 2.
-.IP "\fB\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR]" 4
-.IX Item "-femit-struct-debug-detailed[=spec-list]"
-Specify the struct-like types
-for which the compiler will generate debug information.
-The intent is to reduce duplicate struct debug information
-between different object files within the same program.
-.Sp
-This option is a detailed version of
-\&\fB\-femit\-struct\-debug\-reduced\fR and \fB\-femit\-struct\-debug\-baseonly\fR,
-which will serve for most needs.
-.Sp
-A specification has the syntax[\fBdir:\fR|\fBind:\fR][\fBord:\fR|\fBgen:\fR](\fBany\fR|\fBsys\fR|\fBbase\fR|\fBnone\fR)
-.Sp
-The optional first word limits the specification to
-structs that are used directly (\fBdir:\fR) or used indirectly (\fBind:\fR).
-A struct type is used directly when it is the type of a variable, member.
-Indirect uses arise through pointers to structs.
-That is, when use of an incomplete struct would be legal, the use is indirect.
-An example is
-\&\fBstruct one direct; struct two * indirect;\fR.
-.Sp
-The optional second word limits the specification to
-ordinary structs (\fBord:\fR) or generic structs (\fBgen:\fR).
-Generic structs are a bit complicated to explain.
-For \*(C+, these are non-explicit specializations of template classes,
-or non-template classes within the above.
-Other programming languages have generics,
-but \fB\-femit\-struct\-debug\-detailed\fR does not yet implement them.
-.Sp
-The third word specifies the source files for those
-structs for which the compiler will emit debug information.
-The values \fBnone\fR and \fBany\fR have the normal meaning.
-The value \fBbase\fR means that
-the base of name of the file in which the type declaration appears
-must match the base of the name of the main compilation file.
-In practice, this means that
-types declared in \fIfoo.c\fR and \fIfoo.h\fR will have debug information,
-but types declared in other header will not.
-The value \fBsys\fR means those types satisfying \fBbase\fR
-or declared in system or compiler headers.
-.Sp
-You may need to experiment to determine the best settings for your application.
-.Sp
-The default is \fB\-femit\-struct\-debug\-detailed=all\fR.
-.Sp
-This option works only with \s-1DWARF\s0 2.
-.IP "\fB\-fenable\-icf\-debug\fR" 4
-.IX Item "-fenable-icf-debug"
-Generate additional debug information to support identical code folding (\s-1ICF\s0).
-This option only works with \s-1DWARF\s0 version 2 or higher.
-.IP "\fB\-fno\-merge\-debug\-strings\fR" 4
-.IX Item "-fno-merge-debug-strings"
-Direct the linker to not merge together strings in the debugging
-information which are identical in different object files. Merging is
-not supported by all assemblers or linkers. Merging decreases the size
-of the debug information in the output file at the cost of increasing
-link processing time. Merging is enabled by default.
-.IP "\fB\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
-.IX Item "-fdebug-prefix-map=old=new"
-When compiling files in directory \fI\fIold\fI\fR, record debugging
-information describing them as in \fI\fInew\fI\fR instead.
-.IP "\fB\-fno\-dwarf2\-cfi\-asm\fR" 4
-.IX Item "-fno-dwarf2-cfi-asm"
-Emit \s-1DWARF\s0 2 unwind info as compiler generated \f(CW\*(C`.eh_frame\*(C'\fR section
-instead of using \s-1GAS\s0 \f(CW\*(C`.cfi_*\*(C'\fR directives.
-.IP "\fB\-p\fR" 4
-.IX Item "-p"
-Generate extra code to write profile information suitable for the
-analysis program \fBprof\fR. You must use this option when compiling
-the source files you want data about, and you must also use it when
-linking.
-.IP "\fB\-pg\fR" 4
-.IX Item "-pg"
-Generate extra code to write profile information suitable for the
-analysis program \fBgprof\fR. You must use this option when compiling
-the source files you want data about, and you must also use it when
-linking.
-.IP "\fB\-Q\fR" 4
-.IX Item "-Q"
-Makes the compiler print out each function name as it is compiled, and
-print some statistics about each pass when it finishes.
-.IP "\fB\-ftime\-report\fR" 4
-.IX Item "-ftime-report"
-Makes the compiler print some statistics about the time consumed by each
-pass when it finishes.
-.IP "\fB\-fmem\-report\fR" 4
-.IX Item "-fmem-report"
-Makes the compiler print some statistics about permanent memory
-allocation when it finishes.
-.IP "\fB\-fpre\-ipa\-mem\-report\fR" 4
-.IX Item "-fpre-ipa-mem-report"
-.PD 0
-.IP "\fB\-fpost\-ipa\-mem\-report\fR" 4
-.IX Item "-fpost-ipa-mem-report"
-.PD
-Makes the compiler print some statistics about permanent memory
-allocation before or after interprocedural optimization.
-.IP "\fB\-fstack\-usage\fR" 4
-.IX Item "-fstack-usage"
-Makes the compiler output stack usage information for the program, on a
-per-function basis. The filename for the dump is made by appending
-\&\fI.su\fR to the \fIauxname\fR. \fIauxname\fR is generated from the name of
-the output file, if explicitly specified and it is not an executable,
-otherwise it is the basename of the source file. An entry is made up
-of three fields:
-.RS 4
-.IP "\(bu" 4
-The name of the function.
-.IP "\(bu" 4
-A number of bytes.
-.IP "\(bu" 4
-One or more qualifiers: \f(CW\*(C`static\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR, \f(CW\*(C`bounded\*(C'\fR.
-.RE
-.RS 4
-.Sp
-The qualifier \f(CW\*(C`static\*(C'\fR means that the function manipulates the stack
-statically: a fixed number of bytes are allocated for the frame on function
-entry and released on function exit; no stack adjustments are otherwise made
-in the function. The second field is this fixed number of bytes.
-.Sp
-The qualifier \f(CW\*(C`dynamic\*(C'\fR means that the function manipulates the stack
-dynamically: in addition to the static allocation described above, stack
-adjustments are made in the body of the function, for example to push/pop
-arguments around function calls. If the qualifier \f(CW\*(C`bounded\*(C'\fR is also
-present, the amount of these adjustments is bounded at compile-time and
-the second field is an upper bound of the total amount of stack used by
-the function. If it is not present, the amount of these adjustments is
-not bounded at compile-time and the second field only represents the
-bounded part.
-.RE
-.IP "\fB\-fprofile\-arcs\fR" 4
-.IX Item "-fprofile-arcs"
-Add code so that program flow \fIarcs\fR are instrumented. During
-execution the program records how many times each branch and call is
-executed and how many times it is taken or returns. When the compiled
-program exits it saves this data to a file called
-\&\fI\fIauxname\fI.gcda\fR for each source file. The data may be used for
-profile-directed optimizations (\fB\-fbranch\-probabilities\fR), or for
-test coverage analysis (\fB\-ftest\-coverage\fR). Each object file's
-\&\fIauxname\fR is generated from the name of the output file, if
-explicitly specified and it is not the final executable, otherwise it is
-the basename of the source file. In both cases any suffix is removed
-(e.g. \fIfoo.gcda\fR for input file \fIdir/foo.c\fR, or
-\&\fIdir/foo.gcda\fR for output file specified as \fB\-o dir/foo.o\fR).
-.IP "\fB\-\-coverage\fR" 4
-.IX Item "--coverage"
-This option is used to compile and link code instrumented for coverage
-analysis. The option is a synonym for \fB\-fprofile\-arcs\fR
-\&\fB\-ftest\-coverage\fR (when compiling) and \fB\-lgcov\fR (when
-linking). See the documentation for those options for more details.
-.RS 4
-.IP "\(bu" 4
-Compile the source files with \fB\-fprofile\-arcs\fR plus optimization
-and code generation options. For test coverage analysis, use the
-additional \fB\-ftest\-coverage\fR option. You do not need to profile
-every source file in a program.
-.IP "\(bu" 4
-Link your object files with \fB\-lgcov\fR or \fB\-fprofile\-arcs\fR
-(the latter implies the former).
-.IP "\(bu" 4
-Run the program on a representative workload to generate the arc profile
-information. This may be repeated any number of times. You can run
-concurrent instances of your program, and provided that the file system
-supports locking, the data files will be correctly updated. Also
-\&\f(CW\*(C`fork\*(C'\fR calls are detected and correctly handled (double counting
-will not happen).
-.IP "\(bu" 4
-For profile-directed optimizations, compile the source files again with
-the same optimization and code generation options plus
-\&\fB\-fbranch\-probabilities\fR.
-.IP "\(bu" 4
-For test coverage analysis, use \fBgcov\fR to produce human readable
-information from the \fI.gcno\fR and \fI.gcda\fR files. Refer to the
-\&\fBgcov\fR documentation for further information.
-.RE
-.RS 4
-.Sp
-With \fB\-fprofile\-arcs\fR, for each function of your program \s-1GCC\s0
-creates a program flow graph, then finds a spanning tree for the graph.
-Only arcs that are not on the spanning tree have to be instrumented: the
-compiler adds code to count the number of times that these arcs are
-executed. When an arc is the only exit or only entrance to a block, the
-instrumentation code can be added to the block; otherwise, a new basic
-block must be created to hold the instrumentation code.
-.RE
-.IP "\fB\-ftest\-coverage\fR" 4
-.IX Item "-ftest-coverage"
-Produce a notes file that the \fBgcov\fR code-coverage utility can use to
-show program coverage. Each source file's note file is called
-\&\fI\fIauxname\fI.gcno\fR. Refer to the \fB\-fprofile\-arcs\fR option
-above for a description of \fIauxname\fR and instructions on how to
-generate test coverage data. Coverage data will match the source files
-more closely, if you do not optimize.
-.IP "\fB\-fdbg\-cnt\-list\fR" 4
-.IX Item "-fdbg-cnt-list"
-Print the name and the counter upper bound for all debug counters.
-.IP "\fB\-fdbg\-cnt=\fR\fIcounter-value-list\fR" 4
-.IX Item "-fdbg-cnt=counter-value-list"
-Set the internal debug counter upper bound. \fIcounter-value-list\fR
-is a comma-separated list of \fIname\fR:\fIvalue\fR pairs
-which sets the upper bound of each debug counter \fIname\fR to \fIvalue\fR.
-All debug counters have the initial upper bound of \fI\s-1UINT_MAX\s0\fR,
-thus \fIdbg_cnt()\fR returns true always unless the upper bound is set by this option.
-e.g. With \-fdbg\-cnt=dce:10,tail_call:0
-dbg_cnt(dce) will return true only for first 10 invocations
-.IP "\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR" 4
-.IX Item "-fenable-kind-pass"
-.PD 0
-.IP "\fB\-fdisable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
-.IX Item "-fdisable-kind-pass=range-list"
-.PD
-This is a set of debugging options that are used to explicitly disable/enable
-optimization passes. For compiler users, regular options for enabling/disabling
-passes should be used instead.
-.RS 4
-.IP "*<\-fdisable\-ipa\-\fIpass\fR>" 4
-.IX Item "*<-fdisable-ipa-pass>"
-Disable ipa pass \fIpass\fR. \fIpass\fR is the pass name. If the same pass is
-statically invoked in the compiler multiple times, the pass name should be
-appended with a sequential number starting from 1.
-.IP "*<\-fdisable\-rtl\-\fIpass\fR>" 4
-.IX Item "*<-fdisable-rtl-pass>"
-.PD 0
-.IP "*<\-fdisable\-rtl\-\fIpass\fR=\fIrange-list\fR>" 4
-.IX Item "*<-fdisable-rtl-pass=range-list>"
-.PD
-Disable rtl pass \fIpass\fR. \fIpass\fR is the pass name. If the same pass is
-statically invoked in the compiler multiple times, the pass name should be
-appended with a sequential number starting from 1. \fIrange-list\fR is a comma
-seperated list of function ranges or assembler names. Each range is a number
-pair seperated by a colon. The range is inclusive in both ends. If the range
-is trivial, the number pair can be simplified as a single number. If the
-function's cgraph node's \fIuid\fR is falling within one of the specified ranges,
-the \fIpass\fR is disabled for that function. The \fIuid\fR is shown in the
-function header of a dump file, and the pass names can be dumped by using
-option \fB\-fdump\-passes\fR.
-.IP "*<\-fdisable\-tree\-\fIpass\fR>" 4
-.IX Item "*<-fdisable-tree-pass>"
-.PD 0
-.IP "*<\-fdisable\-tree\-\fIpass\fR=\fIrange-list\fR>" 4
-.IX Item "*<-fdisable-tree-pass=range-list>"
-.PD
-Disable tree pass \fIpass\fR. See \fB\-fdisable\-rtl\fR for the description of
-option arguments.
-.IP "*<\-fenable\-ipa\-\fIpass\fR>" 4
-.IX Item "*<-fenable-ipa-pass>"
-Enable ipa pass \fIpass\fR. \fIpass\fR is the pass name. If the same pass is
-statically invoked in the compiler multiple times, the pass name should be
-appended with a sequential number starting from 1.
-.IP "*<\-fenable\-rtl\-\fIpass\fR>" 4
-.IX Item "*<-fenable-rtl-pass>"
-.PD 0
-.IP "*<\-fenable\-rtl\-\fIpass\fR=\fIrange-list\fR>" 4
-.IX Item "*<-fenable-rtl-pass=range-list>"
-.PD
-Enable rtl pass \fIpass\fR. See \fB\-fdisable\-rtl\fR for option argument
-description and examples.
-.IP "*<\-fenable\-tree\-\fIpass\fR>" 4
-.IX Item "*<-fenable-tree-pass>"
-.PD 0
-.IP "*<\-fenable\-tree\-\fIpass\fR=\fIrange-list\fR>" 4
-.IX Item "*<-fenable-tree-pass=range-list>"
-.PD
-Enable tree pass \fIpass\fR. See \fB\-fdisable\-rtl\fR for the description
-of option arguments.
-.Sp
-.Vb 10
-\& # disable ccp1 for all functions
-\& \-fdisable\-tree\-ccp1
-\& # disable complete unroll for function whose cgraph node uid is 1
-\& \-fenable\-tree\-cunroll=1
-\& # disable gcse2 for functions at the following ranges [1,1],
-\& # [300,400], and [400,1000]
-\& # disable gcse2 for functions foo and foo2
-\& \-fdisable\-rtl\-gcse2=foo,foo2
-\& # disable early inlining
-\& \-fdisable\-tree\-einline
-\& # disable ipa inlining
-\& \-fdisable\-ipa\-inline
-\& # enable tree full unroll
-\& \-fenable\-tree\-unroll
-.Ve
-.RE
-.RS 4
-.RE
-.IP "\fB\-d\fR\fIletters\fR" 4
-.IX Item "-dletters"
-.PD 0
-.IP "\fB\-fdump\-rtl\-\fR\fIpass\fR" 4
-.IX Item "-fdump-rtl-pass"
-.PD
-Says to make debugging dumps during compilation at times specified by
-\&\fIletters\fR. This is used for debugging the RTL-based passes of the
-compiler. The file names for most of the dumps are made by appending
-a pass number and a word to the \fIdumpname\fR, and the files are
-created in the directory of the output file. Note that the pass
-number is computed statically as passes get registered into the pass
-manager. Thus the numbering is not related to the dynamic order of
-execution of passes. In particular, a pass installed by a plugin
-could have a number over 200 even if it executed quite early.
-\&\fIdumpname\fR is generated from the name of the output file, if
-explicitly specified and it is not an executable, otherwise it is the
-basename of the source file. These switches may have different effects
-when \fB\-E\fR is used for preprocessing.
-.Sp
-Debug dumps can be enabled with a \fB\-fdump\-rtl\fR switch or some
-\&\fB\-d\fR option \fIletters\fR. Here are the possible
-letters for use in \fIpass\fR and \fIletters\fR, and their meanings:
-.RS 4
-.IP "\fB\-fdump\-rtl\-alignments\fR" 4
-.IX Item "-fdump-rtl-alignments"
-Dump after branch alignments have been computed.
-.IP "\fB\-fdump\-rtl\-asmcons\fR" 4
-.IX Item "-fdump-rtl-asmcons"
-Dump after fixing rtl statements that have unsatisfied in/out constraints.
-.IP "\fB\-fdump\-rtl\-auto_inc_dec\fR" 4
-.IX Item "-fdump-rtl-auto_inc_dec"
-Dump after auto-inc-dec discovery. This pass is only run on
-architectures that have auto inc or auto dec instructions.
-.IP "\fB\-fdump\-rtl\-barriers\fR" 4
-.IX Item "-fdump-rtl-barriers"
-Dump after cleaning up the barrier instructions.
-.IP "\fB\-fdump\-rtl\-bbpart\fR" 4
-.IX Item "-fdump-rtl-bbpart"
-Dump after partitioning hot and cold basic blocks.
-.IP "\fB\-fdump\-rtl\-bbro\fR" 4
-.IX Item "-fdump-rtl-bbro"
-Dump after block reordering.
-.IP "\fB\-fdump\-rtl\-btl1\fR" 4
-.IX Item "-fdump-rtl-btl1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-btl2\fR" 4
-.IX Item "-fdump-rtl-btl2"
-.PD
-\&\fB\-fdump\-rtl\-btl1\fR and \fB\-fdump\-rtl\-btl2\fR enable dumping
-after the two branch
-target load optimization passes.
-.IP "\fB\-fdump\-rtl\-bypass\fR" 4
-.IX Item "-fdump-rtl-bypass"
-Dump after jump bypassing and control flow optimizations.
-.IP "\fB\-fdump\-rtl\-combine\fR" 4
-.IX Item "-fdump-rtl-combine"
-Dump after the \s-1RTL\s0 instruction combination pass.
-.IP "\fB\-fdump\-rtl\-compgotos\fR" 4
-.IX Item "-fdump-rtl-compgotos"
-Dump after duplicating the computed gotos.
-.IP "\fB\-fdump\-rtl\-ce1\fR" 4
-.IX Item "-fdump-rtl-ce1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-ce2\fR" 4
-.IX Item "-fdump-rtl-ce2"
-.IP "\fB\-fdump\-rtl\-ce3\fR" 4
-.IX Item "-fdump-rtl-ce3"
-.PD
-\&\fB\-fdump\-rtl\-ce1\fR, \fB\-fdump\-rtl\-ce2\fR, and
-\&\fB\-fdump\-rtl\-ce3\fR enable dumping after the three
-if conversion passes.
-.IP "\fB\-fdump\-rtl\-cprop_hardreg\fR" 4
-.IX Item "-fdump-rtl-cprop_hardreg"
-Dump after hard register copy propagation.
-.IP "\fB\-fdump\-rtl\-csa\fR" 4
-.IX Item "-fdump-rtl-csa"
-Dump after combining stack adjustments.
-.IP "\fB\-fdump\-rtl\-cse1\fR" 4
-.IX Item "-fdump-rtl-cse1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-cse2\fR" 4
-.IX Item "-fdump-rtl-cse2"
-.PD
-\&\fB\-fdump\-rtl\-cse1\fR and \fB\-fdump\-rtl\-cse2\fR enable dumping after
-the two common sub-expression elimination passes.
-.IP "\fB\-fdump\-rtl\-dce\fR" 4
-.IX Item "-fdump-rtl-dce"
-Dump after the standalone dead code elimination passes.
-.IP "\fB\-fdump\-rtl\-dbr\fR" 4
-.IX Item "-fdump-rtl-dbr"
-Dump after delayed branch scheduling.
-.IP "\fB\-fdump\-rtl\-dce1\fR" 4
-.IX Item "-fdump-rtl-dce1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-dce2\fR" 4
-.IX Item "-fdump-rtl-dce2"
-.PD
-\&\fB\-fdump\-rtl\-dce1\fR and \fB\-fdump\-rtl\-dce2\fR enable dumping after
-the two dead store elimination passes.
-.IP "\fB\-fdump\-rtl\-eh\fR" 4
-.IX Item "-fdump-rtl-eh"
-Dump after finalization of \s-1EH\s0 handling code.
-.IP "\fB\-fdump\-rtl\-eh_ranges\fR" 4
-.IX Item "-fdump-rtl-eh_ranges"
-Dump after conversion of \s-1EH\s0 handling range regions.
-.IP "\fB\-fdump\-rtl\-expand\fR" 4
-.IX Item "-fdump-rtl-expand"
-Dump after \s-1RTL\s0 generation.
-.IP "\fB\-fdump\-rtl\-fwprop1\fR" 4
-.IX Item "-fdump-rtl-fwprop1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-fwprop2\fR" 4
-.IX Item "-fdump-rtl-fwprop2"
-.PD
-\&\fB\-fdump\-rtl\-fwprop1\fR and \fB\-fdump\-rtl\-fwprop2\fR enable
-dumping after the two forward propagation passes.
-.IP "\fB\-fdump\-rtl\-gcse1\fR" 4
-.IX Item "-fdump-rtl-gcse1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-gcse2\fR" 4
-.IX Item "-fdump-rtl-gcse2"
-.PD
-\&\fB\-fdump\-rtl\-gcse1\fR and \fB\-fdump\-rtl\-gcse2\fR enable dumping
-after global common subexpression elimination.
-.IP "\fB\-fdump\-rtl\-init\-regs\fR" 4
-.IX Item "-fdump-rtl-init-regs"
-Dump after the initialization of the registers.
-.IP "\fB\-fdump\-rtl\-initvals\fR" 4
-.IX Item "-fdump-rtl-initvals"
-Dump after the computation of the initial value sets.
-.IP "\fB\-fdump\-rtl\-into_cfglayout\fR" 4
-.IX Item "-fdump-rtl-into_cfglayout"
-Dump after converting to cfglayout mode.
-.IP "\fB\-fdump\-rtl\-ira\fR" 4
-.IX Item "-fdump-rtl-ira"
-Dump after iterated register allocation.
-.IP "\fB\-fdump\-rtl\-jump\fR" 4
-.IX Item "-fdump-rtl-jump"
-Dump after the second jump optimization.
-.IP "\fB\-fdump\-rtl\-loop2\fR" 4
-.IX Item "-fdump-rtl-loop2"
-\&\fB\-fdump\-rtl\-loop2\fR enables dumping after the rtl
-loop optimization passes.
-.IP "\fB\-fdump\-rtl\-mach\fR" 4
-.IX Item "-fdump-rtl-mach"
-Dump after performing the machine dependent reorganization pass, if that
-pass exists.
-.IP "\fB\-fdump\-rtl\-mode_sw\fR" 4
-.IX Item "-fdump-rtl-mode_sw"
-Dump after removing redundant mode switches.
-.IP "\fB\-fdump\-rtl\-rnreg\fR" 4
-.IX Item "-fdump-rtl-rnreg"
-Dump after register renumbering.
-.IP "\fB\-fdump\-rtl\-outof_cfglayout\fR" 4
-.IX Item "-fdump-rtl-outof_cfglayout"
-Dump after converting from cfglayout mode.
-.IP "\fB\-fdump\-rtl\-peephole2\fR" 4
-.IX Item "-fdump-rtl-peephole2"
-Dump after the peephole pass.
-.IP "\fB\-fdump\-rtl\-postreload\fR" 4
-.IX Item "-fdump-rtl-postreload"
-Dump after post-reload optimizations.
-.IP "\fB\-fdump\-rtl\-pro_and_epilogue\fR" 4
-.IX Item "-fdump-rtl-pro_and_epilogue"
-Dump after generating the function pro and epilogues.
-.IP "\fB\-fdump\-rtl\-regmove\fR" 4
-.IX Item "-fdump-rtl-regmove"
-Dump after the register move pass.
-.IP "\fB\-fdump\-rtl\-sched1\fR" 4
-.IX Item "-fdump-rtl-sched1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-sched2\fR" 4
-.IX Item "-fdump-rtl-sched2"
-.PD
-\&\fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR enable dumping
-after the basic block scheduling passes.
-.IP "\fB\-fdump\-rtl\-see\fR" 4
-.IX Item "-fdump-rtl-see"
-Dump after sign extension elimination.
-.IP "\fB\-fdump\-rtl\-seqabstr\fR" 4
-.IX Item "-fdump-rtl-seqabstr"
-Dump after common sequence discovery.
-.IP "\fB\-fdump\-rtl\-shorten\fR" 4
-.IX Item "-fdump-rtl-shorten"
-Dump after shortening branches.
-.IP "\fB\-fdump\-rtl\-sibling\fR" 4
-.IX Item "-fdump-rtl-sibling"
-Dump after sibling call optimizations.
-.IP "\fB\-fdump\-rtl\-split1\fR" 4
-.IX Item "-fdump-rtl-split1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-split2\fR" 4
-.IX Item "-fdump-rtl-split2"
-.IP "\fB\-fdump\-rtl\-split3\fR" 4
-.IX Item "-fdump-rtl-split3"
-.IP "\fB\-fdump\-rtl\-split4\fR" 4
-.IX Item "-fdump-rtl-split4"
-.IP "\fB\-fdump\-rtl\-split5\fR" 4
-.IX Item "-fdump-rtl-split5"
-.PD
-\&\fB\-fdump\-rtl\-split1\fR, \fB\-fdump\-rtl\-split2\fR,
-\&\fB\-fdump\-rtl\-split3\fR, \fB\-fdump\-rtl\-split4\fR and
-\&\fB\-fdump\-rtl\-split5\fR enable dumping after five rounds of
-instruction splitting.
-.IP "\fB\-fdump\-rtl\-sms\fR" 4
-.IX Item "-fdump-rtl-sms"
-Dump after modulo scheduling. This pass is only run on some
-architectures.
-.IP "\fB\-fdump\-rtl\-stack\fR" 4
-.IX Item "-fdump-rtl-stack"
-Dump after conversion from \s-1GCC\s0's \*(L"flat register file\*(R" registers to the
-x87's stack-like registers. This pass is only run on x86 variants.
-.IP "\fB\-fdump\-rtl\-subreg1\fR" 4
-.IX Item "-fdump-rtl-subreg1"
-.PD 0
-.IP "\fB\-fdump\-rtl\-subreg2\fR" 4
-.IX Item "-fdump-rtl-subreg2"
-.PD
-\&\fB\-fdump\-rtl\-subreg1\fR and \fB\-fdump\-rtl\-subreg2\fR enable dumping after
-the two subreg expansion passes.
-.IP "\fB\-fdump\-rtl\-unshare\fR" 4
-.IX Item "-fdump-rtl-unshare"
-Dump after all rtl has been unshared.
-.IP "\fB\-fdump\-rtl\-vartrack\fR" 4
-.IX Item "-fdump-rtl-vartrack"
-Dump after variable tracking.
-.IP "\fB\-fdump\-rtl\-vregs\fR" 4
-.IX Item "-fdump-rtl-vregs"
-Dump after converting virtual registers to hard registers.
-.IP "\fB\-fdump\-rtl\-web\fR" 4
-.IX Item "-fdump-rtl-web"
-Dump after live range splitting.
-.IP "\fB\-fdump\-rtl\-regclass\fR" 4
-.IX Item "-fdump-rtl-regclass"
-.PD 0
-.IP "\fB\-fdump\-rtl\-subregs_of_mode_init\fR" 4
-.IX Item "-fdump-rtl-subregs_of_mode_init"
-.IP "\fB\-fdump\-rtl\-subregs_of_mode_finish\fR" 4
-.IX Item "-fdump-rtl-subregs_of_mode_finish"
-.IP "\fB\-fdump\-rtl\-dfinit\fR" 4
-.IX Item "-fdump-rtl-dfinit"
-.IP "\fB\-fdump\-rtl\-dfinish\fR" 4
-.IX Item "-fdump-rtl-dfinish"
-.PD
-These dumps are defined but always produce empty files.
-.IP "\fB\-fdump\-rtl\-all\fR" 4
-.IX Item "-fdump-rtl-all"
-Produce all the dumps listed above.
-.IP "\fB\-dA\fR" 4
-.IX Item "-dA"
-Annotate the assembler output with miscellaneous debugging information.
-.IP "\fB\-dD\fR" 4
-.IX Item "-dD"
-Dump all macro definitions, at the end of preprocessing, in addition to
-normal output.
-.IP "\fB\-dH\fR" 4
-.IX Item "-dH"
-Produce a core dump whenever an error occurs.
-.IP "\fB\-dm\fR" 4
-.IX Item "-dm"
-Print statistics on memory usage, at the end of the run, to
-standard error.
-.IP "\fB\-dp\fR" 4
-.IX Item "-dp"
-Annotate the assembler output with a comment indicating which
-pattern and alternative was used. The length of each instruction is
-also printed.
-.IP "\fB\-dP\fR" 4
-.IX Item "-dP"
-Dump the \s-1RTL\s0 in the assembler output as a comment before each instruction.
-Also turns on \fB\-dp\fR annotation.
-.IP "\fB\-dv\fR" 4
-.IX Item "-dv"
-For each of the other indicated dump files (\fB\-fdump\-rtl\-\fR\fIpass\fR),
-dump a representation of the control flow graph suitable for viewing with \s-1VCG\s0
-to \fI\fIfile\fI.\fIpass\fI.vcg\fR.
-.IP "\fB\-dx\fR" 4
-.IX Item "-dx"
-Just generate \s-1RTL\s0 for a function instead of compiling it. Usually used
-with \fB\-fdump\-rtl\-expand\fR.
-.RE
-.RS 4
-.RE
-.IP "\fB\-fdump\-noaddr\fR" 4
-.IX Item "-fdump-noaddr"
-When doing debugging dumps, suppress address output. This makes it more
-feasible to use diff on debugging dumps for compiler invocations with
-different compiler binaries and/or different
-text / bss / data / heap / stack / dso start locations.
-.IP "\fB\-fdump\-unnumbered\fR" 4
-.IX Item "-fdump-unnumbered"
-When doing debugging dumps, suppress instruction numbers and address output.
-This makes it more feasible to use diff on debugging dumps for compiler
-invocations with different options, in particular with and without
-\&\fB\-g\fR.
-.IP "\fB\-fdump\-unnumbered\-links\fR" 4
-.IX Item "-fdump-unnumbered-links"
-When doing debugging dumps (see \fB\-d\fR option above), suppress
-instruction numbers for the links to the previous and next instructions
-in a sequence.
-.IP "\fB\-fdump\-translation\-unit\fR (\*(C+ only)" 4
-.IX Item "-fdump-translation-unit ( only)"
-.PD 0
-.IP "\fB\-fdump\-translation\-unit\-\fR\fIoptions\fR\fB \fR(\*(C+ only)" 4
-.IX Item "-fdump-translation-unit-options ( only)"
-.PD
-Dump a representation of the tree structure for the entire translation
-unit to a file. The file name is made by appending \fI.tu\fR to the
-source file name, and the file is created in the same directory as the
-output file. If the \fB\-\fR\fIoptions\fR form is used, \fIoptions\fR
-controls the details of the dump as described for the
-\&\fB\-fdump\-tree\fR options.
-.IP "\fB\-fdump\-class\-hierarchy\fR (\*(C+ only)" 4
-.IX Item "-fdump-class-hierarchy ( only)"
-.PD 0
-.IP "\fB\-fdump\-class\-hierarchy\-\fR\fIoptions\fR\fB \fR(\*(C+ only)" 4
-.IX Item "-fdump-class-hierarchy-options ( only)"
-.PD
-Dump a representation of each class's hierarchy and virtual function
-table layout to a file. The file name is made by appending
-\&\fI.class\fR to the source file name, and the file is created in the
-same directory as the output file. If the \fB\-\fR\fIoptions\fR form
-is used, \fIoptions\fR controls the details of the dump as described
-for the \fB\-fdump\-tree\fR options.
-.IP "\fB\-fdump\-ipa\-\fR\fIswitch\fR" 4
-.IX Item "-fdump-ipa-switch"
-Control the dumping at various stages of inter-procedural analysis
-language tree to a file. The file name is generated by appending a
-switch specific suffix to the source file name, and the file is created
-in the same directory as the output file. The following dumps are
-possible:
-.RS 4
-.IP "\fBall\fR" 4
-.IX Item "all"
-Enables all inter-procedural analysis dumps.
-.IP "\fBcgraph\fR" 4
-.IX Item "cgraph"
-Dumps information about call-graph optimization, unused function removal,
-and inlining decisions.
-.IP "\fBinline\fR" 4
-.IX Item "inline"
-Dump after function inlining.
-.RE
-.RS 4
-.RE
-.IP "\fB\-fdump\-passes\fR" 4
-.IX Item "-fdump-passes"
-Dump the list of optimization passes that are turned on and off by
-the current command line options.
-.IP "\fB\-fdump\-statistics\-\fR\fIoption\fR" 4
-.IX Item "-fdump-statistics-option"
-Enable and control dumping of pass statistics in a separate file. The
-file name is generated by appending a suffix ending in
-\&\fB.statistics\fR to the source file name, and the file is created in
-the same directory as the output file. If the \fB\-\fR\fIoption\fR
-form is used, \fB\-stats\fR will cause counters to be summed over the
-whole compilation unit while \fB\-details\fR will dump every event as
-the passes generate them. The default with no option is to sum
-counters for each function compiled.
-.IP "\fB\-fdump\-tree\-\fR\fIswitch\fR" 4
-.IX Item "-fdump-tree-switch"
-.PD 0
-.IP "\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR" 4
-.IX Item "-fdump-tree-switch-options"
-.PD
-Control the dumping at various stages of processing the intermediate
-language tree to a file. The file name is generated by appending a
-switch specific suffix to the source file name, and the file is
-created in the same directory as the output file. If the
-\&\fB\-\fR\fIoptions\fR form is used, \fIoptions\fR is a list of
-\&\fB\-\fR separated options that control the details of the dump. Not
-all options are applicable to all dumps, those which are not
-meaningful will be ignored. The following options are available
-.RS 4
-.IP "\fBaddress\fR" 4
-.IX Item "address"
-Print the address of each node. Usually this is not meaningful as it
-changes according to the environment and source file. Its primary use
-is for tying up a dump file with a debug environment.
-.IP "\fBasmname\fR" 4
-.IX Item "asmname"
-If \f(CW\*(C`DECL_ASSEMBLER_NAME\*(C'\fR has been set for a given decl, use that
-in the dump instead of \f(CW\*(C`DECL_NAME\*(C'\fR. Its primary use is ease of
-use working backward from mangled names in the assembly file.
-.IP "\fBslim\fR" 4
-.IX Item "slim"
-Inhibit dumping of members of a scope or body of a function merely
-because that scope has been reached. Only dump such items when they
-are directly reachable by some other path. When dumping pretty-printed
-trees, this option inhibits dumping the bodies of control structures.
-.IP "\fBraw\fR" 4
-.IX Item "raw"
-Print a raw representation of the tree. By default, trees are
-pretty-printed into a C\-like representation.
-.IP "\fBdetails\fR" 4
-.IX Item "details"
-Enable more detailed dumps (not honored by every dump option).
-.IP "\fBstats\fR" 4
-.IX Item "stats"
-Enable dumping various statistics about the pass (not honored by every dump
-option).
-.IP "\fBblocks\fR" 4
-.IX Item "blocks"
-Enable showing basic block boundaries (disabled in raw dumps).
-.IP "\fBvops\fR" 4
-.IX Item "vops"
-Enable showing virtual operands for every statement.
-.IP "\fBlineno\fR" 4
-.IX Item "lineno"
-Enable showing line numbers for statements.
-.IP "\fBuid\fR" 4
-.IX Item "uid"
-Enable showing the unique \s-1ID\s0 (\f(CW\*(C`DECL_UID\*(C'\fR) for each variable.
-.IP "\fBverbose\fR" 4
-.IX Item "verbose"
-Enable showing the tree dump for each statement.
-.IP "\fBeh\fR" 4
-.IX Item "eh"
-Enable showing the \s-1EH\s0 region number holding each statement.
-.IP "\fBall\fR" 4
-.IX Item "all"
-Turn on all options, except \fBraw\fR, \fBslim\fR, \fBverbose\fR
-and \fBlineno\fR.
-.RE
-.RS 4
-.Sp
-The following tree dumps are possible:
-.IP "\fBoriginal\fR" 4
-.IX Item "original"
-Dump before any tree based optimization, to \fI\fIfile\fI.original\fR.
-.IP "\fBoptimized\fR" 4
-.IX Item "optimized"
-Dump after all tree based optimization, to \fI\fIfile\fI.optimized\fR.
-.IP "\fBgimple\fR" 4
-.IX Item "gimple"
-Dump each function before and after the gimplification pass to a file. The
-file name is made by appending \fI.gimple\fR to the source file name.
-.IP "\fBcfg\fR" 4
-.IX Item "cfg"
-Dump the control flow graph of each function to a file. The file name is
-made by appending \fI.cfg\fR to the source file name.
-.IP "\fBvcg\fR" 4
-.IX Item "vcg"
-Dump the control flow graph of each function to a file in \s-1VCG\s0 format. The
-file name is made by appending \fI.vcg\fR to the source file name. Note
-that if the file contains more than one function, the generated file cannot
-be used directly by \s-1VCG\s0. You will need to cut and paste each function's
-graph into its own separate file first.
-.IP "\fBch\fR" 4
-.IX Item "ch"
-Dump each function after copying loop headers. The file name is made by
-appending \fI.ch\fR to the source file name.
-.IP "\fBssa\fR" 4
-.IX Item "ssa"
-Dump \s-1SSA\s0 related information to a file. The file name is made by appending
-\&\fI.ssa\fR to the source file name.
-.IP "\fBalias\fR" 4
-.IX Item "alias"
-Dump aliasing information for each function. The file name is made by
-appending \fI.alias\fR to the source file name.
-.IP "\fBccp\fR" 4
-.IX Item "ccp"
-Dump each function after \s-1CCP\s0. The file name is made by appending
-\&\fI.ccp\fR to the source file name.
-.IP "\fBstoreccp\fR" 4
-.IX Item "storeccp"
-Dump each function after STORE-CCP. The file name is made by appending
-\&\fI.storeccp\fR to the source file name.
-.IP "\fBpre\fR" 4
-.IX Item "pre"
-Dump trees after partial redundancy elimination. The file name is made
-by appending \fI.pre\fR to the source file name.
-.IP "\fBfre\fR" 4
-.IX Item "fre"
-Dump trees after full redundancy elimination. The file name is made
-by appending \fI.fre\fR to the source file name.
-.IP "\fBcopyprop\fR" 4
-.IX Item "copyprop"
-Dump trees after copy propagation. The file name is made
-by appending \fI.copyprop\fR to the source file name.
-.IP "\fBstore_copyprop\fR" 4
-.IX Item "store_copyprop"
-Dump trees after store copy-propagation. The file name is made
-by appending \fI.store_copyprop\fR to the source file name.
-.IP "\fBdce\fR" 4
-.IX Item "dce"
-Dump each function after dead code elimination. The file name is made by
-appending \fI.dce\fR to the source file name.
-.IP "\fBmudflap\fR" 4
-.IX Item "mudflap"
-Dump each function after adding mudflap instrumentation. The file name is
-made by appending \fI.mudflap\fR to the source file name.
-.IP "\fBsra\fR" 4
-.IX Item "sra"
-Dump each function after performing scalar replacement of aggregates. The
-file name is made by appending \fI.sra\fR to the source file name.
-.IP "\fBsink\fR" 4
-.IX Item "sink"
-Dump each function after performing code sinking. The file name is made
-by appending \fI.sink\fR to the source file name.
-.IP "\fBdom\fR" 4
-.IX Item "dom"
-Dump each function after applying dominator tree optimizations. The file
-name is made by appending \fI.dom\fR to the source file name.
-.IP "\fBdse\fR" 4
-.IX Item "dse"
-Dump each function after applying dead store elimination. The file
-name is made by appending \fI.dse\fR to the source file name.
-.IP "\fBphiopt\fR" 4
-.IX Item "phiopt"
-Dump each function after optimizing \s-1PHI\s0 nodes into straightline code. The file
-name is made by appending \fI.phiopt\fR to the source file name.
-.IP "\fBforwprop\fR" 4
-.IX Item "forwprop"
-Dump each function after forward propagating single use variables. The file
-name is made by appending \fI.forwprop\fR to the source file name.
-.IP "\fBcopyrename\fR" 4
-.IX Item "copyrename"
-Dump each function after applying the copy rename optimization. The file
-name is made by appending \fI.copyrename\fR to the source file name.
-.IP "\fBnrv\fR" 4
-.IX Item "nrv"
-Dump each function after applying the named return value optimization on
-generic trees. The file name is made by appending \fI.nrv\fR to the source
-file name.
-.IP "\fBvect\fR" 4
-.IX Item "vect"
-Dump each function after applying vectorization of loops. The file name is
-made by appending \fI.vect\fR to the source file name.
-.IP "\fBslp\fR" 4
-.IX Item "slp"
-Dump each function after applying vectorization of basic blocks. The file name
-is made by appending \fI.slp\fR to the source file name.
-.IP "\fBvrp\fR" 4
-.IX Item "vrp"
-Dump each function after Value Range Propagation (\s-1VRP\s0). The file name
-is made by appending \fI.vrp\fR to the source file name.
-.IP "\fBall\fR" 4
-.IX Item "all"
-Enable all the available tree dumps with the flags provided in this option.
-.RE
-.RS 4
-.RE
-.IP "\fB\-ftree\-vectorizer\-verbose=\fR\fIn\fR" 4
-.IX Item "-ftree-vectorizer-verbose=n"
-This option controls the amount of debugging output the vectorizer prints.
-This information is written to standard error, unless
-\&\fB\-fdump\-tree\-all\fR or \fB\-fdump\-tree\-vect\fR is specified,
-in which case it is output to the usual dump listing file, \fI.vect\fR.
-For \fIn\fR=0 no diagnostic information is reported.
-If \fIn\fR=1 the vectorizer reports each loop that got vectorized,
-and the total number of loops that got vectorized.
-If \fIn\fR=2 the vectorizer also reports non-vectorized loops that passed
-the first analysis phase (vect_analyze_loop_form) \- i.e. countable,
-inner-most, single-bb, single\-entry/exit loops. This is the same verbosity
-level that \fB\-fdump\-tree\-vect\-stats\fR uses.
-Higher verbosity levels mean either more information dumped for each
-reported loop, or same amount of information reported for more loops:
-if \fIn\fR=3, vectorizer cost model information is reported.
-If \fIn\fR=4, alignment related information is added to the reports.
-If \fIn\fR=5, data-references related information (e.g. memory dependences,
-memory access-patterns) is added to the reports.
-If \fIn\fR=6, the vectorizer reports also non-vectorized inner-most loops
-that did not pass the first analysis phase (i.e., may not be countable, or
-may have complicated control-flow).
-If \fIn\fR=7, the vectorizer reports also non-vectorized nested loops.
-If \fIn\fR=8, \s-1SLP\s0 related information is added to the reports.
-For \fIn\fR=9, all the information the vectorizer generates during its
-analysis and transformation is reported. This is the same verbosity level
-that \fB\-fdump\-tree\-vect\-details\fR uses.
-.IP "\fB\-frandom\-seed=\fR\fIstring\fR" 4
-.IX Item "-frandom-seed=string"
-This option provides a seed that \s-1GCC\s0 uses when it would otherwise use
-random numbers. It is used to generate certain symbol names
-that have to be different in every compiled file. It is also used to
-place unique stamps in coverage data files and the object files that
-produce them. You can use the \fB\-frandom\-seed\fR option to produce
-reproducibly identical object files.
-.Sp
-The \fIstring\fR should be different for every file you compile.
-.IP "\fB\-fsched\-verbose=\fR\fIn\fR" 4
-.IX Item "-fsched-verbose=n"
-On targets that use instruction scheduling, this option controls the
-amount of debugging output the scheduler prints. This information is
-written to standard error, unless \fB\-fdump\-rtl\-sched1\fR or
-\&\fB\-fdump\-rtl\-sched2\fR is specified, in which case it is output
-to the usual dump listing file, \fI.sched1\fR or \fI.sched2\fR
-respectively. However for \fIn\fR greater than nine, the output is
-always printed to standard error.
-.Sp
-For \fIn\fR greater than zero, \fB\-fsched\-verbose\fR outputs the
-same information as \fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR.
-For \fIn\fR greater than one, it also output basic block probabilities,
-detailed ready list information and unit/insn info. For \fIn\fR greater
-than two, it includes \s-1RTL\s0 at abort point, control-flow and regions info.
-And for \fIn\fR over four, \fB\-fsched\-verbose\fR also includes
-dependence info.
-.IP "\fB\-save\-temps\fR" 4
-.IX Item "-save-temps"
-.PD 0
-.IP "\fB\-save\-temps=cwd\fR" 4
-.IX Item "-save-temps=cwd"
-.PD
-Store the usual \*(L"temporary\*(R" intermediate files permanently; place them
-in the current directory and name them based on the source file. Thus,
-compiling \fIfoo.c\fR with \fB\-c \-save\-temps\fR would produce files
-\&\fIfoo.i\fR and \fIfoo.s\fR, as well as \fIfoo.o\fR. This creates a
-preprocessed \fIfoo.i\fR output file even though the compiler now
-normally uses an integrated preprocessor.
-.Sp
-When used in combination with the \fB\-x\fR command line option,
-\&\fB\-save\-temps\fR is sensible enough to avoid over writing an
-input source file with the same extension as an intermediate file.
-The corresponding intermediate file may be obtained by renaming the
-source file before using \fB\-save\-temps\fR.
-.Sp
-If you invoke \s-1GCC\s0 in parallel, compiling several different source
-files that share a common base name in different subdirectories or the
-same source file compiled for multiple output destinations, it is
-likely that the different parallel compilers will interfere with each
-other, and overwrite the temporary files. For instance:
-.Sp
-.Vb 2
-\& gcc \-save\-temps \-o outdir1/foo.o indir1/foo.c&
-\& gcc \-save\-temps \-o outdir2/foo.o indir2/foo.c&
-.Ve
-.Sp
-may result in \fIfoo.i\fR and \fIfoo.o\fR being written to
-simultaneously by both compilers.
-.IP "\fB\-save\-temps=obj\fR" 4
-.IX Item "-save-temps=obj"
-Store the usual \*(L"temporary\*(R" intermediate files permanently. If the
-\&\fB\-o\fR option is used, the temporary files are based on the
-object file. If the \fB\-o\fR option is not used, the
-\&\fB\-save\-temps=obj\fR switch behaves like \fB\-save\-temps\fR.
-.Sp
-For example:
-.Sp
-.Vb 3
-\& gcc \-save\-temps=obj \-c foo.c
-\& gcc \-save\-temps=obj \-c bar.c \-o dir/xbar.o
-\& gcc \-save\-temps=obj foobar.c \-o dir2/yfoobar
-.Ve
-.Sp
-would create \fIfoo.i\fR, \fIfoo.s\fR, \fIdir/xbar.i\fR,
-\&\fIdir/xbar.s\fR, \fIdir2/yfoobar.i\fR, \fIdir2/yfoobar.s\fR, and
-\&\fIdir2/yfoobar.o\fR.
-.IP "\fB\-time\fR[\fB=\fR\fIfile\fR]" 4
-.IX Item "-time[=file]"
-Report the \s-1CPU\s0 time taken by each subprocess in the compilation
-sequence. For C source files, this is the compiler proper and assembler
-(plus the linker if linking is done).
-.Sp
-Without the specification of an output file, the output looks like this:
-.Sp
-.Vb 2
-\& # cc1 0.12 0.01
-\& # as 0.00 0.01
-.Ve
-.Sp
-The first number on each line is the \*(L"user time\*(R", that is time spent
-executing the program itself. The second number is \*(L"system time\*(R",
-time spent executing operating system routines on behalf of the program.
-Both numbers are in seconds.
-.Sp
-With the specification of an output file, the output is appended to the
-named file, and it looks like this:
-.Sp
-.Vb 2
-\& 0.12 0.01 cc1 <options>
-\& 0.00 0.01 as <options>
-.Ve
-.Sp
-The \*(L"user time\*(R" and the \*(L"system time\*(R" are moved before the program
-name, and the options passed to the program are displayed, so that one
-can later tell what file was being compiled, and with which options.
-.IP "\fB\-fvar\-tracking\fR" 4
-.IX Item "-fvar-tracking"
-Run variable tracking pass. It computes where variables are stored at each
-position in code. Better debugging information is then generated
-(if the debugging information format supports this information).
-.Sp
-It is enabled by default when compiling with optimization (\fB\-Os\fR,
-\&\fB\-O\fR, \fB\-O2\fR, ...), debugging information (\fB\-g\fR) and
-the debug info format supports it.
-.IP "\fB\-fvar\-tracking\-assignments\fR" 4
-.IX Item "-fvar-tracking-assignments"
-Annotate assignments to user variables early in the compilation and
-attempt to carry the annotations over throughout the compilation all the
-way to the end, in an attempt to improve debug information while
-optimizing. Use of \fB\-gdwarf\-4\fR is recommended along with it.
-.Sp
-It can be enabled even if var-tracking is disabled, in which case
-annotations will be created and maintained, but discarded at the end.
-.IP "\fB\-fvar\-tracking\-assignments\-toggle\fR" 4
-.IX Item "-fvar-tracking-assignments-toggle"
-Toggle \fB\-fvar\-tracking\-assignments\fR, in the same way that
-\&\fB\-gtoggle\fR toggles \fB\-g\fR.
-.IP "\fB\-print\-file\-name=\fR\fIlibrary\fR" 4
-.IX Item "-print-file-name=library"
-Print the full absolute name of the library file \fIlibrary\fR that
-would be used when linking\-\-\-and don't do anything else. With this
-option, \s-1GCC\s0 does not compile or link anything; it just prints the
-file name.
-.IP "\fB\-print\-multi\-directory\fR" 4
-.IX Item "-print-multi-directory"
-Print the directory name corresponding to the multilib selected by any
-other switches present in the command line. This directory is supposed
-to exist in \fB\s-1GCC_EXEC_PREFIX\s0\fR.
-.IP "\fB\-print\-multi\-lib\fR" 4
-.IX Item "-print-multi-lib"
-Print the mapping from multilib directory names to compiler switches
-that enable them. The directory name is separated from the switches by
-\&\fB;\fR, and each switch starts with an \fB@\fR instead of the
-\&\fB\-\fR, without spaces between multiple switches. This is supposed to
-ease shell-processing.
-.IP "\fB\-print\-multi\-os\-directory\fR" 4
-.IX Item "-print-multi-os-directory"
-Print the path to \s-1OS\s0 libraries for the selected
-multilib, relative to some \fIlib\fR subdirectory. If \s-1OS\s0 libraries are
-present in the \fIlib\fR subdirectory and no multilibs are used, this is
-usually just \fI.\fR, if \s-1OS\s0 libraries are present in \fIlib\fIsuffix\fI\fR
-sibling directories this prints e.g. \fI../lib64\fR, \fI../lib\fR or
-\&\fI../lib32\fR, or if \s-1OS\s0 libraries are present in \fIlib/\fIsubdir\fI\fR
-subdirectories it prints e.g. \fIamd64\fR, \fIsparcv9\fR or \fIev6\fR.
-.IP "\fB\-print\-prog\-name=\fR\fIprogram\fR" 4
-.IX Item "-print-prog-name=program"
-Like \fB\-print\-file\-name\fR, but searches for a program such as \fBcpp\fR.
-.IP "\fB\-print\-libgcc\-file\-name\fR" 4
-.IX Item "-print-libgcc-file-name"
-Same as \fB\-print\-file\-name=libgcc.a\fR.
-.Sp
-This is useful when you use \fB\-nostdlib\fR or \fB\-nodefaultlibs\fR
-but you do want to link with \fIlibgcc.a\fR. You can do
-.Sp
-.Vb 1
-\& gcc \-nostdlib <files>... \`gcc \-print\-libgcc\-file\-name\`
-.Ve
-.IP "\fB\-print\-search\-dirs\fR" 4
-.IX Item "-print-search-dirs"
-Print the name of the configured installation directory and a list of
-program and library directories \fBgcc\fR will search\-\-\-and don't do anything else.
-.Sp
-This is useful when \fBgcc\fR prints the error message
-\&\fBinstallation problem, cannot exec cpp0: No such file or directory\fR.
-To resolve this you either need to put \fIcpp0\fR and the other compiler
-components where \fBgcc\fR expects to find them, or you can set the environment
-variable \fB\s-1GCC_EXEC_PREFIX\s0\fR to the directory where you installed them.
-Don't forget the trailing \fB/\fR.
-.IP "\fB\-print\-sysroot\fR" 4
-.IX Item "-print-sysroot"
-Print the target sysroot directory that will be used during
-compilation. This is the target sysroot specified either at configure
-time or using the \fB\-\-sysroot\fR option, possibly with an extra
-suffix that depends on compilation options. If no target sysroot is
-specified, the option prints nothing.
-.IP "\fB\-print\-sysroot\-headers\-suffix\fR" 4
-.IX Item "-print-sysroot-headers-suffix"
-Print the suffix added to the target sysroot when searching for
-headers, or give an error if the compiler is not configured with such
-a suffix\-\-\-and don't do anything else.
-.IP "\fB\-dumpmachine\fR" 4
-.IX Item "-dumpmachine"
-Print the compiler's target machine (for example,
-\&\fBi686\-pc\-linux\-gnu\fR)\-\-\-and don't do anything else.
-.IP "\fB\-dumpversion\fR" 4
-.IX Item "-dumpversion"
-Print the compiler version (for example, \fB3.0\fR)\-\-\-and don't do
-anything else.
-.IP "\fB\-dumpspecs\fR" 4
-.IX Item "-dumpspecs"
-Print the compiler's built-in specs\-\-\-and don't do anything else. (This
-is used when \s-1GCC\s0 itself is being built.)
-.IP "\fB\-feliminate\-unused\-debug\-types\fR" 4
-.IX Item "-feliminate-unused-debug-types"
-Normally, when producing \s-1DWARF2\s0 output, \s-1GCC\s0 will emit debugging
-information for all types declared in a compilation
-unit, regardless of whether or not they are actually used
-in that compilation unit. Sometimes this is useful, such as
-if, in the debugger, you want to cast a value to a type that is
-not actually used in your program (but is declared). More often,
-however, this results in a significant amount of wasted space.
-With this option, \s-1GCC\s0 will avoid producing debug symbol output
-for types that are nowhere used in the source file being compiled.
-.SS "Options That Control Optimization"
-.IX Subsection "Options That Control Optimization"
-These options control various sorts of optimizations.
-.PP
-Without any optimization option, the compiler's goal is to reduce the
-cost of compilation and to make debugging produce the expected
-results. Statements are independent: if you stop the program with a
-breakpoint between statements, you can then assign a new value to any
-variable or change the program counter to any other statement in the
-function and get exactly the results you would expect from the source
-code.
-.PP
-Turning on optimization flags makes the compiler attempt to improve
-the performance and/or code size at the expense of compilation time
-and possibly the ability to debug the program.
-.PP
-The compiler performs optimization based on the knowledge it has of the
-program. Compiling multiple files at once to a single output file mode allows
-the compiler to use information gained from all of the files when compiling
-each of them.
-.PP
-Not all optimizations are controlled directly by a flag. Only
-optimizations that have a flag are listed in this section.
-.PP
-Most optimizations are only enabled if an \fB\-O\fR level is set on
-the command line. Otherwise they are disabled, even if individual
-optimization flags are specified.
-.PP
-Depending on the target and how \s-1GCC\s0 was configured, a slightly different
-set of optimizations may be enabled at each \fB\-O\fR level than
-those listed here. You can invoke \s-1GCC\s0 with \fB\-Q \-\-help=optimizers\fR
-to find out the exact set of optimizations that are enabled at each level.
-.IP "\fB\-O\fR" 4
-.IX Item "-O"
-.PD 0
-.IP "\fB\-O1\fR" 4
-.IX Item "-O1"
-.PD
-Optimize. Optimizing compilation takes somewhat more time, and a lot
-more memory for a large function.
-.Sp
-With \fB\-O\fR, the compiler tries to reduce code size and execution
-time, without performing any optimizations that take a great deal of
-compilation time.
-.Sp
-\&\fB\-O\fR turns on the following optimization flags:
-.Sp
-\&\fB\-fauto\-inc\-dec
-\&\-fcompare\-elim
-\&\-fcprop\-registers
-\&\-fdce
-\&\-fdefer\-pop
-\&\-fdelayed\-branch
-\&\-fdse
-\&\-fguess\-branch\-probability
-\&\-fif\-conversion2
-\&\-fif\-conversion
-\&\-fipa\-pure\-const
-\&\-fipa\-profile
-\&\-fipa\-reference
-\&\-fmerge\-constants
-\&\-fsplit\-wide\-types
-\&\-ftree\-bit\-ccp
-\&\-ftree\-builtin\-call\-dce
-\&\-ftree\-ccp
-\&\-ftree\-ch
-\&\-ftree\-copyrename
-\&\-ftree\-dce
-\&\-ftree\-dominator\-opts
-\&\-ftree\-dse
-\&\-ftree\-forwprop
-\&\-ftree\-fre
-\&\-ftree\-phiprop
-\&\-ftree\-sra
-\&\-ftree\-pta
-\&\-ftree\-ter
-\&\-funit\-at\-a\-time\fR
-.Sp
-\&\fB\-O\fR also turns on \fB\-fomit\-frame\-pointer\fR on machines
-where doing so does not interfere with debugging.
-.IP "\fB\-O2\fR" 4
-.IX Item "-O2"
-Optimize even more. \s-1GCC\s0 performs nearly all supported optimizations
-that do not involve a space-speed tradeoff.
-As compared to \fB\-O\fR, this option increases both compilation time
-and the performance of the generated code.
-.Sp
-\&\fB\-O2\fR turns on all optimization flags specified by \fB\-O\fR. It
-also turns on the following optimization flags:
-\&\fB\-fthread\-jumps
-\&\-falign\-functions \-falign\-jumps
-\&\-falign\-loops \-falign\-labels
-\&\-fcaller\-saves
-\&\-fcrossjumping
-\&\-fcse\-follow\-jumps \-fcse\-skip\-blocks
-\&\-fdelete\-null\-pointer\-checks
-\&\-fdevirtualize
-\&\-fexpensive\-optimizations
-\&\-fgcse \-fgcse\-lm
-\&\-finline\-small\-functions
-\&\-findirect\-inlining
-\&\-fipa\-sra
-\&\-foptimize\-sibling\-calls
-\&\-fpartial\-inlining
-\&\-fpeephole2
-\&\-fregmove
-\&\-freorder\-blocks \-freorder\-functions
-\&\-frerun\-cse\-after\-loop
-\&\-fsched\-interblock \-fsched\-spec
-\&\-fschedule\-insns \-fschedule\-insns2
-\&\-fstrict\-aliasing \-fstrict\-overflow
-\&\-ftree\-switch\-conversion
-\&\-ftree\-pre
-\&\-ftree\-vrp\fR
-.Sp
-Please note the warning under \fB\-fgcse\fR about
-invoking \fB\-O2\fR on programs that use computed gotos.
-.IP "\fB\-O3\fR" 4
-.IX Item "-O3"
-Optimize yet more. \fB\-O3\fR turns on all optimizations specified
-by \fB\-O2\fR and also turns on the \fB\-finline\-functions\fR,
-\&\fB\-funswitch\-loops\fR, \fB\-fpredictive\-commoning\fR,
-\&\fB\-fgcse\-after\-reload\fR, \fB\-ftree\-vectorize\fR and
-\&\fB\-fipa\-cp\-clone\fR options.
-.IP "\fB\-O0\fR" 4
-.IX Item "-O0"
-Reduce compilation time and make debugging produce the expected
-results. This is the default.
-.IP "\fB\-Os\fR" 4
-.IX Item "-Os"
-Optimize for size. \fB\-Os\fR enables all \fB\-O2\fR optimizations that
-do not typically increase code size. It also performs further
-optimizations designed to reduce code size.
-.Sp
-\&\fB\-Os\fR disables the following optimization flags:
-\&\fB\-falign\-functions \-falign\-jumps \-falign\-loops
-\&\-falign\-labels \-freorder\-blocks \-freorder\-blocks\-and\-partition
-\&\-fprefetch\-loop\-arrays \-ftree\-vect\-loop\-version\fR
-.IP "\fB\-Ofast\fR" 4
-.IX Item "-Ofast"
-Disregard strict standards compliance. \fB\-Ofast\fR enables all
-\&\fB\-O3\fR optimizations. It also enables optimizations that are not
-valid for all standard compliant programs.
-It turns on \fB\-ffast\-math\fR.
-.Sp
-If you use multiple \fB\-O\fR options, with or without level numbers,
-the last such option is the one that is effective.
-.PP
-Options of the form \fB\-f\fR\fIflag\fR specify machine-independent
-flags. Most flags have both positive and negative forms; the negative
-form of \fB\-ffoo\fR would be \fB\-fno\-foo\fR. In the table
-below, only one of the forms is listed\-\-\-the one you typically will
-use. You can figure out the other form by either removing \fBno\-\fR
-or adding it.
-.PP
-The following options control specific optimizations. They are either
-activated by \fB\-O\fR options or are related to ones that are. You
-can use the following flags in the rare cases when \*(L"fine-tuning\*(R" of
-optimizations to be performed is desired.
-.IP "\fB\-fno\-default\-inline\fR" 4
-.IX Item "-fno-default-inline"
-Do not make member functions inline by default merely because they are
-defined inside the class scope (\*(C+ only). Otherwise, when you specify
-\&\fB\-O\fR, member functions defined inside class scope are compiled
-inline by default; i.e., you don't need to add \fBinline\fR in front of
-the member function name.
-.IP "\fB\-fno\-defer\-pop\fR" 4
-.IX Item "-fno-defer-pop"
-Always pop the arguments to each function call as soon as that function
-returns. For machines which must pop arguments after a function call,
-the compiler normally lets arguments accumulate on the stack for several
-function calls and pops them all at once.
-.Sp
-Disabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fforward\-propagate\fR" 4
-.IX Item "-fforward-propagate"
-Perform a forward propagation pass on \s-1RTL\s0. The pass tries to combine two
-instructions and checks if the result can be simplified. If loop unrolling
-is active, two passes are performed and the second is scheduled after
-loop unrolling.
-.Sp
-This option is enabled by default at optimization levels \fB\-O\fR,
-\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-ffp\-contract=\fR\fIstyle\fR" 4
-.IX Item "-ffp-contract=style"
-\&\fB\-ffp\-contract=off\fR disables floating-point expression contraction.
-\&\fB\-ffp\-contract=fast\fR enables floating-point expression contraction
-such as forming of fused multiply-add operations if the target has
-native support for them.
-\&\fB\-ffp\-contract=on\fR enables floating-point expression contraction
-if allowed by the language standard. This is currently not implemented
-and treated equal to \fB\-ffp\-contract=off\fR.
-.Sp
-The default is \fB\-ffp\-contract=fast\fR.
-.IP "\fB\-fomit\-frame\-pointer\fR" 4
-.IX Item "-fomit-frame-pointer"
-Don't keep the frame pointer in a register for functions that
-don't need one. This avoids the instructions to save, set up and
-restore frame pointers; it also makes an extra register available
-in many functions. \fBIt also makes debugging impossible on
-some machines.\fR
-.Sp
-On some machines, such as the \s-1VAX\s0, this flag has no effect, because
-the standard calling sequence automatically handles the frame pointer
-and nothing is saved by pretending it doesn't exist. The
-machine-description macro \f(CW\*(C`FRAME_POINTER_REQUIRED\*(C'\fR controls
-whether a target machine supports this flag.
-.Sp
-Starting with \s-1GCC\s0 version 4.6, the default setting (when not optimizing for
-size) for 32\-bit Linux x86 and 32\-bit Darwin x86 targets has been changed to
-\&\fB\-fomit\-frame\-pointer\fR. The default can be reverted to
-\&\fB\-fno\-omit\-frame\-pointer\fR by configuring \s-1GCC\s0 with the
-\&\fB\-\-enable\-frame\-pointer\fR configure option.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-foptimize\-sibling\-calls\fR" 4
-.IX Item "-foptimize-sibling-calls"
-Optimize sibling and tail recursive calls.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fno\-inline\fR" 4
-.IX Item "-fno-inline"
-Don't pay attention to the \f(CW\*(C`inline\*(C'\fR keyword. Normally this option
-is used to keep the compiler from expanding any functions inline.
-Note that if you are not optimizing, no functions can be expanded inline.
-.IP "\fB\-finline\-small\-functions\fR" 4
-.IX Item "-finline-small-functions"
-Integrate functions into their callers when their body is smaller than expected
-function call code (so overall size of program gets smaller). The compiler
-heuristically decides which functions are simple enough to be worth integrating
-in this way.
-.Sp
-Enabled at level \fB\-O2\fR.
-.IP "\fB\-findirect\-inlining\fR" 4
-.IX Item "-findirect-inlining"
-Inline also indirect calls that are discovered to be known at compile
-time thanks to previous inlining. This option has any effect only
-when inlining itself is turned on by the \fB\-finline\-functions\fR
-or \fB\-finline\-small\-functions\fR options.
-.Sp
-Enabled at level \fB\-O2\fR.
-.IP "\fB\-finline\-functions\fR" 4
-.IX Item "-finline-functions"
-Integrate all simple functions into their callers. The compiler
-heuristically decides which functions are simple enough to be worth
-integrating in this way.
-.Sp
-If all calls to a given function are integrated, and the function is
-declared \f(CW\*(C`static\*(C'\fR, then the function is normally not output as
-assembler code in its own right.
-.Sp
-Enabled at level \fB\-O3\fR.
-.IP "\fB\-finline\-functions\-called\-once\fR" 4
-.IX Item "-finline-functions-called-once"
-Consider all \f(CW\*(C`static\*(C'\fR functions called once for inlining into their
-caller even if they are not marked \f(CW\*(C`inline\*(C'\fR. If a call to a given
-function is integrated, then the function is not output as assembler code
-in its own right.
-.Sp
-Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
-.IP "\fB\-fearly\-inlining\fR" 4
-.IX Item "-fearly-inlining"
-Inline functions marked by \f(CW\*(C`always_inline\*(C'\fR and functions whose body seems
-smaller than the function call overhead early before doing
-\&\fB\-fprofile\-generate\fR instrumentation and real inlining pass. Doing so
-makes profiling significantly cheaper and usually inlining faster on programs
-having large chains of nested wrapper functions.
-.Sp
-Enabled by default.
-.IP "\fB\-fipa\-sra\fR" 4
-.IX Item "-fipa-sra"
-Perform interprocedural scalar replacement of aggregates, removal of
-unused parameters and replacement of parameters passed by reference
-by parameters passed by value.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
-.IP "\fB\-finline\-limit=\fR\fIn\fR" 4
-.IX Item "-finline-limit=n"
-By default, \s-1GCC\s0 limits the size of functions that can be inlined. This flag
-allows coarse control of this limit. \fIn\fR is the size of functions that
-can be inlined in number of pseudo instructions.
-.Sp
-Inlining is actually controlled by a number of parameters, which may be
-specified individually by using \fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR.
-The \fB\-finline\-limit=\fR\fIn\fR option sets some of these parameters
-as follows:
-.RS 4
-.IP "\fBmax-inline-insns-single\fR" 4
-.IX Item "max-inline-insns-single"
-is set to \fIn\fR/2.
-.IP "\fBmax-inline-insns-auto\fR" 4
-.IX Item "max-inline-insns-auto"
-is set to \fIn\fR/2.
-.RE
-.RS 4
-.Sp
-See below for a documentation of the individual
-parameters controlling inlining and for the defaults of these parameters.
-.Sp
-\&\fINote:\fR there may be no value to \fB\-finline\-limit\fR that results
-in default behavior.
-.Sp
-\&\fINote:\fR pseudo instruction represents, in this particular context, an
-abstract measurement of function's size. In no way does it represent a count
-of assembly instructions and as such its exact meaning might change from one
-release to an another.
-.RE
-.IP "\fB\-fno\-keep\-inline\-dllexport\fR" 4
-.IX Item "-fno-keep-inline-dllexport"
-This is a more fine-grained version of \fB\-fkeep\-inline\-functions\fR,
-which applies only to functions that are declared using the \f(CW\*(C`dllexport\*(C'\fR
-attribute or declspec
-.IP "\fB\-fkeep\-inline\-functions\fR" 4
-.IX Item "-fkeep-inline-functions"
-In C, emit \f(CW\*(C`static\*(C'\fR functions that are declared \f(CW\*(C`inline\*(C'\fR
-into the object file, even if the function has been inlined into all
-of its callers. This switch does not affect functions using the
-\&\f(CW\*(C`extern inline\*(C'\fR extension in \s-1GNU\s0 C90. In \*(C+, emit any and all
-inline functions into the object file.
-.IP "\fB\-fkeep\-static\-consts\fR" 4
-.IX Item "-fkeep-static-consts"
-Emit variables declared \f(CW\*(C`static const\*(C'\fR when optimization isn't turned
-on, even if the variables aren't referenced.
-.Sp
-\&\s-1GCC\s0 enables this option by default. If you want to force the compiler to
-check if the variable was referenced, regardless of whether or not
-optimization is turned on, use the \fB\-fno\-keep\-static\-consts\fR option.
-.IP "\fB\-fmerge\-constants\fR" 4
-.IX Item "-fmerge-constants"
-Attempt to merge identical constants (string constants and floating point
-constants) across compilation units.
-.Sp
-This option is the default for optimized compilation if the assembler and
-linker support it. Use \fB\-fno\-merge\-constants\fR to inhibit this
-behavior.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fmerge\-all\-constants\fR" 4
-.IX Item "-fmerge-all-constants"
-Attempt to merge identical constants and identical variables.
-.Sp
-This option implies \fB\-fmerge\-constants\fR. In addition to
-\&\fB\-fmerge\-constants\fR this considers e.g. even constant initialized
-arrays or initialized constant variables with integral or floating point
-types. Languages like C or \*(C+ require each variable, including multiple
-instances of the same variable in recursive calls, to have distinct locations,
-so using this option will result in non-conforming
-behavior.
-.IP "\fB\-fmodulo\-sched\fR" 4
-.IX Item "-fmodulo-sched"
-Perform swing modulo scheduling immediately before the first scheduling
-pass. This pass looks at innermost loops and reorders their
-instructions by overlapping different iterations.
-.IP "\fB\-fmodulo\-sched\-allow\-regmoves\fR" 4
-.IX Item "-fmodulo-sched-allow-regmoves"
-Perform more aggressive \s-1SMS\s0 based modulo scheduling with register moves
-allowed. By setting this flag certain anti-dependences edges will be
-deleted which will trigger the generation of reg-moves based on the
-life-range analysis. This option is effective only with
-\&\fB\-fmodulo\-sched\fR enabled.
-.IP "\fB\-fno\-branch\-count\-reg\fR" 4
-.IX Item "-fno-branch-count-reg"
-Do not use \*(L"decrement and branch\*(R" instructions on a count register,
-but instead generate a sequence of instructions that decrement a
-register, compare it against zero, then branch based upon the result.
-This option is only meaningful on architectures that support such
-instructions, which include x86, PowerPC, \s-1IA\-64\s0 and S/390.
-.Sp
-The default is \fB\-fbranch\-count\-reg\fR.
-.IP "\fB\-fno\-function\-cse\fR" 4
-.IX Item "-fno-function-cse"
-Do not put function addresses in registers; make each instruction that
-calls a constant function contain the function's address explicitly.
-.Sp
-This option results in less efficient code, but some strange hacks
-that alter the assembler output may be confused by the optimizations
-performed when this option is not used.
-.Sp
-The default is \fB\-ffunction\-cse\fR
-.IP "\fB\-fno\-zero\-initialized\-in\-bss\fR" 4
-.IX Item "-fno-zero-initialized-in-bss"
-If the target supports a \s-1BSS\s0 section, \s-1GCC\s0 by default puts variables that
-are initialized to zero into \s-1BSS\s0. This can save space in the resulting
-code.
-.Sp
-This option turns off this behavior because some programs explicitly
-rely on variables going to the data section. E.g., so that the
-resulting executable can find the beginning of that section and/or make
-assumptions based on that.
-.Sp
-The default is \fB\-fzero\-initialized\-in\-bss\fR.
-.IP "\fB\-fmudflap \-fmudflapth \-fmudflapir\fR" 4
-.IX Item "-fmudflap -fmudflapth -fmudflapir"
-For front-ends that support it (C and \*(C+), instrument all risky
-pointer/array dereferencing operations, some standard library
-string/heap functions, and some other associated constructs with
-range/validity tests. Modules so instrumented should be immune to
-buffer overflows, invalid heap use, and some other classes of C/\*(C+
-programming errors. The instrumentation relies on a separate runtime
-library (\fIlibmudflap\fR), which will be linked into a program if
-\&\fB\-fmudflap\fR is given at link time. Run-time behavior of the
-instrumented program is controlled by the \fB\s-1MUDFLAP_OPTIONS\s0\fR
-environment variable. See \f(CW\*(C`env MUDFLAP_OPTIONS=\-help a.out\*(C'\fR
-for its options.
-.Sp
-Use \fB\-fmudflapth\fR instead of \fB\-fmudflap\fR to compile and to
-link if your program is multi-threaded. Use \fB\-fmudflapir\fR, in
-addition to \fB\-fmudflap\fR or \fB\-fmudflapth\fR, if
-instrumentation should ignore pointer reads. This produces less
-instrumentation (and therefore faster execution) and still provides
-some protection against outright memory corrupting writes, but allows
-erroneously read data to propagate within a program.
-.IP "\fB\-fthread\-jumps\fR" 4
-.IX Item "-fthread-jumps"
-Perform optimizations where we check to see if a jump branches to a
-location where another comparison subsumed by the first is found. If
-so, the first branch is redirected to either the destination of the
-second branch or a point immediately following it, depending on whether
-the condition is known to be true or false.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fsplit\-wide\-types\fR" 4
-.IX Item "-fsplit-wide-types"
-When using a type that occupies multiple registers, such as \f(CW\*(C`long
-long\*(C'\fR on a 32\-bit system, split the registers apart and allocate them
-independently. This normally generates better code for those types,
-but may make debugging more difficult.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR,
-\&\fB\-Os\fR.
-.IP "\fB\-fcse\-follow\-jumps\fR" 4
-.IX Item "-fcse-follow-jumps"
-In common subexpression elimination (\s-1CSE\s0), scan through jump instructions
-when the target of the jump is not reached by any other path. For
-example, when \s-1CSE\s0 encounters an \f(CW\*(C`if\*(C'\fR statement with an
-\&\f(CW\*(C`else\*(C'\fR clause, \s-1CSE\s0 will follow the jump when the condition
-tested is false.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fcse\-skip\-blocks\fR" 4
-.IX Item "-fcse-skip-blocks"
-This is similar to \fB\-fcse\-follow\-jumps\fR, but causes \s-1CSE\s0 to
-follow jumps which conditionally skip over blocks. When \s-1CSE\s0
-encounters a simple \f(CW\*(C`if\*(C'\fR statement with no else clause,
-\&\fB\-fcse\-skip\-blocks\fR causes \s-1CSE\s0 to follow the jump around the
-body of the \f(CW\*(C`if\*(C'\fR.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-frerun\-cse\-after\-loop\fR" 4
-.IX Item "-frerun-cse-after-loop"
-Re-run common subexpression elimination after loop optimizations has been
-performed.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fgcse\fR" 4
-.IX Item "-fgcse"
-Perform a global common subexpression elimination pass.
-This pass also performs global constant and copy propagation.
-.Sp
-\&\fINote:\fR When compiling a program using computed gotos, a \s-1GCC\s0
-extension, you may get better runtime performance if you disable
-the global common subexpression elimination pass by adding
-\&\fB\-fno\-gcse\fR to the command line.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fgcse\-lm\fR" 4
-.IX Item "-fgcse-lm"
-When \fB\-fgcse\-lm\fR is enabled, global common subexpression elimination will
-attempt to move loads which are only killed by stores into themselves. This
-allows a loop containing a load/store sequence to be changed to a load outside
-the loop, and a copy/store within the loop.
-.Sp
-Enabled by default when gcse is enabled.
-.IP "\fB\-fgcse\-sm\fR" 4
-.IX Item "-fgcse-sm"
-When \fB\-fgcse\-sm\fR is enabled, a store motion pass is run after
-global common subexpression elimination. This pass will attempt to move
-stores out of loops. When used in conjunction with \fB\-fgcse\-lm\fR,
-loops containing a load/store sequence can be changed to a load before
-the loop and a store after the loop.
-.Sp
-Not enabled at any optimization level.
-.IP "\fB\-fgcse\-las\fR" 4
-.IX Item "-fgcse-las"
-When \fB\-fgcse\-las\fR is enabled, the global common subexpression
-elimination pass eliminates redundant loads that come after stores to the
-same memory location (both partial and full redundancies).
-.Sp
-Not enabled at any optimization level.
-.IP "\fB\-fgcse\-after\-reload\fR" 4
-.IX Item "-fgcse-after-reload"
-When \fB\-fgcse\-after\-reload\fR is enabled, a redundant load elimination
-pass is performed after reload. The purpose of this pass is to cleanup
-redundant spilling.
-.IP "\fB\-funsafe\-loop\-optimizations\fR" 4
-.IX Item "-funsafe-loop-optimizations"
-If given, the loop optimizer will assume that loop indices do not
-overflow, and that the loops with nontrivial exit condition are not
-infinite. This enables a wider range of loop optimizations even if
-the loop optimizer itself cannot prove that these assumptions are valid.
-Using \fB\-Wunsafe\-loop\-optimizations\fR, the compiler will warn you
-if it finds this kind of loop.
-.IP "\fB\-fcrossjumping\fR" 4
-.IX Item "-fcrossjumping"
-Perform cross-jumping transformation. This transformation unifies equivalent code and save code size. The
-resulting code may or may not perform better than without cross-jumping.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fauto\-inc\-dec\fR" 4
-.IX Item "-fauto-inc-dec"
-Combine increments or decrements of addresses with memory accesses.
-This pass is always skipped on architectures that do not have
-instructions to support this. Enabled by default at \fB\-O\fR and
-higher on architectures that support this.
-.IP "\fB\-fdce\fR" 4
-.IX Item "-fdce"
-Perform dead code elimination (\s-1DCE\s0) on \s-1RTL\s0.
-Enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-fdse\fR" 4
-.IX Item "-fdse"
-Perform dead store elimination (\s-1DSE\s0) on \s-1RTL\s0.
-Enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-fif\-conversion\fR" 4
-.IX Item "-fif-conversion"
-Attempt to transform conditional jumps into branch-less equivalents. This
-include use of conditional moves, min, max, set flags and abs instructions, and
-some tricks doable by standard arithmetics. The use of conditional execution
-on chips where it is available is controlled by \f(CW\*(C`if\-conversion2\*(C'\fR.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fif\-conversion2\fR" 4
-.IX Item "-fif-conversion2"
-Use conditional execution (where available) to transform conditional jumps into
-branch-less equivalents.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fdelete\-null\-pointer\-checks\fR" 4
-.IX Item "-fdelete-null-pointer-checks"
-Assume that programs cannot safely dereference null pointers, and that
-no code or data element resides there. This enables simple constant
-folding optimizations at all optimization levels. In addition, other
-optimization passes in \s-1GCC\s0 use this flag to control global dataflow
-analyses that eliminate useless checks for null pointers; these assume
-that if a pointer is checked after it has already been dereferenced,
-it cannot be null.
-.Sp
-Note however that in some environments this assumption is not true.
-Use \fB\-fno\-delete\-null\-pointer\-checks\fR to disable this optimization
-for programs which depend on that behavior.
-.Sp
-Some targets, especially embedded ones, disable this option at all levels.
-Otherwise it is enabled at all levels: \fB\-O0\fR, \fB\-O1\fR,
-\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR. Passes that use the information
-are enabled independently at different optimization levels.
-.IP "\fB\-fdevirtualize\fR" 4
-.IX Item "-fdevirtualize"
-Attempt to convert calls to virtual functions to direct calls. This
-is done both within a procedure and interprocedurally as part of
-indirect inlining (\f(CW\*(C`\-findirect\-inlining\*(C'\fR) and interprocedural constant
-propagation (\fB\-fipa\-cp\fR).
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fexpensive\-optimizations\fR" 4
-.IX Item "-fexpensive-optimizations"
-Perform a number of minor optimizations that are relatively expensive.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-foptimize\-register\-move\fR" 4
-.IX Item "-foptimize-register-move"
-.PD 0
-.IP "\fB\-fregmove\fR" 4
-.IX Item "-fregmove"
-.PD
-Attempt to reassign register numbers in move instructions and as
-operands of other simple instructions in order to maximize the amount of
-register tying. This is especially helpful on machines with two-operand
-instructions.
-.Sp
-Note \fB\-fregmove\fR and \fB\-foptimize\-register\-move\fR are the same
-optimization.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fira\-algorithm=\fR\fIalgorithm\fR" 4
-.IX Item "-fira-algorithm=algorithm"
-Use specified coloring algorithm for the integrated register
-allocator. The \fIalgorithm\fR argument should be \f(CW\*(C`priority\*(C'\fR or
-\&\f(CW\*(C`CB\*(C'\fR. The first algorithm specifies Chow's priority coloring,
-the second one specifies Chaitin-Briggs coloring. The second
-algorithm can be unimplemented for some architectures. If it is
-implemented, it is the default because Chaitin-Briggs coloring as a
-rule generates a better code.
-.IP "\fB\-fira\-region=\fR\fIregion\fR" 4
-.IX Item "-fira-region=region"
-Use specified regions for the integrated register allocator. The
-\&\fIregion\fR argument should be one of \f(CW\*(C`all\*(C'\fR, \f(CW\*(C`mixed\*(C'\fR, or
-\&\f(CW\*(C`one\*(C'\fR. The first value means using all loops as register
-allocation regions, the second value which is the default means using
-all loops except for loops with small register pressure as the
-regions, and third one means using all function as a single region.
-The first value can give best result for machines with small size and
-irregular register set, the third one results in faster and generates
-decent code and the smallest size code, and the default value usually
-give the best results in most cases and for most architectures.
-.IP "\fB\-fira\-loop\-pressure\fR" 4
-.IX Item "-fira-loop-pressure"
-Use \s-1IRA\s0 to evaluate register pressure in loops for decision to move
-loop invariants. Usage of this option usually results in generation
-of faster and smaller code on machines with big register files (>= 32
-registers) but it can slow compiler down.
-.Sp
-This option is enabled at level \fB\-O3\fR for some targets.
-.IP "\fB\-fno\-ira\-share\-save\-slots\fR" 4
-.IX Item "-fno-ira-share-save-slots"
-Switch off sharing stack slots used for saving call used hard
-registers living through a call. Each hard register will get a
-separate stack slot and as a result function stack frame will be
-bigger.
-.IP "\fB\-fno\-ira\-share\-spill\-slots\fR" 4
-.IX Item "-fno-ira-share-spill-slots"
-Switch off sharing stack slots allocated for pseudo-registers. Each
-pseudo-register which did not get a hard register will get a separate
-stack slot and as a result function stack frame will be bigger.
-.IP "\fB\-fira\-verbose=\fR\fIn\fR" 4
-.IX Item "-fira-verbose=n"
-Set up how verbose dump file for the integrated register allocator
-will be. Default value is 5. If the value is greater or equal to 10,
-the dump file will be stderr as if the value were \fIn\fR minus 10.
-.IP "\fB\-fdelayed\-branch\fR" 4
-.IX Item "-fdelayed-branch"
-If supported for the target machine, attempt to reorder instructions
-to exploit instruction slots available after delayed branch
-instructions.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fschedule\-insns\fR" 4
-.IX Item "-fschedule-insns"
-If supported for the target machine, attempt to reorder instructions to
-eliminate execution stalls due to required data being unavailable. This
-helps machines that have slow floating point or memory load instructions
-by allowing other instructions to be issued until the result of the load
-or floating point instruction is required.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-fschedule\-insns2\fR" 4
-.IX Item "-fschedule-insns2"
-Similar to \fB\-fschedule\-insns\fR, but requests an additional pass of
-instruction scheduling after register allocation has been done. This is
-especially useful on machines with a relatively small number of
-registers and where memory load instructions take more than one cycle.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fno\-sched\-interblock\fR" 4
-.IX Item "-fno-sched-interblock"
-Don't schedule instructions across basic blocks. This is normally
-enabled by default when scheduling before register allocation, i.e.
-with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fno\-sched\-spec\fR" 4
-.IX Item "-fno-sched-spec"
-Don't allow speculative motion of non-load instructions. This is normally
-enabled by default when scheduling before register allocation, i.e.
-with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-pressure\fR" 4
-.IX Item "-fsched-pressure"
-Enable register pressure sensitive insn scheduling before the register
-allocation. This only makes sense when scheduling before register
-allocation is enabled, i.e. with \fB\-fschedule\-insns\fR or at
-\&\fB\-O2\fR or higher. Usage of this option can improve the
-generated code and decrease its size by preventing register pressure
-increase above the number of available hard registers and as a
-consequence register spills in the register allocation.
-.IP "\fB\-fsched\-spec\-load\fR" 4
-.IX Item "-fsched-spec-load"
-Allow speculative motion of some load instructions. This only makes
-sense when scheduling before register allocation, i.e. with
-\&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-spec\-load\-dangerous\fR" 4
-.IX Item "-fsched-spec-load-dangerous"
-Allow speculative motion of more load instructions. This only makes
-sense when scheduling before register allocation, i.e. with
-\&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-stalled\-insns\fR" 4
-.IX Item "-fsched-stalled-insns"
-.PD 0
-.IP "\fB\-fsched\-stalled\-insns=\fR\fIn\fR" 4
-.IX Item "-fsched-stalled-insns=n"
-.PD
-Define how many insns (if any) can be moved prematurely from the queue
-of stalled insns into the ready list, during the second scheduling pass.
-\&\fB\-fno\-sched\-stalled\-insns\fR means that no insns will be moved
-prematurely, \fB\-fsched\-stalled\-insns=0\fR means there is no limit
-on how many queued insns can be moved prematurely.
-\&\fB\-fsched\-stalled\-insns\fR without a value is equivalent to
-\&\fB\-fsched\-stalled\-insns=1\fR.
-.IP "\fB\-fsched\-stalled\-insns\-dep\fR" 4
-.IX Item "-fsched-stalled-insns-dep"
-.PD 0
-.IP "\fB\-fsched\-stalled\-insns\-dep=\fR\fIn\fR" 4
-.IX Item "-fsched-stalled-insns-dep=n"
-.PD
-Define how many insn groups (cycles) will be examined for a dependency
-on a stalled insn that is candidate for premature removal from the queue
-of stalled insns. This has an effect only during the second scheduling pass,
-and only if \fB\-fsched\-stalled\-insns\fR is used.
-\&\fB\-fno\-sched\-stalled\-insns\-dep\fR is equivalent to
-\&\fB\-fsched\-stalled\-insns\-dep=0\fR.
-\&\fB\-fsched\-stalled\-insns\-dep\fR without a value is equivalent to
-\&\fB\-fsched\-stalled\-insns\-dep=1\fR.
-.IP "\fB\-fsched2\-use\-superblocks\fR" 4
-.IX Item "-fsched2-use-superblocks"
-When scheduling after register allocation, do use superblock scheduling
-algorithm. Superblock scheduling allows motion across basic block boundaries
-resulting on faster schedules. This option is experimental, as not all machine
-descriptions used by \s-1GCC\s0 model the \s-1CPU\s0 closely enough to avoid unreliable
-results from the algorithm.
-.Sp
-This only makes sense when scheduling after register allocation, i.e. with
-\&\fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-group\-heuristic\fR" 4
-.IX Item "-fsched-group-heuristic"
-Enable the group heuristic in the scheduler. This heuristic favors
-the instruction that belongs to a schedule group. This is enabled
-by default when scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
-or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-critical\-path\-heuristic\fR" 4
-.IX Item "-fsched-critical-path-heuristic"
-Enable the critical-path heuristic in the scheduler. This heuristic favors
-instructions on the critical path. This is enabled by default when
-scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
-or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-spec\-insn\-heuristic\fR" 4
-.IX Item "-fsched-spec-insn-heuristic"
-Enable the speculative instruction heuristic in the scheduler. This
-heuristic favors speculative instructions with greater dependency weakness.
-This is enabled by default when scheduling is enabled, i.e.
-with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR
-or at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-rank\-heuristic\fR" 4
-.IX Item "-fsched-rank-heuristic"
-Enable the rank heuristic in the scheduler. This heuristic favors
-the instruction belonging to a basic block with greater size or frequency.
-This is enabled by default when scheduling is enabled, i.e.
-with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
-at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-last\-insn\-heuristic\fR" 4
-.IX Item "-fsched-last-insn-heuristic"
-Enable the last-instruction heuristic in the scheduler. This heuristic
-favors the instruction that is less dependent on the last instruction
-scheduled. This is enabled by default when scheduling is enabled,
-i.e. with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
-at \fB\-O2\fR or higher.
-.IP "\fB\-fsched\-dep\-count\-heuristic\fR" 4
-.IX Item "-fsched-dep-count-heuristic"
-Enable the dependent-count heuristic in the scheduler. This heuristic
-favors the instruction that has more instructions depending on it.
-This is enabled by default when scheduling is enabled, i.e.
-with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
-at \fB\-O2\fR or higher.
-.IP "\fB\-freschedule\-modulo\-scheduled\-loops\fR" 4
-.IX Item "-freschedule-modulo-scheduled-loops"
-The modulo scheduling comes before the traditional scheduling, if a loop
-was modulo scheduled we may want to prevent the later scheduling passes
-from changing its schedule, we use this option to control that.
-.IP "\fB\-fselective\-scheduling\fR" 4
-.IX Item "-fselective-scheduling"
-Schedule instructions using selective scheduling algorithm. Selective
-scheduling runs instead of the first scheduler pass.
-.IP "\fB\-fselective\-scheduling2\fR" 4
-.IX Item "-fselective-scheduling2"
-Schedule instructions using selective scheduling algorithm. Selective
-scheduling runs instead of the second scheduler pass.
-.IP "\fB\-fsel\-sched\-pipelining\fR" 4
-.IX Item "-fsel-sched-pipelining"
-Enable software pipelining of innermost loops during selective scheduling.
-This option has no effect until one of \fB\-fselective\-scheduling\fR or
-\&\fB\-fselective\-scheduling2\fR is turned on.
-.IP "\fB\-fsel\-sched\-pipelining\-outer\-loops\fR" 4
-.IX Item "-fsel-sched-pipelining-outer-loops"
-When pipelining loops during selective scheduling, also pipeline outer loops.
-This option has no effect until \fB\-fsel\-sched\-pipelining\fR is turned on.
-.IP "\fB\-fcaller\-saves\fR" 4
-.IX Item "-fcaller-saves"
-Enable values to be allocated in registers that will be clobbered by
-function calls, by emitting extra instructions to save and restore the
-registers around such calls. Such allocation is done only when it
-seems to result in better code than would otherwise be produced.
-.Sp
-This option is always enabled by default on certain machines, usually
-those which have no call-preserved registers to use instead.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fcombine\-stack\-adjustments\fR" 4
-.IX Item "-fcombine-stack-adjustments"
-Tracks stack adjustments (pushes and pops) and stack memory references
-and then tries to find ways to combine them.
-.Sp
-Enabled by default at \fB\-O1\fR and higher.
-.IP "\fB\-fconserve\-stack\fR" 4
-.IX Item "-fconserve-stack"
-Attempt to minimize stack usage. The compiler will attempt to use less
-stack space, even if that makes the program slower. This option
-implies setting the \fBlarge-stack-frame\fR parameter to 100
-and the \fBlarge-stack-frame-growth\fR parameter to 400.
-.IP "\fB\-ftree\-reassoc\fR" 4
-.IX Item "-ftree-reassoc"
-Perform reassociation on trees. This flag is enabled by default
-at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-pre\fR" 4
-.IX Item "-ftree-pre"
-Perform partial redundancy elimination (\s-1PRE\s0) on trees. This flag is
-enabled by default at \fB\-O2\fR and \fB\-O3\fR.
-.IP "\fB\-ftree\-forwprop\fR" 4
-.IX Item "-ftree-forwprop"
-Perform forward propagation on trees. This flag is enabled by default
-at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-fre\fR" 4
-.IX Item "-ftree-fre"
-Perform full redundancy elimination (\s-1FRE\s0) on trees. The difference
-between \s-1FRE\s0 and \s-1PRE\s0 is that \s-1FRE\s0 only considers expressions
-that are computed on all paths leading to the redundant computation.
-This analysis is faster than \s-1PRE\s0, though it exposes fewer redundancies.
-This flag is enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-phiprop\fR" 4
-.IX Item "-ftree-phiprop"
-Perform hoisting of loads from conditional pointers on trees. This
-pass is enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-copy\-prop\fR" 4
-.IX Item "-ftree-copy-prop"
-Perform copy propagation on trees. This pass eliminates unnecessary
-copy operations. This flag is enabled by default at \fB\-O\fR and
-higher.
-.IP "\fB\-fipa\-pure\-const\fR" 4
-.IX Item "-fipa-pure-const"
-Discover which functions are pure or constant.
-Enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-fipa\-reference\fR" 4
-.IX Item "-fipa-reference"
-Discover which static variables do not escape cannot escape the
-compilation unit.
-Enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-fipa\-struct\-reorg\fR" 4
-.IX Item "-fipa-struct-reorg"
-Perform structure reorganization optimization, that change C\-like structures
-layout in order to better utilize spatial locality. This transformation is
-affective for programs containing arrays of structures. Available in two
-compilation modes: profile-based (enabled with \fB\-fprofile\-generate\fR)
-or static (which uses built-in heuristics). It works only in whole program
-mode, so it requires \fB\-fwhole\-program\fR to be
-enabled. Structures considered \fBcold\fR by this transformation are not
-affected (see \fB\-\-param struct\-reorg\-cold\-struct\-ratio=\fR\fIvalue\fR).
-.Sp
-With this flag, the program debug info reflects a new structure layout.
-.IP "\fB\-fipa\-pta\fR" 4
-.IX Item "-fipa-pta"
-Perform interprocedural pointer analysis and interprocedural modification
-and reference analysis. This option can cause excessive memory and
-compile-time usage on large compilation units. It is not enabled by
-default at any optimization level.
-.IP "\fB\-fipa\-profile\fR" 4
-.IX Item "-fipa-profile"
-Perform interprocedural profile propagation. The functions called only from
-cold functions are marked as cold. Also functions executed once (such as
-\&\f(CW\*(C`cold\*(C'\fR, \f(CW\*(C`noreturn\*(C'\fR, static constructors or destructors) are identified. Cold
-functions and loop less parts of functions executed once are then optimized for
-size.
-Enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-fipa\-cp\fR" 4
-.IX Item "-fipa-cp"
-Perform interprocedural constant propagation.
-This optimization analyzes the program to determine when values passed
-to functions are constants and then optimizes accordingly.
-This optimization can substantially increase performance
-if the application has constants passed to functions.
-This flag is enabled by default at \fB\-O2\fR, \fB\-Os\fR and \fB\-O3\fR.
-.IP "\fB\-fipa\-cp\-clone\fR" 4
-.IX Item "-fipa-cp-clone"
-Perform function cloning to make interprocedural constant propagation stronger.
-When enabled, interprocedural constant propagation will perform function cloning
-when externally visible function can be called with constant arguments.
-Because this optimization can create multiple copies of functions,
-it may significantly increase code size
-(see \fB\-\-param ipcp\-unit\-growth=\fR\fIvalue\fR).
-This flag is enabled by default at \fB\-O3\fR.
-.IP "\fB\-fipa\-matrix\-reorg\fR" 4
-.IX Item "-fipa-matrix-reorg"
-Perform matrix flattening and transposing.
-Matrix flattening tries to replace an m\-dimensional matrix
-with its equivalent n\-dimensional matrix, where n < m.
-This reduces the level of indirection needed for accessing the elements
-of the matrix. The second optimization is matrix transposing that
-attempts to change the order of the matrix's dimensions in order to
-improve cache locality.
-Both optimizations need the \fB\-fwhole\-program\fR flag.
-Transposing is enabled only if profiling information is available.
-.IP "\fB\-ftree\-sink\fR" 4
-.IX Item "-ftree-sink"
-Perform forward store motion on trees. This flag is
-enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-bit\-ccp\fR" 4
-.IX Item "-ftree-bit-ccp"
-Perform sparse conditional bit constant propagation on trees and propagate
-pointer alignment information.
-This pass only operates on local scalar variables and is enabled by default
-at \fB\-O\fR and higher. It requires that \fB\-ftree\-ccp\fR is enabled.
-.IP "\fB\-ftree\-ccp\fR" 4
-.IX Item "-ftree-ccp"
-Perform sparse conditional constant propagation (\s-1CCP\s0) on trees. This
-pass only operates on local scalar variables and is enabled by default
-at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-switch\-conversion\fR" 4
-.IX Item "-ftree-switch-conversion"
-Perform conversion of simple initializations in a switch to
-initializations from a scalar array. This flag is enabled by default
-at \fB\-O2\fR and higher.
-.IP "\fB\-ftree\-dce\fR" 4
-.IX Item "-ftree-dce"
-Perform dead code elimination (\s-1DCE\s0) on trees. This flag is enabled by
-default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-builtin\-call\-dce\fR" 4
-.IX Item "-ftree-builtin-call-dce"
-Perform conditional dead code elimination (\s-1DCE\s0) for calls to builtin functions
-that may set \f(CW\*(C`errno\*(C'\fR but are otherwise side-effect free. This flag is
-enabled by default at \fB\-O2\fR and higher if \fB\-Os\fR is not also
-specified.
-.IP "\fB\-ftree\-dominator\-opts\fR" 4
-.IX Item "-ftree-dominator-opts"
-Perform a variety of simple scalar cleanups (constant/copy
-propagation, redundancy elimination, range propagation and expression
-simplification) based on a dominator tree traversal. This also
-performs jump threading (to reduce jumps to jumps). This flag is
-enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-dse\fR" 4
-.IX Item "-ftree-dse"
-Perform dead store elimination (\s-1DSE\s0) on trees. A dead store is a store into
-a memory location which will later be overwritten by another store without
-any intervening loads. In this case the earlier store can be deleted. This
-flag is enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-ch\fR" 4
-.IX Item "-ftree-ch"
-Perform loop header copying on trees. This is beneficial since it increases
-effectiveness of code motion optimizations. It also saves one jump. This flag
-is enabled by default at \fB\-O\fR and higher. It is not enabled
-for \fB\-Os\fR, since it usually increases code size.
-.IP "\fB\-ftree\-loop\-optimize\fR" 4
-.IX Item "-ftree-loop-optimize"
-Perform loop optimizations on trees. This flag is enabled by default
-at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-loop\-linear\fR" 4
-.IX Item "-ftree-loop-linear"
-Perform loop interchange transformations on tree. Same as
-\&\fB\-floop\-interchange\fR. To use this code transformation, \s-1GCC\s0 has
-to be configured with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to
-enable the Graphite loop transformation infrastructure.
-.IP "\fB\-floop\-interchange\fR" 4
-.IX Item "-floop-interchange"
-Perform loop interchange transformations on loops. Interchanging two
-nested loops switches the inner and outer loops. For example, given a
-loop like:
-.Sp
-.Vb 5
-\& DO J = 1, M
-\& DO I = 1, N
-\& A(J, I) = A(J, I) * C
-\& ENDDO
-\& ENDDO
-.Ve
-.Sp
-loop interchange will transform the loop as if the user had written:
-.Sp
-.Vb 5
-\& DO I = 1, N
-\& DO J = 1, M
-\& A(J, I) = A(J, I) * C
-\& ENDDO
-\& ENDDO
-.Ve
-.Sp
-which can be beneficial when \f(CW\*(C`N\*(C'\fR is larger than the caches,
-because in Fortran, the elements of an array are stored in memory
-contiguously by column, and the original loop iterates over rows,
-potentially creating at each access a cache miss. This optimization
-applies to all the languages supported by \s-1GCC\s0 and is not limited to
-Fortran. To use this code transformation, \s-1GCC\s0 has to be configured
-with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to enable the
-Graphite loop transformation infrastructure.
-.IP "\fB\-floop\-strip\-mine\fR" 4
-.IX Item "-floop-strip-mine"
-Perform loop strip mining transformations on loops. Strip mining
-splits a loop into two nested loops. The outer loop has strides
-equal to the strip size and the inner loop has strides of the
-original loop within a strip. The strip length can be changed
-using the \fBloop-block-tile-size\fR parameter. For example,
-given a loop like:
-.Sp
-.Vb 3
-\& DO I = 1, N
-\& A(I) = A(I) + C
-\& ENDDO
-.Ve
-.Sp
-loop strip mining will transform the loop as if the user had written:
-.Sp
-.Vb 5
-\& DO II = 1, N, 51
-\& DO I = II, min (II + 50, N)
-\& A(I) = A(I) + C
-\& ENDDO
-\& ENDDO
-.Ve
-.Sp
-This optimization applies to all the languages supported by \s-1GCC\s0 and is
-not limited to Fortran. To use this code transformation, \s-1GCC\s0 has to
-be configured with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to
-enable the Graphite loop transformation infrastructure.
-.IP "\fB\-floop\-block\fR" 4
-.IX Item "-floop-block"
-Perform loop blocking transformations on loops. Blocking strip mines
-each loop in the loop nest such that the memory accesses of the
-element loops fit inside caches. The strip length can be changed
-using the \fBloop-block-tile-size\fR parameter. For example, given
-a loop like:
-.Sp
-.Vb 5
-\& DO I = 1, N
-\& DO J = 1, M
-\& A(J, I) = B(I) + C(J)
-\& ENDDO
-\& ENDDO
-.Ve
-.Sp
-loop blocking will transform the loop as if the user had written:
-.Sp
-.Vb 9
-\& DO II = 1, N, 51
-\& DO JJ = 1, M, 51
-\& DO I = II, min (II + 50, N)
-\& DO J = JJ, min (JJ + 50, M)
-\& A(J, I) = B(I) + C(J)
-\& ENDDO
-\& ENDDO
-\& ENDDO
-\& ENDDO
-.Ve
-.Sp
-which can be beneficial when \f(CW\*(C`M\*(C'\fR is larger than the caches,
-because the innermost loop will iterate over a smaller amount of data
-that can be kept in the caches. This optimization applies to all the
-languages supported by \s-1GCC\s0 and is not limited to Fortran. To use this
-code transformation, \s-1GCC\s0 has to be configured with \fB\-\-with\-ppl\fR
-and \fB\-\-with\-cloog\fR to enable the Graphite loop transformation
-infrastructure.
-.IP "\fB\-fgraphite\-identity\fR" 4
-.IX Item "-fgraphite-identity"
-Enable the identity transformation for graphite. For every SCoP we generate
-the polyhedral representation and transform it back to gimple. Using
-\&\fB\-fgraphite\-identity\fR we can check the costs or benefits of the
-\&\s-1GIMPLE\s0 \-> \s-1GRAPHITE\s0 \-> \s-1GIMPLE\s0 transformation. Some minimal optimizations
-are also performed by the code generator CLooG, like index splitting and
-dead code elimination in loops.
-.IP "\fB\-floop\-flatten\fR" 4
-.IX Item "-floop-flatten"
-Removes the loop nesting structure: transforms the loop nest into a
-single loop. This transformation can be useful to vectorize all the
-levels of the loop nest.
-.IP "\fB\-floop\-parallelize\-all\fR" 4
-.IX Item "-floop-parallelize-all"
-Use the Graphite data dependence analysis to identify loops that can
-be parallelized. Parallelize all the loops that can be analyzed to
-not contain loop carried dependences without checking that it is
-profitable to parallelize the loops.
-.IP "\fB\-fcheck\-data\-deps\fR" 4
-.IX Item "-fcheck-data-deps"
-Compare the results of several data dependence analyzers. This option
-is used for debugging the data dependence analyzers.
-.IP "\fB\-ftree\-loop\-if\-convert\fR" 4
-.IX Item "-ftree-loop-if-convert"
-Attempt to transform conditional jumps in the innermost loops to
-branch-less equivalents. The intent is to remove control-flow from
-the innermost loops in order to improve the ability of the
-vectorization pass to handle these loops. This is enabled by default
-if vectorization is enabled.
-.IP "\fB\-ftree\-loop\-if\-convert\-stores\fR" 4
-.IX Item "-ftree-loop-if-convert-stores"
-Attempt to also if-convert conditional jumps containing memory writes.
-This transformation can be unsafe for multi-threaded programs as it
-transforms conditional memory writes into unconditional memory writes.
-For example,
-.Sp
-.Vb 3
-\& for (i = 0; i < N; i++)
-\& if (cond)
-\& A[i] = expr;
-.Ve
-.Sp
-would be transformed to
-.Sp
-.Vb 2
-\& for (i = 0; i < N; i++)
-\& A[i] = cond ? expr : A[i];
-.Ve
-.Sp
-potentially producing data races.
-.IP "\fB\-ftree\-loop\-distribution\fR" 4
-.IX Item "-ftree-loop-distribution"
-Perform loop distribution. This flag can improve cache performance on
-big loop bodies and allow further loop optimizations, like
-parallelization or vectorization, to take place. For example, the loop
-.Sp
-.Vb 4
-\& DO I = 1, N
-\& A(I) = B(I) + C
-\& D(I) = E(I) * F
-\& ENDDO
-.Ve
-.Sp
-is transformed to
-.Sp
-.Vb 6
-\& DO I = 1, N
-\& A(I) = B(I) + C
-\& ENDDO
-\& DO I = 1, N
-\& D(I) = E(I) * F
-\& ENDDO
-.Ve
-.IP "\fB\-ftree\-loop\-distribute\-patterns\fR" 4
-.IX Item "-ftree-loop-distribute-patterns"
-Perform loop distribution of patterns that can be code generated with
-calls to a library. This flag is enabled by default at \fB\-O3\fR.
-.Sp
-This pass distributes the initialization loops and generates a call to
-memset zero. For example, the loop
-.Sp
-.Vb 4
-\& DO I = 1, N
-\& A(I) = 0
-\& B(I) = A(I) + I
-\& ENDDO
-.Ve
-.Sp
-is transformed to
-.Sp
-.Vb 6
-\& DO I = 1, N
-\& A(I) = 0
-\& ENDDO
-\& DO I = 1, N
-\& B(I) = A(I) + I
-\& ENDDO
-.Ve
-.Sp
-and the initialization loop is transformed into a call to memset zero.
-.IP "\fB\-ftree\-loop\-im\fR" 4
-.IX Item "-ftree-loop-im"
-Perform loop invariant motion on trees. This pass moves only invariants that
-would be hard to handle at \s-1RTL\s0 level (function calls, operations that expand to
-nontrivial sequences of insns). With \fB\-funswitch\-loops\fR it also moves
-operands of conditions that are invariant out of the loop, so that we can use
-just trivial invariantness analysis in loop unswitching. The pass also includes
-store motion.
-.IP "\fB\-ftree\-loop\-ivcanon\fR" 4
-.IX Item "-ftree-loop-ivcanon"
-Create a canonical counter for number of iterations in the loop for that
-determining number of iterations requires complicated analysis. Later
-optimizations then may determine the number easily. Useful especially
-in connection with unrolling.
-.IP "\fB\-fivopts\fR" 4
-.IX Item "-fivopts"
-Perform induction variable optimizations (strength reduction, induction
-variable merging and induction variable elimination) on trees.
-.IP "\fB\-ftree\-parallelize\-loops=n\fR" 4
-.IX Item "-ftree-parallelize-loops=n"
-Parallelize loops, i.e., split their iteration space to run in n threads.
-This is only possible for loops whose iterations are independent
-and can be arbitrarily reordered. The optimization is only
-profitable on multiprocessor machines, for loops that are CPU-intensive,
-rather than constrained e.g. by memory bandwidth. This option
-implies \fB\-pthread\fR, and thus is only supported on targets
-that have support for \fB\-pthread\fR.
-.IP "\fB\-ftree\-pta\fR" 4
-.IX Item "-ftree-pta"
-Perform function-local points-to analysis on trees. This flag is
-enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-sra\fR" 4
-.IX Item "-ftree-sra"
-Perform scalar replacement of aggregates. This pass replaces structure
-references with scalars to prevent committing structures to memory too
-early. This flag is enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-copyrename\fR" 4
-.IX Item "-ftree-copyrename"
-Perform copy renaming on trees. This pass attempts to rename compiler
-temporaries to other variables at copy locations, usually resulting in
-variable names which more closely resemble the original variables. This flag
-is enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-ter\fR" 4
-.IX Item "-ftree-ter"
-Perform temporary expression replacement during the \s-1SSA\-\s0>normal phase. Single
-use/single def temporaries are replaced at their use location with their
-defining expression. This results in non-GIMPLE code, but gives the expanders
-much more complex trees to work on resulting in better \s-1RTL\s0 generation. This is
-enabled by default at \fB\-O\fR and higher.
-.IP "\fB\-ftree\-vectorize\fR" 4
-.IX Item "-ftree-vectorize"
-Perform loop vectorization on trees. This flag is enabled by default at
-\&\fB\-O3\fR.
-.IP "\fB\-ftree\-slp\-vectorize\fR" 4
-.IX Item "-ftree-slp-vectorize"
-Perform basic block vectorization on trees. This flag is enabled by default at
-\&\fB\-O3\fR and when \fB\-ftree\-vectorize\fR is enabled.
-.IP "\fB\-ftree\-vect\-loop\-version\fR" 4
-.IX Item "-ftree-vect-loop-version"
-Perform loop versioning when doing loop vectorization on trees. When a loop
-appears to be vectorizable except that data alignment or data dependence cannot
-be determined at compile time then vectorized and non-vectorized versions of
-the loop are generated along with runtime checks for alignment or dependence
-to control which version is executed. This option is enabled by default
-except at level \fB\-Os\fR where it is disabled.
-.IP "\fB\-fvect\-cost\-model\fR" 4
-.IX Item "-fvect-cost-model"
-Enable cost model for vectorization.
-.IP "\fB\-ftree\-vrp\fR" 4
-.IX Item "-ftree-vrp"
-Perform Value Range Propagation on trees. This is similar to the
-constant propagation pass, but instead of values, ranges of values are
-propagated. This allows the optimizers to remove unnecessary range
-checks like array bound checks and null pointer checks. This is
-enabled by default at \fB\-O2\fR and higher. Null pointer check
-elimination is only done if \fB\-fdelete\-null\-pointer\-checks\fR is
-enabled.
-.IP "\fB\-ftracer\fR" 4
-.IX Item "-ftracer"
-Perform tail duplication to enlarge superblock size. This transformation
-simplifies the control flow of the function allowing other optimizations to do
-better job.
-.IP "\fB\-funroll\-loops\fR" 4
-.IX Item "-funroll-loops"
-Unroll loops whose number of iterations can be determined at compile
-time or upon entry to the loop. \fB\-funroll\-loops\fR implies
-\&\fB\-frerun\-cse\-after\-loop\fR. This option makes code larger,
-and may or may not make it run faster.
-.IP "\fB\-funroll\-all\-loops\fR" 4
-.IX Item "-funroll-all-loops"
-Unroll all loops, even if their number of iterations is uncertain when
-the loop is entered. This usually makes programs run more slowly.
-\&\fB\-funroll\-all\-loops\fR implies the same options as
-\&\fB\-funroll\-loops\fR,
-.IP "\fB\-fsplit\-ivs\-in\-unroller\fR" 4
-.IX Item "-fsplit-ivs-in-unroller"
-Enables expressing of values of induction variables in later iterations
-of the unrolled loop using the value in the first iteration. This breaks
-long dependency chains, thus improving efficiency of the scheduling passes.
-.Sp
-Combination of \fB\-fweb\fR and \s-1CSE\s0 is often sufficient to obtain the
-same effect. However in cases the loop body is more complicated than
-a single basic block, this is not reliable. It also does not work at all
-on some of the architectures due to restrictions in the \s-1CSE\s0 pass.
-.Sp
-This optimization is enabled by default.
-.IP "\fB\-fvariable\-expansion\-in\-unroller\fR" 4
-.IX Item "-fvariable-expansion-in-unroller"
-With this option, the compiler will create multiple copies of some
-local variables when unrolling a loop which can result in superior code.
-.IP "\fB\-fpartial\-inlining\fR" 4
-.IX Item "-fpartial-inlining"
-Inline parts of functions. This option has any effect only
-when inlining itself is turned on by the \fB\-finline\-functions\fR
-or \fB\-finline\-small\-functions\fR options.
-.Sp
-Enabled at level \fB\-O2\fR.
-.IP "\fB\-fpredictive\-commoning\fR" 4
-.IX Item "-fpredictive-commoning"
-Perform predictive commoning optimization, i.e., reusing computations
-(especially memory loads and stores) performed in previous
-iterations of loops.
-.Sp
-This option is enabled at level \fB\-O3\fR.
-.IP "\fB\-fprefetch\-loop\-arrays\fR" 4
-.IX Item "-fprefetch-loop-arrays"
-If supported by the target machine, generate instructions to prefetch
-memory to improve the performance of loops that access large arrays.
-.Sp
-This option may generate better or worse code; results are highly
-dependent on the structure of loops within the source code.
-.Sp
-Disabled at level \fB\-Os\fR.
-.IP "\fB\-fno\-peephole\fR" 4
-.IX Item "-fno-peephole"
-.PD 0
-.IP "\fB\-fno\-peephole2\fR" 4
-.IX Item "-fno-peephole2"
-.PD
-Disable any machine-specific peephole optimizations. The difference
-between \fB\-fno\-peephole\fR and \fB\-fno\-peephole2\fR is in how they
-are implemented in the compiler; some targets use one, some use the
-other, a few use both.
-.Sp
-\&\fB\-fpeephole\fR is enabled by default.
-\&\fB\-fpeephole2\fR enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fno\-guess\-branch\-probability\fR" 4
-.IX Item "-fno-guess-branch-probability"
-Do not guess branch probabilities using heuristics.
-.Sp
-\&\s-1GCC\s0 will use heuristics to guess branch probabilities if they are
-not provided by profiling feedback (\fB\-fprofile\-arcs\fR). These
-heuristics are based on the control flow graph. If some branch probabilities
-are specified by \fB_\|_builtin_expect\fR, then the heuristics will be
-used to guess branch probabilities for the rest of the control flow graph,
-taking the \fB_\|_builtin_expect\fR info into account. The interactions
-between the heuristics and \fB_\|_builtin_expect\fR can be complex, and in
-some cases, it may be useful to disable the heuristics so that the effects
-of \fB_\|_builtin_expect\fR are easier to understand.
-.Sp
-The default is \fB\-fguess\-branch\-probability\fR at levels
-\&\fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-freorder\-blocks\fR" 4
-.IX Item "-freorder-blocks"
-Reorder basic blocks in the compiled function in order to reduce number of
-taken branches and improve code locality.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-freorder\-blocks\-and\-partition\fR" 4
-.IX Item "-freorder-blocks-and-partition"
-In addition to reordering basic blocks in the compiled function, in order
-to reduce number of taken branches, partitions hot and cold basic blocks
-into separate sections of the assembly and .o files, to improve
-paging and cache locality performance.
-.Sp
-This optimization is automatically turned off in the presence of
-exception handling, for linkonce sections, for functions with a user-defined
-section attribute and on any architecture that does not support named
-sections.
-.IP "\fB\-freorder\-functions\fR" 4
-.IX Item "-freorder-functions"
-Reorder functions in the object file in order to
-improve code locality. This is implemented by using special
-subsections \f(CW\*(C`.text.hot\*(C'\fR for most frequently executed functions and
-\&\f(CW\*(C`.text.unlikely\*(C'\fR for unlikely executed functions. Reordering is done by
-the linker so object file format must support named sections and linker must
-place them in a reasonable way.
-.Sp
-Also profile feedback must be available in to make this option effective. See
-\&\fB\-fprofile\-arcs\fR for details.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fstrict\-aliasing\fR" 4
-.IX Item "-fstrict-aliasing"
-Allow the compiler to assume the strictest aliasing rules applicable to
-the language being compiled. For C (and \*(C+), this activates
-optimizations based on the type of expressions. In particular, an
-object of one type is assumed never to reside at the same address as an
-object of a different type, unless the types are almost the same. For
-example, an \f(CW\*(C`unsigned int\*(C'\fR can alias an \f(CW\*(C`int\*(C'\fR, but not a
-\&\f(CW\*(C`void*\*(C'\fR or a \f(CW\*(C`double\*(C'\fR. A character type may alias any other
-type.
-.Sp
-Pay special attention to code like this:
-.Sp
-.Vb 4
-\& union a_union {
-\& int i;
-\& double d;
-\& };
-\&
-\& int f() {
-\& union a_union t;
-\& t.d = 3.0;
-\& return t.i;
-\& }
-.Ve
-.Sp
-The practice of reading from a different union member than the one most
-recently written to (called \*(L"type-punning\*(R") is common. Even with
-\&\fB\-fstrict\-aliasing\fR, type-punning is allowed, provided the memory
-is accessed through the union type. So, the code above will work as
-expected. However, this code might not:
-.Sp
-.Vb 7
-\& int f() {
-\& union a_union t;
-\& int* ip;
-\& t.d = 3.0;
-\& ip = &t.i;
-\& return *ip;
-\& }
-.Ve
-.Sp
-Similarly, access by taking the address, casting the resulting pointer
-and dereferencing the result has undefined behavior, even if the cast
-uses a union type, e.g.:
-.Sp
-.Vb 4
-\& int f() {
-\& double d = 3.0;
-\& return ((union a_union *) &d)\->i;
-\& }
-.Ve
-.Sp
-The \fB\-fstrict\-aliasing\fR option is enabled at levels
-\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fstrict\-overflow\fR" 4
-.IX Item "-fstrict-overflow"
-Allow the compiler to assume strict signed overflow rules, depending
-on the language being compiled. For C (and \*(C+) this means that
-overflow when doing arithmetic with signed numbers is undefined, which
-means that the compiler may assume that it will not happen. This
-permits various optimizations. For example, the compiler will assume
-that an expression like \f(CW\*(C`i + 10 > i\*(C'\fR will always be true for
-signed \f(CW\*(C`i\*(C'\fR. This assumption is only valid if signed overflow is
-undefined, as the expression is false if \f(CW\*(C`i + 10\*(C'\fR overflows when
-using twos complement arithmetic. When this option is in effect any
-attempt to determine whether an operation on signed numbers will
-overflow must be written carefully to not actually involve overflow.
-.Sp
-This option also allows the compiler to assume strict pointer
-semantics: given a pointer to an object, if adding an offset to that
-pointer does not produce a pointer to the same object, the addition is
-undefined. This permits the compiler to conclude that \f(CW\*(C`p + u >
-p\*(C'\fR is always true for a pointer \f(CW\*(C`p\*(C'\fR and unsigned integer
-\&\f(CW\*(C`u\*(C'\fR. This assumption is only valid because pointer wraparound is
-undefined, as the expression is false if \f(CW\*(C`p + u\*(C'\fR overflows using
-twos complement arithmetic.
-.Sp
-See also the \fB\-fwrapv\fR option. Using \fB\-fwrapv\fR means
-that integer signed overflow is fully defined: it wraps. When
-\&\fB\-fwrapv\fR is used, there is no difference between
-\&\fB\-fstrict\-overflow\fR and \fB\-fno\-strict\-overflow\fR for
-integers. With \fB\-fwrapv\fR certain types of overflow are
-permitted. For example, if the compiler gets an overflow when doing
-arithmetic on constants, the overflowed value can still be used with
-\&\fB\-fwrapv\fR, but not otherwise.
-.Sp
-The \fB\-fstrict\-overflow\fR option is enabled at levels
-\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-falign\-functions\fR" 4
-.IX Item "-falign-functions"
-.PD 0
-.IP "\fB\-falign\-functions=\fR\fIn\fR" 4
-.IX Item "-falign-functions=n"
-.PD
-Align the start of functions to the next power-of-two greater than
-\&\fIn\fR, skipping up to \fIn\fR bytes. For instance,
-\&\fB\-falign\-functions=32\fR aligns functions to the next 32\-byte
-boundary, but \fB\-falign\-functions=24\fR would align to the next
-32\-byte boundary only if this can be done by skipping 23 bytes or less.
-.Sp
-\&\fB\-fno\-align\-functions\fR and \fB\-falign\-functions=1\fR are
-equivalent and mean that functions will not be aligned.
-.Sp
-Some assemblers only support this flag when \fIn\fR is a power of two;
-in that case, it is rounded up.
-.Sp
-If \fIn\fR is not specified or is zero, use a machine-dependent default.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-falign\-labels\fR" 4
-.IX Item "-falign-labels"
-.PD 0
-.IP "\fB\-falign\-labels=\fR\fIn\fR" 4
-.IX Item "-falign-labels=n"
-.PD
-Align all branch targets to a power-of-two boundary, skipping up to
-\&\fIn\fR bytes like \fB\-falign\-functions\fR. This option can easily
-make code slower, because it must insert dummy operations for when the
-branch target is reached in the usual flow of the code.
-.Sp
-\&\fB\-fno\-align\-labels\fR and \fB\-falign\-labels=1\fR are
-equivalent and mean that labels will not be aligned.
-.Sp
-If \fB\-falign\-loops\fR or \fB\-falign\-jumps\fR are applicable and
-are greater than this value, then their values are used instead.
-.Sp
-If \fIn\fR is not specified or is zero, use a machine-dependent default
-which is very likely to be \fB1\fR, meaning no alignment.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-falign\-loops\fR" 4
-.IX Item "-falign-loops"
-.PD 0
-.IP "\fB\-falign\-loops=\fR\fIn\fR" 4
-.IX Item "-falign-loops=n"
-.PD
-Align loops to a power-of-two boundary, skipping up to \fIn\fR bytes
-like \fB\-falign\-functions\fR. The hope is that the loop will be
-executed many times, which will make up for any execution of the dummy
-operations.
-.Sp
-\&\fB\-fno\-align\-loops\fR and \fB\-falign\-loops=1\fR are
-equivalent and mean that loops will not be aligned.
-.Sp
-If \fIn\fR is not specified or is zero, use a machine-dependent default.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-falign\-jumps\fR" 4
-.IX Item "-falign-jumps"
-.PD 0
-.IP "\fB\-falign\-jumps=\fR\fIn\fR" 4
-.IX Item "-falign-jumps=n"
-.PD
-Align branch targets to a power-of-two boundary, for branch targets
-where the targets can only be reached by jumping, skipping up to \fIn\fR
-bytes like \fB\-falign\-functions\fR. In this case, no dummy operations
-need be executed.
-.Sp
-\&\fB\-fno\-align\-jumps\fR and \fB\-falign\-jumps=1\fR are
-equivalent and mean that loops will not be aligned.
-.Sp
-If \fIn\fR is not specified or is zero, use a machine-dependent default.
-.Sp
-Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
-.IP "\fB\-funit\-at\-a\-time\fR" 4
-.IX Item "-funit-at-a-time"
-This option is left for compatibility reasons. \fB\-funit\-at\-a\-time\fR
-has no effect, while \fB\-fno\-unit\-at\-a\-time\fR implies
-\&\fB\-fno\-toplevel\-reorder\fR and \fB\-fno\-section\-anchors\fR.
-.Sp
-Enabled by default.
-.IP "\fB\-fno\-toplevel\-reorder\fR" 4
-.IX Item "-fno-toplevel-reorder"
-Do not reorder top-level functions, variables, and \f(CW\*(C`asm\*(C'\fR
-statements. Output them in the same order that they appear in the
-input file. When this option is used, unreferenced static variables
-will not be removed. This option is intended to support existing code
-which relies on a particular ordering. For new code, it is better to
-use attributes.
-.Sp
-Enabled at level \fB\-O0\fR. When disabled explicitly, it also imply
-\&\fB\-fno\-section\-anchors\fR that is otherwise enabled at \fB\-O0\fR on some
-targets.
-.IP "\fB\-fweb\fR" 4
-.IX Item "-fweb"
-Constructs webs as commonly used for register allocation purposes and assign
-each web individual pseudo register. This allows the register allocation pass
-to operate on pseudos directly, but also strengthens several other optimization
-passes, such as \s-1CSE\s0, loop optimizer and trivial dead code remover. It can,
-however, make debugging impossible, since variables will no longer stay in a
-\&\*(L"home register\*(R".
-.Sp
-Enabled by default with \fB\-funroll\-loops\fR.
-.IP "\fB\-fwhole\-program\fR" 4
-.IX Item "-fwhole-program"
-Assume that the current compilation unit represents the whole program being
-compiled. All public functions and variables with the exception of \f(CW\*(C`main\*(C'\fR
-and those merged by attribute \f(CW\*(C`externally_visible\*(C'\fR become static functions
-and in effect are optimized more aggressively by interprocedural optimizers. If \fBgold\fR is used as the linker plugin, \f(CW\*(C`externally_visible\*(C'\fR attributes are automatically added to functions (not variable yet due to a current \fBgold\fR issue) that are accessed outside of \s-1LTO\s0 objects according to resolution file produced by \fBgold\fR. For other linkers that cannot generate resolution file, explicit \f(CW\*(C`externally_visible\*(C'\fR attributes are still necessary.
-While this option is equivalent to proper use of the \f(CW\*(C`static\*(C'\fR keyword for
-programs consisting of a single file, in combination with option
-\&\fB\-flto\fR this flag can be used to
-compile many smaller scale programs since the functions and variables become
-local for the whole combined compilation unit, not for the single source file
-itself.
-.Sp
-This option implies \fB\-fwhole\-file\fR for Fortran programs.
-.IP "\fB\-flto[=\fR\fIn\fR\fB]\fR" 4
-.IX Item "-flto[=n]"
-This option runs the standard link-time optimizer. When invoked
-with source code, it generates \s-1GIMPLE\s0 (one of \s-1GCC\s0's internal
-representations) and writes it to special \s-1ELF\s0 sections in the object
-file. When the object files are linked together, all the function
-bodies are read from these \s-1ELF\s0 sections and instantiated as if they
-had been part of the same translation unit.
-.Sp
-To use the link-time optimizer, \fB\-flto\fR needs to be specified at
-compile time and during the final link. For example:
-.Sp
-.Vb 3
-\& gcc \-c \-O2 \-flto foo.c
-\& gcc \-c \-O2 \-flto bar.c
-\& gcc \-o myprog \-flto \-O2 foo.o bar.o
-.Ve
-.Sp
-The first two invocations to \s-1GCC\s0 save a bytecode representation
-of \s-1GIMPLE\s0 into special \s-1ELF\s0 sections inside \fIfoo.o\fR and
-\&\fIbar.o\fR. The final invocation reads the \s-1GIMPLE\s0 bytecode from
-\&\fIfoo.o\fR and \fIbar.o\fR, merges the two files into a single
-internal image, and compiles the result as usual. Since both
-\&\fIfoo.o\fR and \fIbar.o\fR are merged into a single image, this
-causes all the interprocedural analyses and optimizations in \s-1GCC\s0 to
-work across the two files as if they were a single one. This means,
-for example, that the inliner is able to inline functions in
-\&\fIbar.o\fR into functions in \fIfoo.o\fR and vice-versa.
-.Sp
-Another (simpler) way to enable link-time optimization is:
-.Sp
-.Vb 1
-\& gcc \-o myprog \-flto \-O2 foo.c bar.c
-.Ve
-.Sp
-The above generates bytecode for \fIfoo.c\fR and \fIbar.c\fR,
-merges them together into a single \s-1GIMPLE\s0 representation and optimizes
-them as usual to produce \fImyprog\fR.
-.Sp
-The only important thing to keep in mind is that to enable link-time
-optimizations the \fB\-flto\fR flag needs to be passed to both the
-compile and the link commands.
-.Sp
-To make whole program optimization effective, it is necessary to make
-certain whole program assumptions. The compiler needs to know
-what functions and variables can be accessed by libraries and runtime
-outside of the link-time optimized unit. When supported by the linker,
-the linker plugin (see \fB\-fuse\-linker\-plugin\fR) passes information
-to the compiler about used and externally visible symbols. When
-the linker plugin is not available, \fB\-fwhole\-program\fR should be
-used to allow the compiler to make these assumptions, which leads
-to more aggressive optimization decisions.
-.Sp
-Note that when a file is compiled with \fB\-flto\fR, the generated
-object file is larger than a regular object file because it
-contains \s-1GIMPLE\s0 bytecodes and the usual final code. This means that
-object files with \s-1LTO\s0 information can be linked as normal object
-files; if \fB\-flto\fR is not passed to the linker, no
-interprocedural optimizations are applied.
-.Sp
-Additionally, the optimization flags used to compile individual files
-are not necessarily related to those used at link time. For instance,
-.Sp
-.Vb 3
-\& gcc \-c \-O0 \-flto foo.c
-\& gcc \-c \-O0 \-flto bar.c
-\& gcc \-o myprog \-flto \-O3 foo.o bar.o
-.Ve
-.Sp
-This produces individual object files with unoptimized assembler
-code, but the resulting binary \fImyprog\fR is optimized at
-\&\fB\-O3\fR. If, instead, the final binary is generated without
-\&\fB\-flto\fR, then \fImyprog\fR is not optimized.
-.Sp
-When producing the final binary with \fB\-flto\fR, \s-1GCC\s0 only
-applies link-time optimizations to those files that contain bytecode.
-Therefore, you can mix and match object files and libraries with
-\&\s-1GIMPLE\s0 bytecodes and final object code. \s-1GCC\s0 automatically selects
-which files to optimize in \s-1LTO\s0 mode and which files to link without
-further processing.
-.Sp
-There are some code generation flags that \s-1GCC\s0 preserves when
-generating bytecodes, as they need to be used during the final link
-stage. Currently, the following options are saved into the \s-1GIMPLE\s0
-bytecode files: \fB\-fPIC\fR, \fB\-fcommon\fR and all the
-\&\fB\-m\fR target flags.
-.Sp
-At link time, these options are read in and reapplied. Note that the
-current implementation makes no attempt to recognize conflicting
-values for these options. If different files have conflicting option
-values (e.g., one file is compiled with \fB\-fPIC\fR and another
-isn't), the compiler simply uses the last value read from the
-bytecode files. It is recommended, then, that you compile all the files
-participating in the same link with the same options.
-.Sp
-If \s-1LTO\s0 encounters objects with C linkage declared with incompatible
-types in separate translation units to be linked together (undefined
-behavior according to \s-1ISO\s0 C99 6.2.7), a non-fatal diagnostic may be
-issued. The behavior is still undefined at runtime.
-.Sp
-Another feature of \s-1LTO\s0 is that it is possible to apply interprocedural
-optimizations on files written in different languages. This requires
-support in the language front end. Currently, the C, \*(C+ and
-Fortran front ends are capable of emitting \s-1GIMPLE\s0 bytecodes, so
-something like this should work:
-.Sp
-.Vb 4
-\& gcc \-c \-flto foo.c
-\& g++ \-c \-flto bar.cc
-\& gfortran \-c \-flto baz.f90
-\& g++ \-o myprog \-flto \-O3 foo.o bar.o baz.o \-lgfortran
-.Ve
-.Sp
-Notice that the final link is done with \fBg++\fR to get the \*(C+
-runtime libraries and \fB\-lgfortran\fR is added to get the Fortran
-runtime libraries. In general, when mixing languages in \s-1LTO\s0 mode, you
-should use the same link command options as when mixing languages in a
-regular (non-LTO) compilation; all you need to add is \fB\-flto\fR to
-all the compile and link commands.
-.Sp
-If object files containing \s-1GIMPLE\s0 bytecode are stored in a library archive, say
-\&\fIlibfoo.a\fR, it is possible to extract and use them in an \s-1LTO\s0 link if you
-are using a linker with plugin support. To enable this feature, use
-the flag \fB\-fuse\-linker\-plugin\fR at link time:
-.Sp
-.Vb 1
-\& gcc \-o myprog \-O2 \-flto \-fuse\-linker\-plugin a.o b.o \-lfoo
-.Ve
-.Sp
-With the linker plugin enabled, the linker extracts the needed
-\&\s-1GIMPLE\s0 files from \fIlibfoo.a\fR and passes them on to the running \s-1GCC\s0
-to make them part of the aggregated \s-1GIMPLE\s0 image to be optimized.
-.Sp
-If you are not using a linker with plugin support and/or do not
-enable the linker plugin, then the objects inside \fIlibfoo.a\fR
-are extracted and linked as usual, but they do not participate
-in the \s-1LTO\s0 optimization process.
-.Sp
-Link-time optimizations do not require the presence of the whole program to
-operate. If the program does not require any symbols to be exported, it is
-possible to combine \fB\-flto\fR and \fB\-fwhole\-program\fR to allow
-the interprocedural optimizers to use more aggressive assumptions which may
-lead to improved optimization opportunities.
-Use of \fB\-fwhole\-program\fR is not needed when linker plugin is
-active (see \fB\-fuse\-linker\-plugin\fR).
-.Sp
-The current implementation of \s-1LTO\s0 makes no
-attempt to generate bytecode that is portable between different
-types of hosts. The bytecode files are versioned and there is a
-strict version check, so bytecode files generated in one version of
-\&\s-1GCC\s0 will not work with an older/newer version of \s-1GCC\s0.
-.Sp
-Link-time optimization does not work well with generation of debugging
-information. Combining \fB\-flto\fR with
-\&\fB\-g\fR is currently experimental and expected to produce wrong
-results.
-.Sp
-If you specify the optional \fIn\fR, the optimization and code
-generation done at link time is executed in parallel using \fIn\fR
-parallel jobs by utilizing an installed \fBmake\fR program. The
-environment variable \fB\s-1MAKE\s0\fR may be used to override the program
-used. The default value for \fIn\fR is 1.
-.Sp
-You can also specify \fB\-flto=jobserver\fR to use \s-1GNU\s0 make's
-job server mode to determine the number of parallel jobs. This
-is useful when the Makefile calling \s-1GCC\s0 is already executing in parallel.
-You must prepend a \fB+\fR to the command recipe in the parent Makefile
-for this to work. This option likely only works if \fB\s-1MAKE\s0\fR is
-\&\s-1GNU\s0 make.
-.Sp
-This option is disabled by default.
-.IP "\fB\-flto\-partition=\fR\fIalg\fR" 4
-.IX Item "-flto-partition=alg"
-Specify the partitioning algorithm used by the link-time optimizer.
-The value is either \f(CW\*(C`1to1\*(C'\fR to specify a partitioning mirroring
-the original source files or \f(CW\*(C`balanced\*(C'\fR to specify partitioning
-into equally sized chunks (whenever possible). Specifying \f(CW\*(C`none\*(C'\fR
-as an algorithm disables partitioning and streaming completely. The
-default value is \f(CW\*(C`balanced\*(C'\fR.
-.IP "\fB\-flto\-compression\-level=\fR\fIn\fR" 4
-.IX Item "-flto-compression-level=n"
-This option specifies the level of compression used for intermediate
-language written to \s-1LTO\s0 object files, and is only meaningful in
-conjunction with \s-1LTO\s0 mode (\fB\-flto\fR). Valid
-values are 0 (no compression) to 9 (maximum compression). Values
-outside this range are clamped to either 0 or 9. If the option is not
-given, a default balanced compression setting is used.
-.IP "\fB\-flto\-report\fR" 4
-.IX Item "-flto-report"
-Prints a report with internal details on the workings of the link-time
-optimizer. The contents of this report vary from version to version.
-It is meant to be useful to \s-1GCC\s0 developers when processing object
-files in \s-1LTO\s0 mode (via \fB\-flto\fR).
-.Sp
-Disabled by default.
-.IP "\fB\-fuse\-linker\-plugin\fR" 4
-.IX Item "-fuse-linker-plugin"
-Enables the use of a linker plugin during link-time optimization. This
-option relies on the linker plugin support in linker that is available in gold
-or in \s-1GNU\s0 ld 2.21 or newer.
-.Sp
-This option enables the extraction of object files with \s-1GIMPLE\s0 bytecode out
-of library archives. This improves the quality of optimization by exposing
-more code to the link-time optimizer. This information specifies what
-symbols can be accessed externally (by non-LTO object or during dynamic
-linking). Resulting code quality improvements on binaries (and shared
-libraries that use hidden visibility) are similar to \f(CW\*(C`\-fwhole\-program\*(C'\fR.
-See \fB\-flto\fR for a description of the effect of this flag and how to
-use it.
-.Sp
-This option is enabled by default when \s-1LTO\s0 support in \s-1GCC\s0 is enabled
-and \s-1GCC\s0 was configured for use with
-a linker supporting plugins (\s-1GNU\s0 ld 2.21 or newer or gold).
-.IP "\fB\-fcompare\-elim\fR" 4
-.IX Item "-fcompare-elim"
-After register allocation and post-register allocation instruction splitting,
-identify arithmetic instructions that compute processor flags similar to a
-comparison operation based on that arithmetic. If possible, eliminate the
-explicit comparison operation.
-.Sp
-This pass only applies to certain targets that cannot explicitly represent
-the comparison operation before register allocation is complete.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fuse\-ld=gold\fR" 4
-.IX Item "-fuse-ld=gold"
-Use the \fBgold\fR linker instead of the default linker.
-This option is only necessary if \s-1GCC\s0 has been configured with
-\&\fB\-\-enable\-gold\fR and \fB\-\-enable\-ld=default\fR.
-.IP "\fB\-fuse\-ld=bfd\fR" 4
-.IX Item "-fuse-ld=bfd"
-Use the \fBld.bfd\fR linker instead of the default linker.
-This option is only necessary if \s-1GCC\s0 has been configured with
-\&\fB\-\-enable\-gold\fR and \fB\-\-enable\-ld\fR.
-.IP "\fB\-fcprop\-registers\fR" 4
-.IX Item "-fcprop-registers"
-After register allocation and post-register allocation instruction splitting,
-we perform a copy-propagation pass to try to reduce scheduling dependencies
-and occasionally eliminate the copy.
-.Sp
-Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
-.IP "\fB\-fprofile\-correction\fR" 4
-.IX Item "-fprofile-correction"
-Profiles collected using an instrumented binary for multi-threaded programs may
-be inconsistent due to missed counter updates. When this option is specified,
-\&\s-1GCC\s0 will use heuristics to correct or smooth out such inconsistencies. By
-default, \s-1GCC\s0 will emit an error message when an inconsistent profile is detected.
-.IP "\fB\-fprofile\-dir=\fR\fIpath\fR" 4
-.IX Item "-fprofile-dir=path"
-Set the directory to search for the profile data files in to \fIpath\fR.
-This option affects only the profile data generated by
-\&\fB\-fprofile\-generate\fR, \fB\-ftest\-coverage\fR, \fB\-fprofile\-arcs\fR
-and used by \fB\-fprofile\-use\fR and \fB\-fbranch\-probabilities\fR
-and its related options. Both absolute and relative paths can be used.
-By default, \s-1GCC\s0 will use the current directory as \fIpath\fR, thus the
-profile data file will appear in the same directory as the object file.
-.IP "\fB\-fprofile\-generate\fR" 4
-.IX Item "-fprofile-generate"
-.PD 0
-.IP "\fB\-fprofile\-generate=\fR\fIpath\fR" 4
-.IX Item "-fprofile-generate=path"
-.PD
-Enable options usually used for instrumenting application to produce
-profile useful for later recompilation with profile feedback based
-optimization. You must use \fB\-fprofile\-generate\fR both when
-compiling and when linking your program.
-.Sp
-The following options are enabled: \f(CW\*(C`\-fprofile\-arcs\*(C'\fR, \f(CW\*(C`\-fprofile\-values\*(C'\fR, \f(CW\*(C`\-fvpt\*(C'\fR.
-.Sp
-If \fIpath\fR is specified, \s-1GCC\s0 will look at the \fIpath\fR to find
-the profile feedback data files. See \fB\-fprofile\-dir\fR.
-.IP "\fB\-fprofile\-generate\-sampling\fR" 4
-.IX Item "-fprofile-generate-sampling"
-Enable sampling for instrumented binaries. Instead of recording every event,
-record only every N\-th event, where N (the sampling rate) can be set either
-at compile time using
-\&\fB\-\-param profile\-generate\-sampling\-rate=\fR\fIvalue\fR, or
-at execution start time through environment variable \fB\s-1GCOV_SAMPLING_RATE\s0\fR.
-.Sp
-At this time sampling applies only to branch counters. A sampling rate of 100
-decreases instrumentated binary slowdown from up to 20x for heavily threaded
-applications down to around 2x. \fB\-fprofile\-correction\fR is always
-needed with sampling.
-.IP "\fB\-fprofile\-use\fR" 4
-.IX Item "-fprofile-use"
-.PD 0
-.IP "\fB\-fprofile\-use=\fR\fIpath\fR" 4
-.IX Item "-fprofile-use=path"
-.PD
-Enable profile feedback directed optimizations, and optimizations
-generally profitable only with profile feedback available.
-.Sp
-The following options are enabled: \f(CW\*(C`\-fbranch\-probabilities\*(C'\fR, \f(CW\*(C`\-fvpt\*(C'\fR,
-\&\f(CW\*(C`\-funroll\-loops\*(C'\fR, \f(CW\*(C`\-fpeel\-loops\*(C'\fR.
-.Sp
-By default, \s-1GCC\s0 emits an error message if the feedback profiles do not
-match the source code. This error can be turned into a warning by using
-\&\fB\-Wcoverage\-mismatch\fR. Note this may result in poorly optimized
-code.
-.Sp
-If \fIpath\fR is specified, \s-1GCC\s0 will look at the \fIpath\fR to find
-the profile feedback data files. See \fB\-fprofile\-dir\fR.
-.IP "\fB\-fpmu\-profile\-generate=\fR\fIpmuoption\fR" 4
-.IX Item "-fpmu-profile-generate=pmuoption"
-Enable performance monitoring unit (\s-1PMU\s0) profiling. This collects
-hardware counter data corresponding to \fIpmuoption\fR. Currently
-only \fIload-latency\fR and \fIbranch-mispredict\fR are supported
-using pfmon tool. You must use \fB\-fpmu\-profile\-generate\fR both
-when compiling and when linking your program. This \s-1PMU\s0 profile data
-may later be used by the compiler during optimizations as well can be
-displayed using coverage tool gcov. The params variable
-\&\*(L"pmu_profile_n_addresses\*(R" can be used to restrict \s-1PMU\s0 data collection
-to only this many addresses.
-.IP "\fB\-fpmu\-profile\-use=\fR\fIpmuoption\fR" 4
-.IX Item "-fpmu-profile-use=pmuoption"
-Enable performance monitoring unit (\s-1PMU\s0) profiling based
-optimizations. Currently only \fIload-latency\fR and
-\&\fIbranch-mispredict\fR are supported.
-.IP "\fB\-fripa\fR" 4
-.IX Item "-fripa"
-Perform dynamic inter-procedural analysis. This is used in conjunction with
-the \fB\-fprofile\-generate\fR and \fB\-fprofile\-use\fR options.
-During the \fB\-fprofile\-generate\fR phase, this flag turns on some additional
-instrumentation code that enables dynamic call-graph analysis.
-During the \fB\-fprofile\-use\fR phase, this flag enables cross-module
-optimizations such as inlining.
-.IP "\fB\-fripa\-disallow\-asm\-modules\fR" 4
-.IX Item "-fripa-disallow-asm-modules"
-During profile-gen, if this flag is enabled, and the module has asm statements,
-arrange so that a bit recording this information will be set in the profile
-feedback data file.
-During profile-use, if this flag is enabled, and the same bit in auxiliary
-module's profile feedback data is set, don't import this auxiliary module.
-If this is the primary module, don't export it.
-.IP "\fB\-fripa\-disallow\-opt\-mismatch\fR" 4
-.IX Item "-fripa-disallow-opt-mismatch"
-Don't import an auxiliary module, if the \s-1GCC\s0 command line options used for this
-auxiliary module during the profile-generate stage were different from those used
-for the primary module. Note that any mismatches in warning-related options are
-ignored for this comparison.
-.IP "\fB\-fripa\-no\-promote\-always\-inline\-func\fR" 4
-.IX Item "-fripa-no-promote-always-inline-func"
-Do not promote static functions with always inline attribute in \s-1LIPO\s0 compilation.
-.IP "\fB\-fripa\-verbose\fR" 4
-.IX Item "-fripa-verbose"
-Enable printing of verbose information about dynamic inter-procedural optimizations.
-This is used in conjunction with the \fB\-fripa\fR.
-.IP "\fB\-fripa\-peel\-size\-limit\fR" 4
-.IX Item "-fripa-peel-size-limit"
-Limit loop peeling of non-const non-FP loops in a \s-1LIPO\s0 compilation under estimates
-of a large code footprint. Enabled by default under \fB\-fripa\fR. Code size
-estimation and thresholds are controlled by the \fBcodesize-hotness-threshold\fR
-and \fBunrollpeel-codesize-threshold\fR parameters.
-.IP "\fB\-fripa\-unroll\-size\-limit\fR" 4
-.IX Item "-fripa-unroll-size-limit"
-Limit loop unrolling of non-const non-FP loops in a \s-1LIPO\s0 compilation under estimates
-of a large code footprint. Enabled by default under \fB\-fripa\fR. Code size
-estimation and thresholds are controlled by the \fBcodesize-hotness-threshold\fR
-and \fBunrollpeel-codesize-threshold\fR parameters.
-.IP "\fB\-fcallgraph\-profiles\-sections\fR" 4
-.IX Item "-fcallgraph-profiles-sections"
-Emit call graph edge profile counts in .note.callgraph.text sections. This is
-used in conjunction with \fB\-fprofile\-use\fR. A new .note.callgraph.text
-section is created for each function. This section lists every callee and the
-number of times it is called. The params variable
-\&\*(L"note-cgraph-section-edge-threshold\*(R" can be used to only list edges above a
-certain threshold.
-.IP "\fB\-frecord\-gcc\-switches\-in\-elf\fR" 4
-.IX Item "-frecord-gcc-switches-in-elf"
-Record the command line options in the .gnu.switches.text elf section for sample
-based \s-1LIPO\s0 to do module grouping.
-.PP
-The following options control compiler behavior regarding floating
-point arithmetic. These options trade off between speed and
-correctness. All must be specifically enabled.
-.IP "\fB\-ffloat\-store\fR" 4
-.IX Item "-ffloat-store"
-Do not store floating point variables in registers, and inhibit other
-options that might change whether a floating point value is taken from a
-register or memory.
-.Sp
-This option prevents undesirable excess precision on machines such as
-the 68000 where the floating registers (of the 68881) keep more
-precision than a \f(CW\*(C`double\*(C'\fR is supposed to have. Similarly for the
-x86 architecture. For most programs, the excess precision does only
-good, but a few programs rely on the precise definition of \s-1IEEE\s0 floating
-point. Use \fB\-ffloat\-store\fR for such programs, after modifying
-them to store all pertinent intermediate computations into variables.
-.IP "\fB\-fexcess\-precision=\fR\fIstyle\fR" 4
-.IX Item "-fexcess-precision=style"
-This option allows further control over excess precision on machines
-where floating-point registers have more precision than the \s-1IEEE\s0
-\&\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR types and the processor does not
-support operations rounding to those types. By default,
-\&\fB\-fexcess\-precision=fast\fR is in effect; this means that
-operations are carried out in the precision of the registers and that
-it is unpredictable when rounding to the types specified in the source
-code takes place. When compiling C, if
-\&\fB\-fexcess\-precision=standard\fR is specified then excess
-precision will follow the rules specified in \s-1ISO\s0 C99; in particular,
-both casts and assignments cause values to be rounded to their
-semantic types (whereas \fB\-ffloat\-store\fR only affects
-assignments). This option is enabled by default for C if a strict
-conformance option such as \fB\-std=c99\fR is used.
-.Sp
-\&\fB\-fexcess\-precision=standard\fR is not implemented for languages
-other than C, and has no effect if
-\&\fB\-funsafe\-math\-optimizations\fR or \fB\-ffast\-math\fR is
-specified. On the x86, it also has no effect if \fB\-mfpmath=sse\fR
-or \fB\-mfpmath=sse+387\fR is specified; in the former case, \s-1IEEE\s0
-semantics apply without excess precision, and in the latter, rounding
-is unpredictable.
-.IP "\fB\-ffast\-math\fR" 4
-.IX Item "-ffast-math"
-Sets \fB\-fno\-math\-errno\fR, \fB\-funsafe\-math\-optimizations\fR,
-\&\fB\-ffinite\-math\-only\fR, \fB\-fno\-rounding\-math\fR,
-\&\fB\-fno\-signaling\-nans\fR and \fB\-fcx\-limited\-range\fR.
-.Sp
-This option causes the preprocessor macro \f(CW\*(C`_\|_FAST_MATH_\|_\*(C'\fR to be defined.
-.Sp
-This option is not turned on by any \fB\-O\fR option besides
-\&\fB\-Ofast\fR since it can result in incorrect output for programs
-which depend on an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications
-for math functions. It may, however, yield faster code for programs
-that do not require the guarantees of these specifications.
-.IP "\fB\-fno\-math\-errno\fR" 4
-.IX Item "-fno-math-errno"
-Do not set \s-1ERRNO\s0 after calling math functions that are executed
-with a single instruction, e.g., sqrt. A program that relies on
-\&\s-1IEEE\s0 exceptions for math error handling may want to use this flag
-for speed while maintaining \s-1IEEE\s0 arithmetic compatibility.
-.Sp
-This option is not turned on by any \fB\-O\fR option since
-it can result in incorrect output for programs which depend on
-an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
-math functions. It may, however, yield faster code for programs
-that do not require the guarantees of these specifications.
-.Sp
-The default is \fB\-fmath\-errno\fR.
-.Sp
-On Darwin systems, the math library never sets \f(CW\*(C`errno\*(C'\fR. There is
-therefore no reason for the compiler to consider the possibility that
-it might, and \fB\-fno\-math\-errno\fR is the default.
-.IP "\fB\-funsafe\-math\-optimizations\fR" 4
-.IX Item "-funsafe-math-optimizations"
-Allow optimizations for floating-point arithmetic that (a) assume
-that arguments and results are valid and (b) may violate \s-1IEEE\s0 or
-\&\s-1ANSI\s0 standards. When used at link-time, it may include libraries
-or startup files that change the default \s-1FPU\s0 control word or other
-similar optimizations.
-.Sp
-This option is not turned on by any \fB\-O\fR option since
-it can result in incorrect output for programs which depend on
-an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
-math functions. It may, however, yield faster code for programs
-that do not require the guarantees of these specifications.
-Enables \fB\-fno\-signed\-zeros\fR, \fB\-fno\-trapping\-math\fR,
-\&\fB\-fassociative\-math\fR and \fB\-freciprocal\-math\fR.
-.Sp
-The default is \fB\-fno\-unsafe\-math\-optimizations\fR.
-.IP "\fB\-fassociative\-math\fR" 4
-.IX Item "-fassociative-math"
-Allow re-association of operands in series of floating-point operations.
-This violates the \s-1ISO\s0 C and \*(C+ language standard by possibly changing
-computation result. \s-1NOTE:\s0 re-ordering may change the sign of zero as
-well as ignore NaNs and inhibit or create underflow or overflow (and
-thus cannot be used on a code which relies on rounding behavior like
-\&\f(CW\*(C`(x + 2**52) \- 2**52)\*(C'\fR. May also reorder floating-point comparisons
-and thus may not be used when ordered comparisons are required.
-This option requires that both \fB\-fno\-signed\-zeros\fR and
-\&\fB\-fno\-trapping\-math\fR be in effect. Moreover, it doesn't make
-much sense with \fB\-frounding\-math\fR. For Fortran the option
-is automatically enabled when both \fB\-fno\-signed\-zeros\fR and
-\&\fB\-fno\-trapping\-math\fR are in effect.
-.Sp
-The default is \fB\-fno\-associative\-math\fR.
-.IP "\fB\-freciprocal\-math\fR" 4
-.IX Item "-freciprocal-math"
-Allow the reciprocal of a value to be used instead of dividing by
-the value if this enables optimizations. For example \f(CW\*(C`x / y\*(C'\fR
-can be replaced with \f(CW\*(C`x * (1/y)\*(C'\fR which is useful if \f(CW\*(C`(1/y)\*(C'\fR
-is subject to common subexpression elimination. Note that this loses
-precision and increases the number of flops operating on the value.
-.Sp
-The default is \fB\-fno\-reciprocal\-math\fR.
-.IP "\fB\-ffinite\-math\-only\fR" 4
-.IX Item "-ffinite-math-only"
-Allow optimizations for floating-point arithmetic that assume
-that arguments and results are not NaNs or +\-Infs.
-.Sp
-This option is not turned on by any \fB\-O\fR option since
-it can result in incorrect output for programs which depend on
-an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
-math functions. It may, however, yield faster code for programs
-that do not require the guarantees of these specifications.
-.Sp
-The default is \fB\-fno\-finite\-math\-only\fR.
-.IP "\fB\-fno\-signed\-zeros\fR" 4
-.IX Item "-fno-signed-zeros"
-Allow optimizations for floating point arithmetic that ignore the
-signedness of zero. \s-1IEEE\s0 arithmetic specifies the behavior of
-distinct +0.0 and \-0.0 values, which then prohibits simplification
-of expressions such as x+0.0 or 0.0*x (even with \fB\-ffinite\-math\-only\fR).
-This option implies that the sign of a zero result isn't significant.
-.Sp
-The default is \fB\-fsigned\-zeros\fR.
-.IP "\fB\-fno\-trapping\-math\fR" 4
-.IX Item "-fno-trapping-math"
-Compile code assuming that floating-point operations cannot generate
-user-visible traps. These traps include division by zero, overflow,
-underflow, inexact result and invalid operation. This option requires
-that \fB\-fno\-signaling\-nans\fR be in effect. Setting this option may
-allow faster code if one relies on \*(L"non-stop\*(R" \s-1IEEE\s0 arithmetic, for example.
-.Sp
-This option should never be turned on by any \fB\-O\fR option since
-it can result in incorrect output for programs which depend on
-an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
-math functions.
-.Sp
-The default is \fB\-ftrapping\-math\fR.
-.IP "\fB\-frounding\-math\fR" 4
-.IX Item "-frounding-math"
-Disable transformations and optimizations that assume default floating
-point rounding behavior. This is round-to-zero for all floating point
-to integer conversions, and round-to-nearest for all other arithmetic
-truncations. This option should be specified for programs that change
-the \s-1FP\s0 rounding mode dynamically, or that may be executed with a
-non-default rounding mode. This option disables constant folding of
-floating point expressions at compile-time (which may be affected by
-rounding mode) and arithmetic transformations that are unsafe in the
-presence of sign-dependent rounding modes.
-.Sp
-The default is \fB\-fno\-rounding\-math\fR.
-.Sp
-This option is experimental and does not currently guarantee to
-disable all \s-1GCC\s0 optimizations that are affected by rounding mode.
-Future versions of \s-1GCC\s0 may provide finer control of this setting
-using C99's \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma. This command line option
-will be used to specify the default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
-.IP "\fB\-fsignaling\-nans\fR" 4
-.IX Item "-fsignaling-nans"
-Compile code assuming that \s-1IEEE\s0 signaling NaNs may generate user-visible
-traps during floating-point operations. Setting this option disables
-optimizations that may change the number of exceptions visible with
-signaling NaNs. This option implies \fB\-ftrapping\-math\fR.
-.Sp
-This option causes the preprocessor macro \f(CW\*(C`_\|_SUPPORT_SNAN_\|_\*(C'\fR to
-be defined.
-.Sp
-The default is \fB\-fno\-signaling\-nans\fR.
-.Sp
-This option is experimental and does not currently guarantee to
-disable all \s-1GCC\s0 optimizations that affect signaling NaN behavior.
-.IP "\fB\-fsingle\-precision\-constant\fR" 4
-.IX Item "-fsingle-precision-constant"
-Treat floating point constant as single precision constant instead of
-implicitly converting it to double precision constant.
-.IP "\fB\-fcx\-limited\-range\fR" 4
-.IX Item "-fcx-limited-range"
-When enabled, this option states that a range reduction step is not
-needed when performing complex division. Also, there is no checking
-whether the result of a complex multiplication or division is \f(CW\*(C`NaN
-+ I*NaN\*(C'\fR, with an attempt to rescue the situation in that case. The
-default is \fB\-fno\-cx\-limited\-range\fR, but is enabled by
-\&\fB\-ffast\-math\fR.
-.Sp
-This option controls the default setting of the \s-1ISO\s0 C99
-\&\f(CW\*(C`CX_LIMITED_RANGE\*(C'\fR pragma. Nevertheless, the option applies to
-all languages.
-.IP "\fB\-fcx\-fortran\-rules\fR" 4
-.IX Item "-fcx-fortran-rules"
-Complex multiplication and division follow Fortran rules. Range
-reduction is done as part of complex division, but there is no checking
-whether the result of a complex multiplication or division is \f(CW\*(C`NaN
-+ I*NaN\*(C'\fR, with an attempt to rescue the situation in that case.
-.Sp
-The default is \fB\-fno\-cx\-fortran\-rules\fR.
-.IP "\fBmin-mcf-cancel-iters\fR" 4
-.IX Item "min-mcf-cancel-iters"
-The minimum number of iterations of negative cycle cancellation during
-\&\s-1MCF\s0 profile correction before early termination. This parameter is
-only useful when using \fB\-fprofile\-correction\fR.
-.PP
-The following options control optimizations that may improve
-performance, but are not enabled by any \fB\-O\fR options. This
-section includes experimental options that may produce broken code.
-.IP "\fB\-fbranch\-probabilities\fR" 4
-.IX Item "-fbranch-probabilities"
-After running a program compiled with \fB\-fprofile\-arcs\fR, you can compile it a second time using
-\&\fB\-fbranch\-probabilities\fR, to improve optimizations based on
-the number of times each branch was taken. When the program
-compiled with \fB\-fprofile\-arcs\fR exits it saves arc execution
-counts to a file called \fI\fIsourcename\fI.gcda\fR for each source
-file. The information in this data file is very dependent on the
-structure of the generated code, so you must use the same source code
-and the same optimization options for both compilations.
-.Sp
-With \fB\-fbranch\-probabilities\fR, \s-1GCC\s0 puts a
-\&\fB\s-1REG_BR_PROB\s0\fR note on each \fB\s-1JUMP_INSN\s0\fR and \fB\s-1CALL_INSN\s0\fR.
-These can be used to improve optimization. Currently, they are only
-used in one place: in \fIreorg.c\fR, instead of guessing which path a
-branch is most likely to take, the \fB\s-1REG_BR_PROB\s0\fR values are used to
-exactly determine which path is taken more often.
-.IP "\fB\-fclone\-hot\-version\-paths\fR" 4
-.IX Item "-fclone-hot-version-paths"
-When multi-version calls are made using \fB_\|_builtin_dispatch\fR, this flag
-enables cloning and hoisting of hot multiversioned paths.
-.IP "\fB\-fprofile\-values\fR" 4
-.IX Item "-fprofile-values"
-If combined with \fB\-fprofile\-arcs\fR, it adds code so that some
-data about values of expressions in the program is gathered.
-.Sp
-With \fB\-fbranch\-probabilities\fR, it reads back the data gathered
-from profiling values of expressions for usage in optimizations.
-.Sp
-Enabled with \fB\-fprofile\-generate\fR and \fB\-fprofile\-use\fR.
-.IP "\fB\-fvpt\fR" 4
-.IX Item "-fvpt"
-If combined with \fB\-fprofile\-arcs\fR, it instructs the compiler to add
-a code to gather information about values of expressions.
-.Sp
-With \fB\-fbranch\-probabilities\fR, it reads back the data gathered
-and actually performs the optimizations based on them.
-Currently the optimizations include specialization of division operation
-using the knowledge about the value of the denominator.
-.IP "\fB\-frename\-registers\fR" 4
-.IX Item "-frename-registers"
-Attempt to avoid false dependencies in scheduled code by making use
-of registers left over after register allocation. This optimization
-will most benefit processors with lots of registers. Depending on the
-debug information format adopted by the target, however, it can
-make debugging impossible, since variables will no longer stay in
-a \*(L"home register\*(R".
-.Sp
-Enabled by default with \fB\-funroll\-loops\fR and \fB\-fpeel\-loops\fR.
-.IP "\fB\-ftracer\fR" 4
-.IX Item "-ftracer"
-Perform tail duplication to enlarge superblock size. This transformation
-simplifies the control flow of the function allowing other optimizations to do
-better job.
-.Sp
-Enabled with \fB\-fprofile\-use\fR.
-.IP "\fB\-funroll\-loops\fR" 4
-.IX Item "-funroll-loops"
-Unroll loops whose number of iterations can be determined at compile time or
-upon entry to the loop. \fB\-funroll\-loops\fR implies
-\&\fB\-frerun\-cse\-after\-loop\fR, \fB\-fweb\fR and \fB\-frename\-registers\fR.
-It also turns on complete loop peeling (i.e. complete removal of loops with
-small constant number of iterations). This option makes code larger, and may
-or may not make it run faster.
-.Sp
-Enabled with \fB\-fprofile\-use\fR.
-.IP "\fB\-funroll\-all\-loops\fR" 4
-.IX Item "-funroll-all-loops"
-Unroll all loops, even if their number of iterations is uncertain when
-the loop is entered. This usually makes programs run more slowly.
-\&\fB\-funroll\-all\-loops\fR implies the same options as
-\&\fB\-funroll\-loops\fR.
-.IP "\fB\-fpeel\-loops\fR" 4
-.IX Item "-fpeel-loops"
-Peels the loops for that there is enough information that they do not
-roll much (from profile feedback). It also turns on complete loop peeling
-(i.e. complete removal of loops with small constant number of iterations).
-.Sp
-Enabled with \fB\-fprofile\-use\fR.
-.IP "\fB\-fmove\-loop\-invariants\fR" 4
-.IX Item "-fmove-loop-invariants"
-Enables the loop invariant motion pass in the \s-1RTL\s0 loop optimizer. Enabled
-at level \fB\-O1\fR
-.IP "\fB\-funswitch\-loops\fR" 4
-.IX Item "-funswitch-loops"
-Move branches with loop invariant conditions out of the loop, with duplicates
-of the loop on both branches (modified according to result of the condition).
-.IP "\fB\-ffunction\-sections\fR" 4
-.IX Item "-ffunction-sections"
-.PD 0
-.IP "\fB\-fdata\-sections\fR" 4
-.IX Item "-fdata-sections"
-.PD
-Place each function or data item into its own section in the output
-file if the target supports arbitrary sections. The name of the
-function or the name of the data item determines the section's name
-in the output file.
-.Sp
-Use these options on systems where the linker can perform optimizations
-to improve locality of reference in the instruction space. Most systems
-using the \s-1ELF\s0 object format and \s-1SPARC\s0 processors running Solaris 2 have
-linkers with such optimizations. \s-1AIX\s0 may have these optimizations in
-the future.
-.Sp
-Only use these options when there are significant benefits from doing
-so. When you specify these options, the assembler and linker will
-create larger object and executable files and will also be slower.
-You will not be able to use \f(CW\*(C`gprof\*(C'\fR on all systems if you
-specify this option and you may have problems with debugging if
-you specify both this option and \fB\-g\fR.
-.IP "\fB\-fbranch\-target\-load\-optimize\fR" 4
-.IX Item "-fbranch-target-load-optimize"
-Perform branch target register load optimization before prologue / epilogue
-threading.
-The use of target registers can typically be exposed only during reload,
-thus hoisting loads out of loops and doing inter-block scheduling needs
-a separate optimization pass.
-.IP "\fB\-fbranch\-target\-load\-optimize2\fR" 4
-.IX Item "-fbranch-target-load-optimize2"
-Perform branch target register load optimization after prologue / epilogue
-threading.
-.IP "\fB\-fbtr\-bb\-exclusive\fR" 4
-.IX Item "-fbtr-bb-exclusive"
-When performing branch target register load optimization, don't reuse
-branch target registers in within any basic block.
-.IP "\fB\-fstack\-protector\fR" 4
-.IX Item "-fstack-protector"
-Emit extra code to check for buffer overflows, such as stack smashing
-attacks. This is done by adding a guard variable to functions with
-vulnerable objects. This includes functions that call alloca, and
-functions with buffers larger than 8 bytes. The guards are initialized
-when a function is entered and then checked when the function exits.
-If a guard check fails, an error message is printed and the program exits.
-.IP "\fB\-fstack\-protector\-all\fR" 4
-.IX Item "-fstack-protector-all"
-Like \fB\-fstack\-protector\fR except that all functions are protected.
-.IP "\fB\-fstack\-protector\-strong\fR" 4
-.IX Item "-fstack-protector-strong"
-Like \fB\-fstack\-protector\fR but includes additional functions to be
-protected \- those that have local array definitions, or have references to
-local frame addresses.
-.IP "\fB\-fsection\-anchors\fR" 4
-.IX Item "-fsection-anchors"
-Try to reduce the number of symbolic address calculations by using
-shared \*(L"anchor\*(R" symbols to address nearby objects. This transformation
-can help to reduce the number of \s-1GOT\s0 entries and \s-1GOT\s0 accesses on some
-targets.
-.Sp
-For example, the implementation of the following function \f(CW\*(C`foo\*(C'\fR:
-.Sp
-.Vb 2
-\& static int a, b, c;
-\& int foo (void) { return a + b + c; }
-.Ve
-.Sp
-would usually calculate the addresses of all three variables, but if you
-compile it with \fB\-fsection\-anchors\fR, it will access the variables
-from a common anchor point instead. The effect is similar to the
-following pseudocode (which isn't valid C):
-.Sp
-.Vb 5
-\& int foo (void)
-\& {
-\& register int *xr = &x;
-\& return xr[&a \- &x] + xr[&b \- &x] + xr[&c \- &x];
-\& }
-.Ve
-.Sp
-Not all targets support this option.
-.IP "\fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR" 4
-.IX Item "--param name=value"
-In some places, \s-1GCC\s0 uses various constants to control the amount of
-optimization that is done. For example, \s-1GCC\s0 will not inline functions
-that contain more that a certain number of instructions. You can
-control some of these constants on the command-line using the
-\&\fB\-\-param\fR option.
-.Sp
-The names of specific parameters, and the meaning of the values, are
-tied to the internals of the compiler, and are subject to change
-without notice in future releases.
-.Sp
-In each case, the \fIvalue\fR is an integer. The allowable choices for
-\&\fIname\fR are given in the following table:
-.RS 4
-.IP "\fBstruct-reorg-cold-struct-ratio\fR" 4
-.IX Item "struct-reorg-cold-struct-ratio"
-The threshold ratio (as a percentage) between a structure frequency
-and the frequency of the hottest structure in the program. This parameter
-is used by struct-reorg optimization enabled by \fB\-fipa\-struct\-reorg\fR.
-We say that if the ratio of a structure frequency, calculated by profiling,
-to the hottest structure frequency in the program is less than this
-parameter, then structure reorganization is not applied to this structure.
-The default is 10.
-.IP "\fBpredictable-branch-outcome\fR" 4
-.IX Item "predictable-branch-outcome"
-When branch is predicted to be taken with probability lower than this threshold
-(in percent), then it is considered well predictable. The default is 10.
-.IP "\fBmax-crossjump-edges\fR" 4
-.IX Item "max-crossjump-edges"
-The maximum number of incoming edges to consider for crossjumping.
-The algorithm used by \fB\-fcrossjumping\fR is O(N^2) in
-the number of edges incoming to each block. Increasing values mean
-more aggressive optimization, making the compile time increase with
-probably small improvement in executable size.
-.IP "\fBmin-crossjump-insns\fR" 4
-.IX Item "min-crossjump-insns"
-The minimum number of instructions which must be matched at the end
-of two blocks before crossjumping will be performed on them. This
-value is ignored in the case where all instructions in the block being
-crossjumped from are matched. The default value is 5.
-.IP "\fBmax-grow-copy-bb-insns\fR" 4
-.IX Item "max-grow-copy-bb-insns"
-The maximum code size expansion factor when copying basic blocks
-instead of jumping. The expansion is relative to a jump instruction.
-The default value is 8.
-.IP "\fBmax-goto-duplication-insns\fR" 4
-.IX Item "max-goto-duplication-insns"
-The maximum number of instructions to duplicate to a block that jumps
-to a computed goto. To avoid O(N^2) behavior in a number of
-passes, \s-1GCC\s0 factors computed gotos early in the compilation process,
-and unfactors them as late as possible. Only computed jumps at the
-end of a basic blocks with no more than max-goto-duplication-insns are
-unfactored. The default value is 8.
-.IP "\fBmax-delay-slot-insn-search\fR" 4
-.IX Item "max-delay-slot-insn-search"
-The maximum number of instructions to consider when looking for an
-instruction to fill a delay slot. If more than this arbitrary number of
-instructions is searched, the time savings from filling the delay slot
-will be minimal so stop searching. Increasing values mean more
-aggressive optimization, making the compile time increase with probably
-small improvement in executable run time.
-.IP "\fBmax-delay-slot-live-search\fR" 4
-.IX Item "max-delay-slot-live-search"
-When trying to fill delay slots, the maximum number of instructions to
-consider when searching for a block with valid live register
-information. Increasing this arbitrarily chosen value means more
-aggressive optimization, increasing the compile time. This parameter
-should be removed when the delay slot code is rewritten to maintain the
-control-flow graph.
-.IP "\fBmax-gcse-memory\fR" 4
-.IX Item "max-gcse-memory"
-The approximate maximum amount of memory that will be allocated in
-order to perform the global common subexpression elimination
-optimization. If more memory than specified is required, the
-optimization will not be done.
-.IP "\fBmax-gcse-insertion-ratio\fR" 4
-.IX Item "max-gcse-insertion-ratio"
-If the ratio of expression insertions to deletions is larger than this value
-for any expression, then \s-1RTL\s0 \s-1PRE\s0 will insert or remove the expression and thus
-leave partially redundant computations in the instruction stream. The default value is 20.
-.IP "\fBmax-pending-list-length\fR" 4
-.IX Item "max-pending-list-length"
-The maximum number of pending dependencies scheduling will allow
-before flushing the current state and starting over. Large functions
-with few branches or calls can create excessively large lists which
-needlessly consume memory and resources.
-.IP "\fBmax-inline-insns-single\fR" 4
-.IX Item "max-inline-insns-single"
-Several parameters control the tree inliner used in gcc.
-This number sets the maximum number of instructions (counted in \s-1GCC\s0's
-internal representation) in a single function that the tree inliner
-will consider for inlining. This only affects functions declared
-inline and methods implemented in a class declaration (\*(C+).
-The default value is 400.
-.IP "\fBmax-inline-insns-auto\fR" 4
-.IX Item "max-inline-insns-auto"
-When you use \fB\-finline\-functions\fR (included in \fB\-O3\fR),
-a lot of functions that would otherwise not be considered for inlining
-by the compiler will be investigated. To those functions, a different
-(more restrictive) limit compared to functions declared inline can
-be applied.
-The default value is 40.
-.IP "\fBmversn-clone-depth\fR" 4
-.IX Item "mversn-clone-depth"
-When using \fB\-fclone\-hot\-version\-paths\fR, hot function paths are multi\-
-versioned via cloning. This parameter specifies the maximum length of the
-call graph path that can be cloned. The default value is 2.
-.IP "\fBnum-mversn-clones\fR" 4
-.IX Item "num-mversn-clones"
-When using \fB\-fclone\-hot\-version\-paths\fR, hot function paths are multi\-
-versioned via cloning. This parameter specifies the maximum number of
-functions that can be cloned. The default value is 10.
-.IP "\fBlarge-function-insns\fR" 4
-.IX Item "large-function-insns"
-The limit specifying really large functions. For functions larger than this
-limit after inlining, inlining is constrained by
-\&\fB\-\-param large-function-growth\fR. This parameter is useful primarily
-to avoid extreme compilation time caused by non-linear algorithms used by the
-backend.
-The default value is 2700.
-.IP "\fBlarge-function-growth\fR" 4
-.IX Item "large-function-growth"
-Specifies maximal growth of large function caused by inlining in percents.
-The default value is 100 which limits large function growth to 2.0 times
-the original size.
-.IP "\fBlarge-unit-insns\fR" 4
-.IX Item "large-unit-insns"
-The limit specifying large translation unit. Growth caused by inlining of
-units larger than this limit is limited by \fB\-\-param inline-unit-growth\fR.
-For small units this might be too tight (consider unit consisting of function A
-that is inline and B that just calls A three time. If B is small relative to
-A, the growth of unit is 300\e% and yet such inlining is very sane. For very
-large units consisting of small inlineable functions however the overall unit
-growth limit is needed to avoid exponential explosion of code size. Thus for
-smaller units, the size is increased to \fB\-\-param large-unit-insns\fR
-before applying \fB\-\-param inline-unit-growth\fR. The default is 10000
-.IP "\fBinline-unit-growth\fR" 4
-.IX Item "inline-unit-growth"
-Specifies maximal overall growth of the compilation unit caused by inlining.
-The default value is 30 which limits unit growth to 1.3 times the original
-size.
-.IP "\fBipcp-unit-growth\fR" 4
-.IX Item "ipcp-unit-growth"
-Specifies maximal overall growth of the compilation unit caused by
-interprocedural constant propagation. The default value is 10 which limits
-unit growth to 1.1 times the original size.
-.IP "\fBlarge-stack-frame\fR" 4
-.IX Item "large-stack-frame"
-The limit specifying large stack frames. While inlining the algorithm is trying
-to not grow past this limit too much. Default value is 256 bytes.
-.IP "\fBlarge-stack-frame-growth\fR" 4
-.IX Item "large-stack-frame-growth"
-Specifies maximal growth of large stack frames caused by inlining in percents.
-The default value is 1000 which limits large stack frame growth to 11 times
-the original size.
-.IP "\fBmax-inline-insns-recursive\fR" 4
-.IX Item "max-inline-insns-recursive"
-.PD 0
-.IP "\fBmax-inline-insns-recursive-auto\fR" 4
-.IX Item "max-inline-insns-recursive-auto"
-.PD
-Specifies maximum number of instructions out-of-line copy of self recursive inline
-function can grow into by performing recursive inlining.
-.Sp
-For functions declared inline \fB\-\-param max-inline-insns-recursive\fR is
-taken into account. For function not declared inline, recursive inlining
-happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
-enabled and \fB\-\-param max-inline-insns-recursive-auto\fR is used. The
-default value is 450.
-.IP "\fBmax-inline-recursive-depth\fR" 4
-.IX Item "max-inline-recursive-depth"
-.PD 0
-.IP "\fBmax-inline-recursive-depth-auto\fR" 4
-.IX Item "max-inline-recursive-depth-auto"
-.PD
-Specifies maximum recursion depth used by the recursive inlining.
-.Sp
-For functions declared inline \fB\-\-param max-inline-recursive-depth\fR is
-taken into account. For function not declared inline, recursive inlining
-happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
-enabled and \fB\-\-param max-inline-recursive-depth-auto\fR is used. The
-default value is 8.
-.IP "\fBmin-inline-recursive-probability\fR" 4
-.IX Item "min-inline-recursive-probability"
-Recursive inlining is profitable only for function having deep recursion
-in average and can hurt for function having little recursion depth by
-increasing the prologue size or complexity of function body to other
-optimizers.
-.Sp
-When profile feedback is available (see \fB\-fprofile\-generate\fR) the actual
-recursion depth can be guessed from probability that function will recurse via
-given call expression. This parameter limits inlining only to call expression
-whose probability exceeds given threshold (in percents). The default value is
-10.
-.IP "\fBearly-inlining-insns\fR" 4
-.IX Item "early-inlining-insns"
-Specify growth that early inliner can make. In effect it increases amount of
-inlining for code having large abstraction penalty. The default value is 10.
-.IP "\fBmax-early-inliner-iterations\fR" 4
-.IX Item "max-early-inliner-iterations"
-.PD 0
-.IP "\fBmax-early-inliner-iterations\fR" 4
-.IX Item "max-early-inliner-iterations"
-.PD
-Limit of iterations of early inliner. This basically bounds number of nested
-indirect calls early inliner can resolve. Deeper chains are still handled by
-late inlining.
-.IP "\fBcomdat-sharing-probability\fR" 4
-.IX Item "comdat-sharing-probability"
-.PD 0
-.IP "\fBcomdat-sharing-probability\fR" 4
-.IX Item "comdat-sharing-probability"
-.PD
-Probability (in percent) that \*(C+ inline function with comdat visibility
-will be shared across multiple compilation units. The default value is 20.
-.IP "\fBmin-vect-loop-bound\fR" 4
-.IX Item "min-vect-loop-bound"
-The minimum number of iterations under which a loop will not get vectorized
-when \fB\-ftree\-vectorize\fR is used. The number of iterations after
-vectorization needs to be greater than the value specified by this option
-to allow vectorization. The default value is 0.
-.IP "\fBgcse-cost-distance-ratio\fR" 4
-.IX Item "gcse-cost-distance-ratio"
-Scaling factor in calculation of maximum distance an expression
-can be moved by \s-1GCSE\s0 optimizations. This is currently supported only in the
-code hoisting pass. The bigger the ratio, the more aggressive code hoisting
-will be with simple expressions, i.e., the expressions which have cost
-less than \fBgcse-unrestricted-cost\fR. Specifying 0 will disable
-hoisting of simple expressions. The default value is 10.
-.IP "\fBgcse-unrestricted-cost\fR" 4
-.IX Item "gcse-unrestricted-cost"
-Cost, roughly measured as the cost of a single typical machine
-instruction, at which \s-1GCSE\s0 optimizations will not constrain
-the distance an expression can travel. This is currently
-supported only in the code hoisting pass. The lesser the cost,
-the more aggressive code hoisting will be. Specifying 0 will
-allow all expressions to travel unrestricted distances.
-The default value is 3.
-.IP "\fBmax-hoist-depth\fR" 4
-.IX Item "max-hoist-depth"
-The depth of search in the dominator tree for expressions to hoist.
-This is used to avoid quadratic behavior in hoisting algorithm.
-The value of 0 will avoid limiting the search, but may slow down compilation
-of huge functions. The default value is 30.
-.IP "\fBmax-unrolled-insns\fR" 4
-.IX Item "max-unrolled-insns"
-The maximum number of instructions that a loop should have if that loop
-is unrolled, and if the loop is unrolled, it determines how many times
-the loop code is unrolled.
-.IP "\fBmax-average-unrolled-insns\fR" 4
-.IX Item "max-average-unrolled-insns"
-The maximum number of instructions biased by probabilities of their execution
-that a loop should have if that loop is unrolled, and if the loop is unrolled,
-it determines how many times the loop code is unrolled.
-.IP "\fBmax-unroll-times\fR" 4
-.IX Item "max-unroll-times"
-The maximum number of unrollings of a single loop.
-.IP "\fBmax-peeled-insns\fR" 4
-.IX Item "max-peeled-insns"
-The maximum number of instructions that a loop should have if that loop
-is peeled, and if the loop is peeled, it determines how many times
-the loop code is peeled.
-.IP "\fBmax-peel-times\fR" 4
-.IX Item "max-peel-times"
-The maximum number of peelings of a single loop.
-.IP "\fBmax-completely-peeled-insns\fR" 4
-.IX Item "max-completely-peeled-insns"
-The maximum number of insns of a completely peeled loop.
-.IP "\fBmax-completely-peeled-insns-feedback\fR" 4
-.IX Item "max-completely-peeled-insns-feedback"
-The maximum number of insns of a completely peeled loop when profile
-feedback is available and the loop is hot. Because of the real
-profiles, this value may set to be larger for hot loops. Its default
-value is 600.
-.IP "\fBmax-once-peeled-insns\fR" 4
-.IX Item "max-once-peeled-insns"
-The maximum number of insns of a peeled loop that rolls only once.
-.IP "\fBmax-once-peeled-insns-feedback\fR" 4
-.IX Item "max-once-peeled-insns-feedback"
-The maximum number of insns of a peeled loop when profile feedback is
-available and the loop is hot. Because of the real profiles, this
-value may set to be larger for hot loops. The default value is 600.
-.IP "\fBmax-completely-peel-times\fR" 4
-.IX Item "max-completely-peel-times"
-The maximum number of iterations of a loop to be suitable for complete peeling.
-.IP "\fBmax-completely-peel-times-feedback\fR" 4
-.IX Item "max-completely-peel-times-feedback"
-The maximum number of iterations of a loop to be suitable for complete
-peeling when profile feedback is available and the loop is
-hot. Because of the real profiles, this value may set to be larger for
-hot loops. Its default value is 16.
-.IP "\fBmax-completely-peel-loop-nest-depth\fR" 4
-.IX Item "max-completely-peel-loop-nest-depth"
-The maximum depth of a loop nest suitable for complete peeling.
-.IP "\fBcodesize-hotness-threshold\fR" 4
-.IX Item "codesize-hotness-threshold"
-The minimum profile count of basic blocks to look at when estimating
-the code size footprint of the call graph in a \s-1LIPO\s0 compile.
-.IP "\fBunrollpeel-codesize-threshold\fR" 4
-.IX Item "unrollpeel-codesize-threshold"
-Maximum \s-1LIPO\s0 code size footprint estimate for loop unrolling and peeling.
-.IP "\fBmax-unswitch-insns\fR" 4
-.IX Item "max-unswitch-insns"
-The maximum number of insns of an unswitched loop.
-.IP "\fBmax-unswitch-level\fR" 4
-.IX Item "max-unswitch-level"
-The maximum number of branches unswitched in a single loop.
-.IP "\fBlim-expensive\fR" 4
-.IX Item "lim-expensive"
-The minimum cost of an expensive expression in the loop invariant motion.
-.IP "\fBiv-consider-all-candidates-bound\fR" 4
-.IX Item "iv-consider-all-candidates-bound"
-Bound on number of candidates for induction variables below that
-all candidates are considered for each use in induction variable
-optimizations. Only the most relevant candidates are considered
-if there are more candidates, to avoid quadratic time complexity.
-.IP "\fBiv-max-considered-uses\fR" 4
-.IX Item "iv-max-considered-uses"
-The induction variable optimizations give up on loops that contain more
-induction variable uses.
-.IP "\fBiv-always-prune-cand-set-bound\fR" 4
-.IX Item "iv-always-prune-cand-set-bound"
-If number of candidates in the set is smaller than this value,
-we always try to remove unnecessary ivs from the set during its
-optimization when a new iv is added to the set.
-.IP "\fBscev-max-expr-size\fR" 4
-.IX Item "scev-max-expr-size"
-Bound on size of expressions used in the scalar evolutions analyzer.
-Large expressions slow the analyzer.
-.IP "\fBscev-max-expr-complexity\fR" 4
-.IX Item "scev-max-expr-complexity"
-Bound on the complexity of the expressions in the scalar evolutions analyzer.
-Complex expressions slow the analyzer.
-.IP "\fBomega-max-vars\fR" 4
-.IX Item "omega-max-vars"
-The maximum number of variables in an Omega constraint system.
-The default value is 128.
-.IP "\fBomega-max-geqs\fR" 4
-.IX Item "omega-max-geqs"
-The maximum number of inequalities in an Omega constraint system.
-The default value is 256.
-.IP "\fBomega-max-eqs\fR" 4
-.IX Item "omega-max-eqs"
-The maximum number of equalities in an Omega constraint system.
-The default value is 128.
-.IP "\fBomega-max-wild-cards\fR" 4
-.IX Item "omega-max-wild-cards"
-The maximum number of wildcard variables that the Omega solver will
-be able to insert. The default value is 18.
-.IP "\fBomega-hash-table-size\fR" 4
-.IX Item "omega-hash-table-size"
-The size of the hash table in the Omega solver. The default value is
-550.
-.IP "\fBomega-max-keys\fR" 4
-.IX Item "omega-max-keys"
-The maximal number of keys used by the Omega solver. The default
-value is 500.
-.IP "\fBomega-eliminate-redundant-constraints\fR" 4
-.IX Item "omega-eliminate-redundant-constraints"
-When set to 1, use expensive methods to eliminate all redundant
-constraints. The default value is 0.
-.IP "\fBvect-max-version-for-alignment-checks\fR" 4
-.IX Item "vect-max-version-for-alignment-checks"
-The maximum number of runtime checks that can be performed when
-doing loop versioning for alignment in the vectorizer. See option
-ftree-vect-loop-version for more information.
-.IP "\fBvect-max-version-for-alias-checks\fR" 4
-.IX Item "vect-max-version-for-alias-checks"
-The maximum number of runtime checks that can be performed when
-doing loop versioning for alias in the vectorizer. See option
-ftree-vect-loop-version for more information.
-.IP "\fBmax-iterations-to-track\fR" 4
-.IX Item "max-iterations-to-track"
-The maximum number of iterations of a loop the brute force algorithm
-for analysis of # of iterations of the loop tries to evaluate.
-.IP "\fBhot-bb-count-fraction\fR" 4
-.IX Item "hot-bb-count-fraction"
-Select fraction of the maximal count of repetitions of basic block in program
-given basic block needs to have to be considered hot.
-.IP "\fBhot-bb-frequency-fraction\fR" 4
-.IX Item "hot-bb-frequency-fraction"
-Select fraction of the entry block frequency of executions of basic block in
-function given basic block needs to have to be considered hot
-.IP "\fBmax-predicted-iterations\fR" 4
-.IX Item "max-predicted-iterations"
-The maximum number of loop iterations we predict statically. This is useful
-in cases where function contain single loop with known bound and other loop
-with unknown. We predict the known number of iterations correctly, while
-the unknown number of iterations average to roughly 10. This means that the
-loop without bounds would appear artificially cold relative to the other one.
-.IP "\fBalign-threshold\fR" 4
-.IX Item "align-threshold"
-Select fraction of the maximal frequency of executions of basic block in
-function given basic block will get aligned.
-.IP "\fBalign-loop-iterations\fR" 4
-.IX Item "align-loop-iterations"
-A loop expected to iterate at lest the selected number of iterations will get
-aligned.
-.IP "\fBtracer-dynamic-coverage\fR" 4
-.IX Item "tracer-dynamic-coverage"
-.PD 0
-.IP "\fBtracer-dynamic-coverage-feedback\fR" 4
-.IX Item "tracer-dynamic-coverage-feedback"
-.PD
-This value is used to limit superblock formation once the given percentage of
-executed instructions is covered. This limits unnecessary code size
-expansion.
-.Sp
-The \fBtracer-dynamic-coverage-feedback\fR is used only when profile
-feedback is available. The real profiles (as opposed to statically estimated
-ones) are much less balanced allowing the threshold to be larger value.
-.IP "\fBtracer-max-code-growth\fR" 4
-.IX Item "tracer-max-code-growth"
-Stop tail duplication once code growth has reached given percentage. This is
-rather hokey argument, as most of the duplicates will be eliminated later in
-cross jumping, so it may be set to much higher values than is the desired code
-growth.
-.IP "\fBtracer-min-branch-ratio\fR" 4
-.IX Item "tracer-min-branch-ratio"
-Stop reverse growth when the reverse probability of best edge is less than this
-threshold (in percent).
-.IP "\fBtracer-min-branch-ratio\fR" 4
-.IX Item "tracer-min-branch-ratio"
-.PD 0
-.IP "\fBtracer-min-branch-ratio-feedback\fR" 4
-.IX Item "tracer-min-branch-ratio-feedback"
-.PD
-Stop forward growth if the best edge do have probability lower than this
-threshold.
-.Sp
-Similarly to \fBtracer-dynamic-coverage\fR two values are present, one for
-compilation for profile feedback and one for compilation without. The value
-for compilation with profile feedback needs to be more conservative (higher) in
-order to make tracer effective.
-.IP "\fBmax-cse-path-length\fR" 4
-.IX Item "max-cse-path-length"
-Maximum number of basic blocks on path that cse considers. The default is 10.
-.IP "\fBmax-cse-insns\fR" 4
-.IX Item "max-cse-insns"
-The maximum instructions \s-1CSE\s0 process before flushing. The default is 1000.
-.IP "\fBggc-min-expand\fR" 4
-.IX Item "ggc-min-expand"
-\&\s-1GCC\s0 uses a garbage collector to manage its own memory allocation. This
-parameter specifies the minimum percentage by which the garbage
-collector's heap should be allowed to expand between collections.
-Tuning this may improve compilation speed; it has no effect on code
-generation.
-.Sp
-The default is 30% + 70% * (\s-1RAM/1GB\s0) with an upper bound of 100% when
-\&\s-1RAM\s0 >= 1GB. If \f(CW\*(C`getrlimit\*(C'\fR is available, the notion of \*(L"\s-1RAM\s0\*(R" is
-the smallest of actual \s-1RAM\s0 and \f(CW\*(C`RLIMIT_DATA\*(C'\fR or \f(CW\*(C`RLIMIT_AS\*(C'\fR. If
-\&\s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a particular platform, the lower
-bound of 30% is used. Setting this parameter and
-\&\fBggc-min-heapsize\fR to zero causes a full collection to occur at
-every opportunity. This is extremely slow, but can be useful for
-debugging.
-.IP "\fBggc-min-heapsize\fR" 4
-.IX Item "ggc-min-heapsize"
-Minimum size of the garbage collector's heap before it begins bothering
-to collect garbage. The first collection occurs after the heap expands
-by \fBggc-min-expand\fR% beyond \fBggc-min-heapsize\fR. Again,
-tuning this may improve compilation speed, and has no effect on code
-generation.
-.Sp
-The default is the smaller of \s-1RAM/8\s0, \s-1RLIMIT_RSS\s0, or a limit which
-tries to ensure that \s-1RLIMIT_DATA\s0 or \s-1RLIMIT_AS\s0 are not exceeded, but
-with a lower bound of 4096 (four megabytes) and an upper bound of
-131072 (128 megabytes). If \s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a
-particular platform, the lower bound is used. Setting this parameter
-very large effectively disables garbage collection. Setting this
-parameter and \fBggc-min-expand\fR to zero causes a full collection
-to occur at every opportunity.
-.IP "\fBmax-reload-search-insns\fR" 4
-.IX Item "max-reload-search-insns"
-The maximum number of instruction reload should look backward for equivalent
-register. Increasing values mean more aggressive optimization, making the
-compile time increase with probably slightly better performance. The default
-value is 100.
-.IP "\fBmax-cselib-memory-locations\fR" 4
-.IX Item "max-cselib-memory-locations"
-The maximum number of memory locations cselib should take into account.
-Increasing values mean more aggressive optimization, making the compile time
-increase with probably slightly better performance. The default value is 500.
-.IP "\fBreorder-blocks-duplicate\fR" 4
-.IX Item "reorder-blocks-duplicate"
-.PD 0
-.IP "\fBreorder-blocks-duplicate-feedback\fR" 4
-.IX Item "reorder-blocks-duplicate-feedback"
-.PD
-Used by basic block reordering pass to decide whether to use unconditional
-branch or duplicate the code on its destination. Code is duplicated when its
-estimated size is smaller than this value multiplied by the estimated size of
-unconditional jump in the hot spots of the program.
-.Sp
-The \fBreorder-block-duplicate-feedback\fR is used only when profile
-feedback is available and may be set to higher values than
-\&\fBreorder-block-duplicate\fR since information about the hot spots is more
-accurate.
-.IP "\fBmax-sched-ready-insns\fR" 4
-.IX Item "max-sched-ready-insns"
-The maximum number of instructions ready to be issued the scheduler should
-consider at any given time during the first scheduling pass. Increasing
-values mean more thorough searches, making the compilation time increase
-with probably little benefit. The default value is 100.
-.IP "\fBmax-sched-region-blocks\fR" 4
-.IX Item "max-sched-region-blocks"
-The maximum number of blocks in a region to be considered for
-interblock scheduling. The default value is 10.
-.IP "\fBmax-pipeline-region-blocks\fR" 4
-.IX Item "max-pipeline-region-blocks"
-The maximum number of blocks in a region to be considered for
-pipelining in the selective scheduler. The default value is 15.
-.IP "\fBmax-sched-region-insns\fR" 4
-.IX Item "max-sched-region-insns"
-The maximum number of insns in a region to be considered for
-interblock scheduling. The default value is 100.
-.IP "\fBmax-pipeline-region-insns\fR" 4
-.IX Item "max-pipeline-region-insns"
-The maximum number of insns in a region to be considered for
-pipelining in the selective scheduler. The default value is 200.
-.IP "\fBmin-spec-prob\fR" 4
-.IX Item "min-spec-prob"
-The minimum probability (in percents) of reaching a source block
-for interblock speculative scheduling. The default value is 40.
-.IP "\fBmax-sched-extend-regions-iters\fR" 4
-.IX Item "max-sched-extend-regions-iters"
-The maximum number of iterations through \s-1CFG\s0 to extend regions.
-0 \- disable region extension,
-N \- do at most N iterations.
-The default value is 0.
-.IP "\fBmax-sched-insn-conflict-delay\fR" 4
-.IX Item "max-sched-insn-conflict-delay"
-The maximum conflict delay for an insn to be considered for speculative motion.
-The default value is 3.
-.IP "\fBsched-spec-prob-cutoff\fR" 4
-.IX Item "sched-spec-prob-cutoff"
-The minimal probability of speculation success (in percents), so that
-speculative insn will be scheduled.
-The default value is 40.
-.IP "\fBsched-mem-true-dep-cost\fR" 4
-.IX Item "sched-mem-true-dep-cost"
-Minimal distance (in \s-1CPU\s0 cycles) between store and load targeting same
-memory locations. The default value is 1.
-.IP "\fBselsched-max-lookahead\fR" 4
-.IX Item "selsched-max-lookahead"
-The maximum size of the lookahead window of selective scheduling. It is a
-depth of search for available instructions.
-The default value is 50.
-.IP "\fBselsched-max-sched-times\fR" 4
-.IX Item "selsched-max-sched-times"
-The maximum number of times that an instruction will be scheduled during
-selective scheduling. This is the limit on the number of iterations
-through which the instruction may be pipelined. The default value is 2.
-.IP "\fBselsched-max-insns-to-rename\fR" 4
-.IX Item "selsched-max-insns-to-rename"
-The maximum number of best instructions in the ready list that are considered
-for renaming in the selective scheduler. The default value is 2.
-.IP "\fBmax-last-value-rtl\fR" 4
-.IX Item "max-last-value-rtl"
-The maximum size measured as number of RTLs that can be recorded in an expression
-in combiner for a pseudo register as last known value of that register. The default
-is 10000.
-.IP "\fBinteger-share-limit\fR" 4
-.IX Item "integer-share-limit"
-Small integer constants can use a shared data structure, reducing the
-compiler's memory usage and increasing its speed. This sets the maximum
-value of a shared integer constant. The default value is 256.
-.IP "\fBmin-virtual-mappings\fR" 4
-.IX Item "min-virtual-mappings"
-Specifies the minimum number of virtual mappings in the incremental
-\&\s-1SSA\s0 updater that should be registered to trigger the virtual mappings
-heuristic defined by virtual-mappings-ratio. The default value is
-100.
-.IP "\fBvirtual-mappings-ratio\fR" 4
-.IX Item "virtual-mappings-ratio"
-If the number of virtual mappings is virtual-mappings-ratio bigger
-than the number of virtual symbols to be updated, then the incremental
-\&\s-1SSA\s0 updater switches to a full update for those symbols. The default
-ratio is 3.
-.IP "\fBssp-buffer-size\fR" 4
-.IX Item "ssp-buffer-size"
-The minimum size of buffers (i.e. arrays) that will receive stack smashing
-protection when \fB\-fstack\-protection\fR is used.
-.IP "\fBmax-jump-thread-duplication-stmts\fR" 4
-.IX Item "max-jump-thread-duplication-stmts"
-Maximum number of statements allowed in a block that needs to be
-duplicated when threading jumps.
-.IP "\fBmax-fields-for-field-sensitive\fR" 4
-.IX Item "max-fields-for-field-sensitive"
-Maximum number of fields in a structure we will treat in
-a field sensitive manner during pointer analysis. The default is zero
-for \-O0, and \-O1 and 100 for \-Os, \-O2, and \-O3.
-.IP "\fBprefetch-latency\fR" 4
-.IX Item "prefetch-latency"
-Estimate on average number of instructions that are executed before
-prefetch finishes. The distance we prefetch ahead is proportional
-to this constant. Increasing this number may also lead to less
-streams being prefetched (see \fBsimultaneous-prefetches\fR).
-.IP "\fBsimultaneous-prefetches\fR" 4
-.IX Item "simultaneous-prefetches"
-Maximum number of prefetches that can run at the same time.
-.IP "\fBl1\-cache\-line\-size\fR" 4
-.IX Item "l1-cache-line-size"
-The size of cache line in L1 cache, in bytes.
-.IP "\fBl1\-cache\-size\fR" 4
-.IX Item "l1-cache-size"
-The size of L1 cache, in kilobytes.
-.IP "\fBl2\-cache\-size\fR" 4
-.IX Item "l2-cache-size"
-The size of L2 cache, in kilobytes.
-.IP "\fBmin-insn-to-prefetch-ratio\fR" 4
-.IX Item "min-insn-to-prefetch-ratio"
-The minimum ratio between the number of instructions and the
-number of prefetches to enable prefetching in a loop.
-.IP "\fBprefetch-min-insn-to-mem-ratio\fR" 4
-.IX Item "prefetch-min-insn-to-mem-ratio"
-The minimum ratio between the number of instructions and the
-number of memory references to enable prefetching in a loop.
-.IP "\fBuse-canonical-types\fR" 4
-.IX Item "use-canonical-types"
-Whether the compiler should use the \*(L"canonical\*(R" type system. By
-default, this should always be 1, which uses a more efficient internal
-mechanism for comparing types in \*(C+ and Objective\-\*(C+. However, if
-bugs in the canonical type system are causing compilation failures,
-set this value to 0 to disable canonical types.
-.IP "\fBswitch-conversion-max-branch-ratio\fR" 4
-.IX Item "switch-conversion-max-branch-ratio"
-Switch initialization conversion will refuse to create arrays that are
-bigger than \fBswitch-conversion-max-branch-ratio\fR times the number of
-branches in the switch.
-.IP "\fBmax-partial-antic-length\fR" 4
-.IX Item "max-partial-antic-length"
-Maximum length of the partial antic set computed during the tree
-partial redundancy elimination optimization (\fB\-ftree\-pre\fR) when
-optimizing at \fB\-O3\fR and above. For some sorts of source code
-the enhanced partial redundancy elimination optimization can run away,
-consuming all of the memory available on the host machine. This
-parameter sets a limit on the length of the sets that are computed,
-which prevents the runaway behavior. Setting a value of 0 for
-this parameter will allow an unlimited set length.
-.IP "\fBsccvn-max-scc-size\fR" 4
-.IX Item "sccvn-max-scc-size"
-Maximum size of a strongly connected component (\s-1SCC\s0) during \s-1SCCVN\s0
-processing. If this limit is hit, \s-1SCCVN\s0 processing for the whole
-function will not be done and optimizations depending on it will
-be disabled. The default maximum \s-1SCC\s0 size is 10000.
-.IP "\fBira-max-loops-num\fR" 4
-.IX Item "ira-max-loops-num"
-\&\s-1IRA\s0 uses a regional register allocation by default. If a function
-contains loops more than number given by the parameter, only at most
-given number of the most frequently executed loops will form regions
-for the regional register allocation. The default value of the
-parameter is 100.
-.IP "\fBira-max-conflict-table-size\fR" 4
-.IX Item "ira-max-conflict-table-size"
-Although \s-1IRA\s0 uses a sophisticated algorithm of compression conflict
-table, the table can be still big for huge functions. If the conflict
-table for a function could be more than size in \s-1MB\s0 given by the
-parameter, the conflict table is not built and faster, simpler, and
-lower quality register allocation algorithm will be used. The
-algorithm do not use pseudo-register conflicts. The default value of
-the parameter is 2000.
-.IP "\fBira-loop-reserved-regs\fR" 4
-.IX Item "ira-loop-reserved-regs"
-\&\s-1IRA\s0 can be used to evaluate more accurate register pressure in loops
-for decision to move loop invariants (see \fB\-O3\fR). The number
-of available registers reserved for some other purposes is described
-by this parameter. The default value of the parameter is 2 which is
-minimal number of registers needed for execution of typical
-instruction. This value is the best found from numerous experiments.
-.IP "\fBloop-invariant-max-bbs-in-loop\fR" 4
-.IX Item "loop-invariant-max-bbs-in-loop"
-Loop invariant motion can be very expensive, both in compile time and
-in amount of needed compile time memory, with very large loops. Loops
-with more basic blocks than this parameter won't have loop invariant
-motion optimization performed on them. The default value of the
-parameter is 1000 for \-O1 and 10000 for \-O2 and above.
-.IP "\fBmax-vartrack-size\fR" 4
-.IX Item "max-vartrack-size"
-Sets a maximum number of hash table slots to use during variable
-tracking dataflow analysis of any function. If this limit is exceeded
-with variable tracking at assignments enabled, analysis for that
-function is retried without it, after removing all debug insns from
-the function. If the limit is exceeded even without debug insns, var
-tracking analysis is completely disabled for the function. Setting
-the parameter to zero makes it unlimited.
-.IP "\fBmin-nondebug-insn-uid\fR" 4
-.IX Item "min-nondebug-insn-uid"
-Use uids starting at this parameter for nondebug insns. The range below
-the parameter is reserved exclusively for debug insns created by
-\&\fB\-fvar\-tracking\-assignments\fR, but debug insns may get
-(non-overlapping) uids above it if the reserved range is exhausted.
-.IP "\fBipa-sra-ptr-growth-factor\fR" 4
-.IX Item "ipa-sra-ptr-growth-factor"
-IPA-SRA will replace a pointer to an aggregate with one or more new
-parameters only when their cumulative size is less or equal to
-\&\fBipa-sra-ptr-growth-factor\fR times the size of the original
-pointer parameter.
-.IP "\fBgraphite-max-nb-scop-params\fR" 4
-.IX Item "graphite-max-nb-scop-params"
-To avoid exponential effects in the Graphite loop transforms, the
-number of parameters in a Static Control Part (SCoP) is bounded. The
-default value is 10 parameters. A variable whose value is unknown at
-compile time and defined outside a SCoP is a parameter of the SCoP.
-.IP "\fBgraphite-max-bbs-per-function\fR" 4
-.IX Item "graphite-max-bbs-per-function"
-To avoid exponential effects in the detection of SCoPs, the size of
-the functions analyzed by Graphite is bounded. The default value is
-100 basic blocks.
-.IP "\fBloop-block-tile-size\fR" 4
-.IX Item "loop-block-tile-size"
-Loop blocking or strip mining transforms, enabled with
-\&\fB\-floop\-block\fR or \fB\-floop\-strip\-mine\fR, strip mine each
-loop in the loop nest by a given number of iterations. The strip
-length can be changed using the \fBloop-block-tile-size\fR
-parameter. The default value is 51 iterations.
-.IP "\fBdevirt-type-list-size\fR" 4
-.IX Item "devirt-type-list-size"
-IPA-CP attempts to track all possible types passed to a function's
-parameter in order to perform devirtualization.
-\&\fBdevirt-type-list-size\fR is the maximum number of types it
-stores per a single formal parameter of a function.
-.IP "\fBlto-partitions\fR" 4
-.IX Item "lto-partitions"
-Specify desired number of partitions produced during \s-1WHOPR\s0 compilation.
-The number of partitions should exceed the number of CPUs used for compilation.
-The default value is 32.
-.IP "\fBlto-minpartition\fR" 4
-.IX Item "lto-minpartition"
-Size of minimal partition for \s-1WHOPR\s0 (in estimated instructions).
-This prevents expenses of splitting very small programs into too many
-partitions.
-.IP "\fBcxx-max-namespaces-for-diagnostic-help\fR" 4
-.IX Item "cxx-max-namespaces-for-diagnostic-help"
-The maximum number of namespaces to consult for suggestions when \*(C+
-name lookup fails for an identifier. The default is 1000.
-.RE
-.RS 4
-.RE
-.SS "Options Controlling the Preprocessor"
-.IX Subsection "Options Controlling the Preprocessor"
-These options control the C preprocessor, which is run on each C source
-file before actual compilation.
-.PP
-If you use the \fB\-E\fR option, nothing is done except preprocessing.
-Some of these options make sense only together with \fB\-E\fR because
-they cause the preprocessor output to be unsuitable for actual
-compilation.
-.IP "\fB\-Wp,\fR\fIoption\fR" 4
-.IX Item "-Wp,option"
-You can use \fB\-Wp,\fR\fIoption\fR to bypass the compiler driver
-and pass \fIoption\fR directly through to the preprocessor. If
-\&\fIoption\fR contains commas, it is split into multiple options at the
-commas. However, many options are modified, translated or interpreted
-by the compiler driver before being passed to the preprocessor, and
-\&\fB\-Wp\fR forcibly bypasses this phase. The preprocessor's direct
-interface is undocumented and subject to change, so whenever possible
-you should avoid using \fB\-Wp\fR and let the driver handle the
-options instead.
-.IP "\fB\-Xpreprocessor\fR \fIoption\fR" 4
-.IX Item "-Xpreprocessor option"
-Pass \fIoption\fR as an option to the preprocessor. You can use this to
-supply system-specific preprocessor options which \s-1GCC\s0 does not know how to
-recognize.
-.Sp
-If you want to pass an option that takes an argument, you must use
-\&\fB\-Xpreprocessor\fR twice, once for the option and once for the argument.
-.IP "\fB\-D\fR \fIname\fR" 4
-.IX Item "-D name"
-Predefine \fIname\fR as a macro, with definition \f(CW1\fR.
-.IP "\fB\-D\fR \fIname\fR\fB=\fR\fIdefinition\fR" 4
-.IX Item "-D name=definition"
-The contents of \fIdefinition\fR are tokenized and processed as if
-they appeared during translation phase three in a \fB#define\fR
-directive. In particular, the definition will be truncated by
-embedded newline characters.
-.Sp
-If you are invoking the preprocessor from a shell or shell-like
-program you may need to use the shell's quoting syntax to protect
-characters such as spaces that have a meaning in the shell syntax.
-.Sp
-If you wish to define a function-like macro on the command line, write
-its argument list with surrounding parentheses before the equals sign
-(if any). Parentheses are meaningful to most shells, so you will need
-to quote the option. With \fBsh\fR and \fBcsh\fR,
-\&\fB\-D'\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB'\fR works.
-.Sp
-\&\fB\-D\fR and \fB\-U\fR options are processed in the order they
-are given on the command line. All \fB\-imacros\fR \fIfile\fR and
-\&\fB\-include\fR \fIfile\fR options are processed after all
-\&\fB\-D\fR and \fB\-U\fR options.
-.IP "\fB\-U\fR \fIname\fR" 4
-.IX Item "-U name"
-Cancel any previous definition of \fIname\fR, either built in or
-provided with a \fB\-D\fR option.
-.IP "\fB\-undef\fR" 4
-.IX Item "-undef"
-Do not predefine any system-specific or GCC-specific macros. The
-standard predefined macros remain defined.
-.IP "\fB\-I\fR \fIdir\fR" 4
-.IX Item "-I dir"
-Add the directory \fIdir\fR to the list of directories to be searched
-for header files.
-Directories named by \fB\-I\fR are searched before the standard
-system include directories. If the directory \fIdir\fR is a standard
-system include directory, the option is ignored to ensure that the
-default search order for system directories and the special treatment
-of system headers are not defeated
-\&.
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-o\fR \fIfile\fR" 4
-.IX Item "-o file"
-Write output to \fIfile\fR. This is the same as specifying \fIfile\fR
-as the second non-option argument to \fBcpp\fR. \fBgcc\fR has a
-different interpretation of a second non-option argument, so you must
-use \fB\-o\fR to specify the output file.
-.IP "\fB\-Wall\fR" 4
-.IX Item "-Wall"
-Turns on all optional warnings which are desirable for normal code.
-At present this is \fB\-Wcomment\fR, \fB\-Wtrigraphs\fR,
-\&\fB\-Wmultichar\fR and a warning about integer promotion causing a
-change of sign in \f(CW\*(C`#if\*(C'\fR expressions. Note that many of the
-preprocessor's warnings are on by default and have no options to
-control them.
-.IP "\fB\-Wcomment\fR" 4
-.IX Item "-Wcomment"
-.PD 0
-.IP "\fB\-Wcomments\fR" 4
-.IX Item "-Wcomments"
-.PD
-Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
-comment, or whenever a backslash-newline appears in a \fB//\fR comment.
-(Both forms have the same effect.)
-.IP "\fB\-Wtrigraphs\fR" 4
-.IX Item "-Wtrigraphs"
-Most trigraphs in comments cannot affect the meaning of the program.
-However, a trigraph that would form an escaped newline (\fB??/\fR at
-the end of a line) can, by changing where the comment begins or ends.
-Therefore, only trigraphs that would form escaped newlines produce
-warnings inside a comment.
-.Sp
-This option is implied by \fB\-Wall\fR. If \fB\-Wall\fR is not
-given, this option is still enabled unless trigraphs are enabled. To
-get trigraph conversion without warnings, but get the other
-\&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
-.IP "\fB\-Wtraditional\fR" 4
-.IX Item "-Wtraditional"
-Warn about certain constructs that behave differently in traditional and
-\&\s-1ISO\s0 C. Also warn about \s-1ISO\s0 C constructs that have no traditional C
-equivalent, and problematic constructs which should be avoided.
-.IP "\fB\-Wundef\fR" 4
-.IX Item "-Wundef"
-Warn whenever an identifier which is not a macro is encountered in an
-\&\fB#if\fR directive, outside of \fBdefined\fR. Such identifiers are
-replaced with zero.
-.IP "\fB\-Wunused\-macros\fR" 4
-.IX Item "-Wunused-macros"
-Warn about macros defined in the main file that are unused. A macro
-is \fIused\fR if it is expanded or tested for existence at least once.
-The preprocessor will also warn if the macro has not been used at the
-time it is redefined or undefined.
-.Sp
-Built-in macros, macros defined on the command line, and macros
-defined in include files are not warned about.
-.Sp
-\&\fINote:\fR If a macro is actually used, but only used in skipped
-conditional blocks, then \s-1CPP\s0 will report it as unused. To avoid the
-warning in such a case, you might improve the scope of the macro's
-definition by, for example, moving it into the first skipped block.
-Alternatively, you could provide a dummy use with something like:
-.Sp
-.Vb 2
-\& #if defined the_macro_causing_the_warning
-\& #endif
-.Ve
-.IP "\fB\-Wendif\-labels\fR" 4
-.IX Item "-Wendif-labels"
-Warn whenever an \fB#else\fR or an \fB#endif\fR are followed by text.
-This usually happens in code of the form
-.Sp
-.Vb 5
-\& #if FOO
-\& ...
-\& #else FOO
-\& ...
-\& #endif FOO
-.Ve
-.Sp
-The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments, but often are not
-in older programs. This warning is on by default.
-.IP "\fB\-Werror\fR" 4
-.IX Item "-Werror"
-Make all warnings into hard errors. Source code which triggers warnings
-will be rejected.
-.IP "\fB\-Wsystem\-headers\fR" 4
-.IX Item "-Wsystem-headers"
-Issue warnings for code in system headers. These are normally unhelpful
-in finding bugs in your own code, therefore suppressed. If you are
-responsible for the system library, you may want to see them.
-.IP "\fB\-w\fR" 4
-.IX Item "-w"
-Suppress all warnings, including those which \s-1GNU\s0 \s-1CPP\s0 issues by default.
-.IP "\fB\-pedantic\fR" 4
-.IX Item "-pedantic"
-Issue all the mandatory diagnostics listed in the C standard. Some of
-them are left out by default, since they trigger frequently on harmless
-code.
-.IP "\fB\-pedantic\-errors\fR" 4
-.IX Item "-pedantic-errors"
-Issue all the mandatory diagnostics, and make all mandatory diagnostics
-into errors. This includes mandatory diagnostics that \s-1GCC\s0 issues
-without \fB\-pedantic\fR but treats as warnings.
-.IP "\fB\-M\fR" 4
-.IX Item "-M"
-Instead of outputting the result of preprocessing, output a rule
-suitable for \fBmake\fR describing the dependencies of the main
-source file. The preprocessor outputs one \fBmake\fR rule containing
-the object file name for that source file, a colon, and the names of all
-the included files, including those coming from \fB\-include\fR or
-\&\fB\-imacros\fR command line options.
-.Sp
-Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
-object file name consists of the name of the source file with any
-suffix replaced with object file suffix and with any leading directory
-parts removed. If there are many included files then the rule is
-split into several lines using \fB\e\fR\-newline. The rule has no
-commands.
-.Sp
-This option does not suppress the preprocessor's debug output, such as
-\&\fB\-dM\fR. To avoid mixing such debug output with the dependency
-rules you should explicitly specify the dependency output file with
-\&\fB\-MF\fR, or use an environment variable like
-\&\fB\s-1DEPENDENCIES_OUTPUT\s0\fR. Debug output
-will still be sent to the regular output stream as normal.
-.Sp
-Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
-warnings with an implicit \fB\-w\fR.
-.IP "\fB\-MM\fR" 4
-.IX Item "-MM"
-Like \fB\-M\fR but do not mention header files that are found in
-system header directories, nor header files that are included,
-directly or indirectly, from such a header.
-.Sp
-This implies that the choice of angle brackets or double quotes in an
-\&\fB#include\fR directive does not in itself determine whether that
-header will appear in \fB\-MM\fR dependency output. This is a
-slight change in semantics from \s-1GCC\s0 versions 3.0 and earlier.
-.IP "\fB\-MF\fR \fIfile\fR" 4
-.IX Item "-MF file"
-When used with \fB\-M\fR or \fB\-MM\fR, specifies a
-file to write the dependencies to. If no \fB\-MF\fR switch is given
-the preprocessor sends the rules to the same place it would have sent
-preprocessed output.
-.Sp
-When used with the driver options \fB\-MD\fR or \fB\-MMD\fR,
-\&\fB\-MF\fR overrides the default dependency output file.
-.IP "\fB\-MG\fR" 4
-.IX Item "-MG"
-In conjunction with an option such as \fB\-M\fR requesting
-dependency generation, \fB\-MG\fR assumes missing header files are
-generated files and adds them to the dependency list without raising
-an error. The dependency filename is taken directly from the
-\&\f(CW\*(C`#include\*(C'\fR directive without prepending any path. \fB\-MG\fR
-also suppresses preprocessed output, as a missing header file renders
-this useless.
-.Sp
-This feature is used in automatic updating of makefiles.
-.IP "\fB\-MP\fR" 4
-.IX Item "-MP"
-This option instructs \s-1CPP\s0 to add a phony target for each dependency
-other than the main file, causing each to depend on nothing. These
-dummy rules work around errors \fBmake\fR gives if you remove header
-files without updating the \fIMakefile\fR to match.
-.Sp
-This is typical output:
-.Sp
-.Vb 1
-\& test.o: test.c test.h
-\&
-\& test.h:
-.Ve
-.IP "\fB\-MT\fR \fItarget\fR" 4
-.IX Item "-MT target"
-Change the target of the rule emitted by dependency generation. By
-default \s-1CPP\s0 takes the name of the main input file, deletes any
-directory components and any file suffix such as \fB.c\fR, and
-appends the platform's usual object suffix. The result is the target.
-.Sp
-An \fB\-MT\fR option will set the target to be exactly the string you
-specify. If you want multiple targets, you can specify them as a single
-argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
-.Sp
-For example, \fB\-MT\ '$(objpfx)foo.o'\fR might give
-.Sp
-.Vb 1
-\& $(objpfx)foo.o: foo.c
-.Ve
-.IP "\fB\-MQ\fR \fItarget\fR" 4
-.IX Item "-MQ target"
-Same as \fB\-MT\fR, but it quotes any characters which are special to
-Make. \fB\-MQ\ '$(objpfx)foo.o'\fR gives
-.Sp
-.Vb 1
-\& $$(objpfx)foo.o: foo.c
-.Ve
-.Sp
-The default target is automatically quoted, as if it were given with
-\&\fB\-MQ\fR.
-.IP "\fB\-MD\fR" 4
-.IX Item "-MD"
-\&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
-\&\fB\-E\fR is not implied. The driver determines \fIfile\fR based on
-whether an \fB\-o\fR option is given. If it is, the driver uses its
-argument but with a suffix of \fI.d\fR, otherwise it takes the name
-of the input file, removes any directory components and suffix, and
-applies a \fI.d\fR suffix.
-.Sp
-If \fB\-MD\fR is used in conjunction with \fB\-E\fR, any
-\&\fB\-o\fR switch is understood to specify the dependency output file, but if used without \fB\-E\fR, each \fB\-o\fR
-is understood to specify a target object file.
-.Sp
-Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
-a dependency output file as a side-effect of the compilation process.
-.IP "\fB\-MMD\fR" 4
-.IX Item "-MMD"
-Like \fB\-MD\fR except mention only user header files, not system
-header files.
-.IP "\fB\-fpch\-deps\fR" 4
-.IX Item "-fpch-deps"
-When using precompiled headers, this flag
-will cause the dependency-output flags to also list the files from the
-precompiled header's dependencies. If not specified only the
-precompiled header would be listed and not the files that were used to
-create it because those files are not consulted when a precompiled
-header is used.
-.IP "\fB\-fpch\-preprocess\fR" 4
-.IX Item "-fpch-preprocess"
-This option allows use of a precompiled header together with \fB\-E\fR. It inserts a special \f(CW\*(C`#pragma\*(C'\fR,
-\&\f(CW\*(C`#pragma GCC pch_preprocess "\f(CIfilename\f(CW"\*(C'\fR in the output to mark
-the place where the precompiled header was found, and its \fIfilename\fR.
-When \fB\-fpreprocessed\fR is in use, \s-1GCC\s0 recognizes this \f(CW\*(C`#pragma\*(C'\fR
-and loads the \s-1PCH\s0.
-.Sp
-This option is off by default, because the resulting preprocessed output
-is only really suitable as input to \s-1GCC\s0. It is switched on by
-\&\fB\-save\-temps\fR.
-.Sp
-You should not write this \f(CW\*(C`#pragma\*(C'\fR in your own code, but it is
-safe to edit the filename if the \s-1PCH\s0 file is available in a different
-location. The filename may be absolute or it may be relative to \s-1GCC\s0's
-current directory.
-.IP "\fB\-x c\fR" 4
-.IX Item "-x c"
-.PD 0
-.IP "\fB\-x c++\fR" 4
-.IX Item "-x c++"
-.IP "\fB\-x objective-c\fR" 4
-.IX Item "-x objective-c"
-.IP "\fB\-x assembler-with-cpp\fR" 4
-.IX Item "-x assembler-with-cpp"
-.PD
-Specify the source language: C, \*(C+, Objective-C, or assembly. This has
-nothing to do with standards conformance or extensions; it merely
-selects which base syntax to expect. If you give none of these options,
-cpp will deduce the language from the extension of the source file:
-\&\fB.c\fR, \fB.cc\fR, \fB.m\fR, or \fB.S\fR. Some other common
-extensions for \*(C+ and assembly are also recognized. If cpp does not
-recognize the extension, it will treat the file as C; this is the most
-generic mode.
-.Sp
-\&\fINote:\fR Previous versions of cpp accepted a \fB\-lang\fR option
-which selected both the language and the standards conformance level.
-This option has been removed, because it conflicts with the \fB\-l\fR
-option.
-.IP "\fB\-std=\fR\fIstandard\fR" 4
-.IX Item "-std=standard"
-.PD 0
-.IP "\fB\-ansi\fR" 4
-.IX Item "-ansi"
-.PD
-Specify the standard to which the code should conform. Currently \s-1CPP\s0
-knows about C and \*(C+ standards; others may be added in the future.
-.Sp
-\&\fIstandard\fR
-may be one of:
-.RS 4
-.ie n .IP """c90""" 4
-.el .IP "\f(CWc90\fR" 4
-.IX Item "c90"
-.PD 0
-.ie n .IP """c89""" 4
-.el .IP "\f(CWc89\fR" 4
-.IX Item "c89"
-.ie n .IP """iso9899:1990""" 4
-.el .IP "\f(CWiso9899:1990\fR" 4
-.IX Item "iso9899:1990"
-.PD
-The \s-1ISO\s0 C standard from 1990. \fBc90\fR is the customary shorthand for
-this version of the standard.
-.Sp
-The \fB\-ansi\fR option is equivalent to \fB\-std=c90\fR.
-.ie n .IP """iso9899:199409""" 4
-.el .IP "\f(CWiso9899:199409\fR" 4
-.IX Item "iso9899:199409"
-The 1990 C standard, as amended in 1994.
-.ie n .IP """iso9899:1999""" 4
-.el .IP "\f(CWiso9899:1999\fR" 4
-.IX Item "iso9899:1999"
-.PD 0
-.ie n .IP """c99""" 4
-.el .IP "\f(CWc99\fR" 4
-.IX Item "c99"
-.ie n .IP """iso9899:199x""" 4
-.el .IP "\f(CWiso9899:199x\fR" 4
-.IX Item "iso9899:199x"
-.ie n .IP """c9x""" 4
-.el .IP "\f(CWc9x\fR" 4
-.IX Item "c9x"
-.PD
-The revised \s-1ISO\s0 C standard, published in December 1999. Before
-publication, this was known as C9X.
-.ie n .IP """c1x""" 4
-.el .IP "\f(CWc1x\fR" 4
-.IX Item "c1x"
-The next version of the \s-1ISO\s0 C standard, still under development.
-.ie n .IP """gnu90""" 4
-.el .IP "\f(CWgnu90\fR" 4
-.IX Item "gnu90"
-.PD 0
-.ie n .IP """gnu89""" 4
-.el .IP "\f(CWgnu89\fR" 4
-.IX Item "gnu89"
-.PD
-The 1990 C standard plus \s-1GNU\s0 extensions. This is the default.
-.ie n .IP """gnu99""" 4
-.el .IP "\f(CWgnu99\fR" 4
-.IX Item "gnu99"
-.PD 0
-.ie n .IP """gnu9x""" 4
-.el .IP "\f(CWgnu9x\fR" 4
-.IX Item "gnu9x"
-.PD
-The 1999 C standard plus \s-1GNU\s0 extensions.
-.ie n .IP """gnu1x""" 4
-.el .IP "\f(CWgnu1x\fR" 4
-.IX Item "gnu1x"
-The next version of the \s-1ISO\s0 C standard, still under development, plus
-\&\s-1GNU\s0 extensions.
-.ie n .IP """c++98""" 4
-.el .IP "\f(CWc++98\fR" 4
-.IX Item "c++98"
-The 1998 \s-1ISO\s0 \*(C+ standard plus amendments.
-.ie n .IP """gnu++98""" 4
-.el .IP "\f(CWgnu++98\fR" 4
-.IX Item "gnu++98"
-The same as \fB\-std=c++98\fR plus \s-1GNU\s0 extensions. This is the
-default for \*(C+ code.
-.RE
-.RS 4
-.RE
-.IP "\fB\-I\-\fR" 4
-.IX Item "-I-"
-Split the include path. Any directories specified with \fB\-I\fR
-options before \fB\-I\-\fR are searched only for headers requested with
-\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
-\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR. If additional directories are
-specified with \fB\-I\fR options after the \fB\-I\-\fR, those
-directories are searched for all \fB#include\fR directives.
-.Sp
-In addition, \fB\-I\-\fR inhibits the use of the directory of the current
-file directory as the first search directory for \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.
-This option has been deprecated.
-.IP "\fB\-nostdinc\fR" 4
-.IX Item "-nostdinc"
-Do not search the standard system directories for header files.
-Only the directories you have specified with \fB\-I\fR options
-(and the directory of the current file, if appropriate) are searched.
-.IP "\fB\-nostdinc++\fR" 4
-.IX Item "-nostdinc++"
-Do not search for header files in the \*(C+\-specific standard directories,
-but do still search the other standard directories. (This option is
-used when building the \*(C+ library.)
-.IP "\fB\-include\fR \fIfile\fR" 4
-.IX Item "-include file"
-Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
-line of the primary source file. However, the first directory searched
-for \fIfile\fR is the preprocessor's working directory \fIinstead of\fR
-the directory containing the main source file. If not found there, it
-is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
-chain as normal.
-.Sp
-If multiple \fB\-include\fR options are given, the files are included
-in the order they appear on the command line.
-.IP "\fB\-imacros\fR \fIfile\fR" 4
-.IX Item "-imacros file"
-Exactly like \fB\-include\fR, except that any output produced by
-scanning \fIfile\fR is thrown away. Macros it defines remain defined.
-This allows you to acquire all the macros from a header without also
-processing its declarations.
-.Sp
-All files specified by \fB\-imacros\fR are processed before all files
-specified by \fB\-include\fR.
-.IP "\fB\-idirafter\fR \fIdir\fR" 4
-.IX Item "-idirafter dir"
-Search \fIdir\fR for header files, but do it \fIafter\fR all
-directories specified with \fB\-I\fR and the standard system directories
-have been exhausted. \fIdir\fR is treated as a system include directory.
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-iprefix\fR \fIprefix\fR" 4
-.IX Item "-iprefix prefix"
-Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
-options. If the prefix represents a directory, you should include the
-final \fB/\fR.
-.IP "\fB\-iwithprefix\fR \fIdir\fR" 4
-.IX Item "-iwithprefix dir"
-.PD 0
-.IP "\fB\-iwithprefixbefore\fR \fIdir\fR" 4
-.IX Item "-iwithprefixbefore dir"
-.PD
-Append \fIdir\fR to the prefix specified previously with
-\&\fB\-iprefix\fR, and add the resulting directory to the include search
-path. \fB\-iwithprefixbefore\fR puts it in the same place \fB\-I\fR
-would; \fB\-iwithprefix\fR puts it where \fB\-idirafter\fR would.
-.IP "\fB\-isysroot\fR \fIdir\fR" 4
-.IX Item "-isysroot dir"
-This option is like the \fB\-\-sysroot\fR option, but applies only to
-header files (except for Darwin targets, where it applies to both header
-files and libraries). See the \fB\-\-sysroot\fR option for more
-information.
-.IP "\fB\-imultilib\fR \fIdir\fR" 4
-.IX Item "-imultilib dir"
-Use \fIdir\fR as a subdirectory of the directory containing
-target-specific \*(C+ headers.
-.IP "\fB\-isystem\fR \fIdir\fR" 4
-.IX Item "-isystem dir"
-Search \fIdir\fR for header files, after all directories specified by
-\&\fB\-I\fR but before the standard system directories. Mark it
-as a system directory, so that it gets the same special treatment as
-is applied to the standard system directories.
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-iquote\fR \fIdir\fR" 4
-.IX Item "-iquote dir"
-Search \fIdir\fR only for header files requested with
-\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
-\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR, before all directories specified by
-\&\fB\-I\fR and before the standard system directories.
-If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
-.IP "\fB\-fdirectives\-only\fR" 4
-.IX Item "-fdirectives-only"
-When preprocessing, handle directives, but do not expand macros.
-.Sp
-The option's behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
-options.
-.Sp
-With \fB\-E\fR, preprocessing is limited to the handling of directives
-such as \f(CW\*(C`#define\*(C'\fR, \f(CW\*(C`#ifdef\*(C'\fR, and \f(CW\*(C`#error\*(C'\fR. Other
-preprocessor operations, such as macro expansion and trigraph
-conversion are not performed. In addition, the \fB\-dD\fR option is
-implicitly enabled.
-.Sp
-With \fB\-fpreprocessed\fR, predefinition of command line and most
-builtin macros is disabled. Macros such as \f(CW\*(C`_\|_LINE_\|_\*(C'\fR, which are
-contextually dependent, are handled normally. This enables compilation of
-files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
-.Sp
-With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
-\&\fB\-fpreprocessed\fR take precedence. This enables full preprocessing of
-files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
-.IP "\fB\-fdollars\-in\-identifiers\fR" 4
-.IX Item "-fdollars-in-identifiers"
-Accept \fB$\fR in identifiers.
-.IP "\fB\-fextended\-identifiers\fR" 4
-.IX Item "-fextended-identifiers"
-Accept universal character names in identifiers. This option is
-experimental; in a future version of \s-1GCC\s0, it will be enabled by
-default for C99 and \*(C+.
-.IP "\fB\-fpreprocessed\fR" 4
-.IX Item "-fpreprocessed"
-Indicate to the preprocessor that the input file has already been
-preprocessed. This suppresses things like macro expansion, trigraph
-conversion, escaped newline splicing, and processing of most directives.
-The preprocessor still recognizes and removes comments, so that you can
-pass a file preprocessed with \fB\-C\fR to the compiler without
-problems. In this mode the integrated preprocessor is little more than
-a tokenizer for the front ends.
-.Sp
-\&\fB\-fpreprocessed\fR is implicit if the input file has one of the
-extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR. These are the
-extensions that \s-1GCC\s0 uses for preprocessed files created by
-\&\fB\-save\-temps\fR.
-.IP "\fB\-ftabstop=\fR\fIwidth\fR" 4
-.IX Item "-ftabstop=width"
-Set the distance between tab stops. This helps the preprocessor report
-correct column numbers in warnings or errors, even if tabs appear on the
-line. If the value is less than 1 or greater than 100, the option is
-ignored. The default is 8.
-.IP "\fB\-fexec\-charset=\fR\fIcharset\fR" 4
-.IX Item "-fexec-charset=charset"
-Set the execution character set, used for string and character
-constants. The default is \s-1UTF\-8\s0. \fIcharset\fR can be any encoding
-supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
-.IP "\fB\-fwide\-exec\-charset=\fR\fIcharset\fR" 4
-.IX Item "-fwide-exec-charset=charset"
-Set the wide execution character set, used for wide string and
-character constants. The default is \s-1UTF\-32\s0 or \s-1UTF\-16\s0, whichever
-corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR. As with
-\&\fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
-by the system's \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
-problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
-.IP "\fB\-finput\-charset=\fR\fIcharset\fR" 4
-.IX Item "-finput-charset=charset"
-Set the input character set, used for translation from the character
-set of the input file to the source character set used by \s-1GCC\s0. If the
-locale does not specify, or \s-1GCC\s0 cannot get this information from the
-locale, the default is \s-1UTF\-8\s0. This can be overridden by either the locale
-or this command line option. Currently the command line option takes
-precedence if there's a conflict. \fIcharset\fR can be any encoding
-supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
-.IP "\fB\-fworking\-directory\fR" 4
-.IX Item "-fworking-directory"
-Enable generation of linemarkers in the preprocessor output that will
-let the compiler know the current working directory at the time of
-preprocessing. When this option is enabled, the preprocessor will
-emit, after the initial linemarker, a second linemarker with the
-current working directory followed by two slashes. \s-1GCC\s0 will use this
-directory, when it's present in the preprocessed input, as the
-directory emitted as the current working directory in some debugging
-information formats. This option is implicitly enabled if debugging
-information is enabled, but this can be inhibited with the negated
-form \fB\-fno\-working\-directory\fR. If the \fB\-P\fR flag is
-present in the command line, this option has no effect, since no
-\&\f(CW\*(C`#line\*(C'\fR directives are emitted whatsoever.
-.IP "\fB\-fno\-show\-column\fR" 4
-.IX Item "-fno-show-column"
-Do not print column numbers in diagnostics. This may be necessary if
-diagnostics are being scanned by a program that does not understand the
-column numbers, such as \fBdejagnu\fR.
-.IP "\fB\-A\fR \fIpredicate\fR\fB=\fR\fIanswer\fR" 4
-.IX Item "-A predicate=answer"
-Make an assertion with the predicate \fIpredicate\fR and answer
-\&\fIanswer\fR. This form is preferred to the older form \fB\-A\fR
-\&\fIpredicate\fR\fB(\fR\fIanswer\fR\fB)\fR, which is still supported, because
-it does not use shell special characters.
-.IP "\fB\-A \-\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4
-.IX Item "-A -predicate=answer"
-Cancel an assertion with the predicate \fIpredicate\fR and answer
-\&\fIanswer\fR.
-.IP "\fB\-dCHARS\fR" 4
-.IX Item "-dCHARS"
-\&\fI\s-1CHARS\s0\fR is a sequence of one or more of the following characters,
-and must not be preceded by a space. Other characters are interpreted
-by the compiler proper, or reserved for future versions of \s-1GCC\s0, and so
-are silently ignored. If you specify characters whose behavior
-conflicts, the result is undefined.
-.RS 4
-.IP "\fBM\fR" 4
-.IX Item "M"
-Instead of the normal output, generate a list of \fB#define\fR
-directives for all the macros defined during the execution of the
-preprocessor, including predefined macros. This gives you a way of
-finding out what is predefined in your version of the preprocessor.
-Assuming you have no file \fIfoo.h\fR, the command
-.Sp
-.Vb 1
-\& touch foo.h; cpp \-dM foo.h
-.Ve
-.Sp
-will show all the predefined macros.
-.Sp
-If you use \fB\-dM\fR without the \fB\-E\fR option, \fB\-dM\fR is
-interpreted as a synonym for \fB\-fdump\-rtl\-mach\fR.
-.IP "\fBD\fR" 4
-.IX Item "D"
-Like \fBM\fR except in two respects: it does \fInot\fR include the
-predefined macros, and it outputs \fIboth\fR the \fB#define\fR
-directives and the result of preprocessing. Both kinds of output go to
-the standard output file.
-.IP "\fBN\fR" 4
-.IX Item "N"
-Like \fBD\fR, but emit only the macro names, not their expansions.
-.IP "\fBI\fR" 4
-.IX Item "I"
-Output \fB#include\fR directives in addition to the result of
-preprocessing.
-.IP "\fBU\fR" 4
-.IX Item "U"
-Like \fBD\fR except that only macros that are expanded, or whose
-definedness is tested in preprocessor directives, are output; the
-output is delayed until the use or test of the macro; and
-\&\fB#undef\fR directives are also output for macros tested but
-undefined at the time.
-.RE
-.RS 4
-.RE
-.IP "\fB\-P\fR" 4
-.IX Item "-P"
-Inhibit generation of linemarkers in the output from the preprocessor.
-This might be useful when running the preprocessor on something that is
-not C code, and will be sent to a program which might be confused by the
-linemarkers.
-.IP "\fB\-C\fR" 4
-.IX Item "-C"
-Do not discard comments. All comments are passed through to the output
-file, except for comments in processed directives, which are deleted
-along with the directive.
-.Sp
-You should be prepared for side effects when using \fB\-C\fR; it
-causes the preprocessor to treat comments as tokens in their own right.
-For example, comments appearing at the start of what would be a
-directive line have the effect of turning that line into an ordinary
-source line, since the first token on the line is no longer a \fB#\fR.
-.IP "\fB\-CC\fR" 4
-.IX Item "-CC"
-Do not discard comments, including during macro expansion. This is
-like \fB\-C\fR, except that comments contained within macros are
-also passed through to the output file where the macro is expanded.
-.Sp
-In addition to the side-effects of the \fB\-C\fR option, the
-\&\fB\-CC\fR option causes all \*(C+\-style comments inside a macro
-to be converted to C\-style comments. This is to prevent later use
-of that macro from inadvertently commenting out the remainder of
-the source line.
-.Sp
-The \fB\-CC\fR option is generally used to support lint comments.
-.IP "\fB\-traditional\-cpp\fR" 4
-.IX Item "-traditional-cpp"
-Try to imitate the behavior of old-fashioned C preprocessors, as
-opposed to \s-1ISO\s0 C preprocessors.
-.IP "\fB\-trigraphs\fR" 4
-.IX Item "-trigraphs"
-Process trigraph sequences.
-These are three-character sequences, all starting with \fB??\fR, that
-are defined by \s-1ISO\s0 C to stand for single characters. For example,
-\&\fB??/\fR stands for \fB\e\fR, so \fB'??/n'\fR is a character
-constant for a newline. By default, \s-1GCC\s0 ignores trigraphs, but in
-standard-conforming modes it converts them. See the \fB\-std\fR and
-\&\fB\-ansi\fR options.
-.Sp
-The nine trigraphs and their replacements are
-.Sp
-.Vb 2
-\& Trigraph: ??( ??) ??< ??> ??= ??/ ??\*(Aq ??! ??\-
-\& Replacement: [ ] { } # \e ^ | ~
-.Ve
-.IP "\fB\-remap\fR" 4
-.IX Item "-remap"
-Enable special code to work around file systems which only permit very
-short file names, such as MS-DOS.
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-.PD 0
-.IP "\fB\-\-target\-help\fR" 4
-.IX Item "--target-help"
-.PD
-Print text describing all the command line options instead of
-preprocessing anything.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-Verbose mode. Print out \s-1GNU\s0 \s-1CPP\s0's version number at the beginning of
-execution, and report the final form of the include path.
-.IP "\fB\-H\fR" 4
-.IX Item "-H"
-Print the name of each header file used, in addition to other normal
-activities. Each name is indented to show how deep in the
-\&\fB#include\fR stack it is. Precompiled header files are also
-printed, even if they are found to be invalid; an invalid precompiled
-header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
-.IP "\fB\-version\fR" 4
-.IX Item "-version"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Print out \s-1GNU\s0 \s-1CPP\s0's version number. With one dash, proceed to
-preprocess as normal. With two dashes, exit immediately.
-.SS "Passing Options to the Assembler"
-.IX Subsection "Passing Options to the Assembler"
-You can pass options to the assembler.
-.IP "\fB\-Wa,\fR\fIoption\fR" 4
-.IX Item "-Wa,option"
-Pass \fIoption\fR as an option to the assembler. If \fIoption\fR
-contains commas, it is split into multiple options at the commas.
-.IP "\fB\-Xassembler\fR \fIoption\fR" 4
-.IX Item "-Xassembler option"
-Pass \fIoption\fR as an option to the assembler. You can use this to
-supply system-specific assembler options which \s-1GCC\s0 does not know how to
-recognize.
-.Sp
-If you want to pass an option that takes an argument, you must use
-\&\fB\-Xassembler\fR twice, once for the option and once for the argument.
-.IP "\fBprofile-generate-sampling-rate\fR" 4
-.IX Item "profile-generate-sampling-rate"
-Set the sampling rate with \fB\-fprofile\-generate\-sampling\fR.
-.SS "Options for Linking"
-.IX Subsection "Options for Linking"
-These options come into play when the compiler links object files into
-an executable output file. They are meaningless if the compiler is
-not doing a link step.
-.IP "\fIobject-file-name\fR" 4
-.IX Item "object-file-name"
-A file name that does not end in a special recognized suffix is
-considered to name an object file or library. (Object files are
-distinguished from libraries by the linker according to the file
-contents.) If linking is done, these object files are used as input
-to the linker.
-.IP "\fB\-c\fR" 4
-.IX Item "-c"
-.PD 0
-.IP "\fB\-S\fR" 4
-.IX Item "-S"
-.IP "\fB\-E\fR" 4
-.IX Item "-E"
-.PD
-If any of these options is used, then the linker is not run, and
-object file names should not be used as arguments.
-.IP "\fB\-l\fR\fIlibrary\fR" 4
-.IX Item "-llibrary"
-.PD 0
-.IP "\fB\-l\fR \fIlibrary\fR" 4
-.IX Item "-l library"
-.PD
-Search the library named \fIlibrary\fR when linking. (The second
-alternative with the library as a separate argument is only for
-\&\s-1POSIX\s0 compliance and is not recommended.)
-.Sp
-It makes a difference where in the command you write this option; the
-linker searches and processes libraries and object files in the order they
-are specified. Thus, \fBfoo.o \-lz bar.o\fR searches library \fBz\fR
-after file \fIfoo.o\fR but before \fIbar.o\fR. If \fIbar.o\fR refers
-to functions in \fBz\fR, those functions may not be loaded.
-.Sp
-The linker searches a standard list of directories for the library,
-which is actually a file named \fIlib\fIlibrary\fI.a\fR. The linker
-then uses this file as if it had been specified precisely by name.
-.Sp
-The directories searched include several standard system directories
-plus any that you specify with \fB\-L\fR.
-.Sp
-Normally the files found this way are library files\-\-\-archive files
-whose members are object files. The linker handles an archive file by
-scanning through it for members which define symbols that have so far
-been referenced but not defined. But if the file that is found is an
-ordinary object file, it is linked in the usual fashion. The only
-difference between using an \fB\-l\fR option and specifying a file name
-is that \fB\-l\fR surrounds \fIlibrary\fR with \fBlib\fR and \fB.a\fR
-and searches several directories.
-.IP "\fB\-lobjc\fR" 4
-.IX Item "-lobjc"
-You need this special case of the \fB\-l\fR option in order to
-link an Objective-C or Objective\-\*(C+ program.
-.IP "\fB\-nostartfiles\fR" 4
-.IX Item "-nostartfiles"
-Do not use the standard system startup files when linking.
-The standard system libraries are used normally, unless \fB\-nostdlib\fR
-or \fB\-nodefaultlibs\fR is used.
-.IP "\fB\-nodefaultlibs\fR" 4
-.IX Item "-nodefaultlibs"
-Do not use the standard system libraries when linking.
-Only the libraries you specify will be passed to the linker, options
-specifying linkage of the system libraries, such as \f(CW\*(C`\-static\-libgcc\*(C'\fR
-or \f(CW\*(C`\-shared\-libgcc\*(C'\fR, will be ignored.
-The standard startup files are used normally, unless \fB\-nostartfiles\fR
-is used. The compiler may generate calls to \f(CW\*(C`memcmp\*(C'\fR,
-\&\f(CW\*(C`memset\*(C'\fR, \f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR.
-These entries are usually resolved by entries in
-libc. These entry points should be supplied through some other
-mechanism when this option is specified.
-.IP "\fB\-nostdlib\fR" 4
-.IX Item "-nostdlib"
-Do not use the standard system startup files or libraries when linking.
-No startup files and only the libraries you specify will be passed to
-the linker, options specifying linkage of the system libraries, such as
-\&\f(CW\*(C`\-static\-libgcc\*(C'\fR or \f(CW\*(C`\-shared\-libgcc\*(C'\fR, will be ignored.
-The compiler may generate calls to \f(CW\*(C`memcmp\*(C'\fR, \f(CW\*(C`memset\*(C'\fR,
-\&\f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR.
-These entries are usually resolved by entries in
-libc. These entry points should be supplied through some other
-mechanism when this option is specified.
-.Sp
-One of the standard libraries bypassed by \fB\-nostdlib\fR and
-\&\fB\-nodefaultlibs\fR is \fIlibgcc.a\fR, a library of internal subroutines
-that \s-1GCC\s0 uses to overcome shortcomings of particular machines, or special
-needs for some languages.
-.Sp
-In most cases, you need \fIlibgcc.a\fR even when you want to avoid
-other standard libraries. In other words, when you specify \fB\-nostdlib\fR
-or \fB\-nodefaultlibs\fR you should usually specify \fB\-lgcc\fR as well.
-This ensures that you have no unresolved references to internal \s-1GCC\s0
-library subroutines. (For example, \fB_\|_main\fR, used to ensure \*(C+
-constructors will be called.)
-.IP "\fB\-pie\fR" 4
-.IX Item "-pie"
-Produce a position independent executable on targets which support it.
-For predictable results, you must also specify the same set of options
-that were used to generate code (\fB\-fpie\fR, \fB\-fPIE\fR,
-or model suboptions) when you specify this option.
-.IP "\fB\-rdynamic\fR" 4
-.IX Item "-rdynamic"
-Pass the flag \fB\-export\-dynamic\fR to the \s-1ELF\s0 linker, on targets
-that support it. This instructs the linker to add all symbols, not
-only used ones, to the dynamic symbol table. This option is needed
-for some uses of \f(CW\*(C`dlopen\*(C'\fR or to allow obtaining backtraces
-from within a program.
-.IP "\fB\-s\fR" 4
-.IX Item "-s"
-Remove all symbol table and relocation information from the executable.
-.IP "\fB\-static\fR" 4
-.IX Item "-static"
-On systems that support dynamic linking, this prevents linking with the shared
-libraries. On other systems, this option has no effect.
-.IP "\fB\-shared\fR" 4
-.IX Item "-shared"
-Produce a shared object which can then be linked with other objects to
-form an executable. Not all systems support this option. For predictable
-results, you must also specify the same set of options that were used to
-generate code (\fB\-fpic\fR, \fB\-fPIC\fR, or model suboptions)
-when you specify this option.[1]
-.IP "\fB\-shared\-libgcc\fR" 4
-.IX Item "-shared-libgcc"
-.PD 0
-.IP "\fB\-static\-libgcc\fR" 4
-.IX Item "-static-libgcc"
-.PD
-On systems that provide \fIlibgcc\fR as a shared library, these options
-force the use of either the shared or static version respectively.
-If no shared version of \fIlibgcc\fR was built when the compiler was
-configured, these options have no effect.
-.Sp
-There are several situations in which an application should use the
-shared \fIlibgcc\fR instead of the static version. The most common
-of these is when the application wishes to throw and catch exceptions
-across different shared libraries. In that case, each of the libraries
-as well as the application itself should use the shared \fIlibgcc\fR.
-.Sp
-Therefore, the G++ and \s-1GCJ\s0 drivers automatically add
-\&\fB\-shared\-libgcc\fR whenever you build a shared library or a main
-executable, because \*(C+ and Java programs typically use exceptions, so
-this is the right thing to do.
-.Sp
-If, instead, you use the \s-1GCC\s0 driver to create shared libraries, you may
-find that they will not always be linked with the shared \fIlibgcc\fR.
-If \s-1GCC\s0 finds, at its configuration time, that you have a non-GNU linker
-or a \s-1GNU\s0 linker that does not support option \fB\-\-eh\-frame\-hdr\fR,
-it will link the shared version of \fIlibgcc\fR into shared libraries
-by default. Otherwise, it will take advantage of the linker and optimize
-away the linking with the shared version of \fIlibgcc\fR, linking with
-the static version of libgcc by default. This allows exceptions to
-propagate through such shared libraries, without incurring relocation
-costs at library load time.
-.Sp
-However, if a library or main executable is supposed to throw or catch
-exceptions, you must link it using the G++ or \s-1GCJ\s0 driver, as appropriate
-for the languages used in the program, or using the option
-\&\fB\-shared\-libgcc\fR, such that it is linked with the shared
-\&\fIlibgcc\fR.
-.IP "\fB\-static\-libstdc++\fR" 4
-.IX Item "-static-libstdc++"
-When the \fBg++\fR program is used to link a \*(C+ program, it will
-normally automatically link against \fBlibstdc++\fR. If
-\&\fIlibstdc++\fR is available as a shared library, and the
-\&\fB\-static\fR option is not used, then this will link against the
-shared version of \fIlibstdc++\fR. That is normally fine. However, it
-is sometimes useful to freeze the version of \fIlibstdc++\fR used by
-the program without going all the way to a fully static link. The
-\&\fB\-static\-libstdc++\fR option directs the \fBg++\fR driver to
-link \fIlibstdc++\fR statically, without necessarily linking other
-libraries statically.
-.IP "\fB\-symbolic\fR" 4
-.IX Item "-symbolic"
-Bind references to global symbols when building a shared object. Warn
-about any unresolved references (unless overridden by the link editor
-option \fB\-Xlinker \-z \-Xlinker defs\fR). Only a few systems support
-this option.
-.IP "\fB\-T\fR \fIscript\fR" 4
-.IX Item "-T script"
-Use \fIscript\fR as the linker script. This option is supported by most
-systems using the \s-1GNU\s0 linker. On some targets, such as bare-board
-targets without an operating system, the \fB\-T\fR option may be required
-when linking to avoid references to undefined symbols.
-.IP "\fB\-Xlinker\fR \fIoption\fR" 4
-.IX Item "-Xlinker option"
-Pass \fIoption\fR as an option to the linker. You can use this to
-supply system-specific linker options which \s-1GCC\s0 does not know how to
-recognize.
-.Sp
-If you want to pass an option that takes a separate argument, you must use
-\&\fB\-Xlinker\fR twice, once for the option and once for the argument.
-For example, to pass \fB\-assert definitions\fR, you must write
-\&\fB\-Xlinker \-assert \-Xlinker definitions\fR. It does not work to write
-\&\fB\-Xlinker \*(L"\-assert definitions\*(R"\fR, because this passes the entire
-string as a single argument, which is not what the linker expects.
-.Sp
-When using the \s-1GNU\s0 linker, it is usually more convenient to pass
-arguments to linker options using the \fIoption\fR\fB=\fR\fIvalue\fR
-syntax than as separate arguments. For example, you can specify
-\&\fB\-Xlinker \-Map=output.map\fR rather than
-\&\fB\-Xlinker \-Map \-Xlinker output.map\fR. Other linkers may not support
-this syntax for command-line options.
-.IP "\fB\-Wl,\fR\fIoption\fR" 4
-.IX Item "-Wl,option"
-Pass \fIoption\fR as an option to the linker. If \fIoption\fR contains
-commas, it is split into multiple options at the commas. You can use this
-syntax to pass an argument to the option.
-For example, \fB\-Wl,\-Map,output.map\fR passes \fB\-Map output.map\fR to the
-linker. When using the \s-1GNU\s0 linker, you can also get the same effect with
-\&\fB\-Wl,\-Map=output.map\fR.
-.IP "\fB\-u\fR \fIsymbol\fR" 4
-.IX Item "-u symbol"
-Pretend the symbol \fIsymbol\fR is undefined, to force linking of
-library modules to define it. You can use \fB\-u\fR multiple times with
-different symbols to force loading of additional library modules.
-.SS "Options for Directory Search"
-.IX Subsection "Options for Directory Search"
-These options specify directories to search for header files, for
-libraries and for parts of the compiler:
-.IP "\fB\-I\fR\fIdir\fR" 4
-.IX Item "-Idir"
-Add the directory \fIdir\fR to the head of the list of directories to be
-searched for header files. This can be used to override a system header
-file, substituting your own version, since these directories are
-searched before the system header file directories. However, you should
-not use this option to add directories that contain vendor-supplied
-system header files (use \fB\-isystem\fR for that). If you use more than
-one \fB\-I\fR option, the directories are scanned in left-to-right
-order; the standard system directories come after.
-.Sp
-If a standard system include directory, or a directory specified with
-\&\fB\-isystem\fR, is also specified with \fB\-I\fR, the \fB\-I\fR
-option will be ignored. The directory will still be searched but as a
-system directory at its normal position in the system include chain.
-This is to ensure that \s-1GCC\s0's procedure to fix buggy system headers and
-the ordering for the include_next directive are not inadvertently changed.
-If you really need to change the search order for system directories,
-use the \fB\-nostdinc\fR and/or \fB\-isystem\fR options.
-.IP "\fB\-iplugindir=\fR\fIdir\fR" 4
-.IX Item "-iplugindir=dir"
-Set the directory to search for plugins which are passed
-by \fB\-fplugin=\fR\fIname\fR instead of
-\&\fB\-fplugin=\fR\fIpath\fR\fB/\fR\fIname\fR\fB.so\fR. This option is not meant
-to be used by the user, but only passed by the driver.
-.IP "\fB\-iquote\fR\fIdir\fR" 4
-.IX Item "-iquotedir"
-Add the directory \fIdir\fR to the head of the list of directories to
-be searched for header files only for the case of \fB#include
-"\fR\fIfile\fR\fB"\fR; they are not searched for \fB#include <\fR\fIfile\fR\fB>\fR,
-otherwise just like \fB\-I\fR.
-.IP "\fB\-L\fR\fIdir\fR" 4
-.IX Item "-Ldir"
-Add directory \fIdir\fR to the list of directories to be searched
-for \fB\-l\fR.
-.IP "\fB\-B\fR\fIprefix\fR" 4
-.IX Item "-Bprefix"
-This option specifies where to find the executables, libraries,
-include files, and data files of the compiler itself.
-.Sp
-The compiler driver program runs one or more of the subprograms
-\&\fIcpp\fR, \fIcc1\fR, \fIas\fR and \fIld\fR. It tries
-\&\fIprefix\fR as a prefix for each program it tries to run, both with and
-without \fImachine\fR\fB/\fR\fIversion\fR\fB/\fR.
-.Sp
-For each subprogram to be run, the compiler driver first tries the
-\&\fB\-B\fR prefix, if any. If that name is not found, or if \fB\-B\fR
-was not specified, the driver tries two standard prefixes, which are
-\&\fI/usr/lib/gcc/\fR and \fI/usr/local/lib/gcc/\fR. If neither of
-those results in a file name that is found, the unmodified program
-name is searched for using the directories specified in your
-\&\fB\s-1PATH\s0\fR environment variable.
-.Sp
-The compiler will check to see if the path provided by the \fB\-B\fR
-refers to a directory, and if necessary it will add a directory
-separator character at the end of the path.
-.Sp
-\&\fB\-B\fR prefixes that effectively specify directory names also apply
-to libraries in the linker, because the compiler translates these
-options into \fB\-L\fR options for the linker. They also apply to
-includes files in the preprocessor, because the compiler translates these
-options into \fB\-isystem\fR options for the preprocessor. In this case,
-the compiler appends \fBinclude\fR to the prefix.
-.Sp
-The run-time support file \fIlibgcc.a\fR can also be searched for using
-the \fB\-B\fR prefix, if needed. If it is not found there, the two
-standard prefixes above are tried, and that is all. The file is left
-out of the link if it is not found by those means.
-.Sp
-Another way to specify a prefix much like the \fB\-B\fR prefix is to use
-the environment variable \fB\s-1GCC_EXEC_PREFIX\s0\fR.
-.Sp
-As a special kludge, if the path provided by \fB\-B\fR is
-\&\fI[dir/]stage\fIN\fI/\fR, where \fIN\fR is a number in the range 0 to
-9, then it will be replaced by \fI[dir/]include\fR. This is to help
-with boot-strapping the compiler.
-.IP "\fB\-specs=\fR\fIfile\fR" 4
-.IX Item "-specs=file"
-Process \fIfile\fR after the compiler reads in the standard \fIspecs\fR
-file, in order to override the defaults that the \fIgcc\fR driver
-program uses when determining what switches to pass to \fIcc1\fR,
-\&\fIcc1plus\fR, \fIas\fR, \fIld\fR, etc. More than one
-\&\fB\-specs=\fR\fIfile\fR can be specified on the command line, and they
-are processed in order, from left to right.
-.IP "\fB\-\-sysroot=\fR\fIdir\fR" 4
-.IX Item "--sysroot=dir"
-Use \fIdir\fR as the logical root directory for headers and libraries.
-For example, if the compiler would normally search for headers in
-\&\fI/usr/include\fR and libraries in \fI/usr/lib\fR, it will instead
-search \fI\fIdir\fI/usr/include\fR and \fI\fIdir\fI/usr/lib\fR.
-.Sp
-If you use both this option and the \fB\-isysroot\fR option, then
-the \fB\-\-sysroot\fR option will apply to libraries, but the
-\&\fB\-isysroot\fR option will apply to header files.
-.Sp
-The \s-1GNU\s0 linker (beginning with version 2.16) has the necessary support
-for this option. If your linker does not support this option, the
-header file aspect of \fB\-\-sysroot\fR will still work, but the
-library aspect will not.
-.IP "\fB\-I\-\fR" 4
-.IX Item "-I-"
-This option has been deprecated. Please use \fB\-iquote\fR instead for
-\&\fB\-I\fR directories before the \fB\-I\-\fR and remove the \fB\-I\-\fR.
-Any directories you specify with \fB\-I\fR options before the \fB\-I\-\fR
-option are searched only for the case of \fB#include "\fR\fIfile\fR\fB"\fR;
-they are not searched for \fB#include <\fR\fIfile\fR\fB>\fR.
-.Sp
-If additional directories are specified with \fB\-I\fR options after
-the \fB\-I\-\fR, these directories are searched for all \fB#include\fR
-directives. (Ordinarily \fIall\fR \fB\-I\fR directories are used
-this way.)
-.Sp
-In addition, the \fB\-I\-\fR option inhibits the use of the current
-directory (where the current input file came from) as the first search
-directory for \fB#include "\fR\fIfile\fR\fB"\fR. There is no way to
-override this effect of \fB\-I\-\fR. With \fB\-I.\fR you can specify
-searching the directory which was current when the compiler was
-invoked. That is not exactly the same as what the preprocessor does
-by default, but it is often satisfactory.
-.Sp
-\&\fB\-I\-\fR does not inhibit the use of the standard system directories
-for header files. Thus, \fB\-I\-\fR and \fB\-nostdinc\fR are
-independent.
-.SS "Specifying Target Machine and Compiler Version"
-.IX Subsection "Specifying Target Machine and Compiler Version"
-The usual way to run \s-1GCC\s0 is to run the executable called \fBgcc\fR, or
-\&\fImachine\fR\fB\-gcc\fR when cross-compiling, or
-\&\fImachine\fR\fB\-gcc\-\fR\fIversion\fR to run a version other than the
-one that was installed last.
-.SS "Hardware Models and Configurations"
-.IX Subsection "Hardware Models and Configurations"
-Each target machine types can have its own
-special options, starting with \fB\-m\fR, to choose among various
-hardware models or configurations\-\-\-for example, 68010 vs 68020,
-floating coprocessor or none. A single installed version of the
-compiler can compile for any model or configuration, according to the
-options specified.
-.PP
-Some configurations of the compiler also support additional special
-options, usually for compatibility with other compilers on the same
-platform.
-.PP
-\fI\s-1ARC\s0 Options\fR
-.IX Subsection "ARC Options"
-.PP
-These options are defined for \s-1ARC\s0 implementations:
-.IP "\fB\-EL\fR" 4
-.IX Item "-EL"
-Compile code for little endian mode. This is the default.
-.IP "\fB\-EB\fR" 4
-.IX Item "-EB"
-Compile code for big endian mode.
-.IP "\fB\-mmangle\-cpu\fR" 4
-.IX Item "-mmangle-cpu"
-Prepend the name of the \s-1CPU\s0 to all public symbol names.
-In multiple-processor systems, there are many \s-1ARC\s0 variants with different
-instruction and register set characteristics. This flag prevents code
-compiled for one \s-1CPU\s0 to be linked with code compiled for another.
-No facility exists for handling variants that are \*(L"almost identical\*(R".
-This is an all or nothing option.
-.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
-.IX Item "-mcpu=cpu"
-Compile code for \s-1ARC\s0 variant \fIcpu\fR.
-Which variants are supported depend on the configuration.
-All variants support \fB\-mcpu=base\fR, this is the default.
-.IP "\fB\-mtext=\fR\fItext-section\fR" 4
-.IX Item "-mtext=text-section"
-.PD 0
-.IP "\fB\-mdata=\fR\fIdata-section\fR" 4
-.IX Item "-mdata=data-section"
-.IP "\fB\-mrodata=\fR\fIreadonly-data-section\fR" 4
-.IX Item "-mrodata=readonly-data-section"
-.PD
-Put functions, data, and readonly data in \fItext-section\fR,
-\&\fIdata-section\fR, and \fIreadonly-data-section\fR respectively
-by default. This can be overridden with the \f(CW\*(C`section\*(C'\fR attribute.
-.PP
-\fI\s-1ARM\s0 Options\fR
-.IX Subsection "ARM Options"
-.PP
-These \fB\-m\fR options are defined for Advanced \s-1RISC\s0 Machines (\s-1ARM\s0)
-architectures:
-.IP "\fB\-mabi=\fR\fIname\fR" 4
-.IX Item "-mabi=name"
-Generate code for the specified \s-1ABI\s0. Permissible values are: \fBapcs-gnu\fR,
-\&\fBatpcs\fR, \fBaapcs\fR, \fBaapcs-linux\fR and \fBiwmmxt\fR.
-.IP "\fB\-mapcs\-frame\fR" 4
-.IX Item "-mapcs-frame"
-Generate a stack frame that is compliant with the \s-1ARM\s0 Procedure Call
-Standard for all functions, even if this is not strictly necessary for
-correct execution of the code. Specifying \fB\-fomit\-frame\-pointer\fR
-with this option will cause the stack frames not to be generated for
-leaf functions. The default is \fB\-mno\-apcs\-frame\fR.
-.IP "\fB\-mapcs\fR" 4
-.IX Item "-mapcs"
-This is a synonym for \fB\-mapcs\-frame\fR.
-.IP "\fB\-mthumb\-interwork\fR" 4
-.IX Item "-mthumb-interwork"
-Generate code which supports calling between the \s-1ARM\s0 and Thumb
-instruction sets. Without this option the two instruction sets cannot
-be reliably used inside one program. The default is
-\&\fB\-mno\-thumb\-interwork\fR, since slightly larger code is generated
-when \fB\-mthumb\-interwork\fR is specified.
-.IP "\fB\-mno\-sched\-prolog\fR" 4
-.IX Item "-mno-sched-prolog"
-Prevent the reordering of instructions in the function prolog, or the
-merging of those instruction with the instructions in the function's
-body. This means that all functions will start with a recognizable set
-of instructions (or in fact one of a choice from a small set of
-different function prologues), and this information can be used to
-locate the start if functions inside an executable piece of code. The
-default is \fB\-msched\-prolog\fR.
-.IP "\fB\-mfloat\-abi=\fR\fIname\fR" 4
-.IX Item "-mfloat-abi=name"
-Specifies which floating-point \s-1ABI\s0 to use. Permissible values
-are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
-.Sp
-Specifying \fBsoft\fR causes \s-1GCC\s0 to generate output containing
-library calls for floating-point operations.
-\&\fBsoftfp\fR allows the generation of code using hardware floating-point
-instructions, but still uses the soft-float calling conventions.
-\&\fBhard\fR allows generation of floating-point instructions
-and uses FPU-specific calling conventions.
-.Sp
-The default depends on the specific target configuration. Note that
-the hard-float and soft-float ABIs are not link-compatible; you must
-compile your entire program with the same \s-1ABI\s0, and link with a
-compatible set of libraries.
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-Equivalent to \fB\-mfloat\-abi=hard\fR.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Equivalent to \fB\-mfloat\-abi=soft\fR.
-.IP "\fB\-mlittle\-endian\fR" 4
-.IX Item "-mlittle-endian"
-Generate code for a processor running in little-endian mode. This is
-the default for all standard configurations.
-.IP "\fB\-mbig\-endian\fR" 4
-.IX Item "-mbig-endian"
-Generate code for a processor running in big-endian mode; the default is
-to compile code for a little-endian processor.
-.IP "\fB\-mwords\-little\-endian\fR" 4
-.IX Item "-mwords-little-endian"
-This option only applies when generating code for big-endian processors.
-Generate code for a little-endian word order but a big-endian byte
-order. That is, a byte order of the form \fB32107654\fR. Note: this
-option should only be used if you require compatibility with code for
-big-endian \s-1ARM\s0 processors generated by versions of the compiler prior to
-2.8.
-.IP "\fB\-mcpu=\fR\fIname\fR" 4
-.IX Item "-mcpu=name"
-This specifies the name of the target \s-1ARM\s0 processor. \s-1GCC\s0 uses this name
-to determine what kind of instructions it can emit when generating
-assembly code. Permissible names are: \fBarm2\fR, \fBarm250\fR,
-\&\fBarm3\fR, \fBarm6\fR, \fBarm60\fR, \fBarm600\fR, \fBarm610\fR,
-\&\fBarm620\fR, \fBarm7\fR, \fBarm7m\fR, \fBarm7d\fR, \fBarm7dm\fR,
-\&\fBarm7di\fR, \fBarm7dmi\fR, \fBarm70\fR, \fBarm700\fR,
-\&\fBarm700i\fR, \fBarm710\fR, \fBarm710c\fR, \fBarm7100\fR,
-\&\fBarm720\fR,
-\&\fBarm7500\fR, \fBarm7500fe\fR, \fBarm7tdmi\fR, \fBarm7tdmi\-s\fR,
-\&\fBarm710t\fR, \fBarm720t\fR, \fBarm740t\fR,
-\&\fBstrongarm\fR, \fBstrongarm110\fR, \fBstrongarm1100\fR,
-\&\fBstrongarm1110\fR,
-\&\fBarm8\fR, \fBarm810\fR, \fBarm9\fR, \fBarm9e\fR, \fBarm920\fR,
-\&\fBarm920t\fR, \fBarm922t\fR, \fBarm946e\-s\fR, \fBarm966e\-s\fR,
-\&\fBarm968e\-s\fR, \fBarm926ej\-s\fR, \fBarm940t\fR, \fBarm9tdmi\fR,
-\&\fBarm10tdmi\fR, \fBarm1020t\fR, \fBarm1026ej\-s\fR,
-\&\fBarm10e\fR, \fBarm1020e\fR, \fBarm1022e\fR,
-\&\fBarm1136j\-s\fR, \fBarm1136jf\-s\fR, \fBmpcore\fR, \fBmpcorenovfp\fR,
-\&\fBarm1156t2\-s\fR, \fBarm1156t2f\-s\fR, \fBarm1176jz\-s\fR, \fBarm1176jzf\-s\fR,
-\&\fBcortex\-a5\fR, \fBcortex\-a8\fR, \fBcortex\-a9\fR, \fBcortex\-a15\fR,
-\&\fBcortex\-r4\fR, \fBcortex\-r4f\fR, \fBcortex\-m4\fR, \fBcortex\-m3\fR,
-\&\fBcortex\-m1\fR,
-\&\fBcortex\-m0\fR,
-\&\fBxscale\fR, \fBiwmmxt\fR, \fBiwmmxt2\fR, \fBep9312\fR.
-.IP "\fB\-mtune=\fR\fIname\fR" 4
-.IX Item "-mtune=name"
-This option is very similar to the \fB\-mcpu=\fR option, except that
-instead of specifying the actual target processor type, and hence
-restricting which instructions can be used, it specifies that \s-1GCC\s0 should
-tune the performance of the code as if the target were of the type
-specified in this option, but still choosing the instructions that it
-will generate based on the \s-1CPU\s0 specified by a \fB\-mcpu=\fR option.
-For some \s-1ARM\s0 implementations better performance can be obtained by using
-this option.
-.IP "\fB\-march=\fR\fIname\fR" 4
-.IX Item "-march=name"
-This specifies the name of the target \s-1ARM\s0 architecture. \s-1GCC\s0 uses this
-name to determine what kind of instructions it can emit when generating
-assembly code. This option can be used in conjunction with or instead
-of the \fB\-mcpu=\fR option. Permissible names are: \fBarmv2\fR,
-\&\fBarmv2a\fR, \fBarmv3\fR, \fBarmv3m\fR, \fBarmv4\fR, \fBarmv4t\fR,
-\&\fBarmv5\fR, \fBarmv5t\fR, \fBarmv5e\fR, \fBarmv5te\fR,
-\&\fBarmv6\fR, \fBarmv6j\fR,
-\&\fBarmv6t2\fR, \fBarmv6z\fR, \fBarmv6zk\fR, \fBarmv6\-m\fR,
-\&\fBarmv7\fR, \fBarmv7\-a\fR, \fBarmv7\-r\fR, \fBarmv7\-m\fR,
-\&\fBiwmmxt\fR, \fBiwmmxt2\fR, \fBep9312\fR.
-.IP "\fB\-mfpu=\fR\fIname\fR" 4
-.IX Item "-mfpu=name"
-.PD 0
-.IP "\fB\-mfpe=\fR\fInumber\fR" 4
-.IX Item "-mfpe=number"
-.IP "\fB\-mfp=\fR\fInumber\fR" 4
-.IX Item "-mfp=number"
-.PD
-This specifies what floating point hardware (or hardware emulation) is
-available on the target. Permissible names are: \fBfpa\fR, \fBfpe2\fR,
-\&\fBfpe3\fR, \fBmaverick\fR, \fBvfp\fR, \fBvfpv3\fR, \fBvfpv3\-fp16\fR,
-\&\fBvfpv3\-d16\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3xd\fR, \fBvfpv3xd\-fp16\fR,
-\&\fBneon\fR, \fBneon\-fp16\fR, \fBvfpv4\fR, \fBvfpv4\-d16\fR,
-\&\fBfpv4\-sp\-d16\fR and \fBneon\-vfpv4\fR.
-\&\fB\-mfp\fR and \fB\-mfpe\fR are synonyms for
-\&\fB\-mfpu\fR=\fBfpe\fR\fInumber\fR, for compatibility with older versions
-of \s-1GCC\s0.
-.Sp
-If \fB\-msoft\-float\fR is specified this specifies the format of
-floating point values.
-.Sp
-If the selected floating-point hardware includes the \s-1NEON\s0 extension
-(e.g. \fB\-mfpu\fR=\fBneon\fR), note that floating-point
-operations will not be used by \s-1GCC\s0's auto-vectorization pass unless
-\&\fB\-funsafe\-math\-optimizations\fR is also specified. This is
-because \s-1NEON\s0 hardware does not fully implement the \s-1IEEE\s0 754 standard for
-floating-point arithmetic (in particular denormal values are treated as
-zero), so the use of \s-1NEON\s0 instructions may lead to a loss of precision.
-.IP "\fB\-mfp16\-format=\fR\fIname\fR" 4
-.IX Item "-mfp16-format=name"
-Specify the format of the \f(CW\*(C`_\|_fp16\*(C'\fR half-precision floating-point type.
-Permissible names are \fBnone\fR, \fBieee\fR, and \fBalternative\fR;
-the default is \fBnone\fR, in which case the \f(CW\*(C`_\|_fp16\*(C'\fR type is not
-defined.
-.IP "\fB\-mstructure\-size\-boundary=\fR\fIn\fR" 4
-.IX Item "-mstructure-size-boundary=n"
-The size of all structures and unions will be rounded up to a multiple
-of the number of bits set by this option. Permissible values are 8, 32
-and 64. The default value varies for different toolchains. For the \s-1COFF\s0
-targeted toolchain the default value is 8. A value of 64 is only allowed
-if the underlying \s-1ABI\s0 supports it.
-.Sp
-Specifying the larger number can produce faster, more efficient code, but
-can also increase the size of the program. Different values are potentially
-incompatible. Code compiled with one value cannot necessarily expect to
-work with code or libraries compiled with another value, if they exchange
-information using structures or unions.
-.IP "\fB\-mabort\-on\-noreturn\fR" 4
-.IX Item "-mabort-on-noreturn"
-Generate a call to the function \f(CW\*(C`abort\*(C'\fR at the end of a
-\&\f(CW\*(C`noreturn\*(C'\fR function. It will be executed if the function tries to
-return.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-.PD 0
-.IP "\fB\-mno\-long\-calls\fR" 4
-.IX Item "-mno-long-calls"
-.PD
-Tells the compiler to perform function calls by first loading the
-address of the function into a register and then performing a subroutine
-call on this register. This switch is needed if the target function
-will lie outside of the 64 megabyte addressing range of the offset based
-version of subroutine call instruction.
-.Sp
-Even if this switch is enabled, not all function calls will be turned
-into long calls. The heuristic is that static functions, functions
-which have the \fBshort-call\fR attribute, functions that are inside
-the scope of a \fB#pragma no_long_calls\fR directive and functions whose
-definitions have already been compiled within the current compilation
-unit, will not be turned into long calls. The exception to this rule is
-that weak function definitions, functions with the \fBlong-call\fR
-attribute or the \fBsection\fR attribute, and functions that are within
-the scope of a \fB#pragma long_calls\fR directive, will always be
-turned into long calls.
-.Sp
-This feature is not enabled by default. Specifying
-\&\fB\-mno\-long\-calls\fR will restore the default behavior, as will
-placing the function calls within the scope of a \fB#pragma
-long_calls_off\fR directive. Note these switches have no effect on how
-the compiler generates code to handle function calls via function
-pointers.
-.IP "\fB\-msingle\-pic\-base\fR" 4
-.IX Item "-msingle-pic-base"
-Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
-loading it in the prologue for each function. The run-time system is
-responsible for initializing this register with an appropriate value
-before execution begins.
-.IP "\fB\-mpic\-register=\fR\fIreg\fR" 4
-.IX Item "-mpic-register=reg"
-Specify the register to be used for \s-1PIC\s0 addressing. The default is R10
-unless stack-checking is enabled, when R9 is used.
-.IP "\fB\-mcirrus\-fix\-invalid\-insns\fR" 4
-.IX Item "-mcirrus-fix-invalid-insns"
-Insert NOPs into the instruction stream to in order to work around
-problems with invalid Maverick instruction combinations. This option
-is only valid if the \fB\-mcpu=ep9312\fR option has been used to
-enable generation of instructions for the Cirrus Maverick floating
-point co-processor. This option is not enabled by default, since the
-problem is only present in older Maverick implementations. The default
-can be re-enabled by use of the \fB\-mno\-cirrus\-fix\-invalid\-insns\fR
-switch.
-.IP "\fB\-mpoke\-function\-name\fR" 4
-.IX Item "-mpoke-function-name"
-Write the name of each function into the text section, directly
-preceding the function prologue. The generated code is similar to this:
-.Sp
-.Vb 9
-\& t0
-\& .ascii "arm_poke_function_name", 0
-\& .align
-\& t1
-\& .word 0xff000000 + (t1 \- t0)
-\& arm_poke_function_name
-\& mov ip, sp
-\& stmfd sp!, {fp, ip, lr, pc}
-\& sub fp, ip, #4
-.Ve
-.Sp
-When performing a stack backtrace, code can inspect the value of
-\&\f(CW\*(C`pc\*(C'\fR stored at \f(CW\*(C`fp + 0\*(C'\fR. If the trace function then looks at
-location \f(CW\*(C`pc \- 12\*(C'\fR and the top 8 bits are set, then we know that
-there is a function name embedded immediately preceding this location
-and has length \f(CW\*(C`((pc[\-3]) & 0xff000000)\*(C'\fR.
-.IP "\fB\-mthumb\fR" 4
-.IX Item "-mthumb"
-Generate code for the Thumb instruction set. The default is to
-use the 32\-bit \s-1ARM\s0 instruction set.
-This option automatically enables either 16\-bit Thumb\-1 or
-mixed 16/32\-bit Thumb\-2 instructions based on the \fB\-mcpu=\fR\fIname\fR
-and \fB\-march=\fR\fIname\fR options. This option is not passed to the
-assembler. If you want to force assembler files to be interpreted as Thumb code,
-either add a \fB.thumb\fR directive to the source or pass the \fB\-mthumb\fR
-option directly to the assembler by prefixing it with \fB\-Wa\fR.
-.IP "\fB\-mtpcs\-frame\fR" 4
-.IX Item "-mtpcs-frame"
-Generate a stack frame that is compliant with the Thumb Procedure Call
-Standard for all non-leaf functions. (A leaf function is one that does
-not call any other functions.) The default is \fB\-mno\-tpcs\-frame\fR.
-.IP "\fB\-mtpcs\-leaf\-frame\fR" 4
-.IX Item "-mtpcs-leaf-frame"
-Generate a stack frame that is compliant with the Thumb Procedure Call
-Standard for all leaf functions. (A leaf function is one that does
-not call any other functions.) The default is \fB\-mno\-apcs\-leaf\-frame\fR.
-.IP "\fB\-mcallee\-super\-interworking\fR" 4
-.IX Item "-mcallee-super-interworking"
-Gives all externally visible functions in the file being compiled an \s-1ARM\s0
-instruction set header which switches to Thumb mode before executing the
-rest of the function. This allows these functions to be called from
-non-interworking code. This option is not valid in \s-1AAPCS\s0 configurations
-because interworking is enabled by default.
-.IP "\fB\-mcaller\-super\-interworking\fR" 4
-.IX Item "-mcaller-super-interworking"
-Allows calls via function pointers (including virtual functions) to
-execute correctly regardless of whether the target code has been
-compiled for interworking or not. There is a small overhead in the cost
-of executing a function pointer if this option is enabled. This option
-is not valid in \s-1AAPCS\s0 configurations because interworking is enabled
-by default.
-.IP "\fB\-mtp=\fR\fIname\fR" 4
-.IX Item "-mtp=name"
-Specify the access model for the thread local storage pointer. The valid
-models are \fBsoft\fR, which generates calls to \f(CW\*(C`_\|_aeabi_read_tp\*(C'\fR,
-\&\fBcp15\fR, which fetches the thread pointer from \f(CW\*(C`cp15\*(C'\fR directly
-(supported in the arm6k architecture), and \fBauto\fR, which uses the
-best available method for the selected processor. The default setting is
-\&\fBauto\fR.
-.IP "\fB\-mword\-relocations\fR" 4
-.IX Item "-mword-relocations"
-Only generate absolute relocations on word sized values (i.e. R_ARM_ABS32).
-This is enabled by default on targets (uClinux, SymbianOS) where the runtime
-loader imposes this restriction, and when \fB\-fpic\fR or \fB\-fPIC\fR
-is specified.
-.IP "\fB\-mfix\-cortex\-m3\-ldrd\fR" 4
-.IX Item "-mfix-cortex-m3-ldrd"
-Some Cortex\-M3 cores can cause data corruption when \f(CW\*(C`ldrd\*(C'\fR instructions
-with overlapping destination and base registers are used. This option avoids
-generating these instructions. This option is enabled by default when
-\&\fB\-mcpu=cortex\-m3\fR is specified.
-.PP
-\fI\s-1AVR\s0 Options\fR
-.IX Subsection "AVR Options"
-.PP
-These options are defined for \s-1AVR\s0 implementations:
-.IP "\fB\-mmcu=\fR\fImcu\fR" 4
-.IX Item "-mmcu=mcu"
-Specify \s-1ATMEL\s0 \s-1AVR\s0 instruction set or \s-1MCU\s0 type.
-.Sp
-Instruction set avr1 is for the minimal \s-1AVR\s0 core, not supported by the C
-compiler, only for assembler programs (\s-1MCU\s0 types: at90s1200, attiny10,
-attiny11, attiny12, attiny15, attiny28).
-.Sp
-Instruction set avr2 (default) is for the classic \s-1AVR\s0 core with up to
-8K program memory space (\s-1MCU\s0 types: at90s2313, at90s2323, attiny22,
-at90s2333, at90s2343, at90s4414, at90s4433, at90s4434, at90s8515,
-at90c8534, at90s8535).
-.Sp
-Instruction set avr3 is for the classic \s-1AVR\s0 core with up to 128K program
-memory space (\s-1MCU\s0 types: atmega103, atmega603, at43usb320, at76c711).
-.Sp
-Instruction set avr4 is for the enhanced \s-1AVR\s0 core with up to 8K program
-memory space (\s-1MCU\s0 types: atmega8, atmega83, atmega85).
-.Sp
-Instruction set avr5 is for the enhanced \s-1AVR\s0 core with up to 128K program
-memory space (\s-1MCU\s0 types: atmega16, atmega161, atmega163, atmega32, atmega323,
-atmega64, atmega128, at43usb355, at94k).
-.IP "\fB\-mno\-interrupts\fR" 4
-.IX Item "-mno-interrupts"
-Generated code is not compatible with hardware interrupts.
-Code size will be smaller.
-.IP "\fB\-mcall\-prologues\fR" 4
-.IX Item "-mcall-prologues"
-Functions prologues/epilogues expanded as call to appropriate
-subroutines. Code size will be smaller.
-.IP "\fB\-mtiny\-stack\fR" 4
-.IX Item "-mtiny-stack"
-Change only the low 8 bits of the stack pointer.
-.IP "\fB\-mint8\fR" 4
-.IX Item "-mint8"
-Assume int to be 8 bit integer. This affects the sizes of all types: A
-char will be 1 byte, an int will be 1 byte, a long will be 2 bytes
-and long long will be 4 bytes. Please note that this option does not
-comply to the C standards, but it will provide you with smaller code
-size.
-.PP
-\f(CW\*(C`EIND\*(C'\fR and Devices with more than 128k Bytes of Flash
-.IX Subsection "EIND and Devices with more than 128k Bytes of Flash"
-.PP
-Pointers in the implementation are 16 bits wide.
-The address of a function or label is represented as word address so
-that indirect jumps and calls can address any code address in the
-range of 64k words.
-.PP
-In order to faciliate indirect jump on devices with more than 128k
-bytes of program memory space, there is a special function register called
-\&\f(CW\*(C`EIND\*(C'\fR that serves as most significant part of the target address
-when \f(CW\*(C`EICALL\*(C'\fR or \f(CW\*(C`EIJMP\*(C'\fR instructions are used.
-.PP
-Indirect jumps and calls on these devices are handled as follows and
-are subject to some limitations:
-.IP "\(bu" 4
-The compiler never sets \f(CW\*(C`EIND\*(C'\fR.
-.IP "\(bu" 4
-The startup code from libgcc never sets \f(CW\*(C`EIND\*(C'\fR.
-Notice that startup code is a blend of code from libgcc and avr-libc.
-For the impact of avr-libc on \f(CW\*(C`EIND\*(C'\fR, see the
-avr-libc\ user\ manual (\f(CW\*(C`http://nongnu.org/avr\-libc/user\-manual\*(C'\fR).
-.IP "\(bu" 4
-The compiler uses \f(CW\*(C`EIND\*(C'\fR implicitely in \f(CW\*(C`EICALL\*(C'\fR/\f(CW\*(C`EIJMP\*(C'\fR
-instructions or might read \f(CW\*(C`EIND\*(C'\fR directly.
-.IP "\(bu" 4
-The compiler assumes that \f(CW\*(C`EIND\*(C'\fR never changes during the startup
-code or run of the application. In particular, \f(CW\*(C`EIND\*(C'\fR is not
-saved/restored in function or interrupt service routine
-prologue/epilogue.
-.IP "\(bu" 4
-It is legitimate for user-specific startup code to set up \f(CW\*(C`EIND\*(C'\fR
-early, for example by means of initialization code located in
-section \f(CW\*(C`.init3\*(C'\fR, and thus prior to general startup code that
-initializes \s-1RAM\s0 and calls constructors.
-.IP "\(bu" 4
-For indirect calls to functions and computed goto, the linker will
-generate \fIstubs\fR. Stubs are jump pads sometimes also called
-\&\fItrampolines\fR. Thus, the indirect call/jump will jump to such a stub.
-The stub contains a direct jump to the desired address.
-.IP "\(bu" 4
-Stubs will be generated automatically by the linker if
-the following two conditions are met:
-.RS 4
-.ie n .IP "\-<The address of a label is taken by means of the ""gs"" modifier>" 4
-.el .IP "\-<The address of a label is taken by means of the \f(CWgs\fR modifier>" 4
-.IX Item "-<The address of a label is taken by means of the gs modifier>"
-(short for \fIgenerate stubs\fR) like so:
-.Sp
-.Vb 2
-\& LDI r24, lo8(gs(<func>))
-\& LDI r25, hi8(gs(<func>))
-.Ve
-.IP "\-<The final location of that label is in a code segment>" 4
-.IX Item "-<The final location of that label is in a code segment>"
-\&\fIoutside\fR the segment where the stubs are located.
-.RE
-.RS 4
-.RE
-.IP "\(bu" 4
-The compiler will emit such \f(CW\*(C`gs\*(C'\fR modifiers for code labels in the
-following situations:
-.RS 4
-.IP "\-<Taking address of a function or code label.>" 4
-.IX Item "-<Taking address of a function or code label.>"
-.PD 0
-.IP "\-<Computed goto.>" 4
-.IX Item "-<Computed goto.>"
-.IP "\-<If prologue-save function is used, see \fB\-mcall\-prologues\fR>" 4
-.IX Item "-<If prologue-save function is used, see -mcall-prologues>"
-.PD
-command line option.
-.IP "\-<Switch/case dispatch tables. If you do not want such dispatch>" 4
-.IX Item "-<Switch/case dispatch tables. If you do not want such dispatch>"
-tables you can specify the \fB\-fno\-jump\-tables\fR command line option.
-.IP "\-<C and \*(C+ constructors/destructors called during startup/shutdown.>" 4
-.IX Item "-<C and constructors/destructors called during startup/shutdown.>"
-.PD 0
-.ie n .IP "\-<If the tools hit a ""gs()"" modifier explained above.>" 4
-.el .IP "\-<If the tools hit a \f(CWgs()\fR modifier explained above.>" 4
-.IX Item "-<If the tools hit a gs() modifier explained above.>"
-.RE
-.RS 4
-.RE
-.IP "\(bu" 4
-.PD
-The default linker script is arranged for code with \f(CW\*(C`EIND = 0\*(C'\fR.
-If code is supposed to work for a setup with \f(CW\*(C`EIND != 0\*(C'\fR, a custom
-linker script has to be used in order to place the sections whose
-name start with \f(CW\*(C`.trampolines\*(C'\fR into the segment where \f(CW\*(C`EIND\*(C'\fR
-points to.
-.IP "\(bu" 4
-Jumping to non-symbolic addresses like so is \fInot\fR supported:
-.Sp
-.Vb 5
-\& int main (void)
-\& {
-\& /* Call function at word address 0x2 */
-\& return ((int(*)(void)) 0x2)();
-\& }
-.Ve
-.Sp
-Instead, a stub has to be set up:
-.Sp
-.Vb 3
-\& int main (void)
-\& {
-\& extern int func_4 (void);
-\&
-\& /* Call function at byte address 0x4 */
-\& return func_4();
-\& }
-.Ve
-.Sp
-and the application be linked with \f(CW\*(C`\-Wl,\-\-defsym,func_4=0x4\*(C'\fR.
-Alternatively, \f(CW\*(C`func_4\*(C'\fR can be defined in the linker script.
-.PP
-\fIBlackfin Options\fR
-.IX Subsection "Blackfin Options"
-.IP "\fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR]" 4
-.IX Item "-mcpu=cpu[-sirevision]"
-Specifies the name of the target Blackfin processor. Currently, \fIcpu\fR
-can be one of \fBbf512\fR, \fBbf514\fR, \fBbf516\fR, \fBbf518\fR,
-\&\fBbf522\fR, \fBbf523\fR, \fBbf524\fR, \fBbf525\fR, \fBbf526\fR,
-\&\fBbf527\fR, \fBbf531\fR, \fBbf532\fR, \fBbf533\fR,
-\&\fBbf534\fR, \fBbf536\fR, \fBbf537\fR, \fBbf538\fR, \fBbf539\fR,
-\&\fBbf542\fR, \fBbf544\fR, \fBbf547\fR, \fBbf548\fR, \fBbf549\fR,
-\&\fBbf542m\fR, \fBbf544m\fR, \fBbf547m\fR, \fBbf548m\fR, \fBbf549m\fR,
-\&\fBbf561\fR.
-The optional \fIsirevision\fR specifies the silicon revision of the target
-Blackfin processor. Any workarounds available for the targeted silicon revision
-will be enabled. If \fIsirevision\fR is \fBnone\fR, no workarounds are enabled.
-If \fIsirevision\fR is \fBany\fR, all workarounds for the targeted processor
-will be enabled. The \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR macro is defined to two
-hexadecimal digits representing the major and minor numbers in the silicon
-revision. If \fIsirevision\fR is \fBnone\fR, the \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR
-is not defined. If \fIsirevision\fR is \fBany\fR, the
-\&\f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR is defined to be \f(CW0xffff\fR.
-If this optional \fIsirevision\fR is not used, \s-1GCC\s0 assumes the latest known
-silicon revision of the targeted Blackfin processor.
-.Sp
-Support for \fBbf561\fR is incomplete. For \fBbf561\fR,
-Only the processor macro is defined.
-Without this option, \fBbf532\fR is used as the processor by default.
-The corresponding predefined processor macros for \fIcpu\fR is to
-be defined. And for \fBbfin-elf\fR toolchain, this causes the hardware \s-1BSP\s0
-provided by libgloss to be linked in if \fB\-msim\fR is not given.
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-Specifies that the program will be run on the simulator. This causes
-the simulator \s-1BSP\s0 provided by libgloss to be linked in. This option
-has effect only for \fBbfin-elf\fR toolchain.
-Certain other options, such as \fB\-mid\-shared\-library\fR and
-\&\fB\-mfdpic\fR, imply \fB\-msim\fR.
-.IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
-.IX Item "-momit-leaf-frame-pointer"
-Don't keep the frame pointer in a register for leaf functions. This
-avoids the instructions to save, set up and restore frame pointers and
-makes an extra register available in leaf functions. The option
-\&\fB\-fomit\-frame\-pointer\fR removes the frame pointer for all functions
-which might make debugging harder.
-.IP "\fB\-mspecld\-anomaly\fR" 4
-.IX Item "-mspecld-anomaly"
-When enabled, the compiler will ensure that the generated code does not
-contain speculative loads after jump instructions. If this option is used,
-\&\f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_LOADS\*(C'\fR is defined.
-.IP "\fB\-mno\-specld\-anomaly\fR" 4
-.IX Item "-mno-specld-anomaly"
-Don't generate extra code to prevent speculative loads from occurring.
-.IP "\fB\-mcsync\-anomaly\fR" 4
-.IX Item "-mcsync-anomaly"
-When enabled, the compiler will ensure that the generated code does not
-contain \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions too soon after conditional branches.
-If this option is used, \f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_SYNCS\*(C'\fR is defined.
-.IP "\fB\-mno\-csync\-anomaly\fR" 4
-.IX Item "-mno-csync-anomaly"
-Don't generate extra code to prevent \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions from
-occurring too soon after a conditional branch.
-.IP "\fB\-mlow\-64k\fR" 4
-.IX Item "-mlow-64k"
-When enabled, the compiler is free to take advantage of the knowledge that
-the entire program fits into the low 64k of memory.
-.IP "\fB\-mno\-low\-64k\fR" 4
-.IX Item "-mno-low-64k"
-Assume that the program is arbitrarily large. This is the default.
-.IP "\fB\-mstack\-check\-l1\fR" 4
-.IX Item "-mstack-check-l1"
-Do stack checking using information placed into L1 scratchpad memory by the
-uClinux kernel.
-.IP "\fB\-mid\-shared\-library\fR" 4
-.IX Item "-mid-shared-library"
-Generate code that supports shared libraries via the library \s-1ID\s0 method.
-This allows for execute in place and shared libraries in an environment
-without virtual memory management. This option implies \fB\-fPIC\fR.
-With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
-.IP "\fB\-mno\-id\-shared\-library\fR" 4
-.IX Item "-mno-id-shared-library"
-Generate code that doesn't assume \s-1ID\s0 based shared libraries are being used.
-This is the default.
-.IP "\fB\-mleaf\-id\-shared\-library\fR" 4
-.IX Item "-mleaf-id-shared-library"
-Generate code that supports shared libraries via the library \s-1ID\s0 method,
-but assumes that this library or executable won't link against any other
-\&\s-1ID\s0 shared libraries. That allows the compiler to use faster code for jumps
-and calls.
-.IP "\fB\-mno\-leaf\-id\-shared\-library\fR" 4
-.IX Item "-mno-leaf-id-shared-library"
-Do not assume that the code being compiled won't link against any \s-1ID\s0 shared
-libraries. Slower code will be generated for jump and call insns.
-.IP "\fB\-mshared\-library\-id=n\fR" 4
-.IX Item "-mshared-library-id=n"
-Specified the identification number of the \s-1ID\s0 based shared library being
-compiled. Specifying a value of 0 will generate more compact code, specifying
-other values will force the allocation of that number to the current
-library but is no more space or time efficient than omitting this option.
-.IP "\fB\-msep\-data\fR" 4
-.IX Item "-msep-data"
-Generate code that allows the data segment to be located in a different
-area of memory from the text segment. This allows for execute in place in
-an environment without virtual memory management by eliminating relocations
-against the text section.
-.IP "\fB\-mno\-sep\-data\fR" 4
-.IX Item "-mno-sep-data"
-Generate code that assumes that the data segment follows the text segment.
-This is the default.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-.PD 0
-.IP "\fB\-mno\-long\-calls\fR" 4
-.IX Item "-mno-long-calls"
-.PD
-Tells the compiler to perform function calls by first loading the
-address of the function into a register and then performing a subroutine
-call on this register. This switch is needed if the target function
-will lie outside of the 24 bit addressing range of the offset based
-version of subroutine call instruction.
-.Sp
-This feature is not enabled by default. Specifying
-\&\fB\-mno\-long\-calls\fR will restore the default behavior. Note these
-switches have no effect on how the compiler generates code to handle
-function calls via function pointers.
-.IP "\fB\-mfast\-fp\fR" 4
-.IX Item "-mfast-fp"
-Link with the fast floating-point library. This library relaxes some of
-the \s-1IEEE\s0 floating-point standard's rules for checking inputs against
-Not-a-Number (\s-1NAN\s0), in the interest of performance.
-.IP "\fB\-minline\-plt\fR" 4
-.IX Item "-minline-plt"
-Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
-not known to bind locally. It has no effect without \fB\-mfdpic\fR.
-.IP "\fB\-mmulticore\fR" 4
-.IX Item "-mmulticore"
-Build standalone application for multicore Blackfin processor. Proper
-start files and link scripts will be used to support multicore.
-This option defines \f(CW\*(C`_\|_BFIN_MULTICORE\*(C'\fR. It can only be used with
-\&\fB\-mcpu=bf561\fR[\fB\-\fR\fIsirevision\fR]. It can be used with
-\&\fB\-mcorea\fR or \fB\-mcoreb\fR. If it's used without
-\&\fB\-mcorea\fR or \fB\-mcoreb\fR, single application/dual core
-programming model is used. In this model, the main function of Core B
-should be named as coreb_main. If it's used with \fB\-mcorea\fR or
-\&\fB\-mcoreb\fR, one application per core programming model is used.
-If this option is not used, single core application programming
-model is used.
-.IP "\fB\-mcorea\fR" 4
-.IX Item "-mcorea"
-Build standalone application for Core A of \s-1BF561\s0 when using
-one application per core programming model. Proper start files
-and link scripts will be used to support Core A. This option
-defines \f(CW\*(C`_\|_BFIN_COREA\*(C'\fR. It must be used with \fB\-mmulticore\fR.
-.IP "\fB\-mcoreb\fR" 4
-.IX Item "-mcoreb"
-Build standalone application for Core B of \s-1BF561\s0 when using
-one application per core programming model. Proper start files
-and link scripts will be used to support Core B. This option
-defines \f(CW\*(C`_\|_BFIN_COREB\*(C'\fR. When this option is used, coreb_main
-should be used instead of main. It must be used with
-\&\fB\-mmulticore\fR.
-.IP "\fB\-msdram\fR" 4
-.IX Item "-msdram"
-Build standalone application for \s-1SDRAM\s0. Proper start files and
-link scripts will be used to put the application into \s-1SDRAM\s0.
-Loader should initialize \s-1SDRAM\s0 before loading the application
-into \s-1SDRAM\s0. This option defines \f(CW\*(C`_\|_BFIN_SDRAM\*(C'\fR.
-.IP "\fB\-micplb\fR" 4
-.IX Item "-micplb"
-Assume that ICPLBs are enabled at runtime. This has an effect on certain
-anomaly workarounds. For Linux targets, the default is to assume ICPLBs
-are enabled; for standalone applications the default is off.
-.PP
-\fI\s-1CRIS\s0 Options\fR
-.IX Subsection "CRIS Options"
-.PP
-These options are defined specifically for the \s-1CRIS\s0 ports.
-.IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
-.IX Item "-march=architecture-type"
-.PD 0
-.IP "\fB\-mcpu=\fR\fIarchitecture-type\fR" 4
-.IX Item "-mcpu=architecture-type"
-.PD
-Generate code for the specified architecture. The choices for
-\&\fIarchitecture-type\fR are \fBv3\fR, \fBv8\fR and \fBv10\fR for
-respectively \s-1ETRAX\s0\ 4, \s-1ETRAX\s0\ 100, and \s-1ETRAX\s0\ 100\ \s-1LX\s0.
-Default is \fBv0\fR except for cris-axis-linux-gnu, where the default is
-\&\fBv10\fR.
-.IP "\fB\-mtune=\fR\fIarchitecture-type\fR" 4
-.IX Item "-mtune=architecture-type"
-Tune to \fIarchitecture-type\fR everything applicable about the generated
-code, except for the \s-1ABI\s0 and the set of available instructions. The
-choices for \fIarchitecture-type\fR are the same as for
-\&\fB\-march=\fR\fIarchitecture-type\fR.
-.IP "\fB\-mmax\-stack\-frame=\fR\fIn\fR" 4
-.IX Item "-mmax-stack-frame=n"
-Warn when the stack frame of a function exceeds \fIn\fR bytes.
-.IP "\fB\-metrax4\fR" 4
-.IX Item "-metrax4"
-.PD 0
-.IP "\fB\-metrax100\fR" 4
-.IX Item "-metrax100"
-.PD
-The options \fB\-metrax4\fR and \fB\-metrax100\fR are synonyms for
-\&\fB\-march=v3\fR and \fB\-march=v8\fR respectively.
-.IP "\fB\-mmul\-bug\-workaround\fR" 4
-.IX Item "-mmul-bug-workaround"
-.PD 0
-.IP "\fB\-mno\-mul\-bug\-workaround\fR" 4
-.IX Item "-mno-mul-bug-workaround"
-.PD
-Work around a bug in the \f(CW\*(C`muls\*(C'\fR and \f(CW\*(C`mulu\*(C'\fR instructions for \s-1CPU\s0
-models where it applies. This option is active by default.
-.IP "\fB\-mpdebug\fR" 4
-.IX Item "-mpdebug"
-Enable CRIS-specific verbose debug-related information in the assembly
-code. This option also has the effect to turn off the \fB#NO_APP\fR
-formatted-code indicator to the assembler at the beginning of the
-assembly file.
-.IP "\fB\-mcc\-init\fR" 4
-.IX Item "-mcc-init"
-Do not use condition-code results from previous instruction; always emit
-compare and test instructions before use of condition codes.
-.IP "\fB\-mno\-side\-effects\fR" 4
-.IX Item "-mno-side-effects"
-Do not emit instructions with side-effects in addressing modes other than
-post-increment.
-.IP "\fB\-mstack\-align\fR" 4
-.IX Item "-mstack-align"
-.PD 0
-.IP "\fB\-mno\-stack\-align\fR" 4
-.IX Item "-mno-stack-align"
-.IP "\fB\-mdata\-align\fR" 4
-.IX Item "-mdata-align"
-.IP "\fB\-mno\-data\-align\fR" 4
-.IX Item "-mno-data-align"
-.IP "\fB\-mconst\-align\fR" 4
-.IX Item "-mconst-align"
-.IP "\fB\-mno\-const\-align\fR" 4
-.IX Item "-mno-const-align"
-.PD
-These options (no-options) arranges (eliminate arrangements) for the
-stack-frame, individual data and constants to be aligned for the maximum
-single data access size for the chosen \s-1CPU\s0 model. The default is to
-arrange for 32\-bit alignment. \s-1ABI\s0 details such as structure layout are
-not affected by these options.
-.IP "\fB\-m32\-bit\fR" 4
-.IX Item "-m32-bit"
-.PD 0
-.IP "\fB\-m16\-bit\fR" 4
-.IX Item "-m16-bit"
-.IP "\fB\-m8\-bit\fR" 4
-.IX Item "-m8-bit"
-.PD
-Similar to the stack\- data\- and const-align options above, these options
-arrange for stack-frame, writable data and constants to all be 32\-bit,
-16\-bit or 8\-bit aligned. The default is 32\-bit alignment.
-.IP "\fB\-mno\-prologue\-epilogue\fR" 4
-.IX Item "-mno-prologue-epilogue"
-.PD 0
-.IP "\fB\-mprologue\-epilogue\fR" 4
-.IX Item "-mprologue-epilogue"
-.PD
-With \fB\-mno\-prologue\-epilogue\fR, the normal function prologue and
-epilogue that sets up the stack-frame are omitted and no return
-instructions or return sequences are generated in the code. Use this
-option only together with visual inspection of the compiled code: no
-warnings or errors are generated when call-saved registers must be saved,
-or storage for local variable needs to be allocated.
-.IP "\fB\-mno\-gotplt\fR" 4
-.IX Item "-mno-gotplt"
-.PD 0
-.IP "\fB\-mgotplt\fR" 4
-.IX Item "-mgotplt"
-.PD
-With \fB\-fpic\fR and \fB\-fPIC\fR, don't generate (do generate)
-instruction sequences that load addresses for functions from the \s-1PLT\s0 part
-of the \s-1GOT\s0 rather than (traditional on other architectures) calls to the
-\&\s-1PLT\s0. The default is \fB\-mgotplt\fR.
-.IP "\fB\-melf\fR" 4
-.IX Item "-melf"
-Legacy no-op option only recognized with the cris-axis-elf and
-cris-axis-linux-gnu targets.
-.IP "\fB\-mlinux\fR" 4
-.IX Item "-mlinux"
-Legacy no-op option only recognized with the cris-axis-linux-gnu target.
-.IP "\fB\-sim\fR" 4
-.IX Item "-sim"
-This option, recognized for the cris-axis-elf arranges
-to link with input-output functions from a simulator library. Code,
-initialized data and zero-initialized data are allocated consecutively.
-.IP "\fB\-sim2\fR" 4
-.IX Item "-sim2"
-Like \fB\-sim\fR, but pass linker options to locate initialized data at
-0x40000000 and zero-initialized data at 0x80000000.
-.PP
-\fI\s-1CRX\s0 Options\fR
-.IX Subsection "CRX Options"
-.PP
-These options are defined specifically for the \s-1CRX\s0 ports.
-.IP "\fB\-mmac\fR" 4
-.IX Item "-mmac"
-Enable the use of multiply-accumulate instructions. Disabled by default.
-.IP "\fB\-mpush\-args\fR" 4
-.IX Item "-mpush-args"
-Push instructions will be used to pass outgoing arguments when functions
-are called. Enabled by default.
-.PP
-\fIDarwin Options\fR
-.IX Subsection "Darwin Options"
-.PP
-These options are defined for all architectures running the Darwin operating
-system.
-.PP
-\&\s-1FSF\s0 \s-1GCC\s0 on Darwin does not create \*(L"fat\*(R" object files; it will create
-an object file for the single architecture that it was built to
-target. Apple's \s-1GCC\s0 on Darwin does create \*(L"fat\*(R" files if multiple
-\&\fB\-arch\fR options are used; it does so by running the compiler or
-linker multiple times and joining the results together with
-\&\fIlipo\fR.
-.PP
-The subtype of the file created (like \fBppc7400\fR or \fBppc970\fR or
-\&\fBi686\fR) is determined by the flags that specify the \s-1ISA\s0
-that \s-1GCC\s0 is targetting, like \fB\-mcpu\fR or \fB\-march\fR. The
-\&\fB\-force_cpusubtype_ALL\fR option can be used to override this.
-.PP
-The Darwin tools vary in their behavior when presented with an \s-1ISA\s0
-mismatch. The assembler, \fIas\fR, will only permit instructions to
-be used that are valid for the subtype of the file it is generating,
-so you cannot put 64\-bit instructions in a \fBppc750\fR object file.
-The linker for shared libraries, \fI/usr/bin/libtool\fR, will fail
-and print an error if asked to create a shared library with a less
-restrictive subtype than its input files (for instance, trying to put
-a \fBppc970\fR object file in a \fBppc7400\fR library). The linker
-for executables, \fIld\fR, will quietly give the executable the most
-restrictive subtype of any of its input files.
-.IP "\fB\-F\fR\fIdir\fR" 4
-.IX Item "-Fdir"
-Add the framework directory \fIdir\fR to the head of the list of
-directories to be searched for header files. These directories are
-interleaved with those specified by \fB\-I\fR options and are
-scanned in a left-to-right order.
-.Sp
-A framework directory is a directory with frameworks in it. A
-framework is a directory with a \fB\*(L"Headers\*(R"\fR and/or
-\&\fB\*(L"PrivateHeaders\*(R"\fR directory contained directly in it that ends
-in \fB\*(L".framework\*(R"\fR. The name of a framework is the name of this
-directory excluding the \fB\*(L".framework\*(R"\fR. Headers associated with
-the framework are found in one of those two directories, with
-\&\fB\*(L"Headers\*(R"\fR being searched first. A subframework is a framework
-directory that is in a framework's \fB\*(L"Frameworks\*(R"\fR directory.
-Includes of subframework headers can only appear in a header of a
-framework that contains the subframework, or in a sibling subframework
-header. Two subframeworks are siblings if they occur in the same
-framework. A subframework should not have the same name as a
-framework, a warning will be issued if this is violated. Currently a
-subframework cannot have subframeworks, in the future, the mechanism
-may be extended to support this. The standard frameworks can be found
-in \fB\*(L"/System/Library/Frameworks\*(R"\fR and
-\&\fB\*(L"/Library/Frameworks\*(R"\fR. An example include looks like
-\&\f(CW\*(C`#include <Framework/header.h>\*(C'\fR, where \fBFramework\fR denotes
-the name of the framework and header.h is found in the
-\&\fB\*(L"PrivateHeaders\*(R"\fR or \fB\*(L"Headers\*(R"\fR directory.
-.IP "\fB\-iframework\fR\fIdir\fR" 4
-.IX Item "-iframeworkdir"
-Like \fB\-F\fR except the directory is a treated as a system
-directory. The main difference between this \fB\-iframework\fR and
-\&\fB\-F\fR is that with \fB\-iframework\fR the compiler does not
-warn about constructs contained within header files found via
-\&\fIdir\fR. This option is valid only for the C family of languages.
-.IP "\fB\-gused\fR" 4
-.IX Item "-gused"
-Emit debugging information for symbols that are used. For \s-1STABS\s0
-debugging format, this enables \fB\-feliminate\-unused\-debug\-symbols\fR.
-This is by default \s-1ON\s0.
-.IP "\fB\-gfull\fR" 4
-.IX Item "-gfull"
-Emit debugging information for all symbols and types.
-.IP "\fB\-mmacosx\-version\-min=\fR\fIversion\fR" 4
-.IX Item "-mmacosx-version-min=version"
-The earliest version of MacOS X that this executable will run on
-is \fIversion\fR. Typical values of \fIversion\fR include \f(CW10.1\fR,
-\&\f(CW10.2\fR, and \f(CW10.3.9\fR.
-.Sp
-If the compiler was built to use the system's headers by default,
-then the default for this option is the system version on which the
-compiler is running, otherwise the default is to make choices which
-are compatible with as many systems and code bases as possible.
-.IP "\fB\-mkernel\fR" 4
-.IX Item "-mkernel"
-Enable kernel development mode. The \fB\-mkernel\fR option sets
-\&\fB\-static\fR, \fB\-fno\-common\fR, \fB\-fno\-cxa\-atexit\fR,
-\&\fB\-fno\-exceptions\fR, \fB\-fno\-non\-call\-exceptions\fR,
-\&\fB\-fapple\-kext\fR, \fB\-fno\-weak\fR and \fB\-fno\-rtti\fR where
-applicable. This mode also sets \fB\-mno\-altivec\fR,
-\&\fB\-msoft\-float\fR, \fB\-fno\-builtin\fR and
-\&\fB\-mlong\-branch\fR for PowerPC targets.
-.IP "\fB\-mone\-byte\-bool\fR" 4
-.IX Item "-mone-byte-bool"
-Override the defaults for \fBbool\fR so that \fBsizeof(bool)==1\fR.
-By default \fBsizeof(bool)\fR is \fB4\fR when compiling for
-Darwin/PowerPC and \fB1\fR when compiling for Darwin/x86, so this
-option has no effect on x86.
-.Sp
-\&\fBWarning:\fR The \fB\-mone\-byte\-bool\fR switch causes \s-1GCC\s0
-to generate code that is not binary compatible with code generated
-without that switch. Using this switch may require recompiling all
-other modules in a program, including system libraries. Use this
-switch to conform to a non-default data model.
-.IP "\fB\-mfix\-and\-continue\fR" 4
-.IX Item "-mfix-and-continue"
-.PD 0
-.IP "\fB\-ffix\-and\-continue\fR" 4
-.IX Item "-ffix-and-continue"
-.IP "\fB\-findirect\-data\fR" 4
-.IX Item "-findirect-data"
-.PD
-Generate code suitable for fast turn around development. Needed to
-enable gdb to dynamically load \f(CW\*(C`.o\*(C'\fR files into already running
-programs. \fB\-findirect\-data\fR and \fB\-ffix\-and\-continue\fR
-are provided for backwards compatibility.
-.IP "\fB\-all_load\fR" 4
-.IX Item "-all_load"
-Loads all members of static archive libraries.
-See man \fIld\fR\|(1) for more information.
-.IP "\fB\-arch_errors_fatal\fR" 4
-.IX Item "-arch_errors_fatal"
-Cause the errors having to do with files that have the wrong architecture
-to be fatal.
-.IP "\fB\-bind_at_load\fR" 4
-.IX Item "-bind_at_load"
-Causes the output file to be marked such that the dynamic linker will
-bind all undefined references when the file is loaded or launched.
-.IP "\fB\-bundle\fR" 4
-.IX Item "-bundle"
-Produce a Mach-o bundle format file.
-See man \fIld\fR\|(1) for more information.
-.IP "\fB\-bundle_loader\fR \fIexecutable\fR" 4
-.IX Item "-bundle_loader executable"
-This option specifies the \fIexecutable\fR that will be loading the build
-output file being linked. See man \fIld\fR\|(1) for more information.
-.IP "\fB\-dynamiclib\fR" 4
-.IX Item "-dynamiclib"
-When passed this option, \s-1GCC\s0 will produce a dynamic library instead of
-an executable when linking, using the Darwin \fIlibtool\fR command.
-.IP "\fB\-force_cpusubtype_ALL\fR" 4
-.IX Item "-force_cpusubtype_ALL"
-This causes \s-1GCC\s0's output file to have the \fI\s-1ALL\s0\fR subtype, instead of
-one controlled by the \fB\-mcpu\fR or \fB\-march\fR option.
-.IP "\fB\-allowable_client\fR \fIclient_name\fR" 4
-.IX Item "-allowable_client client_name"
-.PD 0
-.IP "\fB\-client_name\fR" 4
-.IX Item "-client_name"
-.IP "\fB\-compatibility_version\fR" 4
-.IX Item "-compatibility_version"
-.IP "\fB\-current_version\fR" 4
-.IX Item "-current_version"
-.IP "\fB\-dead_strip\fR" 4
-.IX Item "-dead_strip"
-.IP "\fB\-dependency\-file\fR" 4
-.IX Item "-dependency-file"
-.IP "\fB\-dylib_file\fR" 4
-.IX Item "-dylib_file"
-.IP "\fB\-dylinker_install_name\fR" 4
-.IX Item "-dylinker_install_name"
-.IP "\fB\-dynamic\fR" 4
-.IX Item "-dynamic"
-.IP "\fB\-exported_symbols_list\fR" 4
-.IX Item "-exported_symbols_list"
-.IP "\fB\-filelist\fR" 4
-.IX Item "-filelist"
-.IP "\fB\-flat_namespace\fR" 4
-.IX Item "-flat_namespace"
-.IP "\fB\-force_flat_namespace\fR" 4
-.IX Item "-force_flat_namespace"
-.IP "\fB\-headerpad_max_install_names\fR" 4
-.IX Item "-headerpad_max_install_names"
-.IP "\fB\-image_base\fR" 4
-.IX Item "-image_base"
-.IP "\fB\-init\fR" 4
-.IX Item "-init"
-.IP "\fB\-install_name\fR" 4
-.IX Item "-install_name"
-.IP "\fB\-keep_private_externs\fR" 4
-.IX Item "-keep_private_externs"
-.IP "\fB\-multi_module\fR" 4
-.IX Item "-multi_module"
-.IP "\fB\-multiply_defined\fR" 4
-.IX Item "-multiply_defined"
-.IP "\fB\-multiply_defined_unused\fR" 4
-.IX Item "-multiply_defined_unused"
-.IP "\fB\-noall_load\fR" 4
-.IX Item "-noall_load"
-.IP "\fB\-no_dead_strip_inits_and_terms\fR" 4
-.IX Item "-no_dead_strip_inits_and_terms"
-.IP "\fB\-nofixprebinding\fR" 4
-.IX Item "-nofixprebinding"
-.IP "\fB\-nomultidefs\fR" 4
-.IX Item "-nomultidefs"
-.IP "\fB\-noprebind\fR" 4
-.IX Item "-noprebind"
-.IP "\fB\-noseglinkedit\fR" 4
-.IX Item "-noseglinkedit"
-.IP "\fB\-pagezero_size\fR" 4
-.IX Item "-pagezero_size"
-.IP "\fB\-prebind\fR" 4
-.IX Item "-prebind"
-.IP "\fB\-prebind_all_twolevel_modules\fR" 4
-.IX Item "-prebind_all_twolevel_modules"
-.IP "\fB\-private_bundle\fR" 4
-.IX Item "-private_bundle"
-.IP "\fB\-read_only_relocs\fR" 4
-.IX Item "-read_only_relocs"
-.IP "\fB\-sectalign\fR" 4
-.IX Item "-sectalign"
-.IP "\fB\-sectobjectsymbols\fR" 4
-.IX Item "-sectobjectsymbols"
-.IP "\fB\-whyload\fR" 4
-.IX Item "-whyload"
-.IP "\fB\-seg1addr\fR" 4
-.IX Item "-seg1addr"
-.IP "\fB\-sectcreate\fR" 4
-.IX Item "-sectcreate"
-.IP "\fB\-sectobjectsymbols\fR" 4
-.IX Item "-sectobjectsymbols"
-.IP "\fB\-sectorder\fR" 4
-.IX Item "-sectorder"
-.IP "\fB\-segaddr\fR" 4
-.IX Item "-segaddr"
-.IP "\fB\-segs_read_only_addr\fR" 4
-.IX Item "-segs_read_only_addr"
-.IP "\fB\-segs_read_write_addr\fR" 4
-.IX Item "-segs_read_write_addr"
-.IP "\fB\-seg_addr_table\fR" 4
-.IX Item "-seg_addr_table"
-.IP "\fB\-seg_addr_table_filename\fR" 4
-.IX Item "-seg_addr_table_filename"
-.IP "\fB\-seglinkedit\fR" 4
-.IX Item "-seglinkedit"
-.IP "\fB\-segprot\fR" 4
-.IX Item "-segprot"
-.IP "\fB\-segs_read_only_addr\fR" 4
-.IX Item "-segs_read_only_addr"
-.IP "\fB\-segs_read_write_addr\fR" 4
-.IX Item "-segs_read_write_addr"
-.IP "\fB\-single_module\fR" 4
-.IX Item "-single_module"
-.IP "\fB\-static\fR" 4
-.IX Item "-static"
-.IP "\fB\-sub_library\fR" 4
-.IX Item "-sub_library"
-.IP "\fB\-sub_umbrella\fR" 4
-.IX Item "-sub_umbrella"
-.IP "\fB\-twolevel_namespace\fR" 4
-.IX Item "-twolevel_namespace"
-.IP "\fB\-umbrella\fR" 4
-.IX Item "-umbrella"
-.IP "\fB\-undefined\fR" 4
-.IX Item "-undefined"
-.IP "\fB\-unexported_symbols_list\fR" 4
-.IX Item "-unexported_symbols_list"
-.IP "\fB\-weak_reference_mismatches\fR" 4
-.IX Item "-weak_reference_mismatches"
-.IP "\fB\-whatsloaded\fR" 4
-.IX Item "-whatsloaded"
-.PD
-These options are passed to the Darwin linker. The Darwin linker man page
-describes them in detail.
-.PP
-\fI\s-1DEC\s0 Alpha Options\fR
-.IX Subsection "DEC Alpha Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1DEC\s0 Alpha implementations:
-.IP "\fB\-mno\-soft\-float\fR" 4
-.IX Item "-mno-soft-float"
-.PD 0
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-.PD
-Use (do not use) the hardware floating-point instructions for
-floating-point operations. When \fB\-msoft\-float\fR is specified,
-functions in \fIlibgcc.a\fR will be used to perform floating-point
-operations. Unless they are replaced by routines that emulate the
-floating-point operations, or compiled in such a way as to call such
-emulations routines, these routines will issue floating-point
-operations. If you are compiling for an Alpha without floating-point
-operations, you must ensure that the library is built so as not to call
-them.
-.Sp
-Note that Alpha implementations without floating-point operations are
-required to have floating-point registers.
-.IP "\fB\-mfp\-reg\fR" 4
-.IX Item "-mfp-reg"
-.PD 0
-.IP "\fB\-mno\-fp\-regs\fR" 4
-.IX Item "-mno-fp-regs"
-.PD
-Generate code that uses (does not use) the floating-point register set.
-\&\fB\-mno\-fp\-regs\fR implies \fB\-msoft\-float\fR. If the floating-point
-register set is not used, floating point operands are passed in integer
-registers as if they were integers and floating-point results are passed
-in \f(CW$0\fR instead of \f(CW$f0\fR. This is a non-standard calling sequence,
-so any function with a floating-point argument or return value called by code
-compiled with \fB\-mno\-fp\-regs\fR must also be compiled with that
-option.
-.Sp
-A typical use of this option is building a kernel that does not use,
-and hence need not save and restore, any floating-point registers.
-.IP "\fB\-mieee\fR" 4
-.IX Item "-mieee"
-The Alpha architecture implements floating-point hardware optimized for
-maximum performance. It is mostly compliant with the \s-1IEEE\s0 floating
-point standard. However, for full compliance, software assistance is
-required. This option generates code fully \s-1IEEE\s0 compliant code
-\&\fIexcept\fR that the \fIinexact-flag\fR is not maintained (see below).
-If this option is turned on, the preprocessor macro \f(CW\*(C`_IEEE_FP\*(C'\fR is
-defined during compilation. The resulting code is less efficient but is
-able to correctly support denormalized numbers and exceptional \s-1IEEE\s0
-values such as not-a-number and plus/minus infinity. Other Alpha
-compilers call this option \fB\-ieee_with_no_inexact\fR.
-.IP "\fB\-mieee\-with\-inexact\fR" 4
-.IX Item "-mieee-with-inexact"
-This is like \fB\-mieee\fR except the generated code also maintains
-the \s-1IEEE\s0 \fIinexact-flag\fR. Turning on this option causes the
-generated code to implement fully-compliant \s-1IEEE\s0 math. In addition to
-\&\f(CW\*(C`_IEEE_FP\*(C'\fR, \f(CW\*(C`_IEEE_FP_EXACT\*(C'\fR is defined as a preprocessor
-macro. On some Alpha implementations the resulting code may execute
-significantly slower than the code generated by default. Since there is
-very little code that depends on the \fIinexact-flag\fR, you should
-normally not specify this option. Other Alpha compilers call this
-option \fB\-ieee_with_inexact\fR.
-.IP "\fB\-mfp\-trap\-mode=\fR\fItrap-mode\fR" 4
-.IX Item "-mfp-trap-mode=trap-mode"
-This option controls what floating-point related traps are enabled.
-Other Alpha compilers call this option \fB\-fptm\fR \fItrap-mode\fR.
-The trap mode can be set to one of four values:
-.RS 4
-.IP "\fBn\fR" 4
-.IX Item "n"
-This is the default (normal) setting. The only traps that are enabled
-are the ones that cannot be disabled in software (e.g., division by zero
-trap).
-.IP "\fBu\fR" 4
-.IX Item "u"
-In addition to the traps enabled by \fBn\fR, underflow traps are enabled
-as well.
-.IP "\fBsu\fR" 4
-.IX Item "su"
-Like \fBu\fR, but the instructions are marked to be safe for software
-completion (see Alpha architecture manual for details).
-.IP "\fBsui\fR" 4
-.IX Item "sui"
-Like \fBsu\fR, but inexact traps are enabled as well.
-.RE
-.RS 4
-.RE
-.IP "\fB\-mfp\-rounding\-mode=\fR\fIrounding-mode\fR" 4
-.IX Item "-mfp-rounding-mode=rounding-mode"
-Selects the \s-1IEEE\s0 rounding mode. Other Alpha compilers call this option
-\&\fB\-fprm\fR \fIrounding-mode\fR. The \fIrounding-mode\fR can be one
-of:
-.RS 4
-.IP "\fBn\fR" 4
-.IX Item "n"
-Normal \s-1IEEE\s0 rounding mode. Floating point numbers are rounded towards
-the nearest machine number or towards the even machine number in case
-of a tie.
-.IP "\fBm\fR" 4
-.IX Item "m"
-Round towards minus infinity.
-.IP "\fBc\fR" 4
-.IX Item "c"
-Chopped rounding mode. Floating point numbers are rounded towards zero.
-.IP "\fBd\fR" 4
-.IX Item "d"
-Dynamic rounding mode. A field in the floating point control register
-(\fIfpcr\fR, see Alpha architecture reference manual) controls the
-rounding mode in effect. The C library initializes this register for
-rounding towards plus infinity. Thus, unless your program modifies the
-\&\fIfpcr\fR, \fBd\fR corresponds to round towards plus infinity.
-.RE
-.RS 4
-.RE
-.IP "\fB\-mtrap\-precision=\fR\fItrap-precision\fR" 4
-.IX Item "-mtrap-precision=trap-precision"
-In the Alpha architecture, floating point traps are imprecise. This
-means without software assistance it is impossible to recover from a
-floating trap and program execution normally needs to be terminated.
-\&\s-1GCC\s0 can generate code that can assist operating system trap handlers
-in determining the exact location that caused a floating point trap.
-Depending on the requirements of an application, different levels of
-precisions can be selected:
-.RS 4
-.IP "\fBp\fR" 4
-.IX Item "p"
-Program precision. This option is the default and means a trap handler
-can only identify which program caused a floating point exception.
-.IP "\fBf\fR" 4
-.IX Item "f"
-Function precision. The trap handler can determine the function that
-caused a floating point exception.
-.IP "\fBi\fR" 4
-.IX Item "i"
-Instruction precision. The trap handler can determine the exact
-instruction that caused a floating point exception.
-.RE
-.RS 4
-.Sp
-Other Alpha compilers provide the equivalent options called
-\&\fB\-scope_safe\fR and \fB\-resumption_safe\fR.
-.RE
-.IP "\fB\-mieee\-conformant\fR" 4
-.IX Item "-mieee-conformant"
-This option marks the generated code as \s-1IEEE\s0 conformant. You must not
-use this option unless you also specify \fB\-mtrap\-precision=i\fR and either
-\&\fB\-mfp\-trap\-mode=su\fR or \fB\-mfp\-trap\-mode=sui\fR. Its only effect
-is to emit the line \fB.eflag 48\fR in the function prologue of the
-generated assembly file. Under \s-1DEC\s0 Unix, this has the effect that
-IEEE-conformant math library routines will be linked in.
-.IP "\fB\-mbuild\-constants\fR" 4
-.IX Item "-mbuild-constants"
-Normally \s-1GCC\s0 examines a 32\- or 64\-bit integer constant to
-see if it can construct it from smaller constants in two or three
-instructions. If it cannot, it will output the constant as a literal and
-generate code to load it from the data segment at runtime.
-.Sp
-Use this option to require \s-1GCC\s0 to construct \fIall\fR integer constants
-using code, even if it takes more instructions (the maximum is six).
-.Sp
-You would typically use this option to build a shared library dynamic
-loader. Itself a shared library, it must relocate itself in memory
-before it can find the variables and constants in its own data segment.
-.IP "\fB\-malpha\-as\fR" 4
-.IX Item "-malpha-as"
-.PD 0
-.IP "\fB\-mgas\fR" 4
-.IX Item "-mgas"
-.PD
-Select whether to generate code to be assembled by the vendor-supplied
-assembler (\fB\-malpha\-as\fR) or by the \s-1GNU\s0 assembler \fB\-mgas\fR.
-.IP "\fB\-mbwx\fR" 4
-.IX Item "-mbwx"
-.PD 0
-.IP "\fB\-mno\-bwx\fR" 4
-.IX Item "-mno-bwx"
-.IP "\fB\-mcix\fR" 4
-.IX Item "-mcix"
-.IP "\fB\-mno\-cix\fR" 4
-.IX Item "-mno-cix"
-.IP "\fB\-mfix\fR" 4
-.IX Item "-mfix"
-.IP "\fB\-mno\-fix\fR" 4
-.IX Item "-mno-fix"
-.IP "\fB\-mmax\fR" 4
-.IX Item "-mmax"
-.IP "\fB\-mno\-max\fR" 4
-.IX Item "-mno-max"
-.PD
-Indicate whether \s-1GCC\s0 should generate code to use the optional \s-1BWX\s0,
-\&\s-1CIX\s0, \s-1FIX\s0 and \s-1MAX\s0 instruction sets. The default is to use the instruction
-sets supported by the \s-1CPU\s0 type specified via \fB\-mcpu=\fR option or that
-of the \s-1CPU\s0 on which \s-1GCC\s0 was built if none was specified.
-.IP "\fB\-mfloat\-vax\fR" 4
-.IX Item "-mfloat-vax"
-.PD 0
-.IP "\fB\-mfloat\-ieee\fR" 4
-.IX Item "-mfloat-ieee"
-.PD
-Generate code that uses (does not use) \s-1VAX\s0 F and G floating point
-arithmetic instead of \s-1IEEE\s0 single and double precision.
-.IP "\fB\-mexplicit\-relocs\fR" 4
-.IX Item "-mexplicit-relocs"
-.PD 0
-.IP "\fB\-mno\-explicit\-relocs\fR" 4
-.IX Item "-mno-explicit-relocs"
-.PD
-Older Alpha assemblers provided no way to generate symbol relocations
-except via assembler macros. Use of these macros does not allow
-optimal instruction scheduling. \s-1GNU\s0 binutils as of version 2.12
-supports a new syntax that allows the compiler to explicitly mark
-which relocations should apply to which instructions. This option
-is mostly useful for debugging, as \s-1GCC\s0 detects the capabilities of
-the assembler when it is built and sets the default accordingly.
-.IP "\fB\-msmall\-data\fR" 4
-.IX Item "-msmall-data"
-.PD 0
-.IP "\fB\-mlarge\-data\fR" 4
-.IX Item "-mlarge-data"
-.PD
-When \fB\-mexplicit\-relocs\fR is in effect, static data is
-accessed via \fIgp-relative\fR relocations. When \fB\-msmall\-data\fR
-is used, objects 8 bytes long or smaller are placed in a \fIsmall data area\fR
-(the \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR sections) and are accessed via
-16\-bit relocations off of the \f(CW$gp\fR register. This limits the
-size of the small data area to 64KB, but allows the variables to be
-directly accessed via a single instruction.
-.Sp
-The default is \fB\-mlarge\-data\fR. With this option the data area
-is limited to just below 2GB. Programs that require more than 2GB of
-data must use \f(CW\*(C`malloc\*(C'\fR or \f(CW\*(C`mmap\*(C'\fR to allocate the data in the
-heap instead of in the program's data segment.
-.Sp
-When generating code for shared libraries, \fB\-fpic\fR implies
-\&\fB\-msmall\-data\fR and \fB\-fPIC\fR implies \fB\-mlarge\-data\fR.
-.IP "\fB\-msmall\-text\fR" 4
-.IX Item "-msmall-text"
-.PD 0
-.IP "\fB\-mlarge\-text\fR" 4
-.IX Item "-mlarge-text"
-.PD
-When \fB\-msmall\-text\fR is used, the compiler assumes that the
-code of the entire program (or shared library) fits in 4MB, and is
-thus reachable with a branch instruction. When \fB\-msmall\-data\fR
-is used, the compiler can assume that all local symbols share the
-same \f(CW$gp\fR value, and thus reduce the number of instructions
-required for a function call from 4 to 1.
-.Sp
-The default is \fB\-mlarge\-text\fR.
-.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
-.IX Item "-mcpu=cpu_type"
-Set the instruction set and instruction scheduling parameters for
-machine type \fIcpu_type\fR. You can specify either the \fB\s-1EV\s0\fR
-style name or the corresponding chip number. \s-1GCC\s0 supports scheduling
-parameters for the \s-1EV4\s0, \s-1EV5\s0 and \s-1EV6\s0 family of processors and will
-choose the default values for the instruction set from the processor
-you specify. If you do not specify a processor type, \s-1GCC\s0 will default
-to the processor on which the compiler was built.
-.Sp
-Supported values for \fIcpu_type\fR are
-.RS 4
-.IP "\fBev4\fR" 4
-.IX Item "ev4"
-.PD 0
-.IP "\fBev45\fR" 4
-.IX Item "ev45"
-.IP "\fB21064\fR" 4
-.IX Item "21064"
-.PD
-Schedules as an \s-1EV4\s0 and has no instruction set extensions.
-.IP "\fBev5\fR" 4
-.IX Item "ev5"
-.PD 0
-.IP "\fB21164\fR" 4
-.IX Item "21164"
-.PD
-Schedules as an \s-1EV5\s0 and has no instruction set extensions.
-.IP "\fBev56\fR" 4
-.IX Item "ev56"
-.PD 0
-.IP "\fB21164a\fR" 4
-.IX Item "21164a"
-.PD
-Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 extension.
-.IP "\fBpca56\fR" 4
-.IX Item "pca56"
-.PD 0
-.IP "\fB21164pc\fR" 4
-.IX Item "21164pc"
-.IP "\fB21164PC\fR" 4
-.IX Item "21164PC"
-.PD
-Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 and \s-1MAX\s0 extensions.
-.IP "\fBev6\fR" 4
-.IX Item "ev6"
-.PD 0
-.IP "\fB21264\fR" 4
-.IX Item "21264"
-.PD
-Schedules as an \s-1EV6\s0 and supports the \s-1BWX\s0, \s-1FIX\s0, and \s-1MAX\s0 extensions.
-.IP "\fBev67\fR" 4
-.IX Item "ev67"
-.PD 0
-.IP "\fB21264a\fR" 4
-.IX Item "21264a"
-.PD
-Schedules as an \s-1EV6\s0 and supports the \s-1BWX\s0, \s-1CIX\s0, \s-1FIX\s0, and \s-1MAX\s0 extensions.
-.RE
-.RS 4
-.Sp
-Native Linux/GNU toolchains also support the value \fBnative\fR,
-which selects the best architecture option for the host processor.
-\&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize
-the processor.
-.RE
-.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
-.IX Item "-mtune=cpu_type"
-Set only the instruction scheduling parameters for machine type
-\&\fIcpu_type\fR. The instruction set is not changed.
-.Sp
-Native Linux/GNU toolchains also support the value \fBnative\fR,
-which selects the best architecture option for the host processor.
-\&\fB\-mtune=native\fR has no effect if \s-1GCC\s0 does not recognize
-the processor.
-.IP "\fB\-mmemory\-latency=\fR\fItime\fR" 4
-.IX Item "-mmemory-latency=time"
-Sets the latency the scheduler should assume for typical memory
-references as seen by the application. This number is highly
-dependent on the memory access patterns used by the application
-and the size of the external cache on the machine.
-.Sp
-Valid options for \fItime\fR are
-.RS 4
-.IP "\fInumber\fR" 4
-.IX Item "number"
-A decimal number representing clock cycles.
-.IP "\fBL1\fR" 4
-.IX Item "L1"
-.PD 0
-.IP "\fBL2\fR" 4
-.IX Item "L2"
-.IP "\fBL3\fR" 4
-.IX Item "L3"
-.IP "\fBmain\fR" 4
-.IX Item "main"
-.PD
-The compiler contains estimates of the number of clock cycles for
-\&\*(L"typical\*(R" \s-1EV4\s0 & \s-1EV5\s0 hardware for the Level 1, 2 & 3 caches
-(also called Dcache, Scache, and Bcache), as well as to main memory.
-Note that L3 is only valid for \s-1EV5\s0.
-.RE
-.RS 4
-.RE
-.PP
-\fI\s-1DEC\s0 Alpha/VMS Options\fR
-.IX Subsection "DEC Alpha/VMS Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1DEC\s0 Alpha/VMS implementations:
-.IP "\fB\-mvms\-return\-codes\fR" 4
-.IX Item "-mvms-return-codes"
-Return \s-1VMS\s0 condition codes from main. The default is to return \s-1POSIX\s0
-style condition (e.g. error) codes.
-.IP "\fB\-mdebug\-main=\fR\fIprefix\fR" 4
-.IX Item "-mdebug-main=prefix"
-Flag the first routine whose name starts with \fIprefix\fR as the main
-routine for the debugger.
-.IP "\fB\-mmalloc64\fR" 4
-.IX Item "-mmalloc64"
-Default to 64bit memory allocation routines.
-.PP
-\fI\s-1FR30\s0 Options\fR
-.IX Subsection "FR30 Options"
-.PP
-These options are defined specifically for the \s-1FR30\s0 port.
-.IP "\fB\-msmall\-model\fR" 4
-.IX Item "-msmall-model"
-Use the small address space model. This can produce smaller code, but
-it does assume that all symbolic values and addresses will fit into a
-20\-bit range.
-.IP "\fB\-mno\-lsim\fR" 4
-.IX Item "-mno-lsim"
-Assume that run-time support has been provided and so there is no need
-to include the simulator library (\fIlibsim.a\fR) on the linker
-command line.
-.PP
-\fI\s-1FRV\s0 Options\fR
-.IX Subsection "FRV Options"
-.IP "\fB\-mgpr\-32\fR" 4
-.IX Item "-mgpr-32"
-Only use the first 32 general purpose registers.
-.IP "\fB\-mgpr\-64\fR" 4
-.IX Item "-mgpr-64"
-Use all 64 general purpose registers.
-.IP "\fB\-mfpr\-32\fR" 4
-.IX Item "-mfpr-32"
-Use only the first 32 floating point registers.
-.IP "\fB\-mfpr\-64\fR" 4
-.IX Item "-mfpr-64"
-Use all 64 floating point registers
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-Use hardware instructions for floating point operations.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Use library routines for floating point operations.
-.IP "\fB\-malloc\-cc\fR" 4
-.IX Item "-malloc-cc"
-Dynamically allocate condition code registers.
-.IP "\fB\-mfixed\-cc\fR" 4
-.IX Item "-mfixed-cc"
-Do not try to dynamically allocate condition code registers, only
-use \f(CW\*(C`icc0\*(C'\fR and \f(CW\*(C`fcc0\*(C'\fR.
-.IP "\fB\-mdword\fR" 4
-.IX Item "-mdword"
-Change \s-1ABI\s0 to use double word insns.
-.IP "\fB\-mno\-dword\fR" 4
-.IX Item "-mno-dword"
-Do not use double word instructions.
-.IP "\fB\-mdouble\fR" 4
-.IX Item "-mdouble"
-Use floating point double instructions.
-.IP "\fB\-mno\-double\fR" 4
-.IX Item "-mno-double"
-Do not use floating point double instructions.
-.IP "\fB\-mmedia\fR" 4
-.IX Item "-mmedia"
-Use media instructions.
-.IP "\fB\-mno\-media\fR" 4
-.IX Item "-mno-media"
-Do not use media instructions.
-.IP "\fB\-mmuladd\fR" 4
-.IX Item "-mmuladd"
-Use multiply and add/subtract instructions.
-.IP "\fB\-mno\-muladd\fR" 4
-.IX Item "-mno-muladd"
-Do not use multiply and add/subtract instructions.
-.IP "\fB\-mfdpic\fR" 4
-.IX Item "-mfdpic"
-Select the \s-1FDPIC\s0 \s-1ABI\s0, that uses function descriptors to represent
-pointers to functions. Without any PIC/PIE\-related options, it
-implies \fB\-fPIE\fR. With \fB\-fpic\fR or \fB\-fpie\fR, it
-assumes \s-1GOT\s0 entries and small data are within a 12\-bit range from the
-\&\s-1GOT\s0 base address; with \fB\-fPIC\fR or \fB\-fPIE\fR, \s-1GOT\s0 offsets
-are computed with 32 bits.
-With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
-.IP "\fB\-minline\-plt\fR" 4
-.IX Item "-minline-plt"
-Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
-not known to bind locally. It has no effect without \fB\-mfdpic\fR.
-It's enabled by default if optimizing for speed and compiling for
-shared libraries (i.e., \fB\-fPIC\fR or \fB\-fpic\fR), or when an
-optimization option such as \fB\-O3\fR or above is present in the
-command line.
-.IP "\fB\-mTLS\fR" 4
-.IX Item "-mTLS"
-Assume a large \s-1TLS\s0 segment when generating thread-local code.
-.IP "\fB\-mtls\fR" 4
-.IX Item "-mtls"
-Do not assume a large \s-1TLS\s0 segment when generating thread-local code.
-.IP "\fB\-mgprel\-ro\fR" 4
-.IX Item "-mgprel-ro"
-Enable the use of \f(CW\*(C`GPREL\*(C'\fR relocations in the \s-1FDPIC\s0 \s-1ABI\s0 for data
-that is known to be in read-only sections. It's enabled by default,
-except for \fB\-fpic\fR or \fB\-fpie\fR: even though it may help
-make the global offset table smaller, it trades 1 instruction for 4.
-With \fB\-fPIC\fR or \fB\-fPIE\fR, it trades 3 instructions for 4,
-one of which may be shared by multiple symbols, and it avoids the need
-for a \s-1GOT\s0 entry for the referenced symbol, so it's more likely to be a
-win. If it is not, \fB\-mno\-gprel\-ro\fR can be used to disable it.
-.IP "\fB\-multilib\-library\-pic\fR" 4
-.IX Item "-multilib-library-pic"
-Link with the (library, not \s-1FD\s0) pic libraries. It's implied by
-\&\fB\-mlibrary\-pic\fR, as well as by \fB\-fPIC\fR and
-\&\fB\-fpic\fR without \fB\-mfdpic\fR. You should never have to use
-it explicitly.
-.IP "\fB\-mlinked\-fp\fR" 4
-.IX Item "-mlinked-fp"
-Follow the \s-1EABI\s0 requirement of always creating a frame pointer whenever
-a stack frame is allocated. This option is enabled by default and can
-be disabled with \fB\-mno\-linked\-fp\fR.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-Use indirect addressing to call functions outside the current
-compilation unit. This allows the functions to be placed anywhere
-within the 32\-bit address space.
-.IP "\fB\-malign\-labels\fR" 4
-.IX Item "-malign-labels"
-Try to align labels to an 8\-byte boundary by inserting nops into the
-previous packet. This option only has an effect when \s-1VLIW\s0 packing
-is enabled. It doesn't create new packets; it merely adds nops to
-existing ones.
-.IP "\fB\-mlibrary\-pic\fR" 4
-.IX Item "-mlibrary-pic"
-Generate position-independent \s-1EABI\s0 code.
-.IP "\fB\-macc\-4\fR" 4
-.IX Item "-macc-4"
-Use only the first four media accumulator registers.
-.IP "\fB\-macc\-8\fR" 4
-.IX Item "-macc-8"
-Use all eight media accumulator registers.
-.IP "\fB\-mpack\fR" 4
-.IX Item "-mpack"
-Pack \s-1VLIW\s0 instructions.
-.IP "\fB\-mno\-pack\fR" 4
-.IX Item "-mno-pack"
-Do not pack \s-1VLIW\s0 instructions.
-.IP "\fB\-mno\-eflags\fR" 4
-.IX Item "-mno-eflags"
-Do not mark \s-1ABI\s0 switches in e_flags.
-.IP "\fB\-mcond\-move\fR" 4
-.IX Item "-mcond-move"
-Enable the use of conditional-move instructions (default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-cond\-move\fR" 4
-.IX Item "-mno-cond-move"
-Disable the use of conditional-move instructions.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mscc\fR" 4
-.IX Item "-mscc"
-Enable the use of conditional set instructions (default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-scc\fR" 4
-.IX Item "-mno-scc"
-Disable the use of conditional set instructions.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mcond\-exec\fR" 4
-.IX Item "-mcond-exec"
-Enable the use of conditional execution (default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-cond\-exec\fR" 4
-.IX Item "-mno-cond-exec"
-Disable the use of conditional execution.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mvliw\-branch\fR" 4
-.IX Item "-mvliw-branch"
-Run a pass to pack branches into \s-1VLIW\s0 instructions (default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-vliw\-branch\fR" 4
-.IX Item "-mno-vliw-branch"
-Do not run a pass to pack branches into \s-1VLIW\s0 instructions.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mmulti\-cond\-exec\fR" 4
-.IX Item "-mmulti-cond-exec"
-Enable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution
-(default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-multi\-cond\-exec\fR" 4
-.IX Item "-mno-multi-cond-exec"
-Disable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mnested\-cond\-exec\fR" 4
-.IX Item "-mnested-cond-exec"
-Enable nested conditional execution optimizations (default).
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-mno\-nested\-cond\-exec\fR" 4
-.IX Item "-mno-nested-cond-exec"
-Disable nested conditional execution optimizations.
-.Sp
-This switch is mainly for debugging the compiler and will likely be removed
-in a future version.
-.IP "\fB\-moptimize\-membar\fR" 4
-.IX Item "-moptimize-membar"
-This switch removes redundant \f(CW\*(C`membar\*(C'\fR instructions from the
-compiler generated code. It is enabled by default.
-.IP "\fB\-mno\-optimize\-membar\fR" 4
-.IX Item "-mno-optimize-membar"
-This switch disables the automatic removal of redundant \f(CW\*(C`membar\*(C'\fR
-instructions from the generated code.
-.IP "\fB\-mtomcat\-stats\fR" 4
-.IX Item "-mtomcat-stats"
-Cause gas to print out tomcat statistics.
-.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
-.IX Item "-mcpu=cpu"
-Select the processor type for which to generate code. Possible values are
-\&\fBfrv\fR, \fBfr550\fR, \fBtomcat\fR, \fBfr500\fR, \fBfr450\fR,
-\&\fBfr405\fR, \fBfr400\fR, \fBfr300\fR and \fBsimple\fR.
-.PP
-\fIGNU/Linux Options\fR
-.IX Subsection "GNU/Linux Options"
-.PP
-These \fB\-m\fR options are defined for GNU/Linux targets:
-.IP "\fB\-mglibc\fR" 4
-.IX Item "-mglibc"
-Use the \s-1GNU\s0 C library. This is the default except
-on \fB*\-*\-linux\-*uclibc*\fR and \fB*\-*\-linux\-*android*\fR targets.
-.IP "\fB\-muclibc\fR" 4
-.IX Item "-muclibc"
-Use uClibc C library. This is the default on
-\&\fB*\-*\-linux\-*uclibc*\fR targets.
-.IP "\fB\-mbionic\fR" 4
-.IX Item "-mbionic"
-Use Bionic C library. This is the default on
-\&\fB*\-*\-linux\-*android*\fR targets.
-.IP "\fB\-mandroid\fR" 4
-.IX Item "-mandroid"
-Compile code compatible with Android platform. This is the default on
-\&\fB*\-*\-linux\-*android*\fR targets.
-.Sp
-When compiling, this option enables \fB\-mbionic\fR, \fB\-fPIC\fR,
-\&\fB\-fno\-exceptions\fR and \fB\-fno\-rtti\fR by default. When linking,
-this option makes the \s-1GCC\s0 driver pass Android-specific options to the linker.
-Finally, this option causes the preprocessor macro \f(CW\*(C`_\|_ANDROID_\|_\*(C'\fR
-to be defined.
-.IP "\fB\-tno\-android\-cc\fR" 4
-.IX Item "-tno-android-cc"
-Disable compilation effects of \fB\-mandroid\fR, i.e., do not enable
-\&\fB\-mbionic\fR, \fB\-fPIC\fR, \fB\-fno\-exceptions\fR and
-\&\fB\-fno\-rtti\fR by default.
-.IP "\fB\-tno\-android\-ld\fR" 4
-.IX Item "-tno-android-ld"
-Disable linking effects of \fB\-mandroid\fR, i.e., pass standard Linux
-linking options to the linker.
-.PP
-\fIH8/300 Options\fR
-.IX Subsection "H8/300 Options"
-.PP
-These \fB\-m\fR options are defined for the H8/300 implementations:
-.IP "\fB\-mrelax\fR" 4
-.IX Item "-mrelax"
-Shorten some address references at link time, when possible; uses the
-linker option \fB\-relax\fR.
-.IP "\fB\-mh\fR" 4
-.IX Item "-mh"
-Generate code for the H8/300H.
-.IP "\fB\-ms\fR" 4
-.IX Item "-ms"
-Generate code for the H8S.
-.IP "\fB\-mn\fR" 4
-.IX Item "-mn"
-Generate code for the H8S and H8/300H in the normal mode. This switch
-must be used either with \fB\-mh\fR or \fB\-ms\fR.
-.IP "\fB\-ms2600\fR" 4
-.IX Item "-ms2600"
-Generate code for the H8S/2600. This switch must be used with \fB\-ms\fR.
-.IP "\fB\-mint32\fR" 4
-.IX Item "-mint32"
-Make \f(CW\*(C`int\*(C'\fR data 32 bits by default.
-.IP "\fB\-malign\-300\fR" 4
-.IX Item "-malign-300"
-On the H8/300H and H8S, use the same alignment rules as for the H8/300.
-The default for the H8/300H and H8S is to align longs and floats on 4
-byte boundaries.
-\&\fB\-malign\-300\fR causes them to be aligned on 2 byte boundaries.
-This option has no effect on the H8/300.
-.PP
-\fI\s-1HPPA\s0 Options\fR
-.IX Subsection "HPPA Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1HPPA\s0 family of computers:
-.IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
-.IX Item "-march=architecture-type"
-Generate code for the specified architecture. The choices for
-\&\fIarchitecture-type\fR are \fB1.0\fR for \s-1PA\s0 1.0, \fB1.1\fR for \s-1PA\s0
-1.1, and \fB2.0\fR for \s-1PA\s0 2.0 processors. Refer to
-\&\fI/usr/lib/sched.models\fR on an HP-UX system to determine the proper
-architecture option for your machine. Code compiled for lower numbered
-architectures will run on higher numbered architectures, but not the
-other way around.
-.IP "\fB\-mpa\-risc\-1\-0\fR" 4
-.IX Item "-mpa-risc-1-0"
-.PD 0
-.IP "\fB\-mpa\-risc\-1\-1\fR" 4
-.IX Item "-mpa-risc-1-1"
-.IP "\fB\-mpa\-risc\-2\-0\fR" 4
-.IX Item "-mpa-risc-2-0"
-.PD
-Synonyms for \fB\-march=1.0\fR, \fB\-march=1.1\fR, and \fB\-march=2.0\fR respectively.
-.IP "\fB\-mbig\-switch\fR" 4
-.IX Item "-mbig-switch"
-Generate code suitable for big switch tables. Use this option only if
-the assembler/linker complain about out of range branches within a switch
-table.
-.IP "\fB\-mjump\-in\-delay\fR" 4
-.IX Item "-mjump-in-delay"
-Fill delay slots of function calls with unconditional jump instructions
-by modifying the return pointer for the function call to be the target
-of the conditional jump.
-.IP "\fB\-mdisable\-fpregs\fR" 4
-.IX Item "-mdisable-fpregs"
-Prevent floating point registers from being used in any manner. This is
-necessary for compiling kernels which perform lazy context switching of
-floating point registers. If you use this option and attempt to perform
-floating point operations, the compiler will abort.
-.IP "\fB\-mdisable\-indexing\fR" 4
-.IX Item "-mdisable-indexing"
-Prevent the compiler from using indexing address modes. This avoids some
-rather obscure problems when compiling \s-1MIG\s0 generated code under \s-1MACH\s0.
-.IP "\fB\-mno\-space\-regs\fR" 4
-.IX Item "-mno-space-regs"
-Generate code that assumes the target has no space registers. This allows
-\&\s-1GCC\s0 to generate faster indirect calls and use unscaled index address modes.
-.Sp
-Such code is suitable for level 0 \s-1PA\s0 systems and kernels.
-.IP "\fB\-mfast\-indirect\-calls\fR" 4
-.IX Item "-mfast-indirect-calls"
-Generate code that assumes calls never cross space boundaries. This
-allows \s-1GCC\s0 to emit code which performs faster indirect calls.
-.Sp
-This option will not work in the presence of shared libraries or nested
-functions.
-.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
-.IX Item "-mfixed-range=register-range"
-Generate code treating the given register range as fixed registers.
-A fixed register is one that the register allocator can not use. This is
-useful when compiling kernel code. A register range is specified as
-two registers separated by a dash. Multiple register ranges can be
-specified separated by a comma.
-.IP "\fB\-mlong\-load\-store\fR" 4
-.IX Item "-mlong-load-store"
-Generate 3\-instruction load and store sequences as sometimes required by
-the HP-UX 10 linker. This is equivalent to the \fB+k\fR option to
-the \s-1HP\s0 compilers.
-.IP "\fB\-mportable\-runtime\fR" 4
-.IX Item "-mportable-runtime"
-Use the portable calling conventions proposed by \s-1HP\s0 for \s-1ELF\s0 systems.
-.IP "\fB\-mgas\fR" 4
-.IX Item "-mgas"
-Enable the use of assembler directives only \s-1GAS\s0 understands.
-.IP "\fB\-mschedule=\fR\fIcpu-type\fR" 4
-.IX Item "-mschedule=cpu-type"
-Schedule code according to the constraints for the machine type
-\&\fIcpu-type\fR. The choices for \fIcpu-type\fR are \fB700\fR
-\&\fB7100\fR, \fB7100LC\fR, \fB7200\fR, \fB7300\fR and \fB8000\fR. Refer
-to \fI/usr/lib/sched.models\fR on an HP-UX system to determine the
-proper scheduling option for your machine. The default scheduling is
-\&\fB8000\fR.
-.IP "\fB\-mlinker\-opt\fR" 4
-.IX Item "-mlinker-opt"
-Enable the optimization pass in the HP-UX linker. Note this makes symbolic
-debugging impossible. It also triggers a bug in the HP-UX 8 and HP-UX 9
-linkers in which they give bogus error messages when linking some programs.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Generate output containing library calls for floating point.
-\&\fBWarning:\fR the requisite libraries are not available for all \s-1HPPA\s0
-targets. Normally the facilities of the machine's usual C compiler are
-used, but this cannot be done directly in cross-compilation. You must make
-your own arrangements to provide suitable library functions for
-cross-compilation.
-.Sp
-\&\fB\-msoft\-float\fR changes the calling convention in the output file;
-therefore, it is only useful if you compile \fIall\fR of a program with
-this option. In particular, you need to compile \fIlibgcc.a\fR, the
-library that comes with \s-1GCC\s0, with \fB\-msoft\-float\fR in order for
-this to work.
-.IP "\fB\-msio\fR" 4
-.IX Item "-msio"
-Generate the predefine, \f(CW\*(C`_SIO\*(C'\fR, for server \s-1IO\s0. The default is
-\&\fB\-mwsio\fR. This generates the predefines, \f(CW\*(C`_\|_hp9000s700\*(C'\fR,
-\&\f(CW\*(C`_\|_hp9000s700_\|_\*(C'\fR and \f(CW\*(C`_WSIO\*(C'\fR, for workstation \s-1IO\s0. These
-options are available under HP-UX and HI-UX.
-.IP "\fB\-mgnu\-ld\fR" 4
-.IX Item "-mgnu-ld"
-Use \s-1GNU\s0 ld specific options. This passes \fB\-shared\fR to ld when
-building a shared library. It is the default when \s-1GCC\s0 is configured,
-explicitly or implicitly, with the \s-1GNU\s0 linker. This option does not
-have any affect on which ld is called, it only changes what parameters
-are passed to that ld. The ld that is called is determined by the
-\&\fB\-\-with\-ld\fR configure option, \s-1GCC\s0's program search path, and
-finally by the user's \fB\s-1PATH\s0\fR. The linker used by \s-1GCC\s0 can be printed
-using \fBwhich `gcc \-print\-prog\-name=ld`\fR. This option is only available
-on the 64 bit HP-UX \s-1GCC\s0, i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
-.IP "\fB\-mhp\-ld\fR" 4
-.IX Item "-mhp-ld"
-Use \s-1HP\s0 ld specific options. This passes \fB\-b\fR to ld when building
-a shared library and passes \fB+Accept TypeMismatch\fR to ld on all
-links. It is the default when \s-1GCC\s0 is configured, explicitly or
-implicitly, with the \s-1HP\s0 linker. This option does not have any affect on
-which ld is called, it only changes what parameters are passed to that
-ld. The ld that is called is determined by the \fB\-\-with\-ld\fR
-configure option, \s-1GCC\s0's program search path, and finally by the user's
-\&\fB\s-1PATH\s0\fR. The linker used by \s-1GCC\s0 can be printed using \fBwhich
-`gcc \-print\-prog\-name=ld`\fR. This option is only available on the 64 bit
-HP-UX \s-1GCC\s0, i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-Generate code that uses long call sequences. This ensures that a call
-is always able to reach linker generated stubs. The default is to generate
-long calls only when the distance from the call site to the beginning
-of the function or translation unit, as the case may be, exceeds a
-predefined limit set by the branch type being used. The limits for
-normal calls are 7,600,000 and 240,000 bytes, respectively for the
-\&\s-1PA\s0 2.0 and \s-1PA\s0 1.X architectures. Sibcalls are always limited at
-240,000 bytes.
-.Sp
-Distances are measured from the beginning of functions when using the
-\&\fB\-ffunction\-sections\fR option, or when using the \fB\-mgas\fR
-and \fB\-mno\-portable\-runtime\fR options together under HP-UX with
-the \s-1SOM\s0 linker.
-.Sp
-It is normally not desirable to use this option as it will degrade
-performance. However, it may be useful in large applications,
-particularly when partial linking is used to build the application.
-.Sp
-The types of long calls used depends on the capabilities of the
-assembler and linker, and the type of code being generated. The
-impact on systems that support long absolute calls, and long pic
-symbol-difference or pc-relative calls should be relatively small.
-However, an indirect call is used on 32\-bit \s-1ELF\s0 systems in pic code
-and it is quite long.
-.IP "\fB\-munix=\fR\fIunix-std\fR" 4
-.IX Item "-munix=unix-std"
-Generate compiler predefines and select a startfile for the specified
-\&\s-1UNIX\s0 standard. The choices for \fIunix-std\fR are \fB93\fR, \fB95\fR
-and \fB98\fR. \fB93\fR is supported on all HP-UX versions. \fB95\fR
-is available on HP-UX 10.10 and later. \fB98\fR is available on HP-UX
-11.11 and later. The default values are \fB93\fR for HP-UX 10.00,
-\&\fB95\fR for HP-UX 10.10 though to 11.00, and \fB98\fR for HP-UX 11.11
-and later.
-.Sp
-\&\fB\-munix=93\fR provides the same predefines as \s-1GCC\s0 3.3 and 3.4.
-\&\fB\-munix=95\fR provides additional predefines for \f(CW\*(C`XOPEN_UNIX\*(C'\fR
-and \f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, and the startfile \fIunix95.o\fR.
-\&\fB\-munix=98\fR provides additional predefines for \f(CW\*(C`_XOPEN_UNIX\*(C'\fR,
-\&\f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, \f(CW\*(C`_INCLUDE_\|_STDC_A1_SOURCE\*(C'\fR and
-\&\f(CW\*(C`_INCLUDE_XOPEN_SOURCE_500\*(C'\fR, and the startfile \fIunix98.o\fR.
-.Sp
-It is \fIimportant\fR to note that this option changes the interfaces
-for various library routines. It also affects the operational behavior
-of the C library. Thus, \fIextreme\fR care is needed in using this
-option.
-.Sp
-Library code that is intended to operate with more than one \s-1UNIX\s0
-standard must test, set and restore the variable \fI_\|_xpg4_extended_mask\fR
-as appropriate. Most \s-1GNU\s0 software doesn't provide this capability.
-.IP "\fB\-nolibdld\fR" 4
-.IX Item "-nolibdld"
-Suppress the generation of link options to search libdld.sl when the
-\&\fB\-static\fR option is specified on HP-UX 10 and later.
-.IP "\fB\-static\fR" 4
-.IX Item "-static"
-The HP-UX implementation of setlocale in libc has a dependency on
-libdld.sl. There isn't an archive version of libdld.sl. Thus,
-when the \fB\-static\fR option is specified, special link options
-are needed to resolve this dependency.
-.Sp
-On HP-UX 10 and later, the \s-1GCC\s0 driver adds the necessary options to
-link with libdld.sl when the \fB\-static\fR option is specified.
-This causes the resulting binary to be dynamic. On the 64\-bit port,
-the linkers generate dynamic binaries by default in any case. The
-\&\fB\-nolibdld\fR option can be used to prevent the \s-1GCC\s0 driver from
-adding these link options.
-.IP "\fB\-threads\fR" 4
-.IX Item "-threads"
-Add support for multithreading with the \fIdce thread\fR library
-under HP-UX. This option sets flags for both the preprocessor and
-linker.
-.PP
-\fIIntel 386 and \s-1AMD\s0 x86\-64 Options\fR
-.IX Subsection "Intel 386 and AMD x86-64 Options"
-.PP
-These \fB\-m\fR options are defined for the i386 and x86\-64 family of
-computers:
-.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
-.IX Item "-mtune=cpu-type"
-Tune to \fIcpu-type\fR everything applicable about the generated code, except
-for the \s-1ABI\s0 and the set of available instructions. The choices for
-\&\fIcpu-type\fR are:
-.RS 4
-.IP "\fIgeneric\fR" 4
-.IX Item "generic"
-Produce code optimized for the most common \s-1IA32/AMD64/EM64T\s0 processors.
-If you know the \s-1CPU\s0 on which your code will run, then you should use
-the corresponding \fB\-mtune\fR option instead of
-\&\fB\-mtune=generic\fR. But, if you do not know exactly what \s-1CPU\s0 users
-of your application will have, then you should use this option.
-.Sp
-As new processors are deployed in the marketplace, the behavior of this
-option will change. Therefore, if you upgrade to a newer version of
-\&\s-1GCC\s0, the code generated option will change to reflect the processors
-that were most common when that version of \s-1GCC\s0 was released.
-.Sp
-There is no \fB\-march=generic\fR option because \fB\-march\fR
-indicates the instruction set the compiler can use, and there is no
-generic instruction set applicable to all processors. In contrast,
-\&\fB\-mtune\fR indicates the processor (or, in this case, collection of
-processors) for which the code is optimized.
-.IP "\fInative\fR" 4
-.IX Item "native"
-This selects the \s-1CPU\s0 to tune for at compilation time by determining
-the processor type of the compiling machine. Using \fB\-mtune=native\fR
-will produce code optimized for the local machine under the constraints
-of the selected instruction set. Using \fB\-march=native\fR will
-enable all instruction subsets supported by the local machine (hence
-the result might not run on different machines).
-.IP "\fIi386\fR" 4
-.IX Item "i386"
-Original Intel's i386 \s-1CPU\s0.
-.IP "\fIi486\fR" 4
-.IX Item "i486"
-Intel's i486 \s-1CPU\s0. (No scheduling is implemented for this chip.)
-.IP "\fIi586, pentium\fR" 4
-.IX Item "i586, pentium"
-Intel Pentium \s-1CPU\s0 with no \s-1MMX\s0 support.
-.IP "\fIpentium-mmx\fR" 4
-.IX Item "pentium-mmx"
-Intel PentiumMMX \s-1CPU\s0 based on Pentium core with \s-1MMX\s0 instruction set support.
-.IP "\fIpentiumpro\fR" 4
-.IX Item "pentiumpro"
-Intel PentiumPro \s-1CPU\s0.
-.IP "\fIi686\fR" 4
-.IX Item "i686"
-Same as \f(CW\*(C`generic\*(C'\fR, but when used as \f(CW\*(C`march\*(C'\fR option, PentiumPro
-instruction set will be used, so the code will run on all i686 family chips.
-.IP "\fIpentium2\fR" 4
-.IX Item "pentium2"
-Intel Pentium2 \s-1CPU\s0 based on PentiumPro core with \s-1MMX\s0 instruction set support.
-.IP "\fIpentium3, pentium3m\fR" 4
-.IX Item "pentium3, pentium3m"
-Intel Pentium3 \s-1CPU\s0 based on PentiumPro core with \s-1MMX\s0 and \s-1SSE\s0 instruction set
-support.
-.IP "\fIpentium-m\fR" 4
-.IX Item "pentium-m"
-Low power version of Intel Pentium3 \s-1CPU\s0 with \s-1MMX\s0, \s-1SSE\s0 and \s-1SSE2\s0 instruction set
-support. Used by Centrino notebooks.
-.IP "\fIpentium4, pentium4m\fR" 4
-.IX Item "pentium4, pentium4m"
-Intel Pentium4 \s-1CPU\s0 with \s-1MMX\s0, \s-1SSE\s0 and \s-1SSE2\s0 instruction set support.
-.IP "\fIprescott\fR" 4
-.IX Item "prescott"
-Improved version of Intel Pentium4 \s-1CPU\s0 with \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0 and \s-1SSE3\s0 instruction
-set support.
-.IP "\fInocona\fR" 4
-.IX Item "nocona"
-Improved version of Intel Pentium4 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0,
-\&\s-1SSE2\s0 and \s-1SSE3\s0 instruction set support.
-.IP "\fIcore2\fR" 4
-.IX Item "core2"
-Intel Core2 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0 and \s-1SSSE3\s0
-instruction set support.
-.IP "\fIcorei7\fR" 4
-.IX Item "corei7"
-Intel Core i7 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0, \s-1SSSE3\s0, \s-1SSE4\s0.1
-and \s-1SSE4\s0.2 instruction set support.
-.IP "\fIcorei7\-avx\fR" 4
-.IX Item "corei7-avx"
-Intel Core i7 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0, \s-1SSSE3\s0,
-\&\s-1SSE4\s0.1, \s-1SSE4\s0.2, \s-1AVX\s0, \s-1AES\s0 and \s-1PCLMUL\s0 instruction set support.
-.IP "\fIcore-avx-i\fR" 4
-.IX Item "core-avx-i"
-Intel Core \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0, \s-1SSSE3\s0,
-\&\s-1SSE4\s0.1, \s-1SSE4\s0.2, \s-1AVX\s0, \s-1AES\s0, \s-1PCLMUL\s0, \s-1FSGSBASE\s0, \s-1RDRND\s0 and F16C instruction
-set support.
-.IP "\fIatom\fR" 4
-.IX Item "atom"
-Intel Atom \s-1CPU\s0 with 64\-bit extensions, \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0 and \s-1SSSE3\s0
-instruction set support.
-.IP "\fIk6\fR" 4
-.IX Item "k6"
-\&\s-1AMD\s0 K6 \s-1CPU\s0 with \s-1MMX\s0 instruction set support.
-.IP "\fIk6\-2, k6\-3\fR" 4
-.IX Item "k6-2, k6-3"
-Improved versions of \s-1AMD\s0 K6 \s-1CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
-.IP "\fIathlon, athlon-tbird\fR" 4
-.IX Item "athlon, athlon-tbird"
-\&\s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX\s0, 3dNOW!, enhanced 3DNow! and \s-1SSE\s0 prefetch instructions
-support.
-.IP "\fIathlon\-4, athlon-xp, athlon-mp\fR" 4
-.IX Item "athlon-4, athlon-xp, athlon-mp"
-Improved \s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX\s0, 3DNow!, enhanced 3DNow! and full \s-1SSE\s0
-instruction set support.
-.IP "\fIk8, opteron, athlon64, athlon-fx\fR" 4
-.IX Item "k8, opteron, athlon64, athlon-fx"
-\&\s-1AMD\s0 K8 core based CPUs with x86\-64 instruction set support. (This supersets
-\&\s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, 3DNow!, enhanced 3DNow! and 64\-bit instruction set extensions.)
-.IP "\fIk8\-sse3, opteron\-sse3, athlon64\-sse3\fR" 4
-.IX Item "k8-sse3, opteron-sse3, athlon64-sse3"
-Improved versions of k8, opteron and athlon64 with \s-1SSE3\s0 instruction set support.
-.IP "\fIamdfam10, barcelona\fR" 4
-.IX Item "amdfam10, barcelona"
-\&\s-1AMD\s0 Family 10h core based CPUs with x86\-64 instruction set support. (This
-supersets \s-1MMX\s0, \s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0, \s-1SSE4A\s0, 3DNow!, enhanced 3DNow!, \s-1ABM\s0 and 64\-bit
-instruction set extensions.)
-.IP "\fIwinchip\-c6\fR" 4
-.IX Item "winchip-c6"
-\&\s-1IDT\s0 Winchip C6 \s-1CPU\s0, dealt in same way as i486 with additional \s-1MMX\s0 instruction
-set support.
-.IP "\fIwinchip2\fR" 4
-.IX Item "winchip2"
-\&\s-1IDT\s0 Winchip2 \s-1CPU\s0, dealt in same way as i486 with additional \s-1MMX\s0 and 3DNow!
-instruction set support.
-.IP "\fIc3\fR" 4
-.IX Item "c3"
-Via C3 \s-1CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support. (No scheduling is
-implemented for this chip.)
-.IP "\fIc3\-2\fR" 4
-.IX Item "c3-2"
-Via C3\-2 \s-1CPU\s0 with \s-1MMX\s0 and \s-1SSE\s0 instruction set support. (No scheduling is
-implemented for this chip.)
-.IP "\fIgeode\fR" 4
-.IX Item "geode"
-Embedded \s-1AMD\s0 \s-1CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
-.RE
-.RS 4
-.Sp
-While picking a specific \fIcpu-type\fR will schedule things appropriately
-for that particular chip, the compiler will not generate any code that
-does not run on the i386 without the \fB\-march=\fR\fIcpu-type\fR option
-being used.
-.RE
-.IP "\fB\-march=\fR\fIcpu-type\fR" 4
-.IX Item "-march=cpu-type"
-Generate instructions for the machine type \fIcpu-type\fR. The choices
-for \fIcpu-type\fR are the same as for \fB\-mtune\fR. Moreover,
-specifying \fB\-march=\fR\fIcpu-type\fR implies \fB\-mtune=\fR\fIcpu-type\fR.
-.IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
-.IX Item "-mcpu=cpu-type"
-A deprecated synonym for \fB\-mtune\fR.
-.IP "\fB\-mfpmath=\fR\fIunit\fR" 4
-.IX Item "-mfpmath=unit"
-Generate floating point arithmetics for selected unit \fIunit\fR. The choices
-for \fIunit\fR are:
-.RS 4
-.IP "\fB387\fR" 4
-.IX Item "387"
-Use the standard 387 floating point coprocessor present majority of chips and
-emulated otherwise. Code compiled with this option will run almost everywhere.
-The temporary results are computed in 80bit precision instead of precision
-specified by the type resulting in slightly different results compared to most
-of other chips. See \fB\-ffloat\-store\fR for more detailed description.
-.Sp
-This is the default choice for i386 compiler.
-.IP "\fBsse\fR" 4
-.IX Item "sse"
-Use scalar floating point instructions present in the \s-1SSE\s0 instruction set.
-This instruction set is supported by Pentium3 and newer chips, in the \s-1AMD\s0 line
-by Athlon\-4, Athlon-xp and Athlon-mp chips. The earlier version of \s-1SSE\s0
-instruction set supports only single precision arithmetics, thus the double and
-extended precision arithmetics is still done using 387. Later version, present
-only in Pentium4 and the future \s-1AMD\s0 x86\-64 chips supports double precision
-arithmetics too.
-.Sp
-For the i386 compiler, you need to use \fB\-march=\fR\fIcpu-type\fR, \fB\-msse\fR
-or \fB\-msse2\fR switches to enable \s-1SSE\s0 extensions and make this option
-effective. For the x86\-64 compiler, these extensions are enabled by default.
-.Sp
-The resulting code should be considerably faster in the majority of cases and avoid
-the numerical instability problems of 387 code, but may break some existing
-code that expects temporaries to be 80bit.
-.Sp
-This is the default choice for the x86\-64 compiler.
-.IP "\fBsse,387\fR" 4
-.IX Item "sse,387"
-.PD 0
-.IP "\fBsse+387\fR" 4
-.IX Item "sse+387"
-.IP "\fBboth\fR" 4
-.IX Item "both"
-.PD
-Attempt to utilize both instruction sets at once. This effectively double the
-amount of available registers and on chips with separate execution units for
-387 and \s-1SSE\s0 the execution resources too. Use this option with care, as it is
-still experimental, because the \s-1GCC\s0 register allocator does not model separate
-functional units well resulting in instable performance.
-.RE
-.RS 4
-.RE
-.IP "\fB\-masm=\fR\fIdialect\fR" 4
-.IX Item "-masm=dialect"
-Output asm instructions using selected \fIdialect\fR. Supported
-choices are \fBintel\fR or \fBatt\fR (the default one). Darwin does
-not support \fBintel\fR.
-.IP "\fB\-mieee\-fp\fR" 4
-.IX Item "-mieee-fp"
-.PD 0
-.IP "\fB\-mno\-ieee\-fp\fR" 4
-.IX Item "-mno-ieee-fp"
-.PD
-Control whether or not the compiler uses \s-1IEEE\s0 floating point
-comparisons. These handle correctly the case where the result of a
-comparison is unordered.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Generate output containing library calls for floating point.
-\&\fBWarning:\fR the requisite libraries are not part of \s-1GCC\s0.
-Normally the facilities of the machine's usual C compiler are used, but
-this can't be done directly in cross-compilation. You must make your
-own arrangements to provide suitable library functions for
-cross-compilation.
-.Sp
-On machines where a function returns floating point results in the 80387
-register stack, some floating point opcodes may be emitted even if
-\&\fB\-msoft\-float\fR is used.
-.IP "\fB\-mno\-fp\-ret\-in\-387\fR" 4
-.IX Item "-mno-fp-ret-in-387"
-Do not use the \s-1FPU\s0 registers for return values of functions.
-.Sp
-The usual calling convention has functions return values of types
-\&\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR in an \s-1FPU\s0 register, even if there
-is no \s-1FPU\s0. The idea is that the operating system should emulate
-an \s-1FPU\s0.
-.Sp
-The option \fB\-mno\-fp\-ret\-in\-387\fR causes such values to be returned
-in ordinary \s-1CPU\s0 registers instead.
-.IP "\fB\-mno\-fancy\-math\-387\fR" 4
-.IX Item "-mno-fancy-math-387"
-Some 387 emulators do not support the \f(CW\*(C`sin\*(C'\fR, \f(CW\*(C`cos\*(C'\fR and
-\&\f(CW\*(C`sqrt\*(C'\fR instructions for the 387. Specify this option to avoid
-generating those instructions. This option is the default on FreeBSD,
-OpenBSD and NetBSD. This option is overridden when \fB\-march\fR
-indicates that the target \s-1CPU\s0 will always have an \s-1FPU\s0 and so the
-instruction will not need emulation. As of revision 2.6.1, these
-instructions are not generated unless you also use the
-\&\fB\-funsafe\-math\-optimizations\fR switch.
-.IP "\fB\-malign\-double\fR" 4
-.IX Item "-malign-double"
-.PD 0
-.IP "\fB\-mno\-align\-double\fR" 4
-.IX Item "-mno-align-double"
-.PD
-Control whether \s-1GCC\s0 aligns \f(CW\*(C`double\*(C'\fR, \f(CW\*(C`long double\*(C'\fR, and
-\&\f(CW\*(C`long long\*(C'\fR variables on a two word boundary or a one word
-boundary. Aligning \f(CW\*(C`double\*(C'\fR variables on a two word boundary will
-produce code that runs somewhat faster on a \fBPentium\fR at the
-expense of more memory.
-.Sp
-On x86\-64, \fB\-malign\-double\fR is enabled by default.
-.Sp
-\&\fBWarning:\fR if you use the \fB\-malign\-double\fR switch,
-structures containing the above types will be aligned differently than
-the published application binary interface specifications for the 386
-and will not be binary compatible with structures in code compiled
-without that switch.
-.IP "\fB\-m96bit\-long\-double\fR" 4
-.IX Item "-m96bit-long-double"
-.PD 0
-.IP "\fB\-m128bit\-long\-double\fR" 4
-.IX Item "-m128bit-long-double"
-.PD
-These switches control the size of \f(CW\*(C`long double\*(C'\fR type. The i386
-application binary interface specifies the size to be 96 bits,
-so \fB\-m96bit\-long\-double\fR is the default in 32 bit mode.
-.Sp
-Modern architectures (Pentium and newer) would prefer \f(CW\*(C`long double\*(C'\fR
-to be aligned to an 8 or 16 byte boundary. In arrays or structures
-conforming to the \s-1ABI\s0, this would not be possible. So specifying a
-\&\fB\-m128bit\-long\-double\fR will align \f(CW\*(C`long double\*(C'\fR
-to a 16 byte boundary by padding the \f(CW\*(C`long double\*(C'\fR with an additional
-32 bit zero.
-.Sp
-In the x86\-64 compiler, \fB\-m128bit\-long\-double\fR is the default choice as
-its \s-1ABI\s0 specifies that \f(CW\*(C`long double\*(C'\fR is to be aligned on 16 byte boundary.
-.Sp
-Notice that neither of these options enable any extra precision over the x87
-standard of 80 bits for a \f(CW\*(C`long double\*(C'\fR.
-.Sp
-\&\fBWarning:\fR if you override the default value for your target \s-1ABI\s0, the
-structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables will change
-their size as well as function calling convention for function taking
-\&\f(CW\*(C`long double\*(C'\fR will be modified. Hence they will not be binary
-compatible with arrays or structures in code compiled without that switch.
-.IP "\fB\-mlarge\-data\-threshold=\fR\fInumber\fR" 4
-.IX Item "-mlarge-data-threshold=number"
-When \fB\-mcmodel=medium\fR is specified, the data greater than
-\&\fIthreshold\fR are placed in large data section. This value must be the
-same across all object linked into the binary and defaults to 65535.
-.IP "\fB\-mrtd\fR" 4
-.IX Item "-mrtd"
-Use a different function-calling convention, in which functions that
-take a fixed number of arguments return with the \f(CW\*(C`ret\*(C'\fR \fInum\fR
-instruction, which pops their arguments while returning. This saves one
-instruction in the caller since there is no need to pop the arguments
-there.
-.Sp
-You can specify that an individual function is called with this calling
-sequence with the function attribute \fBstdcall\fR. You can also
-override the \fB\-mrtd\fR option by using the function attribute
-\&\fBcdecl\fR.
-.Sp
-\&\fBWarning:\fR this calling convention is incompatible with the one
-normally used on Unix, so you cannot use it if you need to call
-libraries compiled with the Unix compiler.
-.Sp
-Also, you must provide function prototypes for all functions that
-take variable numbers of arguments (including \f(CW\*(C`printf\*(C'\fR);
-otherwise incorrect code will be generated for calls to those
-functions.
-.Sp
-In addition, seriously incorrect code will result if you call a
-function with too many arguments. (Normally, extra arguments are
-harmlessly ignored.)
-.IP "\fB\-mregparm=\fR\fInum\fR" 4
-.IX Item "-mregparm=num"
-Control how many registers are used to pass integer arguments. By
-default, no registers are used to pass arguments, and at most 3
-registers can be used. You can control this behavior for a specific
-function by using the function attribute \fBregparm\fR.
-.Sp
-\&\fBWarning:\fR if you use this switch, and
-\&\fInum\fR is nonzero, then you must build all modules with the same
-value, including any libraries. This includes the system libraries and
-startup modules.
-.IP "\fB\-msseregparm\fR" 4
-.IX Item "-msseregparm"
-Use \s-1SSE\s0 register passing conventions for float and double arguments
-and return values. You can control this behavior for a specific
-function by using the function attribute \fBsseregparm\fR.
-.Sp
-\&\fBWarning:\fR if you use this switch then you must build all
-modules with the same value, including any libraries. This includes
-the system libraries and startup modules.
-.IP "\fB\-mvect8\-ret\-in\-mem\fR" 4
-.IX Item "-mvect8-ret-in-mem"
-Return 8\-byte vectors in memory instead of \s-1MMX\s0 registers. This is the
-default on Solaris@tie{}8 and 9 and VxWorks to match the \s-1ABI\s0 of the Sun
-Studio compilers until version 12. Later compiler versions (starting
-with Studio 12 Update@tie{}1) follow the \s-1ABI\s0 used by other x86 targets, which
-is the default on Solaris@tie{}10 and later. \fIOnly\fR use this option if
-you need to remain compatible with existing code produced by those
-previous compiler versions or older versions of \s-1GCC\s0.
-.IP "\fB\-mpc32\fR" 4
-.IX Item "-mpc32"
-.PD 0
-.IP "\fB\-mpc64\fR" 4
-.IX Item "-mpc64"
-.IP "\fB\-mpc80\fR" 4
-.IX Item "-mpc80"
-.PD
-Set 80387 floating-point precision to 32, 64 or 80 bits. When \fB\-mpc32\fR
-is specified, the significands of results of floating-point operations are
-rounded to 24 bits (single precision); \fB\-mpc64\fR rounds the
-significands of results of floating-point operations to 53 bits (double
-precision) and \fB\-mpc80\fR rounds the significands of results of
-floating-point operations to 64 bits (extended double precision), which is
-the default. When this option is used, floating-point operations in higher
-precisions are not available to the programmer without setting the \s-1FPU\s0
-control word explicitly.
-.Sp
-Setting the rounding of floating-point operations to less than the default
-80 bits can speed some programs by 2% or more. Note that some mathematical
-libraries assume that extended precision (80 bit) floating-point operations
-are enabled by default; routines in such libraries could suffer significant
-loss of accuracy, typically through so-called \*(L"catastrophic cancellation\*(R",
-when this option is used to set the precision to less than extended precision.
-.IP "\fB\-mstackrealign\fR" 4
-.IX Item "-mstackrealign"
-Realign the stack at entry. On the Intel x86, the \fB\-mstackrealign\fR
-option will generate an alternate prologue and epilogue that realigns the
-runtime stack if necessary. This supports mixing legacy codes that keep
-a 4\-byte aligned stack with modern codes that keep a 16\-byte stack for
-\&\s-1SSE\s0 compatibility. See also the attribute \f(CW\*(C`force_align_arg_pointer\*(C'\fR,
-applicable to individual functions.
-.IP "\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR" 4
-.IX Item "-mpreferred-stack-boundary=num"
-Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
-byte boundary. If \fB\-mpreferred\-stack\-boundary\fR is not specified,
-the default is 4 (16 bytes or 128 bits).
-.IP "\fB\-mincoming\-stack\-boundary=\fR\fInum\fR" 4
-.IX Item "-mincoming-stack-boundary=num"
-Assume the incoming stack is aligned to a 2 raised to \fInum\fR byte
-boundary. If \fB\-mincoming\-stack\-boundary\fR is not specified,
-the one specified by \fB\-mpreferred\-stack\-boundary\fR will be used.
-.Sp
-On Pentium and PentiumPro, \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long double\*(C'\fR values
-should be aligned to an 8 byte boundary (see \fB\-malign\-double\fR) or
-suffer significant run time performance penalties. On Pentium \s-1III\s0, the
-Streaming \s-1SIMD\s0 Extension (\s-1SSE\s0) data type \f(CW\*(C`_\|_m128\*(C'\fR may not work
-properly if it is not 16 byte aligned.
-.Sp
-To ensure proper alignment of this values on the stack, the stack boundary
-must be as aligned as that required by any value stored on the stack.
-Further, every function must be generated such that it keeps the stack
-aligned. Thus calling a function compiled with a higher preferred
-stack boundary from a function compiled with a lower preferred stack
-boundary will most likely misalign the stack. It is recommended that
-libraries that use callbacks always use the default setting.
-.Sp
-This extra alignment does consume extra stack space, and generally
-increases code size. Code that is sensitive to stack space usage, such
-as embedded systems and operating system kernels, may want to reduce the
-preferred alignment to \fB\-mpreferred\-stack\-boundary=2\fR.
-.IP "\fB\-mmmx\fR" 4
-.IX Item "-mmmx"
-.PD 0
-.IP "\fB\-mno\-mmx\fR" 4
-.IX Item "-mno-mmx"
-.IP "\fB\-msse\fR" 4
-.IX Item "-msse"
-.IP "\fB\-mno\-sse\fR" 4
-.IX Item "-mno-sse"
-.IP "\fB\-msse2\fR" 4
-.IX Item "-msse2"
-.IP "\fB\-mno\-sse2\fR" 4
-.IX Item "-mno-sse2"
-.IP "\fB\-msse3\fR" 4
-.IX Item "-msse3"
-.IP "\fB\-mno\-sse3\fR" 4
-.IX Item "-mno-sse3"
-.IP "\fB\-mssse3\fR" 4
-.IX Item "-mssse3"
-.IP "\fB\-mno\-ssse3\fR" 4
-.IX Item "-mno-ssse3"
-.IP "\fB\-msse4.1\fR" 4
-.IX Item "-msse4.1"
-.IP "\fB\-mno\-sse4.1\fR" 4
-.IX Item "-mno-sse4.1"
-.IP "\fB\-msse4.2\fR" 4
-.IX Item "-msse4.2"
-.IP "\fB\-mno\-sse4.2\fR" 4
-.IX Item "-mno-sse4.2"
-.IP "\fB\-msse4\fR" 4
-.IX Item "-msse4"
-.IP "\fB\-mno\-sse4\fR" 4
-.IX Item "-mno-sse4"
-.IP "\fB\-mavx\fR" 4
-.IX Item "-mavx"
-.IP "\fB\-mno\-avx\fR" 4
-.IX Item "-mno-avx"
-.IP "\fB\-maes\fR" 4
-.IX Item "-maes"
-.IP "\fB\-mno\-aes\fR" 4
-.IX Item "-mno-aes"
-.IP "\fB\-mpclmul\fR" 4
-.IX Item "-mpclmul"
-.IP "\fB\-mno\-pclmul\fR" 4
-.IX Item "-mno-pclmul"
-.IP "\fB\-mfsgsbase\fR" 4
-.IX Item "-mfsgsbase"
-.IP "\fB\-mno\-fsgsbase\fR" 4
-.IX Item "-mno-fsgsbase"
-.IP "\fB\-mrdrnd\fR" 4
-.IX Item "-mrdrnd"
-.IP "\fB\-mno\-rdrnd\fR" 4
-.IX Item "-mno-rdrnd"
-.IP "\fB\-mf16c\fR" 4
-.IX Item "-mf16c"
-.IP "\fB\-mno\-f16c\fR" 4
-.IX Item "-mno-f16c"
-.IP "\fB\-msse4a\fR" 4
-.IX Item "-msse4a"
-.IP "\fB\-mno\-sse4a\fR" 4
-.IX Item "-mno-sse4a"
-.IP "\fB\-mfma4\fR" 4
-.IX Item "-mfma4"
-.IP "\fB\-mno\-fma4\fR" 4
-.IX Item "-mno-fma4"
-.IP "\fB\-mxop\fR" 4
-.IX Item "-mxop"
-.IP "\fB\-mno\-xop\fR" 4
-.IX Item "-mno-xop"
-.IP "\fB\-mlwp\fR" 4
-.IX Item "-mlwp"
-.IP "\fB\-mno\-lwp\fR" 4
-.IX Item "-mno-lwp"
-.IP "\fB\-m3dnow\fR" 4
-.IX Item "-m3dnow"
-.IP "\fB\-mno\-3dnow\fR" 4
-.IX Item "-mno-3dnow"
-.IP "\fB\-mpopcnt\fR" 4
-.IX Item "-mpopcnt"
-.IP "\fB\-mno\-popcnt\fR" 4
-.IX Item "-mno-popcnt"
-.IP "\fB\-mabm\fR" 4
-.IX Item "-mabm"
-.IP "\fB\-mno\-abm\fR" 4
-.IX Item "-mno-abm"
-.IP "\fB\-mbmi\fR" 4
-.IX Item "-mbmi"
-.IP "\fB\-mno\-bmi\fR" 4
-.IX Item "-mno-bmi"
-.IP "\fB\-mtbm\fR" 4
-.IX Item "-mtbm"
-.IP "\fB\-mno\-tbm\fR" 4
-.IX Item "-mno-tbm"
-.PD
-These switches enable or disable the use of instructions in the \s-1MMX\s0,
-\&\s-1SSE\s0, \s-1SSE2\s0, \s-1SSE3\s0, \s-1SSSE3\s0, \s-1SSE4\s0.1, \s-1AVX\s0, \s-1AES\s0, \s-1PCLMUL\s0, \s-1FSGSBASE\s0, \s-1RDRND\s0,
-F16C, \s-1SSE4A\s0, \s-1FMA4\s0, \s-1XOP\s0, \s-1LWP\s0, \s-1ABM\s0, \s-1BMI\s0, or 3DNow! extended instruction sets.
-These extensions are also available as built-in functions: see
-\&\fBX86 Built-in Functions\fR, for details of the functions enabled and
-disabled by these switches.
-.Sp
-To have \s-1SSE/SSE2\s0 instructions generated automatically from floating-point
-code (as opposed to 387 instructions), see \fB\-mfpmath=sse\fR.
-.Sp
-\&\s-1GCC\s0 depresses SSEx instructions when \fB\-mavx\fR is used. Instead, it
-generates new \s-1AVX\s0 instructions or \s-1AVX\s0 equivalence for all SSEx instructions
-when needed.
-.Sp
-These options will enable \s-1GCC\s0 to use these extended instructions in
-generated code, even without \fB\-mfpmath=sse\fR. Applications which
-perform runtime \s-1CPU\s0 detection must compile separate files for each
-supported architecture, using the appropriate flags. In particular,
-the file containing the \s-1CPU\s0 detection code should be compiled without
-these options.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Do (don't) generate code that uses the fused multiply/add or multiply/subtract
-instructions. The default is to use these instructions.
-.IP "\fB\-mcld\fR" 4
-.IX Item "-mcld"
-This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`cld\*(C'\fR instruction in the prologue
-of functions that use string instructions. String instructions depend on
-the \s-1DF\s0 flag to select between autoincrement or autodecrement mode. While the
-\&\s-1ABI\s0 specifies the \s-1DF\s0 flag to be cleared on function entry, some operating
-systems violate this specification by not clearing the \s-1DF\s0 flag in their
-exception dispatchers. The exception handler can be invoked with the \s-1DF\s0 flag
-set which leads to wrong direction mode, when string instructions are used.
-This option can be enabled by default on 32\-bit x86 targets by configuring
-\&\s-1GCC\s0 with the \fB\-\-enable\-cld\fR configure option. Generation of \f(CW\*(C`cld\*(C'\fR
-instructions can be suppressed with the \fB\-mno\-cld\fR compiler option
-in this case.
-.IP "\fB\-mvzeroupper\fR" 4
-.IX Item "-mvzeroupper"
-This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`vzeroupper\*(C'\fR instruction
-before a transfer of control flow out of the function to minimize
-\&\s-1AVX\s0 to \s-1SSE\s0 transition penalty as well as remove unnecessary zeroupper
-intrinsics.
-.IP "\fB\-mcx16\fR" 4
-.IX Item "-mcx16"
-This option will enable \s-1GCC\s0 to use \s-1CMPXCHG16B\s0 instruction in generated code.
-\&\s-1CMPXCHG16B\s0 allows for atomic operations on 128\-bit double quadword (or oword)
-data types. This is useful for high resolution counters that could be updated
-by multiple processors (or cores). This instruction is generated as part of
-atomic built-in functions: see \fBAtomic Builtins\fR for details.
-.IP "\fB\-msahf\fR" 4
-.IX Item "-msahf"
-This option will enable \s-1GCC\s0 to use \s-1SAHF\s0 instruction in generated 64\-bit code.
-Early Intel CPUs with Intel 64 lacked \s-1LAHF\s0 and \s-1SAHF\s0 instructions supported
-by \s-1AMD64\s0 until introduction of Pentium 4 G1 step in December 2005. \s-1LAHF\s0 and
-\&\s-1SAHF\s0 are load and store instructions, respectively, for certain status flags.
-In 64\-bit mode, \s-1SAHF\s0 instruction is used to optimize \f(CW\*(C`fmod\*(C'\fR, \f(CW\*(C`drem\*(C'\fR
-or \f(CW\*(C`remainder\*(C'\fR built-in functions: see \fBOther Builtins\fR for details.
-.IP "\fB\-mmovbe\fR" 4
-.IX Item "-mmovbe"
-This option will enable \s-1GCC\s0 to use movbe instruction to implement
-\&\f(CW\*(C`_\|_builtin_bswap32\*(C'\fR and \f(CW\*(C`_\|_builtin_bswap64\*(C'\fR.
-.IP "\fB\-mcrc32\fR" 4
-.IX Item "-mcrc32"
-This option will enable built-in functions, \f(CW\*(C`_\|_builtin_ia32_crc32qi\*(C'\fR,
-\&\f(CW\*(C`_\|_builtin_ia32_crc32hi\*(C'\fR. \f(CW\*(C`_\|_builtin_ia32_crc32si\*(C'\fR and
-\&\f(CW\*(C`_\|_builtin_ia32_crc32di\*(C'\fR to generate the crc32 machine instruction.
-.IP "\fB\-mrecip\fR" 4
-.IX Item "-mrecip"
-This option will enable \s-1GCC\s0 to use \s-1RCPSS\s0 and \s-1RSQRTSS\s0 instructions (and their
-vectorized variants \s-1RCPPS\s0 and \s-1RSQRTPS\s0) with an additional Newton-Raphson step
-to increase precision instead of \s-1DIVSS\s0 and \s-1SQRTSS\s0 (and their vectorized
-variants) for single precision floating point arguments. These instructions
-are generated only when \fB\-funsafe\-math\-optimizations\fR is enabled
-together with \fB\-finite\-math\-only\fR and \fB\-fno\-trapping\-math\fR.
-Note that while the throughput of the sequence is higher than the throughput
-of the non-reciprocal instruction, the precision of the sequence can be
-decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.99999994).
-.Sp
-Note that \s-1GCC\s0 implements 1.0f/sqrtf(x) in terms of \s-1RSQRTSS\s0 (or \s-1RSQRTPS\s0)
-already with \fB\-ffast\-math\fR (or the above option combination), and
-doesn't need \fB\-mrecip\fR.
-.IP "\fB\-mveclibabi=\fR\fItype\fR" 4
-.IX Item "-mveclibabi=type"
-Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
-external library. Supported types are \f(CW\*(C`svml\*(C'\fR for the Intel short
-vector math library and \f(CW\*(C`acml\*(C'\fR for the \s-1AMD\s0 math core library style
-of interfacing. \s-1GCC\s0 will currently emit calls to \f(CW\*(C`vmldExp2\*(C'\fR,
-\&\f(CW\*(C`vmldLn2\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldPow2\*(C'\fR,
-\&\f(CW\*(C`vmldTanh2\*(C'\fR, \f(CW\*(C`vmldTan2\*(C'\fR, \f(CW\*(C`vmldAtan2\*(C'\fR, \f(CW\*(C`vmldAtanh2\*(C'\fR,
-\&\f(CW\*(C`vmldCbrt2\*(C'\fR, \f(CW\*(C`vmldSinh2\*(C'\fR, \f(CW\*(C`vmldSin2\*(C'\fR, \f(CW\*(C`vmldAsinh2\*(C'\fR,
-\&\f(CW\*(C`vmldAsin2\*(C'\fR, \f(CW\*(C`vmldCosh2\*(C'\fR, \f(CW\*(C`vmldCos2\*(C'\fR, \f(CW\*(C`vmldAcosh2\*(C'\fR,
-\&\f(CW\*(C`vmldAcos2\*(C'\fR, \f(CW\*(C`vmlsExp4\*(C'\fR, \f(CW\*(C`vmlsLn4\*(C'\fR, \f(CW\*(C`vmlsLog104\*(C'\fR,
-\&\f(CW\*(C`vmlsLog104\*(C'\fR, \f(CW\*(C`vmlsPow4\*(C'\fR, \f(CW\*(C`vmlsTanh4\*(C'\fR, \f(CW\*(C`vmlsTan4\*(C'\fR,
-\&\f(CW\*(C`vmlsAtan4\*(C'\fR, \f(CW\*(C`vmlsAtanh4\*(C'\fR, \f(CW\*(C`vmlsCbrt4\*(C'\fR, \f(CW\*(C`vmlsSinh4\*(C'\fR,
-\&\f(CW\*(C`vmlsSin4\*(C'\fR, \f(CW\*(C`vmlsAsinh4\*(C'\fR, \f(CW\*(C`vmlsAsin4\*(C'\fR, \f(CW\*(C`vmlsCosh4\*(C'\fR,
-\&\f(CW\*(C`vmlsCos4\*(C'\fR, \f(CW\*(C`vmlsAcosh4\*(C'\fR and \f(CW\*(C`vmlsAcos4\*(C'\fR for corresponding
-function type when \fB\-mveclibabi=svml\fR is used and \f(CW\*(C`_\|_vrd2_sin\*(C'\fR,
-\&\f(CW\*(C`_\|_vrd2_cos\*(C'\fR, \f(CW\*(C`_\|_vrd2_exp\*(C'\fR, \f(CW\*(C`_\|_vrd2_log\*(C'\fR, \f(CW\*(C`_\|_vrd2_log2\*(C'\fR,
-\&\f(CW\*(C`_\|_vrd2_log10\*(C'\fR, \f(CW\*(C`_\|_vrs4_sinf\*(C'\fR, \f(CW\*(C`_\|_vrs4_cosf\*(C'\fR,
-\&\f(CW\*(C`_\|_vrs4_expf\*(C'\fR, \f(CW\*(C`_\|_vrs4_logf\*(C'\fR, \f(CW\*(C`_\|_vrs4_log2f\*(C'\fR,
-\&\f(CW\*(C`_\|_vrs4_log10f\*(C'\fR and \f(CW\*(C`_\|_vrs4_powf\*(C'\fR for corresponding function type
-when \fB\-mveclibabi=acml\fR is used. Both \fB\-ftree\-vectorize\fR and
-\&\fB\-funsafe\-math\-optimizations\fR have to be enabled. A \s-1SVML\s0 or \s-1ACML\s0 \s-1ABI\s0
-compatible library will have to be specified at link time.
-.IP "\fB\-mabi=\fR\fIname\fR" 4
-.IX Item "-mabi=name"
-Generate code for the specified calling convention. Permissible values
-are: \fBsysv\fR for the \s-1ABI\s0 used on GNU/Linux and other systems and
-\&\fBms\fR for the Microsoft \s-1ABI\s0. The default is to use the Microsoft
-\&\s-1ABI\s0 when targeting Windows. On all other systems, the default is the
-\&\s-1SYSV\s0 \s-1ABI\s0. You can control this behavior for a specific function by
-using the function attribute \fBms_abi\fR/\fBsysv_abi\fR.
-.IP "\fB\-mpush\-args\fR" 4
-.IX Item "-mpush-args"
-.PD 0
-.IP "\fB\-mno\-push\-args\fR" 4
-.IX Item "-mno-push-args"
-.PD
-Use \s-1PUSH\s0 operations to store outgoing parameters. This method is shorter
-and usually equally fast as method using \s-1SUB/MOV\s0 operations and is enabled
-by default. In some cases disabling it may improve performance because of
-improved scheduling and reduced dependencies.
-.IP "\fB\-maccumulate\-outgoing\-args\fR" 4
-.IX Item "-maccumulate-outgoing-args"
-If enabled, the maximum amount of space required for outgoing arguments will be
-computed in the function prologue. This is faster on most modern CPUs
-because of reduced dependencies, improved scheduling and reduced stack usage
-when preferred stack boundary is not equal to 2. The drawback is a notable
-increase in code size. This switch implies \fB\-mno\-push\-args\fR.
-.IP "\fB\-mthreads\fR" 4
-.IX Item "-mthreads"
-Support thread-safe exception handling on \fBMingw32\fR. Code that relies
-on thread-safe exception handling must compile and link all code with the
-\&\fB\-mthreads\fR option. When compiling, \fB\-mthreads\fR defines
-\&\fB\-D_MT\fR; when linking, it links in a special thread helper library
-\&\fB\-lmingwthrd\fR which cleans up per thread exception handling data.
-.IP "\fB\-mno\-align\-stringops\fR" 4
-.IX Item "-mno-align-stringops"
-Do not align destination of inlined string operations. This switch reduces
-code size and improves performance in case the destination is already aligned,
-but \s-1GCC\s0 doesn't know about it.
-.IP "\fB\-minline\-all\-stringops\fR" 4
-.IX Item "-minline-all-stringops"
-By default \s-1GCC\s0 inlines string operations only when destination is known to be
-aligned at least to 4 byte boundary. This enables more inlining, increase code
-size, but may improve performance of code that depends on fast memcpy, strlen
-and memset for short lengths.
-.IP "\fB\-minline\-stringops\-dynamically\fR" 4
-.IX Item "-minline-stringops-dynamically"
-For string operation of unknown size, inline runtime checks so for small
-blocks inline code is used, while for large blocks library call is used.
-.IP "\fB\-mstringop\-strategy=\fR\fIalg\fR" 4
-.IX Item "-mstringop-strategy=alg"
-Overwrite internal decision heuristic about particular algorithm to inline
-string operation with. The allowed values are \f(CW\*(C`rep_byte\*(C'\fR,
-\&\f(CW\*(C`rep_4byte\*(C'\fR, \f(CW\*(C`rep_8byte\*(C'\fR for expanding using i386 \f(CW\*(C`rep\*(C'\fR prefix
-of specified size, \f(CW\*(C`byte_loop\*(C'\fR, \f(CW\*(C`loop\*(C'\fR, \f(CW\*(C`unrolled_loop\*(C'\fR for
-expanding inline loop, \f(CW\*(C`libcall\*(C'\fR for always expanding library call.
-.IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
-.IX Item "-momit-leaf-frame-pointer"
-Don't keep the frame pointer in a register for leaf functions. This
-avoids the instructions to save, set up and restore frame pointers and
-makes an extra register available in leaf functions. The option
-\&\fB\-fomit\-frame\-pointer\fR removes the frame pointer for all functions
-which might make debugging harder.
-.IP "\fB\-mtls\-direct\-seg\-refs\fR" 4
-.IX Item "-mtls-direct-seg-refs"
-.PD 0
-.IP "\fB\-mno\-tls\-direct\-seg\-refs\fR" 4
-.IX Item "-mno-tls-direct-seg-refs"
-.PD
-Controls whether \s-1TLS\s0 variables may be accessed with offsets from the
-\&\s-1TLS\s0 segment register (\f(CW%gs\fR for 32\-bit, \f(CW%fs\fR for 64\-bit),
-or whether the thread base pointer must be added. Whether or not this
-is legal depends on the operating system, and whether it maps the
-segment to cover the entire \s-1TLS\s0 area.
-.Sp
-For systems that use \s-1GNU\s0 libc, the default is on.
-.IP "\fB\-msse2avx\fR" 4
-.IX Item "-msse2avx"
-.PD 0
-.IP "\fB\-mno\-sse2avx\fR" 4
-.IX Item "-mno-sse2avx"
-.PD
-Specify that the assembler should encode \s-1SSE\s0 instructions with \s-1VEX\s0
-prefix. The option \fB\-mavx\fR turns this on by default.
-.IP "\fB\-mfentry\fR" 4
-.IX Item "-mfentry"
-.PD 0
-.IP "\fB\-mno\-fentry\fR" 4
-.IX Item "-mno-fentry"
-.PD
-If profiling is active \fB\-pg\fR put the profiling
-counter call before prologue.
-Note: On x86 architectures the attribute \f(CW\*(C`ms_hook_prologue\*(C'\fR
-isn't possible at the moment for \fB\-mfentry\fR and \fB\-pg\fR.
-.IP "\fB\-m8bit\-idiv\fR" 4
-.IX Item "-m8bit-idiv"
-.PD 0
-.IP "\fB\-mno\-8bit\-idiv\fR" 4
-.IX Item "-mno-8bit-idiv"
-.PD
-On some processors, like Intel Atom, 8bit unsigned integer divide is
-much faster than 32bit/64bit integer divide. This option will generate a
-runt-time check. If both dividend and divisor are within range of 0
-to 255, 8bit unsigned integer divide will be used instead of
-32bit/64bit integer divide.
-.IP "\fB\-mavx256\-split\-unaligned\-load\fR" 4
-.IX Item "-mavx256-split-unaligned-load"
-.PD 0
-.IP "\fB\-mavx256\-split\-unaligned\-store\fR" 4
-.IX Item "-mavx256-split-unaligned-store"
-.PD
-Split 32\-byte \s-1AVX\s0 unaligned load and store.
-.PP
-These \fB\-m\fR switches are supported in addition to the above
-on \s-1AMD\s0 x86\-64 processors in 64\-bit environments.
-.IP "\fB\-m32\fR" 4
-.IX Item "-m32"
-.PD 0
-.IP "\fB\-m64\fR" 4
-.IX Item "-m64"
-.PD
-Generate code for a 32\-bit or 64\-bit environment.
-The 32\-bit environment sets int, long and pointer to 32 bits and
-generates code that runs on any i386 system.
-The 64\-bit environment sets int to 32 bits and long and pointer
-to 64 bits and generates code for \s-1AMD\s0's x86\-64 architecture. For
-darwin only the \-m64 option turns off the \fB\-fno\-pic\fR and
-\&\fB\-mdynamic\-no\-pic\fR options.
-.IP "\fB\-mno\-red\-zone\fR" 4
-.IX Item "-mno-red-zone"
-Do not use a so called red zone for x86\-64 code. The red zone is mandated
-by the x86\-64 \s-1ABI\s0, it is a 128\-byte area beyond the location of the
-stack pointer that will not be modified by signal or interrupt handlers
-and therefore can be used for temporary data without adjusting the stack
-pointer. The flag \fB\-mno\-red\-zone\fR disables this red zone.
-.IP "\fB\-mcmodel=small\fR" 4
-.IX Item "-mcmodel=small"
-Generate code for the small code model: the program and its symbols must
-be linked in the lower 2 \s-1GB\s0 of the address space. Pointers are 64 bits.
-Programs can be statically or dynamically linked. This is the default
-code model.
-.IP "\fB\-mcmodel=kernel\fR" 4
-.IX Item "-mcmodel=kernel"
-Generate code for the kernel code model. The kernel runs in the
-negative 2 \s-1GB\s0 of the address space.
-This model has to be used for Linux kernel code.
-.IP "\fB\-mcmodel=medium\fR" 4
-.IX Item "-mcmodel=medium"
-Generate code for the medium model: The program is linked in the lower 2
-\&\s-1GB\s0 of the address space. Small symbols are also placed there. Symbols
-with sizes larger than \fB\-mlarge\-data\-threshold\fR are put into
-large data or bss sections and can be located above 2GB. Programs can
-be statically or dynamically linked.
-.IP "\fB\-mcmodel=large\fR" 4
-.IX Item "-mcmodel=large"
-Generate code for the large model: This model makes no assumptions
-about addresses and sizes of sections.
-.PP
-\fIi386 and x86\-64 Windows Options\fR
-.IX Subsection "i386 and x86-64 Windows Options"
-.PP
-These additional options are available for Windows targets:
-.IP "\fB\-mconsole\fR" 4
-.IX Item "-mconsole"
-This option is available for Cygwin and MinGW targets. It
-specifies that a console application is to be generated, by
-instructing the linker to set the \s-1PE\s0 header subsystem type
-required for console applications.
-This is the default behavior for Cygwin and MinGW targets.
-.IP "\fB\-mdll\fR" 4
-.IX Item "-mdll"
-This option is available for Cygwin and MinGW targets. It
-specifies that a \s-1DLL\s0 \- a dynamic link library \- is to be
-generated, enabling the selection of the required runtime
-startup object and entry point.
-.IP "\fB\-mnop\-fun\-dllimport\fR" 4
-.IX Item "-mnop-fun-dllimport"
-This option is available for Cygwin and MinGW targets. It
-specifies that the dllimport attribute should be ignored.
-.IP "\fB\-mthread\fR" 4
-.IX Item "-mthread"
-This option is available for MinGW targets. It specifies
-that MinGW-specific thread support is to be used.
-.IP "\fB\-municode\fR" 4
-.IX Item "-municode"
-This option is available for mingw\-w64 targets. It specifies
-that the \s-1UNICODE\s0 macro is getting pre-defined and that the
-unicode capable runtime startup code is chosen.
-.IP "\fB\-mwin32\fR" 4
-.IX Item "-mwin32"
-This option is available for Cygwin and MinGW targets. It
-specifies that the typical Windows pre-defined macros are to
-be set in the pre-processor, but does not influence the choice
-of runtime library/startup code.
-.IP "\fB\-mwindows\fR" 4
-.IX Item "-mwindows"
-This option is available for Cygwin and MinGW targets. It
-specifies that a \s-1GUI\s0 application is to be generated by
-instructing the linker to set the \s-1PE\s0 header subsystem type
-appropriately.
-.IP "\fB\-fno\-set\-stack\-executable\fR" 4
-.IX Item "-fno-set-stack-executable"
-This option is available for MinGW targets. It specifies that
-the executable flag for stack used by nested functions isn't
-set. This is necessary for binaries running in kernel mode of
-Windows, as there the user32 \s-1API\s0, which is used to set executable
-privileges, isn't available.
-.IP "\fB\-mpe\-aligned\-commons\fR" 4
-.IX Item "-mpe-aligned-commons"
-This option is available for Cygwin and MinGW targets. It
-specifies that the \s-1GNU\s0 extension to the \s-1PE\s0 file format that
-permits the correct alignment of \s-1COMMON\s0 variables should be
-used when generating code. It will be enabled by default if
-\&\s-1GCC\s0 detects that the target assembler found during configuration
-supports the feature.
-.PP
-See also under \fBi386 and x86\-64 Options\fR for standard options.
-.PP
-\fI\s-1IA\-64\s0 Options\fR
-.IX Subsection "IA-64 Options"
-.PP
-These are the \fB\-m\fR options defined for the Intel \s-1IA\-64\s0 architecture.
-.IP "\fB\-mbig\-endian\fR" 4
-.IX Item "-mbig-endian"
-Generate code for a big endian target. This is the default for HP-UX.
-.IP "\fB\-mlittle\-endian\fR" 4
-.IX Item "-mlittle-endian"
-Generate code for a little endian target. This is the default for \s-1AIX5\s0
-and GNU/Linux.
-.IP "\fB\-mgnu\-as\fR" 4
-.IX Item "-mgnu-as"
-.PD 0
-.IP "\fB\-mno\-gnu\-as\fR" 4
-.IX Item "-mno-gnu-as"
-.PD
-Generate (or don't) code for the \s-1GNU\s0 assembler. This is the default.
-.IP "\fB\-mgnu\-ld\fR" 4
-.IX Item "-mgnu-ld"
-.PD 0
-.IP "\fB\-mno\-gnu\-ld\fR" 4
-.IX Item "-mno-gnu-ld"
-.PD
-Generate (or don't) code for the \s-1GNU\s0 linker. This is the default.
-.IP "\fB\-mno\-pic\fR" 4
-.IX Item "-mno-pic"
-Generate code that does not use a global pointer register. The result
-is not position independent code, and violates the \s-1IA\-64\s0 \s-1ABI\s0.
-.IP "\fB\-mvolatile\-asm\-stop\fR" 4
-.IX Item "-mvolatile-asm-stop"
-.PD 0
-.IP "\fB\-mno\-volatile\-asm\-stop\fR" 4
-.IX Item "-mno-volatile-asm-stop"
-.PD
-Generate (or don't) a stop bit immediately before and after volatile asm
-statements.
-.IP "\fB\-mregister\-names\fR" 4
-.IX Item "-mregister-names"
-.PD 0
-.IP "\fB\-mno\-register\-names\fR" 4
-.IX Item "-mno-register-names"
-.PD
-Generate (or don't) \fBin\fR, \fBloc\fR, and \fBout\fR register names for
-the stacked registers. This may make assembler output more readable.
-.IP "\fB\-mno\-sdata\fR" 4
-.IX Item "-mno-sdata"
-.PD 0
-.IP "\fB\-msdata\fR" 4
-.IX Item "-msdata"
-.PD
-Disable (or enable) optimizations that use the small data section. This may
-be useful for working around optimizer bugs.
-.IP "\fB\-mconstant\-gp\fR" 4
-.IX Item "-mconstant-gp"
-Generate code that uses a single constant global pointer value. This is
-useful when compiling kernel code.
-.IP "\fB\-mauto\-pic\fR" 4
-.IX Item "-mauto-pic"
-Generate code that is self-relocatable. This implies \fB\-mconstant\-gp\fR.
-This is useful when compiling firmware code.
-.IP "\fB\-minline\-float\-divide\-min\-latency\fR" 4
-.IX Item "-minline-float-divide-min-latency"
-Generate code for inline divides of floating point values
-using the minimum latency algorithm.
-.IP "\fB\-minline\-float\-divide\-max\-throughput\fR" 4
-.IX Item "-minline-float-divide-max-throughput"
-Generate code for inline divides of floating point values
-using the maximum throughput algorithm.
-.IP "\fB\-mno\-inline\-float\-divide\fR" 4
-.IX Item "-mno-inline-float-divide"
-Do not generate inline code for divides of floating point values.
-.IP "\fB\-minline\-int\-divide\-min\-latency\fR" 4
-.IX Item "-minline-int-divide-min-latency"
-Generate code for inline divides of integer values
-using the minimum latency algorithm.
-.IP "\fB\-minline\-int\-divide\-max\-throughput\fR" 4
-.IX Item "-minline-int-divide-max-throughput"
-Generate code for inline divides of integer values
-using the maximum throughput algorithm.
-.IP "\fB\-mno\-inline\-int\-divide\fR" 4
-.IX Item "-mno-inline-int-divide"
-Do not generate inline code for divides of integer values.
-.IP "\fB\-minline\-sqrt\-min\-latency\fR" 4
-.IX Item "-minline-sqrt-min-latency"
-Generate code for inline square roots
-using the minimum latency algorithm.
-.IP "\fB\-minline\-sqrt\-max\-throughput\fR" 4
-.IX Item "-minline-sqrt-max-throughput"
-Generate code for inline square roots
-using the maximum throughput algorithm.
-.IP "\fB\-mno\-inline\-sqrt\fR" 4
-.IX Item "-mno-inline-sqrt"
-Do not generate inline code for sqrt.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Do (don't) generate code that uses the fused multiply/add or multiply/subtract
-instructions. The default is to use these instructions.
-.IP "\fB\-mno\-dwarf2\-asm\fR" 4
-.IX Item "-mno-dwarf2-asm"
-.PD 0
-.IP "\fB\-mdwarf2\-asm\fR" 4
-.IX Item "-mdwarf2-asm"
-.PD
-Don't (or do) generate assembler code for the \s-1DWARF2\s0 line number debugging
-info. This may be useful when not using the \s-1GNU\s0 assembler.
-.IP "\fB\-mearly\-stop\-bits\fR" 4
-.IX Item "-mearly-stop-bits"
-.PD 0
-.IP "\fB\-mno\-early\-stop\-bits\fR" 4
-.IX Item "-mno-early-stop-bits"
-.PD
-Allow stop bits to be placed earlier than immediately preceding the
-instruction that triggered the stop bit. This can improve instruction
-scheduling, but does not always do so.
-.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
-.IX Item "-mfixed-range=register-range"
-Generate code treating the given register range as fixed registers.
-A fixed register is one that the register allocator can not use. This is
-useful when compiling kernel code. A register range is specified as
-two registers separated by a dash. Multiple register ranges can be
-specified separated by a comma.
-.IP "\fB\-mtls\-size=\fR\fItls-size\fR" 4
-.IX Item "-mtls-size=tls-size"
-Specify bit size of immediate \s-1TLS\s0 offsets. Valid values are 14, 22, and
-64.
-.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
-.IX Item "-mtune=cpu-type"
-Tune the instruction scheduling for a particular \s-1CPU\s0, Valid values are
-itanium, itanium1, merced, itanium2, and mckinley.
-.IP "\fB\-milp32\fR" 4
-.IX Item "-milp32"
-.PD 0
-.IP "\fB\-mlp64\fR" 4
-.IX Item "-mlp64"
-.PD
-Generate code for a 32\-bit or 64\-bit environment.
-The 32\-bit environment sets int, long and pointer to 32 bits.
-The 64\-bit environment sets int to 32 bits and long and pointer
-to 64 bits. These are HP-UX specific flags.
-.IP "\fB\-mno\-sched\-br\-data\-spec\fR" 4
-.IX Item "-mno-sched-br-data-spec"
-.PD 0
-.IP "\fB\-msched\-br\-data\-spec\fR" 4
-.IX Item "-msched-br-data-spec"
-.PD
-(Dis/En)able data speculative scheduling before reload.
-This will result in generation of the ld.a instructions and
-the corresponding check instructions (ld.c / chk.a).
-The default is 'disable'.
-.IP "\fB\-msched\-ar\-data\-spec\fR" 4
-.IX Item "-msched-ar-data-spec"
-.PD 0
-.IP "\fB\-mno\-sched\-ar\-data\-spec\fR" 4
-.IX Item "-mno-sched-ar-data-spec"
-.PD
-(En/Dis)able data speculative scheduling after reload.
-This will result in generation of the ld.a instructions and
-the corresponding check instructions (ld.c / chk.a).
-The default is 'enable'.
-.IP "\fB\-mno\-sched\-control\-spec\fR" 4
-.IX Item "-mno-sched-control-spec"
-.PD 0
-.IP "\fB\-msched\-control\-spec\fR" 4
-.IX Item "-msched-control-spec"
-.PD
-(Dis/En)able control speculative scheduling. This feature is
-available only during region scheduling (i.e. before reload).
-This will result in generation of the ld.s instructions and
-the corresponding check instructions chk.s .
-The default is 'disable'.
-.IP "\fB\-msched\-br\-in\-data\-spec\fR" 4
-.IX Item "-msched-br-in-data-spec"
-.PD 0
-.IP "\fB\-mno\-sched\-br\-in\-data\-spec\fR" 4
-.IX Item "-mno-sched-br-in-data-spec"
-.PD
-(En/Dis)able speculative scheduling of the instructions that
-are dependent on the data speculative loads before reload.
-This is effective only with \fB\-msched\-br\-data\-spec\fR enabled.
-The default is 'enable'.
-.IP "\fB\-msched\-ar\-in\-data\-spec\fR" 4
-.IX Item "-msched-ar-in-data-spec"
-.PD 0
-.IP "\fB\-mno\-sched\-ar\-in\-data\-spec\fR" 4
-.IX Item "-mno-sched-ar-in-data-spec"
-.PD
-(En/Dis)able speculative scheduling of the instructions that
-are dependent on the data speculative loads after reload.
-This is effective only with \fB\-msched\-ar\-data\-spec\fR enabled.
-The default is 'enable'.
-.IP "\fB\-msched\-in\-control\-spec\fR" 4
-.IX Item "-msched-in-control-spec"
-.PD 0
-.IP "\fB\-mno\-sched\-in\-control\-spec\fR" 4
-.IX Item "-mno-sched-in-control-spec"
-.PD
-(En/Dis)able speculative scheduling of the instructions that
-are dependent on the control speculative loads.
-This is effective only with \fB\-msched\-control\-spec\fR enabled.
-The default is 'enable'.
-.IP "\fB\-mno\-sched\-prefer\-non\-data\-spec\-insns\fR" 4
-.IX Item "-mno-sched-prefer-non-data-spec-insns"
-.PD 0
-.IP "\fB\-msched\-prefer\-non\-data\-spec\-insns\fR" 4
-.IX Item "-msched-prefer-non-data-spec-insns"
-.PD
-If enabled, data speculative instructions will be chosen for schedule
-only if there are no other choices at the moment. This will make
-the use of the data speculation much more conservative.
-The default is 'disable'.
-.IP "\fB\-mno\-sched\-prefer\-non\-control\-spec\-insns\fR" 4
-.IX Item "-mno-sched-prefer-non-control-spec-insns"
-.PD 0
-.IP "\fB\-msched\-prefer\-non\-control\-spec\-insns\fR" 4
-.IX Item "-msched-prefer-non-control-spec-insns"
-.PD
-If enabled, control speculative instructions will be chosen for schedule
-only if there are no other choices at the moment. This will make
-the use of the control speculation much more conservative.
-The default is 'disable'.
-.IP "\fB\-mno\-sched\-count\-spec\-in\-critical\-path\fR" 4
-.IX Item "-mno-sched-count-spec-in-critical-path"
-.PD 0
-.IP "\fB\-msched\-count\-spec\-in\-critical\-path\fR" 4
-.IX Item "-msched-count-spec-in-critical-path"
-.PD
-If enabled, speculative dependencies will be considered during
-computation of the instructions priorities. This will make the use of the
-speculation a bit more conservative.
-The default is 'disable'.
-.IP "\fB\-msched\-spec\-ldc\fR" 4
-.IX Item "-msched-spec-ldc"
-Use a simple data speculation check. This option is on by default.
-.IP "\fB\-msched\-control\-spec\-ldc\fR" 4
-.IX Item "-msched-control-spec-ldc"
-Use a simple check for control speculation. This option is on by default.
-.IP "\fB\-msched\-stop\-bits\-after\-every\-cycle\fR" 4
-.IX Item "-msched-stop-bits-after-every-cycle"
-Place a stop bit after every cycle when scheduling. This option is on
-by default.
-.IP "\fB\-msched\-fp\-mem\-deps\-zero\-cost\fR" 4
-.IX Item "-msched-fp-mem-deps-zero-cost"
-Assume that floating-point stores and loads are not likely to cause a conflict
-when placed into the same instruction group. This option is disabled by
-default.
-.IP "\fB\-msel\-sched\-dont\-check\-control\-spec\fR" 4
-.IX Item "-msel-sched-dont-check-control-spec"
-Generate checks for control speculation in selective scheduling.
-This flag is disabled by default.
-.IP "\fB\-msched\-max\-memory\-insns=\fR\fImax-insns\fR" 4
-.IX Item "-msched-max-memory-insns=max-insns"
-Limit on the number of memory insns per instruction group, giving lower
-priority to subsequent memory insns attempting to schedule in the same
-instruction group. Frequently useful to prevent cache bank conflicts.
-The default value is 1.
-.IP "\fB\-msched\-max\-memory\-insns\-hard\-limit\fR" 4
-.IX Item "-msched-max-memory-insns-hard-limit"
-Disallow more than `msched\-max\-memory\-insns' in instruction group.
-Otherwise, limit is `soft' meaning that we would prefer non-memory operations
-when limit is reached but may still schedule memory operations.
-.PP
-\fI\s-1IA\-64/VMS\s0 Options\fR
-.IX Subsection "IA-64/VMS Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1IA\-64/VMS\s0 implementations:
-.IP "\fB\-mvms\-return\-codes\fR" 4
-.IX Item "-mvms-return-codes"
-Return \s-1VMS\s0 condition codes from main. The default is to return \s-1POSIX\s0
-style condition (e.g. error) codes.
-.IP "\fB\-mdebug\-main=\fR\fIprefix\fR" 4
-.IX Item "-mdebug-main=prefix"
-Flag the first routine whose name starts with \fIprefix\fR as the main
-routine for the debugger.
-.IP "\fB\-mmalloc64\fR" 4
-.IX Item "-mmalloc64"
-Default to 64bit memory allocation routines.
-.PP
-\fI\s-1LM32\s0 Options\fR
-.IX Subsection "LM32 Options"
-.PP
-These \fB\-m\fR options are defined for the Lattice Mico32 architecture:
-.IP "\fB\-mbarrel\-shift\-enabled\fR" 4
-.IX Item "-mbarrel-shift-enabled"
-Enable barrel-shift instructions.
-.IP "\fB\-mdivide\-enabled\fR" 4
-.IX Item "-mdivide-enabled"
-Enable divide and modulus instructions.
-.IP "\fB\-mmultiply\-enabled\fR" 4
-.IX Item "-mmultiply-enabled"
-Enable multiply instructions.
-.IP "\fB\-msign\-extend\-enabled\fR" 4
-.IX Item "-msign-extend-enabled"
-Enable sign extend instructions.
-.IP "\fB\-muser\-enabled\fR" 4
-.IX Item "-muser-enabled"
-Enable user-defined instructions.
-.PP
-\fIM32C Options\fR
-.IX Subsection "M32C Options"
-.IP "\fB\-mcpu=\fR\fIname\fR" 4
-.IX Item "-mcpu=name"
-Select the \s-1CPU\s0 for which code is generated. \fIname\fR may be one of
-\&\fBr8c\fR for the R8C/Tiny series, \fBm16c\fR for the M16C (up to
-/60) series, \fBm32cm\fR for the M16C/80 series, or \fBm32c\fR for
-the M32C/80 series.
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-Specifies that the program will be run on the simulator. This causes
-an alternate runtime library to be linked in which supports, for
-example, file I/O. You must not use this option when generating
-programs that will run on real hardware; you must provide your own
-runtime library for whatever I/O functions are needed.
-.IP "\fB\-memregs=\fR\fInumber\fR" 4
-.IX Item "-memregs=number"
-Specifies the number of memory-based pseudo-registers \s-1GCC\s0 will use
-during code generation. These pseudo-registers will be used like real
-registers, so there is a tradeoff between \s-1GCC\s0's ability to fit the
-code into available registers, and the performance penalty of using
-memory instead of registers. Note that all modules in a program must
-be compiled with the same value for this option. Because of that, you
-must not use this option with the default runtime libraries gcc
-builds.
-.PP
-\fIM32R/D Options\fR
-.IX Subsection "M32R/D Options"
-.PP
-These \fB\-m\fR options are defined for Renesas M32R/D architectures:
-.IP "\fB\-m32r2\fR" 4
-.IX Item "-m32r2"
-Generate code for the M32R/2.
-.IP "\fB\-m32rx\fR" 4
-.IX Item "-m32rx"
-Generate code for the M32R/X.
-.IP "\fB\-m32r\fR" 4
-.IX Item "-m32r"
-Generate code for the M32R. This is the default.
-.IP "\fB\-mmodel=small\fR" 4
-.IX Item "-mmodel=small"
-Assume all objects live in the lower 16MB of memory (so that their addresses
-can be loaded with the \f(CW\*(C`ld24\*(C'\fR instruction), and assume all subroutines
-are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
-This is the default.
-.Sp
-The addressability of a particular object can be set with the
-\&\f(CW\*(C`model\*(C'\fR attribute.
-.IP "\fB\-mmodel=medium\fR" 4
-.IX Item "-mmodel=medium"
-Assume objects may be anywhere in the 32\-bit address space (the compiler
-will generate \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
-assume all subroutines are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
-.IP "\fB\-mmodel=large\fR" 4
-.IX Item "-mmodel=large"
-Assume objects may be anywhere in the 32\-bit address space (the compiler
-will generate \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
-assume subroutines may not be reachable with the \f(CW\*(C`bl\*(C'\fR instruction
-(the compiler will generate the much slower \f(CW\*(C`seth/add3/jl\*(C'\fR
-instruction sequence).
-.IP "\fB\-msdata=none\fR" 4
-.IX Item "-msdata=none"
-Disable use of the small data area. Variables will be put into
-one of \fB.data\fR, \fBbss\fR, or \fB.rodata\fR (unless the
-\&\f(CW\*(C`section\*(C'\fR attribute has been specified).
-This is the default.
-.Sp
-The small data area consists of sections \fB.sdata\fR and \fB.sbss\fR.
-Objects may be explicitly put in the small data area with the
-\&\f(CW\*(C`section\*(C'\fR attribute using one of these sections.
-.IP "\fB\-msdata=sdata\fR" 4
-.IX Item "-msdata=sdata"
-Put small global and static data in the small data area, but do not
-generate special code to reference them.
-.IP "\fB\-msdata=use\fR" 4
-.IX Item "-msdata=use"
-Put small global and static data in the small data area, and generate
-special instructions to reference them.
-.IP "\fB\-G\fR \fInum\fR" 4
-.IX Item "-G num"
-Put global and static objects less than or equal to \fInum\fR bytes
-into the small data or bss sections instead of the normal data or bss
-sections. The default value of \fInum\fR is 8.
-The \fB\-msdata\fR option must be set to one of \fBsdata\fR or \fBuse\fR
-for this option to have any effect.
-.Sp
-All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
-Compiling with different values of \fInum\fR may or may not work; if it
-doesn't the linker will give an error message\-\-\-incorrect code will not be
-generated.
-.IP "\fB\-mdebug\fR" 4
-.IX Item "-mdebug"
-Makes the M32R specific code in the compiler display some statistics
-that might help in debugging programs.
-.IP "\fB\-malign\-loops\fR" 4
-.IX Item "-malign-loops"
-Align all loops to a 32\-byte boundary.
-.IP "\fB\-mno\-align\-loops\fR" 4
-.IX Item "-mno-align-loops"
-Do not enforce a 32\-byte alignment for loops. This is the default.
-.IP "\fB\-missue\-rate=\fR\fInumber\fR" 4
-.IX Item "-missue-rate=number"
-Issue \fInumber\fR instructions per cycle. \fInumber\fR can only be 1
-or 2.
-.IP "\fB\-mbranch\-cost=\fR\fInumber\fR" 4
-.IX Item "-mbranch-cost=number"
-\&\fInumber\fR can only be 1 or 2. If it is 1 then branches will be
-preferred over conditional code, if it is 2, then the opposite will
-apply.
-.IP "\fB\-mflush\-trap=\fR\fInumber\fR" 4
-.IX Item "-mflush-trap=number"
-Specifies the trap number to use to flush the cache. The default is
-12. Valid numbers are between 0 and 15 inclusive.
-.IP "\fB\-mno\-flush\-trap\fR" 4
-.IX Item "-mno-flush-trap"
-Specifies that the cache cannot be flushed by using a trap.
-.IP "\fB\-mflush\-func=\fR\fIname\fR" 4
-.IX Item "-mflush-func=name"
-Specifies the name of the operating system function to call to flush
-the cache. The default is \fI_flush_cache\fR, but a function call
-will only be used if a trap is not available.
-.IP "\fB\-mno\-flush\-func\fR" 4
-.IX Item "-mno-flush-func"
-Indicates that there is no \s-1OS\s0 function for flushing the cache.
-.PP
-\fIM680x0 Options\fR
-.IX Subsection "M680x0 Options"
-.PP
-These are the \fB\-m\fR options defined for M680x0 and ColdFire processors.
-The default settings depend on which architecture was selected when
-the compiler was configured; the defaults for the most common choices
-are given below.
-.IP "\fB\-march=\fR\fIarch\fR" 4
-.IX Item "-march=arch"
-Generate code for a specific M680x0 or ColdFire instruction set
-architecture. Permissible values of \fIarch\fR for M680x0
-architectures are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
-\&\fB68030\fR, \fB68040\fR, \fB68060\fR and \fBcpu32\fR. ColdFire
-architectures are selected according to Freescale's \s-1ISA\s0 classification
-and the permissible values are: \fBisaa\fR, \fBisaaplus\fR,
-\&\fBisab\fR and \fBisac\fR.
-.Sp
-gcc defines a macro \fB_\|_mcf\fR\fIarch\fR\fB_\|_\fR whenever it is generating
-code for a ColdFire target. The \fIarch\fR in this macro is one of the
-\&\fB\-march\fR arguments given above.
-.Sp
-When used together, \fB\-march\fR and \fB\-mtune\fR select code
-that runs on a family of similar processors but that is optimized
-for a particular microarchitecture.
-.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
-.IX Item "-mcpu=cpu"
-Generate code for a specific M680x0 or ColdFire processor.
-The M680x0 \fIcpu\fRs are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
-\&\fB68030\fR, \fB68040\fR, \fB68060\fR, \fB68302\fR, \fB68332\fR
-and \fBcpu32\fR. The ColdFire \fIcpu\fRs are given by the table
-below, which also classifies the CPUs into families:
-.RS 4
-.IP "Family : \fB\-mcpu\fR arguments" 4
-.IX Item "Family : -mcpu arguments"
-.PD 0
-.IP "\fB51\fR : \fB51\fR \fB51ac\fR \fB51cn\fR \fB51em\fR \fB51qe\fR" 4
-.IX Item "51 : 51 51ac 51cn 51em 51qe"
-.IP "\fB5206\fR : \fB5202\fR \fB5204\fR \fB5206\fR" 4
-.IX Item "5206 : 5202 5204 5206"
-.IP "\fB5206e\fR : \fB5206e\fR" 4
-.IX Item "5206e : 5206e"
-.IP "\fB5208\fR : \fB5207\fR \fB5208\fR" 4
-.IX Item "5208 : 5207 5208"
-.IP "\fB5211a\fR : \fB5210a\fR \fB5211a\fR" 4
-.IX Item "5211a : 5210a 5211a"
-.IP "\fB5213\fR : \fB5211\fR \fB5212\fR \fB5213\fR" 4
-.IX Item "5213 : 5211 5212 5213"
-.IP "\fB5216\fR : \fB5214\fR \fB5216\fR" 4
-.IX Item "5216 : 5214 5216"
-.IP "\fB52235\fR : \fB52230\fR \fB52231\fR \fB52232\fR \fB52233\fR \fB52234\fR \fB52235\fR" 4
-.IX Item "52235 : 52230 52231 52232 52233 52234 52235"
-.IP "\fB5225\fR : \fB5224\fR \fB5225\fR" 4
-.IX Item "5225 : 5224 5225"
-.IP "\fB52259\fR : \fB52252\fR \fB52254\fR \fB52255\fR \fB52256\fR \fB52258\fR \fB52259\fR" 4
-.IX Item "52259 : 52252 52254 52255 52256 52258 52259"
-.IP "\fB5235\fR : \fB5232\fR \fB5233\fR \fB5234\fR \fB5235\fR \fB523x\fR" 4
-.IX Item "5235 : 5232 5233 5234 5235 523x"
-.IP "\fB5249\fR : \fB5249\fR" 4
-.IX Item "5249 : 5249"
-.IP "\fB5250\fR : \fB5250\fR" 4
-.IX Item "5250 : 5250"
-.IP "\fB5271\fR : \fB5270\fR \fB5271\fR" 4
-.IX Item "5271 : 5270 5271"
-.IP "\fB5272\fR : \fB5272\fR" 4
-.IX Item "5272 : 5272"
-.IP "\fB5275\fR : \fB5274\fR \fB5275\fR" 4
-.IX Item "5275 : 5274 5275"
-.IP "\fB5282\fR : \fB5280\fR \fB5281\fR \fB5282\fR \fB528x\fR" 4
-.IX Item "5282 : 5280 5281 5282 528x"
-.IP "\fB53017\fR : \fB53011\fR \fB53012\fR \fB53013\fR \fB53014\fR \fB53015\fR \fB53016\fR \fB53017\fR" 4
-.IX Item "53017 : 53011 53012 53013 53014 53015 53016 53017"
-.IP "\fB5307\fR : \fB5307\fR" 4
-.IX Item "5307 : 5307"
-.IP "\fB5329\fR : \fB5327\fR \fB5328\fR \fB5329\fR \fB532x\fR" 4
-.IX Item "5329 : 5327 5328 5329 532x"
-.IP "\fB5373\fR : \fB5372\fR \fB5373\fR \fB537x\fR" 4
-.IX Item "5373 : 5372 5373 537x"
-.IP "\fB5407\fR : \fB5407\fR" 4
-.IX Item "5407 : 5407"
-.IP "\fB5475\fR : \fB5470\fR \fB5471\fR \fB5472\fR \fB5473\fR \fB5474\fR \fB5475\fR \fB547x\fR \fB5480\fR \fB5481\fR \fB5482\fR \fB5483\fR \fB5484\fR \fB5485\fR" 4
-.IX Item "5475 : 5470 5471 5472 5473 5474 5475 547x 5480 5481 5482 5483 5484 5485"
-.RE
-.RS 4
-.PD
-.Sp
-\&\fB\-mcpu=\fR\fIcpu\fR overrides \fB\-march=\fR\fIarch\fR if
-\&\fIarch\fR is compatible with \fIcpu\fR. Other combinations of
-\&\fB\-mcpu\fR and \fB\-march\fR are rejected.
-.Sp
-gcc defines the macro \fB_\|_mcf_cpu_\fR\fIcpu\fR when ColdFire target
-\&\fIcpu\fR is selected. It also defines \fB_\|_mcf_family_\fR\fIfamily\fR,
-where the value of \fIfamily\fR is given by the table above.
-.RE
-.IP "\fB\-mtune=\fR\fItune\fR" 4
-.IX Item "-mtune=tune"
-Tune the code for a particular microarchitecture, within the
-constraints set by \fB\-march\fR and \fB\-mcpu\fR.
-The M680x0 microarchitectures are: \fB68000\fR, \fB68010\fR,
-\&\fB68020\fR, \fB68030\fR, \fB68040\fR, \fB68060\fR
-and \fBcpu32\fR. The ColdFire microarchitectures
-are: \fBcfv1\fR, \fBcfv2\fR, \fBcfv3\fR, \fBcfv4\fR and \fBcfv4e\fR.
-.Sp
-You can also use \fB\-mtune=68020\-40\fR for code that needs
-to run relatively well on 68020, 68030 and 68040 targets.
-\&\fB\-mtune=68020\-60\fR is similar but includes 68060 targets
-as well. These two options select the same tuning decisions as
-\&\fB\-m68020\-40\fR and \fB\-m68020\-60\fR respectively.
-.Sp
-gcc defines the macros \fB_\|_mc\fR\fIarch\fR and \fB_\|_mc\fR\fIarch\fR\fB_\|_\fR
-when tuning for 680x0 architecture \fIarch\fR. It also defines
-\&\fBmc\fR\fIarch\fR unless either \fB\-ansi\fR or a non-GNU \fB\-std\fR
-option is used. If gcc is tuning for a range of architectures,
-as selected by \fB\-mtune=68020\-40\fR or \fB\-mtune=68020\-60\fR,
-it defines the macros for every architecture in the range.
-.Sp
-gcc also defines the macro \fB_\|_m\fR\fIuarch\fR\fB_\|_\fR when tuning for
-ColdFire microarchitecture \fIuarch\fR, where \fIuarch\fR is one
-of the arguments given above.
-.IP "\fB\-m68000\fR" 4
-.IX Item "-m68000"
-.PD 0
-.IP "\fB\-mc68000\fR" 4
-.IX Item "-mc68000"
-.PD
-Generate output for a 68000. This is the default
-when the compiler is configured for 68000\-based systems.
-It is equivalent to \fB\-march=68000\fR.
-.Sp
-Use this option for microcontrollers with a 68000 or \s-1EC000\s0 core,
-including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
-.IP "\fB\-m68010\fR" 4
-.IX Item "-m68010"
-Generate output for a 68010. This is the default
-when the compiler is configured for 68010\-based systems.
-It is equivalent to \fB\-march=68010\fR.
-.IP "\fB\-m68020\fR" 4
-.IX Item "-m68020"
-.PD 0
-.IP "\fB\-mc68020\fR" 4
-.IX Item "-mc68020"
-.PD
-Generate output for a 68020. This is the default
-when the compiler is configured for 68020\-based systems.
-It is equivalent to \fB\-march=68020\fR.
-.IP "\fB\-m68030\fR" 4
-.IX Item "-m68030"
-Generate output for a 68030. This is the default when the compiler is
-configured for 68030\-based systems. It is equivalent to
-\&\fB\-march=68030\fR.
-.IP "\fB\-m68040\fR" 4
-.IX Item "-m68040"
-Generate output for a 68040. This is the default when the compiler is
-configured for 68040\-based systems. It is equivalent to
-\&\fB\-march=68040\fR.
-.Sp
-This option inhibits the use of 68881/68882 instructions that have to be
-emulated by software on the 68040. Use this option if your 68040 does not
-have code to emulate those instructions.
-.IP "\fB\-m68060\fR" 4
-.IX Item "-m68060"
-Generate output for a 68060. This is the default when the compiler is
-configured for 68060\-based systems. It is equivalent to
-\&\fB\-march=68060\fR.
-.Sp
-This option inhibits the use of 68020 and 68881/68882 instructions that
-have to be emulated by software on the 68060. Use this option if your 68060
-does not have code to emulate those instructions.
-.IP "\fB\-mcpu32\fR" 4
-.IX Item "-mcpu32"
-Generate output for a \s-1CPU32\s0. This is the default
-when the compiler is configured for CPU32\-based systems.
-It is equivalent to \fB\-march=cpu32\fR.
-.Sp
-Use this option for microcontrollers with a
-\&\s-1CPU32\s0 or \s-1CPU32+\s0 core, including the 68330, 68331, 68332, 68333, 68334,
-68336, 68340, 68341, 68349 and 68360.
-.IP "\fB\-m5200\fR" 4
-.IX Item "-m5200"
-Generate output for a 520X ColdFire \s-1CPU\s0. This is the default
-when the compiler is configured for 520X\-based systems.
-It is equivalent to \fB\-mcpu=5206\fR, and is now deprecated
-in favor of that option.
-.Sp
-Use this option for microcontroller with a 5200 core, including
-the \s-1MCF5202\s0, \s-1MCF5203\s0, \s-1MCF5204\s0 and \s-1MCF5206\s0.
-.IP "\fB\-m5206e\fR" 4
-.IX Item "-m5206e"
-Generate output for a 5206e ColdFire \s-1CPU\s0. The option is now
-deprecated in favor of the equivalent \fB\-mcpu=5206e\fR.
-.IP "\fB\-m528x\fR" 4
-.IX Item "-m528x"
-Generate output for a member of the ColdFire 528X family.
-The option is now deprecated in favor of the equivalent
-\&\fB\-mcpu=528x\fR.
-.IP "\fB\-m5307\fR" 4
-.IX Item "-m5307"
-Generate output for a ColdFire 5307 \s-1CPU\s0. The option is now deprecated
-in favor of the equivalent \fB\-mcpu=5307\fR.
-.IP "\fB\-m5407\fR" 4
-.IX Item "-m5407"
-Generate output for a ColdFire 5407 \s-1CPU\s0. The option is now deprecated
-in favor of the equivalent \fB\-mcpu=5407\fR.
-.IP "\fB\-mcfv4e\fR" 4
-.IX Item "-mcfv4e"
-Generate output for a ColdFire V4e family \s-1CPU\s0 (e.g. 547x/548x).
-This includes use of hardware floating point instructions.
-The option is equivalent to \fB\-mcpu=547x\fR, and is now
-deprecated in favor of that option.
-.IP "\fB\-m68020\-40\fR" 4
-.IX Item "-m68020-40"
-Generate output for a 68040, without using any of the new instructions.
-This results in code which can run relatively efficiently on either a
-68020/68881 or a 68030 or a 68040. The generated code does use the
-68881 instructions that are emulated on the 68040.
-.Sp
-The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-40\fR.
-.IP "\fB\-m68020\-60\fR" 4
-.IX Item "-m68020-60"
-Generate output for a 68060, without using any of the new instructions.
-This results in code which can run relatively efficiently on either a
-68020/68881 or a 68030 or a 68040. The generated code does use the
-68881 instructions that are emulated on the 68060.
-.Sp
-The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-60\fR.
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-.PD 0
-.IP "\fB\-m68881\fR" 4
-.IX Item "-m68881"
-.PD
-Generate floating-point instructions. This is the default for 68020
-and above, and for ColdFire devices that have an \s-1FPU\s0. It defines the
-macro \fB_\|_HAVE_68881_\|_\fR on M680x0 targets and \fB_\|_mcffpu_\|_\fR
-on ColdFire targets.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Do not generate floating-point instructions; use library calls instead.
-This is the default for 68000, 68010, and 68832 targets. It is also
-the default for ColdFire devices that have no \s-1FPU\s0.
-.IP "\fB\-mdiv\fR" 4
-.IX Item "-mdiv"
-.PD 0
-.IP "\fB\-mno\-div\fR" 4
-.IX Item "-mno-div"
-.PD
-Generate (do not generate) ColdFire hardware divide and remainder
-instructions. If \fB\-march\fR is used without \fB\-mcpu\fR,
-the default is \*(L"on\*(R" for ColdFire architectures and \*(L"off\*(R" for M680x0
-architectures. Otherwise, the default is taken from the target \s-1CPU\s0
-(either the default \s-1CPU\s0, or the one specified by \fB\-mcpu\fR). For
-example, the default is \*(L"off\*(R" for \fB\-mcpu=5206\fR and \*(L"on\*(R" for
-\&\fB\-mcpu=5206e\fR.
-.Sp
-gcc defines the macro \fB_\|_mcfhwdiv_\|_\fR when this option is enabled.
-.IP "\fB\-mshort\fR" 4
-.IX Item "-mshort"
-Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR.
-Additionally, parameters passed on the stack are also aligned to a
-16\-bit boundary even on targets whose \s-1API\s0 mandates promotion to 32\-bit.
-.IP "\fB\-mno\-short\fR" 4
-.IX Item "-mno-short"
-Do not consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide. This is the default.
-.IP "\fB\-mnobitfield\fR" 4
-.IX Item "-mnobitfield"
-.PD 0
-.IP "\fB\-mno\-bitfield\fR" 4
-.IX Item "-mno-bitfield"
-.PD
-Do not use the bit-field instructions. The \fB\-m68000\fR, \fB\-mcpu32\fR
-and \fB\-m5200\fR options imply \fB\-mnobitfield\fR.
-.IP "\fB\-mbitfield\fR" 4
-.IX Item "-mbitfield"
-Do use the bit-field instructions. The \fB\-m68020\fR option implies
-\&\fB\-mbitfield\fR. This is the default if you use a configuration
-designed for a 68020.
-.IP "\fB\-mrtd\fR" 4
-.IX Item "-mrtd"
-Use a different function-calling convention, in which functions
-that take a fixed number of arguments return with the \f(CW\*(C`rtd\*(C'\fR
-instruction, which pops their arguments while returning. This
-saves one instruction in the caller since there is no need to pop
-the arguments there.
-.Sp
-This calling convention is incompatible with the one normally
-used on Unix, so you cannot use it if you need to call libraries
-compiled with the Unix compiler.
-.Sp
-Also, you must provide function prototypes for all functions that
-take variable numbers of arguments (including \f(CW\*(C`printf\*(C'\fR);
-otherwise incorrect code will be generated for calls to those
-functions.
-.Sp
-In addition, seriously incorrect code will result if you call a
-function with too many arguments. (Normally, extra arguments are
-harmlessly ignored.)
-.Sp
-The \f(CW\*(C`rtd\*(C'\fR instruction is supported by the 68010, 68020, 68030,
-68040, 68060 and \s-1CPU32\s0 processors, but not by the 68000 or 5200.
-.IP "\fB\-mno\-rtd\fR" 4
-.IX Item "-mno-rtd"
-Do not use the calling conventions selected by \fB\-mrtd\fR.
-This is the default.
-.IP "\fB\-malign\-int\fR" 4
-.IX Item "-malign-int"
-.PD 0
-.IP "\fB\-mno\-align\-int\fR" 4
-.IX Item "-mno-align-int"
-.PD
-Control whether \s-1GCC\s0 aligns \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`long long\*(C'\fR,
-\&\f(CW\*(C`float\*(C'\fR, \f(CW\*(C`double\*(C'\fR, and \f(CW\*(C`long double\*(C'\fR variables on a 32\-bit
-boundary (\fB\-malign\-int\fR) or a 16\-bit boundary (\fB\-mno\-align\-int\fR).
-Aligning variables on 32\-bit boundaries produces code that runs somewhat
-faster on processors with 32\-bit busses at the expense of more memory.
-.Sp
-\&\fBWarning:\fR if you use the \fB\-malign\-int\fR switch, \s-1GCC\s0 will
-align structures containing the above types differently than
-most published application binary interface specifications for the m68k.
-.IP "\fB\-mpcrel\fR" 4
-.IX Item "-mpcrel"
-Use the pc-relative addressing mode of the 68000 directly, instead of
-using a global offset table. At present, this option implies \fB\-fpic\fR,
-allowing at most a 16\-bit offset for pc-relative addressing. \fB\-fPIC\fR is
-not presently supported with \fB\-mpcrel\fR, though this could be supported for
-68020 and higher processors.
-.IP "\fB\-mno\-strict\-align\fR" 4
-.IX Item "-mno-strict-align"
-.PD 0
-.IP "\fB\-mstrict\-align\fR" 4
-.IX Item "-mstrict-align"
-.PD
-Do not (do) assume that unaligned memory references will be handled by
-the system.
-.IP "\fB\-msep\-data\fR" 4
-.IX Item "-msep-data"
-Generate code that allows the data segment to be located in a different
-area of memory from the text segment. This allows for execute in place in
-an environment without virtual memory management. This option implies
-\&\fB\-fPIC\fR.
-.IP "\fB\-mno\-sep\-data\fR" 4
-.IX Item "-mno-sep-data"
-Generate code that assumes that the data segment follows the text segment.
-This is the default.
-.IP "\fB\-mid\-shared\-library\fR" 4
-.IX Item "-mid-shared-library"
-Generate code that supports shared libraries via the library \s-1ID\s0 method.
-This allows for execute in place and shared libraries in an environment
-without virtual memory management. This option implies \fB\-fPIC\fR.
-.IP "\fB\-mno\-id\-shared\-library\fR" 4
-.IX Item "-mno-id-shared-library"
-Generate code that doesn't assume \s-1ID\s0 based shared libraries are being used.
-This is the default.
-.IP "\fB\-mshared\-library\-id=n\fR" 4
-.IX Item "-mshared-library-id=n"
-Specified the identification number of the \s-1ID\s0 based shared library being
-compiled. Specifying a value of 0 will generate more compact code, specifying
-other values will force the allocation of that number to the current
-library but is no more space or time efficient than omitting this option.
-.IP "\fB\-mxgot\fR" 4
-.IX Item "-mxgot"
-.PD 0
-.IP "\fB\-mno\-xgot\fR" 4
-.IX Item "-mno-xgot"
-.PD
-When generating position-independent code for ColdFire, generate code
-that works if the \s-1GOT\s0 has more than 8192 entries. This code is
-larger and slower than code generated without this option. On M680x0
-processors, this option is not needed; \fB\-fPIC\fR suffices.
-.Sp
-\&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT\s0.
-While this is relatively efficient, it only works if the \s-1GOT\s0
-is smaller than about 64k. Anything larger causes the linker
-to report an error such as:
-.Sp
-.Vb 1
-\& relocation truncated to fit: R_68K_GOT16O foobar
-.Ve
-.Sp
-If this happens, you should recompile your code with \fB\-mxgot\fR.
-It should then work with very large GOTs. However, code generated with
-\&\fB\-mxgot\fR is less efficient, since it takes 4 instructions to fetch
-the value of a global symbol.
-.Sp
-Note that some linkers, including newer versions of the \s-1GNU\s0 linker,
-can create multiple GOTs and sort \s-1GOT\s0 entries. If you have such a linker,
-you should only need to use \fB\-mxgot\fR when compiling a single
-object file that accesses more than 8192 \s-1GOT\s0 entries. Very few do.
-.Sp
-These options have no effect unless \s-1GCC\s0 is generating
-position-independent code.
-.PP
-\fIM68hc1x Options\fR
-.IX Subsection "M68hc1x Options"
-.PP
-These are the \fB\-m\fR options defined for the 68hc11 and 68hc12
-microcontrollers. The default values for these options depends on
-which style of microcontroller was selected when the compiler was configured;
-the defaults for the most common choices are given below.
-.IP "\fB\-m6811\fR" 4
-.IX Item "-m6811"
-.PD 0
-.IP "\fB\-m68hc11\fR" 4
-.IX Item "-m68hc11"
-.PD
-Generate output for a 68HC11. This is the default
-when the compiler is configured for 68HC11\-based systems.
-.IP "\fB\-m6812\fR" 4
-.IX Item "-m6812"
-.PD 0
-.IP "\fB\-m68hc12\fR" 4
-.IX Item "-m68hc12"
-.PD
-Generate output for a 68HC12. This is the default
-when the compiler is configured for 68HC12\-based systems.
-.IP "\fB\-m68S12\fR" 4
-.IX Item "-m68S12"
-.PD 0
-.IP "\fB\-m68hcs12\fR" 4
-.IX Item "-m68hcs12"
-.PD
-Generate output for a 68HCS12.
-.IP "\fB\-mauto\-incdec\fR" 4
-.IX Item "-mauto-incdec"
-Enable the use of 68HC12 pre and post auto-increment and auto-decrement
-addressing modes.
-.IP "\fB\-minmax\fR" 4
-.IX Item "-minmax"
-.PD 0
-.IP "\fB\-mnominmax\fR" 4
-.IX Item "-mnominmax"
-.PD
-Enable the use of 68HC12 min and max instructions.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-.PD 0
-.IP "\fB\-mno\-long\-calls\fR" 4
-.IX Item "-mno-long-calls"
-.PD
-Treat all calls as being far away (near). If calls are assumed to be
-far away, the compiler will use the \f(CW\*(C`call\*(C'\fR instruction to
-call a function and the \f(CW\*(C`rtc\*(C'\fR instruction for returning.
-.IP "\fB\-mshort\fR" 4
-.IX Item "-mshort"
-Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR.
-.IP "\fB\-msoft\-reg\-count=\fR\fIcount\fR" 4
-.IX Item "-msoft-reg-count=count"
-Specify the number of pseudo-soft registers which are used for the
-code generation. The maximum number is 32. Using more pseudo-soft
-register may or may not result in better code depending on the program.
-The default is 4 for 68HC11 and 2 for 68HC12.
-.PP
-\fIMCore Options\fR
-.IX Subsection "MCore Options"
-.PP
-These are the \fB\-m\fR options defined for the Motorola M*Core
-processors.
-.IP "\fB\-mhardlit\fR" 4
-.IX Item "-mhardlit"
-.PD 0
-.IP "\fB\-mno\-hardlit\fR" 4
-.IX Item "-mno-hardlit"
-.PD
-Inline constants into the code stream if it can be done in two
-instructions or less.
-.IP "\fB\-mdiv\fR" 4
-.IX Item "-mdiv"
-.PD 0
-.IP "\fB\-mno\-div\fR" 4
-.IX Item "-mno-div"
-.PD
-Use the divide instruction. (Enabled by default).
-.IP "\fB\-mrelax\-immediate\fR" 4
-.IX Item "-mrelax-immediate"
-.PD 0
-.IP "\fB\-mno\-relax\-immediate\fR" 4
-.IX Item "-mno-relax-immediate"
-.PD
-Allow arbitrary sized immediates in bit operations.
-.IP "\fB\-mwide\-bitfields\fR" 4
-.IX Item "-mwide-bitfields"
-.PD 0
-.IP "\fB\-mno\-wide\-bitfields\fR" 4
-.IX Item "-mno-wide-bitfields"
-.PD
-Always treat bit-fields as int-sized.
-.IP "\fB\-m4byte\-functions\fR" 4
-.IX Item "-m4byte-functions"
-.PD 0
-.IP "\fB\-mno\-4byte\-functions\fR" 4
-.IX Item "-mno-4byte-functions"
-.PD
-Force all functions to be aligned to a four byte boundary.
-.IP "\fB\-mcallgraph\-data\fR" 4
-.IX Item "-mcallgraph-data"
-.PD 0
-.IP "\fB\-mno\-callgraph\-data\fR" 4
-.IX Item "-mno-callgraph-data"
-.PD
-Emit callgraph information.
-.IP "\fB\-mslow\-bytes\fR" 4
-.IX Item "-mslow-bytes"
-.PD 0
-.IP "\fB\-mno\-slow\-bytes\fR" 4
-.IX Item "-mno-slow-bytes"
-.PD
-Prefer word access when reading byte quantities.
-.IP "\fB\-mlittle\-endian\fR" 4
-.IX Item "-mlittle-endian"
-.PD 0
-.IP "\fB\-mbig\-endian\fR" 4
-.IX Item "-mbig-endian"
-.PD
-Generate code for a little endian target.
-.IP "\fB\-m210\fR" 4
-.IX Item "-m210"
-.PD 0
-.IP "\fB\-m340\fR" 4
-.IX Item "-m340"
-.PD
-Generate code for the 210 processor.
-.IP "\fB\-mno\-lsim\fR" 4
-.IX Item "-mno-lsim"
-Assume that run-time support has been provided and so omit the
-simulator library (\fIlibsim.a)\fR from the linker command line.
-.IP "\fB\-mstack\-increment=\fR\fIsize\fR" 4
-.IX Item "-mstack-increment=size"
-Set the maximum amount for a single stack increment operation. Large
-values can increase the speed of programs which contain functions
-that need a large amount of stack space, but they can also trigger a
-segmentation fault if the stack is extended too much. The default
-value is 0x1000.
-.PP
-\fIMeP Options\fR
-.IX Subsection "MeP Options"
-.IP "\fB\-mabsdiff\fR" 4
-.IX Item "-mabsdiff"
-Enables the \f(CW\*(C`abs\*(C'\fR instruction, which is the absolute difference
-between two registers.
-.IP "\fB\-mall\-opts\fR" 4
-.IX Item "-mall-opts"
-Enables all the optional instructions \- average, multiply, divide, bit
-operations, leading zero, absolute difference, min/max, clip, and
-saturation.
-.IP "\fB\-maverage\fR" 4
-.IX Item "-maverage"
-Enables the \f(CW\*(C`ave\*(C'\fR instruction, which computes the average of two
-registers.
-.IP "\fB\-mbased=\fR\fIn\fR" 4
-.IX Item "-mbased=n"
-Variables of size \fIn\fR bytes or smaller will be placed in the
-\&\f(CW\*(C`.based\*(C'\fR section by default. Based variables use the \f(CW$tp\fR
-register as a base register, and there is a 128 byte limit to the
-\&\f(CW\*(C`.based\*(C'\fR section.
-.IP "\fB\-mbitops\fR" 4
-.IX Item "-mbitops"
-Enables the bit operation instructions \- bit test (\f(CW\*(C`btstm\*(C'\fR), set
-(\f(CW\*(C`bsetm\*(C'\fR), clear (\f(CW\*(C`bclrm\*(C'\fR), invert (\f(CW\*(C`bnotm\*(C'\fR), and
-test-and-set (\f(CW\*(C`tas\*(C'\fR).
-.IP "\fB\-mc=\fR\fIname\fR" 4
-.IX Item "-mc=name"
-Selects which section constant data will be placed in. \fIname\fR may
-be \f(CW\*(C`tiny\*(C'\fR, \f(CW\*(C`near\*(C'\fR, or \f(CW\*(C`far\*(C'\fR.
-.IP "\fB\-mclip\fR" 4
-.IX Item "-mclip"
-Enables the \f(CW\*(C`clip\*(C'\fR instruction. Note that \f(CW\*(C`\-mclip\*(C'\fR is not
-useful unless you also provide \f(CW\*(C`\-mminmax\*(C'\fR.
-.IP "\fB\-mconfig=\fR\fIname\fR" 4
-.IX Item "-mconfig=name"
-Selects one of the build-in core configurations. Each MeP chip has
-one or more modules in it; each module has a core \s-1CPU\s0 and a variety of
-coprocessors, optional instructions, and peripherals. The
-\&\f(CW\*(C`MeP\-Integrator\*(C'\fR tool, not part of \s-1GCC\s0, provides these
-configurations through this option; using this option is the same as
-using all the corresponding command line options. The default
-configuration is \f(CW\*(C`default\*(C'\fR.
-.IP "\fB\-mcop\fR" 4
-.IX Item "-mcop"
-Enables the coprocessor instructions. By default, this is a 32\-bit
-coprocessor. Note that the coprocessor is normally enabled via the
-\&\f(CW\*(C`\-mconfig=\*(C'\fR option.
-.IP "\fB\-mcop32\fR" 4
-.IX Item "-mcop32"
-Enables the 32\-bit coprocessor's instructions.
-.IP "\fB\-mcop64\fR" 4
-.IX Item "-mcop64"
-Enables the 64\-bit coprocessor's instructions.
-.IP "\fB\-mivc2\fR" 4
-.IX Item "-mivc2"
-Enables \s-1IVC2\s0 scheduling. \s-1IVC2\s0 is a 64\-bit \s-1VLIW\s0 coprocessor.
-.IP "\fB\-mdc\fR" 4
-.IX Item "-mdc"
-Causes constant variables to be placed in the \f(CW\*(C`.near\*(C'\fR section.
-.IP "\fB\-mdiv\fR" 4
-.IX Item "-mdiv"
-Enables the \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`divu\*(C'\fR instructions.
-.IP "\fB\-meb\fR" 4
-.IX Item "-meb"
-Generate big-endian code.
-.IP "\fB\-mel\fR" 4
-.IX Item "-mel"
-Generate little-endian code.
-.IP "\fB\-mio\-volatile\fR" 4
-.IX Item "-mio-volatile"
-Tells the compiler that any variable marked with the \f(CW\*(C`io\*(C'\fR
-attribute is to be considered volatile.
-.IP "\fB\-ml\fR" 4
-.IX Item "-ml"
-Causes variables to be assigned to the \f(CW\*(C`.far\*(C'\fR section by default.
-.IP "\fB\-mleadz\fR" 4
-.IX Item "-mleadz"
-Enables the \f(CW\*(C`leadz\*(C'\fR (leading zero) instruction.
-.IP "\fB\-mm\fR" 4
-.IX Item "-mm"
-Causes variables to be assigned to the \f(CW\*(C`.near\*(C'\fR section by default.
-.IP "\fB\-mminmax\fR" 4
-.IX Item "-mminmax"
-Enables the \f(CW\*(C`min\*(C'\fR and \f(CW\*(C`max\*(C'\fR instructions.
-.IP "\fB\-mmult\fR" 4
-.IX Item "-mmult"
-Enables the multiplication and multiply-accumulate instructions.
-.IP "\fB\-mno\-opts\fR" 4
-.IX Item "-mno-opts"
-Disables all the optional instructions enabled by \f(CW\*(C`\-mall\-opts\*(C'\fR.
-.IP "\fB\-mrepeat\fR" 4
-.IX Item "-mrepeat"
-Enables the \f(CW\*(C`repeat\*(C'\fR and \f(CW\*(C`erepeat\*(C'\fR instructions, used for
-low-overhead looping.
-.IP "\fB\-ms\fR" 4
-.IX Item "-ms"
-Causes all variables to default to the \f(CW\*(C`.tiny\*(C'\fR section. Note
-that there is a 65536 byte limit to this section. Accesses to these
-variables use the \f(CW%gp\fR base register.
-.IP "\fB\-msatur\fR" 4
-.IX Item "-msatur"
-Enables the saturation instructions. Note that the compiler does not
-currently generate these itself, but this option is included for
-compatibility with other tools, like \f(CW\*(C`as\*(C'\fR.
-.IP "\fB\-msdram\fR" 4
-.IX Item "-msdram"
-Link the SDRAM-based runtime instead of the default ROM-based runtime.
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-Link the simulator runtime libraries.
-.IP "\fB\-msimnovec\fR" 4
-.IX Item "-msimnovec"
-Link the simulator runtime libraries, excluding built-in support
-for reset and exception vectors and tables.
-.IP "\fB\-mtf\fR" 4
-.IX Item "-mtf"
-Causes all functions to default to the \f(CW\*(C`.far\*(C'\fR section. Without
-this option, functions default to the \f(CW\*(C`.near\*(C'\fR section.
-.IP "\fB\-mtiny=\fR\fIn\fR" 4
-.IX Item "-mtiny=n"
-Variables that are \fIn\fR bytes or smaller will be allocated to the
-\&\f(CW\*(C`.tiny\*(C'\fR section. These variables use the \f(CW$gp\fR base
-register. The default for this option is 4, but note that there's a
-65536 byte limit to the \f(CW\*(C`.tiny\*(C'\fR section.
-.PP
-\fIMicroBlaze Options\fR
-.IX Subsection "MicroBlaze Options"
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Use software emulation for floating point (default).
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-Use hardware floating point instructions.
-.IP "\fB\-mmemcpy\fR" 4
-.IX Item "-mmemcpy"
-Do not optimize block moves, use \f(CW\*(C`memcpy\*(C'\fR.
-.IP "\fB\-mno\-clearbss\fR" 4
-.IX Item "-mno-clearbss"
-This option is deprecated. Use \fB\-fno\-zero\-initialized\-in\-bss\fR instead.
-.IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
-.IX Item "-mcpu=cpu-type"
-Use features of and schedule code for given \s-1CPU\s0.
-Supported values are in the format \fBv\fR\fIX\fR\fB.\fR\fI\s-1YY\s0\fR\fB.\fR\fIZ\fR,
-where \fIX\fR is a major version, \fI\s-1YY\s0\fR is the minor version, and
-\&\fIZ\fR is compatibility code. Example values are \fBv3.00.a\fR,
-\&\fBv4.00.b\fR, \fBv5.00.a\fR, \fBv5.00.b\fR, \fBv5.00.b\fR, \fBv6.00.a\fR.
-.IP "\fB\-mxl\-soft\-mul\fR" 4
-.IX Item "-mxl-soft-mul"
-Use software multiply emulation (default).
-.IP "\fB\-mxl\-soft\-div\fR" 4
-.IX Item "-mxl-soft-div"
-Use software emulation for divides (default).
-.IP "\fB\-mxl\-barrel\-shift\fR" 4
-.IX Item "-mxl-barrel-shift"
-Use the hardware barrel shifter.
-.IP "\fB\-mxl\-pattern\-compare\fR" 4
-.IX Item "-mxl-pattern-compare"
-Use pattern compare instructions.
-.IP "\fB\-msmall\-divides\fR" 4
-.IX Item "-msmall-divides"
-Use table lookup optimization for small signed integer divisions.
-.IP "\fB\-mxl\-stack\-check\fR" 4
-.IX Item "-mxl-stack-check"
-This option is deprecated. Use \-fstack\-check instead.
-.IP "\fB\-mxl\-gp\-opt\fR" 4
-.IX Item "-mxl-gp-opt"
-Use \s-1GP\s0 relative sdata/sbss sections.
-.IP "\fB\-mxl\-multiply\-high\fR" 4
-.IX Item "-mxl-multiply-high"
-Use multiply high instructions for high part of 32x32 multiply.
-.IP "\fB\-mxl\-float\-convert\fR" 4
-.IX Item "-mxl-float-convert"
-Use hardware floating point conversion instructions.
-.IP "\fB\-mxl\-float\-sqrt\fR" 4
-.IX Item "-mxl-float-sqrt"
-Use hardware floating point square root instruction.
-.IP "\fB\-mxl\-mode\-\fR\fIapp-model\fR" 4
-.IX Item "-mxl-mode-app-model"
-Select application model \fIapp-model\fR. Valid models are
-.RS 4
-.IP "\fBexecutable\fR" 4
-.IX Item "executable"
-normal executable (default), uses startup code \fIcrt0.o\fR.
-.IP "\fBxmdstub\fR" 4
-.IX Item "xmdstub"
-for use with Xilinx Microprocessor Debugger (\s-1XMD\s0) based
-software intrusive debug agent called xmdstub. This uses startup file
-\&\fIcrt1.o\fR and sets the start address of the program to be 0x800.
-.IP "\fBbootstrap\fR" 4
-.IX Item "bootstrap"
-for applications that are loaded using a bootloader.
-This model uses startup file \fIcrt2.o\fR which does not contain a processor
-reset vector handler. This is suitable for transferring control on a
-processor reset to the bootloader rather than the application.
-.IP "\fBnovectors\fR" 4
-.IX Item "novectors"
-for applications that do not require any of the
-MicroBlaze vectors. This option may be useful for applications running
-within a monitoring application. This model uses \fIcrt3.o\fR as a startup file.
-.RE
-.RS 4
-.Sp
-Option \fB\-xl\-mode\-\fR\fIapp-model\fR is a deprecated alias for
-\&\fB\-mxl\-mode\-\fR\fIapp-model\fR.
-.RE
-.PP
-\fI\s-1MIPS\s0 Options\fR
-.IX Subsection "MIPS Options"
-.IP "\fB\-EB\fR" 4
-.IX Item "-EB"
-Generate big-endian code.
-.IP "\fB\-EL\fR" 4
-.IX Item "-EL"
-Generate little-endian code. This is the default for \fBmips*el\-*\-*\fR
-configurations.
-.IP "\fB\-march=\fR\fIarch\fR" 4
-.IX Item "-march=arch"
-Generate code that will run on \fIarch\fR, which can be the name of a
-generic \s-1MIPS\s0 \s-1ISA\s0, or the name of a particular processor.
-The \s-1ISA\s0 names are:
-\&\fBmips1\fR, \fBmips2\fR, \fBmips3\fR, \fBmips4\fR,
-\&\fBmips32\fR, \fBmips32r2\fR, \fBmips64\fR and \fBmips64r2\fR.
-The processor names are:
-\&\fB4kc\fR, \fB4km\fR, \fB4kp\fR, \fB4ksc\fR,
-\&\fB4kec\fR, \fB4kem\fR, \fB4kep\fR, \fB4ksd\fR,
-\&\fB5kc\fR, \fB5kf\fR,
-\&\fB20kc\fR,
-\&\fB24kc\fR, \fB24kf2_1\fR, \fB24kf1_1\fR,
-\&\fB24kec\fR, \fB24kef2_1\fR, \fB24kef1_1\fR,
-\&\fB34kc\fR, \fB34kf2_1\fR, \fB34kf1_1\fR,
-\&\fB74kc\fR, \fB74kf2_1\fR, \fB74kf1_1\fR, \fB74kf3_2\fR,
-\&\fB1004kc\fR, \fB1004kf2_1\fR, \fB1004kf1_1\fR,
-\&\fBloongson2e\fR, \fBloongson2f\fR, \fBloongson3a\fR,
-\&\fBm4k\fR,
-\&\fBocteon\fR,
-\&\fBorion\fR,
-\&\fBr2000\fR, \fBr3000\fR, \fBr3900\fR, \fBr4000\fR, \fBr4400\fR,
-\&\fBr4600\fR, \fBr4650\fR, \fBr6000\fR, \fBr8000\fR,
-\&\fBrm7000\fR, \fBrm9000\fR,
-\&\fBr10000\fR, \fBr12000\fR, \fBr14000\fR, \fBr16000\fR,
-\&\fBsb1\fR,
-\&\fBsr71000\fR,
-\&\fBvr4100\fR, \fBvr4111\fR, \fBvr4120\fR, \fBvr4130\fR, \fBvr4300\fR,
-\&\fBvr5000\fR, \fBvr5400\fR, \fBvr5500\fR
-and \fBxlr\fR.
-The special value \fBfrom-abi\fR selects the
-most compatible architecture for the selected \s-1ABI\s0 (that is,
-\&\fBmips1\fR for 32\-bit ABIs and \fBmips3\fR for 64\-bit ABIs).
-.Sp
-Native Linux/GNU toolchains also support the value \fBnative\fR,
-which selects the best architecture option for the host processor.
-\&\fB\-march=native\fR has no effect if \s-1GCC\s0 does not recognize
-the processor.
-.Sp
-In processor names, a final \fB000\fR can be abbreviated as \fBk\fR
-(for example, \fB\-march=r2k\fR). Prefixes are optional, and
-\&\fBvr\fR may be written \fBr\fR.
-.Sp
-Names of the form \fIn\fR\fBf2_1\fR refer to processors with
-FPUs clocked at half the rate of the core, names of the form
-\&\fIn\fR\fBf1_1\fR refer to processors with FPUs clocked at the same
-rate as the core, and names of the form \fIn\fR\fBf3_2\fR refer to
-processors with FPUs clocked a ratio of 3:2 with respect to the core.
-For compatibility reasons, \fIn\fR\fBf\fR is accepted as a synonym
-for \fIn\fR\fBf2_1\fR while \fIn\fR\fBx\fR and \fIb\fR\fBfx\fR are
-accepted as synonyms for \fIn\fR\fBf1_1\fR.
-.Sp
-\&\s-1GCC\s0 defines two macros based on the value of this option. The first
-is \fB_MIPS_ARCH\fR, which gives the name of target architecture, as
-a string. The second has the form \fB_MIPS_ARCH_\fR\fIfoo\fR,
-where \fIfoo\fR is the capitalized value of \fB_MIPS_ARCH\fR.
-For example, \fB\-march=r2000\fR will set \fB_MIPS_ARCH\fR
-to \fB\*(L"r2000\*(R"\fR and define the macro \fB_MIPS_ARCH_R2000\fR.
-.Sp
-Note that the \fB_MIPS_ARCH\fR macro uses the processor names given
-above. In other words, it will have the full prefix and will not
-abbreviate \fB000\fR as \fBk\fR. In the case of \fBfrom-abi\fR,
-the macro names the resolved architecture (either \fB\*(L"mips1\*(R"\fR or
-\&\fB\*(L"mips3\*(R"\fR). It names the default architecture when no
-\&\fB\-march\fR option is given.
-.IP "\fB\-mtune=\fR\fIarch\fR" 4
-.IX Item "-mtune=arch"
-Optimize for \fIarch\fR. Among other things, this option controls
-the way instructions are scheduled, and the perceived cost of arithmetic
-operations. The list of \fIarch\fR values is the same as for
-\&\fB\-march\fR.
-.Sp
-When this option is not used, \s-1GCC\s0 will optimize for the processor
-specified by \fB\-march\fR. By using \fB\-march\fR and
-\&\fB\-mtune\fR together, it is possible to generate code that will
-run on a family of processors, but optimize the code for one
-particular member of that family.
-.Sp
-\&\fB\-mtune\fR defines the macros \fB_MIPS_TUNE\fR and
-\&\fB_MIPS_TUNE_\fR\fIfoo\fR, which work in the same way as the
-\&\fB\-march\fR ones described above.
-.IP "\fB\-mips1\fR" 4
-.IX Item "-mips1"
-Equivalent to \fB\-march=mips1\fR.
-.IP "\fB\-mips2\fR" 4
-.IX Item "-mips2"
-Equivalent to \fB\-march=mips2\fR.
-.IP "\fB\-mips3\fR" 4
-.IX Item "-mips3"
-Equivalent to \fB\-march=mips3\fR.
-.IP "\fB\-mips4\fR" 4
-.IX Item "-mips4"
-Equivalent to \fB\-march=mips4\fR.
-.IP "\fB\-mips32\fR" 4
-.IX Item "-mips32"
-Equivalent to \fB\-march=mips32\fR.
-.IP "\fB\-mips32r2\fR" 4
-.IX Item "-mips32r2"
-Equivalent to \fB\-march=mips32r2\fR.
-.IP "\fB\-mips64\fR" 4
-.IX Item "-mips64"
-Equivalent to \fB\-march=mips64\fR.
-.IP "\fB\-mips64r2\fR" 4
-.IX Item "-mips64r2"
-Equivalent to \fB\-march=mips64r2\fR.
-.IP "\fB\-mips16\fR" 4
-.IX Item "-mips16"
-.PD 0
-.IP "\fB\-mno\-mips16\fR" 4
-.IX Item "-mno-mips16"
-.PD
-Generate (do not generate) \s-1MIPS16\s0 code. If \s-1GCC\s0 is targetting a
-\&\s-1MIPS32\s0 or \s-1MIPS64\s0 architecture, it will make use of the MIPS16e \s-1ASE\s0.
-.Sp
-\&\s-1MIPS16\s0 code generation can also be controlled on a per-function basis
-by means of \f(CW\*(C`mips16\*(C'\fR and \f(CW\*(C`nomips16\*(C'\fR attributes.
-.IP "\fB\-mflip\-mips16\fR" 4
-.IX Item "-mflip-mips16"
-Generate \s-1MIPS16\s0 code on alternating functions. This option is provided
-for regression testing of mixed MIPS16/non\-MIPS16 code generation, and is
-not intended for ordinary use in compiling user code.
-.IP "\fB\-minterlink\-mips16\fR" 4
-.IX Item "-minterlink-mips16"
-.PD 0
-.IP "\fB\-mno\-interlink\-mips16\fR" 4
-.IX Item "-mno-interlink-mips16"
-.PD
-Require (do not require) that non\-MIPS16 code be link-compatible with
-\&\s-1MIPS16\s0 code.
-.Sp
-For example, non\-MIPS16 code cannot jump directly to \s-1MIPS16\s0 code;
-it must either use a call or an indirect jump. \fB\-minterlink\-mips16\fR
-therefore disables direct jumps unless \s-1GCC\s0 knows that the target of the
-jump is not \s-1MIPS16\s0.
-.IP "\fB\-mabi=32\fR" 4
-.IX Item "-mabi=32"
-.PD 0
-.IP "\fB\-mabi=o64\fR" 4
-.IX Item "-mabi=o64"
-.IP "\fB\-mabi=n32\fR" 4
-.IX Item "-mabi=n32"
-.IP "\fB\-mabi=64\fR" 4
-.IX Item "-mabi=64"
-.IP "\fB\-mabi=eabi\fR" 4
-.IX Item "-mabi=eabi"
-.PD
-Generate code for the given \s-1ABI\s0.
-.Sp
-Note that the \s-1EABI\s0 has a 32\-bit and a 64\-bit variant. \s-1GCC\s0 normally
-generates 64\-bit code when you select a 64\-bit architecture, but you
-can use \fB\-mgp32\fR to get 32\-bit code instead.
-.Sp
-For information about the O64 \s-1ABI\s0, see
-<\fBhttp://gcc.gnu.org/projects/mipso64\-abi.html\fR>.
-.Sp
-\&\s-1GCC\s0 supports a variant of the o32 \s-1ABI\s0 in which floating-point registers
-are 64 rather than 32 bits wide. You can select this combination with
-\&\fB\-mabi=32\fR \fB\-mfp64\fR. This \s-1ABI\s0 relies on the \fBmthc1\fR
-and \fBmfhc1\fR instructions and is therefore only supported for
-\&\s-1MIPS32R2\s0 processors.
-.Sp
-The register assignments for arguments and return values remain the
-same, but each scalar value is passed in a single 64\-bit register
-rather than a pair of 32\-bit registers. For example, scalar
-floating-point values are returned in \fB\f(CB$f0\fB\fR only, not a
-\&\fB\f(CB$f0\fB\fR/\fB\f(CB$f1\fB\fR pair. The set of call-saved registers also
-remains the same, but all 64 bits are saved.
-.IP "\fB\-mabicalls\fR" 4
-.IX Item "-mabicalls"
-.PD 0
-.IP "\fB\-mno\-abicalls\fR" 4
-.IX Item "-mno-abicalls"
-.PD
-Generate (do not generate) code that is suitable for SVR4\-style
-dynamic objects. \fB\-mabicalls\fR is the default for SVR4\-based
-systems.
-.IP "\fB\-mshared\fR" 4
-.IX Item "-mshared"
-.PD 0
-.IP "\fB\-mno\-shared\fR" 4
-.IX Item "-mno-shared"
-.PD
-Generate (do not generate) code that is fully position-independent,
-and that can therefore be linked into shared libraries. This option
-only affects \fB\-mabicalls\fR.
-.Sp
-All \fB\-mabicalls\fR code has traditionally been position-independent,
-regardless of options like \fB\-fPIC\fR and \fB\-fpic\fR. However,
-as an extension, the \s-1GNU\s0 toolchain allows executables to use absolute
-accesses for locally-binding symbols. It can also use shorter \s-1GP\s0
-initialization sequences and generate direct calls to locally-defined
-functions. This mode is selected by \fB\-mno\-shared\fR.
-.Sp
-\&\fB\-mno\-shared\fR depends on binutils 2.16 or higher and generates
-objects that can only be linked by the \s-1GNU\s0 linker. However, the option
-does not affect the \s-1ABI\s0 of the final executable; it only affects the \s-1ABI\s0
-of relocatable objects. Using \fB\-mno\-shared\fR will generally make
-executables both smaller and quicker.
-.Sp
-\&\fB\-mshared\fR is the default.
-.IP "\fB\-mplt\fR" 4
-.IX Item "-mplt"
-.PD 0
-.IP "\fB\-mno\-plt\fR" 4
-.IX Item "-mno-plt"
-.PD
-Assume (do not assume) that the static and dynamic linkers
-support PLTs and copy relocations. This option only affects
-\&\fB\-mno\-shared \-mabicalls\fR. For the n64 \s-1ABI\s0, this option
-has no effect without \fB\-msym32\fR.
-.Sp
-You can make \fB\-mplt\fR the default by configuring
-\&\s-1GCC\s0 with \fB\-\-with\-mips\-plt\fR. The default is
-\&\fB\-mno\-plt\fR otherwise.
-.IP "\fB\-mxgot\fR" 4
-.IX Item "-mxgot"
-.PD 0
-.IP "\fB\-mno\-xgot\fR" 4
-.IX Item "-mno-xgot"
-.PD
-Lift (do not lift) the usual restrictions on the size of the global
-offset table.
-.Sp
-\&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT\s0.
-While this is relatively efficient, it will only work if the \s-1GOT\s0
-is smaller than about 64k. Anything larger will cause the linker
-to report an error such as:
-.Sp
-.Vb 1
-\& relocation truncated to fit: R_MIPS_GOT16 foobar
-.Ve
-.Sp
-If this happens, you should recompile your code with \fB\-mxgot\fR.
-It should then work with very large GOTs, although it will also be
-less efficient, since it will take three instructions to fetch the
-value of a global symbol.
-.Sp
-Note that some linkers can create multiple GOTs. If you have such a
-linker, you should only need to use \fB\-mxgot\fR when a single object
-file accesses more than 64k's worth of \s-1GOT\s0 entries. Very few do.
-.Sp
-These options have no effect unless \s-1GCC\s0 is generating position
-independent code.
-.IP "\fB\-mgp32\fR" 4
-.IX Item "-mgp32"
-Assume that general-purpose registers are 32 bits wide.
-.IP "\fB\-mgp64\fR" 4
-.IX Item "-mgp64"
-Assume that general-purpose registers are 64 bits wide.
-.IP "\fB\-mfp32\fR" 4
-.IX Item "-mfp32"
-Assume that floating-point registers are 32 bits wide.
-.IP "\fB\-mfp64\fR" 4
-.IX Item "-mfp64"
-Assume that floating-point registers are 64 bits wide.
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-Use floating-point coprocessor instructions.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Do not use floating-point coprocessor instructions. Implement
-floating-point calculations using library calls instead.
-.IP "\fB\-msingle\-float\fR" 4
-.IX Item "-msingle-float"
-Assume that the floating-point coprocessor only supports single-precision
-operations.
-.IP "\fB\-mdouble\-float\fR" 4
-.IX Item "-mdouble-float"
-Assume that the floating-point coprocessor supports double-precision
-operations. This is the default.
-.IP "\fB\-mllsc\fR" 4
-.IX Item "-mllsc"
-.PD 0
-.IP "\fB\-mno\-llsc\fR" 4
-.IX Item "-mno-llsc"
-.PD
-Use (do not use) \fBll\fR, \fBsc\fR, and \fBsync\fR instructions to
-implement atomic memory built-in functions. When neither option is
-specified, \s-1GCC\s0 will use the instructions if the target architecture
-supports them.
-.Sp
-\&\fB\-mllsc\fR is useful if the runtime environment can emulate the
-instructions and \fB\-mno\-llsc\fR can be useful when compiling for
-nonstandard ISAs. You can make either option the default by
-configuring \s-1GCC\s0 with \fB\-\-with\-llsc\fR and \fB\-\-without\-llsc\fR
-respectively. \fB\-\-with\-llsc\fR is the default for some
-configurations; see the installation documentation for details.
-.IP "\fB\-mdsp\fR" 4
-.IX Item "-mdsp"
-.PD 0
-.IP "\fB\-mno\-dsp\fR" 4
-.IX Item "-mno-dsp"
-.PD
-Use (do not use) revision 1 of the \s-1MIPS\s0 \s-1DSP\s0 \s-1ASE\s0.
- This option defines the
-preprocessor macro \fB_\|_mips_dsp\fR. It also defines
-\&\fB_\|_mips_dsp_rev\fR to 1.
-.IP "\fB\-mdspr2\fR" 4
-.IX Item "-mdspr2"
-.PD 0
-.IP "\fB\-mno\-dspr2\fR" 4
-.IX Item "-mno-dspr2"
-.PD
-Use (do not use) revision 2 of the \s-1MIPS\s0 \s-1DSP\s0 \s-1ASE\s0.
- This option defines the
-preprocessor macros \fB_\|_mips_dsp\fR and \fB_\|_mips_dspr2\fR.
-It also defines \fB_\|_mips_dsp_rev\fR to 2.
-.IP "\fB\-msmartmips\fR" 4
-.IX Item "-msmartmips"
-.PD 0
-.IP "\fB\-mno\-smartmips\fR" 4
-.IX Item "-mno-smartmips"
-.PD
-Use (do not use) the \s-1MIPS\s0 SmartMIPS \s-1ASE\s0.
-.IP "\fB\-mpaired\-single\fR" 4
-.IX Item "-mpaired-single"
-.PD 0
-.IP "\fB\-mno\-paired\-single\fR" 4
-.IX Item "-mno-paired-single"
-.PD
-Use (do not use) paired-single floating-point instructions.
- This option requires
-hardware floating-point support to be enabled.
-.IP "\fB\-mdmx\fR" 4
-.IX Item "-mdmx"
-.PD 0
-.IP "\fB\-mno\-mdmx\fR" 4
-.IX Item "-mno-mdmx"
-.PD
-Use (do not use) \s-1MIPS\s0 Digital Media Extension instructions.
-This option can only be used when generating 64\-bit code and requires
-hardware floating-point support to be enabled.
-.IP "\fB\-mips3d\fR" 4
-.IX Item "-mips3d"
-.PD 0
-.IP "\fB\-mno\-mips3d\fR" 4
-.IX Item "-mno-mips3d"
-.PD
-Use (do not use) the \s-1MIPS\-3D\s0 \s-1ASE\s0.
-The option \fB\-mips3d\fR implies \fB\-mpaired\-single\fR.
-.IP "\fB\-mmt\fR" 4
-.IX Item "-mmt"
-.PD 0
-.IP "\fB\-mno\-mt\fR" 4
-.IX Item "-mno-mt"
-.PD
-Use (do not use) \s-1MT\s0 Multithreading instructions.
-.IP "\fB\-mlong64\fR" 4
-.IX Item "-mlong64"
-Force \f(CW\*(C`long\*(C'\fR types to be 64 bits wide. See \fB\-mlong32\fR for
-an explanation of the default and the way that the pointer size is
-determined.
-.IP "\fB\-mlong32\fR" 4
-.IX Item "-mlong32"
-Force \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`int\*(C'\fR, and pointer types to be 32 bits wide.
-.Sp
-The default size of \f(CW\*(C`int\*(C'\fRs, \f(CW\*(C`long\*(C'\fRs and pointers depends on
-the \s-1ABI\s0. All the supported ABIs use 32\-bit \f(CW\*(C`int\*(C'\fRs. The n64 \s-1ABI\s0
-uses 64\-bit \f(CW\*(C`long\*(C'\fRs, as does the 64\-bit \s-1EABI\s0; the others use
-32\-bit \f(CW\*(C`long\*(C'\fRs. Pointers are the same size as \f(CW\*(C`long\*(C'\fRs,
-or the same size as integer registers, whichever is smaller.
-.IP "\fB\-msym32\fR" 4
-.IX Item "-msym32"
-.PD 0
-.IP "\fB\-mno\-sym32\fR" 4
-.IX Item "-mno-sym32"
-.PD
-Assume (do not assume) that all symbols have 32\-bit values, regardless
-of the selected \s-1ABI\s0. This option is useful in combination with
-\&\fB\-mabi=64\fR and \fB\-mno\-abicalls\fR because it allows \s-1GCC\s0
-to generate shorter and faster references to symbolic addresses.
-.IP "\fB\-G\fR \fInum\fR" 4
-.IX Item "-G num"
-Put definitions of externally-visible data in a small data section
-if that data is no bigger than \fInum\fR bytes. \s-1GCC\s0 can then access
-the data more efficiently; see \fB\-mgpopt\fR for details.
-.Sp
-The default \fB\-G\fR option depends on the configuration.
-.IP "\fB\-mlocal\-sdata\fR" 4
-.IX Item "-mlocal-sdata"
-.PD 0
-.IP "\fB\-mno\-local\-sdata\fR" 4
-.IX Item "-mno-local-sdata"
-.PD
-Extend (do not extend) the \fB\-G\fR behavior to local data too,
-such as to static variables in C. \fB\-mlocal\-sdata\fR is the
-default for all configurations.
-.Sp
-If the linker complains that an application is using too much small data,
-you might want to try rebuilding the less performance-critical parts with
-\&\fB\-mno\-local\-sdata\fR. You might also want to build large
-libraries with \fB\-mno\-local\-sdata\fR, so that the libraries leave
-more room for the main program.
-.IP "\fB\-mextern\-sdata\fR" 4
-.IX Item "-mextern-sdata"
-.PD 0
-.IP "\fB\-mno\-extern\-sdata\fR" 4
-.IX Item "-mno-extern-sdata"
-.PD
-Assume (do not assume) that externally-defined data will be in
-a small data section if that data is within the \fB\-G\fR limit.
-\&\fB\-mextern\-sdata\fR is the default for all configurations.
-.Sp
-If you compile a module \fIMod\fR with \fB\-mextern\-sdata\fR \fB\-G\fR
-\&\fInum\fR \fB\-mgpopt\fR, and \fIMod\fR references a variable \fIVar\fR
-that is no bigger than \fInum\fR bytes, you must make sure that \fIVar\fR
-is placed in a small data section. If \fIVar\fR is defined by another
-module, you must either compile that module with a high-enough
-\&\fB\-G\fR setting or attach a \f(CW\*(C`section\*(C'\fR attribute to \fIVar\fR's
-definition. If \fIVar\fR is common, you must link the application
-with a high-enough \fB\-G\fR setting.
-.Sp
-The easiest way of satisfying these restrictions is to compile
-and link every module with the same \fB\-G\fR option. However,
-you may wish to build a library that supports several different
-small data limits. You can do this by compiling the library with
-the highest supported \fB\-G\fR setting and additionally using
-\&\fB\-mno\-extern\-sdata\fR to stop the library from making assumptions
-about externally-defined data.
-.IP "\fB\-mgpopt\fR" 4
-.IX Item "-mgpopt"
-.PD 0
-.IP "\fB\-mno\-gpopt\fR" 4
-.IX Item "-mno-gpopt"
-.PD
-Use (do not use) GP-relative accesses for symbols that are known to be
-in a small data section; see \fB\-G\fR, \fB\-mlocal\-sdata\fR and
-\&\fB\-mextern\-sdata\fR. \fB\-mgpopt\fR is the default for all
-configurations.
-.Sp
-\&\fB\-mno\-gpopt\fR is useful for cases where the \f(CW$gp\fR register
-might not hold the value of \f(CW\*(C`_gp\*(C'\fR. For example, if the code is
-part of a library that might be used in a boot monitor, programs that
-call boot monitor routines will pass an unknown value in \f(CW$gp\fR.
-(In such situations, the boot monitor itself would usually be compiled
-with \fB\-G0\fR.)
-.Sp
-\&\fB\-mno\-gpopt\fR implies \fB\-mno\-local\-sdata\fR and
-\&\fB\-mno\-extern\-sdata\fR.
-.IP "\fB\-membedded\-data\fR" 4
-.IX Item "-membedded-data"
-.PD 0
-.IP "\fB\-mno\-embedded\-data\fR" 4
-.IX Item "-mno-embedded-data"
-.PD
-Allocate variables to the read-only data section first if possible, then
-next in the small data section if possible, otherwise in data. This gives
-slightly slower code than the default, but reduces the amount of \s-1RAM\s0 required
-when executing, and thus may be preferred for some embedded systems.
-.IP "\fB\-muninit\-const\-in\-rodata\fR" 4
-.IX Item "-muninit-const-in-rodata"
-.PD 0
-.IP "\fB\-mno\-uninit\-const\-in\-rodata\fR" 4
-.IX Item "-mno-uninit-const-in-rodata"
-.PD
-Put uninitialized \f(CW\*(C`const\*(C'\fR variables in the read-only data section.
-This option is only meaningful in conjunction with \fB\-membedded\-data\fR.
-.IP "\fB\-mcode\-readable=\fR\fIsetting\fR" 4
-.IX Item "-mcode-readable=setting"
-Specify whether \s-1GCC\s0 may generate code that reads from executable sections.
-There are three possible settings:
-.RS 4
-.IP "\fB\-mcode\-readable=yes\fR" 4
-.IX Item "-mcode-readable=yes"
-Instructions may freely access executable sections. This is the
-default setting.
-.IP "\fB\-mcode\-readable=pcrel\fR" 4
-.IX Item "-mcode-readable=pcrel"
-\&\s-1MIPS16\s0 PC-relative load instructions can access executable sections,
-but other instructions must not do so. This option is useful on 4KSc
-and 4KSd processors when the code TLBs have the Read Inhibit bit set.
-It is also useful on processors that can be configured to have a dual
-instruction/data \s-1SRAM\s0 interface and that, like the M4K, automatically
-redirect PC-relative loads to the instruction \s-1RAM\s0.
-.IP "\fB\-mcode\-readable=no\fR" 4
-.IX Item "-mcode-readable=no"
-Instructions must not access executable sections. This option can be
-useful on targets that are configured to have a dual instruction/data
-\&\s-1SRAM\s0 interface but that (unlike the M4K) do not automatically redirect
-PC-relative loads to the instruction \s-1RAM\s0.
-.RE
-.RS 4
-.RE
-.IP "\fB\-msplit\-addresses\fR" 4
-.IX Item "-msplit-addresses"
-.PD 0
-.IP "\fB\-mno\-split\-addresses\fR" 4
-.IX Item "-mno-split-addresses"
-.PD
-Enable (disable) use of the \f(CW\*(C`%hi()\*(C'\fR and \f(CW\*(C`%lo()\*(C'\fR assembler
-relocation operators. This option has been superseded by
-\&\fB\-mexplicit\-relocs\fR but is retained for backwards compatibility.
-.IP "\fB\-mexplicit\-relocs\fR" 4
-.IX Item "-mexplicit-relocs"
-.PD 0
-.IP "\fB\-mno\-explicit\-relocs\fR" 4
-.IX Item "-mno-explicit-relocs"
-.PD
-Use (do not use) assembler relocation operators when dealing with symbolic
-addresses. The alternative, selected by \fB\-mno\-explicit\-relocs\fR,
-is to use assembler macros instead.
-.Sp
-\&\fB\-mexplicit\-relocs\fR is the default if \s-1GCC\s0 was configured
-to use an assembler that supports relocation operators.
-.IP "\fB\-mcheck\-zero\-division\fR" 4
-.IX Item "-mcheck-zero-division"
-.PD 0
-.IP "\fB\-mno\-check\-zero\-division\fR" 4
-.IX Item "-mno-check-zero-division"
-.PD
-Trap (do not trap) on integer division by zero.
-.Sp
-The default is \fB\-mcheck\-zero\-division\fR.
-.IP "\fB\-mdivide\-traps\fR" 4
-.IX Item "-mdivide-traps"
-.PD 0
-.IP "\fB\-mdivide\-breaks\fR" 4
-.IX Item "-mdivide-breaks"
-.PD
-\&\s-1MIPS\s0 systems check for division by zero by generating either a
-conditional trap or a break instruction. Using traps results in
-smaller code, but is only supported on \s-1MIPS\s0 \s-1II\s0 and later. Also, some
-versions of the Linux kernel have a bug that prevents trap from
-generating the proper signal (\f(CW\*(C`SIGFPE\*(C'\fR). Use \fB\-mdivide\-traps\fR to
-allow conditional traps on architectures that support them and
-\&\fB\-mdivide\-breaks\fR to force the use of breaks.
-.Sp
-The default is usually \fB\-mdivide\-traps\fR, but this can be
-overridden at configure time using \fB\-\-with\-divide=breaks\fR.
-Divide-by-zero checks can be completely disabled using
-\&\fB\-mno\-check\-zero\-division\fR.
-.IP "\fB\-mmemcpy\fR" 4
-.IX Item "-mmemcpy"
-.PD 0
-.IP "\fB\-mno\-memcpy\fR" 4
-.IX Item "-mno-memcpy"
-.PD
-Force (do not force) the use of \f(CW\*(C`memcpy()\*(C'\fR for non-trivial block
-moves. The default is \fB\-mno\-memcpy\fR, which allows \s-1GCC\s0 to inline
-most constant-sized copies.
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-.PD 0
-.IP "\fB\-mno\-long\-calls\fR" 4
-.IX Item "-mno-long-calls"
-.PD
-Disable (do not disable) use of the \f(CW\*(C`jal\*(C'\fR instruction. Calling
-functions using \f(CW\*(C`jal\*(C'\fR is more efficient but requires the caller
-and callee to be in the same 256 megabyte segment.
-.Sp
-This option has no effect on abicalls code. The default is
-\&\fB\-mno\-long\-calls\fR.
-.IP "\fB\-mmad\fR" 4
-.IX Item "-mmad"
-.PD 0
-.IP "\fB\-mno\-mad\fR" 4
-.IX Item "-mno-mad"
-.PD
-Enable (disable) use of the \f(CW\*(C`mad\*(C'\fR, \f(CW\*(C`madu\*(C'\fR and \f(CW\*(C`mul\*(C'\fR
-instructions, as provided by the R4650 \s-1ISA\s0.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Enable (disable) use of the floating point multiply-accumulate
-instructions, when they are available. The default is
-\&\fB\-mfused\-madd\fR.
-.Sp
-When multiply-accumulate instructions are used, the intermediate
-product is calculated to infinite precision and is not subject to
-the \s-1FCSR\s0 Flush to Zero bit. This may be undesirable in some
-circumstances.
-.IP "\fB\-nocpp\fR" 4
-.IX Item "-nocpp"
-Tell the \s-1MIPS\s0 assembler to not run its preprocessor over user
-assembler files (with a \fB.s\fR suffix) when assembling them.
-.IP "\fB\-mfix\-r4000\fR" 4
-.IX Item "-mfix-r4000"
-.PD 0
-.IP "\fB\-mno\-fix\-r4000\fR" 4
-.IX Item "-mno-fix-r4000"
-.PD
-Work around certain R4000 \s-1CPU\s0 errata:
-.RS 4
-.IP "\-" 4
-A double-word or a variable shift may give an incorrect result if executed
-immediately after starting an integer division.
-.IP "\-" 4
-A double-word or a variable shift may give an incorrect result if executed
-while an integer multiplication is in progress.
-.IP "\-" 4
-An integer division may give an incorrect result if started in a delay slot
-of a taken branch or a jump.
-.RE
-.RS 4
-.RE
-.IP "\fB\-mfix\-r4400\fR" 4
-.IX Item "-mfix-r4400"
-.PD 0
-.IP "\fB\-mno\-fix\-r4400\fR" 4
-.IX Item "-mno-fix-r4400"
-.PD
-Work around certain R4400 \s-1CPU\s0 errata:
-.RS 4
-.IP "\-" 4
-A double-word or a variable shift may give an incorrect result if executed
-immediately after starting an integer division.
-.RE
-.RS 4
-.RE
-.IP "\fB\-mfix\-r10000\fR" 4
-.IX Item "-mfix-r10000"
-.PD 0
-.IP "\fB\-mno\-fix\-r10000\fR" 4
-.IX Item "-mno-fix-r10000"
-.PD
-Work around certain R10000 errata:
-.RS 4
-.IP "\-" 4
-\&\f(CW\*(C`ll\*(C'\fR/\f(CW\*(C`sc\*(C'\fR sequences may not behave atomically on revisions
-prior to 3.0. They may deadlock on revisions 2.6 and earlier.
-.RE
-.RS 4
-.Sp
-This option can only be used if the target architecture supports
-branch-likely instructions. \fB\-mfix\-r10000\fR is the default when
-\&\fB\-march=r10000\fR is used; \fB\-mno\-fix\-r10000\fR is the default
-otherwise.
-.RE
-.IP "\fB\-mfix\-vr4120\fR" 4
-.IX Item "-mfix-vr4120"
-.PD 0
-.IP "\fB\-mno\-fix\-vr4120\fR" 4
-.IX Item "-mno-fix-vr4120"
-.PD
-Work around certain \s-1VR4120\s0 errata:
-.RS 4
-.IP "\-" 4
-\&\f(CW\*(C`dmultu\*(C'\fR does not always produce the correct result.
-.IP "\-" 4
-\&\f(CW\*(C`div\*(C'\fR and \f(CW\*(C`ddiv\*(C'\fR do not always produce the correct result if one
-of the operands is negative.
-.RE
-.RS 4
-.Sp
-The workarounds for the division errata rely on special functions in
-\&\fIlibgcc.a\fR. At present, these functions are only provided by
-the \f(CW\*(C`mips64vr*\-elf\*(C'\fR configurations.
-.Sp
-Other \s-1VR4120\s0 errata require a nop to be inserted between certain pairs of
-instructions. These errata are handled by the assembler, not by \s-1GCC\s0 itself.
-.RE
-.IP "\fB\-mfix\-vr4130\fR" 4
-.IX Item "-mfix-vr4130"
-Work around the \s-1VR4130\s0 \f(CW\*(C`mflo\*(C'\fR/\f(CW\*(C`mfhi\*(C'\fR errata. The
-workarounds are implemented by the assembler rather than by \s-1GCC\s0,
-although \s-1GCC\s0 will avoid using \f(CW\*(C`mflo\*(C'\fR and \f(CW\*(C`mfhi\*(C'\fR if the
-\&\s-1VR4130\s0 \f(CW\*(C`macc\*(C'\fR, \f(CW\*(C`macchi\*(C'\fR, \f(CW\*(C`dmacc\*(C'\fR and \f(CW\*(C`dmacchi\*(C'\fR
-instructions are available instead.
-.IP "\fB\-mfix\-sb1\fR" 4
-.IX Item "-mfix-sb1"
-.PD 0
-.IP "\fB\-mno\-fix\-sb1\fR" 4
-.IX Item "-mno-fix-sb1"
-.PD
-Work around certain \s-1SB\-1\s0 \s-1CPU\s0 core errata.
-(This flag currently works around the \s-1SB\-1\s0 revision 2
-\&\*(L"F1\*(R" and \*(L"F2\*(R" floating point errata.)
-.IP "\fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR" 4
-.IX Item "-mr10k-cache-barrier=setting"
-Specify whether \s-1GCC\s0 should insert cache barriers to avoid the
-side-effects of speculation on R10K processors.
-.Sp
-In common with many processors, the R10K tries to predict the outcome
-of a conditional branch and speculatively executes instructions from
-the \*(L"taken\*(R" branch. It later aborts these instructions if the
-predicted outcome was wrong. However, on the R10K, even aborted
-instructions can have side effects.
-.Sp
-This problem only affects kernel stores and, depending on the system,
-kernel loads. As an example, a speculatively-executed store may load
-the target memory into cache and mark the cache line as dirty, even if
-the store itself is later aborted. If a \s-1DMA\s0 operation writes to the
-same area of memory before the \*(L"dirty\*(R" line is flushed, the cached
-data will overwrite the DMA-ed data. See the R10K processor manual
-for a full description, including other potential problems.
-.Sp
-One workaround is to insert cache barrier instructions before every memory
-access that might be speculatively executed and that might have side
-effects even if aborted. \fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR
-controls \s-1GCC\s0's implementation of this workaround. It assumes that
-aborted accesses to any byte in the following regions will not have
-side effects:
-.RS 4
-.IP "1." 4
-the memory occupied by the current function's stack frame;
-.IP "2." 4
-the memory occupied by an incoming stack argument;
-.IP "3." 4
-the memory occupied by an object with a link-time-constant address.
-.RE
-.RS 4
-.Sp
-It is the kernel's responsibility to ensure that speculative
-accesses to these regions are indeed safe.
-.Sp
-If the input program contains a function declaration such as:
-.Sp
-.Vb 1
-\& void foo (void);
-.Ve
-.Sp
-then the implementation of \f(CW\*(C`foo\*(C'\fR must allow \f(CW\*(C`j foo\*(C'\fR and
-\&\f(CW\*(C`jal foo\*(C'\fR to be executed speculatively. \s-1GCC\s0 honors this
-restriction for functions it compiles itself. It expects non-GCC
-functions (such as hand-written assembly code) to do the same.
-.Sp
-The option has three forms:
-.IP "\fB\-mr10k\-cache\-barrier=load\-store\fR" 4
-.IX Item "-mr10k-cache-barrier=load-store"
-Insert a cache barrier before a load or store that might be
-speculatively executed and that might have side effects even
-if aborted.
-.IP "\fB\-mr10k\-cache\-barrier=store\fR" 4
-.IX Item "-mr10k-cache-barrier=store"
-Insert a cache barrier before a store that might be speculatively
-executed and that might have side effects even if aborted.
-.IP "\fB\-mr10k\-cache\-barrier=none\fR" 4
-.IX Item "-mr10k-cache-barrier=none"
-Disable the insertion of cache barriers. This is the default setting.
-.RE
-.RS 4
-.RE
-.IP "\fB\-mflush\-func=\fR\fIfunc\fR" 4
-.IX Item "-mflush-func=func"
-.PD 0
-.IP "\fB\-mno\-flush\-func\fR" 4
-.IX Item "-mno-flush-func"
-.PD
-Specifies the function to call to flush the I and D caches, or to not
-call any such function. If called, the function must take the same
-arguments as the common \f(CW\*(C`_flush_func()\*(C'\fR, that is, the address of the
-memory range for which the cache is being flushed, the size of the
-memory range, and the number 3 (to flush both caches). The default
-depends on the target \s-1GCC\s0 was configured for, but commonly is either
-\&\fB_flush_func\fR or \fB_\|_cpu_flush\fR.
-.IP "\fBmbranch\-cost=\fR\fInum\fR" 4
-.IX Item "mbranch-cost=num"
-Set the cost of branches to roughly \fInum\fR \*(L"simple\*(R" instructions.
-This cost is only a heuristic and is not guaranteed to produce
-consistent results across releases. A zero cost redundantly selects
-the default, which is based on the \fB\-mtune\fR setting.
-.IP "\fB\-mbranch\-likely\fR" 4
-.IX Item "-mbranch-likely"
-.PD 0
-.IP "\fB\-mno\-branch\-likely\fR" 4
-.IX Item "-mno-branch-likely"
-.PD
-Enable or disable use of Branch Likely instructions, regardless of the
-default for the selected architecture. By default, Branch Likely
-instructions may be generated if they are supported by the selected
-architecture. An exception is for the \s-1MIPS32\s0 and \s-1MIPS64\s0 architectures
-and processors which implement those architectures; for those, Branch
-Likely instructions will not be generated by default because the \s-1MIPS32\s0
-and \s-1MIPS64\s0 architectures specifically deprecate their use.
-.IP "\fB\-mfp\-exceptions\fR" 4
-.IX Item "-mfp-exceptions"
-.PD 0
-.IP "\fB\-mno\-fp\-exceptions\fR" 4
-.IX Item "-mno-fp-exceptions"
-.PD
-Specifies whether \s-1FP\s0 exceptions are enabled. This affects how we schedule
-\&\s-1FP\s0 instructions for some processors. The default is that \s-1FP\s0 exceptions are
-enabled.
-.Sp
-For instance, on the \s-1SB\-1\s0, if \s-1FP\s0 exceptions are disabled, and we are emitting
-64\-bit code, then we can use both \s-1FP\s0 pipes. Otherwise, we can only use one
-\&\s-1FP\s0 pipe.
-.IP "\fB\-mvr4130\-align\fR" 4
-.IX Item "-mvr4130-align"
-.PD 0
-.IP "\fB\-mno\-vr4130\-align\fR" 4
-.IX Item "-mno-vr4130-align"
-.PD
-The \s-1VR4130\s0 pipeline is two-way superscalar, but can only issue two
-instructions together if the first one is 8\-byte aligned. When this
-option is enabled, \s-1GCC\s0 will align pairs of instructions that it
-thinks should execute in parallel.
-.Sp
-This option only has an effect when optimizing for the \s-1VR4130\s0.
-It normally makes code faster, but at the expense of making it bigger.
-It is enabled by default at optimization level \fB\-O3\fR.
-.IP "\fB\-msynci\fR" 4
-.IX Item "-msynci"
-.PD 0
-.IP "\fB\-mno\-synci\fR" 4
-.IX Item "-mno-synci"
-.PD
-Enable (disable) generation of \f(CW\*(C`synci\*(C'\fR instructions on
-architectures that support it. The \f(CW\*(C`synci\*(C'\fR instructions (if
-enabled) will be generated when \f(CW\*(C`_\|_builtin_\|_\|_clear_cache()\*(C'\fR is
-compiled.
-.Sp
-This option defaults to \f(CW\*(C`\-mno\-synci\*(C'\fR, but the default can be
-overridden by configuring with \f(CW\*(C`\-\-with\-synci\*(C'\fR.
-.Sp
-When compiling code for single processor systems, it is generally safe
-to use \f(CW\*(C`synci\*(C'\fR. However, on many multi-core (\s-1SMP\s0) systems, it
-will not invalidate the instruction caches on all cores and may lead
-to undefined behavior.
-.IP "\fB\-mrelax\-pic\-calls\fR" 4
-.IX Item "-mrelax-pic-calls"
-.PD 0
-.IP "\fB\-mno\-relax\-pic\-calls\fR" 4
-.IX Item "-mno-relax-pic-calls"
-.PD
-Try to turn \s-1PIC\s0 calls that are normally dispatched via register
-\&\f(CW$25\fR into direct calls. This is only possible if the linker can
-resolve the destination at link-time and if the destination is within
-range for a direct call.
-.Sp
-\&\fB\-mrelax\-pic\-calls\fR is the default if \s-1GCC\s0 was configured to use
-an assembler and a linker that supports the \f(CW\*(C`.reloc\*(C'\fR assembly
-directive and \f(CW\*(C`\-mexplicit\-relocs\*(C'\fR is in effect. With
-\&\f(CW\*(C`\-mno\-explicit\-relocs\*(C'\fR, this optimization can be performed by the
-assembler and the linker alone without help from the compiler.
-.IP "\fB\-mmcount\-ra\-address\fR" 4
-.IX Item "-mmcount-ra-address"
-.PD 0
-.IP "\fB\-mno\-mcount\-ra\-address\fR" 4
-.IX Item "-mno-mcount-ra-address"
-.PD
-Emit (do not emit) code that allows \f(CW\*(C`_mcount\*(C'\fR to modify the
-calling function's return address. When enabled, this option extends
-the usual \f(CW\*(C`_mcount\*(C'\fR interface with a new \fIra-address\fR
-parameter, which has type \f(CW\*(C`intptr_t *\*(C'\fR and is passed in register
-\&\f(CW$12\fR. \f(CW\*(C`_mcount\*(C'\fR can then modify the return address by
-doing both of the following:
-.RS 4
-.IP "\(bu" 4
-Returning the new address in register \f(CW$31\fR.
-.IP "\(bu" 4
-Storing the new address in \f(CW\*(C`*\f(CIra\-address\f(CW\*(C'\fR,
-if \fIra-address\fR is nonnull.
-.RE
-.RS 4
-.Sp
-The default is \fB\-mno\-mcount\-ra\-address\fR.
-.RE
-.PP
-\fI\s-1MMIX\s0 Options\fR
-.IX Subsection "MMIX Options"
-.PP
-These options are defined for the \s-1MMIX:\s0
-.IP "\fB\-mlibfuncs\fR" 4
-.IX Item "-mlibfuncs"
-.PD 0
-.IP "\fB\-mno\-libfuncs\fR" 4
-.IX Item "-mno-libfuncs"
-.PD
-Specify that intrinsic library functions are being compiled, passing all
-values in registers, no matter the size.
-.IP "\fB\-mepsilon\fR" 4
-.IX Item "-mepsilon"
-.PD 0
-.IP "\fB\-mno\-epsilon\fR" 4
-.IX Item "-mno-epsilon"
-.PD
-Generate floating-point comparison instructions that compare with respect
-to the \f(CW\*(C`rE\*(C'\fR epsilon register.
-.IP "\fB\-mabi=mmixware\fR" 4
-.IX Item "-mabi=mmixware"
-.PD 0
-.IP "\fB\-mabi=gnu\fR" 4
-.IX Item "-mabi=gnu"
-.PD
-Generate code that passes function parameters and return values that (in
-the called function) are seen as registers \f(CW$0\fR and up, as opposed to
-the \s-1GNU\s0 \s-1ABI\s0 which uses global registers \f(CW$231\fR and up.
-.IP "\fB\-mzero\-extend\fR" 4
-.IX Item "-mzero-extend"
-.PD 0
-.IP "\fB\-mno\-zero\-extend\fR" 4
-.IX Item "-mno-zero-extend"
-.PD
-When reading data from memory in sizes shorter than 64 bits, use (do not
-use) zero-extending load instructions by default, rather than
-sign-extending ones.
-.IP "\fB\-mknuthdiv\fR" 4
-.IX Item "-mknuthdiv"
-.PD 0
-.IP "\fB\-mno\-knuthdiv\fR" 4
-.IX Item "-mno-knuthdiv"
-.PD
-Make the result of a division yielding a remainder have the same sign as
-the divisor. With the default, \fB\-mno\-knuthdiv\fR, the sign of the
-remainder follows the sign of the dividend. Both methods are
-arithmetically valid, the latter being almost exclusively used.
-.IP "\fB\-mtoplevel\-symbols\fR" 4
-.IX Item "-mtoplevel-symbols"
-.PD 0
-.IP "\fB\-mno\-toplevel\-symbols\fR" 4
-.IX Item "-mno-toplevel-symbols"
-.PD
-Prepend (do not prepend) a \fB:\fR to all global symbols, so the assembly
-code can be used with the \f(CW\*(C`PREFIX\*(C'\fR assembly directive.
-.IP "\fB\-melf\fR" 4
-.IX Item "-melf"
-Generate an executable in the \s-1ELF\s0 format, rather than the default
-\&\fBmmo\fR format used by the \fBmmix\fR simulator.
-.IP "\fB\-mbranch\-predict\fR" 4
-.IX Item "-mbranch-predict"
-.PD 0
-.IP "\fB\-mno\-branch\-predict\fR" 4
-.IX Item "-mno-branch-predict"
-.PD
-Use (do not use) the probable-branch instructions, when static branch
-prediction indicates a probable branch.
-.IP "\fB\-mbase\-addresses\fR" 4
-.IX Item "-mbase-addresses"
-.PD 0
-.IP "\fB\-mno\-base\-addresses\fR" 4
-.IX Item "-mno-base-addresses"
-.PD
-Generate (do not generate) code that uses \fIbase addresses\fR. Using a
-base address automatically generates a request (handled by the assembler
-and the linker) for a constant to be set up in a global register. The
-register is used for one or more base address requests within the range 0
-to 255 from the value held in the register. The generally leads to short
-and fast code, but the number of different data items that can be
-addressed is limited. This means that a program that uses lots of static
-data may require \fB\-mno\-base\-addresses\fR.
-.IP "\fB\-msingle\-exit\fR" 4
-.IX Item "-msingle-exit"
-.PD 0
-.IP "\fB\-mno\-single\-exit\fR" 4
-.IX Item "-mno-single-exit"
-.PD
-Force (do not force) generated code to have a single exit point in each
-function.
-.PP
-\fI\s-1MN10300\s0 Options\fR
-.IX Subsection "MN10300 Options"
-.PP
-These \fB\-m\fR options are defined for Matsushita \s-1MN10300\s0 architectures:
-.IP "\fB\-mmult\-bug\fR" 4
-.IX Item "-mmult-bug"
-Generate code to avoid bugs in the multiply instructions for the \s-1MN10300\s0
-processors. This is the default.
-.IP "\fB\-mno\-mult\-bug\fR" 4
-.IX Item "-mno-mult-bug"
-Do not generate code to avoid bugs in the multiply instructions for the
-\&\s-1MN10300\s0 processors.
-.IP "\fB\-mam33\fR" 4
-.IX Item "-mam33"
-Generate code which uses features specific to the \s-1AM33\s0 processor.
-.IP "\fB\-mno\-am33\fR" 4
-.IX Item "-mno-am33"
-Do not generate code which uses features specific to the \s-1AM33\s0 processor. This
-is the default.
-.IP "\fB\-mam33\-2\fR" 4
-.IX Item "-mam33-2"
-Generate code which uses features specific to the \s-1AM33/2\s0.0 processor.
-.IP "\fB\-mam34\fR" 4
-.IX Item "-mam34"
-Generate code which uses features specific to the \s-1AM34\s0 processor.
-.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
-.IX Item "-mtune=cpu-type"
-Use the timing characteristics of the indicated \s-1CPU\s0 type when
-scheduling instructions. This does not change the targeted processor
-type. The \s-1CPU\s0 type must be one of \fBmn10300\fR, \fBam33\fR,
-\&\fBam33\-2\fR or \fBam34\fR.
-.IP "\fB\-mreturn\-pointer\-on\-d0\fR" 4
-.IX Item "-mreturn-pointer-on-d0"
-When generating a function which returns a pointer, return the pointer
-in both \f(CW\*(C`a0\*(C'\fR and \f(CW\*(C`d0\*(C'\fR. Otherwise, the pointer is returned
-only in a0, and attempts to call such functions without a prototype
-would result in errors. Note that this option is on by default; use
-\&\fB\-mno\-return\-pointer\-on\-d0\fR to disable it.
-.IP "\fB\-mno\-crt0\fR" 4
-.IX Item "-mno-crt0"
-Do not link in the C run-time initialization object file.
-.IP "\fB\-mrelax\fR" 4
-.IX Item "-mrelax"
-Indicate to the linker that it should perform a relaxation optimization pass
-to shorten branches, calls and absolute memory addresses. This option only
-has an effect when used on the command line for the final link step.
-.Sp
-This option makes symbolic debugging impossible.
-.IP "\fB\-mliw\fR" 4
-.IX Item "-mliw"
-Allow the compiler to generate \fILong Instruction Word\fR
-instructions if the target is the \fB\s-1AM33\s0\fR or later. This is the
-default. This option defines the preprocessor macro \fB_\|_LIW_\|_\fR.
-.IP "\fB\-mnoliw\fR" 4
-.IX Item "-mnoliw"
-Do not allow the compiler to generate \fILong Instruction Word\fR
-instructions. This option defines the preprocessor macro
-\&\fB_\|_NO_LIW_\|_\fR.
-.PP
-\fI\s-1PDP\-11\s0 Options\fR
-.IX Subsection "PDP-11 Options"
-.PP
-These options are defined for the \s-1PDP\-11:\s0
-.IP "\fB\-mfpu\fR" 4
-.IX Item "-mfpu"
-Use hardware \s-1FPP\s0 floating point. This is the default. (\s-1FIS\s0 floating
-point on the \s-1PDP\-11/40\s0 is not supported.)
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-Do not use hardware floating point.
-.IP "\fB\-mac0\fR" 4
-.IX Item "-mac0"
-Return floating-point results in ac0 (fr0 in Unix assembler syntax).
-.IP "\fB\-mno\-ac0\fR" 4
-.IX Item "-mno-ac0"
-Return floating-point results in memory. This is the default.
-.IP "\fB\-m40\fR" 4
-.IX Item "-m40"
-Generate code for a \s-1PDP\-11/40\s0.
-.IP "\fB\-m45\fR" 4
-.IX Item "-m45"
-Generate code for a \s-1PDP\-11/45\s0. This is the default.
-.IP "\fB\-m10\fR" 4
-.IX Item "-m10"
-Generate code for a \s-1PDP\-11/10\s0.
-.IP "\fB\-mbcopy\-builtin\fR" 4
-.IX Item "-mbcopy-builtin"
-Use inline \f(CW\*(C`movmemhi\*(C'\fR patterns for copying memory. This is the
-default.
-.IP "\fB\-mbcopy\fR" 4
-.IX Item "-mbcopy"
-Do not use inline \f(CW\*(C`movmemhi\*(C'\fR patterns for copying memory.
-.IP "\fB\-mint16\fR" 4
-.IX Item "-mint16"
-.PD 0
-.IP "\fB\-mno\-int32\fR" 4
-.IX Item "-mno-int32"
-.PD
-Use 16\-bit \f(CW\*(C`int\*(C'\fR. This is the default.
-.IP "\fB\-mint32\fR" 4
-.IX Item "-mint32"
-.PD 0
-.IP "\fB\-mno\-int16\fR" 4
-.IX Item "-mno-int16"
-.PD
-Use 32\-bit \f(CW\*(C`int\*(C'\fR.
-.IP "\fB\-mfloat64\fR" 4
-.IX Item "-mfloat64"
-.PD 0
-.IP "\fB\-mno\-float32\fR" 4
-.IX Item "-mno-float32"
-.PD
-Use 64\-bit \f(CW\*(C`float\*(C'\fR. This is the default.
-.IP "\fB\-mfloat32\fR" 4
-.IX Item "-mfloat32"
-.PD 0
-.IP "\fB\-mno\-float64\fR" 4
-.IX Item "-mno-float64"
-.PD
-Use 32\-bit \f(CW\*(C`float\*(C'\fR.
-.IP "\fB\-mabshi\fR" 4
-.IX Item "-mabshi"
-Use \f(CW\*(C`abshi2\*(C'\fR pattern. This is the default.
-.IP "\fB\-mno\-abshi\fR" 4
-.IX Item "-mno-abshi"
-Do not use \f(CW\*(C`abshi2\*(C'\fR pattern.
-.IP "\fB\-mbranch\-expensive\fR" 4
-.IX Item "-mbranch-expensive"
-Pretend that branches are expensive. This is for experimenting with
-code generation only.
-.IP "\fB\-mbranch\-cheap\fR" 4
-.IX Item "-mbranch-cheap"
-Do not pretend that branches are expensive. This is the default.
-.IP "\fB\-munix\-asm\fR" 4
-.IX Item "-munix-asm"
-Use Unix assembler syntax. This is the default when configured for
-\&\fBpdp11\-*\-bsd\fR.
-.IP "\fB\-mdec\-asm\fR" 4
-.IX Item "-mdec-asm"
-Use \s-1DEC\s0 assembler syntax. This is the default when configured for any
-\&\s-1PDP\-11\s0 target other than \fBpdp11\-*\-bsd\fR.
-.PP
-\fIpicoChip Options\fR
-.IX Subsection "picoChip Options"
-.PP
-These \fB\-m\fR options are defined for picoChip implementations:
-.IP "\fB\-mae=\fR\fIae_type\fR" 4
-.IX Item "-mae=ae_type"
-Set the instruction set, register set, and instruction scheduling
-parameters for array element type \fIae_type\fR. Supported values
-for \fIae_type\fR are \fB\s-1ANY\s0\fR, \fB\s-1MUL\s0\fR, and \fB\s-1MAC\s0\fR.
-.Sp
-\&\fB\-mae=ANY\fR selects a completely generic \s-1AE\s0 type. Code
-generated with this option will run on any of the other \s-1AE\s0 types. The
-code will not be as efficient as it would be if compiled for a specific
-\&\s-1AE\s0 type, and some types of operation (e.g., multiplication) will not
-work properly on all types of \s-1AE\s0.
-.Sp
-\&\fB\-mae=MUL\fR selects a \s-1MUL\s0 \s-1AE\s0 type. This is the most useful \s-1AE\s0 type
-for compiled code, and is the default.
-.Sp
-\&\fB\-mae=MAC\fR selects a DSP-style \s-1MAC\s0 \s-1AE\s0. Code compiled with this
-option may suffer from poor performance of byte (char) manipulation,
-since the \s-1DSP\s0 \s-1AE\s0 does not provide hardware support for byte load/stores.
-.IP "\fB\-msymbol\-as\-address\fR" 4
-.IX Item "-msymbol-as-address"
-Enable the compiler to directly use a symbol name as an address in a
-load/store instruction, without first loading it into a
-register. Typically, the use of this option will generate larger
-programs, which run faster than when the option isn't used. However, the
-results vary from program to program, so it is left as a user option,
-rather than being permanently enabled.
-.IP "\fB\-mno\-inefficient\-warnings\fR" 4
-.IX Item "-mno-inefficient-warnings"
-Disables warnings about the generation of inefficient code. These
-warnings can be generated, for example, when compiling code which
-performs byte-level memory operations on the \s-1MAC\s0 \s-1AE\s0 type. The \s-1MAC\s0 \s-1AE\s0 has
-no hardware support for byte-level memory operations, so all byte
-load/stores must be synthesized from word load/store operations. This is
-inefficient and a warning will be generated indicating to the programmer
-that they should rewrite the code to avoid byte operations, or to target
-an \s-1AE\s0 type which has the necessary hardware support. This option enables
-the warning to be turned off.
-.PP
-\fIPowerPC Options\fR
-.IX Subsection "PowerPC Options"
-.PP
-These are listed under
-.PP
-\fI\s-1IBM\s0 \s-1RS/6000\s0 and PowerPC Options\fR
-.IX Subsection "IBM RS/6000 and PowerPC Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1IBM\s0 \s-1RS/6000\s0 and PowerPC:
-.IP "\fB\-mpower\fR" 4
-.IX Item "-mpower"
-.PD 0
-.IP "\fB\-mno\-power\fR" 4
-.IX Item "-mno-power"
-.IP "\fB\-mpower2\fR" 4
-.IX Item "-mpower2"
-.IP "\fB\-mno\-power2\fR" 4
-.IX Item "-mno-power2"
-.IP "\fB\-mpowerpc\fR" 4
-.IX Item "-mpowerpc"
-.IP "\fB\-mno\-powerpc\fR" 4
-.IX Item "-mno-powerpc"
-.IP "\fB\-mpowerpc\-gpopt\fR" 4
-.IX Item "-mpowerpc-gpopt"
-.IP "\fB\-mno\-powerpc\-gpopt\fR" 4
-.IX Item "-mno-powerpc-gpopt"
-.IP "\fB\-mpowerpc\-gfxopt\fR" 4
-.IX Item "-mpowerpc-gfxopt"
-.IP "\fB\-mno\-powerpc\-gfxopt\fR" 4
-.IX Item "-mno-powerpc-gfxopt"
-.IP "\fB\-mpowerpc64\fR" 4
-.IX Item "-mpowerpc64"
-.IP "\fB\-mno\-powerpc64\fR" 4
-.IX Item "-mno-powerpc64"
-.IP "\fB\-mmfcrf\fR" 4
-.IX Item "-mmfcrf"
-.IP "\fB\-mno\-mfcrf\fR" 4
-.IX Item "-mno-mfcrf"
-.IP "\fB\-mpopcntb\fR" 4
-.IX Item "-mpopcntb"
-.IP "\fB\-mno\-popcntb\fR" 4
-.IX Item "-mno-popcntb"
-.IP "\fB\-mpopcntd\fR" 4
-.IX Item "-mpopcntd"
-.IP "\fB\-mno\-popcntd\fR" 4
-.IX Item "-mno-popcntd"
-.IP "\fB\-mfprnd\fR" 4
-.IX Item "-mfprnd"
-.IP "\fB\-mno\-fprnd\fR" 4
-.IX Item "-mno-fprnd"
-.IP "\fB\-mcmpb\fR" 4
-.IX Item "-mcmpb"
-.IP "\fB\-mno\-cmpb\fR" 4
-.IX Item "-mno-cmpb"
-.IP "\fB\-mmfpgpr\fR" 4
-.IX Item "-mmfpgpr"
-.IP "\fB\-mno\-mfpgpr\fR" 4
-.IX Item "-mno-mfpgpr"
-.IP "\fB\-mhard\-dfp\fR" 4
-.IX Item "-mhard-dfp"
-.IP "\fB\-mno\-hard\-dfp\fR" 4
-.IX Item "-mno-hard-dfp"
-.PD
-\&\s-1GCC\s0 supports two related instruction set architectures for the
-\&\s-1RS/6000\s0 and PowerPC. The \fI\s-1POWER\s0\fR instruction set are those
-instructions supported by the \fBrios\fR chip set used in the original
-\&\s-1RS/6000\s0 systems and the \fIPowerPC\fR instruction set is the
-architecture of the Freescale MPC5xx, MPC6xx, MPC8xx microprocessors, and
-the \s-1IBM\s0 4xx, 6xx, and follow-on microprocessors.
-.Sp
-Neither architecture is a subset of the other. However there is a
-large common subset of instructions supported by both. An \s-1MQ\s0
-register is included in processors supporting the \s-1POWER\s0 architecture.
-.Sp
-You use these options to specify which instructions are available on the
-processor you are using. The default value of these options is
-determined when configuring \s-1GCC\s0. Specifying the
-\&\fB\-mcpu=\fR\fIcpu_type\fR overrides the specification of these
-options. We recommend you use the \fB\-mcpu=\fR\fIcpu_type\fR option
-rather than the options listed above.
-.Sp
-The \fB\-mpower\fR option allows \s-1GCC\s0 to generate instructions that
-are found only in the \s-1POWER\s0 architecture and to use the \s-1MQ\s0 register.
-Specifying \fB\-mpower2\fR implies \fB\-power\fR and also allows \s-1GCC\s0
-to generate instructions that are present in the \s-1POWER2\s0 architecture but
-not the original \s-1POWER\s0 architecture.
-.Sp
-The \fB\-mpowerpc\fR option allows \s-1GCC\s0 to generate instructions that
-are found only in the 32\-bit subset of the PowerPC architecture.
-Specifying \fB\-mpowerpc\-gpopt\fR implies \fB\-mpowerpc\fR and also allows
-\&\s-1GCC\s0 to use the optional PowerPC architecture instructions in the
-General Purpose group, including floating-point square root. Specifying
-\&\fB\-mpowerpc\-gfxopt\fR implies \fB\-mpowerpc\fR and also allows \s-1GCC\s0 to
-use the optional PowerPC architecture instructions in the Graphics
-group, including floating-point select.
-.Sp
-The \fB\-mmfcrf\fR option allows \s-1GCC\s0 to generate the move from
-condition register field instruction implemented on the \s-1POWER4\s0
-processor and other processors that support the PowerPC V2.01
-architecture.
-The \fB\-mpopcntb\fR option allows \s-1GCC\s0 to generate the popcount and
-double precision \s-1FP\s0 reciprocal estimate instruction implemented on the
-\&\s-1POWER5\s0 processor and other processors that support the PowerPC V2.02
-architecture.
-The \fB\-mpopcntd\fR option allows \s-1GCC\s0 to generate the popcount
-instruction implemented on the \s-1POWER7\s0 processor and other processors
-that support the PowerPC V2.06 architecture.
-The \fB\-mfprnd\fR option allows \s-1GCC\s0 to generate the \s-1FP\s0 round to
-integer instructions implemented on the \s-1POWER5+\s0 processor and other
-processors that support the PowerPC V2.03 architecture.
-The \fB\-mcmpb\fR option allows \s-1GCC\s0 to generate the compare bytes
-instruction implemented on the \s-1POWER6\s0 processor and other processors
-that support the PowerPC V2.05 architecture.
-The \fB\-mmfpgpr\fR option allows \s-1GCC\s0 to generate the \s-1FP\s0 move to/from
-general purpose register instructions implemented on the \s-1POWER6X\s0
-processor and other processors that support the extended PowerPC V2.05
-architecture.
-The \fB\-mhard\-dfp\fR option allows \s-1GCC\s0 to generate the decimal floating
-point instructions implemented on some \s-1POWER\s0 processors.
-.Sp
-The \fB\-mpowerpc64\fR option allows \s-1GCC\s0 to generate the additional
-64\-bit instructions that are found in the full PowerPC64 architecture
-and to treat GPRs as 64\-bit, doubleword quantities. \s-1GCC\s0 defaults to
-\&\fB\-mno\-powerpc64\fR.
-.Sp
-If you specify both \fB\-mno\-power\fR and \fB\-mno\-powerpc\fR, \s-1GCC\s0
-will use only the instructions in the common subset of both
-architectures plus some special \s-1AIX\s0 common-mode calls, and will not use
-the \s-1MQ\s0 register. Specifying both \fB\-mpower\fR and \fB\-mpowerpc\fR
-permits \s-1GCC\s0 to use any instruction from either architecture and to
-allow use of the \s-1MQ\s0 register; specify this for the Motorola \s-1MPC601\s0.
-.IP "\fB\-mnew\-mnemonics\fR" 4
-.IX Item "-mnew-mnemonics"
-.PD 0
-.IP "\fB\-mold\-mnemonics\fR" 4
-.IX Item "-mold-mnemonics"
-.PD
-Select which mnemonics to use in the generated assembler code. With
-\&\fB\-mnew\-mnemonics\fR, \s-1GCC\s0 uses the assembler mnemonics defined for
-the PowerPC architecture. With \fB\-mold\-mnemonics\fR it uses the
-assembler mnemonics defined for the \s-1POWER\s0 architecture. Instructions
-defined in only one architecture have only one mnemonic; \s-1GCC\s0 uses that
-mnemonic irrespective of which of these options is specified.
-.Sp
-\&\s-1GCC\s0 defaults to the mnemonics appropriate for the architecture in
-use. Specifying \fB\-mcpu=\fR\fIcpu_type\fR sometimes overrides the
-value of these option. Unless you are building a cross-compiler, you
-should normally not specify either \fB\-mnew\-mnemonics\fR or
-\&\fB\-mold\-mnemonics\fR, but should instead accept the default.
-.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
-.IX Item "-mcpu=cpu_type"
-Set architecture type, register usage, choice of mnemonics, and
-instruction scheduling parameters for machine type \fIcpu_type\fR.
-Supported values for \fIcpu_type\fR are \fB401\fR, \fB403\fR,
-\&\fB405\fR, \fB405fp\fR, \fB440\fR, \fB440fp\fR, \fB464\fR, \fB464fp\fR,
-\&\fB476\fR, \fB476fp\fR, \fB505\fR, \fB601\fR, \fB602\fR, \fB603\fR,
-\&\fB603e\fR, \fB604\fR, \fB604e\fR, \fB620\fR, \fB630\fR, \fB740\fR,
-\&\fB7400\fR, \fB7450\fR, \fB750\fR, \fB801\fR, \fB821\fR, \fB823\fR,
-\&\fB860\fR, \fB970\fR, \fB8540\fR, \fBa2\fR, \fBe300c2\fR,
-\&\fBe300c3\fR, \fBe500mc\fR, \fBe500mc64\fR, \fBec603e\fR, \fBG3\fR,
-\&\fBG4\fR, \fBG5\fR, \fBtitan\fR, \fBpower\fR, \fBpower2\fR, \fBpower3\fR,
-\&\fBpower4\fR, \fBpower5\fR, \fBpower5+\fR, \fBpower6\fR, \fBpower6x\fR,
-\&\fBpower7\fR, \fBcommon\fR, \fBpowerpc\fR, \fBpowerpc64\fR, \fBrios\fR,
-\&\fBrios1\fR, \fBrios2\fR, \fBrsc\fR, and \fBrs64\fR.
-.Sp
-\&\fB\-mcpu=common\fR selects a completely generic processor. Code
-generated under this option will run on any \s-1POWER\s0 or PowerPC processor.
-\&\s-1GCC\s0 will use only the instructions in the common subset of both
-architectures, and will not use the \s-1MQ\s0 register. \s-1GCC\s0 assumes a generic
-processor model for scheduling purposes.
-.Sp
-\&\fB\-mcpu=power\fR, \fB\-mcpu=power2\fR, \fB\-mcpu=powerpc\fR, and
-\&\fB\-mcpu=powerpc64\fR specify generic \s-1POWER\s0, \s-1POWER2\s0, pure 32\-bit
-PowerPC (i.e., not \s-1MPC601\s0), and 64\-bit PowerPC architecture machine
-types, with an appropriate, generic processor model assumed for
-scheduling purposes.
-.Sp
-The other options specify a specific processor. Code generated under
-those options will run best on that processor, and may not run at all on
-others.
-.Sp
-The \fB\-mcpu\fR options automatically enable or disable the
-following options:
-.Sp
-\&\fB\-maltivec \-mfprnd \-mhard\-float \-mmfcrf \-mmultiple
-\&\-mnew\-mnemonics \-mpopcntb \-mpopcntd \-mpower \-mpower2 \-mpowerpc64
-\&\-mpowerpc\-gpopt \-mpowerpc\-gfxopt \-msingle\-float \-mdouble\-float
-\&\-msimple\-fpu \-mstring \-mmulhw \-mdlmzb \-mmfpgpr \-mvsx\fR
-.Sp
-The particular options set for any particular \s-1CPU\s0 will vary between
-compiler versions, depending on what setting seems to produce optimal
-code for that \s-1CPU\s0; it doesn't necessarily reflect the actual hardware's
-capabilities. If you wish to set an individual option to a particular
-value, you may specify it after the \fB\-mcpu\fR option, like
-\&\fB\-mcpu=970 \-mno\-altivec\fR.
-.Sp
-On \s-1AIX\s0, the \fB\-maltivec\fR and \fB\-mpowerpc64\fR options are
-not enabled or disabled by the \fB\-mcpu\fR option at present because
-\&\s-1AIX\s0 does not have full support for these options. You may still
-enable or disable them individually if you're sure it'll work in your
-environment.
-.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
-.IX Item "-mtune=cpu_type"
-Set the instruction scheduling parameters for machine type
-\&\fIcpu_type\fR, but do not set the architecture type, register usage, or
-choice of mnemonics, as \fB\-mcpu=\fR\fIcpu_type\fR would. The same
-values for \fIcpu_type\fR are used for \fB\-mtune\fR as for
-\&\fB\-mcpu\fR. If both are specified, the code generated will use the
-architecture, registers, and mnemonics set by \fB\-mcpu\fR, but the
-scheduling parameters set by \fB\-mtune\fR.
-.IP "\fB\-mcmodel=small\fR" 4
-.IX Item "-mcmodel=small"
-Generate PowerPC64 code for the small model: The \s-1TOC\s0 is limited to
-64k.
-.IP "\fB\-mcmodel=medium\fR" 4
-.IX Item "-mcmodel=medium"
-Generate PowerPC64 code for the medium model: The \s-1TOC\s0 and other static
-data may be up to a total of 4G in size.
-.IP "\fB\-mcmodel=large\fR" 4
-.IX Item "-mcmodel=large"
-Generate PowerPC64 code for the large model: The \s-1TOC\s0 may be up to 4G
-in size. Other data and code is only limited by the 64\-bit address
-space.
-.IP "\fB\-maltivec\fR" 4
-.IX Item "-maltivec"
-.PD 0
-.IP "\fB\-mno\-altivec\fR" 4
-.IX Item "-mno-altivec"
-.PD
-Generate code that uses (does not use) AltiVec instructions, and also
-enable the use of built-in functions that allow more direct access to
-the AltiVec instruction set. You may also need to set
-\&\fB\-mabi=altivec\fR to adjust the current \s-1ABI\s0 with AltiVec \s-1ABI\s0
-enhancements.
-.IP "\fB\-mvrsave\fR" 4
-.IX Item "-mvrsave"
-.PD 0
-.IP "\fB\-mno\-vrsave\fR" 4
-.IX Item "-mno-vrsave"
-.PD
-Generate \s-1VRSAVE\s0 instructions when generating AltiVec code.
-.IP "\fB\-mgen\-cell\-microcode\fR" 4
-.IX Item "-mgen-cell-microcode"
-Generate Cell microcode instructions
-.IP "\fB\-mwarn\-cell\-microcode\fR" 4
-.IX Item "-mwarn-cell-microcode"
-Warning when a Cell microcode instruction is going to emitted. An example
-of a Cell microcode instruction is a variable shift.
-.IP "\fB\-msecure\-plt\fR" 4
-.IX Item "-msecure-plt"
-Generate code that allows ld and ld.so to build executables and shared
-libraries with non-exec .plt and .got sections. This is a PowerPC
-32\-bit \s-1SYSV\s0 \s-1ABI\s0 option.
-.IP "\fB\-mbss\-plt\fR" 4
-.IX Item "-mbss-plt"
-Generate code that uses a \s-1BSS\s0 .plt section that ld.so fills in, and
-requires .plt and .got sections that are both writable and executable.
-This is a PowerPC 32\-bit \s-1SYSV\s0 \s-1ABI\s0 option.
-.IP "\fB\-misel\fR" 4
-.IX Item "-misel"
-.PD 0
-.IP "\fB\-mno\-isel\fR" 4
-.IX Item "-mno-isel"
-.PD
-This switch enables or disables the generation of \s-1ISEL\s0 instructions.
-.IP "\fB\-misel=\fR\fIyes/no\fR" 4
-.IX Item "-misel=yes/no"
-This switch has been deprecated. Use \fB\-misel\fR and
-\&\fB\-mno\-isel\fR instead.
-.IP "\fB\-mspe\fR" 4
-.IX Item "-mspe"
-.PD 0
-.IP "\fB\-mno\-spe\fR" 4
-.IX Item "-mno-spe"
-.PD
-This switch enables or disables the generation of \s-1SPE\s0 simd
-instructions.
-.IP "\fB\-mpaired\fR" 4
-.IX Item "-mpaired"
-.PD 0
-.IP "\fB\-mno\-paired\fR" 4
-.IX Item "-mno-paired"
-.PD
-This switch enables or disables the generation of \s-1PAIRED\s0 simd
-instructions.
-.IP "\fB\-mspe=\fR\fIyes/no\fR" 4
-.IX Item "-mspe=yes/no"
-This option has been deprecated. Use \fB\-mspe\fR and
-\&\fB\-mno\-spe\fR instead.
-.IP "\fB\-mvsx\fR" 4
-.IX Item "-mvsx"
-.PD 0
-.IP "\fB\-mno\-vsx\fR" 4
-.IX Item "-mno-vsx"
-.PD
-Generate code that uses (does not use) vector/scalar (\s-1VSX\s0)
-instructions, and also enable the use of built-in functions that allow
-more direct access to the \s-1VSX\s0 instruction set.
-.IP "\fB\-mfloat\-gprs=\fR\fIyes/single/double/no\fR" 4
-.IX Item "-mfloat-gprs=yes/single/double/no"
-.PD 0
-.IP "\fB\-mfloat\-gprs\fR" 4
-.IX Item "-mfloat-gprs"
-.PD
-This switch enables or disables the generation of floating point
-operations on the general purpose registers for architectures that
-support it.
-.Sp
-The argument \fIyes\fR or \fIsingle\fR enables the use of
-single-precision floating point operations.
-.Sp
-The argument \fIdouble\fR enables the use of single and
-double-precision floating point operations.
-.Sp
-The argument \fIno\fR disables floating point operations on the
-general purpose registers.
-.Sp
-This option is currently only available on the MPC854x.
-.IP "\fB\-m32\fR" 4
-.IX Item "-m32"
-.PD 0
-.IP "\fB\-m64\fR" 4
-.IX Item "-m64"
-.PD
-Generate code for 32\-bit or 64\-bit environments of Darwin and \s-1SVR4\s0
-targets (including GNU/Linux). The 32\-bit environment sets int, long
-and pointer to 32 bits and generates code that runs on any PowerPC
-variant. The 64\-bit environment sets int to 32 bits and long and
-pointer to 64 bits, and generates code for PowerPC64, as for
-\&\fB\-mpowerpc64\fR.
-.IP "\fB\-mfull\-toc\fR" 4
-.IX Item "-mfull-toc"
-.PD 0
-.IP "\fB\-mno\-fp\-in\-toc\fR" 4
-.IX Item "-mno-fp-in-toc"
-.IP "\fB\-mno\-sum\-in\-toc\fR" 4
-.IX Item "-mno-sum-in-toc"
-.IP "\fB\-mminimal\-toc\fR" 4
-.IX Item "-mminimal-toc"
-.PD
-Modify generation of the \s-1TOC\s0 (Table Of Contents), which is created for
-every executable file. The \fB\-mfull\-toc\fR option is selected by
-default. In that case, \s-1GCC\s0 will allocate at least one \s-1TOC\s0 entry for
-each unique non-automatic variable reference in your program. \s-1GCC\s0
-will also place floating-point constants in the \s-1TOC\s0. However, only
-16,384 entries are available in the \s-1TOC\s0.
-.Sp
-If you receive a linker error message that saying you have overflowed
-the available \s-1TOC\s0 space, you can reduce the amount of \s-1TOC\s0 space used
-with the \fB\-mno\-fp\-in\-toc\fR and \fB\-mno\-sum\-in\-toc\fR options.
-\&\fB\-mno\-fp\-in\-toc\fR prevents \s-1GCC\s0 from putting floating-point
-constants in the \s-1TOC\s0 and \fB\-mno\-sum\-in\-toc\fR forces \s-1GCC\s0 to
-generate code to calculate the sum of an address and a constant at
-run-time instead of putting that sum into the \s-1TOC\s0. You may specify one
-or both of these options. Each causes \s-1GCC\s0 to produce very slightly
-slower and larger code at the expense of conserving \s-1TOC\s0 space.
-.Sp
-If you still run out of space in the \s-1TOC\s0 even when you specify both of
-these options, specify \fB\-mminimal\-toc\fR instead. This option causes
-\&\s-1GCC\s0 to make only one \s-1TOC\s0 entry for every file. When you specify this
-option, \s-1GCC\s0 will produce code that is slower and larger but which
-uses extremely little \s-1TOC\s0 space. You may wish to use this option
-only on files that contain less frequently executed code.
-.IP "\fB\-maix64\fR" 4
-.IX Item "-maix64"
-.PD 0
-.IP "\fB\-maix32\fR" 4
-.IX Item "-maix32"
-.PD
-Enable 64\-bit \s-1AIX\s0 \s-1ABI\s0 and calling convention: 64\-bit pointers, 64\-bit
-\&\f(CW\*(C`long\*(C'\fR type, and the infrastructure needed to support them.
-Specifying \fB\-maix64\fR implies \fB\-mpowerpc64\fR and
-\&\fB\-mpowerpc\fR, while \fB\-maix32\fR disables the 64\-bit \s-1ABI\s0 and
-implies \fB\-mno\-powerpc64\fR. \s-1GCC\s0 defaults to \fB\-maix32\fR.
-.IP "\fB\-mxl\-compat\fR" 4
-.IX Item "-mxl-compat"
-.PD 0
-.IP "\fB\-mno\-xl\-compat\fR" 4
-.IX Item "-mno-xl-compat"
-.PD
-Produce code that conforms more closely to \s-1IBM\s0 \s-1XL\s0 compiler semantics
-when using AIX-compatible \s-1ABI\s0. Pass floating-point arguments to
-prototyped functions beyond the register save area (\s-1RSA\s0) on the stack
-in addition to argument FPRs. Do not assume that most significant
-double in 128\-bit long double value is properly rounded when comparing
-values and converting to double. Use \s-1XL\s0 symbol names for long double
-support routines.
-.Sp
-The \s-1AIX\s0 calling convention was extended but not initially documented to
-handle an obscure K&R C case of calling a function that takes the
-address of its arguments with fewer arguments than declared. \s-1IBM\s0 \s-1XL\s0
-compilers access floating point arguments which do not fit in the
-\&\s-1RSA\s0 from the stack when a subroutine is compiled without
-optimization. Because always storing floating-point arguments on the
-stack is inefficient and rarely needed, this option is not enabled by
-default and only is necessary when calling subroutines compiled by \s-1IBM\s0
-\&\s-1XL\s0 compilers without optimization.
-.IP "\fB\-mpe\fR" 4
-.IX Item "-mpe"
-Support \fI\s-1IBM\s0 \s-1RS/6000\s0 \s-1SP\s0\fR \fIParallel Environment\fR (\s-1PE\s0). Link an
-application written to use message passing with special startup code to
-enable the application to run. The system must have \s-1PE\s0 installed in the
-standard location (\fI/usr/lpp/ppe.poe/\fR), or the \fIspecs\fR file
-must be overridden with the \fB\-specs=\fR option to specify the
-appropriate directory location. The Parallel Environment does not
-support threads, so the \fB\-mpe\fR option and the \fB\-pthread\fR
-option are incompatible.
-.IP "\fB\-malign\-natural\fR" 4
-.IX Item "-malign-natural"
-.PD 0
-.IP "\fB\-malign\-power\fR" 4
-.IX Item "-malign-power"
-.PD
-On \s-1AIX\s0, 32\-bit Darwin, and 64\-bit PowerPC GNU/Linux, the option
-\&\fB\-malign\-natural\fR overrides the ABI-defined alignment of larger
-types, such as floating-point doubles, on their natural size-based boundary.
-The option \fB\-malign\-power\fR instructs \s-1GCC\s0 to follow the ABI-specified
-alignment rules. \s-1GCC\s0 defaults to the standard alignment defined in the \s-1ABI\s0.
-.Sp
-On 64\-bit Darwin, natural alignment is the default, and \fB\-malign\-power\fR
-is not supported.
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-.PD 0
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-.PD
-Generate code that does not use (uses) the floating-point register set.
-Software floating point emulation is provided if you use the
-\&\fB\-msoft\-float\fR option, and pass the option to \s-1GCC\s0 when linking.
-.IP "\fB\-msingle\-float\fR" 4
-.IX Item "-msingle-float"
-.PD 0
-.IP "\fB\-mdouble\-float\fR" 4
-.IX Item "-mdouble-float"
-.PD
-Generate code for single or double-precision floating point operations.
-\&\fB\-mdouble\-float\fR implies \fB\-msingle\-float\fR.
-.IP "\fB\-msimple\-fpu\fR" 4
-.IX Item "-msimple-fpu"
-Do not generate sqrt and div instructions for hardware floating point unit.
-.IP "\fB\-mfpu\fR" 4
-.IX Item "-mfpu"
-Specify type of floating point unit. Valid values are \fIsp_lite\fR
-(equivalent to \-msingle\-float \-msimple\-fpu), \fIdp_lite\fR (equivalent
-to \-mdouble\-float \-msimple\-fpu), \fIsp_full\fR (equivalent to \-msingle\-float),
-and \fIdp_full\fR (equivalent to \-mdouble\-float).
-.IP "\fB\-mxilinx\-fpu\fR" 4
-.IX Item "-mxilinx-fpu"
-Perform optimizations for floating point unit on Xilinx \s-1PPC\s0 405/440.
-.IP "\fB\-mmultiple\fR" 4
-.IX Item "-mmultiple"
-.PD 0
-.IP "\fB\-mno\-multiple\fR" 4
-.IX Item "-mno-multiple"
-.PD
-Generate code that uses (does not use) the load multiple word
-instructions and the store multiple word instructions. These
-instructions are generated by default on \s-1POWER\s0 systems, and not
-generated on PowerPC systems. Do not use \fB\-mmultiple\fR on little
-endian PowerPC systems, since those instructions do not work when the
-processor is in little endian mode. The exceptions are \s-1PPC740\s0 and
-\&\s-1PPC750\s0 which permit the instructions usage in little endian mode.
-.IP "\fB\-mstring\fR" 4
-.IX Item "-mstring"
-.PD 0
-.IP "\fB\-mno\-string\fR" 4
-.IX Item "-mno-string"
-.PD
-Generate code that uses (does not use) the load string instructions
-and the store string word instructions to save multiple registers and
-do small block moves. These instructions are generated by default on
-\&\s-1POWER\s0 systems, and not generated on PowerPC systems. Do not use
-\&\fB\-mstring\fR on little endian PowerPC systems, since those
-instructions do not work when the processor is in little endian mode.
-The exceptions are \s-1PPC740\s0 and \s-1PPC750\s0 which permit the instructions
-usage in little endian mode.
-.IP "\fB\-mupdate\fR" 4
-.IX Item "-mupdate"
-.PD 0
-.IP "\fB\-mno\-update\fR" 4
-.IX Item "-mno-update"
-.PD
-Generate code that uses (does not use) the load or store instructions
-that update the base register to the address of the calculated memory
-location. These instructions are generated by default. If you use
-\&\fB\-mno\-update\fR, there is a small window between the time that the
-stack pointer is updated and the address of the previous frame is
-stored, which means code that walks the stack frame across interrupts or
-signals may get corrupted data.
-.IP "\fB\-mavoid\-indexed\-addresses\fR" 4
-.IX Item "-mavoid-indexed-addresses"
-.PD 0
-.IP "\fB\-mno\-avoid\-indexed\-addresses\fR" 4
-.IX Item "-mno-avoid-indexed-addresses"
-.PD
-Generate code that tries to avoid (not avoid) the use of indexed load
-or store instructions. These instructions can incur a performance
-penalty on Power6 processors in certain situations, such as when
-stepping through large arrays that cross a 16M boundary. This option
-is enabled by default when targetting Power6 and disabled otherwise.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Generate code that uses (does not use) the floating point multiply and
-accumulate instructions. These instructions are generated by default
-if hardware floating point is used. The machine dependent
-\&\fB\-mfused\-madd\fR option is now mapped to the machine independent
-\&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
-mapped to \fB\-ffp\-contract=off\fR.
-.IP "\fB\-mmulhw\fR" 4
-.IX Item "-mmulhw"
-.PD 0
-.IP "\fB\-mno\-mulhw\fR" 4
-.IX Item "-mno-mulhw"
-.PD
-Generate code that uses (does not use) the half-word multiply and
-multiply-accumulate instructions on the \s-1IBM\s0 405, 440, 464 and 476 processors.
-These instructions are generated by default when targetting those
-processors.
-.IP "\fB\-mdlmzb\fR" 4
-.IX Item "-mdlmzb"
-.PD 0
-.IP "\fB\-mno\-dlmzb\fR" 4
-.IX Item "-mno-dlmzb"
-.PD
-Generate code that uses (does not use) the string-search \fBdlmzb\fR
-instruction on the \s-1IBM\s0 405, 440, 464 and 476 processors. This instruction is
-generated by default when targetting those processors.
-.IP "\fB\-mno\-bit\-align\fR" 4
-.IX Item "-mno-bit-align"
-.PD 0
-.IP "\fB\-mbit\-align\fR" 4
-.IX Item "-mbit-align"
-.PD
-On System V.4 and embedded PowerPC systems do not (do) force structures
-and unions that contain bit-fields to be aligned to the base type of the
-bit-field.
-.Sp
-For example, by default a structure containing nothing but 8
-\&\f(CW\*(C`unsigned\*(C'\fR bit-fields of length 1 would be aligned to a 4 byte
-boundary and have a size of 4 bytes. By using \fB\-mno\-bit\-align\fR,
-the structure would be aligned to a 1 byte boundary and be one byte in
-size.
-.IP "\fB\-mno\-strict\-align\fR" 4
-.IX Item "-mno-strict-align"
-.PD 0
-.IP "\fB\-mstrict\-align\fR" 4
-.IX Item "-mstrict-align"
-.PD
-On System V.4 and embedded PowerPC systems do not (do) assume that
-unaligned memory references will be handled by the system.
-.IP "\fB\-mrelocatable\fR" 4
-.IX Item "-mrelocatable"
-.PD 0
-.IP "\fB\-mno\-relocatable\fR" 4
-.IX Item "-mno-relocatable"
-.PD
-Generate code that allows (does not allow) a static executable to be
-relocated to a different address at runtime. A simple embedded
-PowerPC system loader should relocate the entire contents of
-\&\f(CW\*(C`.got2\*(C'\fR and 4\-byte locations listed in the \f(CW\*(C`.fixup\*(C'\fR section,
-a table of 32\-bit addresses generated by this option. For this to
-work, all objects linked together must be compiled with
-\&\fB\-mrelocatable\fR or \fB\-mrelocatable\-lib\fR.
-\&\fB\-mrelocatable\fR code aligns the stack to an 8 byte boundary.
-.IP "\fB\-mrelocatable\-lib\fR" 4
-.IX Item "-mrelocatable-lib"
-.PD 0
-.IP "\fB\-mno\-relocatable\-lib\fR" 4
-.IX Item "-mno-relocatable-lib"
-.PD
-Like \fB\-mrelocatable\fR, \fB\-mrelocatable\-lib\fR generates a
-\&\f(CW\*(C`.fixup\*(C'\fR section to allow static executables to be relocated at
-runtime, but \fB\-mrelocatable\-lib\fR does not use the smaller stack
-alignment of \fB\-mrelocatable\fR. Objects compiled with
-\&\fB\-mrelocatable\-lib\fR may be linked with objects compiled with
-any combination of the \fB\-mrelocatable\fR options.
-.IP "\fB\-mno\-toc\fR" 4
-.IX Item "-mno-toc"
-.PD 0
-.IP "\fB\-mtoc\fR" 4
-.IX Item "-mtoc"
-.PD
-On System V.4 and embedded PowerPC systems do not (do) assume that
-register 2 contains a pointer to a global area pointing to the addresses
-used in the program.
-.IP "\fB\-mlittle\fR" 4
-.IX Item "-mlittle"
-.PD 0
-.IP "\fB\-mlittle\-endian\fR" 4
-.IX Item "-mlittle-endian"
-.PD
-On System V.4 and embedded PowerPC systems compile code for the
-processor in little endian mode. The \fB\-mlittle\-endian\fR option is
-the same as \fB\-mlittle\fR.
-.IP "\fB\-mbig\fR" 4
-.IX Item "-mbig"
-.PD 0
-.IP "\fB\-mbig\-endian\fR" 4
-.IX Item "-mbig-endian"
-.PD
-On System V.4 and embedded PowerPC systems compile code for the
-processor in big endian mode. The \fB\-mbig\-endian\fR option is
-the same as \fB\-mbig\fR.
-.IP "\fB\-mdynamic\-no\-pic\fR" 4
-.IX Item "-mdynamic-no-pic"
-On Darwin and Mac \s-1OS\s0 X systems, compile code so that it is not
-relocatable, but that its external references are relocatable. The
-resulting code is suitable for applications, but not shared
-libraries.
-.IP "\fB\-msingle\-pic\-base\fR" 4
-.IX Item "-msingle-pic-base"
-Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
-loading it in the prologue for each function. The run-time system is
-responsible for initializing this register with an appropriate value
-before execution begins.
-.IP "\fB\-mprioritize\-restricted\-insns=\fR\fIpriority\fR" 4
-.IX Item "-mprioritize-restricted-insns=priority"
-This option controls the priority that is assigned to
-dispatch-slot restricted instructions during the second scheduling
-pass. The argument \fIpriority\fR takes the value \fI0/1/2\fR to assign
-\&\fIno/highest/second\-highest\fR priority to dispatch slot restricted
-instructions.
-.IP "\fB\-msched\-costly\-dep=\fR\fIdependence_type\fR" 4
-.IX Item "-msched-costly-dep=dependence_type"
-This option controls which dependences are considered costly
-by the target during instruction scheduling. The argument
-\&\fIdependence_type\fR takes one of the following values:
-\&\fIno\fR: no dependence is costly,
-\&\fIall\fR: all dependences are costly,
-\&\fItrue_store_to_load\fR: a true dependence from store to load is costly,
-\&\fIstore_to_load\fR: any dependence from store to load is costly,
-\&\fInumber\fR: any dependence which latency >= \fInumber\fR is costly.
-.IP "\fB\-minsert\-sched\-nops=\fR\fIscheme\fR" 4
-.IX Item "-minsert-sched-nops=scheme"
-This option controls which nop insertion scheme will be used during
-the second scheduling pass. The argument \fIscheme\fR takes one of the
-following values:
-\&\fIno\fR: Don't insert nops.
-\&\fIpad\fR: Pad with nops any dispatch group which has vacant issue slots,
-according to the scheduler's grouping.
-\&\fIregroup_exact\fR: Insert nops to force costly dependent insns into
-separate groups. Insert exactly as many nops as needed to force an insn
-to a new group, according to the estimated processor grouping.
-\&\fInumber\fR: Insert nops to force costly dependent insns into
-separate groups. Insert \fInumber\fR nops to force an insn to a new group.
-.IP "\fB\-mcall\-sysv\fR" 4
-.IX Item "-mcall-sysv"
-On System V.4 and embedded PowerPC systems compile code using calling
-conventions that adheres to the March 1995 draft of the System V
-Application Binary Interface, PowerPC processor supplement. This is the
-default unless you configured \s-1GCC\s0 using \fBpowerpc\-*\-eabiaix\fR.
-.IP "\fB\-mcall\-sysv\-eabi\fR" 4
-.IX Item "-mcall-sysv-eabi"
-.PD 0
-.IP "\fB\-mcall\-eabi\fR" 4
-.IX Item "-mcall-eabi"
-.PD
-Specify both \fB\-mcall\-sysv\fR and \fB\-meabi\fR options.
-.IP "\fB\-mcall\-sysv\-noeabi\fR" 4
-.IX Item "-mcall-sysv-noeabi"
-Specify both \fB\-mcall\-sysv\fR and \fB\-mno\-eabi\fR options.
-.IP "\fB\-mcall\-aixdesc\fR" 4
-.IX Item "-mcall-aixdesc"
-On System V.4 and embedded PowerPC systems compile code for the \s-1AIX\s0
-operating system.
-.IP "\fB\-mcall\-linux\fR" 4
-.IX Item "-mcall-linux"
-On System V.4 and embedded PowerPC systems compile code for the
-Linux-based \s-1GNU\s0 system.
-.IP "\fB\-mcall\-gnu\fR" 4
-.IX Item "-mcall-gnu"
-On System V.4 and embedded PowerPC systems compile code for the
-Hurd-based \s-1GNU\s0 system.
-.IP "\fB\-mcall\-freebsd\fR" 4
-.IX Item "-mcall-freebsd"
-On System V.4 and embedded PowerPC systems compile code for the
-FreeBSD operating system.
-.IP "\fB\-mcall\-netbsd\fR" 4
-.IX Item "-mcall-netbsd"
-On System V.4 and embedded PowerPC systems compile code for the
-NetBSD operating system.
-.IP "\fB\-mcall\-openbsd\fR" 4
-.IX Item "-mcall-openbsd"
-On System V.4 and embedded PowerPC systems compile code for the
-OpenBSD operating system.
-.IP "\fB\-maix\-struct\-return\fR" 4
-.IX Item "-maix-struct-return"
-Return all structures in memory (as specified by the \s-1AIX\s0 \s-1ABI\s0).
-.IP "\fB\-msvr4\-struct\-return\fR" 4
-.IX Item "-msvr4-struct-return"
-Return structures smaller than 8 bytes in registers (as specified by the
-\&\s-1SVR4\s0 \s-1ABI\s0).
-.IP "\fB\-mabi=\fR\fIabi-type\fR" 4
-.IX Item "-mabi=abi-type"
-Extend the current \s-1ABI\s0 with a particular extension, or remove such extension.
-Valid values are \fIaltivec\fR, \fIno-altivec\fR, \fIspe\fR,
-\&\fIno-spe\fR, \fIibmlongdouble\fR, \fIieeelongdouble\fR.
-.IP "\fB\-mabi=spe\fR" 4
-.IX Item "-mabi=spe"
-Extend the current \s-1ABI\s0 with \s-1SPE\s0 \s-1ABI\s0 extensions. This does not change
-the default \s-1ABI\s0, instead it adds the \s-1SPE\s0 \s-1ABI\s0 extensions to the current
-\&\s-1ABI\s0.
-.IP "\fB\-mabi=no\-spe\fR" 4
-.IX Item "-mabi=no-spe"
-Disable Booke \s-1SPE\s0 \s-1ABI\s0 extensions for the current \s-1ABI\s0.
-.IP "\fB\-mabi=ibmlongdouble\fR" 4
-.IX Item "-mabi=ibmlongdouble"
-Change the current \s-1ABI\s0 to use \s-1IBM\s0 extended precision long double.
-This is a PowerPC 32\-bit \s-1SYSV\s0 \s-1ABI\s0 option.
-.IP "\fB\-mabi=ieeelongdouble\fR" 4
-.IX Item "-mabi=ieeelongdouble"
-Change the current \s-1ABI\s0 to use \s-1IEEE\s0 extended precision long double.
-This is a PowerPC 32\-bit Linux \s-1ABI\s0 option.
-.IP "\fB\-mprototype\fR" 4
-.IX Item "-mprototype"
-.PD 0
-.IP "\fB\-mno\-prototype\fR" 4
-.IX Item "-mno-prototype"
-.PD
-On System V.4 and embedded PowerPC systems assume that all calls to
-variable argument functions are properly prototyped. Otherwise, the
-compiler must insert an instruction before every non prototyped call to
-set or clear bit 6 of the condition code register (\fI\s-1CR\s0\fR) to
-indicate whether floating point values were passed in the floating point
-registers in case the function takes a variable arguments. With
-\&\fB\-mprototype\fR, only calls to prototyped variable argument functions
-will set or clear the bit.
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-On embedded PowerPC systems, assume that the startup module is called
-\&\fIsim\-crt0.o\fR and that the standard C libraries are \fIlibsim.a\fR and
-\&\fIlibc.a\fR. This is the default for \fBpowerpc\-*\-eabisim\fR
-configurations.
-.IP "\fB\-mmvme\fR" 4
-.IX Item "-mmvme"
-On embedded PowerPC systems, assume that the startup module is called
-\&\fIcrt0.o\fR and the standard C libraries are \fIlibmvme.a\fR and
-\&\fIlibc.a\fR.
-.IP "\fB\-mads\fR" 4
-.IX Item "-mads"
-On embedded PowerPC systems, assume that the startup module is called
-\&\fIcrt0.o\fR and the standard C libraries are \fIlibads.a\fR and
-\&\fIlibc.a\fR.
-.IP "\fB\-myellowknife\fR" 4
-.IX Item "-myellowknife"
-On embedded PowerPC systems, assume that the startup module is called
-\&\fIcrt0.o\fR and the standard C libraries are \fIlibyk.a\fR and
-\&\fIlibc.a\fR.
-.IP "\fB\-mvxworks\fR" 4
-.IX Item "-mvxworks"
-On System V.4 and embedded PowerPC systems, specify that you are
-compiling for a VxWorks system.
-.IP "\fB\-memb\fR" 4
-.IX Item "-memb"
-On embedded PowerPC systems, set the \fI\s-1PPC_EMB\s0\fR bit in the \s-1ELF\s0 flags
-header to indicate that \fBeabi\fR extended relocations are used.
-.IP "\fB\-meabi\fR" 4
-.IX Item "-meabi"
-.PD 0
-.IP "\fB\-mno\-eabi\fR" 4
-.IX Item "-mno-eabi"
-.PD
-On System V.4 and embedded PowerPC systems do (do not) adhere to the
-Embedded Applications Binary Interface (eabi) which is a set of
-modifications to the System V.4 specifications. Selecting \fB\-meabi\fR
-means that the stack is aligned to an 8 byte boundary, a function
-\&\f(CW\*(C`_\|_eabi\*(C'\fR is called to from \f(CW\*(C`main\*(C'\fR to set up the eabi
-environment, and the \fB\-msdata\fR option can use both \f(CW\*(C`r2\*(C'\fR and
-\&\f(CW\*(C`r13\*(C'\fR to point to two separate small data areas. Selecting
-\&\fB\-mno\-eabi\fR means that the stack is aligned to a 16 byte boundary,
-do not call an initialization function from \f(CW\*(C`main\*(C'\fR, and the
-\&\fB\-msdata\fR option will only use \f(CW\*(C`r13\*(C'\fR to point to a single
-small data area. The \fB\-meabi\fR option is on by default if you
-configured \s-1GCC\s0 using one of the \fBpowerpc*\-*\-eabi*\fR options.
-.IP "\fB\-msdata=eabi\fR" 4
-.IX Item "-msdata=eabi"
-On System V.4 and embedded PowerPC systems, put small initialized
-\&\f(CW\*(C`const\*(C'\fR global and static data in the \fB.sdata2\fR section, which
-is pointed to by register \f(CW\*(C`r2\*(C'\fR. Put small initialized
-non\-\f(CW\*(C`const\*(C'\fR global and static data in the \fB.sdata\fR section,
-which is pointed to by register \f(CW\*(C`r13\*(C'\fR. Put small uninitialized
-global and static data in the \fB.sbss\fR section, which is adjacent to
-the \fB.sdata\fR section. The \fB\-msdata=eabi\fR option is
-incompatible with the \fB\-mrelocatable\fR option. The
-\&\fB\-msdata=eabi\fR option also sets the \fB\-memb\fR option.
-.IP "\fB\-msdata=sysv\fR" 4
-.IX Item "-msdata=sysv"
-On System V.4 and embedded PowerPC systems, put small global and static
-data in the \fB.sdata\fR section, which is pointed to by register
-\&\f(CW\*(C`r13\*(C'\fR. Put small uninitialized global and static data in the
-\&\fB.sbss\fR section, which is adjacent to the \fB.sdata\fR section.
-The \fB\-msdata=sysv\fR option is incompatible with the
-\&\fB\-mrelocatable\fR option.
-.IP "\fB\-msdata=default\fR" 4
-.IX Item "-msdata=default"
-.PD 0
-.IP "\fB\-msdata\fR" 4
-.IX Item "-msdata"
-.PD
-On System V.4 and embedded PowerPC systems, if \fB\-meabi\fR is used,
-compile code the same as \fB\-msdata=eabi\fR, otherwise compile code the
-same as \fB\-msdata=sysv\fR.
-.IP "\fB\-msdata=data\fR" 4
-.IX Item "-msdata=data"
-On System V.4 and embedded PowerPC systems, put small global
-data in the \fB.sdata\fR section. Put small uninitialized global
-data in the \fB.sbss\fR section. Do not use register \f(CW\*(C`r13\*(C'\fR
-to address small data however. This is the default behavior unless
-other \fB\-msdata\fR options are used.
-.IP "\fB\-msdata=none\fR" 4
-.IX Item "-msdata=none"
-.PD 0
-.IP "\fB\-mno\-sdata\fR" 4
-.IX Item "-mno-sdata"
-.PD
-On embedded PowerPC systems, put all initialized global and static data
-in the \fB.data\fR section, and all uninitialized data in the
-\&\fB.bss\fR section.
-.IP "\fB\-mblock\-move\-inline\-limit=\fR\fInum\fR" 4
-.IX Item "-mblock-move-inline-limit=num"
-Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure
-copies) less than or equal to \fInum\fR bytes. The minimum value for
-\&\fInum\fR is 32 bytes on 32\-bit targets and 64 bytes on 64\-bit
-targets. The default value is target-specific.
-.IP "\fB\-G\fR \fInum\fR" 4
-.IX Item "-G num"
-On embedded PowerPC systems, put global and static items less than or
-equal to \fInum\fR bytes into the small data or bss sections instead of
-the normal data or bss section. By default, \fInum\fR is 8. The
-\&\fB\-G\fR \fInum\fR switch is also passed to the linker.
-All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
-.IP "\fB\-mregnames\fR" 4
-.IX Item "-mregnames"
-.PD 0
-.IP "\fB\-mno\-regnames\fR" 4
-.IX Item "-mno-regnames"
-.PD
-On System V.4 and embedded PowerPC systems do (do not) emit register
-names in the assembly language output using symbolic forms.
-.IP "\fB\-mlongcall\fR" 4
-.IX Item "-mlongcall"
-.PD 0
-.IP "\fB\-mno\-longcall\fR" 4
-.IX Item "-mno-longcall"
-.PD
-By default assume that all calls are far away so that a longer more
-expensive calling sequence is required. This is required for calls
-further than 32 megabytes (33,554,432 bytes) from the current location.
-A short call will be generated if the compiler knows
-the call cannot be that far away. This setting can be overridden by
-the \f(CW\*(C`shortcall\*(C'\fR function attribute, or by \f(CW\*(C`#pragma
-longcall(0)\*(C'\fR.
-.Sp
-Some linkers are capable of detecting out-of-range calls and generating
-glue code on the fly. On these systems, long calls are unnecessary and
-generate slower code. As of this writing, the \s-1AIX\s0 linker can do this,
-as can the \s-1GNU\s0 linker for PowerPC/64. It is planned to add this feature
-to the \s-1GNU\s0 linker for 32\-bit PowerPC systems as well.
-.Sp
-On Darwin/PPC systems, \f(CW\*(C`#pragma longcall\*(C'\fR will generate \*(L"jbsr
-callee, L42\*(R", plus a \*(L"branch island\*(R" (glue code). The two target
-addresses represent the callee and the \*(L"branch island\*(R". The
-Darwin/PPC linker will prefer the first address and generate a \*(L"bl
-callee\*(R" if the \s-1PPC\s0 \*(L"bl\*(R" instruction will reach the callee directly;
-otherwise, the linker will generate \*(L"bl L42\*(R" to call the \*(L"branch
-island\*(R". The \*(L"branch island\*(R" is appended to the body of the
-calling function; it computes the full 32\-bit address of the callee
-and jumps to it.
-.Sp
-On Mach-O (Darwin) systems, this option directs the compiler emit to
-the glue for every direct call, and the Darwin linker decides whether
-to use or discard it.
-.Sp
-In the future, we may cause \s-1GCC\s0 to ignore all longcall specifications
-when the linker is known to generate glue.
-.IP "\fB\-mtls\-markers\fR" 4
-.IX Item "-mtls-markers"
-.PD 0
-.IP "\fB\-mno\-tls\-markers\fR" 4
-.IX Item "-mno-tls-markers"
-.PD
-Mark (do not mark) calls to \f(CW\*(C`_\|_tls_get_addr\*(C'\fR with a relocation
-specifying the function argument. The relocation allows ld to
-reliably associate function call with argument setup instructions for
-\&\s-1TLS\s0 optimization, which in turn allows gcc to better schedule the
-sequence.
-.IP "\fB\-pthread\fR" 4
-.IX Item "-pthread"
-Adds support for multithreading with the \fIpthreads\fR library.
-This option sets flags for both the preprocessor and linker.
-.IP "\fB\-mrecip\fR" 4
-.IX Item "-mrecip"
-.PD 0
-.IP "\fB\-mno\-recip\fR" 4
-.IX Item "-mno-recip"
-.PD
-This option will enable \s-1GCC\s0 to use the reciprocal estimate and
-reciprocal square root estimate instructions with additional
-Newton-Raphson steps to increase precision instead of doing a divide or
-square root and divide for floating point arguments. You should use
-the \fB\-ffast\-math\fR option when using \fB\-mrecip\fR (or at
-least \fB\-funsafe\-math\-optimizations\fR,
-\&\fB\-finite\-math\-only\fR, \fB\-freciprocal\-math\fR and
-\&\fB\-fno\-trapping\-math\fR). Note that while the throughput of the
-sequence is generally higher than the throughput of the non-reciprocal
-instruction, the precision of the sequence can be decreased by up to 2
-ulp (i.e. the inverse of 1.0 equals 0.99999994) for reciprocal square
-roots.
-.IP "\fB\-mrecip=\fR\fIopt\fR" 4
-.IX Item "-mrecip=opt"
-This option allows to control which reciprocal estimate instructions
-may be used. \fIopt\fR is a comma separated list of options, that may
-be preceded by a \f(CW\*(C`!\*(C'\fR to invert the option:
-\&\f(CW\*(C`all\*(C'\fR: enable all estimate instructions,
-\&\f(CW\*(C`default\*(C'\fR: enable the default instructions, equivalent to \fB\-mrecip\fR,
-\&\f(CW\*(C`none\*(C'\fR: disable all estimate instructions, equivalent to \fB\-mno\-recip\fR;
-\&\f(CW\*(C`div\*(C'\fR: enable the reciprocal approximation instructions for both single and double precision;
-\&\f(CW\*(C`divf\*(C'\fR: enable the single precision reciprocal approximation instructions;
-\&\f(CW\*(C`divd\*(C'\fR: enable the double precision reciprocal approximation instructions;
-\&\f(CW\*(C`rsqrt\*(C'\fR: enable the reciprocal square root approximation instructions for both single and double precision;
-\&\f(CW\*(C`rsqrtf\*(C'\fR: enable the single precision reciprocal square root approximation instructions;
-\&\f(CW\*(C`rsqrtd\*(C'\fR: enable the double precision reciprocal square root approximation instructions;
-.Sp
-So for example, \fB\-mrecip=all,!rsqrtd\fR would enable the
-all of the reciprocal estimate instructions, except for the
-\&\f(CW\*(C`FRSQRTE\*(C'\fR, \f(CW\*(C`XSRSQRTEDP\*(C'\fR, and \f(CW\*(C`XVRSQRTEDP\*(C'\fR instructions
-which handle the double precision reciprocal square root calculations.
-.IP "\fB\-mrecip\-precision\fR" 4
-.IX Item "-mrecip-precision"
-.PD 0
-.IP "\fB\-mno\-recip\-precision\fR" 4
-.IX Item "-mno-recip-precision"
-.PD
-Assume (do not assume) that the reciprocal estimate instructions
-provide higher precision estimates than is mandated by the powerpc
-\&\s-1ABI\s0. Selecting \fB\-mcpu=power6\fR or \fB\-mcpu=power7\fR
-automatically selects \fB\-mrecip\-precision\fR. The double
-precision square root estimate instructions are not generated by
-default on low precision machines, since they do not provide an
-estimate that converges after three steps.
-.IP "\fB\-mveclibabi=\fR\fItype\fR" 4
-.IX Item "-mveclibabi=type"
-Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
-external library. The only type supported at present is \f(CW\*(C`mass\*(C'\fR,
-which specifies to use \s-1IBM\s0's Mathematical Acceleration Subsystem
-(\s-1MASS\s0) libraries for vectorizing intrinsics using external libraries.
-\&\s-1GCC\s0 will currently emit calls to \f(CW\*(C`acosd2\*(C'\fR, \f(CW\*(C`acosf4\*(C'\fR,
-\&\f(CW\*(C`acoshd2\*(C'\fR, \f(CW\*(C`acoshf4\*(C'\fR, \f(CW\*(C`asind2\*(C'\fR, \f(CW\*(C`asinf4\*(C'\fR,
-\&\f(CW\*(C`asinhd2\*(C'\fR, \f(CW\*(C`asinhf4\*(C'\fR, \f(CW\*(C`atan2d2\*(C'\fR, \f(CW\*(C`atan2f4\*(C'\fR,
-\&\f(CW\*(C`atand2\*(C'\fR, \f(CW\*(C`atanf4\*(C'\fR, \f(CW\*(C`atanhd2\*(C'\fR, \f(CW\*(C`atanhf4\*(C'\fR,
-\&\f(CW\*(C`cbrtd2\*(C'\fR, \f(CW\*(C`cbrtf4\*(C'\fR, \f(CW\*(C`cosd2\*(C'\fR, \f(CW\*(C`cosf4\*(C'\fR,
-\&\f(CW\*(C`coshd2\*(C'\fR, \f(CW\*(C`coshf4\*(C'\fR, \f(CW\*(C`erfcd2\*(C'\fR, \f(CW\*(C`erfcf4\*(C'\fR,
-\&\f(CW\*(C`erfd2\*(C'\fR, \f(CW\*(C`erff4\*(C'\fR, \f(CW\*(C`exp2d2\*(C'\fR, \f(CW\*(C`exp2f4\*(C'\fR,
-\&\f(CW\*(C`expd2\*(C'\fR, \f(CW\*(C`expf4\*(C'\fR, \f(CW\*(C`expm1d2\*(C'\fR, \f(CW\*(C`expm1f4\*(C'\fR,
-\&\f(CW\*(C`hypotd2\*(C'\fR, \f(CW\*(C`hypotf4\*(C'\fR, \f(CW\*(C`lgammad2\*(C'\fR, \f(CW\*(C`lgammaf4\*(C'\fR,
-\&\f(CW\*(C`log10d2\*(C'\fR, \f(CW\*(C`log10f4\*(C'\fR, \f(CW\*(C`log1pd2\*(C'\fR, \f(CW\*(C`log1pf4\*(C'\fR,
-\&\f(CW\*(C`log2d2\*(C'\fR, \f(CW\*(C`log2f4\*(C'\fR, \f(CW\*(C`logd2\*(C'\fR, \f(CW\*(C`logf4\*(C'\fR,
-\&\f(CW\*(C`powd2\*(C'\fR, \f(CW\*(C`powf4\*(C'\fR, \f(CW\*(C`sind2\*(C'\fR, \f(CW\*(C`sinf4\*(C'\fR, \f(CW\*(C`sinhd2\*(C'\fR,
-\&\f(CW\*(C`sinhf4\*(C'\fR, \f(CW\*(C`sqrtd2\*(C'\fR, \f(CW\*(C`sqrtf4\*(C'\fR, \f(CW\*(C`tand2\*(C'\fR,
-\&\f(CW\*(C`tanf4\*(C'\fR, \f(CW\*(C`tanhd2\*(C'\fR, and \f(CW\*(C`tanhf4\*(C'\fR when generating code
-for power7. Both \fB\-ftree\-vectorize\fR and
-\&\fB\-funsafe\-math\-optimizations\fR have to be enabled. The \s-1MASS\s0
-libraries will have to be specified at link time.
-.IP "\fB\-mfriz\fR" 4
-.IX Item "-mfriz"
-.PD 0
-.IP "\fB\-mno\-friz\fR" 4
-.IX Item "-mno-friz"
-.PD
-Generate (do not generate) the \f(CW\*(C`friz\*(C'\fR instruction when the
-\&\fB\-funsafe\-math\-optimizations\fR option is used to optimize
-rounding a floating point value to 64\-bit integer and back to floating
-point. The \f(CW\*(C`friz\*(C'\fR instruction does not return the same value if
-the floating point number is too large to fit in an integer.
-.PP
-\fI\s-1RX\s0 Options\fR
-.IX Subsection "RX Options"
-.PP
-These command line options are defined for \s-1RX\s0 targets:
-.IP "\fB\-m64bit\-doubles\fR" 4
-.IX Item "-m64bit-doubles"
-.PD 0
-.IP "\fB\-m32bit\-doubles\fR" 4
-.IX Item "-m32bit-doubles"
-.PD
-Make the \f(CW\*(C`double\*(C'\fR data type be 64\-bits (\fB\-m64bit\-doubles\fR)
-or 32\-bits (\fB\-m32bit\-doubles\fR) in size. The default is
-\&\fB\-m32bit\-doubles\fR. \fINote\fR \s-1RX\s0 floating point hardware only
-works on 32\-bit values, which is why the default is
-\&\fB\-m32bit\-doubles\fR.
-.IP "\fB\-fpu\fR" 4
-.IX Item "-fpu"
-.PD 0
-.IP "\fB\-nofpu\fR" 4
-.IX Item "-nofpu"
-.PD
-Enables (\fB\-fpu\fR) or disables (\fB\-nofpu\fR) the use of \s-1RX\s0
-floating point hardware. The default is enabled for the \fI\s-1RX600\s0\fR
-series and disabled for the \fI\s-1RX200\s0\fR series.
-.Sp
-Floating point instructions will only be generated for 32\-bit floating
-point values however, so if the \fB\-m64bit\-doubles\fR option is in
-use then the \s-1FPU\s0 hardware will not be used for doubles.
-.Sp
-\&\fINote\fR If the \fB\-fpu\fR option is enabled then
-\&\fB\-funsafe\-math\-optimizations\fR is also enabled automatically.
-This is because the \s-1RX\s0 \s-1FPU\s0 instructions are themselves unsafe.
-.IP "\fB\-mcpu=\fR\fIname\fR" 4
-.IX Item "-mcpu=name"
-Selects the type of \s-1RX\s0 \s-1CPU\s0 to be targeted. Currently three types are
-supported, the generic \fI\s-1RX600\s0\fR and \fI\s-1RX200\s0\fR series hardware and
-the specific \fI\s-1RX610\s0\fR \s-1CPU\s0. The default is \fI\s-1RX600\s0\fR.
-.Sp
-The only difference between \fI\s-1RX600\s0\fR and \fI\s-1RX610\s0\fR is that the
-\&\fI\s-1RX610\s0\fR does not support the \f(CW\*(C`MVTIPL\*(C'\fR instruction.
-.Sp
-The \fI\s-1RX200\s0\fR series does not have a hardware floating point unit
-and so \fB\-nofpu\fR is enabled by default when this type is
-selected.
-.IP "\fB\-mbig\-endian\-data\fR" 4
-.IX Item "-mbig-endian-data"
-.PD 0
-.IP "\fB\-mlittle\-endian\-data\fR" 4
-.IX Item "-mlittle-endian-data"
-.PD
-Store data (but not code) in the big-endian format. The default is
-\&\fB\-mlittle\-endian\-data\fR, i.e. to store data in the little endian
-format.
-.IP "\fB\-msmall\-data\-limit=\fR\fIN\fR" 4
-.IX Item "-msmall-data-limit=N"
-Specifies the maximum size in bytes of global and static variables
-which can be placed into the small data area. Using the small data
-area can lead to smaller and faster code, but the size of area is
-limited and it is up to the programmer to ensure that the area does
-not overflow. Also when the small data area is used one of the \s-1RX\s0's
-registers (\f(CW\*(C`r13\*(C'\fR) is reserved for use pointing to this area, so
-it is no longer available for use by the compiler. This could result
-in slower and/or larger code if variables which once could have been
-held in \f(CW\*(C`r13\*(C'\fR are now pushed onto the stack.
-.Sp
-Note, common variables (variables which have not been initialised) and
-constants are not placed into the small data area as they are assigned
-to other sections in the output executable.
-.Sp
-The default value is zero, which disables this feature. Note, this
-feature is not enabled by default with higher optimization levels
-(\fB\-O2\fR etc) because of the potentially detrimental effects of
-reserving register \f(CW\*(C`r13\*(C'\fR. It is up to the programmer to
-experiment and discover whether this feature is of benefit to their
-program.
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-.PD 0
-.IP "\fB\-mno\-sim\fR" 4
-.IX Item "-mno-sim"
-.PD
-Use the simulator runtime. The default is to use the libgloss board
-specific runtime.
-.IP "\fB\-mas100\-syntax\fR" 4
-.IX Item "-mas100-syntax"
-.PD 0
-.IP "\fB\-mno\-as100\-syntax\fR" 4
-.IX Item "-mno-as100-syntax"
-.PD
-When generating assembler output use a syntax that is compatible with
-Renesas's \s-1AS100\s0 assembler. This syntax can also be handled by the \s-1GAS\s0
-assembler but it has some restrictions so generating it is not the
-default option.
-.IP "\fB\-mmax\-constant\-size=\fR\fIN\fR" 4
-.IX Item "-mmax-constant-size=N"
-Specifies the maximum size, in bytes, of a constant that can be used as
-an operand in a \s-1RX\s0 instruction. Although the \s-1RX\s0 instruction set does
-allow constants of up to 4 bytes in length to be used in instructions,
-a longer value equates to a longer instruction. Thus in some
-circumstances it can be beneficial to restrict the size of constants
-that are used in instructions. Constants that are too big are instead
-placed into a constant pool and referenced via register indirection.
-.Sp
-The value \fIN\fR can be between 0 and 4. A value of 0 (the default)
-or 4 means that constants of any size are allowed.
-.IP "\fB\-mrelax\fR" 4
-.IX Item "-mrelax"
-Enable linker relaxation. Linker relaxation is a process whereby the
-linker will attempt to reduce the size of a program by finding shorter
-versions of various instructions. Disabled by default.
-.IP "\fB\-mint\-register=\fR\fIN\fR" 4
-.IX Item "-mint-register=N"
-Specify the number of registers to reserve for fast interrupt handler
-functions. The value \fIN\fR can be between 0 and 4. A value of 1
-means that register \f(CW\*(C`r13\*(C'\fR will be reserved for the exclusive use
-of fast interrupt handlers. A value of 2 reserves \f(CW\*(C`r13\*(C'\fR and
-\&\f(CW\*(C`r12\*(C'\fR. A value of 3 reserves \f(CW\*(C`r13\*(C'\fR, \f(CW\*(C`r12\*(C'\fR and
-\&\f(CW\*(C`r11\*(C'\fR, and a value of 4 reserves \f(CW\*(C`r13\*(C'\fR through \f(CW\*(C`r10\*(C'\fR.
-A value of 0, the default, does not reserve any registers.
-.IP "\fB\-msave\-acc\-in\-interrupts\fR" 4
-.IX Item "-msave-acc-in-interrupts"
-Specifies that interrupt handler functions should preserve the
-accumulator register. This is only necessary if normal code might use
-the accumulator register, for example because it performs 64\-bit
-multiplications. The default is to ignore the accumulator as this
-makes the interrupt handlers faster.
-.PP
-\&\fINote:\fR The generic \s-1GCC\s0 command line \fB\-ffixed\-\fR\fIreg\fR
-has special significance to the \s-1RX\s0 port when used with the
-\&\f(CW\*(C`interrupt\*(C'\fR function attribute. This attribute indicates a
-function intended to process fast interrupts. \s-1GCC\s0 will will ensure
-that it only uses the registers \f(CW\*(C`r10\*(C'\fR, \f(CW\*(C`r11\*(C'\fR, \f(CW\*(C`r12\*(C'\fR
-and/or \f(CW\*(C`r13\*(C'\fR and only provided that the normal use of the
-corresponding registers have been restricted via the
-\&\fB\-ffixed\-\fR\fIreg\fR or \fB\-mint\-register\fR command line
-options.
-.PP
-\fIS/390 and zSeries Options\fR
-.IX Subsection "S/390 and zSeries Options"
-.PP
-These are the \fB\-m\fR options defined for the S/390 and zSeries architecture.
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-.PD 0
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-.PD
-Use (do not use) the hardware floating-point instructions and registers
-for floating-point operations. When \fB\-msoft\-float\fR is specified,
-functions in \fIlibgcc.a\fR will be used to perform floating-point
-operations. When \fB\-mhard\-float\fR is specified, the compiler
-generates \s-1IEEE\s0 floating-point instructions. This is the default.
-.IP "\fB\-mhard\-dfp\fR" 4
-.IX Item "-mhard-dfp"
-.PD 0
-.IP "\fB\-mno\-hard\-dfp\fR" 4
-.IX Item "-mno-hard-dfp"
-.PD
-Use (do not use) the hardware decimal-floating-point instructions for
-decimal-floating-point operations. When \fB\-mno\-hard\-dfp\fR is
-specified, functions in \fIlibgcc.a\fR will be used to perform
-decimal-floating-point operations. When \fB\-mhard\-dfp\fR is
-specified, the compiler generates decimal-floating-point hardware
-instructions. This is the default for \fB\-march=z9\-ec\fR or higher.
-.IP "\fB\-mlong\-double\-64\fR" 4
-.IX Item "-mlong-double-64"
-.PD 0
-.IP "\fB\-mlong\-double\-128\fR" 4
-.IX Item "-mlong-double-128"
-.PD
-These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
-of 64bit makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the \f(CW\*(C`double\*(C'\fR
-type. This is the default.
-.IP "\fB\-mbackchain\fR" 4
-.IX Item "-mbackchain"
-.PD 0
-.IP "\fB\-mno\-backchain\fR" 4
-.IX Item "-mno-backchain"
-.PD
-Store (do not store) the address of the caller's frame as backchain pointer
-into the callee's stack frame.
-A backchain may be needed to allow debugging using tools that do not understand
-\&\s-1DWARF\-2\s0 call frame information.
-When \fB\-mno\-packed\-stack\fR is in effect, the backchain pointer is stored
-at the bottom of the stack frame; when \fB\-mpacked\-stack\fR is in effect,
-the backchain is placed into the topmost word of the 96/160 byte register
-save area.
-.Sp
-In general, code compiled with \fB\-mbackchain\fR is call-compatible with
-code compiled with \fB\-mmo\-backchain\fR; however, use of the backchain
-for debugging purposes usually requires that the whole binary is built with
-\&\fB\-mbackchain\fR. Note that the combination of \fB\-mbackchain\fR,
-\&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported. In order
-to build a linux kernel use \fB\-msoft\-float\fR.
-.Sp
-The default is to not maintain the backchain.
-.IP "\fB\-mpacked\-stack\fR" 4
-.IX Item "-mpacked-stack"
-.PD 0
-.IP "\fB\-mno\-packed\-stack\fR" 4
-.IX Item "-mno-packed-stack"
-.PD
-Use (do not use) the packed stack layout. When \fB\-mno\-packed\-stack\fR is
-specified, the compiler uses the all fields of the 96/160 byte register save
-area only for their default purpose; unused fields still take up stack space.
-When \fB\-mpacked\-stack\fR is specified, register save slots are densely
-packed at the top of the register save area; unused space is reused for other
-purposes, allowing for more efficient use of the available stack space.
-However, when \fB\-mbackchain\fR is also in effect, the topmost word of
-the save area is always used to store the backchain, and the return address
-register is always saved two words below the backchain.
-.Sp
-As long as the stack frame backchain is not used, code generated with
-\&\fB\-mpacked\-stack\fR is call-compatible with code generated with
-\&\fB\-mno\-packed\-stack\fR. Note that some non-FSF releases of \s-1GCC\s0 2.95 for
-S/390 or zSeries generated code that uses the stack frame backchain at run
-time, not just for debugging purposes. Such code is not call-compatible
-with code compiled with \fB\-mpacked\-stack\fR. Also, note that the
-combination of \fB\-mbackchain\fR,
-\&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported. In order
-to build a linux kernel use \fB\-msoft\-float\fR.
-.Sp
-The default is to not use the packed stack layout.
-.IP "\fB\-msmall\-exec\fR" 4
-.IX Item "-msmall-exec"
-.PD 0
-.IP "\fB\-mno\-small\-exec\fR" 4
-.IX Item "-mno-small-exec"
-.PD
-Generate (or do not generate) code using the \f(CW\*(C`bras\*(C'\fR instruction
-to do subroutine calls.
-This only works reliably if the total executable size does not
-exceed 64k. The default is to use the \f(CW\*(C`basr\*(C'\fR instruction instead,
-which does not have this limitation.
-.IP "\fB\-m64\fR" 4
-.IX Item "-m64"
-.PD 0
-.IP "\fB\-m31\fR" 4
-.IX Item "-m31"
-.PD
-When \fB\-m31\fR is specified, generate code compliant to the
-GNU/Linux for S/390 \s-1ABI\s0. When \fB\-m64\fR is specified, generate
-code compliant to the GNU/Linux for zSeries \s-1ABI\s0. This allows \s-1GCC\s0 in
-particular to generate 64\-bit instructions. For the \fBs390\fR
-targets, the default is \fB\-m31\fR, while the \fBs390x\fR
-targets default to \fB\-m64\fR.
-.IP "\fB\-mzarch\fR" 4
-.IX Item "-mzarch"
-.PD 0
-.IP "\fB\-mesa\fR" 4
-.IX Item "-mesa"
-.PD
-When \fB\-mzarch\fR is specified, generate code using the
-instructions available on z/Architecture.
-When \fB\-mesa\fR is specified, generate code using the
-instructions available on \s-1ESA/390\s0. Note that \fB\-mesa\fR is
-not possible with \fB\-m64\fR.
-When generating code compliant to the GNU/Linux for S/390 \s-1ABI\s0,
-the default is \fB\-mesa\fR. When generating code compliant
-to the GNU/Linux for zSeries \s-1ABI\s0, the default is \fB\-mzarch\fR.
-.IP "\fB\-mmvcle\fR" 4
-.IX Item "-mmvcle"
-.PD 0
-.IP "\fB\-mno\-mvcle\fR" 4
-.IX Item "-mno-mvcle"
-.PD
-Generate (or do not generate) code using the \f(CW\*(C`mvcle\*(C'\fR instruction
-to perform block moves. When \fB\-mno\-mvcle\fR is specified,
-use a \f(CW\*(C`mvc\*(C'\fR loop instead. This is the default unless optimizing for
-size.
-.IP "\fB\-mdebug\fR" 4
-.IX Item "-mdebug"
-.PD 0
-.IP "\fB\-mno\-debug\fR" 4
-.IX Item "-mno-debug"
-.PD
-Print (or do not print) additional debug information when compiling.
-The default is to not print debug information.
-.IP "\fB\-march=\fR\fIcpu-type\fR" 4
-.IX Item "-march=cpu-type"
-Generate code that will run on \fIcpu-type\fR, which is the name of a system
-representing a certain processor type. Possible values for
-\&\fIcpu-type\fR are \fBg5\fR, \fBg6\fR, \fBz900\fR, \fBz990\fR,
-\&\fBz9\-109\fR, \fBz9\-ec\fR and \fBz10\fR.
-When generating code using the instructions available on z/Architecture,
-the default is \fB\-march=z900\fR. Otherwise, the default is
-\&\fB\-march=g5\fR.
-.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
-.IX Item "-mtune=cpu-type"
-Tune to \fIcpu-type\fR everything applicable about the generated code,
-except for the \s-1ABI\s0 and the set of available instructions.
-The list of \fIcpu-type\fR values is the same as for \fB\-march\fR.
-The default is the value used for \fB\-march\fR.
-.IP "\fB\-mtpf\-trace\fR" 4
-.IX Item "-mtpf-trace"
-.PD 0
-.IP "\fB\-mno\-tpf\-trace\fR" 4
-.IX Item "-mno-tpf-trace"
-.PD
-Generate code that adds (does not add) in \s-1TPF\s0 \s-1OS\s0 specific branches to trace
-routines in the operating system. This option is off by default, even
-when compiling for the \s-1TPF\s0 \s-1OS\s0.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Generate code that uses (does not use) the floating point multiply and
-accumulate instructions. These instructions are generated by default if
-hardware floating point is used.
-.IP "\fB\-mwarn\-framesize=\fR\fIframesize\fR" 4
-.IX Item "-mwarn-framesize=framesize"
-Emit a warning if the current function exceeds the given frame size. Because
-this is a compile time check it doesn't need to be a real problem when the program
-runs. It is intended to identify functions which most probably cause
-a stack overflow. It is useful to be used in an environment with limited stack
-size e.g. the linux kernel.
-.IP "\fB\-mwarn\-dynamicstack\fR" 4
-.IX Item "-mwarn-dynamicstack"
-Emit a warning if the function calls alloca or uses dynamically
-sized arrays. This is generally a bad idea with a limited stack size.
-.IP "\fB\-mstack\-guard=\fR\fIstack-guard\fR" 4
-.IX Item "-mstack-guard=stack-guard"
-.PD 0
-.IP "\fB\-mstack\-size=\fR\fIstack-size\fR" 4
-.IX Item "-mstack-size=stack-size"
-.PD
-If these options are provided the s390 back end emits additional instructions in
-the function prologue which trigger a trap if the stack size is \fIstack-guard\fR
-bytes above the \fIstack-size\fR (remember that the stack on s390 grows downward).
-If the \fIstack-guard\fR option is omitted the smallest power of 2 larger than
-the frame size of the compiled function is chosen.
-These options are intended to be used to help debugging stack overflow problems.
-The additionally emitted code causes only little overhead and hence can also be
-used in production like systems without greater performance degradation. The given
-values have to be exact powers of 2 and \fIstack-size\fR has to be greater than
-\&\fIstack-guard\fR without exceeding 64k.
-In order to be efficient the extra code makes the assumption that the stack starts
-at an address aligned to the value given by \fIstack-size\fR.
-The \fIstack-guard\fR option can only be used in conjunction with \fIstack-size\fR.
-.PP
-\fIScore Options\fR
-.IX Subsection "Score Options"
-.PP
-These options are defined for Score implementations:
-.IP "\fB\-meb\fR" 4
-.IX Item "-meb"
-Compile code for big endian mode. This is the default.
-.IP "\fB\-mel\fR" 4
-.IX Item "-mel"
-Compile code for little endian mode.
-.IP "\fB\-mnhwloop\fR" 4
-.IX Item "-mnhwloop"
-Disable generate bcnz instruction.
-.IP "\fB\-muls\fR" 4
-.IX Item "-muls"
-Enable generate unaligned load and store instruction.
-.IP "\fB\-mmac\fR" 4
-.IX Item "-mmac"
-Enable the use of multiply-accumulate instructions. Disabled by default.
-.IP "\fB\-mscore5\fR" 4
-.IX Item "-mscore5"
-Specify the \s-1SCORE5\s0 as the target architecture.
-.IP "\fB\-mscore5u\fR" 4
-.IX Item "-mscore5u"
-Specify the \s-1SCORE5U\s0 of the target architecture.
-.IP "\fB\-mscore7\fR" 4
-.IX Item "-mscore7"
-Specify the \s-1SCORE7\s0 as the target architecture. This is the default.
-.IP "\fB\-mscore7d\fR" 4
-.IX Item "-mscore7d"
-Specify the \s-1SCORE7D\s0 as the target architecture.
-.PP
-\fI\s-1SH\s0 Options\fR
-.IX Subsection "SH Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1SH\s0 implementations:
-.IP "\fB\-m1\fR" 4
-.IX Item "-m1"
-Generate code for the \s-1SH1\s0.
-.IP "\fB\-m2\fR" 4
-.IX Item "-m2"
-Generate code for the \s-1SH2\s0.
-.IP "\fB\-m2e\fR" 4
-.IX Item "-m2e"
-Generate code for the SH2e.
-.IP "\fB\-m2a\-nofpu\fR" 4
-.IX Item "-m2a-nofpu"
-Generate code for the SH2a without \s-1FPU\s0, or for a SH2a\-FPU in such a way
-that the floating-point unit is not used.
-.IP "\fB\-m2a\-single\-only\fR" 4
-.IX Item "-m2a-single-only"
-Generate code for the SH2a\-FPU, in such a way that no double-precision
-floating point operations are used.
-.IP "\fB\-m2a\-single\fR" 4
-.IX Item "-m2a-single"
-Generate code for the SH2a\-FPU assuming the floating-point unit is in
-single-precision mode by default.
-.IP "\fB\-m2a\fR" 4
-.IX Item "-m2a"
-Generate code for the SH2a\-FPU assuming the floating-point unit is in
-double-precision mode by default.
-.IP "\fB\-m3\fR" 4
-.IX Item "-m3"
-Generate code for the \s-1SH3\s0.
-.IP "\fB\-m3e\fR" 4
-.IX Item "-m3e"
-Generate code for the SH3e.
-.IP "\fB\-m4\-nofpu\fR" 4
-.IX Item "-m4-nofpu"
-Generate code for the \s-1SH4\s0 without a floating-point unit.
-.IP "\fB\-m4\-single\-only\fR" 4
-.IX Item "-m4-single-only"
-Generate code for the \s-1SH4\s0 with a floating-point unit that only
-supports single-precision arithmetic.
-.IP "\fB\-m4\-single\fR" 4
-.IX Item "-m4-single"
-Generate code for the \s-1SH4\s0 assuming the floating-point unit is in
-single-precision mode by default.
-.IP "\fB\-m4\fR" 4
-.IX Item "-m4"
-Generate code for the \s-1SH4\s0.
-.IP "\fB\-m4a\-nofpu\fR" 4
-.IX Item "-m4a-nofpu"
-Generate code for the SH4al\-dsp, or for a SH4a in such a way that the
-floating-point unit is not used.
-.IP "\fB\-m4a\-single\-only\fR" 4
-.IX Item "-m4a-single-only"
-Generate code for the SH4a, in such a way that no double-precision
-floating point operations are used.
-.IP "\fB\-m4a\-single\fR" 4
-.IX Item "-m4a-single"
-Generate code for the SH4a assuming the floating-point unit is in
-single-precision mode by default.
-.IP "\fB\-m4a\fR" 4
-.IX Item "-m4a"
-Generate code for the SH4a.
-.IP "\fB\-m4al\fR" 4
-.IX Item "-m4al"
-Same as \fB\-m4a\-nofpu\fR, except that it implicitly passes
-\&\fB\-dsp\fR to the assembler. \s-1GCC\s0 doesn't generate any \s-1DSP\s0
-instructions at the moment.
-.IP "\fB\-mb\fR" 4
-.IX Item "-mb"
-Compile code for the processor in big endian mode.
-.IP "\fB\-ml\fR" 4
-.IX Item "-ml"
-Compile code for the processor in little endian mode.
-.IP "\fB\-mdalign\fR" 4
-.IX Item "-mdalign"
-Align doubles at 64\-bit boundaries. Note that this changes the calling
-conventions, and thus some functions from the standard C library will
-not work unless you recompile it first with \fB\-mdalign\fR.
-.IP "\fB\-mrelax\fR" 4
-.IX Item "-mrelax"
-Shorten some address references at link time, when possible; uses the
-linker option \fB\-relax\fR.
-.IP "\fB\-mbigtable\fR" 4
-.IX Item "-mbigtable"
-Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables. The default is to use
-16\-bit offsets.
-.IP "\fB\-mbitops\fR" 4
-.IX Item "-mbitops"
-Enable the use of bit manipulation instructions on \s-1SH2A\s0.
-.IP "\fB\-mfmovd\fR" 4
-.IX Item "-mfmovd"
-Enable the use of the instruction \f(CW\*(C`fmovd\*(C'\fR. Check \fB\-mdalign\fR for
-alignment constraints.
-.IP "\fB\-mhitachi\fR" 4
-.IX Item "-mhitachi"
-Comply with the calling conventions defined by Renesas.
-.IP "\fB\-mrenesas\fR" 4
-.IX Item "-mrenesas"
-Comply with the calling conventions defined by Renesas.
-.IP "\fB\-mno\-renesas\fR" 4
-.IX Item "-mno-renesas"
-Comply with the calling conventions defined for \s-1GCC\s0 before the Renesas
-conventions were available. This option is the default for all
-targets of the \s-1SH\s0 toolchain except for \fBsh-symbianelf\fR.
-.IP "\fB\-mnomacsave\fR" 4
-.IX Item "-mnomacsave"
-Mark the \f(CW\*(C`MAC\*(C'\fR register as call-clobbered, even if
-\&\fB\-mhitachi\fR is given.
-.IP "\fB\-mieee\fR" 4
-.IX Item "-mieee"
-Increase IEEE-compliance of floating-point code.
-At the moment, this is equivalent to \fB\-fno\-finite\-math\-only\fR.
-When generating 16 bit \s-1SH\s0 opcodes, getting IEEE-conforming results for
-comparisons of NANs / infinities incurs extra overhead in every
-floating point comparison, therefore the default is set to
-\&\fB\-ffinite\-math\-only\fR.
-.IP "\fB\-minline\-ic_invalidate\fR" 4
-.IX Item "-minline-ic_invalidate"
-Inline code to invalidate instruction cache entries after setting up
-nested function trampolines.
-This option has no effect if \-musermode is in effect and the selected
-code generation option (e.g. \-m4) does not allow the use of the icbi
-instruction.
-If the selected code generation option does not allow the use of the icbi
-instruction, and \-musermode is not in effect, the inlined code will
-manipulate the instruction cache address array directly with an associative
-write. This not only requires privileged mode, but it will also
-fail if the cache line had been mapped via the \s-1TLB\s0 and has become unmapped.
-.IP "\fB\-misize\fR" 4
-.IX Item "-misize"
-Dump instruction size and location in the assembly code.
-.IP "\fB\-mpadstruct\fR" 4
-.IX Item "-mpadstruct"
-This option is deprecated. It pads structures to multiple of 4 bytes,
-which is incompatible with the \s-1SH\s0 \s-1ABI\s0.
-.IP "\fB\-mspace\fR" 4
-.IX Item "-mspace"
-Optimize for space instead of speed. Implied by \fB\-Os\fR.
-.IP "\fB\-mprefergot\fR" 4
-.IX Item "-mprefergot"
-When generating position-independent code, emit function calls using
-the Global Offset Table instead of the Procedure Linkage Table.
-.IP "\fB\-musermode\fR" 4
-.IX Item "-musermode"
-Don't generate privileged mode only code; implies \-mno\-inline\-ic_invalidate
-if the inlined code would not work in user mode.
-This is the default when the target is \f(CW\*(C`sh\-*\-linux*\*(C'\fR.
-.IP "\fB\-multcost=\fR\fInumber\fR" 4
-.IX Item "-multcost=number"
-Set the cost to assume for a multiply insn.
-.IP "\fB\-mdiv=\fR\fIstrategy\fR" 4
-.IX Item "-mdiv=strategy"
-Set the division strategy to use for SHmedia code. \fIstrategy\fR must be
-one of: call, call2, fp, inv, inv:minlat, inv20u, inv20l, inv:call,
-inv:call2, inv:fp .
-\&\*(L"fp\*(R" performs the operation in floating point. This has a very high latency,
-but needs only a few instructions, so it might be a good choice if
-your code has enough easily exploitable \s-1ILP\s0 to allow the compiler to
-schedule the floating point instructions together with other instructions.
-Division by zero causes a floating point exception.
-\&\*(L"inv\*(R" uses integer operations to calculate the inverse of the divisor,
-and then multiplies the dividend with the inverse. This strategy allows
-cse and hoisting of the inverse calculation. Division by zero calculates
-an unspecified result, but does not trap.
-\&\*(L"inv:minlat\*(R" is a variant of \*(L"inv\*(R" where if no cse / hoisting opportunities
-have been found, or if the entire operation has been hoisted to the same
-place, the last stages of the inverse calculation are intertwined with the
-final multiply to reduce the overall latency, at the expense of using a few
-more instructions, and thus offering fewer scheduling opportunities with
-other code.
-\&\*(L"call\*(R" calls a library function that usually implements the inv:minlat
-strategy.
-This gives high code density for m5\-*media\-nofpu compilations.
-\&\*(L"call2\*(R" uses a different entry point of the same library function, where it
-assumes that a pointer to a lookup table has already been set up, which
-exposes the pointer load to cse / code hoisting optimizations.
-\&\*(L"inv:call\*(R", \*(L"inv:call2\*(R" and \*(L"inv:fp\*(R" all use the \*(L"inv\*(R" algorithm for initial
-code generation, but if the code stays unoptimized, revert to the \*(L"call\*(R",
-\&\*(L"call2\*(R", or \*(L"fp\*(R" strategies, respectively. Note that the
-potentially-trapping side effect of division by zero is carried by a
-separate instruction, so it is possible that all the integer instructions
-are hoisted out, but the marker for the side effect stays where it is.
-A recombination to fp operations or a call is not possible in that case.
-\&\*(L"inv20u\*(R" and \*(L"inv20l\*(R" are variants of the \*(L"inv:minlat\*(R" strategy. In the case
-that the inverse calculation was nor separated from the multiply, they speed
-up division where the dividend fits into 20 bits (plus sign where applicable),
-by inserting a test to skip a number of operations in this case; this test
-slows down the case of larger dividends. inv20u assumes the case of a such
-a small dividend to be unlikely, and inv20l assumes it to be likely.
-.IP "\fB\-maccumulate\-outgoing\-args\fR" 4
-.IX Item "-maccumulate-outgoing-args"
-Reserve space once for outgoing arguments in the function prologue rather
-than around each call. Generally beneficial for performance and size. Also
-needed for unwinding to avoid changing the stack frame around conditional code.
-.IP "\fB\-mdivsi3_libfunc=\fR\fIname\fR" 4
-.IX Item "-mdivsi3_libfunc=name"
-Set the name of the library function used for 32 bit signed division to
-\&\fIname\fR. This only affect the name used in the call and inv:call
-division strategies, and the compiler will still expect the same
-sets of input/output/clobbered registers as if this option was not present.
-.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
-.IX Item "-mfixed-range=register-range"
-Generate code treating the given register range as fixed registers.
-A fixed register is one that the register allocator can not use. This is
-useful when compiling kernel code. A register range is specified as
-two registers separated by a dash. Multiple register ranges can be
-specified separated by a comma.
-.IP "\fB\-madjust\-unroll\fR" 4
-.IX Item "-madjust-unroll"
-Throttle unrolling to avoid thrashing target registers.
-This option only has an effect if the gcc code base supports the
-\&\s-1TARGET_ADJUST_UNROLL_MAX\s0 target hook.
-.IP "\fB\-mindexed\-addressing\fR" 4
-.IX Item "-mindexed-addressing"
-Enable the use of the indexed addressing mode for SHmedia32/SHcompact.
-This is only safe if the hardware and/or \s-1OS\s0 implement 32 bit wrap-around
-semantics for the indexed addressing mode. The architecture allows the
-implementation of processors with 64 bit \s-1MMU\s0, which the \s-1OS\s0 could use to
-get 32 bit addressing, but since no current hardware implementation supports
-this or any other way to make the indexed addressing mode safe to use in
-the 32 bit \s-1ABI\s0, the default is \-mno\-indexed\-addressing.
-.IP "\fB\-mgettrcost=\fR\fInumber\fR" 4
-.IX Item "-mgettrcost=number"
-Set the cost assumed for the gettr instruction to \fInumber\fR.
-The default is 2 if \fB\-mpt\-fixed\fR is in effect, 100 otherwise.
-.IP "\fB\-mpt\-fixed\fR" 4
-.IX Item "-mpt-fixed"
-Assume pt* instructions won't trap. This will generally generate better
-scheduled code, but is unsafe on current hardware. The current architecture
-definition says that ptabs and ptrel trap when the target anded with 3 is 3.
-This has the unintentional effect of making it unsafe to schedule ptabs /
-ptrel before a branch, or hoist it out of a loop. For example,
-_\|_do_global_ctors, a part of libgcc that runs constructors at program
-startup, calls functions in a list which is delimited by \-1. With the
-\&\-mpt\-fixed option, the ptabs will be done before testing against \-1.
-That means that all the constructors will be run a bit quicker, but when
-the loop comes to the end of the list, the program crashes because ptabs
-loads \-1 into a target register. Since this option is unsafe for any
-hardware implementing the current architecture specification, the default
-is \-mno\-pt\-fixed. Unless the user specifies a specific cost with
-\&\fB\-mgettrcost\fR, \-mno\-pt\-fixed also implies \fB\-mgettrcost=100\fR;
-this deters register allocation using target registers for storing
-ordinary integers.
-.IP "\fB\-minvalid\-symbols\fR" 4
-.IX Item "-minvalid-symbols"
-Assume symbols might be invalid. Ordinary function symbols generated by
-the compiler will always be valid to load with movi/shori/ptabs or
-movi/shori/ptrel, but with assembler and/or linker tricks it is possible
-to generate symbols that will cause ptabs / ptrel to trap.
-This option is only meaningful when \fB\-mno\-pt\-fixed\fR is in effect.
-It will then prevent cross-basic-block cse, hoisting and most scheduling
-of symbol loads. The default is \fB\-mno\-invalid\-symbols\fR.
-.PP
-\fISolaris 2 Options\fR
-.IX Subsection "Solaris 2 Options"
-.PP
-These \fB\-m\fR options are supported on Solaris 2:
-.IP "\fB\-mimpure\-text\fR" 4
-.IX Item "-mimpure-text"
-\&\fB\-mimpure\-text\fR, used in addition to \fB\-shared\fR, tells
-the compiler to not pass \fB\-z text\fR to the linker when linking a
-shared object. Using this option, you can link position-dependent
-code into a shared object.
-.Sp
-\&\fB\-mimpure\-text\fR suppresses the \*(L"relocations remain against
-allocatable but non-writable sections\*(R" linker error message.
-However, the necessary relocations will trigger copy-on-write, and the
-shared object is not actually shared across processes. Instead of
-using \fB\-mimpure\-text\fR, you should compile all source code with
-\&\fB\-fpic\fR or \fB\-fPIC\fR.
-.PP
-These switches are supported in addition to the above on Solaris 2:
-.IP "\fB\-threads\fR" 4
-.IX Item "-threads"
-Add support for multithreading using the Solaris threads library. This
-option sets flags for both the preprocessor and linker. This option does
-not affect the thread safety of object code produced by the compiler or
-that of libraries supplied with it.
-.IP "\fB\-pthreads\fR" 4
-.IX Item "-pthreads"
-Add support for multithreading using the \s-1POSIX\s0 threads library. This
-option sets flags for both the preprocessor and linker. This option does
-not affect the thread safety of object code produced by the compiler or
-that of libraries supplied with it.
-.IP "\fB\-pthread\fR" 4
-.IX Item "-pthread"
-This is a synonym for \fB\-pthreads\fR.
-.PP
-\fI\s-1SPARC\s0 Options\fR
-.IX Subsection "SPARC Options"
-.PP
-These \fB\-m\fR options are supported on the \s-1SPARC:\s0
-.IP "\fB\-mno\-app\-regs\fR" 4
-.IX Item "-mno-app-regs"
-.PD 0
-.IP "\fB\-mapp\-regs\fR" 4
-.IX Item "-mapp-regs"
-.PD
-Specify \fB\-mapp\-regs\fR to generate output using the global registers
-2 through 4, which the \s-1SPARC\s0 \s-1SVR4\s0 \s-1ABI\s0 reserves for applications. This
-is the default.
-.Sp
-To be fully \s-1SVR4\s0 \s-1ABI\s0 compliant at the cost of some performance loss,
-specify \fB\-mno\-app\-regs\fR. You should compile libraries and system
-software with this option.
-.IP "\fB\-mfpu\fR" 4
-.IX Item "-mfpu"
-.PD 0
-.IP "\fB\-mhard\-float\fR" 4
-.IX Item "-mhard-float"
-.PD
-Generate output containing floating point instructions. This is the
-default.
-.IP "\fB\-mno\-fpu\fR" 4
-.IX Item "-mno-fpu"
-.PD 0
-.IP "\fB\-msoft\-float\fR" 4
-.IX Item "-msoft-float"
-.PD
-Generate output containing library calls for floating point.
-\&\fBWarning:\fR the requisite libraries are not available for all \s-1SPARC\s0
-targets. Normally the facilities of the machine's usual C compiler are
-used, but this cannot be done directly in cross-compilation. You must make
-your own arrangements to provide suitable library functions for
-cross-compilation. The embedded targets \fBsparc\-*\-aout\fR and
-\&\fBsparclite\-*\-*\fR do provide software floating point support.
-.Sp
-\&\fB\-msoft\-float\fR changes the calling convention in the output file;
-therefore, it is only useful if you compile \fIall\fR of a program with
-this option. In particular, you need to compile \fIlibgcc.a\fR, the
-library that comes with \s-1GCC\s0, with \fB\-msoft\-float\fR in order for
-this to work.
-.IP "\fB\-mhard\-quad\-float\fR" 4
-.IX Item "-mhard-quad-float"
-Generate output containing quad-word (long double) floating point
-instructions.
-.IP "\fB\-msoft\-quad\-float\fR" 4
-.IX Item "-msoft-quad-float"
-Generate output containing library calls for quad-word (long double)
-floating point instructions. The functions called are those specified
-in the \s-1SPARC\s0 \s-1ABI\s0. This is the default.
-.Sp
-As of this writing, there are no \s-1SPARC\s0 implementations that have hardware
-support for the quad-word floating point instructions. They all invoke
-a trap handler for one of these instructions, and then the trap handler
-emulates the effect of the instruction. Because of the trap handler overhead,
-this is much slower than calling the \s-1ABI\s0 library routines. Thus the
-\&\fB\-msoft\-quad\-float\fR option is the default.
-.IP "\fB\-mno\-unaligned\-doubles\fR" 4
-.IX Item "-mno-unaligned-doubles"
-.PD 0
-.IP "\fB\-munaligned\-doubles\fR" 4
-.IX Item "-munaligned-doubles"
-.PD
-Assume that doubles have 8 byte alignment. This is the default.
-.Sp
-With \fB\-munaligned\-doubles\fR, \s-1GCC\s0 assumes that doubles have 8 byte
-alignment only if they are contained in another type, or if they have an
-absolute address. Otherwise, it assumes they have 4 byte alignment.
-Specifying this option avoids some rare compatibility problems with code
-generated by other compilers. It is not the default because it results
-in a performance loss, especially for floating point code.
-.IP "\fB\-mno\-faster\-structs\fR" 4
-.IX Item "-mno-faster-structs"
-.PD 0
-.IP "\fB\-mfaster\-structs\fR" 4
-.IX Item "-mfaster-structs"
-.PD
-With \fB\-mfaster\-structs\fR, the compiler assumes that structures
-should have 8 byte alignment. This enables the use of pairs of
-\&\f(CW\*(C`ldd\*(C'\fR and \f(CW\*(C`std\*(C'\fR instructions for copies in structure
-assignment, in place of twice as many \f(CW\*(C`ld\*(C'\fR and \f(CW\*(C`st\*(C'\fR pairs.
-However, the use of this changed alignment directly violates the \s-1SPARC\s0
-\&\s-1ABI\s0. Thus, it's intended only for use on targets where the developer
-acknowledges that their resulting code will not be directly in line with
-the rules of the \s-1ABI\s0.
-.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
-.IX Item "-mcpu=cpu_type"
-Set the instruction set, register set, and instruction scheduling parameters
-for machine type \fIcpu_type\fR. Supported values for \fIcpu_type\fR are
-\&\fBv7\fR, \fBcypress\fR, \fBv8\fR, \fBsupersparc\fR, \fBhypersparc\fR,
-\&\fBleon\fR, \fBsparclite\fR, \fBf930\fR, \fBf934\fR, \fBsparclite86x\fR,
-\&\fBsparclet\fR, \fBtsc701\fR, \fBv9\fR, \fBultrasparc\fR,
-\&\fBultrasparc3\fR, \fBniagara\fR and \fBniagara2\fR.
-.Sp
-Default instruction scheduling parameters are used for values that select
-an architecture and not an implementation. These are \fBv7\fR, \fBv8\fR,
-\&\fBsparclite\fR, \fBsparclet\fR, \fBv9\fR.
-.Sp
-Here is a list of each supported architecture and their supported
-implementations.
-.Sp
-.Vb 5
-\& v7: cypress
-\& v8: supersparc, hypersparc, leon
-\& sparclite: f930, f934, sparclite86x
-\& sparclet: tsc701
-\& v9: ultrasparc, ultrasparc3, niagara, niagara2
-.Ve
-.Sp
-By default (unless configured otherwise), \s-1GCC\s0 generates code for the V7
-variant of the \s-1SPARC\s0 architecture. With \fB\-mcpu=cypress\fR, the compiler
-additionally optimizes it for the Cypress \s-1CY7C602\s0 chip, as used in the
-SPARCStation/SPARCServer 3xx series. This is also appropriate for the older
-SPARCStation 1, 2, \s-1IPX\s0 etc.
-.Sp
-With \fB\-mcpu=v8\fR, \s-1GCC\s0 generates code for the V8 variant of the \s-1SPARC\s0
-architecture. The only difference from V7 code is that the compiler emits
-the integer multiply and integer divide instructions which exist in \s-1SPARC\-V8\s0
-but not in \s-1SPARC\-V7\s0. With \fB\-mcpu=supersparc\fR, the compiler additionally
-optimizes it for the SuperSPARC chip, as used in the SPARCStation 10, 1000 and
-2000 series.
-.Sp
-With \fB\-mcpu=sparclite\fR, \s-1GCC\s0 generates code for the SPARClite variant of
-the \s-1SPARC\s0 architecture. This adds the integer multiply, integer divide step
-and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClite but not in \s-1SPARC\-V7\s0.
-With \fB\-mcpu=f930\fR, the compiler additionally optimizes it for the
-Fujitsu \s-1MB86930\s0 chip, which is the original SPARClite, with no \s-1FPU\s0. With
-\&\fB\-mcpu=f934\fR, the compiler additionally optimizes it for the Fujitsu
-\&\s-1MB86934\s0 chip, which is the more recent SPARClite with \s-1FPU\s0.
-.Sp
-With \fB\-mcpu=sparclet\fR, \s-1GCC\s0 generates code for the SPARClet variant of
-the \s-1SPARC\s0 architecture. This adds the integer multiply, multiply/accumulate,
-integer divide step and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClet
-but not in \s-1SPARC\-V7\s0. With \fB\-mcpu=tsc701\fR, the compiler additionally
-optimizes it for the \s-1TEMIC\s0 SPARClet chip.
-.Sp
-With \fB\-mcpu=v9\fR, \s-1GCC\s0 generates code for the V9 variant of the \s-1SPARC\s0
-architecture. This adds 64\-bit integer and floating-point move instructions,
-3 additional floating-point condition code registers and conditional move
-instructions. With \fB\-mcpu=ultrasparc\fR, the compiler additionally
-optimizes it for the Sun UltraSPARC I/II/IIi chips. With
-\&\fB\-mcpu=ultrasparc3\fR, the compiler additionally optimizes it for the
-Sun UltraSPARC III/III+/IIIi/IIIi+/IV/IV+ chips. With
-\&\fB\-mcpu=niagara\fR, the compiler additionally optimizes it for
-Sun UltraSPARC T1 chips. With \fB\-mcpu=niagara2\fR, the compiler
-additionally optimizes it for Sun UltraSPARC T2 chips.
-.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
-.IX Item "-mtune=cpu_type"
-Set the instruction scheduling parameters for machine type
-\&\fIcpu_type\fR, but do not set the instruction set or register set that the
-option \fB\-mcpu=\fR\fIcpu_type\fR would.
-.Sp
-The same values for \fB\-mcpu=\fR\fIcpu_type\fR can be used for
-\&\fB\-mtune=\fR\fIcpu_type\fR, but the only useful values are those
-that select a particular \s-1CPU\s0 implementation. Those are \fBcypress\fR,
-\&\fBsupersparc\fR, \fBhypersparc\fR, \fBleon\fR, \fBf930\fR, \fBf934\fR,
-\&\fBsparclite86x\fR, \fBtsc701\fR, \fBultrasparc\fR, \fBultrasparc3\fR,
-\&\fBniagara\fR, and \fBniagara2\fR.
-.IP "\fB\-mv8plus\fR" 4
-.IX Item "-mv8plus"
-.PD 0
-.IP "\fB\-mno\-v8plus\fR" 4
-.IX Item "-mno-v8plus"
-.PD
-With \fB\-mv8plus\fR, \s-1GCC\s0 generates code for the \s-1SPARC\-V8+\s0 \s-1ABI\s0. The
-difference from the V8 \s-1ABI\s0 is that the global and out registers are
-considered 64\-bit wide. This is enabled by default on Solaris in 32\-bit
-mode for all \s-1SPARC\-V9\s0 processors.
-.IP "\fB\-mvis\fR" 4
-.IX Item "-mvis"
-.PD 0
-.IP "\fB\-mno\-vis\fR" 4
-.IX Item "-mno-vis"
-.PD
-With \fB\-mvis\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
-Visual Instruction Set extensions. The default is \fB\-mno\-vis\fR.
-.IP "\fB\-mfix\-at697f\fR" 4
-.IX Item "-mfix-at697f"
-Enable the documented workaround for the single erratum of the Atmel \s-1AT697F\s0
-processor (which corresponds to erratum #13 of the \s-1AT697E\s0 processor).
-.PP
-These \fB\-m\fR options are supported in addition to the above
-on \s-1SPARC\-V9\s0 processors in 64\-bit environments:
-.IP "\fB\-mlittle\-endian\fR" 4
-.IX Item "-mlittle-endian"
-Generate code for a processor running in little-endian mode. It is only
-available for a few configurations and most notably not on Solaris and Linux.
-.IP "\fB\-m32\fR" 4
-.IX Item "-m32"
-.PD 0
-.IP "\fB\-m64\fR" 4
-.IX Item "-m64"
-.PD
-Generate code for a 32\-bit or 64\-bit environment.
-The 32\-bit environment sets int, long and pointer to 32 bits.
-The 64\-bit environment sets int to 32 bits and long and pointer
-to 64 bits.
-.IP "\fB\-mcmodel=medlow\fR" 4
-.IX Item "-mcmodel=medlow"
-Generate code for the Medium/Low code model: 64\-bit addresses, programs
-must be linked in the low 32 bits of memory. Programs can be statically
-or dynamically linked.
-.IP "\fB\-mcmodel=medmid\fR" 4
-.IX Item "-mcmodel=medmid"
-Generate code for the Medium/Middle code model: 64\-bit addresses, programs
-must be linked in the low 44 bits of memory, the text and data segments must
-be less than 2GB in size and the data segment must be located within 2GB of
-the text segment.
-.IP "\fB\-mcmodel=medany\fR" 4
-.IX Item "-mcmodel=medany"
-Generate code for the Medium/Anywhere code model: 64\-bit addresses, programs
-may be linked anywhere in memory, the text and data segments must be less
-than 2GB in size and the data segment must be located within 2GB of the
-text segment.
-.IP "\fB\-mcmodel=embmedany\fR" 4
-.IX Item "-mcmodel=embmedany"
-Generate code for the Medium/Anywhere code model for embedded systems:
-64\-bit addresses, the text and data segments must be less than 2GB in
-size, both starting anywhere in memory (determined at link time). The
-global register \f(CW%g4\fR points to the base of the data segment. Programs
-are statically linked and \s-1PIC\s0 is not supported.
-.IP "\fB\-mstack\-bias\fR" 4
-.IX Item "-mstack-bias"
-.PD 0
-.IP "\fB\-mno\-stack\-bias\fR" 4
-.IX Item "-mno-stack-bias"
-.PD
-With \fB\-mstack\-bias\fR, \s-1GCC\s0 assumes that the stack pointer, and
-frame pointer if present, are offset by \-2047 which must be added back
-when making stack frame references. This is the default in 64\-bit mode.
-Otherwise, assume no such offset is present.
-.PP
-\fI\s-1SPU\s0 Options\fR
-.IX Subsection "SPU Options"
-.PP
-These \fB\-m\fR options are supported on the \s-1SPU:\s0
-.IP "\fB\-mwarn\-reloc\fR" 4
-.IX Item "-mwarn-reloc"
-.PD 0
-.IP "\fB\-merror\-reloc\fR" 4
-.IX Item "-merror-reloc"
-.PD
-The loader for \s-1SPU\s0 does not handle dynamic relocations. By default, \s-1GCC\s0
-will give an error when it generates code that requires a dynamic
-relocation. \fB\-mno\-error\-reloc\fR disables the error,
-\&\fB\-mwarn\-reloc\fR will generate a warning instead.
-.IP "\fB\-msafe\-dma\fR" 4
-.IX Item "-msafe-dma"
-.PD 0
-.IP "\fB\-munsafe\-dma\fR" 4
-.IX Item "-munsafe-dma"
-.PD
-Instructions which initiate or test completion of \s-1DMA\s0 must not be
-reordered with respect to loads and stores of the memory which is being
-accessed. Users typically address this problem using the volatile
-keyword, but that can lead to inefficient code in places where the
-memory is known to not change. Rather than mark the memory as volatile
-we treat the \s-1DMA\s0 instructions as potentially effecting all memory. With
-\&\fB\-munsafe\-dma\fR users must use the volatile keyword to protect
-memory accesses.
-.IP "\fB\-mbranch\-hints\fR" 4
-.IX Item "-mbranch-hints"
-By default, \s-1GCC\s0 will generate a branch hint instruction to avoid
-pipeline stalls for always taken or probably taken branches. A hint
-will not be generated closer than 8 instructions away from its branch.
-There is little reason to disable them, except for debugging purposes,
-or to make an object a little bit smaller.
-.IP "\fB\-msmall\-mem\fR" 4
-.IX Item "-msmall-mem"
-.PD 0
-.IP "\fB\-mlarge\-mem\fR" 4
-.IX Item "-mlarge-mem"
-.PD
-By default, \s-1GCC\s0 generates code assuming that addresses are never larger
-than 18 bits. With \fB\-mlarge\-mem\fR code is generated that assumes
-a full 32 bit address.
-.IP "\fB\-mstdmain\fR" 4
-.IX Item "-mstdmain"
-By default, \s-1GCC\s0 links against startup code that assumes the SPU-style
-main function interface (which has an unconventional parameter list).
-With \fB\-mstdmain\fR, \s-1GCC\s0 will link your program against startup
-code that assumes a C99\-style interface to \f(CW\*(C`main\*(C'\fR, including a
-local copy of \f(CW\*(C`argv\*(C'\fR strings.
-.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
-.IX Item "-mfixed-range=register-range"
-Generate code treating the given register range as fixed registers.
-A fixed register is one that the register allocator can not use. This is
-useful when compiling kernel code. A register range is specified as
-two registers separated by a dash. Multiple register ranges can be
-specified separated by a comma.
-.IP "\fB\-mea32\fR" 4
-.IX Item "-mea32"
-.PD 0
-.IP "\fB\-mea64\fR" 4
-.IX Item "-mea64"
-.PD
-Compile code assuming that pointers to the \s-1PPU\s0 address space accessed
-via the \f(CW\*(C`_\|_ea\*(C'\fR named address space qualifier are either 32 or 64
-bits wide. The default is 32 bits. As this is an \s-1ABI\s0 changing option,
-all object code in an executable must be compiled with the same setting.
-.IP "\fB\-maddress\-space\-conversion\fR" 4
-.IX Item "-maddress-space-conversion"
-.PD 0
-.IP "\fB\-mno\-address\-space\-conversion\fR" 4
-.IX Item "-mno-address-space-conversion"
-.PD
-Allow/disallow treating the \f(CW\*(C`_\|_ea\*(C'\fR address space as superset
-of the generic address space. This enables explicit type casts
-between \f(CW\*(C`_\|_ea\*(C'\fR and generic pointer as well as implicit
-conversions of generic pointers to \f(CW\*(C`_\|_ea\*(C'\fR pointers. The
-default is to allow address space pointer conversions.
-.IP "\fB\-mcache\-size=\fR\fIcache-size\fR" 4
-.IX Item "-mcache-size=cache-size"
-This option controls the version of libgcc that the compiler links to an
-executable and selects a software-managed cache for accessing variables
-in the \f(CW\*(C`_\|_ea\*(C'\fR address space with a particular cache size. Possible
-options for \fIcache-size\fR are \fB8\fR, \fB16\fR, \fB32\fR, \fB64\fR
-and \fB128\fR. The default cache size is 64KB.
-.IP "\fB\-matomic\-updates\fR" 4
-.IX Item "-matomic-updates"
-.PD 0
-.IP "\fB\-mno\-atomic\-updates\fR" 4
-.IX Item "-mno-atomic-updates"
-.PD
-This option controls the version of libgcc that the compiler links to an
-executable and selects whether atomic updates to the software-managed
-cache of PPU-side variables are used. If you use atomic updates, changes
-to a \s-1PPU\s0 variable from \s-1SPU\s0 code using the \f(CW\*(C`_\|_ea\*(C'\fR named address space
-qualifier will not interfere with changes to other \s-1PPU\s0 variables residing
-in the same cache line from \s-1PPU\s0 code. If you do not use atomic updates,
-such interference may occur; however, writing back cache lines will be
-more efficient. The default behavior is to use atomic updates.
-.IP "\fB\-mdual\-nops\fR" 4
-.IX Item "-mdual-nops"
-.PD 0
-.IP "\fB\-mdual\-nops=\fR\fIn\fR" 4
-.IX Item "-mdual-nops=n"
-.PD
-By default, \s-1GCC\s0 will insert nops to increase dual issue when it expects
-it to increase performance. \fIn\fR can be a value from 0 to 10. A
-smaller \fIn\fR will insert fewer nops. 10 is the default, 0 is the
-same as \fB\-mno\-dual\-nops\fR. Disabled with \fB\-Os\fR.
-.IP "\fB\-mhint\-max\-nops=\fR\fIn\fR" 4
-.IX Item "-mhint-max-nops=n"
-Maximum number of nops to insert for a branch hint. A branch hint must
-be at least 8 instructions away from the branch it is effecting. \s-1GCC\s0
-will insert up to \fIn\fR nops to enforce this, otherwise it will not
-generate the branch hint.
-.IP "\fB\-mhint\-max\-distance=\fR\fIn\fR" 4
-.IX Item "-mhint-max-distance=n"
-The encoding of the branch hint instruction limits the hint to be within
-256 instructions of the branch it is effecting. By default, \s-1GCC\s0 makes
-sure it is within 125.
-.IP "\fB\-msafe\-hints\fR" 4
-.IX Item "-msafe-hints"
-Work around a hardware bug which causes the \s-1SPU\s0 to stall indefinitely.
-By default, \s-1GCC\s0 will insert the \f(CW\*(C`hbrp\*(C'\fR instruction to make sure
-this stall won't happen.
-.PP
-\fIOptions for System V\fR
-.IX Subsection "Options for System V"
-.PP
-These additional options are available on System V Release 4 for
-compatibility with other compilers on those systems:
-.IP "\fB\-G\fR" 4
-.IX Item "-G"
-Create a shared object.
-It is recommended that \fB\-symbolic\fR or \fB\-shared\fR be used instead.
-.IP "\fB\-Qy\fR" 4
-.IX Item "-Qy"
-Identify the versions of each tool used by the compiler, in a
-\&\f(CW\*(C`.ident\*(C'\fR assembler directive in the output.
-.IP "\fB\-Qn\fR" 4
-.IX Item "-Qn"
-Refrain from adding \f(CW\*(C`.ident\*(C'\fR directives to the output file (this is
-the default).
-.IP "\fB\-YP,\fR\fIdirs\fR" 4
-.IX Item "-YP,dirs"
-Search the directories \fIdirs\fR, and no others, for libraries
-specified with \fB\-l\fR.
-.IP "\fB\-Ym,\fR\fIdir\fR" 4
-.IX Item "-Ym,dir"
-Look in the directory \fIdir\fR to find the M4 preprocessor.
-The assembler uses this option.
-.PP
-\fIV850 Options\fR
-.IX Subsection "V850 Options"
-.PP
-These \fB\-m\fR options are defined for V850 implementations:
-.IP "\fB\-mlong\-calls\fR" 4
-.IX Item "-mlong-calls"
-.PD 0
-.IP "\fB\-mno\-long\-calls\fR" 4
-.IX Item "-mno-long-calls"
-.PD
-Treat all calls as being far away (near). If calls are assumed to be
-far away, the compiler will always load the functions address up into a
-register, and call indirect through the pointer.
-.IP "\fB\-mno\-ep\fR" 4
-.IX Item "-mno-ep"
-.PD 0
-.IP "\fB\-mep\fR" 4
-.IX Item "-mep"
-.PD
-Do not optimize (do optimize) basic blocks that use the same index
-pointer 4 or more times to copy pointer into the \f(CW\*(C`ep\*(C'\fR register, and
-use the shorter \f(CW\*(C`sld\*(C'\fR and \f(CW\*(C`sst\*(C'\fR instructions. The \fB\-mep\fR
-option is on by default if you optimize.
-.IP "\fB\-mno\-prolog\-function\fR" 4
-.IX Item "-mno-prolog-function"
-.PD 0
-.IP "\fB\-mprolog\-function\fR" 4
-.IX Item "-mprolog-function"
-.PD
-Do not use (do use) external functions to save and restore registers
-at the prologue and epilogue of a function. The external functions
-are slower, but use less code space if more than one function saves
-the same number of registers. The \fB\-mprolog\-function\fR option
-is on by default if you optimize.
-.IP "\fB\-mspace\fR" 4
-.IX Item "-mspace"
-Try to make the code as small as possible. At present, this just turns
-on the \fB\-mep\fR and \fB\-mprolog\-function\fR options.
-.IP "\fB\-mtda=\fR\fIn\fR" 4
-.IX Item "-mtda=n"
-Put static or global variables whose size is \fIn\fR bytes or less into
-the tiny data area that register \f(CW\*(C`ep\*(C'\fR points to. The tiny data
-area can hold up to 256 bytes in total (128 bytes for byte references).
-.IP "\fB\-msda=\fR\fIn\fR" 4
-.IX Item "-msda=n"
-Put static or global variables whose size is \fIn\fR bytes or less into
-the small data area that register \f(CW\*(C`gp\*(C'\fR points to. The small data
-area can hold up to 64 kilobytes.
-.IP "\fB\-mzda=\fR\fIn\fR" 4
-.IX Item "-mzda=n"
-Put static or global variables whose size is \fIn\fR bytes or less into
-the first 32 kilobytes of memory.
-.IP "\fB\-mv850\fR" 4
-.IX Item "-mv850"
-Specify that the target processor is the V850.
-.IP "\fB\-mbig\-switch\fR" 4
-.IX Item "-mbig-switch"
-Generate code suitable for big switch tables. Use this option only if
-the assembler/linker complain about out of range branches within a switch
-table.
-.IP "\fB\-mapp\-regs\fR" 4
-.IX Item "-mapp-regs"
-This option will cause r2 and r5 to be used in the code generated by
-the compiler. This setting is the default.
-.IP "\fB\-mno\-app\-regs\fR" 4
-.IX Item "-mno-app-regs"
-This option will cause r2 and r5 to be treated as fixed registers.
-.IP "\fB\-mv850e2v3\fR" 4
-.IX Item "-mv850e2v3"
-Specify that the target processor is the V850E2V3. The preprocessor
-constants \fB_\|_v850e2v3_\|_\fR will be defined if
-this option is used.
-.IP "\fB\-mv850e2\fR" 4
-.IX Item "-mv850e2"
-Specify that the target processor is the V850E2. The preprocessor
-constants \fB_\|_v850e2_\|_\fR will be defined if
-.IP "\fB\-mv850e1\fR" 4
-.IX Item "-mv850e1"
-Specify that the target processor is the V850E1. The preprocessor
-constants \fB_\|_v850e1_\|_\fR and \fB_\|_v850e_\|_\fR will be defined if
-.IP "\fB\-mv850es\fR" 4
-.IX Item "-mv850es"
-Specify that the target processor is the V850ES. This is an alias for
-the \fB\-mv850e1\fR option.
-.IP "\fB\-mv850e\fR" 4
-.IX Item "-mv850e"
-Specify that the target processor is the V850E. The preprocessor
-constant \fB_\|_v850e_\|_\fR will be defined if this option is used.
-.Sp
-If neither \fB\-mv850\fR nor \fB\-mv850e\fR nor \fB\-mv850e1\fR
-nor \fB\-mv850e2\fR nor \fB\-mv850e2v3\fR
-are defined then a default target processor will be chosen and the
-relevant \fB_\|_v850*_\|_\fR preprocessor constant will be defined.
-.Sp
-The preprocessor constants \fB_\|_v850\fR and \fB_\|_v851_\|_\fR are always
-defined, regardless of which processor variant is the target.
-.IP "\fB\-mdisable\-callt\fR" 4
-.IX Item "-mdisable-callt"
-This option will suppress generation of the \s-1CALLT\s0 instruction for the
-v850e, v850e1, v850e2 and v850e2v3 flavors of the v850 architecture. The default is
-\&\fB\-mno\-disable\-callt\fR which allows the \s-1CALLT\s0 instruction to be used.
-.PP
-\fI\s-1VAX\s0 Options\fR
-.IX Subsection "VAX Options"
-.PP
-These \fB\-m\fR options are defined for the \s-1VAX:\s0
-.IP "\fB\-munix\fR" 4
-.IX Item "-munix"
-Do not output certain jump instructions (\f(CW\*(C`aobleq\*(C'\fR and so on)
-that the Unix assembler for the \s-1VAX\s0 cannot handle across long
-ranges.
-.IP "\fB\-mgnu\fR" 4
-.IX Item "-mgnu"
-Do output those jump instructions, on the assumption that you
-will assemble with the \s-1GNU\s0 assembler.
-.IP "\fB\-mg\fR" 4
-.IX Item "-mg"
-Output code for g\-format floating point numbers instead of d\-format.
-.PP
-\fIVxWorks Options\fR
-.IX Subsection "VxWorks Options"
-.PP
-The options in this section are defined for all VxWorks targets.
-Options specific to the target hardware are listed with the other
-options for that target.
-.IP "\fB\-mrtp\fR" 4
-.IX Item "-mrtp"
-\&\s-1GCC\s0 can generate code for both VxWorks kernels and real time processes
-(RTPs). This option switches from the former to the latter. It also
-defines the preprocessor macro \f(CW\*(C`_\|_RTP_\|_\*(C'\fR.
-.IP "\fB\-non\-static\fR" 4
-.IX Item "-non-static"
-Link an \s-1RTP\s0 executable against shared libraries rather than static
-libraries. The options \fB\-static\fR and \fB\-shared\fR can
-also be used for RTPs; \fB\-static\fR
-is the default.
-.IP "\fB\-Bstatic\fR" 4
-.IX Item "-Bstatic"
-.PD 0
-.IP "\fB\-Bdynamic\fR" 4
-.IX Item "-Bdynamic"
-.PD
-These options are passed down to the linker. They are defined for
-compatibility with Diab.
-.IP "\fB\-Xbind\-lazy\fR" 4
-.IX Item "-Xbind-lazy"
-Enable lazy binding of function calls. This option is equivalent to
-\&\fB\-Wl,\-z,now\fR and is defined for compatibility with Diab.
-.IP "\fB\-Xbind\-now\fR" 4
-.IX Item "-Xbind-now"
-Disable lazy binding of function calls. This option is the default and
-is defined for compatibility with Diab.
-.PP
-\fIx86\-64 Options\fR
-.IX Subsection "x86-64 Options"
-.PP
-These are listed under
-.PP
-\fIXstormy16 Options\fR
-.IX Subsection "Xstormy16 Options"
-.PP
-These options are defined for Xstormy16:
-.IP "\fB\-msim\fR" 4
-.IX Item "-msim"
-Choose startup files and linker script suitable for the simulator.
-.PP
-\fIXtensa Options\fR
-.IX Subsection "Xtensa Options"
-.PP
-These options are supported for Xtensa targets:
-.IP "\fB\-mconst16\fR" 4
-.IX Item "-mconst16"
-.PD 0
-.IP "\fB\-mno\-const16\fR" 4
-.IX Item "-mno-const16"
-.PD
-Enable or disable use of \f(CW\*(C`CONST16\*(C'\fR instructions for loading
-constant values. The \f(CW\*(C`CONST16\*(C'\fR instruction is currently not a
-standard option from Tensilica. When enabled, \f(CW\*(C`CONST16\*(C'\fR
-instructions are always used in place of the standard \f(CW\*(C`L32R\*(C'\fR
-instructions. The use of \f(CW\*(C`CONST16\*(C'\fR is enabled by default only if
-the \f(CW\*(C`L32R\*(C'\fR instruction is not available.
-.IP "\fB\-mfused\-madd\fR" 4
-.IX Item "-mfused-madd"
-.PD 0
-.IP "\fB\-mno\-fused\-madd\fR" 4
-.IX Item "-mno-fused-madd"
-.PD
-Enable or disable use of fused multiply/add and multiply/subtract
-instructions in the floating-point option. This has no effect if the
-floating-point option is not also enabled. Disabling fused multiply/add
-and multiply/subtract instructions forces the compiler to use separate
-instructions for the multiply and add/subtract operations. This may be
-desirable in some cases where strict \s-1IEEE\s0 754\-compliant results are
-required: the fused multiply add/subtract instructions do not round the
-intermediate result, thereby producing results with \fImore\fR bits of
-precision than specified by the \s-1IEEE\s0 standard. Disabling fused multiply
-add/subtract instructions also ensures that the program output is not
-sensitive to the compiler's ability to combine multiply and add/subtract
-operations.
-.IP "\fB\-mserialize\-volatile\fR" 4
-.IX Item "-mserialize-volatile"
-.PD 0
-.IP "\fB\-mno\-serialize\-volatile\fR" 4
-.IX Item "-mno-serialize-volatile"
-.PD
-When this option is enabled, \s-1GCC\s0 inserts \f(CW\*(C`MEMW\*(C'\fR instructions before
-\&\f(CW\*(C`volatile\*(C'\fR memory references to guarantee sequential consistency.
-The default is \fB\-mserialize\-volatile\fR. Use
-\&\fB\-mno\-serialize\-volatile\fR to omit the \f(CW\*(C`MEMW\*(C'\fR instructions.
-.IP "\fB\-mforce\-no\-pic\fR" 4
-.IX Item "-mforce-no-pic"
-For targets, like GNU/Linux, where all user-mode Xtensa code must be
-position-independent code (\s-1PIC\s0), this option disables \s-1PIC\s0 for compiling
-kernel code.
-.IP "\fB\-mtext\-section\-literals\fR" 4
-.IX Item "-mtext-section-literals"
-.PD 0
-.IP "\fB\-mno\-text\-section\-literals\fR" 4
-.IX Item "-mno-text-section-literals"
-.PD
-Control the treatment of literal pools. The default is
-\&\fB\-mno\-text\-section\-literals\fR, which places literals in a separate
-section in the output file. This allows the literal pool to be placed
-in a data \s-1RAM/ROM\s0, and it also allows the linker to combine literal
-pools from separate object files to remove redundant literals and
-improve code size. With \fB\-mtext\-section\-literals\fR, the literals
-are interspersed in the text section in order to keep them as close as
-possible to their references. This may be necessary for large assembly
-files.
-.IP "\fB\-mtarget\-align\fR" 4
-.IX Item "-mtarget-align"
-.PD 0
-.IP "\fB\-mno\-target\-align\fR" 4
-.IX Item "-mno-target-align"
-.PD
-When this option is enabled, \s-1GCC\s0 instructs the assembler to
-automatically align instructions to reduce branch penalties at the
-expense of some code density. The assembler attempts to widen density
-instructions to align branch targets and the instructions following call
-instructions. If there are not enough preceding safe density
-instructions to align a target, no widening will be performed. The
-default is \fB\-mtarget\-align\fR. These options do not affect the
-treatment of auto-aligned instructions like \f(CW\*(C`LOOP\*(C'\fR, which the
-assembler will always align, either by widening density instructions or
-by inserting no-op instructions.
-.IP "\fB\-mlongcalls\fR" 4
-.IX Item "-mlongcalls"
-.PD 0
-.IP "\fB\-mno\-longcalls\fR" 4
-.IX Item "-mno-longcalls"
-.PD
-When this option is enabled, \s-1GCC\s0 instructs the assembler to translate
-direct calls to indirect calls unless it can determine that the target
-of a direct call is in the range allowed by the call instruction. This
-translation typically occurs for calls to functions in other source
-files. Specifically, the assembler translates a direct \f(CW\*(C`CALL\*(C'\fR
-instruction into an \f(CW\*(C`L32R\*(C'\fR followed by a \f(CW\*(C`CALLX\*(C'\fR instruction.
-The default is \fB\-mno\-longcalls\fR. This option should be used in
-programs where the call target can potentially be out of range. This
-option is implemented in the assembler, not the compiler, so the
-assembly code generated by \s-1GCC\s0 will still show direct call
-instructions\-\-\-look at the disassembled object code to see the actual
-instructions. Note that the assembler will use an indirect call for
-every cross-file call, not just those that really will be out of range.
-.PP
-\fIzSeries Options\fR
-.IX Subsection "zSeries Options"
-.PP
-These are listed under
-.SS "Options for Code Generation Conventions"
-.IX Subsection "Options for Code Generation Conventions"
-These machine-independent options control the interface conventions
-used in code generation.
-.PP
-Most of them have both positive and negative forms; the negative form
-of \fB\-ffoo\fR would be \fB\-fno\-foo\fR. In the table below, only
-one of the forms is listed\-\-\-the one which is not the default. You
-can figure out the other form by either removing \fBno\-\fR or adding
-it.
-.IP "\fB\-fbounds\-check\fR" 4
-.IX Item "-fbounds-check"
-For front-ends that support it, generate additional code to check that
-indices used to access arrays are within the declared range. This is
-currently only supported by the Java and Fortran front-ends, where
-this option defaults to true and false respectively.
-.IP "\fB\-ftrapv\fR" 4
-.IX Item "-ftrapv"
-This option generates traps for signed overflow on addition, subtraction,
-multiplication operations.
-.IP "\fB\-fwrapv\fR" 4
-.IX Item "-fwrapv"
-This option instructs the compiler to assume that signed arithmetic
-overflow of addition, subtraction and multiplication wraps around
-using twos-complement representation. This flag enables some optimizations
-and disables others. This option is enabled by default for the Java
-front-end, as required by the Java language specification.
-.IP "\fB\-fexceptions\fR" 4
-.IX Item "-fexceptions"
-Enable exception handling. Generates extra code needed to propagate
-exceptions. For some targets, this implies \s-1GCC\s0 will generate frame
-unwind information for all functions, which can produce significant data
-size overhead, although it does not affect execution. If you do not
-specify this option, \s-1GCC\s0 will enable it by default for languages like
-\&\*(C+ which normally require exception handling, and disable it for
-languages like C that do not normally require it. However, you may need
-to enable this option when compiling C code that needs to interoperate
-properly with exception handlers written in \*(C+. You may also wish to
-disable this option if you are compiling older \*(C+ programs that don't
-use exception handling.
-.IP "\fB\-fnon\-call\-exceptions\fR" 4
-.IX Item "-fnon-call-exceptions"
-Generate code that allows trapping instructions to throw exceptions.
-Note that this requires platform-specific runtime support that does
-not exist everywhere. Moreover, it only allows \fItrapping\fR
-instructions to throw exceptions, i.e. memory references or floating
-point instructions. It does not allow exceptions to be thrown from
-arbitrary signal handlers such as \f(CW\*(C`SIGALRM\*(C'\fR.
-.IP "\fB\-funwind\-tables\fR" 4
-.IX Item "-funwind-tables"
-Similar to \fB\-fexceptions\fR, except that it will just generate any needed
-static data, but will not affect the generated code in any other way.
-You will normally not enable this option; instead, a language processor
-that needs this handling would enable it on your behalf.
-.IP "\fB\-fasynchronous\-unwind\-tables\fR" 4
-.IX Item "-fasynchronous-unwind-tables"
-Generate unwind table in dwarf2 format, if supported by target machine. The
-table is exact at each instruction boundary, so it can be used for stack
-unwinding from asynchronous events (such as debugger or garbage collector).
-.IP "\fB\-fpcc\-struct\-return\fR" 4
-.IX Item "-fpcc-struct-return"
-Return \*(L"short\*(R" \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in memory like
-longer ones, rather than in registers. This convention is less
-efficient, but it has the advantage of allowing intercallability between
-GCC-compiled files and files compiled with other compilers, particularly
-the Portable C Compiler (pcc).
-.Sp
-The precise convention for returning structures in memory depends
-on the target configuration macros.
-.Sp
-Short structures and unions are those whose size and alignment match
-that of some integer type.
-.Sp
-\&\fBWarning:\fR code compiled with the \fB\-fpcc\-struct\-return\fR
-switch is not binary compatible with code compiled with the
-\&\fB\-freg\-struct\-return\fR switch.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-freg\-struct\-return\fR" 4
-.IX Item "-freg-struct-return"
-Return \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in registers when possible.
-This is more efficient for small structures than
-\&\fB\-fpcc\-struct\-return\fR.
-.Sp
-If you specify neither \fB\-fpcc\-struct\-return\fR nor
-\&\fB\-freg\-struct\-return\fR, \s-1GCC\s0 defaults to whichever convention is
-standard for the target. If there is no standard convention, \s-1GCC\s0
-defaults to \fB\-fpcc\-struct\-return\fR, except on targets where \s-1GCC\s0 is
-the principal compiler. In those cases, we can choose the standard, and
-we chose the more efficient register return alternative.
-.Sp
-\&\fBWarning:\fR code compiled with the \fB\-freg\-struct\-return\fR
-switch is not binary compatible with code compiled with the
-\&\fB\-fpcc\-struct\-return\fR switch.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-fshort\-enums\fR" 4
-.IX Item "-fshort-enums"
-Allocate to an \f(CW\*(C`enum\*(C'\fR type only as many bytes as it needs for the
-declared range of possible values. Specifically, the \f(CW\*(C`enum\*(C'\fR type
-will be equivalent to the smallest integer type which has enough room.
-.Sp
-\&\fBWarning:\fR the \fB\-fshort\-enums\fR switch causes \s-1GCC\s0 to generate
-code that is not binary compatible with code generated without that switch.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-fshort\-double\fR" 4
-.IX Item "-fshort-double"
-Use the same size for \f(CW\*(C`double\*(C'\fR as for \f(CW\*(C`float\*(C'\fR.
-.Sp
-\&\fBWarning:\fR the \fB\-fshort\-double\fR switch causes \s-1GCC\s0 to generate
-code that is not binary compatible with code generated without that switch.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-fshort\-wchar\fR" 4
-.IX Item "-fshort-wchar"
-Override the underlying type for \fBwchar_t\fR to be \fBshort
-unsigned int\fR instead of the default for the target. This option is
-useful for building programs to run under \s-1WINE\s0.
-.Sp
-\&\fBWarning:\fR the \fB\-fshort\-wchar\fR switch causes \s-1GCC\s0 to generate
-code that is not binary compatible with code generated without that switch.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-fno\-common\fR" 4
-.IX Item "-fno-common"
-In C code, controls the placement of uninitialized global variables.
-Unix C compilers have traditionally permitted multiple definitions of
-such variables in different compilation units by placing the variables
-in a common block.
-This is the behavior specified by \fB\-fcommon\fR, and is the default
-for \s-1GCC\s0 on most targets.
-On the other hand, this behavior is not required by \s-1ISO\s0 C, and on some
-targets may carry a speed or code size penalty on variable references.
-The \fB\-fno\-common\fR option specifies that the compiler should place
-uninitialized global variables in the data section of the object file,
-rather than generating them as common blocks.
-This has the effect that if the same variable is declared
-(without \f(CW\*(C`extern\*(C'\fR) in two different compilations,
-you will get a multiple-definition error when you link them.
-In this case, you must compile with \fB\-fcommon\fR instead.
-Compiling with \fB\-fno\-common\fR is useful on targets for which
-it provides better performance, or if you wish to verify that the
-program will work on other systems which always treat uninitialized
-variable declarations this way.
-.IP "\fB\-fno\-ident\fR" 4
-.IX Item "-fno-ident"
-Ignore the \fB#ident\fR directive.
-.IP "\fB\-finhibit\-size\-directive\fR" 4
-.IX Item "-finhibit-size-directive"
-Don't output a \f(CW\*(C`.size\*(C'\fR assembler directive, or anything else that
-would cause trouble if the function is split in the middle, and the
-two halves are placed at locations far apart in memory. This option is
-used when compiling \fIcrtstuff.c\fR; you should not need to use it
-for anything else.
-.IP "\fB\-fverbose\-asm\fR" 4
-.IX Item "-fverbose-asm"
-Put extra commentary information in the generated assembly code to
-make it more readable. This option is generally only of use to those
-who actually need to read the generated assembly code (perhaps while
-debugging the compiler itself).
-.Sp
-\&\fB\-fno\-verbose\-asm\fR, the default, causes the
-extra information to be omitted and is useful when comparing two assembler
-files.
-.IP "\fB\-frecord\-gcc\-switches\fR" 4
-.IX Item "-frecord-gcc-switches"
-This switch causes the command line that was used to invoke the
-compiler to be recorded into the object file that is being created.
-This switch is only implemented on some targets and the exact format
-of the recording is target and binary file format dependent, but it
-usually takes the form of a section containing \s-1ASCII\s0 text. This
-switch is related to the \fB\-fverbose\-asm\fR switch, but that
-switch only records information in the assembler output file as
-comments, so it never reaches the object file.
-.IP "\fB\-fpic\fR" 4
-.IX Item "-fpic"
-Generate position-independent code (\s-1PIC\s0) suitable for use in a shared
-library, if supported for the target machine. Such code accesses all
-constant addresses through a global offset table (\s-1GOT\s0). The dynamic
-loader resolves the \s-1GOT\s0 entries when the program starts (the dynamic
-loader is not part of \s-1GCC\s0; it is part of the operating system). If
-the \s-1GOT\s0 size for the linked executable exceeds a machine-specific
-maximum size, you get an error message from the linker indicating that
-\&\fB\-fpic\fR does not work; in that case, recompile with \fB\-fPIC\fR
-instead. (These maximums are 8k on the \s-1SPARC\s0 and 32k
-on the m68k and \s-1RS/6000\s0. The 386 has no such limit.)
-.Sp
-Position-independent code requires special support, and therefore works
-only on certain machines. For the 386, \s-1GCC\s0 supports \s-1PIC\s0 for System V
-but not for the Sun 386i. Code generated for the \s-1IBM\s0 \s-1RS/6000\s0 is always
-position-independent.
-.Sp
-When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
-are defined to 1.
-.IP "\fB\-fPIC\fR" 4
-.IX Item "-fPIC"
-If supported for the target machine, emit position-independent code,
-suitable for dynamic linking and avoiding any limit on the size of the
-global offset table. This option makes a difference on the m68k,
-PowerPC and \s-1SPARC\s0.
-.Sp
-Position-independent code requires special support, and therefore works
-only on certain machines.
-.Sp
-When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
-are defined to 2.
-.IP "\fB\-fpie\fR" 4
-.IX Item "-fpie"
-.PD 0
-.IP "\fB\-fPIE\fR" 4
-.IX Item "-fPIE"
-.PD
-These options are similar to \fB\-fpic\fR and \fB\-fPIC\fR, but
-generated position independent code can be only linked into executables.
-Usually these options are used when \fB\-pie\fR \s-1GCC\s0 option will be
-used during linking.
-.Sp
-\&\fB\-fpie\fR and \fB\-fPIE\fR both define the macros
-\&\f(CW\*(C`_\|_pie_\|_\*(C'\fR and \f(CW\*(C`_\|_PIE_\|_\*(C'\fR. The macros have the value 1
-for \fB\-fpie\fR and 2 for \fB\-fPIE\fR.
-.IP "\fB\-fno\-jump\-tables\fR" 4
-.IX Item "-fno-jump-tables"
-Do not use jump tables for switch statements even where it would be
-more efficient than other code generation strategies. This option is
-of use in conjunction with \fB\-fpic\fR or \fB\-fPIC\fR for
-building code which forms part of a dynamic linker and cannot
-reference the address of a jump table. On some targets, jump tables
-do not require a \s-1GOT\s0 and this option is not needed.
-.IP "\fB\-ffixed\-\fR\fIreg\fR" 4
-.IX Item "-ffixed-reg"
-Treat the register named \fIreg\fR as a fixed register; generated code
-should never refer to it (except perhaps as a stack pointer, frame
-pointer or in some other fixed role).
-.Sp
-\&\fIreg\fR must be the name of a register. The register names accepted
-are machine-specific and are defined in the \f(CW\*(C`REGISTER_NAMES\*(C'\fR
-macro in the machine description macro file.
-.Sp
-This flag does not have a negative form, because it specifies a
-three-way choice.
-.IP "\fB\-fcall\-used\-\fR\fIreg\fR" 4
-.IX Item "-fcall-used-reg"
-Treat the register named \fIreg\fR as an allocable register that is
-clobbered by function calls. It may be allocated for temporaries or
-variables that do not live across a call. Functions compiled this way
-will not save and restore the register \fIreg\fR.
-.Sp
-It is an error to used this flag with the frame pointer or stack pointer.
-Use of this flag for other registers that have fixed pervasive roles in
-the machine's execution model will produce disastrous results.
-.Sp
-This flag does not have a negative form, because it specifies a
-three-way choice.
-.IP "\fB\-fcall\-saved\-\fR\fIreg\fR" 4
-.IX Item "-fcall-saved-reg"
-Treat the register named \fIreg\fR as an allocable register saved by
-functions. It may be allocated even for temporaries or variables that
-live across a call. Functions compiled this way will save and restore
-the register \fIreg\fR if they use it.
-.Sp
-It is an error to used this flag with the frame pointer or stack pointer.
-Use of this flag for other registers that have fixed pervasive roles in
-the machine's execution model will produce disastrous results.
-.Sp
-A different sort of disaster will result from the use of this flag for
-a register in which function values may be returned.
-.Sp
-This flag does not have a negative form, because it specifies a
-three-way choice.
-.IP "\fB\-fpack\-struct[=\fR\fIn\fR\fB]\fR" 4
-.IX Item "-fpack-struct[=n]"
-Without a value specified, pack all structure members together without
-holes. When a value is specified (which must be a small power of two), pack
-structure members according to this value, representing the maximum
-alignment (that is, objects with default alignment requirements larger than
-this will be output potentially unaligned at the next fitting location.
-.Sp
-\&\fBWarning:\fR the \fB\-fpack\-struct\fR switch causes \s-1GCC\s0 to generate
-code that is not binary compatible with code generated without that switch.
-Additionally, it makes the code suboptimal.
-Use it to conform to a non-default application binary interface.
-.IP "\fB\-finstrument\-functions\fR" 4
-.IX Item "-finstrument-functions"
-Generate instrumentation calls for entry and exit to functions. Just
-after function entry and just before function exit, the following
-profiling functions will be called with the address of the current
-function and its call site. (On some platforms,
-\&\f(CW\*(C`_\|_builtin_return_address\*(C'\fR does not work beyond the current
-function, so the call site information may not be available to the
-profiling functions otherwise.)
-.Sp
-.Vb 4
-\& void _\|_cyg_profile_func_enter (void *this_fn,
-\& void *call_site);
-\& void _\|_cyg_profile_func_exit (void *this_fn,
-\& void *call_site);
-.Ve
-.Sp
-The first argument is the address of the start of the current function,
-which may be looked up exactly in the symbol table.
-.Sp
-This instrumentation is also done for functions expanded inline in other
-functions. The profiling calls will indicate where, conceptually, the
-inline function is entered and exited. This means that addressable
-versions of such functions must be available. If all your uses of a
-function are expanded inline, this may mean an additional expansion of
-code size. If you use \fBextern inline\fR in your C code, an
-addressable version of such functions must be provided. (This is
-normally the case anyways, but if you get lucky and the optimizer always
-expands the functions inline, you might have gotten away without
-providing static copies.)
-.Sp
-A function may be given the attribute \f(CW\*(C`no_instrument_function\*(C'\fR, in
-which case this instrumentation will not be done. This can be used, for
-example, for the profiling functions listed above, high-priority
-interrupt routines, and any functions from which the profiling functions
-cannot safely be called (perhaps signal handlers, if the profiling
-routines generate output or allocate memory).
-.IP "\fB\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,...\fR" 4
-.IX Item "-finstrument-functions-exclude-file-list=file,file,..."
-Set the list of functions that are excluded from instrumentation (see
-the description of \f(CW\*(C`\-finstrument\-functions\*(C'\fR). If the file that
-contains a function definition matches with one of \fIfile\fR, then
-that function is not instrumented. The match is done on substrings:
-if the \fIfile\fR parameter is a substring of the file name, it is
-considered to be a match.
-.Sp
-For example:
-.Sp
-.Vb 1
-\& \-finstrument\-functions\-exclude\-file\-list=/bits/stl,include/sys
-.Ve
-.Sp
-will exclude any inline function defined in files whose pathnames
-contain \f(CW\*(C`/bits/stl\*(C'\fR or \f(CW\*(C`include/sys\*(C'\fR.
-.Sp
-If, for some reason, you want to include letter \f(CW\*(Aq,\*(Aq\fR in one of
-\&\fIsym\fR, write \f(CW\*(Aq,\*(Aq\fR. For example,
-\&\f(CW\*(C`\-finstrument\-functions\-exclude\-file\-list=\*(Aq,,tmp\*(Aq\*(C'\fR
-(note the single quote surrounding the option).
-.IP "\fB\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,...\fR" 4
-.IX Item "-finstrument-functions-exclude-function-list=sym,sym,..."
-This is similar to \f(CW\*(C`\-finstrument\-functions\-exclude\-file\-list\*(C'\fR,
-but this option sets the list of function names to be excluded from
-instrumentation. The function name to be matched is its user-visible
-name, such as \f(CW\*(C`vector<int> blah(const vector<int> &)\*(C'\fR, not the
-internal mangled name (e.g., \f(CW\*(C`_Z4blahRSt6vectorIiSaIiEE\*(C'\fR). The
-match is done on substrings: if the \fIsym\fR parameter is a substring
-of the function name, it is considered to be a match. For C99 and \*(C+
-extended identifiers, the function name must be given in \s-1UTF\-8\s0, not
-using universal character names.
-.IP "\fB\-fstack\-check\fR" 4
-.IX Item "-fstack-check"
-Generate code to verify that you do not go beyond the boundary of the
-stack. You should specify this flag if you are running in an
-environment with multiple threads, but only rarely need to specify it in
-a single-threaded environment since stack overflow is automatically
-detected on nearly all systems if there is only one stack.
-.Sp
-Note that this switch does not actually cause checking to be done; the
-operating system or the language runtime must do that. The switch causes
-generation of code to ensure that they see the stack being extended.
-.Sp
-You can additionally specify a string parameter: \f(CW\*(C`no\*(C'\fR means no
-checking, \f(CW\*(C`generic\*(C'\fR means force the use of old-style checking,
-\&\f(CW\*(C`specific\*(C'\fR means use the best checking method and is equivalent
-to bare \fB\-fstack\-check\fR.
-.Sp
-Old-style checking is a generic mechanism that requires no specific
-target support in the compiler but comes with the following drawbacks:
-.RS 4
-.IP "1." 4
-Modified allocation strategy for large objects: they will always be
-allocated dynamically if their size exceeds a fixed threshold.
-.IP "2." 4
-Fixed limit on the size of the static frame of functions: when it is
-topped by a particular function, stack checking is not reliable and
-a warning is issued by the compiler.
-.IP "3." 4
-Inefficiency: because of both the modified allocation strategy and the
-generic implementation, the performances of the code are hampered.
-.RE
-.RS 4
-.Sp
-Note that old-style stack checking is also the fallback method for
-\&\f(CW\*(C`specific\*(C'\fR if no target support has been added in the compiler.
-.RE
-.IP "\fB\-fstack\-limit\-register=\fR\fIreg\fR" 4
-.IX Item "-fstack-limit-register=reg"
-.PD 0
-.IP "\fB\-fstack\-limit\-symbol=\fR\fIsym\fR" 4
-.IX Item "-fstack-limit-symbol=sym"
-.IP "\fB\-fno\-stack\-limit\fR" 4
-.IX Item "-fno-stack-limit"
-.PD
-Generate code to ensure that the stack does not grow beyond a certain value,
-either the value of a register or the address of a symbol. If the stack
-would grow beyond the value, a signal is raised. For most targets,
-the signal is raised before the stack overruns the boundary, so
-it is possible to catch the signal without taking special precautions.
-.Sp
-For instance, if the stack starts at absolute address \fB0x80000000\fR
-and grows downwards, you can use the flags
-\&\fB\-fstack\-limit\-symbol=_\|_stack_limit\fR and
-\&\fB\-Wl,\-\-defsym,_\|_stack_limit=0x7ffe0000\fR to enforce a stack limit
-of 128KB. Note that this may only work with the \s-1GNU\s0 linker.
-.IP "\fB\-fsplit\-stack\fR" 4
-.IX Item "-fsplit-stack"
-Generate code to automatically split the stack before it overflows.
-The resulting program has a discontiguous stack which can only
-overflow if the program is unable to allocate any more memory. This
-is most useful when running threaded programs, as it is no longer
-necessary to calculate a good stack size to use for each thread. This
-is currently only implemented for the i386 and x86_64 backends running
-GNU/Linux.
-.Sp
-When code compiled with \fB\-fsplit\-stack\fR calls code compiled
-without \fB\-fsplit\-stack\fR, there may not be much stack space
-available for the latter code to run. If compiling all code,
-including library code, with \fB\-fsplit\-stack\fR is not an option,
-then the linker can fix up these calls so that the code compiled
-without \fB\-fsplit\-stack\fR always has a large stack. Support for
-this is implemented in the gold linker in \s-1GNU\s0 binutils release 2.21
-and later.
-.IP "\fB\-fleading\-underscore\fR" 4
-.IX Item "-fleading-underscore"
-This option and its counterpart, \fB\-fno\-leading\-underscore\fR, forcibly
-change the way C symbols are represented in the object file. One use
-is to help link with legacy assembly code.
-.Sp
-\&\fBWarning:\fR the \fB\-fleading\-underscore\fR switch causes \s-1GCC\s0 to
-generate code that is not binary compatible with code generated without that
-switch. Use it to conform to a non-default application binary interface.
-Not all targets provide complete support for this switch.
-.IP "\fB\-ftls\-model=\fR\fImodel\fR" 4
-.IX Item "-ftls-model=model"
-Alter the thread-local storage model to be used.
-The \fImodel\fR argument should be one of \f(CW\*(C`global\-dynamic\*(C'\fR,
-\&\f(CW\*(C`local\-dynamic\*(C'\fR, \f(CW\*(C`initial\-exec\*(C'\fR or \f(CW\*(C`local\-exec\*(C'\fR.
-.Sp
-The default without \fB\-fpic\fR is \f(CW\*(C`initial\-exec\*(C'\fR; with
-\&\fB\-fpic\fR the default is \f(CW\*(C`global\-dynamic\*(C'\fR.
-.IP "\fB\-fvisibility=\fR\fIdefault|internal|hidden|protected\fR" 4
-.IX Item "-fvisibility=default|internal|hidden|protected"
-Set the default \s-1ELF\s0 image symbol visibility to the specified option\-\-\-all
-symbols will be marked with this unless overridden within the code.
-Using this feature can very substantially improve linking and
-load times of shared object libraries, produce more optimized
-code, provide near-perfect \s-1API\s0 export and prevent symbol clashes.
-It is \fBstrongly\fR recommended that you use this in any shared objects
-you distribute.
-.Sp
-Despite the nomenclature, \f(CW\*(C`default\*(C'\fR always means public; i.e.,
-available to be linked against from outside the shared object.
-\&\f(CW\*(C`protected\*(C'\fR and \f(CW\*(C`internal\*(C'\fR are pretty useless in real-world
-usage so the only other commonly used option will be \f(CW\*(C`hidden\*(C'\fR.
-The default if \fB\-fvisibility\fR isn't specified is
-\&\f(CW\*(C`default\*(C'\fR, i.e., make every
-symbol public\-\-\-this causes the same behavior as previous versions of
-\&\s-1GCC\s0.
-.Sp
-A good explanation of the benefits offered by ensuring \s-1ELF\s0
-symbols have the correct visibility is given by \*(L"How To Write
-Shared Libraries\*(R" by Ulrich Drepper (which can be found at
-<\fBhttp://people.redhat.com/~drepper/\fR>)\-\-\-however a superior
-solution made possible by this option to marking things hidden when
-the default is public is to make the default hidden and mark things
-public. This is the norm with \s-1DLL\s0's on Windows and with \fB\-fvisibility=hidden\fR
-and \f(CW\*(C`_\|_attribute_\|_ ((visibility("default")))\*(C'\fR instead of
-\&\f(CW\*(C`_\|_declspec(dllexport)\*(C'\fR you get almost identical semantics with
-identical syntax. This is a great boon to those working with
-cross-platform projects.
-.Sp
-For those adding visibility support to existing code, you may find
-\&\fB#pragma \s-1GCC\s0 visibility\fR of use. This works by you enclosing
-the declarations you wish to set visibility for with (for example)
-\&\fB#pragma \s-1GCC\s0 visibility push(hidden)\fR and
-\&\fB#pragma \s-1GCC\s0 visibility pop\fR.
-Bear in mind that symbol visibility should be viewed \fBas
-part of the \s-1API\s0 interface contract\fR and thus all new code should
-always specify visibility when it is not the default; i.e., declarations
-only for use within the local \s-1DSO\s0 should \fBalways\fR be marked explicitly
-as hidden as so to avoid \s-1PLT\s0 indirection overheads\-\-\-making this
-abundantly clear also aids readability and self-documentation of the code.
-Note that due to \s-1ISO\s0 \*(C+ specification requirements, operator new and
-operator delete must always be of default visibility.
-.Sp
-Be aware that headers from outside your project, in particular system
-headers and headers from any other library you use, may not be
-expecting to be compiled with visibility other than the default. You
-may need to explicitly say \fB#pragma \s-1GCC\s0 visibility push(default)\fR
-before including any such headers.
-.Sp
-\&\fBextern\fR declarations are not affected by \fB\-fvisibility\fR, so
-a lot of code can be recompiled with \fB\-fvisibility=hidden\fR with
-no modifications. However, this means that calls to \fBextern\fR
-functions with no explicit visibility will use the \s-1PLT\s0, so it is more
-effective to use \fB_\|_attribute ((visibility))\fR and/or
-\&\fB#pragma \s-1GCC\s0 visibility\fR to tell the compiler which \fBextern\fR
-declarations should be treated as hidden.
-.Sp
-Note that \fB\-fvisibility\fR does affect \*(C+ vague linkage
-entities. This means that, for instance, an exception class that will
-be thrown between DSOs must be explicitly marked with default
-visibility so that the \fBtype_info\fR nodes will be unified between
-the DSOs.
-.Sp
-An overview of these techniques, their benefits and how to use them
-is at <\fBhttp://gcc.gnu.org/wiki/Visibility\fR>.
-.IP "\fB\-fstrict\-volatile\-bitfields\fR" 4
-.IX Item "-fstrict-volatile-bitfields"
-This option should be used if accesses to volatile bitfields (or other
-structure fields, although the compiler usually honors those types
-anyway) should use a single access of the width of the
-field's type, aligned to a natural alignment if possible. For
-example, targets with memory-mapped peripheral registers might require
-all such accesses to be 16 bits wide; with this flag the user could
-declare all peripheral bitfields as \*(L"unsigned short\*(R" (assuming short
-is 16 bits on these targets) to force \s-1GCC\s0 to use 16 bit accesses
-instead of, perhaps, a more efficient 32 bit access.
-.Sp
-If this option is disabled, the compiler will use the most efficient
-instruction. In the previous example, that might be a 32\-bit load
-instruction, even though that will access bytes that do not contain
-any portion of the bitfield, or memory-mapped registers unrelated to
-the one being updated.
-.Sp
-If the target requires strict alignment, and honoring the field
-type would require violating this alignment, a warning is issued.
-If the field has \f(CW\*(C`packed\*(C'\fR attribute, the access is done without
-honoring the field type. If the field doesn't have \f(CW\*(C`packed\*(C'\fR
-attribute, the access is done honoring the field type. In both cases,
-\&\s-1GCC\s0 assumes that the user knows something about the target hardware
-that it is unaware of.
-.Sp
-The default value of this option is determined by the application binary
-interface for the target processor.
-.SH "ENVIRONMENT"
-.IX Header "ENVIRONMENT"
-This section describes several environment variables that affect how \s-1GCC\s0
-operates. Some of them work by specifying directories or prefixes to use
-when searching for various kinds of files. Some are used to specify other
-aspects of the compilation environment.
-.PP
-Note that you can also specify places to search using options such as
-\&\fB\-B\fR, \fB\-I\fR and \fB\-L\fR. These
-take precedence over places specified using environment variables, which
-in turn take precedence over those specified by the configuration of \s-1GCC\s0.
-.IP "\fB\s-1LANG\s0\fR" 4
-.IX Item "LANG"
-.PD 0
-.IP "\fB\s-1LC_CTYPE\s0\fR" 4
-.IX Item "LC_CTYPE"
-.IP "\fB\s-1LC_MESSAGES\s0\fR" 4
-.IX Item "LC_MESSAGES"
-.IP "\fB\s-1LC_ALL\s0\fR" 4
-.IX Item "LC_ALL"
-.PD
-These environment variables control the way that \s-1GCC\s0 uses
-localization information that allow \s-1GCC\s0 to work with different
-national conventions. \s-1GCC\s0 inspects the locale categories
-\&\fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR if it has been configured to do
-so. These locale categories can be set to any value supported by your
-installation. A typical value is \fBen_GB.UTF\-8\fR for English in the United
-Kingdom encoded in \s-1UTF\-8\s0.
-.Sp
-The \fB\s-1LC_CTYPE\s0\fR environment variable specifies character
-classification. \s-1GCC\s0 uses it to determine the character boundaries in
-a string; this is needed for some multibyte encodings that contain quote
-and escape characters that would otherwise be interpreted as a string
-end or escape.
-.Sp
-The \fB\s-1LC_MESSAGES\s0\fR environment variable specifies the language to
-use in diagnostic messages.
-.Sp
-If the \fB\s-1LC_ALL\s0\fR environment variable is set, it overrides the value
-of \fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR; otherwise, \fB\s-1LC_CTYPE\s0\fR
-and \fB\s-1LC_MESSAGES\s0\fR default to the value of the \fB\s-1LANG\s0\fR
-environment variable. If none of these variables are set, \s-1GCC\s0
-defaults to traditional C English behavior.
-.IP "\fB\s-1TMPDIR\s0\fR" 4
-.IX Item "TMPDIR"
-If \fB\s-1TMPDIR\s0\fR is set, it specifies the directory to use for temporary
-files. \s-1GCC\s0 uses temporary files to hold the output of one stage of
-compilation which is to be used as input to the next stage: for example,
-the output of the preprocessor, which is the input to the compiler
-proper.
-.IP "\fB\s-1GCC_EXEC_PREFIX\s0\fR" 4
-.IX Item "GCC_EXEC_PREFIX"
-If \fB\s-1GCC_EXEC_PREFIX\s0\fR is set, it specifies a prefix to use in the
-names of the subprograms executed by the compiler. No slash is added
-when this prefix is combined with the name of a subprogram, but you can
-specify a prefix that ends with a slash if you wish.
-.Sp
-If \fB\s-1GCC_EXEC_PREFIX\s0\fR is not set, \s-1GCC\s0 will attempt to figure out
-an appropriate prefix to use based on the pathname it was invoked with.
-.Sp
-If \s-1GCC\s0 cannot find the subprogram using the specified prefix, it
-tries looking in the usual places for the subprogram.
-.Sp
-The default value of \fB\s-1GCC_EXEC_PREFIX\s0\fR is
-\&\fI\fIprefix\fI/lib/gcc/\fR where \fIprefix\fR is the prefix to
-the installed compiler. In many cases \fIprefix\fR is the value
-of \f(CW\*(C`prefix\*(C'\fR when you ran the \fIconfigure\fR script.
-.Sp
-Other prefixes specified with \fB\-B\fR take precedence over this prefix.
-.Sp
-This prefix is also used for finding files such as \fIcrt0.o\fR that are
-used for linking.
-.Sp
-In addition, the prefix is used in an unusual way in finding the
-directories to search for header files. For each of the standard
-directories whose name normally begins with \fB/usr/local/lib/gcc\fR
-(more precisely, with the value of \fB\s-1GCC_INCLUDE_DIR\s0\fR), \s-1GCC\s0 tries
-replacing that beginning with the specified prefix to produce an
-alternate directory name. Thus, with \fB\-Bfoo/\fR, \s-1GCC\s0 will search
-\&\fIfoo/bar\fR where it would normally search \fI/usr/local/lib/bar\fR.
-These alternate directories are searched first; the standard directories
-come next. If a standard directory begins with the configured
-\&\fIprefix\fR then the value of \fIprefix\fR is replaced by
-\&\fB\s-1GCC_EXEC_PREFIX\s0\fR when looking for header files.
-.IP "\fB\s-1COMPILER_PATH\s0\fR" 4
-.IX Item "COMPILER_PATH"
-The value of \fB\s-1COMPILER_PATH\s0\fR is a colon-separated list of
-directories, much like \fB\s-1PATH\s0\fR. \s-1GCC\s0 tries the directories thus
-specified when searching for subprograms, if it can't find the
-subprograms using \fB\s-1GCC_EXEC_PREFIX\s0\fR.
-.IP "\fB\s-1LIBRARY_PATH\s0\fR" 4
-.IX Item "LIBRARY_PATH"
-The value of \fB\s-1LIBRARY_PATH\s0\fR is a colon-separated list of
-directories, much like \fB\s-1PATH\s0\fR. When configured as a native compiler,
-\&\s-1GCC\s0 tries the directories thus specified when searching for special
-linker files, if it can't find them using \fB\s-1GCC_EXEC_PREFIX\s0\fR. Linking
-using \s-1GCC\s0 also uses these directories when searching for ordinary
-libraries for the \fB\-l\fR option (but directories specified with
-\&\fB\-L\fR come first).
-.IP "\fB\s-1LANG\s0\fR" 4
-.IX Item "LANG"
-This variable is used to pass locale information to the compiler. One way in
-which this information is used is to determine the character set to be used
-when character literals, string literals and comments are parsed in C and \*(C+.
-When the compiler is configured to allow multibyte characters,
-the following values for \fB\s-1LANG\s0\fR are recognized:
-.RS 4
-.IP "\fBC\-JIS\fR" 4
-.IX Item "C-JIS"
-Recognize \s-1JIS\s0 characters.
-.IP "\fBC\-SJIS\fR" 4
-.IX Item "C-SJIS"
-Recognize \s-1SJIS\s0 characters.
-.IP "\fBC\-EUCJP\fR" 4
-.IX Item "C-EUCJP"
-Recognize \s-1EUCJP\s0 characters.
-.RE
-.RS 4
-.Sp
-If \fB\s-1LANG\s0\fR is not defined, or if it has some other value, then the
-compiler will use mblen and mbtowc as defined by the default locale to
-recognize and translate multibyte characters.
-.RE
-.PP
-Some additional environments variables affect the behavior of the
-preprocessor.
-.IP "\fB\s-1CPATH\s0\fR" 4
-.IX Item "CPATH"
-.PD 0
-.IP "\fBC_INCLUDE_PATH\fR" 4
-.IX Item "C_INCLUDE_PATH"
-.IP "\fB\s-1CPLUS_INCLUDE_PATH\s0\fR" 4
-.IX Item "CPLUS_INCLUDE_PATH"
-.IP "\fB\s-1OBJC_INCLUDE_PATH\s0\fR" 4
-.IX Item "OBJC_INCLUDE_PATH"
-.PD
-Each variable's value is a list of directories separated by a special
-character, much like \fB\s-1PATH\s0\fR, in which to look for header files.
-The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, is target-dependent and
-determined at \s-1GCC\s0 build time. For Microsoft Windows-based targets it is a
-semicolon, and for almost all other targets it is a colon.
-.Sp
-\&\fB\s-1CPATH\s0\fR specifies a list of directories to be searched as if
-specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
-options on the command line. This environment variable is used
-regardless of which language is being preprocessed.
-.Sp
-The remaining environment variables apply only when preprocessing the
-particular language indicated. Each specifies a list of directories
-to be searched as if specified with \fB\-isystem\fR, but after any
-paths given with \fB\-isystem\fR options on the command line.
-.Sp
-In all these variables, an empty element instructs the compiler to
-search its current working directory. Empty elements can appear at the
-beginning or end of a path. For instance, if the value of
-\&\fB\s-1CPATH\s0\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
-effect as \fB\-I.\ \-I/special/include\fR.
-.IP "\fB\s-1DEPENDENCIES_OUTPUT\s0\fR" 4
-.IX Item "DEPENDENCIES_OUTPUT"
-If this variable is set, its value specifies how to output
-dependencies for Make based on the non-system header files processed
-by the compiler. System header files are ignored in the dependency
-output.
-.Sp
-The value of \fB\s-1DEPENDENCIES_OUTPUT\s0\fR can be just a file name, in
-which case the Make rules are written to that file, guessing the target
-name from the source file name. Or the value can have the form
-\&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
-file \fIfile\fR using \fItarget\fR as the target name.
-.Sp
-In other words, this environment variable is equivalent to combining
-the options \fB\-MM\fR and \fB\-MF\fR,
-with an optional \fB\-MT\fR switch too.
-.IP "\fB\s-1SUNPRO_DEPENDENCIES\s0\fR" 4
-.IX Item "SUNPRO_DEPENDENCIES"
-This variable is the same as \fB\s-1DEPENDENCIES_OUTPUT\s0\fR (see above),
-except that system header files are not ignored, so it implies
-\&\fB\-M\fR rather than \fB\-MM\fR. However, the dependence on the
-main input file is omitted.
-.SH "BUGS"
-.IX Header "BUGS"
-For instructions on reporting bugs, see
-<\fBhttp://gcc.gnu.org/bugs.html\fR>.
-.SH "FOOTNOTES"
-.IX Header "FOOTNOTES"
-.IP "1." 4
-On some systems, \fBgcc \-shared\fR
-needs to build supplementary stub code for constructors to work. On
-multi-libbed systems, \fBgcc \-shared\fR must select the correct support
-libraries to link against. Failing to supply the correct flags may lead
-to subtle defects. Supplying them in cases where they are not necessary
-is innocuous.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7),
-\&\fIcpp\fR\|(1), \fIgcov\fR\|(1), \fIas\fR\|(1), \fIld\fR\|(1), \fIgdb\fR\|(1), \fIadb\fR\|(1), \fIdbx\fR\|(1), \fIsdb\fR\|(1)
-and the Info entries for \fIgcc\fR, \fIcpp\fR, \fIas\fR,
-\&\fIld\fR, \fIbinutils\fR and \fIgdb\fR.
-.SH "AUTHOR"
-.IX Header "AUTHOR"
-See the Info entry for \fBgcc\fR, or
-<\fBhttp://gcc.gnu.org/onlinedocs/gcc/Contributors.html\fR>,
-for contributors to \s-1GCC\s0.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with the
-Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
-Free Software\*(R", the Front-Cover texts being (a) (see below), and with
-the Back-Cover Texts being (b) (see below). A copy of the license is
-included in the \fIgfdl\fR\|(7) man page.
-.PP
-(a) The \s-1FSF\s0's Front-Cover Text is:
-.PP
-.Vb 1
-\& A GNU Manual
-.Ve
-.PP
-(b) The \s-1FSF\s0's Back-Cover Text is:
-.PP
-.Vb 3
-\& You have freedom to copy and modify this GNU Manual, like GNU
-\& software. Copies published by the Free Software Foundation raise
-\& funds for GNU development.
-.Ve
diff --git a/share/man/man1/arm-eabi-gcov.1 b/share/man/man1/arm-eabi-gcov.1
deleted file mode 100644
index 579c0f3..0000000
--- a/share/man/man1/arm-eabi-gcov.1
+++ /dev/null
@@ -1,681 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "GCOV 1"
-.TH GCOV 1 "2012-01-06" "gcc-4.6.x-google" "GNU"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-gcov \- coverage testing tool
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-gcov [\fB\-v\fR|\fB\-\-version\fR] [\fB\-h\fR|\fB\-\-help\fR]
- [\fB\-a\fR|\fB\-\-all\-blocks\fR]
- [\fB\-b\fR|\fB\-\-branch\-probabilities\fR]
- [\fB\-c\fR|\fB\-\-branch\-counts\fR]
- [\fB\-m\fR|\fB\-\-pmu\-profile\fR]
- [\fB\-n\fR|\fB\-\-no\-output\fR]
- [\fB\-l\fR|\fB\-\-long\-file\-names\fR]
- [\fB\-p\fR|\fB\-\-preserve\-paths\fR]
- [\fB\-q\fR|\fB\-\-pmu_profile\-path\fR]
- [\fB\-f\fR|\fB\-\-function\-summaries\fR]
- [\fB\-o\fR|\fB\-\-object\-directory\fR \fIdirectory|file\fR] \fIsourcefiles\fR
- [\fB\-u\fR|\fB\-\-unconditional\-branches\fR]
- [\fB\-i\fR|\fB\-\-intermediate\-format\fR]
- [\fB\-d\fR|\fB\-\-display\-progress\fR]
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\fBgcov\fR is a test coverage program. Use it in concert with \s-1GCC\s0
-to analyze your programs to help create more efficient, faster running
-code and to discover untested parts of your program. You can use
-\&\fBgcov\fR as a profiling tool to help discover where your
-optimization efforts will best affect your code. You can also use
-\&\fBgcov\fR along with the other profiling tool, \fBgprof\fR, to
-assess which parts of your code use the greatest amount of computing
-time.
-.PP
-Profiling tools help you analyze your code's performance. Using a
-profiler such as \fBgcov\fR or \fBgprof\fR, you can find out some
-basic performance statistics, such as:
-.IP "\(bu" 4
-how often each line of code executes
-.IP "\(bu" 4
-what lines of code are actually executed
-.IP "\(bu" 4
-how much computing time each section of code uses
-.PP
-Once you know these things about how your code works when compiled, you
-can look at each module to see which modules should be optimized.
-\&\fBgcov\fR helps you determine where to work on optimization.
-.PP
-Software developers also use coverage testing in concert with
-testsuites, to make sure software is actually good enough for a release.
-Testsuites can verify that a program works as expected; a coverage
-program tests to see how much of the program is exercised by the
-testsuite. Developers can then determine what kinds of test cases need
-to be added to the testsuites to create both better testing and a better
-final product.
-.PP
-You should compile your code without optimization if you plan to use
-\&\fBgcov\fR because the optimization, by combining some lines of code
-into one function, may not give you as much information as you need to
-look for `hot spots' where the code is using a great deal of computer
-time. Likewise, because \fBgcov\fR accumulates statistics by line (at
-the lowest resolution), it works best with a programming style that
-places only one statement on each line. If you use complicated macros
-that expand to loops or to other control structures, the statistics are
-less helpful\-\-\-they only report on the line where the macro call
-appears. If your complex macros behave like functions, you can replace
-them with inline functions to solve this problem.
-.PP
-\&\fBgcov\fR creates a logfile called \fI\fIsourcefile\fI.gcov\fR which
-indicates how many times each line of a source file \fI\fIsourcefile\fI.c\fR
-has executed. You can use these logfiles along with \fBgprof\fR to aid
-in fine-tuning the performance of your programs. \fBgprof\fR gives
-timing information you can use along with the information you get from
-\&\fBgcov\fR.
-.PP
-\&\fBgcov\fR works only on code compiled with \s-1GCC\s0. It is not
-compatible with any other profiling or test coverage mechanism.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.IP "\fB\-h\fR" 4
-.IX Item "-h"
-.PD 0
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-.PD
-Display help about using \fBgcov\fR (on the standard output), and
-exit without doing any further processing.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Display the \fBgcov\fR version number (on the standard output),
-and exit without doing any further processing.
-.IP "\fB\-a\fR" 4
-.IX Item "-a"
-.PD 0
-.IP "\fB\-\-all\-blocks\fR" 4
-.IX Item "--all-blocks"
-.PD
-Write individual execution counts for every basic block. Normally gcov
-outputs execution counts only for the main blocks of a line. With this
-option you can determine if blocks within a single line are not being
-executed.
-.IP "\fB\-b\fR" 4
-.IX Item "-b"
-.PD 0
-.IP "\fB\-\-branch\-probabilities\fR" 4
-.IX Item "--branch-probabilities"
-.PD
-Write branch frequencies to the output file, and write branch summary
-info to the standard output. This option allows you to see how often
-each branch in your program was taken. Unconditional branches will not
-be shown, unless the \fB\-u\fR option is given.
-.IP "\fB\-c\fR" 4
-.IX Item "-c"
-.PD 0
-.IP "\fB\-\-branch\-counts\fR" 4
-.IX Item "--branch-counts"
-.PD
-Write branch frequencies as the number of branches taken, rather than
-the percentage of branches taken.
-.IP "\fB\-m\fR" 4
-.IX Item "-m"
-.PD 0
-.IP "\fB\-\-pmu\-profile\fR" 4
-.IX Item "--pmu-profile"
-.PD
-Output the additional \s-1PMU\s0 profile information if available.
-.IP "\fB\-q\fR" 4
-.IX Item "-q"
-.PD 0
-.IP "\fB\-\-pmu_profile\-path\fR" 4
-.IX Item "--pmu_profile-path"
-.PD
-\&\s-1PMU\s0 profile path (default \fIpmuprofile.gcda\fR).
-.IP "\fB\-n\fR" 4
-.IX Item "-n"
-.PD 0
-.IP "\fB\-\-no\-output\fR" 4
-.IX Item "--no-output"
-.PD
-Do not create the \fBgcov\fR output file.
-.IP "\fB\-l\fR" 4
-.IX Item "-l"
-.PD 0
-.IP "\fB\-\-long\-file\-names\fR" 4
-.IX Item "--long-file-names"
-.PD
-Create long file names for included source files. For example, if the
-header file \fIx.h\fR contains code, and was included in the file
-\&\fIa.c\fR, then running \fBgcov\fR on the file \fIa.c\fR will produce
-an output file called \fIa.c##x.h.gcov\fR instead of \fIx.h.gcov\fR.
-This can be useful if \fIx.h\fR is included in multiple source
-files. If you use the \fB\-p\fR option, both the including and
-included file names will be complete path names.
-.IP "\fB\-p\fR" 4
-.IX Item "-p"
-.PD 0
-.IP "\fB\-\-preserve\-paths\fR" 4
-.IX Item "--preserve-paths"
-.PD
-Preserve complete path information in the names of generated
-\&\fI.gcov\fR files. Without this option, just the filename component is
-used. With this option, all directories are used, with \fB/\fR characters
-translated to \fB#\fR characters, \fI.\fR directory components
-removed and \fI..\fR
-components renamed to \fB^\fR. This is useful if sourcefiles are in several
-different directories. It also affects the \fB\-l\fR option.
-.IP "\fB\-f\fR" 4
-.IX Item "-f"
-.PD 0
-.IP "\fB\-\-function\-summaries\fR" 4
-.IX Item "--function-summaries"
-.PD
-Output summaries for each function in addition to the file level summary.
-.IP "\fB\-o\fR \fIdirectory|file\fR" 4
-.IX Item "-o directory|file"
-.PD 0
-.IP "\fB\-\-object\-directory\fR \fIdirectory\fR" 4
-.IX Item "--object-directory directory"
-.IP "\fB\-\-object\-file\fR \fIfile\fR" 4
-.IX Item "--object-file file"
-.PD
-Specify either the directory containing the gcov data files, or the
-object path name. The \fI.gcno\fR, and
-\&\fI.gcda\fR data files are searched for using this option. If a directory
-is specified, the data files are in that directory and named after the
-source file name, without its extension. If a file is specified here,
-the data files are named after that file, without its extension. If this
-option is not supplied, it defaults to the current directory.
-.IP "\fB\-u\fR" 4
-.IX Item "-u"
-.PD 0
-.IP "\fB\-\-unconditional\-branches\fR" 4
-.IX Item "--unconditional-branches"
-.PD
-When branch probabilities are given, include those of unconditional branches.
-Unconditional branches are normally not interesting.
-.IP "\fB\-d\fR" 4
-.IX Item "-d"
-.PD 0
-.IP "\fB\-\-display\-progress\fR" 4
-.IX Item "--display-progress"
-.PD
-Display the progress on the standard output.
-.IP "\fB\-i\fR" 4
-.IX Item "-i"
-.PD 0
-.IP "\fB\-\-intermediate\-format\fR" 4
-.IX Item "--intermediate-format"
-.PD
-Output gcov file in an intermediate text format that can be used by
-\&\fBlcov\fR or other applications. It will output a single *.gcov file per
-*.gcda file. No source code is required.
-.Sp
-The format of the intermediate \fI.gcov\fR file is plain text with
-one entry per line
-.Sp
-.Vb 5
-\& SF:<source_file_name>
-\& FN:<line_number>,<function_name>
-\& FNDA:<execution_count>,<function_name>
-\& BA:<line_num>,<branch_coverage_type>
-\& DA:<line number>,<execution_count>
-\&
-\& Where the <branch_coverage_type> is
-\& 0 (Branch not executed)
-\& 1 (Branch executed, but not taken)
-\& 2 (Branch executed and taken)
-\&
-\& There can be multiple SF entries in an intermediate gcov file. All
-\& entries following SF pertain to that source file until the next SF
-\& entry.
-.Ve
-.PP
-\&\fBgcov\fR should be run with the current directory the same as that
-when you invoked the compiler. Otherwise it will not be able to locate
-the source files. \fBgcov\fR produces files called
-\&\fI\fImangledname\fI.gcov\fR in the current directory. These contain
-the coverage information of the source file they correspond to.
-One \fI.gcov\fR file is produced for each source file containing code,
-which was compiled to produce the data files. The \fImangledname\fR part
-of the output file name is usually simply the source file name, but can
-be something more complicated if the \fB\-l\fR or \fB\-p\fR options are
-given. Refer to those options for details.
-.PP
-The \fI.gcov\fR files contain the \fB:\fR separated fields along with
-program source code. The format is
-.PP
-.Vb 1
-\& <execution_count>:<line_number>:<source line text>
-.Ve
-.PP
-Additional block information may succeed each line, when requested by
-command line option. The \fIexecution_count\fR is \fB\-\fR for lines
-containing no code and \fB#####\fR for lines which were never executed.
-Some lines of information at the start have \fIline_number\fR of zero.
-.PP
-The preamble lines are of the form
-.PP
-.Vb 1
-\& \-:0:<tag>:<value>
-.Ve
-.PP
-The ordering and number of these preamble lines will be augmented as
-\&\fBgcov\fR development progresses \-\-\- do not rely on them remaining
-unchanged. Use \fItag\fR to locate a particular preamble line.
-.PP
-The additional block information is of the form
-.PP
-.Vb 1
-\& <tag> <information>
-.Ve
-.PP
-The \fIinformation\fR is human readable, but designed to be simple
-enough for machine parsing too.
-.PP
-When printing percentages, 0% and 100% are only printed when the values
-are \fIexactly\fR 0% and 100% respectively. Other values which would
-conventionally be rounded to 0% or 100% are instead printed as the
-nearest non-boundary value.
-.PP
-When using \fBgcov\fR, you must first compile your program with two
-special \s-1GCC\s0 options: \fB\-fprofile\-arcs \-ftest\-coverage\fR.
-This tells the compiler to generate additional information needed by
-gcov (basically a flow graph of the program) and also includes
-additional code in the object files for generating the extra profiling
-information needed by gcov. These additional files are placed in the
-directory where the object file is located.
-.PP
-Running the program will cause profile output to be generated. For each
-source file compiled with \fB\-fprofile\-arcs\fR, an accompanying
-\&\fI.gcda\fR file will be placed in the object file directory.
-.PP
-Running \fBgcov\fR with your program's source file names as arguments
-will now produce a listing of the code along with frequency of execution
-for each line. For example, if your program is called \fItmp.c\fR, this
-is what you see when you use the basic \fBgcov\fR facility:
-.PP
-.Vb 5
-\& $ gcc \-fprofile\-arcs \-ftest\-coverage tmp.c
-\& $ a.out
-\& $ gcov tmp.c
-\& 90.00% of 10 source lines executed in file tmp.c
-\& Creating tmp.c.gcov.
-.Ve
-.PP
-The file \fItmp.c.gcov\fR contains output from \fBgcov\fR.
-Here is a sample:
-.PP
-.Vb 10
-\& \-: 0:Source:tmp.c
-\& \-: 0:Graph:tmp.gcno
-\& \-: 0:Data:tmp.gcda
-\& \-: 0:Runs:1
-\& \-: 0:Programs:1
-\& \-: 1:#include <stdio.h>
-\& \-: 2:
-\& \-: 3:int main (void)
-\& 1: 4:{
-\& 1: 5: int i, total;
-\& \-: 6:
-\& 1: 7: total = 0;
-\& \-: 8:
-\& 11: 9: for (i = 0; i < 10; i++)
-\& 10: 10: total += i;
-\& \-: 11:
-\& 1: 12: if (total != 45)
-\& #####: 13: printf ("Failure\en");
-\& \-: 14: else
-\& 1: 15: printf ("Success\en");
-\& 1: 16: return 0;
-\& \-: 17:}
-.Ve
-.PP
-When you use the \fB\-a\fR option, you will get individual block
-counts, and the output looks like this:
-.PP
-.Vb 10
-\& \-: 0:Source:tmp.c
-\& \-: 0:Graph:tmp.gcno
-\& \-: 0:Data:tmp.gcda
-\& \-: 0:Runs:1
-\& \-: 0:Programs:1
-\& \-: 1:#include <stdio.h>
-\& \-: 2:
-\& \-: 3:int main (void)
-\& 1: 4:{
-\& 1: 4\-block 0
-\& 1: 5: int i, total;
-\& \-: 6:
-\& 1: 7: total = 0;
-\& \-: 8:
-\& 11: 9: for (i = 0; i < 10; i++)
-\& 11: 9\-block 0
-\& 10: 10: total += i;
-\& 10: 10\-block 0
-\& \-: 11:
-\& 1: 12: if (total != 45)
-\& 1: 12\-block 0
-\& #####: 13: printf ("Failure\en");
-\& $$$$$: 13\-block 0
-\& \-: 14: else
-\& 1: 15: printf ("Success\en");
-\& 1: 15\-block 0
-\& 1: 16: return 0;
-\& 1: 16\-block 0
-\& \-: 17:}
-.Ve
-.PP
-In this mode, each basic block is only shown on one line \*(-- the last
-line of the block. A multi-line block will only contribute to the
-execution count of that last line, and other lines will not be shown
-to contain code, unless previous blocks end on those lines.
-The total execution count of a line is shown and subsequent lines show
-the execution counts for individual blocks that end on that line. After each
-block, the branch and call counts of the block will be shown, if the
-\&\fB\-b\fR option is given.
-.PP
-Because of the way \s-1GCC\s0 instruments calls, a call count can be shown
-after a line with no individual blocks.
-As you can see, line 13 contains a basic block that was not executed.
-.PP
-When you use the \fB\-b\fR option, your output looks like this:
-.PP
-.Vb 6
-\& $ gcov \-b tmp.c
-\& 90.00% of 10 source lines executed in file tmp.c
-\& 80.00% of 5 branches executed in file tmp.c
-\& 80.00% of 5 branches taken at least once in file tmp.c
-\& 50.00% of 2 calls executed in file tmp.c
-\& Creating tmp.c.gcov.
-.Ve
-.PP
-Here is a sample of a resulting \fItmp.c.gcov\fR file:
-.PP
-.Vb 10
-\& \-: 0:Source:tmp.c
-\& \-: 0:Graph:tmp.gcno
-\& \-: 0:Data:tmp.gcda
-\& \-: 0:Runs:1
-\& \-: 0:Programs:1
-\& \-: 1:#include <stdio.h>
-\& \-: 2:
-\& \-: 3:int main (void)
-\& function main called 1 returned 1 blocks executed 75%
-\& 1: 4:{
-\& 1: 5: int i, total;
-\& \-: 6:
-\& 1: 7: total = 0;
-\& \-: 8:
-\& 11: 9: for (i = 0; i < 10; i++)
-\& branch 0 taken 91% (fallthrough)
-\& branch 1 taken 9%
-\& 10: 10: total += i;
-\& \-: 11:
-\& 1: 12: if (total != 45)
-\& branch 0 taken 0% (fallthrough)
-\& branch 1 taken 100%
-\& #####: 13: printf ("Failure\en");
-\& call 0 never executed
-\& \-: 14: else
-\& 1: 15: printf ("Success\en");
-\& call 0 called 1 returned 100%
-\& 1: 16: return 0;
-\& \-: 17:}
-.Ve
-.PP
-For each function, a line is printed showing how many times the function
-is called, how many times it returns and what percentage of the
-function's blocks were executed.
-.PP
-For each basic block, a line is printed after the last line of the basic
-block describing the branch or call that ends the basic block. There can
-be multiple branches and calls listed for a single source line if there
-are multiple basic blocks that end on that line. In this case, the
-branches and calls are each given a number. There is no simple way to map
-these branches and calls back to source constructs. In general, though,
-the lowest numbered branch or call will correspond to the leftmost construct
-on the source line.
-.PP
-For a branch, if it was executed at least once, then a percentage
-indicating the number of times the branch was taken divided by the
-number of times the branch was executed will be printed. Otherwise, the
-message \*(L"never executed\*(R" is printed.
-.PP
-For a call, if it was executed at least once, then a percentage
-indicating the number of times the call returned divided by the number
-of times the call was executed will be printed. This will usually be
-100%, but may be less for functions that call \f(CW\*(C`exit\*(C'\fR or \f(CW\*(C`longjmp\*(C'\fR,
-and thus may not return every time they are called.
-.PP
-The execution counts are cumulative. If the example program were
-executed again without removing the \fI.gcda\fR file, the count for the
-number of times each line in the source was executed would be added to
-the results of the previous run(s). This is potentially useful in
-several ways. For example, it could be used to accumulate data over a
-number of program runs as part of a test verification suite, or to
-provide more accurate long-term information over a large number of
-program runs.
-.PP
-The data in the \fI.gcda\fR files is saved immediately before the program
-exits. For each source file compiled with \fB\-fprofile\-arcs\fR, the
-profiling code first attempts to read in an existing \fI.gcda\fR file; if
-the file doesn't match the executable (differing number of basic block
-counts) it will ignore the contents of the file. It then adds in the
-new execution counts and finally writes the data to the file.
-.SS "Using \fBgcov\fP with \s-1GCC\s0 Optimization"
-.IX Subsection "Using gcov with GCC Optimization"
-If you plan to use \fBgcov\fR to help optimize your code, you must
-first compile your program with two special \s-1GCC\s0 options:
-\&\fB\-fprofile\-arcs \-ftest\-coverage\fR. Aside from that, you can use any
-other \s-1GCC\s0 options; but if you want to prove that every single line
-in your program was executed, you should not compile with optimization
-at the same time. On some machines the optimizer can eliminate some
-simple code lines by combining them with other lines. For example, code
-like this:
-.PP
-.Vb 4
-\& if (a != b)
-\& c = 1;
-\& else
-\& c = 0;
-.Ve
-.PP
-can be compiled into one instruction on some machines. In this case,
-there is no way for \fBgcov\fR to calculate separate execution counts
-for each line because there isn't separate code for each line. Hence
-the \fBgcov\fR output looks like this if you compiled the program with
-optimization:
-.PP
-.Vb 4
-\& 100: 12:if (a != b)
-\& 100: 13: c = 1;
-\& 100: 14:else
-\& 100: 15: c = 0;
-.Ve
-.PP
-The output shows that this block of code, combined by optimization,
-executed 100 times. In one sense this result is correct, because there
-was only one instruction representing all four of these lines. However,
-the output does not indicate how many times the result was 0 and how
-many times the result was 1.
-.PP
-Inlineable functions can create unexpected line counts. Line counts are
-shown for the source code of the inlineable function, but what is shown
-depends on where the function is inlined, or if it is not inlined at all.
-.PP
-If the function is not inlined, the compiler must emit an out of line
-copy of the function, in any object file that needs it. If
-\&\fIfileA.o\fR and \fIfileB.o\fR both contain out of line bodies of a
-particular inlineable function, they will also both contain coverage
-counts for that function. When \fIfileA.o\fR and \fIfileB.o\fR are
-linked together, the linker will, on many systems, select one of those
-out of line bodies for all calls to that function, and remove or ignore
-the other. Unfortunately, it will not remove the coverage counters for
-the unused function body. Hence when instrumented, all but one use of
-that function will show zero counts.
-.PP
-If the function is inlined in several places, the block structure in
-each location might not be the same. For instance, a condition might
-now be calculable at compile time in some instances. Because the
-coverage of all the uses of the inline function will be shown for the
-same source lines, the line counts themselves might seem inconsistent.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7), \fIgcc\fR\|(1) and the Info entry for \fIgcc\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1996, 1997, 1999, 2000, 2001, 2002, 2003, 2004,
-2005, 2008, 2010 Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with the
-Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
-Free Software\*(R", the Front-Cover texts being (a) (see below), and with
-the Back-Cover Texts being (b) (see below). A copy of the license is
-included in the \fIgfdl\fR\|(7) man page.
-.PP
-(a) The \s-1FSF\s0's Front-Cover Text is:
-.PP
-.Vb 1
-\& A GNU Manual
-.Ve
-.PP
-(b) The \s-1FSF\s0's Back-Cover Text is:
-.PP
-.Vb 3
-\& You have freedom to copy and modify this GNU Manual, like GNU
-\& software. Copies published by the Free Software Foundation raise
-\& funds for GNU development.
-.Ve
diff --git a/share/man/man1/arm-eabi-gdb.1 b/share/man/man1/arm-eabi-gdb.1
deleted file mode 100644
index d14eb78..0000000
--- a/share/man/man1/arm-eabi-gdb.1
+++ /dev/null
@@ -1,381 +0,0 @@
-.\" Copyright (C) 1991, 1999, 2010, 2011 Free Software Foundation, Inc.
-.\" See section COPYING for conditions for redistribution
-.\" $Id: gdb.1,v 1.4 1999/01/05 00:50:50 jsm Exp $
-.TH gdb 1 "22may2002" "GNU Tools" "GNU Tools"
-.SH NAME
-gdb \- The GNU Debugger
-.SH SYNOPSIS
-.na
-.TP
-.B gdb
-.RB "[\|" \-help "\|]"
-.RB "[\|" \-nx "\|]"
-.RB "[\|" \-q "\|]"
-.RB "[\|" \-batch "\|]"
-.RB "[\|" \-cd=\c
-.I dir\c
-\|]
-.RB "[\|" \-f "\|]"
-.RB "[\|" "\-b\ "\c
-.IR bps "\|]"
-.RB "[\|" "\-tty="\c
-.IR dev "\|]"
-.RB "[\|" "\-s "\c
-.I symfile\c
-\&\|]
-.RB "[\|" "\-e "\c
-.I prog\c
-\&\|]
-.RB "[\|" "\-se "\c
-.I prog\c
-\&\|]
-.RB "[\|" "\-c "\c
-.I core\c
-\&\|]
-.RB "[\|" "\-x "\c
-.I cmds\c
-\&\|]
-.RB "[\|" "\-d "\c
-.I dir\c
-\&\|]
-.RB "[\|" \c
-.I prog\c
-.RB "[\|" \c
-.IR core \||\| procID\c
-\&\|]\&\|]
-.ad b
-.SH DESCRIPTION
-The purpose of a debugger such as GDB is to allow you to see what is
-going on ``inside'' another program while it executes\(em\&or what another
-program was doing at the moment it crashed.
-
-GDB can do four main kinds of things (plus other things in support of
-these) to help you catch bugs in the act:
-
-.TP
-\ \ \ \(bu
-Start your program, specifying anything that might affect its behavior.
-
-.TP
-\ \ \ \(bu
-Make your program stop on specified conditions.
-
-.TP
-\ \ \ \(bu
-Examine what has happened, when your program has stopped.
-
-.TP
-\ \ \ \(bu
-Change things in your program, so you can experiment with correcting the
-effects of one bug and go on to learn about another.
-.PP
-
-You can use GDB to debug programs written in C, C++, and Modula-2.
-Fortran support will be added when a GNU Fortran compiler is ready.
-
-GDB is invoked with the shell command \c
-.B gdb\c
-\&. Once started, it reads
-commands from the terminal until you tell it to exit with the GDB
-command \c
-.B quit\c
-\&. You can get online help from \c
-.B gdb\c
-\& itself
-by using the command \c
-.B help\c
-\&.
-
-You can run \c
-.B gdb\c
-\& with no arguments or options; but the most
-usual way to start GDB is with one argument or two, specifying an
-executable program as the argument:
-.sp
-.br
-gdb\ program
-.br
-.sp
-
-You can also start with both an executable program and a core file specified:
-.sp
-.br
-gdb\ program\ core
-.br
-.sp
-
-You can, instead, specify a process ID as a second argument, if you want
-to debug a running process:
-.sp
-.br
-gdb\ program\ 1234
-.br
-.sp
-
-would attach GDB to process \c
-.B 1234\c
-\& (unless you also have a file
-named `\|\c
-.B 1234\c
-\&\|'; GDB does check for a core file first).
-
-Here are some of the most frequently needed GDB commands:
-.TP
-.B break \fR[\|\fIfile\fB:\fR\|]\fIfunction
-\&
-Set a breakpoint at \c
-.I function\c
-\& (in \c
-.I file\c
-\&).
-.TP
-.B run \fR[\|\fIarglist\fR\|]
-Start your program (with \c
-.I arglist\c
-\&, if specified).
-.TP
-.B bt
-Backtrace: display the program stack.
-.TP
-.BI print " expr"\c
-\&
-Display the value of an expression.
-.TP
-.B c
-Continue running your program (after stopping, e.g. at a breakpoint).
-.TP
-.B next
-Execute next program line (after stopping); step \c
-.I over\c
-\& any
-function calls in the line.
-.TP
-.B edit \fR[\|\fIfile\fB:\fR\|]\fIfunction
-look at the program line where it is presently stopped.
-.TP
-.B list \fR[\|\fIfile\fB:\fR\|]\fIfunction
-type the text of the program in the vicinity of where it is presently stopped.
-.TP
-.B step
-Execute next program line (after stopping); step \c
-.I into\c
-\& any
-function calls in the line.
-.TP
-.B help \fR[\|\fIname\fR\|]
-Show information about GDB command \c
-.I name\c
-\&, or general information
-about using GDB.
-.TP
-.B quit
-Exit from GDB.
-.PP
-For full details on GDB, see \c
-.I
-Using GDB: A Guide to the GNU Source-Level Debugger\c
-\&, by Richard M. Stallman and Roland H. Pesch. The same text is available online
-as the \c
-.B gdb\c
-\& entry in the \c
-.B info\c
-\& program.
-.SH OPTIONS
-Any arguments other than options specify an executable
-file and core file (or process ID); that is, the first argument
-encountered with no
-associated option flag is equivalent to a `\|\c
-.B \-se\c
-\&\|' option, and the
-second, if any, is equivalent to a `\|\c
-.B \-c\c
-\&\|' option if it's the name of a file. Many options have
-both long and short forms; both are shown here. The long forms are also
-recognized if you truncate them, so long as enough of the option is
-present to be unambiguous. (If you prefer, you can flag option
-arguments with `\|\c
-.B +\c
-\&\|' rather than `\|\c
-.B \-\c
-\&\|', though we illustrate the
-more usual convention.)
-
-All the options and command line arguments you give are processed
-in sequential order. The order makes a difference when the
-`\|\c
-.B \-x\c
-\&\|' option is used.
-
-.TP
-.B \-help
-.TP
-.B \-h
-List all options, with brief explanations.
-
-.TP
-.BI "\-symbols=" "file"\c
-.TP
-.BI "\-s " "file"\c
-\&
-Read symbol table from file \c
-.I file\c
-\&.
-
-.TP
-.B \-write
-Enable writing into executable and core files.
-
-.TP
-.BI "\-exec=" "file"\c
-.TP
-.BI "\-e " "file"\c
-\&
-Use file \c
-.I file\c
-\& as the executable file to execute when
-appropriate, and for examining pure data in conjunction with a core
-dump.
-
-.TP
-.BI "\-se=" "file"\c
-\&
-Read symbol table from file \c
-.I file\c
-\& and use it as the executable
-file.
-
-.TP
-.BI "\-core=" "file"\c
-.TP
-.BI "\-c " "file"\c
-\&
-Use file \c
-.I file\c
-\& as a core dump to examine.
-
-.TP
-.BI "\-command=" "file"\c
-.TP
-.BI "\-x " "file"\c
-\&
-Execute GDB commands from file \c
-.I file\c
-\&.
-
-.TP
-.BI "\-directory=" "directory"\c
-.TP
-.BI "\-d " "directory"\c
-\&
-Add \c
-.I directory\c
-\& to the path to search for source files.
-.PP
-
-.TP
-.B \-nx
-.TP
-.B \-n
-Do not execute commands from any `\|\c
-.B .gdbinit\c
-\&\|' initialization files.
-Normally, the commands in these files are executed after all the
-command options and arguments have been processed.
-
-
-.TP
-.B \-quiet
-.TP
-.B \-q
-``Quiet''. Do not print the introductory and copyright messages. These
-messages are also suppressed in batch mode.
-
-.TP
-.B \-batch
-Run in batch mode. Exit with status \c
-.B 0\c
-\& after processing all the command
-files specified with `\|\c
-.B \-x\c
-\&\|' (and `\|\c
-.B .gdbinit\c
-\&\|', if not inhibited).
-Exit with nonzero status if an error occurs in executing the GDB
-commands in the command files.
-
-Batch mode may be useful for running GDB as a filter, for example to
-download and run a program on another computer; in order to make this
-more useful, the message
-.sp
-.br
-Program\ exited\ normally.
-.br
-.sp
-
-(which is ordinarily issued whenever a program running under GDB control
-terminates) is not issued when running in batch mode.
-
-.TP
-.BI "\-cd=" "directory"\c
-\&
-Run GDB using \c
-.I directory\c
-\& as its working directory,
-instead of the current directory.
-
-.TP
-.B \-fullname
-.TP
-.B \-f
-Emacs sets this option when it runs GDB as a subprocess. It tells GDB
-to output the full file name and line number in a standard,
-recognizable fashion each time a stack frame is displayed (which
-includes each time the program stops). This recognizable format looks
-like two `\|\c
-.B \032\c
-\&\|' characters, followed by the file name, line number
-and character position separated by colons, and a newline. The
-Emacs-to-GDB interface program uses the two `\|\c
-.B \032\c
-\&\|' characters as
-a signal to display the source code for the frame.
-
-.TP
-.BI "\-b " "bps"\c
-\&
-Set the line speed (baud rate or bits per second) of any serial
-interface used by GDB for remote debugging.
-
-.TP
-.BI "\-tty=" "device"\c
-\&
-Run using \c
-.I device\c
-\& for your program's standard input and output.
-.PP
-
-.SH "SEE ALSO"
-.RB "`\|" gdb "\|'"
-entry in
-.B info\c
-\&;
-.I
-Using GDB: A Guide to the GNU Source-Level Debugger\c
-, Richard M. Stallman and Roland H. Pesch, July 1991.
-.SH COPYING
-Copyright (c) 1991, 2010 Free Software Foundation, Inc.
-.PP
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
-.PP
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, provided that the
-entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
-.PP
-Permission is granted to copy and distribute translations of this
-manual into another language, under the above conditions for modified
-versions, except that this permission notice may be included in
-translations approved by the Free Software Foundation instead of in
-the original English.
diff --git a/share/man/man1/arm-eabi-gdbtui.1 b/share/man/man1/arm-eabi-gdbtui.1
deleted file mode 100644
index d14eb78..0000000
--- a/share/man/man1/arm-eabi-gdbtui.1
+++ /dev/null
@@ -1,381 +0,0 @@
-.\" Copyright (C) 1991, 1999, 2010, 2011 Free Software Foundation, Inc.
-.\" See section COPYING for conditions for redistribution
-.\" $Id: gdb.1,v 1.4 1999/01/05 00:50:50 jsm Exp $
-.TH gdb 1 "22may2002" "GNU Tools" "GNU Tools"
-.SH NAME
-gdb \- The GNU Debugger
-.SH SYNOPSIS
-.na
-.TP
-.B gdb
-.RB "[\|" \-help "\|]"
-.RB "[\|" \-nx "\|]"
-.RB "[\|" \-q "\|]"
-.RB "[\|" \-batch "\|]"
-.RB "[\|" \-cd=\c
-.I dir\c
-\|]
-.RB "[\|" \-f "\|]"
-.RB "[\|" "\-b\ "\c
-.IR bps "\|]"
-.RB "[\|" "\-tty="\c
-.IR dev "\|]"
-.RB "[\|" "\-s "\c
-.I symfile\c
-\&\|]
-.RB "[\|" "\-e "\c
-.I prog\c
-\&\|]
-.RB "[\|" "\-se "\c
-.I prog\c
-\&\|]
-.RB "[\|" "\-c "\c
-.I core\c
-\&\|]
-.RB "[\|" "\-x "\c
-.I cmds\c
-\&\|]
-.RB "[\|" "\-d "\c
-.I dir\c
-\&\|]
-.RB "[\|" \c
-.I prog\c
-.RB "[\|" \c
-.IR core \||\| procID\c
-\&\|]\&\|]
-.ad b
-.SH DESCRIPTION
-The purpose of a debugger such as GDB is to allow you to see what is
-going on ``inside'' another program while it executes\(em\&or what another
-program was doing at the moment it crashed.
-
-GDB can do four main kinds of things (plus other things in support of
-these) to help you catch bugs in the act:
-
-.TP
-\ \ \ \(bu
-Start your program, specifying anything that might affect its behavior.
-
-.TP
-\ \ \ \(bu
-Make your program stop on specified conditions.
-
-.TP
-\ \ \ \(bu
-Examine what has happened, when your program has stopped.
-
-.TP
-\ \ \ \(bu
-Change things in your program, so you can experiment with correcting the
-effects of one bug and go on to learn about another.
-.PP
-
-You can use GDB to debug programs written in C, C++, and Modula-2.
-Fortran support will be added when a GNU Fortran compiler is ready.
-
-GDB is invoked with the shell command \c
-.B gdb\c
-\&. Once started, it reads
-commands from the terminal until you tell it to exit with the GDB
-command \c
-.B quit\c
-\&. You can get online help from \c
-.B gdb\c
-\& itself
-by using the command \c
-.B help\c
-\&.
-
-You can run \c
-.B gdb\c
-\& with no arguments or options; but the most
-usual way to start GDB is with one argument or two, specifying an
-executable program as the argument:
-.sp
-.br
-gdb\ program
-.br
-.sp
-
-You can also start with both an executable program and a core file specified:
-.sp
-.br
-gdb\ program\ core
-.br
-.sp
-
-You can, instead, specify a process ID as a second argument, if you want
-to debug a running process:
-.sp
-.br
-gdb\ program\ 1234
-.br
-.sp
-
-would attach GDB to process \c
-.B 1234\c
-\& (unless you also have a file
-named `\|\c
-.B 1234\c
-\&\|'; GDB does check for a core file first).
-
-Here are some of the most frequently needed GDB commands:
-.TP
-.B break \fR[\|\fIfile\fB:\fR\|]\fIfunction
-\&
-Set a breakpoint at \c
-.I function\c
-\& (in \c
-.I file\c
-\&).
-.TP
-.B run \fR[\|\fIarglist\fR\|]
-Start your program (with \c
-.I arglist\c
-\&, if specified).
-.TP
-.B bt
-Backtrace: display the program stack.
-.TP
-.BI print " expr"\c
-\&
-Display the value of an expression.
-.TP
-.B c
-Continue running your program (after stopping, e.g. at a breakpoint).
-.TP
-.B next
-Execute next program line (after stopping); step \c
-.I over\c
-\& any
-function calls in the line.
-.TP
-.B edit \fR[\|\fIfile\fB:\fR\|]\fIfunction
-look at the program line where it is presently stopped.
-.TP
-.B list \fR[\|\fIfile\fB:\fR\|]\fIfunction
-type the text of the program in the vicinity of where it is presently stopped.
-.TP
-.B step
-Execute next program line (after stopping); step \c
-.I into\c
-\& any
-function calls in the line.
-.TP
-.B help \fR[\|\fIname\fR\|]
-Show information about GDB command \c
-.I name\c
-\&, or general information
-about using GDB.
-.TP
-.B quit
-Exit from GDB.
-.PP
-For full details on GDB, see \c
-.I
-Using GDB: A Guide to the GNU Source-Level Debugger\c
-\&, by Richard M. Stallman and Roland H. Pesch. The same text is available online
-as the \c
-.B gdb\c
-\& entry in the \c
-.B info\c
-\& program.
-.SH OPTIONS
-Any arguments other than options specify an executable
-file and core file (or process ID); that is, the first argument
-encountered with no
-associated option flag is equivalent to a `\|\c
-.B \-se\c
-\&\|' option, and the
-second, if any, is equivalent to a `\|\c
-.B \-c\c
-\&\|' option if it's the name of a file. Many options have
-both long and short forms; both are shown here. The long forms are also
-recognized if you truncate them, so long as enough of the option is
-present to be unambiguous. (If you prefer, you can flag option
-arguments with `\|\c
-.B +\c
-\&\|' rather than `\|\c
-.B \-\c
-\&\|', though we illustrate the
-more usual convention.)
-
-All the options and command line arguments you give are processed
-in sequential order. The order makes a difference when the
-`\|\c
-.B \-x\c
-\&\|' option is used.
-
-.TP
-.B \-help
-.TP
-.B \-h
-List all options, with brief explanations.
-
-.TP
-.BI "\-symbols=" "file"\c
-.TP
-.BI "\-s " "file"\c
-\&
-Read symbol table from file \c
-.I file\c
-\&.
-
-.TP
-.B \-write
-Enable writing into executable and core files.
-
-.TP
-.BI "\-exec=" "file"\c
-.TP
-.BI "\-e " "file"\c
-\&
-Use file \c
-.I file\c
-\& as the executable file to execute when
-appropriate, and for examining pure data in conjunction with a core
-dump.
-
-.TP
-.BI "\-se=" "file"\c
-\&
-Read symbol table from file \c
-.I file\c
-\& and use it as the executable
-file.
-
-.TP
-.BI "\-core=" "file"\c
-.TP
-.BI "\-c " "file"\c
-\&
-Use file \c
-.I file\c
-\& as a core dump to examine.
-
-.TP
-.BI "\-command=" "file"\c
-.TP
-.BI "\-x " "file"\c
-\&
-Execute GDB commands from file \c
-.I file\c
-\&.
-
-.TP
-.BI "\-directory=" "directory"\c
-.TP
-.BI "\-d " "directory"\c
-\&
-Add \c
-.I directory\c
-\& to the path to search for source files.
-.PP
-
-.TP
-.B \-nx
-.TP
-.B \-n
-Do not execute commands from any `\|\c
-.B .gdbinit\c
-\&\|' initialization files.
-Normally, the commands in these files are executed after all the
-command options and arguments have been processed.
-
-
-.TP
-.B \-quiet
-.TP
-.B \-q
-``Quiet''. Do not print the introductory and copyright messages. These
-messages are also suppressed in batch mode.
-
-.TP
-.B \-batch
-Run in batch mode. Exit with status \c
-.B 0\c
-\& after processing all the command
-files specified with `\|\c
-.B \-x\c
-\&\|' (and `\|\c
-.B .gdbinit\c
-\&\|', if not inhibited).
-Exit with nonzero status if an error occurs in executing the GDB
-commands in the command files.
-
-Batch mode may be useful for running GDB as a filter, for example to
-download and run a program on another computer; in order to make this
-more useful, the message
-.sp
-.br
-Program\ exited\ normally.
-.br
-.sp
-
-(which is ordinarily issued whenever a program running under GDB control
-terminates) is not issued when running in batch mode.
-
-.TP
-.BI "\-cd=" "directory"\c
-\&
-Run GDB using \c
-.I directory\c
-\& as its working directory,
-instead of the current directory.
-
-.TP
-.B \-fullname
-.TP
-.B \-f
-Emacs sets this option when it runs GDB as a subprocess. It tells GDB
-to output the full file name and line number in a standard,
-recognizable fashion each time a stack frame is displayed (which
-includes each time the program stops). This recognizable format looks
-like two `\|\c
-.B \032\c
-\&\|' characters, followed by the file name, line number
-and character position separated by colons, and a newline. The
-Emacs-to-GDB interface program uses the two `\|\c
-.B \032\c
-\&\|' characters as
-a signal to display the source code for the frame.
-
-.TP
-.BI "\-b " "bps"\c
-\&
-Set the line speed (baud rate or bits per second) of any serial
-interface used by GDB for remote debugging.
-
-.TP
-.BI "\-tty=" "device"\c
-\&
-Run using \c
-.I device\c
-\& for your program's standard input and output.
-.PP
-
-.SH "SEE ALSO"
-.RB "`\|" gdb "\|'"
-entry in
-.B info\c
-\&;
-.I
-Using GDB: A Guide to the GNU Source-Level Debugger\c
-, Richard M. Stallman and Roland H. Pesch, July 1991.
-.SH COPYING
-Copyright (c) 1991, 2010 Free Software Foundation, Inc.
-.PP
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
-.PP
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, provided that the
-entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
-.PP
-Permission is granted to copy and distribute translations of this
-manual into another language, under the above conditions for modified
-versions, except that this permission notice may be included in
-translations approved by the Free Software Foundation instead of in
-the original English.
diff --git a/share/man/man1/arm-eabi-gprof.1 b/share/man/man1/arm-eabi-gprof.1
deleted file mode 100644
index bf7b523..0000000
--- a/share/man/man1/arm-eabi-gprof.1
+++ /dev/null
@@ -1,757 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "GPROF 1"
-.TH GPROF 1 " " "binutils-2.21" "GNU"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-gprof \- display call graph profile data
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-gprof [ \-[abcDhilLrsTvwxyz] ] [ \-[ACeEfFJnNOpPqQZ][\fIname\fR] ]
- [ \-I \fIdirs\fR ] [ \-d[\fInum\fR] ] [ \-k \fIfrom/to\fR ]
- [ \-m \fImin-count\fR ] [ \-R \fImap_file\fR ] [ \-t \fItable-length\fR ]
- [ \-\-[no\-]annotated\-source[=\fIname\fR] ]
- [ \-\-[no\-]exec\-counts[=\fIname\fR] ]
- [ \-\-[no\-]flat\-profile[=\fIname\fR] ] [ \-\-[no\-]graph[=\fIname\fR] ]
- [ \-\-[no\-]time=\fIname\fR] [ \-\-all\-lines ] [ \-\-brief ]
- [ \-\-debug[=\fIlevel\fR] ] [ \-\-function\-ordering ]
- [ \-\-file\-ordering \fImap_file\fR ] [ \-\-directory\-path=\fIdirs\fR ]
- [ \-\-display\-unused\-functions ] [ \-\-file\-format=\fIname\fR ]
- [ \-\-file\-info ] [ \-\-help ] [ \-\-line ] [ \-\-min\-count=\fIn\fR ]
- [ \-\-no\-static ] [ \-\-print\-path ] [ \-\-separate\-files ]
- [ \-\-static\-call\-graph ] [ \-\-sum ] [ \-\-table\-length=\fIlen\fR ]
- [ \-\-traditional ] [ \-\-version ] [ \-\-width=\fIn\fR ]
- [ \-\-ignore\-non\-functions ] [ \-\-demangle[=\fI\s-1STYLE\s0\fR] ]
- [ \-\-no\-demangle ] [\-\-external\-symbol\-table=name]
- [ \fIimage-file\fR ] [ \fIprofile-file\fR ... ]
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\f(CW\*(C`gprof\*(C'\fR produces an execution profile of C, Pascal, or Fortran77
-programs. The effect of called routines is incorporated in the profile
-of each caller. The profile data is taken from the call graph profile file
-(\fIgmon.out\fR default) which is created by programs
-that are compiled with the \fB\-pg\fR option of
-\&\f(CW\*(C`cc\*(C'\fR, \f(CW\*(C`pc\*(C'\fR, and \f(CW\*(C`f77\*(C'\fR.
-The \fB\-pg\fR option also links in versions of the library routines
-that are compiled for profiling. \f(CW\*(C`Gprof\*(C'\fR reads the given object
-file (the default is \f(CW\*(C`a.out\*(C'\fR) and establishes the relation between
-its symbol table and the call graph profile from \fIgmon.out\fR.
-If more than one profile file is specified, the \f(CW\*(C`gprof\*(C'\fR
-output shows the sum of the profile information in the given profile files.
-.PP
-\&\f(CW\*(C`Gprof\*(C'\fR calculates the amount of time spent in each routine.
-Next, these times are propagated along the edges of the call graph.
-Cycles are discovered, and calls into a cycle are made to share the time
-of the cycle.
-.PP
-Several forms of output are available from the analysis.
-.PP
-The \fIflat profile\fR shows how much time your program spent in each function,
-and how many times that function was called. If you simply want to know
-which functions burn most of the cycles, it is stated concisely here.
-.PP
-The \fIcall graph\fR shows, for each function, which functions called it, which
-other functions it called, and how many times. There is also an estimate
-of how much time was spent in the subroutines of each function. This can
-suggest places where you might try to eliminate function calls that use a
-lot of time.
-.PP
-The \fIannotated source\fR listing is a copy of the program's
-source code, labeled with the number of times each line of the
-program was executed.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-These options specify which of several output formats
-\&\f(CW\*(C`gprof\*(C'\fR should produce.
-.PP
-Many of these options take an optional \fIsymspec\fR to specify
-functions to be included or excluded. These options can be
-specified multiple times, with different symspecs, to include
-or exclude sets of symbols.
-.PP
-Specifying any of these options overrides the default (\fB\-p \-q\fR),
-which prints a flat profile and call graph analysis
-for all functions.
-.ie n .IP """\-A[\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-A[\f(CIsymspec\f(CW]\fR" 4
-.IX Item "-A[symspec]"
-.PD 0
-.ie n .IP """\-\-annotated\-source[=\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-\-annotated\-source[=\f(CIsymspec\f(CW]\fR" 4
-.IX Item "--annotated-source[=symspec]"
-.PD
-The \fB\-A\fR option causes \f(CW\*(C`gprof\*(C'\fR to print annotated source code.
-If \fIsymspec\fR is specified, print output only for matching symbols.
-.ie n .IP """\-b""" 4
-.el .IP "\f(CW\-b\fR" 4
-.IX Item "-b"
-.PD 0
-.ie n .IP """\-\-brief""" 4
-.el .IP "\f(CW\-\-brief\fR" 4
-.IX Item "--brief"
-.PD
-If the \fB\-b\fR option is given, \f(CW\*(C`gprof\*(C'\fR doesn't print the
-verbose blurbs that try to explain the meaning of all of the fields in
-the tables. This is useful if you intend to print out the output, or
-are tired of seeing the blurbs.
-.ie n .IP """\-C[\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-C[\f(CIsymspec\f(CW]\fR" 4
-.IX Item "-C[symspec]"
-.PD 0
-.ie n .IP """\-\-exec\-counts[=\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-\-exec\-counts[=\f(CIsymspec\f(CW]\fR" 4
-.IX Item "--exec-counts[=symspec]"
-.PD
-The \fB\-C\fR option causes \f(CW\*(C`gprof\*(C'\fR to
-print a tally of functions and the number of times each was called.
-If \fIsymspec\fR is specified, print tally only for matching symbols.
-.Sp
-If the profile data file contains basic-block count records, specifying
-the \fB\-l\fR option, along with \fB\-C\fR, will cause basic-block
-execution counts to be tallied and displayed.
-.ie n .IP """\-i""" 4
-.el .IP "\f(CW\-i\fR" 4
-.IX Item "-i"
-.PD 0
-.ie n .IP """\-\-file\-info""" 4
-.el .IP "\f(CW\-\-file\-info\fR" 4
-.IX Item "--file-info"
-.PD
-The \fB\-i\fR option causes \f(CW\*(C`gprof\*(C'\fR to display summary information
-about the profile data file(s) and then exit. The number of histogram,
-call graph, and basic-block count records is displayed.
-.ie n .IP """\-I \f(CIdirs\f(CW""" 4
-.el .IP "\f(CW\-I \f(CIdirs\f(CW\fR" 4
-.IX Item "-I dirs"
-.PD 0
-.ie n .IP """\-\-directory\-path=\f(CIdirs\f(CW""" 4
-.el .IP "\f(CW\-\-directory\-path=\f(CIdirs\f(CW\fR" 4
-.IX Item "--directory-path=dirs"
-.PD
-The \fB\-I\fR option specifies a list of search directories in
-which to find source files. Environment variable \fI\s-1GPROF_PATH\s0\fR
-can also be used to convey this information.
-Used mostly for annotated source output.
-.ie n .IP """\-J[\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-J[\f(CIsymspec\f(CW]\fR" 4
-.IX Item "-J[symspec]"
-.PD 0
-.ie n .IP """\-\-no\-annotated\-source[=\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-\-no\-annotated\-source[=\f(CIsymspec\f(CW]\fR" 4
-.IX Item "--no-annotated-source[=symspec]"
-.PD
-The \fB\-J\fR option causes \f(CW\*(C`gprof\*(C'\fR not to
-print annotated source code.
-If \fIsymspec\fR is specified, \f(CW\*(C`gprof\*(C'\fR prints annotated source,
-but excludes matching symbols.
-.ie n .IP """\-L""" 4
-.el .IP "\f(CW\-L\fR" 4
-.IX Item "-L"
-.PD 0
-.ie n .IP """\-\-print\-path""" 4
-.el .IP "\f(CW\-\-print\-path\fR" 4
-.IX Item "--print-path"
-.PD
-Normally, source filenames are printed with the path
-component suppressed. The \fB\-L\fR option causes \f(CW\*(C`gprof\*(C'\fR
-to print the full pathname of
-source filenames, which is determined
-from symbolic debugging information in the image file
-and is relative to the directory in which the compiler
-was invoked.
-.ie n .IP """\-p[\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-p[\f(CIsymspec\f(CW]\fR" 4
-.IX Item "-p[symspec]"
-.PD 0
-.ie n .IP """\-\-flat\-profile[=\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-\-flat\-profile[=\f(CIsymspec\f(CW]\fR" 4
-.IX Item "--flat-profile[=symspec]"
-.PD
-The \fB\-p\fR option causes \f(CW\*(C`gprof\*(C'\fR to print a flat profile.
-If \fIsymspec\fR is specified, print flat profile only for matching symbols.
-.ie n .IP """\-P[\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-P[\f(CIsymspec\f(CW]\fR" 4
-.IX Item "-P[symspec]"
-.PD 0
-.ie n .IP """\-\-no\-flat\-profile[=\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-\-no\-flat\-profile[=\f(CIsymspec\f(CW]\fR" 4
-.IX Item "--no-flat-profile[=symspec]"
-.PD
-The \fB\-P\fR option causes \f(CW\*(C`gprof\*(C'\fR to suppress printing a flat profile.
-If \fIsymspec\fR is specified, \f(CW\*(C`gprof\*(C'\fR prints a flat profile,
-but excludes matching symbols.
-.ie n .IP """\-q[\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-q[\f(CIsymspec\f(CW]\fR" 4
-.IX Item "-q[symspec]"
-.PD 0
-.ie n .IP """\-\-graph[=\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-\-graph[=\f(CIsymspec\f(CW]\fR" 4
-.IX Item "--graph[=symspec]"
-.PD
-The \fB\-q\fR option causes \f(CW\*(C`gprof\*(C'\fR to print the call graph analysis.
-If \fIsymspec\fR is specified, print call graph only for matching symbols
-and their children.
-.ie n .IP """\-Q[\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-Q[\f(CIsymspec\f(CW]\fR" 4
-.IX Item "-Q[symspec]"
-.PD 0
-.ie n .IP """\-\-no\-graph[=\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-\-no\-graph[=\f(CIsymspec\f(CW]\fR" 4
-.IX Item "--no-graph[=symspec]"
-.PD
-The \fB\-Q\fR option causes \f(CW\*(C`gprof\*(C'\fR to suppress printing the
-call graph.
-If \fIsymspec\fR is specified, \f(CW\*(C`gprof\*(C'\fR prints a call graph,
-but excludes matching symbols.
-.ie n .IP """\-t""" 4
-.el .IP "\f(CW\-t\fR" 4
-.IX Item "-t"
-.PD 0
-.ie n .IP """\-\-table\-length=\f(CInum\f(CW""" 4
-.el .IP "\f(CW\-\-table\-length=\f(CInum\f(CW\fR" 4
-.IX Item "--table-length=num"
-.PD
-The \fB\-t\fR option causes the \fInum\fR most active source lines in
-each source file to be listed when source annotation is enabled. The
-default is 10.
-.ie n .IP """\-y""" 4
-.el .IP "\f(CW\-y\fR" 4
-.IX Item "-y"
-.PD 0
-.ie n .IP """\-\-separate\-files""" 4
-.el .IP "\f(CW\-\-separate\-files\fR" 4
-.IX Item "--separate-files"
-.PD
-This option affects annotated source output only.
-Normally, \f(CW\*(C`gprof\*(C'\fR prints annotated source files
-to standard-output. If this option is specified,
-annotated source for a file named \fIpath/\fIfilename\fI\fR
-is generated in the file \fI\fIfilename\fI\-ann\fR. If the underlying
-file system would truncate \fI\fIfilename\fI\-ann\fR so that it
-overwrites the original \fI\fIfilename\fI\fR, \f(CW\*(C`gprof\*(C'\fR generates
-annotated source in the file \fI\fIfilename\fI.ann\fR instead (if the
-original file name has an extension, that extension is \fIreplaced\fR
-with \fI.ann\fR).
-.ie n .IP """\-Z[\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-Z[\f(CIsymspec\f(CW]\fR" 4
-.IX Item "-Z[symspec]"
-.PD 0
-.ie n .IP """\-\-no\-exec\-counts[=\f(CIsymspec\f(CW]""" 4
-.el .IP "\f(CW\-\-no\-exec\-counts[=\f(CIsymspec\f(CW]\fR" 4
-.IX Item "--no-exec-counts[=symspec]"
-.PD
-The \fB\-Z\fR option causes \f(CW\*(C`gprof\*(C'\fR not to
-print a tally of functions and the number of times each was called.
-If \fIsymspec\fR is specified, print tally, but exclude matching symbols.
-.ie n .IP """\-r""" 4
-.el .IP "\f(CW\-r\fR" 4
-.IX Item "-r"
-.PD 0
-.ie n .IP """\-\-function\-ordering""" 4
-.el .IP "\f(CW\-\-function\-ordering\fR" 4
-.IX Item "--function-ordering"
-.PD
-The \fB\-\-function\-ordering\fR option causes \f(CW\*(C`gprof\*(C'\fR to print a
-suggested function ordering for the program based on profiling data.
-This option suggests an ordering which may improve paging, tlb and
-cache behavior for the program on systems which support arbitrary
-ordering of functions in an executable.
-.Sp
-The exact details of how to force the linker to place functions
-in a particular order is system dependent and out of the scope of this
-manual.
-.ie n .IP """\-R \f(CImap_file\f(CW""" 4
-.el .IP "\f(CW\-R \f(CImap_file\f(CW\fR" 4
-.IX Item "-R map_file"
-.PD 0
-.ie n .IP """\-\-file\-ordering \f(CImap_file\f(CW""" 4
-.el .IP "\f(CW\-\-file\-ordering \f(CImap_file\f(CW\fR" 4
-.IX Item "--file-ordering map_file"
-.PD
-The \fB\-\-file\-ordering\fR option causes \f(CW\*(C`gprof\*(C'\fR to print a
-suggested .o link line ordering for the program based on profiling data.
-This option suggests an ordering which may improve paging, tlb and
-cache behavior for the program on systems which do not support arbitrary
-ordering of functions in an executable.
-.Sp
-Use of the \fB\-a\fR argument is highly recommended with this option.
-.Sp
-The \fImap_file\fR argument is a pathname to a file which provides
-function name to object file mappings. The format of the file is similar to
-the output of the program \f(CW\*(C`nm\*(C'\fR.
-.Sp
-.Vb 8
-\& c\-parse.o:00000000 T yyparse
-\& c\-parse.o:00000004 C yyerrflag
-\& c\-lang.o:00000000 T maybe_objc_method_name
-\& c\-lang.o:00000000 T print_lang_statistics
-\& c\-lang.o:00000000 T recognize_objc_keyword
-\& c\-decl.o:00000000 T print_lang_identifier
-\& c\-decl.o:00000000 T print_lang_type
-\& ...
-.Ve
-.Sp
-To create a \fImap_file\fR with \s-1GNU\s0 \f(CW\*(C`nm\*(C'\fR, type a command like
-\&\f(CW\*(C`nm \-\-extern\-only \-\-defined\-only \-v \-\-print\-file\-name program\-name\*(C'\fR.
-.ie n .IP """\-T""" 4
-.el .IP "\f(CW\-T\fR" 4
-.IX Item "-T"
-.PD 0
-.ie n .IP """\-\-traditional""" 4
-.el .IP "\f(CW\-\-traditional\fR" 4
-.IX Item "--traditional"
-.PD
-The \fB\-T\fR option causes \f(CW\*(C`gprof\*(C'\fR to print its output in
-\&\*(L"traditional\*(R" \s-1BSD\s0 style.
-.ie n .IP """\-w \f(CIwidth\f(CW""" 4
-.el .IP "\f(CW\-w \f(CIwidth\f(CW\fR" 4
-.IX Item "-w width"
-.PD 0
-.ie n .IP """\-\-width=\f(CIwidth\f(CW""" 4
-.el .IP "\f(CW\-\-width=\f(CIwidth\f(CW\fR" 4
-.IX Item "--width=width"
-.PD
-Sets width of output lines to \fIwidth\fR.
-Currently only used when printing the function index at the bottom
-of the call graph.
-.ie n .IP """\-x""" 4
-.el .IP "\f(CW\-x\fR" 4
-.IX Item "-x"
-.PD 0
-.ie n .IP """\-\-all\-lines""" 4
-.el .IP "\f(CW\-\-all\-lines\fR" 4
-.IX Item "--all-lines"
-.PD
-This option affects annotated source output only.
-By default, only the lines at the beginning of a basic-block
-are annotated. If this option is specified, every line in
-a basic-block is annotated by repeating the annotation for the
-first line. This behavior is similar to \f(CW\*(C`tcov\*(C'\fR's \fB\-a\fR.
-.ie n .IP """\-\-demangle[=\f(CIstyle\f(CW]""" 4
-.el .IP "\f(CW\-\-demangle[=\f(CIstyle\f(CW]\fR" 4
-.IX Item "--demangle[=style]"
-.PD 0
-.ie n .IP """\-\-no\-demangle""" 4
-.el .IP "\f(CW\-\-no\-demangle\fR" 4
-.IX Item "--no-demangle"
-.PD
-These options control whether \*(C+ symbol names should be demangled when
-printing output. The default is to demangle symbols. The
-\&\f(CW\*(C`\-\-no\-demangle\*(C'\fR option may be used to turn off demangling. Different
-compilers have different mangling styles. The optional demangling style
-argument can be used to choose an appropriate demangling style for your
-compiler.
-.SS "Analysis Options"
-.IX Subsection "Analysis Options"
-.ie n .IP """\-a""" 4
-.el .IP "\f(CW\-a\fR" 4
-.IX Item "-a"
-.PD 0
-.ie n .IP """\-\-no\-static""" 4
-.el .IP "\f(CW\-\-no\-static\fR" 4
-.IX Item "--no-static"
-.PD
-The \fB\-a\fR option causes \f(CW\*(C`gprof\*(C'\fR to suppress the printing of
-statically declared (private) functions. (These are functions whose
-names are not listed as global, and which are not visible outside the
-file/function/block where they were defined.) Time spent in these
-functions, calls to/from them, etc., will all be attributed to the
-function that was loaded directly before it in the executable file.
-This option affects both the flat profile and the call graph.
-.ie n .IP """\-c""" 4
-.el .IP "\f(CW\-c\fR" 4
-.IX Item "-c"
-.PD 0
-.ie n .IP """\-\-static\-call\-graph""" 4
-.el .IP "\f(CW\-\-static\-call\-graph\fR" 4
-.IX Item "--static-call-graph"
-.PD
-The \fB\-c\fR option causes the call graph of the program to be
-augmented by a heuristic which examines the text space of the object
-file and identifies function calls in the binary machine code.
-Since normal call graph records are only generated when functions are
-entered, this option identifies children that could have been called,
-but never were. Calls to functions that were not compiled with
-profiling enabled are also identified, but only if symbol table
-entries are present for them.
-Calls to dynamic library routines are typically \fInot\fR found
-by this option.
-Parents or children identified via this heuristic
-are indicated in the call graph with call counts of \fB0\fR.
-.ie n .IP """\-D""" 4
-.el .IP "\f(CW\-D\fR" 4
-.IX Item "-D"
-.PD 0
-.ie n .IP """\-\-ignore\-non\-functions""" 4
-.el .IP "\f(CW\-\-ignore\-non\-functions\fR" 4
-.IX Item "--ignore-non-functions"
-.PD
-The \fB\-D\fR option causes \f(CW\*(C`gprof\*(C'\fR to ignore symbols which
-are not known to be functions. This option will give more accurate
-profile data on systems where it is supported (Solaris and \s-1HPUX\s0 for
-example).
-.ie n .IP """\-k \f(CIfrom\f(CW/\f(CIto\f(CW""" 4
-.el .IP "\f(CW\-k \f(CIfrom\f(CW/\f(CIto\f(CW\fR" 4
-.IX Item "-k from/to"
-The \fB\-k\fR option allows you to delete from the call graph any arcs from
-symbols matching symspec \fIfrom\fR to those matching symspec \fIto\fR.
-.ie n .IP """\-l""" 4
-.el .IP "\f(CW\-l\fR" 4
-.IX Item "-l"
-.PD 0
-.ie n .IP """\-\-line""" 4
-.el .IP "\f(CW\-\-line\fR" 4
-.IX Item "--line"
-.PD
-The \fB\-l\fR option enables line-by-line profiling, which causes
-histogram hits to be charged to individual source code lines,
-instead of functions. This feature only works with programs compiled
-by older versions of the \f(CW\*(C`gcc\*(C'\fR compiler. Newer versions of
-\&\f(CW\*(C`gcc\*(C'\fR are designed to work with the \f(CW\*(C`gcov\*(C'\fR tool instead.
-.Sp
-If the program was compiled with basic-block counting enabled,
-this option will also identify how many times each line of
-code was executed.
-While line-by-line profiling can help isolate where in a large function
-a program is spending its time, it also significantly increases
-the running time of \f(CW\*(C`gprof\*(C'\fR, and magnifies statistical
-inaccuracies.
-.ie n .IP """\-m \f(CInum\f(CW""" 4
-.el .IP "\f(CW\-m \f(CInum\f(CW\fR" 4
-.IX Item "-m num"
-.PD 0
-.ie n .IP """\-\-min\-count=\f(CInum\f(CW""" 4
-.el .IP "\f(CW\-\-min\-count=\f(CInum\f(CW\fR" 4
-.IX Item "--min-count=num"
-.PD
-This option affects execution count output only.
-Symbols that are executed less than \fInum\fR times are suppressed.
-.ie n .IP """\-n\f(CIsymspec\f(CW""" 4
-.el .IP "\f(CW\-n\f(CIsymspec\f(CW\fR" 4
-.IX Item "-nsymspec"
-.PD 0
-.ie n .IP """\-\-time=\f(CIsymspec\f(CW""" 4
-.el .IP "\f(CW\-\-time=\f(CIsymspec\f(CW\fR" 4
-.IX Item "--time=symspec"
-.PD
-The \fB\-n\fR option causes \f(CW\*(C`gprof\*(C'\fR, in its call graph analysis,
-to only propagate times for symbols matching \fIsymspec\fR.
-.ie n .IP """\-N\f(CIsymspec\f(CW""" 4
-.el .IP "\f(CW\-N\f(CIsymspec\f(CW\fR" 4
-.IX Item "-Nsymspec"
-.PD 0
-.ie n .IP """\-\-no\-time=\f(CIsymspec\f(CW""" 4
-.el .IP "\f(CW\-\-no\-time=\f(CIsymspec\f(CW\fR" 4
-.IX Item "--no-time=symspec"
-.PD
-The \fB\-n\fR option causes \f(CW\*(C`gprof\*(C'\fR, in its call graph analysis,
-not to propagate times for symbols matching \fIsymspec\fR.
-.ie n .IP """\-S\f(CIfilename\f(CW""" 4
-.el .IP "\f(CW\-S\f(CIfilename\f(CW\fR" 4
-.IX Item "-Sfilename"
-.PD 0
-.ie n .IP """\-\-external\-symbol\-table=\f(CIfilename\f(CW""" 4
-.el .IP "\f(CW\-\-external\-symbol\-table=\f(CIfilename\f(CW\fR" 4
-.IX Item "--external-symbol-table=filename"
-.PD
-The \fB\-S\fR option causes \f(CW\*(C`gprof\*(C'\fR to read an external symbol table
-file, such as \fI/proc/kallsyms\fR, rather than read the symbol table
-from the given object file (the default is \f(CW\*(C`a.out\*(C'\fR). This is useful
-for profiling kernel modules.
-.ie n .IP """\-z""" 4
-.el .IP "\f(CW\-z\fR" 4
-.IX Item "-z"
-.PD 0
-.ie n .IP """\-\-display\-unused\-functions""" 4
-.el .IP "\f(CW\-\-display\-unused\-functions\fR" 4
-.IX Item "--display-unused-functions"
-.PD
-If you give the \fB\-z\fR option, \f(CW\*(C`gprof\*(C'\fR will mention all
-functions in the flat profile, even those that were never called, and
-that had no time spent in them. This is useful in conjunction with the
-\&\fB\-c\fR option for discovering which routines were never called.
-.SS "Miscellaneous Options"
-.IX Subsection "Miscellaneous Options"
-.ie n .IP """\-d[\f(CInum\f(CW]""" 4
-.el .IP "\f(CW\-d[\f(CInum\f(CW]\fR" 4
-.IX Item "-d[num]"
-.PD 0
-.ie n .IP """\-\-debug[=\f(CInum\f(CW]""" 4
-.el .IP "\f(CW\-\-debug[=\f(CInum\f(CW]\fR" 4
-.IX Item "--debug[=num]"
-.PD
-The \fB\-d\fR \fInum\fR option specifies debugging options.
-If \fInum\fR is not specified, enable all debugging.
-.ie n .IP """\-h""" 4
-.el .IP "\f(CW\-h\fR" 4
-.IX Item "-h"
-.PD 0
-.ie n .IP """\-\-help""" 4
-.el .IP "\f(CW\-\-help\fR" 4
-.IX Item "--help"
-.PD
-The \fB\-h\fR option prints command line usage.
-.ie n .IP """\-O\f(CIname\f(CW""" 4
-.el .IP "\f(CW\-O\f(CIname\f(CW\fR" 4
-.IX Item "-Oname"
-.PD 0
-.ie n .IP """\-\-file\-format=\f(CIname\f(CW""" 4
-.el .IP "\f(CW\-\-file\-format=\f(CIname\f(CW\fR" 4
-.IX Item "--file-format=name"
-.PD
-Selects the format of the profile data files. Recognized formats are
-\&\fBauto\fR (the default), \fBbsd\fR, \fB4.4bsd\fR, \fBmagic\fR, and
-\&\fBprof\fR (not yet supported).
-.ie n .IP """\-s""" 4
-.el .IP "\f(CW\-s\fR" 4
-.IX Item "-s"
-.PD 0
-.ie n .IP """\-\-sum""" 4
-.el .IP "\f(CW\-\-sum\fR" 4
-.IX Item "--sum"
-.PD
-The \fB\-s\fR option causes \f(CW\*(C`gprof\*(C'\fR to summarize the information
-in the profile data files it read in, and write out a profile data
-file called \fIgmon.sum\fR, which contains all the information from
-the profile data files that \f(CW\*(C`gprof\*(C'\fR read in. The file \fIgmon.sum\fR
-may be one of the specified input files; the effect of this is to
-merge the data in the other input files into \fIgmon.sum\fR.
-.Sp
-Eventually you can run \f(CW\*(C`gprof\*(C'\fR again without \fB\-s\fR to analyze the
-cumulative data in the file \fIgmon.sum\fR.
-.ie n .IP """\-v""" 4
-.el .IP "\f(CW\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.ie n .IP """\-\-version""" 4
-.el .IP "\f(CW\-\-version\fR" 4
-.IX Item "--version"
-.PD
-The \fB\-v\fR flag causes \f(CW\*(C`gprof\*(C'\fR to print the current version
-number, and then exit.
-.SS "Deprecated Options"
-.IX Subsection "Deprecated Options"
-These options have been replaced with newer versions that use symspecs.
-.ie n .IP """\-e \f(CIfunction_name\f(CW""" 4
-.el .IP "\f(CW\-e \f(CIfunction_name\f(CW\fR" 4
-.IX Item "-e function_name"
-The \fB\-e\fR \fIfunction\fR option tells \f(CW\*(C`gprof\*(C'\fR to not print
-information about the function \fIfunction_name\fR (and its
-children...) in the call graph. The function will still be listed
-as a child of any functions that call it, but its index number will be
-shown as \fB[not printed]\fR. More than one \fB\-e\fR option may be
-given; only one \fIfunction_name\fR may be indicated with each \fB\-e\fR
-option.
-.ie n .IP """\-E \f(CIfunction_name\f(CW""" 4
-.el .IP "\f(CW\-E \f(CIfunction_name\f(CW\fR" 4
-.IX Item "-E function_name"
-The \f(CW\*(C`\-E \f(CIfunction\f(CW\*(C'\fR option works like the \f(CW\*(C`\-e\*(C'\fR option, but
-time spent in the function (and children who were not called from
-anywhere else), will not be used to compute the percentages-of-time for
-the call graph. More than one \fB\-E\fR option may be given; only one
-\&\fIfunction_name\fR may be indicated with each \fB\-E\fR option.
-.ie n .IP """\-f \f(CIfunction_name\f(CW""" 4
-.el .IP "\f(CW\-f \f(CIfunction_name\f(CW\fR" 4
-.IX Item "-f function_name"
-The \fB\-f\fR \fIfunction\fR option causes \f(CW\*(C`gprof\*(C'\fR to limit the
-call graph to the function \fIfunction_name\fR and its children (and
-their children...). More than one \fB\-f\fR option may be given;
-only one \fIfunction_name\fR may be indicated with each \fB\-f\fR
-option.
-.ie n .IP """\-F \f(CIfunction_name\f(CW""" 4
-.el .IP "\f(CW\-F \f(CIfunction_name\f(CW\fR" 4
-.IX Item "-F function_name"
-The \fB\-F\fR \fIfunction\fR option works like the \f(CW\*(C`\-f\*(C'\fR option, but
-only time spent in the function and its children (and their
-children...) will be used to determine total-time and
-percentages-of-time for the call graph. More than one \fB\-F\fR option
-may be given; only one \fIfunction_name\fR may be indicated with each
-\&\fB\-F\fR option. The \fB\-F\fR option overrides the \fB\-E\fR option.
-.SH "FILES"
-.IX Header "FILES"
-.ie n .IP """\f(CIa.out\f(CW""" 4
-.el .IP "\f(CW\f(CIa.out\f(CW\fR" 4
-.IX Item "a.out"
-the namelist and text space.
-.ie n .IP """\f(CIgmon.out\f(CW""" 4
-.el .IP "\f(CW\f(CIgmon.out\f(CW\fR" 4
-.IX Item "gmon.out"
-dynamic call graph and profile.
-.ie n .IP """\f(CIgmon.sum\f(CW""" 4
-.el .IP "\f(CW\f(CIgmon.sum\f(CW\fR" 4
-.IX Item "gmon.sum"
-summarized dynamic call graph and profile.
-.SH "BUGS"
-.IX Header "BUGS"
-The granularity of the sampling is shown, but remains
-statistical at best.
-We assume that the time for each execution of a function
-can be expressed by the total time for the function divided
-by the number of times the function is called.
-Thus the time propagated along the call graph arcs to the function's
-parents is directly proportional to the number of times that
-arc is traversed.
-.PP
-Parents that are not themselves profiled will have the time of
-their profiled children propagated to them, but they will appear
-to be spontaneously invoked in the call graph listing, and will
-not have their time propagated further.
-Similarly, signal catchers, even though profiled, will appear
-to be spontaneous (although for more obscure reasons).
-Any profiled children of signal catchers should have their times
-propagated properly, unless the signal catcher was invoked during
-the execution of the profiling routine, in which case all is lost.
-.PP
-The profiled program must call \f(CW\*(C`exit\*(C'\fR(2)
-or return normally for the profiling information to be saved
-in the \fIgmon.out\fR file.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fImonitor\fR\|(3), \fIprofil\fR\|(2), \fIcc\fR\|(1), \fIprof\fR\|(1), and the Info entry for \fIgprof\fR.
-.PP
-\&\*(L"An Execution Profiler for Modular Programs\*(R",
-by S. Graham, P. Kessler, M. McKusick;
-Software \- Practice and Experience,
-Vol. 13, pp. 671\-685, 1983.
-.PP
-\&\*(L"gprof: A Call Graph Execution Profiler\*(R",
-by S. Graham, P. Kessler, M. McKusick;
-Proceedings of the \s-1SIGPLAN\s0 '82 Symposium on Compiler Construction,
-\&\s-1SIGPLAN\s0 Notices, Vol. 17, No 6, pp. 120\-126, June 1982.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1988, 1992, 1997, 1998, 1999, 2000, 2001, 2003,
-2007, 2008, 2009 Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-ld.1 b/share/man/man1/arm-eabi-ld.1
deleted file mode 100644
index 8b5c3d8..0000000
--- a/share/man/man1/arm-eabi-ld.1
+++ /dev/null
@@ -1,2413 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "LD 1"
-.TH LD 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-ld \- The GNU linker
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-ld [\fBoptions\fR] \fIobjfile\fR ...
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\fBld\fR combines a number of object and archive files, relocates
-their data and ties up symbol references. Usually the last step in
-compiling a program is to run \fBld\fR.
-.PP
-\&\fBld\fR accepts Linker Command Language files written in
-a superset of \s-1AT&T\s0's Link Editor Command Language syntax,
-to provide explicit and total control over the linking process.
-.PP
-This man page does not describe the command language; see the
-\&\fBld\fR entry in \f(CW\*(C`info\*(C'\fR for full details on the command
-language and on other aspects of the \s-1GNU\s0 linker.
-.PP
-This version of \fBld\fR uses the general purpose \s-1BFD\s0 libraries
-to operate on object files. This allows \fBld\fR to read, combine, and
-write object files in many different formats\-\-\-for example, \s-1COFF\s0 or
-\&\f(CW\*(C`a.out\*(C'\fR. Different formats may be linked together to produce any
-available kind of object file.
-.PP
-Aside from its flexibility, the \s-1GNU\s0 linker is more helpful than other
-linkers in providing diagnostic information. Many linkers abandon
-execution immediately upon encountering an error; whenever possible,
-\&\fBld\fR continues executing, allowing you to identify other errors
-(or, in some cases, to get an output file in spite of the error).
-.PP
-The \s-1GNU\s0 linker \fBld\fR is meant to cover a broad range of situations,
-and to be as compatible as possible with other linkers. As a result,
-you have many choices to control its behavior.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-The linker supports a plethora of command-line options, but in actual
-practice few of them are used in any particular context.
-For instance, a frequent use of \fBld\fR is to link standard Unix
-object files on a standard, supported Unix system. On such a system, to
-link a file \f(CW\*(C`hello.o\*(C'\fR:
-.PP
-.Vb 1
-\& ld \-o <output> /lib/crt0.o hello.o \-lc
-.Ve
-.PP
-This tells \fBld\fR to produce a file called \fIoutput\fR as the
-result of linking the file \f(CW\*(C`/lib/crt0.o\*(C'\fR with \f(CW\*(C`hello.o\*(C'\fR and
-the library \f(CW\*(C`libc.a\*(C'\fR, which will come from the standard search
-directories. (See the discussion of the \fB\-l\fR option below.)
-.PP
-Some of the command-line options to \fBld\fR may be specified at any
-point in the command line. However, options which refer to files, such
-as \fB\-l\fR or \fB\-T\fR, cause the file to be read at the point at
-which the option appears in the command line, relative to the object
-files and other file options. Repeating non-file options with a
-different argument will either have no further effect, or override prior
-occurrences (those further to the left on the command line) of that
-option. Options which may be meaningfully specified more than once are
-noted in the descriptions below.
-.PP
-Non-option arguments are object files or archives which are to be linked
-together. They may follow, precede, or be mixed in with command-line
-options, except that an object file argument may not be placed between
-an option and its argument.
-.PP
-Usually the linker is invoked with at least one object file, but you can
-specify other forms of binary input files using \fB\-l\fR, \fB\-R\fR,
-and the script command language. If \fIno\fR binary input files at all
-are specified, the linker does not produce any output, and issues the
-message \fBNo input files\fR.
-.PP
-If the linker cannot recognize the format of an object file, it will
-assume that it is a linker script. A script specified in this way
-augments the main linker script used for the link (either the default
-linker script or the one specified by using \fB\-T\fR). This feature
-permits the linker to link against a file which appears to be an object
-or an archive, but actually merely defines some symbol values, or uses
-\&\f(CW\*(C`INPUT\*(C'\fR or \f(CW\*(C`GROUP\*(C'\fR to load other objects. Specifying a
-script in this way merely augments the main linker script, with the
-extra commands placed after the main script; use the \fB\-T\fR option
-to replace the default linker script entirely, but note the effect of
-the \f(CW\*(C`INSERT\*(C'\fR command.
-.PP
-For options whose names are a single letter,
-option arguments must either follow the option letter without intervening
-whitespace, or be given as separate arguments immediately following the
-option that requires them.
-.PP
-For options whose names are multiple letters, either one dash or two can
-precede the option name; for example, \fB\-trace\-symbol\fR and
-\&\fB\-\-trace\-symbol\fR are equivalent. Note\-\-\-there is one exception to
-this rule. Multiple letter options that start with a lower case 'o' can
-only be preceded by two dashes. This is to reduce confusion with the
-\&\fB\-o\fR option. So for example \fB\-omagic\fR sets the output file
-name to \fBmagic\fR whereas \fB\-\-omagic\fR sets the \s-1NMAGIC\s0 flag on the
-output.
-.PP
-Arguments to multiple-letter options must either be separated from the
-option name by an equals sign, or be given as separate arguments
-immediately following the option that requires them. For example,
-\&\fB\-\-trace\-symbol foo\fR and \fB\-\-trace\-symbol=foo\fR are equivalent.
-Unique abbreviations of the names of multiple-letter options are
-accepted.
-.PP
-Note\-\-\-if the linker is being invoked indirectly, via a compiler driver
-(e.g. \fBgcc\fR) then all the linker command line options should be
-prefixed by \fB\-Wl,\fR (or whatever is appropriate for the particular
-compiler driver) like this:
-.PP
-.Vb 1
-\& gcc \-Wl,\-\-start\-group foo.o bar.o \-Wl,\-\-end\-group
-.Ve
-.PP
-This is important, because otherwise the compiler driver program may
-silently drop the linker options, resulting in a bad link. Confusion
-may also arise when passing options that require values through a
-driver, as the use of a space between option and argument acts as
-a separator, and causes the driver to pass only the option to the linker
-and the argument to the compiler. In this case, it is simplest to use
-the joined forms of both single\- and multiple-letter options, such as:
-.PP
-.Vb 1
-\& gcc foo.o bar.o \-Wl,\-eENTRY \-Wl,\-Map=a.map
-.Ve
-.PP
-Here is a table of the generic command line switches accepted by the \s-1GNU\s0
-linker:
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.IP "\fB\-a\fR \fIkeyword\fR" 4
-.IX Item "-a keyword"
-This option is supported for \s-1HP/UX\s0 compatibility. The \fIkeyword\fR
-argument must be one of the strings \fBarchive\fR, \fBshared\fR, or
-\&\fBdefault\fR. \fB\-aarchive\fR is functionally equivalent to
-\&\fB\-Bstatic\fR, and the other two keywords are functionally equivalent
-to \fB\-Bdynamic\fR. This option may be used any number of times.
-.IP "\fB\-\-audit\fR \fI\s-1AUDITLIB\s0\fR" 4
-.IX Item "--audit AUDITLIB"
-Adds \fI\s-1AUDITLIB\s0\fR to the \f(CW\*(C`DT_AUDIT\*(C'\fR entry of the dynamic section.
-\&\fI\s-1AUDITLIB\s0\fR is not checked for existence, nor will it use the \s-1DT_SONAME\s0
-specified in the library. If specified multiple times \f(CW\*(C`DT_AUDIT\*(C'\fR
-will contain a colon separated list of audit interfaces to use. If the linker
-finds an object with an audit entry while searching for shared libraries,
-it will add a corresponding \f(CW\*(C`DT_DEPAUDIT\*(C'\fR entry in the output file.
-This option is only meaningful on \s-1ELF\s0 platforms supporting the rtld-audit
-interface.
-.IP "\fB\-A\fR \fIarchitecture\fR" 4
-.IX Item "-A architecture"
-.PD 0
-.IP "\fB\-\-architecture=\fR\fIarchitecture\fR" 4
-.IX Item "--architecture=architecture"
-.PD
-In the current release of \fBld\fR, this option is useful only for the
-Intel 960 family of architectures. In that \fBld\fR configuration, the
-\&\fIarchitecture\fR argument identifies the particular architecture in
-the 960 family, enabling some safeguards and modifying the
-archive-library search path.
-.Sp
-Future releases of \fBld\fR may support similar functionality for
-other architecture families.
-.IP "\fB\-b\fR \fIinput-format\fR" 4
-.IX Item "-b input-format"
-.PD 0
-.IP "\fB\-\-format=\fR\fIinput-format\fR" 4
-.IX Item "--format=input-format"
-.PD
-\&\fBld\fR may be configured to support more than one kind of object
-file. If your \fBld\fR is configured this way, you can use the
-\&\fB\-b\fR option to specify the binary format for input object files
-that follow this option on the command line. Even when \fBld\fR is
-configured to support alternative object formats, you don't usually need
-to specify this, as \fBld\fR should be configured to expect as a
-default input format the most usual format on each machine.
-\&\fIinput-format\fR is a text string, the name of a particular format
-supported by the \s-1BFD\s0 libraries. (You can list the available binary
-formats with \fBobjdump \-i\fR.)
-.Sp
-You may want to use this option if you are linking files with an unusual
-binary format. You can also use \fB\-b\fR to switch formats explicitly (when
-linking object files of different formats), by including
-\&\fB\-b\fR \fIinput-format\fR before each group of object files in a
-particular format.
-.Sp
-The default format is taken from the environment variable
-\&\f(CW\*(C`GNUTARGET\*(C'\fR.
-.Sp
-You can also define the input format from a script, using the command
-\&\f(CW\*(C`TARGET\*(C'\fR;
-.IP "\fB\-c\fR \fIMRI-commandfile\fR" 4
-.IX Item "-c MRI-commandfile"
-.PD 0
-.IP "\fB\-\-mri\-script=\fR\fIMRI-commandfile\fR" 4
-.IX Item "--mri-script=MRI-commandfile"
-.PD
-For compatibility with linkers produced by \s-1MRI\s0, \fBld\fR accepts script
-files written in an alternate, restricted command language, described in
-the \s-1MRI\s0 Compatible Script Files section of \s-1GNU\s0 ld documentation.
-Introduce \s-1MRI\s0 script files with
-the option \fB\-c\fR; use the \fB\-T\fR option to run linker
-scripts written in the general-purpose \fBld\fR scripting language.
-If \fIMRI-cmdfile\fR does not exist, \fBld\fR looks for it in the directories
-specified by any \fB\-L\fR options.
-.IP "\fB\-d\fR" 4
-.IX Item "-d"
-.PD 0
-.IP "\fB\-dc\fR" 4
-.IX Item "-dc"
-.IP "\fB\-dp\fR" 4
-.IX Item "-dp"
-.PD
-These three options are equivalent; multiple forms are supported for
-compatibility with other linkers. They assign space to common symbols
-even if a relocatable output file is specified (with \fB\-r\fR). The
-script command \f(CW\*(C`FORCE_COMMON_ALLOCATION\*(C'\fR has the same effect.
-.IP "\fB\-\-depaudit\fR \fI\s-1AUDITLIB\s0\fR" 4
-.IX Item "--depaudit AUDITLIB"
-.PD 0
-.IP "\fB\-P\fR \fI\s-1AUDITLIB\s0\fR" 4
-.IX Item "-P AUDITLIB"
-.PD
-Adds \fI\s-1AUDITLIB\s0\fR to the \f(CW\*(C`DT_DEPAUDIT\*(C'\fR entry of the dynamic section.
-\&\fI\s-1AUDITLIB\s0\fR is not checked for existence, nor will it use the \s-1DT_SONAME\s0
-specified in the library. If specified multiple times \f(CW\*(C`DT_DEPAUDIT\*(C'\fR
-will contain a colon separated list of audit interfaces to use. This
-option is only meaningful on \s-1ELF\s0 platforms supporting the rtld-audit interface.
-The \-P option is provided for Solaris compatibility.
-.IP "\fB\-e\fR \fIentry\fR" 4
-.IX Item "-e entry"
-.PD 0
-.IP "\fB\-\-entry=\fR\fIentry\fR" 4
-.IX Item "--entry=entry"
-.PD
-Use \fIentry\fR as the explicit symbol for beginning execution of your
-program, rather than the default entry point. If there is no symbol
-named \fIentry\fR, the linker will try to parse \fIentry\fR as a number,
-and use that as the entry address (the number will be interpreted in
-base 10; you may use a leading \fB0x\fR for base 16, or a leading
-\&\fB0\fR for base 8).
-.IP "\fB\-\-exclude\-libs\fR \fIlib\fR\fB,\fR\fIlib\fR\fB,...\fR" 4
-.IX Item "--exclude-libs lib,lib,..."
-Specifies a list of archive libraries from which symbols should not be automatically
-exported. The library names may be delimited by commas or colons. Specifying
-\&\f(CW\*(C`\-\-exclude\-libs ALL\*(C'\fR excludes symbols in all archive libraries from
-automatic export. This option is available only for the i386 \s-1PE\s0 targeted
-port of the linker and for \s-1ELF\s0 targeted ports. For i386 \s-1PE\s0, symbols
-explicitly listed in a .def file are still exported, regardless of this
-option. For \s-1ELF\s0 targeted ports, symbols affected by this option will
-be treated as hidden.
-.IP "\fB\-\-exclude\-modules\-for\-implib\fR \fImodule\fR\fB,\fR\fImodule\fR\fB,...\fR" 4
-.IX Item "--exclude-modules-for-implib module,module,..."
-Specifies a list of object files or archive members, from which symbols
-should not be automatically exported, but which should be copied wholesale
-into the import library being generated during the link. The module names
-may be delimited by commas or colons, and must match exactly the filenames
-used by \fBld\fR to open the files; for archive members, this is simply
-the member name, but for object files the name listed must include and
-match precisely any path used to specify the input file on the linker's
-command-line. This option is available only for the i386 \s-1PE\s0 targeted port
-of the linker. Symbols explicitly listed in a .def file are still exported,
-regardless of this option.
-.IP "\fB\-E\fR" 4
-.IX Item "-E"
-.PD 0
-.IP "\fB\-\-export\-dynamic\fR" 4
-.IX Item "--export-dynamic"
-.IP "\fB\-\-no\-export\-dynamic\fR" 4
-.IX Item "--no-export-dynamic"
-.PD
-When creating a dynamically linked executable, using the \fB\-E\fR
-option or the \fB\-\-export\-dynamic\fR option causes the linker to add
-all symbols to the dynamic symbol table. The dynamic symbol table is the
-set of symbols which are visible from dynamic objects at run time.
-.Sp
-If you do not use either of these options (or use the
-\&\fB\-\-no\-export\-dynamic\fR option to restore the default behavior), the
-dynamic symbol table will normally contain only those symbols which are
-referenced by some dynamic object mentioned in the link.
-.Sp
-If you use \f(CW\*(C`dlopen\*(C'\fR to load a dynamic object which needs to refer
-back to the symbols defined by the program, rather than some other
-dynamic object, then you will probably need to use this option when
-linking the program itself.
-.Sp
-You can also use the dynamic list to control what symbols should
-be added to the dynamic symbol table if the output format supports it.
-See the description of \fB\-\-dynamic\-list\fR.
-.Sp
-Note that this option is specific to \s-1ELF\s0 targeted ports. \s-1PE\s0 targets
-support a similar function to export all symbols from a \s-1DLL\s0 or \s-1EXE\s0; see
-the description of \fB\-\-export\-all\-symbols\fR below.
-.IP "\fB\-EB\fR" 4
-.IX Item "-EB"
-Link big-endian objects. This affects the default output format.
-.IP "\fB\-EL\fR" 4
-.IX Item "-EL"
-Link little-endian objects. This affects the default output format.
-.IP "\fB\-f\fR \fIname\fR" 4
-.IX Item "-f name"
-.PD 0
-.IP "\fB\-\-auxiliary=\fR\fIname\fR" 4
-.IX Item "--auxiliary=name"
-.PD
-When creating an \s-1ELF\s0 shared object, set the internal \s-1DT_AUXILIARY\s0 field
-to the specified name. This tells the dynamic linker that the symbol
-table of the shared object should be used as an auxiliary filter on the
-symbol table of the shared object \fIname\fR.
-.Sp
-If you later link a program against this filter object, then, when you
-run the program, the dynamic linker will see the \s-1DT_AUXILIARY\s0 field. If
-the dynamic linker resolves any symbols from the filter object, it will
-first check whether there is a definition in the shared object
-\&\fIname\fR. If there is one, it will be used instead of the definition
-in the filter object. The shared object \fIname\fR need not exist.
-Thus the shared object \fIname\fR may be used to provide an alternative
-implementation of certain functions, perhaps for debugging or for
-machine specific performance.
-.Sp
-This option may be specified more than once. The \s-1DT_AUXILIARY\s0 entries
-will be created in the order in which they appear on the command line.
-.IP "\fB\-F\fR \fIname\fR" 4
-.IX Item "-F name"
-.PD 0
-.IP "\fB\-\-filter=\fR\fIname\fR" 4
-.IX Item "--filter=name"
-.PD
-When creating an \s-1ELF\s0 shared object, set the internal \s-1DT_FILTER\s0 field to
-the specified name. This tells the dynamic linker that the symbol table
-of the shared object which is being created should be used as a filter
-on the symbol table of the shared object \fIname\fR.
-.Sp
-If you later link a program against this filter object, then, when you
-run the program, the dynamic linker will see the \s-1DT_FILTER\s0 field. The
-dynamic linker will resolve symbols according to the symbol table of the
-filter object as usual, but it will actually link to the definitions
-found in the shared object \fIname\fR. Thus the filter object can be
-used to select a subset of the symbols provided by the object
-\&\fIname\fR.
-.Sp
-Some older linkers used the \fB\-F\fR option throughout a compilation
-toolchain for specifying object-file format for both input and output
-object files.
-The \s-1GNU\s0 linker uses other mechanisms for this purpose: the
-\&\fB\-b\fR, \fB\-\-format\fR, \fB\-\-oformat\fR options, the
-\&\f(CW\*(C`TARGET\*(C'\fR command in linker scripts, and the \f(CW\*(C`GNUTARGET\*(C'\fR
-environment variable.
-The \s-1GNU\s0 linker will ignore the \fB\-F\fR option when not
-creating an \s-1ELF\s0 shared object.
-.IP "\fB\-fini=\fR\fIname\fR" 4
-.IX Item "-fini=name"
-When creating an \s-1ELF\s0 executable or shared object, call \s-1NAME\s0 when the
-executable or shared object is unloaded, by setting \s-1DT_FINI\s0 to the
-address of the function. By default, the linker uses \f(CW\*(C`_fini\*(C'\fR as
-the function to call.
-.IP "\fB\-g\fR" 4
-.IX Item "-g"
-Ignored. Provided for compatibility with other tools.
-.IP "\fB\-G\fR \fIvalue\fR" 4
-.IX Item "-G value"
-.PD 0
-.IP "\fB\-\-gpsize=\fR\fIvalue\fR" 4
-.IX Item "--gpsize=value"
-.PD
-Set the maximum size of objects to be optimized using the \s-1GP\s0 register to
-\&\fIsize\fR. This is only meaningful for object file formats such as
-\&\s-1MIPS\s0 \s-1ECOFF\s0 which supports putting large and small objects into different
-sections. This is ignored for other object file formats.
-.IP "\fB\-h\fR \fIname\fR" 4
-.IX Item "-h name"
-.PD 0
-.IP "\fB\-soname=\fR\fIname\fR" 4
-.IX Item "-soname=name"
-.PD
-When creating an \s-1ELF\s0 shared object, set the internal \s-1DT_SONAME\s0 field to
-the specified name. When an executable is linked with a shared object
-which has a \s-1DT_SONAME\s0 field, then when the executable is run the dynamic
-linker will attempt to load the shared object specified by the \s-1DT_SONAME\s0
-field rather than the using the file name given to the linker.
-.IP "\fB\-i\fR" 4
-.IX Item "-i"
-Perform an incremental link (same as option \fB\-r\fR).
-.IP "\fB\-init=\fR\fIname\fR" 4
-.IX Item "-init=name"
-When creating an \s-1ELF\s0 executable or shared object, call \s-1NAME\s0 when the
-executable or shared object is loaded, by setting \s-1DT_INIT\s0 to the address
-of the function. By default, the linker uses \f(CW\*(C`_init\*(C'\fR as the
-function to call.
-.IP "\fB\-l\fR \fInamespec\fR" 4
-.IX Item "-l namespec"
-.PD 0
-.IP "\fB\-\-library=\fR\fInamespec\fR" 4
-.IX Item "--library=namespec"
-.PD
-Add the archive or object file specified by \fInamespec\fR to the
-list of files to link. This option may be used any number of times.
-If \fInamespec\fR is of the form \fI:\fIfilename\fI\fR, \fBld\fR
-will search the library path for a file called \fIfilename\fR, otherwise it
-will search the library path for a file called \fIlib\fInamespec\fI.a\fR.
-.Sp
-On systems which support shared libraries, \fBld\fR may also search for
-files other than \fIlib\fInamespec\fI.a\fR. Specifically, on \s-1ELF\s0
-and SunOS systems, \fBld\fR will search a directory for a library
-called \fIlib\fInamespec\fI.so\fR before searching for one called
-\&\fIlib\fInamespec\fI.a\fR. (By convention, a \f(CW\*(C`.so\*(C'\fR extension
-indicates a shared library.) Note that this behavior does not apply
-to \fI:\fIfilename\fI\fR, which always specifies a file called
-\&\fIfilename\fR.
-.Sp
-The linker will search an archive only once, at the location where it is
-specified on the command line. If the archive defines a symbol which
-was undefined in some object which appeared before the archive on the
-command line, the linker will include the appropriate file(s) from the
-archive. However, an undefined symbol in an object appearing later on
-the command line will not cause the linker to search the archive again.
-.Sp
-See the \fB\-(\fR option for a way to force the linker to search
-archives multiple times.
-.Sp
-You may list the same archive multiple times on the command line.
-.Sp
-This type of archive searching is standard for Unix linkers. However,
-if you are using \fBld\fR on \s-1AIX\s0, note that it is different from the
-behaviour of the \s-1AIX\s0 linker.
-.IP "\fB\-L\fR \fIsearchdir\fR" 4
-.IX Item "-L searchdir"
-.PD 0
-.IP "\fB\-\-library\-path=\fR\fIsearchdir\fR" 4
-.IX Item "--library-path=searchdir"
-.PD
-Add path \fIsearchdir\fR to the list of paths that \fBld\fR will search
-for archive libraries and \fBld\fR control scripts. You may use this
-option any number of times. The directories are searched in the order
-in which they are specified on the command line. Directories specified
-on the command line are searched before the default directories. All
-\&\fB\-L\fR options apply to all \fB\-l\fR options, regardless of the
-order in which the options appear. \fB\-L\fR options do not affect
-how \fBld\fR searches for a linker script unless \fB\-T\fR
-option is specified.
-.Sp
-If \fIsearchdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
-by the \fIsysroot prefix\fR, a path specified when the linker is configured.
-.Sp
-The default set of paths searched (without being specified with
-\&\fB\-L\fR) depends on which emulation mode \fBld\fR is using, and in
-some cases also on how it was configured.
-.Sp
-The paths can also be specified in a link script with the
-\&\f(CW\*(C`SEARCH_DIR\*(C'\fR command. Directories specified this way are searched
-at the point in which the linker script appears in the command line.
-.IP "\fB\-m\fR \fIemulation\fR" 4
-.IX Item "-m emulation"
-Emulate the \fIemulation\fR linker. You can list the available
-emulations with the \fB\-\-verbose\fR or \fB\-V\fR options.
-.Sp
-If the \fB\-m\fR option is not used, the emulation is taken from the
-\&\f(CW\*(C`LDEMULATION\*(C'\fR environment variable, if that is defined.
-.Sp
-Otherwise, the default emulation depends upon how the linker was
-configured.
-.IP "\fB\-M\fR" 4
-.IX Item "-M"
-.PD 0
-.IP "\fB\-\-print\-map\fR" 4
-.IX Item "--print-map"
-.PD
-Print a link map to the standard output. A link map provides
-information about the link, including the following:
-.RS 4
-.IP "\(bu" 4
-Where object files are mapped into memory.
-.IP "\(bu" 4
-How common symbols are allocated.
-.IP "\(bu" 4
-All archive members included in the link, with a mention of the symbol
-which caused the archive member to be brought in.
-.IP "\(bu" 4
-The values assigned to symbols.
-.Sp
-Note \- symbols whose values are computed by an expression which
-involves a reference to a previous value of the same symbol may not
-have correct result displayed in the link map. This is because the
-linker discards intermediate results and only retains the final value
-of an expression. Under such circumstances the linker will display
-the final value enclosed by square brackets. Thus for example a
-linker script containing:
-.Sp
-.Vb 3
-\& foo = 1
-\& foo = foo * 4
-\& foo = foo + 8
-.Ve
-.Sp
-will produce the following output in the link map if the \fB\-M\fR
-option is used:
-.Sp
-.Vb 3
-\& 0x00000001 foo = 0x1
-\& [0x0000000c] foo = (foo * 0x4)
-\& [0x0000000c] foo = (foo + 0x8)
-.Ve
-.Sp
-See \fBExpressions\fR for more information about expressions in linker
-scripts.
-.RE
-.RS 4
-.RE
-.IP "\fB\-n\fR" 4
-.IX Item "-n"
-.PD 0
-.IP "\fB\-\-nmagic\fR" 4
-.IX Item "--nmagic"
-.PD
-Turn off page alignment of sections, and disable linking against shared
-libraries. If the output format supports Unix style magic numbers,
-mark the output as \f(CW\*(C`NMAGIC\*(C'\fR.
-.IP "\fB\-N\fR" 4
-.IX Item "-N"
-.PD 0
-.IP "\fB\-\-omagic\fR" 4
-.IX Item "--omagic"
-.PD
-Set the text and data sections to be readable and writable. Also, do
-not page-align the data segment, and disable linking against shared
-libraries. If the output format supports Unix style magic numbers,
-mark the output as \f(CW\*(C`OMAGIC\*(C'\fR. Note: Although a writable text section
-is allowed for PE-COFF targets, it does not conform to the format
-specification published by Microsoft.
-.IP "\fB\-\-no\-omagic\fR" 4
-.IX Item "--no-omagic"
-This option negates most of the effects of the \fB\-N\fR option. It
-sets the text section to be read-only, and forces the data segment to
-be page-aligned. Note \- this option does not enable linking against
-shared libraries. Use \fB\-Bdynamic\fR for this.
-.IP "\fB\-o\fR \fIoutput\fR" 4
-.IX Item "-o output"
-.PD 0
-.IP "\fB\-\-output=\fR\fIoutput\fR" 4
-.IX Item "--output=output"
-.PD
-Use \fIoutput\fR as the name for the program produced by \fBld\fR; if this
-option is not specified, the name \fIa.out\fR is used by default. The
-script command \f(CW\*(C`OUTPUT\*(C'\fR can also specify the output file name.
-.IP "\fB\-O\fR \fIlevel\fR" 4
-.IX Item "-O level"
-If \fIlevel\fR is a numeric values greater than zero \fBld\fR optimizes
-the output. This might take significantly longer and therefore probably
-should only be enabled for the final binary. At the moment this
-option only affects \s-1ELF\s0 shared library generation. Future releases of
-the linker may make more use of this option. Also currently there is
-no difference in the linker's behaviour for different non-zero values
-of this option. Again this may change with future releases.
-.IP "\fB\-q\fR" 4
-.IX Item "-q"
-.PD 0
-.IP "\fB\-\-emit\-relocs\fR" 4
-.IX Item "--emit-relocs"
-.PD
-Leave relocation sections and contents in fully linked executables.
-Post link analysis and optimization tools may need this information in
-order to perform correct modifications of executables. This results
-in larger executables.
-.Sp
-This option is currently only supported on \s-1ELF\s0 platforms.
-.IP "\fB\-\-force\-dynamic\fR" 4
-.IX Item "--force-dynamic"
-Force the output file to have dynamic sections. This option is specific
-to VxWorks targets.
-.IP "\fB\-r\fR" 4
-.IX Item "-r"
-.PD 0
-.IP "\fB\-\-relocatable\fR" 4
-.IX Item "--relocatable"
-.PD
-Generate relocatable output\-\-\-i.e., generate an output file that can in
-turn serve as input to \fBld\fR. This is often called \fIpartial
-linking\fR. As a side effect, in environments that support standard Unix
-magic numbers, this option also sets the output file's magic number to
-\&\f(CW\*(C`OMAGIC\*(C'\fR.
-If this option is not specified, an absolute file is produced. When
-linking \*(C+ programs, this option \fIwill not\fR resolve references to
-constructors; to do that, use \fB\-Ur\fR.
-.Sp
-When an input file does not have the same format as the output file,
-partial linking is only supported if that input file does not contain any
-relocations. Different output formats can have further restrictions; for
-example some \f(CW\*(C`a.out\*(C'\fR\-based formats do not support partial linking
-with input files in other formats at all.
-.Sp
-This option does the same thing as \fB\-i\fR.
-.IP "\fB\-R\fR \fIfilename\fR" 4
-.IX Item "-R filename"
-.PD 0
-.IP "\fB\-\-just\-symbols=\fR\fIfilename\fR" 4
-.IX Item "--just-symbols=filename"
-.PD
-Read symbol names and their addresses from \fIfilename\fR, but do not
-relocate it or include it in the output. This allows your output file
-to refer symbolically to absolute locations of memory defined in other
-programs. You may use this option more than once.
-.Sp
-For compatibility with other \s-1ELF\s0 linkers, if the \fB\-R\fR option is
-followed by a directory name, rather than a file name, it is treated as
-the \fB\-rpath\fR option.
-.IP "\fB\-s\fR" 4
-.IX Item "-s"
-.PD 0
-.IP "\fB\-\-strip\-all\fR" 4
-.IX Item "--strip-all"
-.PD
-Omit all symbol information from the output file.
-.IP "\fB\-S\fR" 4
-.IX Item "-S"
-.PD 0
-.IP "\fB\-\-strip\-debug\fR" 4
-.IX Item "--strip-debug"
-.PD
-Omit debugger symbol information (but not all symbols) from the output file.
-.IP "\fB\-t\fR" 4
-.IX Item "-t"
-.PD 0
-.IP "\fB\-\-trace\fR" 4
-.IX Item "--trace"
-.PD
-Print the names of the input files as \fBld\fR processes them.
-.IP "\fB\-T\fR \fIscriptfile\fR" 4
-.IX Item "-T scriptfile"
-.PD 0
-.IP "\fB\-\-script=\fR\fIscriptfile\fR" 4
-.IX Item "--script=scriptfile"
-.PD
-Use \fIscriptfile\fR as the linker script. This script replaces
-\&\fBld\fR's default linker script (rather than adding to it), so
-\&\fIcommandfile\fR must specify everything necessary to describe the
-output file. If \fIscriptfile\fR does not exist in
-the current directory, \f(CW\*(C`ld\*(C'\fR looks for it in the directories
-specified by any preceding \fB\-L\fR options. Multiple \fB\-T\fR
-options accumulate.
-.IP "\fB\-dT\fR \fIscriptfile\fR" 4
-.IX Item "-dT scriptfile"
-.PD 0
-.IP "\fB\-\-default\-script=\fR\fIscriptfile\fR" 4
-.IX Item "--default-script=scriptfile"
-.PD
-Use \fIscriptfile\fR as the default linker script.
-.Sp
-This option is similar to the \fB\-\-script\fR option except that
-processing of the script is delayed until after the rest of the
-command line has been processed. This allows options placed after the
-\&\fB\-\-default\-script\fR option on the command line to affect the
-behaviour of the linker script, which can be important when the linker
-command line cannot be directly controlled by the user. (eg because
-the command line is being constructed by another tool, such as
-\&\fBgcc\fR).
-.IP "\fB\-u\fR \fIsymbol\fR" 4
-.IX Item "-u symbol"
-.PD 0
-.IP "\fB\-\-undefined=\fR\fIsymbol\fR" 4
-.IX Item "--undefined=symbol"
-.PD
-Force \fIsymbol\fR to be entered in the output file as an undefined
-symbol. Doing this may, for example, trigger linking of additional
-modules from standard libraries. \fB\-u\fR may be repeated with
-different option arguments to enter additional undefined symbols. This
-option is equivalent to the \f(CW\*(C`EXTERN\*(C'\fR linker script command.
-.IP "\fB\-Ur\fR" 4
-.IX Item "-Ur"
-For anything other than \*(C+ programs, this option is equivalent to
-\&\fB\-r\fR: it generates relocatable output\-\-\-i.e., an output file that can in
-turn serve as input to \fBld\fR. When linking \*(C+ programs, \fB\-Ur\fR
-\&\fIdoes\fR resolve references to constructors, unlike \fB\-r\fR.
-It does not work to use \fB\-Ur\fR on files that were themselves linked
-with \fB\-Ur\fR; once the constructor table has been built, it cannot
-be added to. Use \fB\-Ur\fR only for the last partial link, and
-\&\fB\-r\fR for the others.
-.IP "\fB\-\-unique[=\fR\fI\s-1SECTION\s0\fR\fB]\fR" 4
-.IX Item "--unique[=SECTION]"
-Creates a separate output section for every input section matching
-\&\fI\s-1SECTION\s0\fR, or if the optional wildcard \fI\s-1SECTION\s0\fR argument is
-missing, for every orphan input section. An orphan section is one not
-specifically mentioned in a linker script. You may use this option
-multiple times on the command line; It prevents the normal merging of
-input sections with the same name, overriding output section assignments
-in a linker script.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.PD
-Display the version number for \fBld\fR. The \fB\-V\fR option also
-lists the supported emulations.
-.IP "\fB\-x\fR" 4
-.IX Item "-x"
-.PD 0
-.IP "\fB\-\-discard\-all\fR" 4
-.IX Item "--discard-all"
-.PD
-Delete all local symbols.
-.IP "\fB\-X\fR" 4
-.IX Item "-X"
-.PD 0
-.IP "\fB\-\-discard\-locals\fR" 4
-.IX Item "--discard-locals"
-.PD
-Delete all temporary local symbols. (These symbols start with
-system-specific local label prefixes, typically \fB.L\fR for \s-1ELF\s0 systems
-or \fBL\fR for traditional a.out systems.)
-.IP "\fB\-y\fR \fIsymbol\fR" 4
-.IX Item "-y symbol"
-.PD 0
-.IP "\fB\-\-trace\-symbol=\fR\fIsymbol\fR" 4
-.IX Item "--trace-symbol=symbol"
-.PD
-Print the name of each linked file in which \fIsymbol\fR appears. This
-option may be given any number of times. On many systems it is necessary
-to prepend an underscore.
-.Sp
-This option is useful when you have an undefined symbol in your link but
-don't know where the reference is coming from.
-.IP "\fB\-Y\fR \fIpath\fR" 4
-.IX Item "-Y path"
-Add \fIpath\fR to the default library search path. This option exists
-for Solaris compatibility.
-.IP "\fB\-z\fR \fIkeyword\fR" 4
-.IX Item "-z keyword"
-The recognized keywords are:
-.RS 4
-.IP "\fBcombreloc\fR" 4
-.IX Item "combreloc"
-Combines multiple reloc sections and sorts them to make dynamic symbol
-lookup caching possible.
-.IP "\fBdefs\fR" 4
-.IX Item "defs"
-Disallows undefined symbols in object files. Undefined symbols in
-shared libraries are still allowed.
-.IP "\fBexecstack\fR" 4
-.IX Item "execstack"
-Marks the object as requiring executable stack.
-.IP "\fBinitfirst\fR" 4
-.IX Item "initfirst"
-This option is only meaningful when building a shared object.
-It marks the object so that its runtime initialization will occur
-before the runtime initialization of any other objects brought into
-the process at the same time. Similarly the runtime finalization of
-the object will occur after the runtime finalization of any other
-objects.
-.IP "\fBinterpose\fR" 4
-.IX Item "interpose"
-Marks the object that its symbol table interposes before all symbols
-but the primary executable.
-.IP "\fBlazy\fR" 4
-.IX Item "lazy"
-When generating an executable or shared library, mark it to tell the
-dynamic linker to defer function call resolution to the point when
-the function is called (lazy binding), rather than at load time.
-Lazy binding is the default.
-.IP "\fBloadfltr\fR" 4
-.IX Item "loadfltr"
-Marks the object that its filters be processed immediately at
-runtime.
-.IP "\fBmuldefs\fR" 4
-.IX Item "muldefs"
-Allows multiple definitions.
-.IP "\fBnocombreloc\fR" 4
-.IX Item "nocombreloc"
-Disables multiple reloc sections combining.
-.IP "\fBnocopyreloc\fR" 4
-.IX Item "nocopyreloc"
-Disables production of copy relocs.
-.IP "\fBnodefaultlib\fR" 4
-.IX Item "nodefaultlib"
-Marks the object that the search for dependencies of this object will
-ignore any default library search paths.
-.IP "\fBnodelete\fR" 4
-.IX Item "nodelete"
-Marks the object shouldn't be unloaded at runtime.
-.IP "\fBnodlopen\fR" 4
-.IX Item "nodlopen"
-Marks the object not available to \f(CW\*(C`dlopen\*(C'\fR.
-.IP "\fBnodump\fR" 4
-.IX Item "nodump"
-Marks the object can not be dumped by \f(CW\*(C`dldump\*(C'\fR.
-.IP "\fBnoexecstack\fR" 4
-.IX Item "noexecstack"
-Marks the object as not requiring executable stack.
-.IP "\fBnorelro\fR" 4
-.IX Item "norelro"
-Don't create an \s-1ELF\s0 \f(CW\*(C`PT_GNU_RELRO\*(C'\fR segment header in the object.
-.IP "\fBnow\fR" 4
-.IX Item "now"
-When generating an executable or shared library, mark it to tell the
-dynamic linker to resolve all symbols when the program is started, or
-when the shared library is linked to using dlopen, instead of
-deferring function call resolution to the point when the function is
-first called.
-.IP "\fBorigin\fR" 4
-.IX Item "origin"
-Marks the object may contain \f(CW$ORIGIN\fR.
-.IP "\fBrelro\fR" 4
-.IX Item "relro"
-Create an \s-1ELF\s0 \f(CW\*(C`PT_GNU_RELRO\*(C'\fR segment header in the object.
-.IP "\fBmax\-page\-size=\fR\fIvalue\fR" 4
-.IX Item "max-page-size=value"
-Set the emulation maximum page size to \fIvalue\fR.
-.IP "\fBcommon\-page\-size=\fR\fIvalue\fR" 4
-.IX Item "common-page-size=value"
-Set the emulation common page size to \fIvalue\fR.
-.RE
-.RS 4
-.Sp
-Other keywords are ignored for Solaris compatibility.
-.RE
-.IP "\fB\-(\fR \fIarchives\fR \fB\-)\fR" 4
-.IX Item "-( archives -)"
-.PD 0
-.IP "\fB\-\-start\-group\fR \fIarchives\fR \fB\-\-end\-group\fR" 4
-.IX Item "--start-group archives --end-group"
-.PD
-The \fIarchives\fR should be a list of archive files. They may be
-either explicit file names, or \fB\-l\fR options.
-.Sp
-The specified archives are searched repeatedly until no new undefined
-references are created. Normally, an archive is searched only once in
-the order that it is specified on the command line. If a symbol in that
-archive is needed to resolve an undefined symbol referred to by an
-object in an archive that appears later on the command line, the linker
-would not be able to resolve that reference. By grouping the archives,
-they all be searched repeatedly until all possible references are
-resolved.
-.Sp
-Using this option has a significant performance cost. It is best to use
-it only when there are unavoidable circular references between two or
-more archives.
-.IP "\fB\-\-accept\-unknown\-input\-arch\fR" 4
-.IX Item "--accept-unknown-input-arch"
-.PD 0
-.IP "\fB\-\-no\-accept\-unknown\-input\-arch\fR" 4
-.IX Item "--no-accept-unknown-input-arch"
-.PD
-Tells the linker to accept input files whose architecture cannot be
-recognised. The assumption is that the user knows what they are doing
-and deliberately wants to link in these unknown input files. This was
-the default behaviour of the linker, before release 2.14. The default
-behaviour from release 2.14 onwards is to reject such input files, and
-so the \fB\-\-accept\-unknown\-input\-arch\fR option has been added to
-restore the old behaviour.
-.IP "\fB\-\-as\-needed\fR" 4
-.IX Item "--as-needed"
-.PD 0
-.IP "\fB\-\-no\-as\-needed\fR" 4
-.IX Item "--no-as-needed"
-.PD
-This option affects \s-1ELF\s0 \s-1DT_NEEDED\s0 tags for dynamic libraries mentioned
-on the command line after the \fB\-\-as\-needed\fR option. Normally
-the linker will add a \s-1DT_NEEDED\s0 tag for each dynamic library mentioned
-on the command line, regardless of whether the library is actually
-needed or not. \fB\-\-as\-needed\fR causes a \s-1DT_NEEDED\s0 tag to only be
-emitted for a library that satisfies an undefined symbol reference
-from a regular object file or, if the library is not found in the
-\&\s-1DT_NEEDED\s0 lists of other libraries linked up to that point, an
-undefined symbol reference from another dynamic library.
-\&\fB\-\-no\-as\-needed\fR restores the default behaviour.
-.IP "\fB\-\-add\-needed\fR" 4
-.IX Item "--add-needed"
-.PD 0
-.IP "\fB\-\-no\-add\-needed\fR" 4
-.IX Item "--no-add-needed"
-.PD
-These two options have been deprecated because of the similarity of
-their names to the \fB\-\-as\-needed\fR and \fB\-\-no\-as\-needed\fR
-options. They have been replaced by \fB\-\-copy\-dt\-needed\-entries\fR
-and \fB\-\-no\-copy\-dt\-needed\-entries\fR.
-.IP "\fB\-assert\fR \fIkeyword\fR" 4
-.IX Item "-assert keyword"
-This option is ignored for SunOS compatibility.
-.IP "\fB\-Bdynamic\fR" 4
-.IX Item "-Bdynamic"
-.PD 0
-.IP "\fB\-dy\fR" 4
-.IX Item "-dy"
-.IP "\fB\-call_shared\fR" 4
-.IX Item "-call_shared"
-.PD
-Link against dynamic libraries. This is only meaningful on platforms
-for which shared libraries are supported. This option is normally the
-default on such platforms. The different variants of this option are
-for compatibility with various systems. You may use this option
-multiple times on the command line: it affects library searching for
-\&\fB\-l\fR options which follow it.
-.IP "\fB\-Bgroup\fR" 4
-.IX Item "-Bgroup"
-Set the \f(CW\*(C`DF_1_GROUP\*(C'\fR flag in the \f(CW\*(C`DT_FLAGS_1\*(C'\fR entry in the dynamic
-section. This causes the runtime linker to handle lookups in this
-object and its dependencies to be performed only inside the group.
-\&\fB\-\-unresolved\-symbols=report\-all\fR is implied. This option is
-only meaningful on \s-1ELF\s0 platforms which support shared libraries.
-.IP "\fB\-Bstatic\fR" 4
-.IX Item "-Bstatic"
-.PD 0
-.IP "\fB\-dn\fR" 4
-.IX Item "-dn"
-.IP "\fB\-non_shared\fR" 4
-.IX Item "-non_shared"
-.IP "\fB\-static\fR" 4
-.IX Item "-static"
-.PD
-Do not link against shared libraries. This is only meaningful on
-platforms for which shared libraries are supported. The different
-variants of this option are for compatibility with various systems. You
-may use this option multiple times on the command line: it affects
-library searching for \fB\-l\fR options which follow it. This
-option also implies \fB\-\-unresolved\-symbols=report\-all\fR. This
-option can be used with \fB\-shared\fR. Doing so means that a
-shared library is being created but that all of the library's external
-references must be resolved by pulling in entries from static
-libraries.
-.IP "\fB\-Bsymbolic\fR" 4
-.IX Item "-Bsymbolic"
-When creating a shared library, bind references to global symbols to the
-definition within the shared library, if any. Normally, it is possible
-for a program linked against a shared library to override the definition
-within the shared library. This option is only meaningful on \s-1ELF\s0
-platforms which support shared libraries.
-.IP "\fB\-Bsymbolic\-functions\fR" 4
-.IX Item "-Bsymbolic-functions"
-When creating a shared library, bind references to global function
-symbols to the definition within the shared library, if any.
-This option is only meaningful on \s-1ELF\s0 platforms which support shared
-libraries.
-.IP "\fB\-\-dynamic\-list=\fR\fIdynamic-list-file\fR" 4
-.IX Item "--dynamic-list=dynamic-list-file"
-Specify the name of a dynamic list file to the linker. This is
-typically used when creating shared libraries to specify a list of
-global symbols whose references shouldn't be bound to the definition
-within the shared library, or creating dynamically linked executables
-to specify a list of symbols which should be added to the symbol table
-in the executable. This option is only meaningful on \s-1ELF\s0 platforms
-which support shared libraries.
-.Sp
-The format of the dynamic list is the same as the version node without
-scope and node name. See \fB\s-1VERSION\s0\fR for more information.
-.IP "\fB\-\-dynamic\-list\-data\fR" 4
-.IX Item "--dynamic-list-data"
-Include all global data symbols to the dynamic list.
-.IP "\fB\-\-dynamic\-list\-cpp\-new\fR" 4
-.IX Item "--dynamic-list-cpp-new"
-Provide the builtin dynamic list for \*(C+ operator new and delete. It
-is mainly useful for building shared libstdc++.
-.IP "\fB\-\-dynamic\-list\-cpp\-typeinfo\fR" 4
-.IX Item "--dynamic-list-cpp-typeinfo"
-Provide the builtin dynamic list for \*(C+ runtime type identification.
-.IP "\fB\-\-check\-sections\fR" 4
-.IX Item "--check-sections"
-.PD 0
-.IP "\fB\-\-no\-check\-sections\fR" 4
-.IX Item "--no-check-sections"
-.PD
-Asks the linker \fInot\fR to check section addresses after they have
-been assigned to see if there are any overlaps. Normally the linker will
-perform this check, and if it finds any overlaps it will produce
-suitable error messages. The linker does know about, and does make
-allowances for sections in overlays. The default behaviour can be
-restored by using the command line switch \fB\-\-check\-sections\fR.
-Section overlap is not usually checked for relocatable links. You can
-force checking in that case by using the \fB\-\-check\-sections\fR
-option.
-.IP "\fB\-\-copy\-dt\-needed\-entries\fR" 4
-.IX Item "--copy-dt-needed-entries"
-.PD 0
-.IP "\fB\-\-no\-copy\-dt\-needed\-entries\fR" 4
-.IX Item "--no-copy-dt-needed-entries"
-.PD
-This option affects the treatment of dynamic libraries referred to
-by \s-1DT_NEEDED\s0 tags \fIinside\fR \s-1ELF\s0 dynamic libraries mentioned on the
-command line. Normally the linker will add a \s-1DT_NEEDED\s0 tag to the
-output binary for each library mentioned in a \s-1DT_NEEDED\s0 tag in an
-input dynamic library. With \fB\-\-no\-copy\-dt\-needed\-entries\fR
-specified on the command line however any dynamic libraries that
-follow it will have their \s-1DT_NEEDED\s0 entries ignored. The default
-behaviour can be restored with \fB\-\-copy\-dt\-needed\-entries\fR.
-.Sp
-This option also has an effect on the resolution of symbols in dynamic
-libraries. With the default setting dynamic libraries mentioned on
-the command line will be recursively searched, following their
-\&\s-1DT_NEEDED\s0 tags to other libraries, in order to resolve symbols
-required by the output binary. With
-\&\fB\-\-no\-copy\-dt\-needed\-entries\fR specified however the searching
-of dynamic libraries that follow it will stop with the dynamic
-library itself. No \s-1DT_NEEDED\s0 links will be traversed to resolve
-symbols.
-.IP "\fB\-\-cref\fR" 4
-.IX Item "--cref"
-Output a cross reference table. If a linker map file is being
-generated, the cross reference table is printed to the map file.
-Otherwise, it is printed on the standard output.
-.Sp
-The format of the table is intentionally simple, so that it may be
-easily processed by a script if necessary. The symbols are printed out,
-sorted by name. For each symbol, a list of file names is given. If the
-symbol is defined, the first file listed is the location of the
-definition. The remaining files contain references to the symbol.
-.IP "\fB\-\-no\-define\-common\fR" 4
-.IX Item "--no-define-common"
-This option inhibits the assignment of addresses to common symbols.
-The script command \f(CW\*(C`INHIBIT_COMMON_ALLOCATION\*(C'\fR has the same effect.
-.Sp
-The \fB\-\-no\-define\-common\fR option allows decoupling
-the decision to assign addresses to Common symbols from the choice
-of the output file type; otherwise a non-Relocatable output type
-forces assigning addresses to Common symbols.
-Using \fB\-\-no\-define\-common\fR allows Common symbols that are referenced
-from a shared library to be assigned addresses only in the main program.
-This eliminates the unused duplicate space in the shared library,
-and also prevents any possible confusion over resolving to the wrong
-duplicate when there are many dynamic modules with specialized search
-paths for runtime symbol resolution.
-.IP "\fB\-\-defsym=\fR\fIsymbol\fR\fB=\fR\fIexpression\fR" 4
-.IX Item "--defsym=symbol=expression"
-Create a global symbol in the output file, containing the absolute
-address given by \fIexpression\fR. You may use this option as many
-times as necessary to define multiple symbols in the command line. A
-limited form of arithmetic is supported for the \fIexpression\fR in this
-context: you may give a hexadecimal constant or the name of an existing
-symbol, or use \f(CW\*(C`+\*(C'\fR and \f(CW\*(C`\-\*(C'\fR to add or subtract hexadecimal
-constants or symbols. If you need more elaborate expressions, consider
-using the linker command language from a script. \fINote:\fR there should be no white
-space between \fIsymbol\fR, the equals sign ("\fB=\fR"), and
-\&\fIexpression\fR.
-.IP "\fB\-\-demangle[=\fR\fIstyle\fR\fB]\fR" 4
-.IX Item "--demangle[=style]"
-.PD 0
-.IP "\fB\-\-no\-demangle\fR" 4
-.IX Item "--no-demangle"
-.PD
-These options control whether to demangle symbol names in error messages
-and other output. When the linker is told to demangle, it tries to
-present symbol names in a readable fashion: it strips leading
-underscores if they are used by the object file format, and converts \*(C+
-mangled symbol names into user readable names. Different compilers have
-different mangling styles. The optional demangling style argument can be used
-to choose an appropriate demangling style for your compiler. The linker will
-demangle by default unless the environment variable \fB\s-1COLLECT_NO_DEMANGLE\s0\fR
-is set. These options may be used to override the default.
-.IP "\fB\-I\fR\fIfile\fR" 4
-.IX Item "-Ifile"
-.PD 0
-.IP "\fB\-\-dynamic\-linker=\fR\fIfile\fR" 4
-.IX Item "--dynamic-linker=file"
-.PD
-Set the name of the dynamic linker. This is only meaningful when
-generating dynamically linked \s-1ELF\s0 executables. The default dynamic
-linker is normally correct; don't use this unless you know what you are
-doing.
-.IP "\fB\-\-fatal\-warnings\fR" 4
-.IX Item "--fatal-warnings"
-.PD 0
-.IP "\fB\-\-no\-fatal\-warnings\fR" 4
-.IX Item "--no-fatal-warnings"
-.PD
-Treat all warnings as errors. The default behaviour can be restored
-with the option \fB\-\-no\-fatal\-warnings\fR.
-.IP "\fB\-\-force\-exe\-suffix\fR" 4
-.IX Item "--force-exe-suffix"
-Make sure that an output file has a .exe suffix.
-.Sp
-If a successfully built fully linked output file does not have a
-\&\f(CW\*(C`.exe\*(C'\fR or \f(CW\*(C`.dll\*(C'\fR suffix, this option forces the linker to copy
-the output file to one of the same name with a \f(CW\*(C`.exe\*(C'\fR suffix. This
-option is useful when using unmodified Unix makefiles on a Microsoft
-Windows host, since some versions of Windows won't run an image unless
-it ends in a \f(CW\*(C`.exe\*(C'\fR suffix.
-.IP "\fB\-\-gc\-sections\fR" 4
-.IX Item "--gc-sections"
-.PD 0
-.IP "\fB\-\-no\-gc\-sections\fR" 4
-.IX Item "--no-gc-sections"
-.PD
-Enable garbage collection of unused input sections. It is ignored on
-targets that do not support this option. The default behaviour (of not
-performing this garbage collection) can be restored by specifying
-\&\fB\-\-no\-gc\-sections\fR on the command line.
-.Sp
-\&\fB\-\-gc\-sections\fR decides which input sections are used by
-examining symbols and relocations. The section containing the entry
-symbol and all sections containing symbols undefined on the
-command-line will be kept, as will sections containing symbols
-referenced by dynamic objects. Note that when building shared
-libraries, the linker must assume that any visible symbol is
-referenced. Once this initial set of sections has been determined,
-the linker recursively marks as used any section referenced by their
-relocations. See \fB\-\-entry\fR and \fB\-\-undefined\fR.
-.Sp
-This option can be set when doing a partial link (enabled with option
-\&\fB\-r\fR). In this case the root of symbols kept must be explicitly
-specified either by an \fB\-\-entry\fR or \fB\-\-undefined\fR option or by
-a \f(CW\*(C`ENTRY\*(C'\fR command in the linker script.
-.IP "\fB\-\-print\-gc\-sections\fR" 4
-.IX Item "--print-gc-sections"
-.PD 0
-.IP "\fB\-\-no\-print\-gc\-sections\fR" 4
-.IX Item "--no-print-gc-sections"
-.PD
-List all sections removed by garbage collection. The listing is
-printed on stderr. This option is only effective if garbage
-collection has been enabled via the \fB\-\-gc\-sections\fR) option. The
-default behaviour (of not listing the sections that are removed) can
-be restored by specifying \fB\-\-no\-print\-gc\-sections\fR on the command
-line.
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-Print a summary of the command-line options on the standard output and exit.
-.IP "\fB\-\-target\-help\fR" 4
-.IX Item "--target-help"
-Print a summary of all target specific options on the standard output and exit.
-.IP "\fB\-Map=\fR\fImapfile\fR" 4
-.IX Item "-Map=mapfile"
-Print a link map to the file \fImapfile\fR. See the description of the
-\&\fB\-M\fR option, above.
-.IP "\fB\-\-no\-keep\-memory\fR" 4
-.IX Item "--no-keep-memory"
-\&\fBld\fR normally optimizes for speed over memory usage by caching the
-symbol tables of input files in memory. This option tells \fBld\fR to
-instead optimize for memory usage, by rereading the symbol tables as
-necessary. This may be required if \fBld\fR runs out of memory space
-while linking a large executable.
-.IP "\fB\-\-no\-undefined\fR" 4
-.IX Item "--no-undefined"
-.PD 0
-.IP "\fB\-z defs\fR" 4
-.IX Item "-z defs"
-.PD
-Report unresolved symbol references from regular object files. This
-is done even if the linker is creating a non-symbolic shared library.
-The switch \fB\-\-[no\-]allow\-shlib\-undefined\fR controls the
-behaviour for reporting unresolved references found in shared
-libraries being linked in.
-.IP "\fB\-\-allow\-multiple\-definition\fR" 4
-.IX Item "--allow-multiple-definition"
-.PD 0
-.IP "\fB\-z muldefs\fR" 4
-.IX Item "-z muldefs"
-.PD
-Normally when a symbol is defined multiple times, the linker will
-report a fatal error. These options allow multiple definitions and the
-first definition will be used.
-.IP "\fB\-\-allow\-shlib\-undefined\fR" 4
-.IX Item "--allow-shlib-undefined"
-.PD 0
-.IP "\fB\-\-no\-allow\-shlib\-undefined\fR" 4
-.IX Item "--no-allow-shlib-undefined"
-.PD
-Allows or disallows undefined symbols in shared libraries.
-This switch is similar to \fB\-\-no\-undefined\fR except that it
-determines the behaviour when the undefined symbols are in a
-shared library rather than a regular object file. It does not affect
-how undefined symbols in regular object files are handled.
-.Sp
-The default behaviour is to report errors for any undefined symbols
-referenced in shared libraries if the linker is being used to create
-an executable, but to allow them if the linker is being used to create
-a shared library.
-.Sp
-The reasons for allowing undefined symbol references in shared
-libraries specified at link time are that:
-.RS 4
-.IP "\(bu" 4
-A shared library specified at link time may not be the same as the one
-that is available at load time, so the symbol might actually be
-resolvable at load time.
-.IP "\(bu" 4
-There are some operating systems, eg BeOS and \s-1HPPA\s0, where undefined
-symbols in shared libraries are normal.
-.Sp
-The BeOS kernel for example patches shared libraries at load time to
-select whichever function is most appropriate for the current
-architecture. This is used, for example, to dynamically select an
-appropriate memset function.
-.RE
-.RS 4
-.RE
-.IP "\fB\-\-no\-undefined\-version\fR" 4
-.IX Item "--no-undefined-version"
-Normally when a symbol has an undefined version, the linker will ignore
-it. This option disallows symbols with undefined version and a fatal error
-will be issued instead.
-.IP "\fB\-\-default\-symver\fR" 4
-.IX Item "--default-symver"
-Create and use a default symbol version (the soname) for unversioned
-exported symbols.
-.IP "\fB\-\-default\-imported\-symver\fR" 4
-.IX Item "--default-imported-symver"
-Create and use a default symbol version (the soname) for unversioned
-imported symbols.
-.IP "\fB\-\-no\-warn\-mismatch\fR" 4
-.IX Item "--no-warn-mismatch"
-Normally \fBld\fR will give an error if you try to link together input
-files that are mismatched for some reason, perhaps because they have
-been compiled for different processors or for different endiannesses.
-This option tells \fBld\fR that it should silently permit such possible
-errors. This option should only be used with care, in cases when you
-have taken some special action that ensures that the linker errors are
-inappropriate.
-.IP "\fB\-\-no\-warn\-search\-mismatch\fR" 4
-.IX Item "--no-warn-search-mismatch"
-Normally \fBld\fR will give a warning if it finds an incompatible
-library during a library search. This option silences the warning.
-.IP "\fB\-\-no\-whole\-archive\fR" 4
-.IX Item "--no-whole-archive"
-Turn off the effect of the \fB\-\-whole\-archive\fR option for subsequent
-archive files.
-.IP "\fB\-\-noinhibit\-exec\fR" 4
-.IX Item "--noinhibit-exec"
-Retain the executable output file whenever it is still usable.
-Normally, the linker will not produce an output file if it encounters
-errors during the link process; it exits without writing an output file
-when it issues any error whatsoever.
-.IP "\fB\-nostdlib\fR" 4
-.IX Item "-nostdlib"
-Only search library directories explicitly specified on the
-command line. Library directories specified in linker scripts
-(including linker scripts specified on the command line) are ignored.
-.IP "\fB\-\-oformat=\fR\fIoutput-format\fR" 4
-.IX Item "--oformat=output-format"
-\&\fBld\fR may be configured to support more than one kind of object
-file. If your \fBld\fR is configured this way, you can use the
-\&\fB\-\-oformat\fR option to specify the binary format for the output
-object file. Even when \fBld\fR is configured to support alternative
-object formats, you don't usually need to specify this, as \fBld\fR
-should be configured to produce as a default output format the most
-usual format on each machine. \fIoutput-format\fR is a text string, the
-name of a particular format supported by the \s-1BFD\s0 libraries. (You can
-list the available binary formats with \fBobjdump \-i\fR.) The script
-command \f(CW\*(C`OUTPUT_FORMAT\*(C'\fR can also specify the output format, but
-this option overrides it.
-.IP "\fB\-pie\fR" 4
-.IX Item "-pie"
-.PD 0
-.IP "\fB\-\-pic\-executable\fR" 4
-.IX Item "--pic-executable"
-.PD
-Create a position independent executable. This is currently only supported on
-\&\s-1ELF\s0 platforms. Position independent executables are similar to shared
-libraries in that they are relocated by the dynamic linker to the virtual
-address the \s-1OS\s0 chooses for them (which can vary between invocations). Like
-normal dynamically linked executables they can be executed and symbols
-defined in the executable cannot be overridden by shared libraries.
-.IP "\fB\-qmagic\fR" 4
-.IX Item "-qmagic"
-This option is ignored for Linux compatibility.
-.IP "\fB\-Qy\fR" 4
-.IX Item "-Qy"
-This option is ignored for \s-1SVR4\s0 compatibility.
-.IP "\fB\-\-relax\fR" 4
-.IX Item "--relax"
-.PD 0
-.IP "\fB\-\-no\-relax\fR" 4
-.IX Item "--no-relax"
-.PD
-An option with machine dependent effects.
-This option is only supported on a few targets.
-.Sp
-On some platforms the \fB\-\-relax\fR option performs target specific,
-global optimizations that become possible when the linker resolves
-addressing in the program, such as relaxing address modes,
-synthesizing new instructions, selecting shorter version of current
-instructions, and combinig constant values.
-.Sp
-On some platforms these link time global optimizations may make symbolic
-debugging of the resulting executable impossible.
-This is known to be the case for the Matsushita \s-1MN10200\s0 and \s-1MN10300\s0
-family of processors.
-.Sp
-On platforms where this is not supported, \fB\-\-relax\fR is accepted,
-but ignored.
-.Sp
-On platforms where \fB\-\-relax\fR is accepted the option
-\&\fB\-\-no\-relax\fR can be used to disable the feature.
-.IP "\fB\-\-retain\-symbols\-file=\fR\fIfilename\fR" 4
-.IX Item "--retain-symbols-file=filename"
-Retain \fIonly\fR the symbols listed in the file \fIfilename\fR,
-discarding all others. \fIfilename\fR is simply a flat file, with one
-symbol name per line. This option is especially useful in environments
-(such as VxWorks)
-where a large global symbol table is accumulated gradually, to conserve
-run-time memory.
-.Sp
-\&\fB\-\-retain\-symbols\-file\fR does \fInot\fR discard undefined symbols,
-or symbols needed for relocations.
-.Sp
-You may only specify \fB\-\-retain\-symbols\-file\fR once in the command
-line. It overrides \fB\-s\fR and \fB\-S\fR.
-.IP "\fB\-rpath=\fR\fIdir\fR" 4
-.IX Item "-rpath=dir"
-Add a directory to the runtime library search path. This is used when
-linking an \s-1ELF\s0 executable with shared objects. All \fB\-rpath\fR
-arguments are concatenated and passed to the runtime linker, which uses
-them to locate shared objects at runtime. The \fB\-rpath\fR option is
-also used when locating shared objects which are needed by shared
-objects explicitly included in the link; see the description of the
-\&\fB\-rpath\-link\fR option. If \fB\-rpath\fR is not used when linking an
-\&\s-1ELF\s0 executable, the contents of the environment variable
-\&\f(CW\*(C`LD_RUN_PATH\*(C'\fR will be used if it is defined.
-.Sp
-The \fB\-rpath\fR option may also be used on SunOS. By default, on
-SunOS, the linker will form a runtime search patch out of all the
-\&\fB\-L\fR options it is given. If a \fB\-rpath\fR option is used, the
-runtime search path will be formed exclusively using the \fB\-rpath\fR
-options, ignoring the \fB\-L\fR options. This can be useful when using
-gcc, which adds many \fB\-L\fR options which may be on \s-1NFS\s0 mounted
-file systems.
-.Sp
-For compatibility with other \s-1ELF\s0 linkers, if the \fB\-R\fR option is
-followed by a directory name, rather than a file name, it is treated as
-the \fB\-rpath\fR option.
-.IP "\fB\-rpath\-link=\fR\fIdir\fR" 4
-.IX Item "-rpath-link=dir"
-When using \s-1ELF\s0 or SunOS, one shared library may require another. This
-happens when an \f(CW\*(C`ld \-shared\*(C'\fR link includes a shared library as one
-of the input files.
-.Sp
-When the linker encounters such a dependency when doing a non-shared,
-non-relocatable link, it will automatically try to locate the required
-shared library and include it in the link, if it is not included
-explicitly. In such a case, the \fB\-rpath\-link\fR option
-specifies the first set of directories to search. The
-\&\fB\-rpath\-link\fR option may specify a sequence of directory names
-either by specifying a list of names separated by colons, or by
-appearing multiple times.
-.Sp
-This option should be used with caution as it overrides the search path
-that may have been hard compiled into a shared library. In such a case it
-is possible to use unintentionally a different search path than the
-runtime linker would do.
-.Sp
-The linker uses the following search paths to locate required shared
-libraries:
-.RS 4
-.IP "1." 4
-Any directories specified by \fB\-rpath\-link\fR options.
-.IP "2." 4
-Any directories specified by \fB\-rpath\fR options. The difference
-between \fB\-rpath\fR and \fB\-rpath\-link\fR is that directories
-specified by \fB\-rpath\fR options are included in the executable and
-used at runtime, whereas the \fB\-rpath\-link\fR option is only effective
-at link time. Searching \fB\-rpath\fR in this way is only supported
-by native linkers and cross linkers which have been configured with
-the \fB\-\-with\-sysroot\fR option.
-.IP "3." 4
-On an \s-1ELF\s0 system, for native linkers, if the \fB\-rpath\fR and
-\&\fB\-rpath\-link\fR options were not used, search the contents of the
-environment variable \f(CW\*(C`LD_RUN_PATH\*(C'\fR.
-.IP "4." 4
-On SunOS, if the \fB\-rpath\fR option was not used, search any
-directories specified using \fB\-L\fR options.
-.IP "5." 4
-For a native linker, the search the contents of the environment
-variable \f(CW\*(C`LD_LIBRARY_PATH\*(C'\fR.
-.IP "6." 4
-For a native \s-1ELF\s0 linker, the directories in \f(CW\*(C`DT_RUNPATH\*(C'\fR or
-\&\f(CW\*(C`DT_RPATH\*(C'\fR of a shared library are searched for shared
-libraries needed by it. The \f(CW\*(C`DT_RPATH\*(C'\fR entries are ignored if
-\&\f(CW\*(C`DT_RUNPATH\*(C'\fR entries exist.
-.IP "7." 4
-The default directories, normally \fI/lib\fR and \fI/usr/lib\fR.
-.IP "8." 4
-For a native linker on an \s-1ELF\s0 system, if the file \fI/etc/ld.so.conf\fR
-exists, the list of directories found in that file.
-.RE
-.RS 4
-.Sp
-If the required shared library is not found, the linker will issue a
-warning and continue with the link.
-.RE
-.IP "\fB\-shared\fR" 4
-.IX Item "-shared"
-.PD 0
-.IP "\fB\-Bshareable\fR" 4
-.IX Item "-Bshareable"
-.PD
-Create a shared library. This is currently only supported on \s-1ELF\s0, \s-1XCOFF\s0
-and SunOS platforms. On SunOS, the linker will automatically create a
-shared library if the \fB\-e\fR option is not used and there are
-undefined symbols in the link.
-.IP "\fB\-\-sort\-common\fR" 4
-.IX Item "--sort-common"
-.PD 0
-.IP "\fB\-\-sort\-common=ascending\fR" 4
-.IX Item "--sort-common=ascending"
-.IP "\fB\-\-sort\-common=descending\fR" 4
-.IX Item "--sort-common=descending"
-.PD
-This option tells \fBld\fR to sort the common symbols by alignment in
-ascending or descending order when it places them in the appropriate output
-sections. The symbol alignments considered are sixteen-byte or larger,
-eight-byte, four-byte, two-byte, and one-byte. This is to prevent gaps
-between symbols due to alignment constraints. If no sorting order is
-specified, then descending order is assumed.
-.IP "\fB\-\-sort\-section=name\fR" 4
-.IX Item "--sort-section=name"
-This option will apply \f(CW\*(C`SORT_BY_NAME\*(C'\fR to all wildcard section
-patterns in the linker script.
-.IP "\fB\-\-sort\-section=alignment\fR" 4
-.IX Item "--sort-section=alignment"
-This option will apply \f(CW\*(C`SORT_BY_ALIGNMENT\*(C'\fR to all wildcard section
-patterns in the linker script.
-.IP "\fB\-\-split\-by\-file[=\fR\fIsize\fR\fB]\fR" 4
-.IX Item "--split-by-file[=size]"
-Similar to \fB\-\-split\-by\-reloc\fR but creates a new output section for
-each input file when \fIsize\fR is reached. \fIsize\fR defaults to a
-size of 1 if not given.
-.IP "\fB\-\-split\-by\-reloc[=\fR\fIcount\fR\fB]\fR" 4
-.IX Item "--split-by-reloc[=count]"
-Tries to creates extra sections in the output file so that no single
-output section in the file contains more than \fIcount\fR relocations.
-This is useful when generating huge relocatable files for downloading into
-certain real time kernels with the \s-1COFF\s0 object file format; since \s-1COFF\s0
-cannot represent more than 65535 relocations in a single section. Note
-that this will fail to work with object file formats which do not
-support arbitrary sections. The linker will not split up individual
-input sections for redistribution, so if a single input section contains
-more than \fIcount\fR relocations one output section will contain that
-many relocations. \fIcount\fR defaults to a value of 32768.
-.IP "\fB\-\-stats\fR" 4
-.IX Item "--stats"
-Compute and display statistics about the operation of the linker, such
-as execution time and memory usage.
-.IP "\fB\-\-sysroot=\fR\fIdirectory\fR" 4
-.IX Item "--sysroot=directory"
-Use \fIdirectory\fR as the location of the sysroot, overriding the
-configure-time default. This option is only supported by linkers
-that were configured using \fB\-\-with\-sysroot\fR.
-.IP "\fB\-\-traditional\-format\fR" 4
-.IX Item "--traditional-format"
-For some targets, the output of \fBld\fR is different in some ways from
-the output of some existing linker. This switch requests \fBld\fR to
-use the traditional format instead.
-.Sp
-For example, on SunOS, \fBld\fR combines duplicate entries in the
-symbol string table. This can reduce the size of an output file with
-full debugging information by over 30 percent. Unfortunately, the SunOS
-\&\f(CW\*(C`dbx\*(C'\fR program can not read the resulting program (\f(CW\*(C`gdb\*(C'\fR has no
-trouble). The \fB\-\-traditional\-format\fR switch tells \fBld\fR to not
-combine duplicate entries.
-.IP "\fB\-\-section\-start=\fR\fIsectionname\fR\fB=\fR\fIorg\fR" 4
-.IX Item "--section-start=sectionname=org"
-Locate a section in the output file at the absolute
-address given by \fIorg\fR. You may use this option as many
-times as necessary to locate multiple sections in the command
-line.
-\&\fIorg\fR must be a single hexadecimal integer;
-for compatibility with other linkers, you may omit the leading
-\&\fB0x\fR usually associated with hexadecimal values. \fINote:\fR there
-should be no white space between \fIsectionname\fR, the equals
-sign ("\fB=\fR"), and \fIorg\fR.
-.IP "\fB\-Tbss=\fR\fIorg\fR" 4
-.IX Item "-Tbss=org"
-.PD 0
-.IP "\fB\-Tdata=\fR\fIorg\fR" 4
-.IX Item "-Tdata=org"
-.IP "\fB\-Ttext=\fR\fIorg\fR" 4
-.IX Item "-Ttext=org"
-.PD
-Same as \fB\-\-section\-start\fR, with \f(CW\*(C`.bss\*(C'\fR, \f(CW\*(C`.data\*(C'\fR or
-\&\f(CW\*(C`.text\*(C'\fR as the \fIsectionname\fR.
-.IP "\fB\-Ttext\-segment=\fR\fIorg\fR" 4
-.IX Item "-Ttext-segment=org"
-When creating an \s-1ELF\s0 executable or shared object, it will set the address
-of the first byte of the text segment.
-.IP "\fB\-\-unresolved\-symbols=\fR\fImethod\fR" 4
-.IX Item "--unresolved-symbols=method"
-Determine how to handle unresolved symbols. There are four possible
-values for \fBmethod\fR:
-.RS 4
-.IP "\fBignore-all\fR" 4
-.IX Item "ignore-all"
-Do not report any unresolved symbols.
-.IP "\fBreport-all\fR" 4
-.IX Item "report-all"
-Report all unresolved symbols. This is the default.
-.IP "\fBignore-in-object-files\fR" 4
-.IX Item "ignore-in-object-files"
-Report unresolved symbols that are contained in shared libraries, but
-ignore them if they come from regular object files.
-.IP "\fBignore-in-shared-libs\fR" 4
-.IX Item "ignore-in-shared-libs"
-Report unresolved symbols that come from regular object files, but
-ignore them if they come from shared libraries. This can be useful
-when creating a dynamic binary and it is known that all the shared
-libraries that it should be referencing are included on the linker's
-command line.
-.RE
-.RS 4
-.Sp
-The behaviour for shared libraries on their own can also be controlled
-by the \fB\-\-[no\-]allow\-shlib\-undefined\fR option.
-.Sp
-Normally the linker will generate an error message for each reported
-unresolved symbol but the option \fB\-\-warn\-unresolved\-symbols\fR
-can change this to a warning.
-.RE
-.IP "\fB\-\-dll\-verbose\fR" 4
-.IX Item "--dll-verbose"
-.PD 0
-.IP "\fB\-\-verbose\fR" 4
-.IX Item "--verbose"
-.PD
-Display the version number for \fBld\fR and list the linker emulations
-supported. Display which input files can and cannot be opened. Display
-the linker script being used by the linker.
-.IP "\fB\-\-version\-script=\fR\fIversion-scriptfile\fR" 4
-.IX Item "--version-script=version-scriptfile"
-Specify the name of a version script to the linker. This is typically
-used when creating shared libraries to specify additional information
-about the version hierarchy for the library being created. This option
-is only fully supported on \s-1ELF\s0 platforms which support shared libraries;
-see \fB\s-1VERSION\s0\fR. It is partially supported on \s-1PE\s0 platforms, which can
-use version scripts to filter symbol visibility in auto-export mode: any
-symbols marked \fBlocal\fR in the version script will not be exported.
-.IP "\fB\-\-warn\-common\fR" 4
-.IX Item "--warn-common"
-Warn when a common symbol is combined with another common symbol or with
-a symbol definition. Unix linkers allow this somewhat sloppy practise,
-but linkers on some other operating systems do not. This option allows
-you to find potential problems from combining global symbols.
-Unfortunately, some C libraries use this practise, so you may get some
-warnings about symbols in the libraries as well as in your programs.
-.Sp
-There are three kinds of global symbols, illustrated here by C examples:
-.RS 4
-.IP "\fBint i = 1;\fR" 4
-.IX Item "int i = 1;"
-A definition, which goes in the initialized data section of the output
-file.
-.IP "\fBextern int i;\fR" 4
-.IX Item "extern int i;"
-An undefined reference, which does not allocate space.
-There must be either a definition or a common symbol for the
-variable somewhere.
-.IP "\fBint i;\fR" 4
-.IX Item "int i;"
-A common symbol. If there are only (one or more) common symbols for a
-variable, it goes in the uninitialized data area of the output file.
-The linker merges multiple common symbols for the same variable into a
-single symbol. If they are of different sizes, it picks the largest
-size. The linker turns a common symbol into a declaration, if there is
-a definition of the same variable.
-.RE
-.RS 4
-.Sp
-The \fB\-\-warn\-common\fR option can produce five kinds of warnings.
-Each warning consists of a pair of lines: the first describes the symbol
-just encountered, and the second describes the previous symbol
-encountered with the same name. One or both of the two symbols will be
-a common symbol.
-.IP "1." 4
-Turning a common symbol into a reference, because there is already a
-definition for the symbol.
-.Sp
-.Vb 3
-\& <file>(<section>): warning: common of \`<symbol>\*(Aq
-\& overridden by definition
-\& <file>(<section>): warning: defined here
-.Ve
-.IP "2." 4
-Turning a common symbol into a reference, because a later definition for
-the symbol is encountered. This is the same as the previous case,
-except that the symbols are encountered in a different order.
-.Sp
-.Vb 3
-\& <file>(<section>): warning: definition of \`<symbol>\*(Aq
-\& overriding common
-\& <file>(<section>): warning: common is here
-.Ve
-.IP "3." 4
-Merging a common symbol with a previous same-sized common symbol.
-.Sp
-.Vb 3
-\& <file>(<section>): warning: multiple common
-\& of \`<symbol>\*(Aq
-\& <file>(<section>): warning: previous common is here
-.Ve
-.IP "4." 4
-Merging a common symbol with a previous larger common symbol.
-.Sp
-.Vb 3
-\& <file>(<section>): warning: common of \`<symbol>\*(Aq
-\& overridden by larger common
-\& <file>(<section>): warning: larger common is here
-.Ve
-.IP "5." 4
-Merging a common symbol with a previous smaller common symbol. This is
-the same as the previous case, except that the symbols are
-encountered in a different order.
-.Sp
-.Vb 3
-\& <file>(<section>): warning: common of \`<symbol>\*(Aq
-\& overriding smaller common
-\& <file>(<section>): warning: smaller common is here
-.Ve
-.RE
-.RS 4
-.RE
-.IP "\fB\-\-warn\-constructors\fR" 4
-.IX Item "--warn-constructors"
-Warn if any global constructors are used. This is only useful for a few
-object file formats. For formats like \s-1COFF\s0 or \s-1ELF\s0, the linker can not
-detect the use of global constructors.
-.IP "\fB\-\-warn\-multiple\-gp\fR" 4
-.IX Item "--warn-multiple-gp"
-Warn if multiple global pointer values are required in the output file.
-This is only meaningful for certain processors, such as the Alpha.
-Specifically, some processors put large-valued constants in a special
-section. A special register (the global pointer) points into the middle
-of this section, so that constants can be loaded efficiently via a
-base-register relative addressing mode. Since the offset in
-base-register relative mode is fixed and relatively small (e.g., 16
-bits), this limits the maximum size of the constant pool. Thus, in
-large programs, it is often necessary to use multiple global pointer
-values in order to be able to address all possible constants. This
-option causes a warning to be issued whenever this case occurs.
-.IP "\fB\-\-warn\-once\fR" 4
-.IX Item "--warn-once"
-Only warn once for each undefined symbol, rather than once per module
-which refers to it.
-.IP "\fB\-\-warn\-section\-align\fR" 4
-.IX Item "--warn-section-align"
-Warn if the address of an output section is changed because of
-alignment. Typically, the alignment will be set by an input section.
-The address will only be changed if it not explicitly specified; that
-is, if the \f(CW\*(C`SECTIONS\*(C'\fR command does not specify a start address for
-the section.
-.IP "\fB\-\-warn\-shared\-textrel\fR" 4
-.IX Item "--warn-shared-textrel"
-Warn if the linker adds a \s-1DT_TEXTREL\s0 to a shared object.
-.IP "\fB\-\-warn\-alternate\-em\fR" 4
-.IX Item "--warn-alternate-em"
-Warn if an object has alternate \s-1ELF\s0 machine code.
-.IP "\fB\-\-warn\-unresolved\-symbols\fR" 4
-.IX Item "--warn-unresolved-symbols"
-If the linker is going to report an unresolved symbol (see the option
-\&\fB\-\-unresolved\-symbols\fR) it will normally generate an error.
-This option makes it generate a warning instead.
-.IP "\fB\-\-error\-unresolved\-symbols\fR" 4
-.IX Item "--error-unresolved-symbols"
-This restores the linker's default behaviour of generating errors when
-it is reporting unresolved symbols.
-.IP "\fB\-\-whole\-archive\fR" 4
-.IX Item "--whole-archive"
-For each archive mentioned on the command line after the
-\&\fB\-\-whole\-archive\fR option, include every object file in the archive
-in the link, rather than searching the archive for the required object
-files. This is normally used to turn an archive file into a shared
-library, forcing every object to be included in the resulting shared
-library. This option may be used more than once.
-.Sp
-Two notes when using this option from gcc: First, gcc doesn't know
-about this option, so you have to use \fB\-Wl,\-whole\-archive\fR.
-Second, don't forget to use \fB\-Wl,\-no\-whole\-archive\fR after your
-list of archives, because gcc will add its own list of archives to
-your link and you may not want this flag to affect those as well.
-.IP "\fB\-\-wrap=\fR\fIsymbol\fR" 4
-.IX Item "--wrap=symbol"
-Use a wrapper function for \fIsymbol\fR. Any undefined reference to
-\&\fIsymbol\fR will be resolved to \f(CW\*(C`_\|_wrap_\f(CIsymbol\f(CW\*(C'\fR. Any
-undefined reference to \f(CW\*(C`_\|_real_\f(CIsymbol\f(CW\*(C'\fR will be resolved to
-\&\fIsymbol\fR.
-.Sp
-This can be used to provide a wrapper for a system function. The
-wrapper function should be called \f(CW\*(C`_\|_wrap_\f(CIsymbol\f(CW\*(C'\fR. If it
-wishes to call the system function, it should call
-\&\f(CW\*(C`_\|_real_\f(CIsymbol\f(CW\*(C'\fR.
-.Sp
-Here is a trivial example:
-.Sp
-.Vb 6
-\& void *
-\& _\|_wrap_malloc (size_t c)
-\& {
-\& printf ("malloc called with %zu\en", c);
-\& return _\|_real_malloc (c);
-\& }
-.Ve
-.Sp
-If you link other code with this file using \fB\-\-wrap malloc\fR, then
-all calls to \f(CW\*(C`malloc\*(C'\fR will call the function \f(CW\*(C`_\|_wrap_malloc\*(C'\fR
-instead. The call to \f(CW\*(C`_\|_real_malloc\*(C'\fR in \f(CW\*(C`_\|_wrap_malloc\*(C'\fR will
-call the real \f(CW\*(C`malloc\*(C'\fR function.
-.Sp
-You may wish to provide a \f(CW\*(C`_\|_real_malloc\*(C'\fR function as well, so that
-links without the \fB\-\-wrap\fR option will succeed. If you do this,
-you should not put the definition of \f(CW\*(C`_\|_real_malloc\*(C'\fR in the same
-file as \f(CW\*(C`_\|_wrap_malloc\*(C'\fR; if you do, the assembler may resolve the
-call before the linker has a chance to wrap it to \f(CW\*(C`malloc\*(C'\fR.
-.IP "\fB\-\-eh\-frame\-hdr\fR" 4
-.IX Item "--eh-frame-hdr"
-Request creation of \f(CW\*(C`.eh_frame_hdr\*(C'\fR section and \s-1ELF\s0
-\&\f(CW\*(C`PT_GNU_EH_FRAME\*(C'\fR segment header.
-.IP "\fB\-\-enable\-new\-dtags\fR" 4
-.IX Item "--enable-new-dtags"
-.PD 0
-.IP "\fB\-\-disable\-new\-dtags\fR" 4
-.IX Item "--disable-new-dtags"
-.PD
-This linker can create the new dynamic tags in \s-1ELF\s0. But the older \s-1ELF\s0
-systems may not understand them. If you specify
-\&\fB\-\-enable\-new\-dtags\fR, the dynamic tags will be created as needed.
-If you specify \fB\-\-disable\-new\-dtags\fR, no new dynamic tags will be
-created. By default, the new dynamic tags are not created. Note that
-those options are only available for \s-1ELF\s0 systems.
-.IP "\fB\-\-hash\-size=\fR\fInumber\fR" 4
-.IX Item "--hash-size=number"
-Set the default size of the linker's hash tables to a prime number
-close to \fInumber\fR. Increasing this value can reduce the length of
-time it takes the linker to perform its tasks, at the expense of
-increasing the linker's memory requirements. Similarly reducing this
-value can reduce the memory requirements at the expense of speed.
-.IP "\fB\-\-hash\-style=\fR\fIstyle\fR" 4
-.IX Item "--hash-style=style"
-Set the type of linker's hash table(s). \fIstyle\fR can be either
-\&\f(CW\*(C`sysv\*(C'\fR for classic \s-1ELF\s0 \f(CW\*(C`.hash\*(C'\fR section, \f(CW\*(C`gnu\*(C'\fR for
-new style \s-1GNU\s0 \f(CW\*(C`.gnu.hash\*(C'\fR section or \f(CW\*(C`both\*(C'\fR for both
-the classic \s-1ELF\s0 \f(CW\*(C`.hash\*(C'\fR and new style \s-1GNU\s0 \f(CW\*(C`.gnu.hash\*(C'\fR
-hash tables. The default is \f(CW\*(C`sysv\*(C'\fR.
-.IP "\fB\-\-reduce\-memory\-overheads\fR" 4
-.IX Item "--reduce-memory-overheads"
-This option reduces memory requirements at ld runtime, at the expense of
-linking speed. This was introduced to select the old O(n^2) algorithm
-for link map file generation, rather than the new O(n) algorithm which uses
-about 40% more memory for symbol storage.
-.Sp
-Another effect of the switch is to set the default hash table size to
-1021, which again saves memory at the cost of lengthening the linker's
-run time. This is not done however if the \fB\-\-hash\-size\fR switch
-has been used.
-.Sp
-The \fB\-\-reduce\-memory\-overheads\fR switch may be also be used to
-enable other tradeoffs in future versions of the linker.
-.IP "\fB\-\-build\-id\fR" 4
-.IX Item "--build-id"
-.PD 0
-.IP "\fB\-\-build\-id=\fR\fIstyle\fR" 4
-.IX Item "--build-id=style"
-.PD
-Request creation of \f(CW\*(C`.note.gnu.build\-id\*(C'\fR \s-1ELF\s0 note section.
-The contents of the note are unique bits identifying this linked
-file. \fIstyle\fR can be \f(CW\*(C`uuid\*(C'\fR to use 128 random bits,
-\&\f(CW\*(C`sha1\*(C'\fR to use a 160\-bit \s-1SHA1\s0 hash on the normative
-parts of the output contents, \f(CW\*(C`md5\*(C'\fR to use a 128\-bit
-\&\s-1MD5\s0 hash on the normative parts of the output contents, or
-\&\f(CW\*(C`0x\f(CIhexstring\f(CW\*(C'\fR to use a chosen bit string specified as
-an even number of hexadecimal digits (\f(CW\*(C`\-\*(C'\fR and \f(CW\*(C`:\*(C'\fR
-characters between digit pairs are ignored). If \fIstyle\fR is
-omitted, \f(CW\*(C`sha1\*(C'\fR is used.
-.Sp
-The \f(CW\*(C`md5\*(C'\fR and \f(CW\*(C`sha1\*(C'\fR styles produces an identifier
-that is always the same in an identical output file, but will be
-unique among all nonidentical output files. It is not intended
-to be compared as a checksum for the file's contents. A linked
-file may be changed later by other tools, but the build \s-1ID\s0 bit
-string identifying the original linked file does not change.
-.Sp
-Passing \f(CW\*(C`none\*(C'\fR for \fIstyle\fR disables the setting from any
-\&\f(CW\*(C`\-\-build\-id\*(C'\fR options earlier on the command line.
-.PP
-The i386 \s-1PE\s0 linker supports the \fB\-shared\fR option, which causes
-the output to be a dynamically linked library (\s-1DLL\s0) instead of a
-normal executable. You should name the output \f(CW\*(C`*.dll\*(C'\fR when you
-use this option. In addition, the linker fully supports the standard
-\&\f(CW\*(C`*.def\*(C'\fR files, which may be specified on the linker command line
-like an object file (in fact, it should precede archives it exports
-symbols from, to ensure that they get linked in, just like a normal
-object file).
-.PP
-In addition to the options common to all targets, the i386 \s-1PE\s0 linker
-support additional command line options that are specific to the i386
-\&\s-1PE\s0 target. Options that take values may be separated from their
-values by either a space or an equals sign.
-.IP "\fB\-\-add\-stdcall\-alias\fR" 4
-.IX Item "--add-stdcall-alias"
-If given, symbols with a stdcall suffix (@\fInn\fR) will be exported
-as-is and also with the suffix stripped.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-base\-file\fR \fIfile\fR" 4
-.IX Item "--base-file file"
-Use \fIfile\fR as the name of a file in which to save the base
-addresses of all the relocations needed for generating DLLs with
-\&\fIdlltool\fR.
-[This is an i386 \s-1PE\s0 specific option]
-.IP "\fB\-\-dll\fR" 4
-.IX Item "--dll"
-Create a \s-1DLL\s0 instead of a regular executable. You may also use
-\&\fB\-shared\fR or specify a \f(CW\*(C`LIBRARY\*(C'\fR in a given \f(CW\*(C`.def\*(C'\fR
-file.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-enable\-long\-section\-names\fR" 4
-.IX Item "--enable-long-section-names"
-.PD 0
-.IP "\fB\-\-disable\-long\-section\-names\fR" 4
-.IX Item "--disable-long-section-names"
-.PD
-The \s-1PE\s0 variants of the Coff object format add an extension that permits
-the use of section names longer than eight characters, the normal limit
-for Coff. By default, these names are only allowed in object files, as
-fully-linked executable images do not carry the Coff string table required
-to support the longer names. As a \s-1GNU\s0 extension, it is possible to
-allow their use in executable images as well, or to (probably pointlessly!)
-disallow it in object files, by using these two options. Executable images
-generated with these long section names are slightly non-standard, carrying
-as they do a string table, and may generate confusing output when examined
-with non-GNU PE-aware tools, such as file viewers and dumpers. However,
-\&\s-1GDB\s0 relies on the use of \s-1PE\s0 long section names to find Dwarf\-2 debug
-information sections in an executable image at runtime, and so if neither
-option is specified on the command-line, \fBld\fR will enable long
-section names, overriding the default and technically correct behaviour,
-when it finds the presence of debug information while linking an executable
-image and not stripping symbols.
-[This option is valid for all \s-1PE\s0 targeted ports of the linker]
-.IP "\fB\-\-enable\-stdcall\-fixup\fR" 4
-.IX Item "--enable-stdcall-fixup"
-.PD 0
-.IP "\fB\-\-disable\-stdcall\-fixup\fR" 4
-.IX Item "--disable-stdcall-fixup"
-.PD
-If the link finds a symbol that it cannot resolve, it will attempt to
-do \*(L"fuzzy linking\*(R" by looking for another defined symbol that differs
-only in the format of the symbol name (cdecl vs stdcall) and will
-resolve that symbol by linking to the match. For example, the
-undefined symbol \f(CW\*(C`_foo\*(C'\fR might be linked to the function
-\&\f(CW\*(C`_foo@12\*(C'\fR, or the undefined symbol \f(CW\*(C`_bar@16\*(C'\fR might be linked
-to the function \f(CW\*(C`_bar\*(C'\fR. When the linker does this, it prints a
-warning, since it normally should have failed to link, but sometimes
-import libraries generated from third-party dlls may need this feature
-to be usable. If you specify \fB\-\-enable\-stdcall\-fixup\fR, this
-feature is fully enabled and warnings are not printed. If you specify
-\&\fB\-\-disable\-stdcall\-fixup\fR, this feature is disabled and such
-mismatches are considered to be errors.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-leading\-underscore\fR" 4
-.IX Item "--leading-underscore"
-.PD 0
-.IP "\fB\-\-no\-leading\-underscore\fR" 4
-.IX Item "--no-leading-underscore"
-.PD
-For most targets default symbol-prefix is an underscore and is defined
-in target's description. By this option it is possible to
-disable/enable the default underscore symbol-prefix.
-.IP "\fB\-\-export\-all\-symbols\fR" 4
-.IX Item "--export-all-symbols"
-If given, all global symbols in the objects used to build a \s-1DLL\s0 will
-be exported by the \s-1DLL\s0. Note that this is the default if there
-otherwise wouldn't be any exported symbols. When symbols are
-explicitly exported via \s-1DEF\s0 files or implicitly exported via function
-attributes, the default is to not export anything else unless this
-option is given. Note that the symbols \f(CW\*(C`DllMain@12\*(C'\fR,
-\&\f(CW\*(C`DllEntryPoint@0\*(C'\fR, \f(CW\*(C`DllMainCRTStartup@12\*(C'\fR, and
-\&\f(CW\*(C`impure_ptr\*(C'\fR will not be automatically
-exported. Also, symbols imported from other DLLs will not be
-re-exported, nor will symbols specifying the \s-1DLL\s0's internal layout
-such as those beginning with \f(CW\*(C`_head_\*(C'\fR or ending with
-\&\f(CW\*(C`_iname\*(C'\fR. In addition, no symbols from \f(CW\*(C`libgcc\*(C'\fR,
-\&\f(CW\*(C`libstd++\*(C'\fR, \f(CW\*(C`libmingw32\*(C'\fR, or \f(CW\*(C`crtX.o\*(C'\fR will be exported.
-Symbols whose names begin with \f(CW\*(C`_\|_rtti_\*(C'\fR or \f(CW\*(C`_\|_builtin_\*(C'\fR will
-not be exported, to help with \*(C+ DLLs. Finally, there is an
-extensive list of cygwin-private symbols that are not exported
-(obviously, this applies on when building DLLs for cygwin targets).
-These cygwin-excludes are: \f(CW\*(C`_cygwin_dll_entry@12\*(C'\fR,
-\&\f(CW\*(C`_cygwin_crt0_common@8\*(C'\fR, \f(CW\*(C`_cygwin_noncygwin_dll_entry@12\*(C'\fR,
-\&\f(CW\*(C`_fmode\*(C'\fR, \f(CW\*(C`_impure_ptr\*(C'\fR, \f(CW\*(C`cygwin_attach_dll\*(C'\fR,
-\&\f(CW\*(C`cygwin_premain0\*(C'\fR, \f(CW\*(C`cygwin_premain1\*(C'\fR, \f(CW\*(C`cygwin_premain2\*(C'\fR,
-\&\f(CW\*(C`cygwin_premain3\*(C'\fR, and \f(CW\*(C`environ\*(C'\fR.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-exclude\-symbols\fR \fIsymbol\fR\fB,\fR\fIsymbol\fR\fB,...\fR" 4
-.IX Item "--exclude-symbols symbol,symbol,..."
-Specifies a list of symbols which should not be automatically
-exported. The symbol names may be delimited by commas or colons.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-exclude\-all\-symbols\fR" 4
-.IX Item "--exclude-all-symbols"
-Specifies no symbols should be automatically exported.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-file\-alignment\fR" 4
-.IX Item "--file-alignment"
-Specify the file alignment. Sections in the file will always begin at
-file offsets which are multiples of this number. This defaults to
-512.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-heap\fR \fIreserve\fR" 4
-.IX Item "--heap reserve"
-.PD 0
-.IP "\fB\-\-heap\fR \fIreserve\fR\fB,\fR\fIcommit\fR" 4
-.IX Item "--heap reserve,commit"
-.PD
-Specify the number of bytes of memory to reserve (and optionally commit)
-to be used as heap for this program. The default is 1Mb reserved, 4K
-committed.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-image\-base\fR \fIvalue\fR" 4
-.IX Item "--image-base value"
-Use \fIvalue\fR as the base address of your program or dll. This is
-the lowest memory location that will be used when your program or dll
-is loaded. To reduce the need to relocate and improve performance of
-your dlls, each should have a unique base address and not overlap any
-other dlls. The default is 0x400000 for executables, and 0x10000000
-for dlls.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-kill\-at\fR" 4
-.IX Item "--kill-at"
-If given, the stdcall suffixes (@\fInn\fR) will be stripped from
-symbols before they are exported.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-large\-address\-aware\fR" 4
-.IX Item "--large-address-aware"
-If given, the appropriate bit in the \*(L"Characteristics\*(R" field of the \s-1COFF\s0
-header is set to indicate that this executable supports virtual addresses
-greater than 2 gigabytes. This should be used in conjunction with the /3GB
-or /USERVA=\fIvalue\fR megabytes switch in the \*(L"[operating systems]\*(R"
-section of the \s-1BOOT\s0.INI. Otherwise, this bit has no effect.
-[This option is specific to \s-1PE\s0 targeted ports of the linker]
-.IP "\fB\-\-major\-image\-version\fR \fIvalue\fR" 4
-.IX Item "--major-image-version value"
-Sets the major number of the \*(L"image version\*(R". Defaults to 1.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-major\-os\-version\fR \fIvalue\fR" 4
-.IX Item "--major-os-version value"
-Sets the major number of the \*(L"os version\*(R". Defaults to 4.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-major\-subsystem\-version\fR \fIvalue\fR" 4
-.IX Item "--major-subsystem-version value"
-Sets the major number of the \*(L"subsystem version\*(R". Defaults to 4.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-minor\-image\-version\fR \fIvalue\fR" 4
-.IX Item "--minor-image-version value"
-Sets the minor number of the \*(L"image version\*(R". Defaults to 0.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-minor\-os\-version\fR \fIvalue\fR" 4
-.IX Item "--minor-os-version value"
-Sets the minor number of the \*(L"os version\*(R". Defaults to 0.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-minor\-subsystem\-version\fR \fIvalue\fR" 4
-.IX Item "--minor-subsystem-version value"
-Sets the minor number of the \*(L"subsystem version\*(R". Defaults to 0.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-output\-def\fR \fIfile\fR" 4
-.IX Item "--output-def file"
-The linker will create the file \fIfile\fR which will contain a \s-1DEF\s0
-file corresponding to the \s-1DLL\s0 the linker is generating. This \s-1DEF\s0 file
-(which should be called \f(CW\*(C`*.def\*(C'\fR) may be used to create an import
-library with \f(CW\*(C`dlltool\*(C'\fR or may be used as a reference to
-automatically or implicitly exported symbols.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-out\-implib\fR \fIfile\fR" 4
-.IX Item "--out-implib file"
-The linker will create the file \fIfile\fR which will contain an
-import lib corresponding to the \s-1DLL\s0 the linker is generating. This
-import lib (which should be called \f(CW\*(C`*.dll.a\*(C'\fR or \f(CW\*(C`*.a\*(C'\fR
-may be used to link clients against the generated \s-1DLL\s0; this behaviour
-makes it possible to skip a separate \f(CW\*(C`dlltool\*(C'\fR import library
-creation step.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-enable\-auto\-image\-base\fR" 4
-.IX Item "--enable-auto-image-base"
-Automatically choose the image base for DLLs, unless one is specified
-using the \f(CW\*(C`\-\-image\-base\*(C'\fR argument. By using a hash generated
-from the dllname to create unique image bases for each \s-1DLL\s0, in-memory
-collisions and relocations which can delay program execution are
-avoided.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-disable\-auto\-image\-base\fR" 4
-.IX Item "--disable-auto-image-base"
-Do not automatically generate a unique image base. If there is no
-user-specified image base (\f(CW\*(C`\-\-image\-base\*(C'\fR) then use the platform
-default.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-dll\-search\-prefix\fR \fIstring\fR" 4
-.IX Item "--dll-search-prefix string"
-When linking dynamically to a dll without an import library,
-search for \f(CW\*(C`<string><basename>.dll\*(C'\fR in preference to
-\&\f(CW\*(C`lib<basename>.dll\*(C'\fR. This behaviour allows easy distinction
-between DLLs built for the various \*(L"subplatforms\*(R": native, cygwin,
-uwin, pw, etc. For instance, cygwin DLLs typically use
-\&\f(CW\*(C`\-\-dll\-search\-prefix=cyg\*(C'\fR.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-enable\-auto\-import\fR" 4
-.IX Item "--enable-auto-import"
-Do sophisticated linking of \f(CW\*(C`_symbol\*(C'\fR to \f(CW\*(C`_\|_imp_\|_symbol\*(C'\fR for
-\&\s-1DATA\s0 imports from DLLs, and create the necessary thunking symbols when
-building the import libraries with those \s-1DATA\s0 exports. Note: Use of the
-\&'auto\-import' extension will cause the text section of the image file
-to be made writable. This does not conform to the PE-COFF format
-specification published by Microsoft.
-.Sp
-Note \- use of the 'auto\-import' extension will also cause read only
-data which would normally be placed into the .rdata section to be
-placed into the .data section instead. This is in order to work
-around a problem with consts that is described here:
-http://www.cygwin.com/ml/cygwin/2004\-09/msg01101.html
-.Sp
-Using 'auto\-import' generally will 'just work' \*(-- but sometimes you may
-see this message:
-.Sp
-"variable '<var>' can't be auto-imported. Please read the
-documentation for ld's \f(CW\*(C`\-\-enable\-auto\-import\*(C'\fR for details."
-.Sp
-This message occurs when some (sub)expression accesses an address
-ultimately given by the sum of two constants (Win32 import tables only
-allow one). Instances where this may occur include accesses to member
-fields of struct variables imported from a \s-1DLL\s0, as well as using a
-constant index into an array variable imported from a \s-1DLL\s0. Any
-multiword variable (arrays, structs, long long, etc) may trigger
-this error condition. However, regardless of the exact data type
-of the offending exported variable, ld will always detect it, issue
-the warning, and exit.
-.Sp
-There are several ways to address this difficulty, regardless of the
-data type of the exported variable:
-.Sp
-One way is to use \-\-enable\-runtime\-pseudo\-reloc switch. This leaves the task
-of adjusting references in your client code for runtime environment, so
-this method works only when runtime environment supports this feature.
-.Sp
-A second solution is to force one of the 'constants' to be a variable \*(--
-that is, unknown and un-optimizable at compile time. For arrays,
-there are two possibilities: a) make the indexee (the array's address)
-a variable, or b) make the 'constant' index a variable. Thus:
-.Sp
-.Vb 3
-\& extern type extern_array[];
-\& extern_array[1] \-\->
-\& { volatile type *t=extern_array; t[1] }
-.Ve
-.Sp
-or
-.Sp
-.Vb 3
-\& extern type extern_array[];
-\& extern_array[1] \-\->
-\& { volatile int t=1; extern_array[t] }
-.Ve
-.Sp
-For structs (and most other multiword data types) the only option
-is to make the struct itself (or the long long, or the ...) variable:
-.Sp
-.Vb 3
-\& extern struct s extern_struct;
-\& extern_struct.field \-\->
-\& { volatile struct s *t=&extern_struct; t\->field }
-.Ve
-.Sp
-or
-.Sp
-.Vb 3
-\& extern long long extern_ll;
-\& extern_ll \-\->
-\& { volatile long long * local_ll=&extern_ll; *local_ll }
-.Ve
-.Sp
-A third method of dealing with this difficulty is to abandon
-\&'auto\-import' for the offending symbol and mark it with
-\&\f(CW\*(C`_\|_declspec(dllimport)\*(C'\fR. However, in practise that
-requires using compile-time #defines to indicate whether you are
-building a \s-1DLL\s0, building client code that will link to the \s-1DLL\s0, or
-merely building/linking to a static library. In making the choice
-between the various methods of resolving the 'direct address with
-constant offset' problem, you should consider typical real-world usage:
-.Sp
-Original:
-.Sp
-.Vb 7
-\& \-\-foo.h
-\& extern int arr[];
-\& \-\-foo.c
-\& #include "foo.h"
-\& void main(int argc, char **argv){
-\& printf("%d\en",arr[1]);
-\& }
-.Ve
-.Sp
-Solution 1:
-.Sp
-.Vb 9
-\& \-\-foo.h
-\& extern int arr[];
-\& \-\-foo.c
-\& #include "foo.h"
-\& void main(int argc, char **argv){
-\& /* This workaround is for win32 and cygwin; do not "optimize" */
-\& volatile int *parr = arr;
-\& printf("%d\en",parr[1]);
-\& }
-.Ve
-.Sp
-Solution 2:
-.Sp
-.Vb 10
-\& \-\-foo.h
-\& /* Note: auto\-export is assumed (no _\|_declspec(dllexport)) */
-\& #if (defined(_WIN32) || defined(_\|_CYGWIN_\|_)) && \e
-\& !(defined(FOO_BUILD_DLL) || defined(FOO_STATIC))
-\& #define FOO_IMPORT _\|_declspec(dllimport)
-\& #else
-\& #define FOO_IMPORT
-\& #endif
-\& extern FOO_IMPORT int arr[];
-\& \-\-foo.c
-\& #include "foo.h"
-\& void main(int argc, char **argv){
-\& printf("%d\en",arr[1]);
-\& }
-.Ve
-.Sp
-A fourth way to avoid this problem is to re-code your
-library to use a functional interface rather than a data interface
-for the offending variables (e.g. \fIset_foo()\fR and \fIget_foo()\fR accessor
-functions).
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-disable\-auto\-import\fR" 4
-.IX Item "--disable-auto-import"
-Do not attempt to do sophisticated linking of \f(CW\*(C`_symbol\*(C'\fR to
-\&\f(CW\*(C`_\|_imp_\|_symbol\*(C'\fR for \s-1DATA\s0 imports from DLLs.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-enable\-runtime\-pseudo\-reloc\fR" 4
-.IX Item "--enable-runtime-pseudo-reloc"
-If your code contains expressions described in \-\-enable\-auto\-import section,
-that is, \s-1DATA\s0 imports from \s-1DLL\s0 with non-zero offset, this switch will create
-a vector of 'runtime pseudo relocations' which can be used by runtime
-environment to adjust references to such data in your client code.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-disable\-runtime\-pseudo\-reloc\fR" 4
-.IX Item "--disable-runtime-pseudo-reloc"
-Do not create pseudo relocations for non-zero offset \s-1DATA\s0 imports from
-DLLs. This is the default.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-enable\-extra\-pe\-debug\fR" 4
-.IX Item "--enable-extra-pe-debug"
-Show additional debug info related to auto-import symbol thunking.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-section\-alignment\fR" 4
-.IX Item "--section-alignment"
-Sets the section alignment. Sections in memory will always begin at
-addresses which are a multiple of this number. Defaults to 0x1000.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-stack\fR \fIreserve\fR" 4
-.IX Item "--stack reserve"
-.PD 0
-.IP "\fB\-\-stack\fR \fIreserve\fR\fB,\fR\fIcommit\fR" 4
-.IX Item "--stack reserve,commit"
-.PD
-Specify the number of bytes of memory to reserve (and optionally commit)
-to be used as stack for this program. The default is 2Mb reserved, 4K
-committed.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.IP "\fB\-\-subsystem\fR \fIwhich\fR" 4
-.IX Item "--subsystem which"
-.PD 0
-.IP "\fB\-\-subsystem\fR \fIwhich\fR\fB:\fR\fImajor\fR" 4
-.IX Item "--subsystem which:major"
-.IP "\fB\-\-subsystem\fR \fIwhich\fR\fB:\fR\fImajor\fR\fB.\fR\fIminor\fR" 4
-.IX Item "--subsystem which:major.minor"
-.PD
-Specifies the subsystem under which your program will execute. The
-legal values for \fIwhich\fR are \f(CW\*(C`native\*(C'\fR, \f(CW\*(C`windows\*(C'\fR,
-\&\f(CW\*(C`console\*(C'\fR, \f(CW\*(C`posix\*(C'\fR, and \f(CW\*(C`xbox\*(C'\fR. You may optionally set
-the subsystem version also. Numeric values are also accepted for
-\&\fIwhich\fR.
-[This option is specific to the i386 \s-1PE\s0 targeted port of the linker]
-.Sp
-The following options set flags in the \f(CW\*(C`DllCharacteristics\*(C'\fR field
-of the \s-1PE\s0 file header:
-[These options are specific to \s-1PE\s0 targeted ports of the linker]
-.IP "\fB\-\-dynamicbase\fR" 4
-.IX Item "--dynamicbase"
-The image base address may be relocated using address space layout
-randomization (\s-1ASLR\s0). This feature was introduced with \s-1MS\s0 Windows
-Vista for i386 \s-1PE\s0 targets.
-.IP "\fB\-\-forceinteg\fR" 4
-.IX Item "--forceinteg"
-Code integrity checks are enforced.
-.IP "\fB\-\-nxcompat\fR" 4
-.IX Item "--nxcompat"
-The image is compatible with the Data Execution Prevention.
-This feature was introduced with \s-1MS\s0 Windows \s-1XP\s0 \s-1SP2\s0 for i386 \s-1PE\s0 targets.
-.IP "\fB\-\-no\-isolation\fR" 4
-.IX Item "--no-isolation"
-Although the image understands isolation, do not isolate the image.
-.IP "\fB\-\-no\-seh\fR" 4
-.IX Item "--no-seh"
-The image does not use \s-1SEH\s0. No \s-1SE\s0 handler may be called from
-this image.
-.IP "\fB\-\-no\-bind\fR" 4
-.IX Item "--no-bind"
-Do not bind this image.
-.IP "\fB\-\-wdmdriver\fR" 4
-.IX Item "--wdmdriver"
-The driver uses the \s-1MS\s0 Windows Driver Model.
-.IP "\fB\-\-tsaware\fR" 4
-.IX Item "--tsaware"
-The image is Terminal Server aware.
-.PP
-The 68HC11 and 68HC12 linkers support specific options to control the
-memory bank switching mapping and trampoline code generation.
-.IP "\fB\-\-no\-trampoline\fR" 4
-.IX Item "--no-trampoline"
-This option disables the generation of trampoline. By default a trampoline
-is generated for each far function which is called using a \f(CW\*(C`jsr\*(C'\fR
-instruction (this happens when a pointer to a far function is taken).
-.IP "\fB\-\-bank\-window\fR \fIname\fR" 4
-.IX Item "--bank-window name"
-This option indicates to the linker the name of the memory region in
-the \fB\s-1MEMORY\s0\fR specification that describes the memory bank window.
-The definition of such region is then used by the linker to compute
-paging and addresses within the memory window.
-.PP
-The following options are supported to control handling of \s-1GOT\s0 generation
-when linking for 68K targets.
-.IP "\fB\-\-got=\fR\fItype\fR" 4
-.IX Item "--got=type"
-This option tells the linker which \s-1GOT\s0 generation scheme to use.
-\&\fItype\fR should be one of \fBsingle\fR, \fBnegative\fR,
-\&\fBmultigot\fR or \fBtarget\fR. For more information refer to the
-Info entry for \fIld\fR.
-.SH "ENVIRONMENT"
-.IX Header "ENVIRONMENT"
-You can change the behaviour of \fBld\fR with the environment variables
-\&\f(CW\*(C`GNUTARGET\*(C'\fR,
-\&\f(CW\*(C`LDEMULATION\*(C'\fR and \f(CW\*(C`COLLECT_NO_DEMANGLE\*(C'\fR.
-.PP
-\&\f(CW\*(C`GNUTARGET\*(C'\fR determines the input-file object format if you don't
-use \fB\-b\fR (or its synonym \fB\-\-format\fR). Its value should be one
-of the \s-1BFD\s0 names for an input format. If there is no
-\&\f(CW\*(C`GNUTARGET\*(C'\fR in the environment, \fBld\fR uses the natural format
-of the target. If \f(CW\*(C`GNUTARGET\*(C'\fR is set to \f(CW\*(C`default\*(C'\fR then \s-1BFD\s0
-attempts to discover the input format by examining binary input files;
-this method often succeeds, but there are potential ambiguities, since
-there is no method of ensuring that the magic number used to specify
-object-file formats is unique. However, the configuration procedure for
-\&\s-1BFD\s0 on each system places the conventional format for that system first
-in the search-list, so ambiguities are resolved in favor of convention.
-.PP
-\&\f(CW\*(C`LDEMULATION\*(C'\fR determines the default emulation if you don't use the
-\&\fB\-m\fR option. The emulation can affect various aspects of linker
-behaviour, particularly the default linker script. You can list the
-available emulations with the \fB\-\-verbose\fR or \fB\-V\fR options. If
-the \fB\-m\fR option is not used, and the \f(CW\*(C`LDEMULATION\*(C'\fR environment
-variable is not defined, the default emulation depends upon how the
-linker was configured.
-.PP
-Normally, the linker will default to demangling symbols. However, if
-\&\f(CW\*(C`COLLECT_NO_DEMANGLE\*(C'\fR is set in the environment, then it will
-default to not demangling symbols. This environment variable is used in
-a similar fashion by the \f(CW\*(C`gcc\*(C'\fR linker wrapper program. The default
-may be overridden by the \fB\-\-demangle\fR and \fB\-\-no\-demangle\fR
-options.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIar\fR\|(1), \fInm\fR\|(1), \fIobjcopy\fR\|(1), \fIobjdump\fR\|(1), \fIreadelf\fR\|(1) and
-the Info entries for \fIbinutils\fR and
-\&\fIld\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free
-Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-nlmconv.1 b/share/man/man1/arm-eabi-nlmconv.1
deleted file mode 100644
index a43abb1..0000000
--- a/share/man/man1/arm-eabi-nlmconv.1
+++ /dev/null
@@ -1,244 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "NLMCONV 1"
-.TH NLMCONV 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-nlmconv \- converts object code into an NLM.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-nlmconv [\fB\-I\fR \fIbfdname\fR|\fB\-\-input\-target=\fR\fIbfdname\fR]
- [\fB\-O\fR \fIbfdname\fR|\fB\-\-output\-target=\fR\fIbfdname\fR]
- [\fB\-T\fR \fIheaderfile\fR|\fB\-\-header\-file=\fR\fIheaderfile\fR]
- [\fB\-d\fR|\fB\-\-debug\fR] [\fB\-l\fR \fIlinker\fR|\fB\-\-linker=\fR\fIlinker\fR]
- [\fB\-h\fR|\fB\-\-help\fR] [\fB\-V\fR|\fB\-\-version\fR]
- \fIinfile\fR \fIoutfile\fR
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\fBnlmconv\fR converts the relocatable \fBi386\fR object file
-\&\fIinfile\fR into the NetWare Loadable Module \fIoutfile\fR, optionally
-reading \fIheaderfile\fR for \s-1NLM\s0 header information. For instructions
-on writing the \s-1NLM\s0 command file language used in header files, see the
-\&\fBlinkers\fR section, \fB\s-1NLMLINK\s0\fR in particular, of the \fI\s-1NLM\s0
-Development and Tools Overview\fR, which is part of the \s-1NLM\s0 Software
-Developer's Kit (\*(L"\s-1NLM\s0 \s-1SDK\s0\*(R"), available from Novell, Inc.
-\&\fBnlmconv\fR uses the \s-1GNU\s0 Binary File Descriptor library to read
-\&\fIinfile\fR;
-.PP
-\&\fBnlmconv\fR can perform a link step. In other words, you can list
-more than one object file for input if you list them in the definitions
-file (rather than simply specifying one input file on the command line).
-In this case, \fBnlmconv\fR calls the linker for you.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.IP "\fB\-I\fR \fIbfdname\fR" 4
-.IX Item "-I bfdname"
-.PD 0
-.IP "\fB\-\-input\-target=\fR\fIbfdname\fR" 4
-.IX Item "--input-target=bfdname"
-.PD
-Object format of the input file. \fBnlmconv\fR can usually determine
-the format of a given file (so no default is necessary).
-.IP "\fB\-O\fR \fIbfdname\fR" 4
-.IX Item "-O bfdname"
-.PD 0
-.IP "\fB\-\-output\-target=\fR\fIbfdname\fR" 4
-.IX Item "--output-target=bfdname"
-.PD
-Object format of the output file. \fBnlmconv\fR infers the output
-format based on the input format, e.g. for a \fBi386\fR input file the
-output format is \fBnlm32\-i386\fR.
-.IP "\fB\-T\fR \fIheaderfile\fR" 4
-.IX Item "-T headerfile"
-.PD 0
-.IP "\fB\-\-header\-file=\fR\fIheaderfile\fR" 4
-.IX Item "--header-file=headerfile"
-.PD
-Reads \fIheaderfile\fR for \s-1NLM\s0 header information. For instructions on
-writing the \s-1NLM\s0 command file language used in header files, see see the
-\&\fBlinkers\fR section, of the \fI\s-1NLM\s0 Development and Tools
-Overview\fR, which is part of the \s-1NLM\s0 Software Developer's Kit, available
-from Novell, Inc.
-.IP "\fB\-d\fR" 4
-.IX Item "-d"
-.PD 0
-.IP "\fB\-\-debug\fR" 4
-.IX Item "--debug"
-.PD
-Displays (on standard error) the linker command line used by \fBnlmconv\fR.
-.IP "\fB\-l\fR \fIlinker\fR" 4
-.IX Item "-l linker"
-.PD 0
-.IP "\fB\-\-linker=\fR\fIlinker\fR" 4
-.IX Item "--linker=linker"
-.PD
-Use \fIlinker\fR for any linking. \fIlinker\fR can be an absolute or a
-relative pathname.
-.IP "\fB\-h\fR" 4
-.IX Item "-h"
-.PD 0
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-.PD
-Prints a usage summary.
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Prints the version number for \fBnlmconv\fR.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-nm.1 b/share/man/man1/arm-eabi-nm.1
deleted file mode 100644
index 8f629f9..0000000
--- a/share/man/man1/arm-eabi-nm.1
+++ /dev/null
@@ -1,516 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "NM 1"
-.TH NM 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-nm \- list symbols from object files
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-nm [\fB\-a\fR|\fB\-\-debug\-syms\fR]
- [\fB\-g\fR|\fB\-\-extern\-only\fR][\fB\-\-plugin\fR \fIname\fR]
- [\fB\-B\fR] [\fB\-C\fR|\fB\-\-demangle\fR[=\fIstyle\fR]] [\fB\-D\fR|\fB\-\-dynamic\fR]
- [\fB\-S\fR|\fB\-\-print\-size\fR] [\fB\-s\fR|\fB\-\-print\-armap\fR]
- [\fB\-A\fR|\fB\-o\fR|\fB\-\-print\-file\-name\fR][\fB\-\-special\-syms\fR]
- [\fB\-n\fR|\fB\-v\fR|\fB\-\-numeric\-sort\fR] [\fB\-p\fR|\fB\-\-no\-sort\fR]
- [\fB\-r\fR|\fB\-\-reverse\-sort\fR] [\fB\-\-size\-sort\fR] [\fB\-u\fR|\fB\-\-undefined\-only\fR]
- [\fB\-t\fR \fIradix\fR|\fB\-\-radix=\fR\fIradix\fR] [\fB\-P\fR|\fB\-\-portability\fR]
- [\fB\-\-target=\fR\fIbfdname\fR] [\fB\-f\fR\fIformat\fR|\fB\-\-format=\fR\fIformat\fR]
- [\fB\-\-defined\-only\fR] [\fB\-l\fR|\fB\-\-line\-numbers\fR] [\fB\-\-no\-demangle\fR]
- [\fB\-V\fR|\fB\-\-version\fR] [\fB\-X 32_64\fR] [\fB\-\-help\fR] [\fIobjfile\fR...]
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\s-1GNU\s0 \fBnm\fR lists the symbols from object files \fIobjfile\fR....
-If no object files are listed as arguments, \fBnm\fR assumes the file
-\&\fIa.out\fR.
-.PP
-For each symbol, \fBnm\fR shows:
-.IP "\(bu" 4
-The symbol value, in the radix selected by options (see below), or
-hexadecimal by default.
-.IP "\(bu" 4
-The symbol type. At least the following types are used; others are, as
-well, depending on the object file format. If lowercase, the symbol is
-local; if uppercase, the symbol is global (external).
-.RS 4
-.ie n .IP """A""" 4
-.el .IP "\f(CWA\fR" 4
-.IX Item "A"
-The symbol's value is absolute, and will not be changed by further
-linking.
-.ie n .IP """B""" 4
-.el .IP "\f(CWB\fR" 4
-.IX Item "B"
-.PD 0
-.ie n .IP """b""" 4
-.el .IP "\f(CWb\fR" 4
-.IX Item "b"
-.PD
-The symbol is in the uninitialized data section (known as \s-1BSS\s0).
-.ie n .IP """C""" 4
-.el .IP "\f(CWC\fR" 4
-.IX Item "C"
-The symbol is common. Common symbols are uninitialized data. When
-linking, multiple common symbols may appear with the same name. If the
-symbol is defined anywhere, the common symbols are treated as undefined
-references.
-.ie n .IP """D""" 4
-.el .IP "\f(CWD\fR" 4
-.IX Item "D"
-.PD 0
-.ie n .IP """d""" 4
-.el .IP "\f(CWd\fR" 4
-.IX Item "d"
-.PD
-The symbol is in the initialized data section.
-.ie n .IP """G""" 4
-.el .IP "\f(CWG\fR" 4
-.IX Item "G"
-.PD 0
-.ie n .IP """g""" 4
-.el .IP "\f(CWg\fR" 4
-.IX Item "g"
-.PD
-The symbol is in an initialized data section for small objects. Some
-object file formats permit more efficient access to small data objects,
-such as a global int variable as opposed to a large global array.
-.ie n .IP """i""" 4
-.el .IP "\f(CWi\fR" 4
-.IX Item "i"
-For \s-1PE\s0 format files this indicates that the symbol is in a section
-specific to the implementation of DLLs. For \s-1ELF\s0 format files this
-indicates that the symbol is an indirect function. This is a \s-1GNU\s0
-extension to the standard set of \s-1ELF\s0 symbol types. It indicates a
-symbol which if referenced by a relocation does not evaluate to its
-address, but instead must be invoked at runtime. The runtime
-execution will then return the value to be used in the relocation.
-.ie n .IP """N""" 4
-.el .IP "\f(CWN\fR" 4
-.IX Item "N"
-The symbol is a debugging symbol.
-.ie n .IP """p""" 4
-.el .IP "\f(CWp\fR" 4
-.IX Item "p"
-The symbols is in a stack unwind section.
-.ie n .IP """R""" 4
-.el .IP "\f(CWR\fR" 4
-.IX Item "R"
-.PD 0
-.ie n .IP """r""" 4
-.el .IP "\f(CWr\fR" 4
-.IX Item "r"
-.PD
-The symbol is in a read only data section.
-.ie n .IP """S""" 4
-.el .IP "\f(CWS\fR" 4
-.IX Item "S"
-.PD 0
-.ie n .IP """s""" 4
-.el .IP "\f(CWs\fR" 4
-.IX Item "s"
-.PD
-The symbol is in an uninitialized data section for small objects.
-.ie n .IP """T""" 4
-.el .IP "\f(CWT\fR" 4
-.IX Item "T"
-.PD 0
-.ie n .IP """t""" 4
-.el .IP "\f(CWt\fR" 4
-.IX Item "t"
-.PD
-The symbol is in the text (code) section.
-.ie n .IP """U""" 4
-.el .IP "\f(CWU\fR" 4
-.IX Item "U"
-The symbol is undefined.
-.ie n .IP """u""" 4
-.el .IP "\f(CWu\fR" 4
-.IX Item "u"
-The symbol is a unique global symbol. This is a \s-1GNU\s0 extension to the
-standard set of \s-1ELF\s0 symbol bindings. For such a symbol the dynamic linker
-will make sure that in the entire process there is just one symbol with
-this name and type in use.
-.ie n .IP """V""" 4
-.el .IP "\f(CWV\fR" 4
-.IX Item "V"
-.PD 0
-.ie n .IP """v""" 4
-.el .IP "\f(CWv\fR" 4
-.IX Item "v"
-.PD
-The symbol is a weak object. When a weak defined symbol is linked with
-a normal defined symbol, the normal defined symbol is used with no error.
-When a weak undefined symbol is linked and the symbol is not defined,
-the value of the weak symbol becomes zero with no error. On some
-systems, uppercase indicates that a default value has been specified.
-.ie n .IP """W""" 4
-.el .IP "\f(CWW\fR" 4
-.IX Item "W"
-.PD 0
-.ie n .IP """w""" 4
-.el .IP "\f(CWw\fR" 4
-.IX Item "w"
-.PD
-The symbol is a weak symbol that has not been specifically tagged as a
-weak object symbol. When a weak defined symbol is linked with a normal
-defined symbol, the normal defined symbol is used with no error.
-When a weak undefined symbol is linked and the symbol is not defined,
-the value of the symbol is determined in a system-specific manner without
-error. On some systems, uppercase indicates that a default value has been
-specified.
-.ie n .IP """\-""" 4
-.el .IP "\f(CW\-\fR" 4
-.IX Item "-"
-The symbol is a stabs symbol in an a.out object file. In this case, the
-next values printed are the stabs other field, the stabs desc field, and
-the stab type. Stabs symbols are used to hold debugging information.
-.ie n .IP """?""" 4
-.el .IP "\f(CW?\fR" 4
-.IX Item "?"
-The symbol type is unknown, or object file format specific.
-.RE
-.RS 4
-.RE
-.IP "\(bu" 4
-The symbol name.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-The long and short forms of options, shown here as alternatives, are
-equivalent.
-.IP "\fB\-A\fR" 4
-.IX Item "-A"
-.PD 0
-.IP "\fB\-o\fR" 4
-.IX Item "-o"
-.IP "\fB\-\-print\-file\-name\fR" 4
-.IX Item "--print-file-name"
-.PD
-Precede each symbol by the name of the input file (or archive member)
-in which it was found, rather than identifying the input file once only,
-before all of its symbols.
-.IP "\fB\-a\fR" 4
-.IX Item "-a"
-.PD 0
-.IP "\fB\-\-debug\-syms\fR" 4
-.IX Item "--debug-syms"
-.PD
-Display all symbols, even debugger-only symbols; normally these are not
-listed.
-.IP "\fB\-B\fR" 4
-.IX Item "-B"
-The same as \fB\-\-format=bsd\fR (for compatibility with the \s-1MIPS\s0 \fBnm\fR).
-.IP "\fB\-C\fR" 4
-.IX Item "-C"
-.PD 0
-.IP "\fB\-\-demangle[=\fR\fIstyle\fR\fB]\fR" 4
-.IX Item "--demangle[=style]"
-.PD
-Decode (\fIdemangle\fR) low-level symbol names into user-level names.
-Besides removing any initial underscore prepended by the system, this
-makes \*(C+ function names readable. Different compilers have different
-mangling styles. The optional demangling style argument can be used to
-choose an appropriate demangling style for your compiler.
-.IP "\fB\-\-no\-demangle\fR" 4
-.IX Item "--no-demangle"
-Do not demangle low-level symbol names. This is the default.
-.IP "\fB\-D\fR" 4
-.IX Item "-D"
-.PD 0
-.IP "\fB\-\-dynamic\fR" 4
-.IX Item "--dynamic"
-.PD
-Display the dynamic symbols rather than the normal symbols. This is
-only meaningful for dynamic objects, such as certain types of shared
-libraries.
-.IP "\fB\-f\fR \fIformat\fR" 4
-.IX Item "-f format"
-.PD 0
-.IP "\fB\-\-format=\fR\fIformat\fR" 4
-.IX Item "--format=format"
-.PD
-Use the output format \fIformat\fR, which can be \f(CW\*(C`bsd\*(C'\fR,
-\&\f(CW\*(C`sysv\*(C'\fR, or \f(CW\*(C`posix\*(C'\fR. The default is \f(CW\*(C`bsd\*(C'\fR.
-Only the first character of \fIformat\fR is significant; it can be
-either upper or lower case.
-.IP "\fB\-g\fR" 4
-.IX Item "-g"
-.PD 0
-.IP "\fB\-\-extern\-only\fR" 4
-.IX Item "--extern-only"
-.PD
-Display only external symbols.
-.IP "\fB\-\-plugin\fR \fIname\fR" 4
-.IX Item "--plugin name"
-Load the plugin called \fIname\fR to add support for extra target
-types. This option is only available if the toolchain has been built
-with plugin support enabled.
-.IP "\fB\-l\fR" 4
-.IX Item "-l"
-.PD 0
-.IP "\fB\-\-line\-numbers\fR" 4
-.IX Item "--line-numbers"
-.PD
-For each symbol, use debugging information to try to find a filename and
-line number. For a defined symbol, look for the line number of the
-address of the symbol. For an undefined symbol, look for the line
-number of a relocation entry which refers to the symbol. If line number
-information can be found, print it after the other symbol information.
-.IP "\fB\-n\fR" 4
-.IX Item "-n"
-.PD 0
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.IP "\fB\-\-numeric\-sort\fR" 4
-.IX Item "--numeric-sort"
-.PD
-Sort symbols numerically by their addresses, rather than alphabetically
-by their names.
-.IP "\fB\-p\fR" 4
-.IX Item "-p"
-.PD 0
-.IP "\fB\-\-no\-sort\fR" 4
-.IX Item "--no-sort"
-.PD
-Do not bother to sort the symbols in any order; print them in the order
-encountered.
-.IP "\fB\-P\fR" 4
-.IX Item "-P"
-.PD 0
-.IP "\fB\-\-portability\fR" 4
-.IX Item "--portability"
-.PD
-Use the \s-1POSIX\s0.2 standard output format instead of the default format.
-Equivalent to \fB\-f posix\fR.
-.IP "\fB\-S\fR" 4
-.IX Item "-S"
-.PD 0
-.IP "\fB\-\-print\-size\fR" 4
-.IX Item "--print-size"
-.PD
-Print both value and size of defined symbols for the \f(CW\*(C`bsd\*(C'\fR output style.
-This option has no effect for object formats that do not record symbol
-sizes, unless \fB\-\-size\-sort\fR is also used in which case a
-calculated size is displayed.
-.IP "\fB\-s\fR" 4
-.IX Item "-s"
-.PD 0
-.IP "\fB\-\-print\-armap\fR" 4
-.IX Item "--print-armap"
-.PD
-When listing symbols from archive members, include the index: a mapping
-(stored in the archive by \fBar\fR or \fBranlib\fR) of which modules
-contain definitions for which names.
-.IP "\fB\-r\fR" 4
-.IX Item "-r"
-.PD 0
-.IP "\fB\-\-reverse\-sort\fR" 4
-.IX Item "--reverse-sort"
-.PD
-Reverse the order of the sort (whether numeric or alphabetic); let the
-last come first.
-.IP "\fB\-\-size\-sort\fR" 4
-.IX Item "--size-sort"
-Sort symbols by size. The size is computed as the difference between
-the value of the symbol and the value of the symbol with the next higher
-value. If the \f(CW\*(C`bsd\*(C'\fR output format is used the size of the symbol
-is printed, rather than the value, and \fB\-S\fR must be used in order
-both size and value to be printed.
-.IP "\fB\-\-special\-syms\fR" 4
-.IX Item "--special-syms"
-Display symbols which have a target-specific special meaning. These
-symbols are usually used by the target for some special processing and
-are not normally helpful when included included in the normal symbol
-lists. For example for \s-1ARM\s0 targets this option would skip the mapping
-symbols used to mark transitions between \s-1ARM\s0 code, \s-1THUMB\s0 code and
-data.
-.IP "\fB\-t\fR \fIradix\fR" 4
-.IX Item "-t radix"
-.PD 0
-.IP "\fB\-\-radix=\fR\fIradix\fR" 4
-.IX Item "--radix=radix"
-.PD
-Use \fIradix\fR as the radix for printing the symbol values. It must be
-\&\fBd\fR for decimal, \fBo\fR for octal, or \fBx\fR for hexadecimal.
-.IP "\fB\-\-target=\fR\fIbfdname\fR" 4
-.IX Item "--target=bfdname"
-Specify an object code format other than your system's default format.
-.IP "\fB\-u\fR" 4
-.IX Item "-u"
-.PD 0
-.IP "\fB\-\-undefined\-only\fR" 4
-.IX Item "--undefined-only"
-.PD
-Display only undefined symbols (those external to each object file).
-.IP "\fB\-\-defined\-only\fR" 4
-.IX Item "--defined-only"
-Display only defined symbols for each object file.
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Show the version number of \fBnm\fR and exit.
-.IP "\fB\-X\fR" 4
-.IX Item "-X"
-This option is ignored for compatibility with the \s-1AIX\s0 version of
-\&\fBnm\fR. It takes one parameter which must be the string
-\&\fB32_64\fR. The default mode of \s-1AIX\s0 \fBnm\fR corresponds
-to \fB\-X 32\fR, which is not supported by \s-1GNU\s0 \fBnm\fR.
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-Show a summary of the options to \fBnm\fR and exit.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIar\fR\|(1), \fIobjdump\fR\|(1), \fIranlib\fR\|(1), and the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-objcopy.1 b/share/man/man1/arm-eabi-objcopy.1
deleted file mode 100644
index fcceb65..0000000
--- a/share/man/man1/arm-eabi-objcopy.1
+++ /dev/null
@@ -1,960 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "OBJCOPY 1"
-.TH OBJCOPY 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-objcopy \- copy and translate object files
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-objcopy [\fB\-F\fR \fIbfdname\fR|\fB\-\-target=\fR\fIbfdname\fR]
- [\fB\-I\fR \fIbfdname\fR|\fB\-\-input\-target=\fR\fIbfdname\fR]
- [\fB\-O\fR \fIbfdname\fR|\fB\-\-output\-target=\fR\fIbfdname\fR]
- [\fB\-B\fR \fIbfdarch\fR|\fB\-\-binary\-architecture=\fR\fIbfdarch\fR]
- [\fB\-S\fR|\fB\-\-strip\-all\fR]
- [\fB\-g\fR|\fB\-\-strip\-debug\fR]
- [\fB\-K\fR \fIsymbolname\fR|\fB\-\-keep\-symbol=\fR\fIsymbolname\fR]
- [\fB\-N\fR \fIsymbolname\fR|\fB\-\-strip\-symbol=\fR\fIsymbolname\fR]
- [\fB\-\-strip\-unneeded\-symbol=\fR\fIsymbolname\fR]
- [\fB\-G\fR \fIsymbolname\fR|\fB\-\-keep\-global\-symbol=\fR\fIsymbolname\fR]
- [\fB\-\-localize\-hidden\fR]
- [\fB\-L\fR \fIsymbolname\fR|\fB\-\-localize\-symbol=\fR\fIsymbolname\fR]
- [\fB\-\-globalize\-symbol=\fR\fIsymbolname\fR]
- [\fB\-W\fR \fIsymbolname\fR|\fB\-\-weaken\-symbol=\fR\fIsymbolname\fR]
- [\fB\-w\fR|\fB\-\-wildcard\fR]
- [\fB\-x\fR|\fB\-\-discard\-all\fR]
- [\fB\-X\fR|\fB\-\-discard\-locals\fR]
- [\fB\-b\fR \fIbyte\fR|\fB\-\-byte=\fR\fIbyte\fR]
- [\fB\-i\fR [\fIbreadth\fR]|\fB\-\-interleave\fR[=\fIbreadth\fR]]
- [\fB\-\-interleave\-width=\fR\fIwidth\fR]
- [\fB\-j\fR \fIsectionname\fR|\fB\-\-only\-section=\fR\fIsectionname\fR]
- [\fB\-R\fR \fIsectionname\fR|\fB\-\-remove\-section=\fR\fIsectionname\fR]
- [\fB\-p\fR|\fB\-\-preserve\-dates\fR]
- [\fB\-\-debugging\fR]
- [\fB\-\-gap\-fill=\fR\fIval\fR]
- [\fB\-\-pad\-to=\fR\fIaddress\fR]
- [\fB\-\-set\-start=\fR\fIval\fR]
- [\fB\-\-adjust\-start=\fR\fIincr\fR]
- [\fB\-\-change\-addresses=\fR\fIincr\fR]
- [\fB\-\-change\-section\-address\fR \fIsection\fR{=,+,\-}\fIval\fR]
- [\fB\-\-change\-section\-lma\fR \fIsection\fR{=,+,\-}\fIval\fR]
- [\fB\-\-change\-section\-vma\fR \fIsection\fR{=,+,\-}\fIval\fR]
- [\fB\-\-change\-warnings\fR] [\fB\-\-no\-change\-warnings\fR]
- [\fB\-\-set\-section\-flags\fR \fIsection\fR=\fIflags\fR]
- [\fB\-\-add\-section\fR \fIsectionname\fR=\fIfilename\fR]
- [\fB\-\-rename\-section\fR \fIoldname\fR=\fInewname\fR[,\fIflags\fR]]
- [\fB\-\-long\-section\-names\fR {enable,disable,keep}]
- [\fB\-\-change\-leading\-char\fR] [\fB\-\-remove\-leading\-char\fR]
- [\fB\-\-reverse\-bytes=\fR\fInum\fR]
- [\fB\-\-srec\-len=\fR\fIival\fR] [\fB\-\-srec\-forceS3\fR]
- [\fB\-\-redefine\-sym\fR \fIold\fR=\fInew\fR]
- [\fB\-\-redefine\-syms=\fR\fIfilename\fR]
- [\fB\-\-weaken\fR]
- [\fB\-\-keep\-symbols=\fR\fIfilename\fR]
- [\fB\-\-strip\-symbols=\fR\fIfilename\fR]
- [\fB\-\-strip\-unneeded\-symbols=\fR\fIfilename\fR]
- [\fB\-\-keep\-global\-symbols=\fR\fIfilename\fR]
- [\fB\-\-localize\-symbols=\fR\fIfilename\fR]
- [\fB\-\-globalize\-symbols=\fR\fIfilename\fR]
- [\fB\-\-weaken\-symbols=\fR\fIfilename\fR]
- [\fB\-\-alt\-machine\-code=\fR\fIindex\fR]
- [\fB\-\-prefix\-symbols=\fR\fIstring\fR]
- [\fB\-\-prefix\-sections=\fR\fIstring\fR]
- [\fB\-\-prefix\-alloc\-sections=\fR\fIstring\fR]
- [\fB\-\-add\-gnu\-debuglink=\fR\fIpath-to-file\fR]
- [\fB\-\-keep\-file\-symbols\fR]
- [\fB\-\-only\-keep\-debug\fR]
- [\fB\-\-extract\-symbol\fR]
- [\fB\-\-writable\-text\fR]
- [\fB\-\-readonly\-text\fR]
- [\fB\-\-pure\fR]
- [\fB\-\-impure\fR]
- [\fB\-\-file\-alignment=\fR\fInum\fR]
- [\fB\-\-heap=\fR\fIsize\fR]
- [\fB\-\-image\-base=\fR\fIaddress\fR]
- [\fB\-\-section\-alignment=\fR\fInum\fR]
- [\fB\-\-stack=\fR\fIsize\fR]
- [\fB\-\-subsystem=\fR\fIwhich\fR:\fImajor\fR.\fIminor\fR]
- [\fB\-\-compress\-debug\-sections\fR]
- [\fB\-\-decompress\-debug\-sections\fR]
- [\fB\-v\fR|\fB\-\-verbose\fR]
- [\fB\-V\fR|\fB\-\-version\fR]
- [\fB\-\-help\fR] [\fB\-\-info\fR]
- \fIinfile\fR [\fIoutfile\fR]
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-The \s-1GNU\s0 \fBobjcopy\fR utility copies the contents of an object
-file to another. \fBobjcopy\fR uses the \s-1GNU\s0 \s-1BFD\s0 Library to
-read and write the object files. It can write the destination object
-file in a format different from that of the source object file. The
-exact behavior of \fBobjcopy\fR is controlled by command-line options.
-Note that \fBobjcopy\fR should be able to copy a fully linked file
-between any two formats. However, copying a relocatable object file
-between any two formats may not work as expected.
-.PP
-\&\fBobjcopy\fR creates temporary files to do its translations and
-deletes them afterward. \fBobjcopy\fR uses \s-1BFD\s0 to do all its
-translation work; it has access to all the formats described in \s-1BFD\s0
-and thus is able to recognize most formats without being told
-explicitly.
-.PP
-\&\fBobjcopy\fR can be used to generate S\-records by using an output
-target of \fBsrec\fR (e.g., use \fB\-O srec\fR).
-.PP
-\&\fBobjcopy\fR can be used to generate a raw binary file by using an
-output target of \fBbinary\fR (e.g., use \fB\-O binary\fR). When
-\&\fBobjcopy\fR generates a raw binary file, it will essentially produce
-a memory dump of the contents of the input object file. All symbols and
-relocation information will be discarded. The memory dump will start at
-the load address of the lowest section copied into the output file.
-.PP
-When generating an S\-record or a raw binary file, it may be helpful to
-use \fB\-S\fR to remove sections containing debugging information. In
-some cases \fB\-R\fR will be useful to remove sections which contain
-information that is not needed by the binary file.
-.PP
-Note\-\-\-\fBobjcopy\fR is not able to change the endianness of its input
-files. If the input format has an endianness (some formats do not),
-\&\fBobjcopy\fR can only copy the inputs into file formats that have the
-same endianness or which have no endianness (e.g., \fBsrec\fR).
-(However, see the \fB\-\-reverse\-bytes\fR option.)
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.IP "\fIinfile\fR" 4
-.IX Item "infile"
-.PD 0
-.IP "\fIoutfile\fR" 4
-.IX Item "outfile"
-.PD
-The input and output files, respectively.
-If you do not specify \fIoutfile\fR, \fBobjcopy\fR creates a
-temporary file and destructively renames the result with
-the name of \fIinfile\fR.
-.IP "\fB\-I\fR \fIbfdname\fR" 4
-.IX Item "-I bfdname"
-.PD 0
-.IP "\fB\-\-input\-target=\fR\fIbfdname\fR" 4
-.IX Item "--input-target=bfdname"
-.PD
-Consider the source file's object format to be \fIbfdname\fR, rather than
-attempting to deduce it.
-.IP "\fB\-O\fR \fIbfdname\fR" 4
-.IX Item "-O bfdname"
-.PD 0
-.IP "\fB\-\-output\-target=\fR\fIbfdname\fR" 4
-.IX Item "--output-target=bfdname"
-.PD
-Write the output file using the object format \fIbfdname\fR.
-.IP "\fB\-F\fR \fIbfdname\fR" 4
-.IX Item "-F bfdname"
-.PD 0
-.IP "\fB\-\-target=\fR\fIbfdname\fR" 4
-.IX Item "--target=bfdname"
-.PD
-Use \fIbfdname\fR as the object format for both the input and the output
-file; i.e., simply transfer data from source to destination with no
-translation.
-.IP "\fB\-B\fR \fIbfdarch\fR" 4
-.IX Item "-B bfdarch"
-.PD 0
-.IP "\fB\-\-binary\-architecture=\fR\fIbfdarch\fR" 4
-.IX Item "--binary-architecture=bfdarch"
-.PD
-Useful when transforming a architecture-less input file into an object file.
-In this case the output architecture can be set to \fIbfdarch\fR. This
-option will be ignored if the input file has a known \fIbfdarch\fR. You
-can access this binary data inside a program by referencing the special
-symbols that are created by the conversion process. These symbols are
-called _binary_\fIobjfile\fR_start, _binary_\fIobjfile\fR_end and
-_binary_\fIobjfile\fR_size. e.g. you can transform a picture file into
-an object file and then access it in your code using these symbols.
-.IP "\fB\-j\fR \fIsectionname\fR" 4
-.IX Item "-j sectionname"
-.PD 0
-.IP "\fB\-\-only\-section=\fR\fIsectionname\fR" 4
-.IX Item "--only-section=sectionname"
-.PD
-Copy only the named section from the input file to the output file.
-This option may be given more than once. Note that using this option
-inappropriately may make the output file unusable.
-.IP "\fB\-R\fR \fIsectionname\fR" 4
-.IX Item "-R sectionname"
-.PD 0
-.IP "\fB\-\-remove\-section=\fR\fIsectionname\fR" 4
-.IX Item "--remove-section=sectionname"
-.PD
-Remove any section named \fIsectionname\fR from the output file. This
-option may be given more than once. Note that using this option
-inappropriately may make the output file unusable.
-.IP "\fB\-S\fR" 4
-.IX Item "-S"
-.PD 0
-.IP "\fB\-\-strip\-all\fR" 4
-.IX Item "--strip-all"
-.PD
-Do not copy relocation and symbol information from the source file.
-.IP "\fB\-g\fR" 4
-.IX Item "-g"
-.PD 0
-.IP "\fB\-\-strip\-debug\fR" 4
-.IX Item "--strip-debug"
-.PD
-Do not copy debugging symbols or sections from the source file.
-.IP "\fB\-\-strip\-unneeded\fR" 4
-.IX Item "--strip-unneeded"
-Strip all symbols that are not needed for relocation processing.
-.IP "\fB\-K\fR \fIsymbolname\fR" 4
-.IX Item "-K symbolname"
-.PD 0
-.IP "\fB\-\-keep\-symbol=\fR\fIsymbolname\fR" 4
-.IX Item "--keep-symbol=symbolname"
-.PD
-When stripping symbols, keep symbol \fIsymbolname\fR even if it would
-normally be stripped. This option may be given more than once.
-.IP "\fB\-N\fR \fIsymbolname\fR" 4
-.IX Item "-N symbolname"
-.PD 0
-.IP "\fB\-\-strip\-symbol=\fR\fIsymbolname\fR" 4
-.IX Item "--strip-symbol=symbolname"
-.PD
-Do not copy symbol \fIsymbolname\fR from the source file. This option
-may be given more than once.
-.IP "\fB\-\-strip\-unneeded\-symbol=\fR\fIsymbolname\fR" 4
-.IX Item "--strip-unneeded-symbol=symbolname"
-Do not copy symbol \fIsymbolname\fR from the source file unless it is needed
-by a relocation. This option may be given more than once.
-.IP "\fB\-G\fR \fIsymbolname\fR" 4
-.IX Item "-G symbolname"
-.PD 0
-.IP "\fB\-\-keep\-global\-symbol=\fR\fIsymbolname\fR" 4
-.IX Item "--keep-global-symbol=symbolname"
-.PD
-Keep only symbol \fIsymbolname\fR global. Make all other symbols local
-to the file, so that they are not visible externally. This option may
-be given more than once.
-.IP "\fB\-\-localize\-hidden\fR" 4
-.IX Item "--localize-hidden"
-In an \s-1ELF\s0 object, mark all symbols that have hidden or internal visibility
-as local. This option applies on top of symbol-specific localization options
-such as \fB\-L\fR.
-.IP "\fB\-L\fR \fIsymbolname\fR" 4
-.IX Item "-L symbolname"
-.PD 0
-.IP "\fB\-\-localize\-symbol=\fR\fIsymbolname\fR" 4
-.IX Item "--localize-symbol=symbolname"
-.PD
-Make symbol \fIsymbolname\fR local to the file, so that it is not
-visible externally. This option may be given more than once.
-.IP "\fB\-W\fR \fIsymbolname\fR" 4
-.IX Item "-W symbolname"
-.PD 0
-.IP "\fB\-\-weaken\-symbol=\fR\fIsymbolname\fR" 4
-.IX Item "--weaken-symbol=symbolname"
-.PD
-Make symbol \fIsymbolname\fR weak. This option may be given more than once.
-.IP "\fB\-\-globalize\-symbol=\fR\fIsymbolname\fR" 4
-.IX Item "--globalize-symbol=symbolname"
-Give symbol \fIsymbolname\fR global scoping so that it is visible
-outside of the file in which it is defined. This option may be given
-more than once.
-.IP "\fB\-w\fR" 4
-.IX Item "-w"
-.PD 0
-.IP "\fB\-\-wildcard\fR" 4
-.IX Item "--wildcard"
-.PD
-Permit regular expressions in \fIsymbolname\fRs used in other command
-line options. The question mark (?), asterisk (*), backslash (\e) and
-square brackets ([]) operators can be used anywhere in the symbol
-name. If the first character of the symbol name is the exclamation
-point (!) then the sense of the switch is reversed for that symbol.
-For example:
-.Sp
-.Vb 1
-\& \-w \-W !foo \-W fo*
-.Ve
-.Sp
-would cause objcopy to weaken all symbols that start with \*(L"fo\*(R"
-except for the symbol \*(L"foo\*(R".
-.IP "\fB\-x\fR" 4
-.IX Item "-x"
-.PD 0
-.IP "\fB\-\-discard\-all\fR" 4
-.IX Item "--discard-all"
-.PD
-Do not copy non-global symbols from the source file.
-.IP "\fB\-X\fR" 4
-.IX Item "-X"
-.PD 0
-.IP "\fB\-\-discard\-locals\fR" 4
-.IX Item "--discard-locals"
-.PD
-Do not copy compiler-generated local symbols.
-(These usually start with \fBL\fR or \fB.\fR.)
-.IP "\fB\-b\fR \fIbyte\fR" 4
-.IX Item "-b byte"
-.PD 0
-.IP "\fB\-\-byte=\fR\fIbyte\fR" 4
-.IX Item "--byte=byte"
-.PD
-If interleaving has been enabled via the \fB\-\-interleave\fR option
-then start the range of bytes to keep at the \fIbyte\fRth byte.
-\&\fIbyte\fR can be in the range from 0 to \fIbreadth\fR\-1, where
-\&\fIbreadth\fR is the value given by the \fB\-\-interleave\fR option.
-.IP "\fB\-i [\fR\fIbreadth\fR\fB]\fR" 4
-.IX Item "-i [breadth]"
-.PD 0
-.IP "\fB\-\-interleave[=\fR\fIbreadth\fR\fB]\fR" 4
-.IX Item "--interleave[=breadth]"
-.PD
-Only copy a range out of every \fIbreadth\fR bytes. (Header data is
-not affected). Select which byte in the range begins the copy with
-the \fB\-\-byte\fR option. Select the width of the range with the
-\&\fB\-\-interleave\-width\fR option.
-.Sp
-This option is useful for creating files to program \s-1ROM\s0. It is
-typically used with an \f(CW\*(C`srec\*(C'\fR output target. Note that
-\&\fBobjcopy\fR will complain if you do not specify the
-\&\fB\-\-byte\fR option as well.
-.Sp
-The default interleave breadth is 4, so with \fB\-\-byte\fR set to 0,
-\&\fBobjcopy\fR would copy the first byte out of every four bytes
-from the input to the output.
-.IP "\fB\-\-interleave\-width=\fR\fIwidth\fR" 4
-.IX Item "--interleave-width=width"
-When used with the \fB\-\-interleave\fR option, copy \fIwidth\fR
-bytes at a time. The start of the range of bytes to be copied is set
-by the \fB\-\-byte\fR option, and the extent of the range is set with
-the \fB\-\-interleave\fR option.
-.Sp
-The default value for this option is 1. The value of \fIwidth\fR plus
-the \fIbyte\fR value set by the \fB\-\-byte\fR option must not exceed
-the interleave breadth set by the \fB\-\-interleave\fR option.
-.Sp
-This option can be used to create images for two 16\-bit flashes interleaved
-in a 32\-bit bus by passing \fB\-b 0 \-i 4 \-\-interleave\-width=2\fR
-and \fB\-b 2 \-i 4 \-\-interleave\-width=2\fR to two \fBobjcopy\fR
-commands. If the input was '12345678' then the outputs would be
-\&'1256' and '3478' respectively.
-.IP "\fB\-p\fR" 4
-.IX Item "-p"
-.PD 0
-.IP "\fB\-\-preserve\-dates\fR" 4
-.IX Item "--preserve-dates"
-.PD
-Set the access and modification dates of the output file to be the same
-as those of the input file.
-.IP "\fB\-\-debugging\fR" 4
-.IX Item "--debugging"
-Convert debugging information, if possible. This is not the default
-because only certain debugging formats are supported, and the
-conversion process can be time consuming.
-.IP "\fB\-\-gap\-fill\fR \fIval\fR" 4
-.IX Item "--gap-fill val"
-Fill gaps between sections with \fIval\fR. This operation applies to
-the \fIload address\fR (\s-1LMA\s0) of the sections. It is done by increasing
-the size of the section with the lower address, and filling in the extra
-space created with \fIval\fR.
-.IP "\fB\-\-pad\-to\fR \fIaddress\fR" 4
-.IX Item "--pad-to address"
-Pad the output file up to the load address \fIaddress\fR. This is
-done by increasing the size of the last section. The extra space is
-filled in with the value specified by \fB\-\-gap\-fill\fR (default zero).
-.IP "\fB\-\-set\-start\fR \fIval\fR" 4
-.IX Item "--set-start val"
-Set the start address of the new file to \fIval\fR. Not all object file
-formats support setting the start address.
-.IP "\fB\-\-change\-start\fR \fIincr\fR" 4
-.IX Item "--change-start incr"
-.PD 0
-.IP "\fB\-\-adjust\-start\fR \fIincr\fR" 4
-.IX Item "--adjust-start incr"
-.PD
-Change the start address by adding \fIincr\fR. Not all object file
-formats support setting the start address.
-.IP "\fB\-\-change\-addresses\fR \fIincr\fR" 4
-.IX Item "--change-addresses incr"
-.PD 0
-.IP "\fB\-\-adjust\-vma\fR \fIincr\fR" 4
-.IX Item "--adjust-vma incr"
-.PD
-Change the \s-1VMA\s0 and \s-1LMA\s0 addresses of all sections, as well as the start
-address, by adding \fIincr\fR. Some object file formats do not permit
-section addresses to be changed arbitrarily. Note that this does not
-relocate the sections; if the program expects sections to be loaded at a
-certain address, and this option is used to change the sections such
-that they are loaded at a different address, the program may fail.
-.IP "\fB\-\-change\-section\-address\fR \fIsection\fR\fB{=,+,\-}\fR\fIval\fR" 4
-.IX Item "--change-section-address section{=,+,-}val"
-.PD 0
-.IP "\fB\-\-adjust\-section\-vma\fR \fIsection\fR\fB{=,+,\-}\fR\fIval\fR" 4
-.IX Item "--adjust-section-vma section{=,+,-}val"
-.PD
-Set or change both the \s-1VMA\s0 address and the \s-1LMA\s0 address of the named
-\&\fIsection\fR. If \fB=\fR is used, the section address is set to
-\&\fIval\fR. Otherwise, \fIval\fR is added to or subtracted from the
-section address. See the comments under \fB\-\-change\-addresses\fR,
-above. If \fIsection\fR does not exist in the input file, a warning will
-be issued, unless \fB\-\-no\-change\-warnings\fR is used.
-.IP "\fB\-\-change\-section\-lma\fR \fIsection\fR\fB{=,+,\-}\fR\fIval\fR" 4
-.IX Item "--change-section-lma section{=,+,-}val"
-Set or change the \s-1LMA\s0 address of the named \fIsection\fR. The \s-1LMA\s0
-address is the address where the section will be loaded into memory at
-program load time. Normally this is the same as the \s-1VMA\s0 address, which
-is the address of the section at program run time, but on some systems,
-especially those where a program is held in \s-1ROM\s0, the two can be
-different. If \fB=\fR is used, the section address is set to
-\&\fIval\fR. Otherwise, \fIval\fR is added to or subtracted from the
-section address. See the comments under \fB\-\-change\-addresses\fR,
-above. If \fIsection\fR does not exist in the input file, a warning
-will be issued, unless \fB\-\-no\-change\-warnings\fR is used.
-.IP "\fB\-\-change\-section\-vma\fR \fIsection\fR\fB{=,+,\-}\fR\fIval\fR" 4
-.IX Item "--change-section-vma section{=,+,-}val"
-Set or change the \s-1VMA\s0 address of the named \fIsection\fR. The \s-1VMA\s0
-address is the address where the section will be located once the
-program has started executing. Normally this is the same as the \s-1LMA\s0
-address, which is the address where the section will be loaded into
-memory, but on some systems, especially those where a program is held in
-\&\s-1ROM\s0, the two can be different. If \fB=\fR is used, the section address
-is set to \fIval\fR. Otherwise, \fIval\fR is added to or subtracted
-from the section address. See the comments under
-\&\fB\-\-change\-addresses\fR, above. If \fIsection\fR does not exist in
-the input file, a warning will be issued, unless
-\&\fB\-\-no\-change\-warnings\fR is used.
-.IP "\fB\-\-change\-warnings\fR" 4
-.IX Item "--change-warnings"
-.PD 0
-.IP "\fB\-\-adjust\-warnings\fR" 4
-.IX Item "--adjust-warnings"
-.PD
-If \fB\-\-change\-section\-address\fR or \fB\-\-change\-section\-lma\fR or
-\&\fB\-\-change\-section\-vma\fR is used, and the named section does not
-exist, issue a warning. This is the default.
-.IP "\fB\-\-no\-change\-warnings\fR" 4
-.IX Item "--no-change-warnings"
-.PD 0
-.IP "\fB\-\-no\-adjust\-warnings\fR" 4
-.IX Item "--no-adjust-warnings"
-.PD
-Do not issue a warning if \fB\-\-change\-section\-address\fR or
-\&\fB\-\-adjust\-section\-lma\fR or \fB\-\-adjust\-section\-vma\fR is used, even
-if the named section does not exist.
-.IP "\fB\-\-set\-section\-flags\fR \fIsection\fR\fB=\fR\fIflags\fR" 4
-.IX Item "--set-section-flags section=flags"
-Set the flags for the named section. The \fIflags\fR argument is a
-comma separated string of flag names. The recognized names are
-\&\fBalloc\fR, \fBcontents\fR, \fBload\fR, \fBnoload\fR,
-\&\fBreadonly\fR, \fBcode\fR, \fBdata\fR, \fBrom\fR, \fBshare\fR, and
-\&\fBdebug\fR. You can set the \fBcontents\fR flag for a section which
-does not have contents, but it is not meaningful to clear the
-\&\fBcontents\fR flag of a section which does have contents\*(--just remove
-the section instead. Not all flags are meaningful for all object file
-formats.
-.IP "\fB\-\-add\-section\fR \fIsectionname\fR\fB=\fR\fIfilename\fR" 4
-.IX Item "--add-section sectionname=filename"
-Add a new section named \fIsectionname\fR while copying the file. The
-contents of the new section are taken from the file \fIfilename\fR. The
-size of the section will be the size of the file. This option only
-works on file formats which can support sections with arbitrary names.
-.IP "\fB\-\-rename\-section\fR \fIoldname\fR\fB=\fR\fInewname\fR\fB[,\fR\fIflags\fR\fB]\fR" 4
-.IX Item "--rename-section oldname=newname[,flags]"
-Rename a section from \fIoldname\fR to \fInewname\fR, optionally
-changing the section's flags to \fIflags\fR in the process. This has
-the advantage over usng a linker script to perform the rename in that
-the output stays as an object file and does not become a linked
-executable.
-.Sp
-This option is particularly helpful when the input format is binary,
-since this will always create a section called .data. If for example,
-you wanted instead to create a section called .rodata containing binary
-data you could use the following command line to achieve it:
-.Sp
-.Vb 3
-\& objcopy \-I binary \-O <output_format> \-B <architecture> \e
-\& \-\-rename\-section .data=.rodata,alloc,load,readonly,data,contents \e
-\& <input_binary_file> <output_object_file>
-.Ve
-.IP "\fB\-\-long\-section\-names {enable,disable,keep}\fR" 4
-.IX Item "--long-section-names {enable,disable,keep}"
-Controls the handling of long section names when processing \f(CW\*(C`COFF\*(C'\fR
-and \f(CW\*(C`PE\-COFF\*(C'\fR object formats. The default behaviour, \fBkeep\fR,
-is to preserve long section names if any are present in the input file.
-The \fBenable\fR and \fBdisable\fR options forcibly enable or disable
-the use of long section names in the output object; when \fBdisable\fR
-is in effect, any long section names in the input object will be truncated.
-The \fBenable\fR option will only emit long section names if any are
-present in the inputs; this is mostly the same as \fBkeep\fR, but it
-is left undefined whether the \fBenable\fR option might force the
-creation of an empty string table in the output file.
-.IP "\fB\-\-change\-leading\-char\fR" 4
-.IX Item "--change-leading-char"
-Some object file formats use special characters at the start of
-symbols. The most common such character is underscore, which compilers
-often add before every symbol. This option tells \fBobjcopy\fR to
-change the leading character of every symbol when it converts between
-object file formats. If the object file formats use the same leading
-character, this option has no effect. Otherwise, it will add a
-character, or remove a character, or change a character, as
-appropriate.
-.IP "\fB\-\-remove\-leading\-char\fR" 4
-.IX Item "--remove-leading-char"
-If the first character of a global symbol is a special symbol leading
-character used by the object file format, remove the character. The
-most common symbol leading character is underscore. This option will
-remove a leading underscore from all global symbols. This can be useful
-if you want to link together objects of different file formats with
-different conventions for symbol names. This is different from
-\&\fB\-\-change\-leading\-char\fR because it always changes the symbol name
-when appropriate, regardless of the object file format of the output
-file.
-.IP "\fB\-\-reverse\-bytes=\fR\fInum\fR" 4
-.IX Item "--reverse-bytes=num"
-Reverse the bytes in a section with output contents. A section length must
-be evenly divisible by the value given in order for the swap to be able to
-take place. Reversing takes place before the interleaving is performed.
-.Sp
-This option is used typically in generating \s-1ROM\s0 images for problematic
-target systems. For example, on some target boards, the 32\-bit words
-fetched from 8\-bit ROMs are re-assembled in little-endian byte order
-regardless of the \s-1CPU\s0 byte order. Depending on the programming model, the
-endianness of the \s-1ROM\s0 may need to be modified.
-.Sp
-Consider a simple file with a section containing the following eight
-bytes: \f(CW12345678\fR.
-.Sp
-Using \fB\-\-reverse\-bytes=2\fR for the above example, the bytes in the
-output file would be ordered \f(CW21436587\fR.
-.Sp
-Using \fB\-\-reverse\-bytes=4\fR for the above example, the bytes in the
-output file would be ordered \f(CW43218765\fR.
-.Sp
-By using \fB\-\-reverse\-bytes=2\fR for the above example, followed by
-\&\fB\-\-reverse\-bytes=4\fR on the output file, the bytes in the second
-output file would be ordered \f(CW34127856\fR.
-.IP "\fB\-\-srec\-len=\fR\fIival\fR" 4
-.IX Item "--srec-len=ival"
-Meaningful only for srec output. Set the maximum length of the Srecords
-being produced to \fIival\fR. This length covers both address, data and
-crc fields.
-.IP "\fB\-\-srec\-forceS3\fR" 4
-.IX Item "--srec-forceS3"
-Meaningful only for srec output. Avoid generation of S1/S2 records,
-creating S3\-only record format.
-.IP "\fB\-\-redefine\-sym\fR \fIold\fR\fB=\fR\fInew\fR" 4
-.IX Item "--redefine-sym old=new"
-Change the name of a symbol \fIold\fR, to \fInew\fR. This can be useful
-when one is trying link two things together for which you have no
-source, and there are name collisions.
-.IP "\fB\-\-redefine\-syms=\fR\fIfilename\fR" 4
-.IX Item "--redefine-syms=filename"
-Apply \fB\-\-redefine\-sym\fR to each symbol pair "\fIold\fR \fInew\fR"
-listed in the file \fIfilename\fR. \fIfilename\fR is simply a flat file,
-with one symbol pair per line. Line comments may be introduced by the hash
-character. This option may be given more than once.
-.IP "\fB\-\-weaken\fR" 4
-.IX Item "--weaken"
-Change all global symbols in the file to be weak. This can be useful
-when building an object which will be linked against other objects using
-the \fB\-R\fR option to the linker. This option is only effective when
-using an object file format which supports weak symbols.
-.IP "\fB\-\-keep\-symbols=\fR\fIfilename\fR" 4
-.IX Item "--keep-symbols=filename"
-Apply \fB\-\-keep\-symbol\fR option to each symbol listed in the file
-\&\fIfilename\fR. \fIfilename\fR is simply a flat file, with one symbol
-name per line. Line comments may be introduced by the hash character.
-This option may be given more than once.
-.IP "\fB\-\-strip\-symbols=\fR\fIfilename\fR" 4
-.IX Item "--strip-symbols=filename"
-Apply \fB\-\-strip\-symbol\fR option to each symbol listed in the file
-\&\fIfilename\fR. \fIfilename\fR is simply a flat file, with one symbol
-name per line. Line comments may be introduced by the hash character.
-This option may be given more than once.
-.IP "\fB\-\-strip\-unneeded\-symbols=\fR\fIfilename\fR" 4
-.IX Item "--strip-unneeded-symbols=filename"
-Apply \fB\-\-strip\-unneeded\-symbol\fR option to each symbol listed in
-the file \fIfilename\fR. \fIfilename\fR is simply a flat file, with one
-symbol name per line. Line comments may be introduced by the hash
-character. This option may be given more than once.
-.IP "\fB\-\-keep\-global\-symbols=\fR\fIfilename\fR" 4
-.IX Item "--keep-global-symbols=filename"
-Apply \fB\-\-keep\-global\-symbol\fR option to each symbol listed in the
-file \fIfilename\fR. \fIfilename\fR is simply a flat file, with one
-symbol name per line. Line comments may be introduced by the hash
-character. This option may be given more than once.
-.IP "\fB\-\-localize\-symbols=\fR\fIfilename\fR" 4
-.IX Item "--localize-symbols=filename"
-Apply \fB\-\-localize\-symbol\fR option to each symbol listed in the file
-\&\fIfilename\fR. \fIfilename\fR is simply a flat file, with one symbol
-name per line. Line comments may be introduced by the hash character.
-This option may be given more than once.
-.IP "\fB\-\-globalize\-symbols=\fR\fIfilename\fR" 4
-.IX Item "--globalize-symbols=filename"
-Apply \fB\-\-globalize\-symbol\fR option to each symbol listed in the file
-\&\fIfilename\fR. \fIfilename\fR is simply a flat file, with one symbol
-name per line. Line comments may be introduced by the hash character.
-This option may be given more than once.
-.IP "\fB\-\-weaken\-symbols=\fR\fIfilename\fR" 4
-.IX Item "--weaken-symbols=filename"
-Apply \fB\-\-weaken\-symbol\fR option to each symbol listed in the file
-\&\fIfilename\fR. \fIfilename\fR is simply a flat file, with one symbol
-name per line. Line comments may be introduced by the hash character.
-This option may be given more than once.
-.IP "\fB\-\-alt\-machine\-code=\fR\fIindex\fR" 4
-.IX Item "--alt-machine-code=index"
-If the output architecture has alternate machine codes, use the
-\&\fIindex\fRth code instead of the default one. This is useful in case
-a machine is assigned an official code and the tool-chain adopts the
-new code, but other applications still depend on the original code
-being used. For \s-1ELF\s0 based architectures if the \fIindex\fR
-alternative does not exist then the value is treated as an absolute
-number to be stored in the e_machine field of the \s-1ELF\s0 header.
-.IP "\fB\-\-writable\-text\fR" 4
-.IX Item "--writable-text"
-Mark the output text as writable. This option isn't meaningful for all
-object file formats.
-.IP "\fB\-\-readonly\-text\fR" 4
-.IX Item "--readonly-text"
-Make the output text write protected. This option isn't meaningful for all
-object file formats.
-.IP "\fB\-\-pure\fR" 4
-.IX Item "--pure"
-Mark the output file as demand paged. This option isn't meaningful for all
-object file formats.
-.IP "\fB\-\-impure\fR" 4
-.IX Item "--impure"
-Mark the output file as impure. This option isn't meaningful for all
-object file formats.
-.IP "\fB\-\-prefix\-symbols=\fR\fIstring\fR" 4
-.IX Item "--prefix-symbols=string"
-Prefix all symbols in the output file with \fIstring\fR.
-.IP "\fB\-\-prefix\-sections=\fR\fIstring\fR" 4
-.IX Item "--prefix-sections=string"
-Prefix all section names in the output file with \fIstring\fR.
-.IP "\fB\-\-prefix\-alloc\-sections=\fR\fIstring\fR" 4
-.IX Item "--prefix-alloc-sections=string"
-Prefix all the names of all allocated sections in the output file with
-\&\fIstring\fR.
-.IP "\fB\-\-add\-gnu\-debuglink=\fR\fIpath-to-file\fR" 4
-.IX Item "--add-gnu-debuglink=path-to-file"
-Creates a .gnu_debuglink section which contains a reference to \fIpath-to-file\fR
-and adds it to the output file.
-.IP "\fB\-\-keep\-file\-symbols\fR" 4
-.IX Item "--keep-file-symbols"
-When stripping a file, perhaps with \fB\-\-strip\-debug\fR or
-\&\fB\-\-strip\-unneeded\fR, retain any symbols specifying source file names,
-which would otherwise get stripped.
-.IP "\fB\-\-only\-keep\-debug\fR" 4
-.IX Item "--only-keep-debug"
-Strip a file, removing contents of any sections that would not be
-stripped by \fB\-\-strip\-debug\fR and leaving the debugging sections
-intact. In \s-1ELF\s0 files, this preserves all note sections in the output.
-.Sp
-The intention is that this option will be used in conjunction with
-\&\fB\-\-add\-gnu\-debuglink\fR to create a two part executable. One a
-stripped binary which will occupy less space in \s-1RAM\s0 and in a
-distribution and the second a debugging information file which is only
-needed if debugging abilities are required. The suggested procedure
-to create these files is as follows:
-.RS 4
-.IP "1.<Link the executable as normal. Assuming that is is called>" 4
-.IX Item "1.<Link the executable as normal. Assuming that is is called>"
-\&\f(CW\*(C`foo\*(C'\fR then...
-.ie n .IP "1.<Run ""objcopy \-\-only\-keep\-debug foo foo.dbg"" to>" 4
-.el .IP "1.<Run \f(CWobjcopy \-\-only\-keep\-debug foo foo.dbg\fR to>" 4
-.IX Item "1.<Run objcopy --only-keep-debug foo foo.dbg to>"
-create a file containing the debugging info.
-.ie n .IP "1.<Run ""objcopy \-\-strip\-debug foo"" to create a>" 4
-.el .IP "1.<Run \f(CWobjcopy \-\-strip\-debug foo\fR to create a>" 4
-.IX Item "1.<Run objcopy --strip-debug foo to create a>"
-stripped executable.
-.ie n .IP "1.<Run ""objcopy \-\-add\-gnu\-debuglink=foo.dbg foo"">" 4
-.el .IP "1.<Run \f(CWobjcopy \-\-add\-gnu\-debuglink=foo.dbg foo\fR>" 4
-.IX Item "1.<Run objcopy --add-gnu-debuglink=foo.dbg foo>"
-to add a link to the debugging info into the stripped executable.
-.RE
-.RS 4
-.Sp
-Note\-\-\-the choice of \f(CW\*(C`.dbg\*(C'\fR as an extension for the debug info
-file is arbitrary. Also the \f(CW\*(C`\-\-only\-keep\-debug\*(C'\fR step is
-optional. You could instead do this:
-.IP "1.<Link the executable as normal.>" 4
-.IX Item "1.<Link the executable as normal.>"
-.PD 0
-.ie n .IP "1.<Copy ""foo"" to ""foo.full"">" 4
-.el .IP "1.<Copy \f(CWfoo\fR to \f(CWfoo.full\fR>" 4
-.IX Item "1.<Copy foo to foo.full>"
-.ie n .IP "1.<Run ""objcopy \-\-strip\-debug foo"">" 4
-.el .IP "1.<Run \f(CWobjcopy \-\-strip\-debug foo\fR>" 4
-.IX Item "1.<Run objcopy --strip-debug foo>"
-.ie n .IP "1.<Run ""objcopy \-\-add\-gnu\-debuglink=foo.full foo"">" 4
-.el .IP "1.<Run \f(CWobjcopy \-\-add\-gnu\-debuglink=foo.full foo\fR>" 4
-.IX Item "1.<Run objcopy --add-gnu-debuglink=foo.full foo>"
-.RE
-.RS 4
-.PD
-.Sp
-i.e., the file pointed to by the \fB\-\-add\-gnu\-debuglink\fR can be the
-full executable. It does not have to be a file created by the
-\&\fB\-\-only\-keep\-debug\fR switch.
-.Sp
-Note\-\-\-this switch is only intended for use on fully linked files. It
-does not make sense to use it on object files where the debugging
-information may be incomplete. Besides the gnu_debuglink feature
-currently only supports the presence of one filename containing
-debugging information, not multiple filenames on a one-per-object-file
-basis.
-.RE
-.IP "\fB\-\-file\-alignment\fR \fInum\fR" 4
-.IX Item "--file-alignment num"
-Specify the file alignment. Sections in the file will always begin at
-file offsets which are multiples of this number. This defaults to
-512.
-[This option is specific to \s-1PE\s0 targets.]
-.IP "\fB\-\-heap\fR \fIreserve\fR" 4
-.IX Item "--heap reserve"
-.PD 0
-.IP "\fB\-\-heap\fR \fIreserve\fR\fB,\fR\fIcommit\fR" 4
-.IX Item "--heap reserve,commit"
-.PD
-Specify the number of bytes of memory to reserve (and optionally commit)
-to be used as heap for this program.
-[This option is specific to \s-1PE\s0 targets.]
-.IP "\fB\-\-image\-base\fR \fIvalue\fR" 4
-.IX Item "--image-base value"
-Use \fIvalue\fR as the base address of your program or dll. This is
-the lowest memory location that will be used when your program or dll
-is loaded. To reduce the need to relocate and improve performance of
-your dlls, each should have a unique base address and not overlap any
-other dlls. The default is 0x400000 for executables, and 0x10000000
-for dlls.
-[This option is specific to \s-1PE\s0 targets.]
-.IP "\fB\-\-section\-alignment\fR \fInum\fR" 4
-.IX Item "--section-alignment num"
-Sets the section alignment. Sections in memory will always begin at
-addresses which are a multiple of this number. Defaults to 0x1000.
-[This option is specific to \s-1PE\s0 targets.]
-.IP "\fB\-\-stack\fR \fIreserve\fR" 4
-.IX Item "--stack reserve"
-.PD 0
-.IP "\fB\-\-stack\fR \fIreserve\fR\fB,\fR\fIcommit\fR" 4
-.IX Item "--stack reserve,commit"
-.PD
-Specify the number of bytes of memory to reserve (and optionally commit)
-to be used as stack for this program.
-[This option is specific to \s-1PE\s0 targets.]
-.IP "\fB\-\-subsystem\fR \fIwhich\fR" 4
-.IX Item "--subsystem which"
-.PD 0
-.IP "\fB\-\-subsystem\fR \fIwhich\fR\fB:\fR\fImajor\fR" 4
-.IX Item "--subsystem which:major"
-.IP "\fB\-\-subsystem\fR \fIwhich\fR\fB:\fR\fImajor\fR\fB.\fR\fIminor\fR" 4
-.IX Item "--subsystem which:major.minor"
-.PD
-Specifies the subsystem under which your program will execute. The
-legal values for \fIwhich\fR are \f(CW\*(C`native\*(C'\fR, \f(CW\*(C`windows\*(C'\fR,
-\&\f(CW\*(C`console\*(C'\fR, \f(CW\*(C`posix\*(C'\fR, \f(CW\*(C`efi\-app\*(C'\fR, \f(CW\*(C`efi\-bsd\*(C'\fR,
-\&\f(CW\*(C`efi\-rtd\*(C'\fR, \f(CW\*(C`sal\-rtd\*(C'\fR, and \f(CW\*(C`xbox\*(C'\fR. You may optionally set
-the subsystem version also. Numeric values are also accepted for
-\&\fIwhich\fR.
-[This option is specific to \s-1PE\s0 targets.]
-.IP "\fB\-\-extract\-symbol\fR" 4
-.IX Item "--extract-symbol"
-Keep the file's section flags and symbols but remove all section data.
-Specifically, the option:
-.RS 4
-.IP "*<removes the contents of all sections;>" 4
-.IX Item "*<removes the contents of all sections;>"
-.PD 0
-.IP "*<sets the size of every section to zero; and>" 4
-.IX Item "*<sets the size of every section to zero; and>"
-.IP "*<sets the file's start address to zero.>" 4
-.IX Item "*<sets the file's start address to zero.>"
-.RE
-.RS 4
-.PD
-.Sp
-This option is used to build a \fI.sym\fR file for a VxWorks kernel.
-It can also be a useful way of reducing the size of a \fB\-\-just\-symbols\fR
-linker input file.
-.RE
-.IP "\fB\-\-compress\-debug\-sections\fR" 4
-.IX Item "--compress-debug-sections"
-Compress \s-1DWARF\s0 debug sections using zlib.
-.IP "\fB\-\-decompress\-debug\-sections\fR" 4
-.IX Item "--decompress-debug-sections"
-Decompress \s-1DWARF\s0 debug sections using zlib.
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Show the version number of \fBobjcopy\fR.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.IP "\fB\-\-verbose\fR" 4
-.IX Item "--verbose"
-.PD
-Verbose output: list all object files modified. In the case of
-archives, \fBobjcopy \-V\fR lists all members of the archive.
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-Show a summary of the options to \fBobjcopy\fR.
-.IP "\fB\-\-info\fR" 4
-.IX Item "--info"
-Display a list showing all architectures and object formats available.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIld\fR\|(1), \fIobjdump\fR\|(1), and the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-objdump.1 b/share/man/man1/arm-eabi-objdump.1
deleted file mode 100644
index 02c7075..0000000
--- a/share/man/man1/arm-eabi-objdump.1
+++ /dev/null
@@ -1,799 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "OBJDUMP 1"
-.TH OBJDUMP 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-objdump \- display information from object files.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-objdump [\fB\-a\fR|\fB\-\-archive\-headers\fR]
- [\fB\-b\fR \fIbfdname\fR|\fB\-\-target=\fR\fIbfdname\fR]
- [\fB\-C\fR|\fB\-\-demangle\fR[=\fIstyle\fR] ]
- [\fB\-d\fR|\fB\-\-disassemble\fR]
- [\fB\-D\fR|\fB\-\-disassemble\-all\fR]
- [\fB\-z\fR|\fB\-\-disassemble\-zeroes\fR]
- [\fB\-EB\fR|\fB\-EL\fR|\fB\-\-endian=\fR{big | little }]
- [\fB\-f\fR|\fB\-\-file\-headers\fR]
- [\fB\-F\fR|\fB\-\-file\-offsets\fR]
- [\fB\-\-file\-start\-context\fR]
- [\fB\-g\fR|\fB\-\-debugging\fR]
- [\fB\-e\fR|\fB\-\-debugging\-tags\fR]
- [\fB\-h\fR|\fB\-\-section\-headers\fR|\fB\-\-headers\fR]
- [\fB\-i\fR|\fB\-\-info\fR]
- [\fB\-j\fR \fIsection\fR|\fB\-\-section=\fR\fIsection\fR]
- [\fB\-l\fR|\fB\-\-line\-numbers\fR]
- [\fB\-S\fR|\fB\-\-source\fR]
- [\fB\-m\fR \fImachine\fR|\fB\-\-architecture=\fR\fImachine\fR]
- [\fB\-M\fR \fIoptions\fR|\fB\-\-disassembler\-options=\fR\fIoptions\fR]
- [\fB\-p\fR|\fB\-\-private\-headers\fR]
- [\fB\-r\fR|\fB\-\-reloc\fR]
- [\fB\-R\fR|\fB\-\-dynamic\-reloc\fR]
- [\fB\-s\fR|\fB\-\-full\-contents\fR]
- [\fB\-W[lLiaprmfFsoRt]\fR|
- \fB\-\-dwarf\fR[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames\-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges]]
- [\fB\-G\fR|\fB\-\-stabs\fR]
- [\fB\-t\fR|\fB\-\-syms\fR]
- [\fB\-T\fR|\fB\-\-dynamic\-syms\fR]
- [\fB\-x\fR|\fB\-\-all\-headers\fR]
- [\fB\-w\fR|\fB\-\-wide\fR]
- [\fB\-\-start\-address=\fR\fIaddress\fR]
- [\fB\-\-stop\-address=\fR\fIaddress\fR]
- [\fB\-\-prefix\-addresses\fR]
- [\fB\-\-[no\-]show\-raw\-insn\fR]
- [\fB\-\-adjust\-vma=\fR\fIoffset\fR]
- [\fB\-\-special\-syms\fR]
- [\fB\-\-prefix=\fR\fIprefix\fR]
- [\fB\-\-prefix\-strip=\fR\fIlevel\fR]
- [\fB\-\-insn\-width=\fR\fIwidth\fR]
- [\fB\-V\fR|\fB\-\-version\fR]
- [\fB\-H\fR|\fB\-\-help\fR]
- \fIobjfile\fR...
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\fBobjdump\fR displays information about one or more object files.
-The options control what particular information to display. This
-information is mostly useful to programmers who are working on the
-compilation tools, as opposed to programmers who just want their
-program to compile and work.
-.PP
-\&\fIobjfile\fR... are the object files to be examined. When you
-specify archives, \fBobjdump\fR shows information on each of the member
-object files.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-The long and short forms of options, shown here as alternatives, are
-equivalent. At least one option from the list
-\&\fB\-a,\-d,\-D,\-e,\-f,\-g,\-G,\-h,\-H,\-p,\-r,\-R,\-s,\-S,\-t,\-T,\-V,\-x\fR must be given.
-.IP "\fB\-a\fR" 4
-.IX Item "-a"
-.PD 0
-.IP "\fB\-\-archive\-header\fR" 4
-.IX Item "--archive-header"
-.PD
-If any of the \fIobjfile\fR files are archives, display the archive
-header information (in a format similar to \fBls \-l\fR). Besides the
-information you could list with \fBar tv\fR, \fBobjdump \-a\fR shows
-the object file format of each archive member.
-.IP "\fB\-\-adjust\-vma=\fR\fIoffset\fR" 4
-.IX Item "--adjust-vma=offset"
-When dumping information, first add \fIoffset\fR to all the section
-addresses. This is useful if the section addresses do not correspond to
-the symbol table, which can happen when putting sections at particular
-addresses when using a format which can not represent section addresses,
-such as a.out.
-.IP "\fB\-b\fR \fIbfdname\fR" 4
-.IX Item "-b bfdname"
-.PD 0
-.IP "\fB\-\-target=\fR\fIbfdname\fR" 4
-.IX Item "--target=bfdname"
-.PD
-Specify that the object-code format for the object files is
-\&\fIbfdname\fR. This option may not be necessary; \fIobjdump\fR can
-automatically recognize many formats.
-.Sp
-For example,
-.Sp
-.Vb 1
-\& objdump \-b oasys \-m vax \-h fu.o
-.Ve
-.Sp
-displays summary information from the section headers (\fB\-h\fR) of
-\&\fIfu.o\fR, which is explicitly identified (\fB\-m\fR) as a \s-1VAX\s0 object
-file in the format produced by Oasys compilers. You can list the
-formats available with the \fB\-i\fR option.
-.IP "\fB\-C\fR" 4
-.IX Item "-C"
-.PD 0
-.IP "\fB\-\-demangle[=\fR\fIstyle\fR\fB]\fR" 4
-.IX Item "--demangle[=style]"
-.PD
-Decode (\fIdemangle\fR) low-level symbol names into user-level names.
-Besides removing any initial underscore prepended by the system, this
-makes \*(C+ function names readable. Different compilers have different
-mangling styles. The optional demangling style argument can be used to
-choose an appropriate demangling style for your compiler.
-.IP "\fB\-g\fR" 4
-.IX Item "-g"
-.PD 0
-.IP "\fB\-\-debugging\fR" 4
-.IX Item "--debugging"
-.PD
-Display debugging information. This attempts to parse \s-1STABS\s0 and \s-1IEEE\s0
-debugging format information stored in the file and print it out using
-a C like syntax. If neither of these formats are found this option
-falls back on the \fB\-W\fR option to print any \s-1DWARF\s0 information in
-the file.
-.IP "\fB\-e\fR" 4
-.IX Item "-e"
-.PD 0
-.IP "\fB\-\-debugging\-tags\fR" 4
-.IX Item "--debugging-tags"
-.PD
-Like \fB\-g\fR, but the information is generated in a format compatible
-with ctags tool.
-.IP "\fB\-d\fR" 4
-.IX Item "-d"
-.PD 0
-.IP "\fB\-\-disassemble\fR" 4
-.IX Item "--disassemble"
-.PD
-Display the assembler mnemonics for the machine instructions from
-\&\fIobjfile\fR. This option only disassembles those sections which are
-expected to contain instructions.
-.IP "\fB\-D\fR" 4
-.IX Item "-D"
-.PD 0
-.IP "\fB\-\-disassemble\-all\fR" 4
-.IX Item "--disassemble-all"
-.PD
-Like \fB\-d\fR, but disassemble the contents of all sections, not just
-those expected to contain instructions.
-.Sp
-If the target is an \s-1ARM\s0 architecture this switch also has the effect
-of forcing the disassembler to decode pieces of data found in code
-sections as if they were instructions.
-.IP "\fB\-\-prefix\-addresses\fR" 4
-.IX Item "--prefix-addresses"
-When disassembling, print the complete address on each line. This is
-the older disassembly format.
-.IP "\fB\-EB\fR" 4
-.IX Item "-EB"
-.PD 0
-.IP "\fB\-EL\fR" 4
-.IX Item "-EL"
-.IP "\fB\-\-endian={big|little}\fR" 4
-.IX Item "--endian={big|little}"
-.PD
-Specify the endianness of the object files. This only affects
-disassembly. This can be useful when disassembling a file format which
-does not describe endianness information, such as S\-records.
-.IP "\fB\-f\fR" 4
-.IX Item "-f"
-.PD 0
-.IP "\fB\-\-file\-headers\fR" 4
-.IX Item "--file-headers"
-.PD
-Display summary information from the overall header of
-each of the \fIobjfile\fR files.
-.IP "\fB\-F\fR" 4
-.IX Item "-F"
-.PD 0
-.IP "\fB\-\-file\-offsets\fR" 4
-.IX Item "--file-offsets"
-.PD
-When disassembling sections, whenever a symbol is displayed, also
-display the file offset of the region of data that is about to be
-dumped. If zeroes are being skipped, then when disassembly resumes,
-tell the user how many zeroes were skipped and the file offset of the
-location from where the disassembly resumes. When dumping sections,
-display the file offset of the location from where the dump starts.
-.IP "\fB\-\-file\-start\-context\fR" 4
-.IX Item "--file-start-context"
-Specify that when displaying interlisted source code/disassembly
-(assumes \fB\-S\fR) from a file that has not yet been displayed, extend the
-context to the start of the file.
-.IP "\fB\-h\fR" 4
-.IX Item "-h"
-.PD 0
-.IP "\fB\-\-section\-headers\fR" 4
-.IX Item "--section-headers"
-.IP "\fB\-\-headers\fR" 4
-.IX Item "--headers"
-.PD
-Display summary information from the section headers of the
-object file.
-.Sp
-File segments may be relocated to nonstandard addresses, for example by
-using the \fB\-Ttext\fR, \fB\-Tdata\fR, or \fB\-Tbss\fR options to
-\&\fBld\fR. However, some object file formats, such as a.out, do not
-store the starting address of the file segments. In those situations,
-although \fBld\fR relocates the sections correctly, using \fBobjdump
-\&\-h\fR to list the file section headers cannot show the correct addresses.
-Instead, it shows the usual addresses, which are implicit for the
-target.
-.IP "\fB\-H\fR" 4
-.IX Item "-H"
-.PD 0
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-.PD
-Print a summary of the options to \fBobjdump\fR and exit.
-.IP "\fB\-i\fR" 4
-.IX Item "-i"
-.PD 0
-.IP "\fB\-\-info\fR" 4
-.IX Item "--info"
-.PD
-Display a list showing all architectures and object formats available
-for specification with \fB\-b\fR or \fB\-m\fR.
-.IP "\fB\-j\fR \fIname\fR" 4
-.IX Item "-j name"
-.PD 0
-.IP "\fB\-\-section=\fR\fIname\fR" 4
-.IX Item "--section=name"
-.PD
-Display information only for section \fIname\fR.
-.IP "\fB\-l\fR" 4
-.IX Item "-l"
-.PD 0
-.IP "\fB\-\-line\-numbers\fR" 4
-.IX Item "--line-numbers"
-.PD
-Label the display (using debugging information) with the filename and
-source line numbers corresponding to the object code or relocs shown.
-Only useful with \fB\-d\fR, \fB\-D\fR, or \fB\-r\fR.
-.IP "\fB\-m\fR \fImachine\fR" 4
-.IX Item "-m machine"
-.PD 0
-.IP "\fB\-\-architecture=\fR\fImachine\fR" 4
-.IX Item "--architecture=machine"
-.PD
-Specify the architecture to use when disassembling object files. This
-can be useful when disassembling object files which do not describe
-architecture information, such as S\-records. You can list the available
-architectures with the \fB\-i\fR option.
-.Sp
-If the target is an \s-1ARM\s0 architecture then this switch has an
-additional effect. It restricts the disassembly to only those
-instructions supported by the architecture specified by \fImachine\fR.
-If it is necessary to use this switch because the input file does not
-contain any architecture information, but it is also desired to
-disassemble all the instructions use \fB\-marm\fR.
-.IP "\fB\-M\fR \fIoptions\fR" 4
-.IX Item "-M options"
-.PD 0
-.IP "\fB\-\-disassembler\-options=\fR\fIoptions\fR" 4
-.IX Item "--disassembler-options=options"
-.PD
-Pass target specific information to the disassembler. Only supported on
-some targets. If it is necessary to specify more than one
-disassembler option then multiple \fB\-M\fR options can be used or
-can be placed together into a comma separated list.
-.Sp
-If the target is an \s-1ARM\s0 architecture then this switch can be used to
-select which register name set is used during disassembler. Specifying
-\&\fB\-M reg-names-std\fR (the default) will select the register names as
-used in \s-1ARM\s0's instruction set documentation, but with register 13 called
-\&'sp', register 14 called 'lr' and register 15 called 'pc'. Specifying
-\&\fB\-M reg-names-apcs\fR will select the name set used by the \s-1ARM\s0
-Procedure Call Standard, whilst specifying \fB\-M reg-names-raw\fR will
-just use \fBr\fR followed by the register number.
-.Sp
-There are also two variants on the \s-1APCS\s0 register naming scheme enabled
-by \fB\-M reg-names-atpcs\fR and \fB\-M reg-names-special-atpcs\fR which
-use the ARM/Thumb Procedure Call Standard naming conventions. (Either
-with the normal register names or the special register names).
-.Sp
-This option can also be used for \s-1ARM\s0 architectures to force the
-disassembler to interpret all instructions as Thumb instructions by
-using the switch \fB\-\-disassembler\-options=force\-thumb\fR. This can be
-useful when attempting to disassemble thumb code produced by other
-compilers.
-.Sp
-For the x86, some of the options duplicate functions of the \fB\-m\fR
-switch, but allow finer grained control. Multiple selections from the
-following may be specified as a comma separated string.
-\&\fBx86\-64\fR, \fBi386\fR and \fBi8086\fR select disassembly for
-the given architecture. \fBintel\fR and \fBatt\fR select between
-intel syntax mode and \s-1AT&T\s0 syntax mode.
-\&\fBintel-mnemonic\fR and \fBatt-mnemonic\fR select between
-intel mnemonic mode and \s-1AT&T\s0 mnemonic mode. \fBintel-mnemonic\fR
-implies \fBintel\fR and \fBatt-mnemonic\fR implies \fBatt\fR.
-\&\fBaddr64\fR, \fBaddr32\fR,
-\&\fBaddr16\fR, \fBdata32\fR and \fBdata16\fR specify the default
-address size and operand size. These four options will be overridden if
-\&\fBx86\-64\fR, \fBi386\fR or \fBi8086\fR appear later in the
-option string. Lastly, \fBsuffix\fR, when in \s-1AT&T\s0 mode,
-instructs the disassembler to print a mnemonic suffix even when the
-suffix could be inferred by the operands.
-.Sp
-For PowerPC, \fBbooke\fR controls the disassembly of BookE
-instructions. \fB32\fR and \fB64\fR select PowerPC and
-PowerPC64 disassembly, respectively. \fBe300\fR selects
-disassembly for the e300 family. \fB440\fR selects disassembly for
-the PowerPC 440. \fBppcps\fR selects disassembly for the paired
-single instructions of the \s-1PPC750CL\s0.
-.Sp
-For \s-1MIPS\s0, this option controls the printing of instruction mnemonic
-names and register names in disassembled instructions. Multiple
-selections from the following may be specified as a comma separated
-string, and invalid options are ignored:
-.RS 4
-.ie n .IP """no\-aliases""" 4
-.el .IP "\f(CWno\-aliases\fR" 4
-.IX Item "no-aliases"
-Print the 'raw' instruction mnemonic instead of some pseudo
-instruction mnemonic. I.e., print 'daddu' or 'or' instead of 'move',
-\&'sll' instead of 'nop', etc.
-.ie n .IP """gpr\-names=\f(CIABI\f(CW""" 4
-.el .IP "\f(CWgpr\-names=\f(CIABI\f(CW\fR" 4
-.IX Item "gpr-names=ABI"
-Print \s-1GPR\s0 (general-purpose register) names as appropriate
-for the specified \s-1ABI\s0. By default, \s-1GPR\s0 names are selected according to
-the \s-1ABI\s0 of the binary being disassembled.
-.ie n .IP """fpr\-names=\f(CIABI\f(CW""" 4
-.el .IP "\f(CWfpr\-names=\f(CIABI\f(CW\fR" 4
-.IX Item "fpr-names=ABI"
-Print \s-1FPR\s0 (floating-point register) names as
-appropriate for the specified \s-1ABI\s0. By default, \s-1FPR\s0 numbers are printed
-rather than names.
-.ie n .IP """cp0\-names=\f(CIARCH\f(CW""" 4
-.el .IP "\f(CWcp0\-names=\f(CIARCH\f(CW\fR" 4
-.IX Item "cp0-names=ARCH"
-Print \s-1CP0\s0 (system control coprocessor; coprocessor 0) register names
-as appropriate for the \s-1CPU\s0 or architecture specified by
-\&\fI\s-1ARCH\s0\fR. By default, \s-1CP0\s0 register names are selected according to
-the architecture and \s-1CPU\s0 of the binary being disassembled.
-.ie n .IP """hwr\-names=\f(CIARCH\f(CW""" 4
-.el .IP "\f(CWhwr\-names=\f(CIARCH\f(CW\fR" 4
-.IX Item "hwr-names=ARCH"
-Print \s-1HWR\s0 (hardware register, used by the \f(CW\*(C`rdhwr\*(C'\fR instruction) names
-as appropriate for the \s-1CPU\s0 or architecture specified by
-\&\fI\s-1ARCH\s0\fR. By default, \s-1HWR\s0 names are selected according to
-the architecture and \s-1CPU\s0 of the binary being disassembled.
-.ie n .IP """reg\-names=\f(CIABI\f(CW""" 4
-.el .IP "\f(CWreg\-names=\f(CIABI\f(CW\fR" 4
-.IX Item "reg-names=ABI"
-Print \s-1GPR\s0 and \s-1FPR\s0 names as appropriate for the selected \s-1ABI\s0.
-.ie n .IP """reg\-names=\f(CIARCH\f(CW""" 4
-.el .IP "\f(CWreg\-names=\f(CIARCH\f(CW\fR" 4
-.IX Item "reg-names=ARCH"
-Print CPU-specific register names (\s-1CP0\s0 register and \s-1HWR\s0 names)
-as appropriate for the selected \s-1CPU\s0 or architecture.
-.RE
-.RS 4
-.Sp
-For any of the options listed above, \fI\s-1ABI\s0\fR or
-\&\fI\s-1ARCH\s0\fR may be specified as \fBnumeric\fR to have numbers printed
-rather than names, for the selected types of registers.
-You can list the available values of \fI\s-1ABI\s0\fR and \fI\s-1ARCH\s0\fR using
-the \fB\-\-help\fR option.
-.Sp
-For \s-1VAX\s0, you can specify function entry addresses with \fB\-M
-entry:0xf00ba\fR. You can use this multiple times to properly
-disassemble \s-1VAX\s0 binary files that don't contain symbol tables (like
-\&\s-1ROM\s0 dumps). In these cases, the function entry mask would otherwise
-be decoded as \s-1VAX\s0 instructions, which would probably lead the rest
-of the function being wrongly disassembled.
-.RE
-.IP "\fB\-p\fR" 4
-.IX Item "-p"
-.PD 0
-.IP "\fB\-\-private\-headers\fR" 4
-.IX Item "--private-headers"
-.PD
-Print information that is specific to the object file format. The exact
-information printed depends upon the object file format. For some
-object file formats, no additional information is printed.
-.IP "\fB\-r\fR" 4
-.IX Item "-r"
-.PD 0
-.IP "\fB\-\-reloc\fR" 4
-.IX Item "--reloc"
-.PD
-Print the relocation entries of the file. If used with \fB\-d\fR or
-\&\fB\-D\fR, the relocations are printed interspersed with the
-disassembly.
-.IP "\fB\-R\fR" 4
-.IX Item "-R"
-.PD 0
-.IP "\fB\-\-dynamic\-reloc\fR" 4
-.IX Item "--dynamic-reloc"
-.PD
-Print the dynamic relocation entries of the file. This is only
-meaningful for dynamic objects, such as certain types of shared
-libraries. As for \fB\-r\fR, if used with \fB\-d\fR or
-\&\fB\-D\fR, the relocations are printed interspersed with the
-disassembly.
-.IP "\fB\-s\fR" 4
-.IX Item "-s"
-.PD 0
-.IP "\fB\-\-full\-contents\fR" 4
-.IX Item "--full-contents"
-.PD
-Display the full contents of any sections requested. By default all
-non-empty sections are displayed.
-.IP "\fB\-S\fR" 4
-.IX Item "-S"
-.PD 0
-.IP "\fB\-\-source\fR" 4
-.IX Item "--source"
-.PD
-Display source code intermixed with disassembly, if possible. Implies
-\&\fB\-d\fR.
-.IP "\fB\-\-prefix=\fR\fIprefix\fR" 4
-.IX Item "--prefix=prefix"
-Specify \fIprefix\fR to add to the absolute paths when used with
-\&\fB\-S\fR.
-.IP "\fB\-\-prefix\-strip=\fR\fIlevel\fR" 4
-.IX Item "--prefix-strip=level"
-Indicate how many initial directory names to strip off the hardwired
-absolute paths. It has no effect without \fB\-\-prefix=\fR\fIprefix\fR.
-.IP "\fB\-\-show\-raw\-insn\fR" 4
-.IX Item "--show-raw-insn"
-When disassembling instructions, print the instruction in hex as well as
-in symbolic form. This is the default except when
-\&\fB\-\-prefix\-addresses\fR is used.
-.IP "\fB\-\-no\-show\-raw\-insn\fR" 4
-.IX Item "--no-show-raw-insn"
-When disassembling instructions, do not print the instruction bytes.
-This is the default when \fB\-\-prefix\-addresses\fR is used.
-.IP "\fB\-\-insn\-width=\fR\fIwidth\fR" 4
-.IX Item "--insn-width=width"
-Display \fIwidth\fR bytes on a single line when disassembling
-instructions.
-.IP "\fB\-W[lLiaprmfFsoRt]\fR" 4
-.IX Item "-W[lLiaprmfFsoRt]"
-.PD 0
-.IP "\fB\-\-dwarf[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames\-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges]\fR" 4
-.IX Item "--dwarf[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges]"
-.PD
-Displays the contents of the debug sections in the file, if any are
-present. If one of the optional letters or words follows the switch
-then only data found in those specific sections will be dumped.
-.Sp
-Note that there is no single letter option to display the content of
-trace sections.
-.IP "\fB\-G\fR" 4
-.IX Item "-G"
-.PD 0
-.IP "\fB\-\-stabs\fR" 4
-.IX Item "--stabs"
-.PD
-Display the full contents of any sections requested. Display the
-contents of the .stab and .stab.index and .stab.excl sections from an
-\&\s-1ELF\s0 file. This is only useful on systems (such as Solaris 2.0) in which
-\&\f(CW\*(C`.stab\*(C'\fR debugging symbol-table entries are carried in an \s-1ELF\s0
-section. In most other file formats, debugging symbol-table entries are
-interleaved with linkage symbols, and are visible in the \fB\-\-syms\fR
-output.
-.IP "\fB\-\-start\-address=\fR\fIaddress\fR" 4
-.IX Item "--start-address=address"
-Start displaying data at the specified address. This affects the output
-of the \fB\-d\fR, \fB\-r\fR and \fB\-s\fR options.
-.IP "\fB\-\-stop\-address=\fR\fIaddress\fR" 4
-.IX Item "--stop-address=address"
-Stop displaying data at the specified address. This affects the output
-of the \fB\-d\fR, \fB\-r\fR and \fB\-s\fR options.
-.IP "\fB\-t\fR" 4
-.IX Item "-t"
-.PD 0
-.IP "\fB\-\-syms\fR" 4
-.IX Item "--syms"
-.PD
-Print the symbol table entries of the file.
-This is similar to the information provided by the \fBnm\fR program,
-although the display format is different. The format of the output
-depends upon the format of the file being dumped, but there are two main
-types. One looks like this:
-.Sp
-.Vb 2
-\& [ 4](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .bss
-\& [ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 fred
-.Ve
-.Sp
-where the number inside the square brackets is the number of the entry
-in the symbol table, the \fIsec\fR number is the section number, the
-\&\fIfl\fR value are the symbol's flag bits, the \fIty\fR number is the
-symbol's type, the \fIscl\fR number is the symbol's storage class and
-the \fInx\fR value is the number of auxilary entries associated with
-the symbol. The last two fields are the symbol's value and its name.
-.Sp
-The other common output format, usually seen with \s-1ELF\s0 based files,
-looks like this:
-.Sp
-.Vb 2
-\& 00000000 l d .bss 00000000 .bss
-\& 00000000 g .text 00000000 fred
-.Ve
-.Sp
-Here the first number is the symbol's value (sometimes refered to as
-its address). The next field is actually a set of characters and
-spaces indicating the flag bits that are set on the symbol. These
-characters are described below. Next is the section with which the
-symbol is associated or \fI*ABS*\fR if the section is absolute (ie
-not connected with any section), or \fI*UND*\fR if the section is
-referenced in the file being dumped, but not defined there.
-.Sp
-After the section name comes another field, a number, which for common
-symbols is the alignment and for other symbol is the size. Finally
-the symbol's name is displayed.
-.Sp
-The flag characters are divided into 7 groups as follows:
-.RS 4
-.ie n .IP """l""" 4
-.el .IP "\f(CWl\fR" 4
-.IX Item "l"
-.PD 0
-.ie n .IP """g""" 4
-.el .IP "\f(CWg\fR" 4
-.IX Item "g"
-.ie n .IP """u""" 4
-.el .IP "\f(CWu\fR" 4
-.IX Item "u"
-.ie n .IP """!""" 4
-.el .IP "\f(CW!\fR" 4
-.IX Item "!"
-.PD
-The symbol is a local (l), global (g), unique global (u), neither
-global nor local (a space) or both global and local (!). A
-symbol can be neither local or global for a variety of reasons, e.g.,
-because it is used for debugging, but it is probably an indication of
-a bug if it is ever both local and global. Unique global symbols are
-a \s-1GNU\s0 extension to the standard set of \s-1ELF\s0 symbol bindings. For such
-a symbol the dynamic linker will make sure that in the entire process
-there is just one symbol with this name and type in use.
-.ie n .IP """w""" 4
-.el .IP "\f(CWw\fR" 4
-.IX Item "w"
-The symbol is weak (w) or strong (a space).
-.ie n .IP """C""" 4
-.el .IP "\f(CWC\fR" 4
-.IX Item "C"
-The symbol denotes a constructor (C) or an ordinary symbol (a space).
-.ie n .IP """W""" 4
-.el .IP "\f(CWW\fR" 4
-.IX Item "W"
-The symbol is a warning (W) or a normal symbol (a space). A warning
-symbol's name is a message to be displayed if the symbol following the
-warning symbol is ever referenced.
-.ie n .IP """I""" 4
-.el .IP "\f(CWI\fR" 4
-.IX Item "I"
-.PD 0
-.ie n .IP """i""" 4
-.el .IP "\f(CWi\fR" 4
-.IX Item "i"
-.PD
-The symbol is an indirect reference to another symbol (I), a function
-to be evaluated during reloc processing (i) or a normal symbol (a
-space).
-.ie n .IP """d""" 4
-.el .IP "\f(CWd\fR" 4
-.IX Item "d"
-.PD 0
-.ie n .IP """D""" 4
-.el .IP "\f(CWD\fR" 4
-.IX Item "D"
-.PD
-The symbol is a debugging symbol (d) or a dynamic symbol (D) or a
-normal symbol (a space).
-.ie n .IP """F""" 4
-.el .IP "\f(CWF\fR" 4
-.IX Item "F"
-.PD 0
-.ie n .IP """f""" 4
-.el .IP "\f(CWf\fR" 4
-.IX Item "f"
-.ie n .IP """O""" 4
-.el .IP "\f(CWO\fR" 4
-.IX Item "O"
-.PD
-The symbol is the name of a function (F) or a file (f) or an object
-(O) or just a normal symbol (a space).
-.RE
-.RS 4
-.RE
-.IP "\fB\-T\fR" 4
-.IX Item "-T"
-.PD 0
-.IP "\fB\-\-dynamic\-syms\fR" 4
-.IX Item "--dynamic-syms"
-.PD
-Print the dynamic symbol table entries of the file. This is only
-meaningful for dynamic objects, such as certain types of shared
-libraries. This is similar to the information provided by the \fBnm\fR
-program when given the \fB\-D\fR (\fB\-\-dynamic\fR) option.
-.IP "\fB\-\-special\-syms\fR" 4
-.IX Item "--special-syms"
-When displaying symbols include those which the target considers to be
-special in some way and which would not normally be of interest to the
-user.
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Print the version number of \fBobjdump\fR and exit.
-.IP "\fB\-x\fR" 4
-.IX Item "-x"
-.PD 0
-.IP "\fB\-\-all\-headers\fR" 4
-.IX Item "--all-headers"
-.PD
-Display all available header information, including the symbol table and
-relocation entries. Using \fB\-x\fR is equivalent to specifying all of
-\&\fB\-a \-f \-h \-p \-r \-t\fR.
-.IP "\fB\-w\fR" 4
-.IX Item "-w"
-.PD 0
-.IP "\fB\-\-wide\fR" 4
-.IX Item "--wide"
-.PD
-Format some lines for output devices that have more than 80 columns.
-Also do not truncate symbol names when they are displayed.
-.IP "\fB\-z\fR" 4
-.IX Item "-z"
-.PD 0
-.IP "\fB\-\-disassemble\-zeroes\fR" 4
-.IX Item "--disassemble-zeroes"
-.PD
-Normally the disassembly output will skip blocks of zeroes. This
-option directs the disassembler to disassemble those blocks, just like
-any other data.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fInm\fR\|(1), \fIreadelf\fR\|(1), and the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-ranlib.1 b/share/man/man1/arm-eabi-ranlib.1
deleted file mode 100644
index 781d9ef..0000000
--- a/share/man/man1/arm-eabi-ranlib.1
+++ /dev/null
@@ -1,192 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "RANLIB 1"
-.TH RANLIB 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-ranlib \- generate index to archive.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-ranlib [\fB\-vVt\fR] \fIarchive\fR
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\fBranlib\fR generates an index to the contents of an archive and
-stores it in the archive. The index lists each symbol defined by a
-member of an archive that is a relocatable object file.
-.PP
-You may use \fBnm \-s\fR or \fBnm \-\-print\-armap\fR to list this index.
-.PP
-An archive with such an index speeds up linking to the library and
-allows routines in the library to call each other without regard to
-their placement in the archive.
-.PP
-The \s-1GNU\s0 \fBranlib\fR program is another form of \s-1GNU\s0 \fBar\fR; running
-\&\fBranlib\fR is completely equivalent to executing \fBar \-s\fR.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Show the version number of \fBranlib\fR.
-.IP "\fB\-t\fR" 4
-.IX Item "-t"
-Update the timestamp of the symbol map of an archive.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIar\fR\|(1), \fInm\fR\|(1), and the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-readelf.1 b/share/man/man1/arm-eabi-readelf.1
deleted file mode 100644
index 5fe93d7..0000000
--- a/share/man/man1/arm-eabi-readelf.1
+++ /dev/null
@@ -1,426 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "READELF 1"
-.TH READELF 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-readelf \- Displays information about ELF files.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-readelf [\fB\-a\fR|\fB\-\-all\fR]
- [\fB\-h\fR|\fB\-\-file\-header\fR]
- [\fB\-l\fR|\fB\-\-program\-headers\fR|\fB\-\-segments\fR]
- [\fB\-S\fR|\fB\-\-section\-headers\fR|\fB\-\-sections\fR]
- [\fB\-g\fR|\fB\-\-section\-groups\fR]
- [\fB\-t\fR|\fB\-\-section\-details\fR]
- [\fB\-e\fR|\fB\-\-headers\fR]
- [\fB\-s\fR|\fB\-\-syms\fR|\fB\-\-symbols\fR]
- [\fB\-\-dyn\-syms\fR]
- [\fB\-n\fR|\fB\-\-notes\fR]
- [\fB\-r\fR|\fB\-\-relocs\fR]
- [\fB\-u\fR|\fB\-\-unwind\fR]
- [\fB\-d\fR|\fB\-\-dynamic\fR]
- [\fB\-V\fR|\fB\-\-version\-info\fR]
- [\fB\-A\fR|\fB\-\-arch\-specific\fR]
- [\fB\-D\fR|\fB\-\-use\-dynamic\fR]
- [\fB\-x\fR <number or name>|\fB\-\-hex\-dump=\fR<number or name>]
- [\fB\-p\fR <number or name>|\fB\-\-string\-dump=\fR<number or name>]
- [\fB\-R\fR <number or name>|\fB\-\-relocated\-dump=\fR<number or name>]
- [\fB\-c\fR|\fB\-\-archive\-index\fR]
- [\fB\-w[lLiaprmfFsoRt]\fR|
- \fB\-\-debug\-dump\fR[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames\-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges]]
- [\fB\-I\fR|\fB\-\-histogram\fR]
- [\fB\-v\fR|\fB\-\-version\fR]
- [\fB\-W\fR|\fB\-\-wide\fR]
- [\fB\-H\fR|\fB\-\-help\fR]
- \fIelffile\fR...
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\fBreadelf\fR displays information about one or more \s-1ELF\s0 format object
-files. The options control what particular information to display.
-.PP
-\&\fIelffile\fR... are the object files to be examined. 32\-bit and
-64\-bit \s-1ELF\s0 files are supported, as are archives containing \s-1ELF\s0 files.
-.PP
-This program performs a similar function to \fBobjdump\fR but it
-goes into more detail and it exists independently of the \s-1BFD\s0
-library, so if there is a bug in \s-1BFD\s0 then readelf will not be
-affected.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-The long and short forms of options, shown here as alternatives, are
-equivalent. At least one option besides \fB\-v\fR or \fB\-H\fR must be
-given.
-.IP "\fB\-a\fR" 4
-.IX Item "-a"
-.PD 0
-.IP "\fB\-\-all\fR" 4
-.IX Item "--all"
-.PD
-Equivalent to specifying \fB\-\-file\-header\fR,
-\&\fB\-\-program\-headers\fR, \fB\-\-sections\fR, \fB\-\-symbols\fR,
-\&\fB\-\-relocs\fR, \fB\-\-dynamic\fR, \fB\-\-notes\fR and
-\&\fB\-\-version\-info\fR.
-.IP "\fB\-h\fR" 4
-.IX Item "-h"
-.PD 0
-.IP "\fB\-\-file\-header\fR" 4
-.IX Item "--file-header"
-.PD
-Displays the information contained in the \s-1ELF\s0 header at the start of the
-file.
-.IP "\fB\-l\fR" 4
-.IX Item "-l"
-.PD 0
-.IP "\fB\-\-program\-headers\fR" 4
-.IX Item "--program-headers"
-.IP "\fB\-\-segments\fR" 4
-.IX Item "--segments"
-.PD
-Displays the information contained in the file's segment headers, if it
-has any.
-.IP "\fB\-S\fR" 4
-.IX Item "-S"
-.PD 0
-.IP "\fB\-\-sections\fR" 4
-.IX Item "--sections"
-.IP "\fB\-\-section\-headers\fR" 4
-.IX Item "--section-headers"
-.PD
-Displays the information contained in the file's section headers, if it
-has any.
-.IP "\fB\-g\fR" 4
-.IX Item "-g"
-.PD 0
-.IP "\fB\-\-section\-groups\fR" 4
-.IX Item "--section-groups"
-.PD
-Displays the information contained in the file's section groups, if it
-has any.
-.IP "\fB\-t\fR" 4
-.IX Item "-t"
-.PD 0
-.IP "\fB\-\-section\-details\fR" 4
-.IX Item "--section-details"
-.PD
-Displays the detailed section information. Implies \fB\-S\fR.
-.IP "\fB\-s\fR" 4
-.IX Item "-s"
-.PD 0
-.IP "\fB\-\-symbols\fR" 4
-.IX Item "--symbols"
-.IP "\fB\-\-syms\fR" 4
-.IX Item "--syms"
-.PD
-Displays the entries in symbol table section of the file, if it has one.
-.IP "\fB\-\-dyn\-syms\fR" 4
-.IX Item "--dyn-syms"
-Displays the entries in dynamic symbol table section of the file, if it
-has one.
-.IP "\fB\-e\fR" 4
-.IX Item "-e"
-.PD 0
-.IP "\fB\-\-headers\fR" 4
-.IX Item "--headers"
-.PD
-Display all the headers in the file. Equivalent to \fB\-h \-l \-S\fR.
-.IP "\fB\-n\fR" 4
-.IX Item "-n"
-.PD 0
-.IP "\fB\-\-notes\fR" 4
-.IX Item "--notes"
-.PD
-Displays the contents of the \s-1NOTE\s0 segments and/or sections, if any.
-.IP "\fB\-r\fR" 4
-.IX Item "-r"
-.PD 0
-.IP "\fB\-\-relocs\fR" 4
-.IX Item "--relocs"
-.PD
-Displays the contents of the file's relocation section, if it has one.
-.IP "\fB\-u\fR" 4
-.IX Item "-u"
-.PD 0
-.IP "\fB\-\-unwind\fR" 4
-.IX Item "--unwind"
-.PD
-Displays the contents of the file's unwind section, if it has one. Only
-the unwind sections for \s-1IA64\s0 \s-1ELF\s0 files, as well as \s-1ARM\s0 unwind tables
-(\f(CW\*(C`.ARM.exidx\*(C'\fR / \f(CW\*(C`.ARM.extab\*(C'\fR) are currently supported.
-.IP "\fB\-d\fR" 4
-.IX Item "-d"
-.PD 0
-.IP "\fB\-\-dynamic\fR" 4
-.IX Item "--dynamic"
-.PD
-Displays the contents of the file's dynamic section, if it has one.
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.PD 0
-.IP "\fB\-\-version\-info\fR" 4
-.IX Item "--version-info"
-.PD
-Displays the contents of the version sections in the file, it they
-exist.
-.IP "\fB\-A\fR" 4
-.IX Item "-A"
-.PD 0
-.IP "\fB\-\-arch\-specific\fR" 4
-.IX Item "--arch-specific"
-.PD
-Displays architecture-specific information in the file, if there
-is any.
-.IP "\fB\-D\fR" 4
-.IX Item "-D"
-.PD 0
-.IP "\fB\-\-use\-dynamic\fR" 4
-.IX Item "--use-dynamic"
-.PD
-When displaying symbols, this option makes \fBreadelf\fR use the
-symbol hash tables in the file's dynamic section, rather than the
-symbol table sections.
-.IP "\fB\-x <number or name>\fR" 4
-.IX Item "-x <number or name>"
-.PD 0
-.IP "\fB\-\-hex\-dump=<number or name>\fR" 4
-.IX Item "--hex-dump=<number or name>"
-.PD
-Displays the contents of the indicated section as a hexadecimal bytes.
-A number identifies a particular section by index in the section table;
-any other string identifies all sections with that name in the object file.
-.IP "\fB\-R <number or name>\fR" 4
-.IX Item "-R <number or name>"
-.PD 0
-.IP "\fB\-\-relocated\-dump=<number or name>\fR" 4
-.IX Item "--relocated-dump=<number or name>"
-.PD
-Displays the contents of the indicated section as a hexadecimal
-bytes. A number identifies a particular section by index in the
-section table; any other string identifies all sections with that name
-in the object file. The contents of the section will be relocated
-before they are displayed.
-.IP "\fB\-p <number or name>\fR" 4
-.IX Item "-p <number or name>"
-.PD 0
-.IP "\fB\-\-string\-dump=<number or name>\fR" 4
-.IX Item "--string-dump=<number or name>"
-.PD
-Displays the contents of the indicated section as printable strings.
-A number identifies a particular section by index in the section table;
-any other string identifies all sections with that name in the object file.
-.IP "\fB\-c\fR" 4
-.IX Item "-c"
-.PD 0
-.IP "\fB\-\-archive\-index\fR" 4
-.IX Item "--archive-index"
-.PD
-Displays the file symbol index infomation contained in the header part
-of binary archives. Performs the same function as the \fBt\fR
-command to \fBar\fR, but without using the \s-1BFD\s0 library.
-.IP "\fB\-w[lLiaprmfFsoRt]\fR" 4
-.IX Item "-w[lLiaprmfFsoRt]"
-.PD 0
-.IP "\fB\-\-debug\-dump[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames\-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges]\fR" 4
-.IX Item "--debug-dump[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges]"
-.PD
-Displays the contents of the debug sections in the file, if any are
-present. If one of the optional letters or words follows the switch
-then only data found in those specific sections will be dumped.
-.Sp
-Note that there is no single letter option to display the content of
-trace sections.
-.Sp
-Note: the \fB=decodedline\fR option will display the interpreted
-contents of a .debug_line section whereas the \fB=rawline\fR option
-dumps the contents in a raw format.
-.Sp
-Note: the \fB=frames\-interp\fR option will display the interpreted
-contents of a .debug_frame section whereas the \fB=frames\fR option
-dumps the contents in a raw format.
-.IP "\fB\-I\fR" 4
-.IX Item "-I"
-.PD 0
-.IP "\fB\-\-histogram\fR" 4
-.IX Item "--histogram"
-.PD
-Display a histogram of bucket list lengths when displaying the contents
-of the symbol tables.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Display the version number of readelf.
-.IP "\fB\-W\fR" 4
-.IX Item "-W"
-.PD 0
-.IP "\fB\-\-wide\fR" 4
-.IX Item "--wide"
-.PD
-Don't break output lines to fit into 80 columns. By default
-\&\fBreadelf\fR breaks section header and segment listing lines for
-64\-bit \s-1ELF\s0 files, so that they fit into 80 columns. This option causes
-\&\fBreadelf\fR to print each section header resp. each segment one a
-single line, which is far more readable on terminals wider than 80 columns.
-.IP "\fB\-H\fR" 4
-.IX Item "-H"
-.PD 0
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-.PD
-Display the command line options understood by \fBreadelf\fR.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIobjdump\fR\|(1), and the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-run.1 b/share/man/man1/arm-eabi-run.1
deleted file mode 100644
index 8bc2706..0000000
--- a/share/man/man1/arm-eabi-run.1
+++ /dev/null
@@ -1,475 +0,0 @@
-.\" Copyright (c) 1993, 2004, 2010, 2011 Free Software Foundation
-.\" See section COPYING for conditions for redistribution
-.TH run 1 "13oct1993" "GNU Tools" "GNU Tools"
-.de BP
-.sp
-.ti -.2i
-\(**
-..
-
-.SH NAME
-run\(em\&Simulator front-end
-
-.SH SYNOPSIS
-.hy 0
-.na
-.TP
-.B run
-.RB "[\|" \-v "\|]"
-." .RB "[\|" \-t "\|]"
-.RB "[\|" \-p
-.IR freq "\|]"
-.RB "[\|" \-m
-.IR memory "\|]"
-.RB "[\|" \--sysroot
-.IR filepath "\|]"
-.I program
-.ad b
-.hy 1
-.SH DESCRIPTION
-
-Use `\|\c
-.BI run " program"\c
-\&\|' to execute a binary by interpreting machine instructions on your
-host computer.
-
-.B run
-is the same emulator used by GDB's `\|\c
-.B target sim\c
-\&\|' command. You can run it directly by executing
-.B run
-if you just want to see your program execute, and do not need any
-debugger functionality. You can also use
-.B run
-to generate profiling information for analysis with
-.BR gprof .
-
-.SH OPTIONS
-
-.TP
-.B \-v
-Verbose output. Display the name of the program to run before
-execution; after execution, display the number of instructions
-executed, the number of machine cycles emulated, the number of
-pipeline stalls, the real time taken, the emulated execution time
-taken, and a summary of how much profiling information was generated.
-."
-." .TP
-." .B \-t
-." `trace', calls a sim_trace routine that does nothing.
-
-.TP
-.BI \-p " freq"
-Generate profile information (for use with
-.B gprof\c
-\&).
-.I freq
-is the profiling frequency. Write the profiling information to a file called
-.BR gmon.out .
-
-.TP
-.BI \-m " memory"
-Set the memory size for the emulated machine to two to the power
-.IR memory .
-The default value is 19, emulating a board with 524288 bytes of memory.
-
-.TP
-.BI \--sysroot " filepath"
-Prepend
-.IR filepath
-to all simulator system calls that pass absolute file paths.
-Change working directory to
-.IR filepath
-at program start. Not all simulators support this option; those
-that don't, will ignore it.
-
-.PP
-
-.SH "SEE ALSO"
-.RB "`\|" gprof "\|'"
-entry in
-.B info\c
-\&;
-.RB "`\|" gdb "\|'"
-entry in
-.B info\c
-\&;
-.I
-Using GDB: A Guide to the GNU Source-Level Debugger\c
-, Richard M. Stallman and Roland H. Pesch.
-
-.SH COPYING
-Copyright (c) 1993, 2000 Free Software Foundation, Inc.
-.PP
-This document is distributed under the terms of the GNU Free
-Documentation License, version 1.1. That license is described in the
-sources for this manual page, but it is not displayed here in order to
-make this manual more consise. Copies of this license can also be
-obtained from: http://www.gnu.org/copyleft/.
-
-\" GNU Free Documentation License
-\" Version 1.1, March 2000
-
-\" Copyright (C) 2000 Free Software Foundation, Inc.
-\" 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-
-\" Everyone is permitted to copy and distribute verbatim
-\" copies of this license document, but changing it is
-\" not allowed.
-\" .PP
-\" 0. PREAMBLE
-\" .PP
-\" The purpose of this License is to make a manual, textbook, or other
-\" written document "free" in the sense of freedom: to assure everyone
-\" the effective freedom to copy and redistribute it, with or without
-\" modifying it, either commercially or noncommercially. Secondarily,
-\" this License preserves for the author and publisher a way to get
-\" credit for their work, while not being considered responsible for
-\" modifications made by others.
-\" .PP
-\" This License is a kind of "copyleft", which means that derivative
-\" works of the document must themselves be free in the same sense. It
-\" complements the GNU General Public License, which is a copyleft
-\" license designed for free software.
-\" .PP
-\" We have designed this License in order to use it for manuals for free
-\" software, because free software needs free documentation: a free
-\" program should come with manuals providing the same freedoms that the
-\" software does. But this License is not limited to software manuals;
-\" it can be used for any textual work, regardless of subject matter or
-\" whether it is published as a printed book. We recommend this License
-\" principally for works whose purpose is instruction or reference.
-\" .PP
-\" 1. APPLICABILITY AND DEFINITIONS
-\" .PP
-\" This License applies to any manual or other work that contains a
-\" notice placed by the copyright holder saying it can be distributed
-\" under the terms of this License. The "Document", below, refers to any
-\" such manual or work. Any member of the public is a licensee, and is
-\" addressed as "you".
-\" .PP
-\" A "Modified Version" of the Document means any work containing the
-\" Document or a portion of it, either copied verbatim, or with
-\" modifications and/or translated into another language.
-\" .PP
-\" A "Secondary Section" is a named appendix or a front-matter section of
-\" the Document that deals exclusively with the relationship of the
-\" publishers or authors of the Document to the Document's overall subject
-\" (or to related matters) and contains nothing that could fall directly
-\" within that overall subject. (For example, if the Document is in part a
-\" textbook of mathematics, a Secondary Section may not explain any
-\" mathematics.) The relationship could be a matter of historical
-\" connection with the subject or with related matters, or of legal,
-\" commercial, philosophical, ethical or political position regarding
-\" them.
-\" .PP
-\" The "Invariant Sections" are certain Secondary Sections whose titles
-\" are designated, as being those of Invariant Sections, in the notice
-\" that says that the Document is released under this License.
-\" .PP
-\" The "Cover Texts" are certain short passages of text that are listed,
-\" as Front-Cover Texts or Back-Cover Texts, in the notice that says that
-\" the Document is released under this License.
-\" .PP
-\" A "Transparent" copy of the Document means a machine-readable copy,
-\" represented in a format whose specification is available to the
-\" general public, whose contents can be viewed and edited directly and
-\" straightforwardly with generic text editors or (for images composed of
-\" pixels) generic paint programs or (for drawings) some widely available
-\" drawing editor, and that is suitable for input to text formatters or
-\" for automatic translation to a variety of formats suitable for input
-\" to text formatters. A copy made in an otherwise Transparent file
-\" format whose markup has been designed to thwart or discourage
-\" subsequent modification by readers is not Transparent. A copy that is
-\" not "Transparent" is called "Opaque".
-\" .PP
-\" Examples of suitable formats for Transparent copies include plain
-\" ASCII without markup, Texinfo input format, LaTeX input format, SGML
-\" or XML using a publicly available DTD, and standard-conforming simple
-\" HTML designed for human modification. Opaque formats include
-\" PostScript, PDF, proprietary formats that can be read and edited only
-\" by proprietary word processors, SGML or XML for which the DTD and/or
-\" processing tools are not generally available, and the
-\" machine-generated HTML produced by some word processors for output
-\" purposes only.
-\" .PP
-\" The "Title Page" means, for a printed book, the title page itself,
-\" plus such following pages as are needed to hold, legibly, the material
-\" this License requires to appear in the title page. For works in
-\" formats which do not have any title page as such, "Title Page" means
-\" the text near the most prominent appearance of the work's title,
-\" preceding the beginning of the body of the text.
-\" .PP
-\" 2. VERBATIM COPYING
-\" .PP
-\" You may copy and distribute the Document in any medium, either
-\" commercially or noncommercially, provided that this License, the
-\" copyright notices, and the license notice saying this License applies
-\" to the Document are reproduced in all copies, and that you add no other
-\" conditions whatsoever to those of this License. You may not use
-\" technical measures to obstruct or control the reading or further
-\" copying of the copies you make or distribute. However, you may accept
-\" compensation in exchange for copies. If you distribute a large enough
-\" number of copies you must also follow the conditions in section 3.
-\" .PP
-\" You may also lend copies, under the same conditions stated above, and
-\" you may publicly display copies.
-\" .PP
-\" 3. COPYING IN QUANTITY
-\" .PP
-\" If you publish printed copies of the Document numbering more than 100,
-\" and the Document's license notice requires Cover Texts, you must enclose
-\" the copies in covers that carry, clearly and legibly, all these Cover
-\" Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
-\" the back cover. Both covers must also clearly and legibly identify
-\" you as the publisher of these copies. The front cover must present
-\" the full title with all words of the title equally prominent and
-\" visible. You may add other material on the covers in addition.
-\" Copying with changes limited to the covers, as long as they preserve
-\" the title of the Document and satisfy these conditions, can be treated
-\" as verbatim copying in other respects.
-\" .PP
-\" If the required texts for either cover are too voluminous to fit
-\" legibly, you should put the first ones listed (as many as fit
-\" reasonably) on the actual cover, and continue the rest onto adjacent
-\" pages.
-\" .PP
-\" If you publish or distribute Opaque copies of the Document numbering
-\" more than 100, you must either include a machine-readable Transparent
-\" copy along with each Opaque copy, or state in or with each Opaque copy
-\" a publicly-accessible computer-network location containing a complete
-\" Transparent copy of the Document, free of added material, which the
-\" general network-using public has access to download anonymously at no
-\" charge using public-standard network protocols. If you use the latter
-\" option, you must take reasonably prudent steps, when you begin
-\" distribution of Opaque copies in quantity, to ensure that this
-\" Transparent copy will remain thus accessible at the stated location
-\" until at least one year after the last time you distribute an Opaque
-\" copy (directly or through your agents or retailers) of that edition to
-\" the public.
-\" .PP
-\" It is requested, but not required, that you contact the authors of the
-\" Document well before redistributing any large number of copies, to give
-\" them a chance to provide you with an updated version of the Document.
-\" .PP
-\" 4. MODIFICATIONS
-\" .PP
-\" You may copy and distribute a Modified Version of the Document under
-\" the conditions of sections 2 and 3 above, provided that you release
-\" the Modified Version under precisely this License, with the Modified
-\" Version filling the role of the Document, thus licensing distribution
-\" and modification of the Modified Version to whoever possesses a copy
-\" of it. In addition, you must do these things in the Modified Version:
-\" .PP
-\" A. Use in the Title Page (and on the covers, if any) a title distinct
-\" from that of the Document, and from those of previous versions
-\" (which should, if there were any, be listed in the History section
-\" of the Document). You may use the same title as a previous version
-\" if the original publisher of that version gives permission.
-\" .PP
-\" B. List on the Title Page, as authors, one or more persons or entities
-\" responsible for authorship of the modifications in the Modified
-\" Version, together with at least five of the principal authors of the
-\" Document (all of its principal authors, if it has less than five).
-\" .PP
-\" C. State on the Title page the name of the publisher of the
-\" Modified Version, as the publisher.
-\" .PP
-\" D. Preserve all the copyright notices of the Document.
-\" .PP
-\" E. Add an appropriate copyright notice for your modifications
-\" adjacent to the other copyright notices.
-\" .PP
-\" F. Include, immediately after the copyright notices, a license notice
-\" giving the public permission to use the Modified Version under the
-\" terms of this License, in the form shown in the Addendum below.
-\" Preserve in that license notice the full lists of Invariant Sections
-\" and required Cover Texts given in the Document's license notice.
-\" .PP
-\" H. Include an unaltered copy of this License.
-\" .PP
-\" I. Preserve the section entitled "History", and its title, and add to
-\" it an item stating at least the title, year, new authors, and
-\" publisher of the Modified Version as given on the Title Page. If
-\" there is no section entitled "History" in the Document, create one
-\" stating the title, year, authors, and publisher of the Document as
-\" given on its Title Page, then add an item describing the Modified
-\" Version as stated in the previous sentence.
-\" .PP
-\" J. Preserve the network location, if any, given in the Document for
-\" public access to a Transparent copy of the Document, and likewise
-\" the network locations given in the Document for previous versions
-\" it was based on. These may be placed in the "History" section.
-\" You may omit a network location for a work that was published at
-\" least four years before the Document itself, or if the original
-\" publisher of the version it refers to gives permission.
-\" .PP
-\" K. In any section entitled "Acknowledgements" or "Dedications",
-\" preserve the section's title, and preserve in the section all the
-\" substance and tone of each of the contributor acknowledgements
-\" and/or dedications given therein.
-\" .PP
-\" L. Preserve all the Invariant Sections of the Document,
-\" unaltered in their text and in their titles. Section numbers
-\" or the equivalent are not considered part of the section titles.
-\" .PP
-\" M. Delete any section entitled "Endorsements". Such a section
-\" may not be included in the Modified Version.
-\" .PP
-\" N. Do not retitle any existing section as "Endorsements"
-\" or to conflict in title with any Invariant Section.
-\" .PP
-\" If the Modified Version includes new front-matter sections or
-\" appendices that qualify as Secondary Sections and contain no material
-\" copied from the Document, you may at your option designate some or all
-\" of these sections as invariant. To do this, add their titles to the
-\" list of Invariant Sections in the Modified Version's license notice.
-\" These titles must be distinct from any other section titles.
-\" .PP
-\" You may add a section entitled "Endorsements", provided it contains
-\" nothing but endorsements of your Modified Version by various
-\" parties--for example, statements of peer review or that the text has
-\" been approved by an organization as the authoritative definition of a
-\" standard.
-\" .PP
-\" You may add a passage of up to five words as a Front-Cover Text, and a
-\" passage of up to 25 words as a Back-Cover Text, to the end of the list
-\" of Cover Texts in the Modified Version. Only one passage of
-\" Front-Cover Text and one of Back-Cover Text may be added by (or
-\" through arrangements made by) any one entity. If the Document already
-\" includes a cover text for the same cover, previously added by you or
-\" by arrangement made by the same entity you are acting on behalf of,
-\" you may not add another; but you may replace the old one, on explicit
-\" permission from the previous publisher that added the old one.
-\" .PP
-\" The author(s) and publisher(s) of the Document do not by this License
-\" give permission to use their names for publicity for or to assert or
-\" imply endorsement of any Modified Version.
-\" .PP
-
-\" 5. COMBINING DOCUMENTS
-\" .PP
-\" You may combine the Document with other documents released under this
-\" License, under the terms defined in section 4 above for modified
-\" versions, provided that you include in the combination all of the
-\" Invariant Sections of all of the original documents, unmodified, and
-\" list them all as Invariant Sections of your combined work in its
-\" license notice.
-\" .PP
-\" The combined work need only contain one copy of this License, and
-\" multiple identical Invariant Sections may be replaced with a single
-\" copy. If there are multiple Invariant Sections with the same name but
-\" different contents, make the title of each such section unique by
-\" adding at the end of it, in parentheses, the name of the original
-\" author or publisher of that section if known, or else a unique number.
-\" Make the same adjustment to the section titles in the list of
-\" Invariant Sections in the license notice of the combined work.
-\" .PP
-\" In the combination, you must combine any sections entitled "History"
-\" in the various original documents, forming one section entitled
-\" "History"; likewise combine any sections entitled "Acknowledgements",
-\" and any sections entitled "Dedications". You must delete all sections
-\" entitled "Endorsements."
-\" .PP
-
-\" 6. COLLECTIONS OF DOCUMENTS
-\" .PP
-\" You may make a collection consisting of the Document and other documents
-\" released under this License, and replace the individual copies of this
-\" License in the various documents with a single copy that is included in
-\" the collection, provided that you follow the rules of this License for
-\" verbatim copying of each of the documents in all other respects.
-\" .PP
-\" You may extract a single document from such a collection, and distribute
-\" it individually under this License, provided you insert a copy of this
-\" License into the extracted document, and follow this License in all
-\" other respects regarding verbatim copying of that document.
-\" .PP
-
-\" 7. AGGREGATION WITH INDEPENDENT WORKS
-\" .PP
-\" A compilation of the Document or its derivatives with other separate
-\" and independent documents or works, in or on a volume of a storage or
-\" distribution medium, does not as a whole count as a Modified Version
-\" of the Document, provided no compilation copyright is claimed for the
-\" compilation. Such a compilation is called an "aggregate", and this
-\" License does not apply to the other self-contained works thus compiled
-\" with the Document, on account of their being thus compiled, if they
-\" are not themselves derivative works of the Document.
-\" .PP
-\" If the Cover Text requirement of section 3 is applicable to these
-\" copies of the Document, then if the Document is less than one quarter
-\" of the entire aggregate, the Document's Cover Texts may be placed on
-\" covers that surround only the Document within the aggregate.
-\" Otherwise they must appear on covers around the whole aggregate.
-\" .PP
-
-\" 8. TRANSLATION
-\" .PP
-\" Translation is considered a kind of modification, so you may
-\" distribute translations of the Document under the terms of section 4.
-\" Replacing Invariant Sections with translations requires special
-\" permission from their copyright holders, but you may include
-\" translations of some or all Invariant Sections in addition to the
-\" original versions of these Invariant Sections. You may include a
-\" translation of this License provided that you also include the
-\" original English version of this License. In case of a disagreement
-\" between the translation and the original English version of this
-\" License, the original English version will prevail.
-\" .PP
-
-\" 9. TERMINATION
-\" .PP
-\" You may not copy, modify, sublicense, or distribute the Document except
-\" as expressly provided for under this License. Any other attempt to
-\" copy, modify, sublicense or distribute the Document is void, and will
-\" automatically terminate your rights under this License. However,
-\" parties who have received copies, or rights, from you under this
-\" License will not have their licenses terminated so long as such
-\" parties remain in full compliance.
-\" .PP
-
-\" 10. FUTURE REVISIONS OF THIS LICENSE
-\" .PP
-\" The Free Software Foundation may publish new, revised versions
-\" of the GNU Free Documentation License from time to time. Such new
-\" versions will be similar in spirit to the present version, but may
-\" differ in detail to address new problems or concerns. See
-\" http://www.gnu.org/copyleft/.
-\" .PP
-\" Each version of the License is given a distinguishing version number.
-\" If the Document specifies that a particular numbered version of this
-\" License "or any later version" applies to it, you have the option of
-\" following the terms and conditions either of that specified version or
-\" of any later version that has been published (not as a draft) by the
-\" Free Software Foundation. If the Document does not specify a version
-\" number of this License, you may choose any version ever published (not
-\" as a draft) by the Free Software Foundation.
-\" .PP
-
-\" ADDENDUM: How to use this License for your documents
-\" .PP
-\" To use this License in a document you have written, include a copy of
-\" the License in the document and put the following copyright and
-\" license notices just after the title page:
-\" .PP
-\" Copyright (c) YEAR YOUR NAME.
-\" Permission is granted to copy, distribute and/or
-\" modify this document under the terms of the GNU
-\" Free Documentation License, Version 1.1 or any later
-\" version published by the Free Software Foundation;
-\" with the Invariant Sections being LIST THEIR TITLES,
-\" with the Front-Cover Texts being LIST, and with the
-\" Back-Cover Texts being LIST. A copy of the license
-\" is included in the section entitled "GNU Free
-\" Documentation License".
-\" .PP
-\" If you have no Invariant Sections, write "with no Invariant Sections"
-\" instead of saying which ones are invariant. If you have no
-\" Front-Cover Texts, write "no Front-Cover Texts" instead of
-\" "Front-Cover Texts being LIST"; likewise for Back-Cover Texts.
-\" .PP
-\" If your document contains nontrivial examples of program code, we
-\" recommend releasing these examples in parallel under your choice of
-\" free software license, such as the GNU General Public License,
-\" to permit their use in free software.
diff --git a/share/man/man1/arm-eabi-size.1 b/share/man/man1/arm-eabi-size.1
deleted file mode 100644
index 5320b58..0000000
--- a/share/man/man1/arm-eabi-size.1
+++ /dev/null
@@ -1,268 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "SIZE 1"
-.TH SIZE 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-size \- list section sizes and total size.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-size [\fB\-A\fR|\fB\-B\fR|\fB\-\-format=\fR\fIcompatibility\fR]
- [\fB\-\-help\fR]
- [\fB\-d\fR|\fB\-o\fR|\fB\-x\fR|\fB\-\-radix=\fR\fInumber\fR]
- [\fB\-\-common\fR]
- [\fB\-t\fR|\fB\-\-totals\fR]
- [\fB\-\-target=\fR\fIbfdname\fR] [\fB\-V\fR|\fB\-\-version\fR]
- [\fIobjfile\fR...]
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-The \s-1GNU\s0 \fBsize\fR utility lists the section sizes\-\-\-and the total
-size\-\-\-for each of the object or archive files \fIobjfile\fR in its
-argument list. By default, one line of output is generated for each
-object file or each module in an archive.
-.PP
-\&\fIobjfile\fR... are the object files to be examined.
-If none are specified, the file \f(CW\*(C`a.out\*(C'\fR will be used.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-The command line options have the following meanings:
-.IP "\fB\-A\fR" 4
-.IX Item "-A"
-.PD 0
-.IP "\fB\-B\fR" 4
-.IX Item "-B"
-.IP "\fB\-\-format=\fR\fIcompatibility\fR" 4
-.IX Item "--format=compatibility"
-.PD
-Using one of these options, you can choose whether the output from \s-1GNU\s0
-\&\fBsize\fR resembles output from System V \fBsize\fR (using \fB\-A\fR,
-or \fB\-\-format=sysv\fR), or Berkeley \fBsize\fR (using \fB\-B\fR, or
-\&\fB\-\-format=berkeley\fR). The default is the one-line format similar to
-Berkeley's.
-.Sp
-Here is an example of the Berkeley (default) format of output from
-\&\fBsize\fR:
-.Sp
-.Vb 4
-\& $ size \-\-format=Berkeley ranlib size
-\& text data bss dec hex filename
-\& 294880 81920 11592 388392 5ed28 ranlib
-\& 294880 81920 11888 388688 5ee50 size
-.Ve
-.Sp
-This is the same data, but displayed closer to System V conventions:
-.Sp
-.Vb 7
-\& $ size \-\-format=SysV ranlib size
-\& ranlib :
-\& section size addr
-\& .text 294880 8192
-\& .data 81920 303104
-\& .bss 11592 385024
-\& Total 388392
-\&
-\&
-\& size :
-\& section size addr
-\& .text 294880 8192
-\& .data 81920 303104
-\& .bss 11888 385024
-\& Total 388688
-.Ve
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-Show a summary of acceptable arguments and options.
-.IP "\fB\-d\fR" 4
-.IX Item "-d"
-.PD 0
-.IP "\fB\-o\fR" 4
-.IX Item "-o"
-.IP "\fB\-x\fR" 4
-.IX Item "-x"
-.IP "\fB\-\-radix=\fR\fInumber\fR" 4
-.IX Item "--radix=number"
-.PD
-Using one of these options, you can control whether the size of each
-section is given in decimal (\fB\-d\fR, or \fB\-\-radix=10\fR); octal
-(\fB\-o\fR, or \fB\-\-radix=8\fR); or hexadecimal (\fB\-x\fR, or
-\&\fB\-\-radix=16\fR). In \fB\-\-radix=\fR\fInumber\fR, only the three
-values (8, 10, 16) are supported. The total size is always given in two
-radices; decimal and hexadecimal for \fB\-d\fR or \fB\-x\fR output, or
-octal and hexadecimal if you're using \fB\-o\fR.
-.IP "\fB\-\-common\fR" 4
-.IX Item "--common"
-Print total size of common symbols in each file. When using Berkeley
-format these are included in the bss size.
-.IP "\fB\-t\fR" 4
-.IX Item "-t"
-.PD 0
-.IP "\fB\-\-totals\fR" 4
-.IX Item "--totals"
-.PD
-Show totals of all objects listed (Berkeley format listing mode only).
-.IP "\fB\-\-target=\fR\fIbfdname\fR" 4
-.IX Item "--target=bfdname"
-Specify that the object-code format for \fIobjfile\fR is
-\&\fIbfdname\fR. This option may not be necessary; \fBsize\fR can
-automatically recognize many formats.
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Display the version number of \fBsize\fR.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIar\fR\|(1), \fIobjdump\fR\|(1), \fIreadelf\fR\|(1), and the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-strings.1 b/share/man/man1/arm-eabi-strings.1
deleted file mode 100644
index 02aff53..0000000
--- a/share/man/man1/arm-eabi-strings.1
+++ /dev/null
@@ -1,257 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "STRINGS 1"
-.TH STRINGS 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-strings \- print the strings of printable characters in files.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-strings [\fB\-afovV\fR] [\fB\-\fR\fImin-len\fR]
- [\fB\-n\fR \fImin-len\fR] [\fB\-\-bytes=\fR\fImin-len\fR]
- [\fB\-t\fR \fIradix\fR] [\fB\-\-radix=\fR\fIradix\fR]
- [\fB\-e\fR \fIencoding\fR] [\fB\-\-encoding=\fR\fIencoding\fR]
- [\fB\-\fR] [\fB\-\-all\fR] [\fB\-\-print\-file\-name\fR]
- [\fB\-T\fR \fIbfdname\fR] [\fB\-\-target=\fR\fIbfdname\fR]
- [\fB\-\-help\fR] [\fB\-\-version\fR] \fIfile\fR...
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-For each \fIfile\fR given, \s-1GNU\s0 \fBstrings\fR prints the printable
-character sequences that are at least 4 characters long (or the number
-given with the options below) and are followed by an unprintable
-character. By default, it only prints the strings from the initialized
-and loaded sections of object files; for other types of files, it prints
-the strings from the whole file.
-.PP
-\&\fBstrings\fR is mainly useful for determining the contents of non-text
-files.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.IP "\fB\-a\fR" 4
-.IX Item "-a"
-.PD 0
-.IP "\fB\-\-all\fR" 4
-.IX Item "--all"
-.IP "\fB\-\fR" 4
-.IX Item "-"
-.PD
-Do not scan only the initialized and loaded sections of object files;
-scan the whole files.
-.IP "\fB\-f\fR" 4
-.IX Item "-f"
-.PD 0
-.IP "\fB\-\-print\-file\-name\fR" 4
-.IX Item "--print-file-name"
-.PD
-Print the name of the file before each string.
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-Print a summary of the program usage on the standard output and exit.
-.IP "\fB\-\fR\fImin-len\fR" 4
-.IX Item "-min-len"
-.PD 0
-.IP "\fB\-n\fR \fImin-len\fR" 4
-.IX Item "-n min-len"
-.IP "\fB\-\-bytes=\fR\fImin-len\fR" 4
-.IX Item "--bytes=min-len"
-.PD
-Print sequences of characters that are at least \fImin-len\fR characters
-long, instead of the default 4.
-.IP "\fB\-o\fR" 4
-.IX Item "-o"
-Like \fB\-t o\fR. Some other versions of \fBstrings\fR have \fB\-o\fR
-act like \fB\-t d\fR instead. Since we can not be compatible with both
-ways, we simply chose one.
-.IP "\fB\-t\fR \fIradix\fR" 4
-.IX Item "-t radix"
-.PD 0
-.IP "\fB\-\-radix=\fR\fIradix\fR" 4
-.IX Item "--radix=radix"
-.PD
-Print the offset within the file before each string. The single
-character argument specifies the radix of the offset\-\-\-\fBo\fR for
-octal, \fBx\fR for hexadecimal, or \fBd\fR for decimal.
-.IP "\fB\-e\fR \fIencoding\fR" 4
-.IX Item "-e encoding"
-.PD 0
-.IP "\fB\-\-encoding=\fR\fIencoding\fR" 4
-.IX Item "--encoding=encoding"
-.PD
-Select the character encoding of the strings that are to be found.
-Possible values for \fIencoding\fR are: \fBs\fR = single\-7\-bit\-byte
-characters (\s-1ASCII\s0, \s-1ISO\s0 8859, etc., default), \fBS\fR =
-single\-8\-bit\-byte characters, \fBb\fR = 16\-bit bigendian, \fBl\fR =
-16\-bit littleendian, \fBB\fR = 32\-bit bigendian, \fBL\fR = 32\-bit
-littleendian. Useful for finding wide character strings. (\fBl\fR
-and \fBb\fR apply to, for example, Unicode \s-1UTF\-16/UCS\-2\s0 encodings).
-.IP "\fB\-T\fR \fIbfdname\fR" 4
-.IX Item "-T bfdname"
-.PD 0
-.IP "\fB\-\-target=\fR\fIbfdname\fR" 4
-.IX Item "--target=bfdname"
-.PD
-Specify an object code format other than your system's default format.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Print the program version number on the standard output and exit.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIar\fR\|(1), \fInm\fR\|(1), \fIobjdump\fR\|(1), \fIranlib\fR\|(1), \fIreadelf\fR\|(1)
-and the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-strip.1 b/share/man/man1/arm-eabi-strip.1
deleted file mode 100644
index bc66900..0000000
--- a/share/man/man1/arm-eabi-strip.1
+++ /dev/null
@@ -1,392 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "STRIP 1"
-.TH STRIP 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-strip \- Discard symbols from object files.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-strip [\fB\-F\fR \fIbfdname\fR |\fB\-\-target=\fR\fIbfdname\fR]
- [\fB\-I\fR \fIbfdname\fR |\fB\-\-input\-target=\fR\fIbfdname\fR]
- [\fB\-O\fR \fIbfdname\fR |\fB\-\-output\-target=\fR\fIbfdname\fR]
- [\fB\-s\fR|\fB\-\-strip\-all\fR]
- [\fB\-S\fR|\fB\-g\fR|\fB\-d\fR|\fB\-\-strip\-debug\fR]
- [\fB\-K\fR \fIsymbolname\fR |\fB\-\-keep\-symbol=\fR\fIsymbolname\fR]
- [\fB\-N\fR \fIsymbolname\fR |\fB\-\-strip\-symbol=\fR\fIsymbolname\fR]
- [\fB\-w\fR|\fB\-\-wildcard\fR]
- [\fB\-x\fR|\fB\-\-discard\-all\fR] [\fB\-X\fR |\fB\-\-discard\-locals\fR]
- [\fB\-R\fR \fIsectionname\fR |\fB\-\-remove\-section=\fR\fIsectionname\fR]
- [\fB\-o\fR \fIfile\fR] [\fB\-p\fR|\fB\-\-preserve\-dates\fR]
- [\fB\-\-keep\-file\-symbols\fR]
- [\fB\-\-only\-keep\-debug\fR]
- [\fB\-v\fR |\fB\-\-verbose\fR] [\fB\-V\fR|\fB\-\-version\fR]
- [\fB\-\-help\fR] [\fB\-\-info\fR]
- \fIobjfile\fR...
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\s-1GNU\s0 \fBstrip\fR discards all symbols from object files
-\&\fIobjfile\fR. The list of object files may include archives.
-At least one object file must be given.
-.PP
-\&\fBstrip\fR modifies the files named in its argument,
-rather than writing modified copies under different names.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.IP "\fB\-F\fR \fIbfdname\fR" 4
-.IX Item "-F bfdname"
-.PD 0
-.IP "\fB\-\-target=\fR\fIbfdname\fR" 4
-.IX Item "--target=bfdname"
-.PD
-Treat the original \fIobjfile\fR as a file with the object
-code format \fIbfdname\fR, and rewrite it in the same format.
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-Show a summary of the options to \fBstrip\fR and exit.
-.IP "\fB\-\-info\fR" 4
-.IX Item "--info"
-Display a list showing all architectures and object formats available.
-.IP "\fB\-I\fR \fIbfdname\fR" 4
-.IX Item "-I bfdname"
-.PD 0
-.IP "\fB\-\-input\-target=\fR\fIbfdname\fR" 4
-.IX Item "--input-target=bfdname"
-.PD
-Treat the original \fIobjfile\fR as a file with the object
-code format \fIbfdname\fR.
-.IP "\fB\-O\fR \fIbfdname\fR" 4
-.IX Item "-O bfdname"
-.PD 0
-.IP "\fB\-\-output\-target=\fR\fIbfdname\fR" 4
-.IX Item "--output-target=bfdname"
-.PD
-Replace \fIobjfile\fR with a file in the output format \fIbfdname\fR.
-.IP "\fB\-R\fR \fIsectionname\fR" 4
-.IX Item "-R sectionname"
-.PD 0
-.IP "\fB\-\-remove\-section=\fR\fIsectionname\fR" 4
-.IX Item "--remove-section=sectionname"
-.PD
-Remove any section named \fIsectionname\fR from the output file. This
-option may be given more than once. Note that using this option
-inappropriately may make the output file unusable.
-.IP "\fB\-s\fR" 4
-.IX Item "-s"
-.PD 0
-.IP "\fB\-\-strip\-all\fR" 4
-.IX Item "--strip-all"
-.PD
-Remove all symbols.
-.IP "\fB\-g\fR" 4
-.IX Item "-g"
-.PD 0
-.IP "\fB\-S\fR" 4
-.IX Item "-S"
-.IP "\fB\-d\fR" 4
-.IX Item "-d"
-.IP "\fB\-\-strip\-debug\fR" 4
-.IX Item "--strip-debug"
-.PD
-Remove debugging symbols only.
-.IP "\fB\-\-strip\-unneeded\fR" 4
-.IX Item "--strip-unneeded"
-Remove all symbols that are not needed for relocation processing.
-.IP "\fB\-K\fR \fIsymbolname\fR" 4
-.IX Item "-K symbolname"
-.PD 0
-.IP "\fB\-\-keep\-symbol=\fR\fIsymbolname\fR" 4
-.IX Item "--keep-symbol=symbolname"
-.PD
-When stripping symbols, keep symbol \fIsymbolname\fR even if it would
-normally be stripped. This option may be given more than once.
-.IP "\fB\-N\fR \fIsymbolname\fR" 4
-.IX Item "-N symbolname"
-.PD 0
-.IP "\fB\-\-strip\-symbol=\fR\fIsymbolname\fR" 4
-.IX Item "--strip-symbol=symbolname"
-.PD
-Remove symbol \fIsymbolname\fR from the source file. This option may be
-given more than once, and may be combined with strip options other than
-\&\fB\-K\fR.
-.IP "\fB\-o\fR \fIfile\fR" 4
-.IX Item "-o file"
-Put the stripped output in \fIfile\fR, rather than replacing the
-existing file. When this argument is used, only one \fIobjfile\fR
-argument may be specified.
-.IP "\fB\-p\fR" 4
-.IX Item "-p"
-.PD 0
-.IP "\fB\-\-preserve\-dates\fR" 4
-.IX Item "--preserve-dates"
-.PD
-Preserve the access and modification dates of the file.
-.IP "\fB\-w\fR" 4
-.IX Item "-w"
-.PD 0
-.IP "\fB\-\-wildcard\fR" 4
-.IX Item "--wildcard"
-.PD
-Permit regular expressions in \fIsymbolname\fRs used in other command
-line options. The question mark (?), asterisk (*), backslash (\e) and
-square brackets ([]) operators can be used anywhere in the symbol
-name. If the first character of the symbol name is the exclamation
-point (!) then the sense of the switch is reversed for that symbol.
-For example:
-.Sp
-.Vb 1
-\& \-w \-K !foo \-K fo*
-.Ve
-.Sp
-would cause strip to only keep symbols that start with the letters
-\&\*(L"fo\*(R", but to discard the symbol \*(L"foo\*(R".
-.IP "\fB\-x\fR" 4
-.IX Item "-x"
-.PD 0
-.IP "\fB\-\-discard\-all\fR" 4
-.IX Item "--discard-all"
-.PD
-Remove non-global symbols.
-.IP "\fB\-X\fR" 4
-.IX Item "-X"
-.PD 0
-.IP "\fB\-\-discard\-locals\fR" 4
-.IX Item "--discard-locals"
-.PD
-Remove compiler-generated local symbols.
-(These usually start with \fBL\fR or \fB.\fR.)
-.IP "\fB\-\-keep\-file\-symbols\fR" 4
-.IX Item "--keep-file-symbols"
-When stripping a file, perhaps with \fB\-\-strip\-debug\fR or
-\&\fB\-\-strip\-unneeded\fR, retain any symbols specifying source file names,
-which would otherwise get stripped.
-.IP "\fB\-\-only\-keep\-debug\fR" 4
-.IX Item "--only-keep-debug"
-Strip a file, removing contents of any sections that would not be
-stripped by \fB\-\-strip\-debug\fR and leaving the debugging sections
-intact. In \s-1ELF\s0 files, this preserves all note sections in the output.
-.Sp
-The intention is that this option will be used in conjunction with
-\&\fB\-\-add\-gnu\-debuglink\fR to create a two part executable. One a
-stripped binary which will occupy less space in \s-1RAM\s0 and in a
-distribution and the second a debugging information file which is only
-needed if debugging abilities are required. The suggested procedure
-to create these files is as follows:
-.RS 4
-.IP "1.<Link the executable as normal. Assuming that is is called>" 4
-.IX Item "1.<Link the executable as normal. Assuming that is is called>"
-\&\f(CW\*(C`foo\*(C'\fR then...
-.ie n .IP "1.<Run ""objcopy \-\-only\-keep\-debug foo foo.dbg"" to>" 4
-.el .IP "1.<Run \f(CWobjcopy \-\-only\-keep\-debug foo foo.dbg\fR to>" 4
-.IX Item "1.<Run objcopy --only-keep-debug foo foo.dbg to>"
-create a file containing the debugging info.
-.ie n .IP "1.<Run ""objcopy \-\-strip\-debug foo"" to create a>" 4
-.el .IP "1.<Run \f(CWobjcopy \-\-strip\-debug foo\fR to create a>" 4
-.IX Item "1.<Run objcopy --strip-debug foo to create a>"
-stripped executable.
-.ie n .IP "1.<Run ""objcopy \-\-add\-gnu\-debuglink=foo.dbg foo"">" 4
-.el .IP "1.<Run \f(CWobjcopy \-\-add\-gnu\-debuglink=foo.dbg foo\fR>" 4
-.IX Item "1.<Run objcopy --add-gnu-debuglink=foo.dbg foo>"
-to add a link to the debugging info into the stripped executable.
-.RE
-.RS 4
-.Sp
-Note\-\-\-the choice of \f(CW\*(C`.dbg\*(C'\fR as an extension for the debug info
-file is arbitrary. Also the \f(CW\*(C`\-\-only\-keep\-debug\*(C'\fR step is
-optional. You could instead do this:
-.IP "1.<Link the executable as normal.>" 4
-.IX Item "1.<Link the executable as normal.>"
-.PD 0
-.ie n .IP "1.<Copy ""foo"" to ""foo.full"">" 4
-.el .IP "1.<Copy \f(CWfoo\fR to \f(CWfoo.full\fR>" 4
-.IX Item "1.<Copy foo to foo.full>"
-.ie n .IP "1.<Run ""strip \-\-strip\-debug foo"">" 4
-.el .IP "1.<Run \f(CWstrip \-\-strip\-debug foo\fR>" 4
-.IX Item "1.<Run strip --strip-debug foo>"
-.ie n .IP "1.<Run ""objcopy \-\-add\-gnu\-debuglink=foo.full foo"">" 4
-.el .IP "1.<Run \f(CWobjcopy \-\-add\-gnu\-debuglink=foo.full foo\fR>" 4
-.IX Item "1.<Run objcopy --add-gnu-debuglink=foo.full foo>"
-.RE
-.RS 4
-.PD
-.Sp
-i.e., the file pointed to by the \fB\-\-add\-gnu\-debuglink\fR can be the
-full executable. It does not have to be a file created by the
-\&\fB\-\-only\-keep\-debug\fR switch.
-.Sp
-Note\-\-\-this switch is only intended for use on fully linked files. It
-does not make sense to use it on object files where the debugging
-information may be incomplete. Besides the gnu_debuglink feature
-currently only supports the presence of one filename containing
-debugging information, not multiple filenames on a one-per-object-file
-basis.
-.RE
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Show the version number for \fBstrip\fR.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.IP "\fB\-\-verbose\fR" 4
-.IX Item "--verbose"
-.PD
-Verbose output: list all object files modified. In the case of
-archives, \fBstrip \-v\fR lists all members of the archive.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-windmc.1 b/share/man/man1/arm-eabi-windmc.1
deleted file mode 100644
index 8449e40..0000000
--- a/share/man/man1/arm-eabi-windmc.1
+++ /dev/null
@@ -1,353 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "WINDMC 1"
-.TH WINDMC 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-windmc \- generates Windows message resources.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-windmc [options] input-file
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\fBwindmc\fR reads message definitions from an input file (.mc) and
-translate them into a set of output files. The output files may be of
-four kinds:
-.ie n .IP """h""" 4
-.el .IP "\f(CWh\fR" 4
-.IX Item "h"
-A C header file containing the message definitions.
-.ie n .IP """rc""" 4
-.el .IP "\f(CWrc\fR" 4
-.IX Item "rc"
-A resource file compilable by the \fBwindres\fR tool.
-.ie n .IP """bin""" 4
-.el .IP "\f(CWbin\fR" 4
-.IX Item "bin"
-One or more binary files containing the resource data for a specific
-message language.
-.ie n .IP """dbg""" 4
-.el .IP "\f(CWdbg\fR" 4
-.IX Item "dbg"
-A C include file that maps message id's to their symbolic name.
-.PP
-The exact description of these different formats is available in
-documentation from Microsoft.
-.PP
-When \fBwindmc\fR converts from the \f(CW\*(C`mc\*(C'\fR format to the \f(CW\*(C`bin\*(C'\fR
-format, \f(CW\*(C`rc\*(C'\fR, \f(CW\*(C`h\*(C'\fR, and optional \f(CW\*(C`dbg\*(C'\fR it is acting like the
-Windows Message Compiler.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.IP "\fB\-a\fR" 4
-.IX Item "-a"
-.PD 0
-.IP "\fB\-\-ascii_in\fR" 4
-.IX Item "--ascii_in"
-.PD
-Specifies that the input file specified is \s-1ASCII\s0. This is the default
-behaviour.
-.IP "\fB\-A\fR" 4
-.IX Item "-A"
-.PD 0
-.IP "\fB\-\-ascii_out\fR" 4
-.IX Item "--ascii_out"
-.PD
-Specifies that messages in the output \f(CW\*(C`bin\*(C'\fR files should be in \s-1ASCII\s0
-format.
-.IP "\fB\-b\fR" 4
-.IX Item "-b"
-.PD 0
-.IP "\fB\-\-binprefix\fR" 4
-.IX Item "--binprefix"
-.PD
-Specifies that \f(CW\*(C`bin\*(C'\fR filenames should have to be prefixed by the
-basename of the source file.
-.IP "\fB\-c\fR" 4
-.IX Item "-c"
-.PD 0
-.IP "\fB\-\-customflag\fR" 4
-.IX Item "--customflag"
-.PD
-Sets the customer bit in all message id's.
-.IP "\fB\-C\fR \fIcodepage\fR" 4
-.IX Item "-C codepage"
-.PD 0
-.IP "\fB\-\-codepage_in\fR \fIcodepage\fR" 4
-.IX Item "--codepage_in codepage"
-.PD
-Sets the default codepage to be used to convert input file to \s-1UTF16\s0. The
-default is ocdepage 1252.
-.IP "\fB\-d\fR" 4
-.IX Item "-d"
-.PD 0
-.IP "\fB\-\-decimal_values\fR" 4
-.IX Item "--decimal_values"
-.PD
-Outputs the constants in the header file in decimal. Default is using
-hexadecimal output.
-.IP "\fB\-e\fR \fIext\fR" 4
-.IX Item "-e ext"
-.PD 0
-.IP "\fB\-\-extension\fR \fIext\fR" 4
-.IX Item "--extension ext"
-.PD
-The extension for the header file. The default is .h extension.
-.IP "\fB\-F\fR \fItarget\fR" 4
-.IX Item "-F target"
-.PD 0
-.IP "\fB\-\-target\fR \fItarget\fR" 4
-.IX Item "--target target"
-.PD
-Specify the \s-1BFD\s0 format to use for a bin file as output. This
-is a \s-1BFD\s0 target name; you can use the \fB\-\-help\fR option to see a list
-of supported targets. Normally \fBwindmc\fR will use the default
-format, which is the first one listed by the \fB\-\-help\fR option.
-.IP "\fB\-h\fR \fIpath\fR" 4
-.IX Item "-h path"
-.PD 0
-.IP "\fB\-\-headerdir\fR \fIpath\fR" 4
-.IX Item "--headerdir path"
-.PD
-The target directory of the generated header file. The default is the
-current directory.
-.IP "\fB\-H\fR" 4
-.IX Item "-H"
-.PD 0
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-.PD
-Displays a list of command line options and then exits.
-.IP "\fB\-m\fR \fIcharacters\fR" 4
-.IX Item "-m characters"
-.PD 0
-.IP "\fB\-\-maxlength\fR \fIcharacters\fR" 4
-.IX Item "--maxlength characters"
-.PD
-Instructs \fBwindmc\fR to generate a warning if the length
-of any message exceeds the number specified.
-.IP "\fB\-n\fR" 4
-.IX Item "-n"
-.PD 0
-.IP "\fB\-\-nullterminate\fR" 4
-.IX Item "--nullterminate"
-.PD
-Terminate message text in \f(CW\*(C`bin\*(C'\fR files by zero. By default they are
-terminated by \s-1CR/LF\s0.
-.IP "\fB\-o\fR" 4
-.IX Item "-o"
-.PD 0
-.IP "\fB\-\-hresult_use\fR" 4
-.IX Item "--hresult_use"
-.PD
-Not yet implemented. Instructs \f(CW\*(C`windmc\*(C'\fR to generate an \s-1OLE2\s0 header
-file, using \s-1HRESULT\s0 definitions. Status codes are used if the flag is not
-specified.
-.IP "\fB\-O\fR \fIcodepage\fR" 4
-.IX Item "-O codepage"
-.PD 0
-.IP "\fB\-\-codepage_out\fR \fIcodepage\fR" 4
-.IX Item "--codepage_out codepage"
-.PD
-Sets the default codepage to be used to output text files. The default
-is ocdepage 1252.
-.IP "\fB\-r\fR \fIpath\fR" 4
-.IX Item "-r path"
-.PD 0
-.IP "\fB\-\-rcdir\fR \fIpath\fR" 4
-.IX Item "--rcdir path"
-.PD
-The target directory for the generated \f(CW\*(C`rc\*(C'\fR script and the generated
-\&\f(CW\*(C`bin\*(C'\fR files that the resource compiler script includes. The default
-is the current directory.
-.IP "\fB\-u\fR" 4
-.IX Item "-u"
-.PD 0
-.IP "\fB\-\-unicode_in\fR" 4
-.IX Item "--unicode_in"
-.PD
-Specifies that the input file is \s-1UTF16\s0.
-.IP "\fB\-U\fR" 4
-.IX Item "-U"
-.PD 0
-.IP "\fB\-\-unicode_out\fR" 4
-.IX Item "--unicode_out"
-.PD
-Specifies that messages in the output \f(CW\*(C`bin\*(C'\fR file should be in \s-1UTF16\s0
-format. This is the default behaviour.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-.PD 0
-.IP "\fB\-\-verbose\fR" 4
-.IX Item "--verbose"
-.PD
-Enable verbose mode.
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Prints the version number for \fBwindmc\fR.
-.IP "\fB\-x\fR \fIpath\fR" 4
-.IX Item "-x path"
-.PD 0
-.IP "\fB\-\-xdgb\fR \fIpath\fR" 4
-.IX Item "--xdgb path"
-.PD
-The path of the \f(CW\*(C`dbg\*(C'\fR C include file that maps message id's to the
-symbolic name. No such file is generated without specifying the switch.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man1/arm-eabi-windres.1 b/share/man/man1/arm-eabi-windres.1
deleted file mode 100644
index 53fe7cc..0000000
--- a/share/man/man1/arm-eabi-windres.1
+++ /dev/null
@@ -1,354 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "WINDRES 1"
-.TH WINDRES 1 " " "binutils-2.21" "GNU Development Tools"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-windres \- manipulate Windows resources.
-.SH "SYNOPSIS"
-.IX Header "SYNOPSIS"
-windres [options] [input\-file] [output\-file]
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-\&\fBwindres\fR reads resources from an input file and copies them into
-an output file. Either file may be in one of three formats:
-.ie n .IP """rc""" 4
-.el .IP "\f(CWrc\fR" 4
-.IX Item "rc"
-A text format read by the Resource Compiler.
-.ie n .IP """res""" 4
-.el .IP "\f(CWres\fR" 4
-.IX Item "res"
-A binary format generated by the Resource Compiler.
-.ie n .IP """coff""" 4
-.el .IP "\f(CWcoff\fR" 4
-.IX Item "coff"
-A \s-1COFF\s0 object or executable.
-.PP
-The exact description of these different formats is available in
-documentation from Microsoft.
-.PP
-When \fBwindres\fR converts from the \f(CW\*(C`rc\*(C'\fR format to the \f(CW\*(C`res\*(C'\fR
-format, it is acting like the Windows Resource Compiler. When
-\&\fBwindres\fR converts from the \f(CW\*(C`res\*(C'\fR format to the \f(CW\*(C`coff\*(C'\fR
-format, it is acting like the Windows \f(CW\*(C`CVTRES\*(C'\fR program.
-.PP
-When \fBwindres\fR generates an \f(CW\*(C`rc\*(C'\fR file, the output is similar
-but not identical to the format expected for the input. When an input
-\&\f(CW\*(C`rc\*(C'\fR file refers to an external filename, an output \f(CW\*(C`rc\*(C'\fR file
-will instead include the file contents.
-.PP
-If the input or output format is not specified, \fBwindres\fR will
-guess based on the file name, or, for the input file, the file contents.
-A file with an extension of \fI.rc\fR will be treated as an \f(CW\*(C`rc\*(C'\fR
-file, a file with an extension of \fI.res\fR will be treated as a
-\&\f(CW\*(C`res\*(C'\fR file, and a file with an extension of \fI.o\fR or
-\&\fI.exe\fR will be treated as a \f(CW\*(C`coff\*(C'\fR file.
-.PP
-If no output file is specified, \fBwindres\fR will print the resources
-in \f(CW\*(C`rc\*(C'\fR format to standard output.
-.PP
-The normal use is for you to write an \f(CW\*(C`rc\*(C'\fR file, use \fBwindres\fR
-to convert it to a \s-1COFF\s0 object file, and then link the \s-1COFF\s0 file into
-your application. This will make the resources described in the
-\&\f(CW\*(C`rc\*(C'\fR file available to Windows.
-.SH "OPTIONS"
-.IX Header "OPTIONS"
-.IP "\fB\-i\fR \fIfilename\fR" 4
-.IX Item "-i filename"
-.PD 0
-.IP "\fB\-\-input\fR \fIfilename\fR" 4
-.IX Item "--input filename"
-.PD
-The name of the input file. If this option is not used, then
-\&\fBwindres\fR will use the first non-option argument as the input file
-name. If there are no non-option arguments, then \fBwindres\fR will
-read from standard input. \fBwindres\fR can not read a \s-1COFF\s0 file from
-standard input.
-.IP "\fB\-o\fR \fIfilename\fR" 4
-.IX Item "-o filename"
-.PD 0
-.IP "\fB\-\-output\fR \fIfilename\fR" 4
-.IX Item "--output filename"
-.PD
-The name of the output file. If this option is not used, then
-\&\fBwindres\fR will use the first non-option argument, after any used
-for the input file name, as the output file name. If there is no
-non-option argument, then \fBwindres\fR will write to standard output.
-\&\fBwindres\fR can not write a \s-1COFF\s0 file to standard output. Note,
-for compatibility with \fBrc\fR the option \fB\-fo\fR is also
-accepted, but its use is not recommended.
-.IP "\fB\-J\fR \fIformat\fR" 4
-.IX Item "-J format"
-.PD 0
-.IP "\fB\-\-input\-format\fR \fIformat\fR" 4
-.IX Item "--input-format format"
-.PD
-The input format to read. \fIformat\fR may be \fBres\fR, \fBrc\fR, or
-\&\fBcoff\fR. If no input format is specified, \fBwindres\fR will
-guess, as described above.
-.IP "\fB\-O\fR \fIformat\fR" 4
-.IX Item "-O format"
-.PD 0
-.IP "\fB\-\-output\-format\fR \fIformat\fR" 4
-.IX Item "--output-format format"
-.PD
-The output format to generate. \fIformat\fR may be \fBres\fR,
-\&\fBrc\fR, or \fBcoff\fR. If no output format is specified,
-\&\fBwindres\fR will guess, as described above.
-.IP "\fB\-F\fR \fItarget\fR" 4
-.IX Item "-F target"
-.PD 0
-.IP "\fB\-\-target\fR \fItarget\fR" 4
-.IX Item "--target target"
-.PD
-Specify the \s-1BFD\s0 format to use for a \s-1COFF\s0 file as input or output. This
-is a \s-1BFD\s0 target name; you can use the \fB\-\-help\fR option to see a list
-of supported targets. Normally \fBwindres\fR will use the default
-format, which is the first one listed by the \fB\-\-help\fR option.
-.IP "\fB\-\-preprocessor\fR \fIprogram\fR" 4
-.IX Item "--preprocessor program"
-When \fBwindres\fR reads an \f(CW\*(C`rc\*(C'\fR file, it runs it through the C
-preprocessor first. This option may be used to specify the preprocessor
-to use, including any leading arguments. The default preprocessor
-argument is \f(CW\*(C`gcc \-E \-xc\-header \-DRC_INVOKED\*(C'\fR.
-.IP "\fB\-I\fR \fIdirectory\fR" 4
-.IX Item "-I directory"
-.PD 0
-.IP "\fB\-\-include\-dir\fR \fIdirectory\fR" 4
-.IX Item "--include-dir directory"
-.PD
-Specify an include directory to use when reading an \f(CW\*(C`rc\*(C'\fR file.
-\&\fBwindres\fR will pass this to the preprocessor as an \fB\-I\fR
-option. \fBwindres\fR will also search this directory when looking for
-files named in the \f(CW\*(C`rc\*(C'\fR file. If the argument passed to this command
-matches any of the supported \fIformats\fR (as described in the \fB\-J\fR
-option), it will issue a deprecation warning, and behave just like the
-\&\fB\-J\fR option. New programs should not use this behaviour. If a
-directory happens to match a \fIformat\fR, simple prefix it with \fB./\fR
-to disable the backward compatibility.
-.IP "\fB\-D\fR \fItarget\fR" 4
-.IX Item "-D target"
-.PD 0
-.IP "\fB\-\-define\fR \fIsym\fR\fB[=\fR\fIval\fR\fB]\fR" 4
-.IX Item "--define sym[=val]"
-.PD
-Specify a \fB\-D\fR option to pass to the preprocessor when reading an
-\&\f(CW\*(C`rc\*(C'\fR file.
-.IP "\fB\-U\fR \fItarget\fR" 4
-.IX Item "-U target"
-.PD 0
-.IP "\fB\-\-undefine\fR \fIsym\fR" 4
-.IX Item "--undefine sym"
-.PD
-Specify a \fB\-U\fR option to pass to the preprocessor when reading an
-\&\f(CW\*(C`rc\*(C'\fR file.
-.IP "\fB\-r\fR" 4
-.IX Item "-r"
-Ignored for compatibility with rc.
-.IP "\fB\-v\fR" 4
-.IX Item "-v"
-Enable verbose mode. This tells you what the preprocessor is if you
-didn't specify one.
-.IP "\fB\-c\fR \fIval\fR" 4
-.IX Item "-c val"
-.PD 0
-.IP "\fB\-\-codepage\fR \fIval\fR" 4
-.IX Item "--codepage val"
-.PD
-Specify the default codepage to use when reading an \f(CW\*(C`rc\*(C'\fR file.
-\&\fIval\fR should be a hexadecimal prefixed by \fB0x\fR or decimal
-codepage code. The valid range is from zero up to 0xffff, but the
-validity of the codepage is host and configuration dependent.
-.IP "\fB\-l\fR \fIval\fR" 4
-.IX Item "-l val"
-.PD 0
-.IP "\fB\-\-language\fR \fIval\fR" 4
-.IX Item "--language val"
-.PD
-Specify the default language to use when reading an \f(CW\*(C`rc\*(C'\fR file.
-\&\fIval\fR should be a hexadecimal language code. The low eight bits are
-the language, and the high eight bits are the sublanguage.
-.IP "\fB\-\-use\-temp\-file\fR" 4
-.IX Item "--use-temp-file"
-Use a temporary file to instead of using popen to read the output of
-the preprocessor. Use this option if the popen implementation is buggy
-on the host (eg., certain non-English language versions of Windows 95 and
-Windows 98 are known to have buggy popen where the output will instead
-go the console).
-.IP "\fB\-\-no\-use\-temp\-file\fR" 4
-.IX Item "--no-use-temp-file"
-Use popen, not a temporary file, to read the output of the preprocessor.
-This is the default behaviour.
-.IP "\fB\-h\fR" 4
-.IX Item "-h"
-.PD 0
-.IP "\fB\-\-help\fR" 4
-.IX Item "--help"
-.PD
-Prints a usage summary.
-.IP "\fB\-V\fR" 4
-.IX Item "-V"
-.PD 0
-.IP "\fB\-\-version\fR" 4
-.IX Item "--version"
-.PD
-Prints the version number for \fBwindres\fR.
-.IP "\fB\-\-yydebug\fR" 4
-.IX Item "--yydebug"
-If \fBwindres\fR is compiled with \f(CW\*(C`YYDEBUG\*(C'\fR defined as \f(CW1\fR,
-this will turn on parser debugging.
-.IP "\fB@\fR\fIfile\fR" 4
-.IX Item "@file"
-Read command-line options from \fIfile\fR. The options read are
-inserted in place of the original @\fIfile\fR option. If \fIfile\fR
-does not exist, or cannot be read, then the option will be treated
-literally, and not removed.
-.Sp
-Options in \fIfile\fR are separated by whitespace. A whitespace
-character may be included in an option by surrounding the entire
-option in either single or double quotes. Any character (including a
-backslash) may be included by prefixing the character to be included
-with a backslash. The \fIfile\fR may itself contain additional
-@\fIfile\fR options; any such options will be processed recursively.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-the Info entries for \fIbinutils\fR.
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-Free Software Foundation, Inc.
-.PP
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, with no Front-Cover Texts, and with no
-Back-Cover Texts. A copy of the license is included in the
-section entitled \*(L"\s-1GNU\s0 Free Documentation License\*(R".
diff --git a/share/man/man7/fsf-funding.7 b/share/man/man7/fsf-funding.7
deleted file mode 100644
index d566678..0000000
--- a/share/man/man7/fsf-funding.7
+++ /dev/null
@@ -1,184 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "FSF-FUNDING 7"
-.TH FSF-FUNDING 7 "2012-01-06" "gcc-4.6.x-google" "GNU"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-fsf\-funding \- Funding Free Software
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-.SS "Funding Free Software"
-.IX Subsection "Funding Free Software"
-If you want to have more free software a few years from now, it makes
-sense for you to help encourage people to contribute funds for its
-development. The most effective approach known is to encourage
-commercial redistributors to donate.
-.PP
-Users of free software systems can boost the pace of development by
-encouraging for-a-fee distributors to donate part of their selling price
-to free software developers\-\-\-the Free Software Foundation, and others.
-.PP
-The way to convince distributors to do this is to demand it and expect
-it from them. So when you compare distributors, judge them partly by
-how much they give to free software development. Show distributors
-they must compete to be the one who gives the most.
-.PP
-To make this approach work, you must insist on numbers that you can
-compare, such as, \*(L"We will donate ten dollars to the Frobnitz project
-for each disk sold.\*(R" Don't be satisfied with a vague promise, such as
-\&\*(L"A portion of the profits are donated,\*(R" since it doesn't give a basis
-for comparison.
-.PP
-Even a precise fraction \*(L"of the profits from this disk\*(R" is not very
-meaningful, since creative accounting and unrelated business decisions
-can greatly alter what fraction of the sales price counts as profit.
-If the price you pay is \f(CW$50\fR, ten percent of the profit is probably
-less than a dollar; it might be a few cents, or nothing at all.
-.PP
-Some redistributors do development work themselves. This is useful too;
-but to keep everyone honest, you need to inquire how much they do, and
-what kind. Some kinds of development make much more long-term
-difference than others. For example, maintaining a separate version of
-a program contributes very little; maintaining the standard version of a
-program for the whole community contributes much. Easy new ports
-contribute little, since someone else would surely do them; difficult
-ports such as adding a new \s-1CPU\s0 to the \s-1GNU\s0 Compiler Collection contribute more;
-major new features or packages contribute the most.
-.PP
-By establishing the idea that supporting further development is \*(L"the
-proper thing to do\*(R" when distributing free software for a fee, we can
-assure a steady flow of resources into making more free software.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7).
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 1994 Free Software Foundation, Inc.
-Verbatim copying and redistribution of this section is permitted
-without royalty; alteration is not permitted.
diff --git a/share/man/man7/gfdl.7 b/share/man/man7/gfdl.7
deleted file mode 100644
index bb1f8fd..0000000
--- a/share/man/man7/gfdl.7
+++ /dev/null
@@ -1,637 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "GFDL 7"
-.TH GFDL 7 "2012-01-06" "gcc-4.6.x-google" "GNU"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-gfdl \- GNU Free Documentation License
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-.SS "\s-1GNU\s0 Free Documentation License"
-.IX Subsection "GNU Free Documentation License"
-.SS "Version 1.3, 3 November 2008"
-.IX Subsection "Version 1.3, 3 November 2008"
-.Vb 2
-\& Copyright (c) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
-\& E<lt>B<http://fsf.org/>E<gt>
-\&
-\& Everyone is permitted to copy and distribute verbatim copies
-\& of this license document, but changing it is not allowed.
-.Ve
-.IP "0." 4
-.IX Item "0."
-\&\s-1PREAMBLE\s0
-.Sp
-The purpose of this License is to make a manual, textbook, or other
-functional and useful document \fIfree\fR in the sense of freedom: to
-assure everyone the effective freedom to copy and redistribute it,
-with or without modifying it, either commercially or noncommercially.
-Secondarily, this License preserves for the author and publisher a way
-to get credit for their work, while not being considered responsible
-for modifications made by others.
-.Sp
-This License is a kind of \*(L"copyleft\*(R", which means that derivative
-works of the document must themselves be free in the same sense. It
-complements the \s-1GNU\s0 General Public License, which is a copyleft
-license designed for free software.
-.Sp
-We have designed this License in order to use it for manuals for free
-software, because free software needs free documentation: a free
-program should come with manuals providing the same freedoms that the
-software does. But this License is not limited to software manuals;
-it can be used for any textual work, regardless of subject matter or
-whether it is published as a printed book. We recommend this License
-principally for works whose purpose is instruction or reference.
-.IP "1." 4
-.IX Item "1."
-\&\s-1APPLICABILITY\s0 \s-1AND\s0 \s-1DEFINITIONS\s0
-.Sp
-This License applies to any manual or other work, in any medium, that
-contains a notice placed by the copyright holder saying it can be
-distributed under the terms of this License. Such a notice grants a
-world-wide, royalty-free license, unlimited in duration, to use that
-work under the conditions stated herein. The \*(L"Document\*(R", below,
-refers to any such manual or work. Any member of the public is a
-licensee, and is addressed as \*(L"you\*(R". You accept the license if you
-copy, modify or distribute the work in a way requiring permission
-under copyright law.
-.Sp
-A \*(L"Modified Version\*(R" of the Document means any work containing the
-Document or a portion of it, either copied verbatim, or with
-modifications and/or translated into another language.
-.Sp
-A \*(L"Secondary Section\*(R" is a named appendix or a front-matter section
-of the Document that deals exclusively with the relationship of the
-publishers or authors of the Document to the Document's overall
-subject (or to related matters) and contains nothing that could fall
-directly within that overall subject. (Thus, if the Document is in
-part a textbook of mathematics, a Secondary Section may not explain
-any mathematics.) The relationship could be a matter of historical
-connection with the subject or with related matters, or of legal,
-commercial, philosophical, ethical or political position regarding
-them.
-.Sp
-The \*(L"Invariant Sections\*(R" are certain Secondary Sections whose titles
-are designated, as being those of Invariant Sections, in the notice
-that says that the Document is released under this License. If a
-section does not fit the above definition of Secondary then it is not
-allowed to be designated as Invariant. The Document may contain zero
-Invariant Sections. If the Document does not identify any Invariant
-Sections then there are none.
-.Sp
-The \*(L"Cover Texts\*(R" are certain short passages of text that are listed,
-as Front-Cover Texts or Back-Cover Texts, in the notice that says that
-the Document is released under this License. A Front-Cover Text may
-be at most 5 words, and a Back-Cover Text may be at most 25 words.
-.Sp
-A \*(L"Transparent\*(R" copy of the Document means a machine-readable copy,
-represented in a format whose specification is available to the
-general public, that is suitable for revising the document
-straightforwardly with generic text editors or (for images composed of
-pixels) generic paint programs or (for drawings) some widely available
-drawing editor, and that is suitable for input to text formatters or
-for automatic translation to a variety of formats suitable for input
-to text formatters. A copy made in an otherwise Transparent file
-format whose markup, or absence of markup, has been arranged to thwart
-or discourage subsequent modification by readers is not Transparent.
-An image format is not Transparent if used for any substantial amount
-of text. A copy that is not \*(L"Transparent\*(R" is called \*(L"Opaque\*(R".
-.Sp
-Examples of suitable formats for Transparent copies include plain
-\&\s-1ASCII\s0 without markup, Texinfo input format, LaTeX input
-format, \s-1SGML\s0 or \s-1XML\s0 using a publicly available
-\&\s-1DTD\s0, and standard-conforming simple \s-1HTML\s0,
-PostScript or \s-1PDF\s0 designed for human modification. Examples
-of transparent image formats include \s-1PNG\s0, \s-1XCF\s0 and
-\&\s-1JPG\s0. Opaque formats include proprietary formats that can be
-read and edited only by proprietary word processors, \s-1SGML\s0 or
-\&\s-1XML\s0 for which the \s-1DTD\s0 and/or processing tools are
-not generally available, and the machine-generated \s-1HTML\s0,
-PostScript or \s-1PDF\s0 produced by some word processors for
-output purposes only.
-.Sp
-The \*(L"Title Page\*(R" means, for a printed book, the title page itself,
-plus such following pages as are needed to hold, legibly, the material
-this License requires to appear in the title page. For works in
-formats which do not have any title page as such, \*(L"Title Page\*(R" means
-the text near the most prominent appearance of the work's title,
-preceding the beginning of the body of the text.
-.Sp
-The \*(L"publisher\*(R" means any person or entity that distributes copies
-of the Document to the public.
-.Sp
-A section \*(L"Entitled \s-1XYZ\s0\*(R" means a named subunit of the Document whose
-title either is precisely \s-1XYZ\s0 or contains \s-1XYZ\s0 in parentheses following
-text that translates \s-1XYZ\s0 in another language. (Here \s-1XYZ\s0 stands for a
-specific section name mentioned below, such as \*(L"Acknowledgements\*(R",
-\&\*(L"Dedications\*(R", \*(L"Endorsements\*(R", or \*(L"History\*(R".) To \*(L"Preserve the Title\*(R"
-of such a section when you modify the Document means that it remains a
-section \*(L"Entitled \s-1XYZ\s0\*(R" according to this definition.
-.Sp
-The Document may include Warranty Disclaimers next to the notice which
-states that this License applies to the Document. These Warranty
-Disclaimers are considered to be included by reference in this
-License, but only as regards disclaiming warranties: any other
-implication that these Warranty Disclaimers may have is void and has
-no effect on the meaning of this License.
-.IP "2." 4
-.IX Item "2."
-\&\s-1VERBATIM\s0 \s-1COPYING\s0
-.Sp
-You may copy and distribute the Document in any medium, either
-commercially or noncommercially, provided that this License, the
-copyright notices, and the license notice saying this License applies
-to the Document are reproduced in all copies, and that you add no other
-conditions whatsoever to those of this License. You may not use
-technical measures to obstruct or control the reading or further
-copying of the copies you make or distribute. However, you may accept
-compensation in exchange for copies. If you distribute a large enough
-number of copies you must also follow the conditions in section 3.
-.Sp
-You may also lend copies, under the same conditions stated above, and
-you may publicly display copies.
-.IP "3." 4
-.IX Item "3."
-\&\s-1COPYING\s0 \s-1IN\s0 \s-1QUANTITY\s0
-.Sp
-If you publish printed copies (or copies in media that commonly have
-printed covers) of the Document, numbering more than 100, and the
-Document's license notice requires Cover Texts, you must enclose the
-copies in covers that carry, clearly and legibly, all these Cover
-Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
-the back cover. Both covers must also clearly and legibly identify
-you as the publisher of these copies. The front cover must present
-the full title with all words of the title equally prominent and
-visible. You may add other material on the covers in addition.
-Copying with changes limited to the covers, as long as they preserve
-the title of the Document and satisfy these conditions, can be treated
-as verbatim copying in other respects.
-.Sp
-If the required texts for either cover are too voluminous to fit
-legibly, you should put the first ones listed (as many as fit
-reasonably) on the actual cover, and continue the rest onto adjacent
-pages.
-.Sp
-If you publish or distribute Opaque copies of the Document numbering
-more than 100, you must either include a machine-readable Transparent
-copy along with each Opaque copy, or state in or with each Opaque copy
-a computer-network location from which the general network-using
-public has access to download using public-standard network protocols
-a complete Transparent copy of the Document, free of added material.
-If you use the latter option, you must take reasonably prudent steps,
-when you begin distribution of Opaque copies in quantity, to ensure
-that this Transparent copy will remain thus accessible at the stated
-location until at least one year after the last time you distribute an
-Opaque copy (directly or through your agents or retailers) of that
-edition to the public.
-.Sp
-It is requested, but not required, that you contact the authors of the
-Document well before redistributing any large number of copies, to give
-them a chance to provide you with an updated version of the Document.
-.IP "4." 4
-.IX Item "4."
-\&\s-1MODIFICATIONS\s0
-.Sp
-You may copy and distribute a Modified Version of the Document under
-the conditions of sections 2 and 3 above, provided that you release
-the Modified Version under precisely this License, with the Modified
-Version filling the role of the Document, thus licensing distribution
-and modification of the Modified Version to whoever possesses a copy
-of it. In addition, you must do these things in the Modified Version:
-.RS 4
-.IP "A." 4
-.IX Item "A."
-Use in the Title Page (and on the covers, if any) a title distinct
-from that of the Document, and from those of previous versions
-(which should, if there were any, be listed in the History section
-of the Document). You may use the same title as a previous version
-if the original publisher of that version gives permission.
-.IP "B." 4
-.IX Item "B."
-List on the Title Page, as authors, one or more persons or entities
-responsible for authorship of the modifications in the Modified
-Version, together with at least five of the principal authors of the
-Document (all of its principal authors, if it has fewer than five),
-unless they release you from this requirement.
-.IP "C." 4
-.IX Item "C."
-State on the Title page the name of the publisher of the
-Modified Version, as the publisher.
-.IP "D." 4
-.IX Item "D."
-Preserve all the copyright notices of the Document.
-.IP "E." 4
-.IX Item "E."
-Add an appropriate copyright notice for your modifications
-adjacent to the other copyright notices.
-.IP "F." 4
-.IX Item "F."
-Include, immediately after the copyright notices, a license notice
-giving the public permission to use the Modified Version under the
-terms of this License, in the form shown in the Addendum below.
-.IP "G." 4
-.IX Item "G."
-Preserve in that license notice the full lists of Invariant Sections
-and required Cover Texts given in the Document's license notice.
-.IP "H." 4
-.IX Item "H."
-Include an unaltered copy of this License.
-.IP "I." 4
-.IX Item "I."
-Preserve the section Entitled \*(L"History\*(R", Preserve its Title, and add
-to it an item stating at least the title, year, new authors, and
-publisher of the Modified Version as given on the Title Page. If
-there is no section Entitled \*(L"History\*(R" in the Document, create one
-stating the title, year, authors, and publisher of the Document as
-given on its Title Page, then add an item describing the Modified
-Version as stated in the previous sentence.
-.IP "J." 4
-.IX Item "J."
-Preserve the network location, if any, given in the Document for
-public access to a Transparent copy of the Document, and likewise
-the network locations given in the Document for previous versions
-it was based on. These may be placed in the \*(L"History\*(R" section.
-You may omit a network location for a work that was published at
-least four years before the Document itself, or if the original
-publisher of the version it refers to gives permission.
-.IP "K." 4
-.IX Item "K."
-For any section Entitled \*(L"Acknowledgements\*(R" or \*(L"Dedications\*(R", Preserve
-the Title of the section, and preserve in the section all the
-substance and tone of each of the contributor acknowledgements and/or
-dedications given therein.
-.IP "L." 4
-.IX Item "L."
-Preserve all the Invariant Sections of the Document,
-unaltered in their text and in their titles. Section numbers
-or the equivalent are not considered part of the section titles.
-.IP "M." 4
-.IX Item "M."
-Delete any section Entitled \*(L"Endorsements\*(R". Such a section
-may not be included in the Modified Version.
-.IP "N." 4
-.IX Item "N."
-Do not retitle any existing section to be Entitled \*(L"Endorsements\*(R" or
-to conflict in title with any Invariant Section.
-.IP "O." 4
-.IX Item "O."
-Preserve any Warranty Disclaimers.
-.RE
-.RS 4
-.Sp
-If the Modified Version includes new front-matter sections or
-appendices that qualify as Secondary Sections and contain no material
-copied from the Document, you may at your option designate some or all
-of these sections as invariant. To do this, add their titles to the
-list of Invariant Sections in the Modified Version's license notice.
-These titles must be distinct from any other section titles.
-.Sp
-You may add a section Entitled \*(L"Endorsements\*(R", provided it contains
-nothing but endorsements of your Modified Version by various
-parties\-\-\-for example, statements of peer review or that the text has
-been approved by an organization as the authoritative definition of a
-standard.
-.Sp
-You may add a passage of up to five words as a Front-Cover Text, and a
-passage of up to 25 words as a Back-Cover Text, to the end of the list
-of Cover Texts in the Modified Version. Only one passage of
-Front-Cover Text and one of Back-Cover Text may be added by (or
-through arrangements made by) any one entity. If the Document already
-includes a cover text for the same cover, previously added by you or
-by arrangement made by the same entity you are acting on behalf of,
-you may not add another; but you may replace the old one, on explicit
-permission from the previous publisher that added the old one.
-.Sp
-The author(s) and publisher(s) of the Document do not by this License
-give permission to use their names for publicity for or to assert or
-imply endorsement of any Modified Version.
-.RE
-.IP "5." 4
-.IX Item "5."
-\&\s-1COMBINING\s0 \s-1DOCUMENTS\s0
-.Sp
-You may combine the Document with other documents released under this
-License, under the terms defined in section 4 above for modified
-versions, provided that you include in the combination all of the
-Invariant Sections of all of the original documents, unmodified, and
-list them all as Invariant Sections of your combined work in its
-license notice, and that you preserve all their Warranty Disclaimers.
-.Sp
-The combined work need only contain one copy of this License, and
-multiple identical Invariant Sections may be replaced with a single
-copy. If there are multiple Invariant Sections with the same name but
-different contents, make the title of each such section unique by
-adding at the end of it, in parentheses, the name of the original
-author or publisher of that section if known, or else a unique number.
-Make the same adjustment to the section titles in the list of
-Invariant Sections in the license notice of the combined work.
-.Sp
-In the combination, you must combine any sections Entitled \*(L"History\*(R"
-in the various original documents, forming one section Entitled
-\&\*(L"History\*(R"; likewise combine any sections Entitled \*(L"Acknowledgements\*(R",
-and any sections Entitled \*(L"Dedications\*(R". You must delete all
-sections Entitled \*(L"Endorsements.\*(R"
-.IP "6." 4
-.IX Item "6."
-\&\s-1COLLECTIONS\s0 \s-1OF\s0 \s-1DOCUMENTS\s0
-.Sp
-You may make a collection consisting of the Document and other documents
-released under this License, and replace the individual copies of this
-License in the various documents with a single copy that is included in
-the collection, provided that you follow the rules of this License for
-verbatim copying of each of the documents in all other respects.
-.Sp
-You may extract a single document from such a collection, and distribute
-it individually under this License, provided you insert a copy of this
-License into the extracted document, and follow this License in all
-other respects regarding verbatim copying of that document.
-.IP "7." 4
-.IX Item "7."
-\&\s-1AGGREGATION\s0 \s-1WITH\s0 \s-1INDEPENDENT\s0 \s-1WORKS\s0
-.Sp
-A compilation of the Document or its derivatives with other separate
-and independent documents or works, in or on a volume of a storage or
-distribution medium, is called an \*(L"aggregate\*(R" if the copyright
-resulting from the compilation is not used to limit the legal rights
-of the compilation's users beyond what the individual works permit.
-When the Document is included in an aggregate, this License does not
-apply to the other works in the aggregate which are not themselves
-derivative works of the Document.
-.Sp
-If the Cover Text requirement of section 3 is applicable to these
-copies of the Document, then if the Document is less than one half of
-the entire aggregate, the Document's Cover Texts may be placed on
-covers that bracket the Document within the aggregate, or the
-electronic equivalent of covers if the Document is in electronic form.
-Otherwise they must appear on printed covers that bracket the whole
-aggregate.
-.IP "8." 4
-.IX Item "8."
-\&\s-1TRANSLATION\s0
-.Sp
-Translation is considered a kind of modification, so you may
-distribute translations of the Document under the terms of section 4.
-Replacing Invariant Sections with translations requires special
-permission from their copyright holders, but you may include
-translations of some or all Invariant Sections in addition to the
-original versions of these Invariant Sections. You may include a
-translation of this License, and all the license notices in the
-Document, and any Warranty Disclaimers, provided that you also include
-the original English version of this License and the original versions
-of those notices and disclaimers. In case of a disagreement between
-the translation and the original version of this License or a notice
-or disclaimer, the original version will prevail.
-.Sp
-If a section in the Document is Entitled \*(L"Acknowledgements\*(R",
-\&\*(L"Dedications\*(R", or \*(L"History\*(R", the requirement (section 4) to Preserve
-its Title (section 1) will typically require changing the actual
-title.
-.IP "9." 4
-.IX Item "9."
-\&\s-1TERMINATION\s0
-.Sp
-You may not copy, modify, sublicense, or distribute the Document
-except as expressly provided under this License. Any attempt
-otherwise to copy, modify, sublicense, or distribute it is void, and
-will automatically terminate your rights under this License.
-.Sp
-However, if you cease all violation of this License, then your license
-from a particular copyright holder is reinstated (a) provisionally,
-unless and until the copyright holder explicitly and finally
-terminates your license, and (b) permanently, if the copyright holder
-fails to notify you of the violation by some reasonable means prior to
-60 days after the cessation.
-.Sp
-Moreover, your license from a particular copyright holder is
-reinstated permanently if the copyright holder notifies you of the
-violation by some reasonable means, this is the first time you have
-received notice of violation of this License (for any work) from that
-copyright holder, and you cure the violation prior to 30 days after
-your receipt of the notice.
-.Sp
-Termination of your rights under this section does not terminate the
-licenses of parties who have received copies or rights from you under
-this License. If your rights have been terminated and not permanently
-reinstated, receipt of a copy of some or all of the same material does
-not give you any rights to use it.
-.IP "10." 4
-.IX Item "10."
-\&\s-1FUTURE\s0 \s-1REVISIONS\s0 \s-1OF\s0 \s-1THIS\s0 \s-1LICENSE\s0
-.Sp
-The Free Software Foundation may publish new, revised versions
-of the \s-1GNU\s0 Free Documentation License from time to time. Such new
-versions will be similar in spirit to the present version, but may
-differ in detail to address new problems or concerns. See
-<\fBhttp://www.gnu.org/copyleft/\fR>.
-.Sp
-Each version of the License is given a distinguishing version number.
-If the Document specifies that a particular numbered version of this
-License \*(L"or any later version\*(R" applies to it, you have the option of
-following the terms and conditions either of that specified version or
-of any later version that has been published (not as a draft) by the
-Free Software Foundation. If the Document does not specify a version
-number of this License, you may choose any version ever published (not
-as a draft) by the Free Software Foundation. If the Document
-specifies that a proxy can decide which future versions of this
-License can be used, that proxy's public statement of acceptance of a
-version permanently authorizes you to choose that version for the
-Document.
-.IP "11." 4
-.IX Item "11."
-\&\s-1RELICENSING\s0
-.Sp
-\&\*(L"Massive Multiauthor Collaboration Site\*(R" (or \*(L"\s-1MMC\s0 Site\*(R") means any
-World Wide Web server that publishes copyrightable works and also
-provides prominent facilities for anybody to edit those works. A
-public wiki that anybody can edit is an example of such a server. A
-\&\*(L"Massive Multiauthor Collaboration\*(R" (or \*(L"\s-1MMC\s0\*(R") contained in the
-site means any set of copyrightable works thus published on the \s-1MMC\s0
-site.
-.Sp
-\&\*(L"CC-BY-SA\*(R" means the Creative Commons Attribution-Share Alike 3.0
-license published by Creative Commons Corporation, a not-for-profit
-corporation with a principal place of business in San Francisco,
-California, as well as future copyleft versions of that license
-published by that same organization.
-.Sp
-\&\*(L"Incorporate\*(R" means to publish or republish a Document, in whole or
-in part, as part of another Document.
-.Sp
-An \s-1MMC\s0 is \*(L"eligible for relicensing\*(R" if it is licensed under this
-License, and if all works that were first published under this License
-somewhere other than this \s-1MMC\s0, and subsequently incorporated in whole
-or in part into the \s-1MMC\s0, (1) had no cover texts or invariant sections,
-and (2) were thus incorporated prior to November 1, 2008.
-.Sp
-The operator of an \s-1MMC\s0 Site may republish an \s-1MMC\s0 contained in the site
-under CC-BY-SA on the same site at any time before August 1, 2009,
-provided the \s-1MMC\s0 is eligible for relicensing.
-.SS "\s-1ADDENDUM:\s0 How to use this License for your documents"
-.IX Subsection "ADDENDUM: How to use this License for your documents"
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and
-license notices just after the title page:
-.PP
-.Vb 7
-\& Copyright (C) <year> <your name>.
-\& Permission is granted to copy, distribute and/or modify this document
-\& under the terms of the GNU Free Documentation License, Version 1.3
-\& or any later version published by the Free Software Foundation;
-\& with no Invariant Sections, no Front\-Cover Texts, and no Back\-Cover
-\& Texts. A copy of the license is included in the section entitled "GNU
-\& Free Documentation License".
-.Ve
-.PP
-If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
-replace the \*(L"with...Texts.\*(R" line with this:
-.PP
-.Vb 3
-\& with the Invariant Sections being <list their titles>, with
-\& the Front\-Cover Texts being <list>, and with the Back\-Cover Texts
-\& being <list>.
-.Ve
-.PP
-If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-.PP
-If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the \s-1GNU\s0 General Public License,
-to permit their use in free software.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIgpl\fR\|(7), \fIfsf\-funding\fR\|(7).
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
-<\fBhttp://fsf.org/\fR>
-.PP
-Everyone is permitted to copy and distribute verbatim copies
-of this license document, but changing it is not allowed.
diff --git a/share/man/man7/gpl.7 b/share/man/man7/gpl.7
deleted file mode 100644
index 18793ba..0000000
--- a/share/man/man7/gpl.7
+++ /dev/null
@@ -1,841 +0,0 @@
-.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
-.\"
-.\" Standard preamble:
-.\" ========================================================================
-.de Sp \" Vertical space (when we can't use .PP)
-.if t .sp .5v
-.if n .sp
-..
-.de Vb \" Begin verbatim text
-.ft CW
-.nf
-.ne \\$1
-..
-.de Ve \" End verbatim text
-.ft R
-.fi
-..
-.\" Set up some character translations and predefined strings. \*(-- will
-.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
-.\" double quote, and \*(R" will give a right double quote. \*(C+ will
-.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
-.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
-.\" nothing in troff, for use with C<>.
-.tr \(*W-
-.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
-.ie n \{\
-. ds -- \(*W-
-. ds PI pi
-. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
-. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
-. ds L" ""
-. ds R" ""
-. ds C` ""
-. ds C' ""
-'br\}
-.el\{\
-. ds -- \|\(em\|
-. ds PI \(*p
-. ds L" ``
-. ds R" ''
-'br\}
-.\"
-.\" Escape single quotes in literal strings from groff's Unicode transform.
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\"
-.\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
-.\" entries marked with X<> in POD. Of course, you'll have to process the
-.\" output yourself in some meaningful fashion.
-.ie \nF \{\
-. de IX
-. tm Index:\\$1\t\\n%\t"\\$2"
-..
-. nr % 0
-. rr F
-.\}
-.el \{\
-. de IX
-..
-.\}
-.\"
-.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
-.\" Fear. Run. Save yourself. No user-serviceable parts.
-. \" fudge factors for nroff and troff
-.if n \{\
-. ds #H 0
-. ds #V .8m
-. ds #F .3m
-. ds #[ \f1
-. ds #] \fP
-.\}
-.if t \{\
-. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
-. ds #V .6m
-. ds #F 0
-. ds #[ \&
-. ds #] \&
-.\}
-. \" simple accents for nroff and troff
-.if n \{\
-. ds ' \&
-. ds ` \&
-. ds ^ \&
-. ds , \&
-. ds ~ ~
-. ds /
-.\}
-.if t \{\
-. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
-. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
-. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
-. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
-. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
-. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
-.\}
-. \" troff and (daisy-wheel) nroff accents
-.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
-.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
-.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
-.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
-.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
-.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
-.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
-.ds ae a\h'-(\w'a'u*4/10)'e
-.ds Ae A\h'-(\w'A'u*4/10)'E
-. \" corrections for vroff
-.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
-.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
-. \" for low resolution devices (crt and lpr)
-.if \n(.H>23 .if \n(.V>19 \
-\{\
-. ds : e
-. ds 8 ss
-. ds o a
-. ds d- d\h'-1'\(ga
-. ds D- D\h'-1'\(hy
-. ds th \o'bp'
-. ds Th \o'LP'
-. ds ae ae
-. ds Ae AE
-.\}
-.rm #[ #] #H #V #F C
-.\" ========================================================================
-.\"
-.IX Title "GPL 7"
-.TH GPL 7 "2012-01-06" "gcc-4.6.x-google" "GNU"
-.\" For nroff, turn off justification. Always turn off hyphenation; it makes
-.\" way too many mistakes in technical documents.
-.if n .ad l
-.nh
-.SH "NAME"
-gpl \- GNU General Public License
-.SH "DESCRIPTION"
-.IX Header "DESCRIPTION"
-.SS "\s-1GNU\s0 General Public License"
-.IX Subsection "GNU General Public License"
-.SS "Version 3, 29 June 2007"
-.IX Subsection "Version 3, 29 June 2007"
-.Vb 1
-\& Copyright (c) 2007 Free Software Foundation, Inc. <http://fsf.org/>
-\&
-\& Everyone is permitted to copy and distribute verbatim copies of this
-\& license document, but changing it is not allowed.
-.Ve
-.SS "Preamble"
-.IX Subsection "Preamble"
-The \s-1GNU\s0 General Public License is a free, copyleft license for
-software and other kinds of works.
-.PP
-The licenses for most software and other practical works are designed
-to take away your freedom to share and change the works. By contrast,
-the \s-1GNU\s0 General Public License is intended to guarantee your freedom
-to share and change all versions of a program\*(--to make sure it remains
-free software for all its users. We, the Free Software Foundation,
-use the \s-1GNU\s0 General Public License for most of our software; it
-applies also to any other work released this way by its authors. You
-can apply it to your programs, too.
-.PP
-When we speak of free software, we are referring to freedom, not
-price. Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-them if you wish), that you receive source code or can get it if you
-want it, that you can change the software or use pieces of it in new
-free programs, and that you know you can do these things.
-.PP
-To protect your rights, we need to prevent others from denying you
-these rights or asking you to surrender the rights. Therefore, you
-have certain responsibilities if you distribute copies of the
-software, or if you modify it: responsibilities to respect the freedom
-of others.
-.PP
-For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must pass on to the recipients the same
-freedoms that you received. You must make sure that they, too,
-receive or can get the source code. And you must show them these
-terms so they know their rights.
-.PP
-Developers that use the \s-1GNU\s0 \s-1GPL\s0 protect your rights with two steps:
-(1) assert copyright on the software, and (2) offer you this License
-giving you legal permission to copy, distribute and/or modify it.
-.PP
-For the developers' and authors' protection, the \s-1GPL\s0 clearly explains
-that there is no warranty for this free software. For both users' and
-authors' sake, the \s-1GPL\s0 requires that modified versions be marked as
-changed, so that their problems will not be attributed erroneously to
-authors of previous versions.
-.PP
-Some devices are designed to deny users access to install or run
-modified versions of the software inside them, although the
-manufacturer can do so. This is fundamentally incompatible with the
-aim of protecting users' freedom to change the software. The
-systematic pattern of such abuse occurs in the area of products for
-individuals to use, which is precisely where it is most unacceptable.
-Therefore, we have designed this version of the \s-1GPL\s0 to prohibit the
-practice for those products. If such problems arise substantially in
-other domains, we stand ready to extend this provision to those
-domains in future versions of the \s-1GPL\s0, as needed to protect the
-freedom of users.
-.PP
-Finally, every program is threatened constantly by software patents.
-States should not allow patents to restrict development and use of
-software on general-purpose computers, but in those that do, we wish
-to avoid the special danger that patents applied to a free program
-could make it effectively proprietary. To prevent this, the \s-1GPL\s0
-assures that patents cannot be used to render the program non-free.
-.PP
-The precise terms and conditions for copying, distribution and
-modification follow.
-.SS "\s-1TERMS\s0 \s-1AND\s0 \s-1CONDITIONS\s0"
-.IX Subsection "TERMS AND CONDITIONS"
-.IP "0. Definitions." 4
-.IX Item "0. Definitions."
-\&\*(L"This License\*(R" refers to version 3 of the \s-1GNU\s0 General Public License.
-.Sp
-\&\*(L"Copyright\*(R" also means copyright-like laws that apply to other kinds
-of works, such as semiconductor masks.
-.Sp
-\&\*(L"The Program\*(R" refers to any copyrightable work licensed under this
-License. Each licensee is addressed as \*(L"you\*(R". \*(L"Licensees\*(R" and
-\&\*(L"recipients\*(R" may be individuals or organizations.
-.Sp
-To \*(L"modify\*(R" a work means to copy from or adapt all or part of the work
-in a fashion requiring copyright permission, other than the making of
-an exact copy. The resulting work is called a \*(L"modified version\*(R" of
-the earlier work or a work \*(L"based on\*(R" the earlier work.
-.Sp
-A \*(L"covered work\*(R" means either the unmodified Program or a work based
-on the Program.
-.Sp
-To \*(L"propagate\*(R" a work means to do anything with it that, without
-permission, would make you directly or secondarily liable for
-infringement under applicable copyright law, except executing it on a
-computer or modifying a private copy. Propagation includes copying,
-distribution (with or without modification), making available to the
-public, and in some countries other activities as well.
-.Sp
-To \*(L"convey\*(R" a work means any kind of propagation that enables other
-parties to make or receive copies. Mere interaction with a user
-through a computer network, with no transfer of a copy, is not
-conveying.
-.Sp
-An interactive user interface displays \*(L"Appropriate Legal Notices\*(R" to
-the extent that it includes a convenient and prominently visible
-feature that (1) displays an appropriate copyright notice, and (2)
-tells the user that there is no warranty for the work (except to the
-extent that warranties are provided), that licensees may convey the
-work under this License, and how to view a copy of this License. If
-the interface presents a list of user commands or options, such as a
-menu, a prominent item in the list meets this criterion.
-.IP "1. Source Code." 4
-.IX Item "1. Source Code."
-The \*(L"source code\*(R" for a work means the preferred form of the work for
-making modifications to it. \*(L"Object code\*(R" means any non-source form
-of a work.
-.Sp
-A \*(L"Standard Interface\*(R" means an interface that either is an official
-standard defined by a recognized standards body, or, in the case of
-interfaces specified for a particular programming language, one that
-is widely used among developers working in that language.
-.Sp
-The \*(L"System Libraries\*(R" of an executable work include anything, other
-than the work as a whole, that (a) is included in the normal form of
-packaging a Major Component, but which is not part of that Major
-Component, and (b) serves only to enable use of the work with that
-Major Component, or to implement a Standard Interface for which an
-implementation is available to the public in source code form. A
-\&\*(L"Major Component\*(R", in this context, means a major essential component
-(kernel, window system, and so on) of the specific operating system
-(if any) on which the executable work runs, or a compiler used to
-produce the work, or an object code interpreter used to run it.
-.Sp
-The \*(L"Corresponding Source\*(R" for a work in object code form means all
-the source code needed to generate, install, and (for an executable
-work) run the object code and to modify the work, including scripts to
-control those activities. However, it does not include the work's
-System Libraries, or general-purpose tools or generally available free
-programs which are used unmodified in performing those activities but
-which are not part of the work. For example, Corresponding Source
-includes interface definition files associated with source files for
-the work, and the source code for shared libraries and dynamically
-linked subprograms that the work is specifically designed to require,
-such as by intimate data communication or control flow between those
-subprograms and other parts of the work.
-.Sp
-The Corresponding Source need not include anything that users can
-regenerate automatically from other parts of the Corresponding Source.
-.Sp
-The Corresponding Source for a work in source code form is that same
-work.
-.IP "2. Basic Permissions." 4
-.IX Item "2. Basic Permissions."
-All rights granted under this License are granted for the term of
-copyright on the Program, and are irrevocable provided the stated
-conditions are met. This License explicitly affirms your unlimited
-permission to run the unmodified Program. The output from running a
-covered work is covered by this License only if the output, given its
-content, constitutes a covered work. This License acknowledges your
-rights of fair use or other equivalent, as provided by copyright law.
-.Sp
-You may make, run and propagate covered works that you do not convey,
-without conditions so long as your license otherwise remains in force.
-You may convey covered works to others for the sole purpose of having
-them make modifications exclusively for you, or provide you with
-facilities for running those works, provided that you comply with the
-terms of this License in conveying all material for which you do not
-control copyright. Those thus making or running the covered works for
-you must do so exclusively on your behalf, under your direction and
-control, on terms that prohibit them from making any copies of your
-copyrighted material outside their relationship with you.
-.Sp
-Conveying under any other circumstances is permitted solely under the
-conditions stated below. Sublicensing is not allowed; section 10
-makes it unnecessary.
-.IP "3. Protecting Users' Legal Rights From Anti-Circumvention Law." 4
-.IX Item "3. Protecting Users' Legal Rights From Anti-Circumvention Law."
-No covered work shall be deemed part of an effective technological
-measure under any applicable law fulfilling obligations under article
-11 of the \s-1WIPO\s0 copyright treaty adopted on 20 December 1996, or
-similar laws prohibiting or restricting circumvention of such
-measures.
-.Sp
-When you convey a covered work, you waive any legal power to forbid
-circumvention of technological measures to the extent such
-circumvention is effected by exercising rights under this License with
-respect to the covered work, and you disclaim any intention to limit
-operation or modification of the work as a means of enforcing, against
-the work's users, your or third parties' legal rights to forbid
-circumvention of technological measures.
-.IP "4. Conveying Verbatim Copies." 4
-.IX Item "4. Conveying Verbatim Copies."
-You may convey verbatim copies of the Program's source code as you
-receive it, in any medium, provided that you conspicuously and
-appropriately publish on each copy an appropriate copyright notice;
-keep intact all notices stating that this License and any
-non-permissive terms added in accord with section 7 apply to the code;
-keep intact all notices of the absence of any warranty; and give all
-recipients a copy of this License along with the Program.
-.Sp
-You may charge any price or no price for each copy that you convey,
-and you may offer support or warranty protection for a fee.
-.IP "5. Conveying Modified Source Versions." 4
-.IX Item "5. Conveying Modified Source Versions."
-You may convey a work based on the Program, or the modifications to
-produce it from the Program, in the form of source code under the
-terms of section 4, provided that you also meet all of these
-conditions:
-.RS 4
-.IP "a." 4
-.IX Item "a."
-The work must carry prominent notices stating that you modified it,
-and giving a relevant date.
-.IP "b." 4
-.IX Item "b."
-The work must carry prominent notices stating that it is released
-under this License and any conditions added under section 7. This
-requirement modifies the requirement in section 4 to \*(L"keep intact all
-notices\*(R".
-.IP "c." 4
-.IX Item "c."
-You must license the entire work, as a whole, under this License to
-anyone who comes into possession of a copy. This License will
-therefore apply, along with any applicable section 7 additional terms,
-to the whole of the work, and all its parts, regardless of how they
-are packaged. This License gives no permission to license the work in
-any other way, but it does not invalidate such permission if you have
-separately received it.
-.IP "d." 4
-.IX Item "d."
-If the work has interactive user interfaces, each must display
-Appropriate Legal Notices; however, if the Program has interactive
-interfaces that do not display Appropriate Legal Notices, your work
-need not make them do so.
-.RE
-.RS 4
-.Sp
-A compilation of a covered work with other separate and independent
-works, which are not by their nature extensions of the covered work,
-and which are not combined with it such as to form a larger program,
-in or on a volume of a storage or distribution medium, is called an
-\&\*(L"aggregate\*(R" if the compilation and its resulting copyright are not
-used to limit the access or legal rights of the compilation's users
-beyond what the individual works permit. Inclusion of a covered work
-in an aggregate does not cause this License to apply to the other
-parts of the aggregate.
-.RE
-.IP "6. Conveying Non-Source Forms." 4
-.IX Item "6. Conveying Non-Source Forms."
-You may convey a covered work in object code form under the terms of
-sections 4 and 5, provided that you also convey the machine-readable
-Corresponding Source under the terms of this License, in one of these
-ways:
-.RS 4
-.IP "a." 4
-.IX Item "a."
-Convey the object code in, or embodied in, a physical product
-(including a physical distribution medium), accompanied by the
-Corresponding Source fixed on a durable physical medium customarily
-used for software interchange.
-.IP "b." 4
-.IX Item "b."
-Convey the object code in, or embodied in, a physical product
-(including a physical distribution medium), accompanied by a written
-offer, valid for at least three years and valid for as long as you
-offer spare parts or customer support for that product model, to give
-anyone who possesses the object code either (1) a copy of the
-Corresponding Source for all the software in the product that is
-covered by this License, on a durable physical medium customarily used
-for software interchange, for a price no more than your reasonable
-cost of physically performing this conveying of source, or (2) access
-to copy the Corresponding Source from a network server at no charge.
-.IP "c." 4
-.IX Item "c."
-Convey individual copies of the object code with a copy of the written
-offer to provide the Corresponding Source. This alternative is
-allowed only occasionally and noncommercially, and only if you
-received the object code with such an offer, in accord with subsection
-6b.
-.IP "d." 4
-.IX Item "d."
-Convey the object code by offering access from a designated place
-(gratis or for a charge), and offer equivalent access to the
-Corresponding Source in the same way through the same place at no
-further charge. You need not require recipients to copy the
-Corresponding Source along with the object code. If the place to copy
-the object code is a network server, the Corresponding Source may be
-on a different server (operated by you or a third party) that supports
-equivalent copying facilities, provided you maintain clear directions
-next to the object code saying where to find the Corresponding Source.
-Regardless of what server hosts the Corresponding Source, you remain
-obligated to ensure that it is available for as long as needed to
-satisfy these requirements.
-.IP "e." 4
-.IX Item "e."
-Convey the object code using peer-to-peer transmission, provided you
-inform other peers where the object code and Corresponding Source of
-the work are being offered to the general public at no charge under
-subsection 6d.
-.RE
-.RS 4
-.Sp
-A separable portion of the object code, whose source code is excluded
-from the Corresponding Source as a System Library, need not be
-included in conveying the object code work.
-.Sp
-A \*(L"User Product\*(R" is either (1) a \*(L"consumer product\*(R", which means any
-tangible personal property which is normally used for personal,
-family, or household purposes, or (2) anything designed or sold for
-incorporation into a dwelling. In determining whether a product is a
-consumer product, doubtful cases shall be resolved in favor of
-coverage. For a particular product received by a particular user,
-\&\*(L"normally used\*(R" refers to a typical or common use of that class of
-product, regardless of the status of the particular user or of the way
-in which the particular user actually uses, or expects or is expected
-to use, the product. A product is a consumer product regardless of
-whether the product has substantial commercial, industrial or
-non-consumer uses, unless such uses represent the only significant
-mode of use of the product.
-.Sp
-\&\*(L"Installation Information\*(R" for a User Product means any methods,
-procedures, authorization keys, or other information required to
-install and execute modified versions of a covered work in that User
-Product from a modified version of its Corresponding Source. The
-information must suffice to ensure that the continued functioning of
-the modified object code is in no case prevented or interfered with
-solely because modification has been made.
-.Sp
-If you convey an object code work under this section in, or with, or
-specifically for use in, a User Product, and the conveying occurs as
-part of a transaction in which the right of possession and use of the
-User Product is transferred to the recipient in perpetuity or for a
-fixed term (regardless of how the transaction is characterized), the
-Corresponding Source conveyed under this section must be accompanied
-by the Installation Information. But this requirement does not apply
-if neither you nor any third party retains the ability to install
-modified object code on the User Product (for example, the work has
-been installed in \s-1ROM\s0).
-.Sp
-The requirement to provide Installation Information does not include a
-requirement to continue to provide support service, warranty, or
-updates for a work that has been modified or installed by the
-recipient, or for the User Product in which it has been modified or
-installed. Access to a network may be denied when the modification
-itself materially and adversely affects the operation of the network
-or violates the rules and protocols for communication across the
-network.
-.Sp
-Corresponding Source conveyed, and Installation Information provided,
-in accord with this section must be in a format that is publicly
-documented (and with an implementation available to the public in
-source code form), and must require no special password or key for
-unpacking, reading or copying.
-.RE
-.IP "7. Additional Terms." 4
-.IX Item "7. Additional Terms."
-\&\*(L"Additional permissions\*(R" are terms that supplement the terms of this
-License by making exceptions from one or more of its conditions.
-Additional permissions that are applicable to the entire Program shall
-be treated as though they were included in this License, to the extent
-that they are valid under applicable law. If additional permissions
-apply only to part of the Program, that part may be used separately
-under those permissions, but the entire Program remains governed by
-this License without regard to the additional permissions.
-.Sp
-When you convey a copy of a covered work, you may at your option
-remove any additional permissions from that copy, or from any part of
-it. (Additional permissions may be written to require their own
-removal in certain cases when you modify the work.) You may place
-additional permissions on material, added by you to a covered work,
-for which you have or can give appropriate copyright permission.
-.Sp
-Notwithstanding any other provision of this License, for material you
-add to a covered work, you may (if authorized by the copyright holders
-of that material) supplement the terms of this License with terms:
-.RS 4
-.IP "a." 4
-.IX Item "a."
-Disclaiming warranty or limiting liability differently from the terms
-of sections 15 and 16 of this License; or
-.IP "b." 4
-.IX Item "b."
-Requiring preservation of specified reasonable legal notices or author
-attributions in that material or in the Appropriate Legal Notices
-displayed by works containing it; or
-.IP "c." 4
-.IX Item "c."
-Prohibiting misrepresentation of the origin of that material, or
-requiring that modified versions of such material be marked in
-reasonable ways as different from the original version; or
-.IP "d." 4
-.IX Item "d."
-Limiting the use for publicity purposes of names of licensors or
-authors of the material; or
-.IP "e." 4
-.IX Item "e."
-Declining to grant rights under trademark law for use of some trade
-names, trademarks, or service marks; or
-.IP "f." 4
-.IX Item "f."
-Requiring indemnification of licensors and authors of that material by
-anyone who conveys the material (or modified versions of it) with
-contractual assumptions of liability to the recipient, for any
-liability that these contractual assumptions directly impose on those
-licensors and authors.
-.RE
-.RS 4
-.Sp
-All other non-permissive additional terms are considered \*(L"further
-restrictions\*(R" within the meaning of section 10. If the Program as you
-received it, or any part of it, contains a notice stating that it is
-governed by this License along with a term that is a further
-restriction, you may remove that term. If a license document contains
-a further restriction but permits relicensing or conveying under this
-License, you may add to a covered work material governed by the terms
-of that license document, provided that the further restriction does
-not survive such relicensing or conveying.
-.Sp
-If you add terms to a covered work in accord with this section, you
-must place, in the relevant source files, a statement of the
-additional terms that apply to those files, or a notice indicating
-where to find the applicable terms.
-.Sp
-Additional terms, permissive or non-permissive, may be stated in the
-form of a separately written license, or stated as exceptions; the
-above requirements apply either way.
-.RE
-.IP "8. Termination." 4
-.IX Item "8. Termination."
-You may not propagate or modify a covered work except as expressly
-provided under this License. Any attempt otherwise to propagate or
-modify it is void, and will automatically terminate your rights under
-this License (including any patent licenses granted under the third
-paragraph of section 11).
-.Sp
-However, if you cease all violation of this License, then your license
-from a particular copyright holder is reinstated (a) provisionally,
-unless and until the copyright holder explicitly and finally
-terminates your license, and (b) permanently, if the copyright holder
-fails to notify you of the violation by some reasonable means prior to
-60 days after the cessation.
-.Sp
-Moreover, your license from a particular copyright holder is
-reinstated permanently if the copyright holder notifies you of the
-violation by some reasonable means, this is the first time you have
-received notice of violation of this License (for any work) from that
-copyright holder, and you cure the violation prior to 30 days after
-your receipt of the notice.
-.Sp
-Termination of your rights under this section does not terminate the
-licenses of parties who have received copies or rights from you under
-this License. If your rights have been terminated and not permanently
-reinstated, you do not qualify to receive new licenses for the same
-material under section 10.
-.IP "9. Acceptance Not Required for Having Copies." 4
-.IX Item "9. Acceptance Not Required for Having Copies."
-You are not required to accept this License in order to receive or run
-a copy of the Program. Ancillary propagation of a covered work
-occurring solely as a consequence of using peer-to-peer transmission
-to receive a copy likewise does not require acceptance. However,
-nothing other than this License grants you permission to propagate or
-modify any covered work. These actions infringe copyright if you do
-not accept this License. Therefore, by modifying or propagating a
-covered work, you indicate your acceptance of this License to do so.
-.IP "10. Automatic Licensing of Downstream Recipients." 4
-.IX Item "10. Automatic Licensing of Downstream Recipients."
-Each time you convey a covered work, the recipient automatically
-receives a license from the original licensors, to run, modify and
-propagate that work, subject to this License. You are not responsible
-for enforcing compliance by third parties with this License.
-.Sp
-An \*(L"entity transaction\*(R" is a transaction transferring control of an
-organization, or substantially all assets of one, or subdividing an
-organization, or merging organizations. If propagation of a covered
-work results from an entity transaction, each party to that
-transaction who receives a copy of the work also receives whatever
-licenses to the work the party's predecessor in interest had or could
-give under the previous paragraph, plus a right to possession of the
-Corresponding Source of the work from the predecessor in interest, if
-the predecessor has it or can get it with reasonable efforts.
-.Sp
-You may not impose any further restrictions on the exercise of the
-rights granted or affirmed under this License. For example, you may
-not impose a license fee, royalty, or other charge for exercise of
-rights granted under this License, and you may not initiate litigation
-(including a cross-claim or counterclaim in a lawsuit) alleging that
-any patent claim is infringed by making, using, selling, offering for
-sale, or importing the Program or any portion of it.
-.IP "11. Patents." 4
-.IX Item "11. Patents."
-A \*(L"contributor\*(R" is a copyright holder who authorizes use under this
-License of the Program or a work on which the Program is based. The
-work thus licensed is called the contributor's \*(L"contributor version\*(R".
-.Sp
-A contributor's \*(L"essential patent claims\*(R" are all patent claims owned
-or controlled by the contributor, whether already acquired or
-hereafter acquired, that would be infringed by some manner, permitted
-by this License, of making, using, or selling its contributor version,
-but do not include claims that would be infringed only as a
-consequence of further modification of the contributor version. For
-purposes of this definition, \*(L"control\*(R" includes the right to grant
-patent sublicenses in a manner consistent with the requirements of
-this License.
-.Sp
-Each contributor grants you a non-exclusive, worldwide, royalty-free
-patent license under the contributor's essential patent claims, to
-make, use, sell, offer for sale, import and otherwise run, modify and
-propagate the contents of its contributor version.
-.Sp
-In the following three paragraphs, a \*(L"patent license\*(R" is any express
-agreement or commitment, however denominated, not to enforce a patent
-(such as an express permission to practice a patent or covenant not to
-sue for patent infringement). To \*(L"grant\*(R" such a patent license to a
-party means to make such an agreement or commitment not to enforce a
-patent against the party.
-.Sp
-If you convey a covered work, knowingly relying on a patent license,
-and the Corresponding Source of the work is not available for anyone
-to copy, free of charge and under the terms of this License, through a
-publicly available network server or other readily accessible means,
-then you must either (1) cause the Corresponding Source to be so
-available, or (2) arrange to deprive yourself of the benefit of the
-patent license for this particular work, or (3) arrange, in a manner
-consistent with the requirements of this License, to extend the patent
-license to downstream recipients. \*(L"Knowingly relying\*(R" means you have
-actual knowledge that, but for the patent license, your conveying the
-covered work in a country, or your recipient's use of the covered work
-in a country, would infringe one or more identifiable patents in that
-country that you have reason to believe are valid.
-.Sp
-If, pursuant to or in connection with a single transaction or
-arrangement, you convey, or propagate by procuring conveyance of, a
-covered work, and grant a patent license to some of the parties
-receiving the covered work authorizing them to use, propagate, modify
-or convey a specific copy of the covered work, then the patent license
-you grant is automatically extended to all recipients of the covered
-work and works based on it.
-.Sp
-A patent license is \*(L"discriminatory\*(R" if it does not include within the
-scope of its coverage, prohibits the exercise of, or is conditioned on
-the non-exercise of one or more of the rights that are specifically
-granted under this License. You may not convey a covered work if you
-are a party to an arrangement with a third party that is in the
-business of distributing software, under which you make payment to the
-third party based on the extent of your activity of conveying the
-work, and under which the third party grants, to any of the parties
-who would receive the covered work from you, a discriminatory patent
-license (a) in connection with copies of the covered work conveyed by
-you (or copies made from those copies), or (b) primarily for and in
-connection with specific products or compilations that contain the
-covered work, unless you entered into that arrangement, or that patent
-license was granted, prior to 28 March 2007.
-.Sp
-Nothing in this License shall be construed as excluding or limiting
-any implied license or other defenses to infringement that may
-otherwise be available to you under applicable patent law.
-.IP "12. No Surrender of Others' Freedom." 4
-.IX Item "12. No Surrender of Others' Freedom."
-If conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License. If you cannot convey
-a covered work so as to satisfy simultaneously your obligations under
-this License and any other pertinent obligations, then as a
-consequence you may not convey it at all. For example, if you agree
-to terms that obligate you to collect a royalty for further conveying
-from those to whom you convey the Program, the only way you could
-satisfy both those terms and this License would be to refrain entirely
-from conveying the Program.
-.IP "13. Use with the \s-1GNU\s0 Affero General Public License." 4
-.IX Item "13. Use with the GNU Affero General Public License."
-Notwithstanding any other provision of this License, you have
-permission to link or combine any covered work with a work licensed
-under version 3 of the \s-1GNU\s0 Affero General Public License into a single
-combined work, and to convey the resulting work. The terms of this
-License will continue to apply to the part which is the covered work,
-but the special requirements of the \s-1GNU\s0 Affero General Public License,
-section 13, concerning interaction through a network will apply to the
-combination as such.
-.IP "14. Revised Versions of this License." 4
-.IX Item "14. Revised Versions of this License."
-The Free Software Foundation may publish revised and/or new versions
-of the \s-1GNU\s0 General Public License from time to time. Such new
-versions will be similar in spirit to the present version, but may
-differ in detail to address new problems or concerns.
-.Sp
-Each version is given a distinguishing version number. If the Program
-specifies that a certain numbered version of the \s-1GNU\s0 General Public
-License \*(L"or any later version\*(R" applies to it, you have the option of
-following the terms and conditions either of that numbered version or
-of any later version published by the Free Software Foundation. If
-the Program does not specify a version number of the \s-1GNU\s0 General
-Public License, you may choose any version ever published by the Free
-Software Foundation.
-.Sp
-If the Program specifies that a proxy can decide which future versions
-of the \s-1GNU\s0 General Public License can be used, that proxy's public
-statement of acceptance of a version permanently authorizes you to
-choose that version for the Program.
-.Sp
-Later license versions may give you additional or different
-permissions. However, no additional obligations are imposed on any
-author or copyright holder as a result of your choosing to follow a
-later version.
-.IP "15. Disclaimer of Warranty." 4
-.IX Item "15. Disclaimer of Warranty."
-\&\s-1THERE\s0 \s-1IS\s0 \s-1NO\s0 \s-1WARRANTY\s0 \s-1FOR\s0 \s-1THE\s0 \s-1PROGRAM\s0, \s-1TO\s0 \s-1THE\s0 \s-1EXTENT\s0 \s-1PERMITTED\s0 \s-1BY\s0
-\&\s-1APPLICABLE\s0 \s-1LAW\s0. \s-1EXCEPT\s0 \s-1WHEN\s0 \s-1OTHERWISE\s0 \s-1STATED\s0 \s-1IN\s0 \s-1WRITING\s0 \s-1THE\s0 \s-1COPYRIGHT\s0
-\&\s-1HOLDERS\s0 \s-1AND/OR\s0 \s-1OTHER\s0 \s-1PARTIES\s0 \s-1PROVIDE\s0 \s-1THE\s0 \s-1PROGRAM\s0 \*(L"\s-1AS\s0 \s-1IS\s0\*(R" \s-1WITHOUT\s0
-\&\s-1WARRANTY\s0 \s-1OF\s0 \s-1ANY\s0 \s-1KIND\s0, \s-1EITHER\s0 \s-1EXPRESSED\s0 \s-1OR\s0 \s-1IMPLIED\s0, \s-1INCLUDING\s0, \s-1BUT\s0 \s-1NOT\s0
-\&\s-1LIMITED\s0 \s-1TO\s0, \s-1THE\s0 \s-1IMPLIED\s0 \s-1WARRANTIES\s0 \s-1OF\s0 \s-1MERCHANTABILITY\s0 \s-1AND\s0 \s-1FITNESS\s0 \s-1FOR\s0
-A \s-1PARTICULAR\s0 \s-1PURPOSE\s0. \s-1THE\s0 \s-1ENTIRE\s0 \s-1RISK\s0 \s-1AS\s0 \s-1TO\s0 \s-1THE\s0 \s-1QUALITY\s0 \s-1AND\s0
-\&\s-1PERFORMANCE\s0 \s-1OF\s0 \s-1THE\s0 \s-1PROGRAM\s0 \s-1IS\s0 \s-1WITH\s0 \s-1YOU\s0. \s-1SHOULD\s0 \s-1THE\s0 \s-1PROGRAM\s0 \s-1PROVE\s0
-\&\s-1DEFECTIVE\s0, \s-1YOU\s0 \s-1ASSUME\s0 \s-1THE\s0 \s-1COST\s0 \s-1OF\s0 \s-1ALL\s0 \s-1NECESSARY\s0 \s-1SERVICING\s0, \s-1REPAIR\s0 \s-1OR\s0
-\&\s-1CORRECTION\s0.
-.IP "16. Limitation of Liability." 4
-.IX Item "16. Limitation of Liability."
-\&\s-1IN\s0 \s-1NO\s0 \s-1EVENT\s0 \s-1UNLESS\s0 \s-1REQUIRED\s0 \s-1BY\s0 \s-1APPLICABLE\s0 \s-1LAW\s0 \s-1OR\s0 \s-1AGREED\s0 \s-1TO\s0 \s-1IN\s0 \s-1WRITING\s0
-\&\s-1WILL\s0 \s-1ANY\s0 \s-1COPYRIGHT\s0 \s-1HOLDER\s0, \s-1OR\s0 \s-1ANY\s0 \s-1OTHER\s0 \s-1PARTY\s0 \s-1WHO\s0 \s-1MODIFIES\s0 \s-1AND/OR\s0
-\&\s-1CONVEYS\s0 \s-1THE\s0 \s-1PROGRAM\s0 \s-1AS\s0 \s-1PERMITTED\s0 \s-1ABOVE\s0, \s-1BE\s0 \s-1LIABLE\s0 \s-1TO\s0 \s-1YOU\s0 \s-1FOR\s0 \s-1DAMAGES\s0,
-\&\s-1INCLUDING\s0 \s-1ANY\s0 \s-1GENERAL\s0, \s-1SPECIAL\s0, \s-1INCIDENTAL\s0 \s-1OR\s0 \s-1CONSEQUENTIAL\s0 \s-1DAMAGES\s0
-\&\s-1ARISING\s0 \s-1OUT\s0 \s-1OF\s0 \s-1THE\s0 \s-1USE\s0 \s-1OR\s0 \s-1INABILITY\s0 \s-1TO\s0 \s-1USE\s0 \s-1THE\s0 \s-1PROGRAM\s0 (\s-1INCLUDING\s0 \s-1BUT\s0
-\&\s-1NOT\s0 \s-1LIMITED\s0 \s-1TO\s0 \s-1LOSS\s0 \s-1OF\s0 \s-1DATA\s0 \s-1OR\s0 \s-1DATA\s0 \s-1BEING\s0 \s-1RENDERED\s0 \s-1INACCURATE\s0 \s-1OR\s0
-\&\s-1LOSSES\s0 \s-1SUSTAINED\s0 \s-1BY\s0 \s-1YOU\s0 \s-1OR\s0 \s-1THIRD\s0 \s-1PARTIES\s0 \s-1OR\s0 A \s-1FAILURE\s0 \s-1OF\s0 \s-1THE\s0 \s-1PROGRAM\s0
-\&\s-1TO\s0 \s-1OPERATE\s0 \s-1WITH\s0 \s-1ANY\s0 \s-1OTHER\s0 \s-1PROGRAMS\s0), \s-1EVEN\s0 \s-1IF\s0 \s-1SUCH\s0 \s-1HOLDER\s0 \s-1OR\s0 \s-1OTHER\s0
-\&\s-1PARTY\s0 \s-1HAS\s0 \s-1BEEN\s0 \s-1ADVISED\s0 \s-1OF\s0 \s-1THE\s0 \s-1POSSIBILITY\s0 \s-1OF\s0 \s-1SUCH\s0 \s-1DAMAGES\s0.
-.IP "17. Interpretation of Sections 15 and 16." 4
-.IX Item "17. Interpretation of Sections 15 and 16."
-If the disclaimer of warranty and limitation of liability provided
-above cannot be given local legal effect according to their terms,
-reviewing courts shall apply local law that most closely approximates
-an absolute waiver of all civil liability in connection with the
-Program, unless a warranty or assumption of liability accompanies a
-copy of the Program in return for a fee.
-.SS "\s-1END\s0 \s-1OF\s0 \s-1TERMS\s0 \s-1AND\s0 \s-1CONDITIONS\s0"
-.IX Subsection "END OF TERMS AND CONDITIONS"
-.SS "How to Apply These Terms to Your New Programs"
-.IX Subsection "How to Apply These Terms to Your New Programs"
-If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these
-terms.
-.PP
-To do so, attach the following notices to the program. It is safest
-to attach them to the start of each source file to most effectively
-state the exclusion of warranty; and each file should have at least
-the \*(L"copyright\*(R" line and a pointer to where the full notice is found.
-.PP
-.Vb 2
-\& <one line to give the program\*(Aqs name and a brief idea of what it does.>
-\& Copyright (C) <year> <name of author>
-\&
-\& This program is free software: you can redistribute it and/or modify
-\& it under the terms of the GNU General Public License as published by
-\& the Free Software Foundation, either version 3 of the License, or (at
-\& your option) any later version.
-\&
-\& This program is distributed in the hope that it will be useful, but
-\& WITHOUT ANY WARRANTY; without even the implied warranty of
-\& MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-\& General Public License for more details.
-\&
-\& You should have received a copy of the GNU General Public License
-\& along with this program. If not, see <http://www.gnu.org/licenses/>.
-.Ve
-.PP
-Also add information on how to contact you by electronic and paper mail.
-.PP
-If the program does terminal interaction, make it output a short
-notice like this when it starts in an interactive mode:
-.PP
-.Vb 4
-\& <program> Copyright (C) <year> <name of author>
-\& This program comes with ABSOLUTELY NO WARRANTY; for details type "show w".
-\& This is free software, and you are welcome to redistribute it
-\& under certain conditions; type "show c" for details.
-.Ve
-.PP
-The hypothetical commands \fBshow w\fR and \fBshow c\fR should show
-the appropriate parts of the General Public License. Of course, your
-program's commands might be different; for a \s-1GUI\s0 interface, you would
-use an \*(L"about box\*(R".
-.PP
-You should also get your employer (if you work as a programmer) or school,
-if any, to sign a \*(L"copyright disclaimer\*(R" for the program, if necessary.
-For more information on this, and how to apply and follow the \s-1GNU\s0 \s-1GPL\s0, see
-<\fBhttp://www.gnu.org/licenses/\fR>.
-.PP
-The \s-1GNU\s0 General Public License does not permit incorporating your
-program into proprietary programs. If your program is a subroutine
-library, you may consider it more useful to permit linking proprietary
-applications with the library. If this is what you want to do, use
-the \s-1GNU\s0 Lesser General Public License instead of this License. But
-first, please read <\fBhttp://www.gnu.org/philosophy/why\-not\-lgpl.html\fR>.
-.SH "SEE ALSO"
-.IX Header "SEE ALSO"
-\&\fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7).
-.SH "COPYRIGHT"
-.IX Header "COPYRIGHT"
-Copyright (c) 2007 Free Software Foundation, Inc.
-.PP
-Everyone is permitted to copy and distribute verbatim copies of this
-license document, but changing it is not allowed.